Graph and Model Transformation Tools for Model Migration

Transcription

1 Software and Systems Modeling manuscript No. (will be inserted by the editor) Graph and Model Transformation Tools for Model Migration Empirical Results from the Transformation Tool Contest Louis M. Rose 1 (case proponent), Markus Herrmannsdoerfer 2 (editor), Steffen Mazanek 3 (editor), Pieter Van Gorp 4 (editor), Sebastian Buchwald 5, Tassilo Horn 6, Elina Kalnina 7, Andreas Koch 8, Kevin Lano 9, Bernhard Schätz 10, Manuel Wimmer 11 1 University of York, United Kingdom, louis@cs.york.ac.uk 2 Institut für Informatik, Technische Universität München, Germany, herrmama@in.tum.de 3 steffen.mazanek@gmail.com 4 Eindhoven University of Technology, The Netherlands, p.m.e.v.gorp@tue.nl 5 Karlsruhe Institute of Technology (KIT), Germany, buchwald@kit.edu 6 Institute for Software Technology, University Koblenz-Landau, Germany, horn@uni-koblenz.de 7 University of Latvia, IMCS, Latvia, elina.kalnina@lumii.lv 8 Software Engineering Research Group, Kassel University, Germany, andreas.koch@cs.uni-kassel.de 9 Kings College London, United Kingdom, kevin.lano@kcl.ac.uk 10 fortiss GmbH, Germany, schaetz@fortiss.org 11 Vienna University of Technology, Austria, wimmer@big.tuwien.ac.at Received: date / Revised version: date Abstract We describe the results of the Transformation Tool Contest 2010 workshop, in which nine graph and model transformation tools have been compared for specifying model migration. The model migration problem migration of UML activity diagrams from version 1.4 to version 2.2 is non-trivial and practically relevant. The solutions have been compared with respect to several criteria: correctness, conciseness, understandability, appropriateness, maturity and support for extensions to the core migration task. We describe in detail the comparison method, and discuss the strengths and weaknesses of the solutions with a special focus on the differences between graph and model transformation for model migration. The comparison results demonstrate tool and language features that strongly impact the efficacy of solutions, such as support for retyping of model elements. The results are used to motivate an agenda for future model migration research (including suggestions for areas in which the tools need to be further improved). 1 Introduction MDE introduces additional challenges for controlling and managing software evolution [48]. For example, when a metamodel evolves, instance models might no longer conform to the structures and rules defined by the metamodel. When an instance model does not conform to its metamodel, it cannot be manipulated with metamodelspecific editors, cannot be managed with model management operations and, in some cases, cannot even be loaded with modelling tools. Model migration is a development activity in which instance models are updated to re-establish conformance 1 in response to metamodel evolution. Problem. Model migration is a specialised form of model transformation [72], in which the source and target metamodels are similar, but not the same. Several approaches to model migration have been proposed, and each uses a particular style of model transformation. Presently, various languages are used for specifying model migration, such as a model-to-model transformation language (in the work of Cicchetti et al. [8] with the Atlas Transformation Language [39]), a language tailored to model migration (Sprinkle s language [72]), or a generalpurpose programming language (in COPE [27]). There has been little work, however, that compares the languages used for performing model migration. In particular, graph transformation languages have not previously been investigated in this context. Similarly, the correlation between language (and tool) features and the efficacy of a model migration approach have not yet been investigated. 1 The definition of conformance varies over model migration problems and over modelling technology, but usually at least requires that a model (graph) uses only those types defined by a metamodel (type graph [10]).

2 2 Louis M. Rose et al. Contribution. In this paper, we describe the outcomes of one of the transformation cases at the 2010 edition of the Transformation Tool Contest (TTC 2010). The particular case aimed at evaluating and comparing transformation approaches (i.e. language/tool combinations) in the context of model migration [65]. The comparison was conducted using the criteria discussed in Section 4 (namely: correctness, conciseness, understandability, appropriateness, maturity, and support for extensions to the core migration task) to assess the suitability of nine approaches (Epsilon Flock, COPE, GrGen.NET, Fujaba, MOLA, PETE, ATL and Java, GReTL and UML-RSDS) for implementing a migration between a subset of the UML 1.4 and 2.2 specifications. As discussed in Sections 8, 10 and 11, analysis of the comparison results has yielded guidance for selecting a migration tool, motivated an agenda for future model migration research and identified classes of transformation approaches that are well-suited to model migration. For example, the comparison results indicate that, for this specific instance of model migration, graph and model transformation tools are equally effective. Finally, the practical importance of the solutions discussed in this paper has been highlighted by Tom Morris, leader of the ArgoUML 2 project, who has stated that the solutions of this case would be directly usable as a starting point for our UML 1.4 to UML 2.x migration facility. We have nothing available to fill this hole currently, so any contributions would be hugely valuable. 3 Outline. Section 2 discusses work relating to model migration, highlighting existing tools and comparisons. Section 3 states the goals of the comparison, and discusses the formulation of three research questions that have been answered by the comparison. Section 4 presents the study object: the migration of activity diagrams from UML 1.4 to 2.2. This section also classifies model migrations as a special type of model transformations, which clarifies the novelty of the comparative study. Section 5 enumerates the steps which had to be performed on the study object to be able to answer the research questions. Section 6 outlines and classifies the subjects the transformation tools that participated in the case study and presents important aspects of their solutions for the case. Section 7 presents the results of the survey in which the TTC participants had to rate all solutions along a set of criteria. Section 8 interprets these results with respect to the research questions. Section 9 lists the threats that may affect the validity of the result together with the measures taken to mitigate them. Section 10 derives a research agenda from these empirical results. Section 11 concludes the paper TTC/ttc10forum.htm (registration required) 2 Related Work There is a large corpus of work on software evolution. In the past, studies have suggested that software evolution can account for as much as 90% of a development budget [14,52], and there is no reason to believe that the situation is different today. Although automated transformation of development artefacts can be used to manage and reduce the cost of evolution [15], engineering approaches that promote the use of automated transformation such as Model-Driven Engineering (MDE) introduce additional challenges for managing evolution [48]. For example, model-metamodel co-evolution in which models are migrated in response to metamodel evolution is an open research challenge in the field of MDE. Model Migration vs. Transformation. Conceptually, model migrations can be classified as a very special type of model transformations. Model migration involves the transformation of models without changing their modelling language and preserving as much as possible their structure and meaning. Model migrations are fundamentally different from the two transformation types that have been described most thoroughly in transformation literature [83, 49, 78]: since model migrations do not change the modelling language, they are different from socalled model translations, and since they should not change the structure of the models, they are different from so-called model rephrasings. Note that refactorings are a special case of rephrasings. Refactorings are quite different from migrations not only at the conceptual level (they change the structure of a model) but also at the technical level: while the input and output metamodel is the same for a refactoring, this is not the case for model migrations. In summary, model migrations are defined as transformations from models in one language to models in another version of the same language. Technically, model migrations adapt models to a new version of a language s metamodel. Theoretically, they raise research challenges related to semantics preservation [30]. In practice, they are typically implemented with either a dedicated migration language or with a transformation language. Model Migration Approaches. Usually, the metamodel versions share quite some similarities, as the metamodel is usually not completely changed during metamodel adaptation [72]. Consequently, migration definitions usually contain identity rules for the unchanged metamodel parts. To reduce this boilerplate code, different approaches have been proposed [67]. Manual specification approaches like Sprinkle s language [72], MCL [56] and Epsilon Flock [66] provide transformation languages that are tailored to model migration and, for example, automatically copy model elements. Operation-based approaches like Wachsmuth s

