Beziehungen zwischen Elementen in Klassendiagrammen

Aus RAD Studio
Wechseln zu: Navigation, Suche

Nach oben zu UML 1.5-Klassendiagramm

Eine Beziehung ist eine Verbindung zwischen Elementen. In der Modellierung sind die drei wichtigsten Beziehungen Abhängigkeiten, Generalisierungen und Assoziationen. Grafisch wird eine Beziehung mit für den jeweiligen Beziehungstyp unterschiedlichen Linien dargestellt.

Beziehungstypen zwischen Elementen in Klassendiagrammen

Für Elemente in Klassendiagrammen können die folgenden Beziehungstypen verwendet werden:

  • Generalisierung und Implementierung
  • Abhängigkeit
  • Assoziation (einfache Assoziation, n-fache Assoziation, Aggregation und Komposition)
  • Bereitgestellte und erforderliche Schnittstellen (UML 2.0)

Generalisierung und Implementierung

  • Generalisierung - Eine Generalisierung ist eine Beziehung zwischen einem allgemeinen Element (Oberklasse oder übergeordnete Klasse) und einem spezielleren Element dieses Typs (Unterklasse oder untergeordnete Klasse). Mit einer Generalisierung wird auch auf die Vererbungsbeziehung zwischen zwei Schnittstellen (untergeordneter und übergeordneter) gezeigt.
Generalisierung bedeutet, dass das untergeordnete Element die Eigenschaften (Attribute, Operationen usw.) des übergeordneten Elements erbt und dass Objekte des untergeordneten Elements überall dort verwendet werden können, wo das übergeordnete Objekt auftritt.
Grafisch wird eine Generalisierung als einfache Linie mit einem gefüllten Pfeil am Ende dargestellt, der auf das übergeordnete Element zeigt:
Generalisierungsbeziehung
  • Implementierung - Eine Implementierungsbeziehung ist eine spezielle Art der Generalisierungsbeziehung. Eine Implementierung it eine Vererbungsbeziehung, die angibt, dass eine untergeordnete Klasse eine übergeordnete Schnittstelle implementiert.
Grafisch wird eine Implementierung als gestrichelte Linie mit einem gefüllten Pfeil am Ende dargestellt, der auf die übergeordnete Schnittstelle zeigt:
Implementierungsbeziehung

Abhängigkeit

Eine Abhängigkeit ist eine Beziehung zwischen zwei Elementen, bei der eine Änderung eines Elements (des unabhängigen Elements - Anbieter) Änderungen des anderen Elements (des abhängigen Elements - Client) bewirken kann.

Grafisch wird eine Abhängigkeit als gestrichelte Linie dargestellt, die auf das unabhängige Element (Anbieter ) gerichtet ist:
Abhängigkeitsbeziehung

Assoziation

Eine Beziehung zwischen Instanzen zweier Klassen. Assoziationen zwischen zwei Klassen bestehen, wenn eine Instanz der einen Klasse (Client) von der anderen (Anbieter) wissen muss, um ihre Aufgaben durchzuführen.

In einem Diagramm wird eine Assoziation durch eine einfache Linie zwischen zwei Klassen dargestellt.

Navigation, Rollen und Multiplizität sind optionale Elemente, die die Interpretation der Assoziation vereinfachen:

  • Assoziationsnavigation. Assoziationen können gerichtet oder ungerichtet sein. Eine gerichtete Beziehung zeigt auf die Anbieterklasse (das Ziel). Ein Navigationspfeil auf einer Assoziation zeigt die Richtung an, in der die Assoziation abgefragt werden kann. Eine Klasse kann bezüglich ihrer "Elemente" abgefragt werden. Abfragen in entgegengesetzter Richtung sind nicht möglich. Am Pfeil lässt sich auch der "Eigentümer" der Implementierung der Assoziation erkennen. Assoziationen ohne Navigationspfeil sind bidirektional. Beispielsweise gibt eine bidirektionale Assoziation zwischen den Klassen Bibliothek und Buch an, dass Objekte des Typs Bibliothek über Objekte des Typs Buch abgefragt werden können und umgekehrt.
  • Rollen. Eine Assoziation besitzt zwei Enden. Jedes Ende kann mit einem Rollennamen versehen sein, der den Charakter der Assoziation beschreibt.
  • Multiplizität. Ein Assoziationsende kann eine Multiplizität besitzen. Die Multiplizität eines Assoziationsendes bestimmt, wie viele Instanzen der Klasse mit einer einzelnen Instanz am anderen Ende verbunden sein können. Die Multiplizität kann als einzelne Werte oder als Wertebereich angegeben werden.
In der folgenden Tabelle sind die gängigsten Arten der Multiplizität aufgeführt:
Multiplizität Bedeutung

0..1

Keine oder eine Instanz. Die Notation n..m steht für n bis m Instanzen.

1 or n

Genau eine Instanz oder genau n Instanzen.

0..* or *

Keine Beschränkung bezüglich der Anzahl der Instanzen (auch keine Instanz ist möglich).

