1、為什麼需要類圖？類圖的作用

我們做專案的需求分析，最開始往往得到的是一堆文字，請看下面這堆文字：

本專案是在一期的基礎上增加對電纜、通訊工程的管理和施工詳細資料的記錄和統計，使整個系統更好的管理各工程專案從中標開始到竣工驗收的全部過程和資料和分析施工過程的資料。

本系統將一條或一個標段的架空電力線路工程定為一個單位工程，即系統中的一個工程專案；每個單位工程分為若干個分部工程；每個分部工程分為若干個分項工程；每個分項工程中又分為若干相同單元工程。

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

專案初期，我們往往對業務一無所知，我們最急迫需要解決的問題就是理清楚這些業務概念以及它們的關係，如果能用好類圖，你將能深入地剖析系統業務。

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

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

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

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

使用工具：Visio或者processon線上作圖

　在類圖中一共包含了以下幾種模型元素，分別是：類（Class）、介面（Interface）以及類之間的關係。

2.1 類（Class)

　　在面向物件（OO) 程式設計中，類是對現實世界中一組具有相同特徵的物體的抽象。

2.2 介面（Interface）

　　介面是一種特殊的類，具有類的結構但不可被例項化，只可以被實現（繼承）。在UML中，介面使用一個帶有名稱的小圓圈來進行表示。

2.3、類圖中關係（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類圖中的規範問題，比如不同關係需要不同的箭頭，可見性符號等。

3、類圖的分類

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

領域UML類圖vs實現UML類圖

上文提到，在軟體分析與設計過程中，會由兩種角色產生兩套UML類圖。一般情況下，分析師繪製的UML類圖叫做“領域UML類圖”，而設計師繪製的UML類圖叫做“實現UML類圖”。這裡要宣告，這兩個名詞是我的習慣性叫法，並不是大家都認同的通用叫法。下面，我對這兩種UML類圖給出我的定義：

領域UML類圖：產生於分析階段，由系統分析師繪製，主要作用是描述業務實體的靜態結構，包括業務實體、各個業務實體所具有的業務屬性及業務操作、業務實體之間具有的關係。

雖然這個UML類圖也叫“UML類圖”，但是說實話，它和程式設計中的“類”實在是沒啥關係，因為最後的系統中可能根本沒有類和它們對應，而且很多最後系統中的類如控制類和介面類這套UML類圖中也沒有。也就是說這套圖和具體技術無關，也不是畫給程式設計師看的，它只是表達業務領域中的一個靜態結構。下面給個例子：

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

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

實現UML類圖：

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

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

總結

1.軟體分析與設計是編碼前的兩個階段，其中分析僅與業務有關，而與技術無關。設計以分析為基礎，主要與具體技術有關。

2.分析階段由分析師繪製領域UML類圖，設計階段由設計師繪製實現UML類圖。

3.領域UML類圖表示系統的靜態領域結構，其中的類不與最終程式中的類對應；設計UML類圖表示系統的技術架構，是程式設計師的編碼依據，其中的類與系統中的類對應。

4.領域UML類圖中類的屬性與操作僅關注與業務相關的部分，實現UML類圖中的屬性與操作要包括最終需要實現的全部方法與操作。