OO过程以及.ppt

OO过程以及 UML的应用 软件生命周期（开发周期） 迭代式开发 先启 主要目标: 建立项目的软件规模和边界条件，包括运作前景、验收标准以及希望产品中包括和不包括的内容 识别系统的关键用例 对比一些主要场景，展示至少一个备选构架 评估整个项目的总体成本和进度 评估潜在的风险（源于各种不可预测因素） 准备项目的支持环境 精化 主要目标 确保构架、需求和计划足够稳定，充分减少风险，从而能够有预见性地确定完成开发所需的成本和进度 处理在构架方面具有重要意义的所有项目风险 建立一个已确定基线的构架 制作产品质量构件的演进式原型 证明已建立基线的构架将在适当时间、以合理的成本支持系统需求 建立支持环境（创建开发案例、创建模板和指南、安装工具） 构建 主要目标 完成所有所需功能的分析、开发和测试 迭代式、递增式地开发 为部署应用程序作好准备 产品化 主要目标 确保最终用户可以使用软件 培训用户和维护人员 根据产品的完整前景和验收标准，对部署基线进行的评估 面向对象开发过程 业务建模 需求 分析 设计 构建 测试 部署 业务建模 对业务进行可视化建模的所有建模方法 业务建模的目的 了解客户组织的结构及运转机制 了解客户组织中当前存在的问题并确定改进的可能性? 业务流程重组 确保客户、最终用户和开发人员就目标组织达成共识 导出支持目标组织所需的系统需求 需求 成果 组织结构视图 - 概述业务中的关键角色和职责以及他们的分组情况。 业务流程视图 - 包括业务的关键业务流程并对其进行概述，这些流程是业务存在的原因。? 文化视图 - 表述对组织文化前景的设想，并定义为促进该文化而应用的机制。? 人力资源状况视图 - 讨论为维持和发展公司职员的技能而应用的机制。? 领域视图（可选） - 对于处理结构复杂信息的组织，通常需要定义应用于这些信息结构的关键机制和模式。在简单的情况下，组织结构视图中可能已经清楚地表示了领域视图。? “4+1”视图 需求 什么是需求 需求是指系统必须符合的条件或具备的功能 功能性：系统无需考虑物理约束而必须能够执行的动作 非功能性 可用性 可靠性 性能 可支持性 设计约束 实施需求 接口需求 物理需求 需求工作流程的目的 与客户和其他涉众在系统的工作内容方面达成并保持一致。 定义系统的用户界面，重点是用户的需要和目标 使系统开发人员能够更清楚地了解系统需求。 定义系统边界（限定） 为计划迭代的技术内容提供基础。 为估算开发系统所需成本和时间提供基础。 需求工作流程 查找主角（Actor） 查找用例（Use Case） 编写用例规约（Use Case Specification） 主角Actor 主角实例是指在系统外部与系统进行交互的人或物。 主角类定义一个主角实例集，其中的各个主角实例在系统中都担任同一角色。 查找主角Actor 与系统交互的用户 与系统交互的外部系统 与系统交互的外部硬件 特别注意：有些时候时间触发器也可看作主角 记录主角Actor 名称 应明确表示主角的角色，确保在以后不会对主角的名称产生混淆。 简要说明 所代表的对象,为何需要,在系统中能获得哪些利益 特征 职责、数量、环境、使用系统的频率、领域知识水平、计算机水平、使用的其它应用程序 主角的UML表示 主角之间的关系 泛化关系 用户与主角之间的关系 一个用户可以抽象为多个主角 张三 ? 教师 学生 一个主角可以包含多个用户 教师 ? 张三 李四 主角与系统边界的关系 图书馆管理信息系统中的主角 用例Use Case 用例实例是系统执行的一系列动作，这些动作将生成特定主角可观测的结果值。 一个用例定义一组用例实例。 用例的UML表示 查找用例Use Case 从每个Actor出发，考虑： 主角希望系统执行的主要任务是什么？ 主角是否将在系统中创建、存储、更改、删除或读取数据？ 主角是否需要将突发变更或外部变更通知给系统？ 是否需要将系统中发生的某些特定事件通知给此主角？ 此主角是否将执行系统启动或关闭操作？ 说明用例Use Case 名称 简要说明 事件流 前置条件 是对用例何时开始的约束，而不是使用例开始的事件 后置条件 用例应该实现什么 扩展点 一个名称和一系列对事件流中一个或多个位置的引用 说明用例Use Case-事件流 说明用例如何开始和结束。 说明在主角和用例之间交换的是什么数据。 说明事件流，而不只是功能，每个动作都应从“当主角... 时”开始。 只说明属于该用例的事件，而不是发生在其他用例中或系统外部的事件。 避免不明确的术语，如“例如”、“等等”和“信息”。 详细说明事件流，即回答所有包含“什么”的问题。 说明系统要做什么，而不是系统怎样做。 说明用例Use Case-事件流