UML 用例图
UML Use-Case Diagram
我正在为以下场景绘制 UML 用例图：
- 外部系统提供了一个事件 - 我想我这里的演员将是生成的事件
- 系统摄取事件
- 系统丰富活动
- 系统将丰富的事件与系统中存在的一些数据相关联
- 如果系统发现命中通知发送给人类演员
- 如果不是，事件被丢弃
所以我的 2 个参与者是：这个外部系统生成的事件和接收通知的用户。
- 事件调用用例摄取事件用例
- 外部用户使用接收通知用例
现在，我不确定如何为我的初始列表中的其他项目建模，因为它们应该被建模。
我应该有这样的东西吗：
- 事件（参与者）- 生成通知（用例）- 用户（参与者）
- 然后生成通知用例与其他用例之间的一些关系：摄取事件、丰富事件、关联事件？
我是否应该为丢弃事件建模？
谢谢！
- 对于您的演员：
Event 不是演员。 Event 是一个事件。如果您没有特定名称，请将其命名为 External system.
Ingest event 作为 UC 就可以了。- 我猜
Ingest event 会带来丰富的内容。丢弃它也一样。两者都是用例中的活动。
- 关联并发送给用户将是 (UC---Actor)
Inform User --- User.
- 不通知用户将是
Inform User 活动中的一条路径。
一般：
- 用例显示所考虑的系统为其参与者之一带来的附加值。
- 用例不是功能（它们隐藏在 UC 的活动中）。
- 如果 UC 不增加价值，则它不是用例。
让我们看看定义。
演员
我将使用第 18.1.3.1 节 UML Specification 中的定义
An Actor models a type of role played by an entity that interacts with the subjects of its associated UseCases (e.g., by exchanging signals and data). Actors may represent roles played by human users, external hardware, or other systems
它清楚地表明了接近 who/what 的列表可以成为演员。在您的情况下，它是一个与您的系统交互的 External System，因此它是您的 Actor。另一个Actor自然是User.
用例
在这里，我将使用 Alistair Cockburn 的 "Writing Effective Use Cases" 书中（第 1.1 节）中的定义来支持自己。
A use case captures a contract between the stakeholders of a system about its behavior. The use case describes the system’s behavior under various conditions as it responds to a request from one of the stakeholders, called the primary actor. The primary actor initiates an interaction with the system to accomplish some goal. The system responds, protecting the interests of all the stakeholders. Different sequences of behavior, or scenarios, can unfold, depending on the particular requests made and conditions surrounding the requests. The use case collects together those different scenarios.
在您的情况下，很明显，一旦 External System（主要 Actor）提供了一个事件，您的系统就会执行处理，直到 User（次要 Actor）是通知或事件被丢弃。为了实现这一目标，似乎不需要延迟或进一步的交互，所以它显然只是一个用例，Ingest event.
以通知 User 结束的处理将是您的主要路径，而事件被丢弃的路径将是替代路径甚至是否定路径（取决于您如何看待它）。
如果您将丢弃视为替代路径，您应该将关联的多重性建模为 User 作为 0..1 以显示 User 并不总是被通知。如果您将此视为消极路径，则不必这样做，因为这些被认为是 "failure paths"，因此并非 UC 的所有任务都必须发生。不过我会非常小心。由于您期望丢弃是定期发生的事情，因此它似乎是一条替代路径而不是消极路径。
替代方法
我的模型假设您主动通知 User（例如，向他发送推送、邮件或执行其他操作）。
虽然您只是创建了一个通知并且 User 必须主动阅读它，但这是可能的。在这种情况下，User 根本就不是 Ingest event 的 Actor。相反，作为 Ingest event 的结果，您创建了一个通知（在 UC 图上不可见）。此外，User 需要 Read notifications 的额外用例，其中他是主要（发起）Actor。
摘要（长话短说；博士）
您的场景中只有一个用例：Ingest event。
您的 Actor 是：External System（主要）和 User（具有多重性的次要 0..1）。
我正在为以下场景绘制 UML 用例图：
- 外部系统提供了一个事件 - 我想我这里的演员将是生成的事件
- 系统摄取事件
- 系统丰富活动
- 系统将丰富的事件与系统中存在的一些数据相关联
- 如果系统发现命中通知发送给人类演员
- 如果不是，事件被丢弃
所以我的 2 个参与者是：这个外部系统生成的事件和接收通知的用户。
- 事件调用用例摄取事件用例
- 外部用户使用接收通知用例
现在，我不确定如何为我的初始列表中的其他项目建模，因为它们应该被建模。
我应该有这样的东西吗：
- 事件（参与者）- 生成通知（用例）- 用户（参与者）
- 然后生成通知用例与其他用例之间的一些关系：摄取事件、丰富事件、关联事件？
我是否应该为丢弃事件建模？
谢谢！
- 对于您的演员：
Event不是演员。Event是一个事件。如果您没有特定名称，请将其命名为External system. Ingest event作为 UC 就可以了。- 我猜
Ingest event会带来丰富的内容。丢弃它也一样。两者都是用例中的活动。 - 关联并发送给用户将是 (UC---Actor)
Inform User---User. - 不通知用户将是
Inform User活动中的一条路径。
一般：
- 用例显示所考虑的系统为其参与者之一带来的附加值。
- 用例不是功能（它们隐藏在 UC 的活动中）。
- 如果 UC 不增加价值，则它不是用例。
让我们看看定义。
演员
我将使用第 18.1.3.1 节 UML Specification 中的定义
An Actor models a type of role played by an entity that interacts with the subjects of its associated UseCases (e.g., by exchanging signals and data). Actors may represent roles played by human users, external hardware, or other systems
它清楚地表明了接近 who/what 的列表可以成为演员。在您的情况下，它是一个与您的系统交互的 External System，因此它是您的 Actor。另一个Actor自然是User.
用例
在这里，我将使用 Alistair Cockburn 的 "Writing Effective Use Cases" 书中（第 1.1 节）中的定义来支持自己。
A use case captures a contract between the stakeholders of a system about its behavior. The use case describes the system’s behavior under various conditions as it responds to a request from one of the stakeholders, called the primary actor. The primary actor initiates an interaction with the system to accomplish some goal. The system responds, protecting the interests of all the stakeholders. Different sequences of behavior, or scenarios, can unfold, depending on the particular requests made and conditions surrounding the requests. The use case collects together those different scenarios.
在您的情况下，很明显，一旦 External System（主要 Actor）提供了一个事件，您的系统就会执行处理，直到 User（次要 Actor）是通知或事件被丢弃。为了实现这一目标，似乎不需要延迟或进一步的交互，所以它显然只是一个用例，Ingest event.
以通知 User 结束的处理将是您的主要路径，而事件被丢弃的路径将是替代路径甚至是否定路径（取决于您如何看待它）。
如果您将丢弃视为替代路径，您应该将关联的多重性建模为 User 作为 0..1 以显示 User 并不总是被通知。如果您将此视为消极路径，则不必这样做，因为这些被认为是 "failure paths"，因此并非 UC 的所有任务都必须发生。不过我会非常小心。由于您期望丢弃是定期发生的事情，因此它似乎是一条替代路径而不是消极路径。
替代方法
我的模型假设您主动通知 User（例如，向他发送推送、邮件或执行其他操作）。
虽然您只是创建了一个通知并且 User 必须主动阅读它，但这是可能的。在这种情况下，User 根本就不是 Ingest event 的 Actor。相反，作为 Ingest event 的结果，您创建了一个通知（在 UC 图上不可见）。此外，User 需要 Read notifications 的额外用例，其中他是主要（发起）Actor。
摘要（长话短说；博士）
您的场景中只有一个用例：Ingest event。
您的 Actor 是：External System（主要）和 User（具有多重性的次要 0..1）。