9.2 The Transformation Definition Language | Project Leadership (The Project Management Essential Library)

In the previous section, we saw transformation rules written in plain English. This is understandable for a human reader, but not for an automated system. In the MDA framework, as shown in Figure 2-7 and Figure 8-8, we need a transformation definition that can be plugged into a transformation tool, which can then automatically execute the transformation. In this section we define a formal notation for writing transformation rules and transformation definitions. Because the rules are not in English but in a formal syntax, they can be interpreted and executed by a transformation tool.

At the time of writing this book, no standard language for writing transformation definitions existed (see section 11.3). Therefore we, the authors, had to define our own transformation definition language. Parts of this language make use of OCL. The purpose of this language is solely to explain the formalization of transformation rules in this book, it is not intended to be a proposal for a standard transformation language. This section explains the transformation definition language used in this book.

9.2.1 Requirements for a Transformation Rule

Any definition of a transformation rule should contain the following information:

The source language reference.
The target language reference.
Optional transformation parameters, for example, constants used in the generation of the target.
A set of named source language model elements (called S) from the source language metamodel.
A set of named target language model elements (called T) from the target language metamodel.
A bidirectional indicator : a boolean that states whether or not a source model may/can be (re)generated from the target.
The source language condition : an invariant that states the conditions that must hold in the source model for this transformation rule to apply. The invariant may only be expressed on elements from set S.
The target language condition : an invariant that states the conditions that must hold in the target model for this transformation rule to apply, or that needs to be generated when the target model is not yet present. The invariant may only be expressed on elements from set T.
A set of mapping rules, where each rule maps some model elements in set S to model elements in set T.

Furthermore, we prefer to name each transformation rule for referential purposes, although this name could be omitted.

9.2.2 A Notation for Transformation Rules

For each of the parts of a transformation rule there is a specific notation. Every transformation rule starts with the keyword Transformation and a name. The source and target languages are referenced by the stating both language names between brackets after the transformation name. The first name indicates the source language, the second the target language. In practice the language names would be standard fully qualified names, in the examples we use simple names . The rest of the transformation rule is written between curly brackets. Example:

  Transformation  ClassToTable (UML, SQL) { ... }

The parameters to this transformation rule are written as a list of variable declarations following the keyword params . The type of a transformation parameter must be a type defined in either the source or the target language. Example:

  params  setterprefix: String = 'set';          getterprefix: String = 'get';

The source and target language model elements are written as variable declarations also following the keywords source and target , respectively. The type of a model element must be a type defined in the source or the target language metamodel, respectively. Example:

  target  c: SQL::Column    ;        f: SQL::ForeignKey;

The directional indicator is given by the keyword bidirectional or unidirectional . Example:

  unidirectional  ;

The source and target language condition are written as OCL boolean expressions after the keywords source condition and target condition . The elements used in the expressions may only come from the source or the target language, respectively and the expressions may only start with elements declared in the source or target elements section respectively. Example:

  target condition  f.value = c  and  c.type = f.refersTo.value.type;

All mapping rules come after the keyword mapping . In the notation for mapping rules, one new symbol is used: <~>. It is used as an infix operator with two operands. The intuitive meaning of this symbol is: "There is a transformation rule from the source language to the target language that transforms the left-hand side operand to the right-hand side operand." If the transformation rule is bidirectional, the same holds from right to left. Example:

  mapping  c.name <~> t.name;

The mapping operator may also be used when both operands are sets. In that case its intuitive meaning is: "For all elements in the first operand there is a transformation to an element in the second operand."

For instance, if classes is a set of UML classes and tables is a set of SQL tables, then the expression classes <~> tables, means that for all classes in the set classes, there is a table in the set tables for which there is a transformation that maps that class to that table. To put it more formally :

 classes->forAll( c  tables->exists( t  c <~> t );

When the transformation is defined as bidirectional, it means also that for all tables in the set tables, there is a class in the set classes for which there is a transformation that maps that table to that class. More formally expressed it means:

 classes->forAll( c  tables->exists( t  c <~> t ); and tables->forAll( t  classes->exists( c  c <~> t )

Because all mapping rules conceptually refer to other transformation rules, transformation rules are actually built up in a boot-strapping manner. The base of this boot-strapping is provided by a number of primitive transformation rules, which map primitive data types in the source language to primitive data types in the target language. From this base all transformations can be built using the mapping rules.

There is one restriction to mapping rules and that is that they cannot be defined conditionally. Any conditions on either source or target can be specified in the source and target conditions. As soon as the source and target conditions are true, the mapping rules are applicable .

9.2.3 Transformation Definitions

A set of rules formalized as explained above constitutes a transformation definition. However, sometimes transformation definitions are more conveniently defined by specifying that other transformation definitions are to be executed in sequence. To transform model A into model C, you might want to use the transformation definitions that transform model A into model B, and model B into model C. The reason might be that both transformations already exist, or that they are much easier to define. Therefore, a transformation definition may be defined in two ways.

A transformation definition may be defined either by specifying all transformation rules in the set, or by specifying that other transformation definitions are to be executed in sequence.

In the case of two transformations to be applied in sequence, application of a subtransformation definition results (at least conceptually) in an intermediate model, which is target to the first subtransformation definition, and source to the next .

There are a number of rules that apply to a transformation definition that is defined by a sequence of other transformation definitions:

The source language of the combined transformation definition is the source language of the first (sub)transformation definition.
The target language of the last (sub)transformation definition is the target language of the combined transformation definition.
The source language of any (sub)transformation definition is the target language of the (sub)transformation definition that precedes.

There is in this book no special notation for transformation definitions.