CN1924908A

CN1924908A - 规则遵守状况检测方法以及相关检测系统

Info

Publication number: CN1924908A
Application number: CNA2005100934801A
Authority: CN
Inventors: 刘�英; 王健; 周欣; 朱俊; 布尔吉特·菲兹曼; 梁海奇; 黄英
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2005-08-30
Filing date: 2005-08-30
Publication date: 2007-03-07
Also published as: US7496552B2; US20070094202A1; US20080301080A1; US7853549B2

Abstract

本发明提供一种规则遵守状况检测方法，其中包括以下步骤：a)为预定的规则建立规则模型，并且为业务流程建立业务运营模型；b)对规则模型和业务运营模型的词汇进行标准化；c)检测规则模型是否被业务运营模型所满足；d)产生并输出检测结果报告。本发明还提供一种相应的规则遵守检测系统。通过本发明的规则遵守检测允许用户快速有效的完成规则遵守自动检测，并且极大程度上地避免了检测过程中人为因素的干扰，从而保证了检测结果的准确性。

Description

规则遵守状况检测方法以及相关检测系统

技术领域

本发明涉及对是否遵守规则的检测，更特别地，涉及对业务流程是否遵守预定规则的检测方法、装置以及实现检测方法的计算机程序产品。

背景技术

无论处在哪个行业，几乎每个企业都需要面对众多可能影响其企业决策的规则。例如，任何企业在业务运营中都需要遵守其所在国家的法律法规以及所属行业制定的行规惯例等；企业通常也会为其自身制定一些具体规定以便更加有效地管理运营；此外，如果企业需要进行国际贸易，还必须遵守一些国际协定或准则。企业在运营过程中应该保证遵守这些规则，这不仅是由于企业的监管部门经常会审查其对法律法规等的遵守情况，还由于遵守这些规则能够保护企业自身的合法利益。因此，是否遵守这些规则对企业的业务运营十分重要。

目前，通常由人手动检测企业的业务运营是否遵守各种规则。在检测过程中，需要一个或一组精通各种法律法规以及企业业务运营的专职人员，采用某种方法以手动的方式对业务运营和预定规则进行逐一比对或判断。

这种依赖于人的经验和判断的传统方法每次只能检测一个业务运营过程对相应规则(法律法规)的遵守状况，因此不利于对多个业务运营过程进行多次检测。而且，这种手动的检测很难或者根本无法有效地复用此前检测中产生的信息资源。例如，同一条规则在对不同的业务运营过程进行遵守状况检测的过程中可能会被重复地分析。此外，最关键的是，手动进行的检测会受到人为因素的影响。由于具体操作人员在经验、认知以及熟练程度上的差异，所得出的遵守检测报告的结果可能不尽相同。这使得该报告的可信度和准确度大打折扣。

综上所述，现有技术中检测业务运营是否遵守预定规则的手动机制存在很多固有的缺陷，它不能满足现代企业在规则遵守检测报告的准确性以及检测过程的高效性等方面的更高需求。

发明内容

为了克服现有技术中存在的缺陷，本发明提供一种能够自动检测业务运营是否遵守预定规则的方法、装置以及实现该方法的计算机程序产品。

根据本发明的一个方面提供一种规则遵守状况检测方法，其中包括以下步骤：a)为预定的规则建立规则模型，并且为业务流程建立业务运营模型；b)对规则模型和业务运营模型中的词汇进行标准化；c)检测规则模型是否被业务运营模型所满足；d)输出检测结果报告。

根据本发明的另一个方面，提供一种规则遵守状况检测系统，包括：规则模型库，用于存储为预定规则建立的规则模型；业务运营模型库，用于存储为业务流程建立的业务运营模型；标准化装置，用于对规则模型和业务运营模型的词汇进行标准化；检测引擎，用于检测规则模型是否被业务运营模型所满足；以及报告装置，用于产生并输出检测结果报告。

