Formale Methoden im Software Engineering

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 SidekickNutzer 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.
2.
3.
4.
5.
6.
Aussagen- und Prädikatenlogik
Beweise über Datenstrukturen (Listen, Heaps)
Algebraische Spezifikationen
Programmbeweise (Hoare, while-Schleifen)
Data Refinement
Temporallogik & Parallele Programme
12
(2 Wochen)
(3 Wochen)
(1 Woche)
(2 Wochen)
(2 Wochen)
(2 Wochen)
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 ∈ 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ü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 ∈ 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 =
OP s→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 ∈ EXPR s (Σ, 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
EXPR(Σ, X) :=
S
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: . ⊕ . : 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 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
ϕ1 , . . . , ϕn
ψ 1 , . . . , ψm
Sequenz
Antezedent (n ≥ 0)
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: Γ ⊢ ∆ =
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(e1 , . . . , en ))
Var (e = e′ )
Var (Qx.ϕ)
=
=
=
=
{x}
x∈X
Sn
i=1 Var (ei )
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
• 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