Applying MDE to the (semi-)automatic development of model transformations

Information and Software Technology 55 (2013) 699–718

Contents lists available at SciVerse ScienceDirect

Information and Software Technology

journal homepage: www.elsevier .com/locate / infsof

Applying MDE to the (semi-)automatic development of model transformations

Verónica Andrea Bollati ⇑, Juan Manuel Vara, Álvaro Jiménez, Esperanza MarcosKybele Research Group, Department of Computing Languages and Systems II, Rey Juan Carlos University, 28933 Móstoles, Madrid, Spain

a r t i c l e i n f o

Article history:Received 25 November 2011Received in revised form 24 September2012Accepted 11 November 2012Available online 29 November 2012

Keywords:Model transformationsModel-driven developmentDesign tools and techniques

0950-5849/$ - see front matter � 2012 Elsevier B.V. Ahttp://dx.doi.org/10.1016/j.infsof.2012.11.004

⇑ Corresponding author. Tel.: +34 914888140.E-mail addresses: [email protected] (V.A.

urjc.es (J.M. Vara), [email protected] (Á. Jiméne(E. Marcos).

a b s t r a c t

Context: Model transformations play a key role in any software development project based on Model-Driven Engineering principles. However, despite the inherent complexity of developing model transfor-mations, little attention has been paid to the application of MDE principles to the development of modeltransformations.Objective: In order to: (a) address the inherent complexity of model transformation development and (b)alleviate the problem of the diversity of the languages that are available for model transformation, thispaper proposes the application of MDE principles to the development of model transformations. In par-ticular, we have adopted the idea of handling model transformations as transformation models in orderto be able to model, transform and generate model transformations.Method: The proposal follows an MDA-based approach that entails the modeling of model transforma-tions at different abstraction levels and the connection of these models by means of model transforma-tions. It has been empirically validated by conducting a set of case studies following a systematic researchmethodology.Results: The proposal was supported by the introduction of MeTAGeM, a methodological and technicalframework for the model-driven development of model transformations that bundles a set of Domain-Specific Languages for modeling model transformations with a set of model transformations in orderto bridge these languages and (semi-)automate model transformations development.Conclusion: This paper serves to show that a semi-automatic development process for model transforma-tions is not only desirable but feasible. This process, based on MDE principles, helps to ease the task ofdeveloping model transformations and to alleviate interoperability issues between model transformationlanguages.

� 2012 Elsevier B.V. All rights reserved.

1. Introduction

The advent of Model-Driven Engineering (MDE) [56] has led to adramatic change in the role of models since they have become themain artifact throughout the development process. In this context,model transformations are typically the link between the differentsteps of the process. For instance, in the context of Model-DrivenSoftware Development (MDSD) [58] which applies MDE principlesto software production, these transformations aim to lower theabstraction level of the target models until they can be (almost)serialized into working code. In other fields, such as model com-parison, transformations are used to generate difference models[50]. Despite the processing task for which transformations aredeveloped, there is no doubt as to their key role in any MDE pro-posal [57,61].

ll rights reserved.

Bollati), juanmanuel.vara@z), [email protected]

Nevertheless, the development of model transformations is achallenging task. With the maturity of MDE technologies [70] mod-el-based projects have begun to involve more complex metamod-els and thus more complex model transformations. Moreover, theconstant evolution of metamodels and the co-evolution of modelshas become a common issue in any model-driven project [20]. Anymodification to a given metamodel (metamodel evolution) impliesthe need to update conforming models (model co-evolution). Thishas another relevant collateral effect: since model transformationsare defined at a metamodel level, any change made to the meta-model must subsequently be transmitted to any model transfor-mation that uses it as source or target metamodel.

Furthermore, a multitude of languages, tools and/or transfor-mation engines have emerged [11,21,44] during the last few yearsin answer to the key role played by the transformations. These dif-fer in many aspects, such as the preferred approach (declarative,imperative, graph-based, etc.), tooling support (complete IDEs,command-line tools, etc.), underlying metamodeling framework(EMF, MDR, built-in, etc.) and so on. This diversity brings additionalcomplexity to the development of model transformations, since

http://dx.doi.org/10.1016/j.infsof.2012.11.004

mailto:[email protected]





http://dx.doi.org/10.1016/j.infsof.2012.11.004

http://www.sciencedirect.com/science/journal/09505849

http://www.elsevier.com/locate/infsof

700 V.A. Bollati et al. / Information and Software Technology 55 (2013) 699–718

the interoperation between transformation languages is at presentpractically nonexistent.

In order to: (a) address the inherent complexity of model trans-formation development and (b) alleviate the problem of the diver-sity of the languages that are available for model transformation,we advocate applying MDE principles to the development of modeltransformations.

Applying model-driven techniques to support the semi-automatic generation of model transformations would be a deci-sive move in helping address these issues. In particular, this paperpresents a proposal to support the model-driven development ofmodel transformations. The proposal is based on a well-knownprinciple: viewing model transformations as transformation mod-els [9]. If the set of rules and constraints that drive the constructionof a model transformation are collected in a metamodel (modeltransformation metamodel), any model transformation can beexpressed as a model conforming to that metamodel and thus pro-cessed like any other type of model. A Higher Order Transforma-tion (HOT), a type of model transformation whose input and/oroutput is a model transformation [59], can consequently be used:to handle and produce transformation models; to apply refactoringor composition techniques in order to build new transformationmodels [53]; or simply to validate and check them like any othermodel [18].

This might additionally bring interoperability to the scope ofexisting model transformation languages: if we can inject a modeltransformation coded with the FOO language into a model, then wecan map that model onto another conforming to the metamodel ofthe BAR language. We can then extract that model to the corre-sponding BAR working-code. Moreover, if we are able to define ahigh-level metamodel for a set of model transformation languages,we should be able to use it as a pivot metamodel to bridge theselanguages. As a result, it would be possible to support interopera-bility between model transformation languages by following theidea shown in [34].

In some respects, it might be considered that the role of such apivot metamodel should be played by the Query/View/Transforma-tion (QVT) standard [47]. However, the majority of the most widelyadopted model transformation languages are not actually based onQVT [38] since until recently it was not sufficiently mature. In fact,existing QVT implementations, such as Eclipse’s Declarative QVT[27] or mediniQVT [30], are considered at the same level as ATL[33] or RubyTL [52]. That is, they would be another target of thebridging process to be addressed.

Given all of the above, this paper introduces a methodologicaland technical proposal for the model-driven development (MDD)of model transformations. In particular, it presents the MeTAGeM

framework: a Meta-Tool for the Automatic GEneration ofModel transformations. The model transformation developmentprocess supported by MeTAGeM starts from a high-levelspecification of the transformation that is subsequently refinedin lower-level transformation models until they can beused to generate the source code that implements thetransformation.

It is worth noting that MeTAGeM does not provide a completelyautomated process. The model transformation developer is incharge of: defining the first transformation model (although arough version could be produced using model matching tech-niques); running the model-to-model transformations that allowssubsequent refinements to be made to produce lower abstractionmodels; running the model-to-text transformation that generatesthe source code; and refining either the intermediate transforma-tion models or the source code generated. Note that refinementis needed since complete automation is too ambitious, except fromvery simplistic transformations [29,44]. However, we shall showthat much of the source-code is effectively generated by MeTAGeM,

thus improving developers’ productivity. The principal buildingblocks of MeTAGeM are therefore:

� A set of Domain Specific Languages (DSLs) [43] with which tomodel transformations at different abstraction levels and thetoolkit needed to use them, which mainly consists of graphicaleditors and model-checkers.� A set of model transformations to bridge these DSLs. These

transformations are HOTs (which are, in certain respects,meta-transformations) that either consume or produce (orboth) transformation models.

In this paper we shall present the methodological approach ofMeTAGeM, focusing on the first set of artifacts, i.e. the DSLs used tomodel model transformations. In order to illustrate their use, a wellknown model transformation problem (Class-to-Relational)[8] is used throughout the paper. Finally, the approach is evaluatedin terms of its effectiveness and the improvement it makes toproductivity.

The remainder of the article is structured as follows: Section 2and Section 3 presents the proposal using the motivating scenarioand focusing on the different DSLs implementing the MDD processof MeTAGeM; Section 4 presents the results of applying a systematiccase study research methodology which is focused on evaluatingthe contributions of the proposal; Section 5 reviews exiting worksin the field; and finally Section 6 concludes by summarizing themain contributions and indicating areas for future work.

2. MeTAGeM: a framework for the MDD of modeltransformations

In this section we present MeTAGeM, a framework for the model-driven development of model transformations. To that end, weshall begin by describing the MDD process supported by MeTAGeM

in order to later introduce the framework, which fundamentallyconsists of various DSLs for the modeling of transformations plusa set of transformations that connect these DSLs. In this paperwe shall focus on the DSLs but we shall also provide a general over-view of the transformations.

2.1. Model-driven development process of MeTAGeM

Fig. 1 provides a general overview of the development processsupported by MeTAGeM. The shaded artifacts are already supportedby the framework, whereas those that are not shaded serve toshow how MeTAGeM can be extended in the future by definingnew DSLs and model transformations to connect them.

As will be noted, MeTAGeM considers different levels of abstrac-tion in the development of transformations. These coincide withthe levels identified in the MDA proposal [46]: PIM (Platform Inde-pendent Model) level, PSM (Platform Specific Model) and sourcecode (which can also be viewed as a model with the least possibleabstraction level [7]). We consider an additional PDM (PlatformDependent Model) that could be viewed as a specialization of thePSM level. This will be described at greater length later.

First, a Platform Independent Transformation model (PIT) de-fines the relationships between the elements of source and targetmodels, without considering any implementation detail. This mod-el is defined by the developer using the IDE provided. Nevertheless,model matching techniques such as those used in [26] can be usedto obtain a first version of the model.

A model transformation then consumes the PIT model to pro-duce a Platform Specific Transformation model (PST). This transfor-mation translates the high-level relationships previously definedinto transformation rules which are modeled in terms of a

Fig. 1. MeTAGeM model-driven development process for model transformations.

V.A. Bollati et al. / Information and Software Technology 55 (2013) 699–718 701

particular approach for model transformation development(declarative, imperative, graph-based, etc.) [21]. In particular, inthe first version of MeTAGeM that we are presenting in this paperwe have opted to support the hybrid style, which we understandis chosen by the transformation languages that are currently mostwidely accepted. Note that this decision is not at all restrictive: asthe dotted boxes show, we plan to support other paradigms orprogramming styles, such as those which are purely imperativeor declarative [21].

The next step of the process is supported by another transfor-mation that generates the model of the transformation for a spe-cific programming language. We refer to this model as thePlatform Dependent Transformation model (PDT). MeTAGeM cur-rently supports the generation of ATL [33] and RubyTL [52] work-ing-code. However, we are already working to support othertransformation languages, such as the Epsilon Transformation Lan-guage [36].

