CN107015794B

CN107015794B - 软件即服务参考流程扩展验证框架

Info

Publication number: CN107015794B
Application number: CN201611166045.1A
Authority: CN
Inventors: M.奥尔盖耶
Original assignee: SAP SE
Current assignee: SAP SE
Priority date: 2015-12-18
Filing date: 2016-12-16
Publication date: 2021-07-06
Anticipated expiration: 2036-12-16
Also published as: CN107015794A; CN107016524A

Abstract

本公开描述了方法、软件、以及系统，包括为核心流程模型提供扩展点的方法。扩展点被提供给与核心流程相关联的核心流程模型。扩展点用规定了在扩展点被插入到核心流程模型中的扩展的受限制的行为的约束来预定义和注释。扩展点以流程扩展约束定义语言来制定，并且允许运行时行为的约束。流程扩展约束定义语言基于时间逻辑，并且用特定支持增强现有属性规范模式，以对包括在流程扩展中的活动在扩展任务类型级别制定约束。从用户接收将所选择的扩展插入到核心流程模型中的实例的指令。每个所选择的扩展包括用于扩展的用户定制的行为。核心流程模型的实例被确认。

Description

软件即服务参考流程扩展验证框架

相关申请的交叉引用

本申请要求于2015年12月18日在美国专利和商标局提交的名称为“软件即服务参考进程扩展验证框架”的第14/974,713号的优先权，并且要求于2015年12月18日在美国专利和商标局提交的名称为“受控参考流程可扩展性框架”的第14/974,662号的优先权；其整体内容通过引用被合并于此。

技术领域

本发明涉及软件即服务参考流程扩展验证框架。

背景技术

多种类型的软件即服务(SaaS)企业系统典型地在行业中可用。系统的大部分将它们的核心参考流程记录为信息流程，例如，作为它们产品文档的一部分来运输。典型的SaaS产品不提供对流程扩展进行准确建模和约束流程扩展的行为的能力，例如，以诸如业务流程建模和标注(BPMN)的业务流程建模语言进行建模。

多种学术方法可以用于应对业务流程模型和工作流程的变化的业务流程管理(BPM)研究领域。然而，这些研究并不应对约束在基于SaaS的企业软件的上下文中流程扩展的行为。在一些实施例中，建立在时间逻辑和模型检查原则上的更好的方案能够被使用作为基础方法。例如，解决方案可以在包含在扩展片段中的活动的类型级别上制定平台扩展约束。

发明内容

本公开一般地描述了用于确认核心流程模型的扩展的计算机实施的方法、软件、以及系统。例如，扩展点可以被提供给与核心流程相关联的核心流程模型。扩展点可以由核心流程模型提供者预先定义和存储。扩展点可以用规定了在扩展点插入到核心流程模型中的扩展的受限制的行为的约束来注释。扩展点可以遵循流程扩展约束定义语言。扩展点可以由核心流程模型提供者披露给核心流程模型的用户，例如，展示在用户界面中。可以从用户接收用于将所选择的扩展插入到核心流程模型的实例中的指令。每个所选择的扩展可以包括用于在核心流程运行时将在相应的扩展点运行的、扩展的用户定制的行为。核心流程模型的实例可以被确认。对于每一个扩展，可以针对于由约束规定的受限制的行为来确认用户定制的行为。

在一些实施例中，一种计算机实施的方法包括：提供用于与核心流程相关联的核心流程模型的扩展点，扩展点由核心流程模型提供者预先定义和存储，并且用规定了在扩展点插入到核心流程模型中的扩展的受限制的行为的约束来注释，扩展点遵循流程扩展约束定义语言；由核心流程模型提供者将扩展点披露给核心流程模型的用户；从用户接收用于将所选择的扩展插入到核心流程模型的实例中的指令，每个所选择的扩展包括用于在核心流程运行时将在相应的扩展点运行的扩展的用户定制的行为；以及确认核心流程模型的实例，包括对于每个扩展，针对于由约束规定的受限制的行为确认用户定制的行为。

前述以及其它实施方式中的每一个可以选择性地包括一个或多个以下特征，无论是单独的还是组合的。特别是，一个实施方式可以包括所有以下特征：

在第一方面，可与先前任何方面组合，该方法还包括，在确认核心流程模型的实例之前，将核心流程变换为不同的格式。

在第二方面，可与先前任何方面组合，确认核心流程模型的实例包括，基于计算树逻辑(CTL)和属性规范模型的流程扩展模型检查。

在第三方面，可与先前任何方面组合，确认核心流程模型的实例包括，使用指示用于扩展任务实例的确认规则的相关性和行为的约束语义。

在第四方面，可与先前任何方面组合，扩展点是包括在软件即服务(SaaS)中的应用域的一部分，该软件即服务(SaaS)作为扩展由SaaS提供者提供给客户和伙伴的参考流程的基于云的企业系统。

本说明书的主题的一个或多个实施方式的细节在附图和下面的描述中阐述。所述主题的其他特征、方面、以及优点将从描述、附图、以及权利要求中变得清晰。

附图说明

图1是示出根据实施方式的用于软件即服务(SaaS)企业系统的SaaS参考流程扩展验证框架的示例系统体系结构的框图。

图2是示出根据实施方式的用于SaaS参考流程扩展验证框架的示例开发/定义流程的框图。

图3A是示出根据实施方式的采样转换系统的示例的框图。

图3B是示出根据实施方式的对应于转换系统300的无限计算树的示例的框图。

图4是示出根据实施方式的平台扩展约束的示例的框图。

图5是示出根据实施方式的用于流程扩展约束定义语言的示例元模型的框图。

图6是示出根据实施方式的用于用扩展点604注释流程的示例用户界面的框图。

图7是根据实施方式的示例流程扩展模型检查算法的流程图。

图8是示出根据实施方式的用于支付流程扩展的扩展逻辑的示例流程的框图。

图9是示出根据实施方式的以佩特里网格式化(Petri net formalization)标记示出的支付流程扩展的示例的框图。

图10是示出根据实施方式的用于平台扩展约束的示例生成的计算树逻辑(CTL)公式的框图。

