The Coad Letter: Modeling and Design Edition, Issue 71, From Associations to Domain Neutral Management, by Stephen Palmer
It's been a busy month traveling to three cities in three weeks to give
workshops. On the last of these I was accompanied by Karl Frank (email@example.com),
another of the Coad Certified Mentors at Togethersoft. During a rather
indifferent, evening meal at a 1950's style diner (Yes - it really did
look like something out of the old Happy Days television series), we discussed
the correlation between the role labels that may be specified on the end
of associations in UML and the yellow Role classes found in Pete's Domain
Neutral Component. The following short set of notes is the result. I hope
you enjoy them.
ps. see Coad Letter
#68 for an introduction to the Domain Neutral Component and class archetypes.
From Associations To Domain Neutral Component
Labeling UML Associations
Imagine two parties (persons or organizations) are related to each other.
We can represent this in an UML class diagram by connecting both ends of
an association to a Party class. We may label the association with the
name of the relationship. In addition, we may also label each end of the
association with the role played by the party in the relationship.
|A corresponding object diagram looks as follows - two objects of the
Party class with a link drawn between them.
1. A person and organization related by an employment relationship with
the organization playing the employer role and the person playing the employee
|2. Two parties related by a sale with one party playing the buyer role
and the other playing the seller role. In this case the relationship
is no more than a business transaction involving the two parties. (We could
view a ongoing business relationship as a set of interactions and/or
transactions between two parties.)
Using a Class to Represent a Relationship
Where there is more to a relationship than a simple name -- when there
are attributes and operations that are specific to that relationship --
we can add a class with those attributes and operations in between the
For a business relationship it is highly likely that we will need to
track the start and possibly the duration of the relationship so the new
class belongs to the Moment-Interval (pink) class archetype.
1. Attributes specific to an employment relationship include such things
as start date, salary and amount of paid leave. Operations might include
calculating the length of employment or calculating the amount of leave
left, for example.
2. The attributes you find in a Sale class include the cost, receipt
or invoice number and possibly the status of the sale. Operations may include
calculating discounts, tax, etc.
Using Classes for Roles
We can also apply the same reasoning to the role labels on the association.
Where there are attributes and operations that are applicable to the role
being played instead of the party or relationship then we can add a classes
to represent the party roles.
Now we have a generic class model shape that looks as follows - Party
connected to PartyRole connected to Moment-Interval.
Personal note: An object modeler named Marc Sewell first introduced
me to this object model shape. He called it the triad pattern; it was my
first encounter with a domain neutral pattern of any sort.
1. For employment we add an Employee role class and an Employer role class
to capture information specific to the role and provide operations that
can iterate over all the associated Employment objects. The Employer class
may include an employer's tax code attribute and an operation to pay employees.
The Employee role class could have an operation to total income across
multiple jobs and/or over a period of time like the tax year.
2. We can do the same for the sale model. If we also add classes for
the things being sold and the place where the transaction is happening,
we have Party connected to PartyRole connected to Moment-Interval connected
to both Place and Thing
Place and Thing Roles
Using similar reasoning, let's add PlaceRole and ThingRole classes to our
model. Place roles allow a property to play the role of a store and/or
a warehouse and/or a residence for example. Thing roles allow an aircraft
to play a military role and/or a civilian role for example.
Until now we have been considering situations where we need to track
both parties in a relationship or Moment-Interval. Now let's generalize
to allow for situations where the second party is not tracked (e.g. a typical
customer in grocery store). Now we have a Moment-Interval connected to
PartyRole, PlaceRole and ThingRole classes that are connected to Party,
Place and Thing respectively. The model is starting to take on a familiar
The Domain Neutral Component
If we compare the shape of the object model above with the Domain Neutral
Component there are only a few items missing. Add the blue description
classes for the Party, Place and Thing classes, a MomentIntervalDetail
to represent parts of a sale and we have all the classes in the Domain
We have seen that the core of the Domain Neutral Component can be derived
from a general association by replacing its label and roles with classes.
Knowing this it should be less of a surprise when we see the Domain Neutral
Component's pattern occurring again and again in our domain models. Of
course, the Domain Neutral Component and archetypes also provides us with
typical attributes, operations, interactions and interface plug-in points.
Coad, De Luca, Lefebrve, Java Modeling in Color with UML, Prentice Hall