A comparative look at model transformation languages

Matthew Stephan Andrew Stevenson Queen’s University Queen’s University Kingston, Canada Kingston, Canada [email protected] [email protected]

ABSTRACT Model-driven development(MDD) is a paradigm in which Model-driven development is an emerging area in software software is constructed in a model-centric fashion. Models development that provides a way to express system require- are the main artifacts of interest to stakeholders and system ments and architecture at a high level of abstraction through developers and the underlying code that implements the models. It involves using these models as the primary system is generated from these models. In a perfect model- artifacts during the development process. One aspect that centric development project, models are the only elements is holding back MDD from more wide-spread adoption is that change as the implementing software code is generated the lack of a well established and easy way of performing and updated automatically. model to model (M2M) transformations. We propose to explore and compare popular M2M model transformation One large area of importance in MDD is the notion of model languages in existence: EMT , Kermeta, and ATL. Each transformations, that is, the ability to transform one model of these languages support transformation of Ecore models to another through modifying the model itself or by creating within the Eclipse Modeling Framework (EMF). We attempt a new version of the model. Model transformations can be to implement the same transformation rule on identical meta split into two categories, model-to-model transformations models in each of these languages to achieve the appropriate and model-to-text/code transformation [5]. The model- transformed model. We provide our observations in using to-text transformation task, sometimes referred to as code each tool to perform the transformation and comment on generation, is relatively more mature and explored compared each language/tool’s expressive power, ease of use, and to model-to-model(M2M) transformations. modularity. We conclude by noting that ATL is our language / tool of choice because it strikes a balance Progressing in the area of model-to-model transformations between ease of use and expressive power and still allows is crucial in continuing to foster the adoption of MDD as for modularity. We believe this, in conjunction with ATL’s noted in [5, 9] as these are important operations. Although role in the official Eclipse M2M project will lead to wide- there are many classifications of model transformation ap- spread use of ATL and, hopefully, a step forward in M2M proaches [3], all with much promise, it is still unclear which transformations. approach is the best for M2M transformations in practice or if some are best suited to specific contexts. Categories and Subject Descriptors D.2.12 [Software Engineering]: [Interface definition lan- In this paper, we utilize and evaluate 3 fairly well known guages] M2M model transformation languages each belonging to a different category of M2M as defined in [3]. The languages that we compare, along with their corresponding categories, General Terms are EMF Model Transformation Framework [1], a graph- Languages transformation based approach; KerMeta [7], a direct- manipulation approach; and Atlas [6] (ATL), which is a Keywords hybrid approach and is part of the official Eclipse M2M Model transformations, Model-driven development, model project. transformation languages, meta modeling Section 2 begins by first providing a brief summary of M2M 1. INTRODUCTION transformations and Eclipse Modeling Framework (EMF) Ecore models and continues with the M2M approaches that we discuss in the remainder of the paper. Section 3 outlines the procedure that we will follow in order to perform the comparison, which includes a discussion of the M2M transformation that will be attempted on all 3 languages and the various dimensions that the 3 approaches will be compared on. Section 4 presents the observations we make when using each of the respective approaches to accomplish the M2M transformation. The paper concludes with Section 5, in which we summarize our observations and provides many useful built-in collection operations such chose which tool we consider the best given our criteria. as iterators, filters, and common set operators. An ATL program is composed of rules that indicate how model 2. BACKGROUND elements are identified and subsequently modified in order This section provides brief background information on M2M to obtain the target model. transformations, EMF Ecore, and the three languages we use. Figure 1 illustrates a sample rule we have taken from the ATL user guide. The rule has a source and a target metamodel, MMAuthor and MMPerson, respectively. The 2.1 M2M Transformations Authors within the MMAuthor metamodel, denoted by !Au- M2M transformation refers to the process of modifying a thor following the source Metamodel name, are represented model to create either a new model or update itself [8]. by the variable a. Persons in the target metamodel, bound Generally model transformation can be seen as an operation to variable p, are new model objects that have their features that takes existing model elements, follows some guidelines name and surname set to name and surname found in the or rules as to what should be modified and how it should corresponding Author object. modified, and then produces either an entirely new model containing appropriate elements or the modified version of There are three types of rules in ATL: Matched rules, such the model with the new/modified elements. Model-to-model as the one presented in Figure 1 that are automatically transformations involve the process of going from platform- called; lazy rules, which are ones only executed when independent models (PIM)s to either other PIMs or from called by another rule; and called rules, which do not PIMs to platform-specific models (PSM)s not in the form of include a source pattern and may contain optional local code. variables/parameters. There are two types of execution modes in ATL: the normal mode and the refining mode. The 2.2 Ecore refining mode is used to focus on specific transformations Ecore [10] is Eclipse’s implementation of the Essential Meta- the program, for example, to transform one source model Object Facility (EMOF). It provides the M2 layer, which is element into one target model element and focus while the Ecore language that allows modelers to develop meta leaving the rest implicitly copied. models, called Ecore models. Ecore models are the M1 layer and can be used to specify systems or a family of systems r u l e Author { that can later be instantiated (M0 layer). That is, Eclipse’s from implementation allows users to develop Ecore meta models a : MMAuthor ! Author (M1 layer) to allow for instantiation of system models (M0 to p : MMPerson!Person ( layer) that can be developed within an Eclipse application. name <− a . name , A completed Ecore (meta) model allows for code generation, surname <− a . surname validation, and instantiation of Ecore instance models. It is ) widely used in both industry and research and all three of } the model transformation languages discussed in this project work with Ecore models. Figure 1: Sample ATL Rule

