本文并没有涉及与 Rational ClearCase 管理有关的问题，也不涉及 Rational XDE 的其他版本。如果您对这些问题感兴趣，请参看本文最后的参考资料部分有关附加信息的出处。
随着时间的推移，可视化设计与软件配置管理（SCM）已经逐渐成为现代软件项目成功的关键因素。IBM Rational 是 IBM Rational XDE 和 IBM Rational ClearCase 的供应商，它们分别是在可视化设计与软件配置管理方面的市场领先的工具。IBM Rational 提供了这些产品间的无缝集成，因此简化了软件开发过程。
本文适用于使用 Rational XDE/Java Platform Edition 和 Rational ClearCase 的软件开发人员。本文详细概述了 Rational XDE 与 Rational ClearCase 之间的集成。
本文旨在使开发人员熟悉与配置管理相关的 XDE 和 ClearCase 概念，并且指出了协同使用 Rational XDE 和 ClearCase 的方法。本文还从软件开发人员的视角概述了最普通的配置管理的相关任务。需要注意的问题在文档中以黄色突出显示。
本文并没有涉及与 Rational ClearCase 管理有关的问题，也不涉及 Rational XDE 的其他版本。如果您对这些问题感兴趣，请参看本文最后的参考资料部分有关附加信息的出处。
  |
