UML 用例图

Question

我正在为以下场景绘制 UML 用例图：

1. 外部系统提供了一个事件 - 我认为我的演员将是生成的事件
2. 系统提取事件
3. 系统丰富活动
4. 系统将丰富的事件与系统中存在的一些数据相关联
5. 如果系统发现命中通知会发送给人类演员
6. 如果不是，则丢弃事件

所以我的两个参与者是：这个外部系统生成的事件和接收通知的用户。

• 事件调用用例摄取事件用例
• 外部用户使用接收通知用例

现在，我不确定如何为我的初始列表中的其他项目建模。

我应该有类似的东西：

• 事件（参与者）- 生成通知（用例）- 用户（参与者）
• 然后是生成通知用例与其他用例之间的一些关系：摄取事件、丰富事件、关联事件？

我应该对丢弃事件建模吗？

谢谢！

Answer 1

让我们看看定义。

演员

我将使用来自UML Specification 的定义，第 18.1.3.1 节

Actor 对实体所扮演的一种角色进行建模，该角色与其相关用例的主体进行交互（例如，通过交换信号和数据）。 Actor 可能代表人类用户、外部硬件或其他系统所扮演的角色

它清楚地列出了谁/什么可以成为演员的详细清单。在您的情况下，它是与您的系统交互的 External System，因此它是您的 Actor。另一个Actor自然是User。

用例

在这里，我将使用 Alistair Cockburn 的“编写有效用例”一书（第 1.1 节）中的定义来支持自己。

用例捕获系统利益相关者之间关于其行为的契约。用例描述了系统在各种条件下响应来自利益相关者之一（称为主要参与者）的请求时的行为。主要参与者启动与系统的交互以完成某些目标。系统响应，保护所有利益相关者的利益。根据提出的特定请求和围绕请求的条件，可以展开不同的行为序列或场景。用例汇集了这些不同的场景。

在您的情况下，很明显，一旦 External System（主要 Actor）提供了一个事件，您的系统就会执行处理，直到通知 User（次要 Actor）或该事件被丢弃.为了实现这一目标，似乎不需要任何延迟或进一步的交互，所以它显然只是一个用例，Ingest event。

以通知User 结束的处理将是您的主要路径，而丢弃事件的路径将是替代路径，甚至是否定路径（取决于您如何看待它）。

如果您将丢弃视为替代路径，则应将与User 的关联的多重性建模为0..1，以显示User 并不总是被通知。如果您将此视为负面路径，则不必这样做，因为这些被视为“失败路径”，因此并非 UC 的所有任务都必须发生。不过我会非常小心。由于您希望丢弃是定期发生的事情，因此它似乎是一条替代路径，而不是负面路径。

替代方法

我的模型中的假设是您主动通知User（例如，向他发送推送、邮件或执行其他操作）。

您可能只是创建了一个通知，而User 必须主动阅读它。在这种情况下，User 根本就不是Ingest event 的演员。相反，Ingest event 的结果是您创建了一个通知（在 UC 图中不可见）。此外，User 需要对Read notifications 附加一个用例，其中他是主要（发起）Actor。

摘要 (TL;DR)

您的场景中只有一个用例：Ingest event。

您的 Actor 是：External System（主要）和 User（具有多重性的次要 0..1）。

Answer 2

• 对于您的演员：Event 不是演员。 Event 是一个事件。如果你没有具体的名字，就叫它External system。
• Ingest event 可以作为 UC。
• 我猜想丰富化与Ingest event 相关。丢弃它也是如此。两者都是用例中的活动。
• 关联并发送给用户将是 (UC---Actor) Inform User --- User。
• 不通知用户将是Inform User 活动中的路径。

一般：

• 用例显示了所考虑的系统为其参与者之一提供的附加价值。
• 用例不是函数（它们隐藏在 UC 的活动中）。
• 如果 UC 没有增加价值，那就没有用例。