The Description Class Archetype

In Peter Coad's 'Modeling in Color' technique, all significant Problem Domain classes belong to one of four class archetypes. One of the four class archetypes is the blue Description archetype. This is used to represent objects that might appear as entries in some sort of catalogue.

The Description Class Archetype is one of four class archetypes in Peter Coad's 'modeling in color' technique.

Peter Coad defines a Description class as modelling a catalog-entry-like description. It is a collection of values that apply again and again. It also provides behavior across the collection of all things that correspond to its description.[Coad99]

Classes belonging to the Description class archetype categorize members of other archetypes based on different values of attributes. Examples include the make and model of cars, the industries to which organizations belong, whether a building is low-rise, or high-rise and so on.

Figure 1: The Description Class Archetype


The other three class archetypes cover the problem domain events and activities that our software is interested in, who participates in those events and how, where the events and activities take place, and what other things are involved. The Description class archetype describes different subsets of the parties, places, and things that are involved and sometimes different categories of Moment-Intervals too.

It is important be clear about the difference between the Description and Party-Place-Thing class archetypes. Each object of a Description class describes a set of objects that belong to some category. An object of Party, Place, Thing classes is a specific, individual, identifiable item.

The difference between a Description and a Party, Place, Thing is the difference between the general description of a particular make and model of a car (the Description) and an actual example of  kind of thing being described, a particular car (the Thing) standing in someone's driveway. An airplane ticket may indicate the type of airplane (the Description) used for a flight but eventually the pilot, crew and passengers need an actual airplane (the Thing) to board. We might decide we want a beach resort vacation this year (the Description) but we have to make a booking at a particular holiday venue (the Place) that fits that description. A person may indicate the industry in which they work (the Description) but this differs from the actual organization (the Party) that employs them.
 
Although we tend to use words like type of and kind of to talk about Description classes we are not talking about an inheritance style relationship between a Description and the items it describes. Inheritance is a relationship between two types of item. Instead the relationship between a Description and the items it describes is similar to the relationship between a class and its instances. It is a type-instance pattern.

There are also times when we truly want to describe different types of yellow Role and pink Moment-Interval archetypes and it feels right to connect a blue Description directly to a yellow Role or pink Moment-Interval. An example is an employment Moment-Interval where there are different types of employment - full-time and part-time for instance. 





Typical Responsibilities

Like all the class archetypes, the usefulness of the Description class archetype in reviewing and building object models is due to its typical responsibilities, and the lists of typical attributes, operations and associations that represent those responsibilities.

More on the typical attributes, operations and associations of Description classes..


Trade off between blue and subclassing green

When talking about description archetypes, we often find ourselves using the 'type' word. A BMW 528i is a type of car; the actual BMW 528i sat on the driveway of one my friendly Borland sales reps is an object, example, specimen or instance of that type. Surely the traditional object oriented way to represent different types is to create subclasses? There are some subtle differences and some design trade-offs to be made. Let's look at the trade-off's first.

Using a blue Description class to represent different types we can very easily create a new type in a running system by creating a new instance of our Description class and configuring its attributes accordingly. Using subclassing we need to code a new class and deploy it before we could create objects of the new type; not too bad in Java but definitely not so easy in C++.

However, blue Description classes have their limitations; if different types actually have different attributes instead of just different values of the same attributes it quickly becomes messy or over complicated to use a Description class and subclassing is usually the better option. The same is true when different types need different operations; if only the algorithm of one or two operations differ we can use the plug-in strategy described below.

To summarize: A blue Description class is useful when the objects it describes have common attributes but subsets have different default values of those attributes. However, when subsets of the described objects have differing quantities and types of attribute and operations then subclassing is the better approach. Of course, the optimum model is often a mix of the two. 


The Class Archetype Formerly Known As...

One oddity  I have observed a number of times is to start to call Description classes, Detail classes by mistake and start a train of thought that understandably leads to profound confusion between what is a Description and what is a party, Place, Thing. This seems strange but it has happened so often in modeling workshops that it is now no longer a surprise when it happens. 

In Martin Fowler's book, Analysis Patterns, classes are split  into two layers: operational and knowledge. We could colour the classes in the knowledge layer blue. It would indeed seem we can connect a blue class to describe any archetype - connecting to a green is the most likely, pink is the next likeliest. In my experience, connecting directly to describe a yellow Role is much less frequent and is more often the result of dropping unnecessary classes from a more general DNC inspired model shape. However, the question of whether we are connecting to describe or connecting because we are dropping unnecessary classes is one probably best debated over a few drinks after work; the end result is much the same.
 
 

The Other Class Archetypes

In addition to the Moment-Interval Class Archetype, Peter Coad defines three other class archetypes:


Related Books

Books (with Amazon.com links) that contain related or complimentary material:
 
  • Coad, Lefebvre, De Luca, Java Modeling in Color with UML, Prentice Hall PTR, 1999
    The original introduction to the modeling in color technique with examples from common business software problem domains.
  • Coad, North, Mayfield, Object Models: Strategies, Patterns, and Applications, Prentice Hall PTR, 1996
    Excellent precursor to the modeling in color technique. Much of the initial thinking that evolved into the technique is clearly visible, and presented through simple example models.
  • Nicola, Mayfield, Abney, Streamlined Object Modeling: Patterns, Rules, and Implementation, Prentice Hall PTR, 2001
    A related set of object modelling patterns with an emphasis on archetypal collaboration between different kinds of classes. A comparison with the modelling in colour archetypes is included.
  • Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley Professional 2003
    A slightly lower-level set of patterns for object models. Compliments the modeling in colour archetypes in many ways and addresses the use of such patterns in agile development environments.
  • Palmer, Felsing, A Practical Guide to Feature-Driven Development, Prentice Hall PTR, 2002
    The author's book describing Jeff De Luca's agile development process. While FDD does not mandate modelling in colour, the two compliment each other exceptionally well. The book explains when and how.

Comments

Stephen Palmer
Stephen Palmer
Software Developer, Consultant, Author
Exmouth, Devon, UK
Article rating:
Your rating:

Activity for this knol

This week:

35pageviews

Totals:

1017pageviews
©2009 Google