Modellbasierte Anforderungsspezifikation sicherheitskritischer ...

Testfallgenerierung ein bei der manuellen Ableitung der Sequenzdiagramme nicht berücksichtigtes
Szenario erkannt wird. Im Beispielmodell geschah dies nach der 3. Iteration, in der die
Reaktion auf ein ausgefallenes Rotlicht spezifiziert wurde. Bei der händischen Erstellung der
Sequenzdiagramme wurde dabei nicht berücksichtigt, dass Gelblichtausfall und Rotlichtausfall
auch gemeinsam auftreten können. Das für die korrekte Reaktion auf einen solchen Doppelausfall
erforderliche Verhalten wurde bei der Erweiterung des Verhaltensmodells jedoch implizit
mitmodelliert. Das Testfallgenerierungswerkzeug erzeugte nun aus dem Verhaltensmodell
heraus ein Sequenzdiagramm für den Doppelausfall und machte das zugehörige korrekte Soll-
Verhalten damit explizit. Damit war sichergestellt, dass es bei der weiteren Erweiterung des
Verhaltensmodells nicht zu einer Regression kommen kann, in der das korrekte Verhalten bei
einem Doppelausfall wieder verändert wird.
Für das Beispielmodell ergeben sich aus 12 Iterationen insgesamt 17 Szenarien für das Beispielmodell
sowie ein in 13 Aktivitätsdiagrammen beschriebenes Systemverhalten. Gegenüber
der vorherigen Phase 1 wurden bei der Erstellung der Diagramme auch die Angaben zu den
ausgetauschten Informationen überarbeitet und präzisiert. So wird zwischen dem BÜ und dem
Straßenverkehrsteilnehmer nicht mehr nur ein abstrakter Befahrbarkeitszustand ausgetauscht,
sondern detailliertere Informationen zum Signalbild der LZA und zur Position der Schrankenbäume.
Diese Modifikationen werden durch den Prozessablauf auch in allen anderen Modellsichten
konsistent nachgezogen, was sich in der Systemabgrenzungssicht der Phase 2 (Bild 6.20)
zeigt. Dort sind die gegenüber der Phase 1 modifizierten Signal-Namen zu erkennen.
Nach Abschluss der Phase 2 sind alle Systemfunktionen des Bahnübergangs im Beispielmodell
enthalten und die Interaktionsszenarien sind nachweislich konsistent zum Systemverhalten.
6.3.4. P3 - Spezifikation der Subsystemarchitektur
In den vorhergehenden Phasen wurde das Modell soweit angereichert, dass es zu Beginn der
Phase P3 ausführbar und testbar ist. Ziel der Phase 3 ist es nun, die Subsysteme des aktuellen
SuB festzulegen, eine Subsystemarchitektur zu definieren und das global auf Systemebene definierte
Verhalten auf die einzelnen Subsystemkomponenten aufzuteilen. Diese Subsystemkomponenten
können dann in weiteren, rekursiven Anwendungen des hier beschriebenen Prozesses
gemäß dem Ebenenkonzept weiter ausspezifiziert werden. Die Subsystemarchitektur wird in der
Subsystemsicht dargestellt, die in Abschnitt 5.1.4.5 beschrieben wird. Die Durchführung dieser
Phase ist dabei optional, da eine Subsystemdefinition nicht zwangsweise erfolgen muss.
Wird jedoch entschieden, diese durchzuführen, erfolgt auch die Abarbeitung dieser Aufgabe
entsprechend dem Vorgehensmodell iterativ-inkrementell. Sinnvollerweise wird dabei über die
einzelnen Subsystemkomponenten iteriert, d.h. pro Iteration wird eine Subsystemkomponente
hinzugefügt. Dies geschieht durch den Subprozess S7, alle weiteren Subprozesse in dieser Phase
entsprechen denen der Phase P2. Allerdings werden diese Aktivitäten in der Phase P3 zu einem
einfacheren Ablauf verknüpft, der nur eine Iterationsschleife über die einzelnen Subsystemkomponenten
enthält. Dieser Ablauf ist in Abbildung 6.21 dargestellt.
125