Objektorientiertes Analyse

Inhaltsverzeichnis

0.  Einleitung - Phasenmodelle

1.  Das Entity Relationship-Modell-Information Modeling

1.1  Begriffe und Notation

2.  Zustandsdiagramme - Lebenszyklen von Informationsobjekten

3.  Strukturierte Analyse

  3.1  Datenflußdiagramme

  3.2  Prozeßspezifikation

  3.3  Data Dictionary

4.  Objektorientierte Analyse

  4.1  Motivation

  4.2  Objektorientierung - Begriffe

  4.3  OOA-Einführung

  4.4  Festlegung von Klassen und Objekten

  4.5  Identifizierung der Strukturen

  4.6  Identifizierung von Subjekten

  4.7  Definition von Attributen

  4.8  Definition von Methoden

0. Einleitung - Phasenmodelle

Zur industriellen Herstellung von SW werden in der Literatur mehrere Phasenmodelle vorgestellt, also Modelle, die vorsehen, die Entwicklung der SW in einer bestimmten Anzahl von Schritten zu realisieren. Sehen wir uns dazu zuerst einmal die klassischen Phasen und ihre Aufgaben an, und danach die diversen Phasenmodelle.

* Analyse: In dieser Phase wird ein Ist-Modells des relevanten Realitätsausschnittes erstellt. Es wird geklärt, was die SW zu leisten hat (nicht wie sie es zu leisten hat!). Als Methoden eignet sich die Entity Relationship-Modellierung, die Strukturierte Analyse oder die OOA.

* Design: In dieser Phase werden die Ergebnisse der Analyse um lösungsspezifische Komponenten erweitert, es wird also geklärt, wie die Anforderungen der Analyse zu erreichen sind. Hier steht die Benutzerführung, die Hardware und das Datenhandling im Mittelpunkt. Im Gegensatz zur Analysephase können die Ergebnisse nun nicht mehr systemunabhängig sein.

* Implementation: In dieser Phase werden die Ergebnisse des Designs (und der Analyse) in eine Programmiersprache umgestezt.

* Test: In dieser Phase wird die Brauchbarkeit und Korrektheit des SW-Produktes überprüft. Wichtig sind v.a. Akzeptanztests bei den späteren Endanwendern.

* Wartung: Ddiese Phase bleibt während des gesamten Produktlebenszyklus bestehen und kann einen Großteil der Entwicklungskosten verschlingen. Es gilt: je genauer analysiert und designed wurden, um so geringer fällt die nötige Wartung aus.

(1) Wasserfallmodell (Boehm): Bei diesem Modell werden die Phasen sequentiell durchlaufen, wobei zwar Rückkopplungen im Prinzip vorgesehen sind, aber aus Kostengründen so selten als möglich durchgeführt werden sollten - schließlich fließt Wasser normalerweise auch nicht bergauf.

(2) Spiralenmodell (Boehm): Bei diesem Modell werden alle Phasen wie beim Wasserfallmodell sequentielle durchlaufen, dies aber immer wieder so oft wie nötig, d.h. nach der Testphase wird erneut analysiert. Zu direkten Rückkopplungen kommt es hierbei nicht.

(3) Fontänenmodell: Bei diesem Modell wird die Sequentialität aufgehoben und explizit Überscheidungen zwischen den Phasen zugelassen, d.h. das Design beginnt, während die Analyse noch in Arbeit ist, so daß Designergebnisse die Analyse beeinflussen können. Dazu ist es wichtig, daß die Ergebnisse der einzelnen Phasen untereinander kompatibel sind - eine Forderung, die der obbjektorientierten Entwicklung bereits sehr nahe kommt.

(4) objektorientierte Entwicklung: Im Gegensatz zu den funktionalen Ansätzen können bei diesem Modell wegen der Methodenhomogenität alle Phasenergebnisse direkt in die nächste Phase übernommen werden, wo sie jeweils phasenspezifisch erweitert werden.

1. Das Entity Relationship-Modell-Information Modeling

Das ERM von Chen dient zur Beschreibung von Daten und ihren STATISCHEN Beziehungen untereinander. Es besitzt den großen Vorteil, daß darauf hierarchische, netzwerkartige, relationale und sogar objektorientierte Datenmodelle aufbauen können.

