There are two main root metamodel elements in StUIML:
- Dialogue
- 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.
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!
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!
No comments:
Post a Comment