UML 2.5.1 Kurzreferenz

1. Systemgrenze (System Boundary)

Element	Beschreibung
Form	Rechteck mit abgerundeten Ecken (optional)
Systemname	Oben im Rechteck, zentriert
Use Cases	INNERHALB der Systemgrenze
Akteure	AUSSERHALB der Systemgrenze

✅ Systemgrenze mit Use Cases und Akteuren

2. Akteure (Actors)

Akteurtyp	Position	Beschreibung	Beispiele
Primärakteur	LINKS	Initiiert die Interaktion, hat ein Ziel	Kunde, Benutzer, Sachbearbeiter
Sekundärakteur	RECHTS	Unterstützt das System	Datenbank, Zahlungsdienst, Bank

3. «include» - MUSS-Beziehung

Element	Beschreibung
Pfeilrichtung	Basis-UC → Include-UC (zum Eingebundenen)
Linie	GESTRICHELT
Bedeutung	Basis-UC enthält IMMER Include-UC

✅ «include» - Pfeil ZUM eingebundenen UC

4. «extend» - KANN-Beziehung

Element	Beschreibung
Pfeilrichtung	Extend-UC → Basis-UC (zum Basis-Use-Case)
Linie	GESTRICHELT
Bedeutung	Extend-UC erweitert Basis OPTIONAL
Condition	OPTIONAL - gibt an WANN erweitert wird
Extension Point	OPTIONAL - gibt an WO erweitert wird

✅ «extend» mit Notizzettel (vollständig)

✅ «extend» Kurzform mit [Condition] (prüfungstauglich!)

Kurzform: Condition direkt am Pfeil in [eckigen Klammern] – kompakter als Notizzettel, für IHK-Prüfungen empfohlen!

✅ «extend» ohne Condition (auch UML 2.5.1 konform!)

Variante	Extension Point	Condition	Empfehlung
Vollform (Notizzettel)	✅ Im Basis-UC	✅ Im Notizzettel {}	Für komplexe Fälle
Kurzform	✅ Im Basis-UC	✅ Am Pfeil []	⭐ Für IHK-Prüfungen!
Minimalform	Optional	–	Wenn Bedingung offensichtlich

Frage	→ «include»	→ «extend»
Wird es IMMER ausgeführt?	Ja, ohne Ausnahme	Nein, nur optional
Funktioniert Basis ohne?	Nein, unvollständig	Ja, vollständig nutzbar
Pfeilrichtung	Basis → Include	Extend → Basis

5. Generalisierung (Vererbung)

✅ Generalisierung - Leeres Dreieck zur Oberklasse

Leserichtung: Kunde ist ein Benutzer, Admin ist ein Benutzer

✅ Generalisierung zwischen Use Cases (spezialisierter Anwendungsfall)

Gleiches Symbol wie bei Akteuren: durchgezogene Linie + leeres Dreieck zum allgemeineren Anwendungsfall. Das IHK-Beiblatt zeigt diese Variante ausdrücklich.

1. Klassenaufbau (Drei-Kammer-Notation)

✅ Vollständige Klasse nach UML 2.5.1

Symbol	Sichtbarkeit	Zugriff
+	public	Überall
-	private	Nur Klasse selbst
#	protected	Klasse + Unterklassen
~	package	Gleiches Paket

Syntax & Eigenschaften (wie im IHK-Beiblatt)

Attribut: Sichtbarkeit Name : Typ {Eigenschaften}

Methode: Sichtbarkeit Name(param : Typ, …) : Rückgabetyp {Eigenschaften}

Eigenschaften stehen in geschweiften Klammern, z. B. {static, final}. Das IHK-Beiblatt notiert static als Property-String – also {static}, nicht unterstrichen.

Hinweis: Der strenge UML-Standard zeigt statische Merkmale unterstrichen. Für die IHK-Prüfung gilt aber die Beiblatt-Schreibweise {static}.