1.1 Begriffe und Notation

Wir unterscheiden nach Shlaer/Mellor bei ERMs folgende Begriffe:

* Entity: eindeutig identifizierbares Objekt, z.B. "Dagobert"

* Entity-Set: eine Menge gleichartiger Entities, z.B. "Comic-Figuren"

* Attribut: typische Eigenschaft von Entity-Set-Entities

* Schlüssel: minimale und identifizierende Attributeausprägung eines Entities

* Referential Attribute: Schlüssel eines anderen Beziehungs-Entity-Sets

* Relationship-Set: Verknüpfung zweier (verschiedener) Entity-Sets

* 1:1-Relationship-Set: bijektive, binäre Entity-Verknüpfung

* 1:M-Relationship-Set: ein Entity ist mit vielen Entities verknüpft

* N:M-Relationship-Set: viele Entities sind mit vielen Entities verknüpft

* konditionaler Relationship-Set: ein Entity ist nicht an der Beziehung beteiligt

* Supertyp: generalisierter Entity-Set einer "is a"-Beziehung

* Subtyp: spezialisierter Entity-Set einer "is a"-Beziehung

Grafische ERM-Darstellung nach Shlaer/Mellor:

* Entity-Set: Rechteck mit enhaltenden Objektname und Attributen

* Attribut: stehen in Entity-Sets mit vorangehendem Punkt

* Schlüssel: wie Attribut, nur statt eines Punktes ein Stern

* Referential Attribute: wie Attribut, nur mit nachstehenden r in Klammer

* Relationship-Set: Verbindungslinie zwischen den Entity-Sets

* 1:1-Relationship-Set: Doppelpfeil

* 1:M-Relationship-Set: Doppelpfeil mit einseitiger Doppelspitze

* N:M-Relationship-Set: Doppelpfeil mit Doppelspitzen und Raute in der Mitte

* konditionaler Relationship-Set: C über Pfeilspitze ggü. des beziehungslosen Entity

* Super-/Subtyp-Relationship-Set: Linienverbund mit gerader Linie am Kopf

Die Modellierung des 1:1-Relationship-Sets, z.B. zwischen "Kunde" und "Konto", verlangt die Aufnahme eines referentiellen Attributes, z.B. "Kundennummer", in einem der beteiligten Entiy-Sets. Bei der Umsetzung von 1:M-Relationship-Sets geschieht das gleiche, nur daß hier in jedem Fall das Entity-Set das referential Attribut erhält, daß in der Beziehung mehrfach vorkommt. Bei N:M-Beziehungen dagegen kann man auf das referentielle Attribut verzichten, kommt dafür aber nicht umhin, einen neuen Entity-Set zu bilden, dessen Attribute den Schlüsseln der beteiligten Entity-Sets entsprechen. Diesen neuen Entity-Set nennt man auch Korrelationstabelle oder Beziehungs-Entity-Set. Zu beachten ist noch, daß 1:1c-Beziehungen verlangen, daß das referentielle Attribut dem Entity-Set zuzuordnen ist, der an jeder Beziehung teilnimmt. Und 1c:1c-Beziehungen können zuguterletzt ebenso gut über referentielle Attribute realisiert werden wie über Korrelationstabellen.

Zur Spezifikation der Entity-Sets und der Relationship-Sets als unverzichtbarer Bestandteile des Information Modelings werden von Shlaer/Mellor zwei Dokumente vorgeschlagen:

(1) Entity-Spezifikation:

1.	Entity(Attribute)			1.	Seminar(Thema, Zeit, Ort)

	Schlüssel: ...					Schlüssel: Thema+Zeit

	Beschreibung: ...				Beschreibung: ...



1.1	Entity.Attribut1			1.1	Seminar.Thema

	Beschreibung: ...				Beschreibung: ...

	Typ: ...					Typ: String

	Wertebereich: ...				Wertebereich: uneingeschränkt

1.2	...

(2) Relationship-Spezifikation:

