Kapitel 4: Formale Verifikation

Transkript

1 Kapitel 4: Formale Verifikation Inhalt 4.1 Grundlagen 4.2 Verifikation auf axiomatischer Basis 4.3 Verifikation einzelner Eigenschaften 4.4 Stärken und Schwächen formaler Verifikation Schlüsselbegriffe Korrektheitsbeweis, Semantik, (formale) Verifikation Software-Qualitätsmanagement Kapitel 4: Formale Verifikation Seite 4-1

2 4.1 Grundlagen Begriffe Verifikation ist (1) der Prozess der Beurteilung eines Systems oder einer Komponente mit dem Ziel, festzustellen, ob die Resultate einer gegebenen Entwicklungsphase den Vorgaben für diese Phase entsprechen, (2) der formale Beweis der Korrektheit eines Programms. (IEEE ) Siehe dazu auch Bild 1.2. Mit formaler Verifikation ist die Bedeutung (2) gemeint Formale Verifikation ist der Beweis, dass ein Programm P alle in einem Vorgabedokument S geforderten Eigenschaften aufweist S ist die Spezifikation die Verifikation erfolgt mit den Mitteln der mathematischen Logik formale Verifikation erfordert eine formale Definition von Syntax und Semantik der für P und S verwendeten Sprachen. Software-Qualitätsmanagement Kapitel 4: Formale Verifikation Seite 4-2

3 4.1.2 Syntax und Semantik von Sprachen Syntax Regelwerk für die Konstruktion orthographisch und grammatisch korrekter Sätze einer Sprache Syntaxdefinition formaler Sprachen konstruktiv durch Übersetzer und gleichzeitig informal mit Text für Benutzer durch formale Definition einer Grammatik (zum Beispiel Backus-Naur-Form (BNF)) für Übersetzer und Benutzer Semantik Festlegung der Bedeutungen der syntaktisch korrekten Sätze einer Sprache Semantikdefinition formaler Sprachen Übersetzersemantik: Bedeutungen durch Übersetzer (Compiler) bestimmt Operationale Semantik: Bedeutungen durch Abläufe in einer abstrakten Maschine (einem Automaten) bestimmt Denotationelle Semantik: Bedeutungen durch Funktion f: E A, definiert, welche den Eingangszustand E auf den Ausgangszustand A abbildet. Axiomatische Semantik: Bedeutungen durch Axiome in Form von Voraussetzungen und Ergebniszusicherungen bestimmt Software-Qualitätsmanagement Kapitel 4: Formale Verifikation Seite 4-3

4 4.2 Verifikation auf axiomatischer Basis Ansatz Beweise (i) Wenn P terminiert, so transformiert P jeden Zustand, in dem V gilt, in einen Zustand, in dem N gilt Schreibweise: {V} P {N} (ii) P terminiert (Hoare, 1969) P zu verifizierendes Programm {V} Menge der Voraussetzungen (Vorbedingungen, Preconditions), deren Erfüllung vor Ausführung von P garantiert, dass die Ergebniszusicherungen gelten {N} Menge der Ergebniszusicherungen (Nachbedingungen, Postconditions), die nach Ausführung von P gelten N und V sind Ausdrücke der Prädikatenlogik {V} und {N} bilden zusammen die Spezifikation von P Beispiel 4.1 Gegeben sei die Spezifikation V x, y INTEGER x = X, y = Y N x = max (0, Y) Beweise: das Programm P x := y; if x < 0 then x := 0 erfüllt die Spezifikation, d.h. {V} P {N} Hinweis: x = X bedeutet, dass die Variable x den Wert X hat Software-Qualitätsmanagement Kapitel 4: Formale Verifikation Seite 4-4

5 Beweisidee: Das zu verifizierende Programm wird in Schritte gegliedert und Schritt für Schritt verifiziert: Zu beweisen sei {V} P {N} P bestehe aus einer Folge s 1, s 2,..., s n von Anweisungen. Dann werden Bedingungen Q i bestimmt mit V = Q 0, N = Q n und {Q 0 } s 1 {Q 1 } s 2 {Q 2 } s 3... {Q n-1 } s n {Q n } Nun gilt: Aus {Q i-1 } s i {Q i } für alle 1 i n folgt {V} P {N} Jeder Einzelschritt wird bewiesen, indem man ihn aus der Semantikdefinition der verwendeten Programmiersprache herleitet. Beweise dieser Art setzen eine axiomatische Semantik für die verwendete Programmiersprache voraus. Software-Qualitätsmanagement Kapitel 4: Formale Verifikation Seite 4-5

