Fortgeschrittene Modellierungsnotationen des UML Aktivitätsdiagramms

UML Aktivitätsdiagramm

https://oer-informatik.de/uml-aktivitaetsdiagramm-objektflusse-unterbrechbare-bereiche

https://bildung.social/deck/@oerinformatik/117437715609630035

tl/dr; (ca. 6 min Lesezeit): Nach den einfachen Grundlagen des UML-Aktivitätsdiagramms erarbeiten wir uns jetzt das Handwerkszeug, um tatsächlich komplexe Zusammenhänge modellieren zu können: Objektflüsse, Vor- und Nachbedingungen, unterbrechbare Bereiche für Exceptions: In diesem Artikel geht es um die Feinheiten, die aus einem Flussdiagramm wie jedes andere ein relevantes Tool für Fachinformatiker*innen machen! (Zuletzt geändert am 14.10.2026)

Dieser Artikel ist Teil einer Artikelreihe über UML-Aktivitäts-Diagramme: Aktivitätsdiagramm Grundlagen, Entwurf digitalisierter Geschäftsprozesse mithilfe des Aktivitätsdiagramms, Übungsaufgaben zum Aktivitätsdiagramm und Hinweise zur Erzeugung von Diagrammen mit PlantUML.

Vor- und Nachbedingungen

Manchmal ist ein Modell leichter verständlich, wenn explizit formuliert wird, welche Vor- und Nachbedingungen man bei Aktionen oder Aktivitäten erwartet. Hierbei handelt es sich nicht um zwingende Bedingungen (wie bei Guards), die den Ablauf steuern. Vielmehr handelt es sich um Behauptungen, was der Modellierende vor bzw. nach einer Aktion erwartet. Im Fall einer Aktion wird mit einer Notiz mit dem Stereotyp <<localPrecondition>> beschrieben, was vor Ausführung dieser Aktion erfüllt sein soll. <<localPostcondition>> beschreibt, was nach< Ausführung der Aktion erfüllt sein soll. Die Notizen werden mit gestrichelter Linie an die Aktion gebunden.

Die Bedingungen sind nicht zwingend und es gibt keine Festlegung, was bei Nichterfüllung passiert.

Analog zu den Vor- und Nachbedingungen einer Aktion gibt es auch Vor- und Nachbedingungen von Aktivitäten (precondition und postcondition), die im Aktivitätsrahmen notiert werden - Details dazu bei Bedarf in der Spezifikation.¹

Objektflüsse darstellen

Bei einfachen Aktivitätsdiagrammen symbolisiert ein Pfeil die Richtung des Kontrollflusses: der Token, der aktive Aktionen markiert wandert von einer Aktion zur nächsten. Anstelle eines abstrakten Tokens können auch Objekte von einer Aktion zur nächsten übergeben werden und darüber implizit auch der Kontrollfluss übergeben werden. Dies kann auf unterschiedliche Arten umgesetzt werden:²

Neben Aktionen können auch Objektknoten (als Rechteck) dargestellt werden. An den ein- und ausgehenden Kanten wird anstelle eines abstrakten Tokens dann ein Objekt transportiert. Die Aktion “Anforderung dokumentieren” erzeugt ein Objekt (Lastenheft), das mit dem Kontrollfluss an die Aktion “Pflichtenheft erstellen” übergeben wird. Lastenheft ist somit Rückgabewert der ersten Aktion und wird von der zweiten Aktion als Eingabewert (Parameter) entgegengenommen. Die Kanten stellen in diesem Fall einen Objektfluss dar, ein eintreffendes Objekt (Daten-Token) startet die Aktion wie ein Kontrollflusstoken.

Anstelle des Objektknotens kann der Objektfluss auch über die Pin-Notation dargestellt werden: hier ist nicht das Objekt selbst im Fokus, sondern die Fähigkeit Ausgabewerte zu erzeugen und Parameter zu übernehmen: wenn am Ausgang und am Eingang der Aktionen jeweils Pins andeuten, dass hier ein Objekt gesendet / empfangen wird, stellt die Kante dazwischen ebenso den Objektfluss dar. Die Pins können optional mit dem Namen des gesendeten Objekts benannt werden, was in der Regel genutzt wird, wenn der Datentyp nicht aus dem Kontext der Aktion eindeutig hervorgeht.

Um ein Diagramm kompakt zu halten, kann man Pins und Objekt auch weglassen: die Kante wird in diesem Fall mit einem Quadrat notiert. Auch hier kann der Name des Objekts angegeben werden, um für Klarheit zu sorgen.

Signale / Ereignisse senden und empfangen

Der Kontrollfluss beginnt normalerweise zu Aktivitätsbeginn in einem Startknoten. Doch auch eingehende Signale können einen Kontrollfluss starten: in einer accept event action kann ein eintreffendes Signal einen Token generieren. Signale stammen häufig von externen Akteuren oder können von unterschiedlichen Quellen stammen, so dass eine Modellierung als Objektknoten nicht möglich ist. Die Signaleingangs-Knoten tragen den Namen des eingehenden Signals (Beispiel unten: HTTP-POST-Request) und werden als Rechteck mit einer herausgeschnittenen Spitze notiert.³

Signale können auch aus einer Aktivität heraus gesendet werden. Erreicht ein Kontrollflusstoken die send signal action wird asynchron das Signal gesendet (Beispiel unten: HTTP-Response) - auf eine Antwort oder Empfangsbestätigung wird nicht gewartet. Die Knoten des Signal-Sendens tragen den Namen des ausgehenden Signals und werden als Rechteck mit einer angeklebten Spitze notiert.⁴

Sofern dieser Signalempfängerknoten auch eingehende Kanten hat, wird der ausgehende Token nur gefeuert, wenn ein Token eingetroffen ist und dann ein Signal eingeht (es wird also das Signal und der Kontrollflusstoken synchronisiert). Ob zuvor eingegangene Signale im Event-Pool gepuffert werden, regelt der Standard nicht, das muss im Zweifel explizit im Diagramm benannt werden.⁵ Umgekehrt wird bei ausgehenden Signalen nicht auf eine Antwort gewartet, sondern es wird unmittelbar die im Kontrollfluss nächste Aktion gestartet.

Wichtig ist bei der oben stehenden Aktivität, dass das gesendete Signal (HTTP-POST-Request) nicht an den Empfänger gesendet wird - der Pfeil symbolisiert hier nur den Kontrollfluss. Der Empfänger wartet auf ein anderes Signal (HTTP-Response). Da der Empfänger nur dann einen Token feuert, sofern neben einem HTTP-Response auch bereits ein Token an einer eingehenden Kante ankommt, lösen vor dem Token eintreffende Signale zunächst keine weitere Verarbeitung aus.

Eine spezialisierte Art eines Signalempfangs (accept event action) ist das Zeitsignal. Hier wird auf kein externes Signal gewartet, sondern ein Zeitevent (Zeitpunkt, Dauer) löst das Token aus. Bei eingehenden Kanten ist auch hier ein Token am Eingang erforderlich.

Betrachten wir die drei Abläufe gemeinsam, wird zum einen deutlich, dass beim Eintreffen eines Tokens an einem Aktivitätsende ( activity final node) des Clients die Gesamtaktivität beendet wird: der Aktivitäts-Endknoten konsumiert alle Token in der Gesamtaktivität. Somit würde damit auch der Server keine Requests mehr entgegennehmen, denn die Gesamtaktivität würde beendet - In der Realität würde man daher gesonderte Aktivitäten für Server und Client modellieren oder es lösen wie beim Server: hier ist ein Ablaufende (flow final node) notiert - es wird somit nur der aktuelle Token konsumiert, es können weitere Signale eintreffen und verarbeitet werden.⁶

Parametersätze - “überladene” Aktionen

Analog zur Überladung von Methoden in der Objektorientierung können im UML-Aktivitätsdiagramm Aktionen, die mit unterschiedlichen Kombinationen an Eingabewerten ihren Nutzen erzeugen können, mit unterschiedlichen Parametern modelliert werden. Diese Kombinationen von Parametern können einen oder mehrere Parameter umfassen. Die Aktion startet, sobald eine gültige Kombination von Parametern vollständig vorliegt.⁷

Parametersätze können sich auch überschneiden - dies wird dadurch gekennzeichnet, dass die Rechtecke um die Parameter-Pins einzelne Objekt-Pins mehrfach umschließen. Im Beispiel benötigen beide Parametersätze ein Starttermin-Objekt:

Unterbrechbare Bereiche - Signale, die Aktionsabläufe beenden

Neben der Parallelisierung und den Objektflüssen ist ein weiterer Unterschied zwischen UML Aktivitätsdiagramm und Programm-Ablaufplan, dass man im Aktivitätsdiagramm auch unterbrechbare Bereiche definieren kann. Aktionen, die sich innerhalb eines mit einer gestrichelten Linie umrahmten Bereichs befinden, werden abgebrochen, wenn der Bereich über eine Kante in Blitzform verlassen wird. Häufig liegt ein Signalempfänger für das Unterbrechungssignal im umrahmten Bereich und wartet aktiv, sobald ein Token den Unterbrechungsbereich erreicht hat. Bei Eintreffen eines Unterbrechungssignals werden alle anderen Token innerhalb des Bereichs konsumiert und über die ausgehende Kante wird (Pfeil in Blitzform) ein Token oder Unterbrechungsobjekt an die Aktion außerhalb des Bereichs weitergeleitet. Es ist dann die Aktion zur Behandlung der Unterbrechung aktiv, alle Token innerhalb des gestrichelten Rahmens werden konsumiert (also auch ggf. mehrere bei Parallelisierung).⁸

