UML-Klassendiagramm lesen und erstellen

UML-Klassendiagramm

UML – die Unified Modeling Language – ist die Sprache der Software-Modellierung. Während du in den letzten Lektionen viel Code geschrieben hast, ist UML eine grafische Notation, um Klassen und ihre Beziehungen vor dem Code zu skizzieren oder Bestehendes zu dokumentieren. In der IHK-Prüfung kommen UML-Diagramme garantiert dran – meist mit Aufgaben wie „lies das Diagramm und erkläre die Vererbungshierarchie" oder „erstelle das Diagramm zu folgendem Code".

Diese Lektion deckt das UML-Klassendiagramm ab – das wichtigste der 14 UML-Diagrammtypen. Du lernst die Notation für Klassen, Sichtbarkeit, Beziehungen (Vererbung, Assoziation, Aggregation, Komposition), Multiplizitäten, und gegenseitige Übersetzung zwischen Code und Diagramm.

1) Was ist UML?

UML wurde Mitte der 1990er entwickelt, um die vielen konkurrierenden Modellierungs-Notationen zu vereinheitlichen. Heute ist sie ISO-standardisiert (ISO/IEC 19501) und wird in fast jedem größeren Software-Projekt zumindest teilweise eingesetzt. Es gibt insgesamt 14 Diagrammtypen, die in zwei Kategorien fallen:

Strukturdiagramme: zeigen die statische Struktur eines Systems. Wichtigste: Klassendiagramm, Komponentendiagramm, Verteilungsdiagramm.
Verhaltensdiagramme: zeigen Dynamik. Wichtigste: Anwendungsfalldiagramm, Sequenzdiagramm, Zustandsdiagramm, Aktivitätsdiagramm.

Für OOP ist das Klassendiagramm der Star – wir konzentrieren uns hier ganz darauf.

2) Eine UML-Klasse

Eine Klasse wird in UML als Rechteck mit drei Abschnitten dargestellt: Name oben, Attribute mittig, Methoden unten:

Eine UML-Klasse Schritt für Schritt

Person

-name: String

-alter: int

-email: String

+getName(): String

+setEmail(email: String): void

+istVolljaehrig(): boolean

Drei Abschnitte:

oben der Klassenname in Fett
mittig die Attribute mit Sichtbarkeit, Name, Typ
unten die Methoden mit Sichtbarkeit, Name, Parameter, Rückgabetyp

Format der Attribute: sichtbarkeit name: Typ. Format der Methoden: sichtbarkeit name(parameter: Typ): Rückgabetyp. In Diagrammen kann man Abschnitte weglassen wenn sie nicht wichtig sind – z.B. nur Name + Methoden, wenn die Attribute nicht relevant sind. UML-Tools zeigen das oft erst auf Klick.

3) Sichtbarkeits-Symbole

Du hast in L4 die Sichtbarkeiten kennengelernt. UML hat dafür kompakte Symbole:

UML-Sichtbarkeits-Symbole

+public

Von überall zugreifbar – die öffentliche API

#protected

Klasse selbst + Unterklassen

~package

Java-package-private (kein Modifier in Java-Code)

−private

Nur innerhalb der eigenen Klasse

Statische (Klassen-)Attribute und -Methoden werden in UML unterstrichen dargestellt. Abstrakte Methoden in kursiv. Konstanten oft mit «readOnly»-Stereotyp markiert oder Großbuchstaben-Namen.

4) Beziehungen zwischen Klassen

Das Herzstück von UML-Klassendiagrammen sind die Beziehungstypen. Hier wird's für die Klausur wichtig – jeder Pfeil hat eine andere Bedeutung:

Die wichtigsten Beziehungstypen

━━▷

Vererbung / Generalisierung

Durchgezogener Pfeil mit leerer dreieckiger Spitze. „A erbt von B" / „A ist-ein B". In Java: extends.

┄┄▷

Realisierung / Interface-Implementierung

Gestrichelter Pfeil mit leerer dreieckiger Spitze. „A implementiert Interface B". In Java: implements.

────

Assoziation