6 4.2.2 Axiomatische Semantik von Programmiersprachen Die Semantik wird durch ein Axiom {V} s {N} für jede ausführbare Anweisung s der verwendeten Programmiersprache definiert. (Hoare, 1969) In den Axiomen sollen die Ergebniszusicherungen unter möglichst schwachen Voraussetzungen gelten: Gesucht ist die schwächste Voraussetzung (weakest precondition) V, für die {V} s {N} bewiesen werden kann. Schreibweise: V wp (s, N) Definiere wp(s, N) für jede ausführbare Anweisung der verwendeten Programmiersprache (Dijkstra, 1976; Gries, 1981) Die Semantik ist nur für syntaktisch korrekte Konstrukte definiert. Es wird daher im Folgenden immer vorausgesetzt, dass die zu verifizierenden Programme oder Programmteile syntaktisch korrekt sind. Bei Sprachen mit Typen, z.b. PASCAL oder Java, gehört die Typverträglichkeit aller Ausdrücke und Zuweisungen ebenfalls zur Syntax. Software-Qualitätsmanagement Kapitel 4: Formale Verifikation Seite 4-6

7 Ausgewählte Axiome für die Sprache PASCAL Wertzuweisung x := E Sei x eine Variable, E ein Ausdruck vom gleichen Typ wie x und Q(x) die Ergebniszusicherung von x := E Dann ist die Semantik von x := E definiert durch wp(x:=e, Q(x)) E ist berechenbar Q(E) In Worten: Wenn E berechnet werden kann, so ergibt sich die schwächste Voraussetzung, indem alle Vorkommen von x in der Ergebniszusicherung durch E ersetzt werden. Hinweis: Situationen, in denen E nicht berechnet werden kann, ergeben sich beispielsweise, wenn E eine Division durch Null enthält. Beispiel 4.2 Seien a, b Zahlen gleichen Typs und seien gegeben Wertzuweisung b := a+1 Ergebniszusicherung b > a wp (b := a+1; b > a) = (a+1 > a) = TRUE Software-Qualitätsmanagement Kapitel 4: Formale Verifikation Seite 4-7

8 Leere Anweisung ε wp (ε, Q) Q Die leere Anweisung wird u.a. benötigt, um IF-Anweisungen ohne ELSE-Zweig zu verifizieren. Sequenz s1 ; s2 wp (s1;s2, Q) wp (s1, wp (s2, Q)) In Worten: Die schwächste Voraussetzung der zweiten Anweisung ist gleich der Ergebniszusicherung Ns1 der ersten Anweisung. Die schwächste Voraussetzung der Sequenz ist damit die schwächste Bedingung, die bei Ausführung von s1 die Bedingung Ns1 liefert. Beispiel 4.3 Seien x,y Zahlen gleichen Typs und seinen gegeben Anweisungssequenz y := x; x := 0 Ergebniszusicherung y = X x 0 wp (y := x; x := 0, (y = X x 0) ) = wp (y := x, wp (x := 0, (y = X x 0)) ) = wp (y := x, (y = X 0 0) ) = (x = X) Software-Qualitätsmanagement Kapitel 4: Formale Verifikation Seite 4-8

9 Alternative if b then s1 else s2 wp (if b then s1 else s2, Q) b wp (s1, Q) b wp (s2, Q) In Worten: ist b wahr, so hat die Alternative die Semantik der Anweisung s1, andernfalls diejenige der Anweisung s2. Beispiel 4.4 Seien x,y,z vergleichbare Objekte gleichen Typs und seien gegeben Alternative if x < y then z := y else z := x Ergebniszusicherung z = max (X, Y) wp (if x < y then z := y else z := x, z = max (X, Y) ) = (x < y) wp (z := y, z = max (X,Y)) (x < y) wp (z := x, z = max (X,Y)) = (x < y) (y = max (X, Y)) (x y) (x = max (X, Y)) = (y = Y) (x = X) Software-Qualitätsmanagement Kapitel 4: Formale Verifikation Seite 4-9

