1 / 38

Dániel Varró Budapest University of Technology and Economics

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. Model checking in a modeling language.

kenyon-valencia
Download Presentation

Dániel Varró Budapest University of Technology and Economics

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. 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. 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. 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. Defining Visual Modeling Languages

  6. Automata Metamodels and instance models transitions current states from AccState State Transition color:{R,G,B} to Meta-level Model-level t3 fr to a1 s3 curr t3 st st s1 a1 s3 s1 t2 tr tr st fr to t1 s2 t1 s2 t2 to fr Abstract syntax Concrete syntax

  7. Automata Metamodels and instance models transitions current states from AccState State Transition to Meta-level Dynamic concept: potentially modified during model execution Static concept: never modified during model execution Model-level t3 fr to a1 s3 curr t3 st st s1 a1 s3 s1 t2 tr tr st fr to t1 s2 t1 s2 t2 to fr Abstract syntax Concrete syntax

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

  9. A1:Autom A1:Autom S1:State S1:State S2:State S2:State Application of a rule current current states states states states transitions transitions T1:Trans T1:Trans from to from to t3 fr to a1 s3 curr t3 st st s1 a1 s3 s1 t2 tr tr st fr to t1 s2 t1 s2 t2 to fr Initial state

  10. A1:Autom A1:Autom S1:State S1:State S2:State S2:State Application of a rule current current states states states states transitions transitions T1:Trans T1:Trans from to from to t3 fr to a1 s3 curr t3 st st s1 a1 s3 s1 t2 tr tr st fr to t1 s2 t1 s2 t2 to fr Pattern matching

  11. A1:Autom A1:Autom S1:State S1:State S2:State S2:State Application of a rule current current states states states states transitions transitions T1:Trans T1:Trans from to from to t3 fr to a1 s3 curr t3 st st s1 a1 s3 s1 t2 tr tr st fr to t1 s2 t1 s2 t2 to fr Non-determinism!

  12. A1:Autom A1:Autom S1:State S1:State S2:State S2:State Application of a rule current current states states states states transitions transitions T1:Trans T1:Trans from to from to t3 fr to a1 s3 curr t3 st st s1 a1 s3 s1 t2 tr tr st fr to t1 s2 t1 s2 t2 to fr Deletion

  13. A1:Autom A1:Autom S1:State S1:State S2:State S2:State Application of a rule current current states states states states transitions transitions T1:Trans T1:Trans from to from to t3 fr to a1 s3 curr t3 st st s1 a1 s3 s1 t2 tr tr st fr to t1 s2 t1 s2 t2 to fr Gluing

  14. A1:Autom A1:Autom S1:State S1:State S2:State S2:State Application of a rule current current states states states states transitions transitions T1:Trans T1:Trans from to from to t3 fr to a1 s3 curr t3 st st s1 a1 s3 s1 t2 tr tr st fr to t1 s2 t1 s2 t2 to fr Final state

  15. Model Checking Transitions 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. 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. 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. From Graph Transformation Systems to Transition Systems

  20. Overview: From GTS to TS States Transitions

  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. Initialization • Each object in the model has a unique id • Evaluation: • class[x] = TRUE if there exists (initially) an object xof type class, otherwise FALSE • assoc[x][y] = TRUEif there exists a link of type assoc between nodes xand y • attr[x] = val if the slot of type attrat node xhas value val • State of the TS: defined by the current evaluation of these predicates

  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. 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. Translating a GT rule into transitions • Find 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) • Extend partial matchings by dynamic parts in all possible (type compliant) combinations • Generate guarded commands • static parts are not included • only dynamic parts appear in guards and actions

  26. A1:Autom A1:Autom S1:State S1:State S2:State S2:State Example: Generating transitions current current states states states states transitions transitions T1:Trans T1:Trans from to from to t3 fr to curr st st s1 a1 s3 tr tr st fr to t1 s2 t2 to fr

  27. A1:Autom A1:Autom S1:State S1:State S2:State S2:State Find static matchings current current states states states states transitions transitions T1:Trans T1:Trans from to from to t3 fr to curr st st s1 a1 s3 tr tr st fr to t1 s2 t2 fr to

  28. A1:Autom A1:Autom S1:State S1:State S2:State S2:State Find static matchings current current states states states states transitions transitions T1:Trans T1:Trans from to from to t3 fr to curr st st s1 a1 s3 tr tr st fr to t1 s2 t2 to fr

  29. A1:Autom A1:Autom S1:State S1:State S2:State S2:State Find static matchings current current states states states states transitions transitions T1:Trans T1:Trans from to from to t3 fr to curr st st s1 a1 s3 tr tr st fr to t1 s2 t2 to fr

  30. A1:Autom A1:Autom S1:State S1:State S2:State S2:State Extend partial matchings current current states states states states transitions transitions T1:Trans T1:Trans from to from to t3 curr curr s1 a1 s3 curr t1 s2 t2 current[a1][s1] = TRUE -> current’[a1][s1] = FALSE current’[a1][s2] = TRUE

  31. A1:Autom A1:Autom S1:State S1:State S2:State S2:State Extend partial matchings current current states states states states transitions transitions T1:Trans T1:Trans from to from to t3 curr curr s1 a1 s3 curr t1 s2 t2 current[a1][s2] = TRUE -> current’[a1][s2] = FALSE current’[a1][s3] = TRUE

  32. A1:Autom A1:Autom S1:State S1:State S2:State S2:State Extend partial matchings current current states states states states transitions transitions T1:Trans T1:Trans from to from to t3 curr curr s1 a1 s3 curr t1 s2 t2 current[a1][s1] = TRUE -> current’[a1][s1] = FALSE current’[a1][s3] = TRUE

  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; 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. CheckVML: A Tool for Model Checking Visual Modeling Languages

  35. CheckVML: Tool architecture Metamodel Metamodel graph Metamodel of trans. systems (GXL) Instance model Model graph Transition system (GXL) GraTra rules Rule graphs (Lhs, Rhs) MC input (Promela) (GXL + XML) CheckVML Property Model checker (SPIN) (GXL) Yes / No + counter example

  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. 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. Thank You for Your Kind Attentionand many thanks toÁkos Schmidt (BUTE - for tooling CheckVML)Sebastian Thöne (UPB - for testing CheckVML)

More Related