Who's King?

The interest in UI modeling has grown during the last year, resulting in a quite impressive group of interested parties and participants for our Presentation Modeling Framework project at Eclipse. During ESE and afterwards we had a lot of discussion about modeling UI's at different abstraction levels. PMF aims to cover the whole spectrum hopefully creating a vibrant ecosystem of models and tooling to pick from.

There are quite a few examples of UI modeling using annotations or marking models to define a UI. The idea behind it is to use the information from the domain model to quickly define a user interface. The advantages are ease of specification and direct use of the domain model available. In my opinion this is great for basic editors and CRUD-like user interaction, but will break down for enterprise level administrative applications where the process and task structure is dominant. It's a question of "who's king?". If you just need property editors and developer style user interfaces, direct representation of domain objects on the UI is sufficient. If you need different viewpoints using various combinations of domain data in numerous scenarios, naked objects will not get you there. Process, task and user interface are king!
A full DSL (on any abstraction level) is needed to support the demanding UI requirements of modern day end users. The UI model is the starting point. The UI model will reference domain concepts and constraints and work together with process descriptions. This is ofcourse what will be provided in the PMF project and shown for the first time during EclipseCon 2009.

I am very excited about everything happening around UI modeling and I hope our PMF talk at EclipseCon will raise the awareness of all the possibilities. Hope to see you there.

Another thing I am looking forward to besides EclipseCon and the great modeling people is the day after EclipseCon. As an ex-basketball dutch international I always wanted to attend an NBA basketball game. In 2009 this will finally happen as I have tickets for the Cleveland Cavaliers game on the 27th to see King James in action! No question who's king in Cleveland. Like in modeling land it does depend on where you are and who you talk to. In LA the question: who's king will get you a completely different answer...

Happy holidays

Jim

See you at ESE2008

Sorry for the long silence. After EclipseCon2008 which was great and generated a lot of attention for UI Modelling I planned to write the next blog about the publicly available metamodel.
Due to IP issues and working hard on a large Client project using StUIML, I have not been able to do just that.
It will happen though! Just a few more weeks now...
To keep you in the loop and talk about all the great possibilities of having a PIM level UI Model we could meet at ESE2008. I can show you cool stuff and tell you about the plans we have for a PMF project (Presentation Modelling Framework) at Eclipse and integration with other projects.
I am also very interested in any modelling and software factory projects you are working on.

Magnum PI

Anyone of my generation reading this title associates it with Tom Selleck. The PI that is a friend of Rick and T.C. stands for Private Investigator, but the PI in PIM I would like to blog about stands for Platform Independent.

MDA describes a transformation of models from PIM (or even CIM) to PSM to code. As StUIML is a PIM level UI Modelling language it should be platform independent. This is not as easy as it sounds, but very important. A lot of the DSL's and Software Factory approaches targeting the UI make use of elements like WebFlow or require a choice for a communication protocol.
Why is this bad? The whole meaning of the PIM level is to be able to reuse a single PIM for several technical platforms depending on the context or requirements. The advantage of using StUIML is that you can generate the models to a Web environment, a rich client desktop application, an embedded device or a character based screen without changing the PIM.

The implicit separation of aspects through the use of different modelling levels enables specialisation for each level. Just like more mature industries, we need specialisation to be able to be reliable, productive and cost efficient.

The StUIML workflow recognizes three separate tasks:

1. functional specification of the UI: specify the intentions
2. technical translation to the target platform: mapping the intentions to platform display technology
3. designing the look and feel: layout and styling

The levels are downward dependent so level 1 has no knowledge of choices made in higher levels. In future blogs I will elaborate some more on the issues we have encountered when keeping StUIML purely PI, but right now I will have to get my presentation ready for EclipseCon.

The root of all things UI

So what is that StUIML metamodel all about?
There are two main root metamodel elements in StUIML:

1. Dialogue
2. Process

A dialogue according to Merriam-Webster's dictionary is

"a conversation between two or more persons or a similar exchange between a person and something else (as a computer)"

In StUIML a Dialogue defines how information is gathered from a person or presented to a person by an application. There are a number of specialisations of Dialogue in the metamodel depending on the underlying intention, but we will dive into that later.
A Process can contain Dialogue-, Operation- and Process-calls depending on the type: an InteractiveProcess can contain Dialogues while an AutomatedProcess cannot.

Below you can see a stripped metamodel diagram of StUIML with the root elements.

StUIML is a PIM-level DSL for user interfaces. Because of this 'narrow' target domain StUIML depends on other DSL's to provide a domain model and constraints. In the past StUIML was used in combination with the following domain model languages: UML, ecore and two customer specific domain model DSL's. The UI target platforms where Swing and MFC for rich clients and JSF and ASP.Net on the web.
Just today I was asked to support a character based UI (charva) as a target platform and I see no reason why that cannot be done.

StUIML refers to the domain metamodel for references to basic OO concepts like classes, properties and associations. The domain model that is referenced from StUIML models does not have to be identical to a backend domain model. In the current SOA practice the domain model for the UI is based on the definition of service data.

All UIModelElements in StUIML have a context classifier that defines the starting point for navigation in the element. Another important property of all UIModelElements is the intention defining the goal of the element. Several types of conditions/constraints can be linked to the elements to enable dynamic behaviour.

In one of the next postings I will work out an example to show how these basic concepts can help you model UI's quickly. If you want to see live demos and coding examples come to EclipseCon2008 and visit my StUIML talk!

The StUIML principles

As my full articles are not ready yet (working around the clock on a Software Factories project for a large dutch Insurance Company), I thought it would be a good idea to reveal the basic principles that StUIML is based on:

1. The UI model should never pose requirements for the domain model


2. Reuse at the model level is key, so each UI model component should follow the 'strong cohesion, loose coupling' principle


3. The percentage of generated code should be well above 90% and preferable > 95%

The antipatterns that the principles above avoid can be seen in many UI development projects:

Allthough n-tier architecture is widely adopted it is still commonplace to add domain model features to accomodate the UI tier.

Programming logic, navigation and content inside a single screen class is another common trap, because of the RAD style of development where a single screen is the focus for developers.

If you only generate 40% or 60% of the UI, you quickly loose some of the advantages of MDSE, because of synchronisation and uncontrolled dependencies. There are too many DSL's that are only used in the first iteration. They are abandoned and the generated code is just a starting point for traditional manual labor.

Next time I will describe the key concepts (metamodel elements) in StUIML.

StUIML at EclipseCon2008

The upcoming EclipseCon2008 will show two StUIML related talks:

Intentional UI Modeling talks about the background and features of StUIML and the role of WYSIWYG in combination with DSL and code generation. The examples used are based on combining StUIML with UML domain models and generation of Java Swing.

Model-driven web applications talks about the use of StUIML in combination with Ecore and generation of Seam/JSF.

There is a lot of attention for modeling and the user interface so I am looking forward to the discussions.

Hope to see you there. As a warning: my picture on the EclipseCon2008 site is at least 15 years old. So look for a bolding middle-aged father of 4 instead...