正式な方法の広範な採用を妨げる障壁は何ですか？[閉まっている]

正式な方法を使用して、アプリケーションのコードを指定、証明、生成できます。これはエラーが発生しにくいため、主に安全/クリティカルプログラムで使用されます。

日常のプログラミングやWebアプリケーションなどでもっと頻繁に使用しないのはなぜですか？

参考資料：

• 正式な方法
• B法
• ホアロジック

エンジニアは、バカが10でできることを1ドルでできる人です。

リソースの制約、予算の制約、時間の制約、これらはすべて重要です。

正式な方法を使用したソフトウェアの開発は通常、非常に高価であり、ない場合よりもはるかに時間がかかります。また、多くのプロジェクトで最も難しいのは、ビジネス要件を理解することです。その場合、正式な方法を使用することで得られるのは、ビジネス要件に対する不完全で誤った理解にコードが100％対応していることの証拠です。

そのため、正式な方法、証明、プログラム検証、および同様の手法の使用は通常、「重要なもの」、つまりアビオニクスソフトウェア、医療機器の制御システム、発電所などに限定されます。

プログラムするかしないか？

ソフトウェア製品の問題を解決するために、要件を理解した後、次のことができEITHERプログラミング言語を使ってプログラムを書くOR形式言語と使用のコード生成ツールを使用してプログラムを指定します。後者は単に抽象化のレベルを追加するだけです。

正しいことをしているのか、正しいことをしているのか？

正式なアプローチにより、仕様に従ってソフトウェアが機能することを証明できます。したがって、製品は適切に機能します。しかし、それは正しいことをしますか？

作業対象の要件は、不完全またはあいまいな場合があります。彼らもバグがあります。最悪の場合、実際のニーズさえ表現されません。しかし、写真は千の言葉に値します。たとえば、この記事の「顧客が望むもの」の画像をグーグルで検索するだけです。

正式な費用

完璧な世界では、最初から完全に詳細で完璧な要件があります。その後、ソフトウェアを完全に指定できます。フォーマルに行くと、コードが自動的に生成されるため、生産性が向上します。生産性の向上は、正式なツールのコストを相殺します。そして、誰もが正式な方法を使用するようになりました。それではなぜですか？

実際には、これはめったに現実ではありません！これが非常に多くのウォーターフォールプロジェクトが失敗した理由であり、なぜ反復的な開発方法（アジャイル、RADなど）がリードしたです。不完全および不完全な要件、設計、実装を処理し、問題がなくなるまでそれらを改良できます。

ここにポイントがあります。フォーマルメソッドでは、各反復で完全に一貫したフォーマル仕様が必要です。正式なロジックは許されず、不完全な思考が好きではないため、これには慎重な思考と追加作業が必要です。この制約の下では、単純な使い捨て実験は高価になります。また、バックトラッキングにつながる各反復（たとえば、機能しないアイデア、または誤解された要件）も同様です。

実際には

法的または契約上の理由で正式な方法を使用する義務がない場合は、たとえば契約ベースのプログラミングやその他の優れたプラクティス（コードレビュー、 TDDなど）。ソフトウェアが機能することを証明することはできませんが、ユーザーはソフトウェアをすぐに楽しむことができます。

更新：測定された努力

Communications of the ACMの 2018年10月号には、実際の世界で正式に検証されたソフトウェアに関する興味深い記事があり、努力の見積もりが記載されています。

興味深いことに（軍事機器のOS開発に基づいて）、正式に証明されたソフトウェアを作成するには、 、従来のエンジニアリング技術の3.3倍の労力ます。だから、本当に高額です。

一方、高セキュリティレベル（EAL 7）でソフトウェアを認定する努力を追加する場合、従来のように設計されたソフトウェアに比べて、この方法で高セキュリティソフトウェアを入手するのに必要な労力は2.3倍少なくなります。したがって、高い信頼性またはセキュリティ要件がある場合は、正式に移行するビジネスケースが必ずあります。

seL4の設計とコード開発には2人年かかりました。長年にわたってすべての血清特異的証明を合計すると、8,700行のCコードで合計18人年になります。それに比べて、seL4に匹敵するL4ファミリーの別のマイクロカーネルであるL4Ka :: Pistachioは、開発に6人年かかり、重要なレベルの保証を提供しません。これは 3.3だけ、検証済みのソフトウェアと従来の設計ソフトウェアとの間にます。ColbertとBoehm8による推定方法によると、8,700行のCコードに対する従来のCommon Criteria EAL7認証には45.9人年以上かかります。つまり、正式なバイナリレベルの実装検証は、すでに2.3倍以上です。 Common Criteriaの最高認証レベルよりも低コストでありながら、大幅に強力な保証を提供します。

任意の言語のすべてのプログラムは、正式な仕様と考えることができます（一部のターニングマシンに相当）。正式な正当性を証明するために使用される、より高いレベルの「正式な仕様」も-単なる別のプログラムです。しかし、その（通常）悪い、不完全、漠然とした、不十分な思考はプログラムを通して。偶然ではありませんが、通常は、プログラミングの方法を知らない人によって書かれます（通常はドメインの専門家です）。

そして、1つのプログラムがそのより高いレベルのフォーマル要件と互換性がある（同じ答えを生成するか、それを特徴づける）ことを証明すると、不変はあなたがより高いレベルのフォーマル仕様のあいまいさを解決する方法に帰着します。それを行うための適切な汎用目的の方法はありません。

高いレベルの要件を低いレベルの詳細にマッピングすることが、実際のプログラミングの要点です。プログラマーが仕様を読んで解釈することによって行われている中核的な作業が、手を振って「このサンプルプログラムによってこの高レベルの正式な仕様が遵守されているかどうかを確認してください」と置き換えることはできないことは驚くべきことではありません。

この概念が最初に非常に有望であると思われたロジックプログラミングの初期においてさえ（高レベルの仕様と実際の基礎となるプログラムの両方が同じ言語で記述できるため）、このコアの問題は扱いにくいことが判明しました。