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

Question

我对在类似 CRUD 的操作上应用 Larman 的系统操作契约（《应用 UML 和模式》一书中的 OO 分析）感到有些困惑。更准确地说，我对后置条件部分感到困惑。

例如，如果我的 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 获取在状态中对世界进行建模的对象生命周期。这是一本很老的书，在 Amazon 上几乎不需要花钱，但它介绍的原理构成了现代 UML 的基础——顺便说一句，书中使用的符号看起来一点也不像 UML。

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

我希望这有用。

Answer 2

我对拉曼合约的解释始终是相对于领域模型的。 Larman 明确指出后置条件只有 5 种类型：

1. 实例创建、
2. 实例删除
3. 、属性值更改。
4. 协会成立。
5. 协会被打破。

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

然而，在记住搜索/读取的领域中存在一个例外。例如，谷歌肯定会跟踪搜索。在这种情况下，执行搜索的后置条件是在其域模型中创建新对象，例如创建了一个搜索实例（实例创建）。

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 相关联”。

事实上，这是拉曼的运营合同中没有详细谈论的事情之一。考虑一个计算项目总数并返回总数的操作合约！好像不能写成经营合同。