SMTL2Java: A simple model transformation language compiled to Java

Metamodels and models can be found everywhere in the information technologies, not everywhere recognised as such, but they are there, just think of a JPEG file. There is a description of how such a file has to look like, what information has to be in there and how the information is stored, that's the metamodel. And then there are JPEG files, e.g. from a digicam or a scanner, those are the models. Model based approaches like Model Driven Development (MDE) or Model Driven Software Engineering (MDSE) heavily depend on the ability to transform one model into another model. Within the previous example, that would be a JPEG file transformed into another format like PNG.

The starting point of our work is the Atlas Transformation Language (ATL), which is easy to read and understand, because it's written in plain text. But as soon as it is compiled into its intermediate bytecode, which is to be interpreted by the model transformation virtual machine, the code isn't that readable or understandable anymore, thus hard to debug. Our approach takes whole transformations and compiles them to Java, the advantage is clearly on hand, it's more readable, understandable and, most important, easily debuggable.

We focused our work on a functionally reduced subset of ATL and named it after what it is, a Simple Model Transformation Language (SMTL). In the first step we created an abstract syntax, our metamodel, see Figure 1.

Figure 1: The SMTL metamodel

In the second step we built a concrete textual syntax with Xtext, following our metamodel.

Concrete textual syntax

SMTL supports the transformation of several source elements to several target elements, the rules are the same as ATL standard matched rules. However OCL constraints are not supported. We have also added some different keywords to SMTL. In Listing 1.1 an example of an SMTL transformation is given. Listing 1.2 show an example of ATL transformation.

Listing 1.1: SMTL transformation

module A2B;
input A path/metamodel
output B path/metamodel

rule A2B {
  from
    a1 : A ! Model
  to
    b1 : B ! Model (
      pb name <− ”name”,
      nb name2 <− a1.name
    ),
    b2 : B ! Model (
      oeb b <− b1,
      rb listB <− a1.listA
    )
}

Listing 1.2: ATL transformation

--@path A=/at.ac.tuwien.big.ame13.atl2java.atl/model/A.ecore
--@path B=/at.ac.tuwien.big.ame13.atl2java.atl/model/B.ecore
module A2B;
create OUT : B from IN : A;

rule Model2Model {
  from
    ma : A ! Model
  to
    mb : B ! Model (
      b <- ma.a
    )
}

Comparing the SMTL grammar in Listing 1.1 with the ATL in Listing 1.2, we can notice the differences in the header part. SMTL doesn’t have a path definition. Instead of that information, the models are provided by the input and output keywords.
The main differences though are the specified bindings with keywords pb, nb, oeb, rb in SMTL, which do not explicitly exist in ATL. These bindings are as follows:

• Primitive binding "pb": Represents the assignment of a primitive type, like integer or string to the feature of a target element.
• Navigation binding "nb": Binds a feature of a target element with a defined source element’s feature value.
• Output pattern element binding "oeb": Binds a feature of a target element with another target element of the same rule, but that target element has to be declared beforehand.
• Resolve binding "rb": Has the purpose to bind a feature of a target element with a list of target elements or a single target object. The target elements have thereby got to be resolved first by the information of the transient links, since only the feature value of a source element is given for this kind of binding. From the grammar’s point of view, resolve bindings are nearly the same as navigation bindings and, as a result, extend those.

In the next step a model to code transformation is realised with the help of Xtend, with which SMTL models can be transformed into executable Java codes.

Model to code transformation

The main purpose of this part is to do a model to model transformation that is executed based on Java. For this, we first of all have to implement a model to code transformation with the help of Xtend, to transform a SMTL model into executable Java code, which then does the actual model to model transformation afterwards. So, the implementation in Xtend can be seen as the compiler for SMTL models to the corresponding Java classes.

For the implementation of the compiler it was important to consider the following points: In order to do a concrete model to model transformation in Java, the transformation has to be divided into a creation phase and an initialization phase. In the former phase only the creation of target elements out of matched source elements is done, whereby the bindings of the target elements’ feature values are completely done in the initialization phase. In order to have enough information to fulfill the bindings the second important point has to be considered, that is to save the trace information of source elements to target elements in transient links during the creation phase. Since in some kinds of bindings (e.g. resolve bindings) the information about which target elements are created out of which source elements is needed, the stored information in the transient links can help in these situations.

The following example shall show an exemplary model to model transformation.

Example

In Figure 2 we try to transform book elements into ebook elements, which is done by the rule Book2Ebook. The element book contains two information, namely title and author and these will be bind to the values of the features name and info of the element ebook. The binding types in this example are navigation bindings, which bind the features name <- title and info <- author. The other rule Model2Model defines the transformation from a model into another model element and contains a resolve binding. The resolve binding here is responsible, that the elements, which are transformed by the rule Book2Ebook, exists in the output model.

In this example, we have as input model three book elements and after the rule is executed, we get as output model the three corresponding ebook elements.

Figure 2: Exemplary model to model transformation "Book2Ebook"