Modellbasierte Anforderungsspezifikation sicherheitskritischer ...

Weitere Magazine

Empfehlungen

Info

Ideenskizzen, implizite Vorstellungen und informelle Anforderungen existieren. Diese sind wesentliches Ausgangsmaterial für die Arbeiten in dieser Phase, für deren erste Schritte sich durchaus auch das Brainstorming in einer Gruppe anbietet. Im Beispielmodell wird zu Beginn der Phase 0 zunächst das SuB modelliert, wozu ein entsprechend stereotypisierter Block mit Namen „BUe” angelegt wird. Dieser steht für die gesamte zu entwickelnde Bahnübergangssicherungsanlage, inklusive aller physischen Komponenten, wie Signalgebern, Schrankenanlage, Überwachungssignalen, etc. In insgesamt sechs Iterationen wurden durch Ausführung der Aktivitäten des Subprozesses S1 daraufhin die das System umgebenden Akteure eingeführt und die jeweiligen Kommunikationsbeziehungen mit dem BÜ festgelegt. Dazu werden für jeden Akteur zunächst die Schnittstellen zum BÜ ermittelt und als Ports in das Modell aufgenommen. So wird beispielsweise - entsprechend der Systembeschreibung in Abschnitt 6.2.6 - der Triebfahrzeugführer (Tf) eines sich nähernden Schienenfahrzeuges durch Überwachungssignale über den Sicherungszustand des Bahnübergangs informiert. Jedes Überwachungssignal stellt im funktionalen Modell somit eine Schnittstelle zum Akteur „Triebfahrzeugführer” dar, und wird daher über einen Port an der Systemgrenze modelliert (Port „UeS”). Entsprechend der genannten Randbedingungen kann der BÜ je nach Gleistopologie über zwei bis vier Überwachungssignale verfügen, weswegen der Port „UeS” die Multiplizitätsangabe „2...4” trägt. Die Kommunikationsflüsse zwischen Akteuren und BÜ werden in dieser frühen Phase noch sehr abstrakt formuliert. Für das Überwachungssignal wird beispielsweise lediglich modelliert, dass dieses den generellen Befahrbarkeitszustand des BÜ an den Tf überträgt. Die zu entwickelnde Bahnübergangssicherungsanlage soll zugbewirkt ein- und ausgeschaltet werden. Als weitere Schnittstellen des Systems nach aussen werden daher Sensoren benötigt, die erkennen, dass sich ein Schienenfahrzeug nähert bzw. dass dieses den Bahnübergang komplett geräumt hat. Diese Schnittstellen, „Einschaltsensor” und „Ausschaltsensor”, werden vom Akteur „Schienenfahrzeug” beeinflusst, da dessen Anwesenheit am jeweiligen Sensor vom System als „Annäherungsinformation” bzw. der „Räumungsinformation” interpretiert wird. Auch hier werden die Schnittstellen im Modell durch Ports repräsentiert, die die entsprechenden Multiplizitäten gemäß der Systemskizze in Abbildung 6.8 besitzen und die oben genannten. Informationen entgegen nehmen. Weiterhin lassen sich die Straßenverkehrsteilnehmer als weitere wichtige Akteure im Systemumfeld identifizieren. Diese werden - analog zum Triebfahrzeugführer - durch den BÜ über den aktuellen Befahrbarkeitszustand der Straßenquerung informiert. Dies geschieht durch die Lichtzeichen- und Schrankenanlage, die durch entsprechende Ports („LZA” und „Schrankenanlage”) an der Systemgrenze dargestellt werden müssen. Beide unterscheiden sich zwar deutlich in ihrer physikalischen Wirkungsweise, dennoch übermitteln beide eine ähnliche Information vom System an den Verkehrsteilnehmer. Dies wird im Modell durch den gleichen Informationsfluss „Befahrbarkeit Straße” ausgedrückt. Eine Sonderstellung nimmt der Akteur „Umwelt” ein, der die sonstige Umgebung des Systems und insbesondere die einwirkenden Umweltbedingungen wie Temperatur, Feuchtigkeit, Erschütterungen und elektromagnetische Abstrahlung darstellt. Diese Umweltbedingungen wirken allerdings nicht über eine abgrenzbare Schnittstelle auf das System ein, sondern diffus auf sämtliche Komponenten. Daher wird für die „Umweltbedingungen” im funktionalen Modell kein Port vorgesehen. Diese interagieren vielmehr direkt mit dem Block „BUe”, was andeutet, dass das gesamte beschriebene System betroffen ist. Über den Subprozess S8 (siehe Abschnitt 6.4.8) werden anschließend nicht-funktionale Anforderungen - wie beispielsweise Angaben zu ertragbaren Temperaturbereichen - entsprechend dem in 5.2 beschriebenen Konzept mit dem Informationsfluss vom Umwelt-Akteur zum SuB verknüpft. Dadurch wird im Modell ausgedrückt, dass die Umweltbedingungen durch die entsprechenden nicht-funktionalen Anforderungen näher spezi- 107
fiziert werden. Der Entwicklungsstand des Beispielmodells nach Abschluss der Phase P0 kann dem Bild 6.10 entnommen werden. Der Arbeitsstand erhebt übrigens keinerlei Anspruch auf Vollständigkeit bezüglich Systemgrenzen, Ports und Akteuren. Er ist vielmehr als Grundlage zu verstehen, die in den folgenden Phasen weiter verfeinert und detailliert wird. Genau dieses allmähliche Anreichern des Modells ist die wesentliche Konzeptidee hinter dem verwendeten iterativinkrementellen Entwicklungsprozess. 6.3.2. P1 - Spezifikation der Systemfunktionen Im Fokus der Phase P1 steht die Ableitung der Systemfunktionen, wobei die in der vorherigen Phase P0 erstellte Systemabgrenzung als Bezugsbasis verwendet wird. Ziel der Phase 1 ist die Modellierung der Systemfunktionen in Form von Anwendungsfällen und damit die initiale Erstellung der Systemfunktionssicht gemäß Abschnitt 5.1.4.2. Die Phase P1 umfasst die Ausführung der Subprozesse S1, S2 und S8. Im Subprozess S2 wird dabei die in dieser Phase neu hinzukommende Systemfunktionssicht iterationsweise aufgebaut. In den Subprozessen S1 und S8 werden die Systemabgrenzungssicht und die Anforderungsschnittstellensicht entsprechend den Konsistenzbedingungen nachgezogen. Der sich daraus ergebende Ablauf der Phase P1 ist in Bild 6.11 dargestellt. act [Aktivitaet] P1 Spezifikation Systemfunktionen[ Ablauf P1 ] Iterationen festlegen : S2 Systemfunktionssicht erstellen/ueberarbeiten : S1 Systemabgrenzungssicht erstellen/ueberarbeiten : S8 Nicht-funktionale Anforderungen ueberabeiten Auf weitere Iteration pruefen [weitere Iteration] [keine weitere Iteration] Abbildung 6.11.: Ablauf Phase P1 Zu Beginn der Phase wird zunächst in der Aktion „Iteration festlegen” das Iterationskonzept für 108
Seite 1:
Modellbasierte Anforderungsspezifik
Seite 4 und 5:
5.1.5.2. Konsistenz der Akteure . .
Seite 6 und 7:
1. Abstract In common with other te
Seite 8 und 9:
2. Einleitung Wie in anderen techni
Seite 10 und 11:
5 % der späteren Fehler aufgedeckt
Seite 12 und 13:
3. Bestandsaufnahme und Identifikat
Seite 14 und 15:
dest |−> q, adr |−> msg.adr] :
Seite 16 und 17:
Abbildung 3.1.: Das Verhältnis von
Seite 18 und 19:
und Testmodell und erweitert somit
Seite 20 und 21:
für LST-Modulverträge für die De
Seite 22 und 23:
Im Kontext des BMW-Prinzips lässt
Seite 24 und 25:
• Die zweite Unterklasse umfasst
Seite 26 und 27:
Abbildung 4.1.: Herunterbrechen der
Seite 28 und 29:
Insgesamt ergibt sich somit die in
Seite 30 und 31:
Abbildung 5.1.: Einordnung des funk
Seite 32 und 33:
5.1.1.3. Objektorientierung im Eise
Seite 34 und 35:
• Eignung für das Systems Engine
Seite 36 und 37:
5.1.2. Metamodell und Subset der Sy
Seite 38 und 39:
Für die Anzahl der Ebenen gibt es
Seite 40 und 41:
Modell_Ebene_Teilmodell_Sichten pac
Seite 42 und 43:
(a) Das funktionale Konzept betrach
Seite 44 und 45:
bdd [Modell] Data[ Kontexktkommunik
Seite 46 und 47:
dd [Modell] Data[ Systemabgrenzungs
Seite 48 und 49:
• die Folgen von Gefährdungen zu
Seite 50 und 51:
uc [view] Systemfunktionssicht [ Te
Seite 52 und 53:
dd [Modell] Data[ Systemfunktionssi
Seite 54 und 55:
Im Rahmen des Anforderungsmodells k
Seite 56 und 57:
Inhaltselement SysML-Sprachelement
Seite 58 und 59:
5.1.4.4. Systemverhaltenssicht Mit
Seite 60 und 61:
hat beispielsweise Arabestani in [A
Seite 62 und 63: Abbildung 5.11.: Einordnung des Sys
Seite 64 und 65: wird - sofern möglich - eben diese
Seite 66 und 67: act [Aktivitaet] Druckluft erzeugen
Seite 68 und 69: • Kontinuierliche Übertragung vo
Seite 70 und 71: in einer Aktionssprache an den Kont
Seite 72 und 73: der Subsystemarchitektur (siehe 5.1
Seite 74 und 75: Verhaltensmuster Senden von Signale
Seite 76 und 77: 5.1.4.5. Subsystem-Struktur/Whitebo
Seite 78 und 79: enthalten ist. So verfügt die beis
Seite 80 und 81: Inhaltselement Diagrammart SuB Port
Seite 82 und 83: 77 Abbildung 5.22.: Beispielhafte E
Seite 84 und 85: 5.1.5. Konsistenzregeln Für die in
Seite 86 und 87: 5.1.5.2. Konsistenz der Akteure Die
Seite 88 und 89: dd [Paket] Konsistenzen [ Allokatio
Seite 90 und 91: Diese Aufstellung zeigt, dass es si
Seite 92 und 93: 87 Abbildung 5.29.: Prinzip der Ver
Seite 94 und 95: 6. Inkrementell-iterativer Erstellu
Seite 96 und 97: zen, wenn die Arbeitsschritte durch
Seite 98 und 99: 6.1.3. Einordnung in den Gesamtlebe
Seite 100 und 101: Von Nach Ausgetauschte Information
Seite 102 und 103: Ein solches Anforderungsprofil best
Seite 104 und 105: den könnte. Vielmehr soll diese ja
Seite 106 und 107: Letztendlich lässt sich keine eind
Seite 108 und 109: 103 Abbildung 6.7.: Rekursive Anwen
Seite 110 und 111: NoMagic in der Version 14.0 zum Ein
Seite 114 und 115: bdd [Modell] Data[ Kontexktkommunik
Seite 116 und 117: 111 Abbildung 6.12.: Detaillierung
Seite 118 und 119: vom BÜ die Anzeige des Befahrbarke
Seite 120 und 121: bdd [Modell] Data[ Kontexktkommunik
Seite 122 und 123: act [Aktivitaet] P2 Spezifikation S
Seite 124 und 125: Entwicklungsziel angestrebt werden,
Seite 126 und 127: Als Ergebnis liefert der Subprozess
Seite 128 und 129: diagramm dargestellte Soll-Kommunik
Seite 130 und 131: Testfallgenerierung ein bei der man
Seite 132 und 133: act [Aktivitaet] P3 Spezifikation S
Seite 134 und 135: Weiterhin wird im Beispielmodell an
Seite 136 und 137: 6.4.2. S2 - Systemfunktionssicht be
Seite 138 und 139: schriebene Vorgehen an: • Zunäch
Seite 140 und 141: die Szenariensicht ist: Letztere ze
Seite 142 und 143: act [Aktivitaet] S5 Systemverhalten
Seite 144 und 145: Abbildung 6.24.: Automatisierter Ve
Seite 146 und 147: act [Aktivitaet] S7 Subsystemsicht
Seite 148 und 149: nicht auszugehen. Die zusätzliche,
Seite 150 und 151: 7. Zusammenfassung, Ergebnisse und
Seite 152 und 153: de ein iterativ-inkrementelles Vorg
Seite 154 und 155: Literaturverzeichnis [ALE02] ALEXAN
Seite 156 und 157: [ISO19005] Norm ISO 19005-1. Docume
Seite 158 und 159: [WES00] WEISSTEIN, Eric W.: Determi
Seite 160 und 161: dd [Modell] Data[ Systemabgrenzungs
Seite 162 und 163:
dd [Modell] Data[ Szenariensicht ]
Seite 164 und 165:
dd [Modell] Data[ Subsystemsicht ]
Seite 166 und 167:
B. Metamodell-Aktivitätsdiagramme
Seite 168 und 169:
act [Aktivitaet] P1 Spezifikation S
Seite 170 und 171:
act [Aktivitaet] P3 Spezifikation S
Seite 172 und 173:
act [Aktivitaet] S1 Systemabgrenzun
Seite 174 und 175:
act [Aktivitaet] S3 Szenariensicht
Seite 176 und 177:
act [Aktivitaet] S5 Systemverhalten
Seite 178:
act [Aktivitaet] S8 Nicht-funktiona
Alle anzeigen

Modellbasierte Anforderungsspezifikation sicherheitskritischer ...

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?