Angesichts der Probleme bei der Umsetzung objektorientierter Paradigmen stehen entsprechende Methoden und Modelle hoch im Kurs. Leider bleibt fuer die Anwender in der Regel voellig undurchschaubar, welche Vorgehensweise fuer sie die geeignete sein koennte. Daher unternimmt Martin Fowler* den Versuch, die Staerken und Schwaechen der am Markt befindlichen Methoden herauszuarbeiten. Im ersten Teil dieses dreiteiligen Beitrags gibt er eine kurze Beschreibung und Bewertung der verschiedenen Ansaetze, um sie dann in einem Teil nach Problemfeldern zu analysieren.

Modelle stellen eine Moeglichkeit dar, die Welt zu beschreiben, doch Modellbildungstechniken machen nur einen Teil des Analyse- und Entwurfsprozesses aus. Jede Methode stellt Techniken zur Verfuegung, die im Rahmen von Analyse und Entwurf die Erarbeitung von Modellen unterstuetzen. Hierfuer gibt es aber keine formalen Schritte. Vielmehr sind Analyse und Entwurf weitgehend mit der Zubereitung von Speisen vergleichbar: Das Rezept ist ein erster Schritt, aber nicht der gesamte Vorgang. So fungieren die Richtlinien, die den Methoden zugrunde liegen, als ein Weg der Konzentration auf die Modellbildung.

Die meisten objektorientierten Autoren lehnen das Konzept fix und fertig vorgegebener Stufen ab. Uebereinstimmend sind sie der Meinung, dass eine Technik zwar so beschrieben wird, als handle es sich um Stufen, dass der tatsaechliche Weg jedoch vielmehr einer Spirale aehnelt.

So besteht der auffaelligste Gegensatz in den Unterschieden zwischen dem datenmodellgesteuerten, dem ereignisgesteuerten und dem szenariogesteuerten Ansatz. Die groesste Uebereinstimmung herrscht hinsichtlich des iterativen Charakters des Prozesses sowie in bezug auf das Ende des Wasserfallmodells bei der Software-Entwicklung.

Der vorherrschende Weg, um den Analyseprozess in Gang zu setzen, fuehrt ueber die Entwicklung der Datensicht: der datengesteuerte Ansatz (data-driven approach). Dabei wird die Datensicht mit der Bildung von Subtypen, Assoziationen und Operationen zuerst entwickelt. Die Unterschiede zwischen einzelnen Varianten sind relativ gering. James Rumbaugh weist darauf hin, dass das Datenmodell zuerst zu entwickeln ist, gefolgt von Zustands- und Datenflussmodellen. Bei Grady Booch liegt der Schwerpunkt auf der Entwicklung von Mechanismen zusammen mit dem Datenmodell. Peter Coad und Ed Yourdon raeumen der Aggregation und der Bildung von Subtypen bei der Entwicklung des Datenmodells Prioritaet vor der Beruecksichtigung von Assoziationen ein.

Die Gefahr beim datengesteuerten Ansatz wie auch bei traditionellen Datenmodellen liegt in der Schwierigkeit zu erkennen, wann es aufzuhoeren gilt. Die Unfaehigkeit, zu sehen, wann genug getan wurde, macht datengesteuerte Ansaetze besonders anfaellig fuer zeitliche Verzoegerungen.

Durch ihre Erfahrungen im Bereich des Information-Engineerings sind James Martin und Jim Odell mit diesem Problem bestens vertraut. Ihre Methode beschreibt eine ereignisgesteuerte Technik (event-driven technique) zur Erfassung des Verhaltens und zur Entwicklung der Datensicht. Bei dieser Technik wird ein Zielereignis bestimmt und mit Hilfe von Datensichttypen formal definiert. Fuer das Ereignis und die es definierenden Typen wird ein entsprechender allgemeiner, uebergeordneter Typ (Supratyp) bestimmt und die Ursachen fuer das Ereignis analysiert. Diese Ursachen gliedern sich entsprechend einem logischen Muster und sind als Ereignisse beschreibbar. Jedes auf diese Weise erkannte Ereignis kann so als weiteres Ausgangsereignis fuer den beschriebenen Prozess dienen.

