Presentation is loading. Please wait.

Presentation is loading. Please wait.

© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 5. Model Checking Modellbasierte Softwareentwicklung 1 17.01.2013.

Similar presentations


Presentation on theme: "© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 5. Model Checking Modellbasierte Softwareentwicklung 1 17.01.2013."— Presentation transcript:

1 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 5. Model Checking Modellbasierte Softwareentwicklung

2 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 2 Verification ? Testing can only show the presence of errors never their absence (Edsgar Dijkstra) Tested cases

3 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 3 Model Checking What is Model Checking? Two answers: … an automated proof method … a precise system analysis tool A rigorous proof that the program does what you say it should do This requires: Formal semantics:Kripke structure Formal specification: Temporal logic Method: Manual proof (up to 1981); today model checking! Reused slides (partially modified/combined) from: [Dwyer2002s] Matthew Dwyer. Kansas State University, USA Software Model Checking Tutorial FSE02 – Charleston, South Carolina – Nov. 19, 2002 [Dwyer2002s]

4 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 4 Model Checking Proof of M φ Question: Is the system a model of the formula? Model Checking algorithm searches the whole state space of the system State space needs to be finite

5 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Input-Output Patterns Reactive systems: Parallelism, distribution Interaction with their environment, no termination, hence Hoare Style proofs do not work High complexity, safety critical

6 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Model Checking Kripke- structure s0s0 s1s1 s2s2 s3s3 s4s4 s5s5 Model Checker × Counter example It is always true.. It is never true… Specification UML-Diagram (e.g. StateChart) Code Generation & Test Temporal logic formula (e.g. CTL, LTL, …)

7 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 7 Defines a state based transition graph, which specifies the behavior of a reactive system Kripke Structure S = {s 0, s 1, s 2, s 3, s 4 } T = {(s 0,s 1 ), (s 1,s 0 ), (s 1, s 2 ), (s 1, s 3 ), (s 2, s 3 ), (s 3, s 0 ), (s 3, s 4 ), (s 4, s 4 )} S 0 = {s 0 } L = {s 0 {p 0 }, s 1 {p 1 }, {s 2 } {p 0 }, s 3 {p 2 }, s 4 {p 1, p 2 }} Kripke Structure = (AP, S, L, T, S 0 ) AP: Set of atomic propositions S: finite set of states L: S (AP), labels T S x S, transitions, is left-total (every node is source node for at least one transition) S 0 : set of initial states s0s0 s1s1 s2s2 s3s3 s4s4 p0p0 p2p2 p1p1 p0p0 p 1, p 2 AP = {p 0, p 1, p 2 }

8 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Kripke Structure Path Tree s0s0 s1s1 s2s2 s3s3 s4s4 p0p0 p2p2 p1p1 p0p0 p1p1 s0s0 p0p0 s1s1 p1p1 s1s1 p1p1 s2s2 s3s3 s0s0 p0p0 p0p0 p2p2 s0s0 s4s4 p0p0 p1p1 s3s3 s4s4 s0s0 p0p0 p1p1 p2p2

9 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Microwave Example start close error S5S5 start close S6S6 start close heat S7S7 S1S1 start error S2S2 close S3S3 heat S4S4 AP := {start, close, error, heat}

10 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Microwave Example Properties: There is a state where MW heats The MW shall not heat if an error occured There is a state directly following the initial state where the door is closed start close error S5S5 start close S6S6 start close heat S7S7 S1S1 start error S2S2 close S3S3 heat S4S4 AP := {start, close, error, heat}

11 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Computation Tree Logic (CTL) CTL-Formula consist of: Atomic propositions (predicates on states) Boolean connectives,, Additional CTL-operators of the form: path quantifier + temporal operator Path Quantifier: A: for all paths holds… E: there is a path for which holds… Temporal Operator: X: Next F: Future G: Global U: Until

12 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Computation Tree Logic (CTL) Valid CTL-formulae are defined recursively as follows: Every atomic proposition (p, q, …) is a valid CTL-Formula. Let 1, 2 be CTL-formulae then the following formulae are valid CTL-formulae: Examples: p, p, p q, EF p, AG q, AG q, AG (EF p), (EX p) (AG q), A[ (EF p) U q ] EX 1 EF 1 EG 1 E[ 1 U 2 ] AX 1 AF 1 AG 1 A[ 1 U 2 ]

13 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn CTL-Operators Examples EX p p E[pUq] p p q AG p p p p AF p p p p There is a path where p holds in the next state. There is a path where p holds Until q holds. For all paths p holds at some point in the Future. For all paths p holds Globally (in every state). CTL: A path quantifier in front of every temporal operator

