BPMN和DMN基本概念和使用案例

BPMN(Business Process Model and Notation)

• 标准
  BPMN 不属于某个企业，而是属于某个机构（OMG），该机构已经通过其他世界范围的标准（例如UML）建立起来。许多软件产品都支持该标准；您对任何特定供应商的产品的依赖程度较低。
  
• 简单
  BPMN 背后的原理相当简单，这就是为什么您可以很快开始使用这种表示法。
  
• 表达的力量
  如有必要，您可以准确描述流程如何使用 BPMN。然而，这比仅仅粗略地描述这个过程要困难得多。这种精确建模的方式是可能的，但不是强制性的。
  
• 在 IT 中的实施
  BPMN 主要用于支持流程的技术实施（“流程自动化”）。IT 在公司中越重要，使用 BPMN 就越有用。
  

BPMN 中的简单流程

开始事件：开始事件显示哪个事件导致进程启动。开始事件总是捕捉事件。
任务：任务是流程的核心。最终，必须发生一些事情才能带来预期的结果。在BPMN中，任务在技术上是活动类别的一部分，其中还包括子流程。
中间事件：中间事件表示在流程中达到的状态，并且是明确建模的。它们很少使用，但中间事件可能很有用，例如，如果您将达到某个状态视为一个里程碑，并且您想要测量达到该里程碑之前的时间。中间无事件总是抛出事件。
结束事件：结束事件标记在流程路径结束时达到的状态。结束事件总是抛出事件。
此图显示了一个由饥饿触发的简单过程。结果是有人必须购买杂货并准备饭菜。之后，有人会吃这顿饭并满足他或她的饥饿感。

例子

装运流程

并行网关：在流程实例化之后，有两件事情是并行完成的，正如并行网关所指示的那样:当文员必须决定这是普通邮件还是特殊货物时(我们没有定义如何在内部决定的标准流程模型)，仓库工人已经可以开始包装货物了。
任务：该文员的任务，其后是专有网关“交付方式”，是阐明专有基于数据的网关的推荐用法的—个很好的例子:网关不负责决定这是特殊的还是特殊的邮政运输。相反，这个决定是在活动之前进行的。网关仅作为路由器工作，它基于上一个任务的结果，并提供替代路径。一个任务代表一个实际的工作单元，而网关只是路由顺序流。
排他网关：这个网关被称为”独家”，因为只有以下两个分支中的一个可以遍历:如果我们需要特殊货物，业务员要求不同承运人的报价，然后指定承运人并准备文书工作。但是，如果正常邮寄是可以的，店员需要检查是否需要额外的保险。
包容性网关：如果需要额外的保险，物流经理必须购买该保险。在任何情况下，文员都必须为货件填写邮政标签。对于这种情况,显示的包容性网关很有帮助，因为我们可以显示始终采用一个分支，而另一个仅在需要额外保险的情况下，但如果采用，这可以与第一个分支并行发生。由于这种并行性，我们需要在”填写帖子标签”和“购买额外保险”后面的同步包容性网关。
包容性网关（同步）：在这种情况下，包容性网关将始终等待“填写帖子标签”完成，因为这始终是启动的。如果需要额外保险，包容性网关也将等待”购买额外保险”完成。
并行网关（同步）：此外，我们还需要在最后一个任务“添加文书工作并将包裹移动到挑选区域”之前同步并行网关，因为我们要确保在执行最后—个任务之前一切都已完成。

在这个例子中，我们只为参与这个过程的人使用了一个池和不同的通道，这自动意味着我们取消了这些人之间的通信：我们只是假设他们以某种方式相互通信。如果我们有一个流程引擎来驱动这个流程，那么该引擎将分配用户任务，因此负责这些人之间的通信。如果我们没有这样的流程引擎，但想明确地对相关人员之间的通信进行建模，我们将不得不使用下一章中描述的协作图。

比萨合作

DMN（Decision Model and Notation决策模型标记）

• 标准
  DMN 不属于某个企业，而是属于某个机构（OMG），该机构已经通过其他世界范围的标准（例如 BPMN 和 UML）建立起来。DMN 标准受到多种软件产品的支持；您对任何特定供应商的产品的依赖程度较低。
  
• 直接执行
  在 DMN 中，可以使用相同的语言对决策进行建模和执行。业务分析师可以在易于阅读的表格中对导致决策的规则进行建模，这些表格可以由决策引擎（如 Camunda）直接执行。这将业务分析师和开发人员之间产生误解的风险降至最低，甚至允许快速更改生产。
  
• 经验
  DMN 作为标准还很年轻，但它是由拥有数十年业务规则管理经验的人开发的。尽管如此，该标准并没有规定任何特殊的实现模式，允许比传统业务规则引擎更现代和轻量级的实现。
  

