類的UML表示
類的命名盡量應用領域中的術語，應明确、無岐義，以利于相互交流和理解。類的屬性、操作中的可見性使用+、#、－分别表示public、protected、private。
類之間的關系
類之間的關系是類圖中比較複雜的内容。有關聯、聚合、組合、泛化、依賴。
關聯：是模型元素之間的一種語義聯系，是類之間的一種很弱的聯系。關聯可以有方向，可以是單向關聯，也可以是雙向關聯。可以給關聯加上關聯名來描述關聯的作用。關聯兩端的類也可以以某種角色參與關聯，角色可以具有多重性，表示可以有多少個對象參與關聯。可以通過關聯類進一步描述關聯的屬性、操作以及其他信息。關聯類通過一條虛線與關聯連接。對于關聯可以加上一些約束，以加強關聯的含義。如下圖所示：
聚合是一種特殊的關聯，聚合表示整體與部分的關系。通常在定義一個整體類後，再去分析這個整體類的組成結構。從而找出一些組成類，該整體類和組成類之間就形成了聚合關系。例如艦隊是由一系列的艦船組成。需求描述中“包含”、“組成”、“分為….部分”等詞常意味着聚合關系。
組合也是一種特殊的關聯，也表示類之間整體和部分的關系，但是組合關系中部分和整體具有統一的生存期。一旦整體對象不存在，部分對象也将不存在。部分對象與整體對象之間具有共生死的關系。
聚合和組合的區别：聚合關系是“has－a”關系，組合關系是“contains－a”關系；聚合關系表示整體與部分的關系比較弱，而組合比較強；聚合關系中代表部分事物的對象與代表聚合事物的對象的生存期無關，一旦删除了聚合對象不一定就删除了代表部分事物的對象。組合中一旦删除了組合對象，同時也就删除了代表部分事物的對象。
泛化定義了一般元素和特殊元素之間的分類關系，類之間的這種泛化關系也就是繼承關系。泛化關系是“a－kind－of”關系，定義一般元素和特殊元素之間的分類關系。下圖是一個泛化關系的例子。
有兩個元素如果修改X的定義可能會導緻對Y的定義，則認為Y依賴X。依賴關系可能由各種原因引起，如一個類向另一個類發送消息，或者一個類是另一個類的數據成員類型，或者一個類是另一個類的操作的參數類型等。有時依賴關系和關聯關系比較難區分。如果類A和類B有關聯關系，它們之間必然有依賴關系。如果兩個類之間有關聯關系時不用再表示出這兩個類之間的依賴關系。
建立類圖
在軟件開發不同階段使用的類圖具有不同的抽象層次，即概念層、說明層、和實現層。使用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)角色扮演。最好是一個團隊執行，一個人很難做。每個人負責幾個類。對每一個Usecase其中的情景。導引者指定從某一個人的類開始，某一個人看一看自己能夠獨立完成，如果不能完成，大家看一看手中的類，誰能完成，就站起來，宣布自己能夠完成，以緻繼續這個過程，每個人完成自己的職責就坐下。在這過程中不斷修改類的責任，并寫下協作者的名字。
4.根據邊界類、控制類、實體類幫助分析系統中的類
UML中類有三種主要的版型：邊界類、控制類和實體類。引入邊界類、控制類及實體類的概念有助于分析和設計人員确定系統中的類。
邊界類位于系統與外界的交界處，窗體、報表、以及表示通訊協議的類、直接與外部設備交互的類、直接與外部系統交互的類等都是邊界類。通過用例圖可以确定需要的邊界類，每個Actor/UseCase對至少要一個邊界類，但并非每個Actor/UseCase對要唯一的邊界類。
實體類保存要放進持久存儲體的信息。持久存儲體就是數據庫、文件等可以永久存儲數據的介質。實體類可以通過事件流和交互圖發現。通常每個實體類在數據庫中有相應的表，實體類中的屬性對應數據庫表中的字段。
控制類是控制其他類工作的類。每個用例通常有一個控制類，控制用例中的事件順序，控制類也可以在多個用例間共用。其他類并不向控制類發送很多消息，而是由控制類發出很多消息。
5.領域進行分析
建立類圖的過程就是對領域及其解決方案的分析和設計過程。類的獲取是一個依賴個人創造力的過程，有時需要和領域專家合作，對研究領域進行仔細分析，抽象出領域中的概念，定義其含義及相互關系，分析出系統類，并用領域中的術語為類命名。領域分析是：通過對某一領域中的已有應用系統、理論、技術、開發曆史等的研究，來标識、收集、組織、分析和表示領域模型及軟件體系結構的過程，并得到結果。