14 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Microwave Example Properties: There is a state where MW heats EF (heat) The MW shall not heat if an error occured AG ¬ (error heat) There is a state directly following the initial state where the door is closed EX (close) start close error S5S5 start close S6S6 start close heat S7S7 S1S1 start error S2S2 close S3S3 heat S4S4 AP := {start, close, error, heat}

15 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn State Explosion Problem Problem: number of states of a realistic system usually huge The number of states of a system is exponential in its number of variables Construction of the whole state space not always feasible (too little system memory) Solution: try to avoid explicit construction of state space (Later in this course)

16 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Software Model Checking: Reality Check Specifications are partial They do not define complete functional correctness Focus on crucial properties Cost of checking is enormous Must approximate What kinds of approximation are useful? OK or Software model Specification Model Checker Error trace Line 5: … Line 12: … Line 15:… Line 21:… Line 25:… Line 27:… … Line 41:… Line 47:… [Dwyer2002s]

17 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 17 Software Model Checking - Approximation OK Software model Specification Model Checker Error trace Line 5: … Line 12: … Line 15:… Line 21:… Line 25:… Line 27:… … Line 41:… Line 47:… No false positives No false negatives Approximation [Dwyer2002s]

18 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Model Construction Problem Semantic gap: Programming Languages with methods, inheritance, dynamic creation, exceptions, etc. Model Description Languages are only automata Model Description Model Checker Program void add(Object o) { buffer[head] = o; head = (head+1)%size; } Object take() { … tail=(tail+1)%size; return buffer[tail]; } Gap [Dwyer2002s]

19 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Output Interpretation Problem Raw error trace may be 1000s of steps long Must map line listing onto model description Mapping to source is made difficult by Semantic gap & clever encodings of complex features multiple optimizations and transformations Model Description Program void add(Object o) { buffer[head] = o; head = (head+1)%size; } Object take() { … tail=(tail+1)%size; return buffer[tail]; } Gap Error trace Line 5: … Line 12: … Line 15:… Line 21:… Line 25:… Line 27:… … Line 41:… Line 47:… [Dwyer2002s]

20 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Why is model-checking software difficult? Problems using existing checkers: Model construction Property specification State explosion Output interpretation OK Error trace or Finite-state model Temporal logic formula Model Checker Line 5: … Line 12: … Line 15:… Line 21:… [Dwyer2002s]

21 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Summary Instead of a complete specification use only one that consists of relevant properties (e.g., for safety) Usually only restricted notions for formal models Finite automata (or similar restricted models) Often restricted notions for formal properties Propositional logic Temporal logic (Model-Checking) Benefit: Counterexample when a property is not fulfilled Limitations: Not feasible for too large models (state explosion) Not feasible for too complex formal properties

22 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 5.1 CTL Model Checking Modellbasierte Softwareentwicklung 22

23 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Microwave Example Properties: There is a state where MW heats EF (heat) The MW shall not heat if an error occured AG ¬ (error heat) There is a state directly following the initial state where the door is closed EX (close) start close error S5S5 start close S6S6 start close heat S7S7 S1S1 start error S2S2 close S3S3 heat S4S4 AP := {start, close, error, heat}

24 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn CTL-Formula Reduction By EX, EG and EU all other properties can be expressed, as e.g. in AX f = EX ( f) EF f = E (true U f) AG f = EF ( f) AF f = EG ( f) A (f U g) = E ( g U ( f g)) EG g = (E ( g U (f g)) EG g) In the following only EX, EG, EU, and

25 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Model Checking Algorithm (1/2) Globally defined Kripke-Structure, label(s) is the set of all formulas which hold in a state s Iterative algorithm: In the i-th run check all sub-formulae of height i in the syntax tree of the formula ensures that no formula is examined before its sub-formulae are examined Example: EX (p EG q) function verify (Formula f) : boolean; for i = 0.. h do for all sub-formulae g of f of height i do check (g); end for all; end for; return s S 0 : f label(s) end verify; (h is height of the syntax tree of f)

26 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 26 function check (Formula f); switch case f APcheckAP(f)// label states with their atomic propositions case f = gcheckNegation(g)// check negations case f = g hcheckDisjunction(g, h) // check disjunction case f = EX gcheckEX(g) case f = EG gcheckEG(g) case f = E[gUh]checkEU(g, h) end switch end check; Model Checking Algorithm (2/2)

27 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn checkAP Function checkAP(g) marks a state s with the atomic proposition g if g holds in s function checkAP(g) for all s S do if g label(s) then label(s) := label(s) {g} end labelStates;

