CN104020997A - 可扩展图形化规则应用系统 - Google Patents

Abstract

本发明涉及民航业务领域，提供了一种可扩展图形化规则应用系统，包括前端规则编辑模块和后端控制模块，前端规则编辑模块提供交互性强、反应快的图形化界面，供用户设置编辑规则；后端控制模块进行规则图有效性验证、规则图编译、数据存储等，并提供扩展接口使得技术人员能够快速开发新的子系统规则编译器。本系统通过可视化、高可用的图形界面，对民航业务规则进行便捷的设置和管理，可以提升使用体验，提高业务操作和软件开发效率、降低软件的维护成本。

Description

可扩展图形化规则应用系统

技术领域

本发明涉及民航业务领域，提供了一种可扩展图形化规则应用系统。 

背景技术

国民经济持续高速增长带来了中国民航业的繁荣局面，也使得国内各个航空公司在航空客运市场的竞争越来越激烈。为应对市场竞争，国内航空公司正逐步引入收益应用系统。如何在不提高现有运力成本的条件下，采取一系列有效的技术手段/措施，达到减小或者消除收益漏洞、最大化航班收益，这是提高航空公司收益的重要因素。 

订座记录控制是收益应用系统中的重要部分，也是情况纷繁复杂、难以处理的部分。航空公司希望进一步细分订座记录，对不同区域订座采取不同的处理措施。比如通常从各级销售渠道区域、航线航班区域等方面将订座记录分类，包括从GDS、国家、城市、office/pcc/iata、起飞到达城市等划分。处理措施也是多种多样，如设置出票时限为订座记录生成某天后或者航班起飞前某天，时限可以具体到某天某时；设置系统自动清票时限；给不完整订座记录的发送提示短信息等。 

可见，这类规则和措施的制定复杂繁琐，并且需要非常灵活的可配置性。目前，航空公司收益应用系统操作流程如图1。现有的操作方式存在着三个急待解决的问题： 

（1）录入方式复杂，交互性差，效率低下；

（2）规则配置方式不够灵活；

（3）规则管理不直观，修改维护不便。

 发明内容 

针对上述现有系统的缺陷，本发明的目的旨在提供一种可扩展图形化规则应用系统，实现图形化方式进行规则编辑、并且提供可配置规则应用系统扩展接口。解决传统配置方式用户体验不好、灵活性不高、管理维护不便等技术问题，提高网络收益部门的工作效率，同时能够加快技术人员扩展其他类型编辑器的开发速度，提升整个收益管理水平，带来可观的经济效益和社会效益。

本发明的可扩展图形化规则应用系统包括前端规则编辑模块和后端控制模块。前端规则编辑模块提供交互性强、反应快的图形化界面，供用户设置编辑规则；后端控制模块进行规则图（即图形化后的规则）有效性验证、规则图编译、数据存储等，并提供扩展接口使得技术人员能够快速开发新的子系统规则编译器。 

根据本发明的可扩展图形化规则应用系统，其中，所述前端规则编辑模块是用户进行规则编辑的图形化界面。用户可以直接拖拽界面上的基本图元到编辑区域，编辑图元属性信息，用连线链接两个图元顺序，从而进行规则设置。该模块可以分为两个个部分：GEF基础框架部分（Model层、EditPart层、Figure层）、规则编辑器（Rule Editor）部分。 

GEF基础框架部分使用MVC架构，实现了“Model”、“EditPar”、“Figure”之间的响应和处理，以及图形的显示和渲染，其底层依赖于Flex SDK。其中Model层实现基础数据描述和数据变更响应；Figure层首先实现了针对图元的扩展，在此基础上实现针对通用处理流程描述的扩展，即提供图元和连线，可以将图元用连线连接起来；EditPart层实现最基础的编辑接口，维护Model-EditPart-Figure之间的关系。整个GEF基础框架提供了一个图形编辑器的基础框架，规则编辑器（Rule Editor）部分基于GEF框架，实现航空公司收益相关规则的特定图元展示和编辑。 

根据本发明的可扩展图形化规则应用系统，其中，所述的后端控制模块包含四个功能模块：子系统规则扩展模块、扩展资源加载模块、规则图编译模块、规则图校验模块。实现规则的校验、编译为Excel决策表、保存规则到数据库等业务功能，另外还要提供子系统、规则图元、规则模版的扩展与加载功能。 

子系统规则扩展模块采用了Eclipse基于扩展点的插件扩展机制，将子系统、图元、模版组成的资源作为插件。 

