Whole-Part Relationships in Color
Modeling
By David J. Anderson
Introduction
Peter Coad first introduced us to color modeling in The Coad Letter #44 back in 1997. Since then there have been many updates from Peter and later Stephen Palmer. However, Java Modeling in Color [Coad 1999] the book which formally introduced the topic left many questions unanswered. Since,
then some of these questions have been addressed in a number of Coad Letters.
One area which still remains unexplained is the use of Whole-Part relationships
in the Domain Neutral Component (DNC) [Figure 1]. The DNC had only one
Whole-Part relationship, the aggregation of <<MI-Detail>>s into
<<Moment-Interval>>s. However, practical color models do feature both composition and aggregation in other places and modelers are often left wondering, what is the "right way" to model these relationships and which colors should be used for the diagram. Does a pink class always aggregate a pink class? Does a green class always aggregate a green class? Is it the same
for blue classes? These are questions I get asked often when facilitating
modeling sessions. This article seeks to demystify aggregation and composition
in color modeling. It pools heavily from the lessons in Streamlined Object
Modeling [Nicola 2002].
Figure 1. The Domain Neutral Component (1999)
Conference Management
Now let us look at a real model example for a hotel &
conference management application, Figure 2.
Figure 2. Hotel
& Conference Management Model
What immediately strikes us about this model is the
whole-part relationships. A Hotel can have one or more rooms. If it didn't have
any rooms at all, by definition, it wouldn't be a hotel. A Conference can have
many Sessions and again by definition, if there weren't any sessions it wouldn't
be a conference. A Hotel can also have a description, for example, Sheraton, or
Hilton. The description includes a list of the hotel facilities and its
quality. The HotelDescription can in turn have RoomDescriptions which describe
the facilities for types of rooms available at that type of hotel.
What should also strike you about this model is that
color is inherited from the containing class. A green contains greens! A blue
contains blues! And, pink contains pinks!
Object Inheritance
There are two types of object inheritance at work in this
model. The first type works across the model from left to right. A Hotel
inherits behavior and default attributes from its HotelDescription, for
example, the brand and the class of the hotel and perhaps its rack rate
pricing. A ConferenceVenue inherits behavior and default attributes from its
Hotel, for example, the address and name of the venue. Similarly, the same left
to right object inheritance is at work on the lower row of the model. A Room
inherits some behavior and default attributes from its RoomDescription. A SessionVenue
inherits some behavior and its default attributes from its Room, for example,
occupancy limit which is may turn be inherited from the RoomDescription.
The second type of object inheritance on this diagram is
top to bottom. A RoomDescription may inherit attributes from its containing
parent, HotelDescription, for example, the class of the room or level of décor
may be inferred from the parent. A Room may inherit default behavior or
attributes from its containing parent, Hotel, for example, address, or
telephone number (without extension). A Session may inherit behavior or default
attributes from its containing parent, Conference, for example, the name of the
sponsor.
Resolving Color Differences
Consider the model in Figure 3 showing a Sale from a
typical retail environment and the Items the sale and the Item's catalog entry,
ItemDescription. Note that this is an aggregation relationship rather than a
composition relationship. In fact, there is strong argument that a simple
association would be the correct relationship. Item's can exist outside of a Sale.
Hence, composition is definitely inappropriate. Note also that the parent role
cardinality is shown as 0..* because an Item may be sold more than once. In a
domain such as vehicle retailing, the same vehicle may be sold several times
over its lifetime. For example, luxury brand retailers such as Mercedes or BMW
will often retail the same vehicle 3 or 4 times over a 10 year period. The
serial number did not change. It is still the same vehicle. Hence, the model
shown requires a zero to many relationship to the Sale object.
Figure 3. Retail Transaction Model (a)
In The Coad Letter #68 Stephen Palmer [2000] described
modeling with the Domain Neutral Component in a fashion which might best be
described as "the art of take-away" rather than the typical object modeling
approach of "add classes until complete". If we started with the DNC and
attempted to model a retail sale, then the model in Figure 4 would be much
closer to our result.
There are several things to note in this example.
Firstly, the aggregation under Sale has changed to a composition relationship.
A SaleItem <<MI-Detail>> would not exist without its containing Sale
<<Moment-Interval>> object and hence we have a pure containment
relationship which can be signified with the solid diamond in the object model.
We have also introduced the somewhat awkwardly named ItemInSale
<<Role>> class. What is this doing?
Roles separate out behavior for specific transaction
interaction from the original Person, Place or Thing class. This provides for
cleaner, simpler classes. It provides a more loosely coupled model and
facilitates re-use. For example, if we wanted to re-use the Item class in a
system for distribution or delivery then we do not have to carry the baggage of
the retail transaction code with us. That code has been delegated out into the ItemInSale
<<Role>> class.
It is a key lesson that the Domain Neutral Component is
a very loosely coupled architecture which facilitates distributed component
architecture. By using the modeling by take-away approach, you maximize the
chance of re-use and minimize the coupling of the model. Every time you take
away a colored class on the model, you are making a choice to limit flexibility
and increase coupling in the architecture. In exchange you have less classes on
your model. The Model in Figure 3 is not wrong but it is more tightly coupled
and this may create problems later which would require refactoring of code.
The use of color gives us a strong visual clue. The
model in Figure 3 looks different. It doesn't look like a DNC model because the
colors are in the wrong sequence. This is telling us that we have sacrificed
some flexibility and added some coupling to the architecture. It is then up to
our judgment to decide whether or not we should add back the other classes
which are missing to complete a DNC facsimile.
Figure 4. Retail Transaction Model (b)
Just Plain Wrong
There are some color combinations for whole-part
relationships which should set off a red flag for you. If you see either of the
combinations in Figure 5 then you probably have a problem with your model. Go
back and think about it a little harder.
Figure 5. Just Plain Wrong
Whole-Part <<Role>>s
You might be wondering why the model in Figure 2 does not
feature a whole-part relationship between the ConferenceVenue class and the SessionVenue
class. The answer is simple - Whole-Part relationships within roles just don't
appear to be very useful. I have seen them very occasionally but ended up
removing them from the implementation. A <<Role>> is there to
provide a delegate for a Person, Place or Thing in a specific transaction. If
for example, you need to ask the SessionVenue class a question about its
parentage, it is likely to delegate out to its Room object or its Session
object which in turn would ask the Hotel object or the Conference object. If
you do find a legitimate use for Whole-Part composition with
<<Role>>s then please send me an email at the address below.
Summary
Color modeling with the Domain Neutral Component is a
very powerful technique which quickly allows you to create a highly flexible,
loosely coupled functional architecture for an object-oriented system in a
language like Java. The DNC relies heavily on object inheritance rather than
class inheritance. The original DNC published in 1999 did not document all the
relationships between the class archetypes on a color model. One of those
missing elements was the Whole-Part composition/containment relationships seen
in Description archetypes and Person, Place and Thing archetypes.
As a general rule, whole-part relationships in a color
model should inherit the color of the parent containing class. When this is not
the case, it is a red flag to the modeler that there may be something missing
or that a choice has been made to reduce the number of classes in the model in
exchange for some tighter coupling and reduced flexibility.
About the author
David J. Anderson is the author of the recent
book, "Agile Management for Software Engineering - Applying the Theory of
Constraints for Business Results" published in Peter Coad's series by Prentice
Hall PTR in September 2003. He is Principal Consultant with VA Systems
Professional Services. David was one of the team which created the popular
agile development method, Feature Driven Development. He has introduced FDD at
two Fortune 100 companies Sprint (a telecommunications operator in the United
States) and Motorola. He writes the regular Agile Management
column at the Borland Developer Network website and publishes the his weblog at
agilemanagement.net. He holds a
degree in Computer Science and Electronics from the University of Strathclyde.
Email: fddmanager@yahoo.com
References
Coad Peter, Eric Le Febvre & Jeff De Luca, Java Modeling in Color with UML - Enterprise
Components and Process, Prentice Hall, Upper Saddle River, NJ, 1999
Nicola, Jill, Mark Mayfield and Mike Abney, Streamlined Object Modeling Patterns,
Rules and Implementation, Prentice Hall, Upper Saddle River, NJ, 2002
Palmer, Stephen R., A New Beginning, The Coad
Letter, 2002
http://www.thecoadletter.com/article/0,1410,29697,00.html
