Formale Spezifikationund Induktion

Transkript

1 Formale Spezifikationund Induktion 91

2 Was ist ein SW-System mathematisch? 1. Sicht: Operational Ein SW-System ist ein Automat mit Zustand, Zustandsübergängen und mit Abläufen. 2. Sicht: Algebraisch Ein SW-System ist eine Algebra = Datenstruktur, d. h. ein System von Daten und Operationen. 92

3 Was ist spezieller? Einen Automaten kann man als spezielle Algebra auffassen: Zustand = Element einer Datenstruktur Algebra! Sorten = State, Input, Output mit Operationen Anfangszustände: isinitial: State Bool Zustandsübergangsfunktion (oder auch Relation): exec: Input State (State Output Bool) Z. B. Zustand eines Programms: Programm + Programmzähler + Speicherbelegung Theoretisch: Algebraische Sicht genügt Praktisch: Automatensicht hat viele Spezialeigenschaften (u.a. ist eine Idee von Zeit damit verbunden). Deshalb Codierung oft nicht die beste Idee. 93

4 SW-Beschreibungsformalismen SW-System ist Datentyp: Modellorientierte Spezifikation (Z, VDM): Alle Datentypen sind mit Mengenlehre gebildet (Tupel und Mengen z. B. für UML-Klassendiagramme) Algebraische Spezifikation SW-System ist Menge von Abläufen: Algorithmische Spezifikation, z. B. Programmiersprachen Programme über algebraischen/modellorientierten Datentypen Automaten, Harel/UML Statecharts, Abstract State Machines (ASMs) Eignung hängt von den Zielen ab (Was will ich beschreiben? Was beweisen?) 94

5 Spezifikation Ziel: Ein bestimmter Datentyp (Algebra) soll spezifiziert werden. Fragen: 1. Was für Operationen brauche ich? 2. Welche Axiome brauche ich? 3. Welche Datentypen kann ich überhaupt spezifizieren? 4. Kann ich alle wahren Aussagen über dem Datentyp auch beweisen? Zunächst: Fragen speziell für die natürlichen Zahlen 95

6 Natürliche Zahlen: Die Peano-Axiome Es gibt eine ausgezeichnete Zahl 0 IN. Jede Zahl n IN hat einen Nachfolger succ(n) IN. Zu zwei Zahlen gibt es Summe m+n und Produkt m n Axiom 1: 0 ist kein Nachfolger. Axiom 2: Die Nachfolgerfunktion ist injektiv. Axiom 3: m+0 = m, m + succ(n) = succ(m+n) Axiom 4: m 0 = 0, m succ(n) = m n+m Axiom 5: IN ist die kleinste Menge M mit: 0 M und wenn n M, dann succ(n) M Aus dem letzten Axiom folgt das Induktionsprinzip: Wenn ϕ(0) gilt, und sich ϕ von n auf n+1 vererbt, dann ist ϕ für alle n wahr Begründung: M := {n : ϕ(n)} ist mindestens so groß wie IN. 96

7 Natürliche Zahlen: Mit PL nicht spezifizierbar! Satz (Charakterisierung der natürlichen Zahlen) Die Peano-Axiome charakterisieren ein Modell (eben die natürlichen Zahlen) bis auf Isomorphie (= Umbenennung). Beachte dabei: Peano-Axiom 5 ist kein prädikatenlogisches Axiom! Aber: Satz von Skolem Es gibt keine Menge Ax-Nat von prädikatenlogischen Formeln, die als einziges Modell (modulo Umbenennung) nur die natürlichen Zahlen hat. Beweisbar mit Vollständigkeitssatz Intuition: Prädikatenlogische Axiome können nicht ausdrücken, dass es neben den echten natürlichen Zahlen keine weiteren Zahlen gibt. 97

8 Natürliche Zahlen: Ein schwächeres Ziel Wir wissen schon: Jede Axiomenmenge hat auch andere Modelle als IN mit zusätzlichen Elementen. Wir versuchen es schwächer: Suche Axiomenmenge, mit der alle über IN wahren Formeln bewiesen werden können (dass sie auch über anderen Modellen gelten, könnte uns ja egal sein). Die Axiomenmenge sollte entscheidbar sein, d. h. es gibt Programm, das immer terminiert und sagt: ja, ist Axiom oder nein, ist kein Axiom. Sonst Triviallösung: Nehme als Axiome sämtliche wahren Aussagen. Zum Beispiel: Nehme Induktionsschema zu den Axiomen dazu: ϕ 0 n ( n. ϕ ϕ n +1 n ) n. ϕ; (: für jedes ϕ For(Σ,X) :) Die Formel ϕ(n) mit freier Variable n beschreibt die Menge {n : IN = ϕ(n)}. Das Induktionsschema für ϕ entspricht Peano-Axiom 5 für diese Menge 98

