在畫類圖的時候，理清類和類之間的關係是重點。類的關係有泛化(Generalization)、實現（Realization）、依賴(Dependency)和關聯(Association)。其中關聯又分為一般關聯關係和聚合關係(Aggregation)，合成關係(Composition)。下面我們結合例項理解這些關係。

基本概念

類圖（Class Diagram）: 類圖是面向物件系統建模中最常用和最重要的圖，是定義其它圖的基礎。類圖主要是用來顯示系統中的類、介面以及它們之間的靜態結構和關係的一種靜態模型。

類圖的3個基本元件：類名、屬性、方法。 

泛化(generalization)：表示is-a的關係，是物件之間耦合度最大的一種關係，子類繼承父類的所有細節。直接使用語言中的繼承表達。在類圖中使用帶三角箭頭的實線表示，箭頭從子類指向父類。

實現（Realization）:在類圖中就是介面和實現的關係。這個沒什麼好講的。在類圖中使用帶三角箭頭的虛線表示，箭頭從實現類指向介面。

依賴(Dependency)：物件之間最弱的一種關聯方式，是臨時性的關聯。程式碼中一般指由區域性變數、函式引數、返回值建立的對於其他物件的呼叫關係。一個類呼叫被依賴類中的某些方法而得以完成這個類的一些職責。在類圖使用帶箭頭的虛線表示，箭頭從使用類指向被依賴的類。

關聯(Association) : 物件之間一種引用關係，比如客戶類與訂單類之間的關係。這種關係通常使用類的屬性表達。關聯又分為一般關聯、聚合關聯與組合關聯。後兩種在後面分析。在類圖使用帶箭頭的實線表示，箭頭從使用類指向被關聯的類。可以是單向和雙向。

聚合(Aggregation) : 表示has-a的關係，是一種不穩定的包含關係。較強於一般關聯,有整體與區域性的關係,並且沒有了整體,區域性也可單獨存在。如公司和員工的關係，公司包含員工，但如果公司倒閉，員工依然可以換公司。在類圖使用空心的菱形表示，菱形從區域性指向整體。

組合(Composition) : 表示contains-a的關係，是一種強烈的包含關係。組合類負責被組合類的生命週期。是一種更強的聚合關係。部分不能脫離整體存在。如公司和部門的關係，沒有了公司，部門也不能存在了；調查問卷中問題和選項的關係；訂單和訂單選項的關係。在類圖使用實心的菱形表示，菱形從區域性指向整體。

多重性(Multiplicity) : 通常在關聯、聚合、組合中使用。就是代表有多少個關聯物件存在。使用數字..星號（數字）表示。如下圖，一個割接通知可以關聯0個到N個故障單。

聚合和組合的區別

這兩個比較難理解，重點說一下。聚合和組合的區別在於：聚合關係是“has-a”關係，組合關係是“contains-a”關係；聚合關係表示整體與部分的關係比較弱，而組合比較強；聚合關係中代表部分事物的物件與代表聚合事物的物件的生存期無關，一旦刪除了聚合物件不一定就刪除了代表部分事物的物件。組合中一旦刪除了組合物件，同時也就刪除了代表部分事物的物件。

例項分析

聯通客戶響應OSS。系統有故障單、業務開通、資源核查、割接、業務重保、網路品質效能等功能模組。現在我們抽出部分需求做為例子講解。

大家可以參照著類圖，好好理解。

1． 通知分為一般通知、割接通知、重保通知。這個是繼承關係。

2． NoticeService和實現類NoticeServiceImpl是實現關係。

3． NoticeServiceImpl通過save方法的引數引用Notice,是依賴關係。同時呼叫了BaseDao完成功能，也是依賴關係。

4． 割接通知和故障單之間通過中間類(通知電路)關聯，是一般關聯。

5． 重保通知和預案庫間是聚合關係。因為預案庫可以事先錄入，和重保通知沒有必然聯絡，可以獨立存在。在系統中是手工從列表中選擇。刪除重保通知，不影響預案。

