基于对象中心行为约束的声明式数据感知流程建模与推理

### 基于对象中心行为约束的声明式数据感知流程建模与推理 #### 引言 在业务流程建模领域，尽管存在众多的符号表示法，但使用像业务流程模型和符号（BPMN）、事件驱动流程链（EPC）以及UML活动图等主流符号来捕捉现实生活中的流程，对流程建模人员来说仍是一项挑战。这些符号通常需要简化假设，即每个流程模型专注于一个单一的、明确定义的案例概念（也称为流程实例）。当使用流程挖掘技术基于可用数据重构流程时，这种单一案例视图与现实之间的差异就变得十分明显。流程挖掘从可用数据开始，除非使用业务流程管理（BPM）或工作流管理（WFM）系统来执行流程，否则通常缺少明确的案例信息。 以BPMN、EPC或UML为代表的以流程为中心的图表描述了单个案例的生命周期。当使用像Petri网、自动机和进程代数等形式语言来描述业务流程时，它们往往孤立地建模案例，数据视角是次要的，甚至完全缺失。像BPMN这样的语言允许建模人员将数据附加到流程中，但无法对这些数据表达复杂的约束（例如，像ER/UML/ORM数据模型中的基数约束、继承关系、不相交性、覆盖等）。主流的业务流程建模符号一次只能描述一种类型的流程实例的生命周期，错过了捕捉多个相互作用实例共同演化的机会。特别是，附加到流程的数据上的复杂约束必须影响流程本身的行为，例如，在不同订单的管理中，一个订单的演变会影响相关订单的可能演变。 为了解决这些问题，对象中心行为约束（OCBC）模型被提出。它是一种结合了声明式、基于约束的语言（如DECLARE）和数据建模语言思想的建模语言。OCBC具有以下优势： - 能够在统一的框架中描述给定流程中活动之间的时间交互，并将（结构化）数据附加到流程中。 - 可以对多个流程实例之间的交互进行建模，特别是当它们之间存在一对多或多对多关系时。 例如，“注册电子邮件”和“发送邀请”是分别与对象类“人员”和“会议”相关的两个活动。一个会议由许多人组织，每个人又可以组织许多会议。连接“注册电子邮件”和“发送邀请”的双向箭头表示约束，即只有当该会议的至少一名组织者先前注册了她的电子邮件时，才能发送会议邀请。这个简单的例子已经包含了两个相互交织的不同案例概念（人员和会议）。在传统符号中，这只能从两个实例之一的角度进行建模：人员的注册过程或会议的邀请过程。使用像BPMN这样的传统符号从后者的角度进行建模，需要明确引入一个循环来处理组织会议的一个或多个人的注册。然而，这是不正确的，因为一次注册可能会引发多个会议。一对多和多对多关系会导致收敛和发散问题，这些问题无法在描述孤立案例的符号中得到处理。 OCBC模型与以工件和数据为中心的方法相关，这些方法旨在集成数据和流程。但不同的是，OCBC在一个单一的图表中表示不同类型的流程实例及其交互。此外，这些方法通常假设对数据有完整的了解，并在指定活动时需要完全详细地说明数据更新。少数处理具有不完全知识的以工件为中心的模型的提案，没有像这里一样提供一个完全集成的声明式语义，而是遵循Levesque功能方法，将系统的演变与每个状态中（不完全）知识的检查分开。 本文对OCBC方法的形式语义进行了完整的刻画，明确地定义了OCBC约束的逻辑含义。我们为OCBC提供了可视化和文本语法，然后根据时态描述逻辑（即著名的OWL语言的时态扩展）来定义不同建模构造的语义。这种形式化反过来使我们能够将为无数据的基于约束的流程建模符号定义的所有推理服务提升到更复杂的OCBC场景中。特别是，我们展示了如何将对OCBC模型的推理重新表述为对相应时态描述逻辑知识库的可判定的标准推理任务，为流程及其操作数据的推理的可判定性和复杂性边界奠定了坚实的基础。 #### 运行示例 我们的提案背后的驱动假设是，流程被建模为其操作数据的镜像。这些数据根据复杂的数据建模约束进行结构化。数据可以附加到活动上，并且可以在这些操作数据上表达临时引用约束，描述活动如何共享/重用相同的数据对象。 例如，有一个由五个活动（创建订单、挑选物品、包装物品、支付订单和交付物品）和数据模型中的五个对象类（订单、订单行、交付、产品和客户）组成的OCBC模型。该模型的上部描述了活动的时间顺序，下部描述了与流程执行相关的对象的结构（可以将下部视为标准的UML类图），中间层（虚线）将活动和数据联系起来。以下是对模型中突出构造的非正式描述： 1. **创建订单与订单的关系**：“创建订单”活动与“订单”之间存在一对一的对应关系，即“创建订单”活动的执行会创建一个唯一的“订单”，反之，由于“创建订单”侧的“1”，每个“订单”都是由“创建订单”活动的单次执行生成的。 2. **挑选物品与订单行的关系**：“挑选物品”活动的每次执行都引用一个唯一的“订单行”，并且每个“订单行”都是由“挑选物品”活动的执行生成的（而不是由“包装物品”活动生成）。 3. **创建订单与支付订单的顺序**：每个“创建订单”活动之后恰好跟随一个（单箭头）与同一订单相关的“支付订单”活动。 4. **支付订单与挑选物品的顺序**：每个“支付订单”活动之前可能有多个（双箭头）“挑选物品”活动。 5. **支付订单后不再挑选物品**：当执行“支付订单”活动时，将不会再对同一已支付订单执行“挑选物品”活动。 6. **订单的支付约束**：虚点线表示对对象类的临时引用约束，规定当“创建订单”创建一个订单实例时，该订单实例最终将通过执行“支付订单”活动来支付。 7. **订单行与订单的关系约束**：虚点线在这种情况下是对关系的临时引用约束，规定当填充一个订单行时，它必须包含在通过执行“创建订单”活动创建的恰好一个订单中。由于在创建订单实例时订单行实例不可能同时存在，并且关系是由共存的对象实例化的，UML模型正确地指定了在每个时间点，每个订单在“包含”关系中参与零次或多次。另一方面，临时引用约束以及强制的基数约束和“创建订单”、“支付订单”和“挑选物品”之间的时间约束意味着任何给定订单中最终会存在至少一个订单行。 8. **已支付订单的约束**：以“×”开头的虚点线表示负临时引用约束，禁止对已通过“支付订单”活动关闭的订单填充更多的订单行。 OCBC流程的一种可能执行情况，称为跟踪片段，会同时记录事件、它们的执行时间以及它们操作的对象。此外，它还捕获在给定时间戳下关于这些对象已知的事实，特别是对象所属的类以及对象之间的关系。跟踪片段遵循标准的一阶逻辑设置，捕获关于流程执行的不完全知识，并且OCBC约束因此在开放世界语义下进行解释。这意味着一个跟踪片段符合OCBC模型，如果它可以扩展为满足其中所有约束的完整跟踪。一个符合上述OCBC模型的跟踪片段可以用以下一阶逻辑符号表示： ``` CO(co1, t0), PI(pi1, t1), PI(pi2, t2), WI(wi1, t3), WI(wi2, t4), PI(pi3, t5), WI(wi3, t6), PO(po1, t7), DI(di1, t8), DI(di2, t9), creates(co1, o1, t0), fills(pi1, ol1, t1), contains(o1, ol1, t1), fills(pi2, ol2, t2), contains(o1, ol2, t2), prepares(wi1, ol1, t3), prepares(wi2, ol2, t4), fills(pi3, ol3, t5), contains(o1, ol3, t5), prepares(wi3, ol ```