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版中无法实现的功能，相信在以后的项目开发中，使用它或更新的版本，将更大程度上提高我们的软件开发效率，提升我们的软件品质。