基于SaaS的业务组件建模

软件即服务的业务流程建模

摘要

传统的业务流程建模方法经常导致难以修改和维护的大型模型。在基于云的环境中，业务动态要求业务流程通常能够更加响应变化。这就要求面向云的应用程序具备高度的模块化、可扩展性和灵活性。此外，在基于云的商业环境中，流程模型除了描述新功能外，还应定义这些功能如何与现有系统集成。本文提出了一种基于分层图的规范，称为基于SaaS的业务组件图（BCGS），以解决上述问题。所提出的BCGS形式化地实现了面向软件即服务（SaaS）应用程序的业务组件。BCGS将复杂的业务逻辑设计表示为一组业务组件及其相互关系。其中，业务组件被定义为业务流程与业务规则的系统性集成。这种提出的集成方法促进了业务组件构成元素的高可扩展性和可重用性，并确保了流程与业务规则之间的一致性。此外，本文还包含了所提出的概念在SaaS框架中的服务导向特性。文中通过一个详细的案例研究展示了BCGS所提出概念的表现力。

关键词 ：业务流程；业务组件；业务规则；云计算；软件即服务；SaaS；服务导向。

1 引言

软件即服务（SaaS）正从一种节约成本机制演变为推动增长的重要驱动力。因此，越来越多的组织正在转向基于云的服务。SaaS能够根据不断变化的市场状况快速扩展资源。与此同时，业务流程管理（BPM）（Catts和Clair，2009年）正成为基于服务的应用管理的蓝图。因此，尽管SaaS几乎在所有企业应用领域都已成为主要的软件交付模型，业务流程管理的重要性也在不断提升，成为当前首选的应用。

经济环境（Morimoto，2008a）。此外，业务流程管理使企业能够快速适应外部环境的巨大变化。软件即服务交付模型的内在成功以及业务流程管理促使研究人员思考将业务流程与基于SaaS的应用相结合的可能性，以实现对服务的更好管理和交付。

在软件即服务交付中，按需供应和快速弹性等模型特征（美国国家标准与技术研究院，2011年）使得应用程序能够非常迅速地部署和扩展。因此，基于SaaS的应用程序的运行环境可能快速变化，应当予以应对以适应不断重新评估的内外部能力。它还应能够启动新举措，以确保其操作的效率和有效性。然而，传统服务架构是以应用为中心的，这意味着为解决某一业务问题而设计的应用程序在未来难以应用于类似的问题（Holschke等，2010）。因此，流程保持相对静态，进而导致僵化且不可扩展的系统。这导致产生了一代仅适用于单一用途的应用程序，但当业务需求变化时难以修改（丁和刘，2008）。此外，业务流程在被称为业务规则的特定约束下实现特定的组织目标。在传统应用中，业务规则通过规定组件如何操作与业务相关的数据来定义工作流。但在云计算环境中，业务规则应能够处理由服务支持的租户特定的企业应用（王等，2010）。此外，租户的公共功能应由同一组业务规则进行管理，因此云环境中的业务规则应具备可重用性，以加快开发速度并实现易于管理（魏斯曼和博布罗斯基，2009）。

为了解决这些问题，有必要采用一种改进且高效的方法，以在软件即服务（SaaS）中融入可扩展性和灵活性，适应频繁的流程变更，并进而实现业务流程与服务之间的强关联。因此，基于服务的应用程序应系统化地从业务功能明确定义的业务流程中衍生出来。从应用角度来看，这将有助于采用以流程为中心的业务视角，并使软件与业务功能之间的关联更加容易（Polani等，2013）。业务流程、规则和服务将在启用这一转变过程中发挥重要作用。然而，从交付模型的角度来看，业务流程本身也必须演进（Benlian等，2009），以支持灵活且可扩展的业务服务。

现有的业务流程系统是封闭的集中式控制系统，仅用于执行组织的关键任务功能（戈亚尔和米基利内尼，2012年）。但在云生态系统中，商业环境将不断变化，因此快速建立协同业务流程的能力成为迫切需求。它还应能够将两个以上的协作方组合到一个配置中，以形成可扩展系统（Norta等，2014年）。然而，当前的BPM系统集合并不支持流程的这种动态性。它也无法利用现有流程创建新的服务通道，并将这些通道重新分配给那些仅在运行时才被知晓、且可能因实例而异的流程（戈亚尔和米基利内尼，2012年）。此外，云环境中的业务流程应具备灵活性。这里的灵活性是指通过仅修改需要变更的部分，来实现业务流程类型和实例变更的能力。可以进行更改，同时保持其他部分的稳定。但现有的业务流程建模技术和模型本质上是命令式的，它们严格描述了如何工作（巴特和德什穆克，2005）。因此，基于云的BPM系统应支持在流程模型内进行调整，甚至在运行时修改流程模型。此外，在云环境中，实现流程建模中的可重用性将非常有用，有助于降低设计新流程或重新设计现有流程时的高复杂度、时间消耗和错误（范登赫维尔和杠杆作用，2011）。因此，云基础BPM系统应由业务流程和规则的动态性、灵活性、可扩展性和可重用性等主要特性驱动。

本文提出了一种基于图的新方法——基于SaaS的业务组件图（BCGS），用于对基于云的业务流程的灵活性、可重用性和动态性进行建模。BCGS反映了表示业务组件组合的业务设计。在此，业务组件被定义为业务流程与业务规则的集成。这种集成方法提高了可扩展性，并确保了流程与规则之间的一致性。同时，它还支持基于SaaS的应用程序持续变化和演进。为了表示业务操作，提出了基于SaaS的业务流程图（BPGS），其满足云环境中业务流程建模与标注（BPMN）的结构与语义。

在此背景下，采用了广义业务规则依赖图（GBRDG）（Mandal等，2013，2014b）来表示业务规则。GBRDG利用图语义对适用于基于云应用的业务规则及其各个方面进行建模。因此，BCGS支持对基于云的业务流程功能方面的高层表示。此外，所提出的BCGS促进了基于云的业务流程中灵活、可重用和动态的业务组件组合，并为这类业务应用提供了一个一致表示。进一步地，本文还讨论了BCGS所提出概念在名为面向数据应用的灵活云架构（FCADCA）（曼达尔等人，2014a）的SaaS框架中的服务导向。在此背景下，FCADCA是一个针对SaaS的概念性架构框架，提供了以数据为中心的SaaS应用的主要功能，即可定制性、可扩展性和灵活性。

2 相关工作

