Softw Syst ModelDOI 10.1007/s10270-012-0297-1

THEME SECTION PAPER

Adapting transformations to metamodel changes via externaltransformation composition

Kelly Garcés · Juan M. Vara · Frédéric Jouault ·Esperanza Marcos

Received: 15 March 2011 / Revised: 17 August 2012 / Accepted: 25 October 2012© Springer-Verlag Berlin Heidelberg 2013

Abstract Evolution is inherent to software systemsbecause of the rapid improvement of technologies and busi-ness logic. As a software development paradigm, modeldriven engineering (MDE) is also affected by this prob-lem. More concretely, being metamodels the cornerstone ofMDE, their evolution impacts the rest of software artefactsinvolved in a development process, i.e., models and trans-formations. The influence over models has been tackled andpartially solved in previous works. This paper focuses onthe impact over transformations. We propose an approach toadapt transformations by means of external transformationcomposition. That is, we chain impacted transformations toparticular adaptation transformations which deal with eitherrefactoring/destruction changes or construction changes. Ourapproach semi-automatically generates such transformationsby using the AtlanMod matching language, a DSL to definemodel matching strategies. To provide with a proof of con-cept for our proposal, we adapt transformations written interms of object-relational database metamodels when suchmetamodels evolve in time.

K. Garcés (B)AtlanMod, ASCOLA, INRIA-EMN, Nantes, Francee-mail: kelly.garces.pernett@gmail.com

J. M. Vara · E. MarcosKybele Research Group, Rey Juan Carlos University, Madrid, Spain

J. M. Varae-mail: juanmanuel.vara@urjc.es

E. Marcose-mail: esperanza.marcos@urjc.es

F. JouaultAtlanMod, INRIA-EMN, Nantes, Francee-mail: frederic.jouault@inria.fr

Keywords Model-driven engineering ·Metamodel evolution · Transformation adaptation

1 Introduction

The adaptation1 of software systems is a rapidly increasingneed due to influence of technological and business innova-tions, changes in legislation and continuing internationaliza-tion [1]. The model-driven engineering paradigm (MDE) [2]is not beyond that need. Any MDE process involves basicallymetamodels, models, and transformations. A metamodel iscomposed of concepts and relationships. A (terminal) modelcontains instances of the metamodel concepts. A transfor-mation can translate the instances conforming to a meta-model concept into instances conforming to another concept.Because every model conforms to a metamodel, changes ina metamodel might impact many other artefacts: models thatconform to it, transformations that take it as source and/or tar-get, syntax specifications (e.g., textual, or visual), etc. There-fore, the adaptation to metamodel evolution is a relativelybroad problem. The issue of adapting models to evolvingmetamodels (model co-evolution) has been already tackledin previous works [3–5]. Here, we extend our previous work[6] around model co-evolution in order to reduce the impactthat the evolution of metamodels has over the ecosystem ofrelated models and transformations. This way, Fig. 1 gives anoverview of the well-known problem of model adaptation toevolving metamodels and puts in context the problem tackledin this paper.

Given two metamodels, M MA and M M B , we have a cou-ple of models conforming to such metamodels, plus the cor-responding transformations to move in both directions (A2B

1 We use adaptation, co-adaptation, and co-evolution as interchange-able terms.

123

K. Garcés et al.

Fig. 1 Need for model transformation adaptation

and B2A). Next, a developer refactors M M B and/or M M A.Such modifications result in new metamodel versions, so-called M M B′ and M M A′ . The first problem is to bring MB

and/or MA in agreement with the new metamodel versions.In [6] we propose adaptation transformations (indicated as α

and β in Fig. 1) to perform this task. This paper focuses onthe second problem: to adapt the transformations A2B andB2A to their evolving metamodels.

An ad-hoc solution to the latter problem is to manu-ally update the transformations and obtain the new versionsshown in the lower part of Fig. 1 (e.g., A′2B, A2B ′, A′2B ′,etc.). To avoid this extra workload, we propose a set of trans-formation chains that emulate the behavior of the updatedtransformations. To that end, the chain combines the alreadyexisting transformations with new adaptation transforma-tions that are generated in a semi-automatic way. As we willshow later, the chain configuration depends on the evolu-tion scenario which varies in two main aspects: evolutionside and changes taxonomy. The first aspect describes theunilateral metamodel evolution (i.e., the evolution of eitherM M A or MMB) as well as the bilateral case (i.e., concur-rent evolution of M M A and MMB).2 Regarding the secondaspect, we focus on the types of changes changes sketchedin [7], namely refactoring (rename element, move property,extract class, inline class, pull property, push property, flattenhierarchy), construction (introduce class or property, gener-alize property, extract superclass) and destruction changes(eliminate class, eliminate property, restrict property). Theadaptation to refactoring changes can be automatically per-formed but sometimes user assistance is required to completethe process for construction/destruction changes [4].

While the evolution side aspect mainly impacts the trans-formation chain execution order, the changes taxonomy

2 Although metamodel evolution is rarely performed simultaneously toavoid conflicts, we want to spell out all the possible scenarios.

aspect influences the selection of the adaptation transfor-mations constituting the chain. In every scenario, at leastone of the transformations referred to as α and α (β and β)are needed for the chain. The duty of α and α is, respec-tively, to move models towards a new metamodel version, ormove models back to an initial metamodel version.3 Whenthe evolved metamodel (e.g., M M A′ ) contains destructionchanges, the transition from M M A to MMA′ implementedby α implies the deletion of some elements. When bringingmodels into agreement with the former metamodel version(in order to apply original transformations, e.g., A2B), itis necessary to fully restore those elements that have beendeleted by α. To this end, α has to interact with anothertransformation so-called λ (analogous for β and β).

For construction changes, another transformation, so-called γ , has to be included in the chain. The duty of γ ,in turn, is to propagate manually added elements to the adap-tation chain output. These added elements are introduced intothe co-evolved model by the user in response to constructionmetamodel changes. For example, if the scenario is the evo-lution of M M A by applying construction changes, γ has toadd in MB , the new model elements that were introduced inMA′ , i.e., from the input to the output of the transformationchain. Along this paper we refer to this element addition as“propagation”. To ensure a correct propagation, the γ trans-formation uses an additional model that collects the tracesbetween MA and MB .

Whereas α and β have been introduced in [6], the remain-ing adaptation transformations α, β, λ, γ , as well as twentyfour adaptation chains, are new contributions of this work.In practice, our approach adapts a given model transfor-mation to its evolving metamodels under the assumptionthat such a transformation is an exogenous and semantical

3 β and β are the transformations performing a similar functionality inthe scenarios where M M B evolves.

123

Adapting transformations to metamodel changes

transformation. According to the model transformation tax-onomy proposed by Mens [8], “exogenous and semantical”mean transformations between models expressed using dif-ferent languages that do not perform a change between tech-nical spaces but some semantics of the models involved.

To generate the adaptation transformations aforemen-tioned, this work uses the AtlanMod matching language(AML) [6]. In a nutshell, AML is a domain specific language(DSL) for defining customizable matching strategies. From amatching output, AML derives executable adaptation trans-formations by using higher-order transformations (HOT)[9].Besides, it is worth mentioning that chaining of transforma-tions is not a real issue using current technology [10,11],especially if the ATLAS transformation language [12] hasbeen used to code such transformations (it is the case in ourproof of concept). Since our approach applies external com-position, it remains applicable to transformations developedwith any transformation language.

Finally, in order to provide a proof of concept for theproposal, we show how it is used in a concrete scenario.In particular, we address the evolution of one metamodelfrom a family of DSLs for object-relational database (ORDB)modelling.

The rest of this paper is organized as follows: Sect. 2presents the scenario that serves to illustrate the approach.Section 3 describes the approach proposed to adapt modeltransformations to evolving metamodels. Section 4 showsthe results of experimenting the approach with the motivat-ing scenario. In addition, this section lists some limitationsobserved in the experimentation. Section 5 revisits relatedworks and Sect. 6 concludes by highlighting the main find-ings and raises a number of questions for future research.

