1  Introduction

During the past few years, KnowGravity has been involved in research on the Business Rules Approach (BRA) as well as in the Unified Modeling Language (UML) and the Model Driven Architecture (MDA) of the Object Management Group (OMG).  In this context we developed an environment, based on our CASSANDRA platform, for creating executable UML models (also called xUML models).  The primary goal of CASSANDRA/xUML is to offer a platform for executable specifications that are as technology-independent as possible.  In other words, CASSANDRA/xUML models are typically Platform Independent Models (PIMs), or Zachman Row 3 models.

In contrast to other approaches to xUML in the OMG, with CASSANDRA/xUML we do not try to define a small subset of UML that may be made executable; rather we try to make the full semantics of the UML executable.  With the Business Rules Approach in mind we try to push the boundaries even further. to and beyond the limits of UML.  During the past two years we have added more rules-oriented features (or rules-oriented interpretations of existing features in UML) to CASSANDRA/xUML.  Today, CASSANDRA/xUML supports derivation rules as well as constraints and process rules.  Furthermore, we use a variant of UML's OCL (Object Constraint Language) that uses a more business-oriented syntax than the original UML2 OCL.

In this series of articles, I will contrast business rules stated in a business-oriented language as described by the OMG specification "Semantics of Business Vocabulary and Business Rules" (SBVR) with business rules stated in a more IT-oriented form and expressed in our interpretation of xUML.  Furthermore, I will show how another new OMG specification, the "Business Process Modeling Notation" (BPMN), can be mapped to xUML.  SBVR as well as BPMN (to a certain degree) are languages intended to express Zachman Row 2 models, and I will show how these models contrast with the Zachman Row 3 models of xUML.  As an illustrative example, I will use "Micro EU-Rent," a simplified version of the well-known car rental case study "EU-Rent."

The remainder of this article is structured as follows:  Section 2 is a general introduction, where I will briefly introduce what business rules are, as seen from the business perspective (Zachman row 2, represented using SBVR), as well as seen from the IT perspective (Zachman row 3, represented using xUML).  Based on these perspectives, in section 3, I will discuss how an SBVR business vocabulary relates to a business object model in xUML. In future instalments, I will discuss the following topics:

• How derivation rules are represented in SBVR as well as in xUML
• How process rules are based on BPMN and represented in SBVR as well as in xUML
• How constraints are represented in SBVR as well as in xUML
• Some advanced topics such as polymorphic and dynamic rule sets.

2  Business Rules

Business rules may be viewed from the business perspective as well as from an IT perspective.

2.1    Business Rules from the Business Perspective

The Business Rules Group defines a business rule from a business perspective as "guidance that there is an obligation concerning conduct, action, practice, or procedure within a particular activity or sphere."  The primary subject of this guidance is the set of business processes performed by humans and potentially (partially) supported or automated by IT systems.  From a business perspective, business rules ought to have a motivation and may be subject to enforcement.  SBVR basically distinguishes two different categories of business rules, as follows:

• Structural Business Rules specify necessities on business concepts, i.e., they are "true by definition" and thus represent a form of definitions or conventions.^[1]  As an example, a rule that specifies how the total price of a rental is calculated is a structural business rule.
  
  
• Operative Business Rules specify business obligations, i.e., they exist in order to produce (or avoid) some effect in the business.  Operative business rules may be violated and thus are usually enforced by some means.  As an example, a rule stating that "blacklisted customers must not be given a rental" is an operative business rule.

Business rules used in this way describe the business, so they are part of row 2 ("Enterprise Model") of the Zachman Framework.  According to SBVR, business rules from a business perspective are based on noun concepts (also called object types) and verb concepts (also called fact types) formalized in a vocabulary.  Such a vocabulary defines the semantics about these concepts as well as providing community-specific terms for those concepts.

2.2    Business Rules from the IT Perspective

The Business Rules Group defines a business rule from an IT perspective as "a statement that defines or constrains some aspect of the business.  It is intended to assert business structure, or to control or influence the behavior of the business."  There exist multiple classification schemes for business rules from the IT perspective.  I will use the following simple scheme of three categories:

• Derivation rules specify how some information is derived when some other information is given.  As an example, derivation rules may define how much of a discount a particular rental gets.
  
  
• Process rules are rules that affect processes, i.e., they trigger, permit, or prohibit some activities.  As an example, a process rule may prohibit a rental from being given to a blacklisted renter.
  
  
• Constraints are propositions that must always hold.  As an example, a constraint might state that the sum of the total price of all open rentals of a renter may never exceed the renter's credit limit.

Business rules used in this way describe IT systems that will support a business, so they are part of row 3 ("Systems Model") of the Zachman Framework.  In general, only some of the rules stated at row 2 will also be part of row 3 -- exactly those rules that are subject to automation by an IT system.^[2]  For those rules that are 'transferred' to row 3, the following heuristics can be applied:

• Structural business rules will be turned into derivation rules.
  
  
• Operative business rules will either be turned into process rules or into constraints.

From an IT perspective, business rules are usually based on some form of business objects, represented in a Business Object Model (BOM).  Such a BOM serves as an intermediary between technical artifacts, such as database tables, classes, Enterprise Java Beans, etc., and the 'user compatible' names for them and their properties (mainly attributes and associations) that will be used to express rules.

3    Defining a Vocabulary

3.1    Business Perspective in SBVR

