4.3 Beziehungen zwischen Objekten 

In Abbildung 4.10 haben wir bereits eine ganze Reihe von Beziehungen zwischen handelnden Personen der griechischen Mythologie dargestellt. Dabei haben Sie gesehen, dass Objekte in den unterschiedlichsten Beziehungen zueinander stehen können.

Wenn man in der objektorientierten Welt von Beziehungen spricht, unterscheidet man grundsätzlich drei Arten von Beziehungen:

Beziehungen zwischen Klassen und Objekten

• Beziehungen zwischen Klassen und Objekten Eine solche Beziehung, die Klassifizierung, haben wir in Abschnitt 4.2.1 kennengelernt. Die Klassifizierung beschreibt eine Beziehung zwischen einer Klasse und ihren Exemplaren. Das Objekt Plato steht zum Beispiel in so einer Beziehung mit der Klasse Mann, denn Plato ist ein Mann (oder auch ein Exemplar der Klasse Mann). In Abbildung 4.21 sehen Sie diese Beziehung an Markierung .

Beziehungen zwischen Klassen

• Beziehungen zwischen Klassen untereinander Weil Plato ein Mann ist, und ein Mann eine Person, ist Plato sterblich, denn jede Person ist sterblich. Es besteht also eine Beziehung zwischen der Klasse der sterblichen Objekte und der Klasse Person – die Klasse Person ist eine Unterklasse der Klasse Sterblich. Und da jeder Mann eine Person ist, ist die Klasse Person eine Oberklasse der Klasse Mann. In Abbildung 4.21 wird dieser Zusammenhang an Markierung dargestellt.

• • Den Beziehungen zwischen den Ober- und Unterklassen werden wir uns in Abschnitt 5.1.1, »Hierarchien von Klassen und Unterklassen«, widmen.

Beziehungen zwischen Objekten

• Beziehungen zwischen Objekten untereinander Aristoteles hatte einen Lehrer, Plato, und einen bekannten Schüler, Alexander den Großen. Dies sind Beispiele einer Beziehung zwischen konkreten Objekten, denen wir uns jetzt widmen werden. In Abbildung 4.21 sehen Sie diese Beziehungen an den Markierungen und .

Abbildung 4.21    UML-Darstellung der Beziehungen von Aristoteles

Assoziation, Aggregation und Komposition

Beziehungen zwischen verschiedenen Objekten werden ganz allgemein auch Assoziation genannt. [Obwohl in UML eine Assoziation als eine Linie zwischen den Klassenkästchen dargestellt wird, ist eine Assoziation eine Beziehung zwischen Objekten – den Exemplaren dieser Klassen. Ein Beispiel einer Beziehung zwischen Klassen wäre die Generalisierung, der wir uns in Abschnitt 5.1.1, »Hierarchien von Klassen und Unterklassen«, widmen werden. ] Außerdem gibt es spezielle Formen von Assoziationen.

Beziehungen zwischen einem Objekt und seinen Teilen werden Aggregation beziehungsweise Komposition genannt. Die Unterscheidung zwischen Aggregation und Komposition ist recht subtil und hängt häufig nur von der Betrachtungsweise des Entwicklers ab. Wir werden uns der Aggregation und der Komposition in Abschnitt 4.3.8 näher widmen.

Assoziationen zwischen Objekten

Schauen wir uns im Folgenden an, was wir über die Assoziationen zwischen Objekten sagen können.

Eine Assoziation hat immer eine semantische Bedeutung. Zwei oder mehrere Objekte können zueinander in verschiedenen Beziehungen stehen. So wie im Leben zwei Menschen in der Beziehung Elternteil – Kind und unabhängig davon in der Beziehung Lieferant – Kunde zueinander stehen können. [Wir werden uns in diesem Buch nicht allen Details der Fähigkeiten der UML widmen, eine tiefer gehende Beschreibung können Sie in [Kecher 2006] finden. ]

4.3.1 Rollen und Richtung einer Assoziation 

