towards interactive, test-driven development of model … · 2020. 10. 18. · keywords model...

Journal of Object Technology | RESEARCH ARTICLE

Towards interactive test-driven development of modeltransformations

Jesuacutes Saacutenchez CuadradoUniversidad de Murcia Spain

ABSTRACT Developing model transformations is a complex task because it requires a deep knowledge of the semantics of theinput and output meta-models Many times this knowledge is refined as the transformation is developed A simple approach toencode this knowledge is in the form of test cases consisting of pairs of input models and expected output models Howevercreating these test cases is a time consuming and error-prone activity and it is barely used Moreover there is little tool supportfor refining a transformation interactively at the same time that the test suite is createdThis paper explores an approach for test-driven development of model transformations based on creating test cases usinga model finder in an interactive manner The synthesis of the input models of the test cases is driven by the results of staticanalysis with respect to the coverage of the transformation with the goal of instantiating input models which are not yet handledby the transformation The expected models are automatically derived using an instrumented transformation and the user is incharge of inspecting the result to validate them The approach has been implemented for ATL and integrated into AnATLyzerusing USE Model Validator as the backend model finder

KEYWORDS Model transformation Test-driven development Model finding USE Model Validator

1 IntroductionModel transformations (MT) are an essential part of Model-Driven Engineering since they allow developers to manipulatemodels automatically for instance to achieve tool interoper-ability to convert models to different formalism for analysis tocreate refactorings or to animate models Model transformationscan be developed using model transformation languages (MTL)like ATL (Jouault et al 2008) ETL (Kolovos et al 2008)QVT (OMG 2005) Henshin (Arendt et al 2010) etc Thedesign of a model transformation language typically includesconstructs specifically tailored to implement transformationsin an efficient way At the same time a model transformationlanguage can be accompanied with a development environment(IDE) which provides productivity features such as editors withsyntax highlighting static analysis (Cuadrado et al 2016) and

JOT reference formatJesuacutes Saacutenchez Cuadrado Towards interactive test-driven development ofmodel transformations Journal of Object Technology Vol 19 No 3 2020Licensed under Attribution 40 International (CC BY 40)httpdxdoiorg105381jot2020193a18

quick fixes (Cuadrado et al 2018b) Moreover there are alsoapproaches to automate and facilitate the creation and executionof tests cases from transformation specifications (Gogolla ampVallecillo 2011)(Guerra amp Soeken 2015) However despite ofthese facilities the development of model transformations isstill a complex and error-prone activity

Using current technology model transformations are devel-oped in a top-down fashion and with little testing (Baudry et al2010)(Guerra et al 2019) There exists methods to design trans-formations (Guerra de Lara Kolovos et al 2013) but they areseldom used In practice in the authorrsquos experience the sourceto target mappings and the required transformation rules areldquodiscoveredrdquo incrementally by building examples of concretemodels (even if these models are constructed informally) Atthe same time building input test models manually is a tediousand error prone activity and therefore it is typically not carriedout Alternatives like creating transformation contracts and gen-erating test cases from them can also be cumbersome since theyrequire a good knowledge of the semantics input and outputmetamodels

This paper proposes a method to develop model transforma-

An AITO publication

tions incrementally and interactively growing the set of inputtest models semi-automatically as the transformation is devel-oped In contrast to other testing approaches (Gonzaacutelez amp Cabot2012 Fleurey et al 2004) we aim at generating input modelswhich are not covered yet by the transformation The goalis that they serve as guidance to evolve the transformation byinspecting concrete examples The method is supported by atool for ATL integrated into ANATLYZER1 Technically wecombine static analysis and model finding in particular modelsynthesis and partial model completion to suggest relevant in-put models and help the developer understand the corner casesof the transformation at the same time that a proper test suite isconstructed To achieve this we make use of the USE Model Val-idator (Kuhlmann amp Gogolla 2012 Gogolla et al 2018) (USEMV) a robust model validator which is integrated in Eclipsethrough EFINDER2 (Cuadrado amp Gogolla 2020)

Altogether this paper makes the following contributions

ndash An approach to incrementally develop a model transforma-tion as well as its test suite by automatically synthesizinguncovered models

ndash Tool support for ATL integrated into ANATLYZER whichincludes static analys input model synthesis test suiteexecution and maintenance and inspection of test cases

ndash This work can also been regarded as a case study abouthow to use model finding in particular USE MV featuresto enhance model transformation tooling

Organization This paper is organized as follows Section 2introduces a running example and motivates this work Sec-tion 3 presents the proposed development process Section 4and Sect 5 explains the details about our static analysis andthe generation of input models respectively whereas Sect 6explains how test cases are inspected and maintained Section 7shows how the approach is implemented in practice FinallySect 8 presents the related work and Sect 9 concludes

2 BackgroundThe availability of techniques to ensure the correctness of modeltransformations is essential for the success of MDE The factthat model transformation languages are higher-level that gen-eral purpose language could in principle provide opportuni-ties for supporting verification methods which are more dif-ficult to provide in general-purpose language languages Forinstance several transformation-specific analysis have been pro-posed for different languages (Cuadrado et al 2018a)(Cheng ampTisi 2017)(Oakes et al 2018) mechanisms for generating testcases automatically (Gonzaacutelez amp Cabot 2012)(Guerra amp Soeken2015)(Gogolla amp Vallecillo 2011) visualizations (Guana ampStroulia 2014) etc

An scenario which has been less explored until now is toenhance the development environment with features to help thetransformation developer construct meaningful transformationrules interactively by means of (semi-)automatically generatedtest cases Instead of generating a complete test suite directly

1 httpanatlyzergithubio2 httpsgithubcomjesuscefinder

EPackage EClassifiereClassifiers

EStructuralFeatureEDataType EClass

eType 1

eStructuralFeatures

eSubpackages

EAttribute EReference

lowerBound intupperBound intcontainment boolean

ConstraintEPackageallInstances()-gtone(p|

peSuperPackageoclIsUndefined())

eSuperPackage01

abstract boolean

eSuperTypes

Figure 1 Excerpt of the Ecore meta-model

Model Classclasses

Collection Simple

Constraint ModelallInstances()-gtsize() = 1

name Stringabstract boolean

Association

name Stringkind AssocKind

associations

Attribute

name String

Role

name StringlowerBound intupperBound int

roles

attributes

superclasses

TypeReftype 1

Figure 2 Excerpt of the USE meta-model

