本文将讨论在使用 IBM® Rational® RequisitePro 及 IBM® Rational® ClearCase® 实现 RequisitePro 需求文档的并行开发和版本化时可能会遇到的挑战，并为您介绍针对这些问题的解决方案。

简介

如果您是在多团队环境下进行工作（通常这是在跨地域分布式开发项目的情况，即 GDD 项目），并按照迭代开发方法进行开发（在这种情况下，当软件开发团队开始执行首个需求基线时，需求团队已经在为下一次迭代的下一个基线进行工作了），您就需要并行地开展工作。当您需要并发工作的时候，您可以使用 IBM® Rational® ClearCase®。

并行开展工作

例如，您的开发团队不会接受已经确定需求的改变。另外一种可能发生的情况，是在开发周期刚开始的阶段，您的测试团队就想测试开发中的原型。对比初始需求测试原型是行得通的。在大多数项目中，软件开发团队通常不能等到需求团队完成其工作，而测试团队也不能等到开发团队完成工作。这样，为了让团队能够并发地工作，有时就需要在相同的时间内，执行不同的需求基线的功能。

目前，IBM® Rational® RequisitePro®只是将 ClearCase 用作项目层次范围内的一个描述工具。这意味着完整的 RequisitePro 项目可以达到“as is”。对于单个的 RequisitePro 需求，以及平台以外支持的文件，并没有相关描述。

您可能想要显示 RequisitePro 文件的历史记录，以便能够检查，谁做出了改变，什么时候做的改变，以及实际上做出了什么改变。ClearCase 以其他的文件类型支持这种操作，本片文章将向您展示，ClearCase 是怎样以一种相似的方式，来处理 RequisitePro 需求的。

本篇文章将讨论，您在使用 RequisitePro 以及 ClearCase ，以进行并行开发以及描述 RequisitePro 文件，和可行的方案时，将会遇到的一些挑战。

基础

本段落将讨论 ClearCase 中并行开发的基本概念。

分类，合并以及比较的概念

ClearCase 通过提供 branching 功能，来支持并发工作。一个分支（如图 1 中的蓝色矩形所示）是版本（蓝色圆圈）的一个线性序列。通过 merging（以红色箭头标识），一个文件的不同版本可以被组合到一起。相关版本的不同之处，被再次访问并有选择的组合到一起，以产生文件的一个新版本。

为了检查在给定文件的两个版本中，发生了什么改变，您可以使用 ClearCase 中的compare功能。按照以下步骤，您可以轻松地进行比较 ：

1. 选择文件的两个版本。
2. 右击并选择 Compare to。
3. 比较工具会显示出两个版本的不同之处，如图 2 所示。

当您的团队在不同的部门中并发地工作时，通常有两个人同时处理同一个文件。在这种情况下，结果就会使文件同时产生一些改变。ClearCase 为将一个文件的不同版本，合并成一个包含了所有改变的兼容版本，提供了一种简便而安全的方法。它使用一种三种方式的合并规则系统，通常能够自动地合并不同的版本。但是如果有冲突的改变发生，那么您就需要手动的去解决它，如图 3 所示。

当考虑到差异时，不管是手动的还是自动的，都会绘出一个合并箭头，并由 ClearCase 考虑解决的差异。由于该合并箭头，合并工具并不考虑不同的版本，甚至在内容实际上不一样时也是这样。在整个目录（树状结构），而不是单个文件中运行合并管理器，会让您意识到，该目录下的所有文件，哪些是添加的，删除的，或者修改的。

变幻文件，元素种类以及种类管理器

比较与合并功能取决于文件格式。ClearCase 通过使用以下三个基本概念，来以一种十分灵活的方式，支持比较与合并功能：

• 变换文件
• 元素种类
• 种类管理器

