1、一.BPMN 業(yè)務流程設計指南云海青鋒編著2017 年6月1BPMN 設計準則.32BPMN 范例、樣板及最佳實踐 .32.1業(yè)務規(guī)則和 BPMN .32.2獨立實例 .52.3四眼原則 .62.4月結(jié)單 .92.5用戶任務后需要額外的信息 .102.6處理來自商城的批量訂單 .112.7重新安排用戶任務 .112.8兩步提升 .133BPMN 建模風格.153.1避免交叉線 .153.2命名規(guī)則 .163.3對稱建模 .173.4使用相同大小的任務框 .184附 1：BPMN 2.0總圖 .205附 2：BPMN 2.0圖元 .215.1事件圖元 .215.2泳池與泳道 .235.3數(shù)據(jù) .

2、235.4編排 .245.5邏輯門（網(wǎng)關） .255.6活動 .265.7標記 .275.8會話 .282一.1 BPMN 設計準則BPM 分析師進行BPMN 建模時應該遵從的一些最佳實踐：1、 簡潔： 最復雜的問題應該使用最簡單的方式來表達?？蛻?、用戶和開發(fā)者更容易理解簡單明了的 BPMN 模型。無論什么地方有些復雜， 也不要讓模型變得更加復雜。 努力、再努力地讓模型更簡潔些。2、 不是所有的業(yè)務規(guī)則、動作等都可以用BPMN 模型來執(zhí)行的。 客戶往往不很清楚業(yè)務流程管理（ BPM）是什么，他們的理解是，通過運用 BPM 方法，強迫按自動化方式實現(xiàn)所有的業(yè)務過程都，其實這些過程往往是人工執(zhí)行的

3、（基于法律、道德、口頭或書面的規(guī)則）。3、 使用子流程：既可以重用有可以制作流程，更易理解而且更好地表達。4、 BPMN 就是 BPMN ：不要在 BPMN 圖中，混合 BPMN 、EPC、VACD、活動圖、順序圖或用例的符號。它不是一個大雜燴！5、 良好表達 ： BPMN 模型不是讓人選擇的十字路口；好的表達不僅更好理解，而且流程動作更不模糊， 消除潛在的問題。 按照從左到右的方式，而不是垂直方式； 每個任務、網(wǎng)關、事件等使用合適的輸入/ 輸出，劃分子流程；不要將所有的東西都放在一頁內(nèi)。6、 BPMN 分析模型與BPMN 執(zhí)行模型： 分析（設計） 模型是獨立于執(zhí)行模型的，同時也獨立于執(zhí)行平臺

4、（比如Oracle 的 BPM 套件、 ActivitiBPM 平臺）； BPM 引入了詳細級別（從 0 級到 4 級），4 級是面向開發(fā)者的；然而，一個好的實踐是要了解每個BPM引擎平臺的能力， 因為它們提供不同的執(zhí)行選項； 而且，取決于業(yè)務需求和執(zhí)行選項，創(chuàng)建一個中間 BPMN 模型會很有好處。7、 定義角色 ：雖然流程任務的角色分配是可選的，而且有些流程引擎（比如Activiti ）可能不需要使用泳池或泳道 （執(zhí)行的靈活性， 使用靈活方式來處理角色管理） ，但對于分析師和設計人員來說，運用泳池和泳道是個好實踐，至少對于主要或高級的干系人應該如此。8、 選擇合適你的需要的 BPMN 建模工

5、具 ；無論如何， 記住所選擇的工具至少要提供驗證機制，因為不是所有的符號組合是允許的。萬一你使用了沒有流程檢驗的流程設計工具，你還可以使用 Aris Express 或 TIBCO 設計器（二者都是免費的）來快速檢驗你的流程。9、 充分了解 BPMN 元素 ：了解每個元素的重要性，了解使用的場合和時間。記住，不是每個流程需要所有的元素；比如，不是每個業(yè)務動作需要獨立任務，不是每個任務需要判斷選擇網(wǎng)關，相應地使用事件；避免使用復雜的元素來提高印象。2 BPMN 范例、樣板及最佳實踐下面通過一些常常會碰到的業(yè)務流程場景給出一些BPMN 建模中共性問題的例子。不管你是什么行業(yè)或什么項目，有很多使用B

