Feature-based survey of approaches

&

Model transformations are touted to play a key role in Model Driven Developmente. Although well-established standards for creating metamodels such as the Meta-Object Facility exist, there is currently no mature foundation for specifying transformations K. Czarnecki among models. We propose a framework for the classification of several existing and S. Helsen proposed model transformation approaches. The classification framework is given as a feature model that makes explicit the different design choices for model transforma- tions. Based on our analysis of model transformation approaches, we propose a few major categories in which most approaches fit.

9,10 INTRODUCTION Creating query-based views of a system Model-driven software development is centered on Model evolution tasks such as model refactor- 1 11,12 the use of models. Models are system abstractions ing that allow developers and other stakeholders to Reverse engineering of higher-level models from 13 effectively address concerns, such as answering a lower-level models or code. question about the system or effecting a change. Examples of model-driven approaches are Model Considerable interest in model transformations has 2,3 Driven Architecture** (MDA**), Model-Inte- been generated by the standardization effort of the 4 5 Object Management Group, Inc. (OMG**). In April grated Computing (MIC), and Software Factories. 2002, the OMG issued a Request for Proposal (RFP) Software Factories, with their focus on automating 14 on Query/Views/Transformations (QVT), which product development in a product-line context, can led to the release of the final adopted QVT also be viewed as an instance of generative software 15 6 specification in November 2005. Driven by prac- development. tical needs and the OMG’s request, a large number Model transformations are touted to play a key role of approaches to model transformation have been in Model Driven Development** (MDD**). Their proposed over the last three years. However, as of intended applications include the following: ÓCopyright 2006 by International Business Machines Corporation. Copying in Generating lower-level models, and eventually printed form for private use is permitted without payment of royalty provided 7 that (1) each reproduction is done without alteration and (2) the Journal code, from higher-level models reference and IBM copyright notice are included on the first page. The title and abstract, but no other portions, of this paper may be copied or distributed Mapping and synchronizing among models at the royalty free without further permission by -based and other 8 information-service systems. Permission to republish any other portion of the same level or different levels of abstraction paper must be obtained from the Editor. 0018-8670/06/$5.00 Ó 2006 IBM

IBM SYSTEMS JOURNAL, VOL 45, NO 3, 2006 CZARNECKI AND HELSEN 621 this writing, industrial-strength and mature model- WHAT IS MODEL TRANSFORMATION? to-model transformation systems are still not avail- Transformation is a fundamental theme in computer able, and the area of model transformation contin- science and software engineering. After all, compu- ues to be a subject of intense research. In this paper, tation can be viewed as data transformation. we propose a feature model to compare different Computing with basic data such as numeric values model transformation approaches and offer a survey and with data structures such as lists and trees is at and categorization of a number of existing ap- the heart of programming. Type systems in pro- proaches from four sources: gramming languages help ensure that operations are applied compatibly to the data. However, when the 1. Published in the literature—VIATRA (VIsual subject of a transformation approach is metadata, Automated model TRAnsformations) frame- i.e., data representing software artifacts such as data 16,17 work, Kent Model Transformation lan- schemas, programs, interfaces, and models, then we 18,19 20,21 guage, Tefkat, GReAT (Graph Rewriting enter the realm of metaprogramming—writing pro- 22 and ), ATL (Atlas grams called metaprograms that write or manipulate 23,24 25 Transformation Language ), UMLX, AToM3 other programs. One of the key challenges in this (A Tool for Multi-formalism and Meta-Model- realm is that metaprograms have to respect the rich 26 ing ), BOTL (Bidirectional Object-oriented semantics of the metadata upon which they operate. 27,28 Transformation Language ), MOLA (MOdel Similarly, model transformation is a form of 29 transformation LAnguage ), AGG (Attributed metaprogramming and, thus, must face the same 30 Graph Grammar system ), AMW (Atlas Model- challenge. 31 32 Weaver ), triple-graph grammars, MTL (Model 33 Model transformation is closely related to program Transformation Language ), YATL (Yet Another 51 34 35 transformation. In fact, their boundaries are not Transformation Language ), , C-SAW 36 clear-cut, and both approaches overlap. Their (Constraint-Specification Aspect Weaver), and 37 differences occur in the mindsets and traditions of MT Model Transformation Language. their respective transformation communities, the 2. Described in the final adopted QVT specifica- subjects being transformed, and the sets of require- tion—The Core, Relations, and Operational lan- 15 ments being considered. Program transformation is guages. Older QVT submissions are also a more mature field with a strong programming mentioned whenever appropriate. language tradition. On the other hand, model 3. Implemented within open-source tools—Andro- 38 39 transformation is a relatively new field, essentially MDA, openArchitectureWare, Fujaba (From 40 rooted in software engineering. Consequently, the UML** to ** And Back Again ), Jamda 41 transformation approaches found in both fields have (JAva Model Driven Architecture ), JET (Java 42 43 quite different characteristics. While program Emitter Templates ), FUUT-je, and MTF 44 transformation systems are typically based on (Model Transformation Framework ), which is a mathematically oriented concepts such as term freely available prototype. rewriting, attribute grammars, and functional pro- 4. Implemented within commercial tools—XMF-Mo- 45 46 47,48 gramming, model transformation systems usually saic, OptimalJ**, MetaEditþ**, ArcSty- 49 50 adopt an object-oriented approach for representing ler, and Codagen Architect. and manipulating their subject models.

The feature model makes explicit the possible design Because model transformations operate on models, choices for a model transformation approach, which we need to clarify what models are. A model is an is the main contribution of this paper. We do not abstraction of a system or its environment, or both. give detailed classification data for each individual In software engineering, the term model is often approach mainly because these details are con- used to refer to abstractions above program code, stantly changing. Instead, we give examples of such as requirements and design specifications. approaches for each design choice. Furthermore, we Some authors in model-driven software develop- propose a clustering of existing approaches into a ment consider program code as models too. This few major categories that capture their main view is consistent with the fact that program code is characteristics and design choices. We conclude an abstraction of the underlying machine code with remarks on the practical applicability of the produced by the compiler. Although being visual is different categories. not a defining characteristic of models, requirements

622 CZARNECKI AND HELSEN IBM SYSTEMS JOURNAL, VOL 45, NO 3, 2006 Refers to Refers to Source Metamodel Transformation Definition Target Metamodel

Conforms to Executes Conforms to Reads Writes Source Model Transformation Target Model Engine

Figure 1 Basic concepts of model transformation

and design models are often more visual than latter has been targeted for a particular set of programs. Models are frequently expressed in requirements that include the representation of focused languages specialized for a particular class models using an object-oriented paradigm, the of software applications or a particular aspect of an traceability among models at different levels of application. For example, the Matlab** Simulink**/ abstraction, the transformation mapping among Stateflow** environment offers notations special- multiple models (i.e., n-way transformations), and ized for modeling control software, whereas inter- the multidirectionality of transformations. Although action diagrams in Unified Modeling Language** these requirements could also be the subject of (UML**) are focused on representing the interaction program transformation approaches, they are typi- aspect of a wide range of systems. Highly special- cally not considered by program transformation ized modeling languages are increasingly referred to systems. as domain-specific modeling languages. EXAMPLES OF MODEL TRANSFORMATIONS In general, model transformations involve models To make our discussion more concrete, we present (in the sense of abstractions above program code) or two examples of model transformations: one that models and programs. Because the concept of maps models to models and another that maps models is more general than the concept of program models to code. code, model transformations tend to operate on a more diverse set of artifacts than program trans- Figure 1 gives an overview of the main concepts formations. Model transformation literature consid- involved in model transformation. The figure shows ers a broad range of software development artifacts the simple scenario of a transformation with one as potential transformation subjects. These include input (source) model and one output (target) model. UML models, interface specifications, data schemas, Both models conform to their respective metamod- component descriptors, and program code. The els. A metamodel typically defines the abstract varied nature of models further invites specialized syntax of a modeling notation. A transformation is transformation approaches that are geared to trans- defined with respect to the metamodels. The forming particular kinds of models. For example, as definition is executed on concrete models by a explained later in the discussion section, most transformation engine. In general, a transformation model transformation approaches based on graph may have multiple source and target models. transformations are better suited for transforming Furthermore, the source and target metamodels may UML models than program code. However, there is be the same in some situations. no fundamental reason why program transforma- Sample metamodels and models tion systems could not be applied to the same Figures 2A and 2B show sample metamodels artifacts as model transformations. In fact, trans- expressed as UML class diagrams. Figure 2A gives a 52 formational software development, which in- simplified metamodel for class models that includes volves the automated refinement of high-level the abstract concept of classifiers, which comprises specifications into implementations, is an old and classes and primitive data types. Packages contain familiar theme in the area of program transforma- classes, and classes contain attributes. All model tion. elements have names, and classes can be marked as In summation, perhaps the most important distinc- persistent. Figure 2B shows a simple metamodel for tion between the current approaches to program defining relational database schemas for a relational transformation and model transformation is that the database management system (RDBMS). A schema

IBM SYSTEMS JOURNAL, VOL 45, NO 3, 2006 CZARNECKI AND HELSEN 623 A Simple UML metamodel contains tables, and tables contain columns. The column type is represented as a string. Every table Classifier type has one primary-key column, which is pointed to by PrimitiveDataType name : String 1 pkey. Additionally, the concept of foreign keys is modeled by FKey, which relates foreign-key columns to tables. * Package Class Attribute * * Sample instances of the metamodels using the UML name : String elems isPersistent : Bool attrs name : String object diagram notation are shown in Figures 2C and 2D. The instance in Figure 2C represents a class model with one package, App, containing two B Simple RDBMS metamodel classes, Customer and Address. Customer is persis- 0..1 1 tent, and Address is not. Figure 2D shows an Schema Table Column * pkey instance of the schema metamodel. The instance name : String tbls name : String * name : String represents a schema that can be used to make cols type : String * refs Customer objects persistent. * fkeys * cols UML-to-schema transformation FKey As a first example, we consider transforming class models into schema models described in the previous section. Such a transformation needs to realize the following three mappings: C UML sample model 1. Package-to-schema: Every package in the class :Package :Class :Attribute model should be mapped to a schema with the name = 'App' name = 'Customer' name = 'name' same name as the package. isPersistent = true 2. Class-to-table: Every persistent class should be mapped to a table with the same name as the class. Furthermore, the table should have a :Attribute :Class :Attribute primary-key column with the type NUMBER and the name = 'Address' name = 'addr' name = 'addln' _tid isPersistent = false type name being the class name with appended. 3. Attribute-to-column—The class attributes have to be appropriately mapped to columns, and some

