5. Model Checking Modellbasierte Softwareentwicklung 17.01.2013.

Name: 5. Model Checking Modellbasierte Softwareentwicklung 17.01.2013.
Uploaded: 2018-01-09T21:19:29+00:00
Duration: PTM40S5
Channel: Victoria Mooney
Description: 5. Model Checking Modellbasierte Softwareentwicklung 17.01.2013.

5. Model Checking Modellbasierte Softwareentwicklung

„Testing can only show the presence of errors never their absence“
Verification? Tested cases „Testing can only show the presence of errors never their absence“ (Edsgar Dijkstra) In der letzten Vorlesung wurde Testen behandelt. Testen ist eine Möglichkeit herauszufinden, ob eine Software sich so verhält, wie es von ihr erwartet wird. Dazu wird die Software in einigen repräsentativen Situationen ausgeführt. Es ist wichtig, Fehler frühzeitig zu erkennen, da deren Beseitigung umso kostengünstiger ist, je eher sie gefunden werden. Deshalb systematisch Testen. Klar festlegen, welche Ergebnisse erwartet werden und wie diese Ergebnisse erreicht werden sollen. Das habt ihr letzte Woche gelernt. Allerdings ist es nicht möglich, ein System unter allen möglichen Bedingungen zu testen. Das ist vor allem bei Systemen in sicherheitskritischen Umgebungen ein Problem, wie zum Beispiel bei Eisenbahnen. Bild erklären

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! [Dwyer2002s] Model Checking ist eine Technik, um endliche Zustandssysteme zu verifizieren. Also zu beweisen, dass diese korrekt sind (eine Spezifikation erfüllen). Außerdem wird mit „Model Checker“ auch das Werkzeug bezeichnet, mit dem Modelle verifiziert werden. Model Checking ist der Beweis über die Korrektheit eines Programms. Also der Beweis, dass ein Programm tut, was es soll. Testen ist kein Beweis sondern ein Experiment. Da wir einen formalen Beweis führen wollen, brauchen wir dazu auch formale Eingaben. Also eine formale Semantik für die Modelle, mit denen wir unser System modellieren, eine formale Spezifikationssprache, mit der wir die Anforderungen an das System formulieren und eine Methode, die den Beweis durchführt. “Reused” slides (partially modified/combined) from: [Dwyer2002s] Matthew Dwyer. Kansas State University, USA Software Model Checking Tutorial FSE’02 – Charleston, South Carolina – Nov. 19, 2002

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

Input-Output Patterns
Reactive systems: Parallelism, distribution Interaction with their environment, no termination, hence Hoare Style proofs do not work High complexity, safety critical Reaktive Systeme: Eingebettete Systeme - Automotive Hoare: {P}S{Q} Die Semantik des Modells ist ein Transitionssystem - was ist ein Transitionssystem? – ein Automat - Das Transitionssystem, was beim Model Checking verwendet wird, ist eine Kripke-Struktur – sehen wir gleich Spezifikation in Form einer temporalen Logik bis 1981 wurden die Beweise manuell geführt. Ihr wisst hoffentlich noch alle aus der Modellierung, wir aufwendig solche Beweise schon für kleine Programme sind. Deshalb ist es wünschenswert, die Beweise automatisch zu machen – Model Checking

×  Model Checking UML-Diagram (e.g. StateChart) Kripke- structure
It is always true.. It is never true… Specification UML-Diagram (e.g. StateChart) Code Generation & Test Kripke- structure s0 s1 s2 s3 s4 s5  Model Checker × Counter example Model Checking Prozess: Modellierung: Konvertiere das Design in ein Format, das vom Model Checker akzeptiert wird Meistens nur eine Übersetzungsaufgabe In anderen Fällen muss man vom Design abstrahieren und irrelevante oder unwichtige Details entfernen Spezifikation: Vor der Verifikation müssen die Eigenschaften ausgedrückt werden, die das Design erfüllen soll. Die Spezifikation wird mit Hilfe eines logischen Formalismus ausgedrückt. Für Software wird temporale Logik verwendet. Damit kann ausgedrückt werden, wie sich das Systemverhalten über der Zeit entwickelt. Vollständigkeit der Spezifikation kann allerdings nicht überprüft werden – ob sie alle Eigenschaften des Systems abdeckt. Model Checking automatisch Wenn das Modell die Spezifikation erfüllt, wird ok ausgegeben und aus dem Modell kann Code generiert werden und anschließend kann der Code getestet werden. z.B. Integration in der Umgebung Wenn das Modell die Spezifikation nicht erfüllt, wird ein Gegenbeispiel ausgegeben. Das ist ein Pfad im Modell, der die Spezifikation nicht erfüllt. Das Gegenbeispiel muss manuell analysiert werden. Es hilft allerdings, den Fehler im Modell ausfindig zu machen. Dabei weiß man allerdings nicht, ob das Modell falsch ist oder die Spezifikation Es kann auch passieren, dass der Model Checker nicht normal terminiert, weil das Modell nicht in den Speicher des Rechners passt. Dann Optionen des Model Checkers anpassen oder Modell oder Spezifikation ändern (F W) Temporal logic formula (e.g. CTL, LTL, …)