In SBVR, a vocabulary is a representation of a so-called 'body of shared concepts'.  The following fact diagram uses SBVR-UML to represent an initial vocabulary for Micro EU-Rent.  This vocabulary introduces noun concepts (such as 'renter') and verb concepts (such as 'is signed by').  It builds on an existing vocabulary named 'Core Concepts' that, besides other things, provides highly-reusable concepts that involve numbers.  The terms used to name these concepts are those used by the community 'UK EU-Rent Employees'.

Other communities may use different terms to represent the same concepts.  The following diagram shows the same 'body of shared concepts' from the perspective of the 'Swiss EU-Rent Employees' community:

In a proper SBVR vocabulary, the exact meaning of each concept introduced above needs to be defined.  Often, additional properties -- such as synonyms, the source of a definition, the owner of a definition, etc. -- are provided as well.  An SBVR vocabulary usually also provides some structural business rules on the concepts it introduces, for example:

Rule R1:

It is necessary that each rental uses at most one car.

Rule R2:

It is necessary that each rental is signed by exactly one renter.

Rule R3:

It is necessary that each rental books exactly one car model.

The syntax used to express the rules above is SBVR Structured English (SBVR-SE).  The color scheme in these expressions reflects the kinds of vocabulary words used:  noun concept, verb concept, and SBVR-SE keyword.

If the same rules are seen by the community 'Swiss EU-Rent Employees', they would look like this (in SBVR Structured German):

Rule R1:

Es ist notwendig, dass jede Miete verwendet höchstens ein Fahrzeug.

Rule R2:

Es ist notwendig, dass jede Miete signiert durch genau einen Mieter.

Rule R3:

Es ist notwendig, dass jede Miete bucht genau einen Fahrzeugtyp.

These few examples of rules clearly illustrate how an SBVR vocabulary serves as a basis for expressing rules.  And, if the vocabularies of various communities represent a common set of shared concepts, the very same rules can automatically be represented by expressions using the terms known to the corresponding communities.

3.2    IT-Perspective in xUML

One of the first things to do when moving from Zachman row 2 to Zachman row 3 is to define the requirements for the required IT system(s).  With respect to vocabulary, this primarily means that we need to define which of the concepts from the vocabulary shall be represented in the IT system.  For Micro EU-Rent, this could appear as follows:

Id	Priority	Type	Description
Rq1	H	Functional	Information about renters and rentals shall be maintained in the IT system.
Rq2	H	Functional	Information about cars and car models shall be maintained in the IT system.
Rq3	H	Functional	Information about prices shall be maintained in the IT system.

The following xUML class diagram represents an initial Business Object Model (BOM) for Micro EU-Rent.  In contrast to the vocabulary above, it shows named attributes^[3] as well as associations with role names.

Compared to an SBVR vocabulary, an xUML BOM usually also reflects cardinalities on associations.  These form a kind of rule:  the '1' end represents a constraint on how many instances of one class may be associated with an instance of another class.  The three structural business rules R1, R2, and R3 introduced in the business perspective above are now enforced by the cardinality constraints in the xUML BOM.

In contrast to the fact-based approach of SBVR, in xUML associations are always named by role names.  Although role names are supported in SBVR as well, fact types are typically named by phrases involving a number of concepts.  For example, the fact type 'rental books car model' in SBVR is represented by the association role 'booked model' in xUML.  In SBVR, fact types often have alternative readings, which are represented by other roles in xUML:  the association role 'booking rentals' in xUML is a representation of the alternative fact type reading 'car model is booked by rental' in SBVR.  However, in xUML a role is stated in the plural if the corresponding cardinality is 'many'.

Also shown in the BOM above is something not often used in 'classical UML':  a number of derived attributes (prefixed by a slash '/').  These attributes will be the logical 'hooks' for specifying derivation rules.  (More on this later.)

The process of transforming an SBVR vocabulary into an xUML BOM can be described by the following set of mapping rules:

1. Noun concepts are transformed into business objects represented as classes.
   
   
2. Value types (such as numbers) are transformed into basic types (boolean, number, text, etc.).
   
   
3. Unary fact types (also called 'characteristics' in SBVR) are transformed into boolean attributes of the owning business objects.
   
   
4. Binary fact types are transformed into either:
   
   
   • attributes of a basic type, if one of the roles is an object type and the other is a value type, or
     
     
   • associations between two business objects, if both roles are object types.
     
     
5. Fact types of higher arity are currently not supported by xUML.
   
   
6. Object types that need to be referenced by a business user need an attribute 'id' in their corresponding business object.

Next Time ...

In the next instalment, I will discuss how derivation rules are represented in SBVR as well as in xUML.  Then, I will discuss how process rules are based on BPMN and can be represented in SBVR as well as in xUML.  After that, I will discuss how constraints are represented in SBVR as well as in xUML.  I will conclude with a discussion of some advanced topics such as polymorphic and dynamic rule sets.

Notes

[1]  At the time of writing, there is still some discussion among the SBVR authors on the relationship between structural business rules and definitions.  This article reflects the personal view of the author.  

[2]  We restrict here row 3 (and below) of the Zachman Framework to IT systems.  However, in general, elements from row 2 that are not implemented by IT systems often need to be mapped to solutions involving people.  

[3]  The attributes called 'id' are a special feature of CASSANDRA/xUML that provides automatic support for 'meaningful' unique identifiers of instances; they have no special relevance here.  

# # #