我們知道，一個商業(yè)目標的實現(xiàn)必定由一系列 的活動組成，這些活動的編排即構成了以目標為導向的業(yè)務流程。管理的目標即通過合理有效的編排這些活動以期以最少的成本達到最大的收益。這個編排的過程亦 即進行業(yè)務流程建模的過程。在進行業(yè)務流程建模時反復出現(xiàn)的活動結構構造即產(chǎn)生了模式。在本章中，我們將討論工作流的控制模式?？刂颇Ｊ疥P注業(yè)務流程中活 動的編排，一方面強調與實際業(yè)務的契合，另一更為重要的方面則是如何合理調配這些活動。

 

本章討論的控制模式共計43種。需要注意的是，這些模式的出發(fā)點是基于對實際業(yè)務進行描述的，與具體的工作流系統(tǒng)沒有太大的關聯(lián)。而一個工作流系統(tǒng)對工作流模式的支持程度則直接決定了該系統(tǒng)對業(yè)務的建模能力。所以在某種程度上，衡量一個合適的工作流系統(tǒng)時，往往會考慮其對工作流模式的支持程度。

 

本章討論的控制模式按照描述、應用和實現(xiàn)展開，分別對應著模式的介紹、模式對實際業(yè)務的映射和工作流產(chǎn)品對該模式的實現(xiàn)支持。最后是小結。作為約定，我們將業(yè)務流程里的活動映射為任務，將對活動的建模描述映射為任務節(jié)點。

 

一、       基本控制模式

基本控制模式包括5個模式，是其他控制模式的基礎。

 

1、順序（WCP_01: Sequence）

描述

在同一個流程實例里，任務會在前續(xù)任務完成后順序觸發(fā)。

圖 4-1

如圖4-1所示，任務A執(zhí)行完畢后會順序觸發(fā)任務B的執(zhí)行，任務B執(zhí)行完畢后會順序觸發(fā)任務C的執(zhí)行。

 

同義詞

順序執(zhí)行、串行路由。

 

應用

順序模式是工作流建模的基礎，是流程定義里最基本的構建塊，用以描述連續(xù)串行的一系列任務，這些任務之間的觸發(fā)是無條件的。

順序模式也是實際的業(yè)務中應用最多的模式， 當實現(xiàn)一個業(yè)務價值需要執(zhí)行多個任務時，最自然的方式就是排序并順序完成這些任務，典型的如流水線作業(yè)。當企業(yè)人數(shù)不多，業(yè)務模式簡單（不需要過多的任務 或任務之間存在很強的線性依賴關系），管理成本很低時，順序模式是最自然的選擇。

 

2、并發(fā)分裂（WCP_02: Parallel Split）

描述

分支分裂為兩個或多個后續(xù)分支，當分支執(zhí)行完畢后觸發(fā)后續(xù)并發(fā)分支的同時執(zhí)行。并發(fā)的分支有可能在后續(xù)合并為一個分支，也可能不合并。

圖 4-2

如圖4-2所示，任務A完成后將同時觸發(fā)任務B和任務C的執(zhí)行，任務B和任務C的執(zhí)行不存在前后關系。

 

同義詞

AND-split、Fork、并行路由、并行分裂。

 

應用

在傳統(tǒng)的軟件開發(fā)里，開發(fā)過程被典型的分為了5個階段，如下圖所示：

圖 4-3

這5個 階段是順序執(zhí)行關系，典型的當需求分析完畢后會有一個需求凍結狀態(tài)，在這種狀態(tài)下才開始正式的軟件設計和實現(xiàn)。該模式最大的弊端在于在需求分析階段不可能 捕獲用戶所有可能的需求，而且客戶的需求是變化的，開發(fā)階段由于需求凍結對于客戶完全黑盒，導致最后的交付無法實現(xiàn)客戶期望的業(yè)務價值。

