UML teilt sich in Strukturdiagramme (statische Sicht auf ein System) und Verhaltensdiagramme (dynamische Abläufe). Für die Prüfung sind fünf Diagrammtypen besonders relevant.

1. Klassendiagramm (Strukturdiagramm)

Das Klassendiagramm bildet die statische Struktur eines Systems ab. Es zeigt Klassen mit ihren Attributen und Methoden sowie die Beziehungen zwischen den Klassen.

Aufbau einer Klasse: Eine Klasse wird als Rechteck mit drei Bereichen dargestellt: Klassenname oben, Attribute in der Mitte, Methoden unten.

Die Zugriffsmodifikatoren werden durch Symbole gekennzeichnet:

• + = public (öffentlich)
• – = private (privat)
• # = protected (geschützt)
• ~ = package (paketweit)

Beziehungstypen:

 

Multiplizitäten: Multiplizitäten stehen an den Enden einer Beziehungslinie und beschreiben, wie viele Objekte einer Klasse mit wie vielen Objekten der anderen Klasse in Beziehung stehen.

 

Prüfungsbeispiel: Ein Online-Shop verwaltet Kunden, Bestellungen und Artikel. Jeder Kunde kann mehrere Bestellungen aufgeben. Jede Bestellung enthält mindestens einen Artikel. Ein Artikel kann in mehreren Bestellungen vorkommen.

Die Beziehung zwischen Bestellung und Position ist eine Komposition (gefüllte Raute): Wird die Bestellung gelöscht, verschwinden auch die Positionen. Die Beziehung zwischen Position und Artikel ist eine Assoziation: Ein Artikel existiert unabhängig von einer einzelnen Bestellung.

2. Anwendungsfalldiagramm (Use-Case-Diagramm)

Das Use-Case-Diagramm zeigt, welche Akteure mit welchen Funktionen eines Systems arbeiten. Damit startet in der Regel jede Modellierung.

Elemente:

• Akteur: Strichmännchen, steht außerhalb des Systems
• Anwendungsfall: Ellipse mit Beschreibung, liegt innerhalb der Systemgrenze
• Systemgrenze: Rechteck, das alle Anwendungsfälle umschließt
• Beziehungen: Linien zwischen Akteuren und Anwendungsfällen, <<include>> und <<extend>> zwischen Anwendungsfällen

include vs. extend:

• <<include>>: Der eingeschlossene Anwendungsfall wird immer ausgeführt. Beispiel: „Bestellung aufgeben“ schließt „Warenkorb prüfen“ ein.
• <<extend>>: Der erweiterte Anwendungsfall wird nur unter bestimmten Bedingungen ausgeführt. Beispiel: „Bestellung aufgeben“ kann durch „Gutschein einlösen“ erweitert werden.

Prüfungsbeispiel: Ein Bibliothekssystem hat zwei Akteure: Bibliotheksnutzer und Bibliothekar. Der Nutzer kann Bücher suchen, Bücher ausleihen und seinen Kontostand einsehen. Der Bibliothekar kann zusätzlich Bücher erfassen und Mahnungen versenden. Das Ausleihen eines Buches schließt immer die Prüfung der Verfügbarkeit ein (<<include>>). Die Ausleihe kann optional durch eine Vormerkung erweitert werden (<<extend>>).

3. Sequenzdiagramm

Das Sequenzdiagramm zeigt den zeitlichen Ablauf von Nachrichten zwischen Objekten. Die vertikale Achse ist die Zeitachse, horizontal stehen die beteiligten Objekte.

Elemente:

• Lebenslinie: Gestrichelte vertikale Linie unter jedem Objekt
• Aktivierungsbalken: Dünnes Rechteck auf der Lebenslinie, zeigt aktive Verarbeitung
• Synchrone Nachricht: Durchgezogener Pfeil mit geschlossener Spitze (der Sender wartet auf Antwort)
• Asynchrone Nachricht: Durchgezogener Pfeil mit offener Spitze (der Sender wartet nicht)
• Antwortnachricht: Gestrichelter Pfeil
• Kombinierte Fragmente: Rahmen für Schleifen (loop), Bedingungen (alt, opt) und parallele Abläufe (par)

Prüfungsbeispiel (Login-Vorgang): Ein Benutzer sendet login(user, pw) an den LoginController. Dieser fragt findUser(user) bei der Datenbank an und erhält userData zurück. In einem alt-Fragment wird bei korrektem Passwort „Erfolg“ zurückgemeldet, andernfalls „Fehler“.

Für FISI-Azubis: In der Prüfung können Sequenzdiagramme für Netzwerkprotokolle drankommen. Ein Beispiel ist der DHCP-DORA-Prozess (Discover, Offer, Request, Acknowledge), bei dem Client und DHCP-Server die vier Nachrichten austauschen.

4. Aktivitätsdiagramm

Das Aktivitätsdiagramm modelliert Abläufe und Workflows. Es ist der Nachfolger des klassischen Flussdiagramms, bietet aber mehr Möglichkeiten wie parallele Abläufe und Swimlanes.

Elemente

