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系统。