主页 > 饮食 > > (决策表怎么做)决策表不会做
最佳回答 最佳答案

本回答由网友推荐

十年寄

基于规则引擎的企业服务开发模式陶晓俊,朱敏(华东师范大学信息科学技术学院计算中心,上海200062)摘要:本文围绕规则引擎技术分离业务流程和业务规则的思想,探讨并提出一套有效使用规则引擎技术开发企业服务应用系统时所遵循的开发模式,其中包括设计一种基于规则引擎的企业服务模型;提出实际开发过程中紧密结合规则引擎思想,使用规则引擎技术实现企业服务应用的具体步骤和方法关键词:规则引擎JSR-94Rete算法DroolsPatternofBuildingEnterpriseServiceswithRuleEngineTAOXiao-jun,ZHUMin(ComputerCenter,EastChinaNormalUniversity,Shanghai,200062,China)Abstract:ThisarticlewillstudyandadvanceapatternwhichisbasedontheideaofruleengineforpracticalbuildingenterpriseservicesthatusingruleenginetechnologyeffectivelyandhandyThepatternincludesamodelofenterpriseservicesbasedonruleengine,andthestepandprocessofdevelopingenterpriseservicesusingruleenginetechnologyKeyWords:RuleEngineJSR-94ReteArithmeticDrools1引言规则引擎是用以管理和自动实现业务规则的软件系统,其主要实现的功能是存储,分类和管理规则,验证规则的一致性,通过规则推断其它规则,联系规则和执行这些规则的应用程序,其中的规则主要是指企业或商务业务逻辑,法律条款,企业政策等规则引擎概念的思想是从软件的应用逻辑中分离出商业规则,以实现商业应用的灵活性在传统的企业服务应用程序开发模式下,业务逻辑被直接固定在应用程序代码中,这使得应用程序维护复杂并且代价昂贵,变化的商业规则和业务流程总是引起对应用程序的频繁修改,尤其面临动态商业模型和业务流程的挑战时,传统模式下开发的应用程序往往面临全面和代价高昂的修改,甚至设计变化解决这个问题就需要采用新的开发模式,将业务逻辑从代码层剥离使用规则引擎恰恰提供了一个将业务处理和业务规则处理分离,共用和统一管理维护业务规则的系统开发构架本文以下探讨的就是基于规则引擎的企业服务应用开发模式,其中包括基于规则引擎的企业服务模型和基本的开发步骤和方法2基于规则引擎的企业服务模型设计明确和有效的系统模型是企业服务系统得以顺利进行的前提图1设计了一个简单的基于使用符合JSR-94标准的规则引擎及其模式开发的企业服务应用程序的体系结构图1"图1"描述的企业服务体系分为三个部分:应用程序/数据获得系统:捕获和存储应用程序提交的所有数据,是业务服务的使用者主要功能是提交业务请求和处理业务判定业务服务:通过具体实现的可调用的网络服务器或者API,调用选定的规则引擎来执行业务规则逻辑或对业务规则逻辑进行运算,产生反馈信息和数据同时也提供方便和有效维护业务规则逻辑的功能支持服务:提供业务服务使用者所提交的相关数据,即规则引擎执行业务规则或运算业务规则所需要的相关数据或应用程序或服务接口3基于规则引擎的企业服务开发模式中的步骤和方法在基于规则引擎的企业服务开发模式中,至关重要的原则是:(1)分离工作流程和业务规则;(2)形式化地描述业务规则在这个开发模式过程中,这两个原则贯穿始终分离工作流程和业务规则的目的在于将关键的业务判断规则和业务事件响应提取出来,置于系统的公共部位(业务服务),供不同的应用程序工作流程使用,并且便于维护和管理这是此模式下开发系统得以顺利进行的前提形式化地描述业务规则的目的则是将业务规则以一种能够被规则引擎处理的形式描述和表示,使业务规则可被运算化,使应用程序可以按照即定义的约定通过一个服务层来访问这些规则以下提及和讨论的开发模式中的方法和原则都围绕着以上两个原则展开31使用决策表提取规则在基于规则引擎的企业服务开发模式中首先要解决的问题是明确企业应用中有哪些规则以及对应的业务判定商业事务中条件元素的集合构成规则,规则决定判定和反馈,在散乱的企业业务中初步提取规则和对应的判定可以使用决策表的方法规则1规则2……规则i条件1条件值条件2……条件j判定1是否反馈判定2……判定k表1"表1"给出的是决策表的一般格式参照"图一"所示模型,其中条件将成为系统中的数据域,条件值则是对应的数据,是支持服务管理和维护的对象,同时是应用程序/数据获得系统捕获和提交的对象若干条件及其值的集合构成规则,是业务服务管理和维护的对象,也是规则引擎处理的根据判定是业务服务通过规则引擎处理给出的反馈,最后由应用程序/数据获得系统接收下面使用一个企业决定销售人员当月销售奖金的例子来进一步说明决策表的使用:ABCDEFG1rule1rule2rule3rule4rule5rule62achieveTargetNNNYYY3saleVolumepreMonth>=10k<10k=10k4warnYNNNYN5amortization0%1%2%2%2%3%表2表2中的"achieveTarget"表示条件"完成销售指标";"saleVolume"表示条件"销售额";"amortization"表示判定"提成";"warn"表示判定"提出警告";"preVolume"表示数据"上月销售额"在"表2"中,列A描述了应用中所涉及的条件和系统处理后的判定,与各个条件或者判定同行的单元格中的值组合构成列B至列G,列B至列G中的每一列都是通过决策表得以分离的规则,规则通过条件值集合和判定反馈值的形式得以描述例如规则2(rule2)描述的业务规则是:若没有完成销售指标,且销售额大于上月销售额,那么不给警告,并且判定提成比率为1%规则5(rule5)描述的业务规则是:若完成销售指标,且销售额小于或等于上月销售额,那么给予警告,并且判定提成比率为1%在实际的应用中可以通过对企业成文或不成文商业规则的总结和归纳来生成决策表,在必要时,例如商业规则不明确时也可以通过对条件组合的穷举来制定决策表,在以后的开发过程中再进行精简分离商业规则是基于规则引擎开发企业应用的前提,它是基于规则引擎的企业服务开发模式中的第一步,也是必须和最重要的步骤如果使用本文提供的决策表方法可以比较方便地分离业务逻辑和商业规则,比较清晰准确地描叙规则,并且具有与基于规则引擎的企业服务模型结合比较紧密的特点,这一特性使其可以对后续开发步骤中问题的解决提供有力支持32分析和解决规则冲突在分离和提取出规则之后,必须考虑规则之间的冲突,这里提到的冲突主要是指由于规则之间同一条件的值域相交而引起的判定歧义如果规则之间存在冲突而没有得到解决将造成判定结果的不确定,使规则引擎的处理不能正确进行我们可以通过使用决策网格来侦测规则之间的冲突具体的做法是将各条规则依次置于网格的行首和列首,网格中的每一个单元表示对应规则的交叉点,用以记录相交的规则或者规则集合为真时,反馈值是否发生歧义判断规则是否冲突的依据是相交规则所包含条件值域的交集以及各个判定的反馈值,具体流程如"图2"所示:图2以21中得到的规则为例,使用决策网格分析对于判定amortization的反馈,各条规则之间的冲突情况,结果如"表3"所示rule1rule2rule3rule4rule5rule6rule1NCY[1,2]NNNNrule2Y[1,2]NCY[2]NNNrule3NY[2]NCNNNrule4NNNNCY[1]Nrule5NNNY[1]NCY[1,2]rule6NNNNY[1,2]NC表3"表3"清晰地描述了各条规则之间的冲突情况,其中Y表示规则可能同时为真,并且有冲突,跟随其后的"[]"中指出具体发生冲突的判定名,判定序号或判定的描述;N表示规则没有冲突或者不可能同时发生在明确了规则之间的冲突关系之后,自然必须考虑如何解决冲突在本文中我们提出三种解决规则冲突的方案:(1)优先级模式;(2)队列模式;(3)常用模式优先级模式:设定规则的优先级顺序,在规则发生冲突时采纳较高优先级规则的判定反馈有利于保持业务处理结果的长期稳定性,适用于业务处理规则比较明确的企业应用队列模式:先进先出原则,即先使用原则在一个时间段内集中批处理业务时,若发生规则冲突,则采纳先使用(前一次或第一次处理已使用)规则的判定反馈有利于保证统一批次业务处理结果的一致性,适用于有业务高峰的企业应用常用模式:记录和参考业务处理中规则的使用频率(规则为真的频率),在发生规则冲突时采纳使用频率较高或较低的规则反馈有利于根据业务开展情况灵活适用规则,适用于业务开展情况多变的企业应用在一个企业应用服务中,以上提出的规则冲突解决方案可以单一使用也可以结合使用,以构成企业应用的规则冲突解决机制在没有采取规则冲突解决方案的情况下,一般规则引擎会采用LIFO(lastin,firstout)原则解决规则冲突,但是对于一个成功的基于规则引擎开发的企业应用,一套规则冲突解决机制是必不可少的33形式化描述规则规则集的冲突问题得到解决之后,基于规则引擎的企业服务开发模式的下一步是要形式化地描述规则,使其具有可代码化和可运算化的性质当前的规则引擎一般都是基于DrCharlesLForgy于1979年提出的Rete算法(网络算法)Rete算法的基本思想是组织一个有效的辨别网络,通过数据在网络中的传播来过滤数据Rete算法的具体做法是首先建立一个根结点(rootnode)作为数据对象进入辨别网络的入口,根据规则所包含的条件建立测试结点构成辨别网络,在网络的最底层构建若干终结点(terminalnode)描述相应的规则数据对象进入辨别网络之后经过途径结点,最终到达某个终结点,激活这个终结点所描述的规则根据Rete算法的特性,要求将规则分割为LHS(lefthandside)和RHS(righthandside),LHS由规则的条件部分组成,决定辨别网络中测试结点的生成,RHS由规则的判定部分组成,决定辨别网络中终结点的生成以21中得到的规则为例,可以采用在提取规则步骤中得到的决策表来解决问题,对于各个规则,其所在的列条件值构成它的LHS,判定反馈值则构成它的RHS由此,每一条规则都可以被形式化地描述为:形式化地描述规则为基于规则引擎的企业服务开发模式中后续的将规则代码化过程做了铺垫34设计业务流程与通常的设计模式相同,基于规则引擎的企业服务开发模式也包含和关注企业服务的业务流程设计由于实现了业务流程与业务规则的分离,使得业务流程的设计得到很大的简化,业务流程中不再需要设计繁琐和庞大的条件判断,大大减轻了业务程序的负担业务流程的设计原则应遵从"图1"描述的服务模型,设计方法则采用与以往设计模式相同的UML方法,在本文中不作详细的讨论,只以21中提出的例子为例,给出相应的业务流程活动图来直观说明分离业务流程与业务规则之后使得业务流程设计得到简化的程度图3从"图3"中可以清晰地看到,业务流程已不包含业务逻辑,当业务逻辑改变时,不需要对业务流程作出改变35业务规则代码化和业务流程代码化代码化的步骤既是企业服务具体得到实现的过程,简而言之就是程序代码实现的过程在这个过程中,需要遵从前序步骤的设计和结果,并且围绕"图1"描述的服务模型展开在此以21中提出的例子为例,选用Java语言和"Drools"规则引擎来实现代码化本文只给出需要实现的类及其简述,而不给出具体实现代码应用程序部分的实现捕获数据,提交业务判定请求,接收反馈,实现业务流程SalesPersonclass记录销售人员相关数据的数据对象FeedBackclass记录判定和反馈数据支持服务部分的实现负责给出销售人员完成销售指标的情况SaleVolumeclass负责提供销售人员月和上月的销售额业务服务部分的实现接受业务判定请求,调用规则引擎服务,反馈判定规则的代码化以"表1"中的rule1为例,其对应"Drools"规则引擎的代码如下rule"rule1"salience-100//优先级设定when//LHSSalesPerson(achieveTargetfalse,SaleVolume<=100000)$sa:SellApplication()$fb:FeedBack()then//RHSfbsetWarn(true);fbsetAmortization("0%");sasetFeedBack(fb);end4结束语本文提出的基于规则引擎构架的企业服务开发模式紧密地与规则引擎思想相结合,提出的步骤和方法能够很好地帮助开发人员在开发企业应用服务过程中分离业务流程和业务规则,明确业务规则,并且使得这些业务规则具有可描述化,可用化的性质,最终得以在应用服务中实现作用虽然规则引擎的应用还不广泛,不深入,但是其概念和理论已经比较成熟,针对于企业服务应用,尤其在动态商业模式下的企业应用有着明显的优势在实际的企业应用服务开发过程中,引入基于规则引擎构架的企业服务开发模式将使得企业服务应用具有更高的可维护性和更高的灵活性,具有推广使用的价值参考文献:[1]MalcolmChisholmHowtoBuildaBusinessRulesEngine[M]USA:MorganKaufmann,200311[2]IanGrahamBusinessRulesManagementandServiceOrientedArchitecture[M]USA:Wiley,200701[3](美)伽玛等著,李英军等译设计模式[M]北京:机械工业出版社,200506[4](美)迪达等著,李宏东等译,模式分类(原书第2版)[M]北京:机械工业出版社,200309