3 Graph and Model Transformation Tools for Model Migration 3 approach [84] and COPE [29] provide reusable operations that encapsulate recurring metamodel adaptations and model migrations. Metamodel matching approaches like Cicchetti s approach [8] and AML [16] automatically derive a transformation definition from the difference between two metamodel versions. The existing approaches mostly use or extend existing model transformation languages and tools. Unfortunately, there is not much work on applying graph transformation approaches to the problem of model migration. Case Studies with Model Migration Approaches. The existing model migration approaches have been evaluated in a number of case studies. The Petri net example evolution originally proposed by Wachsmuth in [84] has been employed as a toy example for a number of approaches [8, 16, 66, 84]. Herrmannsdoerfer et al. analysed the automatability of model migration in case of two industrial metamodel evolutions from BMW Car IT [27]. The practical applicability of the operation-based tool COPE has been shown by reverse engineering the model migration for the metamodel evolution of the Palladio Component Model (PCM) [29] and the evolution of all metamodels of the Graphical Modeling Framework (GMF) [31]. The matching tool AML has been evaluated by detecting the model migration between different versions of the Netbeans Java metamodel [16]. These case studies have only evaluated a single model migration tool. However, there has been relatively little work that seeks to compare several model migration approaches on practical cases of model migration. Rose et al. [66] compare Epsilon Flock to other model transformation and migration languages ATL, Ecore2Ecore, COPE using the Petri net example evolution, but they focus only on the criterion of conciseness. Rose et al. [63] describe an expert evaluation of the model migration approaches AML, COPE, Ecore2Ecore and Epsilon Flock using an example from the Graphical Modeling Framework [22], but their comparison focuses solely on tools tailored for model migration, and did not investigate general-purpose transformation languages. In particular, no existing work investigates graph transformation tools for performing model migration, and no work compares graph and model transformation tools and model migration approaches. This is an area to which the work described in this paper contributes. Comparison of Model Transformation Approaches and Tools. Existing comparisons of model and graph transformation focus on applications other than model migration. Czarnecki and Helsen [9] present a feature model to classify transformation languages according to their technical properties. Mens and Van Gorp [49] list different applications of transformation languages and tools and present functional and non-functional requirements for transformation approaches. Taentzer et al. [75] compare the graph transformation languages AGG, TGG, VIATRA, and VMTS using the well-known object-torelational transformation example. Grønmo et al. [23] compare the transformation languages CGT, AGG, and ATL using a complex refactoring example. Varró et al. [82] propose a method for comparing the performance of model and graph transformation languages. These comparisons are used here to derive criteria for the comparison of model migration approaches. Specifically, the criteria of correctness and conciseness are inspired by the work of Taentzer et al. [75] and Grønmo et al. [23]. Earlier editions of the Transformation Tool Contest (TTC) have also resulted in the publication of tool comparisons. Varro et al. [81] present the results of the AGTIVE 2007 Tool Contest in which the participants had to specify a transformation from UML activity diagrams to formal CSP processes for verification purposes. In this edition, 11 graph transformation tools participated: Tiger, TGG, PROGRESS, GrGen.NET, GReAT, VTMS, USE, MoTMoT, GrTP, MOMENT2-GT, and XL. Extended discussions of individual solutions to that case have been published as separate papers, without detailed comparisons [1, 54]. There also has been a special section on the 2008 edition of the contest: Pérez et al. [59] as well as Rensink and Van Gorp [62] introduce the different cases, the execution of the contest and its results: program refactoring, simulation of ant populations with a focus on performance, a realistic transformation from BPMN to BPEL models, and a live contest case on the domain of conference scheduling. There are separate publications for the different graph transformation tools that have been applied to the cases: MoTMoT [55], VI- ATRA2 [36], GReAT [50], EMF Tiger [3], GrGen.NET [37], Kermeta [53], and Fujaba [17]. The earlier editions have helped to improve the execution of the TTC. There also have been publications that propose techniques to improve contests that compare transformation tools. Van Gorp and Eshuis compared two solutions for transforming process models [79]: a solution implemented in Java and a solution implemented in Gr- Gen.NET. To effectively compare the two solutions, they propose a four-level framework. This framework is based on the assumption that the influence on criteria can only be attributed to language and tool features that have been used in the solutions. We follow this advice and thus only classify the features used in the solutions in Section 6. Moreover, we apply the framework by separating language-related criteria from tool-related ones and we analyse which properties of a solution could in fact be due to language- and tool-independent design patterns. Finally, we apply the framework by analysing whether or not incompletenesses and errors in solutions are just a matter of incomplete work by the solution builders. Van Amstel et al. investigate the automatic assessment of transformation quality by means of specialised metrics and associated tools [76, 77]. This is promising

