第5章 面向对象方法——RUP

RUP（Rational Unified Process）是一种面向对象的软件开发方法，由Rational Software（现在是IBM的一部分）开发并推广。

5.1 RUP的特点

5.1.1 RUP的突出特点

RUP的突出特点是，它是一种以用况为驱动的、以体系结构为中心的迭代、增量式开发。

(1)以用况为驱动 以用况为驱动是指在系统的生存周期中，以用况作为基础，驱动系统有关人员对所要建立系统的功能需求进行交流，驱动系统分析、设计、实现和测试等活动。

(2)以体系结构为中心 以体系结构为中心是指在系统的生存周期中，开发的任何阶段都要给出相关模型视角下有关体系结构的描述，作为构思、构造、管理和改善系统的主要标准。

(3)迭代、增量式开发 迭代、增量式开发是指通过开发活动的迭代，不断地产生相应的增量。在RUP中，规定了四个开发阶段：初始阶段、精化阶段、构造阶段和移交阶段。

5.1.2 初始阶段的基本目标

初始阶段的基本目标是：获得与特定用况和平台无关的系统体系结构轮廓，以此建立产品功能范围；编制初始的业务实例，从业务角度指出该项目的价值，减少项目主要的错误风险。

5.1.3 精化阶段的基本目标

精化阶段的基本目标是：通过捕获并描述系统的大部分需求，建立系统体系结构基线的第一个版本；到该阶段末，就能够估算成本、进度，并能详细地规划构造阶段。

5.1.4 构造阶段的基本目标

构造阶段的基本目标是：通过演化，形成最终的系统体系结构基线，开发完整的系统，确保产品可以开始向客户交付。

5.1.5 移交阶段的基本目标

移交阶段的基本目标是：确保有一个实在的产品发布给用户群。

5.2 核心工作流

5.2.1 RUP迭代中的核心工作流

在RUP的每次送代中都要经历一个核心工作流，即需求获取、分析,设计、实现和测试。

5.2.2 需求获取的基本步骤和相关制品

基本步骤	产生的制品
列出候选的特征	特征表
理解系统语境	领域模型或业务模型
捕获功能需求	用况模型
捕获非功能需求	补充需求或针对特殊需求的用况

5.2.3 业务用况模型和业务对象模型

(1)业务用况模型。业务用况模型是以用况图予以表达的，如下图所示。

图5-1业务用况模型

(2)业务对象模型。 为了精化业务用况模型中的每一个业务用况，RUP引入了三个术语，用于表达参与业务的业务对象：工作人员、业务实体和工作单元。业务对象模型可通过交互图和活动图予以表达。

5.2.4 标识用况应注意的问题

(1)建立用况的结构中，应尽可能反映用况的实际情况；

(2)在用况的结构化中，不论是施加什么结构，新引入的用况都不应该太小或太大；

(3)在建立用况的结构时，应尽量避免对用况模型中的用况功能进行分解；

5.2.5 需求分析层上的术语

(1)分析类是类的一种衍型,分为边界类、实体类和控制类。

(2)用况细化时一个协作，针对一个用况，其行为可用多个分析类之间的相互作用来细化，并记为用况细化。用况细化对用况模型中的一个特定的用况提供了一种直接跟踪的方式。

(3)分析包是一种控制信息组织复杂性的机制，提供了分析制品的一种组织手段。其主要特征为：体现问题的分离；高内聚、低耦合；尽可能体现一个系统的完整顶层设计，尽可能成为一些子系统或成为一些子系统的组成部分。

5.2.6 具有良好结构的分析包的特征

(1)体现问题分离。

(2)高内聚、低耦合。

(3)尽可能体现一个系统的完整顶层设计。

5.2.7 软件设计层上的术语

软件设计是定义满足需求规约所需要的软件结构。RUP为了满足系统/产品分析模型规约需求的软件结构，为设计层提供了四个术语：设计类、用况细化、设计子系统和接口，用于表达软件结构中的基本元素。

(1)设计类：一个设计类是对系统实现中一个类或类似构造的一个无缝抽象。

(2)用况细化：用况细化是设计模型中的一个协作，其中使用设计类及其对象，描述个特定用况是如何予以细化的，是如何执行的。

