首页> 中国专利> 一种面向规则执行日志的流程挖掘方法

一种面向规则执行日志的流程挖掘方法

摘要

本发明公开了一种面向规则执行日志的流程挖掘方法,包括如下步骤:1)业务规则引擎、业务规则引擎,2)XESame3)ProM,ProM是开源的挖掘框架,以插件的形式支持流程挖掘。它以第二步生成的“.xes”文件作为输入来源,通过以插件形式进行挖掘工作的α-r方法的挖掘,并配合Petri网的建模,最终形成流程挖掘结果图。

著录项

  • 公开/公告号CN102509171A

    专利类型发明专利

  • 公开/公告日2012-06-20

    原文格式PDF

  • 申请/专利权人 浙江大学;

    申请/专利号CN201110325501.3

  • 申请日2011-10-24

  • 分类号

  • 代理机构杭州裕阳专利事务所(普通合伙);

  • 代理人江助菊

  • 地址 310027 浙江省杭州市西湖区浙大路38号

  • 入库时间 2023-12-18 05:34:25

法律信息

  • 法律状态公告日

    法律状态信息

    法律状态

  • 2014-11-12

    授权

    授权

  • 2012-07-18

    实质审查的生效 IPC(主分类):G06Q10/04 申请日:20111024

    实质审查的生效

  • 2012-06-20

    公开

    公开

说明书

技术领域

本发明属于数据挖掘领域,主要是针对传统的基于事件日志的流程挖掘技术,提出面向规则引擎日志的流程挖掘技术,涉及一种面向规则执行日志的流程挖掘方法。

背景技术

工作流技术对企业优化其组织及经营管理过程提供了积极的作用,如今该技术已经广泛应用于企业的各种信息系统中,包括企业资源管理(ERP)系统、客户关系管理(CRM)系统、供应链管理(SCM)系统、B2B系统等。一方面,这些信息系统确实给企业带来了信息化建设道路上的种种竞争优势;另一方面,这些信息系统一般都是由显示的工作流模型来驱动的,即必须事先设计一个工作流模型来准确描述工作流的执行流程。然而,工作流模型的设计是一项复杂、涉及方方面面的工程,既需要有丰富的工作流模型设计经验,也要有很好的交流沟通技巧(包括与工作人员及上层决策者之间的不断交流),因此这样的设计往往既耗时又费力,也容易导致错误。同时,由于最后都是由公司决策者来拍板决定采用哪个工作流模型,往往带有一定的主观性。再者,业务逻辑的复杂性可能导致设计出的模型与实际的运行流程有偏差,而在实际运行期间,业务流程也很有可能随着环境或种种因素的改变而导致工作流模型缺乏可适应性。

工作流挖掘技术的提出正是为了弥补以上的不足,其目的是为了发现潜在的业务流程进而对企业业务流程进行改进或者重建。如今基于事件日志的流程挖掘比较普遍。

于此同时,随着业务规则引擎的不断发展,凭借其强大的支撑,企业的业务信息系统将会抛弃以前那种“硬编码”式的模式,转向“可配置”式的模式,不仅可以实现企业业务系统运行期的高度可配性,提升业务工作流的柔性支持能力,同时使得企业能够处理一些及其复杂的业务规则流程,为生产能力及市场竞争力的提升起到积极的作用。

发明内容

为了解决上述技术问题,本发明提出一种面向规则执行日志的流程挖掘方法。

一种面向规则执行日志的流程挖掘方法,包括如下步骤:

1)获取规则流日志                                                并将其转换为标准的ProM输入格式;

2)对转换后的规则流日志中的每一条规则轨迹的每个规则任务t进行查询,若t是规则轨迹中第一条规则任务,则t就是流程的起始点;

3)获得该规则任务t对应的LHS所涉及的事实集FL(r)和对应的RHS所涉及的事实集FR(r)

4)对FL(r)进行判断,若为空,则规则任务t是流程的终点;若不为空,则

对于规则任务t之后的每个规则任务t',获得该规则任务t'中规则r'对应的LHS所涉及的事实集FL(r')和对应的RHS所涉及的事实集FR(r');判断FL(r)FL(r')的关系,如果两者中的事实更新频率均相同,则tt'存在关系;如果两者至少存在一个相同的事实,则tt'存在关系;如果两者至少存在一个相同的事实,则tt'存在关系;若FR(r)在规则任务t之后从未触发过任何规则,那么t就是流程的终点;

