MeTAGeM-Trace: Improving trace generation in model transformation by leveraging the role of transformation models

Science of Computer Programming 98 (2015) 3–27

Contents lists available at ScienceDirect

Science of Computer Programming www.elsevier.com/locate/scico

MeTAGeM-Trace: Improving trace generation in model transformation by leveraging the role of transformation models Álvaro Jiménez, Juan M. Vara ∗ , Verónica A. Bollati, Esperanza Marcos Kybele Research Group, University Rey Juan Carlos, 28933 Madrid, Spain

a r t i c l e

i n f o

Article history: Received 1 November 2012 Received in revised form 5 September 2014 Accepted 9 September 2014 Available online 16 September 2014 Keywords: Model-driven engineering Traceability Model transformation

a b s t r a c t In the context of Model-Driven Engineering (MDE), generation of traces can be automated using the implicit traceability relationships contained in any model transformation. Besides, if transformations are developed adopting a Model-Driven Engineering (MDE) approach, i.e. promoting the role of models and the level of automation, model transformation will benefit from the promised advantages of MDE in terms of less costly software development while reducing the inherent complexity of coding model transformations. To put these ideas into practice, this work introduces MeTAGeM-Trace, the first prototype of an EMF-based toolkit for the MDD of model-to-model transformations which supports trace generation, i.e. it allows developing model transformations that produce not only the corresponding target models, but also a trace model between the elements of the source and target models involved in the transformation. © 2014 Elsevier B.V. All rights reserved.

1. Introduction The management of traceability in software development projects implies keeping track of the relationships between the different software artifacts produced along the process. This way, appropriate management of traceability helps to monitor the evolution of system components and can be used in a wide range of activities related to software development, most of which deal with software maintenance, such as change impact assessment, regression testing, requirements validation or coverage analysis [55,45]. Even software life cycle processes standards, such as ISO-12207, recognize traceability management as a mandatory task. Unfortunately, generating and maintaining links among different software artifacts is a tedious, time-consuming and error prone task if no tooling support is provided to that end [34]. In this sense, the advent of the Model-Driven Engineering (MDE) paradigm, which principles are to enhance the role of models and to increase the level of automation all along the development process [44], provides a new landscape that can positively influence the management of traceability [42]. Indeed, MDE brings new scenarios where appropriate management of traceability is almost mandatory, such as model synchronization or incremental model changes [46]. The key to foster automation in MDE projects is usually a set of model transformations that connect the different models involved in the proposal [5]. Simply put, a model transformation defines a set of relationships between the elements of source and target metamodels that must hold between the elements of the models conforming to such metamodels [47]. Therefore, a model transformation contains implicit information from which trace-links (traces) can be derived. Actually,

*

Corresponding author.

http://dx.doi.org/10.1016/j.scico.2014.09.003 0167-6423/© 2014 Elsevier B.V. All rights reserved.

4

Á. Jiménez et al. / Science of Computer Programming 98 (2015) 3–27

such links can be seen as instances of the relationships defined at metamodel-level. Therefore, if we made explicit this information in the model transformation itself, it could generate, apart from the corresponding target models, an extra model which contains the traces between the elements of the models involved in the transformation. In addition, the trace links generated could be collected in trace models that can be subsequently processed by means of MDE techniques, such as model transformation, model matching or model merging [4]. Despite there exist some model transformation languages that take advantage from this promising scenario [8,30,56], some of the most widely adopted, such as ATL [25], ETL [29] or RubyTL [10] do not support the production of trace models, even though they undoubtedly use some kind of transient traceability model during the execution of the transformation. This is probably due to the fact that coding model transformations, which is an inherently complex task, becomes even more complex if they have to deal with traceability. One possible solution to this scenario would be the refining of each transformation engine to inject trace generation capabilities. For instance Yie and Wageelaar presented in [58] an extension of the ATL Virtual Machine (ATL-VM) to that end. Nevertheless, this approach entails the development of a set of complex and language-specific solutions. This work aims at providing an alternative approach by raising the level of abstraction at which transformations are conceived and developed in order to provide a language-agnostic solution to this issue. To that end, this work presents MeTAGeM-Trace, a toolkit for semi-automatic development of model-to-model transformations which include traces generation. This way, apart from automating the production of traces from the execution of model transformations, MeTAGeMTrace benefits from the idea of transformation models to address one of the main issues hampering the adoption of MDE: the absence of systematic approaches for the development of model transformations [46]. The underlying idea is to start from a high-level specification of the model transformation that is subsequently refined into lower-level transformation models until they can be used to generate the source code that implements the transformation. When executed, such transformation will produce not only the corresponding target models but also a trace model between the elements of the models implied in the transformation. To that end, MeTAGeM-Trace implements a ModelDriven Development (MDD) process for model transformations atop of the Eclipse Modeling Framework (EMF) [19], the most adopted metamodelling frameworks to deploy model-based proposals. The rest of this paper is structured as follows: Section 2 introduces the methodological proposal of MeTAGeM-Trace while the tooling support, main focus of this paper, is presented in Section 3. Its use is illustrated in Section 4 by means of a simple case study. Section 6 reviews existing works in the area and Section 7 discuss current limitations and threats to validity of the proposal. Finally, Section 8 concludes by summarizing the main contributions and providing directions for further work. Furthermore, Appendix A provides user documentation in the form of installation instructions, user manual and pointers to other available examples. 2. MDD of model transformations including traces generation The aim of this section is to present the methodological basis of MeTAGeM-Trace by introducing the MDD for model transformations that it supports. Since MDE technologies have increased their maturity level [54], model-based proposals have started to involve more complex metamodels, thus, more complex model transformations. Model transformations coding is a complex task by nature [20] that might get even more complex if they need to deal also with traces generation. To alleviate this issue, we advocate in favor of applying MDE principles to the development of model transformations which support traces generation, i.e. modeling transformations [6] which include traceability information at different abstraction levels and automating the transition between these levels by means of model transformations. Proceeding this way, an additional advantage might be obtained: the process proposed is independent of the targeted model transformation language. As a consequence, (semi-)automatic migration between different model transformation languages of the same family could be supported in the medium-term. Probably the most representative example of the successful adoption of layered-trace enabled architectures to date are the different works around the application of the horseshoe reengineering model that drives the Architecture-Driven Modernization (ADM) forward (see [41] for instance). The distinction between levels of abstractions to separate the problem and the solution domain was indeed set as one of the main principles of MDE from its origins, whereas the use and development of MDE technologies have later revealed the need for model synchronization facilities (for which tracing is a must) as one of the key issues that MDE must address to enhance its level of adoption [13,46]. MeTAGeM-Trace aims therefore at improving existing tooling for the development of model transformations by supporting a layered-MDD process which yields trace-enabled model transformations. The MDD process proposed by MeTAGeM-Trace extends the one defined by MeTAGeM [7], a precursor of MeTAGeMTrace which supports the MDD of model-to-model transformations without considering traceability management. As shown in Fig. 1(a), it is based on the modeling of the model transformation at different abstraction levels. In particular, apart from those identified in the MDA proposal [37], namely PIM and PSM (Platform-Independent and Platform-Specific Model), it considers an additional abstraction level, so-called PDM (Platform-Dependent Model) which can be viewed as a specialization of the PSM level. The right-hand side of the picture (Fig. 1(b)) shows the instantiation of this process for a simplistic scenario (Square2Cube) where the aim is to map squares into cubes.

Á. Jiménez et al. / Science of Computer Programming 98 (2015) 3–27

5

Fig. 1. (a) Generic MeTAGeM-Trace process and (b) MeTAGeM-Trace process instantiated for the Square2Cube scenario.

