I think the stuff from yesterday's post kind of sucked. Sorry about that. It seems that my perishable skill of writing nears six feet under. I’ll endeavor to make today’s post more lucid, cohesive, and informative. Perhaps that will revive my chosen word.

I told my nascent development team that we would use modeling with color as our object-oriented design philosophy. Then, I reserved a conference room for four mornings so we could learn this practice first hand. I started by showing them the following list of user stories.

• People join the club to become members and get invoiced monthly a flat fee and participation fees for classes
• Participation fees for classes consist of a prorated amount of the instructor’s hourly rate and a percentage of the cost of the equipment used by participants in the class
• Record member purchases of food and beverages from the club for rewards
• For every ten dollars spent on food and beverages from the club, the member receives a one dollar credit on their next invoice.
• Members RSVP for classes and their arrival is recorded
• Instructors schedule rooms and equipment for classes

Then, I asked them to break out in groups and create some static class diagrams that model the problem. From three groups, we had four designs emerge. They all looked like candidates for creating software to address the user stories. However, they all looked different. They all lacked some transactional information. Nothing wonky, mind you. Nobody forgot to include a Person class. But, this project that we’ve launched will grow in number tenfold over the next year; I want the code to look and feel the same regardless of who wrote it and when they wrote it. Modeling in color to the resuce!

Let’s apply modeling in color to those user stories found above.

Colors and the Domain-Neutral Component

Recall that we have the following archetypes for classes in our domain model.

Archetype	Color	Purpose
Moment-Interval	Pink	Describes a moment in or interval of time that the application should track for business or legal reasons.
Moment-Interval Detail	Pink	Describes a detail of a «moment-interval».
Thing	Green	A party (person or organization), place, or, well..., thing.
Role	Yellow	A specific kind of behavior taken on by a «thing» to allow it to create or participate in the creation of «moment-interval»s.
Description	Blue	A prototype for one or more «thing»s.

Using those four archetypes, Peter Coad, Jeff de Luca, and Eric Lefebvre formalized a standard relationship for classes that fulfill these archetypes. They dubbed that formalization the Domain-Neutral Component (DNC) because they posited that, regardless of the problem domain, the DNC provides an adequate structure to express the associations, behavior, and data needed. That structure looks like this.

The «plug-in points» allow you to provide different strategies at different levels in the component.

Modeling with the DNC means identifying the «moment-interval» of interest, then the participating «thing» in that transaction, then any «role»s those «thing»s expose, then any «description»s that contain prototype-level attributes or behavior.

In some cases, you will have classes that will fill all of the reserved blocks in the DNC. In other cases, you may find that you have only two. The relevant point to glean from this: start with the DNC and take away superfluous boxes until you have reached what you need. Take away the things you don’t need. Don’t suffer from blank-page syndrome.

You should never have a DNC that does not contain a «moment-interval».

Quoting Eric S. Raymond in The New Hacker’s Dictionary, we find similar advice from a pretty cool guy:

The French aviator, adventurer and author Antoine de Saint-Exupéry, probably best known for his classic children’s book The Little Prince, was also an aircraft designer. He gave us perhaps the best definition of engineering elegance when he said “A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.”

Starting to model with color

Those user stories at the top of this page describe some of the functionality for software to administer an athletic club. We can do our usual “list of nouns” that starts most object-oriented design sessions and come up with the following nouns at first blush.

• member
• instructor
• class
• invoice
• equipment
• reward
• member purchase
• reservation
• member arrival
• membership
• person
• room
• payment

That may not consist of all of the nouns implied by the user stories, but I think it represents a good start. Now, we should classify each of the nouns as one of the four archetypes.

Moment-Interval Moment-Interval Detail	Role	Thing	Description
class invoice reward member purchase reservation member arrival membership payment	member instructor	person room equipment

We’ll start tomorrow with that first column containing the «moment-interval»s and laying out their flow from one to another. In that way, we can model the flow of information through the business processes and the features that they represent. Then, we’ll fill out DNCs for each of the «moment-interval»s to complete the design portion of the classes for the athletic club software.