1. Budapest University of Technology and EconomicsDagstuhl 2004 Department of Measurement and Information Systems 1 Towards Automated Formal Verification of Visual Modeling Langauges by Model Checking (The CheckVML approach) Dániel Varró Budapest University of Technology and Economics Department of Measurement and Information Systems

2. Budapest University of Technology and EconomicsDagstuhl 2004 Department of Measurement and Information Systems 2 Model checking in a modeling language Formal verification of UML models –to decide automatically whether the system meets its (functional) requirements –source: statecharts –target: model checkers (e.g., SPIN) BUT: there is life beyond statecharts… Model checking visual modeling languages –UML: activity models, interaction diagrams –formal analysis: Petri nets, dataflow nets, … –future modeling languages

3. Budapest University of Technology and EconomicsDagstuhl 2004 Department of Measurement and Information Systems 3 Problem statement and Objective Traditional approach: precise knowledge of –the semantics of the modeling language –the technicalities of the model checker (at least its low-level input language) Problem: it is very difficult and expensive –to map new languages to model checkers –to maintain existing tools (e.g. UML 1.x  2.0) Objective: a mapping into model checkers parameterized by the semantics of the language –hide the technicalities from domain engineers

4. Budapest University of Technology and EconomicsDagstuhl 2004 Department of Measurement and Information Systems 4 Outline of the talk Defining visual modeling languages –syntax: metamodeling –semantics: graph transformation systems (GTS) Transition systems (TS) and model checking A language-level encoding from GTS to TS The CheckVML tool Experimental results Conclusions and future work

5. Budapest University of Technology and EconomicsDagstuhl 2004 Department of Measurement and Information Systems 5 Defining Visual Modeling Languages

6. Metamodels and instance models StateAccStateTransition Automata from to transitions statescurrent t1s2t2 s1a1s3 t3 st tr fr to fr curr s2 s3 s1 t1 t2 t3 a1 Abstract syntaxConcrete syntax Meta-level Model-level color:{R,G,B}

7. Metamodels and instance models StateAccStateTransition Automata from to transitions statescurrent t1s2t2 s1a1s3 t3 st tr fr to fr curr s2 s3 s1 t1 t2 t3 a1 Abstract syntaxConcrete syntax Meta-level Model-level Dynamic concept: potentially modified during model execution Static concept: never modified during model execution

8. Graph transformation Graph transformation = meta-level (language level) operational semantics for modeling languages T1:TransS1:StateS2:State A1:Autom fromto states transitions current T1:TransS1:StateS2:State A1:Autom fromto states transitions current LHSRHS Diagrams to define dynamic behavior of a language are missing from the UML 2.0 Infrastructure !!!

9. Application of a rule T1:TransS1:StateS2:State A1:Autom fromto states transitions current T1:TransS1:StateS2:State A1:Autom fromto states transitions current t1s2t2 s1a1s3 t3 st tr fr to fr curr s2 s3 s1 t1 t2 t3 a1 Initial state

10. Application of a rule T1:TransS1:StateS2:State A1:Autom fromto states transitions current T1:TransS1:StateS2:State A1:Autom fromto states transitions current t1s2t2 s1a1s3 t3 st tr fr to fr curr s2 s3 s1 t1 t2 t3 a1 Pattern matching

11. Application of a rule T1:TransS1:StateS2:State A1:Autom fromto states transitions current T1:TransS1:StateS2:State A1:Autom fromto states transitions current t1s2t2 s1a1s3 t3 st tr fr to fr curr s2 s3 s1 t1 t2 t3 a1 Non-determinism!

12. Deletion Application of a rule T1:TransS1:StateS2:State A1:Autom fromto states transitions current T1:TransS1:StateS2:State A1:Autom fromto states transitions current t1s2t2 s1a1s3 t3 st tr fr to fr curr s2 s3 s1 t1 t2 t3 a1

13. Gluing Application of a rule T1:TransS1:StateS2:State A1:Autom fromto states transitions current T1:TransS1:StateS2:State A1:Autom fromto states transitions current t1s2t2 s1a1s3 t3 st tr fr to fr curr s2 s3 s1 t1 t2 t3 a1

14. Final state Application of a rule T1:TransS1:StateS2:State A1:Autom fromto states transitions current T1:TransS1:StateS2:State A1:Autom fromto states transitions current t1s2t2 s1a1s3 t3 st tr fr to fr curr s2 s3 s1 t1 t2 t3 a1

