UML 用例图——正确地描述关系？答案

【问题标题】：UML use case diagram - depicting relationships correctly?UML 用例图——正确地描述关系？
【发布时间】：2021-11-14 22:17:23
【问题描述】：

我想知道是否有人可以让我知道这个图表是否大致正确？

我正在描述一个数据库预订系统，但我对其中一些用例之间的关系感到非常困惑。我相当确定我应该将它们包含在同一张图中，但不确定我的一些演员（兽医/护士）是否应该在右侧，因为他们是最终用户，同时也是第一个用户（抱歉不能回忆一下这个词）。

【问题讨论】：

嗯。哪个图？
嗨，Jenny，您本可以付出一些努力，在没有应用程序或计算机的额外部分的情况下包含一个可读性很好的图表。如果您懒得花时间在您的问题上，您怎么能指望人们花时间来回答它。
我不知道该怎么做。我会用谷歌搜索并回复你。
完成！希望这会更容易查看。
在哪里画演员并不重要。您可以在不改变模型含义的情况下将演员从左侧移动到右侧，反之亦然。您如何将用例划分为多个图表也无关紧要。您可以在一张图中全部描绘它们，在一张图中绘制一些，在另一张图中绘制一些，或者您甚至可以在多个图中绘制相同的用例。它不会影响模型的语义。

【解决方案1】：

因此，当您对用例图进行建模时，您必须意识到您只能用于描述系统的功能需求。

您的系统被视为黑盒，即处理系统响应参与者输入的操作，而不是处理它的内部操作。用例总是从参与者的输入开始。

在为图表建模之前，您必须确定参与者（主要、次要）、用例和用例关系。参与者是谁或什么在用例的任务中发起事件。 Actor 只是人们在对象之前扮演的角色。

根据你的问题，

狗主人打电话给诊所预约一年清理。护士找到最近的空闲时间段约会簿并安排该时间段的约会。

在这里您可以看到涉及场景的两个人，狗主人和护士，但与系统交互的实际演员是护士。

用例是单个任务或目标的场景摘要。因此，您可以看到 Nurse 正在为狗主人预约。所以到最后，你必须确定什么是关系。简单的关系表示参与者之间的通信和用例或用例之间的依赖关系。

用例之间的依赖关系可以通过使用包含和扩展关系来定义。 Include 用于 determine 来识别多个用例中的常见交互序列。（可提取重复使用）

& 扩展是 使用用例可能具有的模型替代路径。并且您必须记住，基本用例不依赖于扩展用例

【讨论】：

请不要提倡使用«extends»来描述替代方案。我发现，在超过 90% 的情况下，不需要扩展用例，可以将其替换为包含，或主要用例中的替代场景（或两者）。扩展似乎只在非常有限的条件下有用。
我同意 «extend» 不应被视为模拟替代场景的标准方式。甚至 «include» 也应该仅用于令人信服的原因，例如重用，而不是用于功能分解。但是看看这个用例图，每个“扩展”关联都可能有一个很好的业务案例。例如，现在可以在第 1 版中完全指定、开发和测试用例“取消预约”，并在第 2 版中添加可选的取消费用支付。