6、PMN 共性的問題。2.1 業(yè)務規(guī)則和 BPMN2.1.1 模型場景我們想使用BPMN 來構(gòu)建一個流程模型，并處理一些業(yè)務規(guī)則。比如，我們使用創(chuàng)建賬單3一的.例子。每個創(chuàng)建賬單，需要計算折扣。訂購數(shù)量和客戶類型都與計算折扣規(guī)則相關。下面是一個簡單的例子，展現(xiàn)哪里要使用BPMN ，哪里不使用。BPMN 2.0 流程圖如下：2.1.2 解釋說明建模過程中，我們聚焦在處理過程。在這個例子中，過程有兩步。折扣是在賬單創(chuàng)建之前計算的。最終得到了一個非常簡單的流程。這個流程并沒有想當然地將折扣計算本身使用BPMN 模型來建模（看下面的例子）。對于規(guī)則判斷樹， 對于每個附件的準則，篇幅會按照幾何級數(shù)地增長。

7、這不是我們希望在BPMN 中看到的。錯誤的建?？赡軙沁@樣的：4一2.2 獨立實例2.2.1 模型場景我們想給并行發(fā)生的實例建模。我們使用一個簡單例子。檢查客戶的信用額度，我們不想再相同的時間檢查同一個客戶的信用額度。原因是額度檢查的總數(shù)會影響到檢查的結(jié)果。比如我們正在對一個客戶進行額度檢查的時候，我們同時收到了第二個對于相同客戶的請求。一般常用的解決方案是在啟動實際的信用額度檢查之前，需要在數(shù)據(jù)級別上檢查并行實例。2.2.2 使用單個事件的解決方案解釋說明： 單個事件是最簡單最緊湊地對多個實例之間交互進行建模的方法。使用信號的問題是它使用廣播的方式而且不標記任何具體的實例。所以，嚴格地說，客

8、戶會忽略，所有等待的實例都可以獲得。2.2.3 使用消息事件的解決方案解釋說明：這個解決方案更加復雜一些，因為你需要決定消息的接受者（每個實例）。這還包括實例結(jié)束前的第二次數(shù)據(jù)請求。 無論如何， 這也是解決單事件解決方案中發(fā)生的問題的正確的方法。5一2.2.4 使用定時器和循環(huán)的解決方案解釋說明：在這個例子中，我們不需要實例之間的通信。實例本身周期性地檢查是否可以進行額度檢查。這個方案不好的地方時可能會導致延時和循環(huán)導致的開銷。2.3 四眼原則2.3.1 建模場景我們想使用 BPMN2.0 對以下場景建模。對于一個請求（比如支付） ，兩個不同的人的兩次批準是需要的。流程引起應確保在請求獲批之前

9、，兩個批準都執(zhí)行。兩個審批者手工執(zhí)行的步驟應該在 BPMN 圖中體現(xiàn)。審批者的決定是在門戶的任務列表中做出的。用例這個樣式的用例有很多。比如：支付批準；采購單批準；合同批準 6一2.3.2 BPMN2.0 解決方案圖2.3.3 解釋說明我們讓流程引擎對于第一和第二個審批者獨立的泳池。這種方式， 我們可以很清楚地定義誰在控制這個流程。用戶任務和審批者手動過程是通過消息流來建模的。這些消息流封裝了需要審批者執(zhí)行來完成用戶任務的手工步驟。為了減低復雜性，任務清單本身并沒有建模。7一2.3.4 變體2.3.4.1 審批者作為下級池2.3.4.2 審批者使用LDAP 來決定8一2.4 月結(jié)單2.4.1