15. Budapest University of Technology and EconomicsDagstuhl 2004 Department of Measurement and Information Systems 15 Model Checking Transitions Systems

16. Budapest University of Technology and EconomicsDagstuhl 2004 Department of Measurement and Information Systems 16 Transition systems State variables pc : {odd, even} x : int Initialization pc = even x = 0 Transitions / Guarded commands pc = odd -> pc’ := even; x’ := x + 1 pc = even -> pc’ := odd; x’ := x + 1 Transition systems  Low-level C-like programming language Guard Action

17. Budapest University of Technology and EconomicsDagstuhl 2004 Department of Measurement and Information Systems 17 Model checking transition systems The model checking problem –Given a finite state transition system and a property (some temporal logic expression) –Decide whether the property holds in the system by traversing the entire state space Typical properties –safety: a bad thing will never happen –liveness: each request is served eventually Practical limitations –state variables must have finite domains (at compile time) –  300 state variables

18. Budapest University of Technology and EconomicsDagstuhl 2004 Department of Measurement and Information Systems 18 CheckVML: Problem definition Input: meta-level specification –a metamodel of the modeling language –a set of graph transformation rules as operational semantics of the language –an instance model of the language Output:model-level specification –a transition system that behaves equivalently to the original (graph transformation) system

19. Budapest University of Technology and EconomicsDagstuhl 2004 Department of Measurement and Information Systems 19 From Graph Transformation Systems to Transition Systems

20. Budapest University of Technology and EconomicsDagstuhl 2004 Department of Measurement and Information Systems 20 Overview: From GTS to TS States Transitions

21. Budapest University of Technology and EconomicsDagstuhl 2004 Department of Measurement and Information Systems 21 Type declarations, State variables State variables: For each dynamic... –class: one dimensional state variable array of bools –association: two dimensional state variable array of bools –attribute: one dimensional state variable array of an enumeration type Optimization for static concepts: –they never change  no state variables are required Restrictions for type declarations: –finite domains for enumeration –a priori (compile time) bounded number of nodes –associations are handled as relations

22. Budapest University of Technology and EconomicsDagstuhl 2004 Department of Measurement and Information Systems 22 Initialization Each object in the model has a unique id Evaluation: –class[x] = TRUE if there exists (initially) an object x of type class, otherwise FALSE –assoc[x][y] = TRUE if there exists a link of type assoc between nodes x and y –attr[x] = val if the slot of type attr at node x has value val State of the TS: defined by the current evaluation of these predicates

23. Budapest University of Technology and EconomicsDagstuhl 2004 Department of Measurement and Information Systems 23 Example: Type declarations, Initialization Naive approach AutID : TYPE = {a1}; StateID : TYPE = {s1, s2, s3}; ColorType : TYPE = {R,G,B}; automaton : ARRAY AutID OF Boolean state : ARRAY AutID OF Boolean states : ARRAY AutID OF ARRAY StateID OF Boolean current : ARRAY AutID OF ARRAY StateID OF Boolean color: ARRAY StateID OF ColorType INITIALIZATION automaton[a1] = TRUE; states[a1][s1] = TRUE;... current[a1][s1] = TRUE; current[a1][s2] = FALSE;... color[s1] = "R";...

24. Budapest University of Technology and EconomicsDagstuhl 2004 Department of Measurement and Information Systems 24 Example: Type declarations, Initialization Optimized approach: (after filtering static part) AutID : TYPE = {a1}; StateID : TYPE = {s1, s2, s3}; current : ARRAY AutID OF ARRAY StateID OF Boolean INITIALIZATION current[a1][s1] = TRUE; current[a1][s2] = FALSE;...

25. Budapest University of Technology and EconomicsDagstuhl 2004 Department of Measurement and Information Systems 25 Translating a GT rule into transitions 1Find all matchings of the static parts of the rule –these are partial matches of the entire rule –overapproximation: no more potential matches (as static parts do not change) 2Extend partial matchings by dynamic parts in all possible (type compliant) combinations 3Generate guarded commands –static parts are not included –only dynamic parts appear in guards and actions

26. Example: Generating transitions T1:TransS1:StateS2:State A1:Autom fromto states transitions current T1:TransS1:StateS2:State A1:Autom fromto states transitions current t1s2t2 s1a1s3 t3 st tr fr to fr curr

