1、1毕 业 论 文 外 文 翻 译Hybrid Rule Engine for Operational Policy Management混 合 规 则 引 擎 在 业 务 政 策 管 理 应 用翻 译 正 文摘 要 ： 规则集在许多规则引擎中作为规则模型结构使用。这样一种模式是不足以用明确的顺序来描述一些操作逻辑的。本文旨在从三个角度，包括分类的规则排序，文本对象和条件弱化。并且这些规则模型、语言和算法的特征的影响正被热议。为了满足这些要求，混合规则流被提出。航空货运装载可作为研究混合规则引擎技术的案例。I.引言：在商业应用领域，对于应用软件开发和维护来说，营销政策变化通常是一个很大的挑战。例
2、如，在一个竞选期间，服务供应商需要部署一个特定的计费/定价逻辑，但竞选期过后，原有的政策需要切换回去。为保持应用程序灵活，将应用程序代码与经营方针分离是十分必要的。规则引擎技术是一种通过建模和管理运营政策的业务规则。与传统的配置参数的方法相比，业务规则的描述能力是在描述复杂的逻辑关系是更加合适(Lu and Sadiq 2007)。目前，业务规则通常被建为规则集模型，和它的扩展形式，例如，决策表和决策树。规则集是一组无序的规则。规则表是一个简洁的组织结构。决策树是另一种逐步陈列条件的组织方式。通常条件下，业务规则由条件和行为两部分组成。因此，这类规则结构可以用简单的决策逻辑来很好地解决大多数业
3、务逻辑的问题，如客户评价，报价和目标市场，即这些逻辑可以表示为一组简单的“如果.那么.。”形式的表达式，来表达条件，然后采取行动。但是也有很多运营决策中需要有序的规则。例如，在航运中，货物装载于多个航段中，所有的航段都必须考虑在一起。在这样情况下将规则分离为“如果.那么.”形式的句子是非常困难的。在分配货物之后，条件（即，bin 中提供的重量和体积的限制，和飞机重量平衡状态）也发生了变化。如果我们建立一个规则集，那么其1 2中的每个规则都需要明确定义。关于这些特征，可见图 1 所示的规则流结构。在这个规则流模型中，规则的序列十分明确，并且也使用条件和行为。事实上，规则流是不可能在一个层面的，所
4、以规则流应展现为层次结构。在图 1 中，五边形块代表子流。在一些传统的规则引擎的包也有相应的概念(Lu and Sadiq 2007).。但是，其中子流是指嵌入在每个活动规则集的工作流。在本文中，我们将讨论业务规则的特征，并分析这些规则模型、语言和算法的特征的影响。基于这种分析，为了满足了所有这些要求我建议使用混合规则流模式。以及研究相关的规则引擎技术。示 例 图 1 规 则 流剩余结构如下。业务规则分类和混合建模的方法是在第二部分讨论。规则引擎应用情况在第三部分。在第四部分，研究空运货物装载计划的问题案例，并展示该规则建模的困难，建模方式和解决方案。最后，结论是在第五节得出。II。规则分类与
5、建模方法1 3A.业 务 规 则 分 类不同的业务规则可能需要不同的捕获方法，商业模式和执行算法。截至目前，几乎没有对业务规则分类的产品。Inastrol category 将一个业务规则的框架中归为 5种类型：资格，验证，计算，处理和权威。 Inastro taxonomy 源于业务功能的前景，它可以使用在业务规则中。本文重点介绍业务规则模型，因此，我们更关心的模型结构，语言格式和执行的算法。这些可以从几个角度描述：1) 规 则 间 的 排 序 。许多运营逻辑需要明确的顺序。例如，在航空货物装载计划，我们需要根据 FILa (First In Last Out 先入后出)原则在近距离之前装配
6、远距离的商品。但是，对于价格的折扣政策没有明显的排序。在当前规则引擎中，任何规则都可以被选中，规则集就是这样的业务逻辑。这个角色将对模型结构产生影响。对于规则没有顺序，我们可以一个规则集的结构。然而，对于这些规则的顺序，规则流可能是一个更好的选择。许多规则引擎的实现需要用户控制规则集的规则设置优先级，确保订单的触发将总是以特定的顺序。但控制权薄弱，因为通常数量优先级是有限的。在理论上，一个规则流模型可以是转化为决策树，但模型的块数将被大大增加。例如，如果图 1 被转化为一个等价的树结构，将增加 100%个条件块的数目，220%个动作块增加。与树型结构相比，流结构提供了一个简洁的方式。2) 规
7、则 的 语 境 。也就是说，在条件部分的评价对象是一个固定的业务对象还是一个可变的业务对象集/列表。这一特性将对规则语言的选择产生影响。如果规则的内容是一个单一的业务对象时，直接操作类属性/方法是足够的。然而，如果规则的内容是业务对象集或列表和设置/列表是动态变化的，对象查询语言保持表达简洁的状态是非常重要的是。 OCL（对象约束语言）和 OQL（对象查询语言）是两种描述对象的关系的流行语言，这可以被用作为规则规范的形式化语言。例如，我们想知道目的地 5 的商品中的最高密度的商品的最大体积是否大于 5 立方英尺。如果使用 OCL，我们只是使用Commodity.aIIInstance- sel
8、ect (destStation=5)-sortedby(weightjvolume) .volume-asOrderedSet()- first(5然而，如果纯级操作，我们可能需要多个规则，甚至包括一个循环。Rule 1 (Priority = 5)1 4IF 1=1THEN this.enumeratorGetEnumerator()Rule 2 (Priority = 4)j jwe need define 2 attributes (highestDensity,highestVolume) in business object to rememberthe temporary res
9、ults only for this logicWhile (this.enumerator.MoveNext()Rules 2.1 (Priority = 3)IF 1=1THEN this.currentCommoditythis.enumerator.CurrentRules 2.2 (Priority = 2)IF this.currentCommodity.destStation=5 &this.currentCommodity.weightjthis.currentCommodity.weightthis.highestDensityThenthis.highestVolume=t
10、his.currentCommodity.volumeRules 2.3 (Priority = 1)IF this.currentCommodity.destStation=5 &this.currentCommodity.weightjthis.currentCommodity.weight=this.highestDensity &This.currentCOmmodity.Volumethis.highestVolumeThenthis.highestVolume=this.currentCommodity.volumeRules 2.4 (Priority = 0)IF this.c
11、urrentCommodity.destStation=5 &this.currentCommodity.weightjthis.currentCommodity.weightthis.highestDensityThenthis.highestDensity=this.currentCommodity.wei1 5ghtjthis.currentCommodity.weightRule 3 (Priority =-1)IF this.highestVolume5THEN return trueElse return false3） 脆 弱 性 规 则 条 件 的 规 则 行 动 。也就是说，
12、在一个规则作用之后，其他规则会有多大的影响。例如，下面的规则是自成体系的。 If a customers membership level is “Golden“ and purchase amount is great than 100 USD,Then the discount rate is 0.85.顾客的折扣率是由他自己的属性决定的。规则的激活不会受到其他客户的影响。并且规则的执行不会影响其他客户。下面是在航空货运装载计划的另一个例子，If destination 5 commodities are the heaviest in the unassigned commodities
13、 and are less than afterward (called AFT hereafter) holds available limit, then put destination 5 commodities to the AFT hold.在这里，这条规则的激活，不仅取决于目的地 5 商品本身。有一个关于重量与其他目的地的商品的排名。如果在目的地 5 之前有分配的商品，则 AFT 也发生改变。这种规则的执行也可能对其他规则产生影响。这会对规则执行算法有很大的影响。Rete 算法也依赖于这样一个假设：执行的规则只能改变其他规则的几个条件。因此，构建一个 和 网络可以有效地减少不必要的
14、检查，提高规则的执行性能（在内存消耗成本获得的性能）。如果条件的脆弱性很高，我们必须使用迭代检查规则集。概括起来，我们将从以下 3 个角度对业务规则进行分类，如表 1 所示。1 6B.混合业务规则模型商业人士通常要尽可能地解决一个业务问题，并尽可能直观地解决一个问题，并在同一个地方验证决策逻辑。规则引擎技术的目的是增加业务规则变化的灵活性。分离的应用程序代码只允许这样的灵活性，在系统架构。为了使它真正的力量，我们需要确保业务规则是可以管理的，从业务的角度看。如果规则太复杂，要改变或者保持，规则引擎对业务用户是没有意义的。商业逻辑的复杂性是现实。有没有太多的方法来减少它。我们所能做的是在模型、语
15、言和算法中包含一个简洁的方法的复杂度。因此，而不是保持规则集作为一个单独的模型形式，从规则流。我们更希望将规则集作为规则流程中的模型元素包含规则集。这类规则流程是一种混合的商业规则模型。规则流模型是一个层次的有向网络，这可以由几个相互关联的流动组成。每一个流有向图由节点和之间的联系节点。有 5 种类型的节点如表 2 所示。*，表示复数。保持整洁，每个流或分流有一个单独的入口点叫做开始点。但它可以有多个出站连接到其他子流或终端节点。所以流节点或终止节点没有出站联动。开始节点没有入站链接流。条件类有 2 个出站支路，表示条件表达式为真、假时的下列路径。基本条件块是布尔表达式。在规则引擎工具，我们可
16、以提供一些扩展到容易的用户建模过程。例如，1 7矩阵的条件是一个二维组合条件。表条件可用于支持多维组合条件。行动类别是设置业务对象属性，或业务对象的调用方法。除了基本的格式，我们可以有许多扩展。如芸香行动作为一个单一的“如果那么”表达式、规则集、决策表、消息到回声信息时间规则执行、数据库查询，从数据库中查询一些数据，在规则执行中。通过这种方法，我们还可以支持规则集。但分离的条件和行动的 2 块提供了更多的灵活性，用户重用的通用模块，如图 1 所示。III、规则引擎A.架构为了支持混合业务模型，我们开发了一个可视化的规则引擎解决方案。它有 3 个核心组件：规则生成器，它是一个图形化的规则库，用于
17、规则编辑和管理。它包括一个 API接口 VI 加载项2）规则引擎是一个用于核心规则执行功能的分析器。它有能力与其他应用程序集成在原料药和数据级，3）业务对象建模提供了一种模型驱动的业务对象的定义和管理方法。在此架构下的每个角色的重点，值得关注的是分开。对于应用程序开发人员来说，他们的重点是定义应用程序特定的业务对象模型，与其他应用程序进行数据交换或服务调用的集成开发3）开发一个应用程序特定的虚拟接口，以最终用户。对于管理者或商业分析，他们的工作是根据当前的业务经营策略制定业务规则，并根据业务策略变更管理业务规则。最终用户使用应用程序特定的 VI。有了这样的架构，每一个角色的焦点/关注是分开的。
18、对于应用程序开发人员来说，他们的重点是1）定义应用程序特定的业务对象模型，2）与其他应用程序进行数据交换或服务调用的集成开发3）开发一个应用程序特定的虚拟接口，以最终用户。对于管理或商业分析，根据当前的业务操作策略，制定业务规则，并根据业务策略变更管理业务规则。对于最终用户，他所有的接口是应用程序特定的 VI。1 8B.规则引擎OCL 作为指定对象查询条件的正式语言因为 OCL 是最领先的面向对象技术具有许多优势，整体传统 defme 几级模板（如技术、自然语言等）的编码语言（如 java #，C，C+）。例如，OCL 的集合操作，可以在简洁的方式处理一组对象。我们也支持模板定义，以重用一些常
19、用的表达式。例如，如果我们定义comoasCommodity .alllnstance- select(destStation=O)- asOrderedSet()因此 是标记字符。因此，第二可简化为例com5-sortedby(weight/volume) .vol ume - first () 5C.规则编辑器规则编辑器提供了一个可视化规则建模和管理环境，有几个功能如图 2 所示，包括模型调色板和建模画布：一个拖放的方法来建立业务规则逻辑。2）工具栏以方便规则的创建，包括a）全球表达和参数定义，支持模板定义（OCL 表达式甚至自然语言）更容易的形式化语言输入b）模型元素的部分名称搜索c）O
20、CL 表达式计算器帮助用户验证的 OCL 表达式的语法d)数据库管理作为全局数据库连接配置，以便在规则执行中允许数据库访问e）Visio 文件导入/导出为微软 Visio 的界面。3）查看a)控制台来显示规则执行占用b）属性来显示/编辑模型元素属性在弹出窗口c)流导航器显示规则文件的层次结构d）概述为一规则流程概述4）规则的验证工具，确保规则流程的正确性和完整性，包括结构符合性检查、语法检查、和基于逻辑缺陷检测的随机模拟。为了支持规则模型，我们提供了丰富的模型调色板，如图 3 所示。对于简单的逻1 9辑，没有顺序，规则集或决策表本身可能是不够的。对于复杂的逻辑顺序，循环和嵌套，我们提供的规则流
21、的方法，让用户灵活地管理逻辑的层次结构。一些常见的流也可以被定义为一个模板，可以多次重复使用。规则集和决策表也可以是规则流的一部分。图 2 规 则 编 辑 器 环 境1 10图 3 型 号 面 板D.业务对象模型一种迭代扩展到业务对象模型的模型驱动方法。用户定义/编辑喜欢 UML 类图修改业务对象模型，并自动生成代码。我们提供这个功能，因为我们相信业务规则相关的项目通常是在一个迭代的方式进行。在规则流的执行中，使用可动态添加新的“属性”到业务对象模型。部署后，用户还可以定义他们的业务对象模型，并实现新的实施，改变规则模型的属性设置为“bypass“旧的。IV。 案例分析在美国北部的一个领先的航空公司，该规则引擎技术已经通过发展的负载规划系统（LPS）的领先的航空公司。自动生成一个最佳的负载计划，以提高其运作效率。此外，负载逻辑可以灵活地改变，根据适应新的业务逻辑。A.空运货物装载规划问题