6． 割接通知和需求單之間是聚合關係。同理，需求單可以獨立於割接通知存在。也就是說刪除割接通知，不影響需求單。

7． 通知和回覆是組合關係。因為回覆不能獨立於通知存在。也就是說刪除通知，該條通知對應的回覆也要級聯刪除。

經過以上的分析，相信大家對類的關係已經有比較好的理解了。大家有什麼其它想法或好的見解，歡迎拍磚。

PS：還是那句話：以上類圖用Enterprise Architect 7.5所畫，在此推薦一下EA,非常不錯。可以替代Visio和Rose了。Visio功能不夠強大，Rose太重。唯有EA比較合適。

在UML 2.0的13種圖形中，類圖是使用頻率最高的UML圖之一。Martin Fowler在其著作《UML Distilled: A Brief Guide to the Standard Object Modeling Language, Third Edition》（《UML精粹：標準物件建模語言簡明指南（第3版）》）中有這麼一段：“If someone were to come up to you in a dark alley and say, 'Psst, wanna see a UML diagram?' that diagram would probably be a class diagram. The majority of UML diagrams I see are class diagrams.”（“如果有人在黑暗的小巷中向你走來並對你說：‘嘿，想不想看一張UML圖？’那麼這張圖很有可能就是一張類圖，我所見過的大部分的UML圖都是類圖”），由此可見類圖的重要性。

類圖用於描述系統中所包含的類以及它們之間的相互關係，幫助人們簡化對系統的理解，它是系統分析和設計階段的重要產物，也是系統編碼和測試的重要模型依據。

1. 類

類(Class)封裝了資料和行為，是面向物件的重要組成部分，它是具有相同屬性、操作、關係的物件集合的總稱。在系統中，每個類都具有一定的職責，職責指的是類要完成什麼樣的功能，要承擔什麼樣的義務。一個類可以有多種職責，設計得好的類一般只有一種職責。在定義類的時候，將類的職責分解成為類的屬性和操作（即方法）。類的屬性即類的資料職責，類的操作即類的行為職責。設計類是面向物件設計中最重要的組成部分，也是最複雜和最耗時的部分。

在軟體系統執行時，類將被例項化成物件(Object)，物件對應於某個具體的事物，是類的例項(Instance)。

類圖(Class Diagram)使用出現在系統中的不同類來描述系統的靜態結構，它用來描述不同的類以及它們之間的關係。

在系統分析與設計階段，類通常可以分為三種，分別是實體類(Entity Class)、控制類(Control Class)和邊界類(Boundary Class)，下面對這三種類加以簡要說明：

(1) 實體類：實體類對應系統需求中的每個實體，它們通常需要儲存在永久儲存體中，一般使用資料庫表或檔案來記錄，實體類既包括儲存和傳遞資料的類，還包括操作資料的類。實體類來源於需求說明中的名詞，如學生、商品等。

(2) 控制類：控制類用於體現應用程式的執行邏輯，提供相應的業務操作，將控制類抽象出來可以降低介面和資料庫之間的耦合度。控制類一般是由動賓結構的短語（動詞+名詞）轉化來的名詞，如增加商品對應有一個商品增加類，註冊對應有一個使用者註冊類等

(3) 邊界類：邊界類用於對外部使用者與系統之間的互動物件進行抽象，主要包括介面類，如對話方塊、視窗、選單等。

在面向物件分析和設計的初級階段，通常首先識別出實體類，繪製初始類圖，此時的類圖也可稱為領域模型，包括實體類及其它們之間的相互關係。

2. 類的UML圖示

在UML中，類使用包含類名、屬性和操作且帶有分隔線的長方形來表示，如定義一個Employee類，它包含屬性name、age和email，以及操作modifyInfo()，在UML類圖中該類如圖1所示：

圖1 類的UML圖示

圖1對應的Java程式碼片段如下：

