Too Much Abstraction?

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

Who Can Handle How Much Abstraction?

Not everybody can handle abstractions equally well. Not even every software developer. Therefore some systems analysis and design methods achieve different levels of acceptance, depending how much or how little abstraction they demand. In this paper I discuss the consequences of different levels of abstraction with respect to the goals of object-oriented methods. In particular I look at the effect of abstraction levels on understandability, closeness to the real world, flexibility and reusability.

Wer verträgt wieviel Abstraktion?

Dr. Peter Hruschka

Nicht jeder Mensch kann gleich gut mit Abstraktionen umgehen. Auch nicht jeder Softwareentwickler. Deshalb ist die Akzeptanz von Analyse- und Designmethoden unterschiedlich stark, je nachdem wieviel oder wie wenig Abstraktion sie enthalten. In diesem Beitrag wollen wir diskutieren, welche Auswirkungen verschiedene Abstraktionsebenen auf wesentliche Ziele objektorientierter Methoden, wie leichte Verständlichkeit, Nähe zur Anwendung, Flexibilität und Wiederverwendbarkeit haben.

Alle modernen Analyse- und Designmethoden gehen davon aus, daþ Sie für Ihre Anwendung Modelle erstellen. Dies gilt für strukturierte Methoden genauso wie für objektorientierte Methoden. Modelle sind immer Abstraktionen Ihrer Projekte, Ihrer realen Anwendungswelt. Sie greifen einige wenige, wesentliche Aspekte heraus und stellen nur diese im Modell dar. Viele andere Aspekte werden bei der Modellabstraktion bewuþt unterdrückt oder beiseite gelassen, um komplexe Sachverhalte möglichst einfach und überschaubar darstellen zu können.

Betrachten wir zuerst die Analysemethode, die derzeit am weitesten verbreitet ist: Strukturierte Analyse. Das wesentliche Modell darin sind die Datenflußdiagramme. Sie zeichnen die Funktionen Ihrer Anwendung und verbinden diese ganz einfach mit den Eingaben und Ausgaben. Die Popularität dieser Methode erklärt sich vielleicht daraus, daß es vielen Entwicklern leicht von der Hand geht, derartige Zusammenhänge aufzuzeichnen: Als Eingabe nehmen wir die Geschichte, die ein Autor erzählen möchte. Die Funktion heißt "schreibe einen Roman" und heraus kommt ein Manuskript. Dieses geht als Eingabe zum Verleger, der die Funktion "drucke Manuskript" ausführt und als Ergebnis entsteht ein neuer Roman.

Bei den objektorientierten Analysemethoden ist das Hauptausdrucksmittel ein Objektdiagramm. hnlich wie bei Entity-Relationship-Modellen stehen dabei die Dinge im Mittelpunkt, mit denen wir etwas tun. Und diese Dinge (= Objekte oder Objektklassen) werden nicht durch Funktionen miteinander verbunden, sondern meist durch Beziehungen (oder Assoziationen). Solche Beziehungen sind oft wesentlich abstrakter als die oben betrachteten Funktionen. Denn im Normalfall kann man aus einer Beziehungen viele Funktionen ableiten. Aus der Beziehung "Verleger produziert Roman" lassen sich z.B. folgende Funktionen ableiten: "suche Verleger eines bestimmten Romans", "suche alle Romane, die ein bestimmter Verleger herausgegeben hat", "produziere einen neuen Roman", "erstelle Verlegerstatistik über eine gegebene Liste von Romanen", und noch viele andere. Objektdiagramme mit Objekten und solch abstrakten Beziehungen fallen nicht vom Himmel. Das Finden der Objekte ist noch (relativ) einfach. Das Zusammenfügen der Diagramme mit den Beziehungen, die wirklich wichtig sind und das Weglassen von Zusammenhängen, die weniger wichtig sind, ist eine schwierige Aufgabe. Viele Entwickler brauchen zuerst die konkreten Zusammenhänge in Form von Funktionen zwischen Objekten, bevor sie die abstrakteren Zusammenhänge finden können.

