活動圖是UML中描述系統動態方面的另一個重要圖。活動圖基本上是一個流程圖，用於表示從一個活動到另一個活動的流程。該活動可以被描述為系統的操作。控制流從一個操作到另一個操作。該流程可以是順序的，分支的或併發的。活動圖通過使用不同的元素（如fork，join等）來處理所有類型的流控制
活動圖的目的
活動圖的基本目的與其他四個圖類似。它捕捉系統的動態行為。其他四個圖用於顯示從一個對像到另一個對象的消息流，但活動圖用於顯示從一個活動到另一個活動的消息流。
活動是系統的特定操作。活動圖不僅用於可視化系統的動態特性，而且還用於通過使用正向和反向工程技術來構建可執行系統。活動圖中唯一缺失的部分是消息部分。
它不顯示任何消息從一個活動流向另一個活動。活動圖有時被認為是流程圖。雖然圖表看起來像一個流程圖，但它們不是。它顯示了不同的流程，如並行，分支，並發和單一。
活動圖的目的可以被描述為 -
-
繪製系統的活動流程。
-
描述從一個活動到另一個活動的順序。
-
描述系統的並行，分支和並發流程。
活動圖
- 描述系統的工作流行為，側重於流程。
- 一個過程描述了一個組織中活動的順序或流程，目的是開展工作。
活動，Action
活動
- 描述了一系列基於控制模型和對象流模型的動作
- 包含邊和活動節點（例如動作）
- 由具有圓角的矩形表示
行動
- 是活動中包含的可執行功能的基本單元
- 代表活動中的一個單一步驟
活動⌘
活動包含節點：
- 行動
- 目的
- 控制節點
和邊緣：
- 控制流
- 對象流
控制流程
- 控制流是在前一個完成之後啟動活動節點的邊
對象Flow⌘
要么 
- 對象流是可以有對像或數據傳遞的活動邊緣
Objects⌘
- 傳入或傳出對像是參數
- 放置在邊框上（如矩形）
- 或者作為小矩形，稱為引腳（輸入或輸出）
Token
- 活動的語義基於令牌流
- 控制令牌和對象令牌在邊緣之間的節點之間流動
活動示例
泳道活動圖
Activity diagrams also describe the roles and areas of responsibilities in the business – in other words who is responsible for doing what in the business. Roles and areas of responsibilities are documented as columns (UML swimlanes) in the activity diagram. Swimlanes show which business workers participate in the realization of the workflow
This activity diagram documenting how the business performs a Proposal process, with three areas of responsibilities (Customer Sales Interface, Proposal Owner, and Quote Owner)
初始節點
- 它有傳出的邊緣，但沒有傳入的邊緣
- 一個活動可能有多個初始節點
- 每個產生一個並發流
- 初始節點可以有多個傳出邊緣
- 語義：每個傳出邊緣的控制令牌
- 活動圖不必具有初始節點
- 符號：一個實心圓
最終Node⌘
- 一個活動可能有多個活動最終節點
- 達到的第一個停止活動中的所有流量
- 不管活動中的令牌數量如何
- 至少有一個傳入邊緣和沒有傳出邊緣
- 如果多個傳入邊緣只有一個必須帶有令牌
- 活動圖不必具有最終節點
- 符號：帶外環的實心圓
Decision
- 是在輸出流之間選擇的控制節點
- 一個傳入邊緣和幾個傳出邊緣
- 當提供令牌時，會評估出口邊緣的警衛
- 令牌轉到第一個真正的傳出
- 符號：菱形
Merge
- 合併節點是將多個備用流程匯集在一起的控制節點
- 它不用於同步並發流
- 幾個傳入邊緣，一個傳出邊緣
- 沒有任何計算，沒有預期
- 符號：空菱形
叉，Join
- 叉 - 一個傳入邊和多個傳出邊
- 加入 - 多個傳入邊緣和一個傳出邊緣
隱式splitting
一旦行動A終止
- 控制令牌在兩個輸出邊緣都可用
- 動作B和C同時開始
隱式同步
行動F不會開始，直到令牌在兩個傳入邊緣都可用 - 動作D和E必須終止
隱式分割/同步 - 對象流程
和對象流的語義
- 一旦行動A終止，它提供兩個對象節點
- 在兩個傳入邊緣都有對象標記可用之前，操作F不會開始 - 操作D和E必須終止
如何繪製活動圖？
活動圖主要用作由系統執行的活動組成的流程圖。活動圖不完全是流程圖，因為它們具有一些附加功能。這些附加功能包括分支，平行流，泳道等。
在繪製活動圖之前，我們必須清楚地了解活動圖中使用的元素。活動圖的主要元素是活動本身。活動是系統執行的功能。在確定活動後，我們需要了解它們如何與約束和條件相關聯。
在繪製活動圖之前，我們應該確定以下要素 -
-
活動
-
協會
-
條件
-
約束
一旦確定了上述參數，我們就需要對整個流程進行心理佈局。這個心理佈局然後轉化為活動圖。
以下是訂單管理系統的活動圖示例。在該圖中，確定了四個與條件相關的活動。重要的一點應該清楚地理解活動圖不能與代碼完全匹配。活動圖用於了解活動的流程，主要由業務用戶使用
下圖繪製了四項主要活動 -
-
由客戶發送訂單
-
訂單的收據
-
確認訂單
-
發送訂單
收到訂單請求後，會執行條件檢查以檢查它是正常訂單還是特殊訂單。在確定訂單類型後，執行分派活動並將其標記為過程的終止。
在哪裡使用活動圖？
活動圖的基本用法與其他四個UML圖類似。具體用法是對從一個活動到另一個活動的控制流進行建模。此控制流程不包含消息。
活動圖適用於對系統的活動流進行建模。一個應用程序可以有多個系統。活動圖還捕獲這些系統並描述從一個系統到另一個系統的流程。該特定用法在其他圖表中不可用。這些系統可以是數據庫，外部隊列或任何其他系統。
我們現在將研究活動圖的實際應用。從上面的討論中可以清楚地看到，一個活動圖是從非常高的水平繪製的。因此它提供了高層次的系統視圖。這種高層次的觀點主要面向商業用戶或任何非技術人員。
這張圖用於模擬只是業務需求的活動。該圖對業務理解的影響更大，而不是實施細節。
活動圖可用於 -
-
使用活動建模工作流程。
-
建模業務需求。
-
高度了解系統的功能。
-
在後期調查業務需求。
尋找線上UML編輯器？以下活動圖是按一下打開並準備編輯!
Swineline for Order Fulfilment
Relationships between Activates and Business Entities
