edit
Proving Programs Correct
- Bis jetzt: Unit testing, um Korrektheit zu prüfen
- Kann nicht alle Bugs finden: Wie weiss man, welche Tests "gut genug" sind?
- Ziel: Programm wie eine mathematische Formel formell beweisen
- Scope dieser Vorlesung: Imperative single-thread Programme
- Ansatz in Dafny: "Desing-by-Contract", man definiert Post-conditions, die vom Compiler überprüft werden
Hoare Triples
-
-
ist Precondition, Programm / Command, ist Postcondition
- Correctness-Aussage: Wenn erfüllt ist, wird durch die Postcondition erfüllt
- Diese Aussage ist selbst ein "boolean" (Predicate): Kann wahr oder falsch sein
Inference Rules
Automatisierung
- Allgemeiner Fall ist unentscheidbar
- Einfache logiken können aber meist automatisch bewiesen werden
- Workflow: Aus Verification Conditions erstellen, die dann bewiesen werden (oder nicht)
Proof mit If und While
If
- Wieder von unten nach oben, aber Verzweigung beachten
- Vorbedingung über ganzes
if
: Entweder ist es true, dann hat man eine Vorbedingung, oder es ist falsch, dann die andere Vorbedingung
- Mit If-Bedingung P:

While
- Keine 100%-ige Lösung (Turing-Completeness - nicht entscheidbar)
- Loop-Invariant: Eigenschaft, die sowohl zu Beginn als auch zum Ende des Loops wahr sein muss (nicht veränderbar)
- Schwierigkeit: Loop Invariant finden
- Vorgehen
- Loop Invariant annehmen
- Vorbedingung des Loop-Bodies ist mit = Loop-Condition
- Mit das Hoar-Triple im
while
beweisen (mit und )
- Wenn dieser Beweis geht, ist die Invariante korrekt
- I als Vor- und Nachbedingung des Loops nehmen
- Nachbedingung erfüllt Loop-Condition nicht (AND verknüpfen):
- while-loop ist jetzt "subroutine", die bewiesen ist
- nachbedingung => Q beweisen
- Vorbedingungen vor der Schleife wie gewöhnlich nach oben beweisen
- Verification Conditions
- Loop Invariant für Prüfung vorgegeben!

Dafny
- Neben formaler Korrektheit wie hier besprochen wird auch Terminierung überprüft
- z.B., ob in while counter hinuntergezählt wird, dass die Schleife terminiert wird