実際の正式なプログラム検証

ソフトウェアエンジニアとして、工業製品用のコードをたくさん書いています。クラス、スレッド、いくつかの設計作業、およびパフォーマンスの妥協を伴う比較的複雑なもの。私は多くのテストを行い、テストにうんざりしているので、Coq、Isabelleなどの正式な証明ツールに興味を持ちました...これらのいずれかを使用して、コードにバグがないことを正式に証明できますか？それと？-しかし、これらのツールの1つをチェックアウトするたびに、日常のソフトウェアエンジニアリングに使用できると確信せずに立ち去ります。今、それは私だけである可能性があり、私はそれについてのポインタ/意見/アイデアを探しています:-)

特に、これらのツールの1つを機能させるには、検討中のプログラムのオブジェクト、メソッドなどを証明者に適切に定義するために莫大な投資が必要になるという印象を受けます。それから、証明者は、対処しなければならないすべてのサイズを考えると、蒸気が尽きないのではないかと思います。または、副作用を取り除く必要があるかもしれません（これらの証明ツールは宣言型言語で本当にうまくいくようです）、それが高速ではないため使用できない「実証済みのコード」になるかどうか疑問に思います十分に小さい。また、使用する言語を変更する余裕はありません。JavaまたはC ++である必要があります。OXXXmlでコードを作成するのは上司に伝えることはできません。コードの正確性を証明できます...

フォーマルプルーフツールの経験が豊富な人はコメントできますか？再び-私なりLOVE正式な証明ツールを使用して、私は彼らが素晴らしいと思いますが、私は彼らが私は、Java / C ++の卑しい溝から到達することはできません象牙の塔にいるという印象を持っている...（PS：IまたLOVEハスケル、OCamlは...間違った考え方得ることはありません：私は、宣言型言語や形式的な証明のファンですが、私は）私は現実的ソフトウェア工学にその便利を作ることができる方法を確認しようとしています

更新：これはかなり広いので、次のより具体的な質問を試してみましょう：1）証明者を使用して産業用Java / C ++プログラムの正確性を証明する例はありますか？2）Coqはそのタスクに適していますか？3）Coqが適切な場合、最初にCoqでプログラムを作成し、次にCoqからC ++ / Javaを生成する必要がありますか？4）このアプローチは、スレッド化とパフォーマンスの最適化を処理できますか？

私はあなたの質問のいくつかに簡潔な答えをしようとします。これは厳密に私の研究分野ではないため、私の情報の一部は古くなったり間違っている可能性があります。

1. JavaおよびC ++のプロパティを正式に証明するために特別に設計された多くのツールがあります。

   ただし、ここで少し余談しなければなりません。プログラムの正しさを証明することはどういう意味ですか？Java型チェッカーは、Javaプログラムの正式な特性、つまりa floatやanの追加などの特定のエラーintが決して発生しないことを証明します！あなたはもっと強い特性、つまりあなたのプログラムが望ましくない状態に陥ることができないこと、または特定の関数の出力が特定の数学的仕様に準拠すること、に興味があると思います。簡単に言えば、単純なセキュリティプロパティから、プログラムが詳細な仕様を満たしていることを完全に証明するまで、「プログラムの正しいことを証明する」という意味には大きな勾配があります。

   ここで、プログラムについて強力な特性を証明することに興味があると仮定します。セキュリティプロパティに関心がある場合（プログラムが特定の状態に到達できない場合）、一般的にはモデルチェックが最善のアプローチと思われます。ただし、Javaプログラムの動作を完全に指定する場合は、その言語の仕様言語、たとえばJMLを使用するのが最善の策です。ACSLなど、Cプログラムの動作を指定するための言語はありますが、C ++については知りません。

2. 仕様が決まったら、プログラムがその仕様に準拠していることを証明する必要があります。

   このためには、適切な定理、つまりプログラムの実行が仕様を尊重することを表現するために、仕様と言語の動作セマンティクス（JavaまたはC ++）の両方を正式に理解するツールが必要です。

   このツールを使用すると、その定理の証明を定式化または生成することもできます。現在、これらのタスク（指定と証明）はどちらも非常に難しいため、多くの場合2つに分けられます。

   • コード、仕様を解析し、適切な定理を生成する1つのツール。フランクが述べたように、クラカトアはそのようなツールの例です。

   • 定理を証明する1つのツール。自動またはインタラクティブに。Coqはこの方法でKrakatoaと対話し、Z3などの強力な自動化ツールも使用できます。

   1つ（小さな）ポイント：自動化された方法では証明するのが難しすぎる定理がいくつかあります。また、自動定理証明器には、信頼性を低下させる健全性のバグがあることが知られています。これは、Coqが比較して輝いている領域です（ただし、自動ではありません！）。

3. Ocamlコードを生成する場合は、必ず最初にCoq（Gallina）を記述してから、コードを抽出してください。ただし、Coqは、可能な場合でもC ++またはJavaの生成がひどいです。

