Wie können wir wissen, dass formale Methoden funktionieren?

20

Ein wichtiges Ziel formaler Methoden ist es, die Korrektheit von Systemen entweder automatisiert oder durch den Menschen zu beweisen. Es scheint jedoch, dass Sie möglicherweise NICHT garantieren können, dass das System nicht ausfällt, auch wenn Sie einen Korrektheitsnachweis erbringen können. Beispielsweise:

  • Die Spezifikation modelliert das System möglicherweise nicht richtig, oder das Modell eines Produktionssystems ist möglicherweise zu kompliziert, oder das System weist aufgrund widersprüchlicher Anforderungen von Natur aus Fehler auf. Welche Techniken sind bekannt, um zu testen, ob eine Spezifikation überhaupt Sinn macht?
  • Der Proofprozess kann auch fehlerhaft sein! Wer weiß, dass diese Inferenzregeln korrekt und legitim sind? Außerdem können Beweise sehr umfangreich sein, und woher wissen wir, dass sie keine Fehler enthalten? Dies ist das Herzstück der Kritik in de Millo, Lipton und Perlis '"Sozialen Prozessen und Beweisen von Theoremen und Programmen". Wie reagieren moderne formale Methodenforscher auf diese Kritik?
  • Zur Laufzeit gibt es viele nicht deterministische Ereignisse und Faktoren, die das System ernsthaft beeinflussen können. Kosmische Strahlung kann beispielsweise den Arbeitsspeicher auf unvorhersehbare Weise verändern, und wir können im Allgemeinen nicht garantieren, dass die Hardware keine byzantinischen Fehler aufweist, gegen die Lamport nachweislich nur sehr schwer robust ist. Die Korrektheit des statischen Systems garantiert also nicht, dass das System nicht ausfällt! Gibt es Techniken, die dafür verantwortlich sind, dass echte Hardware nicht funktioniert?
  • Derzeit ist das Testen das wichtigste Werkzeug, um sicherzustellen, dass die Software funktioniert. Es scheint, als sollte es ein komplementäres Instrument mit formalen Methoden sein. Ich sehe jedoch hauptsächlich Forschung, die sich entweder auf formale Methoden oder auf das Testen konzentriert. Was ist über die Kombination der beiden bekannt?
Jenny
quelle
4
Die Punkte 1 und 3 scheinen der Systemanalyse unabhängig von der Methode inhärent zu sein. Formale Methoden machen sie zumindest im Gegensatz zu anderen Methoden deutlich. Problem 2 ist meines Wissens nicht vorhanden; Die von mir verwendeten formalen Systeme haben sich als richtig erwiesen. Sie können jedes Abzugssystem durcheinander bringen, indem Sie es selbst modifizieren und natürlich Fehler machen.
Raphael
8
Diese Frage ist eher subjektiv und provozierend formuliert. Ich würde empfehlen, neu zu formulieren oder zu schließen.
Suresh Venkat
4
Ich habe einige wichtige Änderungen vorgenommen, um die Frage für mein Urteilsvermögen nützlicher zu machen. Wenn Sie der Meinung sind, dass dies eine zu aggressive Änderung war, posten Sie dies bitte in Meta.
Neel Krishnaswami
1
@Neel: Nice edit. Eine Sache, die Ihre Änderung auslässt, ist ein Hinweis auf die Systemsicherheit, die Teil des Wesens der ursprünglichen Frage war. Vielleicht kann Jenny das wieder einbauen, um es wieder zu ihrer Frage zu machen.
Dave Clarke
1
Wie bei Punkt 4: Großes Missverständnis: (realistische) Tests können niemals die Abwesenheit von Fehlern zeigen.
Raphael

Antworten:

11

Zu 4: Es gibt viel zu tun, um formale Methoden und Tests zu kombinieren. Das googeln von "formalen Methodentests" bringt einen ziemlichen Arbeitsaufwand mit sich. Obwohl es viele verschiedene Ziele dieser Arbeit gibt, besteht eines der Hauptziele darin, effektivere Testsuiten zu generieren. Dieser Vortrag gibt eine nette Einführung, basierend auf der Modellprüfung.

