UML 用例图 Use Case Diagram

我们把用例图分解为四个不同的元素：系统Systems，参与者Actors，用例Use Cases和关系Relationships

1、系统

    系统就是我们正在开发的任何东西。它可以是一个网站，一个软件组件，业务流程，应用程序或任何其他的事情。

    矩形表示一个系统，并把系统的名称放在顶部。

我们构建一个简单的银行应用程序用例图。我们称为银行应用程序系统。此矩形有助于定义此系统的范围。

这个矩形内的任何东西都在银行应用程序内。这个矩形之外的任何东西都没有发生在银行应用程序中。

2、下一个元素是参与者，如图所示。参与者Actor将成为某人或者某事，来使我们的系统实现目标。那可能是一个人，一个组织，

另一个系统或者外部设备等。

        

那么谁或将要使用我们的银行业务程序呢？

最明显的参与者是顾客，我们将有顾客下载并使用我们的银行应用程序。

另一个参与者是银行，银行将提供相关信息，与交易一样，我们的银行应用程序提供交易，账户余额等

以下是我们除了参与者Actor时要注意的：

    首先，重要的是要注意这些参与者都是外部对象。它们总是要放在我们的系统外面

     其次，参与者要被视为类型或者类别。对于我们的银行应用程序，参与者不会去成为特定的个人或者特定组织。我们不会将我们的

参与者Actor标记为王超和招商银行。我们希望保持绝对的东西。所有现在我们说两个顾客和银行将使用我们的应用程序。这提出了主要次要的参与者。主要参与者启动系统的使用，而次要参与者更被动。所以在我们的例子中，那个参与者是主要的，那个是次要的？顾客是主要的    客户开始使用我们的系统，他们打算拿出手机打开我们的银行应用程序，并做一些事情。银行是次要的，银行只会在顾客做了些什么之后，才会采取行动。

    主要参与者应该在系统左边，次要参与者在系统的右边。

    

在这里我们只是视觉上强化了这一事实，客户参与银行应用程序，然后银行作出反应。

3、下一个元素是用例，这是我们真正开始描述我们的系统。

    我们使用椭圆描绘一个用例，它代表一个完成的动作，或者系统内的某种任务。

用例将被放置在矩形内，因为它们是在系统中发生的行为。

那么我们的银行应用程序会做些什么呢？简单来说，如果我们的银行应用程序可以进行 客户登录，查询余额，转账，支付等，那么这些将就是我们要描述的用例。

可以看到，我们的每个用例的描述都使用动词开始，我们使用动词加强了动作的发生。我们还希望它们具有足够的描述性。最后我们尽可能的按照逻辑顺序使用用例。这是我们将登陆置于顶端的原因。这是客户使用我们应用程序的第一件事。

4、用例图中的最后一个元素是关系。根据定义，参与者Actor正在使用我们的系统实现目标。所以每个参与者都必须至少与我们系统中的一个用例互动。

在我们的系统中，客户将要登录进入我们的应用程序。所以我们再参与者Actor与用例之间画一条实线，来表示这种关系。这种关系称为关联，它只是表示基本的沟通或互动。客户将与其他用例进行互动，也是如此。他们将查询余额，转账，支付，所以我们将用实线连接参与者与这些用例。

次要参与者Actor也要至少连接一个用例，请注意，每个参与者都必须与至少一个用例互动。

那么银行将与那些用例互动？当客户想要查询余额时，在应用程序上，银行将提供账户余额。我们再银行和查询余额直接画一条实线。同时，当客户进行转账或者支付时，银行正在跟进这些交易。我们不需要在登录时刻连线，是因为该过程发送在应用程序中，银行实际行没有必要参与登录过程。

还有其他三种关系，除了association 组合，还有Include包含、Extend扩展和Generalization泛化。

我们另外构建这个图表用例，以解释这些类型关系。

当客户输入他们的登录信息时，我们程序将在完成登录过程之前，验证密码是否正确，如果密码不正确，程序将显示错误消息。

因此我们创建两个新的用例验证，验证密码，和显示登录错误。

当客户在进行转账或支付时，银行会先验证余额是否充足；另外客户在支付和付款时，可以选择支票支付或者储蓄支付。我们创建两个用例支票支付，储蓄支付。

返回验证密码用例再次讨论关系。验证密码如何与其他用例发生关系？我们的参与者都没有直接发起，它只会在每次尝试登录时，发生在程序内部。这是一个包含关系。

包含关系显示基本用例和包含用例之间的依赖关系。 每次在执行基本用例时，包含用例也被执行。为了执行完一个基本用例，需要执行一个包含用例。

当基本用例有一个包含关系时，我们画一条带有箭头的虚线，到包含用例。

因此，在我们的示例中，登录用例是基本用例，它和验证密码用例是包含关系。每次客户登录是，应用程序将自动验证密码。除非登录用例不完整，或者验证密码已完成。

下一种关系是Extend扩展关系，扩展关系存在于基本用例和扩展用例之间。当执行基本用例时，扩展用例有时会发生，但不是每次都会发生。扩展用例只会在确定的符合标准的时间才会发生。

