In-Depth

Merging data and object models with business rules

• By Ellen Gottesdiener
• July 25, 2001

Since objects are responsible for their own data and behavior, business rules in most object-oriented methodologies are implied; they are not distinct classes. Business rule enforcement in an object-oriented application often requires collaborating objects which know what objects to interact with to satisfy a rule.

Can data models, object models and business rules come together? Consider the emerging IDEF1X97 standard. IDEF1X is a data modeling standard used by federal agencies. Extensions to IDEF1X97 in development include class/object modeling standards. "We have the concept that an object (an instance of a class) 'has knowledge, exhibits behavior, and obeys rules,'" said Keri Anderson Healy, a senior consultant at Model Systems Consultants Inc., Bainbridge Island, Wash., a technical editor of the IDEF1X97 standard. "There is not a separate step for listings rules in the form of constraints. They will evolve during modeling sessions," said Tom Bruce, chair of the standards committee.

Properties of objects/classes include attributes, operations, participant properties (arising from relationships to other classes/objects) and constraints. "Some constraints (such as uniqueness constraints) are so prevalent that there is a graphic way to declare them. Most constraints, however, are unique to a particular model. These constraints are named and specified as a property of some object (class)," said Anderson Healy.

The business rule defined by an object's constraint is not independent. It may need to collaborate with other objects. This could result in complex communications amongst objects. "The realization of the constraint may require the collaboration of several objects, possibly of differing classes," pointed out Anderson Healy.

The emerging IDEF1X97 object model subsumes many business rules within the modeling constructs. Many business rules are implied as part of the graphical notation. A business rule might be a property of a class or be implied in an aspect of the model's structure.

With an object-oriented paradigm, there are other ways to incorporate a business rule approach, such as making each rule an object, which would likely yield significant performance problems. Another approach is to design artificial objects such as "Service" or "Policy" objects which are responsible for enforcing business rules.

Should business rules be independent constructs in object-orientation? The question may be moot since there are no independent constructs except objects. All behaviors and attributes -- responsibilities -- are encapsulated in a class/object. "I think that many object 'modeling' techniques do reflect the notion of 'rule' in some fashion. In a (conceptual) object model, I find that the prevailing debate is not so much whether 'rule' can be represented. Rather, the debate is whether a 'rule' should be represented as an independent (free-floating) construct or whether 'rule' has to 'belong' to some other (business) object/class," said Anderson Healy. "In many object languages, anything that appears to be 'free-floating' is ultimately attached to the application (itself an object) -- so nothing is really free-floating."

Dan Tasker, of Air New Zealand, believes business rules and objects should be "free-floating in the same way that entities are free-floating. There should be instances of business rules which are managed and associated (mapped) to other appropriate things, like entities and operations. These instances of business rules have properties of their own, for example who is the owner."

Some experts are doubtful that objects provide an answer. "Objects are fine for non-persistent things, like GUIs and service providers, but anything that has to do with knowledge and persistence, objects are not the right answer. Business rules are the Achilles' heel of object orientation for business database applications," asserted Ron Ross, an author and business rules expert.