The first instalment began with a look 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.  Next we examined how another new OMG specification -- the "Business Process Modeling Notation" (BPMN) -- could be mapped to xUML.  In the second instalment, I discussed how derivation rules can be represented in SBVR as well as in xUML.  In this segment I discuss how process rules are based on BPMN and can be represented in SBVR as well as in xUML.  I conclude with a discussion of how constraints are represented in both SBVR and in xUML.

5    Expressing Process Rules

5.1    Business Perspective in SBVR and BPMN

Let's assume that from the business perspective the following operative business rules have been formulated (in SBVR-SE):

Rule R5:

It is prohibited that a renter has signed a rental if that renter is on blacklist.

Rule R6:

It is prohibited that a rental books a car model that is phased-out.

Rule R7:

It is obligatory that a rental uses a car that is available and that has mileage that is minimal.^[7]

These operative rules seem to have some effect on business processes; they control the business activities 'create rental contract' (rules 1 and 2) and 'assign car' (rule 3).  More specifically, these rules prevent these business activities from being carried out as long as their necessary preconditions are not met.

In general, operative business rules affect the behavior of humans and/or IT systems, i.e., they affect business processes carried out by those humans and/or IT systems.  We may distinguish the following kinds of effects operative business rules may have on business processes:

• They may initiate business processes (obligations)

• They may allow business processes (permissions)

• They may disallow business processes (prohibitions)

As soon as we introduce such rules that affect business processes (currently not fully supported by SBVR), we need to extend our vocabulary in order to have the necessary concepts available to state those rules.  More specifically, we need to introduce the following process-related concepts into our vocabulary:

• Business activities are the primary components of business processes and (hopefully) produce some outcome.  Usually, business activities can be further decomposed into other business processes (and thereby described in greater detail).

• Business events are occurrence types that initiate business processes.  We may further distinguish the following kinds of business events:  explicit business events (e.g., 'customer appears at front desk'), implicit business events (e.g., 'open amount is over threshold'), and time events (e.g., 'end of day').

• Business artifacts are abstract or real things that are consumed, manipulated, or produced by business activities.

• Business executives are agents within a business that are declared to be responsible for the proper execution of some business activities.  Such business executives may be organizations, organization units, job positions, or people.  As a special but important case, IT systems may be regarded as business executives as well.

Business activities and business events are the 'core competency' of business process models.  Business artifacts are usually well covered by an SBVR vocabulary, and business executives are represented either in workflow models and/or in organization structure models.  After the merger of BPMI.org and OMG in 2005, the Business Process Modeling Notation (BPMN) became an OMG specification.  Since BPMN is a notation that supports all of the four key elements described above, I will use BPMN as a complementary vocabulary to SBVR to support the formulation of process rules.  The following diagram shows a fragment of EU-Rent's business processes represented in BPMN (Business Process Modeling Notation):

Note that the business activity 'check customer' shows a plus sign '+' which indicates in BPMN that this business activity is non-atomic and decomposed into another business process.  Please also note that this diagram introduces some business events such as 'new rental' and 'book car model' that will later become important in the xUML model as well.

Now, we are able to state some rules based on a combination of an SBVR vocabulary and a business process model in BPMN (the color scheme has been extended to include business activities), as follows:

Rule R5a:

It is obligatory to reject rental for a renter, if that renter is on blacklist.

Rule R6a:

It is prohibited to create rental contract for a car model, if that car model is phased-out.

Rule R7a:

It is permitted to assign car for a car, only if that car is available and has mileage that is minimal.

In those rules, 'for a' represents a keyword that introduces concepts from the context of a business activity and that are relevant to other parts of the rule (such as the 'if' clause).  In this form, obligations may be considered as triggers of business activities, whereas prohibitions, as well as permissions, may be considered as (necessary) preconditions for business activities.

5.2    IT-Perspective in xUML

As you may have noticed in the business process diagram above, the business activities have already been classified according to their IT support, as follows:

• IT support = automated:  This means that this business activity is completely automated by an IT system and needs no human intervention.

• IT support = supported:  This means that this business activity is supported by an IT system, i.e., some interactive services are provided to the human user.

• IT support = none:  This means that this business activity is not at all affected by the IT system and must be carried-out manually.

This decision can also be represented in the requirements catalog for the IT system, for example as follows:

Id	Priority	Type	Description
Rq7	H	Functional	Business activities 'create rental contract', 'assign car', and 'calculate final price' shall be fully automated.
Rq8	H	Functional	Business activities 'reject rental', 'handover car', 'check car', and 'accept payment' shall be fully automated.

In xUML, events are an important element of the interface between an IT system and its environment.  Business events that occur in the business (modeled in Zachman row 2) trigger some business activities that in turn request some functionality (also called 'use cases') from an IT system (modeled in Zachman row 3).  On the other hand, outcomes from these use cases are communicated by the IT system via events sent to its business environment.  On the business side of the boundary between IT system and its business environment we often have people (also called 'actors') who are responsible for the interaction with the IT system.  The xUML Use Case Diagram below defines which actors will be given access to which use cases:

This use case diagram is intended to support the business activities as specified by the requirements.  More specifically, we have the following traceability back to the BPMN business process diagram above:

• Use case 'handle rental' supports the business activities 'create rental contract', 'reject rental', 'calculate final price', and 'accept payment'.

• Use case 'handover car' supports the business activities 'assign car' and 'check car'.

• Use case 'handle renter' supports the business activity 'create rental contract'.

• Use cases 'define car model' and 'handle cars' support business activities of the car management business process not shown in this document.

In xUML, the individual use cases are formally specified by so-called 'black box sequence diagrams'.  These diagrams define, for each use case, which events may be raised by the actor.  As an example, the diagram below shows the events available to the actor 'sales clerk' when carrying out the use case 'handle rental':

The four black-box diagrams below show the available events when carrying out the use cases 'handover car', 'handle renter', 'define car model', and 'handle cars':  

The events renter, 'car model', and car represent the 'birth events' of the business objects renter, 'car model', and car, i.e., the events that create new instances of those business objects.^[8]  For reasons not relevant here, the xUML formalism strongly suggests naming the birth event of a business object with the same name as the business object itself.

From the use case model, CASSANDRA/xUML generates a simple, menu-oriented user interface for each actor.  For example, the screen dump below shows the generated user interface for a 'sales clerk':

In xUML, the automated parts of business activities are encapsulated in the business objects and the dynamic behavior of business objects is specified by means of state transition diagrams.  The most important elements of a state transition diagram are the following:

• A state is a named abstraction of a combination of properties of a business object showing different observable behavior from other states.

• A transition represents a reaction of a business object, usually triggered by the occurrence of an event and often accompanied by a change of the business object's state.

• An event is the named indication of some occurrence that may potentially cause some reaction by or some effect on a business object.  Events often carry parameters that transport additional information about the event that has just occurred.

• An action is a formally-specified effect of a transition in a business object after the object has been hit by an event.

• A guard is a Boolean expression that may prohibit a action from being carried out, even if the corresponding event has occurred.

The example below shows the state transition diagram of the 'car model' business object:

A state transition diagram is a way to express event-related rules in a semi-graphical form.  More specifically, a state transition diagram may represent two kinds of rules, as follows:

• ECA (Event Condition Action) rules specify that a particular action is to be carried out when a particular event occurs and a particular condition is true (the business object being in a particular state with, possibly, a guard).  The example state transition diagram above includes the following ECA rules:
  • If event 'change price' occurs and the 'car model' is in state normal then set attribute 'price per day' to the value of the event parameter price.

  • If event 'phase-out car model' occurs and the 'car model' is in state normal and there are no 'booking rentals' then delete that 'car model'.

• CA (Condition Action) rules specify that a particular action is to be carried out when a particular condition becomes true (the so-called 'change condition' indicated by the pseudo-event 'when') and another particular condition is true (the business object is in a particular state with, possibly, a guard).  The example state transition diagram above includes the following CA rule:
  • If no 'booking rentals' exist for a 'car model' anymore and the 'car model' is in state 'phased-out' then delete that 'car model'.

CA rules as described above are fairly common in business rules technology; they represent 'production rules' that are processed by 'forward inference engines' (sometimes also called 'forward chaining engines').

An interesting question that arises is:  "What happens if a business object is hit by an event but the business object is currently in a state in which it doesn't expect that event?"  For example in the state transition diagram above, what happens if one of the events 'change price' or 'phase-out car model' occurs but the car model is in the state 'phased-out'?  In CASSANDRA/xUML there are several options:

• Ignore:  The event is simply ignored.

• Warning:  A warning is shown to the user that this event was not expected in this state.

• Abort:  An error message is shown to the user and any further processing of this event is aborted.

• Rollback:  An error message is shown to the user, any changes already caused by this event are undone, and further processing of this event is aborted.

CASSANDRA/xUML provides a form of transaction support that is well suited to modeling business rules on a conceptual level.  The runtime system of CASSANDRA/xUML automatically starts a transaction each time when a user raises an external event.  During the processing of that event, every business object has a 'veto power' to abort or rollback the transaction for business reasons.  If no veto is made, the transaction is automatically committed by the runtime system after completing the processing of the user event.

With this in mind, let's see how the three original process rules stated earlier may be represented in the xUML model.

Rule R5a:

It is obligatory to reject rental for a renter, if that renter is on blacklist.

This rule is represented in the state transition diagram of the business object renter.  The event 'new rental' is only accepted (and processed) if the renter is in state normal, as illustrated:

If 'new rental' occurs when the renter is in the state 'on blacklist', the transaction is automatically rolled back.  This diagram also illustrates how some derivation rules are assigned to derived attributes (and thus become part of their specification) upon creation of a new renter.

Rule R6a:

It is prohibited to create rental contract for a car model, if that car model is phased-out.

