Larman的系统操作合同 - CRUD示例

Question

我对使用Larman的系统操作合同（来自应用UML和模式的书中的OO分析）对类似CRUD的操作有些困惑。更确切地说，我对后置条件感到困惑。

举例来说，如果我有CRUD系统操作看如下：

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

这将是对后置条件，例如，readEmployee系统操作，或一些其它操作喜欢searchEmployees等？例如：对于读取操作，系统需要从数据库中读取记录，实例化域对象，在域对象上设置属性值（也可以设置关系），就是这样。这是否意味着后置条件如上所述 - 实例创建，属性更改等。或者，读操作没有任何后置条件。这听起来对我来说都不合逻辑。

我的困惑是关于领域模型（状态）和数据库（状态）之间的关系。我只是没有得到上述操作对域模型的影响。我总是认为数据库是一个保存系统状态的地方。创建员工之后，其对象的状态将保留在数据库中......但是域模型状态会发生什么情况？

Answer 1

后置条件定义了应用程序（或对象，取决于抽象级别）的状态应该在操作之后被认为是成功的。例如，对于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的对象生命周期对状态进行建模的。它是一本相当老的书，在亚马逊上几乎没有任何成本，但它引入的原则构成了现代UML的基础 - 顺便说一句，本书中使用的符号看起来与UML完全不同。

我意识到我没有涉及数据库状态，但在概念层面上，数据库层只是另一个状态系统，适用相同的原则。

我希望这是有用的。

Answer 2

我对Larman合同的解释总是与领域模型有关。 Larman与明确指出，只有5种类型的后置条件：

1. 的实例创建
2. 实例删除
3. 的价值属性的变化。
4. 形成的协会。
5. 协会破裂。

因此，读（或搜索）操作将有没有后置条件，至少不是正在读取或搜索的元素。例如，如果10,000个用户在一天内执行了读取/搜索操作，但从未执行过任何其他操作（C，U，D），则不会更改该域中的对象。

但是，在搜索/读取被记住的域中有一个例外。例如，Google肯定会追踪搜索。在这种情况下，搜索具有在其领域模型中创建新对象的后置条件，例如，，搜索实例 s 已创建（实例创建）。

Answer 3

混乱的形式来提的是Larman与如在所提供的合同模板中的数据模型的关系：数据库的

Contract CO2: enterItem 
Operation: enterItem(itemID : ItemID, quantity : integer) 
... 
sli was associated with a ProductSpecification, based on itemID match (association formed). 

细节参考属性不应该在操作合同被提及。最好将它留作：“sli与ProductSpecification关联”。

事实上，这是Larman的运营合同中没有详细讨论的事情之一。考虑计算项目总数并返回总数的操作合同！似乎它不能被写成操作合同。