Auch in Bezug auf das Thema Softwaresicherheit , das außer Frage gestellt wurde: Formale Methoden müssen härter arbeiten, um in diesem Bereich erfolgreich zu sein. In der Regel schreibt man eine Spezifikation für eine Software und überprüft, ob die Spezifikation erfüllt ist, dh ob die Ausgabe die Nachbedingung erfüllt, wenn die Eingabe die Vorbedingung erfüllt. Um eine sichere Software zu gewährleisten, muss auch überprüft werden, ob sich die Software bei Eingaben, die die Voraussetzung nicht erfüllen, vernünftig verhält. (Dies ist natürlich gleichbedeutend damit, die Vorbedingung für alle Eingaben auf "wahr" zu setzen.) Der Platz aller Eingaben ist in der Regel viel größer als nur eine wohlgeformte Eingabe. In der Regel ist dies jedoch eine Stelle, an der selbst funktionell korrekte Software verletzt werden kann Verletzung seiner Annahmen.

Zu Punkt 3: Es wurden einige Arbeiten durchgeführt, um Systeme in Einstellungen zu überprüfen, in denen Fehler explizit modelliert werden, einschließlich Fehlerlogik: Begründen fehlertoleranter Programme. Matthew Meola und David Walker. Europäisches Symposium für Programmierung, 2010. Die Arbeiten zur probabilistischen Modellprüfung und zur probabilistischen Verifizierung befassen sich mit dem Problem der Fehler in gewissem Maße.

Dave Clarke
quelle
9

Ihre Punkte in der Reihenfolge:

  • Die Richtigkeit aller Angaben ist letztendlich subjektiv: Sie werden wahrgenommen, um ein Problem nach Ansicht ihrer Benutzer richtig zu lösen, oder sie tun es nicht. Es gibt kein Entrinnen von Software-Entwicklung, und keine Methode hat die Silberkugel für diese.
  • Es wird viel Arbeit investiert, um zu beweisen, dass der Prozess in Bezug auf seine Annahmen korrekt ist. Normalerweise stehen Experten Informationen zur Verfügung, um diese Regeln zu validieren. Jede menschliche Aktivität ist fehleranfällig, aber sehr formalisierte Systeme, die gut untersuchte Ansätze verwenden, sind wesentlich weniger fehleranfällig als fast alle anderen menschlichen Prozesse.
  • Irgendwann weist jedes System einen Fehlermodus auf, der außerhalb des Bereichs dieses Systems liegt. Sie sind immer noch besser dran, alle vorhersehbaren Fehlerquellen zu beseitigen , selbst wenn Sie einige unvorhersehbare Fehlerquellen unberücksichtigt lassen.
  • Testen und beweisen kann leicht koexistieren. Testen ist ein weniger spezifischer, mehr Ad-hoc- Prozess, sodass Sie möglicherweise weniger formelle Arbeit daran finden. Möglicherweise interessieren Sie sich jedoch für ein Tool wie QuickCheck , das die vom Haskell-Typensystem angebotenen Beweise durch Tests ergänzt.
Marc Hamann
quelle
9

Es wurde bereits gezeigt, dass formale Methoden sehr gut funktionieren. Ohne sie hätten wir die Komplexität des Entwurfs moderner digitaler Systeme (Mikroprozessoren) nicht bewältigen können.

Keine Mikroschiffe, deren Logik keiner Überprüfung der funktionalen Äquivalenz unterliegt; ohne dass die FPU der FV unterlag; ohne dass die Cache-Kohärenz-Protokolle FV unterlagen (dies ist seit 1995 der Fall).

Abgesehen von offensichtlichen Unterschieden zwischen Software und technischen physischen Systemen (z. B. Brücken, bei denen Sicherheitsfaktoren hinzugefügt werden können), spielen sie in CS die Rolle der technischen Mathematik. Die Verwendung von FM hängt jedoch immer vom Nutzen / Kosten ab. Fuzz-Tests zahlen sich bei Unternehmen wie Microsoft aus (Google SAGE auf einer Folie).

