Björn Klippstein

Assoziation

Klippstein IT Service

Aus 4webmaster.de

Wechseln zu: Navigation, Suche

Inhaltsverzeichnis

Verbindungen und Assoziationen werden in der UML zur Darstellung der Beziehungen zwischen Objekten genutzt.

Verbindungen stellen Beziehungen zwischen Objekten dar. Verbundene Objekte kommunizieren miteinander. Verbindungen sind die konkreten Instanzen von Assoziationen. Im Objektdiagramm wird eine Momentaufnahme beispielhafter Objekte und ihrer Verbindungen untereinander dargestellt. Das Objektdiagramm stellt damit einen bestimmten Systemzustand dar.
Assoziationen werden dagegen zwischen Klassen eingezeichnet. Sie stellen aber auch eine Relation zwischen den Objekten der Klassen dar: Sie zeigen, dass zwischen ihren Instanzen eine Verbindung besteht. Das Klassendiagramm zeigt die Klassen eines Systems und ihre Assoziationen untereinander. Im Gegensatz zum Objektdiagramm wird hier aber kein Schnappschuss, sondern die grundsätzliche und zeitinvariante Struktur des Systems dargestellt.
Das Use-Case-Diagramm zeigt die externen Akteure, die mit dem System interagieren und ein bestimmtes Verhalten abrufen. Diese Interaktion (z.B. ein Austausch von Daten) lässt sich als Assoziation zwischen dem Akteur und einem Use-Case darstellen.

Verbindungen und Assoziationen sind also zwei verschiedene Perspektiven auf ein und die gleiche Sache, nämlich eine Relation zwischen Objekten. Diese Relation wird in ihrer Grundform als einfache Linie dargestellt.

Als Beispiel betrachten wir die Situation in einer Bücherei. Dargestellt wird Relation zwischen Bücherei-Nutzer und Buch. (Leider kann das hier verwendeten Tool (Graphiz) keine Unterstreichungen. Sie müssen daher Objekte und Klassen allein anhand ihrer Schreibweise unterscheiden.)

Beispiel: Verbundene Objekte
Verbundene Objekte







Beispiel: Assoziierte Klassen
Assoziierte Klassen


Beide Diagramme drücken prinzipiell den gleichen Sachverhalt aus, nämlich die Relation zwischen Nutzern und Büchern einer Bücherei. Das Objektdiagramm stellt konkrete Beispiele zu einem bestimmten Zeitpunkt dar, während das Klassendiagramm den abstrakten Zusammenhang über alle Zeiten darstellt.

Eine (bidirektionale) Assoziation wird programmtechnisch so umgesetzt, dass mindestens zwei Methoden daraus entstehen, eine für jede Richtung.

Die Enden einer Assoziation können als Mengen von Instanzen aufgefasst werden.



Kardinalität

Die Kardinalität spezifiziert eine Anzahl. Sie wird auch Multiplizität oder Vielfachheit genannt. Für Attribute spezifiziert sie die Anzahl der Werte, die ein Attribut haben kann oder muss. Für Assoziationen spezifiziert sie die Anzahl der Objekte, mit der ein Objekt in Beziehung stehen kann.

1:n

Als Beispiel betrachten wir die Situation in einer Bücherei. Dargestellt wird Relation zwischen Titel und Buch. Eine Bücherei hat besonders beliebte Titel ja mehrfach im Bestand.

1:n - Beziehung
1:n - Beziehung

Im diesem Klassendiagramm sind die Kardinalitäten der Assoziation notiert:

  • zu einem Titel können beliebig viele Bücher im Bestand sein. Die Kardinalität ist daher ∗. Beliebig viele heißt: 0 ist erlaubt (das Buch wurde noch nicht angeschafft oder es existiert keines mehr), ein einzelnes Buch ist auch möglich und mehrere Bücher ebenso.
  • jedes Buch hat genau einen Titel. Die Kardinalität ist daher 1. Es gibt keine Bücher ohne Titel (daher ist die Kardinalität nicht 0..1). Ein Buch kann auch nicht mehrere Titel haben (daher ist die Kardinalität nicht 1..∗).

In der Datenbankwelt spricht man in diesem Fall von einer 1:n-Beziehung.

