Aktivitätsdiagramm: Kursanmeldung bearbeiten

Übersicht Use Case Klassen Sequenz Aktivität Zustand

Szenario

Ein Teilnehmer möchte sich zu einem Kurs anmelden. Das System prüft Login, freie Plätze und ob Voraussetzungen erfüllt sind. Bei kostenpflichtigen Zusatzkursen muss die Zahlung erfolgreich sein. Danach wird die Einschreibung gespeichert und eine Bestätigung versendet. Wenn eine Prüfung fehlschlägt, endet der Ablauf mit einer passenden Meldung.

Lernziel: Du modellierst einen Geschäftsprozess mit Aktionen, Entscheidungen und Bedingungen so, dass der Ablauf auch bei Varianten nachvollziehbar bleibt.

Zeit & Ergebnis

0–5 Min.

Szenario lesen, Fachbegriffe markieren, Annahmen notieren.

5–15 Min.

Bausteine auswählen und Struktur planen.

15–35 Min.

Diagramm im Codefeld erstellen und Vorschau prüfen.

35–45 Min.

Selbstcheck, Begründung, Korrekturen.

Abzugeben

Mindestens 8 Aktionen/Knoten.
Mindestens 3 Entscheidungen mit Guards.
Mindestens 1 optionaler Zahlungszweig.

So sehen die Bausteine aus

Aktion
Abgerundetes Rechteck für einen Arbeitsschritt.

Entscheidung
Raute mit Guards wie [ja] und [nein].

Start/Ende
Schwarzer Startpunkt und finaler Endknoten.

Wichtig: Das Codefeld unten ist kein PlantUML-Renderer, sondern ein bewusst einfacher Lern-Baukasten. Jede Änderung im Codefeld aktualisiert die Vorschau direkt auf dieser Seite.

Diagramm-Baukasten zum Einfügen

Klicke auf einen Baustein. Der passende Code wird an der Cursorposition eingefügt und die Vorschau wird aktualisiert.

StartAktionEntscheidungFlow mit GuardFehleraktionEndeFork/Join

Variablen und Regeln

Variablen

Login: gültig oder ungültig.
Plätze: frei oder ausgebucht.
Voraussetzungen: erfüllt oder nicht erfüllt.
Kursart: kostenlos oder kostenpflichtig.

Regeln

Jeder Entscheidungsabgang braucht einen Guard, z. B. [ja].
Aktionen sind Tätigkeiten, keine Zustände.
Fehlerfälle sollten nicht im Nirgendwo enden.
Parallelität nur verwenden, wenn Aktionen unabhängig gleichzeitig laufen können.

Arbeitsauftrag

Liste alle Prozessschritte in natürlicher Reihenfolge.
Setze Entscheidungen dort, wo Regeln geprüft werden.
Beschrifte alle Abgänge mit Guards.
Führe erfolgreiche und fehlerhafte Pfade zu sinnvollen Enden.
Prüfe, ob der Zahlungszweig nur bedingt ausgeführt wird.

Mini-Syntax

start S "Start" action A1 "Login prüfen" decision D1 "Login gültig?" flow S -> A1 flow A1 -> D1 flow D1 -> A2 : [ja] end E "Ende"

Interaktive Arbeitsfläche

Live-Vorschau

ändert sich beim Tippen

Selbstcheck

Jeder Entscheidungsabgang hat einen Guard. Erfolgs- und Fehlerpfade enden sauber. Aktionen sind aktiv formuliert. Zahlung ist nur bedingt Teil des Ablaufs. Keine fachlich wichtigen Prüfungen fehlen.

Diagramm-Code / Baustein-Liste

start S "Start"
action A1 "Login prüfen"
decision D1 "Login gültig?"
action A2 "Kursdaten laden"
decision D2 "Freie Plätze?"
action A3 "Voraussetzungen prüfen"
decision D3 "Voraussetzungen erfüllt?"
decision D4 "Kostenpflichtiger Kurs?"
action A4 "Zahlung durchführen"
decision D5 "Zahlung erfolgreich?"
action A5 "Einschreibung speichern"
action A6 "Bestätigung senden"
action F1 "Fehlermeldung anzeigen"
end E "Ende"
flow S -> A1
flow A1 -> D1
flow D1 -> A2 : [ja]
flow D1 -> F1 : [nein]
flow A2 -> D2
flow D2 -> A3 : [ja]
flow D2 -> F1 : [nein]
flow A3 -> D3
flow D3 -> D4 : [ja]
flow D3 -> F1 : [nein]
flow D4 -> A4 : [ja]
flow D4 -> A5 : [nein]
flow A4 -> D5
flow D5 -> A5 : [ja]
flow D5 -> F1 : [nein]
flow A5 -> A6
flow A6 -> E
flow F1 -> E

Begründung: Regeln, Variablen, Entscheidungen

Skizzenfläche für Ausdruck

Hier kannst du im Ausdruck eine saubere finale Zeichnung ergänzen oder die Live-Vorschau als Vorlage nutzen.

Bewertungsraster

Kriterium	Erwartung	Punkte
Vollständigkeit	Alle geforderten Bausteine sind vorhanden und passen zum Szenario.	10
UML-Korrektheit	Notation, Richtung, Beziehungen und Sonderfälle sind nachvollziehbar.	10
Fachliche Modellierung	Das Diagramm abstrahiert sinnvoll und vermeidet zu technische Einzelschritte.	10
Begründung	Variablen, Regeln und Modellierungsentscheidungen werden verständlich erklärt.	5