on the correctness of model transformationscse814/lectures/modeltransformations.pdf · on the...

On the Correctness of Model

Transformations

Matthew Nizol

CSE 814, Fall 2014

Thursday, December 11, 2014

Agenda

� Context: Model-driven development

� Background on verification techniques

� Presentation of each technique

� Comparison of techniques

Context: What do we mean by “Model”?

� An abstraction of a software system

� Many types of models in software development:

UML vs. program codeVisual vs. textual

Ontology vs. XML schemaHigh- vs. low-level

Class diagram vs. state chartStatic vs. dynamic

Alloy spec vs. whiteboard sketchFormal vs. informal

ExamplesDimension

Context: Model-driven Development

� Problem:

� Complex software hard to develop

� Related artifacts hard to keep synchronized

� Solution:

� Models increase the abstraction level of development

� Transformations formalize relationships between models

Model Transformations

� Convert source model to target model

� Composed of transformation rules

� Rules may be imperative or declarative

� Example applications:

RefinementLanguage migration

OptimizationReverse engineering

RefactoringCode generation

EndogenousExogenous

Transformation Properties

Confluence

Termination

Execution of the transformation

Correspondence

Preservation

Semantics

Type correctness

Well-formedness

Syntax

ExamplesCategory

Verification Approaches

� Informal:

� Testing

� Inspection

� Formal:

� Model Checking

� Theorem Proving

� Graph-theoretic

Verification Approaches

� Informal:

� Testing

� Inspection

� Formal:

� Model Checking

� Theorem Proving

� Graph-theoretic

SourceModel

Transformation Target

Direct Indirect

Approach 1: Indirect, Model Checking

Figure adapted from Varro et al.

Example: Source Model

Example: Target Model (Petri Net)

Tool: pneditor.org

Example: Source to NuSMV (Partial)MODULE sensor(resumemsg)

VAR

state : {imagecapture, processimage, computedist, waiting};

transition : {captured, clear, obstacle, closeobs, resume};

ASSIGN

init(state) := imagecapture;

next(state) :=

case

state = imagecapture & transition = captured : processimage;

…

state = waiting & transition = resume : imagecapture;

TRUE : state;

esac;

next(transition) :=

case

state = imagecapture : captured;

state = processimage : {clear, obstacle};

state = computedist : {clear, closeobs};

state = waiting & resumemsg : resume;

TRUE : transition;

esac;

MODULE sensor(resumemsg)

VAR



ASSIGN


next(state) :=

case


…


TRUE : state;

esac;

next(transition) :=

case





TRUE : transition;

esac;

Example: Source to NuSMV (Partial)

Define states and transitions


VAR



ASSIGN


next(state) :=

case


…


TRUE : state;

esac;

next(transition) :=

case





TRUE : transition;

esac;


Define initial state


VAR



ASSIGN


next(state) :=

case


…


TRUE : state;

esac;

next(transition) :=

case





TRUE : transition;

esac;


Define next state given a

transition


VAR



ASSIGN


next(state) :=

case


…


TRUE : state;

esac;

next(transition) :=

case





TRUE : transition;

esac;


Define legal transitions from a state

Example: Some properties we can prove

Petri NetUML

G ((imgcap | procimg) ->

moving)

G ((s.state = imagecapture |

s.state = processimage) ->

a.state = moving)

G (turning -> waiting) G (a.state = turning ->

s.state = waiting)

G (closeobs -> F turning) G (s.state = closeobs ->

F a.state = turning)

Approach 2: Direct, Deductive Reasoning

� A model transformation can be represented

as a series of rules in a control graph

� ADL (Assertion Description Language)

permits reasoning on such transformations

Rule 1

Rule 2

Rule 3

Rule 4

Assertion Description Language (ADL)

� An ADL sentence is of the form:

<location> : <assertion>

� A location is relative to a node in the control

graph, e.g. before(rule 1) or after(rule 1)

� An assertion has the form:

<operator> <pattern>

ADL Operators

