基本概念

類圖（Class Diagram）: 類圖是面向物件系統建模中最常用和最重要的圖，是定義其它圖的基礎。類圖主要是用來顯示系統中的類、介面以及它們之間的靜態結構和關係的一種靜態模型。

類圖的3個基本元件：類名、屬性、方法。

泛化(generalization)：表示is-a的關係，是物件之間耦合度最大的一種關係，子類繼承父類的所有細節。直接使用語言中的繼承表達。在類圖中使用帶三角箭頭的實線表示，箭頭從子類指向父類。

實現（Realization）:在類圖中就是介面和實現的關係。這個沒什麼好講的。在類圖中使用帶三角箭頭的虛線表示，箭頭從實現類指向介面。

依賴(Dependency)：物件之間最弱的一種關聯方式，是臨時性的關聯。程式碼中一般指由區域性變數、函式引數、返回值建立的對於其他物件的呼叫關係。一個類呼叫被依賴類中的某些方法而得以完成這個類的一些職責。在類圖使用帶箭頭的虛線表示，箭頭從使用類指向被依賴的類。

關聯(Association) : 物件之間一種引用關係，比如客戶類與訂單類之間的關係。這種關係通常使用類的屬性表達。關聯又分為一般關聯、聚合關聯與組合關聯。後兩種在後面分析。在類圖使用帶箭頭的實線表示，箭頭從使用類指向被關聯的類。可以是單向和雙向。

聚合(Aggregation) : 表示has-a的關係，是一種不穩定的包含關係。較強於一般關聯,有整體與區域性的關係,並且沒有了整體,區域性也可單獨存在。如公司和員工的關係，公司包含員工，但如果公司倒閉，員工依然可以換公司。在類圖使用空心的菱形表示，菱形從區域性指向整體。

組合(Composition) : 表示contains-a的關係，是一種強烈的包含關係。組合類負責被組合類的生命週期。是一種更強的聚合關係。部分不能脫離整體存在。如公司和部門的關係，沒有了公司，部門也不能存在了；調查問卷中問題和選項的關係；訂單和訂單選項的關係。在類圖使用實心的菱形表示，菱形從區域性指向整體。

多重性(Multiplicity) : 通常在關聯、聚合、組合中使用。就是代表有多少個關聯物件存在。使用數字..星號（數字）表示。如下圖，一個割接通知可以關聯0個到N個故障單。

聚合和組合的區別

這兩個比較難理解，重點說一下。聚合和組合的區別在於：聚合關係是“has-a”關係，組合關係是“contains-a”關係；聚合關係表示整體與部分的關係比較弱，而組合比較強；聚合關係中代表部分事物的物件與代表聚合事物的物件的生存期無關，一旦刪除了聚合物件不一定就刪除了代表部分事物的物件。組合中一旦刪除了組合物件，同時也就刪除了代表部分事物的物件。

例項分析

聯通客戶響應OSS。系統有故障單、業務開通、資源核查、割接、業務重保、網路品質效能等功能模組。現在我們抽出部分需求做為例子講解。

大家可以參照著類圖，好好理解。

1． 通知分為一般通知、割接通知、重保通知。這個是繼承關係。

2． NoticeService和實現類NoticeServiceImpl是實現關係。

3． NoticeServiceImpl通過save方法的引數引用Notice,是依賴關係。同時呼叫了BaseDao完成功能，也是依賴關係。

4． 割接通知和故障單之間通過中間類(通知電路)關聯，是一般關聯。

5． 重保通知和預案庫間是聚合關係。因為預案庫可以事先錄入，和重保通知沒有必然聯絡，可以獨立存在。在系統中是手工從列表中選擇。刪除重保通知，不影響預案。

6． 割接通知和需求單之間是聚合關係。同理，需求單可以獨立於割接通知存在。也就是說刪除割接通知，不影響需求單。

7． 通知和回覆是組合關係。因為回覆不能獨立於通知存在。也就是說刪除通知，該條通知對應的回覆也要級聯刪除。

經過以上的分析，相信大家對類的關係已經有比較好的理解了。大家有什麼其它想法或好的見解，歡迎拍磚。

PS：還是那句話：以上類圖用Enterprise Architect 7.5所畫，在此推薦一下EA,非常不錯。可以替代Visio和Rose了。Visio功能不夠強大，Rose太重。唯有EA比較合適。

