Modellbasierte Anforderungsspezifikation sicherheitskritischer ...

hat beispielsweise Arabestani in [ARA05] durchgeführt. Die Aktivitätsdiagramme verwenden
eine Mischung aus dem Tokentransport der Petri-Netze [OMG07-2, S. 295] und einer Datenflussnotation
(ObjectFlows, [OMG07-2, S. 386]). Dabei hinkt die wissenschaftliche Aufarbeitung
der Semantik von Aktivitätsdiagrammen hinter der beschriebenen pragmatisch-technischen Umsetzung
durch die Werkzeughersteller und dem erreichten Arbeitsstand bei den Zustandsautomaten
hinterher. Neben dem generellen Ansatz des UML Semantics Project werden in diversen
Forschungsarbeiten zurzeit dedizierte Ansätze für eine formale Definition von Aktivitätsdiagrammen
beschrieben. Dabei werden verschiedene Strategien verfolgt: So wird beispielsweise
versucht, die Aktivitätsdiagramme in Petri-Netze zu transformieren [STÖ04]. Andere Ansätze
basieren auf der Verwendung von kleinen, virtuellen Maschinen zum Ausführen der einzelnen
Aktivitäten, wobei hierbei meist nur eine Teilmenge der Sprachelemente von Aktivitätsdiagrammen
implementiert wird [VIK05]. Wieder andere Autoren versuchen Aktivitätsdiagramme durch
Zustandsmaschinen auszudrücken, wobei oftmals aber nur UML 1.5-konforme Sprachkonstrukte
verarbeitet werden können. Eshuis beschreibt in [ESW01] eine formale Semantik für Aktivitätsdiagramme
und zeigt in [ESH06], dass sich aus Aktivitätsdiagrammen Eingangsdaten für den
symbolischen Model-Checker NuSMV erzeugen lassen, womit auch das in Aktivitätsdiagrammen
beschriebene Verhalten formal verifizierbar wird.
Eine idealisierte Zielvorstellung - als Fortführung der genannten Arbeiten - wäre eine formal
fundierte Semantik für Aktivitätsdiagramme analog [ARA05]. Die Semantik müsste die direkte
Ausführbarkeit von Aktivitätsdiagrammen sowie deren Einsatz für Testfallausführung, Testfallgenerierung
und formale Verifikation ermöglichen. Jedoch erscheint es für den Bereich der
Anforderungsmodellierung vertretbar, bereits jetzt die Vorteile der in zahlreichen Werkzeugen
implementierten Codeerzeugung für Aktivitätsdiagramme auch ohne strikte Semantikdefinition
zu nutzen. Zuvor sollte jedoch in gesonderten Arbeiten das aus unzureichend formal definierter
Codeerzeugung entstehende Risiko analysiert werden.
Neben diesen Differenzen im Grad des Formalismus unterscheiden sich Zustandsmaschinen und
Aktivitätsdiagramme auch aus Sicht der Modellierung und damit auch die Anwendungsschwerpunkte
beider Beschreibungsmittel. Die folgende Auflistung differenziert die wichtigsten Unterschiede
aus einer pragmatischen Sicht auf die Modellierung:
(a) Bei Zustandsautomaten liegt der Schwerpunkt auf den Zuständen, in denen sich die zugehörigen
Komponenten (Klassen, Blöcke, Systeme, etc.) befinden sowie auf den Transitionen
(optional mit Ereignis, Bedingung und auszuführender Aktion), die Zustandsänderungen
darstellen. Daher eignen sich Zustandsautomaten gut für die Beschreibung von
Systemen, für die sich diskrete Zustände ermitteln lassen. Für eine weiterführende, detaillierte
Beschreibung der Möglichkeiten und der Syntax von Zustandsmaschinen sei auf
[WEI06, S. 272 ff.] und [OMG07-1, S. 519, ff.] verwiesen.
(b) Aktivitätsdiagramme sind im Gegensatz zu den Zustandsmaschinen geeigneter für ablauforientierte
Beschreibungen, ähnlich z.B. Flussdiagrammen. Einzelne Aktivitäten repräsentieren
nicht zwangsläufig einen bestimmten Systemzustand und die Übergänge zwischen
zwei Aktivitäten sind nicht zwangsweise an das Auftreten von Ereignissen gebunden. Außerdem
können Aktivitäten in der SysML-Version von Aktivitätsdiagrammen auch kontinuierlich
ablaufen, wenn beispielsweise Stoff- oder Informationsflüsse (Luft, Wasser, Datenströme,
etc.) modelliert werden sollen. Weiterhin kann in Aktivitätsdiagrammen durch
das Konstrukt der Objektflüsse auch der Austausch von Daten zwischen den einzelnen Aktivitäten
explizit dargestellt werden. Weitere Informationen über die Aktivitätsdiagramme
finden sich in [WEI06, S. 251 ff.], in [OMG07-1, S. 85 ff.] und in [OMG07-2, S. 295 ff.].
Während der Modellierung im Rahmen dieser Arbeit hat sich gezeigt, dass Aktivitätsdiagramme
wegen der in (b) genannten Eigenschaften für anforderungsbezogene Problemstellungen übli-
55