Note that the inclusion of this additional level is mainly orientedtowards improving interoperability between model transforma-tion languages: in the conventional MDA scenario, solely PIT andPST (for specific model transformation languages) models wouldbe considered. However, there is a huge semantic gap betweenthe high-level specifications collected in PIT models and the partic-ularities of a given transformation language collected in a PSTmodel. Using the PIT model as a pivot model to migrate one trans-formation written in the FOO language to the BAR language wouldtherefore be almost impossible: too many details would be lost inthe PST_Foo2PIT transition and these details would be needed la-ter, when moving from the PIT2PST_Bar.

In contrast, we have opted to add an extra level that smoothesthe transition between abstraction levels: the PDT level. The PDTthus abstracts the main features of the different programmingstyles for model transformation, whereas the PDT expresses theprevious transformation model in terms of a concrete transforma-tion language. Note that this language must be one of those follow-ing the programming paradigm selected at PST level, i.e. if we havechosen the hybrid approach at the PST level, the PDT must be de-scribed in terms of a hybrid language, such as ATL [33] or RubyTL[52]. The PST model can consequently be used as a pivot model to

migrate transformations written in a given language to anotherlanguage that adopts the same programming paradigm. Followingthe same programming paradigm implies that the constructionssupported by each one would necessarily be similar, since theyshare the same principles. The automatic migration of exitingtransformations would therefore be much easier to achieve.

Indeed, the notion of several platform-specific levels has al-ready been acknowledged in the MDA guide [46], p. 62: ‘‘A PSMmay provide more or less detail, depending on its purpose. APSM will be an implementation, if it provides all the informationneeded to construct a system and to put it into operation, or itmay act as a PIM that is used for further refinement to a PSM thatcan be directly implemented.’’

Finally, the PDT model is serialized into the code that imple-ments the transformation modeled. To support this transition wehave opted to adopt a metamodel-based approach [45] in orderto obtain bidirectional model-to-text transformations: by definingthe textual syntax for each element of the transformation meta-model it is possible to obtain not only a code generator but alsoa model extractor. That is, we can generate the code that imple-ments the transformation from the transformation model or viceversa, i.e. extract the transformation model from the code thatimplements it.

At this point, it is also worth pointing out that although eachstep of the process has been automated by transformation models,each interim model can be refined by the developer using the edi-tors included in the IDE that supports MeTAGeM. Indeed, as we havealready mentioned, this refining is necessary, as will be explainedin Section 4.5. Note that the model transformations bundled inMeTAGeM are intended to work with any given model that con-forms to the corresponding metamodel. Thus, the manual refine-ments do not invalidate the transformation models to beconsumed by such transformations.

The MeTAGeM toolkit, which will be introduced in the followingsection, partially supports the development process presentedabove by integrating two large sets of software artifacts: on theone hand, a set of DSLs with which to model transformations atdifferent levels, which will be presented in Section 3.2; and on theother hand, a set of model transformations, both model-to-model

Fig. 2. MeTAGeM toolkit development process.


(m2m) and model-to-text (m2t) that connect these DSLs, thus(semi-)automating the different steps of the development process.A general overview of these transformations will be provided in Sec-tion 3.3. It is worth mentioning that the current version of theMeTAGeM toolkit aims to provide a proof of concept for the pro-posal. It therefore supports the MDD of ATL and RubyTL modeltransformations. Future versions of the framework will broadenthe scope of model transformation programming styles and the lan-guages supported. This is highlighted in the legend of Fig. 1.

2.2. MeTAGeM toolkit

As we have outlined, MeTAGeM combines a methodological pro-posal and its technical support. In particular, in order to provide aproof of concept for the proposal described above, we have devel-oped an EMF-based [16] toolkit that supports the MDD process forthe model transformations presented. It is basically composed of aset of DSLs with which to model model transformations plus a setof model transformations that connect them. The construction ofMeTAGeM therefore consists basically of developing these artifactsand the tooling needed to use them.

Fig. 2 therefore shows a simplified version of the developmentprocess followed to build MeTAGeM, which applies the technicaldecisions for the construction of DSL toolkits described in [66].Note that the order in which each task must be completed is indi-cated by rounded numbers, while the input needed to accomplisheach task is depicted by the different arrows. For instance, Model-to-Model transformations are the fourth task to address andits input data are essentially the metamodels (abstract syntax) ofthe different DSLs.

The first task involved in supporting a new DSL in MeTAGeM isthe specification of the abstract syntax of the DSL, i.e., of its meta-model. The metamodels of the DSLs bundled in MeTAGeM havebeen defined by using KM3 [6], a language for the textual defini-tion of metamodels and/or directly Ecore, the metamodeling lan-guage of EMF [16]. The DSLs for which KM3 was used will bespecified later.

The next task is the definition of the DSL concrete syntax.Broadly speaking, defining the concrete syntax of a DSL consistsof associating a notation with each concept and relationship col-lected in the metamodel. Note that here we focus on visual nota-tions. Thus, in order to provide a visual notation for each DSL wehave used the facilities provided by EMF and AMW [25] to developgraphical editors for each DSL. Nevertheless, owing to the genericnature of EMF these editors do not always fit with the nature ofspecific scenarios. In other words, the generative nature of EMF im-plies a compromise between the level of automation (100%) andthe level of adjustment to specific purposes. i.e. EMF generates

an efficient though not perfect editor in a reasonable time andmanner. EMF-generated code therefore tends to be modified in or-der to adapt the generated editor and thus enrich modeling expe-riences in specific scenarios [41]. The next task addressed whendeveloping a new DSL for MeTAGeM is therefore that of improvingthe basic editor with the aim of maximizing its use for the devel-oper of the transformations. The figures shown below will serveto illustrate the result. Note that although these improvementshave been made by directly modifying the EMF generated code,we are working to automate them by combining the use of AMWannotation models [64] and MoDisco [15] capabilities in order tocustomize model browsers.

At this point, we can state that the development of the DSL (andits tooling) has been completed. It is now time to bridge it with al-ready existing DSLs by developing the model transformations thatuse it as either source or target. To that end we use ATL for m2mtransformations whereas TCS is used for bidirectional m2t trans-formations [31] in order to support code generation and modelextraction.

Finally, once all the transformations in which the new DSL is in-volved have been developed, we address the implementation ofmodel-checking mechanisms by using the Epsilon Validation Lan-guage (EVL) [37]. Typically, the metamodel of a DSL is not alwayssufficient to attain a precise and rigorous specification of what avalid model will be. It simply collects the abstract syntax of thelanguage, while some constraints have to be attached in order tocollect certain domain rules that could not be collected in themetamodel itself [28]. These constraints are defined at metamodellevel and evaluated in conforming models to check whether theyare valid. Likewise, we have noted that most of the domain rulesthat a given model has to satisfy do not arise until the model isused as the source of a model transformation since the executionfailed in the presence of erroneous models. It is for this reason thatwe have opted to delay the implementation of the model valida-tion mechanisms in the development process until all the transfor-mations involving the DSL have been completed.

3. MDD of model transformations with MeTAGeM

This section explores MeTAGeM insights in greater depth byproviding in-depth explanations of each step of the MDD processoverviewed in Fig. 1. To do so, the development of well-knownmodel transformation is used as a conducting thread.

3.1. Motivating scenario: Class2Relational

The class to relational transformation [9] is a simple yet com-plete scenario that has been traditionally used as a case study to

Fig. 3. (a) Class metamodel and (b) relational metamodel.

Table 1Class2Relational mapping rules.

Class metamodel Relational metamodel

Class TableDataType TypeSingle-value attribute (DataType) ColumnMulti-value attribute (DataType) TableMulti-value attribute (Class) Table

Fig. 4. MDD of the Class2Relational ATL transformation with MeTAGeM.


present new approaches or languages for the development of mod-el transformations (see, for example, [18,33,71]).

Since source and target domains (and even the rationale behindthe mappings) are well known, the addition of accidental complex-ity to the presentation of the proposal is avoided. However, forthose interested in seeing the use of MeTAGeM in more complexscenarios, the toolkit that can be downloaded from its Web site1 in-cludes some projects in which MeTAGeM is used to develop muchmore complex transformations.

Fig. 3 shows the Class and Relational metamodels used in thiswork, taken from the ATL Web site [31], while Table 1 summarizesthe mapping rules that comprise the transformation that makes itpossible to move from simple class models to relational models.

In order to develop the Class2Relational ATL transforma-tion with MeTAGeM, we follow the process depicted in Fig. 4 (notethat this is merely an instantiation of the generic process shown inFig. 1).

The developer defines a model that collects the correspon-dences between the elements of the Class and Relational meta-models (Class2Relational.pit). As mentioned previously, itis possible to commence with a first version of this model thathas been automatically generated by means of model matchingtechniques. An ATL transformation (PIT2PSTH.atl) then auto-matically generates the transformation model for the hybrid ap-proach (Class2Relational.pst) which is consumed by a newATL transformation (PSTH2ATL.atl) in order to generate thetransformation model for ATL. Finally, the TCS injector/extractorthat is bundled in the ATL IDE serializes the previous modelin the ATL source code which implements the modeledtransformation.

MeTAGeM incorporates launchers and wizards for each of thetransformations mentioned to automate the generation of bothATL and RubyTL transformations. Therefore, if the target languagewas RubyTL, the process would be exactly the same, the onlydifference being the launchers used.

The following section presents each of the DSLs bundled inMeTAGeM, using the Class2Relational transformation to illus-trate its use. In particular, we shall focus on the transformation ruledescribed informally in the following manner.

� For each class in the source model a table in the target model iscreated with the same name as the class name.

The complete case study can be found on the MeTAGeM Website.

1 http://metagem.wordpress.com/.

3.2. Modeling model transformations

The following sub-sections provide detailed descriptions ofeach of the DSLs bundled in MeTAGeM. To that end, we introducetheir abstract syntax (basically their metamodels) and show theuse of each DSL to define the transformation models used to pro-duce the Class2Relational transformation described above.

3.2.1. Platform Independent Transformation model (PIT)One of the main objectives of MeTAGeM was to allow the devel-

opment of model transformations without considering the

http://metagem.wordpress.com/

Table 2High-level relationships modeled at PIT level.

Source metamodel Target metamodel

0 1 N

0 –p

–1

p p p

N –p p


targeted language and the source and target metamodels of eachparticular scenario. To that end, we needed a high-level modelinglanguage with which to define high-level transformation models.This section introduces the metamodel of this language: the Plat-form Independent Transformation (PIT) metamodel. Note that PITmodels correspond to the upper level of the model-driven develop-ment process depicted in Figs. 1 and 4.