First, the developer defines a set of relationships between the elements of the source and target metamodels. These relationships are collected in the PIM transformation model. Note that they are defined without considering the model transformation language targeted. Regarding the development of the Square2Cube transformation, the PIM transformation model states that there is a relationship between the square and cube metaclasses. This model is consumed by a model transformation (PIM2PSM) that produces a new model which maps high-level relationships onto mapping rules in terms of a particular approach for model transformation development, namely imperative, declarative, hybrid, graph-oriented, etc. [12]. Moreover, the traceability relationships that were implicit in the PIM transformation model become explicit at PSM level. Returning to the motivating scenario, the relationship that was defined between squares and cubes gives rise to a transformation relationship plus a traceability relationship. See Fig. 1(b) – PSM box. The PSM2PDM model transformation then consumes the previous platform-specific transformation model in order to produce a platform-dependent transformation model, i.e. a model that expresses the mapping rules and the traceability relationships in terms of a particular transformation language. Note that such language must follow the programming paradigm selected at the previous level. For instance, if the hybrid approach was chosen at PSM level, then the PDM must be described in terms of a hybrid language such as ATL [25], ETL [29] or RubyTL [10]. In particular, the PDM transformation model for the Square2Cube transformation contains a mapping rule with which to map square objects onto cube objects plus a trace creation rule. The latter creates trace objects that connect the elements involved in the former. Finally, a model-to-text transformation (PDM2Code) serializes the previous transformation model into the working-code that implements the modeled transformation. When this generated transformation is executed, it produces not only the corresponding target models, but also a trace model between the elements of the source and target models. Note that the rules for the creation of traces (not the traces themselves) are explicitly included both in the platformspecific and platform-dependent transformation models, since they are automatically derived from the high-level relationships collected in the PIM. An alternative approach would be to omit these constructions in all the transformation models generated along the process. The PDM2Code should take charge then of adding trace generation capabilities in the source code that implements the modeled transformation. However, this implies that too much logic would be encoded in the PDM2Code transformation. By contrary, we advocate in favor of modeling any artifact subject to model. This goes in favor of future maintenance,

6

Á. Jiménez et al. / Science of Computer Programming 98 (2015) 3–27

Fig. 2. Conceptual architecture of MeTAGeM-Trace toolkit.

eases automatic (by means of model-based techniques) or manual refining, improves interoperability, etc. For instance, the developer might delete the objects used to model a particular trace creation rule to prevent the produced transformation from generating a particular set of traces. 3. MeTAGeM-Trace in action The MeTAGeM-Trace toolkit has been developed to provide a proof of concept for the MDD process proposed in the previous section. It is an EMF-based toolkit [19] that supports the MDD of model-to-model transformations including traces generation [23]. To that end it bundles a set of Domain-Specific Languages (DSLs) [36] for modeling model transformations at different levels of abstraction (PIM, PSM and PDM) and a set of model-to-model (m2m) and model-to-text (m2t) transformations. While the m2m transformations serve to subsequently refine high-level transformation models into those of a lower level ones, the m2t transformations serve to serialize them into working-code. In particular, the MeTAGeM-Trace toolkit supports the development of ATL and ETL transformations. Supporting the whole spectrum of programming styles for model transformation development was too ambitious since the aim was just at showing that the proposal can be efficiently put into practice. Therefore, the hybrid approach was selected as targeted style since it was found to be the most commonly adopted by existing model transformation languages [12]. Among the existing hybrid languages, ATL was selected because of being commonly acknowledged as standard de-facto for model transformation development [1]. On the other hand, to prove that MeTAGeM-Trace could generate model transformations for different languages, it was necessary to show the application of the proposal for at least one other model transformation language. Since another (EMF-based) metamodel-based language was not found, we opted to target ETL. The fact that it is well documented – e.g. [29] provides a partial specification of its abstract syntax – eased the task of defining its underlying metamodel. All this given, an overview of the conceptual architecture of the MeTAGeM-Trace toolkit is shown in Fig. 2. Note that it bundles a DSL with which to model transformations at platform-independent level (MeTAGeMDSL); a DSL to model transformations at platform-specific level according to the hybrid approach (HybridDSL); and finally a pair of DSLs to model ATL and ETL model transformations (ATLDSL and ETLDSL). It also bundles several m2m (Metagem2Hybrid, Hybrid2ETL and Hybrid2ATL,) and m2t (ETL2Code ATL2Code) transformations in order to bridge these DSLs and to (semi-)automate the different steps of the process. The level of automation achieved depends on the nature of each particular transformation since MeTAGeM-Trace is not able to generate fully executable transformations: some manual refinements are always needed over generated transformations. For instance, for the five transformations published in the MeTAGeM-Trace Web site (see Section A.3) the percentage of refined code ranged from 3.4% to 12.98% whereas the amount of code that had to be added from scratch ranged from 0.78% to 3.76%. The refinements and additions needed were mainly related to the body of auxiliary functions since MeTAGeM-Trace fills them with comments. It is the developer who should use such comments/indicators to code the body of the function in terms of the targeted model transformation language. The more operations the transformation contains, the more refining it will therefore be necessary to make over the generated transformation. Another issue is that MeTAGeM-Trace leans on the type of a given variable to generate its identifier. Variables of the same type in a rule are therefore given the same name, so

Á. Jiménez et al. / Science of Computer Programming 98 (2015) 3–27

7

Fig. 3. Development process of MeTAGeM-Trace.

the developer has to manually update both these identifiers and any reference to them all along the transformation. Note that this task could be automated by means of a Higher-Order Transformation [50]. As an aside, regarding the comparison with hand-crafted code, our experiments have served to show that, according to the metrics proposed by van Amstel and van den Brand [51] the understandability of the code generated by MeTAGeMTrace is lower than that of the equivalent transformations. This is mainly due to the fact that enriching the transformation with trace generation capabilities entails the use of imperative code, function calls, etc. which contribute to raise the complexity of the transformation developed. 3.1. Building an EMF-based toolkit In order to develop the MeTAGeM-Trace toolkit, an adaptation of the process proposed in [52] for the development of EMF-based toolkits was followed. Fig. 3 provides an overview of this process. The process begins with the specification of (a first draft of) the abstract syntax of each of the DSLs that will be bundled in the tool. To that end, its metamodel is described in terms of the Ecore metamodeling language [19,48] (step 1). Note that the one for ATL was not defined since it is already bundled in the ATL IDE [25]. In order to provide the DSLs with a concrete syntax, EMF is then used to generate a fully functional tree-like editor to handle models conforming to each metamodel (step 2). Nevertheless, the generic nature of such editors does not always fit with the specific nature of a given DSL. Thus, the third step of the process is to create ad-hoc editors to fit the nature of their targeted domain. In particular, during the development of MeTAGeM-Trace, we built a set of multipanel editors that fit better with the relational nature of transformation and trace models (Fig. 4). They allow representing at the same time the different source and target models plus the relations model. At this point of the development process, there exist isolated versions of all the DSLs to bundled in the toolkit. The next step is to connect them by means of a set of m2m transformations, Hybrid2ATL and Hybrid2ETL (step 4). ATL was used to implement such transformations. MeTAGeM-Trace also bundles two DSLs whose purpose is to define low-level transformation models that are to be used as source for code generation (namely ETLDSL and ATLDSL). The programs used to support this code generation steps were therefore developed next (step 5). Again, note that the program for ATL was not developed as part of MeTAGeM-Trace since the ATL IDE already bundles a model injector-extractor. A MOFScript [38] m2t transformation was therefore developed to support the serialization of ETL transformation models into ETL working-code. As mentioned above, the metamodel that constitutes each given DSL might serve to specify its abstract syntax but on many occasions this is not always sufficient to attain a precise and rigorous specification [52]. In the context of MeTAGeMTrace, like any other MDD process, identifying which models are valid becomes crucial since the process implies the execution of different model transformations and these transformations were developed by assuming that only models would be consumed. Hence, the next step of the development process was to develop a set of model checkers using the Epsilon Validation Language (EVL) [28], a language which extends the capabilities of the OCL for validation purposes (step 6). Finally, an integration plug-in is built in order to collect and integrate all the software assets developed at this point, mainly metamodels, editors, transformations, code generators and model checkers. This plug-in provides a common user

8

Á. Jiménez et al. / Science of Computer Programming 98 (2015) 3–27

Fig. 4. Multipanel editor for trace models.

Fig. 5. Architecture of MeTAGeM-Trace toolkit.

interface, including different controls such as pop-up menus, launchers or wizards to set-up the execution of the model transformations bundled in the tool. The result is an integrated framework that can be downloaded as a unique Eclipse plug-in.1 This development process results in the layered architecture depicted in Fig. 5 which summarizes the main dependencies of MeTAGeM-Trace according to the convention widely adopted by Eclipse developers to represent the architecture of their proposals. DSLs are mainly developed atop of EMF while some minor refinements coded with the aid of JFace and SWT to obtain the desired functionality from multi-panel editors. Such DSLs are connected by means of model-to-model transformations coded with ATL and serialized into source code (if needed) with MOFScript. Finally, the Epsilon Validation Language is used to implement additional constraints that the models developed with each DSL bundles in the tool must satisfy. For the sake of simplicity, this work will not go into detail about the specifications of the DSLs and the model transformations that compose MeTAGeM-Trace. On the contrary, the following sections are focused on showing the functionality delivered by the toolkit and some insights on its operation. Interested reader is however referred to [23] for thorough explanations on such artifacts. 4. Case study This section illustrates the use of the MeTAGeM-Trace toolkit for the MDD of model-to-model transformations that support traces generation by presenting its application to a simple and well-known case study: the development of the