1.	Entity1 VERB1 Entity2		1.	Betreuer BETREUT Arbeit (1:Mc)

	Entity2 VERB2 Entity1			Arbeit WIRD BETREUT VON Betreuer

	Beschreibung: ...			Beschreibung: ...

2. Zustandsdiagramme - Lebenszyklen von Informationsobjekten

Im Rahmen des information Modelings werden die Daten eines Systems und ihre Strukturen nur statisch beschrieben; die DYNAMISCHE Sicht auf die daten wird durch Zustandsdiagramme (State Transition Diagrams, STDs) modelliert. Die möglichen Zustände, die ein Entity im Laufe seines "Lebens" annehmen kann, werden hierbei durch die folgenden vier Komponenten pro Entity-Set gekennzeichnet:

(1) Zustand: ein Zustand repräsentiert eine Situation, in der die Eigenschaften des Obhjekts einen definierten Wert besitzen. Grafisch dargestellt wird dies durch ein Rechteck mit dem Zustandsnamen inseitig, z.B. "Warten auf Eingabe".

(2) Zustandsübergang: Objekte können ihrern Zustand in einen bestimmten anderen Zustand ändern. Welche anderen Zustände dies sein können, wird durch Pfeile zwischen den Zuständen symbolisiert.

(3) Ereignis: bevor ein Objekt seinen Zustand ändert, muß mindestens ein bestimmtes Ereignis, z.B. "korrekte Eingabe", eingetreten sein. Dieses Ereignis wird über den Zustandsübergangs-Pfeil geschrieben, den es aktivieren soll.

(4) Aktion: ein Ereignis bewirkt eine unmittelbare Aktion, z.B. "Bildschirm löschen", die das Objekt in den nächsten Zustand überführt. Symbolisiert wird dies durch einen mit einem Strich vom Ereignis abgetrennten Text.

Bleibt nur noch zu sagen: die STDs werden durch die im nächsten Kapitel beschriebene Strukturierte Analyse näher spezifiziert.

3. Strukturierte Analyse

Die Strukturierte Analyse von DeMarco bzw. Yourdon/Constantine ist eine datenflußorientierte (un d also DYNAMISCHE) Vorgehensweise der Systemanalyse. Die in der Strukturierten Analyse erstellten Dokumente sind Datenflußdiagramme, Prozeßspezifikationen und Data Directories.

3.1 Datenflußdiagramme

Ein Datenflußdiagramm (DFD) ist von einem Zustandsdiagramm zu unterscheiden. Es beschreibt ein System in Form eines Netzwerkes und besteht aus den folgenden Elementen:

(1) Datenflüsse: durch einen Pfeil symbolisierter Informationsfluß zwischen Prozessen, Dateien oder Datenquellen/-senken.

(2) Prozesse: durch Kreise symbolisierte Einheiten, in denen Eingangsdatenflüsse in Ausgangsdatenflüsse transformiert werden.

(3) Dateien: durch zwei parallele Striche symbolisierte temporärer Speicher von Daten (Repository), z.B. "Bestelldaten".

(4) Datenquellen/-senken: durch ein Recheck symboloisierte Entität, die außerhalb des zu analysierenden Systems liegen. Sie repräsentieren die Schnittstellen des Systems zur Umwelt hin.

Vorgehensweise der Strukturierten Analyse: anhand der Problemspezifikation wird ein Kontextdiagramm erstellt, das nur aus einem Prozeß und den zugehörigen Datenquellen/-senken besteht. Die Datenflüsse dazwischen werden ihrer Aufgabe gemäß beschriftet. Dieses Kontextdiagramm, insbesonderer der Prozeß, wird in den folgenden Schritten durch neue DFDs immer weiter verfeinert; die Strukturierte Analyse ist also eine "Top down"-Entwurfsmethode. Damit jeder Prozeß eindeutig identifizierbat bleibt, wird er in hierarchischer Form nummeriert (z.B. mit 1., 1.1 und 1.2.3).

Für die Verfeinerung der Prozesse schlägt DeMarco folgende Regeln vor:

(1) Die Verfeinerung des Prozesses n ist im DFD mit der Nummer n enthalten. Z.B. enthält das DFD mit der Nummer 1.2 die Prozesse 1.2.1, 1.2.2, ...