赞同 (80588)

反对 (738)

其它回答
摘星星

基于规则引擎的企业服务开发模式陶晓俊,朱敏(华东师范大学信息科学技术学院计算中心,上海200062)摘要:本文围绕规则引擎技术分离业务流程和业务规则的思想,探讨并提出一套有效使用规则引擎技术开发企业服务应用系统时所遵循的开发模式,其中包括设计一种基于规则引擎的企业服务模型;提出实际开发过程中紧密结合规则引擎思想,使用规则引擎技术实现企业服务应用的具体步骤和方法关键词:规则引擎JSR-94Rete算法DroolsPatternofBuildingEnterpriseServiceswithRuleEngineTAOXiao-jun,ZHUMin(ComputerCenter,EastChinaNormalUniversity,Shanghai,200062,China)Abstract:ThisarticlewillstudyandadvanceapatternwhichisbasedontheideaofruleengineforpracticalbuildingenterpriseservicesthatusingruleenginetechnologyeffectivelyandhandyThepatternincludesamodelofenterpriseservicesbasedonruleengine,andthestepandprocessofdevelopingenterpriseservicesusingruleenginetechnologyKeyWords:RuleEngineJSR-94ReteArithmeticDrools1引言规则引擎是用以管理和自动实现业务规则的软件系统,其主要实现的功能是存储,分类和管理规则,验证规则的一致性,通过规则推断其它规则,联系规则和执行这些规则的应用程序,其中的规则主要是指企业或商务业务逻辑,法律条款,企业政策等规则引擎概念的思想是从软件的应用逻辑中分离出商业规则,以实现商业应用的灵活性在传统的企业服务应用程序开发模式下,业务逻辑被直接固定在应用程序代码中,这使得应用程序维护复杂并且代价昂贵,变化的商业规则和业务流程总是引起对应用程序的频繁修改,尤其面临动态商业模型和业务流程的挑战时,传统模式下开发的应用程序往往面临全面和代价高昂的修改,甚至设计变化解决这个问题就需要采用新的开发模式,将业务逻辑从代码层剥离使用规则引擎恰恰提供了一个将业务处理和业务规则处理分离,共用和统一管理维护业务规则的系统开发构架本文以下探讨的就是基于规则引擎的企业服务应用开发模式,其中包括基于规则引擎的企业服务模型和基本的开发步骤和方法2基于规则引擎的企业服务模型设计明确和有效的系统模型是企业服务系统得以顺利进行的前提图1设计了一个简单的基于使用符合JSR-94标准的规则引擎及其模式开发的企业服务应用程序的体系结构图1"图1"描述的企业服务体系分为三个部分:应用程序/数据获得系统:捕获和存储应用程序提交的所有数据,是业务服务的使用者主要功能是提交业务请求和处理业务判定业务服务:通过具体实现的可调用的网络服务器或者API,调用选定的规则引擎来执行业务规则逻辑或对业务规则逻辑进行运算,产生反馈信息和数据同时也提供方便和有效维护业务规则逻辑的功能支持服务:提供业务服务使用者所提交的相关数据,即规则引擎执行业务规则或运算业务规则所需要的相关数据或应用程序或服务接口3基于规则引擎的企业服务开发模式中的步骤和方法在基于规则引擎的企业服务开发模式中,至关重要的原则是:(1)分离工作流程和业务规则;(2)形式化地描述业务规则在这个开发模式过程中,这两个原则贯穿始终分离工作流程和业务规则的目的在于将关键的业务判断规则和业务事件响应提取出来,置于系统的公共部位(业务服务),供不同的应用程序工作流程使用,并且便于维护和管理这是此模式下开发系统得以顺利进行的前提形式化地描述业务规则的目的则是将业务规则以一种能够被规则引擎处理的形式描述和表示,使业务规则可被运算化,使应用程序可以按照即定义的约定通过一个服务层来访问这些规则以下提及和讨论的开发模式中的方法和原则都围绕着以上两个原则展开31使用决策表提取规则在基于规则引擎的企业服务开发模式中首先要解决的问题是明确企业应用中有哪些规则以及对应的业务判定商业事务中条件元素的集合构成规则,规则决定判定和反馈,在散乱的企业业务中初步提取规则和对应的判定可以使用决策表的方法规则1规则2……规则i条件1条件值条件2……条件j判定1是否反馈判定2……判定k表1"表1"给出的是决策表的一般格式参照"图一"所示模型,其中条件将成为系统中的数据域,条件值则是对应的数据,是支持服务管理和维护的对象,同时是应用程序/数据获得系统捕获和提交的对象若干条件及其值的集合构成规则,是业务服务管理和维护的对象,也是规则引擎处理的根据判定是业务服务通过规则引擎处理给出的反馈,最后由应用程序/数据获得系统接收下面使用一个企业决定销售人员当月销售奖金的例子来进一步说明决策表的使用:ABCDEFG1rule1rule2rule3rule4rule5rule62achieveTargetNNNYYY3saleVolumepreMonth>=10k<10k=10k4warnYNNNYN5amortization0%1%2%2%2%3%表2表2中的"achieveTarget"表示条件"完成销售指标";"saleVolume"表示条件"销售额";"amortization"表示判定"提成";"warn"表示判定"提出警告";"preVolume"表示数据"上月销售额"在"表2"中,列A描述了应用中所涉及的条件和系统处理后的判定,与各个条件或者判定同行的单元格中的值组合构成列B至列G,列B至列G中的每一列都是通过决策表得以分离的规则,规则通过条件值集合和判定反馈值的形式得以描述例如规则2(rule2)描述的业务规则是:若没有完成销售指标,且销售额大于上月销售额,那么不给警告,并且判定提成比率为1%规则5(rule5)描述的业务规则是:若完成销售指标,且销售额小于或等于上月销售额,那么给予警告,并且判定提成比率为1%在实际的应用中可以通过对企业成文或不成文商业规则的总结和归纳来生成决策表,在必要时,例如商业规则不明确时也可以通过对条件组合的穷举来制定决策表,在以后的开发过程中再进行精简分离商业规则是基于规则引擎开发企业应用的前提,它是基于规则引擎的企业服务开发模式中的第一步,也是必须和最重要的步骤如果使用本文提供的决策表方法可以比较方便地分离业务逻辑和商业规则,比较清晰准确地描叙规则,并且具有与基于规则引擎的企业服务模型结合比较紧密的特点,这一特性使其可以对后续开发步骤中问题的解决提供有力支持32分析和解决规则冲突在分离和提取出规则之后,必须考虑规则之间的冲突,这里提到的冲突主要是指由于规则之间同一条件的值域相交而引起的判定歧义如果规则之间存在冲突而没有得到解决将造成判定结果的不确定,使规则引擎的处理不能正确进行我们可以通过使用决策网格来侦测规则之间的冲突具体的做法是将各条规则依次置于网格的行首和列首,网格中的每一个单元表示对应规则的交叉点,用以记录相交的规则或者规则集合为真时,反馈值是否发生歧义判断规则是否冲突的依据是相交规则所包含条件值域的交集以及各个判定的反馈值,具体流程如"图2"所示:图2以21中得到的规则为例,使用决策网格分析对于判定amortization的反馈,各条规则之间的冲突情况,结果如"表3"所示rule1rule2rule3rule4rule5rule6rule1NCY[1,2]NNNNrule2Y[1,2]NCY[2]NNNrule3NY[2]NCNNNrule4NNNNCY[1]Nrule5NNNY[1]NCY[1,2]rule6NNNNY[1,2]NC表3"表3"清晰地描述了各条规则之间的冲突情况,其中Y表示规则可能同时为真,并且有冲突,跟随其后的"[]"中指出具体发生冲突的判定名,判定序号或判定的描述;N表示规则没有冲突或者不可能同时发生在明确了规则之间的冲突关系之后,自然必须考虑如何解决冲突在本文中我们提出三种解决规则冲突的方案:(1)优先级模式;(2)队列模式;(3)常用模式优先级模式:设定规则的优先级顺序,在规则发生冲突时采纳较高优先级规则的判定反馈有利于保持业务处理结果的长期稳定性,适用于业务处理规则比较明确的企业应用队列模式:先进先出原则,即先使用原则在一个时间段内集中批处理业务时,若发生规则冲突,则采纳先使用(前一次或第一次处理已使用)规则的判定反馈有利于保证统一批次业务处理结果的一致性,适用于有业务高峰的企业应用常用模式:记录和参考业务处理中规则的使用频率(规则为真的频率),在发生规则冲突时采纳使用频率较高或较低的规则反馈有利于根据业务开展情况灵活适用规则,适用于业务开展情况多变的企业应用在一个企业应用服务中,以上提出的规则冲突解决方案可以单一使用也可以结合使用,以构成企业应用的规则冲突解决机制在没有采取规则冲突解决方案的情况下,一般规则引擎会采用LIFO(lastin,firstout)原则解决规则冲突,但是对于一个成功的基于规则引擎开发的企业应用,一套规则冲突解决机制是必不可少的33形式化描述规则规则集的冲突问题得到解决之后,基于规则引擎的企业服务开发模式的下一步是要形式化地描述规则,使其具有可代码化和可运算化的性质当前的规则引擎一般都是基于DrCharlesLForgy于1979年提出的Rete算法(网络算法)Rete算法的基本思想是组织一个有效的辨别网络,通过数据在网络中的传播来过滤数据Rete算法的具体做法是首先建立一个根结点(rootnode)作为数据对象进入辨别网络的入口,根据规则所包含的条件建立测试结点构成辨别网络,在网络的最底层构建若干终结点(terminalnode)描述相应的规则数据对象进入辨别网络之后经过途径结点,最终到达某个终结点,激活这个终结点所描述的规则根据Rete算法的特性,要求将规则分割为LHS(lefthandside)和RHS(righthandside),LHS由规则的条件部分组成,决定辨别网络中测试结点的生成,RHS由规则的判定部分组成,决定辨别网络中终结点的生成以21中得到的规则为例,可以采用在提取规则步骤中得到的决策表来解决问题,对于各个规则,其所在的列条件值构成它的LHS,判定反馈值则构成它的RHS由此,每一条规则都可以被形式化地描述为:形式化地描述规则为基于规则引擎的企业服务开发模式中后续的将规则代码化过程做了铺垫34设计业务流程与通常的设计模式相同,基于规则引擎的企业服务开发模式也包含和关注企业服务的业务流程设计由于实现了业务流程与业务规则的分离,使得业务流程的设计得到很大的简化,业务流程中不再需要设计繁琐和庞大的条件判断,大大减轻了业务程序的负担业务流程的设计原则应遵从"图1"描述的服务模型,设计方法则采用与以往设计模式相同的UML方法,在本文中不作详细的讨论,只以21中提出的例子为例,给出相应的业务流程活动图来直观说明分离业务流程与业务规则之后使得业务流程设计得到简化的程度图3从"图3"中可以清晰地看到,业务流程已不包含业务逻辑,当业务逻辑改变时,不需要对业务流程作出改变35业务规则代码化和业务流程代码化代码化的步骤既是企业服务具体得到实现的过程,简而言之就是程序代码实现的过程在这个过程中,需要遵从前序步骤的设计和结果,并且围绕"图1"描述的服务模型展开在此以21中提出的例子为例,选用Java语言和"Drools"规则引擎来实现代码化本文只给出需要实现的类及其简述,而不给出具体实现代码应用程序部分的实现捕获数据,提交业务判定请求,接收反馈,实现业务流程SalesPersonclass记录销售人员相关数据的数据对象FeedBackclass记录判定和反馈数据支持服务部分的实现负责给出销售人员完成销售指标的情况SaleVolumeclass负责提供销售人员月和上月的销售额业务服务部分的实现接受业务判定请求,调用规则引擎服务,反馈判定规则的代码化以"表1"中的rule1为例,其对应"Drools"规则引擎的代码如下rule"rule1"salience-100//优先级设定when//LHSSalesPerson(achieveTargetfalse,SaleVolume<=100000)$sa:SellApplication()$fb:FeedBack()then//RHSfbsetWarn(true);fbsetAmortization("0%");sasetFeedBack(fb);end4结束语本文提出的基于规则引擎构架的企业服务开发模式紧密地与规则引擎思想相结合,提出的步骤和方法能够很好地帮助开发人员在开发企业应用服务过程中分离业务流程和业务规则,明确业务规则,并且使得这些业务规则具有可描述化,可用化的性质,最终得以在应用服务中实现作用虽然规则引擎的应用还不广泛,不深入,但是其概念和理论已经比较成熟,针对于企业服务应用,尤其在动态商业模式下的企业应用有着明显的优势在实际的企业应用服务开发过程中,引入基于规则引擎构架的企业服务开发模式将使得企业服务应用具有更高的可维护性和更高的灵活性,具有推广使用的价值参考文献:[1]MalcolmChisholmHowtoBuildaBusinessRulesEngine[M]USA:MorganKaufmann,200311[2]IanGrahamBusinessRulesManagementandServiceOrientedArchitecture[M]USA:Wiley,200701[3](美)伽玛等著,李英军等译设计模式[M]北京:机械工业出版社,200506[4](美)迪达等著,李宏东等译,模式分类(原书第2版)[M]北京:机械工业出版社,200309

