Wozu dient ein UML-Klassendiagramm und wie ist es aufgebaut?
Die statische Struktur der Software visualisieren
Aus der Datenbankmodellierung kennst du bereits das Entity-Relationship-Modell (ERM), um Datenstrukturen zu planen. Das UML-Klassendiagramm erfüllt einen ähnlichen Zweck, jedoch für die Architektur der eigentlichen Software. Es visualisiert die statische Struktur eines objektorientierten Systems.
Bevor du auch nur eine Zeile Code schreibst, dient dieses Diagramm dem Entwicklungsteam als gemeinsamer Bauplan. Es zeigt auf einen Blick, aus welchen Bausteinen (Klassen) das Programm besteht und wie diese logisch zusammenhängen. Im Gegensatz zum ERM definiert das Klassendiagramm nicht nur, welche Daten ein Objekt speichert, sondern auch, welches Verhalten es ausführen kann.
Die Klasse: Der dreigeteilte Bauplan
Der zentrale Baustein des Diagramms ist die Klasse, die in drei horizontale Bereiche unterteilt ist:
- Klassenname: Steht im obersten Bereich und wird meist im Singular geschrieben (z. B.
Produkt). - Attribute: Der mittlere Bereich definiert die Eigenschaften (den Zustand) der Klasse. Jedes Attribut besitzt einen Namen und einen Datentyp (z. B.
preis: Double). - Methoden: Der untere Bereich definiert das Verhalten (die Funktionen). Hier notierst du den Methodennamen, mögliche Parameter in Klammern und den Rückgabetyp (z. B.
berechneRabatt(prozent: Integer): Double).
Datenkapselung durch Sichtbarkeitsmodifikatoren
Ein wichtiges Prinzip der objektorientierten Programmierung ist die Datenkapselung. Um diese zu modellieren, erhalten Attribute und Methoden im Diagramm ein Vorzeichen, den sogenannten Sichtbarkeitsmodifikator (Visibility):
+public (öffentlich): Jeder andere Teil des Programms darf auf dieses Element zugreifen. Dies wird häufig für Methoden genutzt, die von außen aufrufbar sein müssen (z. B.+ inDenWarenkorbLegen()).-private (privat): Nur die Klasse selbst darf dieses Element lesen oder ändern. Dies ist der Standard für die meisten Attribute, um sie vor ungewollten Änderungen zu schützen (z. B.- passwortHash: String).#protected (geschützt): Das Element ist für die Klasse selbst sowie für alle ihre abgeleiteten Unterklassen (durch Vererbung) sichtbar.
Welche Beziehungsarten gibt es zwischen Klassen?
Assoziation, Rollen und Multiplizitäten
Eine Assoziation ist die grundlegendste Verbindung und zeigt an, dass zwei Klassen miteinander kommunizieren oder in Beziehung stehen. Um die Beziehung genauer zu beschreiben, werden oft Rollennamen an die Enden der Verbindung geschrieben (z. B. + käufer), die die Funktion der Zielklasse in diesem spezifischen Kontext erklären.
Ähnlich wie bei den Kardinalitäten im ER-Modell nutzt UML Multiplizitäten, um die genaue Anzahl der beteiligten Objekte zu definieren:
1: Genau ein Objekt.0..1: Null oder maximal ein Objekt.0..*oder*: Beliebig viele Objekte (von null bis unendlich).1..*: Mindestens ein Objekt.
Beispiel: Eine Kundschaft (1) tätigt beliebig viele Bestellungen (0..*).
Aggregation und Komposition: Das "Teil-von"-Verhältnis
Diese beiden Beziehungen beschreiben hierarchische Strukturen, bei denen ein Objekt aus anderen Objekten besteht. Die grafische Unterscheidung durch Rauten verdeutlicht die existenzielle Abhängigkeit:
- Aggregation (lockere Bindung): Die Teile können auch unabhängig vom "Ganzen" existieren.
- Beispiel: Ein
WarenkorbenthältProdukte. Wird der Warenkorb gelöscht, existieren die Produkte im Shop-System weiterhin problemlos. - Komposition (starke Bindung): Die Teile sind existenziell vom Ganzen abhängig. Sie werden gemeinsam erstellt und zerstört.
- Beispiel: Eine
Bestellungbesteht ausBestellpositionen. Wird die gesamte Bestellung storniert und aus dem System gelöscht, werden auch ihre spezifischen Positionen unwiderruflich gelöscht.
Generalisierung: Die "Ist-ein"-Beziehung (Vererbung)
Die Generalisierung modelliert eine Vererbungshierarchie. Eine spezialisierte Unterklasse erbt dabei alle Attribute und Methoden einer allgemeinen Oberklasse und kann diese um eigene, spezifische Eigenschaften erweitern.
Beispiel: Die Klassen Buch und Elektronikartikel erben von der Oberklasse Produkt. Beide sind ein Produkt und besitzen daher automatisch das Attribut - preis. Die Unterklasse Buch fügt jedoch das spezifische Attribut - isbn hinzu, während Elektronikartikel das Attribut - spannung ergänzt. Dies verhindert redundanten Code und fördert die Wiederverwendbarkeit.
Abhängigkeit und Realisierung
Zwei weitere wichtige Beziehungen beschreiben das Verhalten von Klassen zueinander, ohne dass sie dauerhaft strukturell verknüpft sind:
- Abhängigkeit (Dependency): Eine Klasse benötigt eine andere nur kurzzeitig, um ihre Aufgabe zu erfüllen. Ändert sich die Zielklasse, muss eventuell auch die abhängige Klasse angepasst werden.
- Beispiel: Ein
Warenkorbnutzt die KlasseRabattRechnerlediglich als Parameter in einer Methode, um den Endpreis zu ermitteln. - Realisierung (Implementation): Eine Klasse setzt ein Interface (eine Schnittstelle) um. Das Interface gibt als Vertrag nur Methodennamen vor, die realisierende Klasse liefert den tatsächlichen, ausführbaren Code.
- Beispiel: Die Klassen
PayPalundKreditkarterealisieren das InterfaceIZahlungsartund müssen dessen vorgegebene MethodezahlungDurchfuehren()zwingend programmieren.
Teste dein Wissen
Dein Entwicklungsteam plant eine neue objektorientierte Anwendung. Du sollst den Bauplan der Architektur visualisieren. Welchen Aspekt zeigt das UML-Klassendiagramm?