Sogar innerhalb eines Mikros gibt es Subsysteme (z. B. Mikroprozessor-Pipelines), in denen FV nicht die gleichen Auswirkungen hatte wie anderswo (z. B. FPU). In vielen Fällen wurden konventionelle Tests überhaupt nicht durchgeführt, als die formale Bewertung der symbolischen Flugbahn das Fehlen von Fehlern bewies : Kaivola et al., CAV'09).

Formale Methoden werden auch bei der Synthese von Artefakten verwendet (Code, hochwertige Tests, Zeitpläne für die optimale Entleerung von Batteriebänken, ...). Natürlich sind alle in der Frage aufgeworfenen Fragen zutreffend, und wie bei jedem anderen Einsatz von Technologie müssen falsche Anzeigen erkannt und vermieden werden.

Ganesh
quelle
8

Zu 2: Wenn das System in einem Proof-Assistenten (z. B. Twelf oder Agda oder Coq) formalisiert ist und die Eigenschaften von Solidität und Vollständigkeit überprüft werden und die Proofs in dieser Codierung erstellt werden, ist dies kein Problem. Möglicherweise haben Sie ein System formalisiert, das nicht das beschreibt, was Sie beabsichtigt haben, aber Sie haben zumindest keine falschen Beweise oder ein kaputtes System, in dem Sie argumentieren.

Jamie Morgenstern
quelle
1
Es gibt auch etwas, das als "Angemessenheit" Ihrer Kodierung bekannt ist: Was Sie in einem Proof-Assistenten formalisiert haben, ist tatsächlich das System, das Sie auf Papier geschrieben haben (siehe twelf.plparty.org/wiki/Adequacy ). Dies spricht jedoch nicht Ihren ersten Punkt an, sondern konstruiert eine Bijektion.
Jamie Morgenstern
6

Es scheint jedoch, dass Sie möglicherweise NICHT garantieren können, dass das System nicht ausfällt, auch wenn Sie einen Korrektheitsnachweis erbringen können.

Ja, vielleicht gibt es keine Garantien . Formale Methoden sollen Fehler finden, beseitigen und Menschen überzeugen.

Welche Techniken sind bekannt, um zu testen, ob eine Spezifikation überhaupt Sinn macht?

Möglicherweise interessieren Sie sich für Tools zur Modellprüfung für Spezifikationen formaler Systeme .

Der Proofprozess kann auch fehlerhaft sein! Wer weiß, dass diese Inferenzregeln korrekt und legitim sind?

Ich denke (aufgrund von Goedels Unvollständigkeitssatz), dass das Zeigen eines Systems von Inferenzregeln konsistent ist, appelliert notwendigerweise an einen noch mächtigeren Satz von Inferenzregeln.

Außerdem können Beweise sehr umfangreich sein, und woher wissen wir, dass sie keine Fehler enthalten?

Hoffentlich werden große Beweise von einem kleinen Proof-Checker geprüft, der von Menschen in angemessener Zeit gelesen und verstanden werden kann. Dies wird manchmal als "de Bruijn-Kriterium" bezeichnet. Wenn Sie der Meinung sind, dass der Proof Checker keinen falschen Proof zertifiziert, müssen Sie nur den Checker überprüfen.

Gibt es Techniken, die dafür verantwortlich sind, dass echte Hardware nicht funktioniert?

Wie wäre es mit fehlertoleranter typisierter Assemblersprache ?

Ich sehe jedoch hauptsächlich Forschung, die sich entweder auf formale Methoden oder auf das Testen konzentriert. Was ist über die Kombination der beiden bekannt?

"Die TAP-Konferenz widmet sich der Konvergenz von Beweisen und Tests" .

Nur für "Beweise und Tests" googeln hat mehrere gute Treffer über der Falte.

Apfel
quelle
5

Welche Techniken sind bekannt, um zu testen, ob eine Spezifikation überhaupt Sinn macht?