Kripke Structure Defines a state based transition graph, which specifies the behavior of a reactive system s1 s2 p1 p0 Kripke Structure = (AP, S, L, T, S0) 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) S0: set of initial states s3 p2 s4 s0 p1, p2 p0 AP = {p0, p1, p2} Kripke Strukur – Eingabemodell des Model Checkers Im wesentlichen ein endlicher Automat mit Aussagen an den Zuständen Links-totale Relation – Jedes Element kommt mindestens einmal als linkes Element eines Tupels vor. Mit anderen Worten: Jeder Zustand der Menge S hat mind. eine ausgehende Transition. S = {s0, s1, s2, s3, s4} L = {s0 → {p0}, s1 → {p1}, {s2} → {p0}, s3 → {p2}, s4 → {p1, p2}} T = {(s0,s1), (s1,s0), (s1, s2), (s1, s3), (s2, s3), (s3, s0), (s3, s4), (s4, s4)} S0 = {s0}

Kripke Structure Path Tree
Kripke-Struktur wird zu einem Baum aufgefaltet, damit man alle Pfade im Modell untersuchen kann. Der Baum kann z.B. mit Tiefen- oder Breitensuche generiert werden.

AP := {start, close, error, heat}
Microwave Example S1 S2 S4 S3 start error close heat close S5 S6 S7 start close error start close start close heat AP := {start, close, error, heat}

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 S1 S2 S4 S3 start error close heat close S5 S6 S7 start close error start close start close heat AP := {start, close, error, heat}

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 Spezifikationen werden mit temporalen Logiken ausgedrückt.

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 ]  1 1  2 1  2 1  2 EX 1 EF 1 EG 1 E[ 1 U 2 ] AX 1 AF 1 AG 1 A[ 1 U 2 ] Spezifikationen werden mit temporalen Logiken ausgedrückt.

CTL-Operators Examples
EX p p E[pUq] p q „There is a path where p holds in the next state.“ „There is a path where p holds Until q holds.“ AF p p AG p p „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

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) S1 S2 S4 S3 start error close heat close S5 S6 S7 start close error start close start close heat AP := {start, close, error, heat}

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) holzmann – spin entwickler

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? [Dwyer2002s] OK Model Checker Software model or Error trace (F W) Line 5: … Line 15:… Line 12: … Line 21:… Line 25:… Line 27:… Line 41:… … Line 47:… Specification

Software Model Checking - Approximation
[Dwyer2002s] Approximation No false positives OK Model Checker Software model No false negatives Error trace Line 5: … Line 12: … Line 15:… Line 21:… Line 25:… Line 27:… … Line 41:… Line 47:… (F W) We are interested in model-checking because it works a lot like the dream: However, instead of processing source code, a model-checker processes a finite-statemachine that abstractly models the computation of some system. Instead of a software specification, the checker processes a specification in temporal logic that describes some invariant or some event sequencing property that you would like to hold in the model. <click> When feed these to the model-checker, the checker will explore all possible paths in the finite-state machine to see if the specification is satisfied. The model-checker will then answer OK, your model satisfies the temporal specification, or No, the model doesn’t satisfy the specification, and by the way, here’s a listing of the transitions in the model that cause the specification to be violated. Time: 1 min Specification

