First page Back Continue Last page Overview Graphics

Aktivitätsdiagramme


Notes:

Aktivitätsdiagramme sind auf einem hohen Abstraktionsniveau und somit früh im Entwicklungsprozess bestens geeignet, um grobe Abläufe darzustellen. Ähnlich einem Flussdiagramm, aus dem es schlussendlich entwickelt wurde, zeigt es Arbeitsschritte in ihrem logischen bzw. zeitlichen Ablauf.
Während das Flussdiagramm hier nur zeitliche Abläufe berücksichtigen konnte - eine Aktion folgte auf die andere, es waren gerade einmal Entscheidungen und Schleifen möglich – ist das Aktivitätsdiagramm auch geeignet, um parallele Abläufe darzustellen. Dazu gibt es die Elemente „fork“ (einen Prozess in zwei oder mehrere nebenläufige Prozesse aufteilen) und „join“ (zwei oder mehrere nebenläufige Prozesse zu einem vereinigen).
Zum eigentlichen Codeentwurf sind Aktivitätsdiagramme aus demselben Grund weniger geeignet wie auch Flussdiagramme weniger geeignet waren: Durch die Darstellung des Ablaufes als Flusslinie wird die Darstellung unstrukturiert oder anders gesagt: Für das Implementieren eines Flussdiagrammes ist oftmals die Verwendung eines GOTO-Befehls unabdingbar. Das widerspricht dem Pragma des strukturierten Programmierens (das ja durch die Objektorientierung keinesfalls aufgegeben wurde).
Und doch hat das Struktogramm zumindest bis dato keinen Eingang in die UML gefunden. Doch hier sollte man ohne weiteres die Empfehlung Fowlers beherzigen: eine praktische Diagrammart benütze man einfach, egal ob sie im Sprachumfang enthalten ist oder nicht. So skizziert der Autor bis heute auf Routinenebene tw. vermittels Struktogrammen.