Objektorientiertes Analyse

---

Inhalt

• 1. Einleitung - Phasenmodelle
• 2. Das Entity Relationship Modell zum Information Modeling
  • 2.1. Begriffe und Notation
• 3. Zustandsdiagramme - Lebenszyklen von Informationsobjekten
• 4. Strukturierte Analyse
  • 4.1. Datenflussdiagramme
  • 4.2. Prozessspezifikation
  • 4.3. Data Dictionary
• 5. Objektorientierte Analyse
  • 5.1. Motivation
  • 5.2. Objektorientierung - Begriffe
  • 5.3. OOA-Einführung
  • 5.4. Festlegung von Klassen und Objekten
  • 5.5. Identifizierung der Strukturen
  • 5.6. Identifizierung von Subjekten
  • 5.7. Definition von Attributen
  • 5.8. Definition von Methoden

1. Einleitung - Phasenmodelle

Zur industriellen Herstellung von Software (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-Modell 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 objektorientierte Analyse (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 stehen 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 umgesetzt.
• 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: Diese Phase bleibt während des gesamten Produktlebenszyklus bestehen und kann einen Grossteil der Entwicklungskosten verschlingen. Es gilt: Je genauer analysiert und designt wurden, um so geringer fällt später die nötige Wartung aus.

Die Phasenmodelle:

1. Wasserfallmodell (Barry Boehm,1981): Bei diesem Modell werden die Phasen sequenziell durchlaufen, wobei zwar Rückkopplungen im Prinzip vorgesehen sind, aber aus Kostengründen so selten als möglich durchgeführt werden sollten - schliesslich fliesst Wasser normalerweise auch nicht bergauf.
2. Spiralenmodell (Barry Boehm, 1988): Bei diesem Modell werden alle Phasen wie beim Wasserfallmodell sequenzielle 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 Sequenzialität aufgehoben und explizit Überscheidungen zwischen den Phasen zugelassen, d.h. das Design beginnt, während die Analyse noch in Arbeit ist, sodass Designergebnisse die Analyse beeinflussen können. Dazu ist es wichtig, dass die Ergebnisse der einzelnen Phasen untereinander kompatibel sind - eine Forderung, die der objektorientierten 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.

2. Das Entity Relationship Modell zum Information Modeling

Das Entity Relationship Modell (ERM) von Peter Chen (1976) dient zur Beschreibung von Daten und ihren STATISCHEN Beziehungen untereinander. Es besitzt den grossen Vorteil, dass darauf hierarchische, netzwerkartige, relationale und sogar objektorientierte Datenmodelle aufbauen können.

2.1. Begriffe und Notation

Wir unterscheiden nach Shlaer/Mellor bei einem ERM 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 Relationship-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 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 gegenüber 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 Entity-Sets. Bei der Umsetzung von 1:M-Relationship-Sets geschieht das Gleiche, nur dass hier in jedem Fall das Entity-Set das referential Attribut erhält, welches in der Beziehung mehrfach vorkommt. Bei N:M-Beziehungen dagegen kann man auf das referentielle Attribut verzichten, kommt dafür aber nicht umhin, ein neues Entity-Set zu bilden, dessen Attribute den Schlüsseln der beteiligten Entity-Sets entsprechen. Dieses neue Entity-Set nennt man auch Korrelationstabelle oder Relationship-Entity-Set. Zu beachten ist noch, dass 1:1c-Beziehungen verlangen, dass das referentielle Attribut dem Entity-Set zuzuordnen ist, der an jeder Beziehung teilnimmt. Und 1c:1c-Beziehungen können zu guter Letzt 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.Attribut 1           1.1  Seminar.Thema
       Beschreibung: ...                Beschreibung: ...
       Typ: ...                         Typ: String
       Wertebereich: ...                Wertebereich: Uneingeschränkt
   
   1.2    ...
   

2. Relationship-Spezifikation:

   1.  Entity-1 VERB-1 Entity-2        1. Betreuer BETREUT Arbeit (1:Mc)
       Entity-2 VERB-2 Entity-1           Arbeit WIRD BETREUT VON Betreuer
       Beschreibung: ...                  Beschreibung: ...
   

3. Zustandsdiagramme - Lebenszyklen von Informationsobjekten

Im Rahmen des Information Modeling werden die Daten eines Systems und ihre Strukturen nur statisch beschrieben; die DYNAMISCHE Sicht auf die Daten wird durch Zustandsdiagramme (State Transition Diagram, STD) 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 Objekts einen definierten Wert besitzen. Grafisch dargestellt wird dies durch ein Rechteck mit dem Zustandsnamen darin, z.B. "Warten auf Eingabe".
2. Zustandsübergang: Objekte können ihren 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, muss 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 STD werden durch die im nächsten Kapitel beschriebene Strukturierte Analyse näher spezifiziert.

4. Strukturierte Analyse

Die Strukturierte Analyse von DeMarco (1978) bzw. Yourdon/Constantine (1979) ist eine datenflussorientierte (und also DYNAMISCHE) Vorgehensweise der Systemanalyse. Die in der Strukturierten Analyse erstellten Dokumente sind Datenflussdiagramme, Prozessspezifikationen und Data Directories.

4.1. Datenflussdiagramme

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

1. Datenflüsse: Das ist der durch einen Pfeil symbolisierter Informationsfluss zwischen Prozessen, Dateien oder Datenquellen/-senken.
2. Prozesse: Das sind 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 symbolisierte Entität, die ausserhalb 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 Prozess und den zugehörigen Datenquellen/-senken besteht. Die Datenflüsse dazwischen werden ihrer Aufgabe gemäss beschriftet. Dieses Kontextdiagramm, insbesondere der Prozess, wird in den folgenden Schritten durch neue DFD immer weiter verfeinert; die Strukturierte Analyse ist also eine "Top down"-Entwurfsmethode. Damit jeder Prozess eindeutig identifizierbar 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 erste Mal dargestellt werden, müssen auch die jeweiligen Zugriffsmöglichkeiten darauf durch Pfeile symbolisiert werden.
5. Die Verfeinerung ist abgeschlossen, wenn jeder Prozess durch eine etwa eine Seite umfassende Prozessspezifikation beschreibbar ist.

4.2. Prozessspezifikation

Die Prozessspezifikation wird oft auch Minispezifikation oder P-Spec genannt. Sie sind redundanzfreie Beschreibungen der durch den Prozess vorgenommen Transformationen der Eingangsdaten in Ausgangsdaten. Für jeden Prozess, der nicht durch ein DFD weiter verfeinert werden kann, muss eine Prozessspezifikation 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: ???

4.3. Data Dictionary

Im Data Dictionary werden die Zusammensetzung aller Datenflüsse und der in den Dateien gespeicherten Datenpakete 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: Kommentare werden mit "**" eingeklammert

Geldausgabe     = Geldausgeber + Gesamtbetrag + { Bestellposition}
Geldausgeber    = Name + Adresse
Gesamtbetrag    = [kleiner gleich 100 | grösser 100]
Bestellposition = Artikelnummer + Anzahl

Artikelnummer
  Typ:          Ziffern
  Wertebereich: vierstellig

Anzahl
  Typ:          positiv ganze Zahl
  Wertebereich: unbeschränkt

5. Objektorientierte Analyse

5.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 Yourdon entwickelten daher die OOA, die in den folgenden Abschnitten vorgestellt wird.

5.2. Objektorientierung - Begriffe

Folgende Begriffe finden bei objektorientierter SW-Entwicklung allgemeine Verwendung:

• Objekt: Entspricht Entity, wobei aber Methoden mit modelliert werden können
• Methode: Eigenschaft eines Entities, die das Verhalten beschreibt
• Kapselung: Anwender sieht nur Schnittstelle, nicht das Entity-Innenleben
• Klassen: Diese entsprechen Entity-Sets, die auch Methoden enthalten können
• Instanzen: Das sind Objekte einer Klasse (Objekt kann auch klassenlos sein)
• Vererbung: Eigenschaften-Wiedergabe der Basisklasse an abgeleitete Klasse
• Polymorphismus: Ein Methodennamen kann für unterschiedliches Verhalten stehen

5.3. OOA-Einführung

Coad und Yourdon sehen für die OOA fünf grundlegende Aktivitäten vor, die iterativ, aber in beliebiger 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 unterschieden 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

5.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ätsausschnitt und das nötige Vokabular zu erfahren.
• der Problembereich vom Systembereich zu trennen, d.h., es muss festgestellt werden, welche Probleme durch das System bearbeitet werden können und welche durch die zu entwickelnde Software 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 relevant sind.
• alle Informationen/Strukturen zu sammeln, die mit den modellierten Objekten irgendwie in Beziehung stehen. Dazu sind alle Rollen, externe 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 enthalten.
• 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.

5.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. Generalisierungsstruktur bzw. 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 eine Klassenbeziehung 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 Generalisierungsstruktur bzw. Spezialisierungsstruktur kann als Baumhierarchie-Struktur ohne Mehrfachvererbung oder Verbundstruktur 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 daher, stets eindeutige Namen zu verwenden).
2. Aggregationsstruktur bzw. Zerlegungsstruktur:
   • Notation: Die Aggregationsklasse steht oben, die Zerlegungsklassen darunter. Verbunden sind sie über Linien, die nur bis an die äusseren Objektränder gehen, da die "part of"-Beziehung keine Klassen-, sondern eine Objektbeziehung modelliert. In der Mitte der Verbindung befindet sich ein Dreieck, dessen Spitze auf die Aggregationsklasse weist. Ist die Zerlegungsklasse gar nicht oder mehrfach in der Aggregationsklasse 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 Aggregationsstrukturen bzw. Zerlegungsstrukturen, nach denen der Systemanalytiker im Problembereich zu suchen hat:
     1. Gesamt-/Teilstruktur, z.B. Endprodukt--0,m--<|--1--Teilprodukt
     2. Container-/Inhaltsstruktur, z.B. LKW--0,m--<|--0,1--Ladung
     3. Gruppierung-/Mitgliedsstruktur, z.B. Verein--1,m--<|--1,n--Mitglied
3. Komplexe Strukturen: Dies sind Strukturen, die aus einer Kombination von Generalisierungsstrukturen bzw. Spezialisierungsstrukturen und Aggregationsstrukturen bzw. Zerlegungsstrukturen bestehen, z.B. ist beim Schach die Klasse "Figur" "part of" Klasse "Schachspiel" (Schachspiel--32--<|--1--Figur) und ausserdem die Generalisierung der Spezialklassen "Bauer", "Springer", usw. In diesem Beispiel kommt es auch zu einer Verbandsstruktur zwischen "Turm", "Läufer" und "Dame".

5.6. Identifizierung von Subjekten

Grosse Analysemodelle können Hunderte von Klassen enthalten. Um hier nicht die Übersicht zu verlieren, können mehrere Klassen zu grösseren Einheiten, zu sogenannten Subjekten zusammengefasst werden. Dadurch werden Diagramme nicht mit Informationen überladen und bleiben nachvollziehbar. Zudem sollen einige Komponenten für den Endanwender auch bewusst unsichtbar gehalten werden.

• Notation: Subjekte werden dadurch dargestellt, dass 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 potenzielles Subjekt deklariert. Diese Subjekte können zu grösseren Subjekten zusammengefasst werden, sofern sie nach innen Verbindungen aufweisen, nach aussen 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.

5.7. Definition von Attributen

Notation von Attributen: Die Attribute 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, dass die Kardinalitäten gerade umgedreht zur ERM platziert werden. Die Beziehung Server--0,m----1--Client bedeutet also, dass ein Server mit keinem Client oder aber mehreren Clients verbunden sein kann, dass ein Client aber stets mit genau einer Serverinstanz in Beziehung steht. Das gemeinsame Attribut könnte in diesem Falle die Prozess-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ässt sich im Bezug auf ableitbare Attribute vermerken, dass 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 widerspiegeln. 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össer. Nimmt ein Objekt an einer Beziehung nur einmal teil, dann ist die Kardinalzahl-Obergrenze 1, und sonst grösser. 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.

Attributsspezifikationen: In die Spezifikation müssen die Wertebereiche der Attributsausprägungen, die Genauigkeit, mögliche Standardwerte, die Zugriffsrechte und Zusammenhangsbeschreibungen zu anderen Attributen/Objekten eingehen.

5.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.

1. Identifizieren von Objektzuständen: Jede Attributsänderung eines Objektes stellt eine Zustandsänderung dar. Um die möglichen Zustände einzuschränken, gibt es zulässige Wertebereiche für die Attributsausprägungen. Grafisch dargestellt wird dies mithilfe von State Transition Diagrams.
2. Identifizieren benötigter Methoden: Coad und Yourdon 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 (Initialisierung 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.
3. Identifizieren von Methodenaufrufen: Objekte kommunizieren über Methodenaufrufe, was in der OOA durch Pfeile vom Sender- zum Empfängerobjekt dargestellt wird.
4. Spezifikation der Methoden: Kann innerhalb von CASE-Vordrucken realisiert werden, indem die Algorithmen oder Struktogramme der Methoden mit passender Beschreibung darin niedergelegt werden.