OCL指南：业务规则

主题

• 解释
• 正式等级
• 业务规则分类
• 如何在模型中反映业务规则

解释

业务规则是对如何操作业务（包括业务工具）的各种要求。它们可以是业务需要遵守的法律或规范，也可以表示选定的业务构架和风格。

正式等级

必须严格、正式地表述业务规则，这样它们才能成为自动化的基础。作为一种备选的方法，可以使用统一建模语言中指定的对象约束语言 (OCL)。[RUM98]

示例：

您可能要表示对团队规模的某个限制，比如说，团队不能超过 10 个成员。使用 OCL，您可以将这个业务规则表示为一个不变量：

context Team inv:

    self.numberOfMembers <= 10

但是，您必须知道一点，许多涉众可能不容易理解这种规范的语言，所以一种较自然的语言类型可能更适用。您可以确定一组保留表达式用于定义规则。这些表达式可以与 [ODL98] 中定义的相同：

• IF
• ONLY IF
• WHEN
• THEN
• ELSE
• IT MUST ALWAYS HOLD THAT
• IS CORRECTLY COMPLETED

示例：

如果使用这种较自然的语言，上例中的规则表示为：

IT MUST ALWAYS HOLD THAT the number of team members is less or equal to 10（必须总是满足团队中成员的数目小于或等于 10）。

业务规则分类

规则可以按多种方法进行分类，但我们常将它们分为约束规则和推导规则。[ODL98] 两类规则还可以进一步细分为以下类别：

• 约束规则规定了限制对象结构和行为的策略和条件。

• 激励和响应规则对某一行为进行约束，方法是通过指定何时触发该行为以及是否必须满足某些条件才能触发该行为。
• 操作约束规则规定了在操作前后必须符合的条件，以确保操作正确执行。
• 结构约束规则规定了有关类、对象和它们之间关系的不可违背的策略和条件。

• 推导规则规定了从一些事实经过推理和计算得到其他事实的策略和条件。

• 推论规则规定如果某些事实为真，则可以推出一个结论。
• 计算规则通过处理运算法则（一种更精确完善的推论规则）得出结果。

应该把业务规则分类看作是对“业务规则是什么”、“如何找到业务规则”以及“如何使用业务规则”的解释，而没必要把它看作是工作中始终要参考的一个固定分类。所以，我们的业务规则工件模板并不显示这种分类 - 在您的项目中，很可能有其他分类方法（按域、按用户或者按产品组进行分类），这些分类方法可能更有价值。

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

业务规则会影响模型的外观。它还能影响在活动图中对活动进行排序的方法，甚至影响业务实体之间的关联关系。有些规则难以直接转换为图的形式，可能需要存在于模型元素的说明中。

不管怎样，使用文字注释表述业务规则并链接到图中适用相应规则的模型元素，这种做法十分有用。

激励和响应规则

这类业务规则影响业务用例的工作流程，而且可以被追踪到应用规则的业务用例。可以在工作流程中显示条件路径或备选路径。如果涉及的操作不太重要，则只需将对业务规则的考虑体现在活动状态中即可。

在业务对象模型中，此类规则可以影响您对业务实体生命周期的描述，也可以是对业务角色所进行操作的部分说明。

示例：

在订单管理组织中，可能会有以下规则：

WHEN an Order is cancelled

IF Order is not shipped

THEN close Order. 

该业务规则通过在工作流程中显示两个备选路径来表示。具体说来，即使用转换的判定条件和警戒条件。

此例中的业务规则转化为一个通过工作流程的备选路径

操作约束规则

此类业务规则通常转化为工作流程的“前置条件”或“后置条件”，或者转化为工作流程中的条件路径或备选路径。它可以是要达到的性能目标或某个应该追踪到应用该规则的业务用例的其他非行为性规则。

示例：

在订单管理组织中，可能会有以下规则：

Ship Order to Customer

ONLY IF Customer has a shipping address. 

业务规则转化为工作流程中的一个备选路径

示例：

以下是操作约束规则的另一个示例：

IT MUST ALWAYS HOLD THAT

All customer inquiries must be responded to within 24 hours of their receipt

此业务规则可以转化为业务用例的一个性能目标。请参见指南：业务用例中的“性能目标”部分。

结构约束规则

这类业务规则影响业务实体实例之间的关系。它们通过两个业务实体之间的关联关系表现出来；有时也表现为关联关系的多重性。  

示例：

在订单管理组织中，可能会有以下规则：

IT MUST ALWAYS HOLD THAT

an Order refers to at least 1 Product. 

此业务规则转化为一个多重性为 1..* 的关联关系。

推论规则

推论规则看上去常与激励和响应规则、操作约束规则或结构约束规则类似；不同之处在于，需要对其中的一些步骤进行思考才能得出结论。此规则为一种方法，需要在工作流程的活动状态中得以体现，最终在对业务角色或业务实体的操作中得以体现。

示例：

您可能已经建立了以下规则来确定客户的状态：

A Customer is a Good Customer IF AND ONLY IF

the unpaid invoices sent to this Customer are less than 30 days old. 

该业务规则和工作流程中的一个备选路径相对应，指定的方法将是评估客户 (Evaluate Customer) 行为的一部分

计算规则

计算规则和推论规则有些类似，不同之处在于它更正式，而且看上去象一个运算法则。和推论规则一样，此方法也需要被追踪到工作流程中的一个活动，并且最终追踪到对业务角色或业务实体的一个操作。

示例：

计算规则可以规定值的计算：

The net price of a Product IS COMPUTED AS FOLLOWS

product price * (1+tax percentage/100).

在开具随货发出的发票时，计算净价是发货 (Ship Order) 活动的一部分内容。在业务对象模型中，规则转化为关联关系和操作。

规则在计算净价的操作中必须作为一种方法表示，同时也是表示模型中类之间关系的一种需要。