Design By Contract
 
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern

Veränderung (letzte Korrektur) (Änderung, Autor, Normalansicht)

Verändert: 81c81
* Contract First Design (CFD) und "Microkernel-Architektur" nach Ralf Westphal, bei Microsoft downloadbarer WebCast
* Contract First Design (CFD) und "Microkernel-Architektur" nach Ralf Westphal, bei Microsoft downloadbarer WebCast (8.5MB)

Herkunft

Design by Contract ist ein Konzept von Bertrand Meyer, das er in seiner Programmiersprache Eiffel und der dazugehörigen Entwicklungs-Methode dargestellt hat.

Grundidee

Die Grundidee ist, eine Methode eines Objektes wie einen Lieferanten (supplier) und den Aufrufer wie einen Kunden (client) zu betrachten. Der Lieferant schließt mit dem Kunden einen Vertrag (contract): Wenn Du (Kunde) meine Anforderungen (in Gestalt von Vorbedingungen) einhältst, werde ich meine Zusicherungen (in Gestalt von Nachbedingungen) einhalten und im übrigen das gewünschte Verfahren durchführen. Sollte ich nicht in der Lage sein, das Verfahren durchzuführen, werde ich nicht "irgend etwas" liefern, sondern eine Ausnahme auslösen.

Zusätzlich gibt es noch sogenannte Invarianten. Diese kann man als spezielle Nachbedingungen betrachten, die immer zugesichert sind, wenn der Kontrollfluss an den client zurückgegeben wird.

Beispiel

Das Einfügen eines Elementes in ein Verzeichnis, und zwar unter einem bestimmten Schlüssel:

  put (x: ELEMENT; key: STRING) is
             -- Insert x so that it will be retrievable through key.
             require
                     count <= capacity
                     not key.empty
             do
                     ... Some insertion algorithm ...
             ensure
                     has (x)
                     item (key) = x
                     count = old count + 1
             end

Man sieht hier den Vertrag. Die Anforderungen sind: Das Verfahren ist irgendein Algorithmus zum Einfügen.

Die Zusicherungen sind:

Vererbung

Besonders mächtig wird DesignByContract im Zusammenspiel mit Vererbungshierarchien. Standardmäßig werden alle Bedingungen vollständig mitvererbt; sie können unter Einhaltung folgender Regeln aber durch Subklassen modifiziert werden:

Diese Regeln scheinen motiviert durch das LiskovSubstitutionPrinciple.

Auf diese Art und Weise kann sogar der Contract eines Interfaces mehr oder weniger genau spezifiziert werden, ohne das also irgendetwas über die tatsächliche Implementierung bekannt ist. Dem Client ist damit sichergestellt, dass jede Implementierung diesem Contract genügt.

Anwendung

Man kann Vorbedingungen beim Eintritt in die Methode mit Hilfe von Asserts abprüfen und eine Ausnahme auslösen, wenn sie nicht eingehalten sind.

Man kann Nachbedingungen beim Austritt aus der Methode mit Hilfe von Asserts abprüfen und eine Ausnahme auslösen, wenn sie nicht eingehalten sind.

Beides zusammen liefert recht robuste Software, da der Aufrufer der Methode sich rechtzeitig die Finger verbrennt, wenn er gegen den Vertrag verstößt, den die Methode fordert.

Das Ganze ist natürlich nicht kostenlos! :-)

Diskussion

Sollte ich nicht in der Lage sein, das Verfahren durchzuführen, werde ich nicht "irgend etwas" liefern, sondern eine Ausnahme auslösen.

Das ist mir etwas unklar. Soweit ich weiß, ist das Ergebnis zumindest bei einer verletzten Vorbedingung nicht definiert... -- IljaPreuß

Nein, es ist ganz wichtig, dass eine Exception fliegt. Ein undefiniertes Ergebnis würde Design by contract entscheidend schwächen. Die Robustheit kommt ja gerade daher, dass sich der Aufrufer darauf verlassen kann, entweder das zugesicherte Ergebnis zu bekommen oder aber ganz deutlich zu merken, dass er es NICHT bekommt. -- MatthiasBohlen

Ressourcen


siehe auch:


StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 30. Juli 2006 10:03 (diff))
Suchbegriff: gesucht wird
im Titel
im Text