《用例分析与用例图》.pptVIP

用例粒度 用例要有路径，路径要有步骤；而这一切都是可观测的 最常犯错误：粒度过细，陷入功能分解 过细的粒度，一般都会导致技术语言的描述，而不再是业务语言 用例粒度-1 把步骤当用例 把系统活动当用例 × √ × 用例粒度-2 × “四轮马车” C(Create) R(Read) U(Update) D(Delete) 所有业务最终会成为CRUD？ CRUD能为Actor提供价值？ CRUD掩盖业务，锐变成关系数据库的建模： “系统就是数据的增删改查” 关心数据的存储和维护，反而忽略了用户的目的 用例粒度-3 用例粒度-4 如果确实是CRUD？ 如果CRUD不涉及复杂的交互，一个用例“管理××”即可 不管是C、R、U、D，都是为了完成“管理”目标 甚至很多种的基本数据管理都可以用一个用例表示 用例粒度-5 灵活处理CRUD 可以把包含复杂交互的路径独立出去形成用例 用例关系 Include 提取公共步骤，便于复用 Extend 分离扩展路径 Generalization 同一业务目的的不同技术实现 包含关系 包含关系1 包含关系2 某些步骤在多个用例重复出现，且单独形成价值 用例步骤较多时，可用Include简化 当完全知道什么时间要调用用例时，基用例需要包含用例所封装的逻辑 可以简单认为源代码中的函数调用或操作调用 包含举例2 包含关系 扩展关系 扩展关系1 扩展关系2 将扩展用例的事件流在一定的条件下按照相应的扩展点插入到基础用例中。 基础用例不必知道扩展用例的任何细节，它仅为其提供扩展点 扩展用例的行为是否被执行要取决于主事件流中的判定点。 基用例路径本身是完整的 可能是一条扩展路径 扩展路径步骤多 扩展路径内部还可以有扩展点－扩展之扩展 扩展路径未定或容易变化－分离以“冻结”基用例 基础用例可以单独存在，但在一定条件下，他的行为可以被另一个用例作为扩展 扩展关系3 软 件 工 程 软 件 工 程 概 论 用例分析 与用例图 回顾 需求工程的六个阶段 需求获取、需求分析与协商、系统建模、需求规约、需求确认、需求管理 需求分析的概念 需求的类型与怎样获取需求 需求分析过程 需求规格说明书（SRS） 主要内容 基于用例的分析与设计 业务用例与系统用例 用例与用例关系 小结与实验 前言之一 软件开发过程中常见的场景 你这做的是什么东西！ 这个做还不错，不过好像不是我想要的。 我们这很混乱，你这个系统应该把我们的所有问题全部解决掉！ “弱弱”地问：“您到底想要什么？” 前言之二 需求分析与管理—软件开发过程中的“永远的痛” 基于用例的分析与设计 以用例为中心组织需求 用例 可用性 可靠性 网络协议 业务规则 …… 硬件接口 界面约束 性能 基于UML的分析与设计 使用UML过程的基本特征是：用例驱动，以体系结构为中心，反复，渐增式。 用例包含了功能描述，它们将影响后面所有阶段及视图。 用户视图 用例图 实现视图 结构视图 行为视图 环境视图 类图 对象图 顺序图 协作图 状态图 活动图 组件图 部署图 结构模型视图 业务用例与系统用例 业务用例： 业务过程是描述这个业务的具体工作流的 一次涉众与实现业务目标的业务之间的交互 它可能包含手工和自动化的过程 也可能发生在一个长期的时间段中 系统用例 涉及范围是这个计算机系统涉及的范围 是一个系统参与者与计算机系统一起实现一个目标 是参与者如何与计算机技术相联系，而不是业务过程。 业务用例与系统用例 业务级（概要级） 系统级 华软校园ATM机系统用例模型 华软特有的业务 用例与用例关系 用例图 参与者 用例 用例关系 用例图 获取需求、指导测试、对过程中的其他工作流起指导作用 系统内部 系统外部 整车销售 参与者 参与者，Actor 关键词：边界 参与者：在系统之外，透过系统边界与系统进行有意义交互的任何事物 边界---Boundary 也叫系统边界，用于界定系统功能范围 用一个带名称的矩形框，把描述系统功能的用例都置于其中，而描述的与系统交互的角色都置于其外 系统----完整系统或子系统 一个系统包括一个或多个用例 准确的定义系统的边界（功能）不是一件很容易的事 先识别出系统的基本功能集，以此为基础定义一个稳定的、精确定义的系统体系结构，再不断地扩充系统功能，以逐步完善 识别参与者 要点 系统外 参与者代表在系统边界之外的真实事物，并不是系统的成分 系统边界 参与者透过系统边界直接与系统交互，参与者的确定代表系统边界的确定 有意义交互的任何事物 人、外部系统、外部因素、时间 识别参与者思路 谁使用系统的主要功能 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务 谁负责日常维护、管理并保证系统正常运行 谁使