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..
Trang 1On Analyzing Rule-Dependencies to Generate Test
Cases for Model Transformations
1st Thi-Hanh Nguyen
Dept of Software Engineering, VNU
University of Engineering and Technology
Email: hanhit@hnue.edu.vn
2nd Duc-Hanh Dang Dept of Software Engineering, VNU University of Engineering and Technology Email: hanhdd@vnu.edu.vn
3th Quang-Trung Nguyen Dept of Information Technology Thuongmai University Email: trungnq@tmu.edu.vn
Abstract—Quality model transformations play a key role in
the successful realization of Model Driven Engineering in
prac-tice 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
gen-erating input test models by solving constraints and querying
interesting properties on the output models
Index Terms—Model Transformation, Triple Graph Grammar
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
gen-erate 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 mod-els generated from a set of input test modmod-els 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 prop-erties (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
Trang 2our 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
interrela-tionships between model elements explicitly The solid
mathe-matical foundation and graph-based concepts of TGGs enable
users to specify model transformation rules in a declarative,
high-level and graphical manner Figure 1 represents TGG
rules of the transformation CD2RDS
TGG rules can be complemented with additional
informa-tion to express applicainforma-tion condiinforma-tions 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
char-acteristics 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 2 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 1 Mapping rules of the transformation CD2RDS.
a) Declarative RTL rule
b) Graphical RTL rule
Fig 2 The graphical and textual presentation of a rule RTL (transform a non-primary attribute to a column).
Trang 3grouped 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
56-57 for the forward and backward transformation, respectively)
present forbidden structures on the rule’s LHS [10]
Transformation approaches based on TGG often use
non-deleting rules [9], but some complex transformations with
deleting TGG rules can be used in the MDE The RTL
lan-guage [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
sce-narios As shown in [8], [11], rule dependencies between
op-erational 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 APPROACH OVERVIEW
Our approach overview for model transformation testing is
shown in Fig 3
Fig 3 Overview of the testing approach.
First, we analyze the declarative transformation
specifica-tion 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 THE ANALYSIS OFRULEDEPENDENCIES
Model transformations are executed by operational rule se-quences for forward/backward/integration/co-evolution trans-formation scenarios A transtrans-formation 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 (use, produce-forbidden, delete-produce-forbidden, and delete-use) between opera-tional 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 dependen-cies between declarative non-deleting TGG rules
Given two TGG rules enriched with OCL conditions spec-ified by the RTL language [10]: p1 = (L1, R1, AC1) = (GSL
1 ← GCL
1 → GT L
1 , GSR
1 ← GCR
1 → GT R
1 , AC1),
p2 = (L2, R2, AC2) = (GSL
2 ← GCL
2 → GT L
2 , GSR
GCR
2 → GT R
2 , 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 Neg-ative Application Conditions (NACs) on the rule’s LHS (NACLHS = NACSL∪ NACCL∪ NACTL), thus in this pa-per 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., NACSL= (GPSL, α) The produce-use and produce-forbidden dependencies are defined as follows: Definition 4.1 (Produce-use dependency) A produce-use dependency exists from a required TGG rule p1 to a dependent rule p , iff there exists x ∈ (GSL∨ GCL∨ GTL),
Trang 4y ∈ (G1 \G1 ) ∨ (G1 \G1 ) ∨ (G1 \G1 )
and x.type = y.type It is denoted p1
t
→ p2 Definition 4.2 (Produce-forbidden dependency) A
produce-forbidden dependency exists from a required RTL rule p1 to
a dependent rule p2, iff there exists x ∈ (GP2SL∨ GPCL
GP2T L), y ∈ (GSR1 \GSL
1 ) ∨ (GCR1 \GCL
1 ) ∨ (GT R1 \GT L
1 ) and x.type = y.type It is denoted p1
t
→ 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
r1 c1:Class, c2t1:C2T, t1:Table
r2 c1:Class, c2t1:C2T, t1:Table a1:Atribute, a2c1:A2C, co1:Column,(c1, a1): attrs, (t1, col1):cols
r3 c1:Class, c2t1:C2T, t1:Table, a1:Atribute, a2c1:A2C, co1:Column, (c1, a1): attrs, (t1, col1):
cols, (t1, col1): pkey
r4
c1:Class, c2:Class, t1:Table,
t2.Table, co1:Column, co2:Column,
(t1, col1):cols, (t2, col2):pkey, (t2,
col2):cols
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
r5 c1:Class, c2t1:C2T, t1:Table c2:Class, c2t2:C2T, (c2, c1): inheritance
TABLE II
P RODUCE - USE DEPENDENCIES
Rule r1 r2 r3 r4 r5 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 r3 0-0-0 0-0-0 0-0-0 0-0-2 0-0-0 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
Comparing elements
(RHS\LHS) of rule
pairs based on the
existence of element
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 1 denotes a
dependency while the value 0 denotes a non-dependency
In some cases, a rule is activated only when another rule be
applied several times, i.e., the rule r4includes two elements of
the C2T type in its LHS that be created by applying rule r1two
times Therefore, the rule r4really 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 2 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
dependen-cies are detected by the analysis of NAC expressions In RTL
language, we express NACs (lines 47-48, 56-57 in Fig 2 (a))
using the following prototype:
not type1.allInstances–>forAll(o1|
typeN.allInstances–>forAll(oN|
conditions(o1, ,oN)))
We compare object types captured from NAC
expres-sions and object types of the graph structure of rules
to detect produce-forbidden dependencies using
Defini-tion 4.2 In the transformaDefini-tion CD2RDS, the rule r3
contains NACs, so there exist produce-forbidden
depen-dencies between r3 and other rules as in Table III
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 1-0-1 0-0-0 0-0-0 r3 0-0-0 0-0-0 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
After rule dependen-cies are detected, they will be used to generate test cases in the next section
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
1-way 2-way 3-way r1 r1-r2, r1-r3, r1-r1-r4 r1-r2-r2-r4 r2 r1-r5, r2-r2-r4 r1-r3-r3-r4 r2 r3-r3-r4, r4-r2, r4-r3 r1-r1-r4-r2 r4 r4-r4-r4, r4-r5, r5-r2 r1-r5-r2 r5 r5-r3, r5-r5-r4,r5-r5 r1-r5-r3 (produce-forbidden) r2-r3,
r3-r3, r4-r3
Most faults in software systems are due to the interaction of several properties Based
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 − 1 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− r2will generates a TCD that
is also the structure of rule r2 in the Fig 1 The algorithm generating TCDs is expressed as follows:
Trang 5Algorithm 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 = (p 1 , p 2 , , p n )
Output: T CDs = Set of test case descriptions
3 tcd ⇐ create new T CD, initialize the tcd by the first rule p 1 ;
parameters that are names of added elements by the rule ;
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
it-erate 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
con-ditions 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 TOOLSUPPORT ANDEXPERIMENTALRESULTS
In this section, we introduce the tool support and
experi-mental results for testing the CD2RDS transformation
A Tool support
This section presents our implementation to test model
transformations based on the declarative specification While
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 Clas-sifying Terms (CTs) [4] by using EMF-based prototype tool Besides, the testing process is executed by the RTL frame-work 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
B Experimental results 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 rule-applications, 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 depen-dencies 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 3-way, 4-3-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
Trang 6forward 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 4 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
Fig 4 The TCD generated from the rule sequence r 5 − r 3 − r 3
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 RELATED WORK
Existing proposals for test case generation often employ
a black-box approach that relies on coverage of the
meta-model [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
expres-sions 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
produce-use 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
foun-dation 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
trans-formation testing ensuring the meta-model coverage criteria
similar to the work in [2] In this paper, we also consider
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 CONCLUSION AND FUTURE WORK
The analysis of declarative rules can be used to find possible derived rule dependencies for checking transformation prop-erties In this paper, we provide an approach to analyze rule-dependencies 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
[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 gram-mars,” 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 appli-cability and non-appliappli-cability 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 transforma-tions,” in Proc 10th Int Conf International Conference on Knowledge and Systems Engineering (KSE), 2018, pp 264–269.
[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.