4-用例图

4-用例图

2.1 视与图

2.1.1 视(重要)

概念

从多个方面来描述一个复杂的系统，不同的视描述系统的不同方面。

4+1视(重要)

软件系统结构可用5个视来描述：用例视、设计视、过程视、实现视和配置视，UML的各种图为系统的不同的视建模提供工具。

各个视之间的关系

5个视彼此相关、交互作用，运用它们可对软件系统进行全方位的描述。

各个视与对应的UML(重要)

4+1视	对应UML图
用例视	用例图
设计视	类图
实现视	类图,顺序图,活动图,组件图
过程视	无完全对应
配置视	部署图

用例视

通过用例描述了可以为最终用户、分析人员和测试人员所看到的系统行为。视的静态方面由用例图描述，动态方面由交互作用图、状态图、活动图描述。

设计视

包括问题域词汇表和解决方案的类、接口和协作，支持系统功能需求，即系统提供给最终用户的服务。视的静态方面由类图和对象图描述，动态方面由交互作用图、状态图、活动图描述。

过程视

包括形成系统的并发和同步机制的线程和过程，描述系统的性能、可扩展性和总处理能力。视的静态方面由类图和对象图描述，动态方面由交互图、状态图、活动图描述。

实现视

包括用于组装物理系统的组件和文件，主要描述系统版本的配置管理。系统版本由独立的组件和文件构成的可运行系统。视的静态方面由组件图描述，动态方面由交互图、状态图、活动图描述。

配置视

包括构成用于运行软件系统的系统硬件拓扑的节点，主要描述物理系统组成部分的分布、交付和安装。视的静态方面由配置图描述，动态方面由交互图、状态图、活动图描述。

4.2 用例图

4.2.1 用例图 (重要)

描述了用例、参与者以及它们之间的关系。

1. 用例（Use Case）
2. 参与者（Actor）
3. 依赖、类属和关联关系
4. 系统边界

用例模型

用例模型处于需求分析阶段，是系统开发者与用户反复讨论的结果，表示开发者与用户之间对需求规格定义达成了共识。UML中，一个用例模型由若干个用例图描述，用例图的主要元素是用例和参与者。

用例图示例(重要)

下图中，用例与参与者之间是双向导航关联关系。一般而言，参与者与用例间是多对多的关系。用例捕捉系统行为但不规定如何实现这些行为，通过协作来实现，协作是实现用例的类和其它元素的总称。

下图中，“Pay for bill”用例由“Deal with bill”协作来实现。每个给定的用例都由一个相应的协作来实现，因而一般不必显式地为这种关系建模。

4.2.2 参与者

参与者代表与系统交互的人、硬件设备或另一个系统，是个虚拟的概念。参与者不是软件系统的组成部分，存在于系统的外部。

参与者的功能

1. 向系统输入信息
2. 从系统接收信息
3. 既可向系统输入信息，也可接收系统输出信息

如何识别参与者(重要)

1. 谁是系统的主要用户
2. 谁从该系统获得信息
3. 谁向系统提供信息
4. 谁从系统删除信息
5. 谁支持、维护系统
6. 谁管理系统
7. 系统需要与哪些其他系统交互
8. 系统需要操作哪些硬件
9. 在预设的时间内，有事情自动发生吗
10. 系统从那里获得信息
11. 谁对系统的特定需求感兴趣
12. 几个人在扮演同样的角色吗
13. 一个人扮演几个不同的角色吗
14. 系统使用外部资源吗
15. 系统用在什么地方

识别参与者注意事项

1. 参与者代表角色
2. 角色不是对职位进行建模

用例图中考虑不同类型的人所扮演的角色，而不是具体考虑不同职位的人作为参与者，这样简化了用例图。

参与者示例

参与者可以是人、组织或系统。一个人、组织或系统可以扮演多个角色。

4.2.3 用例

用例是对系统行为的动态描述。它正式化、形式化地获取软件开发过程中的场景，促进理解系统的需求和工作原理。

识别用例(重要)

首先识别参与者，对每个参与者列出它的用例，形成用例清单。
1. 每个参与者的任务是什么
2. 有参与者将要创建、存储、改变、删除或读取系统中的信息吗
3. 什么用例会创建、存储、改变、删除或读取这个信息
4. 参与者需要通知系统外部的突然变化吗
5. 需要通知参与者系统中正在发生的事情吗
6. 什么用例将支持和维护系统
7. 所有的功能需求都能被用例执行吗
8. 系统需要何种输入输出？输入从何而来？输出到何处
9. 当前运行系统的主要问题

确定用例原则(重要)

