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 lead.

Best wishes for success in all, including better modeling and design,

Peter Coad

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 www.togethersoft.com).

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 Neutral Component...

Quick Review of Color and Class Archetypes

When modeling, we look for four categories of Problem Domain (PD) class, the four class archetypes:

1. Moment/Interval (MI) (Pink) - a moment or interval in time that must be tracked for business or legal reasons.
2. Role (Yellow) - a role played by someone, something, or some place, a way of participating.
3. Party,Place,Thing (PPT) (Green) - a role player, a uniquely identifiable entity.
4. 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 archetypes.
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 AccountInApplication.

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.

Have fun

Stephen Palmer

ps. any feedback by email on the content, new format, suggestions for improvements etc is very welcome