clearcaselt配置

bmccbj

113
配置的私有变化工作区；一个查看配置和防止非授权访问的可调配置的
透明检查；一个协调配置变化的团队协调。这些术语代表了配置管理系
统功能方面的先进性。
光谱拓朴的目的是显示一个术语的进化过程。例如，图2 从左到右
总的来说有不同过程的建模、捕获组件、描述产品的构件，优化产品工
程。特定构件间相互关联的协调团队工作。光谱的“臂”显示了相关过
程。例如，需求变化和生命周期模型（如本书描述的一样）是相关联的：
生命周期模型小计了一个特定变化需求模型，同时变化需求操作了一个
库。
有一些术语在光谱上没有显示。那些不能显示的术语如：构件的细
微进化（例如从版本标识到配置标识到不同配置的不同版本）；系统建
模过程（例如从命令文件的进化到创造文件到系统模型如版本对象）；
“角色”的识别和不同类型的变化（例如增强反病毒功能，病毒出现提
示）；目前的研究工作。
在本书上简化了从配置管理系统是提炼出来的术语。相对于已实施
的系统来说是为了找到一些共同的术语。没有共同的词汇来表达术语。
术语和它们的实施之间的区别并不总是清晰的。例如，工作区的实施在
不同配置管理系统中变化，同时为用户提供不同的功能。此外，工作区
的术语应该是所有实施的最低共同命名或相反？既然协调统计了工作
区和检查的术语，那么工作区、透明检查、协调又真的是同一术语吗？
或者它们真的如在光谱上显示的一样是三个术语吗？
另外一个在提炼术语时的难点是大多数配置管理系统都有过多的
术语。那就是一个术语有许多目的（这些目的在配置管理系统中通常是

bmccbj

114
不统一的）。例如，Rational 子系统术语在光谱中被看作为限制变化范
围而提供支持。然而，子系统比那个术语提供了更多的功能。它们能：
提供一个名字范围边界，支持系统分区，代表一个基线，一个工作区，
代表一个意思（为工作在不同的配置或一个团队的同一配置）。检查接
口提供的细微变化或代表一个不可调的可执行的组件（在Rational 术
语中的一个“装载检查”）。因此，为了讨论子系统，在其一个特定方面
的磨合是必要的。此外，过多的术语使得提炼基本的术语变得困难。同
样，组合不同术语的不同部份，或一个特定术语的实施副影响都使得术
语的提炼更加困难。例如，当考虑一个变化需求时，角色（象配置经理
和测试经理）和生命周期术语（如开发和测试）对那个术语是至关重要
的，或者它们是独立的？
无论如何，这些术语的光谱为开发提供了一个起始点，或者至少从
已存在的配置管理系统中提炼出一个配置管理模型——一组基本的配
置管理服务。此外，需要进一步的工作来决定：光谱的使用价值，是否
还有其它的术语，怎样定义、命名和表达这些术语以及它们的多种语义，
并且怎样将这些术语组合成一套有用的配置管理系统。
4. 配置管理系统的未来
图2 所示配置管理概念光谱图表示了商用配置管理系统的典型概
念。我们预计，随着研究的继续，和不断从这些概念的结合使用中获取
经验，光谱图上的许多分支将会互相连接。这意味着，每个配置管理系
统最终都可能将提供一个基本的配置管理服务集，从而更好地适应用户
需求。但是，即使不考虑是否每个配置管理系统设计者都试图实现这些
共同的特征，还有政治和技术方面的因素都会影响未来的软件配置管理

bmccbj