n:m

Ein anderes Beispiel. Betrachten wir die Assoziation zwischen den Klassen Titel und Autor:

n:m - Beziehung
n:m - Beziehung

  • ein Autor kann mehrere Titel verfassen. Die Kardinalität ist daher ∗.
  • ein Titel kann von mehreren Autoren verfasst sein. Die Kardinalität ist daher ∗.

In der Datenbankwelt spricht man in diesem Fall von einer n:m-Beziehung.


1:1

Als Beispiel für eine 1:1-Beziehung betrachten wir die Assoziation zwischen der Klasse Ausweis und Nutzer:

1:1 - Beziehung
1:1 - Beziehung

  • Ein Ausweis hat genau einen Nutzer. Die Kardinalität ist daher 1. Er kann nicht mehrere Nutzer haben. Ein Ausweis kann auch nicht 0 Nutzer haben (stattdessen wird er in diesem Fall gelöscht). Es handelt sich also um eine Muss-Beziehung: Jeder Ausweis muss genau einen Nutzer haben.
  • Ein Nutzer kann einen oder keinen Ausweis haben. Die Kardinalität ist daher 0..1 . Der Nutzer kann also nicht mehrere Ausweise haben. Es ist aber möglich, dass der Nutzer auch ohne Ausweis als Nutzer registriert bleibt. Es handelt sich also um eine Kann-Beziehung.
Ein anspruchsvolles Beispiel zu Kardinalitäten findet sich im Abschnitt zur Transformation von Assoziationsklassen.



Benennung

Eine unbeschriftete Linie sagt wenig aus über die Natur der Assoziation. Zur Charakterisierung der Assoziation benennt man eine Assoziation. Der Name wird in der Mitte der Linie notiert.

Mit einer Assoziation stellt man im Grunde eine Relation zwischen zwei Konzepten dar. Im folgenden Beispiel ist das die Relation zwischen Autoren und Titeln. Will man diese Relation als UML-Assoziation darstellen, so nimmt man dafür eine Perspektive ein: Die Relation wird aus einer bestimmten Perspektive (aus der des Autors oder aus der des Titels) dargestellt. Die Relation bekommt dadurch eine Richtung.

Die folgenden vier Diagramme stellen exakt die gleiche Relation zwischen Autoren und Titeln dar, aber auf unterschiedliche Weise:



Der Name der Assoziation bezieht sich also immer auf eine bestimmte Richtung. Im UML-Diagramm ist diese Richtung entweder durch die Leserichtung implizit festgelegt, oder man gibt sie explizit durch einen kleinen Richtungspfeil ◀ oder ▶ an.



Aktiv oder Passiv?

Auch durch den Wechsel der grammatikatischen Form vom Aktiv ins Passiv oder umgekeht wird die Richtung gewechselt, wie obige Diagramme zeigen. Festzuhalten ist: alle vier Assoziationsbenennungen drücken exakt den gleichen Zusammenhang aus. Es gibt hier auch kein richtig oder falsch, sondern nur ein geeigneter oder ungeeigneter für einen bestimmten Zweck. Meist ist die Aktivform prägnanter als die Passivform. Aber die Passivform ist prinzipiell genauso richtig wie die Aktivform. Bei der Benennung sollte man sich nicht von der Grammatik der deutschen oder englischen Sprache leiten lassen, sondern vom Informationsfluss im zu modellierenden System.



Verb oder Substantiv?

Verwenden Sie Verben statt Substantiven, heißt es überall. Aber warum eigentlich?
Substantive sind abstrakter und unkronkreter. Sie können beispielsweise die Richtung einer Assoziation verbergen. Ein gutes Beispiel ist die Teil..Ganzes-Relation, auch Aggregation genannt. Beispielsweise ist Schokolade Teil eines Schokopuddings, und umgekehrt beinhaltet ein Schokopudding Schokolade.

Die folgenden beiden Diagramme stellen die gleiche Relation dar, verwenden aber als Benennung einmal ein nur das abstrakte Substantiv und einmal ein Verb:

Das obere Diagramm verschweigt, ob A das Teil oder das Ganze ist. Erst indem man der Assoziation eine Richtung gibt (durch Verwendung eines Verbes, hier ist) wird klar, was das Teil und was das Ganze ist.


