統一建模語言（UML）是物件導向軟體設計的骨幹。在各種可用的圖表類型中，類圖最為關鍵，能有效呈現系統的靜態結構。理解此圖表中每一項元件，對於開發人員、架構師與分析師而言至關重要，有助於清楚傳達複雜的系統設計。本指南深入探討 UML 類圖的結構，確保您能精準地閱讀與建立此類圖表。
🔍 類圖的目的
類圖是結構圖，透過展示系統的類別、屬性、操作以及物件之間的關係，來描述系統的結構。與捕捉時間動態行為的序列圖不同，類圖保持靜態。它們如同建築的設計圖，作為程式碼建構的基礎藍圖。
主要目標包括：
- 記錄物件導向系統的靜態視圖。
- 為程式碼產生與逆向工程提供基礎。
- 促進技術與非技術利益相關者之間的溝通。
- 在實作開始前，識別潛在的設計缺陷。
🏗️ 類別方塊：核心結構
類圖的基本構成單元是類別方塊。它是一個被分割成區塊的矩形。標準的類別方塊通常包含三個部分：類別名稱、屬性與操作。雖然並非所有部分都是必要項目，但完整的圖表通常會顯示全部三個部分，以提供完整的上下文。
1. 名稱區塊
方塊的頂部區塊存放類別的名稱。此名稱應為名詞或名詞片語，能清楚識別該實體。命名慣例對於可讀性與可維護性至關重要。
- 大小寫： 類別名稱通常以大寫字母開頭（例如，客戶, 發票).
- 唯一性： 名稱應在命名空間內具有唯一性，以避免混淆。
- 單數與複數： 類別應使用單數名詞（例如，產品，而非產品們）以代表類型，而非集合。
2. 屬性區塊
中間區塊列出屬性。屬性代表類別實例所持有的狀態或資料。它們定義了類別自身所了解的資訊內容。
在記錄屬性時，請考慮以下要素：
- 名稱： 通常為小寫，通常以可見性符號作為前綴。
- 類型： 資料類型（例如，字串, 整數, 日期).
- 預設值： 如果屬性具有標準的起始值，可以顯示（例如，status = 「active」).
範例： - name: 字串 表示名為 name 的私有字串屬性。
3. 操作區段
底部區段列出操作。操作代表類別可用的行為或方法。它們定義了類別可以執行.
操作的關鍵細節包括：
- 可見性： 表示存取層級的符號（+、-、#、~）。
- 名稱： 通常為小寫，以動詞開頭（例如，calculateTotal).
- 參數： 執行操作所需的參數。
- 返回類型： 操作完成後返回的資料類型。
範例： + calculateTotal(): Integer 表示一個傳回整數的公開操作。
🔗 理解關係
關係定義了類別之間如何互動。它們是連接類別方框的線條。誤解這些關係可能會導致最終程式碼庫出現重大架構錯誤。以下是標準 UML 關係的詳細說明。
關係對比表
| 關係類型 | 對稱性 | 語義意義 | 符號表示 |
|---|---|---|---|
| 關聯 | 可選 | 實例之間的結構性連結 | 實線 |
| 聚合 | 弱 | 整體-部分關係（部分可獨立於整體存在） | 帶空菱形的實線 |
| 組合 | 強 | 整體-部分關係（部分無法在沒有整體的情況下存在） | 帶實心菱形的實線 |
| 一般化 | 是 | 繼承關係（是一種） | 帶空三角形的實線 |
| 依賴 | 否 | 使用關係（一個類使用另一個類） | 虛線搭配開放箭頭 |
| 實現 | 否 | 介面的實作 | 虛線搭配空心三角形 |
關聯
關聯代表物件之間的結構性連結。它表示一個類別的物件與另一個類別的物件相連。這是最基本的關係。
- 它可以命名以描述連結的性質。
- 它可以是雙向或單向的。
- 它不表示擁有權或生命週期管理。
聚合
聚合是關聯的一種特殊形式。它代表「擁有」關係，其中部分可以獨立於整體而存在。
- 範例： 一所大學擁有系所。如果大學關閉，系所資料可能仍存在於舊系統中，或系所可被轉移。
- 以線段的「整體」端點處的空心菱形來表示。
組合
組合是聚合的一種更強形式。它暗示生命週期上的依賴關係。如果整體被銷毀，其部分也會隨之被銷毀。
- 範例： 一棟房子擁有房間。如果房子被拆除，房間也就不復存在。
- 以線段的「整體」端點處的實心菱形來表示。
一般化（繼承）
一般化代表「是」關係。它允許一個類別從另一個類別繼承屬性和操作。
- 子類別是父類別的特殊化版本。
- 它促進程式碼的重用。
- 以實線搭配指向父類別的空心三角形來表示。
依賴
依賴表示一個類別使用另一個類別。這通常是一種暫時性的關係，例如將物件作為參數傳遞給方法。
- 供應者類別的變更可能影響依賴類別。
- 以虛線搭配開放箭頭來表示。
實現（介面）
實現表示一個類別實作了介面。該類別承諾提供介面中定義的行為。
- 以虛線搭配空心三角形表示。
- 常被用來實現多型性，並將實作與介面分離。
🔢 多重性與基數
多重性定義了一個類別的實例與另一個類別的實例之間的關聯數量。這對於資料庫設計與邏輯驗證至關重要。多重性通常放置在關聯線的兩端附近。
常見的多重性符號
- 1:恰好一個實例。
- 0..1:零個或一個實例（可選）。
- 1..*:一個或多個實例。
- 0..*:零個或多個實例（多個）。
- *:0..* 的簡寫。
- 1..5:特定範圍的實例。
情境：考慮一個學生與一個課程。一名學生必須註冊至少一門課程（1..*），但一門課程可以沒有學生（0..*）。這表示為在學生端的課程旁放置「1..*」，而在課程端的學生旁放置「0..*」。
🎨 可見性修飾符
可見性決定類別的哪些部分可從其他類別存取。這是封裝的基本概念。符號會放在屬性或運算名稱的開頭。
- 公開 (+)：可從任何其他類別存取。這是存取層級中最開放的。
- 私有 (-)： 僅可在類別內部存取。這可保護內部資料。
- 受保護的 (#)： 可在類別及其子類別中存取。常見於繼承層次結構中。
- 套件 (~)： 僅可在同一套件或命名空間內存取。
選擇正確的可見性對於維持物件狀態的完整性至關重要。過度使用公開存取會導致緊密耦合與脆弱的程式碼。
📝 標記與約束
除了標準元素之外，UML 可透過標記與約束進行擴展。這些擴展在不改變視覺結構的情況下增加語義意義。
標記
標記是一種建立新類型元素的機制。它以角引號包圍（例如，<<標記>>）。
- 範例： <<介面>> 表示定義介面的類別。
- 範例： <<實體>> 可能表示資料庫表格的對應。
- 範例： <<抽象>> 表示無法直接實例化的類別。
約束
約束是系統必須滿足的條件。它們以大括號包圍（例如，{約束}）。
- 範例： 屬性上的 {唯一} 可確保無重複。
- 範例： 屬性上的 {唯讀} 可確保其無法被修改。
- 範例： 操作上的 {pre: age >= 18} 可確保邏輯成立。
🛠️ 設計的最佳實務
建立類別圖不僅是畫方框與線條；更在於正確地建模邏輯。遵循最佳實務可確保圖表長期保持實用性。
命名慣例
- 使用清晰且具描述性的名稱。
- 避免使用縮寫，除非是業界標準。
- 確保整個圖表的一致性。
簡潔性
- 避免在圖表中顯示每個屬性。專注於重要的屬性。
- 不要用無關緊要的操作來混雜圖表。
- 明智地使用繼承。過深的層次結構可能變得難以管理。
一致性
- 確保關係的一致性。如果A與B相關，方向應明確。
- throughout 保持可見性符號的風格一致。
- 保持多重性與業務規則一致。
⚠️ 應避免的常見陷阱
即使經驗豐富的建模者也可能犯錯。了解常見錯誤有助於產生更清晰的圖表。
- 循環依賴：避免出現類A依賴類B，而類B又依賴類A的循環。這在許多語言中會導致編譯問題。
- 混淆聚合與組合：這兩者經常被混淆。請記住：組合表示擁有權和生命週期。
- 過度設計：不要在一個圖表中建模系統的每個細節。將大型系統拆分為子系統。
- 忽略可見性：僅顯示私有屬性會隱藏重要的資料結構，而僅顯示公開屬性則可能暴露安全風險。
- 誤用泛化：並非每一個「有-」關係都是繼承。繼承嚴格來說是「是-」關係。
📈 在開發生命週期中的應用
類圖不是靜態文件；它們會隨著專案的發展而演變。
分析階段
在分析階段，類圖專注於業務概念。它們不需要技術上完美，但應準確反映領域邏輯。
設計階段
在設計階段，會加入技術細節。可見性、資料類型和特定關係會被定義。這是開發人員用來撰寫程式碼的版本。
維護階段
隨著變更的發生，圖表必須更新。過時的圖表比沒有圖表更糟糕，因為它會誤導開發人員並造成技術負債。
🧩 高階考量
對於複雜系統，標準類圖可能需要擴展。
- 介面： 使用介面可以實現鬆散耦合。類別實作介面，使得實作可以變更而不影響客戶端。
- 抽象類別： 這些定義了共同的介面，但無法實例化。它們對於群組共同行為非常有用。
- 關聯類別： 當關聯本身具有屬性或操作時，可以將其建模為關聯類別。這在多對多關係中很常見。
📌 主要重點摘要
掌握UML類圖的各個元件，需要注重細節並對物件導向原則有扎實的理解。從基本的類別方框到複雜的關係如組合與泛化，每個元素都在定義系統架構中扮演特定角色。
- 類別方框： 透過名稱、屬性和操作來定義結構。
- 關係： 透過關聯、聚合、組合、繼承、依賴和實作來定義互動。
- 多重性： 定義關係的基數和約束條件。
- 可見性： 控制對資料和行為的存取。
- 最佳實務： 重視清晰性、一致性和準確性。
透過正確運用這些元件，團隊可以建立穩健、可維護且可擴展的軟體系統。圖表作為一種共通語言，彌補了抽象需求與具體實作之間的差距。
