基于SaaS的业务组件建模

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

摘要

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

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

参考本文应作如下引用 ：曼达尔，A.K. 和 萨卡尔，A. (2017) ‘软件即服务的业务流程建模’, 国际商业流程集成与管理杂志, 第8卷, 第2期, 第81–101页。

1 引言

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

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

在软件即服务交付中，模型特征如按需配置和快速弹性（NIST, 2011）使得应用程序能够非常迅速地部署和扩展。因此，基于SaaS的应用程序的运行环境可能快速变化，且应具备相应的适应能力。

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

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

现有的业务流程系统是封闭的集中式控制系统，仅用于执行组织的关键任务功能（戈亚尔和米基利内尼，2012年）。但在云生态系统中，商业环境将不断变化，因此能够快速建立集体业务流程成为一种需求。它还应具备将两个以上的协作方组合到一个配置中的能力，以形成可扩展系统（Norta 等，2014）。然而，当前的BPM系统并不支持流程的这种动态性。同时，也无法利用现有流程创建新的服务渠道，并将这些渠道重新分配给那些仅在运行时才被知晓其存在的流程，且这些流程可能因实例而异（戈亚尔和米基利内尼，2012年）。

此外，云环境中的业务流程应具备灵活性。此处，灵活性是指通过仅修改需要变更的部分，来实现业务流程类型和实例变更的能力。

可以进行修改，同时保持其他部分的稳定。但现有的业务流程建模技术和模型本质上是命令式的，它们严格描述了如何工作（巴特和德什穆克，2005）。因此，基于云的BPM系统应支持在流程模型内部的操控，甚至在运行时对流程模型进行修改。此外，在云环境中，提供流程建模的可重用性将非常有用，有助于降低设计新流程或重新设计现有流程时的高复杂度、时间消耗和错误（范登赫维尔和Leveraging，2011）。因此，云基础BPM系统应由业务流程和规则的动态性、灵活性、可扩展性和可重用性等主要特征驱动。

本文提出了一种基于图的新方法——面向软件即服务的业务组件图（BCGS），用于对基于云的业务流程的灵活性、可重用性和动态性进行建模。BCGS 反映了表示业务组件组合的业务设计。其中，业务组件被定义为业务流程与业务规则的集成。这种集成方法提高了可扩展性，并确保了流程与规则之间的一致性，同时允许基于 SaaS 的应用程序持续地流动和变更。为了表示业务操作，提出了面向 SaaS 的业务流程图（BPGS），其满足云环境中业务流程模型与符号（BPMN）的结构和语义。在此背景下，采用了广义业务规则依赖图（GBRDG）（曼达尔等，2013，2014b）来表示业务规则。GBRDG 利用图语义对适用于基于云的应用程序的业务规则及其各个方面进行建模。因此，BCGS 支持对基于云的业务流程功能方面的高层表示。此外，所提出的 BCGS 促进了基于云的业务流程中灵活、可重用和动态的业务组件组合，并为这类业务应用提供了单一连贯表示。进一步地，本文还讨论了 BCGS 所提出概念在一种名为面向数据应用的灵活云架构（FCADCA）（曼达尔等，2014a）的 SaaS 框架中的服务导向。

FCADCA 是一个针对 SaaS 的概念性架构框架，提供了以数据为中心的 SaaS 应用的主要功能，即可定制性、可扩展性和灵活性。

2 相关工作

多年来，许多研究工作都致力于业务流程管理。一般来说，业务流程管理涉及现有业务流程的设计与捕获，以及对新业务流程的分析（森本，2008b）。在业务流程设计方面，大多数文献集中在管理业务流程模型的复杂性（霍尔斯克等，2010；丁和刘，2008；波拉尼等，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的业务流程中使用不同业务规则的适用性。

流程。然而，该方向的大部分工作基于使用业务规则进行以工作流为基础的服务组合（施等人，2009；查尔菲和梅齐尼，2004；黄和阮，2009；佩特库和斯坦科夫斯基，2012）。部分研究文献提出了一个框架及相关技术，用于在分布式环境中半自动地实现业务流程（韩等人，2007）。而张等人（2009）提出了一种业务规则处理模型（BRPM），主要包含针对多租户SaaS应用的规则定制、规则存储和规则执行。米兰诺维奇等人（2008）通过添加规则作为建模概念，以新型网关类型的形式对BPMN进行了扩展，并采用了模型驱动工程的原则。但这些方法中的业务规则主要关注服务组合方面，且不支持相同业务流程的用户特定配置。因此，业务流程与业务规则在适应性、灵活性、可扩展性等方面的显著潜力难以实现。

