Feature-based survey of model transformation approaches.

INTRODUCTION

Model-driven software development is centered on the use of models. (1) Models are system abstractions that allow developers and other stakeholders to effectively address concerns, such as answering a question about the system or effecting a change. Examples of model-driven approaches are Model Driven Architecture ** (MDA **), (2,3) Model-Integrated Computing (MIC), (4) and Software Factories. (5) Software Factories, with their focus on automating product development in a product-line context, can also be viewed as an instance of generative software development. (6)

Model transformations are touted to play a key role in Model Driven Development ** (MDD **). Their intended applications include the following:

[] Generating lower-level models, and eventually code, from higher-level models (7)

[] Mapping and synchronizing among models at the same level or different levels of abstraction (8)

[] Creating query-based views of a system (9,10)

[] Model evolution tasks such as model refactoring (11,12)

[] Reverse engineering of higher-level models from lower-level models or code. (13)

Considerable interest in model transformations has been generated by the standardization effort of the Object Management Group, Inc. (OMG **). In April 2002, the OMG issued a Request for Proposal (RFP) on Query/Views/Transformations (QVT), (14) which led to the release of the final adopted QVT specification in November 2005. (15) Driven by practical needs and the OMG's request, a large number of approaches to model transformation have been proposed over the last three years. However, as of this writing, industrial-strength and mature model-to-model transformation systems are still not available, and the area of model transformation continues to be a subject of intense research. In this paper, we propose a feature model to compare different model transformation approaches and offer a survey and categorization of a number of existing approaches from four sources:

1. Published in the literature--VIATRA (Visual Automated model TRAnsformations) framework, (16,17) Kent Model Transformation language (18,19) Tefkat, (20,21) GReAT (Graph Rewriting and Transformation language (22)), ATL (Atlas Transformation Language (23,24)), UMLX, (25) AToM3 (A Tool for Multi-formalism and Meta-Modeling (26), BOTL (Bidirectional Object-oriented Transformation Language (27,28)), MOLA (MOdel transformation LAnguage (29)), AGG (Attributed Graph Grammar system (30), AMW (Atlas Model-Weaver (31)), triple-graph grammars, (32) MTL (Model Transformation Language (33)), YATL (Yet Another Transformation Language (34)), Kermeta, (35) C-SAW (Constraint-Specification Aspect Weaver), (36) and MT Model Transformation Language. (37)

2. Described in the final adopted QVT specification--The Core, Relations, and Operational languages. (15) Older QVT submissions are also mentioned whenever appropriate.

3. Implemented within open-source tools--Andro-MDA, (38) openArchitectureWare, (39) Fujaba (From UML ** to Java ** And Back Again (40)), Jamda (JAva Model Driven Architecture (41), JET (Java Emitter Templates (42)), FUUT-je, (43) and MTF (Model Transformation Framework (44), which is a freely available prototype.

4. Implemented within commercial tools--XMF-Mosaic, (45) OptimalJ **, (46) MetaEdit+ ** (47,48) ArcStyler, (49) and Codagen Architect. 50

The feature model makes explicit the possible design choices for a model transformation approach, which is the main contribution of this paper. We do not give detailed classification data for each individual approach mainly because these details are constantly changing. Instead, we give examples of approaches for each design choice. Furthermore, we propose a clustering of existing approaches into a few major categories that capture their main characteristics and design choices. We conclude with remarks on the practical applicability of the different categories.

WHAT IS MODEL TRANSFORMATION?

Transformation is a fundamental theme in computer science and software engineering. After all, computation can be viewed as data transformation. Computing with basic data such as numeric values and with data structures such as lists and trees is at the heart of programming. Type systems in programming languages help ensure that operations are applied compatibly to the data. However, when the subject of a transformation approach is metadata, i.e., data representing software artifacts such as data schemas, programs, interfaces, and models, then we enter the realm of metaprogramming--writing programs called metaprograms that write or manipulate other programs. One of the key challenges in this realm is that metaprograms have to respect the rich semantics of the metadata upon which they operate. Similarly, model transformation is a form of metaprogramming and, thus, must face the same challenge.

Model transformation is closely related to program transformation. (51) In fact, their boundaries are not clear-cut, and both approaches overlap. Their differences occur in the mindsets and traditions of their respective transformation communities, the subjects being transformed, and the sets of requirements being considered. Program transformation is a more mature field with a strong programming language tradition. On the other hand, model transformation is a relatively new field, essentially rooted in software engineering. Consequently, the transformation approaches found in both fields have quite different characteristics. While program transformation systems are typically based on mathematically oriented concepts such as term rewriting, attribute grammars, and functional programming, model transformation systems usually adopt an object-oriented approach for representing and manipulating their subject models.

Because model transformations operate on models, we need to clarify what models are. A model is an abstraction of a system or its environment, or both. In software engineering, the term model is often used to refer to abstractions above program code, such as requirements and design specifications. Some authors in model-driven software development consider program code as models too. This view is consistent with the fact that program code is an abstraction of the underlying machine code produced by the compiler. Although being visual is not a defining characteristic of models, requirements and design models are often more visual than programs. Models are frequently expressed in focused languages specialized for a particular class of software applications or a particular aspect of an application. For example, the Matlab ** Simulink **/ Stateflow ** environment offers notations specialized for modeling control software, whereas interaction diagrams in Unified Modeling Language ** (UML **) are focused on representing the interaction aspect of a wide range of systems. Highly specialized modeling languages are increasingly referred to as domain-specific modeling languages.

In general, model transformations involve models (in the sense of abstractions above program code) or models and programs. Because the concept of models is more general than the concept of program code, model transformations tend to operate on a more diverse set of artifacts than program transformations. Model transformation literature considers a broad range of software development artifacts as potential transformation subjects. These include UML models, interface specifications, data schemas, component descriptors, and program code. The varied nature of models further invites specialized transformation approaches that are geared to transforming particular kinds of models. For example, as explained later in the discussion section, most model transformation approaches based on graph transformations are better suited for transforming UML models than program code. However, there is no fundamental reason why program transformation systems could not be applied to the same artifacts as model transformations. In fact, transformational software development, (52) which involves the automated refinement of high-level specifications into implementations, is an old and familiar theme in the area of program transformation.

In summation, perhaps the most important distinction between the current approaches to program transformation and model transformation is that the latter has been targeted for a particular set of requirements that include the representation of models using an object-oriented paradigm, the traceability among models at different levels of abstraction, the transformation mapping among multiple models (i.e., n-way transformations), and the multidirectionality of transformations. Although these requirements could also be the subject of program transformation approaches, they are typically not considered by program transformation systems.

EXAMPLES OF MODEL TRANSFORMATIONS

To make our discussion more concrete, we present two examples of model transformations: one that maps models to models and another that maps models to code.

Figure 1 gives an overview of the main concepts involved in model transformation. The figure shows the simple scenario of a transformation with one input (source) model and one output (target) model. Both models conform to their respective metamodels. A metamodel typically defines the abstract syntax of a modeling notation. A transformation is defined with respect to the metamodels. The definition is executed on concrete models by a transformation engine. In general, a transformation may have multiple source and target models. Furthermore, the source and target metamodels may be the same in some situations.

[FIGURE 1 OMITTED]

Sample metamodels and models