契約によるデザイン – ウィキペディア

契約による設計 （短い DBC 、英語 契約に従ってドラフト ） また 契約によるプログラミング （「契約ベースのプログラミング」）は、ソフトウェア開発の分野からの概念です。目的は、静的定義を超えるインターフェイスを使用するための正式な契約の定義を通じて、個々のプログラムモジュールのスムーズな相互作用です。プログラミング言語Eiffelの開発により、Bertrand Meyerによって開発および導入されました。

プログラムモジュールのスムーズな相互作用は、メソッドを使用する場合、観察する必要がある「契約」によって達成されます。これはで構成されています

• 前提条件（英語 前提条件 ）、すなわち、発信者が満たさなければならないという保証
• Post -Conditions（英語 ポストコンディション ）、すなわち、呼び出されたものと
• Invariant（英語 クラスの不変 ）、クラスのすべてのインスタンスにわたって。

契約は、利用可能な総情報、つまり、変動およびパラメーターのコンテンツ、および影響を受けるオブジェクトまたはその他のアクセス可能なオブジェクトのオブジェクトを指すことができます。呼び出しが前処理と不変に準拠している場合、間違いは発生できず、この方法は予期しない結果を提供しないように保証されます。

入力パラメーターと出力パラメーターを入力することにより、型言語では既に縮小された形式が達成されています。このタイプは、事前およびポストコンディションとして解釈できる値を決定します。ただし、タイプシステムでは、入力値と出力値の間のいくつかのパラメーターまたは関係のコンテキストを記録できません。したがって、それは契約による設計と比較して大幅に弱体化された保護形態を表しますが、一般に翻訳時にこれに適用されますが、契約で行われた保証は期間中にのみ有効になります。

クラスの不変、保存、およびフォローアップを定義することにより、同じ「契約」を満たす場合、モジュールを他の方法に置き換えることができます。ただし、使用されるデザイナーと構文の詳細も、事前およびポストコンディションとして理解する必要がある場合があります。

不変 オブジェクトのライフサイクル全体にわたってクラスのすべてのインスタンスに適用される論理的なステートメントです。それらは通常の形で発生します クラス-in -variants それについては、影響を受けるクラスの私有地にもアクセスできます。したがって、1つは話します 実装Invarianten 。現在のシステムでの不変のレビューは、メソッド呼び出しの前後にのみチェックできるため、メソッド内の不変性は間違いなく 一時的 傷つく。この点で、それらはすべてのメソッド呼び出しの暗黙の前およびその後の条件を表します。これまでのところ、このアプローチは、契約による設計の一般的な実現で追求されていません。

すべてのサブルーチンになります 前提条件 （ 前提条件 ） と ファローアップ （ ポストコンディション ）割り当て。 前提条件 サブルーチンを呼び出す必要がある状況を決定します。たとえば、ファイルから読み取るためのサブルーチンは、事前にファイルが正常に開かれた場合にのみ呼び出される場合があります。 ファローアップ サブプログラム呼び出しが完了した後に与えなければならない条件を決定します。

優先順位とフォローアップ条件は、ブール式として策定されます。前提条件が満たされていない場合（つまり、評価結果 間違い 、したがって、「正しくない」）、呼び出しコードにエラーがあります。そこで、前提条件が満たされていることを確認する必要があります。背中の状態が満たされない場合、サブルーチン自体にエラーがあります。サブルーチンは、後方状態が満たされることを保証する必要があります。

したがって、保護とフォローアップは一種の契約を形成します（英語 契約 ）： もしも 通話コードは前提条件を満たします、 それから サブルーチンは、背中の状態を満たす義務があります。

リスコフの代替原理 [ 編集 | ソーステキストを編集します ]

Liskovscheの代替原則を事前およびポストコンディションに適用すると、次の声明が得られます。

サブクラスの方法を呼び出す前に上流階級の前提条件が満たされている場合、この方法は上流階級の後続条件を満たす必要があります。

