CN1786995A - 基于时序逻辑的业务过程建模方法 - Google Patents

Abstract

本发明涉及一种面向领域应用支撑平台的业务过程建模方法，通过将业务过程分为工作流和业务规则两部分，给出了工作流和业务规则的相互融合准则，并且基于时序逻辑语义定义了工作流和业务规则中的基本元素，从而建立了由工作流和业务规则表示的、统一的、基于时序逻辑的业务过程模型。本发明为业务过程描述和分析提供形式化的、统一的和灵活的业务过程建模方法，适应面向领域应用支撑平台中不同领域业务过程建模的需要。

Description

基于时序逻辑的业务过程建模方法

技术领域

本发明涉及一种基于时序逻辑的业务过程建模方法，特别涉及一种通过工作流和业务规则相互融合来描述业务过程，并且利用时序逻辑作为工作流和业务规则一致描述语言的业务过程建模的方法，属于信息系统技术领域。

背景技术

现代领域应用信息管理系统非常复杂，为了降低系统的复杂性和适应业务应用的多变性，领域应用系统一般采用分层的体系结构，即系统结构层次可以分为操作系统、中间件、领域应用公共支撑平台和特定的领域应用，同时还包括贯穿各个层次的质量保证体系和安全保证体系。在上述各个层次中，介于操作系统或中间件平台之上的领域应用公共支撑平台是构建领域应用的关键，平台中包括了创建领域应用的组件。一般来说，领域应用中业务组件的提炼应该具备粒度适中、简单、可重用、独立和技术上的现实性特点，并且可以方便地应用于领域业务的自动化，因此，业务过程建模组件成为领域应用支撑平台的核心组件。

业务过程建模组件提供了结构化的框架来描述领域应用中的知识，根据领域知识组织方式的不同可以从两方面来刻画业务过程，一是工作流部分，表示业务过程中的控制流，主要用于过程的自动化；另一是业务规则部分，表示业务过程中的事实及其相互关系和状态，主要用于与业务过程相关的领域知识推理。

形式化的业务过程模型能一定程度上提高模型的准确性和质量，可以用于业务过程的分析和验证，因此得到了广泛的重视。一般来说，根据对业务过程理解和描述方式的不同，业务过程形式化建模方法至少可分为Petri网、事件代数和时序逻辑三类：Petri网建模方法把业务过程的执行结果看作是活动动作触发状态变化的序列，并用位置表示活动状态或条件，变迁表示活动动作；事件代数建模方法认为业务过程的执行是活动事件变化的过程，并用代数的方式表示活动事件之间的依赖关系。总的来说，Petri网模型具有直观的图形表示和强的数学分析能力，但不能表达全局状态中业务过程中活动之间的控制依赖关系；事件代数模型适于推理事件之间的约束，但不能表达业务过程中活动状态变化之间的条件约束。时序逻辑模型一定程度上避免了上述两个模型中的不足，具有成熟的验证和分析方法，并且可以自然地统一表达工作流和业务规则，因而将其用于业务过程建模具有重要的意义。我们在目前公开的专利文献中未发现时序逻辑在业务过程建模方面的应用。

发明内容

本发明的主要目的在于提供一种基于时序逻辑的业务过程建模方法，为业务过程描述和分析提供形式化的、统一的和灵活的基于时序逻辑的建模方法。

本发明的另一目的在于提供一种基于时序逻辑的业务过程建模方法，支持领域应用支撑平台中工作流和业务规则的统一建模，从而可以从工作流和业务规则两方面描述领域应用。

为了达到上述发明目的，本发明提供了一种基于时序逻辑的业务过程建模方法，根据时序逻辑的语法和语义对业务过程进行建模，其特征在于，至少包括以下步骤：

步骤A、根据组织方式对业务过程进行分类，一是工作流部分，表示业务过程中的控制流；另一是业务规则部分，表示业务过程中的事实及其相互关系和状态，并且，对工作流部分，确定各活动状态以及活动状态基本依赖结构；

