| UML软件工程组织 | |||
| |
|||
|
|||
IBM Rational ClearCase 部署指南
作者：Khawar Ahmed 来源：IBM
本文并没有涉及与 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 ClearCase 相关的问题：
什么是软件配置管理？项目团队中的任何成员都有可能遇到软件配置管理工作，并且以某种形式完成这项工作。工作的难易程度大相径庭，简单的只需确保修改后的软件签入一个用于安全保管的版本控制系统，复杂的可能需要使用大量脚本来设置开发所需的环境。 更正式的说法是，软件配置管理（SCM）一般用来指：
包括管理软件的变更。SCM 工具使软件配置管理涉及的技术实现了自动化。 从开发人员的视角来说，执行SCM 需要最少的附加工作，但是它提供了明显的获益，例如：
现代 SCM 工具（例如 Rational ClearCase）提供了大量的附加优点。其中的一些在下一部分突出显示。 IBM Rational ClearCase 概览Rational ClearCase 是市场领先的 SCM 工具。它为 SCM 自动化提供了一种灵活的、经过验证的方法，可用于各种类型的软件项目。 与其他的 SCM 工具一样，Rational ClearCase 提供了所有关键的 SCM 功能，例如保护并版本化软件工件的能力。同时，与其他的 SCM 工具不同的是，Rational ClearCase 还提供了几种高级功能：
IBM Rational ClearCase 的术语与概念Rational Clearcase 的功能从广义上来讲可以分为两种基本类型：
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 项目还具有一个作为共享工作区一部分的集成流。 作为一名开发人员，您根据分配的活动对组件进行变更。一项活动本质上标识了在特定文件版本的环境中需要处理的一项任务、缺陷或者功能。这允许您关注需要完成的任务，而不需花时间决定哪些文件需要签入或者签出，也不用担心哪些文件与特定版本匹配等问题。 当您完成工作时，将活动提交经项目集成流。每个项目的集成流都是独立的，对于一个集成流提交的变更对于另一个项目来说是不具有可见性，直到这些变更合并到下一个项目基线中。 您需要定期地调整开发流基线以更新您的视图，并且访问所有近期提交且并入基线中的变更。从总体上来说，在发布操作前重新调整开发基线是非常好的习惯，这样可以确保在最新的基线基础上提交变更。 IBM Rational XDE 的术语与概念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 ClearCaseRational XDE 的用户偏好设置可以有多种，因此可能影响与 Rational ClearCase 之间的交互。如果使用 Rational XDE 2002 Rel 2.1 Service Release(SR)，那么大多数的设置已经事先设置好了。 推荐的设置、推荐设置的原理以及符合推荐设置范围内情况的原理将在下文中讨论。 与用户偏好设置相关的签出通过如下路径访问：Window>Preferences>Rational ClearCase>Advanced
Options>Operations 标签。如图 2 所示。 该话框中具有三种用户设置方式。其目的与推荐设置讨论如下。
与用户偏好设置相关的签入设置通过如下路径访问：Window>Preferences>Rational ClearCase>Advanced Options>Operations标签。如图2所示。 签入有两个相关选项：
与撤销签出操作相关的只有一种设置。可以通过如下路径访问：Window>Preferences>Rational ClearCase>Advanced Options>Operations 标签。如图 2 所示。
与活动偏好设置相关的只有一个设置。需要注意的是，这仅仅适用于使用 ClearCase UCM 的项目。可以通过如下路径访问：Window>Preferences>Rational ClearCase>Advanced Options>Operations 标签。如图 2 所示。
模型－代码同步偏好设置 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 选项。该设置的下拉列表框中包括如下选项：
由开发团队来决定这三个选项哪一个最适合用于项目。作为一般的推荐设置，您应该经过深思熟虑后再决定是否创建新的存储单元。例如，创建存储单元以便于分辨模型单元文件的归属以及减少合并。 一般来说，由于在分析与设计的早期阶段，框架可能会被频繁地、大规模地修改，因此会经常创建和/或移动建模元素。这表明，应该限制在该阶段放入存储单元中模型元素的数量和粒度。一般可以创建一到二级的包的控制级别，这将提供足够的灵活性直到框架稳定。一旦构架稳定下来，其中的元素可以在进行详细实施时分为独立的、更细粒度的存储单元。 Rational XDE 源代码控制偏好设置可以通过如下路径访问：Window>Preferences >Rational XDE>Source Control。如图 5 所示。 图 5：源代码控制偏好设置 
可以选择两种偏好设置：
协同使用Rational XDE与Base ClearCase在 Base ClearCase 环境中设置与使用 Rational XDE 是很简单的。本节概述了您作为开发者使用 Rational XDE 与基本的 ClearCase 进行配置管理时需要执行的不同活动的高级过程。 在真正开发活动进行之前需要进行一些步骤的设置：
设置 VOB、XDE 模型与项目文件的具体步骤不在此讨论。请参见"Rational ClearCase用户使用手册与 Rational XDE Service Release 文档"以获得更详细的信息。 为协同使用 Rational XDE 与 base ClearCase，您必须首先：
图 6：视图选择对话框 
如果您已经设置了开发环境，正常情况下您就可以添加新模型元素。
使用已经进行源代码管理的元素是相当简单的。您只需签出模型元素即可按需求修改它们。
一旦您完成了您需要进行的添加/修改操作，模型元素将进入 ClearCase，同时创建了新版本。
协同使用 XDE 与 UCM本节概述了您作为开发者使用 XDE 与 UCM 进行各种活动时所需的高级过程。 在实际开发活动前还需要进行一些步骤的设置：
当开发者开始工作于 UCM 项目时，您需要按照步骤确保您的环境正确设置，再进行开发活动。
Rational XDE 源代码控制偏好设置可以通过如下路径访问：Window>Preferences >Rational XDE>Source Control。如图 5 所示。 图 5：源代码控制偏好设置
可以选择两种偏好设置：
协同使用Rational XDE与Base ClearCase在 Base ClearCase 环境中设置与使用 Rational XDE 是很简单的。本节概述了您作为开发者使用 Rational XDE 与基本的 ClearCase 进行配置管理时需要执行的不同活动的高级过程。 在真正开发活动进行之前需要进行一些步骤的设置：
设置 VOB、XDE 模型与项目文件的具体步骤不在此讨论。请参见"Rational ClearCase用户使用手册与 Rational XDE Service Release 文档"以获得更详细的信息。 为协同使用 Rational XDE 与 base ClearCase，您必须首先：
图 6：视图选择对话框
如果您已经设置了开发环境，正常情况下您就可以添加新模型元素。
使用已经进行源代码管理的元素是相当简单的。您只需签出模型元素即可按需求修改它们。
一旦您完成了您需要进行的添加/修改操作，模型元素将进入 ClearCase，同时创建了新版本。
协同使用 XDE 与 UCM本节概述了您作为开发者使用 XDE 与 UCM 进行各种活动时所需的高级过程。 在实际开发活动前还需要进行一些步骤的设置：
当开发者开始工作于 UCM 项目时，您需要按照步骤确保您的环境正确设置，再进行开发活动。
一旦您已经设置开发环境，就可以添加新模型元素。
签出源码控制中的元素非常简单。您只需签出模型元素，然后按需要修改它们即可。
在 UCM 中，您需要将您的工作交付给集成流，从而使其他成员知道您的工作。这可以通过 Deliver to stream 选项实现。 为获得他人近期所作的变更，开发者需要调整基线。 其他应知事项使用优秀思想设计且得出最佳效果的软件配置管理包括若干方面。本节提供并且概述一些这方面的内容。 合并是一项耗时的任务，而且对于 CM 系统来说，它并不总是能够检测到互相冲突的变更。使用特定的方式获得模型所有权可以约束所需的合并。 一般来说，模型所有权策略分成以下几个部分：
处理模型所有权的一种方法就是考虑特定活动中的成员的数量以及水平。例如，参与分析活动的人员可能占少数，而人数较多的团队可能会负责构建应用程序。在这种情况下，所有权策略可能会随着开发进程的不同而有所改变，从分析阶段基于模型的所有权到设计过程中的包所有权，再到构建过程中的单元所有权。 Martin Fowler 给出了重构的定义："变更软件系统的过程，可以在不改变代码的外部行为的情况下，改进其内部结构"。从开发者的观点看，这是比较普通的活动，一般情况下都需要在不改变外部形式的情况下修改设计或工件。 下面是一些简单的重构示例：
在可视开发环境和SCM中某些重构过程引起问题。例如，以下操作可能产生问题：
这是因为已在 ClearCase 中设置版本的元素不能只通过在 XDE 中重命名而完成重命名操作。推荐您尽可能少使用重构，即使在不得不使用时，应该遵循一些基本的推荐方式。关于 XDE 与 ClearCase 的重构，请参见 Rational XDE SR 文档中的更多指南。 当跨模型引用不明确时，该不明确的引用在模型中通过特殊的图标来识别。例如这种情况可能会在包含跨模型引用的模型共享时出现。 一些不明确引用的特殊图标如图 7 所示。在该图中，C 1 为外部引用，通过在左上角的箭头来识别。右上角圆圈中的"X"表明 C 1 是不明确的。继承关联中圆圈内的"\"表示被继承 C 1 是不明确的。如果 C 2 是外部不明确引用，该继承关联会以"X"表示，以表明关联中双方都是不明确的。 一旦您已经设置开发环境，就可以添加新模型元素。
签出源码控制中的元素非常简单。您只需签出模型元素，然后按需要修改它们即可。
在 UCM 中，您需要将您的工作交付给集成流，从而使其他成员知道您的工作。这可以通过 Deliver to stream 选项实现。 为获得他人近期所作的变更，开发者需要调整基线。 其他应知事项使用优秀思想设计且得出最佳效果的软件配置管理包括若干方面。本节提供并且概述一些这方面的内容。 合并是一项耗时的任务，而且对于 CM 系统来说，它并不总是能够检测到互相冲突的变更。使用特定的方式获得模型所有权可以约束所需的合并。 一般来说，模型所有权策略分成以下几个部分：
处理模型所有权的一种方法就是考虑特定活动中的成员的数量以及水平。例如，参与分析活动的人员可能占少数，而人数较多的团队可能会负责构建应用程序。在这种情况下，所有权策略可能会随着开发进程的不同而有所改变，从分析阶段基于模型的所有权到设计过程中的包所有权，再到构建过程中的单元所有权。 Martin Fowler 给出了重构的定义："变更软件系统的过程，可以在不改变代码的外部行为的情况下，改进其内部结构"。从开发者的观点看，这是比较普通的活动，一般情况下都需要在不改变外部形式的情况下修改设计或工件。 下面是一些简单的重构示例：
在可视开发环境和SCM中某些重构过程引起问题。例如，以下操作可能产生问题：
这是因为已在 ClearCase 中设置版本的元素不能只通过在 XDE 中重命名而完成重命名操作。推荐您尽可能少使用重构，即使在不得不使用时，应该遵循一些基本的推荐方式。关于 XDE 与 ClearCase 的重构，请参见 Rational XDE SR 文档中的更多指南。 当跨模型引用不明确时，该不明确的引用在模型中通过特殊的图标来识别。例如这种情况可能会在包含跨模型引用的模型共享时出现。 一些不明确引用的特殊图标如图 7 所示。在该图中，C 1 为外部引用，通过在左上角的箭头来识别。右上角圆圈中的"X"表明 C 1 是不明确的。继承关联中圆圈内的"\"表示被继承 C 1 是不明确的。如果 C 2 是外部不明确引用，该继承关联会以"X"表示，以表明关联中双方都是不明确的。 图 7：不明确引用图标 
Rational XDE 为处理不明确引用提供了内置功能。为处理不明确引用，您需要按照下述步骤：
从现在开始，模型的进一步更新将会进行正确地分辨。 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。对于每种组合，都推荐进行特定的设置以确保最佳的工作环境。 参考资料
|
| |||
组织简介 | 联系我们 | Copyright 2002 ® UML软件工程组织 京ICP备10020922号 京公海网安备110108001071号 |