Prüfungsbeispiel (Bestellprozess): Start → Bestellung aufgeben → Entscheidung (Lagerbestand?) → bei vorrätig: Ware kommissionieren, bei nicht vorrätig: Nachbestellung → Rechnung erstellen → Fork (parallele Pfade: Ware versenden + Rechnung versenden) → Join → Ende.

Der Fork-Balken teilt den Ablauf in zwei parallele Pfade: Ware versenden und Rechnung versenden laufen gleichzeitig. Der Join-Balken synchronisiert sie wieder.

5. Zustandsdiagramm

Das Zustandsdiagramm beschreibt die möglichen Zustände eines Objekts und die Übergänge (Transitionen) zwischen diesen Zuständen.

Elemente:

• Zustand: Abgerundetes Rechteck mit Zustandsname
• Startzustand: Ausgefüllter Kreis
• Endzustand: Ausgefüllter Kreis mit Ring
• Transition: Pfeil zwischen Zuständen, beschriftet mit Ereignis [Bedingung] / Aktion

Prüfungsbeispiel (Zustand einer Bestellung): Startzustand → Neu → (bestellung_bestätigt) → In Bearbeitung → (ware_versendet) → Versendet → (zugestellt) → Abgeschlossen → Endzustand. Alternativ: Versendet → (retourniert) → Retourniert → (erstattet) → Storniert → Endzustand.

Jeder Pfeil trägt das Ereignis, das den Übergang auslöst. Optional können Bedingungen in eckigen Klammern und Aktionen nach einem Schrägstrich ergänzt werden.

Beispiel für eine vollständige Transition: zahlung_eingegangen [Betrag >= Rechnungsbetrag] / Versand_auslösen

Die IHK fragt UML in unterschiedlichen Formaten ab. Drei Varianten kommen regelmäßig vor:

Lückendiagramm vervollständigen: Ein Diagramm ist vorgegeben, aber unvollständig. Fehlende Klassen, Beziehungen, Multiplizitäten oder Zustände müssen ergänzt werden. Das ist das häufigste Format.

Diagramm aus Fließtext erstellen: Ein Szenario wird als Text beschrieben. Daraus soll ein UML-Diagramm erstellt werden. Hier kommt es auf saubere Notation an, nicht auf künstlerische Darstellung.

Diagramm interpretieren: Ein fertiges Diagramm wird gezeigt. Dazu kommen Verständnisfragen: Welche Beziehung besteht zwischen X und Y? Was passiert, wenn Zustand Z eintritt?

Multiplizitäten vergessen oder falsch setzen. Jede Assoziation in einem Klassendiagramm braucht Multiplizitäten an beiden Enden. Ohne sie ist das Diagramm unvollständig.

Aggregation und Komposition verwechseln. Die Faustregel: Kann das Teil ohne das Ganze existieren? Ja → Aggregation (leere Raute). Nein → Komposition (gefüllte Raute). Ein Raum existiert nicht ohne ein Gebäude (Komposition). Ein Mitarbeiter existiert auch ohne eine Abteilung (Aggregation).

include und extend vertauschen. Include ist verpflichtend, extend ist optional. Wer unsicher ist, fragt sich: Wird der eingebundene Anwendungsfall immer ausgeführt? Dann include.

Notation nicht sauber. In der Prüfung auf Papier zeichnen bedeutet: Pfeile korrekt, Rauten geschlossen, Dreiecke richtig ausgerichtet. Prüfer werten Notation streng.

Synchrone und asynchrone Nachrichten verwechseln. Geschlossene Pfeilspitze = synchron (Sender wartet). Offene Pfeilspitze = asynchron (Sender wartet nicht).

Drei Schritte, die funktionieren:

1. Notation auswendig lernen. Jedes Diagramm hat feste Symbole. Wer die Symbole nicht kennt, kann die Aufgabe nicht lösen, egal wie gut das Verständnis ist.
2. Auf Papier üben. In der Prüfung wird mit Stift gezeichnet, nicht am Bildschirm. Das Zeichnen auf Papier trainiert die saubere Darstellung und zeigt schnell, wo Unsicherheiten liegen.
3. Alte Prüfungsaufgaben durcharbeiten. Die IHK-Aufgabenstile wiederholen sich. Wer drei bis vier alte Prüfungen durchgearbeitet hat, kennt die Muster.

Die Grundregel: Klassendiagramm und Use-Case-Diagramm sicher beherrschen, Sequenz- und Aktivitätsdiagramm verstehen und zeichnen können, Zustandsdiagramme zumindest lesen und interpretieren können.

Wer sich gezielt auf diese fünf Diagrammtypen vorbereitet und die Notation sauber beherrscht, ist für den UML-Teil der Prüfung gut aufgestellt.

In unserer Prüfungsvorbereitung für Fachinformatiker Anwendungsentwicklung und Fachinformatiker Systemintegration gehen wir intensiv auf dieses und viele weitere prüfungsrelevante Themen ein und bereiten dich so optimal auf die AP1 und die AP2 vor.

Du hast Fragen? Dann melde dich gerne bei uns!