5)对于规则轨迹中任意两个规则任务tt'的规则r',若FL(r)FL(r')均为空集或者tt'均与轨迹中的其它规则任务不存在关系,则tt'存在关系;

6)合并由上述步骤挖掘的结果并发现关系;

7)通过Petri网形式对最终的挖掘结果进行建模;

上述规则是一个二元组(LHS,RHS),其中:LHS是左边部分,即一个规则中的一组有限个数条件的集合;RHS是右边部分,即一个规则中的一组有限个数动作的集合;令T为规则任务的集合,则表示一条规则流轨迹,是一个规则流日志,其中是的幂集,所述 表示最先开始执行的规则任务,即在系统运行时规则库中最先被并行触发的规则任务;所述关系表示并行结束,存在于两种不同的情形之下,即规则任务中没有涉及到任何事实或规则的RHS中所涉及到的事实无法再触发别的规则,所述表示两个规则间有直接因果依赖关系,关系表示了每个并行分支的最初节点,最后一个关系是基于两个不同的轨迹,所以它表示规则间是选择关系。

进一步的,所述事实 f 由三元组  组成, 表示事实类型ID,表示事实ID,表示事实在一个规则任务的集合,一起结合使用并以工作流的形式做出最终决策中被更新的次数。

进一步的,令 g 为规则任务集合T(即)上的规则流日志,以 / 分别代表规则r所对应的LHS / RHS所涉及到的事实集,而π(f) 表示事实f的更新频率:当存在轨迹,其中且 , 时:

 当且仅当相同;

 当且仅当 ;

 当且仅当 ;

 当且仅当 ;

当存在另外一条规则流轨迹,其与轨迹共享某些相同的规则任务,令:

 当且仅当。

本发明的有益效果在于:该技术分析嵌入在企业信息系统中的业务规则引擎所产生的业务规则日志信息,给出规则日志的基本形式,通过日志格式的转换及基于规则日志的流程挖掘算法的挖掘,发现规则间潜在的流程,从而为企业的业务流程改进或者重建提供积极的建议。

附图说明

 图1为 α-r方法中基于事实的规则触发关系图;

图2一个规则流日志样例;

图3基于图2的利用α-r方法挖掘出的流程图;

图4面向规则日志的流程挖掘整体架构图。

具体实施方式

    下面将结合附图和具体实施例对本发明做进一步的说明。

在本发明中,考虑这样一个情形,即业务规则引擎与工作流引擎已经集成到企业的业务信息系统中,它们相互配合帮助企业进行业务的高效流转与执行,即业务流程中的活动流转通过工作流引擎来驱动,而流程中各节点活动所涉及的业务逻辑的执行将由业务规则的匹配与否所决定,即任何规则得到满足后导致一系列业务动作的执行。在这样的情形下,一旦业务信息系统开始运行,传统的流程挖掘所依赖的信息系统的日志信息开始被流程引擎记录,而规则引擎所产生的规则日志信息也被同时记录下来。从现有技术中可得知,规则引擎所产生的规则日志是关于规则库中规则按照时间顺序执行时的上下文信息(即规则流日志),由于规则引擎与工作流引擎相互融合使用,因此规则引擎日志中的信息与企业的业务流程的运转有着千丝万缕的联系。然而,规则日志信息几乎很少被收集用来进行流程挖掘方面的分析工作,因此,本发明意图从规则引擎所产生的规则日志信息中挖掘出隐含的流程信息,进而从业务规则间执行流程的角度来重构流程。

一、相关规则制定

首先给出如下的一些定义:

定义(1)事实:事实 f 由三元组  组成,其中:

1) 表示事实类型ID

2) 表示事实ID

3) 表示事实在同一实例(即一个规则任务的集合,一起结合使用并以工作流的形式做出最终决策)中被更新的次数

定义(2)规则Rule:规则是一个二元组(LHS,RHS),其中:

1) LHS是左边部分(Left-Hand-Side),即一个规则中的一组有限个数条件的集合;

2) RHS是右边部分(Right-Hand-Side),即一个规则中的一组有限个数动作的集合。

定义(3)规则流轨迹、规则流日志:令T为规则任务的集合,则表示一条规则流轨迹,是一个规则流日志,其中是的幂集。