public class Employee {
	private String name;
	private int age;
	private String email;
	
	public void modifyInfo() {
		......
	}
}

在UML類圖中，類一般由三部分組成：

(1) 第一部分是類名：每個類都必須有一個名字，類名是一個字串。

(2) 第二部分是類的屬性(Attributes)：屬性是指類的性質，即類的成員變數。一個類可以有任意多個屬性，也可以沒有屬性

UML規定屬性的表示方式為：

可見性 名稱:型別 [ = 預設值 ]

其中：

• “可見性”表示該屬性對於類外的元素而言是否可見，包括公有(public)、私有(private)和受保護(protected)三種，在類圖中分別用符號+、-和#表示。
• “名稱”表示屬性名，用一個字串表示。
• “型別”表示屬性的資料型別，可以是基本資料型別，也可以是使用者自定義型別。
• “預設值”是一個可選項，即屬性的初始值。

(3) 第三部分是類的操作(Operations)：操作是類的任意一個例項物件都可以使用的行為，是類的成員方法。

UML規定操作的表示方式為：

可見性 名稱(引數列表) [ : 返回型別]

其中：

• “可見性”的定義與屬性的可見性定義相同。
• “名稱”即方法名，用一個字串表示。
• “引數列表”表示方法的引數，其語法與屬性的定義相似，引數個數是任意的，多個引數之間用逗號“，”隔開。
• “返回型別”是一個可選項，表示方法的返回值型別，依賴於具體的程式語言，可以是基本資料型別，也可以是使用者自定義型別，還可以是空型別(void)，如果是構造方法，則無返回型別。

