Abou Chleih

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:

Das 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

Eine 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.

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:

Quelle

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):

[spoiler title=“Employee-Klasse“ style=“fancy“ anchor=“BeispielVererbung“]

namespace Vererbung
{
    class Employee
    {
        static int staticID = 1;

        protected int ID = 0;
        protected string Name = "";

        public Employee(string _name)
        {
            CreateEmployee(_name);
        }

        protected void CreateEmployee(string _name)
        {
            staticID++;
            ID = staticID;
            Name = _name;
        }

        public int getID()
        {
            return ID;
        }

        public string getName()
        {
            return Name;
        }
    }
}

[/spoiler]

[spoiler title=“Manager-Klasse“ style=“fancy“]

namespace Vererbung
{
    class Manager:Employee
    {
        static int staticManagerID = 1;

        int ManagerID;

        public Manager(string _name):base(_name)
        {
            CreateManager();
        }

        private void CreateManager()
        {
            staticManagerID++;
            ManagerID = staticManagerID;
        }

        public int getManagerID()
        {
            return ManagerID;
        }
    }
}

[/spoiler]

(Binäre) assoziation:

Quelle

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

Quelle

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

Quelle

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):

[spoiler title=“Bidirektionale binäre Assoziation“ style=“fancy“ anchor=“BeispielAssoziation“]

public class Firma 
{ 
  public Mitarbeiter mitarbeiter; 
}

 public class Mitarbeiter 
{ 
  public Firma firma; 
}

public class Verzeichnis
{ 
  Mitarbeiter Mustermann = new Mitarbeiter(); 
  Firma  Musterfirma  = new Firma(); 
  Mustermann.firma  = Musterfirma;
  Musterfirma.mitarbeiter = Mustermann; 
  // Man beachte, dass die Objekte von Firma und Mitarbeiter in einer
  // weitern Klasse liegen und somit nicht voneinander abhängig sind
  // und somit weiterleben, auch wenn eines der Objekte zerstört wird
}

[/spoiler]

Aggregation:

Quelle

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.

[tabs]
[tab title=“Allgmeines 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
    }
}

[/tab]
[tab title=“Auto-Rad-Beispiel“]Wird nachgereicht…

[/tab]
[/tabs]

Komposition:

Bei 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).

Stirbt 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:

[spoiler title=“Codebeispiel Komposition“ style=“fancy“ anchor=“BeispielKomposition“]

public class CompositionClass
{
    SomeUtilityClass objSC = new SomeUtilityClass(); //Das Objekt der Klasse
    // existiert lediglich in der CompositionClass und wird mit dem Objekt der
    // CompositionClass vernichtet

    public void doSomething()
    {
        objSC.someMethod();
    }
}

[/spoiler]