一个规则日志中含有一条或多条规则流轨迹,每条规则流轨迹对应至少一个实例。通过分析整个规则流日志信息可以获得规则流轨迹的发生频率等信息,而本发明所关注的是每条规则流轨迹间所蕴涵着的流程信息。针对规则日志信息的完整性问题,假设日志信息记录没有噪音,即是完整的,这一点和传统的基于事件日志的流程挖掘方法是一致的。

定义(4)基于事实的规则触发关系:令 g 为规则任务集合T(即)上的规则流日志,以 / 分别代表规则r所对应的LHS / RHS所涉及到的事实集,而π(f) 表示事实f的更新频率:

假设存在轨迹,其中且 , :

1.      当且仅当相同.

2.      当且仅当 .

3.      当且仅当 .

4.      当且仅当 .

假设存在另外一条规则流轨迹,其与轨迹共享某些相同的规则任务。令,则:

5.      当且仅当.

需要说明的是前四条关系是基于同一条规则流轨迹的,而最后一个定义则是基于同一个规则流日志下的两条不同的规则流轨迹。从上述定义可看出,通过分析单个轨迹中的每条规则中的事实就能够发现大多数的关系。在本方法中将主要依赖上述关系。

二、方法实现

本发明在提出面向规则执行日志的流程挖掘技术的同时,已经以ProM(一个开源的流程挖掘工具)插件的形式实现了面向规则执行日志的流程挖掘方法,下面将其命名为α-r方法。其实现过程如下:

α-r方法实现过程

------------------------------------------------------------------------------------------

输入input:规则流日志

输出output:以Petri网建模的流程图

1、对于规则流日志中的每一条规则路径,do:

1.2、对于规则轨迹的每个规则任务t,do:

1.2.1、若t是中第一条规则任务,那么t就是流程的起始点

1.2.2、获得该规则任务对应的LHS所涉及的事实集FL(r)

   1.2.3、获得该规则任务对应的RHS所涉及的事实集FR(r)

   1.2.4、如果FL(r)为空

        1.2.4.1、规则任务t是流程的终点。

   1.2.5、对于规则任务t之后的每个规则任务t',do:

        1.2.5.1、获得该规则任务中规则r'对应的LHS所涉及的事实集FL(r')

        1.2.5.2、获得该规则任务中规则r'对应的RHS所涉及的事实集FR(r')

