Grundlagen der Informatik I “Programmierung”

einen Rechner überprüft werden kann. 11 Beweisen ist derzeit jedoch noch sehr kostspielig, da es – wie für
die Erzeugung von Implementierungen – keine allgemeingültigen Verfahren gibt, mit denen Beweise durchgeführt
werden können (dies ist schon ist aus theoretischen Gründen grundsätzlich unmöglich). Auch mangelt
es an Werkzeugen, die eine präzise Beweisführung angemessen unterstützen. Bisher erfordert es immer noch
eine Menge Training und einen hohen intellektuellen Aufwand, der für manche Produkte einfach zu teuer
ist. Trotzdem sollte man immer wieder versuchen, wenigstens die sicherheitsrelevanten Teile eines Systems zu
beweisen (z.B. daß der Zugang zum Password nur in der geplanten Form möglich ist).
Neben der Korrektheitsgarantie gibt es aber auch noch einen anderen Grund, Programme zu beweisen. Es
ist ein Spiel von hohem intellektuellen Reiz, das zudem auch die “Ästhetik” von Algorithmen begreifbar
macht. Bei guten Programmen fällt es leicht, einen Korrektheitsbeweis zu führen: die wesentlichen Ideen sind
leicht zu erkennen und die Struktur ist durchschaubar. Das Führen des Beweises birgt den Schlüssel zu einem
Verständnis, das weit über das “es funktioniert” hinausgeht. Wer selbst Programme beweist, beginnt die
Methodik zu erfassen, die bei der Implementierung implizit im Raume stand, und wird verstehen, in welchem
Rahmen sich diese Methodik auf die Lösung anderer Probleme übertragen lassen. 12 Gewöhnt man sich an,
bei der Implementierung gleichzeitig auch schon an einen möglichen Korrektheitsbeweis zu denken, so wird
dies die Qualität des erstellten Programms erheblich steigern. Es empfiehlt sich fast, einen Beweis simultan
zu der Implementierung zu erstellen. Auf Methoden einer derartigen Form der Programmerstellung werden
wir im letzten Abschnitt dieses Kapitels ein wenig eingehen.
Wie bereits erwähnt, gibt es keine allgemeine Methodik des Beweisens. Wir können daher in diesem Skript
nicht genau beschreiben, wie man Beweise führen kann, sondern nur einige vage Leitlinien angeben, Beweise
an Beispielen demonstrieren, und versuchen, Sie dabei nicht in einer Flut von Formeln ersticken zu lassen,
was wegen der Komplexität solcher Beweise leider leicht geschieht. Wichtig ist daher, daß Sie selber Beweise
entwickeln und dies an kleinen und mittleren Beispielen trainieren. Erst hierdurch kommt die oben erwähnte
Ästhetik von Programmen wirklich zutage. Als weitere Anregung sind die Bücher von Dijkstra “A Discipline
of Programming” [Dijkstra, 1976] und Gries “The Science of Programming” [Gries, 1981] sehr zu empfehlen.
4.2.1 Korrektheit von Routinen und Klassen
Zum Beweis der Korrektheit einer Routine gehen wir aus von dem vereinbarten Kontrakt, also der Vorbedingung
pre, die zu Beginn des Anweisungsteils zu finden ist, und der Nachbedingung post, die am Ende
Gültigkeit haben soll. Um nun nachzuweisen, daß für jede akzeptable Eingabe beim Verlassen der Routine
die Nachbedingung gilt, versuchen wir, Aussagen darüber zu treffen, welcher Zustand nach jeder einzelnen
Anweisung erreicht ist, und dies schrittweise zu beweisen. Diese schreiben wir “zwischen” die einzelnen Anweisungen.
Die Implementierung wird also ergänzt um logische Bestandteile, die nicht zur Programmiersprache
Eiffel gehören. 13
11 Die Realität ist leider noch nicht soweit: Es fehlt noch an der Qualifikation der Systementwickler, Beweise mit akzeptablen
Aufwand durchzuführen, an praktikablen Programmiersprachen, für die ein Beweiskalkül existiert, und schließlich an akzeptierten
Beweisprüfern. Trotzdem ist das Ziel des Programmbeweisens aus gesellschaftlichen und Umwelt-Gründen notwendig.
Leider gibt ein Programmbeweis nur die Aussage, daß das Programm auf einer fiktiven mathematischen Maschine (der Semantikdefinition
der Programmiersprache) korrekt läuft, aber nicht, daß sich das übersetzte Programm im Rahmen eines Betriebssystem
auf einer realen Hardware sich korrekt verhält. Daher sind neben der mathematischen Methode des Programmbeweisens
auch die Stichprobenverfahren der statistischen Qualitätsprüfung notwendig. Diese werden Tests genannt.
Ein Beweis ohne systematisches Testen gibt keine hohe Sicherheit. Systematisches Testen allein gibt nur eine schwache Wahrscheinlichkeitsaussage
über die Zuverlässigkeit. Testen ist jedoch für die anderen Qualitätsmerkmale der Angemessenheit des
Produkts, wie Effizienz, Benutzerfreundlichkeit usw. unbedingt erforderlich.
12 Aus dem Versuch, Korrektheitsbeweise zu systematisieren, haben sich sogar erste Systeme ergeben, die einfache Programme
automatisch aus ihren Vor- und Nachbedingungen synthetisieren können. Ohne eine Analyse von Programmen in Form eines
Korrektheitsbeweises kann man eine Antwort auf die Frage “wie implementiere ich zuverlässige Programme” wohl kaum finden.
13 Da der Beweis jedoch eine Aussage über das Programm ist, die nur für die Überprüfung, nicht aber für den Ablauf des
Programms relevant ist, gehören diese Bestandteile nicht zum eigentlichen Programm und könnten, wenn man sie unbedingt in
den Programmtext integrieren möchte, bestenfalls als Kommentare aufgenommen werden.