利用根据本发明的规则遵守状况检测方法和系统，用户可以实现快速有效的规则遵守状况自动检测，极大程度地避免了检测过程中人为因素的干扰，从而保证了检测结果的准确性。业务运营和预定规则经过计算机建模和处理保存在相应的存储库中，使得用户可以对同一个业务运营模型进行不同的规则遵守检测，还可以利用同一个规则模型多次检测不同的业务运营模型。因此，这种可以多次重复利用模型的优点大大节约了检测所耗费的人力和时间。此外，基于计算机平台的规则遵守检测，易于进行策略的调整，能够方便快捷的支持用户多变的需求。

本发明还提供编有机器可读计算机程序的存储介质，该计算机程序包括用于使处理器实现根据本发明方法的指令。

结合附图阅读本发明实施方式的详细描述后，本发明的其他特点和优点将变得更加清楚。

附图说明

图1是本发明一个实施例的规则遵守状况检测的概要性流程图；

图2是本发明一个实施例的建立规则模型的示意性流程图；

图3是规则模型化简后对应的可视化规则树的示意图；

图4示出了本发明一个实施例的业务运营模型、其形式化模型以及其化简模型的示意图；

图5是本发明一个实施例检测规则模型是否能被业务运营模型所满足的处理流程图；

图6示出了本发明一个实施例的基于规则模型给出的可视化检测结果报告；

图7是本发明一个实施例的规则遵守状况检测系统的示意性结构框图。

具体实施方式

下面结合附图详细描述本发明的具体实施方式。

图1是本发明一个实施例的规则遵守状况检测的概要性流程图。

在步骤100中，该处理开始。

在步骤101中，将以自然语言描述的诸如法律法规等预定规则抽象为计算机易于处理的数学或逻辑化模型；并且利用业务运营建模工具为现实世界中的企业、政府部门等组织机构建立业务运营模型。

在步骤102中，将模型中所用的词汇标准化，也即对步骤101中所建立的规则模型及业务运营模型进行语义上的标准化，以便针对其二者的概念和关系进行匹配检测。

在步骤103中，检测上述规则模型是否能够被上述业务运营模型所满足，以判断该业务运营是否遵守预定的规则。

在步骤104中，自动生成并输出反映该业务对规则遵守状况的检测结果报告。

在步骤105中，该处理流程结束。

以下将按照图1所示流程图的步骤顺序，对各个步骤进行详细的说明。

首先，说明在图1中如何分别为法律法规等预定规则和业务运营建立相应的模型(步骤101)。这里应该理解，虽然此处按一定先后顺序说明了两种模型的建立过程，但是实际上可以并行地或者按任何需要的顺序来建立模型。

诸如法律法规等规则，通常是用自然语言描述的。在计算机自动化处理中，很难对这种自然语言进行直接处理。因此，需要将这种自然语言描述的规则重新定义为计算机易于处理的形式。例如，可以利用一种定义语言，从规则中提取各种基本概念，以及各概念之间的逻辑关系，进而将该规则抽象为一种逻辑化公式。在本发明的一种实施例中，该定义语言定义了用于抽象规则的11种概念，包括：行为、参与者、资源、组织、时间、费用、触发、事物、位置、原则以及目的；以及这11种概念之间的各种可能发生的关系。实际上，并不存在绝对的标准来限制这些概念的选择，用户可以根据不同的需求在其语言中定义不同的概念，并且定义不同的关系来说明各个概念之间的含义。

图2是本发明一个实施例的建立规则模型的示意性流程图。

这里，可以利用一条具体法规来详细说明规则建模。例如，对“公开发行证券，必须符合法律、行政法规规定的条件，并依法报经国务院证券监督管理机构或者国务院授权的部门核准或者审批；未经依法核准或者审批，任何单位和个人不得向社会公开发行证券”(《中华人民共和国证券法》第二章，第十条)进行建模。

首先，在步骤200中，开始对规则建模的处理。

在步骤201中，找出包括在该规则中的所有概念。例如，上述的法规中包括的概念有：

行为：“公开发行证券”、“上报发行证券申请”；

触发事件：“核准或者审批”；

