Ziele: Darstellen können, aus welchen Teilmodellen und mit welchen Konzepten sich

1. 23. Grundlagen der objektorientierten Analyse • Ziele: • Darstellen können, aus welchen Teilmodellen und mit welchen Konzepten sich OOA zusammensetzt. • Die Eigenschaften und Einsatzbereiche von Assoziationen und Aggregationen erklären können. • Die problemgerechten Kardinalitäten identifizieren und entsprechend der dargestellten Notation beschreiben können. • Darstellen können, wie innerhalb von Operationen Dienstleistungen anderer Klassen, die durch Assoziationen bzw. Aggregationen verbunden sind, in Anspruch genommen werden können (Vererbung). • Für gegebenen Beispiele die behandelten Konzepte problemgerecht auswählen und anwenden können.

2. Geschichtliche Entwicklung der Objektorientierten Analyse 1980 wurde mit der Programmiersprache Smalltalk-80 die Ära der OOP eröffnet. Seitdem bilden Objekt, Klasse, Attribut, Operation, Botschaft, Vererbung und Polymorphismus die Grundkonzepte der objektorientierten Software-Entwicklung. 1990 ergänzten die Autoren Coad und Yourdon die objektorientierten Grundkonzepte aus dem Entity-Relationship-Modell und der semantischen Datenmodellierung. Sie fügten Assoziationen, (Beziehungsmengen) und Aggregationen (Ist-Teil-von-Beziehungen) den Grundkonzepten hinzu. Umfangreiche Modelle können in Subsysteme gegliedert werden. Der Objektlebenszyklus kann durch Zustandsautomaten spezifiziert werden. Andere Autoren integrierten Interaktions-Diagramme zur Beschreibung von Szenarien.

3. Die objektorientierten Grundkonzepte zusammen mit diesen Erweiterungen bilden die objektorientierte Analyse (OOA, object oriented analysis) die es dem Systemanalytiker erlaubt, Anforderungen an ein neues Software-System problemnah zu modellieren. 1990 - 1994 Stürmische Entwicklung der objektorientierten Software-Entwicklung, insbesondere die objektorientierte Analyse. Es wurden ca. 50 verschiedenen Analyse-Methoden entwickelt. Allein über 15 objektorientierte Methoden wurden beschrieben. Seit 1993 wurden über 15 verschiedene CASE-Werkzeuge (Computer Aided Software Engineering) zur Unterstützung dieser Methoden in den Markt eingeführt. Bedingt durch diese innovative und dynamische Entwicklung gibt es insbesondere unterschiedliche grafische Notationen für verschiedene OOA-Konzepte.

4. Abb.: OO-Grundkonzepte und OOA-Konzepte OO-Grundkonzepte Objekt Botschaft Klasse Vererbung Attribut Poly- Operation morphismus Assoziation Aggregation Subsystem Zustandsautomat Interaktionsdiagramm OOA-Konzepte

5. Ziel der objektorientierten Analyse ist es, die Anforderungen an ein neues Software-Produkt mit Hilfe objektorientierter Konzepte zu modellieren. Das entstehende Modell läßt sich in drei Teilmodellegliedern. (nach Heide Balzert) Botschaft Interaktions- Diagramm Dynamisches Modell Objekt- Lebenszyklus Spezifikation Assoziation Aggregation Statisches Modell Vererbung Subsystem Objekt / Klasse Attribut Basismodell Operation Poly- morphismus

6. Assoziation Eine Assoziation, auch Beziehungsmenge (instance connection) genannt, modelliert Beziehungen zwischen Objekten gleichrangiger Klassen. Sie ist auch zwischen Objekten derselben Klasse zulässig. Im Gegensatz dazu verknüpft eine Vererbung Klassen miteinander, nicht Objekte der Klassen. Beispiel: In der Fallstudie „Seminarorganisation“ kann ein Kunde sich um Zahlungsverzug befinden. Der Kunde Schulz aus Dortmund hat seine offenen Posten vom 10.05.95 in Höhe von DM 2.000,- noch nicht bezahlt. Außerdem ist die Rechnung vom 15.07.95 in Höhe von DM 1.500,- noch offen.

