Universität Paderborn Die Universität der Informationsgesellschaft. Validierung und Verifikation (inkl. Testen, Model-Checking, Theorem Proving)

Transkript

1 Universität Paderborn Die Universität der Informationsgesellschaft Analyse, Entwurf und Implementierung zuverlässiger Software und (inkl., Model-Checking, Theorem Proving) Torsten Bresser

2 Motivation Zunehmend mehr Software in sicherheitskritischen Bereichen Straßenverkehr Luftfahrt Gesundheitswesen Atomkraftwerke Fehlerhafte Software in diesen Bereichen kann zu schlimmen (katastrophalen) Folgen führen Fragen: Wie können Fehler bei der Entwicklung von Software vermieden werden? Kann die Fehlerfreiheit einer Software nachgewiesen werden? Folie 2

3 Agenda Grundbegriffe und nicht-formale formale (Theorem Proving, Model-Checking) Formen Statisches Dynamisches Folie 3

4 Grundbegriffe und Spezifikation Text, der die Syntax und Semantik eines bestimmten Bestandteiles beschreibt. Modell Bewusst konstruiertes Abbild der Wirklichkeit, das auf der Grundlage einer Struktur-, Funktions- oder Verhaltensanalogie zu einem entsprechenden Original von einem Subjekt eingesetzt bzw. genutzt wird, um eine bestimmte Aufgabe lösen zu können, deren Durchführung mittels direkter Operation am Original zunächst oder überhaupt nicht möglich bzw. unter gegebenen Bedingungen zu aufwendig oder nicht zweckmäßig ist. Folie 4

5 Grundbegriffe und System Eine Menge von Elementen, zwischen denen Beziehungen existieren und die dazu dient, eine bestimmte Aufgabe zu erfüllen und durch eine Menge von Modellen aus verschiedenen Blickwinkeln beschrieben wird. Ein System ist möglicherweise in weitere Teilsysteme zerlegt. Prozess des Überprüfens, ob die Ausgabe einer Lebenszyklusphase die durch die vorhergehende Phase spezifizierten Anforderungen erfüllt. Folie 5

6 Grundbegriffe und Prozess des Bestätigens, dass die Spezifikation einer Phase oder des Gesamtsystems passend zu und konsistent mit den Anforderungen des Kunden ist. Prozess des Verifizierens und Validierens eines Systems oder seiner Komponenten. Theorem Proving Automatische oder teil-automatische Technik zum Beweisen von Aussagen auf Basis geeigneter Logiken (z. B. Prädikatenlogik erster Ordnung, Aussagenlogik) Folie 6

7 Grundbegriffe und Model-Checking Technik zur vollautomatischen reaktiver Systeme mit endlichem Zustandsbaum. Fehler Eine Fehlerursache (Fault) ist ein Defekt in einem System. Ein Fehlzustand (Error) ist eine Abweichung vom geforderten Verhalten des Systems oder Subsystems. Ein Ausfall des Systems (System Failure) tritt auf, wenn das System bei der Durchführung einer Pflicht-Funktion versagt. Folie 7

8 Prozess zum Aufspüren von Fehlern Überprüfung, ob Output einer Entwicklungsphase funktional äquivalent zur vorherigen Phase ist nur nach Spezifikationserstellung entstandene Fehler können gefunden werden Kein Nachweis der Fehlerfreiheit von Produkten Spezifikation kann schon fehlerhaft sein Kundenanforderungen sind nicht-formal kein geeigneter Input für Ziel: frühes Aufspüren von Fehlern spät entdeckte Fehler nur zeitaufwendig und teuer zu korrigieren Folie 8

9 Einfaches Projekt-Entwicklungsmodell Folie 9

10 nicht-formale Auffinden von Spezifikationsverletzungen durch des Systems oder seiner Komponenten auch als manuelle bezeichnet weniger automatisierbar als formale unterstützende Werkzeuge existieren Vorteile ohne tiefgehendes mathematisches Wissen anwendbar auch für komplexe Systeme geeignet am häufigsten eingesetzte stechnik Nachteile Abwesenheit von Fehlern nicht beweisbar Folie 10

11 formale Auffinden von Spezifikationsverletzungen durch Model- Checking und Theorem Proving auch als automatisierte bezeichnet wünschenswert ist Durchführbarkeit ohne menschliche Hilfe in der Praxis nicht voll-automatisch durchführbar nicht anwendbar bei hochkomplexer Software Theorem Proving Beweisen von Aussagen auf Basis gegebener Logik Beweissystem passend zur Logik notwendig Theorem Prover baut intern Beweisbaum auf, um Aussagen beweisen zu können Folie 11