想到它的另一种方式是，你有扩展基础行为的选项用例。当有延伸关系时，我们画一条带有箭头的虚线，指向基本用例。

在我们的示例中，登录是一个基本用例，和显示登录错误是一种扩展关系。我们不会每次都显示错误信息，只会在用户输入错误密码时才显示。

这里我们解释了包含和扩展直接差异关系，以防万一，我们再举一个简单的例子，来区分两者之间的差异。

如果你打喷嚏，你会闭上眼睛。这是一个包含关系，因为它每次都会发生。另外，如果你打喷嚏，你可能会说劳驾，这是一个扩展关系，因为它补充了打喷嚏，但并非完全属于打喷嚏过程中必不可少的。

请记住每次都包含，延伸恰好发生在有时，而不是每次，箭头指向相反方向。

需要注意的一点是，多重基础用例 可以指向相同的包含或者扩展用例。例如：支付和转账将指向验证余额，我们希望系统每次在进行转账和支付时，进行此检查。每次这些基本用例执行时，都会执行检查余额用例。

最后一种关系是泛化，也叫继承。

当我们使用银行APP进行付款时，可以选择支票支付，或者储蓄支付。这种情况下，付款是基本用例，与支票支付用例，储蓄支付用例是父子关系，每个孩子都有共同的父行为，但每个孩子都有它自己的一些行为，更多的是它自己的。为了表名这种概况，我们从孩子哪里画出箭头，指向父母。

另外我们也允许对参与者Actor进行泛化。这些每种孩子参与者，都具有某些特有的行为或者品质。

最后，我们看一个带扩展点的用例，用例的名称在横线上方，下面有扩展点。扩展点只是一个详细的版本延伸关系。

UML 用例图

参考

【UML】— 用例图
用例图
初学UML——用例图
需求中如何画用例图

为什么使用用例图

• 从业务事件、发起事件以及系统如何响应这些事件来建模系统功能的过程。
• 用例建模起源于面向对象建模。

概念

• 图形化地描述了谁将使用该系统以及用户希望与系统交互的方式。
• 业务事件的文本描述以及用户如何与系统交互以完成任务。

参与者

• 参与者是与系统主体交互的外部实体的类元，描述了一个或一组与系统产生交互的外部用户或外部事物。
• 参与者位于系统边界之外，而不是系统的一部分。
• 可以是：人，组织，另一个信息系统，外部设备，甚至时间。

确定参与者

从以下角度确定参与者

• 为系统提供输入的人或事物
• 接收系统输出的人或事物
• 需要接入的第三方系统或设备
• 时间是否会触发某些事件
• 负责支持或维护系统中信息的人

参与者分类

• 主要业务参与者：主要从用例的执行中获得好处的关联人员。
• 主要系统参与者：直接同系统交互以触发业务或系统事件的关联人员。
• 外部服务参与者：响应来自用例的请求的关联人员。
• 外部接收参与者：从用例中接收某些价值或输出的非主要的关联人员。

参与者的泛化关系

• 当系统中的几个参与者既扮演自身的角色，同时也有更一般化的角色时，可以通过建立泛化关系来进行描述。
• 与类相似，父参与者可以是抽象的，即不能创建一个父参与者的直接实例，这就要求属于抽象父参与者的外部对象一定能够属于其子参与者之一。

用例

• 用例是类元提供的一个内聚的的功能单元，表明系统与一个或多个参与者之间信息交换的顺序，也表明了系统执行的动作。
• 简单来说，用例就是某一个参与者在系统中做某件事从开始到结束的一系列活动的集合，以及结束时应该返回的可观测、有意义的结果，其中也包含可能的各种分支情况。
• 用例与用例图被广泛使用于系统的需求建模阶段，并在系统的整个生命周期中被不断细化。

确定用例

用例的特征保证用例能够正确地捕捉功能性需求，同时也是判断用例是否准确的依据。

• 用例是动宾短语
• 用例是相对独立的
• 用例是由参与者启动的
• 用例要有可观测的执行结果
• 一个用例是一个单元

用例与参与者

• 一个用例可以隶属一个或多个参与者，一个参与者也可以参与一个或多个用例。
• 用例与参与者之间存在关联关系。
• 主参与者与次参与者：通常来说主参与者是用例的重要服务对象，而次参与者处于一种协作地位。

用例的粒度

• 在业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为宜。即一个用例可以描述一项完整的业务流程。例如取钱、报装电话、借书等表达完整业务的用例，而不要细节到验证密码、填写申请单、查找数目等业务中的一个步骤。
• 在用例分析阶段，即概念建模阶段，用例的粒度以每个用例能描述一个完整事件流为宜。可以理解为一个用例描述一项完整业务中的一个步骤。
• 在系统建模阶段，用例视角是针对计算机的，因此用例的粒度以一个用例能够描述操作者与计算机的一次完成交互为宜。例如，填写申请单、审核申请单、派发任务单等。可以理解为一个操作界面或一个页面流。

泛化关系

