ch6补充-面向对象的分析.pptVIP

用例：用户观点而非系统观点 用例 VS. 功能 用例的命名 执行者视角： （状语）动词+（定语+ ）宾语 参与者的泛化 用例干什么？ 扩展 VS. 包含 包含：由用例A连向用例B，表示用例A中使用了用例B中的行为或功能 扩展：由用例B连向用例A，表示用例A描述了一项基本需求，而用例B则描述了该基本需求的特殊情况，即一种扩展 扩展用例的目的是在不改变某个已存在（或假定存在）的用例的前提下为之增添新行为 这些附加的行为可能是必需的，也可能是可选的 扩展 VS. 包含 用例粒度 要点：用例粒度-1 用例要有路径，路径要有步骤；而这一切都是可观测的 最常犯错误：粒度过细，陷入功能分解 过细的粒度，一般都会导致技术语言的描述，而不再是业务语言 用例粒度-2 把步骤当用例 把系统活动当用例 用例粒度-3 “四轮马车” C(Create)R(Read)U(Update)D(Delete) 所有业务最终对会成为CRUD？ CRUD能为Actor提供价值？ CRUD掩盖业务，锐变成关系数据库的建模： “系统就是数据的增删改查” 关心数据的存储和维护，反而忽略了用户的目的 用例粒度-4 如果确实是CRUD？ 如果CRUD不涉及复杂的交互，一个用例“管理××”即可 不管是C、R、U、D，都是为了完成“管理”目标 甚至很多种的基本数据管理都可以用一个用例表示 用例粒度-5 灵活处理CRUD 用例分析 用例分析的一般方法： 案例——个人图书管理系统 记录需求——特性表： 已有的上下文关系图（表示系统范围）及其他相关模型：它们描述了系统与外部系统的边界，从这些图中可以寻找出与系统有交互关系的外部实体。 项目相关人员分析：对项目的相关人员进行分析，就能够决定出哪些人将会与系统进行交互 书面的规格说明和其他项目文档（如会议备忘录等） 需求研讨会和联合应用开发会议的记录：这些会议的参与者通常是很重要的，因为他们在组织中所代表的角色就是可能与系统发生交互的参与者 当前过程和系统的培训指南及用户手册：这些东西中经常会有潜在参与者 得到用例 合并需求获得用例： 得到用例 合并需求获得用例（续）： 用例图 绘制用例图： 用例说明（用例描述） 细化用例描述——搭框架： 用例说明（用例描述） 细化用例描述——填血肉： * 用户观点 系统观点 呼叫某人 接听电话 发送短信 记住电话号码 …… 传输/接收 电源/基站 输入输出（显示、键盘） 电话簿管理 …… 用户观点 系统观点 参与者泛化：特化的参与者会继承泛化参与者所有的要素！ 外围系统表示是已有的或计划中的外围的独立的软件系统！ 使用英文时注意单词的正确用法！ “其他”、“打印清单”用例和外围没有任何有意义交互，和其他用例也没有任何关系，这样的用例有意义吗？ “其他”用例又代表什么呢？想说明什么样的功能需求？ 老大知道老二 老二知道老大 什么时候该我上场呢？不知道！ 出现这种情况，就该我上场了！ 注意“管理用例”的使用！ 可以把包含复杂交互的路径独立出去形成用例 ① 捕获需求。 ② 确定系统的边界范围，找出系统外部的参与者和外部系统。 ③ 确定每一个参与者所希望的系统行为，命名用例。 ④ 把公共系统行为分解为新用例，供其他用例引用。 ⑤ 把一些变更的行为分解为扩展用例。 ⑥ 编制用例说明。 ⑦ 绘制用例图。 ⑧ 把特殊情况的用例画成单独的子用例图。 识别参与者： 识别参与者 使用时，直接删除本页！ 精品课件，你值得拥有！ 精品课件，你值得拥有！ 使用时，直接删除本页！ 精品课件，你值得拥有！ 精品课件，你值得拥有！ 使用时，直接删除本页！ 精品课件，你值得拥有！ 精品课件，你值得拥有！ * * *