Hoare-Kalkül

formales System, um die Korrektheit von Programmen nachzuweisen
(Weitergeleitet von Hoare-Logik)

Der Hoare-Kalkül (auch Hoare-Logik oder Floyd-Hoare-Kalkül) ist ein formales System, um die Korrektheit von Programmen nachzuweisen. Er wurde von dem britischen Informatiker C. A. R. Hoare entwickelt und später von ihm und anderen Wissenschaftlern verbessert. Der Hoare-Kalkül wurde 1969 in einem Artikel mit dem Titel An axiomatic basis for computer programming veröffentlicht.[1]

Der Zweck des Systems ist es, eine Menge von logischen Regeln zu liefern, die es erlauben, Aussagen über die Korrektheit von imperativen Computer-Programmen zu treffen und sich dabei der mathematischen Logik zu bedienen. Hoare knüpft an frühere Beiträge von Robert Floyd an, der ein ähnliches System für Flussdiagramme veröffentlichte.[2] Im Gegensatz zum floydschen Verfahren, bei dem Ausführungspfade interpretiert werden, arbeitet der Hoare-Kalkül mit dem Quellcode.[3]

Alternativ kann auch der wp-Kalkül benutzt werden, bei dem im Gegensatz zum Hoare-Kalkül eine Rückwärtsanalyse stattfindet.

Hoare-Tripel

Bearbeiten

Das zentrale Element des Hoare-Kalküls ist das Hoare-Tripel, das beschreibt, wie ein Programmteil den Zustand einer Berechnung verändert:

 

Dabei sind   und   Zusicherungen (englisch assertions),   ist ein Programmsegment.   ist die Vorbedingung (englisch precondition) und   die Nachbedingung (englisch postcondition). Wenn die Vorbedingung zutrifft, gilt nach der Ausführung des Programmsegments die Nachbedingung. Zusicherungen sind Formeln der Prädikatenlogik.[1]

Ein Tripel kann auf folgende Weise verstanden werden: Falls   für den Programmzustand vor der Ausführung von   gilt, dann gilt   danach. Falls   nicht terminiert, dann gibt es kein danach, also kann in diesem Fall   jede beliebige Aussage sein. Tatsächlich kann man für   die Aussage falsch wählen, um auszudrücken, dass   nicht terminiert. Man spricht hier von partieller Korrektheit. Falls   immer terminiert und danach   wahr ist, spricht man von totaler Korrektheit. Die Terminierung muss unabhängig bewiesen werden.

Falls keine Vorbedingung existiert, schreibt man:[3]

 

Partielle Korrektheit

Bearbeiten

Der Hoare-Kalkül besteht aus Axiomen und Ableitungsregeln für alle Konstrukte einer einfachen imperativen Programmiersprache:

Axiom der leeren Anweisung

Bearbeiten

Wenn ein Programmsegment   keine Variablen verändert, so ändern sich auch die Zusicherungen nicht, es gilt also Nachbedingung gleich Vorbedingung:

 

Zuweisungsaxiom

Bearbeiten

Das Zuweisungsaxiom besagt, dass nach einer Zuweisung jede Aussage für die Variable gilt, welche vorher für die rechte Seite der Zuweisung galt:

 

  ist die Aussage, die dadurch entsteht, dass man in   jedes freie Vorkommen von   durch   ersetzt.

Genau genommen ist das Zuweisungsaxiom kein einzelnes Axiom, sondern ein Schema für eine unendliche Menge von Axiomen, denn  ,   und   können jede mögliche Form annehmen, und   kann daraus konstruiert werden.

Ein Beispiel für ein durch das Zuweisungsaxiom beschriebenes Tripel ist:

 

Kompositions- oder Sequenzregel

Bearbeiten

Um sequentielle Programme zu analysieren, können die einzelnen Tripel nach folgender Regel verknüpft werden:

 

Diese Regel kann auf folgende Weise angewendet werden: Wenn die über dem Strich stehenden Aussagen bewiesen worden sind, kann die unter dem Strich stehende Aussage auch als bewiesen angesehen werden.

Betrachtet man zum Beispiel die folgenden beiden Aussagen, die aus dem Zuweisungsaxiom folgen

 

und

 

kann man die folgende Aussage daraus folgern:

 

Auswahlregel (if-then-else-Regel)

Bearbeiten

Es gilt folgende Regel für Auswahlkonstrukte mit 2 Auswahlmöglichkeiten:[3]

 

Die Regel beweist also sowohl den if-Zweig, als auch den else-Zweig. Hat eine if-Abfrage keinen else-Zweig, so verwendet man eine leicht modifizierte Version dieser Regel:

 

Iterationsregel (while-Regel)

Bearbeiten
 

Hierbei wird   als die Schleifeninvariante bezeichnet, die sowohl vor, während und nach Ausführung der Schleife gültig ist. Eine Invariante muss manuell ermittelt werden.

Konsequenzregel (Rule of Consequence)

Bearbeiten
 