一个简单的决策表

我们应该从一个相当简单的决策表开始我们的 DMN 教程：
假设我们邀请了一些客人共进晚餐。问题是，我们应该准备哪道菜。在这个例子中，我们遵循一个非常简单的决策逻辑：根据当前季节，我们决定菜肴。如果是秋天，我们会去吃排骨，冬天去吃烤牛肉等等。
让我们看看这个例子中的元素：

• 在左上角，我们找到这个决策表的 名称 ：“Dish”
• 下面是一个“U”，代表 唯一 ，是该决策表定义的 命中策略 。这意味着，当必须做出决定时，只有下面的一行可以为真。在这种情况下，当前季节只能是秋季、冬季、春季或夏季。我们不能同时拥有两个季节，即使今年夏天冷得要命。
• 浅绿色的列是指可能的 输入 数据。在这个例子中，只有一个输入列，因为我们只对当前季节感兴趣。带有文本“季节”的单元格对此进行了定义。在 DMN 中，这是 输入表达式的标签。为简单起见，表达式本身在此示例中被隐藏，但将在本教程的后面部分显示。下面的单元格（称为 输入条目）是指有关输入的可能条件。这些条件用引号引起来（如“Summer”），这是因为我们在技术上比较字符串值。
• 对于每个可能的输入条目（即当前季节的名称），我们 在其旁边的单元格中定义相应的输出条目。这就是我们根据季节表达的方式，我们想要某道菜。同样，我们必须使用引号（如“Steak”），因为从技术上讲，我们正在分配字符串值。
• 根据为真的输入条目（或真输入条目的组合），应应用特定输出条目的定义是 规则。每个规则都在表格标题下方的表格行中定义，并有一个编号，您可以在左侧的单元格中找到该编号。
• 最后但并非最不重要的一点是，您可以 在右侧的列中注释您的规则。这些注释只是为了解释而存在，并且会被决策引擎忽略。

组合条件

介绍感觉

现在您已经对决策表结构有了基本的了解，让我们仔细看看可能的输入条目。很简单地说，某些数据应该与某些字符串进行比较（例如，季节应该是夏天）。但是 DMN 提供了更高级的概念来检查输入条目。DMN 标准的一部分是 足够友好的表达语言 (FEEL)。
FEEL 定义了一种语法，用于表达输入数据应该被评估的条件。例如，您可以在 FEEL 中描述某个输入数据应该是

• 一个具体的字符串（比如季节，应该是“夏天”）
• 真或假（比如我们的客人是素食主义者）
• 低于、高于或与另一个给定数字完全相同的数字
• 一个介于最小给定数字和最大给定数字之间的数字
• 早于、晚于或与另一个给定日期相同的日期
• …以及更多

要获得第一个想法，请查看以下示例：
您会注意到的第一件事是另外两行带有灰色单元格。这些行描述了决策引擎执行决策所需的技术细节。第一个包含表达式——在这种情况下——简单地引用变量名，即season、guestCount 和desiredDish。第二个告诉引擎表达式各自结果的类型，在这种情况下是字符串和整数。
在第一个示例中，这些行被隐藏了，以免一开始就让你不知所措。但实际上，这些类型很重要，因为它们决定了哪些 FEEL 表达式可用于输入条目。
让我们看看每条规则，即每一行：

1. 如果是秋天，您预计最多有 8 位客人，您将准备排骨。
2. 如果是冬天，您预计最多有 8 位客人，您将为他们提供烤牛肉。
3. 如果是春天，您预计最多可容纳 4 位客人，您可以享用非常精致的干式陈年牛排，让他们尽情享受。
4. 如果是春天，您预计有 5 到 8 位客人，您将为他们提供一份普通的牛排。
5. 如果是秋季、冬季或春季，并且您预计超过 8 位客人，您会去炖菜。
6. 如果是夏天，无论如何都会有一份清淡的沙拉，当然还有一份美味的牛排。耶！

正如您可能已经猜到的那样，这只是冰山一角。正如我们在 DMN 参考指南中描述的那样，您可以在 DMN 决策表中表达更多内容。

DMN 和 BPMN 流程

决策需求图

如果您想讨论和分析可能由其他决策组成的复杂决策，决策需求图 (DRD) 可能会有所帮助。这是 DMN 标准中定义的一个非常简单的符号，基本上由

• 决策：使用逻辑定义从多个输入值中确定输出值的行为。这个决策逻辑是你可以在决策表中表达的。
• 输入数据：您“输入”到决策逻辑以确定输出值的输入数据。
• 决策之间的关系：您可以将决策与箭头连接起来，从而指示哪个决策输出将被视为另一个决策的输入。