The rule terminatesTerminates

P2 replaces every instance of P1ForEach P1 � P2

P2 replaces one instance of P1ForOne P1 � P2

If Pattern P1 is present, so is P2Any P1 � P2

Pattern P is in the modelExists P

Pattern P is not in the modelNone P

SemanticsOperator

Example: Flattening a model

Example adapted from Asztalos et al.

Example: Transformation rules

Rule 1 Rule 2 Rule 3

Example: Property and Precondition

� If a path exists before deleting the composite

node, the path exists afterwards:

� Before(rule 3): None P1

� Before(rule 3): None P2

� Preconditions:

� Before(rule 1): Any P1 � LHS1

� Before(rule 1): Any P2 � LHS1

Example: Proof

6

5

4

3

2

1

Modus Ponens with (3), (5)After(r2): None P2

Contrapositive of (4)Before(r2): None P2 �After(r2): None P2

Rule 2 only removes

composite edges

After(r2): Exists P2 �

Before(r2): Exists P2

(1), (2) + P2 is a subgraphof LHS1

After(r1): None P2

PreconditionBefore(r1): Any P2 � LHS1

Application of rule 1After(r1): None LHS1

JustificationDeduction

Note: Control graph is linear so Before(n) is equivalent to After(n)

Discussion

Requires use of

ADL, graph

transformations

Everything a black

box

Generality

Persistent artifactTransient processTransformation

considered…

All source modelsSingle source modelVerification coverage

Direct, DeductiveIndirect, Model Chk

Discussion

Unclear how

theoretical deduction rules can be efficiently

decided.

State explosion. Can

be alleviated during translation to tool.

Scalability

Manual proof required.Transformation to

tool formalism and of properties

Effort

Pattern-based properties

Language of chosen tool

Expressivity

Direct, DeductiveIndirect, Model Chk

References

[1] L. Ab. Rahim and J. Whittle. A survey of approaches for verifying model transformations. Software & Systems Modeling, pages 1-26, 2013.

[2] K. Anastasakis, B. Bordbar, and J. M. Kuster. Analysis of model transformations via Alloy. In Proceedings of the 4th MoDeVVaworkshop, Model-Driven Engineering, Verification and Validation, pages 47-56, 2007.

[3] M. Asztalos, L. Lengyel, and T. Levendovszky. Towards automated, formal verification of model transformations. In Software Testing, Verification and Validation (ICST), 2010 ThirdInternational Conference on, pages 15-24, April 2010.

[4] E. M. Clarke, O. Grumberg, and D. A. Peled. Model Checking. The MIT Press, 1999.

[5] H. Ehrig. Fundamentals of algebraic graph transformation, chapter General Introduction, pages 5-20. Springer Verlag, 2006.

References

[6] B. Hailpern and P. Tarr. Model-driven development: The good, the bad, and the ugly. IBM Syst. J., 45(3):451-461, July 2006.

[7] R. Heckel. Graph transformation in a nutshell. Electronic Notes in Theoretical Computer Science, 148(1):187-198, 2006. Proceedings of the School of SegraVis Research Training Network on Foundations of Visual Modelling Techniques (FoVMT 2004).

[8] T. Mens and P. V. Gorp. A taxonomy of model transformation. Electronic Notes in Theoretical Computer Science, 152(0):125-142, 2006. Proceedings of the International Workshop on Graph and Model Transformation (GraMoT 2005).

[9] T. Murata. Petri nets: Properties, analysis and applications. Proceedings of the IEEE, 77(4):541-580, Apr 1989.

[10] D. C. Schmidt. Guest editor's introduction: Model-driven engineering. Computer, 39(2):25-31, 2006.

[11] D. Varro and A. Pataricza. Automated formal verification of model transformations. In CSDUML 2003: Critical Systems Development inUML; Proceedings of the UML'03 Workshop, pages 63-78, September 2003.

on the correctness of model transformationscse814/lectures/modeltransformations.pdf · on the...

Documents