多年来，许多研究工作致力于业务流程管理。一般来说，业务流程管理涉及现有业务流程的设计与捕获，以及新业务流程的分析（Morimoto，2008b）。在业务流程设计方面，大多数文献集中在管理业务流程模型的复杂性（Holschke等，2010；丁和刘，2008；Polani等，2013），将用户访问纳入结构化业务流程（Caetano等，2005；Badica和Badica，2011），临时业务流程管理（Lakshmanan等，2011；Wombacher和Mahleko，2003），以及业务流程与业务目标的对齐（Walraven等，2014）。针对这些需求，已提出多种语言用于建模业务流程（List和Korherr，2006）。其中，BPMN（Owen和Raj，2003）被视为工业和学术界中业务流程的事实上的建模表示标准。

在此过程中，由于需要描述业务流程的结构和行为，用于业务流程建模的语言的形式化定义成为业务流程管理（BPM）中的关键步骤。Yamasathien和Vatanawood，2014提出了一种从给定的BPMN工作流模式构建业务流程模型形式化模型的方法。Yuan等（2010）和张和王（2007）提出了一种基于π演算的业务流程执行语义形式化的严谨方法。但这类方法的一个主要缺点是流程的通信能力是静态的（Aguilar‐Saven，2004）。而Amziani等（2013）和Klai和Tata（2013）提出了一个基于Petri网的形式化模型，用于云中基于服务的业务流程的弹性。该模型表明，在服务被复制或合并时，所提出的模型能够保持基于服务的流程的语义。然而，使用Petri网进行业务流程建模存在两个严重缺点：首先，即使在中等规模系统的情况下，Petri网的表示也会变得非常庞大且复杂；其次，Petri网缺乏支持系统组件间层次结构的语义。

Koubarakis和Plexousakis（2002）提出了一种使用结构化图语法进行业务流程工程的形式化模型。然而，图重写规则无法为占位符提供丰富的语义，并且在大多数情况下也不支持结构递归（Hoffmann等，2008）。因此，使用基于Petri网和图语法的模型来表达可重用性、封装等特性变得相当困难。此外，文献中还研究了其他一些方法：Armando等（2012）提出了一种基于动作语言C的框架，用于在授权约束下对业务流程进行形式化规约和自动推理；Markovic和Pereira（2008）提出了一种表达性强的形式体系，用于描述业务流程模型以支持业务流程建模中的重用；Varosyan（2011）提出了一个基于对IT基础架构库（ITIL）和微软操作框架（MOF）库分析的业务流程模板的形式化定义；Koubarakis和Plexousakis（2001）提出了一种用于表示企业知识的形式化框架。但这些文献仅提供了支持业务流程特定特性的孤立解决方案。因此，由于局限于业务流程设计，这些方案本身无法实现业务流程的可扩展且灵活的端到端管理。

根据高德纳（2012年）的预测，到2016年，20%的所有影子业务流程将由基于云的业务流程服务。高德纳（2012）指出，所有由IT部门支持的隐藏组织流程作为传统业务流程的一部分，也可以被工作流软件等技术所取代。近年来，许多研究致力于基于云的业务流程。埃伦霍费尔和克鲁泽（2012）概述了新型商业模式中服务创新日益增长的挑战与前景，以及服务创新与业务发展流程之间的关系。威布利（2012）讨论了选择基于云的BPM平台所带来的业务优势，以及BPM在整体云架构中的位置。杜普曼斯（2012）提出了一种分布式解决方案，将一个业务流程拆分为多个独立的业务流程，分别在云环境和本地部署环境中执行。在此方法中，通过在分发列表指导下对原始业务流程进行转换，生成适用于本地和云环境的业务流程，该分发列表定义了每个活动和数据元素的部署位置。维内齐安·波沃阿等人（2013）设计了转换机制，将用WS‐BPEL表示的业务流程分解为可在用户本地环境和云中部署的子流程。达马森诺等人（2011）开发了一个名为SSC4Cloud的基于云的模型驱动开发与执行环境，以提供共享业务流程建模工作区和业务流程执行环境。范德阿尔斯特（2011）讨论了与业务流程配置相关的挑战和机遇，并提出因果网（C‐网）作为一种新的形式化方法来应对这些挑战。在万和余（2011）的研究中，提出了一种主谓宾状复合业务流程描述元模型，能够表示业务流程描述问题空间中的静态关系。刘等人（2012）提出了一个BPM平台，帮助业务分析师在混合云环境中高效地设计、实现、部署和执行业务流程。

罗宾逊等人（2012）提出一种方法，以降低分析在云环境中运行的业务流程工作流的难度。Amziani等（2013）提出了一种用于云中基于服务的流程弹性的形式化模型。他们证明了所提出的模型在服务被复制或合并时仍能保持基于服务的流程的语义。甘比和波塔索（2013）以及贝萨伊等人（2013）提出了在云环境中对业务流程实例进行匹配与调度的新战略。然而，现有文献仅从工作流管理视角提供了业务流程的单一维度视图。

但对于云应用而言，业务流程应定义为具有清晰可区分的操作，并且应具备高度响应性以适应新能力（曼达尔等人，2014a）。除了促进新能力外，业务流程还应能够应对这些能力在完全基于服务的系统中如何处理变化的问题。随着越来越多的业务流程迁移到云，有必要解决与其状态相关的问题，并为关键问题提供支持可扩展性、灵活性、动态性和可重用性等特征。

此外，从管理的角度来看，在多个流程集合中应用一致的策略变得困难。策略的变更将需要对每个流程进行重新开发。业务规则系统能够反映这些业务政策、目标或战略。业务规则通常由一系列声明性语句和约束组成，可用于决定特定的动作或目标（IBM，2012年）。因此，对于云应用而言，需要业务规则（业务规则组，2000年）来实现业务策略的自动化，消除手动逻辑插入，并降低维护成本。然而，易于配置的业务规则集仍然是当今基于云的商业应用的主要支柱。目前大多数业务规则表示方法缺乏适当的建模技术支持。多数传统方法扩展了现有的标准软件工程概念，如决策表（Auechaikul和Vatanawood，2007年）、实体关系图（ERD）（Loucopoulos和Katsouli，1992年）、统一建模语言（UML）（Vasilecas和Lebedysa，2005年）等，通过XML实现业务规则的表示。这些方法适用于处理业务规则的结构方面。然而，这些模型并未定义业务规则的动态方面。因此，这些表示模型不适用于云应用。程亮和金文（2009年）讨论了业务规则在创建灵活应用中的重要性。应等人（2010年）研究了针对支持多租户的SaaS应用程序中基于Web服务的业务流程的建模方法。在王等人（2010年）的研究中，提出了一种面向策略的方面化业务框架模型。在此模型中，多个客户可以将其业务规则插入到BPEL业务流程中。