:PrimitiveDataType columns may need to be related to other tables by foreign key definitions. For simplicity, the attri- typename = 'STRING' type bute mapping is not further considered in this paper.

D RDBMS sample model The above transformation would map the class model in Figure 2C to the schema model in Figure :Schema :Table :Column 2D. The part of the result in Figure 2D shown in name = 'App' name = 'Customer' name = 'name' green (lefthand and middle boxes) is handled by the type = 'STRING' first two mappings. The blue part (righthand boxes) corresponds to the result of the attribute-to-column pkey mapping. :Column :Column Transformations expressed in QVT Relations name = 'Customer_tid' name = 'addrln' type = 'NUMBER' type = 'STRING' language Example 1 shows how this transformation can be expressed using the QVT Relations language, which Figure 2 UML-to-RDBMS example and sample models: (A) Simple is a declarative language for model-to-model trans- UML metamodel, (B) Simple RDBMS metamodel, formations. The language has both a textual and a (C) UML sample model, and (D) RDBMS sample model graphical representation, but only the textual representation is shown here. The transformation

624 CZARNECKI AND HELSEN IBM SYSTEMS JOURNAL, VOL 45, NO 3, 2006 declaration specifies two parameters for holding the bound to a model (e.g., uml) and declares a pattern, models involved in the transformation. The param- which will be bound with elements from the model eters are typed over the appropriate metamodels. to which the domain is bound. Such patterns consist The execution direction is not fixed at transforma- of a variable and a type declaration, which itself tion definition time, which means that both uml and may specify some of the properties of that type. rdbms could be source and target models and vice When the transformation is executed, the relations versa. The user specifies the direction in which the are verified and, if necessary, enforced by manipu- transformation has to be executed only upon lating the target model. If the target model is empty, invoking the transformation. its content is freshly created; otherwise, the existing content is updated. Example 1 A relation may specify a condition under which it transformation umlRdbms f applies by using a when clause. The where clause uml : SimpleUML, rdbms : SimpleRDBMS) f specifies additional constraints among the involved key Table (name, schema); elements, which may need to be enforced. The key key Column (name, table); definitions are used by the transformation engine to identify objects that need to be updated during a top relation PackageToSchema f transformation execution. There is much more to domain uml p:Package fname ¼ png say about the execution semantics of QVT Relations, domain rdbms s:Schema fname ¼ png and the interested reader is invited to explore the g 15 QVT specification document.

top relation ClassToTable f UML-to-Java transformation domain uml c:Class f In this example, we consider the generation of Java package ¼ p:Package fg, code from class models conforming to the meta- isPersistent ¼ true, model in Figure 2A. In particular, a Java class with name ¼ cn the appropriate attribute definitions and getters and g setters should be generated for each class in the domain rdbms t:Table f class model. Example 2 shows the desired output for schema ¼ s:Schema fg, the input model from Figure 2C. name ¼ cn, cols ¼ cl:Column f Example 2 name¼cnþ0_tid0, public class Customer type¼0NUMBER0g, f private String name; pkey ¼ cl private Address addr; g when f PackageToSchema (p, s); public void setName ( String name ) f this.name name; g ¼ where f g AttributeToColumn (c, t); public String getName () g f return this.name; g g

relation AttributeToColumn f ... public void setAddr ( String addr ) f g this.addr ¼ addr; ... g g public String getAddr () f Each mapping is represented as a relation. A relation return this.addr; has as many domain declarations as there are g models involved in the transformation. A domain is g

IBM SYSTEMS JOURNAL, VOL 45, NO 3, 2006 CZARNECKI AND HELSEN 625 Model Transformation

Specification Transform- Rule Rule Source-Target Incremen- Direction- Tracing ation Rules Application Organization Relationship tality ality Control

Location Scheduling Determinaton

Figure 3 Top-level feature diagram

The code can conveniently be generated using a analyzing and modeling the variabilities and com- textual template approach, such as the openArchi- monalities of systems or concepts in a given 53 tectureWare template language demonstrated in domain. We document our results using feature 54,55 Example 3. A template can be thought of as the diagrams. Essentially, a feature diagram is a target text with holes for variable parts. The holes hierarchy of common and variable features charac- contain metacode which is run at template instan- terizing the set of instances of a concept. In our case, tiation time to compute the variable parts. The the features provide a terminology and representa- metacode in Example 3 is underlined. It has facilities tion of the design choices for model transformation to iterate over the elements of the input model approaches. We do not aim for this terminology to (FOREACH), access the properties of the elements, be normative. Unfortunately, the relatively new area and call other templates (EXPAND). of model transformation has many overloaded terms, and many of the terms we use in our Example 3 terminology are often used with different meanings in the original descriptions of the different ap- ,,DEFINE Root FOR Class.. proaches. Consequently, we provide the definitions public class ,,name.. f of the terms as we use them. Furthermore, we ,,FOREACH attrs AS a.. expect the terminology to evolve as our under- private ,,a.type.name.. ,,a.name..; standing of model transformation matures. Our ,,ENDFOREACH.. main goal is to show the vast range of available ,,EXPAND AccessorMethods FOREACH attribute.. choices as represented by the current approaches. g ,,ENDDEFINE.. Figure 3 shows the top-level feature diagram, where each subnode represents a major point of variation. ,,DEFINE AccessorMethods FOR Attribute.. The fragment of the cardinality-based feature 56,57 public ,,type.name.. get,,name.toFirstUpper..() f modeling notation used in this paper is further return this.,,name..; explained in Table 1. Note that our feature diagrams g treat model-to-model and model-to-text approaches public void set,,name.toFirstUpper..( uniformly. We will distinguish between these ,,type.name.. ,,name.. ) f categories later in the ‘‘Major Categories’’ section. this.,,name.. ¼ ,,name.. The description of the top-level features in Figure 3 g follows. ,,ENDDEFINE.. Specification—Some transformation approaches FEATURES OF MODEL TRANSFORMATION provide a dedicated specification mechanism, APPROACHES such as preconditions and postconditions ex- 58 This section presents the results of applying domain pressed in Object Constraint Language (OCL). A analysis to existing model transformation ap- particular transformation specification may rep- proaches. Domain analysis is concerned with resent a function between source and target

626 CZARNECKI AND HELSEN IBM SYSTEMS JOURNAL, VOL 45, NO 3, 2006 models and be executable; however, in general, Table 1 Symbols used in cardinality-based feature specifications describe relations and are not modeling 59 executable. The QVT-Partners submission dis- Symbol Explanation tinguished between relations as potentially non- executable specifications of transformations and Solitary feature with cardinality their executable implementations. The QVT spec- F [1..1], i.e., mandatory feature 15 ification still keeps this distinction, although the Solitary feature with cardinality Relations language is now meant to be used F [0..1], i.e., optional feature primarily for expressing executable transforma- [n..m] Solitary feature with cardinality > >_ > >_ tions. F [n..m], n 0 m n m>1, Transformation rules—In this paper, transforma- i.e., mandatory clonable feature tion rules are understood as a broad term Grouped feature describing the smallest units of transformation. F Rewrite rules with a lefthand side (LHS) and a F Reference to feature model F righthand side (RHS) are obvious examples of transformation rules; however, we also consider a xor-group function or a procedure implementing some or-group transformation step as a transformation rule. In fact, the boundary between rules and functions is not so clear-cut; for example, function definitions Each of the following subsections elaborates on one in modern functional languages such as Haskell major area of variation represented as a reference in resemble rules with patterns on the left and Figure 3 by giving its feature diagram, describing the expressions on the right. Templates can be different choices, and providing examples of ap- considered as a degenerate form of rules, as proaches supporting a given feature. The diagrams discussed later in the ‘‘Template-Based Ap- remain at a certain level of detail to fit the available proaches’’ section. space; however, each feature could be further Rule application control—This has two aspects: analyzed uncovering additional subfeatures. Also, location determination and scheduling. Location the feature groups in the presented diagrams usually determination is the strategy for determining the express typical rather than all possible feature model locations to which transformation rules are combinations. For example, different language applied. Scheduling determines the order in which paradigms (see Figure 5B later) are organized into transformation rules are executed. Although con- an xor-group rather than an or-group (Table 1). trol mechanisms usually address both aspects at Hybrid approaches may always provide any combi- the same time, for presentation purposes, we nations of these features, which would correspond discuss them separately. to an or-group. Rule organization—This comprises general struc- turing issues, such as modularization and reuse Transformation rules mechanisms. The features of transformation rules are given in Source-target relationship—This is concerned with Figure 4A. Their descriptions follow. issues such as whether source and target are one and the same model or two different models. Incrementality—This refers to the ability to update Domains existing target models based on changes in the A domain is the part of a rule responsible for source models. accessing one of the models on which the rule Directionality—This describes whether a trans- operates. Rules usually have a source and a target formation can be executed in only one direction domain, but they may also involve more than two (unidirectional transformation) or multiple direc- domains. Transformations involving n domains are tions (multidirectional transformation). sometimes referred to as n-way transformations. 31 Tracing—This is concerned with the mechanisms Examples are model merging or model weaving, for recording different aspects of transformation which are transformations with more than one input execution, such as creating and maintaining trace domain. In general, a set of domains can also be links between source and target model elements. seen as one large composite domain; however, it is

IBM SYSTEMS JOURNAL, VOL 45, NO 3, 2006 CZARNECKI AND HELSEN 627 A Transformation Rules

[1..*]

Domain Syntactic Multidirection- Application Intermediate Parameterization Reflection Aspects Separation ality Conditions Structures

B Domain

Domain Static Dynamic Mode Body Typing Language Mode Restriction

Variables Patterns Logic In Out In/Out

Figure 4 Features of transformation rules: (A) rules and (B) domains