Praktiker sind der Ansicht, dass - obwohl diese Abfolge in der Regel nicht strikt beibehalten wird - der Prozess der gleichzeitigen Modellbildung fuer Ereignisse und Daten das Problem des Anwendungsbereichs der datengesteuerten Analyse erheblich vereinfacht.

Problematisch ist allerdings die Abbildung dieses Datenmodells auf die vom Benutzer anerkannten Schnittstellen. Die Art und Weise der Interaktion zwischen Benutzer und System bildet den Schwerpunkt des szenariogesteuerten Ansatzes (scenario-driven approach) von Ivar Jacobson und Alan Wirfs-Brock.

Dabei werden typische Verwendungsarten eines Systems durchgespielt. Jacobson stellt sie formal als Anwendungsfaelle (use-cases) dar. Sie bilden die Grundlage seines Ansatzes. Jeder Anwendungsfall wird beschrieben und dann mittels eines Analysemodells modelliert. Anwendungsfaelle werden darueber hinaus auch verwendet, um Strukturtests durchzufuehren.

Wirfs-Brock entwirft mit Karten ganze Szenarios

Um die "responsibilities" (Aufgaben) eines Systems zu ermitteln, arbeitet Wirfs-Brock mit "Walk-throughs", die er Klassen zuordnet. Nachdem eine angemessene Detailstufe definiert ist - hierzu empfehlen die Autoren die Verwendung von Karten - lassen sich die Interaktionen zwischen den Klassen bei ihrer Ausuebung als "collaborations" (Zusammenarbeit) beschreiben. Dabei entstehen Szenarios. Anhand des Modells koennen diese dann durchgespielt werden, um die Aufgaben wie auch die collaborations zu verfeinern. Dieses Modell wird im Gegensatz zu den meisten anderen Techniken nicht mit Hilfe eines Diagramms beschrieben, sondern durch eine Ansammlung von Karteikarten. Erst nach Erarbeitung der re- sponsibilities und der collabora-tions entsteht im "CRC-Diagramm" (Cyclic Redundancy Code) die architektonische Sicht.

Der Vorteil des Entwurfs liegt darin, dass keinerlei Datenstruktur vorgegeben ist und auf diese Weise das Konzept der Kapselung Eingang in den Analyse- und Entwurfsprozess findet. Bisher liegen jedoch noch keine ueberzeugenden Hinweise darauf vor, dass es sinnvoller ist, die Analyse auf diesem Wege anzugehen.

Der szenariogesteuerte Entwurf orientiert sich eng an der Verwendung des Systems. Dies kann jedoch ebenso leicht nachteilig wie vorteilhaft sein. Die Gefahr des szenariogesteuerten Ansatzes besteht moeglicherweise darin, dass ein System zu sehr auf aktuelle Beduerfnisse ausgerichtet ist, was die langfristige Flexibilitaet gefaehrdet.

Zudem koennte eine Konzentration auf die gegenwaertige Arbeitsweise der Benutzer zur Folge haben, dass die Analyse Moeglichkeiten der DV-gestuetzten Arbeitsprozess-Umstrukturierung ausser acht laesst. Grundsaetzlich kann eine Veraenderung von Arbeitsprozessen bedeutend groessere Vorteile bieten als der blosse Einsatz von Computern. Da sich daten- und ereignisgesteuerte Techniken auf den wesentlichen Prozess und nicht auf die Benutzerinteraktion konzentrieren, eignen sie sich besser dazu, im Rahmen des Entwurfs ineffiziente aktuelle Praktiken auszuklammern.

Auch die Beziehung von Analyse und Entwurf klammern die Autoren in der Regel nicht aus. Coad und Yourdon betonen, dass sich die Analyse mit der Komponente des Problembereichs befasst, waehrend der Entwurf andere Komponenten betrachtet. Dies deuten auch andere Autoren an. Rumbaugh schlaegt einen drei Schritte umfassenden Prozess der Analyse, des architektonischen Entwurfs und des detaillierten Entwurfs vor.