4 4 Louis M. Rose et al. work, but unfortunately the required tools are not yet available for application on the scale of our study. 3 Study Goal The aim of TTC is to compare the expressiveness, usability and performance of graph and model transformation tools via a number of selected case studies. Participants apply their favourite graph or model transformation tool to one of the proposed cases, and the solutions are compared and evaluated. To contextualise the comparison described in this article, we have synthesised the following research questions from the more general aims of the contest 4 : RQ1. What are the pros and cons of the different transformation tools considering model migration? By comparing the solutions, we are able to identify the pros and cons of the different tools concerning the model migration case. This research question is aimed at aiding prospective users of transformation languages and tools in selecting the right technology for model migration. RQ2. Which classes of transformation tools are especially well-suited for realising a model migration? By clustering solution features, we can analyse across languages and tools which combinations of features have proven successful for solving the case. This research question is aimed at aiding language and transformation tool developers in improving their technology for model migration. RQ3. How do graph transformation tools compare to model transformation (and migration) tools in a model migration scenario? This research question aims at analysing whether there are any differences between graph transformation tools and model transformation (and migration) tools. At the same time, we want to stimulate a more general discussion about graph vs. model transformation and derive a research agenda that aims to combine the strengths of all approaches. language today, and hence it is likely to be familiar to participants of the contest (i.e. the study). (2) Existing UML tools have a need for migrating between different versions of the UML specification, as evidenced by Morris s statements (cf. Section 1). (3) The migration of activity diagrams between versions 1.4 and 2.2 of the UML specification is non-trivial: the evolution involved changes to the underlying semantic model of activity diagrams. In UML 1, activities were defined as a special case of state machines, while in UML 2, they are defined atop a variant of coloured Petri nets [70]. The remainder of this section briefly introduces UML activity diagrams, outlines the way in which activity diagrams have evolved between the versions 1.4 and 2.2 of the UML specification, and describes the criteria used to compare the tools and languages applied to migrate an activity diagram from UML 1.4 to UML Activity Diagrams in UML In both UML 1.4 and 2.2, activity diagrams are used for modelling workflows, such as business processes or system behaviour [58]. Fig. 1 shows an activity diagram for the sales process of an online retailer. The diagram is partitioned into three swimlanes, representing different organisational units. Activities are represented with rounded rectangles and transitions with directed arrows. Fork and join nodes are specified using a solid black rectangle. Decision nodes are represented with a rhombus. Guards on transitions are specified using square brackets. For example, in Fig. 1, the transition to the restock activity is guarded by the condition [not in stock]. Text on transitions that is not enclosed in square brackets represents a trigger event. In Fig. 1, the transition from the Restock activity occurs on receipt of the asynchronous signal called receive stock. Finally, the transitions between activities might involve interaction with objects. In Fig. 1, the Fill Order activity leads to an interaction with an object called Filled Order. 4 Study Object For the comparative study presented in this paper, several examples of model migration were considered by the case submitters. The metamodels defined in the Graphical Modeling Framework [22] and UML [58] were considered carefully, since they have undergone several significant revisions of industrial relevance. The migration of activity diagrams between versions 1.4 and 2.2 of the UML specification was selected for three reasons: (1) UML arguably is the most well-known modelling 4 cf. option=com_content&id= Evolution of Activity Diagrams Between versions 1.4 and 2.2 of the UML specification, the metamodel for activity diagrams underwent significant changes. In particular, activities are now represented in Petri net concepts, such as places and transitions 5, rather than state machine concepts, such as states and transitions. Fig. 2 highlights the main changes to the activity diagrams part of the UML metamodel between versions 1.4 and 2.2 of the UML specification. For clarity, Fig. 2 omits some metamodel elements that were 5 In the metamodel, these concepts are still called nodes and edges.

5 Graph and Model Transformation Tools for Model Migration 5 Customer Sales Stockroom Request Service Placed Order Take order Entered Order [not in stock] [in stock] Restock receive stock Pay Filled Order Fill order Collect order Delivered Order Deliver order Fig. 1 Example of an activity diagram based on [57]. This diagram conforms to the concrete syntax defined for activity diagrams in both the UML 1.4 and the UML 2.2 specifications. not affected by the changes made in the UML 2.2 specification. The subfigures show classes that correspond to each other in roughly the same positions. To migrate an activity diagram from UML 1.4 to UML 2.2 (Fig. 2), the following metamodel changes must be addressed: ActivityGraphs are now represented as Activitys. The top and transition references are now represented using the nodes and edges references. Partitions are now represented as Activity- Partitions. The contents reference is now represented using the nodes and edges references. ActionStates are now represented as OpaqueActions. Pseudostates are now represented as a subtype of ActivityNode, such as InitialNode or Fork- Node. Transitions are now represented as ObjectFlows or ControlFlows. Guards are now represented as OpaqueExpressions. Note that the changes above refer only to abstract syntax, and do not mandate changes to the concrete syntax. This is because no changes were made to the concrete syntax of activity diagrams between UML 1.4 and UML 2.2 [73]. To facilitate the comparison of model migration solutions (Section 6), the activity diagram shown in Fig. 1 was migrated by hand to conform to the UML 2.2 specification. The migrated model was checked by a UML expert, and used as a reference by solution developers. Solutions were assessed according to the criteria in Table 1. Note that this study does not question whether or not generic graph and model transformation approaches are sufficiently expressive for the manual specification of the migration from UML 1.4 and 2.2: Habel and Plumb have demonstrated that three very basic language features are sufficient for computational completeness [24]. The vast majority of graph and model transformation languages provide these features. Therefore, this comparative study focuses on criteria such as conciseness and understandability rather than expressiveness. Even if operation-based approaches or approaches based on metamodel matching would turn out to be superior to approaches for the manual specification of migrations, it remains interesting to learn which of the general model and graph transformation approaches perform best in a migration context: the existing specialised approaches mostly use or extend existing model transformation languages and tools and therefore it is interesting to analyse which generic approach would be the best basis for building migration-specific extensions. By involving an operation-based approach in this comparative study, we want to learn (1) whether it makes sense to extend generic approaches with a migration-specific library of operations and (2) which generic approach provides the best basis if such an extension makes sense.

6 6 Louis M. Rose et al. ModelElement name: String * contents StateMachine ActivityGraph * transitions Guard * source 0..1 Transition StateVertex guard outgoing * incoming 1 target 1 * subvertex partition * Partition 1 expression BooleanExpression language: String body: String «enum» PseudostateKind initial = 0 join = 1 fork = 2 junction = 3 Pseudostate kind: PseudostateKind State 1 top FinalState ActionState ObjectFlowState CompositeState isdynamic: Boolean (a) Metamodel for activity diagrams in UML 1.4, based on [57]. ModelElement name: String Activity OpaqueExpression language: String body: String 0..1 guard ActivityEdge * edges nodes * groups * * outgoing * incoming * edges source 1 target 1 ActivityNode * nodes ActivityPartition ControlFlow ObjectFlow InitialNode JoinNode ForkNode ActivityFinalNode OpaqueAction ObjectNode DecisionNode (b) Metamodel for activity diagrams in UML 2.2, based on [58]. Fig. 2 The evolution of activity diagrams between UML 1.4 and UML 2.2.

