In CoadLetter #68 we built some object models by starting with the Domain Neutral Component and replacing domain neutral names with specific names from our domain, removing anything we did not need along the way.

In this issue of the CoadLetter we look at another way of using the Domain Neutral Component to help build better object models. This time we use the DNC to review existing object models.

If you are not familiar modeling in color techniques, CoadLetter #68 has a brief introduction. You can also download the first chapter of the book, Java Modeling in Color with UML, from http://bdn.borland.com/article/images/29871/colormodeling1.pdf if you want more information.

Have fun

Steve

---

Comparing Object Models to the DNC

How can we use the Domain Neutral Component to help us refactor an existing object model? Maybe we have reverse-engineered an object model from an old system, inherited an object model from a previous project or simply been asked to review an object model.

Here are a few strategies we can use:

Strategy 2001-02-01: Color in an Object Model

Take four colored highlighter pens if working on paper or select the appropriate class archetype names in the stereotype property if using Together. For each class in the object model ask yourself these questions in the following order until you either answer yes or reach the end:

1. Does the class represent a moment or interval of time that we need to track for business or legal reasons?

  Yes - then color it pink, it belongs to the Moment-Interval class archetype
 
2. Does the class represent a role being played by a party (person or organization), place or thing?

  Yes - then color it yellow, it belongs to the Role class archetype
 
3. Does the class represent a catalog-entry like description?

  Yes - then color it blue, it belongs to the Description class archetype
 
4. Color the class green, it belongs to the Party/Place/Thing class archetype

Lets use the following simplified object model of flights and airports as an example.

Taking each class in turn:

Person:

• a moment or interval of time that we need to track for business of legal reasons? No
• a role played by a party, place or thing (a way of participating)? No
• a catalog-entry like description? No
• then its green and in this case it is a Party

• a moment or interval of time that we need to track for business of legal reasons? No
• a role played by a party, place or thing (a way of participating)? Yes, Pilot belongs to the Role archetype

• a moment or interval of time that we need to track for business of legal reasons? No
• a role played by a party, place or thing (a way of participating)? Yes, Passenger belongs to the Role archetype

• a moment or interval of time that we need to track for business of legal reasons? Yes, Flight belongs to the Moment-Interval archetype.

• a moment or interval of time that we need to track for business of legal reasons? Yes, SeatReservation belongs to the Moment-Interval archetype.

• a moment or interval of time that we need to track for business of legal reasons? No
• a role played by a party, place or thing (a way of participating)? No
• a catalog-entry like description? No
• then its green, Airport belongs in the Place archetype

The resulting model looks as follows:

Strategy 2001-02-02: Challenge Multi-Colored Inheritance

Challenge any subclasses that belong to a class archetype different to that of their superclass. Inheritance is an extension mechanism. An object of a sub-class is the same sort of thing as an object of the superclass. It is a nonsense to have a subclass belong to a different archetype than the class it extends.

Example

In our example, we have Pilot and Passenger as subclasses of Person but Person belongs to the Party archetype and Pilot and Passenger belong to the Role archetype. The difference in color on the two ends of the generalization link makes this problem very easy to spot. Comparing with the Domain Neutral Component we see that it suggests using composition instead of inheritance between classes of Party and Role archetypes.

Using composition when modeling Roles is much more flexible than using inheritance and avoids problems where a Person needs to play more than one role at the same time.

Strategy 2001-02-03: Look for Missing Place and Thing Roles

The Domain Neutral Component suggests that there may be a need for Role classes between Moment-Interval classes and Party/Place/Thing classes. Challenge associations from Moment-Interval (and Moment-Interval Detail) classes to Party/Place/Thing classes and ask if there should be a yellow between the pink and green.

Notes

If there is behavior specific to the way the Party/Place/Thing participates in the Moment-Interval then it may be useful to separate that behavior out into a Role class played by the Thing class.

Classes of the Party archetype nearly always play multiple different roles in a system. Place classes often do so too and Thing classes play different roles occasionally.

Things are normally created to serve one purpose and one purpose only. Therefore a Thing is most likely to only perform one role in any particular system; the role for which it was made. An additional Role class in this situation is usually unnecessary.

Where we are involved with the selling and manufacturing of a Thing, here a Thing may have different roles to separate its behavior in the manufacturing process from its behavior in the selling process.

Example

In our example we have Role classes between Person and the Moment-Interval classes. However, we do not have any Role classes between Airport and Flight.

Each Flight object is associated with two Airports objects; the departure airport and the arrival airport. Airport is playing two different Roles; it has a departure airport role and an arrival airport role. Let's add these two Roles and examine what behavior differences there are.

The Airport class has an assignRunway() operation. This presumably behaves differently depending on whether the flight is arriving or departing. You certainly do not want to be taking off from a runway when another plane is about to land on it. Let's split that operation into two and assign the parts to the relevant Role class instead - feels much safer. We can also move the countXOnTime() operations into the relevant Role class to give a better separation of behavior.

The result is:

 

Concluding Remarks

These three strategies give a glimpse into the ways in which we can use the Domain Neutral Component to improve existing object models.

If you discover a helpful color modeling strategy and would like to share it, please do drop me an e-mail ... or better still post a message on Together Community.