第3章用例和用例图

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