The Coad Letter: Modeling and Design Edition, Issue 68, a New Beginning, by Stephen Palmer
Thank you for your kind interest in The Coad Letter. Some of you have been
active readers of this brief, frequent, and informative series of special
reports for many years now. I remain most grateful.
I am writing to share with you that I recently changed my career focus:
I am now spending 24/7 as the CEO of the startup TogetherSoft Corporation.
And I love it! The stories I could tell, the lessons learned, the joy of mentally
growing and stretching in every way possible! Business is great, we're hitting
new sales records each month--and we're profitable! Lovely.
I have really enjoyed writing The Coad Letter, sharing what I am learning
in practice with you: practical, down-to-earth, real insights from modeling
with teams around the globe. Yet now my career focus has changed, and so I
wish to ask someone I completely trust to continue in my stead.
Introducing the new lead editor of The Coad Letter: Steve Palmer. Steve
is the modeler and designer I have personally spent the *most* time with,
building models and facilitating teams together. He was there when we first
modeled in color. He was there when we first put "lessons learned from Fred"
(Coad Letter issue 44) into practice on a large-scale project. And his knowledge
of design and Java surpasses my own.
And so it is my privilege to introduce Steve as the new lead editor of
The Coad Letter. Other very talented ones on my team, called (I write this
sheepishly) Coad-certified Mentors (CCMs) will contribute. Steve takes the
Best wishes for success in all, including better modeling and design,
Welcome to this new series of The Coad Letter!
In 1997 Pete introduced the idea of adding color to object models (Coad Letter
44). Over the following two years, a number of subsequent Coad Letters built
on that theme (Coad Letters 51, 54, 58-65). Then last summer, Pete consolidated
the work in chapter one of the 'Java Modeling in Color with UML' book
published by Prentice Hall (chapter one can also be downloaded from
Using color-coded class archetypes has become our primary modeling technique
at TogetherSoft. However, drawing object models in ASCII is tedious and time
consuming; drawing color object models in ASCII is impossible. Also, TogetherSoft's
tool, Together, supports modeling in color with UML very well and it seems
a little silly not to use it. Therefore, making the most of this transition
phase, I'm going to start publishing the Coad Letter in HTML format instead
of plain ASCII text.
Also over the next few months, I hope to introduce you to some of the other
Coad-Certified Mentors in the TogetherSoft family and let them share with
you insights from their varied backgrounds and experience.
Now finally to this issue...
In this issue, we apply Pete's Domain Neutral Component to a simple but
typical modeling example. I recently worked with a group that was struggling
a little with applying the Domain Neutral Component to their object model.
This example helped clarify some of the design trade offs involved. First,
a bit of background for any that are new to modeling in color and the Domain
Quick Review of Color and Class Archetypes
When modeling, we look for four categories of Problem Domain (PD)
class, the four class archetypes:
- Moment/Interval (MI) (Pink) - a moment or interval
in time that must be tracked for business or legal reasons.
- Role (Yellow) - a role played by someone, something,
or some place, a way of participating.
- Party,Place,Thing (PPT) (Green) - a role player,
a uniquely identifiable entity.
- Description (Desc) (Blue) - a catalog-like entry,
a set of values that apply again and again.
The archetypes suggest typical attributes and methods for their classes.
The archetypes also suggest typical interactions between classes of different
The Domain Neutral Component (DNC) is a pattern of archetypes that
occurs again and again within PD object models of business systems.
It look as follows:
Modeling Account Membership at a Simple Video Rental Business
Let's have a go at modeling account membership at a simple video rental business.
We'll start by replacing the archetypes in the DNC with names from our problem
domain. The event or activity we want to track is a person applying
for a membership account. So lets replace the MomentInterval class with a
class called AccountApplication.
The DNC consists of three similar-looking legs connected to the
MI classes; the Party leg, the Place leg and the Thing leg. Attacking the
Party leg first - the role being played by a party in the AccountApplication
is that of a membership holder (potential and/or confirmed). So we replace
the PartyRole class with a class called Member. We'll restrict ourselves to
renting to people (and not include organisations) so we replace the Party
class with Person. Similarly the PartyDescription class becomes PersonDesc;
we could use this class to handle people of different age groups and store
the video ratings that an age group may legally rent, for example.
The Thing leg is next. The membership account is the thing for which we
are applying, We, therefore, replace Thing with Account. ThingDescription
becomes AccountDesc; we can use this to provide default values for different
types of account (maximum number of tapes rentable at any one time for example).
The ThingRole class? Any attributes and behavior specific to the way an Account
participates in the AccountApplication can be placed here so we'll call it
Lastly the Place leg. People apply for accounts at a video store. We can
model this as some type of building or Property (high rise/low rise, commercial/residential,
etc.) playing the role of a video store.
The result is a very powerful, flexible model shape in no time at all.
Notice we have lost the MI-Detail class because we did not identify any parts
to our account application process. Conceivably we could allow a person to
apply for multiple accounts at the same time and that would require a suitable
MI-Detail class but this capability would not be useful in our video rental
domain. Another side-effect of this decision to support only one account
per person is the narrowing from 0..* to 1 in cardinality between the AccountApplication
class and the AccountInApplication class.
Much of the flexibility provided by our model is obviously overkill for
a simple video rental business. Therefore, lets see what other classes we
can drop out along the legs where we do not need the extra flexibility.
The rather contrived name of AccountInApplication is a clue. If there is
little or no behavior and/or attributes specific to an Account while it participates
in the application process we can drop the AccountInApplication role class.
If the difference in account types is very small and AccountDesc only has
a handful of methods we can also drop the AccountDesc class and represent
the type as a simple attribute (probably enumerated) in the Account class,
plus a handful of static methods (for example, listNewAccounts()).
(Note: static methods would not work in most distributed object frameworks
because they do not support remote invocation of static methods.).
It does not make sense to allow video store members to close and reopen
membership accounts unless members are charged regular subscription fees.
This is not usually the case for a simple video rental business; membership
is normally for life. Therefore we can replace the other 0..* cardinality
between AccountApplication and Account with 1.
The result is:
For a small video rental business, the store at which you apply for membership
is of no relevance; indeed the business may only operate one store or may
be operated via the web. In this case the whole Place leg can be dropped.
If the store is relevant (for example, in the case of a video store chain),
we can again challenge the need for a separate role class and the need for
a separate description class in addition to the Property class ( maybe just
a green Place class.would be good enough).For the purposes of this example,
let's assume we do not need the store at all. Now our model looks as follows:
Lets review the Party leg of the model. Again if the PersonDesc does not
add much value to our model we can fold it into a simple attribute and maybe
a static method or two in the Person class. Do we need the Member role? Party
roles are far more common than Thing roles and Place roles. We'll probably
need some other party roles at some point (Cashier springs to mind) so it's
safer to keep the Member role for now. Role classes have attributes and operations
that are specific to the roleplayer's participation in that role. Typical
attributes are an ID or a status and typical operations for a Member role
class could include: assessAccountArrears(), listFavoriteGenre(), listRentalHistory().
We still allow a Member to make multiple applications. We have already
decided that membership is for life so a member will only ever have one successful
AccountApplication that we need to keep around at any one time. Keeping record
of previous failed AccountApplications does not seem important enough to
warrant the complexity of a 0..* relationship between Member and AccountApplication;
let's reduce that to a 1.
The 1-1 association between AccountApplication and Account suggest we can
collapse AccountApplication and Account into one class. It is really the
account that we are interested in; we have reduced the application process
until it is trivial. At most, we might keep a dateApplied attribute and a
dateApproved attribute so that we could ask the Account class its status.
Let's see what we have left:
We now have another 1-1 association between Member and Account. Let's merge
the Account into Member. Why keep Member and not Account - after all, in
the end it is little more than a choice of name and color for a class? Choosing
Person and Member leaves us with a roleplayer class and a related role class.
Remember the DNC is a pattern that occurs again and again in business systems.
Person and Member fit the DNC better than Person and Account; it helps us
plug Member into other MomentIntervals (Rental for example).
In some cases we may be uninterested in the actual role player or the roleplayer
may only ever play one role. If this were the case we would end up with single
role class, Member, representing account membership.
We started with ten classes and have ended up with one class. Ok, so this
example is a little artificial but I hope it has demonstrated some of the
subtle power of the Domain Neutral Component and illustrated some of the
design trade offs between flexibility and simplicity. Obviously our start
and end points represent two extremes; the object model we want is the simplest
that does the job and no simpler. Color modeling and the DNC are great techniques
we can use to make our work easier but they are certainly not a silver bullet
or an excuse to disengage our brains.
ps. any feedback by email on the content, new format, suggestions for improvements
etc is very welcome