用例分析与用例图

用例1
软 件 工 程
用例捕获某些角色可见的需求，实现 一个具体的角色需求 用例由其用户角色使用，并提供确切 的输出给角色 用例可大可小，但它必须是对一个具 体的角色目标实现的完整描述 用例的动态执行过程可以用U M L的交 互作用来说明，可以用状态图、顺序图、 协作图、活动图或非正式的文字描述来 表示
过细的粒度，一般都会导致技术语 言的描述，而不再是业务语言
用例粒度-1
把步骤当用例
软 件 工 程
会员 输入用户名
<<include>>
×
会员
登录
验证用户名和密码
把系统活动当用例
<<include>> 建立数据库连接 <<include>> 查询订单 执行SQL语句
√
×
用例粒度-2
软 件 工 程
独立关系 泛化关系
一个参与者的抽象 描述可以被一个或 多个具体的参与者 所共享
客户
商业客户
个体客
用例
软 件 工 程
用例
定义：Use Case 用例表示系统的一项外部 功能，它从用户的角度分析 所得的需求。为完成一个相 对完整的一种功能，系统执 行的一系列动作的集合
是外部可见的一种系统功能 代表的是一个完整的功能 有一系列动作
软 件 工 程
结构视图 类图 对象图 顺序图 协作图 状态图 活动图 实现视图 组件图
用户视图
用例图 部署图
行为视图
环境视图
业务用例与系统用例
业务用例：
软 件 工 程
业务过程是描述这个业务的具体工作流的 一次涉众与实现业务目标的业务之间的交互 它可能包含手工和自动化的过程 也可能发生在一个长期的时间段中
会员
管理订单
从订单中删除某个订单项
扩展关系1
软 件 工 程
扩展关系2
软 件 工 程
将扩展用例的事件流在一定的条 件下按照相应的扩展点插入到基础 用例中。 基础用例不必知道扩展用例的 任何细节，它仅为其提供扩展点 扩展用例的行为是否被执行要 取决于主事件流中的判定点。
扩展关系3
软 件 工 程
用例粒度-4
如果确实是CRUD？
软 件 工 程
如果CRUD不涉及复杂的交互，一 个用例“管理××”即可 不管是C、R、U、D，都是为了完 管理用户 管理员 成“管理”目标 甚至很多种的基本数据管理都可以 用一个用例表示
用例粒度-5
灵活处理CRUD
软 件 工 程
管理员 管理用户
<<extend>>
识别用例---登录怎么处理？
软 件 工 程
会员 购物 <<include>> 登录 <<include>> 修改会员资料
识别用例---几个登录？
软 件 工 程
或
用例之间的关系
软 件 工 程
小结
软 件 工 程
理解需求 以用例为中心组织需求 基于用例的需求分析过程
获取原始需求 开发一个可以理解的需求
识别参与者 识别用例 确定关系
思考
软 件 工 程
基于用例的需求分析过程可大致分几步？ 什么是系统边界 用例的概念 用例的关系 参与者的定义与关系
ຫໍສະໝຸດ Baidu验06
软 件 工 程
画出系统用例图 注意用例的粒度与关系 描述一个用例的活动图
软 件 工 程
谢谢
软 件 工 程
用例分析 与用例图
回顾
需求工程的六个阶段
软 件 工 程
需求获取、需求分析与协商、系统 建模、需求规约、需求确认、需求 管理
需求分析的概念 需求的类型与怎样获取需求 需求分析过程 需求规格说明书（SRS）
主要内容
软 件 工 程
基于用例的分析与设计 业务用例与系统用例 用例与用例关系 小结与实验
增加用户 修改用户
×
查询用户
管理员
删除用户
用例粒度-3
“四轮马车”
软 件 工 程
C(Create) R(Read) U(Update) D(Delete)
所有业务最终会成为CRUD？ CRUD能为Actor提供价值？ CRUD掩盖业务，锐变成关系数据库的建模：
“系统就是数据的增删改查” 关心数据的存储和维护，反而忽略了用户的目的
前言之一
软 件 工 程
软件开发过程中常见的场景
这个做还不错，不过 好像不是我想要的。 我们这很混乱，你这 个系统应该把我们的 所有问题全部解决掉 ！ 你这做的是什么 东西！
“弱弱”地问：“您 到底想要什么？”
前言之二
软 需求分析与管理—软件开发过程中的“永远 件 的痛” 工 程
基于用例的分析与设计
会员 选择零件
设定查询条件
√
会员 检索零件
系统执行：结果值由系统生成
软 件 工 程
出纳员
吃饭
系统需要处理的，由系统生成
参与者观测：用户观点而非系统观点
软 件 工 程
订票 旅客 查看今日航班
处理订票
旅客 显示今日航班
用户观点
系统观点
用例粒度
软 件 工 程
用例要有路径，路径要有步骤； 而这一切都是可观测的 最常犯错误：粒度过细，陷入功 能分解
参与者的类型和职责
主要参与者
软 件 次要参与者 工 使用系统次要功能的执行者，或维护系统一般功 程 能的执行者
直接与系统交互的人，或执行系统主要功能的执 行者
外部硬件
作为系统一部分的、运行应用的非计算机的硬件
其他系统
为其工作需要与系统交互的外部系统
参与者之间的关系
软 件 工 程
增加用户
可以把包含复杂交互的路径独立出去形成用例
用例关系
Include
软 件 工 程
提取公共步骤，便于复用
Extend
分离扩展路径
Generalization
同一业务目的的不同技术实现
包含关系
软 件 工 程
<<include>>
下订单
提供客户信息
包含关系1
软 件 工 程
包含关系2
识别参与者
要点
软 件 工 程
系统外
参与者代表在系统边界之外的真实事 物，并不是系统的成分
系统边界
参与者透过系统边界直接与系统交互， 参与者的确定代表系统边界的确定
有意义交互的任何事物
人、外部系统、外部因素、时间
识别参与者思路
软 件 工 程
谁使用系统的主要功能 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务 谁负责日常维护、管理并保证系统正常运行 谁使用或删除系统中的信息 谁（或什么）对系统运行产生的结果（值）感兴趣 系统需要应付（处理）那些硬设备 系统需要和那些外部系统交互 在预定时间，是否有事件自动发生 时间、气温等内部外部条件 ……
用例的命名
执行者视角：
软 件 工 程
（状语）动词+（定语+ ）宾语
<<extend>> 付款 顾客 <<extend>> 支付宝支付 微信支付
识别用例
识别用例
软 件 工 程
关键词：价值 定义
用例实例是系统执行的一系列动作， 这些动作将生成特定参与者可观测的 结果值 一个用例定义一组用例实例（场景） 场景-----用例的实例 简洁：参与者使用系统达到目标
软 件 工 程 用一个带名称的矩形框，把描述系统功能的用 例都臵于其中，而描述的与系统交互的角色都 臵于其外 系统----完整系统或子系统 一个系统包括一个或多个用例
准确的定义系统的边界（功能）不是一件 很容易的事 先识别出系统的基本功能集，以此为基础 定义一个稳定的、精确定义的系统体系结构， 再不断地扩充系统功能，以逐步完善
基用例路径本身是完整的 可能是一条扩展路径 扩展路径步骤多 扩展路径内部还可以有扩展点－扩展之扩 展 扩展路径未定或容易变化－分离以“冻结” 基用例 基础用例可以单独存在，但在一定条件下， 他的行为可以被另一个用例作为扩展
扩展举例
软 件 工 程
泛化关系
同一业务目的不同技术实现：
软 件 工 程
一个用例可以泛化为另一个更普通 用例（更普通用例特化为特殊用例） UML 1.5: 用例间的泛化关系表明子 用例包含父用例中定义的所有属性、 行为序列和扩展点，并且参与父用例 中所有的关系
泛化
软 件 工 程
一个售货员可以终止任何交易，除了 那些需要特殊的售货员（高级代理） 终止的超过了一定限制的交易
系统用例
涉及范围是这个计算机系统涉及的范围 是一个系统参与者与计算机系统一起实现一个 目标 是参与者如何与计算机技术相联系，而不是业 务过程。
业务用例与系统用例
软 件 工 程
系统级
业务级（概要级 ）
华软校园ATM机系统用例模型
软 件 工 程
华软 特有 的业 务
用例与用例关系
软 件 工 程
软 件 工 程
某些步骤在多个用例重复出现，且单 独形成价值 用例步骤较多时，可用Include简化 当完全知道什么时间要调用用例时， 基用例需要包含用例所封装的逻辑 可以简单认为源代码中的函数调用或 操作调用
包含举例2
软 件 工 程
包含关系
软 件 工 程
扩展关系
软 件 工 程
<<extend>>
用例图 参与者 用例 用例关系
用例图
系统外部 系统内部
软 件 工 程
整车销售
获取需求、指导测试、对过 程中的其他工作流起指导作 用
参与者
参与者，Actor
软 件 工 程
关键词：边界 参与者：在系统之外，透 过系统边界与系统进行有意 义交互的任何事物
边界---Boundary
也叫系统边界，用于界定系统功能范围
软 件 工 程
以用例为中心组织需求
软 件 工 程
性能 界面约束 用例 硬件接口 …… 网络协议 业务规则 可用性 可靠性
基于UML的分析与设计
软 件 工 程
使用UML过程的基本特征是：用 例驱动，以体系结构为中心，反 复，渐增式。 用例包含了功能描述，它们将影 响后面所有阶段及视图。
结构模型视图
识别用例要点
软 件 工 程
可观测→用例止于系统边界 结果值→用例是有意义的目标 系统执行→结果值由系统生成 由参与者观测→业务语言、用户观 点 一组用例实例→用例的粒度
可观测：用例止于系统边界
软 件 工 程
系统
描述交互，而不是内在的系统活动
结果值：有意义的目标
业务功能，而非系统处理
软 件 工 程