1..*

Mindestens eine Instanz.


Assoziationstypen

Es gibt verschiedene Untertypen von Assoziationsbeziehungen:

  1. Assoziation (Einfache Assoziation) - Eine Assoziation ("einfache Assoziation") zwischen zwei gleichgeordneten Klassen. Die Assoziation repräsentiert eine rein strukturelle Beziehung zwischen zwei gleichgeordneten Klassen. Beide Klassen befinden sich konzeptuell auf derselben Ebene, keine ist wichtiger als die andere.
Grafisch wird eine Assoziation durch eine einfache Linie zwischen zwei Klassen dargestellt:
Assoziationsbeziehung
Diese Abbildung zeigt die "einfache Assoziationsbeziehung", mit einer Eigentümerrolle (owner), der Multiplizität 1 und 0..* und legt die Assoziationsnavigation von der Rolle Client zu der Rolle Password fest.
  1. Assoziation (n-fache Assoziation) - Die n-fache Assoziation kann soviel Assoziationsendklassen (Teilnehmer) wie erforderlich verbinden. Erstellen Sie n-fache Assoziationen mit einer Assoziationsklasse.
Assoziationsklassen werden in Diagrammen durch drei Elemente dargestellt:
* Assoziationsklasse (Assoziationsklassenelement), dargestellt durch ein Klassensymbol.
* N-fache Assoziationsklassenbeziehung (Assoziationsendbeziehung), dargestellt durch eine Raute.
* Assoziationskonnektor (Assoziationsklassenkonnektor), dargestellt durch eine Linie zwischen einem Assoziationsklassensymbol und einer Assoziationsraute.
Im Objektinspektor für eine Assoziationsklasse, eine Assoziationsbeziehung und einen Konnektor wird zusätzlich die Registerkarte Assoziation angezeigt. Sie enthält lediglich die Eigenschaft label, die automatisch den Namen der Assoziationsklasse enthält. Bei Assoziationsklassen und Assoziationsendebeziehungen enthält der Eintrag Custom des Objektinspektors weitere Eigenschaften, die der Rolle dieses Bestandteils der n-fachen Assoziation entsprechen (associationClass bzw. associationEnd).
Sie können beliebige Assoziationsendebeziehungen oder Teilnehmerklassen löschen, ohne dass die gesamte n-fache Assoziation entfernt wird. Wenn Sie jedoch die Assoziationsklasse löschen, werden alle Bestandteile der n-fachen Assoziation entfernt.
Siehe auch: Assoziationsklasse erstellen.
  1. Aggregation - Eine Aggregation ist ein spezieller Assoziationstyp, der eine "Teil-zum-Ganzen"-Beziehung darstellt, in der eine Klasse ein größeres Element ("Ganzes") repräsentiert, das kleinere Elemente ("Teile") enthält. Eine separate Aggregationsbeziehung wird zwischen allen Klassen, die einen Teil repräsentieren, und einer Klasse, die das Ganze repräsentiert, verwendet.
Grafisch wird eine Komposition als einfache Linie zwischen zwei Klassen mit einer gefüllten Raute am Kompositionsende dargestellt:
Kompositionsbeziehung
Diese Abbildung zeigt die Aggregationsbeziehung. Die Klasse Group repräsentiert das "Ganze" und die Klasse Person "Teile". Eine Multiplizität von 0..* an beiden Enden und die Rollen union und member geben an, dass jede union (des Typs Group) eine beliebige Anzahl von member-Rollen (des Typs Person) enthalten kann, und im Gegenzug jedes Typobjekt Person ein member einer beliebigen Anzahl von union-Rollen (des Typs Group) sein kann. Die bidirektionale Aggregationsnavigation legt fest, dass ein Group-Typobjekt seine Person-Typ-Member und ein Person-Typobjekt Unions (des Typs Group), deren Member es ist, abfragen kann.
  1. Komposition - Eine Komposition ist eine spezielle "starke" Form einer Aggregation, bei der das "Kompositionsende" die komplette Verantwortung für die Verwaltung seiner "Teileenden" hat (z.B. das Erstellen und Freigeben seiner Teile).
Grafisch wird eine Komposition als einfache Linie zwischen zwei Klassen mit einer gefüllten Raute am Kompositionsende dargestellt:
Kompositionsbeziehung
Diese Abbildung zeigt die Kompositionsbeziehung. Die Klasse Order repräsentiert die "Komposition" und die Klassen Customer und LifeItem "Teile".

Bereitgestellte und erforderliche Schnittstellen

UML 2.0-Klassendiagramme führen die bereitgestellten und erforderlichen Schnittstellen ein.

In UML 2.0-Klassendiagrammen werden bereitgestellte Schnittstellen mit Bereitgestellte Schnittstellenbeziehung ("Lollipop"-Notation) und erforderliche Schnittstellen mit Erforderliche Schnittstellenbeziehung ("Sockel"-Notation) gekennzeichnet (siehe Elemente in einem UML 2.0-Klassendiagramm).


Siehe auch