Transformations: MDA / Generative Programming

The construction of models helps to understand and analyse complex systems. However, a central idea in model-driven software development is to create models of software sys- tems with the final aim of generating the respective system. In a model-driven software construction process, transformations or generators translate models into binary code au- tomatically.

This idea is quite old as generative techniques have been applied in compiler con- struction for a long time (cf. Aho et al. (1986)). Programs written in a programming language are transformed by compilers into executable binary code which is a generative process. However, compiler frontends (i.e., lexer and parser) usually process a fixed set of programming languages and compiler backends generate code for a fixed amount of processors.

In contrast to this, in model-driven techniques users are allowed to define their own meta-models (including their concrete syntax) and user-defined transformations. Hence, only the meta-meta-model and the transformation engines are fixed, but not the meta- model and the transformations. Both can be defined by the end-user for specific purposes.

Note, that the fact that meta-models and transformations can be specified, they need not be specified. As with any other software artefact, third party software developers can simply reuse them. However, the reuse possibilities depend on how specific a meta- model and its transformations are designed with respect to a certain domain. Very specific meta-models can only be reused in very few other cases, where generic meta-models can be reused in many cases. The same is true for programming languages: general purpose languages like Java can be used for a wide range of problems while domain specific languages are specialised for a specific domain.

The following paragraphs give an overview on exiting generation and transformation techniques.Czarnecki and Eisenecker(2000) have introduced the idea of using generators to raise the level of abstraction in the software development process in their book on Generative Programming already in 2000. However, their work on domain modelling and domain variance analysis using feature diagrams is still applied especially in the area of software product line engineering (Lee et al.,2002).

More recent approaches are based on MOF or EMF as meta-models and utilise spe- cialised transformation engines. They can be classified into Model-2-Model transforma- tions and Model-2-Text transformations.

Finally, the overview concludes with a section on best practices for writing transfor- mations. This is important as the analysis of transformations should concentrate on the most common types of transformations.

Generative Programming Czarnecki and Eisenecker (2000) introduced the concept of

Generative Programming. The idea is to use generators to generate program code. An input specification parameterises the generation process. It defines how the generated code should look like. In Generative Programming, a domain analysis identifies all vari- abilities of a given target domain for which the generator generates code.

The identified variabilities in the target domain are formally captured in so called fea- ture diagrams. A feature represents a certain aspect of the domain which either exists in an instance of the target domain or not. Additionally, features may also carry additional attributes which characterise them in more detail. Relationships among the features cap- ture constrains among them, e.g., features may require other feature as prerequisites or be mutually exclusive with other features. Feature diagrams support a graphical concrete syntax which allows to specify them in an easy understandable way. Figure2.6shows an example for a feature diagram.

An instance of a feature diagram, is called a (feature) configuration. Any configura- tion of the feature diagram in figure 2.6 either has Feature1 or Feature2 selected. If Feature1is selected, the optional feature may also be selected. If Feature2 is selected,

Legend

Feature Configuration

Feature 1 Feature 2

Optional Feature Required Feature Required Feature XOR-Relation Optional Feature Required Feature

Figure 2.6: Example for a Feature Diagram

both required features also have to be selected.

Feature diagrams and their configurations are specialised to parameterise generators. This thesis uses them to parameterise model transformations as model transformations are special types of generators.

MDSD Transformations Commonly, transformations in the context of MDSD are clas-

sified into two types: model-2-model (M2M) and model-2-text (M2T) transformations. The following paragraphs briefly introduce each class.

Model-2-Model Model-2-Model transformations transform an instance of a meta-

model A into an instance of a meta-model B. Usually, meta-model A and B are instances of the same meta-meta-model in such a transformation. A and B need not necessarily be different.

The transformation is specified in some special language executable by a specific transformation engine. The transformation language itself can be an instance of the meta- meta-model of A and B, but this is no necessary prerequisite. Figure2.7gives an overview on the introduced relationships.

As shown in figure2.7, transformation rules use concepts of the source and the target meta-model to specify their effect. Hence, they are specific to the meta-models involved. A rule for a class in meta-model A is matched to instances of this class found in model- instance A. The matching objects are then transformed as specified into objects in model- instance B. These objects are instances of meta-model B.

For example, a model-transformation capable of transforming an instance of UML2 into an instance of a meta-model for Entity-Relationship-Models (ER-Model) may con- tain the rule to transform any instance of a UML2 class into an entity of the ER-Model. Additionally, any instance of an UML2 association is transformed into a corresponding

Model

Instance A

Meta-Model A

InstanceOf

Meta-Model

B

Model

Instance B

InstanceOf

input

output

InstanceOf

Figure 2.7: Function of a MDSD-Transformation Engine

relationship in the ER-Model. These rules demonstrate how the transformation maps concepts of the UML2-Meta-Model (class, association) to concepts of the ER-Meta-Model. There is a wide range of available transformation engines and languages summarised and classified in a recent survey by Czarnecki and Helsen (2003). The most impor- tant types for model-2-model transformations are direct-manipulations, relational, graph- transformation-based, or hybrid approaches.