在帕帕佐格卢（2012）中，提出了一种分层架构模型，有助于避免部署无控制的服务迷宫的陷阱，并为服务赋能提供了坚实的基础，从而使Web服务能够在基于SOA的业务应用中高效使用。该模型包含六个主要抽象层，分别是领域、业务流程、业务服务、基础设施服务、服务实现和运营系统。对该模型的分析强调了现有的企业资产如何被转化为业务服务，以及业务服务又如何被组合成业务流程（Papazoglou, 2007）。因此，服务被纳入业务流程的任务之中，并通过有限的业务策略定义组合模式。这样，服务可以在不同流程之间重用。

这些有限的业务策略仅从提供者视角定义了服务之间的工作流。然而，通过此类策略难以实现消费者特定配置。

因此，在很大程度上影响了面向服务的架构（SOA）和业务流程框架的灵活性与可扩展性特征。

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

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

3 面向数据为中心应用程序的灵活云架构

称为FCADCA的概念性架构框架是基于软件即服务的主要功能（如可定制性、可扩展性和灵活性）而设计的。

除此之外，该架构还能够支持以数据为中心的云应用在异构数据集上的实现。如图1所示，FCADCA采用四层结构设计。

1 Application layer ：这是最外层，直接与用户交互。它负责提供服务并管理服务配置。

2 Service management layer ：它负责根据请求者的需求向其提供服务。在此，多个功能模块被组合在一起以定义一项服务。通过定义服务之间的字段、公式和工作流，可以实现应用定制。

3 业务层 ：该层由多个业务组件和一组作用于服务及其组件的业务规则组成。通过这种框架，设计者能够实现面向业务的服务分组，且该分组独立于用于定义它们的功能模块。因此，由于业务组件与业务规则相互分离，业务层的变更可以更容易地被适应。

4 数据层 ：在此架构框架中，数据层分为两个子层，即元数据管理子层和数据管理子层。元数据管理层在业务层与数据管理层之间起到桥梁作用。根据数据类型的 不同，元数据可分为用户数据、应用数据、服务数据和事件数据。云中的数据具有高度动态演化的特性。

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

在FCADCA中，每一层都包含一个“接口”，该接口提供了不同层之间交互的手段，并支持信息交换。信息交换可以是消息，这些消息符合可引用交换模式以及指定信息模型的结构和语义。接口还提供了一道屏障，使得应用逻辑的变更不会影响到接口的使用者。此外，每层的接口由两个子接口组成：一个与前一层的接口进行交互，称为α − interface；另一个与下一层的接口进行交互，称为β − interface。接口由多个接入点组成，这些接入点提供对应用程序所暴露功能的访问。一个接口的接入点可以在不同层之间与另一个接口的多个接入点进行交互。

接入点会根据其可用性以及服务或服务组件的类型，为特定的服务或服务组件动态选择。因此，可以实现针对特定服务组合的动态添加或删除服务组件。

4 软件即服务应用程序中业务组件的形式化表示

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

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

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

$$ \text{BPGS} : \langle G_p, N_p, E_p, L_p \rangle $$

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

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

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

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

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

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

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

$$ L_p: E_p \rightarrow O $$

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

4.1.1 业务上下文层级分析

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

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

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

在BPGS中，event类型的节点大致可分为三类：开始事件（$ev_{start}$）、中间事件（$ev_{intermediate}$）和结束事件（$ev_{end}$）。

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

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

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

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

此外，在BPGS中，gateway类型的节点用于控制业务流程中的顺序流。它们用于过程图中的顺序流的分流与合流。

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

根据决策机制的不同，网关可以进一步分为三类：互斥网关（$g_{ex}$）、包容网关（$g_{in}$）和并行网关（$g_{pri}$）。因此，

$$ g = g_{ex} \cup g_{in} \cup g_{pri} $$

其中

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

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

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

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

4.1.2 业务流层级分析

BPGS 的边 ($E_p$) 有三种类型：顺序边 ($E_{ps}$)、消息边 ($E_{pm}$) 和关联边 ($E_{pa}$)。

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

序列边用于表示活动、事件或网关条件在流程中执行的顺序。因此，如果$N_{p1}$与$N_{p2}$是业务流程图$G_p$的节点，则

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

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

