UML圖中類之間的關係:依賴,泛化,關聯,聚合,組合,實現

類與類圖

1) 類(Class)封裝了資料和行為，是面向物件的重要組成部分，它是具有相同屬性、操作、關係的物件集合的總稱。

2) 在系統中，每個類具有一定的職責，職責指的是類所擔任的任務，即類要完成什麼樣的功能，要承擔什麼樣的義務。一個類可以有多種職責，設計得好的類一般只有一種職責，在定義類的時候，將類的職責分解成為類的屬性和操作（即方法）。

3) 類的屬性即類的資料職責，類的操作即類的行為職責

 

 

 一、依賴關係(Dependence)

 

依賴關係（Dependence）：假設A類的變化引起了B類的變化，則說名B類依賴於A類。

 

•  依賴關係(Dependency) 是一種使用關係，特定事物的改變有可能會影響到使用該事物的其他事物，在需要表示一個事物使用另一個事物時使用依賴關係。大多數情況下，依       賴關係體現在某個類的方法使用另一個類的物件作為引數。

•   在UML中，依賴關係用帶箭頭的虛線表示，由依賴的一方指向被依賴的一方。

1. public class Driver  
2. {  
3.     public void drive(Car car)  
4.     {  
5.         car.move();  
6.     }  
7.     ……  
8. }  
9. public class Car  
10. {  
11.     public void move()  
12.     {  
13.         ......  
14.     }  
15.     ……  
16. }  

 

 

依賴關係有如下三種情況：

1、A類是B類中的（某中方法的）區域性變數；

2、A類是B類方法當中的一個引數；

3、A類向B類傳送訊息，從而影響B類發生變化；

 

 

 二、泛化關係（Generalization）

 

泛化關係（Generalization）：A是B和C的父類，B,C具有公共類（父類）A，說明A是B,C的一般化（概括，也稱泛化）

 

•  泛化關係(Generalization)也就是繼承關係，也稱為“is-a-kind-of”關係，泛化關係用於描述父類與子類之間的關係，父類又稱作基類或超類，子類又稱作派生類。在UML中，泛      化關係用帶空心三角形的直線來表示。

•  在程式碼實現時，使用面向物件的繼承機制來實現泛化關係，如在Java語言中使用extends關鍵字、在C++/C#中使用冒號“：”來實現。 

 

 

 

1. public class Person   
2. {  
3.     protected String name;  
4.     protected int age;  
5.     public void move()   
6.     {  
7.         ……  
8.     }  
9.     public void say()   
10.    {  
11.         ……  
12.     }  
13. }  
14. public class Student extends Person   
15. {  
16.     private String studentNo;  
17.     public void study()   
18.     {  
19.         ……  
20.     }  
21. }  

 

 

在UML當中，對泛化關係有三個要求：

1、子類與父類應該完全一致，父類所具有的屬性、操作，子類應該都有；

2、子類中除了與父類一致的資訊以外，還包括額外的資訊；

3、可以使用父類的例項的地方，也可以使用子類的例項；

 

 三、關聯關係（Association）

 

關聯關係（Association）:類之間的聯絡，如客戶和訂單，每個訂單對應特定的客戶，每個客戶對應一些特定的訂單，再如籃球隊員與球隊之間的關聯（下圖所示）。

 

其中，關聯兩邊的"employee"和“employer”標示了兩者之間的關係，而數字表示兩者的關係的限制，是關聯兩者之間的多重性。通常有“*”（表示所有，不限），“1”（表示有且僅有一個），“0...”（表示0個或者多個），“0，1”（表示0個或者一個），“n...m”(表示n到m個都可以),“m...*”（表示至少m個）。

 

•  關聯關係(Association) 是類與類之間最常用的一種關係，它是一種結構化關係，用於表示一類物件與另一類物件之間有聯絡。

•  在UML類圖中，用實線連線有關聯的物件所對應的類，在使用Java、C#和C++等程式語言實現關聯關係時，通常將一個類的物件作為另一個類的屬性。

•  在使用類圖表示關聯關係時可以在關聯線上標註角色名。

 

1)  雙向關聯: 預設情況下，關聯是雙向的。

 

 

1. public class Customer  
2. {  
3.     private Product[] products;  
4.     ……  
5. }  
6. public class Product  
7. {  
8.     private Customer customer;  
9.     ……  
10. }  

 

 

2 ) 單向關聯:類的關聯關係也可以是單向的，單向關聯用帶箭頭的實線表示.

1. public class Customer  
2. {  
3.     private Address address;  
4.     ……  
5. }  
6.   
7. public class Address  
8. {  
9.     ……  
10. }  

 

3) 自關聯: 在系統中可能會存在一些類的屬性物件型別為該類本身，這種特殊的關聯關係稱為自關聯。

1. public class Node  
2. {  
3.     private Node subNode;  
4.     ……  
5. }   

 

4) 重數性關聯: 重數性關聯關係又稱為多重性關聯關係(Multiplicity)，表示一個類的物件與另一個類的物件連線的個數。在UML中多重性關係可以直接在關聯直線上增加一個數字表示與之對應的另一個類的物件的個數。

表示方式	多重性說明
1..1	表示另一個類的一個物件只與一個該類物件有關係
0..*	表示另一個類的一個物件與零個或多個該類物件有關係
1..*	表示另一個類的一個物件與一個或多個該類物件有關係
0..1	表示另一個類的一個物件沒有或只與一個該類物件有關係
m..n	表示另一個類的一個物件與最少m、最多n個該類物件有關係 (m<=n)