10 Iteration while b do s durch rekursive Definition zurückführbar auf Semantik einer Folge von Anweisungen : while b do s if b then begin s ; while b do s end führt zu Rekursion in der Definition von wp schwierig Besser: Verifikation über eine Schleifeninvariante Eine Schleifeninvariante Inv ist ein logischer Ausdruck, der bei jeder Prüfung der Fortsetzungsbedingung b wahr ist Da Inv bei jeder Prüfung der Fortsetzungsbedingung wahr ist, muss Inv auch nach jedem Schleifendurchlauf, d.h. nach jeder Ausführung von s wahr sein. Folglich gilt: {Inv b} s {Inv} Für den letzten Schleifendurchlauf gilt {Inv b} s {Inv b} Durch geeignete Wahl von Voraussetzungen V und einer Invarianten Inv ist zu beweisen: V Inv sowie (Inv b) N Nach den Regeln für die Zusammensetzung von Bedingungen für eine Folge von Anweisungen (vgl. p. 4-5) ist damit {V} while b do s {N} bewiesen. Software-Qualitätsmanagement Kapitel 4: Formale Verifikation Seite 4-10

11 Beispiel 4.5 Gegeben sei die Iteration mit der Ergebniszusicherung while i n do begin p := p * s; i := i + 1 end {p = S**N} Die Bedingung p = S**i-1 ist Schleifeninvariante, sofern bei Eintritt in die Schleife die Voraussetzung (p = S) (i = 2) (n > 0) erfüllt ist V Inv ist trivial, weil die Voraussetzung gerade so bestimmt wurde Leite aus der Invariante die Ergebniszusicherung ab (beweise Inv b N): Nach dem letztem Schleifendurchlauf gilt i = n+1: (p = S**i-1 für alle i n+1) i = n+1 (p = S**n) (mit der trivialen Voraussetzung n = N) (p = S**N) Damit ist bewiesen: {(p = S) (i = 2) (n > 0)} while i n do begin p := p * s; i := i + 1 end {p = S**N} Hinweis: Würde man als Schleifeninitialisierung wie üblich i := 1 wählen, wäre die Voraussetzung der Schleife verletzt und damit das Ergebnis nicht mehr garantiert (nicht notwendig falsch, da die Voraussetzung nicht sicher die schwächste ist). Im konkreten Fall wäre das Ergebnis für n= 1 falsch, weil p den Initialwert S hat. Software-Qualitätsmanagement Kapitel 4: Formale Verifikation Seite 4-11

