一、UCM简介

Unified Change Management (UCM)是Rational管理软件开发中变更的一种方法。它适用于从最初需求到最终发布的整个软件开发周期，可管理需求，设计模型，文档，组件，测试案例，及源代码中的所有变更。

UCM是使用ClearCase来进行版本控制和配置管理的一种模式。它基于Base ClearCase,在Base ClearCase之上提供了高层抽象，可在不了解Base ClearCase细节的情况下有效使用，简单易用。UCM的核心是基于活动(Activity)的变更和配置管理。它需要变更管理工具ClearQuest和配置管理工具ClearCase两者结合起来使用。

二、为何要用UCM

当今有多种软件配置管理工具可供软件开发团队选择，那为什么我公司要采用基于ClearCase和ClearQuest的UCM呢？主要是了解到UCM会带来以下益处：

1. 简单，易用

UCM建立在Base ClearCase之上,它定义了一种基于活动的变更管理方法，为项目开发提供了统一和简单易用的处理流程。任何需求和设计变更，以及缺陷修正，都以活动的方式展现在开发者面前，开发人员针对这些明确而实际的任务展开变动。通过直观的图形用户界面，无论是项目管理员还是开发人员，都可以在无需掌握Base ClearCase中相对复杂的操作情况下，完成日常的变更管理工作。诸如项目的建立，开发人员工作空间的创建，针对活动的工作，项目的整合，变更的追溯等等，都可以在简便的图形用户界面上进行。

2. 独立的工作空间

项目中每个开发者拥有一个或多个开发流(Stream)，在每次项目整合之前，开发者均工作在自己的开发流上，通过关联到开发流上的视图(View),进行活动的选择，文件的检出，检入等工作，开发者相互不干扰。

3. 任务清楚，明了

对于需求和设计的变更以及缺陷的修正，项目管理者首先在ClearQuest中提交相应活动并分配给相关开发人员。相关开发者在ClearCase Explorer中，在自己的开发视图之My Activivities下，可清楚地看到当前分配给自己的任务。另外，如果在ClearQuest中设置相应Email Rule，相关开发者还可及时收到由ClearQuest自动发送的关于被分配任务的通知邮件，使得任何变更都可及时知会相关责任人。

4. 易于项目整合

每个项目除拥有多个开发流之外，还拥有一个集成流。集成流收集来自所有开发者所交付的成果。每个版本或Build需要整合与建立之前，项目经理决定需要包含哪些变更，然后通知各开发者提交相关活动，接下来开发者 从自己的开发流上把已实施的活动提交到项目的集成流上，与活动对应的所有文件变更从而被交付到集成流。项目的整合与建立在对应到集成流上的视图上进行。通过在ClearCase及ClearQuest中的查询，测试人员可准确地知道所要测试的版本有哪些功能变更。

5. 变更的追溯简便且直接

软件开发中经常需要查询针对某个功能的变动和缺陷的修正，有哪些文件被改过，以及文件的具体变动内容。使用UCM,在ClearCase和ClearQuest中，都可以通过方便的图形界面，查看到这些Change Set。对于每个vob不同基线之间的变化，也可以方便地查到。

6. 强大的与其它工具的集成功能

Ratioanl不仅将UCM集成到Rational的其它工具中(如建模工具Rose和Rose RealTime),更把它集成到许多流行开发工具中，如Microsoft Visual Studio, Sybase PowerBuilder, Adobe FrameMakeer等，还可以在Windows Explorer中直接使用。

三、UCM的工作流程

如图1,2,3所示，在UCM中，软件的循环开发过程可分为项目管理循环和开发循环。

图2 项目管理循环

图3 开发循环

具体为：

项目管理员创建项目及项目中的各组件，定义各组件的初始基线 开发者加入项目，创建自己的开发流和视图，建立私有工作区 项目经理和开发者创建和分配活动，开发者找到分配给自己的活动 开发者工作在活动上，在自己的私有工作区上进行文件的检出，检入和测试

开发者完成活动后，通过交付活动到项目集成流使其工作在项目共享工作区中体现项目管理员在项目共享工作区中集成由开发者交付的工作项目管理员根据需要在项目共享工作区中周期性地创建新的基线 开发者从新基线更新其私有工作区，以包含此基线对应的目录和文件之版本 开发者继续下一循环的工作，即查找活动，在活动上工作，交付活动，从新基线更新其私有工作区 项目管理员根据需要在项目共享工作区中周期性地调整基线的提升级以反映该基线的状况。

四、我公司的实际应用

在一个通信软件项目中，我公司采用了UCM来进行变更管理，至今已有近一年时间。所用的ClearCase和ClearQuest的版本为2001A.04.00。由于UCM的简单易用，开发人员只用了几天就掌握了使用方法，并且一直较为稳定地在运用。以下就UCM中的各个步骤，介绍一下在此项目中的实际应用。

1. 制定配置管理计划

在建立UCM项目之前，首先制定了一个详细的配置管理计划。该计划确定ClearCase网路的构成，ClearQuest数据库的结构，依软件系统架构定义所需各组件(vob),制定UCM项目的策略，等等。

图4

ClearCase网路的构成如图4所示，名为LICENSE的电脑作为ClearCase和Suite的License Server，名为PDC3RASRV的电脑作为ClearCase之VOB/VIEW Server及Registry Server，名为VVTSERVE的电脑存储ClearQuest Schema Repository Database和User Database(采用SQL Server 7.0)。

ClearQuest之Schema是基于Enterprise,并作了一些定制。

2. 建立项目

首先用VOB Creation Wizard创建PVOB以及作为UCM Component的各个vob, 然后在ClearCase Project Explorer中创建UCM项目，设定该项目采用ClearQuest UCM集成(ClearQuest数据库已建立)。

