drools规则引擎用户手册剖析

上传人:今*** 文档编号:105875596 上传时间:2019-10-13 格式:DOC 页数:209 大小:5.60MB
返回 下载 相关 举报
drools规则引擎用户手册剖析_第1页
第1页 / 共209页
drools规则引擎用户手册剖析_第2页
第2页 / 共209页
drools规则引擎用户手册剖析_第3页
第3页 / 共209页
drools规则引擎用户手册剖析_第4页
第4页 / 共209页
drools规则引擎用户手册剖析_第5页
第5页 / 共209页
点击查看更多>>
资源描述

《drools规则引擎用户手册剖析》由会员分享,可在线阅读,更多相关《drools规则引擎用户手册剖析(209页珍藏版)》请在金锄头文库上搜索。

1、Drools规则引擎 目 录 第一章 规则引擎初步了解51 为什么会有规则引擎?52 什么是规则引擎?53 为何要使用规则引擎?63.1 声明式编程63.2逻辑与数据分离63.3 速度及可测量性63.4 知识集中化63.5 工具集成63.6 解释机制63.7易懂的规则74 何时应当使用规则引擎?75 如何使用规则引擎?76 何时不要使用规则引擎 ?87 规则引擎的架构和推理88规则引擎的算法109 Java规则引擎商业产品1010 Dools介绍11第二章.Drools 规则引擎112.1.概述112.2.编制132.3.RuleBase182.4.WorkingMemory 和有状态/无状态

2、Sessions222.5.StatefulSession282.6.StatelessSession292.7.Agenda312.8.Truth Maintenance with Logical Objects342.9.事件模型(Event Model)372.10.顺序模式41第三章.安装和设置(Core 与IDE)423.1.安装和使用423.1.1. 依赖库423.1.2.运行时(Runtime)433.1.3.安装IDE (规则工作台)433.2.从源码进行安装543.3.源码Checkout543.4.构建593.4.1.构建源码593.4.2.构建使用手册613.5.Ecli

3、pse653.5.1.产生Eclipse项目653.5.2.导入Eclipse项目663.5.3.导出IDE插件713.5.4.构建更新站点76第四章.决策表784.1. 在电子表格中的决策表784.1.1.何时使用决策表784.1.2.概述794.1.3.决策表如何工作814.1.4.关键字和语法834.1.5.基于决策表建立并集成电子表格874.1.6. 在决策表中管理业务规则88第五章.规则工作台 (IDE)895.1.Introduction895.1.1.特性概要905.1.2.建立规则项目905.1.3.新建规则向导925.1.4.规则编辑器945.1.5.视图955.1.6.领域

4、规范语言DSL985.1.7.The Rete视图1005.1.8.大容量DRL文件1015.1.9.调试规则102第六章.规则语言1036.1.概述1036.1.1. 规则文件1036.1.2.规则的构成1046.1.3.保留字1046.2.Comments注释1066.2.1.单行注释1066.2.2.多行注释1066.3.Package1076.3.1.import1086.3.2.expander1086.3.3.global全局变量1086.4.Function1106.5.Rule1116.5.1.Rule 属性1126.5.2.LHS (when) 条件元素1156.5.3.Th

5、e Right Hand Side (then)1406.5.4.对自动封箱/拆箱以及元数据类型的注解1416.6.Query1416.7.Domain Specific Languages 领域特定语言1426.7.1.何时使用DSL1426.7.2.编辑与管理DSL1436.7.3.在规则中使用DSL1446.7.4.增加对fact的约束1456.7.5.DSL如何工作1466.7.6.从头开始建立DSL1466.8.规则流1476.8.1.设置规则所属的规则流组1486.8.2.简单的规则流1486.8.3.如何建立规则流1486.8.4.在你的应用程序中使用规则流1536.9.XML规

6、则语言1536.9.1.何时使用XML1536.9.2. XML 格式1546.9.3.遗留的Drools 2.x XML 规则格式1596.9.4.Automatic transforming between formats (XML and DRL)159第七章:部署和测试1607.1.部署选项1607.1.1.使用RuleAgent部署1607.1.2.使用drl源码部署1617.1.3.在你的classpath中部署规则1617.1.4.可部署的对象RuleBase, Package等等.1617.1.5.部署模式1637.1.6.Web Services1667.1.7.未来的构想1

7、667.2.测试1667.2.1.测试框架1667.2.2.FIT for Rules 一种规则测试框架166第八章. BRMS (业务规则管理系统)1688.1.简介1688.1.1.什么是BRMS?1698.1.2.特性概要1708.2.管理指南1708.2.1.安装1718.2.2.数据库配置1728.2.3.安全性1738.2.4.数据管理1768.3.体系结构1788.3.1.从源码构建1798.3.2.可重用组件1808.3.3.版本和存储库1808.3.4.贡献1818.4.快速使用指南1818.4.1.快速使用指南1818.4.2.BRMS 概念1838.4.3.The bus

