变更管理（CM）术语是指一个组织或项目用来计划、执行以及对软件系统变更进行跟踪的流程和工具。统一变更管理（UCM）是Rational与我们的客户联合开发的一套特定的变更管理流程。UCM在管理文件、目录、组件和系统的生成与修改等方面为软件项目小组提供支持。从学术上说，变更管理流程由两条工作流组成：

软件配置管理（SCM）

缺陷与变更跟踪（DCT） 【批注：亦称作变更请求管理（CRM），此处避免与“客户关系管理”混淆。】

SCM处理版本控制、工作空间管理、软件集成、软件编译（Build）、软件分发及发布等流程。DCT处理流程与过程，通过这些流程与过程，缺陷、增强型请求与新特性被提交、评估、实施、验证及完成。

Rational拥有两种工具对这两条工作流提供相应支持。首先是Rational ClearCase，自动化SCM相关流程。其次是Rational ClearQuest，自动化DCT相关流程。同时使用这两种工具，就能自动化UCM。事实上，使用ClearCase和ClearQuest能够自动化几乎任何变更管理流程，但是如果需要为变更管理提供黑盒支持，那么UCM是最佳选择。

在Rational，我们已对问题“什么是UCM流程？”提供了多种方式的回复。我们提供产品文档、论述ClearCase与UCM的书、可免费订购的多媒体光盘。因此，如果已经对UCM有了一定了解，可能会问：“UCM相对其它变更管理流程的优点是什么？”这里将对此问题作一阐述。

首先要说的是，一种流程可能不是对所有软件项目都是最合适的。因而，脱离实际软件开发项目的环境来描述UCM较之其它变更管理流程更优，并无意义。所以相反，将要描述UCM与传统变更管理（CM）流程的差异。然后你就能决定怎样将这些不同点应用到自己的软件开发项目中去。

用UCM进行更高级别的抽象

如果你观察软件开发语言，具有几十年历史的计算机科学与工程，显而易见，其抽象水平已从机器代码级大为提升。在最底层，全都是1和0，只能期望非常早的程序员在此级别上工作。汇编语言很快出现，它对1和0进行抽象以提供雏形的机器指令如“load register X with value Y”。接下来出现了Pascal与C这样的语言，它们提供了更高水平的指令诸如“if-then-else”语句。那么，在今天，我们开始认识到可视化“编程”的潜力。通过对软件系统的行为建模，我们能让代码被生成。随着这些抽象的引入，更复杂的软件系统编程对开发人员来言已变得更容易和快速。

至于CM工具的演变，类似的情况正在发生。最初，CM工具仅仅由存储版本的存储库构成：文件及目录在保存并标识的给定时间点上的内容，可以必要时重新取出。接着，出现了允许用户管理工作空间的工具：可为特定任务或活动选择特定版本的文件及目录集合。同时，当类似存储库及工作空间这样低层次的抽象变得普遍起来并被广为接受时，高水准功能可凸显出来以简化变更管理流程。UCM就是干这件事的。让我们看看UCM包括的三个核心抽象：项目、组件基线、活动。

项目

典型地，软件开发小组以项目方式组织。这些项目，有时有子项目等等，有时没有，因此一个项目可能是非常大或非常小的。从变更管理角度来看，按项目方式组织与以下三个目标相适应：

• 第一，它标识了小组成员。这对安全目的及协作目的是有用的，两个目的对良好的变更管理都至关重要。
• 第二，项目限制了小组需要关心的文件和目录的范围。也就是说，对于全部文件和目录，在特定公司正使用的整个存储库中，项目标识了指派到该项目的某个开发人员需要考虑的精确子集。
• 第三，项目标识了小组成员正在完成的工作中的公共集成点。

所有这些可能听起来非常地稀松平常，但是由ClearCase和ClearQuest实现的UCM，其关键优势在于，项目实际上是存在于CM系统中的物理对象，该对象映射到现实世界的一个项目。与作为非CM工具概念的项目相比，可能达到的自动化与安全程度高得多。当新的开发人员加入一个UCM项目时，举例来说，他们被自动给出一个由他们所需文件与目录的正确版本预配置好的工作空间。

组件与组件基线