在類圖2中，操作method1的可見性為public(+)，帶入了一個Object型別的引數par，返回值為空(void)；操作method2的可見性為protected(#)，無引數，返回值為String型別；操作method3的可見性為private(-)，包含兩個引數，其中一個引數為int型別，另一個為int[]型別，返回值為int型別。

圖2 類圖操作說明示意圖

由於在Java語言中允許出現內部類，因此可能會出現包含四個部分的類圖，如圖3所示：

圖3 包含內部類的類圖

類與類之間的關係（1）

在軟體系統中，類並不是孤立存在的，類與類之間存在各種關係，對於不同型別的關係，UML提供了不同的表示方式。

1. 關聯關係

關聯(Association)關係是類與類之間最常用的一種關係，它是一種結構化關係，用於表示一類物件與另一類物件之間有聯絡，如汽車和輪胎、師傅和徒弟、班級和學生等等。在UML類圖中，用實線連線有關聯關係的物件所對應的類，在使用Java、C#和C++等程式語言實現關聯關係時，通常將一個類的物件作為另一個類的成員變數。在使用類圖表示關聯關係時可以在關聯線上標註角色名，一般使用一個表示兩者之間關係的動詞或者名詞表示角色名（有時該名詞為例項物件名），關係的兩端代表兩種不同的角色，因此在一個關聯關係中可以包含兩個角色名，角色名不是必須的，可以根據需要增加，其目的是使類之間的關係更加明確。

如在一個登入介面類LoginForm中包含一個JButton型別的註冊按鈕loginButton，它們之間可以表示為關聯關係，程式碼實現時可以在LoginForm中定義一個名為loginButton的屬性物件，其型別為JButton。如圖1所示：

圖1 關聯關係例項

圖1對應的Java程式碼片段如下：

public class LoginForm {
private JButton loginButton; //定義為成員變數
……
}

public class JButton {
    ……
}

在UML中，關聯關係通常又包含如下幾種形式：

(1) 雙向關聯

預設情況下，關聯是雙向的。例如：顧客(Customer)購買商品(Product)並擁有商品，反之，賣出的商品總有某個顧客與之相關聯。因此，Customer類和Product類之間具有雙向關聯關係，如圖2所示：

圖2 雙向關聯例項

圖2對應的Java程式碼片段如下：

public class Customer {
private Product[] products;
……
}

public class Product {
private Customer customer;
……
}

(2) 單向關聯

類的關聯關係也可以是單向的，單向關聯用帶箭頭的實線表示。例如：顧客(Customer)擁有地址(Address)，則Customer類與Address類具有單向關聯關係，如圖3所示：

圖3 單向關聯例項

圖3對應的Java程式碼片段如下：

public class Customer {
private Address address;
……
}

public class Address {
……
}

(3) 自關聯

在系統中可能會存在一些類的屬性物件型別為該類本身，這種特殊的關聯關係稱為自關聯。例如：一個節點類(Node)的成員又是節點Node型別的物件，如圖4所示：

圖4 自關聯例項

圖4對應的Java程式碼片段如下：

public class Node {
private Node subNode;
……
}

(4) 多重性關聯

多重性關聯關係又稱為重數性(Multiplicity)關聯關係，表示兩個關聯物件在數量上的對應關係。在UML中，物件之間的多重性可以直接在關聯直線上用一個數字或一個數字範圍表示。

物件之間可以存在多種多重性關聯關係，常見的多重性表示方式如表1所示：

表1 多重性表示方式列表

例如：一個介面(Form)可以擁有零個或多個按鈕(Button)，但是一個按鈕只能屬於一個介面，因此，一個Form類的物件可以與零個或多個Button類的物件相關聯，但一個Button類的物件只能與一個Form類的物件關聯，如圖5所示：

圖5 多重性關聯例項

圖5對應的Java程式碼片段如下：

public class Form {
private Button[] buttons; //定義一個集合物件
……
}

public class Button {
……
}

(5) 聚合關係

聚合(Aggregation)關係表示整體與部分的關係。在聚合關係中，成員物件是整體物件的一部分，但是成員物件可以脫離整體物件獨立存在。在UML中，聚合關係用帶空心菱形的直線表示。例如：汽車發動機(Engine)是汽車(Car)的組成部分，但是汽車發動機可以獨立存在，因此，汽車和發動機是聚合關係，如圖6所示：

圖6 聚合關係例項

在程式碼實現聚合關係時，成員物件通常作為構造方法、Setter方法或業務方法的引數注入到整體物件中，圖6對應的Java程式碼片段如下：

public class Car {
	private Engine engine;

    //構造注入
	public Car(Engine engine) {
		this.engine = engine;
	}
    
    //設值注入
public void setEngine(Engine engine) {
    this.engine = engine;
}
……
}

public class Engine {
	……
} 

(6) 組合關係

組合(Composition)關係也表示類之間整體和部分的關係，但是在組合關係中整體物件可以控制成員物件的生命週期，一旦整體物件不存在，成員物件也將不存在，成員物件與整體物件之間具有同生共死的關係。在UML中，組合關係用帶實心菱形的直線表示。例如：人的頭(Head)與嘴巴(Mouth)，嘴巴是頭的組成部分之一，而且如果頭沒了，嘴巴也就沒了，因此頭和嘴巴是組合關係，如圖7所示：

圖7 組合關係例項

在程式碼實現組合關係時，通常在整體類的構造方法中直接例項化成員類，圖7對應的Java程式碼片段如下：

public class Head {
	private Mouth mouth;

	public Head() {
		mouth = new Mouth(); //例項化成員類
	}
……
}

public class Mouth {
	……
} 

類與類之間的關係（2）

2. 依賴關係

依賴(Dependency)關係是一種使用關係，特定事物的改變有可能會影響到使用該事物的其他事物，在需要表示一個事物使用另一個事物時使用依賴關係。大多數情況下，依賴關係體現在某個類的方法使用另一個類的物件作為引數。在UML中，依賴關係用帶箭頭的虛線表示，由依賴的一方指向被依賴的一方。例如：駕駛員開車，在Driver類的drive()方法中將Car型別的物件car作為一個引數傳遞，以便在drive()方法中能夠呼叫car的move()方法，且駕駛員的drive()方法依賴車的move()方法，因此類Driver依賴類Car，如圖1所示：

圖1 依賴關係例項

在系統實施階段，依賴關係通常通過三種方式來實現，第一種也是最常用的一種方式是如圖1所示的將一個類的物件作為另一個類中方法的引數，第二種方式是在一個類的方法中將另一個類的物件作為其區域性變數，第三種方式是在一個類的方法中呼叫另一個類的靜態方法。圖1對應的Java程式碼片段如下：

public class Driver {
	public void drive(Car car) {
		car.move();
	}
    ……
}

public class Car {
	public void move() {
		......
	}
    ……
}  

3. 泛化關係

泛化(Generalization)關係也就是繼承關係，用於描述父類與子類之間的關係，父類又稱作基類或超類，子類又稱作派生類。在UML中，泛化關係用帶空心三角形的直線來表示。在程式碼實現時，我們使用面向物件的繼承機制來實現泛化關係，如在Java語言中使用extends關鍵字、在C++/C#中使用冒號“：”來實現。例如：Student類和Teacher類都是Person類的子類，Student類和Teacher類繼承了Person類的屬性和方法，Person類的屬性包含姓名(name)和年齡(age)，每一個Student和Teacher也都具有這兩個屬性，另外Student類增加了屬性學號(studentNo)，Teacher類增加了屬性教師編號(teacherNo)，Person類的方法包括行走move()和說話say()，Student類和Teacher類繼承了這兩個方法，而且Student類還新增方法study()，Teacher類還新增方法teach()。如圖2所示：

圖2 泛化關係例項

圖2對應的Java程式碼片段如下：

//父類
public class Person {
protected String name;
protected int age;

public void move() {
        ……
}

    public void say() {
    ……
    }
}

//子類
public class Student extends Person {
private String studentNo;

public void study() {
    ……
    }
}

//子類
public class Teacher extends Person {
private String teacherNo;

public void teach() {
    ……
    }
}

4. 介面與實現關係

在很多面向物件語言中都引入了介面的概念，如Java、C#等，在介面中，通常沒有屬性，而且所有的操作都是抽象的，只有操作的宣告，沒有操作的實現。UML中用與類的表示法類似的方式表示介面，如圖3所示：

圖3 介面的UML圖示

介面之間也可以有與類之間關係類似的繼承關係和依賴關係，但是介面和類之間還存在一種實現(Realization)關係，在這種關係中，類實現了介面，類中的操作實現了介面中所宣告的操作。在UML中，類與介面之間的實現關係用帶空心三角形的虛線來表示。例如：定義了一個交通工具介面Vehicle，包含一個抽象操作move()，在類Ship和類Car中都實現了該move()操作，不過具體的實現細節將會不一樣，如圖4所示：

圖4 實現關係例項

實現關係在程式設計實現時，不同的面嚮物件語言也提供了不同的語法，如在Java語言中使用implements關鍵字，而在C++/C#中使用冒號“：”來實現。圖4對應的Java程式碼片段如下：

public interface Vehicle {
public void move();
}

public class Ship implements Vehicle {
public void move() {
    ……
    }
}

public class Car implements Vehicle {
public void move() {
    ……
    }
}

例項分析1——登入模組

某基於C/S的即時聊天系統登入模組功能描述如下：

使用者通過登入介面(LoginForm)輸入賬號和密碼，系統將輸入的賬號和密碼與儲存在資料庫(User)表中的使用者資訊進行比較，驗證使用者輸入是否正確，如果輸入正確則進入主介面(MainForm)，否則提示“輸入錯誤”。

根據以上描述繪製初始類圖。

參考解決方案：

參考類圖如下：

考慮到系統擴充套件性，在本例項中引入了抽象資料訪問介面IUserDAO，再將具體資料訪問物件注入到業務邏輯物件中，可通過配置檔案（如XML檔案）等方式來實現，將具體的資料訪問類類名儲存在配置檔案中，如果需要更換新的具體資料訪問物件，只需修改配置檔案即可，原有程式程式碼無須做任何修改。

類說明：

方法說明：

例項分析2——註冊模組

某基於Java語言的C/S軟體需要提供註冊功能，該功能簡要描述如下：

使用者通過註冊介面(RegisterForm)輸入個人資訊，使用者點選“註冊”按鈕後將輸入的資訊通過一個封裝使用者輸入資料的物件(UserDTO)傳遞給操作資料庫的資料訪問類，為了提高系統的擴充套件性，針對不同的資料庫可能需要提供不同的資料訪問類，因此提供了資料訪問類介面，如IUserDAO，每一個具體資料訪問類都是某一個數據訪問類介面的實現類，如OracleUserDAO就是一個專門用於訪問Oracle資料庫的資料訪問類。

根據以上描述繪製類圖。為了簡化類圖，個人資訊僅包括賬號(userAccount)和密碼(userPassword)，且介面類無需涉及介面細節元素。

參考解決方案：

在以上功能說明中，可以分析出該系統包括三個類和一個介面，這三個類分別是註冊介面類RegisterForm、使用者資料傳輸類UserDTO、Oracle使用者資料訪問類OracleUserDAO，介面是抽象使用者資料訪問介面IUserDAO。它們之間的關係如下：

(1) 在RegisterForm中需要使用UserDTO類傳輸資料且需要使用資料訪問類來操作資料庫，因此RegisterForm與UserDTO和IUserDAO之間存在關聯關係，在RegisterForm中可以直接例項化UserDTO，因此它們之間可以使用組合關聯。

(2) 由於資料庫型別需要靈活更換，因此在RegisterForm中不能直接例項化IUserDAO的子類，可以針對介面IUserDAO程式設計，再通過注入的方式傳入一個IUserDAO介面的子類物件（在本書後續章節中將學習如何具體實現），因此RegisterForm和IUserDAO之間具有聚合關聯關係。

(3) OracleUserDAO是實現了IUserDAO介面的子類，因此它們之間具有類與介面的實現關係。

(4) 在宣告IUserDAO介面的增加使用者資訊方法addUser()時，需要將在介面類中例項化的UserDTO物件作為引數傳遞進來，然後取出封裝在UserDTO物件中的資料插入資料庫，因此addUser()方法的函式原型可以定義為：public boolean addUser(UserDTO user)，在IUserDAO的方法addUser()中將UserDTO型別的物件作為引數，故IUserDAO與UserDTO存在依賴關係。

通過以上分析，該例項參考類圖如圖1所示：

圖1 註冊功能參考類圖

注意：在繪製類圖或其他UML圖形時，可以通過註釋(Comment)來對圖中的符號或元素進行一些附加說明，如果需要詳細說明類圖中的某一方法的功能或者實現過程，可以使用如圖2所示表示方式：

圖2 類圖註釋例項

例項分析3——售票機控制程式

某運輸公司決定為新的售票機開發車票銷售的控制軟體。圖I給出了售票機的面板示意圖以及相關的控制部件。

圖I 售票機面板示意圖

售票機相關部件的作用如下所述：

(1) 目的地鍵盤用來輸入行程目的地的程式碼（例如，200表示總站）。

(2) 乘客可以通過車票鍵盤選擇車票種類（單程票、多次往返票和座席種類）。

(3) 繼續/取消鍵盤上的取消按鈕用於取消購票過程，繼續按鈕允許乘客連續購買多張票。

(4) 顯示屏顯示所有的系統輸出和使用者提示資訊。

(5) 插卡口接受MCard（現金卡），硬幣口和紙幣槽接受現金。

(6) 印表機用於輸出車票。

(7) 所有部件均可實現自檢並恢復到初始狀態。

現採用面向物件方法開發該系統，使用UML進行建模，繪製該系統的初始類圖。

參考解決方案：

參考類圖如下：

類說明：

方法說明：