Peter Coad's 'modeling in color' object modelling technique represents class archetypes as colour-coded, stereotyped UML classes. Why?

UML is the most popular industry standard for representing object-oriented analysis and design ideas in a graphical form. Therefore, if we are building problem domain object models using the four class archetypes defined Peter Coad's 'modeling in color' technique, it is highly likely we will also want to use UML. To use class archetypes effectively in our UML models we need some way of indicating the class archetype of a class.

By default UML shows classes as a rectangle split into three sections or compartments. The top compartment contains the name of the class. The second compartment lists the attributes of the class and the third compartment lists the operations of the class. UML defines in detail exactly what each of these compartments may can contain and the exact syntax for that content.

UML notation for a class

Figure 1 : UML Class Notation

Communicating the Class Archetype of a Class

To communicate the class archetype to which a class belongs we could resort to a naming convention where standard prefixes or suffixes are added to the names of the classes. However, this is not a good idea because it may conflict with other naming standards in use. Also, demanding extensive renaming within an existing model to communicate the class archetypes of classes is not likely to prove popular and may not even be feasible with the use of third-party frameworks, toolkits or libraries.

Peter Coad uses UML stereotypes to label a class with its archetype[Coad99]. Stereotypes are one of the extension mechanisms built into UML. Adding one or more stereotypes to a model element further defines the type of that element. For example, a class might be given a <<persistent>> stereotype to indicate that its objects are saved to secondary storage such as a database or XML file when they are not in memory.

UML notation for a class stereotype

Figure 2: UML Stereotype Notation

In the more recent versions of UML, model elements like classes may be given multiple stereotypes. By default the stereotypes of a class are displayed above the class name between guillemot characters. Guillemot characters are used instead of quote marks in some European languages. If guillemot characters are not readily available then pairs of angled brackets are used instead. Multiple stereotypes are separated by commas between a single pair of guillemots.

A stereotype may be nothing more than a name that conveys more information about the type of a model element. Therefore, it seems quite reasonable to use the UML stereotyping mechanism to indicate the class archetype of a class. However, if we are going to use the stereotype tags in UML to record the archetype of a class, why not follow the UML terminology and call them class stereotypes instead of class archetypes? The answer to that comes from the idea of archetypes being a more or less type of pattern.

Phil Bradley is the acknowledged source of this discussion and the chief advocate of the use of 'archetype' instead of 'stereotype'. The problem with the term, stereotype, is that it describes a rigid pattern of behavior or set of characteristics. Stereotypes are strict patterns that are repeated without change. Assigning a class a stereotype is to give it a set of rules that may not be broken. Although a UML stereotype can be just a name, it may also define additional meta-data items in the form of name-value pairs for model elements with that stereotype. For example, our <<persistent>> stereotype for classes could define an extra meta-data item for classes called table_name that holds the name of the database table to be used to store objects of that class.

A UML stereotype may also define additional constraints for model elements with that stereotype. Our <<persistent>> stereotype could insist that classes with that stereotype have at least one attribute that has a stereotype of <<primary key>> to indicate which attributes of the class should be used to form the primary key column of the database table in which objects of that class are stored.

An archetype is more relaxed than this. It is more about general guidelines than specific meta-data items, rules and constraints. This is why we prefer the term class archetypes to class stereotypes. Peter Coad defines a class archetype as " a form from which all classes of the same kind more or less follow" [Coad 99]. There are no additional meta-data items to add for any of the class archetypes and the checklist of typical responsibilities, operations, attributes and associations are guidelines and suggestions rather than strict constraints.