Substantive sind aber nicht immer richtungslos, manchmal beinhalten sie auch eine Richtung. Das macht die Sache aber nicht unbedingt besser, wie folgendes Beispiel zeigt:

Haben Sie die Relation verstanden? Ist A das Allgemeine oder das Spezielle? Viel klarer ist es, wenn ein Verb verwendet wird:



Benennung der Assoziationsenden

Zusätzlich oder alternativ zur Benennung der Assoziation selbst kann man auch eine oder beide Assoziationsenden benennen. Man benennt ein Assoziationende nach der Rolle , welche die Instanzen der Klasse durch die Assoziation einnehmen.

Im Diagramm rechts wird ein Beispiel dargestellt.

 
Rollenname

 

Der Rollenname wird klein geschrieben, da er direkt als Attribut oder Methode realisiert wird. Auch die automatische Codeerzeugung durch UML-Tools verwendet die Benennung der Assoziationsenden für die generierten Methoden und Attribute.

Im Diagramm rechts wird das obige Beispiel nochmals mit eingetragenen Attributen dargestellt.

Die Enden einer Assoziation können als Mengen von Instanzen aufgefasst werden.

Jedes Assoziationsende entspricht einer Methode oder einem Attribut in der jeweils gegenüberliegenden Klasse.

 



Aggregation

Die Relation zwischen dem Ganzen und seinen Teilen bezeichnet man als Aggregation oder Komposition.
Aus Sicht der UML handelt es sich um spezielle Assoziationen, das sind Relationen zwischen Objekten. Eingezeichnet wird die Aggregation zwar zwischen zwei Klassen, aber die Relation besteht insbesondere zwischen den Instanzen dieser Klassen.

Das Ganze wird auch als Aggregat bezeichnet. Die Teile heißen dann Komponenten.

Beispiele:


Aggregation
Aggregation

Aggregation und Kardinalität
Aggregation mit Angabe der Kardinalität


Aggregationen sind transitiv, d.h. aus Ein typisches Beispiel für eine transitive Relation ist die Aggregation (Teil-Ganzes-Beziehung):

A istTeilvon B    und    B istTeilvon C
   folgt A istTeilvon C


In der UML lässt sich die Aggregation komplexitätsreduzierend nutzen, indem man

  • in einem Diagramm den inneren Aufbau einer Klasse darstellt (die externen Assoziationen werden weggelassen)
  • und in einem anderen Diagramm die Außenbeziehungen der Klasse (das komplexe Innenleben bleibt verborgen)

Die Aggregation wird in der UML durch einen Pfeil mit einer Diamantform dargestellt. Der Diamant weist auf das Ganze. Die Benennung der Assoziationen und die Benennung der Assoziationsenden / Rollen enfällt normalerweise.


Bei der Konstruktion einer Aggregation muss die Verteilung der Funktionalität auf die Einzelteile gründlich durchdacht sein:

  • In welcher Weise wird jedes einzelne Verhalten des Ganzen von den Teilen realisiert?
  • Wie werden Fehler nach oben durchgereicht?
  • Wie hängen die Lebenszyklen der Objekte miteinander zusammen? Während der Lebensdauer des Ganzen können Teile entstehen und wegfallen. Bleiben Teile erhalten, nachdem das Ganze zerstört wurde? Oft wird dazu ein Zustandsdiagramm erstellt.
  • Welche Reihenfolgen müssen beachtet werden?


Komposition

In der UML wird zwischen Aggregation und Komposition unterschieden. Die Komposition ist eine spezielle, strengere Form der Aggregation:

Kardinalität Bei der Komposition gehört die Instanz eines Teils zu maximal einer Instanz eines Ganzen. Bsp.: Ein Schlafzimmer gehört nicht zu mehreren Häusern.
Exklusivität Ein Teilobjekt kann auch nicht zu mehreren Ganzes-Objekten gehören. Bsp.: Ein WC gehört nicht zu einem Haus und zugleich zu einem Flugzeug.
Lebensdauer Bei einer Komposition kann das Teil nicht ohne sein Ganzes existieren. Das Teil entsteht nach dem Ganzen und wird vor dem Ganzen wieder zerstört. Bsp.: Räume existieren nur als Teil eines Hauses.

