Modellbasierte Anforderungsspezifikation sicherheitskritischer ...

formal definierte Semantik für die UML bzw. SysML vorhanden ist. Die Übersetzung des Modells
in ausführbaren Code erfolgt daher auf Grundlage semantischer Definitionen, die jeder
Werkzeughersteller nach eigenem Ermessen erstellt. Gleiche Modelle können somit in unterschiedlichen
Werkzeugen zu unterschiedlichem ausführbaren Code führen. Die Schaffung einer
einheitlichen semantischen Definition der UML-Sprachelemente (die auch in der SysML weiterverwendet
werden könnte) ist jedoch Gegenstand verschiedener Forschungsvorhaben, beispielsweise
des UML Sematics Project. Eine Darstellung des aktuellen Arbeitsstandes findet sich
beispielsweise in [BCD07].
Eine stringentere Methode zur Überprüfung des Modellverhaltens ist das systematische Anwenden
von Testfällen. Dabei wird das zu untersuchende System von seiner Umgebung frei geschnitten
und die Umwelt durch die Testumgebung simuliert. Bei der Testausführung versorgt diese
den Testling mit bestimmten Stimuli und zeichnet die Reaktionen des Systems beispielsweise in
Form von Sequenzdiagrammen auf. Das Testprotokoll kann dann mit dem Soll-Verhalten verglichen
werden, wodurch sich Abweichungen übersichtlich erkennen lassen. Auf die allgemeinen
Möglichkeiten und Grenzen des Testens mit Testfällen und die konkrete Umsetzung im Rahmen
dieser Arbeit wird in Abschnitt 6.4.5 eingegangen.
Eine nochmals strengere Möglichkeit zur Überprüfung des Systemverhaltens stellt die Anwendung
des Model Checkings (Modellprüfung) dar. Dabei handelt es sich um eine Technik zur
Prüfung eines Systems aus einem endlichen Automaten [CGP00, S. 3] gegen eine formale Spezifikation.
Ergebnis dieser Prüfung ist eine ja/nein-Aussage, ob das Verhalten des Systems die
Spezifikation erfüllt oder verletzt. Auch diese Verifikationstechnik kann mit bestimmten Einschränkungen
auf ausführbare UML/SysML-Modelle angewendet werden, was in Abschnitt 6.4.6
beschrieben wird.
Zu beachten ist, dass zwischen der Systemverhaltenssicht und der Szenariensicht eine inhaltliche
Abhängigkeit besteht. Die einzelnen Szenarien stellen dabei exemplarische, kontextabhängige
Protokolle des Systemverhaltens dar, das durch die Verhaltensmodellierung bestimmt
wird. Da die Szenariensicht und die Verhaltenssicht jedoch zunächst unabhängig voneinander
erstellt werden, müssen Mechanismen vorgesehen werden, die beide Sichten inhaltlich aneinander
koppeln. Dies geschieht durch Integration von Testausführungs- und Testerzeugungstechniken,
durch die ein bidirektionaler Abgleich zwischen Szenariensicht und Verhaltenssicht
möglich wird. Dadurch kann sowohl überprüft werden, ob das Verhaltensmodell des SuB die
als Soll-Vorgabe dienenden Szenarien erfüllt, als auch, ob tatsächlich alle zur Beschreibung
des gewünschten Systemverhaltens erforderlichen Interaktionsszenarien ermittelt wurden. Diese
wechselseitige Abhängigkeit ist Grundlage der im Prozess verfolgten internen Teststrategie.
Details dazu finden sich in Abschnitt 6.4.5.
5.1.4.4.2. Diskussion des Beschreibungsmittels
Für die Verhaltensmodellierung bieten sich zwei Beschreibungsmittel an, die fast unverändert
aus der UML 2 in die SysML übernommen wurden [OMG07-1, S. 85]: Die Modellierung durch
State Machines (Zustandsmaschinen) oder die Modellierung mit Activity Diagrams (Aktivitätsdiagrammen).
Im Bezug auf die Ausführbarkeit sind beide Beschreibungsmittel als gleichwertig
anzusehen, da sowohl durch Zustandsmaschinen, als auch durch Aktivitätsdiagramme mit geeigneten
Werkzeugen ausführbare Modelle im Sinne der Definition in 5.1.4.4.1 erstellt werden
können.
Unterschiedlich ist jedoch der Reifegrad der Formalität beider Beschreibungsmittel. Die Zustandsmaschinen
der UML/SysML basieren auf den Zustandsdiagrammen von Harel [HAR87]
[OMG07-2, S. 519], für die eine formale Ausführungssemantik abgeleitet werden kann. Dies
54