Rational统一过程RUP贴近中小软件开发

对于中、小规模的软件项目，开发团队的规模不是很大。软件的开发周期也比较短。在这种情况下，完全照搬RUP并不完全适用。因此，裁剪RUP使其适合中、小型软件开发项目是非常有必要的。

　　

　　图1：一个复杂的BUC的实现方法

　　Rational统一过程(RUP)是IBM公司的一个软件过程产品。它几乎覆盖了软件开发过程中的所有方面。

　　J2EE技术提供了一个基于组件的、多层分布式计算平台。在J2EE的应用系统的开发过程中，由于使用了中间件，开发人员可以把工作重点放在系统功能的建模、设计与实现上。此外，J2EE技术结合了软件设计中的最佳实践(best practices)，如以架构为中心的软件体系结构、基于组件的架构等等。这一切都对现有的软件工程过程提出了新的挑战。所以，裁剪RUP并且使其在J2EE项目中起更大的作用是非常有意义的。

　　本文讲述了如何把RUP应用到小型项目团队开发J2EE应用系统的过程中，并且结合J2EE技术的特点从项目管理、架构设计、开发和测试等方面重点阐明了对RUP的裁剪。

　　项目管理

　　在RUP中，角色定义了个人或团队的行为和职责，包括分析设计人员、编程人员、测试人员、项目管理人员和辅助人员，一个人可以同时担当几个角色.一个角色也可以由几个人来共同承担。针对J2EE系统的开发和维护，J2EE规范中也定义不同的角色，包括J2EE产品供应商、应用组件供应商、发布人员、系统管理员等等。

　　在实际的项目运行中.要根据软件开发组织的实际情况来确定角色的定义和分配。项目经理是必不可少的一个角色，通常是一个人来担任。项目经理代表整个项目与软件客户进行沟通和协商，并且制定软件开发计划等等。架构师也是一个必须的角色，通常由一名经验丰富的软件开发人员来担任。

　　在项目运行的前期，架构师负责设计软件架构和原型系统。在项目运行后期，架构师可以参与到具体的软件开发中。SQA同样是必不可少的，通常是一名经验丰富的软件开发人员来担任。SQA在整个项目的运行过程中负责监督和改进软件质量，包括制定系统测试方案、用户接受测试方案等等。开发人员是组成团队的主要力量，负责系统的设计、开发和测试。如果可能的话，团队中必须设立业务分析员的角色，负责商业建模等，通常由有特定行业经验的人来担任。

　　迭代开发计划

　　RUP的精髓之一迭代式的开发，它是基于Spiral模型翻的。整个软件开发周期由很多个迭代组成，其中初始迭代最为重要。其它每个迭代都为了实现软件的部分功能。在完成所有迭代后，软件的所有功能都已实现并且通过测试。

　　初始迭代又叫作0迭代，它开始于项目的启动。结束于RUP初始阶段(inception phase)的完成。初始迭代在整个软件项目中起着十分重要的作用，这是因为在这个迭代中，项目团队和客户必须对软件项目的范围、成本、进度和应用系统的边界以及功能等达成一致的理解。

　　在初始迭代中，最重要的活动有明确项目的范围、商业需求和提出至少一个可用的软件架构方案。在明确项目范围的过程中，项目经理就项目的边界、产品、限制条件等与软件客户进行协商，从而达成一致认识。同时，在理解客户需求的基础上，项目经理或者业务分析员以需求说明书和功能说明书的形式把客户的需求记录下来。并且和客户达成一致理解。在此基础上，架构师提供至少一个合适的软件架构方案，并且完成原型系统。原型系统的目的不但是为了验证技术上的可行性，而且是为了给客户一个感性的认识，更好地完善对需求的理解。

　　需求说明书从客户的角度简要地描述了系统要具备的功能，它包含了很多商业用例。通常情况下，需求说明书还不能够全面地描述整个应用系统，所以软件开发组织还要从不同角度来描述系统的功能和特征，这就是功能说明书。功能说明书中包含了很多系统用例。功能说明书和需求说明书必须征求客户的意见，直到客户满意为止。

