Aggregation wird verwendet, um eine Kompositionsbeziehung zwischen Modellelementen zu modellieren. Es gibt viele
Beispiele für Kompositionsbeziehungen: Eine Bibliothek enthält Bücher, in einem Unternehmen setzen sich
Abteilungen aus Mitarbeitern zusammen, und ein Computer besteht aus vielen Einheiten. Um
dies zu modellieren, hat das Aggregat (Abteilung) eine Aggregationsassoziation zu ihren Bestandteilen
(Mitarbeiter).
Am Ende eines Assoziationspfades befindet sich auf der Seite des Aggregats (dem Ganzen) eine ungefüllte Raute, die auf
die Aggregation hinweist.
Beispiel
In diesem Beispiel hat ein Kunde eine Adresse. Die Aggregation wird deshalb hier verwendet, weil die
beiden Klassen Teile eines großen Ganzen darstellen. Adresse wird als separate Klasse modelliert, weil es noch
viele andere Dinge gibt, die ebenfalls Adressen haben können.
Ein Aggregatobjekt kann andere Objekte zusammenhalten.
Eine Aggregationsbeziehung, die eine Multiplizität größer als eins für das Aggregat zulässt, wird als
Mehrfachaggregation bezeichnet. Wenn das Aggregat gelöscht wird, werden damit nicht unbedingt auch die
Bestandteile gelöscht. Dies impliziert, dass eine Mehrfachaggregation einen Graphen oder eine Baumstruktur mit vielen
Wurzeln bildet. Mehrfachaggregationen werden verwendet, wenn eine enge Beziehung zwischen zwei Klassen herrscht, so
dass dieselbe Instanz in zwei unterschiedlichen Aggregationen verwendet werden kann.
Beispiel
Stellen Sie sich vor, eine Person hat ihr Büro im Wohnhaus. Sowohl die Person als auch das Büro haben eine Anschrift.
In diesem Fall handelt es sich um dieselbe Anschrift. Die Anschrift ist ein integraler Bestandteil der Person
und des Büros. Wenn die Person das Büro auflöst, muss dies jedoch nicht heißen, dass die Person auch die Wohnung
auflöst und damit die Anschrift wechselt.
Man könnte in diesem Fall auch mit einer Mehrfachaggregation beginnen und später dann auf eine einfache Aggregation
umstellen. Das Heimbüro könnte wachsen und gedeihen und schließlich in ein eigenes Gebäude umgezogen werden. Von diesem
Zeitpunkt an haben die Person und das Büro nicht mehr dieselbe Anschrift. Deshalb löst sich die Mehrfachaggregation
auf.
Ein Beispiel für Mehrfachaggregation.
Komposition ist eine Form der Aggregation mit enger Eignerbeziehung, in der die Lebenszeit des Bestandteils mit
der des Aggregats vollständig übereinstimmt. Die Multiplizität des Aggregatendes (in dem Beispiel der Auftrag)
darf eins nicht überschreiten (d. h. Mehrfachaggregation nicht möglich). Außerdem ist die Aggregation nicht
modifizierbar, d. h., sobald die Aggregation hergestellt ist, können die Verknüpfungen nicht mehr geändert werden. Dies
impliziert, dass eine Kompositionsaggregation eine Baumstruktur mit Bestandteilen bildet, in der das Aggregat die
Wurzel und die Bestandteile die Zweige sind.
Eine Kompositionsaggregation ist einer einfachen Aggregation vorzuziehen, wenn eine starke gegenseitige
Abhängigkeitsbeziehung zwischen dem Aggregat und den Bestandteilen besteht und die Definition des Aggregats ohne die
Bestandteile unvollständig ist. Im folgenden Beispiel macht es selbst dann Sinn, einen Auftrag zu haben, wenn
nichts bestellt ist (d. h. der Auftrag keine Positionen hat). Manchmal kann diese gegenseitige Abhängigkeit
bereits bei der Analyse (wie in diesem Beispiel) festgelegt werden, aber häufiger können derartige Entscheidungen erst
zuverlässig während des Designs getroffen werden.
Wie im folgenden Beispiel gezeigt, befindet sich zur Kennzeichnung der Komposition am Ende eines Assoziationspfades
eine gefüllte Raute:
Ein Beispiel für Kompositionsaggregation
Beispiel
In diesem Beispiel setzt sich die Kundenschnittstelle aus mehreren anderen Klassen zusammen. In diesem Beispiel
sind die Multiplizitäten der Aggregationen noch nicht definiert.
Ein Objekt Kundenschnittstelle weiß, welche Objekte Bildschirm, Belegdrucker, Tastenfeld und
Lautsprecher zu ihm gehören.
Eine Eigenschaft einer Klasse ist etwas, das die Klasse ausmacht. Für die Klasse Kunde (s. o.) könnte man
beispielsweise die Adresse wie gezeigt als Klasse oder als Gruppe von Attributen der Klasse modellieren. Ob eine
Klasse und die Aggregationsbeziehung oder eine Gruppe von Attributen verwendet wird, hängt von der Beantwortung der
folgenden Fragen ab:
-
Müssen die 'Eigenschaften' eine unabhängige Identität haben, so dass sie von mehreren Objekten referenziert werden
können? Wenn ja, verwenden Sie eine Klasse und Aggregation.
-
Müssen mehrere Klassen dieselben 'Eigenschaften' haben? Wenn ja, verwenden Sie eine Klasse und Aggregation.
-
Haben die 'Eigenschaften' eine komplexe Struktur und eigene Eigenschaften? Wenn ja, verwenden Sie Klassen und
Aggregation.
-
In allen anderen Fällen verwenden Sie Attribute.
Beispiel
Bei einem Geldausgabeautomaten muss das System den aktuellen Kunden und seine PIN überwachen. Angenommen, die
Kundenschnittstelle ist dafür verantwortlich. Sie können sich die Informationen als "Eigenschaften" der Klasse
vorstellen. Diese Aufgabe kann mit einer separaten Klasse bewältigt werden, wie das folgende Beispiel zeigt:
Durch Aggregation modellierte Objekteigenschaften
Die Alternative, nämlich den Kunden und die PIN von der Kundenschnittstelle mit Attributen überwachen zu lassen,
wird folgendermaßen modelliert:
Durch Attribute modellierte Objekteigenschaften
Ob eine Aggregationsassoziation zu einer separaten Klasse oder Attribute verwendet werden, richtet sich nach dem Grad
der Koppelung zwischen den dargestellten Konzepten. Wenn die zu modellierenden Konzepte eng miteinander verbunden sind,
verwenden Sie Attribute. Wenn die Konzepte eher unabhängig voneinander geändert werden, verwenden Sie Aggregation.
Aggregation sollte nur verwendet werden, wenn eine Kompositionsbeziehung zwischen Klassen besteht und sich eine Klasse
aus anderen Klassen zusammensetzt und die "Bestandteile" außerhalb des Gesamtkontextes unvollständig sind. Denken Sie
an einen Auftrag: Es macht keinen Sinn, einen "leeren" Auftrag zu haben, der "nichts" enthält. Dasselbe gilt für
alle Aggregate: Abteilungen müssen Mitarbeiter haben, Familien müssen Familienmitglieder haben usw.
Wenn die Klassen außerhalb des Kontextes anderer Klassen eine unabhängige Identität haben können und nicht Bestandteil
eines größeren Ganzen sind, sollte die Assoziationsbeziehung verwendet werden. Im Zweifelsfall ist eine Assoziation
immer vorzuziehen. Aggregationen sind im Allgemeinen klar erkennbar. Aggregation wird nur ausgewählt, um den
Sachverhalt zu verdeutlichen, und ist nichts, was sich entscheidend auf den Erfolg der Modellierung auswirkt.
Manchmal kann eine Klasse mit sich selbst aggregiert werden. Das bedeutet nicht, dass eine Instanz dieser Klasse aus
sich selbst besteht (das wäre unsinnig). Es bedeutet vielmehr, dass eine Instanz der Klasse ein Aggregat ist, das sich
aus anderen Instanzen derselben Klasse zusammensetzt. Bei Selbstaggregationen sind Rollennamen von entscheidender
Bedeutung, um den Zweck der Assoziation abzuleiten.
Beispiel
Sehen Sie sich die folgende Selbstaggregation mit der Klasse Produkt an:
In diesem Beispiel kann sich ein Produkt aus anderen Produkten zusammensetzen, die dann als Unterprodukte bezeichnet
werden. Die einzige Navigationsrichtung in der Assoziation ist vom Aggregat zum Unterprodukt, d. h. Unterprodukte
wissen nicht, zu welchen Produkten sie gehören (da sie zu vielen Produkten gehören können).
|