軟體系統和複雜的硬體架構很少是簡單的。隨著需求增加，組件內部的連接變得錯綜複雜。標準圖表通常只顯示什麼存在，但很難顯示如何零件如何在特定分類器內部組合在一起。這正是UML組合結構圖變得至關重要的地方。它提供了分類器內部結構的細節視圖，揭示了零件、角色和連接器之間的關係。
若缺乏這種細節層級，架構師可能建造出難以維護或擴展的系統。理解類別或組件的內部組成對於高保真建模至關重要。本指南探討了此類圖表的必要性，並提供了一套清晰的創建方法。
什麼是組合結構圖？🧩
組合結構圖（CSD）是統一建模語言中的一種結構圖。它用來模擬分類器的內部結構及其內部零件之間的互動。雖然類圖顯示屬性和方法，組件圖顯示可部署單元，但CSD專注於內部機制.
可以把它想像成一間房子中特定房間的設計圖，而不是整棟建築的平面圖。它詳細說明：
- 零件： 分類器內部的單獨組件。
- 角色： 零件所扮演的介面或責任。
- 埠： 與外部世界互動的點。
- 連接器： 零件之間的連結。
當處理需要嚴格內部邊界或內部連接決定了系統行為的系統時，此圖表尤為重要。
組合結構圖的構造 🔍
要繪製出有效的圖表，你必須理解基本構件。這些元素定義了系統內的關係與邊界。
1. 零件 🧱
零件是被組合分類器所擁有的分類器實例。它代表大型結構內部的一個組件。在軟體情境中，零件可能是一個子程序、資料庫連接池或特定模組。
- 可見性： 零件可以是公開的、私有的或受保護的。
- 多重性： 你可以指定零件實例的數量（例如：1，0..*，1..1）。
2. 角色 🎭
當一個組件與另一個組件或外部世界互動時，它會以特定的角色進行。這個角色就是功能。單一組件可能在不同時間或針對不同互動扮演多個角色。
- 角色通常由介面來表示。
- 它們定義了組件所提供的服務或所需的服務。
3. 埠 📡
埠是分類器上的一個命名互動點。它作為內部結構與外部環境之間的邊界。可以將埠想像成主機板上的插座；它允許外部電纜連接到內部電路。
- 提供的介面： 埠提供給其他組件的功能。
- 所需的介面： 埠運作時需要其他組件提供的功能。
4. 連接器 🔗
連接器連結互動點。它們定義了資料或控制在組件之間，或組件與外部環境之間的傳輸方式。
- 內部連接器： 連結同一個複合分類器內的組件。
- 外部連接器： 連結複合分類器的埠與其他分類器。
為何你的架構需要此視圖 📈
許多架構師僅依賴類圖或順序圖。雖然這些圖表很有用，但往往忽略了複雜系統所需的結構細節。以下是為何你應該投入時間學習複合結構圖的原因。
1. 明確內部複雜性 🧠
當一個類別變得過於複雜時，它會變成「上帝對象」。複合結構圖迫使你將其拆解。它能視覺化責任的委派。如果一個類別包含太多組件，你就知道它需要重構。
2. 管理邊界 🚧
埠與介面定義了嚴格的邊界。它們可防止內部實作細節洩漏至公開 API。這符合封裝原則，並使系統更能抵禦變更。
3. 硬體-軟體共同設計 🖥️
嵌入式系統通常混合了軟體與硬體。CSD 可以模擬一個微控制器（硬體）內含特定軟體驅動程式（組件）。這種混合建模在標準 UML 圖中難以實現，但卻是複合結構圖的原生功能。
4. 重用與組合 ♻️
設計模式通常依賴於組合。透過明確地建模組件，你可以在不同的分類器之間重用內部結構。如果你一次定義了「記錄系統」組件，就可以將它插入多個分類器中。
CSD 與其他 UML 圖表的比較 🔄
了解何時使用 CSD，需要知道它與其他圖表的差異。下表概述了這些差異。
| 圖表類型 | 重點 | 最適合用於 |
|---|---|---|
| 類圖 | 靜態結構、屬性、方法 | 資料庫結構、一般物件關係 |
| 組件圖 | 高階部署、實體檔案 | 系統部署、模組邊界 |
| 複合結構圖 | 內部結構、組件、角色、埠 | 複雜的內部接線、嵌入式系統、詳細設計 |
| 物件圖 | 特定時刻的執行時期實例 | 狀態快照、測試情境 |
請注意，CSD 位於抽象的類圖與實體的組件圖之間。它彌補了邏輯設計與實體實作之間的差距。
繪製一個的逐步指南 📝
繪製圖表需要有系統的方法。不要一開始就畫方框。應先分析需求。
步驟 1：識別分類器 🏷️
決定您要建模的類別或組件為何。是特定的服務嗎？還是硬體控制器？確保此分類器足夠複雜，值得進行內部分解。如果它僅有兩個屬性，則使用 CSD 就過度了。
步驟 2：定義組件 🛠️
列出構成分類器的內部組件。這些應為邏輯上的工作單元。
- 分解責任。是否有一個組件負責資料？另一個是否負責邏輯？
- 指定多重性。是否可以沒有組件，還是必須恰好有一個？
- 為組件使用標準分類器（例如：資料庫連接、記錄器）。
步驟 3：指定埠與介面 🔌
針對每個組件，決定其如何通訊。
- 此組件運作所需的條件為何？（所需介面）
- 此組件提供給其他組件的服務為何？（提供介面）
- 定義主分類器上的埠。這些是外部世界進入的入口點。
步驟 4：繪製連接器 ⛓️
將組件連結起來。這正是邏輯流動的地方。
- 將一個組件的輸出連接到另一個組件的輸入。
- 確保連接點處的資料類型相符。
- 如果連接器為單向，請標示其方向。
步驟 5：檢視與驗證 ✅
走過一次圖表。如果某個特定組件失效，系統是否仍能運作？是否存在循環依賴？外部介面是否符合內部實際情況？
現實世界應用 💻
為了讓這更具體，讓我們看看這如何應用於實際的工程情境。
情境 1：微服務架構 🔗
在微服務環境中，「付款服務」可能包含內部組件：交易記錄器、詐欺偵測器與網關適配器。CSD 展示了網關適配器在交易記錄器記錄資料之前，如何將資料傳遞給詐欺偵測器。這在不需完整序列圖的情況下，清楚地說明了執行順序。
情境 2：嵌入式控制系統 🚗
汽車煞車系統包含感測器、控制器與致動器。CSD 模擬控制器的內部邏輯。它顯示感測器組件需要資料串流，運算組件使用該串流，致動器組件接收指令。這清楚地呈現了軟體與硬體驅動程式之間的緊密耦合。
情境 3：GUI 框架 🖱️
視窗元件通常包含較小的組件：標題列、內容區域與關閉按鈕。每個組件都有其獨特的行為。CSD 定義這些組件的排列方式，以及使用者點擊關閉按鈕時它們如何通訊。
應避免的常見錯誤 ⚠️
即使經驗豐富的架構師在建模時也會犯錯。請留意這些陷阱。
- 過度建模： 不要為每個類別都建立 CSD。僅對複雜結構進行建模。當內部連接方式至關重要時才使用。
- 忽略多重性： 未明確指定組件數量會導致模糊不清。系統可能需要三個緩衝區實例，而不僅僅是一個。
- 層級混雜： 不要在同一張圖表中混用高階組件與低階變數。保持細節層級的一致性。
- 遺漏埠點： 確保所有外部互動都必須透過埠點進行。內部組件直接連結外部世界會破壞封裝性。
維護的最佳實務 🛠️
圖表是活文件，必須隨著程式碼的演進而更新。
- 保持更新： 如果程式碼變更，圖表也必須跟著變更。過時的圖表所造成的混淆，甚至超過沒有圖表的情況。
- 使用範本： 如果您的架構使用標準模式，請為常見組件建立範本。這能加快建模速度並確保一致性。
- 連結至程式碼： 在可能的情況下，將圖表元件連結至實際的程式碼倉儲。這能確保可追蹤性。
- 限制深度： 避免過度嵌套圖表。如果某個組件需要自己的CSD，請連結到獨立的圖表，而不是內聯繪製。這樣可以保持主視圖的可讀性。
關鍵元素分解表 📊
為了快速參考，以下是您將遇到的核心元素摘要。
| 元素 | 符號 | 用途 |
|---|---|---|
| 組件 | 帶有類名的矩形 | 代表複合結構內部分類器的實例。 |
| 角色 | 介面符號或棒棒糖符號 | 定義組件所公開或需要的行為。 |
| 埠 | 邊緣上的小方塊 | 分類器邊界上的互動點。 |
| 連接器 | 帶箭頭的線條 | 連結互動點以實現資料流。 |
| 合作 | 帶標籤的虛線框 | 將組件和連接器分組，以定義特定的互動情境。 |
關於結構完整性的最後想法 🏛️
建立穩健的軟體不僅僅需要撰寫程式碼，還需要清晰地掌握各組件如何結合。UML複合結構圖提供了一種嚴謹的方式來記錄這種視野。它迫使架構師正面應對內部複雜性。
透過專注於組件、角色和埠，您將建立一個既詳細又易於維護的模型。它能降低隱藏依賴的風險，並明確資料在系統中如何流動。雖然繪製需要額外努力，但為開發團隊帶來的清晰度，使這項投入值得。
從今天開始，將此技術應用於您最複雜的類別。您會發現，您的架構內部佈線將如同外部介面一樣清晰。
