4 Formale Methoden zur Entwicklung qualitativ hochwertiger Software

ias.uni.stuttgart.de

4 Formale Methoden zur Entwicklung qualitativ hochwertiger Software

Softwaretechnik II

§ 4 Formale Methoden zur Entwicklung qualitativ

hochwertiger Software

Lernziele

ST II

– Wissen, was formale Methoden sind

– Einsatz formaler Methoden zur Erstellung mathematisch nachweisbar

korrekter IT-Systeme kennen

– Verstehen, dass mit der Einsatztiefe formaler Methoden das Vertrauen in

die Korrektheit der so entwickelten SW-Komponenten erwächst

Formale Sprachen kennen

– Modelchecker „Symbolic Model Verifier“ (SMV) kennen

Literatur

– G. Thaller: Software- Test, Verifikation und Validation, Heise Verlag, 2000

– W. Ehrenberger: Software-Verifikation - Verfahren für den

Zuverlässigkeitsnachweis von Software, Hanser Verlag, 2001

– A. Moik: Ingenieurgerechte formale Methoden für die Entwicklung von

sicheren Automatisierungssystemen, Shaker Verlag, 2002

© 2013 IAS, Universität Stuttgart 162


Softwaretechnik II

§ 4 Formale Methoden zur Entwicklung qualitativ

hochwertiger Software

ST II

4.1 Wozu formale Methoden?

4.2 Grundlagen der formalen Spezifikation und Verifikation

4.3 Vorgehensweise bei der formalen Softwareentwicklung

4.4 Modelchecker SMV

4.5 Hinweise für die Praxis

© 2013 IAS, Universität Stuttgart 163


4.1 Wozu formale Methoden?

ST II

Vorgehensweise im Brückenbau

F HR,A

F A

a

r 0

r 1

I

F B

S

F HR,B

F GO

F G

Warum stürzen so selten Brücken ein?

Film: Modellbildung

© 2013 IAS, Universität Stuttgart 164


4.1 Wozu formale Methoden?

ST II

Schlagzeilen aus Zeitungsmeldungen

Millionenschaden durch

kostenloses Telefonieren

Hacker dringen in

militärische Netze ein

Airbusabsturz

Softwarefehler?

P ostgiro 3000

Zin sen w erden m an u ell

berech n et!

Problemfeld: Verlässlichkeit von Software

© 2013 IAS, Universität Stuttgart 165


4.1 Wozu formale Methoden?

ST II

Einsatzgebiete

– Security (Vertraulichkeit, Integrität, Verfügbarkeit)

– Safety (Betriebssicherheit, technische Sicherheit)

– Privacy (Datenschutz, Schutz der Privatsphäre)

Aufgabenstellung

– Nachweis spezifischer Eigenschaften eines Softwaresystems

– Korrekte Implementierung eines Softwaresystems

© 2013 IAS, Universität Stuttgart 166


4.1 Wozu formale Methoden?

ST II

Anwendungsbereiche

– Kernkraftwerke

– Verkehr/Transport

Eisenbahnwesen, insbesondere Signaltechnik

Flugzeugsteuerung, Flugverkehrslenkung

Kraftfahrzeug: elektronische Motorregelung, ABS

– Medizintechnik

– Telekommunikation

– Hardware: Prozessordesign

© 2013 IAS, Universität Stuttgart 167


4.1 Wozu formale Methoden?

ST II

Formale Methoden in Standards, Richtlinien, Empfehlungen

– Bewertungskriterien für die Sicherheit von IT-Systemen (security) fordern ab

gewissen Stufen formale Spezifikation von Sicherheitsmodellen und Funktionalität

und Verifikation

Trusted Computer System Evaluation Criteria

(TCSEC, “Orange Book”) US NCSC

International standard (ISO/IEC 15408) for computer security

Harmonisierte IT-Sicherheitskriterien (ITSEC Handbuch)

