Grundlagen der Informatik I “Programmierung”

Verständlichkeit der Module: Die Leistungen eines Moduls sollte von außen unabhängig von seinen
Verwendungen verständlich sein (“Grob”-Spezifikation oder Kontrakt des Moduls). Die Beschreibung,
wie die Leistungen des Moduls zustande kommen, sollen aus Beschreibung der Kooperation (“Fein”-
Spezifikation oder Implementierung des Moduls) einiger weniger Module (Supplier) und deren Grobspezifikationen
ersichtlich sein.
Nur, wenn ein Modul auch unabhängig von seiner Umgebung verstanden werden kann, sind Wartungen
und Erweiterungen eines Systems leicht durchzuführen.
Auf diese Punkte werden wir im nächsten Kapitel besonders eingehen. Die Grobspezifikation von BUCH
wird einfach sein, da man mit Büchern nur wenig machen kann. Die Implementierung von TRANSAKTION
und BIBLIOTHEK sollte so einfach werden, daß sie auf der Basis der Grobspezifikationen der Klassen
ARRAY, LINKED LIST und BUCH voll verständlich ist.
Stetigkeit der Module: Im Gegensatz zu “chaotischen” Systemen haben stetige Systeme die Eigenschaft,
daß kleine Änderungen der Ursachen auch nur kleine Änderungen der Wirkung nach sich ziehen. Von
einer Beschreibungsmethode sollte man verlangen, daß sie die Entwicklung stetiger Systeme unterstützt.
Speziell sollen lokale Änderungen in einem Modul nicht die Architektur des Systems ruinieren. Anders
ausgedrückt, wird ein Fehler in einem Modul repariert, so sollen die Korrekturen auf diesen Modul
beschränkt bleiben.
Das bedeutet zum Beispiel, daß wir innerhalb der Klassen PERSON und BUCH tun können, was wir wollen,
solange wir die Schnittstelle nicht ändern (eine Erweiterung der Schnittstelle unter Beibehaltung aller
alten Verträge ist erlaubt).
Modularer Schutz: Eine Beschreibungsmethode muß es ermöglichen, daß Ausnahmesituationen (Laufzeitfehler,
fehlerhafte Eingaben, Speichermangel etc.), die bei der Durchführung eines Moduls auftreten, nur
lokale Effekte haben und sich nicht etwa auf andere Module fortpflanzen.
Im Vergleich zu allen anderen Sprachen, die derzeit im industriellen Einsatz sind, ist Eiffel derzeit die einzige
Sprache, welche diese Prinzipien massiv unterstützt. Sie gibt also einen geeigneten Rahmen um eine adäquate
Modellierung der Realität zu erreichen. Damit ist der sinnvolle Einsatz jedoch noch lange nicht gewährleistet.
Viele Eiffel-Programme werden noch im Stil herkömmlicher Programmiersprachen geschrieben und verstoßen
gegen die Richtlinien eines objektorientierten Entwurfs.
Welche Prinzipien sind nun zu beachten, wenn ein System methodisch korrekt entworfen werden soll? Auch
hier schlägt [Meyer, 1988] fünf Kriterien vor, die eine geeignete Modularisierung gewährleisten sollen:
Moduln müssen Klassen entsprechen: Die Klassenstruktur der Zerlegungseinheiten stellt sicher, daß
das System in klar definierte und voneinander abgegrenzte Einheiten zerlegt ist, die für sich verständlich
sind, später in anderen Systemen kombiniert werden können und Schutz gegen Fehlfunktion gewähren.
Minimale Kommunikation zwischen Moduln: Zwischen Modulen kann auf vielfache Weise kommuniziert
werden. Module können einander aufrufen (durch Typvereinbarung von Variablen), gemeinsame
Datenstrukturen benutzen usw. Prinzipiell könnte jedes Modul jedes andere verwenden. Stetigkeit aber
erreicht man nur bei geringer gegenseitiger Verwendung.
Schmale Schnittstellen: Wenn zwei Module kooperieren, so soll sich der Informationsaustausch (Parameter)
auf die absolut notwendige Information (need to know) beschränken. Dies unterstützt Stetigkeit
und modularen Schutz.
Vollständige Beschreibung der Schnittstellen: Wenn zwei Moduln kooperieren, so muß diese Kooperation
in diesen beiden vollständig beschrieben sein. Dies fördert Zerlegbarkeit und Kombinierbarkeit,
Stetigkeit und Verständlichkeit, da keine unvorhersehbaren Effekte auftreten können.