Open Issues addressed by UCL
This document presents the Open Issues that have been assigned to UCL.
1. Should UIML include the definition of transforms in the specification?
No for the moment, but yes if UIML is willing to be compliant with MDA.
Beyond modeling techniques as defined in Unified Modeling Language (UML), the Object Management Group (OMG) takes a next step to Model Driven Architecture (MDA), a new system development approach that will guide system designers to face the continuous change in system development. The main concept of MDA is about how to use the models efficiently. To develop a system according to the MDA principles, we have to design first a system in a platform independent way. Then model transformation techniques could be used to refine the design by adding details specific to the platform of your choice. The last transformation step can produce the system codes for you. Therefore, model transformation allows the same model expressing business logic to be realized in multiple platforms with the maximum automation. The development life cycle of the user interface (UI) does not escape from this problem. Therefore, there could be a need to define a UI Transformation Language (UITL) that performs logically defined transformations on a UI model in order to obtain a refined UI model, another model, or final code. The UI transformations are then specified based on the UITL.
Including the UI transformation definitions in UIML has the following consequences:
- Advantages
o If the UITL is part of the UIML language, it is no longer needed to implement interfaces between UIML and the UITL (e.g., through a style sheet if both languages are XML-compliant). In this way, a transformation should not be reformulated before applying it.
o The objects on which a transformation is defined in the UITL could be directly referenced in the transformation definition. If a transformation involves a particular object, say a widget, the definition of this transformation is simplified because it could simply refer to this widget without any external reference or conversion.
o Embarking the transformations in a UIML file could be particularly useful for all those cases where a run-time UI is desired, equipped with its own transformation mechanism. For example, context-aware adaptation is a case where context-aware adaptation rules could be expressed as transformations embarked in the file so as to process them when needed. As a consequence, it is also imaginable to modify transformation rules dynamically.
o A transformation could be defined thanks to a selector mechanism. A Selector consists of a definition of the types of UIML elements to which the transformation applies, and a series of property declarations that define the transformation. Three major types of selector could be considered:
§ Universal Selector: applies the transformation to all elements belonging to the UIML file.
§ Element Type Selector: applies the transformation to all elements belonging to the UIML which correspond to the selector’s type (e.g., all windows, all list boxes).
§ Class Selector: applies the transformation to all elements belonging to the UIML which correspond to the selector’s type whose definition makes them part of the class (e.g., all windows having an id greater or equal to W7, all list boxes having more than 10 items).
- Shortcomings
o The UITL is tied up to the source language, UIML in this case. Therefore, it is difficult, if not possible, to change the definition of the UITL. This decision could be decisive as many formats exist for expressing a transformation. Of course, the OMG recommends the Query-View-Transformation (QVT) expression, whose definition has recently become officially definitive. Several QVT implementations exist, all of them with only partial support of QVT. Some other implementations are even non-compliant with QVT.
o Moreover, it forces any rendering engine to work with a particular transformation technique. For instance, in UsiXML, transformations could be embedded in a UsiXML file, but forces the rendering engine to interpret these transformations through graph grammars techniques because each transformation is actually a graph transformation. If another technique should to be used (e.g., a template-based approach or generative programming), the transformation should be expressed in another way.
o The size of the UI specifications is increasing: when the transformations are embarked within the UIML file, the size of this file inevitably increases, thus increasing the system response time.
o The principle of separation of concerns, as defined by Dijkstra, is more difficult to achieve without introducing a lot of references in the resulting file.
o The implementation of a transformation engine remains a challenging task. Similarly, discovering a reasonably-scaled set of transformations for each class of problems encountered in UI development life cycle remains an open research problem.
Proposed Solution
As it is formulated today, UIML does not really need any UITL, embedded or not. But if UIML is intended to address more complex problems like context-aware adaptation or if UIML is willing to become compliant to some extent with OMG recommendations (which may be important for standardization reasons), then a UITL could become recommended. If UIML is also evolving towards MDA approach for all involved models, and not only the UI model, then the inclusion of a UITL is inevitable. The question of being embedded or not does not make many difference.
If such a goal becomes relevant, the following steps should be conducted for a solution. Since a model transformation consists in writing transformation rules and applying them, transformation rules need specifying the mappings between concepts of the source metamodel (source language) and those of the target metamodel. Since the transformations rules are defined in the metamodel level, they are applicable to any source model that is conforming to the source metamodel.
In the case of model-to-model transformation, source and target languages should remain the same, thus in favor of embedding the transformations in the UIML file. In the case of model-to-code transformation, source and target languages are different. In this case, it is preferable to solve the problem through a definition of vocabularies.
Once the transformation rules for a particular transformation (e.g., a task model to a UI model), the transformation engine is of applying the rules to a source model and produce the corresponding target model.
In the architecture of a typical transformation engine, to use the transformation service, a designer needs to supply the transformation rules written in the UITL, the source metamodel, the source model, and the target metamodel. Each transformation then uses these files to construct the repositories that store transformation rules, source model, and target model. Guided by the supplied rules, the core engine read the source model and creates the corresponding target model. Finally, the transformation service exports the target model to the user in XMI format.
Affected Sections of the Specification
In principle, no existing section of UIML should be affected since the introduction of a UITL is more a matter of adding new tags representing a transformation. The UITL should remain as much autonomous as possible from the transformation technique.
2. Should UIML include Data Models?
Not as a full model. First of all, we make a distinction between a data model (which consists of a data structure) and a domain model (which consists of a conceptual model of data with relationships, like a UML class diagram or an entity-relationship model).
Including a data or a domain model in UIML has the following consequences:
- Advantages
o It better supports the OMG principles that define the MDA as the data/domain model is clearly isolated from the rest of the specifications contained in the other models. In the same vein, this model could be at the same level as the layout, style, structure definitions found in UIML.
o It clearly reduces redundancy: if a data needs to be modeled, it should belong to the data/domain model, not to the UI model. However, including a reference to the domain model is neater and preserves the separations of concerns. It avoids repeating things at the UI level that should normally be specified in a data/domain model. For instance, the profile of an alphanumeric entry is certainly important for the UI to be implemented in an edit box, but this could change according to the data being input or output in this box. If some aspects are specified both in the UI model and in the data/domain model, it becomes more difficult to maintain the consistency between them and to propagate changes from one model to another.
o The data could be vehiculated with a particular UI, which is particularly useful for supporting migrating UIs, distributed UIs, and run-time adaptive UIs.
o The relationships (e.g., inheritance, aggregation, composition, materialization) contained in the domain model, if any, could be exploited to improve the quality of resulting models based on these relationships, as well as design options or model transformations. Without these relationships, less design options are available or poor quality results could be obtained.
o Having a data/domain model is particularly appropriate in the case of reverse engineering. Several researches have addressed the problem of data/domain model reverse engineering or user interface reverse engineering, but not that much which combines both at the same time.
- Disadvantages
o It is not the main purpose of a User Interface Description Language like UIML to include a data/domain model, but the experience shows that specifying some data in a UI model is really a must. On the one hand, only some simple data could be captured and modeled. On the other hand, a complete model could be established, thus complexifying the model management. Instead of simply incorporating data when and where it is needed, references to the data/domain model should be added. It is a permanent choice between independence (thus requiring correlability between models) and combination (thus requiring integrability).
o It introduces yet another model to manage, which may be not desirable if one wants to avoid the proliferation of models. In addition, it requires a precise definition of data types and structures which could be manipulated during the development life cycle. Or even more precise aspects, like the profile of an edit box.
o The reverse engineering of a data/domain model is a complex problem to solve.
Proposed Solution
As it is formulated today, UIML does not really need any data model, unless it is intended to be compliant with the MDA approach or is dealing with data-intensive interfaces. At first glance, a simple tag describing the contents of a widget could be added. If the needs evolve towards a true model, such a model could then be defined later on. But for the moment, we do not see the need.
Affected Sections of the Specification
If a contents definition is decided, it will affect all widgets for which contents could be specified. A contents definition could be similar to:
<widget>
</ normal definition-->
<contents>
<data type=”alphanumeric” profile=”[0-9]*A*”/>
<default value=”1QWERTY”>
<current value=””>
</contents>
…
</widget>
3. Should the UIML Specification Support Optional Template Elements?
Yes. A template could be defined as a set of predefined attributes whose value is assigned at design time. A template could be seen as a shortcut for repeating several assignments at the same time (e.g., repeating the same presentation attributes for whole or parts of a user interface).
A template is intrinsically reusable: once defined, it may be reused at any time in principle. In addition, this mechanism supports evolution of systems as a template could give rise to many other templates which could be considered as generalizations or specialization of a source template.
The definition of a template mechanism is particularly straightforward in UIML since all attributes are clearly separated in the four main sections, such as style, structure, layout. Building a library of templates is a task that is inevitably related to the introduction of templates. But one should take care of not introducing too many templates with only little variations from one template to another, which may induce designers in confusion on what template to apply.
Proposed Solution
The following UML class diagram represents the meta-model of a possible template mechanism. The Template Class is subclassed into several sub-types depicting particular types of templates that could be applied separately and independently of each other, thus ensuring some modularity and flexibility. A template may be declared context-dependent if its application is peculiar to a particular context of use, where the context of use is here referred to as a triple composed of a user, a computing platform, and an environment.
A template parameter consists of any UIML attributes that may be subject to an assignment prior to development. A template parameter is characterized by an id, a name, a definition, a data type, and a template value. Each template may have one to many selectors, such as:
- universalSelector: applies the template to all elements belonging to the UIML.
- elementTypeSelector: applies the template to all elements belonging to the UIML which correspond to the selector’s type (e.g., all containers, all list boxes).
- classSelector: applies the template to all elements belonging to the UIML which corresponds to the selector’s type whose definition makes them part of the class (e.g., all containers having an id greater or equal to CC2, all list boxes having more than 15 items).
- idSelector: applies the template to only one element belonging to the UIML: the one whose id attribute matches the string contained in the parameter.
Affected Sections of the Specification
In principle, all UIML sections containing attributes whose value may be pre-assigned are subject to a template. A template could govern an entire UI or a portion of it. Several templates could be used for multiple parts and be based on an inheritance mechanism. If a local template is specified for a UIML fragment, then it overwrites the values assigned by a global template if any.