Die Beziehungen zwischen Objekten sind meistens nicht symmetrisch, das heißt, dass jedes Objekt eine unterschiedliche Rolle in der Beziehung einnimmt. Wir können sagen, dass Zeus auf dem Olymp wohnt, nicht aber der Olymp auf dem Zeus. Die Bezeichnung einer Beziehung hat also eine Richtung.

Abbildung 4.22    Rolle und Richtung einer Assoziation

4.3.2 Navigierbarkeit 

Eine weitere wichtige Eigenschaft einer Beziehung ist ihre Navigierbarkeit. Nehmen wir an, es besteht eine Assoziation schickt Werbung zwischen den Exemplaren der Klasse Firma und der Klasse Person. Die Firma kann alle Personen auflisten, denen sie Werbung zuschickt. Eine Person hat aber keine Liste der Firmen, die sie mit Werbung belästigen. Wir sagen, dass die Assoziation schickt Werbung in der Richtung Firma-Person navigierbar ist, nicht jedoch in der Richtung Person-Firma. Die Navigierbarkeit wird meistens in den Designmodellen angegeben, in den Analysemodellen spielt die Navigierbarkeit selten eine Rolle.

Abbildung 4.23    Navigierbarkeit einer Assoziation

4.3.3 Multiplizität  

Die Multiplizität einer Beziehung sagt aus, wie viele Objekte des jeweiligen Typs in dieser Beziehung stehen können.

Dateien im Dateisystem

Nehmen Sie zum Beispiel ein Modell für ein einfaches Dateisystem, in dem jede Datei immer in genau einem Verzeichnis liegt. Ein Verzeichnis kann aber leer sein, oder es kann eine oder mehrere Dateien enthalten. Der Bereich für die mögliche beziehungsweise nötige Anzahl der Objekte in einer solchen Beziehung wird als die Multiplizität dieser Beziehung bezeichnet.

Multiplizität

Die Multiplizität einer Beziehung zwischen Klassen legt die mögliche Anzahl der an der Beziehung beteiligten Exemplare fest. Dabei sprechen wir von der Multiplizität einer Rolle in der Beziehung, wenn wir nur eine der beteiligten Klassen sowie deren Rolle in der Beziehung betrachten. In UML wird die Multiplizität einer Klasse in einer Beziehung als eine Auflistung der möglichen Anzahl von Exemplaren angegeben. Diese Angabe wird einfach in der Nähe des einen Endes der Beziehung bei der betroffenen Klasse dargestellt. Intervalle werden als »min .. max« angegeben. Ein Stern bedeutet dabei »beliebig viele«. Das Intervall »0..*« kann also auch als »*« angegeben werden. Neben den Multiplizitäten in einer Beziehung gibt es auch noch die reine Multiplizität einer Klasse. Diese legt fest, wie viele Exemplare dieser Klasse überhaupt existieren können oder müssen. So ist die Multiplizität einer Singleton-Klasse16 in der Regel 0 ... 1, das heißt es kann maximal ein Exemplar davon existieren.

In Abbildung 4.24 wird das Konzept der Multiplizität und deren Darstellung in UML verdeutlicht.

An Markierung ist eine Assoziation liegt in zwischen Exemplaren der Klasse Stadt und der Klasse Land dargestellt. Die Assoziation wird durch eine Linie repräsentiert, die an der Klasse Stadt anfängt und an der Klasse Land endet. Eine Stadt liegt nach unserem Modell in genau einem Land. In einem Land muss es mindestens eine Stadt geben, nach oben ist die Zahl der Städte aber unbegrenzt. Damit ist die Multiplizität der Rolle Stadt in der beschriebenen Beziehung 1..*, die Multiplizität der Rolle Land ist genau 1. Die Multiplizität der gesamten Beziehung liegt in ist damit 1..* zu 1.

Abbildung 4.24    Mehrwertige Beziehungen in UML

