用例图主要用来描述“用户、需求、系统功能单元”之间的关系，在需求分析阶段，常会借助用例图，从用户的角度描述系统的功能，以图形可视化的方式作为开发团队与客户的交流，同时也有助于形成统一语言。

一、用例图描述

用例图（Use Case Diagrame）：描述了人们希望如何使用一个系统，将相关用户、用户需要系统提供的服务以及系统需要用户提供的服务更清晰的显示出来，以便使系统用户更容易理解这些元素的用途，也便于开发人员最终实现这些元素。之所以说用例图至关重要，是由于用户并不关心系统的实现和内部结构，只关心产品所呈现出来的外部特征动态。而用例图恰好就是描述软件产品外部特性的视图，它从用户的角度而不是从开发者的角度来描述需求，分析产品的功能和动态行为。

二、基本元素

1、 参与者(Actor) ，在 系统外部 与系统直接交互的角色或外部系统。可通过与客户的沟通交流，确定利益相关人，进而确定参与者。

• 角色： 通常是具体人承担着角色，这是最常见的参与者。
• 外部系统： 如CRM系统要操作OA系统，以方便发送通知，那么针对OA系统的调用，CRM系统作为外部系统这一参与者。
• 时间： 如存在定时任务操作或者类似操作等，则时间作为参与者

2、 用例

客户通过对需求的描述(主要为功能需求)，开发团队通过用例来体现系统功能和服务，通过参与者与用例的交互，来达到客户与开发团队的目标一致。

3、 关联关系

1）参与者与参与者间的泛化关系

比如腾讯用户，包括微信用户和QQ用户两部分，但是使用腾讯业务时，只需要是腾讯用户即可，此时，可以采用泛化关系，采用三角空心箭头作为指向。

2）参与者与用例间的关联关系

参与者与用例间是简单的关联关系，一个参与者可以有着多个用例

3）用例与用例间的泛化关系

用例之间可以存在泛化关系，比如常见的支付，可以选择微信支付、支付宝支付等等，但是这个操作就是支付。泛化关系采用三角空心箭头。

4）用例与用例间的包含关系

包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。通常可以这么理解，由基础用例向复杂用例转换的过程。但是最终被参与者直接操作的还是基础用例。包含关系的图形为虚线箭头加<<include>>，箭头指向复杂用例。

5）用例与用例间的扩展关系

扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能。当 特定条件出现 时，该扩展用例的行为才会被执行。扩展关系的图形为虚线箭头加上<<<exclude>>>，箭头指向基础用例。

三、简单案例

依照常见的购买操作，设计简单的用例操作，当然，实际中的用例远不止这么简单，本次只是将以上几种关系融入进来，设计简单的案例。

至此，针对UML用例图的相关内容做了大概的总结，需求分析阶段，利用用例图，来方便与客户形成统一语言，也方便活动图的设计。