步骤B、构建时序逻辑表示的工作流基本结构算子，并且建立根据工作流基本结构算子描述工作流的方法；构建时序逻辑表示的业务规则基本元素，并且建立根据业务规则基本元素描述业务规则方法；

步骤C、利用步骤A中的活动状态基本依赖结构和步骤B中的工作流基本结构算子，建立时序逻辑表示的状态基本依赖结构及活动状态依赖；根据步骤B中的业务规则基本元素，建立时序逻辑表示的业务规则；

步骤D、建立业务规则和工作流交互准则，实现根据业务规则返回结果确定工作流执行方式。

较佳的，步骤A中所述工作流，定义了业务过程中活动状态之间的依赖关系，活动是业务过程中的最小粒度单元，每个活动至少包括非激活、激活、取消和完成四种状态；步骤A中所述业务规则定义了业务过程中动态易变的领域知识，包括两类，一类是与活动状态变迁相关的规则，包括变迁条件和活动状态的结束规则；另一类是与活动状态相关的领域应用规则；步骤A所述活动状态之间基本依赖结构分为汇聚依赖结构和分支依赖结构。

较佳的，步骤A中确定各活动状态以及活动状态基本依赖结构的步骤是：

1)建立业务过程中的活动列表，确定每个活动的状态及属性；

2)定义业务过程中活动状态之间的基本依赖结构，所述基本依赖结构包括顺序、汇聚、分支关系，根据业务过程，将各活动列表中的活动的不同状态之间建立基本依赖结构；

3)根据业务过程中活动列表和活动状态之间的基本依赖结构，确定业务中活动状态变迁的基本控制结构。

较佳的，步骤A中定义业务规则的步骤是：

1)根据各活动变迁之间的约束关系，定义条件规则；所述条件规则包括条件表达式和条件表达式为真时的执行动作；

2)定义活动状态关联的领域应用规则，所述领域应和规则包括事件名称、条件表达式、执行动作，其中事件名称表示活动状态关联的具体事件。

较佳的，步骤B中所述时序逻辑表示的工作流基本结构算子至少包括异步与汇聚、异步或汇聚、同步与汇聚、与分支、或分支和异或分支，采用区间时序逻辑；步骤B中所述的时序逻辑表示的业务规则基本元素包括事件名称、条件表达式和动作名称。

较佳的，步骤B中所述建立根据工作流基本结构算子描述工作流的方法，是指根据区间时序逻辑表示的工作流基本结构算子，以及活动状态之间的依赖结构，将活动状态之间的依赖结构用工作流基本结构算子来描述；步骤B中所述业务规则包括条件规则和事件/条件/动作规则，其中，条件规则用蕴含式表达，前件为区间时序逻辑表示的条件表达式，后件是区间时序逻辑表示的动作名；事件/条件/动作规则用蕴含式表达，前件为区间时序逻辑表示的条件表达式和事件名的合取，后件为区间时序逻辑表示的动作名。

较佳的，步骤D中所述业务规则与工作流交互准则包括：基于业务规则返回结果来控制工作流执行的准则。

较佳的，步骤D中进一步包括，确定工作流中活动触发业务规则的事件点准则，还包括确定业务规则与工作流的接口准则。

本发明通过将业务过程分为工作流和业务规则两部分，并确定出工作流和业务规则的融合准则，基于时序逻辑，建立了由工作流和业务规则表示的、统一的、基于时序逻辑的业务过程模型。本发明为业务过程描述和分析提供了形式化的、统一的、灵活的业务过程建模方法，适应领域应用支撑平台中不同领域业务过程建模的需要。

附图说明

下面结合附图和具体实施方式对本发明作进一步的说明。

图1为本发明实施过程的总体流程示意图。

图2是将本发明所述方法应用于具体的软件测试过程的示意图。

具体实施方式

本发明提供了一种基于时序逻辑的业务过程建模方法。本发明将业务过程分为工作流和业务规则两部分，分别定义用时序逻辑表示的工作流和业务规则的基本结构和基本元素，并且建立了工作流和业务规则的互操作规则，从而建立了用工作流和业务规则统一表示的业务过程建模方法。