2.3 Languages Used 2.3.2 EMF Model Transformation Framework The three modeling transformation languages used by us The EMF Model Transformation (EMT) framework pro- for this project all work with Ecore models as we figure vides an entirely graphical interface to describe in-place this will provide a common foundation for comparison. We transformation rules on an Ecore model. It includes a attempt to select languages that are prevalent in research compiler and a code generator so that the transformations and industry, based on quantity of documentation and other created within it can be reused. EMT is built upon information sources, and that are different enough that AGG [11], which is a graph transformation tool. a comparison will exhibit the benefits and drawbacks of various approaches to achieving M2M transformation. As shown in Figure 2, the Eclipse editor is divided into Left- Hand Side (LHS) and Right-Hand Side (RHS) panes that 2.3.1 Atlas Transformation Language show how model elements are structured before and after the The ATLAS Transformation Language (ATL) is one of transformation. Optionally, a negative application condition three transformation engines within the Eclipse Model- (NAC) pane can be used to show the one or more situations To-Model subproject, which, itself, is part of the Eclipse where a rule should not be applied. Model elements in Modeling Project. The other two engines are based on the LHS can be mapped to corresponding elements in the the Query/View/Transformation (QVT) standard set by the RHS and NAC section to indicate their identity, and are Object Management Group, but their implementations are represented visually by having the same colour in those still relatively immature so we consider them out of scope panes. Unmapped elements in the LHS are deleted in the for the work in this paper. transformation and unmapped elements in the RHS are created. The example in Figure 2, is an example of a ATL is a ruled-based domain-specific language that de- transformation that will move all Eclasses with name equal scribes transformations from one Ecore metamodel to an- to ’n’ to the package with its name equal to ’p’. The other Ecore metamodel. It supports an interesting mix NAC pane indicates that any packages already containing of declarative and imperative language paradigms, and the Eclass to be moved can be ignored. EMT has been c l a s s Class2RDBMS { /∗∗ The trace of the transformation ∗/ reference class2table : Trace /∗∗ Set of keys of the output model ∗/ reference fkeys : Collection operation transform(inputModel : ClassModel ) : RDBMSModel i s do // Initialize the trace class2table := Trace.new class2table .create f k e y s := Set.new r e s u l t := RDBMSModel . new // Create tables getAllClasses(inputModel). select { c | c . i s p e r s i s t e n t } . each { c | Figure 2: Move Class Example [1] var table : Table init Table. new table.name := c.name class2table.storeTrace(c, table) result .table.add(table) approved for inclusion in the Eclipse Modeling Framework } under the name EMF-Tiger, with an initial release scheduled // Create columns for Summer 2010. getAllClasses(inputModel). select { c | c . i s p e r s i s t e n t } . each { c | createColumns(class2table . 2.3.3 KerMeta getTargetElem(c), c, ””) } Kermeta is a language intended for meta modeling but // Create foreign keys provides many features found in a general-purpose program- f k e y s . each { k | k. createFKeyColumns } ming language. It allows for navigation and manipulation end [...] of a model in an object-oriented way with a syntax heavily } influenced by Eiffel. Like ATL, KerMeta is strongly typed and supports built-in collection modifiers. M2M model transformation is accomplished in KerMeta by using actual Figure 3: Sample KerMeta Code instances located within the target model in conjunction with those from the source model. Users then implement a transformation model that uses the elements in both the the transformation will then be compared to our expected source and the target meta models to create the desired output. If they do not match, the transformation rules may elements in the target meta model. need to be debugged if we notice they do not accurately express the intended transformation. Figure 3 provides a snippet of some model transformation code used in the example from [7] of transforming object 3.1 Method of Evaluation oriented classes to database tables. It contains elements Expressing model transformations well is a difficult problem from both the source metamodel, for example classes bound because of the complexities involved. The transformation to the c variable, and the target metamodel, the table writer needs to have a mental map of both the source variable. and target meta models simultaneously and visualize the transition from one to the other. The transformation 3. PROPOSED PROCEDURE language should do as much as possible to make this task As a use case we decided to transform a tree model into easier. We focus on three independent evaluation areas for a list model. For the source and target meta models, comparison: we use the ones provided in the ATL example [4] but do not follow the rest of the example. That is, we develop 1. Expressiveness: The expressiveness of the language the ATL transformation independently. We choose this determines the complexity of the transformations that can example because it represents the common case where a be performed by the tool. We expect all the languages software project wants to change the underlying platform- to have sufficient expressive power to represent the trans- independent implementation. Without a transformation formation we wish to perform, but we will also examine language or approach to accomplish this it can be quite language elements that provide additional expressiveness. difficult to do manually. Using a common use case for these For example, we will investigate whether each language tests ensures that any differences we observe will be a result has the ability to apply transformations recursively to of the transformation tool and not due to a difference in the newly created model elements. A tool that supports the source or target meta models. choice to execute transformations recursively would be more expressive than a language that forces one option in all cases. The bulk of the testing phase will likely be taken up learning how to use each tool and in particular how to express our 2. Ease of Use: The simple design and small learning desired transformation in each tool’s syntax. However, this curve of a tool is important to its widespread acceptance, aspect of learning is also important as it will help show especially in the field of model-driven development where the the ease of adoption of each of the tools. Running the chain of tools used, that is, compilers, interpreters, parsers, tests should be a relatively simple task of invoking the IDEs, modelers, meta-modelers, is already extensive. For transformation engine within each tool. The output of example, is it more natural to use a graphical user interface or syntax to express model transformations? For syntactic user will be more familiar with. It does, however, provide transformation languages we will be considering whether excellent correspondence between the ATL statements and the structures and concrete syntax are intuitive and lend the execution state of the transformation engine. themselves well to expressing transformations. Finally, we will investigate the cohesion between the various tools and ATL is a well-rounded transformation language, with an the Eclipse/EMF framework. A tool that integrates well easy to use declarative syntax and a more expressive imper- into Eclipse and reuses concepts and terminology familiar to ative syntax. Modularity is achieved using helper functions EMF modelers will make it much easier to learn compared and transformation staging. to one that doesn’t leverage existing EMF concepts.

3. Modularization: Cuadrado and Molina [2] suggest 4.2 EMF Model Transformation Framework that modularization is an important criteria for a model We found EMT’s graphical rule editor to be far more transformation language because it promotes reusability and intuitive and comprehensible than a syntax-based transfor- helps manage complexity. Modularization can come in many mation language. The user interacts with elements of a forms and depends on the nature of the transformation model familiar to them and the visual differences between language used. Modularization constructs can be built the LHS and RHS are far more concrete than mentally into the transformation language itself, or modularity can interpreting a syntax-based rule and visualizing how it be achieved through adopted practices such as the way affects the model. By eliminating this cognitive burden transformations are decomposed. from the user, EMT’s visual editor allows users naturally sto grasp and manipulate more complex transformations easier These evaluation criteria above are of a qualitative nature than they could with a similar transformation expressed in rather than a quantitative one, but taken together should a syntax-based transformation language. provide a good insight into the maturity and effectiveness of the various transformation tools. EMT is best suited to when the source and target meta models are the same. It is possible to write transformation 4. OBSERVATIONS rules from one metamodel to another, but this requires the user to first create a reference metamodel that relates The following sections detail our impressions and experi- the source metamodel elements to the target metamodel ences working with ATL, EMT, and Kermeta in light of our elements. evaluation criteria. Unfortunately EMT does not currently have supporting 4.1 Atlas Transformation Language tools such as a debugger, profiler, test framework, et cetera. s One immediate positive we found in using ATL is the The background work required to interpret and run the complexity of model transformations can be managed by transformation rules must be written by the developer in ATL in several ways, the most basic being the use of helper Java manually and the feature to automatically generate functions. As the name implies, helper functions are used code to run the transformation appears to be broken. With by modelers to modularize transformation rules by hiding these difficulties, we were not able to run our transformation periphery details in a separate function and calling that rules in the current build. function within the rule body. This greatly increases the readability and comprehension of the transformation rule The EMT editor is easy and natural to use, but the tool and is often used to iterate and collect elements from a support and expressiveness leave a lot to be desired. These repeating or recursive model structure. issues should improve as the tool matures.

Much of the power behind ATL comes from its imperative language constructs, but we found that this makes the 4.3 Kermeta transformation code harder to read and understand. The Kermeta is a powerful language but takes a while to pick up. philosophy of ATL is to avoid these constructs in favour Unlike ATL and EMT, the metamodel is defined within the of splitting the complex transformation into two or more Kermeta language itself rather than in a separate Ecore file, simpler transformations that run in sequence. By having although, an Ecore-equivalent Kermeta model is available to modelers transform the source model first into an inter- help bridge the two formats. mediate model and then into the target model allows for the complexity of the transformation to be divided among Kermeta transformations are achieved using its object- the various transformation steps and can then be expressed oriented model navigation commands and imperative lan- using the more desirable functional constructs of ATL. guage constructs. The lack of explicit transformation rules sets it apart from both ATL and EMT. As a model trans- The distribution of ATL comes with a transformation formation language Kermeta is expressive and powerful, debugger and, similarly to Eclipse’s Java debugger, it allows however it lacks the simplicity of a rule-based language the user to set breakpoints and view the variable values of where the before and after model is clearly defined. the currently executing thread. The debugger reflects the implementation of the ATL resolve algorithm rather than The programming-language nature of Kermeta allows it a model-level view of how the transformation is evolving. to utilize common modularization paradigms from existing The debugger is beneficial if the user is already familiar programming languages, such as object-oriented program- with the ATL resolve algorithm or if they want to learn how ming, aspect-oriented programming, and generics. All it works but seems removed from the metamodel that the these techniques can be brought to bear on the model transformation problem to help reduce complexity and [8] I. Porres. Model refactorings as rule-based update increase understandability. transformations. Lecture Notes in Computer Science, pages 159–174, 2003. Kermeta’s more mature programming library also includes [9] B. Selic. The pragmatics of model-driven development. useful tools such as a unit test framework called KUnit, IEEE software, 20(5):19–25, 2003. based on Java’s JUnit framework. A test suite can be cre- [10] D. Steinberg, F. Budinsky, M. Paternostro, and ated to exercise and verify model transformations, which is E. Merks. EMF Eclipse Modeling Framework. Addison especially important for regression testing if the metamodel Wesley, second edition, 2009. or model constraints should change. [11] G. Taentzer. AGG: A graph transformation environment for modeling and validation of software. 5. CONCLUSIONS Lecture Notes in Computer Science, 3062:446–453, We compared briefly three model transformation tools, 2004. ATL; EMT; and Kermeta, for expressiveness, ease of use, and modularity by attempting the same transformation in each language. Each tool had some positive and negative characteristics. As a fully fledged programming language, Kermeta is powerful and expressive, but takes the longest to learn and was not designed with transformations in mind. EMT’s visual editor is very easy to use but the lack of automatic build tools makes running the transformations problematic. As a rule-based language with declarative and imperative constructs, ATL strikes a good balance between ease of use and expressiveness. All three tools showed instances of modularity, albeit in different forms. Of all three tools used to perform the transformation, we choose ATL as the best because it is not overly difficult to use and is still quite powerful. We found the modularity to be relatively equal to the other two tools. Seeing as ATL is being integrated into official Eclipse’s M2M project stream, we believe that it will eventually establish itself as a prevalent approach to perform M2M transformations and will hopefully prove to be the next step forward in M2M transformations and MDD adoption.

6. REFERENCES [1] E. Biermann, K. Ehrig, C. Kohler, G. Kuhns, G. Taentzer, and E. Weiss. Graphical definition of in-place transformations in the eclipse modeling framework. Lecture Notes in Computer Science, 4199:425, 2006. [2] J. Cuadrado and J. Molina. Modularization of model transformations through a phasing mechanism. Software and Systems Modeling, 8(3):325–345, 2009. [3] K. Czarnecki and S. Helsen. Classification of model transformation approaches. In Proceedings of the 2nd OOPSLA Workshop on Generative Techniques in the Context of the Model Driven Architecture, 2003. [4] C. Faure and F. Allilaire. The tree to list example. http://www.eclipse.org/m2m/atl/basicExamples_ Patterns/article.php?file=Tree2List/index.html, July 2007. [5] A. Gerber, M. Lawley, K. Raymond, J. Steel, and A. Wood. Transformation: The missing link of MDA. Lecture notes in computer science, pages 90–105, 2002. [6] F. Jouault and I. Kurtev. Transforming models with ATL. Lecture Notes in Computer Science, 3844:128, 2006. [7] P. Muller, F. Fleurey, D. Vojtisek, Z. Drey, D. Pollet, F. Fondement, P. Studer, and J. J´ez´equel. On executable meta-languages applied to model transformations. In Model Transformations In Practice Workshop, 2005.