Aktivitätsdiagramm

Ein Aktivitätsdiagramm ist ein Diagramm der UML, mit dem du Abläufe und Geschäftsprozesse modellierst. Es zeigt, welche Schritte nacheinander passieren, wo Entscheidungen getroffen werden, wann Schleifen entstehen und welche Aktivitäten parallel laufen können.

In der IT-Ausbildung ist das Aktivitätsdiagramm besonders hilfreich, wenn du Prozesse beschreiben, Anforderungen strukturieren oder Abläufe für eine Anwendung vorbereiten musst. Es passt zu Aufgaben in der AP Teil 1, zur fachrichtungsspezifischen AP Teil 2 und zur Projektdokumentation, wenn du einen Ist- oder Soll-Prozess verständlich darstellen willst.

Was ein Aktivitätsdiagramm zeigt

Ein Aktivitätsdiagramm beschreibt Verhalten. Es beantwortet also nicht primär die Frage, welche Klassen oder Datenobjekte existieren. Dafür eignen sich eher ein Klassendiagramm oder ein Entity-Relationship-Modell. Stattdessen geht es um den Ablauf:

• Wo beginnt der Prozess?
• Welche Aktionen werden ausgeführt?
• Welche Bedingungen steuern den weiteren Weg?
• Gibt es Wiederholungen oder alternative Pfade?
• Können Schritte parallel ablaufen?
• Wer oder welches System ist für einzelne Schritte verantwortlich?
• Wo endet der Prozess?

Damit ist das Aktivitätsdiagramm eine gute Brücke zwischen fachlicher Beschreibung und technischer Umsetzung. Es ist detaillierter als eine reine Stichpunktliste, aber oft verständlicher als direktes Programmieren.

Grundelemente eines Aktivitätsdiagramms

Die wichtigsten Elemente solltest du in der Prüfung sicher erkennen und verwenden können.

Ein Aktivitätsdiagramm muss nicht jedes technische Detail enthalten. Es sollte genau so detailliert sein, dass der Prozess nachvollziehbar wird und die geforderten Entscheidungen sichtbar sind.

Beispiel: Bestellung prüfen

Ein einfacher Prozess in einem Online-Shop könnte so aussehen:

1. Bestellung eingeht
2. Kundendaten prüfen
3. Lagerbestand prüfen
4. Falls Artikel verfügbar sind: Zahlung anstoßen
5. Falls Zahlung erfolgreich ist: Bestellung freigeben
6. Falls Artikel nicht verfügbar oder Zahlung fehlgeschlagen ist: Kunde informieren
7. Prozess beenden

In einem Aktivitätsdiagramm würdest du dafür Startknoten, Aktionen, Entscheidungsknoten und Endknoten verwenden. Die Bedingungen an den Entscheidungspfeilen könnten zum Beispiel [Artikel verfügbar], [Artikel nicht verfügbar], [Zahlung erfolgreich] und [Zahlung fehlgeschlagen] heißen.

Wenn Lagerprüfung und Kundendatenprüfung unabhängig voneinander laufen können, könntest du sie mit einem Fork parallel starten und später mit einem Join wieder zusammenführen. Damit zeigst du nicht nur Reihenfolge, sondern auch mögliche Parallelität.

Entscheidungen und Bedingungen

Entscheidungen werden im Aktivitätsdiagramm mit Rauten modelliert. Von einer Entscheidung gehen mehrere ausgehende Pfade ab. Jeder Pfad sollte eine Bedingung haben.

Beispiel:

Wichtig ist, dass Bedingungen eindeutig und vollständig sind. Wenn nur ein Pfad beschriftet ist, bleibt oft unklar, wann der andere Pfad genommen wird. In Prüfungen kostet das schnell Punkte, weil der Kontrollfluss nicht sauber begründet ist.

Schleifen modellieren

Schleifen entstehen, wenn ein Ablauf zu einem früheren Schritt zurückführt. Ein typisches Beispiel ist die Eingabeprüfung:

• Nutzer gibt Daten ein.
• System prüft die Eingabe.
• Wenn die Eingabe gültig ist, geht der Prozess weiter.
• Wenn die Eingabe ungültig ist, wird eine Fehlermeldung angezeigt und die Eingabe erneut angefordert.

In einem Aktivitätsdiagramm wird das durch einen Pfeil zurück zu einer vorherigen Aktivität modelliert. Die Bedingung am Rücksprung sollte klar benannt sein, zum Beispiel [Eingabe ungültig].

Parallelität mit Fork und Join

Aktivitätsdiagramme können parallele Abläufe darstellen. Dafür werden Fork- und Join-Knoten genutzt.