In order to identify the constructions that the PIT metamodelshould contain we have combined the main conclusions gatheredfrom our reviews of existing transformation languages [11,66]with the lessons learned while developing model transformationswith different languages in different application domains[12,23,62,63,65]. As a result, a set of constructions was identifiedthat allows the definition of transformation models to be dealtwith at the highest level of abstraction. In essence, a high-leveltransformation model is nothing but a collection of relationshipsbetween the elements of source and target metamodels. In orderto specify such relationships it is necessary to identify:

� The type of the elements involved in the relationship.� The cardinality of the relationship. Table 2 summarizes the

types of relationships identified according to their cardinality.

The simplest and most common scenario is a one-to-one rela-tionship (mapping rule). Indeed, we should aim to express all therules as one-to-one mapping rules in order to keep the transforma-tion simple and ease the maintenance of traceability links [72].However, this is only feasible for quite simple metamodels thatare semantically close.

Fig. 5. Platform Independent T

Given all of this, Fig. 5 shows the PIT metamodel: each PITmodel (ModelRoot) is composed of Source and Target metamod-els (InModelTransf and OutModelTransf) and bundles a setof Relations objects that connect source and target objects(InElement and OutElement). Note that the cardinality of therelation defines different sub-types of relations, whereas the typeof the elements related is identified by the Relations.typeE

property, while the Relations.MyTypeElem property serves toidentify the nature of the relationship (primary, secondary orabstract). The complete specification of the metamodel can befound in [11].

With regard to implementation details, given that a PIT model isin essence a relationships model we opted to represent PIT modelsas weaving models [5]. In particular, we used the facilities providedby the AMW tool as the underlying basis to implement the PIT DSL.The PIT metamodel therefore extends the Core Weaving metamod-el presented in [25].

The use of the PIT DSL to define a high-level specification of theClass2Relational transformation (i.e. its PIT model) is shownbelow. After creating a new PIT model using the correspondingwizard, the developer instantiates the different metaclasses ofthe metamodel described above in order to define the correspon-dences between source and target metaclasses. To illustrate theprocess, the upper-left hand corner of Fig. 6 shows an overviewof the Class2Relational PIT model defined with MeTAGeM.

There are three different panels: that on the left shows the ele-ments of the Class metamodel; that on the right shows the ele-ments of the Relational metamodel; and finally, that in themiddle is the PIT model, whose objects represent the relationshipsbetween the source and target metamodels specified by thedeveloper.

The lower half of Fig. 6 shows an excerpt of the PIT model whichfocuses on the OneToMany relation between a Class, and theTable that maps it onto the Relational model. In particular, itfocuses on the high-level binding between the name attribute ofthe Class and the name attribute of the Table. Note also theproperties tab for both attributes in the top right corner pointingto the corresponding elements in the source and target models.

ransformation metamodel.

Fig. 6. Class2Relational Platform Independent Transformation model.


Moreover, even though this is not the case here, some guard con-ditions could be specified in the InElement object in order to filterwhich source Class objects will be mapped by this rule. Likewise,complex expressions with which to state how the binding shouldbe performed can be attached to the OutElement object.

3.2.2. Platform Specific Transformation model for the Hybrid approach(PST-H)

As mentioned previously, as regards supporting the modeling oftransformations for a particular platform (or programming style),we have chosen to consider the hybrid approach. The objective ofthis was solely to provide a proof of concept for the proposal. Werefer to this metamodel as PST-H (Platform Specific Transformationmodel for the Hybrid approach) since it is intended to abstractthe main concepts handled by the model transformation lan-guages that adopt the hybrid approach, such as ATL [33] or RubyTL[52]. Nevertheless, as Fig. 1 shows, the architecture of MeTAGeMis defined to support the inclusion of other programming stylesin the future: new metamodels can be defined for graph-based,pure imperative or pure declarative model transformationlanguages.

As with the PIT metamodel, we have analyzed the most repre-sentative (hybrid) transformation languages in order to definethe metamodel shown in Fig. 7. One of the main conclusions ofthe analysis is that although each language refers to those ele-ments using different names, they all fundamentally use two typesof elements that offer a similar functionality:

� Rules (Rule metaclass) are used to generate the elements spec-ified by their RightPattern in the target model. They can berun once they have been explicitly invoked by another rule(imperative rules) or each time a matching occurs betweenone part of the source model and the source pattern of the rule(declarative or matched rules). This source pattern is specifiedby a LeftPattern object. Each rule owns a set of propertiesthat are used to identify the concrete PDM type that will beused to map the rule when the transformation model is refinedfor a specific transformation language (see Section 3.3.1). More-over, each pattern refers to a set of source or target Elementobjects.

� Operations (Operation metaclass) work as auxiliary functionswith which to obtain a particular interim value and/or tomaintain references to elements or sets of elements of thesource and target models. These operations can return a valueof a certain data type (Return) and can be defined for aspecific type of element (context reference), which can beeither a source or target element (InElementRule andOutElementRule).

A transformation model is therefore basically a Module thatcontains rules and operations, together with references to themetamodels that participate in the transformation (InMetaModeland OutMetaModel). The complete specification of the metamodelcan be found in [11].

With regard to implementation details, the PST-H metamodelhas been implemented as an Ecore metamodel and the (graphical)concrete syntax is supported by an improved version of the EMFtree-like editor generated from this metamodel.

To return to the motivating scenario, the upper part of Fig. 8shows that the PIT model shown in the previous section is con-sumed by the PIM2PSTH.atl transformation to produce theClass2Relational PST-H model. In essence, every relation ob-ject in the PIT model is transformed into a rule object in the PST-H model.

In particular, the bottom part of the figure shows the correspon-dence between the Class2Table relation of the PIT model and theClass2Table rule of the PST-H model. Recall that, like the PITmodel, the PST-H model can be refined by the developer, eitherby modifying some of the generated objects or by aggregatingnew ones.

3.2.3. Platform Dependent Transformation model (PDT)The next step of the MDD process illustrated in Fig. 1 and

instantiated in Fig. 4 is to produce a transformation model for agiven technology, i.e., for a particular model transformation lan-guage (one of those that adopt the programming style selectedpreviously: the hybrid approach). As mentioned previously,for the proof of concept provided by MeTAGeM we opted to sup-port the ATL [33] and RubyTL [52] model transformationlanguages.

Fig. 7. Platform Specific Transformation metamodel (hybrid approach).

Fig. 8. Class2Relational: from PIT model to PST-H model.


With regard to the selection of ATL, there were two decisive fac-tors. Firstly, ATL is considered the de facto standard for the devel-opment of model transformations [66] and it has additionallybeen developed according to MDE principles. As a result, it pro-vides a complete metamodel that allows ATL model transforma-tions to be modeled without the need to define a new

metamodel. In addition, former versions of the ATL IDE includeda TCS injector/extractor with which to generate ATL code fromATL models and vice versa.

A simplified version of the ATL metamodel is shown in Fig. 9. Itsmost important elements will be briefly described here (see [33]for a detailed explanation of this metamodel).

Fig. 9. ATL metamodel.


An ATL transformation model is a module (Module) that con-tains different types of rules (Rule) and operations (Helper). ACalledRule should be explicitly invoked from the imperative sec-tion (ActionBlock) of another rule.

In contrast, a MatchedRule is declarative by nature and it rep-resents the core of any ATL transformation. Every time the trans-formation engine finds a correspondence between an excerpt ofthe source model and the source pattern of the rule (InPattern),the rule is executed, and the elements specified in the target pat-tern of the rule (OutPattern) are added to the target model.

Finally a LazyMatchedRule is somewhere between a declara-tive and an imperative rule. It is a kind of MatchedRule, and wecould therefore say that it is declarative. However, it should beexplicitly invoked, receiving the element or elements correspond-ing to its source pattern as parameters. We could therefore saythat it is imperative. It is worth mentioning that, if the propertyisUnique takes the value true, then the rule will only add ele-ments to the target model the first time it is invoked. Subsequentinvocations return a reference to the element/s created the firsttime.

The rest of the metamodel (fundamentally the part on the rightin Fig. 9) contains the constructions needed to model the machin-ery of a transformation, such as the Bindings needed to initializethe value of properties and references and the Statements

needed to model the imperative part of a rule.Nevertheless, in order to show that the proposal is applicable to

any transformation language, it was necessary to prove its efficiencywith other languages. Unfortunately, on the contrary to ATL, mostexisting model transformation languages were not developedaccording to MDE principles. They were not therefore developedin a metamodel-based manner (at least explicitly). Of the remaininghybrid model transformation languages, we therefore chose RubyTLbecause, on the one hand, some partial specifications of this meta-model existed [52,53], which facilitated the construction of a com-plete metamodel and on the other, our proximity to the developersof the language facilitated communication with them when it cameto defining this metamodel and building the technological supportneeded to use it. That said, it is worth mentioning that we are cur-rently completing the next release of MeTAGeM which also supportsthe development of ETL [36] model transformations, another lan-guage that adopts the hybrid approach.

Fig. 10 shows a simplified version of the metamodel defined forthe RubyTL language. A RubyTL transformation model (Transfor-mation) is fundamentally made up of various types of rules (Rule)and operations (Decorator).

A TopRule is analogue of an ATL MatchedRule: for eachmatching of the source pattern (FromElement), the constructionspecified by the target pattern (ToElement) is added to the targetmodel. Normally, there is only a TopRule which is in charge of ini-tiating the execution of the transformation. If there were variousTopRules, they would be run in the order in which they appearin the specification of the transformation. In a certain sense, thefact that the developer should perform a pseudo-schedule takesaway part of the declarative nature of the language. A RubyTL Nor-malRule is similar to an (Unique) ATL LazyMatchedRule since ithas to be explicitly invoked and repeated invocations return refer-ences to the element/s created in the first invocation. Finally aCopyRule serves to complement the previous types of rule. Thatis, they should be explicitly invoked and each invocation causesthe instantiation of the target pattern in the target model.

Note that most components are similar to those included in theATL metamodel since both adopt the same programming style. Infact, the ETL metamodel does not differ much from those for ATLand RubyTL.

Finally, as with the PST-H DSL, the (graphical) concrete syntaxused to define ATL and RubyTL transformation models is providedby means of (improved) EMF tree-like editors. Note that that usedfor ATL was recovered from former versions of the ATL IDE whereasthat used for RubyTL has been developed from scratch.

To return to the development of the Class2Relational mod-el transformation, as the top part of Fig. 11 shows, the PSTH2ATL

consumes the PST-H model described in the previous section in or-der to generate the transformation model for ATL.

Again, the bottom half of the figure focuses on the mapping ofthe Class2Table rule. In this case the Class2Table rule objectof the PST-H model, whose isMain property evaluates to true, ismapped onto a MatchedRule object in the ATL transformationmodel.

Finally, the last step in the MDD of the Class2Relational

model transformation is to serialize the ATL transformation modelin the source code that implements the modeled transformation.As mentioned previously, this step is supported by a TCS injec-tor/extractor [32]. Fig. 12 shows a partial overview of this transfor-mation, focusing on the Class2Table mapping rule.