2 Motivating scenario

M2DAT-DB (MIDAS MDA Tool for DataBases) is a frame-work for model-driven development of modern DB schemas[13]. It is a toolkit to work with a set of interrelated DSLs.Here, we focus on the DSL supporting ORDB modelling forthe SQL:2003 standard [14], the one for ORDB modellingin Oracle 10g [15] and the transformations to bridge them.Both of them are large enough to illustrate the scalability ofthe proposal. Since the tool is still a prototype, new versionsof its metamodels are delivered sporadically. All this given,Fig. 2 shows the concrete evolution scenario addressed inthis paper.

In this paper, some changes introduced in the SQL2003metamodel yield a new version, so-called SQL2003_evo.The new version invalidates existing transformations:SQL20032ORA (49 mapping rules; almost 1300 LOC) andORA2SQL2003 (48 mapping rules; more than 1400 LOC).Thus, instead of developing new SQL2003_evo2ORA and

ORA2SQL2003_evo transformations (i.e., produce alteredcopies of the former transformations), we emulate them bymeans of transformation chains. In particular, Sect. 4 willshow how it is done for the SQL2003_evo2ORA trans-formation. For the sake of space, we will not present herethe metamodels in detail. We refer the reader to [13] for adetailed explanation on them. Instead, next sections focus onthe modifications done over the SQL2003 metamodel (thatyield the SQL2003_evo metamodel) and their impact overconforming models and related transformations.

2.1 Metamodel evolution

This section presents the complex changes introduced in thenew version of the SQL2003metamodel. A complex changeintegrates a set of actions affecting multiple concepts [16].Here, such changes are related with the modelling of trig-gers, views and default values in SQL:2003. To illustratethese changes, Fig. 3 shows excerpts from the two consid-ered versions of the metamodel: SQL2003 (the former) isshown in the upper part while SQL2003_evo is shown inthe lower one.

In the SQL2003 metamodel, a Trigger is defined overany Table and serves to define a set of actions to carryout over a set of Structural Components—that arespecialized into Columns of a Table (not shown here) orAttributes of a StructuredType used to define aTypedTable. TypedTables are defined over Struc-turedTypes, that can be thought of as a Class while therows in the tables defined over such a type would be theobjects instantiating such a Class. Besides,Restrictionsare defined over specificTableswhile a Table can be usedby one or more Views.

The new version of the metamodel, shown in the lowerpart of Fig. 3, collects some suggestions from the studentsinteracting with the tool (we use it for teaching purposes inan advanced database course): since triggers serve to definecomplex constraints over a given table (for instance, to sup-port bidirectional referential integrity), they should be con-sidered as a type of Restriction. As a consequence,the containment relationship between Table and Trig-ger disappears since it is already collected in the relation-ship between a Table and its restrictions. As well, theDescriptor class is introduced in an attempt to reflectthe standard in a more fairly way: “ A trigger is describedby a trigger descriptor. A trigger descriptor includes …”[14, p. 126]. Besides, the level property included in theDescriptor class allows modelling the type of a trig-ger (row-levelor statement-level), overcoming anerror introduced in the previous version of the metamodel.Finally, the later version of the metamodel incorporates adefault property in the Attribute class to support themodelling of default values for table columns.

123

K. Garcés et al.

Fig. 2 Motivating scenario

Fig. 3 Excerpt from the SQL2003 and SQL2003_evo metamodels

123

Adapting transformations to metamodel changes

Furthermore, another set of modifications have been addedto show the application of our proposal to deal with destruc-tion changes. In particular, the ability to associate views andtables and to state whether a given user defined type can beextended to disappear in the new version of the metamodel.This way, both the View class and the Table-View associa-tion are deleted, as well as the is_final property of theStructuredType class.

All this given, according to [17] we can summarize themodifications introduced as follows:

1. Introduce superclass: a class gets another class as itssuper-class. In our scenario, the Trigger class getsRestriction as its superclass. Note that being a non-breaking change it does not break the conformance ofmodels to the former version of the metamodel [4].

2. Extract class: a set of properties is extracted from a classto a new introduced class. This requires a zero-to-onerelation between the new container class and the affectedclass. Then, the properties are moved along this relationinto the new class. In this case, the introduced Trig-gerDescriptor class gets some of the the propertiesof the Trigger class.

3. Introduce property: this is an instance of a constructionchange and serves to show the problems derived from thiskind of evolution. When a mandatory property is intro-duced into a metaclass, the model elements conformingto it become invalid. Therefore, co-adaptation needs tointroduce a value for the new property into each modelelement of the metaclass. In our scenario, the defaultproperty is added to the attribute metaclass.

4. Eliminate class: deleted metamodel elements deservespecial attention when adapting model transformations.We illustrate the problem by means of the View meta-class which is deleted from the SQL2003 metamodel,along with its association with the Table metaclass.

5. Eliminate property: the considerations made for theprevious modification apply also here. In particular, theis_finalproperty is deleted from theStructured-Type metaclass in the new version of the metamodel.

According to the catalog of changes sketched in [16],first/second changes are refactoring changes while the thirdone is a construction change and the fourth/fifth ones aredestruction changes.

2.2 Impact of metamodel evolution over models

To illustrate how the changes described in the previoussection impact corresponding models, we use the onlinemovie database (OMDB) case study, taken from [18, p. 5].The OMDB case study addresses the development of an

ORDB devoted to manage information about movies, actors,directors, play writers, and movies. Using M2DAT-DB, theOMDB conceptual data model is translated into an ORDBschema conforming to the SQL:2003 standard and into anORDB Schema for Oracle. For the sake of space, we do notinclude the complete ORDB models here but they can befound in [13].

Figure 4a shows two excerpts of the OMDB.sql2003model. In particular, the upper part of the figure shows themovie_type Typed Table and two outgoing arrows thatpoint to the Eclipse4 properties views for DeleteRelat-edProducts Trigger and WARNER_MOVIES View. In theexcerpt of the corresponding XMI file note that: (a) thetrigger object is not included in the collection of restric-tions of the table; the properties view shows that (b) trig-geredAction and event are properties of the triggerobject itself and (c) theWARNER_MOVIESview is associatedwith the movie_type table. Moreover, the lower part ofthe figure shows the properties view for the Person_typeStructured Type and the country attribute. Note that: (d)the country attribute has no default property; (e) thePerson_type structured type owns an is_final prop-erty.

On the other hand, Fig. 4b shows the result of adaptingthe previous model to the new version of the metamodelby using α. The major updates are: (a) As shown by theXMI excerpt, the Trigger object is included in the setof restrictions of the table. As a consequence, the formertriggers relation between Table and Trigger gets subsumedunder the restrictions relation between Table and Restric-tion. In addition, the properties view (at the upper part ofthe figure) shows that Trigger object owns a newly addedTriggerDescriptor object; (b) the triggeredAc-tion and event properties have been moved to the newTriggerDescriptor object; (c) there is no view asso-ciated with the movie_type table. Finally, the propertiesview at the lower part of the figure shows that (d) the coun-try attribute of the Person_type structured type ownsa default property with the value “USA” introduced bythe user and (e) the country attribute has no is_finalproperty.

Note that later on, when showing the application of ourproposal in Sect. 4, we will focus just on some of these mod-ifications.

Besides, the reader might find that there are some elementsin the models shown in Fig.4a and b for which there is noconforming meta-classes in Fig. 3. The reason behind it is thatFig. 3 shows just excerpts of the two versions of the SQL2003metamodel used in this work for the sake of clarity.

4 www.eclipse.org/.

123

K. Garcés et al.

Fig. 4 SQL:2003 models

123

Adapting transformations to metamodel changes

2.3 Impact of metamodel evolution over transformations

