Terry Moriarty
Adapting object-oriented concepts to business rule analysis
Borrowing from OOMay, 1998
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, OO
class diagrams, and scenarios.
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).
Table 1. Example concept catalog. |
||
| Concept | Description | Questions |
|---|---|---|
| Customer | A person or organization who purchases or uses our products or services, who has purchased or used our products and services in the past, or who we want to purchase our products and services. | Do we really consider the people/ organizations who use our products and services to be our customers, or are only those who actually do the purchasing our customers? |
| Household | People who live at the same address who have the same surname whom we want to treat as a unit for marketing purposes. | Is the household a
"customer"? Are all the people in a target household considered customers? Are businesses run from home offices considered to be part of the household? What if people with different last names live in the same house? Are they part of the same household? Are we interested in households for any reasons other than marketing? |
| Head of Household | The person in the household who is considered to be the primary decision maker. | What sorts of decisions does this person make? In what products may the household be interested? Can there be more than one head of household per household? What if we don't know which person is the head of household? Do we guess? |
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 (OMT) notation, I quickly converted to this
modeling style. OMT, 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 OMT 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 OMT, 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," object-class models 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 OMT 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 OMT 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
Next month, we'll explore how scenarios, another analysis approach that has been popularized by OO, can be applied to business rule analysis.
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.
Terry Moriarty, president of Inastrol, a San Francisco-based information
management consultancy, specializes in customer relationship information and metadata
management. Her common business models have been used as the basis of customer models for
companies within the financial services, telecommunication, software/hardware technology
manufacturing, and retail consumer product industries. You can reach her at terry@inastrol.com