7 Graph and Model Transformation Tools for Model Migration 7 Table 1 Criteria for evaluation by participants. Name Description Correctness Does the transformation produce a model equivalent to the migrated UML 2.2 model included in the case resources? Furthermore, does the transformation specification facilitate reasoning about the correctness of the migration process? Conciseness How much code is required to specify the transformation? Sprinkle et al. [72] proposed that the amount of effort required to codify migration should be directly proportional to the number of changes between original and evolved metamodel. Understandability How easy is it to read and understand the transformation? Appropriateness How suitable is the tool for the specific application defined by the case? Tool Maturity How mature is the tool? Extensions To what extent have the extensions defined by the case been solved? (See Section 4.3) 4.3 Extensions For the extensions criterion (Table 1), the solutions were compared by considering the extent to which they were applied and could be applied to address three extensions to the core task. The extensions are now discussed. Extension 1: Alternative Object Flow State Migration Semantics. Prior to the TTC workshop, discussion on the forums 6 revealed an ambiguity in the UML 2.2 specification indicating that the migration semantics for the ObjectFlowState UML 1.4 concept are not clear from the UML 2.2 specification. The case was revised to incorporate both the original semantics (core task) and an alternative semantics (extension) for migrating ObjectFlowStates. In the core task, instances of ObjectFlowState are migrated to instances of ObjectNode. Any instances of Transition that had an ObjectFlowState as their source or target were migrated to instances of ObjectFlow. Fig. 3 shows an example application of this migration semantics. Structures such as the one shown in Fig. 3(a) are migrated to an equivalent structure shown in Fig. 3(b). The Transitions, t1 and t2, are migrated to instances of ObjectFlow. Likewise, the instance of ObjectFlowState, s2, is migrated to an instance of ObjectNode. This extension considered an alternative migration semantics for ObjectFlowState. For this extension, instances of ObjectFlowState (and any connected Transitions) were migrated to instances of Object- Flow, as shown in Fig. 3(c), in which the UML 2.2 ObjectFlow, f1, replaces t1, t2 and s2. Extension 2: Concrete Syntax. The second extension relates to the appearance of activity diagrams. The UML specifications provide no formally defined metamodel for the concrete syntax of UML diagrams. However, some 6 index.php?option=com_community&view= groups&task=viewgroup&groupid=4&itemid=150 (registration required) UML tools store diagrammatic information in a structured manner using XML or a modelling tool. For example, the Eclipse UML 2 tools 7 store diagrams as GMF [22] diagram models. Between versions of 1.4 and 2.2 of the UML specification, there were no changes to the concrete syntax of activity diagrams [73] and hence this extension relates to migration in response to adaptive evolution (making a system compatible with a change to platforms or technologies that underpin its implementation) [71, ch. 21]. To this end, submissions were invited to explore the feasibility of migrating the concrete syntax of the activity diagram shown in Fig. 1 to the concrete syntax in their chosen UML 2 tool. To facilitate this, the case resources included an ArgoUML project 8 containing the activity diagram shown in Fig. 1. Extension 3: XMI. The UML specifications [57, 58] indicate that UML models should be stored using XMI. However, because XMI has evolved at the same time as UML, UML 1.4 tools most likely produce XMI of a different version to UML 2.2 tools. For instance, ArgoUML produces XMI 1.2 for UML 1.4 models, while the Eclipse UML2 tools produce XMI 2.1 for UML 2.2. As an extension to the core task, submissions were invited to consider how to migrate a UML 1.4 model represented in XMI 1.2 to a UML 2.2 model represented in XMI 2.1. To facilitate this, the UML 1.4 model shown in Fig. 1 was made available in XMI 1.2 as part of the case resources 9. This extension was more technical in nature than the other extensions, and was included to assess the way in which solutions could be applied for model migration in realistic scenarios. 4.4 Summary The study object is a model migration for one of the diagram types defined in UML, activity diagrams. The louis/ttc/

8 8 Louis M. Rose et al. s1 : State src t1 : Transition dst s2 : ObjectFlowState src t2 : Transition dst s3 : State (a) ObjectFlowState structure in UML 1.4. s1 : ActivityNode src t1 : ObjectFlow dst s2 : ObjectNode src t2 : ObjectFlow dst s3 : ActivityNode (b) Equivalent ObjectNode structure in UML 2.2 (core task). s1 : ActivityNode src s2 : ObjectFlow dst s3 : ActivityNode Fig. 3 ObjectFlowState migration semantics. (c) Equivalent ObjectFlow structure in UML 2.2 (extension 1). abstract syntax of activity diagrams underwent significant changes between versions 1.4 and 2.2. of the UML specification, which changed the underlying semantics. Although the appearance (i.e. concrete syntax) of a UML activity diagram did not change between UML 1.4 and UML 2.2. (see Fig. 1), the way in which activities are modelled (i.e. abstract syntax) changed significantly (see Fig. 2). 5 Study Execution The organisers of the contest devised the following steps to carry out the contest: 1. Submission of solution: Potential participants submitted solutions for the migration case to the contest. A valid submission consists of an installation in a remote virtual machine to make the solution reproducible, an accompanying document of no more than 5 pages which describes the solution, and an appendix with the full listing of the solution. The solution descriptions typically focus on the strengths of the submitted solution, but participants were encouraged to fairly refer to disadvantages too. The participants could also discuss the case in a forum that was set up by the organisers. 2. Review of solution: The submitted solutions were reviewed by experts in the domain of graph and model transformation to evaluate them with respect to validity for the contest. As a result, a number of submitted solutions were accepted for the contest. 3. Peer review: Workshop participants were invited to investigate the solutions of other participants ahead of the workshop. The virtual machines as well as the solution descriptions were made available a month before the workshop, so participants could prepare for an informed judgement. Opponents (discussed in step 5) were assigned at this point. 4. Presentation of solution: The participants presented their solution at the workshop in front of all other participants. The presentation was restricted to 10 minutes. During their presentation, the participants were given the freedom to point to these aspects that they considered most relevant for winning the contest. The other participants of the contest could use the installation in the remote virtual machine to play with the solution and tool. 5. Presentation of opponents: To compensate for the threat that some attendees had not investigated all solutions before the workshops, each submission needed to have two opponents that critically analysed the solution before the workshop. Both opponents presented the found issues and open questions together in a 5 minute slot. 6. Evaluation of solution: All the contest participants were requested to fill out an evaluation sheet for each solution in parallel to the presentation. The evaluation sheet considered the criteria presented in Table 1 and required participants to score each solution with respect to each criterion. Based on the obtained points, the organisers awarded the best solutions for each case. 7. Statistical analysis: The organisers and case submitters analysed the survey outcomes statistically based on a relevant subset of the transformation comparison criteria that are described in literature. 8. Reflection: Based on the combined results of the workshop evaluations and the additional expert assessment, the organisers evaluated the effectiveness of these research steps and planned follow-up actions. While steps 1 and 2 were conducted before the workshop took place, steps 3 to 5 were conducted at the workshop and steps 6 to 8 were conducted afterwards. 6 Study Subjects and their Solutions Table 2 lists the subjects that participated in the case study (in the order of the overall ranks assigned by the contest participants). For each subject, we mention the

