Wichtiger Bestandteil objektorientierter Techniken ist die Modellbildung, sollen die Modelle doch helfen, komplexe Systeme zu entwerfen, zu entwirren sowie Zusammenhaenge aufzuzeigen. Dass der Anspruch nicht in jedem Fall erfuellt wird, zeigt Martin Fowler*, indem er die gaengigsten Methoden einander gegenueberstellt. Der dritte und letzte Teil seiner Untersuchung befasst sich mit den Darstellungsmoeglichkeiten wechselnder Systemzustaende und der Aufspaltung in Systemkomponenten.

Der am haeufigsten verwendete Ansatz fuer die verhaltensbezogene Modellbildung ist noch immer der Ablaufplan oder sein Aequivalent, der Pseudocode. Die Unzulaenglichkeiten, die die beiden prozedurbasierten Techniken bei einem komplexen Verhalten aufweisen, wurden von vielen Autoren ausfuehrlich dokumentiert. Beide Techniken sind jedoch bei der Beschreibung eines einzelnen Algorithmus unuebertroffen, sofern dieser nicht zu lang oder umfassend ist.

Eine Darstellungstechnik, die in der Echtzeitwelt grosse Beachtung fand, ist das Zustandsveraenderungs-Diagramm. Es verfuegt ueber eine relativ gut ausgearbeitete formale Basis, und es ist ausfuehrbar. Mit Hilfe von Kaestchen lassen sich hier die verschiedenen Zustaende modellierter Systeme darstellen.

Direkte Verbindungen verknuepfen die Kaestchen und stellen damit die Veraenderungen zwischen den Zustaenden dar. Jede Veraenderung kann mit einem Ereignis bezeichnet werden. Wird ein solches empfangen, reagiert das System in Abhaengigkeit vom jeweiligen Zustand, indem es die fuer den Zustand und das Ereignis vorgegebene Veraenderung durchfuehrt.

Die Diagramme haben den Nachteil, dass saemtliche Zustaende des Systems als Knoten definiert werden muessen. Waehrend das Vorgehen fuer kleinere Systeme problemlos ist, wird bei groesseren bald die Grenze der Durchfuehrbarkeit erreicht, da die Anzahl der Zustaende exponentiell zunimmt. Um dieses Problem zu umgehen, definieren objektorientierte Methoden pro Klasse ein eigenes Zustandsveraenderungs-Diagramm. Damit ist es aber auch schwieriger geworden, sich ein Gesamtbild vom Verhalten zu machen.

Die Hauptunterschiede der variierenden Zustandsveraenderungsdiagramme liegt in der Handhabung von Aktionen. Der Ansatz des Mealy-Modells besteht darin, Aktionen mit Veraenderungen zu verknuepfen, so dass bei Eintreten einer Veraenderung eine Aktion ausgefuehrt wird. Danach befindet sich das System in den verschiedenen Zustaenden in Warteposition.

Ein feiner Unterschied

Das Moore-Modell verknuepft dagegen Aktionen mit Zustaenden: Erfolgt der Uebergang in einen neuen Zustand, wird eine Aktion ausgefuehrt. Der beschriebene Unterschied ist zwar fein, aber sehr wichtig, da fuer ein und dieselbe Situation unterschiedliche Diagramme erstellt werden.

Besonders deutlich treten die Unterschiede zutage, wenn die Zustandsveraenderungs-Diagramme fuer "Proposed Action" miteinander verglichen werden. Booch verwendet ein Mealy-Modell, Shlaer/Mellor dagegen ein Moore-Modell. Sofort faellt auf, dass im Shlaer/Mellor- Diagramm zwei zusaetzliche Zustaende eingefuehrt werden: Resuming (Fortsetzen) und Initiating (Starten).

Das von Booch entwickelte Modell benoetigt Bedingungsveraenderungen, wobei das Fortsetzungsereignis ausgehend vom jeweils unterbrochenen Zustand zu zwei verschiedenen Veraenderungen fuehren kann. Mit jeder Veraenderung muss eine Art Bedingung verknuepft sein, die angibt, welche Veraenderung aufzurufen ist.

Die bemerkenswerteste Erweiterung der Grundtypen bieten die Supra- und Subzustaende, wie Rumbaughs Proposed-Action-Version verdeutlicht. Sie ermoeglicht die Darstellung von Verhaltensweisen, die ueber die Grenzen eines Zustands hinausgehen, beispielsweise die Ereignisse "unterbrechen" und "abbrechen". Zudem wurde hier die Verknuepfung von Aktionen mit dem Diagramm verfeinert, so dass die Verarbeitung entweder mit Zustaenden oder mit Veraenderungen erfolgen kann.