2. Assoziationen (UML 2.5.1)

Eine Assoziation ist eine strukturelle Beziehung zwischen Klassen.

Assoziationstyp	Darstellung	Bedeutung
Einfache Assoziation	Durchgezogene Linie ohne Pfeil	Bidirektional (beide kennen sich)
Gerichtete Assoziation	Linie mit offener Pfeilspitze >	Navigierbar nur in Pfeilrichtung
Aggregation	Linie mit leerer Raute ◇	"hat ein" - Teil existiert unabhängig
Komposition	Linie mit gefüllter Raute ◆	"besteht aus" - Teil stirbt mit Ganzem

✅ Einfache Assoziation (bidirektional)

Keine Pfeilspitze = beide Klassen kennen einander

✅ Gerichtete Assoziation (unidirektional)

Offene Pfeilspitze = Bestellung kennt Kunde, aber nicht umgekehrt

3. Aggregation vs. Komposition

✅ Aggregation ◇ (leere Raute)

"hat ein" - Mitglied existiert unabhängig

✅ Komposition ◆ (gefüllte Raute)

"besteht aus" - Position existiert nicht ohne Bestellung

KRITISCH: Raute IMMER am "Ganzen"!

Team ◇─── Mitglied | Bestellung ◆─── Position

4. Vererbung (Generalisierung)

✅ Vererbung - Leeres Dreieck △ zur Oberklasse

Kursiv = abstrakte Klasse

5. Interface & Realisierung

Ein Interface definiert einen Vertrag (nur Operationen, keine Implementierung). Eine Klasse, die das Interface umsetzt, steht über die Realisierungsbeziehung damit in Verbindung: gestrichelte Linie + leeres Dreieck zum Interface.

Element	Darstellung	Bedeutung
Interface	Klasse mit Stereotyp `«interface»` (kursiver Name)	Vertrag ohne Implementierung
Realisierung	GESTRICHELTE Linie + LEERES Dreieck △	Klasse setzt Interface um („implements“)

✅ Realisierung - gestrichelte Linie + leeres Dreieck zum Interface

Merke: Vererbung = durchgezogen + Dreieck · Realisierung = gestrichelt + Dreieck. Gleiche Spitze, andere Linie!

Begriff im IHK-Beiblatt: „Implementierung"

Das offizielle IHK-Beiblatt beschriftet diese Beziehung mit „Implementierung" (Klasse → «interface»). Gemeint ist dasselbe wie die hier gezeigte Realisierung – beide Begriffe sind UML-konform und austauschbar.

6. Abhängigkeit (Dependency)

Hinweis: Die Abhängigkeit steht nicht auf dem IHK-Beiblatt – sie ist also nicht als Vorlage vorgegeben. Sie ist trotzdem gültiges UML und kann im Aufgabentext verlangt sein, daher hier zur Vollständigkeit.

Eine Abhängigkeit ist die schwächste Beziehung: Klasse A benutzt Klasse B nur vorübergehend – z. B. als Methodenparameter, lokale Variable oder Rückgabetyp. Es gibt kein dauerhaftes Attribut.

Element	Darstellung	Bedeutung
Linie	GESTRICHELT	Lose, temporäre Nutzung
Pfeilspitze	OFFEN > (zum Benutzten)	A hängt von B ab
Typische Auslöser	Parameter, lokale Variable, Rückgabewert	„uses“ statt „has“

✅ Abhängigkeit - gestrichelte Linie + OFFENE Pfeilspitze

Abgrenzung: Wird B dauerhaft als Attribut gehalten → Assoziation/Aggregation. Wird B nur kurz benutzt (Parameter/lokal) → Abhängigkeit.

7. Multiplizitäten

Notation	Bedeutung	Beispiel
1	Genau eins	Auto hat 1 Motor
0..1	Optional	Person hat 0..1 Ehepartner
* oder 0..*	Beliebig viele	Kunde hat * Bestellungen
1..*	Mindestens eins	Bestellung hat 1..* Positionen

