Published in TDAN.com July 2001
As a business rule analyst, I’m always looking for better approaches to identify, document, communicate, and manage business rules. After supporting a number of projects that were
using object-oriented (OO) concepts, I found that some of these OO techniques adapt well to business rule analysis, including concept catalogs and OO class diagrams.
CONCEPT CATALOG
A concept catalog is a dictionary of terms that are important to the business domain being analyzed. So you say, what’s so new about that? Our data models have included this type of data
dictionary forever! I first encountered a concept catalog when I was working on an object-oriented project to develop an application whose persistence layer incorporated a relational database.
Consequently, the OO architects were forced to incorporate a relational model into their OO environment. As I perused the concept catalog with a data modeler’s eyes, I saw entities, relationships,
and attributes. I saw unanalyzed data that would eventually be redundant with the data that would reside in the data model’s data dictionary.
To say that I looked upon the company’s concept catalog unfavorably is an understatement. Classification is so fundamental to data analysts that we naturally start classifying any group of objects
we encounter. Until those objects are classified according to some scheme that brings order to what otherwise is a random collection of things, we see chaos. If no classification scheme exists,
then we invent one. This is probably why we have spent so much time over the last few years developing and refining business rule classification schemes. Our value to our organizations is our
ability to consume large amounts of business ramblings and transform them into an organized set of information structures that can be readily transformed into information systems.
But the concept catalog is for the business people; it is a repository where they capture their concepts in their terminology. As such, the concept catalog must remain neutral of any information
analysis approach. Information analysis classification schemes, both OO and information engineering, are specifically avoided at the requirement discovery stage of the project.
On the other hand, when I look at a concept catalog with a business rule analyst’s eyes, I find an extremely valuable business rule discovery tool. The concept catalog’s power is in its
neutrality–its lack of classification. After all, who benefits from the classifying we do during data analysis? If we are honest with ourselves, we know that the IT organization is the primary
beneficiary. Sure, enlightened business subject matter experts (SMEs) who participate in data modeling sessions will say that they gained valuable insight into their businesses. They may even
decide to change their business practices and business rules as a result. But business SMEs don’t care about our information classification schemes. Do they actually use the data model after the
sessions are completed? Have you ever taken an approved data model, years later, back to the SMEs who participated in its development? Were they still able to comprehend the diagram? Do they even
want to learn how to read a data model? Or are they forced to because we only offer the results of our analysis as a data model?
Consequently, as data modelers, we often ask how the business rule approach is different from our current data analysis approaches. The difference, while subtle, is significant. The main difference
between data modeling and business rule analysis are in the objectives of each approach and the mechanisms used to communicate the results of the analysis. When developing a data model, we analyze
the statements made by the SMEs, sometimes on the fly, and convert them into our frame of reference, an entity-relationship or object-class diagram. The classification of business rule statements
and transformation into a data model is the primary objective of this analysis process. On the other hand, the objective of the business rule approach is to identify, capture, and communicate our
understanding of the statements made by the SMEs about their businesses. The business rule analyst must be able to maintain the SMEs’ frames of reference using their vocabulary and whatever
documentation techniques required by the SME to facilitate their validation of the business rules. While data model diagrams are one of business rules analysts’ more powerful business rule
communication vehicles, some people do not relate well to business rules presented in this format. The business rule analyst must have an arsenal of alternate ways of presenting business rules to
those people. While the data model diagram is mandatory for deliverable data analysis, it is optional when analyzing business rules.
The concept catalog fits perfectly into the business rule analyst’s toolkit because it provides an environment for capturing the SMEs’ initial ramblings as they identify and define their business
terms and maintain questions about those definitions (see Table 1). Ideally, the catalog is supported by an application that is available to all SMEs and the various business rule, data, and object
analysts. Because the concept catalog is available outside the official analysis sessions, the SMEs can use it as a notepad to comment on existing concepts or record new ones for review in
subsequent sessions. A robust concept catalog is integrated into the enterprise’s business rule management environment. As business rule analysts review the concepts, they will convert the
statements into atomic business rules and classify them according to the organization’s business rule classification scheme. Once verified, the business rules can be cross-referenced to their
information technology counterparts (such as object classes, entities, and attributes).
A concept catalog should be a catalyst for discussion among the SMEs. Resolving the questions generated by the initial definition for each concept can have a profound impact on the future direction
of the business. Frequently, the business SMEs and visionaries only have a vague notion of what they mean by a term; the concept behind the term is not yet well formed. Furthermore, each
stakeholder may have a different impression of what the concept means. Consequently, during a business rule analysis session, we want focus on flushing out what the term means to the business.
Discussing whether “Head of Household” is an entity or an attribute will divert attention away from the primary concern: deciding what is meant by “head of household.”
OBJECT-CLASS DIAGRAMS
The data model diagram can be one of the best vehicles for communicating to the SMEs our understanding of their business rules. When the business rules asserted by the data model diagram are also
generated as textual statements, the data model is an even more powerful communication medium because you have the ability to present information in two formats, graphically and as text, while
guaranteeing these representations are in synch. Therefore, you can communicate with those individuals who relate well with diagrams while still being able to reinforce the diagrams with the text
preferred by some SMEs.
Unfortunately, the data model diagram notation can be used to represent only a subset of business rule types. Most data modeling methodologies do not provide specific notation to support many other
types of business rules that occur in the real world, such as attributes about relationships, multivalued attributes (attributes that can assume more than one value at a time), and derived
attributes. During business rule analysis, it is essential to represent the business rules as closely as possible to the way the business actually states them. When relational modeling constraints
are introduced too early in the business rule discovery process, we are at risk of obscuring important business knowledge.1 I have always felt constrained by the popular data modeling
methodologies. Once I was exposed to object-oriented class diagrams presented in object modeling technique (UML) notation, I quickly converted to this modeling style. UML, like most of its OO
modeling brethren (such as universal modeling language, or UML), has specific notation to represent more types of business rules than most data modeling methodologies.
The object-class model presented in Figure 1 illustrates some of the additional modeling notation provided by the UML methodology. The object class attached to the relationship line is a link
object class that represents attributes associated with the relationship. This object class contains a derivable attribute, balance. The slash before the attribute name indicates that it is
derivable. You can also use this notation to indicate a derivable object class or relationship. I’m using the term “relationship” to refer to the line between object classes, but in UML, the
interaction between object classes is known as an “association.” The statement enclosed in brackets represents a constraint imposed on the object class. Notation exists to represent many other
business rules, such as:
- Mutually exclusive and overlapping subtypes
- Class attributes (attributes that apply to the entire object class, as opposed to a specific object within the class)
- Multivalued attributes
- Aggregations in which one object class represents a specific collection of other object classes
N-ary associations, in which more than two object classes participate in the same association.
Data modelers often wish that object analysts would avoid these types of data structures because they can be problematic when the object model is subjected to data analysis. I’ve seen several
object-class models whose object classes and attributes have been optimized for the specific business events and processes being analyzed. After all, use cases, which have become the fundamental
component of object-oriented analysis, are very process specific. However, when object-class models are constructed by people who have the precision of thought that accompanies data analysis and
who believe in “one fact in one place,” an object-class model can be a powerful analysis and communication tool.
Object-oriented analysis methodologies weren’t the first to provide support for data structures that “violate” relational normalization rules. Semantic modeling has allowed these types of data
structures for years. In fact, Peter Chen’s paper introducing entity-relationship modeling concepts was based on the idea that the relational model was not appropriate for modeling the business
because of these restrictions.2 I believe that OO modeling methodologies such as UML are the first to provide notation for representing these types of business rules that is not overwhelming.
An added benefit of the object-class model is its ability to represent additional types of business rules that are object class or attribute specific. The UML constraint notation is an example of
this capability. There is a notion within the business rule community that a business rule “normalizes” to the object class that is primarily constrained by the business rule. Barbara von Halle
has done extensive research on approaches for extending the OO class model to support normalized business rules.3
References
- Moriarty, T. “Where’s the Business.” Database Programming & Design. May 1993.
- Chen, P. “The Entity-Relationship Model: Toward a Unified View of Data.” ACM Transactions on Database Systems, March 1976.
- von Halle, B. Business Rules and Object series, Database Programming & Design. April 1995-July 1996.
A slightly different version of this article was previously published in Database Programming & Design in May of 1998. Contact Terry for information regarding the Business Rules Forum later
this year.
