Defining Business Rules ~ What Are They Really? (Appendix C)

This page contains Appendix C of the paper "Defining Business Rules ~ What Are They Really?", produced by the Business Rules Group. Other formats in which this paper is available are described in Defining Business Rules -- What Are They Really? (Abstract & Table of Contents)

Defining Business Rules ~ What Are They Really?

Appendix C - An Extended List of Action Assertion Types

In the main part of the text, rule types enabler, executive, and timer were discussed. These are in fact but three of a much larger number of rule types. Some of these are presented here. <12>

Instance verifiers -- These rules pertain to individual instances or occurrences of object classes.
- Mandatory -- something must occur, or a test for its existence.
- Limited -- constrains the number of instances of an object class that may exist.
- Restricted -- special case of 'mandatory,' involving recursive structures.
- Pre-existing -- requires occurrence of correspondent object class to exist before anchor object class, and still exists, or tests for that condition.
- Antecedent -- requires occurrence of correspondent object class to exist before anchor object class, whether or not it still exists, or tests for that condition
Type verifiers -- These rules control the creation of multiple instances in various object classes.
- Mutual -- requires instances of correspondent objects to exist simultaneously, or tests for that condition.
- Mutually exclusive -- requires that no more than one correspondent object exist simultaneously, or tests for that condition.
- Mutually dependent -- requires that either one instance of every correspondent object class exists, or that no instances of any correspondent object class exist, or tests for that condition.
- Mutually prohibited -- requires that at least one of the correspondent object classes has no instances, or tests for that condition.
Sequence verifiers -- These rules control changes in state. If an object class may be in multiple states (often portrayed on an e/r diagram as subtypes), then these rules determine the sequence in which instances of that object class may assume those states.
- Initializing -- requires that an instance of the supertype object class must be defined first in a specified state, or tests for that condition.
- Forward -- requires that once an instance of the supertype object class has attained a state, it cannot move to one lower in the defined sequence, or tests for that condition.
- Progressive -- requires that once an instance of the supertype object class has attained a state, it can only move to the next higher state in the defined sequence, or tests for that condition.
- Retrogressive -- requires that once an instance of the supertype object class has attained a state, it can only move to the next lower state in the defined sequence, or tests for that condition.
- Re-initializing -- requires that, if an instance of the supertype object class moves to a lower state in the defined sequence, it must be reset to the initial state, before it can be advanced, or tests for that condition.
- Cyclical -- requires that an instance of the supertype object class be advanced to the highest state in the sequence defined for this rule, before it can be moved to a lower state, and that the instance must be moved back to the lowest state in the sequence defined for this rule, before it can be moved to a higher state, or tests to see if an instance has been in both the highest and lowest state.
Position selectors -- These rules pertain to the position of a value (either of an attribute, or of the identifying attribute of an object class), either in a value sequence or a chronological sequence.
- Positioned, lowest and highest -- for value sequences, requires that the value of an instance of the anchor object class must be higher or lower than the values of all instances of the correspondent object class, or tests for that condition.
- Chronological, oldest and newest -- for chronological sequences, requires that the value of an instance of the anchor object class must be older or newer than the values of all instances of the correspondent object class or tests for that condition.
Functional evaluators -- These rules control the sequence in which instances of an object class are defined.
- Unique -- requires that no two instances of the anchor object class may possess the same values for the instance(s) of the correspondent object, or tests for that condition.
- Fluctuating -- requires that no successive instances of the anchor object class may possess the same values for the instance(s) of the correspondent object, or tests for that condition.
- Ascending -- requires that instances of a correspondent object class must increase in value for all successive instances of its anchor object, or tests for that condition.
- Descending -- requires that instances of a correspondent object class must decrease in value for all successive instances of its anchor object, or tests for that condition.
- Non-renewable -- requires that any given value of the correspondent object class, if used more than once, may be used only in strictly successive instances of the anchor object.
- Patterned -- requires that successive instances of the anchor object class be assigned in a specified sequence, or tests for that condition.
- Functional -- requires the value of any instance of the correspondent object class to be produced as a function of the relative position of the given instance of the anchor object class in the succession of all its peers.
Comparative evaluators -- These rules describe comparisons between pairs of instances of object classes. The comparisons may be 'equal to,' 'not-equal-to,' 'greater-than,' 'greater-than-or-equal-to,' 'less-than,' or 'less-than-or-equal-to,' and so forth.
Calculators -- These rules test the result of a standard computation involving values of the correspondent object class(es). Any standard computation may be the subject of one of these rules. Among the possibilities are: 'Summed,' 'Subtracted,' 'Maximum,' 'median,' and so forth.
- Type 1: The first type of calculator rule always indicates that an attribute is the anchor object. The result of the computation indicated for instance(s) of the rule's correspondent object class(es) is tested against the current value of this attribute type.
- Type 2: The second type of calculator rule always indicates a data object class as its anchor object class. This means that no calculations are actually performed on the anchor object class. For this reason, all type 2 calculators can only be conditions, never integrity constraints.
Update controllers -- These rules prescribe whether updates to a database may occur.
- Frozen -- requires that instance(s) of the correspondent object may not be created, deleted and/or modified while an instance of the anchor object exists, or tests for that condition.
- Frozen-to-users -- like Frozen, requires that instances of a correspondent object must increase in value for all successive instances of its anchor object, or tests for that condition, but this applies only to user-specified updates, not to any created automatically.
- Enabled -- requires existence for every instance of the correspondent object class, or tests for that condition. That is, if an instance of the anchor object exists, then the correspondent object is enabled, or the condition tests to see if the correspondent object is enabled.
- Enabled with reversal -- like Enabled, requires existence for every instance of the correspondent object class, or tests for that condition. However, unlike Enabled, if the rule's anchor object is deleted, the state of the correspondent objects is reversed.
Timing controllers -- These rules prescribe tests for the length of time that instances of correspondent objects have (or have not) existed.
- Timed -- requires a timing threshold for instances of the correspondent object class(es), or tests for that threshold.

Go to... Top of page | Next chapter | Table of Contents | BRG Home Page