Formale Spezifikation und Induktion

Formale Spezifikation und
Induktion
91
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
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
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
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 3 + 4 speziell für die natürlichen Zahlen
95
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
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
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:
ϕ0n ∧ (∀ n. ϕ → ϕnn +1 ) → ∀ 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
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 6= 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
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
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
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 = {f1 , . . . , fn } ⊆ OP ,
• die Konstruktoren fi haben die Ergebnissorte s
(Konstanten sind als Konstruktoren erlaubt)
• für wenigstens ein fi 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 Ts ((S, C), X \ Xs ).
102
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 ∈ As gibt es ein v und t ∈ Ts ((S, C), X \ Xs ) 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
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
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
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 6= n +1;
m 6= n → m +1 6= n +1;
end specification
ist konsistent und mononorph
106
Spez. der natürlichen Zahlen mit Add. und Mult.
specification
sorts nat;
constants 0 : nat;
functions
. +1 : nat
→
. + . : nat × nat →
. ∗ . : nat × nat →
induction nat generated by 0, +1;
variables m, n : nat;
axioms
0 6= n +1;
m 6= n → m +1 6= 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
nat;
nat;
nat;
Minimale Spez. der Listen in KIV
specification
sorts elem; list;
constants [] : list;
functions
. + . : elem × list
induction list generated by [], +;
variables a, b : elem;
x, y : list;
axioms
[] 6= a + x;
a 6= b ∨ x 6= y → a + x 6= b + y;
end specification
→
list;
ist konsistent und mononorph,wenn die Trägermenge
für die Elemente vorgegeben ist (“monomorph modulo Parameter”)
108
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)
Induktionsregel:
ϕ = ∀ y.
V
Γ→
W
ϕ(c) ∧ (∀ x. ϕ(x) → ϕ(f (x))) → ∀ x. ϕ(x)
∆,
ϕ(x) ⊢ ϕ(f (x))
Γ⊢∆
y = f ree(Γ → ∆) \ {x}
Ableitung
Wenn man aus der Spezifikation SP durch Anwendung von
Sequenzenkalkül + Induktions-Regel die Formel ϕ ableiten kann, dann
schreibt man SP ⊢IN D ϕ.
109
Kalkül mit struktureller Induktion:
Korrektheit und Unvollständigkeit
Satz (Korrektheit)
Es gilt SP ⊢IN D ϕ
⇒
SP |= ϕ
Satz (Unvollständigkeit)
Es gibt Spezifikationen und Theoreme mit SP |= ϕ, die aber mit Induktion
nicht beweisbar sind (SP 6⊢IN D ϕ).
110
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 ′ ⊢IN D ϕ 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
Strukturierte Spezifikation:
Freie Datentypen
112
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
Freie und nichtfreie Datentypen
nat
nat
integer
set
set
stack
bintree
graph
???? by
list
???? by
???? by
???? by
???? by
???? by
???? by
???? by
???? by
114
Freie und nichtfreie Datentypen
Manche Datentypen sind frei (erzeugt): Zwei verschiedene
Konstruktorterme repräsentieren auch immer zwei verschiedene Elemente.
Beobachtung:
nat
nat
integer
set
set
stack
bintree
graph
0, +1
0, 1, +
0, +1, −1
∅, ins
∅, {.}, ∪
empty, push
mkleaf, mkbranch
∅, +node, +edge
list
[], +
114
Freie und nichtfreie Datentypen
Manche Datentypen sind frei (erzeugt): Zwei verschiedene
Konstruktorterme repräsentieren auch immer zwei verschiedene Elemente.
Beobachtung:
nat
nat
integer
set
set
stack
bintree
graph
list
generated by
0, +1
0, 1, +
0, +1, −1
∅, ins
∅, {.}, ∪
empty, push
mkleaf, mkbranch
∅, +node, +edge
freely generated by
[], +
freely generated by
generated by
generated by
generated by
generated by
freely generated by
freely generated by
114
0+0=0
0 +1 −1 = 0
ins(a,ins(a,∅)) = ins(a,∅)
{a} ∪ {a} = {a}
∅ +node n +node n
= ∅ +node n
Axiome für freie Datentypen
Beispiel: Konstante c, einstellige Funktion f , zweistellige Funktion g
• Verschiedenheit der Konstruktoren c, f und g :
c 6= f (x), f (x) 6= g(y, z), c 6= 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
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 \ Xs ) 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
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
end specification
by 0, +1;
⇒ Neu: Axiome jetzt generiert.
117
Listen als freier Datentyp
Beispiel: Listen als freier Datentyp
List2 =
specification
sorts list, elem;
functions
:
→ list;
: elem × list → list;
variables a, b: elem; l, l1 , l2 : list;
induction list freely generated by [], +;
[]
.+.
end specification
118
Generierte Axiome für Listen
Generierte Axiome
Spezifikation generiert:
[] 6= a + l,
a + l1 = b + l2 ↔ a = b ∧ l1 = l2
Induktionsregel für die Sorte list
∀ y.
V
Γ→
W
a+l
⊢
∆
∆, Γa+l
l
l
Γ⊢∆
y = f ree(Γ ⊢ ∆) \ {l}
119
[]
[]
Γl ⊢ ∆l
Datentyp-Definion (Motivation)
Häufige Situation:
• Freie Erzeugbarkeit mit Konstruktoren c
• Selektoren, die aus c(x1 , . . . xn ) die xi 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
Data Specification (Beispiel 1)
Beispiel 1: Wochentage
Weekday2 =
data specification
weekday = Mon | Tue | Wed | Thu | Fri | Sat | Sun;
variables w : weekday;
end data specification
Die Konstanten sind paarweise verschieden:
Mon 6= Tue, Mon 6= Wed, Mon 6= Thu, Mon 6= Fri, . . .
Generierte Axiome:
Induktionsregel:
Mon
ΓMon
⊢
∆
w
w
Sun
. . . ΓSun
⊢
∆
w
w
Γ⊢∆
⇒ Beweis durch Fallunterscheidung nach dem Tag
Verallgemeinerung:
Aufzählungstypen
121
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
⇒ Expandiert Variable p zu mkpair(a, b)
Verallgemeinerung:
mkpair(a,b)
⊢ ∆p
Γ⊢∆
Tupel
122