基于构件的软件开发方法实现配置管理系统JBCM的研究

1 、引言

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

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

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

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

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

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

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

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

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

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

3.2 文件的操作模式与并发控制

在实现基于构件的版本管理系统中，构件是版本控制单位，而并发控制则在构件内部的文件级别上进行管理。对于一个构件，使用者可设定其中文件的操作模式，由此来控制相关文件的加锁活动。

文件的操作模式可以分为三种： /只读0、/排它写0和/共享写0、/只读0表示对文件不加锁，使用者也不能对文件进行修改，使用者可以使用/只读0模式来浏览文件； /排它写0表示对文件加锁，使用者可以对文件进行修改，但不允许其他使用者同时进行修改，这样可以保证对同一文件的修改是串行化的； /共享写0则表示对文件不加锁，使用者可以对文件进行修改，而且允许其他使用者同时对同一文件进行修改。虽然/共享写0模式可以提高并发程度，但会带来多个用户修改结果互相冲突的问题。版本管理系统可以分析这种冲突，并提示用户进行相应的合并处理，由此解决了文件内容的一致性问题。

在构件的修改过程中，文件的操作模式是可以随时改变的。例如，使用者先用只读模式检出构件中的各个文件，而在要修改文件时，可将需修改文件的操作模式改为/排它写0或/共享写0，然后修改。完成了对构件中所有相关文件的修改，也就完成了对构件的修改。这时检入修改后的构件，系统会自动产生该构件的一个新版本。如果在使用者检入之前另一使用者已检入了构件的另一新版本，该使用者就需要先进行更新操作，系统会将构件最新版本拿到工作区，与该使用者修改过的版本进行合并后才能检入。使用者对文件操作模式的修改必须满足一定的条件。具体转换条件见图3.

3.3 文件的操作权限管理

操作权限用于管理特定用户对构件中文件的使用权限，分为/只读0和/可写0两种。它控制的是用户对文件的操作能力。用户操作模式是用户检出构件时对文件的实际操作。用户操作模式不能超过操作权限。例如，拥有/只读0权限的用户只能用/只读0模式检出文件，拥有/可写0权限的用户才可以用/只读0、/排他写0和/共享写0模式修改文件。操作权限与操作模式一样，都是针对构件中的文件。通过操作权限的管理，可以划分不同用户对同一构件所承担的工作任务。操作模式和操作权限相结合，有效地解决了多个用户协同开发同一个构件时的并发控制问题。

图3 各种文件操作模式间的转换

4、 基于构件的版本管理系统的实现

在上述研究基础之上，研制了青鸟配置管理系统JBCM的核心部分。基于构件的版本管理系统JBVM. JBVM对基于构件的软件开发方法提供了充分支持，其最主要的特点是将构件与文件版本管理分布于两个不同层次，在系统设计方面也就具有相应的层次性。本节主要讨论设计与实现中的关键问题及其解决策略。

4.1 版本库的组织结构

版本库是构件版本演化历史的存储区。版本库中记录的数据分为版本构件和元数据两类。版本构件是用户交付的各类构件，由于同时具有版本信息，故称为版本构件。元数据是管理系统维持自身运行所需的各种控制文件与完成各种版本管理功能所需的信息，包含日志、用户管理、并发控制、权限控制、操作模式、统计与审计等信息。

图4 版本库的层次结构

版本管理系统设计的核心内容包括版本库的组织、结构与维护。 版本库的组织结构分为两个层次： 项目层和构件层。对于系统开发人员来说， 版本库中的项目可以与系统开发中的工作划分相对应， 一个软件系统的整体或子系统都可以作为一个项目。 而构件对应于软件系统结构中最低层的不可再分的基本逻辑单元， 可以是系统开发过程中需要作为一个整体的文件集合， 例如用于实现一个C+ + 类的所有。 cpp 和。 h文件。 下面是版本库的一个简化结构示例图。 在项目a（ 用a.Prj 表达） 下， 有c 和d 两个构件（ 用c. Comp 和d. Comp 表达） ，而c 构件由e. cpp、f. h 和一个g 目录组成。 TempFile 是版本库的临时文件存储区。

4.2 构件的增量存储

构 件的不同版本间具有较大的内容相似性， 不同版本的存储有必要使用增量存储方式， 以减少存储冗余。 在传统的文件版本管理系统中， 已较深入地研究了文件的增量存储技术， 有实际的算法及实现， 如最长公共子序列算法［ 5］ 等。 根据基于构件的版本管理的特点，提出了按构件和文件两个层次分别进行增量存储的设计方案：

（ 1） 对于构件中具体文件的修改， 使用传统的文件逆向增量存储技术 ， 保存最新文件版本与增量部分。

（ 2） 构件的版本由附属目录及文件的版本组成。 构件的增量存储体现在版本中记录的是相比前一版本组成成分的不同部分。

（ 3） 对于文件和构件存在多个分支的情况， 对各分支独立进行增量式存储。 保存每个分支上的最新版本和其他版本相对于各自后一版本的增量。

4.3 构件版本的比较与合并

构件演化过程中会产生多个分支，各分支都会实现一些不同于其他分支的新特性。有时需要将这些特性都合并到一个版本中。为了保证在多个用户协同工作时的正确性，也经常需要合并多个用户分别修改过的构件版本。构件不同版本的合并采用如下策略：不同版本添加的文件有选择地添加到合并版本中，修改过的文件逐一进行合并。

构件版本的比较是版本合并的基础。在合并之前，可以通过构件版本的比较得到不同版本间的差异。除此之外，为了查看构件的演化历史，实现对构件的变化与过程控制，也需要比较构件的新老版本；在基于构件的版本管理系统中，构件版本的比较分为两个层次。底层是文件级的比较，通过比较不同版本文件的具体内容，得到文件内容的差异。上层是构件级的比较，通过比较构件不同版本组成成分，来获取构件整体的变化情况。在JBVM系统中，通过构件级别上的比较则可分析出构件的不同版本各自包含哪些文件，以及分别对哪些文件进行了修改。

5、 结束语

本 文着重讨论了基于构件的软件版本管理模型， 以及相应系统的设计与实现。 基于构件的思想不仅可以应用于版本控制， 配置管理中的其它功能， 例如配置支持、构造支持、审计控制、统计报告、过程支持和团队支持等方面都可以建立在构件的基础上。 我们将进一步研究以构件为粒度配置支持、构造支持和变化控制方法。

责任编辑：gt