9 Natürliche Zahlen: Unvollständigkeit Problem: Alle Formeln (abzählbar viele) beschreiben nicht alle Mengen (überabzählbar viele)! Es gilt leider: Gödelscher Unvollständigkeitssatz Es gibt keine entscheidbare Menge von Formeln über (0, succ, +, ), die die ersten 4 Peano-Axiome und n 0 n. n = succ(m) enthält oder impliziert, mit der sich alle in IN wahren Aussagen ableiten lassen (insbesondere ist das Induktionsschema auch unvollständig). Der Trick zum Beweis ist das Lügnerparadoxon ( ich lüge jetzt ) in Form einer Formel, die sagt: Ich bin nicht beweisbar. Indem man die Formeln durchnumeriert (z.b. ASCII-Codierung), wird das Ich durch Meine Nummer ausdrückbar. 99

10 Natürliche Zahlen: Unvollständigkeit Intuition: Leider findet man auch keine gute Axiomenmenge, mit der die wahren Aussagen herleitbar sind Alle wahren Aussagen könnte man als Axiome trivialerweise nehmen. Die Menge der wahren Aussagen ist also nicht entscheidbar. Wahre Aussagen für die natürlichen Zahlen zu beweisen, ist kreativ. Verursachte ziemlich viel Wirbel in den 30er Jahren: Die Idee, Mathematik auf ganz einfachen Grundlagen aufzubauen (Hilbert sches Programm) zu definieren, war gescheitert Heute: Komplizierte Mengenlehre (Zermelo-Fränkel, Gödel-Bernays) als Grundlage für Mathematik. 100

11 Problem: Prädikatenlogik reicht nicht Problem: Prädikatenlogik kann nicht ausdrücken, dass es ausser den Zahlen 0,1,2 (= die aus 0 und +1 gebildeten Terme 0,0+1,0+1+1,...) keine weiteren Elemente gibt. Dasselbe Problem gibt es auch für andere Datentypen: Alle ganzen Zahlen sind mit 0, +1, 1 gebildet Alle Listen sind die aus [] und + gebildeten Terme: [], a + [], a + b + [],... Bei Listen: Terme dürfen Elementvariablen enthalten Alle (endlichen) Graphen bekommt man aus dem leeren, durch Addieren von Knoten addnode und Kanten addedge Alle Arrays bekommt man durch: mkarray(n) (erzeugt Array der Grösse n) put(a,i,d) (schreibt an Position i das Datum d) 101

12 Generiertheitsklauseln: Syntax Deshalb Idee: Wir definieren ein Spezialaxiom, genannt Generiertheitsklausel, das aussagt: Die Daten eines Datentyps sind genau die mit bestimmten Konstruktoren gebildeten Terme. Syntax s generated by C ist Termerzeugtheitsklausel ( Gen(Σ)) s S, C = {f 1,...,f n } OP, die Konstruktoren f i haben die Ergebnissorte s (Konstanten sind als Konstruktoren erlaubt) für wenigstens ein f i sind alle Argumentsorten ungleich s (sonst gibt es keine Konstruktorterme!) Ein Konstruktorterm t hat die Sorte s, ist mit Konstruktoren aus C gebildet und enthält nur Variablen anderer Sorten, ist also aus T s ((S,C),X \X s ). 102

13 Generiertheitsklauseln: Semantik Idee: Jedes Element der generierten Sorte ist der Wert eines Konstruktorterms, wenn man die (Parameter)-Variablen geeignet belegt. Semantik A = s generated by C : für jedes a A s gibt es ein v und t T s ((S,C),X \X s ) mit a = [[t]] A,v. Beispiel: Zur Liste [2,5] gibt es den Konstruktorterm a+b+[]. Mit einer Belegung v der Variablen a,b als v(a) = 2 und v(b) = 5 gilt: [[a+b+[]]] A,v = [2,5]. 103

14 Basisspezifikation Basisspezifikation Eine Spezifikation SP = (Σ, Ax, Gen) ist ein Tripel mit: Σ = (S, OP ) Ax For(Σ, X) endlich Gen Gen(Σ) endlich Modell A ist Modell von SP (A = SP, A Mod(SP )) A = SP : A Alg(Σ), A = Gen und A = Ax. Gültigkeit SP = ϕ : für alle A in Mod(SP ): A = ϕ 104

