Saturday, March 15, 2008

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.

2 comments:

Unknown said...

Hi,

I went through this process 3 years ago, developing a set of Stereotypes on Entities and Associations and Tagged values for Attributes to fully generate a Plexus Summit based UI (this uses Velocity templates for the HTML, which I also generated) to JPOX backend. Because Plexus is such a great lightweight component framework generating the configuration was relatively easy.

This is in dentaku.codehaus.org in CVS. Unfortunately no one really 'got' what Bill Topping and I were doing, so the project has been dormant for 2 years. We used Netbeans MDR, which was challenging to say the least, we always had to write helper classes to bridge the gap between what the MDR contained and what the Velocity templates required to be able to generate.

Anyway I was interested in what you are doing, but see no links to a definition of StUIML, is there anything concrete?

David

Unknown said...

Hello David,

Yes, we have a fully functional modeling environment and generate to different platforms based on StUIML. We need to clear IP issues and get company approval before we can contribute the metamodel and examples however.

I recognize the problems you mention as I had a preliminary version using MDR. We actually had a properietary toolset back in 1995 containing a predecessor of StUIML. Currently we use the Eclipse toolset including OAW. These frameworks save me a lot of time.

I was very encouraged by the number of requests and interested parties for StUIML concepts at EclipseCon. I have been quiet on the blog after EclipseCon, but we expect to give more details this summer.