Aktivitätsdiagramme
Folien
Falls keine PDF-Präsentation zu sehen ist: Direktdownload der PDF-Präsentation
Zielsetzung
Aktivitätsdiagramme sollen die Abläufe im System veranschaulichen. Grundlage ist (theoretisch) die Use-Case-Beschreibung; jeder Use-Case erhält ein Aktivitätsdiagramm.
Aktivitätsdiagramme und Struktogramme sind sich sehr ähnlich; Struktogramme werden weniger in der Praxis, dafür um so mehr im Informatikunterricht eingesetzt, weil sie sehr eingängig sind und durch ihre strenge Linearität etwas leichter zu überblicken.
Aktivitäten, Aktionen, Kanten
Unter Aktionen verstehen wir elementare Vorgänge im System. Aktionen werden in Aktivitäten zusammengefasst. Verbindungen zwischen den "Knoten" des Diagramms (Aktionen, Kontrollelemente, Objekte ...) werden durch "Kanten" (i.d.R. Pfeile) dargestellt. Diese Kanten zeigen die Richtung, in der der Prozess verläuft.
Es spielt keine Rolle, ob man sich in die Vertikale oder die Horizontale entwickelt. Wesentlich ist die Linearität des Ablaufs: Ich gehe zum Fenster, öffne das Fenster und gehe zu meinem Platz zurück. Das ist die Aktivität "Fenster öffnen", die aus den genannten drei Aktionen besteht.
Startpunkt, Endpunkt, Token-Konzept
Beginn und Ende werden durch einen ausgefüllten Punkt (Beginn der Aktivität) bzw. durch einen ausgefüllten, von einem Kreis umgebenen Punkt (Ende der Aktivität) markiert. Der Punkt stellt ein "Token" dar. Wir stellen ihn uns als Markierung für die aktuelle Aktion vor: Der Punkt wandert durch die einzelnen Aktionen entlang der Pfeile.
Entscheidung
Verzweigungen werden in Aktivitätsdiagrammen durch Rauten angezeigt. Die Bedingung, die zur Auswahl führt, muss textlich vorgegeben sein:
Splitter, Synchronisierer
Sie teilen den Programmfluss in parallele Abläufe auf bzw. führen parallele Abläufe zusammen.
Objekte und Objektfluss
Es kann sinnvoll sein anzuzeigen, wenn durch Aktionen oder Aktivitäten ein Objekt erzeugt wird oder sich ändert. Hier sind nicht alle Tools UML-konform, mögliche Darstellung:
Beispiel: Userregistrierung
Im folgenden Beispiel sind die zentralen, oben dargestellten Elemente von Aktivitätsdiagrammen dargestellt.
Wann braucht man Aktivitätsdiagramme und wie genau sollen sie sein?
Hierzu ein hübsches Beispiel von highscore.de, wo es diverse ziemlich gute informationstechnologische (Grundlagen-)Tutorials gibt:
So schön und einleuchtend Aktivitätsdiagramme auch sein mögen, so sind es doch nur Hilfsmittel, um sich einen Überblick über komplexe Abläufe vor der Programmierung zu verschaffen. Um die Programmierung dieser Abläufe kommen Sie nicht herum. Viele Entwickler haben daher Schwierigkeiten, sich mit der UML anzufreunden: Es scheint als macht man alles doppelt. Zuerst zeichnet man Abläufe in Aktivitätsdiagrammen auf, danach muss man sie in einer Programmiersprache nochmal erstellen.
Das Aktivitätsdiagramm der UML ist ein Hilfsmittel, um Abläufe schrittweise und übersichtlich darzustellen. Das bedeutet jedoch nicht, dass Sie nun alles, was Sie finden können, in Aktivitätsdiagrammen darstellen sollen. Wenn Ihnen bestimmte Abläufe auch ohne Aktivitätsdiagramm klar sind, brauchen Sie natürlich kein Aktivitätsdiagramm erstellen. Wenn Sie jedoch vor der Eingabe der ersten Zeile des Quellcodes alle komplizierten Abläufe durch Aktivitätsdiagramme dargestellt und durchdacht haben, brauchen Sie bei der Programmierung nur noch Ihre Aktivitätsdiagramme in die Programmiersprache übersetzen. Alle Probleme und Schwierigkeiten wurden ja bereits vorher gelöst.