赞同 (9465)

反对 (520)

曾以为

根据题目,先将收件距离分为大于1000和小于或等于1000两种,这就是决策树的第一层的两个分支。
如收费标准——L≤1000——L>1000;
然后,题目告知,在1000公里以内,普通邮件2元/公斤;
挂号3元/公斤,这就是第一个分支上的两个更细的分支;
也就是说L≤1000里面又可以有两个分支,一个是挂号,一个是普通(暂时先不分,大家看明白,下面我会把整个图画出来的);
第三,可以看到大于1000公里的,普通邮件25元/公斤;
挂号35元/公斤。
这是大于1000公里的两个分支。
第四,到这里,还没有完,因为可以看到题目的最后一句,就是在超过1000公里以外的邮件,还有一个分支,就是重量部分的,超过30公斤,要加收05元,当然,另一个条件就是不超过的不加,这就需要在大于1000公里的分出的两个分支里面又要分出两个分支。
题目分析完了之后,我们开始绘图。
(因为我对WORD文档的很多使用还不是特别熟练,呵呵,只能是粗略的绘一张草图,大家克服一下,看明白就可以了)。
第一层两个分支收费标准——L≤1000——L>1000第二层分支L≤1000——挂号3W——普通2WL>1000——挂号——普通由于在大于1000里面还分超过30公斤和不超过30公斤的,所以,暂时我们还不给它定价,等到第三层的分支里再定价;
第三层分支L>1000——挂号——W>3035×30+4(W-30)——W≤3035W——普通——W>3025×30+4(W-30)——W≤3025W再把整个图复合一下,就成为下面这样的一个完整的:
收费标准——L≤1000——挂号3W——普通2W——L>1000——挂号——W>3035×30+4(W-30)——W≤3035W——普通——W>3025×30+3(W-30)——W≤3025W然后,大家自己再用大括号连一下就可以了,应该能看明白了。
下面是决策表;
决策表基本是根据决策树来画的,现在我们可以看出,我们总共有6个组合,条件有3个,行动的结果有6个,这就确定了决策表的列与行,6个组合构成了决策表的列,3个条件和6个行动结果构成了决策表的9个行,于是,一个决策表的大致轮廓就出来了:条件和行动组合123456距离是否大于1000YYYYNN是否挂号YYNNYN重量是否大于30YNYNF=2W√F=3W√F=25W√F=35W√F=25×30+3(W-30)√F=35×30+4(W-30)√我想要说明的是,其中的W代表的是你包裹的重量,在决策表中上面三行是条件,下面六行是结果,这个是根据决策表的条件一个一个对照来了,Y代表是,N代表否,不要想当然的往里添,在条件都符合的情况下画勾,这样,一个决策表就做出来了

