UML Klassendiagramm

Der Bauplan deiner Software

Stell dir vor, du entwirfst die Software für einen Online-Shop. Ein UML-Klassendiagramm ist wie der detaillierte Bauplan dafür. Es zeigt dir die statische Struktur – also die festen Bestandteile und wie sie zusammenhängen. Eine Klasse ist dabei der Bauplan (z.B. der allgemeine Plan für ein 'Produkt' mit Eigenschaften wie Name, Preis, Beschreibung), während ein Objekt eine konkrete Ausprägung dieses Plans ist (z.B. das spezifische 'Smartphone Modell X' mit dem Namen 'SuperPhone', dem Preis 499€ und der Beschreibung 'Neueste Technologie'). Du siehst im Klassendiagramm auf einen Blick:

• Welche Klassen (die verschiedenen Grundtypen von Elementen im Shop, z.B. Person, Produkt, Bestellung) gibt es?
• Welche Attribute (Eigenschaften dieser Elemente, z.B. für Produkt: artikelnummer, preis, bezeichnung) haben sie?
• Welche Methoden (Was können diese Elemente tun? z.B. für Produkt: preisAktualisieren(), verfuegbarkeitPruefen()) bieten sie an?

Es hilft dem gesamten Team, die Architektur der Software zu verstehen, zu planen und darüber zu sprechen. Ein Klassendiagramm ist somit ein zentrales Werkzeug im Softwareentwurf, um die Struktur eines Systems zu visualisieren, zu dokumentieren und zu kommunizieren, bevor oder während es entwickelt wird. Es dient als gemeinsame Sprache für Entwickler:innen, Architekt:innen und manchmal auch für technisch versierte Stakeholder.

Die Klasse: Der Grundbaustein

Jede Klasse wird als Rechteck dargestellt, meist unterteilt in drei Bereiche:

1. Klassenname: Ganz oben steht der Name der Klasse (z.B. Person, Produkt, Bestellung).
2. Attribute: Darunter folgen die Eigenschaften oder Datenfelder, die Objekte dieser Klasse besitzen. Jedes Attribut hat einen Namen und typischerweise einen Datentyp. Zusätzlich wird die Sichtbarkeit angegeben:
   • + public: Das Attribut ist von überall im Programm sichtbar und zugreifbar.
   • - private: Das Attribut ist nur innerhalb der eigenen Klasse sichtbar und zugreifbar (z.B. - kundennummer: String).
   • # protected: Das Attribut ist innerhalb der eigenen Klasse und in davon abgeleiteten Klassen (Unterklassen) sichtbar.
   • Beispiel für Attribute in einer Klasse Produkt: - produktID: Integer, + bezeichnung: String, - einkaufspreis: Double
3. Methoden: Ganz unten stehen die Operationen oder Verhaltensweisen, die Objekte dieser Klasse ausführen können. Jede Methode hat einen Namen, kann Parameter (Eingabewerte mit Typen) haben, besitzt einen Rückgabetyp (den Datentyp des Ergebnisses, das sie liefert; void bedeutet, sie liefert kein Ergebnis) und ebenfalls eine Sichtbarkeit.
   • Beispiel für Methoden in einer Klasse Produkt: + getVerkaufspreis(): Double, + setLagerbestand(neuerBestand: Integer): void

Assoziation: Eine allgemeine Verbindung

Eine Assoziation beschreibt eine allgemeine Beziehung zwischen zwei (oder mehr) Klassen. Sie bedeutet, dass Objekte dieser Klassen miteinander in Verbindung stehen oder interagieren.

• Beispiel: Eine Person tätigt eine Bestellung.
• Notation: Eine durchgezogene Linie zwischen den Klassen. An den Enden der Linie können Rollennamen und Multiplizitäten (auch Kardinalitäten genannt) angegeben werden.
• Multiplizitäten: Geben an, mit wie vielen Objekten der anderen Klasse ein Objekt verbunden sein kann.
  • 1: Genau ein Objekt. (Jede Bestellung gehört zu genau 1 Person.)
  • * oder 0..*: Null bis beliebig viele Objekte. (Eine Person kann 0..* Bestellungen tätigen.)
  • 1..*: Mindestens ein bis beliebig viele Objekte. (Eine Bestellung enthält 1..* Bestellpositionen.)
  • 0..1: Null oder ein Objekt. (Ein:e Mitarbeiter:in hat 0..1 Dienstwagen.)