图11是示出根据实施方式的、从现有业务流程建模和标记(BPMN)建模工具扩展的平台扩展约束定义编辑器1100的示例内容的框图。

图12是根据实施方式的用于确认被插入到核心流程模型中的扩展的示例方法的流程图。

各个附图中相似的参考标号和名称指示相似的元素。

具体实施方式

本公开一般地描述了用于确认核心流程模型的扩展的计算机实施的方法、软件、以及系统。例如，扩展点被提供给与核心流程相关联的核心流程模型，扩展点由核心流程模型提供者预先定义和存储，并且用规定了在扩展点被插入到核心流程模型中的扩展的受限制的行为的约束来注释，扩展点遵循流程扩展约束定义语言。扩展点由核心流程模型提供者披露给核心流程模型的用户。从用户接收到将所选择的扩展插入核心流程模型的实例中的指令，每个所选择的扩展包括在核心流程运行时对于将在相应的扩展点运行的扩展的用户定制的行为。核心流程模型的实例被确认，对于每个扩展，包括针对于由约束规定的受限制的行为，确认用户定制的行为。

在基于云的企业系统中，同一个企业应用可以被许多客户消费，诸如软件即服务(SaaS)递送模型。典型地，基于云的企业系统对客户的特定需求的适配是一种核心要求。为此，SaaS提供者可以披露综合配置和扩展能力(例如，平台即服务)。这些能力中的一个关键挑战是通过客户和伙伴的参考流程的扩展(例如，由SaaS提供者运送(shipped))。在一些实施方式中，当多个客户共享同一个SaaS平台时，SaaS提供者可以约束插件扩展的行为，从而SaaS平台的总体完整性和稳定性得到保证(例如，受控的参考流程扩展性)。

本公开描述了SaaS参考流程扩展验证框架，其包括了超过工业和科学上目前最先进系统的以下贡献。首先，流程扩展约束定义语言可以允许由核心SaaS参考流程模型披露的扩展点用限制插入的扩展的行为的约束来注释。此域特定语言可以解决SaaS提供者定义关于流程扩展的行为的约束的需求。例如，该语言可以基于时间逻辑，并且可以利用特定的支持来增强现有属性规范模式，例如，对于包含在流程扩展中的活动在类型级别制定约束。第二，流程扩展模型检查算法可以允许将增强的属性规范模式变换为计算树逻辑(CTL)。在业务流程建模和标记(BPMN)元素的核心组中建模的流程扩展可以被变换为例如佩特里网，并且通过应用模型检查原则来针对于平台约束进行检查。

图1是示出根据实施方式的用于SaaS企业系统100的SaaS参考流程扩展验证框架的系统体系结构的示例的框图。例如，图1示出了框架的组件和它们的互动。本公开提出的组件包括，例如，流程扩展验证引擎102、BPMN到佩特里网变换组件104、属性规范模式到CTL变换组件106、平台扩展约束108(例如，来自SaaS参考流程储存库110)、以及平台扩展约束定义编辑器112(例如，来自SaaS提供者内容授权系统114)。目前最先进组件中可再用的组件包括佩特里网模型检查器116。目前最先进组件中可再用并且通过本公开扩展的组件可以包括，例如，流程扩展建模器118(例如，来自流程扩展建模环境120)、流程扩展122、核心流程124(例如，BPMN)、以及参考流程授权编辑器126。SaaS企业系统100可以服务至少一个SaaS客户/伙伴128和至少一个SaaS提供者130。其它配置是可能的。

图2是示出根据实施方式的用于SaaS参考流程扩展验证框架的示例开发/定义流程200的框图。例如，流程扩展模型检查方案的基本原理示出在图2中。SaaS客户或伙伴202可以开发需要被验证的流程扩展204，例如，用以确定其是否遵守由SaaS提供者206对于特定扩展点定义的约束。可选地，框架预见整合由法定权威(legal authorities)208定义的约束和符合性规则。流程扩展可以在BPMN中建模，并且作为模型检查方案的先决条件，可以被变换为佩特里网格式。

在一些实施方式中，框架可以支持至少两个不同类别的符合性(compliance)检查，例如，使用核心平台扩展约束210的符合性检查，以及使用一般域知识212的符合性检查。

例如，在使用核心平台扩展约束210的符合性检查中，SaaS提供者206可以用定义了允许(不允许)扩展做什么的平台扩展约束来充实(enrich)扩展点。流程扩展模型检查214可以被提供，其验证流程扩展是否遵循这些限制。例如，这能够保证核心SaaS企业系统只在定义的边界内扩展(例如，提供稳定性)。

例如，对于使用一般域知识212的符合性检查，约束可以来源于公司范围的设计指南。而且，符合性要求可以来源于质量标准和法律法规，例如，来源于萨班斯法案(Sarbanes-Oxley)、新巴塞尔资本协定(Basel II)、或ISO9000。这些和/或其他法规可以定义业务流程的符合性要求，例如，以保证流程扩展符合这些法规。为了实施这些原理，本公开描述了用于属性规范的流程扩展约束定义语言以及相应的流程扩展模型检查算法。

在一些实施方式中，流程扩展模型检查可以基于一些基础，诸如，CTL基础和属性规范模式基础。在CTL基础中，例如，系统模型可以以毫无疑义的方式描述系统的行为。例如，系统可以使用描述了系统如何从一个状态进化到另一个状态的状态和转换的有限集合来抽象。系统要求可以典型地使用基于时间逻辑的属性规范语言来描述。模型检查可以被用作验证技术，其考察所有可能的系统状态以便进行检查，例如，某一属性是否被满足，或不被满足。这个方案可以建立在CTL上，作为格式化平台扩展约束的基础。

在转换系统基础中，例如，转换系统TS可以描述软件系统的行为，并且可以通过以下元组来定义：

TS＝(S,Act,→,I,AP,L) (1)

其中S是状态的有限集合，Act是动作的集合，

是转换关系，

是初始状态的集合，AP是原子命题(atomic proposition)的集合，而L：S→2^AP是标记函数。状态s∈S可以在某些时刻描述系统的一些信息。动作α∈Act可以描述两个状态之间的转换。