10、建模場景這個例子解釋了非常普遍的 BPMN2.0 圖布局中糾結(jié)的問題。比如，有個律師給他的客戶提供法律咨詢。這個服務工作流程如下：客戶可以在他們需要的任何時候來尋求法律咨詢。律師提供所需建議并將計費時間記錄在客戶的時間表中。 但一個月結(jié)束的時候， 律師的財務人員基于時間表確定計費時間，并生成賬單。2.4.2 BPMN2.0 解決方案2.4.3 解釋說明這個圖最重要的方面是它的結(jié)構(gòu)。 提供法律咨詢在每個月會執(zhí)行很多次。 月結(jié)單每個月只執(zhí)行一次。因此，這兩個過程應該作為獨立的泳池來建模。當然，這兩個泳池也不是相互之間完全獨立的。 為什么呢？它們工作在相同的數(shù)據(jù)之上客戶端時間表。我們要在 BPMN

11、中建模這樣數(shù)據(jù)連接相關的模型能力是很有限的。這是因為 BPMN 聚焦在控制流而不是數(shù)據(jù)流上。無論如何，我們可以使用數(shù)據(jù)存儲元素來對數(shù)據(jù)連接進行建模。2.4.4 錯誤的建模方式解釋為何是錯誤的：本例中，兩個過程混合在一起。最好是非常顯性地將兩個流程建模。9一這.個模型可能意思是對于每個法律咨詢在一個月結(jié)束會都要發(fā)送一個賬單。 這種建模的方法在大多數(shù)場合下都是錯誤的。2.5 用戶任務后需要額外的信息建模場景： 我們假設想對以下場景進行建模： 我們想執(zhí)行一個用戶在門戶上完成的用戶任務。在用戶任務完成之后，需要額外的信息，流程引擎發(fā)送信息請求給另一個人或給一個技術服務人員。2.5.1 解決方案 1：從

12、另一個人處請求信息2.5.2 解決方案 2：從技術服務人員處請求信息10一2.6 處理來自商城的批量訂單2.6.1 場景我們想使用BPMN2.0 建模以下場景：假設一個公司從不同的分銷渠道的訂單。這些渠道之一是商城。在某個時間內(nèi)，從商城來的訂單是批量獲得的。批量單中的每個單在導入到ERP系統(tǒng)之前需要進行校驗。2.6.2 使用 BPMN2.0 流程的解決方案解釋說明：這個例子顯示了非常普遍的建模場景。我們有時叫做一到多問題。一個流程實例（導入訂單）會導致很多另外的流程 （ ERP系統(tǒng)）。典型構(gòu)造方法是多實例或循環(huán)， 使用消息 （消息流）來啟動其他的流程。2.7 重新安排用戶任務2.7.1 建模場

13、景假設我們需要某個任務是完全執(zhí)行的。 因此，用戶任務需要在當前分配者不可用的時候盡可能的重新安排，比如，由于臨時離開或生病了。11一2.7.2 解決方案 1：消息邊界時間和重新分配服務注：這個流程通過調(diào)用服務來確定新的分配者。2.7.3 解決方案 2：消息邊界時間和重新分配規(guī)則注：這個流程通過調(diào)用規(guī)則引擎來確定新的分配者。12一2.7.4 解決方案 3：消息邊界事件和隱性分配注：這個流程本身確定分配者，比如使用表達式。2.8 兩步提升2.8.1 建模場景我們使用下面的例子圖示如何對兩步提升使用BPMN2.0 來建模。當我們需要訂披薩時，我們定了一個。 有時披薩派送太忙了， 派送超過了 20 分

14、鐘。然后我們就投訴派送服務。 之后，我們給他們額外 30 分鐘的派送派送。如果他們沒有準時送到，我們就放棄并取消我們訂單。2.8.2 解決方案 1：兩個基于時間的網(wǎng)關這個解決方案的優(yōu)點：這個解決方案非常顯性地展示了兩步提升的執(zhí)行過程。計時器分別建模，隨后是它們相應的提升活動。這個解決方案的缺點：基于時間的網(wǎng)關并補充一個BPMN 標準中的直觀的BPMN 符號，需要有一定的經(jīng)驗。使用基于兩個事件網(wǎng)關讓模型更大，導致復制了“Pizza received ”消息事件。13一2.8.3 解決方案 2：使用附加計時器接收任務這個解決方案的優(yōu)點：這個模型比第一個模型要小，而且可能是大多數(shù)開發(fā)人員使用引擎來解

