Die Elemente
Ein Aktivitätsdiagramm (activity diagram) beschreibt eine Aktivität, also einen Ablauf von Anfang bis Ende. Stell dir eine Spielfigur vor, die vom Startknoten aus den Pfeilen folgt: UML nennt sie Token. Wo sie gerade steht, passiert etwas. Mit diesem Bild lassen sich alle Elemente erklären.
- Startknoten (initial node): gefüllter Kreis. Hier beginnt der Ablauf.
- Aktion (action): abgerundetes Rechteck mit einem Verb, etwa „Ticket erfassen“. Eine Aktion ist ein Schritt, der nicht weiter zerlegt wird.
- Kontrollfluss (control flow): Pfeil mit offener Spitze von einem Knoten zum nächsten.
- Aktivitätsende (activity final node): Kreis mit gefülltem Punkt. Sobald ein Token hier ankommt, endet die gesamte Aktivität, auch alle parallelen Zweige. Das Ablaufende (flow final node, Kreis mit Kreuz) beendet dagegen nur den einen Zweig, der dort ankommt.
Entscheidung und Zusammenführung
Die leere Raute ist als Entscheidung (decision node) ein Weichensteller: Ein Pfeil geht hinein, mehrere gehen heraus, und an jedem ausgehenden Pfeil steht eine Bedingung (guard) in eckigen Klammern, etwa [hoch] und [niedrig]. Die Bedingungen müssen sich gegenseitig ausschließen und zusammen alle Fälle abdecken; für „alles andere“ gibt es [else]. Ein Fragetext neben der Raute, etwa „Rad frei?“, ist verbreitet und schadet nicht; entscheidend sind die Wächter in eckigen Klammern an jedem Ausgang.
Dieselbe Raute mit mehreren Eingängen und einem Ausgang ist eine Zusammenführung (merge node). Sie führt die Zweige wieder zusammen, ohne zu warten: Jedes ankommende Token läuft sofort weiter. Auch jede Schleife braucht eine Zusammenführung, denn der Rückweg mündet nicht direkt in eine Aktion, sondern in eine Raute davor.
Gabelung und Vereinigung
Der schwarze Balken ist als Gabelung (fork node) der Startschuss für Parallelität: Ein Token kommt an, auf jedem ausgehenden Pfeil läuft eines weiter. Der Balken als Vereinigung (join node) wartet, bis alle parallelen Zweige angekommen sind, und lässt erst dann ein Token weiter. „Parallel“ heißt dabei nicht zwingend gleichzeitig, sondern: Die Reihenfolge ist egal.
Zwei Symbole solltest du erkennen, aber nicht zeichnen müssen: das Zeitereignis (Sanduhr, etwa „nach 14 Tagen“) und der Signalempfang (Rechteck mit eingekerbter Seite, etwa „Zahlung eingegangen“). Beide lösen einen Kontrollfluss von außen aus.
Schwimmbahnen und Objektfluss
Schwimmbahnen
Sobald mehrere Beteiligte am Ablauf mitwirken, teilst du das Diagramm in Schwimmbahnen (swimlanes), in UML 2.5 offiziell Partitionen (activity partitions). Jede Bahn trägt oben den Namen einer Rolle, Abteilung oder eines Systems, und jede Aktion liegt in der Bahn dessen, der sie ausführt. Pfeile dürfen die Bahnen frei kreuzen; genau dort sieht man, wo eine Aufgabe übergeben wird.
Objektfluss
Manchmal ist wichtig, was zwischen zwei Aktionen weitergereicht wird. Dann setzt du einen Objektknoten (object node) dazwischen: ein eckiges Rechteck mit dem Namen des Objekts, optional mit seinem Zustand in eckigen Klammern. Die Pfeile davor und danach heißen Objektfluss (object flow). In Prüfungen kommt das selten vor, erkennen solltest du es aber.
Abgrenzung zu PAP und Struktogramm
Die IHK fragt Abläufe in drei Notationen ab: als UML-Aktivitätsdiagramm, als Programmablaufplan (PAP) und als Struktogramm. Alle drei zeigen Reihenfolge und Verzweigung, aber mit unterschiedlichen Symbolen. Hier dieselbe kleine Logik in allen drei Formen:
| Merkmal | Aktivitätsdiagramm | PAP | Struktogramm |
|---|---|---|---|
| Norm | UML 2.5 (OMG) | DIN 66001 | DIN 66261, auch Nassi-Shneiderman-Diagramm |
| Start und Ende | gefüllter Kreis, Kreis mit Punkt | Oval (Terminator) mit „Start“ und „Ende“ | keine eigenen Symbole |
| Anweisung | Aktion, abgerundetes Rechteck | Rechteck; Ein- und Ausgabe als Parallelogramm | Rechteckiger Block |
| Verzweigung | leere Raute, Bedingungen [ … ] an den Kanten | Raute mit Frage, Ausgänge „ja“ und „nein“ | Block mit Dreieck, Spalten „ja“ und „nein“ |
| Schleife | Rückfluss in eine Zusammenführung | Rückpfeil vor die Entscheidung | eigener Schleifenblock, kopf- oder fußgesteuert |
| Parallelität | Gabelung und Vereinigung | in Prüfungen praktisch nie | in Prüfungen praktisch nie |
| Wer macht was | Schwimmbahnen | nicht vorgesehen | nicht vorgesehen |
| Typischer Einsatz | Geschäftsprozesse und Systemabläufe mit mehreren Beteiligten | Programmlogik, nah am Code | Programmlogik ohne Sprünge, strukturierte Programmierung |
Beispiel Schritt für Schritt: Störungsticket
So sieht eine typische Prüfungsaufgabe aus. Lies den Text einmal ganz, dann gehst du in drei Schritten vor.
Der IT-Support eines Systemhauses bearbeitet Störungsmeldungen. Geht eine Meldung ein, erfasst der Support ein Ticket und prüft dessen Priorität. Tickets mit niedriger Priorität werden zunächst in die Warteschlange eingereiht, Tickets mit hoher Priorität gehen sofort in die Bearbeitung. Danach geschieht zweierlei, in beliebiger Reihenfolge: Der Support informiert den Kunden über den Stand, und die Technik behebt die Störung und dokumentiert die Lösung. Erst wenn beides erledigt ist, schließt der Support das Ticket.
Aufgabe: Stellen Sie den Ablauf als UML-Aktivitätsdiagramm mit Schwimmbahnen dar.
Schritt 1: Aktionen und Beteiligte sammeln
Die markierten Verben werden zu Aktionen, jeweils mit Objekt und Verb: Ticket erfassen, Priorität prüfen, In Warteschlange einreihen, Kunde informieren, Störung beheben, Lösung dokumentieren, Ticket schließen. Die markierten Beteiligten werden zu Schwimmbahnen: Support und Technik. Der Kunde handelt im Text selbst nicht, er bekommt keine eigene Bahn.
Schritt 2: Reihenfolge, Entscheidung und Parallelität
Jetzt ordnest du die Aktionen. „Tickets mit niedriger Priorität …, Tickets mit hoher Priorität …“ ist eine Entscheidung mit den Bedingungen [niedrig] und [hoch]; der Weg für hoch führt ohne eigene Aktion direkt zur Zusammenführung. „In beliebiger Reihenfolge“ und „erst wenn beides erledigt ist“ sind die Signalwörter für Gabelung und Vereinigung.
Schritt 3: Schwimmbahnen einziehen
Zum Schluss legst du die Bahnen Support und Technik an und schiebst jede Aktion in die Bahn dessen, der sie ausführt. Gabelung und Vereinigung reichen über beide Bahnen, weil die parallelen Zweige bei verschiedenen Beteiligten liegen.
Zeichenaufgaben
Zeichne erst selbst, dann klapp die Musterlösung auf und vergleiche Punkt für Punkt. Die Punkte sind Richtwerte im Stil der IHK; die tatsächliche Verteilung legt jede Prüfung selbst fest.
Ein Kunde sendet im Onlineshop eine Bestellung ab. Der Shop prüft daraufhin die Zahlung. Wird sie abgelehnt, ändert der Kunde die Zahlungsart und der Shop prüft erneut. Wird sie bestätigt, sendet der Shop die Rechnung per E-Mail, während das Lager gleichzeitig die Ware verpackt und versendet. Sind Rechnung und Versand erledigt, schließt der Shop die Bestellung ab.
Aufgabe: Stellen Sie den Ablauf als UML-Aktivitätsdiagramm mit den Schwimmbahnen Kunde, Shop und Lager dar.
Zeichne auf Papier oder im Diagramm-Tool nachzeichnen: Es steckt in den Übungsprüfungen und öffnet sich dort bei jeder Zeichenaufgabe.
Musterlösung anzeigen
Der Rückweg nach „Zahlungsart ändern“ mündet in eine Zusammenführung vor „Zahlung prüfen“, nicht direkt in die Aktion. Rechnung und Versand laufen parallel, deshalb Gabelung und Vereinigung über die Bahnen Shop und Lager. Bietest du dem Kunden nach einer Ablehnung zusätzlich den Abbruch an, brauchst du eine zweite Entscheidung und ein weiteres Ende; auch das ist eine gute Lösung.
So wird typischerweise bewertet
- 1 Punkt: drei Schwimmbahnen Kunde, Shop und Lager mit Namen.
- 2 Punkte: Startknoten, Endknoten und alle Aktionen in der richtigen Bahn.
- 2 Punkte: Entscheidung nach „Zahlung prüfen“ mit Bedingungen in eckigen Klammern.
- 2 Punkte: Schleife über eine Zusammenführung vor „Zahlung prüfen“.
- 2 Punkte: Gabelung und Vereinigung um Rechnung und Versand.
- 1 Punkt: Bestellung abschließen erst nach der Vereinigung.
- Richtwert gesamt: 10 Punkte.
Ein Nutzer fordert im Kundenportal an, sein Passwort zurückzusetzen. Das System sendet ihm einen Link per E-Mail, den er öffnet. Ist der Link abgelaufen, erhält er einen Hinweis und muss das Zurücksetzen erneut anfordern. Ist der Link gültig, gibt er ein neues Passwort ein. Ist es zu schwach, zeigt das System eine Fehlermeldung und der Nutzer gibt ein anderes Passwort ein. Ist es stark genug, wird es gespeichert.
Aufgabe: Stellen Sie den Ablauf einschließlich der Fehlerpfade als UML-Aktivitätsdiagramm dar. Schwimmbahnen sind nicht gefordert.
Zeichne auf Papier oder im Diagramm-Tool nachzeichnen: Es steckt in den Übungsprüfungen und öffnet sich dort bei jeder Zeichenaufgabe.
Musterlösung anzeigen
Beide Fehlerpfade sind Schleifen und brauchen je eine Zusammenführung: Der abgelaufene Link führt zurück an den Anfang, das zu schwache Passwort nur zurück zur Eingabe. Eine Kleinigkeit aus der IT-Sicherheit: Ob die E-Mail-Adresse existiert, verrät ein gutes System nicht; es zeigt immer dieselbe Meldung. Deshalb gibt es an dieser Stelle bewusst keine Entscheidung.
So wird typischerweise bewertet
- 1 Punkt: Startknoten und Endknoten.
- 2 Punkte: Aktionen in sinnvoller Reihenfolge von „Zurücksetzen anfordern“ bis „Passwort speichern“.
- 2 Punkte: Entscheidung zum Link mit [abgelaufen] und [gültig], Rückweg an den Anfang.
- 2 Punkte: Entscheidung zur Passwortstärke mit Bedingungen, Rückweg zur Eingabe.
- 2 Punkte: beide Rückwege münden in Zusammenführungen, nicht direkt in Aktionen.
- 1 Punkt: UML-Notation durchgehalten, Wächter in eckigen Klammern an jedem Ausgang der Rauten.
- Richtwert gesamt: 10 Punkte.
Typische Fehler
Jetzt selbst testen
Fünf Fragen zur Notation. Du hast so viele Versuche, wie du willst.
Welches Symbol wartet, bis alle eingehenden Zweige angekommen sind?
Wie werden die Ausgänge einer Entscheidung im UML-Aktivitätsdiagramm beschriftet?
Was passiert, wenn in einem Diagramm mit parallelen Zweigen ein Token das Aktivitätsende erreicht?
Wozu dienen Schwimmbahnen im Aktivitätsdiagramm?
Eine Aufgabe verlangt ein Struktogramm. Welches Element gehört NICHT hinein?