　　迭代计划是项目计划的一部分，指如何把要实现的系统分解成更小的子系统和如何在不同迭代中(除初始迭代之外)划分子系统，从而使每个迭代的目标明确，不同迭代之间的依赖关系达到最低。通常情况下，从逻辑上看，应用系统可以划分成多个BUC，而每个BUC又可以进一步划分成SUC;因此，可以从BUC的角度出发，根据相互之间的依赖程度来进行划分，把依赖程度低的BUC划分到不同的迭代中，从而确定每一个迭代的范围。一个复杂的BUC可以把它分解成独立的几个小BUC在几个迭代中来实现。

　　一个应用系统也是由很多组件组成的。一个或者几个组件组合起来可以实现一个SUC或者一个BUC的要求。在设计迭代计划的时候，要考虑到组件之间可能存在的约束关系。基于J2EE的应用系统是基于组件架构的，因此，最小化迭代之间的依赖是一个最重要的衡量标准。

　　采用这种迭代办法后，每个迭代的范围限制在一个或者几个相互独立的BUC中。这样做的好处在于降低需求变化带来的风险。

　　风险管理

　　采用迭代式开发的一个很重要的原因是，项目的风险能够在早期的几个迭代中暴露出来。风险有两个基本的属性，一个是它发生的概率，还有一个是风险发生后对项目的影响。风险管理的目的是为了尽量降低风险发生时对项目的影响。

　　在风险管理中，首先要识别项目中存在的风险。其次根据风险发生的概率和风险发生后对项目的影响来分析存在的风险。通常采用量化风险的办法。给概率和影响分别赋予一定的数值，经过分析，把概率的数值和影响的数值相乘后的结果风险量化后的值。接着，对于量化后值比较高的风险制定相应的风险规避计划。在项目运行过程中，要不断地监督风险的变化。

　　架构设计

　　RUP采用基于组件的软件架构和以架构为中心的开发方式。J2EE技术强调基于组件的软件架构,能够很好地体现RUP的架构思想。根据3D方法可以把一个J2EE应用系统的架构从三维进行分析，分别是Tier、Layer和Systematic Quality。在设计系统架构的时候，可以从这三个角度考虑。

　　Tier

　　从Tier层的角度进行考虑，一个J2EE应用系统的架构可以分为以下几个部分：客户端层、表示层、业务逻辑层、集成层、资源层，如图2所示。每层都是按系统中业务逻辑而划分的，它具有唯一的职责。每层与相邻层都是松散耦合的。

　　

　　图2：基于Tier层的J2EE应用系统架构

　　在实现的时候，需要结合项目的具体情况而定。基于MVC设计模式的J2EE Web应用系统中，客户一般访问JSP。然后由Control层进行处理：如果需要进行复杂的业务逻辑处理并且已经有后台实现，业务逻辑使用Facade模式进行封装，形成统一的接口，业务逻辑层实现复杂的事务处理;如果需要访问资源层，再经过DAO层访问资源。

　　Layer

　　从Layer的角度进行考虑，一个J2EE应用系统的架构可以分为几个部分：最下层为操作系统、Java虚拟机和网络，它们负责系统的底层操作和网络数据的传输;之上是J2EE服务层，一般由J2EE服务器(如WebSphere，WebLogic等)提供各种基础服务，如事务的管理(JTS)、命名目录服务(JNDI)、负载均衡(Load Balancing)、容错(failover)、安全(security)等;其次是通用业务层，它一般完成与具体业务无关的基本操作，由通用的组件来实现，如数据库处理组件、系统错误处理组件、字符处理和数值处理组件、日志(10g)处理、数据转化和编码维护等;最上层才是具体业务逻辑模块，它完成具体的业务逻辑。

　　

　　图3：基于Layer的J2EE应用系统架构

　　在实现的时候.底层一般是不需开发人员关心的操作系统和网络环境，并且不同J2EE服务器厂商都提供了相应J2EE服务层， 开发人员需要关心上面两层的实现。如果是J2EEWeb应用体系，应用服务层一般会使用Struts框架。log服务一般选择log4j等。最上层才是具体业务模块。

　　Systematic Quality

　　这是指在软件架构中通过一定的办法或者使用一定的工具来达到系统要求的QoS，一般指可扩展性、可移植性、可维护性、安全等等,而这些恰恰是J2EE架构本身所带来的好处。

　　实现和测试

　　实现是软件开发人员编写代码来完成每一个组件。测试是用来保证软件质量的重要手段。采用RUP的软件工程过程后，整个项目被划分成不同的迭代。每个迭代(除了初始迭代)的范围是一个或者多个独立的BUC， 目标是编写代码实现BUC并且保证软件的质量。

　　在实现和测试的时候，集成(integration)是很重要的。这是因为整个软件开发过程分成多个迭代来完成，每个迭代(除初始迭代外)都是为了实现应用系统的一个部分。对于相邻的两个迭代。后者是在前者的基础上进行开发的，是实现功能上的一个增量。因此，相邻迭代之间需要功能上的集成。此外，每一个迭代都是由BUC组成的。从逻辑上来看，一个BUC是由一个或者多个SUC组成的。从实现上来看，每个SUC是由一个或者多个组件(component)组成的。因此，每一个迭代中都需要组件之间的集成，如图4所示。

　　

　　图4：BUC的组成结构

　　根据集成程度的不同，可以划分几个不同的开发集成和测试：

　　首先是SUC集成和单元测试。这个是粒度最小的集成，它把几个不同的组件集成起来，实现同一个SUC。例如，SUC1是通过集成C1和C2来实现的。同时，在集成完成后，进行相应的单元测试。

　　其次是BUC集成和集成测试。BUC集成是把几个相关的组件集成起来,来实现它的功能。图4中BUC的实现需要集成4个组件。同时，在集成完成后进行相应的集成测试。

　　再次是迭代内集成和系统测试。迭代内集成从功能上来看，就是把这个迭代包含的所有BUC集成起来;从代码上看，是把所有和BUC相关的组件集成起来。同时，在集成完成后进行系统测试。系统测试分两步，首先是从功能上来测试每个BUC，其次是测试不同BUC之间的依赖和约束。

　　最后是迭代间集成和回归测试。对于相邻的两个迭代，从功能上来看，后者是前者基础上的一个增量。迭代间集成把这个增量准确地集成到应用系统上。同时，在集成完成后进行衰减测试。回归测试不但要测试功能增量的正确性。而且要测试增量发生后系统原来功能的正确性。

　　实例研究

　　笔者在Trade Manager项目中运用了上述的方法。TradeManager是一个关于金融软件研究的项目，开发基于J2EE技术的金融订单管理系统。项目由12个人的团队来进行开发。团队成员分工明确，有项目经理、架构师、测试员和SQA等等。项目采用迭代式的开发方式。在初始迭代中，项目双方对项目范围、功能需求及架构达成一致，并签字同意。整个开发分为三个迭代阶段，根据功能点来划分，每个迭代分别实现交易前、交易中和交易后的功能。每个迭代的开发时间在六个星期。

　　这个软件采用J2EE 的架构，如图5所示。其中UI和Delegate层在客户端，采用Swing技术来实现，是一个典型的肥客户端。Facade、Business Logic和DAO在J2EE服务器端，采用EJB技术来实现，它与客户端的通讯是典型的RMI/IIOp协议，采用的服务器是WebSphere。后台采用Oracle数据库来存放各种系统数据。同时，采用SiteMinder来实现系统的认证和授权。用log4j来实现logging/auditing功能。由于采用WebSphere集群技术，系统的可扩展性和高可用性得到了保证。

　　

　　图5：应用实例

　　在开发的三个迭代中(除初始迭代外)，相邻两个迭代进行衰减测试，由SQA和测试员来完成。每个迭代中，开发人员完成单元测试和集成测试，SQA和测试人员完成系统测试。在做完三个迭代后，软件移交给客户进行UAT。

　　RUP适用于规模比较大的软件项目和大型的软件开发组织或团队。在实际中，软件项目团队根据自身客观条件的限制和技术的影响，应该对RUP进行必要的裁剪，从而让RUP更好地服务于软件开发过程。本文在结合J2EE技术特点的基础上，从不同方面讲述了如何定制RUP，在项目管理中，应该正确定义团队角色、采用迭代式的开发方式和重视风险管理;在架构设计中，针对J2EE技术的特点。指出了从三个不同方面来设计软件架构;在开发和测试中，应该正确对待各个阶段的集成和测试。

查看本文来源