Bei Jacobson findet sich der am staerksten strukturierte Ansatz: das Analysemodell aus Entitaet, Schnittstelle und Kontrollobjekten wird zu einem auf Bloecken basierenden Entwurfsmodell. Urspruenglich besteht eine Eins-zu-eins-Beziehung zwischen beiden, doch im Laufe der Entwurfsentwicklung werden Aenderungen vorgenommen, die die Beduerfnisse der Implementierungsumgebung widerspiegeln. Systemverhalten, Verwendungsmechanismus und zustandsbasierte Techniken werden nur in dieser Phase beruecksichtigt, nicht waehrend der Analyse. Sally Shlaer und Stephen Mellor stellen einen von ihnen als rekursiven Entwurf (recursive design) bezeichneten Ansatz vor. Dieser betont die Verwendung einer Reihe von Entwurfsregeln, um das Analysemodell auf praezise und wiederholbare Weise in einen Entwurf zu ueberfuehren. Dadurch wird es einfacher, in grossen Systemen Konsistenz zu wahren. Es liegt leider nur wenig Material ueber die Festlegung dieser Regeln vor, und die Entwurfsnotation, weithin vergleichbar mit Strukturablaufplaenen, verschleiert die Verbindungen zwischen Analyse und Code.

Die Booch-Methode: Der Name Grady Booch gehoert in der Welt des objektorientierten Entwurfs zu den am laengsten bekannten. Boochs vielzitierte einschlaegige Ausfuehrungen wurden 1986 veroeffentlicht. Seit jener Zeit widmete er seine Aufmerksamkeit zum grossen Teil der ADA-Welt, beschreibt in seinem neuen Buch allerdings seinen objektorientierten Analyse- und Entwurfsansatz.

Merkmal der Datensicht sind Entity-Relationship-Diagramme (ER), die hier Klassendiagramme (class diagrams) genannt werden. Dynamische Veraenderungen werden mit Hilfe eines Zustandsveraenderungsdiagramms innerhalb einer Klasse dargestellt. Zeit- und Objektdiagramme zeigen die Interaktionen zwischen Objekten.

Die Darstellung der logischen Architektur erfolgt mit Hilfe von Objektdiagrammen und Klassenkategorien, fuer die eine Objektdekomposition vorgenommen wird. Der physische Entwurf wird mittels Modul- und Prozessdiagrammen dargestellt.

Die Objektdiagramme dienen sowohl der Darstellung der Objektdekomposition als auch des Verhaltens der Objekte untereinander. Neuere, vom Booch-Unternehmen (Rational Inc.) veroeffentlichte Dokumentationen beschreiben eine Reihe von Aktualisierungen.

Alles in allem bietet Boochs Methode durch eine breite Palette an Techniken ein grosses Mass an Flexibilitaet, besonders im Umgang mit dem Zusammenspiel von Systemen. Durch die Vielfalt an Techniken wird die Anwendung der Methode allerdings auch erschwert, da in keiner Weise ersichtlich ist, wie die Techniken fuer verschiedene Problemtypen optimal zu kombinieren sind. Eine Hilfe bieten die fuenf detaillierten Beispiele im Buch. Im Endeffekt jedoch fuehlt sich der Leser moeglicherweise von den Techniken ebenso erdrueckt wie von der sehr umfangreichen Bibliografie.

Coad/Yourdon-Methode: Coad und Yourdons erstes Buch ueber die objektorientierte Analyse traf in der Szene bei vielen Lesern auf vehemente Kritik. Nach allgemeiner Auffassung war das Werk nicht strikt genug, trennte Klassen und Objekte nicht klar voneinander und ging nur wenig ueber die ER-Modellbildung hinaus. Die zweite Ausgabe jedoch stellt in vielerlei Hinsicht ein komplett neues Buch dar und hat manches zu bieten.

Coad/Yourdon fasst ganze Systeme in ein Diagramm

Herzstueck der Technik ist nach wie vor die Datensicht mit ER- Diagrammen. Diese zeichnet sich nun durch Aggregation sowie Assoziationen und die Bildung von Subtypen aus. Verhalten wird ausgedrueckt, indem Operationen fuer die Klassen benannt und innerhalb der Klassen duch Zustandsveraenderungs- und Ablaufplaene ("service charts", Serviceplaene) definiert werden.