扩展资源由扩展资源加载模块在应用启动时加载，接着会加载扩展文件。最后再根据扩展文件中的配置信息，依次实例化子系统、图元、模版。当应用终止时，扩展资源加载模块会去清除已加载的扩展资源。 

规则图编译模块负责将用户在界面编辑的规则图编译转换成一种能描述规则图所有数据信息的数据文件。规则图编译模块后端连接规则引擎，将规则图编译为能被Jboss Drools规则擎执行的Excel决策表，主要包括决策表表头生成、列生成、数据生成三个部分。 

决策表表头由规则编辑器的配置信息生成。列定义对应图元中的属性，包括：类型、对象变量声明、条件或行为表达式、注释说明。规则图编译模块会根据各个图元的列定义属性生成决策表列定义。 

决策表数据生成数据分为三个部分：路径计算、规则条目计算、生成数据。 

路径计算：规则图连线允许分支和聚合，即允许从一个图元出发指向多个图元，也允许由多个图元指向同一个图元。这样使得从开始图元出发会可能有多条路径达到结束图元。路径计算就是找出从开始图元到结束图元的所有通路。 

规则条目计算：每条路径上有多个图元，每个图元上有1个或多个规则条目。某条路径上的规则条目总数等于各图元上的规则条目数相乘。 

生成数据：每条路径上的规则条目汇总并写入决策表文件。每一个规则条目中包含若干个列的数据，这些列的数据会写到决策表对应的单元格中。 

规则图编译前，需要规则图校验模块执行校验，才能确保生成的决策表文件有效。校验主要有以下几条原则： 

(1)只能有一个开始和结束图元；

(2)至少有一个扩展图元；

(3)开始图元必须是第一个，结束图元必须为最后一个；

(4)连线校验，索引大的图元不能指向索引小于等于自己的图元，即按照左侧图元列表的先后顺序，排在后面的图元不能指向排在前面的图元，也不能指向和自己相同的图元；

(5)连线后不能有循环回路；

(6)不能有孤立结点；

(7)结点不能指向自身；

(8)名称为空的图元给出警告；

(9)扩展图元不允许作为开始或者结束图元。

本发明与现有技术相比的优点在于： 

（1）交互性强、速度快

采用本系统后，数据输入不再使用表格文件方式，而采用图形化界面编辑，体验优秀，交互性强，灵活性和效率大幅提升。本发明的图形化界面类似桌面应用程序，可以直接拖拽的基础图元到编辑区域。对于规则中基本图元的顺序关系，使用箭头联线方式表示。使用拷贝复制按钮或快捷键可以复制单个图元或者整个规则的信息；使用回退、前进按钮或快捷键能够回退到历史操作、进入到前一个操作。对规则中图元位置可以使用左右对齐等方式调整，界面尺寸也能够放大或者缩小。

依靠本发明的支持，用户能够快速新建编辑规则、设置规则中数据模块的关系，大幅提升用户体验、提高航空公司相关部门的工作效率。 

（2）规则管理更直观，配置更灵活、简洁 

航空公司用户在管理收益规则时，更希望能够看到整个区域设置的规则属性及其之间的关系。使用图形化配置方式，航空公司用户能够直观的看到所管辖区域内配置规则的全部属性信息。同时，规则图连线允许分支和聚合，这样用户在设置规则时，能从一个属性节点出发设置多个后续节点，反之亦可。这中操作方式使得规则配置更灵活更方便，大大提高了规则配置效率。

  

（3）提高开发速率，缩短新编辑器的开发周期

本发明图形化规则应用系统后端采用了基于Eclipse RCP的插件扩展机制，开发人员可以根据不同的应用（子系统）扩展出相应的规则图元及模版，保证了系统能够快速响应用户需求的变化，缩短开发周期。

附图说明

图1为现有系统规则设置流程图； 

图2为本发明的可扩展图形化规则应用系统组成框图；

图3为可扩展图形化规则应用系统流程图；

图4为本发明规则图校验模流程图；

图5为本发明规则图编译模块流程图；

图6为本发明可扩展机制原理图；

图7为本发明字系统规则扩展模块流程图；

图8为本发明部署实施图。

具体实施方式

