This page contains Chapter 5 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)
The subsections in this chapter are:
An action assertion is a statement that concerns some dynamic aspect of the business. It specifies constraints on the results that actions can produce. The constraints are described non-procedurally, in terms of the other atomic business rules. Where the structural assertions describe possibilities, action assertions impose constraints -- 'must' (or 'should') or 'must not' (or 'should not'). Figure 9 shows the business rule model of action assertions.
A correspondent object may be either another business rule or some specified action, represented by the generalized term construct, where a construct is either some other business rule or an action. That is, a construct is the correspondent object in an action assertion.
An action could be the sale of a car, rental of a car, or suspension of a customer. Each of these things could be the correspondent object in an action assertion. An action assertion is evaluated using one or more constructs. These describe the conditions doing the constraining. In the phrase, "If . . . then . . ." each of these would go after 'then.'
For example, action assertions might be:
Action assertions may be classified in three ways. First, an action assertion class identifies whether an action assertion is either a condition, an integrity constraint, or an authorization. An action assertion may also be classified into one of a larger number of action assertion types, which define the specific nature of the constraint. Finally, an action assertion may be defined as an action controlling assertion or an action influencing assertion. The remainder of this chapter explains and illustrates these three classifications of action assertion.
Note that the first action assertions that will be apparent are those that can be depicted graphically in a conceptual model, such as those that constrain a relationship to applying to 'at least one' or 'no more than one' occurrence of an entity. Similarly, attributes may be constrained as 'mandatory.' Other model graphics permit subtypes to be specified as 'mutually exclusive' and subtype clusters to be designated as 'complete.'
As shown in Figure 10, every action assertion must be classified as either an integrity constraint, a condition, or an authorization.
A condition is an assertion that if something is true, another business rule will apply. It can be thought of as a 'test' -- if true, it may be the basis for enforcing or testing other action assertions. For example, a condition can ask: "did a customer not show a valid driver's license?" "is a customer in arrears?" or "has a customer placed an order?"
An authorization defines a specific prerogative or privilege with respect to one or more constructs. It is an assertion represented by the predicate
(Only) x may do y,
where x typically is a user and y is an action that may be executed or performed. Authorizations are given only to types capable of independent activity (e.g., people, departments, computers, etc.). For example, only a branch manager of the 'losing' branch may assign a car for transfer to another branch.
As shown in Figure 11, every action assertion may also be classified by type. The business rules model depicts only three possible types -- enabler, timer, and executive. This list is by no means exhaustive. Appendix C presents one view of a more comprehensive set of types than that discussed by the Project team or this paper.
More precisely, the above description is of an enabler that is an integrity constraint. When an enabler is a condition, it simply tests to see if the correspondent object is enabled rather than directly enabling the correspondent object.
A timer is a type of action assertion that tests, enables (or disables), or creates (or deletes) if a specified threshold has been satisfied. A timer can be thought of as a 'countdown timer' -- its effect occurs after the 'ticking' stops -- or as an 'alarm clock.' In the latter case, its effect occurs when the alarm clock 'rings.' For example, if the thing that is controlled by a timer is another action assertion, then the timer will 'turn on' the action assertion. If the thing that is controlled by a timer is a structural Assertion (e.g., an attribute), the timer will set (or test) its value.
An executive is a type of action assertion that requires (causes) the execution of one or more actions. The following example shows how these types can be combined in various ways. In the statement "if a customer is three months in arrears, then repossess the car," the part that measures (counts down) 'three months in arrears' and requires action thereafter is a condition of type timer. A second action assertion 'repossess the car' is an integrity constraint of type executive.
All of the action assertion classes and types described above are intended to be used to define what must (or must not) be or what must (or must not) happen. When used in this way, they are examples of action controlling assertions.
Action assertions can also be used, however, to describe what should (or should not) be or what should (or should not) happen. These action influencing assertions tend to be things that companies are not inclined to build into computer systems as hard constraints. However, they may be of sufficient interest that management wants to be notified by the information system if they are violated. Or they may simply serve as guidelines in the human activity system, with or without direct automation support.
Figure 12 shows this classification of an action assertion as either an action-controlling assertion or an action-influencing assertion.
For example, "in each quarter, no more than 10% of rentals should have free upgrades."
For example, live with a one-off anomaly, change the mix of cars at the branch, or discipline the manager.
Meeting these requirements may require the definition of additional terms and facts.
Aside from identifying that there is an 'influencing' form of an action assertion, the Business Rules Project has not modeled these in detail in this stage of the Project.
The following summarizes the definitions of the concepts relating to Action Assertion.
An Action cannot be constrained; only Types (things that have persistent instances) can be constrained. The enabling and execution of an Action can be controlled through Business Rules. An Action is permitted to proceed once/if conditions are satisfied.
Go to... Top of page | Next chapter | Table of Contents | BRG Home Page
Copyright ©2001, the Business Rules Group. All rights reserved.