组织：“国务院证券监督管理机构”、“国务院授权的部门”；

原则：“法律、行政法规规定的条件”、“法”；

目的：“核准或者审批”。

在步骤202中，定义出现在该规则中的在概念之间的关系。下面用函数的形式来表示上述概念之间的关系：

概念1概念2关系(概念1(内容)，概念2(内容))

该函数表示，“概念1”与“概念2”的具体内容之间的相互关系。

例如，上述的法规中包括的关系有：

行为_原则_符合(行为(“公开发行证券”)，原则(“法律、行政法规规定的条件”))，表示“公开发行证券”要符合“法律、行政法规规定的条件”的条件；

行为_触发事件_导致(行为(“上报发行证券申请”)，触发事件(“核准或者审批”))，表示“上报发行证券申请”导致“核准或者审批”的逻辑关系；

触发事件_组织_来自(触发事件(“核准或者审批”)，组织(“国务院证券监督管理机构”))，表示由“国务院证券监督管理机构”来“核准或者审批”的规定；

触发事件_组织_来自(触发事件(“核准或者审批”)，组织(“国务院授权的部门”))，表示由“国务院授权的部门”来“核准或者审批”的规定；

行为_行为_直到(行为(“上报发行证券申请”)，行为(“公开发行证券”))，表示“上报发行证券申请”直到“公开发行证券”的时间次序；

行为_原则_符合(行为(“上报发行证券申请”)，原则(“法”))，表示“上报发行证券申请”要符合“法”的条件；

行为_目的_具有(行为(“上报发行证券申请”)，目的(“核准或者审批”))，表示“上报发行证券申请”的目的是获得“核准或者审批”。

在步骤203中，确定该规则(例如法律法规)所对应的形式化的规则模型。例如，上述的法规可以定义为：

