Eduard Sauerbrei eddie@uni-muenster.de Formale Techniken Eduard Sauerbrei eddie@uni-muenster.de.

Präsentation zum Thema: "Eduard Sauerbrei eddie@uni-muenster.de Formale Techniken Eduard Sauerbrei eddie@uni-muenster.de."—  Präsentation transkript:

1 Eduard Sauerbrei eddie@uni-muenster.de
Formale Techniken Eduard Sauerbrei

2 Agenda Motivation Verifikation Symbolischer Test Zusammenfassung
Hoare-Kalkül Model Checking Bounded Model Checking Symbolischer Test Zusammenfassung

3 Motivation Anteil der SW-Kosten höher als der HW-Kosten.
Längere Lebensdauer der Software (SW). SW-Kosten hoch in der Wartungsphase, insb. durch die Fehlerbehebung. Kosten im Falle von „SW-Versagen“ (HW-Verlust, Schadensersatzansprüche etc.). SW soll wenige Fehler beinhalten oder gar fehlerfrei sein  formale Techniken zum Beweis von Korrektheit der SW

4 Korrektheit der SW Partielle Korrektheit Totale Korrektheit
Programm liefert das richtige Ergebnis Annahme: Programm terminiert Totale Korrektheit Programm partiell korrekt Beweis: Programm terminiert (Terminationsbeweis)

5 Formale Techniken (Einordnung)

6 Formale Techniken (Eigenschaften)
Programmcode enthält alle wichtigen Informationen. Wirkungen von Programmen auf hohem Abstraktionsniveau mit mathematischen Mitteln ermittelt  keine Ausführung einer Programminstanz Verzicht auf stichprobenartige Tests

7 Verifikation Ziel: Beweis der Konsistenz zw. der Spezifikation und Implementierung Spezifikation beschreibt formal die geforderten Eigenschaften des Programms formal: temporallogische Ausdrücke (Bounded Model Checking) Ein-/ Ausgangszusicherungen (Hoare-Kalkül) Außerdem notwendig: formal spezifizierte Semantik der Programmiersprache

8 Hoare-Kalkül (Allgemein)
Halb-automatisches Verifikationsverfahren Programm: Sequenz von Zuständen und Pfaden Zustände: als Variablenwerte repräsentiert Gültige logische Aussagen in Bezug auf Variablen als Zusicherungen (assertions) bezeichnet Spezifikation des Programms: Eingangs- und Ausgangszusicherung des Programms {Q} S {R}

9 Zusicherungen Vor der Ausführung einer Anweisung S gilt die Vorbedingung Q Nach der Ausführung von S gilt die Nachbedingung R boolsche Ausdrücke (Prädikatenlogik) über Variablenwerte (Zustände) des Programms Allquantor und Existenzquantor

10 Semantik / Beweisregeln
WHILE-Sprache mit folgenden Konstrukten Arithmetische Ausdrücke Boolsche Ausdrücke Programmanweisungen (Zuweisung, skip-, if-, while-Konstrukte) Axiomatische Semantik 6 Beweisregeln

11 Zuweisungsaxiom (A1) gegeben: Nachbedingung R
gesucht: passende Vorbedingung RAx Vorgehen: alle Vorkommen von x in R durch A zu ersetzen

12 IF-Regel (A2) gegeben: zwei Programmstücke S1, S2 Q, R und Bedingung B Falls im Zähler in angegebener Form  Zusammenfassung zum Nenner möglich

13 Konsequenzregel (A3, A4) gegeben:
Programmanweisung S Q‘ und R‘ Q‘ kann durch schärfere Vorbedingung Q ersetzt werden (A3) R‘ kann durch schwächere Nachbedingung R ersetzt werden (A4)

14 Sequenzregel (A5) gegeben:
Programmanweisungen S1, S2 Q‘ ist Nachbedingung von S1 und Vorbedingung von S2 S1 und S2 können als Sequenz geschrieben werden ohne die Bedingung Q‘

15 WHILE- Regel (A6) gegeben:
Schleifeninvariante P und Bedingung B S wird solange wiederholt, bis die B nicht mehr erfüllt ist

16 Schleifeninvariante Zusicherung an der Schnittstelle einer Schleife
Ergibt unabhängig von der Anzahl der Schleifendurchläufe immer eine wahre Aussage Gilt vor und nach der Ausführung der Schleife Geeignete Invariante kann nicht automatisch gefunden werden. Wird Meistens aus der Nachbedingung abgeleitet . Richtige Invariante?  Beweis durch vollständige Induktion

17 Beispiel {x > 0 y > 0}
z := 0; n := x; while n > 0 do begin z := z + y; n := n – 1; end; {(z = x * y) (n = 0) (y > 0)} Programm zur Multiplikation von zwei positiven ganzen Zahlen Schleifeninvariante: (z + ny = xy) (n >= 0) (y > 0).

