用例图 (Use Case Diagram) 是用来显示一组用例、参与者以及它们之间关系的图。它描述了用户希望如何使用一个系统。通过用例图可以知道谁是系统相关的用户，他们希望系统提供哪些服务，以及他们需要为系统提供什么样的服务。
用例图能给我们带来什么？
- 用来描述要开发的系统的功能需求和系统的使用场景。
- 促进开发过程中各个阶段工作的进展。
- 用来验证与确认系统需求。
用例建模是实现系统需求分析的一个很好的方法，通过它可以使得系统分析员和客户之间能够更好地沟通系统的需求。
用例图的组成
在介绍中我们说到用例图是显示一组用例、参与者之间关系的图。接下来的内容详细的阐述了什么是用例、什么是参与者以及他们之间有什么样的关系。
参与者 (Actor)
参与者也叫角色，它表示了系统的用户。这里需要注意的是：这里的用户并不特指人，如果我们开发的是公共 API 项目，那么这个时候，API 的调用者就是我们的用户。
参与者指的不是用户本身，而是它在系统中所扮演的角色。举个例子来说，张三是淘宝店的店主，这个时候他参与淘宝的交互时，他既可以是店主这个角色，也可以作为买家在淘宝上购买东西，这个时候张三在系统中扮演了两个角色，这两个角色是两个不同的参与者即买家和卖家。
参与者的作用是：
- 建立系统的外部用户模型
- 对系统边界之外的对象进行描述
我们先来看两个案例：
例：销售员每天下班前将当日销售情况通过邮件发送给销售经理，由销售经理将总的销售记录进行汇总录入到系统中。
这个时候和系统进行交互的人是销售经理，所以销售经理是系统的参与者。
参与者在我们代码中，本质上还是类，所以在参与者中也存在继承的关系（分析阶段一般用泛化关系来表示继承）。泛化关系 (Generalization) 表示一个一般性的参与者（父参与者）和另一个特殊参与者（子参与者）之间的联系。参与者之间的泛化关系用带空心箭头的实线来表示，箭头端表示父参与者。
在上面的图中，我们可以发现，管理员和普通用户都是用户的特殊化，所以可以抽象出一个父参与者来，管理员和普通用户都拥有用户的全部特性，同时还具有自己特殊的特性。
用例(Use Case)
需求分析是软件开发流程中必不可少的一个环节，其主要目的就是建立待开发系统的模型，而用例则是建立这些的最好方法。
用例是对一组动作的描述，系统通过执行这些动作将对用例的参与者产生可以看到的结果。用来描述参与者可以感受到的系统服务或者功能。
在 UML 中，用例通常用一个椭圆形符号来表示：
在电商系统中，“加入购物车”就是一个用例，在社交软件中，“发送消息给某人”就是一个用例。
使用用例进行系统需求分析的特点：
- 用例是从系统的使用者角度来描述系统中的信息，即在系统的外部所能看到的系统的功能，而不考虑系统内部对该功能的具体实现
- 用例描述了一下可见需求，对应一个具体的用户目标。使用用例可以用来划分系统与外部实体的界限。
- 用例通常由某个参与者来执行。
- 用例把执行结果返回给参与者。
- 用例在功能上具有完整性。它从参与者接受输入，再将产生的结果输出给参与者。
一般情况下，我们如果向其他人描述一个一个功能的具体信息呢？我们通过文字来对功能进行讲解。用例图只是简单的用图形方式描述系统，关于功能的完整解说还是需要用文字来表达。所以，对于用例，我们需要由详细的说明，这样才能让其他人更加清楚的了解这个系统。这个时候我们就需要编写用例描述了。
通常不会对用例描述做硬性规定，但是一些复杂的或者是重要的用例还是要编写用例描述。用例描述一般包括用例编号、用例说明、前置条件、基本事件流、其他事件流、异常事件流和后置条件等。
下面是“加入购物车”用例的详细描述：
| 元素 | 描述 |
|---|---|
| 用例名称 | 加入购物车 |
| 用例标识 | UC001 |
| 简要说明 | 将商品添加到用户购物车中 |
| 前置条件 | 用户已经登录 |
| 基本事件流 | 用户向系统发送加入购物车的请求，系统需要对商品的库存、用户购物车数量进行验证来判断是否能够加入到购物车中 |
| 其它事件流 | 无 |
| 异常事件流 | 如果商品库存不足，则告知用户库存不足无法添加；如果用户购物车已达上限，则告知用户购物车已满，需要删除部分商品后才能添加 |
| 后置条件 | 添加成功后，需要对用户购物车数量重新进行统计 |
| 注释 | 无 |
说完用例，我们来说说用例之间的关系
用例之间的关系
包含关系
包含关系指的是两个用例之间，其中一个用例(基本用例)的行为包含了另外一个用例(包含用例)。
在 UML 图中，包含关系用带箭头的虚线表示，并且线上标有<<include>>，箭头的方向是从基本用例到包含用例。
扩展关系
扩展关系是对基本用例的扩展，基本用例是一个完整的用例，即使没有子用例参与，也可以完成一个完整的功能。扩展的基本用例中存在一个扩展点，只有扩展点被激活时，子用例才会被执行。扩展关系是从扩展用例到基本用例的关系，它说明扩展用例如何插入到基本用例中。
扩展用例的使用场景：
- 表明用例的某一部分是可选行为
- 表明只在特定条件下才执行的分支
- 表明可能有一组行为，其中的一个或多个行为可以在基本用例中的扩展点处插入。所插入的行为和顺序取决于在执行基本用例时与主角进行的交互。
在 UML 图中，使用带箭头的虚线表示，并且虚线上标有 <<extend>>:
泛化关系
泛化关系指的是一般(父用例)与特殊(子用例)的关系。当多个用例共同拥有一种类似的结构和行为时，可以将它们的共性抽象为父用例，其他的用例作为泛化关系中的子用例。
分组关系
在一些用例图中，用例数量可能很多，这个时候就需要把这些用例组织起来。
用例图建模及应用
创建用例图模型主要包含3部分内容：
- 识别系统中的角色和用例
- 区分用例之间的先后次序
- 创建用例图模型结构
识别系统中的角色和用例
这部分工作通常由系统分析员通过和客户沟通来完成。
要获取系统的用例，首先要找出系统的角色。
要获取系统角色可以在与客户沟通时，询问用户一些问题来识别角色。可以参考下列问题：
- 谁将使用系统的主要功能？
- 是需要系统的支持以完成日常工作？
- 谁负责维护、管理系统并保持系统正常运行？
- 系统需要与哪些外部系统交互？
- 系统需要处理哪些硬件设备？
- 谁对系统运行产生的结果比较感兴趣？
当我们获取到系统角色后，我们可以通过角色来列出它的用例。可以通过回答下列问题来识别用例：
- 每个角色执行的操作有什么？
- 什么角色将要创建、存储、改变、删除或者读取系统中的信息？
- 什么用例会创建、存储、改变、删除或读取这个信息？
- 角色需要通知外部系统的突然变化嘛？
- 系统需要通知角色正在发生的事情吗？
- 什么用例将支持和维护系统？
区分用例优先次序
某些用例必须在其他用例完成之前完成，因为它们是相互依赖的。例如在购买商品前，用户必须先登录。
构建用例图模型
将已经确定并细化的角色和用例放入用例图。再借助包含、扩展和泛化的关系给出用例之间的结构模型。
在系统需求分析中需要考虑系统用例图模型需要哪些视图、每个视图包含什么内容，以及视图中成员是否需构成包。
小结
用例建模是实现系统需求分析的一个很好的方法，使得系统分析员和用户之间能够更好地沟通系统的需求。
