正式な方法が機能することをどのように知ることができますか？

正式な方法の重要な目標は、自動化された手段または人間主導の手段によってシステムの正確性を証明することです。ただし、正当性を証明できたとしても、システムが故障しないことを保証できない場合があります。例えば：

• 仕様がシステムを正しくモデル化していないか、実動システムが複雑すぎてモデル化できないか、矛盾する要件のためにシステムに本質的に欠陥がある可能性があります。仕様がまったく意味をなすかどうかをテストするためにどのようなテクニックが知られていますか？
• 証明プロセスにも欠陥がある可能性があります！これらの推論規則が正しく、正当であることを誰が知っていますか？さらに、証明は非常に大きくなる可能性がありますが、エラーが含まれていないことをどのようにして知ることができますか？これは、デミロ、リプトン、およびペルリスの「社会プロセスと定理とプログラムの証明」の批評の中心です。現代の形式的手法の研究者は、この批判にどのように対応しますか？
• 実行時には、システムに深刻な影響を与える可能性のある多くの非決定的なイベントと要因があります。たとえば、宇宙線はRAMを予測不可能な方法で変更する可能性があり、より一般的には、ハードウェアがビザンチン障害を被らないという保証はありません。したがって、静的システムの正確さは、システムが失敗しないことを保証しません！実際のハードウェアの誤りを説明するために知られている技術はありますか？
• 現在、テストは、ソフトウェアが機能することを確認するための最も重要なツールです。正式な方法を備えた補完的なツールであるように思われます。しかし、私は主に正式な方法またはテストに焦点を当てた研究を見ています。2つの組み合わせについては何が知られていますか？

4：正式な方法とテストを組み合わせた多くの作業があります。グーグルの「フォーマルメソッドテスト」では、非常に多くの作業が明らかになります。このような作業にはさまざまな目標がありますが、重要な目標の1つは、より効果的なテストスイートを生成することです。この講演では、モデル検査に基づいた素晴らしい紹介をします。

また、問題から編集されたソフトウェアセキュリティの問題についても説明します。正式な方法は、その領域で提供するためにより懸命に取り組む必要があります。通常、ソフトウェアの仕様を記述し、仕様が満たされていること、つまり、入力が前提条件を満たしている場合、出力が事後条件を満たしていることを検証します。安全なソフトウェアを確保するために、前提条件を満たさない入力に対してソフトウェアが適切に動作することも確認する必要があります。（これはもちろん、すべての入力に対して前提条件をtrueに設定することと同等です。）すべての入力のスペースは通常、整形式の入力よりもはるかに大きくなりますが、通常は、その前提に違反しています。

ポイント3に関して：Faulty Logic：Reasoning About Fault-tolerant Programsなど、障害が明示的にモデル化されている設定でシステムを検証するためのいくつかの作業が行われました。マシュー・メオラとデビッド・ウォーカー。プログラミングに関する欧州シンポジウム、2010年。確率モデルのチェックと確率検証の研究は、確かにある程度障害の問題にも確実に対処しています。

順番にあなたのポイント：

• すべての仕様の正しさは最終的に主観的です。ユーザーに応じて問題を正しく解決するか、しないかのどちらかです。これから逃れることはソフトウェア開発ではありませんし、この方法の特効薬となる方法はありません。
• プロセスがその仮定に関して正しいことを証明するために多くの作業が行われます。通常、専門家がこれらのルールを検証するために利用できる情報があります。人間の活動はすべてエラーにさらされますが、十分に研究されたアプローチを使用した非常に形式化されたシステムは、他のほとんどすべての人間のプロセスよりもエラーにさらされにくいです。
• ある時点で、どのシステムにも、そのシステムの範囲外の障害モードがあります。予測不可能なエラーを考慮に入れない場合でも、予測可能なエラーの原因をすべて排除したほうがよいでしょう。
• テストと証明は簡単に共存できます。テストは特定性が低く、アドホックなプロセスであるため、正式な作業が少なくなる場合があります。しかし、Haskell型システムによって提供される証明をテストで補足するQuickCheckなどのツールに興味があるかもしれません。

正式な方法はすでに大きな効果を発揮することがすでに示されています。それらがなければ、現代のデジタルシステム（マイクロプロセッサ）の設計の複雑さに対処できませんでした。

機能的な同等性検証の対象となるロジックを持たないマイクロ船はありません。FPUがFVの対象になっていない場合。キャッシュコヒーレンスプロトコルがFVの対象になっていない（これは1995年以来のケースです）。