The modifications performed over the SQL2003metamodel (that yield the SQL2003_evo metamodel)invalidate the SQL20032ORA transformation which wasdeveloped to translate SQL2003 models into ORDB4ORAmodels. For instance, List 1 gives an ATL rule that mapstrigger objects from a SQL2003 model to the Ora-cle ones. Line 12 shows that the body property (of OracleTrigger objects) is initialized with the triggeredActionproperty (of SQL2003 trigger objects). Nevertheless, thetriggeredAction attribute, as well as actionTimeand event, have been extracted from the Trigger classto the TriggerDescription class as SQL2003 evolves(see Fig. 3). Hence, the rule Trigger2Trigger becomesinvalid and SQL20032ORA raises an exception at executiontime.

Furthermore, the ATL rule that transforms attributeobjects does not contain mappings for the default prop-erty because it has been introduced in the SQL2003_evometamodel. Because of this, the default value “USA” is notpropagated to OMDB.ordb4ora as it is required when thetransformation is executed. Besides, the mapping of the infor-mation related with the modeling of views would be impos-sible to address since SQL2003_evo metamodel does notconsider them. Finally, the destruction changes will not raiseany exception when running SQL20032ORA: in the absenceof some elements, some rules are just not matched. How-ever, destruction changes make OMDB.ordb4ora becomean invalid model since mandatory information is missing.That is, because the values for the is_final property havebeen removed from the SQL2003_evo model, the trans-formation assigns null to the corresponding Oracle property.In this example, destruction and construction changes do not

make the transformation fail, nevertheless, its output modellacks information and is invalid.

Our challenge then, is to adapt SQL20032ORA to refac-toring, destruction and construction changes and to generatea correct OMDB.ordb4ora model. Next section presentsour proposal to deal with this challenge.

3 Adapting model transformations via externaltransformation composition

We automate the adaptation of transformations to metamodelchanges by means of external transformation composition[19]. That is, instead of writing new transformations as meta-models evolve, we emulate their behavior by executing atransformation chain (referred to as adaptation chain). Sothat, every transformation in the chain consumes the outputof the previous one, emulating the mathematical notion offunction composition. The chain configuration depends onthe metamodel evolution scenario which can be character-ized by the next two features:

– Evolving metamodel. Metamodel evolution can be uni-lateral or bilateral. Unilateral means that the evolutionconcerns only one of the metamodels in terms of whicha transformation is written, either M M A or M M B meta-model, while bilateral describes a simultaneous evolutionof M M A and M M B metamodels. As we have alreadyargued, metamodel evolution is not frequently performedin a simultaneous way. Nevertheless, bilateral scenarioscan be tackled as two subsequent unilateral scenarios.

– Types of metamodel changes. It refers to the kinds ofchanges introduced by evolving metamodels.

According to the possible values for these two features,Table 1 shows 24 metamodel evolution scenarios for whichwe propose adaptation chains. For each scenario, the tableindicates:

– The evolving metamodels (M M A and/or M M B).– The types of changes introduced by the evolution.– The new transformations that should be developed to sup-

port the metamodel evolution.– The chains proposed to emulate the behavior of such

transformations and thus avoiding the workload of man-ual updates. An equation number is associated with everychain. Note that an equation can be written in terms of(or be equal to) another, for example, Eq. 17 needs Eq.13 and Eq. 8 is equal to Eq. 2.

Every chain is composed by one of the existing transfor-mations (A2B or B2A), plus one or more of the new trans-formations, namely α, γ , λ, etc. The latter transformations

123

K. Garcés et al.

Table 1 Adaptation chains for metamodel evolution scenarios

Evolving metamodel Type of metamodel changes Evolving transformations Eq. Adaptation chain

M M A MMB Ref. Con. Des.

� � A′2B(MA′ ) (1) A2B(α(MA′ ))

B2A′(MB) (2) α(B2A(MB))

� � A2B ′(MA) (3) β(A2B(MA))

B ′2A(MB′ ) (4) B2A(β(MB′ ))

� � � A′2B ′(MA′ ) (5) β((1))

B ′2A′(MB′ ) (6) α((2))

� � � A′2B(MA′ ) (7) γ (A2Btrace(α(MA′ )), MA′ )

B2A′(MB) (8) (2)

� � � A2B ′(MA) (9) (3)

B ′2A(MB′ ) (10) γ (B2Atrace(β(MB′ )), MB′ )

� � � � A′2B ′(MA′ ) (11) β((7))

B ′2A′(MB′ ) (12) α((10))

� � � A′2B(MA′ ) (13) A2B(λ(α(MA′ ), MA′(Deletions)))

B2A′(MB) (14) (2)

� � � A2B ′(MA) (15) (3)

B ′2A(MB′ ) (16) B2A(λ(β(MB′ ), MB′(Deletions)))

� � � � A′2B ′(MA′ ) (17) β((13))

B ′2A′(MB′ ) (18) α((16))

� � � � A′2B(MA′ ) (19) γ (A2Btrace(λ(α(MA′ ), MA′(Deletions))), MA′ )

B2A′(MB) (20) (2)

� � � � A2B ′(MA) (21) (3)

B ′2A(MB′ ) (22) γ (B2Atrace(λ(β(MB′ ), MB′(Deletions))), MB′ )

� � � � � A′2B ′(MA′ ) (23) β((19))

B ′2A′(MB′ ) (24) α((22))

Table 2 Adaptationtransformations Moniker Source models Target models

α MA MA′ and MA′(Deletions)

β MB MB′ and MB′(Deletions)

α M ′A MA(I ntermediate)

β M ′B MB(I ntermediate)

λ MA(I ntermediate) and MA′(Deletions) MA

MB(I ntermediate) and MB′(Deletions) MB

γ MA′ , MB and traceMA MB MA(Additions)

MB′ , MA and traceMB MA MB(Additions)

enable the adaptation to refactoring, destruction, or construc-tion changes and we refer to them as adaptation transforma-tions. For the sake of clarity, Table 2 summarizes the sourceand target models of each transformation. The functionalityprovided by each transformation, as well as the purpose oftheir source and target models are given in Sect. 3.2 and 3.3.

Being based on transformation chains, execution orderis key to our proposal. The nature of two transformations

restricts their execution order: the order of t1 and t2 can notbe inverted if such transformations are not compliant, i.e.,the output metamodel of the first one is included into theinput metamodel of the second one [20]. This is similar to asequential function composition f(g(x)), where f is appliedto the result of g(x). For example, to emulate A′2B(MA′), weexecute α(MA′) first and after that we execute A2B. In thissense, our proposal starts from the premise that existing trans-

123

Adapting transformations to metamodel changes

formations (A2B and B2A) are valid. Thus, the correctnessanalysis is restricted to the generated adaptation transforma-tions.

3.1 Fundamentals of generating adaptation transformations

As we have already mentioned, every chain is composed ofan existing transformation plus one or more adaptation trans-formations. The latter are generated automatically followinga common process that differs slightly from one type of trans-formation to the other. Before introducing such a process, thissection introduces some basic concepts for our proposal:

– A model transformation can be abstracted as a (transfor-mation) model conforming to a metamodel [21]. Then,a higher-order transformation (HOT) is a transformationsuch that the input and/or the output models are transfor-mation models [22].

– A mapping model establishes correspondences betweenelements of two (meta)models. Mapping models can bemanipulated by means of model transformations andGraphical User Interfaces. A HOT can produce a trans-formation from the correspondences between metamodelelements collected in a mapping model [23].

– Manually finding mappings is labor-intensive and error-prone as (meta)models are large. A solution is to executematching strategies. A matching strategy executes a setof heuristics and delivers a mapping model [17]. Everyheuristic has a specific functionality: create correspon-dences, find similarity between (meta)model elements,prune correspondences or semantically enrich them.

Next, let us describe in a nutshell the process to generatethe adaptation transformations (namely α, β, α, β, λ andγ ). Later on, we will show that the auxiliary transformationsshown in Table 1, A2Btrace and B2Atrace, are produced in asingle step by applying a particular HOT.

– First, a matching strategy computes the equivalences anddifferences between a pair of metamodels and persiststhe results in a mapping model.

