基本概念

類圖（Class Diagram）: 類圖是面向?qū)ο笙到y(tǒng)建模中最常用和最重要的圖，是定義其它圖的基礎。

類圖主要是用來顯示系統(tǒng)中的類、接口以及它們之間的靜態(tài)結構和關系的一種靜態(tài)模型。

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

在UML類圖中，常見的有以下幾種關系: 泛化（Generalization）, 實現(xiàn)（Realization），關聯(lián)（Association)，聚合（Aggregation，組合(Composition)，依賴(Dependency)

1. 泛化（Generalization)

【泛化關系】：是一種繼承關系，表示一般與特殊的關系，它指定了子類如何特化父類的所有特征和行為。例如：老虎是動物的一種，即有老虎的特性也有動物的共性。 

【箭頭指向】：帶三角箭頭的實線，箭頭指向父類

2. 實現(xiàn)（Realization）

【實現(xiàn)關系】：是一種類與接口的關系，表示類是接口所有特征和行為的實現(xiàn). 

【箭頭指向】：帶三角箭頭的虛線，箭頭指向接口

3. 關聯(lián)（Association)

【關聯(lián)關系】：是一種擁有的關系，它使一個類知道另一個類的屬性和方法；如：老師與學生，丈夫與妻子關聯(lián)可以是雙向的，也可以是單向的。雙向的關聯(lián)可以有兩個箭頭或者沒有箭頭，單向的關聯(lián)有一個箭頭。 

【代碼體現(xiàn)】：成員變量 

【箭頭及指向】：帶普通箭頭的實心線，指向被擁有者

上圖中，老師與學生是雙向關聯(lián)，老師有多名學生，學生也可能有多名老師。但學生與某課程間的關系為單向關聯(lián)，一名學生可能要上多門課程，課程是個抽象的東西他不擁有學生。

下圖為自身關聯(lián)：

4. 聚合（Aggregation）

【聚合關系】：是整體與部分的關系，且部分可以離開整體而單獨存在。如車和輪胎是整體和部分的關系，輪胎離開車仍然可以存在。

聚合關系是關聯(lián)關系的一種，是強的關聯(lián)關系；關聯(lián)和聚合在語法上無法區(qū)分，必須考察具體的邏輯關系。

【代碼體現(xiàn)】：成員變量 

【箭頭及指向】：帶空心菱形的實心線，菱形指向整體

5. 組合(Composition)

【組合關系】：是整體與部分的關系，但部分不能離開整體而單獨存在。如公司和部門是整體和部分的關系，沒有公司就不存在部門。

組合關系是關聯(lián)關系的一種，是比聚合關系還要強的關系，它要求普通的聚合關系中代表整體的對象負責代表部分的對象的生命周期。

【代碼體現(xiàn)】：成員變量

【箭頭及指向】：帶實心菱形的實線，菱形指向整體

6. 依賴(Dependency)

【依賴關系】：是一種使用的關系，即一個類的實現(xiàn)需要另一個類的協(xié)助，所以要盡量不使用雙向的互相依賴. 

【代碼表現(xiàn)】：局部變量、方法的參數(shù)或者對靜態(tài)方法的調(diào)用 

【箭頭及指向】：帶箭頭的虛線，指向被使用者

各種關系的強弱順序： 

泛化 = 實現(xiàn) > 組合 > 聚合 > 關聯(lián) > 依賴

下面這張UML圖，比較形象地展示了各種類圖關系：

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

UML實例分析

聯(lián)通客戶響應OSS。系統(tǒng)有故障單、業(yè)務開通、資源核查、割接、業(yè)務重保、網(wǎng)絡品質(zhì)性能等功能模塊?，F(xiàn)在我們抽出部分需求做為例子講解。

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

• 通知分為一般通知、割接通知、重保通知。這個是繼承關系。
• NoticeService和實現(xiàn)類NoticeServiceImpl是實現(xiàn)關系。
• NoticeServiceImpl通過save方法的參數(shù)引用Notice,是依賴關系。同時調(diào)用了BaseDao完成功能，也是依賴關系。
• 割接通知和故障單之間通過中間類(通知電路)關聯(lián)，是一般關聯(lián)。
• 重保通知和預案庫間是聚合關系。因為預案庫可以事先錄入，和重保通知沒有必然聯(lián)系，可以獨立存在。在系統(tǒng)中是手工從列表中選擇。刪除重保通知，不影響預案。
• 割接通知和需求單之間是聚合關系。同理，需求單可以獨立于割接通知存在。也就是說刪除割接通知，不影響需求單。
• 通知和回復是組合關系。因為回復不能獨立于通知存在。也就是說刪除通知，該條通知對應的回復也要級聯(lián)刪除。

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

重點講一下聚合和組合的關系：

聚合關系圖：

組合關系圖：

從代碼上看這兩種關系的區(qū)別在于：

構造函數(shù)不同

雁群類：

   public  class GooseGroup  
    {  
        public Goose goose;  
  
  
        public GooseGroup(Goose goose)  
        {  
            this.goose = goose;  
		}
	}

大雁類：

public class Goose  
{  
    public Wings wings;  
  
    public Goose()  
    {  
        wings=new Wings();  
    }  
}  

聚合關系的類里含有另一個類作為參數(shù)

**雁群類（GooseGroup）**的構造函數(shù)中要用到大雁（Goose）作為參數(shù)把值傳進來 大雁類（Goose）可以脫離雁群類而獨立存在

組合關系的類里含有另一個類的實例化

• 大雁類（Goose）在實例化之前 一定要先實例化翅膀類（Wings） 兩個類緊密耦合在一起 它們有相同的生命周期 翅膀類（Wings）不可以脫離大雁類（Goose）而獨立存在
• 信息的封裝性不同
• 在聚合關系中，客戶端可以同時了解雁群類和大雁類，因為他們都是獨立的
• 而在組合關系中，客戶端只認識大雁類，根本就不知道翅膀類的存在，因為翅膀類被嚴密的封裝在大雁類中。

總結

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論