Tuesday, December 23, 2008
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...
Thursday, October 30, 2008
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.
Saturday, March 15, 2008
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:
- functional specification of the UI: specify the intentions
- technical translation to the target platform: mapping the intentions to platform display technology
- designing the look and feel: layout and styling
Wednesday, March 5, 2008
There are two main root metamodel elements in StUIML:
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)"
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.
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!
Sunday, February 17, 2008
- The UI model should never pose requirements for the domain model
- Reuse at the model level is key, so each UI model component should follow the 'strong cohesion, loose coupling' principle
- 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.
Thursday, February 14, 2008
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...