115
系统。（政治层面的因素是指与市场和标准化相关，技术因素则是关乎
实现某一特定机制的可行性。）
一个主要的政治因素是关于CASE（计算机辅助软件工程）工具的发
展。例如：CASE工具经销商是否应该假设环境经销商会在他们的框架内
提供配置管理支持，所以他们自己可以避免在他们的工具中实现配置管
理。或者，是否应该由CASE 工具开发商在他们的工具中提供配置管理
支持。如果CASE 经销商合并他们自己的配置管理支持，那么当用户安
装不同的CASE 工具时，用户将不得不自己解决如何集成不同的CASE 工
具的问题。同样，从经销商的视角看，他们会真正重复去做那些已经被
整个环境框架尝试过的工作吗？
另一方面，如果CASE 经销商不把配置管理合并到他们的工具中去，
他们能依赖环境集成商提供合适的环境框架，去集成CASE 工具并同时
提供某种通用的配置管理能力吗？这些问题的答案都是未知的。我们都
可以看到，任何一种情况都意味着，对于环境来说，配置管理系统需要
一定的标准化。反之亦然。
许多技术、研究方面的问题都影响着配置管理系统的能力，冒出来
了如下这些问题：
什么适当的技术可作为配置管理系统的基础？对象命名约定不变
的面向的对象数据库技术是最合适的吗？在环境体系结构中软件配置
管理是在哪一层？它是否应该作为环境框架中一部分，放在数据库的基
础层，还是把配置管理看作一个过程，处于体系结构的较高层？配置管
理的机制能否从所有的配置管理功能中分离出来？也就是说，是否有一
个标准的配置管理本质部分，能够在任何环境中使用，并支持所有的配

bmccbj

116
置管理功能。存在一个统一的配置管理模型吗？是否可能提供分布式的
配置管理支持？在地理上分散的软件开发组能否与本地配置管理和系
统集成使用同样的配置管理系统。这是工业界的一个主要难题，尤其是
对于国防合同承包商来说。配置管理支持跨软件开发吗？工程师是否能
够在主机上开发产品，然后在保持对产品的配置管理控制的同时轻易地
将它转移到目标机上去吗？规模是配置管理系统的一个限制性因素
吗？配置管理对一百万线产品的支持和对一兆线产品的支持是一样的
吗？有可能将配置管理过程中，包括劳力密集型的部分，所有方面都建
模，并在配置管理系统中实现它吗？
对以上这些问题的回答都不是显而易见的。因为很可能要管理的过
程有着不同的来源，从配置管理系统经销商，开发环境集成商，研究人
员，工具继承商，软件过程建模论坛，还有计算机辅助设计，计算机辅
助工程，计算机集成制造等不同的领域。
5. 结论
配置管理是对软件产品发展演化进行的管理。从配置管理系统的操
作层面上看，配置管理是认证，控制，状态统计，审计，评估，制造，
过程管理和团组合作。它是软件工程领域的一部分。它的工作对象是这
个领域中产生的过程。这从概念光谱图可以明显地看出来，同样也可以
从已有的配置管理系统的数量和它们的能力看出来。本文的光谱图表示
的是许多不同的配置管理系统经已实现的概念的一个快照。每个存在的
系统的重点都不同，在用户问题——包括角色，集成，控制，自动化层，
过程等等，与产品支持，什么时候是开始使用配置管理的最佳时机，系
统能提供哪些功能等之间进行竞争和权衡。希望提供这个光谱图能够有

bmccbj

117
助于对配置管理系统能力的理解，并且提供一个讨论配置管理支持工具
的通用框架。
6. 附录：CM 体系总览
这个附录给出了此份论文中前面章节提到的不同CM 体系能力的总
体印象。既不是整个体系的评估也不是完整描述，目的只是让读者对下
列CM 体系能力范围有一个了解，这些是存在于今天的不同种类的CM 体
系的代表：Adele, ADC, CCC, CMA, DMS, DSEE, ISTAR, Jasmine,
LifeSPAN, NSE, PowerFrame, Rational, RCS, “shape”, SMS。这些
体系在下面描述。
A. Adele
Adele 是一个来自于格勒诺布尔大学的配置管理体系。它的基本特
征是数据模型，届面检查，展示产品系列，配置建立和工作现场控制。
Adele 是用来成为软件工程环境的核心。Adele数据库是一个实体关系，
一个为物件提供定义，如界面和它们的实现（instances of bodies），
配置和家族。物件有特性：描述它们的特点，和DEP关系：描述它们的
从属关系，Adele 用这些功能来帮助组成配置。使用者可以指定一种基
于合意的特性的配置。特性可以用户定义或体系定义。用户可以指定规
则基于特征价值，局限和优先。Adele 可以探测到不完整和不连续的配
置描述。
B. Aide-De-Camp (ADC)
ADC, 来源于Software Maintenance and Development Systems,
Inc.，由基本的ADC 体系和一个看守系统组成。基本的ADC 提供了一

bmccbj

118
个数据库以获取CM 信息。用户在文件内定义特征和关系。数据库可以
贮存资源和二进制码，它贮存易变的(“塑料”)和不变的（“安装的”）
信息。ADC 的列表处理语言有效地允许用户在一个文件或一组文件上
工作。ADC 冲突解决方案在登陆（check-in）和标记时执行。改变设
置俘获改变了配置和允许用户指定任何版本的通过一个改变设置清单
从而创建它们自己的版本树。报告可基于数据内容而产生。程序建立
得到支持，结构的关系被自动得到。一些非—ADC 的CM信息可以输入
至ADC 数据库。监管系统直接支持配置，集成问题报告，改变需求，
和了解用户，承担分派工作指令和建立当地的工作站（“干净房间”）
的角色。这意味着当一个变化需求被送到CM 经理并得到认可时，经理
把工作分派给软件工程师。当工程师执行那项活动时，一个被复制的
本地的路径和文件工作站建立了。一旦工程师完成那项工作，工作站
自动删除，变化被加入数据库。
C. Change and Configuration Control (CCC)
Softool 的CCC（称为CCC/发展和维护）被作为一个监管系统或
作为一个本地的产品出售。CCC 提供一个变化控制方法论，配置标识
和状态会计，以及起源建筑。所有的这些被用来假定瀑布生命周期模
型。CCC 下的部件在适当的认可之后，经过了不同阶段的生命周期。
CCC 支持一些文件化的标准。五个等级的客户构成权限的层次列入数
据库。他们是数据库管理员，CM 经理，项目经理，开发者，及测试经
理。一些层次的通道控制了存在，例如密码控制，用户等级，指定数
据或改变需求分配。CCC 数据库层次，代表产品的结构，由多层次数
据结构组成，包括数据库，体系，配置，模块和文本。编码的平行版

bmccbj

119
本可用于通过实质拷贝实现同时发展。这些可以合并或选择，变化可
跨配置运用。在合并中冲突可监测到。CCC 的变化需求，如项目，可
以处理一个部件的小变化，或产品的下一次发布所需的所有变化。电
子邮件事件通知与变化需求相关。紧急变化绕过大多数的变化控制是
允许的。
D. Configuration Mnanagement Assistant (CMA)
来自于TARTAN 实验室的CMA 提供mechanism（无方针）创建CM
系统。Mechanism 使用的是实体关系特性数据库。特性和关系的等级
详细说明了部件的特征，一个产品的分解和部件之间的相互依赖。特
性的等级是分割，演示，和版本；关系的等级是逻辑从属，一致性，
兼容性，部件，立即和可继承的从属性。CMA 用来录制和获取配置描
述，部件的组成，录制和获取关于一个配置的部件之间已知的（不）
一致性和从属性。它预告新形成的配置的完整性，不明确，和一致性。
任何数据库的变化是通过对简单“交易”的承诺产生的。每种配置可
以有它自己的通道控制mechanism。配置之间的名字冲突通过使用间
隔来避免。
E. Design Management System (DMS)
来自于SHERPA 公司的DMS 适用于电脑辅助设计/工程师市场和硬
件的一部份，设计工程师环境。DMS 提供逻辑的集中仓库，内含清晰
的分布的数据。文档可包含任何种类的信息，如ASCII，图形，以及
设计数据。文档的版本通过当地操作系统的版本控制来实现。所有信
息（产品结构，发布程序，事件警告，用户定义特性和关系）被集中
在一个核心的数据库。“发布”的意见通过促销水平（代表项目通过时

bmccbj