28 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 28 function check (Formula f); switch case f APcheckAP(f)// label states with their atomic propositions case f = gcheckNegation(g)// check negations case f = g hcheckDisjunction(g, h) // check disjunction case f = EX gcheckEX(g) case f = EG gcheckEG(g) case f = E[gUh]checkEU(g, h) end switch end check; Model Checking Algorithm (2/2)

29 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn checkNegation Function checkNegation(g) marks a state s with g if the sub-formula g does not hold in s function checkNegation(g) for all s S do if g label(s) then label(s) := label(s) { g} end labelStates;

30 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 30 Model Checking Algorithm (2/2) function check (Formula f); switch case f APcheckAP(f)// label states with their atomic propositions case f = gcheckNegation(g)// check negations case f = g hcheckDisjunction(g, h) // check disjunction case f = EX gcheckEX(g) case f = EG gcheckEG(g) case f = E[gUh]checkEU(g, h) end switch end check;

31 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn checkDisjunction Function checkDisjunction(g, h) marks all states for which g or h holds function checkDisjunction(g, h) for all s S do if g label(s) or h label(s) then label(s) := label(s) {g h} end labelStates;

32 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 32 function check (Formula f); switch case f APcheckAP(f)// label states with their atomic propositions case f = gcheckNegation(g)// check negations case f = g hcheckDisjunction(g, h) // check disjunction case f = EX gcheckEX(g) case f = EG gcheckEG(g) case f = E[gUh]checkEU(g, h) end switch end check; Model Checking Algorithm (2/2)

33 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn CheckEX Marks all states for which EX(g) holds Is there a path for which g holds in the next state? function checkEX(g) S 1 := {s | g label(s)} for all (s 1, s 2 ) T, s 2 S 1 do label(s 1 ) := label(s 1 ) {EX g} end checkEX; Remark: T S x S is left-total S1S1 S2S2 S4S4 S3S3 S5S5 g g f f f EX g

34 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 34 function check (Formula f); switch case f APcheckAP(f)// label states with their atomic propositions case f = gcheckNegation(g)// check negations case f = g hcheckDisjunction(g, h) // check disjunction case f = EX gcheckEX(g) case f = EG gcheckEG(g) case f = E[gUh]checkEU(g, h) end switch end check; Model Checking Algorithm (2/2)

35 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Strongly Connected Component Given: directed Graph G Strongly Connected Component C: Subgraph of G Any node of C is reachable by a (directed) path from any other node in C Non trivial Strongly Connected Component C is a Strongly Connected Component C has either more than one node or one node with a self referencing edge

36 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Example Non trivial SCC Trivial SCC

37 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn CheckEG: Example Marks all states for which EG (f) holds Is there a path for which f always holds? S1S1 f S2S2 f S7S7 g S3S3 f S4S4 f S5S5 f S6S6 f

38 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn CheckEG: Example M0 = {S3, S4, S5} M1 = {S3, S4, S5, S2} M2 = {S3, S4, S5, S2, S1} S1S1 f S2S2 f S3S3 f S4S4 f S5S5 f S6S6 f {f} {EG(f)}

39 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn CheckEG function checkEG(f) S 1 := {s | f label(s)} SCC := {C | nontrivial SCC of S 1 } S 2 := c SCC {s | s C} for all s S 2 do label(s) := label(s) {EG f} end for all while S 2 do choose s S 2 S 2 := S 2 \ {s} for all (s, s) T, s S 1 do if EG f label(s) then label(s) := label(s) {EG f} S 2 := S 2 {s} end if end for all end while end checkEG

40 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 40 function check (Formula f); switch case f APcheckAP(f)// label states with their atomic propositions case f = gcheckNegation(g)// check negations case f = g hcheckDisjunction(g, h) // check disjunction case f = EX gcheckEX(g) case f = EG gcheckEG(g) case f = E[gUh]checkEU(g, h) end switch end check; Model Checking Algorithm (2/2)

41 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn CheckEU Marks all states for which E[fUg] holds CheckEU(f,g): is there a path where f holds until g holds M0 = {S4, S5} M1 = {S4, S5, S2} M2 = {S4, S5, S2, S1} S1S1 S2S2 S5S5 S4S4 S3S3 f f g g h E[fUg]

42 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn CheckEU function CheckEU(f,g) S 1 := {s | g label(s)} for all s S 1 do label(s) := label(s) {E[fUg]} end for all while S 1 choose s S 1 S 1 := S 1 \ {s} for all (s, s) T do if E[fUg] label(s) and f label(s) then label(s) := label(s) {E[fUg]} S 1 := S 1 {s} end if end for all end while end checkEU


Download ppt "© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 5. Model Checking Modellbasierte Softwareentwicklung 1 17.01.2013."

Similar presentations


Ads by Google