1. public class Form  
2. {  
3.     private Button buttons[];  
4.     ……  
5. }   
6. public class Button  
7. {  
8.     …  
9. }  

 

 

 

 四、聚合關係（Aggregation）

 

聚合關係（Aggregation）:表示的是整體和部分的關係，整體與部分 可以分開.

 

•  聚合關係(Aggregation) 表示一個整體與部分的關係。通常在定義一個整體類後，再去分析這個整體類的組成結構，從而找出一些成員類，該整體類和成員類之間就形成了聚合   關係。

•  在聚合關係中，成員類是整體類的一部分，即成員物件是整體物件的一部分，但是成員物件可以脫離整體物件獨立存在。在UML中，聚合關係用帶空心菱形的直線表示。 

 

 

1. public class Car  
2. {  
3.     private Engine engine;  
4.     public Car(Engine engine)  
5.    {  
6.         this.engine = engine;  
7.     }  
8.       
9.     public void setEngine(Engine engine)  
10.     {  
11.         this.engine = engine;  
12.     }  
13.     ……  
14. }  
15. public class Engine  
16. {  
17.     ……  
18. }  

 

 

如：電話機包括一個話筒

       電腦包括鍵盤、顯示器，一臺電腦可以和多個鍵盤、多個顯示器搭配，確定鍵盤和顯示器是可以和主機分開的，主機可以選擇其他的鍵盤、顯示器組成電腦；

 五、組合關係（Composition）

組合關係（Composition）:也是整體與部分的關係，但是整體與部分不可以分開.

 

•  組合關係(Composition)也表示類之間整體和部分的關係，但是組合關係中部分和整體具有統一的生存期。一旦整體物件不存在，部分物件也將不存在，部分物件與整體物件之    間具有同生共死的關係。

•  在組合關係中，成員類是整體類的一部分，而且整體類可以控制成員類的生命週期，即成員類的存在依賴於整體類。在UML中，組合關係用帶實心菱形的直線表示。

 

 

 

1. public class Head  
2. {  
3.     private Mouth mouth;  
4.     public Head()  
5.     {  
6.     mouth = new Mouth();  
7.     }  
8.     ……  
9. }  
10.   
11. public class Mouth  
12. {  
13.     ……  
14. }  

 

 

如：公司和部門，部門是部分，公司是整體，公司A的財務部不可能和公司B的財務部對換，就是說，公司A不能和自己的財務部分開； 人與人的心臟.

 

 六、實現關係（Implementation)

 

實現關係（Implementation）：是用來規定介面和實線介面的類或者構建結構的關係，介面是操作的集合，而這些操作就用於規定類或者構建的一種服務。

 

• 介面之間也可以有與類之間關係類似的繼承關係和依賴關係，但是介面和類之間還存在一種實現關係(Realization)，在這種關係中，類實現了介面，類中的操作實現了介面中所     宣告的操作。在UML中，類與介面之間的實現關係用帶空心三角形的虛線來表示。

 

1. public interface Vehicle   
2. {  
3.     public void move();  
4. }  
5. public class Ship implements Vehicle  
6. {  
7.     public void move()   
8.     {  
9.     ……  
10.     }  
11. }  
12. public class Car implements Vehicle  
13. {  
14.     public void move()   
15.     {  
16.     ……  
17.     }  
18. }  
19.  

 

UML的9中圖例概述

 

作為一種建模語言，UML的定義包括UML語義和UML表示法兩個部分。

l UML語義：描述基於UML的精確元模型定義。

l UML表示法：定義UML符號的表示法，為開發者或開發工具使用這些圖形符號和文字語法為系統建模提供了標準。這些圖形符號和文字所表達的是應用級的模型，在語義上它是UML元模型的例項。

標準建模語言UML可以由下列5類圖來定義。

l 用例圖：從使用者角度描述系統功能，並指出各功能的操作者。

l 靜態圖：包括類圖和物件圖。類圖描述系統中類的靜態結構，不僅定義系統中的類，表示類之間的聯絡，如關聯、依賴、聚合等，也包括類的屬性和操作，類圖描述的是一種靜態關係，在系統的整個生命週期都是有效的。物件圖是類圖的例項，幾乎使用與類圖完全相同的標識。一個物件圖是類圖的一個例項。由於物件存在生命週期，因此物件圖只能在系統某一時間段存在。

l 行為圖：描述系統的動態模型和組成物件間的互動關係，包括狀態圖和活動圖。狀態圖描述類的物件所有可能的狀態以及事件發生時狀態的轉移條件，狀態圖是對類圖的補充，活動圖描述滿足用例要求所要進行的活動以及活動間的約束關係，有利於識別並進行活動。

l 互動圖：描述物件間的互動關係，包括時序圖和協作圖。時序圖顯示物件之間的動態合作關係，它強調物件之間訊息傳送的順序，同時顯示物件之間的互動；協作圖描述物件間的協作關係，協作圖跟時序圖相似，顯示物件間的動態合作關係。除顯示資訊交換外，協作圖還顯示物件以及它們之間的關係。如果強調時間和順序，則使用時序圖；如果強調上下級關係，則選擇協作圖。