– Vorgaben durch Zertifizierungsstelle

Darlington NPS, TCAS

TÜV Rheinland: diversitäre Rückentwicklung

TÜV zieht Vorgaben für formale Methoden in Erwägung

BSI und andere für sichere Systeme zuständige Stellen

Entwicklung von Empfehlungen in verschiedenen technischen Bereichen

“Railway applications: Software for Railway Control and Protection Systems”

(CEN/CENELEC-Entwurf, 1993)

Vorschläge für Standards sicherheitsrelevanter Software: Formale Methoden

der Spezifikation und Verifikation empfohlen für höhere Stufen ( safety

integrity levels)

© 2013 IAS, Universität Stuttgart 168


4.1 Wozu formale Methoden?

ST II

Kriterien zur Beurteilung vertrauenswürdiger Systeme

IT- Sicherheitskriterien (BSI)

Qualitätsmaßstab

Q 0 Unzureichend

Q 1 Getestet

Q 2 Methodisch getestet

Q 3 Teilanalysiert

Q 4 Informell analysiert

Q 5 Semiformal analysiert

Q 6 Formal analysiert

Q 7 Formal verifiziert

Hohe Qualitätsstufen

Q 5: Die Anforderungen sind überwiegend formal

zu spezifizieren. Die Entwurfsbeschreibung

liegt in semiformaler Notation vor. Letztere

sowie die Implementierung sind sorgfältig mit

semiformalen Methoden zu analysieren und

auf Konsistenz mit den Anforderungen zu

prüfen

Q 6: Anforderungen und Entwurfsbeschreibungen

sind in formaler Notation niederzulegen und

auf Konsistenz zu verifizieren. Die

Implementierung ist sorgfältig auf Konsistenz

mit der Entwurfsbeschreibung zu prüfen.

Q 7: Anforderungen und Entwurfsbeschreibungen

sind in formaler Notation niederzulegen und

auf Konsistenz zu verifizieren. Die

Implementierung ist in einer Sprache mit

formal definierter Semantik auszuführen. Die

Konsistenz zwischen Entwurfsbeschreibung

und Implementierung ist formal zu verifizieren.

© 2013 IAS, Universität Stuttgart 169


Frage zu Kapitel 4.1

ST II

Frage zu Kapitel 4.1

Um welche Art von Sicherheit handelt es sich in folgenden Situationen?

Situationen:

Eine sichere Datenübertragung zwischen Server und

Client, damit kein Unbefugter die Daten abhören kann

f


Privacy


Security

Safety

Eine sichere Steuerungssoftware für ein medizinisches

Gerät, damit kein Fehler auftritt

f

f

Privacy

Security

Safety


In der Datenbank dürfen nur bestimmte

personenbezogenen Daten gespeichert werden

f

f


Privacy

Security

Safety

© 2013 IAS, Universität Stuttgart 170


Softwaretechnik II

ST II

§ 4 Formale Methoden zur Entwicklung qualitativ

hochwertiger Software

4.1 Wozu formale Methoden?

4.2 Grundlagen der formalen Spezifikation und Verifikation

4.3 Vorgehensweise bei der formalen Softwareentwicklung

4.4 Modellchecker SMV

4.5 Hinweise für die Praxis

© 2013 IAS, Universität Stuttgart 171


4.2 Grundlagen der formalen Spezifikation und Verifikation

ST II

Die Formale Entwicklung in der Übersicht (Live-Mitschrieb)

Informelle

Beschreibung

Formale

Eigenschaften

Formale

Systembeschreibung

Korrektheitsbeweise

Formale Beschreibng

der Implementierung

Physikalisch-technische

Realisierung

© 2013 IAS, Universität Stuttgart 172


4.2 Grundlagen der formalen Spezifikation und Verifikation

ST II

C.A.R. Hoare:

“ I hold the opinion that the construction of computer programs is a

mathematical activity like the solution of differental equations, that