(3)设计子系统：设计子系统可以包含设计类、用况细化、接口，以及其他子系统，通过对其操作来显示其功能。

(4)接口：接口用于规约由设计类和设计子系统，必须提供与该接口操作对应的实现方法。

5.2.8 创建系统/产品用况模型的活动和任务

创建系统/产品用况模型需要的活动和任务如下 ：

(1)活动1：发现并描述参与者。 任务1：发现参与者，即直接发现一些候选的参与者。 任务2：描述参与者，即对参与者进行命名并描述。

(2)活动2：发现用况并对用况进行描述。 任务1：发现用况。 任务2：描述用况，即确定用况后对其进行描述。

(3)活动3：确定用况的优先级，目的是在寻找参与者并对其进行描述和发现用况，并对用况进行描述的基础上确定哪些用况适合在早期的迭代中开发，哪些适合在后期的迭代中开发。

(4)活动4：精化用况。这一活动的目的是详细描述出每一用况的事件流，包括用况是怎样开始的，是怎样结束的，是怎样与参与者进行交互的。最终形成一系列精化的用况。

(5)活动5：构造用户界面原型。这一活动的目的在于建造用户界面原型，使用户可以有效地执行用况。

(6)活动6：用况模型的结构化。进行用况模型的结构化要做以下工作。

①抽取用况描述中的那些一般性的和共享的功能并使用泛化关系标识和描述那些共享功能。

②抽取用况描述中附加的或可选的功能。

③标识用况之间的包含关系。通过用况模型的结构化，最终形成一个系统/产品的精化用户模型。

5.2.9 创建系统/产品需求分析模型的活动和任务

(1)活动1：体系结构分析。该活动的目标是通过标识分析包和分析类，建立分析模型和体系结构“骨架”，并标识有关分析包和分析类的特定需求。

任务1：标识分析包。该任务的基本输入是系统的用况模型。

任务2：处理分析包之间的共性。

任务3：标识服务包。

任务4：定义分析包的依赖，该任务的目标是发现相对独立的包，实现包的高内聚和低耦合。

任务5：标识重要的实体类，该任务的目标是标识在体系结构方面具有意义的实体类。

任务6：标识分析包和重要实体类的公共特定需求，该任务的目标是依据需求获取阶段所标识的非功能需求，针对在分析期间所标识的包和分析类，标识它们的一些公共的特定要求。

(2)活动2：用况分析。该活动的目标是：一是标识那些在用况事件流执行中所需要的分析类和对象；二是将用况的行为分布到参与交互的各个分析对象;三是捕获用况细化上的特定需求。

任务1：标识分析类，该任务的目标是标识在细化一个用况中所需要的实体类、控制类和边界类，给出它们的名字、责任、属性和关系。

任务2：描述分析类对象之间的交互。首先确定细化该用况所必要的交互，其次分派该用况的功能，最后根据其责任，发现该交互图中的各个链。

(3)活动3：类的分析。该活动的目标：一是标识并维护分析类的属性和关系；三是捕获分析类细化中的特殊需求。

任务1：标识责任，通过组合一个类在不同用况细化中所扮演的角色来完成。

任务2：标识属性。

任务3：标识关联和聚合。

(4)活动4：包的分析。该活动的目标是：一是确保分析包尽可能与其他包相对独立；二是确保分析包实现了它的目标；三是描述依赖，以益于可以估计未来的变化

5.2.10 创建系统/产品设计模型的活动和任务

创建系统产品设计模型的活动和任务如下：

(1)活动1：体系结构设计，该活动的目标是创建设计模型和部署模型，以及它们视角下的体系结构描述。

任务1：标识节点和它们的网络配置，网络配置通常使用一种三元模式：客户端、数据库功能、业务/应用逻辑。

任务2：标识子系统和它们的接口，目的是为了寻求一些复用的可能，而后随着设计模型的开发，在形成子系统结构中不断发现并演化。

任务3：标识在体系结构方面有意义的设计类和它们的接口。标识在体系结构方面有意义的设计类的基本思想是：初始可以依据在体系结构方面有意义的分析类来标识一些体系结构上具有重要意义的设计类。标识在系统体系结构方面有意义的设计类时，应注意主动类往往是一类在体系结构方面具有重要意义的类。

