前页 后页

规则差距

决策规则必须先完整,然后才能实施到生产系统或服务中。这势在必行,因为它们必须完全覆盖所有可能的输入。可以为一个表定义一个以缺省输出条目为形式的包罗万象的条件,但是许多有经验的建模者更喜欢确保逻辑上覆盖所有输入。对于经验不足的建模者来说,通常也会排除在输入域或Universe的上下文中不可能输入的输入规则。一个更有经验的建模者将知道,即使当前的经验结果另有说明,一切皆有可能,因此将确保这些外部输入都被规则覆盖。可以执行Enterprise Architect的决策表验证来发现规则覆盖范围中的任何空白。这是一种非常有用的工具,因为决策逻辑中的错误可能会导致规则实施中甚至在某些情况下造成灾难性后果,从而导致不良结果。此图显示了一个简单决策模型,其中包含两个输入数据的单个决策元素;创建它是为了举例说明验证的使用方式。

第二张屏幕截图显示了部分完整的决策表,其中仅在行中定义了Gold客户。建模者无意间创建了包含缺口的规则。这是一个简单的演示,读者应该容易找到差距,但是在具有更多规则和输入的更为复杂的表中,定位问题可能会非常具有挑战性。

我们能够使用Enterprise Architect的内置验证工具来查找规则逻辑中的任何错误。在这种情况下,建模者已被撤职,未涵盖所有有效输入值。没有为销售价值为“(40,000-50,000]”的“金”级客户定义规则。

运行验证时, Enterprise Architect将打开输出窗口并显示验证错误,表明在这种情况下存在“违反完整行为”,并且还牵涉到表的哪些行。如前所述,该示例故意演示了该功能,并且可以通过扫描表规则轻松识别错误,但是对于更复杂的表,很难定位错误。

在此示例中,已为客户级别输入了允许的值,即“金,银,青铜”。在定义规则时,决策分析师忘记了包括输入值“ Bronze”的规则。

运行验证时,错误将被报告为空白,因为为客户级别定义的枚举值之一根本没有覆盖范围。

可以通过添加另一个规则来纠正该错误,该规则涵盖了Customer LevelBronze的情况 。然后,这将确保规则在语法和逻辑上都是正确的,并且在运行验证时不会出现错误,也不会生成警告。

生成到输出窗口的验证将是: