UML-Aktivitätsdiagramm
https://oer-informatik.de/uml-aktivitaetsdiagramm
https://bildung.social/@oerinformatik/109865194039578226
UML, Aktivitätsdiagramm, Verhaltensdiagramm, Kontrollfluss, Tokenmodell, Entscheidung, Parallelisierung, Swimlanes, Ablaufende, Zählschleife, Prüfungsvorbereitung
tl/dr; (ca. 29 min Lesezeit): UML-Aktivitätsdiagramme sind die Flussdiagramme der UML zur Planung und Dokumentation von Algorithmen und Abläufen. In diesem Artikel geht es um die Grundlagen dieses Diagramms (Abläufe, Parallelisierung, Swimlanes), um typische Modellierungsfehler und darum, wie Du aus einer Ablaufbeschreibung Schritt für Schritt ein Diagramm entwickelst. In einem zweiten Teil wird es um Feinheiten wie den Objektfluss und Umgang mit Exceptions gehen [AI-Assisted]. (Zuletzt geändert am 29.10.2026)
Dieser Artikel ist Teil einer Artikelreihe über UML-Aktivitätsdiagramme: Grundlagen des Aktivitätsdiagramms (Übungsaufgaben) / Objektflüsse, Signale und Ausnahmen / Aktivitätsdiagramme mit PlantUML / Kurzübung: WebApp-Seite zusammenstellen / Anwendung: Geschäftsprozesse digitalisieren. Zu den übrigen UML-Diagrammen gibt es eigene Reihen, z. B. zum Klassendiagramm, Sequenzdiagramm, Zustandsdiagramm und Anwendungsfalldiagramm.
Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast.
Als Aktivitätsdiagramm-Grundlagen kann ich nach Durchlesen des Artikels…
… Startknoten, Ablaufende und Endknoten notieren und erklären, wann ein Ablaufende statt eines Endknotens nötig ist.
… Aktionen als Tätigkeit (Objekt + Verb) benennen.
… Entscheidungen mit Bedingungen (guards) bezeichnen und mit Zusammenführungen wieder vereinen.
… parallele Strukturen mit Gabelung und Synchronisierung notieren.
… korrekte Pfeile und Symbole verwenden.
… Verantwortungsbereiche über Partitionen (Swimlanes) darstellen.
… Tokentunnel (Konnektoren) darstellen.
… Wiederholungen über Zusammenführung und Entscheidung modellieren und optionale Schritte darstellen.
… Vorteile eines Aktivitätsdiagramms gegenüber einer Textbeschreibung nennen und UML-Diagramme der statischen oder der dynamischen Sicht zuordnen.
… Bedingungen für Zahlenbereiche lückenlos und ohne Überschneidung formulieren.
Darüber hinaus kann ich als Aktivitätsdiagramm-Expertenwissen…
… aus einer Ablaufbeschreibung oder einer ungeordneten Liste von Aktionen ein Aktivitätsdiagramm mit Schwimmbahnen erstellen und ein vorgegebenes Diagramm erweitern oder vervollständigen.
… mit dem Tokenmodell nachvollziehen, wie ein Diagramm abläuft, und typische Fehler (Verklemmung, doppelte Ausführung, falscher Endknoten, Bedingung in der Raute) erkennen und korrigieren.
… Varianten eines Ablaufs vergleichen und hinsichtlich ihrer Praxistauglichkeit begründet bewerten.
… eine Zählschleife modellieren und vorgegebene Aktionen in ein vorbereitetes Diagramm einordnen.
… parallele Zweige für eine erst zur Laufzeit bekannte Anzahl gleichartiger Aufgaben darstellen.
… eine Aktivität mit Rahmen und Namen darstellen und eine andere Aktivität über das Rechen-Symbol aufrufen.
Diagramm zur Verhaltensmodellierung
Ein UML-Aktivitätsdiagramm (activity diagram) beschreibt, wie das Verhalten eines (Software-)Systems realisiert ist. Es erweitert die Ausdrucksmöglichkeiten gegenüber einfacheren Flussdiagrammen wie dem Programmablaufplan, z. B. durch die Möglichkeit, Parallelisierung, Ausnahmen oder Datenflüsse abzubilden. Im Aktivitätsdiagramm können Daten- und Kontrollflüsse modelliert werden, z. B. von
Algorithmen,
Geschäftsprozessen oder
Workflows.
Im Fokus steht die Modellierung der Abfolge (sequenziell oder parallel), Bedingungen, Verzweigungen, Wiederholungen sowie Anfang und Ende von Aktivitäten. Alle Schritte können zudem in Verantwortungsbereichen konkreten Akteur*innen oder Systemen zugewiesen werden.
Häufig beschreibt ein Aktivitätsdiagramm im Detail, wie ein Anwendungsfall aus dem Use-Case-Diagramm abläuft – als Ist-Prozess, um Schwachstellen zu finden, oder als Soll-Prozess bzw. Systemablauf, der später programmiert wird. Die Notation ist in der UML-Spezifikation 2.5.1 der Object Management Group festgelegt (Kapitel 15 „Activities“ und 16 „Actions“).
Die UML unterscheidet zwei Gruppen von Diagrammen: Strukturdiagramme zeigen die statische Sicht, also den Aufbau eines Systems (z. B. Klassen-, Objekt-, Komponenten-, Verteilungs- und Paketdiagramm). Verhaltensdiagramme zeigen die dynamische Sicht, also was im System geschieht (Aktivitäts-, Anwendungsfall- und Zustandsdiagramm sowie die Interaktionsdiagramme wie das Sequenzdiagramm). Das Aktivitätsdiagramm gehört zu den Verhaltensdiagrammen.
Gegenüber einer reinen Textbeschreibung hat ein Aktivitätsdiagramm mehrere Vorteile:
Übersicht: Verzweigungen, Wiederholungen und parallele Schritte sind auf einen Blick erkennbar.
Gemeinsame Sprache: Die Notation ist genormt; Fachabteilung und Entwicklung lesen dasselbe Diagramm gleich.
Lücken finden: Beim Zeichnen fällt auf, wenn ein Fall fehlt („Was passiert, wenn …?“) oder ein Ablauf unnötig oft die Zuständigkeit wechselt.
Grundlage für Umsetzung und Test: Aus Entscheidungen werden Programmverzweigungen und Testfälle, aus Schwimmbahnen Zuständigkeiten.
Einarbeitung: Neue Mitarbeitende verstehen einen Ablauf schneller als aus einem langen Text.
Die wichtigsten Notationselemente, die dieser Artikel vorstellt, zeigt die folgende Übersicht:
Das Tokenmodell im Flussdiagramm: mit Knoten und Kanten
Aktivitätsdiagramme bestehen aus Knoten und Kanten. Sie nutzen das Tokenmodell: ein Token ist eine gedachte Markierung. Diese kennzeichnet die momentan ausgeführten Aktionen – vergleichbar mit dem springenden Punkt beim Karaokesingen, der die aktuelle Silbe markiert. Ein Token wird im Startpunkt (initial node) erzeugt und durchläuft das Diagramm entlang der gerichteten Kanten (Pfeile, edges). Im Endpunkt (activity final node) wird der Token konsumiert und die Aktivität so beendet.
Ein minimales Aktivitätsdiagramm, das eine unverzweigte Aktivität darstellt, sieht wie folgt aus:
Aktionen benennen: Objekt + Verb
Jede Aktion (action) ist ein einzelner Arbeitsschritt, der im Diagramm nicht weiter zerlegt wird. Sie wird als Rechteck mit abgerundeten Ecken gezeichnet und beschreibt eine Tätigkeit: ein Objekt und ein Verb im Infinitiv, z. B. „Rechnung erstellen“, „Anfrage prüfen“, „Ware versenden“.
Nicht geeignet sind Dinge oder Dokumente („Rechnung“), Substantivierungen („Rechnungserstellung“) und Zustände oder Ergebnisse („Rechnung erstellt“, „Login erfolgreich“).
Gibt eine beteiligte Person oder ein System etwas an andere weiter, wird das als Aktion bei der oder dem Handelnden notiert („Bestätigung senden“). Die Kante führt dann zur nächsten Aktion der Empfängerin oder des Empfängers.
Wie fein Du zerlegst, richtet sich nach der Beschreibung: Was dort als ein Schritt genannt ist, wird eine Aktion. „Daten eingeben und absenden“ darf z. B. eine Aktion sein.
Ein Diagramm hat in der Regel genau einen Startknoten. Endknoten darf es mehrere geben, z. B. für den regulären Abschluss und für eine Absage.
Kontrollstrukturen: Verzweigung und Vereinigung
Neben dem rein sequenziellen unverzweigten Ablauf können auch bedingte Anweisungen modelliert werden. Verzweigungen werden als Entscheidungsknoten (decision node) mit dem Raute-Symbol notiert. Die Bedingungen selbst werden als guard bezeichnet und in eckigen Klammern an der jeweiligen Kante notiert. (Die Notation wird häufig mit dem Programm-Ablaufplan verwechselt, bei dem die Bedingung in die Raute und die Alternativen ohne eckige Klammern geschrieben wird.)
Die Bedingungen müssen als boolescher Ausdruck formuliert sein – also mit true oder false auswertbar sein. Sie sollten disjunkt sein (sich gegenseitig ausschließen), um ein vorhersagbares Verhalten zu modellieren. Bei einfachen Verzweigungen erreicht man das, indem zu jeder Bedingung ein [else]-Zweig modelliert wird.
Im Gegensatz zum Programmablaufplan werden die verschiedenen Kanten einer Verzweigung auch wieder an einer Raute (merge node) zusammengeführt. Weder ein decision node noch ein merge node ändern die Anzahl der vorhandenen Token.
Soll nur in einem Fall zusätzlich etwas passieren (optionaler Schritt), bleibt der andere Zweig leer: Die Kante mit [else] führt direkt zur Zusammenführung. Beispiel: „Liegt der Füllstand des Tanks unter 30 %, erhält der Betrieb eine Warnung“ – danach geht es in beiden Fällen gleich weiter.
Die Raute steht in der Schwimmbahn derjenigen Person oder des Systems, die bzw. das entscheidet (siehe Partitionen unten). Mehrere Entscheidungen dürfen aufeinander folgen oder ineinander verschachtelt sein; jede wird mit einer eigenen Zusammenführung geschlossen, sobald die Zweige wieder gemeinsam weiterlaufen.
Nicht alle Bedingungen lassen sich unmittelbar als boolescher Ausdruck (true/false) formulieren. Sofern nähere Erläuterungen nötig sind, sieht die UML vor, dass diese über eine Notiz mit dem Schlüsselwort «decisionInput» erfolgt, die mit der decision node über eine gestrichelte Linie verbunden wird.
Mehrfache Verzweigungen können durch mehr Kanten realisiert werden, die den decision node verlassen. Wichtig ist auch hier, dass die guards disjunkt sind. Die Zusammenführung erfolgt auch in diesem Fall über einen merge node.
Besonders fehleranfällig sind Bedingungen über Zahlenbereiche (Akkustände, Beträge, Anzahlen). Jeder mögliche Wert muss in genau einem Bereich liegen – lückenlos und ohne Überschneidung. Kritisch sind die Grenzwerte: Bei [Akkustand < 20 %] und [Akkustand > 20 %] ist der Fall „genau 20 %“ nicht abgedeckt; ein Token mit diesem Wert könnte die Entscheidung nicht verlassen. Richtig ist zum Beispiel [Akkustand < 20 %], [Akkustand >= 20 % und < 50 %], [Akkustand >= 50 %]. Hilfreich ist ein Zahlenstrahl, auf dem Du die Bereiche einträgst; den letzten Fall kannst Du auch [else] nennen.
Wiederholungsstrukturen: kopf- und fußgesteuerte Schleifen
Eine nachgelagerte Bedingung, die eine Wiederholung bestimmter Aktionen erzwingt, wird über die Rückführung der ausgehenden Kante mit guard einer decision node modelliert. Bei diesen fußgesteuerten Schleifen werden die Aktionen innerhalb der Schleife in jedem Fall einmal ausgeführt:
Im Fall einer kopfgesteuerten Schleife wird die Bedingung zunächst geprüft, die zu wiederholenden Aktionen also ggf. nie ausgeführt:
In Abläufen aus dem Arbeitsalltag sind Wiederholungen oft Rücksprünge: „Fehlen Angaben, füllt die Person das Formular erneut aus“ oder „Werden Mängel gefunden, werden sie behoben und es wird erneut geprüft“. Der Rücksprung endet immer in einer Zusammenführung (Raute) vor der Aktion, die wiederholt wird – nie direkt in der Aktion selbst und nie im Startknoten. Eine Aktion mit zwei eingehenden Kanten würde nach UML auf Token an beiden Kanten warten (siehe Parallelisierung unten). Der Rücksprung darf auch über Bahngrenzen führen, etwa wenn die Buchhaltung eine Rechnung zurückweist und der Vertrieb sie neu erstellt.
Auch Algorithmen lassen sich so darstellen. Eine Zählschleife über eine Liste oder ein Array braucht drei Bestandteile: eine Aktion vor der Schleife, die den Zähler setzt (i = 0), eine Entscheidung mit der Laufbedingung ([i < n], zum Verlassen [else]) und am Ende des Schleifenrumpfs eine Aktion, die den Zähler erhöht (i = i + 1). Fehlt die Erhöhung, endet die Schleife nie. Soll innerhalb der Schleife gezählt werden (z. B. anzahl = anzahl + 1, wenn ein Element eine Bedingung erfüllt), ist das ein optionaler Schritt mit leerem [else]-Zweig. In solchen Algorithmen dürfen Aktionen auch Zuweisungen oder kurze Anweisungen sein; die Regel „Objekt + Verb“ gilt vor allem für Abläufe mit Personen und Systemen.
Concurrency: Parallelisierung von Aktionen (Splitting und Synchronisation)
Im Gegensatz zu einem decision node oder merge node muss bei Gabelungen (fork node) und Synchronisierungen (join node) an allen eingehenden Kanten ein Token anliegen, damit sie Token weiterreichen. Sie geben dann an allen ausgehenden Kanten einen Token weiter. Auf diese Art werden parallele Prozesse und Synchronisierungen modelliert.
Nach UML-Standard gilt diese Regel auch für Aktionen: Sie werden erst ausgeführt, wenn an allen eingehenden Kanten ein Token anliegt – und sie geben nach ihrem Abschluss an allen ausgehenden Kanten einen Token weiter. Diese Festlegung wird in der Praxis sehr häufig missachtet, sodass sich im Internet und der Literatur zahlreiche nicht navigierbare Aktivitätsdiagramme finden.
Entscheidungen in parallelen Zweigen
Auch innerhalb eines parallelen Zweigs darf entschieden werden. Wichtig ist, dass der Zweig vor der Synchronisation wieder zu einer Kante zusammengeführt wird, damit dort in jedem Fall genau ein Token ankommt. Im Beispiel wird ein Artikel nur bei Bedarf als Geschenk verpackt; die Rechnung wird in jedem Fall parallel erstellt:
Soll nur in einem bestimmten Fall parallel gearbeitet werden („Bei einem Großauftrag werden gleichzeitig Material bestellt und Personal eingeplant“), liegen Teilung und Synchronisation vollständig in einem Zweig einer Entscheidung; danach werden die Zweige mit einer Zusammenführung vereint. Paralleles Arbeiten ist auch über Bahngrenzen hinweg möglich: Der Balken darf mehrere Schwimmbahnen überspannen.
Viele gleichartige Aufgaben parallel
Steht erst beim Ablauf fest, wie viele gleichartige Aufgaben parallel erledigt werden (alle Positionen einer Bestellung, alle hochgeladenen Fotos), zeichnest Du nach der Teilung stellvertretend zwei Zweige – etwa „Aufgabe 1 erledigen“ und „Aufgabe n erledigen“ – und setzt Auslassungspunkte (…) dazwischen. Alle Zweige münden in eine Synchronisation, sodass erst weitergemacht wird, wenn alle Aufgaben fertig sind. Exakt modellieren lässt sich eine beliebige Anzahl mit einem Expansionsbereich mit dem Schlüsselwort «parallel» (UML 2.5.1, Abschnitt 16.12): Er führt die Aktionen in seinem Inneren für jedes Element einer Eingabeliste aus.
Partitionen / Swimlanes zur Unterscheidung von Verantwortungsbereichen
Die UML sieht vor, dass modelliert werden kann, welche Akteurin oder welches System für bestimmte Aktionen verantwortlich oder organisatorisch zuständig ist. Aufgrund des Aussehens werden diese Verantwortungsbereiche, die die UML partition nennt, oft swimlanes genannt. Diese können hierarchisch aufgebaut sein: Dimension (“Beteiligte”), Partitionen (“Auftragnehmer”), Sub-Partitionen (“Geschäftsführer”).
Anstelle der Swimlanes (wenn auch weniger übersichtlich) können die Partitionen auch innerhalb der Aktionen in Klammern angegeben sein. Folgendes Beispiel ist inhaltsgleich zu dem obigen Beispiel:
Beim Zeichnen mit Schwimmbahnen gilt:
Jede Aktion liegt in der Bahn der Person oder des Systems, die bzw. das sie ausführt.
Auch Entscheidungen liegen in der Bahn derjenigen, die entscheiden: Gibt eine Teamleitung einen Urlaubsantrag frei oder lehnt ihn ab, gehört die Raute in ihre Bahn – nicht in die des Personalportals.
Kanten dürfen Bahngrenzen überqueren. So wird sichtbar, wo ein Vorgang von einer oder einem Beteiligten an die nächste Stelle übergeht. Jede Übergabe ist eine mögliche Schwachstelle (Wartezeit, Medienbruch) – das ist bei der Analyse von Geschäftsprozessen interessant.
Die Reihenfolge der Bahnen ist frei, sofern sie nicht vorgegeben ist. Günstig ist eine Anordnung, bei der sich möglichst wenige Kanten kreuzen.
Ablaufende
Wenn das Erreichen eines Endes zwar den aktuellen Ausführungsstrang beendet - also den eingetroffenen Token konsumiert - aber in der Gesamtaktivität noch weitere Token vorhanden sein können, muss ein Ablaufende (flow final node) modelliert werden. Im Gegensatz zu einem activity final node werden nicht alle vorhandenen Token konsumiert, sondern nur der am flow final node eintreffende Token.
Der Unterschied ist vor allem bei Parallelität wichtig: Ein Endknoten in einem parallelen Zweig beendet die gesamte Aktivität – auch die anderen Zweige, die vielleicht noch gar nicht fertig sind. Soll ein Zweig nur auslaufen (z. B. „Zugriff protokollieren“, auf dessen Ende nicht gewartet wird), gehört dorthin ein Ablaufende. In Abläufen ohne Parallelität ist immer nur ein Token unterwegs; dort sind mehrere Endknoten für verschiedene Ausgänge (regulärer Abschluss, Absage, Abbruch) üblich und richtig.
Aktivitäten einrahmen und aufrufen
Ein Aktivitätsdiagramm zeigt immer eine Aktivität: den gesamten Ablauf, der aus einzelnen Aktionen besteht. Soll ihr Name sichtbar sein, wird das Diagramm in einen Rahmen mit abgerundeten Ecken gesetzt; der Name steht oben links im Rahmen (z. B. „Bestellung bearbeiten“). Auf dem Rand können zusätzlich Ein- und Ausgabeparameter als Rechtecke stehen.
Wird ein Teilablauf an mehreren Stellen gebraucht oder ist er für ein Diagramm zu groß, modellierst Du ihn als eigene Aktivität und rufst sie auf: Im aufrufenden Diagramm steht eine normale Aktion mit dem Namen der aufgerufenen Aktivität und einem kleinen Rechen-Symbol (einer dreizinkigen Gabel) unten rechts (call behavior action). Ist die aufgerufene Aktivität beendet, geht der Ablauf an der ausgehenden Kante der Aktion weiter. Beispiele zeigt der Artikel zu fortgeschrittenen Techniken.
Konnektoren (Sprungmarken) zur übersichtlicheren Darstellung
Um Kreuzungen zu vermeiden oder um komplexere Zusammenhänge übersichtlicher darstellen zu können, können Sprungmarken (A) verwendet werden. Abläufe können dadurch unterbrochen und in gesonderten Aktivitätsdiagrammen ausgeführt werden.
Typische Fehler – und wie Du sie vermeidest
Die meisten Fehler entstehen, wenn Verzweigungen und parallele Abläufe nicht mit dem passenden Gegenstück geschlossen werden. Mit dem Tokenmodell lässt sich jeder dieser Fehler nachvollziehen:
| Fehler | Was passiert (Tokenmodell)? | Richtig |
|---|---|---|
| Zweige einer Entscheidung werden mit einem Balken (Synchronisation) vereint. | Nur ein Zweig erhält einen Token, der Balken wartet ewig auf den zweiten: Verklemmung (deadlock). | Zusammenführung (Raute) |
| Parallele Zweige werden mit einer Raute (Zusammenführung) vereint. | Beide Token laufen weiter, alle folgenden Aktionen werden doppelt ausgeführt. | Synchronisation (Balken) |
| Ein Rücksprung führt direkt in eine Aktion, die schon eine eingehende Kante hat. | Die Aktion wartet auf Token an allen eingehenden Kanten (implizite Synchronisation) – der Ablauf bleibt stehen. | Zusammenführung vor der Aktion |
| Endknoten am Ende eines parallelen Zweigs | Die ganze Aktivität endet, auch unfertige Zweige werden abgebrochen. | Ablaufende oder Synchronisation |
| Bedingung als Frage in der Raute, Ausgänge „ja“/„nein“ | Schreibweise des Programmablaufplans, in der UML nicht vorgesehen | Bedingungen in [ ] an den Kanten |
| Bedingungen fehlen, überschneiden sich oder decken nicht alle Fälle ab. | Der Ablauf ist nicht eindeutig oder bleibt stehen. | vollständige, disjunkte Bedingungen, ggf. [else] |
| Teilung ohne Synchronisation, obwohl auf alle Zweige gewartet werden soll | Folgeaktionen starten, bevor alles erledigt ist. | Synchronisation vor der Folgeaktion |
| Aktion als Ding oder Zustand benannt („Rechnung“, „bezahlt“) | Es bleibt unklar, was getan wird. | Objekt + Verb („Rechnung erstellen“) |
Schritt für Schritt: vom Text zum Aktivitätsdiagramm
Oft liegt ein Ablauf als Beschreibung, als Gesprächsnotiz oder als ungeordnete Liste von Aktionen vor. So gehst Du vor:
Beteiligte finden: Jede Person, Abteilung oder jedes System, das etwas tut, wird eine Schwimmbahn. Ist die Reihenfolge der Bahnen vorgegeben, übernimm sie.
Aktionen markieren: Unterstreiche alle Tätigkeiten und formuliere sie als Objekt + Verb. Liegt schon eine Liste von Aktionen vor, ordne sie zuerst den Bahnen zu und bringe sie dann in eine Reihenfolge.
Signalwörter übersetzen:
„wenn“, „falls“, „ist … nicht …“ → Entscheidung mit Bedingungen; jeder Fall braucht einen Ausgang.
„nur wenn“, „zusätzlich“ → optionaler Schritt (Entscheidung mit leerem
[else]-Zweig).„erneut“, „wieder“, „zurück“, „so lange, bis“ → Rücksprung über eine Zusammenführung.
„gleichzeitig“, „parallel“, „währenddessen“ → Teilung.
„sobald beide“, „nachdem alle … erledigt sind“ → Synchronisation.
„ist beendet“, „Vorgang abgeschlossen“ → Endknoten; „auf … wird nicht gewartet“ → Ablaufende.
Zeichnen: Startknoten in die Bahn, in der der Ablauf beginnt, dann dem Text folgen. Lass Platz: Zusammenführungen für spätere Rücksprünge liegen vor der Aktion, zu der zurückgesprungen wird.
Prüfen: Hat jede Entscheidung Bedingungen in eckigen Klammern? Wird jede Entscheidung mit einer Zusammenführung und jede Teilung mit einer Synchronisation (oder einem Ablaufende) geschlossen? Liegen alle Aktionen und Entscheidungen in der richtigen Bahn? Führt jeder Weg zu einem Ende? Spiele dazu jeden Fall einmal mit einem Token durch.
Sollst Du ein angefangenes Diagramm erweitern oder vervollständigen, bleiben die vorgegebenen Elemente stehen. Führt ein Rücksprung zurück in den vorgegebenen Teil, fügst Du dort eine Zusammenführung ein; dafür darfst Du eine vorgegebene Kante auftrennen.
Manchmal ist das Diagramm schon gezeichnet, und Du sollst nur vorgegebene Aktionen oder Begriffe in leere Felder eintragen. Beginne dann bei den festen Punkten: Start und Ende, Bedingungen an den Kanten und Rücksprünge. Eine Aktion direkt vor einer Entscheidung muss liefern, was die Bedingung prüft; die letzte Aktion eines Schleifenrumpfs ist oft das Weiterzählen. Prüfe zum Schluss, ob jede Aktion genau einmal verwendet ist und der Ablauf mit dem Tokenmodell durchläuft.
Prüfe Dein Diagramm zum Schluss mit dieser Checkliste: Aktionen an der richtigen Stelle und in der richtigen Bahn, Entscheidungen mit Bedingungen, Teilung und Synchronisation, Zusammenführungen, Start- und Endknoten.
Abläufe bewerten und vergleichen
Aktivitätsdiagramme eignen sich gut, um Varianten eines Ablaufs nebeneinanderzulegen, bevor programmiert wird. Für die Frage, welche Variante praxistauglicher ist, helfen diese Kriterien:
Gleichzeitige Zugriffe: Was passiert, wenn zwei Personen gleichzeitig denselben Termin, Platz oder Artikel buchen? Blockiert eine Variante Ressourcen (z. B. alle Plätze einer Fahrgemeinschaft, solange eine Anfrage offen ist) länger als nötig?
Wartezeiten und Durchlaufzeit: Wie lange wartet jemand auf eine Antwort? Lassen sich Schritte parallelisieren?
Übergaben: Wie oft wechselt der Ablauf die Bahn? Jede Übergabe kostet Zeit und ist eine Fehlerquelle.
Risiken: Welche Fehler- und Ausnahmefälle gibt es (Zahlung bleibt aus, Verbindung bricht ab), und sind sie im Ablauf behandelt?
Aufwand für die Nutzenden: Wie viele Schritte müssen sie selbst ausführen?
Wie man so einen bestehenden Geschäftsprozess analysiert und digital verbessert, zeigt der Artikel Geschäftsprozesse digitalisieren und optimieren.
Fazit
In diesem ersten Teil über UML-Aktivitätsdiagramme ging es vor allem um die Standardnotationsmittel. Im zweiten Teil werden die Feinheiten wie Objektfluss mit Parameter(-gruppen) und Bedingungen sowie das Exceptionhandling behandelt, die aus einem einfachen Flussdiagramm ein mächtiges Werkzeug zur Modellierung machen. Weiter zu Teil zwei
Ein Beispiel für ein Aktivitätsdiagramm eines bestehenden Prozesses ist die Authentifizierung mit OAuth2:
Leitfragen
- Wodurch unterscheiden sich Endknoten und Ablaufende, und wann brauchst Du welches?
Ein Endknoten beendet die gesamte Aktivität und entfernt alle Token, ein Ablaufende verbraucht nur den Token, der dort ankommt. Ein Ablaufende brauchst Du vor allem in parallelen Zweigen, die auslaufen sollen, ohne die anderen Zweige abzubrechen. siehe Abschnitt „Ablaufende“
- Wie werden Bedingungen an einer Entscheidung notiert, und welche Anforderungen müssen sie erfüllen?
Bedingungen (guards) stehen in eckigen Klammern an den ausgehenden Kanten, nicht in der Raute. Sie müssen sich als wahr oder falsch auswerten lassen, sich gegenseitig ausschließen und zusammen alle Fälle abdecken; dabei hilft [else]. siehe Abschnitt „Kontrollstrukturen“
- Warum wird eine Entscheidung mit einer Zusammenführung, eine Teilung aber mit einer Synchronisation geschlossen?
Nach einer Entscheidung ist nur ein Token unterwegs: Ein Synchronisationsbalken würde ewig auf einen zweiten Token warten (Verklemmung). Nach einer Teilung laufen mehrere Token: Eine Raute würde jeden davon weiterreichen, und die folgenden Aktionen liefen mehrfach. siehe Abschnitt „Typische Fehler“
- Wie modellierst Du einen Rücksprung, der einen Teil des Ablaufs wiederholt, und wie einen optionalen Schritt?
Ein Rücksprung endet in einer Zusammenführung vor der Aktion, die wiederholt wird, nie direkt in der Aktion oder im Startknoten. Für einen optionalen Schritt führt der [else]-Zweig einer Entscheidung ohne Aktion direkt zur Zusammenführung. siehe Abschnitt „Wiederholungsstrukturen“
- Nach welchen Regeln ordnest Du Aktionen und Entscheidungen den Schwimmbahnen zu?
Jede Aktion liegt in der Bahn der Person oder des Systems, die bzw. das sie ausführt, jede Entscheidung in der Bahn derjenigen, die entscheiden. Kanten dürfen Bahngrenzen überqueren und zeigen so Übergaben. siehe Abschnitt „Partitionen / Swimlanes“
- Welche Signalwörter in einer Ablaufbeschreibung deuten auf Entscheidung, Teilung, Synchronisation und Schleife hin?
„Wenn“ und „falls“ führen zu einer Entscheidung, „gleichzeitig“ und „währenddessen“ zu einer Teilung, „sobald beide“ und „nachdem alle … erledigt sind“ zu einer Synchronisation, „erneut“ und „so lange, bis“ zu einem Rücksprung über eine Zusammenführung. siehe Abschnitt „Schritt für Schritt“
- Wie findest Du mithilfe des Tokenmodells Fehler wie Verklemmungen oder doppelte Ausführungen?
Du spielst jeden Fall mit einem Token durch. Wartet ein Synchronisationsbalken auf einen Token, der nie kommt, liegt eine Verklemmung vor; kommen mehrere Token nacheinander durch eine Raute, werden die folgenden Aktionen doppelt ausgeführt. siehe Abschnitt „Typische Fehler“
- Nach welchen Kriterien vergleichst Du zwei Varianten eines Ablaufs?
Hilfreich sind gleichzeitige Zugriffe auf dieselben Ressourcen, Wartezeiten und Durchlaufzeit, die Zahl der Übergaben zwischen Bahnen, die behandelten Risiken und Ausnahmefälle sowie der Aufwand für die Nutzenden. siehe Abschnitt „Abläufe bewerten und vergleichen“
- Welche Vorteile hat ein Aktivitätsdiagramm gegenüber einer Textbeschreibung, und welche UML-Diagramme zeigen die statische, welche die dynamische Sicht?
Ein Aktivitätsdiagramm zeigt Verzweigungen, Wiederholungen und Parallelität auf einen Blick, nutzt eine genormte Sprache und macht Lücken sichtbar. Strukturdiagramme wie Klassen-, Objekt-, Komponenten-, Verteilungs- und Paketdiagramm zeigen die statische Sicht, Verhaltensdiagramme wie Aktivitäts-, Anwendungsfall-, Zustands- und Sequenzdiagramm die dynamische. siehe Abschnitt „Diagramm zur Verhaltensmodellierung“
- Wie formulierst Du Bedingungen für Zahlenbereiche so, dass jeder Wert genau einen Weg nimmt?
Du legst die Bereiche lückenlos und ohne Überschneidung fest und prüfst besonders die Grenzwerte, z. B. mit [< 20 %] und [>= 20 %]. Ein Zahlenstrahl hilft, den letzten Fall kannst Du [else] nennen. siehe Abschnitt „Kontrollstrukturen“
- Wie modellierst Du eine Zählschleife, wie viele gleichartige parallele Aufgaben und wie den Aufruf einer anderen Aktivität?
Eine Zählschleife setzt den Zähler vor der Schleife, prüft [i < n] in einer Entscheidung und erhöht den Zähler am Ende des Rumpfs. Viele gleichartige Aufgaben zeichnest Du nach einer Teilung als zwei stellvertretende Zweige mit Auslassungspunkten und einer Synchronisation. Eine andere Aktivität rufst Du über eine Aktion mit Rechen-Symbol auf. siehe Abschnitt „Viele gleichartige Aufgaben parallel“ und Abschnitt „Aktivitäten einrahmen und aufrufen“
Links und weitere Informationen
zum Üben: Übungsaufgaben zum UML-Aktivitätsdiagramm und Übungsaufgabe WebApp
als Primärquelle: die UML-Spezifikation (aktuell Version 2.5.1) der Object Management Group (Definition des Standards, jedoch nicht für Endnutzer aufbereitet): https://www.omg.org/spec/UML
für den Einstieg: Martina Seidl, Marion Brandsteidl, Christian Huemer, Gerti Kappel: UML@Classroom, dpunkt Verlag, Heidelberg 2012 Gut zu lesende Einführung in die wichtigsten UML-Diagramme, Empfehlung für den Einstieg.
für Lesefaule: Die Vorlesungsreihe der Technischen Uni Wien (zu UML@Classroom) kann hier angeschaut werden (Videos, Folien): http://www.uml.ac.at/de/lernen
als Nachschlagewerk: Christoph Kecher, Alexander Salvanos: UML 2.5 – Das umfassende Handbuch, Rheinwerk Bonn 2015, ISBN 978-3-8362-2977-7 Sehr umfangreiches Nachschlagewerk zu allen UML-Diagrammen
als Cheatsheet: die Notationsübersicht von oose.de: https://www.oose.de/wp-content/uploads/2012/05/UML-Notations%C3%BCbersicht-2.5.pdf
UML und Software Engineering: Chris Rupp, Stefan Queins & die SOPHISTen: UML2 glasklar, Hanser Verlag, München 2012; ISBN 978-3-446-43057-0 Schwerpunkt: Einbindung von UML-Diagrammen in den Softwareentwicklungszyklus
Zur Zertifizierungs-Vorbereitung: M. Chonoles: OCUP 2 Certification Guide , Morgan Kaufmann Verlag, Cambridge 2018, ISBN 978-0-12-809640-6 Informationen zur Zertifizierung nach OMG Certified UML Professional 2™ (OCUP 2™): Foundation Level
Software zur Erzeugung von UML-Aktivitätsdiagrammen
PlantUML: Deklaratives UML-Tool, das in vielen Entwicklungsumgebungen integriert ist, auch als Web-Editor verfügbar. Die meisten Diagramme dieses Artikels wurden damit erzeugt – eine detaillierte Anleitung für plantUml mit den Quelltexten findet sich hier
WhiteStarUML (Relativ umfangreiches Tool, viele UML-Diagramme, mit Code-Generierung für Java, C, C# und Vorlagen für Entwurfsmuster)
draw.io: Online-Tool für Flussdiagramme usw. – aber eben auch für UML
Hinweis zur Nachnutzung als Open Educational Resource (OER)
Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “UML-Aktivitätsdiagramm” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/uml-aktivitaetsdiagramm veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/uml/uml-diagramme. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 29.10.2026.
[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]