1

http://www.kybele.etsii.urjc.es/MeTAGem-Trace.

Á. Jiménez et al. / Science of Computer Programming 98 (2015) 3–27

9

Fig. 6. Families2Persons MetagemT transformation model: Father_2_Male One-To-One relationship.

(Families2Persons2 ) transformation for ATL. Note that Appendix A includes a user manual detailing each step of the case study that follows, including also the development of the (Families2Persons) ETL transformation. We have opted for using such scenario in order to avoid accidental complexity. However, for those interested in showing the application of the proposal to more complex scenarios, complete examples are available to download at the above mentioned Web site. For instance, they include a project in which MeTAGeM-Trace is used to develop an ATL model transformation to map UML conceptual data models into XML Schema models and another one which handles several aspects of two telephony DSLs: SPL and CPL.3 The process starts by defining a MeTAGeM model (PIM), where the developer defines high-level relationships between the elements of source and target metamodels. In this case, the relationships between the elements of Families and Persons metamodels are specified putting the emphasis in their cardinalities (One-To-One, One-To-Many, ZeroTo-One, etc.). For instance, Fig. 6 shows the Father_2_male relationship that corresponds to the definition of a One-To-One relationship between the Father element of the Families metamodel and the Male element of the Persons metamodel. To define such relationship, the user only had to drag and drop the source and target elements into a newly created One-To-One relationship object. It is worth mentioning that relationships can be established also at attribute level (e.g. firstName_To_fullName). Next step of the process is to generate an Hybrid model (PSM) by executing the MeTaGeM2Hybrid transformation bundled in MeTAGeM-Trace using the MeTAGeM model just created as input. In the hybrid transformation model obtained, transformation rules are described in terms of the hybrid approach and traceability relationships become explicit. It is worth noting that model validation is implicitly performed before the transformation is run to avoid raising non-controlled exceptions. Back to the case study, Fig. 7 shows that the Mother_2_Female transformation rule owns a trace rule object which describes the traceability relationship between Mother and Female objects. Recall that this generated model can be refined manually by adding, modifying or removing objects. In this case, the getFatherName() operation has been added, including the code that implements this operation, to compute the value for the Persons!Person.fullName property when the type of the source object is Families!Father. The hybrid model is then used as input to generate a transformation model that conforms to the ATL (respectively ETL) metamodel. So, the platform-specific transformation rules are mapped into the different types of rules supported by the ATL language (the machinery of the Hybrid2ATL and Hybrid2ETL transformations encode the logics of these mappings). Again, the corresponding model-checker is implicitly invoked before running the transformation. Fig. 8(a) shows an excerpt of the transformation model produced, where the hybrid transformation rule Mother_2_Female has been mapped into a matched rule. Moreover, since the ATL metamodel does not support the modeling of traceability elements, trace rule objects are mapped into elements of the target pattern of the ATL rules. Finally, the ATL transformation model is serialized into the ATL code that implements the modeled transformation. For instance, Fig. 8(b) shows the source code of the ATL rule Mother_2_Female. Note the extra-load of machinery needed to support the generation of traces. This fact serves to back the convenience of raising the level of automation in the development of model transformations to support traces generation. Otherwise, vast amounts of similar code should be replicated all along the transformation.

2 3

http://www.eclipse.org/m2m/atl/basicExamples Patterns/. http://www.eclipse.org/atl/usecases/DSLsTelephony/.

10

Á. Jiménez et al. / Science of Computer Programming 98 (2015) 3–27

Fig. 7. Families2Persons Hybrid model.

Fig. 8. Excerpts from the (a) Families2Persons ATL Transformation model and (b) ATL transformation.

However, it is worth noting that the developer is not completely free of coding tasks when using MeTAGeM-Trace. In our experiments, we have found that some imperative constructions have to be manually added in auxiliary functions. However, a huge amount of the source code is automatically generated. Not only the most repetitive and error-prone parts, one of the promised advantages of MDE [44], but also most of the pattern-matching parts, the heart of any model transformation [47]. Once the source-code has been refined (if needed), the execution of the transformation consuming a Families model generates a Person model plus a model which contains the traces between these models. Fig. 9 shows the trace model generated when running the ATL Families2Persons transformation developed with MeTAGeM-Trace. In particular, it focuses on the trace-link between the Marge Mother object (source model) and the MargeSimpson Mother object (target model). This trace-link is directly derived from the Mother_2_Female high-level relationship that was defined in the MeTAGeM model. 5. Rapid assessment Even though a rigorous of the proposal is out of the scope of this paper, whose main objective was to present the tool, this section provides a minimal assessment of the advantages brought by MeTAGeM-Trace. To that end, we summarize some results gathered from an experiment in which model transformations were developed with and without MeTAGeM-Trace. In particular, the following transformations were considered:

Á. Jiménez et al. / Science of Computer Programming 98 (2015) 3–27

11

Fig. 9. Families2Persons trace model.

Table 1 Development times (seconds) with and without MeTAGeM-Trace.

Families2Person

HsD

MsD

1080 812

2165 1282

3520 2356

4781 3536

MeTAGeM-Trace

5200 3278

8231 5633

% Automated vs. Manual

69%

67%

Manual

MeTAGeM-Trace Class2Relational

Manual

MeTAGeM-Trace UML2XMLSchema

Manual

• The afore mentioned Families2Person transformation found on the ATL Web site, which contains 46 Lines of Code (LOC).

• The well known Class2Relational transformation found on the ATL Web site, which contains 114 LOC. • The UML2XMLSchema transformation, one of the transformations bundled in M2DAT-DB, a toolkit for the development of modern database schemas [52]. It maps conceptual data models, represented with a UML class diagram, onto XML Schemas (460 LOC). The M2DAT-DB toolkit can be downloaded from its Web site.4 Besides, since MeTAGeM-trace aims at reducing the inherent complexity of model transformation development, independently of developers’ expertise, the case studies were therefore conducted with two different groups of developers:

• Highly skilled developers (HSd), who had more than 6 months of experience in model transformation development. In particular this group comprised five PhD students whose research focus is 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 group included 12 MSc students who had attended seminars on MDE, EMF and ATL in the context of a course which included a set of assignments on DSLs and model transformations development. Table 1 summarizes the data related to the time (seconds) devoted to the development of each transformation with and without MeTAGeM-Trace. For each case study, first column shows the time needed by HSd and MSd developers. In both cases this times includes the time devoted to model the transformation plus that needed to refine the source-code generated. According to the data summarized in the last row, the development of transformations using MeTAGeM-Trace takes on average less than 70% of the time needed for manual development. However, note that such transformations already bundle the machinery to support traces generation, what would imply a considerable amount of manual (and repetitive) coding to add imperative constructions all along the transformation. To conclude, it is worth noting that this is by no means a complete and proper validation for MeTAGeM-Trace but just a rapid assessment to provide a intuition of the results yielded by a more rigorous study in presence of more com-

4

http://m2datdb.wordpress.com/.

12

Á. Jiménez et al. / Science of Computer Programming 98 (2015) 3–27

plex transformations. As a matter of fact, our experiments have revealed that the more complex the transformation is, the greater the improvement in terms of development time obtained when MeTAGeM-Trace is used. Actually, shortening development times is not the main advantage brought by MeTAGeM-Trace. Apart from enabling the production of traces, MeTAGeM-Trace implements a methodological proposal in which interim transformation models can be recovered, refined and reused at any time. Besides, semi-automatic migration, debugging and even reverse engineering of model transformations are current or potential applications of MeTAGeM-Trace. Some of these advantages are later introduced in more detail in Section 7. 6. Related work As Fig. 1 shows, our proposal combines two main ideas: model-driven development of model transformations and trace generation. Although there exists some proposals focused on the MDD of model-to-model transformations and some others which use transformations to generate traces, no proposal combining both ideas has been found. Moreover, many of these works do not provide any type of implementation. Therefore, in the following we provide an overview of related works grouped into two main categories: model transformations development and traces generation. This review is mainly extracted from that previously performed in [42] whose main objective was to analyze the state of the art in traceability management in the context of MDE. 6.1. Model transformations development The first group collects proposals focused on improving the development of model transformations, mostly by applying MDE techniques. These proposals argue in favor of using models to define high-level specifications of model transformations that are independent of any model transformation language. Such specifications are later translated into low-level specifications, directly executable or interpretable. Although the number of levels of abstraction considered is not the same for all the works in this group, all of them consider at least some kind of platform-independent and platform-dependent level. Regarding the transition between such levels of abstraction, Kusel [31] and Vignaga [53] already acknowledged that it was desirable to automate it, whereas Bézivin et al. [6] went a step further and point to model transformations as the way to do so. One of the most mature works in the application of MDE principles to the development of model transformations is the one from Guerra et al. [20]. It presents transML, a family of languages with which to consider the development of transformations from an engineering perspective. These languages offer support for the whole life-cycle, from requirements to implementation, including languages for the architectural design of transformations and the emphasis of validation tasks. In contrast to the current version of MeTAGeM-Trace, there exist just partial implementations of the different steps that should be accomplished in order to develop model transformations with transML. Regarding traceability management, the authors state that the proposal can be applied to languages offering implicit or explicit support for traces generation. As mentioned before, MeTAGeM [7], the seed of MeTAGeM-Trace falls also in this category of related works. Like the rest of them, MeTAGeM was focused in supporting the MDD of model transformations but it does not deal with traceability. Actually, MeTAGeM was needed as building block to develop MeTAGeM-Trace. After supporting the MDD of model transformations, we were ready to add traces generation capabilities to the framework. Finally, there is a number of works focused on the application of model-matching techniques [4] to automate the production of model transformations. Regarding MDE principles, Didonet Del Fabro and Valduriez [14] implements a cumulative weaving process based on the chaining of model transformations that produce refined version of matching models. As a result an ATL transformation model, which can be serialized into source-code, is obtained. Falleri et al. [16] use an adaptation of the Similarity Flooding algorithm to find the matching between two given metamodels expressed by graphs, though no implementation is provided. Besides, some works focused on schema translation could be also considered in this category since they support automatic development of model transformations. For instance, in [3] Atzeni et al. discusses a proposal for the implementation of the ModelGen operator, which translates schemas from one model to another, here schema must be read as metamodel in terms of MDE. Nevertheless, this last group of proposals are mainly intended to work with metamodels owning a high-level of similarity. 6.2. Traces generation This section provides a brief overview of previous works focused on the generation of traces in MDE contexts. In general, those works are based on the idea of using model transformations to support trace generation. Note that those proposals do not concern how the transformations were developed. In particular, they do not consider the application of MDE principles to the development of the transformation. As a result, each proposal uses to be specific to a particular model transformation language. First of all, those languages providing built-in support for trace generation should be considered. For instance, there are some implementations of the QVT standard [30], such as mediniQVT or QVTo,5 that allows generating a trace model

5

http://wiki.eclipse.org/QVTo.

Á. Jiménez et al. / Science of Computer Programming 98 (2015) 3–27

13

every time a transformation is executed. Some m2t transformation languages support also the generation of traces, like MOFScript of Acceleo, though the latter does not allow to persist the traces out of the development environment. Regarding languages supporting traces generation, special attention deserve the recent progresses made by Willink et al. under the umbrella of the QVT Declarative (QVTd) project6 towards the provision of reliable EMF-based implementations for QVT Relations (QVTr) and QVT Core (QVTc) [56]. To that end they adopt a progressive approach based on three intermediate languages. The idea is to translate a pure declarative specification in terms of QVTr or QVTc into an imperative unidirectional version of the transformation which can be executed atop of an OCL-based Virtual Machine. Tooling is already available for all these languages whereas the chain of model transformations connecting them is planned for future Eclipse Luna releases. The aim of MeTAGeM-Trace is by no means to replace QVTr or QVTc, but to provide with higher abstractions with which to assist in the development model transformations. In this sense, MeTAGeM-Trace could be integrated with this work in a number of ways since they work at different abstraction levels. Some of them, such as simply targeting QVTr for code generation purposes, are briefly introduced in the following section. On the other hand, most of the existing transformation engines maintain some kind of record to keep track of the relationships that hold between source and target objects. Nevertheless, they do not support the materialization of such record. In order to overcome this issue, the creator of ATL proposed in [24] to take advantage from MDE principles to add traces generation capabilities to ATL existing transformations. The idea is to extract transformation models from existing model transformations, enrich them with the machinery needed for traces generation and generate back an enriched model transformation. Note that the proposal works only for existing ATL model transformations. The proposal of Levendovszky et al. [32] wides the scope by supporting also model-to-code traces. However, the developer must specify explicitly which the traceability-links are at development time. This way, when the transformation is executed, such relationships are instantiated as trace links. There are some other works, such as those from Bondé et al. [33] and Oldevik and Neple [39], that makes explicit the implicit traceability relationships that exist in any model transformation but these proposals were devised for a specific transformation language/engine. Special attention deserves the proposal of Grammel, Kastenholz and Voigt [18], which lean on metamodel matching techniques to support the generation of traces without the need of executing a model transformation. Finally, two relevant works deserve special attention since they do not deal only with traces generation, but with model management in general. In [8] Boronat et al. present the support for traceability generation embedded in MOMENT, an EMF-based model management framework where model operators are defined at metamodel level to carry out different model management tasks. Trace models are automatically produced when executing such operators. In addition, they can be manually defined by the user. On the other hand, Guerra et al. [21] propose a pattern-based approach to define inter-model specifications, i.e. models defining how other models are related. Such specifications can be used in different MDE scenarios, such as model matching or model traceability. Regarding traceability, inter-model specifications can be used to check whether a trace model is valid according to such specification and update it accordingly or to produce trace models directly. The authors also present PAMOMO, an Eclipse tool support their proposal. 7. Discussion Since MeTAGeM-Trace is on-going work, the following sections discuss its main limitations and possible threats to validity. Some pointers for improvement are provided when appropriate. 7.1. Supporting different approaches for model transformation As it can be derived from reading the paper, current prototype of MeTAGeM-Trace supports only hybrid model transformation languages. The validity of the proposal for other approaches is therefore arguable. This paper has consequently acknowledged that the scope of the proposal is currently limited to hybrid model transformation languages. Nevertheless, this limitation should not hamper the adoption of MeTAGeM-Trace since the hybrid style is the most commonly adopted by existing model transformation languages [12,35]. In addition, most of the existing approaches are based on the definition of rules composed of source and target patterns and consider just the abstract syntax of the modeling languages to bridge [27]. We believe that any model transformation language fulfilling these premises could be abstracted in terms of the MeTAGeMDSL. More concretely, hybrid languages, for which the proposal has proven to work fine, are in essence declarative, what results in a manageable gap between the HybridDSL implemented in the current version of MeTAGeM-Trace and an hypothetical DeclarativeDSL. To fill this gap a Higher-Order Transformation (HOT) [50] should be developed to bridge the newly defined metamodel with the one already bundled in MeTAGeM-Trace. The same might apply for graph-based transformation languages, which adopt a rule-based approach similar to that of declarative languages.

6

http://wiki.eclipse.org/QVTd.

14

Á. Jiménez et al. / Science of Computer Programming 98 (2015) 3–27

