A graph analysis based approach for specification driven testing of model transformations

A Graph Analysis Based Approach for Specification Driven Testing of Model Transformations A Graph Analysis Based Approach for Specification Driven Testing of Model Transformations Thi Hanh Nguyen and[.]

A Graph Analysis Based Approach for

Specification-Driven Testing of Model

Transformations

Thi-Hanh Nguyen and Duc-Hanh Dang Department of Software Engineering, VNU University of Engineering and Technology

hanhit@hnue.edu.vn, hanhdd@vnu.edu.vn

Abstract—Model transformation plays a critical role of

model-driven approaches and is a significant quality factor for final

products Among current approaches to testing transformations,

specification-driven testing gains much attention of research

community since the black-box testing has many advantages

including understandability for modelers and independence of

transformation languages One of the main challenges for this

approach is how to systematically and effectively generate test

cases from a transformation specification, i.e, rather than from its

implementation This paper aims to introduce a language on the

one hand to precisely specify transformation requirements and

on the other hand to facilitate the verification and validation of

MTs Within our approach, such a transformation specification

language is defined based on triple-graph-grammar (TGG) rules

and graph patterns that allow us to express transformation

requirements in a visual, precise, and declarative way Besides,

we introduce a systematic testing framework to ensure many

important properties of MTs such as syntactical correctness,

completeness, functional behavior, and information preservation

Index Terms—Model Transformation, Triple Graph Grammar,

Specification-Driven Testing

I INTRODUCTION

Model transformations (MTs) are the heart of model-driven

approaches They might be employed for different situations

such as to refine models, to migrate them for current language

versions, and to transform them into verification domains

Within such situations model transformation quality plays a

key role in order to ensure the validity of underlying

model-driven methods Testing is accepted as a practical and effective

technique to ensure model transformation quality To test a

model transformation [1], a tester needs to provide a set

of input test models (so-called test models) conforming to

the source metamodel, run the transformation implementation

with these models and check the correctness of resulting

model Testing transformations as well as complex software

is often unable to prove their correctness, since exhaustive

testing is infeasible The effectiveness of a test method mainly

depends on the quality of test suites, which are generated using

objective stop criteria that are referred to as coverage criteria

Model transformation testing is a relatively new field that

is similar to software testing and contains specific challenges

Firstly, transformations are often defined at the implementation

level without specifications MTs are implemented using

dif-ferent transformation languages, that can be divided into four

paradigms [2]: relational/declarative languages, e.g.,

QVT-relation [3]; imperative/operational languages, e.g., QVTo [3]; graph-based languages, e.g., DSLTrans [4]; and hybrid lan-guages, e.g., ATL [5] Like programs testing MTs at imple-mentation level is currently still challenging [1] Secondly, because of the diversity of current MT languages used in practice, there is a need for a systematic testing approach that

is independent of implementation languages Specification-based testing tends to be a promising approach for the aim MT specifications can be represented by OCL (Object Constraint Language) contacts [6], math notations [7], graph patterns [8], and transformation rules [9]

To test MTs independently of implementation languages, testers could exploit information in both metamodels and specification of MTs in order to generate test cases using black-box testing techniques Current works dealing with the generation of input test models often consider only features

of the input metamodel [10] so that within such metamodel-based approaches the generated test suite tends to be large and contains irrelevant test data Moreover, generating input test is completely independent of constructing oracle test Several other works [6], [8] propose utilizing MT contracts including pre- and postconditions and invariants for test case generation Based on invariants of a MT specification that specify structural relations between valid and invalid pairs

of input and output models, test models and test oracle could be consistently defined However, such approaches to specification-based transformation testing either often consider only requirements independently or focus on verifying the syntactical correctness of MT by checking output models Most errors of complex software as well as MTs are often caused by the interaction relationships between requirements, therefore, are not considered thoroughly within the current approaches Finally, input and output models within current

MT testing methods are often considered as graphs However, the complex graph structure of the input and output models as well as the complex relationship between transformation rules make it difficult to generate effective test suites