useful to distinguish among individual domains Static modes. Similar to the parameters of a proce- when writing transformations. dure, domains have explicitly declared or implicitly assumed static modes, such as in, out,orin/out. Domains can have different forms. In QVT Rela- Classical unidirectional rewrite rules with an LHS tions, a domain is a distinguished typed variable and RHS can be thought of as having an in-domain with an associated pattern that can be matched in a (source) and an out-domain (target), or a single in/ model of a given model type (Example 1). In a out-domain for in-place transformations. Multidi- rewrite rule, each side of the rule represents a rectional rules, such as in MTF, assume all domains domain. In an implementation of a rule as an to be in/out. imperative procedure, a domain corresponds to a parameter and the code that navigates or creates Dynamic mode restriction. Some approaches allow model elements by using the parameter as an entry dynamic mode restriction—restricting the static point. Furthermore, a rule may combine domains of modes at execution time. For example, MTF allows different forms. For example, the source domain of marking any of the participating in/out-domains as the templates in Example 3 is captured by the read-only, that is, restricting them to in for a metacode, whereas the target domain has the form particular execution of a transformation. Essentially, of string patterns. such restrictions define the execution direction.

The features of a domain are shown in Figure 4B Body. There are three subcategories under Body, variables, patterns, and logic: and described in the following subsections:

Domain languages. A domain has an associated Variables may hold elements from the source and/ domain language specification that describes the or target models (or some intermediate elements). possible structures of the models for that domain. In They are sometimes referred to as metavariables the context of MDA, that specification has the form to distinguish them from variables that may be of a metamodel expressed in the Meta Object Facility part of the models being transformed (e.g., Java 60 (MOF**). Transformations with source and target variables in transformed Java programs). domains conforming to a single metamodel are Patterns are model fragments with zero or more referred to as endogenous or rephrasings, whereas variables. Sometimes, such as in the case of transformations with different source and target templates, patterns can have not only variables metamodels are referred to as exogenous or embedded in their body, but also expressions and 61,62 translations. statements of the metalanguage. Depending on the

628 CZARNECKI AND HELSEN IBM SYSTEMS JOURNAL, VOL 45, NO 3, 2006 A Patterns

Structure Syntax

Strings Terms Graphs Abstract Concrete

Textual Graphical

B Logic

Language Value Element Paradigm Specification Creation

Object-Oriented Functional Logic Procedural Imperative Value Constraint Implicit Explicit Assignment Binding

Figure 5 Features of the body of a domain: (A) patterns and (B) logic

63 internal representation of the models being trans- (JMI) provides a Java API to access models in a formed, we can have string, term, or graph MOF repository. Imperative code uses imperative patterns (Figure 5A). String patterns are used in assignment, whereas declarative approaches may textual templates, as discussed later in the bind values to variables, as in functional pro- ‘‘Template-Based Approaches’’ section. Model-to- gramming, or specify values through constraints. model transformations usually apply term or graph patterns. Patterns can be represented using Typing. The typing of variables, logic, and patterns the abstract or concrete syntax of the corre- can be untyped, syntactically typed, or semantically sponding source or target model language, and the typed (Figure 6). Textual templates are examples of syntax can be textual or graphical. untyped patterns (see the ‘‘Template-Based Ap- Logic expresses computations and constraints on proaches’’ section). In the case of syntactic typing, a model elements (Figure 5B). Logic may follow variable is associated with a metamodel element different programming paradigms such as object- whose instances it can hold. Semantic typing allows oriented or functional and be nonexecutable or stronger properties to be asserted, such as well- executable. Nonexecutable logic is used to specify formedness rules (static semantics) and behavioral relationships among models. Executable logic can properties (dynamic semantics). A type system for a take a declarative or imperative form. Examples of transformation language could statically ensure for a the declarative form include OCL queries to transformation that the models produced by the retrieve elements from the source model and the transformation will satisfy a certain set of syntactic implicit creation of target elements through con- and semantic properties, provided the input models straints, as in the QVT Relations and Core satisfy some syntactic and semantic properties. languages. Imperative logic often has the form of program code calling repository application pro- Syntactic separation gramming interfaces (APIs) to manipulate models Some approaches offer syntactic separation (see directly. For instance, the Java Metadata Interface Figure 4A). They clearly separate the parts of a rule

IBM SYSTEMS JOURNAL, VOL 45, NO 3, 2006 CZARNECKI AND HELSEN 629 Typing multiple ‘‘firings’’ of a rule for the same input element.

Untyped Syntactically Typed Semantically Typed Parameterization The simplest kind of parameterization is the use of Figure 6 control parameters that allow passing values as Typing 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 Parameterization which of the alternative patterns of object-relational 7 mapping should be used in a given execution. Generics allow passing data types, including model Control Parameters Generics Higher-Order Rules element types, as parameters. Generics can help make transformation rules more reusable. Generic Figure 7 transformations have been described by Varro´ and 17 Parameterization Pataricza. Finally, higher-order rules take other rules as parameters and may provide even higher 64 levels of reuse and abstraction. Stratego is an operating on one model from the parts operating on example of a term rewriting language for program other models. For example, classical rewrite rules transformation supporting higher-order rules. We have an LHS operating on the source model and an are currently not aware of any model transformation RHS operating on the target model. In other approaches with a first class support for higher- approaches, such as a rule implemented as a Java order rules. program, there might not be any such syntactic distinction. Reflection and aspects Some authors advocate the support for reflection Multidirectionality and aspects (Figure 4) in transformation languages. Multidirectionality refers to the ability to execute a Reflection is supported in ATL by allowing reflective rule in different directions (see Figure 4A). Rules access to transformation rules during the execution supporting multidirectionality are usually defined of transformations. An aspect-oriented extension of 65 over in/out-domains. Multidirectional rules are MTL was proposed by Silaghi et al. Reflection and available in MTF and QVT Relations. aspects can be used to express concerns that crosscut several rules, such as custom traceability 66 Application condition management policies. Transformation rules in some approaches may have an application condition (see Figure 4A) that must Rule application control: Location determination be true in order for the rule to be executed. An A rule needs to be applied to a specific location example is the when-clause in QVT Relations within its source scope. As there may be more than (Example 1). one match for a rule within a given source scope, we need a strategy for determining the application Intermediate structure locations (Figure 8A). The strategy could be The execution of a rule may require the creation of deterministic, nondeterministic,orinteractive. For some additional intermediate structures (see Figure example, a deterministic strategy could exploit some 4A) which are not part of the models being trans- standard traversal strategy (such as depth first) over 64 formed. These structures are often temporary and the containment hierarchy in the source. Stratego require their own metamodel. A particular example is an example of a term rewriting language with a of intermediate structures are traceability links. In rich mechanism for expressing traversal in tree contrast to other intermediate structures, trace- structures. Examples of nondeterministic strategies ability links are usually persisted. Even if trace- include one-point application, where a rule is ability links are not persisted, some approaches, applied to one nondeterministically selected loca- such as AGG and VIATRA, rely on them to prevent tion, and concurrent application, where one rule is

630 CZARNECKI AND HELSEN IBM SYSTEMS JOURNAL, VOL 45, NO 3, 2006 A Rule Application Strategy

Deterministic Non-Deterministic Interactive

Concurrent One-Point

B Rule Scheduling

Form Rule Selection Rule Iteration Phasing

Implicit Explicit Explicit Non- Conflict Interactive Recursion Looping Fixpoint Condition Deterministic Resolution Iteration

Internal External

c D Rule Organization Source-Target Relationship

Modularity Reuse Organizational New Target Existing Target Mechanisms Mechanisms Structure

Update In-Place Inheritance Logical Source- Target- Independent Composition Oriented Oriented Destructive Extension Only

E G Incrementality Tracing

Target-Incrementality Source-Incrementality Preservation of Dedicated Support User Edits in the Target Creation Storage Location

Manual Automatic Model Separate F Tunable Directionality Source Target

Unidirectional Multidirectional

Figure 8 Model transformation approach features: (A) location determination, (B) rule scheduling, (C) rule organization, (D) source-target relationship, (E) incrementality, (F) directionality, and (G) tracing

IBM SYSTEMS JOURNAL, VOL 45, NO 3, 2006 CZARNECKI AND HELSEN 631 applied concurrently to all matching locations in the priorities and interactive selection are supported source. Concurrent application is supported in in AToM3. AToM3, AGG, and VIATRA. AGG offers critical pair 3. Rule iteration—Rule iteration mechanisms in- analysis to verify for a set of rules that there will be clude recursion, looping, and fixpoint iteration no rules competing for the same source location. (i.e., repeated application until no changes are Some tools, such as AToM3, allow the user to detected). For example, ATL supports recursion, determine the location for rule application inter- MOLA has a looping construct, and VIATRA actively. supports fixpoint iteration. 4. Phasing—The transformation process may be The target location for a rule is usually determin- organized into several phases, with each phase istic. In an approach with separate source and target having a specific purpose, and only certain rules models, traceability links can be used to determine can be invoked in a given phase. For example, the target: A rule may follow the traceability link to structure-oriented approaches, such as OptimalJ and the QVT submission by Interactive Objects a target element that was created by another rule 67 and use the element as its own target. In the case of and partners, have a separate phase to create in-place update, the source location becomes the the containment hierarchy of the target model target location, although traceability links can also and a separate phase to set the attributes and be used (as later illustrated in Figure 10). references in the target (see the ‘‘Structure-driven approaches’’ section). Rule application control: Rule scheduling Scheduling mechanisms determine the order in Rule organization Rule organization is concerned with composing and which individual rules are applied. Scheduling structuring multiple transformation rules. We con- mechanisms can vary in four main areas sider three areas of variation in this context (Figure 8B). (Figure 8C): 1. Form—The scheduling aspect can be expressed 1. Modularity mechanisms—Some approaches (e.g., implicitly or explicitly. Implicit scheduling implies QVT, ATL, MTL, and VIATRA) allow packaging that the user has no explicit control over the rules into modules. A module can import another scheduling algorithm defined by the tool, as in module to access its content. BOTL. The only way a user can influence the 2. Reuse mechanisms—Reuse mechanisms offer a system-defined scheduling algorithm is by de- way to define a rule based on one or more other signing the patterns and logic of the rules to rules. In general, scheduling mechanisms, such ensure certain execution orders. For example, a as calling one rule from another, can be used to given rule could check for some information that define composite transformation rules. However, only some other rule would produce. Explicit some approaches offer dedicated reuse mecha- scheduling has dedicated constructs to explicitly nisms, such as inheritance between rules (e.g., 68 67 69 control the execution order. Explicit scheduling rule inheritance, derivation, extension, and 59 can be internal or external. In external schedul- specialization ), inheritance between modules 68 ing, there is a clear separation between the rules (e.g., unit inheritance ), and logical composi- 59 and the scheduling logic. For example, VIATRA tion. offers rule scheduling by an external finite state 3. Organizational structure—Rules may be orga- machine. In contrast, internal scheduling is a nized according to the structure of the source mechanism allowing a transformation rule to language (as in attribute grammars, where directly invoke other rules, as in ATL or the code actions are attached to the elements of the source template shown in Example 3. language) or the target language, or they may 2. Rule selection—Rules can be selected by an have their own independent organization. An explicit condition, as in MOLA. Some ap- example of the organization according to the proaches, such as BOTL, offer a nondeterministic structure of the target is the QVT submission by 67 choice. Alternatively, a conflict resolution mech- Interactive Objects and partners. In this ap- anism based on priorities can be provided. proach, there is one rule for each target element Interactive rule selection is also possible. Both type and the rules are nested according to the