Ein weiteres Beispiel ist die Beziehung Elternteil-Kind, die an Markierung von Abbildung 4.24 dargestellt ist. Diese Beziehung besteht zwischen Exemplaren der Klasse Person. Solche Beziehungen zwischen Exemplaren derselben Klasse werden reflexiv genannt. Die Multiplizität der Rolle Kind ist * (also beliebig viele), denn es gibt Menschen, die keine Kinder haben, und Menschen, die ein oder mehrere Kinder haben. Wie sieht es aber mit der Multiplizität der Rolle Elternteil aus? Wenn wir zum Beispiel eine genealogische Anwendung schreiben, würde man spontan sagen, dass sie 2 ist, denn jeder Mensch hat genau eine biologische Mutter und genau einen biologischen Vater. In der Abbildung sehen Sie aber, dass die Multiplizität der Rolle Elternteil als 0..2 modelliert ist.

Dies liegt daran, dass Sie in der praktischen Verwendung der Beziehung in ein logisches Problem laufen, wenn Sie für jede Person fordern, dass auch die zugehörigen Eltern bekannt sein sollen. Da für jeden eingefügten Elternteil (auch wieder eine Person) gefordert würde, dass auch für diesen bereits die Eltern bekannt sind, kommen Sie beim Versuch, einen konsistenten Datenbestand zu erstellen, in eine nicht terminierende Rekursion. Deshalb wird die Beziehung so modelliert, dass zu einer Person die Eltern auch einfach unbekannt sein können, also die Rolle Elternteil die Multiplizität 0..2 erhält.

Mögliche Multiplizitäten

Im Beispiel haben Sie bereits einige der möglichen Multiplizitäten gesehen. Am häufigsten werden Sie in Modellen auf Beziehungen mit folgenden Multiplizitäten treffen:

Ein Objekt steht in einer Beziehung mit

• genau einem anderen Objekt.

• keinem oder einem anderen Objekt.

• mindestens einem anderen Objekt.

• beliebig vielen anderen Objekten.

Es kann aber durchaus Beziehungen mit anderen Multiplizitäten geben. Zum Beispiel in der Beziehung Tennismatch-Spieler, die ebenfalls in Abbildung 4.24 dargestellt ist, ist die Multiplizität der Spieler zwei oder vier.

Mehrwertige Beziehungen

Wenn die obere Schranke der Multiplizität einer Beziehung größer als 1 ist (z. B. *), die Beziehung also mehrwertig ist, können wir uns Gedanken über die Struktur der Objekte am mehrwertigen Ende der Beziehung machen. Wenn die Objekte in dieser Beziehung eine definierte Reihenfolge haben, sagt man, dass die Beziehung geordnet ist.

Eine weitere Frage, die wir uns stellen können, ist die Frage, ob ein Objekt in der Beziehung mehrfach aufgelistet sein kann. Ein Team kann aus mehreren Spielern bestehen, ein konkreter Spieler kann aber nicht mehrfach in einem Team auftauchen. Eine Reiseroute kann durch mehrere Städte führen, dabei kann eine Stadt in einer Route mehrfach durchlaufen werden.

Mehrwertige Beziehungen als Menge

Wenn nichts Abweichendes angegeben ist, verstehen wir eine mehrwertige Beziehung üblicherweise als eine Menge (englisch Set) ohne definierte Ordnung, in der ein Objekt nur einmal auftreten kann. Ist die Reihenfolge definiert, gilt für die Beziehung die Einschränkung {ordered} oder {ordered set}, je nachdem, ob ein Objekt mehrfach auftreten kann. Es gibt auch den Fall, in dem ein Objekt zwar mehrfach auftreten kann, die Ordnung aber trotzdem keine Rolle spielt. Diese Art der Beziehung wird im Englischen als Bag, im Deutschen als Korb bezeichnet. Ein Beispiel einer solchen Beziehung wäre die Liste der Abonnenten einer Zeitschrift, wenn der Verlag kein Aussortieren von Dubletten vorgenommen hat. Ein Kunde kann eine Zeitschrift mehrfach abonniert haben, die Reihenfolge, in der die Zeitschrift versendet wird, spielt aber keine Rolle.

Abbildung 4.25    Zusatzinformationen zu Beziehungen in UML

4.3.4 Qualifikatoren 

Manchmal kann man über die Multiplizität einer Beziehung eine genauere Aussage treffen. Zum Beispiel kann ein Mensch im Laufe seines Lebens mehrere Ehepartner haben. Doch zu einem Zeitpunkt, zumindest in unserem Kulturkreis, kann ein Mensch höchstens einen Ehepartner haben. Ein anderes Beispiel ist die Beziehung zwischen einer Firma und ihren Kunden. Eine Firma kann viele Kunden haben, aber durch eine Kundennummer kann sie einen ihrer Kunden eindeutig identifizieren. Pro Kundennummer hat eine Firma also genau einen Kunden.

Diese Informationen über die Multiplizität einer mehrwertigen Beziehung können wir durch die Angabe der Qualifikatoren ausdrücken. Mithilfe eines Qualifikators kann man aus vielen Objekten an einem mehrwertigen Ende einer Beziehung bestimmte Objekte auswählen.

Abbildung 4.26    Qualifikatoren der Beziehungen in UML

In der Beziehung Ehe ist zum Beispiel ein Zeitpunkt ein Qualifikator, der es uns ermöglicht, einen konkreten Ehepartner eines mehrmals verheirateten Menschen genau zu bestimmen. Die Kundennummer ist wiederum ein solcher Qualifikator in der Beziehung zwischen einer Firma und seinen Kunden.

4.3.5 Beziehungsklassen, Attribute einer Beziehung 

Schauen wir uns jetzt die Beziehung Job zwischen den Klassen Person und Firma an.

Abbildung 4.27    Beziehungsklasse in UML

Es gibt Personen ohne Job, eine Person kann aber auch mehrere Jobs haben. Eine Firma hat (zumindest in unserem Modell) immer mindestens einen Beschäftigten, sei es der Unternehmer selbst. Die Multiplizität der Rolle Arbeitgeber ist also 0..*, die der Rolle Arbeitnehmer 1..*.

Obwohl die Reihenfolge der Mitarbeiter keine Rolle spielt und wir deswegen die Beziehung in Richtung Firma-Person als eine Menge (Set) modelliert haben, ist es doch wichtig zu wissen, welche Funktion ein Mitarbeiter in einer Firma hat. Und wichtig ist auch, zumindest für die meisten von uns, die in einer solchen Beziehung stehen, wie hoch das Gehalt [Wir meinen hier sowohl die Löhne als auch die Gehälter. ] eines Menschen in einer Firma ist.

Welcher Klasse können wir diese Informationen zuordnen? Offensichtlich können wir die Attribute Funktion und Gehalt nicht der Klasse Firma zuordnen, denn dann müssten alle Mitarbeiter die gleiche Funktion haben und dasselbe Gehalt verdienen.

Würden wir diese Attribute der Klasse Person zuordnen, könnte zwar jeder Mitarbeiter eine eigene Funktion und sein eigenes Gehalt haben, allerdings müssten die Funktion und sein Gehalt bei jeder Firma gleich sein. Außerdem hätten diese Attribute bei einem Menschen ohne Job keine Bedeutung. [Würden wir ein Personalverwaltungssystem für einen Arbeitgeber entwickeln, könnten wir durchaus die Attribute Funktion und Gehalt der Klasse Mitarbeiter zuordnen. Ein Mensch kann zwar mehrere Jobs haben, für unser System wäre dies aber nicht relevant. Die Jobs, die ein Mitarbeiter bei anderen Firmen hat, würden wir nicht verwalten. ]

Assoziationsklasse

Die Lösung unserer Aufgabe ist, die Attribute weder der Klasse Firma noch der Klasse Person zuzuordnen, sondern der Beziehung Job selbst. In diesem Falle spricht man von einer Assoziationsklasse oder auch einer Beziehungsklasse.

Abbildung 4.28    Alternative Darstellung einer Beziehungsklasse

4.3.6 Implementierung von Beziehungen 

Beziehungen unterscheiden sich unter anderem durch ihre Multiplizität, ihre Navigierbarkeit; die mehrwertigen können geordnet oder ungeordnet sein; ein Objekt kann einmal oder mehrfach auftreten. Es gibt also sehr viele Varianten von Beziehungen. Aus diesem Grunde findet man in den gängigen Programmiersprachen keine speziellen Konstrukte für die Umsetzung der Beziehungen.

Umsetzung von Beziehungen

Stattdessen verwendet man bei einwertigen Beziehungen in dem Objekt, von dem die Beziehung navigierbar ist, meistens Zeiger oder Referenzen, die zu dem anderen Objekt zeigen.

Eine beidseitig navigierbare Beziehung wird am häufigsten implementiert durch zwei Zeiger oder Referenzen, die programmtechnisch synchron gehalten werden müssen.

Die mehrwertigen Beziehungen werden auf verschiedene Arten umgesetzt. Verwendet werden Arrays, Listen, Mengen oder andere Containerkonstrukte, die in der jeweiligen Programmiersprache vorhanden sind oder die man selbst implementiert.

Beziehungsklassen werden als gewöhnliche Klassen implementiert.

Listing 4.12 stellt die Umsetzung von verschiedenen Beziehungen in Java dar. Wir zeigen dabei eine mögliche Umsetzung einer beidseitig navigierbaren Mengenbeziehung Person–Adresse. Eine Person kann mehrere Adressen haben, und unter einer Adresse kann man mehrere Personen finden.

class Person { 
  private Set<Address> addresses = new HashSet<Address>(); 
  // Hier verwalten wir eine Richtung der Beziehung 
  // Person-Address: 
  public void addAddress(Address address) { 
    if (addresses.contains(address)) return; 
    adresses.add(address); 
    address.addPerson(this); // die andere Richtung pflegen 
  } 
  ... 
} 
 
class Address { 
private Set<Person> people = new HashSet<Person>(); 
  // Hier verwalten wir eine Richtung der Beziehung 
  // Person-Address: 
  public void addPerson(Person person) { 
    if (people.contains(person)) return; 
    people.add(person); 
    person.addAddress(this); // die andere Richtung pflegen 
  } 
  ... 
}

Listing 4.12    Abbildung von Beziehungen auf Klassen

4.3.7 Komposition und Aggregation 

Bisher haben wir uns die Beziehungen zwischen verschiedenen Objekten angeschaut. Doch ein Objekt selbst kann eine komplexe Struktur besitzen, und wir können die Beziehungen zwischen dem Objekt und seinen Teilen modellieren. Dabei unterscheiden wir zwischen Komposition und Aggregation.

Sowohl die Komposition als auch die Aggregation sind Teil-von- bzw. Besteht-aus-Beziehungen. Wir können zum Beispiel modellieren, dass eine Bestellung aus den Bestellungsposten oder dass eine Fußballmannschaft aus ihren Spielern besteht.

Unterschied Aggregation –Komposition

Eine Aggregation unterscheidet sich von einer Komposition

• in der Anzahl der zusammengesetzten Objekte, deren Teil ein Objekt sein kann, und

• in der Lebensdauer der zusammengesetzten Objekte und deren Teile.

Aggregation

Von einer Aggregation sprechen wir, wenn ein Objekt ein Teil von mehreren zusammengesetzten Objekten sein kann. Die zusammengesetzten Objekte nennen wir in diesem Fall Aggregate. Die Lebensdauer der Teile kann dabei länger sein als die Lebensdauer der Aggregate.

Ein Beispiel für eine Aggregation ist die Beziehung zwischen einer Mannschaft und ihren Spielern. Ein Mensch kann in mehreren Mannschaften spielen, und wird eine Mannschaft aufgelöst, bedeutet es in den allermeisten Fällen nicht das Ende für ihre Ex-Spieler.

Komposition

Bei einer Komposition kann ein Teil immer nur in genau einem zusammengesetzten Objekt enthalten sein, und die Lebensdauer des zusammengesetzten Objekts entspricht immer der Lebensdauer seiner Komponenten. Das zusammengesetzte Objekt wird hier als Kompositum bezeichnet.

Ein Beispiel für eine Komposition ist die Beziehung zwischen einer Bestellung und den einzelnen Posten der Bestellung. Ein Bestellungsposten gehört in genau eine Bestellung, und wird die Bestellung gelöscht, löscht man automatisch auch alle ihre Posten.

Abbildung 4.29    Aggregation und Komposition in UML

