<< zurück

MBSE Home

weiter >>

2.3 Assoziationen

Eine Assoziation dient dazu, Objekte zweier Klassen in Beziehung zu setzen. Mithilfe von Assoziationen können komplexe Datenstrukturen gebildet werden und Methoden benachbarter Objekte aufgerufen werden. Abbildung 2.8 beschreibt einen Ausschnitt aus dem Auktionssystem mit drei Klassen, zwei Interfaces und fünf Assoziationen in unterschiedlichen Formen.

Eine Assoziation besitzt im Normalfall einen Assoziationsnamen und für jedes der beiden Enden je eine Assoziationsrolle, eine Angabe der Kardinalität und eine Beschreibung der möglichen Navigationsrichtungen. Einzelne Angaben können im Modell auch weggelassen werden, wenn sie zur Darstellung des gewünschten Sachverhalts keine Rolle spielen und die Eindeutigkeit nicht verloren geht. Zum Beispiel dienen Assoziationsnamen häufig nur zur Unterscheidung von Assoziationen, insbesondere dann, wenn sie die gleichen Klassen verbinden. Im Falle des Fehlens eines Assoziations- oder Rollennamens gibt es Standardregeln zur Gewinnung eines Ersatznamens, die im folgenden Abschnitt skizziert und in Abschnitt 3.3.8 detaillierter besprochen werden.

Eine Assoziation ist genauso wie eine Klasse ein Modellierungskonzept im Klassendiagramm. Zur Laufzeit eines Systems manifestiert sich eine Assoziation durch Links zwischen den damit verbundenen Objekten. Die Anzahl der Links wird durch die Kardinalität der Assoziation eingeschränkt. Ist eine Assoziation in eine Richtung navigierbar, so werden in der Implementierung Vorkehrungen getroffen diese Navigerbarkeit effizient zu realisieren.

2.3.1 Rollen

Mithilfe des Rollennamens lassen sich die über eine Assoziation beziehungsweise deren Links verbundenen Objekte ansprechen. So kann aus einem Objekt der Klasse Person mithilfe des Rollennamens auctions auf die Auktionen zugegriffen werden, an der die Person teilnimmt. Ist kein expliziter Rollenname gegeben, so wird ersatzweise der Name der Assoziation oder der Zielklasse als Rollenname angenommen, wenn diese die intendierte Navigation eindeutig beschreiben. Im Beispiel 2.8 kann von einem Objekt der Klasse Auction mit den Namen biddingPolicy und messages auf die entsprechenden Objekte zugegriffen werden. Dabei werden gemäß der zur Implementierung genutzten Programmiersprache und der im Klassendiagramm angegebenen Kardinalitäten schematische Umsetzungen des ersten Buchstabens im Namen vorgenommen. So beginnen in UML/P Rollennamen grundsätzlich mit einem Kleinbuchstaben, während Klassennamen mit einem Großbuchstaben anfangen.

Sind beide Assoziationsenden mit derselben Klasse verbunden, so wird von einer reflexiven Assoziation gesprochen. Reflexive Assoziationen erlauben die Realisierung einer Reihe von Entwurfsmustern [GHJV94, BMR⁺96], wie zum Beispiel eine Teile-Ganzes-Beziehung. In einer reflexiven Assoziation ist es notwendig, wenigstens eines der Enden mit Rollennamen zu versehen. So kann eine Unterscheidung der teilnehmenden Objekte durch ihre Rollen vorgenommen werden.

Abbildung 2.10 zeigt eine reflexive Assoziation, in der einem Beobachter der Bieter zugeordnet wird, den er „beobachten“ darf. Obwohl damit eine reflexive Klassenstruktur geschaffen wurde, ist im Beispiel die Rekursionstiefe auf 1 beschränkt. Bieter sind selbst keine Beobachter und Beobachter haben eine direkte Verbindung zu Bietern. Dies kann durch geeignete OCL-Bedingungen ausgedrückt werden (siehe Kapitel 3).

2.3.2 Navigation

In einem entwurfsnahen oder für die Implementierung gedachten Klassendiagramm spielen die erlaubten Richtungen zur Navigation entlang einer Assoziation eine wesentliche Rolle. Im Beispiel 2.8 ist beschrieben, dass von einem Personen-Objekt der Zugriff auf die ihm zugeordneten Message-Objekte möglich ist. Umgekehrt ist es nicht vorgesehen, von einem Message-Objekt (direkt) auf die Personen zuzugreifen, denen es zugestellt wurde. Das Modell erlaubt damit die Verteilung einer Nachricht, zum Beispiel im Broadcast-Verfahren, an mehrere Personen ohne Duplikation.

Assoziationen können grundsätzlich uni- oder bidirektional sein. Ist keine explizite Pfeilrichtung angegeben, so wird von einer bidirektionalen Assoziation ausgegangen. Formal werden die Navigationsmöglichkeiten in dieser Situation als unspezifiziert und damit nicht einschränkend betrachtet.

