UML建模（三）用例图

1. 用例图的概述

1.1 概述

用例图（Use Case Diagram）也称为用户模型图，是由软件需求分析到最终实现的第一步，是从用户的角度来描述系统功能，描述如何使用一个系统。用例图显示谁将是相关用户、用户希望系统提供什么服务，以及用户需要为系统提供的服务。最长用来描述系统以及子系统。

1.2 定义用例图

用例图是有关系统细节的最高形式。事实上，用例图仅仅是站在外部观察系统功能，即参与者使用系统的角度描述系统中的信息，并不描述这些功能在系统内部是如何实现的。用例图包含多个元素，即系统、参与者和用例，并且用例图也表示这些元素之间存在的各种关系，包括泛化关系、关联关系和依赖关系。

图1 银行日常业务用例图

1.3 主要组件

用例图包含4个基本组件，即参与者（Actor）、用例（Use Case）、关系和系统。

1.3.1 参与者（Actor）

参与者是指与系统打交道的人或其他系统，就是使用该系统的人或事物。参与者通过向系统输入或请求系统输入某些事件来触发系统的执行，因此参与者可以是人，也可以是事物，还可以是时间、气压、温度等环境因素或其他系统等。它在系统之外，与系统直接交互。

参与者代表的是一个角色，而不是系统的单个用户。因此参与者的命名要有一个群体的概念，反映该参与者的身份和行为，例如老师、学生等。参与者与系统之间的通信是通过相互放和接收消息来实现的，。用例总是由某个参与者发送消息而启动的，这种参与者被称为主动参与者。永远不会初始启动用例，仅是参与系统中的一个或多个用例的参与者称为被动参与者。

1.3.2 用例（Use Case）

用例代表系统的某项完整的功能，是动作步骤的集合。UML中的用例的定义是系统执行的一组动作序列，这些动作可以对系统的参与者产生一定价值的可观察到的结果。系统的功能是通过参与者使用用例来实现的。

用例通过关联与参与者相连，这种关联也称为通信关系，表示该用例与哪些参与者进行通信。

1.3.3 关系

除了用例和参与者之间的关联关系外，还可以定义参与者之间的关系，用例之间有包含、扩展、和泛化3种关系。

泛化关系：是一种从子用例到父用例的关系，明确指出了子用例怎样才能实例化父用例的所有行为和特征。

图2 泛化关系

扩展关系：指一个用例的行为可能是由另一个用例进行扩展的。

图3 扩展关系

包含关系：指一个用例包括另一个用例中定义的行为。

图4 包含关系

1.3.4 系统

系统指一个软件系统、一项业务、一个商务活动、一台机器等。系统的功能通过用例来表现，即所有用例共同构成了整个系统。在实际建模时，可以先定义一些一般用例，以后再详细地处理它们。

2. 识别参与者

2.1 参与者的类型

参与者总是处于正在建模的系统的外部，不是系统的组成部分。参与者有3大类：系统用户、与本系统交互的其他系统、一些可以运行的进程。

名称	说明
人	即用户，是最常用的参与者。例如，各种客户。
其他的系统	在当前的项目范围外，建立与其他系统的接口。该类位于系统边界之外的系统，也是参与者。例如，第三方支付，需要用的第三方支付系统。
可以运行的进程	例如时间。例如贷款到期，系统会提醒银行工作人员致电客户。

2.2 捕获需求

收集需求的方式有访谈、问卷调查、实地观察、使用原型、特定群体调查、用户指导等。需求的来源主要是人、各种现有成品（例如报表、培训手册和视频记录等）、现有的软件系统或人工系统。通过各种形式记录下收集到的需求信息，经过整理，从中获取有价值的信息来建立系统模型。

2.3 识别参与者的方法

在获取用例前，首先要确定系统的参与者。识别方式：

（1）谁使用系统的主要功能

（2）谁改变系统的数据

（3）谁从系统获取信息

（4）谁需要系统的支持已完成日常工作任务

（5）谁负责维护、管理并保持系统正常运行

（6）系统需求要处理哪些硬件设备

（7）系统需要和哪些外部系统交互

（8）谁对系统运行产生的结果感兴趣

有着共同行为特征的多个参与者，可以抽象为更具一般化的参与者，用泛化关系来定义。

2.4 识别用例

识别用例的最好方法是从客户需求入手，分析系统的参与者，分析每个参与者是如何使用系统的。识别方式：

（1）特定参与者希望系统提供什么功能

（2）系统是否存储和检索信息，如果是，由哪个参与者触发

（3）当系统改变状态时，是否通知参与者

（4）是否存在影响系统的外部事件