12 formale Beispiel: zu beweisen ist aussagenlogische Tautologie Beweisbaum: 1 1) 2 2) 3) 4) ) 5.2) 6.1.1) 6.1.2) 6.2.1) 6.2.2) Folie 12

13 formale Theorem Proving Bekannte Theorem Prover HOL (Higher Order Logic): Puristen-Ansatz PVS: Praktischer Ansatz Vorteile steigert Verlässlichkeit sicherheitskritischer Anwendungen Nachteile aufwendig (Kosten-/Nutzen-Verhältnis abwägen) mathematisches Wissen Voraussetzung hohe Komplexität nicht immer durchführbar Folie 13

14 formale Model-Checking nur für Programme mit endlich vielen Zuständen Eingabe System-Modell A und Spezifikation B als endlicher Automat (oder in äquivalenter Form) Ausgabe Ergebnis der Überprüfung, ob L(A) L(B) Ggf. Konstr. von Beispielen, die Bedingung verletzen Vorteile Automatisierungsgrad hoch Idee relativ einfach viele Werkzeuge verfügbar Nachteile hohe Hardwareanforderungen nicht anwendbar bei sehr großen Zustandsräumen (Stichwort State Space Explosion) Folie 14

15 Ziel Überprüfung, ob Spezifikation die Anforderungen richtig formalisiert möglichst frühe Erkennung von Fehlern Probleme Anforderungen meist informell, unpräzise, unvollständig, widersprüchlich nicht-formaler Prozess Automatisierung nicht möglich Techniken zur (System Validation/Accepting Testing) Environment Simulation Folie 15

16 am häufigsten eingesetzte Technik zur Erhöhung von Software-Qualität erschöpfende Tests wegen Zeitbeschränkungen (meist) nicht möglich, deshalb erzielbare Software-Qualität niedriger als bei formalen Techniken Generierung von Testfällen sollte vor den eigentlichen Tests stattfinden (schon ab Anforderungsanalyse) Programmierer sollten nicht eigenen Code testen (tendieren zur Konstruktion ungeeigneter Testfälle) Folie 16

17 V-Modell inkl. Testplanung und -durchführung Folie 17

18 mögliche Testformen Unterscheidungskriterium»Ausführung«Dynamisches Statisches Unterscheidungskriterium»Verfügbare Infos«Black-Box-/Requirements-Based-Testing White-Box-/Transparent-Box-Testing Unterscheidungskriterium»Ebene der Tests«Unit (Module) Testing System Integration Testing System Validation Testing Accepting Testing Regression Testing Stress Testing Folie 18

19 mögliche Testformen Unterscheidungskriterium»Test Coverage«Statement Coverage (x: 2, y: 2, z: 4, w: 3) Edge Coverage ( ; ) Condition Coverage ( ; ) Edge/Condition Coverage ( ; ; ) Multiple Condition Coverage (zus ) Path Coverage Loop Coverage Exhaustive Testing true y := y + 1 y := y + 1 x = y und z > w false Folie 19

20 Formen Techniken für das statische Code Inspection Walkthrough/Design Reviews Checklisten Formale Beweise Kontrollflussanalyse Datenflussanalyse Techniken für das dynamische Funktionales Strukturelles Statistisches, zufallsbasiertes Folie 20

21 Vorteile einfach zu erlernen gutes Kosten-/Nutzen-Verhältnis auch bei komplexen Datenstrukturen/Programmen anwendbar Nachteile kein Nachweis der Fehlerfreiheit eines Programms möglich kann sehr aufwendig sein (wegen eventuell notwendiger Simulation der Umwelt oder noch nicht implementierter Komponenten) gewährt insgesamt weniger Zuverlässigkeit als formale Methoden Folie 21

22 vorgestellte Techniken erhöhen allesamt Qualität der entwickelten Software Kombination von Techniken einsetzbar (und bei sicherheitskritischer Anwendung wünschenswert) Model-Checking und Theorem Proving sind für nicht-sicherheitskritische Anwendungen meist zu aufwendig (Kosten-/Nutzen-Analyse notwendig) keine Methode garantiert absolute Sicherheit kann Fehlerfreiheit generell nicht garantieren Model-Checking und Theorem Proving meist nur anwendbar auf Teile eines Systems oder abgespeckte Systeme Folie 22