当向资源管理器添加一个文件时，ClearCase 会向它分配一个元素种类。元素种类是由 magic 文件决定的。变幻文件包含了一些标准（通常是文件扩展），以及与之相联系的元素种类。元素种类具有一个分配的种类管理器 。当比较、合并、检查以及等等其他操作ClearCase 元素时，种类管理器会执行文件特定格式的操作。

默认的变幻文件位于ClearCase 安装路径的 ccase-home-dir\config\magic 中。关于变幻文件格式的明细问题，在 ClearCase 手册中会有所解释。列表1 引用自 default.magic 文件的一部分作为示例。

				
# Match by name without examining data
core file : -name "core" ;
# (seems printable, but has binary at the end of it)
lisp_object object_module file : -name "*.lbin" ;
program compressed_file : -name "*.[eE][xX][eE]" | -name "*.bin" ;
object_module compressed_file : -name "*.[oO][bB][jJ]" ;
shlib library compressed_file : -name "*.[dD][lL][lL]" ;
zip_archive archive file : -name "*.[zZ][iI][pP]" ;
gtar_archive archive file : -name "*.gtar" ;
tar_archive archive compressed_file : -name "*.tar" ;
audio compressed_file : -name "*.au" | -name "*.aif" | -name "*.aiff" ;
audio file : -name "*.aifc" ;

基本上，格式为：

object_module compressed_file : -name "*.[oO][bB][jJ]" ;

其中：

• object_module 是一个占位符的名字。
• compressed_file 是与之相关的使用到的种类管理器
• -name "*.[oO][bB][jJ]" 是一个文件选择器

您可以在 ClearCase VOB 中，使用 ClearCase 种类浏览器，来浏览可用的元素种类。每一个 VOB 都有一系列的默认的元素种类，如图 4 所示。

特殊文件格式具有相应的元素种类。检查元素种类的明细，可以发现它们中有一些来自于一个超类管理器。另外，如果合并需要考虑这个类型的元素，那么您可以指定它。如图5. 元素种类明细所示。

支持并行开发的一般分组方法

并行工作的一个非常直接的方法，是在分组工作直到基线确定以后。当情况是这样时，分组中所有文件都将被贴上基线的标签。一个新的分组（基于正处理的分组以及标签）会被创建。然后重复：处理新的分组直到下一个基线确定下来 。接着，又是分组中的文件被贴上标签，然后一个新的分组会被创建，如图 6 所示。

当您需要修改已完成的基线时，您可以对基线的分组做一些改变，然后将改变延伸至基线。Merging RequisitePro 文件可能会导致出现问题，所以您可以按照下述步骤来做：

1. 手动检查文件
2. 检查并解决差异
3. 标识文件
4. 手动创建一个合并箭头，以指示差异被解决了

这个过程支持以下各项：

1. 需求团队的工作从基线 b11 开始（主要分组，因为主要分组不能被重命名为合适的 rq_bl1 ）。
2. 当需求团队在处理基线 bl1 时，他们给它贴上了 RQ_BL1 的标签。
3. 在基线 b11 和标签（RQ_BL1）的基础上，下一个基线（b12）被创建（分组 rq_bl2）。
4. 需求团队继续处理基线 bl2 （分组 rq_bl2）。
5. 软件开发团队的工作从处理基线 b11（分组 rq_bl1 ）开始。
6. 如果软件开发团队需要辨别以及将需求具体化，他们将会对基线 b11（主要分组） 直接做出改变。
7. 软件开发团队对基线 b11（主要分组） 所做的任何改变，都会手动的“合并”（意思是在基线 b12 中找到文件，考虑拒绝或者接受的所有改变，在基线 b12 中找回文件，并画一个合并箭头）到基线 bl2 （分组 rq_bl2）。
8. 当需求团队处理基线 b12 时，他们将它贴上 RQ_BL2 的标签。
9. 在基线 b12（分组 rq_bl2）和标签 RQ_BL2 的基础上，创建了下一个基线 b13（分组 rq_bl3）。
10. 需求团队继续处理基线 b13（分组 rq_bl3）。
11. 软件开发团队继续在基线 b12 的基础上工作（分组rq_bl2）。
12. 软件测试团队在基线 b11（主要分组）的基础上开始工作。
13. 如上类推。