in this proposal the test suite is grown incrementally as thetransformation is developed thus allowing the developer toreason over concrete example models

21 Running exampleAs a running example let us consider an ATL transformation toconvert Ecore meta-models into USE class diagrams3 Fig 1shows an excerpt of the Ecore meta-model and Fig 2 shows ameta-model for USE

The Ecore meta-model includes a constraint to express that ameta-model contains a unique root package4 The USE meta-model requires that there is only one Model element to reflectthe fact that in USE each specification contains a single classdiagram

22 MotivationDeveloping a model(-to-model) transformation is typically acomplex task because the developer must know the semantics ofboth the source and target domains of the transformation (in theexample the details of Ecore and USE class diagrams) and howthey related to each other Moreover the developer must ensurethat the implementation handles all possible input configurationscorrectly This is done by creating transformation rules with theappropriate input patterns or by documenting invalid configura-tions with pre-conditions At the same time the target modelsgenerated by the transformation must be both syntactically andsemantically correct by creating adequate output patterns andrelationships between rules This includes ensuring that thetransformation satisfies the invariants of the meta-models as3 Full transformation and meta-models available at

httpatenealccumaesprojectsMTBhtml4 This is technically not requirement for an Ecore meta-model to be valid but it

is a common assumption

2 Cuadrado

well as transformation post-conditions (ie constraints overthe target meta-models specific to the models generated by thetransformation)

A well known approach to establish the semantics of a trans-formation is to create transformation contracts (Tracts (Gogollaamp Vallecillo 2011)(Hilken et al 2018) is a specific instance ofthis approach) which specifies the main relationships betweenthe input and target meta-models For instance the followinglisting is a piece of contract for the running example taken fromthe Ecore2USE case study in (Burguentildeo et al 2014) It specifiesthat there must be the same number of classes in the source andtarget models and it uses the class name as a way to identifythem

1 minusminus Same number of classes2 EClassallInstancesrarrsize = ClassallInstancesrarrsize3

4 minusminus Equivalent names5 EClassallInstancesrarrforAll(ec |6 ClassallInstancesrarrexists(uc | ucname = ecname))

Listing 1 Contract for Ecore2USE

From these contracts test cases can be generated automat-ically and used to create a test harness As noted in (Gogollaamp Vallecillo 2011) the contracts do not need to be exhaustive(ie cover all configurations) but it can be refined graduallyNevertheless this approach forces the developer to have a ldquotop-downrdquo knowledge of the transformation in the sense that heor she needs to be able to describe the mapping in an abstractway Actually the proposed contract does not respect the Ecoresemantics since it assumes that the class name is not scopedby its package name This is a corner case which is typicallydifficult to consider upfront without seeing a concrete exam-ple Moreover the original contract did not include constraintsto indicate how Ecore sub-packages are handled (ie in USEnested modelspackages are not allowed) Although contractsare certainly useful to reason about transformation semanticsit can be difficult to identify corner cases which may requirereasoning about concrete instances

A simpler alternative is to create pairs of inputoutput testcases manually which in the process of creating them may helpthe developer identify and showcase the corner cases This canbe considered a ldquobottom-uprdquo approach The main advantageis that it allows us to work with concrete examples about theexpected behaviour of the transformation which may help inthe implementation task Unfortunately creating these pairs ofmodels can be very time consuming and this approach is seldomused

In this paper we propose a development process that allowsa transformation developer to create transformation in a bottom-up manner by growing a test suite incrementally and interac-tively as new transformation rules are created This approachis not incompatible with existing approaches like the use oftransformation contracts On the contrary it can also be usedto refine existing contracts and gain a better knowledge of thetransformation semantics iteratively

23 A quick tourThis section provides a quick tour of our tool for the test-drivendevelopment of ATL transformations The goal is to give thereader a concrete view of our proposal in order to facilitate theunderstanding of the following sections

Fig 3 shows how a developer would start developing therunning example The different steps are illustrated with screen-shots from our tool First an initial rule is created (label 1)from which an initial test case is derived (label 2) The devel-oper inspects the the test case (label 3) which is a passing testcase because the output is as expected and marks it as reviewedThen the transformation is analysed to find out which elementsare not covered by the transformation (label 4) In this caseEClass is not covered and it is choosen by the user to generatea new test case (label 5) This implies synthesizing an inputmodel and executing the transformation to generate the outputmodel (label 6) The developer inspects the test case and findouts that the output model should contain two objects of typeUSE Class (label 7) This means that the transformation is notbehaving as expected If we fix the transformation (labels 8 and9) and re-run it the output model is as expected and the devel-oper commits the output model to the test suite by promoting itto ldquoexpected modelrdquo (label 10)

In summary the purpose is to avoid the burden of manuallycreating test cases The input models are automatically createdand can be refined manually if needed The output models aregenerated automatically by running the transformation Thedeveloper commits the output model when it is correct andthere is no need to manually create it

Next section gives an overview of the proposed method andthe rest of the sections describes its technical realization

3 Interactive test-driven development trans-formations

Our proposal for interactive test-driven model transformationsis based on three ingredients the use of static analysis includinga coverage analysis model finding to enhance static analysisand to automatically extend the test suite with new test casesand finally automated execution of the test suite so that user caninspect the output of new test cases and identify transformationrefinement needs

In the case of the running example to start developing thetransformation from scratch we could begin by writing thesimplest rule that we could come up with For instance wecould write a rule to map Ecore packages to USE models andset simple properties like name and classes The followinglisting shows the initial version of the transformation

1 rule package2model 2 from e EcoreEPackage3 to c UseModel (4 name ltminus ename5 classes ltminus eeClassifiers6 )7

Listing 2 Ecore2USE transformation (version 1)

Towards interactive test-driven development of model transformations 3

1

2

Inital rule3 Review example Mark valid

4

5 Identify next element

6

7

8

Generatetest case amprun transformationReview test case

Fixed transformation

Create seedtest case

Analysis

9

Fix

Re-run

10

Figure 3 Usage of the interactive transformation tool

EPackage

name=ldquotestrdquo

EPackage

name=ldquotestrdquo

EClass

name=ldquoPersonrdquo

Model

name=ldquotestrdquo

Testcase 1(seed)

Test case 2

eClassifiers

Model

name=ldquotestrdquo

package2model

package2model

uncovered

Input Output Expected

Model

name=ldquotestrdquo

Model

name=ldquotestrdquo

Class

name=ldquoPersonrdquoclasses

Pass

Fail

