使用UCM进行更高级别的抽象

　　如果你看一下软件语言的发展，很明显，在计算机科学和工程十多年来，机器代码的抽象级别有了很大的提高。在最低级别上，所有都是1和0，并且我认为非常早期的开发工程师就工作在这个级别上。很快有了汇编语言，它将1和0抽象成基本的机器指令，例如用值Y加载寄存器X。接下来的语言例如Pascal and C，它们提供了更高次序的结构例如“if-then-else”语句。并且现在，在今天，我们开始认识到可视化“编程”的潜力。通过模型化软件系统的行为，我们可以让代码为我们而产生。通过引入这些抽象，开发者进行更复杂软件系统的编程会变得更容易和更快速。

　　类似的事情发生在配置管理工具的演变上。最初，配置管理工具只是由保存版本的存储库组成：一个文件和目录的内容在给定的时间点上存储和确定，并且在需要时可以重现取回。然后到了允许用户管理工作空间的工具：一个特殊任务或活动所选择的文件和目录的特定版本集。并且，随着较作为低级别的抽象，例如存储库和工作空间，变得普通和广泛被接受，较高等级功能可以放在顶端，以简化变更管理过程。UCM正是做这些。让我们看看UCM包括的三个关键抽象：项目，构件基线，和活动。

　　项目

　　通常，软件开发团队被组织成项目。这些项目，依次还有子系统，等等，因此一个项目可能非常大，或者是非常小。从变更管理的观点来看，项目的组织有三个目的：

　　首先，项目定义了团队成员。这对安全目的和协助目的很有用，这两点对好的变更管理非常关键。

　　其次，项目限制了团队需要知道的文件和目录的范围。也就是说，所有的文件和目录保存在库里，项目确定了开发者被分配的精确子集，那是项目需要考虑的方面。

　　第三，项目为团队成员所执行的工作确定了一个公共集成点。