Telephone Catalog
用例 参与者与用例间的关系
check status
place order
顾客 用例名
fill orders
establish credit
系统边界
参与者 销售员 货运员 监督员
3.2 参与者
参与者指系统外部的、需要使用系统或与 系统交互的一个实体。
参与用例的执行过程。 通过向系统输入或请求系统输入某些事件
一个动词或者一个动词短语，用 于指明关系的类型或者目的。
关联关系表示通信途径
关联关系
用例图的两种类型关联：
1、单向关联
项目管理系统
项目经理
管理项目
2、双向关联
项目数据库
包含关系
将若干用例的相同动作，提取出来单独构成一个 用例。这个用例可以重用
描述的是基本用例需要某种类型的行为，而包含 用例定义了该行为，那么在用例的执行过程中， 就可以调用已经定义好的用例。
父用例表示通用行为序列，通过插入额外的步骤， 子用例特化父用例。
表示方法
例如，
项目经理
泛化关系
项目管理系统
邮件系统
公布项目 进度表
发送邮件 生成Web
站点
项目 数据库
兼职经理
全职经理
Web站点主机
关系数据库
面向对象 数据库
关系的比较
包含 扩展 泛化
特点
若一个用例包含一段定义良好且有可能用于其它 场合的动作序列或几个用例都有共同的一段动作 序列，可把该动作序列定义成一个包含用例。 基本用例没有包含用例是不完整的。 使用时，基本用例无条件调用包含用例。
例如，
项目经理
包含关系
项目管理系统 添加项目 删除项目
<<include>> 查找项目
项目 数据库
扩展关系
指的是一个用例可以增强另一个用例的行为 基本用例提供扩展点以添加新的行为。 扩展用例提供插入片段以插入到基本用例的扩展点上。 当在某个现有用例中插入“可选”行为或“异常”行为时，
3.4 用例间的关系
关系反应了参与者和用例之间、用例和用例之间 以及参与者和参与者之间的相互作用。
1 关联关系 2 包含关系 3 扩展关系 4 泛化关系
关联关系
表示参与者用例之间进行通信。 信息可以双向流动。
关系方向显示的不是信息的流 动方向，而是谁启动信息。
表示
工具箱：
模型图中：
关联命名
3.3 用例
图形表示
用椭圆形表示， 用例的名字显示 在图标的下面
例1，字处理程序
Purchase Ticket
置正文为黑体
左对齐
例2，银行业务系统
创建索引
浏览帐户余额 列出交易内容 划拨资金 支付账款
3.3 用例
注意：
① 不要把所有需求都以用例的形式表示出来， 只把重要的、交互过程复杂的用例找出来
② 用例不是系统的全部需求，全部需求包括： 系统的目的和范围；系统中的术语表；用例； 系统采用的技术；开发过程中的参加人员、 业务规则、系统运行所依赖的条件等；法律、 政治、组织机构等
③ 用例是与实现无关的关于系统功能的描述。 是一种功能分解的技术，并没有使用面向对 象思想。
3.3 用例
协作
是对由共同工作的类、接口和别的元素所组成 的群体的命名，这组群体提供合作的行为。
例如，“提取现金”用例
3.6 事件流及脚本
主事件流
1 插入卡 2 验证卡 3 验证银行客户 4 选择取款 5 在标准数额列表里选
择取款金额
6 与银行系统确认交易 7 支付现金 8 弹出卡
可选事件流
1.1 无法识别卡 3.1 无法识别客户 4.1 不需要取款 5.1 非标准取款数额 5.2 帐户余额不足 5.3 金额超出每日最 高限额
3.6 事件流及脚本
例如：“浏览产品并下定单”用例 主事件流的开始部分
参与者“客户”选择浏览“在售产品目录”时， 启动本用例
用例结束部分
系统询问客户是否还需订购更多产品 如果客户希望订购更多的产品，用例重回到{显
示产品类别}处 如果客户不想再订购其他产品，用例终止
3.6 事件流及脚本
参与者需要读取、创建、撤消、修改、或存储 系统的某些信息吗？
是否任何一个参与者都要向系统通知有关突发 性的、外部的改变？或者必须通知参与者关于 系统中的发生的事件？
这些事件代表了哪些功能？
用例识别
识别用例
系统需要哪些输入/输出？ 这些输入输出来自哪里或者到哪里去？ 哪些用例支持或维护系统？ 是否所有功能需求都被用例使用了？ 系统当前实现的主要问题是什么？
例 1 参与者客户选择浏览“在售产品目录”时，启
动用例 {显示产品类别} 2 系统显示出“在售产品”，突出显示与客户的
配置文件相关的产品类别
3.6 事件流及脚本
5.定义可选事件流
可选事件流所描述的行为是可选的、特殊的， 他总是依赖于其他事件流中某个明显位置所发 生的条件，他允许在移除行为的同时，不会影 响主事件流或其他可选事件流
与用户沟通系统流 程，并将沟通内容
绘制成用例图
3.1 用例图
用例图包含6元素： ① 参与者（Actor） ② 用例（Use Case） ③ 用例间关系（Association） ④ 脚本（Scenario） ⑤ 描述（Description） ⑥ 系统
3.1 用例图
电话簿销售系统用例图 ：
系统名
对于在某些条件下，或可选情况下的一段动作序 列，可定义为扩展用例。 基本用例本身是完整的。 使用时，基本用例有条件调用扩展用例。
如果一个用例有几种变体，可使用泛化。
常见问题
一个用例应该至少向他的一个参与者提供唯一的、 独立的价值。若发现需要依次执行几个用例来获 取有用的信息，那么一定有问题
用例的粒度大小要合适，过小的用例不会对任何 参与者产生价值，过大的用例其逻辑又比较复杂
3.3 用例
用例特征：
① 用例从使用系统的角度描述系统中的信息，是从系 统的外部查看系统的功能，不考虑系统内部的具体 实现
② 说明了一个参与者与系统执行的一个相关事务序列
③ 用例描述了用户提出的一些可见需求，对应一个具 体的用户目标
④ 用例是对系统行为的动态描述，属于UML的动态建 模部分
⑤ 提供了一种与最终用户和领域专家进行沟通的方法 ⑥ 提供了一种测试系统的方法
不要将用例定义为功能菜单项，所谓CRUD问题
3.5 用例视图
用例图包含的内容
用例 参与者 用例与参与者之间的关联关系 用例之间的包含和扩展关系 参与者的泛化关系 用例图 用例实现 顺序图 协作图
3.5 用例视图
用例图操作
创建新的用例图 打开已有的用例图 删除用例图 链接用例图 重命名用例图
用例：提取现金
1 当参与者“客户”插入银行卡时，启动用例 2 系统从卡中读取银行卡信息 3 执行子事件流“验证客户” 4 系统提示客户输入提取金额
3.6 事件流及脚本
4.定义扩展点
扩展点是事件流中的命名空间，在这里可以插 入或附加其他行为
在事件流内部，扩展点用粗体大括号表示 例如，包含扩展点的“浏览产品并下定单”用
3.定义子事件流
子事件流是用例中一个行为片段，他有明确的 目标，同时是“原子性”的。
子事件流可以将复杂的事件流进一步划分，以 提高可读性
3.6 事件流及脚本
例如，子事件流
S1 验证客户 1 系统查询客户银行，确保该客户的帐户有效 2 系统提示客户输入PIN 3 客户输入PIN 4 系统使用从卡中读取的PIN验证所输入的PIN 5 恢复到下一步骤
特点：由基本用例决定是否调用，包含用例对调 用对象一无所知，且不参与其中的选择判断。
图形表示：
包含关系
使用包含关系的三种情况：
a. 多个用例包含大量类似的行为，应该考虑将这 些类似的行为通过包含关系包含到用例中
b.对两个或多个互相独立的用例建模时做了重复 的工作，可以通过包含关系包含这些重复的工 作
3.6 事件流及脚本
事件流用于描述参与者什么时候激活用例，以及 用例如何完成其任务
1.定义一个事件流
推荐使用叙述式风格，为每一个步骤编号，给每个独 立的部分加标题。
2.定义主事件流
应该覆盖用例执行时，正常发生的情况，是用例事件 流部分所描述的第一个事件流 从定义参与者启动用例的事件着手 描述参与者与系统正常交互 描述用例如何结束
参与者的识别 ① 谁将使用系统的主要功能？ ② 谁将需要系统的支持来完成他们的日常任务？ ③ 谁必须维护、管理和确保系统正常工作？ ④ 谁将给系统提供信息、使用信息和删除信息？ ⑤ 系统需要处理哪些硬件设备？ ⑥ 系统使用了外部资源吗？ ⑦ 系统需要与其他什么系统交互吗？ ⑧ 谁或者什么对系统产生的结果感兴趣？ ⑨ 一个人同时使用几种不同的规则吗？ ⑩ 几个人使用相同的规则吗？ 11 系统使用遗留下来的应用吗？
参与者间的关系
在用例图中，使用泛化关系 来描述多个参与者之间的公 共行为。
示例：
父参与者
子参与者
子参与者
子参与者继承父参与者的 行为和含义，并能增加自 己特有的行为和含义
子参与者可以出现在父参 与者能出现的任何位置上
3.3 用例
定义：
对一组动作序列的描述，系统通过执行这一 组动作序列为参与者产生一个可观察的结果
会变得十分复杂，应该考虑使用扩展关系
例
项目经理
扩展关系
项目管理系统
<<extend>> ( 任务函数)
[ 选择任务选项]