120
的台阶）获取。这些代表公司方针用于评审，确认或完毕信号。用户
可以指定谁可以获得什么样的数据，数据群，谁应该被告知状态变化，
完毕信号及促销需要什么样的确认和检查。DMS 通道控制是在用户等
级和promotion level of file 的基础上实现的，文档名可以加密，
实质的团队可以定义（这些是地理上分散但分享同一数据库的用户）。
可要求自动同步更新或分批更新。变化可以在小组成员间得到交流沟
通。不管在网络的哪个地方，文档的最新版本都可以定位。DMS 用这
个结构来执行检查。并可提供报告及预评审。变化需求（包括相关文
件）确认后自动随附。
F. Domain Software Engineering Environment(DSEE)
DSEE 提供版本控制、系统建模、配置发放、分散系统建立、物件
组、用以查找要做的事务及已经完成任务的任务单、将特殊事件通知
用户的控制。版本控制置于一资源文档库中。一DSEE 系统模型是对一
产品或产品一部分的描述。它是一针对静态和结构特点的公开描述，
包括资源文档、派生物件和从属工具、组件的阶层、创建规则、创建
顺序、数据库及路径的确定、转换工具的选择和一些控制过程规则。
G. ISTAR
ISTAR 来自于imperial software technology ltd. 是一个环境
设计的特别用来支持项目管理的。软件项目个体之间的关系被模仿为
合同。一个合同理论上是对期望产品的描述，并被构造成数据库。一
个配置是在合同之间移转的单元，移转时被认为是“冻结的”。合同的
移转暗示了一定的任务或阶段已完成。CM 为合同数据库内的项目而存
在，并在合同之间可交付。为数据库内的部件提供继承者和不同的控

bmccbj

121
制。用户可以定义CM部件之间的关系，可以为问题报告分配部件。这
是对系统建立的支持。
H. JASMINE
JASMINE是应用于室内CM的XEROX信息系统分配上开发的大型程序
设计系统。系统模型是其核心。它描述一个软件系统，这个软件系统使
用在设置和功能上构建的代数模式。用户能用这个代数模式来定义复杂
的询问和简单的译本。软件结构则被定义在模板中，翻译捆绑体由图象
支持，后继的翻译记录在一个族中，这个族支持并行开发。专业译文被
分类后组织成特殊历史记录（如：一个项目专业历史记录）正文内容和
这些族均被提供给译本，同时定义它的语法结构和连贯性。
JASMINE 工具利用系统模型信息拷贝文件并存档，编译源代码，浏
览并释放空间。
I. LIFESPAN
生命期来自YARD 软件系统，严格支持变化控制。它适用于项目经
理监控各种变化的情形，只有经过授权的用户才能使用它。生命期使用
相关的数据库和询问语言，存储文字、二进制代码和图表，并为这些项
目提供版本控制。
目标集BELONG TO。。。负责批准对包进行改动的管理人员被指派此
包。生命期使用制图办公模型，这些模型建立在硬件设计方法论的基础
上。它识别状态量，偏移量，偏移触发器，命令行和用户权限。电子邮
件提供自动识别功能。报告建立在库存项目基础上，并可以进行改动。
在安全方面，配置项目设有密码和加密的文件名。它支持各种国际标准
的问题的提出，跟踪和正式改动控制。

bmccbj

122
一般认为测试信息也是一种配置项，它依赖于其它项目。生命期监
控改动的一致性标准过程。它决定什么系统使用回顾性模块，标识所有
需要被纳入回顾系统的开发人员并发布必要的控制文件。
改动一经批准，如何授权它并分配源代码是一项管理策略。以上工
作完成后，项目被从存储区调出，模拟，以开发项的身份重新提交。此
过程重复进行。
J. Network Software Environment（NSE）
由SUN软件系统开发的NSE是管理操作系统目录结构并从源代码获
取附加文件的一套应用体，附带一个数据库。NSE 为开发代码的项目组
提供工作空间。此工作空间通过一个合并并升级处于子空间和父空间之
间的文件的协议来支持递归转换。工作空间里的文件表示为一种结构
体，它代表对这种结构体的多种版本，除了最后一种，其它的结构体都
是不可变的。同一个工作空间的不同用户在此工作时都得经过检查并登
记在文件中。合并交叉工作空间的冲突问题NSE 提供了交互性支持。工
作空间能够高效地获取目录结构，这种目录结构用于存储源代码并从产
品，已建成的结构体和产品的逻辑结构中衍生构件。
K. PowerFrame
Powerframe 这个工具来自EDA系统，对计算机辅助设计工作提供配
置管理。它用一种统一的图解接口把用户屏敝在操作系统和文件系统之
外。操作时，用户拖出一个合适的工具菜单。POWERFRAME自动检索所有
相关数据，运行这个工具，在用户使用完毕时保存所有的改动。
POWERFRAME 把在产品中数据的几种组织方式合并起来以便用户集中精
力于那些仅适合于完成特定任务的数据，工程，一个展望，一个见解和