1、首先來認識下類圖？以及類圖的作用
類圖(Class diagram)由許多（靜態）說明性的模型元素（例如類、包和它們之間的關系，這些元素和它們的內容互相連接）組成。類圖可以組織在（並且屬於）包中，僅顯示特定包中的相關內容。
類圖(Class diagram)是最常用的UML圖，顯示出類、接口以及它們之間的靜態結構和關系；它用於描述系統的結構化設計。
類圖(Class diagram)最基本的元素是類或者接口。
為系統詞匯建模型
為系統的詞匯建模實際上是從詞匯表中發現類，發現它的責任。
模型化簡單的協作
協作是指一些類、接口和其他的元素一起工作提供一些合作的行為，這些行為不是簡單地將元素相加能得到的。例如：當你為一個分布式的系統中的事務處理過程建模型時，你不可能只通過一個類來明白事務是怎樣進行的，事實上這個過程的執行涉及到一系列的類的協同工作。使用類圖來可視化這些類和他們的關系。
模型化一個邏輯數據庫模式
想象模式是概念上設計數據庫的藍圖。在很多領域，你將想保存持久性數據到關系數據庫或面向對象的數據庫。你可以用類圖為這些數據庫模式建立模型。
2、怎么畫類圖？用什么工具？
使用工具：Visio或者processon在線作圖
在類圖中一共包含了以下幾種模型元素，分別是：類（Class）、接口（Interface）以及類之間的關系。
2.1 類（Class)
在面向對象（OO) 編程中，類是對現實世界中一組具有相同特征的物體的抽象。
一般包含3個組成部分。第一個是類名；第二個是屬性（attributes）；第三個是該類提供的方法（ 類的性質可以放在第四部分；如果類中含有內部類，則會出現第五個組成部分）。類名部分是不能省略的，其他組成部分可以省略。
類名書寫規范：正體字說明類是可被實例化的，斜體字說明類為抽象類。
屬性和方法書寫規范：修飾符 [描述信息] 屬性、方法名稱 [參數] [：返回類型|類型]
屬性和方法之前可附加的可見性修飾符：
加號（+）表示public；減號（-）表示private；井號(#)表示protected；省略這些修飾符表示具有package（包）級別的可見性。
如果屬性或方法具有下划線，則說明它是靜態的。
描述信息使用 << 開頭，使用 >> 結尾。
類的性質是由一個屬性、一個賦值方法和一個取值方法組成。書寫方式和方法類似。
2.2 接口（Interface）
接口是一種特殊的類，具有類的結構但不可被實例化，只可以被實現（繼承）。在UML中，接口使用一個帶有名稱的小圓圈來進行表示。
2.3、類圖中關系（relation）
在UML類圖中，常見的有以下幾種關系: 泛化（Generalization）, 實現（Realization），關聯（Association)，聚合（Aggregation），組合(Composition)，依賴(Dependency)
關系 |
形狀 |
泛化（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類圖和實現UML類圖
領域UML類圖：產生於分析階段，由系統分析師繪制，主要作用是描述業務實體的靜態結構，包括業務實體、各個業務實體所具有的業務屬性及業務操作、業務實體之間具有的關系。
雖然這個UML類圖也叫“UML類圖”，但是說實話，它和編程中的“類”實在是沒啥關系，因為最后的系統中可能根本沒有類和它們對應，而且很多最后系統中的類如控制類和界面類這套UML類圖中也沒有。也就是說這套圖和具體技術無關，也不是畫給程序員看的，它只是表達業務領域中的一個靜態結構。下面給個例子：
這是一個選課系統的簡單領域分析UML類圖。可以看到，主要實體有教師、學生、課程和開課安排。每個實體標注了其在業務上具有的屬性和方法。而且圖中還表明了實體間的關系。
實現UML類圖：產生於設計階段，由系統設計師繪制，其作用是描述系統的架構結構、指導程序員編碼。它包括系統中所有有必要指明的實體類、控制類、界面類及與具體平台有關的所有技術性信息。
總結
最后，我們總結一下要點：
1.軟件分析與設計是編碼前的兩個階段，其中分析僅與業務有關，而與技術無關。設計以分析為基礎，主要與具體技術有關。
2.分析階段由分析師繪制領域UML類圖，設計階段由設計師繪制實現UML類圖。
3.領域UML類圖表示系統的靜態領域結構，其中的類不與最終程序中的類對應；設計UML類圖表示系統的技術架構，是程序員的編碼依據，其中的類與系統中的類對應。
4.領域UML類圖中類的屬性與操作僅關注與業務相關的部分，實現UML類圖中的屬性與操作要包括最終需要實現的全部方法與操作。