Fallstudie
Die Firma ProfiSoft erhält von verschiedenen Kunden Aufträge. Dabei gelten folgende Geschäftsregeln (Pflichtenheft) für Kunden und Aufträge:
- Zu jedem Auftrag sind folgende Daten zu speichern: Auftragsnummer, Art des Auftrags (Beratung oder Programmierung), Anzahl benötigter Stunden (default = 1), Stundensatz (default = 90) und das Auftragsdatum.
- Beim Anlegen eines Auftrags müssen die Auftragsnummer und das Auftragsdatum angegeben werden.
- Auf die Auftragsart, die Stundenzahl und den Stundensatz muss einzeln schreibend zugegriffen werden.
- Auf alle Daten muss einzeln lesend zugegriffen werden.
- Von einem Kunden sind der Name, eine Adresse und die Auftragssumme zu erfassen.
- Ein Kunde kann ohne Daten oder mit seinem Namen angelegt werden.
- Alle Daten sollen gelesen und geschrieben werden können.
Mit diesen Geschäftsregeln erhalten wir zwei Klassen Auftrag und Kunde (hier im UML-Diagramm):
Da ein Kunde nun einen Auftrag erteilen möchte, müssen wir den beiden Klassen eine Möglichkeit geben miteinander in Verbindung zu treten.
Klassen können grundsätzlich über drei Verschiedene Beziehungen verknüpft werden: Assoziation, Aggregation und Komposition. Aggregation und Komposition sind besondere Assoziationen. Die konkrete Unterscheidung ist zum Teil schwierig und nicht klar abzugrenzen, so dass in einigen Lehrwerken nur von Assoziation gesprochen wird.
In den KCGO Informatik Hessen wird zwischen Assoziation und Aggregation unterschieden. Eine Komposition wird als Aggregation eingestuft.
Assoziation
Definition: Assoziation (kennt-Beziehung; benutzt-Beziehung)
Bestehen zwischen Objekten von Klassen Beziehungen, dann spricht man von Assoziationen. Dabei kennen sich die Objekte, existieren aber unabhängig voneinander. Ein Objekt, das ein anderes Objekt kennt, verwaltet dieses nicht.
In der Regel zeichnet man Assoziationen in ein Klassendiagramm ein. Zwischen zwei Klassen wird eine Linie eingezeichnet. Am Ende der Linie kennzeichnet eine (offene) Pfeilspitze die Art der Beziehung (Assoziation).
Uni- und bidirektionale Assoziationen
Befindet sich nur an einem Ende der Linie ein Pfeil, liegt eine unidirektionale Assoziation vor. Bei dieser Art kennen alle Objekte einer Klasse die assoziierten Objekte, umgekehrt wissen diese jedoch nicht, mit wem sie verbunden sind. Beispielsweise kennt ein Objekt der Klasse Kunde (s)ein Auftrags-Objekt, umgekehrt kennt ein Objekt Auftrag nicht sein Kunde-Objekt.
Zum Verwalten seines Auftrages erhält die Klasse Kunde drei Methoden: getAAuftrag(), setAAuftrag() und removeAAuftrag().
Befinden sich an beiden Enden Pfeile, liegt eine bidirektionale Assoziation vor, d. h. alle verbundenen Objekte kennen sich gegenseitig; in diesem Fall kennt ein Objekt Kunde (s)ein Auftragsobjekt, umgekehrt kennt ein Objekt Auftrag auch (s)ein Kunde-Objekt.
Nun erhält auch die Klasse Auftrag die drei Methoden get, set und remove.
Multiplizität
Zusätzlich zur Richtung ist auch die Angabe der Art der Assoziation möglich. Man unterscheidet hier zwischen
Kann-Beziehung (Optionalität)
Eine Beziehung kann zwischen zwei Objekten bestehen, muss aber nicht, z. B. kann ein Kunde einen Auftrag erteilen …
und
Muss-Beziehung
Zwischen zwei Objekten muss eine Beziehung bestehen, z. B. ein Auftrag muss einem Kunden zugeordnet werden.
Neben der Angabe, ob eine Kann- oder Muss-Beziehung vorliegt, könnte noch angegeben werden, mit wie vielen anderen Objekten einer Klasse eine Beziehung eingegangen werden kann / muss.
Die Summe dieser Angaben wird als Multiplizität (auch Kardinalität oder Wertigkeit) bezeichnet. In der UML-Notation sind dafür folgende Darstellungen definiert:
Bezogen auf das oben diskutierte Problem (lt. Pflichtenheft), liegen folgende Vereinbarungen vor: Ein Kunde kann keinen, einen oder mehrere Aufträge erteilen (kann), ein Auftrag gehört zu genau einem Kunden (muss). Zudem kann der Assoziation ein Name vergeben werden.
Als mögliche (aber nicht zwingende) Erweiterung ist auch diese Darstellung möglich, in der für jede Richtung ein Assoziationsname vereinbart wird.
Assoziationen in Java
Die Programmierung einer Assoziation hängt davon ab, ob
- die Obergrenze der Kardinalität maximal 1 oder größer 1 ist,
- die Assoziation bidirektional oder unidirektional ist.
Ist eine Assoziation unidirektional, muss nur eine Verbindungsrichtung verwaltet werden, während bei der bidirektionalen beide verwaltet werden müssen.
Ist die Obergrenze der Kardinalität maximal 1, genügt ein einzelnes Referenz-Attribut als Zeiger auf das assoziierende Objekt. Sollen mehrere Objekte assoziiert werden, muss man auf strukturierte Datentypen zurückgreifen, z. B. Felder oder Listen.
Jede Klasse, die Objekte assoziieren soll benötigt dafür drei Operationen:
- eine Methode zum Anlegen der Verbindung (z. B. setLink(KlasseB einObjekt)),
- eine Methode zum Abfragen der Verbindung (z. B. getLink()) und
- eine Methode zum Löschen der Verbindung (z. B. removeLink()).
Die Methode zum Löschen einer Verbindung kann evtl. entfallen, da diese Aufgabe zum Teil vom garbage collector erledigt wird, der alle Objekte, auf die keine Referenzen mehr zeigen, automatisch löscht. Die Methode zum Setzen eines Links kann ebenfalls entfallen, wenn z. B. das Setzen im Konstruktor erfolgt und ein Ändern laut Geschäftsregeln (bzw. Pflichtenheft) nicht vorgesehen ist.
Aggregation
Definition: Aggregation (hat-Beziehung; besitzt-Beziehung)
Die Aggregation ist eine Sonderform der Assoziation zwischen zwei Klassen. Sie liegt dann vor, wenn zwischen den Objekten der beteiligten Klassen eine Beziehung vorliegt, die sich als „ist Teil von“, „besteht aus“ oder einfach „hat“ beschreiben lässt.
Aggregationen sind festere Beziehungen zwischen Objekten als die oben beschriebenen Assoziationen, z. B. wenn eine Rangordnung zwischen den Objekten besteht. Eine Assoziation wird in einem UML-Diagramm durch eine offene Raute an der besitzenden Seite gekennzeichnet.
In diesem Beispiel besitzt ein Tisch eine Tischplatte und kann beliebig viele Tischbeine besitzen. Eine Tischplatte gehört maximal zu einem Tisch, ebenso kann ein Tischbein maximal zu einem Tisch gehören.
Die Unterscheidung zwischen einer allgemeinen Assoziation und einer Aggregation ist in vielen Fällen schwierig. In einigen Quellen wird schon die Verwendung mehrerer Referenzen als Aggregation gedeutet. Im obigen Beispiel würde damit zwischen Kunden und Aufträgen eine Assoziation vorliegen, solange nur auf ein Objekt verwiesen wird. Kann ein Kunde mehrere Aufträge geben, müsste man diese in einem Feld oder einer Liste verwalten. Damit würde die Beziehung als Aggregation gewertet …
In Java wird eine Aggregation analog einer Assoziation umgesetzt – im angegebenen Beispiel besitzt die Klasse Tisch entsprechende Methoden zum Setzen, Abfragen und Löschen von Tischbeinen und einer Tischplatte. Die Tischplatte und die Tischbeine kennen den besitzenden Tisch nicht – daher ist die Aggregation unidirektional.
Komposition
Definition: Komposition
Die Komposition ist eine Sonderform der Aggregation. Sie drückt aus, dass die Teile von der Existenz des Ganzen abhängig sind.
Im angegebenen Beispiel besitzt das Dokument ein Inhaltsverzeichnis und kann mehrere Kapitel besitzen. Eine Komposition liegt vor, da eine Existenzabhängigkeit vorliegt; wird das Dokument gelöscht, sind auch das Inhaltsverzeichnis und das / die Kapitel gelöscht – die Unterklassen können nicht eigenständig existieren.
Eine Unterscheidung zwischen einer Komposition und einer Aggregation ist im Detail noch schwieriger als zwischen einer Aggregation und einer Assoziation. Da auch die Umsetzung in Java bis auf eine strengere Verwaltung (Löschen) identisch ist, wird in der Praxis selten eine Unterscheidung vorgenommen.
Beispiel: Assoziation – Aggregation – Komposition
Treiben wir es in einem Beispiel mal auf die Spitze … wir haben die zwei Objekte Bank und Auflage für eine Bank. Unter welchen Rahmenbedingungen liegt nun eine Assoziation, eine Aggregation bzw. eine Komposition vor.
Assoziation
Es existiert zu der Bank eine passende Auflage, die zwar zur Bank gehört aber trotzdem auch selbständig gekauft werden kann (und auch auf andere Bänke gelegt werden kann).
Aggregation
Die Bank besitzt eine spezielle pass-genaue Auflage, die nur hier passt und auch direkt mitgeliefert wird. Diese könnte u. U. auch fest angeschraubt sein (und wieder abgeschraubt werden können. Hier könnten auch mehrere Auflagen existieren, die man je nach Wunsch wechselt.
Komposition
Da hier eine existentielle Abhängigkeit bestehen muss, müsste die Auflage also unwiderruflich fest auf der Bank angebracht sein, so dass eine Abnahme nicht möglich ist. Eine Zerstörung der Bank würde auch die Auflage zerstören.
… ist halt ziemlich auf die Spitze getrieben 🙂