IF 发生(行为(“公开发行证券”)

THEN

行为_原则_符合(行为(“公开发行证券”)，原则(“法律、行

政法规规定的条件”))

AND

行为_触发事件_导致(行为(“上报发行证券申请”)，触发事

件(“核准或者审批”))

AND

{

触发事件_组织_来自(触发事件(“核准或者审批”)，

组织(“国务院证券监督管理机构”))

OR

触发事件_组织_来自(触发事件(“核准或者审批”)，

组织(“国务院授权的部门”))

}

AND

行为_行为_直到(行为(“上报发行证券申请”)，行为(“公开

发行证券”))

AND

行为_原则_符合(行为(“上报发行证券申请”)，原则(“法”))

AND

行为_目的_具有(行为(“上报发行证券申请”)，目的(“核准

或者审批”))。

在步骤204中，对所定义的规则模型进行化简。例如，对于上述的法规，其规则模型可以化简为：

IF 发生(行为(“公开发行证券”)

THEN

行为_行为_直到(行为(“上报发行证券申请”)

符合

(原则(“法律、行政法规规定的条件”)

AND原则(“法”))

具有

目的(“核准或者审批”)

导致

触发事件(“核准或者审批”)

来自

(组织(“国务院证券监督管理机构”)

OR组织(“国务院授权的部门”))，

行为(“公开发行证券”))。

在步骤205中，结束对规则建模的处理。

以上具体说明了为规则建模的过程，应该注意到的是，在步骤204中对所定义的规则模型进行化简的步骤是可选的，而不是必须执行的。但是，本领域技术人员可以理解这样的化简使得以后的处理更加简便和直观。

此外，为了更加直观地显示该规则模型，优选地，还可以将该模型可视化为一种规则树。

在图3中示出了在步骤204中化简后的规则模型的可视化规则树。如图3所示，根节点300表示“IF…THEN”的逻辑结构；节点301、302表示在该规则中概念之间的关系；节点303、304、305、307、308、309、310、312和313表示上述规则中的概念；节点306、311是连接概念的逻辑运算符；在箭头上标注的是表示概念之间关系的谓词。

以下参照附图详细说明业务运营模型的建立。

图4示出了本发明一个实施例的业务运营模型、其形式化模型以及其化简模型的示意图。其中，参考标号40表示所建立的公开发行证券的业务运营模型；参考标号41表示对该模型Petri网络形式化模型；参考标号42表示形式化模型41的化简模型。

如图4所示，可以利用现有的计算机业务运营建模工具来建立业务运营模型40。在业务运营模型40中包括用箭头逻辑连接的起始节点400、任务节点401、402、403、404、405、406、决策节点407以及多个结束节点408。起始节点表示该业务过程的开始。结束节点表示该业务过程的各个可能的结束。任务节点表示一个当前需要执行的任务。决策节点表示根据当前的状态执行判断，并且根据判断结果从紧临的多个后续任务节点表示的任务中选择一个作为下一步执行的任务。

每一个任务节点都对应一个用于描述该任务的属性列表。在属性列表中记载有该节点对应于预先定义的各种属性的相应属性值。在该实施例中，为每个任务节点定义了“行为”、“组织”、“触发事件”、“原则”、“目的”等属性。举例来说，“行为”属性限定了该任务节点执行的行为，并且可以作为标识该任务节点的名称；“组织”属性限定了执行该任务的主体；“触发事件”限定了执行该任务的前提，其值可以默认为前一个任务节点“行为”的发生；“原则”属性限定了执行该任务要符合的原则；“目的”属性限定了执行该任务所具有的目的；等等。对于特定任务节点，无意义或者无需具体限定的属性可以设为空值。例如，任务节点401的“行为”属性值为“收到公开发行申请”，限定了当前执行的任务；其“组织”属性为“证监会”，限定了执行“收到公开发行申请”的任务的主体；其“原则”属性和“目的”属性，没有设置相应的限定值，被置为空值。

本领域的技术人员可以理解，可以根据当前业务运营模型的领域增加或者减少限定任务节点的属性。为了能够更加有效的进行业务运营模型和规则模型之间的比对，更佳地，可以将任务节点的属性的类型定义为与规则模型中的概念类型相应。

更佳地，还可以将上述业务运营模型40进行形式化，转换成易于利用计算机处理的形式化模型。可以利用诸如Petri网、进程代数、Z方法、B方法、通信有限状态机(Communicating Finite StateMachine)等多种方法将业务运营模型40进行形式化。图4中仅示意性示出了业务运营模型40的Petri网形式化模型41及其化简模型42。

应该理解到，虽然对业务运营模型41进行了形式化和化简的处理，形式化和化简后的模型仍然保持有原来业务运营模型的逻辑关系，并且其中的每个节点仍然受限于对应任务节点的属性。也就是说，形式化和化简的处理并不改变业务运营模型的实质性内容，而是使得该业务运营模型能够在后续步骤中变得更容易处理。

接下来，说明在图1所示流程图中对规则模型和业务运营模型进行标准化的步骤(步骤102)。

在建立模型时由于模型所属领域、偏重角度以及建模者主观描述方式的差异，很可能会出现这种情况：在规则模型和业务运营模型中对于同一种概念、关系或者当前可以视为相同的概念、关系所使用的术语(词汇、描述方式等)会不同。例如，在上述规则模型中概念“组织”包括“国务院证券监督管理机构”和“国务院授权的部门”；而在业务运营模型任务节点的“组织”属性中却表述为“证监会”。虽然，“国务院证券监督管理机构”或“国务院授权的部门”与“证监会”在所处的上下文环境中含义和作用上是相同的，但是其表述形式是不同的。在这种情况下，对规则模型和业务运营模型进行规则遵守状况检测是非常困难的。因此在检测之前，需要将规则模型和业务运营模型标准化，以实现二者在术语上的统一，也即认定“国务院证券监督管理机构”或“国务院授权的部门”与“证监会”为同一概念。而且，即使在建模之初就将两种模型中使用的术语进行统一(这通常非常困难，而且由于词汇量巨大，十分费时费力)，在进行检测之前也需要对这些术语的统一性进行认定。因此，这种认定两种模型间术语统一性的标准化步骤对于整个规则遵守状况检测方法是十分必要和关键的。

一种可行的模型语义标准化的机制是，建立当前领域的标准词汇库，利用该标准词汇库对两种模型的语义进行统一或者进行统一性的认定。在这种方案中，可以采用类似于同义词库的编排方式，将多种不同的词汇和表述方式归为同义，并且在模型中分别出现同义词时认定其统一。这样的标准化机制允许一定的模糊处理。例如，通过规定近义词，并有选择的将近义词认定为统一，实现模型语义标准化的模糊处理。

当然，对模型执行严格的标准化过程会使得后续的规则遵守状况检测相对变得苛刻，反之，过度模糊的标准化虽然会让检测环境变得宽松，但有时甚至会得出没有参考价值的检测结果。这就需要在标准化过程中进行有效的平衡。因此，一种更佳的模型标准化方法是：在利用标准词汇库的同时引入人为的选择和判断。例如，可以通过与人交互进一步判断是否将两个近义词认定为统一，或者指示将两个不同的表述认定为统一，等等。

通过以上的说明，本领域的技术人员可以理解，上述的模型标准化处理以及其改进型可以利用软件程序和人机接口的结合等本领域熟悉的方式实现，这里不再对此赘述。

接下来，参照图5利用上述描述的规则模型和业务运营模型示例具体说明在图1所示流程图中检测规则模型是否被业务运营模型所满足的步骤(步骤103)。

图5是说明本发明一个实施例的规则模型是否能被业务运营模型所满足的检测流程图。

在步骤500中，开始该处理流程。

在步骤501中，执行检测引擎加载已经建立的规则模型和业务运营模型。

在步骤502中，解析上述加载的规则模型。例如，可以按照上述建立规则模型时的优选步骤对其进行化简并且建立规则树。如上所述，解析的规则模型所得的规则树可以包括三种节点：概念节点、关系谓词节点以及逻辑运算符节点(参见图3)。

在步骤503中，在业务运营模型中定位规则模型所涉及的所有概念。如果存在，则在规则树相应概念上标记为“真”；如果不存在，则在规则树相应概念上标记“未知”。

例如，在图3所示规则模型的规则树中，概念节点包括：行为“公开发行证券”303、305，目的“核准或者审批”307，原则“法”309，原则“法律、行政法规规定的条件”310，组织“国务院证券监督管理机构”312以及组织“国务院授权部门”313。在图4所示的业务运营模型中，对上述概念节点一一定位。概念行为“公开发行证券”与任务节点404的属性行为-“公开发行证券”相匹配，因此在规则树中将该概念节点303、305标记为“真”。由上文可知，组织“国务院证券监督管理机构”312和组织“国务院授权部门”313在执行模型标准化的步骤之后语义统一为组织“证监会”，其与任务节点401、402、403、405、406的属性组织-“证监会”相匹配，因此在规则树中将该概念节点312、313标记为“真”。而目的“核准或者审批”307，原则“法”309以及原则“法律、行政法规规定的条件”310在业务运营模型中没有找到相匹配的属性项，因此将这些节点标记为“未知”。这样，就完成了规则模型中所有概念节点在业务运营模型中的定位。

在步骤504中，计算逻辑运算符和关系谓词。

逻辑运算符包括“AND”、“OR”以及“NOT”。可以定义每种逻辑运算有“真”、“假”和“未知”三种计算结果返回值。例如可以根据以下各表计算对应逻辑运算符的返回值，其中X和Y分别表示该逻辑运算符节点在规则树中的可能的叶子节点。

表1 逻辑运算符“AND”的返回值

AND		Y
		Y			真	未知	假
		X	真	真	真	未知	假	未知	假
未知	未知		真	真	未知	假		未知	假
未知	未知		假	假	未知	假	假	假

表2 逻辑运算符“NOT”的返回值

NOT
NOT			X	真	假
未知	未知			真	假
未知	未知	假		真

表3 逻辑运算符“OR”的返回值

OR		Y
		Y			真	未知	假
		X	真	真	真	未知	假	真	真
未知	真		真	真	未知	未知		真	真
未知	真		假	真	未知	未知	未知	假

相对于逻辑运算符的计算，关系谓词的计算要相对复杂。类似地，可以定义每个关系谓词具有“真”、“假”和“未知”三种计算结果返回值，其中如果检测的业务运营模型满足关系谓词表达的关系，则计算返回值为“真”，否则返回值为“假”；如果关系谓词的任何一个参数在当前业务运营模型中未知(即在步骤503中关系谓词节点的任何叶子节点标记为“未知”)，则关系谓词计算结果返回值也为“未知”。从以上的描述中可以看出，由于每一种谓词都表明一种特殊的关系，其表达和含义十分灵活，这使得无法为所有的谓词定义统一的运算。因此，在检测业务运营模型是否遵守某种关系时，需要针对不同的关系谓词预先定义并采用不同的算法计算其返回值。

例如，在图3所示的规则树中逻辑运算符“OR”节点311的两个叶子概念节点312和313的值均为“真”。根据表2，节点311的返回值也为“真”。而逻辑运算符“AND”节点306的两个概念叶子节点309、310的值均为“未知”。根据表1，节点306的返回值为“未知”。又例如，在处理图3所示的规则树中谓词节点“行为行为直到”302时，可到业务流程模型中检查任务“公开发行证券”之前是否已经存在任务“上报发行证券申请”，如果是，则该节点的值为“真”；如果不存在，则该节点的值为“假”。这样就确定了在图3所示规则模型中的所有逻辑运算符节点和谓词节点的返回值。

在步骤505中，依据上述的计算结果判断规则模型是否被业务运营模型所满足，在本实施例中也即，判断规则树中根节点的返回值。类似地，该根节点的返回值同样包括：“真”，表示业务运营模型遵守规则模型代表的规则；“假”，表示业务运营模型没有遵守规则模型代表的规则；“未知”，表示该业务运营模型相对于该规定的遵守状况是不明确的，需要更多信息才能进一步明确。

例如，在图3中由于根节点“IF…THEN”300的两个叶子节点，即关系谓词“发生”节点301和关系谓词“行为_行为_直到”节点302的检测返回值均为“真”，则根节点300的返回值为“真”。

在步骤506中，结束该处理。

以上解释了如何检查分析业务运营模型是否满足规则树。但是应该理解到，这种具体的检测机制可以根据用户的需求加以调整和改进，以满足对于不同规则、不同业务进行检测所产生的多层次要求。例如，虽然在上述实施例中仅给出了“真”、“假”和“未知”3种节点返回值类型，但是可以为每个节点增加更多种的节点返回值类型，以便表示业务运营模型对规则模型的不同的遵守程度。

除了所说明的实施例之外，还可以利用本领域技术人员所熟悉的其他的检测方法来实现这一步骤(步骤103)。例如，检测引擎利用语义解析程序代码对规则模型和业务运营模型进行语义解析的方式，而直接执行语义匹配检测，以得出业务运营模型是否满足规则模型的判断，等等。

最后，基于上述检测结果自动生成并输出该规则遵守情况的检测结果报告(步骤104)。

这种自动报告机制可以设计为不仅支持产生书面的文本报告，还可以支持根据所建立的规则模型、业务运营模型或者其二者的组合给出多层次可视化的检测报告。用户可以定义业务对于规则的不同的违反和遵守程度，然后将其体现在检测报告中。当然，可以理解到，用户的自定义自由度取决于具体的检测机制是否支持复杂的判断过程以及是否能够产生更加细密的多层次检测结果数据。

例如，图6示出了本发明一个实施例基于规则模型给出的可视化检测报告。如图6所示，利用规则树的形式显示了在上述实施例中业务运营模型对规则中的各种关系、逻辑等的遵守情况。其中，示例性的利用不同的图形符号标识出各个节点不同的规则遵守程度。

图7是根据本发明的一个实施例的规则遵守检测状况系统的示意性结构框图。

在图7中，参考标号700表示本发明一个实施例的规则遵守状况检测系统；参考标号701表示业务运营模型库；参考标号702表示规则模型库；参考标号703表示标准化装置；参考标号704表示标准词汇库；参考标号705表示变换装置；参考标号706表示规则解释装置；参考标号707表示检测引擎；参考标号708表示报告装置。

如图7所示，用户通过业务运营模型建模工具(未示出)建立需要检测的业务运营模型，并将其存储在业务运营模型库701中；并且通过规则建模工具(未示出)建立规则模型，并将其存储在规则模型库702中。

标准化装置703利用标准词汇库704所提供的当前检测领域内的标准词汇，对业务运营模型库701中的要检测的业务运营模型和规则模型库702中的要检测的规则模型进行语义标准化。在图7所示的系统中，标准化后的业务运营模型和规则模型仍分别存储在业务运营模型库701和规则模型库702中，以便能够多次使用已标准化的模型。

将标准化后的业务运营模型输入变换装置705，进行业务运营模型的形式化处理。之后，将形式化的业务运营模型输入检测引擎707。

与此同时，将标准化后的规则模型输入规则解释装置706，对其进行有效的化简，并且优选地生成规则树。之后，将处理后的规则模型输入检测引擎707。

这里需要指出的是，虽然在图7所示的检测系统中，业务运营模型和规则模型被标准化装置703标准化之后才分别输入变换装置705和规则解释装置706进行处理，但是如前所述，本领域的技术人员可以理解到，也可以先由变换装置705和规则解释装置706分别对业务运营模型和规则模型进行处理，然后再由标准化装置703对这两种模型进行标准化。上述处理的先后顺序以及相应装置的之间的可能的连接关系不对本发明构成限制。

在图7所示的实施例中，检测引擎707是可以执行如图5所示处理流程的装置，用于对输入的业务运营模型是否满足输入的规则模型进行检测，并将检测数据输入报告装置708。

报告装置708根据检测引擎707报告的检测数据，更佳地，还根据检测中间数据生成并输出检测报告。报告装置708可以同时支持文本报告以及图形化报告的生成和输出。

以上结合本发明的一个实施例描述了规则遵守状况检测系统的结构。根据上文所述的其他实施例，该遵守状况检测系统还可以具有其他的结构。例如，可以将标准化后的业务运营模型和规则模型直接输入检测引擎，利用语义解析程序代码对规则模型和业务运营模型进行语义解析，而直接执行规则遵守检测。因此，根据本发明的规则遵守检测系统并不限于图7所示的形式。

本发明的一部分可以作为一序列或一组存储在计算机可读存储介质上的计算机可执行指令(计算机软件)而实现。该计算机可读存储介质可以是诸如硬盘、只读存储器(ROM)装置、CD或DVD光盘、磁带等那样的持续性存储介质。

虽然结合附图描述了本发明的实施方式，但是本领域技术人员可以在所附权利要求的范围内做出各种变形或修改。

Claims

1.一种规则遵守状况检测方法，其中包括以下步骤：

a)为预定的规则建立规则模型，并且为业务流程建立业务运营模型；

b)对所述规则模型和所述业务运营模型的词汇进行标准化；

