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.
diagramm dargestellte Soll-Kommunikation hervorruft. Dies geschieht im Beispielmodell durch<br />
ein Aktivitätsdiagramm, das zunächst nur den Regelablauf des BÜ-Sicherns implementiert (siehe<br />
Bild 6.19).<br />
Wichtig ist bei der Erstellung dieses Diagramms, dass die dort versendeten und empfangenen<br />
Signale und deren Attribute - entsprechend der in Kapitel 5.1.5.1 beschriebenen Konsistenzbedingung<br />
- exakt so bezeichnet werden, wie in den Nachrichten der Sequenzdiagramme. Nur so<br />
kann durch Testausführungswerkzeuge später überprüft werden, ob die durch das modellierte<br />
Verhalten hervorgerufene Kommunikation zwischen SuB und Umgebung den Sollvorgaben<br />
entspricht. Diese Bedingung wird jedoch durch den datenbankähnlichen Ansatz der meisten<br />
Modellierungswerkzeuge ohnehin erzwungen.<br />
Nach Erstellung des Aktivitätsdiagramms wird das Modell ausgeführt 2 , das entstehende Kommunikationsverhalten<br />
in einer Testumgebung (wie z.B. dem TestConductor für Rhapsody) aufgezeichnet<br />
und mit dem zuvor in Form der Sequenzdiagramme modellierten Soll-Kommunikationsverhalten<br />
verglichen. Sind sie inhaltlich identisch, erfolgt im nächsten Schritt die Anwendung<br />
des automatischen Testfallgenerierungswerkzeuges auf das Verhaltensmodell. Diese hat zum<br />
einen das Ziel, implizit mitmodelliertes, gewünschtes Verhalten explizit zu machen, andererseits<br />
eventuell enthaltenes Fehlverhalten zu offenbaren. Da das Aktivitätsdiagramm in dieser<br />
ersten Phase noch sehr einfach ist, ergeben sich zu diesem Zeitpunkt durch die Ausführung des<br />
Testfallgenerators keine neuen Erkenntnisse und die erste Iteration der inneren Schleife kann<br />
abgeschlossen werden.<br />
An dieser Stelle ist im Prozessablauf die Durchführung einer formalen Verifikation gegen Sicherheitsund<br />
Lebendigkeitsrandbedingungen vorgesehen. Allerdings stand zum Zeitpunkt der Modellierung<br />
(Anfang 2008) kein geeignetes formales Verifikationswerkzeug zur Verfügung, mit dem ein<br />
auf Aktivitätsdiagrammen basierendes Verhaltensmodell hätte verifiziert werden können. Daher<br />
konnte dieser Prozessschritt nicht durchgeführt werden und wurde übersprungen.<br />
In den folgenden Iterationen wurden nun nach und nach die einzelnen Störungssituationen<br />
modelliert. Dies geschieht nach dem gleichen Vorgehen wie beim Regelablauf. So wurde beim<br />
vorliegenden Beispielmodell in der zweiten Iteration als Fehlerfall die Reaktion auf ein ausgefallenes<br />
Gelblicht am Bahnübergang modelliert: Sobald die Bahnübergangssteuerung einen Ausfall<br />
des Gelblichts 3 erkennt, muss sie sofort auf das Rotlicht umschalten und nicht erst nach der<br />
sonst üblichen Gelbzeit. Für die sich dadurch ergebenden Kommunikationsabläufe wird - wie<br />
beim Regelablauf - zunächst ein Sequenzdiagramm erstellt und anschließend das Verhaltensmodell<br />
so erweitert, dass auch der Fehlerfall korrekt abgebildet wird. Auch der nachfolgende<br />
Testzyklus folgt dabei dem zuvor beschriebenen Muster, verwendet als Eingangsdaten jedoch eine<br />
gegenüber der ersten Iteration vergrößerte Datenmenge. So muss sich das Verhaltensmodell<br />
nun gegen die Sequenzdiagramme von Regelfall (aus der ersten Iteration) und Gelblichtausfall<br />
(aus der aktuellen zweiten Iteration) bewähren, wodurch praktisch ein Regressionstest-Szenario<br />
entsteht. Sollte durch das Hinzufügen der Verhaltenskonstrukte in der zweiten Iteration das Gesamtverhalten<br />
ungewollt so verändert worden sein, dass das Sollverhalten aus der ersten Iteration<br />
nicht mehr erfüllt wird, würde dies jetzt bemerkt.<br />
Auch die nachfolgende Testfallgenerierung stützt sich auf das nun erweiterte Verhaltensmodell.<br />
Mit dessen zunehmender Komplexität steigt auch die Wahrscheinlichkeit, dass durch die<br />
2 Ein ablauffähiges Modell erfordert minunter noch zusätzliche Modellierungsarbeiten (z.B. zur vereinfachten Abbildung<br />
der Systemumgebung), die aber nicht inhaltlich relevant sind und daher hier nicht näher beschrieben<br />
werden.<br />
3 Bei realen Anlagen im Bereich der Bahnen nach EBO wird eine bestimmte Anzahl an ausgefallenen Gelblichtern<br />
üblicherweise toleriert. Die Sicherungsanlage reagiert beispielsweise erst dann auf einen Gelblichtausfall, wenn<br />
es an einer bestimmten Anzahl an Signalgebern gleichzeitig zu einem Gelblichtausfall kommt.<br />
123