UML系统用例及用例关系教案.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 同一业务目的的不同技术实现 extend Extend include Include Generalization 包含关系1 包含关系2 包含关系 某些步骤在多个用例重复出现，且单独形成价值 用例步骤较多时，可用Include简化 当完全知道什么时间要调用用例时，基用例需要包含用例所封装的逻辑 可以简单认为源代码中的函数调用或操作调用 包含举例1 包含举例2 扩展关系1 扩展关系2 将扩展用例的事件流在一定的条件下按照相应的扩展点插入到基础用例中。 基础用例不必知道扩展用例的任何细节，它仅为其提供扩展点 扩展用例的行为是否被执行要取决于主事件流中的判定点。 扩展关系2 基用例路径本身是完整的 可能是一条扩展路径 扩展路径步骤多 扩展路径内部还可以有扩展点－扩展之扩展 扩展路径未定或容易变化－分离以“冻结”基用例 基础用例可以单独存在，但在一定条件下，他的行为可以被另一个用例作为扩展 扩展关系 用例图 * 系统的存在是因为：参与者有一些需要使用它来满足的目标 * 用户可以看见的，是由系统生成的 * * * * * * * 是include还是extend * CH4 用例图 系统用例及用例关系 统一建模语言 11软件工程 知识回顾—需求获取 需求工程 需求管理 需求开发 问题获取 分析 编写规格说明 验证 难点 重 点 掌握用例图模型元素 能够根据需求分析使用用例图建模 掌握用例图的地位作用及定义 确定用例及用例间的关系 教学目标 教学内容 用例图 什么叫用例图 用例图的构成要素 用例的重要元素 用例之间的各种重要关系 用例图建模应用 识别参与者 确定用例 用例建模 需求获取 需求获取及分析需求的基本方法 需求是客户在项目立项时就有的一个远景，客户需求将决定在整个项目中需求承办方具体做些什么，即承办方的任务。承办方在明确了需求后，就会开始后期的设计、开发、测试、部署等工作。 一 需求获取 Click to add title in here 4 问题引入 1 在需求获取过程中，主要需要弄清楚三个问题 一 需求获取 解答问题 2 明确需要获取的信息 明确所获取信息的来源和渠道 怎样获取需求 What Where How 二 用例图相关概念介绍 1. 什么是用例图 由参与者（Actor）、用例（Use Case）以及它们之间的关系构成的用于描述系统功能的动态视图称为用例图。 2. 用例图的作用 用例图是需求分析中的产物，主要作用是描述参与者和用例之间的关系，帮助开发人员可视化的了解系统的功能。 用例图可视化地表达了系统的需求，具有直观、规范等优点，克服了纯文字性说明的不足。 用例方法是完全从外部来定义系统功能，它把需求和设计完全的分离开来。 参与者，Actor 关键词：边界 参与者：在系统之外，透过系统边界与系统进行有意义交互的任何事物 识别参与者1 要点 系统外 参与者代表在系统边界之外的真实事物，并不是系统的成分 系统边界 参与者透过系统边界直接与系统交互，参与者的确定代表系统边界的确定 有意义交互的任何事物 人、外系统、外部因素、时间 识别参与者２ 识别参与者思路 谁使用系统的主要功能 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务 谁负责日常维护、管理并保证系统正常运行 谁使用或删除系统中的信息 谁（或什么）对系统运行产生的结果（