it-swarm.com.de

Was sind die Hindernisse, die eine breite Akzeptanz formaler Methoden verhindern?

Formale Methoden können verwendet werden, um Code für eine Anwendung anzugeben, zu beweisen und zu generieren. Dies ist weniger fehleranfällig - wird daher hauptsächlich in sicherheitsrelevanten/kritischen Programmen verwendet.

Warum verwenden wir es nicht häufiger für die tägliche Programmierung oder in Webanwendungen usw.?

Verweise :

14
toto

Ein Ingenieur ist eine Person, die mit einem Dollar machen kann, was jeder Idiot mit 10 machen kann.

Ressourcenbeschränkungen, Budgetbeschränkungen, Zeitbeschränkungen sind alle wichtig.

Die Entwicklung von Software mit formalen Methoden ist in der Regel erheblich teurer und dauert viel länger als ohne. Bei vielen Projekten ist es außerdem am schwierigsten, die Geschäftsanforderungen zu verstehen. Alles, was Sie in diesem Fall mit formalen Methoden kaufen, ist der Beweis, dass Ihr Code zu 100% Ihrem unvollständigen und falschen Verständnis der Geschäftsanforderungen entspricht.

Aus diesem Grund ist die Verwendung formaler Methoden, Beweise, Programmüberprüfungen und ähnlicher Techniken typischerweise auf "wichtige Dinge" beschränkt, d. H. Avionik-Software, Steuerungssysteme für medizinische Geräte, Kraftwerke usw.

19
Jörg W Mittag

Programmieren oder nicht programmieren?

