指南:业务规则
业务规则表示对如何操作业务(包括业务工具)的要求。本指南描述如何确定业务规则并对业务规则建模。
关系
相关元素
主要描述

说明

业务规则是对业务(包括业务工具)必须如何操作的各种要求。它们可以是强加在业务上的法律法规,但是也表示选定的业务体系结构和样式。有两种方法来捕获业务规则:

  • 基于模型 - 在 UML 模型中将业务规则作为定型的约束进行捕获。可使用自然语言或更正式的表示法(例如对象约束语言(OCL))来说明规则。该方法的优点是在业务规则适用的源中捕获并显示这些规则。主要的缺点是业务规则分散到整个模型中,因而要查看相关的业务规则非常困难。报告:业务规则调查提供了对模型中所有业务规则的概述。 
  • 基于文档 - 在单独的文档中捕获业务规则。该文档包含业务规则,但是它们并不是基于模型的方法中使用的业务规则。当大量业务规则适用(例如对于财务产品)时,基于文档的方法就非常有用了。缺点是在与业务规则适用的源不同的工件中捕获业务规则。

获取业务规则

可按文档和模型的形式来捕获业务规则。若想要以模型获得业务规则的概述,您可以生成报告:业务规则调查

对于有大段描述的业务规则(例如立法),“业务规则文档”尤其有用。基于文档的业务规则的缺点在于:它可能仍然必须从业务规则追及它所适用的模型的所有部分(若多于一个部分)。通过选择可在规则所适用的模型中被直接捕获的、基于模型的业务规则,可克服这种情况。但是,这种做法仍然有缺点,即某些规则“在模型中会被隐藏”,并且更难以获得具有某些共同特征(例如属于特定类别)的所有业务规则的概述。

形式化程度

必须对业务规则作出严密、正式的表述,使它们可形成自动化的基础。一个替代方法是使用“统一建模语言”(UML)[RUM98] 中指定的“对象约束语言”(OCL)。始终要考虑到业务规则的读者是谁。将重点放在读者有助于确保捕获业务规则的方式(文档或模型)、选择的样式以及形式化程度与目标对象相配。读者无法理解的业务规则在任何项目中都是一种时间的浪费。

示例:

您可能想要说明团队人数限制为少于十个成员。可使用 OCL 将该业务规则声明为一个不变的规则:

context Team inv:

    self.numberOfMembers <= 10

但是,您必须考虑到:要向很多项目干系人解释这种正式类型的语言可能非常困难,因此使用更自然的语言风格可能更为可取。您可以定义一组用于定义规则的、保留的表达句式。这些表达式可以与那些在 [ODL98] 中定义的表达式相同:

  • 如果
  • 仅当
  • 然后
  • 否则
  • 始终必须保持
  • 正确完成

示例:

在这种不那么正式的语言中,以上的示例将如下所示:

始终必须保持团队成员的数目少于或等于 10 个。 

业务规则的类别

尽管通常按约束规则和派生规则对规则进行分类,但规则的分类方法有很多。[ODL98] 可以按以下方式对这两种类别进行进一步细分:

  • 约束规则指定限制对象结构和行为的策略或条件。约束规则可能始终适用,也可能仅在某些条件下适用。始终适用的约束被称为不变约束
  • 激励和响应规则通过指定何时以及是否条件必须为真才能触发行为来约束行为。 
  • 操作约束规则指定在操作之前以及之后必须为真以确保操作正确执行的那些条件。 
  • 结构约束规则指定关于类、对象及其关系的、不应被违反的策略或条件。 
  • 派生规则指定用于从其他事实推断或计算事实的策略或条件。 
  • 推理规则指定:若某些事实为真,则可推断出某个结论。 
  • 计算规则通过处理算法得出其结果,它是推理规则的一种更为复杂的变体。 

