1、首先來認識下類圖？以及類圖的做用程序員
類圖(Class diagram)由許多（靜態）說明性的模型元素（例如類、包和它們之間的關係，這些元素和它們的內容互相鏈接）組成。類圖能夠組織在（而且屬於）包中，僅顯示特定包中的相關內容。數據庫
類圖(Class diagram)是最經常使用的UML圖，顯示出類、接口以及它們之間的靜態結構和關係；它用於描述系統的結構化設計。編程
類圖(Class diagram)最基本的元素是類或者接口。架構
爲系統詞彙建模型分佈式
爲系統的詞彙建模其實是從詞彙表中發現類，發現它的責任。工具
模型化簡單的協做編碼
協做是指一些類、接口和其餘的元素一塊兒工做提供一些合做的行爲，這些行爲不是簡單地將元素相加能獲得的。例如：當你爲一個分佈式的系統中的事務處理過程建模型時，你不可能只經過一個類來明白事務是怎樣進行的，事實上這個過程的執行涉及到一系列的類的協同工做。使用類圖來可視化這些類和他們的關係。url
模型化一個邏輯數據庫模式spa
想象模式是概念上設計數據庫的藍圖。在不少領域，你將想保存持久性數據到關係數據庫或面向對象的數據庫。你能夠用類圖爲這些數據庫模式創建模型。.net
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類圖中的屬性與操做要包括最終須要實現的所有方法與操做。