用例图 (Use Case Diagram) 是用来显示一组用例、参与者以及它们之间关系的图。它描述了用户希望如何使用一个系统。通过用例图可以知道谁是系统相关的用户，他们希望系统提供哪些服务，以及他们需要为系统提供什么样的服务。

用例图能给我们带来什么？

用来描述要开发的系统的功能需求和系统的使用场景。
促进开发过程中各个阶段工作的进展。
用来验证与确认系统需求。

用例建模是实现系统需求分析的一个很好的方法，通过它可以使得系统分析员和客户之间能够更好地沟通系统的需求。

用例图的组成

在介绍中我们说到用例图是显示一组用例、参与者之间关系的图。接下来的内容详细的阐述了什么是用例、什么是参与者以及他们之间有什么样的关系。

参与者 (Actor)

参与者也叫角色，它表示了系统的用户。这里需要注意的是：这里的用户并不特指人，如果我们开发的是公共 API 项目，那么这个时候，API 的调用者就是我们的用户。

参与者指的不是用户本身，而是它在系统中所扮演的角色。举个例子来说，张三是淘宝店的店主，这个时候他参与淘宝的交互时，他既可以是店主这个角色，也可以作为买家在淘宝上购买东西，这个时候张三在系统中扮演了两个角色，这两个角色是两个不同的参与者即买家和卖家。

参与者的作用是：

建立系统的外部用户模型
对系统边界之外的对象进行描述

我们先来看两个案例：

例：销售员每天下班前将当日销售情况通过邮件发送给销售经理，由销售经理将总的销售记录进行汇总录入到系统中。

这个时候和系统进行交互的人是销售经理，所以销售经理是系统的参与者。

参与者在我们代码中，本质上还是类，所以在参与者中也存在继承的关系（分析阶段一般用泛化关系来表示继承）。泛化关系 (Generalization) 表示一个一般性的参与者（父参与者）和另一个特殊参与者（子参与者）之间的联系。参与者之间的泛化关系用带空心箭头的实线来表示，箭头端表示父参与者。

在上面的图中，我们可以发现，管理员和普通用户都是用户的特殊化，所以可以抽象出一个父参与者来，管理员和普通用户都拥有用户的全部特性，同时还具有自己特殊的特性。

用例(Use Case)

需求分析是软件开发流程中必不可少的一个环节，其主要目的就是建立待开发系统的模型，而用例则是建立这些的最好方法。

用例是对一组动作的描述，系统通过执行这些动作将对用例的参与者产生可以看到的结果。用来描述参与者可以感受到的系统服务或者功能。

在 UML 中，用例通常用一个椭圆形符号来表示：

在电商系统中，“加入购物车”就是一个用例，在社交软件中，“发送消息给某人”就是一个用例。

使用用例进行系统需求分析的特点：

用例是从系统的使用者角度来描述系统中的信息，即在系统的外部所能看到的系统的功能，而不考虑系统内部对该功能的具体实现
用例描述了一下可见需求，对应一个具体的用户目标。使用用例可以用来划分系统与外部实体的界限。
用例通常由某个参与者来执行。
用例把执行结果返回给参与者。
用例在功能上具有完整性。它从参与者接受输入，再将产生的结果输出给参与者。

一般情况下，我们如果向其他人描述一个一个功能的具体信息呢？我们通过文字来对功能进行讲解。用例图只是简单的用图形方式描述系统，关于功能的完整解说还是需要用文字来表达。所以，对于用例，我们需要由详细的说明，这样才能让其他人更加清楚的了解这个系统。这个时候我们就需要编写用例描述了。

通常不会对用例描述做硬性规定，但是一些复杂的或者是重要的用例还是要编写用例描述。用例描述一般包括用例编号、用例说明、前置条件、基本事件流、其他事件流、异常事件流和后置条件等。

下面是“加入购物车”用例的详细描述：

元素	描述
用例名称	加入购物车
用例标识	UC001
简要说明	将商品添加到用户购物车中
前置条件	用户已经登录
基本事件流	用户向系统发送加入购物车的请求，系统需要对商品的库存、用户购物车数量进行验证来判断是否能够加入到购物车中
其它事件流	无
异常事件流	如果商品库存不足，则告知用户库存不足无法添加；如果用户购物车已达上限，则告知用户购物车已满，需要删除部分商品后才能添加
后置条件	添加成功后，需要对用户购物车数量重新进行统计
注释	无

说完用例，我们来说说用例之间的关系

用例之间的关系

包含关系

包含关系指的是两个用例之间，其中一个用例(基本用例)的行为包含了另外一个用例(包含用例)。

在 UML 图中，包含关系用带箭头的虚线表示，并且线上标有<<include>>，箭头的方向是从基本用例到包含用例。

扩展关系

扩展关系是对基本用例的扩展，基本用例是一个完整的用例，即使没有子用例参与，也可以完成一个完整的功能。扩展的基本用例中存在一个扩展点，只有扩展点被激活时，子用例才会被执行。扩展关系是从扩展用例到基本用例的关系，它说明扩展用例如何插入到基本用例中。

扩展用例的使用场景：

表明用例的某一部分是可选行为
表明只在特定条件下才执行的分支
表明可能有一组行为，其中的一个或多个行为可以在基本用例中的扩展点处插入。所插入的行为和顺序取决于在执行基本用例时与主角进行的交互。

在 UML 图中，使用带箭头的虚线表示，并且虚线上标有 <<extend>>:

泛化关系

泛化关系指的是一般(父用例)与特殊(子用例)的关系。当多个用例共同拥有一种类似的结构和行为时，可以将它们的共性抽象为父用例，其他的用例作为泛化关系中的子用例。

分组关系

在一些用例图中，用例数量可能很多，这个时候就需要把这些用例组织起来。

用例图建模及应用

创建用例图模型主要包含3部分内容：

识别系统中的角色和用例
区分用例之间的先后次序
创建用例图模型结构

识别系统中的角色和用例

这部分工作通常由系统分析员通过和客户沟通来完成。

要获取系统的用例，首先要找出系统的角色。

要获取系统角色可以在与客户沟通时，询问用户一些问题来识别角色。可以参考下列问题：

谁将使用系统的主要功能？
是需要系统的支持以完成日常工作？
谁负责维护、管理系统并保持系统正常运行？
系统需要与哪些外部系统交互？
系统需要处理哪些硬件设备？
谁对系统运行产生的结果比较感兴趣？

当我们获取到系统角色后，我们可以通过角色来列出它的用例。可以通过回答下列问题来识别用例：

每个角色执行的操作有什么？
什么角色将要创建、存储、改变、删除或者读取系统中的信息？
什么用例会创建、存储、改变、删除或读取这个信息？
角色需要通知外部系统的突然变化嘛？
系统需要通知角色正在发生的事情吗？
什么用例将支持和维护系统？

区分用例优先次序

某些用例必须在其他用例完成之前完成，因为它们是相互依赖的。例如在购买商品前，用户必须先登录。

构建用例图模型

将已经确定并细化的角色和用例放入用例图。再借助包含、扩展和泛化的关系给出用例之间的结构模型。

在系统需求分析中需要考虑系统用例图模型需要哪些视图、每个视图包含什么内容，以及视图中成员是否需构成包。

小结

用例建模是实现系统需求分析的一个很好的方法，使得系统分析员和用户之间能够更好地沟通系统的需求。