Beispiel 1 zur Verifikation eines bedingten Anweisung. Hoare-Regel für die bedingte Anweisung. Beispiel 2 zur Verifikation eines bedingten Anweisung

Transkript

1 Hoare-Regel für die bedingte Anweisung I1 : I2 : {B und P } S 1 {Q} { nicht B und P } {Q} {P } if (B) then S 1 {Q} {B und P } S 1 {Q} { nicht B und P } S 2 {Q} {P } if (B) then S 1 S 2 {Q} In der Regel für bedingte Anweisungen wird die Bedingung der Anweisung in weitere Bedingungen in den Zusicherungen umgewandelt. Da die Handlungsstränge des Programmes wieder zusammenlaufen, muss in beiden Alternativen die selbe Nachbedingung erreicht werden. Eine gemeinsame Nachbedingung kann durch Abschwächungsregeln erreicht werden: durch Abstraktion wie im Beispiel oder durch disjunktive Verknüpfung der einzelnen Nachbedingungen. Beispiel 1 zur Verifikation eines bedingten Anweisung {a Z} if (a >0) then {a Z und a>0} {a Z und a>0 und a = a} b := a; {a Z und a>0 und b = a} {a Z und b = a } {a Z und nicht a>0} {a Z und a 0 und a = a} b := a; {a Z und a 0 und b = a} {a Z und b = a } {a Z und b = a } Vorgehensweise bei bekannter Vorbedingung {P } Vorbedingung zu den Vorbedingungen {P und B} im then-teil und {P und nicht B} im -Teil ergänzen. then-teil und -Teil verifizieren mit Nachbedinugungen {Q 1 } bzw. {Q 2 }. Nachbedinungen zu gemeinsamer Nachbedingung {Q} abschwächen (z.b. Q (Q 1 oder Q 2 ). Nachbedingung {Q} der bedingten Anweisung einfügen. c LETTMANN 2003/04 Modellierung Verifikation V-31 c LETTMANN 2003/04 Modellierung Verifikation V-32 Beispiel 2 zur Verifikation eines bedingten Anweisung Beispiel 2 zur Verifikation eines bedingten Anweisung {a >0 und b>0 und a b} if (a >b) then {a >0 und b>0 und a b} if (a >b) then {a >0 und b>0 und a b und a>b} {a b>0 und b>0} {a >0 und b>0 und a b und a b} {a>0 und b a>0} c LETTMANN 2003/04 Modellierung Verifikation V-33 c LETTMANN 2003/04 Modellierung Verifikation V-34

2 Hoare-Regel für die Schleife Beispiel 1 zur Verifikation einer Schleife L : {I und B} S {I} {I} while (B) do S {I und nicht B} Gilt die Zusicherung I vor Ausführung der Schleife und gilt ferner, dass die Ausführung des Schleifenrumpfes S, falls sie terminiert, einen Zustand erzeugt, in dem I gilt, vorausgesetzt vor Ausführung der Schleife galt die Zusicherung (I und B), so gilt I nach jeder Ausführung des Schleifenrumpfes S. Da I nach jeder Ausführung des Schleifenrumpfes gilt, so gilt I nach der Schleife, sofern diese terminiert. Zusätzlich gilt nach der Schleife die Schleifenbedingung natürlich nicht und kann daher negiert zur Nachbedingung ergänzt werden. Wenn die Schleifenbedingung von Anfang an nicht gilt, so wird die Schleife nicht durchlaufen. Da I vor der Schleife gilt, so gilt I daher auch nach der Schleife und damit auch (I und nicht B). Die Verifikation mit der Schleifenregel zeigt NICHT die Terminierung der Schleife. Das Finden der Invarianten stellt in der Programmverifikation i.d.r. den schwierigsten Schritt dar. Die Verifikation einer Schleife entspricht einem induktiven Beweis. Die Invariante entspricht der Induktionsbehauptung. {x + y = a und x 0} Invariante while (x >0) do {x + y = a und x 0 und x>0} {x 1+y +1=a und x 1 0} x := x 1; {x + y +1=a und x 0} y := y +1; {x + y = a und x 0} {x + y = a und x 0 und x 0} {x + y = a und x =0} Wie entdeckt man eine Invariante? Bei der Programmerstellung eine Invariante zur Verifikation vorgeben und als Kommentar in den Programmtext einfügen. Ansonsten ist die einzige Möglichkeit, die Implementation vollständig zu begreifen, aus Durchläufen durch den Schleifenrumpf mit Beispielwerten ein Verständnis für die Veränderung der Zustände zu entwickeln und dieses Verständnis in eine Invariante umzusetzen. Invarianten sind nicht eindeutig. c LETTMANN 2003/04 Modellierung Verifikation V-35 c LETTMANN 2003/04 Modellierung Verifikation V-36 Beispiel zur Verifikation: Potenzieren (1) Beispiel zur Verifikation: Potenzieren (2) Idee des Algorithmus: Rückführung der Potenzierung auf die iterierte Multiplikation Variable x und n bleiben unverändert, damit Eingabewerte zugreifbar bleiben. Variable b speichert das Ergebnis. {b = x n } c LETTMANN 2003/04 Modellierung Verifikation V-37 c LETTMANN 2003/04 Modellierung Verifikation V-38

3 Beispiel zur Verifikation: Potenzieren (3) Suche nach einer Invarianten Tautologische Aussagen sind immer invariant, aber sie helfen nicht. Betrachte Werteverlauf in der Schleife für beteiligte Variablen. Variablenwerte bei Test der Bedingung in while Invariante: {x n = b a i und i 0} x n a b i Beispiel zur Verifikation: Potenzieren(4) {x R und n N und x = x} {x R und n N und a = x} {x R und n N und a = x und 1=1} {x R und n N und a = x und b =1} {x R und n N und a = x und b =1 und n = n} {x R und n N und a = x und b =1 und i = n} {x n = b a i und i 0} Invariante {x n = b a i und i 0 und i>0} {x n = b a i und i>0} {x n = b a a i 1 und i>0} {x n = b a i 1 und i>0} {x n = b a i 1 und i 1 0} {x n = b a i und i 0} {x n = b a i und i 0 und i 0} {x n = b a i und i =0} {x n = b} {b = x n } c LETTMANN 2003/04 Modellierung Verifikation V-39 c LETTMANN 2003/04 Modellierung Verifikation V-40 Beispiel zur Verifikation: Effizientes Potenzieren (1) Beispiel zur Verifikation: Effizientes Potenzieren (2) Idee des Algorithmus: Quadrieren von Teilergebnissen spart die Hälfte der Multiplikationen. Sei n k n k 1...n 2 n 1 n 0 die Dualdarstellung von n, alson = Es gilt dann x n = k n i 2 i. i=0 k (x 2i ) n i, wobei in diesem Produkt nur die i=0 Faktoren für n i =1eine Rolle spielen, und außerdem gilt { 1 falls n/2 i ungerade n i = 0 sonst Damit ergibt sich folger Algorithmus zur Potenzierung: if (i ungerade ) then a := a 2 ; i := i/2; {x R und n N und a = x und b =1 und i = n} {x n = b a i und i 0} Invariante {x n = b a i und i 0 und i>0} {x n = b a i und i>0} if (i ungerade ) then {x n = b a i und i>0 und i ungerade } {x n = b a (a 2 ) [i/2] und i>0 und i ungerade } {x n = b (a 2 ) [i/2] und i>0 und i ungerade } {x n = b (a 2 ) [i/2] und i>0} {x n = b a i und i>0 und i gerade } {x n = b (a 2 ) [i/2] und i>0 und i gerade } {x n = b (a 2 ) [i/2] und i>0} {x n = b (a 2 ) [i/2] und i>0} a := a 2 ; {x n = b a [i/2] und i>0} {x n = b a [i/2] und [i/2] 0} i := i/2; {x n = b a i und i 0} {x n = b a i und i 0 und i 0} {x n = b a i und i =0} {x n = b} {b = x n } c LETTMANN 2003/04 Modellierung Verifikation V-41 c LETTMANN 2003/04 Modellierung Verifikation V-42

4 Invarianten Terminierung Schleifeninvarianten sind Zusicherungen, d.h. sie beschreiben Zusammenhänge von Programmgrößen. Eine Invariante muss vor der Schleife gültig sein. Eine Invariante muss nach Durchlauf durch den Schleifenrumpf gültig sein, wenn sie vor dem Schleifenrumpf gültig war (zusammen mit der Schleifenbedingung). Invarianten sind zum Zeitpunkt der Implementierung leichter zu bestimmen. Der Nachweis der totalen Korrekheit eines Programms erfordert neben der bisher betrachteten partiellen Korrektheit den Nachweis seiner Terminierung. Wann ist Terminierung ein Problem? In Zuweisungen, falls der arithmetische Ausdruck nicht berechenbar ist (z.b. Division durch 0, nicht initialisierte Variable), in bedingten Anweisungen, falls die Bedingung nicht entschieden werden kann oder falls die Anweisungen im then-teil oder im -Teil nicht terminieren, in Anweisungsfolgen, falls eine Anweisung darin nicht terminiert, aber vor allem in Schleifen. Ausser in Schleifen kann die Terminierung garantiert werden,indem man die Art der arithmetischen oder booleschen Ausdrücke auf einfache Formen beschränkt (Komplexitätstheorie: Addition, Subtraktion von 1, also x := x +1;und Test auf 0, also if (x =0)...). Wir beschränken uns daher auf Terminierungsbeweise für Schleifen. c LETTMANN 2003/04 Modellierung Verifikation V-43 c LETTMANN 2003/04 Modellierung Verifikation V-44 Terminierung von Schleifen Beispiel zum Terminierungsbeweis einer Schleife Eine Schleife while (B) do S terminiert unter der Vorbedingung P genau dann, wenn jede Ausführung von S terminiert und wenn ein ganzzahliger Ausdruck T existiert, so dass folge Aussagen gelten: 1. P I 2. (T 0 und I) nicht B 3. {T = i +1 und B und I} S {T = i und I} I bezeichnet dabei eine Invariante der Schleife und i ein Bezeichner für eine ganzzahlige Variable ist, die weder in T noch in der Schleife vorkommt, d.h. nicht in B und nicht in S. T heißt auch Terminierungsfunktion oder Variante der Schleife. Ganzzahliger Ausdruck: T = x Invariante: I =(x + y = a und x 0) Schleifenbedingung: B =(x>0) Nachweis (T 0) und I nicht B x 0 und (x + y = a und x 0) x =0 x 0 Nachweis der Invarianz von I und der Dekrementierung von T while (x >0) do {x = i +1 und x + y = a und x 0 und x>0} {x 1=i und x 1+y +1=a und x 1 0} x := x 1; {x = i und x + y +1=a und x 0} y := y +1; {x = i und x + y = a und x 0} c LETTMANN 2003/04 Modellierung Verifikation V-45 c LETTMANN 2003/04 Modellierung Verifikation V-46

5 Nachweis der Terminierung von Schleifen Terminierung: Ein Problem? Insgesamt sind fünf Nachweise erforderlich: Terminierung des Schleifenrumpfes Ganzzahligkeit von T Folgerbarkeit der Nicht-Gültigkeit der Schleifenbedingung aus T 0 und einer Invarianten I Folgerbarkeit dieser Invarianten I aus der Vorbedingung der Schleife Nachweis der Invarianz von I und Nachweis der Dekrementierung von T Die Invariante I muss nicht mit der Invarianten für den Nachweis der partiellen Korrektheit der Schleife übereinstimmen. Die Gestalt der Hoare-Regel für die Schleife erlaubt keinen gleichzeitigen Nachweis von partieller Korrektheit und Terminierung. Manche Schleifen terminieren immer! while (a b) do while (a >b) do while (b >a) do Manche Schleifen terminieren nicht immer! while (a b) do while (a b) do while (b >a) do Für manche Schleifen ist nicht bekannt, ob sie terminieren! {n N und n>0} while (n 1)do if (n gerade ) then n := n/2; n := 3 n 1; Ulam s Funktion Die Terminierung von Schleifen ist unentscheidbar. c LETTMANN 2003/04 Modellierung Verifikation V-47 c LETTMANN 2003/04 Modellierung Verifikation V-48 Alternative Formulierung des Terminierungsnachweises Zeige Terminierung des Schleifenrumpfes. Bestimme einen ganzzahligen Ausdruck T über den Variablen des Programms. Zeige, dass T in jedem Durchlauf der Schleife verkleinert wird (streng monoton fall). Zeige, dass T nach unten beschränkt ist (T bound ist invariant). Anstelle des streng monoton fallen Ausdruckes T kann auch ein streng monoton wachser ganzzahliger Ausdruck gewählt werden mit eine oberen Schranke. Sind die beiden Formulierungen gleichwertig? Eine Schleife Nicht-Terminierung von Schleifen while (B) do S terminiert nicht, wenn eine Zusicherung I NT existiert, so dass folge Aussagen gelten: 1. Es gibt Eingaben, so dass {B und I NT } vor der Schleife gültig ist. 2. {B und I NT } ist Invariante der Schleife. I NT bezeichnet also eine Zusicherung, die nur in bestimmten Eingabesituationen gültig ist. Beim Nachweis der partiellen Korrektheit und der Terminierung müssen die verweten Zusicherungen in allen denkbaren Zuständen des Programmes an den entsprechen Stellen gelten. c LETTMANN 2003/04 Modellierung Verifikation V-49 c LETTMANN 2003/04 Modellierung Verifikation V-50

6 Notwigkeit von Verifikation Informationssicherheit (Security) Vertraulichkeit Integrität Authentizität Nicht-Rückweisbarkeit (Signaturgesetz) Zertifizierung von IT-Systemen durch das Bundesamt für Sicherheit in der Informationstechnik. (Höhere Stufen der Vertrauenswürdigkeit erfordern formale Spezifikation und formale Verifikation.) Beispiele Home Banking Geld- und Chipkarten Systemsicherheit (Safety) Software für sicherheitskritische Systeme ist formal zu spezifizieren und zu verifizieren. Beispiele: Eingebettete Systeme (Embedded Systems) als Regelungssysteme / reaktive Systeme unter Berücksichtigung von Realzeitaspekten in Autos, Flugzeugen, Raumfahrzeugen, Anlagensteuerungen. Anmerkungen zum Testen Tests können die Anwesenheit von Fehlern beweisen, aber nie die Abwesenheit von Fehlern (bei unlich vielen möglichen Eingaben). Klassifikation von Testverfahren: Schnittstellentest (Blackbox-Test) Die Ein- / Ausgaberelation wird auf Übereinstimmung mit der Spezifikation geprüft. Programmabhängiger Test (Whitebox-Test) Möglichst große Teile aller Pfade durch das Programm werden getestet. Eine möglichst große Überdeckung (des Programmcodes) ist erwünscht. Systematische Auswahl von Testfällen: Schnittstellentest Pro spezifizierter Bedingung mindestens einen Testfall prüfen, Randbereiche (ggf. von beiden Seiten) prüfen, Maximal-, Minmalwerte nicht vergessen, eine genüg große Anzahl von Normalfällen prüfen. Überdeckungstest Erwünscht, aber kaum machbar ist eine Wegüberdeckung d.h. jeder Weg wird mindestens einmal durchlaufen. Auf jeden Fall nötig ist eine Anweisungsüberdeckung, d.h. jede Anweisung wird mindestens einmal durchlaufen. Hauptproblem des Testens: Kombinatorische Explosion der Testfälle c LETTMANN 2003/04 Modellierung Verifikation V-51 c LETTMANN 2003/04 Modellierung Verifikation V-52