4 Formale Methoden zur Entwicklung qualitativ hochwertiger Software
4 Formale Methoden zur Entwicklung qualitativ hochwertiger Software
4 Formale Methoden zur Entwicklung qualitativ hochwertiger Software
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
<strong>Software</strong>technik II<br />
§ 4 <strong>Formale</strong> <strong>Methoden</strong> <strong>zur</strong> <strong>Entwicklung</strong> <strong>qualitativ</strong><br />
<strong>hochwertiger</strong> <strong>Software</strong><br />
Lernziele<br />
ST II<br />
– Wissen, was formale <strong>Methoden</strong> sind<br />
– Einsatz formaler <strong>Methoden</strong> <strong>zur</strong> Erstellung mathematisch nachweisbar<br />
korrekter IT-Systeme kennen<br />
– Verstehen, dass mit der Einsatztiefe formaler <strong>Methoden</strong> das Vertrauen in<br />
die Korrektheit der so entwickelten SW-Komponenten erwächst<br />
– <strong>Formale</strong> Sprachen kennen<br />
– Modelchecker „Symbolic Model Verifier“ (SMV) kennen<br />
Literatur<br />
– G. Thaller: <strong>Software</strong>- Test, Verifikation und Validation, Heise Verlag, 2000<br />
– W. Ehrenberger: <strong>Software</strong>-Verifikation - Verfahren für den<br />
Zuverlässigkeitsnachweis von <strong>Software</strong>, Hanser Verlag, 2001<br />
– A. Moik: Ingenieurgerechte formale <strong>Methoden</strong> für die <strong>Entwicklung</strong> von<br />
sicheren Automatisierungssystemen, Shaker Verlag, 2002<br />
© 2013 IAS, Universität Stuttgart 162
<strong>Software</strong>technik II<br />
§ 4 <strong>Formale</strong> <strong>Methoden</strong> <strong>zur</strong> <strong>Entwicklung</strong> <strong>qualitativ</strong><br />
<strong>hochwertiger</strong> <strong>Software</strong><br />
ST II<br />
4.1 Wozu formale <strong>Methoden</strong>?<br />
4.2 Grundlagen der formalen Spezifikation und Verifikation<br />
4.3 Vorgehensweise bei der formalen <strong>Software</strong>entwicklung<br />
4.4 Modelchecker SMV<br />
4.5 Hinweise für die Praxis<br />
© 2013 IAS, Universität Stuttgart 163
4.1 Wozu formale <strong>Methoden</strong>?<br />
ST II<br />
Vorgehensweise im Brückenbau<br />
F HR,A<br />
F A<br />
a<br />
r 0<br />
r 1<br />
I<br />
F B<br />
S<br />
F HR,B<br />
F GO<br />
F G<br />
Warum stürzen so selten Brücken ein?<br />
Film: Modellbildung<br />
© 2013 IAS, Universität Stuttgart 164
4.1 Wozu formale <strong>Methoden</strong>?<br />
ST II<br />
Schlagzeilen aus Zeitungsmeldungen<br />
Millionenschaden durch<br />
kostenloses Telefonieren<br />
Hacker dringen in<br />
militärische Netze ein<br />
Airbusabsturz<br />
<strong>Software</strong>fehler?<br />
P ostgiro 3000<br />
Zin sen w erden m an u ell<br />
berech n et!<br />
Problemfeld: Verlässlichkeit von <strong>Software</strong><br />
© 2013 IAS, Universität Stuttgart 165
4.1 Wozu formale <strong>Methoden</strong>?<br />
ST II<br />
Einsatzgebiete<br />
– Security (Vertraulichkeit, Integrität, Verfügbarkeit)<br />
– Safety (Betriebssicherheit, technische Sicherheit)<br />
– Privacy (Datenschutz, Schutz der Privatsphäre)<br />
Aufgabenstellung<br />
– Nachweis spezifischer Eigenschaften eines <strong>Software</strong>systems<br />
– Korrekte Implementierung eines <strong>Software</strong>systems<br />
© 2013 IAS, Universität Stuttgart 166
4.1 Wozu formale <strong>Methoden</strong>?<br />
ST II<br />
Anwendungsbereiche<br />
– Kernkraftwerke<br />
– Verkehr/Transport<br />
Eisenbahnwesen, insbesondere Signaltechnik<br />
Flugzeugsteuerung, Flugverkehrslenkung<br />
Kraftfahrzeug: elektronische Motorregelung, ABS<br />
– Medizintechnik<br />
– Telekommunikation<br />
– Hardware: Prozessordesign<br />
© 2013 IAS, Universität Stuttgart 167
4.1 Wozu formale <strong>Methoden</strong>?<br />
ST II<br />
<strong>Formale</strong> <strong>Methoden</strong> in Standards, Richtlinien, Empfehlungen<br />
– Bewertungskriterien für die Sicherheit von IT-Systemen (security) fordern ab<br />
gewissen Stufen formale Spezifikation von Sicherheitsmodellen und Funktionalität<br />
und Verifikation<br />
Trusted Computer System Evaluation Criteria<br />
(TCSEC, “Orange Book”) US NCSC<br />
International standard (ISO/IEC 15408) for computer security<br />
Harmonisierte IT-Sicherheitskriterien (ITSEC Handbuch)<br />
– Vorgaben durch Zertifizierungsstelle<br />
Darlington NPS, TCAS<br />
TÜV Rheinland: diversitäre Rückentwicklung<br />
TÜV zieht Vorgaben für formale <strong>Methoden</strong> in Erwägung<br />
BSI und andere für sichere Systeme zuständige Stellen<br />
– <strong>Entwicklung</strong> von Empfehlungen in verschiedenen technischen Bereichen<br />
“Railway applications: <strong>Software</strong> for Railway Control and Protection Systems”<br />
(CEN/CENELEC-Entwurf, 1993)<br />
Vorschläge für Standards sicherheitsrelevanter <strong>Software</strong>: <strong>Formale</strong> <strong>Methoden</strong><br />
der Spezifikation und Verifikation empfohlen für höhere Stufen ( safety<br />
integrity levels)<br />
© 2013 IAS, Universität Stuttgart 168
4.1 Wozu formale <strong>Methoden</strong>?<br />
ST II<br />
Kriterien <strong>zur</strong> Beurteilung vertrauenswürdiger Systeme<br />
IT- Sicherheitskriterien (BSI)<br />
Qualitätsmaßstab<br />
Q 0 Un<strong>zur</strong>eichend<br />
Q 1 Getestet<br />
Q 2 Methodisch getestet<br />
Q 3 Teilanalysiert<br />
Q 4 Informell analysiert<br />
Q 5 Semiformal analysiert<br />
Q 6 Formal analysiert<br />
Q 7 Formal verifiziert<br />
Hohe Qualitätsstufen<br />
Q 5: Die Anforderungen sind überwiegend formal<br />
zu spezifizieren. Die Entwurfsbeschreibung<br />
liegt in semiformaler Notation vor. Letztere<br />
sowie die Implementierung sind sorgfältig mit<br />
semiformalen <strong>Methoden</strong> zu analysieren und<br />
auf Konsistenz mit den Anforderungen zu<br />
prüfen<br />
Q 6: Anforderungen und Entwurfsbeschreibungen<br />
sind in formaler Notation niederzulegen und<br />
auf Konsistenz zu verifizieren. Die<br />
Implementierung ist sorgfältig auf Konsistenz<br />
mit der Entwurfsbeschreibung zu prüfen.<br />
Q 7: Anforderungen und Entwurfsbeschreibungen<br />
sind in formaler Notation niederzulegen und<br />
auf Konsistenz zu verifizieren. Die<br />
Implementierung ist in einer Sprache mit<br />
formal definierter Semantik auszuführen. Die<br />
Konsistenz zwischen Entwurfsbeschreibung<br />
und Implementierung ist formal zu verifizieren.<br />
© 2013 IAS, Universität Stuttgart 169
Frage zu Kapitel 4.1<br />
ST II<br />
Frage zu Kapitel 4.1<br />
Um welche Art von Sicherheit handelt es sich in folgenden Situationen?<br />
Situationen:<br />
Eine sichere Datenübertragung zwischen Server und<br />
Client, damit kein Unbefugter die Daten abhören kann<br />
f<br />
<br />
Privacy<br />
<br />
Security<br />
Safety<br />
Eine sichere Steuerungssoftware für ein medizinisches<br />
Gerät, damit kein Fehler auftritt<br />
f<br />
f<br />
Privacy<br />
Security<br />
Safety<br />
<br />
In der Datenbank dürfen nur bestimmte<br />
personenbezogenen Daten gespeichert werden<br />
f<br />
f<br />
<br />
Privacy<br />
Security<br />
Safety<br />
© 2013 IAS, Universität Stuttgart 170
<strong>Software</strong>technik II<br />
ST II<br />
§ 4 <strong>Formale</strong> <strong>Methoden</strong> <strong>zur</strong> <strong>Entwicklung</strong> <strong>qualitativ</strong><br />
<strong>hochwertiger</strong> <strong>Software</strong><br />
4.1 Wozu formale <strong>Methoden</strong>?<br />
4.2 Grundlagen der formalen Spezifikation und Verifikation<br />
4.3 Vorgehensweise bei der formalen <strong>Software</strong>entwicklung<br />
4.4 Modellchecker SMV<br />
4.5 Hinweise für die Praxis<br />
© 2013 IAS, Universität Stuttgart 171
4.2 Grundlagen der formalen Spezifikation und Verifikation<br />
ST II<br />
Die <strong>Formale</strong> <strong>Entwicklung</strong> in der Übersicht (Live-Mitschrieb)<br />
Informelle<br />
Beschreibung<br />
<strong>Formale</strong><br />
Eigenschaften<br />
<strong>Formale</strong><br />
Systembeschreibung<br />
Korrektheitsbeweise<br />
<strong>Formale</strong> Beschreibng<br />
der Implementierung<br />
Physikalisch-technische<br />
Realisierung<br />
© 2013 IAS, Universität Stuttgart 172
4.2 Grundlagen der formalen Spezifikation und Verifikation<br />
ST II<br />
C.A.R. Hoare:<br />
“ I hold the opinion that the construction of computer programs is a<br />
mathematical activity like the solution of differental equations, that<br />
programs can be derived from their specification through mathematical<br />
insight, calculations, and proof, using algebraic laws as simple and<br />
elegant as those of elementary arithmetic.”<br />
<strong>Formale</strong> Spezifikation und Verifikation von Programmen<br />
Nachweis mit mathematischer Exaktheit, dass ein Programm eine<br />
gestellte Aufgabe erfüllt<br />
Voraussetzung<br />
Verwendete Begriffe und <strong>Methoden</strong> müssen exakt definiert und<br />
formuliert werden<br />
© 2013 IAS, Universität Stuttgart 173
4.2 Grundlagen der formalen Spezifikation und Verifikation<br />
ST II<br />
<strong>Formale</strong> Spezifikation<br />
Formallogische Sprachen erlauben objektivierte Beschreibungen<br />
durch mathematisch definierte Syntax und Semantik<br />
– Syntax:<br />
Sprachen als mathematisch definierte Mengen von Zeichenreihen<br />
Grammatiken, Typen, induktive Syntaxregeln<br />
Systemunterstützung: Editoren, Syntaxanalyse, Typcheck,...<br />
– Semantik:<br />
Zuordnung von (Klassen von) mathematischen Strukturen zu<br />
Sprachkonstrukten<br />
Mengen, Relationen, Funktionen, algebraische Strukturen<br />
Die Prädikatenlogik bildet den Kern der meisten Formalismen<br />
© 2013 IAS, Universität Stuttgart 174
4.2 Grundlagen der formalen Spezifikation und Verifikation<br />
ST II<br />
<strong>Formale</strong> Verifikation<br />
Nachweis mit formalen, mathematisch logischen Schlussweisen<br />
– Ein Programm ist korrekt bezüglich einer gegebenen formalen<br />
Spezifikation<br />
– Eine formale Spezifikation ist eine Verfeinerung einer anderen formalen<br />
Spezifikation<br />
– Die Transformation eines bezüglich einer Spezifikation korrekten<br />
Programms in eine Implementierungssprache ist korrekt<br />
© 2013 IAS, Universität Stuttgart 175
4.2 Grundlagen der formalen Spezifikation und Verifikation<br />
ST II<br />
Beschreibung von Objekten und Beziehungen<br />
zwischen Objekten<br />
– Informell<br />
Chico (C) ist ein Lebewesen (l)<br />
Alle Menschen (m) sind Lebewesen<br />
Chico gehört Susanne (S)<br />
Lebende Besitzgegenstände sind Tiere (t)<br />
– Formal:<br />
Objektbezeichner: S, C ... l(C)<br />
Einstellige Prädikatsymbole: ..., l(...), m(...), t(...), ...<br />
Relationssymbole: g (gehört), ...<br />
Alle Menschen sind Lebewesen: "x, (m(x) I (x))<br />
Chico gehört Susanne: g(C, S)<br />
Lebende Besitzgegenstände sind Tiere : " x, y . (( I(y) g(y, x)) t(y) )<br />
© 2013 IAS, Universität Stuttgart 176
4.2 Grundlagen der formalen Spezifikation und Verifikation<br />
ST II<br />
Ist Chico ein Tier?<br />
Gegeben die Aussage von oben<br />
A<br />
x, y . (( I (y) g (y, x )) t (Y) )<br />
<<br />
I (C) g (C, S)<br />
Einsetzen<br />
UND<br />
((I (C)<br />
<<br />
g (C, S)) t (C))<br />
((I (C)<br />
<<br />
g (C, S))<br />
Modus Ponens<br />
t (C)<br />
© 2013 IAS, Universität Stuttgart 177
4.2 Grundlagen der formalen Spezifikation und Verifikation<br />
ST II<br />
Klassifizierung möglicher Vorgehensweisen beim Einsatz<br />
formaler <strong>Methoden</strong><br />
– Klassische Verifikation<br />
Annotierung von Programmen mit Bedingungen (Assertions)<br />
= Spezifikation des Programms<br />
Korrektheit: Konsistenz von Programm und Assertions<br />
– Gleichzeitige <strong>Entwicklung</strong> von Spezifikation, Programm und Beweisen<br />
Methode der schrittweisen Verfeinerung<br />
Vorgehen z.B. Programmschleife<br />
- Spezifikation der Invarianten<br />
- Realisierung der Schleife gemäß Invarianten<br />
– Systematische <strong>Entwicklung</strong> des Programms aus der Spezifikation<br />
Abstrakte Spezifikation wird über mehrere Zwischenebenen in<br />
ausführbaren Programmtext transformiert<br />
Verwendung von formalisierten Transformationsregeln<br />
© 2013 IAS, Universität Stuttgart 178
4.2 Grundlagen der formalen Spezifikation und Verifikation<br />
ST II<br />
Korrektheit von Programmen<br />
1. Partielle Korrektheit<br />
– Wenn ein Ergebnis abgeliefert wird, ist es korrekt bezüglich<br />
der Problemstellung<br />
– Keine Garantie, dass Ergebnis abgeliefert wird<br />
2. Terminierung<br />
– Programm kommt zum Ende<br />
– Partielle Korrektheit + Terminierung = Totale Korrektheit<br />
3. Keine Laufzeitfehler<br />
– Bsp.: Division durch “0”, Überlauf<br />
© 2013 IAS, Universität Stuttgart 179
4.2 Grundlagen der formalen Spezifikation und Verifikation<br />
ST II<br />
Korrektheit von Parallelen Programmen<br />
4. Interferenzfreiheit<br />
Keine Komponente eines parallelen Programms mischt sich in<br />
unerwünschter Weise in die Berechnung einer anderen Komponente ein<br />
5. Deadlockfreiheit<br />
Keine Situation, in der alle noch nicht terminierten Komponenten unendlich<br />
lange auf die Erfüllung einer Bedingung warten<br />
6. Korrektheit ohne Fairness-Annahme<br />
© 2013 IAS, Universität Stuttgart 180
4.2 Grundlagen der formalen Spezifikation und Verifikation<br />
ST II<br />
Deduktive Verifikation (Theorem Proving)<br />
Beweis durch Deduktion mit Axiomen und Inferenzregeln<br />
Vorteile<br />
• Anwendbar auf alle Systeme<br />
• Jede korrekte Eigenschaft kann verifiziert werden<br />
Nachteile<br />
• Nicht vollständig automatisierbar<br />
• Aufwand nicht vorhersagbar<br />
© 2013 IAS, Universität Stuttgart 181
4.2 Grundlagen der formalen Spezifikation und Verifikation<br />
ST II<br />
Algorithmische Verifikation (Model Checking)<br />
Beweis durch vollständige Exploration des Zustandsraums<br />
Vorteile<br />
• Automatische Verifikation<br />
• Error-Trace bei Fehlern<br />
Nachteile<br />
• Nur Systeme mit endlich vielen Zuständen<br />
• Problem: Explosion des Zustandsraums<br />
© 2013 IAS, Universität Stuttgart 182
Frage zu Kapitel 4.2<br />
ST II<br />
Frage zu Kapitel 4.2<br />
Welche Eigenschaften gehören zu „Partieller Korrektheit“?<br />
Antwort<br />
f<br />
f<br />
<br />
<br />
<br />
Programm kommt zum Ende<br />
Eingabegrößen werden gemäß der Spezifikation auf Ausgabegrößen<br />
abgebildet<br />
Kein Laufzeitfehler<br />
© 2013 IAS, Universität Stuttgart 183
<strong>Software</strong>technik II<br />
ST II<br />
§ 4 <strong>Formale</strong> <strong>Methoden</strong> <strong>zur</strong> <strong>Entwicklung</strong> <strong>qualitativ</strong><br />
<strong>hochwertiger</strong> <strong>Software</strong><br />
4.1 Wozu formale <strong>Methoden</strong>?<br />
4.2 Grundlagen der formalen Spezifikation und Verifikation<br />
4.3 Vorgehensweise bei der formalen <strong>Software</strong>entwicklung<br />
4.4 Modellchecker SMV<br />
4.5 Hinweise für die Praxis<br />
© 2013 IAS, Universität Stuttgart 184
4.3 Vorgehensweise bei der formalen <strong>Software</strong>entwicklung<br />
ST II<br />
<strong>Formale</strong> Spezifikation des Systems<br />
Informelle<br />
Anforderungsbeschreibung<br />
Sicherheitsrelevante<br />
Anforderungen<br />
<strong>Formale</strong><br />
Eigenschaften<br />
formal<br />
Beweis über Erfüllung<br />
der sicherheitsrelevanten<br />
Anforderungen<br />
Operationelle<br />
Anforderungen<br />
<strong>Formale</strong><br />
Systembeschreibung<br />
Beweis über Umsetzung der<br />
formalen Systembeschreibung<br />
nicht formal<br />
Rahmensystem<br />
Verfeinerung<br />
<strong>Formale</strong> Beschreibung<br />
der Implementierung<br />
Programmquelltext<br />
Physikalischtechnische<br />
Realisierung<br />
© 2013 IAS, Universität Stuttgart 185
4.3 Vorgehensweise bei der formalen <strong>Software</strong>entwicklung<br />
ST II<br />
Beispiel: Systemstruktur Verkehrsleitsystem<br />
NS<br />
OW<br />
Verkehrsleitsystem<br />
Verkehrsüberwachung<br />
Ampelsystem<br />
Verkehrssteuerung<br />
Ampelsteuerungsmodul<br />
Ampelstatistik<br />
Ampelinit<br />
Schalten<br />
Druck-Ausgabe<br />
Schaltprotokoll<br />
Statistikauswertung<br />
© 2013 IAS, Universität Stuttgart 186
4.3 Vorgehensweise bei der formalen <strong>Software</strong>entwicklung<br />
ST II<br />
Anforderungsspezifikation<br />
Anforderung 317 (1)<br />
<br />
Die Signale an zwei feindlichen Fahrstraßen (Kreuzung) dürfen nicht<br />
gleichzeitig grün sein<br />
Anforderung 318 (1) <br />
Das Verkehrsleitsystem muss an einer Kreuzung die Rot-Grün-Phasen für<br />
optimalen Durchsatz von Fahrzeugen regeln<br />
© 2013 IAS, Universität Stuttgart 187
4.3 Vorgehensweise bei der formalen <strong>Software</strong>entwicklung<br />
ST II<br />
Sicherheitsmodell Ampelsteuerungsmodul<br />
Informell:<br />
Signale an ns_ampel und ow_ampel nicht gleichzeitig grün<br />
Formal: S_SPEC<br />
ist_sichere_ampel (ns_ampel, ow_ampel) =<br />
ns_ampel = rot OR ow_ampel = rot<br />
© 2013 IAS, Universität Stuttgart 188
4.3 Vorgehensweise bei der formalen <strong>Software</strong>entwicklung<br />
ST II<br />
Funktionale Spezifikation Ampelsteuerungsmodul<br />
Informell:<br />
Die Prozedur “schalten” ändert die Farben der ns_ampel<br />
und der ow_ampel gemäß folgendem Schaltplan:....<br />
Formal: L_SPEC<br />
funktionale Spezifikation<br />
PROC schalten<br />
WHEN ns_ampel = rot AND ow_ampel = gruen THEN<br />
ns_ampel = rot AND ow_ampel = gelb<br />
ELSEWHEN ns_ampel = rot AND ow_ampel = gelb THEN<br />
ns_ampel = gruen AND ow_ampel = rot<br />
ELSEWHEN ns_ampel = gruen AND ow_ampel = rot THEN<br />
ns_ampel = gelb AND ow_ampel = rot<br />
OTHERWISE ns_ampel = rot AND ow_ampel = gruen<br />
INITIAL: ns_ampel = rot AND ow_ampel = gelb<br />
© 2013 IAS, Universität Stuttgart 189
4.3 Vorgehensweise bei der formalen <strong>Software</strong>entwicklung<br />
ST II<br />
Abstraktes Programm<br />
Informell:<br />
Structured Design<br />
OOD<br />
Formal: A_SPEC<br />
PROCEDURE schalten<br />
BODY:IF nsa = rot<br />
THEN owa := next (owa);<br />
IF owa = rot<br />
then nsa := next (nsa)<br />
FI<br />
ELSE nsa := next (nsa);<br />
IF nsa = rot<br />
THEN owa := next (owa)<br />
FI<br />
FI<br />
PROCEDUREEND<br />
FUNCTION: next: farbe farbe<br />
AXIOMS: next (gruen) = gelb;<br />
next (gelb) = rot;<br />
next (rot) = gruen<br />
© 2013 IAS, Universität Stuttgart 190
4.3 Vorgehensweise bei der formalen <strong>Software</strong>entwicklung<br />
ST II<br />
Verifikation der Sicherheitsanforderungen<br />
Informell:<br />
– Systematisches Testen und Inspektion<br />
– Gefahr verborgener Fehler<br />
Formal:<br />
– Nachweis mathematischer Aussagen<br />
L_SPEC erfüllt S_SPEC<br />
A_SPEC erfüllt L_SPEC<br />
– erfolgreicher Beweis garantiert Fehlerfreiheit<br />
– Fehlersuche und -Korrektur durch Fehlschlaganalyse<br />
© 2013 IAS, Universität Stuttgart 191
Frage zu Kapitel 4.3<br />
ST II<br />
Frage zu Kapitel 4.3<br />
Welche Aussagen gelten bei der formalen <strong>Software</strong>entwicklung?<br />
Antwort<br />
f<br />
f<br />
<br />
<br />
<br />
Alle Anforderungen müssen formal beschrieben werden<br />
Sicherheitsnachweis der formal beschriebenen<br />
Sicherheitsanforderungen muss vorhanden sein<br />
Nur die zeitbehafteten Sicherheitsanforderungen werden formal<br />
beschrieben<br />
© 2013 IAS, Universität Stuttgart 192
<strong>Software</strong>technik II<br />
ST II<br />
§ 4 <strong>Formale</strong> <strong>Methoden</strong> <strong>zur</strong> <strong>Entwicklung</strong> <strong>qualitativ</strong><br />
<strong>hochwertiger</strong> <strong>Software</strong><br />
4.1 Wozu formale <strong>Methoden</strong>?<br />
4.2 Grundlagen der formalen Spezifikation und Verifikation<br />
4.3 Vorgehensweise bei der formalen <strong>Software</strong>entwicklung<br />
4.4 Modelchecker SMV<br />
4.5 Hinweise für die Praxis<br />
© 2013 IAS, Universität Stuttgart 193
4.4 Modelchecker SMV<br />
ST II<br />
Merkmale von SMV (Symbolic Model Verifier )<br />
– Unterstützung <strong>zur</strong> Verifikation von Modellen in der Hard- und<br />
<strong>Software</strong>entwicklung<br />
– Beweisführung vollständig automatisch<br />
– Grafische Benutzungsoberfläche<br />
– Modellierung und Anforderungsspezifikation erfolgt textbasiert<br />
<strong>Formale</strong> Sicherheitsanforderungen<br />
<strong>Formale</strong>s Modell<br />
Model-Checking mit SMV<br />
O.K.<br />
Gegenbeispiel (Error-Trace)<br />
© 2013 IAS, Universität Stuttgart 194
4.4 Modelchecker SMV<br />
ST II<br />
Symbolic Model Verifier<br />
– „Symbolisches“ Model-Checking. Der Zustandsraum wird implizit<br />
dargestellt. Effiziente Technik, die die Verarbeitung großer Zustandsräume<br />
ermöglicht.<br />
– SMV wurde ursprünglich für die Verifikation von Hardwaremodellen<br />
entwickelt<br />
– Haupt-Entwickler von SMV: Ken McMillan, Cadence Berkley Labs,<br />
Berkeley, USA<br />
– SMV ist frei verfügbar: http://www-cad.eecs.berkeley.edu/~kenmcmil/<br />
Ziel:<br />
– Industrielle Einsetzbarkeit auch in der <strong>Software</strong>entwicklung<br />
Erforderliche Maßnahme:<br />
– Anbindung an gängige Modellierungswerkzeuge<br />
© 2013 IAS, Universität Stuttgart 195
4.4 Modelchecker SMV<br />
ST II<br />
Vorgehensweise <strong>zur</strong> praktischen Anwendung von SMV<br />
1. Schritt:<br />
– <strong>Software</strong>entwurf mit industriell verbreitetem <strong>Entwicklung</strong>swerkzeug<br />
2. Schritt:<br />
– Umsetzung des Modells in die Sprache des verwendeten<br />
Verifikationswerkzeugs, hier SMV<br />
3. Schritt:<br />
– <strong>Formale</strong> Verifikation durch Model-Checking<br />
© 2013 IAS, Universität Stuttgart 196
4.4 Modelchecker SMV<br />
ST II<br />
Die SMV-Modellierungssprache<br />
– Textbasierte Modellierungssprache<br />
– Die Sprache besteht aus drei Teilsprachen:<br />
Definitional Language <strong>zur</strong> Datendeklaration<br />
Structural Language <strong>zur</strong> Instanziierung und<br />
Modellierung von Modulen<br />
Language of Expressions <strong>zur</strong> Beschreibung von Automaten<br />
– Modellierung ist deklarativ<br />
Module werden parallel ausgeführt<br />
Anweisungen in Modulen werden parallel ausgeführt<br />
© 2013 IAS, Universität Stuttgart 197
4.4 Modelchecker SMV<br />
ST II<br />
Beispiel für Zustandsautomaten-Modellierung<br />
a<br />
In SMV-Language of Expressions:<br />
Standby<br />
b<br />
c / z := true<br />
Aktiv<br />
State: {Begin,Standby,Aktiv}<br />
...<br />
case{<br />
...<br />
(State = Aktiv) & c :<br />
{<br />
next(State) := Standby;<br />
next(z) := true;<br />
}<br />
...<br />
}<br />
© 2013 IAS, Universität Stuttgart 198
4.4 Modelchecker SMV<br />
ST II<br />
Spezifikation der Anforderungen in der Logik-Sprache LTL oder CTL<br />
LTL = Linear Temporal Logic<br />
CTL = Computation Tree Logic<br />
LTL und CTL sind jeweils eine Art von Temporallogik<br />
Temporallogik ermöglicht das Ausdrücken von Eigenschaften, die<br />
– für alle Zustände des Zustandsraum gelten<br />
– nur für bestimmte Zustände im Zustandsraum gelten<br />
(Aussagen mit zeitlichen Abhängigkeiten)<br />
© 2013 IAS, Universität Stuttgart 199
4.4 Modelchecker SMV<br />
ST II<br />
Beispiel für die Formalisierung einer Anforderung<br />
Sicherheitsanforderung an die Steuerung eines pneumatischen<br />
Bremssystems eines Lkw:<br />
Natürlich-sprachliche Formulierung:<br />
„Das Auslass-Ventil (AV) und das Einlass-Ventil (EV) dürfen nie<br />
gleichzeitig geöffnet sein.”<br />
In CTL: AG(!(AV_geöffnet & EV_geöffnet))<br />
Legende:<br />
AG „Für alle Ausführungspfade im Zustandsraum vom<br />
Anfangszustand an muss immer gelten, dass ...“<br />
& Logische UND-Verknüpfung<br />
! Negation<br />
© 2013 IAS, Universität Stuttgart 200
4.4 Modelchecker SMV<br />
ST II<br />
Ergebnis-Ausgabe von SMV (1)<br />
1. Ergebnismöglichkeit: Das Modell erfüllt die Anforderung!<br />
Anforderung<br />
3 ist wahr<br />
Verifikationszeit:<br />
52,5 s<br />
Knotenanzahl<br />
im Zustandsraum:<br />
767525<br />
© 2013 IAS, Universität Stuttgart 201
4.4 Modelchecker SMV<br />
ST II<br />
Ergebnis-Ausgabe von SMV (2)<br />
Anforderung: Die Variablen anav und anbr dürfen nie gleichzeitig null sein<br />
Error-Trace von SMV:<br />
Erläuterung:<br />
Im 145. Schritt der Knotenfolge im Zustandsraum tritt eine<br />
Verletzung der Anforderung auf.<br />
Film: Verifikation<br />
© 2013 IAS, Universität Stuttgart 202
Frage zu Kapitel 4.4<br />
ST II<br />
Frage zu Kapitel 4.4<br />
Welche Aussagen stimmen für SMV?<br />
Antwort<br />
f<br />
f<br />
<br />
<br />
<br />
<br />
SMV ist ein Tool für endliche Zustandsmaschinen (FSM) mit CTL-<br />
Spezifikation<br />
Es erlaubt keine Aufteilung des Systemmodells in mehrere Module<br />
Es lässt sich auch nicht-deterministisches Verhalten spezifizieren<br />
Die Interaktion zwischen den Systemkomponenten kann nur synchron<br />
erfolgen<br />
© 2013 IAS, Universität Stuttgart 203
<strong>Software</strong>technik II<br />
ST II<br />
§ 4 <strong>Formale</strong> <strong>Methoden</strong> <strong>zur</strong> <strong>Entwicklung</strong> <strong>qualitativ</strong><br />
<strong>hochwertiger</strong> <strong>Software</strong><br />
4.1 Wozu formale <strong>Methoden</strong>?<br />
4.2 Grundlagen der formalen Spezifikation und Verifikation<br />
4.3 Vorgehensweise bei der formalen <strong>Software</strong>entwicklung<br />
4.4 Modelchecker SMV<br />
4.5 Hinweise für die Praxis<br />
© 2013 IAS, Universität Stuttgart 204
4.5 Hinweise für die Praxis<br />
ST II<br />
Szenarien für den Einsatz von formalen <strong>Methoden</strong><br />
Einsatz<br />
ja: – Folgekosten von Fehlern sind groß im Vergleich zu den<br />
<strong>Entwicklung</strong>skosten<br />
– Personen/Sachschäden<br />
5% aller Projekte<br />
nein:<br />
Minimierung von Zeit und Kosten der <strong>Entwicklung</strong> ist Primärziel<br />
95% aller Projekte<br />
© 2013 IAS, Universität Stuttgart 205
4.5 Hinweise für die Praxis<br />
ST II<br />
Hohe Folgekosten<br />
– Rückrufaktion bei Systemen in großer Stückzahl<br />
PKW<br />
Haushaltsgeräte<br />
– Vertrauensverlust<br />
Zahlungsverkehr in Banken<br />
Smartcardsystem<br />
Telekom<br />
Personenschäden/hohe Sachschäden<br />
– Verlust des Gesamtsystems<br />
Raumfahrt<br />
Flugzeug<br />
– Störungen/Beeinträchtigungen<br />
KKW<br />
Verkehrsleitsystem<br />
chemische Industrie<br />
medizinische Geräte<br />
© 2013 IAS, Universität Stuttgart 206
Vorbereitungsfragen<br />
ST II<br />
Vorbereitungsfragen zu § 4<br />
Frage 1: <strong>Software</strong>-Metriken (SS 10)<br />
Schreiben Sie die CTL-Ausdrücke, die in den Abbildungen I und II dargestellt sind.<br />
Frage 2: <strong>Formale</strong> <strong>Entwicklung</strong> (SS 05)<br />
Sie entwickeln ein komplexes System für den Einsatz in der Luftfahrt. Das System besteht<br />
aus sicherheitskritischen und nicht sicherheitskritischen Teilen.<br />
a) Wo würden Sie formal entwickeln? Begründen Sie Ihre Antwort.<br />
b) Welches Problem ergibt sich bei der teilweise formalen <strong>Entwicklung</strong>?<br />
© 2013 IAS, Universität Stuttgart 207
Change language