UML defines a mechanism for describing and showing the use of design patterns. This uses a construct called a collaboration represented by a dashed ellipse with the name of the pattern inside it. We have said that class archetypes participate in patterns so maybe collaborations are a better way than stereotypes of indicating the archetype of classes in our models. Unfortunately they are not for a number of reasons including:

  • The class archetype of a class is more strongly related to what the class models than how a class participates in a pattern. The fact a class is of a certain archetype means it will typically collaborate in a particular way with other classes. It is not the way it collaborates with other classes that determines the archetype of a class.

  • The notation for collaborations adds a significant amount of clutter to a diagram and can make larger diagrams almost impossible to read. The notation is obviously designed for use on small diagrams only.

  • UML 2.0 adds the complications of collaboration roles and parts to the mix, making the notation harder to learn.

  • The use of collaborations to show the structure, interaction and use of a design pattern is far too rigid again for what we want when modeling with class archetypes.
Therefore, despite some small reservations, the use of stereotypes is still the most appropriate way of indicating the archetype of a class in UML models.

Responsibilities and UML

The more-or-less aspect of class archetypes also explains why, when we come to consider how we might represent the typical responsibilities of a class archetype in UML, we find that the stereotype extension mechanism provides us with no additional help. Typical responsibilities, operations, attributes and associations are neither additional meta-data or strict constraints.

Ideally what we want is the list of typical attributes, operations, and associations to be available once we have decided on the archetype of a class. There is one simple way to provide most of what we ideally want. In our UML modeling tool we simply create a template class for each of the class archetypes that contains all the typical attributes and operations for that class archetype. To create a new class for our model we simply copy the template class of the appropriate class archetype and amend the contents as necessary.

Template classes, one for each class archetype

Figure 3: Template classes, one for each class archetype

The other advantage of creating template classes like this is that we can also use them to show the typical associations between the different archetypes and the ways they participate in different archetypal models and patterns.

Template classes for the four class archetypes plus Moment-Interval Detail with typical associations

Figure 4: Template classes for the four class archetypes plus Moment-Interval Detail with typical associations

Obviously, if modeling on a whiteboard or flipchart using Post-It™ notes we cannot make a copy of a template. We could make photocopies of each template class with it's typical content printed faintly so it fades into the background as we write in the actual content of the class. These could be stuck on the whiteboard with double-sided tape or paper adhesive. However, this feels like far more trouble than it is worth. Therefore, unless we can afford to have custom Post-It™ notes printed lightly with the content for each class, we simply make do with referring to a printed copy of the diagram above.

Colour Coding Class Archetypes

Although class archetypes can obviously be used effectively without it, colour coding the class archetypes is what gives the technique its 'modeling in color' name. In practice, the colour coding has proved so beneficial that it is well worth the little extra effort required to learn and use it.

As also shown in figure 1, when working in a UML modelling tool (like Together, UModel, Enterprise Architect or Visual Paradigm), classes belonging to a particular class archetype display that class archetype in a UML stereotype (the text above the class name between the pairs of angle brackets). So if the archetype that a class belongs to is shown as a UML stereotype tag, why bother with the colour-coding? As Peter Coad says, "Although a stereotype tag is a convenient UML mechanism for indicating the archetype of a class, it does hide some very important meaning in a rather plain and simple text label" [Coad99].

The same could be argued for the standard stereotypes of UML and the designers of UML obviously recognized this because UML allows for alternative ways of depicting stereotypes that help the stereotype stand out more clearly in diagrams. The stereotype name between pairs of angle brackets (or guillemot characters) are the default way of showing a stereotype but stereotypes can also be shown by a change of graphic symbol or shape.

In figure 5 the Cashier class is drawn using the alternative symbol for the <<actor>> stereotype and the Manager class is drawn using the default representation.

An alternative icon for the actor stereotype next to the default class symbol with text tag indicating the stereotype

Figure 5: An alternative icon for the actor stereotype next to the default class symbol with text tag indicating the stereotype