Deshalb schlagen einige Autoren (z.B. James Rumbaugh in OMT) vor, daß man neben den Objektdiagrammen auch Diagramme mit einzelnen Ausprägungen von Objekten und ganz konkreten Verbindungen zu anderen Objekten zeichnen soll. Bevor man "Person ist Autor von Buch" und "Person liest Buch" als abstrakte Beziehungen in seinem Modell einzeichnet, ist es leichter, wenn man ganz konkret mit echten Objekten und deren Zusammenhängen beginnt: Ivar Jacobson (eine konkrete Person) hat das Buch "Object-Oriented Software Enginering" geschrieben. Das Buch "OMT" stammt (u.a.) von James Rumbaugh. Fritz Müller hat das Buch "Objektorientierte Analyse" von Coad/Yourdon gelesen. Das Buch "Design Patterns" wurde nicht nur von Onkel Alfred, sondern auch von Nichte Maria gelesen.

Auf Dauer sind diese Ausprägungsdiagramme bei größeren Projekten nicht leicht durchzuhalten. Denn erstens erschlägt uns in realen Projekten die Vielzahl von solchen Zusammenhängen, so daß wir versuchen müssen, möglichst schnell auf ein abstrakteres Modell zu kommen. Statt hunderte von möglichen einzelnen Zusammenhängen aufzuzeichnen müssen wir die wenigen interessanten Beziehungen finden. Und zweitens sind viele Systementwickler und Kunden es nicht gewöhnt, in Objekten und Beziehungen zu denken. Vielen fällt es leichter, in Geschäftsprozessen und (dynamischen) Abläufen zu denken, unabhängig davon, welche Objekte an solchen Abläufen insgesamt beteiligt sind. "Zuerst muß ein Autor eine Idee für einen Roman haben. Dann schreibt er ihn und sucht einen Verleger. Sobalb das Buch gedruckt ist, hoffen Verlag und Autor auf eine möglichst große Leserschaft. Ist das Buch erst einmal in den Bestsellerlisten, so läuft der Verkauf viel besser. Durch die Diskussion mit Freunden und Bekannten werden immer mehr Personen angeregt, dieses Buch auch zu lesen". Solche Geschichten erzählen sich leichter, als grundlegende Beziehungen wie "Autor schreibt Buch", Verleger produziert Buch", "Person liest Buch" zu finden.

Ivar Jacobson hat diese Art zu denken wieder salonfähig gemacht, indem er derartige informelle Szenarienbeschreibungen, die er "Use Cases" (Anwendungsfälle) nennt, als Basis seiner Methode OOSE eingeführt hat. Somit können Sie die objektorientierte Analyse damit beginnen, ohne viel Abstraktion die Ihnen bekannten, konkreten Abläufe umgangssprachlich hinzuschreiben. Das können viele Entwickler, auch ohne OOA-Ausbildung. Und das können auch viele Kunden lesen und verstehen. Use-Cases verlangen noch nicht nach einem hohen Abstraktionsgrad.

Will man einen Schritt weitergehen, so kann man Use-Cases etwas stärker formalisieren und abstrahieren. Wir erstellen daraus "Event Traces": Diagramme, die die Ereignisse (Events) in einem Use-Case Schritt für Schritt in ihrer zeitlichen Aufeinanderfolge aufzeichnen und nachvollziehbar machen (= tracing). Damit denken wir zwar nach wie vor in ganz konkreten Abläufen und Folgen von Ereignissen und Aktionen, aber wir ordnen diese bereits Objekten zu. Ein Event Trace betrachtet ein bestimmtes Eingangsereignis und modelliert, welche Objekte bei diesem Ereignis beteiligt sind, was sie in diesem Falle machen und mit welchen anderen Objekten sie kommunizieren. Der gesamte Ablauf eines Use-Cases wird in Stückchen aufgeteilt, die jeweils einem Objekt zugeordnet werden können.

Gehen wir noch einen Schritt weiter mit der Abstraktion: Hat man nun mehrere Use-Cases oder Event-Traces gefunden, so kann man anfangen, typische Zusammenhänge zwischen Objekten und typische Verhaltensmuster einzelner Objekte daran zu erkennen. Betrachten wir beide Abstraktionsschritte etwas näher:

Zunächst die typischen Zusammenhänge zwischen Objekten: Wir modellieren sie als Objektdiagramme mit Beziehungen (Assoziationen). Wie oben besprochen ist eine Beziehung ist eine sehr abstrakter, statischer Zusammenhang zwischen zwei Objektklassen. Das Auffinden ist nicht leicht. Aber jetzt haben Sie viele Use-Cases und Event-Traces als Hilfe dazu. Aus den konkreten Zusammenhängen kommt man zu abstrakten Zusammenhängen. Was aber bringt dieser Abstraktionsschritt für unsere objektorientierten Modelle? So wie die Daten generell langlebiger als die Funktionen sind, so gilt auch in den Objektmodellen, daß die Beziehungen viel langlebiger sind, als die Zugriffsfunktionen von einem Objekt zu einem anderen. Hat man daher den schwierigen Schritt geschafft und gute Beziehungen gefunden, dann kann man davon ausgehen, ein sehr stabiles und ausbaufähiges Modell zu haben. Das spätere Hinzufügen neuer Funktionen ist dann leicht machbar (wenn der Chef wieder einmal eine neue Art von Auswerteliste über andere Attribute von Büchern und Autoren braucht, wie z.B. "suche alle Bücher, deren Titel mehr als 5 Wörter enthält und erstelle eine Statistik über das Herkunftland der Autoren").

Die zweite, höhere Abstraktion aus Use-Cases und Event-Traces, die typischen Verhaltensmuster von Objekten, modellieren wir als Zustandübergangsdiagramme (oder als State Charts). Diese gelten jetzt unabhängig von konkreten Ereignissen. Sie sind ein abstraktes Verhaltensmodell und beschreiben daher nicht nur einen möglichen Ablauf, sondern alle möglichen Abläufe eines Objekts. In den Lehrbüchern sind das meist zusammenhängende, schöne Zyklen (Object Life Cycles): Ein Ventil wechselt den Zustand immer zwischen "auf" und "zu"; manchmal auch "blockiert". Schwieriger werden diese Modelle, wenn ein Objekt viele nicht zusammenhängende Abläufe haben kann, die zu unterschiedlichsten Zeitpunkten bei unterschiedlichen Ereignissen benutzt werden. Dann ist das Finden und Zeichnen dieser Zustandsmodelle gar nicht so einfach.

Durch Objektmodelle und dynamische Modelle erreichen wird bereits mehr von den Zielen, die den Einsatz der Objektorientierung rechtfertigen. Für die Insider beginnt jedoch die Objektorientierung vielleicht erst einen Schritt danach. Versetzen Sie sich in die Lage eines Lagerleiters eines großen Kfz-Reparaturbetriebes. Sie haben in Zusammenarbeit mit einem Softwarehaus Ihre Bedürfnisse bezüglich Lagerhaltung und Nachbestellung analysiert und ein wunderbares Objektmodell mit dynamischen Modellen für Ihre Autoteile entwickelt. Ein halbes Jahr später kommt der Innendienst dieses Betriebes auf die Idee, daß es für die Ðberwachung des vorhandenen Büromaterials und für dessen Nachbestellung höchste Zeit wäre, ein EDV-System einzuführen. Leider ist das Lager- und Bestellsystem der Werkstatt so spezifisch auf Motorenteile, Getriebe, Auspuff, etc. ausgelegt und geht außerdem davon aus, daß alles von der Zentralwerkstatt des Autoherstellers geliefert wird, daß der Innendienst mit seinen verschiedenen Artikeln und Zulieferer das System nicht direkt nutzen kann. Eine höhere Abstraktion des Lagerhaltungssystems über die einzelnen Abteilungen des KfZ-Reparaturbetriebs wäre schön, denn dann könnte man den Entwicklungsaufwand für das zweite System drastisch reduzieren. Das erste System hätte genügend Funktionalität und Flexibilität, um auch die Nachbestellung von Büromaterial zu übernehmen.