为什么需要合并 RequisitePro 文件

尽管 ClearCase 并不支持 Microsoft®Word 文档的合并，并不合并 RequisitePro 需求文件。下面是一些解释为什么的理由 ：

• 对于一个已存在的需求，只有需求文本会被改变。如果有一个需求名的话，它仍然会保持不变。需求的属性同样不会被合并所改变。需求会被再次分析，并引入到一个平的层级结构中去。
• 对于一个新的需求，文件的默认需求种类会被指定（不考虑初始的需求种类）。需求的属性会被设置成默认的属性值。
• 如果需求已经在两种版本的需求文件间被删除掉，并且这两种版本已经合并到一起的话，那么一些需求就会有消失的可能。

从 RequisitePro 项目中删除 RequisitePro 文件

如果从 RequisitePro 项目中删除 RequisitePro 文件，文件扩展名将被设置成 .doc。文件 RequisitePro 需要首先被检查，以允许 RequisitePro 去运行该操作。

在从 RequisitePro 项目中删除文件以后，您应该清除文件上的选项，并在清除工具命令行中执行一次 rmname 操作，以从项目名中去掉文件名（不要使用 rmelem ，因为这将删除掉文件的整个版本树状结构）。不要粗心地合并掉不同版本的 RequisitePro 项目文件夹，因为如果 RequisitePro 文件从其他基线中移除的话，这将会导致 RequisitePro 文件在其他基线中消失。

在ClearCase 中存储一个 RequisitePro 项目

Microsoft Word 文档有一个比较功能，但是 ClearCase 需要知道 RequisitePro 需求文件类型，以及它们特定的文件扩展名。通过创建一个新的 ClearCase 元素类，可以做到这点。另外，您需要扩展 default.magic 文件，以从 RequisitePro 文件名（扩展名）中，为新的 ClearCase 元素种类提供一个映射。因为已存在的 ms_word 种类管理器很好地满足了您的需求，所以您可以把它当作您的新元素种类的超类。

尽管 RequisitePro 文件的合并在技术上是可行的，但是它可能会导致数据库不稳定或者数据丢失，因为 RequisitePro 在很大程度上依靠格式化，以及文件中的书签。

能够比较不同版本的 RequisitePro 文件，对您得到需求怎样演化的概况，是十分有帮助的。

就目前的关系数据库来说，在ClearCase 中并没有比较和合并功能，而且也没有简单执行的方式。这是因为，对于一个 Relational Database，不但要考虑内容，还要考虑结构。如果合并不合适的执行了，那么将会发生数据库不稳定的情况。

在 developerWorks （http://www.ibm.com/developerworks/rational/library/5066.html）处可以得到一个工具，这个工具允许您去比较 RequisitePro 项目，需求种类，或者需求水平，如图 7 所示。

实现

这个段落将向您展示，怎样执行本文中讨论的规则。

创建元素种类

首先，创建一个 RequisitePro 项目中的 RequisitePro 文件类的元素种类。元素种类将会

• 基于种类管理器并且
• 避免这种元素种类文件的合并

按照下面的步骤，您可以很容易的在命令行上做到这点：

Cleartool mkeltype -supertype ms_word -mergetype never -nc reqpro_docs_cnnew1@\REQS

对于 RequisitePro 项目文件，创建另外一个元素种类，该元素种类将会

• 基于二进制的种类管理器（因为有一些项目文件是二进制的）
• 避免这种元素类型的文件的合并

再一次，简化种类并执行以下命令：

cleartool mkeltype -supertype binary_delta_file -mergetype never -nc reqpro_prj@\REQS