ソフトウェアと設計された物理システム（たとえば、安全係数を追加できるブリッジ）の明らかな違いを除けば、それらはCSの工学計算の役割を果たします。ただし、FMの使用は常に利益/コストに依存します。ファズテストは、Microsoftなどの企業で大きな成果を上げています（1つのスライドでGoogle SAGE）。

マイクロ内にも、サブシステム（マイクロプロセッサパイプラインなど）があり、FVが他の場所と同じ影響を与えていません（FPUなど、多くの場合、公式のシンボリックトラジェクトリー評価でバグがないことが証明された従来のテストはまったく行われませんでした） ：Kaivola et al CAV'09）。

アーティファクトの合成にも正式な方法が使用されています（コード、高品質のテスト、バッテリーバンクを最適に使い切るためのスケジュールなど）。もちろん、質問で提起された問題はすべて非常に有効であり、他の技術の使用と同様に、偽の広告を認識して回避する必要があります。

2に関して：システムが証明アシスタント（TwelfまたはAgdaまたはCoqなど）で形式化され、健全性と完全性のプロパティが検証され、このエンコーディングで証明が行われる場合、これは問題ではありません。あなたが意図したことを説明していないシステムを正式にしたかもしれませんが、少なくともあなたは間違った証拠や推論している壊れたシステムを持っていません。

ただし、正当性を証明できたとしても、システムが故障しないことを保証できない場合があります。

はい、おそらく保証はありません。正式な方法は、エラーを見つけて排除し、人間を説得することを目的としています。

仕様がまったく意味をなすかどうかをテストするためにどのようなテクニックが知られていますか？

フォーマルシステムの仕様のモデルチェックツールに興味があるかもしれません。

証明プロセスにも欠陥がある可能性があります！これらの推論規則が正しく、正当であることを誰が知っていますか？

（Goedelの不完全性定理のため）推論ルールのシステムを示すことは、一貫した推論ルールのより強力なセットに一貫してアピー​​ルすると思います。

さらに、証明は非常に大きくなる可能性がありますが、エラーが含まれていないことをどのようにして知ることができますか？

うまくいけば、巨大なプルーフが小さなプルーフチェッカーによってチェックされ、妥当な時間内に人間が読んで理解できるようになります。これは「de Bruijn基準」と呼ばれることもあります。プルーフチェッカーが間違ったプルーフを証明しないと思われる場合は、チェッカーのみをチェックする必要があります。

実際のハードウェアの誤りを説明するために知られている技術はありますか？

どの程度フォルトトレラントは、アセンブリ言語を入力しましたか？

しかし、私は主に正式な方法またはテストに焦点を当てた研究を見ています。2つの組み合わせについては何が知られていますか？

「TAP会議は、証明とテストの収束に専念しています」。

「証明とテスト」をグーグルで検索するだけで、フォールドの上にいくつかの良いヒットがあります。

仕様がまったく意味をなすかどうかをテストするためにどのようなテクニックが知られていますか？

それは間違いなく判断の呼び出しです。ソフトウェアエンジニアリングでは、仕様を検索、書き込み、確認するための非常に厳密な方法論が設計されています。これは実際の人間によって行われ、非形式的な（非数学的な意味での）方法を使用するため、依然として矛盾が生じますが、結局のところ、それは人々が検証したいものに対応しています。

実際のハードウェアの誤りを説明するために知られている技術はありますか？

確かに、ランタイム検証と呼ばれる検証のフィールドがあり、特定のシナリオの対象となる完全に仮想的な環境で実行されている実システムで実行ベースのモデルチェックを使用することもできます（V-DS + APMCでこれに貢献しました）。ただし、これは明らかに、システムと環境の間の相互作用を検証プロセスに追加するための大きな問題です。

しかし、私は主に正式な方法またはテストに焦点を当てた研究を見ています。2つの組み合わせについては何が知られていますか？

うわー、今日私は完全に恥知らずであり、再び自分自身を引用します。モデルのチェックとテストの組み合わせに取り組んでいる共著者は、グループの元博士課程の学生の出版物リストを見るか、優れた検索エンジンで「近似確率モデルチェック」または「統計モデルチェック」を検索できますYounes et al。、Sen et al。またはmyself et al。および他の多く）。

PVS定理証明の設計者の1人であるJohn Rushbyの作品に非常に興味があるかもしれません。あなたは、この古典的な読書を楽しむかもしれない形式手法の使用およびクリティカル・システム（1993）の認定について、FAAに報告書を、そして彼の新しい著作（テスト、証明提供された証拠の様々な手段のうち、確率論を組み立てるについて、正式な安全性の場合、分析など）。