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