Wer Software plant und entwickelt wird unweigerlich mit der Unified Modeling Language (kurz UML) in Berührung kommen.
Ich werde in  diesem Blog-Eintrag vor allem auf das Klassendiagramm, genauer auf die Beziehungen der einzelnen Klassen eingehen.

Das Klassendiagramm:

UML_ClassdiagramDas Klassendiagramm zeigt  Klassen eines Namespaces an und deren jeweilige Abhängigkeiten. Es handelt sich um eine statische Darstellung, da lediglich die Attribute und Methoden, sowie die Verbindungen der Klassen untereinander dargestellt werden. Es wird nicht gezeigt, wie diese Verbindungen stattfinden.

Darstellungselemente:

Zur Realisierung eines Klassendiagramms stehen folgende Formen und Notationen zur Verfügung

Klasse

ClassEine Klasse wird mit als Rechteck dargestellt und enthält Attribute und Methoden (Operationen). Sollte es sich um eine abstrakte Klasse handeln, so wird der Klassennamen kursiv dargestellt

Zusätzlich werden die in der Klasse enthaltenen Attribute und Operationen (bspw. Methoden) mit deren Daten- oder ggf. Rückgabetypen und Sichtbarkeiten dargestellt.

Class_ExplanationClass_AttrOperation

Zur Darstellung der Sichtbarkeit von Attributen und Funktionen bietet UML folgende Zeichen:

  • + steht für public, also eine öffentliche Funktion/ein öffentliches Attribut
  • # steht für protected, also eine geschützte Funktion/ein geschütztes Attribut
  • – steht für eine private Funktion/ein privates Attribut

Wie Anfangs erwähnt, stellt das Klassendiagramm auch die Beziehungen der Klassen untereinander dar. Ich werde in diesem Beitrag auf folgende Beziehungen eingehen und zu der jeweiligen Beziehung ein Codebeispiel (C#) geben:

  • Vererbung
  • Binäre Assoziation (zwei Klassen sind beteiligt)
  • Aggregation
  • Komposition
Vererbung:

Eine Vererbung (engl.: Inheritance) ist auch als „Ist-Ein-Beziehung“ oder „Ist-Implementiert-Als-Beziehung“ bekannt.

Als Beispiel dienen hier die Klassen Employee und Manager
Da ein Manager auch ein Mitarbeiter (Employee) ist, erbt die Klasse Manager von Employee
Dadurch werden Variablen, Felder und Methoden, welche nicht private sind in die erbende Klasse übernommen.
Achtung: Konstruktoren werden nicht vererbt und müssen daher manuell angesprochen werden:

public Manager(string _name):base(_name){ ... }

Die Umsetzung in C# würde wie folgt aussehen (Bild):

Employee-Klasse
Manager-Klasse
(Binäre) assoziation:

Eine Assoziation ist eine beliebige Beziehung zwischen den Objekten von Klassen. Hier werden wir nur die binären Assoziationen (2 Klassen sind beteiligt) behandeln.

Dies ist eine gerichtete Assoziation, das bedeutet, dass Klasse 1 die Klasse 2 kennt, dagegen Klasse 2 nichts von Klasse 1 weiß. In der Beschreibung wird Beschrieben auf welche Weise die Objekte in Verbindung stehen

Links sehen wir eine bidirektionale binäre Assoziation, d.h. die Firma kennt seinen Mitarbeiter und der Mitarbeiter seine Firma.

Die Form der Assoziation sähe in der Programmierung wie folgt aus (Man beachte die Kommentierung):

Bidirektionale binäre Assoziation
Aggregation:

Bei der Aggregation handelt es sich um eine spezielle Form der Assoziation. Sie ist auch als „Ganzes-Teil-Beziehung“ oder „Hat-Ein-Beziehung“ bekannt.
Darunter versteht man ein Objekt (Aggregatobjekt), welches aus verschiedenen Einzelteilen (Objekten) besteht, wobei diese nicht existenzabhängig sind (d.h. sie leben weiter, auch wenn das Aggregatobjekt zerstört wird.

Eine Beispiel für eine Aggregation wäre das Auto (als Ganzes) und ein Rad, als Teil.

Allgmeines BeispielAuto-Rad-Beispiel
public class Aggregatklasse
{
    ExistenzUnabhängigeKlasse objKlasse;
    public void doSomething(ExistenzUnabhängigeKlasse obj)
    {
      //Das Objekt der Klasse ExistenzUnabhängigeKlasse wird als Parameter übergeben 
      objKlasse = obj; 
	  // und ist somit noch existent wenn die Aggregatklasse zerstört wird
    }
}
Wird nachgereicht…

Komposition:

CompositionBei der Komposition handelt es sich um eine strenge Form der Aggregation. Das Kompositionsobjekt besteht, wie bei der Aggregation auch, aus mehreren Einzelteilen (Komponentenobjekte), welche jedoch im Gegensatz zur Aggregation mit der Zerstörung des Ganzen (Kompositionsobjekt) zerstört werden (Existenzabhängigkeit).
Damit ist auch die Kardinalität/Multiplizität auf Seite des Kompositionsobjekts immer 1. Das bedeutet, dass eine Komponente nur Teil eines Objekts sein kann. Somit wird sichergestellt, dass die Lebensdauer aller Objekte gleich ist. Die Kardinalität auf der Seite der Komponenten kann jedoch variable sein

Beispiel:
Ein Kunde einer Bank hat mindestens eine Anschrift und keine oder mehrere hinterlegte Bankverbindungen (kann per Rechnung zahlen).

CompositionExampleStirbt der Kunden, so wohnt er logischerweise nicht mehr und ist ebenso wenig ein Kunde der Bank. Seine Anschrift(en), sowie seine Bankverbindung(en) werden also zerstört

Die Umsetzung im Code würde wie folgt aussehen:

Codebeispiel Komposition