Assoziationen und Kardinalitäten
Aus Informatik
Inhaltsverzeichnis |
Fallstudie
Die schon bekannte Firma ProfiSoft erhält von verschiedenen Kunden Aufträge. Dabei gelten folgende Vereinbarungen:
- 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.
- Ein Kunde kann keinen, aber auch mehrere Aufträge erteilen.
- Jeder Auftrag gehört genau zu einem Kunden.
Mit den bisher bekannten Vereinbarungen für die Firma ProfiSoft sind nun folgende Klassen vereinbart:
Zwischen den Kundenobjekten und den Auftragsobjekten entstehen Verbindungen: Ein Kunde kann mehrere Aufträge erteilen, ein Auftrag gehört genau zu einem Kunden.
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. |
UML - Darstellung (Objektdiagramm)
In Objektdiagrammen werden Assoziationen durch einfache Linien zwischen den in Beziehung stehenden Objekten eingezeichnet:
UML - Darstellung (Klassendiagramm)
In der Regel zeichnet man Assoziationen jedoch in ein Klassendiagramm ein. Zwischen zwei Klassen wird ebenfalls eine Linie eingezeichnet. Zusätzlich wird ein Assoziationsname vergeben. An den Ende der Linie können (offene) Pfeilspitzen eingetragen werden.
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.
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.
Besitzt eine Linie keine Pfeile, bedeutet dies, dass noch nicht festgelegt wurde, ob eine uni- oder bidirektionale Assoziation vorliegen soll.
Multiplizität (Kardinalitäten)
Zusätzlich zur Richtung ist auch die Angabe der Art der Assoziation notwendig. Man unterscheidet hier zwischen
- Kann-Beziehung
- 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, muss 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).
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 & Komposition
| 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, 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 genau 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.
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.
Die Unterscheidung zwischen einer allgemeinen Assoziation und einer Aggregation ist in vielen Fällen schwierig. In vielen Quellen wird schon die Verwendung mehrerer Referenzen als Aggregation gedeutet. Im obigen Beispiel würde damit zwischen Kunden und Aufträgen eine Assoziatin 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 ...
Beispiel "Autowaschanlage Tankstelle OSSE"
In der Übungsaufgabe zur Verwaltung einer Autowaschanlage (Lösung) sollten eine Reihe von Autos verwaltet werden. Hier liegt eine unidirektionale Aggregation vor, da die Klasse Warteschlange die Autos in die Schlange einreiht und auch wieder entfernt; es entsteht eine Art Hierarchie zwischen der Warteschlange und den Autos. Zum Anlegen einer Verbindung besitzt die Klasse Warteschlange die Methode neuesAuto(), zum Abfragen die Methode getAuto().
