面向对象Part 2(4-8).ppt

用例图的书写格式 用例图的书写（参与者） 用例的扩展 用例的包含 用例驱动的开发计划 统一过程（UP）中用例驱动的开发方式 开发团队以完成一个或几个用例为目标。 系统用例和业务用例 系统用例是系统环境中的参与者及其目标 业务建模中使用业务用例 例如：收银员（系统）、顾客（业务）、供应商（业务） 初始阶段不需要写出所有用例 CH 7 其他需求 补充规范 跨越多个用例的规范性描述 其他种类的需求（非功能性） P78 7.4 7.5（读书） 构想 项目计划(背景、定位、市场、系统特性、约束条件） P82 7.6 7.7 （读书） 术语表 数据字典。原数据的说明和定义 CH 8 从初始到细化 初始阶段完成了什么 依据不同项目的主要需求 命名了大多数的参与者、目标和用例 用简短格式书写了大多数用例 风险需求（技术、进度、市场） 概念验证（关键风险技术可行性） 系统架构的构想 细化的工作计划 迭代计划 细化的工作计划 标准和规范 项目开发的规范 如何开发过程管理，如何提交制品？ 使用什么分析设计工具？ 迭代计划 风险驱动的 先做哪些？做到什么地步？ 用况驱动的 一个用况将被分配到哪几阶段的迭代中？ 开发计划 规范 文档书写规范：格式、发布手段等。 开发计划 迭代过程 开发计划 POS系统的迭代计划 需求分析工具RequestePro 需求分析工具RequestePro CH 4 项目初始阶段 特点 初试阶段信息并不充足 还没有项目的准备 需要尽快确定后续的工作 目标： 预见项目的范围、构想和业务案例 确定项目是否值得继续研究 工件（Artifacts）和文档 后续有用的工件 需要在后续迭代过程中进一步细化的工件 初始阶段的工件样例 构想和业务案例 用例模型 补充规范 术语表 风险列表和风险管理计划 原形和概念验证 迭代计划 阶段计划和软件开发计划 开发案例 CH 5 需求 软件项目中必需提供的能力和必需满足的约束 瀑布法的需求 在设计前弄清需求 统一过程的需求—进化式需求 逐步细化的需求 允许需求的变化 需求分析的活动 活动和工件 FURPS+需求类型 FURPS 功能性(Functional) 可用性(Usablity) 可靠性(Rliability) 性能(Performance) 可支持性(Supportability) + 辅助需求 实现(Implementation) 接口(Interface) 操作(Operation) 包装(Packaging) 授权(Legal) 功能需求和非功能性需求 功能需求 使用用例模型和系统特性表描述 非功能性需求 可以使用系统的补充规范描述 CH 6 用例模型 用例模型（Use Case Model）是描述系统功能和环境的模型 用例是最好的理解和描述需求的办法 用例：使用系统时的情况 抛开人机界面分析系统的功能需求 用例分析 参与者：具有行为能力的人或者计算机系统。（于系统打交道的事物）。 场景：参与者与系统进行的交互活动。 成功场景 失败场景 分析场景（用例分析） 怎么才能为用户实现他们的目标，为用户提供可观察的返回值。 避免罗列功能清单 黑箱用例和系统职责 系统应该做什么，而不是应该怎么做。 用例模型 用例的描述--使用文本文档描述的活动 辅助描述—UML的用例图 用于描述系统与环境(参与者)的语境 作为用例模型的引导 用例描述的一些准则 以无用户界面的风格编写 编写简洁用例 编写黑箱用例 从参与者的目标出发的编写 发现参与者、目标和用例 选择系统边界 找出参与者和目标 定义用例 选择系统边界 系统边界的不同，可能的参与者是不同的。 基本业务过程（EBP） EBP规则 以一个基本业务过程为单位来确定用例，就是基本业务过程级别的用例。 过高级别的定义无法清除的描述目标。 过低级别的定义不便于描述用户的真实意图和总体目标。 用例的类型和格式 摘要(简洁)用例 概要性的成功场景的文字描述。（例） 详述用例 详述用例的各个步骤和其中的变化，包括前置条件、扩展流程、变化情况、成功保障等。（例） 非正式(临时)用例 临时的描述部分场景。 处理销售的用例描述 主要参与者：收銀員 相关人员和利益： 收銀員：希望準確、快速的輸入方式，也不會發生付款錯誤的情形，因為收銀機抽屜如果短缺金額的話，要從他們的薪水裡扣。 銷售員：希望銷售佣金能（隨銷售）馬上更新。 顧客：希望買到商品、省時省力的快速服務。希望購買後保證能退貨。 公司：希望準確記錄交易，並且滿足顧客喜好。希望記錄付款授權服務的付款應收帳款。希望在無法獲得伺服器元件（例如遠端信用驗證）的情況下，也能容錯、繼續捕捉銷售紀錄。希望自動、快速更新會計與庫存紀錄。 政府稅務單位：希望收到每筆銷售稅金。賦稅單位可能