Model Construction Problem
Semantic gap: Programming Languages with methods, inheritance, dynamic creation, exceptions, etc. Model Description Languages are only automata [Dwyer2002s] void add(Object o) { buffer[head] = o; head = (head+1)%size; } Object take() { … tail=(tail+1)%size; return buffer[tail]; Model Checker Gap Program Model Description Was, wenn man jetzt ein Programm hat und kein Modell? Dann muss das Programm auf ein Modell abgebildet werden.

Output Interpretation Problem
Raw error trace may be 1000’s 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 [Dwyer2002s] Error trace Line 5: … Line 12: … Line 15:… Line 21:… Line 25:… Line 27:… … Line 41:… Line 47:… void add(Object o) { buffer[head] = o; head = (head+1)%size; } Object take() { … tail=(tail+1)%size; return buffer[tail]; Gap Model Description Program

Why is model-checking software difficult?
Problems using existing checkers: Model construction Property specification State explosion Output interpretation [Dwyer2002s] OK Error trace or Finite-state model Temporal logic formula Model Checker (F W) Line 5: … Line 12: … Line 15:… Line 21:…

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 Sinnvolles Beispiel fehlte bisher.

5.1 CTL Model Checking Modellbasierte Softwareentwicklung

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) S1 S2 S4 S3 start error close heat close S5 S6 S7 start close error start close start close heat AP := {start, close, error, heat}

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  Wir müssen und können alle Formeln auf diese Quantoren-Operatoren-Paare reduzieren, weil der Model Checking Algorithmus damit arbeitet.

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  S0: f  label(s) end verify; (h is height of the syntax tree of f)

function check (Formula f); switch case f  AP checkAP(f) // label states with their atomic propositions case f = g checkNegation(g) // check negations case f = g  h checkDisjunction(g, h) // check disjunction case f = EX g checkEX(g) case f = EG g checkEG(g) case f = E[gUh] checkEU(g, h) end switch end check; Aussagen mit nur einer atomaren Aussage werden einfach gelabelt für oder wird für jede atomare Aussage die Funktion aufgerufen und alle mit f und g gelabelt danach werden alle in denen f oder g steht mit der formel gelabelt. Die temporalen Operatoren sind ein bisschen komplizierter und werden im folgenden genauer betrachtet.

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;

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;

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;

CheckEX Marks all states for which EX(g) holds
Is there a path for which g holds in the next state? function checkEX(g) S1 := {s | g  label(s)} for all (s1, s2)  T, s2  S1 do label(s1) := label(s1)  {EX g} end checkEX; Remark: T  S x S is left-total S5 f EX g S4 S3 f g Nimm alle Zustände, die mit g markiert sind Dann nimm für alle Zustände die Kanten, die auf diese Zustände zeigen und markiere den Quellzustand mit Ex g S1 S2 f g

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

Example 1 2 4 5 3 Trivial SCC Non trivial SCC Non trivial SCC

CheckEG: Example Marks all states for which EG (f) holds
Is there a path for which f always holds? S6 f S7 S3 S5 g f f S1 S2 S4 f f f

CheckEG: Example M0 = {S3, S4, S5} M1 = {S3, S4, S5, S2}
M2 = {S3, S4, S5, S2, S1} S6 f {f}  {EG(f)} {f}  {EG(f)} S3 f S5 f {f}  {EG(f)} {f}  {EG(f)} S1 f S2 f S4 f {f}  {EG(f)}

CheckEG function checkEG(f) S1 := {s | f  label(s)}
SCC := {C | nontrivial SCC of S1} S2 := c SCC{s | s  C} for all s S2 do label(s) := label(s)  {EG f} end for all while S2   do choose s  S2 S2 := S2 \ {s} for all (s‘, s)  T, s‘  S1 do if EG f  label(s‘) then label(s‘) := label(s‘)  {EG f} S2 := S2  {s‘} end if end for all end while end checkEG S1: markiere alle Zustände, in denen f gilt S2: Vereinigung der starken Zusammenhangskomponenten Alle Zustände in starken Zusammenhangskomponenten werden mit EGf markiert WHILE: nimm einen Zustand aus den starken Zusammenhangskomponenten raus Markiere alle Zustände von Transitionen, die auf den Zustand zeigen und in S1 sind mit EG f Nimm den Zustand in S2 auf, um seine Vorgänger zu untersuchen

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} E[fUg] S2 S3 f h S4 g E[fUg] S1 S5 E[fUg] g f

CheckEU function CheckEU(f,g) S1 := {s | g  label(s)}
for all s  S1 do label(s) := label(s)  {E[fUg]} end for all while S1   choose s  S1 S1 := S1 \ {s} for all (s‘, s)  T do if E[fUg]  label(s‘) and f  label(s‘) then label(s‘) := label(s‘)  {E[fUg]} S1 := S1  {s‘} end if end for all end while end checkEU packe in S1 alle Knoten, die mit g markiert sind markiere alle Knoten, die mit g markiert sind mit E(f U g) durchsuche alle s in S1 wähle ein s aus und entferne es aus S1 (solange, bis S leer ist) untersuche alle Quellknoten von Transitionen, die auf s zeigen wenn sie noch nicht mit E(f U g) markiert sind und mit f markiert sind, markiere sie mit E(f U g) dann nimm den Knoten in S1 auf, damit seine Vorgänger untersucht werden können.

5. Model Checking Modellbasierte Softwareentwicklung 17.01.2013.

Similar presentations

Presentation on theme: "5. Model Checking Modellbasierte Softwareentwicklung 17.01.2013."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

5. Model Checking Modellbasierte Softwareentwicklung 17.01.2013.

Similar presentations

Presentation on theme: "5. Model Checking Modellbasierte Softwareentwicklung 17.01.2013."— Presentation transcript:

Similar presentations

About project

Feedback