8、iness user perspective1978.4.4.部署: 将规则与你的应用集成1978.5.例子与教程2008.5.1.保险经济折扣200第九章. Java规则引擎API2029.1 简介2029.2 java规则引擎API体系结构2029.3 规则管理API2029.4 运行时API2039.5 java规则引擎API的安全问题2049.6 异常与日志2059.7 JSR小结2059.8 Dools API 参考2059.8.1 简介2059.8.2.如何使用2059.8.3.参考书目209第一章 规则引擎初步了解1 为什么会有规则引擎?背景:复杂企业级项目的开发以及其中随外部条

9、件不断变化的业务规则(business logic),迫切需要分离商业决策者的商业决策逻辑和应用开发者的技术决策,并把这些商业决策放在中心数据库或其他统一的地方,让它们能在运行时(即商务时间)可以动态地管理和修改从而提供软件系统的柔性和适应性。规则引擎正是应用于上述动态环境中的一种解决方法。企业管理者对企业级IT系统的开发有着如下的要求:为提高效率,管理流程必须自动化,即使现代商业规则异常复杂;市场要求业务规则经常变化,IT系统必须依据业务规则的变化快速、低成本的更新;为了快速、低成本的更新,业务人员应能直接管理IT系统中的规则,不需要程序开发人员参与。2 什么是规则引擎?也许这又是一种“先有

10、蛋还是先有鸡”哲学争论,在JSR-94种也几乎没有定义,规则引擎这个术语是非常不明确的,因为任何以任意形式使用能够应用于数据生成结果的规则的系统都可以称为规则引擎。包括像表单验证和动态表达式引擎这样的简单系统都可以称之为规则引擎。可以这样理解规则引擎由推理引擎发展而来,是一种嵌入在应用程序中的组件,实现了将业务决策从应用程序代码中分离出来,并使用预定义的语义模块编写业务决策。接受数据输入,解释业务规则,并根据规则做出业务决策。3 为何要使用规则引擎?3.1 声明式编程规则引擎允许你描述做什么而不是如何去做。这里的主要优点是使用规则更加容易对复杂的问题进行表述,并得到验证。 (规则比编码更容易阅

11、读). 规则系统能够解决非常非常困难的问题,并提供了方案怎样达到和在解决问题的方向上所作的每一个决定的原因(这对于类似神经网络这样的AI系统来说不容易达到)3.2逻辑与数据分离数据保存在系统对象中,逻辑保存在规则中。这根本性的打破了面向对象系统中将数据和逻辑耦合起来的局面,这点是有利的也是不利的,在于你的观察角度。这样做的结果是,将来逻辑发生改变时更容易被维护,因为逻辑保存在规则中。这点在逻辑是跨领域或多领域中使用时尤其有用。通过将逻辑集中在一个或数个清晰的规则文件中,取代了之前分散在代码中的局面。3.3 速度及可测量性Rete算法、Leaps算法,以及由此衍生出来的Drools的Rete、L

12、eaps算法,提供了对系统数据对象非常有效率的匹配。这些都是高效率尤其当你的数据是不完全的改变(规则引擎能够记得之前的匹配)。这些算法经过了大量实际考验的证明。3.4 知识集中化通过使用规则,将建立一个可执行的规则库。这意味着规则库代表着现实中的业务策略的唯一对应,理想情况下可读性高的规则还可以被当作文档使用。3.5 工具集成例如Eclipse(将来可能在基于Web的界面上)这样的工具为规则的修改与管理、即时获得反馈、内容验证与修补提供了办法。审查与调试工具同样也可用了。3.6 解释机制通过将规则引擎的决断与决断的原因一起记录下来,规则系统提供了很好的“解释机制”。3.7易懂的规则通过建立对象

13、模型以及DSL(域定义语言),你可以用接近自然语言的方式来编写规则。这让非技术人员与领域专家可以用他们自己的逻辑来理解规则(因为程序的迷宫已经被隐藏起来了) 。4 何时应当使用规则引擎?最简短的回答就是“当没有令人满意的传统的程序设计方法能够解决这个问题时”。下面对这个所谓的传统解决方法的一个描述: 对于传统代码来说,问题需要的精确度太高。这种问题可能并不复杂,但是你找不到一种稳定的方法去建立它。 问题超越了任何有明显运算法则的方案。 它是一个难以解决的复杂问题,没有明显的传统解决方案或者问题没有一个准确的定论。 业务逻辑经常发生改变逻辑本身是简单的(但不是指过于简单),但是规则经常发生变化。

14、在许多软件组织中正式版本的间隔是较长并且较少的,规则可以在适当的安全前提下帮助提供一定的敏捷性。 领域专家(或者业务分析师)是非技术人员领域专家通常对业务规则和流程具有很好的认知。他们通常是不了解软件技术的人员,但是具有很好的逻辑性。规则能够让他们用自己的术语来描述业务逻辑。当然他们仍然需要严密的思考和良好的逻辑思维能力(许多在非软件技术型岗位上的人没有进行过形式逻辑的训练,因此在和他们工作时要特别小心,在将业务知识编撰成规则时,要特别注意业务规则和流程应当是当前能够理解的)。 5 如何使用规则引擎?由于规则引擎是软件组件,所以只有开发人员才能够通过程序接口的方式来使用和控制它,规则引擎的程序接口至少包含以下几种API:l 加载和卸载

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 高等教育 > 大学课件

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号