如图2所示，本发明的实施例由前端应用服务器和数据库服务器组成。本发明的规则编译器图形前端可嵌入普通网页中，运行于用户浏览器；后端逻辑控制部分部署在应用服务器Web应用容器中；规则数据存储于数据库服务器。同时，本发明前端规则编译模块支持热更新。如果需要新增一个应用图元信息，可以在不停止前端服务器的情况下，将新增应用相关文件复制到前端服务器相应的目录，系统会自动加载新应用图元信息；同样的，需要删除某个应用图元时，只要把相关文件删除就可以了。 

参见图3，具体工作过程如下： 

步骤1：航空公司用户通过浏览器访问前端规则编辑模块，输入规则名称，创建规则。创建规则进入规则编辑器时，默认只有“开始”和“结束”结点，可以选择模版实现进入编辑器时有模板设定的图元结点。

步骤2：进入前端规则编辑模块后，用户通过拖拽图元的方式添加或删除规则节点，每个节点点击后可进入数据编辑界面，每个节点数据可以都设置多条。 

步骤3：待规则编辑完成后，用户点击验证进行规则校验。后台规则图验证模块接收到请求后，按照一定原则执行规则校验，并将校验结果信息返回到前台。 

步骤4：用户编辑完成后可以保存或修改规则。后台控制模块接收到请求后会访问后台数据库存储或修改规则。 

步骤5：在规则管理界面，用户可选择需要的规则进行生效。后台接收到生效命令后会从数据库取出相关规则条目进行校验，校验成功后，规则图编译模块将规则信息编译为决策表。 

规则图校验的具体实施过程如图4所示：用户提交校验请求后，首先将规则转换成json类型的字符串形式并传往后台。后台将收到数据进行字符串解析操作，得到图形数据对象，从图形根部开始遍历每条路径，按照上述校验规则进行校验。如果校验失败，将记录失败原因和相关节点信息。最后将校验结果返回前台界面。 

规则图编译的具体实施过程参见图5：首先将接收到的数据进行字符串解析，得到数据对象。接着根据应用配置信息生成决策表表头、根据图元列定义信息生成决策表列定义。最后也是最复杂的一步是数据生成，数据生成的前提是路径计算和规则条目计算。路径计算是寻找从开始图元到结束图元的所有通路。同时，每个图元上会有一条或多条数据规则条目，某条路径上的规则条目总数等于各图元上的规则条目数相乘。规则条目计算就是要计算出规则图中所有可能的完整条目。每一个规则条目中包含若干个列的数据，通过图元配置信息和列定义能够定位到决策表中的单元格，将列的值写入决策表中。遍历完成每个条目的数据写入后，也就完成了规则图编译、决策表的生成。 

如图6所示本发明图形化规则应用系统后端采用了基于Eclipse RCP的插件扩展机制，开发人员可以根据不同的应用（子系统）扩展出相应的规则图元及模版，参见图7，具体扩展方法如下： 

首先，定义决策表。基于规则编辑器开发规则的目标是生成子系统特定规格的Excel决策表文件，所以第一步首先是确定Excel决策表的表头、和列定义（Condition和Action定义）。其中表头对应子系统扩展配置，列定义对应图元配置。

然后，进行配置扩展。为了便于管理扩展资源，我们做了如下约定：子系统扩展开发目录为/ri/src/main/webapp/ruleEdit/extend/。 

ruleExt文件：扩展配置文件，约定命名为子系统加“.ruleExt”，如galt.ruleExt。 

nodeFigure目录：图元扩展目录，约定子目录名称为子系统名，如galt；子系统目录下放图元的资源目录，约定资源目录名为图元id，如orderLimit；资源目录下放图元图标、图元属性界面、图元模型等资源文件。 

template目录：模版扩展目录，约定子目录名称为子系统名，如galt；子系统目录下放模版的资源目录，约定资源目录名为模版id，如flat；资源目录下放模版图标、模版模型等资源文件。 

配置扩展部分需要创建扩展文件。规则扩展文件（*.ruleExt）与Eclipse插件扩展文件（plugin.xml）的格式一致。只是为了区分，把文件名后缀改为了“.ruleExt”。接着是扩展子系统、扩展图元，包括配置图元基本属性，配置图元列定义。 

最后，进行属性界面开发。图元属性界面主要用于展示和存储规则条目数据，接收用户输入。属性界面主要用html语言编写，或者类似jsp、asp的动态网页亦可。本发明提供几个框架功能供属性界面开发者使用，包括界面数据初始化、图元数据获取、图元数据修改和存储等。 

另外，本发明还提供两个高级配置，这两个配置不是必需，只是为了方便用户较少数据输入量提供默认值或模版，开发人员可以根据需要进行配置。 