Der Ansatz unterscheidet zwischen Aktionen, die im Rahmen des Modells als unmittelbar betrachtet werden, und Aktivitaeten, die eine betraechtliche Zeit beanspruchen. Aktionen sind mit Veraenderungen verknuepft und Aktivitaeten mit Zustaenden. Des weiteren koennen Aktionen mit dem Zustandein- oder -ausgang verknuepft sein. Die Handhabung von Aktionen, die den Beginn oder das Ende einer zeitlichen Aussetzung verursachen, wurde bei diesem Ansatz also sehr elegant geloest.

Aktionen (und Aktivitaeten) werden bei Rumbaugh und Booch durch Pseudocode naeher spezifiziert, bei Shlaer/Mellor durch Aktions- Datenflussdiagramme. Diese basieren auf den Echtzeit-Erweiterungen von Datenflussdiagrammen.

Die einfache Variante

Fuer jede Aktion im Zustandsveraenderungs-Diagramm wird ein einfaches, einschichtiges Aktions-Datenflussdiagramm vorbereitet, wobei Daten- und Kontrollstroeme zwischen Prozessen verwendet werden. Zur Handhabung des Bedingungsverhaltens existieren Bedingungs-Kontrollstroeme.

Beim Ansatz von Coad/Yourdon (1992) werden Zustaende auf eine wesentlich einfachere Art und Weise verwendet. Ein einfaches Zustandsveraenderungs-Diagramm (ohne Aktionen) dient lediglich dazu, die verschiedenen Zustaende zu ermitteln, die ein Objekt durchlaufen kann. So lassen sich Dienstleistungen, die eine Klasse anzubieten hat, auffinden. Jede dieser Serviceleistungen ist ein Algorithmus, der durch einen Ablaufplan beschrieben wird.

Sind Zustandsveraenderungs-Diagramme auf die einzelnen Klassen beschraenkt, so faellt es schwer, sich das Verhalten des gesamten Systems vorzustellen, das auf dem Zusammenspiel vieler Klassen basiert. Zur Loesung dieses Problems, liegen drei wesentliche Ansaetze vor.

Ein Weg besteht darin, das Problem im Rahmen der verhaltensbezogenen Modellbildung voellig ausser acht zu lassen. Dieser Ansatz beschreibt das Verhalten der Klassen untereinander nur in einem architektonischen Sinne. Hierbei werden die Nachrichten und Ereignisse, die Klassen einander schicken koennen, beschrieben. Doch es wird keinerlei Versuch unternommen, die Abfolge der einzelnen Nachrichten zu beschreiben. Es ist wichtig, festzuhalten, dass dieses Vorgehen die Praezision des Ansatzes nicht beeintraechtigt.

Der zweite Weg ist ein mechanismusbasierter Ansatz. Der Begriff "mechanism" wurde von Booch gepraegt, um die Instrumente zu beschreiben, mit denen das Zusammenspiel von Objekten erfolgt. Beschreibungen der Mechanismen werden neben dem Objektdiagramm geliefert - eine architektonische Sicht, die beschreibt, welche Nachrichten von Objekt zu Objekt geschickt werden. Booch fuehrt drei Arten der Beschreibung von Mechanismen aus: die Numerierung der Nachrichten entsprechend ihrer Abfolge, die Bereitstellung eines Pseudocodes und den Einsatz eines Zeitdiagramms, das eine diagrammatische Version des Mechanismus liefert.

Anschauliches Zeitdiagramm

Der anschaulichste Ansatz ist das Zeitdiagramm, das jedoch keine besonders gute Definition des Verhaltens bietet. Allerdings koennen Diagramme ueber Bedingungsverhalten erstellt werden. Der mechanismusbasierte Ansatz ist ebenfalls bei einer Reihe an-derer Methoden anzutreffen. Coad/Yourdon sprechen in diesem Zusammenhang von einem "service layer", Jacobson von "interaction diagram" und Rumbaugh von "event trace".

Nur Jacobson verwendet Pseudocode, so dass das Verhalten definiert und nicht nur beschrieben werden kann. Zurueckfuehren laesst sich das wahrscheinlich auf die weniger ausgepraegte Konzentration auf Zustandsveraenderungs-Diagramme.

Die Nachteile beim Mechanismuskonzept liegen zum einen im Fehlen eines diagrammatischen Konstrukts, das ausreichend Moeglichkeiten fuer einen umfassenden Einsatz von Computern bietet. Zum anderen beschreiben Mechanismen im wesentlichen Algorithmen und nur einen einzigen Kontrollstrom. Es besteht keine Moeglichkeit, Mechanismen zu kombinieren, um eine breitere Sicht des Systemverhaltens zu zeigen.

Im Gegensatz zu den anderen Methoden geht die von Martin und Odell entwickelte nur fluechtig auf Zustandsveraenderungs-Diagramme ein. Sie basiert auf dem Ereignisdiagramm. Anstelle von Zustaenden bestehen die wichtigsten Konstruktionsbloecke aus Ereignissen.

