本文并沒有涉及與 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。對于每種組合，都推薦進行特定的設置以確保最佳的工作環境。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