3.3. Model transformations for model transformations development

This section introduces the two types of model transformationsconsidered in MeTAGeM. According to Fig. 1, MeTAGeM defines a setof m2m transformations that bridge the different DSLs presented

Fig. 10. RubyTL metamodel.

Fig. 11. Class2Relational: from PST-H model to PDT model for ATL.


Fig. 12. Class2Relational: from PDT model for ATL to ATL source code.


in Section 3.2, i.e. they (semi-)automate the transition from high-level to low-level transformation models. It also defines anotherset of m2t transformations that map the low-level transformationmodels onto the source code that implements the transformationmodeled. In addition, since they are bidirectional m2t transforma-tions, they support the extraction of transformation models fromexisting model transformations.

Since the main focus of this work is not to present these trans-formations, we have summarized the main highlights below. For amore detailed insight see [11].

3.3.1. Model-to-Model transformationsWith regard to the development of m2m transformations, we

follow the generic process outlined below:

� First, the mappings between models are defined using naturallanguage and structured in a set of rules.� These rules are then formalized as an intermediate step towards

implementation. To that end, we use the graphical notation ofthe QVT Relations standard [47], following the idea reflectedin several previous works, such as [35] or [49]. Formalizingthe mappings before implementing them leads to the detectionof errors and inconsistencies in the early stages of softwaredevelopment, and can help to increase the quality of both themodels built and the subsequent code generated from them.� Finally, the previous set of formalized rules is implemented

using ATL.

As already mentioned, this topic will not be dealt with here, andwe shall not therefore present the QVT formalization or the ATLimplementation (both of which can be found in [11]). Nevertheless,in order to illustrate the development process supported by MeTA-GeM, Table 3 summarizes the correspondences that drive the trans-formation with which to move from platform-independenttransformation models to platform-specific transformation modelsfor the hybrid paradigm (PIT2PSTH transformation). It is worthmentioning that these rules are the result of a continuous refiningprocess that might continue in the near future.

The root element of the PIT model (ModelRoot) is mapped ontothe corresponding root element for the PST-H model (Model). Like-wise, the references to the source and target metamodels in the PITmodel (InModelTransf and OutModelTransf) are mapped ontothe corresponding references in the PST-H Model (InMetaModeland OutMetamodel).

Two abstract rules then take charge of the generic mapping ofthe Relations objects: the first creates a Rule object which mapsRelations objects that do not depend on any other Relationsobject; the second creates an ElementIncluded object to mapdependent Relations objects. These two abstract rules are spe-cialized in a set of rules for each specific type of relation.

Finally, the InElement objects are transformed intoSourceElementRule objects that represent the source patternof the rule. This might contain a guard object defining a conditionwith which to filter the set of source objects matched by the rule.Likewise, OutElement objects give rise to TargetElementRule

objects which represent the target pattern of the rule.On the other hand, Table 4 summarizes the mapping rules of

which the transformation of platform-specific transformationmodels (for the hybrid approach) into platform-dependent trans-formation models for ATL (PSTH2ATL) are composed.

It contains a set of mapping rules with which to create ATL Ruleobjects from PST-H Rule objects. Each rule maps different types ofrules depending on certain attribute values such as isMain,isAbstract, etc. Furthermore, the inPattern and outPattern

properties of each Rule are filled with references to theSimpleInPatternElement and SimpleOutPatternElement

objects which in turn map SourceElementRule and TargetEl-

ementRule objects respectively. The ElementIncluded objectsare subsequently mapped onto Binding objects containingpropertyName and values objects which map the differentLeftPattern and RightPattern from source objects. Finally,Operation objects are mapped onto ATL Helper objects. Therules that map platform-specific transformation models (for thehybrid approach) onto platform-dependent transformation modelsfor RubyTL (PSTH2RubyTL) are similar.

3.3.2. Model-to-Text transformationsOnce a PDT model has been obtained, either for ATL or RubyTL,

the next stage is to serialize these models in the source code thatimplements the modeled transformation.

For this purpose, the most immediate step is to use one of theexisting EMF-based languages for m2t transformation, such as Acc-eleo MTL, Xpand or MOFScript. However, we have opted to adoptthe same approach as ATL developers. That is, we have opted to de-velop a bidirectional mapping that supports both m2t (extraction),and t2m transformation (injection) [45].

In particular, we have used the Textual Concrete Syntax(TCS) [31] which provides a DSL for the specification of the

Table 3From PIT models to PST-H models: general overview.

PIT metamodel PST-hybrid metamodel

ModelRoot ModuleInModelTransf InMetaModelOutModelTransf OutMetaModelRelations No dependency on other

elementsRule

Dependency on otherelements

ElementIncluded

OneToOne No dependency on otherelements

Rule:– in with cardinality = 1– out with cardinality = 1

SourceElementRuleOutElementRule


ElementIncludedRightPatternLeftPattern

OneToZero Rule:– in with cardinality = 1

SourceElementRuleZeroToOne No dependency on other

elementsRule

– out with cardinality 1TargetElementRule


ElementIncludedRightPattern (withoutelements)LeftPattern

OneToMany Rule:– in with cardinality = 1– out with cardinality = N

SourceElementRuleN OutElementRule

ManyToOne No dependency on otherelements

Rule:– in with cardinality = N– out with cardinality = 1

N SourceElementRuleOutElementRule


ElementIncludedRightPattern(1 RightPattern with NsourceElements)LeftPattern

ManyToMany Rule:– in with cardinality = N– out with cardinality = N

N SourceElementRuleN OutElementRule

InElement (with GuardCondition) SourceElementRuleGuard

InElement (without GuardCondition) SourceElementoRuleOutElement TargetElementRule

Table 4From PST-H to RubyTL models: general overview.

High-level transformation metamodel ATL metamodel

Module ModuleInMetaModel OclModel (Input)OutMetaModel OclModel (Output)Rule isMain = true y in > 0 Rule Matched Rule

isAbstract = true yisExtended = defined y in > 0

MatchedRule(superRule = true)