l 實現圖：包括元件圖和部署圖。元件圖描述程式碼部件的物理結構及各部件之間的依賴關係，元件圖有助於分析和理解部件之間的相互影響程度；部署圖定義系統中軟硬體的物理體系結構。

採用UML來設計系統時，第一步是描述需求；第二步根據需求建立系統的靜態模型，以構造系統的結構；第三步是描述系統的行為。其中在第一步與第二步中所建立的模型都是靜態的，包括用例圖、類圖、物件圖、元件圖和部署圖等5種圖形，是標準建模語言UML的靜態建模機制。其中第三步中所建立的模型或者可以執行，或者表示執行時的時序狀態或互動關係。它包括狀態圖、活動圖、時序圖和協作圖等4種圖形，是標準建模語言UML的動態建模機制。

 

首先對UML中的各個圖的功用做一個簡單介紹：

1、用例圖

    描述角色以及角色與用例之間的連線關係。說明的是誰要使用系統，以及他們使用該系統可以做些什麼。一個用例圖包含了多個模型元素，如系統、參與者和用例，並且顯示了這些元素之間的各種關係，如泛化、關聯和依賴。

2、類圖

    類圖是描述系統中的類，以及各個類之間的關係的靜態檢視。能夠讓我們在正確編寫程式碼以前對系統有一個全面的認識。類圖是一種模型型別，確切的說，是一種靜態模型型別。

3、物件圖

    與類圖極為相似，它是類圖的例項，物件圖顯示類的多個物件例項，而不是實際的類。它描述的不是類之間的關係，而是物件之間的關係。

4、活動圖

    描述用例要求所要進行的活動，以及活動間的約束關係，有利於識別並行活動。能夠演示出系統中哪些地方存在功能，以及這些功能和系統中其他元件的功能如何共同滿足前面使用用例圖建模的商務需求。

5、狀態圖

    描述類的物件所有可能的狀態，以及事件發生時狀態的轉移條件。可以捕獲物件、子系統和系統的生命週期。他們可以告知一個物件可以擁有的狀態，並且事件(如訊息的接收、時間的流逝、錯誤、條件變為真等)會怎麼隨著時間的推移來影響這些狀態。一個狀態圖應該連線到所有具有清晰的可標識狀態和複雜行為的類；該圖可以確定類的行為，以及該行為如何根據當前的狀態變化，也可以展示哪些事件將會改變類的物件的狀態。狀態圖是對類圖的補充。

6、序列圖（順序圖）

    序列圖是用來顯示你的參與者如何以一系列順序的步驟與系統的物件互動的模型。順序圖可以用來展示物件之間是如何進行互動的。順序圖將顯示的重點放在訊息序列上，即強調訊息是如何在物件之間被髮送和接收的。

7、協作圖

    和序列圖相似，顯示物件間的動態合作關係。可以看成是類圖和順序圖的交集，協作圖建模物件或者角色，以及它們彼此之間是如何通訊的。如果強調時間和順序，則使用序列圖；如果強調上下級關係，則選擇協作圖；這兩種圖合稱為互動圖。

8、構件圖 （元件圖）

    描述程式碼構件的物理結構以及各種構建之間的依賴關係。用來建模軟體的元件及其相互之間的關係，這些圖由構件標記符和構件之間的關係構成。在元件圖中，構件時軟體單個組成部分，它可以是一個檔案，產品、可執行檔案和指令碼等。

9、部署圖 （配置圖）

    是用來建模系統的物理部署。例如計算機和裝置，以及它們之間是如何連線的。部署圖的使用者是開發人員、系統整合人員和測試人員。

幾種圖的區別：

一：這九種模型圖各有側重，

1:用例圖側重描述使用者需求，

2:類圖側重描述系統具體實現；

二：描述的方面都不相同，

1:類圖描述的是系統的結構，

2:序列圖描述的是系統的行為；

三：抽象的層次也不同，

1：構件圖描述系統的模組結構，抽象層次較高，

2：類圖是描述具體模組的結構，抽象層次一般，

3：物件圖描述了具體的模組實現，抽象層次較低。

 

在有的文獻書籍中，將這九種模型圖分為三大類：

結構分類、動態行為和模型管理：

1：結構分類包括用例圖、類圖、物件圖、構件圖和部署圖，

2：動態行為包括狀態圖、活動圖、順序圖和協作圖，

3：模型管理則包含類圖。

 

 

畫圖說明

UML(統一建模語言)：是面向物件的視覺化建模的一種語言。是資料庫設計過程中，在E-R圖（實體-聯絡圖）的設計後的進一步建模。
UML中有3種構造塊：事物、關係和圖，事物是對模型中最具有代表性的成分的抽象；關係是把事物結合在一起；圖聚集了相關的的事物。具體關係圖示如下：

說明：
構件事物是名詞，是模型的靜態部分。
行為事物是動態部分，表示行為。
分組事物是組織部分。
註釋事物是解釋部分。

依賴：一個事物變化會引起另一個事物變化。
聚集：特殊的關聯，描述整體與部分的組合關係。
泛化：是一種特殊與一般的關係，如子元素（特殊）與父元素（一般），箭頭指向父元素。
實現：類元之間的關係，其中一個類元指定了由另一個類元保證執行的契約。一般用在介面和實現他們的類之間或用例和實現它們的協作之間。

UML提供9種檢視：類圖、物件圖，用例圖，序列圖、協作圖，狀態圖、活動圖，構件圖和部署圖。

在UML系統開發中有三個主要的模型：