Die Konsequenzregel erlaubt es, die Vorbedingung zu verstärken und die Nachbedingung abzuschwächen und so die Anwendung anderer Beweisregeln zu ermöglichen. Insbesondere kann man auch die Vor- oder Nachbedingung durch eine äquivalente logische Formel ersetzen. Beispiel:

  ist partiell korrekt, denn
 

Totale Korrektheit

Bearbeiten

Wie oben erläutert eignet sich der beschriebene Kalkül nur für den Beweis der partiellen Korrektheit. Zum Beweis der totalen Korrektheit muss die while-Regel durch eine Schleifenvariante erweitert werden. Dabei handelt es sich um eine Funktion oder eine Variable  , die eine Zahl mit einem Anfangswert   darstellt. Es muss nun nachgewiesen werden, dass   in jedem Schleifendurchlauf verringert wird, und dass die Schleife ab einem bestimmten, verringerten Wert terminiert.[2]

Iterationsregel für totale Korrektheit

Bearbeiten
 

Hierbei ist   ein Term,   die Schleifeninvariante – also das, was in jedem Schleifendurchlauf gilt – und   eine Variable, die in  ,  ,   und   nicht frei vorkommt. Sie dient dazu, den Wert des Terms vor der Schleife mit dem nach der Schleife zu vergleichen. Die Bedingung   stellt sicher, dass   nicht negativ wird. Die Idee hinter der Regel ist, dass, wenn   mit jedem Schleifendurchlauf abnimmt, aber nie kleiner als Null wird, die Schleife irgendwann enden muss.   muss dabei aus einer fundierten Menge sein.

Bewertung

Bearbeiten

Mit dem Hoare-Kalkül und einer formalen Spezifikation ist es möglich, ein Programm oder Teile eines Programms auf Korrektheit zu prüfen. Er liefert damit eines der wenigen Verfahren, die tatsächlich Korrektheit nachweisen und nicht nur Anwesenheit von Fehlern feststellen können. Allerdings müssen die Ergebnisse einer Analyse mit dem Hoare-Kalkül mit Vorsicht genossen werden:

  • Ist die Spezifikation fehlerhaft, können zwar die Ergebnisse der Analyse korrekt sein, allerdings gegenüber einer falschen Spezifikation.
  • Mit dem Hoare-Kalkül werden keine Fehler gefunden, die durch Fehler in der Spezifikation der Programmiersprache selbst oder durch einen fehlerhaften Compiler entstehen.[3]
  • Der Hoare-Kalkül stößt bei großen Softwaresystemen, speziell mit globalen Variablen und Rekursion schnell an seine Grenzen.[4]
  • Zur Verifikation müssen Axiome der Computerarithmetik benutzt werden, die Besonderheiten, wie die Beschränktheit der mit Integer-Typen repräsentierbaren ganzen Zahlen und die Ungenauigkeit von Gleitkommazahlen, berücksichtigen.[3]

Literatur

Bearbeiten
Bearbeiten
  • Programmverifikation mit zahlreichen Beispielen und Übungsaufgaben
  • Das Project Bali hat Regeln nach Art des Hoare-Kalküls für ein Subset von Java aufgestellt, zur Benutzung mit dem Theorembeweiser Isabelle
  • Hoare Tutorial (Memento vom 31. Januar 2012 im Internet Archive) Ein Tutorial, das den Umgang mit dem Hoare-Kalkül zur Programmverifikation erklärt (PDF; 493 kB)
  • j-Algo-Modul Hoare Kalkül Ein Visualisierung des Hoare-Kalküls im Rahmen des Algorithmenvisualisierungsprogramms j-Algo
  • KeY-Hoare ist ein halbautomatisches Verifikationssystem, das auf dem KeY-Theorem-Prover aufbaut. Es führt den Hoare-Kalkül für einfache Schleifen durch.

Einzelnachweise

Bearbeiten
  1. a b Charles Antony Richard Hoare: An Axiomatic Basis for Computer Programming (Memento vom 4. März 2016 im Internet Archive) (PDF; 659 kB). In: Communications of the ACM. Bd. 12, Nr. 10, 1969, S. 576–585, doi:10.1145/363235.363259.
  2. a b Robert W. Floyd: Assigning meanings to programs. In: Proceedings of the American Mathematical Society Symposia on Applied Mathematics. Nr. 19, 1967, S. 19–31 (virginia.edu [PDF; 684 kB]).
  3. a b c d e Peter Liggesmeyer: Software-Qualität. 2. Auflage. Spektrum Akademischer Verlag, Heidelberg 2009, ISBN 978-3-8274-2056-5, S. 321–360, doi:10.1007/978-3-8274-2203-3.
  4. Edmund M. Clarke: Programming Language Constructs for Which it is Impossible to Obtain Good Hoare-like Axiom Systems. In: Journal of the Association for Computing Machinery. Band 26, Nr. 1, 1979, S. 129–147, doi:10.1145/512950.512952.