一条消息边用于表示两个节点之间的消息流。它存在于两个不同流程的事件、活动或网关之间。因此，如果 $N_{px}$和 $N_{py}$是两个不同业务流程 $G_{px}$和 $G_{py}$的节点，则

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

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

此外，在 BPGS 中，关联边 用于将外部要素与活动事件或网关相关联。因此，如果 $N_{p1}$和 $N_{p2}$是一个业务流程图 $G_p$的节点，则

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

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

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

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

除了支持业务规则系统的分析与设计外，GBRDG 还能够在云环境中基于跨业务场景对业务规则集进行划分。

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

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

$$ \text{GBRDG} : \langle N_s, N_c, E_c, E_d, L_r \rangle $$

简单规则表示为$N_s$，它由一个原子结构断言组成，并可包含一个动作断言。复合规则或复杂规则表示为$N_c$，由多个简单规则或简单规则与其他复合规则的任意组合构成。同样，根据事实的特征，云环境中的业务规则的简单规则语句 broadly 可分为行为规则（$N_{br}$）、服务规则（$N_{sr}$）和数据规则（$N_{dr}$）。因此，通常情况下，GBRDG中的节点$N_r$定义为，

$$ N_r = N_c \cup N_d $$

其中

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

且

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

GBRDG 中的边 $E_r$ 也由两个互不相交的集合组成，称为控制边 $E_c$ 和依赖边 $E_d$。其中，控制边定义了执行特定业务规则所需的业务规则及其关联关系。当某个业务规则在特定上下文中被细化为更详细的规则时，则认为存在依赖边。形式上，控制边可表示为 $(x \times y) \in E_c$，其中 $x,y \in N_r$，且由 $y$ 表示的业务规则将在由 $x$ 表示的业务规则实例化之后立即被实例化。另一方面，依赖边也表示为 $(m_r \times n_r) \in E_d$，其中 $m_r \in N_r’$ 且 $n_r \in N_r$，这里 $N_r’ \in N_r$ 仅与从其他规则派生出的业务规则保持一致。在此，由 $m$ 表示的业务规则被由 $n_r$ 表示的业务规则所引用。因此，GBRDG 中的边 $E_r$

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

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

算法1 GBRDG 创建算法

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

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

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

BCGS 是业务组件的抽象表示。BCGS 是一个有向层次图，其中每个节点（$N_{bc}$）表示一个业务组件，边 $E_{bc}$ 和 $E_c$ 表示图的构成部分之间的关联和包含关系。而 $L$ 是边上的一个标签函数。形式上，BCGS 可以表示为，

$$ \text{BCGS} : \langle G_{bc}, N_{bc}, E_{bc}, E_c, L, l_{bc} \rangle $$

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

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

其中 $G_p \neq \emptyset$ 且 $|G_p| = 1$

此外，一个业务组件也可以由多个其他已存在的业务组件组成。因此，

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

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

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

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

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

其中$E_{bp}$表示存在于业务流程与业务组件之间的业务流程边，

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

并且$E_{br}$表示存在于业务规则与业务组件之间的规则边，

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

$L_r$与$L_{bc}$是携带业务组件组成信息的标签函数。规则边上的标签（$L_r$）包含可访问该规则的业务组件列表。

$$ L_r: E_{br} \rightarrow {bc_1, bc_2, \dots, bc_n} $$

然而，业务组件边上的标签（$L_{bc}$）定义了业务组件的组合顺序。组合顺序是一个自然数集合（$\mathbb{N}$），其中数值越小，优先级越高。因此，标签函数可以定义为，

$$ L_{bc}: E_{bc} \rightarrow \mathbb{N} $$

• 业务组件状态 ：BCGS中节点（$N_{bc}$）的状态由一个状态函数定义，该函数将节点映射为数值0或1。其中，0表示启动一个组件节点，1 表示组件节点的终止。

$$ S: N_{bc} \rightarrow {0,1} $$

• 业务组件启动 ：在BCGS中，要执行一个业务流程，需要启动相关的业务组件。这涉及保持业务流程的状态，并关联适用于该流程的业务规则。但是，当一条规则激活时，通常会从输入参数或知识库中获取其输入，进行求值，然后更新知识库或将结果传递至输出。因此，规则片段是无状态的。因此，在BCGS中，组件启动仅涉及流程启动。当实例$(N_{bc})$满足以下条件时，业务流程$G_p \in N_{bc}$被启用，