赞同 (52835)

反对 (615)

无须终有i

问题:根据自身兴趣、性格、技能等情况,就大学毕业后,升学和就业2个选择制定决策平衡单并作出决策结果,A4纸手写
先列出你有几个可能的选项,一般三到五个,然后判断利益得失,当然分几个纬度,自我、他人、物质、精神四个纬度就是它的得失。
2然后分数就是从正5到负5,中间有一个0,这是量表,最重要的加5,最不重要的减5,0的话可有可无。
然后当在选项上列完表之后,打完分之后找重点、关键点,可以加权,就是可以乘1至5,这个特别重要乘5倍,一般重要我就乘1倍,看你的想法。
然后计算得分,逐一计算得分,有正分,还有可能负分,然后累加就可以了。
先列出你有几个可能的选项,一般三到五个,然后判断利益得失,当然分几个纬度,自我、他人、物质、精神四个纬度就是它的得失。
然后分数就是从正5到负5,中间有一个0,这是量表,最重要的加5,最不重要的减5,0的话可有可无。
然后当在选项上列完表之后,打完分之后找重点、关键点,可以加权,就是可以乘1至法旦瘁秆诓飞搭时但江5,这个特别重要乘5倍,一般重要我就乘1倍,看你的想法。
然后计算得分,逐一计算得分,有正分,还有可能负分,然后累加就可以了。
看一下这个例子。
这是一个大学生在选择毕业出路时的一个选项,直接就业、去公司找工作,自己创业、创办软件公司,第三是考研。
自我物质方面的因素,收入、健康、工作、休闲生活、未来的展望。
自我精神方面的有,潜能、兴趣、成就感、改变生活的形态、生活方式等等。
他人物质方面的得失,比如说家庭收入与家庭分担的家事,与家人相处的时间、与朋友相处的时间等等。
他人精神方面的收入损失。
家人的荣誉感、家人的认同、家人的担心。
6这里要澄清一下,这是主要的一级纬度是你可以盘点的,可以增加,也可以删减的,并不是说把这些全都照顾到,是你觉得最重要对自己的选择有影响的尽量的去列,以什么为参考点呢,在选择时候的,自我因素、职业因素、环境因素都可以,充分考虑家庭、他人、情感、生活、休闲、工作等等,选项可以根据个人的选择增加。
7最后出来分数,第一个自己创业77分,考研68分,职业工作22分,经过角色平衡之后发现原来创业是他的第一选项,这个方法用在换工作要有一个出路的时候特别实用。

