英语原文共 13 页，剩余内容已隐藏，支付完成后下载完整资料
BPMN 2.0：支持和实施的状态
作者A[Matthias Geiger , Simon Harrer，Guido Wirtz] B[ Jouml;rg Lenhardb]
- 班贝格大学分布式系统组，An der Weberei 5，96047，德国班贝格
- 卡尔斯塔德大学数学与计算机科学系，Universitetsgatan 2，65188，瑞典卡尔斯塔德
强调：
bull;BPMN的47个供应商实现中只有三个确实支持直接执行本地BPMN格式。
bull;这三种实现仅支持BPMN的大约一半功能。
bull;功能支持足以实现20个工作流控制流模式中的至少13个。
bull;部署过程中通常不会拒绝错误的流程模型。
bull;过去四年中功能支持的增长有限
文章信息：
1.文章历史
2016年7月14日收到
以修改后的格式收到
2016年11月30日
2017年1月7日接受
2017年1月13日在线提供
2.关键词
BPMN
流程引擎
软件演变
一致性测试
摘要：
业务流程模型和符号2.0（BPMN）标准被誉为业务流程建模和自动化的重要一步。 最近，它也被接受为ISO标准。 期望的是，业务流程管理系统（BPMS）的供应商将切换到新的标准，并本身支持其在流程引擎中的执行。
本文分析了BPMN 2.0支持和实施的现状和发展。 我们调查BPMN 2.0实施者如何处理标准，表明本机BPMN 2.0执行是一个例外。 在47个BPMS中，只有三个支持标准中定义的执行格式，尽管它们都声称符合BPMN 2.0标准。 此外，我们评估了三种提供本地BPMN支持的流程引擎，即camunda BPM，jBPM和activiti，并检查三年以上支持度的演变情况。 这使我们可以划定实施者认为重要的标准领域。 由于过去几年支持的功能只有有限的增加，似乎标准的实施或多或少都是从实施者的角度出发的。 因此，将来不可能实现现在不可用的功能。
copy;2017 Elsevier B.V.保留所有权利。
- 介绍
业务流程管理（BPM）是一个广泛的学科，对计算研究的其他领域（如服务）有影响
组成[1]。 BPM非常适合专用建模语言中组织过程的建模以及后续可执行软件中过程模型的实现。 在许多用于过程建模的语言中（如[2]中讨论的例子），业务模型和表示法（BPMN）[3]已经成为工业界和学术界广泛接受的候选人[4]。 其巩固过程标准市场的潜力得到了随后被接受为ISO标准的强调[5] .(1)
随着2011年1月发布BPMN 2.0，支持本地执行BPMN流程模型和标准化序列化格式已经被添加到标准中。这种加入的目的是为了减小流程建模与通过软件执行流程之间的差距[4]。当通过将模型转换为可执行软件弥合这种差距时，不管所用的具体建模语言如何，出现各种各样的问题，这些问题是各种出版物的主题，例如[6-8]。特别是对于行业规模的流程模型，这种手动平移步骤并不重要，可能会导致实际行为的偏差从过程模型中捕获的期望的执行语义开始实现流程实现。由BPMN 2.0启用的流程模型的直接执行旨在最大限度地减少期望行为与实际行为之间的距离。它首先避免了翻译步骤的必要性，并有可能抢占先机实现与相应行为的行为偏差模型。
在BPMN 2.0 [5]中实现的标准文档中过程模型的执行语义规范是实现直接执行目标的第一步。作为一个下一步，执行语义必须由供应商支持的正确和完全实现标准。在BPMN的情况下，第二步面临两大障碍：一是执行指定执行语义学需要是可行的，遗憾的是单纯的理论和非正式的讨论无法保证这是BPMN 2.0标准中的执行语义[9]。其次，供应商需要真正实现相同的语义而不是解释或定制。由于没有BPMN的认证机构，任何供应商都可以申请
实施完整性和完全标准一致性，而无需证明此索赔。另一方面，它可能是正如[10]所指出的，从医师的观点来看，只有一部分BPMN是有价值的。因此，供应商可能只想实现标准的有限部分。
在本文中，我们将对BPMN 2.0实施者的当前产品进行全面调查。首先，我们分析一下一系列声称实施BPMN 2.0的供应商的产品。这表明绝大多数目前的自称BPMN 2.0实现仅限于可视化，并没有实际实现BPMN 2.0的执行语义。之后，我们将标准一致性分析从以前的工作[11]扩展到一套更复杂的测试，涵盖更高级别的可执行部分标准。此外，我们还分析是否支持所谓的工作流模式定义的共同特征组合[12]。我们比较了在三年多时间内支持BPMN 2.0原生执行的多个引擎的多个修订版本。这让我们看到了自从将它作为ISO标准采用以来BPMN 2.0支持如何发展。目前的发展表明，BPMN 2.0的实施正在进行巩固，从而排除了标准的大部分实际执行语义。
本文基于[13]并解决了几个缺点和弱点：（a）对发动机质量的见解有限，因为测试套件只包含一致性和表达性测试，（b）纵向研究仅限于两年的时间，最后但并非最不重要的是（c）同时发布了新的发动机版本，限制了目前的研究结果的基础数据。在这项工作中，我们如下缓解了这些问题。测试套件已经扩展了一个新的静态分析测试类别。这项新增加了测试数量的双倍，并为我们提供了关于发动机质量的更详细见解。此外，我们还增加了几个新图形的一致性数据的表示。通过增加新的引擎版本，我们能够将纵向研究的范围扩大三分之一。通过这一补充获得的附加结果加强了我们[13]的发现并加强了对数据的解释。最后但并非最不重要的是，我们更新了两个版本，相关的工作部分考虑到了与此同时发布的最新结果，以及通过重复基准测试以及编写本文时提供的最新引擎版本的引擎一致性数据。
本文的其余部分结构如下：下一节概述相关工作。 在第3节中，我们评估了47个产品
声称遵守BPMN 2.0。之后，在第4节中，我们详细介绍了评估BPMN引擎标准支持的过程，并展示了三种评估产品的结果。 纵向研究的结果显示了三年以上支持的发展，结论是我们在第五部分的研究结果。最后，第6节总结了这项工作。
- 相关工作
与本文相关的工作分为三个主要方面：首先，我们讨论涉及本机序列化格式和BPMN 2.0流程模型执行的工作，包括此任务期间遇到的问题。 其次，我们概述方法
评估和基准测试BPMN 2.0引擎。 第三，我们提出了构建可重复性基准的方法，这是我们在本文中的目标。
2.1 BPMN 2.0序列化格式和本地执行
自从首次发布以来，BPMN已经通过各种研究评估了其业务流程建模的适用性。 Aagesen和Krogstie [14]给出了相关工作的概述。
有一些研究调查了BPMN序列化格式的适用性，它的缺陷以及它在BPMN中的支持建模工具[15-17]。当涉及到BPMN 2.0执行语义和序列化格式的使用时，Chinosi和Trombetta [4]根据一项调查提出了第一批结果。在那个时候，在BPMN 2.0发布后不久，就有40％的人调查受访者声称使用新的本地序列化格式。但Eveacute;quoz和Sterren [16]当时对建模系统进行的分析仅记录了基本的支持，特别是对于标准化格式的出口。在[15]中讨论了BPMN序列化格式规范中的问题，并对建模工具中的BPMN支持进行了初步分析。Kurz [17]最近的研究表明，过去五年情况有了很大改善。如[17]所示，一个重要的原因是BPMN模型交换工作组（BPMN MIWG）的工作，该工作组旨在改进建模工具之间的模型可移植性.(2)
虽然之前的BPMN版本经常被分析和批评[18-20]，但是有关BPMN 2.0执行语义的研究
很少见，研究BPMN 2.0流程引擎的研究更是如此。正如Bouml;rger[9]所讨论的那样，对BPMN 2.0执行语义的描述在各个地方仍然不准确且不明确。因此，具有相同执行行为的完全符合标准的BPMN 2.0实现的目标是难以捉摸的[9]。Gutschier等人证实了同样的方面。 [21]，因为作者讨论了特定语言结构的不足指定，服务任务可能导致不同实现的运行时行为不同。还有Kossak等人。 [22]针对这一方面，并提供BPMN 2.0的执行语义及其缺点的全面讨论。为了改善这种情况，Kossak等人[22]完善规范使用抽象状态机。 [23]中介绍了另一种使用图形重写技术来形式化和分析BPMN 2.0执行语义的方法。 Gorp和Dijkman [23]声称他们的执行语义的实现可以看作是一个参考实现，并且可以用于工具供应商来检查他们对标准的一致性。与我们的方法相比，此一致性检查必须手动执行，而我们支持完全自动化的一致性检查。
2.2评估和基准测试BPMN 2.0引擎
当涉及到BPMN 2.0流程引擎的评估时，我们之前关于标准一致性的工作显然是相关的。由于我们基于这种方法，下面将对它进行更详细的描述。 Dirndorfer等人提出了一个分析一组BPMN 2.0引擎的几个功能的简短案例研究。[24]。 那时，实际上没有任何引人注意的引擎能够以本地BPMN序列化格式正确导入模型。 这是一个有趣的结果，我们在第3部分中对BPMN实现者的分析证实了这一点。然而，它与[4]中已经提到的结果相矛盾。建模工具之间似乎存在差异，这些工具能够创建和使用符合标准的BPMN 模型和执行引擎无法与这些模型一起工作。
除了对标准一致性的评估之外，还对BPMN 2.0引擎的其他方面进行了研究。 评估BPMN引擎性能特征的一个值得注意的方法是BenchFlow项目[25]。 Kluza等人 [26]提出了另一个比较研究，评估三个BPMN引擎activiti，jBPM和camunda BPM的总体架构和可扩展性。然而，[26]的重点是集成语义技术，如本体，以提高要执行的流程的质量。更广泛的研究，不仅包括BPMN引擎，还包括BPMS作为一个整体，[27]。 这项研究的重点更多地放在BPMS对业务需求的一般适用性上，而不是它们与流程标准的一致性上。 因此，标准支持仅在高层次上讨论。
2.3 计算重现性
可重复研究，尤其是计算重现性，是当今科学的关键[28]。 许多科学成果都是在广泛的软件工具的帮助下获得的，没有这些结果就不可能重现或检查结果的正确性。 为了实现计算重现性，Merali [28]建议最好通过版本控制系统免费提供必要的资料。 这包括科学计算所基于的记录，测试和模块化代码，以及所有其他所需资源和结果。 但即使遵循这些指导方针，试图重现实验的研究人员仍然面临着“重大障碍”[29]，例如，难以遵循的不准确文件或实验中使用的工具的学习曲线陡峭。
为了提高科学计算的可重复性，Boettiger [29]和Chamberlain和Schommer [30]建议使用Docker 作为计算环境的基础，(3)因为这项技术降低了上述几个障碍。在Docker中，可以创建基于Docker镜像的轻量级Linux容器。 这些图像可以共享，重用，归档，置于版本控制之下，并部署在不同的平台上[29]。 更重要的是，可以通过向Docker本身传递Dockerfile（即命令列表）来自动构建这样的图像，从而可以为第三方创建软件环境创建的复制。为了使本文提出的基准具有可重复性，它的执行基于Docker。这符合相关的基准测试方法[25]。
- 分析BPMN 2.0的实施者
为了收集有关BPMN实施状况的见解，有必要调查实施该标准的系统的当前市场。 为此，我们评估BPMN实现者的公共列表，并在本节中执行BPMN 2.0过程时判断其实现的状态。 只有现有实现的一小部分已经足够成熟，足以证明它们展示的标准一致性程度的评估。 本节介绍从实际市场中选择这种成熟的发动机。 第4部分分析了选定发动机的标准一致性程度。
乍一看，支持BPMN的BPM套件和引擎市场似乎相当活跃。 在编写本文时，BPMN实施者列表包含超过60个条目。(4) 但是，这些实现者不仅提供BPMN引擎，还提供BPMN建模工具或其他声称实现（某些）BPMN方面的工具。 关于BPMN执行语义一致性，只有完全成熟的BPMS套件或专用BPMN引擎才具有相关性，因为它们应该能够执行BPMN流程模型。
另一个“主动BPMN 2.0引擎列表”可在维基百科上找到(5)，它由BenchFlow项目的成员创建和维护.(6)在撰写本文时，列出了27个条目。在比较和合并这两个列表之后，我们 到达47个声称符合BPMN标准的BPM套件。 与之前的工作相比，这是两个BPM套件的增加[13]。
3.1 BPMN引擎的要求
标准文档[5]在流程执行一致性方面相当严格：“声明BPMN执行一致性类型的工具必须完全支持和解释子条款14.2.2中指定的操作语义和活动生命周期。符合的实现必须完全支持和解释基础元模型[5]。在这些语句之后，有两个与BPMN引擎和BPMS相关的主要方面：必须支持在BPMN元模型中定义的所有语言构造，并且对于每个语言构造，必须正确实现基础执行语义。唯一的例外是一些在[5]中定义的“非操作元素”。根据这两个要求，BPMN引擎还应能够检测BPMN流程模型，这些流程模型对于BPMN元模型是不正确的：如果在BPMN引擎上部署了这样一个无效流程，则其运行时行为不可预测。这个过程执行可能会失败，运行时异常可能会发生，或者可能发生其他意外行为。因此，BPMN兼容引擎应该能够检测到要部署的流程模型中违反BPMN规范[5]的情况，即它们应该在部署时执行静态分析检查。
BPMN标准化的目的是实现不同建模工具和引擎之间的可移植性和互操作性。 实现流程的常见工作流程是首先在BPMN建模工具中对“基本”业务流程模型进行建模，然后再为其提供用于执
全文共24425字，剩余内容已隐藏，支付完成后下载完整资料
资料编号：[10393]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