To tackle such problems, we propose a graph transformation-based specification language for MTs The language would allow us to represent typical patterns of transformation rules and to facilitate the systematic testing of MTs We take advantage of the pattern-based specification approach and features of graph transformation rules in order

to exploit dependent relationships between transformation

requirements at the specification level Such relationships

would allow us to generate effective test suites Besides,

we also define a set of black-box test criteria and testing

strategies to navigate the test case selection

The rest of this paper is structured as follows Section II

sketches our approach for the specification-driven

transforma-tion testing Sectransforma-tion III introduces our specificatransforma-tion language

TC4MT Then, we explain a method for test case generation

from a transformation specification TC4MT in Sect IV and

present the tool support as well as some experimental results in

Sect V The paper is closed with a conclusion and an outlook

on future works in Sect VI

II A SPECIFICATION-DRIVENTESTINGFRAMEWORK FOR

TRANSFORMATIONS

Figure 1 outlines our approach for testing MTs First,

as shown in label 1, the designer defines a

transforma-tion specificatransforma-tion written in TC4MT (Test Case for Model

Transformations) The transformation implementation is then

created manually by the developer as indicated in label 2, or

generated automatically by a HOT transformation as indicated

in label 2a As presented in label 3, we develop a technique

to discover rule dependencies in the TC4MT specification in

order to define test conditions for checking properties of the

transformation implementation From such rule dependencies,

we would construct applicable rule sequences to create test

case descriptions (TCDs) based on selected test criterion

In our approach, TCDs is represented using flattening triple

graph that permits input test conditions and output oracle

specification, as depicted in labels 4.1 and label 4.2, can be

consistently defined All graph patterns representing input test

and oracle specifications basically can be translated into OCL

Boolean expressions which characterizes them The input test

conditions expressed in OCL Boolean expressions, will be

solved by a SAT solver in order to find concrete input models,

as illustrated in label 5

For each checked qualify property, we construct partial

oracle functions specified by OCL assertions, as depicted in

label 6 The transformation implementation will take as input

the input test models and produce output models, as illustrated

in label 7 The output models could be checked using OCL

assertions, resulting a test report, as shown in label 8

In order to demonstrate our approach for testing MTs,

we use a model-to-model transformation CD2RDBM between

UML class diagram models (CD) and relational database

models (RDBM) [11] The source and target metamodels

of the transformation CD2RDBM is shown in Fig 2 The

transformation specification CD2RDBM contains functional

requirements expressed by following transformation rules:

Class2Table (r1) maps classes in a CD model to

cor-responding tables; Att2Column (r2) maps non-primary

at-tributes to columns without the primary key role;

Primary-Att2Column(r3) maps primary attributes to columns that play

the primary key column; MultiToMultiAss2Table (r4) maps

Fig 1 A specification-driven testing framework for model transformations.

Fig 2 The source and target metamodels of the CD2RDBM transformation.

multi-valued aggregation and association to a new associa-tive table that relates the two original tables; SingleToMulti-Ass2Fkey(r5) maps aggregation and association relationships characterized by a single-valued end and a multi-valued end (0 *, 1 *) to a foreign key that relates two original tables; SubClass2Table(r6) maps a subclass to the same table with the parent class; and an optional rule for model refactoring after forward transformation executions InheritanceFlattening (r7) flattens the inheritance hierarchy by copying the parent class’s attributes down to all of the subclasses and removing the superclass from the model

III THETRANSFORMATIONSPECIFICATIONLANGUAGE

TC4MT This section introduces our specification language TC4MT that represents model transformation requirements in terms of triple rules and graph patterns enriched by OCL constraints Figure 3 presents the metamodel of the language TC4MT

In the fact, most transformation implementations for exe-cuting MTs based on TGGs use plain graphs, where graph morphisms mapping between component graphs are encoded

as plain edges This reduces the efforts for implementation,

as developers can reuse existing graph transformation engines and development environments Therefore, we propose to use the plain graph that is the flattening construction to specify transformation rules

Definition 1: (Flattening construction) A triple graph