赞同 (71059)

反对 (951)

眼底有星光

问题:题目如下:
检查订购单的处理逻辑具体如下:
(1)如果金额超过500元,且未过期,则发出批准单和提货单;
(2)如果金额超过500元,且已过期,则不发批准单;
(3)如果金额不超过500元,且不论过期与否,则均发出批准单和提货单,在过期的情况下,还需发出通知单。
试绘制决策表???
处理订单决策表决策规则号1234条金额>500YYNN件金额<500NNYY过期NYNY应采取发出批准单和提货单X的行动不发批准单X只发出批准单和提货单X发出批准单和提货单和通知单X上面就一张表,分两大块。
上部分是条件,下部分是行动。
Y表述是的,N表示否。
比如:规则号1(Y,N,N)表示金额超过500且不过期。
然后看1列中的下部分表,看规则号1与那条行动相交叉。
此例中与第一条行动交叉,所以执行之。
其实就可以看列中对应的X,然后X所在的行即为行动。
通常,董事会通过授权形式给管理者一定的管理权限,超出权限,就要上报董事会。
董事会的授权是决策的依据。
案例:
汶川地震后,王石建议人捐10元,理由是授权的年度捐款额度有限。
后来,通过董事会批准,参与重建项目。
王石的做法当时令网民无法接受,事实上,管理者知道如何行使决策是公司治理的重要一步。
万科的做法符合公司治理原则。
随便坐自己做

赞同 (536)

反对 (870)

逾期不侯

在所有的测试方法中,基于决策表的测试方法是最严格的,因为决策表具有逻辑严格性。
决策表有四个部分,如下图所示:
条件桩条件条目行动桩行动条目(条目中的一列就是一个规则)所有条件都是二叉条件的决策表称为有限条件决策表,如果条件可以有多个值,则对应的决策表叫做扩展条目决策表。
为了使用决策表标识测试用例,把条件解释为输入,把行动解释为输出。
有时条件最终引用输入的等价类,行动引用被测软件的主要功能处理部分。
这时规则就解释为测试用例。
对于有限条件决策表,如果有n个条件,则必须有2的n次幂条规则。
在决策表中要小心使用不关心条目。
决策表技术适合具有以下特征的应用程序:
if-then-else逻辑很突出输入变量之间存在逻辑关系涉及输入变量子集的计算输入和输出之间存在因果关系很高的圈复杂度??决策表不能很好的伸缩(有n个条件的有限条目决策表有2的n次幂个规则),不过有多个方法可以解决这个问题,如使用扩展条目决策表,代数简化表,将大表分解为小表,查找条件条目的重复模式等。
功能性测试技术的选择:
如果变量引用的是物理量,可采用定义域测试和等价类测试如果变量是独立的,则可以用定义域测试和等价类测试如果变量不是独立的,可采用决策表测试如果可保证是单缺陷假设,则可采用边界值分析和健壮性测试如果可保证是多缺陷假设,可采用最坏情况测试、健壮最坏情况测试和决策表测试如果程序包含大量例外处理,可采用健壮性测试和决策表测试如果变量引用的是逻辑量,可采用等价类测试用力和决策表测试