Operationen sind durch Trigger-Regeln verknuept

Ereignisse werden durch Operationen geschaffen, die durch Trigger- Regeln miteinander verknuepft sind - eine Struktur, die im Vergleich zum Aktions-Flussdiagramm von Shlaer/Mellor keine voellig kontraeren Merkmale aufweist. Das Ereignisdiagramm wird allerdings nicht fuer eine zustandsbasierte Aktion erstellt, sondern zur (potentiellen) Beschreibung des gesamten Systemverhaltens eingesetzt.

Zwar koennten Ereignisdiagramme wie Pseudocode auch zur Beschreibung von Zustandsveraenderungs-Aktionen oder -Mechanismen eingesetzt werden, doch liegt ihre grosse Staerke in der Faehigkeit, einen Schritt weiter zu gehen und Verhalten mittels vieler verschiedener interagierender Kontrollstroeme zu beschreiben.

Neben der Datensicht und der verhaltensorientierten Sicht auf das Objekt- und Klassenverhalten existiert noch eine dritte Sichtweise in den behandelten Modellen. Diese architektonische Sicht entspricht der Aufspaltung eines umfangreichen Systems in einzelne Komponenten.

Systeme werden mit Hilfe von Objekten aufgespaltet

Traditionell geschieht dies auf der Ebene der Funktionen: Eine Funktion einer hoeheren Stufe wird in Subfunktionen zerlegt, die wiederum weiter untergliedert werden, bis eine ausreichend tiefe Stufe erreicht ist. Bisher griff der Entwickler dazu auf Datenflusskonzepte zurueck, die sich nicht nur fuer die Beschreibung der Programmmodule, sondern auch fuer Daten, die zwischen diesen Modulen fliessen, eignen.

Mit der Entwicklung des objektorientierten Ansatzes kuendigte sich eine andere Moeglichkeit an: die Aufspaltung von Systemen mit Hilfe von Objekten anstelle von Funktionen. Unter den Autoren der analysierten Methoden gehen - mit Ausnahme von Rumbaugh und Martin/Odell - fast alle diesen Weg.

Waehrend Datenflussdiagramme in traditionellen Analysen breite Anwendung finden, setzt sie in objektorientierten Ansaetzen nur Rumbaugh ein: Ein System wird durch Funktionen beschrieben, und gespeicherte Daten werden durch Datenstroeme miteinander verbunden. Fuer Subfunktionen erfolgt so lange ein weiteres Aufspalten, bis die unterste Stufe erreicht ist. Hier wird die Verbindung zu den anderen Sichtweisen hergestellt. Die Funktionen auf der untersten Stufe entsprechen den Operationen der Datensicht.

Dieser Teil des Ansatzes von Rumbaugh trifft auf vehemente Kritik, und die meisten Praktiker scheinen Datenflussdiagramme zu ignorieren. In zahlreichen Spekulationen wurde die Frage laut, ob Rumbaughs Team ueberhaupt selbst mit Datenflussdiagrammen arbeitet.

Der von Martin/Odell entwickelte Ansatz ist zwar auch funktional, um das System jedoch in Aktivitaeten aufzuspalten, werden Objektflussdiagramme eingesetzt. Dabei konzentrieren sich die Autoren auf den Produkt- und Ressourcenstrom und weniger auf den Datenstrom.

Heraus kommt eine Kettenbeschreibung mit Wertsteigerung: Jede Aktivitaet erhoeht den Wert ihrer Ressourcen, um das Produkt daraus zu bilden. Dieses fungiert wiederum als Ressource fuer eine andere Aktivitaet.

Dieser Ansatz ist aeusserst hilfreich fuer die strategische Analyse auf hoeherer Stufe, bei der informationstechnologische Wege fuer grosse Organisationen entwickelt werden. Es handelt sich ausserdem um eine Technik, die sich mit anderen Ansaetzen kombinieren laesst. Allerdings ist die Anwendung fuer niedrigere Stufen nicht geeignet.

Der Ansatz der Objekt-Dekomposition beruht auf der Kommunikation von Objekten, die auf einer hoeheren Stufe angesiedelt sind. Ihre gegenseitige Verwendung erfolgt wie bei Objekten auf niedriger Stufe. Kommunikationsbeschreibungen ermitteln, auf welche Weise Objekte der hoeheren Stufe miteinander verbunden sind.

Booch haelt die Ergebnisse in einem Objektdiagramm fest, indem typische Objekte und die Nachrichten, die diese einander schicken koennen, dargestellt werden. Zeitliche Aspekte dieser Nachrichten (synchron, asynchron) lassen sich aufzeigen.