(2) Eingangs- und Ausgangsdatenflüsse müssen balanciert sein, d.h. die Datenflüsse aus Diagramm n müssen auch in Diagramm n+1 vorkommen.

(3) In jeder Hierarchieebene werden Dateien nur dargestellt, falls als Schnittstellen zwischen den Prozessen dienen. Dateien innerhalb von Prozessen werden nicht eingezeichnet.

(4) Sowie Dateien das erstemal dargestellt werden, müssen auch die jeweiligen Zugriffsmöglichkeiten darauf durch Pfeile symbolisiert werden.

(5) Die Verfeinerung ist abgeschlossen, wenn jeder Prozeß durch eine etwa eine Seite umfassende Prozeßspezifikation beschreibbar ist.

3.2 Prozeßspezifikation

Die Prozeßspezifikation wird oft auch auch Minispezifikation oder P-Spec genannt. Sie sind redundanzfreie Beschreibungen der durch den Prozeß vorgenommen Transformationen der Eingangs- in Ausgangsdaten. Für jeden Prozeß, der nicht durch ein DFD weiter verfeinert werden kann, muß eine Prozeßspezifikation vorgenommen werden. Dazu werden drei Methoden verwendet:

(1) Strukturierte Sprache: dient der verbalen Beschreibung eines Prozesses, wobei eine eingeschränktes Vokabular und eine begrenzte Syntax zum Einsatz kommt. Beispiel:

  Für jede Geldausgabe tue folgendes:

    1. Sende Nachricht an Dagobert Duck

    2. Falls Geldausgabe>100 durch Donald Duck erfolgt

      dann generiere Wutanfall Dagoberts

      sonst ignoriere Geldausgabe

(2) Entscheidungstabellen: hiermit werden (nur komplexe) formale Entscheidungsprozesse tabellarisch wiedergegeben, wobei es folgenden Aufbau einzuhalten gilt:

Bedingung: Geldausgabe		| Bedingungsteil: Nein	 Ja    Ja

	      Betrag > 100	|                 Nein  Nein  Ja

-----------------------------------------------------------

Aktion:    Wutanfall  		| Regelteil:                  X

		 Ignorieren    |                 X     X     

(3) Entscheidungsbäume: ???

3.3 Data Dictionary

Im Data Dictionary werden die Zusammensetzung aller Datenflüsse und der in den Datein gespeicherten Datenpackete definiert. Diese Definitionen sollten redundanzfrei und leicht erweiterbar sein, z.B. durch einen hierarchischen Aufbau. DeMarco schlägt folgende Syntaxkonventionen vor:

- Zuweisung: symbolisiert durch "="-Zeichen

- Konjunktion: die Und-Verknüpfung wird durch "+" dargestellt

- Selektion: XOR wird durch "[]" dargestellt

- Wiederholung: Elemente werden durch "{}"-Einklammerung wiederholt

- Option: Elemente in "()"-Klammern sind optional

- Kommentar: Kommenatre werden mit "**" eingeklammert

Geldausgabe = Geldausgeber + Gesamtbetrag + { Bestellposition }

Geldausgeber = Name + Adresse

Gesamtbetrag = [kleiner gleich 100 | größer 100]

Bestellposition = Artikelnummer + Anzahl

Artikelnummer

Typ: Ziffern

Wertebereich: vierstellig

Anzahl

Typ: positiv ganze Zahl

Wertebereich: unbeschränkt

4. Objektorientierte Analyse

4.1 Motivation

Die in den vorherigen Kapiteln vorgestellten Methoden haben sich in der industriellen SW-Entwicklung zwar zu Standards entwickelt, können jeweils aber nur einen Teilaspekt des abzubildenden Systems wiedergeben. Im Hinblick auf objektorientierte Programmiersprachen sind sie mit zusätzlichen Schwächen behaftet, so müssen z.B. in allen Phasen unterschiedliche, nicht-kompatible Methoden zum Einsatz kommen.

Coad und Yourdan entwickelten daher die OOA, die in den folgenden Abschnitten vorgestellt wird.