programs can be derived from their specification through mathematical

insight, calculations, and proof, using algebraic laws as simple and

elegant as those of elementary arithmetic.”

Formale Spezifikation und Verifikation von Programmen

Nachweis mit mathematischer Exaktheit, dass ein Programm eine

gestellte Aufgabe erfüllt

Voraussetzung

Verwendete Begriffe und Methoden müssen exakt definiert und

formuliert werden

© 2013 IAS, Universität Stuttgart 173


4.2 Grundlagen der formalen Spezifikation und Verifikation

ST II

Formale Spezifikation

Formallogische Sprachen erlauben objektivierte Beschreibungen

durch mathematisch definierte Syntax und Semantik

– Syntax:

Sprachen als mathematisch definierte Mengen von Zeichenreihen

Grammatiken, Typen, induktive Syntaxregeln

Systemunterstützung: Editoren, Syntaxanalyse, Typcheck,...

– Semantik:

Zuordnung von (Klassen von) mathematischen Strukturen zu

Sprachkonstrukten

Mengen, Relationen, Funktionen, algebraische Strukturen

Die Prädikatenlogik bildet den Kern der meisten Formalismen

© 2013 IAS, Universität Stuttgart 174


4.2 Grundlagen der formalen Spezifikation und Verifikation

ST II

Formale Verifikation

Nachweis mit formalen, mathematisch logischen Schlussweisen

– Ein Programm ist korrekt bezüglich einer gegebenen formalen

Spezifikation

– Eine formale Spezifikation ist eine Verfeinerung einer anderen formalen

Spezifikation

– Die Transformation eines bezüglich einer Spezifikation korrekten

Programms in eine Implementierungssprache ist korrekt

© 2013 IAS, Universität Stuttgart 175


4.2 Grundlagen der formalen Spezifikation und Verifikation

ST II

Beschreibung von Objekten und Beziehungen

zwischen Objekten

– Informell

Chico (C) ist ein Lebewesen (l)

Alle Menschen (m) sind Lebewesen

Chico gehört Susanne (S)

Lebende Besitzgegenstände sind Tiere (t)

– Formal:

Objektbezeichner: S, C ... l(C)

Einstellige Prädikatsymbole: ..., l(...), m(...), t(...), ...

Relationssymbole: g (gehört), ...

Alle Menschen sind Lebewesen: "x, (m(x) I (x))

Chico gehört Susanne: g(C, S)

Lebende Besitzgegenstände sind Tiere : " x, y . (( I(y) g(y, x)) t(y) )

© 2013 IAS, Universität Stuttgart 176


4.2 Grundlagen der formalen Spezifikation und Verifikation

ST II

Ist Chico ein Tier?

Gegeben die Aussage von oben

A

x, y . (( I (y) g (y, x )) t (Y) )

<

I (C) g (C, S)

Einsetzen

UND

((I (C)

<

g (C, S)) t (C))

