.webp)
Bei binären Assoziationen handelt es sich um eine Beziehung zwischen genau zwei Klassen oder Objekten in einem Klassen- bzw. Objektdiagramm. Dabei gibt es verschiedene Arten, wie die Aggregation, Komposition, gerichtete Assoziation, Implementations- und die Schnittstellenvererbung.
Erklärung
Die binären Assoziationen erleichtern das Planen von Softwaresystemen, da mit ihnen eine Verbindung zwischen zwei Klassen oder Objekten aufgezeigt werden kann. Jedoch wird daraus noch nicht deutlich, von welcher Art diese Beziehung ist.
Daher gibt es neben den binären Assoziationen noch viele weitere Arten, wie:
- Aggregation
- Komposition
- Gerichtete Assoziation (strukturelle und allgemeine Abhängigkeit)
- Implementationsvererbung
- Schnittstellenvererbung
Aggregation
Die Aggregation stellt eine starke Beziehung zwischen Klassen dar.
Die eine Klasse besitzt dabei die andere. Dennoch sind beide Klassen unabhängig voneinander.
Die Aggregation wird durch eine leere Raute kenntlich gemacht:
Da die Raute auf der Seite der Klasse A ist, besitzt Klasse A die Klasse B.
Klasse A ist dabei die Aggregationsklasse und Klasse B die Teilklasse.
Beide Klassen existieren jedoch weiter, wenn die Assoziation aufgelöst wird.
Komposition
Die Komposition stellt eine noch stärkere Verbindung zwischen zwei Klassen dar.
Dabei ist nämlich eine Klasse von der anderen abhängig und ist gleichzeitig ein Teil dieser Klasse:
Klasse A besitzt also Klasse B und ist unabhängig von B, wohingegen B abhängig von Klasse A ist.
Das bedeutet, B kann nicht ohne A existieren.
Gerichtete Assoziation
Durch eine gerichtete Assoziation wird angegeben, dass die Verbindung nur in eine Richtung durchlaufen werden kann. Dabei wird noch in die strukturelle und die allgemeine Abhängigkeit unterschieden.
Strukturelle Abhängigkeit
Die Klasse A steht bei der strukturellen Abhängigkeit in Beziehung zu Klasse B aber nicht umgekehrt.
A hat dabei zum Beispiel eine Exemplarvariable der Klasse B und ist somit strukturell abhängig von B.
Allgemeine Abhängigkeit
Bei der allgemeinen Abhängigkeit wird beispielsweise die Klasse A als Parameter, lokale Variable oder Rückgabetyp in einer Methode der Klasse B genutzt.
Diese Art der Abhängigkeit wird mit einem gestrichelten Pfeil dargestellt:
Implementationsvererbung
Eine Klasse kann von einer anderen Klasse etwas erben (zum Beispiel Attribute oder Methoden).
Jedes Objekt der einen Klasse ist dann auch ein Objekt der anderen Klasse.
Diese Verbindung wird mit einem nicht ausgefüllten Pfeil dargestellt:
Die Unterklasse A erbt also von der Oberklasse B.
Man spricht dabei von einer Implementationsvererbung, da die Klasse A mithilfe des extends-Befehls Attribute oder Methoden von Klasse B erbt und bei sich implementiert.
Schnittstellenvererbung
Die Schnittstellenvererbung ist ähnlich aufgebaut wie die Implementationsvererbung, nur dass hier eine Klasse von einem Interface (zu Deutsch Schnittstelle) erbt:
Die Klasse A implementiert mithilfe des implements-Befehls die Elemente des Interfaces B. A ist dabei der Subtyp und B der Supertyp, da A ja von B erbt.
Generell kannst du dir merken: Wird die gesamte Implementation vererbt oder eine Klasse als Exemplarvariable genutzt, liegt eine starke Abhängigkeit vor, der Pfeil ist also durchgezogen.
Wird jedoch nur implementiert oder eine Klasse nur als lokale Variable / Parameter oder Rückgabetyp verwendet, liegt eine schwache Abhängigkeit vor, der Pfeil ist also gestrichelt.
Beispiel
Stell dir vor, du möchtest dir einen Überblick darüber verschaffen, welche Komponenten (Klassen) ein Geschäft benötigt und in welcher Beziehung diese zueinander stehen.
Du möchtest dafür ein Klassendiagramm aufzeichnen.
Dieses Diagramm soll dabei die Klassen Store (Geschäft), Employee (Mitarbeiter:in), ChangingRoom (Umkleidekabine), Article (Artikel), Customer (Kund:in) und ShiftManagement (Schichtleitung) enthalten.
Nachdem du nun alle Klassen hast, musst du dir jetzt überlegen, in welcher Beziehung sie zueinander stehen:
Zwischen ChangingRoom und Store muss eine Komposition eingefügt werden, da die Umkleide ja nicht ohne ein Geschäft existieren kann. Da mindestens eine Umkleidekabine nur in einem Geschäft enthalten sein kann, wird an das Ende des Geschäfts eine 1 und an das Ende der Kabine 1..* als Multiplizität ergänzt.
Da die Mitarbeiter:innen auch außerhalb des Geschäfts existieren, wird zwischen Store und Employees eine Aggregation eingezeichnet. An das Ende der Mitarbeiter:innen kann 4..* ergänzt werden, da mindestens 4 Mitarbeiter:innen im Geschäft arbeiten müssen. Diese arbeiten jedoch alle in nur einem Geschäft, weswegen auf der Store-Seite der Assoziation eine 1 ergänzt wird.
Da eine Schichtleitung einfach nur eine speziellere Form von Mitarbeiter:innen ist, kann hier auf die Implementationsvererbung zugegriffen werden:
Die Mitarbeiter:innen verkaufen die Artikel, dem Artikel ist es dabei egal, von wem es verkauft wird, weswegen es sich anbietet, dort auf eine strukturelle Abhängigkeit zurückzugreifen. Die Anzahl an verkauften Artikeln muss dabei mindestens 1 betragen. Auch kann ein bestimmter Artikel nur von einer Person verkauft werden:
Da für die Kaufabwicklung relevant ist, welche Verkäufer:innen die Kund:innen bedient hat, die Information aber sonst nicht relevant ist, reicht hier eine allgemeine Abhängigkeit aus:
Und fertig ist dein Klassendiagramm!
.png)
.svg)