15 Konsistenz und Monomorphie Definition Eine Spezifikation ist konsistent : Axiome nicht widersprüchlich Kein Beweis von false möglich Es gibt ein Modell A der Spezifikation Das muss sein! Definition Eine Spezifikation ist monomorph : Axiome legen Verhalten eindeutig fest Je zwei Modelle sind bis auf Umbenennung (Isomorphie) gleich Sollte für Datentypen wie natürliche Zahlen etc. so sein (die Axiome sollten ja nicht versehentlich auch reelle Zahlen erlauben). Für Systembeschreibungen oft nicht erforderlich bzw. wünschenswert. Man will ja gerade Details offenlassen. 105

16 Minimale Spez. der natürlichen Zahlen in KIV specification sorts nat; constants 0 : nat; functions. +1 : nat nat; induction nat generated by 0, +1; variables m, n : nat; axioms 0 n +1; m n m +1 n +1; end specification ist konsistent und mononorph 106

17 Spez. der natürlichen Zahlen mit Add. und Mult. specification sorts nat; constants 0 : nat; functions. +1 : nat nat;. +. : nat nat nat;.. : nat nat nat; induction nat generated by 0, +1; variables m, n : nat; axioms 0 n +1; m n m +1 n +1; m + 0 = m; m + n +1 = (m + n) +1; m 0 = 0; m (n +1) = m * n + m; end specification ist konsistent und mononorph 107

18 Minimale Spez. der Listen in KIV specification sorts elem; list; constants [] : list; functions. +. : elem list list; induction list generated by [], +; variables a, b : elem; x, y : list; axioms [] a + x; a b x y a + x b + y; end specification ist konsistent und mononorph,wenn die Trägermenge für die Elemente vorgegeben ist ( monomorph modulo Parameter ) 108

19 Kalkül mit struktureller Induktion Strukturelle Induktion Sorte s erzeugt von Konstruktoren c, f Jedes Element der Trägermenge ist darstellbar als Konstruktorterm f(f(...f(c))) Induktionsformeln: ϕ(c) ( x. ϕ(x) ϕ(f(x))) x. ϕ(x) Induktionsregel: ϕ(c) ϕ(x) ϕ(f(x)) Γ ϕ = y. Γ, y = free(γ )\{x} Ableitung Wenn man aus der Spezifikation SP durch Anwendung von Sequenzenkalkül + Induktions-Regel die Formel ϕ ableiten kann, dann schreibt man SP IND ϕ. 109

20 Kalkül mit struktureller Induktion: Korrektheit und Unvollständigkeit Satz (Korrektheit) Es gilt SP IND ϕ SP = ϕ Satz (Unvollständigkeit) Es gibt Spezifikationen und Theoreme mit SP = ϕ, die aber mit Induktion nicht beweisbar sind (SP IND ϕ). 110

21 Wie schlimm ist Unvollständigkeit? Der Kalkül mit der Induktions-Regel ist fast vollständig : Wenn SP = ϕ, dann gibt es eine Erweiterung SP von SP um neue rekursiv definierte Hilfsfunktionen, so dass SP IND ϕ gilt. Praktisch gesehen: Mit den zusätzlichen Symbolen in SP wird eine passend (verallgemeinerte) Induktionshypothese für den Beweis von ϕ ausdrückbar. Beachte: Mit der Generiertheitsklausel ist die Induktionsregel auch auf Formeln mit den Hilfsfunktionen anwendbar (die Menge der möglichen Ind. hypothesen wächst!) SP ist je nach ϕ verschieden (kein uniformes SP ). In jedem SP gibt es neue Formeln ψ, die wahr aber nicht ableitbar sind. Kreativitität also für Verallgemeinerung und passende Hilfsfunktionen. 111

22 Strukturierte Spezifikation: Freie Datentypen 112

23 Wie spezifiziert man Datentypen? Vorgehen: Schritt 1: Definiere benötigte Sorten Schritt 2: Datentypen auf Rechnern sind generiert Definiere Konstruktoren und Generiertheitsklauseln Schritt 3(?): Definiere weitere Operationen und ihre Axiome Problem: Wie geeignete, richtige Axiome finden? Formal richtig : Sie sollten für den gewünschten Datentyp stimmen (keine Inkonsistenz!), und sollten ihn möglichst eindeutig charakterisieren. 113

24 Freie und nichtfreie Datentypen nat nat???? by???? by integer???? by set???? by set???? by stack???? by bintree???? by graph???? by list???? by 114