15、決問題的方法。因為我們使用兩個非中斷的附加計時器事件，這個解決方案在出現(xiàn)多個投訴方案的時候更加靈活（比如我們想每5 分鐘，直到50 分鐘過了） 。這個解決方案的缺點：對于業(yè)務人員來說， 接收任務通常不是直觀的， 他們可能使用消息接收時間來處理這種等待狀態(tài)。這個將中斷的或非中斷的計時器協(xié)同使用的方法需要對附加的事件有透徹的了解。2.8.4 解決方案 3：一個使用通用計時器的基于事件的網(wǎng)關解決方案的優(yōu)點：這個模型緊湊通用。如果變成n 步提升的話，你需要這個通用的方法來避免圖形太大。解決方案的缺點：通用解決方案比其他解決方法更不直觀。 我們不能看到實際的計時器事件， 因為一個計時器應在兩個時間段。對

16、于快速了解兩步提升來說，這個方法不合適。14一.3 BPMN 建模風格3.1 避免交叉線3.1.1 建議這個 BPMN 例子是有關如何創(chuàng)建好的流程模型布局的。更好的布局， 更高的理解度。 這是我們在創(chuàng)建流程模型的時候需要達到的目標。盡可能地努力避免交叉的流線。這將對有經(jīng)驗和沒有經(jīng)驗的BPMN 用戶來說二者都可以增加BPMN 流程模型的理解。當然，并不是總是可以避免這個問題的。但需要時刻在腦袋里記住需要投入額外的時間來優(yōu)化布局，采用將大多數(shù)交叉線減少的方式布局。3.1.2 處理流線的好的例子3.1.3 反例15一3.2 命名規(guī)則3.2.1 建議最重要的是：每個BPMN 符號都要有標簽。事件應該使

17、用名詞 + 過去分詞來標記。開始事件總是使用表示流程觸發(fā)的標記。結(jié)束事件應標記流程終止。流程本身也應該標識。標識應該表示流程的名稱以及執(zhí)行流程的角色。任務應該使用名詞+ 動詞的方式標記。這樣強迫建模的人集中在任務中所作的事情。異或邏輯網(wǎng)關應該標記為一個問題。隨后的順序流應該標記為問題可能的答案（各種條件）。3.2.2 好的例子3.2.3 通用實例16一3.2.4 反例3.3 對稱建模3.3.1 建議我們知道無論是有經(jīng)驗的用戶還是沒有經(jīng)驗的用戶，對稱結(jié)構(gòu)都便于他們理解流程。3.3.2 使用對稱結(jié)構(gòu)的好例子17一3.3.3 反例3.3.4 另一個對稱結(jié)構(gòu)的好例子3.3.5 另一個反例3.4 使用相

18、同大小的任務框3.4.1 建議我們建議總是使用相同大小的任務框。原因很簡單。人們傾向于解釋任務框大小，雖然大小在BPMN 標準中不代表任何語義。一些人認為更大的任務框比小的任務框更重要按照BPMN ，這是錯誤的。一些人認為更大的任務比小的任務框需要更多的時間按照BPMN ，這也是錯誤。你可以很容易滴使用相同大小的任務框來避免這些疑惑。18一3.4.2 使用相同大小任務框的好例子3.4.3 反例19一.4 附 1：BPMN 2.0 總圖205 附 2：BPMN 2.0 圖元5.1 事件圖元事件圖元 按過程進程共分為三大類：開始事件類、中間事件類、結(jié)束事件類。按事件類型分類如下：1)常規(guī)事件類：為

