用例图：被包含的用例是否必须由基础用例触发？

Question

如果我有一个由演员调用的用例，例如“创建缺勤”，每次演员创建缺勤时，他们都需要“搜索员工”，那么使用包含关系对此建模是否正确？

在所有的解释中，这一点并不清楚，被包含的用例是否必须被基础自动触发，还是可以用来显示每次创建缺勤时用户总是会搜索员工。

或者两者都应该被建模为由演员调用，并且它们之间没有包含关系？

- berimbolo

Answer 1

标准很清楚，来自formal/2017-12-05 § 18.1.3.3 包含页面641：

包含是两个用例之间的DirectedRelationship，表示被包含的UseCase（即添加项）的行为被插入到包含它的UseCase（即包含项）的行为中。

在包含UseCase的单个位置执行所有被包含UseCase的行为，然后继续执行包含UseCase。

所以：

• 被包含的用例是否必须由基础自动触发：是的，即使方式不完美，因为被包含的UC并非被触发，而是其行为被插入。

• 它能否用于显示每次创建缺勤时用户都会搜索员工：不，如果UC创建缺勤包含UC搜索员工，则用户将不会在之后搜索，而是在期间搜索。

• 使用包含关系对此建模是否正确：不是。

• 或者这两个应该被建模为演员调用，并且它们之间没有包含关系？：是的，注意您可以在UC创建缺勤中设置后置条件，说明演员将需要搜索员工。

- bruno

---

@berimbolo 哦，是的，抱歉我在评论中说错了话，但我的答案是正确且未更改的。UC 创建缺勤 是否包含搜索员工的内容取决于您，但对我来说，UC的名称表明已经找到了员工并且您知道必须创建缺勤，否则最好将UC命名为创建所需的缺勤（复数），因为当激活UC时，需要创建缺勤的可能员工是未知的。无论如何，请注意，用例描述系统对外部刺激的操作，而不是实现方式（如何做）。 - bruno

太好了，谢谢。我正在按照你的帖子建模，将它们作为单独的用例，彼此之间没有包含关系。一方面，这更符合逻辑，经过和你的交流后我也更加认同；另一方面，这样做对其他人来说更加清晰明了，避免混淆到底发生了什么。 - berimbolo

所以我对所教授的材料提出了疑问，并被讲师告知：“然而，“包含”关系的理解是，所包含的用例永远不会单独存在，这意味着它们本身不能为用户提供有价值的目标。” 这似乎与我在此处收到的两个答案相矛盾，因为现在我被告知只有带有“扩展”的用例是独立的... 我现在更加困惑了——“另一方面，扩展的用例是独立的，这意味着它们本身可以为用户提供有价值的东西。” - berimbolo

那么，您是否可以有一个用例被其他用例包含，但是又是独立的？讲师在暗示这个问题的答案是否定的，包含的用例不能独立存在... - berimbolo

@berimbolo 如果它只是被包含在内，那么它就不是独立的。从先验上看，并没有什么反对一个被包含的 UC 也可以是独立的（因此受到一个 actor 的刺激），但这可能很少见。 - bruno

Answer 2

请不要再谈论用例被“触发”或“调用”了。一个用例描述的是使用系统达到某个目的的情况。被触发或调用的只能是系统的功能。用例帮助我们找到这些功能。如果你用锤子钉木板，那么“钉木板”用例并不会在锤子上被调用。相反，“储存动能”功能、“瞄准锤头”功能和“将能量转移到物体”功能被调用。通过分析用例，我们发现钉子经常会弯曲，所以可能会有“拔钉子”的功能很有用。

因此，“搜索员工”是一个函数，需要用例“创建请假申请”。很可能其他用例也需要这个功能。许多函数在多个用例中都需要。例如，“拔钉子”功能在您想打开一个板条箱时非常方便。

因此，我只会在找到两个有效的用例时使用“包含”，其中第一个用例的目标包含在第二个目标中。而且只有当包含的用例值得分析时才会这样做。否则只需引用该功能。您已经有一个描述其需求的用例。

顺便说一下，在用例的背景下，UML规范总是谈论“行为”。请注意，当它谈论UML行为概念时，它将用“B”大写的“Behavior”来表示。这意味着这里更多地是以口头方式使用。因此，我不会解释关于“包含”的句子，作为定义其精确语义的一部分。

- Axel Scheithauer

---

许多关于用例的文本对于什么是有效用例的标准要求过低。我赞同Alistair Cockburn在《编写有效用例》中的观点，即用例描述了系统如何向用户（或其他利益相关者）提供价值。因此，“验证Pin”只是一个工具性目标，本身没有任何价值。我只关心它是否是达到检索资金最终目标的一步。 - Axel Scheithauer

你是在寻找一个员工然后关闭应用程序吗？还是你正在寻找一个员工来添加病假或休假，或者更改他/她的工资或角色等等... 用例试图捕捉用户为什么需要系统。仅仅为了没有目的地搜索员工通常不会增加价值，找到新的火车连接则会，至少如果你错过了原来的火车。另一个指导原则是，用例是否帮助我找到新的功能。搜索员工已经是一个功能，从分析用例 使用函数“搜索员工”中无法学到任何新东西。 - Axel Scheithauer

不，这些东西是用例步骤，通常涉及系统功能。如何描述用例步骤是一个方法论问题。一些作者建议使用基本流和替代流的表格，而其他人则更喜欢交互图。我通常使用活动图，因为它们可以在一张图片中展示所有的替代流程。 - Axel Scheithauer

您是否同意或不同意以下观点：“然而，对于‘包含’关系的理解是，所包含的用例永远不会独立存在，这意味着它们本身无法为用户提供有价值的目标。只有与包含的用例一起，它们才能向用户提供有价值的东西。”？您似乎认为包含用例的解释可以独立存在，但我在上面的回答中引用的标准中并没有任何说明所包含的用例不能独立存在。 - berimbolo

规范只知道“用例”的一个定义。这个定义的强制组成部分是，用例必须有一个值的结果。这意味着包含的用例也必须具备这一点。现在，有些人认为即使无法独立存在，达到中间目标已经具有价值。有两个问题：哪些中间目标值得通过用例进行分析？如何区分可以独立存在和不能独立存在的用例？我有时会使用“次要”这个原型来表示后者，并且只有在多个用例需要包含它时才创建它。 - Axel Scheithauer