Es ist definitiv ein Urteilsspruch. In der Softwareentwicklung wurde eine sehr strenge Methodik entwickelt, um die Spezifikationen zu finden, zu schreiben und zu bestätigen. Dies geschieht durch echte Menschen und unter Verwendung eines nicht-formalen (im Sinne eines nicht-mathematischen) Prozesses, so dass es immer noch Inkonsistenzen unterliegt, aber am Ende des Tages entspricht es dem, was die Menschen überprüfen möchten, nicht mehr und nicht weniger.

Gibt es Techniken, die dafür verantwortlich sind, dass echte Hardware nicht funktioniert?

Sicher, es gibt ein Feld der Überprüfung, das als Laufzeitüberprüfung bezeichnet wird. Sie können auch die ausführungsbasierte Modellüberprüfung auf dem realen System verwenden, das in einer vollständig virtuellen Umgebung ausgeführt wird, die einem bestimmten Szenario unterliegt (dazu habe ich mich mit V-DS + APMC selbst beigetragen ). Dies ist jedoch eindeutig ein Hauptproblem, um die Interaktion zwischen dem System und der Umgebung in den Verifizierungsprozess einzubeziehen.

Ich sehe jedoch hauptsächlich Forschung, die sich entweder auf formale Methoden oder auf das Testen konzentriert. Was ist über die Kombination der beiden bekannt?

Wow, heute werde ich total schamlos sein und mich wieder zitieren. Mit den Autoren, die an der Kombination von Modellprüfung und - prüfung arbeiten, können Sie in der Publikationsliste eines ehemaligen Doktoranden unserer Gruppe nachsehen oder in einer guten Suchmaschine nach "Näherungsprüfung des probabilistischen Modells" oder "Überprüfung des statistischen Modells" suchen (Aufgabe von Younes et al., Sen et al. Oder ich et al. Und viele andere).

Sylvain Peyronnet
quelle
Zu 1: Es ist zu beachten, dass die Notwendigkeit einer formalen Formulierung von Spezifikationen den subjektiven Teil im Gegensatz zu Formulierungen in natürlicher Sprache unterstützen soll. Unstimmigkeiten und Unsicherheiten werden sichtbar und müssen behoben werden, indem sie sehr genau sein müssen.
Raphael
Der Prozess ist nicht formal, aber das Ergebnis für die Modellprüfung ist typischerweise eine zeitliche Formel (z. B. LTL oder CTL). Nach meiner Erfahrung (mit Leuten aus der Industrie) verbessert die Verwendung einer formalen Sprache nicht unbedingt die Konsistenz des Ergebnisses :(
Sylvain Peyronnet
Aber Sie können zumindest auf Inkonsistenzen prüfen, oder? Welche Erfahrungen haben Sie mit dem Thema "Bekommen, was Sie wollen" gemacht?
Raphael
2
Ja, ich kann die Inkonsistenzen überprüfen, aber das hilft leider nicht immer, sie zu beheben. Das Problem ist, dass es für die meisten Ingenieure / Industriedesigner sehr schwierig ist, Spezifikationen in klassischen Verifizierungssprachen zu schreiben. Meiner Meinung nach führt Sie die Verwendung einer Spezifikationssprache zu viel, wenn Sie keine umfassenden Kenntnisse in dieser Sprache haben: Sie schreiben nur das, was Sie mit ein wenig Vertrautheit in der Sprache schreiben können. Zusammenfassend gesagt, tötet es Ihre Kreativität.
Sylvain Peyronnet
5

Vielleicht interessieren Sie sich sehr für die Arbeiten von John Rushby , einem der Designer des PVS-Theorembeweisers, der generell an genau den Punkten interessiert ist, die Sie erwähnen. Lesen Sie diesen klassischen Bericht an die FAA über die Verwendung formaler Methoden und die Zertifizierung kritischer Systeme (1993) und seine neueren Schriften über die Zusammenstellung eines probabilistischen formalen Sicherheitsnachweises aus verschiedenen Beweismitteln (Tests, Nachweise, Analysen usw.).

Martin Schwarz
quelle