8. Vollständiges Klassendiagramm-Beispiel

✅ Online-Shop mit verschiedenen Beziehungstypen

Legende: ── Assoziation | ◆─ Komposition | ─> Gerichtete Assoziation

1. Grundelemente

Element	Darstellung	Beschreibung
Objekt/Lebenslinie	Rechteck + gestrichelte Linie	:Klassenname oder objekt:Klasse
Aktivierungsbalken	Schmales Rechteck auf Lebenslinie	Objekt führt gerade Code aus
Nachricht	Horizontaler Pfeil	Methodenaufruf

2. Nachrichtentypen (UML 2.5.1)

Typ	Linie	Pfeilspitze	Bedeutung
Synchron	Durchgezogen	GEFÜLLT ▶	Sender wartet auf Antwort
Asynchron	Durchgezogen	OFFEN >	Sender wartet NICHT
Rückgabe	GESTRICHELT	OFFEN >	Antwort auf synchronen Aufruf

✅ Synchrone Nachricht - GEFÜLLTE Spitze

✅ Rückgabe - GESTRICHELT + offene Spitze

✅ Asynchrone Nachricht - durchgezogen + OFFENE Spitze

Unterschied zur synchronen: gleiche durchgezogene Linie, aber offene statt gefüllter Spitze. Der Sender wartet nicht auf eine Antwort.

3. Selbstaufruf, Objekt-Konstruktion & -Destruktion

Diese drei Elemente stehen ausdrücklich auf dem IHK-Beiblatt und tauchen regelmäßig in AP2-Sequenzdiagrammen auf.

✅ Selbstaufruf (reflexive Nachricht)

Pfeil vom Objekt zu sich selbst – das Objekt ruft eine eigene Methode auf.

✅ Objekt-Konstruktion (create) & Destruktion (X)

create = gestrichelter Pfeil auf den Objekt-Kopf (Objekt entsteht hier). X = Lebenslinie endet, Objekt wird zerstört.

4. Kombinierte Fragmente

Fragment	Bedeutung	Verwendung
alt	Alternative	if-else (mit [guards])
opt	Optional	if ohne else
loop	Schleife	while/for [min,max]
par	Parallel	Gleichzeitige Ausführung
break	Abbruch	Vorzeitiger Ausstieg

5. Vollständiges Sequenzdiagramm-Beispiel

✅ Login-Prozess mit alt-Fragment

Legende: ▶ Synchrone Nachricht | - - -> Rückgabe | alt = if-else mit [Guards]

1. Grundelemente

Element	Symbol	Beschreibung
Startknoten	● (gefüllter Kreis)	Beginn des Ablaufs
Endknoten	◉ (Kreis mit Punkt)	Beendet alle Aktivitäten
Ablaufende (Flow Final)	⊗ (Kreis mit X)	Beendet nur den aktuellen Fluss, andere Pfade laufen weiter
Aktivität	Abgerundetes Rechteck	Auszuführende Aktion
Entscheidung (Decision)	◇ Raute (1 rein, n raus)	Verzweigung mit [Guards]
Zusammenführung (Oder) (Merge)	◇ Raute (n rein, 1 raus)	Alternative Pfade zusammenführen
Teilung (Splitting) (Fork)	▬ Balken (1 rein, n raus)	Parallele Pfade starten
Synchronisation (Und) (Join)	▬ Balken (n rein, 1 raus)	Parallele Pfade synchronisieren

Verzweigung	Zusammenführung	Bedeutung
◇ Entscheidung (Decision)	◇ Merge (Raute!)	ENTWEDER-ODER Pfade
▬ Fork (Balken)	▬ Join (Balken!)	UND Pfade (parallel)

2. Entscheidung + Merge (Alternative Pfade)

✅ Entscheidung (◇) wird mit Merge (◇) zusammengeführt

