2

CRUD のような操作で Larman のシステム操作コントラクト (書籍 Applying UML and Patterns の OO 分析) を適用することについて、多少の混乱があります。より正確には、事後条件部分と混同しています。

たとえば、次のような CRUD システム操作があるとします。

createEmployee(employee:Employee), 
readEmployee(employeeId:int), 
updateEmployee(employee:Employee), 
deleteEmployee(employeeId:int)

たとえば、readEmployeeシステム操作やその他の操作searchEmployeesなどの事後条件は何ですか?

例：読み取り操作の場合、システムはデータベースからレコードを読み取り、ドメインオブジェクトをインスタンス化し、ドメインオブジェクトに属性値を設定する（関係も設定する）必要があります。インスタンスの作成、属性の変更など、事後条件が上記で言及されていることを意味しますか。または、読み取り操作には事後条件がありません。これはどれも私には論理的に聞こえません。

私の混乱は、ドメイン モデル (状態) とデータベース (状態) の関係についてです。上記の操作がドメインモデルに与える影響はわかりません。データベースはシステムの状態を保存する場所だと常に考えています。従業員を作成した後、そのオブジェクトの状態はデータベースに永続化されます...しかし、ドメイン モデルの状態はどうなるでしょうか?

4

3 に答える 3

0

事後条件は、アプリケーション (または抽象化のレベルに応じてオブジェクト) の状態が、操作が成功したと見なされるためにどのような状態になるべきかを定義します。たとえば、readEmployee操作の場合、事後条件は次のようになります。

  • 新しいEmployeeインスタンスが作成されます。
  • Employeeインスタンスには、データベース値と一致する属性が含まれています。
  • データベース接続が閉じられています。

「事前条件」と「事後条件」は、それぞれ操作が実行される前後のアプリケーションの「心の状態」と考えるのが好きです。ご想像のとおり、DbC を実行するときは、コーディングの演習というよりは思考プロセスです。

(単体テストを行う場合、状態によって、テストでカバーする必要があるものが明確になります。基本的に、アプリケーションの「心の状態」をテストすることになります。)

興味深いことに、DbC の逆を考えると、アプリケーション (またはオブジェクト) が公開する必要がある操作を特定するには、アプリケーションが取り得る状態と、これらの状態間でどのように遷移するかをリストするだけの問題であることがわかります。これらの遷移を行うために実行する必要があるアクションは、操作になります。目的の状態に至らない操作をわざわざ実装する必要はありません。したがって、たとえば、アプリケーションに次の状態が必要になる可能性があります。

  • 従業員の詳細が追加されました (S1)
  • 従業員の詳細が読み込まれました (S2)
  • 従業員の詳細が更新されました (S3)
  • 従業員の詳細が削除されました (S4)

以下の状態遷移が可能です。

  • S1 -> S3 (新しい従業員の追加、詳細の更新)
  • S1 -> S4 (新しい従業員の追加、従業員の削除)
  • S2 -> S3 (従業員の詳細を読み込み、従業員の詳細を更新)
  • S2 -> S4 (従業員の詳細を読み込み、従業員を削除)
  • S4 -> S1 (従業員の削除、新しい従業員の追加)
  • S2 -> S1 (従業員の詳細を読み込み、新しい従業員を追加)
  • S3 -> S1 (従業員の詳細の更新、新しい従業員の追加)
  • S3 -> S2 (従業員の詳細の更新、従業員の詳細の読み込み)

上記に基づいて、有効な遷移のみが許可され、それ以外はエラーを引き起こすような方法で操作を記述することができます。

不可能な状態遷移:

  • S4 -> S2 (従業員を削除してから詳細をロードすることはできません)
  • S4 -> S3 (従業員を削除してから詳細を更新することはできません)

ステート モデリングは、おそらくオブジェクトの設計において最も重要な部分です。状態モデリングに関する優れたリソースが必要な場合は、Sally Shlaer / Stephen Mellorの Object Lifecycles Modeling the World in Statesを入手してください。これはかなり古い本であり、Amazon での価格はほとんどありませんが、この本で紹介されている原則は最新の UML の基礎を形成しています。

データベースの状態については触れていませんが、概念レベルでは、データベース層は状態の別のシステムであり、同じ原則が適用されます。

これがお役に立てば幸いです。

于 2012-04-18T23:33:23.823 に答える
0

ラーマンのコントラクトの私の解釈は、常にドメイン モデルに関するものです。Larman は、投稿条件には 5 種類しかないと明言しています。

  1. インスタンスの作成
  2. インスタンスの削除
  3. 値の属性変更。
  4. 協会が結成されました。
  5. 関連付けが壊れています。

したがって、読み取り (または検索) 操作には事後条件がありません。少なくとも、読み取りまたは検索されている要素にはありません。たとえば、1 日に 10,000 人のユーザーが読み取り/検索を実行し、他の操作 (C、U、D) をまったく実行しなかった場合、ドメイン内のオブジェクトに変更はありません。

ただし、検索/読み取りが記憶されるドメインでは例外があります。たとえば、Google は確実に検索を追跡します。この場合、検索を実行すると、ドメイン モデルに新しいオブジェクトを作成するという事後条件があります。たとえば、A Search instance s was created (instance creation)です。

于 2015-06-29T20:39:30.550 に答える