OOD Easy?

The following paper was originally published in Peter Hruschka's column on object-oriented analysis and design methods in Objekt Spektrum 5/95. This is the English abstract:

OO-Design: totally simple or very complex?

Many object-oriented methods claim to model the real world during the analysis stage of a project, and just "add a few things" until the object program finally runs. This seamless transition between analysis, design and implementation is one of the often-quoted advantages of OO methods when comparing them with structured methods. This paper takes a closer look at today's OO design methods. We will answer the question whether OOD is really such an easy mapping from analysis objects to programming languages.

OO-Design: ganz einfach oder sehr kompliziert?

Peter Hruschka

Viele OO-Methoden sind mit dem Anspruch angetreten, in der Analyse die Anwendungsobjekte zu modellieren und diese danach "ganz einfach" weiterzuentwickeln, bis das Programm läuft. Der nahtlose, weiche Ðbergang von Analyse über Design zur Programmierung ist eine der immer wieder genannten Versprechungen der Objektorientierung. In diesem Beitrag wollen wir objektorientierten Entwurf und die dafür heute verfügbaren Methoden einmal unter die Lupe nehmen. Wir fragen, ob Design wirklich nur das Abbilden der Analyseobjekte in eine Programmiersprache ist oder ob mehr dahintersteckt.

Aus Sicht der Methoden behandeln wir hier nur zwei Extrembeispiele. In der Coad/Yourdon Methode reicht für das Design das gleiche Ausdrucksmittel wie für die Analyse aus: eine Art von Diagramm mit Klassen und Objekten. Hinzu kommt jedoch die Empfehlung, diese Diagramme für 4 Bereiche zu erstellen, wovon nur einer (die "Problem Domain Component") schon in der Analyse betrachtet wurde. Die anderen drei diskutieren die Mensch-Maschine-Schnittstelle, die Datenhaltung und die Task-Verwaltung eines Systems. Also einfachste Ausdrucksmittel, angewandt auf vier relevante Bereiche im Design. Bei Grady Booch hingegen werden acht verschiedene Modelle mit verschiedenen Diagrammarten verwendet, um jeweils logische und physikalische, statische und dynamische Sichten zu erstellen.

Brauchen wir diese Komplexität in der Methode von Booch oder reicht eine einfache Methode wie die von Coad/Yourdon aus? Zweifelsohne wurde mit beiden Methoden bereits erfolgreich in Projekten gearbeitet und lauffähige Systeme produziert. Die Antwort hängt wohl stark davon ab, in welcher Branche man Systeme von welcher Größenordnung und Komplexität produziert.

Bei einfachen Systemen, die aus einem Hauptprogramm und einigen Unterprogrammen bestehen, die auf einem einzigen Rechner ausgeführt werden und außer ein bißchen Bedienerdialog keine wesentlichen Schnittstellen zu anderen Systemen aufweisen, kann man sicherlich das Analyseergebnis rasch und ohne viele Modifikationen in einen Entwurf und in eine Implementierung umsetzen. Dazu braucht man keine fünf verschiedenen Diagrammarten.

Wenn Sie jedoch an einem System arbeiten, das geographisch verteilt wird, Netzwerke benutzt, aus vielen physikalischen Teilsystemen besteht, die zusammen die in den Anforderungen gewünschte Funktionalität umsetzen, und wenn Sie aus Sicherheitsgründen Redundanz ins Spiel bringen und dieselbe vom Benutzer gewünschte Funktionalität auf verschiedene Weise mehrfach implementieren, wenn Client/Server-Schnittstellen sowohl in die Mensch-Maschine-Komponente, wie auch in die Anwendung und in die Datenhaltung eingezogen werden, und wenn Sie dynamische Lastverteilung brauchen, damit der jeweils freieste Rechner die Aufgabe übernimmt, und wenn Sie aus Performancegründen logische Aufgaben in Teile zerstückeln und zu neuen Einheiten zusammenfügen müssen, dann brauchen Sie eine Designmethode, die logische und physikalische Modelle sauber trennt, die Verteilung darstellen kann, die Prozessormodelle unterstützt, um Hardwarestrukturen oder Organisationsstrukturen auszudrücken, die unterschiedliche Einheiten für die Laufzeitumgebung bilden kann - und trotzdem noch alle Informationen im Projekt zusammenhält und querverweist, so daß jeder einzelne Aspekt für sich betrachtet, diskutiert und überprüft werden kann.

