2

契約による設計の投稿や例を読んでいますが、頭を包み込めないように見えるものがあります。私が見たすべての例で、DbC は事後条件 (多数の銀行口座など) で独自の状態をテストする単純なクラスで使用されます。

ほとんどの場合、クラスのメソッドを呼び出すと、メソッド呼び出しをその外部依存関係に委譲することで、はるかに多くの作業が行われるように思えます。メソッドの外部動作に焦点を当てた依存関係の反転とモック オブジェクトを使用して、特定のシナリオで単体テストでこれを確認する方法を理解していますが、これは DbC と事後条件でどのように機能しますか?

2 番目の質問は、複雑な事後条件の理解に対処する必要があります。多くの関数の事後条件を書き出すには、基本的に事後条件の関数の本体を書き直して、新しい状態がどうなるかを知る必要があるように思えます。そのポイントは何ですか？

私は DbC の概念が本当に気に入っています。特に、検証済みのコントラクトを見つけたときに障害状態を再現する方法を見つけられる場合は、大きな可能性があると思います。過去数時間にわたって、私はいくつかのきちんとしたものを読んでいます。Eiffel での自動テスト生成。私は現在、C++ 開発のプロセスを改善しようとしていますが、現在のプロジェクトで築いたすべての土台を失わないようにする方法を理解できれば、何か新しいことを学ぶことにオープンです。ありがとう。

4

2 に答える 2

1

契約レベルでの委任

ほとんどの場合、クラスのメソッドを呼び出すと、メソッド呼び出しを外部依存関係に委譲するというより多くの作業が行われます

この最初の質問について: 関数/メソッドの実装は他の多くの関数/メソッドを呼び出す可能性がありますが、コードの設計者が明確な心を持っていた場合、これは呼び出し元の仕様が仕様の連結であることを意味しません。呼び出し先。他の多くのメソッドを呼び出すメソッドの場合、そのメソッドが正確で明確に定義されたタスクを実行する場合、仕様のサイズを抑えることができます。システム全体が適切に設計されていれば、どちらが適切でしょうか。

実行時のアサーション チェックの観点から明確に質問しています。このコンテキストでは、上記はおそらく次のように表現されるでしょう。呼び出し元の事後条件は、呼び出し元の機能的に目に見える結果のみをチェックします。」

複雑な事後条件を理解する

この「ACSL by example」ドキュメントは興味深いものだと思うかもしれません (ただし、慣れ親しんだものとはおそらく異なるでしょう)。これには、C 関数の正式な契約の例が多数含まれています。コントラクトの言語は、実行時のチェックではなく静的な検証を目的としており、それに伴うすべての利点と欠点があります。これらは、あなたが言及した「銀行口座」よりも少し洗練されています。これらの関数は、単純なものではありますが、実際のアルゴリズムを実装しています。このドキュメントでは、よく考え抜かれた補助述語( Daniel が回答で指摘しているように、Eiffel ではクエリと呼ばれます) を導入することで、コントラクトを短く読みやすくしています。

于 2010-01-27T15:14:41.963 に答える
1

しかし、これは DbC と事後条件でどのように機能するのでしょうか?

すべての関数は、基本的に次のいずれかです。

  • ステートメントのシーケンス
  • 条件文
  • ループ

アイデアは、呼び出されたすべての関数の事後条件の結合を超える関数の結果に関する事後条件をチェックする必要があるということです。

新しい状態がどうなるかを知るために、事後条件の関数の本体を基本的に書き直す必要があること

逆に考えてみてください。そもそも関数を作成した理由は何ですか? 何を追求していたのですか？関数本体自体よりも単純な事後条件で表現できますか? 事後条件は通常、クエリ(C++ ではconst関数) を使用しますが、本体は通常、コマンドとクエリ (オブジェクトを変更するメソッドとオブジェクトから情報を取得するメソッド) を組み合わせます。

場合によっては、そうです。事後条件を使用して付加できる価値はほとんどないことがわかります。このような場合、通常は一連のテストを作成するだけで十分です。

以下も参照してください。

于 2010-01-19T07:59:32.287 に答える