25 Freie und nichtfreie Datentypen Beobachtung: Manche Datentypen sind frei (erzeugt): Zwei verschiedene Konstruktorterme repräsentieren auch immer zwei verschiedene Elemente. nat 0, +1 nat 0,1,+ integer 0, +1, 1 set, ins set, {.}, stack empty, push bintree mkleaf, mkbranch graph, +node, +edge list [], + 114

26 Freie und nichtfreie Datentypen Beobachtung: Manche Datentypen sind frei (erzeugt): Zwei verschiedene Konstruktorterme repräsentieren auch immer zwei verschiedene Elemente. nat freely generated by 0, +1 nat generated by 0,1,+ 0+0 = 0 integer generated by 0,+1, = 0 set generated by, ins ins(a,ins(a, )) = ins(a, ) set generated by, {.}, {a} {a} = {a} stack freely generated by empty, push bintree freely generated by mkleaf, mkbranch graph generated by, +node, +edge +node n +node n list freely generated by [], + = +node n 114

27 Axiome für freie Datentypen Beispiel: Konstante c, einstellige Funktion f, zweistellige Funktion g Verschiedenheit der Konstruktoren c, f und g: c f(x), f(x) g(y,z), c g(x,y) Injektivität der Konstruktoren: f(x) = f(y) x = y, g(x,y) = g(u,v) x = u y = v Satz: Die Spezifikation mit diesen Axiomen ist monomorph und konsistent, sie charakterisiert also genau einen Datentyp. KIV: Schreibe freely generated by, Axiome werden generiert. 115

28 Freie Erzeugtheitsklauseln Freie Erzeugtheitsklauseln A = S freely generated by C : A = S generated by C Für 2 Konstruktorterme t,t T s ((S,C),X \X s ) mit s S gilt nur dann [[t]] A,v = [[t ]] A,v wenn sie mit den exakt gleichen Konstruktoren gebildet sind, und die Variablen an gleichen Positionen gleich belegt sind. Beispiel Listen: [[[]]] A,v, [[a + []]] A,v, [[a + b + []]] A,v sind auf jeden Fall verschiedene Listen (egal wie die Belegungen v, v, v sind) [[a + []]] A,v = [[b + []]] A,v gdw. wenn v(a) = v (b). 116

29 Natürliche Zahlen als freier Datentyp Beispiel: Die natürlichen Zahlen Nat3 = specification sorts nat; constants 0 : nat; functions +1 : nat nat; variables n : nat; induction nat freely generated by 0, +1; end specification Neu: Axiome jetzt generiert. 117

30 Listen als freier Datentyp Beispiel: Listen als freier Datentyp List2 = specification sorts list, elem; functions [] : list;. +. : elem list list; variables a, b: elem; l, l 1, l 2 : list; induction list freely generated by [], +; end specification 118

31 Generierte Axiome für Listen Generierte Axiome Spezifikation generiert: [] a+l, a+l 1 = b+l 2 a = b l 1 = l 2 Induktionsregel für die Sorte list y. Γ,Γ a+l l Γ a+l l Γ [] l [] l y = free(γ )\{l} 119

32 Datentyp-Definion (Motivation) Häufige Situation: Freie Erzeugbarkeit mit Konstruktoren c Selektoren, die aus c(x 1,...x n ) die x i selektieren Testprädikate ist mit Konstruktor c gebildet Ordnung: ist Unterterm von Größenfunktion: Anzahl nichtkonstanter Konstruktoren Eigenes Syntaxkonstrukt data specification vermeidet unnötige Schreibarbeit. In KIV typischerweise nie freely generated, sondern gleich data specification 120

33 Data Specification (Beispiel 1) Beispiel 1: Wochentage Weekday2 = data specification weekday = Mon Tue Wed Thu Fri Sat Sun; variables w : weekday; end data specification Generierte Axiome: Die Konstanten sind paarweise verschieden: Mon Tue, Mon Wed, Mon Thu, Mon Fri,... Induktionsregel: Γ Mon w Mon w... Γ Sun w Sun w Γ Beweis durch Fallunterscheidung nach dem Tag Verallgemeinerung: Aufzählungstypen 121

34 Data Specification (Beispiel 2) Beispiel 2: Paare Pair = data specification using Elem1, Elem2; pair = mkpair (..1 : elem1;..2 : elem2 ) variables p : pair; end data specification Generierte Axiome: mkpair(a, b).1 = a; mkpair(a, b).2 = b Induktionsregel: Γ mkpair(a,b) p mkpair(a,b) p Γ Expandiert Variable p zu mkpair(a, b) Verallgemeinerung: Tupel 122