赞同 (37068)

反对 (913)

房东的猫

在所有的测试方法中,基于决策表的测试方法是最严格的,因为决策表具有逻辑严格性。
决策表有四个部分,如下图所示:
条件桩条件条目行动桩行动条目(条目中的一列就是一个规则)所有条件都是二叉条件的决策表称为有限条件决策表,如果条件可以有多个值,则对应的决策表叫做扩展条目决策表。
为了使用决策表标识测试用例,把条件解释为输入,把行动解释为输出。
有时条件最终引用输入的等价类,行动引用被测软件的主要功能处理部分。
这时规则就解释为测试用例。
对于有限条件决策表,如果有n个条件,则必须有2的n次幂条规则。
在决策表中要小心使用不关心条目。
决策表技术适合具有以下特征的应用程序:
if-then-else逻辑很突出输入变量之间存在逻辑关系涉及输入变量子集的计算输入和输出之间存在因果关系很高的圈复杂度??决策表不能很好的伸缩(有n个条件的有限条目决策表有2的n次幂个规则),不过有多个方法可以解决这个问题,如使用扩展条目决策表,代数简化表,将大表分解为小表,查找条件条目的重复模式等。
功能性测试技术的选择:
如果变量引用的是物理量,可采用定义域测试和等价类测试如果变量是独立的,则可以用定义域测试和等价类测试如果变量不是独立的,可采用决策表测试如果可保证是单缺陷假设,则可采用边界值分析和健壮性测试如果可保证是多缺陷假设,可采用最坏情况测试、健壮最坏情况测试和决策表测试如果程序包含大量例外处理,可采用健壮性测试和决策表测试如果变量引用的是逻辑量,可采用等价类测试用力和决策表测试