18 Beispiel {x > 0 y > 0}
z := 0; n := x; {(z + ny = xy) (n >= 0) (y > 0)} while n > 0 do begin z := z + y; n := n – 1; end; {(z = x * y) (n = 0) (y > 0)} Programm zur Multiplikation von zwei positiven ganzen Zahlen Schleifeninvariante: (z + ny = xy) (n >= 0) (y > 0).

19 Beispiel Q {x > 0 y > 0}
z := 0; n := x; {(z + ny = xy) (n >= 0) (y > 0)} while n > 0 do begin z := z + y; n := n – 1; end; R {(z = x * y) (n = 0) (y > 0)} Herleitung der Eingangszusicherung Q aus der Ausgangszusicherung R durch Anwendung der Regeln  partielle Korrektheit bewiesen.

20 Beispiel Q {x > 0 y > 0} z := 0; n := x;
Inv {(z + ny = xy) (n >= 0) (y > 0)}

21 Beispiel Q {x > 0 y > 0} z := 0; (A1) n := x;
Inv {(z + ny = xy) (n >= 0) (y > 0)}

22 Beispiel Q {x > 0 y > 0} z := 0;
{(z + xy = xy) (x >= 0) (y > 0)} (A1) n := x; Inv {(z + ny = xy) (n >= 0) (y > 0)}

23 Beispiel Q {x > 0 y > 0} (A1) z := 0;
{(z + xy = xy) (x >= 0) (y > 0)} (A1) n := x; Inv {(z + ny = xy) (n >= 0) (y > 0)}

24 Beispiel Q {x > 0 y > 0} {(0 + xy = xy) (x >= 0) (y > 0)}
(A1) z := 0; {(z + xy = xy) (x >= 0) (y > 0)} (A1) n := x; Inv {(z + ny = xy) (n >= 0) (y > 0)}

25 Beispiel Q {x > 0 y > 0}
{(0 + xy = xy) (x > 0) (x = 0) (y > 0)} {(0 + xy = xy) (x >= 0) (y > 0)} (A1) z := 0; {(z + xy = xy) (x >= 0) (y > 0)} (A1) n := x; Inv {(z + ny = xy) (n >= 0) (y > 0)}

26 Beispiel Q {x > 0 y > 0} (A3)
{(0 + xy = xy) (x > 0) (x = 0) (y > 0)} {(0 + xy = xy) (x >= 0) (y > 0)} (A1) z := 0; {(z + xy = xy) (x >= 0) (y > 0)} (A1) n := x; Inv {(z + ny = xy) (n >= 0) (y > 0)}

27 Beispiel Q {x > 0 y > 0}
{(0 + xy = xy) (x > 0) (y > 0)} (A3). {(0 + xy = xy) (x > 0) (x = 0) (y > 0)} {(0 + xy = xy) (x >= 0) (y > 0)} (A1) z := 0; {(z + xy = xy) (x >= 0) (y > 0)} (A1) n := x; Inv {(z + ny = xy) (n >= 0) (y > 0)} Damit das obere Teil des Programms (rückwärts) bewiesen

28 Beispiel Bei der Ausführung des Schleifenrumpfes, d.h. B gilt:
Inv {(z + ny = xy) (n >= 0) (y > 0)} while n > 0 do begin B=(n>0) {(z + ny = xy) (n > 0) (y > 0)} z := z + y; n := n – 1; (A1, A5) {(z+y + (n-1)y = xy) (n-1 > 0) (y > 0)} wg. n-1 {(z + ny = xy) (n >= 0) (y > 0)} = Inv!

29 Beispiel Wenn die Schleifenbedingung B nicht gilt: Inv {(z + ny = xy) (n >= 0) (y > 0)} while n > 0 do begin ... end; {(z + ny = xy) (n >= 0) (n >0) (y > 0)} R {(z = x * y) (n = 0) (y > 0)} Damit der untere Teil des Programms, sowie die partielle Korrektheit des gesamten Programms bewiesen.

30 Terminationsfunktion t
Notwendig, um beweisen zu können, dass die Schleife terminiert (totale Korrektheit) Wird jedem Schleifendurchlauf zugeordnet Wertbereich: ganzzahlige nicht-negative Zahlen Mit jedem Schleifendurchlauf sollte der Wert kleiner werden  streng monoton fallende Folge  Schleife terminiert Für obiges Beispiel t = n  Schleife terminiert  Programm total korrekt!