Figure 4 Test suite examples Input models (left) expectedmodels (right) and transformation output (middle)

We can start testing the transformation by writing a simpletest case Figure 4 shows the seed test case of our test suiteFrom this we woud like to know which input configurationshave not been handled yet and to create new test cases whichinclude these elements For instance in Listing 2 there are notany rule to handle EClass elements This information can beextracted by analysing the coverage of the transformation ruleswith respect to the meta-model elements

In an ATL transformation we can find three scenarios ofldquolack of coveragerdquo (1) there might be rules yet to be written(missing rules) (2) existing rules might have missing bindings(eg target features not yet assigned) and (3) it might be thatsome of the bindings are not fully covered by existing rules Toanalyse the coverage of the transformation rules with respectto the input meta-model we have implemented a new analysisin ANATLYZER called Uncovered elements It checks whichmeta-model elements have not been handled by the transforma-tion For instance elements like EClass EClassabstract andEAttribute have not been handled yet by the transformation This

is described in more details in the next section In addition tothis analysis it is possible to use existing analysis provided byANATLYZER in order to generate example input models namely

ndash Unresolved bindings Checks whether a binding is com-pletely covered by the transformation rules If a bindingis not resolved the element right-hand side of the bindingwill not be resolved into an element assignable to the targetfeature For instance the binding in line 5 will be unre-solved because there is no rule with EClassifier as inputpattern (or two rules for covering EClass and EDataTypewhich are the direct subtypes of EClassifier)

ndash Invariant analysis It checks whether any possible outputmodel of a transformation will satisfy the post-conditionstarget meta-model invariants and transformation contractsexpressed in OCL (Cuadrado et al 2017) In the runningexample the invariant in the USE meta-model will beviolated by the transformation The analysis generates acounter example which can be used as a test case as well

ndash Unconnected components Checks if all the target elementsgenerated by the transformation form a connected graphIf this is not the case then it might be sign of missingbindings or rules For instance with the current versionof the transformation a model with a root EPackage and achildren EPackage element will in result an unconnectedgraph (ie two unlinked Model elements) This modelwill also be discovered by the invariant analysis in thiscase because the USE meta-model has a precise constraintabout this

The goal is then to devise a development process driven bythe results of these analysis The process would help the de-veloper construct the transformation by incrementally coveringmore input meta-model elements and by examining new pairs of

4 Cuadrado

inputoutput models (ie a generated test case) We propose thedevelopment process depicted in Fig 5 For simplicity the pro-cess assumes that the transformation is going to be developedfrom scratch and using a deterministic transformation languageIt has the following steps

1 A new transformation is created To begin with a simplerule is created Typically to transform the root element Inthe running example we have started with package2model

2 Create one or more initial test cases This step can beperformed manually or automatically by generating a seedinput model which covers all the elements of the transfor-mation and then execute automatically the transformationto generate the corresponding output model The initial testcase is a seed test case to start growing the test suite Thetest suite is formed by pairs of input and output modelsGiven that the initial rule is very simple it is assumed to becorrect and the output model is therefore a valid expectedoutput model

3 We use ANATLYZER to analyse the transformation and iden-tify a number of elements that are not covered by thecurrent set of rules by using the coverage analysis men-tioned above For instance elements like EClass EPack-ageeSubPackages are not covered in the current versionof the transformation

4 The user inspects the results of the analysis and choose ameta-model element to cover in the next iteration For in-stance in the example a natural selection would be EClass

5 The system synthesizes one or more input models whichinclude the choosen meta-model element The synthesis isconstrained to produce models that do not include the pathsfor which the transformation already cover the elementIf we choose EClass the resulting input model could besimilar to the test case 2 of Fig 4

6 The transformation is executed automatically to show theuser both the input and outputs of the transformation Theinput model can be refined manually if needed The userinspects the output model to determine if this is what itis expected If not then it means that the transformationneeds to be fixed If the output model is considered avalid expected model (wrt to the input model) then theinputoutput pair is added to the test suite and the processcontinues In the example test case 2 is not yet validbecause its output model is not as expected We needto add a rule for EClass to generate the expected outputmodel

7 The test suite is run continously as part of the processto ensure that fixing a specific test case does not breakexisting ones (or alternatively to fix existing test cases)Running the test suite consists of executing the transforma-tion using the input model of each test case and comparingthe resulting output model with the expected model of thetest case

8 The process finishes when the input meta-model is com-pletely covered or when the developer determines that theuncovered elements are not of interest for the transforma-tion

A key element is to provide comprehensive tool support forthe process The developer should be able to perform all manualsteps with the less possible effort In particular the inspectionof the generated test case must be easy and fast To this endtest cases tend to be small and focused on the new elements tobe tested In addition the model transformation is instrumentedto generate a trace model (as a secondary target model) whichincludes information about which meta-model elements hasbeen ldquotouchedrdquo by the transformation This information allowsus to display runtime coverage information from the test casesand the explicit mapping between the input and output models

The next section presents the analysis that we perform andSect 5 describes how to use model finding to generate new testcases

4 Transformation analysisIn the proposed process we make use of several analysis whichhave been briefly discussed above In this section we discussthe uncovered elements analysis which is particularly useful forthe interactive process First we discuss the analysis for classesand then we extend it for structural features

41 Uncovered classesThis analysis is in charge of checking which classes of the inputmeta-models are not handled by any rule or if there are someinstances of a class which are handled but others not We saythat a class is covered when for each valid input model eachinstance of the class is matched by at least one input pattern5

Our approach to identify which classes are not covered bya transformation is based on two steps In the first step weidentify classes that are fully covered or partially covered andin a second step we use model finding to reason about the rulefilters

Gathering initial coverage information Algorithm 1 showsthe first step which classifies input metamodel classes into fullyand partially covered A class is fully covered when there isan input pattern whose type is the same class or a super typeand there is no condition involved in its matching A class ispartially covered when there is also a matching input pattern butit includes conditions (eg in rule filters) In addition abstractclasses requires special treatment since they are covered onlywhen all its concrete subclasses are also covered (lines 14 ndash 19)

Listing 3 shows an evolution of the running example In thistransformation class EClass is fully covered by rule class2classwhereas class EPackage is partially covered by rule pack-age2model To determine whether EPackage is not actuallyfully covered (eg if there are pre-conditions which comple-ments the rule filter to cover the whole input configuration)we need to resort to model finding to reason about the OCLexpressions

5 We say ldquoat leastrdquo instead of ldquoexactly onerdquo because we also consider lazy rules