功能模型: 從使用者的角度展示系統的功能，包括用例圖。
物件模型: 採用物件，屬性，操作，關聯等概念展示系統的結構和基礎，包括類圖。
動態模型: 展現系統的內部行為。 包括序列圖，活動圖，狀態圖。

下面具體說明：

1.類圖：描述一組物件、介面、協作等事物之間的關係。如下圖(摘自網路)：

注：#表示protected，+表示Public，-表示private

 

2.物件圖：描述一組物件之間的關係，是具有具體屬性值和行為的一個具體事物，其是類圖中所建事物例項的靜態快照，其與類圖的主要區別是一個是抽象的,而物件圖是具體的。如下圖(摘自網路)：

3.用例圖：描述一組用例、參與者以及它們之間的關係，其展示的是該系統在它的外面環境中所提供的外部可見服務。如下圖(摘自網路)：

4.互動圖：包括序列圖（順序圖）和協作圖，兩者對應，順序圖是強調訊息時間順序，有物件生命線和控制焦點。協作圖是強調接收和傳送訊息的物件的結構組織，有路徑和順序號。如下圖(摘自網路)：

序列圖：

協作圖：

5.狀態圖：展示了一個狀態機，由狀態、轉換、事件和活動組成。強調事件行為的順序。如下圖(摘自網路)：

6.活動圖：是一種特殊的狀態圖，實現一個活動到另一個活動的流程。如下圖(摘自網路)：

7.構件圖和部署圖：構件圖展示一組構件之間的組織和依賴關係，並以全域性的模型展示出來。部署圖是構件的配置及描述系統如何在硬體上部署。如下圖(摘自網路)：

 

 

 

 

UML中的幾種關係詳細解析

 

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

 　　1. 泛化（Generalization）

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

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

　　2. 實現（Realization）

　　【實現關係】：是一種類與介面的關係，表示類是介面所有特徵和行為的實現.

　　【箭頭指向】：帶三角箭頭的虛線，箭頭指向介面

　　3. 關聯（Association)

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

　　【程式碼體現】：成員變數

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

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

　　下圖為自身關聯： 

　　4. 聚合（Aggregation）

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

　　聚合關係是關聯關係的一種，是強的關聯關係；關聯和聚合在語法上無法區分，必須考察具體的邏輯關係。

　　【程式碼體現】：成員變數

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

　　5. 組合(Composition)

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

       組合關係是關聯關係的一種，是比聚合關係還要強的關係，它要求普通的聚合關係中代表整體的物件負責代表部分的物件的生命週期。

【程式碼體現】：成員變數

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

　　6. 依賴(Dependency)

　　【依賴關係】：是一種使用的關係，即一個類的實現需要另一個類的協助，所以要儘量不使用雙向的互相依賴.

　　【程式碼表現】：區域性變數、方法的引數或者對靜態方法的呼叫

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

　　各種關係的強弱順序：

　　泛化 = 實現 > 組合 > 聚合 > 關聯 > 依賴 

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

 

 

UML幾種圖介紹

 

 

用例圖

　　用例圖描述了系統提供的一個功能單元。用例圖的主要目的是幫助開發團隊以一種視覺化的方式理解系統的功能需求，包括基於基本流程的"角色"（actors，也就是與系統互動的其他實體）關係，以及系統內用例之間的關係。用例圖一般表示出用例的組織關係 —— 要麼是整個系統的全部用例，要麼是完成具有功能（例如，所有安全管理相關的用例）的一組用例。要在用例圖上顯示某個用例，可繪製一個橢圓，然後將用例的名稱放在橢圓的中心或橢圓下面的中間位置。要在用例圖上繪製一個角色（表示一個系統使用者），可繪製一個人形符號。角色和用例之間的關係使用簡單的線段來描述，如圖1所示。

 

圖1：示例用例圖

　　圖字（從上到下）：CD銷售系統；檢視樂隊CD的銷售統計；樂隊經理；檢視Billboard 200排行榜報告；唱片經理；檢視特定CD的銷售統計；檢索最新的Billboard 200排行榜報告；排行榜報告服務

　　用例圖通常用於表達系統或者系統範疇的高階功能。如圖1所示，可以很容易看出該系統所提供的功能。這個系統允許樂隊經理檢視樂隊CD的銷售統計報告以及Billboard 200排行榜報告。它也允許唱片經理檢視特定CD的銷售統計報告和這些CD在Billboard 200排行榜的報告。這個圖還告訴我們，系統將通過一個名為"排行榜報告服務"的外部系統提供Billboard排行榜報告。

　　此外，在用例圖中，沒有列出的用例表明了該系統不能完成的功能。例如，它不能提供給樂隊經理收聽Billboard 200上不同專輯中的歌曲的途徑 —— 也就是說，系統沒有引用一個叫做"收聽Billboard 200上的歌曲"的用例。這種缺少不是一件小事。在用例圖中提供清楚的、簡要的用例描述，專案贊助商就很容易看出系統是否提供了必須的功能。

　　類圖

　　類圖表示不同的實體（人、事物和資料）如何彼此相關；換句話說，它顯示了系統的靜態結構。類圖可用於表示邏輯類，邏輯類通常就是業務人員所談及的事物種類 —— 搖滾樂隊、CD、廣播劇；或者貸款、住房抵押、汽車信貸以及利率。類圖還可用於表示實現類，實現類就是程式設計師處理的實體。實現類圖或許會與邏輯類圖顯示一些相同的類。然而，實現類圖不會使用相同的屬性來描述，因為它很可能具有對諸如Vector和HashMap這種事物的引用。