There are a number of problems in this approach. Firstly, when the alternative symbol is used it is not easy to list the attribute and operations that belong to that class so they are either omitted from the diagram or are listed underneath the symbol in a rather unsatisfactory manner. One way around this is to stick with the default rectangle but instead of the textual stereotype tag above the class name, display a much smaller version of the stereotype's alternative symbol to the right of the class name (see figure 6). This approach has grown in popularity recently and is used throughout UML 2.x to good effect. Unfortunately, it also significantly reduces the ability of the stereotype information to stand out from the rest of the information in a diagram. It is better than the text tag but not by very much.

Stereotype symbol shown to the right of the element name

Figure 6: Stereotype symbol shown to the right of the element name

A second disadvantage of using a non-standard symbol to represent a stereotype is that it fails to communicate to people unfamiliar with the symbols being used.

Thirdly, additional symbols add to the burden of learning to read the diagrams for those new to UML and those who are only occasional users. Most people deliberately restrict themselves to the most frequently used subset of UML class and sequence diagram notation. There is more than enough additional notation available for UML class diagrams in the UML specification without us adding more shapes and symbols without a very good reason.

Fortunately the UML standard does rather begrudgingly allow us an alternative: colour.

Colour Objections

There are two immediate objections raised when anyone suggests the use of a color-coding scheme. Firstly, because of the difficulty it causes for some colourblind people. Secondly, because of the problems of reproducing color on grayscale-only printers, copiers and fax machines and the cost of reproducing colour copies.

Retaining the textual tags for our class stereotypes and class archetypes when using colour solves the challenge for some colourblind people in distinguishing one class archetype from another and an appropriate choice of colours keeps the diagrams readable when grayscaled by colour-challenged devices.

These days most projects can afford the cost of an ink-jet printer/scanner/copier for occasional, reasonable-quality, colour, printed output and the increasing use of intranets and mime content in e-mail by project teams means that the use of colour is not quite the technological problem it might have been in the past. However, publishers of books and other high-volume, high-quality printed material may still have good cause to object to the use of colour due to the additional cost involved, but with improving technology, this really should become less and less of a problem.

For most of those that have tried object modeling in colour, the benefits of using colour heavily outweigh the objections. So instead of assigning a different shape or symbol to each class archetype we assign a different colour.

A Brief History of Coloured Archetypes

As explained by Peter Coad [Coad99], the colours that were originally used are those that happened to be available in multicoloured packets of Post-It™ notes at United Overseas Bank, Tiong Bahru, Singapore in September 1997. In collaborative workshop style object modeling sessions, we were using Post-It™ notes to represent classes and objects as we built UML-like class and sequence diagrams on flipchart pads. We very quickly exhausted the stationary cupboard's supply of yellow-only pads of Post-It™ notes and were provided with packs containing pads in four different colours. Peter Coad, who was facilitating and coaching the sessions, put the colour-coding in place to counter a growing sense of confusion from using the four different colours. This worked so well that Peter went away to research and develop the technique. The results were briefly documented in [Coad 99]. We expand a little more below.

Benefits of using Colour in Modelling

Even without research into colour theory it is quickly clear to most people that try object modelling in colour, that it has very positive benefits.

Firstly, and maybe most importantly, object modeling using colour-coded class archetypes becomes helpful in the analysis of requirements and a problem domain. The class archetypes themselves represent concepts that are within the grasp of most reasonably intelligent people even if they do not have a technical or analytical background. Also most people find learning a four-colour code well within their grasp. With colour, object models become a much better communication framework for business and development to collaboratively explore and explain requirements for software systems and components.

Secondly, for developers, the use of colour adds new depth to a diagram making the different layers of information in it stand out from each other.

Why is this so? I readily acknowledge that I am not an expert in the psychological and technological aspects of the use of colour but a quick browse of the Internet reveals a wealth of information about colour theory, models, and psychology both ancient and modern. Thanks must go to the authors of the many helpful websites, too many to list individually, that were visited in researching this topic.

