Transformation Languages and Systems

Based on the different transformation approaches outlined in Sect. 2.4.2, various trans- formation languages have been proposed. This section starts off with a classification of the most important ones. As enumerating all existing languages is out of the scope of this thesis, a selection is made. This selection is based on the relevance of the languages from a practical point of view and w.r.t. this thesis.

To give an overview of the transformation languages that are covered by this section, Table 2.2 summarizes some important language properties. It gives information about the type of the language (declarative or imperative), the kind of syntax used (textual or graphical) and the semantic foundation.

2 Background

Transformation Language Type Syntax Semantics

QVT Hybrid Hybrid Informal

ATL Hybrid Textual Informal

MISTRAL Declarative Textual Informal

MOLA Procedural Graphical Informal

GReAT Declarative Graphical Graph Rewriting

Story Diagrams Hybrid Graphical Graph Rewriting

GTXL n/a Textual n/a

AGG Declarative Graphical Graph Rewriting

PMT Procedural Textual Informal

MoTMoT Hybrid Graphical Graph Rewriting

Atom3 Declarative Graphical Graph Rewriting

VIATRA Declarative Graphical Graph Rewriting

Tefkat Declarative Textual Logic-based

Table 2.2: Classification of transformation languages.

QVT

Query View Transformation (QVT) [83] is a set of related transformation languages that was standardized by the OMG. It consists of a two level architecture. On the lower level, QVT Core can be used to perform pattern matching and to check conditions over variables (i.e., elements and attributes of models involved in the transformation). These basic operations can already be employed to transform models, but yield very verbose transformation specifications because of the simplicity of the operators. Based on this, QVT Relations can be used to specify relations between models declaratively. More complex patterns are supported on this higher level and trace information can automatically be gathered when executing transformations.

Transformations written in QVT Relations are translated QVT Core specifications. This is similar to the translation of high level programs to instructions of a virtual machine and also pictured as such in the QVT standard [83].

QVT is not formally based on the TGG formalism, but the relational part of QVT exposes many similarities. A comprehensive comparison between QVT and the TGG approach can be found in [84]. In the QVT standard itself, the semantics of the QVT languages is only specified informally. To obtain a more formal representation of the semantics of QVT, different approaches have been published [85, 86]. Unfortunately the QVT committee did not include these suggestions in new versions of the standard3_.

As the name QVT Relations indicates, the aim of this language is to allow for bidirec- tional transformations. However, the QVT specification contains some inconsistencies

2.4 Model Transformations

which can cause problems in this regard [87]. Nonetheless many industrial transforma- tion engines adopt the QVT standard.

ATL

Atlas Transformation Language (ATL) [88] is a model transformation language and tool developed as part of the ATLAS Model Management Architecture (AMMA) [89] platform. ATL uses textual syntax to define transformation rules. It adopts parts of the QVT specification, but does not strictly implement the standard (cf. [90] for a comparison of ATL and QVT). ATL does also rely on OCL to express conditions and constraints. Thus, ATL is a hybrid language that provides both imperative, as well as declarative concepts. ATL transformation rules are unidirectional. Thus, ATL cannot be readily employed in RTE.

However, ATL is very popular among practitioners, which can probably be explained by the fact that ATL was one of the first stable and mature transformation tools in the Eclipse ecosystem. Also, ATL is built on top of Eclipse Modeling Framework (EMF) [28], which is heavily used in the industry. The relevance that ATL has gained in the modeling community does amplify the need for RTE systems that can deal with unidirectional transformations. Rewriting all existing transformations using a bidirectional language is most probably not an option for practitioners.

Technically, ATL comes with a compiler that translates transformation specifications to a lower level representation, which can be executed by the ATL virtual machine. Also, quite recently attempts have been made to specify the semantics of ATL formally [91]. ATL does not provide built-in support for traceability, but transformations can be ex- tended to emulate such functionality [92].

MISTRAL

Another language that can be used to transform models is Multiple IntenSion TRAns- formation Language (MISTRAL) [93]. MISTRAL is based on the observation that de- pending on the metalevel(s) a transformation is defined and execute on, different model transformation scenarios emerge. The authors explore reasons why there is no uniform language to handle all these scenarios. They point out the different meanings of gener- alization and instantiation on the various metalevels as a root cause. As a consequence, they propose a framework where the transformation language is separated from these two concepts. This framework is called MISTRAL and relies on mappings from models on all levels (M3-M0) to a generic model, which models theinstanceOf relation explicitly.

MOLA

MOdel transformation LAnguage (MOLA) [94] is a procedural, graphical model trans- formation language. Using graphical syntax loops, patterns and statements can be ex-

2 Background

pressed. The original paper on MOLA [94] showed two example transformations—a translation of class diagrams to relational models and the flattening of state charts.

The authors of MOLA, state that it was designed to be an easily readable transfor- mation language by combining traditional structured programming [...] with rules based on simple patterns [94]. While readability is difficult to measure, a clear disadvantage of the approach is the complexity of the languages operators. Using constructs from programming languages (e.g.,while loops), renders the analysis of transformation pro- grams difficult. Using MOLA programs for bidirectional transformations does not seem feasible or is at least not considered in [94].

GReAT