– Next, users might refine the generated mapping modelif it is not as expected (i.e., it contains false positives orfalse negatives).

– Finally, a HOT generates the adaptation transformationfrom the (refined) mapping model.

To support the proposal we have developed a prototype thatuses the matching strategies available in the AML tool.5

AML facilitates the development (and customization) of

5 http://wiki.eclipse.org/AML.

matching strategies. The generated adaptation transforma-tions are themselves written in the ATL language, as wellas the HOTs. Besides, we have also used the ATL facili-ties to build the chains that include the generated adaptationtransformations. With regard to the mapping models, theyare extensions of weaving models. The nature of weavingmodels results ideal for representing relationships betweenmodel elements [24]. In particular, we use the ATLAS ModelWeaver (AMW) tool for the management of weaving mod-els [23]. This way, the developer can use AMW to refineany input/intermediate/output mapping model manipulatedalong the matching step. The next sections give more detailsabout the generation process which can slightly vary with thekind of adaptation transformation.

3.2 Adaptation transformations for refactoringand destruction changes

We name α and β the adaptation transformations that migratemodels as its evolving metamodel contains refactoring anddestruction changes. While α adapts any model conformingto M M A to MMA′ , β adapts models conforming to M M B toMMB′ . In [6], where α and β were introduced first as a wayof adapting models to evolving metamodels, we explainedthe different operators for refactoring changes. In addition,we stated that destruction changes do not require any specialoperator. The adaptation transformations simply avoid anyrule referring to the deleted meta-element, thus, the modelelements conforming to such a meta-element are not migratedto the new model as expected according to the scope of [6].

Because this work focuses on the adaptation of transfor-mations to their evolving metamodels, we pay significantlymore attention to metamodel deletions. Let us explain howmetamodel deletions impact the correctness of adaptationchains as follows: Assume an obligatory attribute is deletedfrom M M A, then α deletes the corresponding values in MA′ .After applying α (which is described in detail below), themodel will not conform to the original M M A as it is manda-tory for the deleted attribute values to be present. In addition,the adaptation chain would be unable to map the missingvalues to MB values when going from MA′ to MB .

To cope with deletions, we extend the behavior of α

(analogue for β) in such a way that it creates MA′ (whichadapts MA to refactoring changes) but also MA′(Deletions)

which keeps a trace of elements deleted from MA in responseto destruction changes. When deleted meta-elements areclasses, MA′(Deletions) contains full copies of instances con-forming to deleted classes. In contrast, if deletions concernattributes or references, MA′(Deletions) contains the copiesof attribute/reference values in stub instances, i.e., instancesof meta-classes that store only the values corresponding todeleted properties.

123

K. Garcés et al.

Table 3 Refactoring changesChange supported by α Change supported by α

Pull property Push property

Drop hierarchy Flatten hierarchy

Rename element Rename element

Move property to owner Move property to owned

Extract class Inline class

Moreover, this paper introduces α and β as the backwardtransformations of α andβ. They make it possible to apply theoriginal transformations A2B and B2A. Let us use equationsto indicate their exact meaning:

1. α(x ′) = x where x ′ is the output of α(x) for scenariosincluding refactoring changes.

2. λ(α(x ′), x ′(Deletions)) = x where x ′ and x ′(Deletions) arethe outputs of α(x) for scenarios including, both, refac-toring and destruction changes.

The first item indicates that α brings x ′ in agreement withthe former metamodel version. To do so, α follows Table 3.If α supports a change in the left column, then α upholds thecorresponding change in the right column, and vice versa. Forexample, whereas α supports an Extract Class opera-tor, α implements an Inline Class operator.

The second item indicates that we need the interactionof α with λ to succeed in recovering deleted elements.Let us illustrate such an interaction by means of the sce-nario that describes refactoring and destruction changesin M M A. In this case, as shown in Eq. 13 of Table 1,the corresponding adaptation chain takes as input MA′ andMA′(Deletions). MA′ is the result of applying refactoring oper-ators to MA and MA′(Deletions) contains elements conform-ing to meta-elements that have been deleted from M M A. λ,in turn, merges MA′(Deletions) and the output of α so-calledMA(I ntermediate). This composition ensures us an MA versionthat conforms to M M A and contains the values expected byA2B.

To generate α and β (and their backward transformations),we apply the generic matching strategy proposed in [6]. Thisstrategy reports quite good results when the pair is constitutedby versions of the same metamodel. In particular, the exper-imentations have shown accuracy percentages ranging from90 to 100 %. The difference between the generation of anadaptation transformation and its backward is the matchingdirection. Thus, α needs a matching from M M A to MMA’,whereas α needs a matching from M M A′ to M M A. More-over, we have extended the HOT proposed in [6] in such away that α and β will create models tracing the deletions.

The generation of λ, in turn, requires a new HOT which isgenerated from the same mapping model used for α and β.

3.3 Adaptation transformations for construction changes

As we have already mentioned a number of times, con-struction changes need special attention. In particular, userassistance is needed for the manual addition of elementswhen metamodel evolution involves construction changes.The adaptation chain (by means of A2Btrace, B2Atrace, andγ ) ensures that such model elements will be at the output ofan adaptation chain if necessary. Note that by “necessary” werefer to those scenarios where the propagation of model ele-ments along the adaptation chain is required. That is, thosewhere the introduced elements conform to a source meta-concept that, although has no correspondence in the formerversion of the source metamodel, do has a correspondencein the target metamodel. For instance, M M A′ might incor-porate an X metaclass with no correspondence in M M A butcorresponding to a Y metaclass in M M B . Then, the adapta-tion chain has to be able to map the X objects in MA′ to Yobjects in MB when moving from MA′ to MB .

This behavior is supported by A2Btrace, B2Atrace, andγ . A2Btrace and B2Atrace are copies of A2B and B2Aplus traceability code. This code creates traceability linksbetween the IDs of source and target model elements. On theother hand, the γ transformation enriches the output of A2Bor B2A with target elements corresponding to the elementsintroduced by hand. To do this, γ relies on the traceabilitylinks produced by A2Btrace or B2Atrace.

Regarding the generation of these transformations,A2Btrace and B2Atrace are produced by a HOT contributedby Jouault in [25]. This HOT copies transformation rulesfrom A2B (or B2A) to A2Btrace (or B2Atrace) and addstraceability patterns to each rule. This way, for each execu-tion of the rule, apart from the corresponding target elements,trace links are also generated. The HOT of γ , in turn, cre-ates a rule for each meta-concept undergoing constructionchanges. The rule instruments the mapping between such ameta-concept and its corresponding target meta-concept. Themapping is indicated by the output of the matching strategyand has likely been refined by the user.

123

Adapting transformations to metamodel changes

3.4 Differences between adaptation transformations

Below, five aspects delimit the differences of generation ofadaptation transformations:

1. Whereas the matching strategy needed for λ, α, β (andtheir backward transformations), takes as input a pairformed by the initial and last version (or vice versa) of thesame metamodel (e.g M M A and M M A′ ), the matchingtransformation for γ uses a pair constituted by versions ofM M A and MMB . That is, for the scenarios where meta-model evolution is unilateral, the matching algorithm forγ uses a pair constituted by the evolved version of onemetamodel (e.g. M M A′ ) and the original version of theother (e.g. M M B). For the scenario where evolution isbilateral, the matching algorithm forγ takes a pair formedby the two evolving metamodels.6

2. Unlike the transformations λ, α, β (and their backwardtransformations), which are yielded by means of the samematching strategy, γ can need other matching strategywhose configuration depends on the evolution scenario.The developer might use AML to define an appropri-ate matching strategy or to tune an existing one. Forthe sake of performance and accuracy, this strategy hasto focus on the discovery of correspondences involvingthe meta-concepts added in the new metamodel versions(e.g., thedefault property of M M B corresponds to thedefault property of M M A′ ). Given the page limit, weare unable to include here guidelines on matching strate-gies tuning. Instead we refer the reader to chapter 5 of[17] which proposes a set of possible matching strategiesand details the results of applying such strategies to 68pairs of metamodels and 3 pairs of ontologies.