7. Assoziation zwischen Objekten (Kunde) Schulz Dortmund (Zahlungsverzug) 2000.- 10.05.95 hat (Zahlungsverzug) 1500.- 15.07.95 hat • Allgemein läßt sich über die Objekte der Klasse Kunde und der Klasse Zahlungsverzug folgendes sagen: • Ein Kunde hat keinen, einen oder mehrere Zahlungsverzüge • Ein Zahlungsverzug gehört zu genau einem Kunden. • Die Menge aller Beziehungen „hat“ bezeichnet man als Assoziation zwischen den Objekten der Klassen Kunde und Zahlungsverzug.

8. d. h. Assoziationen zwischen zwei Objekten. Jedes dieser Objekte gehört i. a. zu einer anderen Klasse. Man spricht daher von einer Assoziation zwischen zwei Klassen, obwohl streng genommen die Objekte dieser Klassen gemeint sind. Assoziationen sind vergleichbar mit den Assoziationen bzw. Beziehungen des Entity-Relationship-Modells. Sie stellen jedoch nicht nur eine statische Struktur zwischen den Klassen dar, sondern bilden vor allem die Voraussetzung für den Botschaftsfluß zwischen Objekten (im Gegensatz zu einer relationalen Datenbank). Assoziationen werden häufig benannt. Der Name beschreibt im allgemeinen nur eine Richtung der Assoziation. Wenn möglich, soll die Grafik so gestaltet werden, daß die Leserichtung von links nach rechts der Assoziationsrichtung entspricht, z. B. jeder Kunde „hat“ Zahlungsverzüge. Der Name darf fehlen, wenn die Bedeutung der Assoziation offensichtlich ist. Existieren mehrere Assoziationen zwischen denselben Klassen, so müssen sie benannt werden. Zunächst werden nurbinäre Assoziationenbetrachtet,

9. instance connection, (object) relationship und acquaintance gebräuchlich. Als Synonyme für die Assoziationen sind die Begriffe Die Kardinalität, auch Komplexitätsgrad und Multiplizität genannt, gibt an, mit wie vielen anderen Objekten ein Objekt einer bestimmten Klasse in einer konkreten Beziehung stehen kann bzw. stehen muß. Zur Darstellung der Kardinalzahlen wird oft die numerische Notation verwendet. Sie benutzt Ziffern und Buchstaben zur Angabe der minimalen und der maximalen Anzahl der in Beziehung stehenden Objekte.

10. Das der Klasse 1 zugeordnete Paar min1, max1 gibt die minimale und die maximale Anzahl von Objekten der Klasse 2 an, mit der ein Objekt der Klasse 1 eine Beziehung eingehen kann. Umgekehrt gibt das der Klasse 2 zugeordnete Paar min2, max2 die minimale und die maximale Anzahl von Objekten der Klasse 1 an, mit der ein Objekt der Klasse 2 eine Beziehung eingehen kann. Ist min = max, dann wird nur ein Wert angegeben. Ist eine konkrete Grenze vom Fachkonzept her bekannt, dann wird die entsprechende Zahl angegeben.

11. Eine Muß-Beziehung liegt vor, wenn bei minimaler Anzahl eine Kardinalität 1 oder größer angegeben ist. Die maximale Anzahl kann zwischen 1 und n liegen. • Demgegenüber erkennt man eine Kann-Beziehung daran, daß die minimale Anzahl gleich Null ist. Ein Objekt kann in einer Beziehung folgende Kardinalitäten besitzen: Zu dem betrachteten Objekt gehören: 1 genau ein Objekt, 0, 1 kein oder ein Objekt, 1, m ein oder mehrere Objekte 0, m kein, ein oder mehrere Objekte 4 genau vier Objekte 2, 8 mindestens 2 und höchstens 8 Objekte ... Man unterscheidet Muß- und Kann-Beziehungen

