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[.]

2021 8th NAFOSTED Conference on Information and Computer Science (NICS) 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 modeldriven 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 I NTRODUCTION 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 modeldriven 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 different transformation languages, that can be divided into four paradigms [2]: relational/declarative languages, e.g., QVT- 978-1-6654-1001-4/21/$31.00 ©2021 IEEE relation [3]; imperative/operational languages, e.g., QVTo [3]; graph-based languages, e.g., DSLTrans [4]; and hybrid languages, e.g., ATL [5] Like programs testing MTs at implementation 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 Specificationbased 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 metamodelbased 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 224 2021 8th NAFOSTED Conference on Information and Computer Science (NICS) 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 transformation testing Section III introduces our specification 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 S PECIFICATION -D RIVEN T ESTING F RAMEWORK FOR T RANSFORMATIONS Figure outlines our approach for testing MTs First, as shown in label 1, the designer defines a transformation specification 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 For each checked qualify property, we construct partial oracle functions specified by OCL assertions, as depicted in label The transformation implementation will take as input the input test models and produce output models, as illustrated in label The output models could be checked using OCL assertions, resulting a test report, as shown in label 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 The transformation specification CD2RDBM contains functional requirements expressed by following transformation rules: Class2Table (r1 ) maps classes in a CD model to corresponding tables; Att2Column (r2 ) maps non-primary attributes to columns without the primary key role; PrimaryAtt2Column (r3 ) maps primary attributes to columns that play the primary key column; MultiToMultiAss2Table (r4 ) maps Fig A specification-driven testing framework for model transformations Fig The source and target metamodels of the CD2RDBM transformation multi-valued aggregation and association to a new associative table that relates the two original tables; SingleToMultiAss2Fkey (r5 ) maps aggregation and association relationships characterized by a single-valued end and a multi-valued end (0 *, *) 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 T HE T RANSFORMATION S PECIFICATION L ANGUAGE 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 presents the metamodel of the language TC4MT In the fact, most transformation implementations for executing 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 225 2021 8th NAFOSTED Conference on Information and Computer Science (NICS) Definition 1: (Flattening construction) A triple graph tG sG GT ) has the flattening conGC → G = (GS ← struction defined by the disjoint union G = GS + GC + GT + LinkS(G) + LinkT (G) with additional  S links LinkS(G) = (x, y) | x ∈ GC V , y ∈ GV , sG (x) = y , T LinkT (G) = (x, y) | x ∈ GC that V , y ∈ GV , tG (x) = y implies ∀x | ((x, y) ∈ LinkS) ∨ ((x, y) ∈ LinkT ) ⇔ ∃(y1 , y2 ) | (y1 ∈ GSV )∧(y2 ∈ GTV )∧(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 AC SL ∪N AC CL ∪N AC T 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, postconditions 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 the element be newly created; status = if the element be deleted (it belongs to the LHS and does not belong the RHS of the rule); status = if elements having attributes that are updated (changed) by the rule; status = −2 if the element be represented in the rule’s NACs Fig 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 = and isT ranslated = true to represent elements deleted by a rule For example, the rule InheritanceFlattening deletes 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 Fig The metamodel of the specification language TC4MT Fig Operational rules derived from a declarative triple rule 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 = if the element be unchanged; status = if IV T EST C ASE G ENERATION FROM A TC4MT TRANSFORMATION SPECIFICATION As regarded in [9], rule dependency relations impact on confluence and termination of rule sequences In this research we consider four typical rule dependencies: ProduceUse (PU), Produce-Forbidden (PF), Delete-Forbid (DF), and Delete-Use (DU) between operational TGG rules [13] 226 2021 8th NAFOSTED Conference on Information and Computer Science (NICS) Given two declarative triple rules (tr1 , tr2 ): tr1 = (L1 → CL TL L L R1 , N AC1 ); L1 = (GSL , G1 , G1 , LinkS1 , LinkT1 ); SR CR TR R R R1 = (G1 , G1 , G1 , LinkS1 , LinkT1 ); tr2 = (L2 → CL TL L L R2 , N AC2 ); L2 = (GSL , G2 , G2 , LinkS2 , LinkT2 ); SR CR TL R R R2 = (G2 , G2 , G2 , LinkS2 , LinkT2 ) 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 ∈ (GCL ∨ GT2 L ) ∨ (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 tr1F to a dependent forward rule tr2F 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 AC2 and an element x ∈ (GCL ∨ GT2 L ) ∨ (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 isTranslated and status for pattern’s elements of specific operational rules Comparing element types of graph patterns in operational 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 − tr2 and tr2 − tr1 are sequential independent If transformation rules are considered as functional modules of a transformation program, the analyzing of rule dependencies 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 corresponding 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 r3 and r7 of 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 generation of test cases for all possible combinations 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 declarative triple rule corresponding to the first rule Then, next coevolution 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 227 2021 8th NAFOSTED Conference on Information and Computer Science (NICS) 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]) Algorithm 1: Finding potential rule sequences F) (tr1F , tr2F , , trn 10 11 12 Input : T R = 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 Initialization: SO = ∅ ; while SI is not empty si ⇐ remove a si from SI; foreach sequential dependent pair sd = (triF , trjF ) ∈ SD if triF ∈ si and N ACtrF = ∅ then i so ← create new rule sequence so, F so = si.add(trj ) SO = SO ∪ {so} B Experiments and Discussion foreach rule sequence so ∈ SO F ) and (tr F , tr F ) ∈ P I then if so.including(triF − tri+1 i i+1 s ← create a new rule sequence s, F F F s = so.replace(tri − tri+1 , tri+1 − triF ) 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 F) rsF = (tr1F − tr2F − − trn co ) is the co-evolution rule rsco = (tr1co , tr2co , , trn sequence of the forward transformation rule sequence Output: T CDs = Set of test case descriptions while RSs is not empty rsF ← remove a rsF from RSs; tcd ← create new T CD, initialize the tcd by the structure of declarative triple rule of first forward transformation rule tr1F ; remove tr1F from the rsF ; foreach rule triF required by rsF apply trico on the tcd by a co-evolution transform with parameters added elements by the rule ; remove triF from the rsF ; 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 V T OOL S UPPORT AND E XPERIMENTAL R ESULTS In this section, we present the tool support and some experimental results for testing the transformation CD2RDBM A Tool Support The presented framework is supported by a UML Specification 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 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 ruleapplications, 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 transformation 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 transformation sequences and corresponding valid source models, then check the validity of generated target models to make a conclusion about the correctness of forward transformations LinkS LinkT Particularly, if a TCD G = (GS ←− GC −→ 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 −r3 can 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 applied on a valid source model that terminates and creates a 228 2021 8th NAFOSTED Conference on Information and Computer Science (NICS) 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 transformation 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 repeat 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 example, 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 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 The TCD generated from the rule sequence r6 − r3 − r3 VI C ONCLUSION 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 specification TC4MT expresses transformation 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 Transformation) 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 R EFERENCES [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 Specification, 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 113129 [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 [11] J Bezivin, B Rumpe, A Schăurr, and L Tratt, “Model transformations in practice workshop,” J Bruel, Ed., 2005, pp 120127 [12] A Schăurr, Specification of graph translators with triple graph grammars,” E W Mayr, G Schmidt, and G Tinhofer, Eds., 1994, pp 151– 163 [13] L Lambers, H Ehrig, and G Taentzer, “Sufficient criteria for applicability and non-applicability 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 549556 [15] M Gogolla, F Băuttner, and M Richters, “USE: A uml-based specification 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 229 ... (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... 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... 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,