Assoziationen

Wie im E-R-Modell bestehen zwischen den Klassen und den dazu gehörigen Objekten Beziehungen, die wir als Assoziationen bezeichnen. Auch hier spielen die kennen gelernten Multiplizitäten eine wichtige Rolle: sie geben an, wie viele Objektbeziehungen von einem Objekt einer Klasse ausgehen können.

Im Klassendiagramm sieht die Assoziation folgendermaßen aus:

Assoziationen zwischen Klassen beschreiben – im Gegensatz zu den Beziehungen zwischen Objekten – die statische Struktur des Systems.
Wir können festhalten:
Eine Objektbeziehung verbindet Objekte zu einem bestimmten Zeitpunkt (Kunde Dr. Müller hat zum Zeitpunkt x zwei Aufträge ausgelöst).
Eine Assoziation beschreibt die grundsätzlichen Möglichkeiten der Objektbeziehungen zwischen den Objekten der jeweiligen Klassen – ohne Rücksicht darauf, einen bestimmten Zeitpunkt hierbei zu beachten.

1 Arten von Assoziationen

In der UML unterscheiden wir zwischen binären und höherwertigeren Assoziationen, wobei wir lediglich die binären näher betrachten wollen, welche die (möglichen) Beziehungen zwischen zwei Objekten beschreiben.

Für den Fall, dass aus der Klasse Angestellter sowohl die Vorgesetzten als auch deren Untergebene entstehen sollen: Wie könnte in der UML diese Beziehung mittels Assoziation dargestellt werden?

Versuchen wir, diese mögliche Beziehung zwischen zwei Objekten ein und derselben Klasse Angestellter (ohne die gesamten Attribute und Operationen aufzulisten) mittels Assoziation darzustellen.

In diesem Falle spricht man in der UML von einer sog. reflexiven Assoziation, welche die Objekte ein und derselben Klasse miteinander verbindet.

Wir halten fest: Die Assoziation in Form einer Linie zwischen einer oder zwei Klassen sagt aus, dass die Objekte dieser Klasse(n) sich kennen.

2 Multiplizitäten

Auch in Verbindung mit den Assoziationen spielen die Multiplizitäten eine wichtige Rolle: Sie beschreiben, wie viele Objekte (der eigenen oder anderer Klassen) ein einzelnes bestimmtes Objekt kennen können.

Eine andere Möglichkeit wäre folgende:

Bei vielen Klassendiagrammen ist die 1 die Untergrenze bei den Multiplizitäten, womit das Korsett der Möglichkeiten relativ eng geschnürt ist, und nur wenige Freiheiten bleiben, der Realität gerecht zu werden. Stattdessen sollte im Zweifelsfall die 0 als Untergrenze gewählt werden.

Fassen wir zusammen:

3 Rollenspiel

Um ein Klassendiagramm verständlicher zu gestalten, kann man ihm sog. Rollennamen hinzufügen.
So werden die Daten einer Bestellung im Shop in der Klasse Auftrag gespeichert. Der Name der Klasse wurde aus Sicht des Anwenders im Shop gewählt. Aus der Sicht des Kunden handelt es sich jedoch wahrscheinlich um eine Bestellung. Der Kunde wiederum ist aus der Sicht des Auftrages der Besteller. In der UML werden diese Informationen als Assoziationsenden (association ends) bezeichnet und folgendermaßen eingefügt:

4 Assoziationsnamen

Ähnlich dem E-R-Modell besteht auch im Klassendiagramm die Möglichkeit, die Assoziationen mittels Assoziationsnamen näher zu bezeichnen:

Zusammenfassend kann festgehalten werden: Der Assoziationsname beschreibt – wie im semantischen Modell – die Bedeutung einer Assoziation. Der Rollenname enthält Informationen darüber, welche Rolle eine Klasse bzw. eines ihrer Objekte innerhalb einer Assoziation hat. Folgende Beispiele sollen das verdeutlichen:

Zwei Assoziationen mit Rollennamen:

Wie bereits erwähnt, entstammt das Konzept der Assoziationen den Relationships der semantischen Datenmodellierung. Im E-R-Modell werden Beziehungen zwischen den Datensätzen verschiedener Tabellen durch Verbindungen zwischen Primärschlüsseln und Fremdschlüsseln erstellt. Klassen dürfen und brauchen hingegen weder Primär- noch Fremdschlüssel enthalten.

5 Assoziationsklassen

Aus dem Fax-Formular geht hervor, dass ein Artikel Bestandteil von mehreren Aufträgen sein kann, und dass ein Auftrag mehrere Artikel enthalten kann. Worüber im Klassendiagramm bislang keine Aussage gemacht werden kann, ist die Stückzahl, mit welcher der Artikel im Auftrag vertreten ist.
Hier bietet sich die Möglichkeit, die Anzahl im Rahmen der neuen Klasse Position in das Klassendiagramm mit aufzunehmen:

Die Folge ist, dass wir aus einer Assoziation eine Assoziationsklasse (association class) machen, welche sowohl die Eigenschaften einer Klasse als auch einer Assoziation hat.

Unser Klassendiagramm wird nun folgendermaßen erweitert:

In Bezug auf die Assoziationsklasse ist zu beachten, dass diese beim Übergang zu den objektorientierten Programmiersprachen in eine eigenständige Klasse und zwei Assoziationen nach folgendem Schema aufzulösen ist:

Für unser Klassendiagramm hat das folgende Auswirkungen: