Jess--专家系统

mql416

用EMF设计Rule-Based系统模型
概述
现今已有很多用ECore模型定义实例和相关数据模型的例子。Rule-Based系统模型的介绍却不是很多。文章用Ecore模型定义了一个建立Rule-Based系统模型的超模型。通过这个超模型可以建立用来解决实际逻辑问题的普通模型，剩下的就是将这个模型做成jet模板和一般的通用代码，并在虚拟机上调试通过以解决实际需求。
作者：Chaur G. Wu(独立咨询公司)
email:cha_urwu@hotmail.com
2004年11月30日
——————————————————————
专用词汇(译者加的)
看文章之前,先让我们了解一下文章的背景和文章中所用的专用词汇.这里我们将给出Rule-Based系统模型和超模型的解释和说明.
Rule-Based系统模型
Rule-Based系统模型到底是什么东西呢?还记得70年代到80年代的计算机发展史么?人们研究了一种叫做人工智能的技术,用来使计算更加像人一样思考.很多看起来能够像人一样思考和对话Rule-Based程序范例也在那个时代大量的涌现出来.一个很经典的例子就是专家系统.它模拟了一个医生或者一个税款咨询员,它能够像专家一样回答人们的一些复杂的问题.(但他们仍然是机器)
Rule-Based程序向人们展示了一个新的专业名词-rules.Rule-Based系统模型这个名字就是由此而来的.除了rules还有一个重要的Rule-Based系统模型名词叫做facts.这里有个例子:约翰是一个气象预报员,每天他都要通过电视节目向人们预报天气情况.因此约翰关于天气的知识结构可能就是这样的:
1,如果今天是雨天,就应该建议人们在外出时带雨伞.
2,如果今天是雨天,路就会很滑,就应该告诫开车的司机师傅要小心一些.
我们把这个知识转化为Rule-Based系统模型就应该是:
Rule 1:如果今天下雨,建议人们出去的时候带雨伞.
Rule 2:如果今天路滑,告诫司机们要小心些.
Rule 3:如果今天下雨,路就会滑.
Fact 1:今天是雨天.
Fact 2:路很滑.
我们想象着虚拟一个向气象预报员约翰一样的专家系统.我们看到窗外下雨了,然后我们告诉系统现在下雨了.这正是我们的Fact 1.系统可以通过以上的3条规则,找出与"下雨了"相关的规则-Rule 1和Rule 3.通过规则Rule 1系统会建议人们出去时候要带伞.通过规则Rule 3联系规则Rule 2(规则3满足规则2的条件),通过规则Rule 2,系统会建议司机朋友们路上要小心.可以看出以上所有的一切都是由事实Fact 1连锁反应得出的回答.
这个例子并不复杂.但是通过它,我们会发现Rule-Based系统的几个关键的地方需要注意:
1,一个Rule-Based系统主要由3部分组成:facts,rules,和事情的驱动引擎engine.
2,Rules在这里代表了知识,Facts代表了数据.而一个Rule-Based系统就是通过把规则表示成数据而解决问题的.
3,一个Rule由2部分组成,条件和行为.
4,一个Rule可能会产生新的rules,(就像规则2的产生)
在当今流行的一些规则引擎中,JESS是一些java开发者中最为流行的一个.它参考jsr 094 java 规则引擎Api，并成功开发出在eclipse中实现对规则系统开发插件。文章中的关于规则的一些代码都会采用jess标准.(以下是jess的介绍，这里删除)
模型，超模型，超超模型
将模型进行不同等级的分类是很有好处的.当一个模型的作用是用来定义制作模型时,我们就会将这个模型叫做超模型.当模型是用来定义超模型时,就叫做超超模型,(以此类推).
例如,Ecore是一个模型.当我们把它用在不同的方法上时,它就会被叫做模型或者是超模型或者是超超模型(但只能有一个叫法).当我们使用Ecore去定义一个购物模型时，它就是一个超模型.这里开发的Rule-Based系统模型也是一个超模型.Rule-Based系统模型也是通过Ecore模型建立的,这个时候,Ecore就是一个超超模型.这个时候我们利用Ecore模型定义了一个超模型.(这里省略了另一个例子)
当我们用模型甲定义模型乙,我们说乙是甲的一个实例.(译者加的,便于理解)而所有用乙模型定义的模型元素都可以认为是甲的模型元素.在文章中,这样的问题会经常出现.为了便于阅读,一些有用的提示如下:
1,没有绝对的模型,超模型和超超模型.也就是说模型的分类没有绝对的.
2,文章使用Ecore定义Rule-Based系统模型
3,Rule-Based系统模型中的模型元素也是Ecore的模型元素(继承原理).
4,Rule-Based系统模型可以定义解决实际逻辑问题的模型.其模型中的元素也是Rule-Based系统模型的元素(还是继承原理).
5,超超模型也被叫做m3模型,超模型也叫做m2模型,模型也叫做m模型.
问题陈述
假设有一个我们要解决的逻辑问题:
有4个编号分别为1,2,3,4的盒子,和4个颜色分别为红,蓝,绿,黄的球.我们将球放到盒子里.规则如下:
1,如果要把红球放到盒子1中,那么必须把篮球放到盒子3中.
2,如果没有把黄球放到盒子2中,那么必须把绿球放到盒子3中.
3,绿球不能被放到盒子4中,红球也绝对不能放到盒子2中.
建立问题的运行环境,运行测试代码
文件RuleMetaModel.zip和BallPlacementRuleModel.zip包含了解决问题的示例代码.示例代码文件的运行需要下面一些软件:
Java Runtime or SDK (The one I use is Java SDK 1.4.2 from Sun Microsystems)
Eclipse (The version I use is Eclipse SDK 3.0)
EMF (The version I use is EMF SDK 2.0.1 RC2)
JESS 7.0a1
JESS的安装很简单.具体可以参考JESS的官方文档http://herzberg.ca.sandia.gov/jess/download.shtml.将以上的2个压缩文档解压后,设置好jess.jar的配置路径.jess不是一个免费软件.当你登陆上面给出的地址你就会发现软件的注册需要你填写一些你的基本信息,如姓名,单位,email之类.简单的注册后,下载页面就会出现.本文使用的是7.01的a1版本.*这个版本的jess是通过插件的形式与eclipse接口的.*文章中提到的程序均不使用到这些插件,因此用户可以选择是否安装这些插件.
解压RuleMetaModel.zip到plugins下的子文件夹中.可以看到它包含3个插件,分别为模型,编辑,EMF为基础的Rule超模型.解压另一个文件BallPlacementRuleModel.zip,可以看出它包含2个文件BallPlacement.rulemetamodel和allPlacement.clp.BallPlacement.rulemetamodel正是我们的逻辑问题的模型.它正是通过Rule超模型制作而成的.另一个文件BallPlacement.clp是通过BallPlacement.rulemetamodel继承下来的.下面是一些关于组件和组件之间的关系的一些图示说明.
图表1,示例代码的总体结构.
我将伴随着程序的运行演示来讲解我的程序.目前,我们已经安装好了jess规则引擎,(假设我们将BallPlacement.clp得两个文件解压缩到c:\并且jess的路径设置也完全正确)让我们开始我们的程序之旅.让我们在jess规则引擎下运行BallPlacement.clp(图表1的黄色部分):
java jess.Main C:\BallPlacement.clp
在下面的窗口中,我们可以看到运行后的结果.可能你会说控制台下的显示方式并不美观,但是它却准确的表示了我们的目地.而最后的4个facts就是我们上面逻辑问题的解答.这正如我们所预料到的,在球和盒子的24中不同的组合中,只有4种情况满足我们给出的要求.
BallPlacement.clp
在我们可以更好的理解Rule超模型和Ball Placement模型之前,先通过观察BallPlacement.clp来对rule语言有一个更清楚地了解。这些知识可以使我们对以后的超模型和模型有个好的理解.BallPlacement.clp定义了2个模板:1,placement和2ball.
1,(deftemplate placement
(slot box_one)
(slot box_two)
(slot box_three)
(slot box_four))
2,(deftemplate ball (slot color))
fact template正如他的名字一样，是一个用jess定义模板定义的一个facts的模板.在前面的例子中,我们将天气的fact表示成:(rainy-day).如果我们加入温度到天气中,我们将这个fact表示成:(rainy-day 50F).像这样其元素具有一定顺序的facts，我们将其称为规则facts.在规则facts中,(rainy-day 50F)和(50F rainy-day)是不一样的.有些时候,我们需要把这些事实组织结构化而不去关心它们具体的顺序.这样我们可以更好的组织其中元素.根据rules模板,我们可以将facts表示为:(weather-report(weather rainy-day)  (temperature 50F)).这样,一个天气预报的fact包含2个接口:天气和温度.天气接口的值为rainy-day,温度接口的为50F.在表示的时候，温度和天气的先后是没有关系的.这样的facts表示方法叫做无规则facts.
现在在回到我们的例子上来,我们需要4个接口来对应每一个盒子.球的模板也采用1个接口:颜色.我们可以使用这两个模板将fact: "绿色的球在盒子1中"表示为(placement (box_one green)).除了这些fact模板外,BallPlacement.clp还有其他的一些rules.下面是第一条规则的rule描述:
(defrule placement_constraint1
?placement  
(retract ?placement))
从上面的描述,我们可以知道rule的名字为placement_constraint1.##1##2是rule的条件.##3是rule的行为.条件##1定义了环境变量.事实上,真正可以定义环境变量的是与类型相对应的fact.在jess中,像box_one,box_two等出现在变量表中的变量是可以改变的.变量是没有赋类型的.它可以表示任何strings,integers,facts或其他的数据类型.通常,一个变量的值是通过一个这样的程序来被赋值的.
(bind ?variable "some string value")
注意,使用这个程序来给变量赋值是一个行为,而不是一个条件.因此,在1中我们使用了一个叫做pattern binding的特殊框架,而不是使用上面的那个程序.条件2有两个与逻辑与相对应的facts.逻辑与在规则语言中也被叫做条件元素.他们并不是很神秘.当我们将下面的一些放到规则引擎中,会发生什么?
(placement (box_one Red) (box_two Blue) (box_three Green) (box_four Yellow))
规则引擎将会尝试着把这些facts是否与placement_constraint1条件对应.其过程就类似的与前面的weather例子有些相似了.
Rule朝模型
现在我们知道了规则语言中诸如patterns, actions, rules, facts的基本结构.下面我们将要讨论我们如何将他们组织成一个超模型.一个Rule超模型包括1个包装，1些数据类型，枚举类型，和类。正如我们以前所说，Rule超模型由Ecore定义，所有Rule超模型的元素都是Ecore的元素的实例。在Rule超模型中，唯一的封装仍然是Ecore的Eclass的一个实例。
下面是Rule超模型在Eclipse中的表示。
图例2，Rule超模型
数据类型
规则语言与java语言不同，它是没有数据类型的。在前面BallPlacement.clp的例子中，我们是看不出球，颜色，还有放置这些的类的类型的。虽然语言本身并没有类型定义，但是具体的规则引擎中的规则语言中，数据是必须有其类型的。例如球，颜色，放置方法的类型叫做符号。就像"something"是字符串类型是一样的。而这些都被称为原始类型或者数据类型。大多数规则语言支持原始类型的通常构成。但是有些类型却只存在于特定的语言中。正确的理解规则语言中的象字符串，或浮点这样的数据类型是很重要的。他们被不同语言通过不同的方式所定义，并在由不同的虚拟机所支持和解释。所以在我们的规则模型中，我们必须使用我们自己的数据类型。
Rule超模型中具有6种不同的数据类型。他们都已经采用java类进行了封装。下面的表格列出了所用的数据类型。
当我们定义一个数据类型的时候，除了要实现对应的java类的接口扩展之外，往往需要重新为一些实例的数据类型编码。在我们的例子中，我重写了com.example.rule.ecore.rulemetamodel.impl中的createRSymbolFromString()和其他5个相似的数据类型。
一个超模型应该创立尽可能的独立平台。任何一种只能为一种特别的语言服务的Rule超模型是没有多大用处的。一个完整的Rule超模型应该可以包含所有流行的规则语言的数据类型。数据类型专有得到一种特定的规则语言能在m1水平作模型。因为我们的模型是面对一种很专业的，所以只完成一般的数据类型的设置远远不够。
球放置规则模型
根据我们的规则模型的3个插件，我们可以使用它来解决我们的逻辑问题。启动eclipse建立一个新工程，选择文件-新工程

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/30529/showart_234841.html