在 uml 用例图中包含或扩展

Question

该应用程序的目的是显示仪表板。 我有几个操作/用例，例如：

• 登录（用户/管理员）
• 显示仪表板 01（用户）
• 显示仪表板 02（用户）
• 显示仪表板 03（用户）
• 显示仪表板 04（用户）
• 过滤数据（用户）
• 管理权限（管理员）
• 管理接口（管理员）
• 管理数据源（管理员）
• 评论（用户）

我的问题是几个仪表板存在哪种连接，还是应该像一个用例“显示仪表板”？

包括还是扩展？

Answer 1

对于User ，我看到以下用例：

• Get an overview of the situation

仅此而已：仪表板和过滤仅意味着您打算解决这些问题。 登录也不是一个用例：它也是解决只有授权用户才能访问信息的限制的一种手段。 单点登录 (SSO) 或面部识别可能是替代方案。

用例并不意味着设计用户界面。 有更好的技术。 用例也不是功能。 用户故事非常适合描述功能（例如，“作为用户，我想过滤仪表板中的数据以找到更具体的见解”）。 你会有几十个，如果不是数百个用户故事，但只有几个用例，因为这些是为了展示大局。

如果你想 model 一些面向动作的东西（显示这个，过滤那个，......）或一些序列（首先登录，然后移动到 dahsboard 01，然后......）你可以考虑一个活动图。

Answer 2

两者都不。 你没有提到用例或用例依赖，但似乎是系统依赖。

根据您要描述的内容，每个站点都被视为一个单独的系统，或者所有这些站点都只是一个系统的模块。

在前一种情况下，如果您试图展示 A 的用例，无论用例需要页面 B、C 或 D，他们都必须联系单独的系统，即 B。由于它是一个单独的系统，因此它将是一个 Actor对于链接到相应用例的 A

在后一种情况下，提供给用户的用例不提供内部实现。 不管它必须使用多少内部模块，它始终只是一个用例。

现在，如果您试图以更精确的方式显示这种依赖关系，它不应该出现在用例图上。 相反，推荐的选项通常是序列图，几乎没有其他可用的替代方案（通信图和活动图是最常出现的补充）。

Answer 3

您好，我已经为我的用例创建了一个活动图表。 你认为它在语法方面是正确的吗？ 我知道我应该插入不同的角色（用户/管理员），终点应该是一个带有黑色填充的白色圆圈。 有什么建议么？