Objektbeziehungen in der OOP: Assoziation, Aggregation, Komposition

Objektbeziehungen - Assoziationen

https://bildung.social/@oerinformatik/110425552692026065

https://oer-informatik.de/uml-klassendiagramm-assoziation

tl/dr; (ca. 10 min Lesezeit): Mit einzelnen Objekten erreicht man in der OOP noch nicht viel. Erst im Zusammenspiel als Objektsammlungen und über Objektinteraktionen entwickelt die OOP ihre Stärken. Der folgende Text behandelt die Fragen: Welche Objektbeziehungen gibt es? Was unterscheidet Assoziation, Aggregation und Komposition? Versuch der Klärung. (Zuletzt geändert am 24.05.2023)

Dieser Text ist ein Teil der Infotext-Serie zu UML-Klassendiagrammen:

• Grundlagen UML-Klassendiagramm

• Sichtbarkeitsmodifikatoren

• Objektbeziehungen (Assoziation/Aggregation/Komposition)

• Klassenbeziehungen (Vererbung)

• abstrakte Klassen und Interfaces

• UML-Klassendiagramme mit PlantUML erstellen

Im Gegensatz zur Vererbung, die Beziehungen zwischen Klassen darstellt, beschreiben Assoziationen Beziehungen zwischen Objekten. Objektbeziehungen können zur Laufzeit eines Programms geändert werden.

Assoziation

Beziehungen zwischen Objekten nennt man Assoziation, wenn ein Objekt eine Methode eines anderen Objekts aufruft (oder ein Attribut eines anderen Objekts ändert). Beide Objekte arbeiten für ein gemeinsames Ziel zusammen. Die Beziehungen werden im UML Klassendiagramm durch eine Linie zwischen den Objekten dargestellt:

Das gemeinsame Ziel der beteiligten Objekte wird oft anhand des Assoziationsnamens klar. Phrasen wie “benutzt ein”, “ist zugeordnet zu” oder “hat eine Beziehung zu” können diese Assoziationen recht unkonkret beschreiben, häufig finden sich präzisere Namen der Beziehung. Diese Assoziationsnamen werden auf der Assoziationskante mit Pfeil in Leserichtung angegeben: ein/e Kund*in bezahlt eine Rechnung.

In einer Assoziation wird aber keine über das eigentliche Ziel hinaus gehende Abhängigkeit beschrieben. Wenn die Rechnung bezahlt ist, haben Kund*in und Rechnung also ggf. keine weitere Beziehung zueinander. Anhand einer konkreteren Darstellung soll die temporäre Zusammenarbeit beider Objekte deutlich werden:

Das Ziel der Zusammenarbeit ist das Bezahlen einer Rechnung. Dazu erhält ein Kundenobjekt bei Aufruf der Methode bezahleRechnung() ein Rechnungsobjekt übergeben. Die Kund*in nutzt die Rechnung-Methoden getRechnungsbetrag() und setBezahlt(), um die Rechnung von seinem vermoegen zu bezahlen. Nach Abschluss dieser Transaktion hält der Kunde keine Referenz mehr auf die Rechnung - beide Objekte können unabhängig voneinander fortbestehen.

Gerichtete Assoziation

Bei den bisherigen Darstellungen wurde im UML-Diagramm offengelassen, ob beide Objekte einander kennen. Beide Enden der Assoziationskante waren unspezifiziert.

Wenn genauer festgelegt werden soll, welches Objekt vom anderen weiß - also Zugriff auf eine Referenz hat - kann dies mit Kantenenden spezifisch dargestellt werden:

Unidirektional navigierbare Assoziationen

Ein Kunde kann auf die Rechnung zugreifen (Pfeil in Richtung Rechnung), eine Rechnung weiß jedoch nicht, welche Kund*in sie bezahlt hat (Kreuz auf der Kantenseite Kunde). Eine Rechnung hält also keine Referenz auf Kunde. Das wird v.a. auch im Beispielcode deutlich:

Java Python all none

public class Rechnung {
    private double rechnungsbetrag;
    public double getRechnungsbetrag() {return rechnungsbetrag;}

    private boolean bezahlt;
    public void setBezahlt(boolean bezahlt) {this.bezahlt = bezahlt;}
}

public class Kunde {
    private double vermoegen;
    public void bezahleRechnung(Rechnung rechnung){
        vermoegen -= rechnung.getRechnungsbetrag();
        rechnung.setBezahlt(true);
    }   }

