詳解UML圖之類圖

產品經理的必備技能之一是畫UML圖，本文就告訴你怎麼畫標準的類圖吧。本文結合網絡資料和我的心得所成，不當之處，請多指教。

一、爲何須要類圖？類圖的做用

咱們作項目的需求分析，最開始每每獲得的是一堆文字，請看下面這堆文字：

本項目是在一期的基礎上增長對電纜、通信工程的管理和施工詳細數據的記錄和統計，使整個系統更好的管理各工程項目從中標開始到竣工驗收的所有過程和資料和分析施工過程的數據。 本系統將一條或一個標段的架空電力線路工程定爲一個單位工程，即系統中的一個工程項目；每一個單位工程分爲若干個分部工程；每一個分部工程分爲若干個分項工程；每一個分項工程中又分爲若干相同單元工程。

這是關於系統狀況的一段概述，裏面充斥了大量的術語、概念，若是你不是專業人士，恐怕難以讀懂上述文字。

項目初期，咱們每每對業務一無所知，咱們最急迫須要解決的問題就是理清楚這些業務概念以及它們的關係，若是能用好類圖，你將能深刻地剖析系統業務。

用下面這個UML圖來描述是否清晰了許多呢？

在上圖中，各個類之間是關聯關係，也就是擁有的關係。

類圖(Class diagram)主要用於描述系統的結構化設計。類圖也是最經常使用的UML圖，用類圖能夠顯示出類、接口以及它們之間的靜態結構和關係。

二、怎麼畫類圖？用什麼工具？

使用工具：Visio或者processon在線做圖  在類圖中一共包含了如下幾種模型元素，分別是：類（Class）、接口（Interface）以及類之間的關係。 2.1 類（Class)   在面向對象（OO) 編程中，類是對現實世界中一組具備相同特徵的物體的抽象。

2.2 接口（Interface）   接口是一種特殊的類，具備類的結構但不可被實例化，只能夠被實現（繼承）。在UML中，接口使用一個帶有名稱的小圓圈來進行表示。

2.三、類圖中關係（relation） 在UML類圖中，常見的有如下幾種關係: 泛化（Generalization）, 實現（Realization），關聯（Association)，聚合（Aggregation），組合(Composition)，依賴(Dependency) 1. 泛化（Generalization） 【泛化關係】：是一種繼承關係，表示通常與特殊的關係，它指定了子類如何特化父類的全部特徵和行爲。 例如：老虎是動物的一種，即有老虎的特性也有動物的共性。 【箭頭指向】：帶三角箭頭的實線，箭頭指向父類

2. 實現（Realization） 【實現關係】：是一種類與接口的關係，表示類是接口全部特徵和行爲的實現. 【箭頭指向】：帶三角箭頭的虛線，箭頭指向接口

3. 關聯（Association) 【關聯關係】：是一種擁有的關係，它使一個類知道另外一個類的屬性和方法；如：老師與學生， 丈夫與妻子關聯能夠是雙向的，也能夠是單向的。 雙向的關聯能夠有兩個箭頭或者沒有箭頭，單向的關聯有一個箭頭。 【代碼體現】：成員變量 【箭頭及指向】：帶普通箭頭的實心線，指向被擁有者

上圖中，老師與學生是雙向關聯，老師有多名學生，學生也可能有多名老師。 但學生與某課程間的關係爲單向關聯，一名學生可能要上多門課程，課程是個抽象的東西他不擁有學生。 下圖爲自身關聯：

4. 聚合（Aggregation） 【聚合關係】：是總體與部分的關係，且部分能夠離開總體而單獨存在。 如車和輪胎是總體和部分的關係，輪胎離開車仍然能夠存在。 聚合關係是關聯關係的一種，是強的關聯關係；關聯和聚合在語法上沒法區分，必須考察具體的邏輯關係。 【代碼體現】：成員變量 【箭頭及指向】：帶空心菱形的實心線，菱形指向總體

5. 組合(Composition)
    【組合關係】：是總體與部分的關係，但部分不能離開總體而單獨存在。
    如公司和部門是總體和部分的關係，沒有公司就不存在部門。
   組合關係是關聯關係的一種，是比聚合關係還要強的關係，
    它要求普通的聚合關係中表明總體的對象負責表明部分的對象的生命週期。
    【代碼體現】：成員變量
    【箭頭及指向】：帶實心菱形的實線，菱形指向總體
複製代碼

6. 依賴(Dependency)
    【依賴關係】：是一種使用的關係，即一個類的實現須要另外一個類的協助，
      因此要儘可能不使用雙向的互相依賴.
    【代碼表現】：局部變量、方法的參數或者對靜態方法的調用
    【箭頭及指向】：帶箭頭的虛線，指向被使用者