下面结合图1和图2，以某企业中一个具体的软件测试过程来说明本发明的实施步骤。

在一个软件测试过程中，测试流程中包括下述活动：总体测试计划制定、需求评审、迭代测试计划制定、迭代测试计划评审、单元测试设计、系统测试设计、集成测试设计、单元测试、系统测试、集成测试和测试结果分析。上述测试流程中，总体测试计划制定、需求评审和迭代测试计划制定顺序执行，同时，在迭代测试计划评审活动变迁至完成状态后，单元测试设计、系统测试设计和集成测试设计同时变迁为激活状态，并且只有单元测试、系统测试和集成测试都变迁至完成状态后，测试结果分析才能变迁至激活状态；各个活动状态只能在确定的时间段内发生，超过确定时间段活动状态的变迁则无意义；另外，需求评审活动和迭代测试计划评审活动分别生成需求评审报告和测试评审报告，同时，在单元测试、系统测试和集成测试活动的激活状态中，活动分别触发不同的函数/方法/程序进行测试，同时，单元测试、系统测试和集成测试变迁至取消状态时，则其分别返回至单元测试设计、系统测试设计和集成测试设计的激活状态，直至其变迁至完成状态激活测试结果分析活动，或者违反时间约束终止测试过程。为了便于说明，在下面的实施例中，只针对特定活动的某个状态进行举例。

本发明的实现过程如下：

步骤1：根据组织方式对业务过程进行分类，一类是工作流部分，表示业务过程中的控制流；另一类是业务规则部分，表示业务过程中的事实及其相互关系和状态。

活动是业务过程中的最小粒度单元，每个活动具有标识、名称、类型、参与者和活动相关数据属性；工作流定义了业务过程中活动状态之间的依赖关系。

业务规则定义了业务过程中动态易变的领域知识，包括两类，一类是与活动状态变迁相关的规则，包括变迁条件和活动状态的结束规则；另一类是与活动状态相关的领域应用规则。

在本实施例中，将软件测试业务过程进行分类，分为工作流和业务规则两部分，建立业务过程中的活动列表。活动列表中的活动包括：总体测试计划制定、需求评审、迭代测试计划制定、迭代测试计划评审、单元测试设计、系统测试设计、集成测试设计、单元测试、系统测试、集成测试和测试结果分析。

步骤2：设定工作流中各活动状态及活动状态之间的基本依赖结构。各活动具有活动的类型、参与者、活动相关数据以及活动之间的依赖关系。每个活动包括非激活(Inactive)、激活(Active)、取消(Cancelled)和完成(Completed)四种状态，例如总体测试计划制定活动的类型为手动活动，参与者为PA₁，活动相关数据为V₁。活动状态之间依赖结构除顺序之外，分为汇聚依赖和分支依赖结构，而汇聚结构又可以进一步分为异步与、异步或和同步与三种形式，分支结构可进一步分为与、或和异或结构三种形式。也就是说，可以将活动状态之间基本依赖结构分为顺序、异步与汇聚、异步或汇聚、同步与汇聚、与分支、或分支、异或分支七类，由此建立活动列表中活动的不同状态之间的依赖关系结构。

图2中显示了本实施例中各活动状态之间的依赖关系结构，例如总体测试计划制定完成与需求评审激活状态之间存在顺序依赖结构关系，迭代测试计划评审完成与单元测试设计激活、系统测试设计激活、集成测试设计激活之间存在与分支结构依赖关系。

步骤3：建立根据活动状态表示的业务过程基本控制结构。由业务过程中活动列表以及活动状态之间的依赖关系，确定业务过程中活动状态变迁的顺序、并行、分支和汇聚基本控制结构。

本实施例中，用活动状态表示的业务过程控制结构与图2类似，在此不重复。图中节点分别表示活动的激活或完成状态。

步骤4：构建时序逻辑表示的工作流基本结构算子，并建立根据工作流基本结构算子描述工作流的方法。

