Moving from Zachman Row 2 to Zachman Row 3 ~ Business Rules from an SBVR and an xUML Perspective (Part 3)
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 statenormal
then set attribute 'price per day
' to the value of the event parameterprice
. - If event '
phase-out car model
' occurs and the 'car model
' is in statenormal
and there are no 'booking rentals
' then delete that 'car model
'.
- If event '
- 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
'.
- If no '
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 leastmileage
. - The permission part of the rule is represented by a guard on the transition leaving
the state
defined
of the business objectrental
(see state diagram below) and leading to its stateactive
: if there are some available cars of the booked 'car model
', the first of these is tied to thatrental
. 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:
- Business activities that are to be supported by an IT system will lead to use
cases of the IT system.
- Events become the interface between business objects and their environment (via
use cases) and are specified via black box sequence diagrams.
- Business activities that are to be automated will be specified by state diagrams
of business objects.
- Obligations to be automated will be represented as 'when' events in state diagrams
of business objects.
- Prohibitions to be automated will be represented as events that are only accepted
in certain states of business objects.
- 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).
# # #
About our Contributor:
Online Interactive Training Series
In response to a great many requests, Business Rule Solutions now offers at-a-distance learning options. No travel, no backlogs, no hassles. Same great instructors, but with schedules, content and pricing designed to meet the special needs of busy professionals.