Parameterized rule where a specific business rule is a parameter within a generic business rule

The previous section illustrated the simplest examples of parameterized rules. Other subtler examples occur frequently. For example, let's return to the Trade Allocation sample application included in the Corticon Studio installation.

A recurring pattern in Trade Allocation might be that specific accounts prohibit or restrict the holding of specific securities for specific reasons. We might notice this pattern by examining specific business rules captured during the business analysis phase:

The first specific rule might be motivated by another, general rule that states:

The general rule explains why Airbus places this specific restriction on its account holdings – Boeing is a competitor. The second rule is very similar in that it also defines an account restriction for a security attribute (the issuer's industry classification), even though the rule has a different motivation. (A client's investments must not conflict with its ethical guidelines?)

There may be many other business rules that share a common structure, meaning similar entity context and scope. This pattern allows us to define a generic business rule:

Or, rewritten as a constraint:

Absent a method for accommodating many similar rules as a single, generalized case, we need to enter each specific rule separately into a Rulesheet. This makes the task of capturing, optimizing, testing, and managing these rules more difficult and time-consuming than necessary. In the example of Trade Allocation, an Account Restriction (as a Vocabulary term) might be associated with Account (as the holder or owner of the restriction), as well as other entities shown in the following figure. For illustration purposes, the Vocabulary is shown as a UML class diagram.

With this Vocabulary, the following Rulesheet can be defined:

Note that Transaction is the scope for this Rulesheet because all included rules apply only to Securities related to a specific Account and contained in the same Transaction.  (See the topic Rule Scope and Context for an in-depth explanation of Scope.) Also, note that the rule statements have been written as generic rules, with parameters appended to identify the specific examples involved in rule execution. This provides the user with a more complete explanation of which rule fired and why it fired.

The following Ruletest tests the second and third rule statements. A single transaction contains one account, Airbus, which has two account restrictions: no competitor securities and no tobacco industry securities. Two securities are included in the transaction, one for Boeing (a competitor) and one for RJR (a company in the tobacco industry). Running the Ruletest in the following figure, we see:

Note the Violation messages posted as a result of the rules firing.