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

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

这一点在所有关于Include的解释中都不清楚，Include用例是否必须由base自动触发，或者是否可以用于显示每次创建缺勤时，用户都会搜索员工

---

或者，这两者是否都应建模为参与者调用，且两者之间不存在包含关系？

标准很明确，从§18.1.3.3中包括第641页：

Include是两个用例之间的直接关系，表示所包含用例的行为（ 添加）插入到包含用例（includingCase）的行为中

包括的用例的所有行为在包括的用例中的单个位置执行，然后继续执行包括的用例

因此：

• 所包含的用例是否必须由基础自动触发

  ：是的，即使说的方式也不完美，因为所包含的UC没有被触发，而是插入了它的行为

• 是否可用于显示每次创建缺勤时，用户将始终搜索员工

  ：否，如果UC创建缺勤包括UC搜索员工，则用户将不会在之后搜索，而是在期间搜索

• 使用包含关系对此进行建模是否正确？

  ：否

• 或者，这两个角色是否都应建模为已调用的参与者，并且它们之间没有包含关系？

  ：是的，请注意，您可以在UC Create缺勤中设置一个post条件，表示参与者必须搜索员工

---

标准很明确，从§18.1.3.3中包括第641页：

Include是两个用例之间的直接关系，表示所包含用例的行为（ 添加）插入到包含用例（includingCase）的行为中

包括的用例的所有行为在包括的用例中的单个位置执行，然后继续执行包括的用例

因此：

• 所包含的用例是否必须由基础自动触发

  ：是的，即使说的方式也不完美，因为所包含的UC没有被触发，而是插入了它的行为

• 是否可用于显示每次创建缺勤时，用户将始终搜索员工

  ：否，如果UC创建缺勤包括UC搜索员工，则用户将不会在之后搜索，而是在期间搜索

• 使用包含关系对此进行建模是否正确？

  ：否

• 或者，这两个角色是否都应建模为已调用的参与者，并且它们之间没有包含关系？

  ：是的，请注意，您可以在UC Create缺勤中设置一个post条件，表示参与者必须搜索员工

---

请停止谈论正在触发或调用的用例。用例描述了为特定目的使用系统的情况。触发或调用的只能是系统的功能。用例帮助我们找到这些函数。如果使用锤子将板条箱钉在一起，则不会在锤子上调用

将板条箱钉在一起

用例。而是调用

存储动能

函数、

瞄准锤头

函数和

将能量转移到对象

函数。通过分析用例，我们发现钉子经常会弯曲，因此我们可能会发现使用

拉钉子

功能很有用

因此，

搜索员工

是用例

创建缺勤

所需的一项功能。很可能其他用例也需要此功能。在多个用例中需要许多函数。例如，当您想要打开板条箱时，

拉钉功能就很方便了

因此，只有当我找到两个有效的用例时，我才会使用«包含»，其中第一个用例有一个包含在第二个目标中的目标。只有当包含的用例值得分析时。否则只需参考函数即可。您已经有了一个描述其需求的用例

顺便说一下，在用例的上下文中，UML规范总是谈论“行为”。请注意，在讨论UML行为概念时，它将用大写字母“B”书写“行为”。这意味着在这里，它更多地被用在口语意义上。因此，我不会将“include”一句解释为定义了它的精确语义。
请停止谈论正在触发或调用的用例。用例描述了为特定目的使用系统的情况。触发或调用的只能是系统的功能。用例帮助我们找到这些函数。如果使用锤子将板条箱钉在一起，则不会在锤子上调用
将板条箱钉在一起
用例。而是调用
存储动能
函数、
瞄准锤头
函数和
将能量转移到对象
函数。通过分析用例，我们发现钉子经常会弯曲，因此我们可能会发现使用
拉钉子
功能很有用

因此，
搜索员工
是用例
创建缺勤
所需的一项功能。很可能其他用例也需要此功能。在多个用例中需要许多函数。例如，当您想要打开板条箱时，
拉钉功能就很方便了

<