$$ N_{bc} \rightarrow \exists G_p \in N_{bc} \land fanin(G_p) \neq \emptyset $$

如果 $(N_{bc})$ 成立，则状态 $S$ 将被修改为

$$ S(N_{bc}) = {0} $$

• 启用规则事实 ：仅当组件$N_{bc}$启动后，且实例$(G_r \in N_{bc})$成立时，业务规则$G_r \in N_{bc}$才能被启用。其中，$G_r$表示业务规则图。

$$ G_r \in N_{bc} \rightarrow \exists G_r \in N_{bc} \land S(N_{bc}) = 0 \land fanin(G_r) \neq \emptyset $$

因此，规则的启用取决于其与组件的关联。如果存在一条边$e \in E_{br}$，使得流程$G_p \in N_{bc}$的输出制品是$G_r$的输入制品，则规则事实被启用。此外，根据业务规则的SA以及业务流程的业务事实，规则图$G_r$中的节点$N_r$与业务流程图$G_p$中的节点$N_p$相关联。这表示业务规则适用于某个业务活动。可形式化定义为，

$$ \exists N_r \in G_r, \exists N_p \in G_p: SA(N_r) = businessfacts(N_p) \land N_r \rightarrow N_p $$

• 关联业务组件的启用 ：对于一个复合业务组件（$N_{bc}$），当其组成组件 $N_{bc1}$ 被启动时，若实例 $N_{bc2}$ 满足条件 $(N_{bc2} \in N_{bc})$，则该组件将被启用。

$$ N_{bc2} \in N_{bc} \rightarrow \exists e \in E_{bc}, \exists L(e), S(N_{bc1}) = 0, L(e) < L(e’), fanin(N_{bc2}) \neq \emptyset $$

其中

$$ eq(N_{bc1}, N_{bc2}) = (N_{bc1} \times N_{bc2}) \land (N_{bc2} \times N_{bc3}) - 1 \leq i \leq n $$

因此，业务组件过程的复合业务组件的启用取决于其与其他业务组件的关联。如果存在一条边 $e \in (N_{bc1} \times N_{bc2})$，使得流程 $N_{bc1}$ 的输出制品是 $N_{bc2}$ 的输入制品，则业务组件 $N_{bc2}$ 将被启用。

• 重用 ：业务组件、其关联的流程和规则以及元数据信息可以被业务组件图 $G_{bc}$ 中的其他业务组件节点重用。

$$ \forall x \in G_p, \forall y \in G_r, \forall N_{bc1}, N_{bc2}, \dots, N_{bcn} \in G_{bc}: (N_{bc1}, N_{bc2}, \dots, N_{bcn}) \rightarrow (x, y) $$

因此，业务流程和/或业务规则可被BCGS的多个业务组件所使用。其中，$N_{bc1}$、$N_{bc2}$、…、$N_{bcn}$为业务组件图$G_{bc}$的节点，而$G_p$、$G_r$分别为业务流程图和业务规则图。如前所述，业务组件可根据使用者的需求以及业务流程和业务规则的可用性来创建。因此，一个业务流程可以在不同规则的多个组件中被重用，或者一个业务规则可以在不同流程的多个组件中被重用。以下正式说明这两种情况：

1. 通过继承机制，可以实现具有不同业务规则的业务流程重用。此处，业务组件p中的业务流程$N_{bc1}$ 在业务组件$N_{bc2}$ 中被重用，并将业务规则从$r_1$替换为$r_2$。

$$ \forall G_p, \forall r_1, r_2, \forall N_{bc1}, N_{bc2} \in N_{bc}: (G_p, r_1, N_{bc1}) \land (G_p, r_2, N_{bc2}) \Rightarrow (G_p, r_2, N_{bc2}) $$

2. 同样，通过继承机制也可以实现不同业务流程中业务规则的重用。此处，业务组件 $r$ 的业务规则 $N_{bc1}$ 在业务组件 $N_{bc2}$ 中被重用，并采用业务流程 $p_2$ 而非 $p_1$。

$$ \forall p_1, p_2, \forall r, \forall N_{bc1}, N_{bc2} \in N_{bc}: (p_1, r, N_{bc1}) \land (p_2, r, N_{bc2}) \Rightarrow (p_2, r, N_{bc2}) $$

• 终止 ：一个业务组件（$N_{bc}$）实例只有在完成其所组成的其他所有组件中包含的业务流程的执行后，才会终止。