Gehen wir noch einen Schritt weiter. Als EDV-Verantwortlicher des Kfz-Reparaturbetriebs haben Sie vielleicht genügend Weitblick gehabt, um das System unabhängig von der Werkstatt zu gestalten und daher auch für den Innendienst einsetzen zu können. Aber haben Sie daran gedacht, daß Sie die Entwicklungskosten für das System vielleicht dadurch wieder mehr als zurückholen können, daß Sie das Lager- und Bestellsystem auch ganz unabhängig von Ihrer Firma analysieren und entwerfen, so daß Sie dieses System auch einer Supermarktkette anbieten können, die weder mit Autoteilen noch mit Büromaterial handelt, sondern mit Lebensmitteln und Haushaltsartikeln? In wirklich guten, objektorientierten Modellen versucht man, nicht nur über den Tellerrand von Projekten hinauszublicken, sondern auch über Firmen- und Branchengrenzen hinweg die Modelle so allgemein zu gestalten, daß eine Anwendung in ähnlichen Branchen ohne nderungen möglich sind. Das heißt natürlich noch höher zu abstrahieren, und sehr weit weg von Ihrer Anwendung über Waren und Warengruppen, über mögliche Lieferanten und Ersatzlieferanten, über variable Strategien bei Lieferschwierigkeiten, etc. nachzudenken, obwohl Ihr konkretes Projekt dies (momentan) nicht verlangt. Diese Ðberlegungen führen aber zu mehr Flexibilität im System, weil Analytiker und Designer explizit nach weiteren Einsatzmöglichkeiten suchen und die Systemarchitektur möglichst unabhängig von den Gegebenheiten des konkreten Projekts gestalten. Es soll natürlich nicht verschwiegen werden, daß diese Flexibilität und Wiederverwendbarkeit ihren Preis hat. Das Finden höherer Abstraktion braucht Zeit und kostet somit auch Geld. Sie müssen entscheiden, wie weit sie mögliche nderungen und Erweiterungen frühzeitig mitplanen oder ob Sie es darauf ankommen lassen, daß das System später in wesentlichen Teilen umgeschrieben werden muß.

Kehren wir zurück zu unserem Ausgangspunkt: Die Popularität der Use-Cases von Ivar Jacobson ist meines Erachtens deshalb so groß, weil sie sehr konkret, in der Sprache von EDV- und Objektlaien, mit wenig Formalismus geschrieben werden können und langsam an die abstraktere Modellierung heranführen. Sie helfen den Entwicklern beim Finden höherer Abstraktionen (z.B. Objektmodelle, dynamische Modelle). Sie helfen aber auch später anderen Personen, die die Analye lesen und verstehen müssen. Diese Leser erhalten durch die Use-Cases ein konkretes Bild zu den abstrakten Objektmodellen. Es ist daher nicht verwunderlich, daß diese Idee von Jacobson inzwischen in fast alle OO-Methoden übernommen wird. Fast alle OO-Gurus bekennen sich inzwischen dazu, daß Use-Cases ein wunderbarer Einstieg sind, um die abstrakteren Modelle zu finden.

Use Cases helfen jedoch wenig bei der Erreichung der wirklichen OO-Ziele: für einen hohen Grad an Wiederverwendbarkeit, für größere Flexibilität und mehr Stabilität der Modelle. Dazu müssen Sie den schwierigen, aber lohnenswerten Schritt zu abstrakteren Modellen machen, die dann weniger mit Ihrer konkreten Anwendungswelt zu tun haben.

Auf den Punkt gebracht: Je konkreter die Modelle sind, d.h. je weniger Abstraktion sie verwenden, desto besser die Akzeptanz. Je weiter weg von der konkreten Anwendung die Modelle sind, d.h. je mehr Abstraktion, desto mehr Flexibilität und Wiederverwendbarkeit für die Systeme. Viele der OO-Methoden ergänzen derzeit die weniger abstrakten Ausdrucksmittel wie Use-Cases und Event-Traces zu den relativ abstrakten Objektdiagrammen und dynamischen Modellen, um so mehr Akzeptanz bei Anwendern zu bekommen.

top of page