UML類圖的6大關係

《小酌重構系列》已經完成了大約1/3了，在這些文章中，我使用了一些簡單的類圖來描述重構策略。在以後的文章中，我可能會藉助稍微複雜一些的UML類圖來介紹。可是在此以前，我以爲有必要先介紹一下UML類圖中6大關係了。這6大關係分別是Inheritance(繼承)、Implementation(實現)、Dependency(依賴)、Association(關聯)、Aggretation(聚合)和Composition(組合)。在這6大關係中，依賴、關聯、聚合和組合是比較容易混淆的，我也會講解它們之間的區別。

UML類圖簡介

UML是Unified Modeling Language的縮寫，翻譯爲中文是「統一建模語言」，它是面向對象軟件的標準化建模語言。它是一個支持模型化和軟件系統開發的圖形化語言，爲軟件開發的全部階段提供模型化和可視化支持，包括由需求分析到規格，到構造和配置。

不一樣組織不一樣軟件對UML的種類劃分是不一樣的，基本全部的UML的軟件都包含了如下4大種類

1. 用例圖
2. 類圖
3. 活動圖
4. 序列圖

UML類圖

UML類圖用於展示了一組對象、接口、協做和它們之間的關係。類圖描述的是一種靜態關係，在系統的整個生命週期都是有效的，是面向對象系統的建模中最多見的圖。

UML工具

市面上UML的工具軟件很是多，每一個人的口味不一樣，我就很少作介紹了，我最經常使用的UML工具是Visio。

固然做爲一個.NET開發者，Ultimate版本的Visual Studio也提供了UML建模功能。

繼承和實現

繼承(Inheritance)

Inheritance表示一個類（接口）繼承另外一個類（接口）的功能和屬性，用於描述父類（接口）和子類（接口）之間的關係。
繼承描述了"is a kind of "關係，例如：Manger是Employee的一種，Manager繼承了Employee的全部功能（例如：刷卡簽到、執行工做）和屬性（例如：員工姓名、入職時間）。

在UML中，繼承使用實線空心箭頭表示，空心箭頭指向父類（接口）。

 

實現(Implementation)

Implementation表示類實現接口的功能。

在UML中，繼承使用虛線空心箭頭表示，空心箭頭指向接口。

繼承和實現的區別

雖然在C#中繼承和實現都使用符號:來表示（java中使用extends表示繼承，implements表示實現），但兩者仍是有些區別的。

1. 繼承發生在「類和類」或「接口和接口」之間，例如：子類繼承父類，子接口繼承父接口。

子類繼承父類：

public abstract class Animal
{		        
}
		
public class Bird : Animal
{		        

}

子接口繼承父接口：

public interface ITransportation
{
    void Move();
}

public interface IVehicle : ITransportation
{
        
}

2. 實現發生在「類和接口」之間，例如：類實現某個接口的方法。

public interface IVehicle : ITransportation
{

}

public class Car : IVehicle
{
    public void Move()
    {
        Console.WriteLine("汽車跑起來...");
    }
}

3. 在C#中，多繼承確切地說是多實現。

不像C++語言的語法，C#的類不能同時繼承多個類。C#僅能繼承一個類，但能夠同時實現多個接口。
例如：ASP.NET MVC中的Controller類，繼承了ControllerBase類，同時實現了IActionFilter, IAuthenticationFilter…等接口。

public abstract class Controller : ControllerBase, IActionFilter, IAuthenticationFilter, IAuthorizationFilter,
    IDisposable, IExceptionFilter, IResultFilter, IAsyncController, IAsyncManagerContainer
{
}

依賴、關聯、聚合和組合

依賴(Dependency)

依賴關係是對象之間最基本的關係。
當一個對象（調用者）須要調用另一個對象（被調用者）的方法去完成某些工做時，依賴關係就創建了。

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

例如：在Web Service中，Client須要調用Service的操做，這就表示Client依賴於Service。

關聯(Association)

