显示对除“<<extend>>”或“<<include>>”之外的 UML 用例图的依赖关系

Question

除了“扩展”或“包含”之外，我们如何显示用例之间的简单依赖关系。例如，我们想说用例 1 依赖于用户 1 完成的用例 2。可以使用简单的箭头吗？哪个方向？

Answer 1

是的。还有其他依赖项。

直接连接到用例的类的完整列表是（UML 2.5 标准的图 18.1）：

• 用例
• 约束
• 演员
• 包括
• 扩展
• 扩展点

但这并不意味着您不能将图表中的其他 UML 元素与用例一起使用。 UML 标准不将任何元素限制为图表。您甚至可以在一张图上使用所有 UML 元素。另一方面，这当然是毫无意义的。

可以看到一个可用的实用集，例如，查看 VP UML 的用例面板上的元素。除了已经提到的，还有：

• 系统
• 依赖关系
• 概括
• 实现
• 合作
• 注意
• 锚点
• 遏制

here 你可以看到一个带有解释的简短列表。

如您所见，依赖不仅是标准允许的（所有都是），而且被广泛使用。

Answer 2

您有多种可能性来显示用例之间的依赖关系。您可以使用的关键字比 > 和 > 更多。

1. > - 表示 UC2 需要先执行 UC1。
2. > - 表示此用例在另一个用例之后立即执行。
3. > - 表示该用例在结果和前置条件上与另一个用例相似，但具有不同的活动
4. > - 相同的用例但名称不同。

在你的情况下，我会从演员（user1）画一个箭头到case1，然后是case1 > case2。 您始终需要记住的是图表的目的。如果您使用 UML 作为草图，则足以确保该图是可理解的并且在范围内。过度规范将不支持这一点。

Answer 3

您说：“用例 1 取决于用户 1 完成的用例 2”。

你能澄清一下吗？ UC1 如何依赖 UC2？

UC 建模可能非常棘手。建模者相对容易忘记 UC 实际上是什么，并在模型中混合一些其他系统关注点。

UC 模型不应表达源自底层系统结构的依赖关系。例如，如果 UC1 实现了一个组件，该组件也用于 UC2 的实现，则这种情况不会显示在 UC 模型本身上。你说的依赖这个成熟吗？

两个UC之间的执行顺序通常也隐藏在图中（可以通过前置条件和后置条件间接显示，但不能使用关系）。

我的建议是保持 UC 模型尽可能简单，并将关系限制为适度使用 include 和 extend。 UC 可以看作是交互的抽象，参与者和系统之间的对话。一个对话如何依赖于其他对话？