Das Verhalten der Objekte untereinander wird durch Nachrichtenverbindungen im ER-Diagramm dargestellt. Die Architektur wird durch Zusammenfassen von Klassen zu Subjekten definiert. Diese Gruppen erscheinen auch im ER-Diagramm. Somit wird fast das gesamte System in einem einzigen Diagramm beschrieben, wobei dieses als aus mehreren Schichten bestehend betrachtet werden muss, so dass der Leser die entsprechende Systemsicht waehlen kann. Dieser Ansatz besticht durch seine Einfachheit, ist jedoch bei Anwendung in groesseren Systemen schwer zu handhaben.

Die groesste Staerke dieser Methode liegt in ihrer Einfachheit, die gleichzeitig leider auch ihre wesentliche Schwaeche darstellt. Allgemein wird die Auffassung vertreten, dass die Methode sich zwar fuer eine fruehe Anwendung eignet, in einem groesseren Projekt aber nicht effektiv einsetzbar ist.

Jacobson-Methode (OOSE): In der objektorientierten Welt ist "Objectory" seit langem ein bekannter Begriff. Es handelt sich um eine Methode der Software-Entwicklung, die von Objective Systems in Schweden unter der Leitung von Ivar Jacobson entwickelt wurde. Leider konnten detaillierte Informationen ueber den Ansatz nie problemlos in Erfahrung gebracht werden, zumindest nicht ohne Zahlung einer betraechtlichen Lizenzgebuehr. Diese Situation aenderte sich mit Erscheinen des von Jacobson veroeffentlichten Buches.

Darin wird die objektorientierte Software-Entwicklung mit Hilfe der OOSE-Methode (Object-Oriented Software Engineering), einer abgespeckten Version von Objectory, beschrieben.

Das charakteristische Merkmal der Methode Jacobsons ist die starke Konzentration auf Anwendungsfaelle (use-cases): ein Szenario, in dem ein Akteur, beispielsweise ein Benutzer, das Computersystem verwendet. Analyse, Entwurf und Test werden gaenzlich durch den Anwendungsfall gesteuert. Darauf baut Jacobson eine Beschreibung des Prozesses von Analyse und Entwurf auf, die zu den strukturierteren gehoert.

Jacobson konzentriert sich auf Anwendungsfaelle

Ein weiteres, einzigartiges Merkmal ist die Klassifizierung von Analyseobjekten in Entitaet, Schnittstelle und Kontrollobjekte. Dies foerdert einen separaten und dennoch gut integrierten Weg aus der Einbindung von Verarbeitungs- und Benutzer-Schnittstellen in den Systementwurf.

Das Buch ist umfangreich und etwas langatmig. Seine Staerken liegen in der Behandlung von allgemein vernachlaessigten Bereichen, zum Beispiel von Tests, sowie in Beschreibungen der Art und Weise, wie die Methode auf Echtzeitsysteme und -datenbanken zugeschnitten werden kann. Isoliert betrachtet sind die einzelnen Techniken im Vergleich zu anderen Methoden schwach. Als Ganzes ist der Ansatz jedoch nicht zu unterschaetzen.

Martin/Odell-Methode (OMW und Ptech): Das von James Martin und Jim Odell veroeffentlichte Buch zum Thema objektorientierte Analyse und Entwurf ist hinsichtlich seiner Entstehungszeit rekordverdaechtig. Es stuetzt sich in grossem Masse auf Techniken, die urspruenglich von John Edwards entwickelt und dann von Jim Odell erweitert wurden.

Das Werk gliedert sich in zwei separate Teile: Die ersten Kapitel behandeln James Martins Sicht der zukuenftigen Software- Entwicklung, die nachfolgenden konzentrieren sich auf die Analysemodelle und -methoden. Leser mit entsprechendem technischen Hintergrund verlieren bei den ersten Kapiteln moeglicherweise das Interesse, sollten sich dadurch jedoch nicht von der Lektuere der darauffolgenden Abschnitte abschrecken lassen.

Bei der Datensicht liegt der Schwerpunkt mehr auf einem binaeren Ansatz der Datenmodellierung als auf ER-Diagrammen. Freiraum ist allerdings fuer beides vorhanden. Die Methode ist insofern von Bedeutung, als dass sie sich durch eine formale Untermauerung der Klassenmathematik und einen starken philosophischen Einfluss auszeichnet. Dies fuehrt zu einer eleganten Handhabung der Subtypenbildung, der Unterstuetzung von Klassenausdruecken, abgeleiteten Assoziationen und dynamischer Klassifikation. So wechseln Objekte im Laufe ihrer Existenz die Klasse.

