By: Coad Letter Modeling Editor
Abstract: In this issue, we look at the role of associations in color modeling.
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.
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.
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.
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
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
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
Server Response from: ETNASC01