Aggregation: Ein "Teil-von"-Verhältnis (locker)

Eine Aggregation ist eine spezielle Form der Assoziation, die eine "hat-ein" oder "Teil-von"-Beziehung darstellt. Das Ganze (Aggregat) besteht aus Teilen, aber die Teile können auch unabhängig vom Ganzen existieren.

• Beispiel: Ein Warenkorb enthält Artikel. Wenn der Warenkorb geleert oder gelöscht wird, existieren die Artikel (als Produktdefinitionen im System) weiterhin.
• Notation: Eine durchgezogene Linie mit einer leeren Raute an der Seite der Klasse, die das "Ganze" darstellt (dem Warenkorb). z.B. Warenkorb <>---- 0..* Artikel

Komposition: Ein "Teil-von"-Verhältnis (stark)

Die Komposition ist eine stärkere Form der "hat-ein"-Beziehung. Hier sind die Teile (Komponenten) existenziell vom Ganzen (Kompositum) abhängig. Wird das Ganze gelöscht, werden auch seine Teile unwiderruflich mitgelöscht.

• Beispiel: Eine Bestellung enthält Bestellpositionen. Wird die Bestellung storniert und gelöscht, existieren auch ihre spezifischen Bestellpositionen nicht mehr eigenständig.
• Notation: Eine durchgezogene Linie mit einer gefüllten Raute an der Seite der Klasse, die das "Ganze" darstellt (der Bestellung). z.B. Bestellung <#>---- 1..* Bestellposition

Generalisierung/Vererbung: Eine "Ist-ein"-Beziehung

Generalisierung (in der Programmierung oft als Vererbung bezeichnet) beschreibt eine hierarchische "ist-eine-Art-von"-Beziehung. Eine spezialisierte Klasse (Unterklasse oder Subklasse) erbt Attribute und Methoden von einer allgemeineren Klasse (Oberklasse oder Superklasse) und kann diese erweitern oder anpassen.

• Beispiel: Ein Buch ist ein Produkt. Ein Elektronikartikel ist auch ein Produkt. Sowohl Buch als auch Elektronikartikel erben allgemeine Eigenschaften von Produkt (z.B. artikelnummer, preis, Methode getBeschreibung()) und fügen spezifische hinzu (z.B. ISBN für Buch, technischeDaten für Elektronikartikel).
• Notation: Eine durchgezogene Linie mit einer leeren Pfeilspitze (einem nicht ausgefüllten Dreieck), die auf die Oberklasse (die allgemeinere Klasse, hier Produkt) zeigt.

Abhängigkeit: Eine "Benutzt"-Beziehung

Eine Abhängigkeit (Dependency) zeigt, dass eine Klasse (der Client) eine andere Klasse (den Supplier) für ihre Funktionalität benötigt, typischerweise temporär. Dies kann z.B. der Fall sein, wenn eine Methode der Client-Klasse ein Objekt der Supplier-Klasse als Parameter erhält oder eine lokale Variable vom Typ der Supplier-Klasse verwendet. Eine Änderung in der Supplier-Klasse kann Änderungen in der Client-Klasse erforderlich machen.

• Beispiel: Ein Bestellservice benutzt einen Versanddienstleister, um die Versandkosten zu berechnen oder ein Versandetikett zu erstellen.
• Notation: Eine gestrichelte Linie mit einer offenen Pfeilspitze, die von der abhängigen Klasse (Client, hier Bestellservice) auf die Klasse zeigt, von der sie abhängt (Supplier, hier Versanddienstleister).

Realisierung: Implementierung einer Schnittstelle

Eine Realisierung (Implementation) beschreibt die Beziehung zwischen einer Klasse und einem Interface (einer Schnittstelle). Ein Interface definiert einen Vertrag – eine Sammlung von Methodensignaturen (was eine Klasse können muss) – aber nicht deren konkrete Umsetzung (das Wie). Eine Klasse, die ein Interface realisiert, verspricht, alle im Interface definierten Methoden zu implementieren.

• Beispiel: Ein Interface IZahlungsart könnte eine Methode zahlungDurchfuehren() vorschreiben. Die Klassen PayPalZahlung und KreditkartenZahlung realisieren beide dieses Interface und stellen jeweils ihre eigene zahlungDurchfuehren()-Methode bereit.
• Notation: Eine gestrichelte Linie mit einer leeren Pfeilspitze (einem nicht ausgefüllten Dreieck), die von der implementierenden Klasse auf das Interface zeigt.