On Analyzing Rule-Dependencies to Generate Test Cases for Model Transformations 1st Thi-Hanh Nguyen 2nd Duc-Hanh Dang 3th Quang-Trung Nguyen Dept of Information Technology Dept of Software Engineering, VNU Dept of Software Engineering, VNU Thuongmai University University of Engineering and Technology University of Engineering and Technology Email: trungnq@tmu.edu.vn Email: hanhdd@vnu.edu.vn Email: hanhit@hnue.edu.vn Abstract—Quality model transformations play a key role in the successful realization of Model Driven Engineering in practice In the relational model transformations, rule dependency relations directly impact quality properties such as correctness, completeness, and information preservation The analysis of rule dependencies from the declarative specification is expected to bring advantages for testing transformation properties In this paper, we proposed a black-box approach for testing relational model transformations based on the analysis of the declarative specification using Triple Graph Grammar (TGG) rules We exploit declarative TGG rules to capture the rule dependencies Then, rule dependencies are combined together using the t-way testing technique to create test case descriptions We transform patterns representing the input test condition and the oracle function of a test case description into OCL (Object Constraint Language) constraints to facilitate automatically generating input test models by solving constraints and querying interesting properties on the output models Index Terms—Model Transformation, Triple Graph Grammar I I NTRODUCTION Model transformations are the pillars of Model-Driven Engineering (MDE), so quality model transformations play a key role in the successful realization of MDE in practice Testing is the popular quality assurance technique for model transformations, since it is lightweight, automatize and can easily uncover bugs Testing model transformations poses two main challenges [1]: the automatic generation of quality input test models and the definition of oracle functions Firstly, input test models have a complex structure (with data and behavior) which must conform to a meta-model and satisfy constraints by transformation requirements Recent approaches to the automatic generation of input test models often adapt standard testing techniques, which try to generate test cases with guaranteed coverage The work in [2] proposes the use of source meta-model coverage to generate valid input test models while transformation properties are not considered Several black-box testing approaches [3], [4] use transformation requirements expressed by pre-conditions and invariants to generate input test models to achieve the transformation specification coverage Besides, the white-box testing approach proposed in [5] exploits operational rules in order to construct an effective meta-model for generating input 978-1-7281-3003-3/19/$31.00 ©2019 IEEE test models in a restricted modeling space Within current transformation approaches, transformation requirements often are specified in form of declarative rules expressed in a transformation language Declarative rules should be analyzed for the testing purpose, as discussed in [6] However, such an analysis of declarative rules has not yet covered several other aspects of transformations such as analyzing rule dependency for complex rules attached with constraints Secondly, oracle functions are used to check output models generated from a set of input test models through a transformation implementation Because models are complex data, building output models and comparing output models manually with expected output models are very difficult and time-consuming [7] Recent approaches often focus on specifying expected properties on output models by using OCL constraints that are captured from the transformation specification [3], [4], [6] Besides, the author in [8] formally proves that quality properties (correctness, completeness, information preservation) are directly impacted by rule dependencies in a relational model transformation Triple Graph Grammar (TGG) is an important representation of relational model transformations [9] In this paper, we propose a testing approach for relational model transformations based on rule dependencies Firstly, we analyze the structure of declarative TGG rules to detect possible derived rule dependencies For the test case selection, we define test criteria based on rules and rule dependencies to create Test Case Descriptions (TCDs) Each TCD is a triple graph built by executing a dependent rule sequence Next, we transform (source, target) graph patterns of the TCD into OCL constraints that represent input test conditions and oracle functions for testing different transformation scenarios Expressing input test conditions and oracle functions by OCL expressions, we can automatically generate test models and check output models by using constraint solver tools We summarize our contributions as follows: • A systematic approach to discover rule dependencies from a declarative transformation specification using TGG rules • A test case generation method based on rule-dependency coverage for testing model transformations The rest of this paper is structured as follows Section II introduces a running example Section III briefly describes our approach overview for testing model transformations using rule-dependencies We show how to find rule dependencies from declarative TGG rules in Sect IV, and provide a method of test case generation from rule dependencies in Sect V Section VI presents our tool support and experiment results We present related works in Sect VII, and give the conclusion in Sect VIII II RUNNING EXAMPLE To illustrate our proposals for testing model transformations, we focus on a transformation situation between UML Class Diagram (CD) and Relational Database Models (RDS) This example is a simplified version of the CD2RDS transformation introduced in [8] The transformation specification CD2RDS includes the following requirements (r1 ) Class2Table: Mapping a class to a table with the same name (r2 ) Attribute2Column: Mapping a non-primary attribute to a column with the same name and same datatype (r3 ) PrimaryAttribute2Column: Mapping a primary attribute to a column that plays the primary key (r4 ) Association2Table: Mapping an association to a table with the same name (r5 ) SubClass2Table: Mapping a subclass to the same table with the parent class Within transformation approaches based on Triple Graph Grammar [9] (TGG), declarative rules are employed to specify the consistency of source and target models and track interrelationships between model elements explicitly The solid mathematical foundation and graph-based concepts of TGGs enable users to specify model transformation rules in a declarative, high-level and graphical manner Figure represents TGG rules of the transformation CD2RDS TGG rules can be complemented with additional information to express application conditions that should be satisfied to enable the rule application execution, and constraints on attribute values of model elements, as well as to constrain when a certain source-target relation should hold The OCL standard is frequently used for this purpose [3], [4] Accordingly, we proposed a model transformation language named Restricted Transformation Language (RTL) [10] The RTL language uses TGG rules incorporating OCL expressions to specify bidirectional model transformations The basic characteristics of model transformations with the RTL language include: (i) supporting unidirectional forward and backward operational rules derived from a single RTL specification, (ii) an algorithm to control which rule be applied on which part of a given input graph, and (iii) an incorporation of OCL in TGGs makes increasing the expressiveness of TGGs for complex model transformations The graphical and textual formats of an RTL rule are described in Fig In the concrete syntax Fig 2(a), the source, target, and correspondence graphs of the triple rule are recognized by the keywords ‘checkSource’, ‘checkTarget’, and ‘checkCorr’ Each graph includes two parts corresponding to the LHS enclosed in parentheses ‘(’ and ‘)’ and the RHS Fig Mapping rules of the transformation CD2RDS a) Declarative RTL rule b) Graphical RTL rule Fig The graphical and textual presentation of a rule RTL (transform a non-primary attribute to a column) grouped by braces ‘’ and ‘’ of a rule In the graphical format Fig 2(b), elements created by a triple rule only appear on the RHS which are marked with ++ Besides, Negative Application Conditions (NACs) (i.e., lines 47-48 and lines 5657 for the forward and backward transformation, respectively) present forbidden structures on the rule’s LHS [10] Transformation approaches based on TGG often use nondeleting rules [9], but some complex transformations with deleting TGG rules can be used in the MDE The RTL language [10] permits specifying both deleting and non-deleting TGG rules The transformation CD2RDS (Fig 1) includes non-deleting TGG rules Model transformations with TGG rules are executed by using operational TGG rules derived from declarative TGG rules for different transformation scenarios As shown in [8], [11], rule dependencies between operational TGG rules can raise conflicts in a rule sequence and make potential problems related to transformation properties (correctness, completeness, information preservation) As a result, the analysis of rule dependencies can facilitate to detect problems of transformation properties Black-box testing is an effective technique for uncovering errors based on transformation specifications The analysis of possible derived rule dependencies from declarative rules is thus an expected black-box approach to provide the basis for testing transformation properties from the specification phase III A PPROACH OVERVIEW Our approach overview for model transformation testing is shown in Fig Fig Overview of the testing approach First, we analyze the declarative transformation specification to find possible derived-rule dependencies (called rule dependencies for the short) Then, based on a selected test criterion guided by the t-way testing technique [12], we combine pairs of rule dependencies to create dependent rule sequences A Test Case Description (TCD) is a triple graph created by executing a col-evolution transformation scenario with a dependent rule sequence on the host graph assigned by the structure of the first rule In the case of testing forward (w.r.t backward) transformations, source (w.r.t target) graph of a TCD is used as the test condition to generate input models, target (w.r.t source) graph are used as the expected pattern to define the oracle function Expressing test conditions and expected patterns by OCL Boolean Expressions so called Classifying Terms (CTs) [4], we automate the test process in the testing framework as introduced in [13] The testing framework takes input test conditions to generate input models, transforms input models into output models by the transformation implementation, and finally check output models by the oracle function to create the test report IV T HE ANALYSIS OF RULE D EPENDENCIES Model transformations are executed by operational rule sequences for forward/backward/integration/co-evolution transformation scenarios A transformation program includes a arbitrary sequence of operational TGG rules A rule sequence is applicable if one rule after the other is applicable starting with a host graph This implies that elements in the LHS of each rule in a rule sequence must be available in the initial host graph or be produced by previous rules in the rule sequence In model transformations, operational rules are automatically derived from declarative TGG rules Therefore, the analysis of dependencies between declarative TGG rules can early detect possible dependencies of operational rules For instance, a derived rule application of the rule r1 (Class2Table) creates a triple graph that includes an object of the type Class, an object of the type Table and an object of the C2T These objects are required in the LHS of operational rules derived from the rule r3 (PrimaryAttribute2Column) Therefore, there exists a rule dependency between r1 and r3 Using the concrete syntax of TGG rules, dependency relations are easily detected by checking object types There are four dependency relations (produce-use, produceforbidden, delete-forbidden, and delete-use) between operational TGG rules [11] The delete-forbidden and delete-use dependencies are dedicated for the deleting TGG rules In the scope of this paper, we only focus on model transformations with non-deleting TGG rules Based on definitions of rule dependencies between operational TGG rules in [11], we give definitions of produce-use and produce-forbidden dependencies between declarative non-deleting TGG rules Given two TGG rules enriched with OCL conditions specified by the RTL language [10]: p1 = (L1 , R1 , AC1 ) = (GSL ← GCL → GT1 L , GSR ← GCR → GT1 R , AC1 ), 1 1 SL CL p2 = (L2 , R2 , AC2 ) = (G2 ← G2 → GT2 L , GSR ← GCR → GT2 R , AC2 ), each rule consists a triple graph L = (GSL , GCL , GT L ) in its LHS and a triple graph R = (GSR , GCR , GT R ) in its RHS Each graph includes a set of elements (nodes, links) specified two properties type and name Application Condition (AC) expressions of a rule can be positive or negative The author [8] shows that most conflicts of a rule sequence are made by Negative Application Conditions (NACs) on the rule’s LHS (NACLHS = NAC SL ∪ NAC CL ∪ NAC TL ), thus in this paper we focus on NACs to detect rule dependencies Each NAC is expressed by a graph pattern GP and a formula α over their elements, i.e., NAC SL = (GP SL , α) The produce-use and produce-forbidden dependencies are defined as follows: Definition 4.1 (Produce-use dependency) A produceuse dependency exists from a required TGG rule p1 to a dependent rule p2 , iff there exists x ∈ (G2SL ∨ G2CL ∨ G2TL ), y ∈ (G1SR \G1SL ) ∨ (G1CR \G1CL ) ∨ (G1TR \G1TL ) t and x.type = y.type It is denoted p1 → p2 Definition 4.2 (Produce-forbidden dependency) A produceforbidden dependency exists from a required RTL rule p1 to a dependent rule p2 , iff there exists x ∈ (GP2SL ∨ GP2CL ∨ SL CR CL TR TL GP2T L ), y ∈ (GSR \G1 ) ∨ (G1 \G1 ) ∨ (G1 \G1 ) and t x.type = y.type It is denoted p1 → p2 To detect produce-use dependencies, we analyze declarative rules by collecting all graph elements (nodes, links) according to their types as presented in Table I Collected elements are divided into subsets LHS and RHS\LHS (denoted ++) of source, target, and corresponding graphs TABLE I S TRUCTURAL ELEMENTS OF TGG RULES LHS r1 r2 c1:Class, c2t1:C2T, t1:Table r3 c1:Class, c2t1:C2T, t1:Table, r4 r5 c1:Class, c2:Class, t1:Table, t2.Table, co1:Column, co2:Column, c2t1:C2T, c2t2:C2T, (t1, col1):pkey, (t1, col1):cols, (t2, col2):pkey, (t2, col2):cols c1:Class, c2t1:C2T, t1:Table ++ c1:Class, c2t1:C2T, t1:Table a1:Atribute, a2c1:A2C, co1:Column,(c1, a1): attrs, (t1, col1): cols a1:Atribute, a2c1:A2C, co1:Column, (c1, a1): attrs, (t1, col1): cols, (t1, col1): pkey ass1:Association, ass2t:ASS2T, t3:Table, co3:Column, co4:Column, fk1:Fkey, kf2:FKey, (ass1, c1): src, (ass1, c2): dest, (fk1, col3): fcols, (t3, fk1): fkeys, (t3, fk2): fkeys, (fk1, t1): references, (fk2, t2): references c2:Class, c2t2:C2T, (c2, c1): inheritance Comparing elements TABLE II P RODUCE - USE DEPENDENCIES in the LHS and Rule r1 r2 r3 r4 r5 (RHS\LHS) of rule r1 0-0-0 1-1-1 1-1-1 2-2-2 1-1-1 r2 0-0-0 0-0-0 0-0-0 0-0-2 0-0-0 pairs based on the r3 0-0-0 0-0-0 0-0-0 0-0-2 0-0-0 existence of element r4 0-0-0 0-0-1 0-0-1 0-0-2 0-0-1 r5 0-0-0 1-1-0 1-1-0 2-2-0 1-1-0 types, produce-use dependencies are detected In table II, the first row contains dependent rules that depend on rules in the first column Three numbers of a number-string in each cell represent produce-use relations between source, corresponding, and target graphs of each rule pair The value denotes a dependency while the value denotes a non-dependency In some cases, a rule is activated only when another rule be applied several times, i.e., the rule r4 includes two elements of the C2T type in its LHS that be created by applying rule r1 two times Therefore, the rule r4 really depends on a rule sequence r1-r1 This case can be detected by comparing the number of elements with the same type in the LHS and RHS\LHS of two rules We denote the maximum number of applications of a rule to create dependent elements for the dependent rule The numbers in cells of the Table II denote this case While produce-use dependencies are detected by comparing the structure of plain-graphs, the produce-forbidden dependencies are detected by the analysis of NAC expressions In RTL language, we express NACs (lines 47-48, 56-57 in Fig (a)) using the following prototype: not type1.allInstances–>forAll(o1| typeN.allInstances–>forAll(oN| conditions(o1, ,oN))) We compare object types captured from NAC expressions and object types of the graph structure of rules to detect produce-forbidden dependencies using Definition 4.2 In the transformation CD2RDS, the rule r3 contains NACs, so there exist produce-forbidden dependencies between r3 and other rules as in Table III After rule dependencies are detected, they will be used to generate test cases in the next section TABLE III PRODUCE - FORBIDDEN DEPENDENCIES Rule r1 r2 r3 r4 r5 r1 0-0-0 0-0-0 0-0-0 0-0-0 0-0-0 r2 0-0-0 0-0-0 0-0-0 0-0-0 0-0-0 r3 0-0-0 1-0-1 1-0-1 0-0-1 0-0-0 r4 0-0-0 0-0-0 0-0-1 0-0-0 0-0-0 r5 0-0-0 0-0-0 0-0-0 0-0-0 0-0-0 V T EST CASE GENERATION In this section, we define test criteria to guide the test case selection in SubSect V-A, and propose an approach to generate test case descriptions in SubSect V-B A Test criteria For detecting conflicts that may appear in other transformation scenarios, we construct test cases covering all rule dependencies of declarative TGG rules TABLE IV T EST CRITERIA AND RULE SEQUENCES Most faults in 1-way 2-way 3-way software systems r1 r1 -r2 , r1 -r3 , r1 -r1 -r4 r1 -r2 -r2 -r4 r2 r1 -r5 , r2 -r2 -r4 r1 -r3 -r3 -r4 are due to the r2 r3 -r3 -r4 , r4 -r2 , r4 -r3 r1 -r1 -r4 -r2 interaction of several r4 r4 -r4 -r4 , r4 -r5 , r5 -r2 r1 -r5 -r2 r5 r5 -r3 , r5 -r5 -r4 ,r5 -r5 r1 -r5 -r3 properties Based (produce-forbidden) r2 -r3 , r3 -r3 , r4 -r3 on this observation, t-wise testing [12] consists of the generation of test cases for all possible combinations of t properties In this paper, we consider declarative rules as underlying properties of the transformation testing We give following coverage criteria: 1-way (rule coverage), 2-way (rule-dependency coverage), and n-way with n>2 (rule-sequence coverage from the combination of n − rule dependencies) Table IV represents rule combinations for different testing coverage levels The extension of rule combinations is necessary to detect potential errors of complex transformation scenarios In our approach, the combination strategy presents the subsumption relationship between the test criteria The 1-way criterion is the weakest coverage level The context-dependent feature of TGG rules ensures that a TGG rule appears at least one in rule-dependent pairs, so the 2-way criterion includes 1-way criterion Similarly, each t-way rule sequence is made by the combination of (t-1)-way rule sequence and a rule-dependency this makes the including relation between test criteria Test criteria are sorted from the weakness to strength as follows: (1 − way) → (2 − way) → → (t − way) B Test case description In MDE, graph grammars can be used to generate (test) models [14] and develop test oracles Similarly, we use the TGG-based test case generation by executing dependent rule sequences to create Test Case Descriptions (TCDs) For each rule sequence, firstly a new TCD is created and initialized by the structure of the first rule Then, next rules be alternately added to the TDC by applying a co-evolution scenario For example, the rule sequence r1 − r2 will generates a TCD that is also the structure of rule r2 in the Fig The algorithm generating TCDs is expressed as follows: Algorithm 1: Generate test case descriptions from dependent rule sequences Input : RSs = A set of dependent rule sequences, each dependent rule sequence includes ordered TGG rules RS = (p1 , p2 , , pn ) Output: T CDs = Set of test case descriptions while RSs is not empty rs ⇐ remove a RS from RSs; tcd ⇐ create new T CD, initialize the tcd by the first rule p1 ; remove p1 from the rs; foreach rule pi required by rs apply pi on the tcd by a co-evolution transform with parameters that are names of added elements by the rule ; romove pi from the rs; a TCD is generated by applying a co-evolution scenario using the RTL tool [10], patterns for input / output test conditions are transformed into OCL Boolean Expression so-called Classifying Terms (CTs) [4] by using EMF-based prototype tool Besides, the testing process is executed by the RTL framework that is available as a plugin on USE [13] This takes as input the specification files of meta-models (in USE’s syntax), transformation rules (textual RTL rules), source (w.r.t target) CTs and target (w.r.t source) CTs for testing forward (w.r.t backward ) transformations, and the Model Validator configuration, all of which are plain text files If the validation process completes successfully, a test report is returned add tcd to T CDs; B Experimental results Each TCD is a triple graph including source, target, and corresponding graphs used to generate test cases for testing forward (w.r.t.backward) transformations The source (w.r.t target) graph represents the interesting structure and properties of source (w.r.t target) models, and the target (w.r.t source) graph represents the interesting structure and properties of target (w.r.t source) models We consider these graphs as patterns for generating input test models and oracle functions We use the following OCL template to translate patterns into OCL expressions, similar to the approach in [3] o1.type::allInstances()–>exists(o1| oi.type::allInstances()–>exists(oi| conditions(o1, ,oi))) Example The source graph of the TCD corresponding to the rule sequence r1 –> r2 is expressed as follows: Class.allInstances()–>exists(c| Attribute.allInstances()–>exists(a| a.isPrimary=true and c.attr–>includes(a))) For translating a pattern into an OCL expression, we iterate on all objects of a (source/target) graph The function conditions is an OCL expression that should be fulfill of all traversed objects of the graph in which the links are specified in the invariants oi.link–> includes(oj), the inequality of the objects with same type is expressed by conditions oi oj In our approach, there exist some benefits for checking output models: (1) Expected outputs expressed in OCL conditions can be used as oracle functions to query properties on real output models; (2) Output conditions can be used similar to input conditions for testing backward transformations of bidirectional model transformations; (3) Both input and output conditions are expressed in Boolean OCL expressions called Classifying Term (CT) [4] that can be used to automatically generate the input models and expected output models in case of oracle checking by model comparison VI T OOL S UPPORT AND E XPERIMENTAL R ESULTS In this section, we introduce the tool support and experimental results for testing the CD2RDS transformation A Tool support This section presents our implementation to test model transformations based on the declarative specification While Using rule dependencies in the testing process of model transformations, we have experimental results 1) Test case design: At the test design phase, not all detected rule dependencies yield applicable rule sequences A possible cause is that a rule depends on several ruleapplications, i.e., the rule r1 –> r1 –> r4 is not applicable because the rule r4 obligatorily requires the application of the r3 to initialize elements in its LHS Another cause may be all OCL conditions of a rule preventing the applicability of another rule Statically analyzing reasons why dependent rule sequences are inapplicable help transformation developers to review and complete transformation specification If a dependent rule sequence is applicable to create a TCD, the TCD will be used to test the transformation properties As shown in [8], the syntactical correctness and completeness of model transformations are impacted by the produce-use dependencies, while the information preservation are impacted by the produce-forbidden dependencies From this basis, we preferentially use test cases generated from different dependencies for different transformation properties 2) Checking the correctness and completeness properties: We generate test cases from the single rules and combinations of rules using t-way testing technique Source CTs and target CTs created from TCDs are used to check the existence of output models (check the completeness property) and the correctness of generated output models (check the correctness property) by using the testing framework [13] Experimenting on the CD2RDS transformation with TCDs satisfying different coverage levels, we have the following result Test cases for r4 at the 1-way level, r4 − r3 , r4 − r4 − r4 , r4 − r5 at 2-way level are false because of invalid target models (violation the correctness property) We recognize that all these rule dependencies include rule r4 , the potential problem is that the rule r4 does not specify the adequate structure between source and target graph or lack of applicable conditions Similarly, practicing with rule sequences in the 3way, 4-way, levels, potential error can be uncovered 3) Checking the information preservation property: For testing the information preservation, the source and target CTs created from produce-forbidden dependencies are used as the pair of consistency constraints on the source models and corresponding target models Comparing test results on forward and backward transformations with the same set of source and target CTs using support tool introduced in [13], we can give conclusions about the information preservation of bidirectional model transformations By experimenting on the CD2RDS transformation, we could detect a violation of the information preservation caused by the rule r3 The rule sequence r5 − r3 − r3 (r3 − r3 is a produce-forbidden dependency) creates a TCD as depicted in Fig While forward transformation testing produces target models that satisfy the target CT of the TCD, the backward transformation testing can not finish because generated target models satisfy the target CT containing the rule structure r3 that is also be the NAC of any applicability of r3 the transformation requirements to generate test cases similar to [3] [4], but we focus on the transformation requirements represented in declarative rules at the lower level specification We extend the proposal in [6] by considering both produce-use and produce-forbidden dependencies between more complex declarative TGG rules for generating test cases VIII C ONCLUSION AND FUTURE WORK The analysis of declarative rules can be used to find possible derived rule dependencies for checking transformation properties In this paper, we provide an approach to analyze ruledependencies implicitly presented in RTL rules and generate test cases targeting these dependencies based on t-way testing technique The input model generation and output model checking are automatically executed with OCL support tools such as the USE framework and USE model validator [15] In future work, delete-use and delete-forbidden dependencies can be discovered for testing complex model transformations R EFERENCES Fig The TCD generated from the rule sequence r5 − r3 − r3 Discussion The main threat to the validity of our evaluation is that we have only discovered rule dependencies based on the graph structure without considering constraint conditions VII R ELATED WORK Existing proposals for test case generation often employ a black-box approach that relies on coverage of the metamodel [2] or the transformation requirements [3], [4] The authors in [3] use graph patterns representing transformation requirements (pre-/postconditions and invariants), and translate them into OCL expressions to automatically generate test cases Similarly, the authors in [4] use OCL Boolean expressions named Classifying Terms to represent requirements for generating test cases For the black-box testing approach based on the low-level specification, the work [6] proposes the analysis of produceuse dependencies between declarative TGG rules to create TCDs Unfortunately, the authors has not yet shown how to generate input models and oracle functions from TCDs, and the proposed approach is performed on well-formlessness TGG rules with some assumptions In order to specify and implement model transformations, we propose an OCL-based framework using the formal foundation of the TGG integrated with the OCL language presented in [10] and discuss the supporting ability of the framework for testing model transformations without given specific testing techniques In [13], we propose an approach for model transformation testing ensuring the meta-model coverage criteria similar to the work in [2] In this paper, we also consider [1] B Baudry, T Dinh-Trong, J.-M Mottu, D Simmonds, R France, S Ghosh, F Fleurey, and Y L Traon, “Model Transformation Testing Challenges,” p 11, 2006 [2] F Fleurey, B Baudry, P Muller, and Yves Le Traon, “Qualifying input test data for model transformations,” Software and System Modeling, vol 8, no 2, pp 185–203, 2009 [3] E Guerra and M Soeken, “Specification-driven model transformation testing,” Software and System Modeling, vol 14, no 2, pp 623–644, 2015 [4] F Hilken, M G andLoli Burgue˜no, and A Vallecillo, “Testing models and model transformations using classifying terms,” Software and System Modeling, vol 17, no 3, pp 885–912, 2018 [5] J M Kăuster and M Abd-El-Razik, Validation of model transformations - first experiences using a white box approach,” in Proc 9th Int Conf Model-Driven Engineering Languages and Systems (MoDELS), 2006, pp 193–204 [6] S Hildebrandt, L Lambers, and H Giese, “Complete specification coverage in automatically generated conformance test cases for TGG implementations,” in Proc 6th Conf Theory and Practice of Model Transformations (ICMT), 2013, pp 174–188 [7] J Mottu, B Baudry, and Y L Traon, “Model transformation testing: oracle issue,” in Proc 1st Int Conf on Software Testing Verification and Validation (ICST), 2008, pp 105–112 [8] F Hermann, H Ehrig, U Golas, and F Orejas, “Formal analysis of model transformations based on triple graph grammars,” Mathematical Structures in Computer Science, vol 24, no 4, 2014 [9] A Schăurr, “Specification of graph translators with triple graph grammars,” in Proc 20th Int Conf Graph-Theoretic Concepts in Computer Science (WG), 1994, pp 151–163 [10] 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 [11] L Lambers, H Ehrig, and G Taentzer, “Sufficient criteria for applicability and non-applicability of rule sequences,” ECEASST, vol 10, 2008 [12] Y Lei, R Kacker, D R Kuhn, V Okun, and J Lawrence, “IPOG: A general strategy for t-way software testing,” in Proc 14th Int Conf Engineering of Computer Based Systems (ECBS), 2007, pp 549–556 [13] T Nguyen and D Dang, “An approach for testing model transformations,” in Proc 10th Int Conf International Conference on Knowledge and Systems Engineering (KSE), 2018, pp 264269 [14] L Făurst, M Mernik, and V Mahnic, “Converting metamodels to graph grammars: doing without advanced graph grammar features,” Software and System Modeling, vol 14, no 3, pp 1297–1317, 2015 [15] M Kuhlmann, L Hamann, and M Gogolla, “Extensive validation of OCL models by integrating SAT solving into USE,” in Proc 49th Int Conf Objects, Models, Components, Patterns (TOOLS), 2011, pp 290– 306 ... properties on real output models; (2) Output conditions can be used similar to input conditions for testing backward transformations of bidirectional model transformations; (3) Both input and output conditions... [13] The testing framework takes input test conditions to generate input models, transforms input models into output models by the transformation implementation, and finally check output models... additional information to express application conditions that should be satisfied to enable the rule application execution, and constraints on attribute values of model elements, as well as to constrain