在莫兰等人（2011年）的研究中，描述了一种规则语言的选择以及在云环境中包含和使用所选规则语言的示例用例。但这些文献主要关注业务规则在云环境中的效用，而非其表示问题。此外，云环境中多租户应用数量的不断增加，使得整合和重用现有业务规则集的需求日益增长。因此，业务规则的逻辑模型应支持这些规则在不同平台和组织边界之间的重用与共享。

除了这些之外，仅有少数文献讨论了在云环境中结合业务流程与业务规则的重要性与挑战。

Papazoglou和van den Heuvel（2007年）调研了面向服务架构（SOA）的基础，评估了作为业务集成推动者的方
法论，并提供了一个灵活且可适应的环境。他们还开发并探讨了对传统SOA的一种扩展，称为扩展型SOA（xSOA）。Muehlen和Indulska（2010）通过关注业务规则与业务流程之间的最大本体完备性和最小本体重叠性，研究了在基于BPMN的业务流程中使用不同的业务规则的适用性。

流程。然而，该方向的大部分工作基于使用业务规则进行服务的基于工作流的组合（Shi et al., 2009；Charfi和Mezini, 2004；Hoang和Nguyen, 2009；Petcu和Stankovski, 2012）。部分研究文献提出了一个框架及相关技术，用于在分布式环境中半自动化地实现业务流程（Han et al., 2007）。而张等人（2009）提出了一种业务规则处理模型（BRPM），主要包含针对多租户SaaS应用的规则定制、规则存储和规则执行。米兰诺维奇等人（2008）通过采用模型驱动工程的原理，以新增网关类型的形式将规则作为建模概念加入，从而扩展了BPMN。但这些方法中的业务规则主要关注服务组合方面，且不支持相同业务流程的用户特定配置。因此，难以实现业务流程与业务规则在适应性、灵活性、可扩展性等方面的显著潜力。

在帕帕佐格卢（2012）中，提出了一种分层架构模型，有助于避免部署无控制的服务迷宫的陷阱，并为服务启用提供了坚实的基础，从而使Web服务能够在基于SOA的业务应用中高效使用。该模型包含六个主要抽象层，分别是领域、业务流程、业务服务、基础设施服务、服务实现和操作系统。对该模型的分析强调了如何将现有的企业资产转化为业务服务，以及业务服务又如何组合成业务流程（帕帕佐格卢，2007年）。因此，服务被纳入业务流程的任务中，且有限的业务政策定义了组合模式。这样，服务可以在流程之间重用。这些有限的业务政策仅从提供者角度定义了服务之间的工作流。然而，通过此类策略难以实现消费者特定配置。因此，在很大程度上影响了面向服务架构（SOA）以及业务流程框架中的灵活性和可扩展性特性。

因此，大多数现有方法仅概述了在云上提供业务操作所面临的挑战和前景。其中只有少数讨论了与云环境中的业务流程管理相关的问题。但是，这些工作流模型需要遵循各种规则，并应具备高度的灵活性。此外，文献中研究的业务规则和业务流程建模技术的主要局限性在于，它们仅为决策提供了有限的框架。然而，最大的挑战是将服务与组织的业务目标相集成，并在云环境中支持组织的不同业务线。因此，在云环境中为业务流程构建高效的服务导向机制，以及保持业务实体的粒度方面，也是主要挑战。再次，近年来研究表明，业务流程与服务的混合方法成为一种主导实践。但它们仅仅解决了基于云的业务流程在灵活性、动态性和可重用性方面的主要技术挑战。

因此，仅采用面向服务的范式还不足以满足云环境中业务流程的需求，还应促进服务与组织业务结构在不同层次上的集成，并且需要一个高效的SaaS架构框架来提供支持。该架构框架应支持对业务实体进行分类和编目，促进不同层次的软件复用，并缓解互操作性挑战。为解决这些问题，考虑了一种称为面向数据为中心应用的灵活云架构（FCADCA）（曼达尔等人，2014a）的概念化云架构框架。

3 面向数据密集型应用程序的灵活云架构

称为FCADCA的概念性架构框架是基于SaaS的主要功能（如可定制性、可扩展性和灵活性）而设计的。除此之外，该架构还能够支持以数据为中心的云应用在异构数据集上的实现。如图1所示，FCADCA采用四层结构设计。

1. Application layer ：这是最外层，直接与用户交互。它负责提供服务并管理服务配置。
2. Service management layer ：它负责根据请求者的需求向其提供服务。在此，多个功能模块被组合在一起以定义一项服务。通过定义字段、公式以及服务之间的工作流，可以实现应用的定制。
3. 业务层 ：该层由多个业务组件和一组作用于服务及其组件的业务规则组成。通过这种框架，设计者能够实现面向业务的服务分组，而无需依赖用于定义这些服务的功能模块。因此，由于业务组件与业务规则相互分离，业务层的变更可以更容易地被适应。
4. 数据层 ：在此架构框架中，数据层分为两个子层，即元数据管理子层和数据管理子层。元数据管理层充当业务层与数据管理层之间的桥梁。根据数据类型的不同，元数据可分为用户数据、应用数据、服务数据和事件数据。云中的数据具有高度动态演化的特性。

FCADCA框架通过使用结构化数据库、半结构化数据库或非结构化数据库等不同的数据库服务，支持大规模业务数据的异构表示与存储。

在FCADCA中，每一层都包含一个“接口”，该接口提供不同层之间的交互方式，并支持信息交换。信息交换可以是消息，这些消息遵循可引用交换模式以及指定信息模型的结构与语义。接口还提供了一道屏障，使得应用逻辑的变更不会影响到接口的使用者。此外，每一层的接口由两个子接口组成：一个与前一层的接口进行交互，称为α − interface；另一个与下一层的接口进行交互，称为β − interface。接口由多个接入点组成，这些接入点提供对应用程序所暴露功能的访问。一个接口的接入点可以在不同层之间与另一个接口的一个以上接入点进行交互。接入点会根据其可用性以及服务或服务组件的类型，为特定的服务或服务组件动态选择。因此，可以实现针对特定服务组合的动态添加或删除服务组件。

4 SaaS应用程序业务组件的形式化表示

