380 likes | 513 Views
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.
E N D
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 • 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
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
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
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
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
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 !!!
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
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
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!
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
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
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
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
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
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
Overview: From GTS to TS States Transitions
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
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
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"; ...
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; ...
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
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
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
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
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
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
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
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
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
CheckVML: A Tool for Model Checking Visual Modeling Languages
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
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.
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
Thank You for Your Kind Attentionand many thanks toÁkos Schmidt (BUTE - for tooling CheckVML)Sebastian Thöne (UPB - for testing CheckVML)