|
基本概念
類圖（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列出了一些多重值及它們含義的例子。
多重值和它們的表示
| 可能的多重值描述 |
| 表示 |
含義 |
| 0..1 |
0個或1個 |
| 1 |
只能1個 |
| 0..* |
0個或多個 |
| * |
0個或多個 |
| 1..* |
1個或我個 |
| 3 |
只能3個 |
| 0..5 |
0到5個 |
| 5..15 |
5到15個 |
|
單向關聯
在一個單向關聯中，兩個類是相關的，但是隻有一個類知道這種聯繫的存在。下圖 顯示單向關聯的透支財務報告的一個實例。
![]()
圖: 單向關聯一個實例：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 中所見到的，一條帶有閉合單向箭頭的實線表示繼承。
|