In der UML die Komposition durch ein ausgefülltes Aggregationssymbol dargestellt.


Komposition
Komposition: Räume existieren nur als Teil eines Hauses

Komposition
Komposition und Aggregation


Kompositionsstrukturdiagramm

Kompositionen können auch innerhalb des Struktur-Abschnittes einer Klasse dargestellt werden. Dadurch reduziert man die Anzahl der dargestellten Linien und verbessert die Übersichtlichkeit. Eine solche Klasse mit "Innenleben" kann in UML durch ein Kompositionsstrukturdiagramm dargestellt werden.

Das folgende Beispiel zeigt zweimal die gleiche Struktur, einmal als normale Komposition und einmal als Kompositionsstrukturdiagramm. (Leider kann das hier verwendeten Tool (Graphiz) im linken Diagramm den Klassennamen nicht in einem abgetrennten Feld darstellen, wie es eigentlich richtig wäre):


Kompositionsstrukturdiagramm
Kompositionsstrukturdiagramm

Komposition
Komposition


Miteinander interagierende Parts werden mit Konnektoren verbunden, die genauso wie Assoziationen dargestellt werden.












Navigation

Assoziationen sind standardmäßig bidirektional, d.h. sie lassen sich in beide Richtungen verwenden. Im Bücherei-Beispiel bedeutet das, dass die Instanzen der Klasse Buch mit den Instanzen der Klasse Nutzer kommunizieren können und umgekehrt genauso.

Soll diese Kommunikation einseitig eingeschränkt werden, so kennzeichnet man das in UML, indem die Assoziation eine Pfeilspitze bekommt. Die Kommunikation kann dann nur noch in die angegebene Richtung laufen. Beispiel:

Mit dieser Assoziation kann ein Objekt der Klasse Kunde die Methoden der Klasse Kreditkarte sehen und aufrufen. Andersherum kann von einer Kreditkarteninstanz aber nicht auf die restlichen Kundendaten geschlossen werden, weil das Kreditkarten-Objekt keinen Methoden der Klasse Kunde aufrufen kann.

Noch deutlicher wird die Einseitigkeit der Assoziation visualisiert, indem eine Assoziationsrichtung mit einem X gekennzeichnet ist:



Constraints

In geschweiften Klammern können Constraints für ein Assoziationsende notiert werden. Constraints sind Einschränkungen, Zusicherungen, Gültigkeitsregeln oder besondere Eigenschaften. Sie beziehen sich auf die Menge von Objekten, die ein Assoziationsende liefert.

Die Notationsregeln sind analog zu denen bei Attributen.

Constraint
Constraint



Assoziationsklassen

Oft besitzt die Assoziation selbst mehrere Attribute. In diesem Fall kann die Assoziation selbst als Klasse modelliert werden. So wird das in UML modelliert:

n:m


Man kann solche Assoziationsklassen aber auch auflösen. Welche Darstellung man bevorzugt, ist Geschmackssache. Aufgelöst ergibt sich folgendes Klassendiagramm (beachten Sie die Transformation der Kardinalität):



1:n

Natürlich lassen sich auch Assoziationsklassen von 1:n-Beziehungen bilden und in einfache Klassen transformieren. Beispiel:


Aufgelöst ergibt sich folgendes Klassendiagramm (beachten Sie die Transformation der Kardinalität):




Ternäre und höherwertige Assoziationen

Die Stelligkeit gibt an, wieviele verschiedene Typen von Objekten an einer Relation teilnehmen. Nicht zu verwechseln mit der Kardinalität, welche angibt, wieviele konkrete Objekte an einer Relation teilnehmen können.


Ternäre Relationen haben nicht zwei, sondern drei Teilnehmer. Sie brauchen daher auch ein 3-Tupel zur Repräsentation. Allgemein spricht man von n-nären Relationen und drückt sie als n-Tupel aus.

In UML werden solche Relationen mit einem Diamanten-Symbol dargestellt. Beispiel für eine ternäre Assoziation:




Reflexive Assoziationen

Selbstverständlich können Assoziationen auch Klassen mit sich selbst verbinden. Solche Assoziationen heißen reflexiv. Beispiel: