Rational Unified Process 软件工程新方法.docx

Rational Unified Process 软件工程新方法.docx

《Rational Unified Process 软件工程新方法.docx》由会员分享，可在线阅读，更多相关《Rational Unified Process 软件工程新方法.docx（7页珍藏版）》请在冰豆网上搜索。

RationalUnifiedProcess软件工程新方法

RationalUnifiedProcess软件工程新方法

　　RationalUnifiedProcess（以下简称RUP）是一套软件工程方法，主要由IvarJacobson的TheObjectoryApproch和TheRationalApproch发展而来。

同时，它又是文档化的软件工程产品，所有RUP的实施细节及方法导引均以Web文档的方式集成在一张光盘上，由Rational公司开发、维护并销售，当前版本是5.0。

RUP又是一套软件工程方法的框架，各个组织可根据自身的实际情况，以及项目规模对RUP进行裁剪和修改，以制定出合乎需要的软件工程过程。

　　RUP吸收了多种开发模型的优点，具有很好的可操作性和实用性。

从它一推出市场，凭借Booch、IvarJacobson、以及Rumbagh在业界的领导地位以及与统一建模语言（UnifiedModelLanguage,以下简称UML）的良好集成、多种CASE工具的支持、不断的升级与维护，迅速得到业界广泛的认同，越来越多的组织以它作为软件开发模型框架。

二维的软件开发模型

　　传统的软件开发模型瀑布式开发模型是一个单维的模型，开发工作划分为多个连续的阶段。

在一个时间段内，只能作某一个阶段的工作比如，分析、设计或者实现。

　　在RUP中，软件开发生生命周期根据时间和RUP的核心工作流划分为二维空间。

　　如下图所示，时间维从组织管理的角度描述整个软件开发生命周期，是RUP的动态组成部分。

它可进一步描述为周期（Cycle）、阶段（phase）、Iteration（迭代）。

核心工作流从技术角度描述RUP的静态组成部分，它可进一步描述为行为（activities）、工作流（workflow）、产品（artifact）、角色（worker）。

　　从图中的阴影部分表示的工作流可以看出，不同的工作流在不同的时间段内工作量的不同。

值得注意的是，几乎所有的工作流，在所有的时间段内均有工作量，只是工作程度不同而已。

这与Waterfallprocess（瀑布式开发模型）有明显的不同。

静态结构：

方法描述

　　软件开发过程描述了什么时候，什么人，做什么事，以及怎样实现某一特定的目标。

RUP采用以下四个基本模型元素组织和构造系统开发过程。

角色:

thewho

行为:

thehow

产品:

thewhat

工作流:

thewhen

　　角色描述某个人或一个小组的行为与职责。

一个开发人员可以同时是几个角色，一个角色也可以由多个开发人员共同承担。

RUP预先定义了很多角色，例如：

Architect、Use-CaseDesigner、CourseDeveloper、Implementer…，并对每一个角色的工作和职责都作了详尽的说明。

　　行为是一个有明确目的的独立工作单元。

产品是行为生成、创建或修改的一段信息。

它是行为的输入同时又是它的输出结果。

产品以多种形式存在，例如：

模型（Model）、源代码、可执行文件、文档等。

　　模型是从某一个角度对系统的完全描述。

RUP的很大一部分工作就是设计和维护一系列的模型，这其中有UseCaseModel、BusinessModel、AnalysisModel、DesignModel等。

所有的这些模型都以UML描述，因此它们是标准的并为多种CASE工具支持。

RUP并不鼓励写在字面上的文挡，产品应尽可能地在CASE工具中创建和修改并为版本管理工具跟踪和维护，它们在整个软件开发周期中动态地增加和修改。

当然也可以根据需要为模型生成报告（Reports），但它们是静态的，是某一时刻模型的快照不需要维护和修改。

工作流描述了一个有意义的连续的行为序列，每个工作流产生一些有价值的产品，并显示了角色之间的关系。

RUP主要提供两种组织工作流的方式：

核心工作流（CoreWorkflow）和迭代工作流（IterationWorkflow）。

