规则挖掘最佳实践

业务规则挖掘

最佳实践

下面介绍了一种对技术规则进行语义捕获并将其抽象为业务规则的一般方法。

准备步骤

一系列准备工作有助于避免旷日持久的规则挖掘活动，确保规则对业务有价值，并加快创建“业务”规则而不是仅仅创建“技术”规则的过程。建议采取这些步骤来构建正确的组织框架，并将规则挖掘与业务优先级相一致。

1. 项目目标和预期输出

定义规则挖掘活动的目標和输出非常重要。这将根据组织的业务优先级而有所不同。对于某些组织来说，目标可能是解决高度定制的应用程序中的灵活性不足或停机时间过长的问题。这可能会导致决定转向支持SOA的打包应用程序。

根据目标，规则挖掘活动可以产生两种主要结果

文档在某些情况下，目标可能是开发程序代码段的以业务为中心的文档。这种文档对于其他分析师和主题专家来说很有价值，可以作为参考，也可以用来装饰现代化后应用程序的高级设计模型。它通常不会生成可执行的业务规则或输入到开发环境中。

业务规则在其他情况下，需要将应用程序中编辑和计算的精确语义行为捕获为真正的业务规则。捕获的语义将用作目标开发环境的基础，甚至可能直接输入到目标开发环境中。此步骤的结果将推动有关技术采用、资源规划和应用于这两种规则挖掘方法的最佳方法的决策。

2. 规则挖掘技术选择

主要手动方法规则挖掘中的一种低成本、低价值的技术应用是在文字处理或电子表格应用程序中记录规则。这种方法无法帮助解决规则挖掘中最资源密集的部分，例如分析应用程序行为并在源代码段中定位规则。

运行时模拟有助于捕获用户行为并将其转化为流程和规则的运行时模拟技术，可以从行为方面提供帮助。它们的主要缺点是，它们仅限于在给定时间段内实际执行的测试场景，可能会遗漏通常未执行的关键异常情况。

扫描工具能够在源代码中定位模式的文本扫描工具可以加速基于源代码中固定模式的规则捕获（例如，显示对变量的所有移动）。这些工具通常会生成大量误报，并倾向于导致技术规则而不是业务规则。

基于存储库的规则挖掘工具基于存储库的技术会重新编译源代码并构建语法解析树，可以在规则挖掘中提供最高价值。最先进的技术使用语义分析自动检测规则，例如，从感兴趣变量的点向上游的每个语句，以及可能影响其值的语句，都被挖掘为候选规则。

规则挖掘工具还可以提供规则管理和审计功能，从而简化项目工作流程和审查人员的规则维护活动。它们还能够保留规则到源代码的追踪性，即使源代码发生变化（这在实时环境中经常发生）。

考虑到以上内容，低成本规则挖掘方法的权衡在于更高的手动工作量和更低的结果质量。这在一次性的小规模文档场景中可能是可以接受的，但在企业级现代化工作中不太可能。

3. 时间和资源分配

项目目标和技术选择会影响资源分配。通常，业务方面的期望是收到从应用程序语义中推导出的精确建模的业务规则集，而没有意识到这种努力的复杂性。在 IT 方面，缺乏规则挖掘经验或不熟悉应用程序主题的从业人员不具备提供可靠估计的能力。

可以采用一种迭代的方法来进行时间和资源估计。在最初几周内，针对应用程序的代表性子集挖掘规则，可以洞察出最适合所选应用程序的方法，以及用于估计总工作量的衡量标准。

4. 业务流程映射和对齐

挖掘的逻辑之所以重要，是因为它的业务背景。毕竟，逻辑是总体业务流程的一部分。只有将挖掘的规则置于相关流程的背景下，它们才会有意义。例如，根据客户的邮政编码将其分配到收入类别中，在信用审批和营销活动流程中可能具有不同的意义（例如，保险公司宣传说他们只看过去的行为，而不是信用评级来设定保费）。

此外，从业务流程的角度查看应用程序对于确定规则挖掘活动的优先级非常重要。企业通常从其流程的角度来审视自身，例如注册新客户、承保保单、收款、登记索赔、将资金存入账户等等。其中一些流程对组织至关重要，而另一些则仅仅是商品功能。一些流程可能正在满足业务线主管设定的服务水平协议，而另一些则没有。现代化活动将集中在哪些领域，将根据这种计算而有所不同。