In dem Beispiel erkennt man, dass ein Projekt unmittelbar abgebrochen wird, wenn von außerhalb (Lenkungsausschuss) ein Signal zum Projektabbruch (Anweisung zum vorzeitigen Projektabschluss) gegeben wurde - der Lenkungsausschuss wird dieses Signal beispielsweise veranlassen, wenn die geschäftliche Rechtfertigung weggefallen ist - das wird jedoch an anderer Stelle modelliert, das Signal stammt von jenseits der Systemgrenze.

Ausnahmenbehandlung im UML Aktivitätsdiagramm (Exception Handling)

Unterbrechbare Bereiche verhalten sich ähnlich wie Exception-Handling in der Programmierung (try/catch-Bereiche) und können genutzt werden, um diese zu modellieren. Der unterbrechbare Bereich entspricht so einem try-Block. Sobald ein Unterbrechungssignal eintrifft (eine passende Exception), werden die Aktionen im unterbrechbaren Rahmen beendet. Der Signalempfänger gibt die Exception als Objekttoken an den Exception-Handler-Block weiter (im Beispiel entspricht Exception-Details loggen und die folgende Aktion dem catch-Block). Ausgabepins von Exceptions werden im Aktivitätsdiagramm mit dem Dreiecksymbol gekennzeichnet.

Sobald eine SQLTimeoutException geworfen wird, wird der Login-Prozess verlassen.

Ausnahmenbehandlung bei einzelnen Aktionen

Auch in einzelnen Aktionen können Exceptions auftreten. Die jeweiligen Handler werden jeweils per Blitzsymbol an die Aktion angebunden. Zu beachten ist hierbei aber: sobald der zur auftretenden Exception passende Handler abgearbeitet ist, kehrt der Kontrollfluss wieder an die ursprüngliche Aktion zurück und die Aktion wird über die reguläre Kante verlassen (als wäre keine Exception aufgetreten). Wird kein zur Exception passender Handler gefunden, wird die Exception an die nächsthöhere Ebene eskaliert.⁹

Ein grundlegend anderer Ablauf entsteht dann, wenn Ausnahmen als reguläre Rückgabewerte zurückgegeben werden können: Die Exception wird als normaler Objekt-Output dargestellt, der mit einem Dreieck als Exception markiert ist. Es wird nur entweder eine Exception zurückgegeben (andere Objekt-Ausgabe-Pins bleiben dann leer), oder die regulären Ausgabe-Objekte. Ausgehende Kontrollflusskanten werden jedoch auch bei Rückgabe einer Exception mit einem Token belegt. Die Exception wird von der Nachfolgeaktion als regulärer Parameter übernommen.¹⁰

Aktivitäten aus einzelnen Aktionen zusammenfassen

Im UML-Aktivitätsdiagramm besteht die Möglichkeit, einzelne Aktionen zu einer Aktivität zusammenzufassen und diese gruppiert im Diagramm als eine Aufruf-Aktion (CallBehaviorAction) anzugeben:¹¹

Darüber hinaus kann man diese Aktivität in einem gesonderten Diagramm modellieren und in der umgebenden Aktivität nur die Kurzform mit dem “Rechen/Gabel-Symbol” ausgeben:

Strukturierte Elemente als alternative Darstellungsform für Loops und bedingte Anweisungen

Neben der Variante, Schleifen und bedingte Anweisungen mit Decision- und Mergenodes darzustellen bietet das UML Aktivitätsdiagramm die Möglichkeit, strukturierte Elemente zu nutzen. Die genaue Form ist in der Spezifikation nicht vorgegeben, lediglich, welche Elemente enthalten sein müssen.¹²

Bei bedingten Anweisungen muss jeweils die Bedingung(-sprüfungsaktion) und die dann auszuführende Aktion angegeben sein - idealtypisch mit else if und else-Block:

Bei Schleifen wird jeweils eine Initialisierungsaktion, der Schleifenbody und die Wiederholungsbedingungsaktion gegeben, zusätzlich wird über ein Flag (isTestedFirst) festgelegt, ob es sich um eine kopf- oder um eine fußgesteuerte Schleife handelt:

Fazit

Die Notationsmittel, die in diesem Blog-Artikel enthalten sind, gehen schon weit über ein normales Flussdiagramm hinaus. Mit unterbrechbaren Bereichen, Objektfluss, Exceptions und strukturierten Elementen können auch sehr komplexe Abläufe gut modelliert werden.

Analog zu unserem Beispiel für ein einfaches Aktivitätsdiagramm mit OAuth2 ist hier ein komplexeres Diagramm für eine Passkey-Authentifizierung dargestellt:

Weitere Literatur zum UML-Aktivitätsdiagramm

• als Primärquelle: die UML Spezifikation der Object Management Group Definition des Standards (jedoch nicht für Endnutzer aufbereitet): https://www.omg.org/spec/UML

• für den Einstieg: Martina Siedl, 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 WebEditor verfügbar. Die obigen Diagramme 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 Flowcharts usw. - aber eben auch 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 Hannes Stein, Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/uml-aktivitaetsdiagramm-objektflusse-unterbrechbare-bereiche veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/uml/umlaktivitaet. Stand: 14.10.2026.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]