Assoziation (UML)

Eine Assoziation (engl. association) ist ein Modellelement in der Unified Modeling Language (UML), einer Modellierungssprache für Software und andere Systeme.

Beispiel für eine binäre Assoziation

Beispiel für eine reflexive Assoziation

Eine Assoziation beschreibt eine Beziehung zwischen zwei oder mehr Classifiern, im häufigsten Fall eine Verbindung zwischen genau zwei Klassen. Assoziationen definieren dabei eine Beziehung auf Typebene. Auf Instanzebene nennen sich die konkreten Ausprägungen einer Assoziation Link.

Neben Klassen können aber auch beliebige andere Classifier (beispielsweise Schnittstellen oder Anwendungsfälle) mittels Assoziationen in Beziehung zueinander gesetzt werden.

Die Möglichkeit, mehr als zwei Typen an einer Assoziation zu beteiligen, wird eher selten genutzt. Die Assoziation wird in diesem Fall n-äre Assoziation genannt und durch eine Raute, an der n zu den Objekten führende Linien anliegen, dargestellt. Die Assoziation in UML ist mit dem Relationship-Typ im Entity-Relationship-Modell vergleichbar, wobei hier Detailunterschiede bestehen, die zwar auf den ersten Blick nicht ohne weiteres erkennbar, in der Praxis aber von großer Bedeutung sind (siehe Object-relational impedance mismatch). Prinzipiell erlaubt, wenn auch nicht üblich, ist die Darstellung mit Raute auch bei Assoziationen mit nur zwei Assoziationsenden, wodurch das Erscheinungsbild Chen-Notation von Entity-Relationship-Modellen ähnelt.

Eine Assoziation heißt reflexiv, wenn sie einen Classifier mit sich selbst verbindet. Die beiden Enden der Assoziation zeigen hier also auf den gleichen Typ. In der Abbildung rechts ist die Assoziation „Vater/Sohn-Beziehung“ reflexiv.

Assoziationsenden

Grafisch wird eine Assoziation durch eine Linie dargestellt. Hierbei wird unterschlagen, dass die Enden einer Assoziation nicht einfach grafische Punkte, sondern eigenständige Modellelemente sind. Im Unterschied zur UML 1.4 gibt es aber kein Modellelement Assoziationsende (association end) mehr, denn das Ende einer Assoziation wird seit UML2 mit dem Modellelement Eigenschaft (Property) modelliert.

Eine binäre Assoziation und das zugehörige Repository-Modell, dargestellt als Objektdiagramm

In der Abbildung rechts ist an einem Beispiel gezeigt, dass das Repository-Modell hinter dem Klassendiagramm ein Assoziationsende als Instanz der Metaklasse Property speichert. Assoziationsenden können deshalb alle Merkmale einer Eigenschaft haben:

• Sie können eine Multiplizität haben, ausgedrückt durch eine untere und eine obere Grenze in der Form untereGrenze..obereGrenze.
• Sie können einen Namen haben.
• Sie können eine Sichtbarkeit deklarieren.
• Man kann spezifizieren, ob das Assoziationsende geordnet (ordered) oder eindeutig (unique) ist.

Eine Assoziation bildet eine Art Brücke zwischen zwei Typen: startet man bei der Instanz des einen beteiligten Typs kann man über eine Objektbeziehung zur Instanz des zweiten Typs navigieren. Die UML2 erlaubt nun, die Navigierbarkeit von Assoziationsenden einzuschränken. Dabei unterscheidet sie drei Arten, wie die Navigierbarkeit festgelegt werden kann:

Navigierbarkeit - graphische Notationen

1. Keine Aussage zur Navigierbarkeit. Das Modell macht keine Aussage zur Navigierbarkeit. Sie ist unspezifiziert und soll erst zu einem späteren Zeitpunkt, zum Beispiel beim Softwaredesign, definiert werden.
2. Erlaubte Navigation. Das Modell erlaubt die Navigation über das Assoziationsende.
3. Nicht erlaubte Navigation. Das Modell verbietet die Navigation über das Assoziationsende.

Assoziationen, die auf beiden Seiten navigierbar sind, heißen bidirektionale Assoziationen, nur an einem Ende navigierbare Assoziationen entsprechend unidirektional.

Beispiel für zwei Assoziationen zwischen den gleichen Typen

