[ UML 文章收集 ] UML 之 Activity Diagram 的簡介

參考自 這裡 
Preface: 
活動圖（Activity Diagram）是一個非常實用的圖款，適合用來具體呈現「企業流程」（Buisness Process）或「工作流程」（Workflow）等等的活動流程觀點. 通常是SA會先請User提供現行的作業流程文件， 再來進行企業流程分析，畫出 Activity Diagram，有點類似 flow chart，但是主要 focus 的目標在每一個activity! 

雖然，以物件導向的實作技術而言，程序員無法「按圖施工」，直接將活動圖的設計內容對應成程式碼。但是，以分析師的角度來看，活動圖光是用來協助釐清並具體呈現繁雜的企業流程，其實就已經值回票價了. 所以，讓我們從活動圖開始學習UML，也讓我們從活動圖開始著手分析設計。 

- 優點：較少的物件導向特徵 

活動圖涵蓋較少的物件導向思維和特徵，倘若以初級和中級概念來看，分析師根本不需要具備物件導向思維，就可以繪製出活動圖了。我個人認為，這是活動圖容易學習和上手的最主要原因之一.

- 優點：易於跟客戶溝通流程 

活動圖、用例圖和循序圖是VS2010/UML圖中，具備較多流程觀點的圖款。不過，雖說它們具備流程觀點，但在實際上，這三款圖卻是以不同的角度來展現流程. 其中，以活動圖所採用的依序步驟，最能夠讓分析師用來與客戶溝通流程。至於，用例圖將流程封裝成一個個近似獨立的單元；還有循序圖則以一群物件互傳訊息的方式，來展現系統內部一群物件協力實現流程的運作過程

- 優點：找尋用例並且串接用例 

活動圖除了可以協助分析師釐清並具體展現企業流程外，還可以用來協助找尋用例、挖掘可能遺漏了的用例，以及用來展現用例的串接情況.

下圖中將 Activity Diagram 常用到的觀念都以範例顯示出來: 
 

Activity Diagram - 動作、起訖和動線 : 
剛才我們提到了，「用例」（Use Case）將流程封裝成一個個近似獨立的單元，倘若分析師讓活動圖中的「動作」（Action），盡可能是一對一對應用例的形式，就可以透過活動圖來展現用例的串接情況了。簡單來說，動作是一個不可切割的流程片段，活動圖中包含了一組動作，透過流程動線（flow edge）來連接動作。在稍後的內容中，我們很快就會學到動作的概念了. 

更有價值的，分析師可以透過活動圖來檢驗並挖掘遺漏的用例。許多專案失敗的重要原因之一，來自於「需求暴增」。為什麼需求會暴增？追根究柢，很可能是分析師一開始便遺漏了需求，以致於客戶會在專案中後期緊急追加需求。所以，分析師可以善用活動圖來挖掘出遺漏的用例，進行更切合實際的成本估算，為客戶和公司帶來雙贏的成果. 

首先，我們要來談活動圖中最最基本的概念：動作（Action）、起點（Initial Node）、活動終點（Activity Final Node）以及活動動線（Activity Edge），在 astah community 工具列上可以找到:
 

接著下面範例表達了活動節點（Activity Node）, 活動動線 (Activity Edge) 與控制節點（Control Node）的使用. 控制節點往下又細分成兩小類：其中一種控制節點為起點（Initial Node），另一種控制節點為活動終點（Activity Final Node）: 
 
請假簽和流程的活動圖 

上面活動圖的活動流程從起點開始，中間會經過數個動作，最後控制流程會進入活動終點，然後整張活動圖就結束. 我們可以這麼說，一張活動圖主要表達一個活動，而這個活動呈現了一項行為（behavior）。行為可以被拆解成數個細小的步驟，或者說，數個細小的步驟組成一項行為. 

因此，活動圖中包含了數個細小的動作，每一個動作即為一個不可以再往下細分的單一步驟. 此處，我們用一、兩句簡單明確的句子，來定義動作、起點和活動終點，如下: 
- 動作（Action） 

動作是活動（Activity）中的一個步驟（single step），而且它具有不可分解的特性

- 起點（Initial Node） 

當一條活動被啟動時，流程即從起點開始往下執行.

- 活動終點（Activity Final Node） 