G = (GS sG

← GC tG

→ GT) has the flattening con-struction defined by the disjoint union G = GS +

GC + GT + LinkS(G) + LinkT (G) with additional

links LinkS(G) = (x, y) | x ∈ GC

V, y ∈ GSV, sG(x) = y , LinkT (G) = (x, y) | x ∈ GC

V, y ∈ GTV, tG(x) = y that implies ∀x | ((x, y) ∈ LinkS) ∨ ((x, y) ∈ LinkT ) ⇔

∃(y1, y2) | (y1∈ GS

V)∧(y2∈ GT

V)∧(sG(x) = y1)∧(tG(x) =

y2))

Definition 2: (Transformation Rule) A rule tr =

(L −→ R, AC) = ((GSL ← GCL → GT L) −→

(GSR ← GCR → GT R), AC) with the rule’s LHS

L = (GSL, GCL, GT L, LinkS(L), LinkT (L)), the rule’s

RHS R = (GSR, GCR, GT R, LinkS(R), LinkT (R)) and

application conditions AC = (N ACSL∪N ACCL∪N ACT L)

includes negative application conditions (NAC) on sub-graph

of the rule’s LHS For specifying transformation rules, we

consider LHS’s sub-graphs as positive application conditions

(PAC) while AC be used to represent NAC

In the specification TC4MT, graph patterns can be used to

represent rule’s sub-graphs, rule’s application conditions, and

other transformation contracts such as preconditions,

postcon-ditions and invariants

Definition 3: (Graph Pattern) A pattern is a tuple P =

(G, C) where G is a typed graph G = (V, E) that contains

a set of object nodes (objects) V and a set of edge links

(references) E; the PatternConstraint C expresses constraint

conditions that the graph G need to fulfill The pattern

constraints are represented in form of either graph patterns

or OCL expressions

Fig 3 The metamodel of the specification language TC4MT.

In order to specify behavior of declarative transformation

rules, we add the marker attribute isT ranslated and the

attribute status for all elements Particularly, the attribute

isT ranslate of elements in rule’s LHS is assigned as true,

and for the remaining ones the attribute is set to false

The attribute status can be used to track the effect of a

rule application on elements It’s value is defined as follows:

status = 0 if the element be unchanged; status = 1 if

the element be newly created; status = 2 if the element be deleted (it belongs to the LHS and does not belong the RHS

of the rule); status = 3 if elements having attributes that are updated (changed) by the rule; status = −2 if the element be represented in the rule’s NACs

Fig 4 The transformation rule PriAttribute2Column in TC4MT.

The key idea of a MT using TGGs is to preserve elements

of LHS and to add the missing elements to create valid triple graph using non-deleting rules [12] However, within the context of QVT [3], model elements should be deleted by transformations Therefore, we extend triple rules by using the integration the attribute status = 2 and isT ranslated = true

to represent elements deleted by a rule For example, the rule InheritanceFlatteningdeletes the parent class and its attributes after copying these attributes down to all sub-classes The author in [9] has formally analyzed the conditions to ensure transformation properties based on TGGs In general, these properties also relate to (non-) applicability, termination and confluence of rule application sequences Our approach

is the discovery of rule dependencies between operational triple rules to find potential applicable rule sequences for constructing test conditions Operational triple rules as well as their application conditions can be derived automatically from declarative triple rules for different transformation scenarios

as shown in Fig 5

Fig 5 Operational rules derived from a declarative triple rule.

IV TESTCASEGENERATION FROM ATC4MT

TRANSFORMATION SPECIFICATION

As regarded in [9], rule dependency relations impact on confluence and termination of rule sequences In this re-search we consider four typical rule dependencies: Produce-Use (PU), Produce-Forbidden (PF), Delete-Forbid (DF), and Delete-Use (DU) between operational TGG rules [13]

Given two declarative triple rules (tr1, tr2): tr1 = (L1 →

R1, N AC1); L1= (GSL

1 , GCL

1 , GT L

1 , LinkSL

1, LinkTL

1);

