BPMN(Business Process Model and Notation)
業務流程模型和表示 (BPMN) 是流程模組化的全球标準，也是成功實作業務-IT 協調的最重要組成部分之一。
越來越多的組織正在使用 BPMN，并且越來越多的大學将 BPMN 作為一門學科來教授。原因如下：
- 标準
BPMN 不屬于某個企業，而是屬于某個機構（OMG），該機構已經通過其他世界範圍的标準（例如UML）建立起來。許多軟體産品都支援該标準；您對任何特定供應商的産品的依賴程度較低。
- 簡單
BPMN 背後的原理相當簡單，這就是為什麼您可以很快開始使用這種表示法。
- 表達的力量
如有必要，您可以準确描述流程如何使用 BPMN。然而，這比僅僅粗略地描述這個過程要困難得多。這種精确模組化的方式是可能的，但不是強制性的。
- 在 IT 中的實施
BPMN 主要用于支援流程的技術實施（“流程自動化”）。IT 在公司中越重要，使用 BPMN 就越有用。
BPMN 中的簡單流程
開始事件：開始事件顯示哪個事件導緻程序啟動。開始事件總是捕捉事件。
任務：任務是流程的核心。最終，必須發生一些事情才能帶來預期的結果。在BPMN中，任務在技術上是活動類别的一部分，其中還包括子流程。
中間事件：中間事件表示在流程中達到的狀态，并且是明确模組化的。它們很少使用，但中間事件可能很有用，例如，如果您将達到某個狀态視為一個裡程碑，并且您想要測量達到該裡程碑之前的時間。中間無事件總是抛出事件。
結束事件：結束事件标記在流程路徑結束時達到的狀态。結束事件總是抛出事件。
此圖顯示了一個由饑餓觸發的簡單過程。結果是有人必須購買雜貨并準備飯菜。之後，有人會吃這頓飯并滿足他或她的饑餓感。
| 最佳實踐：命名約定 |
| 在命名任務時，我們盡量堅持使用[動詞] + [對象]模式的面向對象的設計原則。例如，我們會說“購買雜貨”，而不是“先處理購買雜貨”。 |
| 事件是指已經發生的事情，無論過程（如果它們正在捕獲事件）或作為過程的結果（如果它們正在抛出事件）。BPMN 不要求您對流程的開始和結束事件進行模組化——你可以将它們排除在外——但 如果 如果您開始為事件模組化，則必須為每條路徑模組化一個結束事件。對于需要開始事件的結束事件也是如此。我們總是使用開始和結束事件建立模型，原因有兩個：首先，這樣可以确定流程觸發器，其次，您可以描述每個路徑結束的最終狀态。我們隻是有時會通過子流程放棄這種做法。稍後再談。 |
| FAQ：水準畫BPMN圖是必須的嗎？如果我更喜歡垂直繪制它們怎麼辦？ |
| --- |
| 您總是可以從上到下而不是從左到右繪制圖表——BPMN 2.0 标準并沒有禁止它。但是，我們不建議這樣做：這是非常罕見的，經驗證明，如果以與書面文本相同的方式描述（從左到右，至少在西方世界），人們往往會更好地了解流程。 |
例子
裝運流程
并行網關：在流程執行個體化之後，有兩件事情是并行完成的，正如并行網關所訓示的那樣:當文員必須決定這是普通郵件還是特殊貨物時(我們沒有定義如何在内部決定的标準流程模型)，倉庫勞工已經可以開始包裝貨物了。
任務：該文員的任務，其後是專有網關“傳遞方式”，是闡明專有基于資料的網關的推薦用法的—個很好的例子:網關不負責決定這是特殊的還是特殊的郵政運輸。相反，這個決定是在活動之前進行的。網關僅作為路由器工作，它基于上一個任務的結果，并提供替代路徑。一個任務代表一個實際的工作單元，而網關隻是路由順序流。
排他網關：這個網關被稱為"獨家”，因為隻有以下兩個分支中的一個可以周遊:如果我們需要特殊貨物，業務員要求不同承運人的報價，然後指定承運人并準備文書工作。但是，如果正常郵寄是可以的，店員需要檢查是否需要額外的保險。
包容性網關：如果需要額外的保險，物流經理必須購買該保險。在任何情況下，文員都必須為貨件填寫郵政标簽。對于這種情況,顯示的包容性網關很有幫助，因為我們可以顯示始終采用一個分支，而另一個僅在需要額外保險的情況下，但如果采用，這可以與第一個分支并行發生。由于這種并行性，我們需要在"填寫文章标簽"和“購買額外保險"後面的同步包容性網關。
包容性網關（同步）：在這種情況下，包容性網關将始終等待“填寫文章标簽"完成，因為這始終是啟動的。如果需要額外保險，包容性網關也将等待"購買額外保險"完成。
并行網關（同步）：此外，我們還需要在最後一個任務“添加文書工作并将包裹移動到挑選區域”之前同步并行網關，因為我們要確定在執行最後—個任務之前一切都已完成。
在這個例子中，我們隻為參與這個過程的人使用了一個池和不同的通道，這自動意味着我們取消了這些人之間的通信：我們隻是假設他們以某種方式互相通信。如果我們有一個流程引擎來驅動這個流程，那麼該引擎将配置設定使用者任務，是以負責這些人之間的通信。如果我們沒有這樣的流程引擎，但想明确地對相關人員之間的通信進行模組化，我們将不得不使用下一章中描述的協作圖。
比薩合作
這個例子是關于企業對企業的協作。因為我們想要明确地模拟披薩顧客和供應商之間的互動，我們将他們歸類為“參與者”，是以為他們提供專用池：
兩個開始事件一個在顧客，一個在披薩商店。顧客開始事件：應該從肚子咕咕叫的披薩顧客開始。是以，客戶選擇披薩并訂購。披薩商店開始事件（也是消息事件）：由客戶的訂單觸發，如消息開始事件和從“訂購披薩"到該事件的消息流所示。披薩烤好後，外賣小哥會送披薩并收款。
消息事件：在此示例中，我們不僅将消息事件用于資訊對象（例如披薩訂單)，還用于實體對象(例如披薩)。我們可以這樣做是因為這些實體對象實際上本質上是作為資訊對象的:當披薩到達顧客家門口時，她會識别到這個到來，是以知道披薩已經到了，這正是消息中—緻消息事件的目的。客戶的遊泳池。當然，我們隻能以這種方式使用模型，因為此示例不打算由流程引擎執行。
請注意，這種類型的模組化沒有預設語義，這意味着您可以模組化協作圖以顯示業務夥伴之間的互動，也可以放大一個公司，模組化不同部門、團隊甚至單個勞工和軟體之間的互動協作圖中的系統。這完全取決于模型的目的，是以模組化者必須做出決定，不同池的協作圖是否有用，或者是否應該堅持使用不同通道的池。
DMN（Decision Model and Notation決策模型标記）
- 标準
DMN 不屬于某個企業，而是屬于某個機構（OMG），該機構已經通過其他世界範圍的标準（例如 BPMN 和 UML）建立起來。DMN 标準受到多種軟體産品的支援；您對任何特定供應商的産品的依賴程度較低。
- 直接執行
在 DMN 中，可以使用相同的語言對決策進行模組化和執行。業務分析師可以在易于閱讀的表格中對導緻決策的規則進行模組化，這些表格可以由決策引擎（如 Camunda）直接執行。這将業務分析師和開發人員之間産生誤解的風險降至最低，甚至允許快速更改生産。
- 經驗
DMN 作為标準還很年輕，但它是由擁有數十年業務規則管理經驗的人開發的。盡管如此，該标準并沒有規定任何特殊的實作模式，允許比傳統業務規則引擎更現代和輕量級的實作。
一個簡單的決策表
我們應該從一個相當簡單的決策表開始我們的 DMN 教程：
假設我們邀請了一些客人共進晚餐。問題是，我們應該準備哪道菜。在這個例子中，我們遵循一個非常簡單的決策邏輯：根據目前季節，我們決定菜肴。如果是秋天，我們會去吃排骨，冬天去吃烤牛肉等等。
讓我們看看這個例子中的元素：
- 在左上角，我們找到這個決策表的名稱：“Dish”
- 下面是一個“U”，代表唯一，是該決策表定義的命中政策。這意味着，當必須做出決定時，隻有下面的一行可以為真。在這種情況下，目前季節隻能是秋季、冬季、春季或夏季。我們不能同時擁有兩個季節，即使今年夏天冷得要命。
- 淺綠色的列是指可能的輸入資料。在這個例子中，隻有一個輸入列，因為我們隻對目前季節感興趣。帶有文本“季節”的單元格對此進行了定義。在 DMN 中，這是輸入表達式的标簽。為簡單起見，表達式本身在此示例中被隐藏，但将在本教程的後面部分顯示。下面的單元格（稱為輸入條目）是指有關輸入的可能條件。這些條件用引号引起來（如“Summer”），這是因為我們在技術上比較字元串值。
- 對于每個可能的輸入條目（即目前季節的名稱），我們 在其旁邊的單元格中定義相應的輸出條目。這就是我們根據季節表達的方式，我們想要某道菜。同樣，我們必須使用引号（如“Steak”），因為從技術上講，我們正在配置設定字元串值。
- 根據為真的輸入條目（或真輸入條目的組合），應應用特定輸出條目的定義是規則。每個規則都在表格标題下方的表格行中定義，并有一個編号，您可以在左側的單元格中找到該編号。
- 最後但并非最不重要的一點是，您可以 在右側的列中注釋您的規則。這些注釋隻是為了解釋而存在，并且會被決策引擎忽略。
組合條件
在許多情況下，規則不僅包含一個條件，而且包含多個條件。我們可以通過向決策表添加輸入列來表達這一點：
在這種情況下，我們可能要考慮素食客人。無論季節如何，我們都不能為他們提供任何肉類。幸運的是，我們總是有一些意大利面可用。通過結合“季節”和“素食客人”這兩個輸入列，我們確定前四個規則隻有在客人不是素食主義者的情況下才能評估為真。規則 5 在檢查季節的輸入條目中有一個“-”，這意味着它可以是任何季節，隻要客人是素食者，他們就會得到意大利面。
如您所見，規則中的輸入條目組合（即表格行）始終遵循 AND 邏輯：“如果是秋天 ， 我的客人不是素食主義者，我将提供排骨。”
介紹感覺
現在您已經對決策表結構有了基本的了解，讓我們仔細看看可能的輸入條目。很簡單地說，某些資料應該與某些字元串進行比較（例如，季節應該是夏天）。但是 DMN 提供了更進階的概念來檢查輸入條目。DMN 标準的一部分是 足夠友好的表達語言 (FEEL)。
FEEL 定義了一種文法，用于表達輸入資料應該被評估的條件。例如，您可以在 FEEL 中描述某個輸入資料應該是
- 一個具體的字元串（比如季節，應該是“夏天”）
- 真或假（比如我們的客人是素食主義者）
- 低于、高于或與另一個給定數字完全相同的數字
- 一個介于最小給定數字和最大給定數字之間的數字
- 早于、晚于或與另一個給定日期相同的日期
- …以及更多
要獲得第一個想法，請檢視以下示例：
您會注意到的第一件事是另外兩行帶有灰色單元格。這些行描述了決策引擎執行決策所需的技術細節。第一個包含表達式——在這種情況下——簡單地引用變量名，即season、guestCount 和desiredDish。第二個告訴引擎表達式各自結果的類型，在這種情況下是字元串和整數。
在第一個示例中，這些行被隐藏了，以免一開始就讓你不知所措。但實際上，這些類型很重要，因為它們決定了哪些 FEEL 表達式可用于輸入條目。
讓我們看看每條規則，即每一行：
- 如果是秋天，您預計最多有 8 位客人，您将準備排骨。
- 如果是冬天，您預計最多有 8 位客人，您将為他們提供烤牛肉。
- 如果是春天，您預計最多可容納 4 位客人，您可以享用非常精緻的幹式陳年牛排，讓他們盡情享受。
- 如果是春天，您預計有 5 到 8 位客人，您将為他們提供一份普通的牛排。
- 如果是秋季、冬季或春季，并且您預計超過 8 位客人，您會去炖菜。
- 如果是夏天，無論如何都會有一份清淡的沙拉，當然還有一份美味的牛排。耶！
正如您可能已經猜到的那樣，這隻是冰山一角。正如我們在 DMN 參考指南中描述的那樣，您可以在 DMN 決策表中表達更多内容。
DMN 和 BPMN 流程
也許你在想：
嘿，我為什麼要使用 DMN，我可以用 BPMN 網關表達這些規則！
如果我們用 BPMN 來表達上面的例子，它看起來像這樣：
遺憾是顯而易見的：在 BPMN 中表達規則更加冗長，尤其是在需要考慮多個條件時。圖表變得複雜且難以維護。
這就是為什麼 BPMN 包含一個所謂的 業務規則任務，在 BPMN 标準的後續版本中最好将其命名為 決策任務 ：該任務是指需要做出的決策，決策的結果允許後續路由流的專用網關，如下例所示。
在模組化和執行過程中，我們可以将“Decide Dish”任務連結到 DMN 決策表，該決策表将在應該做出決策時執行，結果将決定 BPMN 中的進一步流程。
在這個特定的示例中，您無論如何都可以質疑流路由的使用。有六項任務是關于準備一頓飯的，唯一的差別是飯菜的種類。擁有這六個不同的任務并沒有明顯的優勢。另一種模式如下：
這太容易了，對吧？但在這種情況下，它實際上是一個合适的模式。
決策需求圖
如果您想讨論和分析可能由其他決策組成的複雜決策，決策需求圖 (DRD) 可能會有所幫助。這是 DMN 标準中定義的一個非常簡單的符号，基本上由
- 決策：使用邏輯定義從多個輸入值中确定輸出值的行為。這個決策邏輯是你可以在決策表中表達的。
- 輸入資料：您“輸入”到決策邏輯以确定輸出值的輸入資料。
- 決策之間的關系：您可以将決策與箭頭連接配接起來，進而訓示哪個決策輸出将被視為另一個決策的輸入。
DRD 符号中還有一些符号，但最相關的是這三個。我們應該看一個例子：
假設對于我們的晚餐，我們還需要決定要供應的飲料。該決定應基于我們将準備的菜肴并考慮兒童。決策表可能如下所示：
您會注意到該表的左上角有一個“C”，而不是您在前面的示例中看到的“U”。C 代表 Collect，這是另一種 命中政策，這意味着可能有多個規則為真，這将導緻輸出值清單。