Fehlervermeidung und Fehlertoleranz im Software-Bereich

Transkript

1 Fehlervermeidung und 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* 1. Projektmodelle Formalisierung, Vereinheitlichung des SW-Entwicklungsprozesses (Einteilung in Phasen) Dient u.a. besserer Projektüberwachung * aktuelle Themen in Praxis heute

2 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)

3 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

4 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: zunehmender Nutzen Inspektion Walk Through Code Reading 5. Tests 4 Stufen der Testdurchführung: - Modultest - Komponententest - Systemtest zunehmende Integration - 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. zunehmender Aufwand

5 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

6 Software- 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

7 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... Vn Versionen n 2 Abnahmetest i<n Mißerfolg Erfolg Fehlernachricht BEGIN System S Systemumgebung Problem: Abnahmetest Bietet sich nicht bei allen Aufgabenstellungen an U.U. komplex, zeitaufwändig, fehlerträchtig, keine 100% Sicherheit

8 BEGIN N-Version Programming V1 V2... Vn Versionen n 3 Voter V Voting erfolgreich NEIN JA 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

9 Fehlererkennung und Fehlerbehandlung in Datenbanksystemen und Umfeld Vorgenannte Techniken zur Fehlervermeidung bei der SW-Entwicklung natürlich auch hier weit verbreitet Techniken der Software- (Divers.) werden dagegen aus Aufwandsgründen nie eingesetzt (also Recovery Blocks, N-Version P.) Software 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

10 Abriss zur traditionellen Fehlerbehandlung in Datenbanksystemen (Mehr Details in Vorlesung DBS2 ) Transaktion: Sequenz zusammengehöriger Operationen auf einer Datenbank 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 [ ] BOT EOT O i t

11 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

12 Fehlerbehandlungsmaßnahmen: DB auf Platte bleibt erhalten ist teuer - 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 Log- Daten ( 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!)

13 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 R4- Recovery) 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?

14 Fehlererkennung für Inkonsistenzen in Datenbanken Klassifikation Fehlererkennung "online" "offline" durch das DBVS I durch eine separate Instanz II unter Verwendung der externen DBVS-Schnittstelle III... der blockorientierten Dateischnittstelle IV I. Online durch das DBVS Die Fälle I-IV im Einzelnen 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

15 (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 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