Shlaer/Mellor verwenden einen aehnlichen Ansatz, gliedern die Nachrichten jedoch in zwei Kategorien: Zugriffe, mit denen ein Objekt durch synchrone Uebertragung Informationen von einem anderen erhaelt, sowie Ereignisse, bei denen Objekte durch das asynchrone Senden von Ereignissen ein Verhalten in anderen Objekten ausloesen. Diese beiden Kommunikationskategorien werden in getrennten Diagrammen definiert.

Wirfs-Brock fuehrt dagegen ein Zusammenschlusskonzept (contract) ein: Nachrichtenaufrufe lassen sich kombinieren und zu Bloecken zusammenschliessen. Diese Massnahme daemmt die Komplexitaet eines Systems erheblich ein. Diagramme sind sowohl auf Klassen- als auch auf Subsystemebene zu finden, es erfolgt jedoch keine Unterscheidung zwischen synchronen und asynchronen Nachrichten.

Mit Hilfe der "Sichtbarkeit" laesst sich zeigen, ob Klassen und Subsysteme in der Lage sind, die Moeglichkeiten anderer Subsysteme zu nutzen, und wie sie aneinan-der anknuepfen koennen. Wirfs-Brock verwendet hier kein spezielles Konstrukt. Er definiert und kontrolliert die Sichtbarkeit vielmehr auf der Ebene des Zusammenschlusses.

Booch geht dagegen von einer kommunikationsbasierten zu einer sichtbarkeitsbasierten Sicht ueber und nimmt ausserdem eine klare architektonische Trennung zwischen logischer und physischer Sicht vor. Bei der logischen Sicht werden die Klassen Klassenkategorien zugeordnet, zwischen denen Sichtbarkeitsbeziehungen bestehen. Bei der physischen Sicht werden Klassen in Module und Subsysteme mit Sichtbarkeitsbeziehungen aufgespaltet. Es ist nicht klar, ob zwischen der Architektur der Klassenkategorien und der der Module Beziehungen bestehen.

Die Dokumentation nutzt Klassendiagramme

Shlaer/Mellor benutzen Diagramme, um die Sichtbarkeit auf hoechster Systemebene zu beschreiben, und zwar lediglich durch Definieren von Bereichen wie Schnittstellen oder Zeitfunktionen. Die beiden Autoren verwenden fuer die Dokumentation Klassendiagramme, wobei die Daten und Operationen mit Parametern und Rueckgabewerten eingetragen werden. Andere Diagramme zeigen den Daten- und Kontrollfluss sowie Nachrichten und die Vererbung zwischen den Klassen.

Coad/Yourdon gliedern die Klassen der Datensicht in Subjekte, um eine architektonische Sicht zu schaffen. Sie fordern dazu auf, diese Subjektbereiche im Rahmen des Systementwurfs als Grundlage zu verwenden, indem Klassen aus dem oberen Bereich der Subtypen- oder Aggregationshierarchie gewaehlt werden. Fuer Nachrichten beziehungsweise die zwischen ihnen bestehende Form der Sichtbarkeit schlagen sie keine spezielle Notation vor.

Martin Fowler vergleicht in einem dreiteiligen Beitrag die gaengigsten objektorientierten Methoden.

- Teil 1 stellte sieben verschiedene Ansaetze vor.

- Teil 2 untersuchte die unterschiedlichen Objektmodelle auf ihre Tauglichkeit zur Beschreibung von Daten und Klassen.

- Teil 3 dokumentiert verschiedene Techniken, mit denen sich das Objektverhalten und die Systemkomponenten beschreiben lassen.

Literatur:

- Booch, G. (1991): Object-Oriented Design with Applications, Benjamin/Cunnings, Redwood City, Ca.

- Coad, P. und Yourdon, E. (1991): Object-Oriented Analysis (zweite Ausgabe), Prentice-Hall. Coad, P. und Yourdon, E. (1991): Object-Oriented Design, Prentice-Hall.

- Jacobson, I., Christerson, M., Jonsson, P. und Oevergaard, G. (1992): Object-Oriented Software Engineering: a use case driven approach, Addison-Wesley.

- Martin, J. und Odell, J. (1991): Object-Oriented Analysis and Design, Prentice-Hall. Martin, J. und Odell, J. (1994): Principles of Object-Oriented Analysis and Design, Prentice-Hall.

- Rumbaugh, J., Blaha, M., Premerlani, W., Eddi, F. und Lorensen, W. (1991): Object-Oriented Modeling and Design, Prentice-Hall.

- Shlaer, S. und Mellor, S. J. (1988): Object-Oriented Systems Analysis: Modeling the World in Data, Prentice-Hall. Shlaer, S. und Mellor, S. J. (1991): Object Life Cycles: Modeling the World in States, Prentice-Hall.

- Wirfs-Brock, R., Wilkerson, B. und Wiener, L. (1990): Designing Object-Oriented Software, Prentice-Hall.