Grundlagen der Informatik I “Programmierung”

4.2 Verifikation
Beim Entwurf haben wir Vor- und Nachbedingungen an Routinen sowie Klasseninvarianten eingeführt, um
“per Vertrag” die Verteilung der Aufgaben auf die einzelnen Module eines Softwaresystems klar zu regeln.
Nach dem Entwurf der Systemarchitektur und der Verteilung der Einzelaufgaben ist es nun möglich, jedes
Modul einzeln und unabhängig von den anderen zu implementieren. Statt einer globalen Sicht, die bisher
erforderlich war, ist es nun (endlich) möglich, lokal zu arbeiten, und auf konventionellere Programmierkonzepte
zurückzugreifen, zu denen seit vielen Jahren Erfahrungen vorliegen und weiter entwickelt werden.
Während dieser Implementierungsphase sind natürlich ganz andere Qualitäten gefragt als beim Entwurf, in
dem Erweiterbarkeit und Wiederverwendbarkeit die wichtigste Rolle spielten. Nun, da die Verträge erstellt
sind, geht es darum, daß sie auch eingehalten werden. Ansonsten wäre die Modularisierung wertlos und eine
Aufteilung der Verantwortung auf mehrere Softwareentwickler unmöglich, denn man könnte sich ja nicht
darauf verlassen, daß die benutzten Dienstleitungen anderer Module auch so funktionieren, wie es vereinbart
war. Zuverlässigkeit, also Korrektheit und Robustheit stehen bei der Implementierung von Klassen und ihren
einzelnen Routinen im Vordergrund. Die Frage, die sich ein verantwortungsbewußter Programmierer nun
stellen sollte, lautet: “Wie implementiere ich eine Routine, deren Zuverlässigkeit ich sicherstellen kann?”. Bei
der Beantwortung dieser Frage sind zwei Aspekte zu berücksichtigen.
Zum einen muß man natürlich wissen, welche Hilfsmittel überhaupt bei der Implementierung zur Verfügung
stehen, also aus welchen Programmkonstrukten und elementaren Ausdrücken man den Anweisungsteil einer
Routine aufbauen kann. Hier gibt es zwischen den meisten höheren Programmiersprachen nur geringfügige
Unterschiede. Fast alle bieten Konstrukte für die in Abschnitt 1.3.2 angedeuteten Strukturierungskonzepte
für Implementierungen an – also für eine Verfeinerung in eine Folge kleinerer Teilschritte, Fallunterscheidung,
Wiederholung, Prozeduralisierung und ggf. auch Rekursion. 10 Da diese konzeptionell nicht so schwer zu verstehen
sind und Probleme allenfalls bei der syntaktischen Beschreibungsform der Programmiersprache auftreten
können, kann man sich die für eine Implementierung nötigen Grundkenntnisse relativ leicht aneignen.
Zum zweiten aber – und das ist wesentlich schwieriger – muß man wissen, wie man diese Programmierkonstrukte
einsetzt, um ein zuverlässiges Programm zu erhalten. Dabei läßt sich die Frage, wie man denn
überhaupt eine lauffähige Routine erstellt, von der Frage nach der Korrektheit dieser Routine nicht trennen.
Denn wer ein Programm entwickelt, der wird auch eine Vorstellung davon haben, warum dieses Programm
denn so funktionieren soll, wie es vorgesehen ist. Wer also ein zuverlässiges Programm erstellen möchte, der
sollte prinzipiell auch in der Lage sein, die Korrektheit zu garantieren. Warum reichen hierfür die logischen
Ausdrücke in Invarianten und Vor- und Nachbedingungen von Routinen nicht aus?
Invarianten, Vorbedingungen und Nachbedingungen werden nur bei der Programmdurchführung kontrolliert,
wenn die Durchführung an dieser Prüfstelle vorbeikommt. Ist die Prüfung negativ, so bedeutet dies, daß
die Vorstellungen des Programmierers vom Programmablauf und der tatsächliche Programmablauf nicht übereinstimmen:
ein Fehler wurde entdeckt. Ist aber die Prüfung in allen durchgeführten Fällen positiv, dann weiß
man nur, daß in diesen speziellen Fällen kein Fehler gefunden wurde. Das sagt aber überhaupt nichts darüber
aus, wie sich das Programm in allen anderen Fällen verhält, die in seinem späteren Einsatz vorkommen mögen.
Man kann die Korrektheit eines Programms nicht mit Programmabläufen prüfen.
Deshalb ist es nötig, die Korrektheit von Programmen völlig unabhängig von konkreten Eingabewerten beweisen
(verifizieren) zu können, und dies in einer mathematisch präzisen Form zu tun. Prinzipiell ist es sogar
wünschenswert, den Beweis in einem logischen Kalkül – also einer Erweiterung des in Abbildung 2.14 auf Seite
49 vorgestellten Ableitungskalküls für die Prädikatenlogik – auszuführen, da dieser Beweis seinerseits durch
10 Differenzen liegen nur in der syntaktischen Beschreibungsform dieser Konstrukte, dem Angebot mehrerer ähnlicher Konstrukte
(z.B. while und for-Schleife in Pascal), und dem Umfang der vordefinierten Ausdrücke, die man nicht mehr selbst
programmieren muß. Deshalb genügt es auch, diese Konzepte exemplarisch an der Sprache Eiffel zu besprechen. Hat man sie
einmal verstanden, so kann man relativ leicht dasselbe Problem in einer anderen Programmiersprache implementieren, indem
man im entsprechenden Manual nach der Syntax vergleichbarer Konstrukte sucht.