使用
可以通過多種互補的方法來使用子系統，將系統分為若干個單元，這些單元：
可以獨立預定、配置或交付 可以獨立開發（只要接口保持不變） 可以在一組分散式計算節點上獨立部署 可以在不破壞系統其他部分的情況下獨立地進行更改 此外，子系統還可以：
子系統將系統分為若干單元，以提供對關鍵資源的有限安全保護 在設計中代表現有產品或外部系統
從類協作中確定子系統
如果某個協作中的各個類只是在相互之間進行互動，並且可生成一組定義明確的結果，就應將該協作和它的類封裝在一個子系統中。
這一規則同樣適用於協作的子集。可以對協作的任何部分或全部進行封裝和簡化，這將會使設計更易於理解。
提示
| 提示 | 詳細說明 |
| 注意可選性 | 如果特定的協作（或子協作）代表可選行為，則應將其封裝在一個子系統中。如果可以將某些功能刪除、升級或替換為其他功能，就應該認為這些功能是獨立的。 |
| 注意系統的用戶界面。 | 如果用戶界面相對獨立於系統中的實體類（即二者都可以且將要獨立地變更），則應創建橫向集成的子系統：將相關的用戶界面邊界類歸入一個子系統，而將相關的實體類歸入另一個子系統。 |
| 如果用戶界面和它所顯示的實體類緊密耦合（即一方的變更會觸發另一方的變更），則應創建縱向集成的子系統：將相關的邊界類和實體類裝入共同的子系統中。 | |
| 注意主角 | 將兩個不同主角使用的功能分開，因為每個主角可能會獨立變更自己對系統的需求。 |
| 查找類與類之間的耦合和內聚 | 耦合度或內聚度較高的類彼此協作，以提供某一組服務。將耦合度較高的類組織成子系統，沿著弱耦合的界線將類分開。在某些情況下，可以將類分成更小的類，使其具有內聚度更高的職責，從而完全消除弱耦合。 |
| 注意替換 | 如果為某項特定功能指定了幾個服務級別（例如，高、中、低可用性），則要將每個服務級別表示成一個獨立的子系統，每個子系統都將實現同一組接口。這樣，子系統就可互相替換。 |
| 注意分布 | 雖然一個特定子系統可能有多個實例，每個實例都在不同的節點上執行，但不可能在各節點間拆分子系統的單個實例。如果必須在各節點間拆分子系統行為，則需要將子系統分成更小的子系統，使其具有限制更嚴格的功能。確定必須存在於每個節點上的功能，並創建一個新的子系統，使其“擁有”該功能，然後相應地在該子系統內分布職責和相關元素。 |
一旦將類組織成子系統，就要相應地更新用例實現。
記錄子系統
一旦創建了子系統：供一個名稱和一段簡短說明。 如果工具支持包但不支持子系統，可以用包來記錄子系統；在此環境中應使用包構造型表示子系統。 應將原始分析類的職責轉移給新建的子系統，並使用該子系統的說明來記錄職責。
子系統和構件
構件屬於實施範疇；為了在設計中表示構件，可以將子系統用作構件的代理。
系統的每個部分都應儘可能獨立於系統的其他部分。 從理論上說，應該可以用新的部分替換系統的任何部分，但前提是新部分必須支持相同的接口。 應該可以使系統的不同部分獨立地演進，而不受系統其他部分的影響。 為此，設計子系統提供了一種在設計模型中表示構件的理想方法：它們是用來封裝許多類的行為的設計元素（就象構件封裝許多類實例的行為一樣），並且只能通過它們所實現的接口訪問它們的行為（構件就是這樣）。
代表現有產品的子系統
如果現有產品是用來導出接口（即操作，也許會導出接收）的產品，但卻隱藏了實施的所有細節，就可以在邏輯視圖中將該產品建模為子系統。您可以用子系統表示系統所使用的產品，例如：
通信軟體（中間件）。 資料庫訪問支持（RDBMS 映射支持）。 應用程式專用產品。 某些現有的產品，如類型集合和數據結構（例如，棧、列表、佇列）最好用包來表示，因為它們所展示的不僅僅是行為。既重要又有用的是包中的特定內容，而不是包本身，包不過是一個容器而已。
對於常用的實用程式（如數學庫），如果它們只導出接口，就可以將其表示成子系統，但這是否有必要或有意義，還要取決於設計人員對建模對象性質的判斷。子系統是面向對象的構造，它們不僅是分類器，還是包：子系統可以具有實例（如果設計人員作出這樣的指定）。通過 UML，也可以在作為構造型類的實用程式（該實用程式沒有實例）中建立多組全局變數和過程的模型。
當定義子系統來代表產品時，還要定義一個或多個接口來表示產品接口。
子系統依賴關係限制
子系統與包在語義上具有差異：子系統是一種通過一個或多個它所實現的接口來提供行為的包。包並不提供行為；它們只不過是用來容納提供行為的對象的容器。
之所以要使用子系統而不使用包，是因為子系統完全封裝自己的內容，只通過自己的接口提供行為。其好處在於，與包不同，只要子系統的接口保持不變，就可以完全自由地更改子系統的內容和內部行為。另外，子系統還提供了一種“可替換的設計”元素：任何兩個實現相同接口的子系統（或類，就此而論）都可以互換。
規則
為確保子系統在模型中是可互換的元素，需要執行以下幾條規則：
子系統不應暴露自己的任何內容（即，子系統所包含的元素都不應有“公有”的可見性）；子系統外部的元素都不應依賴於子系統內部特定元素的存在。 子系統只應依賴於其他模型元素的接口，因此它不直接依賴於子系統外部的任何特定模型元素。例外情況是，許多子系統共享一組類定義。在這種情況下，這些子系統將“導入”包含公共類的包中的內容。這一操作只應對位於構架低層的包執行，並且只能是為了確保必須在子系統之間傳遞的公共類定義保持一致。
以下顯示了子系統和包的依賴關係的示例：
示例設計模型中子系統和包的依賴關係
