Simplifier: Datenstrukturabhangige Regeln
• Simplifierregeln sind Axiome oder Theoreme (Sequenzen),die einen entsprechenden Verwendungseintrag haben
• Die syntaktische Form bestimmt den Effekt
• Es gibt mehrere Klassen:• Simplifierregeln• Forward-Regeln
• Alle Regeln konnen lokal oder global sein
Zentral fur das Verstandnis von KIV:Welche Simplifierregel hat welchen Effekt?
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 70 / 290
Simplifier: Lokale und globale Regeln
2 Klassen von Simplifierregeln
• Lokale Simplifierregeln: Werden in Beweisen uber der Spezifikation,in der sie definiert sind, benutzt.
• Globale Simplifierregeln: Werden in Beweisen in Spezifikationen, dieuber der, in der sie definiert sind, benutzt.
Pragmatik
• Lokal werden Axiome als Simplifierregeln verwendet
• Global werden Theoreme verwendet, die “gute” Simplifierregeln sind
Analog fur Forward-Regeln
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 71 / 290
Simplifier: Eingabe von Simplifierregeln
Theoreme werden als Simplifierregeln eingetragen, wahlweise durch:
• Am Ende der Sequenz in der specification/sequents-Datei:used for: s, ls;
used for: f, lf;
• Auf Spezifikationsebene im Menu:Add (Local) Simplifierrules
Add (Local) Forwardrules
• Auf Spezifikationsebene: Durch Rechtsklick auf das Theoremund Anklicken der Checkbox
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 72 / 290
Simplifier: Typen von Simplifierregeln
Simplifierregeln (mit Eintrag s und/oder ls) gehoren zu einer der Klassen
• Termersetzungsregel = Rewriteregel:
Generelle Form: Γ ` ϕ → (σ = τ)Effekt: (Instanzen von) σ durch τ ersetzen
• Formelersetzungsregel = Aquivalenzregel
Generelle Form: Γ ` ϕ → (ψ ↔ χ)Effekt: (Instanzen von) ψ durch χ ersetzen
• Assoziativitat und Kommutativitat:
Generelle Form: (a + b) + c = a + (b + c) und a + b = b + aEffekt: Alle anderen Regeln modulo Ass. und Komm. anwenden
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 73 / 290
Simplifier: Pragmatik von Bedingungen
Rewrite- und Aquivalenzregeln haben die generelle Form
Γ ` ϕ → σ = τ und Γ ` ϕ → (ψ ↔ χ)
• Vorbedingungen Γ und ϕ:Als Formel dieselbe Bedeutung, aber unterschiedlich behandelt.
• ϕ = ϕ1 ∧ . . . ∧ ϕn muss Konjunktion von Literalen sein
• Literal = evtl. negierte atomare Formel
• Atomare Formel = Anwendung von Gleicheit odernicht vordefiniertem Pradikat (ungleich ∧, ∨, . . . ) auf Terme
• (Instanzen von) ϕ1, . . . , ϕn werden in Sequenz gesucht:Nichtnegierte Formeln im Antezedent, negierte im Sukzedent
• Γ wird versucht durch rekursiven Simplifieraufruf zu beweisen
• Γ darf beliebige Formeln enthalten
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 74 / 290
Simplifier: Pragmatik von Bedingungen
Wann sollte man Vorbedingungen in Γ stecken, wann in ϕ1, . . . ,ϕn?
• Vorbedingungen vor dem Sequenzenhaken in Γ sollten nur danndefiniert werden, wenn sie in sinnvollen Sequenzen immer erfullt sind.
• Typische sinnvolle Vorbedingungen sind Definiertheitsbedingungen:
• m −1 (Vorganger von m) ist nur fur m 6= 0 definiert• m − n ist nur fur n ≤ m definiert• .rest und .last sind nur fur nichtleere Listen definiert• Arrays: i < #ar sollte fur Zugriff a[i ] immer wahr sein
• Wenn man die Pragmatik nicht befolgt:Viele nutzlose Simplifieraufrufe (wird schnell sehr langsam)
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 75 / 290
Simplifier: Beispiele zu Vorbedingungen
• n 6= 0 ` (m < n −1 ↔ m +1 < n)Vorbedingung ok im Antezedent, da 0 −1 nicht sinnvoll ist
• ` m < n → (n < m + 2 ↔ m + 1 = n)Nicht im Antezedent, sonst, sobald Instanzen von n < m + 2vorkommen: Viele unnotige Beweisversuche fur m < n
• m ≤ n ` (n − m) + m = m
Beweist z. B. die Sequenz f(x) > 5 ` (f(x) − 3) + 3 = f(x)(da der Simplifier f(x) > 5 ` 3 ≤ f(x) beweisen kann)
` m ≤ n → (n − m) + m = m beweist die Sequenz nicht,da 3 ≤ f(x) nicht in der Sequenz vorkommt
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 76 / 290
Simplifier: Rewrite-Regeln
Γ ` ϕ → σ = τ
ersetzt (Instanzen von) σ durch τ , wenn Vorbedingungen ok
Einschrankungen:
• free(ϕ) ∪ free(σ) muß alle freien Variablen abdecken
• σ und τ mussen Terme sein, σ darf keine Variable sein
Beispiele:
• (m + n) − n = m
• i > 0 → sqrt(i ˆ 2) = i (i integer; warum nicht im Antezedent?)
• (s1 ∪ s2) \ s2 = s1 \ s2 (Mengen)
• x 6= [] → (x + y).first = x .first (Listen, + = append, warum nichtAnt.?)
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 77 / 290
Simplifier: Aquivalenzregeln
Γ ` ϕ → (ψ ↔ χ)
ersetzt (Instanzen von) ψ durch χ, wenn Vorbedingungen ok
Einschrankungen:
• free(ϕ) ∪ free(ψ) muß alle freien Variablen abdecken
• ψ muss Literal sein, χ ist beliebige Formel
• Vereinfachung: Falls ψ keine Gleichung, statt (ψ ↔ true) nur ψ
• Vereinfachung: Statt (ψ ↔ false) nur ¬ ψ
Beispiele:
• sorted(a + []), # x = 0 ↔ x = [] (Listen)
• m + n < m + n0 ↔ n < n0
• n 6= 0 ` (m < n −1 ↔ m +1 < n)
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 78 / 290
Simplifier: Kommutativitat und Assoziativitat
• Kommutativitat: m + n = n + m
• Assoziativitat: (m + n) + k = n + (m + k)
• Kurz: C(+), A(+), AC(+) fur komm., ass., komm. und ass.
• Werden nicht direkt verwendet (Warum?)
• Ob eine Simplifierregel passt, wird “modulo” dieser Regeln gepruft
• ` a + b ∗ c = c ∗ b + a wird mit C(+,*) sofort (per Reflexivitat)bewiesen
• ` b ∗ c ≤ (c ∗ a) ∗ b wird fur AC(∗) mit der Regel m ≤ m ∗ nbewiesen
• Viele Operatoren sind AC: +, ∗, min, ggt, ∪• Nur assoziativ ist z. B. append auf Listen, ∗ auf Matrizen
• Nur kommutativ ist sehr selten
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 79 / 290
Simplifier: Forwardregeln
• Manchmal will man neue Information zu einer Sequenz dazunehmen
• Fast nur fur Transitivitat von Ordnungs- und Aquivalenzrelationen:• m < n ∧ n < n0 → m < n0• isperm(x , y) ∧ isperm(y , z) → isperm(x , z)
• Dazu gibt es Forward-Regeln der Form:
Γ ` ϕ1 ∧ . . . ∧ ϕn → ϕ
• Vorbedingungen werden wie bei Simplifierregeln behandelt
• ϕ wird genau einmal zur Sequenz addiert
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 80 / 290
Simplifier: Hinweise zu Forwardregeln
• Transitivitat ist unkritisch (sollte man machen)
• Haufig etliche Varianten notwendig:• m < n ∧ n ≤ n0 → m < n0• m < n ∧ ¬ n0 < n → m < n0• m ≤ n + 1 ∧ n < n0 → m ≤ n0
• Ein Lemma sollte nie Forward- und Simplifierregel sein. Warum?
• Forward-Regeln geben sehr leicht Endlosschleifen im Simplifier! ⇒Sehr vorsichtig, nur mit gutem Grund verwenden
• Einfaches Bsp. fur Endlosschleife: ` m < n → m < n + 1
• Bsp.: 0 < n ` (∗ n) ≤ m → m 6= 0
• Warum nur (∗ n) und nicht einfach n? Warum 0 < n im Antezedent?
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 81 / 290
KIV-Kalkul: Elimination fur Selektoren
• Listen haben (Postfix-)Selektoren• .first (erstes Element)• .rest (Rest der Liste)
• Trick: Selektoren loswerden mit Hilfe von insert elim lemma
• Benotigt wird Lemma` x 6= [] → (a = x .first ∧ y = x .rest ↔ x = a + y)
• Eliminationsregel sucht einen Term t.first oder t.rest
• Wenn t 6= [] gilt, wird t = a + y ersetzt (neue Variablen a, y)
• Damit wird aus t.first bzw. t.rest jetzt a bzw. y
t = a + y ,Γ(a, y , a + y) ` ∆(a, y , a + y)
t 6= [],Γ(t.first, t.rest, t) ` ∆(t.first, t.rest, t)
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 82 / 290
KIV-Kalkul: Elimination fur andere Funktionen
• Manchmal geht Elimination auch fur andere “unbeliebte” Funktionen
• Beliebte Beispiele: Minus und Division
• Lemma fur Minus: n ≤ m ` n0 = m − n ↔ m = n0 + n
• Vorteil: Man kann auf Simplifierregeln fur − verzichten!
• Nachteil: Neue Variable n0 wird eingefuhrt (manchmal unintuitiv)
Γ(n0 + n, n, n0) ` ∆(n0 + n, n, n0)
n ≤ m, Γ(m, n,m − n) ` ∆(m, n,m − n)
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 83 / 290
Automatisierung in KIV: Heuristiken
• Flexible Automatisierung ist zentral, um bei grossen Fallstudien nichtimmer wieder die gleichen Beweisschritte wiederholen zu mussen
• Deshalb in KIV: Automatisierung durch zuschaltbare Heuristiken
• Speziell: Der Simplifier ist eine Heuristik⇒ Sollte man (fast) immer benutzen
• Fur jedes Beweisziel werden alle Heuristiken der Reihen nachausprobiert
• Gewahlte Heuristiken jederzeit anderbar
Sehr wichtig fur das Verstandnis von KIV:Welche Heuristik hat welchen Effekt?
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 84 / 290
Wichtige Heuristiken fur PL in KIV (1)
• Simplifier• Wendet die Simplifier-Regel an
• pl case distinction• Wendet Regel case distinction an• Fur einfache bis mittelschwere Beweise• Gefahr, unnotige Fallunterscheidungen zu machen
• if-then-else-split• if-then-else-Operator:
(ϕ ⊃ σ; τ) bezeichnet σ, falls ϕ wahr ist, sonst τ• Wendet cut Regel mit ϕ an• Haufig einsetzbar, um sinnvolle Fallunterscheidungen zu erzwingen• Beispiel: Fallunterscheidung nach Anwendung von Rewrite-Regel
abs(i) = (i ≥ 0 ⊃ i ; − i)
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 85 / 290
Wichtige Heuristiken fur PL in KIV (2)
• Quantifier closing• Sucht Instanzen, mit denen eine Pramisse direkt geschlossen werden
kann• Immer verwenden• Einziges Problem: Bei sehr vielen Quantoren braucht die Heuristik viel
unnotige Zeit• Deshalb Spezifikationsmethodik:
Pradikat (+ Simplifierregeln) definieren statt grosse Quantorenformelnzu verwenden
• Quantifier:• Sucht
”sinnvolle“ Instanzen fur Quantoren
• Kann Endlosschleifen verursachen!• Nur bei einfachen Quantorenbeweisen einsetzbar
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 86 / 290
Wichtige Heuristiken fur PL in KIV (3)
• structural induction:• Macht strukturelle Induktion uber “sinnvolle” Terme• Idee fur “sinnvoll”: Variablen an rekursiven Positionen:
n ist sinnvoll in m + n, da + rekursiv uber das zweite Argumentdefiniert: m + 0 = m, m + (n +1) = (m + n) +1
• Klappt meistens, aber nicht immer• Heuristik wendet ausserdem einmal die Induktionshypothese an
• module specific:• Eigentlich eine Meta-Heuristik: Erlaubt heuristische Anwendung von
Regeln durch Patterns• Pattern: Gibt Formeln (oder Schemas fur Formeln) an, die in der
Sequenz vorkommen mussen bzw. nicht vorkommen durfen + Regeldie angewandt werden soll
• Alle Patterns stehen in der Datei module-specific
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 87 / 290
Wichtige Heuristiken fur PL in KIV (4)
elimination:
• Heuristik gesteuert durch Eliminationsregeln(analog zu: Simplifier durch Simplifierregeln)
• KIV-Eingabe analog: used for: e; etc.
• Beispiel: n ≤ m ` n0 = m − n ↔ m = n0 + n
• Vorbedingung im Antezedent: n ≤ m muss beweisbar sein(analog zu Simplifierregeln)
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 88 / 290
KIV-Kalkul: Heuristiksatze
• In KIV: 3 vordefinierte Heuristiksatze:• PL Heuristics: Minimale Menge sinnvoller Heuristiken• PL Heuristics + Case Splitting: Keine Induktion, FU automatisch• PL Heuristics + Struct. Ind.:
Versucht, Ziel induktiv zu beweisen und Fallunterscheidungen (FU)automatisch zu machen
• Fur grossere Projekte definiert man haufig seinen eigenenStandardsatz⇒ Datei default-heuristics
• Weitere Heuristiken fur Programme (DL). Dort noch wichtiger, daProgramme mehr Struktur haben (spater)
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 89 / 290
Formale Spezifikation und Induktion
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 90 / 290
Was ist ein SW-System mathematisch?
1. Sicht: Operational
Ein SW-System ist ein Automat
• mit Zustand,
• Zustandsubergangen und
• mit Ablaufen.
2. Sicht: Algebraisch
Ein SW-System ist eine Algebra = Datenstruktur, d. h. ein System vonDaten und Operationen.
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 91 / 290
Was ist spezieller?
Einen Automaten kann man als spezielle Algebra auffassen:
• Zustand = Element einer Datenstruktur ⇒ Algebra!
• Sorten = State, Input, Output mit Operationen• Anfangszustande:
isinitial: State → Bool• Zustandsubergangsfunktion (oder auch Relation):
exec: Input × State → (State × Output → Bool)
• Z. B. Zustand eines Programms:Programm + Programmzahler + Speicherbelegung
• Theoretisch: Algebraische Sicht genugt
• Praktisch: Automatensicht hat viele Spezialeigenschaften(u. a. ist eine Idee von
”Zeit“ damit verbunden).
Deshalb Codierung oft nicht die beste Idee.
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 92 / 290
SW-Beschreibungsformalismen
SW-System ist Datentyp:
• Modellorientierte Spezifikation (Z, VDM):Alle Datentypen sind mit Mengenlehre gebildet (Tupel und Mengenz. B. fur UML-Klassendiagramme)
• Algebraische Spezifikation
SW-System ist Menge von Ablaufen:
• Algorithmische Spezifikation, z. B. Programmiersprachen
• Programme uber algebraischen/modellorientierten Datentypen
• Automaten, Harel/UML Statecharts, Abstract State Machines(ASMs)
Eignung hangt von den Zielen ab (Was will ich beschreiben? Wasbeweisen?)
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 93 / 290
Spezifikation
Ziel: Ein bestimmter Datentyp (Algebra) soll spezifiziert werden.
Fragen:
1 Was fur Operationen brauche ich?
2 Welche Axiome brauche ich?
3 Welche Datentypen kann ich uberhaupt spezifizieren?
4 Kann ich alle wahren Aussagen uber dem Datentyp auch beweisen?
Zunachst: Fragen 3 + 4 speziell fur die naturlichen Zahlen
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 94 / 290
Naturliche 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 ϕ fur alle nwahr
Begrundung: M := {n : ϕ(n)} ist mindestens so groß wie IN.
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 95 / 290
Naturliche Zahlen: Mit PL nicht spezifizierbar!
Satz (Charakterisierung der naturlichen Zahlen)Die Peano-Axiome charakterisieren ein Modell (eben die naturlichenZahlen) bis auf Isomorphie (= Umbenennung).
Beachte dabei: Peano-Axiom 5 ist kein pradikatenlogisches Axiom!
Aber:
Satz von SkolemEs gibt keine Menge Ax-Nat von pradikatenlogischen Formeln, die alseinziges Modell (modulo Umbenennung) nur die naturlichen Zahlen hat.Beweisbar mit Vollstandigkeitssatz
Intuition: Pradikatenlogische Axiome konnen nicht ausdrucken, dass esneben den
”echten“ naturlichen Zahlen keine weiteren Zahlen gibt.
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 96 / 290
Naturliche Zahlen: Ein schwacheres Ziel
Wir wissen schon: Jede Axiomenmenge hat auch andereModelle als IN mit zusatzlichen Elementen.
Wir versuchen es schwacher: Suche Axiomenmenge, mit der alle uber INwahren Aussagen bewiesen werden konnen (dass sie auch uber anderenModellen gelten, konnte 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 keinAxiom”.Sonst Triviallosung: Nehme als Axiome samtliche wahren Aussagen.
Zum Beispiel: Nehme Induktionsschema zu den Axiomen dazu:ϕ0n ∧ (∀ n. ϕ → ϕn +1
n ) → ∀ n. ϕ; (: fur jedes ϕ ∈ For(Σ,X) :)
Die Formel ϕ(n) mit freier Variable n beschreibt die Menge{n : IN |= ϕ(n)}.Das Induktionsschema fur ϕ entspricht Peano-Axiom 5 fur diese Menge
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 97 / 290
Naturliche Zahlen: Unvollstandigkeit
Problem: Alle Formeln (abzahlbar viele) beschreiben nicht alle Mengen(uberabzahlbar viele)!
Es gilt leider:
Godelscher UnvollstandigkeitssatzEs gibt keine entscheidbare Menge von Formeln uber (0, succ, +, ∗), diedie ersten 4 Peano-Axiome und n 6= 0 → ∃ n. n = succ(m) enthalt oderimpliziert, mit der sich alle in IN wahren Aussagen ableiten lassen(insbesondere ist das Induktionsschema auch unvollstandig).
Der Trick zum Beweis ist das Lugnerparadoxon (”ich luge 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“ ausdruckbar.
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 98 / 290
Naturliche Zahlen: Unvollstandigkeit
Intuition:
• Leider findet man auch keine”gute“ Axiomenmenge, mit der die
wahren Aussagen herleitbar sind
• Alle wahren Aussagen konnte man als Axiome trivialerweise nehmen.
• Die Menge der wahren Aussagen ist also nicht entscheidbar.
• Wahre Aussagen fur die naturlichen Zahlen zu beweisen, ist kreativ.
• Verursachte ziemlich viel Wirbel in den 30er Jahren:Die Idee, Mathematik auf ganz einfachen Grundlagen aufzubauen(Hilbert’sches Programm), war gescheitert
• Heute: Komplizierte Mengenlehre (Zermelo-Frankel, Godel-Bernays)als Grundlage fur Mathematik.
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 99 / 290
Problem: Pradikatenlogik reicht nicht
Problem: Pradikatenlogik kann nicht ausdrucken, dass es ausser denZahlen 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 fur 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 durfen Elementvariablen enthalten
• Alle (endlichen) Graphen bekommt man aus dem leeren ∅, durchAddieren von Knoten (addnode) und Kanten (addedge)
• Alle Arrays bekommt man durch:• mkarray(n) (erzeugt Array der Grosse n)• put(a, i , d) (schreibt an Position i das Datum d)
Gemeinsame Idee: Alle Datenelemente durch endlich-malige Anwendungvon Konstruktoren bildbar
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 100 / 290
Generiertheitsklauseln: Syntax
Deshalb Idee: Wir definieren ein “Spezialaxiom”, genanntGeneriertheitsklausel, das aussagt: Die Daten eines Datentyps sind genaudie mit bestimmten Konstruktoren gebildeten Terme.
Syntaxs generated by C ist Termerzeugtheitsklausel (∈ Gen(Σ)) ⇔
• s ∈ S , C = {f1, . . . , fn} ⊆ OP,
• die Konstruktoren fi haben die Ergebnissorte s(Konstanten sind als Konstruktoren erlaubt)
• fur wenigstens ein fi sind alle Argumentsorten ungleich s(sonst gibt es keine Konstruktorterme!)
Ein Konstruktorterm t hat die Sorte s, ist mit Konstruktoren aus Cgebildet und enthalt nur Variablen anderer Sorten, ist also ausTs((S,C),X \ Xs).
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 101 / 290
Generiertheitsklauseln: Semantik
Idee: Jedes Element der generierten Sorte ist der Wert einesKonstruktorterms, wenn man die (Parameter)-Variablen geeignet belegt.
Semantik
A |= s generated by C :⇔fur 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].
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 102 / 290
Basisspezifikation
BasisspezifikationEine Spezifikation SP = (Σ, Ax , Gen) ist ein Tripel mit:
• Σ = (S , OP)
• Ax ⊆ For(Σ, X ) endlich
• Gen ⊆ Gen(Σ) endlich
ModellA ist Modell von SP (A |= SP, A ∈ Mod(SP))A |= SP :⇔ A ∈ Alg(Σ), A |= Gen und A |= Ax .
GultigkeitSP |= ϕ :⇔ fur alle A in Mod(SP): A |= ϕ
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 103 / 290
Konsistenz und Monomorphie
Definition Eine Spezifikation ist konsistent:⇔ Axiome nicht widerspruchlich⇔ Kein Beweis von false moglich⇔ 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 fur Datentypen wie naturliche Zahlen etc. so sein(die Axiome sollten ja nicht versehentlich auch reelle Zahlen erlauben).
⇒ Fur Systembeschreibungen oft nicht erforderlich bzw. wunschenswert.Man will ja gerade Details offenlassen.
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 104 / 290
Minimale Spez. der naturlichen Zahlen in KIV
specificationsorts nat;constants 0 : nat;functions . +1 : nat → nat;induction nat generated by 0, +1;variables m, n : nat;axioms0 6= n +1;m 6= n → m +1 6= n +1;
end specification
ist konsistent und mononorph
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 105 / 290
Spez. der naturlichen Zahlen mit Add. und Mult.
specificationsorts nat;constants 0 : nat;functions . +1 : nat → nat;
. + . : nat × nat → nat;
. ∗ . : nat × nat → nat;induction nat generated by 0, +1;variables m, n : nat;axioms0 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
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 106 / 290
Minimale Spez. der Listen in KIV
specificationsorts elem; list;constants [] : list;functions . + . : elem × list → 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
ist konsistent und mononorph, wenn die Tragermengefur die Elemente vorgegeben ist (“monomorph modulo Parameter”)
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 107 / 290
Kalkul mit struktureller Induktion
Strukturelle Induktion
Sorte s erzeugt von Konstruktoren c , f ⇒ Jedes Element derTragermenge 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}
AbleitungWenn man aus der Spezifikation SP durch Anwendung vonSequenzenkalkul + Induktions-Regel die Formel ϕ ableiten kann, dannschreibt man SP `IND ϕ.
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 108 / 290
Kalkul mit struktureller Induktion:Korrektheit und Unvollstandigkeit
Satz (Korrektheit)Es gilt SP `IND ϕ ⇒ SP |= ϕ
Satz (Unvollstandigkeit)Es gibt Spezifikationen und Theoreme mit SP |= ϕ, die aber mitInduktion nicht beweisbar sind (SP 6`IND ϕ).
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 109 / 290
Wie schlimm ist Unvollstandigkeit?
• Der Kalkul mit der Induktions-Regel ist”fast vollstandig“:
Wenn SP |= ϕ, dann gibt es eine Erweiterung SP ′ von SP um neuerekursiv definierte Hilfsfunktionen, so dass SP ′ `IND ϕ gilt.
• Praktisch gesehen: Mit den zusatzlichen Symbolen in SP ′ wird einepassend (verallgemeinerte) Induktionshypothese fur den Beweis vonϕ ausdruckbar.
• Beachte: Mit der Generiertheitsklausel ist die Induktionsregel auchauf Formeln mit den Hilfsfunktionen anwendbar (die Menge dermoglichen Ind. hypothesen wachst!)
• SP ′ ist je nach ϕ verschieden (kein uniformes SP ′).
• In jedem SP ′ gibt es neue Formeln ψ, die wahr aber nicht ableitbarsind.
• Kreativititat also fur Verallgemeinerung und passendeHilfsfunktionen.
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 110 / 290
Strukturierte Spezifikation:
Freie Datentypen
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 111 / 290
Wie spezifiziert man Datentypen?
Vorgehen:
• Schritt 1: Definiere benotigte 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 fur den gewunschten Datentyp stimmen(keine Inkonsistenz!), und sollten ihn moglichst eindeutig charakterisieren.
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 112 / 290
Freie und nichtfreie Datentypen
nat ???? bynat ???? byinteger???? byset ???? byset ???? bystack ???? bybintree???? bygraph ???? by
list ???? by
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 113 / 290
Freie und nichtfreie Datentypen
Beobachtung: Manche Datentypen sind frei (erzeugt): Zwei verschiedeneKonstruktorterme reprasentieren auch immer zwei verschiedene Elemente.
nat 0,+1nat 0, 1,+integer 0,+1,−1set ∅, insset ∅, {.}, ∪stack empty, pushbintree mkleaf, mkbranchgraph ∅, +node, +edge
list [], +
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 113 / 290
Freie und nichtfreie Datentypen
Beobachtung: Manche Datentypen sind frei (erzeugt): Zwei verschiedeneKonstruktorterme reprasentieren auch immer zwei verschiedene Elemente.
nat freely generated by 0,+1nat generated by 0, 1,+ 0 + 0 = 0integer generated by 0,+1,−1 0 +1−1 = 0set generated by ∅, ins ins(a,ins(a,∅)) = ins(a,∅)
set generated by ∅, {.}, ∪ {a} ∪ {a} = {a}stack freely generated by empty, pushbintree freely generated by mkleaf, mkbranchgraph generated by ∅, +node, +edge ∅ +node n +node n
= ∅ +node nlist freely generated by [], +
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 113 / 290
Axiome fur 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)
• Injektivitat 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.
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 114 / 290
Freie Erzeugtheitsklauseln
Freie Erzeugtheitsklauseln
A |= S ′ freely generated by C :⇔• A |= S ′ generated by C
• Fur 2 Konstruktorterme t, t ′ ∈ T s((S ,C ),X \ Xs) mit s ∈ S ′ gilt nurdann
[[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 Fallverschiedene Listen (egal wie die Belegungen v , v ′, v ′′ sind)
• [[a + []]]A,v = [[b + []]]A,v ′ gdw. wenn v(a) = v ′(b).
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 115 / 290
Naturliche Zahlen als freier Datentyp
Beispiel: Die naturlichen Zahlen
Nat3 =specificationsorts nat;constants 0 : nat;functions +1 : nat → nat;variables n : nat;induction nat freely generated by 0, +1;end specification
⇒ Neu: Axiome jetzt generiert.
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 116 / 290
Listen als freier Datentyp
Beispiel: Listen als freier Datentyp
List2 =specificationsorts list, elem;functions
[] : → list;. + . : elem × list → list;
variables a, b: elem; l, l1, l2: list;induction list freely generated by [], +;end specification
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 117 / 290
Generierte Axiome fur Listen
Generierte Axiome
Spezifikation generiert:[] 6= a + l ,a + l1 = b + l2 ↔ a = b ∧ l1 = l2
Induktionsregel fur die Sorte list
∀ y .∧
Γ→∨
∆,Γa+ll ` ∆a+l
l Γ[]l ` ∆
[]l
Γ ` ∆
y = free(Γ ` ∆) \ {l}
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 118 / 290
Datentyp-Definion (Motivation)
Haufige Situation:
• Freie Erzeugbarkeit mit Konstruktoren ci
• Selektoren, die aus ci (x1, . . . xn) die xj selektieren
• Testpradikate”ist mit Konstruktor cl gebildet“
• Ordnung:”ist Unterterm von“
• Großenfunktion:”Anzahl nichtkonstanter Konstruktoren“
⇒ Eigenes Syntaxkonstrukt data specification vermeidet unnotigeSchreibarbeit.
In KIV typischerweise nie freely generated, sondern gleich dataspecification
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 119 / 290
Data Specification (Beispiel 1)
Beispiel 1: Wochentage
Weekday2 =data specificationweekday = Mon | Tue | Wed | Thu | Fri | Sat | Sun;variables w : weekday;end data specification
Generierte Axiome: Die Konstanten sind paarweise verschieden:
Mon 6= Tue, Mon 6= Wed, Mon 6= Thu, Mon 6= Fri, . . .
Induktionsregel:ΓMonw ` ∆Mon
w . . . ΓSunw ` ∆Sun
w
Γ ` ∆
⇒ Beweis durch Fallunterscheidung nach dem Tag
Verallgemeinerung: Aufzahlungstypen
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 120 / 290
Data Specification (Beispiel 2)
Beispiel 2: Paare
Pair =data specificationusing 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
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 121 / 290
Data Specification (Beispiel 3)
Beispiel 3: naturliche Zahlen
Nat =data specificationnat = 0
| . +1 (. −1 : nat);variables n : nat → nat;order predicates . < . : nat × nat;end data specification
Generierte Axiome: n +1−1 = n; (: 0−1 ist unspezifiziert :)¬ n < n; m<n ∧ n<k → m<k ;¬ n < 0; m < n +1 ↔ (m = n ∨ m < n)
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 122 / 290
Data Specification (Beispiel 4)
Beispiel 4: Listen
List =data specificationusing Nat, Elem;list = . + . (. .first : elem; . .rest : list) with consp
| [] with nilp;variables l : list;(: ist Unterterm fur Listen = ist Endstuck :)order predicates . � . : list × list;size functions length : list → nat;end data specification
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 123 / 290
Selektoren als partielle Funktionen
Problem: Was tun, wenn ein Selektor auf den falschen Summandangewandt wird?
Hier: Was sind [] .first und [] .rest?
.first und .rest sollten fur [] gar nicht definiert sein ⇒ Partielle Funktionen
In KIV: []. first und [].rest sind unspezifiziert (i. e. kein Axiom)
Semantik: [].rest ist in jeder Algebra (Datenstruktur) irgendeine andereListe ⇒ Echte Implementierung muss irgendeine Liste zuruckgeben
Pragmatik: Formeln mit [].rest sollten nicht vorkommen.Wenn doch, muss die Sequenz ohne die Formeln beweisbar sein.
Bem.: Alternativen sind moglich aber komplizierter (u. a. Fehlerelemente,echte Partialitat, etc.)
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 124 / 290
Data Specification (Beispiel 3)
Neue Axiome fur List3:
nilp([]);¬ nilp(a + l);
¬ consp([]);consp(a + l);
(a + l).first = a; (: kein Axiom fur [] .first :)
(a + l).rest = l ; (: kein Axiom fur [] .rest :)
¬ l � [];l � (a + l1) ↔ l = l1 ∨ l � l1;
(: beweisbar, aber der Einfachheit halber generiert :)¬ l � l ; l1 � l2 ∧ l2 � l3 → l1 � l3;
length([]) = 0;length(a + l) = length(l) +1;
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 125 / 290
Data Specification allgemein
Definition (Datendefinition)
Eine Datendefinition D hat die Form (optionales in eckigen Klammern):
s = c1(sel1,1 : s1,1; . . . ; sel1,n1 : s1,n1) [with p1]| . . .| ck(selk,1 : sk,1; . . . ; selk,nk : sk,nk ) [with pk ];
[order predicate . � . : s × s;][size function sz : s → nat;]
Uberladen: sel i ,j = sel i ′,j ′ erlaubt, falls si ,j = si ′,j ′ ,ansonsten alle Operationen paarweise verschieden.
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 126 / 290
Eigenschaften von Data Specifications
Satz: Alle Data Specifications sind immer konsistent. Sie sind immer
monomorph bis auf unspezifizierte Selektoren und Parameter.
Intuition bei Listen ist also:
1 Wir haben exakt den Datentyp der Listen beschrieben.
2 Fur die Realisierung auf einem Rechner ist lediglich offen,
• was fur ein Elementtyp verwendet wird und• was fur eine Element bzw. Liste [].first und [].rest zuruckgeben.
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 127 / 290
Datentyp-Definitionen in Java
Implementierung von Datentyp-Definitionen in Java:
abstract class s {} /* Dies entspricht der Sorte s */
/* Subklasse fur Konstruktor c1 */
class c1 extends s {s11 sel11; /* ein Feld pro Selektor */
s12 sel12; ...
s1n1 : sel1n1;
/* Konstruktor */
public c1(s11 se1, s12 se2, ...) {sel11 = se1; sel12 = se2; ...}
}
/* Subklasse fur Konstruktor c2 */
class c2 extends s {...
}
7. Mai 2012 D. Haneberg: Formale Methoden im Software Engineering 128 / 290