c)检测所述规则模型是否被所述业务运营模型所满足；

d)产生并输出检测结果报告。

2.根据权利要求1所述的方法，其中步骤a)包括至少利用概念、关系将所述预定的规则描述为逻辑公式形式的规则模型。

3.根据权利要求2所述的方法，其中所述概念包括行为、参与者、资源、组织、时间、费用、触发、事物、位置、原则以及目的，所述关系包括所述概念之间可能发生的关系。

4.根据权利要求2所述的方法，其中步骤a)包括将所述规则模型化简为由逻辑关系符和谓词所连接的逻辑表达式。

5.根据权利要求4所述的方法，其中步骤a)包括将化简后的规则模型表示为规则树形式。

6.根据权利要求1所述的方法，其中所述步骤a)包括对所述业务运营模型进行形式化。

7.根据权利要求6所述的方法，其中所述步骤a)包括对形式化后的所述业务运营模型进行化简。

8.根据权利要求1所述的方法，其中所述步骤b)包括利用标准词汇库对所述规则模型和所述业务运营模型中使用的表达进行统一或者对其统一性进行认定。

9.根据权利要求8所述的方法，其中所述步骤b)进一步包括根据用户输入的信息，对所述规则模型和所述业务运营模型中的表达进行统一或者对其统一性进行认定。