在添加元素以后，列表将类似于图 8 中显示的那样。

请检查两种新元素种类都被设置成避免合并。选项 Never consider elements of this type for merging 应该被选中，如图 9 所示。

编辑 default.magic 文件

为了让 ClearCase 使用新的元素种类，您需要扩展 default.magic 文件，如列表 2 所示。文件 default.magic 可以在 ccase-home-dir\config\magic 中找到。为了避免在每一个ClearCase 客户机上都保持 default.magic 文件，您可以使用一个可得到的环境变量（MAGIC_PATH）来指向一个中心位置。

				
# RequisitePro
# document types from RUP template
reqpro_doc : !-printable &-name "*.[uU][cC][sS]" ;
reqpro_doc : !-printable &-name "*.[vV][iI][sS]" ;
reqpro_doc : !-printable &-name "*.[bB][rR][sS]" ;
reqpro_doc : !-printable &-name "*.[gG][lL][sS]" ;
reqpro_doc : !-printable &-name "*.[rR][mM][pP]" ;
reqpro_doc : !-printable &-name "*.[rR][sS][kK]" ;
reqpro_doc : !-printable &-name "*.[sS][tT][rR]" ;
reqpro_doc : !-printable &-name "*.[sS][uU][pP]" ;
reqpro_doc : !-printable &-name "*[uU][cC][mM][gG]" ;

# RequisitePro 
# database files
reqpro_prj : -printable & -name "*.[lL][dD][pP]" ;
reqpro_prj : -name "*.[mM][dD][bB]" ;
reqpro_prj : -name "*.[rR][qQ][lL]" ;
reqpro_prj : -printable & -name "*.[rR][qQ][sS]" ;

在default.magic 文件的最顶部都应该有一道添加的线，因为如果找到一个匹配的文件选择器的话，过程会终止。最重要的一点是，要让一个更普通的文件选择器避免与 RequisitePro 文件匹配。

取消 Save documents in RequisitePro Format 选项

复选框 Save documents in RequisitePro Format 必须 不 被选中，如图 10 所示 。如果该选项被选中了，文件 RequisitePro 将不能在 RequisitePro 外部执行。而这就意味着，它们不能通过 ClearCase 种类管理器来管理。

工作视图

由于以下一系列原因，在 Microsoft®Windows®上使用一个集中的 snapshot 视图，是十分合适的。

• 所有的用户需要为一个特定的基线处理相同系列的文件。
• RequisitePro 在注册表中一定的存储位置存储了项目名。由于不同的存储位置，处理不同（动态）的视图将会混淆 RequisitePro （通过移除项目，并再次在新位置一起添加该项目，您可以解决这个问题，但这将是十分繁琐的）。
• 在Microsoft Word 中用动态视图来处理，需要很好的网络性能。
• RequisitePro 需要 一个Windows 共享文件夹，来存储 RequisitePro 项目。

Check in 或者 Check out 以及 Add to Source Control

您应该保持 RequisitePro 项目文件录出。如果它们被录入，那么 RequisitePro 将把项目当做“只读”模式。当 Word 在 RequisitePro 需求文件中打开一个录入时，这点也是适用的。为了检查属于 RequisitePro 的所有文件，该文件应该立即被录入及录出。

因为这是一个不太好的程序，所以有一个可以处理这个问题的工具。又因为记住哪一个文件已经属于 RequisitePro 项目，哪一个文件需要被添加以及哪一个不需要，这很困难，所以该工具能从 RequisitePro 项目中，直接处理需要考虑的文件。

不论何时执行 Checkin，Checkout 或者 CreateVersion 操作时，如果文件仍然是在私人视图下，那么它将会自动向 ClearCase 添加一个 RequisitePro 需求文件（图 11）。给整个项目贴上标签也是可能的（只有文件可以贴标签，目录不行）。

RequisitePro 项目的创建

