【IT168 技术文章】

    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没有提供用户和维护者交流的方式，但是提供了：特定变更请求关联的历史变更；变更过程的状态报告；变更完成的审计；变更影响分析和确保合适的人在合适时间执行各自任务的支持机制。实际上，变更请求是控制变更过程的辅助。