规则引擎需求（捕捉业务规则需求，将需求转换为规则引擎）
转自：http://www.ibm.com/developerworks/cn/opensource/os-rulesengines/index.html
简介：?业务软件系统通常要处理复杂的重复任务，如处理保险索赔或发送货物包裹。这些系统是使用专用业务规则编码的，用于完成这些任务，但必须能够灵活适应变化。为了简化开发，允许快速部署更改，人们创建了规则引擎，独立于过程代码执行业务规则，允许在无需修改底层代码的前提下更改规则。了解业务规则的需求捕捉、建模和测试所用的工具和技术。
不同于一般的看法，软件开发中最困难的部分并不是系统的实际编码，而在于捕捉和解释含糊不清、不完整、往往彼此矛盾的业务需求。在沟通需求的早期引入的错误是最难纠正的系统错误，会导致开发补丁，并增加维护成本。在尝试捕捉和编码复杂业务规则时，这一点尤为明显。
业务规则有多种定义方法，但通常最好的思考方法是将其视为业务流程中的决策点。业务规则是根据 “if-then-else”类型的逻辑描述的，其中?if?是所满足的一组特定业务条件，then?是所执行的特定操作，else （否则）是可以执行的其他某些操作。举例来说，假设一家公司为其服务实行推广价格。推广存在有效时限，并且针对特定的一组产品或服务，则后台处理系统必须具有足够的能力，不仅能够为新客户正确实行推广价格，还能在恰当的时间中断推广活动。这些行为是由业务规则驱动的。
困难的部分在于将这些规则编入软件程序。大多数编程语言并未直接支持根据一组条件匹配或触发独立规则的概念 — 而大量业务流程都是规则驱动的（请参见下表）。
表 1. 规则驱动业务流程示例
?
这篇文章探讨了捕捉和建模复杂业务规则的分析技术。作为一个示例，我将使用水污染测试的一些假定规则。在这个主题领域，美国环境保护署（EPA）定义了确定饮用水污染物浓度的完善规范。出于本文的目的，假设测试是由监控地方供水系统质量的政府机构执行的。目的在于展示如何将简单的规则整合到复杂的结构中，实现健壮的业务流程。
回页首
捕捉业务规则需求
规则间的差异在于描述业务逻辑的用例行为（而非系统行为）方面。在典型的用例中，活动流是由特定参与者与系统间以执行特定目标为目的而开展的交互驱动的（例如，“管理水健康状况样本”）。与之相对，只有在其他系统处理（例如，为未清偿余款提供支付）导致准确匹配相应规则的条件时，该规则才会执行。因而，捕捉和验证业务规则的方法与用例开发大有不同。
定义规则
规则的结构通常是定义良好的条件与操作语句对。一般来说，最佳实践是成组编写规则条件，必须满足一组中的所有条件才能触发规则。尽管某些规则引擎允许在条件中使用?or?结构，但在实践中，此类结构可能会导致难以理解和测试的规则。在这些情况下，最好创建多个规则，涵盖每种?or?情况，而不要创建一条带有多种可能匹配场景的复杂规则。因而，在下面的例子中，默认的条件组合始终是?and?（请参见?表 2）。除此之外，在创建规则时，应尽可能保证其可独立执行，使指定操作的执行仅需一条规则。这将允许对各规则进行独立测试和验证，随后可以将这些规则合并成为更复杂的行为。
表 2. 规则分类
?
独立规则
独立规则是在原子级别上定义的 — 也就是说，您可以定义一个独特的条件组合，为这一组触发条件执行一条（且惟一一条）规则。表 3?给出了一个简单的规则定义，在这个定义中评估了水样是否符合既定的水质标准。在这个例子中，活动就是简单地生成某种形式的通知，但也可以在规则活动中执行更复杂的活动（如发传票）。请注意，这个规则定义可独立验证和理解，因而无需理解其他可能在此规则之前或之后执行的规则。
表 3. 单一规则定义
?
有时，一种条件的出现会改变另一种条件。例如，考虑这样一种情况，最新研究表明，若水样中存在 carbofuran（标准上限为 0.04 mg/L），则苯浓度的标准上限应折半（新上限 = 0.0025 mg/L）。这样一条规则可按如下形式捕捉。
表 4. 单一规则定义，修订版
?
请注意，现在不仅存在多个条件，还有多种活动。您可以使用?or?条件组合编写这两条规则，但正如上文所述，这将增加独立理解和测试各规则的难度，因而将规则分割为原子单位是最佳实践。
某些规则更适合以决策表?的形式表现，这种方法用于汇总大量共享同一组条件、其活动基于这些条件的可变值的规则。这种情况在金融机构中极为常见，批准贷款申请的决策要以申请人的信贷历史、工作状况、自有资产等条件为依据。
表 5. 表格式规则定义
?
上述每一行都表示一条单独的规则。大多数商业和开源规则引擎都支持以规则表格的形式捕捉规则的功能。
最后一种规则类型称为树状?规则。与前例相同，这种规则捕捉技巧是表示多条相关规则的一种简便方法，但这种形式允许查看用于达成特定结论的完整决策树。如?图 1?所示，客户可根据客户回报的级别、地理位置和所获得的产品组合得到折扣。
图 1. 决策树
规则组
规则可能密切相关，它们可能匹配相同的输入数据，也可能执行一组类似的活动（例如，验证规则）。组织这些规则以限制匹配时要考虑的规则数量通常比较有用。这样做主要是为了方便观察者，因为规则引擎优化算法足够强大，能够优化规则匹配。然而，如果一组特定数据使之前的处理步骤失败，这里会有一个显著的优势，这组数据将不再用于下游规则的后续处理，输入无效。这种排除简化了下游规则的条件，减少了出错的可能性。
可使用规则组，根据定义良好的分类组织规则分组，允许创建规则流。如?图 2?所示，规则流可包含支点和接点，允许极为细致地管理规则执行。通过使用规则组合流，您就可以清晰地建模整个规则引擎行为，并独立验证各规则。
图 2. 规则组模型
随着规则集变得越来越复杂，业务主题专家（SME）要完全理解和验证规则与规则组间的所有交互也变得越来越困难。这些交互和依赖关系的可视化建模提供了一种强大的机制，用于在开发团队、测试团队和业务参与者之间通信。在这种上下文中，最有用的三种模型是规则组的结构模型、组间的依赖关系图，以及规则引擎本身执行的执行流。
如图 2 所示，我使用了统一建模语言（UML）?stereotype??扩展机制来增强 UML 活动图，以提供捕捉这一信息的可视化模型。?rule-group??stereotype 表示一个规则组，?rule??表示一条指定规则。图 3 显示了指出一个规则定义的??condition??和?action??对的两种方法。
图 3. 规则 UML 模型
在直接与业务用户一起工作时，这种方法极为有用，因为它能以可视化的方式呈现规则，而非文本。与规则组建模图相结合，这两种模型视图可提供业务规则组中的规则的全面视图。
回页首
将需求转换为规则引擎
需求定义无需以上述形式定义，但这种方法能得到简化的实现，可直接回溯到指定需求。如?表 6?所示，这三个示例规则分别用于验证水样（Validate Water Sample）、评估水样（Evaluate Water Sample）— 超标（Exposure Limit Exceeded）?和?评估水样（Evaluate Water Sample）— 大肠杆菌（Fecal Coliforms），将使用 JBoss Rules (Drools) 开源规则引擎编码。
表 6. 示例规则定义
?
图 4 展示了这三种规则的 Drool 实现。
图 4. 三种水样规则的 Drools 实现
根据规则引擎实现和规则间的交互，往往需要确定规则执行的优先级。这方面的技术有两种，第一种是前面介绍的规则组和规则执行流。另一种技术是建立在独立规则级别上的，在此级别上，可为一个组中的某条规则赋予高于其他规则的优先级。（在 Drool 引擎中，这称为显著性级别（salience level）。）
有时会出现这样一些情况，例如需要在执行其他处理规则之前应用验证规则时、一条规则必须先于其他规则执行时 —— 即便两条规则都是触发的有效选择（也就是说，满足规则条件）。在这些情况下，规则可能具有重叠的条件组，或应在其他规则先执行后再执行。
在上述示例中，尽管两条规则位于同一个规则组（WaterSample）中，根据所提供的显著性水平，评估规则也将在验证规则后执行。假设水样未能通过验证，则水样的数据将从工作存储器中删除，不再用于匹配后续规则。
测试和验证
在规则引擎中实现业务规则时，最后一步就是确保编码的规则匹配需求。许多规则引擎都提供了测试和评估工具，但有些时候，有必要创建专用的工具。如图 5 所示，我们编写了一种工具，作为 Drools 引擎中所提供的测试工具的补充，允许测试团队动态选择验证数据，并查看结果和执行的规则。
图 5. 规则评估和测试
如图所示，以原子单位定义、捕捉和实现规则后，可以非常轻松地测试规则的正确性。使用自动化工具支持重复测试，确保新规则添加到集合中时，旧规则不会被违背。另外还要注意，在这个例子中，工具包含维护规则引擎的工作状态的功能，这就允许了有状态的动态测试 — 对于来自之前处理的数据必须呈现在规则引擎中以测试一组规则的执行情况的测试场景极为有用。
?
?
?
?
?
?
?
?
?
?
?
?
?
?
