UML & Modellierung — erst zeichnen, dann coden

Prüfungsaufgaben lassen Klassendiagramme ergänzen oder bewerten. Die Notationsregeln sind streng, aber wenige — wer sie kennt, hat die Aufgabe meist sicher.

Warum modelliert man

Modelle machen eine Lösung besprechbar, bevor Code entsteht. Fehler in der Modellierung sind billig zu beheben — umgesetzte Fehler sind teuer. Genau deshalb wird in der FIAE-Prüfung geprüft, ob man Diagramme lesen und ergänzen kann.

Klassendiagramm — das wichtigste Diagramm

Es zeigt Klassen mit Attributen und Methoden sowie ihre Beziehungen:

Element	Notation
Klasse	Rechteck, drei Abschnitte: Name / Attribute / Methoden
Sichtbarkeit	`+` public, `−` private, `#` protected, `~` package
Assoziation	durchgezogene Linie — „kennt"
Vererbung	Linie mit leerem Dreieck zur Oberklasse
Komposition	gefüllte Raute am Ganzen — Teil existiert nicht ohne Ganzes
Aggregation	leere Raute — Teil kann auch allein bestehen
Multiplizität	`1`, `0..1`, ``, `0..`, `1..*`

Lesebeispiel: Kunde 1 —— 0..* Bestellung heißt: Ein Kunde kann keine oder beliebig viele Bestellungen haben, jede Bestellung gehört genau einem Kunden.

Die häufigsten Fehler: Aggregation und Komposition vertauscht, Multiplizität auf der falschen Seite eingetragen, Vererbungspfeil vergessen, Sichtbarkeit als + bei Attributen gesetzt, die gekapselt sein sollten.

Use-Case-Diagramm

Zeigt von außen, was das System leisten soll — ohne Technik:

Akteur: Strichmännchen, immer außerhalb des Systems (auch Systeme können Akteure sein).
Anwendungsfall: Ellipse mit der Funktion.
Systemgrenze: Rechteck um die Anwendungsfälle.
<<include>>: zwingend mitbenutzt (Pflichtteil).
<<extend>>: optionale Erweiterung unter Bedingung.

Der Klassiker: include = immer, extend = nur manchmal. Wer das vertauscht, verliert die Aufgabe.

Aktivitäts- und Zustandsdiagramm

Aktivitätsdiagramm: Ablauf mit Start-/Endknoten, Aktionen (abgerundete Rechtecke), Entscheidungen (Raute), Verzweigung und Zusammenführung (Balken).
Zustandsdiagramm: Zustände einer Objektlebenszeit und die Übergänge dazwischen — nützlich für Auftrags- oder Bestellstatus.

ER-Modell für Datenbanken

Vor der Datenbank steht das Entity-Relationship-Modell:

Entität: Objekttyp, z. B. Kunde, Artikel (Rechteck).
Attribut: Eigenschaft (Ellipse oder im Rechteck), Schlüssel unterstrichen.
Beziehung: Raute, mit Kardinalität (1:1, 1:n, n:m).

n:m-Beziehungen müssen beim Übergang ins relationale Modell über eine Zwischentabelle aufgelöst werden — mit den Primärschlüsseln beider Seiten als zusammengesetztem Schlüssel.

Typische Prüfungsfallen

include/extend vertauscht.
Vererbung und Assoziation verwechselt: „erbt von" gegen „hat einen Zeiger auf".
n:m nicht aufgelöst im relationalen Modell.
Diagramm mit Implementierungsdetails gefüllt: Das Use-Case-Diagramm bleibt fachlich.
Multiplizität fehlt ganz — bei Prüfungsaufgaben oft der eigentliche Bewertungspunkt.

Weiter üben

Das Grundlagenwissen steht hier frei — geübt wird in der Lernplattform: über 1.300 Prüfungsfragen mit ausführlicher Erklärung zu jeder Antwort, Fortschritt im eigenen Konto.

Zur Lernplattform Weitere Themen