=Paper=
{{Paper
|id=Vol-1503/02_pap_burgueno
|storemode=property
|title=Testing M2M/M2T/T2M Transformations
|pdfUrl=https://ceur-ws.org/Vol-1503/02_pap_burgueno.pdf
|volume=Vol-1503
|dblpUrl=https://dblp.org/rec/conf/models/Burgueno15
}}
==Testing M2M/M2T/T2M Transformations==
https://ceur-ws.org/Vol-1503/02_pap_burgueno.pdf
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.