12. Eine Rolle beschreibt, welche Funktion ein Objekt in einer Assoziation innehat. Eine binäre Assoziation besitzt maximal zwei Rollen. Der Rollenname wird jeweils an ein Ende der Assoziation geschrieben, und zwar bei der Klasse, deren Bedeutung in der Assoziation sie näher beschreibt. Beispiel für Rollen: Konzeptionelle Details Arbeit-geber Firma Mitarbeiter PKW 0,1 1 Fahrer 0, m Arbeit-nehmer 0, 1 Dienst-wagen Der Gebrauch von Rollen ist optional. Die geschickte Wahl der Rollennamen kann zur Verständlichkeit jedoch mehr beitragen als der Name der Assoziation selbst. Rollennamen oder Assoziationen müssen aus Gründen der Lesbarkeit angegeben werden, wenn zwischen zwei Klassen mehr als eine Assoziation besteht.

13. Normalerweise bestehen Assoziationen zwischen Objekten verschiedener Klassen. Eine Assoziation ist jedoch auch zwischen Objekten derselben Klasse erlaubt. In diesem Fall müssen die Rollen stets angegeben werden, um die Verständlichkeit zu gewährleisten. Manchmal ist es sinnvoll auf den Assoziationen eine Ordnung zu definieren. Man spricht dann von geordneten Assoziationen Die Ordnung kann als eine spezielle Form der Restriktion aufgefaßt werden. Gegebenfalls muß die Art der Ordnung (zeitlich, alphabetisch,...) genauer spezifiziert werden. Besteht eine Restriktion (constraint) zwischen den Attributwerten zweier Objekte, so ist damit immer eine Restriktion für die Assoziation zwischen diesen Objekten vorhanden. Eine Restriktion kann auch zwischen zwei Assoziationen bestehen. Eine Assoziation kann auch als Klasse modelliert werden, wenn es nötig ist, der Assoziation eigene Attribute und Operationen zuzuordnen.

14. besteht zwischen Kunden und Seminarveranstaltung die Assoziation „bucht“. Zu jeder Buchung müssen jedoch zusätzliche Informationen gespeichert werden, wie „Abgemeldet am“, „Rechnung am“ usw. Außerdem gehören die Operationen „Anmelden“ und „Abmelden“ zur Buchung. Da diese Attribute und Operationen weder allein zu Kunde noch allein zu Seminarveranstaltung gehören, sondern ursächlich mit jeder individuellen Buchung verknüpft sind, wird eine zusätzliche Klasse Buchung eingeführt und zwischen Kunde und Seminarveranstaltung eingefügt. In der Fallstudie„Seminarorganisation“ Buchung Angemeldet am Abgemeldet am Änderungsmitteilung am Rechnung am Anmelden Abmelden Seminar- veranstaltung Kunde 0, m 1 1 0, m

15. Aggregation Vererbung: Besteht eine Assoziation zu den Objekten einer Oberklasse, dann wird die Assoziation an die Unterklassen vererbt, analog wie Attribute und Operationen. Eine Aggregation ist eine gerichtete Assoziation zwischen Objekten. Sie stellt einen Sonderfall der Assoziation dar und liegt vor, wenn zwischen den Objekten der beteiligten Klassen (kurz: den beteiligten Klassen) eine Rangordnung gilt, die sich durch „ist Teil von“ bzw. „besteht aus“ beschreiben läßt. Man spricht auch vom Ganzen und seinen Teilen bzw. von einer Stücklistenstruktur.

16. In der Abbildung besteht zwischen den Klassen Mitarbeiter und Auto eine Assoziation. Obwohl ein Fahrer zeitweise in einem Auto sitzt, läßt sich diese Beziehung nicht durch „besteht aus“ beschreiben. Ein Auto besteht jedoch aus einem Motor, vier Rädern und einer Karosserie: In diesem Fall liegt eine Aggregation vor. Abb. Assoziation versus Aggregation Mitarbeiter Auto 0, 1 Hierarchie zwischen den Klassen 0, 1 1 4 1 0, 1 0, 1 0, 1 Motor Rad Karosserie