((I (C)

<

g (C, S))

Modus Ponens

t (C)

© 2013 IAS, Universität Stuttgart 177


4.2 Grundlagen der formalen Spezifikation und Verifikation

ST II

Klassifizierung möglicher Vorgehensweisen beim Einsatz

formaler Methoden

– Klassische Verifikation

Annotierung von Programmen mit Bedingungen (Assertions)

= Spezifikation des Programms

Korrektheit: Konsistenz von Programm und Assertions

– Gleichzeitige Entwicklung von Spezifikation, Programm und Beweisen

Methode der schrittweisen Verfeinerung

Vorgehen z.B. Programmschleife

- Spezifikation der Invarianten

- Realisierung der Schleife gemäß Invarianten

– Systematische Entwicklung des Programms aus der Spezifikation

Abstrakte Spezifikation wird über mehrere Zwischenebenen in

ausführbaren Programmtext transformiert

Verwendung von formalisierten Transformationsregeln

© 2013 IAS, Universität Stuttgart 178


4.2 Grundlagen der formalen Spezifikation und Verifikation

ST II

Korrektheit von Programmen

1. Partielle Korrektheit

– Wenn ein Ergebnis abgeliefert wird, ist es korrekt bezüglich

der Problemstellung

– Keine Garantie, dass Ergebnis abgeliefert wird

2. Terminierung

– Programm kommt zum Ende

– Partielle Korrektheit + Terminierung = Totale Korrektheit

3. Keine Laufzeitfehler

– Bsp.: Division durch “0”, Überlauf

© 2013 IAS, Universität Stuttgart 179


4.2 Grundlagen der formalen Spezifikation und Verifikation

ST II

Korrektheit von Parallelen Programmen

4. Interferenzfreiheit

Keine Komponente eines parallelen Programms mischt sich in

unerwünschter Weise in die Berechnung einer anderen Komponente ein

5. Deadlockfreiheit

Keine Situation, in der alle noch nicht terminierten Komponenten unendlich

lange auf die Erfüllung einer Bedingung warten

6. Korrektheit ohne Fairness-Annahme

© 2013 IAS, Universität Stuttgart 180


4.2 Grundlagen der formalen Spezifikation und Verifikation

ST II

Deduktive Verifikation (Theorem Proving)

Beweis durch Deduktion mit Axiomen und Inferenzregeln

Vorteile

• Anwendbar auf alle Systeme

• Jede korrekte Eigenschaft kann verifiziert werden

Nachteile

• Nicht vollständig automatisierbar

• Aufwand nicht vorhersagbar

© 2013 IAS, Universität Stuttgart 181


4.2 Grundlagen der formalen Spezifikation und Verifikation

ST II

Algorithmische Verifikation (Model Checking)

Beweis durch vollständige Exploration des Zustandsraums

Vorteile

• Automatische Verifikation

• Error-Trace bei Fehlern

Nachteile

• Nur Systeme mit endlich vielen Zuständen

• Problem: Explosion des Zustandsraums

© 2013 IAS, Universität Stuttgart 182


Frage zu Kapitel 4.2

ST II

Frage zu Kapitel 4.2

Welche Eigenschaften gehören zu „Partieller Korrektheit“?

Antwort

f

f




Programm kommt zum Ende

Eingabegrößen werden gemäß der Spezifikation auf Ausgabegrößen

abgebildet

Kein Laufzeitfehler

© 2013 IAS, Universität Stuttgart 183


Softwaretechnik II

ST II

§ 4 Formale Methoden zur Entwicklung qualitativ

hochwertiger Software

4.1 Wozu formale Methoden?

4.2 Grundlagen der formalen Spezifikation und Verifikation

4.3 Vorgehensweise bei der formalen Softwareentwicklung

4.4 Modellchecker SMV

4.5 Hinweise für die Praxis

© 2013 IAS, Universität Stuttgart 184


4.3 Vorgehensweise bei der formalen Softwareentwicklung

ST II

Formale Spezifikation des Systems

Informelle

Anforderungsbeschreibung

Sicherheitsrelevante

Anforderungen

Formale

Eigenschaften

formal

Beweis über Erfüllung

der sicherheitsrelevanten

Anforderungen

Operationelle

Anforderungen

Formale

Systembeschreibung

Beweis über Umsetzung der

formalen Systembeschreibung

nicht formal

Rahmensystem

Verfeinerung

Formale Beschreibung

der Implementierung

Programmquelltext

Physikalischtechnische

Realisierung

© 2013 IAS, Universität Stuttgart 185


4.3 Vorgehensweise bei der formalen Softwareentwicklung

ST II

Beispiel: Systemstruktur Verkehrsleitsystem

NS

OW

Verkehrsleitsystem

Verkehrsüberwachung

Ampelsystem

Verkehrssteuerung

Ampelsteuerungsmodul

Ampelstatistik

Ampelinit

Schalten

Druck-Ausgabe

Schaltprotokoll

Statistikauswertung

© 2013 IAS, Universität Stuttgart 186


4.3 Vorgehensweise bei der formalen Softwareentwicklung

ST II

Anforderungsspezifikation

Anforderung 317 (1)


Die Signale an zwei feindlichen Fahrstraßen (Kreuzung) dürfen nicht

gleichzeitig grün sein

Anforderung 318 (1)

Das Verkehrsleitsystem muss an einer Kreuzung die Rot-Grün-Phasen für

optimalen Durchsatz von Fahrzeugen regeln

© 2013 IAS, Universität Stuttgart 187


4.3 Vorgehensweise bei der formalen Softwareentwicklung

ST II

Sicherheitsmodell Ampelsteuerungsmodul

Informell:

Signale an ns_ampel und ow_ampel nicht gleichzeitig grün

Formal: S_SPEC

ist_sichere_ampel (ns_ampel, ow_ampel) =

ns_ampel = rot OR ow_ampel = rot

© 2013 IAS, Universität Stuttgart 188


4.3 Vorgehensweise bei der formalen Softwareentwicklung

ST II

Funktionale Spezifikation Ampelsteuerungsmodul

Informell:

Die Prozedur “schalten” ändert die Farben der ns_ampel

und der ow_ampel gemäß folgendem Schaltplan:....

Formal: L_SPEC

funktionale Spezifikation

PROC schalten

WHEN ns_ampel = rot AND ow_ampel = gruen THEN

ns_ampel = rot AND ow_ampel = gelb

ELSEWHEN ns_ampel = rot AND ow_ampel = gelb THEN

ns_ampel = gruen AND ow_ampel = rot

ELSEWHEN ns_ampel = gruen AND ow_ampel = rot THEN

ns_ampel = gelb AND ow_ampel = rot

OTHERWISE ns_ampel = rot AND ow_ampel = gruen

INITIAL: ns_ampel = rot AND ow_ampel = gelb

© 2013 IAS, Universität Stuttgart 189


4.3 Vorgehensweise bei der formalen Softwareentwicklung

ST II

Abstraktes Programm

Informell:

Structured Design

OOD

Formal: A_SPEC

PROCEDURE schalten

BODY:IF nsa = rot

THEN owa := next (owa);

IF owa = rot

then nsa := next (nsa)

FI

ELSE nsa := next (nsa);

IF nsa = rot

THEN owa := next (owa)

FI

FI

PROCEDUREEND

FUNCTION: next: farbe farbe

AXIOMS: next (gruen) = gelb;

next (gelb) = rot;

next (rot) = gruen

© 2013 IAS, Universität Stuttgart 190


4.3 Vorgehensweise bei der formalen Softwareentwicklung

ST II

Verifikation der Sicherheitsanforderungen

Informell:

– Systematisches Testen und Inspektion

– Gefahr verborgener Fehler

Formal:

– Nachweis mathematischer Aussagen

L_SPEC erfüllt S_SPEC

A_SPEC erfüllt L_SPEC

– erfolgreicher Beweis garantiert Fehlerfreiheit

– Fehlersuche und -Korrektur durch Fehlschlaganalyse

© 2013 IAS, Universität Stuttgart 191


Frage zu Kapitel 4.3

ST II

Frage zu Kapitel 4.3

Welche Aussagen gelten bei der formalen Softwareentwicklung?

Antwort

f

f




Alle Anforderungen müssen formal beschrieben werden

Sicherheitsnachweis der formal beschriebenen

Sicherheitsanforderungen muss vorhanden sein

Nur die zeitbehafteten Sicherheitsanforderungen werden formal

beschrieben

© 2013 IAS, Universität Stuttgart 192


Softwaretechnik II

ST II

§ 4 Formale Methoden zur Entwicklung qualitativ

hochwertiger Software

4.1 Wozu formale Methoden?

4.2 Grundlagen der formalen Spezifikation und Verifikation

4.3 Vorgehensweise bei der formalen Softwareentwicklung

4.4 Modelchecker SMV

4.5 Hinweise für die Praxis

© 2013 IAS, Universität Stuttgart 193


4.4 Modelchecker SMV

ST II

Merkmale von SMV (Symbolic Model Verifier )

– Unterstützung zur Verifikation von Modellen in der Hard- und

Softwareentwicklung

– Beweisführung vollständig automatisch

– Grafische Benutzungsoberfläche

– Modellierung und Anforderungsspezifikation erfolgt textbasiert

Formale Sicherheitsanforderungen

Formales Modell

Model-Checking mit SMV

O.K.

Gegenbeispiel (Error-Trace)

© 2013 IAS, Universität Stuttgart 194


4.4 Modelchecker SMV

ST II

Symbolic Model Verifier

– „Symbolisches“ Model-Checking. Der Zustandsraum wird implizit

dargestellt. Effiziente Technik, die die Verarbeitung großer Zustandsräume

ermöglicht.

– SMV wurde ursprünglich für die Verifikation von Hardwaremodellen

entwickelt

– Haupt-Entwickler von SMV: Ken McMillan, Cadence Berkley Labs,

Berkeley, USA

– SMV ist frei verfügbar: http://www-cad.eecs.berkeley.edu/~kenmcmil/

Ziel:

– Industrielle Einsetzbarkeit auch in der Softwareentwicklung

Erforderliche Maßnahme:

– Anbindung an gängige Modellierungswerkzeuge

© 2013 IAS, Universität Stuttgart 195


4.4 Modelchecker SMV

ST II

Vorgehensweise zur praktischen Anwendung von SMV

1. Schritt:

Softwareentwurf mit industriell verbreitetem Entwicklungswerkzeug

2. Schritt:

– Umsetzung des Modells in die Sprache des verwendeten

Verifikationswerkzeugs, hier SMV

3. Schritt:

Formale Verifikation durch Model-Checking

© 2013 IAS, Universität Stuttgart 196


4.4 Modelchecker SMV

ST II

Die SMV-Modellierungssprache

– Textbasierte Modellierungssprache

– Die Sprache besteht aus drei Teilsprachen:

Definitional Language zur Datendeklaration

Structural Language zur Instanziierung und

Modellierung von Modulen

Language of Expressions zur Beschreibung von Automaten

– Modellierung ist deklarativ

Module werden parallel ausgeführt

Anweisungen in Modulen werden parallel ausgeführt

© 2013 IAS, Universität Stuttgart 197


4.4 Modelchecker SMV

ST II

Beispiel für Zustandsautomaten-Modellierung

a

In SMV-Language of Expressions:

Standby

b

c / z := true

Aktiv

State: {Begin,Standby,Aktiv}

...

case{

...

(State = Aktiv) & c :

{

next(State) := Standby;

next(z) := true;

}

...

}

© 2013 IAS, Universität Stuttgart 198


4.4 Modelchecker SMV

ST II

Spezifikation der Anforderungen in der Logik-Sprache LTL oder CTL

LTL = Linear Temporal Logic

CTL = Computation Tree Logic

LTL und CTL sind jeweils eine Art von Temporallogik

Temporallogik ermöglicht das Ausdrücken von Eigenschaften, die

– für alle Zustände des Zustandsraum gelten

– nur für bestimmte Zustände im Zustandsraum gelten

(Aussagen mit zeitlichen Abhängigkeiten)

© 2013 IAS, Universität Stuttgart 199


4.4 Modelchecker SMV

ST II

Beispiel für die Formalisierung einer Anforderung

Sicherheitsanforderung an die Steuerung eines pneumatischen

Bremssystems eines Lkw:

Natürlich-sprachliche Formulierung:

„Das Auslass-Ventil (AV) und das Einlass-Ventil (EV) dürfen nie

gleichzeitig geöffnet sein.”

In CTL: AG(!(AV_geöffnet & EV_geöffnet))

Legende:

AG „Für alle Ausführungspfade im Zustandsraum vom

Anfangszustand an muss immer gelten, dass ...“

& Logische UND-Verknüpfung

! Negation

© 2013 IAS, Universität Stuttgart 200


4.4 Modelchecker SMV

ST II

Ergebnis-Ausgabe von SMV (1)

1. Ergebnismöglichkeit: Das Modell erfüllt die Anforderung!

Anforderung

3 ist wahr

Verifikationszeit:

52,5 s

Knotenanzahl

im Zustandsraum:

767525

© 2013 IAS, Universität Stuttgart 201


4.4 Modelchecker SMV

ST II

Ergebnis-Ausgabe von SMV (2)

Anforderung: Die Variablen anav und anbr dürfen nie gleichzeitig null sein

Error-Trace von SMV:

Erläuterung:

Im 145. Schritt der Knotenfolge im Zustandsraum tritt eine

Verletzung der Anforderung auf.

Film: Verifikation

© 2013 IAS, Universität Stuttgart 202


Frage zu Kapitel 4.4

ST II

Frage zu Kapitel 4.4

Welche Aussagen stimmen für SMV?

Antwort

f

f





SMV ist ein Tool für endliche Zustandsmaschinen (FSM) mit CTL-

Spezifikation

Es erlaubt keine Aufteilung des Systemmodells in mehrere Module

Es lässt sich auch nicht-deterministisches Verhalten spezifizieren

Die Interaktion zwischen den Systemkomponenten kann nur synchron

erfolgen

© 2013 IAS, Universität Stuttgart 203


Softwaretechnik II

ST II

§ 4 Formale Methoden zur Entwicklung qualitativ

hochwertiger Software

4.1 Wozu formale Methoden?

4.2 Grundlagen der formalen Spezifikation und Verifikation

4.3 Vorgehensweise bei der formalen Softwareentwicklung

4.4 Modelchecker SMV

4.5 Hinweise für die Praxis

© 2013 IAS, Universität Stuttgart 204


4.5 Hinweise für die Praxis

ST II

Szenarien für den Einsatz von formalen Methoden

Einsatz

ja: – Folgekosten von Fehlern sind groß im Vergleich zu den

Entwicklungskosten

– Personen/Sachschäden

5% aller Projekte

nein:

Minimierung von Zeit und Kosten der Entwicklung ist Primärziel

95% aller Projekte

© 2013 IAS, Universität Stuttgart 205


4.5 Hinweise für die Praxis

ST II

Hohe Folgekosten

– Rückrufaktion bei Systemen in großer Stückzahl

PKW

Haushaltsgeräte

– Vertrauensverlust

Zahlungsverkehr in Banken

Smartcardsystem

Telekom

Personenschäden/hohe Sachschäden

– Verlust des Gesamtsystems

Raumfahrt

Flugzeug

– Störungen/Beeinträchtigungen

KKW

Verkehrsleitsystem

chemische Industrie

medizinische Geräte

© 2013 IAS, Universität Stuttgart 206


Vorbereitungsfragen

ST II

Vorbereitungsfragen zu § 4

Frage 1: Software-Metriken (SS 10)

Schreiben Sie die CTL-Ausdrücke, die in den Abbildungen I und II dargestellt sind.

Frage 2: Formale Entwicklung (SS 05)

Sie entwickeln ein komplexes System für den Einsatz in der Luftfahrt. Das System besteht

aus sicherheitskritischen und nicht sicherheitskritischen Teilen.

a) Wo würden Sie formal entwickeln? Begründen Sie Ihre Antwort.

b) Welches Problem ergibt sich bei der teilweise formalen Entwicklung?

© 2013 IAS, Universität Stuttgart 207

Weitere Magazine dieses Users
Ähnliche Magazine