class Rechnung:
    def __init__(self, rechnungsbetrag: float):
        self.__rechnungsbetrag: float
        self.__rechnungsbetrag = rechnungsbetrag
        self.__bezahlt: bool
        self.__bezahlt = False

    def get_rechnungsbetrag(self):
        return self.__rechnungsbetrag;
    
    def set_bezahlt(self, bezahlt: bool):
        self.__bezahlt = bezahlt

class Kunde:
    def __init__(self, vermoegen:float ):
        self.__vermoegen: int
        self.__vermoegen = vermoegen
        
    def bezahle_rechnung(self, rechnung):
        self.__vermoegen -= rechnung.get_rechnungsbetrag()
        rechnung.set_bezahlt(True)

Da diese Assoziation nur in einer Richtung navigiert werden kann, spricht man von einer unidirektional navigierbaren Assoziation.

Bidirektional navigierbare Assoziation

Wird beispielsweise beim Bezahlvorgang aufseiten der Rechnung vermerkt, welche Kund*in die Rechnung bezahlt hat (z.B. in der Methode setBezahlt(istBezahlt:boolean, kunde:Kunde)), so kennen sich beide Objekte. Die Assoziation kann in beide Richtungen navigiert werden (Kunde ruft Methoden von Rechnung auf und umgekehrt). Wir sprechen dann von einer bidirektionale navigierbaren Assoziation. In der UML wird dies durch zwei Pfeilenden an der Assoziationskante gekennzeichnet:

Im Beispielcode wird der gegenseitige Methodenaufruf der beiden Klassen deutlich:

Java Python all none

public class Rechnung {
    private double rechnungsbetrag;
    public double getRechnungsbetrag() {return rechnungsbetrag;}

    private boolean bezahlt=false;
    public void setBezahlt(boolean bezahlt, Kunde kunde) {
        this.bezahlt = bezahlt;
        System.out.println("wurde gezahlt von "+kunde.toString());
}   }

public class Kunde {
    private int vermoegen;
    public void bezahleRechnung(Rechnung rechnung){
        vermoegen -= rechnung.getRechnungsbetrag();
        rechnung.setBezahlt(true, this);
    }   }

class Rechnung:
    def __init__(self, rechnungsbetrag: float):
        self.__rechnungsbetrag: float
        self.__rechnungsbetrag = rechnungsbetrag
        self.__bezahlt: bool
        self.__bezahlt = False

    def get_rechnungsbetrag(self):
        return self.__rechnungsbetrag;
    
    def set_bezahlt(self, bezahlt: bool, kunde):
        self.__bezahlt = bezahlt
        print("wurde gezahlt von "+str(kunde.get_name()))

class Kunde:
    def __init__(self, vermoegen:float, name:str):
        self.__vermoegen: int
        self.__vermoegen = vermoegen
        self.__name = name
        
    def bezahle_rechnung(self, rechnung):
        self.__vermoegen -= rechnung.get_rechnungsbetrag()
        rechnung.set_bezahlt(True, self)

    def get_name(self) -> str:
        return self.__name

Nicht navigierbare Assoziation

Modellierbar ist auch der Fall, dass keine Richtung navigierbar ist. Keines der Objekte hält dann direkt Referenzen auf das jeweils andere (zwei “x” an den Kantenenden), es besteht nur eine logische, aber keine faktische Beziehung. Ich bin für jeden Hinweis dankbar, wann es einen sinnvollen Anwendungsfall hierfür gibt und wie dieser implementiert werden muss.

Multiplizitäten

Bei den bisherigen Notationsmitteln für Assoziationen wurde noch keine Festlegung getroffen, wie viele Objekte der einen Klasse mit wie vielen Objekte der anderen Klasse in Beziehung stehen. Im folgenden Diagramm sind eine Reihe von Festlegungen für ein Programm zur Erstellung von Rechnungen getroffen. Zu jeder Kante können zwei unterschiedliche Multiplizitäten ausgewiesen werden: für jeder der beiden Klassen je eine:

Sofern die Multiplizität die Zahl 1 überschreitet, werden die entsprechenden Referenzen in Objektsammlungen gespeichert. Je nach Programmiersprache können diese als Array, ArrayList, List o.ä. umgesetzt werden. Jede Multiplizität legt fest, wie viele Instanzen der Klasse, an der sie notiert ist, an der Beziehung mindestens und höchstens beteiligt sind. Möglich sind folgende Notationen:

Im Programmtext muss anhand des Datentyps der Referenz oder über Implementierung sichergestellt werden, dass die jeweilige Anzahl an Instanzen übergeben werden kann.

Die Begriffe Kardinalität und Multiplizität

In der UML wird eine tatsächliche Anzahl der verknüpften Instanzen Kardinaltät genannt. An folgendem Beispiel soll das deutlich werden: Ein Fahrzeug kann eines oder viele Räder haben.

Ist das Fahrzeug ein Fahrrad, so beträgt die tatsächliche Anzahl (die Kardinalität) 2, bei einem Auto 4, bei einem Einrad 1, bei einer Ape 3 und bei einem Zug ein Vielfaches von 4 - z.B. 128. Der Begriff Kardinalität beschreibt in der UML also die konkrete Anzahl an Beziehungen einer identifizierten Instanz der Klasse. Das weicht von der Bedeutung ab, mit der Kardinalität bei der Datenbankmodellierung (Entity Relationship Model) verwendet wird - dort ist Kardinalität synonym zu Multiplizität zu sehen.

In der UML ist der Begriff Multiplizität definiert als die Menge aller zulässigen Kardinalitäten. Ein Fahrzeug allgemein kann ein oder viele Räder haben: Die Multiplizität ist daher 1..*.

Aggregation

Die bisherigen Assoziationen beschreiben eine temporäre, einem Ziel zugeordnete Zusammenarbeit zweier Objekte. Wir können diese mit “benutzt ein” beschreiben. Eine engere Bindung zweiter Objekte ist gegeben, wenn Objekte zueinander eine dauerhafte Teil-Ganzes-Beziehung haben, die mit Phrasen wie “besteht aus” oder “hat ein/e” beschrieben werden können (in umgekehrter Leserichtung: “ist Teil von”).

Die zugeordneten Instanzen der Teile werden i.d.R. in Attributen des Ganzen verwaltet. Per Setter-Methoden wird das Ganze (das Aggregat) zusammengesetzt, somit im wörtlichen Sinne aggregiert. Man nennt diese Beziehung daher Aggregation.

Im UML-Klassendiagramm wird diese besondere Assoziation durch eine nicht ausgefüllte Raute aufseiten des Ganzen notiert.

Bei einer Aggregation kann das Teil auch unabhängig vom Ganzen existieren - es gibt Referenzen auf das Teil außerhalb des Ganzen (z.B. in dem die Teil-Instanz außerhalb des Ganzen erzeugt wird).

Es kann auch Teilinstanzen geben, die mehreren Ganzen zugeordnet sind. Denkbar wäre im obigen Beispiel etwa, dass Konten mehreren Kundinnen zugeordnet werden oder eine Kundin gelöscht wird, die Konten aber weiterbestehen. Ein Quelltextbeispiel:

Java Python all none

public class Kunde {
    private ArrayList<Konto> kontenListe;
    public void addKonto(Konto konto){this.kontenListe.add(konto);}

    public double gesamtVermoegen(){
        double vermoegen = 0;
        for(Konto konto:kontenListe){
            vermoegen+=konto.getKontostand();
        }
        return vermoegen;
}   }

public class Konto {
    private double kontostand;
    public double getKontostand() {return kontostand;}
}

class Kunde:
    def __init__(self):
        self.__kontenliste = []

    def add_konto(self, konto):
        self.__kontenliste.append(konto)

    def gesamt_vermoegen(self):
        vermoegen = 0.0
        for konto in self.__kontenliste:
            vermoegen += konto.get_kontostand()
        return vermoegen
    

class Konto:
    def __init__(self, kontostand: float):
        self.__kontostand: float
        self.__kontostand = kontostand

    def get_kontostand(self):
        return self.__kontostand
    
    def set_bezahlt(self, bezahlt: bool, kunde):
        self.__bezahlt = bezahlt
        print("wurde gezahlt von "+str(kunde.get_name()))

Komposition

Bei der Komposition handelt es sich um eine Sonderform der Teil/Ganzes-Beziehung: Die Teilobjekte existieren nur innerhalb des Ganzen und sind somit in Ihrer Lebensdauer auf die Lebensdauer des zugehörigen Ganzen beschränkt. Da dies eine festere Bindung zwischen Teil und Ganzem ist, wird in der Literatur hierfür häufig auch der Begriff “starke Aggregation” gewählt.

