在UML的靜態機制中類圖是一個重點，它不但是設計人員關心的核心，更是實現人員關注的核心。建模工具也主要根據類圖來產生代碼。類圖在UML的9個圖中占據了一個相當重要的地位。

James Rumbaugh對類的定義是：類是具有相似結構、行為和關系的一組對象的描述符。類是面向對象系統中最重要的構造塊。類圖顯示了一組類、接口、協作以及他們之間的關系。在UML中問題域最終要被逐步轉化，通過類來建模，通過編程語言構建這些類從而實現系統。類加上他們之間的關系就構成了類圖，類圖中還可以包含接口、包等元素，也可以包括對象、鏈等實例。接口在類圖中通過版型來表示<<interface>>，下面的介紹將主要介紹類，接口和類類似。

A.????? 類的UML表示

類的命名盡量應用領域中的術語，應明確、無岐義，以利于相互交流和理解。類的屬性、操作中的可見性使用＋、#、－分別表示public、protected、private。

?

B.????? 類之間的關系

類之間的關系是類圖中比較復雜的內容。有關聯、聚合、組合、范化、依賴。

關聯：是模型元素之間的一種語義聯系，是類之間的一種很弱的聯系。關聯可以有方向，可以是單向關聯，也可以是雙向關聯。可以給關聯加上關聯名來描述關聯的作用。關聯兩端的類也可以以某種角色參與關聯，角色可以具有多重性，表示可以有多少個對象參與關聯。可以通過關聯類進一步描述關聯的屬性、操作以及其他信息。關聯類通過一條虛線與關聯連接。對于關聯可以加上一些約束，以加強關聯的含義。如下圖所示：

?

聚合是一種特殊的關聯，聚合表示整體與部分的關系。通常在定義一個整體類后，再去分析這個整體類的組成結構。從而找出一些組成類，該整體類和組成類之間就形成了聚合關系。例如艦隊是由一系列的艦船組成。需求描述中“包含”、“組成”、“分為….部分”等詞常意味著聚合關系。

組合也是一種特殊的關聯，也表示類之間整體和部分的關系，但是組合關系中部分和整體具有統一的生存期。一旦整體對象不存在，部分對象也將不存在。部分對象與整體對象之間具有共生死的關系。

聚合和組合的區別：聚合關系是“has－a”關系，組合關系是“contains－a”關系；聚合關系表示整體與部分的關系比較弱，而組合比較強；聚合關系中代表部分事物的對象與代表聚合事物的對象的生存期無關，一旦刪除了聚合對象不一定就刪除了代表部分事物的對象。組合中一旦刪除了組合對象，同時也就刪除了代表部分事物的對象。

泛化定義了一般元素和特殊元素之間的分類關系，類之間的這種泛化關系也就是繼承關系。泛化關系是“a－kind－of”關系，定義一般元素和特殊元素之間的分類關系。下圖是一個泛化關系的例子。

有兩個元素如果修改X的定義可能會導致對Y的定義，則認為Y依賴X。依賴關系可能由各種原因引起，如一個類向另一個類發送消息，或者一個類是另一個類的數據成員類型，或者一個類是另一個類的操作的參數類型等。有時依賴關系和關聯關系比較難區分。如果類A和類B有關聯關系，它們之間必然有依賴關系。如果兩個類之間有關聯關系時不用再表示出這兩個類之間的依賴關系。

?

C.????? 建立類圖

在軟件開發不同階段使用的類圖具有不同的抽象層次，即概念層、說明層、和實現層。使用UML進行應用建模也應該是一個迭代的過程，所以我們應該建立一個類圖的層次的概念。

概念層類圖描述應用領域中的概念，這些概念與實現它們的類有聯系。通常沒有直接的映射關系。畫概念層類圖時很少考慮或不考慮實現問題，因此概念層類圖應獨立于具體的編程語言。下面是一個概念層類的表示。

說明層類圖。此時我們考察的是類的接口部分，而不是實現部分。這個接口可能因為實現環境、運行特性等有多種不同的實現。下面是一個說明層類的表示。

實現層類圖才真正考慮類的實現問題，提供實現的細節。此時的類的概念才應該是真正的嚴格意義上的類。它揭示了軟件實體的構成情況。實現層的類是最常用的，在很多的時候說明層的類更有助于人們對軟件的理解。

UML的最終目標是識別出所有必須的類，并分析這些類之間的關系，類的識別貫穿于整個建模過程，分析階段主要識別問題域相關的類，在設計階段需要加入一些反映設計思想、方法的類以及實現問題域所需要的類，在編碼實現階段，因為語言的特點，可能需要加入一些其他的類。

建立類圖的步驟：

（1）研究分析問題領域確定系統需求。

（2）確定類，明確類的含義和職責、確定屬性和操作。

（3）確定類之間的關系。

類的識別是一個需要大量技巧的工作，尋找類的一些技巧包括：名詞識別法；根據用例描述確定類；使用CRC分析法；根據邊界類、控制類、實體類的劃分來幫助分析系統中的類；參考設計模式確定類；對領域進行分析或利用已有領域分析結果得到類；利用RUP中如何在分析和設計中尋找類的步驟。

1.?????? 名詞識別法：

這種方法的關鍵是識別系統問題域中的實體。對系統進行描述，描述應該使用問題域中的概念和命名，從系統描述中標識名詞及名詞短語，其中的名詞往往可以標識為對象，復數名詞往往可以標識為類。

2.?????? 從用例中識別類：

用例圖實質上是一種系統描述的形式，自然可以根據用例描述來識別類。針對各個用例，可以提如下的問題輔助識別：

用例描述中出現了那些實體？

用例的完成需要哪些實體合作？

用例執行過程中會產生并存儲哪些信息？

用例要求與之關聯的每個角色的輸入是什么？

用例反饋與之關聯的每個角色的輸出是什么？

用例需要操作哪些硬設備？

在面向對象應用中，類之間傳遞的信息數據要么可以映射到發送方的某些屬性，要么該信息數據本身就是一個對象。綜合不同的用例識別結果，就可以得到整個系統的類，在類的基礎上，我們又可以分析用例的動態特性來對用例進行動態行為建模。

3.?????? 使用CRC分析法：

CRC（Class,Responsibilities,Collaboration）卡的最大價值在于把人們從思考過程模式中脫離出來，更充分的專注于對象技術。CRC卡允許整個項目組對設計做出貢獻。參與系統設計的人越多，能夠收集到的好主意也就越多。因為CRC會議是大家全力參與的，通常只需要很少的有類名的卡片，實際上沒有寫出完整的卡片。CRC會議進行中，一些人模擬系統和對象交流，把消息傳給其他的對象。通過一步步處理，問題很容易地被解決。它由三部分組成：類(Class)、職責(Responsibility)、協作(Collaborator)。下面是一個CRC卡的示例：

職責是類需要知道或做的任何事物。這些職責是類自身所知的知識，或類在執行時所需的知識。協作是指為獲取消息，或協助執行活動的其他類。創建CRC模型需要下面的步驟。

1)??????? 建立團隊，包括客戶、設計人員、分析人員和一個導引者。如果沒有那么多人，那么可以是客戶和你自己兩個人。

2)??????? 找出需求中存在的名詞和名詞詞組，特別注意復數（通常是集合），他們對應的單數才是。把你第一次想到的所有概念都寫在白板或紙上。不管看起來這些概念是如何荒謬，把他們都寫下來。

3)??????? 篩選。把對象分為三類，核心對象（必須首先實現），可選的（目前不能確定），以及不需要的對象。這之前最好確定一下你的項目范圍。某些不屬于本項目范圍的對象可以使用輕量的adapter或proxy實現。這里可以加入對分析、設計模式的考慮和應用。

4)??????? 建卡。取出CRC卡，把核心類寫在每一張卡上，把可選的類和排除的類分別寫在不同的紙上。

5)??????? 角色扮演。最好是一個團隊執行，一個人很難做。每個人負責幾個類。對每一個Use case其中的情景。導引者指定從某一個人的類開始，某一個人看一看自己能夠獨立完成，如果不能完成，大家看一看手中的類，誰能完成，就站起來，宣布自己能夠完成，以致繼續這個過程，每個人完成自己的職責就坐下。在這過程中不斷修改類的責任，并寫下協作者的名字。