$$ \exists G_p \in N_{bc}: S(N_{bc}) = {1} $$

• 可扩展性 ：指系统处理随时间变化的较重或较轻负载的能力。在此背景下，可扩展性属性指的是随着业务组件实例的增加而增强的能力，或随着业务组件实例的减少而减弱的能力。因此，此类可扩展系统应具备以下能力：纵向扩展当负载增加时，scale-out当负载减少时。通过遵循mo建模语义，可以证明所提出的BCGS可以实现纵向扩展与横向扩展能力dif不同阶段：

1. 纵向扩展 ：它指的是提升系统的功能能力。在BCGS中，可以通过从流程创建新的业务组件、添加现有的业务组件，或在不同阶段添加业务规则来增强能力。

a. 可以从现有的业务流程和规则创建新的业务组件。因此，在实例 $t$ 创建的业务组件 $(N_{bc})^t$ 可表示为，

$$ \forall G_p, \exists G_{ri}, \forall N_{bc}: (G_p, G_{ri}, N_{bc}) \land (e \in E_{br} \times G_{ri} \neq \emptyset) \land (\forall e \in E_{br} \times G_{ri} \neq \emptyset) \land (G_{ri} \times N_{bc} \neq \emptyset), i \leq n $$

b. 同样可能出现的情况是，业务组件 $(N_{bc})$ 的能力需要在特定时间实例 $t$ 根据需求得到增强。这可以通过向现有组件添加业务组件 $(N_{bci})$ 来实现，更新后的业务组件 $(N_{bc})^t$ 可描述为，

$$ \forall N_{bci}, \exists N_{bc}: N_{bc} \subseteq N_{bc} \land n \in N_{bci} \land (\forall e \in E_{br} \times n \neq \emptyset) \land (fanout(N_{bc}) > fanout(N_{bci})), i \leq n $$

c. 也有可能出现这样的情况：在特定时间实例 $t$，某个业务组件 $(N_{bc})$ 需要额外的一组业务规则 $(G_{ri})$ 来满足使用者的请求。所得组件 $(N_{bc})^t$ 可描述为，

$$ \forall G_{ri}, \exists N_{bc}: N_{bc} \subseteq N_{bc} \land G_{ri} \in G_{ri} \land (\forall e \in E_{br} \times G_{ri} \neq \emptyset), i \leq n $$

2. 横向扩展 ：指降低系统的功能能力。在BCGS中，可以通过移除业务组件、删除现有业务组件以及移除业务规则来降低能力。

a. 当系统负载降低到一定程度时，需要从 GBRDG 中移除新创建的业务组件，以维持其效率。这可以通过从该业务组件中删除所有业务规则和业务流程，并将该组件本身从 GBRDG 中分离来实现。因此，在实例 $t$ 处可被移除的业务组件 $(N_{bc})^{t}_{rem}$ 可表示为，

$$ \exists G_p, \exists G_{ri}, \exists N_{bc}: (G_p, G_{ri}, N_{bc}) \land (e \in E_{br} \times G_{ri} = \emptyset) \land (\forall e \in E_{br} \times G_{ri} = \emptyset) \land (G_{ri} \times N_{bc} = \emptyset \land G_p \times N_{bc} = \emptyset), i \leq n $$

b. 业务组件（$N_{bc}$）的资源可根据需求在给定时间 $t$ 减少。这可以通过从现有业务组件（$N_{bc}$）中移除业务组件（$N_{bci}$）来实现。所得的业务组件（$(N_{bc})^t$）可描述为，

$$ \forall N_{bci}, \exists N_{bc}: N_{bc} \subseteq N_{bc} \land n \in N_{bci} \land (\forall e \in E_{br} \times n = \emptyset) \land (N_{bci} \times N_{bc} = \emptyset) \land (fanout(N_{bc}) < fanout(N_{bci})), i \leq n $$

c. 也可能出现这种情况：某个业务组件（$N_{bc}$）需要在特定时间实例 $t$ 删除某些业务规则（$G_{ri}$）。所得的组件 $(N_{bc})^t$ 可以描述为，

$$ \forall G_{ri}, \exists N_{bc}: N_{bc} \subseteq N_{bc} \land G_{ri} \in G_{ri} \land (\forall e \in E_{br} \times G_{ri} = \emptyset) \land (N_{bc} \times G_{ri} = \emptyset), i \leq n $$