　　核心工作流从逻辑上把相关角色和行为划分为组，以描述RUP的逻辑组成部件。

它们相当于模板一样，并不在开发过程中真正的执行。

迭代工作流是RUP的一个具体的实现过程，它们对核心工作流进行裁剪，是核心工作流的具体实现。

每类工作流都会同一个或多个模型打交道。

RUP有九个核心的工作流。

以下简单描述这些工作流的目的：

商业建模（BusinessModeling）：

理解待开发系统的组织结构及其商业运作，确保所有参与人员对待开发系统有共同的认识。

需求分析（Requirements）：

定义系统功能及用户界面，使客户知道系统的功能，开发人员知道系统的需求，为项目预算及计划提供基础。

分析与设计（AnalysisandDesign）：

把需求分析的结果转化为实现规格。

实现（Implementation）：

定义代码的组织结构、实现代码、单元测试、系统集成。

测试（Test）：

校验各自子系统的交互与集成。

确保所有的需求被正确实现并在系统发布前发现错误。

发布（Deployment）：

打包、分发、安装软件，升级旧系统；培训用户及销售人员，并提供技术支持。

制定并实施beta测试。

配置管理（ConfigurationandChangeManagement）：

跟踪并维护系统所有产品s的完整性和一致性。

项目管理（ProjectManagement）：

为计划、执行和监控软件开发项目提供可行性的指导；为风险管理提供框架。

环境（Environment）：

为组织提供过程管理和工具的支持。

　　由于版面所限，无法详细解释每一个工作流。

前六个核心工作流的名字，很可能使人们同WaterfallProcess的顺序工作阶段相混淆。

但我们知道核心工作流并不是具体的实现，而核心工作流中的某些行为有可能在软件开发周期中，一遍又一遍地在迭代工作流中得以细化。

　　下图是需求分析工作流的具体例子，RUP为每一个行为的实现步骤都作了详尽的说明。

动态结构：

迭代式开发

在时间维上，为了能够方便地管理软件开发过程，监控软件开发状态，RUP把软件开发周期划分为Cycles,每个Cycle生成一个产品的新的版本。

每个Cycle都依次由四个连续的阶段（pahse）组成，每个阶段都应完成确定的任务。

起始阶段（Inception）：

定义最终产品视图、商业模型并确定系统范围。

演化阶段（evaluation）：

设计及确定系统的体系结构，制定工作计划及资源要求。

构造阶段（construction）：

构造产品并继续演进需求、体系结构、计划直至产品提交。

提交阶段（Transition）：

把产品提交给用户使用。

如下图所示，在每个阶段结束前都应有一个里程碑（MileStone）评估该阶段的工作。

如果未能通过该里程碑的评估，则决策者应该做出决定是应取消该项目，还是继续做该阶段的工作。

　　每一个阶段都由一个或多个连续的迭代组成，每一个迭代都是一个完整的开发过程是一个具体的迭代工作流从头到尾的执行。

与核心工作流不同的是RUP并没有也无法给出迭代工作流的具体实现步骤，它需要项目经理根据当前迭代所处的阶段、以及上次迭代的结果，适当地对核心工作流中的行为进行剪裁以实现一个具体的迭代工作流。

　　RUP的迭代开发过程是受控的，在项目计划中就制定了项目迭代的个数、每个迭代的延续时间以及目标。

在每一个迭代的起始阶段都制定详细的迭代计划以及具体的迭代工作流。

每次迭代过程都生成该次迭代的Release.作为下次迭代的基础。

在迭代结束前，都应执行测试工作，并仔细评估该迭代过程，为下一次迭代做准备。

迭代并不是重复地做相同的事，而是针对不同UseCase的细化和实现。

使用实例（UseCase）驱动

　　传统的面向对象开发方法因为缺乏贯穿整个开发过程的线索，因此很难阐述清楚一个软件系统是如何实现其功能的。

在RUP中，UseCaseModel就是这样一个线索它是整个软件开发过程的基础。

　　UseCasesModel是需求分析工作流的结果,它从用户的角度描述该系统应该实现的功能。

利用UseCaseModel可以有效地界定系统范围及其行为,并为用户及开发人员认同。