在说明业务规则是什么、如何查找到它们以及如何使用业务规则时,业务规则的这种分类将非常实用。但是,您没有必要将它们作为您一直需要引用的固定分组。因此,我们为业务规则工件提供的模板并未显示该分类。在您的项目中,很可能将存在更具显示价值的其他分组(按域、按用户或按产品组)。关于分类以及应用业务规则的更多信息,请参阅 [ROS97]。

在模型中如何反映业务规则

业务规则影响着模型的外观。它还可以影响如何在活动图对任务进行排序,甚至可能影响业务实体之间的关联。 很难将某些规则直接转换到图的外观形式 - 这些规则可能需要放置在模型元素的描述中。 

UML 图中的业务规则应与它们所影响的模型元素建立链接。 

出于可跟踪性和报告的目的,在需求属性中跟踪业务规则也是有用的。

激励和响应规则

该类业务规则影响业务用例的工作流程,并可追及该规则适用的业务用例。您可能通过工作流程来显示条件路径或备用路径。若涉及的行动不是那么重要,那么使业务规则的评估包含在活动状态中就足够了。 

在业务分析模型中,该类规则可能(例如)影响对业务实体生命周期的描述方式,或它可能是对业务工作者的操作的一部分描述。检查确定的业务事件对于定义这些种类的业务规则是非常有用的来源。由于某人或某物对事件的发生感兴趣,所以业务事件通常被确定下来。询问问题:“一旦发生事件,该应用什么条件或行为?”

示例:

在订单管理组织中,可能会找到以下规则:

当订单被取消时

如果订单未装运

然后结束订单。 

通过在工作流程中显示两种备用路径,特别是通过在输出移交中使用决策和警戒条件,来反映该业务规则。 

附带文本中描述的图。

该案例中的业务规则通过工作流程转换为备用路径。

操作约束规则

该类型的业务规则经常转换为工作流程的前置条件和后置条件或者工作流程中的条件或备用路径。它也可以是性能目标或某些其他非行为规则(应追及该规则适用的业务用例)。 

示例:

在订单管理组织中,可能会找到以下规则:

为客户装运订单

仅当客户有装运地址时。 

附带文本中描述的图。

业务规则转换为工作流程中的备用路径。

示例:

以下是另一个操作约束规则:

始终必须保持

必须在接收到客户查询的 24 小时之内对所有查询作出响应

该业务规则将转换为业务用例的性能目标。请参阅指南:业务用例中关于性能目标的那一节。 

结构约束规则

该类型的业务规则影响业务实体的实例之间的关系。它们由两个业务实体之间存在的关联(有时作为关联的多重性)来表示。 

示例:

在订单管理组织中,可能会找到以下规则:

始终必须保持

一份订单包含至少一个产品。 

附带文本中描述的图。

该业务规则转换为多重性为 1..* 的关联。 

推理规则

经常,推理规则似乎与激励和响应规则以及操作约束或结构约束类型的规则相似。不同之处在于得出结论需要考虑一些步骤。规则暗示一种方法,该方法需要在工作流程的活动状态中,并最终在业务工作者或业务实体的操作中得到反映。 

示例:

您可能设置以下规则来确定客户状态:

认定客户是信誉客户的条件是当且仅当

该客户在发出尚未付款的发票之日起的 30 天内结清欠款。 

附带文本中描述的图。

该业务规则与工作流程的备用路径相对应,规定的方法将作为“评估客户”任务的一部分。

计算规则

计算规则与推理规则相似。不同之处在于该方法更为正式且看起来像算法。如同推理规则一样,此方法需要追溯到工作流程中的任务,并最终追溯到对业务工作者或业务实体的操作。 

示例:

计算规则可指定值的计算:

如下计算产品净价

产品价格 * (1 + 税金百分比/100)。

由于产生的是与订单一起发送的帐单,因此评估净价可作为任务“装运订单”的一部分。在业务分析模型中,该规则转换为关联和操作。 

附带文本中描述的图。

需要在“计算净价”操作中将该规则反映为方法,但该规则也意味着对模型中类之间的关系的需要。