　　類在類圖上使用包含三個部分的矩形來描述，如圖2所示。最上面的部分顯示類的名稱，中間部分包含類的屬性，最下面的部分包含類的操作（或者說"方法"）。

圖2：類圖中的示例類物件

　　根據我的經驗，幾乎每個開發人員都知道這個類圖是什麼，但是我發現大多數程式設計師都不能正確地描述類的關係。對於像圖3這樣的類圖，您應該使用帶有頂點指向父類的箭頭的線段來繪製繼承關係1，並且箭頭應該是一個完全的三角形。如果兩個類都彼此知道對方，則應該使用實線來表示關聯關係；如果只有其中一個類知道該關聯關係，則使用開箭頭表示。

圖3：一個完整的類圖，包括了圖2所示的類物件

　　在圖3中，我們同時看到了繼承關係和兩個關聯關係。CDSalesReport類繼承自Report類。一個CDSalesReport類與一個CD類關聯，但是CD類並不知道關於CDSalesReport類的任何資訊。CD類和Band類都彼此知道對方，兩個類彼此都可以與一個或者多個對方類相關聯。

　　一個類圖可以整合其他許多概念，這將在本系列文章的後續文章中介紹。

　　序列圖

　　序列圖顯示具體用例（或者是用例的一部分）的詳細流程。它幾乎是自描述的，並且顯示了流程中不同物件之間的呼叫關係，同時還可以很詳細地顯示對不同物件的不同調用。

　　序列圖有兩個維度：垂直維度以發生的時間順序顯示訊息/呼叫的序列；水平維度顯示訊息被髮送到的物件例項。

　　序列圖的繪製非常簡單。橫跨圖的頂部，每個框（參見圖4）表示每個類的例項（物件）。在框中，類例項名稱和類名稱之間用空格/冒號/空格來分隔，例如，myReportGenerator : ReportGenerator。如果某個類例項向另一個類例項傳送一條訊息，則繪製一條具有指向接收類例項的開箭頭的連線，並把訊息/方法的名稱放在連線上面。對於某些特別重要的訊息，您可以繪製一條具有指向發起類例項的開箭頭的虛線，將返回值標註在虛線上。就我而言，我總喜歡繪製出包括返回值的虛線，這些額外的資訊可以使得序列圖更易於閱讀。

　　閱讀序列圖也非常簡單。從左上角啟動序列的"驅動"類例項開始，然後順著每條訊息往下閱讀。記住：雖然圖4所示的例子序列圖顯示了每條被髮送訊息的返回訊息，但這只是可選的。

圖4：一個示例序列圖

　　通過閱讀圖4中的示例序列圖，您可以明白如何建立一個CD銷售報告（CD Sales Report）。其中的aServlet物件表示驅動類例項。aServlet向名為gen的ReportGenerator類例項傳送一條訊息。該訊息被標為generateCDSalesReport，表示ReportGenerator物件實現了這個訊息處理程式。進一步理解可發現，generateCDSalesReport訊息標籤在括號中包括了一個cdId，表明aServlet隨該訊息傳遞一個名為cdId的引數。當gen例項接收到一條generateCDSalesReport訊息時，它會接著呼叫CDSalesReport類，並返回一個aCDReport的例項。然後gen例項對返回的aCDReport例項進行呼叫，在每次訊息呼叫時向它傳遞引數。在該序列的結尾，gen例項向它的呼叫者aServlet返回一個aCDReport。

　　請注意：圖4中的序列圖相對於典型的序列圖來說太詳細了。然而，我認為它才是足夠易於理解的，並且它顯示瞭如何表示巢狀的呼叫。對於初級開發人員來說，有時把一個序列分解到這種詳細程度是很有必要的，這有助於他們理解相關的內容。

　　狀態圖

　　狀態圖表示某個類所處的不同狀態和該類的狀態轉換資訊。有人可能會爭論說每個類都有狀態，但不是每個類都應該有一個狀態圖。只對"感興趣的"狀態的類（也就是說，在系統活動期間具有三個或更多潛在狀態的類）才進行狀態圖描述。

　　如圖5所示，狀態圖的符號集包括5個基本元素：初始起點，它使用實心圓來繪製；狀態之間的轉換，它使用具有開箭頭的線段來繪製；狀態，它使用圓角矩形來繪製；判斷點，它使用空心圓來繪製；以及一個或者多個終止點，它們使用內部包含實心圓的圓來繪製。要繪製狀態圖，首先繪製起點和一條指向該類的初始狀態的轉換線段。狀態本身可以在圖上的任意位置繪製，然後只需使用狀態轉換線條將它們連線起來。

 圖5：顯示類通過某個功能系統的各種狀態的狀態圖

　　圖5中的狀態圖顯示了它們可以表達的一些潛在資訊。例如，從中可以看出貸款處理系統最初處於Loan Application狀態。當批准前（pre-approval）過程完成時，根據該過程的結果，或者轉到Loan Pre-approved狀態，或者轉到Loan Rejected狀態。這個判斷（它是在轉換過程期間做出的）使用一個判斷點來表示 —— 即轉換線條間的空心圓。通過該狀態圖可知，如果沒有經過Loan Closing狀態，貸款不可能從Loan Pre-Approved狀態進入Loan in Maintenance狀態。而且，所有貸款都將結束於Loan Rejected或者Loan in Maintenance狀態。