一旦对业务流程进行了建模，就会识别出支持所选流程的应用程序元素。从历史上看，这些应用程序是按孤岛组织的，这使得高级匹配成为一个直接的步骤。然而，在更细粒度的级别上，一个单一的订单管理应用程序可能会处理客户注册、信用审批、订单输入和订单履行。如果组织只对客户注册和订单输入组件的规则挖掘感兴趣，那么在流程及其支持的应用程序组合元素之间进行映射练习将是有益的。

使用基于存储库的软件，应用程序对象会被注册，并在它们之间自动捕获语法和语义关系。

记录重叠的情况，即一个程序或数据存储服务于多个业务流程。

示例 - 客户订单

在下图 1 中，尽管客户主数据、订单主数据和库存数据存储支持范围之外的其他流程，但它们仍然在规则挖掘的范围内。同样，客户处理程序是单块的，包括信用审批的逻辑，这超出了此次工作范围。

图 1：业务流程映射到应用程序对象

5. 应用程序分析

在前面的步骤中，已经对应用程序进行了清点，并且已经从高级别上理解了应用程序工件中包含的所需的业务流程。下一步是将应用程序分解为其组成逻辑元素。一个关键因素仍然是语境化。排除与组织优先级无关的应用程序元素。这种通过语境进行的范围界定使我们能够看到规则的“边界”及其相关影响。

应用程序分解

在此步骤中，应用程序进一步分解为其详细组件。目标是获得足够详细的工件集合，作为规则挖掘步骤的输入。

同样，技术也可以提供帮助。基于存储库的软件可以创建详细应用程序对象及其关系的解析树。然后，这些信息以多种图形和文本视图形式呈现，彼此同步以促进上下文相关的分析。

例如，上下文视图将以压缩和概述模式显示程序中所有数据字段声明、过程和过程调用。详细源代码视图将显示与上下文视图相对应的代码段，允许用户通过上下文视图快速浏览程序。遍历上下文视图，用户可以快速了解程序的结构和复杂性。

在详细程序级别上提供的其他视图包括段落之间控制流的图表、段落内的逻辑流程图、执行路径以及所选条件结果的运行时模拟器。这些工具用于在实际开始规则挖掘阶段之前，深入了解应用程序。

如果没有自动解析工具的帮助，仍然可以通过手动检查和遍历应用程序工件来获得价值。

识别排除项

在审查和分析应用程序的过程中，会标记出因功能和技术原因不应包含在规则挖掘范围内的元素。这些元素可能包括标准实用程序、报表、系统例程和范围之外的业务流程。在图 1 中的示例中，这将包括与信用审批和订单履行相关的工件，因为它们本质上是商品化的、标准化的业务流程。

排除项的识别说明了从上面描述的预先业务语境化步骤中获得的好处。如果没有进行这些步骤，则“全面扫描”方法将导致在规则挖掘和主题专家审查阶段投入更多资金，因为首先会挖掘出商品化业务流程的规则，然后会将其丢弃，因为它们不相关。

6. 词汇表创建

从应用程序中挖掘规则的一个主要挑战是，很难浏览其中的各种变量和命名约定。这些约定通常与业务术语之间的联系很微弱，这使得从业务角度理解逻辑变得很困难。

最佳实践是细化这些技术术语，以创建更以业务为中心的视图。这可以通过创建应用程序对象的词汇表以及相关的业务术语来实现。对象可以是数据字段、段落、程序、数据源以及其他感兴趣的应用程序对象。

词汇表术语的信息来源可以是业务文档、数据字典、数据库模式、用户通知，甚至源代码注释。

自动规则挖掘工具提供了一个功能，可以传播应用程序中重复模式（通常称为“标记”）的值。例如，标记“ACCT-”可以在任何地方都被“Account-”替换。然后，工具将使用词汇表中的业务名称在候选规则的自动构建过程中替换技术术语。

7. 规则组成和层次结构定义

预先建立所需的规则格式。相同的设置订单折扣的规则可以采用不同的形式，例如

(i) 声明形式：“每个来自加州的资深AAA会员都可享受 5% 的折扣。”

(ii) 如果-那么-否则形式：如果申请人是资深人士，那么如果她是 AAA 会员，那么如果她住在加州，则分配 5% 的折扣。

(iii) 作为决策表中的条目

图 2：决策表中的条目

将附加信息和工作流属性（例如）附加到挖掘的规则上可能会有用