在FCADCA中，业务层由多个业务组件组成。业务组件被定义为可能完全可自动化的业务流程。这些组件构成应用程序，并表示为包含在其中的一组业务操作，用于描述业务如何承诺并执行其工作。然而，简单的过程式业务流程存在一个问题：随着组织试图捕获与业务领域相关的所有逻辑，这些流程可能变得极为复杂。此外，从管理角度来看，很难在一系列流程中应用一致的策略。策略的变更将需要对每个流程进行重新开发。业务规则系统能够反映这些超越性的业务政策、目标或战略。因此，在FCADCA中，业务流程和业务规则被视为不同的机制，可以在业务组件中动态集成。这种业务流程与业务规则的集成方法提高了云应用的灵活性。然而，为了实现开发能力的快速演进，流程的显式表示被认为是必要的。非正式流程描述结构不够清晰，导致信息检索困难。通过采用形式化的流程描述方法，可以确保流程描述的一致性、无歧义性和完整性。因此，在本节中，业务流程和业务规则被分别建模，而业务组件则作为业务流程和业务规则的封装器。

4.1 软件即服务的业务流程建模

业务流程是一组与特定客户请求相关的活动或任务，旨在实现特定目标。它通常被可视化为一系列活动，并交织着决策点。通过将输入转化为更具价值的输出，这些相互关联的活动创造了价值。在此过程中，由于需要描述业务流程的结构和行为，用于建模业务流程的语言的形式化定义是业务流程管理中的关键步骤。在云环境中，业务流程需要明确流程活动执行的顺序和条件（控制流）以及活动之间的数据交换（数据流）。然而，现有研究仅提供了支持业务流程生命周期各阶段的孤立的解决方案。由于局限于业务流程设计，这些方案本身无法实现灵活的端到端管理，尤其是在云环境中。此外，与其他业务流程生命周期阶段的解决方案集成也存在问题。为解决这些问题，本文讨论了一种表示业务流程的形式化方法。该方法通过一种称为BPGS的图结构来表示，其定义如下：

$$
BPGS: G_p = \langle N_p, E_p, L_p \rangle
$$

BPGS中的每个节点（Np）都关联一个标识（id）、业务功能（fun）和业务事实（business facts），这些业务事实表示业务流程中的单个业务上下文。因此，BPGS中的一个节点可以表示为，

$$
N_p = \langle id, businessfacts, fun \rangle
$$

边（Ep）表示业务流程图中节点的流程执行。业务流程图的边是一个集合，可以表示为，

$$
E_p = { N_{pi} \times N_{pj} }
$$

BPGS中的节点（Np）可能属于不同类型的节点，它可以表示一个活动（a）、事件（ev）、网关（g），甚至是一个工件（ar）。因此，节点类型可以被视为一个函数，并可被形式化定义为。

$$
type: N_p \rightarrow {a, ev, g, ar}
$$

在BPGS中，Lp 是表示执行顺序O={0,1,2,…,n}的边上的标注函数。这里，O{0}表示边之间没有顺序。因此，Lp 可以表示为：

$$
L_p: E_p \rightarrow O
$$

在业务流程建模范式中，BPMN是一个广泛接受的标准，具有明确定义的语法和足够清晰的语义。但BPMN的语法和语义是通过半正式方法定义的（Capel‐Tunon, 2009）。因此，本文提出的图模型为BPMN定义了形式化语法和语义，以提高其在云环境中的适用性。以下形式化分析表明，BPGS遵循BPMN的结构与语义。

4.1.1 业务上下文级别分析

如前所述，BPGS中的节点（Np）通常可以是不同类型，其中活动节点恰好有一个输入和一个输出，因此

$$
\forall a \in N_p: fanin(a) = 1 \land fanout(a) = 1
$$

这里，fanin()和fanout()是标准的软件工程度量（扇入和扇出），用于确定影响节点的总输入边和输出边。

在BPGS中，event类型的节点大致可分为三类：开始事件（evstart）、中间事件（evintermediate）和结束事件（evend）。

$$
ev = ev_{start} \cup ev_{intermediate} \cup ev_{end}
$$

$$
\forall ev_{start} \in N_p: fanin(ev_{start}) = 0 \land fanout(ev_{start}) = 1
$$

$$
\forall ev_{intermediate} \in N_p: fanin(ev_{intermediate}) = 1 \land fanout(ev_{intermediate}) = 1
$$

$$
\forall ev_{end} \in N_p: fanin(ev_{end}) = 1 \land fanout(ev_{end}) = 0
$$

此外，在BPGS中，gateway类型的节点用于控制业务流程中的顺序流。它们用于在流程图中实现顺序流的分流和汇聚。

$$
\forall g \in N_p: (fanin(g) = 1 \land fanout(g) > 1) \lor (fanin(g) > 1 \land fanout(g) = 1)
$$

再次，根据决策机制，网关可以进一步分为三类：互斥网关(gex)、包容网关(gin)和并行网关(gpri)。

因此，$$
g = g_{ex} \cup g_{in} \cup g_{pri}
$$

其中

$$
\forall g_{ex} \in N_p: fanout(g_{ex}) = 1
$$

$$
\forall g_{in} \in N_p: fanout(g_{in}) > 1 \land fanout(g_{in}) < fanout(g_{in})
$$

$$
\forall g_{pri} \in N_p: fanout(g_{pri}) = fanout(g_{pri})
$$

这里，fanout(Np)t 表示在实例’t’时刻，网关条件评估后影响节点Np的活跃输出路径的总数。

4.1.2 业务流级别分析

BPGS的边（Ep）有三种类型：顺序边（Eps）、消息边（Epm）和关联边（Epa）。

$$
E_p = E_{ps} \cup E_{pm} \cup E_{pa}
$$

序列边用于表示在流程中活动、事件或网关条件的执行顺序。因此，如果Np1和Np2是业务流程图Gp的节点，则

$$
E_{ps} = { N_{p1} \times N_{p2} }
$$

其中 $$ type(N_{p1}), type(N_{p2}) \in {a, ev, g} $$

消息边用于显示两个节点之间的消息流。它存在于两个不同流程的事件、活动或网关之间。因此，如果Npx 和 Npy 是两个不同业务流程Gpx 和Gpy 的节点，则

$$
E_{pm} = { N_{px} \times N_{py} }
$$

其中 $$ type(N_{px}), type(N_{py}) \in {a, ev, g} $$

此外，在BPGS中，使用关联边将外部要素与活动事件或网关相关联。因此，如果Np1和Np2是业务流程图Gp的节点，则