1. 选取适中的用例粒度，提炼和归纳
2. 一个用例应描述一个从头至尾的完整功能，用例要与参与者交互
3. 绑定彼此密切相关但不同的功能，减少用例数目

用例示例

用例描述(重要)

对于每个用例，可用事件流来规定用例的行为。用例的事件流是对完成用例规定行为所需要的事件的描述。

1. 用例什么时候开始，如何开始
2. 用例什么时候结束，如何结束
3. 用例和参与者之间有什么样的交互作用
4. 用例需要什么数据
5. 用例的标准的事件顺序
6. 替代的或例外的事件流的描述

用例事件流描述(重要)

用例描述,需要对用例的主要属性进行说明,这些属性有:

1. 前置条件
2. 后置条件
3. 扩充点
4. 事件流
5. 特殊要求
6. 问题说明

事件流描述
1. 基流
2. 分流(循环与分支)
3. 替换流(一般用于错误处理过程)

用例事件流描述示例

学生选课用例的基本流描述

1. 基本流
   a. 学生选择要选修的课程.
   b. 系统通过财务系统检查学生是否缴费.
   c. 系统更新该学生所选课程.
   d. 系统显示学生所选课程.
   e. 学生确认所选课程.
   f. 系统保存学生所选课程.
2. 备选流
   a. 如果学生没有交费,给出提示,结束.
   b. 如果学生没有确认,给出提示,结束.
3. 事件流的循环与分支
   a. 学生输入锁选课程编号.
   b. 系统记录输入的课程.重复~
   …

用例与脚本

当细化对系统需求的理解时，需要用交互作用图来描述这些流。使用不同的交互作用图来描述用例包含信息的不同方面。

一个用例描述了一个序列集，序列集中的每个序列描述了一个流，这个流代表用例的一个变种，每个这样的序列称为一个脚本或场景(Scenario)。脚本是阐明行为的一个特定的动作序列。脚本与用例的关系就象实例与类的关系。

复杂系统用多个用例来描述系统行为，每个用例用多个交互作用图来详细描述。

用例之间的关系(重要)

类属关系(泛化,Generalization)

类属、包含、扩充关系。应用这些关系抽取出公共行为和变种。

【箭头指向】：指向父用例

包含关系

多个用例将共享功能放于一单独的用例中，新用例与其他使用其功能的用例间创建包含关系。被包含的用例不能单独存在，只是包含它的更大用例的一部分。

使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用.基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。

【箭头指向】：指向分解出来的功能用例

业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来理清关系。

扩充关系(Extend)

说明可选的、只在特定条件下运行的行为，基于参与者的选择可运行几个不同的流。

基用例可独立存在，但在特定条件下，它的行为将被另一个用例的行为扩充。基用例只在被称为扩充点的特定点被扩充。可认为，扩充用例将行为推进基用例。

如果一个用例明显地混合了两种或两种以上不同的场景，可以将这个用例分为一个基础用例和一个扩展用例.扩展关系用<>关系表示，箭头指向基本用例（也就是从子类指向父类）。

与此同时，扩展用例是基础用例在某些特定条件下触发产生的，扩展用例不是基础用例必须存在的部分，扩展用例可以单独存在，扩展用例知道基础用例的存在而基础用例不知道基础用例的存在。

一个用例可以有多个扩充点，每个扩充点也可出现多次。

下图中，考试失败是扩充点，特定条件下的行为置于补考用例中

例如，系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导入、打印和查询相对独立，而且为查询添加了新行为。因此可以采用扩展关系来描述：

元素符号总览(重要)

4.2.4 用例图的应用(重要)

用来为系统的静态用例视建模。静态用例视支持系统的行为—系统提供的外部可见服务。

用例图主要用来描述用户需求,侧重从最终用户的角度来理解软件系统的需求,强调谁在使用系统,系统可以完成哪些功能.

用例图是一种有效的用户需求获取分析和描述的技术.

1.为系统的上下文建模

围绕整个系统划一条线，并确保位于系统外的参与者与系统相互作用。这个上下文定义了系统存在的环境。为系统上下文建模时：

1. 确定参与者（识别参与者原则）
2. 将彼此类似的参与者组织在类属关系中
3. 为每个参与者提供原型，以利于理解
4. 规定每个参与者到系统用例的通信路径

2.为系统的需求建模

需求规定了用户期望系统做什么。系统的全部或大部分需求可以表达为用例。为系统需求建模时：

1. 确定环绕系统的参与者，建立系统上下文
2. 考虑每个参与者期望的行为
3. 抽取常见的行为作为用例
4. 确定被其它用例使用的用例或用来扩充其他用例的用例
5. 在用例图中描述用例、参与者及它们的关系
6. 用注释来描述非功能需求