用例的名称有两种： ① 简单名，如：AddItem ② 路径名，如：Business::Maintenance
识别用例
识别用例最好的方法就是从分析系统的参 与者开始，考虑每个参与者是如何使用系 统的。 如何识别用例。
用例与事件流
事件流描述系统“做什么”，而不是“怎 么做”，它通常包括： 1. 简要说明； 2. 前提条件； 3. 主事件流、其他事件流、错误流； 4. 事后条件。
1. 借阅者请求服务的用例 2. 图书馆管理员处理借书、还书等的用例 3. 系统管理员进行系统维护的用例
1. 借阅者请求服务的用例
① ② ③ ④ ⑤ ⑥ 登录系统 查询自己的借阅信息 查询书籍信息 预定书籍 借阅书籍 归还书籍
2. 图书馆管理员处理借书、还书的用例
① 处理书籍借阅 ② 处理书籍归还 ③ 删除预定信息
31
面向对象分析与设计 & UML
3.7 寻找用例的方法
发现用例的一般原则：
与用户交互 假设自己是参与者, 与系统进行交互 确定用例和确定参与者不能截然分开
Jacobson提供的一些原则:

32
参与者的主要任务是什么? 参与者需要了解系统的什么信息? 需要修改系统的什么信息? 参与者是否需要把系统外部的变化通知系统? 参与者是否希望系统把异常情况通知自己?
确定参与者
如何寻找系统的参与者； 对参与者建模的过程中需要注意的问题。
参与者间的关系
在用例图中，使用泛化 关系来描述多个参与者 之间的公共行为。 参与者间的泛化关系 示例：
5.1.3 用例（Use Case）
用例是外部可见的系统功能单元。 用例的用途是在不揭示系统内部构造的前提 下定义连贯的行为。 用例不是需求或功能的规格说明，但是也展 示和体现其所描述的过程中的需求情况。
(2) 储户按“取款”按钮,并输入 • 设置交易类型为“取款” 取款数目 • ATM系统获得取款金额 (3) 储户取走现金/ATM卡/收据 • 输出现金、收据和ATM卡 (4) 储户离开
只描述了actor的行为
29 面向对象分析与设计 & UML
• 系统复位
只描述了System的行为
3.6 用例的描述
网上预订
填写电子表格
5.1 包含关系
15
面向对象分析与设计 & UML
扩展关系
扩展用例被定义为基础用例的增量扩展。 基础用例提供扩展点以添加新的行为。 扩展用例提供插入片段以插入到基础用例的扩展 点上。
如：
<<extend>>
还车
交纳罚金
5.1 扩展关系
17
面向对象分析与设计 & UML
确定参与者
参与者
学生 教师
系统管理员
确定与参与者相关的用例
5.3.5 图书馆管理系统的用例图
1. 借阅者请求服务的用例图 2. 图书馆管理员处理借书、还书的用例图 3. 系统管理员进行系统维护的用例图
1. 借阅者请求服务的用例图
2. 图书馆管理员处理借书、还书的 用例图
3. 系统管理员进行系统维护的用例图
实例分析—网络教学系统
学生可以登录网站浏览信息、查找信息和 下载文件 教师可以登录网站输入课程简介、上传课 件、发布消息、修改和更新消息 系统管理员对页面维护以及处理注册申请
28
面向对象分析与设计 & UML
3.6 用例的描述
ATM系统“取款”用例的两个错误描述：
Use case: Withdraw cash Actor: customer 主事件流： (1) 储户插入ATM卡,并输入密码 Use case: Withdraw cash Actor: customer 主事件流： • ATM系统获得ATM卡和密码
5.1.2 参与者（Actor）
系统外部的一个实体。 参与用例的执行过程。 通过向系统输入或请求系统 输入某些事件来触发系统的 执行。 由参与用例时所担当的角色 来表示。 每个参与者可以参与一个或 多个用例。
① ② ③
参与者的种类： 系统用户； 与所建造的系统交互的其他系统； 一些可以运行的进程 。
频率[可选]
27
参与者访问此用例的频率, 如: 每日一次/每月一次等
面向对象分析与设计 & UML
例：用例“处理订单”的描述
3.6 用例的描述
描述用例时易出现的错误：
只描述系统的行为, 没有描述参与者的行为
只描述参与者的行为, 没有描述系统的行为 在用例描述中就设定了对用户界面的设计的要求 描述过于冗长
ATM系统“取款”用例的正确描述：
Use case: Withdraw cash Actor: customer 主事件流： • 储户通过读卡机插入ATM卡 • ATM系统从卡上读取银行ID、账号、加密密码, 并通过主银行 系统验证银行ID和账号 • 储户输入密码, ATM系统根据加密密码对输入密码进行验证 • 储户按 “取款”按钮, 并输入取款数目, 该数目应该为$5的倍 数 • ATM系统通知主银行系统, 传递账号和金额, 并接收返回的确认 信息和账户余额 • ATM系统输出现金、ATM卡和收据 • ATM系统记录交易到日志文件
3.8 常见问题分析
(2) 四轮马车 系统中相似的功能, 是合并为一个用例还是 分解为几个用例?
方法1 一个用例/三个脚本
方法2 三个用例
36
面向对象分析与设计 & UML
3.8 常见问题分析
(4) 下面哪个用例图正确?
37
面向对象分析与设计 & UML
5.3 实例——图书馆管理系统的用例图
5.3.1 5.3.2 5.3.3 5.3.4 5.3.5 确定系统涉及的总体信息 确定系统的参与者 确定系统的用例 使用Rational Rose绘制用例图的步骤 图书馆管理系统的用例图
30 面向对象分析与设计 & UML
3.7 寻找用例的方法
用例分析的基本步骤：
①
② ③ ④
找出系统外部的参与者和外部系统, 确定系统边界和范围
确定每一个参与者所期望的系统行为 把这些系统行为命名为用例 使用泛化、包含、扩展等关系处理系统行为的公共或变更部分
⑤
⑥ ⑦ ⑧
编制每一个用例的脚本
绘制用例图 区分主要事件流和异常事件流, 如果需要, 可以把异常事件流处 理为单独的用例 细化用例图, 解决用例间重复与冲突的问题.
描述项
被泛化的用 例 此用例所泛化的用例列表 此用例所包含的用例列表 此用例所扩展的用例列表 关于用例的修改时间、修改原因、修改人的详细信息 与此用例的开发有关的问题列表 关键决策的列表, 将这些决策信息记录下来以便维护时使 用
说明
被包含的用 例
被扩展的用 例 修改历史记 录[可选] 问题[可选] 决策[可选]
5.1 几种关系的比较
关系类型 关联 说明 actor与use case 之间 表示符号
泛化
包含 扩展
21
actor之间或use case之间
use case之间 use case之间
面向对象分析与设计 & UML
5.2 用例图建模技术
5.2.1 对语境建模 5.2.2 对需求建模
5.2.1 对语境建模
5.2 用例的描述
用例描述一般包括的内容：
用例的目标
用例是怎么启动的 参与者与用例之间的消息如何传送
用例中除了主路径外, 其它路径是什么
用例结束后系统的状态 其它需要描述的内容 描述用例时的原则是尽可能写得“充分”, 而不是形式 化、完整或漂亮.
25 面向对象分析与设计 & UML
5.1.4 用例间的关系
1 2 3 4 关联关系 包含关系 扩展关系 泛化关系
关联关系
表示参与者与用例之间进行通信。 不同的参与者可以访问相同的用例。
包含关系
客户用例可以简单地包含提供者用例具有的行为， 并把它所包含的用例行为作为自身行为的一部分。
如：
<<include>>
3. 系统管理员进行系统维护的用例
① ② ③ ④ ⑤ ⑥ ⑦ ⑧ 查询借阅者信息 查询书籍信息 增加书目 删除或更新书目 增加书籍 删除书籍 添加借阅者帐户 删除或更新借阅者帐户
5.3.4 使用Rational Rose绘制用例图 的步骤
1. 2. 3. 4. 5. 6. 创建用例图 用例图工具栏按钮简介 工具栏的定制 添加参与者与用例 添加参与者与用例之间的关系 添加用例之间的关系
前置条件
后置条件 基本操作流 程
一个条件列表, 这些条件必须在访问用例前得到满足
一个条件列表, 这些条件必须在用例完成之后得到满足 描述用例中各项工作都顺利进行时用例的工作方式
可选操作流 描述变异工作方式、出现异常或发生错误的情况下的路径 26程 面向对象分析与设计 & UML
3.6 用例的描述
用例的描述格式(续表)
第5章 用例图
5.1 用例图的概念 5.2 用例图建模技术 5.6 实例——图书馆管理系统中的 用例图
5.1.1 概述
用例图显示谁将是相关的用户、用户希望系统提 供什么服务以及用户需要为系统提供的服务。 用例图最常用来描述系统以及子系统。
5.1.1 概述
① ② ③ ④ ⑤ ⑥ 用例图包含6个元素： 参与者（Actor） 用例（Use Case） 关联关系（Association） 包含关系（Include） 扩展关系（Extend） 泛化关系（Generalization）
强调的是：系统的外部参与者。