9 Graph and Model Transformation Tools for Model Migration 9 name of the approach, classify the relevant tool and language properties and characterise the solution design. Solution. The solution is characterised by the extensions it implements and a reference to a more detailed solution description. This reference also provides a link to the remote installation of the tool which allows readers to reproduce the solution, and to apply it to additional input models. Tool. We classify a tool according to whether it originates from the domain of graph or model transformation. In the domain of graph transformation, models are called graphs, and metamodels are called type graphs [10]. In the case, models basically are node- and edgetyped graphs with inheritance between node types, as can be seen in Fig. 2(a) and Fig. 2(b). Due to a lot of theoretical work, graph transformation is already a very mature domain, whereas model transformation is still a comparably young discipline. In addition, we distinguish tools that are tailored to migration and general-purpose transformation tools. Finally, we classify tools based on their cognitive support for the development of model migrations. Some tools provide a visualiser of the differences between input and output metamodels (DIFF in Table 2) while other tools provide rule-based debuggers with support for visualising intermediate models (DBG in Table 2). Language. Concerning the way the migration is defined, we distinguish declarative and imperative languages. Declarative languages focus on what needs to be transformed into what by defining a relation between the source and target models, whereas imperative languages focus on how the transformation itself needs to be performed by specifying the steps that are required to derive the target models from the source models [49]. In addition, we distinguish languages with a graphical syntax from those with a textual syntax (resp. GR vs. TXT in Table 2). Moreover, we distinguish first-class languages from embedded languages (external vs. internal in Table 2). First-class languages have their own compiler or interpreter while languages embedded into an existing host language use the constructs provided by that host. Some languages support the retyping of model elements (RT in Table 2). Finally, some languages provide a comprehensive library of reusable migration operations (Lib. in Table 2) which can reduce the specification effort for solving individual case studies significantly. Modes. Finally, we consider the execution mode (inplace vs. out-of-place) as well as the termination mode. For in-place transformations the target is the same model or graph, for out-of-place transformations the target is a new model or graph [49]. Note that various transformation approaches support in-place as well as out-of-place transformation designs. Similarly, some languages support multiple approaches to transformation termination. For example, languages supporting explicit control flows for scheduling rules (CF in Table 2) typically also support the step-wise destruction of the input graph (DE- STR in Table 2) for controlling rule termination [81]. However, some languages provide a single rule scheduling algorithm, meaning that scheduling and hence termination is specified implicitly (IMPL in Table 2). Note that we classified the transformation language features used in the solution and not all language features, since unused features do not contribute to the quality of a solution. In the following, we provide for each subject a short solution description as well as the opponent statements that were presented at the workshop. The following subsections give the reader a brief summary of the solution descriptions, presentations and opponent statements in order to make the complete process as transparent as possible. Note that this leads to some unbalance in the solution descriptions but this is compensated by a subsequent section. Moreover, each solution description covers at least (1) a transformation definition fragment showing the mapping of action state nodes, (2) a discussion of how this fragment is embedded in the overall transformation definition, and (3) a description of the most interesting tool feature. Note that Table 2 contains additional classification criteria, as explained above. 6.1 Epsilon Flock Epsilon Flock (subsequently referred to as Flock) [66] is a model transformation language tailored for model migration. With respect to the classification in Table 2, Flock is a declarative, textual and external language and its transformations are executed out-of-place and termination is implicit. While transformation languages typically either create models afresh or update models in-place, Flock uses an alternative strategy, which is tailored for model migration and termed conservative copy. In conservative copy, model elements that conform to both the source and target metamodel are automatically copied from the source to the migrated model. Moreover, any model elements that do not conform to the target metamodel are not copied. Compared to Sprinkle s language [72] and MCL [56] which provide similar copying strategies for migration, conservative copy is extensible (i.e. facilitates variation in conformance constraints to support, for example, migration between differing modelling technologies) and finer-grained (i.e. applies to feature values as well as model elements). Migration of ActionStates. When executed, a Flock migration strategy first invokes conservative copy and then invokes any user-defined rules (namely: retypings, deletions or migrate blocks). User-defined rules are used to guide and customise the conservative copy. For example, Listing 1 shows a user-defined rule (for the UML

10 10 Louis M. Rose et al. Table 2 Overview of the study subjects. Solution Tool Language Modes Subject Ext. Ref. Dom. Purpose Cognit. Paradigm Syntax Impl. RT Lib. Exec. Term. Flock 1, 3 [64] model migration none declarative TXT external yes no OO-place IMPL COPE 1 [26] model migration DIFF imperative GR a /TXT b ext a /int b yes yes in-place IMPL GrGen.NET 1 [5] graph transform. DBG declarative TXT external yes no in-place DESTR Fujaba 1, 3 [42] graph transform. DBG imperative GR external no no OO-place CF MOLA [40] model transform. none imperative GR external no no OO-place CF PETE 1 [68] model transform. none declarative TXT internal yes no OO-place IMPL ATL/Java 1, 2 [7] model transform. none declarative TXT external no no OO-place IMPL GReTL 1 [33] graph transform. none imperative TXT internal no no OO-place IMPL UML- RSDS [43] model transform. none declarative TXT external no no OO-place IMPL a history model b migration language activity diagram migration case) that instructs conservative copy to create an OpaqueAction in the target model for each ActionState in the source model. Features of the source ActionStates that conform to equivalent features in OpaqueAction are automatically copied by Flock. Listing 1 Migrating UML 1.4 ActionStates with Epsilon Flock. 1 retype ActionState to OpaqueAction Overall Transformation. The Flock migration strategy for migrating UML 1.4 to UML 2.2 activity diagrams is written using retypings (an example of which is shown in Listing 1) and migrate blocks to change the values of features after conservative copy has been invoked. For example, the migrate block of Listing 2 is executed on every Guard in the source model and produces an OpaqueExpression (as specified by the retyping). Values are copied automatically from the source to the target model element when conformance would not be affected. For example, Guard and OpaqueExpression both define a feature, name, with the same type and multiplicity. Consequently, the name of a Guard is automatically copied to the corresponding OpaqueExpression before the body of the migrate block is executed. After conservative copy has copied names and other conformant values, the body of the migrate block is executed for each Guard. A more detailed discussion of the structure and semantics of conservative copy is available [66]. Notable Feature. The platform atop which Flock is implemented, Epsilon, contributes a model connectivity layer, EMC. The languages developed atop Epsilon access models via EMC and, hence, are decoupled from implementation details of a particular modelling technology. Consequently, programs written in Flock (and the other Epsilon languages) can be executed on models represented in a range of modelling technologies: EMC currently supports EMF, MDR, Z and XML. For the UML activity diagram migration, the same Flock program could be used to migrate both the XMI 1.x (MDR) and the XMI 2.x (EMF) models. Hence, Flock implements the third extension of the activity diagram case without the need for any additional code: the user simply specifies which modelling technology will be used before launching the Flock program. EMC can be extended for use with further modelling technologies by implementing Epsilon s IModel interface and specifying an Eclipse extension. Listing 2 Migrating UML 1.4 Guards with Epsilon Flock 1 retype Guard to OpaqueExpression 2 migrate Guard { 3 migrated.body.add(source.expression.body); 4 } Summary. The solution presented in this section makes use of the conservative copy and model connectivity layer of Epsilon Flock. The former has been applied to minimise the amount of duplicated (i.e. boilerplate) code by automatically copying model elements and feature values that are not affected by metamodel evolution. The latter has been applied to facilitate migration between models that are specified in different formats, namely XMI 1 and XMI 2. Opponent Statements (Cicchetti, Buchwald). Flock allows for concise and understandable model migration programs thanks to the conservative copying strategy. Furthermore, several metamodelling languages and model formats are supported by reusing the model connectivity layer EMC. However, how well different metamodelling languages may be supported by EMC, and subsequently, how well Flock applies for evolution scenarios of metamodels implemented with metamodelling languages besides Ecore has to be explored more deeply in the future. Finally, it has to be noted that a DSL approach allows for concise migration programs, but at the same time, additional effort is necessary to learn a new language for model migration instead of reusing an existing transformation language. Flock uses some implicit assumptions that allows for a concise solution: if an element of the original model and its counterpart in the migrated model have an attribute or edge with the same name, they are considered semantically equivalent. This assumption is true for this case study, but can be very error-prone in general. A more