Ist die grundsätzliche Navigierbarkeit durch den Pfeil modelliert, so wird durch den Rollennamen festgelegt, wie die Assoziation bzw. die auf der anderen Seite liegenden Objekte angesprochen werden können. Die Modifikatoren public, protected und private können für Rollen eingesetzt werden, um die Sichtbarkeit dieser Navigation entsprechend einzuschränken.

2.3.3 Kardinalität

Für jedes Ende einer Assoziation kann eine Kardinalität angegeben werden. Die Assoziation participants lässt zum Beispiel zu, dass eine Person in mehreren Auktionen teilnimmt und in einer Auktion mehrere Personen bieten können. Einer Auktion ist jedoch nur genau eine TimingPolicy zugeordnet. Die drei Kardinalitätsangaben „⋆“, „1“ und „0..1“ erlauben wie in Abbildung 2.8 zu sehen die Zuordnung von beliebig vielen, genau einem beziehungsweise maximal einem Objekt. Allgemein sind Kardinalitäten von der Form m..n oder m..⋆ und konnten in den früheren UML 1.x Varianten sogar kombiniert werden (Beispiel 3..7,9,11..⋆). In einer Implementierung sind jedoch vor allem die drei zuerst genannten Kardinalitätsformen direkt umsetzbar und daher von Interesse, weshalb auf eine Behandlung der allgemeinen Kardinalitätsform hier verzichtet wird. In Kapitel 3 wird mit den OCL-Invarianten ein Mechanismus eingeführt, der es erlaubt allgemeine Kardinalitäten zu beschreiben und methodisch einzusetzen.

In der UML Literatur wird manchmal zwischen Kardinalität und Multiplizität unterschieden. Dann bezeichnet die Kardinalität die Anzahl der tatsächlichen Links einer Assoziation, während die Multiplizität den Bereich möglicher Kardinalitäten angibt. Die ER-Modelle unterscheiden nicht und verwenden einheitlich den Begriff Kardinalität.

2.3.4 Komposition

Eine besondere Form der Assoziation ist die Komposition. Sie wird durch eine ausgefüllte Raute an einem Assoziationsende dargestellt. In einer Komposition sind die Teilobjekte stark abhängig vom Ganzen. Im Beispiel 2.8 sind BiddingPolicy und TimingPolicy in ihrem Lebenszyklus von dem Auktionsobjekt abhängig. Das heißt, Objekte dieser Typen werden gemeinsam mit dem Auktionsobjekt erzeugt und an dessen Lebensende obsolet. Da es sich bei BiddingPolicy und TimingPolicy um Interfaces handelt, werden stattdessen geeignete Objekte verwendet, die diese Interfaces implementieren.

Eine alternative Darstellungsform stellt den Kompositionscharakter einer Kompositionsassoziation stärker in den Vordergrund, indem sie statt einer Raute graphisches Enthaltensein nutzt. Abbildung 2.9 zeigt zwei Alternativen, die sich nur in Details unterscheiden. Im Klassendiagramm (a) ist der Assoziationscharakter der Komposition herausgestellt. Er beschreibt auch Navigationsmöglichkeiten. Im Klassendiagramm (b) sind Navigationsrichtungen nicht direkt angegeben, jedoch beide Klassen mit je einem Rollennamen versehen, der beschreibt, wie ein Zugriff vom enthaltenden Auktions-Objekt auf seine Komponenten möglich ist. Die Kardinalität ist in der Klasse rechts oben angegeben. Die Darstellung (b) wirkt einerseits intuitiver, ist andererseits aber weniger aussagekräftig. So ist es darin weder möglich die Rückrichtung der Navigation zu klären, noch der darin vorhandenen Kompositionsassoziation weitere Merkmale hinzuzufügen. Die Kardinalität auf Kompositionsseite ist standardmäßig „1“ kann aber durch „0..1“ angepasst werden. Das heißt, ein Objekt ist maximal einem Kompositum zugeordnet.

Bezüglich der Austauschbarkeit und des Lebenszyklus von abhängigen Objekten in einem Kompositum gibt es erhebliche Interpretationsunterschiede² . Eine präzise Definition der Bedeutung einer Komposition sollte daher jeweils projektspezifisch festgelegt werden. Dies kann zum Beispiel durch die in Abschnitt 2.5 eingeführten Stereotypen erfolgen, durch ergänzende projekt- oder unternehmensspezifische, informelle Erläuterungen präzisiert oder durch selbst definierte Stereotypen festgelegt werden.

2.3.5 Abgeleitete Assoziationen

Neben abgeleiteten Attributen gibt es in UML/P auch abgeleitete Assoziationen. Deren Namen wird ebenfalls die Marke „/“ vorangestellt. Eine Assoziation gilt als abgeleitet, wenn sich die Menge ihrer Links aus anderen Zustandselementen berechnen („ableiten“) läßt. Zur Berechnung können andere Attribute und Assoziationen herangezogen werden. Im Beispiel in Abbildung 2.10 sind zwei Assoziationen gegeben, die beschreiben, welche Personen in einer Auktion bieten und welche Personen das Verhalten eines bietenden Kollegen („fellow“) beobachten dürfen. Die abgeleitete Assoziation /observers berechnet sich aus diesen beiden Assoziationen. Dazu kann zum Beispiel die ebenfalls in Abbildung 2.10 angegebene Charakterisierung mittels einer OCL-Bedingung (siehe Kap. 3) verwendet werden.