Regarding imperative languages, the Zero-To-One and Zero-To-Many constructors of MeTAGeMDSL have proven to work fine to model the imperative blocks of the model transformations used so far for experimentation. However, a completely imperative transformation has not been developed with MeTAGeM-Trace. Whether the proposal could be used with imperative languages is much more arguable therefore. As a matter of fact, the complexity of bridging declarative and imperative model transformation languages was already acknowledged by Jouault and Kurtev in one of the first works that addressed the interoperability of model transformation languages [26]. The most immediate solution to address this issue would be the definition of a high-level imperative metamodel that again could be bridged with MeTAGeMDSL by means of a HOT. All this given, we are not sure about the convenience of using a similar approach to address the development of imperative transformations. Modeling such transformations would imply thinking on terms of programming blocks from the very first step of the development process. By contrast, with MeTAGeM-Trace we aimed at rising the level of abstraction at which developers should start working on the development of the transformation. This could be reasonable just when the transformation is thought in terms of relations that should hold between source and target models. Otherwise, we find that the act of modeling the transformation could result in too complex models akin to huge business process models or state machines. These might help for sure for debugging purposes but not for raising the level of abstraction at which transformations are thought of. Nevertheless, as we have already mentioned, most of the existing programming languages. 7.2. Ensuring consistency between transformation artifacts Current version of the proposal does not offer any mechanism to ensure that consistency is preserved between the different transformation models, nor between them and the source code that implements the modeled transformation. Any modification over the MeTAGeMDSL model entails regenerating the remaining artifacts (transformation models and source code). Manual refinements over any of the artifacts can therefore not be preserved. As a matter of fact, despite some significant efforts in the area [9,57] the provision of efficient model synchronization facilities is still one of the main issues for widespread adoption of model-based proposals [46]. In the context of MeTAGeM-Trace this issue could be addressed in different steps. First, addressing the development of the transformations needed in MeTAGeM-Trace to support reverse engineering of existing transformations. For the case of ETL these would be the Code2ETL and ETL2Hybrid transformations plus the Hybrid2Metagem transformation that will work to bridge any other hybrid language. Next, injecting traceability capabilities in all the transformations bundled in MeTAGeM-Trace following the enrichment approach introduced by Jouault et al. in [24] which we have extended later in [43]. Finally, the traces models generated by running the enriched transformations could be used to propagate the changes made to the modified artifact to the rest of artifacts, adapting the approach presented in [15] to that end. 7.3. Extending MeTAGeM Since previous section mentioned that MeTAGeM [7] has been used as building block for MeTAGeM-Trace one might wonder about the novelty of MeTAGeM-Trace. To sed light on this issue, this section highlights the main contributions of MeTAGeM-Trace with respect to MeTAGeM. Regarding the conceptual proposal, the 4-stage architecture for the development of model transformations was already proposed in MeTAGeM. The novelty here comes from the specification of the different DSLs and the transformations that connect them. All of them have been redefined in MeTAGeM-Trace in order to bring support for trace generation to the transformations produced. This implies adding new constructions to support the modeling of trace generation mechanisms and refining the transformations to cope with these newly added elements. Besides, two new DSLs have been defined from scratch: the one to elaborate trace models plus the one to support the modeling of ETL transformations (ETLDSL) since MeTAGeM considered only ATL and RubyTL transformations. Regarding the tooling, the previous contributions were correspondingly incorporated in the EMF-based toolkit. In this sense, despite the effort devoted to the construction of the DSLs, the development of the m2m transformations bundled in MeTAGeM-Trace was extremely challenging because of the mental abstractions handled. In particular, the PSM2PDM transformations were specially complex: apart from refining the previous HybridDSL transformation model, they are in charge of instantiating in the target transformation model the needed constructions to embed a traces generator in the transformation that will be produced when serializing the PDM transformation model. As an aside, the resulting DSLs and model transformations support also the development of N:M model transformations, which were not supported in MeTAGeM. 7.4. Advanced model transformation features

MeTAGeMDSL supports the conceptual modeling of transformations in terms of relationships that must hold between source and target models. Such relationships are later expressed in terms of a particular approach for model transformation development with the HybridDSL. The generic nature of these DSLs prevent the developer from considering advanced model transformation features, such as rules composition, incremental execution or package import, when modeling the

Á. Jiménez et al. / Science of Computer Programming 98 (2015) 3–27

15

transformation. However, they can be later incorporated in the PDM transformation model if the targeted language does support them. For instance, one might add a Library ref object to an ATL transformation model to specify that a given ATL file is to be imported. On the other hand, we dedicate special attention to bidirectionality [11] as a particularly advanced feature that a model transformation language could support. Despite bidirectional transformations would help to cope with issues like metamodel evolution and model co-evolution or reverse engineering, there is a lack of mature tooling support in the area [11,49]. As a matter of fact, even though the QVT-Relations specification [40] owns a bidirectional nature, the best approach towards providing a reliable implementation has turned to be shredding QVTr transformation into unidirectional transformations [56]. In some sense, we already pointed to this approach as the best way to support bidirectional transformations when we first presented MeTAGeM [7]. The underlying idea is that from the high-level specification of relationships between source and target metamodels collected in a MeTAGeMDSL transformation model, two complementary unidirectional transformations could be produced. Obviously, this entails a set of challenges, like reconciling the manual refinements to be done over each unidirectional transformation produced, but we believe that it could be an interesting direction for further work. 8. Conclusions and future work Given that model transformation is the wheel that moves MDE forward, it should be the place to inject traces generation capabilities in MDE projects. Unfortunately, model transformation development entails a huge amount of accidental complexity. Dealing with traces when coding model transformations increases such complexity. Nevertheless, being nothing but another software artifact, MDE principles can be applied to ease the development of model transformations. Combining these ideas, we have extended our previous work on MDD of model transformations [7] to introduce MeTAGeM-Trace, a framework for model-driven development of model-to-model transformations which support traces generation. The proposal is based in a simple an intuitive idea: to use the implicit traceability relationships hidden in any model transformation to identify and generate the trace links that should be produced when that transformation is executed. To provide tooling support for such approach, an EMF-based toolkit has been developed to support the MDD of ATL and ETL model transformations. To that end, it bundles a set of DSLs to model transformations at different abstraction levels. Such DSLs are connected by a number of model transformations that support subsequent refinements of high-level transformation models into lower-level transformation models until they can be translated into ATL or ETL source code. Running the generated transformation produces not only the corresponding target models, but also a trace model between the elements of source and target models. To the best of our knowledge MeTAGeM-Trace is the first tool supporting (semi-)automatic development of model transformations that include traces generation. Furthermore, the underlying proposal provides a systematic and repetitive way of addressing the development of model transformations, a need that recent works in the field has acknowledged [20,46]. However, it is worth noting that currently the tool targets just hybrid languages, though some pointers for future extension to other families of languages have been provided. Regarding directions for further work different than those discussed so far, this tool can be seen as a first step to improve the management of traceability in MDE projects. The aim of MeTAGeM-Trace is therefore to ease the provision of the raw data (trace-links) with which activities such as the debugging of model transformations [2], the proper propagation of information in transformation chains [17], or the analysis of metamodel change impact [22] can be carried out. The next task we plan to address is therefore the proper use of the information provided by running trace-enabled model transformations. In general, the lack of querying support hampers or inabilities the analysis of traceability information [42]. We are therefore working to provide mechanisms with which to analyze the low-level data collected in the trace models generated by transformations in order to produce high-level information that can be used to support decision making processes. Our first results in this area can be found in [43]. Acknowledgements This research was carried out in the framework of the MASAI (TIN-2011-22617) project, financed by the Spanish Ministry of Science and Innovation and the iTrace project (PRIN13-IYA15/2013/00190/001), financed by the University Rey Juan Carlos. Appendix A. User documentation This section provides the following documentation on MeTAGeM-Trace:

• Installation instructions. • A user manual showing each step of the process followed to develop the transformation used in Section 4. • A set of examples where MeTAGeM-Trace is used to address more complex transformation scenarios.

16

Á. Jiménez et al. / Science of Computer Programming 98 (2015) 3–27

A.1. Installation This section provides instructions on how to manually install and configure MeTAGeM-Trace:

• JVM Installation. JVM 1.6 was used during the development of MeTAGeM-Trace. So, equal or higher version is recommended.

• Eclipse and MeTAGeM-Trace installation. There are two options: – Download the MeTAGeM-Trace-Eclipse distribution.7 It bundles the Eclipse Modeling Tools distribution and the rest of plug-ins required by MeTAGeM-Trace. Extract the zip to a location on your local drive and run Eclipse. – To install Eclipse and MeTAGeM-Trace separately. In case Eclipse has not been previously installed, an Eclipse distribution must be downloaded from its Web site.8 Besides, MeTAGeM-Trace requires the following plug-ins: ∗ EMF 2.6 ∗ ATL 3.2 ∗ Epsilon 0.9 ∗ MOFScript 1.4.0.3 Once Eclipse and the afore-mentioned plug-ins have been installed on your local drive, MeTAGeM-Trace plug-ins9 must be downloaded and installed. To that end, extract the zip file in your Eclipse directory. A.2. User manual This manual shows how to use MeTAGeM-Trace to develop the Families2Persons10 transformation. This scenario is used in order to avoid adding accidental complexity. A number of more complex scenarios (apart from the one used here) can be downloaded from the afore-mentioned Web site. A.2.1. Set-up We are going to use the source files provided with the ATL Families2Persons basic example as source and target (meta)models. Therefore, following tasks must be completed before start the development of the transformation: 1. Download the source files of the ATL basic example11 to your local drive. Create a new project: File -> New -> General -> Project. 2. Import the project into your workspace: File -> Import -> Existing projects into workspace -> Select archive file (radio button) -> Finish. 3. Name the project as Families2persons. A.2.2. Defining the MeTAGeM transformation model The process starts by defining a MeTAGeMDSL model that collects (at metamodel level) the relationships that must hold between source and target models. MeTAGeM-Trace provides a wizard to collect the data needed for the creation of such model:

