While model based design of platform independent application logic has already shown significant success, the design of platform independent user interfaces still needs further investigation. Nowadays, user interface design is usually platform specific or based on C-level cross-platform libraries. In this paper, we propose a MDA like design approach for user interfaces based on the transformation of UML models at different levels of abstraction. This enables platform independent design of user interfaces and a clear separation of UI and application logic design while enabling full use of native controls in the actual user interface implementation.
Providing individual User Interface (UI)
implementations for each target platform of a
contemporary application becomes an increasing
burden as the number platforms as well as the size of
the applications increases. In the context of
modelbased design methods and the UML [
Model Driven Architecture (MDA) [
Furthermore, lack of abstraction in UI design forces large parts of the UI implementation into the responsibility of the software engineer rather than enabling the UI designer to work concurrently. A clear separation of UI and application logic design is desirable to improve both productivity and software quality.
The remainder of this paper is organized as follows: The next section discusses related work before Section 3 introduces our approach. Finally, Section 4 closes with a conclusion and future work. 2.
UI design has been subject to research for quite some time now. However, model based methods are discussed mainly in the context of XML.
The User Interface Markup Language (UIML) [
The USer interface eXtensible Markup Language
(USIXML) [
Finally, [
Our approach is driven by the idea to allow for a complete separation of the UI and application logic design. As in MDA, our approach starts with the creation of a platform independent model. Before generating a platform specific UI implementation, the designer can configure the UI on multiple levels of PIMs, each independent of a target platform. From the most detailed PIM we can generate a platform specific UI implementation (see Figure 1). Transformation rules between the different models facilitate tool support for our UI development approach.
Our basic PIM is the Information Model (IM). This class diagram provides an abstract definition of the information and their logical dependencies. The goal is to develop a UI for presenting this information. It is undistorted by technology information. Therefore, it allows business experts to ascertain much better than with a platform specific model and it provides an early starting point for user interface design.
Figure 2 shows the IM of an administration interface of a simple Web server. The Web Server may have a ContentHandler at a certain Port to which a Connection can be made by a User to access the content of a Folder if he has the necessary Permissions according to his Group memberships. Furthermore, the pending Requests and Responses are represented.
ContentHandler
Port * «editable» * + «creatable» Number: Integer + «creatable» UseSSL: Boolean «deletable» *
InternetAddress 1 + Hostname: String
+ IPAddress: Integer [1..4] {ordered}
The associations and attributes in the IM are marked to indicate different kinds of data. Generally, the stereotypes <<readonly>> and <<editable>> mark associations and attributes as only displayable or editable. Attributes marked <<editable>> may have their values altered at runtime while such associations may have links added and removed. If an association is marked as <<deletable>>, links may only be removed in contrast to attributes, which may instead be marked as <<creatable>> indicating that their value may only be by the constructor, i.e., when creating a new instance. If no stereotype is provided for an attribute or association, <<readonly>> is assumed.
P ltf a o
D e p e
M(PodMe)l tn
P lft a o
I n
Abstract User Interface Model (AUIM) UI Elements pe e
Transformation Rules (AUIEM) den t
Connection 1 * * 0..1 * «editable» «root» Server
* «editable»
User + «editable» Login: String + «editable» Name: String = "" + «editable» Password: String «editable» * + «editable» Description: String = "" *
Folder + «editable» URI: String + «editable» BasePath: String
* «editable» «editable» * * «editable» * «editable»
*
Group + «editable» Name: String
Permissions + «editable» Read: Boolean = false + «editable» Write: Boolean = false + «editable» List: Boolean = false + «editable» Execute: Boolean = false +type 1 +type 1
The data types used by the attributes in the IM are fixed and range from primitive types (e.g. Integer, Float) to complex types defined by classes. Operations may define interface application logic that cannot be captured by the data model, e.g., to send explicit messages to the application aside from persistent data.
The whole IM is a composition tree starting by a <<root>> class whose only instance represents the whole systems. This enables inference of aggregations to automatically generate all levels of abstraction from the IM without the need for user interaction. However, usually this is not desirable and the UI designer wants to provide these decisions manually at each level of abstraction.
The PIM at the next level is the Abstract User Interface Model (AUIM). It includes some aspects of UI technology event though platform-specific details are absent. Essentially, the AUIM combines the data from the IM with abstract UI elements to access and manipulate that data. We have developed a metamodel –Abstract User Interface Elements Model (AUIEM)– that defines different UI elements at an abstract level in terms of related data sets and triggers. This metamodel can be extended to project-specific needs by using the UML profiling mechanism.
Figure 3 shows an excerpt from the AUIEM employed in our example. This excerpt defines the Choice UIElement for selecting one Item from a Set. Furthermore, it provides the necessary elements to employ the Choice to select an Instance of a Class or a Link from a Property.
These elements are used in a set of graph
transformation rules [
The application order of rules is not determined. Furthermore, different rules with the same left-hand side may exist to provide alternative UI elements for the same structure. The actual choice of the desired mappings is an interactive design decision that can be supported by tools. However, complete generation of the AUIM based on the rules is possible. This could be interesting in the context of an UI style defining the actual mappings to be applied.
L
<t> :Type +type :Class
<P> :Property +memberEnd :Extension
:Association +memberEnd :ExtensionEnd :Property «UIElement» :AddLinkTrigger «UIElement»
:Choice R <P> :Property +target «UIElement»
:Item +chosen «UIElement»
:Choice +choices
«UIElement» :FilteredInstances +class
<t> :Type +type «UIElement» :FilteredLinks +choices +chosen «UIElement»
:Item +Link «UIElement» :KillLinkTrigger :Stereotype name = "editable" <C> :Class
<C> :Class The most detailed PIM is the View Composition Model (VCM). It partitions the AUIM into several overlapping and navigable views. Each of these views provides the scope of a class instance for the contained UIElements. Thus, master-detail-like views can be implemented. Furthermore, navigation along Links can be defined. Finally, views can be composed. Each contained view either inherits the scope from the containing view or has the scope provided by links selected in the containing view. One root view must be defined. Views enable the purposeful selection of different platform UI elements for the same UIElement depending on the overall context of a view while deriving the Concrete User Interface Model (CUIM) representing the actual platform dependent user interface.
The CUIM is defined by the Platform Model (PM), which contains a set of available native UI elements on the target platform. Like in the AUIEM, these elements are combined with the elements form the Information Metamodel. Thus, the translation between these models is based on the substitution of the UIElements from the AUIEM by native UI elements from the PM.
The creation of the CUIM not only involves mapping the UIElements to actual UI controls (widgets) on the target platform, but also providing additional layout and decoration. A GUI builder tool should support the whole task where the designer may handpick individual mappings for UIElements. Transformation rules similar to the rules for the IMAUIM transformation can be employed here. These rules map UIElements and their context to attributed and annotated instances of platform specific UI classes.
The resulting CUIM has to be complemented by the Information Retrieval Model (IRM) describing how the data processed by the UI is actually accessed. The IRM is a behavioral UML model (e.g. an activity diagram) giving an operational description how to retrieve the IM elements from the actual implementation. Thus, the IRM functions as an abstraction layer between the UI and the application similar to database abstraction layers. However, the actual implementation of the IRM may vary and is not discussed here.
To create the code for an Actual User Interface Implementation, complete code generation takes place combining the IRM and CUIM information to a working platform dependent UI. Again, we use a set of graph transformation rules for the transformation.
Conclusion and Future Work
In this paper, we have proposed a model-driven design approach for user interfaces based on the UML. This approach allows concurrent development of UI and application logic by starting from a common platform independent information model. Furthermore, due to our code generation mechanisms we can support different target platforms from the same abstract model. The approach has been outlined and discussed in the context of an interface of a Web.server.
We are currently implementing the results of the
manual execution of our approach for this example.
Future work will include a prototype implementation in
the context of our work in the fields of executable
models [