3. Fork + Join (Parallele Pfade)

✅ Fork (▬) wird mit Join (▬) synchronisiert

Join wartet auf ALLE parallelen Pfade!

4. Schwimmbahnen (Partitionen / Verantwortungsbereiche)

Schwimmbahnen (engl. Swimlanes, UML-Begriff: Partitionen) teilen das Diagramm in Spalten (oder Zeilen) auf und ordnen jede Aktivität einem Verantwortlichen zu – Person, Rolle, Abteilung oder System. So wird sichtbar, wer was macht. Im IHK-Beiblatt heißen sie „Schwimmbahn 1 / Schwimmbahn 2".

Warum prüfungsrelevant?

Sobald eine AP2-Aufgabe Formulierungen wie „der Kunde …“, „das System …“, „der Sachbearbeiter …“ mischt, erwartet der Erwartungshorizont meist ein Aktivitätsdiagramm mit Swimlanes. Jede Aktivität gehört eindeutig in genau eine Lane.

✅ Bestellprozess mit drei Partitionen (Kunde | System | Lager)

Regel: Eine Aktivität liegt in der Lane, deren Verantwortlicher sie ausführt. Eine Transition, die die Lane wechselt, bedeutet eine Zuständigkeits-Übergabe.

Typische Fehler bei Swimlanes

Fehler	Richtig
Aktivität auf einer Lane-Grenze platziert	Eindeutig in einer Lane
Start-/Endknoten vergessen einzuordnen	Auch sie liegen in einer Lane
Decision-Raute über mehrere Lanes gezogen	Raute gehört zu der Lane, die entscheidet

1. Zustände

Element	Darstellung	Beschreibung
Einfacher Zustand	Abgerundetes Rechteck	Zustand ohne interne Aktionen
Zustand mit Aktionen	Zweigeteilt: Name \| entry/do/exit	Zustand mit internen Aktionen
Startzustand	● (gefüllter Kreis)	Initialer Zustand
Endzustand	◉ (Kreis mit Punkt)	Finaler Zustand

2. Interne Aktionen

Aktion	Wann?	Beispiel
entry /	Beim Betreten	entry / lampeAn()
do /	Während (unterbrechbar)	do / blinken()
exit /	Beim Verlassen	exit / lampeAus()
ereignis /	Bei internem Ereignis (ohne Zustandswechsel)	tasteGedrückt / zähleHoch()

Das IHK-Beiblatt listet im Zustandskörper genau diese vier Zeilen: entry/aktion, do/aktion, exit/aktion, ereignis/aktion.

✅ Zustand mit internen Aktionen

3. Übergänge (Transitionen)

✅ Übergangsnotation: Ereignis [Guard] / Aktion

Format: Ereignis [Guard] / Aktion - alle Teile sind optional!

Im IHK-Beiblatt steht dieselbe Notation als operation[bedingung]/verhalten – nur andere Wörter, gleiche Struktur.

Zeitauslöser: `after(Zeitdauer)`

Ein Übergang kann auch durch Zeitablauf ausgelöst werden. Statt eines Ereignisses steht dann after(Zeitdauer) an der Transition – z. B. after(30s) für „nach 30 Sekunden automatisch wechseln". Das IHK-Beiblatt zeigt diesen Auslöser ausdrücklich.

4. Vollständiges Zustandsdiagramm-Beispiel

✅ Bestellung-Lebenszyklus

Legende: ● Start | ◉ Ende | Transitionen: ereignis [guard] / aktion

5. Pseudozustände: Choice & Junction (Legacy)

📜 Historischer Hintergrund

In UML 1.x (1997-2005) wurden Rauten häufig für Verzweigungen in Zustandsdiagrammen verwendet – ähnlich wie in Aktivitätsdiagrammen. Seit UML 2.0 werden Guards bevorzugt direkt an Transitionen geschrieben.

