Formale Methoden, Heinrich Rust, Lehrstuhl für Software-Systemtechnik, BTU Cottbus, 2004-09-16, p. 1 Formale Methoden: Ein Überblick Heinrich Rust Lehrstuhl für Software-Systemtechnik BTU Cottbus 2004-09-16
Formale Methoden, Heinrich Rust, Lehrstuhl für Software-Systemtechnik, BTU Cottbus, 2004-09-16, p. 2 Szenario: der ideale Compiler Leistung: meldet neben Syntaxfehlern auch semantische Fehler Bedingung: Vorliegen einer präzisen, formalen und korrekten Spezifikation Korrektheitsprüfung für Spezifikation: letztlich nicht automatisierbar
Zwei Ziele formaler Methoden Präziser, vollständiger und verständlicher Ausdruck der Anforderungen Konsistenzrüfungen von Formalisierungen Verständnis der Anforderungen Formalisierungen Formale Methoden, Heinrich Rust, Lehrstuhl für Software-Systemtechnik, BTU Cottbus, 2004-09-16, p. 3
Formale Methoden, Heinrich Rust, Lehrstuhl für Software-Systemtechnik, BTU Cottbus, 2004-09-16, p. 4 Gliederung 1. Formale Methoden: Geisteshaltung oder Werkzeugkasten 2. Ultra-High-Level-Programmiersprachen 3. Abstraktion in Spezifikationsnotationen 4. Anwendungsbereiche: Abstrakte Datentypen und nebenläufige Prozesse 5. Spezifizieren und Beweisen, allgemeiner Fall 6. Zusammenfassung
Formale Methoden, Heinrich Rust, Lehrstuhl für Software-Systemtechnik, BTU Cottbus, 2004-09-16, p. 5 1. FM als Geisteshaltung Harlan Mills, 1975: "Professional programmers today are producing code at the rate of one error per year in their finished work; that performance is not possible by cut-and-try programming. The professional programmer of tomorrow will remember, more or less vividly, every error in his career." völlige Veränderung der Arbeitsweise nötig! Schlüssel: Gedankenprozess und seine Klarheit
Formale Methoden, Heinrich Rust, Lehrstuhl für Software-Systemtechnik, BTU Cottbus, 2004-09-16, p. 6 Zwei Haltungen zu Programmierfehlern (a) Software-Defekte sind uninteressante Nebeneffekte der Arbeit als Softwareentwickler unter Bedingungen unvollständigen Wissens. Eine Analyse der geistigen Ursachen lohnt nicht. (b) Software-Defekte sind wertvolle Hinweise auf falsche Überzeugungen der Entwickler bezüglich des zu entwickelnden Systems. Aus jedem muss man lernen.
1. FM als Werkzeugkasten automatisierte Konsistenzprüfungen vertraute Oberfläche neuartige Algorithmen Ziel: nur oberflächliches Lernen nötig zentral: Notationen (für Vertrautheit), und Unterstützung von Konsistenzbeweisen Formale Methoden, Heinrich Rust, Lehrstuhl für Software-Systemtechnik, BTU Cottbus, 2004-09-16, p. 7
Formale Methoden, Heinrich Rust, Lehrstuhl für Software-Systemtechnik, BTU Cottbus, 2004-09-16, p. 8 2. Beispiele für High-Level-Notationen Ziel: Identität von Spezifikation und Implementierung Vorschläge für funktionale Spezifikationen: ML für Prädikatenlogik: Prolog für Relationenalgebra: SQL für reguläre Sprachen: Reguläre Ausdrücke für kontextfreie Sprachen: Grammatiken in Parsergeneratoren
Formale Methoden, Heinrich Rust, Lehrstuhl für Software-Systemtechnik, BTU Cottbus, 2004-09-16, p. 9 Problem von High-Level-Programmiernotationen zur Spezifikation Zugeständnisse an Ausführbarkeit: von Effektivität und Effizienz wird nicht völlig abstrahiert! (a) Notationen nicht wirklich deklarativ, sondern prozedurale Aspekte wichtig in Semantik. (b) Spezifikations-Lücken nicht erlaubt.
Flexibilität Formale Methoden, Heinrich Rust, Lehrstuhl für Software-Systemtechnik, BTU Cottbus, 2004-09-16, p. 10 3. Abstraktion in Spezifikationsnotationen Spezifikationsnotationen: formaler als natürliche Sprache, und flexibler als Programmiernotationen natürliche Sprache Spezifikationsnotationen Programmiernotationen Formalität
Formale Methoden, Heinrich Rust, Lehrstuhl für Software-Systemtechnik, BTU Cottbus, 2004-09-16, p. 11 3. Abstraktion in Spezifikationsnotationen Beispiel Abstract State Machines (Gurevich) ASM-These: "Jeder Algorithmus ist als ASM formalisierbar, die jeden intuitiven Schritt durch genau einen ASM- Schritt ausführt." intuitiver Algorithmus ASM- Formalisierung...
Formale Methoden, Heinrich Rust, Lehrstuhl für Software-Systemtechnik, BTU Cottbus, 2004-09-16, p. 12 3. Abstraktion in Spezifikationsnotationen: ASMs Schritt-treue Formalisierbarkeit intuitiver Algorithmen beruht wesentlich auf Flexibilität der Daten-Modellierung benötigte mathematische Strukturen werden einfach vorausgesetzt: Codierung durch primitivere Mittel unnötig hohe Anforderungen an Benutzer! Leitfunktion eingeschränkterer Formalismen fehlt
Formale Methoden, Heinrich Rust, Lehrstuhl für Software-Systemtechnik, BTU Cottbus, 2004-09-16, p. 13 3. Abstraktion in Spezifikationsnotationen: Zusammenfassung Hauptziele beim Benutzung von Spezifikationsnotationen: (a) abstraktionstreue Modellierung von Problem und Lösung (b) mathematische Präzision
Formale Methoden, Heinrich Rust, Lehrstuhl für Software-Systemtechnik, BTU Cottbus, 2004-09-16, p. 14 4. Wichtigste Anwendungsbereiche formaler Methoden 4.1 Modellierung abstrakter Datentypen (weil Abstraktion das Hauptmittel ist, um mit kognitiver Beschränktheit umzugehen) 4.2 Modellierung nebenläufiger Prozesse, inklusive Modellprüfung (weil Nebenläufigkeit besonders schwierig zu verstehen, aber praktisch sehr relevant ist)
4.1 Modellierung abstrakter Datentypen Formale Methoden, Heinrich Rust, Lehrstuhl für Software-Systemtechnik, BTU Cottbus, 2004-09-16, p. 15 algebraisch oder modellbasiert modellbasiert: Zustand und Übergang explizit (als Beispiel, Programmierung im Abstrakten), gewöhnlich verständlicher (Beispiele: Z, VDM, B, ASMs) algebraisch: Zustand implizit, als Äquivalenzklasse von Ereignisfolgen; schwerer verständlich; in Forschung verbreitet
Formale Methoden, Heinrich Rust, Lehrstuhl für Software-Systemtechnik, BTU Cottbus, 2004-09-16, p. 16 4.1 Modellierung abstrakter Datentypen: Konsistenzprüfungen Konsistenzprüfungen meist als Prüfung von Invarianten, Vor- und Nachbedingungen von Operationen auf Exemplaren der Datentypen Prüfungen in Entwurfs- und Entwicklungswerkzeuge integrierbar: Eiffel: "design by contract" Java: "extended static checking": ESCJava/2 (autom. Beweise, Beschränkung auf Spezialfälle)
Formale Methoden, Heinrich Rust, Lehrstuhl für Software-Systemtechnik, BTU Cottbus, 2004-09-16, p. 17 4.2 Nebenläufige Prozesse Prozessalgebren (CCS, CSP) Petrinetze hierarchische endliche Automaten (StateCharts) zeitbehaftete Automaten ("Timed Automata"; Kronos, UppAal, Rabbit) synchrone Programmiersprachen (VHDL, ESTEREL, LUSTRE)
4.2 Modellprüfung Überprüfung, ob ein Modell eine Formel erfüllt Modell: Programmlauf, oder Menge davon Formel: temporallogische Spezifikation, die eine Menge von Läufen beschreibt (temporale Operatoren: "nie", "irgendwann", "bis") in endlichen Systemen entscheidbar, ob Formel im Modell erfüllt dramatische Aufwandsprobleme ("Zustandsexplosion"): nur "kleine" Systeme analysierbar Formale Methoden, Heinrich Rust, Lehrstuhl für Software-Systemtechnik, BTU Cottbus, 2004-09-16, p. 18
Formale Methoden, Heinrich Rust, Lehrstuhl für Software-Systemtechnik, BTU Cottbus, 2004-09-16, p. 19 4.2 Modellprüfung: Beispiel Rabbit (BTU Cottbus): Erreichbarkeitsanalyse in Timed Automata, zur Verifikation von zeitbehafteten Algorithmen Zustandsexplosionsproblem: durch sehr erfolgreiche Heuristiken verkleinert
5. Theorembeweiser Formale Methoden, Heinrich Rust, Lehrstuhl für Software-Systemtechnik, BTU Cottbus, 2004-09-16, p. 20 Mathematik: per Varianten der Prädikatenlogik Beispiel: PVS ("Prototype Verification System", SRI) mächtiger Formalismus: sehr flexibel und entsprechend unentscheidbar verblüffend vieles ist automatisch deduzierbar! menschliche Intervention unverzichtbar, wenn letztlich Mathematik als Ganze im Werkzeugkasten liegt
6. Zusammenfassung FM: Mathematik in der Softwareentwicklung, für verständliche Spezifikationen und Konsistenzbeweise FM: Geisteshaltung oder Werkzeugkasten Korrektheitsgarantie uneinlösbar! Notationen: High-level-Programmierung, Spezifikation Wichtigste Anwendungsgebiete: abstrakte Datentypen und nebenläufige Prozesse Konsistenzbeweise: vollautomatisch für Spezialfälle durch Modellprüfung, nicht- oder halb-automatisch durch Theorembeweiser Formale Methoden, Heinrich Rust, Lehrstuhl für Software-Systemtechnik, BTU Cottbus, 2004-09-16, p. 21