The Description Class Archetype is one of four class archetypes in Peter Coad's 'modeling in colour' 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.
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.
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 Description Class Archetype
The fourth and last class archetype defined by the modeling in colour technique, is the Description class archetype. This class archetype models 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. It categorizes objects of other classes according to different values.
Typical Responsibilities of Descriptions
Like all the class archetypes in modeling in colour, the true usefulness of the Description class archetype in identifying and reviewing problem domain classes is due to its typical responsibilities, and the lists of typical attributes, operations and associations that represent those responsibilities.
Accelerated Problem Domain Analysis
Peter Coad's 'Modeling in Color' technique uses the idea of class archetypes to build understanding of a problem domain quickly. Jeff De Luca's Feature-Driven Development approach defines a collaborative process that works beautifully with modeling in colour. Domain experts and developers work together on a daily basis to build an overall, initial, 'just enough' domain model that is then used to build a much better initial product backlog or features list.
Model Archetypes and Domain Neutral Components
Linking together the typical associations between class archetypes presents us with a pattern of classes we call a model archetype or domain neutral component. We can display this with the Party, Place, Thing class archetype as a single class to give a basic model archetype. Alternatively we can explode the Party, Place, Thing class into its three flavors and produce a larger more comprehensive domain neutral component that is even more useful. Model archetypes can be used to rapidly build new problem domain models or review and revise existing problem domain models.
Class Archetypes, UML and Colour
Class archetypes can be used without the colour coding quite happily. Colour can be used to highlight items in diagrams with great effect without the use of class archetypes. The combination of the two, however, provides a much deeper means of communication. The colour-coding 'layers' into the diagram. It provides a means to quickly and effectively engage with a non-trivial diagram. You can 'step back' from the diagram and examine the patterns of linked coloured classes, 'zooming in' on textual detail as needed. After modeling in colour for a while, you wonder how you were ever satisfied with black and white diagrams.
From UML Association to the Domain Neutral Component
Karl Frank and I were in Denver, USA, giving a modeling in colour workshop for a client. One evening Karl asked me what if any relationship I thought there was between roles in the Domain Neutral Component (DNC) and role labels on a UML association. The subsequent discussion sparked a train of thought that further convinced me of the simple, effectiveness of using the domain neutral component.