Aktivitätsdiagramm

Ein Use-Case-Diagramm zeigt was ein System tut, aber nicht wie der Ablauf eines einzelnen Use-Cases tatsächlich aussieht. Genau für diese Detail-Sicht ist das Aktivitätsdiagramm da: es zeigt einen Geschäftsablauf oder Algorithmus Schritt für Schritt, mit Entscheidungen, parallelen Pfaden und Endpunkten.

Aktivitätsdiagramme sind die UML-Schwester des klassischen Flussdiagramms (Flowchart) – aber mit präziser Notation und einigen mächtigen Erweiterungen wie Swimlanes und parallelen Bereichen. In dieser Lektion lernst du, sie zu lesen, zu zeichnen und in IHK-Prüfungen sicher anzuwenden.

1) Wozu Aktivitätsdiagramme?

Aktivitätsdiagramme beantworten die Frage: In welcher Reihenfolge passieren welche Schritte – und wer macht was? Sie eignen sich für:

Geschäftsprozesse dokumentieren: vom Bestelleingang bis zur Auslieferung.
Use-Case-Details visualisieren: der konkrete Ablauf eines Anwendungsfalls.
Algorithmen grafisch darstellen: ähnlich wie Struktogramme, aber mit anderen Konventionen.
Genehmigungsabläufe: wer prüft was, wann eskaliert es?
Parallele Vorgänge: was läuft gleichzeitig, wo wird wieder zusammengeführt?

Im Gegensatz zum Use-Case-Diagramm (Was-Sicht) ist das Aktivitätsdiagramm eine Ablauf-Sicht. Beide ergänzen sich – meist gibt es pro Use-Case ein zugehöriges Aktivitätsdiagramm.

2) Die Grundsymbole

Aktivitätsdiagramme verwenden eine Handvoll Standardsymbole. Wer sie kennt, kann jedes Diagramm lesen:

Die Symbol-Galerie

Startknoten

Gefüllter schwarzer Kreis. Markiert den Beginn. Genau einer pro Diagramm.

Endknoten

Ring mit Punkt drin. Markiert das Ende. Kann mehrfach vorkommen.

Aktion / Aktivität

Abgerundetes Rechteck mit Verb. Ein konkreter Schritt.

Entscheidung

Raute. Verzweigung nach Bedingung. Eingang oben, mehrere Ausgänge.

Parallelisierung

Dicker schwarzer Balken. Fork teilt in parallele Pfade, Join führt zusammen.

Kontrollfluss

Pfeil zwischen Elementen. Zeigt Reihenfolge der Schritte.

Die wichtigsten sechs Symbole – damit lassen sich 95 % aller Aktivitätsdiagramme erstellen. Zusätzlich gibt es noch Spezialsymbole (Send/Receive Signal, Time Event, Object Node), die aber in IHK-Klausuren selten gefragt sind. Wer diese sechs beherrscht, ist sicher aufgestellt.

3) Ein einfaches Beispiel

Bevor wir komplexe Strukturen anschauen, ein simples Aktivitätsdiagramm: der Ablauf einer Geld-Abhebung am Geldautomaten. Du wirst die wichtigsten Symbole im Einsatz sehen – Start, Aktionen, Entscheidung, Endknoten:

Geldautomat: einfacher Ablauf

Lies das Diagramm von oben nach unten: Start, dann die Aktionen der Reihe nach. An der Raute „PIN korrekt?" gibt es eine Verzweigung – Pfeile sind beschriftet mit [ja] bzw. [nein]. Bei „nein" geht's nach rechts zum „Karte einziehen"-Pfad mit eigenem Endknoten. Bei „ja" weiter geradeaus zum normalen Ende. Das ist die übliche Form: mehrere Endknoten für verschiedene Ausgänge.

4) Animation: das Diagramm „durchlaufen"

Aktivitätsdiagramme sind dynamisch – sie beschreiben einen Ablauf. Schau dir an, wie der „Token" (sozusagen die aktuelle Position) durch das Diagramm wandert. Mit jeder Aktion wird ein Schritt gemacht:

Token-Animation: Bestellung aufgeben

Bereit. Klick „Schritt" um den Ablauf nachzuvollziehen.

Der orangene Token markiert die aktuelle Position. So liest jemand das Diagramm im Kopf: er „verfolgt" mental den Pfad. Bei der Raute trifft er eine Entscheidung („leer?") und nimmt einen der Ausgänge. Genau dieses mentale Modell ist die Stärke von Aktivitätsdiagrammen: man kann jeden Pfad einzeln durchgehen und prüfen, ob er sinnvoll ist.

5) Swimlanes: wer macht was?

