Formale Methoden im Software Engineering Eine praktische Einführung Dominik Haneberg, Florian Nafz, Bogdan Tofan 1
Organisatorisches Vorlesung: Mittwoch 12:15 Uhr - 13:45 Uhr (1058 N) Versuche: (Raum 3017 N, 2 Termine wählen) Freitag: 08:15-09:45 Uhr Freitag: 10:00-11:30 Uhr Freitag: 12:15-13:45 Uhr Freitag: 14:00-15:30 Uhr 2
Anmeldung Maximal 40 Teilnehmer in Zweiergruppen In Zweiergruppen in die Liste eintragen: Ergibt Gruppennummer Dann ganz rechts aus den 4 möglichen Terminen so viele wie möglich auswählen (nicht bloß 2!) Wir verteilen die Gruppen auf mögliche Termine (je 2 pro Gruppe) Bei zu vielen Teilnehmern: Los. Vorausgesetzt: Kenntnisse aus Logik-Vorlesung Logik bestanden bevorzugt Spätestens morgen auf Webseite: Welche Gruppen an welchen Terminen 3
Prüfung Anwesenheitspflicht in den Übungen! Vorbereitung der Aufgaben anhand der Doku! Abgabe der gelösten Aufgaben im SVN. 2 Mündliche Abnahmen im Semester in Zweiergruppen: 1. Abnahme nach ca. 6 Wochen (zu: Prädikatenlogik und Algebraische Spezifikationen) 2. Abnahme am Ende (Programmbeweisen und TL) Mit: Testaufgaben (KIV) & Fragen zur Vorlesung 4
Leistungspunkte und Sprechstunden Leistungspunkte 2 V + 4 Ü = 8 Creditpoints. Alte PO: Für den Bereich Softwaretechnik oder für den Bereich Theoretische Informatik Neue PO: Nur für den Bereich Softwaretechnik Sprechstunden Dominik Haneberg: Raum 3015 N, Tel. 2178 Florian Nafz: Raum 3013 N, Tel. 2207 Bogdan Tofan: Raum 3043 N, Tel. 2181 5
Formale Methoden: Ziel und Vorgehen Ziel: Beweisbar korrekte Software Vorgehen 1. Formale Spezifikation der Anforderungen 2. Validierung/Nachweis von Sicherheitseigenschaften 3. Programmierung 4. Beweis, dass Programm die Spezifikation erfüllt Notwendig Definition formaler Modelle und Aussagen Logik 6
Verschiedene Logiken Aussagenlogik Prädikatenlogik (erster Stufe) Logiken höherer Stufe Hoare-Logik (imperative Programme) Dynamische Logik (imperative Programme) LCF (funktionale Programme) Temporallogik (parallele Programme) (Modallogik) (Nichtmonotone Logik) 7
Warum Beweise über Programme? Fehler in Software sind eine nicht enden wollende Geschichte: Oft nur ärgerlich, manchmal sehr teuer oder sogar lebensgefährlich! Softwarefehler in deutschen EC-Karten Anfang 2010 Verlust aller Kontaktdaten der Sidekick- Nutzer von T-Mobile USA (Okt. 2009) Gepäckverteilung Flughafen Denver (1994) und Terminal 5 London Heathrow (2008) Ausfall des A340-Autopiloten Strahlentherapiesystem Therac-25 Ariane 5 Explosion beim ersten Start Mars Climate Orbiter und Mars Polar Lander... 8
Warum formale Beweise mit KIV? These: Eine detaillierte Analyse des Programms von Hand genügt, um seine Korrektheit nachzuweisen! Problem 9
Warum formale Beweise mit KIV? These: Eine detaillierte Analyse des Programms von Hand genügt, um seine Korrektheit nachzuweisen! Problem Beweise über Software sind häufig sehr langwierig (viele Details) und daher noch fehleranfälliger als die Programme selbst. Systemunterstützung mit KIV (andere Systeme: ACL2, Isabelle, PVS,... ) Durch die Systemunterstützung wird die Korrektheit der Beweise (durch korrekte Anwendung der Kalkülregeln) sichergestellt 9
Lernziele Erlernen des Umgangs mit KIV Strukturierte Spezifikation mit KIV Formales Beweisen mit KIV Umsetzen von Beweisen in einem Kalkül Automatisierung durch Simplifikation und Heuristiken Beweise für Datenstrukturen und Programme Verschiedene Verfeinerungskonzepte um von abstrakten Spezifikationen zu konkreten Programmen zu kommen Verifikationstechnik für nebenläufige Systeme 10
Praktische Anwendung Einsatz von KIV durch KIV-Experten in sicherheitskritischen Anwendungen Einsatz von automatischen (spezialisierten) Tools: Model Checking (HW-Design, eingebettete Systeme) Bounded Model Checking, SAT checking (z. B. Security-Protokolle) Datenflussanalyse (z. B. MS Kernel Treiber im SLAM-Projekt) Predicative Abstraction und Typechecking (z. B. Nullpointer-Exceptions, SPEC#) Entscheidungsprozeduren für Arithmetik (z.b. für Zeitconstraints bei Echtzeitsystemen)... Systematisches Testen mit aus Spezifikationen generierten Testfällen Konstruktion von endlichen Gegenbeispielen (z. B. Alloy, MACE) 11
Überblick 1. Aussagen- und Prädikatenlogik (2 Wochen) 2. Beweise über Datenstrukturen (Listen, Heaps) (3 Wochen) 3. Algebraische Spezifikationen (1 Woche) 4. Programmbeweise (Hoare, while-schleifen) (2 Wochen) 5. Data Refinement (2 Wochen) 6. Temporallogik & Parallele Programme (2 Wochen) 12
Prädikatenlogik mit Sorten und der Sequenzenkalkül 13
Prädikatenlogik mit Sorten In Logik für Inf.: n-stellige Funktionssymbole f F n Semantik: n-stellige Funktion über Grundbereich D Hier: Gegeben ist eine endliche Menge S von Sorten. Semantik: Jede Sorte bezeichnet einen Grundbereich Funktionen jetzt: f F s s oder einfacher: f : s s wobei s = s 1,...,s n mit n 0 (n = 0: Konstante c : s) Vorteile: Theorie: Praxis: 14
Prädikatenlogik mit Sorten In Logik für Inf.: n-stellige Funktionssymbole f F n Semantik: n-stellige Funktion über Grundbereich D Hier: Gegeben ist eine endliche Menge S von Sorten. Semantik: Jede Sorte bezeichnet einen Grundbereich Funktionen jetzt: f F s s oder einfacher: f : s s wobei s = s 1,...,s n mit n 0 (n = 0: Konstante c : s) Vorteile: Pro Datentyp eine Sorte, damit Typcheck wie in Prog.-sprachen Später: Leichte Erweiterbarkeit zu Higher-Order-Logik Theorie: Sorten können in Prädikate codiert werden Praxis: Ohne Sorten zusätzliche Axiome und Deduktion notwendig! (Z. B. nat(x) nat(y) nat(x + y)) Es gibt immer eine vordefinierte Sorte bool. 14
Die Sorte bool: Formeln sind auch Terme! Mit einer vordefinierten Sorte bool wird es möglich, Formeln und Terme der Sorte bool zu identifizieren Logische Operatoren sind jetzt vordefinierte boolesche Funktionen:..,..,..,.. : bool bool bool. : bool bool true,false : bool Formeln ϕ, ψ und Terme t heissen jetzt Ausdrücke e Prädikate sind einfach Funktionen mit Zielsorte bool Funktionen und Prädikate heissen jetzt Operationen OP 15
Signaturen und Variablen Eine Signatur Σ = (S,OP) ist ein Paar mit: Endlicher Menge S von Sorten, mit bool S Endlicher Familie OP = s S,s S OP s s von Operationssymbolen mit Argumentsorten s und Ergebnissorte s (leere Liste von Argumentsorten: Konstante c) OP enthält immer die üblichen booleschen Operationen Wie üblich: Konstanten sind null-stellige Operationen Boolesche Konstanten = atomare Aussagen Eine Variablenmenge X besteht aus einer abzählbar unendlichen Menge von Variablen X s für jede Sorte s S 16
Syntax von Ausdrücken Ausdrücke e EXPR s (Σ,X) der Sorte s S über der Signatur Σ und über den Variablen X sind rekursiv definiert durch x aus X s ist ein Ausdruck der Sorte s Sind e 1,...,e n Ausdrücke der Sorten s 1,...,s n und op : s 1,...,s n s, dann ist op(e 1,...,e n ) ein Ausdruck der Sorte s Bem.: Schreibe c statt c() für Konstanten (n = 0) Sind e 1,e 2 Ausdrücke der Sorte s, so ist e 1 = e 2 eine Formel (i. e. ein Ausdruck der Sorte bool) Ist ϕ eine Formel und x eine Variable, so sind x.ϕ und x.ϕ Formeln EXPR(Σ,X) := s S EXPR s (Σ,X),For(Σ,X) := EXPR bool (Σ,X) Terme t T(Σ,X) sind Ausdrücke ohne Quantoren und Gleichheit. 17
KIV-Syntax für Signaturen sorts nat; list; constants 0 : nat; ϕ : bool; (: 0-stelliges Prädikat als boolesche Konstante :) functions f : nat nat nat; g : nat, nat -> nat; (: es geht auch ASCII :) predicates isprime : nat;. <. : nat nat; variables x,y : nat; u : list; Sorten, Funktionen, Prädikate, Variablen immer in dieser Reihenfolge Aufzählungen mit derselben Sorte nur bei Variablen 18
KIV: Infix-Schreibweise und Bindungsstärken Signatur:.. : s 1 s 2 s, s 1,s 2,s S Üblich: besteht aus Sonderzeichen, z. B. +,, <, /,,, Term (t 1 t 2 ) Infix-Funktionssymbole in KIV können priorisiert werden ( bindet stärker als +) Es gibt auch Postfix (z. B. für Fakultät.! ) und Präfix (für Anzahl der Elemente: # = 0) Bindungsstärken {postfix} > {präfix} > {infix} > { } > { } > { } > { } > { } > {, } Außenklammern werden weggelassen, Aufzählungen mit, ungeklammert. 19
Sequenzenkalkül Erfunden von Gerhard Gentzen (1934) Nur einer von vielen möglichen Kalkülen: Hilbertkalkül, natürliches Schliessen, Tableaukalkül, Modellelimination Charakteristik: Versucht, Beweisziel auf Axiome zu reduzieren (schrittweise Vereinfachung des Problems); am menschlichen Beweisen orientiert ϕ 1,...,ϕ n ψ 1,...,ψ m Sequenz ϕ 1,...,ϕ n Antezedent (n 0) ψ 1,...,ψ m Sukzedent (m 0) Beachte: ist Sequenzenpfeil, PL ist Ableitbarkeit 20
Sequenzenkalkül Notation Γ,Γ 1,,... Listen von Formeln, Γ = ϕ 1,...,ϕ n, = ψ 1,...,ψ m Γ := ϕ 1,...,ϕ n ψ 1,...,ψ m Γ,ϕ ψ := ϕ 1,...,ϕ n,ϕ ψ Γ,ϕ ψ, := ϕ 1,...,ϕ n,ϕ ψ,ψ 1,...,ψ m [ϕ1,...,ϕ n ] := ϕ 1... ϕ n [] := true [ψ1,...,ψ m ] := ψ 1... ψ m [] := false Bedeutung einer Sequenz: Γ = Γ 21
Sequenzenkalkül: Inferenzregeln Regel: (n 0) Γ 1 1 Γ 2 2... Γ n n Γ Regeln werden von unten nach oben gelesen: Um Γ (die Konklusion) zu beweisen, beweise stattdessen einfachere Prämissen Γ 1 1,...,Γ n n Bei n = 0 ist die Konklusion direkt bewiesen n = 1: Vereinfachung n = 2: Fallunterscheidung 22
Beispiel Ein erster Beweis. 23
Sequenzenkalkül: Ableitbarkeit Γ ist aus einer Menge von Formeln (Axiomen) Ax ableitbar (kurz: Ax PL Γ ) : Es gibt eine Ableitung (Baum) mit Wurzel: Γ (Konklusion) Blätter: ϕ mit ϕ Ax (Prämissen) Innere Knoten durch Regelanwendungen gebildet 24
Kalkül für Aussagenlogik ϕ,γ ϕ, (axiom) false,γ (false left) Γ true, Γ Γ (weakening, Γ Γ, ) Γ ϕ, Γ ϕ,γ Γ ϕ, ϕ,γ (negation left) ψ,γ Γ ψ, ϕ,ψ,γ ϕ ψ,γ ϕ,γ Γ ϕ, ϕ ψ,γ ψ,γ ψ,γ ϕ ψ,γ Γ ϕ,ψ, ϕ,ψ,γ ϕ ψ,γ (conjunction left/right) (disjunction left/right) (implication left/right) (equivalence left/right) 25 Γ ϕ, ϕ,γ ψ, (true right) (cut formula) (negation right) Γ ϕ ψ, Γ ψ, Γ ϕ,ψ, Γ ϕ ψ, ϕ,γ ψ, Γ ϕ ψ, ψ,γ ϕ, Γ ϕ ψ,
Regeln für Quantoren und Gleichungen ϕτ x, x.ϕ,γ x.ϕ,γ (all left) Γ ϕ τ x, x.ϕ, Γ x.ϕ, (exists right) ϕ y x,γ x.ϕ,γ (exists left) Γ ϕ y x, Γ x.ϕ, (all right) ϕ τ x die Substitution von x durch einen beliebigen Term τ in ϕ. y ist eine neue Variable, i. e. eine die nicht frei in Q x.ϕ,γ, (Q {, }) vorkommt. Genauer: y (free(ϕ)\{x}) free(γ) free( ) Γ τ = τ, (reflexivity right) 26 x = τ,γ τ x τ x x = τ,γ (insert equation)
Variablen und freie Variablen eines Ausdrucks Die Variablen eines Ausdrucks (Var(e)) Var(x) = {x} x X Var(op(e 1,...,e n )) = n i=1 Var(e i ) Var(e = e ) = Var(e) Var(e ) Var(Qx.ϕ) = {x} Var(ϕ) Q {, } Die freien Variablen einer Formel (free(ϕ)) sind genauso definiert ausser: free(qx.ϕ) = free(ϕ) \ {x} Q {, } 27
Substitution Die Substitution einer Variablen x durch einen Ausdruck t in e (e t x) x t x = t yx t = y falls x y op(e 1,...,e n ) t x = op((e 1 ) t x,...,(e n ) t x) (e 1 = e 2 ) t x = ((e 1 ) t x = (e 2 ) t x) Qy.ϕ falls y = x x free(ϕ) (Qy.ϕ) t Qy.ϕ t x falls y x,y free(t),x free(ϕ) x = Qz.(ϕ z y) t x falls y x,y free(t),x free(ϕ) (z neu, d. h. z Var(ϕ) Var(t)) (Q {, }) 28
KIV: Organisation in Projekte Grundlegende Organisation: In KIV arbeitet man in (SW-Entwicklungs-) Projekten Jedes Projekt definiert Spezifikationen (Σ + Ax + Weiteres) Spezifikationen können aufeinander aufbauen Entwicklungsgraph Über jeder Spezifikation kann man Theoreme formulieren und beweisen 29
KIV: Projektauswahl- und Projektebene 4 Ebenen: 1. Projektauswahlebene Projekte anlegen, löschen, auf einem Projekt arbeiten 2. Projektebene Zeigt den Entwicklungsgraph der Spezifikationen Spezifikationen anlegen, ändern, löschen Auf einer Spezifikation arbeiten 30
KIV: Spezifikations- und Beweisebene 3. Spezifikationsebene Theoreme anlegen, ändern, löschen Ein Theorem zum Beweisen wählen 4. Beweisebene Beweise führen durch interaktive Anwendung von Regeln Zwei Regelsätze: Basisregeln/für s Beweisen optimierte Regeln Backtracking, Pruning Simplifikation + Heuristiken zur automatischen Anwendung von Regeln 31
KIV: Verzeichnisstruktur Verzeichnisstruktur: Ein Projektverzeichnis <projektname> Darin: Ein Unterverzeichnis specs [Eine Datei devgraph für den Entwicklungsgraph] In specs: ein Unterverzeichnis <specname> für jede Spezifikation Darin: Eine Datei specification für Signatur, Axiome etc. Eine Datei sequents für Theoreme [Ein Verzeichnis proofs das geladene Theoreme, geführte Beweise etc. speichert] 32