Dr. Wolfram Amme, Verifikation imperativer Programme, Informatik II, FSU Jena, SS 2002 1 Verifikation von imperativen Programmen.

Slides:



Advertisements
Ähnliche Präsentationen
Algorithmentheorie 08 – Dynamische Programmierung (1)
Advertisements

Eine dynamische Menge, die diese Operationen unterstützt,
Programmierung 1 - Repetitorium
6. Regelbasierte Systeme
Invariante und Algorithmenentwurf
Rekursion vs. Iteration
Frame-Logik Eine Einführung Andreas Glausch.
Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt.
Zusammenfassung der Vorwoche
Foliensatz von A. Weber zur Vorlesung Informatik I, Bonn, 2002/03
Kapitel 6. Suchverfahren
Ausdrücke bezeichnen Elemente eines Datentyps induktive Definition:
10. Grundlagen imperativer Programmiersprachen
Finale Semantik und beobachtbares Verhalten
Syntax, Semantik, Spezifikation - Grundlagen der Informatik R. Hartwig Kapitel 4 / 1 Termalgebren Definition "Freie Algebra" Die -Algebra A = [A, F ] heißt.
3. Berechenbarkeit Wann ist eine Funktion (über den natürlichen Zahlen) berechenbar? Intuitiv: Wenn es einen Algorithmus gibt, der sie berechnet! Was heißt,
Lösung 6.3 Denksportaufgabe
Terminierung und Deadlocks Enkhbat Daginaa Betreuerin Prof. Heike Wehrheim Totale Korrektheit.
Funktionalität Vorhandensein vor Funktionen mit festgelegten Eigenschaften. Diese Funktionen erfüllen die definierten Anforderungen. Richtigkeit - Liefern.
Übung 6.1Turing-Maschine 1.Machen Sie sich mit der Funktionsweise des Busy Beaver-Programms vertraut Vollziehen sie die 11 Schritte der ersten Turing-Tabelle.
1 Vorlesung Informatik 2 Algorithmen und Datenstrukturen (02 – Funktionenklassen) Prof. Dr. Th. Ottmann.
Vorlesung Informatik 2 Algorithmen und Datenstrukturen (02 – Funktionenklassen) Tobias Lauer.
Vorlesung Informatik 2 Algorithmen und Datenstrukturen (02 – Funktionenklassen) Prof. Dr. Th. Ottmann.
Informatik II, SS 2008 Algorithmen und Datenstrukturen Vorlesung 4 Prof. Dr. Thomas Ottmann Algorithmen & Datenstrukturen, Institut für Informatik Fakultät.
Informatik II, SS 2008 Algorithmen und Datenstrukturen Vorlesung 2 Prof. Dr. Thomas Ottmann Algorithmen & Datenstrukturen, Institut für Informatik Fakultät.
Vorlesung Informatik 3 Einführung in die Theoretische Informatik (17 –Turingmaschinen) Prof. Dr. Th. Ottmann.
Kapitel 5 Stetigkeit.
Eduard Sauerbrei Formale Techniken Eduard Sauerbrei
Universität Dortmund, Lehrstuhl Informatik 1 EINI II Einführung in die Informatik für Naturwissenschaftler und Ingenieure.
Imperative Programmierung
Gleichungskalkül und Induktion
Boolesche Ausdrücke Ist der Rückgabewert eines Ausdrucks vom Typ boolean, so wird dieser als Boolescher Ausdruck bezeichnet (nach dem Mathematiker George.
DVG Ablaufsteuerung
DVG Methoden 1 Methoden. 2 int dezi = Integer.parseInt(args[0]); boolean vz = (dezi>=0); dezi = Math.abs(dezi); String Bin = ""; do { } while.
LS 2 / Informatik Datenstrukturen, Algorithmen und Programmierung 2 (DAP2)
Einführung in die Programmierung Datensammlung
Informatik 1 Übung 2.
Effiziente Algorithmen
Debugging in Lua Universität zu Köln Re-usable Content in 3D und Simulationssystemen Prof. Dr. Manfred Thaller Referent: Artur Wilke.
BIT – Schaßan – WS 02/03 Basisinformationstechnologie HK-Medien Teil 1, 11.Sitzung WS 02/03.
Effiziente Algorithmen
Quantum Computing Hartmut Klauck Universität Frankfurt WS 05/
Information und Kommunikation Hartmut Klauck Universität Frankfurt SS
Beweissysteme Hartmut Klauck Universität Frankfurt WS 06/
Beweissysteme Hartmut Klauck Universität Frankfurt WS 06/
Information und Kommunikation Hartmut Klauck Universität Frankfurt SS
Beweissysteme Hartmut Klauck Universität Frankfurt WS 06/
Einführung in die Programmierung
Einführung in die Programmierung Wintersemester 2013/14 Prof. Dr. Günter Rudolph Lehrstuhl für Algorithm Engineering Fakultät für Informatik TU Dortmund.
Wiederholte Programmausführung
Institut für Wirtschaftsinformatik – Software Engineering, JKU Linz 1 Algorithmen und Datenstrukturen SS 2005 Mag.Th. Hilpold u. Dr. A.Stritzinger Institut.
2.4 Rekursion Klassifikation und Beispiele
Black Box Algorithmen Hartmut Klauck Universität Frankfurt SS
Algorithmen und Datenstrukturen Übungsmodul 8
Automaten, formale Sprachen und Berechenbarkeit II SoSe 2004 Prof. W. Brauer Teil 1: Wiederholung (Vor allem Folien von Priv.-Doz. Dr. Kindler vom WS 2001/02.
Agenda für heute, 20. April, 2006 Wiederholte ProgrammausführungWiederholte Programmausführung Algorithmische Grundlagen Bedingungen zum Abbruch von Programmschleifen.
Agenda für heute, 7. April, 2005 Bedingte ProgrammausführungBedingte Programmausführung Algorithmische Grundlagen Vergleichsoperatoren, Wahrheitswerte.
PHP: Operatoren und Kontrollstrukturen
1 Albert-Ludwigs-Universität Freiburg Rechnernetze und Telematik Prof. Dr. Christian Schindelhauer Informatik III Christian Schindelhauer Wintersemester.
Korrektheit von Programmen – Testen
Grundlagen01Logik 02Mengen 03Relationen Arithmetik04Die natürlichen Zahlen 05Erweiterungen der Zahlenmenge Elementare Geometrie06Ebene Geometrie 07Trigonometrie.
Korrektheit von Programmen – Testen
Wann ist eine Funktion (über den natürlichen Zahlen) berechenbar?
 Sortigkeit oder Arität
Funktionen, Felder und Parameter- übergabe. Funktionsaufruf mit Feld als Parameter: Parameter = Name des Feldes.
Dr. Wolfram Amme, Semantik funktionaler Programme, Informatik II, FSU Jena, SS Semantik funktionaler Programme.
Dr. Wolfram Amme, Grundsätze der Logikprogrammierung, Informatik II, FSU Jena, SS Grundsätze der Logikprogrammierung.
1 Grundsätze objektorientierter Programmierung. Dr. Wolfram Amme, Grundsätze objektorientierter Programmierung, Informatik II, FSU Jena, SS Objektorientierte.
Dr. Wolfram Amme, Automatische Speicherverwaltung, Informatik II, FSU Jena, SS Automatische Speicherverwaltung.
Dr. Wolfram Amme, Funktionale Programmierung, Informatik II, FSU Jena, SS Funktionale Programmierung.
 Präsentation transkript:

Dr. Wolfram Amme, Verifikation imperativer Programme, Informatik II, FSU Jena, SS Verifikation von imperativen Programmen

Dr. Wolfram Amme, Verifikation imperativer Programme, Informatik II, FSU Jena, SS Korrektheit von Programmen Ein Programm heißt korrekt, wenn es genau die Semantik (Wirkung) hat, wie sie durch die Spezifikation gegeben ist wesentliches Ziel jeder Programmentwicklung ist die Sicherstellung der Korrektheit des erstellten Programms 70% vom gesamten Aufwand der Softwareproduktion entfallen auf die Fehlerbehebung und Weiterentwicklung alter Programme erst nach Auslieferung an den Kunden stellen sich 3% aller Programmzeilen als fehlerhaft heraus Fehler die noch während der Entwicklung entdeckt werden, verursachen nur 5% der Kosten, wie Fehler die während des praktischen Einsatzes gefunden werden Verwenden von Entwicklungsmethoden mit denen aus der Spezifikation zielorientiert korrekte Programme entwickelt werden können, senkt den Wartungsaufwand erheblich

Dr. Wolfram Amme, Verifikation imperativer Programme, Informatik II, FSU Jena, SS Verifizieren versus Testen von Programmen Techniken zur Überprüfung der semantischen Übereinstimmung von Spezifikation und Programm Testen wird für einige gut ausgewählte Testdaten ausgeführt Testvorgang kann meist nicht über alle Kombinationen der Eingabewerte durchgeführt werden über die Korrektheit nicht getesteter Eingabewerte kann nur spekuliert werden Verifikation ist eine exakte formale Methode zur Korrektheitsprüfung Konsistenz zwischen Spezifikation und Programm wird für alle Eingabedaten bewiesen Fehlerfreiheit eines Programms kann mit wesentlich höherer Sicherheit garantiert werden Verifikation liefert jedoch auch keine hundertprozentige Gewissheit über die Fehlerfreiheit eines Programms

Dr. Wolfram Amme, Verifikation imperativer Programme, Informatik II, FSU Jena, SS Für und wider: Programmverifikation Verifikation liefert Gewissheit über die Korrektheit sämtlicher Eingabedaten kann mit der Programmentwicklung durchgeführt werden und unterstützt deshalb die zielorientierte Programmentwicklung reduziert die Kosten für Fehlersuche und Wartung erheblich dokumentiert das Programm ist intellektuell anspruchsvoll Verifikation, aber verursacht wesentlich mehr Zeitaufwand ist nicht vollautomatisch durchführbar ist bei fertigen Programmen im nach herein wesentlich schwieriger durchführbar ist intellektuell anspruchsvoll

Dr. Wolfram Amme, Verifikation imperativer Programme, Informatik II, FSU Jena, SS Spezifikation von Unterprogrammen Spezifikationen werden zur Semantikbeschreibung von Prozedur/Funktionsaufrufen benutzt Spezifikationen sollen beschreiben/vorschreiben was eine Prozedur/Funktion zu leisten hat, aber nicht wie die Leistung erbracht werden soll Ein-/Ausgabespezifikation welche Zusicherung können an das Ausgabeverhalten (dem Resultat) einer Prozedur/Funktion f gemacht werden welche Anforderungen werden an die Parameterwerte einer Prozedur/Funktion f gemacht Spezifikationssprachen: natürlichsprachliche Formulierungen pseudoalgorithmische Sprachen mathematische Aussagen- und Prädikatenlogik

Dr. Wolfram Amme, Verifikation imperativer Programme, Informatik II, FSU Jena, SS Grobschema einer Spezifikation (** Name und Kurzbeschreibung von f(p 1,..., p k ) * Anforderungsteil: * - Anforderung an die p i * - Anforderung an den Datenteil des Moduls * Zusicherungsteil: * - Zusicherung an das Ergebnis result * - Zusicherungen an geworfene Ausnahmen * - Zusicherungen an den Datenteil des Moduls * - Zusicherungen an veränderte Referenzparameter * Weitere Kommentare **) PROCEDURE f(p 1 :T 1,..., p k :T k ):T

Dr. Wolfram Amme, Verifikation imperativer Programme, Informatik II, FSU Jena, SS Vereinbarungen zur Anfertigung von Spezifikationen Anforderungen und Zusicherungen, die sich aus den Typen der Signatur ergeben, werden nicht wiederholt von einer Funktion benutzte globale Variablen werden als Eingabeparameter aufgeführt werden globale Variablen zur Ausgabe genutzt, müssen sie als Ausgabeparameter genannt werden Referenzparameter sollten zusätzlich als Eingabe oder Eingabe/Ausgabeparameter angegeben werden eine Spezifikation kann Kurzkommentare, wie Sinn und Zweck der Funktion, Autorangabe, Datum, relevante Literaturstellen, Programmiermethoden, etc. enthalten

Dr. Wolfram Amme, Verifikation imperativer Programme, Informatik II, FSU Jena, SS Beispiel einer Spezifikation power:  x N -> Z, (a,b) -> a b (** * Exponentialfunktion power * Anforderungen: * a: Basis, -- * b: Exponent, b >= 0 * Zusicherungen: * resultat = a^b * Achtung: kein besonderer Test auf Ergebnisüberlauf **) PROCEDURE power (a : INTEGER, b : INTEGER) : INTEGER

Dr. Wolfram Amme, Verifikation imperativer Programme, Informatik II, FSU Jena, SS Terminologie und Problemstellung Ein Aufruf f(a 1,...,a n ) heißt zulässig, falls die Werte a 1,...,a n nach entsprechender Substitution die Parameteranforderungen erfüllen. Die Implementierung einer Funktion ist partiell korrekt, falls jedes Resultat resultat eines zulässigen Aufrufs die Zusicherung erfüllt. Eine Implementierung terminiert,wenn jeder zulässige Aufruf in endlicher Zeit ein Resultat berechnet. Eine Implementierung ist total korrekt, wenn sie partiell korrekt ist und terminiert.

Dr. Wolfram Amme, Verifikation imperativer Programme, Informatik II, FSU Jena, SS Mit der Methode der Zusicherung (Hoare, 1969) kann die partielle Korrektheit einer Anweisungssequenz S formal gezeigt werden. Zusicherungen beschreiben Eigenschaften oder Zustände die an bestimmten Programmstellen gelten Zusicherungen werden eingesetzt zur Dokumentation, Spezifikation und Verifikation von Programmen. Methode der Zusicherung

Dr. Wolfram Amme, Verifikation imperativer Programme, Informatik II, FSU Jena, SS Zusicherung zur Dokumentation von Programmen x := y 2 x ist nicht negativ x := y 2 x  0 x := y 2 x > y > 1 y >1

Dr. Wolfram Amme, Verifikation imperativer Programme, Informatik II, FSU Jena, SS Sprache der Zusicherungen Zusicherungen sind logische Aussagen über die Werte der Programmvariablen Zusicherungen können umgangssprachlich oder x ist nicht negativ x hat den Wert y 2 alle Elemente des Feldes a sind nicht negativ alle Elemente des Feldes a sind aufsteigend sortiert formal in der Sprache der Prädikatenlogik formuliert werden x  0 x = y 2  i : 0  i < N : a i  0  i : 0  i < N : a i-1  a i

Dr. Wolfram Amme, Verifikation imperativer Programme, Informatik II, FSU Jena, SS Boolesche Ausdrücke bilden die Grundlage für die Sprache der Zusicherungen Konstante, Programmvariable Relationsoperatoren:, , =,  Logische Operatoren: and, or, not, ,  sollen zwei Zusicherungen gleichzeitig gelten, werden sie mit dem logischen Operator and verknüpft x  a and x  b oder x  a, x  b soll mindestens eine von zwei Zusicherungen gelten, so werden sie mit dem logischen Operator or verknüpft x  a or x  b Zusicherungen als Boolesche Ausdrücke

Dr. Wolfram Amme, Verifikation imperativer Programme, Informatik II, FSU Jena, SS die Zusicherungen true und false sind die beiden extremsten Zusicherungsformen Die Zusicherung true ist stets erfüllt gilt an beliebigen Stellen des Programms und schränkt den Wertebereich des Variablen in keiner Form ein wird verwendet um anzudeuten, das keine Anforderungen an die Eingabeparameter gelten Die Zusicherung false ist nie erfüllt: kann an keiner Stelle gelten, die das Programm bei seinem Ablauf erreichen kann false schränkt den Wertebereich der Variablen dermaßen ein, dass es keine gültigen Variablenwerte mehr gibt Die Zusicherungen true und false

Dr. Wolfram Amme, Verifikation imperativer Programme, Informatik II, FSU Jena, SS ein Programm verwendet eine endliche Anzahl an Variablen v 1,...,v n die stets Werte entsprechenden Wertbereich haben ein Programmzustand ist eine bestimmte Belegung der Variablen mit Werten (v 1,..., v n ) = (w 1,..., w n ) Zusicherungen beschreiben den Zustandsraum eines Programms zu einer bestimmten Ausführungszeit Programmzustand und Zusicherungen x := y + 2 x = 3 and y = 5 x = 7 and y = 5

Dr. Wolfram Amme, Verifikation imperativer Programme, Informatik II, FSU Jena, SS in linearen Programmtext werden Zusicherungen zur Zustandsraumbeschreibung in Kommentarform angegeben die Zusicherungen die den Zustandsraum vor bzw. nach Ausführung einer Anweisung S beschreiben nennen wir die Vor- bzw. Nachbedingung einer Anweisung (*V*) S (*N*) Für jeden (Eingangs-) Zustand, für den vor Ausführung der Anweisung S die Vorbedingung V gilt, gilt nach Ausführung von S der (Nachfolge-)Zustand die Nachbedingung Vor- und Nachbedingung einer Anweisung

Dr. Wolfram Amme, Verifikation imperativer Programme, Informatik II, FSU Jena, SS V beschreibt die Zustand vor der Programmausführung und N den Zustand nach Ausführung von P Zusicherungen als Form der Spezifikation P V N Anfangsbedingung spezifiziertes Programm Beschreibung der Endbedingung

Dr. Wolfram Amme, Verifikation imperativer Programme, Informatik II, FSU Jena, SS Beispiel : Maximum Maximum zweier Zahlen: Die Variable m soll den größeren Wert der Variablen x und y erhalten Maximum V: x = X, y = Y N: (m=X) or (m=Y), m  X, m  Y Maximum V: x = X, y = Y N: m = X max Y

Dr. Wolfram Amme, Verifikation imperativer Programme, Informatik II, FSU Jena, SS Beispiel : Fakultät Bestimmung der Fakultät: Die Variable y soll unter Verwendung der Programmvariablen x für beliebige natürliche Zahlen A den Wert A! zugewiesen bekommen Fakultät V: A  0 and x = A N: y = A!

Dr. Wolfram Amme, Verifikation imperativer Programme, Informatik II, FSU Jena, SS Programmverifikation mit dem Hoare-Kalkül Hoare-Kalkül besteht aus Axiomen und Regeln, die zur formalen Beweisführung verwendet werden können Korrektheit eines Programms wird aufgrund der Korrektheit der beinhalteten Teilstrukturen bewiesen Beweis der partiellen Korrektheit eines Unterprogramms Zur Verifikation eines Unterprogramms U, sehen wir die Anforderungen an die Parameterwerte als Vorbedingung und die Zusicherung an das Resultat als Nachbedingung an und zeigen Unterprogramm V: Anforderungen N: Zusicherung

Dr. Wolfram Amme, Verifikation imperativer Programme, Informatik II, FSU Jena, SS Anwendung der Zusicherungsmethode Zusicherungsmethode leitet für eine Nachbedingung des Programms die schwächste Vorbedingung ab Zusicherung A heißt schwächer als Zusicherung B falls A den Zustandsraum weniger einschränkt als B Programm Schwächste Vorbedingung Nachbedingung

Dr. Wolfram Amme, Verifikation imperativer Programme, Informatik II, FSU Jena, SS Konsequenzregel Stärkere Anforderung: P  Q, (* Q *) S (* R *) (* P *) S (* R *) Verstärken der Vorbedingung oder Hinzufügen wahrer Bedingungen zur Vorbedingung Konsequenzregel: Stärkere Anforderung S Q R P  S P R

Dr. Wolfram Amme, Verifikation imperativer Programme, Informatik II, FSU Jena, SS Konsequenzregel: Schwächere Zusicherung (* Q *) S (* R *), R  P (* Q *) S (* P *) Abschwächen der Nachbedingung oder Vergessen von Nachbedingungen Konsequenzregel: Schwächere Zusicherung S Q R P  S Q P

Dr. Wolfram Amme, Verifikation imperativer Programme, Informatik II, FSU Jena, SS Seien x eine beliebige Variable und t ein beliebiger Ausdruck, dessen Berechnung frei von Seiteneffekten ist Sei P[x  t] die Formel, die aus P hervorgeht, indem alle Vorkommnisse von x durch t ersetzt werden, dann gilt immer (* P[x  t] *) x := t; (* P *) x darf auch in t enthalten sein (z.B. x := x + 1) Art des verwendeten Zuweisungsaxioms schränkt die Programmverifikation auf Rückwärtsschreiten ein Zuweisungsaxiom

Dr. Wolfram Amme, Verifikation imperativer Programme, Informatik II, FSU Jena, SS Sequenzregel: (* P *) S 1 (* Q *), (* Q *) S 2 (* R *) (* P *) S 1 ; S 2 (* R *) Mit der Sequenzregel kann man Teilbeweise für einzelne Programmschritte zu einem Gesamtbeweis zusammensetzen Sequenzregel S1S1 Q P S2S2 R Q S1S1 S2S2 P R

Dr. Wolfram Amme, Verifikation imperativer Programme, Informatik II, FSU Jena, SS (*** * Anforderung: -- * Zusicherung: res = 31 ***) PROCEDURE f() : INTEGER = BEGIN x, res : INTEGER, x := 5; res := x * x + 6; RETURN res; END; Beispiel: Sequenzregel

Dr. Wolfram Amme, Verifikation imperativer Programme, Informatik II, FSU Jena, SS Verallgemeinerte Sequenzregel: P  P 1, (* P 1 *) S 1 (* R 1 *), R 1  P 2, (* P 2 *) S 2 (* R 2 *), R 2  R (* P *) S 1 ; S 2 (* R *) Verallgemeinerung der Sequenzregel S1S1 R1R1 P1P1 S2S2 R2R2 P2P2 S1S1 S2S2 P R  P R  

Dr. Wolfram Amme, Verifikation imperativer Programme, Informatik II, FSU Jena, SS Alternativregel: (* P and B *) S 1 (* R *), (* P and not B *) S 2 (* R *) (* P *) IF B THEN S 1 ELSE S 2 END (* R *) Alternativregel P S1S1 P and BP and not B R B janein R R S2S2

Dr. Wolfram Amme, Verifikation imperativer Programme, Informatik II, FSU Jena, SS (*** * Anforderung: true * Zusicherung: res = | a |Absolutbetrag von a ***) PROCEDURE f(a : INTEGER) : INTEGER = BEGIN res : INTEGER; IF a  0 THEN res := -a ELSE res := a END; RETURN res; END; Beispiel: Alternativregel

Dr. Wolfram Amme, Verifikation imperativer Programme, Informatik II, FSU Jena, SS Die while-Schleife WHILE B DO S END;  für die Verifikation einer Schleife verwendet man eine invariante Zusicherung, die sogenannte Schleifeninvariante (INV) INV gilt nach jedem Durchlauf der Schleife und beschreibt im dynamischen Ablauf der Schleife das Gleichbleibende eine spezielle Behandlung anderer Schleifenformen ist unnötig, da diese in eine while-Schleife transformiert werden können S not B

Dr. Wolfram Amme, Verifikation imperativer Programme, Informatik II, FSU Jena, SS Iterationsregel: (* INV and B *) S (* INV *) (* INV *) WHILE B DO S END (* INV and not B *) Iterationsregel not B INV INV and not B INV and B INV S

Dr. Wolfram Amme, Verifikation imperativer Programme, Informatik II, FSU Jena, SS (*** * Anforderung: -- * Zusicherung: res = n! Fakultätsfunktion ***) PROCEDURE fac(n : INTEGER) : INTEGER = BEGIN i, res : INTEGER; i := n; res := 1; WHILE i > 1 DO (* INV: i! * res = n! *) res := res * i; i := i – 1; END; RETURN res; END; Beispiel: Iterationsregel

Dr. Wolfram Amme, Verifikation imperativer Programme, Informatik II, FSU Jena, SS (* V: true *) i := n; res := 1; (* INV *) WHILE i > 1 DO (* INV: i! * res = n! *) (* INV and i > 1 *) res := res * i; i := i – 1, (* INV *) END; (* INV and not (i > 1) *)  (* N: res = n!*) Beispiel Iterationsregel: Beweisführung 1 2 3

Dr. Wolfram Amme, Verifikation imperativer Programme, Informatik II, FSU Jena, SS eine Schleifeninvariante garantiert im allgemeinen nur die partielle Korrektheit der Schleife damit eine Schleife terminiert, muss die Schleifenbedingung B nach endlichen Schleifendurchläufen nicht mehr erfüllt sein Berechnung des ganzzahligen Quotienten q = (X div Y) und des Restes r = (X mod Y) zweier ganzer Zahlen X und Y Terminierung von Schleifen Ganzzahlige Division R: X = q * Y + r, 0  r  Y P: X  0,Y > 0

Dr. Wolfram Amme, Verifikation imperativer Programme, Informatik II, FSU Jena, SS INV and r  Y Ganzzahlige Division (total korrekt) r := r – Y; q := q + 1; INV: X = q * Y + r, 0  r INV r < Y R: X = q * Y + r, 0  r < Y q := 0; r := X; Q: X  0, Y > 0

Dr. Wolfram Amme, Verifikation imperativer Programme, Informatik II, FSU Jena, SS Ganzzahlige Division (nur partiell korrekt) INV and r  Y r := r + Y; q := q - 1; INV r < Y INV and r  Y r := r + Y +Y; q := q - 2; INV r < Y INV and r  Y skip INV r < Y

Dr. Wolfram Amme, Verifikation imperativer Programme, Informatik II, FSU Jena, SS Kriterien für die Terminierung von Schleifen vorm Schleifenrumpf gilt r  Y, damit die Schleife terminiert muss der Wert von r im Schleifenrumpf kleiner werden Aufgabe des Schleifenrumpfes ist die Verkleinerung von r unter der Beibehaltung der Invarianz von INV Wird r um Y verkleinert muß q um 1 erhöht damit INV: X = q * Y + r and 0  r invariant bleibt INV and r  Y r := r - Y; q := q + 1; INV r < Y

Dr. Wolfram Amme, Verifikation imperativer Programme, Informatik II, FSU Jena, SS Einführung einer Terminierungsfunktion t, die die Programmzustände auf ganze Zahlen abbildet Der ganzzahlige Wert der Terminierungsfunktion muss mit jedem Schleifendurchlauf um mindestens 1 kleiner werden und stets positiv sein formal muss für die Terminierungsfunktion gelten für jede Ausführung des Schleifenrumpfes (* INV and B and t = T *) S (* t < T *) vor Ausführung des Schleifenrumpfes INV and B  t  0 für die ganzzahlige Division ist die Terminierungsfunktion durch t:r gegeben Einführung einer Terminierungsfunktion

Dr. Wolfram Amme, Verifikation imperativer Programme, Informatik II, FSU Jena, SS Beispiel: Terminierung (*** * Anforderung: a > 0, b > 0 * Zusicherung: res = a % b Modulofunktion ***) PROCEDURE mod(a : INTEGER, b : INTEGER):INTEGER = BEGIN x, y : INTEGER; x := a; y := b; WHILE x >= y DO x := x - y; END; res := x; RETURN res; END;