Präsentation herunterladen
1
N-Version Programmierung
von Rafael Bielen
2
Inhalt Einleitung Motivation Funktionsprinzip Herausforderungen
Abwandlungen wichtige historische Ansätze Probleme Fazit
3
Einleitung 1/2 weiterer Ansatz um Software fehlertoleranter und robuster zu entwickeln Programmierfehler mildern Kernidee: mehrfach dasselbe Programm implementieren Hoffnung: Auftreten gleicher Fehler senken
4
Einleitung 2/2 alle Implementierungen nach gleichen Spezifikationen
Implementierungen unabhängig voneinander alle Implementierungen nach gleichen Spezifikationen ein Algorithmus wählt das vermutlich richtige Ergebnis
5
Motivation Wieso Programmierfehlern vorbeugen? Programmierfehler:
Sichere Software spart Kosten! Ariane 5 Satelliten, 1,7 Milliarden DM Schaden Programmierfehler: 64Bit – 16Bit Umwandlung Studie aus dem Jahr 1986: pro 1 Million Zeilen Code Bugs
6
Funktionsprinzip Software ist kein „ganzes Stück“ mehr
besteht aus verschiedenen Softwaremodulen
7
Herausforderungen 1/4 Spezifikationen:
Eingabespezifikation, ein Fehler N fehlerhafte Softwaremodule Cross-Check Punkte gut definieren Designfehler ausschließen Freiraum für verschiedene Implementierungen lassen
8
Herausforderungen 2/4 unabhängige Entwicklung:
Ziel: Auftreten von gemeinsamen Fehlern in den unterschiedlichen Softwareversionen vermindern. verschiedene Programmiersprachen benutzen Verwendung von unterschiedlichen Instrumenten und Compilern unterschiedliche Teams
9
Herausforderungen 3/4 Entscheidungs-Algorithmus: effizient
selber sicher von Fehlern Wie erkennt man das richtige Ergebnis? oftmals einziger Weg Mehrfachbeschluss
10
Herausforderungen 4/4 Wartung eines laufenden Systems:
Welches Modul verursacht einen Fehler? Wartung aufwendiger als bei „normaler“ Software höhere Wartungskosten
11
N-Version Programmierung Abwandlungen
verschiedene Abwandlungen Darstellung von verschiedenen Konfigurationen der Abwandlungen als 3er Tupel möglich. Zeit | Plattformen | Software
12
Single-Channel 1/2 Rollback-Methode Beispiel:
Nutzung einer einzigen Plattform zur Ausführung N x Zeit | 1 x Plattform | N x Software Rollback-Methode Beispiel: 2 x Zeit | 1 x Plattform | 1 x Software Rollback zum letzten fehlerfreien Zustand mehrfacher Rollback bei einem Fehler auch möglich nicht geeignet für permanente Fehler (zerstörte Hardware) Reparatur von außen nötig
13
Single-Channel 2/2 neue Softwareinstanz-Methode Beispiel:
Starten einer neuen Softwareinstanz 2 x Zeit | 1 x Plattform| 2 x Software Daten auf denen gearbeitet wird stabile und fehlerfreie gespeicherte Kopie
14
Multi-Channel 1/3 alles nur einmal berechnen
mehrere Softwareversionen, jede auf einer eigenen Plattform 1 x Zeit | N x Plattformen | N x Software NASA's Space Shuttle mit N = 4 2. Punkt wichtig für Realisierung
15
Multi-Channel 2/3 1. Konsistenz:
Plattformen müssen alle die gleiche Eingabe bekommen sowie im gleichen Startzustand sein. 2. Zuverlässiger Entscheidungs- Algorithmus: Kontrolle aller Ergebnisse der Berechnungen unnötig Akzeptanzbereich
16
Multi-Channel 3/3 Entscheidungs-Algorithmus wird oft für jeden Bereich neu geschrieben. hilft nicht gegen Designfehler Lösung: Erstelle von Software und Hardware individuelle Versionen.
17
Welche Fehler können behoben werden?
Fehlerbehebung möglich bei: Programmierfehlern Programmfehlern Hardwarefehlern Kein Erfolg bei: mangelhafter Spezifikation fehlerbehaftetem Input Fehler in der Bedienung
18
Wichtige historische Ansätze
Dr. Dionysius Lardner (1834): Fehler vorbeugen durch gleiche Berechnungen auf unterschiedlichen Plattformen N-Version Programmierung: auch genannt Multi-Version Programmierung, Beginn 1970 zwei wichtige Ansätze von: Brian Randell UCLA (Universität von Kalifornia, Los Angels)
19
„Recovery Block“ von Brian Randell 1/2
Ziel: Softwarefehler, auch welche die durch Hardwarefehler verursacht werden, im laufenden Betrieb zu erkennen. Ursprungsversion der Software erstellen Berechnungen der Version im laufenden Zustand mit der Berechnung der Ursprungsversion verglichen Akzeptanztest
20
„Recovery Block“ von Brian Randell 2/2
Nichtbestehen des Akzeptanztests ältere Version der Software einspielen, die den Test bestanden hat N x Zeit | 1 x Hardware | N x Software Variierung der „Recovery Block“ Methode möglich: unterschiedliche Plattformen um Design- und Hardwarefehler auszuschließen
21
NVP von UCLA Erstellung von individuell gestalteten Softwaremodulen
Softwaremodule erfüllen alle die gleichen Spezifikationen vermutlich richtiges Ergebnis mit Hilfe eines Algorithmus auswählen 1 x Zeit | N x Hardware | N x Software
22
Experimentale Resultate der UCLA 1/4
UCLA negativ aufgefallen „Klassische“ Computersysteme sind nicht gut dafür geeignet, N-Version Software auszuführen und zu überwachen. Eigener Computer Prototyp designt und implementiert (DEDIX = Design Diversity Experiment).
23
Experimentale Resultate der UCLA 2/4
Betriebssystem, Unix Abwandlung, genannt LOCUS DEDIX nutzt eine verteilte Rechenarchitektur, die auf 20 VAX 11/750 Computern basiert (3.125 MHz pro Maschine)
24
Experimentale Resultate der UCLA 3/4
Studie: Spezifikation in je 3 Sprachen für das gleiche Problem/Aufgabe OBJ (Declarative "ultra high-level" Sprache) PDL (Seitenbeschreibungssprache) Englisch als 3te Kontrollsprache
25
Experimentale Resultate der UCLA 4/4
30 Programmierer beschäftigt, die 19 Programme erstellten 8 Programme aus der OBJ Spezifikation 5 aus der PDL Spezifikation 6 aus der Kontrollsprache Eng. Spezifikation = 10 Seiten OBJ Spezifikation = 7 Seiten PDL Spezifikation = 74 Seiten
26
Probleme 1/5 Tests: 6 unterschiedliche Versionen, alle untereinander testen, 21 Tests nötig Aufwand fast um N-Mal höher als bei „normaler“ Software Tests werden komplexer Wechselwirkung Entscheidungs-Algorithmus muss getestet werden Kosten steigen damit
27
Probleme 2/5 Unterschiedliche Plattformen und Betriebssysteme:
Für jedes Betriebssystem meistens eigene Testkonfigurationen und unterschiedliche Hilfsprogramme notwendig Probleme Ergebnisse untereinander vergleichen unterschiedliche Zeichensätze oder komplett andere Byte-Reihenfolge
28
Probleme 3/5
29
Probleme 4/5 Kosten: Es gibt keine konkreten Statistiken, die besagen wie viel teurer die Entwicklung von N-Software Versionen ist. Zahlen schwanken von 25%-134% Die Idee, N-Versionen einer Software lassen die Kosten um N-Mal multiplizieren, ist falsch! viele Gemeinsamkeiten in der Entwicklung
30
Probleme 5/5 Unabhängige Versionen:
Problemlösung lässt oft wenig Spielraum Implementierungen oft ähnlich Keine Studien die Beweisen, dass gleiche Fehler gemindert werden.
31
Fazit 1/2 Positiv: interessanter Ansatz
praktisch Einsetzung z.B. NASA Space Shuttle intuitiv verschiedene Softwareversionen müssen nicht die gleichen Fehler enthalten
32
Fazit 2/2 Negativ: nicht gut entwickelt/erforscht Kosten/Aufwand?
Werden gleiche Fehler wirklich minimiert?! Entscheidungs-Algorithmus nicht trivial
33
Fragen? Fragen?
34
Literaturverzeichnis
Algirdas Avizienis.The N-Version Approach to Fault-Tolerant Software. Software Engineering, IEEE Transactions on , vol.SE-11, no.12, pp , Dec. 1985 Israel Koren and C. Mani Krishna. Fault-Tolerant Systems. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 2007 Proseminar Software Desaster ARIANE 5 Absturz des Flugs 501 Mathias Riedl , Vorlesung Universtität Zürich, Martin Glinz Software Engineering I The Evolution of the Recovery Block ConceptBRIAN RANDELL and JIE XU University of Newcastle upon Tyne
Ähnliche Präsentationen
© 2024 SlidePlayer.org Inc.
All rights reserved.