图3A是示出根据实施方式的采样转换系统300的示例的框图。图3B是示出根据实施方式的对应于转换系统300的无限计算树302的示例的框图。例如，转换系统300和相应的无限计算树302可以从状态s₀ 304开始。

标记函数L涉及对转换系统的任何状态s的原子命题的集合(s)∈2^AP。(s)恰好代表状态s满足的那些原子命题a∈AP。给定Φ是命题逻辑公式，然后状态s满足公式Φ，当且仅当，由(s)导致的评估使得公式Φ为真。缩写“iff”代表“if and only if”(当且仅当)，而2^AP表示AP的幂集。

表1总结了基本的CTL公式。假设TS＝(S,Act,→,I,AP,L)是转换系统，并且假设(s_i,s_i+1,…)是从s_i∈出发的路径。假设

和ω∈AP是原子命题。

表1：CTL公式

虽然属性规范语言，诸如CTL，可以提供非常强大的工具，用于定义行为约束，但是SaaS提供者和客户可能难于使用该语言，因为需要坚实的数学背景。例如，这个限制可以提供使用属性规范模式作为平台扩展约束语言中的基础的动机。例如，属性规范模式可以是关于系统的有限状态模型中的可准许的状态/事件序列的共同出现的要求的一般化的描述。

每个属性规范可以至少由模式和范围组成。例如，模式部分可以规定哪些必须发生，而范围部分可以规范何时模式必须保持。每个属性规范模式可以包括关于如何将模式映射到正式语言的描述，例如，支持到CTL的映射。

表2总结了模式，例如，模式可以被划分为发生和次序(order)模式。符号P和Q代表系统模型的给定状态/事件。

模式	类型	语义
			不存在	发生	P不在范围内出现
通用性	发生	P在范围内始终出现
			存在	发生	P必须在范围内出现
有界存在	发生	P必须在范围内至少/准确地/至多出现k次
			优先	次序	P必须总是在范围内领先Q
响应	次序	P必须总是在范围内跟随Q

表2：模式层级

范围可以定义，例如，用于模式的开始和结束状态/事件(例如，见表3)。符号P和Q分别代表系统模型的给定状态和事件。“全局的”，当用作范围时，意味着模式必须在整个系统运行期间保持。“之前”意味着模式必须在给定状态P的第一次出现时保持。“之后”意味着模式必须在给定P的第一次出现之后保持。“之间/和”意味着模式必须从给定P的出现保持到给定Q的出现。“之后/直到”与“之间/和”相同，但是即使Q从不出现，模式也必须保持。

表3：模式范围

平台扩展约束语言可以解决，例如，规定在SaaS企业系统的上下文中关于流程扩展的任务类型的约束的具体要求。约束可以包括，例如，扩展任务类型的符合性约束。为了解决用于受控参考流程的可扩展性的要求，SaaS提供者可以制定某些符合性约束，这些符合性约束定义了什么流程扩展是被允许(或不允许)做的，以便保证核心企业系统的总体稳定性。当核心SaaS企业系统的运输货物被运送时，例如，提供者不知道将被SaaS客户和伙伴开发的具体的流程扩展。然而，SaaS提供者需要制定流程扩展当被插入核心SaaS企业系统的某些扩展点时需要满足的约束。这包括对流程扩展之内发生某些活动的约束，例如，不存在从核心SaaS企业系统中删除或更新数据的活动，以保证对于某一扩展点的只读扩展。此外，在流程扩展建模的上下文中的通用域知识可以约束某些活动的次序(例如，指示消息加密活动必须总是在来自外部消息的响应消息被解密之前被运行)。可以对扩展任务的类型、而不是在任务实例制定约束。这要求用额外的语义来增强现有的属性规范模式。

图4是示出根据实施方式的平台扩展约束的示例的框图。例如，图4示出了具有由三个扩展任务组成的简单的信用额度检查的流程扩展的两个解释语义，例如，BPMN格式402和佩特里网格式404。流程中的扩展包括核准步骤扩展任务类型406和通知步骤扩展任务类型408。

扩展以BPMN格式402示出并以相应的佩特里网格式404示出。流程扩展已经被插入核心SaaS参考流程。这个示例表达了在流程扩展模型PE中，当应用扩展模式时，必须发生类型T＝“ApprovalStep(批准步骤)”的扩展任务t。但是，流程扩展模型可以包含与特定扩展任务类型T相关的多个任务实例t_i，并且这可以导致现有模式的两个不同的解释语义。在CTL中，例如，现有全局(Exists Globally)模式可以使用公式(Q)来表达，其中，Q代表流程扩展模型必须满足的某个状态。在这种情况下，流程扩展模型PE的状态可以使用其佩特里网代表的标记功能M:P→N来表达。均参考扩展任务类型T的核准任务实例t₁和t₂两者已经被映射到佩特里网中的位置p₁和p₂。

参考图4，当将模式应用到扩展任务类型时，示出两个解释语义。首先，“所有任务实例”(All Task Instances)约束语义410指示该约束与涉及给定扩展任务类型T的所有任务实例t_i有关。如果在PE的运行期间存在状态，该模式对于流程扩展PE和扩展任务类型T成立，其中与扩展任务类型T有关的所有任务实例t_i被激活(运行)。这意味着存在这样一个状态，其中在p₁和p₂中存在令牌(token)。将现有全局模式的这个解释语义应用到我们的示例，流程扩展模型将不满足这个约束：

((p1)>0∧(M(p2)>0)) (2)

其次，“至少一个任务实例”(At Least One Task Instances)约束语义412指示该约束与涉及给定扩展任务类型T的至少一个任务实例t_i有关。如果在PE的运行期间存在状态，则模式对于流程扩展PE和扩展任务类型T保持，其中，与扩展任务类型T相关的至少一个任务实例t_i被激活(运行)。这意味着存在这样一个状态，其中在p₁和p₂中存在令牌(token)。将现有全局模式的这个解释语义应用到我们的示例，流程扩展模型将满足这个约束：

((p1)>0∨((p2)>0)) (3)