在敏捷開發(fā)里，開發(fā)過程由多個迭代組成，在每個迭代里，需求分析、架構設計、編碼開發(fā)、測試和交付都是同時進行的，客戶參與到這個過程中，客戶能夠從不斷的交付中提出新的需求，這樣軟件才能夠更好的響應變化，不至于在最終交付時出現(xiàn)業(yè)務價值的偏差。

圖 4-4

其實從某種角度上看，不同企業(yè)的組織管理結構也決定了它所采用的業(yè)務流程模式。在圖4-3所 示的開發(fā)流程里，每個階段都對應于不同的部門，需求分析有專門的業(yè)務部門，開發(fā)部門內部分為了架構部門、開發(fā)部門和測試部門，交付則又有專門的實施團隊， 在這種情況下，從管理的成本考慮，順序執(zhí)行無疑是最自然和最便宜的選擇（這也是為什么在傳統(tǒng)企業(yè)里實施敏捷困難的原因之一）。

而在敏捷開發(fā)團隊里，整個團隊則是圍繞開發(fā)流程建立，減少了內部不必要的協(xié)調溝通成本，能夠達到相對較高的執(zhí)行效率。

 

實現(xiàn)

由于后續(xù)分支的觸發(fā)是無條件的，所以在很多工作流產(chǎn)品的實現(xiàn)里省去了AND-split節(jié)點，直接由任務節(jié)點進行分支分裂，如下圖4-5所示：

圖 4-5

jBPM使用token記錄當前流程實例執(zhí)行的位置并觸發(fā)流轉，建立起token的父子關系。如下圖所示，在AND-split節(jié)點每個并發(fā)的分支都會產(chǎn)生一個新的子token，當子token到達AND-join節(jié)點后即可通過其訪問到它的父token，再通過父token遍歷其子token即可獲得當前并發(fā)分支的執(zhí)行情況并實現(xiàn)合并。

圖 4-6

作為約定，我們在后續(xù)的說明中，將會采用token來指代當前流程實例所執(zhí)行的位置。

 

3、同步（WCP_03: Synchronization）

描述

兩個或多個分支合并為一個后續(xù)分支，當被合并的分支都執(zhí)行完畢后，后續(xù)分支才被觸發(fā)。

圖4-7

如上圖所示，當任務A和任務B都完成后，才會觸發(fā)任務C的執(zhí)行。

 

同義詞

AND-join、匯聚、同步。

 

應用

在實際的應用中，AND-split節(jié)點與AND-join節(jié)點一般成對出現(xiàn)。

在任何時候，總結總是有必要的，每次迭代開發(fā)結束后，我們都會進行迭代小結，寫出應該改進的部分、應該保持的部分，以保持整個團隊的迭代前進。

實際上，很多情況下AND-split節(jié)點和AND-join節(jié)點往往隱含著管理意義，上一級的管理者在AND-split節(jié)點進行任務的管理和下發(fā)，在AND-join節(jié)點對任務執(zhí)行結果進行負責。

 

實現(xiàn)

和AND-split節(jié)點一樣，在部分工作流產(chǎn)品里，直接采用任務節(jié)點進行分支合并，如下圖所示：

圖 4-7

jBPM里，分支的合并實際是token的合并，子token生命周期終止，父token重新激活。

 

4、排他選擇（WCP_04: Exclusive Choice）

描述

分支分裂為兩個或多個后續(xù)分支，當分支執(zhí)行完畢后只能選擇觸發(fā)一個后續(xù)分支執(zhí)行，即多選一。

圖 4-9

如上圖所示，任務A完成后將會選擇觸發(fā)任務B或任務C的執(zhí)行，任務B和任務C之間只能選擇一個執(zhí)行。

 

同義詞

XOR-split、排他OR-split、條件路由。

 

應用

流程里的決策任務。會存在兩種決策方式：人為決策和系統(tǒng)決策。由人或一組系統(tǒng)設定條件根據(jù)流程執(zhí)行情況作出后續(xù)執(zhí)行路徑的選擇。

 

實現(xiàn)

