Beweisbar korrekte Software eine praktische Einführung Dominik Haneberg, Gerhard Schellhorn, Jonathan Schmitt 1 Organisatorisches Vorlesung: Mittwoch 10.00 Uhr - 11.30 Uhr (1005 L1) Versuche: (Raum 1006, 2 Termine wählen) Montag: 10.00 - 11.30 Uhr Montag: 11.45 - 13.45 Uhr Montag: 14.00 - 15.30 Uhr Montag: 15.45 - 17.30 Uhr 2 Anmeldung • Maximal 40 Teilnehmer in Zweiergruppen • Paarweise in die erste Liste in Zweiergruppen eintragen: Ergibt Gruppennummer • Zweite Liste: Unter der Gruppennummer aus den 4 möglichen Terminen so viele wie möglich auswählen (nicht bloss 2!) • Wir verteilen die Gruppen auf mögliche Termine (je 2 pro Gruppe) • Bei zuviel Teilnehmern: Los. • Vorausgesetzt: Kenntnisse aus Logik-Vorlesung Logik bestanden ⇒ bevorzugt • Spätestens morgen: Welche Gruppennummer wann dran ist auf WWW 3 Prüfung • • Anwesenheitspflicht in den Übungen! Vorbereitung der Aufgaben anhand der Doku • Abgabe der gelösten Aufgaben per Mail. • 2 Mündliche Abnahmen im Semester in Zweiergruppen : ⋆ 1. Abnahme nach 6 Wochen (zu: Prädikatenlogik und Algebraische Spezifikation) ⋆ 2. Abnahme am Ende (Programmbeweisen) • mit: Testaufgaben (KIV) & Fragen zur Vorlesung 4 Schein und Sprechstunden Schein 2 V + 4 Ü = 8 Creditpoints für den Bereich ”Softwaretechnik” oder für den Bereich ”Theoretische Informatik” Sprechstunden Dominik Haneberg: Raum 2032, Tel. 2178 Gerhard Schellhorn: Raum 2002A, Tel. 2124 Jonathan Schmitt: Raum 2028, Tel. 2176 5 BKS: 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! • 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! Beweise für Software sind häufig sehr langwierig (viele Details) und daher noch fehleranfälliger als die Programme selbst. Problem ⇒ Systemunterstützung mit KIV (andere Systeme: ACL2, Isabelle, PVS, . . . ) Durch die Systemunterstützung wird die korrekte Anwendung von Kalkülregeln sichergestellt 9 Lernziele • Erlernen des Umgangs mit KIV • Formales Beweisen mit KIV ⋆ Umsetzen von Beweisen in einen Kalkül ⋆ Automatisierung durch Simplifikation und Heuristiken ⋆ Beweise für Datenstrukturen und Programme • Strukturierte Spezifikation mit KIV • Verschiedene Verfeinerungskonzepte um von abstrakten Spezifikationen zu konkreten Programmen zu kommen 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.Bsp. Security Protokolle) ⋆ Datenflussanalyse (z.Bsp. MS Kernel Treiber im SLAM-Projekt). ⋆ predicative Abstraction und Typechecking (z.Bsp. 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) • Verwendung der Vorgehensmethodik (“UML, aber eine Nummer präziser”) 11 Überblick 1. 2. 3. 4. 5. 6. Aussagen- und Prädikatenlogik Beweise über Datenstrukturen (Listen) Algebraische Spezifikationen Programmbeweise (Hoare, while-Schleifen) Modulverifikation Abstract State Machines und Refinement 12 (2 Wochen) (2 Wochen) (1 Woche) (2 Wochen) (2 Wochen) (3 Wochen) Prädikatenlogik mit Sorten und Sequenzenkalkül 13 Prädikatenlogik mit Sorten • in Logik f. Inf.: n-stellige Funktionssymbole f ∈ F n Semantik: n-stellige Funktion über Grundbereich D • BKS: gegeben ist eine endliche Menge S von Sorten. Semantik: jede Sorte bezeichnet einen Grundbereich • Funktionen jetzt: f ∈ Fs→s′ oder einfacher: f : s → s wobei s = s1 , . . . , sn mit n ≥ 0 (n = 0 : Konstante c : s) • Vorteile: • Theorie: • Praxis: 14 Prädikatenlogik mit Sorten • in Logik f. Inf.: n-stellige Funktionssymbole f ∈ F n Semantik: n-stellige Funktion über Grundbereich D • BKS: gegeben ist eine endliche Menge S von Sorten. Semantik: jede Sorte bezeichnet einen Grundbereich • Funktionen jetzt: f ∈ Fs→s′ oder einfacher: f : s → s wobei s = s1 , . . . , sn 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 = OPs→s′ s∈S ∗ ,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 Xs für jede Sorte s ∈ S 16 Syntax von Ausdrücken Ausdrücke e ∈ EXP Rs (Σ, X) der Sorte s ∈ S über der Signatur Σ und über den Variablen X sind rekursiv definiert durch • x aus Xs ist ein Ausdruck der Sorte s • Sind e1 , . . . , en Ausdrücke der Sorten s1 , . . . , sn und op : s1 , . . . , sn → s′ , dann ist op(e1 , . . . , en ) ein Ausdruck der Sorte s′ • Bem.: Schreibe c statt c() für Konstanten (n = 0) • sind e1 , e2 Ausdrücke der Sorte s, so ist e1 = e2 eine Formel (i.e. ein Ausdruck der Sorte bool ). • Ist ϕ eine Formel, und x eine Variable, so sind ∀ x.ϕ und ∃ x.ϕ Formeln. EXP R(Σ, X) := S s∈S EXP Rs (Σ, X), F or(Σ, X) := EXP Rbool (Σ, 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: . ⊕ . : s1 × s2 → s, s1 , s2 , s ∈ S • üblich: ⊕ besteht aus Sonderzeichen, z. B. +, ∗, <, /, ⊕, ∈, ≥ • Term (t1 ⊕ t2 ) • 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 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 ϕ1 , . . . , ϕn ψ 1 , . . . , ψm Sequenz Antezedent (n ≥ 0) Sukzedent (m ≥ 0) Beachte: “⊢” ist Sequenzenpfeil, “⊢PL ” ist Ableitbarkeit 20 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: Γ ⊢ ∆ = V 21 Γ→ W ∆ 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, Γ ⊢ ∆ Γ′ ⊢ ∆′ (weakening, Γ′ ⊆ Γ, ∆′ ⊆ ∆) Γ⊢∆ (false left) Γ ⊢ ϕ, ∆ ϕ, Γ ⊢ ∆ (cut formula) Γ⊢∆ Γ ⊢ ϕ, ∆ (negation left) ¬ ϕ, Γ ⊢ ∆ ϕ, ψ, Γ ⊢ ∆ ϕ ∧ ψ, Γ ⊢ ∆ ϕ, Γ ⊢ ∆ ψ, Γ ⊢ ∆ ϕ ∨ ψ, Γ ⊢ ∆ Γ ⊢ ϕ, ∆ ψ, Γ ⊢ ∆ ϕ → ψ, Γ ⊢ ∆ Γ ⊢ true, ∆ (true right) ψ, Γ ⊢ ∆ (negation right) Γ ⊢ ¬ ψ, ∆ (conjunction left/right) Γ ⊢ ϕ, ∆ Γ ⊢ ψ, ∆ Γ ⊢ ϕ ∧ ψ, ∆ (disjunction left/right) Γ ⊢ ϕ, ψ, ∆ Γ ⊢ ϕ ∨ ψ, ∆ (implication left/right) ϕ, Γ ⊢ ψ, ∆ Γ ⊢ ϕ → ψ, ∆ Γ ⊢ ϕ, ψ, ∆ ϕ, ψ, Γ ⊢ ∆ ϕ, Γ ⊢ ψ, ∆ ψ, Γ ⊢ ϕ, ∆ (equivalence left/right) ϕ ↔ ψ, Γ ⊢ ∆ Γ ⊢ ϕ ↔ ψ, ∆ 25 Regeln für Quantoren und Gleichungen ϕτx , ∀ x.ϕ, Γ ⊢ ∆ (all left) • ∀ x.ϕ, Γ ⊢ ∆ Γ ⊢ ϕτx , ∃ x.ϕ, ∆ (exists right) Γ ⊢ ∃ x.ϕ, ∆ ϕyx , Γ ⊢ ∆ • (exists left) ∃ x.ϕ, Γ ⊢ ∆ Γ ⊢ ϕyx , ∆ (all right) Γ ⊢ ∀ x.ϕ, ∆ ϕτ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 6∈ (free(ϕ)\{x}) ∪ free(Γ) ∪ free(∆) • Γ ⊢ τ = τ, ∆ x = τ, Γτx ⊢ ∆τx (insert equation) x = τ, Γ ⊢ ∆ (reflexivity right) 26 Variablen und freie Variablen eines Ausdrucks Die Variablen eines Ausdrucks (Var (e)) Var (x) Var (op(t1 , . . . , tn )) Var (e = e′ ) Var (Qx.ϕ) = = = = {x} x∈X Sn i=1 Var (ti ) Var (e) ∪ Var (e′ ) {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 (etx ) xtx = t yxt = y falls x 6= y op(e1 , . . . , en )tx = op((e1 )tx , . . . , (en )tx ) (e1 = e2 )tx (Qy.ϕ)tx = (e1 )tx = (e2 )tx ) = Qy.ϕ Qy.ϕt x Qz.(ϕzy )tx falls y = x ∨ x 6∈ free(ϕ) falls y 6= x, y 6∈ free(t), x ∈ free(ϕ) falls y 6= x, y ∈ free(t), x ∈ free(ϕ) (z neu, d. h. z 6∈ 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 ⋆ einen Beweis führen 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 Bis nächsten Montag Vorbereiten der ersten Übung anhand der Doku! 33