4.?????? 根據邊界類、控制類、實體類幫助分析系統中的類

UML中類有三種主要的版型：邊界類、控制類和實體類。引入邊界類、控制類及實體類的概念有助于分析和設計人員確定系統中的類。

邊界類位于系統與外界的交界處，窗體、報表、以及表示通訊協議的類、直接與外部設備交互的類、直接與外部系統交互的類等都是邊界類。通過用例圖可以確定需要的邊界類，每個Actor/Use Case對至少要一個邊界類，但并非每個Actor/Use Case對要唯一的邊界類。

實體類保存要放進持久存儲體的信息。持久存儲體就是數據庫、文件等可以永久存儲數據的介質。實體類可以通過事件流和交互圖發現。通常每個實體類在數據庫中有相應的表，實體類中的屬性對應數據庫表中的字段。

控制類是控制其他類工作的類。每個用例通常有一個控制類，控制用例中的事件順序，控制類也可以在多個用例間共用。其他類并不向控制類發送很多消息，而是由控制類發出很多消息。

5.?????? 領域進行分析

建立類圖的過程就是對領域及其解決方案的分析和設計過程。類的獲取是一個依賴個人創造力的過程，有時需要和領域專家合作，對研究領域進行仔細分析，抽象出領域中的概念，定義其含義及相互關系，分析出系統類，并用領域中的術語為類命名。領域分析是：通過對某一領域中的已有應用系統、理論、技術、開發歷史等的研究，來標識、收集、組織、分析和表示領域模型及軟件體系結構的過程，并得到結果。

?

D.?????? 使用類圖

類圖幾乎是所有面向對象方法的支柱，應該如何使用類圖呢？以下提供了一些使用類圖的一些建議。

不要試圖在項目的初始階段使用所有的符號，首先應該從簡單概念開始。比如類的關系等等，在需要的時候才使用。在項目的不同開發階段，應該使用不同的觀點來畫類圖。如果處于分析階段應該畫概念層類圖，當開始著手軟件設計時，應該畫說明層類圖，當針對某個特定的技術實現時應該畫實現層類圖。不要為每個事物都畫一個模型，應該把精力放在關鍵的領域。使用類圖的最大危險是過早的陷入實現的細節，為了避免這個問題，應該將重點放在概念層和說明層。



1．依賴：

依賴對象通過調用被依賴對象的方法來獲得服務。一種比較松散的關系，并且是短期的。我們的過程與對象往往依賴于我們的實體域對象。如在struts 的 action中調用模型層的方法。

2．關聯

它使一個類指到另一個類的屬性。長期的

3．聚合

聚合關系是關聯關系的一種，是強的關聯關系。聚合是整體和部分之間的關系。

4．組合

也叫合成關系，組成關系是關聯關系的一種，是比聚合關系強的關系。對象負責代表部分的對象的生命周期。

注：既然聚合，組合關系屬于關聯關系，那么如何區分一般關聯關系，聚合關系和組合關系呢？

一般關聯：只要一個對象聯系到另外一個對象就形成了關聯關系。如：人和他的貓，黑豹樂隊和竇魏，pc機和顯示器。

聚合關系：一種強關聯關系，它要求有部分和整體的關系，并且沒有了整體部分也可以獨立存在。在上面三個例子中人和它的貓顯然沒有部分和整體的關系，所以只能是一般的關聯關系。而黑豹樂隊和竇魏，竇魏等人組成了黑豹樂隊即：竇魏和黑豹是整體和部分的關系。而竇魏脫離了黑豹（早就離開了）更或者黑豹不存在了那么竇魏仍然可以以音樂人的身份存在（即對象仍然可以獨立存在）所以它屬于聚合關系。組成關系是可以共享的。（竇魏也可以加入其他樂隊）。

組合關系：一種更強的整體和部分的關系。它并且要求代表整體的對象負責代表部分的對象的生命周期，組成關系是不能共享的。如：pc機和顯示器的關系。