10.根据权利要求4所述的方法，其中所述步骤c)包括以下步骤：

加载所述化简的规则模型和所述业务运营模型；

在所述业务运营模型中定位所述规则模型所涉及的所有概念；

基于所述业务运营模型计算所述化简的规则模型中的逻辑运算符和谓词；

确定所述规则模型是否被所述业务运营模型所满足。

11.根据权利要求1所述的方法，其中步骤c)包括以下步骤：

解析所述规则模型的语义；

解析所述业务运营模型的语义；

对解析后的规则模型和业务运营模型执行语义匹配检测，以确定所述规则模型是否被所述业务运营模型所满足。

12.根据权利要求1所述的方法，其中所述步骤d)所述检测结果报告定义了所述业务对于所述规则的违反和/或遵守程度。

13.根据权利要求1所述的方法，其中所述步骤d)所述检测结果报告为可视化图形报告。

14.一种规则遵守状况检测系统，包括：

规则模型库，用于存储为预定的规则建立的规则模型；

业务运营模型库，用于存储为业务流程建立的业务运营模型；

标准化装置，用于对所述规则模型和所述业务运营模型的词汇进行标准化；

检测引擎，用于检测所述规则模型是否被所述业务运营模型所满足；以及

报告装置，用于产生并输出检测结果报告。