isMain = false and in > 0 LazyMatchedRule(isMain = false and in > 0 andtypeAttribute = #unique)

LazyMatchedRule(unique = true)

in = 0 CalledRuleSourceElementRule SimpleInPatternElementTargetElementRule SimpleOutPatternElementElementIncluded Binding

– LeftPattern – propertyName (Left side)– RightPattern – value (Right side)

Operation Helper– Return.datatype – Operation.returnType– Boolean – BooleanType– Integer – IntegerType– String – StringType– Element – OclModelElement


correspondence between the metamodel of a given DSL and its tex-tual representation. An ANTLR grammar together with a parser forthis grammar is generated from this. This parser (also known as aninjector) takes a textual program of the DSL as input and generatesa model conforming to the DSL metamodel. TCS also generates anextractor that provides us with m2t capabilities.

As mentioned, previous versions of the ATL IDE already in-cluded a TCS-based injector/extractor. It was therefore only neces-sary to recover it (since it is no longer bundled in the standarddistribution of ATL) and integrate it into MeTAGeM. In addition,we have developed another TCS-based injector/extractor for Rub-yTL from scratch. MeTAGeM is therefore able to produce ATL andRubyTL code from ATL and RubyTL transformation models respec-tively, in addition to consuming ATL and RubyTL model transfor-mations in order to produce transformation models.

4. Validation

The validation of MeTAGeM has consisted basically of carryingout an experiment that comprises several case studies. To that

end, three different groups of developers have addressed thedevelopment of three model transformations with and withoutMeTAGeM and the execution of these transformations with differentinput models.

The main objectives of this validation have been: to assesswhether the proof of concept could be used to produce modeltransformations (Feasibility) and to verify whether doing so wouldserve to increase model transformation developers’ productivity(Productivity increase). We also wished to verify whether the trans-formations generated would be able to produce correct models(Validity). The latter implies comparing the results of the executionof the transformations generated with the results of executing anexisting version of the same transformation, whose correctionhas been already evaluated (which we refer to as referencetransformation).

In order to improve the rigor of this validation, we have fol-lowed the guidelines for conducting case studies proposed byRuneson and Höst in [51]. In particular, we have adopted the pro-tocol used in [48] which is based on the proposal of Runeson andHöst. In essence, the protocol distinguishes a set of stages, namely:case selection, design, execution, data collection, analysis andinterpretation, and evaluation of its validity. The highlights of eachstage are presented as follows.

4.1. Case selection

In order to consider different levels of complexity, the followingcase studies were selected (from lesser to greater complexity):

� The previously mentioned Class2Relational transformationfound on the ATL Web site, which contains 114 Lines of Code(LOC).� The KM32XML transformation that maps KM3 models onto XML

models, which can also be downloaded from the ATL Web site(166 LOC).� The UML2ORDB4ORA transformation, one of the transforma-

tions bundled in M2DAT-DB, a tool for the development ofmodern database schemas [65,66]. This maps conceptual datamodels, represented by a UML class diagram, onto object-relational models for Oracle (485 LOC). The tool can bedownloaded from its Web site (http://m2datdb.word-press.com/).

http://m2datdb.wordpress.com/

http://m2datdb.wordpress.com/


Note that these case studies provide contrasted transformationsthat can be used as reference implementations with which trans-formations produced with MeTAGeM can be compared. The resultof executing the transformations generated will therefore becompared with those obtained by executing these referencetransformations. Moreover, the three reference transformationsare public, so any interested reader can download them to verifytheir complexity. In this respect, some previous works exist thatpropose indicators with which to assess the complexity of modeltransformations [69], such as the size of the source and targetmetamodels or the number of the different types of rules includedin the transformation. The complexity of the model transforma-tions used here has been judged according to these indicators.

Finally, it is worth mentioning that we have opted to use ATLcase studies to validate MeTAGeM since ATL provides more scenar-ios, documentation and information in general than any othertransformation language, in particular RubyTL [66].

4.2. Design

According to the objects and purpose of the study, the followingresearch questions were posed to assess the Feasibility and the in-crease in Productivity of the proposal. These questions had to beanswered with the data gathered from the development of thetransformations:

� Can the proposal properly support the creation of the sourcecode that implements the transformation?� How many Lines of Code (LOC) are automatically generated?� How many LOC have to be refined manually?� How many LOC have to be coded from scratch?� How long does it take to develop the transformation withMeTAGeM?� How long does it take to develop the transformation manually?� Are the transformations that are generated bigger than those

developed manually?

Two additional research questions were also posed to verify theValidity of the proposal, i.e., these questions had to be answeredwith the data gathered from the executions of the transformationsgenerated with MeTAGeM and the reference transformations.

� Are the models produced by both transformations different? Ifso, what are the main differences?– Direct observation– EMF Compare [14], a diff tool.� What is the difference between the execution time of both

transformations?

MeTAGeM also aims to reduce the inherent complexity of modeltransformation development, independently of the developer’s le-vel of expertise. The case studies were therefore conducted withthree different groups of developers:

� Highly skilled developers (HSd), who had more than 6 months ofexperience in model transformation development. In particular,this group comprised seven PhD students whose research focusis on MDE and who use ATL for implementation tasks.� Medium skilled developers (MSd), who had been developing

model transformations for between 2 and 6 months. This groupincluded 15 Information Systems Engineering MSc studentsfrom the University of Rey Juan Carlos. These students hadattended seminars on MDE, EMF and ATL in the context of thecourse on Novel approaches to Information Systems engineering,which included a set of assignments on DSL design and modeltransformations development.

� Beginner skilled developers (BSd), who had no experience inmodel transformation development. This group included 20students in the fourth year of the Computer Science degree atthe University of Rey Juan Carlos. They attended an introductorylecture on EMF and ATL.

4.3. Execution

Before conducting the case studies that comprise the experi-ment, the three groups of developers attended a tutorial on thedevelopment of model transformations with MeTAGeM, in whichthey developed some toy examples, such as the Families2Per-

sons transformation [1].Each student then developed the three model transformations

with and without MeTAGeM. To that end, they were provided witha high-level specification of each transformation. Each specifica-tion consisted of the mapping rules comprising each transforma-tion described in natural language, thus alleviating biased resultsderived from the students having previous knowledge of the trans-formation. Obviously there was no consensus between developers:each developer defined his/her own transformation models start-ing from the specifications provided. These were therefore thetransformations generated, and consequently the refinements thateach developer had to perform on the transformation eventuallygenerated. They were also provided with another specificationwhich described both the data collection process and the data thathas to be collected, in addition to different source and target mod-els to enable them to compare the target models obtained withthose that should be obtained in order to identify possiblerefinements.

Likewise, in order to avoid possible deviations in executiontimes, each student used a similar execution hardware environ-ment to develop the transformations. Finally, in order to gatherdata concerning execution times, each transformation developedwas executed 10 times with four different sized models.

4.4. Data collection

Table 5 summarizes the data related to the LOC produced withMeTAGeM (on average) by each group of developers. Again, for eachcase study, the first column shows how many LOC were automat-ically generated by MeTAGeM (Generated); the next columns showhow many of them had to be refined by hand (Refined) and howmany had to be coded from scratch, i.e. they had to be added man-ually to the transformation produced (Coded from scratch); and fi-nally, the last column shows the total LOC of the finaltransformation (Total LOC = Generated + Coded from Scratch). Notethat the final row shows the average percentages for these magni-tudes: for instance, MeTAGeM generates, on average, 86.43% of theClass2Relational transformation LOC, of which 23.83% haveto be manually refined; 13.57% of the LOC are therefore addedmanually.

To illustrate the performance of the three different groups ofsubjects considered, Table 6 shows the percentage of LOC eachgroup has generated, modified and added from scratch, on average.For instance, High-Skilled developers (HSd) are able to generate85.14% of the total amount of LOC of the transformation. This im-plies that they generate 7.66% and 6.47% more LOC than MSd andBSd respectively.

Table 7 summarizes the data related to the time (seconds) de-voted to the development of each transformation with and withoutMeTAGeM. For each case study (Class2Relational, KM32XML,UML2ORDB) the first column shows the time devoted to modelingthe transformation at different levels with MeTAGeM (Modeling)and the next column shows the time devoted to refining the codegenerated (Refining). Both times are added to compute the time

Table 5Code generation with MeTAGeM.

Class2Relational KM32XML UML2ORDB

Generated Refined Coded fromscratch

TotalLOC


TotalLOC


TotalLOC

HSd 93.43 20.71 5.71 99.14 115.26 25.26 38.32 153.58 395.26 69.58 63.58 458.84MSd 84.40 20.20 14.20 98.60 109.52 31.05 58.10 167.62 336.52 78.56 76.32 412.84BSd 78.40 20.15 20.30 98.70 124.26 31.69 30.25 154.51 305.58 102.56 95.62 401.20

Percentile 86.43% 23.83% 13.57% 73.37% 25.21% 26.63% 81.50% 24.17% 18.50%

Table 6Distance between different types of subjects (percentiles).

Generated (%) Refined (%) Coded from scratch (%)

HSd 85.14 20.56 14.86MSd 77.48 25.21 22.52BSd 78.67 28.26 21.33


devoted to developing the transformation with MeTAGeM

(MeTAGeM). The last columns show the time devoted to developingthe transformation manually, without the aid of MeTAGeM (Manualdevelopment).

Fig. 13 shows a column chart overview of these data. Note thatthe time devoted to manual development is higher than that de-voted to development with MeTAGeM for the three types of devel-opers considered.

With regard to the comparison with the reference implementa-tions, Table 8 compares their LOC with those of the transforma-tions produced with MeTAGeM.

Likewise, Table 9 summarizes the data that allows their execu-tion times to be compared.

4.5. Analysis and interpretation

The principal conclusions derived from the above data are sum-marized as follows. To that end, we review the answers to the re-search questions posed during the design of the case studies.

4.5.1. Feasibility and productivity increaseFirst, we review those related to the Feasibility and the increase

in Productivity of the proposal:

� Can the proposal properly support the creation of the sourcecode that implements the transformation?

The case studies have served to show that MeTAGeM can be usedto produce much of the source code that implements a given trans-formation but not the whole transformation.

� How many LOC are automatically generated? How many LOChave to be refined manually? How many LOC have to be codedfrom scratch?

Table 7Average development times: MeTAGeM vs manual development.

Class2Relational KM32XML

Modeling Refining MeTAGeM Manualdevelopment

Modeling Refining M

HSd 1690 597 2287 3682 1843 1117 2MSd 2261 1140 5357 4669 2770 1029 3BSd 4314 1616 5965 9586 4912 1859 6

According to the data summarized in Table 5 (see last row), onaverage, MeTAGeM generates around 80% of the source code of themodel transformation, whereas 25% of that code has to be refinedby hand. Finally, 20% of the source code has to be implementedfrom scratch, i.e., 20% of LOC are added manually to the sourcecode produced by MeTAGeM.

In this respect, the data summarized in Table 5 next to thosefrom Table 6 show that the expertise level has a direct influenceon the amount of source code generated. Highly Skilled developers(HSds) are able to refine the transformation model for ATL pro-duced by MeTAGeM in order to maximize the amount of source codegenerated. In contrast, Medium and Beginner Skilled developers(MSd and BSd) experience more problems in identifying the refine-ments that need to be made to that model. They are not able to re-fine the transformation at an abstraction level other than that ofthe source code itself. Moreover, the code generated by MSd needsless refinement than the code generated by BSd.

The refinements and additions that need to be made to thesource code produced by MeTAGeM are principally related to thebody of auxiliary functions since MeTAGeM fills them with com-ments. Other common points of refinement were the conditionsof some guards: non-expert developers were not able to useMeTAGeM supported constructions to model over-complex expres-sions. They therefore had to be manually refined over the sourcecode generated. Finally, note that not only the expertise level ofthe developer but also the complexity level of the transformationinfluences the amount of source code that has to be either refinedor added manually.

� How long does it take to develop the transformation withMeTAGeM? How long does it take to develop the transformationmanually?

The data summarized in Table 6 shows that the developmenttime increases as the level of complexity of the transformation in-creases and the expertise level of the developer decreases, inde-pendently of whether or not MeTAGeM is used. A furthercomment is that the time devoted to modeling the transformationis much higher than the time devoted to refining the source codegenerated in all the cases. For instance, the box chart in Fig. 14shows that the means of the time that HSd devoted to modelingthe transformation with MeTAGeM (4314, 4912, 6194) is alwayslower that the mean of the time devoted to refine the source code

UML2ORDB

eTAGeM Manualdevelopment

Modeling Refining MeTAGeM Manualdevelopment

960 4227 1961 1015 2977 4625800 5626 3324 1483 4807 7120771 8532 6194 2344 8538 14941

Fig. 13. Average development times: MeTAGeM vs manual development: graphicoverview.

Table 8LOC: MeTAGeM vs reference implementation.


MeTAGeM Reference MeTAGeM Reference MeTAGeM Reference

98.81 114 158.57 166 424,29 485

Table 9Execution times: MeTAGeM vs reference implementation.


MeTAGeM Reference MeTAGeM Reference MeTAGeM Reference

Model 1 0.0046 0.0032 0.0049 0.0033 0.0895 0.0836Model 2 0.0251 0.0234 0.0266 0.0248 0.0974 0.0969Model 3 0.0734 0.0719 0.0778 0.0762 0.1980 0.0958Model 4 0.2769 0.2747 0.2935 0.2912 0.0983 0.0994

Fig. 14. Box chart of time devoted to modelling vs refining for each case study(HSd).


produced from the modeled transformation (1616, 1859, 2344) foreach case study.

Finally, the most relevant conclusion regarding developmenttime is that the use of MeTAGeM reduces the time needed to devel-op the transformation in all cases. For instance, the box chart inFig. 15c shows that the mean of the time BSd devoted to develop-ing the transformation with MeTAGeM is lower than the mean of thetime devoted to doing so by hand.

Likewise, in order to provide an overall conclusion, Fig. 16 com-pares the time devoted to the development of model transforma-tions with MeTAGeM (on average) with that dedicated to doing somanually.

� Are the transformations generated bigger (in terms of LOC) thanthose developed manually?

As Table 8 shows, for the three case studies conducted, refer-ence transformations are bigger than the mean of the correspon-dence transformations developed with MeTAGeM. Nevertheless,this difference is not significant since we have observed that it isprincipally related to the inclusion of comments in the referenceimplementations.

4.5.2. ValidityThe second set of research questions was posed to be answered

with the data gathered from the executions of the transformationsgenerated with MeTAGeM and the reference transformations. Theprincipal objective of these questions was to assess the Validityof the proposal.

� Are the models produced by both transformations different? Ifso, what are the main differences?

The students used direct observation to verify that the modelsgenerated by running the transformation produced with MeTAGeM

were equal to those generated by the reference implementations.They then used EMFCompare [14], a tool with which to calculateand represent model differences, to back up this observation. Asa result, we can conclude that the models have exactly the same

structure. The only differences were caused by the different nam-ing policies. For instance, the UML2ORDB4ORA reference transfor-mation assigns a kind of stereotyped name to every target object.This kind of decision cannot be obviously reflected in the transfor-mation produced with MeTAGeM unless intermediate models aremodified to do so.

� What is the difference between the execution time of bothtransformations?

Finally, Table 9 shows that, as expected, there are no significantdifferences between the execution times of the transformationsproduced with MeTAGeM and the reference implementations sinceboth transformations should be almost identical.

4.6. Evaluation and discussion

This section analyzes the validation process that has been car-ried out and discusses the main conclusions and the lessonslearned from this process.

With regard to internal validity, the case studies have differentlevels of complexity and they have been conducted by 42 develop-ers with different levels of expertise in order to prevent biased re-sults. We therefore believe them to be statically representativeresults.

Nevertheless, the experiments could be replicated with trans-formations that imply source and target metamodels from differ-ent domains. Likewise, the results related to the time devoted tomanual development might be biased because the students hadpreviously used MeTAGeM to develop the transformation and theytherefore already knew the transformation.

Fig. 15. Box chart of development time with MeTAGeM vs manual development: (a) HSd, (b) MSd y, (c) BSd.


With regard to the validation of the proposal, the case studieshave served to show a number of limitations. Some of these willbe tackled soon (and some of them are currently under develop-ment) but others will not be tackled because we do not aim to re-lease a fully industrial tool but rather a usable prototype.

When we first conceived MeTAGeM, we aimed to provide a com-pletely automated MDD process for model transformations. How-ever, the case studies have served to confirm that a completelyautomatic process, from requirements to final deployment, is notfeasible. Around 25% of the code generated has to be refined byhand and 20% of the total LOC has to be coded from scratch. How-ever, a huge amount of the source code is generated automaticallyand not only the most repetitive and error-prone parts, one of thetheoretical advantages of MDE [56], but also most of the pattern-matching parts, the heart of any model transformation. This pro-posal thus alleviates the accidental complexity inherent to modeltransformations development [26,29].

In this line, the case studies conducted have also served to showthat support for the imperative aspect of hybrid languages needs tobe improved. In particular, the current prototype is able to gener-ate the signature of auxiliary functions, but their body has to becoded by the developer using the target language’s own syntax.Nevertheless, we are evaluating existing proposals for the model-ing of OCL since many of the existing transformation languagesuse an OCL-based language for navigation purposes [54]. OCL-based expressions could therefore be used as technology-agnosticspecifications to model the internals of operations and later trans-late them into specific-code for each particular language [17,19].

With regard to future improvements, a major issue with thecurrent version of MeTAGeM is the fact that, to date, it supports onlybinary transformations, i.e., transformations that consume onlyone source model and produce one target model. However, themethodological proposal was designed to support n-ary transfor-mations (see Section 2.1). The next release of MeTAGeM that is closeto being finished therefore supports n-ary transformations.

Another decisive improvement on which we are already work-ing is to provide support for the reverse engineering of transforma-tions. Refinement of the source code produced can be translated toRubyTL and ATL transformation models, since MeTAGeM bundlescode extractors. However, it cannot be translated to the PST-Hmodel or the PIT model. We are therefore working on the develop-ment of m2m transformations to move from platform-dependentto platform-specific and platform-independent models.

In addition, the decision to use a bidirectional m2t transforma-tion to support code generation and model extraction raises certainissues. For instance, the concrete syntax of RubyTL hampers thebinding of variables and elements of the transformation at the timeof injecting it into a model. For instance, according to the RubyTL

metamodel shown in Fig. 10, the src1 variable should produce avariable object, whose classname property should be Src1

and its metamodel reference should point to the InMM object. How-ever, owing to the concrete syntax of RubyTL, we have not beenable to establish such a binding when generating the RubyTL mod-el. We will probably address this issue by modifying the RubyTLmetamodel, but we are still considering some other solutions. In-deed, the fact that RubyTL is an embedded DSL hampers the mod-eling of RubyTL transformations since we would have to extend themetamodel to support the modeling of some Ruby elements.

Finally, it is worth mentioning that since the current prototypewas developed atop of older Eclipse and ATL versions, updatingtasks will be addressed in the near future.

5. Related works

In order to verify whether that MeTAGeM improves the state-of-the-art, we have reviewed existing works in the field. In this re-spect, we have studied those works that deal with the MDD ofmodel transformations. The following section therefore providesa broad overview of this literature review which can be consultedin [11].

5.1. On the MDD of model transformations

First, there is a set of works that acknowledges the need to in-crease the level of abstraction in the development of model trans-formations. One of the first was that of Bezivin et al. [10]. Followingthe MDA four-layer architecture [46], the authors argue that trans-formations should be specified regardless of the platform on whichthey will be deployed (Platform Independent Transformation, PIT)and subsequently refined into transformations for specific plat-forms (Platform Specific Transformation, PST). This idea is developedfurther in [9], in which the authors show, with the help of a casestudy, the modeling of a particular transformation. In [40], Küsteret al. presented a systematic method for model transformationdevelopment in which high-level mapping rules are translated intolow-level mapping rules according to a collection of pre-established design guides. In [67], Vignaga puts forward aniterative and incremental method for the development of modeltransformations. The proposal covers the whole lifecycle of thetransformations and aims to increase the developers’ productivity.Nevertheless, although [68] sets out the first steps towards imple-mentation, the author abandoned the proposal before being able toput it into practice in the form of a tool. Finally, more recently,Lano and Kolahdouz [42] proposed an MDD process for modeltransformations focused on the semantics of the transformation.

Fig. 16. Box chart of development time with MeTAGeM vs manual development.


The authors show how the proposal is applied to the classicClass2Relational scenario but do not offer any type of toolingsupport.

Next, we consider another group of related works that consider,in some form, the use of models and/or the distinction of levels ofabstraction in the development of transformations and accompanythe proposal with some sort of technical support.

Didonet Del Fabro’s doctoral thesis [25] presents AMW (ATLASModel Weaver), a generic and adaptable tool, which provides asolution based on model weaving [5] for the management of rela-tions between the elements of different models. In one of the casestudies included, an AMW weaving model is used to specify therelations between the elements of the source and target metamod-els of a transformation. This model is consumed by a HOT to pro-duce the model of the transformation for the ATL language. Ourproposal in some respects expands on the work of Didonet Del Fab-ro, by increasing the level of abstraction of the starting model andautomating the transition from this model to a platform specificone.

On the other hand, TROPIC (TRansformations on Petri Nets inColor) [39] is a framework which is focused on supporting therefinement of transformations and providing mechanisms for thereuse of components for its development. TROPIC identifies twolevels of abstraction in the development of transformations. Firstly,it defines a high-level specification of the transformation (mappingview) from predefined generic operators that can be viewed ascomponents. From this high level specification it generates a lowlevel executable specification (transformation view) based on PetriNets in Color, which facilitates the refinement of the transforma-tion. TROPIC can therefore be viewed as a debugging environmentbased on translating declarative specifications into fully executablecolored nets. The proposal allows existing transformations to be

Table 10Existing works on the application of MDE to model transformations development.

Criteria Bezivin et al. Didonet Del Fabro Guerra et al. K

Point of view M T M T M T M

PIM Y � � � Yp

YPSM Y � Y

pY

pY

PIM2PSM P � N � Pp

PPSM2PSM N � Y

pN � P

Codegen P � Yp

Yp

P

translated into transformation views, e.g. the authors show it forQVT-Relations [71]. However, we find that the method proposedfor high-level specification is too restrictive since the designer islimited by the use of a set of pre-defined operators to definethe transformation. In other words, it is not a real platform-independent transformation model since it is restricted by theset of constructions supported by the framework. What is more,using Petri Nets for debugging purposes might not be veryintuitive.

The most comprehensive work in the area of MDD of modeltransformations published to date is probably [29], in whichGuerra et al. presented transML, a family of languages with whichto consider the development of transformations from an engineer-ing perspective. These languages offer support to the whole life-cycle, from requirements to implementation, including languagesfor the architectural design of transformations and emphasizingvalidation tasks. They thus support the semi-automatic develop-ment of test cases or the specification of restrictions to definewhich models are valid as a transformation input. Their proposalsupports the semi-automatic development of model transforma-tions for different languages (in particular QVT-Relations andETL). From our point of view, the transML approach might be veryuseful for over-complex transformations. However, it might be tooverbose. In general, transformations are not the software to be pro-duced but a means to produce software. In other words, an excessof accidental complexity [13] might appear by following an over-formal and strict development process for model transformationswhen the transformations are not the only software to be pro-duced. In contrast, our proposal considers only three differentmodels with which to develop a model transformation, two ofwhich are generated semi-automatically, requiring only somemanual refinement. However, we find the support for verificationand testing of transformations provided by transML particularlyinteresting and we are considering the idea of combining both pro-posals in the near future since we believe that they may be com-plementary. Finally, it is worth noting that, in contrast withMeTAGeM, the current version of transML provides only partialimplementations of the proposal and requires far more manualtasks.

Finally, Table 10 summarizes the main conclusions of the liter-ature review performed, focusing on the following criteria:

� Considers or supports the definition of high-level specificationsof model transformations (PIM).� Considers or supports the definition of low-level specifications

of model transformations (PSM).� Considers or supports the mapping between such specifications

(PIM2PSM).� Considers or supports the mapping between low-level specifi-

cations at different abstraction levels (PSM2PDM).� Considers or supports code generation from transformation

models (Codegen).

Note that the criteria have been evaluated from two differentpoints of view: methodological and technical, i.e., we were inter-

üster et al. Lano et al. TROPIC Vignaga MeTAGeM

T M T M T M T M T

� Y � Yp

P � Yp

� Y � Yp

P � Yp

� N � N � P � Yp

� N � N � P � Yp

� N � P � Y � Yp


ested in identifying whether the proposal considers (Methodolog-ical) or supports (Technical) each aspect. For the former, the valueoptions are (Y)es, (N)o, (P)artially; for the latter, we simply checkwhether or not tool support is provided for that specific task.

5.2. Improving the development of model transformations

Finally, before finishing this section, it is worth mentioning an-other set of existing works found during the literature review per-formed. We refer to proposals that focus on improving thedevelopment of model transformations, without necessarily usingMDE principles to do so, or which do not follow a MDD process.

For instance, in [26], Didonet del Fabro and Valduriez definedand implemented a cumulative matching process. Successive ver-sions of a weaving model that identify the similarities and differ-ences between the source and target metamodel of atransformation are therefore generated automatically until theweaving model is sufficiently refined so as to be used to generatea transformation model. The process is automated by means of dif-ferent HOTs. We have put this proposal into practice in [63] to sup-port (semi-)automatic model migration. It was very useful togenerate a first version of the transformation when dealing withover-large or over-complex metamodels. Nevertheless, since it isbased on heuristics, the cumulative matching process was not ableto correctly identify some of the structural differences betweenthese metamodels. Moreover, the interim models generated duringthe process are not aimed at modeling the transformation itself,but only the similarities and differences between source and targetmetamodels. This prevents them from being used as high-leveltransformation models.

Sanchez Cuadrado et al. [55] presented a proposal based onreutilization mechanisms for the development of transformations.In particular the authors defined transformation templates for gen-eric parts of metamodels, called metamodel concepts. These tem-plates could later be combined to define transformations. In thisresearch line, i.e., those works which aimed to support reuse inthe development of model transformations, it is worth mentioningthe work of Atzeni et al. [3] in which the authors presented MIDST(Model Independent Data and Schema Translation), a frameworkfor the platform-independent modeling of database schemas.MIDST implements MODELGEN [4], an operator for the migrationof database schemas from one data model to another; for instance,relational to object oriented. MIDST proposes the definition oftransformation rules in Datalog. The user can combine these ele-mentary rules to define more complex transformations. The frame-work is, in some respects, ad hoc for the database domain andconsiders neither a platform-specific nor a platform-dependentmodel.

In summary, the works of Sanchez Cuadrado et al. and Atzeniet al. do provide some form of composition and/or modularizationfor model transformation development. It could thus be concludedthat they in some way allow the abstraction level at which trans-formations are developed to be raised. However, they do not focuson supporting a MDD process for model transformations: they donot establish which levels should be considered or which lan-guages should be used in the modeling of the transformations inthese levels, or, obviously, automate the transition from one modelto another. Since our work permits the high-level specification oftransformations, it can be fully aligned with research focused onreusing mechanisms such as those mentioned above. In particular,the relations that must hold between source and target metamod-els, collected in the platform-independent model of MeTAGeM, sim-plify the identification of suitable transformation patterns to beapplied when generating the platform-specific model of the modeltransformation.

Finally we would like to consider metamodeling frameworkssuch as ATOM3 [24], MetaEdit+ [60], GME [22] or MOFLON [2].These are principally focused on providing mechanisms withwhich to define DSLs and producing the tools needed to deal withthese models created with such DSLs. Moreover, owing to the keyrole of model transformations, in some cases they incorporatesome kind of support for model transformation development, likeIDEs including facilities such as syntax highlighting, code comple-tion and the like. However, apart from these facilities, they do notprovide any other mechanism with which to increase model trans-formation developers’ productivity or to raise the level of abstrac-tion at which transformations are developed. Actually, from thepoint of view of MeTAGeM they can be seen as another targetingplatform: MeTAGeM could be extended in order to produce sourcecode for the model transformation engines bundled in theseframeworks.

6. Conclusion and further work

Model transformations are the cornerstone of any MDE pro-posal. However, despite the impact of MDE and the relevance ofmodel transformations, there has not, to date, been a great dealof research oriented towards applying MDE principles to the devel-opment of model transformations. Indeed, their inherent complex-ity and the existence of a wide set of model transformationlanguages make the development of transformations an ideal sce-nario in which to apply MDE techniques. We should therefore beable to: (a) bring simplicity to the development process and (b)shorten the distance between different model transformation lan-guages. In order to address these issues, rather than defining adhoc bridges, we have preferred to propose an MDD process formodel transformations in which high-level transformation modelsare translated into specific models for different approaches and aresubsequently refined to obtain the transformation model for a spe-cific technology. A transformation is ultimately another softwareproduct, and is thus subject to the application of MDE techniquesfor its development.

In order to put this idea into practice, in this paper we haveintroduced the specification of MeTAGeM, a methodological andtechnical framework for the model-driven development of modeltransformations. In particular, this research has focused on intro-ducing the different DSLs produced to support the modeling oftransformations at different abstraction levels and the DSL toolkitthat supports them by means of a simple yet complete transforma-tion scenario. We have also briefly introduced the different m2mand (bidirectional) m2t transformations that automate the differ-ent steps of the MDD process supported by MeTAGeM.

Moreover, we have conducted a set of systematic case studies inorder to evaluate the proposal. These have served to show that,although the code generated by MeTAGeM needs manual refine-ment and completion, it reduces the need to hand-craft code andincreases model transformation developers’ productivity. In thisrespect, it is worth mentioning that, outside the scope of the sys-tematic case studies presented, we have realized that as long asthe developer obtains experience in the use of MeTAGeM, the in-crease in productivity is much more significant.

This paper provides us with a number of directions for futurework. We are working to integrate support for other model trans-formation languages by adopting the already supported hybridparadigm, such as ETL [36]. What is more, as long as metamodelsfor other transformation languages are available, we should be ableto develop mappings between them and assist in the migration ofany existing transformation. Moreover, as long as we specify high-level transformation metamodels, they could be used as pivotmetamodels to move between different model transformation en-


gines. For instance, in this paper we have used a metamodel for hy-brid languages which collects the main abstractions shared by themost widely adopted hybrid model transformation languages. Thesame approach could be applied to bridge graph-based or impera-tive languages. We could even bridge these high-level metamodelsin order to support interoperability not only between languagesthat follow the same paradigm, but also between those that followdifferent paradigms.

Acknowledgments

This research was carried out in the framework of the MASAI(TIN-2011-22617) project, financed by the Spanish Ministry of Sci-ence and Innovation. The authors wish to thank David Granada forhis valuable contributions during the implementation tasks.

References

[1] F. Allilaire, F. Jouault, Families to Persons: A Simple Illustration of Model-to-Model Transformation, 2007, <http://www.eclipse.org/m2m/atl/doc/ATLUseCase_Families2Persons.pdf> (last accessed 12.05.12).

[2] C. Amelunxen, A. Königs, T. Rötschke, A. Schürr, MOFLON: A standard-compliant metamodelling framework with graph transformations, in:Proceedings of the Second European Conference on Model DrivenArchitecture – Foundations and Applications, ECMDA-FA’2006, Bilbao, Spain,2006.

[3] P. Atzeni, P. Cappellari, P. Bernstein, A. Modelgen, model-independent schemaand data translation, in: Proceedings of EDBT Conference, EDBT’2006, LNCS3896, Springer, 2006, pp. 368–385.

[4] P. Atzeni, P. Cappellari, P. Bernstein, A. Modelgen, Model Independent SchemaTranslation, in: Proceedings of ICDE Conference, IEEE Computer Society,Tokyio, 2005, pp. 1111–1112.

[5] P.A. Bernstein, Applying model management to classical meta data problems,in: Proceedings of the First Biennial Conference on Innovative Data SystemsResearch, Asilomar, CA, USA, 2003.

[6] J. Bézivin, F. Jouault, KM3: a DSL for metamodel specification, in: Proceedingsof the 8th IFIP International Conference on Formal Methods for Open Object-Based Distributed Systems, FMOODS’2006, Bologna, Italy, 2006.

[7] J. Bézivin, In search of a Basic Principle for Model Driven, Engineering,Novatica/Upgrade V (2) (2004) 21–24.

[8] J. Bézivin, B. Rumpe, A. Schürr, L. Tratt, Mandatory example specification.Model Transformations in Practice Workshop, in: Proceedings of the SatteliteEvents at the MoDELS’2005 Conference, Montego Bay, Jamaica, 2006, pp 120–127.

[9] J. Bézivin, F. Büttner, M. Gogolla, F. Jouault, I. Kurtev, A. Lindow, ModelTransformations? Transformation Models!, in: Proceedings of the 9thInternational Conference on Model Driven Engineering Languages andSystems, MoDELS’06, Genève, Italy, 2006.

[10] J. Bezivin, N. Farcet, J.M. Jezequel, B. Langlois, D. Pollet, Reflective Model DrivenEngineering, UML, vol. 2863 of LNCS, 2003, pp. 175–189.

[11] V.A. Bollati, MeTAGeM: A Framework for Model-Driven Development of ModelTransformations, Ph.D. Thesis, University Rey Juan Carlos, 2011.

[12] V.A. Bollati, P. Atzeni, J.M. Vara, E. Marcos, Model management systems vs.model driven engineering: a case study, in: Proceedings of the 27thSymposium on Applied Computing, SAC’2012, ACM, Riva del Garda, Italy,2012, pp. 865–872.

[13] F. Brooks, The Mythical Man-Month, Addison Wesley, 1995.[14] C. Brun, A. Pierantonio, Model differences in the eclipse modelling framework,

UPGRADE IX (2) (2008) 29–35.[15] H. Bruneliere, J. Cabot, F. Jouault, MoDisco, A generic and extensible

framework for model driven reverse engineering, in: Proceedings of theIEEE/ACM International Conference on, Automated Software Engineering,2010, pp. 1–2.

[16] F. Budinsky, E. Merks, D. Steinberg, Eclipse Modeling Framework 2.0, seconded., Addison-Wesley Professional, 2008.

[17] J. Cabot, E. Teniente, Transformation techniques for OCL Constraints, Science ofComputer Programming 68 (3) (2007) 179–195.

[18] J. Cabot, R. Clarisó, E. Guerra, J. de Lara, Verification and validation ofdeclarative model-to-model transformations through invariants, Journal ofSystems and Software 83 (2) (2010) 283–302.

[19] J. Cabot, R. Pau, R. Raventós, From UML/OCL to SBVR specifications: achallenging transformation, Information Systems Journal 35 (4) (2010) 417–440.

[20] A. Cicchetti, D. Di Ruscio, R. Eramo, A. Pierantonio, Automating co-evolution inmodel-driven engineering, in: Proceedings of the 12th International IEEEEnterprise Distributed Object Computing Conference – EDOC’2008, München,Germany, 2008.

[21] K. Czarnecki, S. Helsen, Feature-based survey of model transformationapproaches, IBM Systems Journal 45 (3) (2006) 621–645.

[22] J. Davis, GME: the generic modeling environment, in: Companion of the 18thAnnual ACM SIGPLAN Conference on Object-Oriented Programming, Systems,Languages, and Applications, OOPSLA’2003, 2003.

[23] V. De Castro, E. Marcos, J.M. Vara, Applying CIM-to-PIM model transformationsfor the service-oriented development of information systems, Information andSoftware Technology 53 (1) (2011) 87–105.

[24] J. De Lara, H. Vangheluwe, M. Alfonseca, Meta-modelling and graph grammarsfor multi-paradigm modelling in AToM3, Journal on Software and SystemsModelling 3 (3) (2004) 194–203.

[25] M. Didonet Del Fabro, Metadata Management Using Model Weaving andModel Transformation. Ph.D. Thesis University of Nantes, Nantes, France, 2007.

[26] M. Didonet Del Fabro, P. Valduriez, Towards the efficient development ofmodel transformations using model weaving and matching transformations,Software Systems Modeling 8 (3) (2008) 305–324.

[27] Eclipse Declarative QVT, 2010, <http://wiki.eclipse.org/M2M/QVT_Declarative_(QVTd)> (last accessed 10.05.12).

[28] S. Efftinge, P. Friese, J. Köhnlein, Best Practices for Model-Driven SoftwareDevelopment, 2008, InfoQ, <http://www.infoq.com/articles/model-driven-dev-best-practices> (last accessed 10.05.12).

[29] E. Guerra, J. De Lara, D. Kolovos, R. Paige, O. Santos, Engineering ModelTransformations with transML, Software and Systems Modeling, http://dx.doi.org/10.1007/s10270-011-0211-2.

[30] ikv++ technologies, medini QVT, 2008, <http://projects.ikv.de/qvt> (lastaccessed 10.05.12).

[31] F. Jouault, Class to Relational ATL Transformation, <http://www.eclipse.org/m2m/atl/atlTransformations/#Class2Relational> (last accessed 10.05.12).

[32] F. Jouault, J. Bezivin, I. Kurtev, TCS: a DSL for the specification of textualconcrete syntaxes in model engineering, in: Proceedings of the FifthInternational Conference on Generative programming and ComponentEngineering, GPCE’06, Portland, Oregon, USA, 2006, pp. 249–254.

[33] F. Jouault, F. Allilaire, J. Bézivin, I. Kurtev, ATL: A model transformation tool,Science Computing Program 72 (1–2) (June 2008) 31–39.

[34] F. Jouault, I. Kurtev, On the interoperability of model-to-model transformationlanguages science, Computing Program 68 (3) (October 2007) 114–137.

[35] N. Koch, Transformation techniques in the model-driven development processof UWE, in: Proceedings of the Workshop. of the 6th International Conferenceson Web Engineering, ICWE’2006, ACM, vol. 155, Palo Alto, California, 2006.

[36] D. Kolovos, R. Paige, F. Polack, The epsilon transformation language, in:Proceedings of the 1st International Conference on Model Transformation,Zurich, Switzerland, July 2008.

[37] D. Kolovos, R. Paige, F. Polack, Detecting and repairing inconsistencies acrossheterogeneous models, in: Proceedings of the International Conference onSoftware Testing, Verification, and Validation, ICST’08, IEEE CS, 2008, pp. 356–364.

[38] I. Kurtev, State of the art of QVT: a model transformation language standard,in: Proceedings of the Third International Symposium on Applications ofGraph Transformations with Industrial Relevance, AGTIVE’2007, Kassel,Germany, 2007.

[39] A. Kusel, TROPIC – A framework for building reusable transformationcomponents, in: Proceedings of the Doctoral Symposium at MODELS 2009,School of Computing, Queen’s University, Denver, October 2009.

[40] J. M. Küster, K. Ryndina, R. Hauser, A Systematic Approach to Designing ModelTransformations. Report RZ 3621, IBM Research, <http://www.zurich.ibm.com/pdf/csc/rz3621.pdf> (last accessed 10.05.12).

[41] P. Langer, K. Wieland, M. Wimmer, J. Cabot. From UML profiles to EMF profilesand beyond, in: Judith Bishop, Antonio Vallecillo (Eds.), Proceedings of the49th International Conference on Objects, Models, Components, Patterns,TOOLS’11, Springer-Verlag, Berlin, Heidelberg, 2011, pp. 52–67.

[42] K. Lano, S. Kolahdouz Rahimi, Model-driven development of modeltransformations, in: Jordi Cabot, Eelco Visser (Eds.), Proceedings of theFourth International Conference on Theory and Practice of ModelTransformations, ICMT’2011, vol. 6707, LNCS, Springer, 2011, pp. 47–61.

[43] M. Mernik, J. Heering, A.M. Sloane, When and how to develop domain-specificlanguages, ACM Computer Surveys 37 (4) (2005) 316–344.

[44] T. Mens, P.V. Gorp, A taxonomy of model transformation, Electronic Notes inTheoretical Computer Science 152 (GraMoT) (2006) 125–142.

[45] P.A. Muller, F. Fleurey, F. Fondement, M. Hassenforder, R. Schneckenburger, S.Gérard, et al., Model-driven analysis and synthesis of concrete syntax, in:Proceedings of the Model Driven Engineering Languages and Systems –MoDELS/UML’2006, Genova, Italy, 2006.

[46] OMG, Model driven architecture, in: J. Miller, J. Mukerji, (Eds.), A TechnicalPerspective, OMG document -ormsc/01-07-01, 2001.

[47] OMG. MOF 2.0 Query/View/Transformation (QVT), V1.0, OMG Document –formal/08-04-03.

[48] R. Pérez-Castillo, J.A. Cruz-Lemus, I. García-Rodríguez de Guzmán, M. Piattini,A family of case studies on business process mining using MARBLE, Journal ofSystems and Software 85 (6) (2012) 1370–1385.

[49] A. Rodríguez, I.G.-R. De Guzmán, E. Fernández-Medina, M. Piattini, Semi-formal transformation of secure business processes into analysis class and usecase models: an MDA approach, Information and Software Technology 52 (9)(2010) 945–971.

[50] L.M. Rose, M. Herrmannsdoerfer, J.R. Williams, D. Kolovos, K. Garcés, R. Paige,F. Polack, A Comparison of Model Migration Tools, in: Proceedings of the 13thInternational Conference on Model Driven Engineering Languages andSystems: Part I, MODELS’10, Springer-Verlag, Berlin, Heidelberg, 2011, pp.61–75.

http://www.eclipse.org/m2m/atl/doc/ATLUseCase_Families2Persons.pdf

http://www.eclipse.org/m2m/atl/doc/ATLUseCase_Families2Persons.pdf

http://wiki.eclipse.org/M2M/QVT_Declarative_(QVTd)

http://wiki.eclipse.org/M2M/QVT_Declarative_(QVTd)

http://www.infoq.com/articles/model-driven-dev-best-practices

http://www.infoq.com/articles/model-driven-dev-best-practices

http://dx.doi.org/10.1007/s10270-011-0211-2

http://dx.doi.org/10.1007/s10270-011-0211-2

http://projects.ikv.de/qvt

http://www.eclipse.org/m2m/atl/atlTransformations/#Class2Relational

http://www.eclipse.org/m2m/atl/atlTransformations/#Class2Relational

http://www.zurich.ibm.com/pdf/csc/rz3621.pdf

http://www.zurich.ibm.com/pdf/csc/rz3621.pdf


[51] P. Runeson, M. Höst, Guidelines for conducting and reporting case studyresearch in software engineering, Empirical Software Engineering 14 (2)(2009) 131–164.

[52] J. Sánchez Cuadrado, J. García Molina, M. Menarguez Tortosa, RubyTL: apractical, extensible transformation language, in: Proceedings of the EuropeanConference on Model Driven Architecture – Foundations and Applications,ECMDA-FA’2006, Bilbao, Spain, 2006.

[53] J. Sánchez Cuadrado, J. García Molina, Approaches for model transformationreuse: factorization and composition, in: Proceedings of the 1st Internationalconference on Theory and Practice of Model Transformations, ICMT’2008,Zurich, Switzerland, 2008.

[54] J. Sánchez Cuadrado, F. Jouault, J. Garcia Molina, J. Bézivin, Optimizationpatterns for OCL-based model transformations, Models in SoftwareEngineering 5421 (2009) 273–284).

[55] J. Sánchez Cuadrado, E. Guerra, J. De Lara, Generic model transformations: writeonce, reuse everywhere, in: Jordi Cabot, Eelco Visser (Eds.), Proceedings of the4th International Conference on Theory and Practice of Model Transformations,ICMT’11, Springer-Verlag, Berlin, Heidelberg, 2011, pp. 62–77.

[56] D.C. Schmidt, Model-driven engineering, IEEE Computer 39 (2) (2006) 25–31.[57] S. Sendall, W. Kozaczynski, Model transformation – the heart and soul of

model-driven software development, IEEE Software 20 (5) (2003) 42–45.[58] T. Stahl, M. Volter, K. Czarnecki, Model-Driven Software Development:

Technology, Engineering, Management, John Wiley & Sons, 2006.[59] M. Tisi, F. Jouault, P. Fraternali, S. Ceri, J. Bézivin, On the use of higher-order

model transformations, in: Proceedings of the 5th European Conference onModel Driven Architecture – Foundations and Applications, ECMDA-FA ‘09,Springer-Verlag, Berlin, Heidelberg, 2009, pp. 18–33.

[60] J. Tolvanen, M. Rossi, MetaEdit+: defining and using domain-specific modelinglanguages and code generators, in: Companion of the 18th Annual ACMSIGPLAN Conference on Object-Oriented Programming, Systems, Languages,and Applications, OOPSLA’03, 2003.

[61] L. Tratt, Model transformations and tool integration, Journal of Software andSystems Modeling 4 (2) (2005) 112–122.

[62] J.M. Vara, V. De Castro, E. Marcos, WSDL automatic generation from UMLmodels in a MDA framework, International Journal of Web Services Practices 1(1–2) (2005) 1–12.

[63] J.M. Vara, M. Didonet Del Fabro, F. Jouault, J. Bézivin, Model weaving supportfor migrating software artifacts from AUTOSAR 2.0 to AUTOSAR 2.1, in:Proceedings of the International Conference on Embedded Real Time SoftwareERTS’2008, Société des Ingénieurs de l’Automobile (SIA), 2008.

[64] J.M. Vara, V. De Castro, M. Didonet Del Fabro, E. Marcos, Using weaving modelsto automate model-driven web engineering proposals, International Journal ofComputer Applications in Technology (39) (2009) 245–252.

[65] J.M. Vara, B. Vela, V. Bollati, E. Marcos, Supporting model-driven developmentof object-relational database schemas: a case study, in: Proceedings of theInternational Conference on Model Transformation, ICMT’2009, Zurich,Switzerland, 2009.

[66] J.M. Vara, E. Marcos, A framework for model-driven development ofinformation systems: technical decisions and lessons learned, Journal ofSystems and Software 85 (10) (2012) 2368–2384. http://dx.doi.org/10.1016/j.jss.2012.04.080.

[67] A. Vignaga, A methodological approach to developing model transformations,in Proceedings of the Model-Driven Engineering Languages and Systems,MoDELS’2007. Nashville (TN), United States, October 2007.

[68] A. Vignaga, D. Perovich, M.C. Bastarrica, Towards Layered Specifications ofModel Transformation. Technical Report TR/DCC-2007-1, January 2007,<http://www.dcc.uchile.cl/TR/2007/TR_DCC-2007-001.pdf> (last accessed31.10.11).

[69] A. Vignaga, Metrics for Measuring ATL Model Transformations. Tech. Rep.,Universidad de Chile, 2009.

[70] M. Völter, From programming to modeling-and back again, IEEE Software 28(6) (2011) 20–25.

[71] M. Wimmer, A. Kusel, T. Reiter, W. Retschitzegger, W. Schwinger, G. Kappel,Lost in translation? Transformation nets to the rescue! in: Proceedings of the8th International Conference on Information Systems Technology and itsApplications, 2009, pp. 315–327.

[72] S. Winkler, J. Pilgrim, A survey of traceability in requirements engineering andmodel-driven development, Software Systems Modeling 9 (4) (2009) 529–565(Springer, Berlin/Heidelberg).

http://www.dcc.uchile.cl/TR/2007/TR_DCC-2007-001.pdf

Applying MDE to the (semi-)automatic development of model transformations

Documents

Transcript of Applying MDE to the (semi-)automatic development of model transformations