Create initialtransformation

Derive roottest case

Test suiteTest suiteTest suite

Transformationanalysis

Choose uncoveredelement

Generate new input model(s)

Modifytransformation

yes

Is outputmodel valid

initalize

add

Run transformation

Mark output model as expected

no

More elementsto consider

no

yes

Regression testing is continouslyexecuted for early detection ofregressions

Figure 5 Activities in the proposed development process

1 rule package2model 2 from e EcoreEPackage (eeSuperPackageoclIsUndefined())3 to c UseModel (4 name ltminus ename5 classes ltminus eeClassifiers6 )7 8

9 rule class2class 10 from e EcoreEClass11 to c UseEClass (12 name ltminus ename13 )14


Reasoning about OCL expressions We use model finding todetermine if a class initiallly deemed as partially covered isactually fully covered To this end we need to construct a for-mula which aggregates all possible path conditions for partiallycovering the class (in the example there is only one path) andwe check if the union of the paths is not equal to the full set ofobjects of the class A path condition is an expression whichdescribes the features of the input models which will make thetransformation execution reach the desired execution point Thedetails about how to construct path conditions in ATL are de-tailed in (Cuadrado et al 2016) In this case if there is a modelthat satisfies the path condition it means there is at least one ex-ecution path that is not considered by the transformation More-over we need to consider the transformation pre-conditions andthe input meta-model invariants For instance to determine ifEPackage is covered we feed USE MV with the following setof constraints (Listing 4) In this case USE MV answers with acounter-example indicating that EPackage is not fully covered(ie a package with nested packages is not covered)

1 minusminus Invariant2 EPackageallInstances()rarrone(p |3 peSuperPackageoclIsUndefined())

4

5 minusminus Coverage criteria6 EPackageallInstances()rarrselect(p |7 peSuperPackageoclIsUndefined()) ltgt EPackageallInstances()

Listing 4 Constraints to determine the coverage of EPackagein the running example

In practice if an object of a given type is not matched byany input pattern it means that such object is not transformedThere are three scenarios

ndash It can be a smell that the transformation is incomplete andour system helps the developer identify these cases andadd new logic to handle them

ndash It can be the case that such input configuration is not in-tended to be handled by the transformation and thus mustbe forbidden Writing a pre-condition is an adequate way todocument this situation In this example we could restrictthe transformation to work with metamodels with a singlepackage using this pre-condition EPackageallInstances()-gtsize() = 1 In this case EPackage would be fully covered

ndash An alternative situation is that the developer wants to de-liberately ignore these objects because they do not belongto scope of the transformation but they are valid input ele-ments For instance a transformation that only transformUML Activity Diagrams In ATL there is not a way tocreate rules that ldquoignorerdquo elements In other languagesnotably RubyTL (Cuadrado et al 2006) it is possible towrite ldquoignore rulesrdquo to make this knowlege explicit

42 Uncovered structural featuresThe analysis for structural features that is proposed in this workis simple and just relies on the previous analysis If a class isuncovered all its structural features are uncovered as well If aclass is fully or partially covered we need to detect the usagesof the structural features of the class within the rule If a feature

6 Cuadrado

Algorithm 1 Identification of uncovered elementsInput Input meta-model classesOutput Set of pairs (class rules) with partial coverageOutput Set of pairs (class rules) with full coverage

1 concreteClasseslarr c isin classes | not cisAbstractforeach r in rules do

2 inClasslarr rinPatternforeach c in concreteClasses do

3 if c = inClass or c is a subtype of inClass then4 if r has filter then5 add (c r) to partial coverage6 else7 add (c r) to full coverage

break8 end9 end

10 abstractClasseslarr c isin classes | cisAbstractforeach c in abstractClasses do

11 if if all concrete subclasses of c are in full coverage then12 ruleslarr rules associated to subclasses add (c rules) to

full coverage13 else if if all concrete subclasses of c are in full or partial

coverage then14 ruleslarr rules associated to subclasses add (c rules) to

partial coverage15 end

is used as part of the rule we consider it covered otherwiseuncovered This analysis can be more precise by consideringpath conditions as above but this is left for future work

5 Creating new test casesGiven the analysis described in the previous sections the nextstep is to use the information about which elements have notbeen covered yet as a means to construct new test cases Ourgoal is to both incrementally evolve the transformation andto improve the test suite The rationale is as follows if thedeveloper is provided with a new test case then he or she has aconcrete instance to reason about and this will help in the taskof creating new rules or refine existing ones in order to evolvethe transformation in the direction of increasing the coverage

51 Generating input modelsIn this step the user is presented with the list of uncoveredclasses He or she has to select one of the classes to create anew test case which covers it Our basic approach is to createnew input models which contain at least one object not coveredby the transformation

For fully uncovered classes this is relatively straightfor-ward For instance to consider EAttribute we just need to useEAttributeallInstances()-gtsize() gt 1

For partially uncovered classes we need to generate path con-ditions in which the filter conditions are negated For instancefor EPackage we would generate the following constraint

1 EPackageallInstances()rarrexists(p | not peSuperPackageoclIsUndefined())

Listing 5 Constraint to generate a new input model withnested EPackage elements

To create models which are structurally more meaningfulwe need to add constraints to enfore the containment hierarchygiven by the meta-model This means that an object must onlyexists within its container if its class is not a root class In thiscase we would add to the previous constraint

1 EClassallInstances()rarrforAll(c |2 EPackageallInstances()rarrexists(p | peClassifiersrarrincludes(c)))3 and4 EDataTypeallInstances()rarrforAll(c |5 EPackageallInstances()rarrexists(p | peClassifiersrarrincludes(c)))6 and7 EStructuralFeatureallInstances()rarrforAll(c |8 EClassallInstances()rarrexists(p |9 peStructuralFeaturesrarrincludes(c)))

Listing 6 Constraints to consider the containment hierarchy

Finally to consider structural features and to give more di-versity to the generated models we could extend the path condi-tions with additional constraints over the features of interest Forinstance the original constraint for EPackage could be extendedin several ways to generate different models

1 minusminus Several subpackages in a nested package2 EPackageallInstances()rarrexists(p |3 not peSuperPackageoclIsUndefined() and4 peSubPackagesrarrsize() gt 2)5

6 minusminus Enforce a value in nsURI value7 EPackageallInstances()rarrexists(p |8 not peSuperPackageoclIsUndefined() and9 pnsURI = rsquotestrsquo)

