理解軟體系統內部的結構關係，是穩健架構設計的根本。在統一模型語言（UML）提供的各種圖形化工具中，組合結構圖提供了內部結構的細節視圖。特別是正確地建模聚合，能確保組件的生命週期與所有權關係明確界定。本指南探討在此背景下聚合的運作機制，並提供具體可行的步驟，以準確呈現該關係。
在設計複雜系統時，區分不同類型的關係至關重要。聚合代表一種特定的關聯，其中一個類別持有對另一個類別的參考，但並無嚴格的所有權。這種細微差別會影響資料流動方式以及物件的銷毀方式。透過掌握視覺符號與邏輯含義，架構師能夠建立真正反映系統行為的圖表。
🔍 理解組合結構圖
組合結構圖專注於分類器的內部組成。它顯示一個類別如何由其組成部分構建而成。與僅顯示類別之間關係的標準類圖不同，此圖聚焦於內部配置。它強調埠、介面與連接器，這些元素使各部分之間得以互動。
主要元素包括：
- 分類器： 最上層的容器，用以定義結構。
- 部分： 包含在主要分類器內的其他分類器的實例。
- 埠： 部分與外部世界連接的互動點。
- 連接器： 用以建立部分之間通訊路徑的連結。
聚合在此框架中被視為組合分類器與其部分之間的關係。它暗示一種「整體-部分」關係，但這種關係並非排他性的。部分可以獨立於整體而存在。
⚖️ 定義聚合與組合的差異
聚合與組合之間常產生混淆。兩者都涉及整體中的部分，但其生命週期依賴性不同。理解此區別對於準確建模至關重要。
聚合特性
- 弱所有權： 部分可以在沒有整體的情況下存在。
- 生命週期獨立性： 毀滅組合並不會毀滅部分。
- 共享責任： 多個整體可能共同擁有同一個部分實例。
- 視覺符號： 通常以組合側的空心菱形表示。
組合特性
- 強所有權： 部分無法在沒有整體的情況下存在。
- 生命週期依賴性：摧毀組合會導致部分被摧毀。
- 獨占性擁有：一個部分通常只屬於一個整體。
- 視覺符號：通常以實心菱形表示，位於組合端。
在建模聚合時，目標是顯示整體使用部分，但不控制其創建或銷毀。例如，部門聚合員工。如果部門解散，員工仍作為個體存在。
🎨 UML 中的視覺符號規則
符號的一致性確保任何閱讀圖表的人都能立即理解設計意圖。UML 規範提供了明確的指南來表示聚合。
1. 菱形符號
在與組合類相連的關聯線末端放置一個空心菱形。這在視覺上表示聚合。請確保菱形未填滿，否則會錯誤地暗示組合。
2. 多重性
定義整體中存在多少部分。常見的多重性值包括：
- 0..1:可選部分。
- 1:必須恰好有一個部分。
- 0..*:允許零個或多個部分。
- 1..*:必須有一個或多個部分。
3. 角色名稱
為關聯線的兩端標註，以明確關係的視角。靠近部分的一端通常會標示角色名稱，表示整體如何看待該部分。
🛠️ 分步建模流程
建立精確的圖表需要系統性的方法。遵循以下步驟以確保清晰與正確。
步驟 1：識別組合類
首先定義作為容器的主要類。這是在關係中的「整體」。考慮系統的範圍。這是一個高階模組還是特定組件？
步驟 2：識別部分類
確定構成內部結構的內容。這些就是「部分」。問問這些部分是否能在整體的上下文之外邏輯上存在。如果可以，則聚合很可能是正確的關係。
步驟 3：定義關係
繪製一條連接組合類與部分類的線。將空心菱形放置在組合類的一側。這確立了聚合的方向。
步驟 4：指定多重性
在線條的兩端添加多重性約束。這定義了基數。例如，圖書館可能擁有 1..* 本書。一本書可能擁有 0..1 個 ISBN。
步驟 5：新增角色與關聯
標示角色。在整體的背景下，一個零件可能被稱為「組件」或「模組」。確保這些名稱在文件中保持一致。
🔄 管理零件生命週期
結構建模中最常見的錯誤之一，是假設存在生命週期依賴關係，而實際上並不存在。聚合明確地解耦了生命週期。在建模時，請考慮以下情境。
- 共用實例：同一個零件實例能否被傳遞給多個組合實例？如果可以，則只有聚合是合適的選擇。
- 外部持久化：當組合被移除後，零件的資料是否仍會保留在資料庫中？如果會，則應避免使用組合。
- 可重用性：這個零件是否設計為可在不同系統中重用？聚合支援這種彈性。
未能尊重生命週期的獨立性，可能會導致實際實作中出現記憶體洩漏或孤立資料。該圖表應作為開發人員實作邏輯時的合約。
🔌 介面與埠
在組合結構圖中，互動通常透過埠進行調解。聚合並不代表零件會直接使用整體的介面，但它可能提供服務。
- 提供的介面：零件可能提供功能，而組合會將這些功能對外公開。
- 所需的介面：組合可能需要來自零件的功能才能運作。
- 連接器：使用連接器將組合上的所需介面對應到零件上的提供介面。
這層抽象允許交換實作方式。如果零件是聚合關係，則可以替換為另一個實作相同介面的類別，而不會破壞組合的內部邏輯。
🚫 常見陷阱與最佳實務
即使經驗豐富的架構師在定義結構關係時也可能出錯。請審查這些常見問題以避免犯錯。
陷阱 1：混淆聚合與關聯
所有聚合都是關聯，但並非所有關聯都是聚合。聚合暗示了一種結構上的「部分」關係。簡單的關聯可能僅表示兩個類別彼此知道，而其中一個並未包含另一個。
陷阱 2：過度建模
不要為每一個關係都建立模型。專注於定義類別行為的結構組成。過度細節會使圖表混亂，並掩蓋主要架構。
陷阱 3：忽略導航
聚合暗示從整體到零件的導航。確保程式碼支援從組合到零件的遍歷。如果導航只能反向進行，則圖表具有誤導性。
📊 比較表格：聚合情境
下表總結了根據系統行為，何時應使用聚合而非其他關係。
| 情境 | 關係類型 | 推理 |
|---|---|---|
| 汽車擁有引擎 | 組合 | 引擎是專屬於汽車的；移除汽車也會同時移除引擎的上下文。 |
| 部門擁有員工 | 聚合 | 員工獨立存在；他們可以轉至其他部門。 |
| 團隊擁有成員 | 聚合 | 成員可能屬於多個團隊，或離開團隊但仍為使用者。 |
| 訂單包含項目 | 聚合 | 項目可能被退回庫存或用於其他訂單。 |
| 房屋擁有房間 | 組合 | 房間通常在沒有房屋結構的情況下無法存在。 |
🧩 實際應用情境
為了加深理解，請考慮聚合至關重要的特定應用領域。
1. 企業資源規劃
在ERP系統中，專案聚合任務。任務具有獨立的生命週期，可重新分配。專案聚合這些任務以管理排程，但銷毀專案不會清除任務的歷史記錄。
2. 電子商務系統
購物車聚合產品。產品即使不在購物車中，也依然存在於目錄中。購物車僅管理暫時的集合，但不擁有產品資料。
3. 教育管理
課程聚合模組。模組是可重複使用的資源，可屬於多門課程。課程聚合這些模組以定義課程路徑。
📝 實作考量
將圖示轉換為程式碼時，聚合會轉換為成員變數或依賴注入。不需要對物件進行深層複製，僅需參考或指標即可。
- 記憶體管理：當組合物件被銷毀時，請勿手動刪除零件物件。
- 垃圾回收：執行時期環境會獨立處理零件的生命週期。
- 參考計數：若使用具有參考計數的語言，請確保零件在仍被其他組合物件參考時不會被釋放。
文件應明確說明聚合合約。開發人員需知道他們不能假設對零件實例擁有獨佔控制權。這可防止清理程式中出現邏輯錯誤。
🔗 結構完整性總結
在UML組合結構圖中準確建模聚合關係，可強化設計階段。它能明確界定所有權邊界與生命週期預期。透過遵循標準符號並避免常見陷阱，團隊可確保其架構圖始終是開發的可靠藍圖。
專注於關係的語義意義。零件是否能獨立於整體而存在？若是，則使用聚合。這個簡單的問題能引導整個系統設計的結構完整性。在開發週期中持續審查這些圖表，可確保理論模型與實際實現的軟體保持一致。
