业务规则在课时津贴结算系统开发中的应用
开篇：润墨网以专业的文秘视角，为您筛选了一篇业务规则在课时津贴结算系统开发中的应用范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！
摘 要：目前很多高职院校的课时津贴结计算仍然处于半自动化的计算方式阶段，由于高职院校课程开设类型十分复杂，规则众多，人工计算出现误差的情况比较突出。因此，实现课时计算自动化，准确、快速的计算课时和课时津贴是一项急需完成的工作。为了能够适应复杂规则的变化，采取基于规则的方式开发课时津贴结算系统，就成了必然的选择。基于规则设计的课时津贴结算系统，能够在一定程度上适应计算规则的变化，将大大提高系统的扩展性和重用性，同时规则易于维护，使得系统能够充分满足高职院校课时津贴结算的使用。
关键词：课时津贴结算；规则；Web服务
中图分类号：TP391.3
1 课时津贴结算系统开发的现状和面临问题
课时津贴计算方法很有可能在以后的使用过程中发生变化而导致不能使用，因此，大部分教务管理系统并不提供课时津贴计算模块，即使系统带有此模块，在使用时也必须根据使用高校的实际情况进行二次开发。很多信息化程度不高的高职院校仍然采用EXCEL表格来完成课时津贴的计算，将近一半的工作量仍然依靠手工完成。采用EXCEL表格完成课时津贴的计算很难实现工作的完全信息化，工作量的减少程度并不明显，出错的情况依然几率很大，教师依然很难核对个人课时津贴。目前设定的课时计算规则在以后的使用过程中很有可能根据需要修改调整，如果仅仅按照现行规则开发系统，规则一旦发生变化，就必须由系统开发人员重新修改程序，这将很大程度上增加系统维护难度。由于各个学校的规则设定不尽相同，如果系统希望系统在最大程度上满足各个高职院校的使用，必须要实现规则可以灵活修改的需求。
2 采用业务规则开发系统的优势
在传统程序开发中，业务规则一直深埋在用某种过程编程语言编写的应用程序中，用户无法探究涉及到这部分，程序开发人员完全控制着业务规则的管理，如果要改变业务规则则必须由程序编写人员来修改，对用户来说存在很多困难和不便。同时还容易造成各种误解，从而产生管理不善的代码，并最终影响整体业务。采用业务规则，将业务逻辑中规则决策部分从固定程序中抽离出来，为用户提供可以自己修改或编写业务规则的界面。在课时津贴结算系统中，教务人员就可以根据学校需要设计、选择和使用相应规则，无需学习复杂的编程语言就能够轻松实现对规则的控制。
采用基于规则的课时开发系统具有重要意义，有以下好处：（1）提高课时计算准确度。所有计算过程由系统来完成，不需要人工参与，教务员只需根据教学执行过程中实际发生的变化更改基本信息；（2）减少工作节点，统一管理数据。数据不需要层层提交到教务处，所有数据集中在教务处，教务员使用平台在一定权限下修改或添加数据库数据；（3）系统适用性增强。能够根据计算规则的变化，由教务员根据文件自己设计规则，并根据具体情况选择使用规则；（4）逻辑出错率降低。对于一个课时计算有多条规则适用的情况，系统可以自动判断使用哪条规则；（5）提高学院教务管理水平。通过采用课时统计系统，课时计算准确度提高，工作效率提高，同时又为学院管理提供参考数据，提升了教务管理水平。
传统业务流程按照部分一级报送数据，流经部门众多，工作节点多，人工控制流程所导致的问题十分明显。同时金字塔式的工作流程不利于快速处理业务。如果按照传统流程开发系统，首先需要解决的就是数据冲突问题。由于存在一个老师在多个系部带课的情况，如果由系部计算教师课时再汇总到教务处数据库，这个老师本周课时总数会被几个系部同时修改，存在处理冲突问题，而且这种方式也不利于数据安全。所以，本文采用扁平式管理办法的思路进行系统开发，数据集中存放在数据库中，各部门根据自身权限读取、修改数据库记录生成数据。同时为了应对在以后的使用过程中规则发生变化调整的情况，将课时计算中需要考虑到的所有因素和规定全部设计成规则存放在规则库中，方便以后使用规则管理功能添加、修改、删除规则。通过从数据库中读出数据，使用规则引擎加载相应规则完成课时、津贴计算。基于规则的课时津贴结算系统业务模型如图1所示。
3.1 规则设计。规则是一条的可以执行的叙述，有条件和动作组成。条件是判断是否成立，条件成立，执行动作。规则库是存储规则语句和属性的地方，将规则和规则包集中起来方便管理。规则实现时，规则引擎从规则库中读出业务规则加以执行。
为了保证系统的扩展性和重用性，课时津贴结算系统中规则的设计要尽量多的考虑可能需要使用到的规则，在开发课时津贴结算系统时主要考虑到以下影响因子：（1）班级系数：理论教学课不同班级系数不同，体育课不同选修人数系数不同，每班课时计算系数有差别；（2）上课时间：理论课包含理论教学课和选修课，两类课系数不同，上课时间也不同，有些课程在暑假期间开课，课程系数也不同；（3）上课区域：校内实践课和校外实践课课时数不同；（4）教师职称津贴：不同教师职称津贴不同，计算理论津贴时要根据不同教师职称津贴来计算，非理论津贴同教师职称津贴没有关系；（5）其他因素：教师不能在一周内同时带两个及以上班级的实践课。
按照规则“条件―动作”的形式，将以上所有影响因子设计成可存储的规则形式。规则的设计必须遵循原子性和确定性，一条规则必须表达一个完整的意思，并且不可再分解；而且对于规则的解释是唯一确定的。 根据以上影响因子，系统将所有规则分为两类：一类是结构化规则，比如课时系数，一类是半结构化或非结构化规则，如教师不能再一周内同时带两个及以上班级实践课。使用过程中，所有由规则引擎自动加载匹配，对于同一对象实例可能有多条规则适用的情况，规则引擎能够自动排列规则优先级。
3.2 规则存储。规则库包含了规则以及相对应的数据，一组业务规则的实现可以是XML文件，也可以是数据库、表格。系统中的业务规则几乎全部是针对或包含数据的操作，因此采用数据库存储和XML存储结合实现业务规则的存储。
系统使用XML文件用来存储半结构化或非结构化的文件内容。当输入对象时，规则引擎调用规则，系统将数据库中的数据文件生成XML文件，以树形结构存储。规则引擎调用加载这些XML文件，并遍历树形结构参数，完成规则匹配和数据匹配，执行条件对应的动作并输出结果。XML文件的这种存储结构加快了规则库的查询。XML文件的存储实现了规则引擎动态加载规则的功能。
规则中结构化部分如具体参数采用数据库的方式存储。课时计算中绝大部分涉及到的都是数据参数，这些参数结构化非常明显，参数出现的位置分为两大类：一类只出现在规则的动作中，如课时系数；一类规则的条件和动作中都包含参数，如人数系数。这些参数采用数据库存储的方式来存储。
4 结束语
基于规则开发系统优势明显，它将课时计算和津贴计算过程存在大量规则从业务逻辑中提取出来，使得整个业务逻辑不单是由程序员来修改和维护，课时计算规则发生变化时，熟悉业务的教务员就可以修改规则。这种设计满足了课时计算方法和参数不断变化的情况，同时也降低了系统维护成本。同时，各高职院校使用系统时可以根据自身情况选用相应的规则，也可以自行设计和修改规则，满足了通用性和特殊性需求的实现，提高了系统应用广泛性。
参考文献：
[1]陈兴顺.基于规则的公共事业计费引擎的设计与实现[D].吉林大学，2010.
[2]于淼，王延章，刘继山.信息系统业务规则的设计模式[J].计算机工程，2012（30）：27-28.
[3]许彦佳课时工作量计算系统[J].计算机光盘软件与应用，2012（12）：188-189.
作者简介：席洁（1983-），女，陕西长安人，校友会办公室主任，讲师，硕士，研究方向：计算机网络。
作者单位：陕西国防工业职业技术学院，西安 710300