赞同 (84662)

反对 (353)

小神仙

在全部的测试方法中,基于决策表的测试方法是最严格的,由于决策表具有逻辑严格性。
决策表有四个部分,如下图所示:
条件桩条件条目行动桩行动条目(条目中的一列就是1个规则)全部条件都是二叉条件的决策表称为有限条件决策表,假如条件可以有多个值,则对应的决策表叫做扩展条目决策表。
为了用决策表标识测试用例,把条件解释为输入,把行动解释为输出。
有时条件最终引用输入的等价类,行动引用被测软件的主要功能处理部分。
这时规则就解释为测试用例。
对于有限条件决策表,假如有n个条件,则必须有2的n次幂条规则。
在决策表中要小心用不关心条目。
决策表技术适合具有以下特征的应用程序:
if-then-else逻辑很突出输入变量之间存在逻辑关系涉及输入变量子集的计算输入和输出之间存在因果关系很高的圈复杂度??决策表不能很好的伸缩(有n个条件的有限条目决策表有2的n次幂个规则),不过有多个方法可以处理这个问题,如用扩展条目决策表,代数简化表,将大表分解为小表,查找条件条目的重复模式等。
功能性测试技术的选取:
假如变量引用的是物理量,可采用定义域测试和等价类测试假如变量是独立的,则可以用定义域测试和等价类测试假如变量不是独立的,可采用决策表测试假如可保证是单缺陷假设,则可采用边界值分析和健壮性测试假如可保证是多缺陷假设,可采用最坏情形测试、健壮最坏情形测试和决策表测试假如程序包含大量例外处理,可采用健壮性测试和决策表测试假如变量引用的是逻辑量,可采用等价类测试用力和决策表测试

赞同 (33753)

反对 (337)

织梦师

问题:刚做婚庆不久,暂时负责一家店面,老板让做年度计划表和时间推进表,但是不知道这个怎么回事,其他行业的类似的表能否借鉴呢?应该怎么做?如何量化?还望本行业专业的人士帮忙指点,最好详细些,刚入行,太多不懂。
着急…
年度计划是一项有必要,且有价值的事情,将在未来一年的日子里实践开年时节的想法和目标。
年度计划,也是全体成员需要参与和贡献想法的事情,除了团队领导作为核心决策者来全盘考量,团队的每个人也最好能为未来一年投入思考和力量。
所以,年度计划的要点其实是:
决策层,从全局把握未来方向,指定有针对性的执行策略。
执行层,从执行层面落实决策层的想法,把战略变成策略,尽而形成可被执行的任务。
其他层面,打酱油,但要指定总体的安排,做到心中有数。
这个没必要做图片做个表格就可以了这样比较简单

赞同 (86675)

反对 (969)

独角兽

建议用微软的甘特图表示。
MicrosoftVIsio来画,下载安装一下就可以用了亲。
记得选择甘特图!
年度计划是一项有必要,且有价值的事情,将在未来一年的日子里实践开年时节的想法和目标。
年度计划,也是全体成员需要参与和贡献想法的事情,除了团队领导作为核心决策者来全盘考量,团队的每个人也最好能为未来一年投入思考和力量。
所以,年度计划的要点其实是:
决策层,从全局把握未来方向,指定有针对性的执行策略。
执行层,从执行层面落实决策层的想法,把战略变成策略,尽而形成可被执行的任务。
其他层面,打酱油,但要指定总体的安排,做到心中有数。

赞同 (87503)

反对 (855)

笑你像狗

选C没问题。
决策的过程就是某实例经过其满足判断条件的所有节点的一条逻辑路径,即从根节点到叶子节点的一次遍历。

赞同 (64644)

反对 (124)

相关百科

(跑婚车怎么做合法)私家车星期六星期天或节假日

“拦婚车小胖”是濮阳当地的“名人”,见到婚车便跪下强行要钱,不给钱不停喊“爸爸”,直到要到钱为止,价格也从10元飙升到200元。8月1日,“拦婚车...全文