17. 1. Ein Buch mit seinen Kapiteln, hier gilt ebenfalls die Aggregation. Die Kapitel sind „Teil von“ dem Buch, bzw. das Buch „besteht aus“ den dazugehörigen Kapiteln. 2. Girokonto - Kontobewegungen. Ein Objekt, das „das Ganze“ repräsentiert, wird als Aggregat-Objekt (Auto, Buch, ...) bezeichnet. Jede Teilklasse wird durch eine Linie mit der Gesamtheitsklasse verbunden. Ein Dreieck, das die Linie unterbricht, zeigt, daß es sich um eine Aggregation handelt. Die Spitze des Dreiecks zeigt zur Gesamtheitsklasse. ( Siehe vorherige Abbildung) Kardinalitäten werden wie bei der Assoziation angegeben. Aggregat-Klassen sollen im Diagramm über den Teil-Klassen angeordnet sein. Weitere Beispiele sind:

18. Die Klassen einer Aggregation können auch in einer Vererbungsstruktur enthalten sein. • Besteht eine Aggregation zu Objekten einer Oberklasse, dann wird die Aggregation an die Unterklasse vererbt, ebenso wie Attribute, Operationen und Assoziationen. • Synonyme: Für Aggregationen werden auch die Begriffe partition hierarchy, whole part structure, composition, whole-part association und composite objects verwendet. • Eine Aggregation ist • im allgemeinen transitiv, d.h. ist A Teil von B und B Teil von C, dann ist auch A Teil von C und • asymmetrisch, d.h. ist A Teil von B, dann ist B kein Teil von A. Aggregationen können auch rekursiv sein, d.h. ein Teilobjekt steht in Beziehung zu seinen Aggregationsobjekt. Da die Aggregation ein Sonderfall der Assoziation ist, können auch Restriktionen benutzt werden. Außerdem können Aggregationen geordnet sein.

19. Die Anzahl der Klassen in einem OOA-Modell ist abhängig von der jeweiligen Anwendung. Ein System mittlerer Größe umfaßt im Durchschnitt 35 Klassen, ein großes System mehr als 100 Klassen. Da alle diese Klassen in einem Diagramm dargestellt werden, hat der Leser Schwierigkeiten, einen Überblick zu bekommen. Subsysteme dienen daher dazu, den Leser durch ein großes, komplexes Modell zu führen. Außerdem helfen sie, geeigneten Teilsysteme bei großen Systemen zu identifizieren. Ein Subsystem faßt eine oder mehrere Klassen zu einer höheren Abstraktionsebene zusammen. Subsysteme dürfen sich überlappen, d.h. eine Klasse kann zu mehreren Subsystemen gehören. Eine Klasse kann auch zu keinem Subsystem gehören. Jedes Subsystem erhält einen eindeutigen Namen. Coad/Yourdon numeriert die Subsysteme zusätzlich durch. Synonyme: Category, subject und clustering Subsystem

20. Ein Subsystem wird durch ein graues Rechteck dargestellt. Das Rechteck enthält eine Zahl und einen Subsystem-Namen (Bsp. (a), komprimiertes System). Optional (Bsp. (b)) können im unteren Teil des Rechtecks die Klassen aufgeführt werden, die das Subsystem umfaßt. c Notation: Subsysteme 1 1 Klasse 1 a 1. Subsystem 1 b 1. Subsystem 1 Klasse 1 Klasse 2 Klasse 3 Klasse 2 Klasse 3 1 1