R1 = (GSR

1 , GCR

1 , GT R

1 , LinkSR

1, LinkTR

1 ); tr2 = (L2 →

R2, N AC2); L2= (GSL2 , GCL2 , GT L2 , LinkS2L, LinkT2L);

R2= (GSR2 , GCR2 , GT L2 , LinkSR2, LinkT2R)

The rule dependencies between two forward rules derived

from two declarative triple rules are defined by following

definitions (rule dependencies of other operational rules are

defined in the similar way)

Definition 4:(Produce-Use (PU)) A PU dependency exists

from a forward rule tr1F to a dependent forward rule tr2F iff

there exist an element y ∈ L2 and an element x ∈ (R1\L1) ∨

(x.status = 1) The pair (x, y) satisfies x.type = y.type or

x.type inherited from y.type

Definition 5: (Delete-Use (DU)) A DU dependency exists

from a forward rule tr1F to a dependent forward rule tr2F iff

there exist an element y ∈ L2 and an element x ∈ (GCL1 ∨

GT L2 ) ∨ (x.status = 2) The pair (x, y) satisfies x.type =

y.type or x.type inherited from y.type

Definition 6: (Produce-Forbid (PF)) A PF dependency

exists from a forward rule trF1 to a dependent forward rule

trF2 iff there exist an element y ∈ N AC2 and an element

x ∈ (R1\L1) ∨ (x.status = 1) The pair (x, y) satisfies

x.type = y.type or x.type inherited from y.type

Definition 7:(Delete-Forbid (DF)) A DF dependency exists

from a forward rule tr1F to a dependent forward rule tr2F iff

there exist an element y ∈ N AC2and an element x ∈ (GCL1 ∨

GT L

2 ) ∨ (x.status = 2) The pair (x, y) satisfies x.type =

y.type or x.type inherited from y.type

To detect rule dependencies, we collect all graph elements

according to their types and update values of attribute

isTrans-lated and status for pattern’s elements of specific operational

rules Comparing element types of graph patterns in

opera-tional rule pairs and checking the attribute value of status

and isT ranslate, we get rule dependencies

Dependent rule pairs also be called critical pairs which

represent the minimal objects where a confluence conflict

may occur The author in [9] discusses rule dependencies

that make minimal conflicts: asymmetric parallel dependencies

that be represented by DU and PF dependencies; asymmetric

sequential dependencies (SD) that represented by PU and DF

dependencies If two rules are sequentially dependent, the

order of their application should be ensured when structuring

chains of applicable rules If two rules are neither sequentially

dependent nor parallel dependent, they are said to be parallel

independent The idea of parallel independent pairs is to create

equivalence rule sequences If the rule pair (tr1, tr2) is parallel

independent, two rule application rule sequences tr1− tr2and

tr2− tr1 are sequential independent

If transformation rules are considered as functional

mod-ules of a transformation program, the analyzing of rule

de-pendencies is a natural approach for the integration system

transformation testing We adapt t − way testing technique

introduced in [14] to construct rule sequence by using combine

strategy guided by rule dependencies We identify four levels

TABLE I

T EST CRITERIA AND POTENTIAL FORWARD RULE SEQUENCES

of specification coverage for the generation test suits: Rules, Closed rules, Rule dependencies, t − way (t > 2)

Rule coverage Rule coverage simply means that a test set explores all operational rules for each particular transformation scenarios For example, the transformation CD2RDBM has seven forward transformation rules, seven TCDs correspond-ing to rule structures are used for the test case generation Closed-rule coverage This criterion extends the previous one by add forward transformation rules without NACs The goal is check whether each particular rule specification is complete and correct Rule’s NACs is often used to restrict the applicability of a rule, which avoids infinite repetition of the rule’s application r3and r7of the CD2RDBM have NACs

r3∗ and r7∗ are forward rules reduced NAC of r3 and r7 Rule dependencies coverage This criterion ensures that all rule dependencies will be considered to construct test cases Combinations of rule pairs based on rule dependencies for design test case can called a pairwise testing situation (t-way testing with t = 2)

