A Comparative Analysis of Transformation

1
A Comparative Analysis of Transformation Engines
for User Interface Development
Jean-Pierre Delacre Université catholique de
Louvain (UCL)
2
Objective and Methodology

• The objective is to compare tools used to create
  transformation rules for the development of user
  interface.
• The methodology is decomposed into the following
  steps
• 1) Selection of a User Interface Description
  Language
• We chose UsiXML as meta-model
• 2) Selection of User Interface Development Method
• Cameleon reference framework
• 3) Selection of case study
• A simple example Currency convertor
  (http//www.xe.com/ucc/)
• Virtual Polling System
• 4) Selection of transformation rules
• 5) Selection of the tools and execution of the
  rules in the tools

3
Step 1 Selection of the UIDL

• Many different UIDLs exist XUL, UIML, XIML,
  UsiXML, XAML,
• We chosed UsiXML as meta-model because
• Based on a transformational approach
• Underlying graph-based syntax
• MDA-compliant
• Not a software vendor product accessibility

4
Step 2 Selection of the UI Development Method

• Our development method was according to the
  Cameleon framework
• Because this framework has now gained consensus
• Tasks and domain are expressed in the source
  (UsiXML) model
• Abstract User Interface is derived from the tasks
  and domain
• Concrete User Interface is then derived
• Code generation was not taken into consideration
  here (out of scope)

5
Steps 3-5 Selection of the transformation rules
and tools

• The rules set we used is the same in each tool
• From Task and Domain Models to AUI Model
• 19 transformation rules (13 in Java)
• From AUI Model to CUI Model
• 17 transformation rules (11 in Java)
• Three tools, representative of three different
  approaches, are compared
• Graphical approach AToM³
• Programmatic approach java
• Hybrid approach (graphical OCL) ATL

6
AToM³

• Graphical syntax
• Meta-model as a UML diagram but with some
  restrictions no composition relation.
• Graph grammar for transformation rules
• Rule composed of a LHS and a RHS graphically
  designed (UML-like) but
• No NAC, the precondition is here implemented as a
  Python algorithm
• No distinction between source and target model
• The model is graphically designed and
• The model is directly modified by the
  transformation rules

7
Virtual polling system model in AToM³
8
Virtual Polling system after execution of
transformation rules by AToM³
9
AToM³ (4)

• AToM³ is easy to use and understand but
• Complex and difficult-to-read graphs can result
  from even quite small models
• Despite simplicity, it is quite long to implement
  the rules
• Learning to use AToM³ is very fast, but
• the implementation itself is quite long
• Meta-model and rules took us about 3 months to
  implement, but with no skills in transformation
  rules in general.

10
ATL

• We have not implemented the rules in ATL
• The meta-model is designed either graphically,
  using UML-like diagram, or programmatically
• Rules are coded using a syntax inspired by OCL
• Two programming styles
• Declarative rules, with optional imperative block
  (implicit flow control)
• Imperative rules (explicit flow control)
• Source and target models are distinct, with
  restrictions
• Source model can only be navigated
• Target model can neither be modified nor navigated

11
Java

• Transformation engine entirely coded using java
• External projects like JMI exist to help
  programmer create a transformation engine, but we
  did not use them
• Also, external projects exist to help use pattern
  matching, but we did not use them either rules
  are thus coded in Java, and it is not possible to
  use UsiXML rules with our java transformation
  engine
• Takes a UsiXML file as input, returns the
  resulting UsiXML file as output

12
Java transformation engine architecture
13
Java transformation engine architecture (2)

• Transformation rules are implemented in the
  Rules class
• Functions to help implementing the rules in the
  RulesHelpers class
• RulesTree class contains a list of the rules,
  showed in the GUI
• A Main class to
• Transform the UsiXML file into java objects
• Call the transformation rules selected by the
  user
• A graphical user interface to
• Open the source UsiXML file
• Choose the transformation rules to execute
• Show the resulting model and save it in a UsiXML
  file

14
Java (4)

• The source UsiXML file is read using the Castor
  project
• A mapping (XML) file contains the rules to map a
  file to Java objects
• Using this mapping file, the application
  transforms the UsiXML file into Java objects
• (Thanks to the structure of UsiXML, a UsiXML file
  can be transformed into one Java object UiModel)
• The transformation rules are applied on the Java
  objects
• One (or two) method(s) per transformation rule
• Source model (Java objects) directly modified
• The Java objects are transformed back into a
  UsiXML file
• Using the same mapping file as for reading, the
  application transforms the Java objects into a
  UsiXML file

15
Java sequence diagram
16
Java (6)

• Transformation engine in java complex to
  implement and maintain
• Took us 3 man-months to implement
• About 2800 lines of Java code
• Modifying the application (modify rules, add
  rules, ) was also very long and complex
• Three classes to modify main, rules and
  rulesTree
• The rules have to be coded in Java

17
Comparison tables
18
Comparison tables (2)
19
Summary of tools avantages and disadvantages (1)

• AToM³
• Easiest tool to use
• Maintainability of model within this tools is
  easy because of its simplicity
• - Only implicit flow control
• - Complex rules cannot be executed in AToM³
• - Does not support code generation

20
Summary of tools avantages and disadvantages (2)

• ATL
• - Slighlty more complex than AToM³
• - Provides a framework for more complex rules
• Provides imperative constructs
• Supports code generation via external model
  handlers

21
Summary of tools avantages and disadvantages (3)

• Java
• - Much more complex than the two others
• - Maintainability is difficult and
• - Strong programming skills are required
• Complex rules can be executed,
• The designer has total control on the execution
  on the rules
• UsiXML files are directly modified.

22
Conclusion

• AToM³ is certainly by far the simplest and
  easiest solution for model-to-model
  transformation, and it is also the most flexible.
  
• ATL is slightly harder to use than AToM³, because
  it requires higher programming skills. But ATL is
  more powerful than AToM³
• ATL allows implicit or explicit scheduling.
  Explicit scheduling is possible in ATL because of
  its rules inheritance support, which AToM³
  doesnt have.
• ATL supports both declarative and imperative
  programming
• ATL supports code generation via external model
  handlers
• Java is certainly the hardest solution to
  implement, but is also offers the widest
  possibilities of the three tools we used

23
Conclusion (2)

• The numbers of the Y-axis have no specific
  value, they are there only to give an measure
  order
• X-Axis is both performance/completeness (in
  blue) and maintainability/flexibility (in red)

24
Thank you very much for your attention
http//www.usixml.org User Interface eXtensible
Markup Language
http//www.similar.cc European network on
Multimodal UIs
For more information and downloading,http//www.i
sys.ucl.ac.be/bchi
Special thanks to all members of the team!