11 Graph and Model Transformation Tools for Model Migration 11 conservative approach would be to consider attributes or edges as semantically equivalent if and only if they belong to a common superclass of both model elements. 6.2 COPE COPE 10 [29] is a model migration tool that records the metamodel adaptation as a sequence of operations in a history model. The operations can be enriched with instructions for model migration to form so-called coupled operations. COPE provides two kinds of coupled operations reusable and custom which vary according to the level of automation required for model migration [29]. Reuse of recurring migration specifications allows to reduce the effort associated with building a model migration [27]. COPE thus provides reusable coupled operations which make metamodel adaptation and model migration independent of the specific metamodel through parameters and constraints restricting the applicability of the operation. Currently, COPE comes with a library of over 60 reusable coupled operations [32]. Migration specifications can become so specific to a certain metamodel that reuse makes no sense [27]. To express these complex migrations, COPE allows the user to define a custom coupled operation by manually encoding a model migration for a metamodel adaptation in a Turing-complete coupled evolution language [28]. With respect to the classification in Table 2, COPE uses an imperative language and its migrating transformations are executed in-place and termination is implicit. Reusable operations are applied with a graphical, external language and custom operations with a textual, internal language. COPE also provides cognitive support with its difference visualiser. Migration of ActionStates. As shown in Listing 3, the mapping of ActionStates to OpaqueActions is implemented by the reusable coupled operation Rename which consistently renames a metamodel element on both the metamodel and model level. In COPE, both metamodel adaptation and model migration are specified as in-place transformations, requiring only to specify the difference on both levels. In order to do so, COPE softens the conformance of the model to the metamodel within a coupled operation, but ensures conformance at the boundaries of the coupled operation by means of a transaction mechanism. Listing 3 Migrating ActionStates with COPE. 1 rename(minuml1.actionstate, "OpaqueAction") Overall Transformation. Fig. 4 shows part of the history model. The Rename of ActionStates is one of the 40 coupled operations that were applied to solve the case, 10 along with further reusable coupled operations for deleting features, inlining a super class and making a class abstract, among others. With the exception of 1 custom coupled operation, the migration can be specified with reusable coupled operations. Therefore, the result is similar to the real-life case studies that have been performed using COPE [27, 31]. From the recorded history model, a migrator in the coupled evolution language can be generated which allows to automatically migrate models. Notable Feature. To record the history model, COPE provides a seamless integration into the existing EMF metamodel editor, as shown in Fig. 4. The user can adapt the metamodel by applying reusable coupled operations through the operation browser. The operation browser allows to set the parameters of a reusable coupled operation, and gives feedback on its applicability based on the constraints. The user needs to perform a custom coupled operation only, in case no reusable coupled operation is available for the change at hand. First, the metamodel is directly adapted in the metamodel editor, in response to which the primitive changes are recorded in the history. A migration can later be attached to the sequence of metamodel changes. If COPE was not used for adapting the metamodel like for the case, the history model needs to be recovered from the two metamodel versions. COPE provides tool support to reverse engineer the history model, also shown in Fig. 4. As a prerequisite, the source metamodel version is loaded directly in the metamodel editor, together with its initial history. The target metamodel is displayed in the so-called convergence view that also displays the difference model resulting from the comparison between the source and target metamodel. By means of the operation browser, the user can apply reusable coupled operations to bring the source metamodel nearer to the target metamodel. After an operation is executed on the source metamodel, the difference is automatically updated to reflect the changes. Summary. To not lose the intention behind the metamodel adaptation, COPE records the model migration together with metamodel adaptations through coupled operations. COPE provides reusable coupled operations to significantly reduce the effort required to specify a model migration. To record the coupled evolution, COPE is seamlessly integrated into the metamodel editor used to perform the metamodel adaptation. COPE provides special tool support to reverse engineer the coupled evolution from two metamodel versions. Opponent Statements (Meyers, Jubeh). COPE is well integrated into Eclipse, thus benefiting optimally from Eclipse features such as browse trees, separate views, etc., which are familiar to metamodellers. Even though almost every aspect of the metamodel changes in the

12 12 Louis M. Rose et al. source metamodel history model Metamodel Editor difference model target metamodel Operation Browser Convergence View Fig. 4 User interface of COPE. case, COPE scales very well to such revolutions, requiring only one custom coupled operation. This is caused by the modularity of the approach treating the model migration of different metamodel changes separate from each other. However, the migration of reusable coupled operations is fixed, requiring the specification of a custom coupled operation, in case a different migration semantics is required. Moreover, additional effort is necessary to learn a new language to specify custom coupled operations. Finally, it is hard to determine the effort for specifying the model migration. While the migration only needs to be specified manually for custom coupled operations, effort is also necessary to apply reusable coupled operations. 6.3 GrGen.NET GrGen.NET 11 [37] is a general purpose graph rewrite system developed at the Karlsruhe Institute of Technology (KIT). It offers a fully featured metamodel, highly expressive rules which get executed very fast [18], programmed rule control, and graphical debugging. With respect to the classification in Table 2, GrGen.NET is a declarative, textual and external language and its transformations are executed in-place. Termination occurs following the step-wise destruction of the input graph. Migration of ActionStates. Listing 4 shows the transformation from an ActionState to an OpaqueAction, with a graph rewrite rule in GrGen.NET syntax. Listing 4 Relabelling of ActionState to OpaqueAction. 1 rule transform_actionstate { 2 state:minuml1_actionstate; 3 4 modify { opaque:uml_opaqueaction<state>; 6 7 eval { opaque._name = state._name; } 8 } 9 } Rules in GrGen.NET consist of a pattern part specifying the graph pattern to match and a nested rewrite part specifying the changes to be made. The pattern part is built up of node and edge declarations or references: Nodes are declared by n:t, where n is an optional node identifier, and t its type. References employ the same syntax omitting the colon and type. An edge e with source x and target y is declared by x -e:t-> y. The rewrite part is specified by a modify block nested within the rule. Usually, here one would add new graph elements or delete old ones, but for this case they should only be retyped. Retyping (i.e. relabelling) is specified with the syntax y:t<x> which defines y to be a retyped version of the original node x, retyped to the new type t; for edges the syntax is -y:t<x>->. More information can be found in the extensive GrGen.NET user manual [4]. Overall Transformation. Fig. 5 illustrates the structure of the GrGen.NET solution [5]. Before the transformation can take place, the activity diagram needs to be imported from an Ecore file describing the source metamodel and an XMI file specifying the input model. Afterwards the resulting activity diagram has to be exported into an XMI file that conforms to a given Ecore file describing the target model. UML 1.4 model (Ecore) Activity (XMI) UML 1.4 model (GrGen) Activity (GrGen) UML 2.2 model (GrGen) Activity (GrGen) UML 2.2 model (Ecore) Activity (XMI) conforms to imported from transformation exported to Fig. 5 Structure of the GrGen.NET solution.

