G.Heyer Digitale Informationsverarbeitung 1 Ziele: ã Darstellen können, aus welchen Teilmodellen...

G.Heyer Digitale Informationsverarbeitung1

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.

23. Grundlagen der objektorientierten Analyse


Geschichtliche Entwicklung der Objektorientierten Analyse

1980 wurde mit der Programmiersprache Smalltalk-80 die Ära derOOP 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.


objektorientierte Analyse (OOA, object oriented analysis)

Die objektorientierten Grundkonzepte zusammen mit diesen Erweiterungen bilden die

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.


Abb.: OO-Grundkonzepte und OOA-Konzepte

OO-Grundkonzepte

Objekt Botschaft

Klasse Vererbung

Attribut Poly-

Operation morphismus

Assoziation Aggregation

Subsystem

Zustandsautomat

Interaktionsdiagramm

OOA-Konzepte


Teilmodelle gliedern. (nach Heide Balzert)

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

Assoziation Aggregation

Statisches Modell

Vererbung Subsystem

Botschaft Interaktions-Diagramm

Dynamisches Modell

Objekt-Lebenszyklus Spezifikation

Objekt / Klasse Attribut

Basismodell

Operation Poly-morphismus


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


Assoziation zwischen Objekten

(Kunde)Schulz

Dortmund

(Zahlungsverzug)1500.-

15.07.95

(Zahlungsverzug)2000.-

10.05.95

hat

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.


Zunächst werden nur binäre Assoziationen betrachtet,

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.


Als Synonyme für die Assoziationen sind die Begriffe

instance connection, (object) relationship und acquaintance gebräuchlich.

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.


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.


Man unterscheidet Muß- und Kann-Beziehungen 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 ...


Konzeptionelle Details

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:

Firma Mitarbeiter PKWArbeit-geber

0, m

1

0, 1

0,1

Arbeit-nehmer

Fahrer

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.


geordneten Assoziationen

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

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.


In der Fallstudie „Seminarorganisation“

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.

Kunde

BuchungAngemeldet amAbgemeldet amÄnderungsmitteilung amRechnung amAnmeldenAbmelden

Seminar-veranstaltung

1

1

0, m

0, m


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.


Abb. Assoziation versus Aggregation

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.

Mitarbeiter

KarosserieRadMotor

Auto

41

0, 10, 10, 1

0, 1

0, 1

1

Hierarchie zwischen den Klassen


Weitere Beispiele sind: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.


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.


SubsystemDie 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


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.

1. Subsystem 1

1. Subsystem 1

Klasse 1Klasse 2Klasse 3

Klasse 1

Klasse 2 Klasse 3

1

c

b

a

1

11Notation: Subsysteme


Das Subsystem soll eine logische Einheit bilden,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.


OOA-MusterDie 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.


Muster 4: Koordination von Objekten

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

BuchAutorTitel

Kaufen

BuchexemplarInventur-Nr

Ausgeliehen amAusleihen

Zurückgeben

Es gibt Klassen, die selbst kaum Attribute / Operationen besitzen, aber mit vielen anderen Klassen in Beziehung stehen und sie koordinieren.

0, m

1


Muster 6: Ereignisse registrierenSollen 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.


Beispiel: Wechselnde Rollen

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.

G.Heyer Digitale Informationsverarbeitung 1 Ziele: ã Darstellen können, aus welchen Teilmodellen...

Documents

Transcript of G.Heyer Digitale Informationsverarbeitung 1 Ziele: ã Darstellen können, aus welchen Teilmodellen...