3. The selected matching strategy gives a mapping modelfrom which γ is generated following the generic processsketched in Sect. 3.1. Such a mapping model may requiremore user refinement than the mapping model for λ, α,β, etc. In other words, the selected matching strategy forγ may be less accurate than the strategy for the otheradaptation transformations. Nevertheless, the fact thatmapping models are expressed as weaving models allowsusing AMW to refine the automatically generated map-ping model.

4. Because our work encourages automation as much aspossible, we evoke that γ can be generated from theoutput mapping of a matching strategy. However, if thenew metamodel version contains a few newly created ele-ments (or if users want to deal with new elements in aspecific way), then it would be easier to manually definethe mappings between such new elements and their cor-

6 The possible pairs are: (M M A, M M B′ ), (M M A′ , M M B ), (M M A′ ,M M B′ ), (M M B′ ,M M A), (M M B , M M A′ ), or (M M B′ , M M A′ ).

responding target elements. These mappings are definedby the user in the matching model from which γ is gen-erated. Thus, users do not need to touch original modeltransformations, they are kept as they are since their evo-lution (in response to metamodel changes) is emulatedby our adaptation chains.

5. Regarding the previous point, the use of a matching strat-egy for γ becomes significant as the number of newlyadded meta-elements is higher than 50 and the meta-models to navigate are very large. In this case, the use ofmatching strategies appears as a good solution to providecandidate mappings which can be subsequently refinedby hand.

6. Finally, the HOT for α, β (and their backward transfor-mations) differs from the γ HOT in that the former gen-erates operators for refactoring changes while the lat-ter generates operators for construction changes. The λ

transformation, in turn, produces operators dealing withdestruction changes.

4 Showing adaptation chains in action

This section shows how to apply the approach to the moti-vating scenario. In particular, we present the execution ofthe adaptation chain specified in Eq. 19 of Table 1 in a step-wise manner. It applies to the motivating scenario where theevolution is unilateral modifying the source metamodel (i.e.,SQL2003) with refactorings, deletions and constructions.This proof of concept enables us to show the functionalityof the transformations described in Sect. 3.2 and 3.3. To thatend, Fig. 5 gives excerpts of the models manipulated by thechain when applied to our motivating example.

Each model is delimited by a dashed-line square and itsname is displayed on the left, top side of the square. Wefocus on the model elements undergoing co-evolution. Toease their tracking, every model element is identified by itsID and corresponding meta-concept. The bold lines indicatethe input/output models of every transformation constitutingthe chain. MA′ and MA′(Deletions) (localized at the left, topside of the figure) are the result of an automatic adaptation torefactoring/destruction changes and a manual modification todeal with construction changes. Remark on MA′ the deletionof elements conforming to View as well as the lack of val-ues for the attribute is_instantiable. To track thesedeletions, λ has brought these elements to MA′(Deletions).The chain goal is to obtain MB(Additions) (bottom side ofthe figure) from MA′ and MA′(Deletions). In the followingwe describe how the adaptation transformations contributeto this goal.

– First, the α transformation brings MA′ into agree-ment with M M A. It implements an Inline Class oper-

123

K. Garcés et al.

Fig. 5 Execution of an adaptation chain

ator that drops triggeredAction and event val-ues back to Trigger instances. That is, the data ins3:Descriptor is moved to s2:Trigger. In addi-tion, the Delete Superclass operator deletes Restric-tion from the list of superclasses of the Triggerinstances. Finally, α deletes the model elements of MA′marked with the red X, that is, the model element con-forming to Descriptor as well as the defaultproperty value “USA”. Remark on the output modelMA(I ntermediate) the lack of information manually addedinto MA′ in response to construction changes, i.e., thevalue for the default property.

– In a second step, the λ transformation mergesMA′(Deletions) and MA(I ntermediate). The goal is to enrichMA(I ntermediate) with certain elements of MA′(Deletions)

and establishing the relationships between deleted ele-ments and elements already existing in MA(I ntermediate).The elements to be copied are those missing inMA(I ntermediate). For example, the elements conforming

to View and the values of the attributeis_instantiable. Notice that the stub instances ofMA′(Deletions) are not copied into MA, they are onlyused to know how to attach deleted values to elementsof MA(I ntermediate). As an illustration, the true valueof the stub instance identified with ID s4 is associatedwith the attribute is_instantiable of the instances4 of MA(I ntermediate). In addition, WARNER_MOVIESbecomes a view of tablemovie_type. Thus, λ makes itpossible to obtain an MA model conforming to the orig-inal M M A and containing all the elements expected byA2Btrace.

– From the result of λ, the A2Btrace transformation yieldstwo output models: MB and traceMA MB . The MB modelis the expected target of A2B while the traceMA MB

model contains a set of traceability links. Each trace-ability link identifies the source element from which atarget element was generated by executing a rule of A2B.Thus, by looking at a given link one can derive which MA

123

Adapting transformations to metamodel changes

element has been used to create a given MB element. Forinstance, the trace link s1 ←→ o1 implies that the ele-ment o1 has been created from s1.

– Finally, γ propagates the newly added information fromMA′ to MB(Additions). For instance, in the motivating sce-nario γ propagates the values for the default property.Notice that this illustrates what we meant by necessarypropagation in Sect. 3: the default property of M M A′corresponds to thedefault property of M M B but thereis no corresponding element in the M M A metamodel.Therefore, we have provided with a way of propagatingthe newly added elements conforming to such a meta-concept from MA′ to MB(Additions).

Next, we explain how the transformations λ and γ

work. The λ transformation mainly focuses on the cre-ation of elements missing in MA(I ntermediate) from ele-ments being in MA′(Deletions). Elements already existingin MA(I ntermediate) are implicitly copied into MA. List2 illustrates the rule that retrieves views elements fromMA′(Deletions) and copies them into MA. The getLamb-daElement operation makes it possible to associate viewswith table elements. To do so, getLambdaElement seeksfor elements in MA(I ntermediate) whose IDs correspond tothe IDs indicated by the stub TypedTable instances ofMA′(Deletions). List 2 depicts a rule that retrieves elementsconforming to the deleted View meta-class. Besides thiskind of rule, dealing with meta-class elimination, we haveidentified two other kinds of rules for property eliminationand property restriction. The rules differ from each other on:1) the model used in the input pattern, either MX (I ntermediate)

or MX ′(Deletions), and 2) the style of binding used in the out-put pattern. The commonality among them is the invocationof getLambdaElement.

The γ transformation, in turn, focuses on enriching MB

with elements from MA′ . The MB elements that need nomodifications are implicitly copied into MB(Additions). List3 depicts one of the γ rules. For each element of MB con-forming to Attribute, the rule initializes its default

property using information from MA′ . To ensure a correctinitialization, every γ rule uses two operations: elemen-tIdCorrespondingTo and getGammaElement.

– elementIdCorrespondingTo returns the MA

model element that corresponds to a given MB element.To that end, it selects the link l from traceMA MB whosetarget corresponds to the element of interest. Next, itreturns the ID of the source element referenced by l.

– getGammaElement looks for an element in MA′whose ID corresponds to the ID returned by elemen-tIdCorrespondingTo. That is, we move from MB

back to MA′ in two steps. First, we use elementId-CorrespondingTo to move from MB to MA and thenwe use getGammaElement to go from there to MA′ .

For example, given the “country” Attribute of MB ,whose ID is o5, elementIdCorrespondingTo findsout the link l4 and returns the ID of its source element, i.e.,s5. The operation getGammaElement, in turn, recoversa “country” Attribute from MA′ , whose ID is s5. Therecovered element is used to initialize thedefault propertyof the MB(Additions) “country” element. Thus, γ successfullypropagates the default property value “USA” from MA′ toMB(Additions) as indicated by the green check mark in thefigure. The remaining properties of the “country” element,as well as the other MB model elements, are implicitly copiedby γ .

