This blog post describes a project implemented in the context of the course “Advanced Model Engineering” in summer semester 2013. The results of the project consist of two parts. On the one hand we created a new exercise for students in the domain of model-driven engineering, and on the other hand we performed a practical evaluation of ATL against an imperative Xtend-based approach.
Model engineering exerciseThe general structure of our exercise is based on the structure of the existing exercises that were used in previous instances of the course “Model Engineering”. Our exercise consists of three parts:
- Creation of two meta-models
- Model-to-model transformation from PIM to PSM using ATL
- Model-to-code transformation from PSM to executable code using Xtend
According to our intended workflow students solve each part in groups and receive a reference implementation of each part after the respective submission deadline. Therefore, we will avoid to publishing figures and code.
Our primary requirement for part 1 was that the PIM and PSM should not be too abstract but from already familiar to most students. Therefore, we chose a meta-model for questionnaires and surveys for part 1.1 (PIM), since most students are probably familiar with questionnaires and surveys. Since we can assume that all students are familiar with web forms, we chose a meta-model for simple web forms for part 1.2 (PSM).
Part 2 uses ATL to transform a questionnaire model into a simple web form model.
The following screenshot shows an example of a simple generated questionnaire web page:
ATL versus an imperative Xtend-based approach
As mentioned above, we implemented a model-to-model transformation using ATL. The purpose of this transformation is to transfrom a questionnaire model into a simple web form model.
Additionaly we evaluated an imperative Xtend-based approach for model-to-model transformations. Our aim was to find out whether learning a DSL, in this case ATL, is really necessary or if a general-purpose programming language such as Xtend is sufficient. We chose Xtend since it is a modern general-purpose programming language. Since Xtend is Java-based we could leverage EMF’s features.
Xtend transformation infrastructure
Our Xtend-based transformation process consist of three steps:
- Model loading: The source model is loaded from disk.
- Model transformation: The target model is derived by applying a transformation method to the source model
- Model persistence: The target model is saved to disk.
In order to isolate the infrastructure code (step 1 and 3) from the actual model transformation we use the following approach: A transformation is modeled as class which extends the base class
AbstractModelToModelTransformation (see source code). The base class is responsible for loading the source model and persisting the target model. The transformation method has to be provided by a concrete sub-class.
The following listing shows the complete implementation of an identity transformation:
The following listing shows two ATL rules interspersed with their Xtend counterparts:
The first ATL rule on lines 2–8, is quite similar to its Xtend counterpart. The derivation of the values
text on lines 5–6 is very similar to its Xtend counterpart on lines 12–13. The second rule on lines 17–22, is also similar to its Xtend counterpart. One noticeable exception is the derivation of the collection
resultMessages on line 20 and the corresponding Xtend counterpart on line 26. Line 26 is more verbose since more explicit steps need to be performed to fit into Java’s type model.
- ATL transformations tend to be shorter than Xtend transformations (in our case 160 versus 250 lines of code). Xtend (and Java) transformations in turn have the benefit that they use an imperative approach which is probably easier to comprehend for developers which are already familiar with Java.
- Whereas the result of an ATL transformation is deterministic the execution order of ATL rules is not. By contrast, Xtend transformations follow the standard execution order semantics of a Java program. ATL’s approach would allow the ATL engine to execute multiple rules in parallel, whereas our Xtend transformation approach is strictly intended for non-parallel (single-threaded) execution. Although a multi-threaded Xtend transformation approach would be technically possible, we doubt that such a transformation could be implemented in a way that does not lack readability in comparison to a similar ATL transformation.
Both ATL and Xtend provide functional features, however, in a very different
form. Most parts of an ATL transformation are functional in the sense that they
are free of side effects. Imperative statements — statements with side effects —
must be performed in designated areas of the code such as
do-blocks. Therefore statements with side effects are easily recognizable by there location in the ATL source code file. By contrast, Xtend is an imperative object-oriented language that additionally provides some functional features. Therefore, there is no way to recognize statements with side-effects by looking for a certain keyword alone.