t-way coverage T-way testing [14] consists of the genera-tion of test cases for all possible combinagenera-tions of t properties

In this paper, we consider operational triple rules as underlying properties and give coverage levels 3-way, 4-way, , n-way (n > 2) to cover rule sequences of length 3, 4, ,n, respectively The extension of rule combination is necessary to detect potential errors of long complicated transformation scenarios The combination strategy aims to find potential applicable rule sequences as the following algorithm

We create Test Case Descriptions (TCDs) using an approach similar to grammar testing For each rule sequence, firstly a new TCD is created and initialized by the structure of declar-ative triple rule corresponding to the first rule Then, next co-evolution rules corresponding to forward transformation rules

of the rule sequence will be applied to extend TDCs In the case of rule coverage and closed rule coverage, the structure of declarative triple rules will be TCDs The algorithm generating TCDs from potential rule sequences is expressed as follows: Generated TCDs are flattening triple graphs so they can

be used to create input model templates and output model templates In our approach, source graph and target graph

of TCDs will be translated into OCL Boolean expressions

Algorithm 1: Finding potential rule sequences

Input : T R = (tr F

1 , tr F

2 , , tr F ) a set of forward transformation rules

t(t > 2) is an integer indicating the length of rule

sequences

SI is a set of rule sequences satisfying (t − 1) way

coverage, each rule sequence si ∈ SI includes (t − 1) ordered rules.

P I: a set of parallel independent rule pairs

SD: a set of sequential dependent rule pairs

Output: SO: a set of potential rule application sequences, each rule

sequence includes t ordered rules

1 Initialization: SO = ∅ ;

2 while SI is not empty do

3 si ⇐ remove a si from SI;

4 foreach sequential dependent pair sd = (tr F

i , tr F

j ) ∈ SD do

5 if tr F

i ∈ si and N ACtrF

i = ∅ then

6 so ← create new rule sequence so,

7 so = si.add(tr F

j )

9 foreach rule sequence so ∈ SO do

10 if so.including(tr F

i − tr F i+1 ) and (tr F

i , tr F i+1 ) ∈ P I then

11 s ← create a new rule sequence s,

12 s = so.replace(tr F

i − tr F i+1 , tr F i+1 − tr F

i )

SO = SO ∪ {s}

Algorithm 2: Generate test case descriptions from

dependent rule sequences

Input : RSs = A set of dependent rule sequences, each dependent

rule sequence includes ordered forward transformation rules

rs F = (tr F

1 − tr F

2 − − tr F )

rs co = (tr co

1 , tr co

2 , , tr co

n ) is the co-evolution rule sequence of the forward transformation rule sequence

Output: T CDs = Set of test case descriptions

1 while RSs is not empty do

2 rs F ← remove a rs F from RSs;

3 tcd ← create new T CD, initialize the tcd by the structure of

declarative triple rule of first forward transformation rule tr F

1 ;

4 remove tr F

1 from the rs F ;

5 foreach rule triF required by rsF do

6 apply tr co

i on the tcd by a co-evolution transform with parameters added elements by the rule ;

7 remove tr F

i from the rs F ;

8 add tcd to T CDs;

so called Classifying Terms (CTs) [6] to generate concrete

input models using snapshots generator tools or model solving

tools, and used as OCL assertion checking output models For

example, the rule sequence r6 − r3− r3 (r3− r3 is a PF

dependency) creates a TCD as depicted in Fig 6

V TOOLSUPPORT ANDEXPERIMENTALRESULTS

In this section, we present the tool support and some

exper-imental results for testing the transformation CD2RDBM

A Tool Support

The presented framework is supported by a UML

Specifica-tion Environment (USE) [15] which allows building TC4MT

metamodel in form of a class diagram using textual editor,

and support visual interface as well as a textual interface to

create object models presenting TC4MT specifications The

analysis of rule dependencies is executed by comparing the flattening construction of rule specifications Besides, existing TGG interpreter tools such as RTL tool [16] all permit derive operational triple rules from declarative triple rules, and apply co-evolution scenarios to create TCDs The translation from graph patterns to OCL Boolean expressions (CTs) is realized