Ältere IHK-Materialien und Prüfungen könnten noch die Rauten-Notation verwenden!

Symbol	Name	UML-Version	Bedeutung
◇	Choice	UML 2.x	Dynamische Entscheidung (Guard zur Laufzeit ausgewertet)
◇	Junction	UML 1.x/2.x	Statische Verzweigung / Zusammenführung

UML 1.x Stil (mit Raute) – noch in älteren Prüfungen zu finden

✅ UML 2.x Stil (Guards direkt an Transition) – EMPFOHLEN

Vorteil: Kompakter, keine Extra-Symbole nötig

Prüfungstipp:

Wenn du in einer Prüfung eine Raute im Zustandsdiagramm siehst → es ist eine Choice/Junction aus UML 1.x-Zeiten.

Für eigene Diagramme: Verwende besser Guards direkt an der Transition – das ist der moderne UML 2.x Standard.

Diagramm	Element	Linie	Spitze
Use-Case	Assoziation	Durchgezogen	KEINE
	«include»	Gestrichelt	OFFEN >
	«extend»	Gestrichelt	OFFEN >
	Generalisierung	Durchgezogen	LEERES △
Klasse	Assoziation	Durchgezogen	KEINE (bidirektional)
	Gerichtete Assoziation	Durchgezogen	OFFEN > (navigierbar)
	Vererbung	Durchgezogen	LEERES △
	Realisierung	Gestrichelt	LEERES △
	Abhängigkeit	Gestrichelt	OFFEN >
	Aggreg./Komp.	Durchgezogen	◇/◆ am Ganzen
Sequenz	Synchron	Durchgezogen	GEFÜLLT ▶
	Asynchron	Durchgezogen	OFFEN >
	Rückgabe	Gestrichelt	OFFEN >
Aktivität	Kontrollfluss	Durchgezogen	OFFEN >
Zustand	Transition	Durchgezogen	OFFEN >

Use-Case-Diagramm

1. Systemgrenze (System Boundary)

2. Akteure (Actors)

3. «include» - MUSS-Beziehung

4. «extend» - KANN-Beziehung

«extend» Notation - Drei gültige Varianten:

Include vs. Extend - Entscheidungshilfe

5. Generalisierung (Vererbung)

Klassendiagramm

1. Klassenaufbau (Drei-Kammer-Notation)

Syntax & Eigenschaften (wie im IHK-Beiblatt)

2. Assoziationen (UML 2.5.1)

3. Aggregation vs. Komposition

KRITISCH: Raute IMMER am "Ganzen"!

4. Vererbung (Generalisierung)

5. Interface & Realisierung

Begriff im IHK-Beiblatt: „Implementierung"

6. Abhängigkeit (Dependency)

7. Multiplizitäten

8. Vollständiges Klassendiagramm-Beispiel

Sequenzdiagramm

1. Grundelemente

2. Nachrichtentypen (UML 2.5.1)

3. Selbstaufruf, Objekt-Konstruktion & -Destruktion

4. Kombinierte Fragmente

5. Vollständiges Sequenzdiagramm-Beispiel

Aktivitätsdiagramm

1. Grundelemente

KRITISCH: Richtige Zusammenführung!

2. Entscheidung + Merge (Alternative Pfade)

3. Fork + Join (Parallele Pfade)

4. Schwimmbahnen (Partitionen / Verantwortungsbereiche)

Warum prüfungsrelevant?

Typische Fehler bei Swimlanes

Zustandsdiagramm

1. Zustände

2. Interne Aktionen

3. Übergänge (Transitionen)

Zeitauslöser: after(Zeitdauer)

4. Vollständiges Zustandsdiagramm-Beispiel

5. Pseudozustände: Choice & Junction (Legacy)

📜 Historischer Hintergrund

Prüfungstipp:

Schnellreferenz - Pfeilspitzen

UML 2.5.1 Referenz

Zeitauslöser: `after(Zeitdauer)`