Graph Rewriting and Transformation (GReAT) [95] is a transformation language that is based on graph rewriting. To specify source and target models, UML class diagrams are utilized. Elements of an additional (third) domain model define crosslinks between the source and the target. The underlying graphs are typed and attributed multi-graphs. Rules in GReAT can contain elements that are explicitly tagged withnew (or delete) to indicate that they have to be created (or deleted) while executing the transformation. The authors of GReAT examine their approach using three scenarios: 1) a transformation of hierarchical concurrent state machines to finite state machines, 2) a Matlab Simulink Stateflow to Hybrid Automata conversion, and 3) a preprocessor for Java to add aspect code. The approach does not take bidirectional transformations into consideration.

Story Diagrams

Story Diagrams [96] are the transformation language that is used in the Fujaba [97] tool suite. Based on graph rewriting, graphical rules—so called patterns—can be spec- ified. These patterns describe the transformation of object graphs. Elements in Story Diagrams can be tagged as new or required, which indicates whether elements must be present to apply a certain pattern or whether they must be created once a pattern matches. Story Diagrams do also allow for control structures (e.g., conditions and loops). To execute a Story Diagram on a concrete object graph (or model), Fujaba translates the diagrams to executable Java code, which in turn modifies the input according to the diagrams contents. Recently, interpreters for Story Diagrams have also become available [98]. Story Diagrams have been successfully applied in various application areas, for example for Round-Trip Engineering [99], tool integration [97] and real-time system development [100].

The formal semantics of Story Diagrams was originally defined by a translation to Progres [101] productions [96]. But, the translation of sorted, ordered and qualified associations to Progres was still missing. Consequently a number of semantic issues were detected and outlined in [102].

2.4 Model Transformations

GTXL

Graph Transformation Exchange Language (GTXL) [103, 104] is an exchange format for graph transformation rules based on XML. GTXL documents contain sets of rules together with positive and negative application conditions. GTXL can be used to ex- change rules for different kinds of transformation techniques. Different techniques are tagged by their particular name. Thus, the semantics of the rules stored in a GTXL document is determined by the tools that process the rules. The GTXL format itself does not establish any restrictions in this regard. Thus, GTXL is purely considered with the specification of an abstract and concrete syntax for graph transformation rules. Semantics is not covered.

AGG

The Attributed Graph Grammar System (AGG) [105] is a tool developed at the TU Berlin. It is based on algebraic graph transformation [106]. Thus, AGG relies on a solid formal foundation. AGG supports various types of analysis that can be performed on transformation rules and input graphs. For example, it can parse graphs, check them for consistency and detect conflicts using critical pair analysis.

AGG uses an interpreter to execute transformation rules and can be flexibly used for different applications, because it supports to add attributes to graphs. Thus, arbitrary data can be represented by and transformed based on the graph formalism. AGG uses type graphs to model the set of graphs that can be transformed. Also, AGG supports negative application conditions to control the execution of rules on a fine-grained basis.

PMT

PMT [107] is a transformation language developed by Laurence Tratt, which is defined as a DSL in the Converge language [108]. PMT is a change-propagating transformation language. That is, instead of creating a new target model upon each execution of a transformation, the source and the target models are updated only. Changes made to one of the models are propagated to the opposite model. This implies an initialization phase, if the target model does not exist yet. In this case, PMT works like a unidirectional language. The target model is created by executing all changes required to build the source model from the scratch (i.e., assuming an empty source model first).

To specify how changes are propagated, PMT uses rules that consist of patterns, con- ditions and actions. When requested by the user, PMT propagates collected changes according to the specified rules. As PMT rules are Converge functions, the transforma- tion is implemented by the execution of these functions. Since Converge is a full-fledged object-oriented programming language, the analysis of PMT rules is restricted.

2 Background

MoTMoT

MoTMoT [109] is a model transformation tool that is based on Story Diagrams [96]. The original implementation of Story Diagrams in the Fujaba tool suite [97] was not based on common standards (e.g., it used a proprietary metamodeling language and serialization format). In contrast, MoTMoT employs UML and a specific profile for Story Diagrams. Thus, MoTMoT leverages the standardization of Story Diagram modeling. Among other things, MoTMoT has been used to apply refactorings to models [110]. Currently, there is activity in the Fujaba community to standardize both the syntax and semantics of Story Diagram models, which continues the goals of MoTMoT.

Atom3

Atom3 [111] is a metamodeling environment for visual languages. Besides its ability to specify visual languages and generate tools from these specifications, Atom3 _provides

support to execute transformations between different languages. The different types of transformations supported by Atom3 can be found in [112]. The formal basis for Atom3 is graph transformation.

VIATRA

The VIsual Automated model TRAnsformations (VIATRA) [113] framework is a set of tools to visually define transformations for models that are based on the UML and the XML Metadata Interchange (XMI) [114] standard. VIATRA can, for example, be used to define static semantics in a declarative and pattern-based manner. Also, the dynamic semantics of models can be specified using graph transformation rules.

Tefkat

Tefkat [115] is an open-source model transformation engine based on EMF. Tefkat im- plements a declarative, textual variant of QVT. Transformation rules in Tefkat consist of patterns that have syntax similar to Structured Query Language (SQL) (e.g., FROM andWHERE clauses). Tefkat rules do support reflection to access metamodels during the execution of transformations. Tefkat also entails a debugger for transformation rules.

Due to its implementation, which is based on logics, Tefkat requires transformation rules to be stratified. For example, rules cannot specify a pattern that requires an object to not exist and then create this object if the rules matches. Since Tefkat is not based on a dedicated logic engine, but implemented from scratch, it is difficult to say whether this restriction is bound to the implementation or the approach in general. For example, the are subclasses of graph transformation that can stratify rules automatically [116]. Unfortunately, Tefkat seems to be inactive since 20074.