是否应始终与包含用例的行为一起执行包含用例的行为？-解网

问：

考虑一个包含 UC2 和 UC3 的用例 UC1。UML 2.5.1 规范在两个用例之间定义：«include»

Include 是两个 UseCase 之间的 DirectedRelationship，指示包含的 UseCase（加法）的行为入到包含的 UseCase（包括 Case）的行为中。
（...）
在恢复执行包含的用例之前，包含的用例的所有行为都会在包含的用例中的单个位置执行。

我理解 UC2 和 UC3 的行为总是与 UC1 一起执行，因为包含定义的肯定措辞意味着系统性并且没有条件的余地（“插入”、“被执行”），而扩展定义明确提到了非强制性的可能性（“可以插入”、“应该添加的行为”、” 可能是有条件的“，另请参阅有关使用CAN和MAY的规范的第5.1节）。

我想知道我的解释是不是太严格了。包含也是如此：

这意味着每当执行 UC1 时，UC2 和 UC3 的行为总是被执行，即为参与者或其他利益相关者提供预期的可观察结果？
或者，其中一个用例（例如 UC2）的行为是否可能并不总是被执行？为什么这种理解符合规范？

语言律师 UML 用例图

确实@qwerty_so！我更愿意专注于目标，并尽可能避免包含/扩展功能分解的陷阱。但是，我不是在建模岛上工作，有时不得不应付其他实践。此外，有时恕我直言，表达某些目标也是更大目标的一部分是有道理的，在这种情况下，我仅在系统的情况下才使用包含。因此，我的问题。

0赞 qwerty_so 9/1/2023

我知道。我可能会在周末找到一个答案......

0赞 qwerty_so 9/3/2023

我重读了 Bittner/Spence 的 Here there are dragons 一章。这就是我的答案。否则，从技术上讲，Geert 的答案可能是正确的——除了我在下面评论的观点。

答：

2赞 Geert Bellekens 8/31/2023 #1

在两种可能的情况下，所包含用例的行为不会被执行：

未满足包含用例中的前提条件

假设 UC1 具有前提条件 User must be authenticate，并且该用户尚未通过身份验证。在这种情况下，UC1 将不会执行。

未到达执行包含的单个位置

规范提到了执行所包含用例的单个位置。现在我们都知道，一个用例不一定遵循单一的步骤序列。尽管 UML 规范中没有明确提及用例场景，但通常有一个主要场景，可能还有一些备用场景和异常场景。

根据具体情况，将无法到达用例中的某些步骤或步骤，可能是因为遵循了备用方案路径，或者可能是因为包含位置位于未遵循此执行的异常路径中。

在这些情况下，我认为完全符合规范，可以说所包含的用例仅在特定条件下执行（即实际达到该执行点）

在此用例 Update Reservation 表示为活动图的场景示例中，我们看到我们只需要在备用场景 Cancel Reservation 中执行用例 Update Inventory

这本可以在 UML 规范中更清楚地表达出来。

非常感谢您非常清晰和图文并茂的解释。尽管如此，我还有一个剩余的担忧：在您的示例中，“更新清单”不应该是一个扩展而不是包含，因为它“在特定条件下增强了扩展用例的执行”？（扩展用例本身并不需要有意义，但如果有意义，也不会被禁止，而且它们也可以发生在一个特定的点上;那么在这种边缘情况下，如何区分、扩展和包含呢？

0赞 Geert Bellekens 9/1/2023

在这种情况下，您可以（不应该）使用扩展@Christophe因为主要用例不依赖于所包含用例的结果。有了像“寻找客户”这样的东西，这是不可能的。include 和 extend 之间的主要区别在于依赖关系的方向，而不是可选性。

0赞 qwerty_so 9/3/2023

标记的操作是活动的实例，而不是用例本身。此活动所属的 UC 可能也有其他活动。我认为“包括 UC xy”只能用文本形式表达。Execute

0赞 Geert Bellekens 9/4/2023

@qwerty_so正确。这是以用例结构化场景的活动图形式呈现的。我更喜欢这种格式，因为它通常比文本场景从业务中获得更好的反馈。

上一个：用例还是参与者的责任？

下一个：使用协程 kotlin 的基本用例

是否应始终与包含用例的行为一起执行包含用例的行为？

Shall the behaviour of an included use-case always be executed with the behavior of the including case?

评论

未满足包含用例中的前提条件

未到达执行包含的单个位置

评论