Einfache Linie. „A kennt B" / „A nutzt B". Sehr lose Beziehung, oft als Attribut-Referenz.

━━━▶

Gerichtete Assoziation

Pfeil mit offener Spitze. A kennt B, aber B kennt A nicht. Klärt die Richtung.

◇────

Aggregation

Leere Raute am Aggregat-Ende. „A hat B" mit lockerer Beziehung – B kann auch ohne A existieren.

◆────

Komposition

Gefüllte Raute am Container-Ende. „A besitzt B" mit starker Bindung – B existiert nur als Teil von A.

┄┄▶

Abhängigkeit

Gestrichelter Pfeil. „A nutzt B kurz". Schwächste Beziehung – z.B. B ist Parameter einer Methode von A.

Die Unterscheidung Aggregation vs. Komposition ist in Klausuren beliebt. Klassisches Beispiel: ein Auto ist mit seinen Rädern in Komposition (geht das Auto in den Schrott, sind die Räder weg). Ein Verein ist mit seinen Mitgliedern in Aggregation (löst sich der Verein auf, leben die Mitglieder weiter).

5) Multiplizitäten

An den Enden von Assoziationen kann man angeben wie viele Objekte beteiligt sind:

Multiplizitäten

Genau ein Objekt

0..1

Null oder ein Objekt (optional)

Beliebig viele (auch null)

1..*

Mindestens ein Objekt

3..5

3 bis 5 Objekte

Genau 5 Objekte

Beispiel: Person — 1..* — Konto bedeutet: jede Person hat mindestens ein Konto, jedes Konto gehört zu genau einer Person. Multiplizitäten sind essentiell für Datenbankschema-Design – sie übersetzen sich direkt in SQL-Beziehungen.

6) Komplettes Beispiel-Diagramm

So sieht ein realistisches UML-Klassendiagramm aus. Ein kleines Shop-System mit Kunden, Bestellungen und Produkten:

Beispiel: Shop-System

«interface» Zahlbar

+berechneBetrag(): double

Bestellung

-id: int

-datum: Date

-kunde: Kunde

+berechneBetrag(): double

+addProdukt(p: Produkt): void

OnlineBestellung

-versandadresse: Adresse

Abholbestellung

-filiale: Filiale

Lesen wir das Diagramm: Bestellung ist abstrakt (kursiver Name). Sie implementiert das Interface Zahlbar (gestrichelter Pfeil hoch). Zwei konkrete Klassen erben von Bestellung: OnlineBestellung und Abholbestellung (durchgezogene Vererbungspfeile hoch). Jede konkrete Klasse hat ein zusätzliches Attribut.

Beachte die Stereotypes: «interface» kennzeichnet Interfaces (oft auch durch Italics). Manche Tools nutzen einen kleinen Kreis oder ein «I» Symbol. Im Klassendiagramm können beliebig viele Klassen, Interfaces, Beziehungen kombiniert werden – große Systeme haben Dutzende.

7) Code zu UML übersetzen

Lass uns das umgekehrte machen: gegeben sei dieser Java-Code – wie sieht das UML-Diagramm dazu aus?

Mitarbeiter.javaJava

1public class Mitarbeiter {
2    private String name;
3    private double gehalt;
4    protected Abteilung abteilung;
5
6    public Mitarbeiter(String name, double gehalt) { ... }
7    public double getGehalt() { ... }
8    public void setGehalt(double g) { ... }
9}

Das UML-Diagramm dazu:

Daraus ergibt sich:

Mitarbeiter

-name: String

-gehalt: double

#abteilung: Abteilung

+Mitarbeiter(name: String, gehalt: double)

+getGehalt(): double

+setGehalt(g: double): void

Beachte: der Konstruktor steht bei den Methoden ohne Rückgabetyp. Manche Tools lassen ihn weg oder markieren mit «constructor». Das Attribut abteilung könnte alternativ als Assoziation zur Abteilungs-Klasse dargestellt werden (Pfeil von Mitarbeiter zu Abteilung) – beides ist erlaubt.

8) UML-Werkzeuge in der Praxis

Für UML gibt es viele Tools – kostenpflichtig und gratis:

draw.io / diagrams.net: kostenlos, browser-basiert, sehr beliebt für schnelle Diagramme
PlantUML: Code-basiert! Du beschreibst UML in Textform, das Tool generiert das Diagramm. Versionierbar im Git, eingebettet in IDEs.
Mermaid: ähnlich PlantUML, aber für Markdown-Integration. GitHub, GitLab und Wikis unterstützen es nativ.
StarUML, Visual Paradigm, Enterprise Architect: professionelle Suites, oft in Großunternehmen
IntelliJ IDEA / Eclipse Plugins: generieren UML aus Code, manchmal auch umgekehrt

Ein PlantUML-Beispiel als Vorgeschmack:

diagramm.pumlPlantUML

1@startuml
2class Mitarbeiter {
3    -name: String
4    -gehalt: double
5    +getGehalt(): double
6}
7class Manager extends Mitarbeiter {
8    -bonus: double
9}
10Manager "*" -- "1" Abteilung
11@enduml

9) Wann lohnt sich UML?

UML ist mächtig, aber wird in der Praxis nicht überall gelebt. Ehrliche Einschätzung:

UML lohnt sich:

In der Entwurfsphase großer Systeme – bevor Code geschrieben wird
Bei der Dokumentation komplexer Architekturen für neue Team-Mitglieder
Zur Kommunikation mit nicht-technischen Stakeholdern
In IHK-Prüfungen und an Hochschulen – fast überall im Pflichtprogramm
Bei Code-Reviews und Architektur-Reviews

UML lohnt sich weniger:

Bei agilen, sich ständig ändernden Projekten – Diagramme veralten sofort
Für kleine Skripte und Wegwerf-Tools
Wenn das Team kein UML kann oder will – dann lieber andere Notation

Moderne Faustregel: UML pragmatisch nutzen. Nicht alles vorab zeichnen. Bei wichtigen Klassen-Beziehungen einfach am Whiteboard skizzieren, fotografieren, im Wiki ablegen. „Lebende" UML-Dokumentation durch automatisch generierte Diagramme aus Code.

10) Häufige Klausurfragen

„Was ist UML?" → Unified Modeling Language, standardisierte grafische Notation für Software-Modelle
„Welche Sichtbarkeits-Symbole gibt es?" → + public, # protected, ~ package, − private
„Unterschied Aggregation und Komposition?" → Aggregation = lose (B kann ohne A leben); Komposition = stark (B existiert nur als Teil von A)
„Wie zeigt man Vererbung?" → Durchgezogener Pfeil mit leerer dreieckiger Spitze, von Unterklasse zur Oberklasse
„Wie zeigt man Interface-Implementierung?" → Gestrichelter Pfeil mit leerer dreieckiger Spitze
„Was bedeutet ein kursiver Klassenname?" → Abstrakte Klasse
„Was bedeutet eine unterstrichene Methode?" → Statische (Klassen-)Methode
„Was bedeutet die Multiplizität 1..*?" → Mindestens ein Objekt
„Erstelle Diagramm zu Code X" oder „Erstelle Code zu Diagramm Y" → klassisch in Prüfungen, einfach Schritt für Schritt übersetzen

Zusammenfassung

UML-Klassendiagramme zeigen die statische Struktur eines OOP-Systems. Klassen-Box mit drei Abschnitten: Name, Attribute, Methoden. Sichtbarkeit: + public, # protected, ~ package, − private. Beziehungstypen: Vererbung (durchgezogener Pfeil), Realisierung (gestrichelt), Assoziation, Aggregation (leere Raute, lockere Bindung), Komposition (gefüllte Raute, starke Bindung), Abhängigkeit. Multiplizitäten an Beziehungsenden: 1, 0..1, *, 1..*, n..m. Abstrakte Klassen kursiv, statische Methoden unterstrichen, Interfaces mit «interface»-Stereotyp. Tools: draw.io, PlantUML, Mermaid (code-basiert, versionierbar). UML ist Klausur-Standard und sollte beherrscht werden – sowohl Diagramm lesen als auch erstellen.