2 MODEL DRIVEN SOFTWARE ENGINEERING
2.3 Transformation Approaches
2.3.4 Transformation Modularization
In the same manner as in traditional software engineering software artifacts such as classes and libraries are composed, reused and adapted, it is important that in model driven engi- neering transformations can also easily be composed, reused and adapted. Transformation modularization into smaller units is an important prerequisite for reuse and helps reducing the complexity of transformations. Based on [Kurtev06a] the basic concepts for transfor- mation modularization are presented. Additionally, a simple transformation metamodel is presented.
Modularization of the metamodel often affects the modularization of the transformation definitions. In general, transformations should be modularized in a way so that tangling and scattering of transformation functionality is minimized. This is not always possible in the case of crosscutting concerns, thus the application of aspect-oriented techniques to the model transformation domain would be interesting. As a general rule transformations should be decomposed along the dimensions of concern by means of the modularization features of a transformation language.
Figure 10 depicts the metamodel for modeling transformation modularization as a profile- able extension of the UML metamodel, cf. 2.2.4. Thus, a UML model with a default profile mapping can be used for modeling transformation modularization. All derived properties in the metamodel are derived from their corresponding “intuitive” properties in the UML metamodel. A further formalization is not given here. The upper part comprises the generic concepts that are independent of the specific transformation language. A transformation is a package that contains a set of rules. The basic concepts for transformation modularization are (1) inheritance, i.e. a rule can inherit functionality from its super rule; and rule calls
6 Homepage for Ant: http://ant.apache.org/
Model Driven Software Engineering for Web Applications
which are specialized to (2) implicit rule calls, i.e. rule calls without explicit references to rule names in declarative approaches; and (3) explicit rule calls in imperative approaches. In hybrid approaches such as QVT and ATL both rule call types are possible. The figure also comprises a specialization for the rule types of ATL as presented in 2.3.3.1. The spe- cialized rules of ATL imply constraints on the possible rule calls: a matched rule is always called implicitly from another matched rule and a called rule is always called explicitly from any rule. Because of these constraints the dependency stereotype may be omitted in a transformation modularization diagram.
ATL MatchedRule LazyRule CalledRule EntrypointRule ExitpointRule Transformation ImplicitRuleCall ExplicitRuleCall Dependency RuleCall Package Rule Class * +/caller 1 * +/called 1 +/rules * +/superRule 0..1
Figure 10. Transformation metamodel
2.3.5 Discussion
From the experiences gained during this work a purely declarative transformation approach such as purely relational or purely graph-based transformations is not practical for real-life transformations. A hybrid approach allows to use imperative constructs for transformation tasks which would be too cumbersome or even impossible to express with declarative con- structs. Nevertheless, the declarative constructs of a hybrid approach should be used as far as possible. Thus, the hybrid approaches QVT and ATL and the hybrid graph- transformation based approach VIATRA are best suited for real-life transformation appli-
cations. The former two approaches fit better in the OMG meta architecture as presented in 2.2 with only ATL providing appropriate tool support at the time of writing. VIATRA on the other hand would be best suited for more formal applications due to being based on graph transformations, but unfortunately appropriate tool support was not available at the time of writing. Now, with the latest version from October 2006 increased interoperability between MOF and the internal model representation of VIATRA is available, but still the practical applicability would have to be investigated.
Another important aspect when deciding between transformation languages are the inter- operability options between them. Interoperability between ATL and QVT is discussed in [Jouault06a]: QVT transformations can be mapped (by a transformation) to the ATL Vir- tual Machine, thus QVT transformations can be run in the ATL runtime environment. In- versely, ATL transformations can be mapped (again by a transformation) to QVT opera- tional mappings transformations. On the other hand the research group behind VIATRA proclaims that QVT transformations can be transformed to Abstract State Machine (ASM) and Graph Transformation (GT) rules [VIATRA].
The conclusion is visualized in Figure 11: ATL has the highest interoperability, transfor- mations can be mapped to QVT operational mapping and transitively to VIATRA. QVT transformations can be mapped to VIATRA, but only to the low level ATL Virtual Ma- chine, meaning that QVT transformations can be run on the ATL Virtual Machine, but the transformation specification itself gets lost. VIATRA transformations in general cannot be mapped to QVT or ATL.
Thus, when specific features of QVT are not needed, such as that QVT is a OMG standard or that QVT provides relations together with a visual notation, ATL can as well be used. Additionally, at the time of writing, ATL has the benefit of a stable implementation. Both QVT and ATL can take advantage of the interoperability with VIATRA, which is based on the long established theories on graph transformations, and thus provides a better formal foundation, e.g. for proving the correctness of transformations.
A recent development is the foundation of the Eclipse Model-to-Model Transformations (M2M) project [M2M]. The objective of this project is to provide a framework for model- to-model transformation languages. The core part will provide an infrastructure for plug- ging in transformation engines. The first transformation engine available under the M2M project is the ATL transformation engine. An implementation of a transformation engine supporting QVT will follow shortly. Another main objective of the M2M project is to pro- vide bridges between transformation languages, i.e. a transformation written in one trans- formation language could be transformed into a transformation in another language. Thus,
Model Driven Software Engineering for Web Applications
the ATL transformations presented in this work could easily be migrated to QVT transfor- mations, as soon as the corresponding bridging tools are available.
QVT
ATL
VIATRA/GT
full interoperability runtime interoperabilityQVT
ATL
VIATRA/GT
full interoperability runtime interoperabilityFigure 11. Interoperability between transformation approaches