Listing 7 Constraints to generate diverse models with nestedEPackage elements

52 Extending test casesThe generated test cases can be manually modified for instanceto introduce more meaningful attribute values (eg for names)or to consider additional cases This means that when wegenerate a new test case we might be interested on extendingthe existing test cases as a way to reuse the knowledge that hasbeen manually introduced The newly generated test case mayreplace the extended case or become a new test case on its own

To achieve this we proceed in two steps First we find testcases which are relevant for the coverage goal Second we usemodel completion to generate test cases based on the ones thathave been found

Finding relevant test cases Given a class of interest c in thisstep we identify existing test cases with two properties Firstthey must not contain objects of type c Second they containat least one object which can be connected to new new objectsof type c Algorithm 2 is in charge of identifying potentialextension points for test cases Given a class c the output isa list of tuples (testcase object re f erence) in which the firstcomponent is a test case the second a container object and


the third a reference that can be used to initialize a slot in thecontainer object with an object of type c

Algorithm 2 Identification of extendable test casesInput test cases in the test suite (testcases)Input class choosen by the user (c)Output list of potential test cases to be extended (testcase

object reference)16 Identify potentially relevant references17 linkslarr empty list

foreach cc in classes of the input meta-models do18 foreach re f in references of cc do19 Is it possible to set the reference with an object of type

c20 if reftype = c or reftypeisSuperTypeOf(c) then21 add (cc ref) to links22 end23 end24 Identify relevant test cases by looking for objects whose class25 is a ldquocontainer classrdquo (cc)26 foreach t in testcases do27 foreach o in objects contained in input models of t do28 classlarr oclass

if class = c then29 continue30 foreach re f such that exists (cc ref) in links where cc

= class do31 add (t o re f ) to tests cases32 end33 end34 end

Model completion The algorithm produces a list of potentialtest cases to be extended along with the container and thefeature to be extended Let us suppose that we choose EPackage(which is partially covered in version 2 of the transformation)The second test case in Fig 4 would be choosen since it alreadyhas an object which is extendable by an EPackage which is theroot EPackage through the eSubpackages reference Thus wegenerate the following formula

1 EPackageallInstances()rarr2 select(p | peSuperpackageoclIsUndefined())rarr3 exists(p | peSubpackagesrarrnotEmpty())

Listing 8 Input for USE MV

There is an additional practical issue to consider In USEMV the model completion functionality requires the user to setthe object bounds to at least the number of objects of eachclass This is done automatically by our system In this case forinstance we set EPackage = 2 (the original package plus one)and EClass = 1 (the original EClass in the model) If no modelcan be synthesized (eg some constraint cannot be satisfied withthese bounds) we apply the heuristic of iteratively incrementthe number of objects up to 5 This is the same approachused in AnATLyzer (Cuadrado et al 2016) As future work we

aim at using recent results in model diversity to generate bettermodels (Semeraacuteth amp Varroacute 2018 Burguentildeo et al 2019)

6 Inspecting test casesEach time that we generate a new input model (either fromscratch or extending an existing one) our system automaticallyruns the transformation and generates a new output model Inour process which is interactive it is the userrsquos task to checkif the new output model is as expected or not Thus the outputmodel of a test case has two states

ndash Unreviewed The output model has been automaticallygenerated but it has not been reviewed by the developerThe model stays in this state until it is a valid output model(ie it is what the developer expects to get obtain from theinput model)

ndash Commited The test case has been reviewed and the userconsiders that the output model can be promoted to becomean expected model From now on the test case can bepassing or failing We use EMF Compare to check if thegenerated output model is the same as the expected model

The underlying idea is to avoid the burden of creating testmodels manually On the one hand input models are auto-matically synthesized and if manual modification is requiredit is expected that only a few elements or properties need tobe edited On other hand the expected models are just cre-ated when the transformation is run and the user only needs toinspect them To facilitate this process our tool shows the cor-respondences between the input and output models along withwhich elements of the input meta-model has been dynamicallycovered (see Fig 3 and Fig 6) This is done by instrumentingthe transformation

61 Transformation instrumentationThe transformation is instrumented in order to generate a fine-grained model gathering dynamic coverage data It is imple-mented as a higher-order transformation which generates an ad-ditional output model which records the coverage data Listing 9shows an excerpt of the instrumented transformation Everyrule is added an imperative block to create a Record object withthe information about the execution of the rule Then for everyfeature access the recordH helper is executed over the sourceobject This helper returns the same object and as a side effectgenerates a Record object to register the execution of this pieceof code

1 module Ecore2Use2 create OUT Use COV COVERAGE from IN Ecore3

4 rule package2model 5 from e EcoreEPackage6 to c UseModel (7 classes ltminus erecordH(rsquo1214minus12minus20rsquo8 rsquonavigationrsquo rsquoEPackageeClassifiersrsquo e)eClassifiers9 )

10 do 11 thisModulerecord(rsquo91minus142rsquo rsquomatchedminusrulersquo rsquopackage2modelrsquo

Sequencee Sequencec)12 13

8 Cuadrado

14 15 rule record(location String kind String info String16 sources Sequence(OclAny) targets Sequence(OclAny)) 17 to tgt COVERAGERecord (18 location ltminus location19 kind ltminus kind20 info ltminus info21 )22 do 23 tgtsources ltminus sources24 tgttargets ltminus targets25 tgt26 27 28

29 helper context OclAny def recordH(location String30 kind String info String object OclAny) OclAny=31 minusminus Force a side effect32 let dummy OclAny = thisModulerecordPath(location kind info33 Sequence object Sequence )34 in self

Listing 9 Instrumented transformation

The resulting coverage model is a flat model with Record ob-jects From this it is straightforward to reconstruct the coverageinformation for instance to show source-target relationshipsgraphically

7 Tool support

To support the development process described in this paper wehave implemented a prototype tool as an Eclipse plug-in inte-grated into ANATLYZER which is an IDE for ATL model trans-formations (Cuadrado et al 2018a)6 To connect USE ModelValidator with EMF we use EFINDER (Cuadrado amp Gogolla2020) which provides an interface to apply model finding withseveral OCL variants including ATL EMFOCL and AQL7