• 审查文本注释
• 规则类型（输入/输出、计算、验证、安全）
• 审计状态（已批准、未批准）
• 工作流程状态（已提取、进行中、已接受、已拒绝）
• 转换（有效、需要修改、重复、完成）
• 审阅者身份
• 程序来源
• 代码段位置（开始、结束）
• 代码段文本
• 输入和输出数据元素

规则也会被置于层次结构中。所有代表决策或在给定条件下执行的规则都可以被分组到规则集中。规则集将被分组到更高层次的活动节点，反映它们当前参与的业务流程。

如果您计划填充可执行的业务规则管理系统 (BRMS)，您将需要定义一个易于转移到所选特定目标环境的模式。如果目标环境尚未确定，请参考可用的业务规则标准。

8. 规则挖掘工作流程

企业规则挖掘通常是一个多步骤的过程，涉及具有不同技能集的从业人员 - 包括顾问、开发人员、架构师、分析师和主题专家。通常，关键人员会被其他项目分散注意力，因此定义和记录通用工作流程至关重要。

遵循本文档中进一步提供的指南，高级工作流程可能如下所示

图 3：示例规则挖掘工作流程

每个步骤应根据采用的方法、项目范围和约束以及规则挖掘技术的使用进行详细定义。在规则以批准的最终格式呈现之前，前几个步骤可能会有多次迭代。

规则挖掘步骤

9. 候选规则挖掘

此时，规则是从映射到先前步骤中确定的业务流程范围内的应用程序工件中挖掘出来的。规则挖掘工具可以帮助您确保排除的工件不包含在范围内，方法是将应用程序组织成子分组。将为子分组挖掘规则，而不是为整个应用程序挖掘规则。

采取的具体规则挖掘方法主要由应用程序模式和所需输出驱动。

自上而下的方法

自上而下或面向过程的方法从在线应用程序中用户界面的检查或从批处理应用程序中的作业流程开始。

在在线应用程序中，事务可能是由用户选择菜单选项或在屏幕上输入值来调用的。标识定义从屏幕发送到接口应用程序的消息或事件的字段。触发消息中的每个字段都可以被视为规则挖掘的种子字段。

以种子字段为起点，记录对该字段的所有下游数据影响，包括所有条件排列。每次数据转换（移入另一个字段或计算）都代表要捕获的候选业务规则。

规则挖掘软件工具通过可视化每个种子字段到每个点（在该点它要么被新值填充，要么通过比较、值传播和计算用作其他字段的输入）的数据影响路径来帮助完成此任务。在每个这样的点上，该工具可用于记录基础业务规则。自动规则检测方法也可以应用于捕获每个屏幕字段编辑作为候选规则。

在批处理应用程序中，概念类似。识别作业流程的一部分，例如实现业务流程的 JCL 或组，并挖掘与该流程相关的单个程序中的所有规则。

图 4：自上而下的规则挖掘

在上图 4 中，请注意生成的“派生候选规则”的格式。它们是从 Cobol 程序中自动检测到的，类似于其结构，变量名称被词汇表定义替换。这些规则稍后将经过审查并转换为更具业务性的形式。虽然此示例演示了 Cobol 应用程序，但高级挖掘工具可以应用于从 PL/I 和 Natural 到 Basic Visual Basic 和 Java 的各种语言。

自下而上的方法

自下而上或面向数据的方法从对系统输出的检查开始 - 发送到文件（批处理和在线）的数据、屏幕和输出消息（仅在线）。

遵循这种方法，规则是通过从一个有趣的数据点开始并识别影响该点的所有逻辑来捕获的。例如，订单折扣字段受来自其上游计算的折扣影响，具体取决于客户的居住地。

图 5：自下而上的规则挖掘

规则挖掘技术特别适合这种方法。通过目视检查或存储库查询，可以快速识别感兴趣的数据输出。然后，自动规则检测例程能够为影响感兴趣点的所有语句捕获候选规则。由于上述已组织成上下文化子分组，因此搜索结果将受到被认为与规则挖掘相关的业务流程子集的约束。

检查相关的 DBMS 表格也可以生成嵌入在键中的规则以及任何用于参照完整性和值约束的数据规则。一旦涵盖了所有感兴趣的数据点，所有面向现有输出的感兴趣的应用程序逻辑本质上都已挖掘出来。

混合方法

混合方法结合了上面描述的两种方法

• 第一步是自上而下地捕获相关交易；
• 对于每个交易，执行自下而上的规则挖掘，包括尚未为其他交易挖掘过的所有数据输出。

