Modules

An ATL module corresponds to a model to model transformation. The structure of an ATL module comprises a header section, an optional import section, a set of helpers and a set of transformation rules. In the header section source and target models of the transformation are defined. External libraries may be included in the import section. Then a set of helpers may be defined. Helpers may be global variables or functions defined with OCL. Functions can be global or bound to the context of a metaclass. The different types of rules are de-scribed in the following subsections.

2.3.3.1.1 Matched Rules

A matched rule is the default construct for the declarative part of transformations in ATL.

The definition comprises the source pattern, the target pattern, an optional imperative block and the optional definition of local variables. The source pattern consists of source pattern elements. Each source pattern element defines a local model element variable with a given type (i.e. metaclass) from a given metamodel. The set of potential matches of the rule is the cartesian product of the sets matching each source pattern element. A source pattern ele-ment matches all model eleele-ments that conform to the type of the model eleele-ment variable.

This set can optionally be constrained by a guard condition expressed in OCL. Each match of the rule generates a target element for each target pattern element. Again each target pat-tern element defines a local model element variable with a given type (i.e. metaclass) from a given metamodel. In addition, a target pattern element comprises a set of bindings that assign values expressed in OCL to meta properties of the generated target elements.

Fi-45

nally, imperative code in the optional imperative section is executed. For details about syn-tax and semantics see [ATL06a]. The synsyn-tax of a matched rule definition has the following form:

rule Name {

using -- optional {

variable : type = OCL-expression;

...

}

from s : Source-Metamodel!Source-Metaclass [( OCL-expression )] -- optional guard [, ...]

to t : Target-Metamodel!Target-Metaclass (

target-meta-property <- OCL-expression [, ...]

) [, ...]

do -- optional {

imperative part of the rule }

}

It is important to know that (currently) each tuple of source model elements must not be matched by more than one (matched) rule. Thus, source patterns have to be designed care-fully and in case of equal types matched by different rules, it must be ensured that the guards of these rules partition the source elements into disjunctive sets. This restriction en-sures that the rule matching algorithm terminates, because each source model element can be matched at most once.

The following example demonstrates the use of matched rules to transform a UML model to a Java model, i.e. a model representing a Java program, which can be transformed to Java code. One rule is responsible for mapping UML classes to Java classes, while another rule is responsible for mapping UML packages to Java packages. Bindings for the name attributes of Java classes and packages are defined. In addition, these two rules are implic-itly related by the binding expression for the package attribute of the matched rule Class2JavaClass, which references the UML package in the source model to which the UML class belongs. The resolution algorithm of ATL resolves this to the target model element generated by the matched rule Package2Package.

Model Driven Software Engineering for Web Applications

rule Package2Package {

from p : UML!Package to jp : JAVA!Package (

name <- p.name )

}

rule Class2JavaClass {

from c : UML!Class to jc : JAVA!JavaClass (

name <- c.name, package <- c.package )

}

2.3.3.1.2 Lazy Rules

A lazy rule is a declarative rule, which is explicitly called. It is used for the application from within a matched rule. Lazy rules are extensions of matched rules but are not trig-gered automatically on elements of the source model, but called explicitly every time when referenced in a binding. Additionally, unique lazy rules are only executed once, thus when called multiple times they always return the same result.

2.3.3.1.3 Called Rules

A called rule is an imperative rule which is explicitly called. It is similar to a procedure with parameters in traditional programming. Called rules are typically used for dealing with global variables or generating output elements independent from a matching source pattern. Instead of a source pattern a parameter list has to be defined. They can only be called from imperative blocks of other rules.

2.3.3.1.4 Entrypoint and Endpoint Rules

Entrypoint rules and endpoint rules are called rules without parameters. Entrypoint rules are called before application of the declarative (i.e. matched) rules to the input model and endpoint rules are called after the output model has been generated.

47

2.3.3.1.5 Rule Inheritance

Inheritance is an important concept in object-oriented approaches [Gall95]. A class may inherit fields and methods from its superclass. Inherited methods can be overwritten and new fields and methods can be added to a subclass. One of the proclaimed benefits of us-ing inheritance is that it eases code reuse. Also many design patterns are based on the in-heritance concept [Gamma95].

In ATL the general concept for inheritance is transferred to matched transformation rules.

When several rules share a common part, this part can be moved upwards in the rule in-heritance hierarchy to the parent rule. To specify polymorphic rules the parent rule speci-fies source and target element names and types which are inherited to its children. Rules may be abstract, i.e. they cannot be applied directly.

A child rule matches a subset of what its parent rule matches. The source pattern must have the same number of elements. Each child source element must correspond to a unique par-ent source elempar-ent and each child elempar-ent type must conform to a type of the correspond-ing parent element, i.e. be of the same type or a subtype. The guards of the source elements are anded. Further, a child rule specializes target elements of its parent rule. Target ments can be added in child rules. Child target elements with corresponding parent ele-ments, i.e. with the same variable name, can have different types (but must be a subtype of the parent type), and have more bindings or redefine bindings. Only one child rule can match. There may be at most one default subrule including the parent rule if it is not ab-stract. A default rule is a rule without guard that is matched by default.

The informal semantics for rule inheritance is:

1. root rules (i.e. without parent) are matched,

2. for each potential match, every subrule with a guard is tested, 3. the one that matches, if any, is selected,

4. if none matches, the default rule, if any, is selected,

5. if selected rule is not a leaf (i.e. if it has subrules), then go to 2 6. target elements are created by using the most specific types.

The most specific bindings are used to initialize target elements, i.e. redefined bindings in the parent rule are not executed.

Model Driven Software Engineering for Web Applications