Recently, Ron Ross invited me to author a regular column on modeling issues for the Business Rules Journal.  Ron’s invitation was both very welcome and timely, as information systems modeling has been an intellectual passion of mine for twenty odd years, and I had just moved back to an academic position that enabled me to spend more time on such writing activities.  Moreover, modeling is finally being recognized as an essential phase of information systems development by a significant and growing number of practitioners, and the expectations are that modeling will become main stream within the next few years.

In this first article, I’d like to simply lay the scene for future articles in this column.  While the general topic addressed is information systems modeling, special emphasis will be placed on conceptual modeling, especially conceptual modeling of business rules.  I use the term “conceptual model” to mean a complete, detailed model of the application domain or business, expressed naturally in concepts and language easily understood by the business users.

Back in the 1980s, my doctoral thesis formalized a conceptual modeling approach now commonly known as Object-Role Modeling (ORM).  Although other approaches such as Entity-Relationship (ER) modeling and the Unified Modeling Language (UML) are valuable for specific tasks, I believe that ORM eats them for breakfast when it comes to conceptual data modeling.  I’ll attempt to justify this claim in some later articles, and you are of course welcome to disagree and let me know how unfair you believe my arguments to be.  The more debate we have on the issues, the more fun the column will be.

One of several aspects of ORM that distinguishes it from ER and UML is the richness of ORM’s graphical and textual languages for expressing constraints.  A constraint is a business rule that restricts how the conceptual schema (model structure) may be instantiated (populated with instances), or may change its state.  A static constraint applies to each state of the information system, taken individually.  For example, if we exclude reincarnation from our application domain, we might assert the following constraint:  each Person was born on at most one Date.  In contrast, a dynamic constraint involves at least two different states.  For example, in an ideal world we might have a rule that a person’s salary must never decrease.  ORM is arguably the best approach for expressing static constraints, but it needs some more work to adequately deal with dynamic constraints.

Another kind of business rule is a derivation rule, showing how some facts can be derived from other facts.  For example, if Person1 is a parent of Person2, and Person1 is male, then we may derive the fact that Person1 is the father of Person2.  There are different kinds of derivation rule.  For example, if-rules are weaker than if-and-only-if rules, and we'll look at examples of these in later articles.

Although much of the modeling discussion will focus on ORM, other approaches such as ER and UML will also be mentioned, and most of the issues raised in terms of ORM are relevant for the other approaches too.  Some modeling concepts and issues we’ll address in later articles include the following:

• What is the best way to express business rules using a textual language?
  
  
• What is the best way to express business rules using a graphical language?
  
  
• How are business rules best discovered?
  
  
• How are business rules best validated?
  
  
• Why doesn’t UML cut it for business rules?
  
  
• What is a good metamodel for information models, including business rules?
  
  
• What are good ways to deal with the impact of temporal aspects on information models?
  
  
• What are good ways to deal with various tricky problems that arise in real world modeling?

These are just some of the things that will be discussed in upcoming articles.  If there are some other topics you’d like addressed, please let me know and I’ll do what I can to include them.

Hoping you'll tune in to this column in later issues.

~ Terry

# # #