632 CZARNECKI AND HELSEN IBM SYSTEMS JOURNAL, VOL 45, NO 3, 2006 containment hierarchy in the target metamodel. the transformation is executed again, the neces- For example, if the target language has a package sary changes to the target are determined and construct in which classes can be nested, the rule applied. At the same time, the target elements for creating packages will contain the rule for that can be preserved are preserved. creating classes (which will contain rules for 2. Source incrementality—Source incrementality is creating attributes and methods). about minimizing the amount of source that needs to be reexamined by a transformation Source-target relationship when the source is changed. Source incremen- Some approaches, such as ATL, mandate the tality corresponds to incremental compilation: A creation of a new target model that has to be change impact analysis determines the total set of separate from the source (Figure 8D). However, in- source modules that need to be recompiled based place transformation can be simulated in ATL on the list of source modules that were changed. through an automatic copy mechanism. In some Source incrementality is useful for working with other approaches, such as VIATRA and AGG, source large source models. and target are always the same model; that is, they 3. Preservation of user edits in the target—Practical only support in-place update. Yet other approaches, scenarios in the context of model synchronization for example, QVT Relations and MTF, allow creating require the ability to rerun a transformation on an a new model or updating an existing one. QVT existing user-modified target to resynchronize the Relations also support in-place update. Further- target with a changed source while preserving the more, an approach could allow a destructive update user edits in the target. The dimensions of model of the existing target or an update by extension only, synchronization, such as the degree of preserva- that is, where existing model elements cannot be tion of user-provided input in the target models, removed. Approaches using nondeterministic selec- the degree of automation, and the frequency of 57 tion and fixpoint iteration scheduling (see ‘‘Rule triggering, are discussed elsewhere. Scheduling’’ section earlier) may restrict in-place update to extension in order to ensure termination. Directionality Alternatively, transformation rules may be orga- Transformations may be unidirectional or multi- nized into an expansion phase followed by a directional (Figure 8F). Unidirectional transforma- contraction phase, which is often done in graph tions can be executed in one direction only, in which transformation systems such as AGG. case a target model is computed (or updated) based on a source model. Multidirectional transformations Incrementality can be executed in multiple directions, which is Incrementality involves three different features particularly useful in the context of model synchro- (Figure 8E): nization. Multidirectional transformations can be achieved using multidirectional rules or by defining 1. Target incrementality—The basic feature of all several separate complementary unidirectional incremental transformations is target-incremen- rules, one for each direction. tality, that is, the ability to update existing target models based on changes in the source models. Transformation rules usually have a functional This basic feature is also referred to as change character: Given some input in the source model, propagation in the QVT final adopted specifica- they produce a concrete result in the target model. A 15 tion. Obviously, target incrementality corre- declarative rule (i.e., one that only uses declarative sponds to the feature update in Figure 8D, but it logic or patterns) can often be applied in the inverse is now seen from the change-propagation per- direction, too. However, as different inputs may lead spective. A target-incremental transformation to the same output, the inverse of a rule may not be creates the target models if they are missing on a function. In this case, the inversion could the first execution. A subsequent execution with enumerate a number of possible solutions (this the same source models as in the previous could theoretically be infinite), or just establish a execution has to detect that the needed target part of the result in a concrete way (because the part elements already exist. This detection can be is the same for all solutions) and use variables, achieved, for example, by using traceability links. defaults, or values already present in the result for When any of the source models are modified and the rest of it. The invertibility of a transformation

IBM SYSTEMS JOURNAL, VOL 45, NO 3, 2006 CZARNECKI AND HELSEN 633 depends not only on the invertibility of the trans- target as an instance of the target metamodel, the formation rules, but also on the invertibility of the target of a model-to-text transformation is just scheduling logic. In general, inverting a set of rules strings. For completeness, we mention the concept may fail to produce any result due to nontermina- of text-to-model transformation, but it essentially tion. comprises parsing and reverse-engineering technol- ogies, which are beyond the scope of this paper. Tracing Tracing can be understood as the runtime footprint Model-to-text transformation corresponds to the of transformation execution (Figure 8G). Trace- concept of ‘‘pretty printing’’ in program transfor- ability links are a common form of trace information mation. Model-to-text approaches are useful for in model transformation, connecting source and generating both code and noncode artifacts such as target elements, which are essentially instances of documents. In general, we can view transforming the mapping between the source and target do- models to code as a special case of model-to-model mains. Traceability links can be established by transformations; we only need to provide a meta- recoding the transformation rule and the source model for the target programming language. How- elements that were involved in creating a given ever, for practical reasons of reusing existing target element. Trace information can be useful in compiler technology and for simplicity, code is often performing impact analysis (i.e., analyzing how generated simply as text, which is then fed into a changing one model would affect other related compiler. OMG issued an RFP for a MOF 2.0 Model- 70 models), determining the target of a transformation to-Text Transformation Language in April 2004, as in model synchronization, model-based debug- which will eventually lead to a standard for mapping ging (i.e., mapping the stepwise execution of an MOF-based models to text. implementation back to its high-level model), and in debugging model transformations themselves. Model-to-text approaches In the model-to-text category, we distinguish be- Some approaches, such as QVT, ATL, and Tefkat, tween visitor-based and template-based approaches. provide dedicated support for tracing. Even without dedicated support, as in the case of AGG, VIATRA Visitor-based approach and GReAT, tracing information can always be A very basic code-generation approach consists in created just as any other target elements. Some providing some visitor mechanism to traverse the approaches with dedicated support, Tefkat for internal representation of a model and write text to a example, require developers to manually encode the text stream. An example of this approach is Jamda— creation of traceability links in the transformation an object-oriented framework providing a set of rules, while other approaches, such as QVT and classes to represent UML models, an API for ATL, create traceability links automatically. In the manipulating models, and a visitor mechanism case of automated support, the approach may still (CodeWriters) to generate code. Jamda does not provide some control over what gets recorded. In support the MOF standard to define new meta- general, we might want to control (1) the kind of models; however, new model element types can be information recorded (e.g., the links between source introduced by subclassing the existing Java classes and target elements, the rules that created them, and that represent the predefined model element types. a time stamp for the creation), (2) the abstraction level of the recorded information (e.g., links for top- Template-based approach level transformations only), and (3) the scope for The majority of currently available MDA tools which the information is recorded (e.g., tracing for support template-based model-to-text generation particular rules or parts of the source only). Finally, (e.g., openArchitectureWare, JET, FUUT-je, Coda- there is the choice of location where the links are gen Architect, AndroMDA, ArcStyler, MetaEditþ, stored (e.g., in the source or target, or separately). and OptimalJ). AndroMDA reuses existing open- source template-based generation technology: Ve- 71 72 MAJOR CATEGORIES locity and XDoclet. An example of the template- At the top level, we distinguish between model-to- based approach is shown in Example 3. text and model-to-model transformation approaches. The distinction between the two categories is that, A template usually consists of the target text while a model-to-model transformation creates its containing splices of metacode to access information

634 CZARNECKI AND HELSEN IBM SYSTEMS JOURNAL, VOL 45, NO 3, 2006 from the source and to perform code selection and as JMI. It is usually implemented as an object- iterative expansion. (For an introduction to tem- oriented framework, which may also provide some 73 plate-based code generation, see Cleaveland. ) minimal infrastructure to organize the transforma- According to our terminology, the LHS uses ex- tions (e.g., abstract class for transformations). ecutable logic to access source, and the RHS However, users usually have to implement trans- combines untyped string patterns with executable formation rules, scheduling, tracing, and other logic for code selection and iterative expansion. facilities, mostly from the beginning, in a program- Furthermore, there is no clear syntactic separation ming language such as Java. between the LHS and RHS. Template approaches usually offer user-defined scheduling in the internal Structure-driven approach form of calling a template from within another Approaches in this category have two distinct template. phases: The first phase is concerned with creating the hierarchical structure of the target model; The LHS logic accessing the source model may have whereas, the second phase sets the attributes and different forms. The logic could be simply Java code references in the target. The overall framework accessing the API provided by the internal repre- determines the scheduling and application strategy; sentation of the source model such as JMI, or it users are only concerned with providing the trans- could be declarative queries, for example, in OCL or formation rules. 74 XPath. The openArchitectureWare Generator Framework propagates the idea of separating more An example of the structure-driven approach is the complex source access logic—which might need to model-to-model transformation framework provided navigate and gather information from different by OptimalJ. The framework is implemented in Java places of the source model—from templates by and provides incremental copiers that users have to moving the logic into user-defined operations of the subclass to define their own transformation rules. source-model elements. The basic metaphor is the idea of copying model elements from the source to the target, which can Compared with a visitor-based transformation, the then be adapted to achieve the desired transforma- structure of a template resembles more closely the tion effect. The framework uses reflection to provide code to be generated. Templates lend themselves to a declarative interface. A transformation rule is iterative development as they can be easily derived implemented as a method with an input parameter from examples. Because the template approaches whose type determines the source type of the rule, discussed in this section operate on text, the patterns and the method returns a Java object representing they contain are untyped and can represent syntac- the class of the target model element. Rules are not tically or semantically incorrect code fragments. On allowed to have side effects, and scheduling is the other hand, textual templates are independent of completely determined by the framework. the target language and simplify the generation of any textual artifacts, including documentation. Another structure-driven approach is the QVT submission by Interactive Objects and Project A related technology is frame processing, which 67 Technology. A special property of this approach is extends templates with more sophisticated adapta- the target-oriented rule organization, where there is tion and structuring mechanisms (Bassett’s 75 76 77 **78 one rule per target element type and the nesting of frames, XVCL, XFramer, ANGIE ). To our the rules corresponds to the containment hierarchy knowledge, XFramer and ANGIE have been applied in the target metamodel. The execution of this to generate code from models. model can be viewed as a top-down configuration of Model-to-model approaches the target model. In the model-to-model category, we distinguish among direct-manipulation, structure-driven, op- Operational approach Approaches that are similar to direct manipulation erational, template-based, relational, graph-trans- formation-based, and hybrid approaches. but offer more dedicated support for model trans- formation are grouped in this category. A typical Direct manipulation approach solution in this category is to extend the utilized This category of approach offers an internal model formalism with facilities for express- representation and some APIs to manipulate it, such ing computations. An example would be to extend a

