我們知道，一個(gè)商業(yè)目標(biāo)的實(shí)現(xiàn)必定由一系列 的活動(dòng)組成，這些活動(dòng)的編排即構(gòu)成了以目標(biāo)為導(dǎo)向的業(yè)務(wù)流程。管理的目標(biāo)即通過(guò)合理有效的編排這些活動(dòng)以期以最少的成本達(dá)到最大的收益。這個(gè)編排的過(guò)程亦 即進(jìn)行業(yè)務(wù)流程建模的過(guò)程。在進(jìn)行業(yè)務(wù)流程建模時(shí)反復(fù)出現(xiàn)的活動(dòng)結(jié)構(gòu)構(gòu)造即產(chǎn)生了模式。在本章中，我們將討論工作流的控制模式。控制模式關(guān)注業(yè)務(wù)流程中活 動(dòng)的編排，一方面強(qiáng)調(diào)與實(shí)際業(yè)務(wù)的契合，另一更為重要的方面則是如何合理調(diào)配這些活動(dòng)。

 

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

 

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

 

一、       基本控制模式

基本控制模式包括5個(gè)模式，是其他控制模式的基礎(chǔ)。

 

1、順序（WCP_01: Sequence）

描述

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

圖 4-1

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

 

同義詞

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

 

應(yīng)用

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

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

 

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

描述

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

圖 4-2

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

 

同義詞

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

 

應(yīng)用

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

圖 4-3

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

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

圖 4-4

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

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

 

實(shí)現(xiàn)

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

圖 4-5

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

圖 4-6

作為約定，我們?cè)诤罄m(xù)的說(shuō)明中，將會(huì)采用token來(lái)指代當(dāng)前流程實(shí)例所執(zhí)行的位置。

 

3、同步（WCP_03: Synchronization）

描述

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

圖4-7

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

 

同義詞

AND-join、匯聚、同步。

 

應(yīng)用

在實(shí)際的應(yīng)用中，AND-split節(jié)點(diǎn)與AND-join節(jié)點(diǎn)一般成對(duì)出現(xiàn)。

在任何時(shí)候，總結(jié)總是有必要的，每次迭代開(kāi)發(fā)結(jié)束后，我們都會(huì)進(jìn)行迭代小結(jié)，寫(xiě)出應(yīng)該改進(jìn)的部分、應(yīng)該保持的部分，以保持整個(gè)團(tuán)隊(duì)的迭代前進(jìn)。

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

 

實(shí)現(xiàn)

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

圖 4-7

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

 

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

描述

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

圖 4-9

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

 

同義詞

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

 

應(yīng)用

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

 

實(shí)現(xiàn)

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

圖 4-10

圖 4-11

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

 

5、簡(jiǎn)單合并（WCP_05: Simple Merge）

描述

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

圖 4-12

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

 

同義詞

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

 

應(yīng)用

在實(shí)際的應(yīng)用中，為保證該模式的前提條件，一般XOR-join節(jié)點(diǎn)與XOR-split節(jié)點(diǎn)成對(duì)使用。

 

實(shí)現(xiàn)

和AND-join節(jié)點(diǎn)一樣，因?yàn)椴恍枰魏螚l件判斷，所以在部分工作流產(chǎn)品里，直接采用任務(wù)節(jié)點(diǎn)進(jìn)行分支簡(jiǎn)單合并，但是需要和AND-join做出區(qū)別，如下圖所示：

圖 4-13

6、基本控制模式小結(jié)

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

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

http://www.tkk7.com/ronghao 榮浩原創(chuàng)，轉(zhuǎn)載請(qǐng)注明出處：）