软件工程论文
摘 要： 目前大部分工资系统的计算方法采用硬编码方式, 与工资政策结合过于密切, 系统适用性、重用性不高, 更新维护困难。针对这一问题, 提出了一种基于规则引擎的自适应工资系统。首先, 结合Drools规则引擎组件建立一个可执行的规则库, 将规则库与现实中的业务需求及政策一一对应;然后通过规则流控制规则的执行, 使其更灵活地适应计算逻辑的变化, 推动了工资系统的解耦合扩展和更新。根据规则引擎得到的规则文件, 可经自然语言处理作为规则文档使用, 极大降低了政策变化与系统功能同步更新难度, 具有较高的实用价值。
关键词： 工资系统; 规则引擎; 规则; 规则流; 适应性;
Abstract： At present, hard-coding is adopted in most payroll system, it is too dependent on wage policy, which makes the system dificult to update and maintain.To slove this problem, this paper prensents a payroll system based on rules.First, we establish a executable rule base with the Drools rules engine components, the rule base corresponds to business requirements and policies;then, the execution of regular flow control rules can make it more flexible to adapt to the changes of calculation logic.It is proved that the system can promote the decoupling, the expansion and update of the salary system.In addition, the rule file can be changed into rule documents by natural language processing, which greatly reducing the policy change and system update difficulty, has a strong practical value.
Keyword： payroll system; rules engine; rule; rule flow; adaptability;
0、 引言
软件行业发展至今, 灵活性和适应性愈加重要。设计模式、极限编程、敏捷软件开发、Rup等, 无一例外地强调了灵活和变化的重要性。
Drools是为Java量身定制的基于Charles Forgy的RETE算法规则实现[1], 具有OO接口的RETE使商业规则有了更自然的表达, 很多Java的应用系统中已开始引入Drools规则引擎以提高系统适应性。
本文以机关事业单位网络工资管理系统开发为例, 建立与工资政策相适应的规则, 减少硬编码, 实现编码与规则的解耦合[2], 以规则库对应工资政策。通过对规则的管理和系统的重新设计, 实现具有自适应性的网络工资管理系统。
1、 相关技术
1.1、 规则引擎
规则引擎[3]一直以来没有明确定义, 因为规则引擎的广义定义使得规则引擎范围很大, 包括以任何形式使用并能应用于生成数据结果的规则系统。本文的规则引擎是一种嵌入在应用程序中的组件, 它主要负责利用用户抽取的业务逻辑, 按预先定义好的语义编写业务规则, 执行预定义流程, 完成一定的检测和执行功能。同时规则引擎还提供一些辅助性插件, 如绘制规则流插件、调试插件等。
Java规则引擎作为一个软件插件, 可管理和执行业务规则、存储规则, 主要包括规则的语法形式、规则的组织形式、规则执行前的标识中间形式以及规则执行中的内存申请管理, 具有声明式编程、逻辑和数据分开、性能高、集中表示知识、不用硬编码等优点。
1.2、 Drool5.0介绍
1.2.1、 业务规则
业务规则[4-5] (BusinessRule, 简称BR) 指包含一组条件和在此条件下执行的操作, 表示应用程序的一段业务逻辑。Drools中每个规则结构如图1所示。
图1 规则结构
1.2.2、 规则流
Drools提供了很多元素以控制规则的执行顺序, 比如优先级、Active-group等。如果项目越来越大, 规则越来越复杂, 单纯靠优先级和Active-group是很难维护的, Ruleflow可轻松地控制规则的执行顺序, 类似工作流那样, 将规则集中、分批管理和组织。Ruleflow还提供了Join、Split、条件判断等复杂条件。图2是一个规则流例子[6]。
图2 规则流实例
1.2.3、 规则执行
编写完规则和规则流后, 建立相应的drl、rf、rfm或xml文件, 这些文件将由一个Antlr3的文法解析器检测是否存在错误。正确性检测后建立一个规则描述descr的中间结构, 文法解析器将descr传入PackageBuilder中, 由它来打包生成Package[7-8]。规则执行流程如图3所示。
2、 工资管理系统规则库模型设计
2.1、 工资管理系统中的规则
规则的分类思想较多, 最具有代表性的是由James Odell提出的分类思想, 该思想较为实用和全面。在对系统进行分析时, 要对系统中的内容进行分析, 确定规则是表示对象与对象之间的关系, 还是表示系统运算逻辑或是商业逻辑, 区分情况进行管理。该思想将规则分为6类:
图3 规则执行流程
(1) 条件型:这类规则用来限制对象所处环境, 设置对象为真还是为假, 比如WHEN……IF……ELSE。
(2) 充分型:这类规则表示当且仅当的条件, 只有条件为真时才执行, 比如ONLY, IF。
(3) 必要型:用例后置规则是表示用例执行结果的规则, 它只关心用例执行的结果。比如:Finally。
(4) 关联关系型:对象约束规则表示对象与对象之间的关系, 有一对多、多对一、多对多等, 还包含依赖、集成、聚合等关系。
(5) 推理型:推理顾名思义是由条件A满足时需要经过多个条件的比对才能得出结果。
(6) 公式型:这类规则来自公式或算法的结果, 比如:工资=基本工资+津贴+边远津贴-纳税。
2.2、 系统规则流
规则流与工作流的区别在于解决问题的中心不一样。如果流程经常变化, 建议用工作流, 如果流程变化较少而流程中的内容变化较大建议用规则流。一般规则流的变更并不频繁, 因此使用规则流。经过分析后一旦决定就不轻易变化, 对于有变化的内容应该尽量用规则来处理。系统规则流分层如图4所示。
2.3、 规则文件组织与管理
规则管理是整个工资系统的核心。对工资系统的业务模式、业务规则以及影响工资计算的各种参数作充分分析, 并以此建立基础构建规则库模型和基于规则库的推理机制, 同时将规则库进行分类管理, 实现规则的可配置管理。
2.3.1、 规则的分类组织
工资系统依赖大量的政策文件, 本文对政策文件进行分类管理, 由规则包→规则文件→规则, 由大到小进行分类和编号, 提供规则管理界面, 方便用户修改规则和加入新的规则, 见表1。
2.3.2、 规则的冲突检测与处理
冲突分为3种: (1) 两条规则条件中的关系运算完全相同; (2) 两条规则中的关系运算有交集而数值不同[7]; (3) 执行规则中顺序不当或混乱导致规则匹配出错。本文对冲突处理的方式如图5所示。
图4 系统规则流分层
表1 单位与规则对照
图5 冲突处理流程
3、 系统设计与建模
3.1、 激活规则库
Drools支持多种规则文件格式, 如drl、dsl和xml等。其中, drl格式为Drools规则引擎的标准格式。Drl语法简单, 格式固定, 属性理解方便, 因此可读性较强。本文的所有规则文件均以drl文件的形式存储, 但是对于各类人员的规则, 具体到某一个单位时, 只会用到部分规则, 因此本文用数据库存储可以激发的规则文件。某一条规则是否激活有两种状态:已激活和未激活。
3.2、 规则过滤器
工资计算时面对大量的规则, 如何根据具体的人去选择规则, 仅仅靠规则引擎是不能完成的。它需要规则过滤器提取规则相关信息, 检测规则执行时的冲突, 处理冲突。同时规则过滤器还担当规则的预处理, 根据人员的相关信息选取可能匹配的规则等。规则过滤流程如图6所示。
图6 规则过滤流程
3.3 规则管理平台
规则管理界面中, 业务规则编码是添加规则时自动生成的规则编号, 这个规则编号蕴含规则的相关信息, 是规则文件的唯一标识。规则名称是规则的说明性名称, 以方便用户理解规则, 规则执行状态表示规则目前所处的状态, 规则类别记录了规则所属人员的类别, 创建时间是最后一次修改规则的时间。
4、 结语
本文进行了如下研究:
(1) 规则引擎与工资计算相结合。规则引擎是人工智能领域专家系统的应用[9], 与工资系统结合, 提高了工资系统的智能性。
(2) 根据jsr94语法规则, 运用Drools插件[10]编写了大量的工资系统相关政策文件规则, 将工资政策直接与规则相关, 将计算流程直接与规则流相关。
(3) 提供规则管理界面。管理员利用规则管理界面可以方便地查看规则、修改规则、添加规则、配置规则, 以适应新的政策变化。
(4) 设置规则激活库以适应不同单位的需要, 激活规则由管理员进行配置和激活。
(5) 设计规则过滤器, 实现了规则文件、规则流和具体人员结合, 通过规则过滤器解决执行时的冲突, 调用规则流执行。
(6) 高可扩展性。基于规则的系统本身就具有很好的扩展性能, 脱离硬编码后, 依赖规则的方式扩展时只需要加入新的规则即可。
有待进一步研究的内容是: (1) 规则没有充分做到自然语言化, 如果能做到自然语言化, 那么规则的编辑与修改就会变得更加容易; (2) 规则流管理基于Drools提供的myeclispe插件, 因此规则流的修改还需要程序人员参与; (3) 目前规则的生成, 主要靠懂政策的人手动编写, 如果能设计一个通用的规则生成器用以生成规则, 就会减少工作量, 使规则编写更加方便。
参考文献：
[1]JOSEPH GIARRATANO, GARY RILEY.专家系统:原理与编程[M].印鉴, 译.第4版.北京:机械工业出版社, 2010.
[2]何仁杰, 梁冰.用规则引擎替代代码[N].计算机世界, 2004-01-19.
[3]Drools开发手册[EB/OL].http://down.51cto.com/data/473041.
[4]TONEY MORGAN.Business rules and information systems:aligning it with business goals[M].Boston:Addison-wesley Professional, 2002:34-63.
[5]RONALD G ROSS.业务规则方法原理[M].北京:机械工业出版社, 2004.
[6]Drools官网[EB/OL].http://drools.org/download/download.html.
[7]张宇, 陈德礼.基于Drools的策略体系设计[J].福建电脑, 2007 (10) :11-12.
[8]刘金龙.Drools规则引擎模式匹配效率优化研究与实现[D].成都:西南交通大学, 2016.
[9]李春芳, 谭庆平.面向业务的Drools规则引擎改进[J].计算机应用与软件, 2015 (5) :20-23.
[10]刘金龙.Drools规则引擎模式匹配效率优化研究与实现[D].成都:西南交通大学, 2015.