Modellbasierte Anforderungsspezifikation sicherheitskritischer ...

5.1.4.4.4. Aktionssprachen
In den Diagrammen der Systemverhaltenssicht kann ein Teil der zur Ausführbarkeit nötigen
Informationen direkt durch die grafischen Sprachelemente der UML/SysML ausgedrückt werden.
Vergleicht man Aktivitäts- und Zustandsdiagramme hinsichtlich dieser Eigenschaft, zeigt
sich, dass Aktivitätsdiagramme durch das Konzept der actions (Aktionen) [OMG07-2, S. 219 ff.]
dabei eine höhere semantische Abdeckung aufweisen. Bei Aktionen handelt es sich um vordefinierte
Verhaltenselemente für bestimmte Routineaufgaben, beispielsweise existieren Aktionen
für das Lesen und Schreiben von Attributen, das Senden und Empfangen von Nachrichten und
für Entscheidungs- und Verzweigungskonstrukte. Die Verwendbarkeit dieser Sprachelemente für
ausführbare Modelle ist allerdings stark davon abhängig, ob und ggf. für wie viele der Standard-
Aktionen das gewählte Modellierungswerkzeug eine Code-Erzeugung unterstützt. So implementiert
das verwendete IBM/telelogic Rhapsody nur einen Bruchteil der in UML und SysML definierten
Aktionen.
Existieren für bestimmte Teile des Zielverhaltens keine grafischen UML/SysML-Sprachkonstrukte,
müssen die nötigen Informationen anderweitig ausgedrückt werden. In vielen Modellierungswerkzeugen
geschieht dies durch Fragmente der gewählten Ausführungs-Zielsprache, also z.B.
durch entsprechenden C++-Code, der bestimmten Modellelementen (beispielsweise als guard
einer Transition) zugeordnet wird.
Dies ist in mehrfacher Hinsicht ungünstig:
• Das Modell wird somit auf eine Ausführungs-Zielsprache festgelegt. Möchte man das gleiche
Modell in eine andere Sprache - wie z.B. Java - übersetzen, müssen alle händisch
eingefügten Statements der einen Zielsprache aufwändig durch die entsprechenden Äquivalente
der anderen Sprache ersetzt werden. Damit wird nicht nur der eigentlich abstrakte,
grafische Modellierungsansatz der UML/SysML durchbrochen, sondern auch eine Möglichkeit
für zusätzliche Modellierungsfehler geschaffen.
• Der Modellierer wird dazu gezwungen, sich Kenntnisse der jeweiligen Zielsprache anzueignen,
damit er die erforderlichen Sprachausdrücke erstellen kann. Dies mag zwar im
Bereich der Softwareentwicklung vertretbar sein, ist aber im Bereich der Anforderungserstellung
für Systeme besonders ungünstig. Der Modellbearbeiter ist dort meist mehr mit
der zugehörigen Fachdomäne als mit Programmiersprachen vertraut.
• Selbst bei prinzipiellen Kenntnissen über die Zielsprache verwenden viele Modellierungswerkzeuge
umfangreiche Frameworks, um den UML/SysML-Sprachumfang abzubilden.
Daher ist nicht nur Wissen über die Zielsprache an sich erforderlich, sondern auch über
deren konkrete Verwendung in der werkzeugspezifischen Systemumgebung.
Dieses grundsätzliche Problem der UML/SysML ist in dieser Form durchaus bekannt, so dass
verschiedene Ansätze zur Lösung entwickelt wurden. Diese lassen sich grob in zwei Gruppen
einteilen: Zum einen in Ansätze zur Entwicklung einer zielsprachenunabhängigen Aktionssprache
und zum anderen in die Einführung des Aktionskonzeptes in der UML 2.0. Zur ersten Gruppe
zählen Ideen zur Erweiterung bestehender Sprachen, beispielsweise in Form einer Erweiterung
der objects constraint language (OCL, [OMG06-1]) zur OCL4X [JZM07], oder auch komplett neu
entwickelte Sprachen [MTA98, DOU01]. Allerdings wird durch dieses Vorgehen lediglich die
Problematik der Abhängigkeit von einer spezifischen Zielsprache und zur Werkzeugumgebung
gelöst. Der Modellbearbeiter muss dennoch die jeweilige Spezifikationssprache zusätzlich zur
UML-Notation beherrschen.
Daher erscheint es aus Sicht der Anwendungsdomain sinnvoller, wo immer es möglich ist, das
UML/SysML-Aktionskonzept zu verwenden, um möglichst wenig Berührungspunkte zur darunter
liegenden Zielsprache und zum Werkzeug-Framework zu erzeugen. Im Rahmen dieser Arbeit
58