UML 用例图详解

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

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

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

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

用例图的组成

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

参与者 (Actor)

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

参与者指的不是用户自己，而是它在系统中所扮演的角色。举个例子来讲，张三是淘宝店的店主，这个时候他参与淘宝的交互时，他既能够是店主这个角色，也能够做为买家在淘宝上购买东西，这个时候张三在系统中扮演了两个角色，这两个角色是两个不一样的参与者即买家和卖家。

参与者的做用是：

• 创建系统的外部用户模型
• 对系统边界以外的对象进行描述

咱们先来看两个案例：

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

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

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

在上面的图中，咱们能够发现，管理员和普通用户都是用户的特殊化，因此能够抽象出一个父参与者来，管理员和普通用户都拥有用户的所有特性，同时还具备本身特殊的特性。

用例(Use Case)

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

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

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

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

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

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

通常状况下，咱们若是向其余人描述一个一个功能的具体信息呢？咱们经过文字来对功能进行讲解。用例图只是简单的用图形方式描述系统，关于功能的完整解说仍是须要用文字来表达。因此，对于用例，咱们须要由详细的说明，这样才能让其余人更加清楚的了解这个系统。这个时候咱们就须要编写用例描述了。

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

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

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

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

用例之间的关系

包含关系

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

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

扩展关系

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

扩展用例的使用场景：

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

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

泛化关系

泛化关系指的是通常(父用例)与特殊(子用例)的关系。当多个用例共同拥有一种相似的结构和行为时，能够将它们的共性抽象为父用例，其余的用例做为泛化关系中的子用例。

分组关系

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

用例图建模及应用

建立用例图模型主要包含3部份内容：

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

识别系统中的角色和用例

这部分工做一般由系统分析员经过和客户沟通来完成。

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

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

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

当咱们获取到系统角色后，咱们能够经过角色来列出它的用例。能够经过回答下列问题来识别用例：

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

区分用例优先次序

某些用例必须在其余用例完成以前完成，由于它们是相互依赖的。例如在购买商品前，用户必须先登陆。

构建用例图模型

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

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

小结

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