Aufgrund dieser Abhängigkeit kann ein Teil auch nur mit einem Ganzen in Beziehung stehen - die Multiplizität aufseiten des Ganzen ist per Definition in der Regel “1” (der Defaultwert) wird daher oft weggelassen.

Die Komposition wird mir einer ausgefüllten Raute aufseiten des Ganzen gekennzeichnet:

Kompositionen erkennt man in der Programmierung in der Regel daran, dass das Teil innerhalb des Ganzen erzeugt wird und das Teilobjekt nicht über Getter oder öffentliche Attribute nach außen veröffentlicht wird. Nur das Ganze hält Referenzen auf das Teil.

Die Entscheidung, ob eine Beziehung als Aggregation oder Komposition umgesetzt wird, trifft der/die Programmierer*in. Häufig gibt die Fachdomäne über gegebene Abhängigkeiten bereits Hinweise, was sinnvoll ist. In der Regel führt die Komposition zu besser wartbarem Code, da weniger externe Abhängigkeiten möglich sind.

Quelltextbeispiel:

Java Python all none

public class Rechnung {

   private ArrayList<Rechnungsposition> rechnungspositionen = new ArrayList<Rechnungsposition>();

   public void addRechnungsposition(String name, String artikelnummer, int anzahl, float nettopreis) {
       rechnungspositionen.add(new Rechnungsposition(name, artikelnummer, anzahl, nettopreis));
   }

   @Override
   public String toString() {
       String text = "Rechnung: \n";
       for (Rechnungsposition position : rechnungspositionen) {
           text += rechnungspositionen.toString() + "\n";
       }
       return text;
}   }


class Rechnungsposition {

   private String name;
   private String artikelnummer;
   private int anzahl;
   private float nettopreis;

   Rechnungsposition(String name, String artikelnummer, int anzahl, float nettopreis) {
       this.name = name;
       this.artikelnummer = artikelnummer;
       this.anzahl = anzahl;
       this.nettopreis = nettopreis;
   }

   @Override
   public String toString() {
       return "Name: " + this.name + " /  Artikelnummer: " + artikelnummer + " / Anzahl: " + this.anzahl + " / Nettoeinzelpreis: " + this.nettopreis;
}    }

 class Rechnung:
    def __init__(self):
        self.__rechnungspositionen = []

    def add_rechnungsposition(self, name:str, artikelnummer:str, anzahl: int, nettopreis:float):
        rechnungsposition = Rechnungsposition(name, artikelnummer, anzahl, nettopreis)
        self.__rechnungspositionen.append(rechnungsposition)


    def __str__(self):
        text = ""
        for position in self.__rechnungspositionen:
            text += str(position) + "\n"
        return text
    
class Rechnungsposition:
    def __init__(self, name:str, artikelnummer:str, anzahl: int, nettopreis:float):
        self.__name = name
        self.__artikelnummer = artikelnummer
        self.__anzahl = anzahl
        self.__nettopreis = nettopreis

    def __str__(self):
        return "Rechnungsposition: {0} {1} {2} {3:0.2f}".format(self.__name,
                                                                self.__artikelnummer,
                                                                self.__anzahl,
                                                                self.__nettopreis)

Für Experten / Hintergrund

Die UML lässt die Möglichkeit, dass Teile vom Ganzen entkoppelt werden und dann auch nicht mit dem Ganzen gelöscht werden. Um diesen Sonderfall abzubilden, müsste man eine Getter-Methode implementieren, die innerhalb des Ganzen die Referenz auf das Teil löscht, sobald es das Ganze verlässt. In obigem Beispiel könnte so eine Methode in Rechnung etwa so aussehen:

    public Rechnungsposition removeRechnungsposition(int index) {
         return rechnungspositionen.remove(index);
    }

Übersicht von Assoziation, Aggregation und Komposition

Die unterschiedlichen Objektbeziehungen anhand der oben genannten Beispiele ergeben insgesamt die Modellierung eines Abrechnungssystems:

Links und weitere Informationen

• Primärquelle: Klassendiagramme werden in Kapitel 11.4 der aktuellen Spezifikation von UML definiert: https://www.omg.org/spec/UML

Hinweis zur Nachnutzung als Open Educational Resource (OER)

Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Objektbeziehungen - Assoziationen” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/uml-klassendiagramm-assoziation veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/uml/umlklasse. Stand: 24.05.2023.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]