Declarative Rules (Relations)

In the Relations language a transformation is specified as a set of relations that must hold for the participating models. A basic relation definition for an example transformation that maps UML classes to Java classes looks like this:

relation Class2JavaClass {

domain uml c : Class { name = cn } domain java jc : JavaClass { name = cn } }

A relation definition comprises a list of domain pattern definitions. A domain is a distin- guished typed variable that can be matched in a model of a given type. In the example there are two domains for UML and Java models, respectively. A domain pattern can be considered as a template for objects and their properties that must be located, modified, or created in a candidate model to satisfy the relation, see [OMG05b] for the definition of syntax and semantics. In the example given above, the property name in both patterns is

bound to the same variable implying that they should have the same value. When execut- ing the transformation the relation above does not have any direction nor will the partici- pating models be modified, but inconsistencies are reported. Thus, this represents a mere model checking transformation.

Domains can be marked as checkonly or enforced. Checkonly domains are merely checked

if there exists a valid match that satisfies the relationship. Enforced domains are first checked and when the checking fails, the target model is modified so that the relation holds. For more details about the semantics see [OMG05b]. The direction of the transfor- mation is from checkonly domains to enforced domains. The example with enforcement of creating the Java classes (if they don’t exist yet) looks like this:

relation Class2JavaClass {

checkonly domain uml c : Class { name = cn }

enforce domain java jc : JavaClass { name = cn } }

A very important aspect for modeling transformations is how transformation rules can be composed. This allows giving a structure to transformation rules and facilitates reuse by decomposing complex transformations into many small ones. In QVT transformation rules can be composed by using either the when part or the where part of a rule. The when part

Model Driven Software Engineering for Web Applications

defines the guard condition of a rule. It can be used to express which rules have to be exe- cuted before executing a rule. The where part on the other hand can be used to trigger other

transformations after a rule is executed. The following example uses the when part to com- pose two rules for mapping packages and their contained classes to Java:

relation Package2Package {

checkonly domain uml p : Package {

name = pn }

enforce domain java jp : Package { name = pn, isImported = false } } relation Class2JavaClass {

checkonly domain uml c : Class {

name = cn,

package = p : Package {} }

enforce domain java jc : JavaClass { name = cn, package = jp : Package {} } when { Package2Package( p, jp ); } }

The other variant using the where part (and the first version of Class2JavaClass) looks like

this:

relation Package2Package {

checkonly domain uml p : Package {

name = pn,

ownedType = c : Class {} }

enforce domain java jp : Package { name = pn, isImported = false, classes = jc : JavaClass {} } where { Class2JavaClass( c, jc ); } }

It case of using when the referenced rule is triggered before, in case of where after the ref-

erencing rule, thus it depends on the transformation design, which solution is more appro- priate.

In addition to the textual notation there is a graphical notation for the Relations language that is similar to UML object diagrams. The example relation Class2JavaClass in the

graphical notation is depicted in Figure 9. The strength of the graphical notation is the visualization of domain patterns in a intuitive way, hence facilitating the acceptance of QVT among users. For more information about the graphical notation see [OMG05b].

c : Class name = cn jc : JavaClass name=cn Class2JavaClass «domain» «domain»

uml : UML java : JAVA

C E c : Class name = cn jc : JavaClass name=cn Class2JavaClass «domain» «domain»

uml : UML java : JAVA

C E

Figure 9. Graphical notation of QVT Relations

2.3.2.2

Imperative Rules (Operational Mappings)

The Operational Mappings language can either be used for a complete imperative approach or for complementing declarative relations with an imperative implementation (hybrid ap- proach). A transformation in the Operational Mappings language comprises an entry opera- tion called main and a set of mapping operations. A mapping operation is syntactically de-

Model Driven Software Engineering for Web Applications

and a postcondition (a where clause). Even if it is not explicitly notated in the concrete syntax, a mapping operation is always a refinement of a relation, which is the owner of the when and where clauses. The method body of a mapping operation comprises imperative expressions and object expressions. Imperative expressions are a marriage between OCL expressions and typical imperative expressions as found for example in Java. Object ex- pressions provide a high-level construct for creating and/or updating model elements. For more details about syntax and semantics of Operational Mappings see [OMG05b].

The following example shows the imperative realization of the transformation rules in the previous section. Operations are always called explicitly by using the map operator. The

entry point of the transformation is the entry operation main.

main() {

uml.objectsOfType( Package )->map package2Package(); }

mapping Package::package2Package() : Package {

name := self.name;

classes := self.ownedType->map class2JavaClass(); }

mapping Class::class2JavaClass() : JavaClass {

name := self.name; }

2.3.2.3

Tools

As already stated in the introduction, the specification of QVT is currently in the finaliza- tions phase, and therefore fully compliant tool support is not yet available, although initial efforts have been made. For example, the current version of the modeling tool Together Architect 2006 for Eclipse2 provides a partial implementation of the imperative part of QVT, i.e. an implementation for operational mappings. An alternative could be the (possi- bly bi-directional) mapping from the relational part of QVT to a graph-based transforma- tion approach such as AGG or VIATRA but, as already stated in 2.3.1.9, this would be in-

2 _{Together Architect product homepage http://www.borland.com/de/products/together/index.html}

sufficient without a mapping of the imperative part of QVT. The lack of tool support at the time of writing was one of the major reasons for choosing ATL over QVT, but this deci- sion was not made without interoperability between the approaches in mind, see also 2.3.5.