Konzept der Assertions und Prinzip von Design-by-Contract in einer kurzen Darstellung (Stand 2005)

Inhaltsverzeichnis

1 Einleitung

2 Vorüberlegungen
2.1 Fehlerquellen
2.2 Fehlererkennung

3 Design-By-Contract
3.1 Grundprinzip
3.2 EIFFEL
3.3 Aspekte von Design-By-Contract
3.4 Vorteile von Design-By-Contract

4 Assertions
4.1 Einsatz von Assertions
4.2 APP, Ein Präpozessor für C
4.3 Assertions und Exceptions
4.4 Vorteile/Probleme

5 Zusammenfassung

1 Einleitung

Die vorliegende Ausarbeitung stellt das Konzept der Assertions vor. As- sertions stellen eine Umsetzung des Design-by-Contract-Prinzips dar und ermöglichen eine Überwachung von Code zur Laufzeit. Im fol- genden sollen, ausgehend von David S. Rosenblums Paper “Toward a Method of Programming with Assertions” sowohl das Konzept der As- sertions, als auch das Prinzip von Design-By-Contract vorgestellt wer- den. (Ergänzt wird dieser Text durch eine weitere Ausarbeitung im Rah- men des o.g. Seminars. Titel: Assertions in Java)

2 Vorüberlegungen

Software sollte frei von Fehlern sein. Fehler während der Erstellung er- höhen die Kosten von Software, insbesondere wenn sie im Endstadium der Software-entwicklung oder später gefunden werden. Die Möglichkeit- en der Reduzierung von Fehlern während aller Stufen der Entwick- lung ist somit ein umfassendes Forschungsgebiet. Mit Hilfe von Asser- tions können Fehler in Programmen während der Phase der Implemen- tierung und der Testphase (und später) gefunden werden.

2.1 Fehlerquellen

Fehler können in allen Phasen der Softwareentwicklung auftreten. Die Fehler entstammen dabei aus unterschiedlichen Quellen:

- Fehler im Software-Design
- Fehler im Modell, welches der Software zugrunde liegt
- Fehler in der Definition von Interfaces
- Fehlerhafte Algorithmen
- Type Mismatch
- Fehler durch ungültige Wertebereiche einer Variablen
- Fehler während der Eingabe des Programms (typo)

Je nach Entwicklungsumgebung können bestimmte Fehlertypen bere- its zur Compilezeit vom Compiler erkannt werden. Dazu gehören Fehler bei der Eingabe (typo) und - bei Umgebungen, die Typechecking unter - stützen - Fehler durch Verwendung nicht-passender Typen.

2.2 Fehlererkennung

Für die Suche nach Fehlern aus den verschiedenen Quellen stehen adäquate Methoden und Werkzeuge zur Verfügung. Typische Konstruk- te und Prinzipien zur Fehlersuche und Fehlerbehandlung oder auch zur Vermeidung von Fehlern sind:

- Modulares Design
- Model Checking
- Exceptions
- Assertions
- Testen
- Extreme Programming

Assertions können helfen, Fehler in u. a. folgenden Bereichen zu ver- meiden bzw. aufzudecken: Fehlerhafte Interface-Definitionen, fehler- hafte Algorithmen (nicht korrekte Umsetzung einer Spezifikation) und Fehler durch ungültige Wertebereiche einer Variablen.

3 Design-By-Contract

Design-By-Contract ist ein Prinzip, welches Korekktheit und Robus- theit von Software unterstützt. Vorgestellt wurde Design-By-Contract von Betrand Meyer im Zuge der Vorstellung der Programmiersprache EIFFEL.

3.1 Grundprinzip

Design-By-Contract ist eine Client-Server Betrachtungsweise der Zusam- menarbeit von Objekten. Dabei existieren Anbieter und Nutzer, wobei hier Funktionalität zur Verfügung gestellt, bzw. genutzt wird. Im Fall einer Interaktion werden - ähnlich einem realen Vertrag - für Nutzer und Anbieter Pflichten und Rechte vereinbart. Erfüllt der Nutzer die Auflagen des Anbieters, so ist die angebotene Leistung garantiert, umgekehrt gilt, dass die Nichterfüllung der Obligationen zum Verlust der Garantie führt.

Design-By-Contract wurde in zeitlicher und gedanklicher Nähe mit EIFFEL entwickelt.

3.2 EIFFEL

EIFFEL wurde 1985 von Betrand Meyer vorgestellt. Es handelt sich um eine vollständig objekt-orientierte Sprache, die als eine Alterna- tive zu C++ geplant gewesen ist. EIFFEL wurde entworfen, um das in- genieursmäßige Entwickeln von Software zu unterstützen. Klares De- sign und gegen Fehler abgesicherte Software sind die Hauptziele dabei gewesen, wobei die Umsetzung des Design-by-Contract eine entschei- dende Rolle einnimmt. EIFFEL hat allerdings weniger Verbreitung ge- funden als JAVA oder C und ihre Nachfolger.

3.3 Aspekte von Design-By-Contract

Spezifikation Jedes größere Softwareprojekt beginnt mit einer Spez- ifikation. Aufgabe von DBC ist das Assozieren von Teilen der Spezifik- tion mit Teilen von Softwarekomponenten, und schließlich die Verbindung mit der Implementierung. Eine Voraussetzung dafür ist die Möglichkeit, Spezifikationen direkt im Code zu plazieren. Assertions stellen eine solche Möglichkeit dar (siehe auch Abschnitt 4).