IBM SYSTEMS JOURNAL, VOL 45, NO 3, 2006 CZARNECKI AND HELSEN 635 query language such as OCL with imperative name :¼ self.name; constructs. The combination of MOF with such key :¼ object Column f extended executable OCL becomes a fully-fledged name :¼ self.name þ 0_tid0; object-oriented programming system. Examples of type :¼ 0NUMBER0; systems in this category are QVT Operational g; mappings, XMF-Mosaic’s executable MOF, MTL, cols :¼ key; C-SAW, and Kermeta. Specialized facilities such as g tracing may be offered through dedicated libraries. mapping Attributes::attributeToColumn () : Column f ... g Example 4 shows our sample transformation from class models to schemas expressed in the QVT ... Operational language. In contrast to the QVT Relations solution from Example 1, the transforma- Template-based approach tion declaration specifies the parameter modes; that Model templates are models with embedded meta- is, the transformation is executed only in one code that compute the variable parts of the resulting direction from uml to rdbms. The entry point for the template instances. Model templates are usually execution is the function main(), which invokes the expressed in the concrete syntax of the target packageToSchema mapping on all packages and then language, which helps the developer to predict the the attributeToColumn mapping on all attributes result of template instantiation. The metacode can contained in the input model uml. The mappings are have the form of annotations on model elements. defined by using an imperative extension of OCL. A Typical annotations are conditions, iterations, and mapping is defined as an operation on a model expressions, all being part of the metalanguage. An element. For example, packageToSchema is an obvious choice for the expression language to be operation of Package with Schema as its return type. used in the metalanguage is OCL. The body of the mapping populates the properties of the return object, while self refers to the object on A concrete model-template approach is given by 79 which the mapping was invoked. QVT Operations is Czarnecki and Antkiewicz. In that approach, a a quite feature-rich language. The interested reader template of a UML model, such as a class or activity is invited to explore the QVT specification diagram, is created by annotating model elements 15 document. with conditions or expressions represented as stereotypes. A very simple example is shown in Figure 9, which reuses the class model from Figure Example 4 2C. This time, however, the model is shown in its transformation umlRdbms( UML concrete syntax. The class Address and the in uml : SimpleUML, addr attribute of Customer are annotated with the out rdbms : SimpleRDBMS presence condition addrFeature. When the tem- ); plate is instantiated with addrFeature being true, the resulting model is the same as the template. If main() f the condition is false, the annotated elements, which uml.objectsOfType(Package)-.map packageToSchema(); are blue in the figure, are removed. uml.objectsOfType(Attribute)-.map attributeToColumn(); Relational approach g This category groups declarative approaches in which the main concept is mathematical relations. mapping Package::packageToSchema () : Schema f In general, relational approaches can be seen as a --population section for the schema form of constraint solving. Examples of relational name :¼ self.name; approaches are QVT Relations, MTF, Kent Model tbls :¼ self.elems-.map classToTable(); Transformation Language, Tefkat, AMW, and map- g pings in XMF-Mosaic.

mapping Class::classToTable () : Table The basic idea is to specify the relations among when f self.isPersistent¼true; gf source and target element types using constraints. In

636 CZARNECKI AND HELSEN IBM SYSTEMS JOURNAL, VOL 45, NO 3, 2006 its pure form, such a specification is nonexecutable App 18,59 68 (e.g., relations and mapping rules ). However, declarative constraints can be given executable Customer <> semantics, such as in logic programming. In fact, {isPersistent=true} Address logic programming with its unification-based {isPersistent=false} matching, search, and backtracking seems a natural name: String choice to implement the relational approach, where <>addr: Address addln: String predicates can be used to describe the relations. 20 Gerber et al. explore the application of logic programming, in particular Mercury, a typed dialect Figure 9 of Prolog, and F-logic, an object-oriented logic Example of a model template paradigm, to implement transformations. An exam- ple of the relational approach is shown in Example 1. to be much more concise than patterns in the corresponding abstract syntax (compare Figures 3C All of the relational approaches are side-effect-free and 9 and also see the work by Marschall and 28 and, in contrast to the imperative direct manipu- Braun for examples). On the other hand, it is easy lation approaches, create target elements implicitly. to provide a default rendering for abstract syntax Relational approaches can naturally support multi- that will work for any metamodel, which is useful directional rules. They sometimes also provide when no specialized concrete syntax is available. backtracking. Most relational approaches require strict separation between source and target models; AGG and AToM3 are systems directly implementing that is, they do not allow in-place update. the theoretical approach to attributed graphs and transformations on such graphs. They have built-in Graph-transformation-based approach fixpoint scheduling with nondeterministic rule This category of model transformation approaches selection and concurrent application to all matching draws on the theoretical work on graph trans- locations, and they rely on implicit scheduling by formations. In particular, this category operates on the user. The transformation rules are unidirectional 80 typed, attributed, labeled graphs, which can be and in-place. thought of as formal representations of simplified class models. Examples include AGG, AToM3, Figure 10 illustrates how the transformation from VIATRA, GReAT, UMLX, BOTL, MOLA, and Fujaba. class models to schemas can be expressed in AGG. Only two rules are shown. The rule in Figure 10A Graph transformation rules have an LHS and an RHS maps packages to schemas. The mapping from graph pattern. The LHS pattern is matched in the classes to tables is given in Figure 10B. The mapping model being transformed and replaced by the RHS of attributes to columns is not shown. The RHS of an pattern in place. The LHS often contains conditions AGG rule contains a mixture of the new elements in addition to the LHS pattern, for example, negative and elements from the LHS, as indicated by the conditions. Some additional logic, for example, in indexes prefixing their names. When the LHS is string and numeric domains, is needed to compute matched, new elements are created. The implicit target attribute values such as element names. scheduling is achieved through correspondence GReAT offers an extended form of patterns with objects connecting source and target elements multiplicities on edges and nodes. (which are an example of intermediate structures) and negative conditions. For example, the package- Graph patterns can be rendered in the concrete to-schema rule matches packages and creates the syntax of their respective source or target language corresponding schemas and the package-to-schema (e.g., in VIATRA) or in the MOF abstract syntax correspondence objects (i.e., instances of P2S). Each (e.g., in BOTL and AGG). The advantage of the rule has a negative application condition, which is concrete syntax is that it is more familiar to implicitly assumed to be its RHS. Because of the developers working with a given modeling language negative application condition, no additional sche- than the abstract syntax. Also, for complex lan- ma objects will be created for a package that is guages like UML, patterns in a concrete syntax tend already connected to a schema by a P2S object.

IBM SYSTEMS JOURNAL, VOL 45, NO 3, 2006 CZARNECKI AND HELSEN 637 A 1:Package 1:Package name = pn name = pn

src P2S

tar Column name = cn+'_tid' Schema type ='NUMBER' name = pn cols pkey B 1:Class 1:Class Table src tar name = cn name = cn C2T name = cn isPersistent = true isPersistent = true

src tar src tar 2:Package 3:P2S 4:Schema 2:Package 3:P2S 4:Schema

Figure 10 Graph transformation in AGG: (A) package-to-schema rule and (B) class-to-table rule

Systems such as VIATRA, GReAT, MOLA, and Hybrid approach Fujaba extend the basic functionality of AGG and Hybrid approaches combine different techniques AToM3 by adding explicit scheduling. For example, from the previous categories. The different ap- VIATRA users can build state machines to schedule proaches can be combined as separate components transformation rules. The explicit representation of or, in a more fine-grained fashion, at the level of scheduling in GReAT is a data-flow graph. MOLA individual rules. QVT is an example of a hybrid and Fujaba use control-flow graphs for that purpose. approach with three separate components, namely Relations, Operational mappings, and Core. Exam- The class-model-to-schema transformation ex- ples of the fine-grained combination are ATL and pressed in MOLA is shown in Figure 11. Each YATL. enclosing rectangular box represents a looping construct. Boxes with rounded corners represent A transformation rule in ATL may be fully declar- looping conditions. The elements to be matched are ative, hybrid, or fully imperative. The LHS of a fully drawn using solid lines; dashed lines are used for declarative rule (so-called source pattern) consists of the elements to be created. The top condition a set of syntactically typed variables with an matches package objects. When a package object is optional OCL constraint as a filter or navigation matched, the corresponding schema is created and logic. The RHS of a fully declarative rule (so-called the body of the loop, which is another loop, is target pattern) contains a set of variables and some executed. The latter loop iterates over all classes in declarative logic to bind the values of the attributes the package that was matched in the current in the target elements. In a hybrid rule, the source or iteration of the outer loop and creates the corre- target patterns are complemented with a block of imperative logic, which is run after the application sponding classes and primary-key columns. The of the target pattern. A fully imperative rule (so- final step is a call to ProcessClassAttributes, called procedure) has a name, a set of formal which is a subprogram mapping attributes to parameters, and an imperative block, but no columns. patterns. Rules are unidirectional and support rule inheritance. Relational-style, multidirectional approaches based on graph transformations are also possible. For Other approaches 32 example, Ko¨nigs discusses using a transformation Two more approaches are mentioned for complete- approach based on triple-graph grammars to simu- ness: transformation implemented using Extensible 81 late QVT Relations. Stylesheet Language Transformation (XSLT ) and

638 CZARNECKI AND HELSEN IBM SYSTEMS JOURNAL, VOL 45, NO 3, 2006 p:Package #packageToSchema s:Schema name := @p.name

#packageToSchema @p:Package @s:Schema

t:Table cols cl:Column c:Class #classToTable {isPersistent = true} name = @c.name pkey name := @c.name+'_tid' type ='NUMBER'

ProcessClassAttributes( )

Figure 11 Graph transformation in MOLA