Systemverhalten wird mit Hilfe von Ereignisdiagrammen definiert, durch die es sich in einem kompakten Diagramm ausdruecken laesst. Die Ereignisse sind formal mit der Datensicht verknuepft. Mit den CASE- Tools lassen sich die Ereignisdiagramme durch Kompilieren in ausfuehrbaren Code ueberfuehren.

Die Handhabung der Architektur erfolgt mit Hilfe von Objektflussdiagrammen, bei denen eine funktionale Dekomposition verwendet wird, gesteuert durch eine erweiterte Kettendarstellung. Diese Technik hilft bei der strategischen Analyse, bietet hinsichtlich der Modellbildungs-Architektur jedoch nicht die Moeglichkeiten anderer Methoden. Beachtung verdient der Analysetyp wegen der Foerderung eines ereignisgesteuerten Ansatzes, bei dem zuerst Ereignisse ermittelt werden, die sich dann zum Definieren von Klassen verwenden lassen.

Die Methode von Martin/Odell ist insofern ungewoehnlich, als sie aus einer philosophischen Analysehaltung heraus entwickelt wurde und somit hinsichtlich der Methodik viele Denkanstoesse liefert. Der Ansatz zeichnet sich durch ein hohes Mass an Kohaesion zwischen den Techniken sowie durch die der Semantik gewidmete Aufmerksamkeit aus. Allerdings geht aus dem Buch nicht eindeutig hervor, wie alle diese Ideen zu verknuepfen sind.

Rumbaugh-Methode (OMT): Rumbaughs Technik der Objektmodellbildung (Object Modelling Technique) wurde in den Forschungslabors von General Electrics, USA, entwickelt. Bei der Methode werden drei Techniken verwendet: Objektdiagramme (eine Form von ER-Diagrammen) fuer die Datensicht, Harel-Zustandsablaufplaene fuer das Verhalten und Datenflussdiagramme fuer die Architektur.

Die ER-Technik bietet besonders viele Moeglichkeiten: Sie unterstuetzt untergliederte und nicht untergliederte Subtypen, abgeleitete Objekte und Beziehungen sowie die Aggregation. Die Zustandsablaufplaene bieten unter den betrachteten Methoden die leistungsfaehigste Bildung von Zustandsveraenderungsmodellen. Die Datenflussdiagramme betonen die Verbindung zu Objekten durch Dekomposition, so dass untere Blasen (bubbles) Operationen mit Klassen darstellen.

Rumbaugh benutzt bei seinem Ansatz Techniken, die bereits von der strukturierten Analyse her bekannt sind, und kombiniert diese sinnvoll miteinander. Leser, die strukturierte Ansaetze kennen, meinen eventuell, dass die bei den Unterschieden anzutreffenden Feinheiten einer gewissen Anpassung beduerfen, werden sich im allgemeinen aber daran gewoehnen. Das Werk ist ein abgerundetes Buch ueber die objektorientierte Modellbildung. Es bietet Details zur Implementierung in einer Reihe von Umgebungen, darunter auch die nicht objektorientierten.

Shlaer/Mellor-Methode: Das erste zum Thema objektorientierte Analyse und Entwurf veroeffentlichte Buch war das von Shlaer und Mellor. Es konzentrierte sich auf die Datensicht und galt gemeinhin als Buch ueber die Datenmodellbildung, das spaeter um objektorientierte Konzepte ergaenzt wurde. Das zweite Buch, das den Lebenszyklus von Objekten behandelt, beruecksichtigt auch verhaltensbezogene und architektonische Sichtweisen. Bei der von Shlaer und Mellor entwickelten Methode erfolgt die Modellbildung fuer Klassen im Rahmen der Datensicht, die Assoziationen und die Bildung von Subtypen ermoeglicht.

Jeder Klasse wird dann ein Zustandsdiagramm zugeordnet, das den Lebenszyklus beschreibt. Aktionen, die fuer diese definiert werden, lassen sich entweder durch Pseudocode oder mittels eines Aktions- Datenflussdiagramms definieren, das als Prozess-Prioritaetsdiagramm fungiert.