Veranschaulichung Ein typische Veranschaulichung des DBC erfolgt über Tabellen. Der Nutzer und der Anbieter eines Dienstes besitzen jeweils eine Auflage, also eine Bedingung, die erfüllt sein muß. Ist diese Bedingung erfüllt, kann die jeweilige Partei mit dem entsprechenden Nutzen aus der Interaktion rechnen.

Abbildung in dieser Leseprobe nicht enthalten

Schlüsselkonzepte Der Begriff der Bedingung (oder der erfüllten Be- dingung) spielt bei DBC eine zentrale Rolle. Nimmt man als Anbieter eines Dienstes beispielsweise eine Funktion, und als Nutzer eines Di- enstes eine weitere Funktion, die die andere aufruft, dann gelten nach dem DBC folgende Vereinbarungen:

- Precondition: Bedingung, die vom Nutzer eines Dienstes erfüllt sein muß, damit der Anbieter des Dienstes ein korrektes Ergebnis gewährleisten kann.
- Postcondition: Bedingung, die nach Ausführung eines Dienstes erfüllt sein muß.

Precondition (Vorbedingung) und Postcondition (Nachbedingung) gehören zu einzelnen Funktionen. Es gibt jedoch auch die Möglichkeit Bedin- gung an eine Klasse als Ganzes zu stellen. Eine Bedingung, die für alle Instanzen einer Klasse erfüllt sein muß heißt Class Invariant (Klass- eninvariante)

Dokumentation Jeder zwischen zwei Parteien geknüpfte Vertrag ist, wird er im Quellcode eingebettet und ist seine Notation nicht zu kom- plex und unverständlich, bereits ein Element eines weiteren wichtigen Teils von Software, der Dokumentation. Ein Fragment EIFFEL-Code zur Veranschaulichung dieser Tatsache:

Abbildung in dieser Leseprobe nicht enthalten

Ohne dass der Quellcode Kommentare enthält, lassen sich - auch ohne Kenntnis der EIFFEL-Syntax - folgende Bedingung feststellen: Das In- terface DICTIONARY bietet eine Funktion put an, an die folgende Vorbe- dingungen geknüpft sind: Eine Variable count soll eine andere Variable capacity nicht überschreiten und es soll kein leerer Schlüssel (key) an die Funktion übergeben werden. Die Nachbedingungen der Funktion wären: Das Interface DICTIONARY enthält ein Element x und diesem ist ein Schlüssel zugeordnet. Die Variable count ist um eins inkremen- tiert. Das Interface DICTIONARY besitzt weiterhin eine Invariante: Die Variable count soll den Wert Null nicht unterschreiten und den Wert der Variable capacity nicht überschreiten.

Das Beispiel ist simpel. Dennoch wird sichtbar, daß durch die in den Quellcode eingebetteten Bedingungen ein großer Teil der Spezifikation der Klasse bzw. der Funktion auf einem intuitiven Weg klar werden können.

Qualitätssicherung Im Idealfall lassen sich in einem Softwaresys- tem für jede Komponente Bedingungen festlegen, die der Spezifikation entsprechen. Angenommen, die Spezifikation sei fehlerfrei, so ließe sich die Korrektheit des Gesamtsystems überprüfen, indem man die Kor- rektheit jeder implementierten Routine oder Klasse in Bezug auf die Spezifikation nachweist. Allerdings ist in fast allen Fällen ein solches Vorgehen für die Praxis ungeeignet. Dennoch helfen die durch DBC zur Verfügung gestellten Konstrukte Fehler in der Software über Tests zu finden. Die Bedingungen können zur Laufzeit überwacht werden, wobei nicht erfüllte Bedingungen eine Ausnahme auslösen und dokumentiert werden. Fehler können so leichter lokalisiert werden.

Design-By-Contract und Vererbung Vererbung gehört zum Paradig- ma der Objekt-Orientierung. Im Rahmen von DBC erben Unterklassen auch Verträge, also Vor- bzw. Nachbedingungen der Oberklasse. Dabei gelten folgende Einschränkungen:

- Jede von einer Unterklasse überschriebene Routine muß die Pre- condition der überschriebenen Routine übernehmen oder kann diese abschwächen.
- Jede von einer Unterklasse überschriebene Routine muß die Post- condion der überschriebenen Routine übernehmen oder kann diese verstärken.

Nicht-erfüllte Bedingungen Enthielte ein Programm lediglich Bedin- gungen, die stets erfüllbar oder erfüllt wären, so hätten sie keinen Nutzen. Im Fall einer Verletzung einer Assertion können grundsätzlich verschiedene Wege eingeschlagen werden:

- Retry: Nach einer fehlgeschlagenen Bedingung steht ein alterna- tiver Programmpfad zur Verfügung und wird ausgeführt.
- Organized panic: Die fehlgeschlagene Routine meldet das Scheit- ern an die aufrufende Funktion.
- Abort: Das Programm bricht ab und gibt eine Diagnosemeldung aus.

Welche Möglichkeiten tatsächlich zur Verfügung stehen, hängt natür- lich von der verwendeten Programmiersprache und der entsprechen- den Unterstützung für die Behandlung von Ausnahmen ab.

[...]