兩種實現(xiàn)方式，一種是在XOR-split節(jié)點定義路由選擇條件（圖4-10）、一種是在后續(xù)轉移線上定義觸發(fā)條件（圖4-11）。

圖 4-10

圖 4-11

條件的計算有多種方式：工作流變量與相應條件定義值簡單匹配、提供接口由具體實現(xiàn)類返回計算結果、規(guī)則引擎進行規(guī)則匹配計算。同時，當存在多個后續(xù)分支和條件判斷時，一般會定義一個默認執(zhí)行分支。

 

5、簡單合并（WCP_05: Simple Merge）

描述

兩個或多個分支合并為一個后續(xù)分支，任何一個分支執(zhí)行完畢后就會觸發(fā)后續(xù)分支的執(zhí)行，不需要同步，遵循先進先出的原則。需要注意的是：該模式有個前提條件，即前續(xù)分支有且只有一個會執(zhí)行。

圖 4-12

如上圖所示，任務A或任務B只要有一個完成都會觸發(fā)任務C的執(zhí)行，但是任務A和任務B有且只有一個可以執(zhí)行。如果任務A和任務B都有可能執(zhí)行，則變?yōu)榱硗庖粋€模式：多合并模式（WCP_08）。

 

同義詞

XOR-join、排他OR-join、merge。

 

應用

在實際的應用中，為保證該模式的前提條件，一般XOR-join節(jié)點與XOR-split節(jié)點成對使用。

 

實現(xiàn)

和AND-join節(jié)點一樣，因為不需要任何條件判斷，所以在部分工作流產(chǎn)品里，直接采用任務節(jié)點進行分支簡單合并，但是需要和AND-join做出區(qū)別，如下圖所示：

圖 4-13

6、基本控制模式小結

基本控制模式非常簡單，實現(xiàn)起來也沒有太大的難度。需要注意的是，對于一種模式往往會存在多種實現(xiàn)方式，筆者的建議是：將條件判斷的節(jié)點獨立出來，由其負責條件計算和路徑選擇，而任務節(jié)點則只關注于實際業(yè)務的執(zhí)行，做到職責分離。例如，AND-split、AND-join、XOR-split和XOR-join節(jié)點都會單獨存在。

可以看到：除去AND-split和AND-join節(jié) 點，順序、排他選擇、簡單合并模式組合的流程和我們編寫程序的邏輯流程圖非常的相似，也就是這三種模式能夠對程序的邏輯流程圖進行建模。于是一件有意思的 事情出現(xiàn)了：有快速開發(fā)平臺產(chǎn)品使用流程引擎來編排程序邏輯。他們的做法是將細粒度的代碼邏輯封裝為運算構件，然后再通過流程的可視化編輯器將這些運算構 件粘合起來。這樣，傳統(tǒng)方式下采用代碼實現(xiàn)業(yè)務邏輯的過程變成了畫流程圖的過程。筆者認為這樣的實現(xiàn)存在相當大的弊端，相當不合理。首先，編寫代碼變得復 雜了，明明幾十行代碼能夠實現(xiàn)的邏輯卻需要經(jīng)過編寫構件、繪制程序流程圖、部署、運行好多步才能實現(xiàn)，編程效率可以想象；其次是代碼的執(zhí)行效率低，程序的 運行需要經(jīng)過一次流程定義的解釋才能執(zhí)行；然后是這種實現(xiàn)完全犧牲了語言自身的特性，面向過程，很難提供代碼級別的單元測試環(huán)境，只能提供有限的調試。該 實現(xiàn)實際上是定義了一種簡單的流程語言，通過該流程語言來進行功能函數(shù)（運算構件）調用的編排。任務編排沒有問題，服務編排也沒有問題，但是如果編排細粒 度到功能函數(shù)，那么就超出了流程引擎的作用域。提升編程效率的最好途徑總是語言而不是工具。

http://www.aygfsteel.com/ronghao 榮浩原創(chuàng)，轉載請注明出處：）