Feature-based survey of model transformation approaches.

Figure 10 illustrates how the transformation from class models to schemas can be expressed in AGG. Only two rules are shown. The rule in Figure 10A maps packages to schemas. The mapping from classes to tables is given in Figure 10B. The mapping of attributes to columns is not shown. The RHS of an AGG rule contains a mixture of the new elements and elements from the LHS, as indicated by the indexes prefixing their names. When the LHS is matched, new elements are created. The implicit scheduling is achieved through correspondence objects connecting source and target elements (which are an example of intermediate structures) and negative conditions. For example, the package-to-schema rule matches packages and creates the corresponding schemas and the package-to-schema correspondence objects (i.e., instances of P25). Each rule has a negative application condition, which is implicitly assumed to be its RHS. Because of the negative application condition, no additional schema objects will be created for a package that is already connected to a schema by a P25 object.

[FIGURE 10 OMITTED]

Systems such as VIATRA, GREAT, MOLA, and Fujaba extend the basic functionality of AGG and ATOM3 by adding explicit scheduling. For example, VIATRA users can build state machines to schedule transformation rules. The explicit representation of scheduling in GREAT is a data-flow graph. MOLA and Fujaba use control-flow graphs for that purpose. The class-model-to-schema transformation expressed in MOLA is shown in Figure 11. Each enclosing rectangular box represents a looping construct. Boxes with rounded corners represent looping conditions. The elements to be matched are drawn using solid lines; dashed lines are used for the elements to be created. The top condition matches package objects. When a package object is matched, the corresponding schema is created and the body of the loop, which is another loop, is executed. The latter loop iterates over all classes in the package that was matched in the current iteration of the outer loop and creates the corresponding classes and primary-key columns. The final step is a call to ProcessClassAttributes, which is a subprogram mapping attributes to columns.

[FIGURE 11 OMITTED]

Relational-style, multidirectional approaches based on graph transformations are also possible. For example, Konigs (32) discusses using a transformation approach based on triple-graph grammars to simulate QVT Relations.

Hybrid approach

Hybrid approaches combine different techniques from the previous categories. The different approaches can be combined as separate components or, in a more fine-grained fashion, at the level of individual rules. QVT is an example of a hybrid approach with three separate components, namely Relations, Operational mappings, and Core. Examples of the fine-grained combination are ATL and YATL.

A transformation rule in ATL may be fully declarative, hybrid, or fully imperative. The LHS of a fully declarative rule (so-called source pattern) consists of a set of syntactically typed variables with an optional OCL constraint as a filter or navigation logic. The RHS of a fully declarative rule (so-called target pattern) contains a set of variables and some declarative logic to bind the values of the attributes in the target elements. In a hybrid rule, the source or target patterns are complemented with a block of imperative logic, which is run after the application of the target pattern. A fully imperative rule (so-called procedure) has a name, a set of formal parameters, and an imperative block, but no patterns. Rules are unidirectional and support rule inheritance.

Other approaches

Two more approaches are mentioned for completeness: transformation implemented using Extensible Stylesheet Language Transformation (XSLT (81)) and the application of metaprogramming to model transformation.

Because models can be serialized as Extensible Markup Language (XML) using the XML Metadata Interchange (XMI **), (82) implementing model transformations using XSLT, which is a standard technology for transforming XML, seems very attractive. Such an approach can be classified as term rewriting using a functional language. Unfortunately, the use of XMI and XSLT has scalability limitations. Manual implementation of model transformations in XSLT quickly leads to non-maintainable implementations because of the verbosity and poor readability of XMI and XSLT. A solution is to generate the XSLT rules from some more declarative rule descriptions, as demonstrated in the work by Peltier et al. (83,84); however, even this approach suffers from poor efficiency because of the copying required by the pass-by-value semantics of XSLT and the poor compactness of XMI.

A more promising direction in applying traditional metaprogramming techniques to model transformations has been proposed by Tratt. (37) His solution is a domain-specific language for model transformations embedded in a metaprogramming language.

DISCUSSION

In this section, we comment on the practical applicability of the different types of model transformation. These comments are based on our intuition and the application examples published together with the approaches. Because of the lack of controlled experiments and extensive practical experience, these comments are not fully validated, but we hope that they will stimulate discussion and further evaluation.

Direct manipulation is obviously the most low-level approach. In its basic form, it offers the user little or no support or guidance in implementing transformations. Essentially, all work has to be done by the user. The approach can be improved by adding specialized libraries and frameworks implementing facilities such as pattern matching and tracing. Operational approaches are similar to direct ones except that they offer an executable metamodeling formalism through a dedicated language. Providing specialized facilities through libraries and frameworks seems to be an attractive way to improve the support for model transformations in an evolutionary way.

The structure-driven category covers pragmatic approaches that were developed in the context of (and seem to apply particularly well to) certain kinds of applications such as generating Enterprise JavaBeans ** (EJB **) implementations and database schemas from UML models. These applications require strong support for transforming models with a 1-to-1 and 1-to-n (and sometimes n-to-1) correspondence between source and target elements. Also, in this application context, there is typically no need for iteration (and in particular fixpointing) in scheduling, which can be system-defined. It is unclear how well these approaches can support other kinds of applications.

Template-based approaches make it easy for the developer to predict the resulting code or models just by looking at the templates. They also support iterative development in which the developer can start with a sample model or code and turn it into a template. Current template-based approaches do not have built-in support for tracing, although trace information can be easily encoded in the templates. Templates are particularly useful in code generation and model compilation scenarios.

Relational approaches seem to strike a good balance between flexibility and declarative expression. They can provide multidirectionality and incrementality, including the update of a manually modified target. On the other hand, their power is contingent on the sophistication of the underlying constraint-solving facilities. As a result, performance strongly depends on the kinds of constraints that need to be solved, which may limit their applicability. In any case, relational approaches seem to be most applicable to model synchronization scenarios.