Feature-based survey of model transformation approaches.

The execution of a rule may require the creation of some additional intermediate structures (see Figure 4A) which are not part of the models being transformed. These structures are often temporary and require their own metamodel. A particular example of intermediate structures are traceability links. In contrast to other intermediate structures, traceability links are usually persisted. Even if traceability links are not persisted, some approaches, such as AGG and VIATRA, rely on them to prevent multiple "firings" of a rule for the same input element.

Parameterization

The simplest kind of parameterization is the use of control parameters that allow passing values as control flags (Figure 7). Control parameters are useful for implementing policies. For example, a transformation from class models to relational schemas could have a control parameter specifying which of the alternative patterns of object-relational mapping should be used in a given execution. (7) Generics allow passing data types, including model element types, as parameters. Generics can help make transformation rules more reusable. Generic transformations have been described by Varro and Pataricza. (17) Finally, higher-order rules take other rules as parameters and may provide even higher levels of reuse and abstraction. Stratego (64) is an example of a term rewriting language for program transformation supporting higher-order rules. We are currently not aware of any model transformation approaches with a first class support for higher-order rules.

[FIGURE 7 OMITTED]

Reflection and aspects

Some authors advocate the support for reflection and aspects (Figure 4) in transformation languages. Reflection is supported in ATL by allowing reflective access to transformation rules during the execution of transformations. An aspect-oriented extension of MTL was proposed by Silaghi et al. (65) Reflection and aspects can be used to express concerns that crosscut several rules, such as custom traceability management policies. (66)

Rule application control: Location determination

A rule needs to be applied to a specific location within its source scope. As there may be more than one match for a rule within a given source scope, we need a strategy for determining the application locations (Figure 8A). The strategy could be deterministic, nondeterministic, or interactive. For example, a deterministic strategy could exploit some standard traversal strategy (such as depth first) over the containment hierarchy in the source. Stratego (64) is an example of a term rewriting language with a rich mechanism for expressing traversal in tree structures. Examples of nondeterministic strategies include one-point application, where a rule is applied to one nondeterministically selected location, and concurrent application, where one rule is applied concurrently to all matching locations in the source. Concurrent application is supported in ATOM3, AGG, and VIATRA. AGG offers critical pair analysis to verify for a set of rules that there will be no rules competing for the same source location. Some tools, such as ATOM3, allow the user to determine the location for rule application interactively.

[FIGURE 8 OMITTED]

The target location for a rule is usually deterministic. In an approach with separate source and target models, traceability links can be used to determine the target: A rule may follow the traceability link to a target element that was created by another rule and use the element as its own target. In the case of in-place update, the source location becomes the target location, although traceability links can also be used (as later illustrated in Figure 10).

Rule application control: Rule scheduling

Scheduling mechanisms determine the order in which individual rules are applied. Scheduling mechanisms can vary in four main areas (Figure 8B).

1. Form--The scheduling aspect can be expressed implicitly or explicitly. Implicit scheduling implies that the user has no explicit control over the scheduling algorithm defined by the tool, as in BOTL. The only way a user can influence the system-defined scheduling algorithm is by designing the patterns and logic of the rules to ensure certain execution orders. For example, a given rule could check for some information that only some other rule would produce. Explicit scheduling has dedicated constructs to explicitly control the execution order. Explicit scheduling can be internal or external. In external scheduling, there is a clear separation between the rules and the scheduling logic. For example, VIATRA offers rule scheduling by an external finite state machine. In contrast, internal scheduling is a mechanism allowing a transformation rule to directly invoke other rules, as in ATL or the code template shown in Example 3.

2. Rule selection--Rules can be selected by an explicit condition, as in MOLA. Some approaches, such as BOTL, offer a nondeterministic choice. Alternatively, a conflict resolution mechanism based on priorities can be provided. Interactive rule selection is also possible. Both priorities and interactive selection are supported in ATOM3.

3. Rule iteration--Rule iteration mechanisms include recursion, looping, and fixpoint iteration (i.e., repeated application until no changes are detected). For example, ATL supports recursion, MOLA has a looping construct, and VIATRA supports fixpoint iteration.

4. Phasing--The transformation process may be organized into several phases, with each phase having a specific purpose, and only certain rules can be invoked in a given phase. For example, structure-oriented approaches, such as OptimalJ and the QVT submission by Interactive Objects and partners, (67) have a separate phase to create the containment hierarchy of the target model and a separate phase to set the attributes and references in the target (see the "Structure-driven approaches" section).

Rule organization

Rule organization is concerned with composing and structuring multiple transformation rules. We consider three areas of variation in this context (Figure 8C):

1. Modularity mechanisms--Some approaches (e.g., QVT, ATL, MTL, and VIATRA) allow packaging rules into modules. A module can import another module to access its content.

2. Reuse mechanisms--Reuse mechanisms offer a way to define a rule based on one or more other rules. In general, scheduling mechanisms, such as calling one rule from another, can be used to define composite transformation rules. However, some approaches offer dedicated reuse mechanisms, such as inheritance between rules (e.g., rule inheritance, (68) derivation, (67) extension, (69) and specialization (59)), inheritance between modules (e.g., unit inheritance (68)), and logical composition. (59)

3. Organizational structure--Rules may be organized according to the structure of the source language (as in attribute grammars, where actions are attached to the elements of the source language) or the target language, or they may have their own independent organization. An example of the organization according to the structure of the target is the QVT submission by Interactive Objects and partners. (67) In this approach, there is one rule for each target element type and the rules are nested according to the containment hierarchy in the target metamodel. For example, if the target language has a package construct in which classes can be nested, the rule for creating packages will contain the rule for creating classes (which will contain rules for creating attributes and methods).

Source-target relationship

Some approaches, such as ATL, mandate the creation of a new target model that has to be separate from the source (Figure 8D). However, in-place transformation can be simulated in ATL through an automatic copy mechanism. In some other approaches, such as VIATRA and AGG, source and target are always the same model; that is, they only support in-place update. Yet other approaches, for example, QVT Relations and MTF, allow creating a new model or updating an existing one. QVT Relations also support in-place update. Furthermore, an approach could allow a destructive update of the existing target or an update by extension only, that is, where existing model elements cannot be removed. Approaches using nondeterministic selection and fixpoint iteration scheduling (see "Rule Scheduling" section earlier) may restrict in-place update to extension in order to ensure termination. Alternatively, transformation rules may be organized into an expansion phase followed by a contraction phase, which is often done in graph transformation systems such as AGG.

Incrementality

Incrementality involves three different features (Figure 8E):

1. Target incrementality--The basic feature of all incremental transformations is target-incrementality, that is, the ability to update existing target models based on changes in the source models. This basic feature is also referred to as change propagation in the QVT final adopted specification. (15) Obviously, target incrementality corresponds to the feature update in Figure 8D, but it is now seen from the change-propagation perspective. A target-incremental transformation creates the target models if they are missing on the first execution. A subsequent execution with the same source models as in the previous execution has to detect that the needed target elements already exist. This detection can be achieved, for example, by using traceability links. When any of the source models are modified and the transformation is executed again, the necessary changes to the target are determined and applied. At the same time, the target elements that can be preserved are preserved.