the application of metaprogramming to model A more promising direction in applying traditional transformation. metaprogramming techniques to model transforma- 37 tions has been proposed by Tratt. His solution is a Because models can be serialized as Extensible domain-specific language for model transformations Markup Language (XML) using the XML Metadata embedded in a metaprogramming language. 82 Interchange (XMI**), implementing model trans- formations using XSLT, which is a standard tech- DISCUSSION nology for transforming XML, seems very attractive. In this section, we comment on the practical Such an approach can be classified as term rewriting applicability of the different types of model trans- using a functional language. Unfortunately, the use formation. These comments are based on our of XMI and XSLT has scalability limitations. Manual intuition and the application examples published implementation of model transformations in XSLT together with the approaches. Because of the lack of controlled experiments and extensive practical quickly leads to non-maintainable implementations experience, these comments are not fully validated, because of the verbosity and poor readability of XMI but we hope that they will stimulate discussion and and XSLT. A solution is to generate the XSLT rules further evaluation. from some more declarative rule descriptions, as 83,84 demonstrated in the work by Peltier et al. ; Direct manipulation is obviously the most low-level however, even this approach suffers from poor approach. In its basic form, it offers the user little or efficiency because of the copying required by the no support or guidance in implementing trans- pass-by-value semantics of XSLT and the poor formations. Essentially, all work has to be done by compactness of XMI. the user. The approach can be improved by adding

IBM SYSTEMS JOURNAL, VOL 45, NO 3, 2006 CZARNECKI AND HELSEN 639 specialized libraries and frameworks implementing possible lack of confluence and termination. Exist- facilities such as pattern matching and tracing. ing theories for detecting such problems are not Operational approaches are similar to direct ones general enough to cover the wide range of trans- except that they offer an executable metamodeling formations found in practice. As a result, tools such formalism through a dedicated language. Providing as GReAT, VIATRA, and MOLA provide mecha- specialized facilities through libraries and frame- nisms for explicit scheduling. It is often argued that works seems to be an attractive way to improve the graph transformations are a natural choice for support for model transformations in an evolu- model transformations because models are graphs. 85 tionary way. As Batory points out, there are plenty of examples of graph structures in practice, including the objects The structure-driven category covers pragmatic approaches that were developed in the context of in a Java program whose processing is usually not (and seem to apply particularly well to) certain understood as graph transformations. In our opin- kinds of applications such as generating Enterprise ion, a particular weakness of existing graph trans- JavaBeans** (EJB**) implementations and database formation theories and tools is that they do not schemas from UML models. These applications consider ordered graphs, that is, graphs with require strong support for transforming models with ordered edges. As a consequence, they are appli- a 1-to-1 and 1-to-n (and sometimes n-to-1) corre- cable to models that contain predominantly un- spondence between source and target elements. ordered collections, such as class diagrams with Also, in this application context, there is typically no classes having unordered collections of attributes need for iteration (and in particular fixpointing) in and methods. However, they do not apply well to scheduling, which can be system-defined. It is method bodies, where ordering is important, such as unclear how well these approaches can support in a list of statements. Ordering can be represented other kinds of applications. by additional edges, but this approach leads to more complex transformations. It is interesting to note Template-based approaches make it easy for the that ordering is well handled by classical program developer to predict the resulting code or models transformation, which uses term rewriting on just by looking at the templates. They also support abstract syntax trees (ASTs). Terms and ASTs are iterative development in which the developer can ordered trees, and the order of child nodes is used to start with a sample model or code and turn it into a encode lists of program elements such as state- template. Current template-based approaches do not ments. Edge ordering can be modeled in graph have built-in support for tracing, although trace transformations by using edge attributes to attach an information can be easily encoded in the templates. index to each edge; however, current tools based on Templates are particularly useful in code generation graph transformation do not exploit this information and model compilation scenarios. for more efficient pattern matching. Nevertheless, Relational approaches seem to strike a good balance graph transformation theory might turn out to be between flexibility and declarative expression. They useful for ensuring correctness in some application can provide multidirectionality and incrementality, scenarios. Fujaba is probably the largest and most including the update of a manually modified target. significant example of applying graph transforma- On the other hand, their power is contingent on the tions to models to date. It remains to be seen what sophistication of the underlying constraint-solving impact these approaches will have on systems used facilities. As a result, performance strongly depends in practice. on the kinds of constraints that need to be solved, which may limit their applicability. In any case, Hybrid approaches allow the user to mix and match relational approaches seem to be most applicable to different concepts and paradigms depending on the model synchronization scenarios. application. Given the wide range of practical scenarios, a comprehensive approach is likely to be Graph-transformation-based approaches are in- hybrid. A point in case is the QVT specification, spired by theoretical work in graph transformations. which also offers a hybrid solution. In their pure form, graph transformations are declarative and also seem intuitive; however, the RELATED WORK usual fixpoint scheduling with concurrent applica- The feature model and categorization presented in 86 tion makes them rather difficult to use due to the this paper is based on our earlier paper. The

640 CZARNECKI AND HELSEN IBM SYSTEMS JOURNAL, VOL 45, NO 3, 2006 previous feature model has been widely discussed in Another account of requirements for model trans- workshops and in personal communications. It has formation approaches is given by Sendall and 88 also been used by other authors. For example, Kozaczynski. 24 Jouault and Kurtev give a classification of ATL and 60 AMW using the earlier version of the model. Mens and Van Gorp have also proposed a classification of model transformations, which they 89 The current feature model and categories take into apply to graph transformation systems. That work account the feedback that we have received based has been significantly influenced by our earlier on the original paper. They were also revised to classification. The main difference is that their cover approaches that were proposed after 2003, classification is broader as it also covers different most prominently, the final adopted QVT specifica- aspects of model transformation tools such as tion. Introducing domains into transformation rules usability, extensibility, interoperability, and stan- was one of the most important changes to the dards. In contrast, our feature model offers a more feature model based on that specification. Only five detailed treatment of model transformation ap- out of the 14 presented feature diagrams remained proaches. Another difference is that Mens and Van unchanged compared with the original model, Gorp present a flat list of dimensions, whereas our namely, those in Figures 5A, 6, and 8A–8C. We also dimensions are organized hierarchically. An exten- added two new categories of model-to-model ap- sive comparison of graph transformation ap- proaches, namely, operational and template-based proaches using a common example is given by 90 approaches. Taentzer et al.

In their review of the different QVT submissions, 87 CONCLUSIONS Gardner et al. propose a unified terminology to Model transformation is a relatively young area. enable a comparison of the different proposals. As Although it is related to and builds upon the more their scope of comparison is considerably different established fields of program transformation and from ours, there is not much overlap in terminology. metaprogramming, the use of graphical modeling While Gardner et al. focus on the eight initial QVT languages and the application of object-oriented submissions, we discuss a wider range of ap- metamodeling to language definitions set a new proaches: In addition to the revised QVT submis- sions, we also discuss other approaches published in context. the literature and available in tools. Another differ- ence is that Gardner et al. discuss model queries, In this paper, we presented a feature model offering views, and transformations, whereas we focus on a terminology for describing model transformation transformations in more detail. The terms defined approaches and making the different design choices by Gardner et al. that are also relevant for our for such approaches explicit. We also surveyed and classification are model transformation, unidirec- classified existing approaches into visitor-based and tional, bidirectional, declarative, imperative, and template-based model-to-text categories and direct- rules. manipulation, structure-driven, operational, tem- plate-based, relational, graph-transformation-based, In addition to providing the basic unifying termi- and hybrid model-to-model categories. nology, Gardner et al. discuss practical requirements on model transformations such as requirements Although there are satisfactory solutions for trans- scalability, simplicity, and ease of adoption. Among forming models to text (such as template-based others, they discuss the need to handle trans- approaches), this is not the case for transforming formation scenarios of different complexities, such models to models. Many new approaches to model- as transformations with different origin relation- to-model transformation have been proposed over ships between source and target model elements, for the last three years, but relatively little experience is example, 1-to-1, 1-to-n, n-to-1, and n-to-m. Finally, available to assess their effectiveness in practical they make some recommendations for the final QVT applications. In this respect, we are still at the stage standard. In particular, they recommend a hybrid of exploring possibilities and eliciting requirements. approach, supporting declarative specification of Modeling tools available on the market are just simpler transformations, but allowing for an im- starting to offer some model-to-model transforma- perative implementation of more complex ones. tion capabilities, but these are still very limited and

