In the first instalment, we looked at how business rules are stated in a business-oriented language as described by the OMG specification "Semantics of Business Vocabulary and Business Rules" (SBVR).  That perspective was then contrasted with business rules as stated in a more IT-oriented form and expressed in an interpretation of xUML.  We also examined how another new OMG specification -- the "Business Process Modeling Notation" (BPMN) -- could be mapped to xUML.  In this segment I discuss how derivation rules can be represented in SBVR as well as in xUML.

4  Expressing Derivation Rules

4.1    Business Perspective in SBVR

Let's assume that from the business perspective the following structural business rule has been formulated (in SBVR Structured English):

Rule R4:

It is necessary that the total price of each rental is the number of days of that rental x the price per day of the car model that is booked by that rental x (100 - the discount of that model) / 100.

This structural business rule supports the definition of 'total price' and, as a structural business rule, is "true by definition."  If we introduce the notion of a 'context concept' for a rule (currently not part of SBVR), we could simplify the above structural business rule by specifying its context to be 'rental', as follows:

Rule R4:

Context rental: It is necessary that the total price is the number of days x the price per day of the car model that is booked by that rental x (100 - the discount) / 100.

Furthermore, let's assume that the following decision table representing a set of structural business rules has been stated as well:

Ruleset RS1:

Although these rules are not expressed in SBVR Structured English, they still comply with SBVR as they are based on the noun concepts and verb concepts defined in the vocabulary introduced earlier.

4.2    IT-Perspective in xUML

Again, first we have to define the requirements for the IT system.  This time, we not only define functional requirements, but also a non-functional requirement that is typical for business rule systems, as follows:

In the general case, the structural business rule about the 'total price' stated above needs to be transformed into a set of derivation rules in xUML:^[4]

1.    'total price' = 'booked model'.'price per day' * 'number of days' * (100 - discount) / 100;

2.   discount = 100 * 'total price' / ('booked model'.'price per day' * 'number of days') - 100;

3.    'booked model'.'price per day' = 'total price' / ('number of days' * (100 - discount) / 100);

4.    'number of days' = 'total price' / ('booked model'.'price per day' * (100 - discount) / 100);

The reason for separating a single structural business rule into a number of derivation rules is because CASSANDRA/xUML (as most commercially-available business rule engines) currently does not include a constraint solver.  The four derivation rules stated above form a kind of 'definition cycle':  if the value of more than one of 'total price', discount, 'booked model'.'price per day', and 'number of days' is unknown, we are unable to determine any of those values.  Thus, we need to decide which elements are given and which are to be derived.  This is the reason why, in xUML, some attributes are declared as derived (i.e., those with a preceding slash in front of the attribute name) and some not (i.e., the attributes that have declared, user-supplied values).

In the Business Object Model introduced earlier, we have already decided that 'total price' and discount will be derived attributes and the others will be declared attributes.  The derivation of 'total price' will be specified by a mathematical formula and the derivation of discount will be based on the decision table specified at the business perspective.  So, we end up with the following derivation rules (expressed in proper CASSANDRA/xUML syntax):

a)    '/total price' := 'booked model'.'price per day' * 'number of days' * (100 - '/discount') / 100;

b)    '/discount' := (

10 if 'number of days' >= 14 or 'signing renter'.'is VIP';

5 if 'number of days' >= 7 and 'number of days' < 14 and not 'signing renter'.'is VIP';

0 otherwise);

Note that the equals symbol ('=') in the original derivation rules has been replaced by the assignment symbol (':=').  This means that the whole expression on the right-hand-side of ':=' (not the result of its evaluation) is 'assigned' to the derived attribute and thus becomes part of its specification.  Please also note that the rule set assigned to '/discount' has been optimized to three rules^[5] (from four columns in the original decision table) by introducing the 'or' operator.

It is important to remember that the rules stated above are formulated in the context of the business object rental.  They could also have been formulated in another context (e.g., renter) or in a global context, but they would then need to be expressed in a more complex form.

Now, whenever the '/total price' of a rental is required, derivation rule a) is applied.  Since this derivation rule requires the given '/discount', derivation rules b) are applied each time as well.  Which one of these actually determines the discount depends on their condition.^[6]  This process of chaining derivation rules in order to determine a particular outcome is also called 'inferencing'.  Since we started with the outcome (the 'total price') and moved backward, finally ending at the declared attributes ('booked model'.'price per day' and 'number of days'), this is a simple form of 'backward inference' (sometimes also called 'backward chaining').

Next Time ...

In the next instalment, I will discuss how process rules are based on BPMN and can be represented in SBVR as well as in xUML.  In addition, I will discuss how constraints are represented in both SBVR and in xUML.

Notes

[4]  A word in blue represents an element from the xUML model.  The quotes are used in CASSANDRA/xUML to delimit symbol names that contain special characters (such as spaces); they have no further relevance here.  

[5]  Or even two and a half rules, if one counts the 'otherwise' clause as a 'half rule'.  

[6]  If the condition of more than one rule is true and these conclusions would yield different discounts, we have an inconsistency in our rule set, which would be reported by CASSANDRA/xUML.  

# # #