这种方法的优点是扩展了规则挖掘的覆盖范围，同时避免了重复。

与图 4 和 5 中所示的示例相关，遵循严格的自上而下的方法会导致对数量和价格字段进行重复的工作，因为它们都遍历了相同的下游数据影响。由于没有发现所有有关客户折扣的规则，因此覆盖范围也不完整。

让我们考虑一个涉及订单输入和提案发布流程的扩展案例。采用排他的自下而上的方法也会导致重复，挖掘“命中”多个输出的上游数据影响的规则（例如客户折扣规则）。使用混合方法，我们首先会从订单交易的所有输出中挖掘规则，然后只挖掘提案交易中与其相关的输出。

图 6：混合规则挖掘

10. 候选规则验证

此时，从应用程序中挖掘出候选规则后，验证和校正是确保规则正确性和完整性的必要步骤。

检查候选规则，以了解

准确性 每条规则是否正确反映了基础应用程序行为？如果使用了自动规则检测技术，则在感兴趣点（种子字段）的规则之前将是来自其上游的规则，可能包含触发器、控制条件和自动规则集分组。对它们中的每一个（或选择的子集）进行准确性审查，并在需要时进行校正，直到结果令人满意。

冗余 对于同一个应用程序流程，规则或规则集是否出现两次？当分别为共享上游功能的两个单独输出挖掘规则时，就会出现这种情况。或者，它可能是简单疏忽的结果，例如多个团队成员无意中从同一个代码库中挖掘规则。规则属性用于标记重复。

另一种形式的冗余发生在语义上相同的规则从不同的流程中分别挖掘出来，并且具有不同的名称（例如订单详情和提案）。这将在下一步处理，当您将候选规则转换为业务规则格式时。

完整性 除了预定义的异常之外，所有应用程序功能是否都已涵盖？规则覆盖范围报告（将挖掘的规则源与总体源匹配）可以提供答案。

相关性 每条挖掘的规则是否可以被视为候选业务规则？虽然这还不是 SME 审查步骤，但可能存在某些结构，在检查时，这些结构显然无关紧要，不应包含在要审查的规则范围内。安全验证规则、维护例程和超出范围的操作都可能属于此类。在规则属性之一上指示相关性。

11. 将候选规则转换为业务规则格式

在前面的步骤中，候选规则已经从您的应用程序中挖掘出来并进行了审查，反映了遗留应用程序行为。这些规则紧密遵循应用程序的过程流程和操作。

现在需要一个转换步骤，将候选规则转换为实际的业务规则，以便进行审查。此步骤由应用程序专家、规则架构师或主题专家执行。审查和转换后，捕获的业务规则反映了当前的现状，作为基准或与目标环境的比较。

重新格式化为业务规则表示法

如果候选规则是手动构建的，它们可能已经采用选择的业务规则格式。在其他情况下，它们可能以技术格式（例如从源代码中剪切粘贴）被捕获，并且需要一些修改和重新分组。

如果使用了自动规则检测工具，则生成的候选规则可能有点类似于业务规则，通过使用词汇表定义将业务名称放置在规则名称、数据元素和控制条件中。但是，即使在规则验证步骤之后，大多数批准的候选规则也需要进行调整，以符合选择的业务规则表示法。

图 7：业务规则转换

事实建模和规则规范化 由于遗留应用程序的程序性质，它们倾向于将业务逻辑锁定在特定于流程的孤岛中。但是，真正的业务规则与流程无关，应作为独立的规则维护。

在我们的示例中，订单明细输入和提案输入事件的规则已分别挖掘并放置在规则集中。它们都是唯一的吗？经过进一步检查，其中大部分逻辑在设计上是相同的。从业务角度分析结果，任何客户文档的各个部分之间都存在共性 - 无论是订单还是提案。

从工具的角度来看，在这一点上，可能需要切换到业务规则管理系统 (BRMS)，将挖掘的规则从规则挖掘工具导入，如以下集成部分所述。

使用 BRMS 或可视化建模工具，构建一个反映您现有应用程序中发现的重要业务实体及其相互关系的事实模型。这些模型将与挖掘的业务规则相关联，并作为待定规则模型的基线。

在我们的示例中，事实模型的一部分将是

完成此操作后，业务规则将被规范化为表示所需的业务级语义

…其中，客户文档处理规则适用于订单和提案。

分组和排序