4.1 Limitations

Our experimentations have reported the following limita-tions:

– AML can generate complete α, β, α, β and λ onlyfor scenarios that contain changes according to the tax-onomy proposed in [7]. Therefore, only 10 % of thetaxonomy of changes reported in Herrmannsdoerfer etal. [16] (i.e., replace enum, collect/combine/propagate

123

K. Garcés et al.

feature, make reference containment) is not automati-cally supported by our approach at present. For evolu-tion scenarios including these kinds of changes, AMLprovides an initial adaptation transformation that has tobe completed by hand. However, we are working towardswidening the types of changes supported automatically,according to Herrmannsdoerfer’s catalog.

– AML can yield γ if the propagation of constructionchanges requires simple assignations between attributes.When complex assignments are needed (e.g., thoseincluding complex OCL expressions), the user hasto manually complete the matching strategy outputwith mappings representing these expressions. Then, anextended HOT traduces the mappings into executabletransformation code.

– The propagation of construction changes relies on thecorrespondence between model element IDs. This mech-anism becomes obsolete when the manual addition ofmodel elements changes the IDs (in particular whenmodel elements are arbitrary added into collections). Asolution to this problem is to use matching strategies atmodel level. Based on heuristics, these strategies wouldfind the correspondences between the model produced byA2Btrace (or B2Atrace) and the model modified by hand.Since a customized matching strategy would be neededfor each metamodel version with construction changes,we work on automating the generation of this kind ofstrategy.

– At present, in our proposal it is the designer who hasto choose the most suitable adaptation chain for a givenscenario of evolution. To do so, she/he needs to know thetypes of changes brought by the metamodel evolution. Anoption to improve the level of automation of this part ofthe process is to obtain a difference model by using AMLfirst, and then to execute a transformation that selects thechain according to the changes reported by the differencemodel.

– Although the presented approach considers just one evo-lution step, it could be generalized to (n) evolutionsteps just by chaining the (n) adaptation transforma-tion chains produced for each step. As spelled out in[26], the optimization of this kind of compositions is acomplex challenge: Adaptation chain branching impactsthe approach performance since it is necessary to keepall intermediate versions of evolved metamodels and toexecute long transformation chains. Moreover, transfor-mation chain debugging becomes complex. To overcomethese issues, we propose to keep a reasonable value for(n) by discarding former versions of a given metamodelas new versions are produced.

– According to Mens [8], the proposal presented hereapplies to exogenous and semantical transformations.Indeed, we believe that supporting (semi-)automatic

adaptation of model transformations to metamodelevolution is only feasible for this type of transformations.As future research, we plan to apply the same proposalto a wider set of the types of transformations identifiedin the above-cited article to check this statement.

– To ensure that elements removed by α and β are success-fully recovered by λ, our chains target the adaptation oftransformations that include only one-to-one rules (i.e.,input and output patterns involve only one meta-class andits corresponding meta-properties). We are aware that, inpractice, transformations may include many-to-one, one-to-many, many-to-many rules. To support these cases fur-ther investigation is needed.

– Besides, the gist of this work was to explore the feasibil-ity of our proposal for a certain type of transformations.Therefore, we opted for a set of self-developed DSLsand model transformations, whose nature does not bringadditional complexity to the validation process. A futuredirection of our work is its application to more complextransformations that can lead us to refine and improve thecurrent implementation. For instance, we would like toapply the approach to DSLs with a bigger semantic gap,e.g., DSLs owning an operational semantics.

5 Related works

We have classified existing works in the area into three maingroups according to their main focus: (1) adaptation of trans-formations to metamodel changes, (2) adaptation of mod-els to evolving metamodels and model differencing and (3)model change propagation via bidirectional transformations.Note that the first group collects those works that are directlyrelated with our proposal while the others collect correlatedworks. The following sections give an overview of the worksfalling in each group.

5.1 Adaptation of transformations to metamodel changes

To the best of our knowledge, the only works addressing asimilar issue to ours are the one from Levendovszky et al.[27], the one from Garcia and Diaz [28] and the one fromMeyers et al. [26].

Regarding the former, whereas we use chains that emu-late the functionality of evolved transformations, the workfrom Levendovszky et al. generates such transformationsfrom metamodel changes which are explicitly specified bythe user, i.e. once the metamodel evolution has been specified,the transformation evolution uses this. Our approach, in turn,discovers metamodel changes semi-automatically. Besides,when comparing the catalogs of changes, one finds that theproposal of Levendovszky et al. cannot treat constructionchanges without user intervention. In contrast, we contribute

123

Adapting transformations to metamodel changes

γ , whose duty is to propagate added elements straightfor-wardly. Under the light of these two points, we can concludethat our proposal offers a higher level of automation.

The proposal of Garcia and Diaz is based on the introduc-tion of annotations in the source code of the existing transfor-mations to indicate how the metamodels have evolved. Then,the developers can use such annotations to complete the adap-tation of the transformation by hand. The annotation processis based on some of the techniques used in this paper: a HOTgenerates the annotated transformation from a model of dif-ferences. As with Levendovszky et al., our approach offers ahigher level of automation. Our adaptation transformationsare able to deal directly with the evolved metamodels. Thus,we minimize the need for user assistance. Another improve-ment over the work form Garcia and Diaz [28] is that weconsider not only the evolution of the source metamodel butalso the target one.

As well, the work from Garcia and Diaz serves toback some of our statements. First, acknowledge thatconstruction changes (also referred to addition changes)bring complexity to the adaptation processes, hamperingits automation. Moreover, the authors suggest the need forheuristics as a way to leverage the level of automation. Notethat both issues are closely related with our proposal. Weprovide with a semi-automatic way to deal with metamodelmodifications (included construction changes) and the under-lying basis of our proposal, the AML language, lies exten-sively on the use of heuristics to generate the mapping modelsthat drive the adaptation process.

Finally, the work from Meyers et al. [26] presents ataxonomy for evolution of modeling languages based alsoon chaining adaptation transformations. It first presents ageneric model-driven scenario where a couple of DSLsare related by means of a model transformation. Next, itdescribes all the scenarios that arise due to the evolution ofany of the artefacts of such a generic scenario, i.e., a model,a metamodel or the model transformation. Likewise, it pro-vides with an algorithm that comprises a set of guidelinesto address each possible scenario. Although the frameworkproposed is quite formal and complete, including a featurediagram describing it and a metamodel to describe any pos-sible scenario (in some sense it is similar to the ones pro-posed in [29] for megamodelling purposes), it is basicallya conceptual framework that provides with no implementa-tion. This way, we could see the work from Meyers et al.such as a complementary work to ours since they formallydescribe the scenarios that we implement here. In particu-lar, we provide with a technological solution to the “domainevolution” and “image evolution” scenarios that correspondto the evolution of the source and target metamodel. Evenmore, by introducing the γ transformation we partially solvethe “projection” problem noted in [26] that arises when themetamodel evolution implies additive changes: whenever the

concepts added to the new version of the source metamodelhave correspondences with some other concepts in the targetmetamodel, the γ transformation uses traceability informa-tion to ensure that such concepts will be properly propagatedalong the transformation chain, despite such concepts haveno correspondence with meta-elements of the former sourcemetamodel version.

5.2 Adaptation of models to evolving metamodelsand model differencing

Though there are a large number of works dealing with thistopic, the reader is referred to [5,6] for a complete overviewof them. Therefore, here we will refer just to the most recentworks in the area.

In [30], Cicchetti et al. enhance their previous workfocused on metamodel evolution and model co-evolution [4].Basically they improve their previous taxonomy of meta-model changes and their technical approach to automate theadaptation of models to evolving metamodels. The proposedadaptation process shares some similarities with ours. Firstly,one computes a model of differences between a metamodeland its evolved version. Next, a transformation is derivedfrom such a model. Finally, the generated transformationperforms the model adaptation. In [31], the authors showthe applicability of the proposal by adapting the diverse arti-facts associated with a given GMF model, i.e., EMFGen,GMFTool, and GMFGraph.

