類圖知識點

1概述編輯
類圖(Class diagram)由許多（靜態）說明性的模型元素（例如類、包和它們之間的關係，這些元素和它們的內容互相連接）組成。類圖可以組織在（並且屬於）包中，僅顯示特定包中的相關內容。
類圖(Class diagram)是最常用的UML圖，顯示出類、接口以及它們之間的靜態結構和關係；它用於描述系統的結構化設計。
類圖(Class diagram)最基本的元素是類或者接口。
2內容編輯
類
接口
協作
關係
同其他的圖一樣，類圖也可以包含註解和限制。
類圖中也可以包含包和子系統，這兩者用來將元素的分組。有時候你也可以將類的實例放到類圖中。
注：組件圖和分佈圖和類圖類似，雖然他們不包含類而是分別包含組件和節點。
3使用類圖編輯
爲系統詞彙建模型
爲系統的詞彙建模實際上是從詞彙表中發現類，發現它的責任。
模型化簡單的協作
協作是指一些類、接口和其他的元素一起工作提供一些合作的行爲，這些行爲不是簡單地將元素加能得到的。例如：當你爲一個分佈式的系統中的事務處理過程建模型時，你不可能只通過一個類來明白事務是怎樣進行的，事實上這個過程的執行涉及到一系列的類的協同工作。使用類圖來可視化這些類和他們的關係。
模型化一個邏輯數據庫模式
想象模式是概念上設計數據庫的藍圖。在很多領域，你將想保存持久性數據到關係數據庫或面向對象的數據庫。你可以用類圖爲這些數據庫模式建立模型。
類
（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體現爲局部變量，方法的參數、或靜態方法的調用。
表示方法：虛線+箭頭 箭頭指向被依賴的一方，也就是指向局部變量。
4通用技術編輯
沒有類是單獨存在的，他們通常和別的類協作，創造比單獨工作更大的語義。因此，除了捕獲系統的詞彙以外，還要將注意力集中到這些類是如何在一起工作的。使用類圖來表達這種協作。
l 確定你建模的機制。機制代表了部分你建模的系統的一些功能和行爲，這些功能和行爲是一組類、接口和其他事物相互作用的結果。
l 對於每個機制，確定類、接口和其他的參與這個協作的協作。同時確定這些事物之間的關係。
l 用場景來預排這些事物，沿着這條路你將發現模型中忽略的部分和定義錯誤的部分。
l 確定用這些事物的內容來填充它們。對於類，開始於獲得一個責任（類的職責），然後，將它轉化爲具體的屬性和方法。
圖7-1是一個自治機器人的類圖。這張的圖焦點聚集那些讓機器人在路上行走的機制對應的類上。你可以發現一個虛類Motor和兩個從它派生出來的類：SteeringMotor和MainMotor。這兩個類都從它的父親Motor繼承了五個方法。這兩個類又是另一個類Driver的一部分。類PathAgent和Driver有一個1對1的關係，和CollisionSensor有1對n的關係。
在這個系統中其實還有很多其他的類，但這張圖的重點是放在那些將機器人移動的類上的。在其他的圖中你可能也會看到這些類。通過將焦點放在不通的功能上，可以獲得從不通的角度對整個系統的認識，最終達到認識整個系統。
很多系統都是有持久性數據的，也就是說要將這些數據保存到數據庫中以便下一次使用。通常你會使用關係型數據庫或面向對象的數據庫，或其它類型的數據庫來保存數據。UML很適合爲邏輯數據庫模式建模。
UML的類圖是E-R圖（爲邏輯數據庫建模的通用工具）的超集，儘管E-R圖的重點是數據，類圖的擴展允許模型化行爲。在物理數據庫中這些邏輯操作一半轉化爲觸發器或存儲過程。
l 確定那些狀態比其生命週期要長的類。
l 創建一張包含這些類的圖，標記它們爲持久性的。
l 詳細定義它們的屬性。
l 對於使得物理數據庫設計複雜的模式如：循環關係、1對1關係、N元關係，考慮創建中間抽象來使得邏輯結構複雜。
l 詳細定義這些類的操作，特別是那些訪問數據和涉及數據完整性的方法。
l 如果可能的話使用工具來將你的邏輯設計轉化爲物理設計。
建模是重要的，但要記住的是對於開發組來說軟件纔是主要的產品，而不是圖。當然，畫圖的主要目的是爲了更好地理解系統，預測什麼時候可以提供什麼樣的軟件來滿足用戶的需要。基於這個理由，讓你畫的圖對開發有指導意義是很重要的。
某些時候，使用UML。你的模型並不能直接映射成爲代碼。例如，如果你在使用活動圖爲一個商業過程建模，很多活動實際上涉及人而不是計算機。
很多時候，你創建的圖形可以被映射成爲代碼。UML並不是專門爲面向對象的語言設計的，它支持多種語言，但使用面向對象的語言會更直觀些，特別是類圖的映射，它的內容可以直接映射成爲面嚮對象語言的內容。如：C++，SMALLTALK、ADA、ObjectPascal、Eiffel和Forte。UML還支持如Visual Basic這樣的面向對象的語言。
正向工程：是從圖到代碼的過程。通過對某中特定語言的映射可以從UML的圖得到該語言的代碼。正向工程會丟失信息，這是因爲UML比任何一種程序語言的語義都豐富。這也正是爲什麼你需要UML模型的原因。結構特性、協作、交互等可以通過UML直觀地表達出來，使用代碼就不是那麼明顯了。