（转载）依赖、关联、聚合、组合
?
?
?一、依賴關系(Dependence)
?
依賴關系（Dependence）：假設A類的變化引起了B類的變化，則說名B類依賴于A類。
?
? ?依賴關系(Dependency)?是一種使用關系，特定事物的改變有可能會影響到使用該事物的其他事物，在需要表示一個事物使用另一個事物時使用依賴關系。大多數情況下，依 ? ? ? 賴關系體現在某個類的方法使用另一個類的對象作為參數。 ? ??在UML中，依賴關系用帶箭頭的虛線表示，由依賴的一方指向被依賴的一方。?
依賴關系有如下三種情況：
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#中使用冒號“：”來實現。??
?
?
?
在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) ?雙向關聯:?默認情況下，關聯是雙向的。?
?
?
2 )?單向關聯:類的關聯關系也可以是單向的，單向關聯用帶箭頭的實線表示.4)?重數性關聯:?重數性關聯關系又稱為多重性關聯關系(Multiplicity)，表示一個類的對象與另一個類的對象連接的個數。在UML中多重性關系可以直接在關聯直線上增加一個數字表示與之對應的另一個類的對象的個數。
| 表示方式 | 多重性說明 |
| 1..1 | 表示另一個類的一個對象只與一個該類對象有關系 |
| 0..* | 表示另一個類的一個對象與零個或多個該類對象有關系 |
| 1..* | 表示另一個類的一個對象與一個或多個該類對象有關系 |
| 0..1 | 表示另一個類的一個對象沒有或只與一個該類對象有關系 |
| m..n | 表示另一個類的一個對象與最少m、最多n個該類對象有關系 (m<=n) |
?
?
?四、聚合關系（Aggregation）
?
聚合關系（Aggregation）:表示的是整體和部分的關系，整體與部分?可以分開.
?
? ?聚合關系(Aggregation)?表示一個整體與部分的關系。通常在定義一個整體類后，再去分析這個整體類的組成結構，從而找出一些成員類，該整體類和成員類之間就形成了聚合 ? 關系。 ? ?在聚合關系中，成員類是整體類的一部分，即成員對象是整體對象的一部分，但是成員對象可以脫離整體對象獨立存在。在UML中，聚合關系用帶空心菱形的直線表示。??
?
?
如：電話機包括一個話筒
???????電腦包括鍵盤、顯示器，一臺電腦可以和多個鍵盤、多個顯示器搭配，確定鍵盤和顯示器是可以和主機分開的，主機可以選擇其他的鍵盤、顯示器組成電腦；
?五、組合關系（Composition）
組合關系（Composition）:也是整體與部分的關系，但是整體與部分不可以分開.
?
? ?組合關系(Composition)也表示類之間整體和部分的關系，但是組合關系中部分和整體具有統一的生存期。一旦整體對象不存在，部分對象也將不存在，部分對象與整體對象之 ? ?間具有同生共死的關系。 ? ?在組合關系中，成員類是整體類的一部分，而且整體類可以控制成員類的生命周期，即成員類的存在依賴于整體類。在UML中，組合關系用帶實心菱形的直線表示。?
?
?
如：公司和部門，部門是部分，公司是整體，公司A的財務部不可能和公司B的財務部對換，就是說，公司A不能和自己的財務部分開；?人與人的心臟.
?
?六、實現關系（Implementation)
?
實現關系（Implementation）：是用來規定接口和實線接口的類或者構建結構的關系，接口是操作的集合，而這些操作就用于規定類或者構建的一種服務。
?
??接口之間也可以有與類之間關系類似的繼承關系和依賴關系，但是接口和類之間還存在一種實現關系(Realization)，在這種關系中，類實現了接口，類中的操作實現了接口中所 ? ? 聲明的操作。在UML中，類與接口之間的實現關系用帶空心三角形的虛線來表示。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狀態。
活動圖
活動圖表示在處理某個活動時，兩個或者更多類對象之間的過程控制流?；顒訄D可用于在業務單元的級別上對更高級別的業務過程進行建模，或者對低級別的內部類操作進行建模。根據我的經驗，活動圖最適合用于對較高級別的過程建模，比如公司當前在如何運作業務，或者業務如何運作等。這是因為與序列圖相比，活動圖在表示上”不夠技術性的”，但有業務頭腦的人們往往能夠更快速地理解它們。
活動圖的符號集與狀態圖中使用的符號集類似。像狀態圖一樣，活動圖也從一個連接到初始活動的實心圓開始。活動是通過一個圓角矩形（活動的名稱包含在其內）來表示的?；顒涌梢酝ㄟ^轉換線段連接到其他活動，或者連接到判斷點，這些判斷點連接到由判斷點的條件所保護的不同活動。結束過程的活動連接到一個終止點（就像在狀態圖中一樣）。作為一種選擇，活動可以分組為泳道（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之序列圖解析
序列圖主要用于展示對象之間交互的順序。
序列圖將交互關系表示為一個二維圖?？v向是時間軸，時間沿豎線向下延伸。橫向軸代表了在協作中各獨立對象的類元角色。類元角色用生命線表示。當對象存在時，角色用一條虛線表示，當對象的過程處于激活狀態時，生命線是一個雙道線。
消息用從一個對象的生命線到另一個對象生命線的箭頭表示。箭頭以時間順序在圖中從上到下排列。?
序列圖中涉及的元素：
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用于對系統的動態行為建模的另一種常用工具，它描述活動的順序，展現從一個活動到另一個活動的控制流。活動圖在本質上是一種流程圖?；顒訄D著重表現從一個活動到另一個活動的控制流，是內部處理驅動的流程。
一、活動圖的組成元素?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<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.從業務用例圖到活動圖
????? 完成了業務用例圖后，我們要為每一個業務用例繪制一幅活動圖?；顒訄D描述了這個業務用例中，用戶可能會進行的操作序列。活動圖有個很重要的使命：從業務用例分析出系統用例。例如，下面是“新聞管理”的活動圖：
????? 可以看到，一個“新聞管理”這個業務用例，分解出N多系統操作。這里要特別注意這些操作，其中很多“活動”都很可能是一個系統用例（當然，不是每個都是）。例如，由這個活動圖可以看出，系統中至少要包含以下備選系統用例：登錄、注銷登錄、查看新聞列表、修改新聞、刪除新聞。
????? 這樣，將每個業務用例都繪制出相應的活動圖，再將其中的“活動”整合，就得出所有備選系統用例。
????? 3.從活動圖到系統用例圖
????? 找出所有的備選系統用例后，我們要對他們進行合并和篩選。合并就是將相同的用例合并成一個，篩選就是將不符合系統用例條件的備選用例去掉。
??????一個系統用例應該是實際使用系統的用戶所進行的一個操作，例如，“查看新聞列表”就不能算一個系統用例，因為他只是某系統用例的一個序列項。
????? 最終我們得出的系統用例圖如下：
????? 4.從系統用例圖到用例規約
????? 得出系統用例圖后，我們應該對每一個系統用例給出用例規約。關于用例規約，沒有一個通用的格式，大家可以按照習慣的格式進行編寫。對用例規約唯一的要求就是“清晰易懂”。
????? 下面給出“登錄”這個系統用例的一個規約：
????? 5.繪制業務領域類圖
????? 完成了上面幾步，下面應該是繪制業務領域類圖了。所謂業務領域類圖要描述一下三點：
??????1.系統中有哪些實體。
????? 2.這些實體能做什么操作。
????? 3.實體間的關系。
????? 這里要特別強調：這里的實體不是Actor，而是Actor使用系統時使用的所調用的實體，是處在系統邊界之內的實體。例如，管理員就沒有作為一個實體出現在這里，因為管理員處在系統邊界之外，它所有的工作都可以通過調用這三個類的方法完成。并且，這里的“注冊會員”實體也不是剛才用例圖中注冊會員這個Actor，而是作為一個系統內的業務實體，供Actor們使用的。例如，其中的注冊功能是給注冊會員這個Actor使用，而移除則是給管理員這個Actor使用的。
????? 理解以上這段話非常重要，我經?？吹接捎诨煜藢嶓w和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的關系，這種關系比聚合更強，也稱為強聚合；他同樣體現整體與部分間的關系，但此時整體與部分是不可分的，整體的生命周期結束也就意味著部分的生命周期結束；比如你和你的大腦；表現在代碼層面，和關聯關系是一致的，只能從語義級別來區分；
對于繼承、實現這兩種關系沒多少疑問，他們體現的是一種類與類、或者類與接口間的縱向關系；其他的四者關系則體現的是類與類、或者類與接口間的引用、橫向關系，是比較難區分的，有很多事物間的關系要想準備定位是很難的，前面也提到，這幾種關系都是語義級別的，所以從代碼層面并不能完全區分各種關系；
但總的來說，后幾種關系所表現的強弱程度依次為：組合>聚合>關聯>依賴；
聚合跟組合其實都屬于關聯 只不過它們是兩種特殊的關聯 因為本是同根生 所以它們之間難免會有相似之處 下面讓我們一起來看一下它們之間有何不同
聚合與組合的概念相信不用我在此贅述大家就已經了解了 下面直接上例子
程老師的《大話》里舉大那個大雁的例子很貼切 在此我就借用一下 大雁喜歡熱鬧害怕孤獨 所以它們一直過著群居的生活 這樣就有了雁群 每一只大雁都有自己的雁群 每個雁群都有好多大雁 大雁與雁群的這種關系就可以稱之為聚合 另外每只大雁都有兩只翅膀 大雁與雁翅的關系就叫做組合 有此可見 聚合的關系明顯沒有組合緊密 大雁不會因為它們的群主將雁群解散而無法生存 而雁翅就無法脫離大雁而單獨生存——組合關系的類具有相同的生命周期
聚合關系圖：
組合關系圖：
從從代碼上看這兩種關系的區別在于：
構造函數不同
雁群類：
?
?
?
大雁類：
?
?
聚合關系的類里含有另一個類作為參數?
雁群類（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:組合關系
組合關系同樣也是關聯關系中的一種，這種關系是比聚合關系更加強的關系。我們前面提到，聚合關系表現的是整體與部分之間的關系，組合關系是在聚合關系的基礎上，表示不可分割的整體與部分之間的關系。也就是說表示整體的對象需要負責表示部分的對象的生命周期。
“代表整體的對象負責保持代表部分的對象的存活，在一些情況下負責將代表部分的對象湮滅掉。代表整體的對象某些時候可以將代表部分的對象傳遞給另外一個對象，并由它負責代表部分的對象的生命周期。換言之，代表部分的對象同一時刻只能與一個對象構成組合關系。并且由后者排他的負責其生命周期?！薄禞ava與模式》
我們以人和手臂的關系舉例，組合關系的類圖如下：
(5)Dependency：依賴關系
依賴關系表示一個類依賴于另一個類的定義。依賴關系是單方向的。人吃蘋果，那么人依賴蘋果。類圖如下：
一般來說，被依賴的對象往往是以局部變量、方法參數的形式存在于來對象中，與關聯關系不同，它不會以成員變量的形式存在于以來對象中。這一點值得注意。另外，每一個依賴都有一個名稱。上面這個依賴關系的名稱就是eats。
以上就是類圖和常見的類圖之間的關系。
</div>總結
以上是生活随笔為你收集整理的（转载）依赖、关联、聚合、组合的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Git中rebase的使用
- 下一篇： Java人力资源管理系统源码 HR源码