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!)

«extend» Notation - Drei gültige Varianten:

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

Include vs. Extend - Entscheidungshilfe

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

Klassendiagramm

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

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. 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

6. Vollständiges Klassendiagramm-Beispiel

✅ Online-Shop mit verschiedenen Beziehungstypen

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

Sequenzdiagramm

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

3. 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

4. Vollständiges Sequenzdiagramm-Beispiel

✅ Login-Prozess mit alt-Fragment

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

Aktivitätsdiagramm

1. Grundelemente

Element	Symbol	Beschreibung
Startknoten	● (gefüllter Kreis)	Beginn des Ablaufs
Endknoten	◉ (Kreis mit Punkt)	Ende des Ablaufs
Aktivität	Abgerundetes Rechteck	Auszuführende Aktion
Entscheidung (Decision)	◇ Raute (1 rein, n raus)	Verzweigung mit [Guards]
Zusammenführung (Merge)	◇ Raute (n rein, 1 raus)	Alternative Pfade zusammenführen
Aufspaltung (Fork)	▬ Balken (1 rein, n raus)	Parallele Pfade starten
Synchronisation (Join)	▬ Balken (n rein, 1 raus)	Parallele Pfade synchronisieren

KRITISCH: Richtige Zusammenführung!

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

Merkregel: Raute → Raute | Balken → Balken

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!

Zustandsdiagramm

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()

✅ Zustand mit internen Aktionen

3. Übergänge (Transitionen)

✅ Übergangsnotation: Ereignis [Guard] / Aktion

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

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.

Schnellreferenz - Pfeilspitzen

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 △
	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 >

UML 2.5.1 Referenz

Diese Kurzreferenz basiert auf dem offiziellen UML 2.5.1 Standard (OMG Document formal/2017-12-05).

Quelle: https://www.omg.org/spec/UML/2.5.1

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)

2. Assoziationen (UML 2.5.1)

3. Aggregation vs. Komposition

KRITISCH: Raute IMMER am "Ganzen"!

4. Vererbung (Generalisierung)

5. Multiplizitäten

6. Vollständiges Klassendiagramm-Beispiel

Sequenzdiagramm

1. Grundelemente

2. Nachrichtentypen (UML 2.5.1)

3. Kombinierte Fragmente

4. Vollständiges Sequenzdiagramm-Beispiel

Aktivitätsdiagramm

1. Grundelemente

KRITISCH: Richtige Zusammenführung!

2. Entscheidung + Merge (Alternative Pfade)

3. Fork + Join (Parallele Pfade)

Zustandsdiagramm

1. Zustände

2. Interne Aktionen

3. Übergänge (Transitionen)

4. Vollständiges Zustandsdiagramm-Beispiel

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

📜 Historischer Hintergrund

Prüfungstipp:

Schnellreferenz - Pfeilspitzen

UML 2.5.1 Referenz