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!