簡介
類圖(Class diagram)由許多（靜态）說明性的模型元素（例如類、包和它們之間的關系，這些元素和它們的内容互相連接）組成。類圖可以組織在（并且屬于）包中，僅顯示特定包中的相關内容。類圖(Class diagram)是最常用的UML圖，顯示出類、接口以及它們之間的靜态結構和關系；它用于描述系統的結構化設計。類圖(Class diagram)最基本的元素是類或者接口。
類圖主要用在面向對象軟件開發的分析和設計階段，描述系統的靜态結構。類圖圖示了所構建系統的所有實體、實體的内部結構以及實體之間的關系。即．類圖中包含從用戶的客觀世界模型中抽象出來的類、類的内部結構和類與類之間的關系。它是構建其他設計模型的基礎，沒有類圖，就沒有對象圖、狀态圖、協作圖等其他UMI。動态模型圖。也就無法表示系統的動态行為。類圖也是面向對象編程的起點和依據。
類圖用于描述系統中所包含的類以及它們之間的相互關系，幫助人們簡化對系統的理解，它是系統分析和設計階段的重要産物，也是系統編碼和測試的重要模型依據。
類圖作為最重要的UML模型，其複雜性直接影響到整個面向對象軟件的複雜性。
由于UML類圖元模型的龐大性和複雜性，為此，提出UML類圖元模型基于描述邏輯的一種表示方法。
作用
類圖的作用：
（1）：在軟件工程中，類圖是一種靜态的結構圖，描述了系統的類的集合，類的屬性和類之間的關系，可以簡化了人們對系統的理解；
（2）：類圖是系統分析和設計階段的重要産物，是系統編碼和測試的重要模型。
使用的場合
主要在三種場合中使用類圖。
（1）為系統詞彙建模型
為系統的詞彙建模實際上是從詞彙表中發現類，發現它的責任。
（2）模型化簡單的協作
協作是指一些類、接口和其他的元素一起工作提供一些合作的行為，這些行為不是簡單地将元素相加能得到的。例如：當你為一個分布式的系統中的事務處理過程建模型時，你不可能隻通過一個類來明白事務是怎樣進行的，事實上這個過程的執行涉及到一系列的類的協同工作。使用類圖來可視化這些類和他們的關系。
（3）模型化一個邏輯數據庫模式
想象模式是概念上設計數據庫的藍圖。在很多領域，你将想保存持久性數據到關系數據庫或面向對象的數據庫。你可以用類圖為這些數據庫模式建立模型。
相關介紹
類
類（Class）一般包含3個組成部分。第一個是類名；第二個是屬性（attributes）；第三個是該類提供的方法（類的性質可以放在第四部分；如果類中含有内部類，則會出現第五個組成部分）。類名部分是不能省略的，其他組成部分可以省略。類名書寫規範：正體字說明類是可被實例化的，斜體字說明類為抽象類。
屬性和方法書寫規範：修飾符[描述信息]屬性、方法名稱[參數][：返回類型|類型]。
屬性和方法之前可附加的可見性修飾符：
加号（+）表示public；減号（-）表示private；井号(#)表示protected；省略這些修飾符表示具有package（包）級别的可見性。
如果屬性或方法具有下劃線，則說明它是靜态的。描述信息使用<<開頭，使用>>結尾。類的性質是由一個屬性、一個賦值方法和一個取值方法組成。書寫方式和方法類似。
包
包（Package）是一種常規用途的組合機制。UML中的一個包直接對應于Java中的一個包。在Java中，一個包可能含有其他包、類或者同時含有這兩者。進行建模時，通常使用邏輯性的包，用于對模型進行組織；使用物理性的包，用于轉換成系統中的Java包。每個包的名稱對這個包進行了惟一性的标識。
接口
接口（Interface）是一系列操作的集合，它指定了一個類所提供的服務。它直接對應于Java中的一個接口類型。接口的表示有大概兩種方式。具體畫法見下例：
關系
常見的關系有：繼承（Inheritance），關聯關系（Association），聚合關系（Aggregation），複合關系（Composition），依賴關系（Dependency）,實現關系(Realization/Implementation)。
其中，聚合關系（Aggregation），複合關系（Composition）屬于關聯關系（Association）。
一般關系表現為繼承或實現關系(is a)，關聯關系表現為變量(has a)，依賴關系表現為函數中的參數(use a)。
一般化關系：表示為類與類之間的繼承關系，接口與接口之間的繼承，類對接口的實現關系。
表示方法：用一個空心箭頭+實線，箭頭指向父類。或空心箭頭+虛線，如果父類是接口。
關聯關系：類與類之間的聯接，它使一個類知道另一個類的屬性和方法。
表示方法：用實線+箭頭，箭頭指向被使用的類。
聚合關系：是關聯關系的一種，是強的關聯關系。聚合關系是整體和個體的關系。關聯關系的兩個類處于同一層次上，而聚合關系兩個類處于不同的層次，一個是整體，一個是部分。
表示方法：空心菱形+實線+箭頭，箭頭指向整體。
合成關系：是關聯關系的一種，是比聚合關系強的關系。它要求普通的聚合關系中代表整體的對象負責代表部分的對象的生命周期，合成關系不能共享。
表示方法：實心菱形+實線+箭頭，
依賴關系：是類與類之間的連接，表示一個類依賴于另一個類的定義。例如如果A依賴于B，則B體現為局部變量，方法的參數、或靜态方法的調用。
表示方法：虛線+箭頭箭頭指向被依賴的一方，也就是指向局部變量。
通用技術
沒有類是單獨存在的，他們通常和别的類協作，創造比單獨工作更大的語義。因此，除了捕獲系統的詞彙以外，還要将注意力集中到這些類是如何在一起工作的。使用類圖來表達這種協作。
确定你建模的機制。機制代表了部分你建模的系統的一些功能和行為，這些功能和行為是一組類、接口和其他事物相互作用的結果。對于每個機制，确定類、接口和其他的參與這個協作的協作。同時确定這些事物之間的關系。用場景來預排這些事物，沿着這條路你将發現模型中忽略的部分和定義錯誤的部分。确定用這些事物的内容來填充它們。對于類，開始于獲得一個責任（類的職責），然後，将它轉化為具體的屬性和方法。
很多系統都是有持久性數據的，也就是說要将這些數據保存到數據庫中以便下一次使用。通常你會使用關系型數據庫或面向對象的數據庫，或其它類型的數據庫來保存數據。UML很适合為邏輯數據庫模式建模。
UML的類圖是E-R圖（為邏輯數據庫建模的通用工具）的超集，盡管E-R圖的重點是數據，類圖的擴展允許模型化行為。在物理數據庫中這些邏輯操作一半轉化為觸發器或存儲過程。
确定那些狀态比其生命周期要長的類。創建一張包含這些類的圖，标記它們為持久性的。詳細定義它們的屬性。
對于使得物理數據庫設計複雜的模式如：循環關系、1對1關系、N元關系，考慮創建中間抽象來使得邏輯結構複雜。
詳細定義這些類的操作，特别是那些訪問數據和涉及數據完整性的方法。
如果可能的話使用工具來将你的邏輯設計轉化為物理設計。
建模是重要的，但要記住的是對于開發組來說軟件才是主要的産品，而不是圖。當然，畫圖的主要目的是為了更好地理解系統，預測什麼時候可以提供什麼樣的軟件來滿足用戶的需要。基于這個理由，讓你畫的圖對開發有指導意義是很重要的。
某些時候，使用UML。你的模型并不能直接映射成為代碼。例如，如果你在使用活動圖為一個商業過程建模，很多活動實際上涉及人而不是計算機。
很多時候，你創建的圖形可以被映射成為代碼。UML并不是專門為面向對象的語言設計的，它支持多種語言，但使用面向對象的語言會更直觀些，特别是類圖的映射，它的内容可以直接映射成為面向對象語言的内容。如：C++，SMALLTALK、ADA、ObjectPascal、Eiffel和Forte。UML還支持如Visual Basic這樣的面向對象的語言。正向工程：是從圖到代碼的過程。通過對某中特定語言的映射可以從UML的圖得到該語言的代碼。正向工程會丢失信息，這是因為UML比任何一種程序語言的語義都豐富。這也正是為什麼你需要UML模型的原因。結構特性、協作、交互等可以通過UML直觀地表達出來，使用代碼就不是那麼明顯了。
注意事項
（1）選擇将圖形映射到哪一種程序語言。
（2）根據你選擇的語言的語義，你可能要對使用某寫UML的特性加以限制。例如：UML允許你使用多重繼承，而SmallTalk隻允許一重繼承。
（3）使用标記值來指定比的目的語言。你可以在類級進行也可以在協作或包的層次上進行。
（4）使用工具來對你的模型進行正向工程。反向工程：反向工程是從代碼到模型的過程。
進行反向工程：
1.确定将你的程序語言的代碼反向成模型的規則。
2.使用工具（Rose C++ Analyzer）進行反向工程。
結構化好的類圖的特點
1、焦點放在系統靜态設計視圖的一個方面。
2、隻包含為了理解該方面而應該存在的元素。
3、提供足夠的信息來理解該圖。
4、不讓讀者産生錯誤的信息。