　　活動圖

　　活動圖表示在處理某個活動時，兩個或者更多類物件之間的過程控制流。活動圖可用於在業務單元的級別上對更高級別的業務過程進行建模，或者對低級別的內部類操作進行建模。根據我的經驗，活動圖最適合用於對較高級別的過程建模，比如公司當前在如何運作業務，或者業務如何運作等。這是因為與序列圖相比，活動圖在表示上"不夠技術性的"，但有業務頭腦的人們往往能夠更快速地理解它們。

　　活動圖的符號集與狀態圖中使用的符號集類似。像狀態圖一樣，活動圖也從一個連線到初始活動的實心圓開始。活動是通過一個圓角矩形（活動的名稱包含在其內）來表示的。活動可以通過轉換線段連線到其他活動，或者連線到判斷點，這些判斷點連線到由判斷點的條件所保護的不同活動。結束過程的活動連線到一個終止點（就像在狀態圖中一樣）。作為一種選擇，活動可以分組為泳道（swimlane），泳道用於表示實際執行活動的物件，如圖6所示。

 

圖6：活動圖，具有兩個泳道，表示兩個物件的活動控制：樂隊經理，以及報告工具

　　圖字（沿箭頭方向）：樂隊經理；報告工具；選擇"檢視樂隊的銷售報告"；檢索該樂隊經理所管理的樂隊；顯示報告條件選擇螢幕；選擇要檢視其銷售報告的樂隊；從銷售資料庫檢索銷售資料；顯示銷售報告。

　　該活動圖中有兩個泳道，因為有兩個物件控制著各自的活動：樂隊經理和報告工具。整個過程首先從樂隊經理選擇檢視他的樂隊銷售報告開始。然後報告工具檢索並顯示他管理的所有樂隊，並要求他從中選擇一個樂隊。在樂隊經理選擇一個樂隊之後，報告工具就檢索銷售資訊並顯示銷售報告。該活動圖表明，顯示報告是整個過程中的最後一步。

　　元件圖

　　元件圖提供系統的物理檢視。它的用途是顯示系統中的軟體對其他軟體元件（例如，庫函式）的依賴關係。元件圖可以在一個非常高的層次上顯示，從而僅顯示粗粒度的元件，也可以在元件包層次2上顯示。

　　元件圖的建模最適合通過例子來描述。圖7顯示了4個元件：Reporting Tool、Billboard Service、Servlet 2.2 API和JDBC API。從Reporting Tool元件指向Billboard Service、Servlet 2.2 API和JDBC API元件的帶箭頭的線段，表示Reporting Tool依賴於那三個元件。

圖7：元件圖顯示了系統中各種軟體元件的依賴關係

　　部署圖

　　部署圖表示該軟體系統如何部署到硬體環境中。它的用途是顯示該系統不同的元件將在何處物理地執行，以及它們將如何彼此通訊。因為部署圖是對物理執行情況進行建模，系統的生產人員就可以很好地利用這種圖。

　　部署圖中的符號包括元件圖中所使用的符號元素，另外還增加了幾個符號，包括節點的概念。一個節點可以代表一臺物理機器，或代表一個虛擬機器器節點（例如，一個大型機節點）。要對節點進行建模，只需繪製一個三維立方體，節點的名稱位於立方體的頂部。所使用的命名約定與序列圖中相同：[例項名稱] : [例項型別]（例如，"w3reporting.myco.com : Application Server"）。

　　圖8：部署圖

　　圖字：由於Reporting Tool元件繪製在IBM WebSphere內部，後者又繪製在節點w3.reporting.myco.com內部，因而我們知道，使用者將通過執行在本地機器上的瀏覽器來訪問Reporting Tool，瀏覽器通過公司intranet上的HTTP協議與Reporting Tool建立連線。

　　圖8中的部署圖表明，使用者使用執行在本地機器上的瀏覽器訪問Reporting Tool，並通過公司intranet上的HTTP協議連線到Reporting Tool元件。這個工具實際執行在名為w3reporting.myco.com的Application Server上。這個圖還表明Reporting Tool元件繪製在IBM WebSphere內部，後者又繪製在w3.reporting.myco.com節點內部。Reporting Tool使用Java語言通過IBM DB2資料庫的JDBC介面連線到它的報告資料庫上，然後該介面又使用本地DB2通訊方式，與執行在名為db1.myco.com的伺服器上實際的DB2資料庫通訊。除了與報告資料庫通訊外，Report Tool元件還通過HTTPS上的SOAP與Billboard Service進行通訊。

　　結束語

　　儘管本文僅提供了對統一建模語言UML的簡要介紹，但還是鼓勵大家把從這裡學到的基本資訊應用到自己的專案中，同時更深入地鑽研UML。已經有多種軟體工具可以幫助您把UML圖整合到軟體開發過程中，不過即使沒有自動化的工具，您也可以使用白板上的標記或者紙和筆來手工繪製UML圖，仍然會獲益匪淺。

 

 

UML之用例圖解析

 

 

用例圖主要用來描述“使用者、需求、系統功能單元”之間的關係。它展示了一個外部使用者能夠觀察到的系統功能模型圖。

　　【用途】：幫助開發團隊以一種視覺化的方式理解系統的功能需求。

