（计算机应用技术专业论文）基于业务规则方法的mis系统研究与实现.pdf

中文摘要 作为管理者意志或相关规定的体现，管理信息系统中的业务逻辑时刻都有可 能发生变化。传统的软件开发方法在处理这些逻辑的变化时必须依靠修改软件系 统的代码得以实现，由此产生的高昂软件维护成本越来越不可接受。所以必须寻 找更为灵活的解决方案。 针对现代信息系统对软件的灵活性要求越来越高的现状，人们在软件体系结 构和软件开发方法上都做出了巨大努力。其中，基于规则的方法试图通过把原来 封装在系统代码中的业务逻辑抽取出来以业务规则的形式加以描述，以达到分离 业务逻辑与应用系统、快速完成业务逻辑变换的目的。它为开发人员构建更为灵 活和更具适应性的业务系统提供了新的思路。 本文在构建一个具体的科技管理信息系统的过程中，充分考虑到软件体系结 构和开发方法对软件的可扩展性及可维护性的影响，在深入研究业务规则方法思 想的基础上，针对该系统设计了一个基于业务规则的分层体系结构，并在此基础 上实现了该系统。系统在j 2 e e 平台上构建，通过加入业务规则组件实现了业务 逻辑与应用组件的分离。系统的业务逻辑被封装成业务规则组件所依赖的称为规 则集的资源数据的形式，不再以系统代码的形式存在。业务逻辑的变化体现为对 作为数据的规则集的修改，而不会对系统代码产生任何影响。 一 一业务规则组件是系统设计和实现的关键所在。在实现该组件时，使用了j b o s s r u l e s 作为业务规则推理引擎，通过设计业务规则服务模块实现了规则组件与应 用组件的交互；通过设计规则维护模块实现了一个基于b s 结构的简易规则维护 管理子系统，用来对系统使用的规则集进行维护和管理。事实表明，该系统在可 用性、易用性及处理业务逻辑变化的快速性方面都有良好的表现。， 关键词：业务规则方法规则规则引擎m i s a b s t r a c t a sr e p r e s e n t a t i o no ft h es u p e r v i s o r sd e c i s i o n so rr e l e v a n tp o l i c i e s ，t h eb u s i n e s s l o g i co fam a n a g e m e n ti n f o r m a t i o ns y s t e m ( m i s ) m i g h tc h a n g er a p i d l y i ft r a d i t i o n a l s o r w a r ed e v e l o p m e n tm e t h o di st a k e n ，t od e a lw i t ht h e s ec h a n g e s ，w eh a v et or e - c o d e p a r to ft h ea p p l i c a t i o ns y s t e m ，a n dt h i sl e a d st oh i g hc o s t so nt h em a i n t e n a n c eo ft h e s o f t w a r e ，w h i c hb e c o m e sm o r ea n dm o r eu n a c c e p t a b l e n e ws o l u t i o n sa r en e e d e d e a g e r l y i no r d e rt os a t i s f yt h ei n c r e a s i n g l yh i 曲r e q u i r e m e n t so ft h ef l e x i b i l i t yo fm o d e r n i n f o r m a t i o ns y s t e m , p e o p l eh a v em a d eal o to fc o n t r i b u t i o n s ，e i t h e rf r o mt h ea s p e c to f t h eo p t i m i z i n ga r c h i t e c t so ft h es o f t w a r e ，o rf r o mt h ea s p e c to fd e v e l o p i n gn e w s o f t w a r ed e v e l o p m e n tm e t h o d i na l lo ft h e m r u l e b a s e ds o f t w a r ed e v e l o p m e n t m e t h o dc a l la c h i e v et h em o t i v e so fs e p a r a t i n gb u s i n e s sl o g i cf r o mt h ea p p l i c a t i o n s y s t e ma n dc o m p l e t i n gt h ec h a n g e so fb u s i n e s sl o g i cr a p i d l y ，t h r o u g he x p r e s s i n gt h e o r i g i n a lb u s i n e s sl o g i co ft h es y s t e mi nt h ef o r mo fb u s i n e s sr u l e si n s t e a do fc o d i n g t h e md i r e c t l yi nt h es o f t w a r e i nt h i sp a p e r ，w ec o n s i d e r e dc a r e f u l l yo ft h ei m p a c t so fs o f t w a r ea r c h i t e c t sa n d d e v e l o p m e n tm e t h o d so nt h ee x t e n s i b i l i t ya n dm a i n t a i n a b i l i t yo ft h es o f t w a r ei nt h e p r o c e s so fb u i l d i n gas p e c i f i cm a n a g e m e n ti n f o r m a t i o ns y s t e m , a n da sar e s u l t ，w e d e s i g n e dab u s i n e s sr u l e - b a s e da r c h i t e c t u r ef o rt h es y s t e m , a n di m p l e m e n t e di t s u c c e s s f u l l y t h i sm i si sb u i l to nt h ep l a t f o r mo fj 2 e e ，a n dw ea c h i e v et h em o t i v eo f s e p a r a t i n gt h eb u s i n e s sl o g i ca n da p p l i c a t i o nc o m p o n e n t sb yi n t r o d u c i n gab u s i n e s s r u l ec o m p o n e n t t h eb u s i n e s sl o g i co ft h es y s t e mi se n c a p s u l a t e di n t oag r o u po f s o - c a l l e dr u l ep a c k a g e s ，w h i c ha r ed e p e n d e do nb yt h eb u s i n e s sr u l ec o m p o n e n ta n d m a i n t a i n e da sr e s o u r c ed a t a ，i n s t e a do fp r o g r a mc o d e t h ec h a n g e so fb u s i n e s sl o g i c c a nb ed o n eb ye a s i l yc h a n g i n gt h ed a t a f o r m e dr u l ep a c k a g e s ，b u tm a k en oi m p a c to n t h ea p p l i c a t i o n ： t h ed e s i g no ft h eb u s i n e s sr u l ec o m p o n e n ti st h ek e yo ft h es y s t e m w h e nw e i m p l e m e n tt h i sc o m p o n e n t ，w eu s et h ej b o s sr u l e st oa c ta st h eb u s i n e s sr u l e i n f e r e n c ee n g i n e ab u s i n e s sr u l es e r v i c em o d u l ei s d e s i g n e dt oa c c o m p l i s ht h e c o m m u n i c a t i o n so ft h eb u s i n e s sr u l ec o m p o n e n tw i t ha p p l i c a t i o nc o m p o n e n t s a b u s i n e s sr u l em a i n t e n a n c em o d u l ei sd e s i g n e dt oa c c o m p l i s ht h em a i n t e n a n c e 。a n d a d m i n i s t r a t i o no ft h eb u s i n e s st a l cp a c k a g e s f a c t sh a v ep r o v e dt h a tt h es y s t e mw e d e s i g n e db e h a v e sw e l li nt h ea s p e c t so fu s a b i l i t y ，e a s et oo p e r a t ea n da b i l i t yt od e a l w i t hr a p i d - c h a n g eb u s i n e s sl o g i c k e yw o r d s ：b u s i n e s sr u l ea p p r o a c h ，r u l e ，r u l ee n g i n e ，m i s 独创性声明 本人声明所呈交的学位论文是本人在导师指导下进行的研究工作和取得的 研究成果，除了文中特别加以标注和致谢之处外，论文中不包含其他人已经发表 或撰写过的研究成果，也不包含为获得墨盗盘鲎或其他教育机构的学位或证 书而使用过的材料。与我一同工作的同志对本研究所做的任何贡献均已在论文中 作了明确的说明并表示了谢意。 学位论文作者签名：丑谄馁 签字日期：沙、7 年f 月日 学位论文版权使用授权书 本学位论文作者完全了解墨鲞盘鲎有关保留、使用学位论文的规定。 特授权墨鲞盘鲎可以将学位论文的全部或部分内容编入有关数据库进行检 索，并采用影印、缩印或扫描等复制手段保存、汇编以供查阅和借阅。同意学校 向国家有关部门或机构送交论文的复印件和磁盘。 + ( 保密的学位论文在解密后适用本授权说明) 学位论文作者签名：1 乌谚 签字日期：少叼年月f 日 聊签名：枷订 签字日期：j 捌7 年月，目 第一章绪论 1 1 研究背景 第一章绪论 当今世界，随着全球经济的快速发展，以信息技术为代表的高科技技术正在 发生深刻的变革。信息技术已经无处不在的应用到社会的各个领域当中。在信息 技术中，软件是所有技术的核心【l 】。据i d c 统计，在过去十年中，全球企业在构 建信息系统上的投资超过了1 8 万亿美元【2 】。由此可见，信息系统在现代化管理 中发挥着巨大作用。 随着企业信息化的深入，信息系统得到了进一步发展，同时也对信息系统提 出了更高的要求。由于商业世界充满了变化，市场在变，客户需求在变，公司产 品在变，工艺流程在变，领导决策在变，“唯一不变的就是变化”口7 1 。在这种 形势下，伴随而来的是信息系统的业务逻辑也处在不断地变化之中。如何使信息 系统可以灵活地应对不断变化的业务逻辑，是对信息系统提出的新挑战。 在传统的软件开发方法中，开发人员需要从业务人员那里了解得到所要构建 的信息系统的功能需求，其中不乏本来是由业务人员所掌握的领域相关的业务知 识。这些知识被统一看作所谓“业务逻辑”，连同其他需求，被开发人员“理解 并用程序设计语言将其编写成可执行的代码。同时，为了支持不断变化的业务逻 辑，实现软件的“演进 ，还必须不断地对这些代码进行修改。经过多次反复修 改之后，软件代码和文档越来越大，软件系统也会随之越来越复杂以致于难以理 解和维护。 针对信息系统在业务逻辑上的易变性，人们对传统的软件开发方法在支持软 件“演进”方面的局限性的认识也更加深刻3 】【4 】【3 3 】： 开发过程需要一个转换步骤，把功能说明中详细阐述的业务知识转化为过程 代码。但是在很多情况下，这种转化并不能保证业务知识的代码形式和功能 文档形式的语义一致性。 业务知识一旦被转化为过程代码，其语义就不再为那些负责业务知识完整性 的人员和业务分析人员所熟悉，只有少数编码人员熟悉它们。一旦这些人忘 记或者离职，业务知识的理解和维护就会异常困难。 将业务知识嵌入过程代码会使其与过程功能之间建立一种不必要的相互依 赖，被嵌入的业务知识无法完全独立地发挥作用，所以对业务规则的建模、 测试和修改变得十分复杂。 第一章绪论 基于这些认识，人们倾向于寻求更为灵活的解决方案。于是基于规则的软件 开发方法应运而生。它试图将那些埋没于过程代码中的业务知识分离出来作为规 则单独加以管理，使业务知识可以用一种描述性的非过程方式加以定义。这样一 来，程序的业务逻辑本身和它的实现被分离开来，业务逻辑以业务规则的形式表 述，它的变化不会影响到应用系统本身。原来的“黑盒 系统演变为一种“白盒” 系统，业务逻辑可以为外界所见【5 】。基于规则的软件开发方法可以提升i t 系统的 寿命，使应用系统能够根据新的客户需求迅速完成i t 系统的业务逻辑的变换。 与传统的软件开发方法相比，基于业务规则的开发方法具有以下优点【6 】： 描述式编程( d e c l a r a t i v ep r o g r a m m i n g ) 由于业务规则是以描述性方式加以定义的，所以能够更容易地把功能说明中 用自然语言阐述的业务规则转化为描述性定义的业务规则，提高开发效率。 业务规则可以被业务人员和开发人员共同理解 描述性定义的业务规则在形式上更接近于用自然语言描述的业务规则，编码 人员、负责业务规则完整性的业务分析人员都可以读懂。这使得业务规则与相应 文档在反复修改之后仍能保证语义的一致性，降低了维护难度。 业务逻辑与程序代码的分离( s e p a r a t i o no f l o g i ca n dc o d e ) 在程序外部定义业务规则，可以将形成业务逻辑的业务规则封装在一个规则 库中，应用程序通过统一的接口访问规则库，彻底地分离了业务规则与程序代码， 使得规则的修改与程序代码的修改互不干扰，有效降低了业务规则建模、测试和 修改的复杂度。 1 2 研究现状 作为一种技术，基于规则的编程方法在2 0 世纪8 0 年代就已经诞生，而且曾 随着人工智能的研究热潮达到顶峰。但是由于当时的规则引擎的性能较差，而且 没有与主流应用系统集成的能力和环境，因此没有得到很好的应用。到2 0 世纪 9 0 年代，随着面向对象开发方法的流行，类、封装、继承以及消息通信机制等 技术的出现为基于规则的程序提供了良好的集成和实现环境，对象模型可以和业 务规则模型完美的结合在一起。在这种背景下，业务规则方法形成理论并逐渐得 到青睐，而且在最近几年得到了较快的发展。研究表明，业务规则技术可以很好 地应用于信息系统的业务逻辑层的实现之中【”】。 业务规则方法的核心是业务规则引擎。一般认为，规则引擎是由基于专家系 统的推理引擎发展而来。它可以作为一种组件嵌入到应用程序之中，用来执行从 程序中分离出来的业务规则。规则引擎的主要工作是接受数据输入，解释业务规 则，并根据业务规则做出相应决策【1 6 】。 2 第一章绪论 随着技术的进步和市场的需要，目前已经出现了一些较为成熟的商业规则引 擎，其中最主要的是i l o g 公司的“一站式”业务规则管理系统j r u l e s 。j r u l e s 是 一个商业软件构件，在力1 a , j r u l e s 的信息系统中，用户可以用规则来描述他们的 商业逻辑，并且能正确地运行这些规则。除了商业产品，开源社区也有不少优秀 的规则引擎，其中的代表有j b o s sr u l e s 、m a n d a r a x 、j l i s a 等【3 0 】。这些开源引擎 尚不具备完善的规则管理功能，但某些已经拥有很好的推理效率和性能。 此外，为了协调不同厂商规则引擎之问在接口和a p i 调用方面的不同，提高 规则引擎之间的互操作性，在i l o g ，b e a ，b l a z e 等公司的发起下，j c p 于2 0 0 4 年8 月正式发布了j a v a 规则引擎a p i 规范，h i j j s r 9 4 。这是规则引擎领域的第一 个正式标准【7 j 。 对比而言，业务规则技术在实际项目中的应用情况还不够理想。目前，在商 业领域，业务规则技术只在金融、保险、电信、e r p 等项目中有所应用，针对一 般信息系统的应用还较为少见。 1 3 研究内容和本文的工作 管理信息系统是信息系统在管理领域的具体应用。高校科研管理部门承担着 高校的日常科研管理工作。随着我国科研水平的不断提高，科研课题的申报和立 项数量逐年增加，科研项目、经费和成果的管理及科研信息的收集、存储和分析 等任务越来越重。因此在高校建立个灵活有效的科技管理信息系统十分必要。 由于我国正处在一个快速发展的阶段，科研管理的相关政策经常变更，各类 项目的申请、审批和经费管理等方面的规定随时都会发生变化【2 3 1 。这要求开发 人员在进行系统设计时就要考虑应对业务逻辑的不断变化。 出于这种考虑，本文在构建天津大学科技管理信息系统的过程中，充分采用 业务规则方法的指导思想，将主要的易变业务逻辑的实现与业务逻辑本身加以分 离，使得系统可以很好地应对科技管理政策的变化，也可以方便后期对软件进行 修改和维护。从另一个角度说，这也是将业务规则方法应用于管理信息系统的一 次有益的尝试。 本文的主要研究工作有： ( 1 ) 对业务规则方法原理和规则引擎理论进行了深入研究； ( 2 ) 了解并掌握开源规则引擎j b o s sr u l e s 的原理、结构及使用等相关技术； ( 3 ) 结合业务规则方法原理和规则引擎j b o s sr u l e s ，针对天津大学科技管理 信息系统设计了一个基于业务规则方法的多层应用结构，并在此基础上实 现了该m i s 系统。 第一章绪论 1 4 论文的结构安排 第一章，主要介绍了课题的选题背景，研究现状，本文的主要研究内容和文 章的主要结构。 第二章，首先介绍了业务规则方法的基本原理，接着详细介绍了业务规则方 法的核心规则引擎的相关理论，最后介绍了规则引擎领域的第一个标准规范 j s r - 9 4 的相关技术细节。 第三章，在分析科技处管理信息系统的需求基础上，利用第二章介绍的业务 规则方法思想，详细论述了针对天津大学科技管理信息系统设计基于规则的多层 应用结构的全过程。 第四章，对第三章设计的基于规则的多层应用结构中核心组件的详细设计、 系统中和业务规则处理相关的各个主要方面的关键设计与实现进行了详细说明， 最后以两个典型应用组件的规则实现对系统的执行情况和性能进行了展示。 第五章，对全文进行了总结，并对下一步需要完善的工作进行了展望。 4 第二章相关理论和技术研究 第二章相关理论和技术研究 2 1 业务规则方法原理 作为一种新的软件设计思想，业务规则方法在2 0 世纪9 0 年代中期被提出， 经过十余年的发展，其理论方法已经被业界认可并走向成熟。与之相关的技术和 方法论已经在2 0 世纪末和本世纪初得到验证，结果表明其理论是完全正确的【2 1 】。 它提出的新的业务系统结构和建立业务系统的方法都是一次革命性的创新。业务 规则方法的核心思想就是整个业务系统必须以规则为核心进行构型1 0 】。 2 1 1 业务规则的概念 业务规则是一组准确凝练的语句，用于描述、约束及控制企业的结构、运作 和战略。具体地说，业务规则有两个层面的意思：从企业的角度看，业务规则是 一种原则，包含在特定活动或范围内关于指导、操作、实践或过程的行为规范； 从信息系统的角度看，业务规则是一个定义或限制业务某些方面的声明，旨在用 来断言业务结构，或者控制或影响业务行为【8 】。 2 1 2 业务规则的表达 对业务规则的表达源于人工智能领域的知识表示。知识是人们在改造客观世 界的过程中积累起来的经验及其总结升华的产物。知识表示是人工智能研究中最 基本的问题之。它是研究用计算机表示人类知识的可行性、有效性的一般方法， 是数据结构与系统控制结构的统一。通过知识表示，可以把人类知识表示成机器 能处理的数据结构。 知识表示方法种类繁多，分类的标准也大不相同，通常的方法有直接表示、 逻辑表示、产生式规则表示、语义网络表示、框架表示、脚本表示、过程表示、 混合型知识表示、面向对象的表示等方法【9 1 。在这些方法中，由于产生式知识表 示方法容易描述事实、规则以及它们之问的不确定性度量，因此可以用于方便地 表示业务规则。 产生式一词最早是由e p o s t 于1 9 4 3 年提出的。p o s t 根据串替换规则提出了 一种称为p o s t 机的计算模型，模型中的每一条规则就称为一个产生式。在产生 式知识表示方法中，事实和规则这样表达： ( 1 ) 事实可看成是断言一个语言变 量的值或是多个语言变量间的关系的陈述句，通常用三元组( 对象，属性，值) 5 第二章相关理论和技术研究 或( 关系，对象1 ，对象2 ) 来表示，其中对象就是语言变量。( 2 ) 规则用于表 示事物之间的因果关系，以i fc o n d i t i o nt h e na c t i o n 的单一形式来描述。其中 c o n d i t i o n 部分称作条件式的前件或模式，a c t i o n 部分称为动作、后件或者结论。 产生式的一般形式为：前件一后件。前件和后件也可以是由“与”、“或”、 “非”等逻辑运算符组合的表达式。条件部分常是一些事实的合取或析取，而结 论常是某一事实。 产生式的语义是：如果前件满足，则可得到后件的结论或者执行后件的相应 动作，即后件由前件来触发。一个产生式生成的结论可以作为另一个产生式的前 提或语言变量使用，进一步可以构成产生式系统。 多数较为简单的专家系统( e x p e r ts y s t e m ) 都是以产生式表示知识的，相应 的系统称作产生式系统。产生式系统由知识库和推理机两部分组成。其中知识库 由规则库和数据库组成。规则库是规则的集合，其中的规则以产生式形式表示； 数据库是事实的集合。推理机是一个程序，控制协调规则库与数据库的运行，包 含推理方式和控制策吲引。 般认为，规则引擎是基于专家系统中的推理机构建的，其工作方式也和推 理机的工作方式类似。所以，按照产生式知识表示法来表达业务规则顺理成章。 事实上，几乎所有的业务规则引擎都是以产生式规则的形式处理业务规则的。 2 1 3 基于规则的业务系统结构 基于规则的业务系统结构包含三个组成要素：结构、控制和过程。结构由业 务词汇和业务知识组成，业务词汇和业务知识是为业务人员所熟悉并在企业共享 的基本单词或词组及其之间的联系，它们包含了特定的业务含义；控制由体现业 务逻辑的业务规则组成；过程代表了完成业务活动所必需的流程和规程。三者独 立并统一地成为一个有机整体，它们的关系可以用下面的图2 1 来表示。 图2 - 1 结构、控制、过程的关系 可以看出，结构是系统的基本事物存在，是构建系统的基础；过程是系统的 最小活动单元，它基于结构而存在；控制是系统的核心组件，它控制过程的协调 运行，同时也是业务逻辑的表达形式，它也是建立在结构基础之上的。控制通过 规则对过程和结构施加影响，过程也可以通过事件影响控制和结构。 第二章相关理论和技术研究 2 1 4 业务规则方法的实施过程 采用业务规则方法构建业务系统，需要在系统构建过程中遵循下面的步骤： ( 1 ) 组织基本的业务知识，建立业务知识模型 组织基本的业务知识是建立业务系统的第一步，业务知识模型由业务词汇和 业务知识组成的集合构成。在建立业务知识模型时要保证业务人员使用的业务词 汇或业务知识在业务知识模型中是一致的、唯一的。这为以后确保所有的规则都 被一致地定义，并且不同的行动都以一致地形式展开创造了条件。 ( 2 ) 实施控制，建立规则控制模型 建立业务知识模型后，就能在业务知识模型提供的基本业务知识基础上，根 据业务的实际需要制定业务规则。在规则控制模型中只有唯一的要素规则。 ( 3 ) 引导活动，建立过程模型 过程模型包括三个要素：流程、规程和事件以及三者之间的联系。流程定义 了业务系统中的业务流，它是把若干规程串接起来完成某个业务项目的过程。规 程是最小的行为单元。事件是流程和规程的驱动力，可以来自内部或外部。 这一步骤就是根据前面两步完成的工作将过程模型建立起来，使得业务系统 可以正常运转起来。 2 1 5 业务规则方法的优势 业务规则方法是以业务规则为基础的在软件设计思想上的一种新的方法论， 它的开发目标就是确保实现更有自适应性的业务系统。相比于传统的软件构建方 法，它具有如下几个方面的优势【l o 】： ( 1 ) 产生尽可能多的业务能力 通过开发覆盖业务范围内业务能力的自顶向下的业务模型，业务规则方法可 以在系统中实现尽可能多的业务能力，建立业务问题与i t 组件问的良好映射。 ( 2 ) 建立最佳的业务解决方案 在为特定企业设计特定的业务能力方面，业务规则方法提供了一种崭新的思 路。它认为，企业达到业务目标永远都涉及到一些具体的企业风险，以及内在的 冲突和折衷。业务策略和业务规则都是解决这些风险、冲突和折衷的基础。业务 规则方法将这些策略和规则放在业务系统构建的首位，通过业务人员直接关注这 些影响业务的关键因素，可以产生客户最为满意的业务解决方案。 ( 3 ) 确保强有力的项目控制 业务人员参与核心业务规则的制定，可以使其对业务目标到所需业务能力有 一个清晰、简明和持续的理解。同时，组织方可以很容易地在项目生命周期的初 始阶段发现项目没有能够满足最初的业务目标，以便根据需要及时采取行动。 第二章相关理论和技术研究 2 2 规则引擎理论 2 2 1 规则引擎的定义 到目前为止，规则引擎还没有明确的定义。j s r - 9 4 是这样描述它的：一个 规则引擎可以被看作一个完善的i f t h e n 语句的解释器。这里的i f t h e n 语句一般被 称为规则。规则引擎的输入是一个规则集和一个初始数据对象集合，输出则是当 初始数据对象符合某些规则之后规则的执行结果【7 】。 通常认为，规则引擎由基于规则的专家系统中的推理引擎( i n f e r e n c ee n g i n e ) 发展而来，是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码 中分离出来，并使用预定义的语义模块编写业务决策。接受数据输入，解释业务 规则，并根据规则做出业务决策f l3 1 。 2 2 2 基于规则的专家系统 专家系统是人工智能的一个分支，它模仿人类的推理方式，使用试探性的方 法进行推理，并使用人类能理解的术语解释和证明它的推理结论。专家系统有很 多分类：神经网络、基于案例的推理系统和基于规则的系统等。 基于规则的专家系统( r b e s ) 主要包括三部分：规则库( r u l eb a s e ) i 工 作内存( w o r k i n gm e m o r y ) 和推理引擎( i n f e r e n c ee n g i n e ) 。如图2 2 所示： 图2 - 2 基于规则的专家系统示意图 在r b e s 中，推理引擎包括三部分：模式匹配器( p a t t e r nm a t c h e r ) 、议程 ( a g e n d a ) 和执行引擎( e x e c u t i o ne n g i n e ) 。p a t t e r nm a t c h e r 决定何时执行哪条 规则；a g e n d a 管理p a t t e m m a t c h e r 挑选出来的规则的执行次序；e x e c u t i o ne n g i n e 负责执行规则规定的动作。 推理引擎的推理方式大致上可以分为二种： ( 1 ) 演绎法：又称正向链推理( f o r w a r dc h a i n i n g ) 。它是从一个初始的事实 出发，不断地应用规则得出结论或执行指定的动作。 ( 2 ) 归纳法：又称反向链推理( b a c k w a r dc h a i n i n g ) 。它是从表示目标的谓词 或命题出发，不断寻找符合目标的事实，直到满足条件的事实都找到为止。 第二章相关理论和技术研究 2 2 3 规则引擎的一般结构 如上所述，规则引擎源于推理引擎，因此它和推理引擎具有极大地相似性。 规则引擎的一般结构如图2 3 所示： r u l ee n g i n ec o r e b r a u s l e e - a g e n d a b a s e c o n f l i c t s t r a t e g y r u l e e x e c u t i o n w o r k i n gm e m o r y r u l ee n g i n ea p i 图2 3 规则引擎的一般结构 可以看出，规则引擎主要由规则引擎a p i 、规则集( r u l eb a s e ) 、工作内存 ( w o r k i n gm e m o r y ) 、议程( a g e n d a ) 、冲突消解器( c o n f l i c ts t r a t e g y ) 和执 行上下文( e x e c u t i o nc o n t e x t ) 几部分组成： ( 1 ) 规则引擎a p i 是与规则引擎进行交互的接口部分。包括了操作规则引擎的 必需方法调用。所有的操作，包括规则集和事实对象的注入、删除、更新 以及引擎执行结果获取都要通过该模块完成。 ( 2 ) 规则集是针对当前事实对象的规则的集合，它代表了要实现的业务逻辑， 也是关注的核心内容之一。 ( 3 ) 工作内存是用来存放所有加载到规则引擎中的事实对象的内存空间，它处 于规则引擎的管辖之下。 ( 4 ) 议程存储了当前所有匹配成功的规则实例。一条规则包含条件( c o n d i t i o n ) 部分和活动( c o n s e q u e n c e ) 部分，当条件部分匹配成功后就执行其活动部 分。议程通过参考冲突消解策略来管理所有匹配成功的规则的执行顺序。 ( 5 ) 冲突消解器，也即冲突消解策略。规则引擎的工作方式决定了在某一时刻， 规则集中可能有超过一条的规则被激发( a c t i v a t e d ) ，此时就需要对规则 的执行顺序加以约束，以保证业务逻辑可以正确的实现。冲突消解器就用 来扮演这一角色，它通过预先设定规则冲突解决策略来解决规则匹配过程 中的冲突问题。典型的冲突消解策略包括：优先级原则，先来先执行等。 ( 6 ) 执行上下文本质上就是一个规则实例解释器，它执行当前被议程输出的规 则的活动( c o n s e q u e n c e ) 部分。 2 2 4 规则引擎的工作机制 9 第二章相关理论和技术研究 规则引擎的基本工作机制是：首先将规则集和事实对象通过规则引擎a p i 提 交给引擎；引擎通过自身的模式匹配器对投入工作内存的事实对象进行高效的匹 配，根据这些对象的当前属性值和它们之间的关系，从加载到引擎的规则集中发 现符合条件的规则，创建这些规则的执行实例；这些实例被依次放入议程，然后 议程根据冲突消解策略，在这些实例接到执行指令时，按照确定的次序依次执行； 同时，由于规则的活动部分可能会改变工作内存中的事实对象，从而会使议程中 的某些规则执行实例因为条件发生改变而失效，从而必须从议程中撤销；也可能 会激活原来不满足条件的规则，生成新的规则执行实例进入议程。这样，就产生 了一种“动态”的规则执行链，形成规则的推理机制。这种规则的“链式”反应 完全是由工作内存中的数据驱动的【h 】。 2 2 5 规则引擎的使用方式 由于规则引擎是软件组件，所以只有开发人员才能通过程序接口的方式来使 用和控制它。通常要求规则引擎的程序接口至少包含以下三种a p i ： ( 1 ) 加载和卸载规则集的a p i ； ( 2 ) 数据操作的a p i ； ( 3 ) 引擎执行的a p i 。 开发人员在程序中使用规则引擎基本遵循以下5 个典型的步骤： ( 1 ) 创建规则引擎对象； ( 2 ) 向引擎中加载规则集或更换规则集； ( 3 ) 向引擎提交需要被当前规则集处理的数据对象集合； ( 4 ) 命令引擎执行； ( 5 ) 导出引擎执行结果，从引擎中撤出处理过的数据。使用了规则引擎之 后，许多涉及业务逻辑的程序代码基本被这五个典型步骤所取代。 一个开放的业务规则引擎可以“嵌入 应用程序的任何位置，不同位置的引 擎可以使用不同的规则集，用于处理不同的数据对象，对引擎的数量也没有限制。 2 2 6 规则匹配算法 前面提到，规则引擎需要通过对当前工作内存中的事实对象和规则集中规则 的条件进行匹配以获得可执行的规则实例，这种对条件的匹配效率在很大程度上 决定了规则引擎的性能。因此，一个好的规则引擎必须解决规则的匹配效率问题。 1 9 8 2 年美国卡内基梅隆大学的c h a r l e sl f o r g y 发明了r e t e 算法，很好地解决了 多数据多模式的匹配效率问题【3 2 】。目前世界顶级的商业规则引擎基本上都采用了 r e t e 算法或者基于它的改进算法。下面详细介绍一下这个算法的原理【1 0 j 。 1 0 第二章相关理论和技术研究 首先研究一下通常情况下如何匹配事实对象和规则，如图2 _ 4 。如果匹配过 程只需一次，那么答案十分简单。推理机可以检查每条规则并寻找一套事实来决 定规则的模式是否已经满足。如果是，就将此规则记入议程，如图2 5 。 图2 - 4 模式匹配规则和事实图2 5 规则寻找事实 然而，在基于规则的语言中，匹配过程不断重复进行。通常，事实对象列表 在每次执行中都会被修改：或添加新的事实对象到事实对象列表，或删除l e t 的事 实对象。这些改变可以使先前不满足条件的模式得到满足，反之亦然。匹配问题 因此成了不断进行的过程。在每次循环中，随着事实对象的添加和删除，必须对 已满足条件的规则集合进行维护和更新。 在每次循环后，令推理机检查每条规则以指导对事实对象的寻找，为解决这 个问题提供了简单直接的技巧。但是这种方法速度太慢。大多数基于规则的系统 都显示了时问冗余性( t e m p o r a lr e d u n d a n c y ) 的特征。就是说，一条规则的运 行或者数据库中数据的更新一般仅会改变事实对象列表中少数事实，系统中的事 实对象随时问改变的速度很慢，所以事实对象列表中的变化一般只影响很少的一 部分规则。因此，让规则推动对所需事实的寻找，需要大量不必要的计算，因为 在当前循环中，大多数规则所找到事实很可能与上一次循环所找到的相同。图 2 - 6 显示出这种低效的方法，阴影部分代表了对事实列表所做的改变。如果在不 断循环中，通过记住那些己经匹配好的，然后只计算那些刚添加或删除事实所引 起的必要变化，可以避免不必要的计算，如图2 7 ：规则是不变的，而事实对象 是变化的，所以应是事实寻找相应的规则，而不是规则寻找相应的事实。 图2 - 6 规则寻找事实产生不必要的计算图2 7 事实寻找规则 r e t e 模式匹配算法正是利用了基于规则的系统所具有的时间冗余性。它存储 第二章相关理论和技术研究 不断循环的匹配过程中的状态，并且只重新计算在事实对象列表中发生了变化、 又反映到本次循环中的事实。也就是说，如果在一次执行周期中，一组模式找到 三个所需要的事实中的两个，那么在下一周期中，就无需对己经找到的这两个事 实进行检查，只有第三个事实才是需要关注的。仅当添加或删除事实对象时，匹 配过程的状态才会被更新，如果添加、删除事实的数量与事实和模式的数量相比 很小，那么匹配过程会进行得很快。最糟的情况是，如果所有的事实都改变了， 那么所有的事实将与所有的模式进行匹配。 此外，通过利用规则的结构相似性( s t r u c t u r a ls i m i l a r i t y ) 的优点，r e t e 算 法同样会提高基于规则的系统的效率。结构相似性是指许多规则通常包含了相似 的模式或模式群。利用这一特性，r e t e 算法通过将模式的公共部分放在一起来提 高效率，因为公共部分不必多次计算。 r e t e 算法的主要缺点是内存使用量大。将所有的事实与所有的模式进行简单 的比较不需要使用内存，但是，存储使用了模式匹配和部分匹配的系统的状态会 消耗大量的内存。 2 3j s r 9 卜j a v a 规则引擎a p i 2 3 1j s r 一9 4 简介 为了能够在商业应用中一致规范地使用不同厂商的规则引擎产品，j c p ( j a v a c o m m u n i t yp r o c e s s ) 在2 0 0 3 年11 月完成了j a v a 规则引擎a p i 标准的最终草案， 艮i j s r 9 4 。该规范于2 0 0 4 年8 月正式发布1 7 j 。 j a v a 规则引擎a p i 是访问规则引擎的标准企业级a p i 。它允许客户程序使用 统一的方式与不同厂商的规则引擎产品交互，就像使用j d b c 编写独立于厂商访 问不同的数据库产品一样。它主要包括创建和管理规则集合的机制，在工作内存 中添加、删除和修改对象的机制，以及初始化、重置和执行规则引擎的机制。 2 3 2j s r 9 4 结构 j s r 一9 4 把外部与规则引擎的交互分为两类：规则管理a p i 和运行时a p i 。 1 规则管理a p i 规则管理a p i 在i a v a x r u l e s a d m i n 中定义，它主要包括装载规则集和实例化 规则引擎的相关调用。规则管理a p i 使用r u l e s e r v i c e p r o v i d e r 来获得规则管理器 ( r u l e a d m i n i s t r a t o r ) 的实例。规则管理器提供了r u l e e x e c u t i o n s e t p r o v i d e r 。它 负责从u r i ，s t r e a m s 或r e a d e r s 等来源中创建规则执行集。这些数据源及其内 容经汇集和序列化后传送到运行规则引擎的服务器上。 1 2 第二章相关理论和技术研究 r u l e e x e c u t i o n s e t p r o v i d e r 除了拥有能够获得有关规则执行集的方法，还拥有 能够检索在规则执行集中定义的所有规则对象的方法。这使得用户能够知道规则 集中的规则对象并且按照自己需要来使用它们。 2 运行时a p i 运行时a p i 定义在j a v a x r u l e s 包中，它为规则引擎用户运行规则和获得结果 提供了相关的类和接口。用户在运行时只能访问那些使用规则管理a p i 注册过的 规则，运行时a p i 帮助用户获得规则会话并且在这个会话中执行规则。 运行时a p i 提供了对不同厂商规则引擎a p i 实现的类似于m b c 的访问方 法。规则引擎厂商通过类r u l e s e r v i c e p r o v i d e r 将其规则引擎实现提供给用户，并 获得r u l e s e r v i c e p r o v i d e r 唯一标识规则引擎的u r l 。 运行时接口是运行时a p i 的关键部分，它提供了用于创建规则会话的方法， 同时也提供了访问在r u l e s e r v i c e p r o v i d e r 中注册过的所有规则执行集的方法。规 则会话接口定义了用户使用的会话类型，用户根据自己运行规则的方式可以选择 使用有状态会话或者无状态会话。 2 3 3j s r 一9 4 关于规则定义语言的规定 j s r 9 4 中没有涉及规则定义语言，而它本身是规则引擎的重要组成部分。 由于没有关于规则如何定义的公共规范，大多数流行的规则引擎都有自己的规则 定义语言，这使不同厂商的规则引擎之间的兼容性成为问题。目前业界还没有就 规则定义语言标准形成共识，不过就国际趋势来看，基于x m l 的规则定义语言 r u l e m l 或许可以在未来成为规则定义语言的标准。这可能也是j s r - 9 4 没有对规 则定义语言进行标准化的原因之一【7 】【1 5 】。 2 4 本章小节 本章主要介绍了和本文工作密切相关的基础理论和技术知识，包括业务规则 方法原理、规则引擎理论和j s r 9 4 的相关内容。业务规则方法原理为本文提供 了根本的理论支持；规则引擎技术是实现业务逻辑规则化的基础，同时也是业务 规则方法的核心；j s r 9 4 是业务规则引擎领域的第一个标准规范，它通过定义 通用的接口使得采用不同厂商规则引擎产品的软件系统方便地实现引擎的移植 成为可能。 第三章基于业务规则