Some developers talk of poorly designed or written code as having a bad smell. Peter Coad used to talk of good object models singing to him, and many of us have used the expression, "it just feels right" when we cannot justify an analysis or design decision in any other way. What we are all talking about, is a sense of harmony. Harmony can be defined as a pleasing arrangement of parts, whether it is music, poetry, source code or colour. Harmony has a sense of correctness, order and balance. Visually, harmony is something that is pleasing to the eye. The opposite of harmony is discord. Visual discord occurs when something is either boring or chaotic. The careful use of colour helps a viewer engage. Poor use of colour can cause a viewer to disengage. Unexpected or unusual combinations or patterns of colour catch the eye.

Before you start to read the detailed textual content of a colour-coded object model, the overall shape and colour are already communicating high-level information. Colour makes the patterns of collaborating class archetypes visible from a distance. Potential problems appear as areas of discord within those patterns. Colour also provides an 'easy in' for non-technical people or those that are not so familiar with UML notation; it gives them something conceptually simple and tangible that they can grasp immediately rather than the featureless, flatness of a monochrome diagram. This helps people penetrate through the initial discouraging and often overwhelming 'where do I start?' feelings when presented with a complex class or sequence diagram.

In the same way that once you have watched colour television or seen colour photographs you do not want to return to black and white except for nostalgic or artistic reasons, most people once they have experienced object modeling in colour never want to return to the shallowness of the black and white version.

Four Colours for Four Archetypes

With four archetypes we obviously need four colours but which four and which archetype should be assigned which colour? We used the four colours we had immediately available in Singapore but are there better choices or good alternatives especially when those colours are not available?

Throughout history various philosophers, psychologists and scientists from China, India, Ancient Greece and Europe including Pythagoras and Leonardo De Vinci have proposed different sets of primary colours; those colours that can be mixed to form all other colours. These historical models were largely based on perception and often associated with the known planets of the solar system and the historical elements of earth, water, wind, and fire. In addition to black and white, the popular choices were red, green, blue and yellow. These same six colours now form the Natural Colour System, the most widely used colour notation system in Europe (

Perhaps predictably, the Post-It™ notes originally used in the modelling exercise in Singapore were pastel shades of red (pink), green, blue, and yellow. Being variations of the perceived primary colours, the pastel shades contrast well with each other so that they stand out but are not so bright that they overpower or so dark that it becomes difficult to read text written or printed on them.

So we have a set of four ideal colours:

  • Pastel Pink
  • Pastel Yellow
  • Pastel Green
  • Pastel Blue
Unfortunately for those wanting to use the workshop-style modeling sessions with Post-It™ notes it is becoming harder and harder to find packs of Post-It™ notes in these four colours. I often need to substitute one or more colours. In these situations I find purple or mauve makes a passable substitute for blue, pastel orange for pink, and grey for green. I have not found a great substitute for yellow but because it is the original Post-It™ note colour I have always found it to be readily available. As with any notation, it is takes some effort to switch so it is best to stick with a set of colours for the duration of a modeling exercise if at all possible. Whenever I can I use the original four colours.

Choosing the Colour for each Archetype

So we have four colours but which colour should be assigned to which class archetype?

Red, orange and yellow are thought of as warm, active, and dynamic colours. Green, purple and blue are thought of as cooler, passive, and more stable. Lighter colours are also thought of as being more active than deeper colours.

These ideas fit nicely with the moment-intervals being pink because moment-intervals represent some event or activity, some sort of interaction. They represent where the money is made and spent in a business system and that is something that excites business people. Selecting orange as alternative colour to pink also makes sense for the same reasons.

With roles there is also a sense of activity because they represent the ways people, places and things participate in moment-intervals. Therefore, making roles yellow, the next warmest colour in our selection makes sense.

The most passive and stable objects in our problem domain are those of the description classes and therefore it is appropriate to colour these blue. Purple as an alternative to blue again fits nicely.

That leaves green for the relatively stable entities, the people, places and things. Gray also fits as an alternative colour for this archetype.

The four achetypes in their assigned colours
Figure 4: The four achetypes in their assigned colours

Follow me on Twitter...