In software engineering, transformational development aims at developing software systems by transforming a coarse-grained specification to final code through a sequence of small transformation steps. This transformational development method has followed a long tradition of establishing models and maintaining mappings between them so as to create and maintain accurate specifications of a user interface. User Interface mappings are also relevant to web engineering. We have been working not just User Interface mappings for webbased systems but as well for Information Systems in general. However, we have been confronted to the mapping problem as the use of an appropriate transformation tool it still an issue in our research group. Although several transformation engines support mappings a transformation engine capable of supporting a transformational approach for ensuring model-driven engineering of user interfaces is still an open issue. This paper provides a comparative analysis of transformation engines ranging from publicly or commercially available engines to be adapted to the mapping problem to hand-coded transformation engines that we developed for the sole purpose of supporting the mapping problem. The results of the comparison let authors to identify the type of transformation engine that fits better to their skills, needs and preferences.
Model engineering (i.e., a discipline that is concerned with the development of models) is part of the numerous solutions proposed to overcome with the increasing complexity that developers must handle to produce software. Modeldriven development (MDD) is an OMG (www.omg.org) initiative that proposes to define a set of non-proprietary standards that will specify interoperable technologies with which to realize model-driven development with automated transformations. It advocates that software development should be guided as much as possible by the construction, and refinement of software models at various levels of abstraction. Four principles underlie the OMG’s view of MDD for User Interfaces (UIs): 1. Models are expressed in a well-formed unified notation and form the cornerstone to understanding software systems for enterprise scale information systems. The semantics of the models are based on meta-models. 2. A formal underpinning for describing models in a set of meta-models facilitates meaningful integration and transformation among models, and is the basis for automation through soft-ware. 3. The building of software systems can be organized around a set of models by applying a series of transformations between models, organized into an architectural framework of layers and transformations: model-to-model transformations support any change between models while model-to-code transformation are typically associated with code production, automated or not. 4. Acceptance and adoption of this model-driven approach requires industry standards to provide openness to consumers, and foster competition among vendors
Not all model-based UI development environments or development methods
can pretend to be compliant with these principles [
In this paper the lesson learned from using graph transformation tools is
discussed. Graph Transformation engines were compared and their benefits and
constraints are presented to authors with the goal of helping in making decisions when
confronted to selecting a graph transformation tool for MDD of UIs. Our analysis
is based on three existing tools TransformiXML [
2.
Transformation engines for User Interface Development
Several research has been conducted addressing the mapping problem for
supporting MDD of UIs, UsiXML [
Our method UsiXML [
The development scenario is the following: a forward engineering path is
applied from a definition of the task and domain viewpoint to produce both an
abstract user interface (AUI) and concrete user interface (CUI). For that purpose
more than one hundred rules are applied. The transformation rules and the details
of this example are fully described for multi-modal applications in [
For instance the root task participate to opinion pool has three task children (provide personal data, answer question and send the questionnaire) so an abstract container (AC1) is created. 2. For each leaf task an abstract individual component (AIC) will be created. For instance for each leaf task, create name, create zip code, select sex, select age category, show questionnaire, select answer, send questionnaire an AIC will be created. 3. For each parent task that has children tasks, If parent task is associated to an AC (called parent AC) and child task is associated to an AC (called child AC), then, create an association relationship that will ensure the containment of the child AC into the parent AC. For instance the task participate to opinion pool associated to AC1 has two task children (provide personal data, answer question) that are respectively associated to AC11 and AC12. An association relationship is created to ensure the containment of AC11 and AC12 into AC1. 4. For each parent task that has children tasks, If parent task is associated to a parent AC and child task is associated to a child AIC, then, create an association relationship that will ensure the containment of the child AIC into the parent AC. For instance the task answer question is associated to AC12 has two children (show questionnaire, select answer that are respectively associated to AIC121 and AIC 122). An association relationship is created to ensure the containment of AIC121 and AIC122 into AC12.
AC1
AC11
AC12 AIC13 AIC111
AIC112
AIC113
AIC114
AIC121
AIC122
In this paper, the aim is to compare several transformation tools with respect
to a selected set of criteria considered of importance for MDD UIs. For this reason
we included the programming model, since it may be a premier choice for a
developer being familiar with either declarative or imperative programming [
The graphical user interface of YATE (Fig. 4) was developed using Java Swing. It is composed of a very simple UI with big text areas used to show the source (1) and target files (2); the tree containing all the implemented transformation rules (3) each with a checkbox aside allowing the decision whether or not the rule will be executeThe code to map files corresponding to Abstract Container objects is as follows: the class usixml.po.AbstractContainer is mapped in the new XML file with the name abstractContainer. Then all attributes of the class AbstractContainer are mapped into the new XML file, for each attribute the way it formatted (attribute or node) is specified. The last attribute is a list, with bindxml=element and auto-naming=deriveByClass, which means that the name of the attribute (in the new xml file) will be dynamically chosen by Castor, following the name of the class. For instance, an AioType can be an AbstractContainer, an AbstractIndividualComponent or an Input (all extend AioType), so the name of the attribute can be one of these three. There is one method per transformation rule. Consequently, the performance of the tool is affected due to constant use of objects to apply one rule at a time. Even thought, maintainability of the code is possible following this approach. The main difficulty encountered was the unavailability of a dedicated pattern matching API, therefore, searching a LHS in the UsiXML file and replacing it with the RHS is not possible. The code shown hereafter corresponds to the transformation rule defining an abstract adjacency. The rule express the adjacency between sibling tasks executed in AIOs, as they are siblings we can infer that they must be next to each other in the Final User Interface. 1 2 3
The structure of UsiXML is represented as an oriented graph in AToM³ [
In Fig. 5 (1) correspond to tasks, (2) to ACs and (3) to AICs. The left hand side (LHS) of the transformation engine corresponds to the condition to search on the graph and the right hand side (RHS) part corresponds to the transformation result. Avoiding an infinite search cycle of the condition is done by the specification of preconditions, coded in Python. At least two actions most be performed to apply a rule. First, set a post-condition to the nodes visited and mark them as visited. Second, define a precondition to check whether the node has been visited or not before applying the transformation. The designer must keep in mine these conditions and code them when necessary.
Rule 3 Relating Abstract Containers Rule 4 Relating Abstract Containers and Abstract Individual Components
Fig. 5. Rules transformation expressed in AToM³
AGG [
AGG allows the graphical expression of directed, typed and attributed graphs (for expressing specifications and rules). It has a powerful library containing notably algorithms for graph transformation, critical pair analysis, consistency checking, positive and negative application condition enforcement. Experiments showed that AGG is a rigorous environment for defining and applying rules. Unfortunately, it shows poor in terms of usability for specifying large UI models. Indeed, it may appear somewhat abstract to the designer to describe a UI appearance with a set of nodes and relationships. The main components are summed up as follows: 1. A design editor allows the creation and the consolidation of models exploited in the development process. A specific environment enables the design of UI appearance by direct manipulation of widgets. 2. A design derivator enables model to model transformations. 3. A rule editor enables the definition of new transformation rules. 4. A rule validator enables the designer to identify conflicts within a set of rules.
The critical pair analysis technique is used for this purpose. 5. A design analyzer enables the verification of desirable properties of the manipulated artifacts such as basic consistency rules, type checking or even usability properties (i.e., IFIP properties like reachability, browsability). Rule 1 Creating abstract Containers
Rule 2 Creating Abstract Individual Components Rule 3 Relating Abstract Containers
Rule 4 Rsterlaactitn Ign dAibvsidtruaaclt C Coomntpaoinneenrst sa nd Ab‐
TransformiXML [
In this section a comparative analysis to transformation engines is presented. This information can be relevant to HCI community while trying to tackle the mapping problem for UI development. The selected criteria, summarized in Table 2, were chosen considering the key factors that are relevant for: (1) implementing of a transformation engine (implementation paradigm and required programming skills, code generation support, pattern matching API), (2) usability (rules organization, rules scheduling organization) and further use of the transformation engines (maintainability and flexibility and completeness). The description of each criterion is as follows: • Implementation paradigm and required programming skills. First major difference between the transformation engines is whether they are imperative or declarative. Like all graph transformation tools, AToM³ and AGG are strictly declarative while YATE and TransformiXML are imperative. Performance is a very important criteria and AToM³ posses a major disadvantage on this aspect. As AToM³ is entirely coded in Python and compiled at execution the execution is slower compared to precompiled Java code, YATE, AGG and TransformiXML. Moreover, the fact that the transformations are graphically designed means that the user does not have the possibility to optimize how they are executed, the engine is in charge of that. YATE and TransformiXML are fasters during execution. Not only because the compiled code is faster that the interpreted code of AToM³ but also the programmer chooses exactly how the transformation will be executed. Redundancy can be eliminated as well by grouping transformation rules. While AToM³ needs programming skills, as there are a few things to code in Python, like conditions, actions, constraints and variables’ valuing, AGG requires programming skills to specify conditions on attributes. However most of the transformation are described graphically in AGG and AToM³, consequently they are more flexible because even GUI designers with (almost) no programming skills can use them, and also because maintaining the rules is simpler. Nevertheless, in AGG and AToM³, the transformation rules are specified for the meta-model that we have graphically created and a change to this meta-model will make the transformations not work anymore. • The model-to-model approach. TransformiXML, AGG and AToM³ use graph transformations. The models are created graphically and so are the transformation rules. This is a very intuitive and easy to read and maintain. YATE uses another approach. Instead of transforming the model into a graph, it directly modifies it. In fact, the XML file is read and transformed into Java objects. These objects are then modified by the transformation rules and finally the Java objects are translated back into XML. In YATE, a method is created for each transformation rule. Comparing with the graphs the code is harder to read and maintain. • Code Generation. In YATE, code generation is feasible; the Castor API supports this process. On the contrary, AGG and AToM³ code generation is possible but it is poorly developed. To generate XML code for a model in AToM³, we should use transformation rules, with the “action” code writing XML code to a text file. This would be long and fastidious, if possible. • Pattern matching. This is a big difference among all the tools. While pattern matching is supported by TransformiXML, AGG and AToM³, YATE does not support it for the moment. Pattern matching is still usable in YATE, but with the help of external projects or at the price of a long a fastidious implementation. This is more complex to implement than in TransformiXML, AGG and AToM³. • Rules scheduling and organization. AGG and AToM³ only allow determining a fixed order on the rules. There is no possibility of explicit flow control on them. And there is not a “call” instruction for a rule to call another. In fact, preconditions serve to decide whether or not the rule will be executed. In AToM³ it is possible to create distinct set of rules and execute one after another. However, there is no rule inheritance mechanism and import mechanism either. Therefore rule sets can not import a rule from another set and a rule can neither use another. Finally, TransformiXML and YATE, allow rules organization (for example one class for each rules set), and the flow control is of course explicit. In YATE it is possible even to call a rule in another, because each rule is a method in Java. • Flexibility and maintainability. The more readable the models the easiest to maintain them. AGG, AToM³ and TransformiXML offer a best capacity to modify and maintain meta-models, models and transformation rules. However, when modifying rules at least two issues must be taken into account: 1) if a meta-model is modified then transformation rules designed for that meta-model are potentially not working anymore (because they can apply on objects removed or modified); 2) modifying rules is sometimes difficult, for instance in AToM³ modifications on rules leads to unexpected behavior. Finally, because of its fully programmatic approach and more complex syntax, YATE is the most difficult to maintain and modify, as it implies several modification in several classes in addition to coding the transformation rules. So, flexibility is worse than for the two other three tools. • Completeness refers to the ability of the system to handle complex rules and generate code. As AToM³ allows programming in Python, it is able of executing more complex rules than strict graph-transformation rules (with only NAC, LHS and RHS). Still, the lack of explicit flow control and the absence of imperative constructs limit it. Because the source and target model are not distinct, they both obviously can be navigated and modified. Finally, the lack of code generation makes AToM³ less complete. Finally, in YATE the limit is in fact the programming skills of the graphical interface designer.
Finally, Fig. 8 shows variations between completeness/performance and maintainability/flexibility. While it is known that robust and complete software is desired, this is difficult to achieve. HCI is a discipline particular with constant changes so it can be said that incompleteness is intrinsic to HCI. However completeness on existing needs is still relevant and for UI development it seems that TransformiXML and YATE are more complete than AGG and ATOM3. On the other hand, the lack of maintainability and flexibility contrast with the other tools. Authors have to choose the equilibrium that fits better their particular needs.
In this paper, we introduced a comparison of transformation engines to support UI development. Four tools were compared, including two developed in our lab, using a common case study. From our evaluation we noticed that it is difficult to find the perfect balance with the criteria. In particular, one of the goals of model-driven development of UIs is to support UI run-time adaptation based on transformation rules. Therefore, the performance is of concern. We conclude our report with a comparative analysis that could help authors to make the decision of the appropriate transformation engine to be used while confronting model-driven engineering of UIs. In this area, we can conclude that a systematic method is recommended to drive the development life cycle to guarantee some form of quality of the resulting software system. Not all of these technologies will directly concern the transformation involved in MDA. MDA does not necessarily rely on the UML, but, as a specialized kind of MDD (Model Driven Development), MDA necessarily involves the use of model(s) in development, which entails that at least one modeling language must be used. Any modeling language used in MDA must be described in terms of the MOF language to enable the metadata to be understood in a standard manner, which is a precondition for any activity to perform automated transformation.
Acknowledgments We gratefully thank the support from the SIMILAR network of excellence, supported by the 6th Framework Program of the European Commission, under contract FP6IST1-2003-507609 (http://www.similar.cc), the Alban program (www. programalban.org) supported by European Commission, and the CONACYT (www.conacyt.mx) program supported by the Mexican government. All information regarding UsiXML is accessible through http://www.usixml.org.