Figure 6 shows some screenshots of the tool Model trans-formations are developed in the regular ATLAnATLyzer editor(label 1) The results of the static analysis to detect transfor-mation problems can be inspected in the Analysis View (label2) In the prototype tool that has been implemented for thispaper we have added a Coverage view (label 3) which includesinformation about which classes are covered and by which rulesFrom this the synthesis of new test cases can be invoked Thetest cases associated to a transformation are maintained in aconfiguration file with extension itrafo There is a dedicatededitor to mantain the configuration file easily The test suiteeditor (label 4) shows the test cases and allows the developer torun them and to inspect their state By double-clicking on a testcase the user can jump to the test case inspector (label 5) whichshows the results of executing the transformation A test case iscommited (or uncommited) by cliking on the Valid check boxThe effect is that the generated output model becomes an ex-pected model and the system copies the output model to the testsuite folder in which the inputexpected models are stored Thisview also offers some information about the dynamic coverageof the transformation


8 Related work

There exists a large variety of works dealing with differentaspects of model transformation testing (Selim et al 2012) Inthis section we review works related to white-box testing black-box testing based on contracts and test-driven developmentmethods

Our approach is based on analysing the transformation rulesin order to synthesize relevant test cases Thus approachesfor white box testing of transformations are very related to ourapproach One approach is to use an iterative algorithm basedon instantiating the classes in the transformation footprint Toinstantiate attribute values representative values can be extractedfrom the transformation (Fleurey et al 2004) A similar line ofwork is presented in (Mottu et al 2012) in which the transfor-mation footprint is also used to drive test generation but usingAlloy to generate more diverse models The work in (Kuumlster ampAbd-El-Razik 2006) reports the experience of testing severalmodel transformation in the business modelling domain Theauthors discuss several types of errors (in our setting some ofthem are statically detected by ANATLYZER) and discuss howto use coverage for testing including an heuristic approach forgenerating test cases that violate transformation constraints Inour case we use model finding which may provide more accu-rate results ATLTest (Gonzaacutelez amp Cabot 2012) is a white-boxtest generation tool for ATL It generates input models tryingto maximize the coverage of the transformation However thisapproach does not handle the need of oracles (eg valid ex-pected models) Our approach does consider the constructionand maintenance of the test suite by doing the generation ofinput models interactively An important difference of our pro-posal with respect to these works is that we try to instantiatemodels which are not covered yet by the transformation Thisis because our approach is interactive and it assumes that thetransformation is incomplete Thus the coverage criteria isachieved as the transformation is fixed to address the test cases

An alternative to deriving test cases from the transformationis to use transformation specifications typically in the form oftransformation contracts Tracts (Gogolla amp Vallecillo 2011)are a generalization of transformation contracts based on estab-lishing relationships between the source and target metamodelsusing OCL expressions From this test cases can be automati-cally generated Visual constracts (Guerra de Lara Wimmer etal 2013) has been proposed to develop transformation contractsThis work is extended in (Guerra amp Soeken 2015) to generateinput test models and oracle functions

Tools to analyse and enrich the test suite are also of interestFor instance there are tools to analyze the coverage of the testsuite (Kuumlster et al 2013) and method to create test cases thatincrease the quality of the test suite is presented in (Kovaacutecs ampKuumlster nd) Also the work in (Gerking et al 2015) uses adomain-specific language to help in the design of model trans-formation tests Classifying terms (Hilken et al 2018) is atechnique which allows the space of possible input models tobe partitioned into equivalence classes using OCL expressionsso that more meaningful test cases can be automatically derivedusing USE Model Validator


1 Editor

2 Static analysis

3 Coverage

4 Test suite5 Test case inspection

Figure 6 Screenshots of the tool

Another related line of work is development process formodel transformations The work in (Candel et al 2019)presents a practical approach for migrating PLSQL code us-ing model transformations It proposes a test-driven method inwhich input models (created by writing pieces of PLSQL pro-grams) are created manually and output models are inspected tocheck if they are valid However the notion of expected modeldoes not seem to be considered therefore the process is not au-tomated In (Kuumlster et al 2009) a process is proposed to developmodel transformation chains using automated testing It is simi-lar to our process but the construction of the test cases is fullymanual In our case the construction is semi-automatic and theoutput models can be automatically ldquocommitedrdquo as test casesby our dedicated tool The transML (Guerra de Lara Kolovoset al 2013) development method includes the so-called ldquotrans-formation casesrdquo which are pairs of concrete source and targetmodels These cases are transformed into validation code Thecreation of these transformation cases can be costly and oursystem is intended to reduce the cost of creating them

9 ConclusionsModel transformation technology still needs from effective test-ing strategies which are applicable in practice This paper haspresented our initial work to support a test-driven process formodel transformation in which a dedicated tool helps the de-veloper create and mantain the test suite interactively The tool

has been implemented as part of ANATLYZER Even though theproposed development process is simple our hope is that itsown simplicity helps to increase the use of test cases in thedevelopment of ATL transformations Finally the paper show-cases the use of the capabilities of USE MV to enhance a modeltransformation development tool

As future work we plan to investigate how to synthesize morerealistic and diverse models (eg reusing recent advances (Bur-guentildeo et al 2019 Semeraacuteth amp Varroacute 2018)) This includesbeing able to generate adequate attribute values according to thedomain of the model Moreover we would like to carry out anempirical study to understand better the advantages and disad-vantages of this approach and to improve the tool accordinglyAnother interesting line of work is to try to synthesize rulesfrom the test cases validated by the user using search-basedtechniques

AcknowledgmentsI am thankful to Martin Gogolla for being a source of inspirationfor all the modelling community Notably all the work aroundUSE Model Validator has been particularly inspiring to me andI am grateful for all the effort that has been put in making USEsuch a robust and usable tool

ReferencesArendt T Biermann E Jurack S Krause C amp Taentzer G

10 Cuadrado

(2010) Henshin advanced concepts and tools for in-placeemf model transformations In International conference onmodel driven engineering languages and systems (pp 121ndash135)

Baudry B Ghosh S Fleurey F France R Le Traon Y ampMottu J-M (2010) Barriers to systematic model transforma-tion testing Communications of the ACM 53(6) 139ndash143

Burguentildeo L Cabot J Clarisoacute R amp Gogolla M (2019) Asystematic approach to generate diverse instantiations for con-ceptual schemas In International conference on conceptualmodeling (pp 513ndash521)

Burguentildeo L Troya J Wimmer M amp Vallecillo A (2014)Static fault localization in model transformations IEEETransactions on Software Engineering 41(5) 490ndash506

Candel C J F Molina J G Ruiz F J B Barceloacute J R HRuiz D S amp Viera B J C (2019) Developing a model-driven reengineering approach for migrating plsql triggersto java A practical experience Journal of Systems andSoftware 151 38ndash64