时序逻辑表示的工作流基本结构算子至少包括：异步与汇聚、异步或汇聚、同步与汇聚、与分支、或分支、异或分支，时序逻辑基本结构算子的复合可以表示复杂的控制流。通过六类基本时序逻辑结构算子的组合，可以描述业务过程的控制结构。本实施例中，时序逻辑类型具体采用区间时序逻辑。

基于区间时序逻辑的工作流部分描述方法为：

步骤5.1根据区间时序逻辑的语法和语义，定义区间时序逻辑表示的工作流基本结构算子。区间时序逻辑中基本时序算子包括：将来时序算子、必然时序算子、终于时序算子，另外，为了适应工作流中过去时间表达，根据区间时序逻辑的“切变”操作定义扩充的时序算子：曾经算子。根据基本和扩充的时序算子，定义区间时序逻辑表示的工作流基本结构算子：顺序、异步与汇聚、异步或汇聚、同步与汇聚、与分支、或分支、异或分支。

步骤4.2根据区间时序逻辑表示的工作流基本结构算子，给出区间时序逻辑表示的工作流。通过步骤2中建立的活动状态之间的依赖关系，以及时序逻辑表示的工作流基本结构算子，将活动状态之间的依赖关系用时序逻辑表示的工作流基本结构进行描述。工作流就表示为上述基本结构算子的组合。

本实施例中，步骤4.1定义区间时序逻辑表示的工作流基本结构算子，举例为，建立异步与汇聚结构算子：

相应地，步骤4.2中根据工作流基本结构算子表示工作流，例如，总体测试计划制定完成状态和需求评审激活状态之间的流程关系，可以用异步与汇聚结构算子表示为：

步骤5：确定工作流中各个活动状态的事件点触发准则

所述工作流中活动触发业务规则的事件点至少包括两类，一类是固定事件点，即在每个活动中预先设定业务规则的触发事件点，在每个事件点根据条件判断是否触发规则；一类是动态事件点即通过事件管理器设定每个活动的触发事件点，并且触发事件点可以随时调整。所述工作流中活动触发业务规则的事件点定义方法为：

步骤5.1工作流中活动触发业务规则的固定事件点定义方法为：每个活动状态包括三个事件触发点，分别是活动状态变迁开始前、活动状态变迁进行中和活动状态变迁完成后。条件规则默认的事件触发点为活动状态变迁完成后，ECA规则默认的事件触发点为活动状态变迁进行中。

步骤5.2工作流中活动触发业务规则的动态事件点定义方法为：定义事件管理器，事件管理器中包括事件监听部分和事件关联部分，其中事件监听部分又包括事件监听名称、事件监听标识，事件关联部分包括活动状态名、事件点和事件监听标识；其次，根据活动状态的操作和相关数据的可能变化点，定义不同的活动状态特征点作为潜在的事件点；最后，建立事件点和活动状态特征点之间的映射。

本实施例中定义活动状态的固定触发事件点，为每个活动状态定义三个事件触发点：活动状态变迁开始前、活动状态变迁进行中和活动状态变迁完成后，同时设定条件规则的触发事件点为活动状态变迁完成后。本实施例定义的动态触发事件点的类似于固定触发事件点定义，只是需要建立事件点和相应活动状态的关联。

步骤6：根据步骤2-5，建立用时序逻辑表示的状态基本依赖结构及活动状态依赖。

在步骤1根据组织方式对业务过程进行分类之后，得到了工作流和业务规则两部分。前面讲述了对工作流部分的处理流程；下面将结合图1和图2讲解对业务规则部分的处理。需要说明的是，对业务规则的处理与工作流的处理是同时进行的。

在步骤1中定义的业务规则部分，至少包括：条件规则和ECA(事件/条件/动作event/condition/action)规则。其中条件规则基本元素条件表达式和动作名，ECA规则基本元素包括事件名、条件表达式和动作名。

接续步骤1之后，对业务规则的处理过程如下：

步骤12：定义所述的业务过程中业务规则中的条件规则和ECA规则。包括：

