類圖的定義：是顯示一組類、接口、協作以及它們之間關系的圖。
類圖主要包含7種元素：、類、接口、協作、依賴關系、泛化關系、實現關系、關聯關系。
類圖：包、子系統，用來把模型元素聚集成更大的組塊。
類圖：約束、注解
類
1.類是一組擁有相同的屬性、操作、方法、關系和行為的對象地描述符。
2.類定義了一組有着狀態與行為的對象。類的狀態由屬性和關聯來描述，個體行為由操作來描述，對象的生命周期則由附加給類的狀態機來描述。
3.在UML中，類表達成一個有三個分隔區的矩形。其中頂端顯示類名，中間顯示類的屬性，尾端顯示類的操作。
類——屬性
可見性：描述了該屬性在那些范圍內可以被使用。
| 可見性 |
英文限定符 |
UML標准圖示 |
Rose圖示 |
說明 |
| 公有 |
public |
+ |
其他類可以訪問 |
|
| 私有 |
private |
- |
只對本類可見，不能被其他類訪問 |
|
| 保護 |
protected |
# |
對本類及其派生類可見 |
類型：屬性的數據類型，可以系統固有，也可以用戶自定義。屬性的類型決定了該屬性的所有可能取值的集合。
類——操作
可見性：同樣描述該操作在那些范圍內可以使用，與屬性的可見性相同。
參數列表：是一些按照順序排列的屬性定義了操作的輸入。例如：oper(out arg1:int, arg2:double=3.2)
返回類型即回送調用對象消息的類型。void關鍵字表示無返回值。
特性是對操作性質的約束說明。
類——職責
職責是類的契約或責任。當創建一個類時，就聲明了這個類的所有對象具有相同種類的狀態和相同種類的行為。在較高的抽象層次上，這些相應的屬性和操作正式要完成類的職責的特征。
類的職責是自由形式的文本，在非正式的類圖中，可以將職責列在類圖操作下的另一分割欄中。
接口
1.接口是一個被命名的操作集合，用於描述類或組件的一個服務。
2.接口不包含屬性與方法實現，但可以有一些操作。接口的所有內容都是公有的。
3.接口代表了一份契約，實現該接口的類元必須履行它。
4.在UML中，接口由一個帶名稱的小圓圈表示；也可以表示為帶有<<interface>>構造型的類
類圖中的關系
UML中最常用的四種關系，即關聯關系、泛化關系、依賴關系和實現關系。
類圖中的關系——關聯關系
1）關聯的實例被稱為鏈，每個鏈由一組有序或無序的對象組成。
2）關聯關系靠近被關聯元素的部分稱為關聯端，關聯的大部分描述都包含在一組關聯端的列表里，每個端用來描述關聯中類的對象的參與
3）二元關聯、自關聯、N元關聯。
注意要點
關聯名稱：放在關聯路徑的旁邊，但遠離關聯端。
角色：放在靠近關聯端的部分，表示該關聯端連接的類在這一關聯關系中擔任的角色。角色名上也可使用可見性修飾符號。
多重性：放在靠近關聯端的部分，表示在關聯關系中源端的一個對象可以與目標類的多少個對象之間有關聯。
導航性：一個布爾值，用來說明運行時刻是否可能穿越一個關聯。
限定符：是二元關聯上的屬性組成的列表的插槽，其中的屬性值用來從整個對象集合里選擇一個唯一的關聯對象或者關聯對象的集合。
約束：關聯間的約束關系。
[現實例子]
比如客戶和訂單，每個訂單對應特定的客戶，每個客戶對應一些特定的訂單；再例如公司和員工，每個公司對應一些特定的員工，每個員工對應一特定的公司。
派生關聯：屬於一種派生元素。它不增加語義信息，只是一種可以由兩個或兩個以上的基礎關聯推算出來的虛擬關聯。
兩種特殊的關聯關系：聚合關系與組合關系
1.聚合關系：描述“整體-部分”的關聯關系
聚合關系沒有改變整體與部分之間整個關聯的導航含義，也與整體和部分的生命周期無關。
2.組合關系：描述“整體-部分”的關聯關系
組合關系中的部分要完全依賴於整體。
關聯與聚合的區別
(1)關聯關系所涉及的兩個對象是處在同一個層次上的。比如人和自行車就是一種關聯關系，而不是聚合關系，因為人不是由自行車組成的。
聚合關系涉及的兩個對象處於不平等的層次上，一個代表整體，一個代表部分。比如:電腦和它的顯示器、鍵盤、主板以及內存就是聚集關系，因為主板是電腦的組成部分。
(2)對於具有聚集關系（尤其是強聚集關系）的兩個對象，整體對象會制約它的組成對象的生命周期。部分類的對象不能單獨存在，它的生命周期依賴於整體類的對象的生命周期，當整體消失，部分也就隨之消失。比如張三的電腦被偷了，那么電腦的所有組件也不存在了，除非張三事先把一些電腦的組件（比如硬盤和內存）拆了下來。
聚合與組合的區別
聚合關系：涉及的兩個對象處於不平等的層次上，一個代表整體，一個代表部分。比如:電腦和它的顯示器、鍵盤、主板以及內存就是聚集關系，因為主板是電腦的組成部分。
組合關系：代表整體的對象負責代表部分對象的生命周期。公司不存在，部門也沒有意義了。再例如：人和五臟六腑、四肢的關系。
類圖中的關系——泛化關系
泛化關系定義為一個較普通的元素與一個較特殊的元素之間的類元關系。其中描述一般的元素稱為父，描述特殊的元素稱為子。（子類是父類的繼承，則父類就是子類的泛化。）
通過泛化對應的繼承機制使子類共享父類的屬性和操作，小了模型的規模，同時也防止了模型的更新所導致的定義不一致的意外。
泛化關系的特征：
傳遞性：一個類子類的子類同樣繼承了這個類的特性。在父方向上經過了一個或幾個泛化的元素被稱為祖先，在子方向上則被稱為后代。
反對稱性：泛化關系不能成環，即一個類不可能是自己的祖先和自己的后代。
泛化關系的兩種情況
單繼承：每個類之多能擁有一個父類。
編程語言：C#、Java等
多重繼承：子類可以有多個父類並繼承了所有父類的結構、行為和約束。
編程語言：C++等
類圖中的關系——依賴關系
依賴關系表示的是兩個元素之間語義上的連接關系。對於兩個元素X和Y，如果元素X的變化會引起對另一個元素Y的變化，則稱元素Y依賴於X。其中，X被稱為提供者，Y被稱為客戶。
[現實例子]比如說你要去擰螺絲，你是不是要借助(也就是依賴)螺絲刀(Screwdriver)來幫助你完成擰螺絲(screw)的工作。
對於類圖而言，主要有以下需要使用依賴的情況：
1）客戶類向提供者類發送消息。
2）提供者類是客戶類的屬性類型。
3）提供者類是客戶類操作的參數類型。
類圖中的關系——實現關系
實現關系用來表示規格說明與實現之間的關系。在類圖中，實現關系主要用於接口與實現該接口的類之間。
一個類可以實現多個接口，一個接口也可以被多個類實現。
實現關系的兩種表示法：
a.當接口元素以帶構造型的類的方式表示時，用虛線三角形箭頭表示。
b.當接口元素以小圓圈方式表示時，用實線表示。
綜合例子：
補充
涉及類的其他概念——抽象類
抽象類即不可實例化的類，也就是說，抽象類沒有直接的實例。
在UML中，抽象類通過對類名添加斜體修飾來表示。
涉及類的其他概念——模板類
模板又稱為參數化元素是對一類帶有一個或者多個未綁定的形式參數的元素的描述。模板應用在類上時稱為模板類。
對應概念：C++中的模板與Java中的泛型
模板類可以根據參數來定義類，而不用說明屬性和操作參數及返回值的具體類型，使用時通過實際值代替參數即可創建新的類，這樣就可以避免建立大量功能相似的類。
涉及類的其他概念——關聯類
具有類的特性的關聯關系，稱為關聯類。關聯類具有關聯和類二者的特性，它既可以關聯類元素，也可以擁有屬性和操作。
關聯類在UML中被表示為一個類符號，並通過一條虛線連接到關聯路徑。
涉及類的其他概念——分析類
分析類是一個主要用於開發過程中的概念，用來獲取系統中主要的“職責簇”，代表系統的原型類，是帶有某些構造型的類元素。
邊界類：用於對系統外部環境與其內部運作之間的交互進行建模的類。
控制類：對一個或多個用例所特有的控制行為進行建模的類。
實體類：用於對必須存儲的信息和相關行為建模的類。
類圖的建模技術
對邏輯數據庫模式建模
識別模型中那些狀態必須超過應用程序生存時間的類作為需要作為永久數據存儲的類。
創建一個包含這些類的類圖。可以自己定義相關的構造型和標記值組合。
對類的結構細節進行細化。包括屬性的細節、類之間的關聯及其多重性。
注意那些增加數據庫設計復雜化的公共模式並盡量簡化，如循環關聯、一對一的關聯和N元關聯等。
考慮類的行為。這些行為主要包括對數據存取和數據完整性約束重要的操作。一般情況下，這些業務規則應該被封裝在這些永久類的上一層中。
如何閱讀類圖？
閱讀順序應遵循的原則：
1）先看清有哪些類；
2）然后看看類之間存在的關系；
3）結合多重性來理解類圖的結構特點以及各個屬性和方法的含義
案例：
1.確定類:Customer、Consignee、Order、OrderItem、DeliverOrder、Peddlery、Product。
2.讀出關系：從圖中關系最復雜（也就是線最密集）的類開始閱讀，本圖中最復雜的就是Order類。
1）OrderItem和Order之間是組合關系，根據箭頭的方向可知Order包含了OrderItem。
2）Order類和Customer、Consignee、DeliverOrder是關聯關系。也就是說，一個訂單和客戶、收貨人、送貨單是相關的。
3.多重性來理解類圖的結構特點
4．理解方法與圖
如何建立類圖？
1、建立類圖的步驟
1）分析問題域，確定需求；
2）尋找類，確定類的含義和職責；
3）定義類的屬性和操作；
4）確定類之間的關系；
5）精化類和類間的關系；
6）繪制類圖。
2、尋找類的方法
使用名詞/動詞尋找類：
1）收集相關信息
a.補充的需求規格說明
b.用例
c.項目說明文檔
d.其他文檔
2）分析信息
名詞、名詞短語 類或屬性
動詞、動詞短語 操作
3、尋找類的方法
使用CRC分析法尋找類：
C-class（類）
R-responsibility（職責）
C-collaboration（協作）
CRC分析法是根據類所要扮演的職責來確定類。
a.腦力風暴收集信息。
b.關鍵業務用類表示，其它卡片作為屬性。
案例：
需求描述如下：
李小平是一個愛書之人，家里各類書籍已過千冊，而平時又時常有朋友外借，因此需要一個個人圖書管理系統。該系統應該能夠將書籍的基本信息按計算機類、非計算機類分別建檔，實現按書名、作者、類別、出版社等關鍵字的組合查詢功能。在使用該系統錄入新書籍時系統會自動按規則生成書號，可以修改信息，但一經創建就不允許刪除。該系統還應該能夠對書籍的外借情況進行記錄，可對外借情況列表打印。另外，還希望能夠對書籍的購買金額、冊數按特定時間周期進行統計。
發現類：
篩選備選類
“李小平”、“人”、“家里”很明顯是系統外的概念，無須對其建模；
而“個人圖書管理系統”、“系統”指的就是將要開發的系統，即系統本身，也無須對其進行建模；
很明顯“書籍”是一個很重要的類，而“書名”、“作者”、“類別”、“出版社”、“書號”則都是用來描述書籍的基本信息的，因此應該作為“書籍”類的屬性處理，而“規則”是指書號的生成規則，而書號則是書籍的一個屬性，因此“規則”可以作為編寫“書籍”類構造函數的指南。
“基本信息”則是書名、作者、類別等描述書籍的基本信息統稱，“關鍵字”則是代表其中之一，因此無需對其建模；
“功能”、“新書籍”、“信息”、“記錄”都是在描述需求時使用到的一些相關詞語，並不是問題域的本質，因此先可以將其淘汰掉；
篩選修選類
“計算機類”、“非計算機類”是該系統中圖書的兩大分類，因此應該對其建模，並改名為“計算機類書籍”和“非計算機類書籍”，以減少歧義；
“外借情況”則是用來表示一次借閱行為，應該成為一個候選類，多個外借情況將組成“外借情況列表”，而外借情況中一個很重要的角色是“朋友”—借閱主體。雖然到本系統中並不需要建立“朋友”的資料庫，但考慮到可能會需要列出某個朋友的借閱情況，因此還是將其列為候選類。為了能夠更好地表述，將“外借情況”改名為“借閱記錄”，而將“外借情況列表”改名為“借閱記錄列表”；
“購買金額”、“冊數”都是統計的結果，都是一個數字，因此不用將其建模，而“特定時限”則是統計的范圍，也無需將其建模；不過從這里的分析中，我們可以發現，在該需求描述中隱藏着一個關鍵類—書籍列表，也就是執行統計的主體。
得到候選類
書籍 計算機類書籍 非計算機類書籍
借閱記錄 借閱記錄列表 書籍列表
分析與建模