　　用例圖所包含的元素如下：

　　1. 參與者(Actor)

　　表示與您的應用程式或系統進行互動的使用者、組織或外部系統。用一個小人表示。

　　2. 用例(Use Case)

 　　用例就是外部可見的系統功能，對系統提供的服務進行描述。用橢圓表示。

　　3. 子系統(Subsystem)

　　用來展示系統的一部分功能，這部分功能聯絡緊密。

　　4. 關係

　　用例圖中涉及的關係有：關聯、泛化、包含、擴充套件。

　　如下表所示：

　　a. 關聯(Association)

　　表示參與者與用例之間的通訊，任何一方都可傳送或接受訊息。

　　【箭頭指向】：指向訊息接收方

　　b. 泛化(Inheritance)

　　就是通常理解的繼承關係，子用例和父用例相似，但表現出更特別的行為；子用例將繼承父用例的所有結構、行為和關係。子用例可以使用父用例的一段行為，也可以過載它。父用例通常是抽象的。

　　【箭頭指向】：指向父用例

　　c. 包含(Include)

　　包含關係用來把一個較複雜用例所表示的功能分解成較小的步驟。

　　【箭頭指向】：指向分解出來的功能用例z

　　d. 擴充套件(Extend)

　　擴充套件關係是指用例功能的延伸，相當於為基礎用例提供一個附加功能。

　　【箭頭指向】：指向基礎用例

　　e. 依賴(Dependency)

　　以上4種關係，是UML定義的標準關係。但VS2010的用例模型圖中，添加了依賴關係，用帶箭頭的虛線表示，表示源用例依賴於目標用例。

　　【箭頭指向】：指向被依賴項

　　5. 專案(Artifact)

　　用例圖雖然是用來幫助人們形象地理解功能需求，但卻沒多少人能夠通看懂它。很多時候跟使用者交流甚至用Excel都比用例圖強，VS2010中引入了“專案”這樣一個元素，以便讓開發人員能夠在用例圖中連結一個普通文件。

　　用依賴關係把某個用例依賴到專案上：

　　然後把專案-》屬性 的Hyperlink設定到你的文件上；

　　這樣當你在用例圖上雙擊專案時，就會開啟相關聯的文件。

　　6. 註釋(Comment)

　　包含(include)、擴充套件(extend)、泛化(Inheritance) 的區別：

　　條件性：泛化中的子用例和include中的被包含的用例會無條件發生，而extend中的延伸用例的發生是有條件的；

　　直接性：泛化中的子用例和extend中的延伸用例為參與者提供直接服務，而include中被包含的用例為參與者提供間接服務。

　　對extend而言，延伸用例並不包含基礎用例的內容，基礎用例也不包含延伸用例的內容。

　　對Inheritance而言，子用例包含基礎用例的所有內容及其和其他用例或參與者之間的關係；

　　一個用例圖示例：

　　牢騷：

　　感覺用例圖還不成熟，並不能很好地表達系統的需求， 沒有UML背景的使用者幾乎不知道畫的是些什麼。

　　其次，包含關係、擴充套件關係的箭頭符號竟然是同樣的箭頭，僅靠上方寫個文字來加以區別，翻譯成其他語言的話，幾乎就不知道代表什麼意思。擴充套件關係的箭頭朝向也很難理解，為何要指向基用例，而不指向擴充套件用例。

　　VS2010新增的“專案”元素，是個很好的創新，能夠在用例圖中關聯word, excel這些文件。但為什麼不把這些功能直接整合到用例裡面，雙擊用例就彈出一份文件豈不更容易理解，非要畫蛇添足地加一個元件，僅僅為了提供個連結功能。 

　　用例描述表：

　　鑑於用列圖並不能清楚地表達功能需求，開發中大家通常用描述表來補充某些不易表達的用例，下圖的表給大家提供一個參考：

 

 

UML之序列圖解析

序列圖主要用於展示物件之間互動的順序。

　　序列圖將互動關係表示為一個二維圖。縱向是時間軸，時間沿豎線向下延伸。橫向軸代表了在協作中各獨立物件的類元角色。類元角色用生命線表示。當物件存在時，角色用一條虛線表示，當物件的過程處於啟用狀態時，生命線是一個雙道線。

　　訊息用從一個物件的生命線到另一個物件生命線的箭頭表示。箭頭以時間順序在圖中從上到下排列。 

　　序列圖中涉及的元素：

　　1. 生命線：

　　生命線名稱可帶下劃線。當使用下劃線時，意味著序列圖中的生命線代表一個類的特定例項。

　　2. 同步訊息

　　傳送人在它繼續之前，將等待同步訊息響應。

　　 

　　3. 非同步訊息

　　在傳送方繼續之前，無需等待響應的訊息。

　　4. 註釋

　　5. 約束

　　約束的符號很簡單；格式是: [Boolean Test]

　　6. 組合片段

　　組合片段用來解決互動執行的條件及方式。它允許在序列圖中直接表示邏輯元件，用於通過指定條件或子程序的應用區域，為任何生命線的任何部分定義特殊條件和子程序。

　　常用的組合片段有：

　　抉擇（Alt）

　　抉擇用來指明在兩個或更多的訊息序列之間的互斥的選擇，相當於經典的if..else..。