任一條動線進入活動終點時，整張活動圖即告終止，即便有還未跑完的流程分支，也會全部終止.

在 UML 2.0 引入了另一個符號稱為 "流程終止 (Flow Final Node)", 說明如下: 
- 流程終止 (Flow Final Node) 

Flow final node is a control final node that terminates a flow. It destroys all tokens that arrive at it but has no effect on other flows in the activity. Flow final was introduced in UML 2.0.

Activity Diagram - 決策點與決策條件 : 
在現實生活中, 在某些 Activity 你可以會根據不同的條件, 環境, 行為而有不同的後續 Activity. 而這在編程的概念中就是 if/else if/else. 以上面的簽核範例來說, 簽核可能通過, 也可能被退件. 此時在 活動圖 可以透過 決策點 與 決策點條件 (guard/condition) 來表達: 
 

下面對 決策點 與 決策條件簡單給個定義: 
- 決策點 (Decision Point) 

用空心菱形表示一個決策點。決策點有一條流程流入、並有多條流程流出，其中，在多條流出的流程中可挑選執行其中一條流程。

- 決策條件 (Guard/Condition) 

用法格式為 [guard] . 附在決策點流出的一條流程線上，表示一項決策條件。一個決策點的每一條流程都必需有決策條件.

Activity Diagram - 結合與分岐點 : 
通常在簽核過程中, 要核准的不會只有一個人. 假設在這裡的範例審核有兩個角色 "部門主管" 與 "專案經理", 又假設他們是平行的角色, 也就是審核是同時進行. 如此在你 "填寫請假單" Activity 後會有兩個 Activity Edges 分別是要給 "部門主管" 與 "專案經理" 審核 (fork), 又 兩位主管 審核都通過後, 只會有一份進行備存, 此時則需要將兩條 Activity Edge 進行合併到下一個 Activity (join): 
 

下面對 "結合" (Join) 與 "分岐 (Fork)" 給了定義: 
- 結合 (Join) 

用一條粗線橫擋、有多條流程流進、並一條流程流出，表示一份平行工作的結束。流程的合併隱含了所有流進的流程都要抵達、才能進行流程結合之後的工作!

- 分岐 (Fork) 

用一條粗線橫擋、有一條流程流進、並多條流程流出，表示一份平行工作的開始.

而與 "結合點" 很相似的有另一個稱為 "合併點 (Merge Point)", 都是將多條 Activity Edges 作為輸入, 而只有一條 Activity Edge 成為輸出. 而與 "結合點" 不同的是 "合併點" 並不要求所有流進的 Activity Edge 都要抵達, 而是有自己的決策條件決定輸出 Activity Edge. 底下是它的定義: 
- 併點 (Merge Point) 

用空心菱形表示一個合併點。合併點有多條流程流入、並有一條流程流出。合併點隱含在多條流入的流程中、根據流出流程的決策條件、有一條或多條流程要抵達，才能進行流程合併之後的工作.

Activity Diagram - Swimlane : 
從上面你應該可以發現在 活動圖 中可能有多個角色, 但你不可能在每個 Activity, Control 與 Line 旁邊都標示這是屬於哪一個角色的. 因此就有了所謂的 "泳道 (Swimlane)" 的引入: 
 

底下給了 "泳道" 簡單定義: 
- 泳道 (Swimlane) 

用大長條方塊、一端加上標籤欄位，表示一條泳道。泳道是UML活動圖中用來將一部份的活動和其他物件劃分為一群的空間。泳道的標籤名稱通常是一項參與者的名稱，表示該泳道包含的活動和一位參與者有關。有些泳道用來代表一段執行緒，則不標識為參與者名稱.

上面的 Swimlane 是垂直的切割, 其實你也可以水平的切割. 而之所以進行切割是為了分群 (Partitioning), 讓某一群的 Activity 屬於某一個使用者, 活動或是時間: 
- 分群 (Partitioning) 

用併排的多條泳道、將UML活動圖的全部或一部份劃分，表示此圖有一些分群

Supplement: 
* PGR應該要看懂的UML Diagram 
* {UML 2.0} Activity Diagram 的說明與範例 
* 工具系列：UML活動圖 
* IBM developerWors: 如何繪製UML 活動圖(Activity Diagram) 
* Activity Diagram Controls