13 Graph and Model Transformation Tools for Model Migration 13 The import is handled by an import filter supplied with GrGen.NET generating an equivalent GrGen.NET-specific type graph (i.e. a graph model file) from a given Ecore file. Afterwards the XMI adhering to the Ecore model is imported by the filter as an instance graph of the just generated equivalent GrGen.NET graph model to serve as the host graph for the following transformation. The export is handled by several graph transformation rules that traverse the graph hierarchically while emitting the corresponding XMI tags. The transformation of the core task complies to the following scheme: For each node or edge type, there is one rule relabelling an element of this type, often containing nothing more than this relabelling, sometimes using alternatives to decide between possible target types depending on the context. In the controlling sequence, a postfix star operator is used to apply each of these rules exhaustively, and an infix bar operator (denoting strict logical disjunction) is used to execute one rule after the other, as e.g. in transform_actionstate*... First all node types are processed, then all edge types (thus a few context dependent rules match against nodes or edges of types from the source and target model). Notable Features. The first extension task requires to transform a node of type ObjectFlowState linked to nodes of type Transition to a node of type Object- Flow. This requires general graph rewriting, instead of only graph relabelling. As GrGen.NET is a graph rewrite system in the first place, this was easily handled with a single additional rule [5]. GrGen.NET does not offer a concrete syntax editor for which one could request concrete syntax migration as required by the second extension task, because the tool was originally developed for handling compiler intermediate language graphs which do not possess a user drawn layout. However, as the ultimate goal of a concrete syntax is a nice layout, a solution of a different kind is presented: the tool includes a highly customisable graph viewer with automatic layout which results in a diagram with concrete syntax very similar to that of activity diagrams, as can be seen in Fig. 6. Summary. Employing graph relabelling rules one rule for each node type and one rule for each edge type we were able to give a concise and very simple solution to the model migration task. Transforming nodes independent from their incident edges provides a degree of modularity that surpasses the other solutions. Opponent Statements (Kalnina, Rahimi). GrGen.NET is a general purpose graph rewriting system. The given model migration case often involves renaming the types (retyping) of existing model elements i.e. nodes and edges. Therefore the proposed solution which mainly uses rules for retyping nodes and edges is quite appropriate. Knowing the graph retyping syntax for nodes (y:t<x>) and edges (-y:t<x>->), it is quite easy to understand the transformation rules. However, if the reader is not familiar with the syntax, it could be hard to guess what is done in these rules. Moreover, the organisation of the solution could be better; especially the description of the execution order is hard to understand. Also, the transformation definition contains the concrete names of the input and output model, which restricts the flexibility in applying the definition. Regarding conciseness, the amount of textual transformation code is quite small. However, the amount of code does not depend on the size of the metamodel changes but on the size of the metamodel itself, which is undesirable [72]. This is because the source and target metamodel elements are located in different packages and package names are included in type names. However, in this migration case all metamodel classes were modified either way. Regarding correctness, the XMI export could not be validated in the Eclipse environment. However, the approach proposed for visualisation of results is quite convincing and interesting. 6.4 Fujaba The Fujaba Tool Suite 12 [6] allows graphical modelling of applications using the Story Driven Modeling methodology [86]. With respect to the classification in Table 2, Fujaba is an imperative, graphical and external language and similarly to GrGen.NET, transformations update one host graph in-place. However, the submitted Fujaba solution realises the migration using an out-of-place design on a subgraph. The submitted solution consists of a simplified UML 1.4 to UML 2.2 migration transformation which reads an XMI file as input and writes a corresponding XMI2 file as output. The transformation is completely specified using Story Driven Modeling (SDM). Story diagrams are graph rewrite rules embedded in activity diagrams that allow to query and modify the application s instance graph on a high level of abstraction. Activities contain individual graph rewrite rules. A graph rewrite rule consists of a graph pattern that should be matched in the host (i.e. instance) graph. Patterns are syntactically similar to object diagrams, but also include graph/object modifications. Object or link creation is denoted by the create stereotype and green colour. Furthermore, names can be updated via attribute assignment expressions. Migration of ActionStates. The mapping of Action- States to OpaqueActions is specified with the story diagram in Fig. 7. In the first pattern the Opaque- Action is created and its attributes are set. The sec- 12

14 14 Louis M. Rose et al. Fig. 6 Configured-automatic layout of the resulting GrGen.NET graph. Fig. 7 Story diagram to migrate ActionState elements. is now traversed following all transitions between state vertices in a depth-first manner. We remember already transformed states with StateMapping instances, so a path joining an already traversed path will terminate the transformation for that branch. Of course, this approach relies on valid input models with exactly one initial node. Each state and transition migration is specified in a story diagram comparable to Fig. 7. To adapt to changed requirements (e.g. the different transformation criteria in Extension 1) a transformation can be exchanged easily by means of object-oriented method overriding. Fig. 8 Story diagram for addnodetopartition. ond pattern contains a collaboration statement (add- NodeToPartition(sourceState, node)) to add the new OpaqueAction its partition. The corresponding method is also defined by a story diagram (Fig. 8). Overall Transformation. A central migration class refers to both the input graph as UML1.4 ActvityGraph and the output graph referenced by a UML 2.2 Activity. It remembers already migrated states via a StateMapping pointing to elements of both metamodels. The transformation is started by searching and migrating the initial state. In the following, the input graph Notable Features. Using the Story Driven Modeling methodology an application can be developed with graphical modelling solely. As mentioned before, story diagrams provide a programming language independent way to specify graph/object modifications. To generate executable source code for an application, a template-based (and therefore customisable) code generator is contained. The edobs debugger visualises the current heap of a Java program at runtime as a UML object diagram e.g. the graph elements during the transformation steps. Using the debugger, the modelled graph transformations can be applied to elements of the object diagram at runtime. Fig. 9 shows such a heap visualisation. The figure also shows that the submitted migration solution provides traceability links (of type StateMapping) from source to target elements for later uses. Opponent Statements (Sostaks, Rensink). The Fujaba Tool Suite is a well known modelling tool. Unlike classical graph rewriting approaches such as TGG or AGG, Fujaba Story Diagrams embed graph rewrite rules in UML-like activity diagrams. In such a way the execution flow of migration transformation is shown clearly at the same time having the advantage of declarative syntax for graph rewriting rules. This is the biggest advantage of Fujaba, and transformations can be understood even by non-experts. However, some improvements of readability can still be made. For example, the submitted solution contains

