類別圖（Class Diagram）是軟體工程中用來描述系統的靜態結構的一種圖形化表示方法。它是統一建模語言（UML, Unified Modeling Language）的一部分，主要用於展示系統中的類別及其之間的關係。
類別圖內的元素
類別（Class）：表示系統中的實體或對象。每個類別通常包含屬性（Attributes）和方法（Methods）
屬性（Attributes）：描述類別的特性或數據成員
方法（Methods）：描述類別的行為或操作
關係（Relationships）：描述類別之間的聯繫。常見的關係包括:
繼承（Inheritance）：一個類別從另一個類別繼承屬性和方法
聯合（Association）：表示類別之間的靜態關係
聚合（Aggregation）：一種特殊的聯合，表示整體和部分之間的關係
組合（Composition）：一種強聚合，表示整體和部分之間的強依賴關係
依賴（Dependency）：一個類別依賴於另一個類別的變化
使用類別圖的注意事項
保持圖表的簡潔和清晰： 避免在一個圖中包含過多的類別和關係。
使用一致的命名規範： 讓類別、屬性和方法的名稱清晰易懂。
根據需求選擇合適的關係： 正確使用各種關係可以準確地表達類別之間的互動。
不斷迭代和更新： 類別圖應該隨著系統的開發而不斷更新。
類別圖實踐
從「人事時地物數」中尋找物件：
在分析系統需求時，可以從以下幾個方面著手，尋找潛在的類別：
人 (Person)： 參與系統互動的角色，例如：顧客、員工、管理員。
事 (Event)： 系統中發生的事件或交易，例如：訂單、預約、付款。
時 (Time)： 與時間相關的概念，例如：日期、時間、時段。
地 (Place)： 與地點相關的概念，例如：地址、位置、地點。
物 (Thing)： 系統中處理的實體物件，例如：商品、書籍、房間。
數 (Number/Concept)： 抽象的概念或數值，例如：價格、數量、評分。
可以套用設計模式，但別因此受限：
設計模式是解決常見設計問題的經驗總結，套用適當的設計模式可以提高設計的品質。
然而，不應該為了套用模式而硬套，而是應該根據實際情況靈活運用
過度或不恰當地使用設計模式反而會使設計變得複雜。
無須太早「分派責任」給物件：
在繪製類別圖的初期，重點應該放在識別類別、建立類別之間的關係。定義物件的操作 (方法) 可以延後到繪製循序圖或活動圖時再進行，這樣可以更清楚地了解物件之間的互動，並更合理地分配責任。
善用使用案例敘述和循序圖來定義並檢驗物件的操作：
使用案例描述了使用者如何與系統互動，而循序圖則展示了物件之間的訊息傳遞。透過分析使用案例和循序圖，可以更有效地定義物件需要提供的操作，並檢驗這些操作是否合理、完整。
分析階段採用預設的能見度：
在分析階段，可以先使用預設的能見度：屬性預設為私有 (private)，操作預設為公開 (public)。在設計階段再仔細考慮每個屬性和操作的能見度，以確保系統的安全性。
避免過度使用繼承：
繼承是強大的工具，但過度使用會導致類別層次過於複雜，難以理解和維護。應該謹慎使用繼承，並優先考慮使用介面或組合來達到程式碼重用的目的。
保持類別圖的簡潔和清晰：
類別圖的目的是為了溝通和理解，因此應該盡量保持簡潔和清晰。避免在一個圖中包含過多的類別和關係，可以將複雜的系統分解成多個較小的圖表。
避免循環依賴：
循環依賴是指兩個或多個類別之間互相依賴，這會導致系統的耦合性過高，難以修改和維護。應該盡量避免循環依賴的產生。