1 引言

配置管理系统[ 3, 9]是软件开发的关键支撑工具之一，是一种管理软件开发和维护过程以及其中各中间软件产品的系统，是ISO与CMM质量保证体系的核心支持工具。配置管理研究怎样在不同时刻标识软件系统的配置，以便系统化地控制配置的改变，并在整个软件系统的生命周期内维护配置的完整性和可追踪性[ 1] .其中，版本管理是基础和核心。传统的版本管理系统以文件作为管理的基本粒度。版本管理系统记录、维护每个文件的演化历史。在大型软件开发中，系统往往包含较多文件，这使得传统方式版本管理的工作量很大，而且不易于描述文件间内在的组合关系。目前，基于构件的软件开发方法已成为发展趋势[ 7, 8] .构件作为系统的有机构成成分，在物理上可以表现为多个文件的集合体，而在开发过程中是作为一个原子单位使用的。系统的开发者关心的是构件整体的开发、演化，组装和维护。这种大粒度的开发方法，对版本管理提出了新的要求[ 3] .这些要求包括：

#应能有效存储和管理构件演化历史。

#操作模型应有利于体现构件的整体性， 降低系统开发的复杂程度。

#需要保证并行开发构件时的正确性， 同时不减少项目组协同工作的灵活性。

本文研究了构件的版本控制策略，提出了基于构件的版本管理模型。针对并行开发问题，又提出了分别在构件和文件粒度上进行版本管理和并发控制的方法。在此基础上，设计实现了一个产品化的配置管理系统JBCM.该系统既提升了管理的粒度，又能确保团队开发具有较好的并行性。

2 以构件为粒度的版本管理

2.1 版本管理系统中的构件定义

在基于构件复用的青鸟软件生产线中，软件构件定义如下： /构件是可以被多个软件系统复用的具有独立功能的系统构成成分0 [8] .构件在实际形态上可表现为通过目录结构组织起来的一些文件的集合，并且是系统中可以明确辨识的构成成分。需要指出的是，在以前许多有关版本管理的文献中都出现了构件的概念[ 4] ,但其中的构件一般指的就是文件。本文中的构件则是应用系统中多个相关文件构成的一个逻辑整体，例如一个类的定义及其实现，一个完整的功能模块等。构件版本是构件组成文件版本的集合。构件版本的变化不仅体现了组成文件的版本变化，同时也反映了构件中文件组成的变化。也就是说，组成文件发生版本演化，或者增加和删除构件中的文件，都会引起构件版本的演化。在基于构件的系统中，文件版本由系统内部控制，用户只关注构件版本，从而提升了管理层次。图1反映了构件版本与文件版本的关系：

图 中虚线箭头表示构件和文件与其不同版本的关系， 实线箭头表示构件版本由文件版本组成的关系。从图中可以看出构件的版本2 比版本1 增加了一个文件3, 而且文件版本也发生了演化。 构件版本的演化与文件版本的演化同步进行， 并且随着文件的版本演化自动产生。基于上述构件与文件关系模型， 提出并实现了基于构件的软件版本管理系统。

2.2 构件的版本管理

（1） 以构件为粒度的版本管理特点

与 基于文件的版本管理相比， 基于构件的版本管理有以下主要特点： ? 构件的抽象级别比文件高。 构件是应用系统中可以明确辨识的构成成分。 记录、维护构件的版本比文件的版本管理更有意义。 ? 构件的粒度可以比文件大很多。 一个项目中可能有诸多分布的逻辑单元， 这些逻辑单元与构件相对应。构件的数量较少， 而且整体逻辑意义明显， 可以更清晰地体现项目的演化历史。 ? 在构件基础上， 可以体现出系统的层次性、构造性等特征。 同时， 构件版本管理也可以满足对文件版本的管理需求， 使版本管理既有大粒度， 又有灵活性。

（2） 构件版本管理的基本模式

基 于构件的版本管理系统采用/ 检出（ Check Out） 、修改、检入（ Check In）0 的基本操作模型， 操作的基本单位是构件。 使用者需要先将构件从版本库检出到工作区， 随后在工作区中完成对构件的修改， 最后将修改的结果检入版本库。 构件组成文件的增删以及其中任何一个文件的修改都被视为对整个构件的修改。 因此， 作为检入操作的结果， 版本管理系统会自动生成构件的一个新版本。 以构件版本为粒度的版本管理系统记录和管理了开发人员对构件修改的历史。

（3） 构件版本树

在 基本模式之上， 使用者可以构件的某个版本进行分支，建立一个新的开发流， 以适应不同的开发需求。 构件多个分支还可以进行合并。 由此， 一个构件的所有版本构成了一棵版本树。 构件版本树是系统对构件进行版本管理的基础。构件的版本树是由版本管理系统维护， 系统需要提供比较完善的版本名自动生成与管理机制。 其基本原则是： ? 无冲突地表示整棵版本树； ? 有效的区分版本名与分支名； ? 有利于体现构件的开发过程。

图2 构件版本树

图2 是采用的一种比较实用有效的版本树命名方法。 版本11 0 为构件的初始版本， 实心节点为分支点。 版本11211121 210 与版本11 21 213 合并后形成版本1121 214.

3 以文件为基本粒度实现并发控制

311 版本控制与并发控制单位的分离

版本管理系统应能对项目组共同开发软件系统提供管理支持。 多个开发人员可以分工开发不同构件， 也可以同时开发同一构件。 为了保证协同开发的安全性和正确性， 必须解决构件开发过程中的并发控制问题。

在基于文件的版本管理系统中， 版本控制与并发控制的基本单位都是文件。 使用者可以在检出时对文件加锁， 防止其它用户对该文件进行修改； 检入时， 在生成文件新版本的同时， 要对文件解锁。 而在基于构件的版本管理系统中， 如果把并发控制的单位定为构件， 在需要修改时对构件加锁， 会造成其他使用者无法同时修改构件和构件中的任何文件。 因此， 提出并实现了以构件为版本控制单位， 以文件作为并发控制单位的管理方法。