• File -> New -> Other -> MeTAGeM-Trace -> Metagem model. See Fig. 10(a). • Next, you have to set the source and target metamodels of the transformation (recall that several source and target metamodels are allowed).

• To that end, click the Add model button in order to give a (local) name and state which is the source file of each metamodel involved in the transformation. See Fig. 10(b) and (c).

• As a result, an empty Metagem model is created. See Fig. 11. As shown in the figure, the model is automatically opened in a multi-panel editor that bundles three different panels to show separately the source models, the high-level transformation metamodel (Metagem model) and the target metamodels. If there are several source or target metamodels, they are be co-located vertically in their corresponding panel. Next, the different relationships between source and target metamodels have to be explicitly defined in the model. To that end, right-click on the root object of the (Metagem) model (Model root) -> New child -> Select the type of relationship to create (Fig. 12). This time, we create a One-To-One relationship. Once the relationship object has been added, the source and target elements of such relationship has to be set. To that end, drag elements from source and target models and drop them on the transformation model. Note that the editor

7 8 9 10 11

http://www.kybele.es/members/ajimenez/thesis/software/Eclipse-MeTAGeM-Trace.zip. http://www.eclipse.org/downloads/. http://www.kybele.es/members/ajimenez/thesis/software/MeTAGeM-Trace-Plugins.zip. http://www.eclipse.org/m2m/atl/basicExamples_Patterns/. http://www.eclipse.org/m2m/atl/atlTransformations/Families2Persons/Families2Persons.zip.

Á. Jiménez et al. / Science of Computer Programming 98 (2015) 3–27

17

Fig. 10. Metagem model creation wizard.

Fig. 11. Empty Metagem model.

Fig. 12. Adding relationship objects to Metagem model.

automatically limits the number of elements that can be referenced by a given relationship depending on the nature of the relationship. For instance, after setting a source and target element in a One-To-One relationship, drag & drop functionality over such relationship object is automatically disabled. Alternatively, source and target elements can be added by means of right-click over the relationship object. Then, the properties view can be used to set the elements of source and target metamodels that should be referenced.

18

Á. Jiménez et al. / Science of Computer Programming 98 (2015) 3–27

Fig. 13. Setting the target element of a One-To-One relationship.

Fig. 14. Adding nested relationships to a Metagem model.

Back to the example, Fig. 13 shows that the source element has already been set (Families!Father) whereas Persons!Person is been set as the target object for the One-To-One relationship previously added. Likewise, nested relationships can be defined in order to relate the properties of source and target classes. For instance, Fig. 14 shows that the One-To-One relationship between Families!Male and Persons!Person contains another One-To-One relationship that binds their fistName and fullName properties Proceeding this way, the final Families2Persons Metagem model is shown in Fig. 15. A.2.3. Producing the Hybrid transformation model Next step of the process is to map the high-level specification of the transformation (Metagem transformation model) into a transformation model for the Hybrid approach:

• Right-click on the Metagem model in the project explorer. • Run As -> MeTAGeM->Hybrid. See Fig. 16(a). • Confirm or modify the suggested name and location for the Hybrid transformation model that will be produced. See Fig. 16(b).

Á. Jiménez et al. / Science of Computer Programming 98 (2015) 3–27

19

Fig. 15. Complete Families2Persons Metagem model.

Fig. 16. Running the MeTAGeM2Hybrid transformation.

Note that implicit model-checking is done before the MeTAGeM2Hybrid transformation is run. As a result, the Hybrid transformation model of Fig. 17 is obtained. Every relationship defined in the Metagem model has given rise to, at least, a (Mapping) Rule object and a Trace Rule object in the Hybrid model. Nevertheless, some refinement is frequently needed in order to add imperative constructions to the transformation (recall that we target the Hybrid approach). This use to take the form of auxiliary functions used to return some value after perform some computation. For instance, shows the creation of the getFatherName() operation for Family!Father objects.

• Right-click on the root element. • New Child -> Operation. See Fig. 18(a).

20

Á. Jiménez et al. / Science of Computer Programming 98 (2015) 3–27

Fig. 17. Families2Persons Hybrid transformation model.

Fig. 18. Adding getFatherName() operation to the Hybrid transformation model.

• Set the name, the return type and the context (object type for which the operation will work) of the operation. See Fig. 18(b). • You might set the body of the operation as well using the properties view. See Fig. 18(c). • Finally, if needed, arguments can also be defined. See Fig. 18(d). Some bindings might need also refining. If the binding is immediate, e.g. a <- b there is no need to worry. It could be set directly in the Metagem model. However, if the binding is not immediate, i.e. some computation is needed before assigning the value, it has to be manually modeled in the Hybrid transformation model (note that this refinement could be delayed and done over the ATL or ETL model that will be later generated).

Á. Jiménez et al. / Science of Computer Programming 98 (2015) 3–27

21

Fig. 19. Setting the RightPattern of a binding to the value returned by the getFatherName() operation.

Fig. 20. Refining multiple source bindings: setting the value of the belongsTo reference.

Back to the example, the value of the Persons!Person.firstName property is returned by the getFatherName() operation previously defined. Therefore, it has to be explicitly modeled. This is shown in Fig. 19.

• • • •

The Father_2_Male contains a binding object to set the value of the Person.firstName property. Hence, the LeftPattern of such binding points to the Person.firstName property. What rests is to set the RightPattern of the binding to point to the getFatherName() operation. This way, once the transformation is run, the value returned by the operation will be assigned to the property.

Another type of binding that needs refinement is the one that entails two or more source elements. Note that a binding is always related to just one target element since it is defined to set the value for such object. However, several source objects might be needed to compute such value. For instance, let suppose that we are not using an operation to get the value for the Persons!Person.fullName property.

• Such value is obtained from concatenating the value of the Families!Member.firstName property and the Families!Member.lastName property. • Therefore, the binding object that sets the value for the Persons!Person.fullName property has to reference the two mentioned source properties.

• The belongsTo reference of the objects representing such properties in the transformation model has to be manually set to the corresponding objects.

• The result is shown in Fig. 20. It is worth noting that the belongsTo reference is automatically resolved when the binding references to just one source object. As shown before, the Hybrid transformation model considers the modeling of two types of traceability relationships. TraceRule objects represent traces that will be derived from the execution of a mapping rule (a kind of top-level trace) whereas TraceBinding objects represent the traces that will be generated by the execution of a binding. These objects

22

Á. Jiménez et al. / Science of Computer Programming 98 (2015) 3–27

Fig. 21. Creating a TraceRule object.

are automatically generated from the Metagem transformation model. However, the user may be interested in defining new traceability relationships. To that end, you should proceed as follows.

• First of all, a new Rule object has to be added since the existing ones were produced by the Metagem2Hybrid • • • •

transformation. So they already contain a TraceRule object and the tool does not allow to create more TraceRule objects inside them. Note that this is the right behavior since traces can be n-ary. Right-click on the root element -> New Child -> Rule. See Fig. 21(a). Set the source and target elements of the rule (e.g. Families!Member and Persons!Person). See Fig. 21(b). Right-click on the root element -> New Child -> TraceRule. See Fig. 21(c). Optionally, set the name of the TraceRule object. Note that the tool set automatically its source and target elements by looking at the containing Rule. See Fig. 21(e).

TraceBinding objects are created similarly. The main difference is that the user must specify to which binding does the TraceBinding belong to since a rule usually contains several bindings. A.2.4. Producing the ATL/ETL transformation model Next step of the MDD development of model transformations supported by MeTAGeM-Trace consists of mapping the Hybrid transformation model into an ATL or ETL transformation model, depending on the targeted language. To that end, MeTAGeM-Trace bundles a pair of launchers

• • • •

Right-click on the Hybrid transformation model and select the targeted language. See Fig. 22. Confirm or modify the suggested name and location for the ATL/ETL transformation model that will be produced. The corresponding ATL or ETL transformation model is automatically obtained. See Fig. 22(a) and (b) respectively. As it happened with the Metagem2Hibrid transformation, model checking is implicitly invoked before the selected transformation (either Hybrid2ATL or Hybrid2ETL) is executed.

A.2.5. Generating the source-code Last step of the process is to obtain the source-code that implements the modeled transformation. To that end, MeTAGeM-Trace we should proceed as with the previous automated steps:

• Right-click on the ATL/ETL transformation model. • Select the targeted language, either ATL or ETL (see Fig. 23): – Extract ATL model to ATL file (MeTAGeM-Trace). – Extract ETL model to ETL file (MeTAGeM-Trace). Note that the source-code generated will probably need from manual refinement. As mentioned before, code for model navigation is usually needed, as well as some re-naming of variables. Nevertheless, we have empirically assessed that more than 80% of the source-code of the transformation is generated by MeTAGeM-Trace, improving drastically development times. In this sense, it is worth noting that MeTAGeM-Trace is oriented to help model transformation developers, i.e. it is

Á. Jiménez et al. / Science of Computer Programming 98 (2015) 3–27

23

Fig. 22. Running the (a) Hybrid2ATL and (b) Hybrid2ETL transformations.

Fig. 23. Generating ATL (a) or ETL (b) source-code.

not a tool intended for novice developers although we have discovered that it contributes to reduce the learning curve of model transformation development. A.2.6. Generating trace models Recall that apart from providing a tool to develop model transformations, the main advantage of MeTAGeM-Trace is that produced transformations are be able to generate, not only the corresponding target models, but also a trace model. Therefore, the last section of this manual is devoted to show such functionality in action by running the Families2Persons transformation. Note that running the transformation is an issue related with the corresponding targeted language. You can look the corresponding manual for more information on how to run ATL and ETL transformations. The only difference is that the transformation will produce an “extra” model in this case.

• Right-click over the source file of the transformation (either ATL or ETL, though we will focus on the ATL one here).

24

Á. Jiménez et al. / Science of Computer Programming 98 (2015) 3–27

Fig. 24. Running the ATL transformation.

• Run-as -> Run configurations • Select the source, target and trace models metamodels. See Fig. 24: note that the Traces metamodel is already available in the EMF registry.

• Run the transformation using the above-described configuration. As a result, apart from the target model, a trace model like the one shown in Fig. 25 is generated. If you open the model with the multi-panel editor bundled in MeTAGeM-Trace you will notice that:

• When a trace-link object is selected in the trace model, corresponding source and target objects are automatically highlighted in the left and right panel. For instance, the picture shows that the Mother_2_Female trace link has been selected. Consequently, the source and target objects referenced by such trace (Marge and MargeSimpson) are automatically highlighted, automatically highlighted in the corresponding models.

• Likewise, if a source or target object is selected in the left or right panel, the trace links referencing it are automatically highlighted in the central panel. A.3. Examples In order to reduce or eliminate accidental complexity, this manual is based on a simple case study. However, the following examples can be found in the MeTAGeM-Trace Web site.12 They show the use of MeTAGeM-Trace in different scenarios. Just download them to your local folder and import the projects to your Eclipse’s workspace with File -> Import -> Existing projects into workspace:

• Families2Person: the Families2Persons transformation is one of the learning examples provided in the ATL Web site.13 12 13

http://www.kybele.etsii.urjc.es/metagem-trace/. http://www.eclipse.org/m2m/atl/atlTransformations/.

Á. Jiménez et al. / Science of Computer Programming 98 (2015) 3–27

25

Fig. 25. Families2Persons trace model.

• Class2Relational: the class to relational transformation [6] is a simple yet complete scenario that has been traditionally used as case study to present new approaches or languages for the development of model transformations. The original version can be downloaded from the ATL Web site. • KM32XML: the KM32XML transformation maps KM3 models onto XML models. The original transformation can be downloaded also from the ATL Web site. • UML2XMLSchema: the UML2XMLSchema transformation is one of the transformations bundled in M2DAT-DB, a tool for the development of modern database schemas [52]. It maps conceptual data models, represented by a UML class diagram, into XML Schema models. The tool can be downloaded from its Web site.14 • CPL2SPL: the CPL2SPL transformation is part of the DSLs coordination for Telephony ATL Use Cases provided in the ATL Web site.15 According to ATL authors, this Use Case is a relatively complex example which handles several aspects of two telephony DSLs: SPL and CPL. Appendix B. Supplementary material Supplementary material related to this article can be found online at http://dx.doi.org/10.1016/j.scico.2014.09.003. References [1] M. Amstel, C. Lange, M. Brand, Using metrics for assessing the quality of ASF + SDF model transformations, in: Proceedings of the 2nd International Conference on Theory and Practice of Model Transformations, Springer-Verlag, 2009, pp. 239–248. [2] V. Aranega, J.-M. Mottu, A. Etien, J.-L. Dekeyser, Using trace to situate errors in model transformations, in: Software and Data Technologies, Springer, 2011, pp. 137–149. [3] P. Atzeni, P. Cappellari, R. Torlone, P. Bernstein, G. Gianforme, Model-independent schema translation, VLDB J. 17 (6) (2008) 1347–1370. [4] P.A. Bernstein, S. Melnik, Model management 2.0: manipulating richer mappings, in: Proceedings of the 2007 ACM SIGMOD International Conference on Management of Data, SIGMOD ’07, ACM, New York, NY, USA, 2007, pp. 1–12. [5] J. Bézivin, In search of a basic principle for model driven engineering, Upgrade V (2) (2004) 21–24. [6] J. Bézivin, F. Buttner, M. Gogolla, F. Jouault, I. Kurtev, A. Lindow, Model transformations? Transformation models!, in: Model Driven Engineering Languages and Systems, in: Lect. Notes Comput. Sci., vol. 4199, Springer, Berlin/Heidelberg, 2006, pp. 440–453.

14 15

http://www.kybele.etsii.urjc.es/kyb_m2datdb/. http://www.eclipse.org/atl/atlTransformations/#CPL2SPL.

26

Á. Jiménez et al. / Science of Computer Programming 98 (2015) 3–27

