實施模型是構件及其所在的實施子系統的集合。構件中既有可交付構件（例如執行檔），又有用來生成可交付檔案的構件（例如原始碼檔案）。
基本介紹
- 中文名：實施模型
- 目的：構建和管理系統
- 特徵：屬於“短文本”類型
- 時機：在精化階段中建立的
中科永聯高級技術培訓中心（www.itisedu.com）
實施模型是構件及其所在的實施子系統的集合。構件中既有可交付構件（例如執行檔），又有用來生成可交付檔案的構件（例如原始碼檔案）。
一、實施模型的目的
實施模型為組裝的綜合工件，包括在運行時環境中構建和管理系統時所需的所有工件。
二、實施模型的特徵
特徵名 簡要說明 UML 表示 簡介 用作模型的簡要介紹的文本說明 標註值，屬於“短文本”類型 實施子系統 模型中的子系統，代表一個層次結構 通過元關聯關係“represents”擁有，或通過元聚合關係“owns”遞歸擁有。 構件 模型中的構件，由子系統擁有 通過元聚合關係“owns”而遞歸擁有 關係 模型中的關係，由子系統擁有 - " - 圖 模型中的圖，由子系統擁有 - " - 實施視圖 模型的實施視圖，它是子系統和層的構架視圖 視圖中的元素和圖通過元聚合關係“owns”遞歸擁有
特徵名 | 簡要說明 | UML 表示 |
簡介 | 用作模型的簡要介紹的文本說明 | 標註值，屬於“短文本”類型 |
實施子系統 | 模型中的子系統，代表一個層次結構 | 通過元關聯關係“represents”擁有，或通過元聚合關係“owns”遞歸擁有。 |
構件 | 模型中的構件，由子系統擁有 | 通過元聚合關係“owns”而遞歸擁有 |
關係 | 模型中的關係，由子系統擁有 | - " - |
圖 | 模型中的圖，由子系統擁有 | - " - |
實施視圖 | 模型的實施視圖，它是子系統和層的構架視圖 | 視圖中的元素和圖通過元聚合關係“owns”遞歸擁有 |
特徵名
簡要說明
UML 表示
三、實施模型的時機
實施模型結構是在精化階段中建立的，並根據需要在構建階段中進行改進。
四、實施模型的職責
構架設計師負責實施模型的完整性，確保：
作為一個整體，實施模型是正確、一致和可讀的。當實施模型實現了用例模型中所述的功能時，它就是正確的模型。
實施視圖中所述的實施模型的構架可實現其目的。實施視圖單獨用一個工件進行說明，請參見工件：軟體構架文檔中。
注意，構架設計師不負責實施子系統和構件，它們應該由相應的實施員負責。
實施視圖中所述的實施模型的構架可實現其目的。實施視圖單獨用一個工件進行說明，請參見工件：軟體構架文檔中。
注意，構架設計師不負責實施子系統和構件，它們應該由相應的實施員負責。
五、實施模型的定製
您必須決定如何將設計模型中的類和包映射到實施模型中的構件和子系統中。
六、建立實施模型
創建最初的實施模型結構
目的
建立實施模型的初始結構。
建立實施模型的初始結構。
“設計空間”向“實施空間”轉換的過程是以在實施模型中反映設計模型的結構開始的。
設計包都有相應的實施子系統，其中包括一個或幾個構件以及實施此構件所需的所有相關檔案。將每一個實施子系統分配給結構中的某一特定層時，從設計模型到實施模型的映射可能會隨之改變。注意，設計模型中的類和可能包括的設計子系統都將映射為實施模型中的構件－雖然不必一一對應（請參見概念：從設計到代碼的映射以及工件：設計子系統）。
創建構件圖來表示實施模型結構。下面顯示了一個簡單的構件圖：
實施模型簡單自動櫃員機的構件圖例
調整實施子系統
目的
修改模型結構使之反映團隊組織或者實施語言的約束。
修改模型結構使之反映團隊組織或者實施語言的約束。
通過處理與實施環境相關的小戰術問題，確定是否需要修改子系統的組織。以下是這類戰術問題的一些示例。注意，如果決定要改變實施子系統的組織，您還必須確定是否應當回過頭去更新設計模型，或者允許設計模型與實施模型之間存在差別。
開發團隊組織。子系統的結構必須能允許幾個實施員或實施員團隊並行工作，而他們的工作不會過份重疊，也不會造成混淆。因此建議每一個實施子系統由一個且只由一個團隊負責。這意味著最好將一個子系統分成兩個部分（如果它太大的話），並將它們分配給兩個實施員或兩個實施員團隊去具體實施，尤其當這兩個實施員（或團隊）有各自不同的構建/發布周期時更應如此。
類型聲明。由於在某個子系統中已經聲明類型，因此在實施過程中您將會意識到該子系統需要從另一個子系統中導入構件。通常，當您使用類型化程式語言（如 C++、Java 和 Ada）時，將會出現上述情況。一般而言，在這種情況下，提取類型聲明生成一個獨立的子系統是一種明智的做法。
示例
類型聲明。由於在某個子系統中已經聲明類型，因此在實施過程中您將會意識到該子系統需要從另一個子系統中導入構件。通常，當您使用類型化程式語言（如 C++、Java 和 Ada）時，將會出現上述情況。一般而言，在這種情況下，提取類型聲明生成一個獨立的子系統是一種明智的做法。
示例
從子系統 D 中提取出某些類型聲明生成一個新的子系統類型，使得子系統 A 不受子系統 D 中公有（可見的）構件變更的影響。
實施模型從子系統 D 中提取類型聲明
.
現有的遺留代碼和構件系統。您最好將遺留代碼、可復用的構件庫或者是市售的產品合併起來。如果在設計時沒有建立它們的模型，則此時必須加入對應的實施子系統。
調整依賴關係。假定子系統 A 和子系統 B 相互之間有導入依賴關係。然而，您最好減少子系統 B 對子系統 A 變化的依賴性。可以提取出系統 B 從系統 A 中導入的構件，並在較低層中建立新的實施子系統 A1 。
調整依賴關係。假定子系統 A 和子系統 B 相互之間有導入依賴關係。然而，您最好減少子系統 B 對子系統 A 變化的依賴性。可以提取出系統 B 從系統 A 中導入的構件，並在較低層中建立新的實施子系統 A1 。
從子系統 A 中提取構件，並將它們放置在新的子系統 A1
實施模型為每個實施子系統定義導入
目的
定義子系統間的依賴關係。
定義子系統間的依賴關係。
為每個子系統定義它所導入的其他子系統。可以為整個子系統集定義導入，即允許某一層的所有子系統導入較低層的所有子系統。一般而言，實施模型的依賴關係將反映設計模型的依賴關係，除非實施模型的結構已經過調整（請參見調整實施子系統）。
用構件圖表示子系統的分層結構。
確定如何處理執行檔（以及其他派生的對象）
執行檔（以及派生的對象）是將構建流程套用於一個（或多個）實施子系統或系統某一部分得到的結果，因此它們在邏輯上應屬於實施子系統。無論如何，構架設計師將和配置經理一道共同確定將要套用於實施模型的配置項結構。
執行檔（以及派生的對象）是將構建流程套用於一個（或多個）實施子系統或系統某一部分得到的結果，因此它們在邏輯上應屬於實施子系統。無論如何，構架設計師將和配置經理一道共同確定將要套用於實施模型的配置項結構。
為了便於選擇和參考，尤其是為了方便部署，默認的推薦方案是定義獨立的配置項以包含可部署的執行檔集。因此，在簡單的情況下，每一個實施子系統都有兩個配置項：一個用於包含可配置的執行檔，另一個用於包含生成這些檔案所使用的原始資料。實施子系統可以視為包含這些配置項（也許還有其他配置項，比如測試資產等）的複合配置項。
從建模的角度看，構建流程中生成的執行檔的集合可以表示為包含在相關實施子系統（本身是一個包）內的工件：工作版本（也是一個包）。
確定如何處理測試資產
目的
將測試工件添加到實施模型中。
將測試工件添加到實施模型中。
一般而言，Rational Unified Process 處理測試構件和測試子系統的方式與其他開發軟體並沒有大的區別。然而，測試構件和子系統一般不構成部署系統的一部分，而且通常不能交付給客戶。因此，默認的推薦方案是將測試資產與測試目標（例如，單元測試針對的構件、集成測試針對的實施子系統、系統測試針對的系統）結合起來，但需要將測試資產保存在不同的目錄中（如果項目儲存庫按照一組目錄或者分層目錄結構進行組織）。不同的測試子系統（用於單元測試級別以上的測試）應當和其他實施子系統一樣，被視為不同的配置項。
從建模角度看，測試構件的集合可以表示為工件：實施子系統（一個包）。對於單元測試，這類測試子系統通常應當包含在相關的（被測試的）實施子系統中。與配置經理商議後，構架設計師應決定是否將該級別的測試構件與它們測試的構件一起配置，或者作為獨立的配置項進行配置。對於集成測試和系統測試，測試子系統和被測試的實施子系統是對等的。
更新實施視圖
目的
更新軟體構架文檔的實施視圖。
更新軟體構架文檔的實施視圖。
實施視圖在軟體構架文檔的“實施視圖”部分中進行說明。此部分包含的構件圖顯示了各個層和將實施子系統分配到層的分配形式，以及子系統之間的導入依賴關係。© 1987 - 2001 Rational Software Corporation。著作權所有。