当处理关于扩展任务类型等级的约束时，考虑到对于每个属性规范模式的全部两个解释语义可能是有益的。

这里描述的流程扩展约束定义语言可以扩展属性规范模式，从以额外的语义用于制定关于任务类型等级的约束到解决在线的SaaS流程扩展要求。

图5是示出根据实施方式的用于流程扩展约束定义语言的示例元模型500的框图。元模型专注于模式的核心集合：存在502、不存在504、优先506、以及响应508。对于这些模式502-508中的每一个，添加参考给定扩展任务中的全部实例或至少一个实例的语义。每个模式502-508的范围510可以被限制在全局的512，意味着每个模式502-508必须在流程扩展模型的全部运行期间被保持。

所有扩展的模型可以被整合到SaaS核心企业系统元模型中、SaaS流程扩展元模型和扩展任务类型元模型中。类别514可以包括可以被导入516的结构，而剩余的类别可以由本公开提供。

在一些实施方式中，可以使用改进属性规范模式的定义，例如，使用在SaaS参考流程扩展性的上下文中所要求的、用于关于扩展任务类型等级的平台扩展约束的公式的额外的语义。在一些实施方式中，模式可以包括以下类型的模式。

定义1(例如，存在所有全局的任务实例(Existence All Task InstancesGlobally))是这样的模式，如果在PE的运行期间存在状态，则该模式可以对于流程扩展PE和扩展任务类型T被保持，其中，与扩展任务类型T相关的所有任务实例t_i被激活(运行)。佩特里网标记功能(t_i)可以确定在涉及t_i的位置处令牌的数量。在等式4中，令n表示包含在与扩展任务类型T相关的PE中的任务实例的总数。

定义2(例如，存在至少一个全局的任务实例(Existence At Least One TaskInstance Globally))是这样的模式，如果在PE的运行期间存在状态，则该模式可以对于流程扩展PE和扩展任务类型T被保持，其中，与扩展任务类型T相关的至少一个任务实例t_i被激活(运行)。佩特里网标记功能(t_i)可以确定在涉及t_i的位置处令牌的数量。

定义3(例如，不存在所有全局的任务实例(Absence All Task InstancesGlobally))是这样的模式，如果在PE的运行期间从不存在状态，则该模式可以对于流程扩展PE和扩展任务类型T被保持，其中，与扩展任务类型T相关的所有任务实例t_i被激活(运行)。佩特里网标记函数(t_i)可以确定在涉及t_i的位置处令牌的数量。在等式6中，令n表示包含在与扩展任务类型T相关的PE中的任务实例的总数。

定义4(例如，不存在至少一个全局的任务实例(Absence At Least One TaskInstance Globally))是这样的模式，如果在PE的运行期间从不存在状态，则该模式可以对于流程扩展PE和扩展任务类型T被保持，其中，与扩展任务类型T相关的至少一个任务实例t_i被激活(运行)。佩特里网标记功能(t_i)可以确定在涉及t_i的位置处令牌的数量。

定义5(例如，优先至少一个全局任务实例(Precedence At Least One TaskInstance Globally))是这样的的模式，如果在PE的运行期间存在状态，则该模式可以对于流程扩展PE和扩展任务类型T_A和T_B被保持，其中，与扩展任务类型T_A相关的至少一个任务实例t_Ai先于与扩展任务类型T_B相关的至少第一个任务实例t_Bi。佩特里网标记函数(t_Ai)可以确定在涉及t_Ai的位置处令牌的数量，而(t_Bi)可以确定在涉及t_Bi的位置处令牌的数量。

原子命题可以定义为如下：

定义6(例如，响应至少一个任务实例(Response At Least One Task Instance))是这样的模式，如果在PE的运行期间存在状态，则该模式可以对于流程扩展PE和扩展任务类型T_A和T_B被保持，其中，与扩展任务类型T_A相关的至少一个任务实例t_Ai跟随与扩展任务类型T_B相关的至少第一个任务实例t_Bi。佩特里网标记功能(t_Ai)可以确定在涉及t_Ai的位置处令牌的数量，而佩特里网标记功能(t_Bi)可以确定在涉及t_Bi的位置处令牌的数量。

在一些实施方式中，原子命题可以定义为如下：

图6是示出根据实施方式的用于用扩展点604注释流程602的示例用户界面600的框图。例如，图6示出了SaaS提供者如何能够用使用扩展606的平台扩展约束来注释流程602(例如，核心流程“现场服务(Field Service)”)的扩展点604。例如，用户界面600可以向用户展示流程602，用户可以从中选择一个扩展点604来注释。注释定义区域608可以被展示。注释定义区域608中的控制610可以允许用户选择性地对于当前选择的扩展点604添加新的约束或去除所选择的约束。当前约束可以列出在扩展点约束列表612中。与约束相关联的字段可以被定义在平台扩展约束定义编辑器614中。显示在注释定义区域608中的扩展点名称614(例如，EP-101)匹配所显示的流程602上的扩展点标记616。例如，使用编辑器614，用户可以定义属性模式616、属性范围618、以及扩展任务类型620(例如，更新核心数据步骤(Update Core Data Step))。在当前示例中，更新核心数据步骤可以使用扩展606来完成，在扩展606中，用户可以编辑支付流程扩展逻辑624的功能性。用户界面600的其它实施方式也是可能的。而且，注释定义区域608的内容对于不同类型的扩展点可以是不同的。

图7是示出根据实施方式的示例流程扩展模型检查算法700的流程图。例如，算法700使用映射到佩特里网模块的频繁使用的BPMN元素的核心集合。在702，流程扩展模型被加载(例如，通过SaaS扩展704)。在706，BPMN模型被自动地变换(例如，通过系统模型708)为佩特里网格式，其构建了这个流程扩展模型的格式验证的基础。算法可以生成至少两个特定格式的佩特里网表示：低级别分析器的佩特里网模型和模型检查工具。

在710，核心流程模型(例如，BPMN)被加载(例如，通过SaaS核心712)。在714，平台扩展约束被从扩展已经被插入到其中(例如，通过属性规范715)的各个扩展点中提取。选择性地，可以在716加载与一般域知识相关的相关平台扩展约束(例如，通过一般域语言718)。在720，约束和设计规则被提取。