$$
E_{pa} = { N_{p1} \times N_{p2} }
$$

其中 $$ type(N_{p1}) \in {a, ev, g} $$ and $$ type(N_{p2}) = ar $$

4.2 面向数据为中心的云应用的业务规则建模

为了保持竞争力，组织需要不断改变和改进支持业务操作的系统。如前所述，大多数业务规则表示方法是集中的，并且缺乏适当的建模技术支撑。这些方法大多扩展了现有的标准软件工程概念，适用于描述业务规则的结构方面，但无法用这些模型描述其动态方面。为解决这些问题，在此考虑使用GBRDG（Mandal等，2013）来表示业务规则。GBRDG是一种与定义规则所用语言无关的业务规则抽象表示。此外，GBRDG能够对业务规则之间的组合和依赖关系进行建模，其中语义具有可重用性。除了支持业务规则系统的分析与设计外，GBRDG还能够在云环境中基于跨业务场景对业务规则集进行划分。

业务规则的通用概念模型定义了其组件及其结构，用于对策略、事实、动作语句和推导进行概念化。每条业务规则都应关联一个结构断言（SA）以及一个动作断言或推导。SA是对概念的定义或事实的陈述，涵盖企业结构的某些方面。当SA描述可能性时，动作断言则施加约束。推导是从其他语句中得出的知识陈述。

GBRDG是一个有向无环图，其表达形式为，

$$
GBRDG: G_r = \langle N_s \cup N_c, E_c \cup E_d, L_r \rangle
$$

简单规则用Ns表示，它由一个原子SA组成，并可能包含一个动作断言。复合规则或复杂规则用Nc表示，由多个简单规则或简单规则与其他复合规则的任意组合构成。

此外，根据事实的特征，在云环境中的业务规则的简单规则语句可 broadly 分为行为规则（Nbr）、服务规则（Nsr）和数据规则（Ndr）。因此，通常情况下，GBRDG中的节点Nr定义为，

$$
N_r = N_c \cup N_d
$$

其中

$$
N_r = { x | x \in N_s \lor x \in N_{br} \lor x \in N_{sr} \lor x \in N_{dr} }
$$

and

$$
N_c = { x | x \subseteq P(N_s), x \neq \emptyset }
$$

GBRDG中的边Er也由两个不相交的集合组成，分别称为控制边Ec和依赖边Ed。其中，控制边定义了执行特定业务规则所需的业务规则及其关联关系。当某个业务规则在特定上下文中被细化为更详细的规则时，则认为存在依赖边。形式上，控制边可表示为(x × y) ∈ Ec，其中 x,y ∈ Nr ，且由y表示的业务规则将在由x表示的业务规则实例化后立即实例化。另一方面，依赖边也表示为(mr × nr) ∈ Ed，其中rrm ∈ N′ 且nr ∈ Nr，此处rrN ∈ N′，仅与从其他规则派生出的业务规则保持一致。这里，由m表示的业务规则被由nr表示的业务规则所引用。因此，GBRDG中的边Er

$$
E_r = E_c \cup E_d = { (x \times y) | x,y \in N_s \cup N_c \cup N_d }
$$

在GBRDG中，Lr是控制边上的层级，表示组合类型。可以通过对现有业务规则集合使用AND、OR、XOR或这些操作的任意组合来构成新的业务规则。标签1超过边表示AND类型的组合，标签0表示OR类型的组合，而X表示XOR类型的组合。在GBRDG中，复合规则的构建遵循从左到右的顺序。GBRDG的构造算法列于算法1中。

Algorithm 1 GBRDG创建算法

业务规则	广义业务规则依赖图
1: 识别业务规则使用的术语
2: 如果业务规则是术语的定义，则∨由原子组成结构断言 then
3: 创建一个简单的业务规则节点 SR
4: if 业务规则 x 使用的术语/事实引用了另一个业务规则 y then
5: 如果实例化 x 需要实例化 y 那么
6: 创建一个复合业务规则节点 CR
7: 通过控制边将 x 和 y 相关联 ec
8: 如果 CR 由多个现有的业务规则组成 then
9: 如果 CR 的实例化需要所有其他规则的实例化则
10: 设置标签为 ec ← 1
11: 如果 CR 的实例化需要多个其他规则的实例化则
12: 集合标签的 ec ← 0
13: if 实例化 CR 仅需要实例化一个其他规则 then
14: 集合ec ← X的标签
15: if 业务规则 x 源自 业务规则y then
16：创建一个复合业务规则节点
17：通过依赖边 x 将 y 与 ed 相关联

4.3 面向数据为中心的云应用的业务组件建模

业务设计体现在构成企业的业务组件的组合中，并通过这些组件所包含的业务操作来表达，这些操作描述了企业如何承诺并执行其工作。这包括：所采用的业务规则、承诺的数据资源以及用于实现其目标的信息。因此，业务组件被定义为应用中的一个自组织且边界清晰的逻辑单元。

BCGS是业务组件的抽象表示。BCGS是一个有向层次图，其中每个节点（Nbc）表示一个业务组件，边Ebc 和Ec 表示图的组成元素之间的关联和包含关系。而L是边上的标注函数。形式上，BCGS可以表示为，

$$
BCGS: G_{bc} = \langle N_{bc}, E_{bc}, E_c, L_{bc}, l_r \rangle
$$

一个业务组件节点（Nbc）由表示为BPGS的业务流程节点（Gp）和表示为GBRDG的业务规则节点（Gr）组成。在一个业务组件中，业务流程及其相关的业务规则共享某些共同的业务上下文。因此，一个业务组件节点可以被定义为，

$$
N_{bc} = \langle G_p, G_r \rangle
$$

其中 $$ G_p \neq \phi $$ and $$ 1 G_p = $$

此外，一个业务组件也可以由多个其他现有的业务组件组成。

因此，

$$
N_{bc} = N_{bc1} \cup N_{bc2} \cup \ldots \cup N_{bcn}
$$

如前所述，BCGS中的边有两种类型，其中association edge存在于业务组件之间，其定义为

$$
E_{bc} = N_{bc} \times N_{bc}
$$

而组件与其包含的业务流程节点或业务规则节点之间存在包含边Ec 。因此，包含边可以定义为，

$$
E_c = E_{bp} \cup E_{br}
$$

其中Ebp表示存在于业务流程与业务组件之间的业务流程边，

$$
E_{bp} = N_{bc} \

5 使用案例研究说明BCGS

当今的基于云的商业场景要求业务流程对变化具有越来越强的响应性。因此，基于云的业务流程模型必须具备模块化、可扩展性和灵活性，这不仅有助于提高建模敏捷性，还能增强执行流程的健壮性和弹性。提出的BCGS能够满足这些需求，为了使用BCGS说明这些概念，本文考虑了一个healthcare system的简单案例研究。该医疗系统包含多个业务流程和规则（表1）。业务流程采用BPGS的语法和语义进行建模，而业务规则则使用GBRDG进行建模。这些流程和规则通过BCGS的概念封装成一个组件，并映射到服务上。

如前所述，一个业务组件由业务规则和可能完全可自动化的业务流程组成。为了说明包含业务规则和流程的组件概念，此处考虑护理计划组件（bc5）。该组件由护理计划流程（P5）和医疗保险政策（R4）构成。如前所述，BPGS图遵循BPMN的结构与语义，因此BPMN流程图可被视为BPGS图。图3描述了护理计划流程。在此流程中，收到报销申请后，首先确定雇佣类型信息；然后检查治疗类型，若为日间护理服务，则仅在此情况下报销申请才会被批准；如果医院是网络医院，则可提供即时结算服务。每当一个组件被实例化时，其关联流程就会被调用，进而调用与之相关的业务规则。此处的规则使用GBRDG进行建模。

与医疗保险相关的业务规则可以使用GBRDG的概念和结构来说明。每条医疗保险政策（R4）的规则被视为GBRDG中的一个节点，边表示这些规则之间的控制流和依赖关系。以下是关于医疗保险的一些简化业务规则。其中，带下划线的词语表示事实或术语，斜体词语表示约束或动作。

• BR1 医疗理赔服务仅适用于在组织直接薪酬体系中的员工。
• BR2 住院时间不超过24小时的日间护理治疗可享受报销。
• BR3 日间护理服务适用于眼科手术、透析等情况。门诊部服务不包含在日间护理服务范围内。
• BR4 救护车费用可在网络医院和非网络医院提供报销，最高报销金额为1,000卢比。
• BR5 每位员工家庭综合保险的最低保险金额为40万卢比，包含生育和职位类别。
• BR6 网络医院的日间护理费用报销额度为保险金额的10%，并提供免付现金服务。
• BR7 非网络医院的日间护理费用报销额度为保险金额的7%，且为非免付现金服务。
• BR8 医疗理赔策略在收到理赔申请后，对因疾病或病症产生的费用进行报销。该报销可以是免付现金或非免付现金形式。

GBRDG是使用第4.2节中指定的算法生成的。其中，BR1用于检查员工类型，而BR2和BR3与确定治疗类型活动相关。这些规则是原子规则，因为它们不依赖于给定规则集中的其他规则。而BR4和BR5适用于计算报销费用活动。保险金额根据职位类别而变化，且职位类别在BR1中定义，因此BR5是一个复杂规则，并且它还依赖于BR1。因此，在BR1和BR5之间添加了控制流和依赖边。类似地，对于BR6、BR7和BR8，遵循算法中规定的步骤，所考虑规则集的GBRDG图如图4所示。

护理计划流程和医疗保险政策被封装以形成护理计划组件（bc5）。然而，如前所述，医疗系统由多个其他业务流程和规则组成，这些构成了其他组件。各组件及其对应的流程和关联规则如表1所示。这些组件可用于构建更高级的抽象业务组件。在此示例中，使用这些组件组合形成了两个复合业务组件：一个用于门诊部（OPD）（BC1），另一个用于日间护理单元（BC2）组件。这些组件的BCGS如图5所示。

在此示例中，门诊部（BC1）的运作分解如下：一旦预约与咨询流程（bc1）完成，临床文档流程（bc2）负责管理患者信息，而门诊临床支持组件（bc3）则负责提供顾问建议所需的医疗设施。治疗流程完成后，所产生的费用可由护理计划（bc4）组件进行报销。同样，对于日间护理组件（BC2），一旦诊断（bc6）完成，即启动医疗治疗流程（bc7），随后遵循日间护理临床支持流程（bc4）以及临床文档管理（bc2）。此处产生的费用也可由护理计划组件（bc5）报销。在此示例中，护理计划组件（bc5）被门诊部（BC1）和日间护理（BC2）组件共享，且未作任何更改。然而，临床文档组件（bc2）也在两者之间共享，但BC1和BC2在临床文档流程中所使用的规则不同。此外，规则（R3）被门诊临床支持（bc3）和日间护理临床支持组件（bc4）共同使用。

为了说明BCGS的建模语义，此处以OPD组件（BC1）的工作流程为例需要考虑。在此流程中，首先将OPD组件（BC1）的状态初始化为0。因此，S(NBC1)={0}。当BC1变为可操作时，其关联的业务组件将根据连接关联边上的标签进行初始化。具有最小整数编号的标签将首先被初始化。此处，连接到预约与咨询过程（bc1）组件的关联边上的标签（Lbc(BC1 × bc1)）最小，因此bc1业务组件的状态变更为0，即S(Nbc1)={0}。在业务组件启动时，其相关的业务规则也会被启用。因此，1 1 = Gr N。然后，规则图R1的节点将与流程图Gp1的适当节点进行映射。在bc1组件完成后，该组件的状态变更为1，S(Nbc1)={1}。一旦处于该状态，将进一步启用bc2、bc3和bc5业务组件，因为Lbc(BC1 × bc1) < Lbc(BC1 × bc2) < Lbc(BC1 × bc3) < Lbc(BC1 × bc5)。此过程将持续遵循BCGS建模语义，直到所有相关组件均完成。在完成后，OPD组件的状态变更为1，即S(NBC1)={1}。随后，终止条件成立，流程终止。

然而，可能需要对OPD组件进行升级，以包含高质量参数的日间护理流程临床支持以及额外的业务规则集合。根据第4.3节中定义的BCGS可扩展性操作的建模语义，这可以通过两种方式实现：

1. 通过将现有的日间护理临床支持组件（bc4）连同额外的业务规则集合复用到业务组件BC1。
2. 也可以通过创建一个新的组件来实现，通过重用业务组件4所使用的相同业务流程（p4）和业务规则（R3），以及根据需求新增的业务规则集合（R3′），来实现业务组件4′。这个新创建的组件随后被添加到BC1组件中，并分配相应的标签（order），以形成扩展的业务组件。

6 BCGS的属性

基于云环境中业务流程的特征以及BCGS的形式化定义，可以得出若干有趣的属性，用于描述基于云的业务流程的上下文和流程标签分解以及业务组件组合的不同方面。这些属性如下：

6.1 动态性

在云环境中，动态业务组件使业务流程能够快速适应不断变化的业务需求。在此，流程被设计为高度可适应，允许参与者在运行时进行快速的流程调整。

1. 业务组件的动态组合
   对于基于云的商业应用，在运行时组合功能/非功能需求已成为处理业务流程和规则集成与重用的普遍方式。在BCGS中，业务组件可以在运行时进行组合。在此示例（图3）中，门诊部（NBC1）使用临床文档（Nbc2）并遵循规则GR2，但当其与日间护理组件（NBC2）一起使用时，组件Nbc2的组合会发生变化。在日间护理的情况下，使用规则集R2 G′。因此，对于组件Nbc2，采用（= ），而对于组件NBC1，则采用2 2 2 ( )，bc p RN G G′ =< >。因此，可以根据使用者需求通过更改业务规则集来改变业务流程的行为。

2. 业务组件中的动态性
   业务流程应支持根据业务需求变更业务活动的顺序或切换到替代路径。但对于传统业务流程而言，实现这一点较为困难，因为它必须对每个备选方案进行单独评估，这反过来降低了流程的效率。在提出的方案中，业务规则通过根据业务约束实现运行时决策，改善了这一情况。为了说明组件内的动态性概念，此处考虑一个简单的诊断和治疗过程（图6）。在此过程中，患者到达急诊接待区或医生诊室并提出问题。医疗人员在收集健康信息后，需要执行一个或多个诊断流程。一旦明确了问题，医疗人员便可制定并执行相应的治疗流程。在此业务流程中，将为每位患者创建一个实例。然而，该流程存在的问题是，当患者前来寻求帮助时，医疗人员无法立即识别出医疗机构或医师可能面临的成千上万个问题。一种常见的解决方案是建立问题层次结构，并使用基于键的方式通过一系列决策进行诊断。但构建和维护这种基于键的分层业务流程将极为复杂。更高效的解决方案是利用业务规则在运行时进行决策。在BCGS中，业务组件由业务流程及应用于该流程的业务规则组成，从而实现业务流程的动态性。

6.2 对临时业务流程的支持

在BCGS中，可以动态组合新的业务组件，或者修改现有组件以创建新组件。这些修改可以通过更改流程或更改规则来实现。此外，在BCGS中，组件之间是松散耦合的，因此在一个组件中所做的更改对其他组件的影响最小。因此，BCGS支持高度可适应的流程设计。但BCGS并不直接支持可重构业务流程。此外，流程模型的形式化描述以流程图的形式提供，并且执行不一定由中心实体控制，因此有可能适应流程活动中的变化。

6.3 多渠道可访问性

通常，业务流程的变化频率远低于其访问所通过的交付渠道。业务流程代表运营功能，而客户端访问渠道基于新技术，这些技术对于基于云的应用而言往往更频繁地发生变化。在BCGS中，借助组件初始化，可以为每个渠道创建独立的流程实例。此外，根据渠道的特性，还可以为不同的交付渠道使用不同的业务规则。因此，在BCGS中，业务流程与规则的结合能够实现更有效的多渠道操作，确保交付一致的客户体验，无论采用何种访问机制。

6.4 分析能力

对流程的分析主要关注已完成流程的行为、当前正在运行的流程实例的评估，甚至预测未来流程实例的行为。BCGS能够提供有关流程、时效性及其与数据源关联的基本信息，因此可为业务分析提供指导。此外，BCGS所表示的组件组合中也清晰地展示了流程的依赖关系。进一步地，BCGS建模语义通过诸如创建、启动等操作符得到增强，但尚未给出形式良好的执行语义。因此，其分析能力仅得到部分支持。

6.5 灵活性

BCGS通过使用业务规则，为软件即服务中的流程与服务的动态组合提供了一种灵活的治理方式。在典型实现中，业务规则用于检查流经特定节点或流程中某个位置（称为可变点）的数据，并做出决定以确定流程的下一步路径。业务规则使得组织策略以及与这些策略相关的运营决策能够独立于核心应用进行定义、部署、监控和维护。通过将业务规则外置，云应用消费者可以定义和维护指导系统行为的决策，从而减少更新系统所需的时间和精力，并增强组织应对商业环境变化的能力。

此外，BCGS的每个业务组件都包含一些业务事实，这些业务事实表示业务流程中的单个业务上下文。这些业务事实可以根据需求或商业环境的变化进行调整。但是，这些更改不会影响使用BCGS的整体组件组合。由于每个业务组件都有其自身的业务目标，并且彼此相互独立，因此一个组件的变更对其他组件的影响最小。

此外，应用的灵活性与其包含的可变点数量成正比。BCGS支持由业务规则驱动的业务流程，其中业务规则通过GBRDG表示，GBRDG专为便于业务规则本身的变更而设计。除此之外，该组件本身的设计方式使其共享流程和规则所共同使用的对象与数据模型。这也有助于业务规则甚至数据模型的变更能够被轻松集成。因此，使用BCGS可以根据商业环境的变化快速地进行调整，这对于SaaS应用程序至关重要。

6.6 业务流程和业务规则的可重用性

重用是提升云环境中业务效率的关键推动力。传统的业务建模方法常常导致难以修改和维护的大型模型。由于这些模型体积庞大，因此不适合云环境。一个能够说明业务组件可重用性的典型场景是云服务提供商提供医疗理赔处理服务的情况。在传统方式下，每当收到新的服务请求时，服务提供商都必须创建一个独立的流程组件，从而导致流程库变得非常庞大。该问题可通过使用BCGS得以解决，BCGS支持组件的重用。在此，一个组件及其关联流程和规则可以被重用，以组合出具有不同流程目标的其他组件。在BCGS中，可重用性可以通过多种方式实现：

1. 重用整个业务组件
2. 使用不同的业务规则重用业务组件
3. 将业务规则用于不同的业务流程

在所考虑的医疗场景（图3）中，护理计划（Nbc5）组件被门诊部（NBC1）和日间护理（NBC2）组件共同使用，且未改变规则，因为通常情况下，对于特定的医疗中心，各单元的报销流程保持一致。但门诊部中的临床支持流程（Nbc3）和日间护理中的临床支持流程（Nbc4）可能不同。然而，临床支持的规则将保持相同（GR3）。因此，在此情况下，该规则被两个不同的组件共享。此外，在临床文档管理（Nbc2）方面，门诊部和日间护理的文档管理流程保持一致，但数据存储的规则可能不同。因此，此处临床文档组件在不同规则下被重用。