因为关系数据库不能被分组，所以不论何时创建新基线时，您都需要创建一个新的 RequisitePro 项目。

RequisitePro Baseline Manager 支持新 RequisitePro 项目的创建。因为 RequisitePro Baseline Manager 没有 ClearCase 界面，所以您需要首先录出所有的项目文件。又因为 RequisitePro Baseline Manager 并不允许在相同的位置有其他的 RequisitePro 项目存在，所以您必须先从 RequisitePro 项目文件夹中删除所有的文件。

注意：它们必须通过 not ClearCase 命令来删除，但是既不是在 Windows®Explorer 也不是在命令行中删除的。

您需要用 RequisitePro Baseline Manager 创建的文件，来替换它们，因为不这样的话，ClearCase 只考虑新元素种类，而不考虑新版本的已存在元素。结果会产生一个 ClearCase 中的新版本树状结构。这意味着它们不能被比较。

每一个基线新 Requisite 项目的创建，将使您能够使用已存在的工具，来比较 RequisitePro 项目。

根据项目所属的基线，来给项目命名，这可以避免用户被弄混淆。理想条件下，这是根据第一条基线来完成的。

Example

您需要为一个新的起始代，创建一个新项目。项目的名字是 Starship。因为需求的第一条基线将要被定义，所以您需要向项目名添加一个“BL1”后缀。当您以名字“Starship_BL1”创建项目时，您需要选择一个 snapshot 视图，该视图被设置成在基线 b11 下工作作为终点。

当基线 b11（主要分组）的工作完成时，并且已经切换至基线 b12（分组rq_bl2 ）时，您需要完成以下步骤：

1. 为基线 b12 创建一个 snapshot 视图（处理并行的分组 rq_bl2，起始于主要分组的 RQ_BL1 标签）。
2. 录出所有基线 b12 分组上的文件。
3. 在 snapshot 视图的 RequisitePro 项目文件夹下，去除所有已录出的文件（否则，RequisitePro Baseline Manager 工具处理已经存在的项目会很费事）。
4. 使用 RequisitePro Baseline Manager 创建一条基线，并将其存储到一个临时的位置，如图 12 所示。

5. 从前面已经创建的基线中创建一条新项目。该新项目必须位于基线 b12 的 snapshot 视图下。

重点 ：您必须确保不同的项目名但是使用相同的位置（见于图 13 和图 14）。

6. 如果您成功的创建了项目，那么文件将被录入。
7. 您可以删除 RequisitePro Baseline Manager 创建的任何视图私人文件（大多数是 XML 文件）。
8. 您应该去除剩余的所有录出文件（通过取消录出操作，并从文件中删除文件名，使用命令行中的 rmname 清除工具），因为这些属于文件的条目，已经不再是 RequisitePro 项目的一部分。

怎样使用它

本段将向您演示怎样来使用这些工具。

比较 RequisitePro 文件

当您处理不同的分组时，一个团队会处理基线 b11（主要分组，如图 15 所示）的版本，同时另一个团队处理基线 b12（rq_bl2 分组，如图 16 所示）版本。

通过点击第一个版本，并选择 Compare，您可以很容易的在两个基线之间检查改变，如图 17 所示 。

添加以及删除文件

随着时间的进行，RequisitePro 文件将会从 RequisitePro 项目中添加或者删除。找出哪一个文件是被添加的，哪一个文件被删除的，最简单的方法是，查看 RequisitePro 项目文件夹中的版本树状结构，如图 18 所示。如果有不同的版本存在，那么在基线之间将会有结构性的改变，如图 19 所示。

比较两个文件夹，您将会发现明细上的差异之处（文件的其余部分）。

至于被删除的 RequisitePro 文件，您应该仔细的考虑一下，该文件是否也从其他基线中被删除掉。如果是这样的话，那么它也可以从 RequisitePro 项目文件夹中删除。以后，您应该使用清除工具上命令行的 rmname 命令，来从 RequisitePro 项目文件夹中删除文件名。

