1.UML標准圖
1.介紹：
在UML中元素以不同的方式，表達了不同的圖表，我們通過不同類型的圖片或者圖表可以很直觀的了解任何復雜的系統，
這種方法以不同的形式被廣泛應用到不同的行業中。
一個單一的圖涵蓋所有方面的制度是不夠的，因此，UML 定義了各種圖表覆蓋系統方面。
我們將 UML 中的圖分為兩大類：
結構圖，行為圖
2.UML 結構圖：
UML 結構圖表示系統的靜態方面。這些靜態方面指示，形成的主要結構並因此穩定那些部分。
這些靜態部分是類，接口，對象，組件和節點四個結構圖：
類圖，對象圖，組件圖，部署圖
UML 類圖：
類圖是描述系統中的類，以及各個類之間的關系的靜態視圖，它包括：類、接口、關聯和協作。
類圖能夠讓我們在正確編寫代碼以前對系統有一個全面的認識。
類圖是一種模型類型，確切的說，是一種靜態模型類型。
活動類在類圖來表示系統的並發性。
類圖代表的面向對象的系統。
UML 對象圖：
對象圖與類圖極為相似，它是類圖的實例，對象圖顯示類的多個對象實例，而不是實際的類，它描述的不是類之間的關系，而是對象之間的關系。
從實際的角度來看，它們被用來建立一個系統的原型。
UML 組件圖：
組件圖描述代碼構件的物理結構以及各種構建之間的依賴關系。
組件圖用來建模軟件的組件及其相互之間的關系，這些圖由構件標記符和構件之間的關系構成。
組件圖中，構件時軟件單個組成部分，它可以是一個文件，產品、可執行文件和腳本等。
在設計階段的軟件構件（類，接口等）的系統被安排在不同的組，這取決於他們的關系。這些組被稱為組件。
組件圖用於可視化的實現。
UML 部署圖：
部署圖是用來建模系統的物理部署。例如計算機和設備，以及它們之間是如何連接的。
部署圖的使用者是開發人員、系統集成人員和測試人員。
部署圖是一組節點和它們之間的關系，這些節點部署這些組件的物理實體。
部署圖用於可視化系統的部署視圖。
ps:如果上述描述和用法仔細觀察，這是很清楚的，所有的圖表都彼此有某種關系。
組件圖是依賴的類，接口等類/對象圖的一部分。
再次部署圖是取決於使用的組件，這些組件，以使一個組件圖。
3.UML 行為圖：
定義：任何系統都可以有兩個方面，靜態和動態。因此，一個模型被認為是完成時，這兩個方面都完全覆蓋。
行為圖基本上捕捉系統的動態方面。動態方面可以進一步改變/移動系統的一部分。
UML具有以下五種行為圖：
用例圖，序列圖，協作圖，狀態圖，活動圖
UML 用例圖：
用例圖描述角色以及角色與用例之間的連接關系。
說明的是誰要使用系統，以及他們使用該系統可以做些什么。
一個用例圖包含了多個模型元素，如系統、參與者和用例，並且顯示了這些元素之間的各種關系，如泛化、關聯和依賴。
因此，用例圖是用來描述的功能之間的關系和他們的內部/外部控制器，這些控制器是已知的參與者。
UML 序列圖：
序列圖是一種交互圖。
序列圖是用來顯示你的參與者如何以一系列順序的步驟與系統的對象交互的模型。
序列圖可以用來展示對象之間是如何進行交互的。
序列圖將顯示的重點放在消息序列上，即強調消息是如何在對象之間被發送和接收的。
從實施和執行的角度來看是非常重要的系統組件之間的交互。
因此，在一個系統中執行一個特定的功能的調用序列的序列圖是用於可視化。
UML 協作圖：
協作圖和序列圖相似，是另一種形式的交互圖；如果強調時間和順序，則使用序列圖；如果強調上下級關系，則選擇協作圖。
協作圖代表了一個系統的組織結構和發送/接收的消息。組織結構由對象和鏈接。
協作圖的目的是類似的序列圖。
但是，協作圖的具體目的是可視化的組織對象及其相互作用。
UML 狀態圖：
狀態圖描述類的對象所有可能的狀態，以及事件發生時狀態的轉移條件。
狀態圖可以捕獲對象、子系統和系統的生命周期。
他們可以告知一個對象可以擁有的狀態，並且事件(如消息的接收、時間的流逝、錯誤、條件變為真等)會怎么隨着時間的推移來影響這些狀態。
狀態圖是用來表示的事件驅動的系統狀態的變化。
它基本上描述了類，接口狀態變化等狀態圖是用於可視化的反應系統內部/外部因素。
UML 活動圖：
活動圖描述了在一個系統中的控制流。
活動圖描述用例要求所要進行的活動，以及活動間的約束關系，有利於識別並行活動。
活動圖能夠演示出系統中哪些地方存在功能，以及這些功能和系統中其他組件的功能如何共同滿足前面使用用例圖建模的商務需求。
活動圖用於可視化的流量控制在一個系統中。
這是准備系統將如何工作，在執行時有一個想法。
ps:在一個系統中很難捕捉到動態性質，而 UML 已經提供從不同的角度捕捉到動態系統的功能。
序列圖和協作圖是同構的，它們之間的轉換不會丟失任何信息。
2.UML類圖
概念： 類圖（Class Diagram）是面向對象系統建模中最常用和最重要的圖，是定義其它圖的基礎。 類圖主要是用來顯示系統中的類、接口以及它們之間的靜態結構和關系的一種靜態模型。 類圖不僅用於可視化描述和記錄系統的不同方面，也為構建可執行代碼的軟件應用程序。 類圖描述一類的屬性和操作，也對系統的約束。 被廣泛應用於類圖的建模的面向對象的系統中，因為它們是唯一的，可以直接映射到面向對象的語言的 UML 圖。 類圖顯示集合的類，接口，關聯，協作和約束，它也被稱為作為結構圖。 UML 類圖的目的: 類圖的目的是模型的一個應用程序的靜態視圖。 類圖是唯一的圖可以直接映射到面向對象的語言，因此廣泛應用於施工時間。 UML 圖，像活動圖，序列圖圖只能給應用程序，但順序流類圖是一個有點不同。 所以它是最流行的 UML 圖編碼社區。 因此，類圖的目的可概括為： 分析和設計應用程序的靜態視圖。 描述一個系統的責任。 基地組件圖和部署圖。 正向和逆向工程。 如何畫類圖？ UML 類圖是軟件行業經常需要的一項技能。 許多項目立項文檔、需求分析等文檔中，都會有關UML類圖的涉及，所以，學習UML類圖的繪制至關重要。 繪制類圖時需要考慮的屬性較多，這里的圖將被視為從頂層視圖。 類圖基本上是一個系統的靜態視圖的圖形表示，代表不同方面的應用。 因此，集合類圖表示整個系統。 在畫類圖時要牢記以下幾點： 類圖中的名稱應該是有意義的描述，並且是面向系統的。 畫類圖前應先確定每個元素之間的關系。 類圖中的每個類職責（屬性和方法）應該清晰標明。 對於每個類的屬性的最小數量應符合規定，不必要的屬性將使圖表復雜。 使用了以下注釋有否要求來描述圖中的某些方面。因為上面的附圖，它應該是可以理解的開發者/編碼器。 最后，在最終版本之前，該圖應繪制在普通紙上盡可能多次，使其糾正和返工。 示例： 描述： 下圖是一個二階系統的一個應用程序的一個例子，它描述了整個應用程序的一個特定方面： 系統中的兩個要素是所有訂單以及客戶，他們有一個一對多的關系，因為一個客戶可以有多個訂單。 我們將保持 Order 類是一個抽象類，它有兩個具體的類（繼承關系）SpecialOrder 和 NormalOrder。 兩個繼承類 Order 類的所有屬性。此外，他們有額外的功能 dispatch () 和 receive (). 因此，下面的類圖已經繪就考慮到所有上述提到的幾點：
在哪里使用類圖？
類圖是一個靜態圖，它是用來模擬一個系統的靜態視圖，也被認為是類圖作為基礎組件圖和部署圖。
類圖不僅用於可視化系統的靜態視圖，但它們也可用於構建可執行代碼的任何系統中的前向和反向工程。
UML 圖一般不直接映射到任何面向對象的編程語言，但在類圖是一個例外。
類圖清楚地顯示了映射面向對象語言，如Java，C++等，因此，從實際經驗的類圖通常用於構建用途。
因此類圖可以用來：
描述系統的靜態視圖。
顯示靜態視圖中的元素之間的協作。
由系統執行的功能的描述。
構建軟件應用面向對象的語言。
3.UML對象圖
概述： UML 對象圖和類圖一樣反映系統的靜態過程，但它是從實際的或原型化的情景來表達的。 UML 對象圖顯示某時刻對象和對象之間的關系。 一個UML對象圖可看成一個類圖的特殊用例，實例和類可在其中顯示。 UML 對象圖是類圖的實例，幾乎使用與類圖完全相同的標識。 由於對象存在生命周期，因此UML對象圖只能在系統某一時間段存在。 UML 對象圖目的: 對象圖的目的與類圖類似。 不同的是，一個類圖代表一個抽象的模型，包括類和它們之間的關系。 但是，由於對象存在生命周期，因此UML對象圖只能在系統某一時間段存在。 這意味着對象圖是更接近實際的系統行為。 目的是在一個特定的時刻捕捉到靜態的系統視圖。 對象圖的目的概述如下： 正向和逆向工程。 一個系統的對象間的關系 一個交互的靜態視圖。 了解對象的行為和他們的關系從實用的角度來看 如何繪制對象圖？ 我們已經討論過的一個對象圖是類圖的一個實例。 它意味着一個對象圖包含在類圖中所用的東西的實例。 所以，對象圖和類圖的基本元素是相同的，不同的只是形式的差別。 在類圖中的元素是抽象的形式來表示藍圖，並在對象圖中元素的具體形式來表示真實世界中的對象。 為了捕捉一個特定的系統，類圖的數量是有限的。 但是，如果我們考慮對象圖，那么我們就可以有無限數量的實例在本質上是獨一無二的。 因此，只有這些情況下被認為是對系統的影響。 從上面的討論，很顯然，一個單一的對象圖不能捕獲所有必要的實例，而不能指定一個系統的所有對象。因此，解決方案是： 首先，分析系統，並決定哪些情況下有重要的數據和關聯。 其次，只考慮那些實例將涵蓋功能。 第三，做一些優化實例的數量是無限的。 繪制對象圖之前，應該記住以下事情，並清楚地理解： 對象圖的主要內容是對象。 對象圖中的鏈接是用來連接對象。 對象和鏈接的兩個要素，用於構造一個對象圖。 在開始構建圖前，下列事項要明確： 對象圖的名稱要有意義，以表明其目的。 最重要的要素是要確定。 對象之間的關聯，應該予以明確。 不同元素的值需要捕獲包含在對象圖。 添加適當的注釋，需要更清晰點。 示例： 描述：
下面的圖是一個對象圖的一個例子。它代表了訂單管理系統，我們已經討論了在類圖。 下圖是該系統的一個實例，在一個特定的時間購買。 它具有以下的對象：顧客，訂單，特殊訂單，一般訂單 現在客戶對象（C）是與三階對象（O1，O2和O3）。 這些訂單對象相關聯的特殊訂單和一般訂單對象（S1，S2和N1）。 顧客具有以下三個具有不同數目的訂單（12，32和40），用於所考慮的特定的時間。 現在，客戶可以在將來增加的訂單數量，在這種情況下對象圖將反映。 如果訂單、特殊訂單和正常秩訂單對象那么觀察會發現，他們有一些值。 訂單的值是12，32和40，這意味着，這些對象都擁有這些實例時，捕獲特定時刻的值（這里是購買時的時刻被視為特定時間）。 相同特別訂訂單和正常訂單對象所具有的訂單數分別為20，30和60。 如果被認為是一個不同的時間購買，那么這些值將發生相應的變化。 因此，下面的對象圖已經繪就考慮到所有上述提到的幾點：
在哪里使用對象圖？
對象圖可以被想象成正在運行的系統在某一時刻的快照。
我們可以舉一個例子來描述它：一個正在運行的列車。
現在，如果運行一個單元列車運行，那么會發現它具有以下靜態圖片：
這是一個特別的運行狀態
一個特定的乘客數量。如果捕捉在不同的時間，這將在不斷改變。
所以，在這里我們可以想像的列車運行的管理單元是一個對象，具有上述值。
任何現實生活中的簡單或復雜的系統而且的確如此。
對象圖可用於：
使一個系統的原型。
逆向工程。
造型復雜的數據結構。
從實用的角度了解系統。
捕捉實例和鏈接。
詳細描述瞬態圖。
4.UML組件圖
概述： UML 組件圖（Component Diagram）又稱為構件圖，他描述的是在軟件系統中遵從並實現一組接口的物理的、可替換的軟件模塊。 組件圖 = 構件（Component）+接口（Interface）+關系（Relationship）+端口（Port）+連接器（Connector） UML 組件圖給提供了將要建立的系統的高層次的架構視圖，這將幫助開發者開始建立實現的路標，並決定關於任務分配及（或）增進需求技能。 UML 組件圖目的: 組件圖是一種特殊的 UML 圖。 與我們之前討論的 UML 圖標的目的都不同。 組件圖不描述該系統的功能，但它描述了用於使這些功能的組件。 所以從這一點來說，組件圖用於可視化在一個系統中的物理組件。 這些組件包括庫，程序包，文件等。 組件圖也被描述為一個靜態的實施的系統視圖，在一個特定的時刻，靜態執行代表組織的組成部分。 一個單一的組件圖不能代表整個系統，但圖的集合可用來代表整個。 組件圖的目的概括如下： 可視化系統的組成部分。 構建的可執行文件，使用正向和反向工程。 描述的組織和組件的關系。 如何繪制組件圖？ 組件圖是用來描述一個系統的物理構件。 此神器包括文件，可執行文件，庫等。 所以這張圖的目的是不同的，組件圖的過程中使用的應用程序的實施階段。 但它准備提前以可視化的實現細節。 最初，系統的設計使用不同的UML圖，然后構件是現成的組件圖是用來得到一個想法的實現。 此圖是非常重要的，因為如果沒有它，應用程序不能有效地實施。 精心准備的組件圖在其他方面也是很重要的，如應用程序的性能，維護等 所以在繪制組件圖后的工件是清楚可辨： 在系統中使用的文件。 庫和其他構件的申請有關。 構件之間的關系。
示例：
描述：
訂單管理系統的組件圖，其中的構件是文件。
該圖顯示了在應用程序的文件以及它們之間的關系。
在實際組件圖還包含 dll 文件，庫，文件夾等。
在下面的圖中，四個文件識別，並產生了它們之間的關系。
到目前為止討論與其他 UML 圖，組件圖不能直接匹配。
因為它是得出完全不同的目的。
所以下面的組件圖已經繪就考慮到所有上述提到的幾點：
在哪里使用組件圖？
UML 組件圖經常是一個架構師在項目的初期就建立的非常重要的圖，它是無價的，因為它們模型化和文檔化了一個系統的架構。
UML 組件圖文檔化了系統的架構，開發者和系統可能的系統管理員會發現這一工作的關鍵產品有助於他們理解系統。
UML 組件圖也視為軟件系統配置圖的輸入，這將會是本系列后面的文章主題。
我們已經說過組件圖可用於可視化系統的靜態實現視圖，它是特殊類型的 UML 圖，它描述了在一個系統中的組件組織。
組織機構可以進一步描述為在一個系統中的組件的位置。這些組件是在一個特殊的組織方式，以滿足系統要求。
正如我們已經討論過這些組件庫，文件，可執行文件等，現在組織實施這些組件的應用程序。
組件圖的使用可以被描述為：
組件建模的一個系統。
模型的數據庫架構。
模型的應用程序的可執行文件。
模型系統的源代碼。
5.UML部署圖
概述：
部署圖由節點以及節點之間的關系組成。
部署圖描述的是系統運行時的結構，展示了硬件的配置及其軟件如何部署到網絡結構中。
部署圖通常用來幫助理解分布式系統，一個系統模型只有一個部署圖。
部署圖用於可視化的軟件組件部署的系統中的物理組件的拓撲結構。
部署圖是用來描述一個系統的靜態部署視圖。
UML 部署圖元素
結點（Node）：
結點是存在與運行時的代表計算機資源的物理元素，
可以是硬件也可以是運行其上的軟件系統，比如64主機、
Windows server 2008操作系統、防火牆等。
結點用三維盒裝表示，如下圖所示：
結點實例（Node Instance）：
結點實例的命名格式：Node Instance : node。
它與結點的區別在於名稱有下划線和結點類型前面有冒號，冒號前面可以有示例名稱也可以沒有示例名稱，如下圖：
結點類型（Node Stereotypes）：
結點類型有：cdrom、cd-rom、computer、disk array、pc、pc client、pc server、secure、server、storage、unix server、user pc，
並在結點的右上角用不同的圖標表示，如下圖：
物件（Artifact）：
物件是軟件開發過程中的產物，包括過程模型（比如用例圖、設計圖等等）、源代碼、
可執行程序、設計文檔、測試報告、需求原型、用戶手冊等等。物件表示如下，帶有關鍵字 artifact 和文檔圖標
連接（Association）：
結點之間的連線表示系統之間進行交互的通信路徑，這個通信路徑稱為連接（Association），
如下圖所示，連接中有網絡協議：
結點容器（Node as Container）：
一個結點可以包括其他的結點，比如組件或者物件，則稱此結點為結點容器（Node as Container）。
如下圖所示，結點（Node）包容了物件（Artifact）：
UML 部署圖目的:
部署圖與組件圖密切相關，部署圖是用來描述軟件組件部署的硬件組件；
而組件圖是用來描述組件和顯示了它們是如何在硬件中部署。
UML的設計主要是把重點放在系統的軟件構件。
但是，這兩個圖是使用特殊圖表專注於軟件組件和硬件組件。
所以大多數的 UML 圖是用來處理邏輯組件，但把重點放在系統的硬件拓撲部署圖。
以下是部署圖的目的描述：
可視化系統的硬件拓撲。
描述用於部署軟件組件的硬件組件。
描述運行時處理節點。
如何繪制 UML 部署圖？
部署圖對系統工程師是非常有用。
一個高效的部署圖是非常重要的，因為它控制以下參數：
性能，可擴展性，可維護性，可移植性
在繪制部署圖前應確定以下構件：
節點，節點之間的關系
下列部署圖是一個樣品給訂單管理系統的部署視圖的想法，已經表明的節點：
監控，調制解調器，緩存服務器，服務器
假定應用程序是一個基於 Web 的應用程序部署在集群環境中使用服務器1，服務器2和服務器3。
用戶連接到使用互聯網的應用程序。控制流從緩存服務器的集群環境中。
所以下面的部署圖已經制定考慮到所有上述提到的幾點：
在哪里使用部署圖？
部署圖主要用於系統工程師。
這些圖用來描述的物理組件（硬件）以及它們的分布和關聯。
為了闡述清楚細節，我們可以想像的硬件組件/節點上的軟件組件位於部署圖。
軟件應用程序的開發需要復雜的業務流程模型。為了滿足業務的需求，一個軟件應用只做到高效是不夠的，
還應考慮到業務是否能夠支持用戶的不斷增長以及響應的時間是否夠快等。
軟件應用程序可以是獨立的，基於 Web，分布式，基於大型機和更多。
使用部署圖可以描述如下：
為了模擬一個系統的硬件拓撲。
嵌入式系統建模。
為了模擬一個客戶機/服務器系統的硬件的詳細信息。
為了模擬硬件的分布式應用程序的細節。
正向和逆向工程。
6.UML用例圖
概述： 用例圖捕捉了模擬系統中的動態行為，並且描述了用戶、需求以及系統功能單元之間的關系。 用例圖展示了一個外部用戶能夠觀察到的系統功能模型圖。 用例圖由主角，用例和它們之間的關系組成。 UML 用例圖的目的: 用例圖的目的是捕捉到一個系統的動態方面。 用例圖是用來收集系統的要求，包括內部和外部的影響。 這些要求大多是設計要求。 所以，分析一個系統時要收集其功能用例和確定參與者。 簡單來說，用例圖的目的如下： 用例圖用來收集系統的要求。 用例圖用於獲取系統的外觀圖。 用例圖識別外部和內部因素影響系統。 用例圖顯示要求之間的相互作用是參與者。 如何畫用例圖？ 用例圖被認為是高層次的需求分析系統。 因此，當系統的要求，分析被捕獲在用例的功能。 因此，我們可以說，使用情況是什么，但在一個有組織的方式編寫的系統功能。 現在到用例相關的第二件事情是參與者。 行為者可以被定義為與系統進行交互的東西。 參與者可以是人的用戶，一些內部的應用程序，或可能會有一些外部應用程序。 因此，在一個簡短的，當我們正計划繪制一個用例圖中應該有以下項目: 功能被表示為一個用例 參與者 用例和參與者之間的關系。 繪制到用例圖捕獲系統的功能要求。 因此，確定上述項目后，我們必須遵循以下指導原則，繪制一個有效的用例圖： 1.一個用例的名稱是非常重要的。所以名的選擇應以這樣的方式，以便它可以識別執行的功能 2.給出一個合適的名參與者。 3.圖中清楚地顯示關系和依賴性。 4.不要試圖包括所有類型的關系。由於該圖的主要目的是確定要求。 5.使用注意以往任何時候都需要闡明一些重要的點。 示例： 描述： 下面是一個示例用例圖，代表訂單管理系統。 因此，如果我們看看圖，那么我們會發現三個用例（訂單，特殊訂單和正常訂單）和一個參與者：顧客。 SpecialOrder 和NormalOrder 從訂單使用情況擴展。 因此，他們擴展了關系。另外很重要的一點是確定系統邊界，這是圖中所示。 參與者是客戶以外的系統，因為它是系統的外部用戶。
用例圖怎么使用？
要了解一個系統的動態，我們需要使用不同類型的圖表。
用例圖就是其中之一，其具體目的是收集系統的的需求和參與者。
用例圖指定系統的事件和他們的流向。
但從未用例圖描述了他們是如何實現的。
可以被想象成一個黑盒子，只有輸入，輸出和黑盒子的功能被稱為用例圖。
在這些圖中使用的設計在一個非常高的水平。
那么這種高層次的設計高雅，一遍又一遍完善使系統得到一個完整實用的圖片。
一個結構良好的用例，還介紹了前置條件，后置條件和例外。
而這些多余的元素在執行測試時被用來制造測試的情況下。
用例都不是正向和反向工程，但他們仍然使用略有不同的方式。
同樣是真實的逆向工程。
仍用例圖的使用方式不同，使其逆向工程的一個候選。
在正向工程用例圖是用來做測試案例和逆向工程中的使用情況下是用來准備從現有的應用程序的需求細節。
所以下面的地方使用用例圖：
需求分析和高水平的設計。
模擬系統的上下文。
逆向工程。
Forward engineering.
7.UML交互圖
概述：
UML 交互圖描述的是對象之間的動態合作關系以及合作過程中的行為次序。
UML 交互圖常常用來描述一個用例的行為，顯示該用例中所涉及的對象以及這些對象之間的消息傳遞情況，即一個用例的實現過程。
UML 交互圖包括兩種：序列圖和協作圖。
序列圖 ：顯示對象之間的關系，強調對象之間消息的時間順序，顯示對象之間的交互。
協作圖 ：描述對象之間的交互關系。
UML 交互圖作用:
UML 交互圖主要包括對象和消息兩類元素，創建交互圖的過程實際上就是向對象分配任務的過程，是可視化系統的交互行為。
由於可視化的交互是一個困難的任務，所以要使用不同類型的模型來捕獲不同方面的相互作用，這也是序列圖和時序圖的作用。
總而言之，對交互圖的描述如下：
交互圖捕捉一個系統的動態行為；
交互圖用來描述該系統中的消息流；
交互圖用來描述對象的結構組織；
交互圖是為了描述對象之間的互動。
UML 交互圖如何繪制？
我們已經了解了交互圖的作用就是捕捉系統的動態環節。
因此，關於動態捕捉，我們需要知道一個動態的環節是如何實現可視化的。
動態環節可以定義為在一個特定的時刻運行的系統快照。
在繪制交互圖之前，確定以下條件：
參與互動的對象；
對象之間的消息流；
消息的順序流程；
對象的組織。
示例：
描述：描述了兩個交互圖建模的訂單管理系統：第一個圖是序列圖，第二個圖是協作圖。
序列圖：
序列圖中包含了四個對象：客戶、訂單、特殊訂單和正常訂單。
下面的關系圖所示的消息序列為 SpecialOrder 對象和 NormalOrder 對象在相同的情況下使用。
現在重要的是要了解時間順序的消息流，與消息流無關，使用一個對象的方法調用。
步驟：
首先調用的是 sendOrder（），這是一個訂單對象的方法；
在下一次調用 confirm ()，這是一個 SpecialOrder 對象的方法；
最后調用 Dispatch ()，它是一種方法的 SpecialOrder 對象。
所以這里的圖主要描述方法從一個對象到另一個對象的調用，在系統運行時這也是實際情況：
協作圖：
協作圖顯示對象的組織，如下圖所示。
這里協作圖的方法調用序列是表示，由一些數字技術，如下所示。
該數字表示方法如何被稱為此起彼伏。我們已經采取了相同的訂單管理系統，協作圖來描述。
這些調用方法類似的序列圖。但不同的是，序列圖中未介紹的對象組織，而協作圖中示出的對象的組織。
現在選擇這兩個圖表之間主要強調的是需求類型。
如果時間序列是很重要的，那么序列圖中被使用，並且，如果需要的組織，那么使用協作圖。
使用交互圖的場合
我們現在來討論交互圖在實際情況中的應用。
要了解實際應用中，我們需要了解的基本性質序列圖和協作圖。
這兩個圖的主要目的，是相似的，因為它們是用來捕捉系統的動態行為：序列圖是用來捕獲從一個對象到另一個消息流的順序；協作圖用來描述參與相互作用中的對象的結構組織。
一個單一的圖是不足以說明整個系統的動態環節，這樣的一套圖是用來捕獲一個整體。
使用交互圖，當我們想要了解的消息流和組織結構。
消息流裝置控制流從一個對象到另一個序列和結構組織的裝置，在一個系統中的元素的視覺組織。
以下是交互圖的用法：
按時間順序的控制流建模。
為了模擬流結構組織控制。
對於正向工程。
逆向工程。
8.UML狀態圖
概述： UML 狀態圖是圖表本身的名稱，主要用於描述對象具有的各種狀態、狀態之間的轉換過程以及觸發狀態轉換的各種事件和條件。 UML 狀態圖描述了一個狀態機，可以被定義為一台機器，它定義了一個對象，這些狀態控制外部或內部事件的不同狀態。 狀態機由狀態、轉換、事件、活動和動作五部分組成。 1.狀態： 狀態指的是對象在其生命周期中的一種狀況， 處於某個特定狀態中的對象必然會滿足某些條件、 執行某些動作或者是等待某些事件。 一個狀態的生命周期是一個有限的時間階段。 2.轉換： 轉換指的是兩個不同狀態之間的一種關系， 表明對象在第一個狀態中執行一定的動作， 並且在滿足某個特定條件下由某個事件觸發進入第二個狀態。 3.事件： 事件指的是發生在時間和空間上的對狀態機來講有意義的那些事情。 事件通常會引起狀態的變遷，促使狀態機從一種狀態切換到另一種狀態， 如信號、對象額度創建和銷毀等。 4.活動：活動指的是狀態機中進行的非原子操作。 5.動作： 動作指的是狀態機中可以執行的哪些原子操作。 所謂原子操作，指的是他們在運行的過程中不能被其他消息中斷， 必須一直執行下去，以至最終導致狀態的變更或者返回一個值。 UML 狀態圖的目的: UML 狀態圖可以捕獲對象、子系統和系統的生命周期， 可以告知一個對象可以擁有的狀態， 並且事件(如消息的接收，時間的流逝、錯誤、條件為真等)會 怎樣隨着時間的推移來影響這些狀態。 一個狀態圖應該連接到所有具有清晰的可標志狀態和復雜行為的類； 該圖可以確定類的行為以及該行為如何根據當前的狀態而變化， 也可以展示哪些事件將會改變類的對象的狀態。 狀態圖主要是為了模擬響應系統。 以下是使用狀態圖的主要目的： 為了模擬系統的動態環節。 反應系統模型生命周期。 一個對象來描述不同的狀態，在其生命周期的時間。 定義一個狀態機模型狀態的對象。 UML 狀態圖怎么畫 狀態圖是用來描述不同的對象在其生命周期的狀態。 因此，強調的是一些內部或外部事件的狀態發生變化時， 這些對象的狀態要重要的分析和准確的貫徹落實。 狀態圖描述的狀態是非常重要的。 對象的狀況，當發生特定事件時，可以被確定為狀態。 繪制狀態圖之前，我們必須明確以下幾點： 識別對象，以進行分析。 識別狀態。 識別的事件。 ps:一個狀態圖（Statechart Diagram）本質上就是一個狀態機， 或者是狀態機的特殊情況，它基本上是一個狀態機中元素的一個投影， 這也就意味着狀態圖包括狀態機的所有特征。 狀態圖描述了一個實體基於事件反映的動態行為， 顯示了該實體是如何根據當前所處的狀態對不同的事件作出反應的。 重點： 在UML中，狀態圖由表示狀態的節點和表示狀態之間轉換的帶箭頭的直線組成。 狀態的轉換由事件觸發，狀態和狀態之間由轉換箭頭連接。 每一個狀態圖都有一個初始狀態（實心圓）， 用來表示狀態機的開始。還有一個中止狀態（半實心圓），用來表示狀態機的終止。 狀態圖主要由元素狀態、轉換、初始狀態、 中止狀態和判定等組成，一個簡單的狀態圖如下：
說明：
1.狀態：
狀態用於對實體在其生命周期中的各種狀況進行建模，一個實體總是在有限的一段時間內保持一個狀態。
狀態由一個帶圓角的矩形表示，狀態的描繪素應該包括名稱、入口和出口動作、內部轉換和嵌套狀態。
如下圖，為一個簡單狀態：
參數說明：
1）狀態名指的是狀態的名字，通常用字符串表示，其中每個單詞的首字母大寫。
狀態名可以包含任意數量的字母、數字和除了冒號“：”以外的一些字符，可以較長，甚至連續幾行。
但是一定要注意一個狀態的名稱在狀態圖所在的上下文中應該是唯一的，能夠把該狀態和其他狀態區分開。
2）入口和出口動作一個狀態可以具有或者沒有入口和出口動作。
入口和出口動作分別指的是進入和退出一個狀態時所執行的“邊界”動作。
3）內部轉換指的是不導致狀態改變的轉換。
內部轉換中可以包含進入或者退出該狀態應該執行的活動或動作。
4）嵌套狀態狀態分為簡單狀態（Simple State）和組成狀態（Composite State）。
簡單狀態是指在語義上不可分解的、對象保持一定屬性值的狀況，簡單狀態不包含其他狀態：
而組成狀態是指內部嵌套有子狀態的狀態，在組成狀態的嵌套狀態圖部分包含的就是此狀態的子狀態。
2.轉換
在UML的狀態建模機制中，轉換用帶箭頭的直線表示，一端連接源狀態，箭頭指向目標狀態。
轉換還可以標注與此轉換相關的選項，如事件、監護條件和動作等，如下圖所示。
注意：如果轉換上沒有標注觸發轉換的事件，則表示此轉換自動進行。
在狀態轉換機制中需要注意的五個概念如下：
1)狀態源（Source State）：指的是激活轉換之間對象處於的狀態。
如果一個一個狀態處於源狀態，當它接收到轉換的觸發事件或滿足監護條件時，就激活了一個離開的轉換。
2)目標狀態（Event State）：指的是轉換完成后對象所處的狀態。
3)事件觸發器（Event Trigger）：指的是引起源狀態轉換的事件。
事件不是持續發生的，它只發生在時間的一點上，對象接收到事件，
導致源狀態發生變化，激活轉換並使監護條件得到滿足。
4)監護條件（Guard Condition）：是一個布爾表達式。
當接收到觸發事件要觸發轉換時，要對該表達式求值。
如果表達式為真，則激活轉換：如果表達式為假，則不激活轉換，所接收到的觸發事件丟失。
5)動作（Action）：是一個可執行的原子計算。
3.初始狀態
每個狀態圖都應該有一個初始狀態，它代表狀態圖的起始位置。
初始狀態是一個偽狀態（一個和普通狀態有連接的假狀態），對象不可能保持在初始狀態，
必須要有一個輸出的無觸發轉換（沒有事件觸發器的轉換）。
通常初始狀態上的轉換是無監護條件的，並且初始狀態只能作為轉換的源，
而不能作為轉換的目標。在UML中，一個狀態圖只能有一個初始狀態，用一個實心圓表示。
4.終止狀態
終止狀態是一個狀態圖的終點，一個狀態圖可以擁有一個或者多個終止狀態。
對象可以保持在終止狀態，但是終止狀態不可能有任何形式的和觸發轉換，
它的目的就是為了激發封裝狀態上的轉換過程的結束。
因此，終止狀態只能作為轉換的目標而不能作為轉換的源，在UML中，終止狀態用一個含有實心圓的空心圓表示。
5.判定
活動圖和狀態圖中都有需要根據給定條件進行判斷，然后根據不同的判斷結果進行不同轉換的情況。
實際就是工作流在此處按監護條件的取值發生分支，在UML中，判定用空心菱形表示。
狀態圖的作用
狀態圖的作用主要體現在以下幾個方面。
(1)狀態圖清晰地描述了狀態之間的轉換順序，通過狀態的轉換順序也就可以清晰地看出事件的執行順序。如果沒有狀態圖我們就不可避免地要使用大量文字來描述外部事件的合法順序。
(2)清晰的事件順序有利於程序員在開發程序時避免出現事件順序錯誤的情況。
例如，對於一個網上銷售系統，在用戶處於登錄狀態前是不允許購買商品的，這就需要程序員開發程序的過程中加以限制。
(3)狀態圖清晰地描述了狀態轉換時所必需的觸發事件、監護條件和動作等影響轉換的因素，有利於程序員避免程序中非法事件的進入。
例如，飛機起飛前半小時不允許售票，在狀態圖中就可以清晰地看到，可以提醒程序員不要遺漏這些限制條件。
(4)狀態圖通過判定可以更好地描述工作流因為不同的條件發生的分支。
例如，當一個班的人數少於10人的時候需要和其他班合為一班上課，大於10人則單獨上課，在狀態圖中就可以很明確地表達出來。
總結：總之一個簡潔完整的狀態圖可以幫助一個設計者不遺漏任何事情，最大程度地避免程序中錯誤的發生
9.UML活動圖
概述：
UML 活動圖是 UML 的動態模型的一種圖形，一般用來描述相關用例圖。
UML 活動圖描述滿足用例要求所要進行的活動以及活動間的約束關系，有利於識別並行活動。
UML 活動圖是一種特殊的狀態圖，它對於系統的功能建模特別重要，強調對象間的控制流程。
UML 活動圖是一種表述過程基理、業務過程以及工作流的技術。它可以用來對業務過程、工作流建模，也可以對用例實現甚至是程序實現來建模
UML 活動圖基本上是代表流程形成一個活動到另一個活動的流程圖。活動可以被描述為一個系統的操作。
UML 活動圖目的:
UML 活動圖能夠捕捉到該系統的動態行為，UML 中其它的四個圖是用來顯示從一個對象到另一個消息流，但活動圖是用來顯示消息流從一個活動到另一個活動圖。
活動圖不僅用於可視化系統的動態性質，也可用於通過使用正向和逆向工程技術來構建可執行的系統。唯一缺少的東西在活動圖的消息部分。
它並不顯示任何消息流程從一個活動到另一個。
活動圖是一段時間視為流程圖。
雖然圖中看起來像一個流程圖，但事實並非如此。
它顯示不同的流程，如並行，分支，並發單。
以下是 UML 活動圖目的描述：
繪制活動流程系統。
描述的順序從一個活動到另一個。
描述系統並行，分支，並發流。
UML 活動圖怎么畫
活動圖主要用於為流程圖包括由系統執行的活動，但活動圖是不完全的，因為他們有一些額外的功能流程圖。
這些額外的功能，包括分支，平行流，泳道等。
繪制活動圖之前，我們得知道活動圖的主要元素是活動本身，一個活動是由系統執行的功能。
確定活動后，我們需要了解他們是如何相關的約束和條件。
所以在繪制活動圖，我們應該確定以下要素：
活動，交互，條件，約束
上述參數確定后，我們需要做一個心理布局整個流程。這種心理的布局轉化成一個活動圖。
示例
下面是一個訂單管理系統的活動圖的例子，在圖中確定了四個活動都與條件。
其中重要的一點應該清楚地了解活動圖不能完全匹配的代碼。活動圖了解活動流程，主要用於企業用戶。
下圖繪制的四個主要活動：
由客戶發送訂單，收到訂單，確認訂單，分發訂單
收到訂單后請求狀態進行檢查，以檢查它是否是正常的或特殊的順序。
不同的順序確定之后，執行調度活動，並標記為終止進程。
活動圖怎么使用
活動圖是適用於該系統的活動流程建模。
應用程序可以有多個系統。
活動圖也抓住了這些系統，並介紹了流程從一個系統到另一個。
在其他圖中，這個特定的用法，不提供。
這些系統可以是數據庫，外部隊列或任何其他系統。
現在，我們將看看活動圖到實際應用。
從上面的討論，很顯然，活動圖是來自一個非常高的級別。
因此，它給出了一個系統的高級視圖。
這種高層次的觀點主要是針對企業用戶或任何其他人而不是一個技術人員。
以下是活動圖的主要用途：
使用業務建模工作流程。
建模的業務需求。
高層次的理解系統的功能。
調查在后一階段的業務需求。
10.UML2.0版本
概述： UML 2.0 中增加了新的功能，所以它的使用可以更廣泛。 UML 2.0 將正式和完全定義語義的定義。 這種新的可能性可以用於模型的開發，並從這些模型可以產生相應的系統。 但要利用這個新的層面，必須作出相當大的努力，獲得知識。 UML2.0 新的層面： UML 的結構和文檔 UML2.0 的最新版本進行了全面修訂。現在有兩個文件，描述 UML： （1）UML2.0 結構的定義是基於 UML 語言的基本結構。 本節是 UML 的用戶並不直接相關。這是指向對建模工具的開發。 所以，這方面不在本節的范圍內。 （2）UML2.0 上蓋定義 UML2.0 的用戶結構。 這意味着這些用戶將立即使用的 UML 元素。 因此，這是UML的用戶群體的主要焦點。 UML 2.0 創建完成一個目標，調整和完善 UML，以便簡化可用性，實施和適應。 使用 UML 基礎設施： （1）提供了一個可重用的元語言的核心。這是用來定義 UML 本身。 （2）提供機制調整的語言。 使用 UML 上層建築： （1）基於組件的發展提供更好的支持。 （2）提高架構規范構造。 （3）提供更好的選擇行為建模。 所以很重要的一點要注意的是上述的主要分部。 這些區划是用來增加UML的可用性和定義清楚地了解它的用法。 另外一個方面，已經提出了這個新版本。 它是一個完全新的對象約束語言（OCL）和圖交匯處的建議。 這些功能都一起形成完整的UML2.0包。 UML 2.0 建模圖： 建模的相互作用： UML2.0 中描述的交互圖與舊版本相比有所不同，主要的區別是增強和附加功能添加到 UML2.0 圖。 UML2.0 模型對象以四個不同的方式互動： （1） 通過序列圖中的對象之間的交互來完成， 系統的行為目標是一個隨時間變化的圖。 時間序列是類似於早期版本的序列圖。 在系統內的設計上的交互，可以在任何級別的抽象設計，從子系統交互的實例級。
（2）UML2.0 中添加了一個新的名字：通信圖。
通信圖是對象之間的消息傳遞，來自於 UML1.4 的協作圖和更早的版本概念的結構圖。
這可以定義為協作圖的修改版本。
（3）UML2.0 也是一個新的互動概述圖。
一組組合成一個邏輯順序的相互作用，包括流量控制邏輯之間的互動導航的互動概述圖描述了一個高層次的。
（4）UML2.0 還增加了時序圖。這是一個可選的設計的一個交互的過程中發送和接收的消息中指定的時間限制的圖。
總結：因此，從上面的描述中，重要的是要注意，所有的圖的目的是發送/接收消息。
載入這些消息的裝卸內部的對象。
所以對象也有接收和發送郵件的選項，這里談到的另一個重要方面稱為接口。
現在，這些接口是負責接受和發送消息到另一個。
因此，從上面的討論可以得出結論，UML2.0中相互作用以不同的方式描述的，
這就是為什么進入圖片所遇到的新的圖名。但是，如果我們分析了新的圖，那么很顯然，
根據在早期版本中所描述的交互圖創建的所有圖。唯一的區別是UML2.0添加附加功能。使圖更高效和目的導向。
UML2.0 建模協作：
正如我們已經討論過的，協作是用來模擬常見的物體之間的相互作用。
要闡明的話，我們可以說，協作是互動對象由一組消息預先定義的角色。
最重要的一點要注意的是協作圖的早期版本，並在UML2.0版本之間的差異。
因此，區分協作圖名稱已更改於UML2.0。它被命名為UML2.0通信圖。
因此，協作被定義為一類的屬性（屬性）和行為（操作）的協作類上的隔間可以用戶定義的也可用於相互作用（時序圖）的構成要素（組合結構圖）。
下圖模型的觀察者設計模式之間的協作對象觀察到的項目中的作用，以及任何數量的觀察員的對象。
UML2.0 建模通信：
通信圖協作圖的早期版本略有不同。
我們可以說，它是一個縮減版的早期版本的UML。
通信圖的區別因素是在對象之間的鏈接。
這是一個可視化的鏈接，它缺少的序列圖。
在序列圖只顯示對象之間傳遞的消息，即使有它們之間沒有聯系。
通信圖是建模人員是用來防止這樣的錯誤，通過使用一個對象圖的格式作為消息傳遞的基礎。
通信圖上每個對象被稱為對象生命線。
通信圖的消息類型是相同的序列圖。
通信圖可以模擬同步，異步，返回，丟失，發現，和對象的創建消息。
下圖顯示了三個對象的對象圖和兩個環節，形成了基礎通信圖是。通信圖是上每個對象被稱為對象生命線。
UML2.0 建模互動概述：
在實際使用中，一個單一的場景的序列圖是用來模型。所以使用序列圖來完成整個應用程序。
當一個單一的場景建模，它有可能忘記的全過程並且這可能帶來誤差。
因此，要解決這個問題，新的互動概述結合的控制流圖，活動圖，序列圖和消息規范。
活動圖使用活動對象流來形容一個過程。互動概述圖使用相互作用和交互出現。
序列圖中的生命線和消息只出現內相互作用或相互作用的發生。
然而，參與的互動概述圖的生命線（對象）可能被列為圖名。
下圖顯示了一個決定幀和終止點的交互概覽圖
UML2.0 建模時序圖：
此圖中本身的名稱，描述圖中的目的。它基本上是涉及在其整個生命周期中的事件的時間。
因此，可以被定義為一個時序圖，把重點放在其使用壽命中的一個對象的事件的特殊目的的交互圖。它基本上是一個混合的狀態機和交互圖。時序圖使用下面的時間線：
-
狀態的時間線
-
一般值的時間線
在時序圖中的生命線一幀的內容區域內形成一個長方形的空間。它通常是水平對齊讀取由左到右。在同一幀內，也可以層疊多個生命線，它們之間的相互作用模型。
以下是UML 2.0介紹的匯總圖
以下是UML 2.0介紹的匯總圖
UML2.0 總結：
UML2.0 是一個增強版本的新功能被添加到使它更可用，高效。
在UML2.0的主要有兩大類，一個是UML超級結構和另一個是UML基礎設施。
雖然新的圖表是基於舊的觀念，但他們仍然有額外的功能。
UML2.0 提供了四個交互圖，序列圖，通信圖，交互概覽圖，和一個可選的時序圖。
所有四個圖使用的幀符號括起來的相互作用。使用框架支持重用的相互作用發生的相互作用。
學習來源：https://www.w3cschool.cn/uml_tutorial/uml_tutorial-kty628y9.html