6.7 可扩展性

可扩展性是指系统将两个以上的协作方组合成一个配置的能力（Norta等，2014年）。在所提出的方法论中，可扩展性或弹性特性表现为：当业务组件实例增加时能力提升，或当业务组件实例减少时能力下降。所提出的BCGS通过多种方式实现可扩展性：

1. 在提出的方案中，业务规则与业务流程是松散耦合的，且业务组件和业务规则可由多个消费者共享。因此，可以非常方便地添加新的规则或流程。
2. 在BCGS中，根据新业务规则的内容，可将其作为简单规则或复杂规则添加。这些规则将根据GBRDG的建模语义添加到适当的位置。因此，语义相关的规则将遵循特定的搜索路径。且现有规则的添加不会在多项式时间内增加业务规则系统的复杂性。
3. 同样，所提出的模型的一个关键概念是将不同的业务组件组合以形成另一个业务组件。这些组件在重用时也可以与多个其他业务组件相关联。因此，这些组件可以根据需求进行扩展。

6.8 服务导向

业务组件描述了服务的内部结构，随后这些组件被实现为服务。此外，服务可以由现有的业务组件组成，或者根据第4.4节所述的服务请求动态创建新的业务组件。该概念特别使用FCADCA架构框架进行了说明。然而，此方法无需进一步修改即可适用于其他基于SaaS的云架构框架。

6.9 规则集成

在此方法中，BCGS的业务组件由业务流程和业务规则组成。业务规则根据其与组件的关联而被启用。在BCGS中，如果业务流程的输出制品对应于业务规则的输入制品，则启用规则事实。此外，根据业务规则的SA以及业务流程的业务事实，规则图（GBRDG）的一个节点将与业务流程图（BPGS）的一个节点相关联。因此，业务规则指导业务流程以实现特定目标。这也实现了加速开发和易于管理。

6.10 符合标准

根据美国国家标准与技术研究院（NIST）2011年云计算模型标准，云模型应包含五个基本特征、三种服务模型和四种部署模型。BCGS的形式化方法表明，它能够实现按需、弹性、灵活和可重用的业务流程。此外，如第3节所述，BCGS是基于FCADCA（曼达尔等人，2014a）框架设计的，该框架为FCADCA的资源提供网络访问和计量服务。此外，FCADCA包括针对SaaS、PaaS和SaaS的三个独立层，以及两个交叉层：管理和安全。因此，提出的机制符合NIST标准。

表2 关于第6节中确定的特征，正式业务流程建模方法论的比较表

	a	b	c	d	e	f	g	h	i
Wong 和 吉本斯（2008）	P	N	N	Y	N	N	N	N	Y
诺尔塔等人（2014）	Y	Y	P	P	Y	P	N	N	N
Walraven et al.（2014）	N	N	Y	P	Y	Y	N	N	N
王等人 (2010)	N	N	Y	N	P	N	Y	N	Y
艾恩德霍芬等人（2008）	N	N	N	P	Y	P	N	N	Y
Wombacher and Mahleko (2003)	Y	Y	N	N	N	N	Y	N	N
杜普曼斯（2012）	N	P	Y	Y	N	Y	Y	N	N
万和余（2011）	P	N	Y	N	N	Y	Y	N	N
维内齐安·波沃阿 等人（2013）	N	P	Y	Y	N	Y	Y	N	N
帕尤宁和 鲁奥科宁（2007）	Y	N	P	N	N	Y	Y	N	P
BCGS（提出的）	Y	P	Y	P	Y	Y	Y	Y	Y

7 BCGS评估

业务流程建模能够设计和捕获现有的业务流程，以及分析新的业务流程。因此，由于需要描述业务流程的结构和行为，定义用于建模业务流程的语言及其形式化表示是业务流程管理中的关键步骤。然而，云环境中的业务流程应具备可扩展性、灵活性、可重用性等能力，以支持频繁的流程变更。同时还应具备在业务流程与服务之间建立强关联的能力。如第6节所述，BCGS支持上述大部分特性。因此，为了评估业务流程建模机制，针对现有业务流程建模机制与提出的BCGS，在以下方面进行了详细的比较研究：

a. 动态性
b. 临时业务流程支持
c. 多渠道可访问性
d. 分析能力
e. 灵活性
f. 可重用性
g. 可扩展性
h. 服务导向
i. 规则集成

比较研究的结果列于表2中。其中，Y表示模型完全支持的特征，P表示模型部分支持的特征，N表示该特征未被模型支持或未被考虑。从对比表中可以看出，现有的业务规则建模机制仅支持少量被认定为基于云的业务流程重要特征的特性。大多数机制未能解决与动态性、灵活性、可重用性和可扩展性相关的问题，而BCGS能够支持这些特征。

8 结论

本文针对面向数据为中心的基于云的应用程序的业务流程建模问题展开研究。为此，提出了一种基于分层图的方法，称为BCGS。BCGS由多个业务组件组成，其中每个业务组件被定义为业务流程与业务规则的组合。同时提出了一种称为BPGS的基于图的形式化方法，用于表示云应用的业务流程。对BPGS的形式化分析表明，其遵循BPMN的结构与语义。业务规则的表示采用GBRDG。GBRDG能够对云环境中业务规则之间的组合与依赖关系进行建模，其中涉及的构造GBRDG中的组件是可重用的。本文还针对可在基于云的应用中的业务组件上执行的各种功能（如创建、启动等）提供了详细的形式化规约。这表明BCGS使流程设计具有高度适应性，允许参与者在运行时快速调整流程。

此外，提出的BCGS概念实现了在名为FCADCA的软件即服务框架中的业务导向服务分组。然而，总体而言，BCGS的服务导向概念适用于任何软件即服务框架。这展示了如何利用提出的BCGS有效管理基于云的服务。

文中还描述了一个详细的案例研究来说明BCGS的概念。研究表明，BCGS能够有效应对与基于云的应用中业务流程的重用性、模块化、动态性和灵活性相关的挑战。除此之外，它还支持临时业务流程实现和多渠道可访问性，这些被认为是云环境中集成业务流程和规则的关键因素。

未来的工作包括为以数据为中心的云应用开发基于业务流程的服务发现与选择机制。此外，基于建模语义，通过执行语义丰富该模型，并开发案例工具也是未来研究的主要目标。