IBM SYSTEMS JOURNAL, VOL 45, NO 3, 2006 CZARNECKI AND HELSEN 641 often ad hoc, that is, without proper theoretical informatik.rwth-aachen.de/Publications/CEUR-WS// foundation. Vol-159/paper8.pdf. 10. A. Solberg, R. France, and R. Reddy, ‘‘Navigating the MetaMuddle,’’ Proceedings of the 4th Workshop in Evaluation of the different design options for a Software Model Engineering, Montego Bay, Jamaica model transformation approach will require more (2005), http://www.planetmde.org/wisme-2005/ NavigatingTheMetaMuddle.pdf. experiments and practical experience. 11. G. Sunye´, D. Pollet, Y. Le Traon, and J.-M. Je´ze´quel, ‘‘Refactoring UML Models,’’ Proceedings of the 4th International Conference, Unified Modeling Language ACKNOWLEDGMENTS Conference, Toronto, Canada (2001), pp. 134–148. The authors thank Karl-Trygve Kalleberg for his 12. J. Zhang, Y. Lin, and J. Gray, ‘‘Generic and Domain- extensive feedback on earlier versions of the feature Specific Model Refactoring Using a Model Transformation model, Markus Vo¨lter for providing the template Engine,’’ Chapter 9 in Model-Driven Software Develop- ment, S. Beydeda, M. Book, and V. Gruhn, Editors, examples in Examples 2 and 3, and Ulrich Eisenecker, Springer-Verlag, Heidelberg, Germany (2005), Don Batory, Jeff Gray, Laurence Tratt, Gabriele pp. 199–218. Taentzer and the anonymous reviewers for their 13. J.-M. Favre, ‘‘CacOphoNy: Metamodel-Driven Architec- valuable comments on a previous draft of the paper. ture Reconstruction,’’ Proceedings of the Working Con- ference on Reverse Engineering, Delft, The Netherlands (2004), pp. 204–213. *Trademark, service mark, or registered trademark of 14. Object Management Group, MOF 2.0 Query/Views/ International Business Machines Corporation. Transformations RFP, OMG Document ad/2002-04-10 (revised on April 24, 2002). **Trademark, service mark, or registered trademark of Object 15. Object Management Group, MOF QVT Final Adopted Management Group, Inc., Inc., Compuware Specification, OMG Adopted Specification ptc/05-11-01 Corporation, MetaCase Consulting, Interactive Objects Soft- (2005). ware GmbH Corporation, The MathWorks, Inc., or Delta Software Technology GmbH, in the United States, other 16. D. Varro´, G. Varro´, and A. Pataricza, ‘‘Designing the countries, or both. Automatic Transformation of Visual Languages,’’ Science of Computer Programming 44, No. 2, 205–227 (2002). 17. D. Varro´ and A. Pataricza, ‘‘Generic and Meta-Trans- formations for Model Transformation Engineering,’’ Proceedings of the 7th International Conference on the CITED REFERENCES Unified Modeling Language, Lisbon, Portugal (2004), 1. T. Stahl and M. Vo¨lter, Model-Driven Software Develop- pp. 290–304. ment—Technology, Engineering, Management, John Wi- 18. D. H. Akehurst and S. J. H. Kent, ‘‘A Relational Approach to ley and Sons, Ltd., Chichester, England (in press June Defining Transformations in a Metamodel,’’ Proceedings of 2006), ISBN: 0470025700. the 5th International Conference on the Unified Modeling 2. Object Management Group, MDA Guide, Version 1.0.1, Language, Dresden, Germany (2002), pp. 243–258. OMG Document omg/2003-06-01 (2003). 19. D. H. Akehurst, W. G. Howells, and K. D. McDonald- Maier, ‘‘Kent Model Transformation Language,’’ Pro- 3. D. S. Frankel, Model Driven Architecture: Applying MDA ceedings of Model Transformations in Practice Workshop, to Enterprise Computing, Wiley Press, Hoboken, NJ MoDELS Conference, Montego Bay, Jamaica (2005), (2003). http://sosym.dcs.kcl.ac.uk/events/mtip05/submissions/ 4. J. Sztipanovits and G. Karsai, ‘‘Model-Integrated Com- akehurst_howells_mcdonald-maier_ _kent_model_ puting,’’ Computer 30, No. 4, 110–111 (1997). transformation_language.pdf. 5. J. Greenfield and K. Short, Software Factories: Assembling 20. A. Gerber, M. Lawley, K. Raymond, J. Steel, and A. Applications with Patterns, Models, Frameworks, and Wood, ‘‘Transformation: The Missing Link of MDA,’’ Tools, John Wiley and Sons, Indianapolis, IN (2004). Proceedings of the 1st International Conference on Graph Transformation, Barcelona, Spain (2002), pp. 90–105. 6. K. Czarnecki, ‘‘Overview of Generative Software Devel- opment,’’ Proceedings of Unconventional Programming 21. M. Lawley and J. Steel, ‘‘Practical Declarative Model Paradigms, Mont Saint-Michel, France (2004), pp. 313– Transformation with Tefkat,’’ Proceedings of Model 328. Transformations in Practice Workshop, MoDELS Confer- ence, Montego Bay, Jamaica (2005), http://sosym.dcs. 7. A. Kleppe, J. Warmer, and W. Bast, MDA Explained, The kcl.ac.uk/events/mtip05/submissions/ Model Driven Architecture: Practice and Promise, Addi- lawley_steel_ _practical_declarative_model_ son-Wesley, Boston, MA (2003). transformation_with_tefkat.pdf. 8. I. Ivkovic and K. Kontogiannis, ‘‘Tracing Evolution 22. A. Agrawal, G. Karsai, and F. Shi, Graph Transformations Changes of Software Artifacts through Model Synchroni- on Domain-Specific Models, Technical Report ISIS-03-403, zation,’’ Proceedings of the 20th IEEE International Institute for Software Integrated Systems, Vanderbilt Conference on Software Maintenance, Washington, DC University, Nashville, TN 37203 (2003). (2004), pp. 252–261. 23. J. Be´zivin, G. Dupe´, F. Jouault, G. Pitette, and J. E. 9. R. I. Bull and J.-M. Favre, ‘‘Visualization in the Context of Rougui, ‘‘First Experiments with the ATL Model Trans- Model Driven Engineering,’’ Proceedings of the Workshop formation Language: Transforming XSLT into XQuery,’’ on Model Driven Development of Advanced User Inter- Proceedings of the Workshop on Generative Techniques in faces, Montego Bay, Jamaica (2005), http://sunsite. the Context of Model Driven Architecture, Anaheim, CA

642 CZARNECKI AND HELSEN IBM SYSTEMS JOURNAL, VOL 45, NO 3, 2006 (2003), http://www.softmetaware.com/oopsla2003/ 38. AndroMDA 2.0.3, http://www.andromda.org. bezivin.pdf. 39. openArchitectureWare (oAW), http://www. 24. F. Jouault and I. Kurtev, ‘‘Transforming Models with openarchitectureware.org/. ATL,’’ Proceedings of Model Transformations in Practice 40. Fujaba Tool Suite 4, University of Paderborn Software Workshop (MTIP), MoDELS Conference, Montego Bay, Engineering, http://www.fujaba.de. Jamaica (2005), http://sosym.dcs.kcl.ac.uk/events/ mtip05/submissions/ 41. JAMDA, Java Model Driven Architecture 0.2, http:// jouault_kurtev_ _transforming_models_with_atl.pdf. sourceforge.net/projects/jamda. 25. E. D. Willink, ‘‘UMLX: A Graphical Transformation 42. R. Pompa, Java Emitter Templates (JET) Tutorial, Azzurri Language for MDA,’’ Proceedings of the 18th Annual ACM Ltd. (June 2005), http://www.eclipse.org/articles/ SIGPLAN Conference on Object-Oriented Programming, Article-JET/jet_tutorial1.html. Systems, Languages, and Applications, Anaheim, 43. G. van Emde Boas, The Fantastic, Unique, UML Tool for CA(2003), pp. 13–24 (2003). the Java Environment (FUUT-je), http://www.bronstee. 26. J. de Lara and H. Vangheluwe, ‘‘AToM: A Tool for Multi- com/index.php?id¼FUUT-je. Formalism and Meta-Modeling,’’ Proceedings of the 5th 44. Model Transformation Framework (MTF), IBM United International Conference on Fundamental Approaches to Kingdom Laboratories Ltd., IBM alphaWorks (2004), Software Engineering, Grenoble, France (2002), pp. 174–188. http://www.alphaworks.ibm.com/tech/mtf. 27. P. Braun and F. Marschall, The Bi-directional Object- 45. XMF-Mosaic, Xactium, http://xactium.com. Oriented Transformation Language, Technical Report TUM-I0307, Technische Universita¨tMu¨nchen 85748, 46. OptimalJ 4.0, User’s Guide, Compuware (June 2005), Mu¨nchen, Germany (May 2003). http://www.compuware.com/products/optimalj. 28. F. Marschall and P. Braun, ‘‘Model Transformations for 47. J.-P. Tolvanen, ‘‘Making Model-Based Code Generation the MDA with BOTL,’’ Proceedings of the Workshop on Work,’’ Embedded Systems Europe, pp. 36–38 (August/ Model Driven Architecture: Foundations and Applica- September 2004), http://i.cmpnet.com/embedded/ tions, Enschede, The Netherlands (2003), pp. 25–36. europe/esesep04/esesep04p36.pdf. 29. A. Kalnins, J. Barzdins, and E. Celms, ‘‘Model Trans- 48. Domain-Specific Modeling with MetaEditþ, MetaCase, formation Language MOLA,’’ Proceedings of Model Driven http://www.metacase.com/. Architecture: Foundations and Applications, Linkoeping, 49. ArcStyler 5.1, Interactive Objects Software GmbH, http:// Sweden (2004), pp. 14–28. www.arcstyler.com. 30. G. Taentzer, ‘‘AGG: A Graph Transformation Environ- 50. Codagen Architect 3.0, Codagen Technologies Corp., ment for Modeling and Validation of Software,’’ Appli- http://www.codagen.com/products/architect/default. cation of Graph Transformations with Industrial htm. Relevance (AGTIVE’03) 3062, pp. 446–453 (2003). 51. H. Partsch and R. Steinbru¨ggen, ‘‘Program Transforma- 31. J. Be´zivin, F. Jouault, P. Rosenthal, and P. Valduriez, tion Systems,’’ ACM Computing Surveys 15, No. 3, 199– ‘‘Modeling in the Large and Modeling in the Small,’’ 236 (1983). Proceedings of the European MDA Workshops: Founda- Specification and Transformation of Pro- tions and Applications, Twente, The Netherlands (2003), 52. H. Partsch, grams—a Formal Approach to Software Development and Linkoeping, Sweden (2004), pp. 33–46. , Springer-Verlag, Berlin, Germany (1990). 32. A. Ko¨nigs, ‘‘Model Transformation with Triple Graph Grammars,’’ Proceedings of Model Transformations in 53. K. Czarnecki, ‘‘Domain Engineering,’’ in Encyclopedia of Practice Workshop at MoDELS Conference, Montego Bay, Software Engineering Second Edition, J. J. Marciniak, Jamaica (2005), http://www.es.tu-darmstadt.de/ Editor, John Wiley and Sons, Inc., Hoboken, NJ (2002), download/publications/koenigs/ pp. 433–444. model_transformation_with_triple_graph_grammars.pdf. 54. K. C. Kang, S. G. Cohen, J. A. Hess, W. E. Nowak, and 33. D. Vojtisek and J.-M. Je´ze´quel, ‘‘MTL and Umlaut NG: A. S. Peterson, Feature-Oriented Domain Analysis Engine and Framework for Model Transformation,’’ (FODA) Feasibility Study, Technical Report CMU/SEI-90- http://www.ercim.org/publication/Ercim_News/enw58/ TR-21, Software Engineereing Institute, Carnegie Mellon vojtisek.html. University, Pittsburgh, PA 15213 (1990). 34. O. Patrascoiu, ‘‘YATL: Yet Another Transformation 55. K. Czarnecki and U. W. Eisenecker, Generative Program- Language,’’ Proceedings of the 1st European MDA Work- ming: Methods, Tools, and Applications, Addison-Wesley shop, Twente, The Netherlands (2004), pp. 83–90. Professional, Boston, MA (2000). 35. P.-A. Muller, F. Fleurey, and J.-M. Je´ze´quel, ‘‘Weaving 56. K. Czarnecki, S. Helsen, and U. Eisenecker, ‘‘Formalizing Executability into Object-Oriented Metalanguages,’’ Cardinality-Based Feature Models and Their Special- ACM/IEEE 8th International Conference on Model Driven ization,’’ Software Process: Improvement and Practice 10, Engineering Languages and Systems, Montego Bay, No. 1, 7–29 (2005). Jamaica (2005), pp. 264–278. 57. C. H. P. Kim and K. Czarnecki, ‘‘Synchronizing Cardin- 36. J. Gray, Y. Lin, and J. Zhang, ‘‘Automating Change ality-Based Feature Models and their Specializations,’’ Evolution in Model-Driven Engineering,’’ IEEE Computer Proceedings of the European Conference on Model Driven (Special issue on Model-Driven Engineering) 36, No. 2, Architecture, Nuremberg, Germany (2005), swen. 51–58 (February 2006), http://www.cis.uab.edu/gray/ uwaterloo.ca/;kczarnec/ecmda05.pdf. Pubs/computer.pdf. 58. E. Cariou, R. Marvie, L. Seinturier, and L. Duchien, Model 37. L. Tratt, ‘‘The MT Model Transformation Language,’’ Transformation Contracts and Their Definition in UML Proceedings of ACM SIGAPP Symposium on Applied and OCL, Technical Report LIFL 2004-n808, Laboratoire Computing, Dijon, France (2006), http://portal.acm.org/ d’Informatique Fondamentale de Lille, Universite´ des affiliated/citation.cfm?id¼1141277.1141577&coll¼ACM Sciences et Technologies de Lille, 59655 Villeneuve &dl¼ACM&type¼series&idx¼1141277&part¼Proceedings& d’Ascq Cedex, France (2004). WantType¼Proceedings&title¼Symposium%20on% 59. MOF Query/Views/Transformations, OMG Document ad/ 20Applied%20Computing&CFID¼15151515& 03-08-08, Object Management Group, Inc., (revised in CFTOKEN¼6184618. August 2003).