此时，将考虑生成的规则分组和排序。需要注意的一点是规则与其他规则和规则集之间的触发关系。由于候选规则通常是从第 3 代语言应用程序（如 Cobol 或 PL/I）派生的，因此它们以过程方式自动排序。转换为声明式模式将消除本质上非业务的过程元素。

如图 8 所示，反映真实业务需求的声明式关系将被建模为规则与其他规则或规则集之间的触发器。在大多数 BRMS 环境中，单个规则可能会触发多个规则和规则集，其中每个触发规则或规则集的排序仅在预编译或运行时解析。

图 8：现状业务规则模型（事件驱动）

主题专家审查和批准

一旦挖掘的规则被转换为业务规则，它们将被交给主题专家 (SME) 和/或业务分析师进行审查和批准。

通常，SME 此时不会对规则进行重大更改。规则挖掘工具可能包含规则归因功能，以帮助 SME 并使他们能够将业务规则标记为

• 已批准或拒绝；
• 重新分类到其他类别；
• 使用文本描述属性添加更多信息进行注释。

规则挖掘工具通常还提供功能侧重于预定义 SME 活动的 Web 门户。这可以极大地加速审查和批准流程。

12. 报告制作

业务规则报告以硬拷贝或数字格式创建。规则挖掘工具会生成报告和图表，以显示您所选上下文中的详细或汇总规则信息：层次结构级别、分组、搜索结果。这些报告既可以作为审查步骤的参考，也可以作为记录的文档。

13. 与目标环境集成

根据采用的现代化策略，与其他环境的集成要求会有所不同。

业务规则开发

使用业务规则方法进行重新开发通常会利用 BRMS 创作环境。这些工具通常包括 XML 导入功能，这些功能将用于定义“现状”业务规则空间，允许规则开发人员有选择地重复使用被认为与目标环境相关的候选规则。这将提供从新部署的规则到其传统来源的宝贵（有时是至关重要的）可追溯性。

传统开发

这种方法通常涉及使用全面的开发工具包构建 Java 和 .NET 应用程序。通常，UML 模型将用于在实际代码生成之前定义逻辑应用程序视图。

在这些环境中，挖掘的业务规则可以作为利用它们的 UML 类中的行为附加。例如，包括 Order_Discount 作为属性的 Order_Invoice 类还可以包括 Calculate_Order_Discount 作为类行为。此行为可以从执行相同功能的挖掘的业务规则中派生（并可能导入）。

BPM

流程管理业务流程管理 (BPM) 工具促进流程模型的创建以及与底层规则和可执行服务的链接。它们还包括定义工作流规则（使用 BPEL）以管理活动节点之间的手动和自动转换的能力。

在这种情况下，每个活动节点都可以通过业务规则实现。规则集和支持的活动之间可能存在多对多关系。使用相关的挖掘的“现状”业务规则填充 BPM 流程可以为业务分析师“闭环”，并显着推进 IT/业务对齐目标。

需求管理

供应商产品还包括需求工具，这些工具可以定义高级用例、详细流程图和活动，以有效地进行应用程序开发和管理。在这些环境中，挖掘的业务规则可以作为核心需求或作为活动节点的文本注释导入并附加。

SOA 启用

现有应用程序的服务启用涉及代码重构和作为服务封装部署。规则挖掘步骤在源代码中定位细粒度服务和提供所需服务组件方面非常宝贵。例如，自动规则检测以计算订单折扣的结果将包括所有导致最终计算的代码段。通过仅使用该代码（及其依赖项）创建组件切片，订单折扣计算可以作为服务重新部署。

14. 主动规则管理

我们预计大多数应用程序将在未来几年内继续维护和维护。从这些应用程序中挖掘了规则，因此至关重要的是它们能够持续更新并与未来的应用程序更改保持同步。规则挖掘工具提供维护和管理功能，包括

• 即使规则由于整体源代码更改而移动，也能够自动将规则与原始代码段对齐；
• 手动规则更改的审计跟踪；
• 允许在规则挖掘后进行单个或批量更改的“更改器”例程。

结论

一个明确的业务规则挖掘方法将允许在流程早期进行业务语境化。语境化步骤不仅有助于正确地构建挖掘的规则，而且还会减少规则挖掘投资，使其仅集中在感兴趣的关键和动态业务流程上。无论采用何种应用程序现代化策略，本文介绍的最佳实践和工具辅助方法将帮助您以更低的成本、更少的重复和更高的质量结果实现目标。

注释和参考文献

1. NEUER，Mannes。上下文为王：规则挖掘的实用方法