4.4 FCADCA中业务组件的服务导向

SaaS 中的应用开发通常指采用服务驱动建模、设计和实现方法进行应用构建。在 FCADCA 中，服务层位于业务流程管理层之上，包含多个服务功能模块，这些模块对应于业务层中的业务组件。在 FCADCA 中，一个服务可以基于业务组件构成，而一个业务组件也可以实现在多个服务上。在此框架中，业务组件是松耦合、动态、可重用的单元，它们是构建面向服务软件的构建块。

从服务设计的角度来看，该业务组件描述了服务内部结构在服务分组方面的实现。通常，特定业务领域中的基本业务流程和基本业务组件的业务规则将由服务提供者提供。这些组件随后被实现为服务。此外，服务可以通过现有的业务组件集合进行组合，或根据服务请求动态地从现有业务流程（使用BPGS指定）和/或业务规则（使用GBRDG指定）的集合中创建新的业务组件来构建。然而，基于特定需求创建新的业务组件可能还需要进一步创建业务流程和/或业务规则。此外，如果使用者的服务需求与现有业务组件的能力不匹配，则服务提供者可以创建新的业务流程，并将其封装适当的业务规则以形成组件。将使用者指定的服务需求与业务组件的能力进行比较，主要涉及将这些需求与由组件构成的业务流程的功能性进行对比。新形成的业务组件可以在BCGS中与其他业务组件关联，以构成更复杂的组件，并进一步在FCADCA的服务管理层中被实现为服务。

由于业务组件作为业务流程、规则和其他业务组件的封装器，对于由其他业务组件组成的组件而言，其组成组件大多属于同一业务领域。此外，在复合业务组件中，组成组件的功能也是相互关联的。因此，通常情况下，BCGS根据业务领域和组件的功能对组件进行分组。因此，服务也可以根据与其关联的业务组件进行分类和分组。因此，BCGS的概念使得在FCADCA框架中实现面向业务的服务分组成为可能。基于业务领域和功能的服务分类也有助于高效的服务发现和选择过程。

表1 简化医疗系统的组件
组件ID
bc1
bc2
bc3
bc4
bc5
bc6
be7

5 使用案例研究说明BCGS

当今的基于云的商业场景要求业务流程必须对变化具有越来越强的响应性。因此，基于云的业务流程模型必须具备模块化、可扩展性和灵活性，这不仅有助于提高建模敏捷性，还能增强执行流程的健壮性和弹性。提出的BCGS满足了这些需求，为了使用BCGS说明这些概念，本文考虑了一个关于healthcare system的简单案例研究。

该医疗系统包含多个业务流程和业务规则（表1）。业务流程采用BPGS的语法和语义进行建模，而业务规则则使用GBRDG进行建模。这些流程和规则通过BCGS的概念封装成一个组件，并映射到服务上。

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

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

• BR 1 医疗声明服务仅适用于在组织直接薪酬名单中的员工。
• BR 2 对于住院时间不超过24小时的日间护理治疗提供报销。
• BR 3 日间护理服务适用于眼科手术、透析等情况。门诊服务不属于日间护理服务范围。
• BR 4 救护车费用可在网络医院和非网络医院提供报销，最高报销金额为1,000卢比。
• BR 5 每位员工家庭综合保险的最低保险金额为40万卢比，包含生育及职位类别。
• BR 6 在网络医院的日间护理费用报销额度为保险金额的10%，并可享受无现金服务。
• BR 7 在非网络医院的日间护理费用报销额度为保险金额的7%，且为非无现金服务。
• BR 8 医疗声明策略在收到理赔申请后，对因疾病产生的费用进行报销。该报销可以是无现金方式或非无现金方式。

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）的工作流程是需要考虑。在此流程中，首先将门诊组件（BC1）的状态初始化为0。因此，$S(N_{BC1}) = {0}$。当BC1开始运行时，其关联的业务组件将根据连接的关联边上的标签进行初始化。具有最小整数编号的标签将首先被初始化。此处，连接到预约与咨询过程（bc1）组件的关联边上的标签（$L_{bc}(BC1 \times bc1)$）最小，因此bc1业务组件的状态被更改为0，即$S(N_{bc1}) = {0}$。在业务组件启动后，其关联的业务规则也会被启用。因此，$G_r \in N_{bc1}$。然后，规则图R1的节点将映射到过程图Gp1中的相应节点。当bc1组件完成后