by a model-to-text transformation using an Acceleo project

on the EMF environment CTs will be put into the Model solving tool (e.g USE model solver [15]) to create input test models After running a MT program under input test models

to create output models, these output models can be checked whether they satisfy CTs expressing OCL assertions using Model Validators (e.g USE validator [15])

B Experiments and Discussion Using the proposed approach for testing MTs, we have some experimental results Firstly, at the test design phase, not all detected rule dependencies yield applicable rule sequences

A possible cause is that a rule depends on several rule-applications, i.e., the rule r1− r4 is not applicable because the rule r4 obligatorily requires at least two applications of the r1 and an application of the r3 to initialize elements in its LHS Besides, attribute constraints on the rule’s elements could also restrict the rule application Statically analyzing reasons why dependent rule sequences are inapplicable help transformation developers to review and complete transfor-mation specification Besides, if a detected rule sequence is applicable to create a TCD, the TCD will be used to test the transformation properties in different strategies

The typical method for checking the syntactical correctness

of forward transformations is to find applicable forward trans-formation sequences and corresponding valid source models, then check the validity of generated target models to make a conclusion about the correctness of forward transformations Particularly, if a TCD G = (GS LinkS←− GC LinkT−→ GT) generated from a co-evolution scenario, the pair (GS,GT)

is consistent with respect to the specification We use the structure of source graph GS as the patterns to generate input models GS they also ensure the satisfaction of preconditons Output models of GS must satisfy both some features defined

by the pattern GT as well as postconditions, and vice versa the correctness is violated

For example, the rule sequence r1−r5−r3−r3can apply to create a TCD in which both sub-class and parent-class have own primary attribute and the first r3 be applied to extend primary attribute for the sub-class before the second r3 be applied to extend primary attribute for the parent class Source graph of this test case description violates the constraint ”a pair

of parent-sub classes has only one primary attribute” while target graph has two pkey columns To deal with situations like this, some negative preconditions as well as rule’s NACs representing unreachable patterns can be considered to add the

MT specification

Besides, the completeness of MTs requires there exist at least one forward transformation sequence that can be ap-plied on a valid source model that terminates and creates a

valid target model Therefore, given any valid input model if

the transformation implementation could not transform it to

corresponding output model, or the transformation program

does not terminate, the violation of completeness property is

determined Valid input models can generated from the pattern

GS of TCDs, or solve precondition constraints on the source

metamodel

In order to check the functional behaviour of forward

transformations, we focus on critical pairs of forward

transfor-mation rules and use them to create test case descriptions in

which these critical pairs are present Using parallel/sequential

independent rules, we can create equivalent rule application

sequences and compare the results of these equivalence we has

conclude about the confluence of the transformation results

The forward transformation execution of all valid input test

models, we have the conclusion about the termination of

the transformation Moreover, exploiting NACs and negative

preconditions for generating robustness tests, we can create

invalid input models to check the termination Rule’s NACs

can cause the transformation program to not terminate or

re-peat indefinitely Experimenting on the forward transformation

CD2RDBM shows that it is termination but not confluence

For testing the information preservation, TCDs included PF

dependencies are used to generate consistent pairs of input

and output models Comparing test results on forward and

backward transformations with the same set of input and

output models, we can give conclusions about the information

preservation of bidirectional model transformations For

exam-ple, we could detect a violation of the information preservation

caused by the rule r3 The rule sequence r6− r3− r3(r3− r3

is a PF dependency) creates a TCD as depicted in Fig 6

While forward transformation testing produces valid target

models matched with the structure of the TCD’s target graph,

corresponding backward transformations from target models

matched with the structure of TCD’s target graph can not finish

to create valid source models

Fig 6 The TCD generated from the rule sequence r 6 − r 3 − r 3

VI CONCLUSION AND FUTURE WORK

In this paper, we have presented the specification language

TC4MT for model-to-model transformations, and its