2.3.6 Assoziationsmerkmale

Der UML-Standard bietet eine Reihe zusätzlicher Merkmale für Assoziationen an, die Assoziationseigenschaften genauer regeln. Abbildung 2.11 beinhaltet drei in diesem Kontext interessante Merkmale. Mit {ordered} wird angezeigt, dass eine mit der Kardinalität „⋆“ versehene Assoziation einen geordneten Zugriff erlaubt. In diesem Fall ist die Reihenfolge der Nachrichten innerhalb einer Auktion relevant. Mit {frozen} wird angezeigt, dass nach Ende der Initialisierung eines Auktionsobjekts die beiden Assoziationen zu den Policy-Objekten nicht mehr verändert werden. Dadurch stehen während der gesamten Lebenszeit eines Auktionsobjekts dieselben Policies zur Verfügung. Mit {addOnly} wird modelliert, dass in der Assoziation nur Objekte hinzugefügt werden dürfen, das Entfernen jedoch verboten ist. Im Modell in Abbildung 2.11 wird damit ausgedrückt, dass Nachrichten, die in einer Auktion versandt worden sind, nicht mehr zurückgenommen werden können.

Eine Assoziation, bei der ein Ende mit dem Merkmal {ordered} gekennzeichnet ist, muss natürlich einen Mechanismus anbieten, der einen Zugriff gemäß dieser Ordnung erlaubt. Assoziationen mit dem Merkmal {ordered} stellen einen Spezialfall einer qualifizierten Assoziation dar.

2.3.7 Qualifizierte Assoziation

In der allgemeinsten Form bietet die qualifizierte Assoziation die Möglichkeit, aus einer Menge von zugeordneten Objekten mithilfe des Qualifikators ein einzelnes Objekt zu selektieren. Abbildung 2.12 zeigt mehrere auf unterschiedliche Weise qualifizierte Assoziationen. Zusätzlich ist es möglich, eine Komposition zu qualifizieren und die Qualifikation einer Assoziation bei beiden Enden vorzunehmen.

Im Auktionssystem wird ein Objekt der Klasse AllData genutzt, um die Sammlung aller aktuell geladenen Auktionen und der daran teilnehmenden Personen zu speichern. Der qualifizierte Zugriff über den Auktionsidentifikator auctionIdent wird als Abbildung verstanden und deshalb die Funktionalität des Interface Map<long, Auction> zur Verfügung gestellt. In welcher Form die qualifizierte Assoziation implementiert wird, ist damit allerdings noch nicht festgelegt. Bei einer Codegenerierung kann eine Transformation in eine alternative Datenstruktur stattfinden oder weitere Funktionalität beispielsweise der NavigableMap hinzugefügt werden.

Als Schlüssel für die Abbildung werden im Beispiel die bereits in der Auktion vorhandenen Auktionsidentifikatoren verwendet. In analoger Form können Personen über den als Typ String gegebenen Namen selektiert werden. Es ist jedoch ein signifikanter Unterschied, ob als Qualifikator ein Typ (im Beispiel: String) oder ein Attributname der gegenüberliegenden Klasse angegeben ist. Während im ersten Fall als Schlüssel beliebige Objekte beziehungsweise Werte des angegebenen Typs verwendet werden können, ist im zweiten Fall als Qualifikator nur der tatsächliche Attributinhalt zulässig. Mit der in Kapitel 3 eingeführten OCL kann diese Eigenschaft wie folgt formuliert werden:

Während in explizit qualifizierten Assoziationen die Art des Qualifikators wählbar ist, stehen in geordneten Assoziationen ganzzahlige Intervalle beginnend mit der 0 zur Verfügung.³

Wird ein expliziter Qualifikator verwendet, so wird durch den qualifizierten Zugriff nur ein Objekt erreicht, auch wenn eine andere Kardinalität angegeben ist. Das Zielobjekt wird normalerweise nur in Bezug auf das Ausgangsobjekt und den Qualifikator eindeutig identifiziert. Beispielsweise können bei Index 0 für jede Auktion unterschiedliche Nachrichten gespeichert sein. Der Qualifikator allIdent ist nur deshalb Systemweit eindeutig, weil er gleichzeitig einen eindeutigen Schlüssel des Zielobjekts darstellt. Sollte der Qualifikator nicht besetzt sein, so muss geeignet reagiert werden, zum Beispiel durch einen null-Pointer wie bei den Java Maps oder eine Exception. In einer geordneten Assoziation (Merkmal {ordered}) bleibt der Qualifikator implizit, denn er wird nicht in einer entsprechenden Box am Assoziationsende angegeben.

Bernhard Rumpe. Agile Modellierung mit UML. Springer 2012

<< zurück

MBSE Home

weiter >>