Das Beispiel links zeigt zwei Assoziationen zwischen den gleichen Typen. Weil sie unterschiedliche Namen Rechnungsadresse für und Lieferadresse für tragen, kann man sie gut unterscheiden. Die beiden kleinen Dreiecke unterstützen den Leser. Sie zeigen die Leserichtung für den Namen der Assoziation an, hier zum Beispiel Adresse [ist] Rechnungsadresse für Bestellung. Zu einer Bestellung können zwei unterschiedliche Instanzen von Adresse gehören, die durch ihre Rolle unterschieden werden. Die eine Instanz hat die Rolle lieferadresse, die andere, optionale, die Rolle rechnungsadresse.

Aggregation und Komposition

Beispiele für Komposition und Aggregation

Möchte man nun ein Assoziationsende hervorheben oder die Bindung einer Assoziation verstärken, so stehen einem Aggregation und Komposition als Mittel zur Verfügung.

In der grafischen Darstellung einer Aggregation kennzeichnet eine nicht ausgefüllte Raute das Ende, das mit dem Ganzen verbunden ist. Im Sonderfall, der Komposition, ist es eine ausgefüllte Raute.

Aggregation

Eine exakte Definition wird in der UML2 nicht gegeben, vielmehr wird darauf verwiesen, dass eine Aggregation je nach Anwendung und Modellierer variiert. Ein konkreter Nutzen lässt sich z. B. ableiten, indem man einem Ende einer Assoziation eine besondere Betonung zukommen lässt.

Grundsätzlich ist die Abgrenzung zwischen Assoziation und Aggregation schwierig. Ein schwaches Indiz für die sinnvolle Verwendung einer Aggregation scheint das Vorliegen von Transitivitäten zwischen den modellierten Klassen zu sein. Das heißt, wenn zwischen A und B eine Teil-Ganzes-Beziehung existiert und zwischen B und C ebenfalls, dann muss A auch ein Teil von C sein.

Eine spezielle und anwendungsträchtigere Art der Aggregation ist die Komposition.

Komposition

Die Komposition (composite aggregation oder composition) als Sonderfall der Aggregation beschreibt ebenfalls die Beziehung zwischen einem Ganzen und seinen Teilen. Der Unterschied zur Aggregation ist, dass die Existenz eines Objekts, das Teil eines Ganzen ist, von der Existenz des Ganzen abhängig ist.

Ein Objekt kann dabei immer nur Teil maximal eines Ganzen sein (Multiplizität 0..1 oder 1). Räume gibt es z. B. in einem Gebäude oder auf einem Wohnschiff. Die Verwendung einer Komposition sagt dann aus, dass ein konkreter Raum entweder in einem Gebäude oder auf einem Wohnschiff liegt. Die Existenz eines Objekts kann eben nicht gleichzeitig von zwei anderen Objekten abhängig sein.

Existenzabhängigkeit bedeutet, dass das Ganze den Lebenszyklus der Teile bestimmt, d. h. das Objekt, welches das Ganze repräsentiert, übernimmt auch die Verantwortung für die Lebensdauer der Objekte, die seine Teile repräsentieren. Wird das Ganze gelöscht, verschwinden auch die Objekte, welche zu diesem Zeitpunkt Bestandteil waren. Sprengt man ein Gebäude oder sinkt ein Wohnschiff (wir sehen ab von einer möglichen Bergung), werden auch die Räume mit vernichtet.

Ein Objekt, das Teil eines Ganzen ist, kann zur Lebenszeit zu einem anderen Ganzen wechseln oder sogar ganz in die Unabhängigkeit entlassen werden. Im Gebäude-Beispiel wäre das ein Containergebäude. Wird ein Containergebäude abgebaut, werden die Wohncontainer unabhängig von anderen Objekten. Sie können dann auch allein existieren. Erst wenn man sie zu einem Containergebäude zusammenbaut, werden sie wieder existenzabhängig.

Eine Komposition beschreibt einen azyklischen, gerichteten Graph (Ganzes ← Teil ← Subteil). Als Relation ist sie asymmetrisch und transitiv.

Unterschiede zur UML 1.4

Die UML2 hat die Notation für die Navigierbarkeit von Assoziationsenden eingeführt.

In der UML 1.4 gab es ein spezielles Modellelement AssociationEnd, das in der UML2 durch Property ersetzt wurde.

Siehe auch

• Assoziationsklasse