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

Model Transformation Verification: some theory and some practice

Levi LúcioMSDL 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)

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

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?

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?

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…

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…

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…

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;

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;

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;

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…

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;

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;

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 transformation’s output;

– [Lara,Vangheluwe:09] on transforming one input model for a transformation into a Petri Net for analysis;

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;

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 transformation’s output;

– [Lúcio,Barroca,etal:10] on proving structural relations between source and target metamodels hold on all transformations;

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;

19

Preliminary classification axis for MT Verification Techniques

Testing Proving

Input model generation Termination

Oracle production and usage Confluence

Test qualification Infinite 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?

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?

22

MDD control software development for a Power Window

Identify– Modeling languages

and artifacts– Software development

activities– Model transformations

23

Modeling artifacts for describing a Power Window

Control PlantEnvironment

24

Plant Description Language

25

Control Description Language

26

Environment Description Language

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

28

Simulation

Control PlantEnvironment + +

Causal Block Diagram

29

Model Checking

Control PlantEnvironment + +

Petri Nets

30

Model Based Testing

Control PlantEnvironment +

Test Cases Oracle

31

Code Generation

Control PlantEnvironment +

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

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?

34

Which MT verification techniques can we use and for what?

?

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…)

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.

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]