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