1.2.5.3、若FL(r)FL(r')中的事实更新频率均相同,则tt'存在关系;

1.2.5.4、若FR(r)FL(r')至少存在一个相同的事实,则tt'存在关系;

1.2.5.5、若FL(r)FL(r')至少存在一个相同的事实,则tt'存在关系;

1.2.6、如果FR(r)在规则任务t之后从未触发过任何规则,那么t就是流程的终点。

1.3、对于规则轨迹中任意两个规则任务tt'的规则r',若FL(r)FL(r')均为空集或者tt'均与轨迹中的其它规则任务不存在关系,则tt'存在关系。

2、合并由上述步骤挖掘的结果并发现关系。

3、通过Petri网形式对最终的挖掘结果进行建模。

------------------------------------------------------------------------------------------

注意以上表格的结构,共分三步,其中第一步主要是挖掘规则间触发关系的步骤;第二步是为了发现不同规则流轨迹间的选择关系;第三步是Petri图的显示。

以上描述了整个α-r方法的实现流程,对于规则流日志的每一条规则轨迹,挖掘和发现其规则任务之间的因果、并行等关系,对于不同的规则轨迹的分析,发现规则任务之间的选择关系。最后,当所有关系被发现以后,AND-Split和AND-Join被用于并行关系的表示,OR-Split和OR-Join则被用于选择关系的表示,这些一并以Petri图的形式给出规则挖掘流程图。

三、挖掘架构设计

基于规则的流程挖掘经过规则日志收集、日志的转换、算法的挖掘、Petri网的建模几个步骤最终以Petri网的形式显示。本发明给出的整体挖掘架构分为三个部分:规则日志收集、规则日志转换及流程挖掘。详细说明将在图4说明。

四、具体例子

图1表示α-r方法中基于事实的规则解决关系图。根据定义4,可知关系“”表示最先开始执行的规则任务,即在系统运行时规则库中最先被并行触发的规则任务。关系“”表示并行结束,存在于两种不同的情形之下,即规则任务中没有涉及到任何事实或规则的RHS中所涉及到的事实无法再触发别的规则。“”表示两个规则间有直接因果依赖关系。从工作流角度来看,关系“”表示了每个并行分支的最初节点。最后一个关系“”是基于两个不同的轨迹,所以它表示规则间是选择关系。

图2是一个规则日志匹配规则记录表,以此图数据具体说明基于规则的流程挖掘算法的原理。图中每行代表一条规则匹配日志记录,共有四列,分别为Case ID、LHS(Conditions)、Fired Rule ID和RHS(Actions),分别代表用例标识、规则触发的条件部分、触发的规则和触发的动作。以第一条记录为例,Case ID为1,LHS为f(1,1,0), f(2,1,0),表示使用两个事实且他们初始化的更新次数为0,Rule为A,表示触发了规则A,RHS为Update f(2,1,1),表示更新了事实f(2,1,0)使得从0增加到1。

图3是基于图2数据,通过基于规则的流程挖掘原理所分析出来的规则流程图。图2中的事实集为{f1,f2,f3},包含三种事实类型,有两条规则流程路径,分别为1-2-3-4-6-7和1-2-3-5-6-7。首先,在两个Case中,初始节点都为1,结束节点都为7。在第一个Case中,看前两条记录信息,第二条的LHS对应于第一条的Actions,根据定义(8)知规则1和2为因果关系,且1—>2。同理可见,规则2和4也为先后因果关系。对于规则1和3,规则1对应的Actions为规则3对应的LHS的一部分,而另一部分为f(3,1,0),更新次数为0,根据定义(2)(事实的定义)可知该事实是预先存在于事实集中的,因此规则1和3也是先后因果关系。而规则4和6,类似规则1和3,不同的是规则6对应的LHS中含有f(2,1,1),该事实是f(2,1,0)触发规则1后更新一次的事实,在触发规则6之前该事实已经存在了,故也是合理的,于是乎规则4和6也是先后因果关系。同理可知规则6和7也是先后因果关系。接下来分析规则间的并行关系。对于规则2和规则3,规则2的触发事实为f(2,1,1),规则3的触发事实为f(2,1,1)和f(3,1,0),两者具有相同的触发事实f(2,1,1),并且f(3,1,0)为事实集中预先存储的事实,根据定义(8)中规则间并行关系的定义可知2和3为并行关系。同理可知规则3和规则6也是并行关系。对于第二个Case,以同样的方式分析得到的结果也是一样的。而选择关系(OR)的挖掘是通过Case1和Case2整体上来分析得到的。

图4表示基于规则的流程挖掘整体架构图,共分为三个部分:业务规则引擎、XESame及ProM。1)业务规则引擎(规则日志收集)。这是规则记录日志信息的来源,是整个架构与外部交互的部分。企业业务规则引擎在运行期间以日志的形式记录所有运行的规则记录信息,记录的文件类型可以是“.csv”、“.xls”、“.txt”等等,本文采用“.csv”类型的文件作为实验的数据来源格式。2)XESame(规则日志转换)。XESame是一个实现日志格式转换功能的辅助开源工具。它的主要功能是通过映射文件的配置,将业务规则引擎产生的规则信息从“.csv”、“.xls”、“.txt”等不统一的文件格式转换成标准的符合ProM输入的“.xes”文件。这一步可以看作是规则日志信息源的处理部分。3)ProM(流程挖掘)。ProM是开源的挖掘框架,以插件的形式支持流程挖掘。它以第二步生成的“.xes”文件作为输入来源,通过以插件形式进行挖掘工作的α-r方法的挖掘,并配合Petri网的建模,最终形成流程挖掘结果图。这一步是整个架构的核心部分,它与第二步一起构成了整个的挖掘及显示部分。

以上所述仅是本发明的优选实施方式,应当指出,对于本技术领域的普通技术人员,在不脱离本发明构思的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本发明保护范围内。

去获取专利,查看全文>

相似文献

  • 专利
  • 中文文献
  • 外文文献
获取专利

客服邮箱:kefu@zhangqiaokeyan.com

京公网安备:11010802029741号 ICP备案号:京ICP备15016152号-6 六维联合信息科技 (北京) 有限公司©版权所有
  • 客服微信

  • 服务号