Fehlervermeidung und Fehlertoleranz im Software

Fehlervermeidung und Fehlertoleranz im Software-Bereich
• Hardware: Entwurfsfehler, Alterungsfehler, Fehler aufgrund äußerer
Einflüsse
• Software: altert (leider!?) nicht, äußere Einflüsse ebenfalls irrelevant
→ im weitesten Sinne sind alle Fehler „Entwurfsfehler“
Fehlervermeidung bei der SW-Entwicklung
→ Software-Engineering-Techniken geeignet ansetzen
Projekt-*
modelle
Werk-*
zeuge
Beweistechniken
Inspek-*
tionen
Tests*
* aktuelle Themen
in Praxis heute
1. Projektmodelle
• Formalisierung, Vereinheitlichung des SW-Entwicklungsprozesses
(Einteilung in Phasen)
• Dient u.a. besserer Projektüberwachung
Fehlertoleranz
25.04.2007
16
2. CASE-Werkzeuge
• Für die verschiedenen Phasen des SW-Entwicklungsprozesses:
Spezifikation, Entwurf, Implementierung, Test ...
• Konsistentes Vorgehen in den einzelnen Phasen und (vor allem) –
angestrebt – phasenübergreifend
• Heute vieles auf dem Markt vorhanden, Einsatz aber noch recht
schleppend
3. Beweistechniken
• Korrektheitsbeweise für Programme angestrebt seit 1960er Jahren
• Prohibitiver Aufwand in größeren Software-Projekten (bisher), trotz
partieller Werkzeugunterstützung
• Erfolgreich angewendet bisher nur in wenigen, als hochkritisch
erachteten Projekten (etwa Teilsysteme in der Luftfahrt)
• Breite Durchsetzung nach wie vor offen
• Heute kein Thema der Praxis (mehr)
Fehlertoleranz
25.04.2007
17
4. Inspektionen
• Begleitend zur Entstehung eines SW-Systems
• Wohldefinierte Zeitpunkte:
- Entwurfsinspektion I0 (Function Level Inspec.)
Nach Festlegung der Modulspezifikationen
- Entwurfsinspektion I1 (Design Complete Inspec.)
Nach Abschluss des Entwurfs: Vollst., Detaillier.
- Code-Inspektion I2
Nach erfolgter erster fehlerfreier Übersetzung
- Testplaninspektion IT1
Testplan wurde begleitend entwickelt
- Testfallinspektion IT2
- Vollständigkeit, Überdeckung
- Dokumentationsinspektionen
Qualität der internen/externen Systembeschr.
• Ziele / Vorgehen:
- Stets im Team
- Steigerung Produktqualität/Produktivität
- Steigerung Produktkenntnisse der Beteiligten
Fehlertoleranz
25.04.2007
18
Inspektion
zunehmender
Aufwand
zunehmender
Nutzen
• Bisweilen noch unterschieden:
- Code Reading
„Lesen“ eines Programmes durch Person ≠ Autor
- Walk Trough
Ähnlich Inspektion, doch ohne Auswertungen (Fehlerlisten,
-klassifikationen, Häufigkeitsvert.)
• Einordnung vom Nutzen her:
Walk Through
Code Reading
Fehlertoleranz
Integration
zunehmende
5. Tests
• 4 Stufen der Testdurchführung:
- Modultest
- Komponententest
- Systemtest
- Anwendungstest (bei/nach Installation)
• Problem bei all dem: „Program testing can be used to show the
presence of bugs, but never to show their absence.“
25.04.2007
19
• Lösungsansatz: Testdatenselektionskriterien, legen Anforderungen
an einen Test fest zur Vermeidung von „Willkür&Gutdünken“
Ggf. Unterstützung durch Testdatengeneratoren und andere
Hilfsmittel zur Testdurchführung
• Testdatenselektionskriterien (Gliederung, Beispiele):
- Strukturelle (abh. vom konkr. Programm-Code)
• C1: jede Programmanweisung ≥ 1∗ ausgef.
• C2: jeder Programmzweig ≥ 1∗ durchl.
- Black Box Kriterien (unabh. vom Code)
Festlegung aufgrund der Progr.spezifikationen und Kenntnis der
Anwendungserfordernisse
Problem: Sonderfallbehandlung (häufig vorkommend in Programmen) bleibt außer Betracht
Strukturelle + Black Box Kriterien meist in Kombination/ergänzend
angewandt → erhöht Fehlererkennungswahrscheinlichkeit
Fehlertoleranz
25.04.2007
20
Software-Fehlertoleranz
Erkenntnis: Fehlervermeidung bei der SW-Entwicklung führt i.d.R. noch
nicht zu völlig fehlerfreiem SW-Produkt
Lösungen:
• Mit Fehlern („Abstürzen“) leben: was man meist tut
• Einfache Replikation von Komponenten à la TMR/NMR: bringt bei SW
nichts
• Verfahren der Software-Diversität bei kritischen Anwendungen
(Aufwand!)
Diversitär bedeutet, daß eine SW-Funktion über zwei oder mehr
unterschiedliche Wege realisiert wird (Versionen, Alternativen)
Auswahl/Kombination folgender Möglichkeiten:
• Unterschiedliche Programmiersprachen, Entwurfsmethoden,
Spezifikationstechniken
• Unterschiedliche Algorithmen bei Realisierung
• Unterschiedliche Projektteams
Fehlertoleranz
25.04.2007
21
Wie wird Software-Diversität eingesetzt?
Zwei Techniken: Recovery Blocks und N-Version Programming
BEGIN
Recovery Blocks
i:=0
i:=i+1
Versionsauswahl Vi
V1
...
V2
Abnahmetest
Versionen
n≥2
Vn
Erfolg
Mißerfolg
i<n
Fehlernachricht
BEGIN
System S
Systemumgebung
Problem: Abnahmetest
• Bietet sich nicht bei allen Aufgabenstellungen an
• U.U. komplex, zeitaufwändig, fehlerträchtig, keine 100% Sicherheit
Fehlertoleranz
25.04.2007
22
BEGIN
V1
V2
...
N-Version Programming
Versionen
n≥3
Vn
Voter V
Voting
erfolgreich
JA
NEIN
Fehlernachricht
BEGIN
System S
Systemumgebung
Bewertung:
• I.G. zu Recovery Blocks: kein Abnahmetest ☺
• Sämtliche n Versionen auszuführen, bei Recovery Blocks meist nur
eine (Aufwand!)
• Benutzt u.a. in Reaktorschutzsystemen: 1 Spezifikation, Diversität
bei Entwicklung/Implementierung
Fehlertoleranz
25.04.2007
23
Fehlererkennung und Fehlerbehandlung in
Datenbanksystemen „und Umfeld“
• Vorgenannte Techniken zur Fehlervermeidung bei der SW-Entwicklung
natürlich auch hier weit verbreitet
• Techniken der Software-Fehlertoleranz (Divers.) werden dagegen aus
Aufwandsgründen nie eingesetzt (also Recovery Blocks, N-Version P.)
• Software Fehlertoleranz kann aber neben Software-Diversität auch
Mitführen redundanter Information „durch die Software“ bedeuten
⇒ übliche Vorgehensweise bei Datenbanksystemen
„Traditionelle“ Fehlerbehandlung in Datenbanksystemen geht aus von
Transaktionskonzept und legt Fehlermodell und Fehlerbehandlungsmaßnahmen zugrunde weitgehend unter Ausschluss von DBVS-Fehlern
Fehlertoleranz
25.04.2007
24
Abriss zur traditionellen Fehlerbehandlung in
Datenbanksystemen (Mehr Details in Vorlesung „DBS2“)
• Transaktion:
Sequenz zusammengehöriger Operationen auf einer Datenbank
[
BOT
]
Oi
t
EOT
Eigenschaften:
- Atomarität: Transaktion wird entweder komplett oder gar nicht auf
der DB ausgeführt
- Konsistenzerhaltung (Consistency): Transaktion überführt von
einem konsistenten in einen konsistenten DB-Zustand
- Isolation: Transaktion wird während des Ablaufs (d.h. solange noch
„offen“) nach außen hin „abgeschottet“: Single-User-Eindruck
- Dauerhaftigkeit: Änderungen am DB-Zustand müssen nach
Abschluss der zugehörigen Transaktion auf jeden Fall „überleben“
(„egal was passiert“)
∑ACID-Prinzip
Fehlertoleranz
25.04.2007
25
• Fehlermodell:
Sagt aus, mit welchen Fehlern (i.S. von Failure) man bei der
Transaktionsverarbeitung rechnet:
- Transaktions abbrüche (Transaction Failure)
versagen
Einzelne Transaktion scheitert, etwa durch Fehler im
Anwendungsprogramm, Deadlock etc.
- System ausfälle
versagen (System Failure)
Gesamte DB-Verarbeitung bricht abrupt ab, etwa durch Stromausfall,
BS-Fehler etc.
- Platten- und Übertragungsfehler in der Datenbank (Media Failure)
Datenverlust auf Externspeichern, etwa durch Head Crash, inkorrekte
E/A-Operationen etc.
Was hierbei implizit ausgeschlossen (wegdefiniert) wird:
Unbemerkt entstandene Inkonsistenzen in der Datenbank (Datenverfälschung im weitesten Sinn) durch DBVS-Fehler, E/A-Fehler, BS-Fehler etc.:
Thema dieser Vorlesung
Fehlertoleranz
25.04.2007
26
• Fehlerbehandlungsmaßnahmen:
ist teuer
DB auf Platte bleibt erhalten
- Bei Transaktionsabbruch:
R1-Recovery: Änderungen, soweit von der Transaktion durchgeführt und bereits in der DB, werden mit Hilfe der Protokolldateieinträge (Log-Daten) rückgängig gemacht (→ Atomarität!)
- Bei Systemausfall:
R2-Recovery (für alle Transaktionen, die zum Fehlerzeitpunkt
bereits abgeschlossen waren):
„Nachfahren“ der Änderungen – soweit nötig – mit Hilfe der LogDaten (→ Dauerhaftigkeit!)
R3-Recovery (für alle Transaktionen, die zum Fehlerzeitpunkt noch
offen waren): wie R1-Recovery (→ Atomarität!)
- Bei Platten- und Übertragungsfehler:
R4-Recovery (für Transaktionen, die zum Fehlerzeitpunkt bereits
abgeschlossen waren):
Einspielen der Log-Daten (Archivprotokolldatei) in Archivkopie
zur Wiederherstellung (→ Dauerhaftigkeit!)
Fehlertoleranz
25.04.2007
27
Außerhalb des o.g. Fehlermodells
R5-Recovery: für den Fall vorgesehen, daß eine Datenbank aus
irgendeinem Grund nicht mehr automatisch (d.h. mit R1- bis R4Recovery) von einem logisch und physisch inkonsistenten Zustand in
einen konsistenten Zustand überführt werden kann:
• Datenbank und Log-Daten defekt/verloren
• Unbemerkt entstandene Inkonsistenzen in der Datenbank
(Verletzungen der physischen Integrität)
• ... entsprechendes in den Log-Daten
Was wir im folgenden ausführlich diskutieren:
• Wie geht man heute üblicherweise mit solchen Fehlern (Inkonsistenzen) um?
• Welche Vorschläge findet man in der Literatur / in heute existierenden
Systemen (nicht nur Datenbanksystemen)?
• Was kann man mehr tun / wie / neue Vorschläge?
Fehlertoleranz
25.04.2007
28
Fehlererkennung für Inkonsistenzen in Datenbanken
Klassifikation
Fehlererkennung
"online"
"offline"
durch das
DBVS
durch eine
separate Instanz
unter Verwendung
der externen
DBVS-Schnittstelle
... der blockorientierten
Dateischnittstelle
I
II
III
IV
Die Fälle I-IV im Einzelnen
I. Online durch das DBVS
• Physische Konsistenz der Daten wird durch in das DBVS eingebaute
Abfragen (Prüfungen) im laufenden DBVS-Betrieb überwacht
• Bsp.: Zugriff auf Datenbankseite i → Prüfung, ob es sich bei der
übergebenen Seite wirklich um Seite i handelt
Fehlertoleranz
25.04.2007
29
• (Binäre) Suche in einer sortierten Folge von Schlüsselwerten →
Prüfung, ob Sortierordnung wirklich korrekt vorliegt
Prüfungen werden oftmals als Plausibilitätsprüfungen bezeichnet
1 in vielen Datenbanksystem-Implementierungen – meist aber nur
rudimentär und z.T. unsystematisch – vorhanden
II. Online durch eine separate Instanz (separater Prüfprozess)
Idee à la "begleitende DB-Reorganisation": "Reorganisation Maintenance Process" reorganisiert parallel zur normalen DB-Verarbeitung
Entsprechend vorstellbar für Fehlererkennung:
- globaler Prüfbereich vs. lokaler P.! bei I
- nur Externspeicherzugriff? → reicht nicht! und sieht scheinbare
Inkonsis.
- wann aktiviert/deaktiviert? → DB-Zustand hat sich u.U. deutlich
verändert zwischenzeitlich
etliche Probleme stellen Einsatz in Frage
Fehlertoleranz
25.04.2007
30