Bisher haben wir den Ablauf abstrakt gezeichnet. Was, wenn mehrere Verantwortliche beteiligt sind und wir zeigen wollen, wer welchen Schritt macht? Dafür gibt es Swimlanes (auch Aktivitätsbereiche oder Partitionen). Das Diagramm wird in vertikale oder horizontale Bahnen geteilt – je eine pro Akteur oder Verantwortlichem:

Aktivitätsdiagramm mit Swimlanes: Online-Bestellung

Beobachte: der Ablauf wechselt mehrfach die Spur – vom Kunden über den Webshop ins Lager und zurück. Jede Spur zeigt, was der entsprechende Akteur tut. Pfeile, die die Spur kreuzen, markieren Übergaben – z.B. Klick „Bestellen" durch den Kunden → Bearbeitung beim Webshop. Das ist eine sehr wertvolle Sicht für Geschäftsprozesse, weil sofort klar wird, wer worauf wartet und wo Engpässe entstehen können.

6) Parallelisierung: Fork und Join

Manche Schritte können gleichzeitig ablaufen. Beispiel: nach einer Bestellung kann gleichzeitig die Rechnung erstellt UND das Paket gepackt werden – keiner wartet auf den anderen. In UML wird das mit einem Fork (Aufspaltung) und einem Join (Zusammenführung) ausgedrückt – zwei dicke schwarze Balken:

Parallelisierung mit Fork und Join

Drei Pfade laufen gleichzeitig. Wichtig zu verstehen: der Join (unterer Balken) wartet, bis alle drei Pfade fertig sind, bevor es weitergeht. Wenn „Paket packen" 30 Minuten dauert und „Bestand reduzieren" 5 Sekunden, wartet der Bestand-Pfad eben 29:55 am Join. Diese Semantik ist exakt das, was man von echter Nebenläufigkeit erwartet. Im Code würde das z.B. mit Threads oder asynchronen Tasks umgesetzt.

7) Aktivitätsdiagramm vs. Flussdiagramm

Wer schon Flussdiagramme (Flowcharts) kennt: wo ist der Unterschied zum UML-Aktivitätsdiagramm? Beide haben Rauten für Entscheidungen, Rechtecke für Aktionen und Pfeile für Reihenfolge. Aber es gibt wichtige Unterschiede:

Vergleich der Notationen

Flussdiagramm (klassisch, ältere Notation)

Rechtecke für Aktionen, Rauten für Entscheidungen. Keine Swimlanes, keine Parallelisierung. Hat oft GOTO-ähnliche Verbindungen. Eingebaut in viele Tools, intuitiv – aber begrenzt expressiv.

Aktivitätsdiagramm (UML, modern)

Abgerundete Rechtecke für Aktionen, Rauten für Entscheidungen, schwarze Balken für Fork/Join, Swimlanes für Verantwortlichkeiten. Strikt strukturiert (keine GOTO-Sprünge), präzise Semantik, viele Spezialsymbole. UML-Standard – auch in IHK-Prüfungen.

In der Praxis: für einfache Algorithmen tut's das Flussdiagramm. Für Geschäftsprozesse mit mehreren Verantwortlichen und parallelen Abläufen ist das Aktivitätsdiagramm überlegen. Für reine Algorithmen-Darstellung sind Struktogramme (Nassi-Shneiderman) oder Pseudocode oft kompakter – das sind eigene Notationen für die Algorithmus-Ebene.

8) Vorgehensweise: ein Aktivitätsdiagramm zeichnen

So gehst du in einer IHK-Aufgabe oder einem echten Projekt vor, wenn du aus einer Anforderung ein Aktivitätsdiagramm erstellen sollst:

Schritt-für-Schritt zum Aktivitätsdiagramm

Anwendungsfall klären. Welcher konkrete Ablauf wird modelliert? Vorbedingungen, Auslöser, Endergebnis. Häufig basiert das auf einer Use-Case-Spezifikation – konkret: dem „normalen Ablauf" und den alternativen Abläufen.

Akteure / Bereiche identifizieren. Wer ist beteiligt? Wenn mehrere – Swimlanes verwenden. Wenn nur einer oder die Verantwortlichkeit irrelevant – ohne Swimlanes.

Hauptpfad modellieren. Erst den „glücklichen Tag" zeichnen – den Normalfall ohne Fehler oder Sonderfälle. Start → Aktion → Aktion → ... → Ende. Das ist meist die längste, aber einfachste Sequenz.

Entscheidungen einfügen. An welchen Stellen muss verzweigt werden? Raute mit beschrifteten Ausgängen. Jeder Ausgang muss einen Pfad haben – nicht einfach hängen lassen.

Parallele Abläufe markieren. Wo läuft etwas gleichzeitig? Fork-Balken setzen, parallele Pfade modellieren, Join-Balken zum Zusammenführen. Faustregel: jeder Fork braucht einen Join.