步骤12.1根据活动状态变迁之间的约束，定义条件规则。条件规则包括两部分，一是条件表达式，另一是条件表达式为真时的执行动作，其中条件表达式中符号包括变量、常数、关系符号和算术符号，执行动作包括触发的函数名、活动状态名；

步骤12.2定义活动状态关联的领域应用规则。领域应用规则包括三部分，其一是事件名称，其二是条件表达式，其三是执行动作，其中事件名表示活动状态关联的具体事件，条件表达式和动作名的含义与步骤12.1中相同；

本实施例中，定义条件规则，例如，定义“if V₁＝’true’then AS₂(I)”表示：活动相关数据V₁为真(true)时，则活动AS₂变迁至激活状态。定义活动状态关联的应用规则，例如用“event：e(AS₂(C))condition：V₂＝’true’action：create(reuqirereport)”表示：需求评审活动在完成状态时触发事件e(AS₂(C))，由此检测条件V₂＝’true’是否满足，条件满足情况下生成需求评审报告。

步骤13：确定时序逻辑表示的业务规则的基本元素，并且建立根据业务规则基本元素描述业务规则的方法。

时序逻辑表示的业务规则分为两部分：条件规则和ECA规则，时序逻辑表示的规则基本元素包括：条件表达式、事件名、动作名；这样，可以通过时序逻辑基本元素来描述业务规则。本实施例中，时序逻辑具体采用区间时序逻辑类型来表示。基于区间时序逻辑的业务规则部分具体表示方法为：

步骤13.1根据区间时序逻辑的语法和语义，定义业务规则的基本元素。业务规则中的事件名和动作名用区间时序逻辑中的静态变元或状态变元表示，条件表达式用区间时序逻辑的公式来定义；

步骤13.2根据区间时序逻辑表示的业务规则基本元素，给出业务规则描述。业务规则包括：条件规则和ECA规则，条件规则用一阶谓词逻辑蕴含式表达，其中蕴含式的前件为区间时序逻辑表示的条件表达式，蕴含式的后件为区间时序逻辑表示的动作名；ECA规则用一阶谓词逻辑蕴含式表达，其中蕴含式的前件为区间时序逻辑表示的条件表达式和事件名的合取，蕴含式的后件为区间时序逻辑表示的动作名。

本实施例中，定义区间时序逻辑表示的规则基本元素，其基本元素分别使用状态变元、项以及蕴涵式表示，例如： 本实施例中，定义区间时序逻辑表示的业务规则描述时，对于步骤12.1中的条件规则使用区间时序逻辑可以表示为：

步骤14：确定业务规则与工作流的接口准则。

所述业务规则与工作流接口准则至少包括：业务规则的返回值类型准则；工作流与业务规则返回值的映射准则；工作流中业务规则返回值的操作准则。

所述业务规则与工作流接口准则的定义方法为：

步骤14.1定义业务规则的返回值类型。业务规则的返回值类型定义了工作流和业务规则数据交互的数据类型，至少包括：数值类型、字符类型和布尔类型。

步骤14.2定义工作流与业务规则返回值的映射方法。根据业务规则的返回类型，定义相同类型的工作流相关数据，并且通过工作流相关数据得到业务规则的返回值。

步骤14.3定义工作流中业务规则返回值的操作方法。在工作流相关数据得到业务规则返回值后，业务规则可以通过工作流相关数据确定流程的运作顺序，或者作为流程的中间数据而传递到后续活动状态。

本实施例中，步骤14.1中定义业务规则的返回值类型为int、string型。步骤14.2中定义工作流与业务规则返回值的映射方法，使业务规则返回值映射为工作流相关数据，例如：对于步骤14.1中的规则返回值create(requirereport)，可以将其赋给状态变量V′，即

本实施例中步骤14.2中状态变量V′得到规则返回值后，在步骤14.3中处理方法即相同于一般的工作流相关数据。

步骤15：建立业务规则和工作流的交互处理方法。

业务规则和工作流的交互处理方法至少包括：工作流和业务规则交互的模式；工作流中不同业务活动类型的执行方式；工作流执行中业务规则的异常处理准则。