Um ein Problem mit einem Softwareprodukt zu lösen, können Sie nach dem Verständnis der Anforderungen [~ # ~] entweder [~ # ~] a schreiben Programm mit Programmiersprachen [~ # ~] oder [~ # ~] spezifizieren das Programm mit einer formalen Sprache und verwenden Tools zur Codegenerierung. Letzteres fügt nur eine Abstraktionsebene hinzu.

Die Dinge richtig machen oder die richtigen Dinge tun?

Der formale Ansatz gibt Ihnen einen Beweis dafür, dass Ihre Software gemäß den Spezifikationen funktioniert. Ihr Produkt macht also die Dinge richtig. Aber macht es die richtigen Dinge?

Die Anforderungen, an denen Sie arbeiten, sind möglicherweise unvollständig oder nicht eindeutig. Sie könnten sogar fehlerhaft sein. Im schlimmsten Fall werden die tatsächlichen Bedürfnisse nicht einmal ausgedrückt. Aber ein Bild sagt mehr als tausend Worte, nur Google-Bilder für "Was der Kunde will", zum Beispiel aus diesem Artikel :

enter image description here

Die Kosten für die Formalität

In einer perfekten Welt hätten Sie von Anfang an detaillierte und perfekte Anforderungen. Sie können dann Ihre Software vollständig spezifizieren. Wenn Sie sich für eine formelle Vorgehensweise entscheiden, wird Ihr Code automatisch generiert, damit Sie produktiver arbeiten können. Produktivitätsgewinne würden die Kosten der formalen Werkzeuge ausgleichen. Und jetzt würde jeder formale Methoden anwenden. Warum ist es nicht so?

In der Praxis ist dies selten die Realität! Dies ist der Grund, warum so viele Wasserfallprojekte fehlgeschlagen sind und warum iterative Entwicklungsmethoden (agil, RAD usw.) die Führung übernommen haben: Sie kann unvollständige und unvollständige Anforderungen, Entwürfe und Implementierungen verarbeiten und verfeinern, bis sie in Ordnung sind.

Und hier kommt der Punkt. Bei formalen Methoden muss für jede Iteration eine vollständig konsistente formale Spezifikation vorliegen. Dies erfordert sorgfältiges Denken und zusätzliche Arbeit, da formale Logik nicht verzeiht und unvollständige Gedanken nicht mag. Einfache Wegwerfexperimente werden unter dieser Bedingung teuer. Dies gilt auch für jede Iteration, die zum Zurückverfolgen führen würde (z. B. eine Idee, die nicht funktioniert hat, oder eine Anforderung, die missverstanden wurde).

In der Praxis

Wenn Sie aus rechtlichen oder vertraglichen Gründen nicht verpflichtet sind, formale Methoden anzuwenden, können Sie auch ohne formale Systeme eine sehr hohe Qualität erzielen, indem Sie beispielsweise vertragsbasierte Programmierung und andere bewährte Verfahren (z. B. Code) verwenden review, [~ # ~] tdd [~ # ~] , etc ...). Sie können nicht beweisen, dass Ihre Software funktioniert, aber Ihre Benutzer werden es genießen, früher mit Software zu arbeiten.

Update: gemessener Aufwand

In der Oktober 2018 Ausgabe von Mitteilungen der ACM gibt es einen interessanten Artikel über Formal verifiziert Software in der realen Welt mit einigen Schätzungen des Aufwands.

Interessanterweise (basierend auf der OS-Entwicklung für militärische Ausrüstung) scheint es, dass die Herstellung formal bewährter Software 3,3-mal mehr Aufwand erfordert als mit herkömmlichen technischen Techniken. Es ist also sehr teuer.

Auf der anderen Seite ist 2,3-mal weniger Aufwand erforderlich, um Hochsicherheitssoftware auf diese Weise zu erhalten, als bei herkömmlich entwickelter Software, wenn Sie den Aufwand für die Erstellung solcher Software erhöhen auf hohem Sicherheitsniveau zertifiziert (EAL 7). Wenn Sie also hohe Zuverlässigkeits- oder Sicherheitsanforderungen haben, gibt es definitiv einen Business Case für die Formalisierung.

das Design und die Codeentwicklung von seL4 dauerten zwei Personenjahre. Die Summe aller serospezifischen Nachweise über die Jahre ergibt insgesamt 18 Personenjahre für 8.700 Zeilen C-Code. Im Vergleich dazu dauerte die Entwicklung von L4Ka :: Pistachio, einem weiteren Mikrokernel der L4-Familie, der in seiner Größe mit seL4 vergleichbar ist, sechs Personenjahre und bietet kein signifikantes Maß an Sicherheit. Dies bedeutet, dass zwischen verifizierter Software und traditionell entwickelter Software nur ein Faktor 3.3 besteht. Nach der Schätzmethode von Colbert und Boehm 8 würde eine traditionelle EAL7-Zertifizierung nach Common Criteria für 8.700 Zeilen C-Code mehr als 45,9 Personenjahre dauern. Dies bedeutet, dass die formale Überprüfung der Implementierung auf Binärebene bereits mehr als einen Faktor von 2,3 weniger kostspielig ist als die höchste Zertifizierungsstufe der Common Criteria, jedoch eine deutlich höhere Sicherheit bietet.

12
Christophe

Jedes Programm in jeder Sprache kann als formale Spezifikation betrachtet werden (entspricht einer Drehmaschine). Jede übergeordnete „formale Spezifikation“, die zum Nachweis der formalen Korrektheit verwendet werden soll, ist ebenfalls - nur ein weiteres Programm. Aber es ist (normalerweise) ein schlechtes, unvollständiges, vages, unzureichend durchdachtes Programm. Und nicht zufällig, normalerweise geschrieben von Leuten, die nicht wissen, wie man programmiert (sie sind normalerweise Domain-Experten).

Wenn Sie also beweisen, dass ein Programm mit seinen formalen Anforderungen auf höherer Ebene kompatibel ist (dieselben Antworten liefert oder wie auch immer Sie es charakterisieren), kommt es immer darauf an, wie Sie die Mehrdeutigkeiten in der formalen Spezifikation auf höherer Ebene lösen. Es gibt keinen guten allgemeinen Weg, dies zu tun.

Diese Zuordnung von Anforderungen auf hoher Ebene zu Details auf niedrigerer Ebene ist der Kern dessen, worum es bei der realen Programmierung geht. Es sollte nicht überraschen, dass die Kernarbeit, die ein Programmierer beim Lesen und Interpretieren von Spezifikationen leistet, nicht durch Handwinken und die Aussage ersetzt werden kann: "Jetzt sehen Sie nur, ob diese hochrangige formale Spezifikation von diesem Beispielprogramm eingehalten wird.".

Selbst in den frühen Tagen der Logikprogrammierung, als dieses Konzept zunächst so vielversprechend schien (weil sowohl die Spezifikation auf hoher Ebene als auch die tatsächlich zugrunde liegenden Programme in derselben Sprache geschrieben werden konnten), erwies sich dieses Kernproblem als unlösbar.

0
Lewis Pringle