面向对象设计过程UP.ppt

软件工程 第十一讲 面向对象设计过程 - UP 朱建凯,上节课思考题：,有没有可能在分析模型创建之后立即开始编码？,本次课程学习要求,UML和UP之间的关系（重要） UP 的本质和特点（非常重要） UP 的四个阶段（重要） UP 的六个基本过程（重要） UP 的六个优秀实践（了解）,第七章 统一软件过程(UP) 7.1 UP的作用和特点 (1) UML是一种可视化的建模语言，而不是一种特定的软件开发方法学。作为一种软件开发方法学，为了支持软件开发活动，例如软件设计，至少涉及三方面的内容：一是应定义设计抽象层，即给出该层的一些术语，二是应给出该层的模型表达工具，三是应给出如何把需求层的模型映射为设计层的模型，即过程。UML仅包括前两方面的内容，即给出了一些可用于定义软件开发各抽象层的术语（符号），给出了各层表达模型的工具。,(2) UP的本质及特点 本质: 是“一般的过程框架 ” . 即: -为软件开发，进行不同抽象层之间“映射”，安排其开发活动的次序，指定任务和需要开发的制品，提供了指导； -为对项目中的制品和活动进行监控与度量，提供了相应的准则。 换言之，UP比较完整地定义了将用户需求转换成产品所需要的活动集，并提供了活动指南以及对产生相关文档的要求。 适用于：大多数软件系统的开发，涉及 -不同应用领域 -不同类型的组织 -不同的技能水平 -不同的项目规模 可见, UP 和UML 是“统一”的方法学。,UP的突出特点 是一种以用况（Use Case）为驱动的、以体系结构为中心的、迭代、增量式开发。 以用况为驱动 意指在系统的生存周期中， 以用况作为基础，驱动有关 人员对所要建立系统之功能 需求进行交流，驱动系统分 析、设计、实现和测试等活 动，包括制定计划、分配任 务、监控执行和进行测试等， 并将它们有机地组合为一体， 使各个阶段中都可以回溯到 用户的实际需求。,USE CASE,分 析,输入,设 计,实 现,跟踪,输入,跟踪,输入,跟踪,输入,输入,测 试,输入,跟踪,输入,从USE CASE模型的视觉,从分析模型的视觉,从设计模型的视觉,从实现模型的视觉,从部署模型的视觉,给 出,体 系 结 构,描 述,以体系结构为中心 意指在系统的生存周期中，开发的任何阶段（UP规定了四个阶段，即初始阶段、细化阶段、构造阶段和移交阶段）都要给出相关模型视角下的有关体系结构的描述，作为构思、构造、管理和改善系统的主要制品。,（3） UP的基本结构,软件开发模型的出发点 如何更快（效率）更好（质量）地满足需求 使得开发过程在一种受控的方式下运行 过程活动任务 还需要涉及：项目、人员、工件 UP（Unified Process）是一个软件开发过程的框架 拥抱变化：用户反馈和适应调整逐步满足用户需求； 迭代增量式开发 用例驱动整个开发过程 提倡基于构件的软件体系结构为中心展开开发活动,（4）RUP 的四个阶段,初始阶段（Inception） 不是需求分析，而是可行性分析 细化阶段（Elaboration） 不是需求分析或设计过程，而是迭代式实现核心体系结构，缓解高风险问题 构造阶段（Construction） 实现遗留下来的风险较低和比较容易的元素，准备部署 移交阶段（Transition） beta测试，部署,每一个阶段都由一个或多个连续的迭代组成，迭代并不是重复做相同的事，而是针对不同用例的细化和实现。每一次迭代都是一个完整的开发过程。,1. 初始阶段,初始阶段所要进行如下的活动： 明确说明项目规模，了解环境以及最重要的需求和约束，以便可以得出最终产品的验收标准。 计划和准备商业理由。评估风险管理、人员配备、项目计划以及成本/进度/收益折衷的被选方案。 综合考虑被选构架，评估构架。 准备项目的环境，评估项目和组织，选择工具，决定流程中要改进的部分。,初始阶段的评估标准如下： 出资人同意系统范围定义以及费用和进度评估。 主要用例是否符合需求。 费用和进度评估、优先级、风险以及开发过程的可信性。 任何已开发的原型的深度和广度。 实际开销与计划开销。 初始阶段的焦点是需求和分析工作流。,2. 细化阶段,细化阶段的评估标准如下： 标明用例模型中的用户和参与者，并且建立用例的描述文档。用例模型需完成80。 创建软件系统开发过程中的软件结构的描述文档。 创建可执行的系统原型。 细化商业案例和风险列表。 创建整个项目的开发计划。 细化阶段的焦点是需求、分析和设计工作流。,3. 构造阶段,构造阶段的主要目标如下： 优化资源、避免不必要的报废和返工，使开发成本降到最低。 尽快达到质量的要求。 快速完成有用的版本，例如Alpha 版、Beta 版和其他测试发布版。 完成所有功能的分析、开发和测试。 迭代式、递增地开发随时可以发布的产品。 确定准备好软件系统的外部环境。 构建阶段的焦点是实现工作流。,4. 交付阶段,交付阶段的主要目标如下： 进行Beta版测试，按用户的要求验证新系统。 替换旧的系统。 对用户和维护人员进行培训。 开始调整活动，例如调试、性能或可用性的增强。 与用户达成共识，配置基线与评估标准一致。 交付阶段的焦点是实现和测试工作流。,（5） 核心工作流,软件开发流程定义了“谁”、“何时”、“如何”做“某事”。四种主要的建模元素被用来表达： 角色（worker）“谁” 活动（activity）“如何” 工件（artifact）“某事” 工作流（workflow，discipline） “何时”,（5） 核心工作流,工作流是产生具有可观察结果的活动序列,（5） 核心工作流（商业建模工作流）,商业建模 大多数商业工程化的主要问题是软件工程人员和商业工程人员之间不能正确地交流，这导致了商业工程的产出没有作为软件开发输入而正确地被使用，反之亦然。 在商业建模中使用商业用例来文档化商业过程，从而确保了组织中所有商业过程人员达到共识。 商业用例被分析以理解商业过程如何被业务支持，而这些在商业对象模型中被核实。 许多项目可能不进行商业建模。,（5） 核心工作流（需求捕获工作流）,需求 是描述系统应“做什么”，并允许开发人员和用户就该描述达成共识。 创建构想 建立用例模型 识别actor 识别use case 描述use case 其他功能和非功能性需求在补充规范中说明。,Use case起到贯穿整个系统的开发周期线索的作用，相同的用例模型在需求捕获阶段、分析/设计阶段和测试阶段中使用。,在需求捕获工作流，主要的UML制品： 用例模型（Use Case Model） 参与者（Actor） 用例（Use Case） 构架描述 术语表（Glossary） 用户界面原型,参与需求捕获阶段的工作人员： 系统分析人员（System Analyst） 用例描述人员（Use Case Specifier） 用户界面设计人员（User Interface Designer） 构架设计师（Architect）,需求捕获的工作流主要包括五个活动： 确定参与者和用例 区分用例的优先级 详细描述一个用例 构造用户界面原型 构造用例模型,（5） 核心工作流（分析和设计工作流）,分析和设计 显示系统“如何”在实现阶段被实现的，达到下列目标： 在特定的实现环境中完成用例描述中指定的任务和功能 满足了所有的需求 健壮地被建造（如果功能需求发生变化易于更改） 分析设计结果是一个设计模型和可选的分析模型： 设计模型由设计类和一些描述组成： 设计类被组织成具有良好接口的设计包和设计子系统 描述则体现了类的对象如何协同工作实现用例的功能 设计模型是源代码的抽象 设计活动以体系结构设计为中心,在分析工作流期间，主要的UML制品： 分析模型 分析类 用例实现（分析） 分析包 构架模型 在分析工作流期间，主要的UML制品： 设计模型 设计类 用例实现-设计 设计子系统 接口 配置图,在分析工作流期间，所参与的工作人员： 构架设计师 用例工程师 构件工程师 参与设计工作流的工作人员包括： 构架设计师 用例工程师 构件工程师,分析工作流主要包括四个活动： 构架分析 分析用例 分析类 分析包 设计工作流中，主要包括四种活动： 构架设计 设计用例 设计类 设计子系统,（5） 核心工作流（实现工作流）,实现 目的： 定义代码的组织结构以层次化方式组织实施子系统； 实现类和对象以构件的形式（源文件、二进制文件、可执行文件等）； 将开发出的构件作为单元进行测试； 将由单个实现者或小组产生的结构集成为可执行的系统。,在实现工作流中，主要有六种制品： 实现模型 组件 实现子系统 接口 构架描述（实现模型） 集成构造计划,参与实现工作流的工作人员： 构架设计师 构件工程师 系统集成人员,在实现工作流中，包括一系列活动： 构架实现 系统集成 实现子系统 实现类 执行单元测试,（5） 核心工作流（测试工作流）,测试 目的 验证对象间的交互作用； 验证软件构件的正确集成； 验证所有需求被正确的实现； 识别并确保在软件发布之前缺陷被处理。,UP提出了迭代的方法，意味着在整个项目中进行测试，从而允许尽可能早地发现缺陷，从根本上降低了修改缺陷的成本； 测试生命周期的几个阶段：计划、设计、实现、执行和审核。,测试工作流中，包括七个制品： 测试模型 测试用例 测试规程 测试组件 制定测试计划 缺陷 评估测试,参与测试工作流的工作人员主要有四类： 测试设计人员 构件工程师 集成测试人员 系统测试人员,在测试工作流中，包括六种活动： 制定测试计划 设计测试 实现测试 执行集成测试 执行系统测试 评估测试,（5） 核心工作流（发布工作流）,发布 目标是成功地生成版本，将软件分发给最终用户。包含的活动： 生成软件本身外的产品； 软件打包 安装软件 给用户提供帮助 许多情况下还包括如下的活动 计划和进行测试版 移植现有的软件或数据 正式验收,（5） 核心工作流（配置和变更管理）,配置和变更管理 完成建立并管理基线的任务。 基线：已经通过正式复审和批准的某规约或产品，它因此可以作为进一步开发的基础，并且只能通过正式的变更控制过程进行改变。 配置项：置于配置和变更管理控制之下的工件。 提供了管理系统演化中的多个变体、跟踪软件版本的准则； 描述了如何管理并行开发、分布式开发，如何自动化创建工程； 涵盖了需求变更管理，即：如何报告缺陷？如何管理缺陷？及如何使用缺陷来跟踪进展和发展的倾向？,（5） 核心工作流（项目管理、环境）,项目管理 集中在迭代开发过程的组织管理方面 目标是提供以下的事物来使该任务更简单： 管理项目的框架； 计划、配备、执行、监控项目的实践准则； 管理风险的框架。 环境 目的是给软件开发组织提供软件开发环境（过程和工具），软件开发队伍需要它们的支持； 集中在项目环境中配置过程的活动，同样着重支持项目的开发规范的活动，提供了逐步指导手册，介绍了如何在组织中实现过程； 还包含了定制流程所必须的准则、模板、工具的开发工具箱。,（6） RUP 六个最佳开发经验,迭代式开发（develop software iteratively） 管理需求（manage requirements） 使用基于构件的体系结构（use component-based architectures) 可视化软件建模（visually model software) 验证软件质量（verify software quality） 控制软件变更（control changes to software),1）迭代式开发,瀑布式软件开发的不足 需求在软件开发过程中可能会经常改变，迭代式开发允许在每次迭代过程中需求都可以有变化，通过不断细化来加深对问题的理解。 迭代式开发通过可验证的方法来帮助降低风险。,迭代开发优点：,早期解决缓解高风险(技术，需求，目标，可用性等方面) 早期可见的进程 早期反馈 可管理的复杂性，不必陷入长而复杂的分析过程,迭代长度：26周,太短则难以获得有意义的成果和反馈 超过6到8周则太复杂、反馈延迟、增加项目风险 若下一迭代周期为4周，则必须在4周内完成集成、测试。完不成则将任务和需求移到下一周期，而不是将完成时间后移 大型开发团队（上百人）才可例外（但仍不超过36个月）,2）管理需求,在软件开发过程中，需求会不断发生变化。确定系统的需求是一个连续的过程，除了一些小系统之外，开发人员在开发系统之前不可能完全详细地说明一个系统的真正需求。 UP描述了如何提取、组织系统的功能和约束条件并将其文档化，用例和脚本的使用已被证明是捕获功能性需求的有效方法。,3）使用基于构件的体系结构,基于构件的开发是非常有效的软件开发方法，构件使重用成为可能，系统可以由已存在的、由第三方开发商提供的构件组成。 RUP描述了如何设计一个有弹性的、能适应变化的、直观上易于理解的、有助于软件重用的软件体系结构。,4）可视化软件建模,可视化建模提高人们管理软件复杂度的能力。 帮助更好地理解问题、加强人员沟通、更早发现错误、获得设计结果并为代码生成