Zwischen Klassen liegen Nachrichtenverbindungen. Diese gliedern sich in asynchrone Ereignisse und synchrone Anfragen und dienen dem Aufbau der architektonischen Sicht. Diese nachrichtenbasierten Modelle finden bei der Beschreibung von Subsystemen erneut Verwendung: Auf hoechster Ebene werden mittels Sichtbarkeitsbeziehungen oder Bruecken (visibility relationships, bridges), die dazwischen liegen, Bereiche definiert.

Mit Hilfe des Begriffs OODLE laesst sich dagegen die Entwurfsseite mit detaillierten Diagrammen fuer Klassen und deren Interaktionen beschreiben. Darin liegt zugleich ein Nachteil der Methode, denn ein wesentlicher Vorteil der objektorientierten Modellbildung besteht gerade im klaren Uebergang von der Analyse zum Entwurf.

Shlaer/Mellor definieren Nachrichtenverbindungen

Darueber hinaus praegt den Ansatz von Shlaer und Mellor der Begriff des rekursiven Entwurfs (recursive design). Um ein Modell formal in ein funktionierendes System zu ueberfuehren, wird die Entwicklung von Entwurfsregeln angeregt. Diese sind abhaengig von der Analysemethode und der Entwicklungsumgebung. Leider geht keines der Buecher naeher auf diesen Ansatz ein.

Wirfs-Brock-Methode (CRC, RDD): Die Wirfs-Brock-Methode - auch CRC-Methode (Classes, Responsibilities, Collaborations) oder RDD- Entwurf (Responsibility Driven Design) genannt - ist unter den momentan vorgestellten Ansaetzen sicherlich der ungewoehnlichste. Im Gegensatz zu allen anderen Methoden, die auch auf einer ausgepraegten Datensicht basieren, verzichtet Wirfs-Brock komplett auf die Datenmodellierung und verwendet nur einen einfachen Vererbungsgraphen.

Die Technik konzentriert sich auf die Beschreibung des Systems mittels responsibilities (Aufgaben), die von Klassen uebernommen werden. Diese Aufgaben dienen dazu, collaborations (Zusammenarbeit) zwischen Klassen zu beschreiben, die schliesslich formal zu einer architektonischen Sicht zusammengefuegt werden. Eine verhaltensbezogene Sicht wird nicht verwendet. Das Konzept der responsibilities stiess bei den meisten Fachleuten auf Zustimmung, und die urspruenglichen Wirf-Brock-Techniken der Klassenermittlung werden allgemein als empfehlenswert eingestuft.

Wirfs-Brock verzichtet auf Datenmodellierung

Ein wesentlicher Reiz der Technik liegt darin, dass die versteckte Datenstruktur und die Verwendung von Aufgaben das Konzept der Kapselung (encapsulation) in die Analyse- und Entwurfsanstrengungen einbringt. Andere Techniken betrachten die Kapselung mehr als ein detailliertes Entwurfskonzept.

Die Frage, die sich zu diesem Ansatz stellt, ist folgende: Ist eine effiziente Systembeschreibung besonders bei groesseren Systemen moeglich, ohne ein Datenmodell zu definieren? Dieser Punkt ist dann wichtig, wenn beruecksichtigt wird, dass Datenmodelle den Schwerpunkt auf eine Datensicht legen, deren Verwendung von Veraenderungen unberuehrt bleiben soll. In dieser Hinsicht laesst sich die Technik von Wirfs-Brock mit der prozessgesteuerten Modellbildung vergleichen. Eine Veraenderung der Anforderungen birgt die Gefahr einer fundamentalen Modellaenderung.

(wird fortgesetzt)

Literatur:

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

- 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 Analysisand Design, Prentice-Hall. Martin J. und Odell J. (1994): Principles of Object-Oriented Analysis and Design, Prentice-Hall.

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

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

Modelingthe World in States, Prentice Hall.

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

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

- Teil 1 stellt sieben verschiedene Ansaetze vor.

- Teil 2 untersucht 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.

*Martin Fowler ist als Unternehmensberater in Europa und den USA taetig.

Der Aufsatz erscheint als Kapitel 6 in: Object Development Methods, hrsg. von Andy Carmichael, SIGS Books, New York 1994. Er wurde im Auftrag der CW von Diplom-Uebersetzerin Petra Brandt, Wolfsburg, ins Deutsche uebersetzt.