Softw Syst Model DOI 10.1007/s10270-012-0245-0
THEME SECTION PAPER
Graph and model transformation tools for model migration Empirical results from the transformation tool contest Louis M. Rose · Markus Herrmannsdoerfer · Steffen Mazanek · Pieter Van Gorp · Sebastian Buchwald · Tassilo Horn · Elina Kalnina · Andreas Koch · Kevin Lano · Bernhard Schätz · Manuel Wimmer
Received: 2 April 2011 / Revised: 27 February 2012 / Accepted: 5 March 2012 © Springer-Verlag 2012
Abstract We describe the results of the Transformation Tool Contest 2010 workshop, in which nine graph and model transformation tools were 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 Communicated by Dr. Andy Schürr and Arend Rensink. L. M. Rose (B) University of York, York, UK e-mail:
[email protected] M. Herrmannsdoerfer · S. Mazanek Institut für Informatik, Technische Universität München, Munich, Germany e-mail:
[email protected] S. Mazanek e-mail:
[email protected] P. Van Gorp Eindhoven University of Technology, Eindhoven, The Netherlands e-mail:
[email protected] S. Buchwald Karlsruhe Institute of Technology (KIT), Karlsruhe, Germany e-mail:
[email protected] T. Horn Institute for Software Technology, University Koblenz-Landau, Landau, Germany e-mail:
[email protected]
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). Keywords Model transformation · Graph transformation · Co-evolution 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 metamodel-specific editors, E. Kalnina IMCS, University of Latvia, Riga, Latvia e-mail:
[email protected] A. Koch Software Engineering Research Group, Kassel University, Kassel, Germany e-mail:
[email protected] K. Lano Kings College London, London, UK e-mail:
[email protected] B. Schätz Fortiss GmbH, Munich, Germany e-mail:
[email protected] M. Wimmer Vienna University of Technology, Vienna, Austria e-mail:
[email protected]
123
L. M. Rose et al.
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 conformance1 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 general-purpose 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 has not yet been investigated. 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 Sect. 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 Sects. 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 ArgoUML2 project, who has stated that 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
http://argouml.tigris.org/.
123
“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 related 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. 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 modeldriven 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 versus 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 [49,78,83]: since model 3 http://is.tm.tue.nl/staff/pvgorp/events/TTC/ttc10forum.htm (registration required).
Graph and model transformation tools for model migration
migrations do not change the modelling language, they are different from so-called 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 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 does 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-to-relational 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
123
L. M. Rose et al.
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], VIATRA2 [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 have also been publications that propose techniques to improve contests that compare transformation tools. Van Gorp and Eshuis [79] compared two solutions for transforming process models: a solution implemented in Java and a solution implemented in GrGen.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 Sect. 6. Moreover, we apply the framework by separating language-related criteria from tool-related ones and 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. [76,77] investigate the automatic assessment of transformation quality by means of specialised metrics and associated tools. This is promising 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. 4
cf. http://planet-mde.org/ttc2010/index.php?option=com_content& id=101.
123
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 versus model transformation and derive a research agenda that aims to combine the strengths of all approaches. 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 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. Sect. 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 2.2. 4.1 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
Graph and model transformation tools for model migration Customer
Sales
Stockroom
Request Service
Placed Order
Take order
Entered Order
[not in stock] [in stock]
Restock receive stock
Pay
Collect order
Filled Order
Delivered Order
Fill 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
behaviour [58]. Figure 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.2 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. Figure 2 highlights the main changes to the activity diagrams part of the UML metamodel between versions 1.4 and 2.2 of the 5
In the metamodel, these concepts are still called nodes and edges.
UML specification. For clarity, Fig. 2 omits some metamodel elements that were 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 ActivityPartitions. 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 ForkNode. – 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].
123
L. M. Rose et al. ModelElement * contents name: String
StateMachine
ActivityGraph
* transitions Guard
0..1 guard
1 expression
partition * source 1 target 1
* outgoing * incoming
Transition
StateVertex
1 top
«enum» PseudostateKind
BooleanExpression
Pseudostate
initial = 0 join = 1 fork = 2 junction = 3
language: String body: String
FinalState
Partition
* subvertex
State
kind: PseudostateKind
ActionState
ObjectFlowState
CompositeState
isDynamic: Boolean
(a) ModelElement name: String
Activity
* edges OpaqueExpression language: String body: String
0..1 guard
ActivityEdge
* outgoing * incoming
nodes * source 1 target 1
groups *
ActivityNode
ActivityPartition
* nodes
* edges
ControlFlow
ObjectFlow
InitialNode
ActivityFinalNode
JoinNode
OpaqueAction
ForkNode
ObjectNode
DecisionNode
(b) Fig. 2 The evolution of activity diagrams between UML 1.4 and UML 2.2. a Metamodel for activity diagrams in UML 1.4, based on [57]. b Metamodel for activity diagrams in UML 2.2, based on [58]
123
Graph and model transformation tools for model migration 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 Sect. 4.3)
To facilitate the comparison of model migration solutions (Sect. 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.
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 forums6 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. Figure 3 shows an example application of this migration semantics. Structures such as the one shown in Fig. 3a are migrated to an equivalent structure shown in Fig. 3b. 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 ObjectFlow, as shown in Fig. 3c, 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 UML tools store diagrammatic information in a structured manner using XML or a modelling tool. For example, the Eclipse UML 2 tools7 store diagrams as GMF [22] diagram models. 6
http://planet-research20.org/ttc2010/index.php?option=com_comm unity&view=groups&task=viewgroup&groupid=4&Itemid=150 (registration required).
7
http://www.eclipse.org/modeling/mdt/?project=uml2tools.
123
L. M. Rose et al. Fig. 3 ObjectFlowState migration semantics. a ObjectFlowState structure in UML 1.4. b Equivalent ObjectNode structure in UML 2.2 (core task). c Equivalent ObjectFlow structure in UML 2.2 (extension 1)
s1 : State
src
t1 : Transition
dst
s2 : ObjectFlowState
src
t2 : Transition
src
t2 : ObjectFlow
dst
s3 : State
(a) s1 : ActivityNode src
t1 : ObjectFlow
dst
s2 : ObjectNode
dst s3 : ActivityNode
(b) s1 : ActivityNode src
s2 : ObjectFlow
dst s3 : ActivityNode
(c) 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 project8 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 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 8
http://argouml.tigris.org/.
9
http://www-users.cs.york.ac.uk/~louis/ttc/.
123
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 five 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 are 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 min. 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.
History model Migration language b
– UML-RSDS
a
IMPL
IMPL OO-place No No External TXT Declarative None Transform. Model
IMPL
1 GReTL
[43]
OO-place
OO-place No
No No
No External
Internal TXT
TXT Declarative
Imperative None
None Transform.
Transform. Graph
Model 1, 2 ATL/Java
[33]
1 PETE
[7]
CF
IMPL OO-place No Yes Internal TXT Declarative None Transform. Model
CF
–
[68]
OO-place No No External GR Imperative None Transform. Model
DESTR
MOLA
[40]
OO-place
in-place No
No No
Yes External
External GR
TXT Declarative
Imperative DBG
DBG Transform.
Transform. Graph
Graph [5]
Fujaba
[42]
1
1, 3
GrGen.NET
IMPL in-place
OO-place No
Yes Yes Exta /intb GRa /TXTb
Yes External TXT Declarative
Imperative DIFF
None Migration
Migration Model
Model [64]
[26]
1, 3
1 COPE
Exec. Dom.
Purpose Tool
Ext.
Ref. Solution Subject
Table 2 Overview of the study subjects
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 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 edge-typed graphs with inheritance between node types, as can be seen in Fig. 2a, 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
Cognit.
6 Study subjects and their solutions
Flock
Language
While steps 1 and 2 were conducted before the workshop took place, steps 3–5 were conducted at the workshop and steps 6–8 were conducted afterwards.
Paradigm
Syntax
Impl.
RT
Lib.
Modes
Term.
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-min 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.
IMPL
Graph and model transformation tools for model migration
123
L. M. Rose et al.
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 versus TXT in Table 2). Moreover, we distinguish first-class languages from embedded languages (external versus 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 (in-place versus out-of-place) as well as the termination mode. For in-place transformations, the target is the same model or graph, and 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 (DESTR 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.
123
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 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 will 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.
Graph and model transformation tools for model migration
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 2 3 4
retype Guard to OpaqueExpression migrate Guard { migrated.body.add(source.expression.body); }
Summary The solution presented in this section makes use of the conservative copy and model connectivity layer of Epsilon Flock. The former was 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 was 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 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 COPE10 [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. 10
http://cope.in.tum.de.
123
Operation Browser
target metamodel
difference model
source metamodel history model
Metamodel Editor
L. M. Rose et al.
Convergence View
Fig. 4 User interface of COPE
Listing 3 Migrating ActionStates with COPE 1
rename(minuml1.ActionState, "OpaqueAction")
Overall transformation Figure 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, along with further reusable coupled operations for deleting features, inlining a super class and making a class abstract, among others. With the exception of one 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
123
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 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.
Graph and model transformation tools for model migration Fig. 5 Structure of the GrGen.NET solution
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.NET11 [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 2
rule transform_ActionState { state:minuml1_ActionState;
3
modify { opaque:uml_OpaqueAction;
4 5 6
eval { opaque._name = state._name; }
7
}
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 which defines y to be a retyped version of the original node x, retyped to the new type t; for 11
http://www.grgen.net.
edges the syntax is -y:t->. More information can be found in the extensive GrGen.NET user manual [4]. Overall transformation Figure 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. 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 ObjectFlow. 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
123
L. M. Rose et al.
Fig. 6 Configured-automatic layout of the resulting GrGen.NET graph
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.
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
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) and edges (-y:t->), 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
123
The Fujaba Tool Suite12 [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 ActionStates to OpaqueActions is specified with the story 12
http://www.fujaba.de.
Graph and model transformation tools for model migration Fig. 7 Story diagram to migrate ActionState elements
Fig. 8 Story diagram for addNodeToPartition
diagram in Fig. 7. In the first pattern, the OpaqueAction is created and its attributes are set. The second pattern contains a collaboration statement (addNodeToPartition(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 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. 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
123
L. M. Rose et al.
Fig. 9 Object graph of two connected ActionStates after its migration
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. Figure 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 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 criterion (see Sect. 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
123
XMI import, it seems that a slight adaptation of the importer is still needed for other use cases. 6.5 MOLA MOLA13 [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).14 Like the Fujaba solution (Sect. 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 13 14
http://mola.mii.lu.lv/.
In the EMF version of MOLA a foreach loop executes “as long as possible” (i.e. new instances that satisfy the loop variable, are processed by the loop) with the restriction that each instance may be processed only once.
Graph and model transformation tools for model migration
Fig. 10 MOLA transformation example
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 Sect. 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 to the metamodelling standard required by MOLA—for example, all associations must be bidirectional. The MOLA execution environment has a builtin 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 as 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 PETE15 (Prolog EMF Transformation Eclipse plugin) is a general-purpose transformation framework. It provides mechanisms for a pure (i.e. side effect free) declarative, rulebased 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). 15
http://www4.in.tum.de/~schaetz/PETE.
123
L. M. Rose et al.
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,[3]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 abovementioned core predicates are sufficient to realise complex transformation; however, being restricted to this low-level language subset drastically impedes conciseness.16 As Prolog also provides high-order predicates, for improving understandablity, this paradigm can be applied to define a complex migration operation in terms of more elementary migration operations, using a composition predicate. For example, for the migration of ActionState by renaming, the renameClass migration operation can be used. Thus, its application via renameClass(ActionState,OpaqueAction) in line 4 in Listing 5 performs the required migration. As was noted at a discussion at the TTC workshop, the implementation of renameClass can be considered to be a part of a reusable library, as this is the case with COPE (Sect. 6.2).
pre-model UML1 to obtain the post-model UML2; e.g. the above-mentioned renameClass to rename a class, renameAssociation to rename an association, refineClass to refine a class depending on the value of an attribute: Listing 5 Modular composition of elementary migration operations. 1 2 3 4 5 6 7 8 9 10 11
12
13 14 15 16 17 18 19
Each of these elementary operations again is a transformation from a pre-model to a post-model, depending on parameters. Listing 6 shows the operation to rename a class named OldName to a class named NewName. Again, it makes use of high-order predicates—e.g. class, element, to access a class of a model or the elements of its class—based on the (de)composition operators mentioned above. Listing 6 Elementary rename operation 1 2
3 4 5 6 7
8 9 10 11
Overall transformation Listing 5 shows the complete specification of the migration predicate migrateUML, making use of the high-order predicate migrate(PreModel, Operations,PostModel). It takes a list of elementary migration operations to apply their concatenation to the 16
This limitation is reflected in the evaluation, as this low-level approach was used in the solution presented at the contest rather than the one outlined here.
123
migrateUML(UML1,UML2) :migrate(UML1,[ renameClass(FinalState,ActivityFinalNode), renameClass(ActionState,OpaqueAction), renameClass(ObjectFlowState,ObjectNode), renameClass(Transition,ControlFlow), refineClass(Pseudostate,kind,initial,InitialNode) , refineClass(Pseudostate,kind,fork,ForkNode), refineClass(Pseudostate,kind,join,JoinNode), refineClass(Pseudostate,kind,junction, DecisionNode), refineClassByRelation(ObjectNode,incoming, Transition,ObjectFlow), refineClassByRelation(ObjectNode,outgoing, Transition,ObjectFlow), foldClass(Guard,expression,BooleanExpression, OpaqueExpression), renameClass(Partition,ActivityPartition), renameAssociation(transitions,edge), renameAssociation(partition,group), renameAssociation(subvertex,nodes), renameClass(ActivityGraph,Activity)], UML2).
12 13 14 15
renameClass(PreModel,OldName,NewName,PostModel) :package(PreModel,PackName,Packs,PreClasses,Assocs) , class(PreClass,OldName,PreElements), union([PreClass],RestClasses,PreClasses), class(PostClass,NewName,PostElements), union([PostClass],RestClasses,PostClasses), package(PostModel,PackName,Packs,PostClasses, Assocs), renameElement(OldName,PreElements,PostElements, NewName). renameElement(OldName,[],[],NewName). renameElement(OldName,PreElements,PostElements, NewName) :union([PreElement],PreRest,PreElements), element(PreElement,OldName,Object,Arguments), renameElement(OldName,PreRest,PostRest,NewName), element(PostElement,NewName,Object,Arguments), union([PostElement],PostRest,PostElements).
Notable feature As Prolog is declarative in nature, operations can basically be used in a bidirectional fashion. This bidirectionality can also be exploited in composed predicates like
Graph and model transformation tools for model migration
the elementary migration operations.17 This can be exploited to obtain inverse transformations for elementary operations by simply swapping PreModel and PostModel in the body of these operations. The overall inverse transformation can then be obtained by substituting each operation in the migration operation with its inverse. Since PETE is provided as an Eclipse plugin, it can immediately be applied to models for which a EMF-based metamodel is provided. It comes with a user interface in form of a transformation wizard, to apply transformations to models. The wizard also supports the debugging of the transformation on the Prolog level. Furthermore, verification tool support can be used to demonstrate the correctness of the transformation [69]. Summary The solution demonstrates the general applicability of declarative languages to practical problems in modelling like model migration. As specific problems like migration profit from a dedicated set of operations, here a general-purpose formalisation in a core language as offered by PETE is not adequate. As languages like Prolog provide mechanisms for defining higher-order operations, however, it is straightforward to add a new language layer supporting such domain-specific problem. Opponent statements (Rose, Rahimi) The integration of PETE with Eclipse is a positive feature of the approach, as is the declarative nature of PETE specifications. Unlike the other solutions described in this paper, migration in PETE is potentially a bidirectional transformation, which might be useful when, for example, models must be “downgraded” for interoperability with other artefacts (such as a legacy transformation). Integration with a tool for demonstrating the correctness of the migration is a further novelty of the PETE solution. However, the use of low-level Prolog coding to define transformations hinders the comprehension of the specification and results in verbose definitions, where decomposition and composition steps in Prolog obscure the essential transformation elements. Prolog is also quite distant in syntax from UML and OCL notations, which are likely to be more familiar to metamodellers. While the first-order predicates are easy to understand, the higher-order predicates are not, because they manipulate structures that are not easily related to the metamodel. 6.7 ATL and Java As other solutions solely focus on the migration of the abstract syntax, i.e. structural information, we emphasise in 17
For effective bidirectional use, the order of the predicates in the body is essential—for easy of reading Listing 6 shows an ordering which is not suitable for bidirectional execution.
this solution the migration of the concrete syntax, i.e. the diagrammatic information. The solution is achieved by two de-coupled transformations: (1) using the Atlas Transformation Language (ATL)18 [39] for abstract syntax migration and (2) using Java for concrete syntax migration. The implementation has been done in a straightforward manner and should be seen as an incentive to tackle the concrete syntax migration challenge as well. We believe that this area is of particular importance, because modellers tend to have a mental map [51] of their models based on concrete syntax. Thus, it is desirable to preserve as much of this information as possible when migrating models to new language versions. As concrete syntax depends on abstract syntax, this solution provides an abstract syntax migration implemented as a model-to-model transformation in ATL, which is a declarative, textual, external and out-of-place transformation language with implicit termination (Table 2). The evolution of the activity diagram metamodel from UML 1.4 to UML 2.2 is split up intuitively into 11 manageable steps, such as “a Partition becomes ActivityPartition as subclass of ActivityGroup”. For each of these evolution steps, a migration solution for instance models has to be devised. Therefore, the corresponding ATL rules have been created, such as “for every Partition, create an ActivityPartition”. This provided a concise abstract syntax migration of 13 transformation rules, as for some of the evolution steps 2 migration rules were created. Migration of ActionStates For instance, Listing 7 shows the rule for mapping ActionStates to OpaqueActions and for setting the name feature of OpaqueActions. Executing the ATL transformation produces an activity diagram conforming to the UML 2.2 specification. Listing 7 Migrating UML 1.4 ActionStates with ATL 1
rule migrate_ActionState{
2
from as : UML1!ActionState
3 4
to oa : UML2!OpaqueAction( name