Opposed to our approach, the works described in [4,30,31] rely on external tools (such as EMF Compare) toobtain the difference model and most of those tools applyhard-coded matching strategies to discover model differ-ences. Recently, EMF Compare came out with a new fea-ture which enables plugging of customizable strategies.Unlike EMF Compare, that uses a general purpose language(Java) to set up matching strategies and is tightly coupled toEMF, AML provides dedicated language constructs and ismetametamodel independent. Even EMF Compare develop-ers acknowledge their intention to evolve the tool towards atransformation/weaving approach.7

In [32] Herrmannsdoerfer et al. present a study of the evo-lution of two real metamodels. They categorize metamodelchanges according to their degree of metamodel specificity.The aim is to identify the requirements of effective tool-support for coupled evolution of metamodels and modelsin practice. Based on the requirements identified, the authorsof [33] perform a comparison of four model migration tools:COPE [34], Ecore2Ecore [35], Flock [36], and AML [17].The study focus on giving recommendations and guidelinesto choose the most suitable tool for different evolution sce-narios. In particular, AML is recommended in scenarios

7 http://wiki.eclipse.org/EMF_Compare/FAQ.

123

K. Garcés et al.

where reverse engineering, quick migration of large models,minimal hand-written code and minimal user guidance arerequired. On the other hand, the main drawback of AML isthat it supports less types of metamodel changes than COPE.However, the generative capabilities of AML make it veryconvenient to deploy our model transformation adaptationapproach.

5.3 Model change propagation via bidirectionaltransformations

The approaches presented by Xiong et al. [37] and Cicchettiet al. [38] focus on bidirectional model transformations topropagate modifications from source to target models andthe other way round. While the former does not support fullpropagation of manual modifications, the latter moves a stepforward: it guarantees a partial propagation of changes bygenerating an approximation so-called the closest model.

Like these works, our approach propagates model changesin two directions (i.e., from source to target model and viceversa). However, our approach differs from them in that thepropagation is motivated by changes at metamodel level andnot by modifications at model level. Therefore, all theseapproaches could complement each other to support the sce-narios combining the two kinds of evolutions.

6 Conclusion

Constant evolution of metamodels and co-evolution ofmodels has been a common issue to any model-driven devel-opment proposal [4]. A modification over a given meta-model (metamodel evolution) often implies updates on theconforming models (model co-evolution or model adapta-tion). Besides, it has another relevant collateral effect: sincemodel transformations are defined in terms of metamodelconcepts, a metamodel change usually has to be transmittedto its related model transformations. Out of doubt, applyingmodel-driven techniques to semi-automate the generation ofmodel transformations should help to address these issues.This kind of generative solution relies on two main basis:firstly, the already identified need for abstracting transforma-tions as transformation models [22]; secondly, the ability togenerate (semi-)automatically transformation models [24].Combining these two main basis, this work has presenteda model-driven approach to adapt model transformations toevolving metamodels.

Instead of updating transformations by hand, we pro-pose transformation chains that emulates the behavior ofsuch transformations. Every chain is appropriate to a givenscenario which is characterized by the evolution side (i.e.,source and/or target metamodel evolves) and the kind ofchanges. Evolution side impacts the order on which thetransformations of a chain are executed. The kind of change

decides whether some particular transformations have to beincluded into a chain or not. More concretely, when the sce-nario involves just refactoring changes, the adaptation chainincludes the impacted transformation along with a (back-ward) adaptation transformation that is generated automati-cally. For scenarios including destruction changes, backwardtransformations interact with λ in order to retrieve deletedinstances which may be mandatory by the impacted transfor-mations. Finally, for scenarios with construction changes, theimpacted transformation is replaced by a copy that includesadditional code devoted to generation of traceability infor-mation and another transformation, so-called γ . The latterconsumes the traceability information to propagate the man-ual additions that the user has performed in response to themetamodel construction changes.

By using external transformation composition, we pro-mote an approach independent of a particular transformationlanguage. However, to provide with a proof of concept wehave built a prototype on top of Ecore, ATL, and AML andwe have shown its application to a concrete scenario thatentails different metamodels and transformations. In sucha prototype, AML is used to generate the adaptation trans-formations. AML is a DSL for the specification of match-ing strategies which compute differences and equivalencesbetween (meta)models in a mapping model. Model transfor-mations can be derived from such mapping models.

The experimentation has shown that the hardest part isto customize the matching strategy that yields the mappingmodel from which a γ transformation is generated. We havementioned a partial solution to this issue which is the manualrefinement of the automatically generated mapping model.A straightforward solution is to provide more guidelinesthat helps tuning the matching strategies for γ accordingto the metamodels that undergo additions. Moreover, theHOT in charge of generating γ has to be extended to sup-port more complex assignments. Besides, for an effectivepropagation of construction changes, it is necessary to relyon more elaborated matching heuristics (i.e., not only IDs)to identify the correspondences between a manually mod-ified model and a model produced by the chain. Likewiseresearch should investigate transformation adaptation whenmore than one target/source metamodel evolves. Finally, therelated work section has pointed out that it would be interest-ing to enrich the taxonomy of metamodel changes supportedby our approach and to integrate our solution with approachessupporting updates at model level.

References

1. Mens, T., Wermelinger, M., Ducasse, S., Demeyer, S., Hirschfeld,R., Jazayeri, M.: Challenges in software evolution. In: Proceedingsof the Eighth International Workshop on Principles of SoftwareEvolution, IEEE Computer Society, pp. 13–22 Washington, DC,USA (2005)

123

Adapting transformations to metamodel changes

2. Bézivin, J.: In search of a basic principle for model driven engi-neering. UPGRADE Eur. J. Inf. Prof. 5(2), 21–24 (2004)

3. Wachsmuth, G.: Metamodel adaptation and model co-adaptation.In: Proceedings of the 21st European Conference on Object-Oriented Programming, ECOOP. Lecture Notes in Computer Sci-ence, vol. 4609, pp. 600–624. Springer, Germany (2007)

4. Cicchetti, A., Ruscio, D.D., Eramo, R., Pierantonio, A.: Automat-ing co-evolution in Model-Driven Engineering. In: Proceedings ofthe 12th International IEEE Enterprise Distributed Object Comput-ing Conference, EDOC: Munich. Germany, IEEE Computer Soci-ety, pp. 222–231 (2008)

5. Kolovos, D.S., Di Ruscio, D., Pierantonio, A., Paige, R.F.: Differ-ent models for model matching: An analysis of approaches to sup-port model differencing. In: Proceedings of the: ICSE Workshopon Comparison and Versioning of Software Models. CVSM ’09.Vancouver, BC, Canada, IEEE Computer Society, pp. 1–6 (2009)

6. Garcés, K., Jouault, F., Cointe, P., Bézivin, J.: Managing ModelAdaptation by Precise Detection of Metamodel Changes. In:Proceedings of the 5th European Conference on Model DrivenArchitecture-Foundations and Applications, ECMDA-FA ’09,Enschede, The Netherlands, Springer (2009)

7. Garcés, K., Jouault, F., Cointe, P., Bézivin, J.: Adaptation of mod-els to evolving metamodels. INRIA-Laboratoire d’Informatique deNantes Atlantique CNRS, Technical report (2008)

8. Mens, T., Van Gorp, P.: A taxonomy of model transformation.Electr. Notes Theor. Comput. Sci. 152, 125–142 (2006)

9. Tisi, M., Jouault, F., Fraternali, P., Ceri, S., Bézivin, J.: On the useof higher-order model transformations. In: Proceedings of the 5thEuropean Conference on Model Driven Architecture-Foundationsand Applications. ECMDA-FA09. pp. 18–33, Springer, Heidelberg(2009)

10. Rivera, J.E., Ruiz-Gonzalez, D., Lopez-Romero, F., Bautista, J.M.,Vallecillo, A.: Orchestrating ATL model transformations. In: Pro-ceedings, Preliminary (ed.) of 1st International Workshop of ModelTransformation with ATL: MtATL 2009, pp. 34–46. France, Nantes(2009)

