1. Model Transformation Verification: some theory and some practice Levi Lúcio MSDL Lab / NECSIS project McGill University

2. Dr. Levi Lúcio Model Based Testing (SMV, U. Geneva) Model Transformation Verification (SOLAR, U. Nova Lisboa) Model Evolution in MDE (LASSY, U. Luxembourg) 2

3. Main interests Formal modeling Verification Formal languages and their semantics DSL and MDE fundaments – Precise definition of a DSL (is Turing incompleteness a usable definition?) – Precise definition of the MDE process Globally intersection between software engineering and formal methods 3

4. Presentation Overview Preliminary state of the art in Model Transformation Verification Introduction to the Power Window case study Which MT verification techniques can we use and for what? 4

5. Presentation Overview Preliminary state of the art in Model Transformation Verification Introduction to the Power Window case study Which MT verification techniques can we use and for what? 5

6. Why is MT verification different from typical program verification? MT are programs with complex inputs, typically MOF/EMF based models; Unlike reactive systems, in MT typically only input and output is interesting. Intermediate states are most of the time disregarded; Most of the current verification technology is built for reactive systems… 6

7. Testing vs. Proving Testing Model Transformation challenges: – Input model generation – Oracle production and usage – Test qualification Proving Model Transformation challenges: – Most transformation languages are Turing complete, nondeterministic and have an infinite amount of input models; – Proving syntax is hard, proving semantics is harder… 7

8. Testing vs. Proving Testing Model Transformation challenges: – Input model generation – Oracle production and usage – Test qualification Proving Model Transformation challenges: – Most transformation languages are Turing complete, nondeterministic and have an infinite amount of input models; – Proving syntax is hard, proving semantics is harder… 8

9. Input model generation Input model generation from analysis of metamodels and of transformation rules: – [Küster,Razik:06] on production of input models based on coverage criteria for metamodels, OCL constraints and critical pairs analysis; – [Baudry:09] on black box domain partitioning (metamodel based) and combinatorial interaction; – [McQuillan,Power:09] on white box transformation rule coverage; – [Mottu,Baudry,Traon:09] on model transformation fault models; 9

10. Oracle production and usage Means of comparison of MT output model and a reference model: – [Lin,Zhang,Grey:05] on an algorithm for output model comparison for oracle implementation; – [Mottu,Baudry,Traon:09] on oracle classification, e.g. manual, reference transformation, contracts and assertions; 10

11. Input model qualification Criteria to evaluate and improve the quality of generated input models: – [Mottu,Baudry,Traon:06] on model transformation mutation operators for input model mutation analysis; – [Fleurey,Baudry,etal:07] on the classification of coverage criteria for input model qualification; 11

12. Testing vs. Proving Testing Model Transformation challenges: – Input model generation – Oracle production and usage – Test qualification Proving Model Transformation challenges: – Most transformation languages are Turing complete, nonconfluent (nondeterministic) and have an infinite amount of input models; – Proving syntax is hard, proving semantics is harder… 12

13. Termination Termination of graph rewriting is undecidable [Plump98]: – [Ehrig,Ehrig,etal:05] on a set of termination criteria transformation rules must satisfy; – [Varró,Varró,etal:06] on transforming into Petri Nets for deciding on transformation termination; – [Lara,Vangheluwe:09] on transforming into Timed Petri Nets for deciding on transformation termination; – [Barroca,Lúcio, etal:10] on a transformation language insuring termination and confluence of all transformations by construction; 13

14. Confluence Rule execution order matters: – [Heckel,Küster,Taentzer:02] on the definition of confluent critical pairs of rules; – [Barroca,Lúcio, etal:10] on a transformation language insuring termination and confluence of all transformations by construction; 14

15. Infinite amount of Input Models (1) Input models are typically infinite instances of MOF/EMF metamodels. Approaches dependent on a given input model: – [Anastasakis,etal:06] on using Alloy for proving the transformation can run for one input model; – [Narayan,Karsai:08] on proving a structural correspondence will exist between an input model and the transformations output; – [Lara,Vangheluwe:09] on transforming one input model for a transformation into a Petri Net for analysis; 15

16. Infinite amount of Input Models (2) Approaches valid for all inputs, independent of any input model: – [Asztalos,etal:10] on proving properties of model transformations based on assertions and deduction rules; – [Lúcio,Barroca,etal:10] on proving structural relations between source and target model based on rule symbolic execution; 16

17. Proving syntactic relations between input and output models Show that certain elements or patterns of an input model will always produce other elements or patterns of the output model – [Akehurst:02] on defining relations that hold between the input and output models by construction; – [Narayan,Karsai:08a] on proving a structural correspondence will exist between an input model and the transformations output; – [Lúcio,Barroca,etal:10] on proving structural relations between source and target metamodels hold on all transformations; 17

18. Proving semantic preservation between input and output models The semantics of the original model is preserved after the transformation: – [Padberg, etal:97] on Petri Nets safety property preserving morphisms (applicable to statecharts); – [Varró,Pataricza:03] on preservation of a given property by model checking it on the input model and its transformed version on the output model; – [Narayanan,Karsai:08b] on the verification of preservation of statechart semantics; 18

19. Preliminary classification axis for MT Verification Techniques 19 TestingProving Input model generationTermination Oracle production and usageConfluence Test qualificationInfinite input models Syntactic relations Semantic preservation

20. Other classification axis Proof techniques – Model checkers (e.g. GROOVE) – Constraint solvers (e.g. Alloy) Applicable to which transformation languages? 20

21. Presentation Overview Preliminary state of the art in Model Transformation Verification Introduction to the Power Window case study Which MT verification techniques can we use and for what? 21

22. MDD control software development for a Power Window 22 Identify – Modeling languages and artifacts – Software development activities – Model transformations

23. Modeling artifacts for describing a Power Window 23 Control Plant Environment

24. Plant Description Language 24

25. Control Description Language 25

26. Environment Description Language 26 Inspired from Dhaussy and Roger, Spécification du langage CDL v.1 : Syntaxe et sémantique, 2011

27. Software development activities Simulation Verification – Model checking – Model based testing Code generation 27

28. Simulation 28 Control Plant Environment ++ Causal Block Diagram

29. Model Checking 29 Control Plant Environment ++ Petri Nets

30. Model Based Testing 30 Control Plant Environment + Test Cases Oracle

31. Code Generation 31 Control Plant Environment + Autosar

32. Identified transformation types Composition – Environment + Control + Plant Same abstraction – Environment + Control + Plant -> Causal Block D. Abstract (lose detail) – Environment + Control + Plant -> Petri Nets Refine (add detail) – Control + Plant -> Autosar 32

33. Presentation Overview Preliminary state of the art in Model Transformation Verification Introduction to the Power Window case study Which MT verification techniques can we use and for what? 33

34. Which MT verification techniques can we use and for what? 34 ?

35. Which MT verification techniques to use and for what? It depends… On the type of the transformation (composition, abstraction, refinement…) On the purpose of the transformation (verification, simulation, composition…) On the domain of application (automotive software development, control systems…) 35

36. Most likely direction Use either proofs of: – Syntactic relations hold between input and output models; – Semantics is preserved during transformation Challenge: using these two general types of proofs and the available techniques understand which specific properties are important to prove in the Power Window case study. 36

37. Bibliography [Plump98] D.Plump Termination of graph rewriting is undecidable, Fundamenta Informaticae 33(2), 1998. [Ehrig,Ehrig,etal:05] H.Ehrig, K.Ehrig, J.Lara, G.Taentzer, D. Varró and S.Varró- Gyapay Termination Criteria for Model Transformation, LNCS 3442, 2005. [Varró,Varró,etal:06] 37