扩展模版。默认情况下，创建规则进入规则应用系统时，只有“开始”和“结束”结点。可以通过配置模版实现进入编辑器时有特定的其他图元结点。模版配置最重要的属性是一个JSON文件，文件内容表示一个完整的规则图。配置成功之后，进入新建规则界面时，选择“demo子系统”，可以看到新配置的模版。 

配置图元属性界面初始值。一般情况下，从规则应用系统图元列表中拖出来的图元，双击后打开的属性界面都没有初始值。通过配置图元规则模型（ruleModel）可以使得图元带初始值。模型文件的内容为JSON格式，表示图元的结点模型。配置成功后，再重新从图元列表中拖出该图元，可以看到图元的文本输入框有了初始值。 

如图2所示为可扩展图形化规则应用系统系统架构示意图，应当指出，在不脱离本发明技术解决方案原理的前提下，可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。 

针对本发明的技术方案，所述的规则图校验模块中的校验规则是一类规则的总称，应当指出，规则图校验模块处理其他子系统规则也应视为本发明的保护范围。本发明未详细阐述的内容为本领域技术人员的公共常识。 

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。 

Claims (5)

1.一种可扩展图形化规则应用系统，包括前端规则编辑模块和后端控制模块，其特征在于：

所述前端规则编辑模块包括GEF基础框架模块和规则编辑器模块；

(1)所述GEF基础框架模块使用MVC架构，实现Model层、EditPart层以及Figure层之间的响应和处理，以及图形的显示和渲染，其底层依赖于Flex SDK，其中Model层实现基础数据描述和数据变更响应，Figure层首先实现了针对图元的扩展，在此基础上实现针对通用处理流程描述的扩展，即提供图元和连线，可将图元用连线连接起来，EditPart层实现最基础的编辑接口，维护Model层、EditPart层以及Figure层之间的关系；

(2)规则编辑器模块基于GEF基础框架模块，实现民航业务相关规则的特定图元展示和编辑；

所述的后端控制模块包括：子系统规则扩展模块、扩展资源加载模块、规则图编译模块、规则图校验模块，其中：

(3)子系统规则扩展模块采用了Eclipse基于扩展点的插件扩展机制，将子系统、图元、模版组成的资源作为插件；

(4)扩展资源加载模块在应用启动时加载，接着会加载扩展文件，最后再根据扩展文件中的配置信息，依次实例化子系统、图元、模版，当应用终止时，扩展资源加载模块清除已加载的扩展资源；

(5)规则图编译模块负责将用户在界面编辑的规则图编译转换成一种能描述规则图所有数据信息的数据文件；

(6)规则图校验模块执行规则图校验。

2.如权利要求1所述的系统，其中所述规则图编译模块后端连接规则引擎，将规则图编译为能被Jboss Drools规则擎执行的Excel决策表，包括决策表表头生成、列生成、数据生成三个部分。

3.如权利要求2所述的系统，其中所述决策表表头由规则编辑器的配置信息生成，列定义对应图元中的属性，包括：类型、对象变量声明、条件或行为表达式、注释说明，规则图编译模块根据各个图元的列定义属性生成决策表列定义，决策表数据生成分为三个部分：路径计算、规则条目计算、生成数据。

4.如权利要求3所述的系统，其中：

(1)路径计算：规则图连线允许分支和聚合，即能够从一个图元出发指向多个图元，也能够由多个图元指向同一个图元，使得从开始图元出发可能有多条路径达到结束图元，路径计算就是找出从开始图元到结束图元的所有路径；

(2)规则条目计算：每条路径上有多个图元，每个图元上有一个或多个规则条目，某条路径上的规则条目总数等于各图元上的规则条目数相乘；

(3)生成数据：每条路径上的规则条目汇总并写入决策表文件，每一个规则条目中包含若干个列的数据，所述列的数据会写到决策表对应的单元格中。

5.如权利要求1-4之一所述的系统，校验需遵循以下原则：

(1)只能有一个开始和结束图元；

(2)至少有一个扩展图元；

(3)开始图元必须是第一个，结束图元必须为最后一个；

(4)连线校验，索引大的图元不能指向索引小于等于自己的图元，即按照左侧图元列表的先后顺序，排在后面的图元不能指向排在前面的图元，也不能指向和自己相同的图元；

(5)连线后不能有循环回路；

(6)不能有孤立结点；

(7)结点不能指向自身；

(8)名称为空的图元给出警告；

(9)扩展图元不允许作为开始或者结束图元。