15 Graph and Model Transformation Tools for Model Migration 15 Fig. 9 Object graph of two connected ActionStates after its migration. a long explicit conditional that could have been refactored into a generic controller. A Story Diagram based solution to the 2007 UML2CSP contest challenge illustrates how Java reflection can support this [21]. Readability decreases also by using non-domain elements (like StateHandler) in the graph rewriting rules and mixing them with domain-specific elements. It would be better to have a generic library instead. The opponents have no doubt that the Fujaba Tool Suite offers great technical support for building model transformations. Besides the very useful edobs debugger, Fujaba provides very useful testing facilities. In particular, JUnit tests, which are familiar to Java developers, have been used for verifying the submitted solution. The specification effort is considered relatively small by the opponents, but the organisers note that it does not satisfy Sprinkle s criterium (see Section 4). The only utility, which had to be implemented in Java, is the XMI import and export facility. Although a reflective mechanism has been used for XMI import, it seems that a slight adaptation of the importer is still needed for other use cases. 6.5 MOLA MOLA 13 [41] is a graphical transformation language developed at the University of Latvia. It is based on traditional concepts from existing transformation languages. The formal description of MOLA as well as the MOLA tool can be downloaded from the MOLA homepage. The MOLA language is conceptually very comparable to Story Diagrams, but its metamodel (abstract syntax) differs significantly to that of Story Diagrams as implemented in Fujaba. With respect to the classification in Table 2, MOLA is an imperative, graphical and external language and its transformations are executed out-of-place. Control flow is specified explicitly with dedicated constructs. Rules and foreach loops are the main elements of the MOLA language. The former specify the way in which instances are to be created, deleted or changed. The latter are executed for each loop variable (a special class element) instance satisfying the loop-head condition (the top most MOLA rule in the loop) In the EMF version of MOLA a foreach loop executes as long as possible (i.e. new instances that satisfy the loop Like the Fujaba solution (Section 6.4), a traceability association was added to facilitate the transformation development and execution. Migration of ActionStates. The transformation of an individual state is very straightforward, for example, the transformation of ActionState is shown in Fig. 10 right side. Note that along with the target element (OpaqueAction) its mapping to the corresponding source element (the link sourceelement/targetelement) is built. Overall Transformation. The MOLA solution of the task consists of 12 MOLA procedures. The transformation process has to be started from the top elements in the containment hierarchy, in the given case from ActivityGraph. All elements of a container, here CompositeState, are transformed using a MOLA foreach loop, running over these elements (see Fig. 10, left side). It is assumed here that an ActivityGraph contains just one CompositeState. Further, the procedure State is just a dispatcher which finds out what kind of state is really represented by the current StateVertex and invokes the corresponding transformation. When the nodes have been transformed, edges can be processed. Finding of end points of an edge to be created is based directly on mappings from the end points of the source edge. Finally, the partitions are created and transformed nodes are attached to the corresponding partitions (again using the mappings). Notable Feature. MOLA has an Eclipse-based graphical development environment (MOLA tool), incorporating all the required development support. A transformation in MOLA is compiled via the low-level transformation language L3 [2] into an executable Java program which can be run against a runtime repository containing the source model. For this case study, Eclipse EMF is used as such a runtime repository, but some other repositories can be used as well e.g. JGraLab, on which the GReTL transformation language is based (see Section 6.8). To develop a solution of this case, the source and target metamodels were imported into the MOLA tool. The import facility automatically adapted the metamodels variable, are processed by the loop) with the restriction that each instance may be processed only once.

16 16 Louis M. Rose et al. Fig. 10 MOLA transformation example. to the metamodelling standard required by MOLA for example, all associations must be bidirectional. The MOLA execution environment has a built-in model importer and exporter. Therefore it was possible to execute the transformations on models produced using the original source metamodel and to produce models compliant to the target metamodel. Summary. The MOLA solution was constructed using foreach loops and rules to specify 12 procedures. The solution developers believe that the effort for implementing the MOLA solution was quite low, mainly due to the chosen straightforward development method (where each correspondence between the source and target metamodel elements was directly implemented by a MOLA procedure or rule), and due to the general readability of MOLA transformations. The required infrastructure for model management within the MOLA tool was sufficient for the case. Opponent Statements (Horn, Jubeh). The fact that MOLA transformations are defined visually using a procedural style first transforming the root element and then transforming down the containment hierarchy makes them easily understandable even by non-experts. The concrete syntax is close to the well-known UML activity diagrams. MOLA supports transformations on different technical spaces. One of them is the widely used de facto standard EMF, and another one is JGraLab. MOLA requires that the navigability of all associations is bidirectional. For some backends like JGraLab, this requirement is met naturally. But when transforming EMF models, it might be cumbersome that all associations are made navigable in both directions. The type dispatching in some procedures is quite verbose. Alternative rules are modelled in chains, and if a rule cannot be applied, the next rule connected with an ELSE flow is tested. A more concise syntax might use UML activity diagram decision nodes and attach the OCL istypeof() constraints as guards to the outgoing flows. Also, [21] may again be used as inspiration for an even more concise and flexible solution. 6.6 PETE PETE 15 (Prolog EMF Transformation Eclipse plugin) is a general-purpose transformation framework. It provides mechanisms for a pure (i.e. side-effect free) declarative, rule-based approach to model transformation, accessing EMF Ecore-based models. PETE is a textual and external language, and its transformations are executed out-of-place and termination is implicit. (Table 2). Based on the EMF Ecore model, an instance model is described by sets of elements (each described as an entity and its attribute values) and relations (each described as a pair of entities), syntactically represented as a Prolog term. Since these elements and relations are instances of classes and associations taken from an EMF Ecore model, the structure of the Prolog term representing an instance model is inferred from the structure of that model. In PETE, a transformation is described in terms of a predicate, relating the model before to the model after the transformation; e.g. in case of the migration as shown in Listing 5 by a predicate migrateuml(uml1, UML2). To build those transformations, predicates are provided to deconstruct a model into its parts as well as to construct a model from its parts. As the structure of the model is defined using only compound functor terms and set terms, only two forms of predicates are needed: union and (de)composition operations. The predicate union(left,right,all) is used to state that set All is the union of Left and Right. Similarly, a predicate like ModelElement(Element,Ident, Name) is used to state that an Element of class ModelElement has an identifier Ident and a name Name. Since these predicates are declarative, they can be used bidirectionally; e.g. ModelElement can be used to deconstruct a given element into its attributes as well as to construct an element from its given attributes. Migration of ActionStates. Basically, the above mentioned core predicates are sufficient to realise complex transformation; however, being restricted to this low schaetz/pete