Inhaltsverzeichnis

1  Einleitung  3

2  Vorüberlegungen  3

2.1  Fehlerquellen  3

2.2  Fehlererkennung  4

3  Design-By-Contract  4

3.1  Grundprinzip  4

3.2  EIFFEL  5

3.3  Aspekte von Design-By-Contract  5

3.4  Vorteile von Design-By-Contract  8

4  Assertions  8

4.1  Einsatz von Assertions  9

4.2  APP, Ein Präpozessor für C  9

4.3  Assertions und Exceptions  12

4.4  Vorteile/Probleme  13

5  Zusammenfassung  15

2

1 Einleitung

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

2 Vorüberlegungen

Software sollte frei von Fehlern sein. Fehler während der Erstellung erhöhen die Kosten von Software, insbesondere wenn sie im Endstadium der Software-entwicklung oder später gefunden werden. Die Möglichkeiten der Reduzierung von Fehlern während aller Stufen der Entwicklung ist somit ein umfassendes Forschungsgebiet. Mit Hilfe von Assertions können Fehler in Programmen während der Phase der Implementierung 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 bereits zur Compilezeit vom Compiler erkannt werden. Dazu gehören Fehler bei der Eingabe (typo) und - bei Umgebungen, die Typechecking unterstützen - Fehler durch Verwendung nicht-passender Typen.

3

2.2 Fehlererkennung

Für die Suche nach Fehlern aus den verschiedenen Quellen stehen adäquate Methoden und Werkzeuge zur Verfügung. Typische Konstrukte 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 vermeiden bzw. aufzudecken: Fehlerhafte Interface-Definitionen, fehlerhafte 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 Robustheit 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 Zusammenarbeit 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.

4

3.2 EIFFEL

EIFFEL wurde 1985 von Betrand Meyer vorgestellt. Es handelt sich um eine vollständig objekt-orientierte Sprache, die als eine Alternative zu C++ geplant gewesen ist. EIFFEL wurde entworfen, um das ingenieursmäßige Entwickeln von Software zu unterstützen. Klares Design und gegen Fehler abgesicherte Software sind die Hauptziele dabei gewesen, wobei die Umsetzung des Design-by-Contract eine entscheidende 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 Spezifikation. Aufgabe von DBC ist das Assozieren von Teilen der Spezifiktion 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.

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

5