UseCaseModel主要由UseCases和演员（Actors）构成。

UseCase是系统执行的一系列行为，并为Actor生成一些有意义的结果。

Actor是所有与本系统有交互的外部系统，可以是人、其他软件系统等。

下图是一个UseCaseMode的例子：

　　UseCase作为分析与设计工作流的输入，是实现分析与设计模型的基础。

设计模型作为实现工作流的规格说明书，它自然要实现UseCase模型所定义的功能。

同样在测试工作流中，UseCaseModel组成测试实例，用来有效地校验整个系统的正确性。

另外，UseCase还是用户手册的基础、并驱动整个迭代开发过程的运作，所以我们说RationalUnifiedProcess是由UseCase驱动的。

以体系结构为中心

　　多年以来，软件设计人员一直强烈地感觉软件体系结构是一个非常重要的概念。

因为它使得开发人员及用户能够更好地理解系统的逻辑结构、物理结构、系统功能及其工作机理，也使系统能够更加容易修改及扩充。

但是由于对体系结构的目的及其定义一直模糊不清，且表示方法的混乱一直影响着它的应用。

　　由于在项目的开发过程中不同的开发人员所关心的角度是不一样的，因此软件的体系结构应该是一个多维的结构，RUP采用如下图所示的4+1View（视图）模型，利用UML语言来描述软件的体系结构。

这5个视图都是从相应的模型中抽取出对系统的结构、功能、健壮性及其可扩充性有重要意义的元素构成。

是各模型的精华与核心部分。

　　UseCase是驱动软件的开发周期的原动力，但是分析与设计工作流是以软件体系结构（Architecture）为核心的。

RUP的早期的迭代工作，特别是演化阶段的重点就是确定和校验软件的体系结构。

演化阶段的MileStone的一个关键任务就是确定该系统的体系结构是否健壮、成熟以及稳定。

RUP的优点

　　迭代式开发方法是一个不断的减除风险的过程,每一次的迭代过程都选择最关键的也是风险最大的UseCases执行。

因此风险在迭代过程中不断地被发现、消灭。

　　迭代式开发方法能够更容易地管理需求的变化，整个开发过程由一次次的独立的迭代所组成，项目经理能够比较容易地调整迭代过程，使最终产品实现变化的需求。

大部分的产品都存在CASE工具中，并为配置工作流所管理，使得所有开发人都能够及时地知道这种变化，制定相应的对策。

　　开发人员以及项目相关人员能够及时地从迭代过程中得到反馈信息，并能够及时修改以前工作中的失误，有效地监控开发过程，并对迭代工作流进行校正，这对一个时间跨度很长的项目具有重要的意义。

　　以UseCase驱动、体系结构为中心使得开发人员比较容易地控制整个系统的开发过程，管理它的复杂性、维护它的完整性。

　　体系结构中定义清晰、功能明确的组件为基于组件式的开发、大规模的软件复用的提供有力的支持，并是项目管理中计划与人员安排的依据。

　　Rational公司提供了丰富的CASE工具支持RUP。

比如：

可视化建模工具RationalRose;需求管理工具RequisitePro;版本管理工具ClearCase;文档生成SoDa;测试工具：

SQA,Perfomence等。

由于RUP采用标准的UML描述系统的模型基体系结构，因此可以利用很多第三方厂家提供的产品。

RUP能够达到软件工程研究所制定的CMM（CapabilityMaturityModel）模型的2级或3级。

总结

　　RationalUnifiedProcess是新一代的软件工程方法。

与早期的瀑布式开发模型相比，它具有迭代式的增量开发、使用实例驱动、以软件体系结构为核心三个鲜明特点，这使得RUP非常适宜于开发复杂、技术难度大、需求多变、高风险的项目。

RUP又是可裁剪的软件开发过程框架，各组织可以根据自身及项目特点对RUP进行裁减，在某些情况下RUP甚至可以蜕化为瀑布式开发模型。

参考文献

Rational公司.RationalUnifiedProcess.版本（5.0）.

PhilippeKruchten.TheRationalUnifiedProcessAnIntroduction.