所述业务规则和工作流的交互处理具体方法为：

步骤15.1设定工作流和业务规则的交互模式。工作流和业务规则存在两类交互模式：同步和异步，其中同步模式是在工作流中活动的事件状态触发点上，在得到事件的返回值后，工作流才能创建新的活动状态实例；异步模式是在工作流中活动的事件状态触发点上，在规则触发后，工作流可以继续创建新的活动状态实例，而不必等规则的返回值，在流程后续的某个活动状态的事件点，工作流得到业务规则的返回值，从而能够根据返回值确定流程的活动状态变迁。

步骤15.2根据工作流中不同活动类型设定业务规则的执行方式。活动类型分为自动活动和手动活动，业务规则的触发类型也分为自动触发和手动触发。一般来说，自动活动类型的业务规则为自动触发，手动活动类型的业务规则为手动触发，其中手动触发类型的业务规则需要业务过程参与者来触发规则，规则执行完成后根据结果自动推进流程；另外，手动活动也可以定义自动触发规则，但自动活动不能定义手动触发规则。

步骤15.3定义工作流执行中业务规则的异常处理方法。工作流中所处理的业务规则异常包括两类：一类是时间异常，即在规定的时间内业务规则无返回值；另一类是执行异常，即业务规则的返回值类型与工作流相关数据不匹配，或者业务规则的返回值错误。对于上述异常，工作流中处理方式有两类：一类是忽略异常，即工作流继续执行，而不考虑规则的返回异常；另一类是中断执行，即在得到业务规则的返回异常后，工作流立即结束执行。

在图2所示实施例中，步骤15.1中设定工作流和业务规则的交互模式，可以是，在需求评审激活状态中设定同步交互模式，即只有在得到规则返回值后才可以触发迭代测试计划制定为激活状态。步骤15.2中设定业务规则的执行方式的一例为：对于需求评审为手动活动，则设定步骤15.2定义活动状态关联的领域应用规则为手动触发规则。步骤15.3定义规则的异常处理方式。不同的活动状态需要定义不同的异常处理方式，对于需求评审活动的激活状态异常处理定义为中断执行。

步骤16：根据步骤12-15，建立用时序逻辑表示的条件规则和ECA规则。与步骤7类似，用步骤13中确定的时序逻辑表示的条件规则和ECA规则基本元素来描述条件规则和ECA规则。

至此，本发明所述的利用时序逻辑作为统一的描述语言对业务过程的工作流和业务规则两部分进行表示。接下来，在步骤7中，可以利用步骤6中得到的时序逻辑表示的状态基本依赖结构及活动状态依赖，还有步骤16中得到的时序逻辑表示的条件规则和ECA规则，按照步骤15中确定的业务规则和工作流交互准则，实现根据业务规则返回结果确定工作流执行方式。这样就实现了利用时序逻辑作为统一的描述语言对业务过程的工作流和业务规则两部分进行建模。

上面对本发明所述的基于时序逻辑的业务过程建模方法进行了详细的说明，但显然本发明的具体实现形式并不局限于此。对于本技术领域的一般技术人员来说，在不背离本发明所述方法的精神和权利要求范围的情况下对它进行的各种显而易见的改变都在本发明的保护范围之内。

Claims (10)

1.一种基于时序逻辑的业务过程建模方法，根据时序逻辑的语法和语义对业务过程进行建模，其特征在于包括以下步骤：

步骤A：根据组织方式对业务过程进行分类，一是工作流部分，表示业务过程中的控制流；另一是业务规则部分，表示业务过程中的事实及其相互关系和状态，并且，对工作流部分，确定各活动状态以及活动状态基本依赖结构；

步骤B：构建时序逻辑表示的工作流基本结构算子，并且建立根据工作流基本结构算子描述工作流的方法；构建时序逻辑表示的业务规则基本元素，并且建立根据业务规则基本元素描述业务规则方法；

步骤C：利用步骤A中的活动状态基本依赖结构和步骤B中的工作流基本结构算子，建立时序逻辑表示的状态基本依赖结构及活动状态依赖；根据步骤B中的业务规则基本元素，建立时序逻辑表示的业务规则；

