Modellbasierte Anforderungsspezifikation sicherheitskritischer ...

die Szenariensicht ist: Letztere zeigt nur beispielhafte Ausschnitte des tatsächlich modellierten
Verhaltens. Ziel B zielt zudem darauf ab, implizite Annahmen während der Verhaltensmodellierung
explizit zu machen und auf Konsistenz mit dem vorgesehenen Verhalten des Systems zu
prüfen. In der Praxis wurden bei der Erstellung des Beispielmodells Fehlerszenarien für einen
„Fadenfehler Gelblicht” und einen „Fadenfehler Rotlicht” der Lichtzeichenanlage spezifiziert. In
der Verhaltenssicht war implizit jedoch auch das (korrekte) Verhalten für einen kombinierten
Fehlerfall „Fadenfehler Gelb- und Rotlicht” enthalten. Für diesen Fehlerfall wurde durch die
Analyse der Verhaltenssicht ein entsprechendes Sequenzdiagramm ermittelt, wodurch die zuvor
nur implizit vorliegende Spezifikation als Szenario explizit gemacht wurde.
Anzumerken ist, dass das beschriebene Vorgehen dann problematisch sein kann, wenn die Szenariensicht
(also die Testfälle) und die Verhaltenssicht (also der Testling) von der gleichen Person
modelliert werden. Die Gefahr besteht, dass sich ein prinzipieller Denkfehler in beiden Sichten
reproduziert und somit ein eigentlich falsches Verhalten als „korrekt” getestet wird. Auch
wenn innerhalb dieser Arbeit prinzipiell keine Aussagen über Rollen und personelle Abhängigkeiten
getroffen werden, ist es höchst sinnvoll, zumindest die Szenariensicht und die Verhaltenssicht
von zwei unterschiedlichen Personen bearbeiten zu lassen. Es ergeben sich somit für den
mikroskopischen Bereich der Anforderungserstellung zwei Rollen, die der des „Implementierers”
und der des „Testers” bei Softwareentwicklungsprozessesn entsprechen.
Um die genauen Anforderungen an diesen Prozessschritt genauer fassen zu können, werden
im folgenden Unterabschnitt 6.4.5.2 die benötigten Eigenschaften für die Testfallgenerierung
mittels einer Taxonomie genauer klassifiziert.
6.4.5.2. Klassifizierung des Verfahrens zur Testfallgenerierung
Um das benötigte Verfahren zur Testfallgenerierung genauer definieren zu können, sollen die
Anforderungen aus dem vorherigen Abschnitt gegen eine Taxonomie möglicher Verfahren evaluiert
werden. Diese Taxonomie wurde von Utting, Pretschner und Legeard in [UPL06] vorgestellt.
Sie unterscheiden dabei sieben Merkmale mit verschiedenen Ausprägungen, mit denen modellbasierte
Testsfallgenerierungsverfahren differenziert werden können. Im Folgenden werden die
für diese Arbeit relevanten Merkmale kurz vorgestellt und dabei diejenige Merkmalsausprägung
ausgewählt, die ein möglichst gut angepasstes Testfallgenerierungsverfahren beschreibt.
(a) Gegenstand des Modells [UPL06, S. 4/5] - Dieses Merkmal beschreibt, ob das Modell eher
das Verhalten des zu testenden Systems darstellt oder eher das Verhalten der Systemumgebung.
Diese Differenzierung ist entscheidend für die Strategie der Testfallgenerierung.
Für das hier angewendete und oben beschriebene Vorgehen zur Testfallerzeugung ist das
Verhalten des Systems maßgeblich. Das gewählte Werkzeug muss also die Analyse des
Systemmodells unterstützen.
(b) Modellredundanz [UPL06, S. 5/6] - hierbei wird zwischen dem Fall separater Modelle für
Implementierung und Testfallgenerierung und dem Fall eines gemeinsamen Modells für
beide Aufgaben unterschieden. Im vorherigen Abschnitt wurde dargelegt, dass die Tests
innerhalb eines Modells durchgeführt werden sollen. Demnach liegt hier der Fall eines
gemeinsamen Modells vor, den das Werkzeug beherrschen können muss.
(c) Modellcharakteristik [UPL06, S. 6] - das Merkmal dient der Unterscheidung der Charakteristiken
eines Modells im Bezug auf Determinismus seiner Ausgaben, der Berücksichtigung
von Echtzeitanforderungen sowie der Unterscheidung von diskreten und kontinuierlichen
Systemen. Für Anforderungsmodelle gilt dabei, dass sie an der Systemgrenze üblicherweise
ein deterministisches Verhalten aufweisen. Die Berücksichtigung harter Echtzeitan-
135