4. 上記のツールはスレッド化とパフォーマンスの問題を処理できますか？おそらくそうではありませんが、パフォーマンスとスレッドの問題は特に難しい問題であるため、特別に設計されたツールで処理するのが最適です。Martin HofmannのPolyNIプロジェクトは興味深いようですが、ここで推奨するツールがあるかどうかはわかりません。

結論として、「実世界」のJavaおよびC ++プログラムの正式な検証は、大きく発達した分野であり、Coqはそのタスクの一部に適しています。たとえば、ここで概要を確認できます。

産業用または非自明な実システムでの形式的手法/形式的検証ツールの3つの注目すべきアプリケーションに言及したいと思います。私はこのトピックについてほとんど経験がなく、論文を読むことからしか学習していないことに注意してください。

1. 2005年にNASAによってリリースされたオープンソースツールJava Pathfinder（略してJPF）は、実行可能なJavaバイトコードプログラムを検証するシステムです（Java Pathfinder @ wikiを参照）。NASA AmesのK9 Roverのエグゼクティブソフトウェアの不整合を検出するために使用されています。

2. このペーパー：モデルチェックを使用して深刻なファイルシステムエラーを検出する@ OSDI'04では、モデルチェックを使用してファイルシステムの重大なエラーを検出する方法を示します。FiSCと呼ばれるシステムは、広く使用され、テストされた3つのファイルシステムext3、JFS、およびReiserFSに適用され、32の重大なバグが見つかりました。ベストペーパー賞を受賞しました。

3. このペーパー：Amazon Web ServicesがFormal Methods @ CACM'15を使用する方法では、AW​​SがS3、DynamoDB、EBS、内部分散ロックマネージャーなどの製品に正式なメソッドを適用する方法について説明しています。LamportのTLA +ツールに焦点を当てています。ところで、Lamportは自分のTLAツールボックスを集中的に使用しました。彼は、論文の付録で自分自身（および共著者）が提案したアルゴリズム/定理の（非常に完全な）正式な検証をTLAで頻繁に行います。

プログラムの正式な仕様は、（多かれ少なかれ）別のプログラミング言語で書かれたプログラムです。その結果、仕様には必ず独自のバグが含まれます。

フォーマル検証の利点は、プログラムと仕様が2つの別個の実装であるため、バグが異なることです。しかし、常にではありません。バグの一般的な原因の1つである、見落とされたケースは、しばしば一致します。したがって、正式な検証は万能薬ではありません。それでも、重要なバグを見逃す可能性があります。

フォーマル検証の欠点は、実装コストの2倍、おそらくそれ以上を課す可能性があることです（フォーマル仕様の専門家が必要であり、それに付属する多かれ少なかれ実験的なツールを使用する必要があります;安くはなりません） ）。

テストケースとスキャフォールディングを設定して自動的に実行する方が、時間を有効に活用できると思います。

セーフティクリティカルな組み込みシステム向けに設計されたC ++のサブセットで記述されたプログラムの正式な検証が可能になりました。参照http://eschertech.com/papers/CanCPlusPlusBeMadeAsSafeAsSpark.pptを短いプレゼンテーションのために、そしてhttp://eschertech.com/papers/CanCPlusPlusBeMadeAsSafeAsSpark.pdf完全な紙のために。

いくつかの異なる質問をします。産業/商業アプリケーションの正式な検証方法はそれほど一般的ではないと思われることに同意します。ただし、プログラムの正確性を判断するために、多くの「形式的検証」の原則がコンパイラに組み込まれていることを理解してください。ある意味では、最新のコンパイラーを使用している場合、フォーマル検証で最先端の多くを使用していることになります。

あなたは「テストにうんざりしている」と言いますが、正式な検証は実際にはテストの代わりではありません。ある意味では、テストのバリエーションです。

あなたはJavaに言及します。FindBugsと呼ばれるJava検証プログラムに組み込まれた多くの高度な形式検証方法がありますが、実際には大規模なコードベースで実行できます。「偽陽性と偽陰性」の両方が発生することに注意してください。結果は人間の開発者がレビュー/分析する必要があります。ただし、実際の機能的な欠陥を引き起こしていない場合でも、通常はコードで回避する必要がある「アンチパターン」を引き起こします。

「産業」以外の特定のアプリケーションについてはもう言及しません。実際の正式な検証は、特定のアプリケーションに依存する傾向があります。

EEでは、マイクロプロセッサの設計など、回路の正確性を証明するために正式な検証手法が広く使用されているようです。

ここに、ラースフィリップソンによるEE分野の正式な検証ツールの調査の例があります。

おそらく、モデルチェッカーが役立つ場合があります。

http://alloytools.org/documentation.html Alloyはモデルチェッカーです。

Alloyを使用したモデル検査の概念を説明する素晴らしいプレゼンテーション：https : //www.youtube.com/watch?v=FvNRlE4E9QQ

同じファミリのツールには「プロパティベースのテスト」があり、それらはすべて、ソフトウェアの指定された仕様モデルの反例を見つけようとします。