Alternative Endpunkte. Fehlerfälle, Abbrüche, Sonderausgänge bekommen jeweils eigene Endknoten. Es ist kein Problem, mehrere Endknoten zu haben – das ist sogar Best Practice für klare Diagramme.

Prüfen. Jede Aktion hat min. einen eingehenden Pfeil und einen ausgehenden. Jede Entscheidung hat alle Ausgänge beschriftet. Forks und Joins kommen paarweise. Keine Pfeile ohne Ziel.

9) Typische Klausur-Fehler

Aktivitätsdiagramme sind ein Klassiker in IHK-Aufgaben. Diese Fehler kosten besonders häufig Punkte:

Klassische Fehler

Aktionen als Substantive

„Bestellung" oder „Rechnung" – das sind keine Aktionen. Immer Verb + Objekt: „Bestellung anlegen", „Rechnung erstellen".

Entscheidungs-Ausgänge nicht beschriftet

Jeder Pfeil aus einer Raute muss eine Bedingung haben ([ja], [nein], [Betrag > 100]). Unbeschriftete Ausgänge sind ein Klassiker für Punktabzug.

Fork ohne Join

Wenn parallel aufgespalten wird, muss irgendwann wieder zusammengeführt werden – oder das Diagramm endet in mehreren Endknoten. Frei „endende" parallele Pfade ohne Endknoten sind falsch.

Endknoten vergessen

Jeder Pfad muss enden. „Hängender" Pfeil zu nirgendwo ist falsch. Lieber einen extra Endknoten setzen.

Pfeile in falsche Richtung

Aktivitätsdiagramme fließen typisch von oben nach unten (oder links nach rechts). Pfeile entgegen der Hauptrichtung sind verwirrend – wenn nötig, dann klar als Schleife kennzeichnen.

Innenleben modellieren

Aktivitätsdiagramme zeigen Abläufe, keine Datenstrukturen oder Klassen. Konkrete Datenbank-Tabellen, Methodennamen, Variablenzuweisungen gehören hier nicht rein.

10) Aktivitätsdiagramm vs. Sequenzdiagramm – wann was?

Sowohl Aktivitäts- als auch Sequenzdiagramme (L4 dieses Kurses) zeigen zeitliche Abläufe. Wo ist der Unterschied?

Aktivitätsdiagramm: zeigt den Prozess-Ablauf. Was sind die Schritte? Wer macht sie? Welche Bedingungen führen wohin? Sehr gut für fachliche Prozesse.
Sequenzdiagramm: zeigt die Interaktion zwischen Objekten. Welche Nachrichten werden in welcher Reihenfolge zwischen Komponenten ausgetauscht? Sehr gut für technische Abläufe.

Faustregel: fachlich → Aktivitätsdiagramm. technisch zwischen Komponenten → Sequenzdiagramm. In großen Projekten kommen oft beide vor: Aktivitätsdiagramme für die Anforderungs-/Prozess-Sicht, Sequenzdiagramme für die Architektur-Sicht.

Zusammenfassung

Das Aktivitätsdiagramm ist ein UML-Diagrammtyp, der Abläufe und Prozesse visualisiert. Es zeigt, in welcher Reihenfolge welche Schritte passieren, mit Entscheidungen, parallelen Pfaden und mehreren Endpunkten. Es ist die Detail-Sicht auf einen Use-Case und die UML-Antwort auf das klassische Flussdiagramm. Symbole: gefüllter Kreis (Start), Ring-mit-Punkt (Ende), abgerundetes Rechteck (Aktion), Raute (Entscheidung), dicker schwarzer Balken (Fork/Join für Parallelität), Pfeile (Kontrollfluss). Swimlanes sind eine Erweiterung: vertikale oder horizontale Bahnen pro Akteur zeigen die Verantwortlichkeit. Fork und Join: mit Forks lässt sich Parallelität modellieren – mehrere Pfade laufen gleichzeitig, der Join wartet auf alle. Unterschied zum Flussdiagramm: präzise UML-Semantik, Swimlanes, Fork/Join, modernes Standardtool. Vorgehensweise: 1) Use-Case klären, 2) Akteure identifizieren, 3) Hauptpfad zeichnen, 4) Entscheidungen einfügen, 5) Parallelität ergänzen, 6) Endknoten, 7) prüfen. Häufige Fehler: Substantive statt Verben, unbeschriftete Entscheidungs-Ausgänge, Fork ohne Join, vergessene Endknoten, technisches Innenleben. Abgrenzung: Aktivitätsdiagramme zeigen Prozesse (fachlich), Sequenzdiagramme zeigen Interaktionen (technisch). Praxis-Anwendung: Geschäftsprozesse, Use-Case-Abläufe, Genehmigungs-Workflows, parallele Operationen. Nächste Lektion: Sequenzdiagramme – noch detaillierter, jetzt mit Fokus auf der Kommunikation zwischen Objekten.