为了生成用于扩展的属性规范模式的CTL公式，算法可以首先确定用于在约束表达中使用的每个扩展任务类型的所有任务实例。例如，在722，用于扩展的任务类型的实例被提取，并且在726，CTL格式被生成。流程扩展模型的佩特里网和CTL公式两者被最终输入用于模型检查组件730，其中，在728，流程扩展模型被验证。

为了验证平台扩展约束，对于BPMN建模元素的子集到佩特里网可以定义映射。例如，由于有效的模型检查算法和支持工具的可用性，佩特里网可以用作下层的格式化语言。BPMN标准可以提供非常广泛的建模元素和图类型。对于映射，可以选择最频繁使用的BPMN元素的核心集合。例如，基于与最频繁使用的BPMN建模元素的关联和对准(alignment)，选择可以完成。

为了能够参考扩展任务实例作为约束表达之内的原子命题，BPMN活动、事件、以及网关可以被映射到佩特里网模型内的明确位置，其可以再次在CTL公式内被参考。详细的映射在下面描述。映射可以利用没有标记(或者所谓的“沉默”转换)的佩特里网转换。例如，这些转换捕获外部用户不能观察到的内部动作。内部地，框架能够生成经典佩特里网格式，其然后可以被序列化为，例如，LoLA模型检查工具的原本格式和能够进一步被用于仿真目的的佩特里网标记语言。例如，在732，对是否要求进一步的分析(例如，通过分析模块734)进行确定。在736，可以发生流程扩展模型的仿真。变换方案可以与一个或多个映射规范相关。但是，主要区别在于，在映射中，BPMN元素活动、事件、以及网关可以被映射到明确的佩特里网位置，允许在与扩展任务实例相关的CTL中制定原子命题。通过允许对于给定活动的多个出站和入站序列流程，这允许活动的分开和合并行为的建模非常灵活。例如，活动需要被限制在单入口和单出口模型。图例738包括识别流程700中的步骤是自动的任务还是人工的任务的示例关键。