これは、サブクラスの方法が、その前後の条件の設計で自由ではないことを意味します。少なくとも、前後の条件によって策定された「契約」を満たす必要があります。これは、前提条件を引き締めてはならないことを意味します（必要な上流階級よりも呼び出しコードからこれ以上要求してはなりません）。後続の条件を和らげてはいけません（少なくとも上流階級と同じくらい保証する必要があります）。

サブクラスの契約条件の概要 [ 編集 | ソーステキストを編集します ]

契約による設計の場合、サブクラスは上流階級に関する次の規則に従う必要があります。

正式には、スーパークラスとサブクラスの関係は、以前と後続の条件に関して次のように表現できます。

前提条件 素晴らしい → 前提条件 サブ 再調整 サブ → 再調整 素晴らしい 

サブクラスの契約条件のレビュー [ 編集 | ソーステキストを編集します ]

前の段落に記載されている論理的意味の履行は、非常に適切にチェックすることができます（履行問題）。したがって、現在の実現にはトリックを使用します。

• 前提条件はリンクされた分離（論理または））です。その結果、上流階級の前提条件は弱体化することしかできませんが、引き締められません。
• 後続の条件は、仮定（論理的および）リンクされています。これは締められるだけですが、弱くなることはありません。
• Invariantesも仮定されています。

契約による設計 ソフトウェアプロパティにのみ適用できます。ソフトウェアプロパティは、処方箋とフォローアップとして策定することもできます。 「ルーチンAがルーチンの前に呼び出されている必要がある」などの条件は、ステータス変数を介してマッピングできます。一方で、これはクラスのプログラミングのための努力の増加を意味します。他方では、ユーザーはそのような装備のオブジェクトを制御下に置いておくことを避けることができますが、他の機能に渡して、ステータスの変更に反応することができます。
同様に、「ルーチンAは常にコース内のルーチンBを呼び出す」（オブジェクト指向の領域では特に重要）ポスト条件およびモジュールの不変剤を介して（特にオブジェクト指向の領域で重要）などの条件。

不変が補助オブジェクトに基づいている場合、エイリアシングによって不変を破壊することができます。すべてのルーチンの開始に加えて不変剤がチェックされた場合、そのような不変侵害のためにプログラムが間違った決定を下す前に不変の破壊を確実に診断することができますが、プログラマーはエイリアスが生成された場所と補助オブジェクトが実際に破壊されたときの兆候を受け取りません。

サブルーチンのセマンティクスが前提条件、後続の条件、およびモジュールの不変剤に完全に巻き込まれている場合、サブルーチンの機能的な仕様を取得し、実際のサブルーチンは原則として保証によって生成される可能性があります。
このようなジェネレーターは、機能的なプログラミング言語のコンパイラテクニックから作成できます。この点で、契約による設計後の手順が完璧に表示されます。

DやEiffelなどのいくつかの普及していないプログラミング言語は、少なくとも部分的にネイティブ、ADA 2012以来のADAなどの契約によるデザインをサポートしています。.NETフレームワークには、バージョン4.0のクラスライブラリが含まれています（特に名前ルームで System.diagnostics.contracts ）、誰も コード契約 契約による設計の実装のために指定されています。 ^[初め] Bean検証の概念はJavaで同じ方法で提供され、Java Bean検証1.1以降、注釈を使用してメソッドに直接事前およびポストコンディショニングを実装することもできました。 ^{[2] [3]} これは以前はフレームワークオーバルまたはJavaモデリング言語（JMLが略して）を介して行われました ^[4] Javaで可能です。
GContractsなどのその他の実装 ^[5] Groovyの場合、APIはコンパイラ拡張機能を使用して適切な言語要素を追加しました。

1. ↑ msdn.microsoft.com
2. ↑ パラメーター制約 Java Bean検証1.1を使用します
3. ↑ 値の制約を返します Java Bean検証1.1を使用します
4. ↑ eecs.ucf.edu 2015年2月6日にアクセス
5. ↑ github.com