前言
用例图（英语：use case diagram）是用户与系统交互的最简表示形式，展现了用户和与他相关的用例之间的关系。通过用例图，人们可以获知系统不同种类的用户和用例。用例图也经常和其他图表配合使用。(引用自百度百科)
同时，用例图是编写需求说明时经常用到的需求表达方式，用于向开发、测试同事说明需求中用户与系统功能单元之间的关系。但是很多刚接触用例的新人，在准备用例说明时并不清楚参与者与用例之间应该如何表达，网上教程五花八门，但感觉部分用例图不够规范，因此对用例图及用例说明梳理总结。
这是开发者与产品沟通的桥梁之一，是双方都需要掌握的技能。用例图常常被用于需求的表达和描述，是软件开发中比较靠前产生的设计图纸之一。
贡献榜
工具集
目录
用例图的组成
参与者/角色(Actor)
参与者也叫角色，它表示了系统的用户。系统的用户不是特指人，而是泛指使用者，使用者可以是功能模块、程序员、C/S架构的C端或者S端、某某系统等。
场景示例一：
公司发布一个需求，要求程序员A开发模块A功能，模块A有接口<增加数据>、<删除数据>、<修改数据>、<查询数据>。而程序员B开发模块B功能，B功能需要使用A功能模块的接口。那么用例图应该如下示例:
程序员B是当前用例图的参与者/使用者，用于表示用例图中的使用者会对那些功能进行调用或者交互。
A功能模块是当前用例图的一个边界，用于表示用例的归属权。
<增加数据>、<删除数据>、<修改数据>、<查询数据> 是功能接口，也可以理解为功能单元，常常是为使用者完成某一个行为的单一功能。
数据库 是功能单元集的数据提供者，在需求描述中我们没有对这个功能单元进行描述，但这里应该是需要这个用例单元存在。
用例(Use case)
用例是对一组动作或者行为的描述，常常代表这一个完整功能单元，系统通过执行这些动作将对用例的参与者产生可以看到的结果，可以让参与者明确的感受到系统服务或者功能。
如场景示例一中的示例用例图的用例单元，对于角色来说用例是一个完整的行为，用例能给角色明确的反馈。但在初期比较抽象的时候，用例也可以是比较大的功能单元，可以是系统或者子系统，完善的功能模块等。
用例之间的关系
关联关系(association)
关联关系是指两个用例间存在使用关系，即A用例使用B用例，或者B用例使用A用例。如程序员B会使用<增加数据>、<删除数据>、<修改数据>、<查询数据>用例，并且接口用例会反馈信息给程序员B。用例图如下:
定向关联关系(directed association)
定向关联关系是指两个用例间存在单方面的使用关系，即A用例使用B用例，但B用例不会关联A用例。类似于托管的关系，我要做什么事情，告诉某某，某某自己抽个空做了就行了。
包含关系(include)
包含关系是指两个用例之间的依赖关系，如A用例的实现必须使用到B用例，那么在用例图中，应该由A用例出发连线到B用例，连线是单向单箭头的虚线，这个虚线带<<include>>字样。
扩展关系(extend)
扩展关系是对基本用例的扩展，基本用例是一个完整的用例，即使没有子用例参与，也可以完成一个完整的功能。如购买商品用例作为基本用例，它拥有打折、赠品等扩展用例，只有扩展点被激活时，子用例才会被执行。扩展关系是打折、赠品属性的扩展用例到购买商品基本用例的关系，由基本用例购买商品出发连线到打折、赠品扩展用例，连线是单向单箭头的虚线，这个虚线带<<extend>>字样。
购买商品用例是可以单独完成功能或者行为的，但同时也能由打折、赠品扩展用例结合。
泛化关系(generalization)
泛化关系跟编程中的继承关系是一致的，即子用例获得父用例的全部功能和特征，并且在父用例的基础上进行扩展实例化。如使用者需要一个万能的图片解析接口(父用例，即图片解析用例)，那么我们泛化父用例的特征并实例化PNG用例、JPG用例、BMP用例等。即由图片解析用例为终点连线PNG用例、JPG用例、BMP用例，连线是单向单箭头(空心)的实线。
使用者可以使用PNG用例、JPG用例、BMP用例、但在图中表示为使用者对图片解析用例关联。你可以理解为图片解析用例可以具体化为PNG用例、JPG用例、BMP用例中的任何一个。
依赖关系(dependency)
依赖关系是指源用例依赖于目标用例，但依赖关系不属于UML的标准关系，建议减少使用或者不使用。如电冰箱用例依赖插头用例，由电冰箱用例出发连线插头用例，连线是单向单箭头的虚线。用例图表示为:
用例描述模板
一般情况下，我们如果向其他人描述一个一个功能的具体信息呢？我们通过文字来对功能进行讲解。用例图只是简单的用图形方式描述系统，关于功能的完整解说还是需要用文字来表达。所以，对于用例，我们需要由详细的说明，这样才能让其他人更加清楚的了解这个系统。这个时候我们就需要编写用例描述了。
通常不会对用例描述做硬性规定，但是一些复杂的或者是重要的用例还是要编写用例描述。用例描述一般包括用例编号、用例说明、前置条件、基本事件流、其他事件流、异常事件流和后置条件等。
| 元素 | 描述 | 备注 |
|---|---|---|
| 用例编号 | 为用例制定一个唯一的编号，通常格式为UCxx | |
| 用例名称 | 让读者一目了然地知道用例的目标，应为个动词短语 | |
| 用例概述 | 指用例的目标，对用例概要性的描述 | |
| 范国 | 用例的设计范围 | |
| 主参与者 | 该用例的主要参与者，在此列出名称，并对其进行简要的描述 | |
| 次要参与者 | 该用例的次要参与者，在此列出名称，并对其进行简要的描述 | |
| 前置条件 | 指的是启动该用例应该满足的条件 | |
| 后置条件 | 指的是该用例完成之后，将执行什么动作 | |
| 成功保证 | 描述当前目标完成后，环境会发生什么变化 | |
| 基本事件流 | 步骤1 步骤2 |
主要是说明为了实现用例中描述的功能，参与者和软件系统之间的交互过程，即参与者执行过程或步骤，系统做出响应，一般是一组有编号的步骤。如表中的步骤 1、2 等。 |
| 扩展事件流 | 1a 1b 2a |
la 表示是对 1的扩展，其中应说明条件和活动。 扩展事件流说明除基本事件流之外的其他成功流、失败流等的描述。 |
| 子事件流 | 对多次重复的事件流可以定义为子事件流，这也是抽取被包含用例的地方 | |
| 规则与约束 | 对该用例实现时需要考虑的业务规则、非功能需求、设计约束等 | |
| 后置条件 | 对该用例操作后，需要做出什么操作或者变化 |
用例图示例
场景示例一：
公司发布一个需求，要求程序员A开发模块A功能，模块A有接口<增加数据>、<删除数据>、<修改数据>、<查询数据>。而程序员B开发模块B功能，B功能需要使用A功能模块的接口。那么用例图应该如下示例:
增加数据 的详细描述
| 元素 | 描述 |
|---|---|
| 用例名称 | 增加数据 |
| 用例标识 | uc001 |
| 简要说明 | 示例说明用例，指增加数据的功能 |
| 前置条件 | A程序员已完成接口定义 |
| 基本事件流 | 使用者向系统发送增加数据的请求，系统会对数据库进行验证是否可以写入请求数据 |
| 其他事件流 | 无 |
| 异常事件流 | 如果数据已存在，则告知使用者不能写入请求数据，需要使用uc003用例修改数据库数据 |
| 后置条件 | 增加成功后，需要告知使用者增加成功 |
| 注释 | 无 |
删除数据 的详细描述
| 元素 | 描述 |
|---|---|
| 用例名称 | 删除数据 |
| 用例标识 | uc002 |
| 简要说明 | 示例说明用例，指删除数据的功能 |
| 前置条件 | A程序员已完成接口定义 |
| 基本事件流 | 使用者向系统发送删除数据的请求，系统会对数据库进行验证是否可以删除请求数据 |
| 其他事件流 | 无 |
| 异常事件流 | 如果数据不存在，则告知使用者不能删除请求数据 |
| 后置条件 | 删除成功后，需要告知使用者删除成功 |
| 注释 | 无 |
修改数据 的详细描述
| 元素 | 描述 |
|---|---|
| 用例名称 | 修改数据 |
| 用例标识 | uc003 |
| 简要说明 | 示例说明用例，指修改数据的功能 |
| 前置条件 | A程序员已完成接口定义 |
| 基本事件流 | 使用者向系统发送修改数据的请求，系统会对数据库进行验证是否可以修改请求数据 |
| 其他事件流 | 无 |
| 异常事件流 | 如果数据不存在，则告知使用者不能修改请求数据 |
| 后置条件 | 修改成功后，需要告知使用者修改成功 |
| 注释 | 无 |
查询数据 的详细描述
| 元素 | 描述 |
|---|---|
| 用例名称 | 查询数据 |
| 用例标识 | uc004 |
| 简要说明 | 示例说明用例，指查询数据的功能 |
| 前置条件 | A程序员已完成接口定义 |
| 基本事件流 | 使用者向系统发送查询数据的请求，系统会对数据库进行验证是否存在目标请求数据 |
| 其他事件流 | 无 |
| 异常事件流 | 如果数据不存在，则告知使用者数据库不存在请求数据 |
| 后置条件 | 查询成功后，需要告知使用者查询数据的详细数据项 |
| 注释 | 无 |
用例图如下
总结
遵守UML标准设计出来的图纸，能让我们更好的与项目中的个部分进行友好的沟通，同时也能让我们的工作变得更加有序，把控能力也能做更好。
！！！不管用例图与表格画得多么酷炫，最终目的也是为了团队同事可以用最短的时间及精力完成对需求的理解！！！
！！！注意，以下内容是借鉴sizeofio前辈的经验！！！
用例图建模及应用
创建用例图模型主要包含3部分内容：
识别系统中的角色和用例
识别系统中的角色和用例通常由系统分析员通过和客户沟通来完成。
要获取系统的用例，首先要找出系统的角色。在与客户沟通时，询问用户一些问题来识别角色。可以参考下列问题：
当我们获取到系统角色后，我们可以通过角色来列出它的用例。可以通过回答下列问题来识别用例：
区分用例优先次序
某些用例必须在其他用例完成之前完成，因为它们是相互依赖的。例如在购买商品前，用户必须先登录。
构建用例图模型
将已经确定并细化的角色和用例放入用例图。再借助包含、扩展和泛化的关系给出用例之间的结构模型。
在系统需求分析中需要考虑系统用例图模型需要哪些视图、每个视图包含什么内容，以及视图中成员是否需构成包。
浙公网安备 33010602011771号