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:

Defining Business Rules ~ What Are They Really?

Chapter 5 - Action Assertions

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.

Action Assertions

Figure 9: Action Assertions
An action assertion is composed of an anchor object, one or more correspondent objects, possibly with one or more modifiers. <11> The anchor object may be any kind of business rule. Specifically, each action assertion must be a property of one other business rule. In turn, that business rule may be the anchor object of one or more action assertions. In the phrase, "If . . . then . . ." this is the phrase after 'If.' The anchor object is often a structural assertion, but it may also be another action assertion.

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:

  • "A car must have a registration number."

    • The business rule 'car' (which is a term) is the anchor object of this action assertion.

    • The business rule that expresses the possibility that a car may have a registration number (a fact) is the correspondent object of this action assertion.

  • "A car cannot be handed over to the customer unless a provisional charge has been accepted against the customer's credit card."

    • The handing over of a car is recorded as a state change on a rental. This resultant state is a term that is the anchor object of the action assertion.

    • The verification that a provisional charge has been accepted against the customer's credit card is the business rule (a fact) that is the correspondent object of the action assertion.

Action Assertion Classifications

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.'

Action Assertion Classes

As shown in Figure 10, every action assertion must be classified as either an integrity constraint, a condition, or an authorization.

Classes of Action Assertion

Figure 10: Classes of Action Assertion
An integrity constraint is an assertion that must always be true. It is considered to have immediate enforcement power because it prohibits any actions that would result in a false truth value. While a condition can test for a value (e.g., ask "is a car registered?") and then specify some action based on that test, an integrity constraint can declare that 'a car must be registered' and prohibit any action that would result in violation of that end state. Such an integrity constraint, for example, would prohibit both creating a new car instance without a registration value, as well as setting an existing car's registration to 'null.'

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.

Action Assertion Types

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.

Types of Action Assertion

Figure 11: Types of Action Assertion
An enabler is a type of action assertion that, if true, permits or leads to the existence of the correspondent object. The assertion is true if the anchor object exists. This has varying interpretations depending on the nature of the correspondent object:

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.

Controlling vs. Influencing

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.

Action-controlling vs. Action-influencing

Figure 12: Action-controlling vs. Action-influencing Assertions
The idea of action-influencing assertions argues for a particular orientation for decision support information. Companies may need to specify rules with their decision support information, to provide guidance:

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.

Definitions

The following summarizes the definitions of the concepts relating to Action Assertion.

Action
something that executes and may change the state of one or more instances of one or more Types. An Action has a protocol and one or more methods that implement it.

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.

Action Assertion
a statement that concerns some dynamic aspect of the business. It specifies constraints on the results that actions can produce.
Action-controlling Assertion
an Action Assertion that describes what must or must not be (or happen).
Action-influencing Assertion
an assertion that describes what should or should not be (or happen).
Authorization
an assertion that a specific prerogative or privilege has been defined with respect to one or more Constructs. It is an assertion represented the predicate: "(Only) x may do y", where x typically is a user and y is an action that may be executed.
Condition
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.
Construct
a generalization that represents either a Business Rule or an Action.
Enabler
a type of Action Assertion that, if true, permits or leads to the existence of the correspondent object. The assertion is true if the anchor object exists.
Executive
a type of Action Assertion that requires (causes) the execution of one or more Actions.
Integrity Constraint
an assertion that must always be true.
Timer
a type of Action Assertion that tests, enables (or disables), or creates (or deletes) if a specified threshold has been satisfied.

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

Copyright ©2001, the Business Rules Group. All rights reserved.