图5为该UCM项目之UCM Component示意。

图5

3. 加入项目

开发者在ClearCase Explorer中，用Join Project精灵来加入到此UCM项目。每个开发者创建一个自己的开发流，一个开发视图(采用快照视图),一个项目集成视图(采用动态视图)。

4. 新增，分配任务

当有功能和设计变更要求时，项目经理在ClearQuest中新建变更需求记录，然后由开发团队或开发负责人对每一变更需求记录，分析需要有哪些开发者做哪些具体改动，然后由开发负责人在ClearQuest中新建对应到此变更需求记录的一个或多个BaseCMActivity,并分配给相关开发者。相关开发者在ClearCase Explorer之My Activities中，就可看到自己要处理的变更。 当测试人员发现缺陷时，在ClearQuest中新建缺陷记录，开发负责人经分析后，将此缺陷分配给相关开发者。相关开发者在ClearCase Explorer之My Activities中，就可看到自己要解决的问题点。另外，我们在ClearQuest之Email Rules中，定制记录使得当变更和缺陷被分配后，相关开发人员能够及时收到Email通知。图6为某一开发者当前的任务清单，可以看到，此开发人员有一界面变动和一个缺陷问题需要处理。

图6

5. 针对任务进行工作

开发人员针对被分配的活动进行工作，需要检出(Check Out)和检入(Check In)相关文件，检出和检入既可在Rose, Rose RealTime, Visual C++这些建模和编码环境中进行，也可在ClearCase Explorer或Windows Explorer中完成。在检出文件时，把对应的活动设为当前要处理的任务，这样，UCM就会把以后检入产生的文件新版本所作的任何改动和此活动相关联起来，便于之后的活动交付和追溯比较。

图7为某一开发者在Rose RealTime中，检出一Capsule以修正某一缺陷。

图7

6. 提交活动

开发人员完成活动后，把所做工作提交到项目共享工作区。提交时，可选择提交哪些活动；对于目前还未完成的活动，或者暂时不用整合到项目中的活动，可选择不提交。

图8为某一开发者提交活动时的活动选择画面。

图8

7. 整合项目

当开发人员把需要整合集成的活动提交到项目集成流后，项目整合人员首先锁住集成流，然后在集成流上的某一视图中进行程序的编译，安装的制作。

8. 建立新基线

如果此Build可以作为后续开发的基准，则由项目管理员创建新的基线，然后解锁集成流，以允许后续的活动提交。新基线的创建可以针对实际有变更的UCM Component (vob)进行。

9. 从新基线Rebase

各开发人员从新的基线Rebase,更新其私有工作区，以包含此基线对应的目录和文件之版本，反映项目的当前最新状况。

10. 变更的追踪

此UCM项目使用了ClearQuest集成，通过直观的图形界面，对于任何变更活动，都可以方便地查看具体的变动内容。

图9为某一新增功能所涉及到的文件及其版本。可以看到，为了加入此功能，Rose模型的一个包(package)和若干C++源程序有变动，有的文件有一次以上的修改。

图10显示为了察看某一文件较之加入此功能前，有哪些具体修改所执行的操作。

图9

五、几点体会

采用UCM，使我们的配置管理工作变得简单而有效，提高了项目开发的效率，提升了产品的品质。当然，在实际使用中，我们也遇到了一些问题，通过自己的研究或Rational的技术支持，这些问题大多在较短的时间内得到了解决。

近一年的UCM使用下来，我们有以下一些体会：VOB的规划相当重要 建立UCM项目，首先要确定Component以及其下的目录结构，不当的Component规划会导致项目开发中不必要的新基线和rebase操作，也使得文档，模型，源程序和测试数据分布紊乱且不易查找。创建UCM项目前，软件的系统架构应已确定。根据软件的子系统，模块来建立相应的vob，使得属于不同子系统，模块的开发人员相互之间不会有干扰。 不同客户版本的处理 有时，开发的软件需要交付给不同的客户，这些客户对于产品有不同的需求。需要针对不同的客户创建不同的UCM项目，它们共享部份或全部的Component。 ClearCase命令行操作不可避免 然UCM提供了简便的图形用户界面，但对于ClearCase管理员，仍然需要用到基于ClearCase命令行的操作。因为UCM在提供简单，易用性的同时，也隐藏了一些Base ClearCase的内容。诸如license的管理，vob的备份和恢复，被损坏的view之删除，不同项目间的merge,等等，都需要项目的ClearCase管理员用ClearCase命令行来进行。 缺乏一定灵活性 UCM以活动和流的方式呈现给用户。每个UCM项目有一个集成流和多个开发流，开发者从其开发流交付活动到集成流，并从集成流更新其开发流以包含其他开发者的工作，各开发流相互之间无法归并。由ClearCase的分支被隐含，不少基于Base ClearCase的灵活功能无法使用。例如，有一 20人的开发团队，开发者A要用到开发者B新的源程序，需要B先提交包含新的源程序的活动到集成流，然后由项目管理员建立新基线，再由A从新基线上更新其工作区以获得开发者B新的源程序。而很可能此源程序还处在调试阶段，却被提交到了项目集成流。开发团队越大，此类现象就越多。

六、结束语

以上是对Rational UCM的介绍和我们在项目中的实际应用情况。现今为止，我们只在一个项目中采用了UCM，且不到一年，既使这样，我们已深切感受到UCM给软件开发带来的效益。 UCM的2002版功能更强大，也更灵活，提供了一些在2001.A版中无法实现的功能，相信在以后的项目开发中，使用它或更新的版本，将更大程度上提高我们的软件开发效率，提升我们的软件品质。