在一些实施方式中，模型检查工具(例如，LoLA)可以用来验证流程扩展模型是否满足平台扩展约束的给定集合。例如，工具可以验证在给定佩特里网上的各种各样的行为属性。例如，工具可以基于明确的状态空间验证(例如，可到达的状态的完全枚举法)，并且工具可以影响(leverage)若干最先进的状态空间减少技术。例如，所述技术可以具有只暴露总体状态空间的很小部分的效果，并且可以相对于被暴露的部分与原始状态空间相等地进行行为。工具还可以支持CTL公式的评估。例如，对于佩特里网，公式可以递归地构建，从而每个比较都是CTL公式。例如，比较可以由位置名称、运算符(例如，<><＝>＝＝<>#之一)、以及自然数组成。标记可以满足比较，例如，特定位置上的令牌的数量是否满足对于给定数量的特定关系。如果网络的初始标记被满足，则布尔运算符AND、OR和NOT可以被使用，并且CTL公式可以是有效的。

图8是示出根据实施方式的用于支付流程扩展的扩展逻辑802的示例流程800的框图。例如，BPMN标记可以用于扩展逻辑802。在这个示例中，由SaaS提供者运送的核心参考流程已经被扩展，以便与用于信用卡验证的外部支付卡提供者整合。每个扩展任务804-816具有唯一标识符(例如，ET1)、名称、以及在使用BPMN标记符号中示出的、具有如通过图例820指示的含义的相关扩展任务类型818。

在这个示例中，假设六个平台扩展约束需要被支付流程扩展满足，如表4中所示：

表4：采样平台扩展约束

采样平台约束可以被分组到两个类别。第一类别(例如，来自扩展点的约束)可以包括约束C1到C3。使用约束，例如，核心企业系统的提供者可以保证在扩展点EP-101处扩展的核心流程“现场服务和维修”的每个扩展片段只能从核心系统中读取数据。而且，流程扩展将不被允许创建、删除或更新核心数据。对于这个目的，三个约束C1到C3可以使用扩展的ABSENCE模式来定义。

第二类别(例如，来自一般域知识的约束)可以包括约束C4到C6。这三个采样扩展约束可以示出一般设计规则如何关于流程扩展进行验证。例如，如果在流程扩展中存在消息加密步骤和消息解密步骤，则消息加密步骤必须总是跟随消息解密步骤。这个要求可以，例如，通过使用对两个扩展任务类型的扩展的EXISTENCE模式，以及通过使用扩展的RESPONSE模式来验证相关任务的排序来表达。

图9是示出根据实施方式的以佩特里网格式化标记示出的支付流程扩展900的示例的框图。例如，扩展900是图8中示出的BPMN模型的佩特里网格式化等同物，例如，根据上面介绍的映射规范变换到佩特里网格式。

在一些实施方式中，在生成CTL公式以前，流程扩展验证引擎可以从流程扩展模型中查询所有的任务实例。对于每个任务，相关的扩展任务类型可以被确定，如表5中所示。

ID	扩展任务名称	扩展任务类型
			ET1	取得信用卡令牌	读取核心数据步骤
ET2	加密支付消息	加密消息步骤
			ET3	更新支付历史	更新核心数据步骤
ET4	请求支付授权	调用服务步骤
			ET5	解密支付消息	解密消息步骤
ET6	批准打折	批准步骤
			ET7	通知客户	通知步骤

表5：支付扩展流程-扩展任务

图10是示出根据实施方式的用于平台扩展约束的示例生成的CTL公式的框图。例如，对于参考(例如，在其操作数之一中)在流程扩展模型中参考的扩展任务类型的每个平台扩展约束(见表5)，相应的CTL公式可以如在图10中所列出的那样生成：

图10中列出的CTL公式可以使用，例如，模型检查的句法来表达。表6示出了用于支付扩展流程的示例验证结果：

表6：流程模型检查结果

图11是示出根据实施方式的从现有BPMN建模工具扩展的平台扩展约束定义编辑器1100的示例内容的框图。例如，对于核心流程1102，扩展点1104被选择。例如，该选择可以导致平台扩展约束1108可以被定义在其中的属性区域1106的显示。

图12是根据实施方式的用于确认插入到核心流程模型中的扩展的示例方法1200的流程图。为了表示清楚，以下描述一般地描述了在图1-11的上下文中的方法1200。

在1202，扩展点被提供给与核心流程相关联的核心流程模型，扩展点被核心流程模型提供者预先定义和存储，并且用规定了在扩展点插入到核心流程模型中的扩展的受限制的行为的约束来注释，扩展点以流程扩展约束定义语言制定并且允许扩展的运行时行为的限制，其中，流程扩展约束定义语言基于时间逻辑，并且以对于包括在流程扩展中的活动的扩展任务类型等级的公式约束的特定支持增强了现有属性规范模式。例如，SaaS提供者130可以使用平台扩展约束定义编辑器112将扩展点添加到核心流程模型。在另一个示例中，SaaS提供者206可以提供核心平台扩展约束210。例如，流程扩展建模器118可以披露SaaS客户/伙伴128能够通过其定义用于核心流程的扩展点的语言。基于SaaS客户/伙伴128的输入，例如，定义的扩展点可以限制跟随被扩展的核心流程模型的流程的运行时行为。从1202，方法1200前进到1204。

在1204，扩展点由核心流程模型提供者披露给核心流程模型的用户。例如，平台扩展约束定义编辑器1100可以披露与核心流程1102相关联的扩展点，包括披露所选择的扩展点1104。从1204，方法1200前进到1206。

在一些实施方式中，扩展点是包括在软件即服务(SaaS)、基于云的企业系统中的应用域的一部分，该软件即服务(SaaS)、基于云的企业系统扩展了由SaaS提供者提供给客户和伙伴的参考流程。例如，扩展点可以由SaaS参考流程储存库110提供。

在1206，从用户接收到将所选择的扩展插入核心流程模型的实例中的指令，每个所选择的扩展包括在核心流程运行时对于将在相应的扩展点运行的扩展的用户定制的行为。例如，对于所选择的扩展点1104使用属性区域1106，用户(例如，SaaS客户/伙伴202)可以规定所选择的扩展点1104的具体参数和行为(例如，在流程扩展204中)，包括平台扩展约束1108。从1206，方法1200前进到1208。

在1208，核心流程模型的实例被确认，对于每个扩展，包括针对于由约束规定的受限制的行为，确认用户定制的行为。例如，由用户保存的核心流程1102可以进行确认流程，诸如流程扩展模型检查214。在1208之后，方法120停止。

在一些实施方式中，方法1200还包括，在确认核心流程模型的实例之前，将核心流程变换为不同的格式。例如，核心流程的BPMN格式402可以在流程扩展模型检查214被运行之前，被变换为核心流程的佩特里网格式404。

在一些实施方式中，确定核心流程模型的实例包括基于CTL和属性规范模式的流程扩展模型检查。例如，如上所述，与转换系统300相对应的无限计算树302可以被用于进行验证。而且，表2中使用的模式，识别系统模型的特定状态/事件，可以被用于进行验证。

在一些实施方式中，确认核心流程模型的实例可以包括使用指示用于扩展任务实例的确认规则的相关性和行为的约束语义。例如，参考图4，如上所述，当应用该模式到扩展任务类型时，约束语义410和412可以被用作两个解释语义。

在本说明中描述的主题和功能操作的实施方式可以以数字电子电路、有形地体现的计算机软件或固件、计算机硬件来实施，包括在本说明中公开的结构以及它们的结构上的等同物，或者一个或多个它们的组合。在本说明中描述的主题的实施方式可以被实施为一个或多个计算机程序，即，编码在有形的、非瞬时的计算机存储介质上的计算机程序指令的一个或多个模块用于由数据处理装置运行或控制数据处理装置的操作。可替换的，或另外的，程序指令可以编码在人工生成的传播信号上，例如，机器生成的电、光、或电磁信号，该信号被生成以编码用于传输给合适的接收者以便由数据处理装置运行的信息。计算机存储介质可以是机器可读存储设备、机器可读存储基质、随机或串行存取存储设备、或一个或多个它们的组合。

术语“数据处理装置”是指数据处理硬件，并且涵盖用于处理数据的所有种类的装置、设备、以及机器，作为示例，包括在本说明中描述的主题和功能操作的实施方式可以以数字电子电路、有形地体现的计算机软件或固件、计算机硬件来实施，包括在本说明中公开的结构以及它们的结构上的等同物，或者它们中的一个或多个的组合。在本说明中描述的主题的实施方式可以被实施为一个或多个计算机程序，即，编码在有形的、非瞬时的计算机存储介质上的计算机程序指令的一个或多个模块用于由数据处理装置运行或控制数据处理装置的操作。可替换的，或另外的，程序指令可以编码在人工生成的传播信号上，例如，机器生成的电、光、或电磁信号，该信号被生成以编码用于传输给合适的接收者以便由数据处理装置运行的信息。计算机存储介质可以是机器可读存储设备、机器可读存储基质、随机或串行存取存储设备、或一个或多个它们的组合。

术语“数据处理装置”是指数据处理硬件，并且涵盖用于处理数据的所有种类的装置、设备和机器，作为示例，包括可编程处理器、计算机、或者多个处理器或计算机。所述装置还可以是，或者进一步包括，专用逻辑电路，例如，中央处理单元(CPU)、FPGA(场可编程门阵列)、或ASIC(专用集成电路)。在一些实施方式中，数据处理装置和/或专用逻辑电路可以是基于硬件的和/或基于软件的。所述装置可以选择性地包括创建用于计算机程序的运行环境的代码，例如，构成处理器固件、协议栈、数据库管理系统、操作系统、或者一会打个它们的组合的代码。本公开考虑到了具有或不具有传统操作系统的数据处理装置，例如，LINUX、UNIX、WINDOWS、MAC OS、ANDROID、IOS、或者其它合适的传统操作系统。

计算机程序，也可以被称为或描述为程序、软件、软件应用、模块、软件模块、脚本、或代码，可以以任何形式的编程语言来编写，包括编译语言或解释语言，或者说明性语言或过程语言，并且其可以以任何形式来布置，包括独立程序或作为模块、组件、子例程、或者适于在计算环境中使用的其它单位。计算机程序可以，但是不必，对应于文件系统中的文件。程序可以被存储在保存其它程序或数据的文件的一部分中，例如，存储在标记语言文档、专用于当前程序的单一文件、或者多个相互协调的文件中的一个和多个脚本，例如，存储一个或多个模块、子程序、或代码部分的文件。计算机程序可以被布置成在一台计算机上运行，或者在位于一个地点或分布在多个地点并通过通信网络相互连接的多台计算机上运行。虽然在各个附图中示出的程序的各个部分被示出为通过各种对象、方法、或其它流程实施各种特征和功能的单独的模块，但是所述程序可以适当地包括许多子模块、第三方服务、组件、程序库等等。相反，各个组件的特征和功能可以适当地被组合到单一组件中。

在本说明中描述的流程和逻辑流程可以由运行一个或多个计算机程序的一个或多个可编程计算机来执行，以便通过对输入数据进行操作并生成输出来执行功能。流程和逻辑流程还可以通过专用逻辑电路执行，并且装置也可以被实施为专用逻辑电路，例如，CPU、FPGA、或ASIC。

适于计算机程序运行的计算机可以基于通用或专用微处理器、全部两者、或任何其它类型的CPU。一般地，CPU将从只读存储器(ROM)或随机存储存储器(RAM)、或全部两者接收指令或数据。计算机的主要元件是用于执行或运行指令的CPU和用于存储指令和数据的一个或多个存储器件。一般地，计算机还将包括一个或多个用于存储数据的海量存储器件、操作地偶接到所述存储器件、从所述存储器件接收数据或向所述存储器件传送数据，或者全部两者，所述存储器件例如磁盘、磁光盘、或光盘。但是，计算机需要具有这样的器件。而且，计算机可以被嵌入到另一个设备中，例如，移动电话、个人数字助理(PDA)、移动音频或视频播放器、游戏机、全球定位系统(GPS)接收器、或者便携式存储设备，例如，通用串行总线(USB)闪速存储器，仅举数例。

适合存储计算机程序指令和数据的计算机可读介质(适当的为瞬时或非瞬时)包括所有形式的非易失性存储器、介质和存储设备，作为示例，包括半导体存储设备，例如，可擦除可编程只读存储器(EPROM)、电可擦除可编程只读存储器(EEPROM)、以及闪速存储设备；磁盘，例如，内部硬盘或可移除盘；磁光盘；以及CDROM、DVD+/-R、DVD-RAM盘。存储器可以存储各种对象或数据，包括缓存、类别、框架、应用、备用数据、工作、网页、网页模板、数据库表格、储存器，存储业务和/或动态信息、以及包括任何参数、变量、算法、指令、规则、约束、或对它们的参考的任何其它适当的信息。此外，储存器可以包括任何其它适当的数据，诸如日志、政策、安全或访问数据、报告文件，以及其它数据。处理器和储存器可以由专用逻辑电路补充，或者整合到专用逻辑电路中。

为了提供与用户的互动，在本说明书中描述的主题的实施方式可以实施在计算机上，该计算机具有显示设备，例如，CRT(阴极射线管)、LCD(液晶显示器)、LED(发光二极管)、或等离子体监视器，用于向用户显示信息，该计算机还包括键盘和指定设备，例如，鼠标、跟踪球、跟踪板，用户能够通过其向计算机提供输入。也可以使用触摸屏向计算机提供输入，所述触摸屏诸如具有压力敏感性的平板计算机表面、使用电容或电感应的多点触摸屏、或者其它类型的触摸屏。其它种类的设备也可以用于提供与用户的互动；例如，提供给用户的反馈可以是任何形式的感觉反馈，例如，视觉反馈、听觉反馈、或者触觉反馈；以及来自用户的输入可以以任何形式接收，包括听觉、语音、或触觉输入。此外，计算机可以通过向用户使用的设备发送文件和从用户使用的设备接收文件来与用户进行互动；例如，通过响应于从网络浏览器接收的请求，向用户的客户端设备上的网络浏览器发送网页。

术语“图形用户界面”，或“GUI”可以以单数或复数使用，来描述一个或多个图形用户界面和特定图形用户界面的显示中的每一个。因此，GUI可以代表任何图形用户界面，包括但不限于，处理信息并向用户有效地展示信息的网络浏览器、触摸屏、或命令行界面(CLI)。一般，GUI可以包括多个用户界面(UI)元素，其中一些或全部与网络浏览器相关联，诸如商务套件用户可操作的互动字段、下拉式列表、以及按钮。这些和其它UI元素可以与网络浏览器的功能有关或代表网络浏览器的功能。

在本说明中描述的主题的实施方式可以以计算系统来实施，实施计算系统包括后端组件，例如，作为数据服务器，或者包括中间件组件，例如，应用服务器，或者包括前端组件，如，具有图形用户界面或网络浏览器的客户端计算机，用户通过其与本说明中描述的主题的实施方式互动，或者包括任何一个或多个这样的后端组件、中间件或前端组件的组合。系统的组件可以通过任何形式或介质的有线和/或无线数字数据通信来进行互动，例如，通信网络。通信网络的示例包括局域网(LAN)、无线接入网(RAN)、城域网(MAN)、广域网(WAN)、全球微波互联接入(WIMAX)、无线局域网(WLAN)，它们使用例如802.11a/b/g/n和802.20，互联网的而全部或部分，和/或在一个或多个地点的一个或多个任何其它的通信系统。例如，网络可以用网际协议(IP)分组、帧中继帧、异步传输模式(ATM)单元、语音、视频、数据、和/或网络地址之间的其它适当的信息。

计算系统可以包括客户端和服务器。客户端和服务器一般相互远离，并且典型地通过通信网络互动。客户端和服务器的关系根据运行在各个计算机上的计算机程序而产生，并且具有相互的客户端-服务器关系。

在一些实施方式中，计算系统的任何或全部组件，全部硬件和/或软件，可以互相互动，和/或使用应用编程接口(API)和/或服务层来交互(interface)。API可以包括用于路由、数据结构、以及对象类别的规范。API可以是独立或非独立的计算机语言，并且参考整个界面、单一功能、或者甚至是API的集合。服务层提供软件服务到计算系统。计算系统的各种组件的功能可以对于使用这个服务层的所有服务客户是可接入的。软件服务通过定义的界面提供可重复使用的、定义的业务功能。例如，界面可以是以JAVA、C++、或者以可扩展标记语言(XML)格式或其他适当格式提供数据的其它适当语言编写的软件。API和/或服务层可以是相对于计算系统的其它组件的整体和/或独立组件。而且，服务层的任何或全部部分可以实施为另一个软件模块、企业应用、或硬件模块的子类或子模块，而不脱离本公开的范围。

虽然本说明包含许多具体实施细节，这些不应被解释为对任何发明的范围或对可能要求保护的范围的限制，而是针对特定发明的特定实施方式的特征的描述。在本说明中在单独的实施方式的上下文中描述的某些特征还可以以单一实施方式的组合的方式来实施。相反地，在单一实施方式的上下文中描述的各种特征还可以以多个实施方式单独地实施或者以任何适当的子组合来实施。而且，虽然特征可以如上所述被描述为以某些组合来动作，并且即使是最初这样要求，但是所要求的组合中的一个或多个特征在一些情况下可以从所述组合中删除，并且所要求的组合可以指向子组合或子组合的变化。

类似的，虽然操作被以特定的次序描绘在附图中，这不应被理解为要求这样的操作以所示出的特定次序或以顺序的次序来执行，或者要求所有示出的操作都被执行，以实现所期望的结果。在某些环境下，多任务处理或并行处理可能是有益的。而且，上述实施方式中各种系统模块和组件的分离和/或整合不应当被理解为要求在所有实施方式中的这样的分离和/或整合，并且应当理解为所描述的程序组件和系统可以被一般地一起整合到单一的软件产品中或者包装到多个软件产品中。

已经描述了主题的特定实施方式。其它实施方式、以及所描述的实施方式的变化和置换在权利要求的范围内，这对于本领域技术人员是清楚的。例如，权利要求中列举的动作可以以不同的次序执行，并且仍将实现期望的结果。

因此，示例实施方式的以上描述没有定义或限制本公开。在不脱离本公开的精神和范围的情况下，其它改变、替代、以及变化也是可能的。

Claims

1.一种用于流程扩展的方法，包括：

对于与核心流程相关联的核心流程模型提供扩展点，扩展点被核心流程模型提供者预先定义和存储，并且用规定了在扩展点被插入到核心流程模型中的扩展的受限制的行为的约束来注释，扩展点以流程扩展约束定义语言制定并且允许扩展的运行时行为的限制，其中，流程扩展约束定义语言基于时间逻辑，并且以对于包括在流程扩展中的活动的扩展任务类型等级的公式约束的特定支持增强了现有属性规范模式；

由核心流程模型提供者将扩展点披露给核心流程模型的用户；

从用户接收将所选择的扩展插入到核心流程模型的实例中的指令，每个所选择的扩展包括在核心流程运行时对于将在相应的扩展点运行的扩展的用户定制的行为；以及

确认核心流程模型的实例，对于每个扩展，包括针对于由所述约束规定的受限制的行为，确认用户定制的行为，

其中，所述扩展点是包括在软件即服务(SaaS)、基于云的企业系统中的应用域的一部分，该基于云的企业系统扩展了由SaaS提供者提供给客户和伙伴的参考流程。

2.如权利要求1所述的方法，还包括在确认核心流程模型的实例之前，将核心流程变换为不同的格式。

3.如权利要求1所述的方法，其中，确认核心流程模型的实例包括，基于计算树逻辑(CTL)和属性规范模式的流程扩展模型检查。

4.如权利要求1所述的方法，其中，确认核心流程模型的实例包括使用指示用于扩展任务实例的确认规则的相关性和行为的约束语义。

5.一种用于流程扩展的系统，包括：

储存器，存储：

包括关于核心流程模型和相关联的扩展点的信息的数据存储；以及

用于提供指令的应用，包括：

为与核心流程相关联的核心流程模型提供扩展点，扩展点被核心流程模型提供者预先定义和存储，并且用规定了在扩展点被插入到核心流程模型中的扩展的受限制的行为的约束来注释，扩展点以流程扩展约束定义语言制定并且允许扩展的运行时行为的限制，其中，流程扩展约束定义语言基于时间逻辑，并且以对于包括在流程扩展中的活动的扩展任务类型等级的公式约束的特定支持增强了现有属性规范模式；

从用户接收将所选择的扩展插入核心流程模型的实例中的指令，每个所选择的扩展包括在核心流程运行时对于将在相应的扩展点运行的扩展的用户定制的行为；以及

确认核心流程模型的实例，对于每个扩展，包括针对于由约束规定的受限制的行为，确认用户定制的行为，

6.如权利要求5所述的系统，所述指令还包括：在确认核心流程模型的实例之前，将核心流程变换为不同的格式。

7.如权利要求5所述的系统，其中，确认核心流程模型的实例包括，基于计算树逻辑(CTL)和属性规范模式的流程扩展模型检查。

8.如权利要求5所述的系统，其中，确认核心流程模型的实例包括使用指示用于扩展任务实例的确认规则的相关性和行为的约束语义。

9.一种用计算机程序编码的非瞬时计算机可读介质，该程序包括当由一个或多个计算机运行时使得所述一个或多个计算机执行以下操作的指令：

10.如权利要求9所述的非瞬时计算机可读介质，所述指令还包括：在确认核心流程模型的实例之前，将核心流程变换为不同的格式。

11.如权利要求9所述的非瞬时计算机可读介质，其中，确认核心流程模型的实例包括，基于计算树逻辑(CTL)和属性规范模式的流程扩展模型检查。

12.如权利要求9所述的非瞬时计算机可读介质，其中，确认核心流程模型的实例包括使用指示用于扩展任务实例的确认规则的相关性和行为的约束语义。