11. Heidenreich, F., Kopcsek, J., Assmann, U.: Safe composition oftransformations. In: Proceedings of the Third international confer-ence on Theory and practice of model transformations. ICMT’10,pp. 108–122, Springer, Heidelberg (2010)

12. Jouault, F., Allilaire, F., Bzivin, J., Kurtev, I.: ATL: a model trans-formation tool. Sci. Comput. Programm. 72(1–2), 31–39 (2008)

13. Vara, J.M.: M2DAT: a Technical Solution for Model-Driven Devel-opment of Web Information Systems. PhD thesis, ETSII, Univer-sity Rey Juan Carlos, Madrid, Spain (November 2009)

14. ISO/IEC: 9075–2:2003 standard, information technology-databaselanguages (2003)

15. Oracle Corporation: Oracle database 10g. release 2 (10.2). www.oracle.com (2008)

16. Herrmannsdoerfer, M., Vermolen, S., Wachsmuth, G.: An extensivecatalog of operators for the coupled evolution of metamodels andmodels. In: 3rd International Conference on Software Language,Engineering (SLE) (2010)

17. Garcés, K.: Adaptation and evaluation of generic model matchingstrategies. PhD thesis, Université de Nantes (2010)

18. Feuerlicht, G., Pokorn, J., Richta, K.: Object-relational databasedesign: Can your application benefit from SQL:2003? In: Informa-tion Systems Development. pp. 1–13, Springer US (2009)

19. Kleppe, A.: First european workshop on composition of modeltransformations-CMT 2006. Centre for Telematics and InformationTechnology University of Twente, Technical report (2006)

20. Etien, A., Muller, A., Legrand, T., Blanc, X.: Combining indepen-dent model transformations. In: Proceedings of the: ACM Sym-posium on Applied Computing. SAC ’10. New York, NY, USA,ACM, pp. 2237–2243 (2010)

21. Bézivin, J., Büttner, F., Gogolla, M., Jouault, F., Kurtev, I., Lindow,A.: Model Transformations? Transformation Models! In: Proceed-ings of the 9th International Conference on Model Driven Engi-neering Languages and Systems. MoDELS, pp. 440–453 (2006)

22. Jouault, F.: Contribution to the study of model transformation lan-guages. PhD thesis, Université de Nantes (2006)

23. Didonet del Fabro, M.: Metadata management using model weav-ing and model transformation. PhD thesis, Université de Nantes(2007)

24. Didonet Del Fabro, M., Valduriez, P.: Towards the efficient develop-ment of model transformations using model weaving and matchingtransformations. Software Syst. Modeling 8(3), 305–324 (2009)

25. Jouault, F.: Loosely coupled traceability for ATL. In: Pro-ceedings of the Traceability Workshop of the First Euro-pean Conference on Model Driven Architecture-Foundationsand Applications(ECMDA-FA 2005), pp. 29–37, Nuremberg,Germany (2005)

26. Meyers, B., Vangheluwe, H.: A framework for evolution of mod-elling languages. Sci. Comput. Progr. 76(12), 1223–1246 (2011)

27. Levendovszky, T., Balasubramanian, D., Narayanan, A., Karsai,G.: A novel approach to semi-automated evolution of dsml modeltransformation. In: SLE. (2009), pp. 23–41

28. Garcia, J., Diaz, O.: Adaptation of transformations to metamodelchanges. In: Proceedings of the 7th Workshop in Model-DrivenSoftware Development. JISBD Workshops (2010), pp. 1–9

29. Vignaga, A., Jouault, F., Bastarrica, M.C., Brunelière, H.: Typingin model management. In: Proceedings of the 2nd InternationalConference on Theory and Practice of Model Transformations.ICMT ’09. pp. 197–212, Springer, Heidelberg (2009)

30. Cicchetti, A., Ruscio, D., Pierantonio, A.: Managing dependentchanges in coupled evolution. In: Proceedings of the 2nd Interna-tional Conference on Theory and Practice of Model Transforma-tions. ICMT ’09. pp. 35–51, Springer (2009)

31. Di Ruscio, D., Laemmel, R., Pierantonio, A.: Automated co-evolution of GMF editor models. In Malloy, B., Staab, S., vanden Brand, M., eds.: 3rd International Conference on SoftwareLanguage Engineering (SLE 2010). Number 6563 in LNCS. pp.143–162, Springer, Heidelberg (2010)

32. Herrmannsdoerfer, M., Benz, S., Juergens, E.: Automatability ofcoupled evolution of Metamodels and Models in Practice. In:11th International Conference on Model-Driven Engineering Lan-guages and Systems, MODELS. pp. 645–659, Springer, Heidelberg(2008)

33. Rose, L., Herrmannsdoerfer, M., Williams, J., Kolovos, D., Garcés,K., Piage, R., Polack, F.: A comparison of model migration tools.In: Models 2010. (2010) to appear

34. Herrmannsdoerfer, M., Benz, S., Jürgens, E.: COPE - automatingcoupled evolution of metamodels and models. In Drossopoulou,S., ed.: ECOOP. Lecture Notes in Computer Science, vol. 5653,pp. 52–76, Springer (2009)

35. Hussey, K., Paternostro, M.: Tutorial on advanced features of EMF.In: EclipseCon, http://www.eclipsecon.org/2006/Sub.do?id=171(Retrieved June 2010)

36. Rose, L., Kolovos, D., Paige, R., Polack, F.: Model migration withEpsilon Flock. ICMT, In (2010)

37. Xiong, Y., Song, H., Hu, Z., Takeichi, M.: Supporting parallelupdates with bidirectional model transformations. In: Proceedingsof the 2nd International Conference on Theory and Practice ofModel Transformations. ICMT ’09, pp. 213–228, Springer, Hei-delberg (2009)

38. Cicchetti, A., Ruscio, D.D., Eramo, R., Pierantonio, A.: JTL: abidirectional and change propagating transformation language. In:van den Brand, M., Malloy, B., Staab, S. (eds): Proceedings of the3rd International Conference on Software Language Engineering,SLE 2010, Springer (2010)

123

K. Garcés et al.

Author Biographies

Kelly Garcés is an R&D Engi-neer/Software Engineer at Net-fective Technology SA. Shereceived her Ph.D. in Sep-tember 2010 from the Uni-versity of Nantes. In 2011,she was a post-doctoral fellowin INRIA lab. Her research inter-ests are software developmentprocess and model-based legacyreverse engineering.

Juan M. Vara is an asso-ciate professor at the Depart-ment of Computing Languagesand Systems II at the Uni-versity Rey Juan Carlos ofMadrid where he is a mem-ber of the Kybele R&D groupand he received his Ph.D. in2009. His current research inter-ests focus on Model-DrivenEngineering, human aspects ofSoftware Engineering andSoftware Quality. He has beena doctoral researcher at the Uni-versity of Nantes and a postdoc-toral researcher at the EuropeanResearch Institute in Service Sci-ence at the University of Tilburg.

Frédéric Jouault is a researcherin the AtlanMod team. Hereceived his Ph.D. in Septem-ber 2006 from the University ofNantes. He did a postdoc at theUniversity of Alabama at Birm-ingham in 2007. His researchinterests involve model engi-neering, model transformation,and their application to Domain-Specific Languages (DSLs) andmodelbased legacy reverse engi-neering. Frédéric created ATL(AtlanMod Transformation Lan-guage), a DSL for model-to-model transformation.

Esperanza Marcos is a fullprofessor at the University ReyJuan Carlos of Madrid, whereshe is the head of the Depart-ment of Computing Languagesand Systems II and she leadsthe Kybele R&D group on Infor-mation Systems. She receivedher Ph.D. from the Techni-cal University of Madrid in1997 and her current researchinterests include Service Sci-ence, Model-Driven engineeringand human aspects of SoftwareEngineering.

123