UML系统用例及用例关系

用例的命名
用例图
执行者视角：
（状语）动词+（定语+ ）宾语
4 Click to add title in here
一 需求获取
用例图
2 解答问题
在需求获取过程中，主要需要弄清楚三个问题
What
•明确需要获取的信息
Where
•明确所获取信息的来源和渠道
How
•怎样获取需求
用例图
二 用例图相关概念介绍
用例图
❖1. 什么是用例图
▪ 由参与者（Actor）、用例（Use Case）以及它们之 间的关系构成的用于描述系统功能的动态视图称为用 例图。
用例由其用户角色使用，并提供确切 的输出给角色
用例可大可小，但它必须是对一个具 体的角色目标实现的完整描述
用例的动态执行过程可以用UML的交互 作用来说明，可以用状态图、顺序图、
协作图或非正式的文字描述来表示百度文库
识别用例
用例图
识别用例
关键词：价值 定义
用例实例是系统执行的一系列动作， 这些动作将生成特定参与者可观测的结 果值
一个用例定义一组用例实例（场景）
简洁：参与者使用系统达到目标
识别用例要点
用例图
可观测→用例止于系统边界 结果值→用例是有意义的目标 系统执行→结果值由系统生成 由参与者观测→业务语言、用户观点 一组用例实例→用例的粒度 用例命名
可观测：用例止于系统边界
用例图
系统
描述交互，而不是内在的系统活动
边界---Boundary
参与者，Actor
关键词：边界 参与者：在系统之外，透过
系统边界与系统进行有意义交 互的任何事物
识别参与者２ 用例图
要点
系统外
参与者代表在系统边界之外的真实事物，并不是 系统的成分
系统边界
参与者透过系统边界直接与系统交互，参与者 的确定代表系统边界的确定
有意义交互的任何事物
人、外系统、外部因素、时间
统一建模语言
用例图 11软件工程
CH4 用例图 系统用例及用例关系
知识回顾—需求获取
用例图
需求工程
需求管理
需求开发
问题获取 分析 编写规格说明 验证
教学目标 用例图
掌握用例图的地位作用及定义
重 点
掌握用例图模型元素
能够根据需求分析使用用例图建模
难 点
确定用例及用例间的关系
教学内容
用例图
需求获取
2. 用例图的作用
用例图
❖ 用例图是需求分析中的产物，主要作用是描述参 与者和用例之间的关系，帮助开发人员可视化的 了解系统的功能。
❖ 用例图可视化地表达了系统的需求，具有直观、 规范等优点，克服了纯文字性说明的不足。
❖ 用例方法是完全从外部来定义系统功能，它把需 求和设计完全的分离开来。
识别参与者1 用例图
最常犯错误：粒度过细，陷入功能分解
过细的粒度，一般都会导致技术语言的描 述，而不再是业务语言
用例粒度-1
把步骤当用例
会员
把系统活动当用例 会员
用例图
×
输入用户名
<<include>>
登录
验证用户名和密码
√
查询订单
<<include>>
建立数据库连接
<<include>>
×
执行SQL语句
用例粒度-2 用例图
×增加用户 管理员
修改用户
查询用户
删除用户
用例粒度-3
用例图
“四轮马车”
C(Create) R(Read) U(Update) D(Delete)
所有业务最终会成为CRUD？ CRUD能为Actor提供价值？ CRUD掩盖业务，锐变成关系数据库的建模：
“系统就是数据的增删改查” 关心数据的存储和维护，反而忽略了用户的目的
识别参与者思路
用例图
谁使用系统的主要功能 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务 谁负责日常维护、管理并保证系统正常运行 谁使用或删除系统中的信息 谁（或什么）对系统运行产生的结果（值）感兴趣 系统需要应付（处理）那些硬设备 系统需要和那些外部系统交互 在预定时间，是否有事件自动发生 时间、气温等内部外部条件 ……
客户
参与者所共享
商业客户 个体客户
用例1
用例
用例图
定义：Use Case 用例表示系统的一项外部
功能，它从用户的角度分析 所得的需求。为完成一个相 对完整的一种功能，系统执 行的一系列动作的集合
是外部可见的一种系统功能 代表的是一个完整的功能 有一系列动作
用例2
用例图
用例捕获某些角色可见的需求，实现 一个具体的角色需求
用例粒度-4
用例图
如果确实是CRUD？
如果CRUD不涉及复杂的交互，一个用例“管理××” 即可
不管是C、R、U、D，都是为了完成“管理”目标 甚至很多种的基本数据管理都可以用一个用例表示
管理员
管理用户
用例粒度-5
用例图
灵活处理CRUD
管理员
<<extend>>
管理用户
增加用户
可以把包含复杂交互的路径独立出去形成用例
用例图
也叫系统边界，用于界定系统功能范围
用一个带名称的矩形框，把描述系统功能的用例都 置于其中，而描述的与系统交互的角色都置于其外
系统----完整系统或子系统 一个系统包括一个或多个用例
准确的定义系统的边界（功能）不是一件很容 易的事
先识别出系统的基本功能集，以此为基础定义 一个稳定的、精确定义的系统体系结构，再不 断地扩充系统功能，以逐步完善
参与者的类型和职责
用例图
主要参与者
直接与系统交互的人，或执行系统主要功能的执 行者
次要参与者
使用系统次要功能的执行者，或维护系统一般功 能的执行者
外部硬件
作为系统一部分的、运行应用的非计算机的硬件
其他系统
为其工作需要与系统交互的外部系统
参与者之间的关系
用例图
独立关系
泛化关系
一个参与者的抽象描述
可以被一个或多个具体的
需求获取及分析 需求的基本方法
用例图
什么叫用例图
用例图的构成要素
用例的重要元素
用例之间的各种重 要关系
用例图建模应用
识别参与者 确定用例 用例建模
一 需求获取
用例图
1 问题引入
▪ 需求是客户在项目立项时就有的一个远景，客户需求 将决定在整个项目中需求承办方具体做些什么，即承 办方的任务。承办方在明确了需求后，就会开始后期 的设计、开发、测试、部署等工作。
结果值：有意义的目标
用例图
业务功能，而非系统处理
设定查询条件
会员 会员
选择零件
×
√
检索零件
系统执行：结果值由系统生成
用例图
出纳员
吃饭
系统需要处理的，由系统生成
×
参与者观测：用户观点而非系统观点
用例图
旅客
订票 查看今日航班
旅客
处理订票 显示今日航班
× 用户观点
系统观点
要点：用例粒度
用例图
用例要有路径，路径要有步骤；而这一 切都是可观测的