UML系统用例及用例关系

用例图
旅客
订票 查看今日航班
用户观点
× 处理订票
旅客 显示今日航班
系统观点
要点：用例粒度
用例图
用例要有路径，路径要有步骤；而这一 切都是可观测的
最常犯错误：粒度过细，陷入功能分解
过细的粒度，一般都会导致技术语言的描 述，而不再是业务语言
用例粒度-1
把步骤当用例
会员
把系统活动当用例 会员
可以被一个或多个具体的
客户
参与者所共享
商业客户 个体客户
用例1
用例
用例图
定义：Use Case 用例表示系统的一项外部
功能，它从用户的角度分析 所得的需求。为完成一个相 对完整的一种功能，系统执 行的一系列动作的集合
是外部可见的一种系统功能 代表的是一个完整的功能 有一系列动作
用例2
用例图
用例图
×
输入用户名
<<include>>
登录
验证用户名和密码
√
查询订单
<<include>>
建立数据库连接
<<include>>
×
执行SQL语句
用例粒度-2 用例图
×增加用户 管理员
修改用户
查询用户
删除用户
用例粒度-3
用例图
“四轮马车”
C(Create) R(Read) U(Update) D(Delete)
4 Click to add title in here
一 需求获取
用例图
2 解答问题
在需求获取过程中，主要需要弄清楚三个问题
What
•明确需要获取的信息
Where
•明确所获取信息的来源和渠道
How
•怎样获取需求
用例图
二 用例图相关概念介绍
用例图
❖1. 什么是用例图
▪ 由参与者（Actor）、用例（Use Case）以及它们之 间的关系构成的用于描述系统功能的动态视图称为用 例图。
管理员
管理用户
用例粒度-5
用例图
灵活处理CRUD
管理员
Hale Waihona Puke Baidu
<<extend>>
管理用户
增加用户
可以把包含复杂交互的路径独立出去形成用例
用例的命名
用例图
执行者视角：
（状语）动词+（定语+ ）宾语
顾客
购买商品 <<extend>> 信用卡支付
用例关系
用例图
Include
<<include>> Include
可观测：用例止于系统边界
用例图
系统
描述交互，而不是内在的系统活动
边界---Boundary
用例图
也叫系统边界，用于界定系统功能范围
用一个带名称的矩形框，把描述系统功能的用例都 置于其中，而描述的与系统交互的角色都置于其外
系统----完整系统或子系统 一个系统包括一个或多个用例
准确的定义系统的边界（功能）不是一件很容 易的事
泛化
用例图
一个售货员可以终止任何交易，除了那些需要特殊的售 货员（高级代理）终止的超过了一定限制的交易
终止一个基本交易
普通售货员 终止一个小交易
终止一个大交易
高级代理
包含用例与扩展用例的区别
用例图
①相对于基础用例，扩展用例是可选的，而 包含用例则不是。
②如果缺少扩展用例，基础用例还是完整的， 而缺少包含用例，则基础用例就不完整了。
…… 开发者：现在考勤卡应用程序是什么样的？
Record Time
客 户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表 格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目
代码，横向是日期。雇员可以在每个条目上填写说明。
开发者：这个收费项目代码可以从什么地方得到？
…… 开发者：谁来管理收费项目代码？
在这个叙述里，谁是寻呼台系统的Actor？ 用户？气温？时间？
思考2：获取需求-考勤卡应用程序
用例图
初次访谈记录 开发者：谁将使用这个应用程序？ 客 户：所有用它来记录可记帐以及不可记帐的工时的雇员 …… 开发者：现在考勤卡应用程序是什么样的？ 客 户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表 格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目 代码，横向是日期。雇员可以在每个条目上填写说明。 开发者：这个收费项目代码可以从什么地方得到？ …… 开发者：谁来管理收费项目代码？ 客 户：嗯，必要的时候由我来添加这个代码。而每个经理总会告诉他 的下属应该填写什么。 ……
Create Charge Code
客 户：嗯，必要的时候由我（业务经理）来添加这个代码。而每个经
理总会告诉他的下属应该填写什么。
……
思考2：考勤卡系统
用例图
思考3：识别用例
用例图
❖ Email客户端（如：outlook express），A在北 京发邮件给上海的B，系统提醒B你有“新邮件”， B收邮件
获取原始需求 开发一个可以理解的需求
识别参与者 识别用例 确定关系
思考
用例图
基于用例的需求分析过程可大致分几步？ 什么是系统边界 用例的概念 用例的关系 参与者的定义与关系
思考1：识别参与者？
用例图
寻呼台系统：用户如果预定了天气预报， 系统每天定时给他发天气消息；如果当天 气温高于35度，还要提醒用户注意防暑；
③扩展用例的执行需要满足某种条件，而包 含用例不需要。
④扩展用例的执行会改变基础用例的行为， 而包含用例不会。
用例关系：扩展 VS. 泛化
用例图
识别用户
<<extend>> 验证口令
验证口令
扫描指纹
识别用户 <<extend>> 扫描指纹
采用不同关系，文档结构不同
小结
用例图
理解需求 以用例为中心组织需求 基于用例的需求分析过程
用例实例是系统执行的一系列动作， 这些动作将生成特定参与者可观测的结 果值
一个用例定义一组用例实例（场景）
简洁：参与者使用系统达到目标
识别用例要点
用例图
可观测→用例止于系统边界 结果值→用例是有意义的目标 系统执行→结果值由系统生成 由参与者观测→业务语言、用户观点 一组用例实例→用例的粒度 用例命名
用例捕获某些角色可见的需求，实现 一个具体的角色需求
用例由其用户角色使用，并提供确切 的输出给角色
用例可大可小，但它必须是对一个具 体的角色目标实现的完整描述
用例的动态执行过程可以用UML的交互 作用来说明，可以用状态图、顺序图、
协作图或非正式的文字描述来表示
识别用例
用例图
识别用例
关键词：价值 定义
思考2：识别参与者：考勤卡系统
用例图
开发者：谁将使用这个应用程序？
客 户：所有用它来记录可记帐以及不可记帐的工时的雇员
…… 开发者：现在考勤卡应用程序是什么样的？
Employee
客 户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表 格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目 代码，横向是日期。雇员可以在每个条目上填写说明。
参与者，Actor
关键词：边界 参与者：在系统之外，透过
系统边界与系统进行有意义交 互的任何事物
识别参与者２ 用例图
要点
系统外
参与者代表在系统边界之外的真实事物，并不是 系统的成分
系统边界
参与者透过系统边界直接与系统交互，参与者 的确定代表系统边界的确定
有意义交互的任何事物
人、外系统、外部因素、时间
参与者的类型和职责
用例图
主要参与者
直接与系统交互的人，或执行系统主要功能的执 行者
次要参与者
使用系统次要功能的执行者，或维护系统一般功 能的执行者
外部硬件
作为系统一部分的、运行应用的非计算机的硬件
其他系统
为其工作需要与系统交互的外部系统
参与者之间的关系
用例图
独立关系
泛化关系
一个参与者的抽象描述
基础用例不必知道扩展用例的 任何细节，它仅为其提供扩展点
扩展用例的行为是否被执行要 取决于主事件流中的判定点。
扩展关系2
用例图
扩展关系
用例图
基用例路径本身是完整的 可能是一条扩展路径 扩展路径步骤多 扩展路径内部还可以有扩展点－扩展之扩展 扩展路径未定或容易变化－分离以“冻结”
基用例 基础用例可以单独存在，但在一定条件下，
开发者：这个收费项目代码可以从什么地方得到？
…… 开发者：谁来管理收费项目代码？
客 户：嗯，必要的时候由我（业务经理）来添加这个代码。而每个经
理总会告诉他的下属应该填写什么。 ……
Administrativ e User
思考2：识别用例：考勤卡系统
用例图
开发者：谁将使用这个应用程序？
客 户：所有用它来记录可记帐以及不可记帐的工时的雇员
识别参与者思路
用例图
谁使用系统的主要功能 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务 谁负责日常维护、管理并保证系统正常运行 谁使用或删除系统中的信息 谁（或什么）对系统运行产生的结果（值）感兴趣 系统需要应付（处理）那些硬设备 系统需要和那些外部系统交互 在预定时间，是否有事件自动发生 时间、气温等内部外部条件 ……
他的行为可以被另一个用例作为扩展
扩展举例
用例图
泛化关系
用例图
同一业务目的不同技术实现：
一个用例可以泛化为另一个更普通用例（更普通用例特化为 特殊用例）
UML 1.5: 用例间的泛化关系表明子用例包含父用例中定义 的所有属性、行为序列和扩展点，并且参与父用例中所有的 关系
识别用户
验证口令
扫描指纹
所有业务最终会成为CRUD？ CRUD能为Actor提供价值？ CRUD掩盖业务，锐变成关系数据库的建模：
“系统就是数据的增删改查” 关心数据的存储和维护，反而忽略了用户的目的
用例粒度-4
用例图
如果确实是CRUD？
如果CRUD不涉及复杂的交互，一个用例“管理××” 即可
不管是C、R、U、D，都是为了完成“管理”目标 甚至很多种的基本数据管理都可以用一个用例表示
提取公共步骤，便于复用
Extend
分离扩展路径
<<extend>>
Extend
Generalization
同一业务目的的不同技术实现
Generalization
包含关系1
用例图
<<include>>
下订单
提供客户信息
包含关系2
用例图
包含关系
用例图
某些步骤在多个用例重复出现，且单 独形成价值
发件人
发邮件
邮件
收邮件
收件人
系统
提醒新邮件
用例是一个完整的交互，用例之间没有顺序的关系
思考3：识别用例-正确
用例图
用户 时间
发邮件 收邮件 提醒新邮件
下一讲内容
❖ 用例规约
用例图
统一建模语言
用例图 11软件工程
CH4 用例图 系统用例及用例关系
知识回顾—需求获取
用例图
需求工程
需求管理
需求开发
问题获取 分析 编写规格说明 验证
教学目标 用例图
掌握用例图的地位作用及定义
重
点
掌握用例图模型元素
能够根据需求分析使用用例图建模
难 点
确定用例及用例间的关系
教学内容
用例图
需求获取
需求获取及分析 需求的基本方法
用例步骤较多时，可用Include简化 当完全知道什么时间要调用用例时，
基用例需要包含用例所封装的逻辑 可以简单认为源代码中的函数调用或
操作调用
包含举例1
用例图
包含举例2
用例图
扩展关系1 用例图
<<extend>>
会员
管理订单
从订单中删除某个订单项
扩展关系2
用例图
将扩展用例的事件流在一定的条 件下按照相应的扩展点插入到基础 用例中。
2. 用例图的作用
用例图
❖ 用例图是需求分析中的产物，主要作用是描述参 与者和用例之间的关系，帮助开发人员可视化的 了解系统的功能。
❖ 用例图可视化地表达了系统的需求，具有直观、 规范等优点，克服了纯文字性说明的不足。
❖ 用例方法是完全从外部来定义系统功能，它把需 求和设计完全的分离开来。
识别参与者1 用例图
用例图
什么叫用例图
用例图的构成要素
用例的重要元素
用例之间的各种重 要关系
用例图建模应用
识别参与者 确定用例 用例建模
一 需求获取
用例图
1 问题引入
▪ 需求是客户在项目立项时就有的一个远景，客户需求 将决定在整个项目中需求承办方具体做些什么，即承 办方的任务。承办方在明确了需求后，就会开始后期 的设计、开发、测试、部署等工作。
先识别出系统的基本功能集，以此为基础定义 一个稳定的、精确定义的系统体系结构，再不 断地扩充系统功能，以逐步完善
结果值：有意义的目标
用例图
业务功能，而非系统处理
设定查询条件
×
会员 选择零件
√
会员
检索零件
系统执行：结果值由系统生成
用例图
出纳员
× 吃饭
系统需要处理的，由系统生成
参与者观测：用户观点而非系统观点