[7] V.A. Bollati, J.M. Vara, A. Jiménez, E. Marcos, Applying MDE to the (semi-)automatic development of model transformations, Inf. Softw. Technol. 55 (4) (2013) 699–718. [8] A. Boronat, J. Carsı, I. Ramos, Automatic support for traceability in a generic model management framework, in: A. Hartman, D. Kreische (Eds.), Model Driven Architecture – Foundations and Applications, in: Lect. Notes Comput. Sci., vol. 3748, Springer, Berlin, Heidelberg, 2005, pp. 316–330. [9] A. Cicchetti, D.D. Ruscio, R. Eramo, A. Pierantonio, JTL: a bidirectional and change propagating transformation language, in: M. van den Brand, B. Malloy, S. Staab (Eds.), Proceedings of the 3rd International Conference on Software Language Engineering, SLE 2010, Springer, October 2010. [10] J.S. Cuadrado, J.G. Molina, M. Tortosa, RubyTL: a practical, extensible transformation language, in: A. Rensink, J. Warmer (Eds.), Model Driven Architecture Foundations and Applications, in: Lect. Notes Comput. Sci., vol. 4066, Springer, Berlin/Heidelberg, 2006, pp. 158–172. [11] K. Czarnecki, J.N. Foster, Z. Hu, R. Lämmel, A. Schürr, J.F. Terwilliger, Bidirectional transformations: a cross-discipline perspective grace meeting notes, state of the art, and outlook, in: International Conference on Model-Transformations, ICMT 2009, in: Lect. Notes Comput. Sci., Springer, Berlin/Heidelberg, 2009. [12] K. Czarnecki, S. Helsen, Feature-based survey of model transformation approaches, IBM Syst. J. 45 (3) (2006) 621–645. [13] J. Davies, J. Gibbons, J. Welch, E. Crichton, Model-driven engineering of information systems: 10 years and 1000 versions, Sci. Comput. Program. 89 Part B (1 September 2014) 88–104, http://dx.doi.org/10.1016/j.scico.2013.02.002. [14] M. Didonet Del Fabro, P. Valduriez, Towards the efficient development of model transformations using model weaving and matching transformations, Softw. Syst. Model. 8 (3) (2009) 305–324. [15] R. Eramo, I. Malavolta, H. Muccini, P. Pelliccione, A. Pierantonio, A model-driven approach to automate the propagation of changes among architecture description languages, Softw. Syst. Model. 11 (1) (2012) 29–53. [16] J. Falleri, M. Huchard, M. Lafourcade, C. Nebut, Metamodel matching for automatic model transformation generation, in: Proceedings of the International Conference on Model Driven Engineering Languages and Systems, Springer, 2008, pp. 326–340. [17] K. Garcés, J.M. Vara, F. Jouault, E. Marcos, Adapting transformations to metamodel changes via external transformation composition, Softw. Syst. Model. (2012) 1–18. [18] B. Grammel, S. Kastenholz, K. Voigt, Model matching for trace link generation in model-driven software development, in: Proceedings of the 15th International Conference on Model Driven Engineering Languages and Systems, MODELS’12, Springer-Verlag, Berlin, Heidelberg, 2012, pp. 609–625. [19] R. Gronback, Eclipse Modeling Project: A Domain-Specific Language Toolkit, Addison-Wesley Professional, 2009. [20] E. Guerra, J. de Lara, D. Kolovos, R. Paige, O. dos Santos, Engineering model transformations with transML, Softw. Syst. Model. 12 (3) (2011) 1–23. [21] E. Guerra, J. Lara, D. Kolovos, R. Paige, Inter-modelling: from theory to practice, in: D. Petriu, N. Rouquette, Ø. Haugen (Eds.), Model Driven Engineering Languages and Systems, in: Lect. Notes Comput. Sci., vol. 6394, Springer, Berlin/Heidelberg, 2010, pp. 376–391. [22] L. Iovino, A. Pierantonio, I. Malavolta, On the impact significance of metamodel evolution in MDE, J. Object Technol. 11 (3) (2012) 1–33. [23] Á. Jiménez, Integrating traceability management in a framework for MDD of model transformations, PhD thesis, ETSII, Rey Juan Carlos University, Madrid, Spain, April 2012. [24] F. Jouault, Loosely coupled traceability for ATL, in: Proceedings of the European Conference on Model Driven Architecture (ECMDA) Workshop on Traceability, Nuremberg, Germany, vol. 91, 2005. [25] F. Jouault, F. Allilaire, J. Bézivin, I. Kurtev, ATL: a model transformation tool, Sci. Comput. Program. 72 (1–2) (2008) 31–39. [26] F. Jouault, I. Kurtev, On the interoperability of model-to-model transformation languages, Sci. Comput. Program. 68 (3) (2007) 114–137. [27] G. Kappel, P. Langer, W. Retschitzegger, W. Schwinger, M. Wimmer, Model transformation by-example: a survey of the first wave, in: Conceptual Modelling and Its Theoretical Foundations, Springer-Verlag, Berlin, Heidelberg, 2012, pp. 197–215. [28] D. Kolovos, R. Paige, F. Polack, Eclipse development tools for Epsilon, in: Proceedings of the Eclipse Summit Europe, Eclipse Modeling Symposium, Esslingen, Germany, 2006. [29] D. Kolovos, R. Paige, F. Polack, The Epsilon transformation language, in: Theory and Practice of Model Transformations, in: Lect. Notes Comput. Sci., vol. 5063, Springer, Berlin/Heidelberg, 2008, pp. 46–60. [30] I. Kurtev, State of the art of QVT: a model transformation language standard, in: Applications of Graph Transformations with Industrial Relevance, vol. 5088, 2008, pp. 377–393. [31] A. Kusel, TROPIC – a framework for building reusable transformation components, in: Proceedings of the Doctoral Symposium at MODELS, 2009. [32] T. Levendovszky, D. Balasubramanian, K. Smyth, F. Shi, G. Karsai, A transformation instance-based approach to traceability, in: ECMFA-TW ’10: Proceedings of the 6th ECMFA Traceability Workshop, ACM, New York, NY, USA, 2010, pp. 55–60. [33] B. Lossanm, B. Pierre, D. Jean-Luc, Traceability and interoperability at different levels of abstraction in model-driven engineering, in: Applications of Specification and Design Languages for SoCs, Springer, Netherlands, 2006, pp. 263–276. [34] P. Mäder, O. Gotel, I. Philippow, Enabling automated traceability maintenance through the upkeep of traceability relations, in: Model Driven Architecture – Foundations and Applications, in: Lect. Notes Comput. Sci., vol. 5562, Springer, Berlin/Heidelberg, 2009, pp. 174–189. [35] T. Mens, P.V. Gorp, A taxonomy of model transformation, Electron. Notes Theor. Comput. Sci. 152 (2006) 125–142, Proceedings of the International Workshop on Graph and Model Transformation (GraMoT 2005). [36] M. Mernik, J. Heering, A.M. Sloane, When and how to develop domain-specific languages, ACM Comput. Surv. 37 (4) (Dec. 2005) 316–344. [37] J. Miller, J. Mukerji, MDA guide version 1.0.1, Technical report, Object Management Group (OMG), 2003. [38] J. Oldevik, MOFScript user guide. Version 0.9 (MOFScript v1.4.0), 2011. [39] J. Oldevik, T. Neple, Traceability in model to text transformations, in: ECMDA-TW’06: Proceedings of the 2th European Conference on Model Driven Architecture – Traceability Workshop, 2006, pp. 17–26 (Citeseer). [40] OMG. Meta object facility (MOF) 2.0 query/view/transformation specification – QVT. http://www.omg.org/spec/QVT/1.1/PDF/, 2011. [41] R. Pérez-Castillo, I. García-Rodríguez, M. Piattini, Business process archeology using MARBLE, Inf. Softw. Technol. 53 (10) (2011) 1023–1044, Special section on mutation testing. [42] I. Santiago, A. Jiménez, J.M. Vara, V. De Castro, V.A. Bollati, E. Marcos, Model-driven engineering as a new landscape for traceability management: a systematic literature review, Inf. Softw. Technol. 54 (12) (Dec. 2012) 1340–1356. [43] I. Santiago, J.M. Vara, V. De Castro, E. Marcos, Towards the effective use of traceability in model-driven engineering projects, in: Proceedings of the 32nd International Conference on Conceptual Modeling, ER 2013, in: Lect. Notes Comput. Sci., vol. 8217, Springer-Verlag, Berlin, Germany, 2013, pp. 429–437. [44] D. Schmidt, Model-driven engineering, Computer 39 (2) (2006) 25–31. [45] A. Schürr, Specification of graph translators with triple graph grammars, in: Proc. of the 20th Int. Workshop on Graph-Theoretic Concepts in Computer Science, WG ’94, Herrsching (D), Springer, 1995. [46] B. Selic, What will it take? A view on adoption of model-based methods in practice, Softw. Syst. Model. (2012) 1–14. [47] S. Sendall, W. Kozaczynski, Model transformation: the heart and soul of model-driven software development, IEEE Softw. 20 (5) (2003) 42–45. [48] D. Steinberg, F. Budinsky, M. Paternostro, E. Merks, EMF: Eclipse Modeling Framework 2.0, 2nd edition, Addison-Wesley Professional, 2009. [49] P. Stevens, A landscape of bidirectional model transformations, in: Generative and Transformational Techniques in Software Engineering II, SpringerVerlag, Berlin, Heidelberg, 2008, pp. 408–424. [50] 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 on Model Driven Architecture – Foundations and Applications, ECMDA-FA ’09, Springer-Verlag, Berlin, Heidelberg, 2009, pp. 18–33.

Á. Jiménez et al. / Science of Computer Programming 98 (2015) 3–27

27

[51] M.F. van Amstel, M.G. van den Brand, Using metrics for assessing the quality of ATL model transformations, in: Proceedings of the Third International Workshop on Model Transformation with ATL, MtATL 2011, vol. 742, 2011, pp. 20–34. [52] J.M. Vara, E. Marcos, A framework for model-driven development of information systems: technical decisions and lessons learned, J. Syst. Softw. 85 (10) (Oct 2012) 2368–2384. [53] A. Vignaga, A methodological approach to developing model transformations, in: MoDELS (Doctoral Symposium), Citeseer, 2007. [54] M. Völter, From programming to modeling – and back again, IEEE Softw. 28 (6) (2011) 20–25. [55] A. von Knethen, M. Grund, Quatrace: a tool environment for (semi-) automatic impact analysis based on traces, in: ICSM, 2003, pp. 246–255. [56] E. Willink, H. Hoyos, D. Kolovos, Yet another three QVT languages, in: K. Duddy, G. Kappel (Eds.), Theory and Practice of Model Transformations, in: Lect. Notes Comput. Sci., vol. 7909, Springer, Berlin/Heidelberg, 2013, pp. 58–59. [57] Y. Xiong, H. Song, Z. Hu, M. Takeichi, Supporting parallel updates with bidirectional model transformations, in: Proceedings of the 2nd International Conference on Theory and Practice of Model Transformations, ICMT ’09, Springer-Verlag, Berlin, Heidelberg, 2009, pp. 213–228. [58] A. Yie, D. Wagelaar, Advanced traceability for ATL, in: Proceedings of the 1st International Workshop on Model Transformation with ATL, MtATL 2009, Nantes, France, 2009, pp. 78–87.