4.2 Objektorientierung - Begriffe

Folgende Begriffe finden bei objektorientierter SW-Entwicklung allgemeine Verwendung:

* Objekt: entspricht Entity, wobei aber Methoden mitmodelliert werden können

* Methode: Eigenschaft eines Entities, die das Verhalten beschreibt

* Kapselung: Anwender sieht nur Schnittstelle, nicht das Entity-Innenleben

* Klassen: entspricht Entity-Set, das auch Methoden mitenhalten kann

* Instanzen: das sind Objekte einer Klasse (Objekt kann auch klassenlos sein)

* Vererbung: Eigenschaften-Wiedergabe der Bassisklasse an abgeleitete Klasse

* Polymorphismus: ein Methodennamen kann für unterschiedliches Verhalten stehen

4.3 OOA-Einführung

Coad und Yourdon sehen für die OOA fünf grundlegende Aktivitäten vor, die iterativ, aber in belibiger Reihenfolge durchgeführt werden. Dies sind die Aktivitäten:

* Festlegung von Objekten und Klassen

* Identifizierung von Strukturen

* Identifizierung von Subjekten

* Definition von Attributen

* Definition von Methoden

Durch die OOA entsteht ein Analysemodell, bei dem die folgenden fünf Schichten untrschieden werden, wobei der Detaillierungsgrad der Darstellung von den Subjekten in Richtung Methoden zunimmt:

(1) Subjekt-Schicht

(2) Klassen-Schicht

(3) Struktur-Schicht

(4) Attribut-Schicht

(5) Methoden-Schicht

4.4 Festlegung von Klassen und Objekten

* Notation: Klassen werden nach Coad und Yourdon als Rechteck mit runden Ecken dargestellt. Abstrakte Klassen haben nur einen Rand, andere Klassen einen Doppelrand. Im oberen Drittel wird der Klassenname eingetragen, in der Mitte die Attribute und im unteren Drittel die Methoden.

* Vorgehensweise: zur Festlegung/Findung von Klassen und Objekten sind:

- die Endanwender zu befragen, um den relevanten Realitätsauschnitt und das nötige Vokabular zu erfahren.

- der Problembereich vom Systembereich zu trennen, d.h. es muß festgestellt werden, welche Probleme durch das System bearbeitet werden können und welche durch die zu entwicklende SW bearbeitet werden müssen. So können z.B. viele typische Attribute eines Objektes wegfallen, da sie für das zu lösende Problem nicht relavant sind.

- alle Informationen/Strukturen zu sammeln, die mit den modellierten Objekten irgendwie in Beziehung stehen. Dazu sind alle Rollen, externen Systeme, Ereignisse, Organisationseinheiten, Instrumente, Prozesse und Orte festzustellen, z.B. sprechende_Ente, Geldspeicher, Geldausgabe, Familie, Rupfmaschine, Wutanfall und Geschäft.

* Überprüfung: die Klassen, die in das Systemmodell aufgenommen werden, sollten:

- nur für das System relevante Eigenschaften enhalten

- mehr als eine Methode/als ein Attribut enthalten

- mehr als nur ein Objekt enthalten

- nur Eigenschaften enthalten, die für alle Objekte davon gültig sind

- keine ableitbaren/berechenbaren Informationen enthalten

- nur den Problembereich berühren und sich nicht mit Programmierungsdetails befassen

4.5 Identifizierung der Strukturen

Coad und Yourdon unterscheiden zwei Strukturformen (deren Kombination auch eine dritte Strukturform erlaubt), die wir uns in diesem Abschnitt nun einmal ansehen wollen.

(1) Generalisierung-/Spezialisierungsstruktur

* Notation: die Basisklasse steht oben, die abgeleiteten Klassen darunter. Verbunden sind sie über Linien, die bis an die innere Klassenumrandung herangehen, weil die "is a"-Beziehung einen Klassen- und keine Objektbeziehung darstellt. In der Mitte der Verbindung befindet sich ein Halbkreis, dessen "Spitze" auf die Basisklasse weist.

