UML圖中類之間的關係:依賴,泛化,關聯,聚合,組合,實現
依賴關係（Dependence）：假設A類的變化引起了B類的變化，則說名B類依賴於A類。
- 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）：A是B和C的父類，B,C具有公共類（父類）A，說明A是B,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）:類之間的聯繫，如客戶和訂單，每個訂單對應特定的客戶，每個客戶對應一些特定的訂單，再如籃球隊員與球隊之間的關聯（下圖所示）。
- public class Customer
- {
- private Product[] products;
- ……
- }
- public class Product
- {
- private Customer customer;
- ……
- }
- public class Customer
- {
- private Address address;
- ……
- }
- public class Address
- {
- ……
- }
- public class Node
- {
- private Node subNode;
- ……
- }
|
表示方式 |
多重性說明 |
|
1..1 |
表示另一個類的一個對象只與一個該類對象有關係 |
|
0..* |
表示另一個類的一個對象與零個或多個該類對象有關係 |
|
1..* |
表示另一個類的一個對象與一個或多個該類對象有關係 |
|
0..1 |
表示另一個類的一個對象沒有或只與一個該類對象有關係 |
|
m..n |
表示另一個類的一個對象與最少m、最多n個該類對象有關係 (m<=n) |
- public class Form
- {
- private Button buttons[];
- ……
- }
- public class Button
- {
- …
- }
聚合關係（Aggregation）:表示的是整體和部分的關係，整體與部分 可以分開.
- 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）:也是整體與部分的關係，但是整體與部分不可以分開.
- public class Head
- {
- private Mouth mouth;
- public Head()
- {
- mouth = new Mouth();
- }
- ……
- }
- public class Mouth
- {
- ……
- }
如：公司和部門，部門是部分，公司是整體，公司A的財務部不可能和公司B的財務部對換，就是說，公司A不能和自己的財務部分開； 人與人的心臟.
實現關係（Implementation）：是用來規定接口和實線接口的類或者構建結構的關係，接口是操作的集合，而這些操作就用於規定類或者構建的一種服務。
- 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:類圖側重描述系統具體實現；
二：描述的方面都不相同，
1:類圖描述的是系統的結構，
2:序列圖描述的是系統的行爲；
三：抽象的層次也不同，
1：構件圖描述系統的模塊結構，抽象層次較高，
2：類圖是描述具體模塊的結構，抽象層次一般，
3：對象圖描述了具體的模塊實現，抽象層次較低。
在有的文獻書籍中，將這九種模型圖分爲三大類：
結構分類、動態行爲和模型管理：
1：結構分類包括用例圖、類圖、對象圖、構件圖和部署圖，
2：動態行爲包括狀態圖、活動圖、順序圖和協作圖，
3：模型管理則包含類圖。
畫圖說明
UML中有3種構造塊：事物、關係和圖，事物是對模型中最具有代表性的成分的抽象；關係是把事物結合在一起；圖聚集了相關的的事物。具體關係圖標如下：
說明：
構件事物是名詞，是模型的靜態部分。
行爲事物是動態部分，表示行爲。
分組事物是組織部分。
註釋事物是解釋部分。
聚集：特殊的關聯，描述整體與部分的組合關係。
泛化：是一種特殊與一般的關係，如子元素（特殊）與父元素（一般），箭頭指向父元素。
實現：類元之間的關係，其中一個類元指定了由另一個類元保證執行的契約。一般用在接口和實現他們的類之間或用例和實現它們的協作之間。
在UML系統開發中有三個主要的模型：
對象模型: 採用對象，屬性，操作，關聯等概念展示系統的結構和基礎，包括類圖。
動態模型: 展現系統的內部行爲。 包括序列圖，活動圖，狀態圖。
下面具體說明：
1.類圖：描述一組對象、接口、協作等事物之間的關係。如下圖(摘自網絡)：
3.用例圖：描述一組用例、參與者以及它們之間的關係，其展示的是該系統在它的外面環境中所提供的外部可見服務。如下圖(摘自網絡)：
4.交互圖：包括序列圖（順序圖）和協作圖，兩者對應，順序圖是強調消息時間順序，有對象生命線和控制焦點。協作圖是強調接收和發送消息的對象的結構組織，有路徑和順序號。如下圖(摘自網絡)：
5.狀態圖：展示了一個狀態機，由狀態、轉換、事件和活動組成。強調事件行爲的順序。如下圖(摘自網絡)：
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）。
活動終止節點表示整個活動的結束
而流程終止節點表示是子流程的結束。
使用關鍵字«datastore»
對象流是動作狀態或者活動狀態與對象之間的依賴關係，表示動作使用對象或動作對對象的影響。用活動圖描述某個對象時，可以把涉及到的對象放置在活動圖中並用一個依賴將其連接到進行創建、修改和撤銷的動作狀態或者活動狀態上，對象的這種使用方法就構成了對象流。
對象流中的對象有以下特點：
(1)、一個對象可以由多個動作操作。
(2)、一個動作輸出的對象可以作爲另一個動作輸入的對象。
(3)、在活動圖中，同一個對象可以多次出現，它的每一次出現表面該對象正處於對象生存期的不同時間點。
對象流用帶有箭頭的虛線表示。如果箭頭是從動作狀態出發指向對象，則表示動作對對象施加了一定的影響。施加的影響包括創建、修改和撤銷等。如果箭頭從對象指向動作狀態，則表示該動作使用對象流所指向的對象。
狀態圖中的對象用矩形表示，矩形內是該對象的名稱，名稱下的方括號表明對象此時的狀態。
10、分支與合併（Decision and
Merge Nodes）
分支與合併用菱形表示
分爲水平風向和垂直方向。
對象在運行時可能會存在兩個或多個併發運行的控制流，爲了對併發的控制流建模，UML中引入了分叉與匯合的概念。分叉用於將動作流分爲兩個或多個併發運行的分支，而匯合則用於同步這些併發分支，以達到共同完成一項事務的目的。
當受保護的活動發生異常時，觸發異常處理節點。
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<Order>();
}
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.舉例
//eg.1
//單向關聯
class Person{};
class Friend
{
Person* mpPerson;
};
//eg.2
//雙向關聯
class A;
class B
{
A* pA;
};
class A
{
B* pB;
};
//eg.3
//自身關聯
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)
圖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)
圖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.4)
圖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。
以上就是類圖和常見的類圖之間的關係。