步骤D：建立业务规则和工作流交互准则，实现根据业务规则返回结果确定工作流执行方式。

2.如权利要求1所述的基于时序逻辑的业务过程建模方法，其特征在于：

步骤A中所述工作流，定义了业务过程中活动状态之间的依赖关系，活动是业务过程中的最小粒度单元，每个活动至少包括非激活、激活、取消和完成四种状态；步骤A中所述业务规则定义了业务过程中动态易变的领域知识，包括两类，一类是与活动状态变迁相关的规则，包括变迁条件和活动状态的结束规则；另一类是与活动状态相关的领域应用规则；步骤A所述活动状态之间基本依赖结构分为汇聚依赖结构和分支依赖结构。

3.如权利要求2所述的基于时序逻辑的业务过程建模方法，其特征在于：

步骤A中确定各活动状态以及活动状态基本依赖结构的步骤是：

1)建立业务过程中的活动列表，确定每个活动的状态及属性；

2)定义业务过程中活动状态之间的基本依赖结构，所述基本依赖结构包括顺序、汇聚、分支关系，根据业务过程，将各活动列表中的活动的不同状态之间建立基本依赖结构；

3)根据业务过程中活动列表和活动状态之间的基本依赖结构，确定业务中活动状态变迁的基本控制结构。

4.如权利要求2所述的基于时序逻辑的业务过程建模方法，其特征在于：

步骤A中定义业务规则的步骤是：

1)根据各活动变迁之间的约束关系，定义条件规则；所述条件规则包括条件表达式和条件表达式为真时的执行动作；

2)定义活动状态关联的领域应用规则，所述领域应和规则包括事件名称、条件表达式、执行动作，其中事件名称表示活动状态关联的具体事件。

5.如权利要求2所述的基于时序逻辑的业务过程建模方法，其特征在于：

步骤B中所述时序逻辑表示的工作流基本结构算子至少包括异步与汇聚、异步或汇聚、同步与汇聚、与分支、或分支和异或分支，采用区间时序逻辑；步骤B中所述的时序逻辑表示的业务规则基本元素包括事件名称、条件表达式和动作名称。

6.如权利要求5所述的基于时序逻辑的业务过程建模方法，其特征在于：

步骤B中所述建立根据工作流基本结构算子描述工作流的方法，是指根据区间时序逻辑表示的工作流基本结构算子，以及活动状态之间的依赖结构，将活动状态之间的依赖结构用工作流基本结构算子来描述；步骤B中所述业务规则包括条件规则和事件/条件/动作规则，其中，条件规则用蕴含式表达，前件为区间时序逻辑表示的条件表达式，后件是区间时序逻辑表示的动作名；事件/条件/动作规则用蕴含式表达，前件为区间时序逻辑表示的条件表达式和事件名的合取，后件为区间时序逻辑表示的动作名。

7.如权利要求1所述的基于时序逻辑的业务过程建模方法，其特征在于：

步骤D中所述业务规则与工作流交互准则包括：基于业务规则返回结果来控制工作流执行的准则。

8.如权利要求7所述的基于时序逻辑的业务过程建模方法，其特征在于：

步骤D中进一步包括，确定工作流中活动触发业务规则的事件点准则，还包括确定业务规则与工作流的接口准则。

9.如权利要求8所述的基于时序逻辑的业务过程建模方法，其特征在于：

所述工作流中活动触发业务规则的事件点准则至少包括两类，一类是固定点准则，即在每个活动中预先设定业务规则的触发事件点，在每个事件点根据条件判断是否触发规则；再一类是动态定义准则，即通过事件管理器设定每个活动的触发事件点，并且触发事件点可以随时调整。

10.如权利要求8所述的基于时序逻辑的业务过程建模方法，其特征在于：

所述业务规则与工作流接口准则至少包括：业务规则的返回值类型准则；工作流与业务规则返回值的映射准则；工作流中业务规则返回值的操作准则。

Images