* Vorgehensweise: jede Klasse ist zunächst als Basisklasse zu verstehen. Der Systemanalytiker überlegt sich, welche Klassen ableitbar gestaltbar sind. Danach wird jede Klasse als abgeleitete Klasse gesehen, für die Basisklassen gefunden werden müssen. Wichtig ist, die früheren Ergebnisse der OOA wiederzuverwenden. Gibt es zwischen den Spezialfällen kein Mittelding, dann eignen sich abstrakte Basisklassen zur Generalisierung.

* Hierarchie versus Verband: die Generalisierungs-/Spezialisierungsstruktur kann als Baumhierarchie-Struktur ohne Mehrfachvererbung, oder als Verbund-Struktur mit Mehrfachvererbung modelliert werden. Letzterer Weg ist der bessere, da durch diesen unnötige Redundanzen vermieden werden können - allerdings können leichter Konflikte durch inkonsistente Namensgebungen auftreten (Coad und Yourdon empfehlen diesbezüglich nur, stets eindeutige Namen zu verwenden).

(2) Aggregations-/Zerlegungsstruktur

* Notation: die Aggregationsklasse steht oben, die Zerlegungsklassen darunter. Verbunden sind sie über Linien, die nur bis an die äußeren Objektränder gehen, da die "part of"-Beziehung keine Klassen-, sondern eine Objektbeziehung modelliert. In der Mitte der Verbindung befindet sich ein EDreieck, dessen Spitze auf die Aggegationsklasse weist. Ist die Zerlegungsklasse gar nicht oder mehrfach in der Aggragationsklasse enthalten, so wird die Verbindung direkt unter der Aggregationsklasse mit "0, m" beschriftet - damit wird die Kardinalität wiedergegeben.

* Vorgehensweise: Coad und Yourdon unterscheiden drei Arten von Aggregations-/Zerlegungsstrukturen, nach denen der Systemanalytiker im Problembereich zu suchen hat:

- Gesamt-/Teilstruktur, z.B. Endprodukt--0,m--<|--1--Teilprodukt

- Container-/Inhaltstruktur, z.B. LKW--0,m--<|--0,1--Ladung

- Gruppierung-/Mitgliedstruktur, z.B. Verein--1,m--<|--1,n--Mitglied

(3) Komplexe Strukturen: dies sind Strukturen, die aus einer Kombination von Generalisierungs-/Spezialisierungs- und Aggregations-/Zerlegungstrukturen bestehen, z.B. ist beim Schach die Klasse "Figur" "part of" Klasse "Schachspiel" (Schachspiel--32--<|--1--Figur) und außerdem die Generalisierung der Spezialklassen "Bauer", "Springer", usw. In diesem Beispiel kommt es auch zu einer Verbandstruktur zwischen "Turm", "Läufer" und "Dame".

4.6 Identifizierung von Subjekten

Große Analysemodelle können hunderte von Klassen enthalten. Um hier nicht die Übersicht zu verlieren, können mehrere Klassen zu größeren Einheiten, zu sogenannten Subjekten zusammengefaßt werden. Dadurch werden Diagramme nicht mit Informationen überladen und bleiben nachvollziehbar. Zudem sollen einige Komponenten für den Endanwender auch bewußt unsichtbar gehalten werden.

* Notation: Subjekte werden dadurch dargestellt, daß ein Rahmen um die zugehörigen Klassen gelegt wird, der in den Ecken eine Subjekt-Nummer erhält.

* Vorgehensweise: zunächst wird jeder eigenständige Beziehungsverbund und jede Aggregations- bzw. Zerlegungsklasse als potentielles Subjekt deklariert. Diese Subjekte können zu größeren Subjekten zusammengefaßt werden, sofern sie nach innen Verbindungen aufweisen, nach außern hin - subjektübergreifend - aber nicht. Üblicherweise werden Subjekte bereits früh in das Modell aufgenommen, da sie dann besser von verschiedenen Gruppen bearbeitet werden können.

4.7 Definition von Attributen

* Notation von Attributen: die Attributre einer Klasse werden in das mittlere Drittel des Klassensymbols eingetragen.

