这个例子说明了什么？
意思是：
a) Actor1 和 Actor2 可以使用 Use Case1
b) Actor1 和 Actor2 都需要启动 Use Case1（例如两个人需要转动钥匙来发射火箭？）
c) Actor1 可以启动用例 1，而 Actor2 稍后会做一些事情
d) Actor2 可以启动 Use Case1 并且 Actor1 稍后会做一些事情
我认为答案 B 是正确的吗？
A 会是：
C 将是：
D 将是：
【问题讨论】：
标签： uml diagram actor use-case
您的回答 A 即 Actor1 和 Actor2 可以使用 UseCase1 是正确的。
当然，您可以使用第二个图表对其进行建模，但在这种情况下，模型会有所不同。 Actor1 和 Actor2 也可以使用 UseCase1，但这是因为它们是 Actor3 的特化，这是唯一可以访问 useCase1 的 Actor 类型
【讨论】：
您的问题在概念上非常丰富且非常相关，因为它解决了用例图的一个关键概念，这是参与者的目的。首先，要了解用例的唯一目的是让给定的参与者（主要参与者）达到一个明确的目标（定义为产生一个可观察到的结果）。如果启用了多个参与者来执行此操作，那么这些参与者实际上是一个参与者，或者用例提供了多个功能，这是错误的（引自 here）：
用例描述一个离散的、独立的活动，参与者可以 执行以实现一些有价值的结果。一个用例可能包含一个 具有共同目标的相关活动的数量。
主要用户通过用例实现的目标可能会为一个或多个参与者带来价值，但请记住，只有一个参与者可以是主要参与者：如果您关联了多个参与者对于同一个用例，其中一个是主要的，其余的必然是次要的。引用well renowned expert A. Cockburn：
用例与一个特定参与者的目标相关联，该参与者 被称为该用例的主要参与者。用例描述了各种 可以在各种外部代理之间发生的一组交互，或 演员，而主要演员正在追求这个目标......用例 收集与该主要参与者的目标相关的所有场景， 既包括实现目标的那些，也包括实现目标的那些 必须放弃。
Cockburn 清楚地表明，存在一个用例来满足单个参与者的某些需求。额外的参与者以某种方式支持该系统，以使其满足主要参与者的需求。 To quote the excellent "UML @ Classroom"，由 Seidl、Scholz 等人撰写。 al, “如果一个用例与两个参与者相关联，这并不意味着一个或另一个参与者都参与了用例的执行：这意味着两者都是执行所必需的”。
An Oracle blog about Unified Method 的帖子中对用例的简短讨论还强调了主要参与者和次要参与者之间的区别：
主要参与者：使用系统实现目标的参与者。这 用例记录了系统和参与者之间的交互 实现主角的目标。
次要参与者：系统需要帮助以实现主要参与者目标的参与者。
...Oracle 统一方法 (OUM) 与 UML 定义一致 演员，连同考克伯恩的提炼，但 OUM 还包括以下内容：
次要参与者可能有也可能没有他们期望得到满足的目标 通过用例，主要参与者总是有一个目标，并且用例存在 以满足主要演员。
Martin Fowler 在他的经典作品UML Distilled 中支持同样的想法：
每个用例都有一个主要参与者，它调用系统 提供服务。主要参与者是有目标的参与者 用例试图满足并且通常但不总是 用例的发起者。可能还有其他演员 系统在执行用例时进行通信。这些 被称为次要演员。
因此，总而言之，每个用例都有一个 - 并且只有一个 - 主要参与者。现在，您在第一个图中有两个参与者，只有一个（主要参与者）有权使用系统来实现目标（另一个参与者协助系统实现主要参与者的目标）。此描述适合您列表中的备选方案 (c) 和 (d)，但请记住：主要用户启动用例并不是强制性的（它也可以由内部或临时事件启动）。
您正确解释了项目 (a) 必须如何描述，因为 Actor 1 和 Actor 2 都是 Actor 3 的特化，它与用例相关联，这使得声明“Actor1 和 Actor2 可以使用 Use Case1”是正确的.但是，我担心您错过了 (b) 项中的要点。事实上，项目 (b) 并没有像您想象的那样描绘第一个图表，因为您声明“需要 Actor1 和 Actor2 开始用例 1”。同样，用例是由内部（也称为“状态”）、时间或外部事件发起的（您可以阅读更多关于 here 的信息）；因此，由于给定用例只有一个主要参与者，因此它绝不需要启动两个参与者。如果您需要一个参与者做某事以允许另一个参与者启动一个用例，这将是该用例的先决条件。在这方面，请注意，您始终可以使用 multiplicity 的概念来指定执行用例需要两个或多个参与者实例 (here)：
如果为actor的关联端指定了大于1的多重性， 这意味着不止一个参与者实例参与了执行 的用例。
为清楚起见，请考虑以下推理。参与者是一个或多个用户在执行用例的上下文中扮演的角色。因此，如果 Mary 和 John 是系统的用户，他们有权启动一个名为 Sell an Item 的用例，那么此时两人都扮演着同样的角色，就像 单身演员，比如说，Seller。没关系，实际上，他们是销售员和销售经理：在用例图中，两者都充当“the”Seller（演员）。
在下图中，您可以看到三个用例图，我们可以在其中进一步扩展参数。
UC-1 展示了一个用例，其中需要两个不同的参与者，销售文员和销售经理来执行该用例出售物品;即，在 UC-1 的描述中，两者都需要运行它。例如，这可能表明文员进行的每笔销售都必须得到销售经理的批准。在这种情况下，Sales Clerk 是主要参与者，因为它启动用例并从中获得一些好处（执行销售），而 Sales Manager 是次要参与者（它参与执行）。
在 UC-2 中，经理 (Sales Manager) 和卖家 (Sales Clerk) 都可以销售商品（即，开始出售物品用例）。鉴于两者都扮演着与卖家相同的角色，这很可能被建模为所描绘的继承 - Sales Clerk "IS A" Seller 并且 Seller 也是如此em>销售经理。如上所述，两个参与者都充当“卖方”（Seller）。
UC-3 描绘了与 UC-1 中看到的完全相同的情况，但有细微差别：箭头清楚地表明谁是主要参与者和次要参与者（ 销售文员和销售经理）。据我所知，这些箭头不是标准化的（引用UML @ Classroom：“从图形上看，主要参与者和次要参与者之间、主动参与者和被动参与者之间没有区别......”）。
你能说两个参与者，Seller 和 Credit Card Company 都有权启动这个用例吗？当然不是，这显然是错误的，因为我们事先知道信用卡公司不在商店销售商品，而是通过他们的计算机系统支持销售。以同样的方式，声明 Sales Clerk 和 Sales Manager 都可能在上图UC-1。
看看here 的教科书。
【讨论】：
根据 UML 定义，Actor 是 UseCase 上下文的外部实体（例如建模系统、模块等）。根据定义，在用例执行期间，系统与 Actor 交互。 UseCase 和 Actor 之间的关联并不定义 Actor 对 usecase 的使用，而是定义 Actor 和系统之间的协作。
用例图中的关联导航性也没有定义通信。
A 会说，所有答案都是正确的，因为无法确定哪个参与者初始化了用例、它何时与系统交互或参与者做了什么。
您可以使用实现（实现）用例声明的功能的系统行为定义来提供更详细的描述。
【讨论】：