Alternativ kann man die Komposition auch darstellen wie in Abbildung 4.30 gezeigt.

Abbildung 4.30    Verschiedene alternative Darstellungen der Komposition

Einsatz von Komposition und Aggregation

Die Entscheidung, ob wir eine Beziehung als eine Aggregation, eine Komposition oder als einfache Assoziation modellieren sollten, ist oft schwierig, weil es keine festen Regeln gibt, nach denen wir unterscheiden können, welche der Möglichkeiten die geeignete ist. Die semantische Bedeutung ist in UML nur vage definiert, man spricht von einem Modellierungsplacebo. Wie wir aber wissen, Placebos wirken. Versuchen wir also ein paar Richtlinien aufzustellen, die uns bei der Entscheidung helfen, welche Variante wir einsetzen sollen.

Hierarchie

Durch die Verwendung der Komposition lässt sich sehr gut ausdrücken, dass eine Beziehung zwischen den Objekten derselben Klasse hierarchisch ist. Gute Beispiele hierfür sind Organigramme oder Dateisysteme.

Lebensdauer und Persistenz

Eine andere Information, die sich durch die Modellierung einer Komposition ausdrücken lässt, ist das Verhalten der Objekte beim Löschen oder beim Speichern des Kompositums. Da das Kompositum aus Teilen besteht, die nur als Teile des Kompositums existieren, werden sie mit dem Kompositum gelöscht beziehungsweise gespeichert. Diese Semantik betrifft jedoch die dynamischen Aspekte der Modelle, und die Klassendiagramme sind für die Darstellung der statischen Sachverhalte vorgesehen.

Datenstruktur

Eine sinnvolle Verwendung einer Komposition ist die Modellierung der Klassen in C++. Dort wird die Struktur des Speichers, in dem die Daten eines Objekts gehalten werden, explizit ausprogrammiert. Ob ein Objekt seine Teile direkt enthält oder ob es Zeiger auf andere Speicherbereiche enthält, ist eine Tatsache, die man hervorragend mit der Verwendung der Komposition ausdrücken kann. Dies ist jedoch keine allgemeine Vorgabe von UML, es ist nur ein Vorschlag, dem man bei der grafischen Darstellung der C++-Klassen in einem UML-Klassendiagramm folgen kann.

Diskussion: Komposition und Aggregation

4.3.8 Attribute 

Neben seiner Funktionalität und den Beziehungen zu anderen Objekten hat ein Objekt Attribute – Eigenschaften, die das Objekt beschreiben, und Daten, die das Objekt verwaltet. In Abschnitt 4.1.1 haben wir bereits vorgestellt, wie Eigenschaften von Objekten beschrieben werden.

Genau genommen entsprechen Attribute eines Objekts den Komponenten dieses Objekts in verschiedenen Kompositionsbeziehungen. Das Attribut-Sein und das Komponente-Sein sind zwei austauschbare Beschreibungsmöglichkeiten desselben Konzeptes. Daher entspricht die Notation für die Darstellung der Attribute in UML der kompakten Notation für die Darstellung der Komposition.

Für Attribute gilt also das Gleiche wie für die Komposition: Sie können ein- oder mehrwertig sein. Wenn sie mehrwertig sind, kann die Reihenfolge der Werte relevant oder irrelevant sein. Ein Wert kann mehrfach vorkommen, oder jeder Wert muss eindeutig sein.

Die Multiplizität des Ganzen ist bei Attributen genau wie bei der Komposition genau 1. Die Navigierbarkeit hat bei den Attributen fast immer die Richtung Zusammengesetztes Objekt-Attribut. Sollte irgendwann eine andere Art der Navigierbarkeit benötigt werden, empfehlen wir, diese Beziehung nicht als Attribut, sondern als Komposition zu modellieren.

4.3.9 Beziehungen zwischen Objekten in der Übersicht 

In Abbildung 4.31 sehen Sie noch einmal die UML-Darstellungsmöglichkeiten für Beziehungen zwischen Objekten in der Übersicht.

Abbildung 4.31    Darstellung von Beziehungen zwischen Objekten in UML

Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.