Die Booch-Methode stellt all diese Konzepte zur Verfügung. Wer sie braucht, kann sie nutzen. Nicht jeder wird sie in jedem Projekt brauchen. Was für den einen daher übermäßig komplex aussieht, ist für den anderen der Reiz der semantischen Vielfalt. Man muß aber aus Methodensicht diese semantische Vielfalt nicht mit so vielen verschiedenen Diagrammarten und Notationen erkaufen. Die Hatley/Pirbhai-Architekturmethode (Derek Hatley/Imtiaz Pirbhai: "Strategies for Real-Time Systems Specifications", Dorset House,New York, 1987; deutsch: Hanser-Verlag, München) kommt mit nur zwei Modellen aus, um ebenfalls all diese Aspekte darzustellen: einem Requirements-Modell für die Anforderungen und einem Architekturmodell für den Entwurf. Diese beiden Modelle werden jedoch auf verschiedenen Ebenen immer wieder angewandt. Das Architekturmodell zeigt auf höherer Ebene zunächst vielleicht die geographische, politische Aufteilung eines Systems, später dann pro Standort die Prozessoraufteilung. Noch eine Ebene tiefer vielleicht die Trennung von Hardware und Softwarekomponenten und zum Schluß innerhalb der Softwarekomponenten die Aufteilung in parallele Tasks. Der Vorteil für den Anwender der Methode: man muß nur zwei Modelle statt acht Modellen lernen! Dies ist kein Plädoyer für die Hatley-Pirbhai-Methode und gegen Booch. Es soll nur zeigen, daß man die notwendigen Aspekte, die man im Design bedenken muß, auf verschiedene Arten ausdrücken kann, ohne an semantischer Vielfalt zu verlieren.

Der letzte Absatz sollte eher als Warnung an all diejenigen verstanden werden, die sich von der Einfachheit einer Methode wie Coad/Yourdon zu der Annahme hinreißen lassen, daß Design ein ganz einfacher Prozeß ist. Das Gegenteil ist der Fall. Design für größere, verteilte Systeme ist eine aufwendige Angelegenheit, bei der viele Aspekte bedacht werden müssen. Eine gute Designmethode muß daher Ausdrucksmittel für all diese Aspekte anbieten. Aber Ausdrucksmittel anbieten bedeutet nicht, daß für jeden Aspekt eine andere Art von Diagramm gezeichnet werden muß. Denken Sie einmal zurück: für die Programmablaufpläne nach DIN 66001 standen uns eine Vielzahl von Symbolen zur Verfügung. Etwas später haben wir gelernt, daß man Programmablauf auch mit den drei Grundelementen der strukturierten Programmierung (Sequenz, Iteration und Selektion) ausdrücken kann. Und Notationen wie Nassi-Shneiderman-Diagramme hatten nur ganz wenige unterschiedliche Konstrukte. Das gleiche erleben wir heute im objektorientierten Design. Manche Methoden haben sehr viele Ausdrucksmittel, andere versuchen es mit wesentlich weniger. Wo die Schmerzgrenze für die Praktiker erreicht wird, muß die Projekterfahrung in den nächsten Jahren noch zeigen.

An einer Stelle können wir bei den Notationen jedoch sparen. Eine Designmethode muß heute hauptsächlich Aspekte des Designs im Großen ausdrücken, d.h. die Architektur des Systems darstellen können. Nicht alle Spezialitäten einzelner Programmiersprachen müssen bis in den Architekturentwurf in die Diagramme durchschlagen. Vieles davon kann kann "hinter den Diagrammen" direkt in der Programmiersprache machen. In diesem Sinne sind viele der heute bekannten OO-Designmethoden noch mangelhaft, weil sie entweder zuviel "graphisches Programmieren" unterstützen (C++ oder Ada in Diagrammform) oder zuwenig Konzepte für Entwurf im Großen (Prozessorstrukturen, Verteilung von Software, etc.) aufweisen. Der Grund für die fehlenden Konzepte im Großen liegt einerseits daran, daß wir erst jetzt ernsthaft an Methoden für große Systeme herangehen (Structured Design mit seinen primitiven Structure Charts ist immer noch die weitverbreitetste Entwurfmethode!) und daß man sich noch nicht einig ist, welche Konzepte zu den wichtigen Architekturprinzipien gehören. Wenn Sie jedoch neuere Artikel lesen, finden Sie immer öfter das Wort "Architektur" statt Detailentwurf, und Begriffe wie "Frameworks" und "Patterns", die anzeigen, daß wir uns vom Entwurf im Kleinen wegbewegen. Bleiben Sie am Ball, aber wehren Sie sich gegen zu komplexe Methoden. Frei nach Einstein: Man soll alles so einfach wie möglich ausdrücken, aber nicht einfacher!

top of page