【问题标题】:BPMN Modelling: Parallel Processes, Dependency on Status of an Incomplete ProcessBPMN 建模:并行流程,对不完整流程状态的依赖
【发布时间】:2021-05-28 07:06:23
【问题描述】:

我正在尝试对拆分为 2 个并行线程的进程进行建模,其中线程 1 通过里程碑独立进行,而线程 2 需要考虑其自身的进度 + 线程 1 的状态才能通过里程碑。最后,两个线程都需要完成。我该如何建模? (下面是我最好的尝试)

【问题讨论】:

    标签: parallel-processing synchronization state modeling bpmn


    【解决方案1】:

    您建模的内容会起作用。但是,您不需要中间事件。您可以直接连接到任务。而且您不需要包容性网关。它会起作用,但并行网关会做同样的事情并且不那么复杂。

    【讨论】:

      【解决方案2】:

      总之

      将传入事件与下分支上的正常流合并的方式存在问题。使用的符号不明确,不保证符合执行语义。

      更多详情

      该图可能会如您所愿地被理解。但由于缺少同步,从 BPMN 执行语义的角度来看是不正确的。

      让我们根据执行语义(规范第13章),用token的概念来分析流程:

      一个进程在其启动事件之一发生时被实例化。

      发生的每个开始事件都会在其传出的序列流上创建一个标记

      要使流程实例完成,该实例中的所有令牌都必须到达结束节点,即没有传出序列流的节点

      因此,在您的流程开始时,会创建一个令牌,并将其传递给第一个任务。然后你就有了一个 fork 的并行网关:

      并行网关从每个传入序列流中仅使用一个令牌,并在每个传出序列流中仅生成一个令牌。

      然后你有 2 个令牌,它们将流向第一个上层和第一个下层任务。上层令牌将继续到“无”中间事件。较低的令牌将到达“合并门”的入口。问题是我们是否保证在每个并行分支上保留一个令牌。

      “无”中间门将抛出令牌并将其传递到传出流中。因此生成了 2 个令牌:一个到下一个上层任务,一个到“合并门”。

      我通俗地称为“合并门”实际上在您的图表中是模棱两可的:

      • 它不能是独占网关,因为这将通过它路由每个传入的令牌。这意味着在较低的分支中,我们最终会得到两个令牌。这是不合法的。
      • 它可能是一个包容性网关。但是里面的符号应该是一个简单的圆圈,而不是你使用的双圆圈。包容性流程消耗输入上所有可用的令牌,但它至少需要一个令牌才能激活,并且不需要等待所有令牌都在那里。没有同步保证,如果其中一个分支有最轻微的延迟,您最终可能会在较低的流上获得多个令牌。这是不可接受的。
      • 基于事件的网关是两步网关。第一个是内部有五边形的事件,它必须有几个流出的流,每个流都会导致要接收的不同类型的事件。在这种情况下,这是没有意义的,因为我们预计不会发生多种事件。
      • 根据 Carmunda 的 Freund & Rücker 所著的“Real-Life BPMN”一书,解决方案是使用复杂的网关,即带有一个大的内部“*”符号和一个条件描述,表明所有输入必须可用。然后,您将被保证在较低流中只有一个传出令牌
      • 我个人会推荐一个并行连接网关:实际上,来自中间事件的两个传出流是不受控制的流,可以理解为隐式启动一个新的并行分支。然后,连接门将清楚地显示新隐式分支与较低分支的合并,并清楚地记录同步(也就是等待两个令牌都可用)。这似乎是迄今为止最合适的选择。
      • 更简单的替代方法是去掉较低的合并门,并为第二个较低的任务提供两个传入流。然后,这被理解为两个传入的不受控制的流,类似于隐式连接。它等同于之前的解决方案,但符号更少。

      最后两个选项是唯一保证在上分支和下分支上保留一个且恰好一个令牌的选项。然后,流程的其余部分将变得微不足道,直到结束。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2019-05-06
        • 2021-02-19
        • 1970-01-01
        • 2019-05-25
        • 2011-11-07
        相关资源
        最近更新 更多