Association表示多個對象之間的關聯關係。
每一個對象都有本身的生命週期，對象之間不存在從屬關係。

在UML中，關聯關係使用一條直線表示。

例如：Student和Teacher之間就屬於」Association」，多個Student能夠關聯到一個Teacher，一個Student也能夠關聯到多個Teacher。
可是Teacher和Student之間沒有「從屬」或「包含」關係。

聚合(Aggregation)

Aggregation體現的是總體和部分之間的關係，即「has-a」關係。
總體和部分是能夠分離的，即總體和部分均可以擁有各自的生命週期。

在UML中，聚合關係使用空心菱形箭頭表示，箭頭指向總體。

例如：一個Department擁有多個Employee，Department做爲總體，Department中的Employee是Department的一部分。
Department和Employee都有本身的生命週期，當一個Department被撤銷時，Employee能夠轉到其餘Department或離職了。
Employee轉到其餘Department或離職時，Department仍然是存在的。

 

組合(Composition)

Composition體現的也是總體和部分之間的關係，即「is-a」關係。
組合關係是更爲強力的聚合關係，總體和部分是不能夠分離的。
總體的生命週期結束時，也意味着部分的生命週期結束。

在UML中，組合關係使用實心菱形箭頭表示，箭頭指向總體。

例如：一套房屋有多個房間，房間是房屋的一部分。房間的生命週期依賴於房屋的生命週期，當房屋被拆掉時，房間也就不存在了。

 

依賴、關聯、聚合和組合的區別

依賴、關聯、聚合和組合均可以泛指爲」依賴關係」。
當對象之間構成Association、Aggregation或Composition關係時，也創建了對象之間的依賴關係。
它們表現的依賴關係強弱程度不一樣，這4種關係所表現的強弱程度依次爲：Composite > Aggregation > Association > Dependency。

關聯、聚合和組合是你們常常容易混淆的3種關係，這種關係最大的區別在於對象的生命週期。

1. 關聯關係：每一個對象都有本身的生命週期，對象之間不存在從屬關係
2. 聚合關係：總體和部分是能夠分離的，總體和部分均可以擁有各自的生命週期
3. 組合關係：總體和部分是不能夠分離的，總體的生命週期結束時，也意味着部分的生命週期結束。

分清楚這些關係有必要嗎？

今天有讀者問到了一個問題：分清楚這些符號有必要嗎？
個人回答是：因團隊而異，這取決於團隊溝通和交流的方式，也取決於團隊成員的能力。
UML是一種溝通語言，你能夠經過它模糊地表達一段內容，你也能夠準確地描述這些內容，只要團隊的其餘成員可以領會你的意思。
溝通是以結果爲嚮導的，你大可沒必要拘泥於溝通的方式，但在溝經過程中準確有效地表達尤爲重要，這裏的「準確」不是指準確地使用UML符號，而是指他人能準確地領會你所表達的內容。

我我的以爲：在涉及到系統中關鍵的模型時，用確切的符號來表達關係仍然是比較重要的。
例如：在一個採購系統中，擁有采購申請 → 採購訂單這樣一個流程。採購申請由用戶選擇商品、供應商後建立；採購訂單由審覈過的採購申請生成。
這裏存在3對關係：
1. 採購申請和採購申請明細的關係
2. 採購訂單和採購訂單明細關係
3. 採購申請和採購訂單之間的關係

從業務上看，一、2是一種組合關係，3是一種關聯關係。若是籠統地將一、二、3理解爲依賴關係，可能會產生一些問題。
在設計過程當中，若是咱們正確地描述了這3對關係，那麼在刪除單據時，可根據確切的關係概括出如下行爲：

1. 刪除採購申請時，採購申請明同時被刪除（由於它們是組合關係）
2. 刪除採購訂單時，採購訂單明細同時被刪除（由於它們是組合關係）
3. 刪除採購訂單時，不影響採購申請（由於它們是關聯關係）

關注keepfool