IBM SYSTEMS JOURNAL, VOL 45, NO 3, 2006 CZARNECKI AND HELSEN 643 60. Meta Object Facility (MOF) 2.0 Core Specification, OMG Variants,’’ Proceedings of the 4th International Conference Adopted Specification ptc/03-10-04, Object Management on Generative Programming and Component Engineering, Group, Inc., (2003). Tallinn, Estonia (2005), pp. 422–437. 61. T. Mens and P. Van Gorp, ‘‘A Taxonomy of Model 80. M. Andries, G. Engels, A. Habel, B. Hoffmann, H.-J. Transformation and Its Application to Graph Trans- Kreowski, S. Kuske, D. Plump, A. Schu¨rr, and G. formation,’’ Proceedings of the International Workshop on Taentzer, Graph Transformation for Specification and Graph and Model Transformation, Tallinn, Estonia Programming, Technical Report 7/96, University of (2005), pp. 7–23. Bremen, 1-D-28359 Bremen, Germany (1996). 62. E. Visser, Program-Transformation.Org: The Program 81. XSL Transformations (XSLT), Version 1.0, James Clark, Transformation Wiki, http://www.program-transformation. Editor, W3C Recommendation (November 16, 1999), org/Transform/ProgramTransformation. http://www.w3.org/TR/xslt. 63. Java Metadata Interface 1.0 (JMI), Sun Microsystems, 82. MOF 2.0/XMI Mapping Specification, Version 2.1,OMG Inc. (June 2002), http://java.sun.com/products/jmi. Document formal/05-09-01, Object Management Group, 64. E. Visser, ‘‘Program Transformation with Stratego/XT: Inc. (2005). Rules, Strategies, Tools, and Systems in StrategoXT-0.9,’’ 83. M. Peltier, F. Ziserman, and J. Be´zivin, ‘‘On Levels of Proceedings of the International Domain-Specific Program Model Transformation,’’ XML Europe, Paris, France Generation Seminar, Dagstuhl, Germany (2003), (2000), pp. 1–17. Graphic Communications Association, pp. 216–238. 2000. 65. R. Silaghi, F. Fondement, and A. Strohmeier, ‘‘ ‘Weaving’ 84. M. Peltier, J. Be´zivin, and G. Guillaume, ‘‘MTRANS: A MTL Model Transformations,’’ Proceedings of the Euro- General Framework, Based on XSLT, for Model Trans- pean MDA Workshops: Foundations and Applications, formations,’’ Proceedings of the Workshop on Trans- Twente, The Netherlands (2003), and Linkoeping, formations in UML, Genova, Italy (April 2001), http:// Sweden (2004), pp. 123–138. www.sciences.univ-nantes.fr/lina/atl/www/papers/ 66. I. Kurtev, Adaptability of Model Transformations, PhD peltier-bezivin-guillaume.pdf. thesis, University of Twente, Enschede, The Netherlands 85. D. Batory, ‘‘Multilevel Models in Model-Driven Engi- (2005), http://wwwhome.cs.utwente.nl/;kurtev/files/ neering, Product Lines, and Metaprogramming,’’ IBM thesis.pdf. Systems Journal 45, No. 3, 527–540 (2006, this issue). 67. Object Management Group, Interactive Objects and 86. K. Czarnecki and S. Helsen, ‘‘Classification of Model Project Technology, MOF Query/Views/Transformations, Transformation Approaches,’’ Proceedings of the 2nd OMG Document ad/03-08-11, ad/03-08-12, and ad/03-08- Workshop on Generative Techniques in the Context of 13 (revised submission, 2003). MDA, Anaheim, CA (2003), http://www.swen. 68. Object Management Group, Response to the MOF 2.0 uwaterloo.ca/;kczarnec/ECE750T7/czarnecki_helsen. Query/Views/Transformations RFP (ad/2002-04-10), pdf. OMG Document ad/2003-08-05 (2003). 87. T. Gardner, C. Griffin, J. Koehler, and R. Hauser, ‘‘A 69. Object Management Group, MOF Query/Views/Trans- Review of OMG MOF 2.0 Query/Views/Transformations formations, First Revised Submission, OMG Document Submissions and Recommendations Toward the Final ad/03-08-03 (2003). Standard,’’ Object Management Group, OMG Document 70. Object Management Group, MOF Model to Text Trans- ad/03-08-02 (2003), http://www.omg.org/cgi-bin/ formation Language RFP, OMG Document ad/2004-04-07 doc?ad/03-08-02. (2004). 88. S. Sendall and W. Kozaczynski, ‘‘Model Transformation: 71. Velocity 1.4, The Apache Jakarta Project, The Apache The Heart and Soul of Model-Driven Software Develop- Software Foundation, http://jakarta.apache.org/velocity. ment,’’ IEEE Software 20, No. 5, 42–45 (2003). 72. XDoclet—Attribute Oriented Programming, http:// 89. T. Mens, P. Van Gorp, D. Varro´, and G. Karsai, ‘‘Applying xdoclet.sourceforge.net/xdoclet/index.html. a Model Transformation Taxonomy to Graph Trans- 73. J. C. Cleaveland, Program Generators with XML and Java, formation Technology,’’ Proceedings of the International Prentice-Hall, Upper Saddle River, NJ (2001). Workshop on Graph and Model Transformation, Tallinn, Estonia (2005), pp. 24–39. 74. XML Path Language (XPath) 2.0, A. Berglund, S. Boag, D. Chamberlin, M. F. Ferna´ndez, M. Kay, J. Robie, and J. 90. K. Ehrig, E. Guerra, J. de Lara, L. Lengyel, T. Leven- Sime´on, Editors,W3C Candidate Recommendation (No- dovszky, U. Prange, G. Taentzer, D. Varro´, and S. Varro´- vember 3, 2005), http://www.w3.org/TR/xpath20/. Gyapay, ‘‘Model Transformation by Graph Transforma- ’’ Proceedings of Model 75. P. G. Bassett, Framing Software Reuse: Lessons from the tion: A Comparative Study, Transformations in Practice Workshop, MoDELS Confer- Real World, Prentice-Hall, Inc., Upper Saddle River, NJ ence (1997). , Montego Bay, Jamaica (2005), http://www.inf.mit. bme.hu/FTSRG/Publications/varro/2005/mtip05.pdf. 76. S. Jarzabek, P. Bassett, H. Zhang, and W. Zhang, ‘‘XVCL: XML-Based Variant Configuration Language,’’ Proceed- ings of the International Conference on Software Engi- Accepted for publication January 25, 2006. neering, Portland, OR (2003), pp. 810–811. Published online July 25, 2006. 77. M. Emrich, Generative Programming Using Frame Tech- nology, Diploma thesis, University of Applied Sciences, Department of Computer Science and Micro-System Krzysztof Czarnecki Engineering, Kaiserslautern, Germany (2003). University of Waterloo, Department of Electrical & Computer Engineering, 200 University Avenue West, Waterloo, 78. Frame Processor ANGIE, Delta Software Technology, ON N2L 3G1, Canada ([email protected]). http://www.d-s-t-g.com/neu/media/pdf/facts_e/ Dr. Czarnecki is an Assistant Professor at the University of DLT21474.pdf. Waterloo. He is a coauthor of Generative Programming: 79. K. Czarnecki and M. Antkiewicz, ‘‘Mapping Features to Methods, Tools, and Applications (Addison-Wesley, 2000), Models: A Template Approach Based on Superimposed regarded as a foundational work in its area and used as a

644 CZARNECKI AND HELSEN IBM SYSTEMS JOURNAL, VOL 45, NO 3, 2006 graduate text at universities around the world. Dr. Czarnecki’s current work focuses on realizing the synergies between generative and model-driven software development.

Simon Helsen SAP AG, Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany ([email protected]). Dr. Helsen is a senior developer at SAP AG, where he works on modeling infrastructure software for SAP NetWeavert development tools. He has an Informatics degree from the University of Leuven (Belgium) and a Ph.D. degree in computer science from the University of Freiburg (Germany). Dr. Helsen’s current interests are in scalable model-driven software engineering, domain-specific languages, and model transformations. &

IBM SYSTEMS JOURNAL, VOL 45, NO 3, 2006 CZARNECKI AND HELSEN 645