第九章 RUP

CONTENTS

m 1. 软件过程

Ø 问题

Ø 定义

Ø 含义

Ø 过程结构

m 2. 统一软件过程

Ø 特点

Ø 实践过程

Ø 过程模型

软件过程问题的提出

m 以软件开发中使用 的方法、技术、 工具和环境为基础的思维方式是软件过程的基本雏形

m 20 世纪 70 年代 —— 进入工程化轨道

m 20 世纪 80 年代 —— 软件过程框架提出

m 1984 年 10 月 —— 正式提出软件过程概念

m 90 年代 —— 得到发展

软件过程的定义

ISO和IEEE指出：

m 软件过程也称软件生命周期过程或软件过程组，是指软件生存周期中的一 系列相关过程。

m 过程就是活动 的集合。

m 活动是任务的集合。

m 任务则起到把输入加工成输出的作用。活动的执行可以是顺序的 、迭代的、并行的、嵌套的或者是有条件地引发的。

过程的含义

m 个体含义：指软件或 系统在生存周期中某一类 活动的集合．如获取过程、供应过程、 开发过程、管理过程。

m 整体含义：指软件或系统在上述含义下软件过程 的总体。

m 工程含义：应用软件工程的原则 、方法来构造 软件过程模型，实例化后，在用户环境下运作，提高软件开发效率。

软件过程的结构

RUP简介

m RUP 是 Rational 软件公司开发的一种软件过程工程．

m RUP 提供了如何在软件开发组织中严格分配任务和职责的方法．

m RUP 是一个营销的软件过程产品 (Process Product) .

m RUP 有规范的过程框架 （ Process framework)

m RUP 的目标是：按照制定的时间计划和经费预算，开发高质量的软件产品，满足最终用户需求．

m 统一过程 RUP 的应用是广泛的． 可用于

Ø 各种不同类型的软件系统、

Ø 各种不同的应用领域、

Ø 各种不同类型的组织、

Ø 各种不同的功能级别 、

Ø 各种不同的项目规模．

RUP特点

m 用例驱动

Ø 传统的系统动能：“系统能做什么”

Ø RUP ：“系统能为每个用户做什么”

m 以架构为中心

软件构架刻画了系统的整体设计，包含了系统中最重要的静态和动态特征。

构架和用例并行进行，用例在实现时必须适合于构架，构架必须预留空间以实现现在或将来所有需要的用例。

m 迭代式、增量式

       迭代是指工作流中的步骤

       增量是指产品中增加的部分

       迭代是按计划好的步骤有选择地执行

       首先，迭代过程要处理一组用例，这些用例合起来能够扩展所开发产品的可用性．

      其次，迭代过程要解决最突出的风险问题．后继的迭代过程建立在前一次迭代末期所开发的制品之上．

       一个增量不一定是对原有制品的增加，也可以用更加详细和完善的设计代替初始简单设计．

m 风险驱动

Ø 减小对项目成功、预算、进度造成危害的严重风险．

m 基于构件

Ø 重用构造块减少成本，提高质量．

RUP实践活动