至于添加的文件，如果您想要这样添加文件以成为其他基线的成员，您还有一些事要做。要记住当您引入文件时，只可引入需求文本。需求种类将会成为 RequisitePro 文件种类的默认需求种类。需求属性将会被设置成，在需求种类中定义的默认值。任何与已存在需求的冲突，都可能导致数据的丢失。

RequisitePro 需求文件应该通过将需求文件，合并到相应的基线分组中，来把需求文件添加至其他的基线中。但是，RequisitePro 项目仍然不清楚附加的文件。添加的需求文件应该被 RequisitePro 引入。您可以通过从 RequisitePro 菜单中选择 File > Import 来做到这点。

文件引入功能最初被设计成引入 .doc 文件，然后用不同的扩展方式（取决于您选择的文件类型）来存储它们。不幸的是，引入的新文件已经处在 ClearCase 的控制之下，而且已经有了文件特定种类的扩展。

这将导致与文件引入工具的冲突，所以您需要做一点工作： 对所有（前面录出的）应该引入的文件，添加一个类似于下划线“_”的首字符。这样，就可以为文件类型中已经应用的扩展做一个提示符，您就可以轻松识别出稍后需要清除的文件。

在您选中 File > Import 以后，会显示出 Import Wizard 对话框，如图 20 所示。

要引入的文件，可以通过浏览到它所在的位置来轻松选中。

接下来，指定需要引入哪一种信息，如图 21 所示。选择 Document only，因为文件中已经包含了，识别需求的 RequisitePro 书签。

您需要指定文件种类（见图 22）以及文件名。请检查确保文件名不包括首字符“_”。保持文件名不变非常重要。否则，ClearCase 会把它当作一个新元素，而不是一个已存在元素的新版本。

引入过程会检测到已经包含格式化的 Word 文件，格式化可能由文件种类格式化重复进行。选择 Yes 以保持格式化，如图 23 所示。

引入过程还会检测到已存在的需求书签，如图 24 所示。您想要保持已经存在的需求书签，所以您可以点击 No。

引入过程将会报告被发现的需求，如图 25 所示。

当您点击 Commit 按钮时，引入过程会从已经存在的书签中，完成需求与数据库更新 。

申明

本文中出现的信息、指导和过程，代表了作者的最高知识水平，并在 RequisitePro V7.0.1，ClearCase V7.01 和 Word 2003 中通过了测试。在开始运行之前，您应该先将所有的数据源备份。给出的指导以及过程，应该在一个严密的项目中通过验证，以确保最终得到的系统满足您的期望 。

参考资料

• 您可以参阅本文在 developerWorks 全球网站上的 英文原文。
• 阅读 RequisitePro ClearCase Interface 用户指南，并下载支持脚本。
• 访问 developerWorks 上的 Rational 专区，了解有关 Rational 软件交付平台产品的技术资源和最佳实践。
• 订阅 IBM developerWorks 时事通讯，获得有关最佳的 developerWorks 教程、文章、下载、社区活动、网络广播和事件的每周更新。
• 订阅 developerWorks Rational 专区时事通讯。时刻关注 developerWorks Rational 内容。每隔一周，您将会收到 Rational 软件交付平台的技术资源和最佳实践的最新更新。
• 订阅 Rational Edge 中文版，获得了解高效软件开发背后概念的文章。
• 浏览 技术书店，获得有关这些和其它技术主题的书籍。

• 下载 IBM Rational 软件的试用版。
• 下载这些 IBM 产品评估版，并着手使用来自于 DB2®，Lotus®，Tivoli®，以及 WebSphere® 的应用程序开发工具和中间件产品。

• 加入 developerWorks 社区 的讨论区，博客，播客，wiki，以及更多。
• 需求管理和 RequisitePro 论坛： 询问有关需求管理和 RequisitePro 的问题。