Direct-manipulations can be used if equal source and target meta-models are used and the result of the transformation is stored directly in the same model used as input. They are applied frequently to add platform specific (see section 2.2.3) information to a platform independent model.

Relational approaches specify the transformation rules as formal relations. This is done by defining a relationship between a selected set of source and target objects using constraints. The transformation engine takes the set of relations and either tests if the relationships are fulfilled resulting in a boolean value or alters the target model such that none of the relationships is violated. The importance of relational transformation languages comes from the OMG’s standardised transformation language QVT (Object

Management Group (OMG),2007a) whose core (QVT-Core and QVT-Relational) is based

on relational semantics.

Graph-transformation approaches use the theoretical foundations of graph-grammars and apply them to models which are interpreted as graphs of objects for this. In graph grammars rules usually consist of a left-hand-side pattern and a right-hand-side pattern. Whenever any left-hand-side pattern of any rule matches to an object-sub-graph of the input model that part of the model is replaced by the structure given via the right-hand- side pattern. The process is repeated as long as matching left-hand-side patterns remain. Finally, hybrid approaches combine the power of several other approaches. The Atlas

Transformation Language (ATLAS Group, 2007) developed by INRIA in France is the most important language in this category. It combines declarative (relation based) rules with imperative rules. ATL’s importance comes from the fact that ATL is supplemented by one of the most mature tools for EMF based model-2-model transformations.

Czarnecki and Helsen (2003) also mention the use of transformations which are di-

rectly based on model instances stored in their concrete syntax as defined by XMI. As XMI is a XML based language, XSLT, a transformation language for transforming XML files, can be used as transformation language. Some of the model-based performance prediction methods described in section2.3.7take this approach.

Discussion Current model-2-model transformation engines posses the potential to al-

ter the way MDSD is applied in practice. However, the current state of research, tool development, and industrial case-studies is still immature. Uhl(2007b) lists a bunch of unresolved issues whose solutions he considers a necessary prerequisite for enterprise- scale MDSD use. Research is still directed at defining the right level of abstraction and ex- pressiveness for transformation languages. Additionally, development processes which are tailored for MDSD need to be researched. Available tools are often restricted to re- search prototypes, industrial quality tools are still under development. QVT which is the designated standard in the OMG’s MDA vision is still in the process of finalization and is considered too complex to be fully implemented. Using XSLT as model-2-model transformation language should become obsolete if more mature tools for higher level transformations are available. Also industrial case studies need mature tool support to become feasible.

Compared to model-2-model transformations, model-2-text transformation engines and languages are more mature.

Model-2-Text Model-2-text transformations can be seen as a special class of model-2-

model transformations where the target meta-model is simply an arbitrary text file. How- ever, as most non-MDSD tools use a textual concrete syntax (like compiler for program- ming languages, XML tools, ...) an efficient generation of textual artefacts is important to reuse those tools. Hence, special transformation engines generate textual artefacts from models. According toCzarnecki and Helsen(2003) andRentschler(2006) visitor and tem- plate based approaches are used in current tools.

Visitor based approaches traverse the graph of objects in the source model by using the visitor design pattern (cf.Gamma et al.(1995)). In this pattern, a visitor object traverses a graph of objects and executes at each node which it traverses code specific to the type of the node.

Template based approaches use templates which are text artefacts enriched with small code snippets. The code snippets are executed at transformation time and their result is inserted into the surrounding text artefact. The code execution is used to query informa- tion from the source model.

Model-2-text transformations for the proof-of-concept implementation in this the- sis have been written using XPand, the template language available in the EMF-based open-source generator framework openArchitectureWare (openArchitectureWare (oAW),

2007). A recent survey on model-2-text engines can be found in a seminar work by

Rentschler(2006).

Transformation practices There is a close relationship between design or architecture

patterns and MDSD transformations. Patterns are common solutions to reoccurring prob- lems (Gamma et al.,1995). Transformations are used to capture expert knowledge on how to transform instances of models in a repeatable, executable way. Often, patterns are part of the expert knowledge needed in this mapping. This is especially true for model-2-text transformations which usually respect best-practices. Hence, Quality of Service analyses of generated code has to cope with patterns frequently. This is especially important as many patterns alter extra-functional properties.

In particular, patterns are useful if the source model contains concepts of higher ab- stractions where the abstractions are taken from pattern literature. For example, a com- munication meta-model for connectors might offer a set of different connectors like call and block, message passing, reliable unicast, etc. (cf. Hohpe and Woolf(2003)). Each con- nector in this list corresponds to a pattern. The model-2-code transformation generates instances of the pattern during connector transformation.

Additionally, patterns are applied if the generated code should be later mixed with manual written parts. As a separation of generated and manually modified code offers several advantages, patterns like the template method pattern are applied to mix gener- ated and manually written code (V ¨olter and Stahl,2006).