Ein Fork teilt den Kontrollfluss in mehrere parallele Pfade. Ein Join führt diese Pfade wieder zusammen. Das ist sinnvoll, wenn Schritte unabhängig voneinander durchgeführt werden können, aber später ein gemeinsames Ergebnis benötigt wird.

Beispiel aus einem IT-Projekt:

• Testumgebung vorbereiten
• Testdaten importieren
• Testfälle aktualisieren

Diese Arbeiten können teilweise parallel laufen. Erst wenn alle abgeschlossen sind, beginnt der eigentliche Abnahmetest. Genau diesen Zusammenhang kann ein Aktivitätsdiagramm gut sichtbar machen.

Swimlanes für Zuständigkeiten

Swimlanes teilen ein Aktivitätsdiagramm in Verantwortungsbereiche auf. Jede Aktivität liegt dann in der Lane der Rolle, Abteilung oder des Systems, das sie ausführt.

Typische Swimlanes sind:

• Kunde
• Webanwendung
• Warenwirtschaft
• Zahlungsdienstleister
• Support

Swimlanes sind besonders nützlich, wenn Prozesse über mehrere Rollen laufen. In einer Projektdokumentation kannst du damit zeigen, wo Medienbrüche entstehen, welche Schritte automatisiert werden und welche Aufgaben weiterhin manuell bleiben.

Aktivitätsdiagramm vs. Programmablaufplan

Ein Aktivitätsdiagramm ähnelt einem Programmablaufplan, ist aber nicht identisch.

Für einfache Algorithmen kann Pseudocode schneller sein. Für Geschäftsprozesse mit Rollen, Systemen und alternativen Wegen ist ein Aktivitätsdiagramm meistens verständlicher.

Typische Prüfungsaufgaben

In Prüfungen werden Aktivitätsdiagramme meist praxisnah abgefragt. Es geht selten darum, einen UML-Standard auswendig zu reproduzieren. Wichtiger ist, dass der Ablauf fachlich korrekt und eindeutig ist.

Typische Aufgaben:

• Aus einer Prozessbeschreibung ein Aktivitätsdiagramm erstellen
• Fehlende Entscheidungspfade ergänzen
• Bedingungen an Verzweigungen formulieren
• Parallel ablaufende Schritte erkennen
• Swimlanes passenden Rollen zuordnen
• einen Prozess fachlich erklären oder verbessern
• ein Diagramm mit Pseudocode oder einem Textablauf vergleichen

Gerade in der AP Teil 1 können Aktivitätsdiagramme in Konstruktionsaufgaben vorkommen. In der AP2 und im Projektteil sind sie hilfreich, um Abläufe sauber zu dokumentieren.

Häufige Fehler

Viele Aktivitätsdiagramme sind schwer lesbar, weil sie entweder zu grob oder zu technisch werden.

Häufige Fehler:

• Es fehlt ein klarer Start- oder Endknoten.
• Bedingungen an Entscheidungspfaden sind unvollständig.
• Aktionen sind als Zustände formuliert, nicht als Tätigkeiten.
• Pfeile kreuzen sich unnötig und machen den Ablauf schwer lesbar.
• Parallelität wird mit einfachen Verzweigungen verwechselt.
• Swimlanes werden genutzt, aber Aktivitäten liegen in der falschen Zuständigkeit.
• Ausnahmen und Fehlerfälle werden komplett weggelassen.
• Das Diagramm zeigt Implementierungsdetails, obwohl ein fachlicher Prozess gefragt war.

Gute Aktivitätsdiagramme verwenden kurze, aktive Formulierungen wie “Bestellung prüfen”, “Zahlung anfordern” oder “Fehlermeldung anzeigen”. Dadurch bleibt der Prozess auch ohne lange Erklärung verständlich.

Checkliste für dein Aktivitätsdiagramm

Prüfe dein Diagramm vor der Abgabe mit diesen Fragen:

• Gibt es genau erkennbare Start- und Endpunkte?
• Ist jede Aktivität als konkrete Handlung formuliert?
• Sind alle Entscheidungspfade mit Bedingungen beschriftet?
• Führen alternative Pfade sinnvoll wieder zusammen oder zu einem Ende?
• Sind Schleifen eindeutig erkennbar?
• Wird Parallelität nur dort verwendet, wo sie fachlich stimmt?
• Sind Swimlanes korrekt und hilfreich?
• Ist der Ablauf ohne zusätzliche Erklärung nachvollziehbar?
• Passt die Detailtiefe zur Aufgabe oder Projektdokumentation?

Wenn du diese Punkte erfüllst, ist dein Aktivitätsdiagramm fachlich klar und gut prüfbar.