配置管理的概念
标识：一种标识模式反映了产品的结构，标识了组件及其类型，使之唯一并且可以通过某种方式访问。
控制：控制产品的发布，并通过创建基线产品来保持软件的连续性以达到整个生命周期的变更控制。
状态记录：记录和报告组件的状态和修改请求，并且收集产品中组件的重要统计。
评审和复查：验证产品的完整性，通过确保产品是定义良好组件的组合来维护组件的连续性。
定义也包扩配置项、基线、发布和版本等术语，大多数CM系统通过组合不同程度上的功能来支持这些方面，一些CM系统提供的功能超越了以上的定义，这归因于（抛去其他原因）多个方面的认识，如不同的用户角色（在1.3和2.1部分有进一步讨论）、异种平台的不同操作环境、建立软件工程师在其中以和谐方式工作的大项目的支持。为了捕获这些额外的功能，有必要拓宽CM的定义：
制造：以一种透明的方式管理产品的构建。
过程管理：确保执行组织的过程、政策和生命周期模型。
团队协作：控制同一产品多个用户的工作和交互。
1.2 CM系统的定义
对于CM系统的组成，没有一种普遍接受的定义。举个例子，版本控制系统是CM系统吗？理想情况下，一个CM系统应该能够提供上面定义的所有功能，但是实践中，任何提供某种形式的版本控制、配置标识、系统构建、系统建模和企图提供CM（某种程度）功能的系统都会被软件工程（和销售）社区当作CM系统。必须注意到存在的CM系统都提供了它们独有的功能组合，而不是标准的。这个报告只包括了15个CM系统，目前至少有40种可以获取并使用的CM系统。
本文有必要阐明一个概念，CM系统和CM工具。一个CM系统可以看作是环境的一部分，CM支持的是集成环境的一部分，并且CM是以包的形式销售，一个CM工具可以被认为一个独立的工具。举个例子，Revision Control System(RCS) [15]是一种CM工具，因为它企图安装到现有的环境，但是因为这一点区别对本文并不重要，我们会用CM系统这一术语来表示这两种概念。
1.3 一个典型的CM用户场景
在开始讨论CM系统之前，为了展示一个参考的框架，我们首先介绍一个组织的CM用户场景。这个场景包括了许多具备不同职责的人：一个负责软件组的项目经理，一个负责CM过程和策略的配置管理经理，一个负责开发和维护软件产品的软件工程师，一个验证产品正确性的测试员，确保产品高质量的质量保证（QA）人员和一个使用产品的客户。
每一个角色都有自己的目标和任务，对于项目经理，目标是保证产品按计划开发，因此，经理监督开发过程，通过分析生成的软件状态报告，执行系统复审，及时发现问题并处理。
配置经理的目标是确保代码的产生、修改和测试的过程和策略是可追踪的，同时保证项目的信息是可访问的。为了实现维护代码变更的控制的技术，这个经理引入了一种对变更进行正式请求的机制，以达到评估变更（通过一个负责确认变更的变更控制委员会（CCB））和授权变更的目的。这个经理要为工程师创建和分发任务列表并创建项目环境，另外，这个经理还要收集软件系统组件的统计信息，例如确定这个系统的哪些组件可能会出问题。
对于软件工程师，目标就是有效率的创建产品，这意味着工程师不应该被非必要的工作打扰，例如他人创建和测试代码，支持产品文档等，但是与此同时，他们还要保持有效率的交流和协作。他们借助工具创建协调一致的产品，通过通知其他人关于任务需求和结束的信息来交流和协作，通过合并代码并解决冲突来将变更传递到所有人的工作中去。产品中的每个组件的演进历史都会保存，通过记录修改的内容和记录的修改原因。每个工程师都在自己的工作区域创建、修改、测试和集成代码，在特定点上，代码会纳入基线，也就是作为进一步开发的开始，也是针对其他目标机器的并行开发的改变的开始。
测试员的目标是保证产品经过测试且达到满意，这包括了测试特定的版本，并且保存对应测试的记录，任何报告的错误会被反馈到合适的人，并在修正后进行回归测试。
QA经理的目标是保证产品的高品质，这意味着特定过程和策略必须通过合适的确认，产品的缺陷必须被修正并且分发到产品的变体中，并经过进一步测试。客户对产品的抱怨也必须要跟进。
客户使用产品，不同客户使用不同的版本和变体，客户依据一定的过程来请求变更以指出缺陷和改进产品。
理想情况下，一个符合这个场景的CM系统必须支持所有这些目标、角色和任务，这意味着这些角色、任务和目标决定了CM系统的功能需求，这篇文章尝试展示完成这些特性的概念。
2.1 用户角色
就像1.3中的场景所描述的，一个CM系统有许多不同的用户，每一种用户都属于特定的角色，对CM系统也有不同的视角，因此对CM系统有不同的需求。图1说明了项目经理、配置经理、软件工程师、测试员、QA经理和客户对CM系统的期望，每一个方框代表了一个功能域，图1中的方框（审计、统计、控制、组件、结构和构建）是可以存在于任何CM系统的功能域，但是当与团队和过程功能结合后，就可以组成了一个全盘的（或者说是复杂的）CM系统。
图1
这些功能域有：
· 组件：识别、分类、保存和访问组成产品的组件。
· 结构：代表了产品的架构。
· 构建：支持制品和产品的构建。
· 审计：保持产品和过程的审计轨迹。
· 统计：收集产品和过程的统计信息。
· 控制：控制如何和何时进行变更。
· 过程：支持产品功能正确性的管理。
· 团队：支持项目团队开发和维护一系列产品。
这些功能的需求会在下面详谈。
对于组件的需求包括：记录组件的版本，区别和区别的原因；标识组成一个配置的组件，其中包括各个版本的组件；标识产品和其扩展的基线；确定代表特定项目组件和制品集合的项目环境。此外，用户需要版本库或运行库来保存和捕获组件和CM信息，例如保存源代码、对象代码、可执行程序、图表、文档和基线等。
对于结构需求，用户需要：通过代表产品组件的列表来建立产品的模型；指出组件、版本和配置的分界点，以此使之可重用；标识和维护组件的关系；选择兼容的组件来组成正确和一致版本的产品。
对于构建需求，用户需要：简化构建和编译产品的过程；在任何时间对产品的状态进行快照和冻结的能力；通过减少重新编译的组件和节约空间来优化构建系统的机制；利用变更影响分析预测衍生物发生的更改；在任何给定时间更方便的重新生成任何阶段或部分的产品。
对于审计需求，用户需要：所有变更的历史；在产品和他们的演化中能够追踪所有相关的组件。所有所作工作的详细日志。
对于统计需求，用户需要：记录统计数据来检验产品状态的机制，更容易的生成关于产品和过程的各个方面的报告。
对于控制需求，用户需要：小心的访问系统的组件防止未保证的变更和变更冲突；在线的变更请求表单和问题报告支持；也意味着要追踪问题原因、时间和处理的负责人。用一种控制的方式传递变更，贯穿不同但是相关的产品版本；分割产品达到减少变更影响的方法。
对于过程需求，用户需要：支持他们的生命周期模型和组织政策；识别将要做的任务，以及这些这些任务何时和如何完成的能力；与正确的人交流相关信息的能力；和记录产品知识的工具。
对于团队需求，用户需要：单独的和组的工作空间；合并修改时解决冲突的方法；支持创建和维护产品族的工具。
需要注意过程框和团队框被表示成重要的功能，这是因为它们会和所有其它部分互相影响。对一个用户来说，一个理想的CM系统应该支持所有的集成了团队和过程的功能域，目前没有一个单独的系统支持所有这些功能域。
2.2 CM系统的集成
任何一个CM系统都有与环境集成程度的概念，一个CM系统可以与其他工具共存或完全集成。集成包括了环境的各个方面：过程、工具集和数据库。过程集成意味着CM系统使用模式（组成了CM过程）的结合。工具集集成意味着在环境中安装所有的CM系统，至少是与环境中的其他工具可以共存。举个例子，用户希望CM系统能够在编辑器中执行“保存”时创建一个新的版本。数据库集成关注CM数据库的逻辑位置－－是否与现存环境的数据库以某种方式合并，或者是它是一个独立的实体，或者是它利用了其它数据库的信息。所有这类集成都是普通的工具集成和技术迁移问题。但是自从CM系统尝试影响环境中的大多数对象和对象的整个生命周期的所有阶段时，CM系统的集成开始对环境中的许多工具产生了重要的影响。大多数CM系统与其他工具共存，而且有一些环境让CM成为他们自身的一部分。
2.3 何时开始使用CM系统
这要看项目组何时在开发和维护的产品上开始使用CM系统。一些小组选择在产品经过了开发周期并准备好交付给客户方时，另一方面，一些小组选择从项目的一开始就将所有的事情放在CM之下。两种方式都有各自的成本，举个例子，团队会根据变更的成本作出选择，如果需要许多手工的过程（例如填写变更请求单，获得CCB的通过和确认），团队一般会选择在开发的主要过程结束后纳入CM控制，但是如果变更请求过程可以在线操作，只需要花费较少的时间和人力，CM将会在较早的时间被引入。理论上讲，CM适应于产品的整个生命周期－－从概念、开发、产品发布、客户交付、客户使用到维护。理想情况下，CM系统必须尽可能将成本最小化，因此应该尽早将CM应用到项目。然而，现存的CM系统，容易将精力集中在产品生命周期的特定阶段，所以用户会被功能限制。
2.4 CM控制的级别
有许多辅助CM执行的步骤、政策和工具，他们会对用户和产品的演进提供不同程度的控制。例如，它们会要求工程师提交正式的书面的变更请求，接着是CCB的评估和对变更的授权。然后配置经理为软件工程师创建工作区，从受保护的版本库选取特定的文件放置到这个工程师独立的工作区。另一方面，另一种不同的步骤、政策和工具或许允许工程师直接用电邮通知配置经理和CCB的其他成员他的变更请求，然后这些成员立刻反馈，经过批准，变更请求指派给一个工程师，然后这个工程师直接从版本库得到代码并进行修改，所有这些操作不需要手工的干预，因为CM系统可以自动的记录所有的访问，一个正式的修改过程记录会被创建。
第一个场景被认为是对任何活动都非常严格和积极的控制，而后一个场景则是对活动宽松和被动的控制。最好不要在第一种场景进行经常性的修改，因为人力成本很大，而第二种情况鼓励频繁的修改，因为这很容易。不同级别的控制可能更适合于产品生命周期的一定阶段，例如，第一种适合维护阶段，而第二种适合开发阶段。无论使用何种CM系统，在产品的演进的某个时间点上都有特定级别的控制，它会限制，加强用户过程或者两者皆有。现存的CM系统提供了各自的控制级别，或松或紧，很少具备允许用户选择控制级别的灵活性。
2.5 区分过程和产品
CM包括了过程和产品，一个CM过程代表了一系列依序执行的CM任务，本质上讲，这个过程是将要做的事情、及其执行者和执行方式的计划，对过程的支持是一种管理功能。过程模型会考虑组织和软件开发生命周期模型的策略和步骤。CM产品是工程任务过程的结果，一个CM系统需要同时提供这两个方面的功能。现存的系统提供了一些产品和过程的支持，但是同时支持通常并不是很简单。
2.6 CM的自动化程度
如前所述，CM通常是手工和自动步骤的组合，有可能在不需要任何即时辅助的情况下执CM，但这是没有效率的，我们的目标是在CM的非创造性部分尽可能的自动化。例如，即使已经有系统可以提供完整的完整的自动变更请求，仍可以用在组织的策略文件夹中写文档的方式来填写变更请求表单和反馈，而不是即时捕捉和执行。尽管每一种CM系统都提供了不同程度的CM自动化功能，仍需要用户用手工手段来作为自动步骤所不能完成任务的补充。
2.7 CM系统的功能
现存的CM系统提供了CM部分必须的一些功能，但是没有一种系统提供了满足所有不同用户需求的功能，改进需要时间，需要随着用户对环境架构更好的理解来完成。下一部分重点介绍现存CM系统中概念的映射。
处理过程相关功能的概念包括环境管理、契约、变更请求和生命周期模型，将会在下面描述。
软件配置管理概念－3,CM
前一小节简述了CM系统关注的需求，本小节将详细论述CM系统的功能。某种程度上讲，这部分将验证上一小节中提到的支持某些功能域的概念，这些概念通过对CM系统演进的表现来组织，每一种概念在一种特定的CM系统下描述。CM系统关心的将要讨论的功能域包括：组件、过程、结构组合、构建特性和团队概念。图2显示了CM系统的概念图谱，下面是对概念和优势的简要描述。这一部分以一个总结和一个对这些概念优势和限制的分析作为结束。 
系统的概念
软件配置管理概念－3.1 警告
必须注意到我们讨论的概念和系统都是现实存在的，而不是一个完全的总结或者现存的演化。对于每一个概念，会讨论一个CM系统。也必须注意，有一些CM系统确实提供了图谱中显示的很多功能。概念是从特定CM系统直接获取的，每一种CM系统都有各自的概念和语义，因此对于自动化功能没有通用的术语。为了重点突出，对概念的描述将会简化，因此有可能没有将概念（和它们的系统）的能力完全描述出来。但是，为了更好的展示一个图谱和专著于CM的基本概念，简化是有必要的。本文引用的CM系统的在附录中有汇总，这个汇总提供了一个每一种CM能力更全面的列表。
软件配置管理概念－3.2 组件概念
组件概念用来标识和访问软件产品的组件，就是下面描述的是版本库和分布式的组件。
3.2.1版本库
版本库概念是一个CM系统的基础，Revision Control System (RCS) [15] 提供了针对ASCII文件的版本库，实际上，版本库是一个文件的中央仓库，并且提供了版本库中文件的版本控制。版本库中的任何文件，可以看作在CM控制下。版本库中的文件是不可变的，不可以更改。作出修改意味着创建文件的一个版本，所有关于文件和其内容的CM信息都保存在版本库中，因此，CM控制适应于版本库中的任何文件。为了修改一个文件，用户需要检出（check out）特定版本的文件到它们的工作目录（working directory），然后根据自己的判断开始修改，最后检入（check in）回版本库，这样就创建了文件的一个新版本。这样用户就不能同时检出同一个文件并修改，在这个用户将其检入回去之前，检出的文件会被锁定（以版本库的视角）。一个版本号码会自动与新版本关联；此后，用户可以在任何时候检出特定版本的文件，当然缺省检出的是最新的版本。对最新版本的更改会产生新的版本，然而对老版本的修改会导致一个不同的版本。总之，版本号方案和使用模式产生了文件的版本历史树，指出了版本的前任和后继。版本库保存了文件的历史信息，包括文件的不同版本和修改的原因、作者和时间。需要注意的是并没有保存所有版本的完整代码，而只是保存了版本的区别，也就是所说的增量，这样就节省了存储空间和对最新版本的访问时间。文件可以使用某个状态标记，并可以根据这个状态值检出。文件也可以根据修订版本号、时间和作者检出。版本库通常与其保存文件的目录关联，总之，一个版本库捕获CM信息并以不可变对象的形式保存文件的版本。
3.2.2分布式组件
Sherpa Design Management System (DMS) [7] 提供了一种文件分布在不同硬件平台上的版本库，这个版本库逻辑上是集中式的，但版本库中的数据可以是物理上分离的。Sherpa DMS可以识别分布式并在执行CM时考虑分布式这一点，例如，通过对文件格式的必要转换提供容错灵活性。所以，对用户来说，分布式是透明的－－用户可以像处理自己工作站的文件一样处理版本库的文件。一组地域上分离的用户可以工作在同样的文件配置下，文件的多份拷贝可以存在于不同的工作站，Sherpa DMS知道文件最新版本的位置，版本库中文件的任何修改都会更新到工作站中的所有本地拷贝中去，因为系统清楚所有本地拷贝的位置。更新可以是交互模式或者批量模式，实际上，分布式用户已经访问了中央版本库，对他们来说，这个CM工具使异种工作站跨越了网络。
软件配置管理概念－3.3 过程概念
3.3.1 环境管理
PowerFrame [13] 是为电脑辅助工程/设计领域设计的系统，可以帮助用户不必关心系统和配置的底层细节，用户只能看到电路设计这个特定领域，而PowerFrame管理用户工作的环境。项目的数据以图像的形式展现，而不是隐藏在目录的形式，PowerFrame提供了工作流程管理来指导团队成员的工作过程。例如，一个工具运行会包括线路的创建，验证和检测性能特性的模拟。在这些活动中，PowerFrame自动得出工具相关的当前环境，如数据集，命令文件和调用工具的选项。下一次，用户只需要选择线路设计和工具功能就可以重新开始工作。用户只能见到：执行特定任务的合适工具；逻辑模式或布局设计之类特定表单的数据展示；属于特定领域的命令表单。用户可以执行不同粒度的动作，例如某个环境数据的条目或配置。用户不必担心版本控制或文件之间的关系，因为系统知道数据来自不同版本的电路，在后台处理了这些任务。实际上，CM系统以一种领域特定的方式捕获用户的工作环境，消除了用户记住工作状态以及所有数据项目及其关系的必要。
3.3.2 契约
ISTAR [9] 环境支持对软件开发过程的正式确认方面进行建模，也就是建立一种契约，确定某种任务的输入和交付，契约的制品被记录下来并成为配置项目，这些项目包括契约模型信息流，任务的开始和完成，产品的任务和组件结果的传递及其交换。一个契约被满足接受条件的交付件的传递完成，交付件被传递到过程模型的特定元素，如生命周期的不同阶段或不同的人，这些制品的移动会被顺序记录下来。契约中的过程会被监控，因此不同的制品（例如交流）会被记录下来。实际上，契约代表了某个配置项上的正式计划、记录和一个单元的工作。
3.3.3 变更请求
在LIFESPAN [11] 中，一个变更请求代表了对一个变更的文档请求和模型关联的过程。LIFESPAN通过一系列的表单和一系列状态表示的过程为变更请求建模，一个客户可能提交一个即时的软件表现报告（SPR），指明了一个问题或者是对某个组件进行加强的请求，这允许报告调查最初的能够诊断这个问题的设计者和实现者。作为SPR和变更影响分析的反馈，会提交一份设计变更（DC），这是组件变更和变更方式的细节。然后这些人会自动进入变更控制委员会，他们会收到关于DC的电邮通知，并且必须投票确定是同意还是否决变更。一旦通过DC，就会产生一份代码的开发版本，DC的状态变为活动，并且锁定变更的代码。当完成了修改，就会冻结新版本，并且提交，以便有QA权限的人检查和确定。经过代码的确认，就会进入“确认”状态，DC的状态变为“确认”会发送“新版本已经可用”的邮件到用户。用户会收到一份Software Status Report(SSR)，会关闭最初的SPR。尽管SPR，DC和SSR没有提供用户和维护者交流的方式，但是提供了：特定变更请求关联的历史变更；变更过程的状态报告；变更完成的审计；变更影响分析和确保合适的人在合适时间执行各自任务的支持机制。实际上，变更请求是控制变更过程的辅助。
3.3.4 生命周期模型
Change and Configuration Control (CCC) [5] 提供了支持特定生命周期模型的概念，包括各个阶段的转换和这些阶段的数据管理，这是通过将整个生命周期分为开发、测试、确认和发布来完成的。这种分离允许不同的用户如软件工程师和测试员可以在同一份代码独立的执行他们自己的工作。这种阶段的分离和转换，以及独立的工作是通过将代码存入每个阶段独立的配置实现的，也就是说，产品是在某一基线基础上开发的。每个基线作为四种配置存在：开发、测试、确认和产品。配置是组件的一种等级关系，每个基线都有自己的方式。代码开发出现在开发配置，传递到测试配置以进行审查，然后是确认配置，最后是用户使用的产品配置。为了进入到下一个阶段，需要经过不同用户必须授权这个转换的交互（例如项目经理和测试经理）。在任何时候，对某个组件确认的等级可以从其所属的配置来得到，实际上，一个生命周期模型是通过不同配置状态实现的。
这个概念将处理：选择一个结构的组件；捕获一个组件及其结构的变更；访问结构的一部分；描绘和保持一个结构一致性的特性，包括：变更集、系统建模、子系统、对象池、属性和一致性维护，这些将在下面描述。
软件配置管理概念－3.4 结构和构建概念
3.4.1变更集
Aide-De-Camp (ADC) [1] 抽象了版本库中组件不同版本的区别的这一基本概念，使之成为一个区别关系并可以被访问。区别的关系，以及其应用的文件和其他变更的细节组成了变更集。ADC 捕获对一个配置的变更集，并且这个变更集可以用来构建一个配置的自定义版本。这个变更集有一个名字，可以在操作中使用，用户可以指定一个表达式来创建配置的特定实例，这个表达式可以为某个变更集指派一个应用的基线。一个变更集可以看作是和前一个变更集是相互独立的（会创建一个版本历史），也可以看作是非独立的（历史中选定的一部分被应用）。因此，用户可以工作在最新的版本上，也可以在自定义的版本上。变更集捕获对所有文件的所有修改，包括修改的原因和细节，以及修改的作者和时间。用户检验修改的范围，ADC会自动记录所有的变更细节。例如，用户希望对一个配置作出一个主要的修改来修正一个问题，用户指派一个变更集并且修改这个文件。这个变更集捕获：对配置中所有文件作出修正的原因；所有实际修改的代码（在配置中每个文件的区别）；所有关联的文件变更；和作出修正的人和时间。用户在浏览每个文件或变更集时可以看到这些信息的大部分，作为汇总，变更集代表了一个产品的逻辑变更，也意味着创建版本的任何配置不必依赖于那个配置的最新版本。
3.4.2系统建模
系统建模描述了一个软件产品的结构和它的组件及组建的创建方式。Jasmine [10] 系统模型是一个文本描述，用户可以调整，并且用来执行他们的任务。Jasmine系统建模由代表了四类信息的功能描述：（1）产品组件的关系，（2）版本绑定信息，（3）构建规则和（4）验证规则。关系描述了：产品的模块分解，如子模块的等级；组件的依赖关系，例如模块的创建次序；还有根据共同属性对组件的分类，如建立源程序或对象模块组。这种根据关系的产品描述叫做模板，这个描述捕获了它的结构。使用功能操作和关系，用户可以从简单中构建复杂的关系。这使的Jasmine可以回答用户定义的查询，例如修改某个模块会影响哪些组件。系统模型包括了族的概念，可以用来捕获产品的历史。一个族描述了组件版本的更迭，许多用户定义的产品版本组成了族，与之相关的还有每个版本的属性如创建日期和作者。查询，版本选择和规则都是基于这些属性，构建规则记录了当前组件是如何生成的，以及未来会怎样生成，例如记录编译器的版本和编译选项。验证规则指定和记录了产品的结构和组织约束，例如源代码和库模块必须一致（所有的二进制模块都是从这些源代码模块编译而得）。通过选择一个组件的一个版本，就会使用族的选择表达式执行评估，来确认这个模块查找的路径，选择的作为结果的模块就会以一个镜像（image）的形式绑定到模板。许多工具，如浏览器，模块retriever，调试器和内置模块分析器可以引用和处理这个系统模型。实际上，系统建模是对产品某个实例的一种抽象，通过对产品的完全描述，辅助其他工具来维护产品的完整性。
3.4.3子系统
Ratinal [14] 环境支持将一个大的Ada产品分解成几个部分，允许限制变更影响的范围，这几个部分叫做子系统。子系统接口规范及其实现，代表了配置项目。因此，它们可以被看作一个整体，并通过它们的名字访问。子系统中的组件对其他子系统的组件不可见，除非是通过结构规范指派公开的。Ratinal环境会在运行时检查实现满足了接口说明，作为结果，可以在接口规范的实现上独立进行工作，只要用户愿意。重复编译只会在子系统的范围内进行，除非接口有改变；在任何时候，任何使用这些组件的产品需要重新编译，对接口规范的修改可能会需要整个产品的重新编译。子系统对它们的组件有版本控制，子系统可以是某个特定的版本。用户可以混合匹配子系统来组合一个产品的特定版本。总之，子系统代表了是一种限制变更和编译影响的方法，对于环境来说，检查了产品组合部分的正确性。
3.4.4对象池
在系统建模中使用了这个概念，Domain Software Engineering Environment (DSEE) [8] 拥有生成特定导出的对象版本必要的信息。导出的对象放置在对象池中共享给用户，DSEE可以让用户为共享的对象指定对象期望的来源属性。导出的对象池保存了一组二进制文件和其他转换工具产生的产品。每个导出的对象都有对应系统模型的信息，包括源代码的版本和转换器用的转换选项，关于导出的用户注释，日期，时间，参与人和导出的位置。这些信息被叫作bound configu-file lists.ration thread (BCT)，当DSEE进行了系统创建，它会为系统模型的每个组件计算目标BCT，DSEE会查看池来确定是否有符合期望的导出对象存在。如果有，就会被使用；如果没有，就会创建。因此，每当用户需要一个特定的导出对象（或是兼容的），DSEE可以重新使用池中的对象，而不需要重新生成对象。用户不必知道是否有导出对象存在；DSEE会检查所有的事情。一旦池中的某个对象已死（根据未使用时间），DSEE可以删除它们，清理空间。这样节约了编译时间和空间需要，并且重用了以前的工作。DSEE也提供了不同类型的对象池，例如对于源文件导出的对象一直会从版本库检出到特定的用户。实际上，CM系统优化了重新生成组件，并且使共享导出对象最大化。
3.4.5属性
Adele [2] 系统通过使用具备建模能力的实体关系数据库来归纳版本库和系统建模。一个产品用数据模型描述，而Adele根据模型执行操作。产品组件通过有属性和关系的数据库对象代表，属性关联到每个对象以描述对象。一个属性有一个名称和一个值，例如属性名“delta”代表了对象是以ASCII形式保存，可以被压缩；它的值可以是“true”或“false”。需要区分两种类型的属性：预定义的和用户定义的。前者是Adele管理的，后者则是用户声明和管理的。一个预定义的，特别的属性是“type”，这个属性对每个对象是不可变的，在Adele中它代表了主要的CM类型（例如组合对象，文档，修订版本和元素）。关系定义了对象之间的依赖关系，例如，对象B源自对象A，用户可以按照对象间的属性描述配置，而不是对象特定版本的列表。Adele根据对属性及关系使用选择的规则和限制进行初始化和创建配置，用户可以对产品的期望特性定义任何结构（而不只是一个等级结构），因此，用户可以用一种高级别的方式来描述一个产品，而不仅仅是组合冗长的文件列表。
3.4.6一致性维护
Configuration Management Assistant (CMA) [6] 支持基于产品抽象描述的配置构建和验证，也就是组成配置的组件的使用成功和失败的信息。数据建模工具包括了用户用来描述配置的预定义属性和关系，基于这些属性和关系的语义，CMA可以确定哪个配置（组件实例集）是可用的，为了可用性，一个配置必须完全的，毫不含糊的，完整的和没有版本问题的。这意味着配置必须包括所有组件的实例而不会包含某个组件的多个实例。属性的类别代表了用户定义特性的属性，如约束，类型和版本，关系的类别代表了依赖的类型，例如逻辑，兼容组件，实例和等级依赖。每当构建一个新的配置，CMA会利用前一次的信息构成配置，通过这种方式，CMA可以预测配置是否可用。新的配置会被添加到数据库，用来分析以后的可用性，因此用户可以反馈系统来识别任何不完整性，或者是在创建和重用配置时保存完整性。
软件配置管理概念－3.5 团队概念
处理工作在一个产品的软件工程团队的隔离、协作和同步的概念有工作区、透明视图和事务，将在下面描述。
3.5.1工作区
"shape" [17] 的工作区概念主要用来防止用户干扰其他人的工作，它支持在CM下的易变对象上持续工作的概念，工作区是通过版本状态模型实现的，这意味着一个属性 “state”是与一个组件的版本关联，根据这个状态（例如“busy”或“frozen”，），决定了一个组件是在私有工作区还是在公共版本库。一个 “busy”的组件是在改变的，不可以被公共使用，而一个“frozen”的组件不是在变的并可以被公共使用。组件在经过合适的人确认后，可以提升到公共版本库并被公共使用。实际上，工作区提供了隔离的工作，并且提供了针对不易变对象公共的长期版本库和针对易变对象的私有的短期版本库的建议。
3.5.2透明视图
Software Management System (SMS) [18] 通过使对象显示和提供了版本库的透明视图加强了工作区的概念，这意味着只有用户关心的文件版本可以被看到；所有其他版本在视图（尽管这些版本在物理上都存在）中被隐藏。例如，任何对最新公共版本的修改可能不需要在工作区中可见，用户被隔离在公共修改之外，工作区给了用户特定版本的样子。工作区里还提供了工作区相关的版本号码，新版本是私有的，在从工作区发布之前对公共不可见。一个配置从公共版本库检出，然后用户被指派访问这个工作区。工作区的组件属于工作区而不是用户，只有工作区注册的用户可以修改配置，只有工作区中的组件可以访问。总之，透明视图提供了一种视图机制，保护了对配置的非授权访问。
3.5.3事务
Network Software Environment(NSE) [12] 的事务概念代表了工作的分类，反映了产品的结构，支持不同用户工作的隔离，修改的合并。一个事务包括了一个环境和一组命令，环境提供了类似于工作区和透明视图的概念，它显示了保存源文件和导出对象的目录结构，如"acquire"、"reconcile"、"resynch"和"resolve"的命令提供了穿越环境的交互。它们代表了用来协调和同步动作的协议，也代表了实际修改的交流。用户可以在自己的环境中独立工作，修改同一个或不同的配置。用户可以用一个新版本的配置更新版本库，NSE帮助合并修改。但是它会检查当前版本库存在的东西（可能是其他用户放置的）不会与新的变更发生冲突。如果有冲突， NSE会通知用户合并的问题，并提供解决冲突的帮助，用户可以请求版本库的任何修改进入到他们各自的工作区。总之，事务同步和分类小组修改了产品的相同或不同部分。
软件配置管理概念－3.6 总结和图谱分析
图2展示了不同CM系统提供的CM概念，概念和它们的目的是：一个捕捉历史和易变文件的版本库；实现版本控制下的分布式数据的分布式组件；表示一组工作的计划的契约；一个捕获对配置的修改和独立选择配置的修改集；加强软件演进的组织过程的生命周期模型；完全描述和记录产品结构和记录的系统建模。建立重用导出对象并优化产品创建的对象池；允许通过特性而不是列表选择配置的特性；对配置组件不一致性自动检测和预测的一致性维护；用来隔离易变配置的工作区；查看配置并保护非授权访问的透明视图；最后是针对配置的分类修改的事务。这些概念代表了CM系统功能的进展。 图谱的拓扑图意在展示概念的演进，例如图2的从左到右，通常来说，有一定的进展，分别在对建模不同的过程，捕获组件，描述产品的组件，优化产品的构建，描述组件依赖和分组工作等方面。图的一翼指出了相关的进程，例如，本文描述的变更请求和生命周期模型是相关的：生命周期模型包含特定的变更请求模型，变更请求操作版本库。
这个图谱没有显示所有的概念，没有说的概念包括：组件演进的粒度（例如从版本识别到配置识别，再到配置的版本）；系统模型的进展（例如从命令文件到make文件，再到作为版本化对象的系统模型）；识别不同角色和不同类型的变更（例如缺陷对增强对紧急补丁）；和当前的研究工作。
考虑到是从CM系统概念的抽象，与实现相比本文中的描述是简化的，只是要发现一些共同概念，但对这些概念确实没有共同的术语。概念和其实现的区别并不是很清楚，例如，工作区的实现在不同CM系统中并不相同，因而为用户提供了不同的功能。因此，这些概念一定要是所有实现的最低共同点吗？因为事务包含了工作区和透明视图，那么工作区，透明视图和事务就真的是一个概念吗？或者它们是三个概念，就像图上显示的？
抽取CM概念的另一个困难是过载的概念，也就是概念有太多的目的（这些目的在CM系统中并不统一），例如，图谱中的Rational子系统概念支持限制变更的范围，尽管子系统提供了更多的功能，它可以：提供名称范围边界，对工作区来说则代表了工作在一个团队的不同配置或同样配置，提供了接口检查或者代表了一个不易变和可执行组件（Rational术语的"load view"）。所以，为了讨论子系统，有必要专著于某个特定的方面，因此，过载造成了抽取基本概念的难度，类似的，概念的组合部分，或者是某个概念特定实现的副作用，让概念的抽象更是充满技巧。例如，考虑一个变更请求，生命周期的角色（例如配置经理和测试经理）和阶段（开发和测试）是否对其至关重要，还是毫不相关？
在任何等级，概念的图谱提供了开发的开始点，或至少抽取一个CM模型－－一组基础CM服务－－从存在的CM系统。此外需要许多检验工作：图谱的用处，是否有其他概念，如何定义，命名和展示概念及其它语义，如何组合概念到一个有用的CM系统
软件配置管理概念－4,CM系统的未来
图2展示的概念代表了典型的商用CM系统的概念，随着研究的继续，以及使用和组合概念的经验，许多新武器将会加入进来，这意味着有可能CM系统将会获取一组新的基础CM服务来满足用户的需求。但是，不考虑是否每个CM系统设计师正在努力实现相同的特性，始终有一些政治和技术问题影响着CM系统的未来。（政治问题关系到市场和标准；技术问题关注实现特定机制的可行性。）
一个主要的政治问题是电脑辅助软件工程（CASE）工具的演进。例如，是否CASE工具零售商会回避用他们的工具范围内实现CM，并且假定环境零售商将会在它们的框架中提供CM支持？如果CASE零售商与其自己的CM工具支持绑定，当用户安装它们的CASE工具时，将需要解决集成不同CM 系统的问题。同样，从零售商的角度，他们会从本质上重复解决许多环境框架解决的问题吗？
另一方面，如果CASE零售商不将CM工具组合到工具中，他们可以依赖CM环境工程提供合适的框架来集成CASE工具，并且同时提供一些全局性的CM功能吗？没有人知道这些问题的答案。在任何情况下，CM系统与环境的关系有一种隐含的标准，反之亦然。
许多技术，研究问题影响CM系统的能力，类似的问题正在上升。构建CM系统基础的合适技术是什么？一个支持对象持久化的面向对象数据库是否合适？什么级别的环境是CM合适的？它在数据库中必须是基础级别，环境框架的集成部分吗？或者是将CM指定为架构中的较高等级？CM的机制是否可以与CM 功能分离，也就是是否有标准的CM原型可以用在所有的环境来支持所有的CM功能？是否有一个统一的CM模型？是否可以支持分布式的CM支持？地理位置分离的团队是否可以使用同一个CM系统来进行本地CM和系统集成？这是业界，特别是国防部的协议中的主要问题。是否有可能支持跨软件开发？工程师是否可以在主机开发一个产品，并在维护中同时发布到目标机器？标准是否扩大了CM系统的限制？是否CM同样的支持一个百万行代码的产品和一个上亿行代码的产品？是否可以对CM过程的所有方面，包括用户敏感的部分建模，并在CM系统中实现？
以上问题的答案还不清晰，进展很有可能会源自各个方面－－从CM系统零售商，环境架构师和研究员，工具集成员，软件过程建模论坛和电脑辅助设计/工程，电脑集成生产商世界。
软件配置管理概念－5,结论
CM是对软件产品演进的管理，在CM系统的操作级别，CM是标识、控制、统计、审核、复审、加工、过程管理和团队协作。这是一个软件工程环境领域取得的进展，这显然是来自概念图谱，也是来自现存CM系统和其能力。本文展示的图谱是对许多不同CM系统实现的概念的快照，每一种系统专注不同的用户问题－－角色、集成、控制、自动化程度、过程对产品的支持和使用系统提供的功能进行CM的最佳开始时间。希望提供这个图谱可以辅助我们理解CM系统的能力，并且能够提供一个讨论CM工具支持的共同框架。