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

Question

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

例如，如果我的CRUD系统操作如下：

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

什么是后置条件，例如readEmployee系统操作，或其他一些操作，如searchEmployees等？

例如：对于读取操作，系统需要从数据库中读取记录，实例化域对象，在域对象上设置属性值（也设置关系），就是这样。这是否意味着上面提到的后置条件 - 实例创建，属性更改等。或者，读操作没有任何后置条件。这些对我来说都不符合逻辑。

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

Answer 1

后置条件定义了应用程序（或对象的状态，取决于抽象级别）在操作之后应该被视为成功的状态。例如，对于readEmployee操作，后置条件是：

• 创建了一个新的Employee实例。
• Employee实例包含与数据库值匹配的属性。
• 数据库连接已关闭。

我喜欢将“前置条件”和“后置条件”分别视为操作执行前后应用程序的“心态”。你可以想象，当你做DbC时，它更像是一个思考过程而不是编码练习。

（如果您进行单元测试，状态会明确说明您的测试需要涵盖哪些内容。基本上，您最终会测试应用程序的“心态”。）

有趣的是，如果你考虑DbC的逆转，你就会意识到要确定你的应用程序（或对象）应该暴露什么操作，只需要列出它可以拥有的状态以及它们如何在这些状态之间转换。您需要采取的操作才能使这些转换成为您的操作，并且您不必费心实施不会导致任何所需状态的操作。因此，例如，您可能希望应用程序具有以下状态。

• 添加了员工详细信息（S1）
• 加载员工详细信息（S2）
• 员工详细信息已更新（S3）
• 删除员工详细信息（S4）

可以进行以下状态转换。

• S1 - ＆gt; S3（添加新员工，更新详细信息）
• S1 - ＆gt; S4（添加新员工，删除员工）
• S2 - ＆gt; S3（加载员工详细信息，更新员工详细信息）
• S2 - ＆gt; S4（加载员工详细信息，删除员工）
• S4 - ＆gt; S1（删除员工，添加新员工）
• S2 - ＆gt; S1（加载员工详细信息，添加新员工）
• S3 - ＆gt; S1（更新员工详细信息，添加新员工）
• S3 - ＆gt; S2（更新员工详细信息，加载员工详细信息）

基于以上所述，您可以编写操作，只允许有效的转换，以及其他任何导致错误的转换。

不可能的状态转换：

• S4 - ＆gt; S2（无法删除员工，然后加载他们的详细信息）
• S4 - ＆gt; 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相关联”。

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