Nutzen und Notwendigkeit der Objektorientierung sind heute allgemein akzeptiert. Viele Entwickler verstehen darunter jedoch ausschließlich objektorientierte Programmierung (OOP). Aber OOP allein ist viel zuwenig objektorientiert. Die Voraussetzungen für eine neuartige Systemarchitektur müssen bereits bei der Analyse herbeigeführt werden.
Theoretisch ist alles klar: Die Objektorientierung führt zu einer einfachen und stabilen Software-Architektur. Objektorientierte Informationssysteme besitzen höhere Qualität und Leistungsfähigkeit, bringen die Kostenvorteile von PCs und Workstations zum fragen und sind darüber hinaus billiger zu erstellen und zu warten.
Soweit die Theorie. Die Praxis sieht oft anders aus. Viele Versuche mit C++, Smalltalk, Enfin oder anderen objektorientierten Programmier-Tools (OOP) enden in Ernüchterung. Die Werkzeuge sind nützlich bei der Programmierung eines Systems, gewähren aber keine Unterstützung für Analyse und Design. Auch läßt sich mit ihrer Hilfe keine stabile Objektarchitektur finden.
Die Diagnose lautet also: OOP allein ist zuwenig Objektorientierung. Wer Analyse und Design herkömmlich betreibt und erst bei der Programmierung mit der Objektorientierung beginnt, darf sich nicht wundern, wenn er hinterher vor unübersichtlichen Systemen steht, die funktionsorientiert aufgebaut, schwer zu ändern sowie teuer und zeitraubend bei Erstellung und Wartung sind. Dabei ist es dann kaum von Vorteil, daß die Programme intern objektorientiert angelegt sind. Hier fehlt - trotz OOP - eine systemweite Objektarchitektur, die die notwendige Vereinfachung und Klarheit des Gesamtsystems mit sich bringt.
Die Therapie besteht darin, früher mit der Objektorientierung zu beginnen - am besten schon in der Analyse. Die Erfahrung hat gezeigt, daß dann nicht nur eine stabile Objektarchitektur entsteht, sondern auch zwei weitere Vorteile wirksam werden: Zum eigen ist das objektorientierte Denken in der Analysephase viel leichter erlernbar, da weniger Details zu berücksichtigen sind; zum anderen erlaubt die objektorientierte Analyse (OOA) eine präzise Dokumentation der Überlegungen, die in den frühen Phasen einer Systemerstellung stattfinden.
Mit der OOA lassen sich, anders als bei älteren Methoden wie Structured Analysis, die wichtigsten strukturierenden Denkleistungen des menschlichen Gehirns festhalten und grafisch sichtbar machen:
- Zusammenfassung von Objekten mit gleichen Attributen und gleichem Verhalten zu einer Klasse,
- Unterscheidung eines Ganzen und seiner Teile,
- Verallgemeinerung und Spezialisierung sowie
- Beziehungen zwischen Objekten.
Diese Denkstrukturen werden von uns allen täglich benutzt. Wir haben sie so früh gelernt und wenden sie so oft an, daß wir sie kaum noch bewußt wahrnehmen.
Stabile Architektur für die folgenden Phasen
Ziel der objektorientierten Analyse ist, eine stabile Architektur für die folgenden Phasen Design und Programmierung bereitzustellen. Hierfür ist es notwendig, die grundlegenden Objekte des analysierten Anwendungsgebietes zu finden und zu dokumentieren. Für jedes Objekt muß definiert sein, was es sich merken muß (seine Attribute), welches Verhalten es zeigen soll (seine Funktionen) und welche Beziehungen zwischen ihm und anderen Objekten bestehen (seine Schnittstellen). Auf diese Weise entsteht eine Objektarchitektur, die über Jahre hin stabil bleiben kann, denn die grundlegenden Objektklassen eines Anwendungsgebietes ändern sich nur selten.
Von den vier Bestandteilen eines Anwendungsgebietes Objekte, Attribute, Funktionen und Schnittstellen - sind die Objekte die stabilsten. Im Gegensatz dazu erfahren Funktionen und Schnittstellen die häufigsten Änderungen. Deshalb bringt es auf jeden Fall Vorteile, wenn die Architektur von Systemen auf den Objekten des Anwendungsgebietes aufgebaut wird.
Herkömmliche DV-Systeme sind dagegen nach funktionalen Gesichtspunkten konzipiert. Sie haben eine funktionsorientierte Architektur, die bereits in der Analyse mit Data-flow-Diagrammen und Funktionaler Dekomposition beginnt. Konventionell arbeitende Entwickler ordnen die Funktionen dann - meist abweichend von der Analyse den vorgesehenen Programmen zu. Da die Architektur auf Funktionen, mithin auf den instabilsten Bestandteilen des Anwendungsgebietes basiert, ist es kein Zufall, daß herkömmliche Systeme von Änderungen stärker erschüttert werden als objektorientierte.
Ein weiterer Nachteil der funktionsorientierten Systemerstellung ist die gesonderte Behandlung von Funktionen und Daten. Diese Trennung beginnt ebenfalls schon in der Analyse, indem für Daten ein separates Entwurfsverfahren - meist eine Entity-Relationship-Modellierung - eingesetzt wird. Als Konsequenz daraus sind die Funktionen, die zu einem Objekt gehören, oft aber viele Diagramme - und später Programme - hinweg verstreut; Änderungen eines einzelnen Objektes erzeugen einen Rattenschwanz von Folgeänderungen.
Die Objektorientierung verfährt genau gegenteilig. Sie beendet die Trennung von Daten und Funktionen, und zwar schon in der Analysephase. Funktionen bleiben also bei ihren Objekten. Das bedeutet nicht nur eine bessere Übersichtlichkeit, sondern hat zusätzlich den Vorteil, daß die in der Analyse entstandene Objektstruktur während des Designs erhalten bleibt und nicht, wie im funktionsorientierten Design, verändert werden muß. Mehrere abgeschlossene Projekte haben dies bestätigt.
Infolge dieser Durchgängigkeit ist die Wartung von objektorientierten Systemen erheblich einfacher als die von herkömmlichen. Zum einen läßt sich eine Änderung der Analyse einfach bis zur Programmierung durchziehen. Zum anderen sind die Funktionen nicht mehr über viele Programme verstreut, sondern zentral im Objekt selber implementiert. Die gefürchteten Folgeänderungen treten deshalb nicht auf.
Das kommt uns Menschen entgegen, denn unser Denken ist nicht nur durch Fähigkeiten, sondern auch durch Beschränkungen gekennzeichnet. Die wichtigste dieser Grenzen beschreibt die sogenannte 7-plus/minus-2-Regel. Sie wurde 1956 in einer psychologischen Fachzeitschrift veröffentlicht und besagt, daß wir nur fünf bis neun Dinge gleichzeitig aufnehmen und verarbeiten können.
Die objektorientierte Vorgehensweise bei der Erstellung von Informationssystemen entspricht uns deshalb, weil sie unsere 7-plus/minus-2-Grenze weitgehend einhält, während die funktionsorientierten Methoden uns ständig zu einer Kapazitätsüberschreitung zwingen. Die Quittung dafür bekommen wir übrigens Tag für Tag in Form von Fehlern, hohen Kosten und langen Entwicklungszeiten.
Kapselung von Daten und Funktionen in Objekten ist wesentlich übersichtlicher. Das Ergebnis sind weniger Fehler, schnellere Entwicklung und geringere Kosten. Die objektorientierte Analyse ermöglicht es uns, für unsere Informationssysteme ein Fundament zu legen, das besser und korrekter ist als herkömmliche Analysen.
Das wichtigste Ergebnis einer objektorientierten Analyse liegt jedoch im Verständnis für das Anwendungsgebiet, das in einem OOA-Modell dokumentiert ist. Andere Themen, zum Beispiel die Gestaltung der Benutzeroberfläche, die Aufteilung der Verarbeitungen auf Prozesse und Rechner sowie die Behandlung von Datenspeichern, lassen sich dabei zurückstellen und auf das objektorientierte Design vertagen.
Auch diese Trennung ist eine Konsequenz aus der 7-plus/minus-2-Regel: Wer die Analyse überfrachtet, bekommt einen pseudopräzisen Datenberg, der für eine effiziente Kommunikation nicht mehr taugt, das Einarbeiten der nächste Änderung erschwert und vor allem nicht wiederverwendbar ist.
Ein OOA-Modell konzentriert sich auf das Wesentliche des Anwendungsgebietes. Es enthält keine überflüssigen Details und kapselt die Daten und Funktionen eines Objektes an einer einzigen Stelle. Unsere Erfahrung hat bestätigt, daß ein gut entworfenes OOA-Modell eins zu eins in Programmcode umsetzbar ist - sogar mit normalen Programmiersprachen (vgl. CW Nr. 19 vom 8. Mai 1992, Seite 38: "Auch unter MVS/TSO lassen sich objektorientierte Systeme bauen"). Für das Finden und Dokumentieren von Objekten gibt es bereits Regeln, die beispielsweise Peter Coad und Edward Yourdon in in ihrem 1991 erschienenen Buch "Object-Oriented Analysis" beschrieben haben. Der zentrale Leitsatz lautet: Was man nicht verstanden hat, kann man auch nicht dokumentieren.
Deshalb sollte sich der Analytiker zuerst mit der täglichen, realen Arbeit der Anwender vertraut machen, indem er zum Beispiel einmal einen ganzen Tag zuschaut, dann Fragen stellt und die wirklichen Experten, die Anwender, erzählen läßt. Zu fragen ist unter anderem, ob es schon OOA-Modelle aus ähnlichen oder angrenzenden Anwendungsgebieten gibt. Bereits in der objektorientierten Analyse kann nämlich die Wiederverwendung beginnen.