任务4：标识一般性的设计机制。其共性需求包括：永久性、透明对象的分布、安全特征、错误检测与揭示和事务管理等，这些共性需求是在分析期间有关用况细化分析中所标识的对设计类的特殊需求。

(2)活动2：用况的设计。其中分析模型的用况细化分析是活动的输入，对应输出用况细化设计。 为了实现用况设计的输入/输出，一般采用两种方法：

①标识参与用况细化的设计类。首先基于分析模型研究相应用况细化分析中的分析类，来标识为细化这些分类所需要的设计类，然后基于用况的功能对每一个标识的设计类赋予相应的责任，最后为该细化创建一个类图，汇聚参与该用况细化的设计类，并给出类之间的关系。

②标识参与用况细化的子系统和接口。

(3)活动3：类的设计。该活动的目标是完成用况细化设计中每一个类的角色设计，并完成有关每一类的非功能需求的设计。

任务1：概括描述设计类，该任务的输入为分析类/接口。

任务2：标识的操作，一般应依据分析类来标识设计类所提供的、所需要的操作，其中需要使用程序设计语言的语法来描述所标识的操作。

任务3：标识属性，该任务的目标是标识设计类所需要的属性，并使用程序设计语言的语法给出属性的描述。

任务4：标识关联和聚合。

任务5：标识泛化,基于分析模型中分析类之间的泛化，可以发现设计模型中的很多泛化。

任务6：描述方法，在设计期间一般用自然语言或适当的使用伪码对方法进行规约，但是在实现期间直接使用程序设计语言对方法进行规约。

任务7：描述状态，有些设计对象是受状态控制的，即它们的状态确定了它们接受一个消息的行为。在这种情况下，使用一个状态图描述一个对象的不同状态转移是有意义的。

(4)活动4：子系统的设计。该活动的目标是：确保子系统尽可能独立于其他子系统或它们的接口；确保子系统提供正确的接口；确保子系统实现了它的目标，即给出了该子系统提供的那些接口所定义的操作的细化。

5.2.11 设计模型包含的元素

RUP设计的主要结果是设计模型，它尽量保持该系统具有分析模型的结构，并作为系统实现的输入，包含以下四个元素。

(1)设计子系统和服务子系，,以及它们的接口、依赖和内容。

(2)设计类以及它们具有的操作、属性、关系及其实现的需求。

(3)用况细化设计。

(4)设计模型视角下的体系结构描述。

5.2.12 用况模型与分析模型的比较

用况模型与分析模型的比较如表5-1所示。 表5-1用况模型与分析模型的比较

用况模型	分析模型
使用客户语言来描述	使用开发者语言来描述
给出的是系统对外的视图	给出的是系统对内的视图
使用用况予以结构化，但给出的是外部视角下的系统结构	使用衍型类予以结构化,但给出的是内部视角下的系统结构
可以作为客户与开发者之间关于“系统应做什么,不应做什么”的契约	可以作为开发者理解系统如何勾画、如何设计和如何实现的基础
在需求之间可能存在一些冗余、不一致和冲突等问题	在需求之间不应存在冗余、不一致和冲突问题
捕获的是系统的功能，包括在体系结构方面具有意义的功能	给出的是细化的系统功能，包括在体系结构方面有意义的功能
定义了一些进一步需要在分析模型中予以分析的	定义了用况模型中每一个用况的细化

5.2.13 RUP测试活动

RUP的测试包括内部测试、中间测试和最终测试。

RUP测试活动:

输入	活动	输出
补充需求、用况模型、分析模型、设计模型、实现模型、体系结构描述	计划测试	测试计划
补充需求、用况模型、分析模型、设计模型、实现模型、体系结构描述、测试计划	设计测试	测试用况，测试过程
测试用况、测试过程、实现模型	实现测试	测试构件
测试用况、测试过程、测试构件、实现模型	执行集成测试	缺陷
测试用况、测试过程、测试构件、实现模型	执行系统测试	缺陷
测试计划、测试模型、缺陷	评价测试	测试评价

前5章的汇总

本人能力有限，文中内容难免有纰漏，真诚欢迎大家斧正~

喜欢本文的朋友请三连哦！！！

另外本文也参考了网络上其他优秀博主的观点和实例，这里虽不能一一列举但内心属实感谢无私分享知识的每一位原创作者。