。这对安全目的和协助目的很有用，这两点对好的变更管理非常关键。
其次，项目限制了团队需要知道的文件和目录的范围。也就是说，所有的文件和目录保存在库里，项目确定了开发者被分配的精确子集，那是项目需要考虑的方面。
第三，项目为团队成员所执行的工作确定了一个公共集成点。
这些听上去非常平凡，但是UCM关键的优势在于在ClearCase和ClearQuest执行时，项目是一个物理对象在这个配置管理系统里，它规划了实际的项目，允许一个比可能的更高程度的自动化和安全，如果project项目不是配置管理工具的概念之一。例如，当新的开发者加入到一个UCM项目时，他们自动地被给定一个预先配置好他们所需要的文件和目录的正确版本的工作空间。
构件和构件基线
UCM里第二个关键的抽象是构件和构件基线。大多数版本控制系统包括存储库的概念，存储库是文件和这些文件版本的集合。一些工具，例如ClearCase，也将这些文件组织到目录并保存目录和目录版本。几乎所有重大的开发工作都包含大量的文件，这些文件包含的代码需要在开发下构造该系统。这些文件组织到目录里，并且这些组织经常列成系统的软件架构。在传统的配置管理系统中，这些关键的目录和其它的目录是不会被看成是同样的。然而，为了区别并保存这些目录，UCM引入了一个component构件的概念。一个UCM构件简单来说，是一个由同一个构件根目录下的文件和目录组成的目录树。
为什么UCM做这些？
UCM构件的主要优势，和项目一起，可以更好地进行自动化。最好理解的方法就是查看关于基线的概念。基线定义了一组相关联的文件版本。基线，换句话说就是，选择在构件里的每个文件的一个版本。几乎所有版本控制工具都声明支持基线，但是如果你走近观察，你通常会发现他们实际上只支持打标签的概念。打标签是一个过程，通过此过程，你可以选择一个标签名，然后将此标签名附在一个或多个文件版本上通过将相同的名字粘附在许多不同的文件版本上，你就可以得到一个基线。
使用这种方式进行基线化的问题在于，没有由标签名所暗指的语意上的含义－－除了那些提示你如何使用这个工具。你不能查看标签和知道特定关联到它的文件。实际上，这告诉你调查哪些文件有这些标签，同时，标签能够关联到新的文件，移动到新版本，或者从选定的文件删除。当然，你可以执行控制并锁定执行你自己的标签，但是UCM基线为你解决了这些问题。这些基线从语义上描述了对象定义的UCM构件版本。通过使用这些版本，你可以确定这些基线没有从你那里变更。一旦创建，UCM基线是不可变的，并且能用于定义更高级的配置。一个完整的系统，例如，能够有一组构件基线进行组合。
活动
可能关于UCM最有特色的事情就是基于活动的变更管理模型。这意味着什么？它意味这对文件的变更是来自变更的理由。比如，假设你正修改一个缺陷和执行一个新功能。无论什么时候你变更一个文件，你确认你正执行的变更的原因是通过在检出时声明一个活动。一个活动可以是一个缺陷，增强请求，或者是简单的一行变更描述，这取决于你的缺陷和变更跟踪过程需要多严格。UCM支持所有类型的活动－－以及任何其它你选择自己定义的活动。
基于活动的变更管理最主要的优势在于如果不关联到一个原因就不能检出文件。第二个优势是变更被集成（或提升）为一个单一、一致的整体。大多数时候，当你进行一个变更时，需要修改多个文件。例如，如果你正在修改一个缺陷，你可能需要修改C文件和一个头文