27. Find static matchings T1:TransS1:StateS2:State A1:Autom fromto states transitions current T1:TransS1:StateS2:State A1:Autom fromto states transitions current t1s2t2 s1a1s3 t3 st tr fr to fr curr

28. Find static matchings T1:TransS1:StateS2:State A1:Autom fromto states transitions current T1:TransS1:StateS2:State A1:Autom fromto states transitions current t1s2t2 s1a1s3 t3 st tr fr to fr curr

29. Find static matchings T1:TransS1:StateS2:State A1:Autom fromto states transitions current T1:TransS1:StateS2:State A1:Autom fromto states transitions current t1s2t2 s1a1s3 t3 st tr fr to fr curr

30. Extend partial matchings T1:TransS1:StateS2:State A1:Autom fromto states transitions current T1:TransS1:StateS2:State A1:Autom fromto states transitions current t1s2t2 s1a1s3 t3 curr current[a1][s1] = TRUE -> current’[a1][s1] = FALSE current’[a1][s2] = TRUE

31. Extend partial matchings T1:TransS1:StateS2:State A1:Autom fromto states transitions current T1:TransS1:StateS2:State A1:Autom fromto states transitions current t1s2t2 s1a1s3 t3 curr current[a1][s2] = TRUE -> current’[a1][s2] = FALSE current’[a1][s3] = TRUE

32. Extend partial matchings T1:TransS1:StateS2:State A1:Autom fromto states transitions current T1:TransS1:StateS2:State A1:Autom fromto states transitions current t1s2t2 s1a1s3 t3 curr current[a1][s1] = TRUE -> current’[a1][s1] = FALSE current’[a1][s3] = TRUE

33. Budapest University of Technology and EconomicsDagstuhl 2004 Department of Measurement and Information Systems 33 Summary of the example AutID : TYPE = {a1}; StateID : TYPE = {s1, s2, s3}; current : ARRAY AutID OF ARRAY StateID OF Boolean INITIALIZATION current[a1][s1] = TRUE; current[a1][s2] = FALSE; TRANSITION current[a1][s1] = TRUE -> current’[a1][s1] = FALSE; current’[a1][s2] = TRUE [] current[a1][s2] = TRUE -> current’[a1][s2] = FALSE; current’[a1][s3] = TRUE [] current[a1][s1] = TRUE -> current’[a1][s1] = FALSE; current’[a1][s3] = TRUE

34. Budapest University of Technology and EconomicsDagstuhl 2004 Department of Measurement and Information Systems 34 CheckVML: A Tool for Model Checking Visual Modeling Languages

35. Budapest University of Technology and EconomicsDagstuhl 2004 Department of Measurement and Information Systems 35 CheckVML: Tool architecture Metamodel graph Metamodel of trans. systems Transition system MC input (Promela) Model checker (SPIN) CheckVML Model graph Rule graphs (Lhs, Rhs) Metamodel (GXL) Instance model (GXL) (GXL + XML) GraTra rules Property (GXL) Yes / No + counter example

36. Budapest University of Technology and EconomicsDagstuhl 2004 Department of Measurement and Information Systems 36 Benchmarks (with and before CheckVML) Modeling + Verification benchmarks: for metamodeling + graph transformation –dining philosophers (a common benchmark to assess the performance of MC tools) safety, deadlock freedom –UML statecharts, Petri nets,... (at Budapest University of Technology and Economics) safety, liveness –modeling and analysis architectural styles (in cooperation with L. Baresi, R. Heckel, S. Thöne) reachability Using model checkers SPIN, Murphi, SAL Detailed information: D. Varró: Automated Formal Verification of Visual Modeling Languages by Model Checking. To appear soon in the Journal of Software and Systems Modeling, Springer.

37. Budapest University of Technology and EconomicsDagstuhl 2004 Department of Measurement and Information Systems 37 Conclusion and Future work Good news: –model checking parameterized with a modeling language is possible and now supported by a prototype tool –CheckVML: transformation into the input of a MC is much faster than the actual MC process Bad news: –model checking terminates within acceptable run-time only for relatively small models (12 dining philosophers  >256MB of memory) Future: –further optimizations driven by static well-formedness constraints of a language

38. Budapest University of Technology and EconomicsDagstuhl 2004 Department of Measurement and Information Systems 38 Thank You for Your Kind Attention and many thanks to Ákos Schmidt (BUTE - for tooling CheckVML) Sebastian Thöne (UPB - for testing CheckVML)