When a new rental is created, this event ('new rental') is propagated via the business object rental to the requested 'car model' as the event 'booked car model'.^[9]  Here, the event is only accepted if the 'car model' is in the state normal (without any further effect); otherwise it is rejected, i.e., the transaction is automatically rolled back:

The diagram above reflects another interesting detail.  The event 'phase-out car model' is accepted when the 'car model' in the state normal.  However, there are two outcomes for this event:

• If there are no rentals that book this car model, it will be deleted immediately.  

• If there are still some rentals booking that car model, the car model simply changes its state to 'phased-out'.  Then, from that state there is a 'when' event that automatically deletes the car model as soon as there are no longer any rentals that book it.

This is a typical behavior pattern that is quite common; it even has a name -- 'intended death.^[10]

Rule R7a:

It is permitted to assign car for a car, only if that car is available and has mileage that is minimal.

In the xUML model, this rule has been divided into two parts:

• The condition of the rule is represented in the business object 'car model' (see state diagram above).  The derived attribute '/available cars' represents all cars that are available and of these, those that have the least mileage.

• The permission part of the rule is represented by a guard on the transition leaving the state defined of the business object rental (see state diagram below) and leading to its state active:  if there are some available cars of the booked 'car model', the first of these is tied to that rental.  If no car is available, the event is simply ignored.

The state diagram above also shows some other interesting details.  First, using an explicit 'rollback' action, a conditional action in the initial transition prevents a rental from being created when a non-existing 'car model' is specified.  Remember that the transaction is also rolled back by the business object 'car model' when the specified 'car model' is in the state 'phased-out'.  Finally, this state diagram illustrates how some of the derivation rules are assigned to the corresponding derived attributes '/total price' and '/discount'.

The mapping rules from the business perspective to the IT-perspective represented as an xUML model can be summarized as follows:

1. Business activities that are to be supported by an IT system will lead to use cases of the IT system.

2. Events become the interface between business objects and their environment (via use cases) and are specified via black box sequence diagrams.

3. Business activities that are to be automated will be specified by state diagrams of business objects.

4. Obligations to be automated will be represented as 'when' events in state diagrams of business objects.

5. Prohibitions to be automated will be represented as events that are only accepted in certain states of business objects.

6. Permissions to be automated will be represented as guards on state transitions of business objects.

These are not the only possible mapping rules, but they are a useful starting point.

6    Expressing Constraints

6.1    Business Perspective in SBVR

Let's assume that from the business perspective the following operational business rule has been formulated (in SBVR-SE):

Rule R8:

It is prohibited that a renter has an open amount that is larger than the credit limit of that renter.

This rule is based on the noun concept 'open amount', which is itself subject of the following structural business rule (in SBVR-SE):

Rule R9:

It is necessary that the open amount of each renter is sum of the total price of each rental that is signed by the renter.

If we look a little closer at rule R8 above, we realize that it represents a kind of constraint on the business; it prohibits any activity in the business that may lead to a situation where a renter may have overdrawn his credit limit.  This is non-trivial because this may happen in several situations:

• If a renter wants to sign a new rental but already has some active rentals close to his credit limit.

• If a renter wants to extend an existing rental, but his open amount is already is close to his credit limit.

• If the credit limit of a renter is decreased below the open amount of the renter.

• If the price per day of a car model rented by the renter is increased and the renter's open amount is already close to his credit limit.^[11]

• If the discounting rules change.

However, in the business process, we do not want to care about all these different situations where this rule may be applicable -- we just want to state the rule.  This is one of the fundamental reasons why business rules must be separated from business processes.

6.2    IT-Perspective in xUML

Constraints such as the example above may be stated very easily in xUML.  In the context of a renter, it simply means that the condition 'open amount' =< 'credit limit' must always be guaranteed.  This is achieved by inverting that condition and using it in a 'when' event added to state normal of a renter to cause a rollback (or abort), as soon as the inverted condition becomes true, as follows:

Adding a 'when' event that represents a constraint to on particular state means that this constraint is only maintained in that particular state.  In other words, as specified above, a renter may exceed his credit limit if he is on the blacklist.  If this is not intended, the 'when' event needs to be moved to a superstate that encompasses the states normal as well as 'on blacklist'.

The state diagram above also shows the representation of rule R9 in xUML.  It is a simple assignment of an aggregate expression to the derived attribute '/has open amount'.

Notes

[7]  Actually, the real SBVR-SE representation of this rule would be more complex due to the special semantics of the unary verb concept is minimal, but we ignore that here.  

[8]  A new 'rental' is created by the corresponding event 'rental' as well, but this event is not shown in the sequence diagrams above.  The reason for this is that a rental is created by a specific 'renter' instance (e.g., 'Jim Smith'), which in turn receives the event 'new rental' (shown in the 'handle rental' sequence diagram) and propagates the event as 'rental' internally.  

[9]  This could also be considered as the business event sent to the 'logistics' organization unit (see BPMN diagram).  

[10]  This is one of a family of so-called 'death models' originally developed in the context of the SSADM methodology.  

[11]  This may not be the intention of the business, but that is a different issue (not pursued further here).  

# # #