UML用例图2个actor与1个用例相关联

Question

这个例子显示了什么？

是不是意味着：

a）Actor1和Actor2可以使用Use Case1
b）需要使用Actor1和Actor2来启动Use Case1（例如，两个人需要转动钥匙才能发射火箭？）
c）Actor1可以启动Use Case1，Actor2可以执行某些操作 d）Actor2可以启动Use Case1，Actor1可以稍后执行

我是对的，答案B是正确的，并且：

A将是：

C将是：

D将是：

Answer 1

您的回答A即Actor1和Actor2可以使用UseCase1是正确的。

当然，您可以使用第二个图表对其进行建模，但在这种情况下，模型有点不同。 Actor1和Actor2也可以使用UseCase1，但这是因为它们是Actor3的特化，这是唯一一种可以访问usecase1的actor

Answer 2

通过UML定义，Actor是UseCase上下文的外部实体（例如建模系统，模块等）。根据定义，在用例执行期间，系统与Actor交互。 UseCase和Actor之间的关联不定义Actor对usecase的使用，而是定义Actor和系统之间的协作。

用例图中的关联导航性也没有定义通信。

可以说，所有答案都是正确的，因为当它与系统或演员的交互时，无法确定哪个演员初始化了用例。

您可以使用系统行为的定义提供更详细的描述，该系统实现（实现）由用户声明的功能。

Answer 3

您的问题在概念上很丰富，非常相关，因为它解决了用例图的关键概念，这是参与者的目的。现在，在综合中，您想知道当一个用例与多个参与者相关联时的含义。长话短说，请记住，只有一个演员可以成为主要演员。因此，如果您有多个与同一个用例相关联的参与者，则其中一个是主要的，其余的则必然是次要的。引用well renowned expert A. Cockburn：

  

用例与一个特定参与者的目标相关   在该用例中称为主要参与者。用例描述了各种   各种外部代理之间可能发生的一组交互，或者   演员，而主要演员正在追求这一目标...用例   收集与该主要参与者的目标有关的所有场景，   包括达到目标的目标和达到目标的目标   必须放弃。

正如Cockburn所说的那样，存在一个用例来满足单个演员的某些需求。额外的参与者正在以某种方式支持该系统，以使其满足主要参与者的需求。 To quote the excellent "UML @ Classroom"，由Seidl，Scholz等撰写。 al，“如果一个用例与两个参与者相关联，这并不意味着一个或另一个参与者都参与了该用例的执行：这意味着两者都对于执行它是必不可少的”。。

An Oracle blog about Unified Method的帖子中有关用例的简短讨论还强调了主要参与者和次要参与者之间的区别：

  

主要演员：使用系统来实现目标的演员。的   用例记录了系统和参与者之间的交互   实现主要演员的目标。

     

次要参与者：系统需要协助以实现主要参与者目标的参与者。

     

... Oracle统一方法（OUM）同意以下方面的UML定义：   演员以及Cockburn的完善之处，但OUM还包括以下内容：

     

次要演员可能有或没有他们期望实现的目标   根据用例，主要参与者总是有目标，并且用例存在   满足主要演员。

马丁·福勒（Martin Fowler）在他的经典著作UML Distilled中也支持相同的想法：

  

每个用例都有一个主要参与者，该参与者要求系统执行以下操作：   提供服务。主要演员是具有目标的演员   用例试图满足，通常但并非总是如此   用例的发起者。可能还有其他演员   系统在执行用例时进行通信。这些   被称为次要演员。

因此，总而言之，每个用例只有一个-只有一个-主角。现在，在第一个图中，您有两个参与者，只有一个（主要参与者）有权使用该系统来实现目标（另一个参与者协助系统实现主要参与者的目标）。此描述适合您列表中的替代方案（c）和（d），但请记住：主要用户启动用例不是强制性的（也可以由内部或临时事件启动）。

您正确地解释了必须如何描述（a）项，因为Actor 1和2都是Actor 3的专业化，Actor 3是与用例相关联的，这正确说明了“ Actor1和Actor2可以使用Use Case1” 。但是，恐怕您错过了（b）项的要点。的确，（b）项没有像您想象的那样描绘第一个图，因为您说“开始用例1需要Actor1和Actor2 ”。同样，用例是由内部（也称为“状态”），时间或外部事件发起的（您可以了解有关here的更多信息）；因此，由于给定用例只有一个主要参与者，因此绝不需要启动两个参与者。如果您需要一个参与者进行某些操作以允许另一个参与者启动一个用例，那么这将是该用例的前提。在这方面，请注意，您始终可以使用 multiplicity 的概念来指定执行用例（here）需要参与者的两个或更多实例：

  

如果为演员的关联结束指定了大于1的多重性，   这意味着执行中涉及多个参与者实例   用例。

为清楚起见，请考虑以下推理。参与者是在执行用例的上下文中由一个或多个用户扮演的角色。因此，如果Mary和John是系统的有权启动名为出售项目的用例的用户，那么他们在那一刻起的作用与 single 相同。演员命名为 Seller 。没关系，实际上，他们是销售员和销售经理：在用例图中，它们都充当“ 卖方”（角色）。

在下图中，您可以看到三个用例图，我们可以在其中进一步扩展参数。

UC-1 显示了一个用例，其中需要两个不同的参与者 Sales Clerk 和 Sales Manager 来执行该用例出售商品；即，在UC-1的说明中，都需要两者来运行它。例如，这可能表明，业务员进行的每笔销售都必须得到销售经理的批准。在这种情况下，销售文员是主要参与者，因为它启动了用例并从中获得了一些好处（进行销售），而销售经理是次要参与者（它参与执行）。

在 UC-2 中，经理（销售经理）和卖方（销售文员）都可以出售商品（即，开始出售商品用例）。鉴于两者都扮演着与卖方相同的角色，因此很可能将其建模为如下所示的继承-销售文员“ IS A” 卖方，而对于< em>销售经理。如上所述，两个参与者都充当“卖方”（卖方）。

UC-3 所描绘的情况与 UC-1 中的情况完全相同，只是略有不同：箭头清楚地表明谁是主要和次要参与者（ 销售文员和销售经理）。据我所知，这些箭头不是标准化的（引用UML @ Classroom：“ 在图形上，主要角色和次要角色之间，主动角色和被动角色之间没有区别... ”）

要最终确定参数，请考虑以下用例图：

您能说卖方和信用卡公司这两个参与者都有资格启动此用例吗？当然不是，这将是完全错误的，因为我们事先知道信用卡公司不会在商店中出售商品，而是通过其计算机系统来支持销售。以同样的方式声明销售文员和销售管理器可能会启动销售项目用例，这是一个错误。上面的 UC-1 图。

在here上看一本教科书。