Cheng Z amp Tisi M (2017) A deductive approach for faultlocalization in atl model transformations In Internationalconference on fundamental approaches to software engineer-ing (pp 300ndash317)

Cuadrado J S amp Gogolla M (2020) Model finding in theemf ecosystem In 16th european conference on modellingfoundations and applications (pp 1ndash20)

Cuadrado J S Guerra E amp de Lara J (2016) Static analysisof model transformations IEEE Transactions on SoftwareEngineering 43(9) 868ndash897

Cuadrado J S Guerra E amp de Lara J (2018a) Anatlyzer anadvanced ide for atl model transformations In Proceedingsof the 40th international conference on software engineeringCompanion proceeedings (pp 85ndash88)

Cuadrado J S Guerra E amp de Lara J (2018b) Quick fixingatl transformations with speculative analysis Software ampSystems Modeling 17(3) 779ndash813

Cuadrado J S Guerra E de Lara J Clarisoacute R amp Cabot J(2017) Translating target to source constraints in model-to-model transformations In 2017 acmieee 20th internationalconference on model driven engineering languages and sys-tems (models) (pp 12ndash22)

Cuadrado J S Molina J G amp Tortosa M M (2006) RubytlA practical extensible transformation language In Europeanconference on model driven architecture-foundations andapplications (pp 158ndash172)

Fleurey F Steel J amp Baudry B (2004) Validation in model-driven engineering testing model transformations In Pro-ceedings 2004 first international workshop on model designand validation 2004 (pp 29ndash40)

Gerking C Ladleif J amp Schaumlfer W (2015) Model-driven testcase design for model-to-model semantics preservation InProceedings of the 6th international workshop on automatingtest case design selection and evaluation (pp 1ndash7)

Gogolla M Hilken F amp Doan K-H (2018) Achievingmodel quality through model validation verification and ex-ploration Computer Languages Systems amp Structures 54474ndash511

Gogolla M amp Vallecillo A (2011) Tractable model trans-formation testing In European conference on modellingfoundations and applications (pp 221ndash235)

Gonzaacutelez C A amp Cabot J (2012) Atltest a white-boxtest generation approach for atl transformations In Interna-tional conference on model driven engineering languagesand systems (pp 449ndash464)

Guana V amp Stroulia E (2014) Chaintracker a model-transformation trace analysis tool for code-generation envi-ronments In International conference on theory and practiceof model transformations (pp 146ndash153)

Guerra E Cuadrado J S amp de Lara J (2019) Towardseffective mutation testing for atl In 2019 acmieee 22ndinternational conference on model driven engineering lan-guages and systems (models) (pp 78ndash88)

Guerra E de Lara J Kolovos D S Paige R F amp dosSantos O M (2013) Engineering model transformationswith transml Software amp Systems Modeling 12(3) 555ndash577

Guerra E de Lara J Wimmer M Kappel G Kusel ARetschitzegger W Schwinger W (2013) Automatedverification of model transformations based on visual con-tracts Automated Software Engineering 20(1) 5ndash46

Guerra E amp Soeken M (2015) Specification-driven modeltransformation testing Software amp Systems Modeling 14(2)623ndash644

Hilken F Gogolla M Burguentildeo L amp Vallecillo A (2018)Testing models and model transformations using classifyingterms Software amp Systems Modeling 17(3) 885ndash912

Jouault F Allilaire F Beacutezivin J amp Kurtev I (2008) ATLA model transformation tool Science of Computer Program-ming 72(1-2) 31ndash39

Kolovos D S Paige R F amp Polack F (2008) The epsilontransformation language In Proc of the 1st internationalconference in theory and practice of model transformations(icmtrsquo08) (pp 46ndash60) doi 101007978-3-540-69927-9_4

Kovaacutecs D amp Kuumlster J M (nd) A method for creating a testcase set to achieve maximum specification coverage in modeltransformation testing

Kuhlmann M amp Gogolla M (2012) From uml and ocl torelational logic and back In International conference onmodel driven engineering languages and systems (pp 415ndash431)

Kuumlster J M amp Abd-El-Razik M (2006) Validation of modeltransformationsndashfirst experiences using a white box approachIn International conference on model driven engineeringlanguages and systems (pp 193ndash204)

Kuumlster J M Gschwind T amp Zimmermann O (2009) In-cremental development of model transformation chains usingautomated testing In International conference on modeldriven engineering languages and systems (pp 733ndash747)

Kuumlster J M Kovacs D Bauer E amp Gerth C (2013)Integrating coverage analysis into test-driven development ofmodel transformations (Tech Rep) IBM Research ReportRZ 3846 IBM Research-Zurich

Mottu J-M Sen S Tisi M amp Cabot J (2012) Staticanalysis of model transformations for effective test genera-tion In 2012 ieee 23rd international symposium on software


reliability engineering (pp 291ndash300)Oakes B J Troya J Luacutecio L amp Wimmer M (2018)

Full contract verification for atl using symbolic executionSoftware amp Systems Modeling 17(3) 815ndash849

OMG (2005) Mof qvt final adopted specification (Computersoftware manual No ptc05-11-01) (OMG doc ptc05-11-01)

Selim G M Cordy J R amp Dingel J (2012) Model trans-formation testing The state of the art In Proceedings of thefirst workshop on the analysis of model transformations (pp21ndash26)

Semeraacuteth O amp Varroacute D (2018) Iterative generation ofdiverse models for testing specifications of dsl tools In Fase(Vol 18 pp 227ndash245)

About the authorJesuacutes Saacutenchez Cuadrado is a Ramoacuten y Cajal researcher atUniversidad de Murcia Earlier he was Assistant Professorat Universidad Autoacutenoma de Madrid His research has beenfocused on Model-Driven Engineering in particular modeltransformations and Domain-Specific Languages He has cre-ated a number of tools among others RubyTL AnATLyzerEFinder and httpmar-searchorg They are available athttpgithubcomjesusc You can contact the author at je-suscumes or visit httpsanchezcuadradoes

12 Cuadrado