補：關聯關係和介面

（1）關聯
當系統建模時，特定的物件間將會彼此關聯，而且這些關聯本身需要被清晰地建模。有五種關聯。在這一部分中，我將會討論它們中的兩個 -- 雙向的關聯和單向的關聯。請注意，關於何時該使用每種型別關聯的詳細討論，不屬於本文的範圍。相反的，我將會把重點集中在每種關聯的用途，並說明如何在類圖上畫出關聯。

雙向（標準）的關聯
關聯是兩個類間的聯接。關聯總是被假定是雙向的；這意味著，兩個類彼此知道它們間的聯絡，除非你限定一些其它型別的關聯。回顧一下Flight 的例子，下圖顯示了在Flight類和Plane類之間的一個標準型別的關聯。

圖 ：在一個Flight類和Plane類之間的雙向關聯的例項

一個雙向關聯用兩個類間的實線表示。線上的任一端，你放置一個角色名和多重值。上圖顯示Flight與一個特定的Plane相關聯，而且Flight類知道這個關聯。因為角色名以Plane類表示，所以Plane承擔關聯中的“assignedPlane”角色。緊接於Plane類後面的多重值描述0...1表示，當一個Flight實體存在時，可以有一個或沒有Plane與之關聯（也就是，Plane可能還沒有被分配）。上圖  也顯示Plane知道它與Flight類的關聯。在這個關聯中，Flight承擔“assignedFlights”角色；圖 6 的圖告訴我們，Plane實體可以不與flight關聯（例如，它是一架全新的飛機）或與沒有上限的flight（例如，一架已經服役5年的飛機）關聯。

由於對那些在關聯尾部可能出現的多重值描述感到疑惑，下面的表3列出了一些多重值及它們含義的例子。

 多重值和它們的表示

單向關聯

在一個單向關聯中，兩個類是相關的，但是隻有一個類知道這種聯絡的存在。下圖 顯示單向關聯的透支財務報告的一個例項。

圖: 單向關聯一個例項：OverdrawnAccountsReport 類 BankAccount 類，而 BankAccount 類則對關聯一無所知。

一個單向的關聯，表示為一條帶有指向已知類的開放箭頭（不關閉的箭頭或三角形，用於標誌繼承）的實線。如同標準關聯，單向關聯包括一個角色名和一個多重值描述，但是與標準的雙向關聯不同的時，單向關聯只包含已知類的角色名和多重值描述。在圖 7 中的例子中，OverdrawnAccountsReport 知道 BankAccount 類，而且知道 BankAccount 類扮演“overdrawnAccounts”的角色。然而，和標準關聯不同，BankAccount 類並不知道它與 OverdrawnAccountsReport 相關聯。

（2）介面
首先考慮分類器。事實上，分類器是一個更為一般的概念，它包括資料型別和介面。關於何時、以及如何高效地在系統結構圖中使用資料型別和介面的完整討論，不在本文的討論範圍之內。既然這樣，我為什麼要在這裡提及資料型別和介面呢？你可能想在結構圖上模仿這些分類器型別，在這個時候，使用正確的記號來表示，或者至少知道這些分類器型別是重要的。不正確地繪製這些分類器，很有可能將使你的結構圖讀者感到混亂，以後的系統將不能適應需求。

一個類和一個介面不同：一個類可以有它形態的真實例項，然而一個介面必須至少有一個類來實現它。在 UML 2 中，一個介面被認為是類建模元素的特殊化。因此，介面就象類那樣繪製，但是長方形的頂部區域也有文字“interface”，如下圖所示

圖 ：Professor類和Student類實現Person介面的類圖例項

在圖 10 中顯示的圖中，Professor和Student類都實現了Person的介面，但並不從它繼承。我們知道這一點是由於下面兩個原因：1) Person物件作為介面被定義 -- 它在物件的名字區域中有“interface”文字，而且我們看到由於Professor和Student物件根據畫類物件的規則（在它們的名字區域中沒有額外的分類器文字）標示，所以它們是 類物件。 2) 我們知道繼承在這裡沒有被顯示，因為與帶箭頭的線是點線而不是實線。如圖 10 所示，一條帶有閉合的單向箭頭的點 線意味著實現（或實施）；正如我們在圖 4 中所見到的，一條帶有閉合單向箭頭的實線表示繼承。