複製代碼

各類關係的強弱順序： 泛化 = 實現 > 組合 > 聚合 > 關聯 > 依賴 下面這張UML圖，比較形象地展現了各類類圖關係：

類圖繪製的要點

1類的操做是針對類自身的操做，而不是它去操做人家。好比書這個類有上架下架的操做，是書本身被上架下架，不能由於上架下架是管理員的動做而把它放在管理員的操做裏。

2兩個相關聯的類，須要在關聯的類中加上被關聯類的ID，而且箭頭指向被關聯類。能夠理解爲數據表中的外鍵。好比借書和書，借書須要用到書的信息，所以借書類需包含書的ID，箭頭指向書。

3因爲業務複雜性，一個顯示中的實體可能會被分爲多個類，這是很正常的，類不是越少越好。類的設計取決於怎樣讓後臺程序的操做更加簡單。好比單看邏輯，借書類能夠不存在，它的信息能夠放在書這個類裏。然而借還書和書的上架下架徹底不是一回事，借書類對借書的操做更加方便，不須要去重複改動書這個類中的內容。此外，若是書和借書是1對多的關係，那就必須分爲兩個類。 4類圖中的規範問題，好比不一樣關係須要不一樣的箭頭，可見性符號等。

三、類圖的分類

軟件在分析與設計兩個階段各自會繪製一套UML類圖，並且是由分析師和設計師兩個不一樣的角色繪製的。那麼這兩套UML類圖有什麼異同呢？下面將解釋這個問題。

領域UML類圖vs實現UML類圖

上文提到，在軟件分析與設計過程當中，會由兩種角色產生兩套UML類圖。通常狀況下，分析師繪製的UML類圖叫作「領域UML類圖」，而設計師繪製的UML類圖叫作「實現UML類圖」。這裏要聲明，這兩個名詞是個人習慣性叫法，並非你們都認同的通用叫法。下面，我對這兩種UML類圖給出個人定義：
領域UML類圖：產生於分析階段，由系統分析師繪製，主要做用是描述業務實體的靜態結構，包括業務實體、各個業務實體所具備的業務屬性及業務操做、業務實體之間具備的關係。

雖然這個UML類圖也叫「UML類圖」，可是說實話，它和編程中的「類」實在是沒啥關係，由於最後的系統中可能根本沒有類和它們對應，並且不少最後系統中的類如控制類和界面類這套UML類圖中也沒有。也就是說這套圖和具體技術無關，也不是畫給程序員看的，它只是表達業務領域中的一個靜態結構。下面給個例子：

這是一個選課系統的簡單領域分析UML類圖。能夠看到，主要實體有教師、學生、課程和開課安排。每一個實體標註了其在業務上具備的屬性和方法。並且圖中還標明瞭實體間的關係。

可是，最終系統中可能沒有一個學生類和其對應。由於最終系統中有哪些類、各個類有什麼屬性、方法依賴於所選擇的平臺和架構。例如，若是使用了Struts2，則會存在不少Action類，而使用了ASP.NETMVC，則會有不少Controller類等，因此，領域UML類圖只於業務有關，和具體實現及編碼等計算機技術無關。

實現UML類圖：產生於設計階段，由系統設計師繪製，其做用是描述系統的架構結構、指導程序員編碼。它包括系統中全部有必要指明的實體類、控制類、界面類及與具體平臺有關的全部技術性信息。

就像上面的領域UML類圖，若是你把它交給程序員編碼，我想程序員會瘋掉，由於它沒有提供任何編碼的依據。假如咱們使用的是.NET平臺分層架構，並使用ASP.NETMVC，則設計師應該在實現UML類圖中繪製出全部的實體類、數據訪問類、業務邏輯類和界面類，界面類又分爲視圖類、控制器類等等，還要表示出IoC和Aop等信息，並明確指出各個類的屬性、方法，不能有遺漏，由於最終程序員實現程序的依據就是實現UML類圖。

總結

最後，咱們總結一下要點： 1.軟件分析與設計是編碼前的兩個階段，其中分析僅與業務有關，而與技術無關。設計以分析爲基礎，主要與具體技術有關。 2.分析階段由分析師繪製領域UML類圖，設計階段由設計師繪製實現UML類圖。 3.領域UML類圖表示系統的靜態領域結構，其中的類不與最終程序中的類對應；設計UML類圖表示系統的技術架構，是程序員的編碼依據，其中的類與系統中的類對應。 4.領域UML類圖中類的屬性與操做僅關注與業務相關的部分，實現UML類圖中的屬性與操做要包括最終須要實現的所有方法與操做。