Object-Oriented Business Rules
An excerpt from Chapter 4 of Streamlined Object Modeling...
Business rules are the heart of any domain. Without their constraining force,
business processes may be initiated by the wrong people, at the wrong times
and places, and with things improperly selected or illegally defined. Running
business processes with illegal information not only corrupts system integrity,
but also induces egregious real-world effects.
Business rules prevent illegal product sales to underage consumers and overseas
customers; business rules prevent movement by an elevator with open doors; business
rules define who can respond to a request-for-quotation and enforce the deadline
for quotes; and business rules determine which house of the U. S. Congress can
initiate an appropriations bill or approve a treaty.
Because business rules are so crucial to the success and goals of a business
domain, it cannot be considered properly or completely modeled until its business
rules are specified. Capturing and specifying business rules is an analysis
activity.
An ideal modeling methodology seamlessly integrates the business rules with
the model, enabling them to be defined at the same time, and in the same vocabulary;
integration simplifies and eases the process of keeping the rules and model
in sync as one or the other evolves.
Our modeling methodology achieves this integration by decomposing all business
domains into pairs of collaborating objects, (called collaboration patterns)
and transforming all business rules into tests between collaborating objects.
These tests are called collaboration rules, and how to describe business rules
as collaboration rules is the theme of the following.
Business Rules and Collaborations
Most business rules involve restrictions on which people can participate,
what events can occur, where events can occur, what things can be involved,
and how those things can be described, grouped, classified, and assembled.
These relationships between people, places, things, and events are modeled
by the 12 collaboration patterns [listed in Chapter Three of the book] ; thus,
a business domain modeled with collaboration patterns can easily express its
business rules in terms of collaborating objects.
Example:
Business rules determine whether a product (specific item) can be added to
an order (transaction), whether an elevator (specific item) can accept a request
(transaction) to go to another floor, whether a bidder (role) can bid (follow-up
transaction) on a request-for-quotation (transaction), and whether a bill (specific
item) can be submitted (transaction) for the calendar (place) of a particular
house of the U. S. Congress.
Collaboration Rules
Collaboration rules test whether two objects can create a new collaboration
or dissolve their existing one; in more technical terms, collaboration rules
establish preconditions for setting or removing an object connection.
Because these rules often run in response to user actions, a common mistake
is to give the human user interface responsibility for checking them. This is
a bad move. If business rules are not in the business objects, every redesign
and enhancement of the user interface puts them in jeopardy. Business rules
lost in a user interface are not easily extracted and ported to other platforms
and other technologies. Business rules kept in the business objects live on,
through all manner of user interfaces, platforms, and new technologies.
Updating business rules is also considerably easier when they live in the
objects they govern; it is easy to find them, and to keep them in sync with
changes in the objects they affect. Objects are responsible for their own welfare
and should not be governed by outside forces.
Collaboration rules do not run when an object and its collaborators are being
restored from a database, or a non-finalized collaboration is being rolled back,
which frequently happens with event collaborations. In the first case, objects
being restored from persistent storage are presumed to have already passed through
the business rules. In the second case, an event involves collaborations between
multiple objects-people, places, and things; if any one collaboration should
fail, then the event is not valid, and any previous collaborations established
with it must be dissolved-checking business rules would, therefore, simply be
gratuitous.
Transforming Business Rules into Collaboration Rules
Consistently transforming business rule constraints into collaboration rules
requires:
- deciding how to express the constraints, and
- deciding how to distribute the rule checking between the two collaborating
objects. Because collaboration rules involve two objects mutually deciding
whether to make or dissolve a collaboration with the other, the first requirement
boils down to deciding what information an object asks of itself and its potential
collaborator.
We believe that the following five categories handle all possible questions:
type, property, state, collaborator multiplicity, and collaborator conflicts.
These categories are discussed below.
The second requirement boils down to deciding which collaborator checks what
rules, and herein lays the power of collaboration patterns. Because collaboration
patterns represent real-world relationships, and each pattern player has a distinct
meaning, knowing the pattern involved determines what rules are likely and how
the work of checking them is to be distributed between the two pattern players.
Type Rules
Type rules limit the kinds of collaborators an object can have.
Think of them as zoning laws: they keep away the wrong types of objects (for
example, you can't put a business in a residential area). For simplicity, only
one collaborator needs to enforce the type rule: "If it is the wrong type for
me, then I am the wrong type for it." The simplest type rules can be depicted
on the object model diagram by looking at the connected objects; however, some
type rules are dynamic, relying on a derived type computed from the object's
state, properties, or collaborations.
Example:
A carton of perishable food can only be loaded into a refrigerated truck.
Type rules raise the possibility that a collaborator may need to be specialized
into one or more subclasses. Indeed, if the collaborator has different types
with clear differences in behaviors, properties, or collaborations, then the
analyst can include multiple specializations in the object model. Otherwise,
the specialization of types is left to design because it affects efficiency,
reuse, and optimization goals. Clearly written type rules assist and inform
the designer.
Multiplicity Rules
Multiplicity rules regulate the number of collaborators of an object, and usually
these rules are easily depicted on the object model diagram; however, an object
can have more dynamic rules determined by its properties.
Multiplicity rules come into play when an object tries to add or break a collaboration;
an object may refuse to add or break a collaboration if doing so would put it
above the maximum or below the minimum required for its existence.
Example:
A system for delivering online interactive educational lectures limits the
number of students that may enroll in each lecture. Different lectures may have
different limits depending on the material and lecturer.
Property Rules
Property rules come in two variations: validation and comparison.
A validation rule verifies a property value against a standard that is not
dependent on the properties of the other potential collaborator. The object
with the clearest access to the standard is the owner of the collaboration rule.
A comparison rule measures a property value of one object against one or more
of the property values of the other potential collaborator. Comparison rules
commonly occur in domains with age, residency, or security requirements. The
object with the properties defining the acceptable values owns the collaboration
rule. In both cases, property values evaluated can be either stored or calculated
data.
Example:
A customer cannot place an order if he lacks a valid name, billing address,
or credit card. A perishable food product cannot collaborate with a shipping
container whose average temperature is outside the product's minimum and maximum
temperature range.
State Rules
State rules specify the proper states an object needs to be in to begin or
end a collaboration.
Basically, a state rule asks the question: Am I ready? State rules are often
confused with property rules, but they differ in several ways. While validation
property rules check for legal property values, state rules check for "proper"
state; according to a state rule, an object in a legal state may still not be
in the proper state to make or break the collaboration. Also, state rules are
always internal and this distinguishes them from comparison property rules that
examine property values in both objects.
Example:
An order cannot be shipped if it has been canceled. An auction cannot accept
a new bid after the auction has expired.
Conflict Rules
Conflict rules define the conditions under which current collaborators protest
gaining a new collaborator or losing an existing one.
Conflict rules come in two varieties: collection and event rules.
Collection conflict rules occur when an object with a group of similar collaborators
polls the group for permission to add a new collaborator to the group or remove
an existing one.
Event conflict rules check for conflicts among the collaborators of an event;
they run when assigning people, places, or things to the event. Conflict
rules are themselves type, multiplicity, property, or state rules.
Example:
A flight arrival cannot be scheduled at a gate if it conflicts with the existing
flight arrivals for the gate. A product cannot be added to an order if it conflicts
with the order's customer, for example, the customer is underage for the product.