12 4.2.3 Verifikation des Programms aus Beispiel 4.1 Seien x,y vom Typ INTEGER Beweise: {x = X, y = Y} x := y; if x < 0 then x := 0 {x = max (0, Y)} 1. Bestimme Q 3 = wp (x := 0, (x = max (0, Y)) = (0 = max (0, Y) ) = (Y 0) 2. Bestimme Q 2 = wp (ε, (x = max (0, Y)) = (x = max (0, Y)) 3. Bestimme Q 1 = wp (if x < 0 then x := 0, (x = max (0, Y)) = ( (x < 0) (Y 0) (x 0) (x = max (0, Y)) 4. Bestimme Q 0 = wp (x := y, Q 1 ) = ( (y < 0) (Y 0) (y 0) (y = max (0, Y)) 5. Zeige: (x = X, y = Y) Q 0 y = Y (y < 0) (y = Y) (y 0) (y = Y) (y < 0) (Y 0) (y 0) (y = max (0, Y)) 6. Zeige, dass das Programm terminiert Das Programm enthält weder Schleifen noch Rekursion das Programm terminiert Software-Qualitätsmanagement Kapitel 4: Formale Verifikation Seite 4-12

13 4.3 Verifikation einzelner Eigenschaften Häufig interessiert man sich nicht nur für den Nachweis einer korrekten Implementierung, sondern für den Beweis anderer wichtiger Eigenschaften, z.b. der Nachweis für eine Spezifikation, dass gefährliche (und daher verbotene) Systemzustände nachweislich nicht erreichbar sind der Nachweis, dass ein Modell verklemmungsfrei ist Solche Nachweise sind möglich, wenn der Untersuchungsgegenstand in einer Sprache vorliegt, die entweder eine vollständig formale Semantik hat oder für welche mindestens die für den Nachweis benötigten Elemente formal definiert sind. Beispiel 4.6: In nachstehendem Petrinetz einer (stark vereinfachten) Liftsteuerung kann die Eigenschaft, dass der Lift niemals bei offener Tür fahren kann, formal bewiesen werden. Lift steht auf Etage Tür zu Tür offen fahrbereit Lift fährt Zielknopf Stockwerksensor Software-Qualitätsmanagement Kapitel 4: Formale Verifikation Seite 4-13

14 4.4 Stärken und Schwächen formaler Verifikation Stärken: Ein formal verifiziertes Programm erfüllt nachweislich seine Spezifikation ein Test erübrigt sich das Programm liefert für alle Daten korrekte Ergebnisse Fehlfunktionen in nicht vorausgesehenen Fällen gibt es nicht Probleme: Viele Beweise ignorieren reale Randbedingungen: in Beispiel 4.2 wurde bewiesen {a, b sind Zahlen gleichen Typs} b := a+1 {b > a} Sind a und b vom Typ REAL und intern mit einer Mantisse von 24 Bit repräsentiert, so liefert dieses verifizierte Programm für alle a 2 24 das falsche Ergebnis b = a Die Verifikation ist aufwendig, insbesondere das Bestimmen von Schleifeninvarianten Es gibt keine Garantie gegen fehlerhafte Beweise. In der Literatur sind Beispiele fehlerhafter Programmbeweise dokumentiert (z.b. Gerhart und Yelowitz 1976) Der Test wird nicht überflüssig Verifikation hilft nicht gegen Spezifikationsfehler Software-Qualitätsmanagement Kapitel 4: Formale Verifikation Seite 4-14

15 Fazit Eine generelle formale Verifikation von Software ist mit den heutigen Mitteln weder machbar noch wirtschaftlich Nachträgliches Verifizieren mit seinem immensen Aufwand ist möglicherweise ein Irrweg Neue Ansätze versuchen Vorwärtsverifikation, d.h. korrektes, schrittweises Ableiten eines Programms aus seiner Spezifikation Die Erstellung und Prüfung einer vollständigen formalen Spezifikation bleibt bei großer Software ein ungelöstes Problem Formale Verifikation ist anzezeigt für eher kurze, aber sehr wichtige Algorithmen in Spezialfällen, z.b. für Kommunikationsprotokolle für sicherheitskritische Eigenschaften von Modellen Software-Qualitätsmanagement Kapitel 4: Formale Verifikation Seite 4-15

16 Aufgaben Aufgabe 4.1 Gegeben sei folgende Anforderung: Der abzugsfähige Betrag A ist der nachgewiesene Betrag B abzüglich des Selbstbehalts S, höchstens aber H. Alle Beträge sind nicht negative ganze Zahlen. a) Formen Sie diese Anforderungen in eine formale Ergebniszusicherung um. b) Ermitteln Sie die schwächste Voraussetzung, mit der folgende Anweisung in PASCAL die Ergebniszusicherung erfüllt: abzugsbetrag, nachgewbetrag, selbstbehalt, maxbetrag: INTEGER;... IF (nachgewbetrag - selbstbehalt) < maxbetrag THEN abzugsbetrag := nachgewbetrag - selbstbehalt ELSE abzugsbetrag := maxbetrag; c) Wie müsste das Programmfragment abgeändert werden, damit die Voraussetzung A S fallengelassen werden kann? Software-Qualitätsmanagement Kapitel 4: Formale Verifikation Seite 4-16

17 Zitierte Literatur Dijkstra, E.W. (1976). A Discipline of Programming. Englewood Cliffs: Prentice Hall. Gerhart, S.L., L. Yelowitz (1976). Observations on Fallibility in Applications of Modern Programming Methodologies. IEEE Transactions on Software Engineering, SE-2, 3 (Sept. 1976) Gries, D. (1981). The Science of Programming. Berlin, etc.: Springer. Hoare, C.A.R. (1969). An Axiomatic Basis for Computer Programming. Communications of the ACM 12, 10 (Oct. 1969) IEEE (1990). Standard Glossary of Software Engineering Terminology. IEEE Std IEEE Computer Society Press. Software-Qualitätsmanagement Kapitel 4: Formale Verifikation Seite 4-17