Modellbasierte Anforderungsspezifikation sicherheitskritischer ...

Der Subprozess beginnt mit der Aktivität „Testlauf gegen Testfälle durchführen” und setzt damit
Testziel A um. Wurde hierbei festgestellt, dass das modellierte Verhalten nicht den in den Szenarien
spezifizierten Systemreaktionen entspricht, wird der Subprozess beendet. In der übergeordneten
Phase muss dann die Inkonsistenz zwischen Szenarien und Verhaltensmodell behoben
werden.
War der Test jedoch erfolgreich, wird auf Basis des gesamten bis zum momentanen Zeitpunkt
modellierten Verhaltens die Testfallgenerierung angestoßen. Die dabei erzeugten Szenarien werden
einem Review unterzogen und mit der bereits bestehenden Menge an Szenarien abgeglichen.
Sollten sich dabei neue Szenarien ergeben, wird dies ebenfalls der übergeordneten Phase
angezeigt und in deren weiteren Abläufen berücksichtigt. Diese Aktivität setzt damit das Testziel
B um.
Der Review der generierten Szenarien und deren Integration in die bestehende Menge an Szenarien
erfolgt dabei zurzeit durch einen rein manuellen Vergleich der einzelnen Szenarien. Dies
ist für größere Mengen an Testfällen, wie sie bereits bei mäßig komplexen Systemen entstehen
können, kaum praktikabel. Daher sollte in weiteren Forschungsarbeiten eine Möglichkeit zum
teilautomatisierten Abgleich zwischen neu generierten Testfällen und der bereits existierenden
Testfallbasis erörtert werden. Als erster Schritt könnte ein automatischer Abgleich eines neuen
Szenarios mit den bereits bestehenden Szenarien über eine einfache Vergleichsfunktion durchgeführt
werden. Damit könnte schneller erkannt werden, ob ein durch die Testfallgenerierung
ermitteltes Szenario bereits in der Menge der Szenarien enthalten ist oder nicht. Eine mögliche
Implementierung zeigt die Funktion „Sequence Diagram Compare” von IBM/telelogic Rhapsody,
die zwei Sequenzdiagramme vergleicht und das Ergebnis durch farbige Markierungen darstellt.
Abbildung 6.24 zeigt das Ergebnis eines solchen Vergleichs. Eine mögliche Weiterentwicklung
dieser Funktion könnte dann automatisiert größere Mengen von Sequenzdiagrammen vergleichen
und Unterschiede entsprechend melden.
6.4.6. S6 - Systemverhalten verifizieren
Eine weitere Möglichkeit zur Prüfung des Systemverhaltens besteht in der Anwendung eines
Model-Checkers zur formalen Verifikation des Verhaltensmodells. Dabei wird das Verhalten eines
Systems gegen eine Spezifikation verglichen, die aus einzelnen Sicherheits- oder Lebendigkeitsbedingungen
besteht. Sicherheitsbedingungen beschreiben dabei Systemzustände, die vom
System niemals eingenommen werden dürfen. Lebendigkeitsbedingungen prüfen hingegen, ob
das System einen bestimmten - beispielsweise betriebswichtigen - Zustand überhaupt erreicht.
Im Gegensatz zum Testen überprüft der Model-Checker dabei den gesamten Zustandsraum des
Systems und somit das gesamte Verhalten auf Konformität mit der Spezifikation. Mit Model-
Checking kann daher ein Korrektheitsnachweis auf dem Niveau eines mathematischen Beweises
durchgeführt werden [CGP00, S. 1].
Grundsätzlich gibt es jedoch deutliche Einschränkungen bezüglich der Komplexität des zu prüfenden
Systems, da Modellchecker systembedingt dem Problem der so genannten Zustandsraumexplosion
unterworfen sind. Dieses Phänomen bezeichnet das rasche Anwachsen des Speicherbedarfs,
insbesondere bei Systemen mit nebenläufigen Prozessen, das bereits bei mäßig komplexen
Systemen zur Nicht-Anwendbarkeit des Model-Checking führen kann [ARA05, S. 152 ff.].
Das Ergebnis des Model-Checkings ist entweder die Aussage, dass das Verhaltensmodell die Spezifikation
nicht verletzt, oder aber ein Gegenbeispiel, das diejenige Folge von Stimuli zeigt, die
zu einer Verletzung der Randbedingungen führen. Arabestani [ARA05] zeigte in seiner Arbeit,
wie sich diese Technologie prinzipiell auf ingenieurwissenschaftliche Problemstellungen anwenden
lässt.
138