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，这是另一种 命中策略，这意味着可能有多个规则为真，这将导致输出值列表。 例如，如果我们有排骨，而我们的客人带着孩子来，我们将提供水、苹果汁和著名的 Aecht Schlenkerla Rauchbier。 显然，在我们决定饮料之前，我们需要确定我们将准备的菜肴。这种关系就是你可以在 DRD 中描述的，就像我们在这个例子中所做的那样：
参考： https://camunda.com/bpmn/ https://camunda.com/dmn/