　　抉擇在任何場合下只發生一個序列。 可以在每個片段中設定一個臨界來指示該片段可以執行的條件。else 的臨界指示其他任何臨界都不為 True 時應執行的片段。如果所有臨界都為 False 並且沒有 else，則不執行任何片段。

　　選項（Opt）

　　包含一個可能發生或不發生的序列

　　迴圈（Loop）

　　片段重複一定次數。 可以在臨界中指示片段重複的條件。

　　並行（Par）

　　下表列出了常用的組合片段：

片段型別	名稱	說明
Opt	選項	包含一個可能發生或可能不發生的序列。 可以在臨界中指定序列發生的條件。
Alt	抉擇	包含一個片段列表，這些片段包含備選訊息序列。 在任何場合下只發生一個序列。 可以在每個片段中設定一個臨界來指示該片段可以執行的條件。 else 的臨界指示其他任何臨界都不為 True 時應執行的片段。 如果所有臨界都為 False 並且沒有 else，則不執行任何片段。
Loop	迴圈	片段重複一定次數。 可以在臨界中指示片段重複的條件。 Loop 組合片段具有“Min”和“Max”屬性，它們指示片段可以重複的最小和最大次數。 預設值是無限制。
Break	中斷	如果執行此片段，則放棄序列的其餘部分。 可以使用臨界來指示發生中斷的條件。
Par	並行	並行處理。 片段中的事件可以交錯。
Critical	關鍵	用在 Par 或 Seq 片段中。 指示此片段中的訊息不得與其他訊息交錯。
Seq	弱順序	有兩個或更多運算元片段。 涉及同一生命線的訊息必須以片段的順序發生。 如果訊息涉及的生命線不同，來自不同片段的訊息可能會並行交錯。
Strict	強順序	有兩個或更多運算元片段。 這些片段必須按給定順序發生。

　　有關如何解釋序列的片段

　　預設情況下，序列圖表明可能發生的一系列訊息。 在執行的系統中，可能會出現您未選擇顯示在關係圖上的其他訊息。

　　以下片段型別可用於更改此釋義：

片段型別	名稱	說明
Consider	考慮	指定此片段描述的訊息列表。 其他訊息可發生在執行的系統中，但對此描述來說意義不大。 在“Messages”屬性中鍵入該列表。
Ignore	忽略	此片段未描述的訊息列表。 這些訊息可發生在執行的系統中，但對此描述來說意義不大。 在“Messages”屬性中鍵入該列表。
Assert	斷言	運算元片段指定唯一有效的序列。 通常用在 Consider 或 Ignore 片段中。
Neg	否定	此片段中顯示的序列不得發生。 通常用在 Consider 或 Ignore 片段中。

 

UML之活動圖解析

 

一、活動圖的組成元素 Activity Diagram Element

1、活動狀態圖（Activity）

2、動作狀態（Actions)

3、動作狀態約束（Action Constraints）

4、動作流（Control Flow）

5、開始節點（Initial Node）

6、終止節點（Final Node）

7、物件（Objects）

8、資料儲存物件（DataStore）

9、物件流（Object Flows）

10、分支與合併（Decision and Merge Nodes）

11、分叉與匯合（Fork and Join Nodes）

12、異常處理（Exception Handler）

13、活動中斷區域（Interruptible Activity Region）

14、泳道（Partition）

二、活動圖案例分析

三、總結

 

活動圖是UML用於對系統的動態行為建模的另一種常用工具，它描述活動的順序，展現從一個活動到另一個活動的控制流。活動圖在本質上是一種流程圖。活動圖著重表現從一個活動到另一個活動的控制流，是內部處理驅動的流程。

一、活動圖的組成元素 Activity Diagram Element

1、活動狀態圖（Activity）

活動狀態用於表達狀態機中的非原子的執行，其特點如下：

(1)、活動狀態可以分解成其他子活動或者動作狀態。

(2)、活動狀態的內部活動可以用另一個活動圖來表示。

(3)、和動作狀態不同，活動狀態可以有入口動作和出口動作，也可以有內部轉移。

(4)、動作狀態是活動狀態的一個特例，如果某個活動狀態只包括一個動作，那麼它就是一個動作狀態。

UML中活動狀態和動作狀態的圖示相同，但是活動狀態可以在圖示中給出入口動作和出口動作等資訊。

 

 

2、動作狀態（Actions）

動作狀態是指原子的，不可中斷的動作，並在此動作完成後通過完成轉換轉向另一個狀態。動作狀態有如下特點：

(1)、動作狀態是原子的，它是構造活動圖的最小單位。

(2)、動作狀態是不可中斷的。

(3)、動作狀態是瞬時的行為。

(4)、動作狀態可以有入轉換，入轉換既可以是動作流，也可以是物件流。動作狀態至少有一條出轉換，這條轉換以內部的完成為起點，與外部事件無關。

(5)、動作狀態與狀態圖中的狀態不同，它不能有入口動作和出口動作，更不能有內部轉移。

(6)、在一張活動圖中，動作狀態允許多處出現。

UML中的動作狀態圖用平滑的圓角矩形表示，如下：

 

3、動作狀態約束（Action Constraints）

動作狀態約束：用來約束動作狀態。如下圖展示了動作狀態的前置條件和後置條件

4、動作流（Control Flow）

動作之間的轉換稱之為動作流，活動圖的轉換用帶箭頭的直線表示，箭頭的方向指向轉入的方向。

5、開始節點（Initial Node）
開始節點：表示成實心黑色圓點

相關推薦