UCM的第二个核心抽象是组件与组件基线的概念。大多数的版本控制系统包含了存储库的思想在里面，它存储文件与文件版本的集合。一些工具，像ClearCase，还将这些文件组成到目录中去并存储目录与目录的版本。几乎所有重大开发成就都有大量数目的文件，这些文件包含了开发中需要编译生成系统的代码。这些文件通常组织成目录，这种组织常常以系统的软件架构来排列。在传统的CM系统中，这些关键目录从不以不同于其它目录的方式对待。然而，UCM引入了组件的概念，以区分并存储这些目录。UCM组件就是一个目录树，该树由具有一个组件根目录的文件及目录组成。

UCM缘何如此？

对项目来说，UCM组件的主要优点是更好的自动化。理解这一点的最佳方式是着眼于基线的概念。基线标识了文件版本的一个相关集合。基线，换言之，是在组件中选定每个文件的单一版本。几乎所有版本控制工具声称为基线化提供支持，但如果你仔细观察，通常你会发现他们真正支持的只有标签概念。标签是这样一个流程，你选定一个标签名并将此标签名称贴至一个或多个文件版本。通过将相同名称标至多个不同的文件版本，你得到一条伪基线。

用这种途径完成的基线存在着这样的问题，标签名称并未包含语义——除了那些如何使用工具的说明。无法通过查看一个标签就能知道什么文件与之相关联。事实上，当你在研究哪些文件具有该标签之时，同时，该标签可能被关联至新的文件、移至新的版本、或者从所选文件移除。当然，你能实施控制和锁定以强制你自己的标签语义，但UCM基线可为你解忧。这些基线在语义上是富涵（Rich）对象，可标识UCM组件的一个“版本”。通过使用它们，可确信组件中的所有文件都与相同版本关联。还能够确信基线不会从你的掌握下改变。一旦创建，UCM基线就不可改变，并且可用于定义更高层次的配置。一个完整的系统，举例来说，可由组件基线的集合装配起来。

活动

可能关于UCM的最大特色是，它是基于活动的变更管理模型。这意味着什么？意味着根据变更原因对文件的变更进行了分组。假定你正在修复一个缺陷或实现一项增强，比方说。不管何时你更改一个文件，你通过在签出时间声明一个活动，标识正作此变更的原因。活动可能是缺陷、增强型请求，或者仅仅是变更的一行描述，这依据你的缺陷与变更跟踪流程所需的严格度而定。UCM支持所有这些类型的活动——以及被选来定义你自己的其它任何类型的活动。

基于活动的变更管理的主要优点是，如果没有相关理由，那么没有文件能被更改。第二个优点是，变更被集成（或晋升）为单个、一致的整体。大多数时候，当你作变更时，你需要修改多个文件。例如，如果修正一个缺陷，可能需要修改一个C文件和一个头文件。你时常需要修改很多的文件。对于UCM，所有要做的就是选择“活动”来录制为所有文件而创建的全部新版本。正如对项目和组件一样，UCM将物理活动对象引入至CM系统中，它映射了一个现实世界的对象：“工作单元”。这具有立竿见影的好处：当你完成了一项指定任务时，比方说，你可以仅通过签入活动，而达到一次签入你所有工作的目的。

不过，还会有更深远的自动化与信息化益处。UCM在活动级别上推动贯穿系统的变更。也就是说，如果准备集成变更，可以“交付”活动。这与其它CM方式不同，它们需要使用文件集合或人工向某人发送物料清单，此人再列出包含于变更的版本。

事实上，基于活动的方式最大的好处在于活动与基线的联合工作方式。在组件被许多人修改以后，创建了一条新的基线。通过活动与基线的使用，使基线间不同点的判断流程的自动化成为可能。基线间的比较不仅产生自一条基线到另一条基线的变化文件清单，还有活动的清单！这具有巨大的好处：能自动生成发布版本说明；协助测试人员判断所必需的回归测试集合，以在每晚的编译后运行；等等。

基于客户系统

本文针对UCM的诸多能力及优点，权作抛砖引玉。从根本上讲，软件项目变更管理流程——通过Rational ClearCase和Rational ClearQuest来自动化——提升了抽象级别，以及通过将现实世界对象引入到CM系统中的自动化可行性。这些对象有项目、组件基线和活动。如果你是Rational ClearCase的长期用户，可能会在ClearCase的定制中意识到UCM流程的点点滴滴。很多这些基于脚本的变更管理流程，建立于ClearCase基础之上，在定义UCM的涵义中扮演了主角——同时将在决定UCM的未来变化中继续如此！