類與類圖
- 類(Class)封裝了資料和行為，是物件導向的重要組成部分，它是具有相同屬性、操作、關係的物件集合的總稱。
- 在系統中，每個類具有一定的職責，職責指的是類所擔任的任務，即類要完成什麼樣的功能，要承擔什麼樣的義務。一個類可以有多種職責，設計得好的類一般只有一種職責，在定義類的時候，將類的職責分解成為類的屬性和操作（即方法）。
- 類的屬性即類的資料職責，類的操作即類的行為職責
一、依賴關係(Dependence)
依賴關係（Dependence）：假設A類的變化引起了B類的變化，則說名B類依賴於A類。
• 依賴關係(Dependency) 是一種使用關係，特定事物的改變有可能會影響到使用該事物的其他事物，在需要表示一個事物使用另一個事物時使用依賴關係。大多數情況下，依 賴關係體現在某個類的方法使用另一個類的物件作為引數。 • 在UML中，依賴關係用帶箭頭的虛線表示，由依賴的一方指向被依賴的一方。
public class Driver
{
public void drive(Car car)
{
car.move();
}
……
}
public class Car
{
public void move()
{
……
}
……
}
依賴關係有如下三種情況：
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#中使用冒號“：”來實現。
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()
{
……
}
}
在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++等程式語言實現關聯關係時，通常將一個類的物件作為另一個類的屬性。 • 在使用類圖表示關聯關係時可以在關聯線上標註角色名。
- 雙向關聯: 預設情況下，關聯是雙向的。
public class Customer
{
private Product[] products;
……
}
public class Product
{
private Customer customer;
……
}
2 ) 單向關聯:類的關聯關係也可以是單向的，單向關聯用帶箭頭的實線表示.
public class Customer
{
private Address address;
……
}
public class Address
{
……
}
- 自關聯: 在系統中可能會存在一些類的屬性物件型別為該類本身，這種特殊的關聯關係稱為自關聯。
public class Node
{
private Node subNode;
……
}
- 重數性關聯: 重數性關聯關係又稱為多重性關聯關係(Multiplicity)，表示一個類的物件與另一個類的物件連線的個數。在UML中多重性關係可以直接在關聯直線上增加一個數字表示與之對應的另一個類的物件的個數。 表示方式
多重性說明
1..1
表示另一個類的一個物件只與一個該類物件有關係
0..*
表示另一個類的一個物件與零個或多個該類物件有關係
1..*
表示另一個類的一個物件與一個或多個該類物件有關係
0..1
表示另一個類的一個物件沒有或只與一個該類物件有關係
m..n
表示另一個類的一個物件與最少m、最多n個該類物件有關係 (m<=n)
public class Form
{
private Button buttons[];
……
}
public class Button
{
…
}
四、聚合關係（Aggregation）
聚合關係（Aggregation）:表示的是整體和部分的關係，整體與部分 可以分開.
• 聚合關係(Aggregation) 表示一個整體與部分的關係。通常在定義一個整體類後，再去分析這個整體類的組成結構，從而找出一些成員類，該整體類和成員類之間就形成了聚合 關係。 • 在聚合關係中，成員類是整體類的一部分，即成員物件是整體物件的一部分，但是成員物件可以脫離整體物件獨立存在。在UML中，聚合關係用帶空心菱形的直線表示。
public class Car
{
private Engine engine;
public Car(Engine engine)
{
this.engine = engine;
}
public void setEngine(Engine engine)
{
this.engine = engine;
}
……
複製程式碼}
public class Engine
{
……
}
如：電話機包括一個話筒
電腦包括鍵盤、顯示器，一臺電腦可以和多個鍵盤、多個顯示器搭配，確定鍵盤和顯示器是可以和主機分開的，主機可以選擇其他的鍵盤、顯示器組成電腦；
複製程式碼五、組合關係（Composition） 組合關係（Composition）:也是整體與部分的關係，但是整體與部分不可以分開.
• 組合關係(Composition)也表示類之間整體和部分的關係，但是組合關係中部分和整體具有統一的生存期。一旦整體物件不存在，部分物件也將不存在，部分物件與整體物件之 間具有同生共死的關係。 • 在組合關係中，成員類是整體類的一部分，而且整體類可以控制成員類的生命週期，即成員類的存在依賴於整體類。在UML中，組合關係用帶實心菱形的直線表示。
public class Head
{
private Mouth mouth;
public Head()
{
mouth = new Mouth();
}
……
}
public class Mouth
{
……
}
如：公司和部門，部門是部分，公司是整體，公司A的財務部不可能和公司B的財務部對換，就是說，公司A不能和自己的財務部分開； 人與人的心臟.
六、實現關係（Implementation)
實現關係（Implementation）：是用來規定介面和實線介面的類或者構建結構的關係，介面是操作的集合，而這些操作就用於規定類或者構建的一種服務。
• 介面之間也可以有與類之間關係類似的繼承關係和依賴關係，但是介面和類之間還存在一種實現關係(Realization)，在這種關係中，類實現了介面，類中的操作實現了介面中所 宣告的操作。在UML中，類與介面之間的實現關係用帶空心三角形的虛線來表示。
public interface Vehicle
{
public void move();
}
public class Ship implements Vehicle
{
public void move()
{
……
}
}
public class Car implements Vehicle
{
public void move()
{
……
}
}
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） 開始節點：表示成實心黑色圓點
6、終止節點（Final Node） 分為活動終止節點（activity final nodes）和流程終止節點（flow final nodes）。
活動終止節點表示整個活動的結束
而流程終止節點表示是子流程的結束。
7、物件（Objects）
8、資料儲存物件（DataStore）
使用關鍵字«datastore»
9、物件流（Object Flows）
物件流是動作狀態或者活動狀態與物件之間的依賴關係，表示動作使用物件或動作對物件的影響。用活動圖描述某個物件時，可以把涉及到的物件放置在活動圖中並用一個依賴將其連線到進行建立、修改和撤銷的動作狀態或者活動狀態上，物件的這種使用方法就構成了物件流。
物件流中的物件有以下特點：
(1)、一個物件可以由多個動作操作。
(2)、一個動作輸出的物件可以作為另一個動作輸入的物件。
(3)、在活動圖中，同一個物件可以多次出現，它的每一次出現表面該物件正處於物件生存期的不同時間點。
物件流用帶有箭頭的虛線表示。如果箭頭是從動作狀態出發指向物件，則表示動作對物件施加了一定的影響。施加的影響包括建立、修改和撤銷等。如果箭頭從物件指向動作狀態，則表示該動作使用物件流所指向的物件。
狀態圖中的物件用矩形表示，矩形內是該物件的名稱，名稱下的方括號表明物件此時的狀態。
10、分支與合併（Decision and Merge Nodes） 分支與合併用菱形表示
11、分叉與匯合（Fork and Join Nodes）
分為水平風向和垂直方向。
物件在執行時可能會存在兩個或多個併發執行的控制流，為了對併發的控制流建模，UML中引入了分叉與匯合的概念。分叉用於將動作流分為兩個或多個併發執行的分支，而匯合則用於同步這些併發分支，以達到共同完成一項事務的目的。
12、異常處理（Exception Handler）
當受保護的活動發生異常時，觸發異常處理節點。
13、活動中斷區域（Interruptible Activity Region）
活動中斷區域圍繞一些可被中斷的動作狀態圖。比如下圖，正常情況下【Process Order】順序流轉到【Close Order】，訂單處理流程完畢；但在【Process Order】過稱中，會傳送【Cancel Order】請求，這時會流轉到【Cancel Order】，從而訂單處理流程結束
14、泳道（Partition） 泳道將活動圖中的活動劃分為若干組，並把每一組指定給負責這組活動的業務組織，即物件。在活動圖中，泳道區分了負責活動的物件，它明確地表示了哪些活動是由哪些物件進行的。在包含泳道的活動圖中，每個活動只能明確地屬於一個泳道。
泳道是用垂直實線繪出，垂直線分隔的區域就是泳道。在泳道的上方可以給出泳道的名字或物件的名字，該物件負責泳道內的全部活動。泳道沒有順序，不同泳道中的活動既可以順序進行也可以併發進行，動作流和物件流允許穿越分隔線。
二、活動圖案例分析
1、 泳道分為：會員泳道和系統泳道。會員選擇商品並加入購物車，系統完成訂單生成及其支付完畢。
2、 開始節點：會員新增商品到購物車，點選【訂單確認】，開始交於系統處理訂單流程
3、 結束節點：商品傳送完畢和付款成功，訂單處理流程結束
4、 活動狀態：產生訂單、Check Credit Cart核對信用卡、Check Stock 核對庫存量、Deliver Goods 傳送商品、Process Credit Cart付款
5、 分叉與匯合：【產生訂單】份叉為檢查庫存量和會員支付金額是否足夠，如果不足，取消訂單，如過庫存量和支付金額足夠，傳送商品和付款，最後匯合為訂單完成。
三、總結 活動圖描述的是物件活動的順序關係所遵循的規則，它著重表現的是系統的行為，而非系統的處理過程。活動圖能夠表示併發活動的情形，活動圖是物件導向的。
UML之關係圖解析
一、簡介
二、類的構成 三、類之間的關係（Relationship） 1、單向關聯 2、雙向關聯 3、自身關聯 4、多維關聯(N-ary Association) 5、泛化(Generalization) 6、依賴(Dependency) 7、聚合(Aggregation) 8、組合（Composite） 四、總結 一、簡介 類是物件的集合，展示了物件的結構以及與系統的互動行為。類主要有屬性（Attribute）和方法（Method）構成,屬性代表物件的狀態，如果屬性被儲存到資料庫，此稱之為“持久化”；方法代表物件的操作行為，類具有繼承關係，可以繼承於父類，也可以與其他的Class進行互動。
類圖展示了系統的邏輯結構，類和介面的關係。
複製程式碼二、類的構成
類主要有屬性和方法構成。比如商品屬性有：名稱、價格、高度、寬度等；商品的方法有：計算稅率，獲得商品的評價等等。如下圖
三、類之間的關係（Relationship） 關聯(Association)
兩個相對獨立的物件，當一個物件的例項與另外一個物件的特定例項存在固定關係時，這兩個物件之間就存在關聯關係。
1、單向關聯 A1->A2: 表示A1認識A2，A1知道A2的存在，A1可以呼叫A2中的方法和屬性
場景：訂單和商品，訂單中包括商品，但是商品並不瞭解訂單的存在。
類與類之間的單向關聯圖:
C#程式碼:
Public class Order
{
Public List<Product> order;
複製程式碼Public void AddOrder(Product product )
{
order.Add(product);
複製程式碼}
}
Public Class Product
{
}
程式碼表現為：Order(A1)中有Product(A2)的變數或者引用
2、雙向關聯 B1-B2: 表示B1認識B2，B1知道B2的存在，B1可以呼叫B2中的方法和屬性；同樣B2也知道B1的存在，B2也可以呼叫B1的方法和屬性。
場景：訂單和客戶，訂單屬於客戶，客戶擁有一些特定的訂單
類與類之間的雙向關聯圖
C#程式碼
Public class User
{
Public List<Order> GetOrder()
{
複製程式碼} return new List();
}
Public Class Order
{
Public User GetUserByOrderID(string OrderId )
{
Return new User();
複製程式碼}
}
3、自身關聯 同一個類物件之間的關聯
類與類之間自身關聯圖
4、多維關聯(N-ary Association) 多個物件之間存在關聯
場景：公司僱用員工，同時公司需要支付工資給員工
類與類之間的多維關聯圖：
5、泛化(Generalization) 類與類的繼承關係，類與介面的實現關係。
場景：父與子、動物與人、植物與樹、系統使用者與B2C會員和B2E會員的關係
類與類之間的泛化圖：
系統的使用者包括：B2C會員、B2B會員和B2E會員。
介面的實現，動物都有吃的行為，而人是動物的一個具體例項,實現具體Eat的動作
6、依賴(Dependency) 類A要完成某個功能必須引用類B，則A與B存在依賴關係，依賴關係是弱的關聯關係。C#不建議雙相依賴，也就是相互引用
場景：本來人與電腦沒有關係的，但由於偶然的機會，人需要用電腦寫程式，這時候人就依賴於電腦。
類與類的依賴關係圖
在程式中一般為 using 引用。
7、聚合(Aggregation) 當物件A被加入到物件B中，成為物件B的組成部分時，物件B和物件A之間為聚合關係。聚合是關聯關係的一種，是較強的關聯關係，強調的是整體與部分之間的關係。
場景：商品和他的規格、樣式就是聚合關係。
類與類的聚合關係圖
8、組合（Composite） 物件A包含物件B，物件B離開物件A沒有實際意義。是一種更強的關聯關係。人包含手，手離開人的軀體就失去了它應有的作用。
場景： Window窗體由滑動條slider、頭部Header 和工作區Panel組合而成。
類與類的組合關係圖
四、總結 本文針對類之間常用的關係進行了簡單的描述，主要有：關聯關係、泛化、依賴、聚合和組合。
UML之狀態圖解析
狀態圖目錄：
一、狀態圖簡介（Brief introduction）
二、狀態圖元素（State Diagram Elements）
1、狀態（States）
2、轉移（Transitions）
3、動作（State Actions）
4、自身轉移（Self-Transitions）
5、組合狀態（Compound States）
6、進入節點（Entry Point）
7、退出節點（Exit Point）
8、歷史狀態（History States）
9、併發區域（Concurrent Regions）
三、狀態圖案例分析（State Diagram Example Analysis）
四、總結（Summary）
複製程式碼一、狀態圖簡介（Brief introduction）
狀態圖（Statechart Diagram）主要用於描述一個物件在其生存期間的動態行為，表現為一個物件所經歷的狀態序列，引起狀態轉移的事件（Event），以及因狀態轉移而伴隨的動作（Action）。一般可以用狀態機對一個物件的生命週期建模，狀態圖用於顯示狀態機（State Machine Diagram），重點在與描述狀態圖的控制流。 如下圖例子，狀態機描述了門物件的生存期間的狀態序列，引起轉移的事件，以及因狀態轉移而伴隨的動作（Action）.
狀態有Opened、Closed、Locked。
事件有 Open、Close、Lock和Unlock。
注意：
1、 並不是所有的事件都會引起狀態的轉移，比如當門是處於【Opened】狀態，不能進行【Lock】事件。
2、 轉移（Transition）有警備條件（guard condition），比如只有doorWay->isEmpty 條件滿足時，才會響應事件。
二、狀態圖元素（State Diagram Elements）
1、狀態（States） 指在物件的生命週期中的某個條件或者狀況，在此期間物件將滿足某些條件、執行某些活動活活等待某些事件。所有物件都有狀態，狀態是物件執行了一系列活動的結果，當某個事件發生後，物件的狀態將發生變化。
狀態用圓角矩形表示
初態和終態（Initial and Final States） 初態用實心圓點表示，終態用圓形內嵌圓點表示。
2、轉移（Transitions） 轉移（Transitions）是兩個狀態之間的一種關係，表示物件將在源狀態（Source State）中執行一定的動作，並在某個特定事件發生而且某個特定的警界條件滿足時進入目標狀態（Target State）
事件標記（Trigger）：是轉移的誘因，可以是一個訊號，事件、條件變化（a change in some condition）和時間表示式。
警界條件（Guard Condition）：當警界條件滿足時，事件才會引發轉移（Transition）。
結果（Effect）：物件狀態轉移後的結果。
複製程式碼3、動作（State Actions） 動作（Actions）是一個可執行的原子操作,也就是說動作是不可中斷的，其執行時間是可忽略不計的。
在上例中，物件狀態轉移後的結果顯示在轉移線上，如果目標狀態有許多轉移，而且每個轉移有相同的結果，這時把轉移後的結果（Effect）展示在目標狀態中（Target State）更好一些，可以定義進入動作（Entry Action ）和退出動作（Exit Action），如下圖
4、自身轉移（Self-Transitions） 狀態可以有返回自身狀態的轉移，稱之為自身轉移（Self-Transitions）
2S後，Poll input事件執行，轉移到自己狀態【Waiting】
5、組合狀態（Compound States） 巢狀在另外一個狀態中的狀態稱之為子狀態（sub-state）,一個含有子狀態的狀態被稱作組合狀態（Compound States）. 如下圖，【Check PIN】是組合狀態，【Enter PIN】是子狀態。
也可用以下方式進行描述
如上圖，狀態機【Check PIN】的細節被分割到另外一個圖中了。
6、進入節點（Entry Point） 如下圖所示，由於一些原因並不會執行初始化（initialization），而是直接通過一個節點進入狀態【Ready】，則此節點稱之為進入節點（Entry Point）
7、退出節點（Exit Point）
8、歷史狀態（History States）
歷史狀態是一個偽狀態（Pseudostate）,其目的是記住從組合狀態中退出時所處的子狀態，當再次進入組合狀態，可直接進入這個子狀態，而不是再次從組合狀態的初態開始。
複製程式碼在上圖的狀態圖中，正常的狀態順序是:【Washing】- >【Rinsing】->【Spinning】。
如果是從狀態【Rinsing】突然停電（Power Cut）退出，,洗衣機停止工作進入狀態【Power Off】，當電力恢復時直接進入狀態【Running】。
9、併發區域（Concurrent Regions） 狀態圖可以分為區域，而區域又包括退出或者當前執行的子狀態。說明組合狀態在某一時刻可以同時達到多個子狀態。如下圖剎車系統，同時進入前剎車【Applying Front Brakes】狀態和後剎車【Applying Rear Brakes】狀態。
三、狀態圖案例分析（State Diagram Example Analysis）
按照blink518的建議（“出貨中”是屬於條件分支應該使用Decision），改成如下圖也是很好的做法：
訂單成立狀態主要有：
訂單成立
訂單取消（Guard:會員訂單-繳款期限已過期）
備貨中（Guard:已付款、訂單成立、庫存量足夠）
出貨中（Effect:扣除商品可接單量及移除購物車中的購買資料）
出貨確認（Guard:實際配達日及發票程式碼、號碼均不為空值）
出貨完畢（Guard:實際配達日不為空）
出貨失敗
訂單成立（Guard:出貨完畢，已付款、鑑賞期結束日期 小於等於 [系統日期]）
分析：
1、購物車生成訂單進入狀態【訂單成立】
2、系統檢測訂單已經付款並且庫存量足夠，則進入狀態【備貨中】
3、物流發貨，進入狀態【發貨中】，狀態轉移為【發貨中】後，需要做的操作有“扣除商品可接單量及移除購物車中的購買資料”
4、發貨完畢後，狀態分為【出貨確認】和狀態【出貨失敗】，如果狀態是【出貨失敗】，則【結束】，如果狀態為【出貨確認】，則進入下一步。
5、配貨人員填寫實際配達日期，進入狀態【出貨完畢】。
6、如果”已付款、鑑賞期結束日期 小於等於 [系統日期]”,則【訂單成立】。
四、總結（Summary）
狀態圖重點在於描述物件的狀態及其狀態之間的轉移，狀態圖的基本元素主要有：狀態、轉移、動作、自身轉移、組合狀態、進入節點、退出節點、歷史狀態、併發區域等，狀態中的事件分為呼叫事件（Call）、變化事件（Change）、時間事件（Time）和訊號事件(Singal)。最後以例項對狀態對進行了分析。
複製程式碼UML之時序圖解析
一、時序圖簡介（Brief introduction）
二、時序圖元素（Sequence Diagram Elements）
複製程式碼角色（Actor）
物件（Object）
生命線（Lifeline）
控制焦點（Focus of Control）
訊息（Message）
自關聯訊息（Self-Message）
Combined Fragments
三、時序圖例項分析（Sequece Diagram Example Analysis）
時序圖場景
時序圖例項
時序圖例項分析
四、總結（Summary）
複製程式碼一、時序圖簡介（Brief introduction） 時序圖（Sequence Diagram）是顯示物件之間互動的圖，這些物件是按時間順序排列的。順序圖中顯示的是參與互動的物件及其物件之間訊息互動的順序。時序圖中包括的建模元素主要有：物件（Actor）、生命線（Lifeline）、控制焦點（Focus of control）、訊息（Message）等等。
二、時序圖元素（Sequence Diagram Elements） 角色（Actor） 系統角色，可以是人、及其甚至其他的系統或者子系統。
物件（Object） 物件包括三種命名方式：
第一種方式包括物件名和類名；
第二中方式只顯示類名不顯示物件名，即表示他是一個匿名物件；
第三種方式只顯示物件名不顯示類明。
生命線（Lifeline） 生命線在順序圖中表示為從物件圖示向下延伸的一條虛線，表示物件存在的時間，如下圖
控制焦點（Focus of Control）
控制焦點是順序圖中表示時間段的符號，在這個時間段內物件將執行相應的操作。用小矩形表示，如下圖。
訊息（Message） 訊息一般分為同步訊息（Synchronous Message），非同步訊息（Asynchronous Message）和返回訊息（Return Message）.如下圖所示：
同步訊息=呼叫訊息（Synchronous Message）
訊息的傳送者把控制傳遞給訊息的接收者，然後停止活動，等待訊息的接收者放棄或者返回控制。用來表示同步的意義。
非同步訊息（Asynchronous Message）
訊息傳送者通過訊息把訊號傳遞給訊息的接收者，然後繼續自己的活動，不等待接受者返回訊息或者控制。非同步訊息的接收者和傳送者是併發工作的。
返回訊息（Return Message）
返回訊息表示從過程呼叫返回
自關聯訊息（Self-Message） 表示方法的自身呼叫以及一個物件內的一個方法呼叫另外一個方法。
Combined Fragments
Ø Alternative fragment（denoted “alt”） 與 if…then…else對應
Ø Option fragment (denoted “opt”) 與 Switch對應
Ø Parallel fragment (denoted “par”) 表示同時發生
Ø Loop fragment(denoted “loop”) 與 for 或者 Foreach對應
三、時序圖例項分析（Sequece Diagram Example Analysis） 時序圖場景 完成課程建立功能，主要流程有：
1、請求新增課程頁面，填寫課程表單，點選【create】按鈕
2、新增課程資訊到資料庫
3、向課程物件追加主題資訊
4、為課程指派教師
5、完成課程建立功能
時序圖例項
時序圖例項分析 1、序號1.0-1.3 完成頁面的初始化
2、序號1.4-1.5 課程管理員填充課程表單
3、序號1.6-1.7 課程管理員點選【Create】按鈕，並響應點選事件
4、序號1.8 Service層建立課程
5、序號1.9-1.10 新增課程到資料庫，並返回課程編號CourseId
6、序號1.11-1.12 新增課程主題到資料庫，並返回主題編號topicId
7、序號1.13 給課程指派教師
8、序號1.14 向介面拋建立課程成功與否的訊息
四、總結（Summary） 時序圖（Sequence Diagram）是顯示物件之間互動的圖，這些物件是按時間順序排列的。順序圖中顯示的是參與互動的物件及其物件之間訊息互動的順序。時序圖中包括的建模元素主要有：物件（Actor）、生命線（Lifeline）、控制焦點（Focus of control）、訊息（Message）等等。最後，以課程建立功能演示一時序圖例項。
例項演示 – 基於UML的物件導向分析與設計
摘要
本文以例項的方式，展示瞭如何使用UML進行物件導向的分析與設計。本文將假設讀者對UML、物件導向等領域的基本內容已瞭然於胸，所以將不會過多闡述，而將重點放在應用過程上。本文的目的是通過一個完整的例項，展現基於UML的OOA&D過程 的一個簡化模式，幫助朋友們更好的認識UML在OOA&D中起的作用。
前言
經常聽到有朋友抱怨，說學了UML不知該怎麼用，或者畫了UML卻覺得沒什麼作用。其實，就UML本身來說，它只是一種交流工具，它作為一種標準化交流符號，在OOA&D過程中開發人員間甚至開發人員與客戶之間傳遞資訊。另外，UML也可以看做是OO思想的一種表現形式，可以說“OO是神，而UML是型”。所以，想用好UML，紮實的OO思想基礎是必不可少的。然而，在UML應用到開發過程中時，還是有一定的模式可以遵循的。（注意，是模式而不是教條，我下面給出的流程只是一個啟發式過程，而不是說一定要遵循這個流程。）下面，我們通過一個CMS系統的分析設計例項，看看如何將UML應用到實際的開發中。
1.從需求到業務用例圖
OOA&D的第一步，就是了解使用者需求，並將其轉換為業務用例圖。我們的CMS系統需求非常簡單，大致課做如下描述：這個系統主要用來發布新聞，管理員只需要一個，登入後可以在後臺釋出新聞。任何人可以瀏覽新聞，瀏覽者可以註冊成為系統會員，註冊後可對新聞進行評論。管理員在後臺可以對新聞、評論、註冊會員進行管理，如修改、刪除等。
通過以上需求描述，我們畫出如下的業務用例圖：
這裡要注意三點：
1.業務用例是僅從系統業務角度關注的用例，而不是具體系統的用例。它描述的是“該實現什麼業務”，而不是“系統該提供什麼操作”。例如，在實際系統中，“登入”肯定要作為一個用例，但是這是軟體系統中的操作，而使用者所關注的業務是不包含“登入”的。
2.業務用例僅包含客戶“感興趣”的內容。
3.業務用例所有的用例名應該讓客戶能看懂，如果某個用例的名字客戶看不懂什麼意思，它也許就不適合作為業務用例。
2.從業務用例圖到活動圖
完成了業務用例圖後，我們要為每一個業務用例繪製一幅活動圖。活動圖描述了這個業務用例中，使用者可能會進行的操作序列。活動圖有個很重要的使命：從業務用例分析出系統用例。例如，下面是“新聞管理”的活動圖：
可以看到，一個“新聞管理”這個業務用例，分解出N多系統操作。這裡要特別注意這些操作，其中很多“活動”都很可能是一個系統用例（當然，不是每個都是）。例如，由這個活動圖可以看出，系統中至少要包含以下備選系統用例：登入、登出登入、檢視新聞列表、修改新聞、刪除新聞。
這樣，將每個業務用例都繪製出相應的活動圖，再將其中的“活動”整合，就得出所有備選系統用例。
3.從活動圖到系統用例圖
找出所有的備選系統用例後，我們要對他們進行合併和篩選。合併就是將相同的用例合併成一個，篩選就是將不符合系統用例條件的備選用例去掉。
一個系統用例應該是實際使用系統的使用者所進行的一個操作，例如，“檢視新聞列表”就不能算一個系統用例，因為他只是某系統用例的一個序列項。
最終我們得出的系統用例圖如下：
4.從系統用例圖到用例規約
得出系統用例圖後，我們應該對每一個系統用例給出用例規約。關於用例規約，沒有一個通用的格式，大家可以按照習慣的格式進行編寫。對用例規約唯一的要求就是“清晰易懂”。
下面給出“登入”這個系統用例的一個規約：
5.繪製業務領域類圖
完成了上面幾步，下面應該是繪製業務領域類圖了。所謂業務領域類圖要描述一下三點：
1.系統中有哪些實體。
2.這些實體能做什麼操作。
3.實體間的關係。
這裡要特別強調：這裡的實體不是Actor，而是Actor使用系統時使用的所呼叫的實體，是處在系統邊界之內的實體。例如，管理員就沒有作為一個實體出現在這裡，因為管理員處在系統邊界之外，它所有的工作都可以通過呼叫這三個類的方法完成。並且，這裡的“註冊會員”實體也不是剛才用例圖中註冊會員這個Actor，而是作為一個系統內的業務實體，供Actor們使用的。例如，其中的註冊功能是給註冊會員這個Actor使用，而移除則是給管理員這個Actor使用的。
理解以上這段話非常重要，我經常看到由於混淆了實體和Actor的關係而導致畫出的領域類圖不準確或職責分配不準確。
大家可能還注意到，我們這裡沒有給出每個實體的屬性。其實，在領域分析階段，實體的屬性並不重要，重要的是找出實體的操作。
6.繪製實現類圖
以上這幾步，就是分析的過程。而下面的步驟就是設計了。
設計沒有分析那麼好描述，因為分析是“客戶面”，它只關心繫統本身的功能和業務，而不關心任何和計算機有關的東西。但是，設計和平臺、語言、開發模型等內容關係緊密，因而很難找出一個一致的過程。但是，一般在設計過程中實現類圖是要繪製的。
實現類圖和領域類圖不一樣，它描述的是真正系統的靜態結構，是和最後的程式碼完全一致的。因此，它和平臺關係密切，必須準確給出系統中的實體類、控制類、介面類、介面等元素以及其中的關係。因此，實現類圖是很複雜的，而且是平臺技術有關的。所以，我在這裡不可能給出一個準確的實現類圖，不過為了描述，我還是給出一個簡化了的實現類圖，當然，它是不準確的，而只是從形式上給出實現類圖的樣子。
我們假設這個系統建構於.NET 3.5平臺上，並且使用ASP.NET MVC作為表示層，整體使用三層架構。那麼，使用者模組體系的實現類圖大體是這樣子（不準確）：
7.繪製序列圖
有了靜態結構，我們還要給出動態結構，這樣，才能看清系統間的類是如何互動的，從而有效幫助程式設計師進行編碼工作。
上圖給出的是使用者登入的序列圖。首先註冊會員作為Actor，呼叫UserController的Login方法啟動序列，然後序列按圖示步驟執行。其中UserServices作為業務元件，首先呼叫資料訪問元件的GetByName確定使用者是否存在，如果存在，再呼叫GetByNameAndPassword確定輸入密碼是否是此使用者的密碼。從而完成業務功能。
要注意，序列圖在實際中是很多的，幾乎每個類方法都配有相應的序列圖。
8.後面的步驟
在完成了上面的過程後，就可以進行編碼、除錯、測試等工作了。但這些已經超出了本文討論的範圍。
總結
本文簡要給出了使用UML進行OOA&D的過程。當然，由於示例較小，而且本人水平有限，所以給出的相關內容可能不是很準確。而且軟體分析設計本來就不是一個固定模式的過程，隨著系統的不同整個過程會有變化。本文只是想起到一個拋磚引玉的作用，讓朋友們大致瞭解UML的使用流程。至於實際的分析設計，還需要深入的學習和實踐的積累。
UML類圖關係（泛化 、繼承、實現、依賴、關聯、聚合、組合）
繼承、實現、依賴、關聯、聚合、組合的聯絡與區別
分別介紹這幾種關係：
繼承 指的是一個類（稱為子類、子介面）繼承另外的一個類（稱為父類、父介面）的功能，並可以增加它自己的新功能的能力，繼承是類與類或者介面與介面之間最常見的關係；在Java中此類關係通過關鍵字extends明確標識，在設計時一般沒有爭議性；
實現 指的是一個class類實現interface介面（可以是多個）的功能；實現是類與介面之間最常見的關係；在Java中此類關係通過關鍵字implements明確標識，在設計時一般沒有爭議性；
依賴 可以簡單的理解，就是一個類A使用到了另一個類B，而這種使用關係是具有偶然性的、、臨時性的、非常弱的，但是B類的變化會影響到A；比如某人要過河，需要借用一條船，此時人與船之間的關係就是依賴；表現在程式碼層面，為類B作為引數被類A在某個method方法中使用；
關聯 他體現的是兩個類、或者類與介面之間語義級別的一種強依賴關係，比如我和我的朋友；這種關係比依賴更強、不存在依賴關係的偶然性、關係也不是臨時性的，一般是長期性的，而且雙方的關係一般是平等的、關聯可以是單向、雙向的；表現在程式碼層面，為被關聯類B以類屬性的形式出現在關聯類A中，也可能是關聯類A引用了一個型別為被關聯類B的全域性變數；
聚合 聚合是關聯關係的一種特例，他體現的是整體與部分、擁有的關係，即has-a的關係，此時整體與部分之間是可分離的，他們可以具有各自的生命週期，部分可以屬於多個整體物件，也可以為多個整體物件共享；比如計算機與CPU、公司與員工的關係等；表現在程式碼層面，和關聯關係是一致的，只能從語義級別來區分；
組合 組合也是關聯關係的一種特例，他體現的是一種contains-a的關係，這種關係比聚合更強，也稱為強聚合；他同樣體現整體與部分間的關係，但此時整體與部分是不可分的，整體的生命週期結束也就意味著部分的生命週期結束；比如你和你的大腦；表現在程式碼層面，和關聯關係是一致的，只能從語義級別來區分；
對於繼承、實現這兩種關係沒多少疑問，他們體現的是一種類與類、或者類與介面間的縱向關係；其他的四者關係則體現的是類與類、或者類與介面間的引用、橫向關係，是比較難區分的，有很多事物間的關係要想準備定位是很難的，前面也提到，這幾種關係都是語義級別的，所以從程式碼層面並不能完全區分各種關係；
但總的來說，後幾種關係所表現的強弱程度依次為：組合>聚合>關聯>依賴；
聚合跟組合其實都屬於關聯 只不過它們是兩種特殊的關聯 因為本是同根生 所以它們之間難免會有相似之處 下面讓我們一起來看一下它們之間有何不同
聚合與組合的概念相信不用我在此贅述大家就已經瞭解了 下面直接上例子
程老師的《大話》裡舉大那個大雁的例子很貼切 在此我就借用一下 大雁喜歡熱鬧害怕孤獨 所以它們一直過著群居的生活 這樣就有了雁群 每一隻大雁都有自己的雁群 每個雁群都有好多大雁 大雁與雁群的這種關係就可以稱之為聚合 另外每隻大雁都有兩隻翅膀 大雁與雁翅的關係就叫做組合 有此可見 聚合的關係明顯沒有組合緊密 大雁不會因為它們的群主將雁群解散而無法生存 而雁翅就無法脫離大雁而單獨生存——組合關係的類具有相同的生命週期
聚合關係圖：
組合關係圖：
從從程式碼上看這兩種關係的區別在於：
建構函式不同
雁群類：
public class GooseGroup{
private Goose goose;
public GooseGroup(Goose goose){
this.goose = goose;
}
}
大雁類：
public class Goose{
private Wings wings;
public Goose(){
wings=new Wings();
}
}
聚合關係的類裡含有另一個類作為引數 雁群類（GooseGroup）的建構函式中要用到大雁（Goose）作為引數把值傳進來 大雁類（Goose）可以脫離雁群類而獨立存在 組合關係的類裡含有另一個類的例項化 大雁類（Goose）在例項化之前 一定要先例項化翅膀類（Wings） 兩個類緊密耦合在一起 它們有相同的生命週期 翅膀類（Wings）不可以脫離大雁類（Goose）而獨立存在 資訊的封裝性不同 在聚合關係中，客戶端可以同時瞭解雁群類和大雁類，因為他們都是獨立的 而在組合關係中，客戶端只認識大雁類，根本就不知道翅膀類的存在，因為翅膀類被嚴密的封裝在大雁類中。
——————————————————————————————————-
UML-泛化、關聯、聚合、組合、依賴
一、泛化關係（generalization）
1.說明
表示類與類之間的繼承關係，介面與介面之間的繼承關係，或類對介面的實現關係。一般化的關係是從子類指向父類的，與繼承或實現的方法相反。
2.例圖
3.表現
父類 父類例項＝new 子類();
4.舉例
class Animal{};
class Tigger : public Animal{};
class Dog : public Animal{};
Animal* pAnimal = new Dog;
二、關聯關係（association）
1.說明
對於兩個相對獨立的物件，當一個物件的例項與另一個物件的一些特定例項存在固定的對應關係時，這兩個物件之間為關聯關係。
表示類與類之間的聯接，有雙向關聯和單向關聯，雙向關聯有兩個箭頭或者沒有箭頭，單向關聯有一個箭頭，表示關聯的方向。
關聯關係以例項變數的形式存在，在每一個關聯的端點，還可以有一個基數(multiplicity),表明這一端點的類可以有幾個例項。
2.例圖
3.表現
雙向關聯在程式碼的表現為雙方都擁有對方的一個指標，當然也可以是引用或者是值。
關聯關係是使用例項變數來實現。
4.舉例
//單向關聯
class Person{};
class Friend
{
Person* mpPerson;
};
//雙向關聯
class A;
class B
{
A* pA;
};
class A
{
B* pB;
};
//自身關聯
class C
{
C* pC;
};
三、聚合關係（aggregation）
1.說明：
關聯關係的一種，是強的關聯關係。聚合是整體和個體的關係。聚合關係也是通過例項變數實現的。例如汽車、發動機、輪胎，一個汽車物件由一個發動機物件，四個輪胎物件組成。
當類之間有整體-部分關係的時候，我們就可以使用組合或者聚合。
2.例圖
3.表現
與關聯關係一樣，聚合關係也是通過例項變數來實現這樣關係的。關聯關係和聚合關係來語法上是沒辦法區分的，從語義上才能更好的區分兩者的區別。
4.舉例
class CPU{};
class Memory{};
class Computer
{
CPU* mpCPU;
Memory* mpMemory;
};
四、組合關係（合成關係）（composition）
1.說明：
合成關係也是關聯關係的一種，是比聚合關係更強的關係。合成關係是不能共享的。例如人有四肢、頭等。
表示類之間整體和部分的關係，組合關係中部分和整體具有統一的生存期。一旦整體物件不存在，部分物件也將不存在。部分物件與整體物件之間具有共生死的關係。
2.例圖
3.表現
4.舉例
//同聚合關係，不過說語義不同
class Leg{};
class Arm{};
class Person
{
Leg mLeg;
Arm mArm;
};
五、依賴關係（Dependency）
1.說明：
對於兩個相對獨立的物件，當一個物件負責構造另一個物件的例項，或者依賴另一個物件的服務時，這兩個物件之間主要體現為依賴關係。
與關聯關係不同的是，依賴關係是以引數變數的形式傳入到依賴類中的，依賴是單向的，要避免雙向依賴。一般來說，不應該存在雙向依賴。
依賴是一種弱關聯，只要一個類用到另一個類，但是和另一個類的關係不是太明顯的時候（可以說是“uses”了那個類），就可以把這種關係看成是依賴。
2.例圖
3.表現
依賴關係表現在區域性變數，方法的引數，以及對靜態方法的呼叫
4.舉例
class Car{};
class House{};
class Person
{
void buy(Car& car){}
void buy(House* pHouse){}
};
六、關係之間的區別
1.聚合與組合
（1）聚合與組合都是一種結合關係，只是額外具有整體-部分的意涵。
（2）部件的生命週期不同
聚合關係中，整件不會擁有部件的生命週期，所以整件刪除時，部件不會被刪除。再者，多個整件可以共享同一個部件。 組合關係中，整件擁有部件的生命週期，所以整件刪除時，部件一定會跟著刪除。而且，多個整件不可以同時間共享同一個部件。
（3）聚合關係是“has-a”關係，組合關係是“contains-a”關係。
2.關聯和聚合
（1）表現在程式碼層面，和關聯關係是一致的，只能從語義級別來區分。
（2）關聯和聚合的區別主要在語義上，關聯的兩個物件之間一般是平等的，例如你是我的朋友，聚合則一般不是平等的。
（3）關聯是一種結構化的關係，指一種物件和另一種物件有聯絡。
（4）關聯和聚合是視問題域而定的，例如在關心汽車的領域裡，輪胎是一定要組合在汽車類中的，因為它離開了汽車就沒有意義了。但是在賣輪胎的店鋪業務裡，就算輪胎離開了汽車，它也是有意義的，這就可以用聚合了。
3.關聯和依賴
（1）關聯關係中，體現的是兩個類、或者類與介面之間語義級別的一種強依賴關係，比如我和我的朋友；這種關係比依賴更強、不存在依賴關係的偶然性、關係也不是臨時性的，一般是長期性的，而且雙方的關係一般是平等的。
（2）依賴關係中，可以簡單的理解，就是一個類A使用到了另一個類B，而這種使用關係是具有偶然性的、臨時性的、非常弱的，但是B類的變化會影響到A。
4.綜合比較
這幾種關係都是語義級別的，所以從程式碼層面並不能完全區分各種關係；但總的來說，後幾種關係所表現的強弱程度依次為：
組合>聚合>關聯>依賴；
———————————————————————————————————————————————–
UML 線條 箭頭
關係
後面的例子將針對某個具體目的來獨立地展示各種關係。雖然語法無誤，但這些例子可進一步精煉，在它們的有效範圍內包括更多的語義。
依賴（Dependency）
實體之間一個“使用”關係暗示一個實體的規範發生變化後，可能影響依賴於它的其他例項（圖D）。 更具體地說，它可轉換為對不在例項作用域內的一個類或物件的任何型別的引用。其中包括一個區域性變數，對通過方法呼叫而獲得的一個物件的引用（如下例所 示），或者對一個類的靜態方法的引用（同時不存在那個類的一個例項）。也可利用“依賴”來表示包和包之間的關係。由於包中含有類，所以你可根據那些包中的 各個類之間的關係，表示出包和包的關係。
圖D
關聯（Association）
實體之間的一個結構化關係表明物件是相互連線的。箭頭是可選的，它用於指定導航能力。如果沒有箭頭，暗示是一種雙向的導航能力。在Java中，關聯（圖E） 轉換為一個例項作用域的變數，就像圖E的“Java”區域所展示的程式碼那樣。可為一個關聯附加其他修飾符。多重性（Multiplicity）修飾符暗示 著例項之間的關係。在示範程式碼中，Employee可以有0個或更多的TimeCard物件。但是，每個TimeCard只從屬於單獨一個 Employee。
圖E
聚合（Aggregation）
聚合（圖F）是關聯的一種形式，代表兩個類之間的整體/區域性關係。聚合暗示著整體在概念上處於比區域性更高的一個級別，而關聯暗示兩個類在概念上位於相同的級別。聚合也轉換成Java中的一個例項作用域變數。
關聯和聚合的區別純粹是概念上的，而且嚴格反映在語義上。聚合還暗示著例項圖中不存在迴路。換言之，只能是一種單向關係。
圖F
合成（Composition）
合成 （圖G） 是聚合的一種特殊形式，暗示“區域性”在“整體”內部的生存期職責。合成也是非共享的。所以，雖然區域性不一定要隨整體的銷燬而被銷燬，但整體要麼負責保持局 部的存活狀態，要麼負責將其銷燬。區域性不可與其他整體共享。但是，整體可將所有權轉交給另一個物件，後者隨即將承擔生存期職責。
Employee和TimeCard的關係或許更適合表示成“合成”，而不是表示成“關聯”。
圖G
泛化（Generalization）
泛化（圖H）表示一個更泛化的元素和一個更具體的元素之間的關係。泛化是用於對繼承進行建模的UML元素。在Java中，用extends關鍵字來直接表示這種關係。
圖H
實現（Realization）
例項（圖I）關係指定兩個實體之間的一個合同。換言之，一個實體定義一個合同，而另一個實體保證履行該合同。對Java應用程式進行建模時，實現關係可直接用implements關鍵字來表示。
圖I
———————————————————————————————————————————————–
UML類圖關係主要有關聯，依賴，泛化，實現等，那麼它們的表示方法你是否熟悉，本文就像大家介紹一下UML類圖關係的表示方法。
AD：
本節和大家一起學習一下UML類圖關係的表示方法，主要包括關聯，聚合，泛化，實現，依賴等內容，希望通過本節的學習大家對UML類圖關係的表示方法有一定的掌握。下面是具體介紹。
UML基礎
1：UML類間關係的種類
2：關聯
UML類圖關係中關聯描述了系統中物件或例項之間的離散連線，關聯帶有系統中各個物件之間關係的資訊。
2.1關聯表示法
2.2聚集與組合
3：泛化，繼承【Generalization】
UML類圖關係中泛化關係是類元的一般描述和具體描述之間的關係，具體描述建立在一般描述的基礎之上，並對其進行了擴充套件。
4：實現【realization】
UML類圖關係中實現關係將一種模型元素（如類）與另一種模型元素（如介面）連線起來，其中介面只是行為的說明而不是結構或者實現。
5：依賴【Dependence】
UML類圖關係中依賴表示兩個或多個模型元素之間語義上的關係。它只將模型元素本身連線起來而不需要用一組例項來表達它的意思。它表示了這樣一種情形，提供者的某些變化會要求或指示依賴關係中客戶的變化。
5.1依賴的種類
訪問：允許一個包訪問另一個包【access】
繫結：為模板引數賦值以生成一個新的模型元素【bind】
呼叫：宣告一個類呼叫其他類的方法【call】
匯出：宣告一個例項可以從另一個例項中到處【derive】
友元：允許一個元素訪問另一個元素而不論被訪問元素的可見性【friend】
引入：允許一個包訪問另一個包的內容並未被訪問包的組成部分新增別名【import】
例項化：關於一個類的方法生成了另一個類的例項的生命【instantate】
引數：一個操作和他引數之間的關係【parameter】
實現：說明和其實之間的對映關係【realize】
精化：宣告具有兩個不同層次上元素的對映關係【refine】
傳送：訊號傳送者和訊號接受者之間的關係【send】
跟蹤：宣告不同模型中元素之間的連線，沒有對映精確【trace】
使用：宣告使用一個模型元素需要已存在的另一個模型元素，這樣才能正確實現使用者的功能（呼叫，例項化，引數，傳送）【use】
6：約束
UML類圖關係中約束可以用來表示各種非區域性的關係，如關聯路徑上的限制。約束尤其可以用來表述存在特性（存在X則C條件成立）和通用特性（對於Y中的所有y，條件D必須成立）。
7：例項
例項是有身份標識的執行實體，即它可以與其他執行實體相區分。它在任何時刻都有一個值，隨著對例項進行操作值也會被改變。
———————————————————————————————————————————————–
類與類之間存在以下關係: (1)泛化(Generalization) (2)關聯(Association) (3)依賴(Dependency) (4)聚合(Aggregation) UML圖與應用程式碼例子: 1.泛化(Generalization) [泛化] 表示類與類之間的繼承關係，介面與介面之間的繼承關係，或類對介面的實現關係。一般化的關係是從子類指向父類的，與繼承或實現的方法相反。 [具體表現] 父類 父類例項＝new 子類() UML圖 圖1.1 Animal類與Tiger類,Dog類的泛化關係 [程式碼表現] class Animal{} class Tiger extends Animal{} public class Test { public void test() { Animal a=new Tiger(); } } 2.依賴(Dependency) [依賴] 對於兩個相對獨立的物件，當一個物件負責構造另一個物件的例項，或者依賴另一個物件的服務時，這兩個物件之間主要體現為依賴關係。 [具體表現] 依賴關係表現在區域性變數，方法的引數，以及對靜態方法的呼叫 [現例項子] 比如說你要去擰螺絲，你是不是要藉助(也就是依賴)螺絲刀(Screwdriver)來幫助你完成擰螺絲(screw)的工作 UML表現 圖1.2 Person類與Screwdriver類的依賴關係 [程式碼表現] public class Person{ /** 擰螺絲 */ public void screw(Screwdriver screwdriver){ screwdriver.screw(); } } 3.關聯(Association) [關聯] 對於兩個相對獨立的物件，當一個物件的例項與另一個物件的一些特定例項存在固定的對應關係時，這兩個物件之間為關聯關係。 [具體表現] 關聯關係是使用例項變數來實現 [現例項子] 比如客戶和訂單，每個訂單對應特定的客戶，每個客戶對應一些特定的訂單；再例如公司和員工，每個公司對應一些特定的員工，每個員工對應一特定的公司 [UML圖] (圖1.3) 圖1.3 公司和員工的關聯關係 [程式碼表現] public class Company{ private Employee employee; public Employee getEmployee(){ return employee; } public void setEmployee(Employee employee){ this.employee=employee; } //公司運作 public void run(){ employee.startWorking(); } } (4)聚合（Aggregation） [聚合] 當物件A被加入到物件B中，成為物件B的組成部分時，物件B和物件A之間為聚集關係。聚合是關聯關係的一種，是較強的關聯關係，強調的是整體與部分之間的關係。 [具體表現] 與關聯關係一樣，聚合關係也是通過例項變數來實現這樣關係的。關聯關係和聚合關係來語法上是沒辦法區分的，從語義上才能更好的區分兩者的區別。 [關聯與聚合的區別] (1)關聯關係所涉及的兩個物件是處在同一個層次上的。比如人和自行車就是一種關聯關係，而不是聚合關係，因為人不是由自行車組成的。 聚合關係涉及的兩個物件處於不平等的層次上，一個代表整體，一個代表部分。比如電腦和它的顯示器、鍵盤、主機板以及記憶體就是聚集關係，因為主機板是電腦的組成部分。 (2)對於具有聚集關係（尤其是強聚集關係）的兩個物件，整體物件會制約它的組成物件的生命週期。部分類的物件不能單獨存在，它的生命週期依賴於整體類的 物件的生命週期，當整體消失，部分也就隨之消失。比如張三的電腦被偷了，那麼電腦的所有元件也不存在了，除非張三事先把一些電腦的元件（比如硬碟和記憶體） 拆了下來。 UML圖 圖1.3 電腦和元件的聚合關係 [程式碼表現] public class Computer{ private CPU cpu; public CPU getCPU(){ return cpu; } public void setCPU(CPU cpu){ this.cpu=cpu; } //開啟電腦 public void start(){ //cpu運作 cpu.run(); } }
———————————————————————————————————————————————–
類圖及類圖中的關係 1.類圖和物件圖
類圖(Class Diagram)是顯示出類、介面以及他們之間的靜態結構與關係的圖。其中最基本的單元是類或介面。
類圖不但可以表示類(或者介面)之間的關係，也可以表示物件之間的關係。下面是一個典型的類圖：
類圖一般分為幾個部分：類名、屬性、方法。下面分別講解。
(1)類名
上面的Car就是類名，如果類名是正體字，則說明該類是一個具體的類，如果類名是斜體字，則說明類是一個抽象類abstract。
(2)屬性列表
屬性可以是public、protected、private。public前面的圖示是菱形，protected對應的是菱形加鑰匙，private對應的是菱形加鎖。當然，這只是一種表現方式。我是用的是Rational Rose，如果用的是別的軟體，還可能使用+、-、#表示：+代表public、-代表private、#代表protected。
(3)方法列表
方法可以是public、protected、private。public前面的圖示是菱形，protected對應的是菱形加鑰匙，private對應的是菱形加鎖。當然，這只是一種表現方式。我是用的是Rational Rose，如果用的是別的軟體，還可能使用+、-、#表示：+代表public、-代表private、#代表protected。
對於靜態屬性，屬性名會加上一條下劃線。如上圖所示。
此外，類圖既能表示類之間的關係，還能表示物件之間的關係。二者的區別是：物件圖中物件名下面會加上一條下劃線。
2.類圖中的關係
(1)Generalization：泛化、一般化
Generalization表示的是類與類之間的繼承關係、介面與介面之間的繼承關係、類與介面之間的實現關係。如果體現到Java語言中，那就是反應extends和implements關鍵字。其典型類圖如下所示：
(2)Association：關聯關係
關聯關係描述的是類與類之間的連線，他表示一個類知道另一個類的屬性和方法。關聯關係可以是單向的或者雙向的。在Java語言中，單向的關聯關係是通過以例項變數的方式持有被關聯物件的引用來實現的。一般來說是不建議使用雙向的關聯關係的。下面舉例介紹單向的關聯關係。
上面的類圖表現的是騎手和馬之間的關係。Rider中有一個例項變數型別是Horse。
每個連線都會有兩個端點，上面的Rider和Horse就是端點，且每個端點都可以有(optional)一個基數(multiplicity)，表示這個類可以有幾個例項。這個類似於資料庫中的1：n、m：n這些關係。我們可以給上面的例子加上基數：
上面表示的是騎手與馬之間的1對n關係。
(3)Aggregation：聚合關係
聚合關係是關聯關係的一部分，是非常強的關聯關係。聚合關係表現的更多的是整體與部分的關係。例如汽車和車門、發動機之間的關係。如圖所示：
與關聯關係一樣，聚合關係也是通過例項變數實現的。單純從語法的角度基本上無法判斷出關聯關係和聚合關係。
(4)Composition:組合關係
組合關係同樣也是關聯關係中的一種，這種關係是比聚合關係更加強的關係。我們前面提到，聚合關係表現的是整體與部分之間的關係，組合關係是在聚合關係的基礎上，表示不可分割的整體與部分之間的關係。也就是說表示整體的物件需要負責表示部分的物件的生命週期。
“代表整體的物件負責保持代表部分的物件的存活，在一些情況下負責將代表部分的物件湮滅掉。代表整體的物件某些時候可以將代表部分的物件傳遞給另外一個物件，並由它負責代表部分的物件的生命週期。換言之，代表部分的物件同一時刻只能與一個物件構成組合關係。並且由後者排他的負責其生命週期。”——《Java與模式》
我們以人和手臂的關係舉例，組合關係的類圖如下：
(5)Dependency：依賴關係
依賴關係表示一個類依賴於另一個類的定義。依賴關係是單方向的。人吃蘋果，那麼人依賴蘋果。類圖如下：
一般來說，被依賴的物件往往是以區域性變數、方法引數的形式存在於來物件中，與關聯關係不同，它不會以成員變數的形式存在於以來物件中。這一點值得注意。另外，每一個依賴都有一個名稱。上面這個依賴關係的名稱就是eats。