m (1 ） 迭代式的软件开发

m (2 ） 管理需求

m (3 ） 应用基于构件的架构

m (4 ） 为软件建立可视化模型

m (5 ） 不断的验证软件的质量

m (6 ） 控制软件的变更

（ 1 ）迭代式的软件开发

迭代式的软件开发，提供了一系列解决软件开发根本问题的方案：

Ø 得到一个健壮的构架．

Ø 早期发现对需求理解的严重错误，并及时修改．处理不断变化的需求．

Ø 鼓励用户反馈信息，获取真实需求．

Ø 降低或屏敝风险，重视项目中最关键问题．

Ø 及时发现需求、设计、实现的不一致．

Ø 实现持续集成

Ø 迭代测试，对项目客观评价，合理改进、合理分配、调整工作量

（2）管理需求

需求是系统必须达到的条件和性能．

管理需求解决软件开发根本问题的方法是：

Ø 规定原则性方法．

Ø 对功能、性能客观评价．发现需求不一致

Ø 区分优先级．

Ø 管理需求变更．特别是动态需求管理（提取、过滤、跟踪、评估 、记录、权衡、决定需求）

（3）应用基于构件的架构

m 构件 （ Component )

       是软件、模块、包或子系统的一个重要部分．是概要设计在物理上的实现．

m 架构

       关注结构和行为 、用途、功能、性能、 弹性、重用 、综合性、经济性、技术限制的权衡．

m 基于构件的开发

       从成百上千的商业运作上可获得的资源中找到可重用或可客户化的构件.

m 基于构件的开发解决软件开发根本问题的方案：

Ø 创建有弹性的构架

Ø 关注系统中易改变的元素 , 为自配置管理提供了基础．

Ø 有可视化开发工具支持．

Ø 使用标准化构架提高重用。如微软的 COM,OMG 的 CORBA ， SUN 公司的 EJB ．

（ 4 ）为软件建立可视化模型

m 可视化建模提供的解决软件开发根本问题的方案

Ø 通过用例和情景可以无二义性地详细说明行为．

Ø 通过模型可以无二义性地理解软件设计，揭示不一致性．

Ø 可以暴露非模型和不灵活性．

（ 5 ）不断验证软件的质量

m 验证软件质量提供的解决软件开发根本问题的方案：

Ø 验证可揭示需求、设计、实现的不一致性 .

Ø 将注意力集中在高风险问题上．

Ø 提早发现缺陷，降低修改软件费用．

Ø 通过验证、测试客观评价测试数据．

（ 6 ）控制软件的变更

m 提供的解决软件开发根本问题的方案：

Ø 变更请求和促进交流．

Ø 变更率为客观，评价项目状况，提供了很好的度量．

Ø 及时定义需求变史的工作流．

RUP模型

m 四种模型元素

Ø WHO

Ø WHAT

Ø HOW

Ø WHEN

m 谁做 —— 工作人员（行为、职责、角色）

    如：

        系统分析员：概述系统功能、边界，引发和协调需求，用例建模。

        设计师：定义一个或多个类，调整类适应实现环境

        测试工程师：制定测试计划、产生设计模型、设计、实现、评估测试

m 做什么 —— 制品（ artifact ）

    是工作人员的责任，一个人可拥有该制品，其他人使用该制品。

    制品的几种形式：

  模型

  模型元素

  文档

  源代码

  可执行文件

m （ 3 ）怎么做 —— 活动（ activity ）

       工作人员执行工作，思考步骤、 执行步骤、评审步骤．如：

       项目经理活动：计划 、迭代过程

       分析员活动：寻找用例、参与者、设计

       评审员活动：评审设计．

m （ 4 ）什么时候做 —— 工作流

m 表示能够产生出有用成果的有重要意义的活动序列 。（工作流与活动、工作人员密切关联）

m 核心工作流

Ø 业务建模

Ø 需求

Ø 分析设计

Ø 实现

Ø 测试

Ø 部署

m 支持工作流

Ø 配置变更管理

Ø 项目管理

Ø 环境管理

m 四个阶段（ phase ）

Ø 起始阶段（ inception ）

Ø 细化阶段（ elaboration ）

Ø 构造阶段（ construction ）

Ø 移交阶段（ transition ）

每个阶段可以进一步分解为迭代

例：ATM系统

m 参与者 “银行储户 ” 使用 ATM 从账户中取款或存款到账户中，或在不同的账户间转账

m 取款用例

(1）银行储户表明自己的身份

(2）银行储户选择从哪个账户取款，确定取款金额

(3）系统从账户上减掉该数量的金额，发给该储户相应金额的现金

m 分析类的结构

m 用协作图描述用例的实现

m 设计模型的设计类跟踪到分析模型的分析类

m 设计模型中部分实现“取款”用例的类图

m 取款用例的顺序图

m 按子系统对类分组

m 实现设计类的构件

m 根据用例确定测试用例

m 测试用例

m 部署视图