我們知道，一個商業目標的實現必定由一系列
的活動組成，這些活動的編排即構成了以目標為導向的業務流程。管理的目標即通過合理有效的編排這些活動以期以最少的成本達到最大的收益。這個編排的過程亦
即進行業務流程建模的過程。在進行業務流程建模時反復出現的活動結構構造即產生了模式。在本章中，我們將討論工作流的控制模式。控制模式關注業務流程中活
動的編排，一方面強調與實際業務的契合，另一更為重要的方面則是如何合理調配這些活動。
本章討論的控制模式共計43種。需要注意的是，這些模式的出發點是基于對實際業務進行描述的，與具體的工作流系統沒有太大的關聯。而一個工作流系統對工作流模式的支持程度則直接決定了該系統對業務的建模能力。所以在某種程度上，衡量一個合適的工作流系統時，往往會考慮其對工作流模式的支持程度。
本章討論的控制模式按照描述、應用和實現展開，分別對應著模式的介紹、模式對實際業務的映射和工作流產品對該模式的實現支持。最后是小結。作為約定，我們將業務流程里的活動映射為任務，將對活動的建模描述映射為任務節點。
一、 基本控制模式
基本控制模式包括5個模式，是其他控制模式的基礎。
1、順序（WCP_01:
Sequence）
描述
在同一個流程實例里，任務會在前續任務完成后順序觸發。
圖 4-1
如圖4-1所示，任務A執行完畢后會順序觸發任務B的執行，任務B執行完畢后會順序觸發任務C的執行。
同義詞
順序執行、串行路由。
應用
順序模式是工作流建模的基礎，是流程定義里最基本的構建塊，用以描述連續串行的一系列任務，這些任務之間的觸發是無條件的。
順序模式也是實際的業務中應用最多的模式，
當實現一個業務價值需要執行多個任務時，最自然的方式就是排序并順序完成這些任務，典型的如流水線作業。當企業人數不多，業務模式簡單（不需要過多的任務
或任務之間存在很強的線性依賴關系），管理成本很低時，順序模式是最自然的選擇。
2、并發分裂（WCP_02:
Parallel Split）
描述
分支分裂為兩個或多個后續分支，當分支執行完畢后觸發后續并發分支的同時執行。并發的分支有可能在后續合并為一個分支，也可能不合并。
圖 4-2
如圖4-2所示，任務A完成后將同時觸發任務B和任務C的執行，任務B和任務C的執行不存在前后關系。
同義詞
AND-split、Fork、并行路由、并行分裂。
應用
在傳統的軟件開發里，開發過程被典型的分為了5個階段，如下圖所示：
圖 4-3
這5個
階段是順序執行關系，典型的當需求分析完畢后會有一個需求凍結狀態，在這種狀態下才開始正式的軟件設計和實現。該模式最大的弊端在于在需求分析階段不可能
捕獲用戶所有可能的需求，而且客戶的需求是變化的，開發階段由于需求凍結對于客戶完全黑盒，導致最后的交付無法實現客戶期望的業務價值。
在敏捷開發里，開發過程由多個迭代組成，在每個迭代里，需求分析、架構設計、編碼開發、測試和交付都是同時進行的，客戶參與到這個過程中，客戶能夠從不斷的交付中提出新的需求，這樣軟件才能夠更好的響應變化，不至于在最終交付時出現業務價值的偏差。
圖 4-4
其實從某種角度上看，不同企業的組織管理結構也決定了它所采用的業務流程模式。在圖4-3所
示的開發流程里，每個階段都對應于不同的部門，需求分析有專門的業務部門，開發部門內部分為了架構部門、開發部門和測試部門，交付則又有專門的實施團隊，
在這種情況下，從管理的成本考慮，順序執行無疑是最自然和最便宜的選擇（這也是為什么在傳統企業里實施敏捷困難的原因之一）。
而在敏捷開發團隊里，整個團隊則是圍繞開發流程建立，減少了內部不必要的協調溝通成本，能夠達到相對較高的執行效率。
實現
由于后續分支的觸發是無條件的，所以在很多工作流產品的實現里省去了AND-split節點，直接由任務節點進行分支分裂，如下圖4-5所示：
圖 4-5
jBPM使用token記錄當前流程實例執行的位置并觸發流轉，建立起token的父子關系。如下圖所示，在AND-split節點每個并發的分支都會產生一個新的子token，當子token到達AND-join節點后即可通過其訪問到它的父token，再通過父token遍歷其子token即可獲得當前并發分支的執行情況并實現合并。
圖 4-6
作為約定，我們在后續的說明中，將會采用token來指代當前流程實例所執行的位置。
3、同步（WCP_03:
Synchronization）
描述
兩個或多個分支合并為一個后續分支，當被合并的分支都執行完畢后，后續分支才被觸發。
圖4-7
如上圖所示，當任務A和任務B都完成后，才會觸發任務C的執行。
同義詞
AND-join、匯聚、同步。
應用
在實際的應用中，AND-split節點與AND-join節點一般成對出現。
在任何時候，總結總是有必要的，每次迭代開發結束后，我們都會進行迭代小結，寫出應該改進的部分、應該保持的部分，以保持整個團隊的迭代前進。
實際上，很多情況下AND-split節點和AND-join節點往往隱含著管理意義，上一級的管理者在AND-split節點進行任務的管理和下發，在AND-join節點對任務執行結果進行負責。
實現
和AND-split節點一樣，在部分工作流產品里，直接采用任務節點進行分支合并，如下圖所示：
圖 4-7
jBPM里，分支的合并實際是token的合并，子token生命周期終止，父token重新激活。
4、排他選擇（WCP_04:
Exclusive Choice）
描述
分支分裂為兩個或多個后續分支，當分支執行完畢后只能選擇觸發一個后續分支執行，即多選一。
圖 4-9
如上圖所示，任務A完成后將會選擇觸發任務B或任務C的執行，任務B和任務C之間只能選擇一個執行。
同義詞
XOR-split、排他OR-split、條件路由。
應用
流程里的決策任務。會存在兩種決策方式：人為決策和系統決策。由人或一組系統設定條件根據流程執行情況作出后續執行路徑的選擇。
實現
兩種實現方式，一種是在XOR-split節點定義路由選擇條件（圖4-10）、一種是在后續轉移線上定義觸發條件（圖4-11）。
圖 4-10
圖 4-11
條件的計算有多種方式：工作流變量與相應條件定義值簡單匹配、提供接口由具體實現類返回計算結果、規則引擎進行規則匹配計算。同時，當存在多個后續分支和條件判斷時，一般會定義一個默認執行分支。
5、簡單合并（WCP_05:
Simple Merge）
描述
兩個或多個分支合并為一個后續分支，任何一個分支執行完畢后就會觸發后續分支的執行，不需要同步，遵循先進先出的原則。需要注意的是：該模式有個前提條件，即前續分支有且只有一個會執行。
圖 4-12
如上圖所示，任務A或任務B只要有一個完成都會觸發任務C的執行，但是任務A和任務B有且只有一個可以執行。如果任務A和任務B都有可能執行，則變為另外一個模式：多合并模式（WCP_08）。
同義詞
XOR-join、排他OR-join、merge。
應用
在實際的應用中，為保證該模式的前提條件，一般XOR-join節點與XOR-split節點成對使用。
實現
和AND-join節點一樣，因為不需要任何條件判斷，所以在部分工作流產品里，直接采用任務節點進行分支簡單合并，但是需要和AND-join做出區別，如下圖所示：
圖 4-13
6、基本控制模式小結
基本控制模式非常簡單，實現起來也沒有太大的難度。需要注意的是，對于一種模式往往會存在多種實現方式，筆者的建議是：將條件判斷的節點獨立出來，由其負責條件計算和路徑選擇，而任務節點則只關注于實際業務的執行，做到職責分離。例如，AND-split、AND-join、XOR-split和XOR-join節點都會單獨存在。
可以看到：除去AND-split和AND-join節
點，順序、排他選擇、簡單合并模式組合的流程和我們編寫程序的邏輯流程圖非常的相似，也就是這三種模式能夠對程序的邏輯流程圖進行建模。于是一件有意思的
事情出現了：有快速開發平臺產品使用流程引擎來編排程序邏輯。他們的做法是將細粒度的代碼邏輯封裝為運算構件，然后再通過流程的可視化編輯器將這些運算構
件粘合起來。這樣，傳統方式下采用代碼實現業務邏輯的過程變成了畫流程圖的過程。筆者認為這樣的實現存在相當大的弊端，相當不合理。首先，編寫代碼變得復
雜了，明明幾十行代碼能夠實現的邏輯卻需要經過編寫構件、繪制程序流程圖、部署、運行好多步才能實現，編程效率可以想象；其次是代碼的執行效率低，程序的
運行需要經過一次流程定義的解釋才能執行；然后是這種實現完全犧牲了語言自身的特性，面向過程，很難提供代碼級別的單元測試環境，只能提供有限的調試。該
實現實際上是定義了一種簡單的流程語言，通過該流程語言來進行功能函數（運算構件）調用的編排。任務編排沒有問題，服務編排也沒有問題，但是如果編排細粒
度到功能函數，那么就超出了流程引擎的作用域。提升編程效率的最好途徑總是語言而不是工具。
http://www.tkk7.com/ronghao 榮浩原創，轉載請注明出處：）
posted on 2009-11-22 22:39
ronghao 閱讀(1433)
評論(9) 編輯 收藏 所屬分類:
Head First Process-深入淺出流程