19、無類型事件類，表示狀態(tài)的開始、轉(zhuǎn)換或結(jié)束。2)消息事件類：帶有消息參數(shù)的事件，可以接收或發(fā)送消息。3)時間事件類：時間事件表示時間點（定時和超時）以及時間區(qū)間。4)升級事件類：從當前的業(yè)務過程跳轉(zhuǎn)到更高層級的業(yè)務過程。5)條件事件類：業(yè)務條件改變或引入新的業(yè)務規(guī)則時引發(fā)的事件。1. 常規(guī)事件類1)頂層事件2)中斷子過程事件3)非中斷子過程事件4)捕獲事件5)中斷邊界事件6)非中斷邊界事件217) 拋出事件2. 鏈接事件類：為鏈接符類，將在不同位置上的業(yè)務過程連接成為一個過程。3. 錯誤事件類：捕獲或拋出已知的錯誤事件。4. 取消事件類：包括無響應取消和有響應取消。5. 補償事件類：觸發(fā)補償處理

20、過程。6. 信號事件類：在不同業(yè)務過程之間傳遞信號，一個信號可以被多次發(fā)送。7. 多重事件類： 多重事件包含多種可能的觸發(fā)事件， 執(zhí)行時根據(jù)捕獲的消息決 定拋出的特定類型的事件。8. 并行多重事件類： 包含多種可能的觸發(fā)事件， 執(zhí)行時根據(jù)捕獲的消息可并行 的拋出多種類型的事件9. 終止事件：立即結(jié)束過程225.2 泳池與泳道1. 泳池和泳道：泳池和泳道都表示活動的參與者，即表示過程中活動的執(zhí)行者，它可以是一個組織、角色或系統(tǒng)。泳池可以劃分成多個泳道，泳道具有分層結(jié)構(gòu)。2.消息流：消息流是跨越組織邊界的信息流。消息流可以與泳池、活動或消息事件連在一起。3. 消息交換次序：由組合消息流和順序流決定

21、。5.3 數(shù)據(jù)23數(shù)據(jù)：1. 輸入數(shù)據(jù)：整個過程中可以被活動讀取的外部數(shù)據(jù)。2. 輸出數(shù)據(jù)：作為整個過程的輸出數(shù)據(jù)量。3.數(shù)據(jù)對象：代表過程中流動的信息，例如：業(yè)務文件、E-mail 、信件。4. 數(shù)據(jù)對象集：表示數(shù)據(jù)對象的集合，例如：訂單列表。5. 數(shù)據(jù)存儲： 存放過程數(shù)據(jù)的地方， 例如數(shù)據(jù)庫或文件。 其生命周期超過了過 程實例的生命周期，即過程實例結(jié)束了，但數(shù)據(jù)依然存在。6. 消息：消息用來表示兩個參與者之間通訊的內(nèi)容。5.4 編排編排圖元：1. 編排任務：代表參與者之間基于消息交換的互動。2. 多例參與者標記：表示一個由同類型參與者組成的集合。3. 復合編排任務：帶有子過程的復合任務。2

22、45.5 邏輯門（網(wǎng)關）邏輯門（又名網(wǎng)關）：1. 排他邏輯門： 對于過程分解的情況， 當活動流抵達該邏輯門時，將會在所有滿足條件的流出分支中、按照既定規(guī)則選取其中一個分支執(zhí)行。對于過程歸并的情況，當有一個活動流抵達該邏輯門時，即執(zhí)行流出分支。2. 事件邏輯門： 該邏輯門總是與捕獲事件或任務接收對象相連，當活動流抵達該邏輯門時總是選擇后續(xù)最早發(fā)生的事件分支執(zhí)行。3. 并行邏輯門： 對于過程分解的情況， 當活動流抵達該邏輯門時， 并行地執(zhí)行后續(xù)所有流出分支。對于過程歸并的情況， 當所有的活動流都抵達該 邏輯門時，即執(zhí)行流出分支。254. 相容邏輯門： 對于過程分解的情況，當活動流到達該邏輯門時， 執(zhí)行所有滿足條件的流出分支。5. 復雜邏輯門：其他邏輯門不能表達的歸并與分 解的行為均采用此邏輯門。此邏輯門的主要作 用是表達同步的行為。它允許多個分支流入并連接多個流出分支。復雜邏輯門攜帶多個參數(shù)并由參數(shù)的設定來表達該邏輯門的具體語義。這四個參數(shù)是：1) activationCondition:定義了觸發(fā)該邏輯門的條件，即流入分支的一種組合狀態(tài)。2) defa