applica-tion for MT testing The specificaapplica-tion TC4MT expresses trans-formation rules based on TGG rules The formal semantics

of TGGs provides benefits of analyzing quality properties as well as finding corresponding test conditions of these quality properties when testing a transformation implementation Our specification-driven approach aims at testing the intention of the transformation, and ensures that the generated models will allow testing transformation requirements of interest The quality of generated test suite highly relies on how to complete a specification is Therefore, we also provide a set

of test coverage criteria to achieve the complete specification coverage These criteria be used to guide and limit the test generation process in the independent way with transformation implementation languages

In the future, we plan to write HOT (High Order Transfor-mation) transformations that abstract MT implementations are written in a specific transformation language to the TC4MT specifications intend to build black-box benchmark test suites independent of MT languages

REFERENCES [1] B Baudry, T Dinh-Trong, J.-M Mottu, D Simmonds, R France,

S Ghosh, F Fleurey, and Y Le Traon, “Model transformation testing challenges,” 01 2006.

[2] N Kahani, M Bagherzadeh, J Cordy, J Dingel, and D Varro, “Survey and classification of model transformation tools,” 2018.

[3] Meta Object Facility (MOF) 2.0 Query/View/Transformation Specifica-tion, 1st ed Object Management Group, 2016.

[4] G M K Selim, L Lucio, J R Cordy, J Dingel, and B J Oakes,

“Specification and verification of graph-based model transformation properties,” in Graph Transformation - 7th International Conference, ICGT 2014, Held as Part of STAF 2014, York, UK, July 22-24, 2014 Proceedings, H Giese and B K¨onig, Eds Springer, 2014, pp 113–129 [5] F Jouault, F Allilaire, J B´ezivin, and I Kurtev, “ATL: A model transformation tool,” Sci Comput Program., vol 72, no 1-2, pp 31–39, 2008.

[6] F Hilken, M Gogolla, L Burgue˜no, and A Vallecillo, “Testing models and model transformations using classifying terms,” Softw Syst Model., vol 17, no 3, pp 885–912, 2018.

[7] K Lano, S K Rahimi, and S Y Tehrani, “Declarative specification

of bidirectional transformations using design patterns,” IEEE Access, vol 7, pp 5222–5249, 2019.

[8] E Guerra and M Soeken, “Specification-driven model transformation testing,” Software and Systems Modeling, pp 623–644, 2015 [9] F Hermann, H Ehrig, U Golas, and F Orejas, “Formal analysis of model transformations based on triple graph grammars,” Math Struct Comput Sci., vol 24, no 4, 2014.

[10] P.-A M Y L T Franck Fleurey, Benoit Baudry, Qualifying input test data for model transformations, 2009, vol 8.

[11] J B´ezivin, B Rumpe, A Sch¨urr, and L Tratt, “Model transformations

in practice workshop,” J Bruel, Ed., 2005, pp 120–127.

[12] A Sch¨urr, “Specification of graph translators with triple graph gram-mars,” E W Mayr, G Schmidt, and G Tinhofer, Eds., 1994, pp 151– 163.

[13] L Lambers, H Ehrig, and G Taentzer, “Sufficient criteria for appli-cability and non-appliappli-cability of rule sequences,” ECEASST, vol 10, 2008.

[14] Y Lei, R Kacker, D R Kuhn, V Okun, and J Lawrence, “Ipog:

A general strategy for t-way software testing,” in 14th Annual IEEE International Conference and Workshop on Engineering of Computer Based Systems (ECBS) 2007), 26-29 March 2007, Tucson, Arizona, USA,

2007, pp 549–556.

[15] M Gogolla, F B¨uttner, and M Richters, “USE: A uml-based specifica-tion environment for validating UML and OCL,” Sci Comput Program., vol 69, no 1-3, pp 27–34, 2007.

[16] D.-H Dang and M Gogolla, “An OCL-Based Framework for Model Transformations,” VNU Journal of Science: Computer Science and Communication Engineering, vol 32, no 1, pp 44–57, 2016.