31 Bounded Model Checking (Allgemein 1/2)
BMC ist ein automatisches Verifikationsverfahren Verifikation von zustandsbasierten nebenläufigen Systemen Für reaktive Systeme verwendet, welche nicht terminieren  z.B. Kommunikationsprotokolle, Betriebssysteme auch für eingebettete Systeme Systemverhalten durch Zustände beschrieben Zustände als Bitfolge dargestellt Zustände und Zustandsübergänge als Kripke-Strukturen beschrieben und als gerichteter Graph modelliert

32 Bounded Model Checking (Allgemein 2/2)
Idee: nur endlich lange Pfade betrachten und daraus das Verhalten des Systems bei unendlich langen Pfaden schließen Vorgehen: entlang der Pfade im Baum überprüfen, ob die Eigenschaft erfüllt wird. Ergebnis des Verfahrens: gezeigt, dass die Eigenschaften (logische Formeln) erfüllt werden, oder Gegenbeispiel  Verbesserung der Systems

33 Kripke-Modell Quintupel M= M = (S, I, T, A, l )

34 Beispiel: Kripke-Modell

35 Temporallogische Ausdrücke
Bilden die Spezifikation, d.h. gewünschte Eigenschaften als temporallogische Ausdrücke angegeben Temporallogik ist um die Temporaloperatoren (TO) erweiterte Aussagenlogik TO erlauben Aussagen über zukünftiges Verhalten des Systems Verschiedene zeitliche Modelle liegen zugrunde: Verzweigte Zeit: Computation Tree Logic Lineare Zeit: Linear Temporal Logic (LTL)

36 LTL-Operatoren Bilden die Spezifikation
Temporallogische Aussagen werden in aussagenlogische übersetzt  Entscheidbarkeitsproblem der Aussagenlogik

37 SAT-Tools Vorteil der Übersetzung in aussagenlogisches Problem: schnelle und effiziente Prüfung durch SAT-Tools SAT-Verfahren bilden Variationen des Davis-Putman-Algorithmus

38 Symbolischer Test (1/3) Symbolische Ausführung eines Programms
Variablen des Programms statt konkreter mit symbolischen Werten versehen Anschließend Ausführung durch einen Interpreter  künstliche Umgebung es werden Wertbereiche abgedeckt  kein Stichprobencharakter Aber: es wird kein mathematischer Korrektheitsbeweis erbracht

39 Symbolischer Test (2/3) Ergebnis der Ausführung: Baum von Anweisungen (symbolischer Ausführungsbaum) Wurzel: Programmbeginn Blätter: Pfadbedingung (logische Ausdrücke) symbolischer Wert der Ausgabevariablen Pfadbedingung: gibt an, wie die Eingaben sein müssen, um den Wert der Ausgabevariablen zu bekommen

40 Symbolischer Test (3/3) Bedingungen für den ST:
Kleine Anzahl von Pfaden (keine Schleifen mit Abbruchbedingung im Schleifenkörper) Vermeidung von bestimmten Datenstrukturen, z.B. Fließpunktdatentypen Korrektheit gezeigt bei Überdeckung zw. Eingabebereich und Pfadbedingungen sowie Übereinstimmung zw. Ergebnisausdrücken und Spezifikation

41 Zusammenfassung (1) Hoare-Kalkül:
Problematisch neben Schleifen sind die Rekursionen  vollständige Induktion Höherer Aufwand  bei umfangreichen und komplexen Programmen Beweis manchmal unmöglich Kein Verzicht auf konventionelles Testen  z.B. Gleitpunktarithmetik Halb-automatisch (Invarianten, Beweise)  viele Werkzeuge Menschlicher Irrtum beim Beweis  Verifikation kann Fehler beinhalten

42 Zusammenfassung (2) BMC: Symbolischer Test
Nicht Terminierung, sondern Erfüllung von best. Eigenschaften im Vordergrund (Lebendigkeit, Sicherheit)  keine totale Korrektheit Partielle Korrektheit mit vollständiger Sicherheit nicht beweisbar  Schließen von nicht-terminierenden auf terminierende Systeme Schneller als z.B. das Symbolic Model Checking Automatisches Verfahren  Werkzeugunterstützung gegeben (SATO, PROVE) Symbolischer Test Kein Korrektheitsbeweis nur Fehleraufdeckung Eingabebereiche überprüft  größere Leistungsfähigkeit im Ggs. zu konventionellen Tests Maschineneigenschaften nicht berücksichtigt  z.B. Fließpunktzahlen Kein Verzicht auf konventionelle Tests Einsatz als Testdatengenerator

43 Zusammenfassung (3) höhere Sicherheit bzgl. der Fehlerfreiheit ggü. den konventionellen Testverfahren Bei alle Verfahren Compilerfehler möglich  damit vollständige Fehlerfreiheit der SW durch alleinige Anwendung nicht erreichbar für sicherheits- und funktionskritische Bereiche