15.根据权利要求14所述的系统，其中所述规则模型是至少利用概念、关系将所述预定的规则描述为逻辑公式形式的规则模型。

16.根据权利要求15所述的系统，其中所述概念包括行为、参与者、资源、组织、时间、费用、触发、事物、位置、原则以及目的，所述关系包括所述概念之间可能发生的关系。

17.根据权利要求15所述的系统，进一步包括：规则解释装置，用于将所述规则模型化简为由逻辑关系符和谓词所连接的逻辑表达式，并且输出到所述检测引擎；以及转换装置，用于对所述业务运营模型进行形式化，并输出到所述检测引擎。

18.根据权利要求17所述的系统，其中所述规则解释装置，进一步用于将化简后的规则模型表示为规则树形式。

19.根据权利要求17所述的系统，其中所述转换装置，进一步用于对形式化后的所述业务运营模型进行化简。

20.根据权利要求14所述的系统，进一步包括标准词汇库，用于向所述标准化装置提供当前领域的标准词汇，并且所述标准化装置利用所述提供的标准词汇对所述规则模型和业务运营模型中所使用的表达进行统一或者对其统一性进行认定。

21.根据权利要求20所述的系统，其中所述标准化装置还根据用户输入的信息，对所述规则模型和所述业务运营模型中的表达进行统一。

22.根据权利要求17所述的系统，其中所述检测引擎用于加载所述化简的规则模型并且加载所述形式化的业务运营模型，而后在所述业务运营模型中定位所述规则模型所涉及的所有概念，并且基于所述业务运营模型计算所述规则模型中的逻辑运算符和谓词，最后确定所述规则模型是否被所述业务运营模型所满足，将检测数据输出给所述报告装置。

23.根据权利要求14所述的系统，其中所述检测引擎用于加载并解析所述规则模型的语义，加载并解析所述业务运营模型的语义，之后对解析后的规则模型和业务运营模型执行语义匹配检测，以确定所述规则模型是否被所述业务运营模型所满足，并且将检测数据输出给所述报告装置。

24.根据权利要求14所述的系统，其中所述报告装置还用于在所述检测结果报告中定义所述业务对于所述规则的违反和/或遵守程度。

25.根据权利要求14所述的系统，其中所述报告装置还用于生成可视化图形检测结果报告。