|
由于软件产品与功能随时都可能发生变更，因此本文的讨论只适用于下面的 IBM Rational 产品的特定软件版本。
- Rational XDE 2002 Release 2.1 Service Release
- Rational ClearCase 2002.05.00 with patch level 15 或更高版本
- Rational ClearCase LT 2002.05.00 with patch level 2 或更高版本
而且，为限定本文讨论的范围，我们不涉及下列与 Rational ClearCase 相关的问题：
- MultiSite
- Triggers
|
|
项目团队中的任何成员都有可能遇到软件配置管理工作，并且以某种形式完成这项工作。工作的难易程度大相径庭，简单的只需确保修改后的软件签入一个用于安全保管的版本控制系统，复杂的可能需要使用大量脚本来设置开发所需的环境。
更正式的说法是，软件配置管理（SCM）一般用来指：
- SCM 工具
- 技术
包括管理软件的变更。SCM 工具使软件配置管理涉及的技术实现了自动化。
从开发人员的视角来说，执行SCM 需要最少的附加工作，但是它提供了明显的获益，例如：
- 安全性：通过知识库，SCM 确保您的工件具有随需应变的安全性和可用性。
- 版本化：您可以跟踪软件的变更，随着它的发展在需要时返回以前的版本。
- 组织化：您可以按要求将已定义版本的工件组织为套件、项目和发布版本。
现代 SCM 工具（例如 Rational ClearCase）提供了大量的附加优点。其中的一些在下一部分突出显示。
|
|
Rational ClearCase 是市场领先的 SCM 工具。它为 SCM 自动化提供了一种灵活的、经过验证的方法，可用于各种类型的软件项目。
与其他的 SCM 工具一样，Rational ClearCase 提供了所有关键的 SCM 功能，例如保护并版本化软件工件的能力。同时，与其他的 SCM 工具不同的是，Rational ClearCase 还提供了几种高级功能：
- 并行变更：当两位或多位开发人员开发同一软件时，可能对软件工件进行并行变更。Rational ClearCase 提供了图形化合并与冲突解决功能，以统一变更。
- 环境与工作空间管理：ClearCase 允许您重新创建完整的项目开发环境，包括随需应变的完整开发工作空间。
- 并行开发：ClearCase 提供了广泛的功能，允许您同时创建与开发多个项目版本。
- 分布式开发：ClearCase 使团队在处于不同地点的情况下通过复制的知识库进行软件开发。
- 统一变更管理（UCM）：使用 Rational ClearCase，您可以按照任务、缺陷和增强请求来组织变更，从而在一个更高的抽象层次上工作。这种基于活动的开发方法流线化了您的整个变更/配置管理工作流。
|
|
Rational Clearcase 的功能从广义上来讲可以分为两种基本类型：
- 一般目的的 SCM 功能，通常称为 Base ClearCase。
- 基于活动的 SCM 功能，称为 Unified Change Management（统一变更管理）或者简称 UCM。
Base ClearCase Base ClearCase 围绕着在永久数据知识库中定义软件工件版本的概念展开，该知识库称为 Versioned Object Base(版本对象基础)或者简称 VOB。VOB 存储的元素可以是文件和目录。您也可以将 VOB 进行分解与组合。
ClearCase VOB 与典型的 CM 知识库不同，因为它使用文件系统的概念表示存储的元素。也就是说，ClearCase VOB 以存储于文件系统中文件的形式显示它们的内容。不仅如此，您也可以如同操作文件系统中的其他内容一样对 ClearCase VOB进行操作。
软件开发经常需要特定的工作环境。例如，如果您是 Java 开发人员，您可能需要位于特定目录结构中的某些源文件。Rational ClearCase 使用工作空间（也称为视图），因此可以方便地操作这些源文件。其中的主要思想就是通过方便地设置与创建一种沙箱，使开发人员能够拥有一个正确配置且稳定的软件开发环境。您可以以配置规格说明书（config spec）的形式在规则的帮助下定义视图，该规格说明书选择了您需要工作的元素的版本。
在 Base ClearCase 中，您的工作内容包括选定某一视图、签出所需元素、按需对其进行修改，以及按要求再将其签入。换句话说，在特定任务中，您必须了解并且管理需要被签入/签出的元素的细节。
ClearCase 中有两种视图。
快照（snapshot）视图提供 VOB 中版本化元素的静态视图。也就是说，当您创建工作空间时，一般都需要创建工作元素的本地副本，这些元素在您创建视图时就已经存在。您可以继续进行修改，稍后通过更新操作使之与 VOB 中的内容同步。
快照视图可以使您以离线方式工作。因为您已经具备工件的本地副本，因此您可以独立工作。而且，操作本地工件的速度要明显快于通过网络执行操作。
与快照视图一样，动态视图同样允许您创建工作空间，它们的主要区别就是动态视图不存在元素的本地副本。相反，所用元素直接通过虚拟文件系统在 VOB 中访问。
静态视图中的内容是上次更新时复制过来的，这些内容可能是过期的，动态视图的一个优点就在于使您不仅仅限于访问这些静态内容。因为您不必要将元素复制到本地，因此可以快速地创建动态视图。动态视图还允许您重用已创建的工件，这些工件是其他人通过一个称为"wink in"的过程创建的。
Rational ClearCase 还支持"分支（branch）"的概念。分支允许您执行并行开发，同时可以维护一个元素的多种版本。每个元素都有一个主分支（其默认分支）。您可以按照需要从主分支中创建附加分支。例如，如果您需要为某位顾客提供定制的产品，您可以创建一个独立的 ClearCase 分支进行开发。
|
|
统一变更管理（UCM）通过将 SCM 封装在即装即用的最佳实践过程中，在 Base ClearCase 概念的基础上创建。该最佳实践过程主要包括以集成的方式使用 Rational ClearCase 和 Rational ClearQuest，虽然也可以在仅有 ClearCase 的 UCM 环境中工作。
UCM 的主要思想是简化 SCM 的总体任务，关注于组件与活动，从而使用户了解大量的变更管理控制功能。
ClearCase 组件将需要开发的、集成的和发布的文件与目录分组。与软件中的组件思想相似，一个 ClearCase 组件主要实施系统中的可重用部分。一个组件的新版本（当您修改构成组件的元素时被创建）称为基线（baseline）。
团队中使用 ClearCase UCM 的开发人员必须首先加入 ClearCase 项目。一个 ClearCase 项目由项目经理创建，同时创建了软件开发所需的环境，例如需包括的组件、工作空间配置、集成变更的共享区域等等。
当开发人员加入项目时，一个逻辑工作区（基于项目中的特定细节）被自动创建，开发人员在其中执行开发工作。该逻辑工作区包括一个开发视图和一个开发流。开发流包含为视图自动生成配置规格说明所需的信息。
每个 UCM 项目还具有一个作为共享工作区一部分的集成流。
作为一名开发人员，您根据分配的活动对组件进行变更。一项活动本质上标识了在特定文件版本的环境中需要处理的一项任务、缺陷或者功能。这允许您关注需要完成的任务，而不需花时间决定哪些文件需要签入或者签出，也不用担心哪些文件与特定版本匹配等问题。
当您完成工作时，将活动提交经项目集成流。每个项目的集成流都是独立的，对于一个集成流提交的变更对于另一个项目来说是不具有可见性，直到这些变更合并到下一个项目基线中。
您需要定期地调整开发流基线以更新您的视图，并且访问所有近期提交且并入基线中的变更。从总体上来说，在发布操作前重新调整开发基线是非常好的习惯，这样可以确保在最新的基线基础上提交变更。
|
|
Rational XDE 提供了与 Rational ClearCase 广泛集成。尽管这两个产品间已经设置了集成，您可以即装即用，但是了解本节所讲的 Rational XDE 概念还是很有帮助的，这样可以定制集成以及与其相关的行为以满足您特定的 SCM 需要。
在 Rational XDE 中，您可以跨模型和项目创建引用，这种引用被称为跨模型引用（cross-model reference），并且需要 XDE 来维护资源所在位置的信息。
跨模型引用并不是动态地调整，来移动与复制工作空间，也不是视图感知的。换句话说，跨模型信息使用绝对路径，如果您不得不复制或者移动资源文件的话，那么就需要仔细地管理。例如，另一名用户可能在不同磁盘上或者不同视图中工作，因此当跨模型元素发生冲突时，就无法分解绝对路径。
下面列举一些与跨模型引用相关的概念。
第一个就是位置注册。Rational XDE使用位置注册来维护特定位置的信息，其中包括跨模型资源的位置和其路径。
位置注册中的每一个条目被称为一个注册位置。这样的注册位置映射了一个独特的位置识别符，称为某一路径的组件 ID（component ID）。它们有两种创建方式，一种是当您在模型之间创建引用（例如，通过将类从一个模型拖入另一个模型的图中）时自动创建，另一种是手动创建。
每台机器都有一个位置注册，包含机器上所有注册位置的条目。物理注册位置（例如包含一些模型元素的目录）本身是由 .ratl_comp_root 文件标记的，其中包含了特殊的地址识别符。
一个注册位置就是位置注册中的一个条目，并且组成了一个组件ID和组件所在位置的根目录。
现在让我们遍历创建新的跨模型引用时的情况。
假定对于目录 d 1 和 d 2，我们具有两个注册位置。由于每个注册位置都由 .ratl_comp_root 文件标记，所以每个目录包含一个文件，其中含有其标记的注册位置的组件 ID。而且，目录 d 1 和 d 2 各自包含模型 a 和 b，每个模型包含一个类。这些类分别命名为 C 1 和 C 2。该目录结构如图 1 所示。
图 1：注册位置
如果您将类 C 1 从模型 A 拖放至模型 B，XDE 将在所包含的目录 d 1 中寻找 .ratl_comp_root 文件。一旦找到该文件，它将使用其中的独特 ID，从用于组件 ID 和路径的 ratl_comp_root 文件创建一个跨模型引用到模型，从而填充 Model Path field。
从使用 Rational XDE SR 版本开始，VOB 的根级组件就可以自动创建。因此，所有的后续跨模型引用都与模型驻留的 VOB 的根相关。
当您使用 Rational XDE 时，您可以构建基于 UML 设计的可视模型。这种模型存储于一个 .mdx 文件中。对于简单的项目来说，使用简单的模型文件来管理模型一般就足够了。不过，在任何实际项目中，这种模型存储的单一方式就会引起问题。例如，一个大模型在启动时会引起模型加载过程缓慢而低效。对于基于团队的开发环境，一个单独的模型常常会引起冲突，因为所有项目成员都对单一模型文件进行变更。
为了解决使用单个文件存储整个模型带来的问题，Rational XDE 使您能够将一个模型分为多个比较小的文件。一般来讲，每个文件都是一个存储单元。在 Rational XDE 中，一个存储单元的粒度大小不同，大到一个完整的子系统或者包，小到可能是一个单独的类或图。
Rational XDE 还提供了一个自动将模型划分为存储单元的用户选择。这些设置和由此带来的争论在"设置 Rational XDE 以使其与 Rational ClearCase 协同使用"部分中将进行深入的讨论。
模型概要（profile）定义了 Rational XDE 模型可以支持的数据集合。模型概要可能需要从一个 XDE 版本变更到下一个版本以适应新产品功能的需求。
当您将 Rational XDE 从一个版本升级到另一个版本时，模型概要可能发生变更，也可能不变。如果模型概要没有变更，那么更新过程可以直接进行，不需要用户执行特定操作。
从另一方面讲，如果模型概要已经改变，所有使用以前模型概要的模型必须更新为新的模型概要才能使用。这是必须的，因为您不能比较或者合并基于不同模型概要的 XDE 模型。模型概要更新的不利影响表现为当您尝试合并刚刚更新过的模型时，可能会遇到大量的冲突。
在 ClearCase 的环境中，推荐使用一种特定的过程将模型升级至新的概要。如果需要更进一步的信息，请参看 Rational XDE Service Release 文档。
|
|
设置Rational XDE以协同使用 Rational ClearCase
Rational XDE 的用户偏好设置可以有多种，因此可能影响与 Rational ClearCase 之间的交互。如果使用 Rational XDE 2002 Rel 2.1 Service Release(SR)，那么大多数的设置已经事先设置好了。
推荐的设置、推荐设置的原理以及符合推荐设置范围内情况的原理将在下文中讨论。
与用户偏好设置相关的签出通过如下路径访问：Window>Preferences>Rational ClearCase>Advanced Options>Operations 标签。如图 2 所示。
图 2： 签出偏好设置对话框
该话框中具有三种用户设置方式。其目的与推荐设置讨论如下。
- Reserved：选中该项，则在执行签出操作时，可使 XDE 执行预留的签出操作。如果另一名用户还没有以预留的模式签出文件，那么对于预留的签出，该文件仍然是可用的。这就是默认的设置，因为它减少了合并。如果您了解合并的工作过程如何满足合并与相关事项，那么您可以不选该选项。
- Unreserved(已经 reserved)：如果文件已经以预留的方式签出，用户可以选择性地以非预留的方式签出。这就允许两个用户同时编辑文件的副本，当用户提交他们各自不同的变更时副本可以进行合并。默认状态下，该项不被选中，其最好方式也是不被选中。主要原因就是为了减少总体的合并，因为需要合并的机会随着非预留的签出而增加。如果您能够满足合并与相关的限制，您可以忽略该推荐设置。
- Preserve file modified time on checkout（保留签出时文件修改的时间）：当您在视图中比较文件上次修改的时间与签出时修改的时间，可能触发不必要的重载。为最大程度地减少这种重载，该设置在每个对话期间的开始时默认状态下是选定的。不过您可以在对话开始时取消其选定。强烈推荐选定这一设置。
与用户偏好设置相关的签入设置通过如下路径访问：Window>Preferences>Rational ClearCase>Advanced Options>Operations标签。如图2所示。
签入有两个相关选项：
- Checkin even if identical（即使完全相同也进行签入）：默认情况下，当附加新的文件时，要对其进行源代码控制并且保持签出状态。如果新文件与已存文件没有变化，那么后续的签入就会发生错误，因为存在完全相同的文件。一般来讲，注意细节并且理解错误报告原因的用户不需要设置此项。如果您不想收到该错误信息而且不在意是否创建了相同版本的文件的话，您可以选择这个选项。
- Preserve file modified time on checkin（签入时保留文件修改时间）：这与前面已讨论的保留签出时文件修改的时间的设置相似。设置该选项有时可能会触发不必要的重载。为减少这种重载，该设置在每个 XDE 对话期间的开始时默认状态下是选定的。不过您可以在对话开始时取消其选定。强烈推荐选定这一设置。
与撤销签出操作相关的只有一种设置。可以通过如下路径访问：Window>Preferences>Rational ClearCase>Advanced Options>Operations 标签。如图 2 所示。
- Save copy of file with a '.keep' extension（使用".keep"扩展名保存文件的副本）：这其实是一项普通意义上的设置。一般来讲，在撤销签出命令时保留一份本地文件的副本是一项良好实践，以备您需要执行恢复操作。不这么做的话会带来风险，如果您能承受，那么可以不选定它。默认情况下该项是选定的。
与活动偏好设置相关的只有一个设置。需要注意的是，这仅仅适用于使用 ClearCase UCM 的项目。可以通过如下路径访问：Window>Preferences>Rational ClearCase>Advanced Options>Operations 标签。如图 2 所示。
- Always prompt for an activity when working in a view of a ClearCase project（在 ClearCase 项目视图中工作时总是提示活动）：您应该选定该选项以确保您有规律地接到提示设置正确的活动。一般来讲，这被认为是一项良好实践。但是如果您在延长的时间段内使用单个活动，您可以不选择该选项。
模型－代码同步偏好设置 Rational XDE 的模型－代码同步的偏好设置通过如下路径访问：Window>Preferences>Rational XDE>Code-Model Synchronization。首先应设置 AutoSync。如图 3 所示。
图 3：模型－代码同步偏好设置
从开发人员的视角来看，在模型与代码变更之间的自动同步是很吸引人的，因为这可以减少手工修改引起的错误。（例如：忽视将代码中的变更进行同步，只能通过覆盖下一个模型中的代码实现代码同步）。
推荐您在模型整合期间关掉自动同步功能。尤其在动态添加新包和其他模型元素时，先关掉自动同步，等到模型已经稳定时再重新将其启动。这可以避免当您将模型元素加入源代码控制时，发现模型需要重新命名。从 CM 的视角来看，这种整合是有问题的，因为在 CM 控制下的工件需要更多的操作和步骤才能进行重新命名。
与 XDE 偏好设置相关的 Rational XDE 的存储单元设置可以通过如下路径访问：Window>Preferences >Rational XDE>File Storage。该设置决定了模型存储的方式。其概念已经在前面的内容"存储单元"中已经讨论过。如图 4 所示。
图 4：文件存储偏好设置
这里的用户偏好设置为 Default for New Models－Modal Storage Settings 选项。该设置的下拉列表框中包括如下选项：
- Manual：选中该选项，则模型必须通过手工进行分割。
- Automatic-Typical：如果选中该选项，包和子系统会作为独立的存储单元而自动创建。如果您想要将包或子系统之外的其他内容存入存储单元，您必须手动进行。
- Single File：不会创建子单元。所有内容都放入一个单独模型文件。
由开发团队来决定这三个选项哪一个最适合用于项目。作为一般的推荐设置，您应该经过深思熟虑后再决定是否创建新的存储单元。例如，创建存储单元以便于分辨模型单元文件的归属以及减少合并。
一般来说，由于在分析与设计的早期阶段，框架可能会被频繁地、大规模地修改，因此会经常创建和/或移动建模元素。这表明，应该限制在该阶段放入存储单元中模型元素的数量和粒度。一般可以创建一到二级的包的控制级别，这将提供足够的灵活性直到框架稳定。一旦构架稳定下来，其中的元素可以在进行详细实施时分为独立的、更细粒度的存储单元。
Rational XDE 源代码控制偏好设置可以通过如下路径访问：Window>Preferences >Rational XDE>Source Control。如图 5 所示。
图 5：源代码控制偏好设置
可以选择两种偏好设置：
- Automatically connect to source control provider at startup（启动时自动连到源代码控制提供器）：如果您不选择此项，然后对源代码进行添加的操作，那么由于您没有连接到 ClearCase，该变更不会加入到源代码控制中。推荐一直选中该选项。
- [action] when checked in files are edited（发现签入文件被编辑时执行[action]）：该选项允许您指定用户试图编辑签入的文件时将要执行的动作。该动作可设置为：prompt、 automatically checkout 和 Do nothing。推荐您使用"prompt"或"automatically checkout"选项。"Do nothing"选项最好不要选，因为使用该选项将允许在不经过实际签出时编辑文件。正如讨论的那样，这种在内存中的编辑可能会导致在后续视图更新或签出操作中造成数据丢失。
|
|
协同使用Rational XDE与Base ClearCase
在 Base ClearCase 环境中设置与使用 Rational XDE 是很简单的。本节概述了您作为开发者使用 Rational XDE 与基本的 ClearCase 进行配置管理时需要执行的不同活动的高级过程。
在真正开发活动进行之前需要进行一些步骤的设置：
- 定义 VOB：任何项目需要的 VOB 都需要在此时定义。
- 创建管理视图：使用管理视图，您可以设置开发者要使用的项目。
- 定义项目与模型：启动 XDE 并且选择管理视图。任何需要的项目与模型作为管理活动的一部分应该在此时定义。
- 准备并行开发：将模型分割为子单元，这样有利于并行开发。
- 导出项目设置文件：一旦模型已建立，应该导出项目设置文件，从而可以在开发视图中重新创建项目。
设置 VOB、XDE 模型与项目文件的具体步骤不在此讨论。请参见"Rational ClearCase用户使用手册与 Rational XDE Service Release 文档"以获得更详细的信息。
为协同使用 Rational XDE 与 base ClearCase，您必须首先：
- 创建一个快照视图：您可以通过 ClearCase 视图创建向导（Start>Program>Rational ClearCase>Create View）进行。遵循 Rational XDE SR 版本文档中的指导，为视图选择正确的选项和适当的VOB。
- XDE 偏好设置：默认情况下，XDE 将设置恰当的偏好设置，这已在"设置 Rational XDE 以使其与 Rational ClearCase 协同使用"有所阐述。如果您想要定制设置，应在此时进行。
- 导入项目设置文件：启动 XDE，在对话框中选择列表中的快照视图，如图 6 所示。您需要在视图中重新创建项目与模型。这通过 ClearCase>Add Project Set to Workspace 的菜单选项实现。您需要使用管理员创建的项目设置文件以达到此目的。
图 6：视图选择对话框
如果您已经设置了开发环境，正常情况下您就可以添加新模型元素。
- 关闭自动同步偏好设置：推荐您在扩展模型整合期间关掉自动同步功能。这可以避免执行附加的步骤来重新命名已处于配置管理下的工件。
- 定义新的模型元素：当您定义新的模型元素时，XDE 会提示您或者从源代码控制中自动签出模型元素的父元素。这取决于用户的偏好设置，如"设置 Rational XDE 以使其与 Rational ClearCase 协同使用"部分中所述。
- 生成代码：如果您的自动同步没有开启，您可以在任何时候生成相关模型的代码。当您进行该操作时，将创建模型元素的源文件。例如，创建名为 myclass 的类，即会创建 myclass.java 文件，系统会提示您将文件加到源代码控制中或者它也会自动将其加入（取决于用户的偏好设置）。然后您可以按需要将操作和属性加入到新创建的模型元素中。
- 启动自动同步偏好设置：如果您启动自动同步，那么一旦您重新命名新创建的模型元素，XDE 将为其创建代码。系统会提示您将文件加到源码控制中，或者它也会自动将其加入（取决于用户的偏好设置）。然后您可以按需要将操作和属性加入到新创建的模型元素中。
使用已经进行源代码管理的元素是相当简单的。您只需签出模型元素即可按需求修改它们。
- 签出模型元素：当您开始使用模型元素时，XDE 会提示您或者自动从源码控制中签出模型元素。这取决于您在"设置 Rational XDE 以使其与 Rational ClearCase 协同使用"部分中的用户偏好设置。您可以按照需要继续修改模型元素的细节（例如操作和属性）。
一旦您完成了您需要进行的添加/修改操作，模型元素将进入 ClearCase，同时创建了新版本。
- 保存工作：您必须保存所有的工作以确保您所作的更改将被交付。
- 验证模型：通过 Modeling>Validate 来完成。
- 签入修改过的工件：所有修改过的模型元素应该同时签入。这一点非常重要，因为只签入相关工件中的部分而忽视其他的将会引发一致性问题。Rational XDE SR 版本使这项工作的某些方面实现了自动化。
|
|
本节概述了您作为开发者使用 XDE 与 UCM 进行各种活动时所需的高级过程。
在实际开发活动前还需要进行一些步骤的设置：
- 定义项目 VOB：每个 UCM 项目必须具有一个项目 VOB。必须在您创建 UCM 项目前进行定义。
- 定义 UCM 项目：为使用 UCM 功能，您必须创建一个 UCM 项目。
- 计划 UCM 组件：在 UCM 中，组件是您的文件与目录的组织单元，尤其代表了您系统的可重用部分。
- 定义 VOB：UCM 组件位于 PVOB 中，而组成组件的文件与目录存于 VOB 中。应该在此阶段创建它们。
- 创建 UCM 工作区：用户工作区包括工作流与视图。您应该设置作为所需共享工作区和开发过程一部分的集成工作流。
- 设置特定项目的细节：一旦基本 UCM 项目设置完成，您就需要设置细节，例如哪些组件在项目中是可以修改的，基线形式项目的开始点（例如作为项目一部分的每个元素的版本），向您的项目推荐的基线以及按需要设置附加的策略。
- 定义项目与模型：启动 XDE 并且选择管理视图。任何需要的项目与模型应该此时定义，作为管理活动的一部分。
- 为并行开发做准备：将模型分为子单元将有助于并行开发。
- 导出项目设置文件：一旦模型经过设置，应该导出项目设置文件，以便在开发者视图重新创建项目。
- 交付给集成流：为使其他成员知道您的工作，您需要交付给集成流。作为该交付的一部分，您应该在集成流中测试该工作，然后完成交付过程。此时应创建并推荐新的基线。
当开发者开始工作于 UCM 项目时，您需要按照步骤确保您的环境正确设置，再进行开发活动。
- 加入 UCM 项目：这可以通过使用 ClearCase Project Explorer 轻松实现，选择正确的项目然后使用 Join Project 选项。当加入项目时，将自动创建视图。
- 将项目设置文档添加到工作空间中：启动 Rational XDE，在最后一步选择创建的视图。将项目设置文件添加到工作空间中，就可以访问所需的正确项目。
Rational XDE 源代码控制偏好设置可以通过如下路径访问：Window>Preferences >Rational XDE>Source Control。如图 5 所示。
图 5：源代码控制偏好设置
可以选择两种偏好设置：
- Automatically connect to source control provider at startup（启动时自动连到源代码控制提供器）：如果您不选择此项，然后对源代码进行添加的操作，那么由于您没有连接到 ClearCase，该变更不会加入到源代码控制中。推荐一直选中该选项。
- [action] when checked in files are edited（发现签入文件被编辑时执行[action]）：该选项允许您指定用户试图编辑签入的文件时将要执行的动作。该动作可设置为：prompt、 automatically checkout 和 Do nothing。推荐您使用"prompt"或"automatically checkout"选项。"Do nothing"选项最好不要选，因为使用该选项将允许在不经过实际签出时编辑文件。正如讨论的那样，这种在内存中的编辑可能会导致在后续视图更新或签出操作中造成数据丢失。
|
|
协同使用Rational XDE与Base ClearCase
在 Base ClearCase 环境中设置与使用 Rational XDE 是很简单的。本节概述了您作为开发者使用 Rational XDE 与基本的 ClearCase 进行配置管理时需要执行的不同活动的高级过程。
在真正开发活动进行之前需要进行一些步骤的设置：
- 定义 VOB：任何项目需要的 VOB 都需要在此时定义。
- 创建管理视图：使用管理视图，您可以设置开发者要使用的项目。
- 定义项目与模型：启动 XDE 并且选择管理视图。任何需要的项目与模型作为管理活动的一部分应该在此时定义。
- 准备并行开发：将模型分割为子单元，这样有利于并行开发。
- 导出项目设置文件：一旦模型已建立，应该导出项目设置文件，从而可以在开发视图中重新创建项目。
设置 VOB、XDE 模型与项目文件的具体步骤不在此讨论。请参见"Rational ClearCase用户使用手册与 Rational XDE Service Release 文档"以获得更详细的信息。
为协同使用 Rational XDE 与 base ClearCase，您必须首先：
- 创建一个快照视图：您可以通过 ClearCase 视图创建向导（Start>Program>Rational ClearCase>Create View）进行。遵循 Rational XDE SR 版本文档中的指导，为视图选择正确的选项和适当的VOB。
- XDE 偏好设置：默认情况下，XDE 将设置恰当的偏好设置，这已在"设置 Rational XDE 以使其与 Rational ClearCase 协同使用"有所阐述。如果您想要定制设置，应在此时进行。
- 导入项目设置文件：启动 XDE，在对话框中选择列表中的快照视图，如图 6 所示。您需要在视图中重新创建项目与模型。这通过 ClearCase>Add Project Set to Workspace 的菜单选项实现。您需要使用管理员创建的项目设置文件以达到此目的。
图 6：视图选择对话框
如果您已经设置了开发环境，正常情况下您就可以添加新模型元素。
- 关闭自动同步偏好设置：推荐您在扩展模型整合期间关掉自动同步功能。这可以避免执行附加的步骤来重新命名已处于配置管理下的工件。
- 定义新的模型元素：当您定义新的模型元素时，XDE 会提示您或者从源代码控制中自动签出模型元素的父元素。这取决于用户的偏好设置，如"设置 Rational XDE 以使其与 Rational ClearCase 协同使用"部分中所述。
- 生成代码：如果您的自动同步没有开启，您可以在任何时候生成相关模型的代码。当您进行该操作时，将创建模型元素的源文件。例如，创建名为 myclass 的类，即会创建 myclass.java 文件，系统会提示您将文件加到源代码控制中或者它也会自动将其加入（取决于用户的偏好设置）。然后您可以按需要将操作和属性加入到新创建的模型元素中。
- 启动自动同步偏好设置：如果您启动自动同步，那么一旦您重新命名新创建的模型元素，XDE 将为其创建代码。系统会提示您将文件加到源码控制中，或者它也会自动将其加入（取决于用户的偏好设置）。然后您可以按需要将操作和属性加入到新创建的模型元素中。
使用已经进行源代码管理的元素是相当简单的。您只需签出模型元素即可按需求修改它们。
- 签出模型元素：当您开始使用模型元素时，XDE 会提示您或者自动从源码控制中签出模型元素。这取决于您在"设置 Rational XDE 以使其与 Rational ClearCase 协同使用"部分中的用户偏好设置。您可以按照需要继续修改模型元素的细节（例如操作和属性）。
一旦您完成了您需要进行的添加/修改操作，模型元素将进入 ClearCase，同时创建了新版本。
- 保存工作：您必须保存所有的工作以确保您所作的更改将被交付。
- 验证模型：通过 Modeling>Validate 来完成。
- 签入修改过的工件：所有修改过的模型元素应该同时签入。这一点非常重要，因为只签入相关工件中的部分而忽视其他的将会引发一致性问题。Rational XDE SR 版本使这项工作的某些方面实现了自动化。
|
|
本节概述了您作为开发者使用 XDE 与 UCM 进行各种活动时所需的高级过程。
在实际开发活动前还需要进行一些步骤的设置：
- 定义项目 VOB：每个 UCM 项目必须具有一个项目 VOB。必须在您创建 UCM 项目前进行定义。
- 定义 UCM 项目：为使用 UCM 功能，您必须创建一个 UCM 项目。
- 计划 UCM 组件：在 UCM 中，组件是您的文件与目录的组织单元，尤其代表了您系统的可重用部分。
- 定义 VOB：UCM 组件位于 PVOB 中，而组成组件的文件与目录存于 VOB 中。应该在此阶段创建它们。
- 创建 UCM 工作区：用户工作区包括工作流与视图。您应该设置作为所需共享工作区和开发过程一部分的集成工作流。
- 设置特定项目的细节：一旦基本 UCM 项目设置完成，您就需要设置细节，例如哪些组件在项目中是可以修改的，基线形式项目的开始点（例如作为项目一部分的每个元素的版本），向您的项目推荐的基线以及按需要设置附加的策略。
- 定义项目与模型：启动 XDE 并且选择管理视图。任何需要的项目与模型应该此时定义，作为管理活动的一部分。
- 为并行开发做准备：将模型分为子单元将有助于并行开发。
- 导出项目设置文件：一旦模型经过设置，应该导出项目设置文件，以便在开发者视图重新创建项目。
- 交付给集成流：为使其他成员知道您的工作，您需要交付给集成流。作为该交付的一部分，您应该在集成流中测试该工作，然后完成交付过程。此时应创建并推荐新的基线。
当开发者开始工作于 UCM 项目时，您需要按照步骤确保您的环境正确设置，再进行开发活动。
- 加入 UCM 项目：这可以通过使用 ClearCase Project Explorer 轻松实现，选择正确的项目然后使用 Join Project 选项。当加入项目时，将自动创建视图。
- 将项目设置文档添加到工作空间中：启动 Rational XDE，在最后一步选择创建的视图。将项目设置文件添加到工作空间中，就可以访问所需的正确项目。
一旦您已经设置开发环境，就可以添加新模型元素。
- 关闭自动同步：在模型整合期间，推荐您关掉自动同步功能。这将避免重新命名源码控制中的工件所需的附加手工步骤。
- 定义新模型元素：当您定义新模型元素时，XDE 将提示您或者从源码控制中自动签出父模型元素。这取决于您的用户偏好设置，如同"设置 Rational XDE 以使其与 Rational ClearCase 协同使用"部分所讨论的。此时您可以按需要重新命名该模型元素。您还会得到活动的提示。
- 生成代码：一旦该条目被重新命名，您可以保存工作并生成相关模型元素的代码。当您进行该项操作时，模型元素的源文件将被创建。例如,创建名为 myclass 的类，即会创建 myclass.java 文件，系统会提示您将文件加到源码控制中或者它也会自动将其加入（取决于用户的偏好设置）。
- 启动自动同步偏好设置：如果您启动自动同步设置，那么一旦您重新命名新创建的模型元素，XDE 将为其生成代码。系统会提示您将文件加到源码控制中，或者它也会自动将其加入（取决于用户的偏好设置）。然后您可以按需要将操作和属性加入到新创建的模型元素中。
签出源码控制中的元素非常简单。您只需签出模型元素，然后按需要修改它们即可。
- 签出模型元素：当您开始使用模型元素时，XDE 会提示您从代码控制中签出该模型元素或自动签出。这取决于您在"设置 Rational XDE 以使其与 Rational ClearCase 协同使用"部分中的用户偏好设置。您可以按照需要继续修改模型元素的细节（例如操作和属性）。
在 UCM 中，您需要将您的工作交付给集成流，从而使其他成员知道您的工作。这可以通过 Deliver to stream 选项实现。
为获得他人近期所作的变更，开发者需要调整基线。
|
|
使用优秀思想设计且得出最佳效果的软件配置管理包括若干方面。本节提供并且概述一些这方面的内容。
合并是一项耗时的任务，而且对于 CM 系统来说，它并不总是能够检测到互相冲突的变更。使用特定的方式获得模型所有权可以约束所需的合并。
一般来说，模型所有权策略分成以下几个部分：
- 模型所有权：避免合并的最简单方式。因为如果只有一个人拥有整个模型，也就没有发生冲突的可能。不过，在团队开发的环境中，这经常是不实用的。
- 包所有权：在模型的最高级修改多个包会导致对根模型的争用状况。这是因为修改包会"干扰"根模型，而且根模型必须经过签出并且与包共同更新。该方式通过将包在模型的最高级设置为单个单元，并且为每个包分配单独所有权，避免了对根模型的争用状况。由于包内子单元的变更一般不会影响到其他单元，所以该方法能够有效地为每个单个创建沙箱工作环境。
- 单元所有权：由于在 XDE 中存储单元的粒度比包的粒度细，所以模型可以被分为多个存储单元而且每个开发者都被分配到特定单元的所有权。如果很多人需要访问一个单元，那么存储单元可以被分为更小的子单元以减少争用的情形。
处理模型所有权的一种方法就是考虑特定活动中的成员的数量以及水平。例如，参与分析活动的人员可能占少数，而人数较多的团队可能会负责构建应用程序。在这种情况下，所有权策略可能会随着开发进程的不同而有所改变，从分析阶段基于模型的所有权到设计过程中的包所有权，再到构建过程中的单元所有权。
Martin Fowler 给出了重构的定义："变更软件系统的过程，可以在不改变代码的外部行为的情况下，改进其内部结构"。从开发者的观点看，这是比较普通的活动，一般情况下都需要在不改变外部形式的情况下修改设计或工件。
下面是一些简单的重构示例：
- 通过移动域或方法为两个类解耦。
- 从现有类中抽取某个类以简化响应性。
- 移动或重命名某个类。
- 移动或重命名包或目录。
在可视开发环境和SCM中某些重构过程引起问题。例如，以下操作可能产生问题：
- 重命名、删除、移动文件，例如将 Class1.java 重命名为 Customer.java。
- 重命名、删除、移动目录，例如包的重命名操作。
- 移动存储单元，例如将单元与其父单元进行组合。
这是因为已在 ClearCase 中设置版本的元素不能只通过在 XDE 中重命名而完成重命名操作。推荐您尽可能少使用重构，即使在不得不使用时，应该遵循一些基本的推荐方式。关于 XDE 与 ClearCase 的重构，请参见 Rational XDE SR 文档中的更多指南。
当跨模型引用不明确时，该不明确的引用在模型中通过特殊的图标来识别。例如这种情况可能会在包含跨模型引用的模型共享时出现。
一些不明确引用的特殊图标如图 7 所示。在该图中，C 1 为外部引用，通过在左上角的箭头来识别。右上角圆圈中的"X"表明 C 1 是不明确的。继承关联中圆圈内的"\"表示被继承 C 1 是不明确的。如果 C 2 是外部不明确引用，该继承关联会以"X"表示，以表明关联中双方都是不明确的。
一旦您已经设置开发环境，就可以添加新模型元素。
- 关闭自动同步：在模型整合期间，推荐您关掉自动同步功能。这将避免重新命名源码控制中的工件所需的附加手工步骤。
- 定义新模型元素：当您定义新模型元素时，XDE 将提示您或者从源码控制中自动签出父模型元素。这取决于您的用户偏好设置，如同"设置 Rational XDE 以使其与 Rational ClearCase 协同使用"部分所讨论的。此时您可以按需要重新命名该模型元素。您还会得到活动的提示。
- 生成代码：一旦该条目被重新命名，您可以保存工作并生成相关模型元素的代码。当您进行该项操作时，模型元素的源文件将被创建。例如,创建名为 myclass 的类，即会创建 myclass.java 文件，系统会提示您将文件加到源码控制中或者它也会自动将其加入（取决于用户的偏好设置）。
- 启动自动同步偏好设置：如果您启动自动同步设置，那么一旦您重新命名新创建的模型元素，XDE 将为其生成代码。系统会提示您将文件加到源码控制中，或者它也会自动将其加入（取决于用户的偏好设置）。然后您可以按需要将操作和属性加入到新创建的模型元素中。
签出源码控制中的元素非常简单。您只需签出模型元素，然后按需要修改它们即可。
- 签出模型元素：当您开始使用模型元素时，XDE 会提示您从代码控制中签出该模型元素或自动签出。这取决于您在"设置 Rational XDE 以使其与 Rational ClearCase 协同使用"部分中的用户偏好设置。您可以按照需要继续修改模型元素的细节（例如操作和属性）。
在 UCM 中，您需要将您的工作交付给集成流，从而使其他成员知道您的工作。这可以通过 Deliver to stream 选项实现。
为获得他人近期所作的变更，开发者需要调整基线。
|
|
使用优秀思想设计且得出最佳效果的软件配置管理包括若干方面。本节提供并且概述一些这方面的内容。
合并是一项耗时的任务，而且对于 CM 系统来说，它并不总是能够检测到互相冲突的变更。使用特定的方式获得模型所有权可以约束所需的合并。
一般来说，模型所有权策略分成以下几个部分：
- 模型所有权：避免合并的最简单方式。因为如果只有一个人拥有整个模型，也就没有发生冲突的可能。不过，在团队开发的环境中，这经常是不实用的。
- 包所有权：在模型的最高级修改多个包会导致对根模型的争用状况。这是因为修改包会"干扰"根模型，而且根模型必须经过签出并且与包共同更新。该方式通过将包在模型的最高级设置为单个单元，并且为每个包分配单独所有权，避免了对根模型的争用状况。由于包内子单元的变更一般不会影响到其他单元，所以该方法能够有效地为每个单个创建沙箱工作环境。
- 单元所有权：由于在 XDE 中存储单元的粒度比包的粒度细，所以模型可以被分为多个存储单元而且每个开发者都被分配到特定单元的所有权。如果很多人需要访问一个单元，那么存储单元可以被分为更小的子单元以减少争用的情形。
处理模型所有权的一种方法就是考虑特定活动中的成员的数量以及水平。例如，参与分析活动的人员可能占少数，而人数较多的团队可能会负责构建应用程序。在这种情况下，所有权策略可能会随着开发进程的不同而有所改变，从分析阶段基于模型的所有权到设计过程中的包所有权，再到构建过程中的单元所有权。
Martin Fowler 给出了重构的定义："变更软件系统的过程，可以在不改变代码的外部行为的情况下，改进其内部结构"。从开发者的观点看，这是比较普通的活动，一般情况下都需要在不改变外部形式的情况下修改设计或工件。
下面是一些简单的重构示例：
- 通过移动域或方法为两个类解耦。
- 从现有类中抽取某个类以简化响应性。
- 移动或重命名某个类。
- 移动或重命名包或目录。
在可视开发环境和SCM中某些重构过程引起问题。例如，以下操作可能产生问题：
- 重命名、删除、移动文件，例如将 Class1.java 重命名为 Customer.java。
- 重命名、删除、移动目录，例如包的重命名操作。
- 移动存储单元，例如将单元与其父单元进行组合。
这是因为已在 ClearCase 中设置版本的元素不能只通过在 XDE 中重命名而完成重命名操作。推荐您尽可能少使用重构，即使在不得不使用时，应该遵循一些基本的推荐方式。关于 XDE 与 ClearCase 的重构，请参见 Rational XDE SR 文档中的更多指南。
当跨模型引用不明确时，该不明确的引用在模型中通过特殊的图标来识别。例如这种情况可能会在包含跨模型引用的模型共享时出现。
一些不明确引用的特殊图标如图 7 所示。在该图中，C 1 为外部引用，通过在左上角的箭头来识别。右上角圆圈中的"X"表明 C 1 是不明确的。继承关联中圆圈内的"\"表示被继承 C 1 是不明确的。如果 C 2 是外部不明确引用，该继承关联会以"X"表示，以表明关联中双方都是不明确的。
图 7：不明确引用图标
Rational XDE 为处理不明确引用提供了内置功能。为处理不明确引用，您需要按照下述步骤：
- 选择模型
- 单击 Modeling>Check External Reference
- 在最终对话框中单击 Resolve
- 在最终对话框中，选中目标模型。这可以在机器上定位注册位置，并且更新位置注册
从现在开始，模型的进一步更新将会进行正确地分辨。
Rational XDE支持合并与冲突解决，从而真正实现团队开发。
需要正确配置 ClearCase Type Manager 才能进行合并。Rational XDE 相关工件的合并需要正确使用 XDE Type Manager。所有支持 Rational XDE 工件的 ClearCase VOB 必须经配置以使用 XDE Type Manager。
启动 Rational XDE Service Release，Type Manager 配置选项即进行自动设置并且依赖于 Rational XDE 的启动。当 XDE 启动时，它会检查并且报告 VOB 是否经过了正确的配置。您需要使用正确的操作以修复任何被报告的问题。需要注意的是，对于 UNIX 机器上的 VOB，Rational XDE 不会检测 VOB Type Manager 的配置问题。这必须通过手工进行。详细信息，请参见"Rational XDE Service Release 文档"。
当不同方对于同一工件做出变更并且变更已被提交时，Rational XDE 会启动 ClearCase 的合并会话，图形化地显示所提交的变更间的差异。如果差异是比较细微的，可以自动解决。对于更棘手的差异，用户可以按需要进行解决与合并。
比较/合并会话的快照截图如图 8 所示。
图 8：比较/合并会话
合并与冲突解决的更详细信息，请参见"Rational XDE Service Release 文档"。
|
|
Rational XDE 与 Rational ClearCase 提供了空前的集成功能，允许您在项目中协同使用这两个第一流的工具。您可以与 Rational XDE 协同使用基本的 ClearCase 或 UCM ClearCase。对于每种组合，都推荐进行特定的设置以确保最佳的工作环境。
文章来源于领测软件测试网 https://www.ltesting.net/