tions incrementally and interactively growing the set of inputtest models semi-automatically as the transformation is devel-oped In contrast to other testing approaches (Gonzaacutelez amp Cabot2012 Fleurey et al 2004) we aim at generating input modelswhich are not covered yet by the transformation The goalis that they serve as guidance to evolve the transformation byinspecting concrete examples The method is supported by atool for ATL integrated into ANATLYZER1 Technically wecombine static analysis and model finding in particular modelsynthesis and partial model completion to suggest relevant in-put models and help the developer understand the corner casesof the transformation at the same time that a proper test suite isconstructed To achieve this we make use of the USE Model Val-idator (Kuhlmann amp Gogolla 2012 Gogolla et al 2018) (USEMV) a robust model validator which is integrated in Eclipsethrough EFINDER2 (Cuadrado amp Gogolla 2020)

Altogether this paper makes the following contributions

ndash An approach to incrementally develop a model transforma-tion as well as its test suite by automatically synthesizinguncovered models

ndash Tool support for ATL integrated into ANATLYZER whichincludes static analys input model synthesis test suiteexecution and maintenance and inspection of test cases

ndash This work can also been regarded as a case study abouthow to use model finding in particular USE MV featuresto enhance model transformation tooling

Organization This paper is organized as follows Section 2introduces a running example and motivates this work Sec-tion 3 presents the proposed development process Section 4and Sect 5 explains the details about our static analysis andthe generation of input models respectively whereas Sect 6explains how test cases are inspected and maintained Section 7shows how the approach is implemented in practice FinallySect 8 presents the related work and Sect 9 concludes

2 BackgroundThe availability of techniques to ensure the correctness of modeltransformations is essential for the success of MDE The factthat model transformation languages are higher-level that gen-eral purpose language could in principle provide opportuni-ties for supporting verification methods which are more dif-ficult to provide in general-purpose language languages Forinstance several transformation-specific analysis have been pro-posed for different languages (Cuadrado et al 2018a)(Cheng ampTisi 2017)(Oakes et al 2018) mechanisms for generating testcases automatically (Gonzaacutelez amp Cabot 2012)(Guerra amp Soeken2015)(Gogolla amp Vallecillo 2011) visualizations (Guana ampStroulia 2014) etc

An scenario which has been less explored until now is toenhance the development environment with features to help thetransformation developer construct meaningful transformationrules interactively by means of (semi-)automatically generatedtest cases Instead of generating a complete test suite directly


EPackage EClassifiereClassifiers

EStructuralFeatureEDataType EClass

eType 1

eStructuralFeatures

eSubpackages

EAttribute EReference

lowerBound intupperBound intcontainment boolean

ConstraintEPackageallInstances()-gtone(p|

peSuperPackageoclIsUndefined())

eSuperPackage01

abstract boolean

eSuperTypes

Figure 1 Excerpt of the Ecore meta-model

Model Classclasses

Collection Simple

Constraint ModelallInstances()-gtsize() = 1

name Stringabstract boolean

Association

name Stringkind AssocKind

associations

Attribute

name String

Role

name StringlowerBound intupperBound int

roles

attributes

superclasses

TypeReftype 1

Figure 2 Excerpt of the USE meta-model

in this proposal the test suite is grown incrementally as thetransformation is developed thus allowing the developer toreason over concrete example models

21 Running exampleAs a running example let us consider an ATL transformation toconvert Ecore meta-models into USE class diagrams3 Fig 1shows an excerpt of the Ecore meta-model and Fig 2 shows ameta-model for USE

The Ecore meta-model includes a constraint to express that ameta-model contains a unique root package4 The USE meta-model requires that there is only one Model element to reflectthe fact that in USE each specification contains a single classdiagram

22 MotivationDeveloping a model(-to-model) transformation is typically acomplex task because the developer must know the semantics ofboth the source and target domains of the transformation (in theexample the details of Ecore and USE class diagrams) and howthey related to each other Moreover the developer must ensurethat the implementation handles all possible input configurationscorrectly This is done by creating transformation rules with theappropriate input patterns or by documenting invalid configura-tions with pre-conditions At the same time the target modelsgenerated by the transformation must be both syntactically andsemantically correct by creating adequate output patterns andrelationships between rules This includes ensuring that thetransformation satisfies the invariants of the meta-models as3 Full transformation and meta-models available at

httpatenealccumaesprojectsMTBhtml4 This is technically not requirement for an Ecore meta-model to be valid but it

is a common assumption

2 Cuadrado



















1

2


4


6

7

8




Analysis

9

Fix

Re-run

10


EPackage

name=ldquotestrdquo

EPackage

name=ldquotestrdquo

EClass


Model

name=ldquotestrdquo

Testcase 1(seed)

Test case 2

eClassifiers

Model

name=ldquotestrdquo

package2model

package2model

uncovered


Model

name=ldquotestrdquo

Model

name=ldquotestrdquo

Class


Pass

Fail









4 Cuadrado


























yes


initalize

add

Run transformation


no


no

yes








4








6 Cuadrado





break8 end9 end













































8 Cuadrado





7 Tool support




8 Related work






1 Editor

2 Static analysis

3 Coverage









10 Cuadrado







































12 Cuadrado



















1

2


4


6

7

8




Analysis

9

Fix

Re-run

10


EPackage

name=ldquotestrdquo

EPackage

name=ldquotestrdquo

EClass


Model

name=ldquotestrdquo

Testcase 1(seed)

Test case 2

eClassifiers

Model

name=ldquotestrdquo

package2model

package2model

uncovered


Model

name=ldquotestrdquo

Model

name=ldquotestrdquo

Class


Pass

Fail









4 Cuadrado


























yes


initalize

add

Run transformation


no


no

yes








4








6 Cuadrado





break8 end9 end













































8 Cuadrado





7 Tool support




8 Related work






1 Editor

2 Static analysis

3 Coverage









10 Cuadrado







































12 Cuadrado


























yes


initalize

add

Run transformation


no


no

yes








4








6 Cuadrado





break8 end9 end













































8 Cuadrado





7 Tool support




8 Related work






1 Editor

2 Static analysis

3 Coverage









10 Cuadrado







































12 Cuadrado





break8 end9 end













































8 Cuadrado





7 Tool support




8 Related work






1 Editor

2 Static analysis

3 Coverage









10 Cuadrado







































12 Cuadrado






















8 Cuadrado





7 Tool support




8 Related work






1 Editor

2 Static analysis

3 Coverage









10 Cuadrado







































12 Cuadrado





7 Tool support




8 Related work






1 Editor

2 Static analysis

3 Coverage









10 Cuadrado







































12 Cuadrado

1 Editor

2 Static analysis

3 Coverage









10 Cuadrado







































12 Cuadrado







































12 Cuadrado

towards interactive, test-driven development of model … · 2020. 10. 18. · keywords model...

Documents