21. d. h. es soll so strukturiert sein, daß es 1 den Leser durch das Modell führt 2 einen Themenbereich enthält, der für sich allein betrachtet und verstanden werden kann, 3 Klassen enthält, die logisch zusammengehören, z.B. Artikel, Lieferant und Lager, 4 für sich entworfen und evtl. implementiert werden kann, wobei eine wohldefinierte Schnittstelle zur Umgebung vorhanden ist. Dabei soll die Schnittstelle 1 Vererbungsstrukturen nur in vertikaler Richtung schneiden, d.h. zu jeder Unterklasse sollen alle Oberklassen in dem Subsystem enthalten sein, 2 keine Aggregationen durchtrennen und 3 möglichst wenig Assoziationen und Botschaftswege enthalten. Das Subsystem soll eine logische Einheit bilden,

22. Die Analyse vorhandener OOA-Modelle zeigt, daß sich bestimmte Grundmuster (pattern) in ähnlicher Form immer wiederholen. Muster 1:Abstrakte Oberklasse Die gemeinsamen Attribute und Operationen von zwei oder mehr konkreten Klassen werden zu einer abstrakten Oberklasse zusammen-gefaßt. Diese Vererbungsstruktur tritt häufig auf. Muster 2:Konkrete Oberklasse Besitzt eine Oberklasse nur eine einzige Unterklasse, dann ist die Oberklasse eine konkrete Klasse. Die Oberklasse kann abstrakt sein, wenn das System für Erweiterungen konzipiert wird. Muster 3:„Assoziation“ mit Eigenschaft / Verhalten Müssen über eine Assoziation Informationen gespeichert werden, dann sind diese Informationen in einer zusätzlichen Klasse zu verkapseln. Zusätzlich besitzt die neu geschaffene Klasse Operationen, über die sie mit ihren Nachbarklassen kommuniziert. OOA-Muster

23. Es gibt Klassen, die selbst kaum Attribute / Operationen besitzen, aber mit vielen anderen Klassen in Beziehung stehen und sie koordinieren. Muster 4: Koordination von Objekten Buch Autor Titel Kaufen Muster 5:Exemplare und ihre Beschreibung Attributwerte, die zu einer Menge von Objekten - physischen und logischen Exemplaren - gehören, werden in einer Aggregatklasse angeordnet Beispiel: Buch - Buchexemplar  0, m 1 Buchexemplar Inventur-Nr Ausgeliehen am Ausleihen Zurückgeben

24. Sollen für ein Objekt einer Klasse bestimmte Ereignisse registriert werden, dann wird dafür ein Aggregat-Objekt verwendet. Bei den Ereignissen handelt es sich um Informationen, die ein Datum und evtl. eine Zeit besitzen. Beispiel: Zeiterfassungsgerät für die Arbeitszeit von Mitarbeitern Muster 7:Fortpflanzung von Attributwerten Ein Attributwert des Attribut-Objekts kann auch für die zugehörigen Objekte der Teilklasse Gültigkeit besitzen. Beispielsweise besitzt jeder Bestellposten das gleiche (Bestell-)Datum wie die zugehörige Bestellung. Muster 8:Wechselnde Rollen Ein Objekt der realen Welt kann zu verschiedenen Zeitpunkten verschiedene Attribute und Rollen besitzen. Soll später nachvollzogen werden, welche Werte ein Objekt zu welchem Zeitpunkt besessen hat, dann ist eine Aufzeichnung der Historie erforderlich. Muster 6:Ereignisse registrieren

25. In der Klasse Kunde werden alle Daten gespeichert, die unabhängig von einem Zeitpunkt sind. Ein Kunde ist in der Regel zunächst ein Adressat von Werbematerial. Die Adresse wird bei einem Adressenhandel gekauft. Fordert der Kunde einen Seminarkatalog an, dann wird er zum Interessenten. Bucht er ein Seminar, dann ist er ein Teilnehmer. Um das Marketing zu optimieren, sollen alle drei Rollen gespeichert werden. Für alle Kunden wird zu bestimmten Zeitpunkten eine Prioritätskategorie ermittelt, die die Bedeutung der Kunden widerspiegelt. Muster 9:power type Ein power type ist eine Klasse, deren Exemplare Unterklassen einer anderen Klasse aggregieren. Beispiel: Wechselnde Rollen