Testing M2M/M2T/T2M Transformations Loli Burgueño Dept. Lenguajes y Ciencias de la Computación University of Malaga Malaga, Spain Email: loli@lcc.uma.es Abstract—As Model-Driven Engineering is becoming adopted and reverse engineering for the modernization of legacy ap- by industry, models and model transformations (MTs) are ex- plications [6]. However, they have received little attention so tensively used. Hence, there is the urgent need for systematic far by the research community. testing mechanisms and tools to check their correctness. In this work, we make use of a particular case of contracts for The contribution presented in this paper is twofold. First, model transformations called Tracts. First, Tracts allow the we have extended the Tract approach for M2T and T2M transformation developer to specify and test a model-to-model transformations. We have created a generic metamodel that transformation in a modular way, and to identify bugs. However, represents text repositories and inject the text into a model they do not allow to track where the faults in the implementation that conforms to that metamodel. Once both source and target are. For doing that, we present an approach based on matching functions that automatically establish the alignments between domains count on a concrete and well-defined representation, the specification and the implementation of a transformation M2T and T2M transformations are reduced to M2M trans- using the metamodel footprints. Second, we extend Tracts to deal formations. Therefore, Tracts can be used for checking their with text-to-model and model-to-text transformations in order to correctness. broaden and complete the scope of our testing proposal. Finally, Second, we define a mechanism based on matching tables we provide the corresponding tools that realize our proposal. that permit relating the rules of a model transformation with its I. P ROBLEM AND M OTIVATION Tracts, i.e., aligning the model transformation implementation with its specification. By analysing the matching tables, the Model transformations (MT) are gaining more and more rules that cause a fault can be identified, hence realizing interest as industry is progressively adopting model-driven a useful tracking mechanism for locating faults in model techniques [1]. The main advantage of using of model trans- transformations. formations is to save effort and reduce errors by automating The structure of the paper is as follows. Section II in- the creation and alteration of models as long as it is possible. troduces the concepts in which this work stands and the Thus, they are becoming a promising approach in many related work. Section III presents the core of our contribution: different scenarios to solve a wide variety of problems, e.g. to the extension of Tracts for M2T and T2M transformations deal with the migration of systems, their modernization, for and how the matching tables are computed and interpreted. code generation, etc., especially when complex data structures Finally, Section IV shows the results we have obtained and are involved. This complexity may lead to the existence of the contributions we have made. bugs in the model transformation implementation that make it faulty. Then, the need of testing, validation and verification II. BACKGROUND AND R ELATED W ORK procedures for model transformations is emerging in recent The need for systematic verification of model transforma- years [2], [3]. tions has been studied in previous works and the challenges it So far, most of the efforts by the research community have has to deal with have been outlined [7], [8]. Many approaches focused on testing model-to-model (M2M) transformations for ranging from lightweight certification to full verification have which having explicit model representations for the input and been proposed to reason about different kinds of properties output domain is assumed. There are different approaches that of M2M transformations [2], [3]. One of them is the use of can be classified attending to their characteristics as black- contracts [4], [9], [10]. box vs. white-box and static vs. dynamic. Depending on the Tracts, which are a particular case of contracts, are a black- concrete situation, the transformation developer needs to make box testing mechanism for M2M transformations. They consist the decision of what mechanism to use. When black-box of a set of constraints on the source and target metamodels, dynamic approaches such as Tracts [4] are the best option, a set of source-target constraints, and a test suite, i.e., a the developer finds that they do allow the testing of model collection of source models. They provide modular pieces of transformations but they do not track where the problem is in specification, each one focusing on a particular transformation the implementation, i.e., they reveal that there is a problem scenario. This permits each model transformation to be speci- but they do not point to where it is or what is producing it. fied by means of a set of Tracts, each one covering a specific Furthermore, text-to-model (T2M) and model-to-text (M2T) use case. Usually, they are seen as unit tests, which means that transformations are extensively used [5] for code generation developers identify the scenarios of interest and define a Tract for each one. Then, they check whether the transformation behaves as expected in these scenarios. Other works proposed alternative ways for defining oracles [11]–[15], however, they do not discuss how to apply their approaches for text artifacts. The most closely related work for testing M2T transformations is presented in [16]. Nevertheless, this approach requires the definition of a functional decomposition diagram for the M2T transformation as well as the design specifications for the text produced by the transformation. Tracking guilty transformation rules using a dynamic ap- Fig. 1. Metamodel for representing text artifacts and repositories. proach where constraints are involved has also been subject to investigations [17], [18]. In [19]–[21], the authors locate errors using the trace information of the MT executions, i.e., determining the relationship between the source and target elements and the excerpt of the transformation involved. The dynamic approach is also used in [22] to build slices of model transformations and in [23] following a white-box testing approach. All these approaches need to count on input models while our aim is to statically build more general traceability models between the specification of the MTs and Fig. 2. Exemplary folder structure and file content. their implementations. III. A PPROACH AND U NIQUENESS analysed thoroughly, we have enriched OCL with an operation called matchesRE() that checks whether a given string matches a regular expression. Furthermore, we have intro- A. Extending Tracts for M2T and T2M transformations duced some auxiliary functions that are currently provided by In order to test model transformations when text is involved M2T transformation languages such as toFirstUpper() in one of the domains, either in the source or the target, we to end up with more concise OCL constraints than just using propose an approach that converts the problem to a M2M the standard OCL String operation library. transformation testing problem [24]. In order to achieve that, In order to illustrate what a Tract looks like, let us assume instead of defining a specific grammar or metamodel for each that we are testing a M2T transformation that generates Java text artifact, we have opted for creating a generic metamodel code from UML models. Let us also assume a very simplified that represents text repositories. Then, the folder structure UML metamodel that only has Packages, Classes and and text files are injected to a model conforming to the text Properties. All of them have a name and the properties metamodel. have a type as well. Furthermore, each package may contain a set of classes and each class may contain set of properties. The metamodel is shown in Figure 1. It counts on a meta- The metamodel is shown in Figure 4. class Repository that represents the entry point to the root The Tract constraint in Listing 1 specifies the correct folder containing folders and files or to a file if only one single behavior that a M2T transformation that transforms each UML artifact is used. Folders just contain a name while files have package to a Java package, each UML class to a Java class in addition an extension as well as a content. The content of and each UML property to a Java attribute must fulfil. files is represented by lines that are sequentially ordered. A derived attribute content is used to allow easy access to the Listing 1. Tract constraint for the UML2Java example. complete content of a file. UMLPackage.allInstances->forAll(upack | Folder.allInstances->exists(folder | Figure 2 displays on its left-hand side the folder structure upack.name = folder.name and of a Java project while on its right-hand side the content of upack.classes->forAll( uclass | folder.content->selectByType(File)->exists( file | one of its Java files. Figure 3 presents an excerpt of the text uclass.name = file.name and model corresponding to the elements that Figure 2 shows and uclass.properties.allInstances->forAll(uprop | file.lines->exists( line | line.machtesRE( several lines of the Java file. ".*"+uprop.type+".*"+uprop.name+".*;"))))))) The specification of the transformation to be tested is composed of a set of Tracts, each one focusing on a particular In order to provide tool support for our proposal, we property that the developer wants to ensure. The constraints have developed a injector (parser) that converts the content defined by those Tracts are OCL expressions. Thus, a problem of a text repository into a model that conforms to the text arises when the developer needs to deal with the text repre- metamodel shown in Figure 1, and an extractor that takes sented by the lines but realises that the variety of libraries and models conforming to the text metamodel and produces text operations that OCL provides to manage Strings is reduced organized in folders. In order to check that a given M2T and very restrictive. As the text in the lines may need to be transformation fulfils the constraints (such as the one shown of an input pattern—that might have a filter condition or not—which is matched on the source model, and an output pattern that produces certain elements in the target model for each match of the input pattern. OCL expressions are used to calculate the values of target features of the target elements. Given the set of OCL constraints from the Tracts and the set of ATL rules from the transformation implementation, the common part they share is the source and target metamodels, which means that the same types and features are used. Thus, we make use of these commonalities to indirectly match the constraints and the rules by matching their footprints Fig. 3. Text Model concerning the source and target metamodels. Our aim is to construct three tables called matching tables with the alignments between specification and implementation. First of all, we need to extract the footprints (i.e., the structural elements) from the constraints and rules. Since meta- models are graphs, OCL expressions are heavily dependent on their contexts and also on the path used to navigate to the Fig. 4. Simplified UML Metamodel types that the constraint is checking. That navigation path has nothing to do with the aim of the constraint. Thus, taking all the footprints on it into account only introduces noise. This before), we execute the transformation using the Tract test is why we only consider as relevant the last elements of the suite and then, we use the injector for obtaining the output OCL expressions. To consider operations on collections, we models conforming to the text metamodel from the output text take into account only the footprints inside the body of the generated by the transformation. Then we check the validity deepest (in the sense of nesting) iterators (forAll, exists, etc.). of the constraints as in the case of Tracts defined for M2M Once the footprints have been extracted, for each pair transformations, with our TractsTool [3]. TractsTool evaluates constraint/rule, the percentage of overlapping footprints is the defined constraints on the source and target models by a calculated. To do so, we also take subtyping into account, transparent translation to the USE tool [25]. i.e., we consider that two footprints matches if they share the In the case that the MT to test is a T2M transformation, same type or if one is a subtype of the other. This is important the procedure is similar. The test suite is defined by the Tract because some OCL operators used in the Tract constraints and as a set of repositories, which need to be transformed first in the ATL rules (such as allInstances) retrieve all instances into a model-based representation using our injector. When the of a certain class, as well as the instances of all its subclasses. source constraints are fulfilled, the content of the repository is When the information about the footprints is available, the transformed by the T2M transformation under test to produce matching tables are calculated according to three metrics: the output models. The models produced from the repository constraint coverage (CC), rule coverage (RC) and relatedness and their corresponding output models can then be validated of constraints and rules (RCR). The value for the cell [i, j] is by TractsTool against the Tracts. given by the following formulas: In this way, we are able to test M2T and T2M transforma- tions in a similar manner to M2M transformations. |Ci ∩ Rj | |Ci ∩ Rj | |Ci ∩ Rj | B. Tracking faults in MT implementations CCi,j = ; RCi,j = ; RCRi,j = |Ci | |Rj | |Ci ∪ Rj | Using Tracts in conjunction with the previously presented approach, M2M, M2T and T2M transformations can be tested CC measures the coverage for constraint i by a given rule but once a failure is detected, it is not possible to track why the j. We interpret this value for rule traceability, i.e., to find the transformation is not working or where the problem is located. rules related to the given constraint. This is, if a constraint The existence of a problem lies in the misalignment between fails, the CC table tells us which rule or rules are more likely the model transformation specification and its implementation. to have caused the faulty behavior. For this reason, the CC We present a white-box and static analysis to ease the task of table is to be consulted by rows. finding the location of the model transformation rules that may On the other hand, RC focuses on rules. This metric have caused the faulty behavior [26]. calculates the coverage for rule j by a given constraint i. We are using Tracts for defining the specification of the We use the RC table to express constraint traceability as it MTs. ATL [27] is the MT language we have chosen for shows what constraints are more closely related to a given building its implementatation. ATL is a rule-based language rule. Therefore, it is to be read by columns. containing a mixture of declarative and imperative constructs RCR is related to both constraints and rules so it can be for defining uni-directional transformations. A rule consists consulted by rows and by columns. It provides information TABLE I Families2Persons MATCHING TABLES . CC RC RCR R1 R2 R1 R2 R1 R2 C1 0.33 0.33 0.25 0.25 0.17 0.17 C2 0.33 0.67 0.50 1.00 0.25 0.67 C3 0.67 0.33 1.00 0.50 0.67 0.25 C4 1.00 1.00 0.50 0.50 0.4 0.4 Fig. 5. The Family and Person metamodels. module Families2Persons; about the relatedness of both rules and constraints, without create OUT: Persons from IN: Families; helper context Families!Member def:isFemale:Boolean=... defining a direction for interpreting the values. helper context Families!Member def:familyName:String=... Let us use the well-known M2M transformation example rule Member2Male { -- R1 Families2Persons1 to show how our approach is applied. The from s:Families!Member (not s.isFemale) to t:Persons!Male(fullName<-s.firstName+’ ’+s.familyName)} two metamodels are presented in Figure 5. We have developed rule Member2Female { -- R2 one Tract (Listing 2) that considers only families with exactly from s:Families!Member (s.isFemale) to t:Persons!Female(fullName<-s.firstName+s.familyName)} four members: one mother, one father, one daughter and one son. The first constraint states that all families in the source The footprints corresponding to R1 are Member, Male, model have exactly one daughter and one son. The second Member.firstName and Male.fullName, while the footprints constraint states that all mothers and daughters are transformed for R2 are Member, Female, Member.firstName and Fe- into female persons and the third mandates that all fathers male.fullName. Note that when a rule calls a helper, the and sons are transformed into male persons. Finally, the last helper’s footprints are included into the set of rule’s footprints. constraint checks that the sizes of the source and target models Table I shows the metrics computed for the Fami- are equal. lies2Persons example. Note that, for a small example like this, the metrics provide information that can be easily interpreted Listing 2. Tracts for the Families2Persons case study. -- C1: SRC_oneDaughterOneSon by just looking at the constraints and the rules. Let us suppose Family.allInstances->forAll(f|f.daughters->size=1 and that we have executed the transformation for a certain input f.sons->size=1) -- C2: SRC_TRG_MotherDaughter2Female model and checked the satisfaction of the constraints using Family.allInstances->forAll(fam|Female.allInstances-> TractsTool. Let us assume the outcome given by the tool is exists(f|fam.mother.firstName.concat(’ ’).concat( fam.lastName)=f.fullName) xor fam.daughters->exists(d| that constraint C2 is not satisfied. Looking at the CC metric, d.firstName.concat(’ ’).concat(fam.lastName)=f.fullName)) we can see that it is more likely that the problem is in rule -- C3: SRC_TRG_FatherSon2Male Family.allInstances->forAll(fam|Male.allInstances-> R2. In case there were several rules with the same probability exists(m| fam.father.firstName.concat(’ ’).concat( in CC, we should look at RCR to decide which one should fam.lastName)=m.fullName xor fam.sons->exists(s| m.firstName.concat(’ ’).concat(fam.lastName)=s.fullName)) be checked first. By looking at RC, we can see that for each -- C4: SRC_TRG_MemberSize_EQ_PersonSize one of the rules, there is always a constraint covering it, what Member.allInstances->size=Person.allInstances->size means that it correctness is being checked by the Tract. The footprints extracted for C1 are Family, Fam- The testing method we propose is far from fully prove ily.daughters, Family.sons and Member (Member appears be- correctness of the transformation. Nevertheless, it provides cause it is the type of f.daughters and f.sons). For C2, the first step to model transformation testing, which aims at they are Family, Member, Female, Member.firstName, Fam- locating faults as early as possible in a quick and cost-effective ily.lastName, Female.fullName. Note that, in the case of the manner. Being aware that our proposal may not work in some navigation path Family.mother.firstName, we will only con- cases, we also provide a method and a tool, called Similarity sider mother.firstName. The footprints for C3 are the same as Matrix Calculator, for checking whether a transformation is for C2 but replacing Female with Male. Finally, the footprints amenable to be used with it. A similarity matrix gives us an for C4 are Member and Person. indication of how rules are related with each other looking at A possible implementation of the transformation in ATL is the common footprints they share. We obtain the mean and given in Listing 3. It comprises two helper functions and two the standard deviation of the rule similarities. The lower both rules. One of the helpers is used to decide whether a member values are (especially the mean), the fewer types and features is female or not, and the second one is used to compute the the rules have in common, and thus, the higher the chance for family name of a family member. The first rule, R1, transforms a successful application of our approach is. However, if the male members (note the use of the helper isFemale() to filter mean and the standard deviation are far from 0, it is difficult the corresponding source objects) into male persons and R2 to distinguish among the rules which is the “guilty” one. is analogous, but for female family members. All the previously mentioned tool support we have devel- oped, i.e., TractTool, Matching Tables Builder and Similarity Listing 3. Families2Persons ATL Transformation. Matrix Calculator, can be downloaded from our website2 . 1 http://www.eclipse.org/atl/atlTransformations/#Families2Persons 2 http://atenea.lcc.uma.es/index.php/Main Page/Resources/FaultLocMT TABLE II initial components of a benchmark for future improvements E VALUATION RESULTS and developments of UML-to-Java code generators. TOOL C1 C2 C3 C4 C5 C6 C7 C8 C9 In order to evaluate the second part of our proposal— ArgoUML X X × × - X X × × Poseidon X × × X × X X × X where, given the failures in the Tracts, the rules that cause MagicD. X X X X × X X × X the problems are disclosed—we have analyzed the alignments EArchitect X X X × × X X × × between specifications and implementations in four different BOUML × X - X × X X × X A.UModel × X X X × X X X X real-world transformation projects. For each one of them we computed manually the alignments between rules and constraints. Having the matching tables obtained with our IV. R ESULTS AND C ONTRIBUTIONS approach and the real alignments, we are able to compute two measures to assess its quality: precision and recall. In In order to evaluate the usefulness of our contract-based the context of our study, precision denotes the fraction of the mechanism for M2T or T2M transformations, we have selected detected alignments that are in fact correct. Recall indicates a set of currently available UML tools that provide code gen- the fraction of alignments that have not been missed. eration facilities to produce source code from UML models. The first case study we selected is a transformation dealing We have generated the Java code corresponding to a set of with the generation of Entity Relationship (ER) Diagrams input models and we have checked the result using a set of from UML Class Diagram Models. Second, a project that Tracts. deals with behavioral models conforming to CPL [28] that For the evaluation, we defined a set of 9 constraints which are transformed into models conforming to SPL [29]. This represent some of the most essential requirements that any transformation [30] is a relatively complex example available UML to Java code generator has to fulfil. C1 establishes that from the ATL zoo4 . Also from the ATL zoo, we considered nested packages are transformed into nested folders. C2 checks a project that does not operate on modeling languages but that the import of packages is supported and C3 that the rather on markup languages. It is the BT2DB transformation inheritance of a leaf class is not allowed. C4 makes sure that from BibTeX documents into DocBook documents. Finally, only single inheritance is used in UML and C5 that derived we experimented with a very large transformation called attributes only result in getter methods. C6 and C7 checks Ecore2Maude which is used by the tool e-Motions [31] in that the visibility of attributes and roles is mapped to Java. order to apply some formal reasoning. C8 watches that no Java keywords are allowed as names in For space reasons, we cannot present the Tract constraints, UML models and C9 that the names in an UML model have the ATL rules and the matching tables but they are available to be valid Java identifiers. The constraints as well as all the at our website 5 . We have observed that the values obtained required files to execute the experiment can be found in our for the precision and recall metrics are acceptable in three website 3 . of the projects: UML2ER, CPL2SPL and Ecore2Maude. With The six UML tools that we selected from industry claimed these accuracy results, we can conclude that our approach to support code generation from UML class diagrams into works well, since the alignments found statically are quite Java code. The selected sample covers both commercial tools reliable. Nevertheless, as pointed by the similarity matrix for and open-source projects. They are ArgoUML v.0.34, Po- the BT2DB example (with a mean of 0.41 and a standard seidon v.6.0.2., MagicDraw v.16.8., EnterpriseArchitect v.10, deviation of 0.24) our approach is unable to help detect BOUML v.4.22.2. and Altova UModel. problems in the implementation. We have also computed the We defined reference test models based on UML and we similarity matrixes for all the transformations in the ATL zoo re-modelled them in all of the selected tools. We run the code in order to investigate the applicability of our approach. Out of generator for each one of the tools and obtainted the Java text the 41 model transformations studied, the mean and standard corresponding to the UML model. Then we checked the output deviation turned out to be below 0.15 in 21 of them, which against the Tracts. means that our approach can be used with around half of the Table II shows the results of the evaluation. A tick symbol transformations. (X) means that the test passed for that Tract and a cross We conclude this paper by listing the contributions we symbol (×) means that the Tract test failed. Some of the tests have made. First, we have extended Tracts to be used for were not available for a given tool, e.g., a particular modeling M2T/T2M transformations and have proved its usefulness de- feature is missing, and were not performed. This is indicated tecting errors in current UML-to-Java code generators offered by a dash (-). We found that no tool performs well even with by well-known UML tools. Second, we have presented a static respect to the basic UML to Java code generators. Further- approach to trace errors in model transformations and have more, we discovered that several tools produced incorrect Java proved that our approach is applicable to a large number of code, even not compilable in some situations. In this sense, the transformations. Tracts presenting the basic requirements could be used as the 3 http://atenea.lcc.uma.es/index.php/Main Page/Resources/Tracts/ 4 http://www.eclipse.org/atl/atlTransformations UML2Java 5 http://atenea.lcc.uma.es/index.php/Main Page/Resources/MTB R EFERENCES [24] M. Wimmer and L. Burgueño, “Testing M2T/T2M transformations,” in Proc. of MODELS’13, ser. LNCS, vol. 8107. Springer, 2013, pp. 203– [1] M. Brambilla, J. Cabot, and M. Wimmer, Model-Driven Software En- 219. gineering in Practice, ser. Synthesis Lectures on Software Engineering. [25] M. Gogolla, F. Büttner, and M. Richters, “USE: A UML-based specifi- Morgan & Claypool Publishers, 2012. cation environment for validating UML and OCL,” Science of Computer [2] M. Amrani, L. Lúcio, G. Selim, B. Combemale, J. Dingel, Programming, vol. 69, pp. 27–34, 2007. H. Vangheluwe, Y. L. Traon, and J. R. Cordy, “A tridimensional [26] L. Burgueño, M. Wimmer, J. Troya, and A. Vallecillo, “Static Fault approach for studying the formal verification of model transformations,” Localization in Model Transformations,” IEEE Transactions on Software in Proc. of the 1st International Workshop on Verification and Validation Engineering, vol. 41, no. 5, pp. 490–506, 2015. of Model Transformations (VOLT 2012), 2012. [27] F. Jouault, F. Allilaire, J. Bézivin, and I. Kurtev, “ATL: A model [3] A. Vallecillo, M. Gogolla, L. Burgueño, M. Wimmer, and L. Hamann, transformation tool,” Science of Computer Programming, vol. 72, no. “Formal specification and testing of model transformations,” in Formal 1-2, pp. 31–39, 2008. Methods for Model-Driven Engineering (SFM), ser. LNCS, vol. 7320. [28] J. Lennox, X. Wu, and H. Schulzrinne, “Call Processing Language Springer, 2012, pp. 399–437. (CPL): A language for user control of internet telephony services,” 2004, [4] M. Gogolla and A. Vallecillo, “Tractable model transformation testing,” http://www.ietf.org/rfc/rfc3880.txt. in Proc. of ECMFA’11, ser. LNCS, vol. 6698. Springer, 2011, pp. [29] L. Burgy, C. Consel, F. Latry, J. Lawall, N. Palix, and L. Reveillere, 221–236. “Language technology for internet-telephony service creation,” in Proc. [5] K. Czarnecki and S. Helsen, “Feature-based survey of model transfor- of ICC’06. IEEE, 2006, pp. 1795–1800. mation approaches,” IBM Systems Journal, vol. 45, no. 3, pp. 621–646, [30] F. Jouault, J. Bézivin, C. Consel, I. Kurtev, and F. Latry, “Building 2006. DSLs with AMMA/ATL, a Case Study on SPL and CPL Telephony Languages,” in Proc. of ECOOP Workshop on Domain-Specific Program [6] H. Bruneliere, J. Cabot, F. Jouault, and F. Madiot, “MoDisco: a generic Development, 2006. and extensible framework for model driven reverse engineering,” in Pro- [31] J. E. Rivera, F. Durán, and A. Vallecillo, “A Graphical Approach for ceedings of the 25th International Conference on Automated Software Modeling Time-Dependent Behavior of DSLs,” in Proc. of VL/HCC’09. Engineering (ASE 2010). ACM, 2010, pp. 173–174. IEEE, 2009, pp. 51–55. [7] B. Baudry, S. Ghosh, F. Fleurey, R. France, Y. L. Traon, and J.-M. Mottu, “Barriers to systematic model transformation testing,” Communications of the ACM, vol. 53, no. 6, pp. 139–143, 2010. [8] R. V. D. Straeten, T. Mens, and S. V. Baelen, “Challenges in model- driven software engineering,” in Models in Software Engineering, ser. LNCS, vol. 5421. Springer, 2008, pp. 35–47. [9] B. Meyer, “Applying design by contract,” IEEE Computer, vol. 25, no. 10, pp. 40–51, 1992. [10] E. Cariou, N. Belloir, F. Barbier, and N. Djemam, “OCL contracts for the verification of model transformations,” ECEASST, vol. 24, 2009. [11] E. Cariou, R. Marvie, L. Seinturier, and L. Duchien, “OCL for the specification of model transformation contracts,” in Proc. of the OCL and Model Driven Engineering Workshop, 2004. [12] A. Garcı́a-Domı́nguez, D. S. Kolovos, L. M. Rose, R. F. Paige, and I. Medina-Bulo, “EUnit: A unit testing framework for model manage- ment tasks,” in Proc. of MODELS’11, ser. LNCS, vol. 6981. Springer, 2011, pp. 395–409. [13] P. Giner and V. Pelechano, “Test-Driven Development of Model Trans- formations,” in Proceedings of the 12th International Conference on Model Driven Engineering Languages and Systems (MODELS 2009), ser. LNCS, vol. 5795. Springer, 2009, pp. 748–752. [14] D. Kolovos, R. Paige, L. Rose, and F. Polack, “Unit testing model management operations,” in ICSTW’08. IEEE, 2008, pp. 97–104. [15] E. Guerra, “Specification-driven test generation for model transforma- tions,” in Proceedings of the 5th International Conference on Theory and Practice of Model Transformations (ICMT 2012, ser. LNCS, vol. 7307. Springer, 2012, pp. 40–55. [16] A. Tiso, G. Reggio, and M. Leotta, “Unit testing of model to text transformations,” in Proc. of AMT’14, 2014, pp. 14–23. [Online]. Available: http://ceur-ws.org/Vol-1277/2.pdf [17] B. Ramesh and V. Dhar, “Supporting systems development by capturing deliberations during requirements engineering,” IEEE Transactions on Software Engineering, vol. 18, no. 6, pp. 498–510, 1992. [18] F. A. C. Pinheiro and J. A. Goguen, “An object-oriented tool for tracing requirements,” IEEE Software, vol. 13, no. 2, pp. 52–64, 1996. [19] M. Hibberd, M. Lawley, and K. Raymond, “Forensic debugging of model transformations,” in Proc. of MODELS’07, ser. LNCS, vol. 4735. Springer, 2007, pp. 589–604. [20] V. Aranega, J.-M. Mottu, A. Etien, and J.-L. Dekeyser, “Traceability mechanism for error localization in model transformation,” in Proc. of ICSOFT’09. INSTICC Press, 2009, pp. 66–73. [21] M. Wimmer, G. Kappel, J. Schönböck, A. Kusel, W. Retschitzegger, and W. Schwinger, “A Petri Net based debugging environment for QVT Relations,” in Proc. of ASE’09. IEEE, 2009, pp. 3–14. [22] Z. Ujhelyi, Á. Horváth, and D. Varró, “Dynamic backward slicing of model transformations,” in Proc. of ICST’12. IEEE, 2012, pp. 1–10. [23] C. A. González and J. Cabot, “ATLTest: A White-Box Test Generation Approach for ATL Transformations,” in Proc. of MoDELS’12, ser. LNCS, vol. 7590. Springer, 2012, pp. 449–464.