UML 用例图 2 个参与者与 1 个用例连接

use*_*261 4 diagram uml use-case actor

这个例子说明了什么?

图表

是不是意味着:

a) Actor1 和 Actor2 可以使用 Use Case1
b) Actor1 和 Actor2 都需要启动 Use Case1(例如需要两个人转动钥匙来发射火箭?)
c) Actor1 可以启动 Use Case1,Actor2 稍后执行某些操作
d) Actor2可以启动 Use Case1,Actor1 稍后执行某些操作

我对吗,答案 B 是正确的,并且:

A 是:

图表

C 是:

图表

D 是:

图表

Hum*_*rro 5

您的问题在概念上丰富且非常相关,因为它解决了用例图的关键概念,即参与者的目的。首先,请了解用例的唯一目的是允许给定参与者(主要参与者)达到明确确定的目标(定义为产生可观察结果的一组操作)。如果启用多个参与者来执行此操作,则这些参与者实际上是单个参与者,或者用例提供了多个功能,这是错误的(引自此处):

\n\n
\n

用例描述了参与者可以执行的离散、独立的活动,以实现某些有价值的结果。一个用例可能包含许多具有共同目标的相关活动。

\n
\n\n

主要用户通过用例实现的目标可能会为一个或多个参与者提供价值,但请记住,只有一个参与者可以是主要参与者:如果您有多个参与者与同一用例关联,那么其中一个是主要的,其余的必然是次要的。引用著名专家 A. Cockburn 的话:

\n\n
\n

该用例与一个特定参与者的目标相关联,该参与者被称为该用例的主要参与者。用例描述了各种外部代理或参与者之间可能发生的各种交互集,而主要参与者正在追求该目标...用例将与以下内容相关的所有场景收集在一起该主要参与者的目标,\n 包括实现目标的目标和必须放弃目标的目标。

\n
\n\n

正如 Cockburn 所说,存在一个用例可以满足单个参与者的某些需求。额外的参与者以某种方式支持系统,使其满足主要参与者的需求。引用Seidl、Scholz 等人写的优秀的“UML @ Classroom”。al,“如果一个用例与两个参与者相关联,这并不意味着一个或另一个参与者参与了该用例的执行:这意味着两者对于其执行都是必要的”

\n\n

Oracle 博客中有关统一方法的文章中对用例的简要讨论也强调了主要参与者和次要参与者之间的区别:

\n\n
\n

主要参与者:使用系统实现目标的参与者。用例记录了系统和参与者之间的交互,以实现主要参与者的目标。

\n\n

次要参与者:系统需要协助以实现主要参与者\xe2\x80\x99s 目标的参与者。

\n\n

...Oracle 统一方法 (OUM) 与\n Actor 的 UML 定义以及 Cockburn\xe2\x80\x99s 细化一致,但 OUM 还包括以下内容:

\n\n

次要参与者可能有也可能没有他们期望用例满足的目标,主要参与者总是有一个目标,并且用例的存在是为了满足主要参与者的需求。

\n
\n\n

Martin Fowler 在他的经典UML Distilled中也支持同样的想法:

\n\n
\n

每个用例都有一个主要参与者,它调用系统来提供服务。主要参与者是具有用例试图满足的目标的参与者,通常但并非总是用例的发起者。系统在执行用例时可能还与其他参与者进行通信。这些被称为次要参与者。

\n
\n\n

因此,总而言之,每个用例都有一个且只有一个主要参与者。现在,您的第一个图中有两个参与者,只有一个(主要参与者)有权使用系统来实现目标(另一个参与者协助系统实现主要参与者\xe2\x80\x99s 目标) 。此描述适合您列表中的替代方案 (c) 和 (d),但请记住:主用户启动用例并不是强制性的(它也可以由内部或临时事件启动)。

\n\n

您正确地解释了项目 (a) 必须如何描述,因为 Actor 1 和 2 都是 Actor 3 的特化,Actor 3 与用例相关联,这使得“Actor1 和 Actor2 可以使用用例 1”的说法是正确的。但恐怕您错过了(b)项中的要点。事实上,项目 (b) 并未像您想象的那样描绘第一个图,因为您声明“需要 Actor1 和 Actor2 来启动Use Case1”。同样,用例是由内部(也称为“状态”)、时间或外部事件启动的(您可以在此处阅读更多相关信息);因此,由于给定用例只有一个主要参与者,因此它绝不需要启动两个参与者。如果您需要一个参与者做某事以便允许另一个参与者启动一个用例,那么这将是该用例的先决条件。在这方面,请注意,您始终可以使用多重性的概念来指定执行用例需要两个或多个参与者实例(此处):

\n\n
\n

如果为 actor\xe2\x80\x99s 关联端指定了大于 1 的重数,则这意味着用例的执行涉及到一个以上的 actor 实例。

\n
\n\n

为了清楚起见,请考虑以下推理。参与者是一个或多个用户在执行用例的上下文中扮演的角色。因此,如果 Mary 和 John 是系统用户,有权启动一个名为(例如,Sell an Item)的用例,那么两人此时都扮演着相同的角色,作为一个名为(例如,Seller )的单个参与者。没关系,实际上,他们是销售员和销售经理:在用例图中,两者都充当“卖方” 参与者)。

\n\n

在下图中,您可以看到三个用例图,我们可以在其中进一步扩展论证。

\n\n

三种不同的用例配置

\n\n

UC-1显示了一个用例,其中需要两个不同的参与者(销售文员销售经理)来执行用例“销售商品”;也就是说,在 UC-1 的描述中,两者都需要运行。例如,这可能表明店员执行的每笔销售都必须得到销售经理的批准。在这种情况下,销售文员是主要参与者,因为它启动用例并从中获得一些好处(执行销售),而销售经理是次要参与者(它参与执行)。

\n\n

UC-2中,经理(销售经理)和卖方(销售职员)都可以销售商品(即启动销售商品用例)。鉴于两者都扮演与卖家相同的角色,这很可能被建模为如图所示的继承 - Sales Clerk "IS A" Seller ,而Sales Manager也是如此。正如上面所指出的,两位演员都扮演“卖家”(Seller)。

\n\n

UC-3描述了与UC-1中完全相同的情况,但有细微差别:箭头清楚地表明谁是主要参与者和次要参与者(分别是销售职员销售经理)。据我所知,这些箭头不是标准化的(引用UML @ Classroom:“从图形上看,主要和次要参与者之间、主动和被动参与者之间没有区别...... ”)。

\n\n

要最终确定论点,请考虑以下用例图:\n两个参与者参与用例执行。 只有一个人启动它

\n\n

您是否可以说,卖家信用卡公司这两个参与者都有权启动此用例?当然不是,这显然是错误的,因为我们事先知道信用卡公司不在商店销售商品,而是通过其计算机化系统支持销售。同样,如果说销售文员销售经理都可能启动上面UC-1图中的销售项目用例,也是错误的。

\n\n

看看这里的教科书。

\n