* Notation von Objektbeziehungen: durch die Wahl der Attribute kommt es zu relationalen Beziehungen zwischen Objekten verschiedener Klassen. Diese Beziehungen werden ähnlich wie im ERM durch einfache Linien zwischen den Objektumrandungen dargestellt, wobei darauf zu achten ist, daß die Kardinalitäten gerade umgedreht zur ERM plaziert werden. Die Beziehung Server--0,m----1--Client bedeutet also, daß ein Server mit keinem oder mehrern Clients verbunden sein kann, daß ein Client aber stets mit genau einer Serverinsatnz in Beziehung steht. Das gemeinsame Attribut könnte in diesem Falle die Prozeß-ID sein. Die Beziehungslinie kann beschriftet werden.

* Vorgehensweise bei Attributen: die Attribute eines Objektes werden gefunden, wenn man aufzählt, welche Zustände sie einnehmen können, welche Merkmale insgesamt typisch für sie sind und welche davon für den Problembereich relevant sind. Die Normalisierung, die Festlegung der Schlüssel und die Behandlung von ableitbaren Attributen sind Aufgaben des OOD, nicht der OOA! Allerdings läßt sich im Bezug auf ableitbare Attribute vermerken, daß diese so nahe wie sinnvoll an der Generalisierungsklasse liegen sollten.

* Vorgehensweise bei Objektbeziehungen: die Objektbeziehungen (zu denen auch die Aggregations-/Zerlegungsstrukturen gehören) sollten Beziehungen des zu modellierenden Realweltausschnitts wiederspiegeln. Sie alleine verbinden i.d.R. die verschiedenen Subjekte eines OOA-Modells. Bei optionalen Beziehungen ist die Kardinalzahl-Untergrenze 0 und bei obligatorischen Beziehungen ist die Kardinalzahl-Untergrenze 1 oder größer. Nimmt ein Objekt an einer Beziehung nur einmal teil, dann ist die Kardinalzahl-Obergrenze 1, und sonst größer. Bei M:N-Beziehungen sind neue Klassen mit gemeinsamen Attributen zu definieren; zusätzlich können aber auch die direkten M:N-Beziehungslinien bestehen bleiben!

* Überprüfung: Attribute müssen

- für alle Objekte gelten, die sie enthalten

- in mehrfacher Weise in mehreren Objekten einer Klasse vorkommen

- voneinander unableitbar sein

* Attributespezifikationen: in die Spezifikation müssen die Wertebereiche der Attributeausprägungen, die Genauigkeit, mögliche Standardwerte, die Zugriffsrechte und Zusammenhangsbeschreibungen zu anderen Attributen/Objekten eingehen.

4.8 Definition von Methoden

* Notation: die Methoden werden im unteren Drittel des Klassensymbols genannt.

* Vorgehensweise: die Definition der Methoden besteht aus den folgenden fünf Aktivitäten.

- Identifizieren von Objektzuständen: jede Attributeausprägunmgs-Änderung eines Objektes stellt eine Zustandsänderung dar. Um die möglichen Zustände einzuschränken, gibt es zulässige Wertebereiche für die Attributeausprägungen. Grafisch dargestellt wird dies mit Hilfe von STDs.

- Identifizieren benötigter Methoden: Coad und Yourdan unterscheiden zwei Gruppen von Methoden: algorithmisch einfache Methoden und algorithmisch komplexe Methoden. Erstere Methoden werden in der Methodenschicht der OOA NICHT explizit dargestellt; es sind dies die Methoden Create (Objekterzeugung), Connect (Initilaisierung eines Beziehungsobjekts), Access (Attribute-Änderungsaufruf) und Release (Objektlöschung). Die algorithmisch komplexen Methoden dagegen werden explizit dargestellt in der Methoden-Schicht der OOA; mit ihnen werden anhand der Objektzustände neue Objektzustände berechnet.

- Identifizieren von Methodenaufrufen: Objekte kommunizieren über Methodenaufrufe, was in der OOA durch Pfeile vom Sender- zum Empfängerobjekt dargestellt wird.

- Spezifikation der Methoden: kann innerhalb von CASE-Vordrucken realisiert werden, indem die Algorhitmen oder Struktogramme der Methoden mit passender Beschreibung darin niedergelegt werden.