• 与参与者的泛化关系相似，用例的泛化关系将特化的用例与一般化的用例联系起来。子用例继承了父用例的属性、操作和行为序列，并且可以增加属于自己的附加属性和操作。
• 父用例同样可以定义为抽象用例。

依赖关系——包含

• 包含指的是一个用例（基用例）可以包含其他用例（包含用例）具有的行为，其中包含用例中定义的行为将被插入基用例定义的行为中。
• 包含的两个基本约束：
  
  • 基用例可以看到包含用例，并需要依赖于包含用例的执行结果，但是它对包含用例的内部结构没有了解；
  • 基用例一定会要求包含用例执行。

扩展

• 扩展指的是一个用例（扩展用例）对另一个用例（基用例）行为的增强。
• 在这一关系中，扩展用例包含了一个或多个片段，每个片段都可以插入到基用例中的一个单独的位置上，而基用例对于扩展的存在是毫不知情的。使用扩展用例我们就可以在不改变基用例的同时，根据需要自由地向用例中添加行为。

用例图示例

依赖关系对比

用例描述

• 一个完整的用例模型应该不仅仅包括用例图部分，还要有完整的用例描述部分。
• 一般的用例描述主要包括以下几部分内容：
  
  • 用例名称：描述用例的意图或实现的目标，一般为动词或动宾短语。
  • 用例编号：用例的唯一标识符，在其他位置可以使用该标识符来引用用例。
  • 参与者：描述用例的参与者，包括主要参与者和其他参与者。
  • 用例描述：对用例的一段简单的概括描述。
  • 触发器：触发用例执行的一个事件。
  • 前置条件：用例执行前系统状态的约束条件。
  • 基本事件流（典型过程）：用例的常规活动序列，包括参与者发起的动作与系统执行的响应活动。
  • 扩展事件流（替代过程）：记录如果典型过程出现异常或变化时的用例行为，即典型过程以外的其他活动步骤。
  • 结论：描述用例何时结束。
  • 后置条件：用例执行后系统状态的约束条件。
  • 补充约束：用例实现时需要考虑的业务规则、实现约束等信息。

用例描述示例

---

I.总述和预备知识

首先，用例图是用来描述系统功能的技术,表示一个系统中用例与参与者及其关系的图,主要用于需求分析阶段，同时它由参与者(actor)、用例(case)和容器(container) 三部分组成，并具有关联(Association)、泛化(Generalization)、包含(Include)和扩展(Extend) 四种关系。

【预备知识】：关于组成成分：参与者、用例和容器

✅参与者(actor)： 表示与应用软件或系统进行交互的用户、组织或外部系统，画图时用一个小人表示：

✅用例(case)： 表示外部可见的系统或软件的功能，对系统提供的服务进行描述，画图时用椭圆和文字表示：

✅容器(container)： 代表着一个系统，画图时用一个矩形表示，矩形内一般是一个一个的用例：

下面从用例图的四种关系进行逐一介绍。

---

II.关联(Association)关系

关联(Association)关系是用例图最常见的一种关系，简单理解就是参与者(actor)与每个用例(case)之间存在的一种相互交流、通信的关系，发生的对象是参与者和用例。这种关系与类图的关联关系很相似，可以近似理解。

画法上，关联关系无论是双向的还是单向的，一律用单向的实线箭头从参与者指向用例：

---

III.泛化(Generalization)关系

泛化(Generalization)关系是我们通常理解的继承关系：子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系；子用例可以使用父用例的一段行为，也可以重载它。此时，父用例通常是抽象的，而子用例表现出很强的具体性。(这里的子用例和父用例同样适用于参与者)

在用例图中，泛化关系存在于用例(case)之间或参与者(actor)之间，但通常不会出现在二者混合之间。画法上，泛化关系表示为实线、空心三角箭头，从“子”指向“父”：

---

IV.包含(Include)关系

包含(Include)关系是用来表示把一个较复杂用例所表示的功能分解成较小的步骤的一种关系。从定义不难看出，这种关系只会存在于用例(case)之间，并且通常是对一个复杂的用例进行拆解操作。

画法上，包含关系表示为两个部分：首先是一条虚线箭头，从较复杂的用例指向拆解出的功能用例；第二部分是在虚线上标注《include》，表示这是包含关系(与下一个扩展关系进行区分)：

---

V.扩展(Extend)关系

扩展(Extend)关系是用来表示用例功能的延伸的一种关系。这种关系同样是发生在用例(case)之间，相当于为基础用例提供一个附加功能用例。

画法上，扩展关系同样分两个部分：首先是一条虚线箭头，从延伸功能用例指向基础用例(直观感受与包含关系刚好相反)；第二部分是在虚线上标注《extend》，表示这是扩展关系：

---

VI.总结

对四种关系的画法进行一个总结：

关系	UML画法
关联关系	一条从参与者指向用例的实线
泛化关系	一条从 “子”指向“父” 的空心三角实线
包含关系	一条从较复杂用例指向拆解出的功能用例的虚线，并标有 《include》
扩展关系	一条从延伸功能用例指向基础用例的虚线，并标有 《extend》

最后放一个登录注册系统的UML用例图：