An Introduction to Modelling in Colour

First used on a major Java software development project in Singapore in 1997, Peter Coad, and his co-authors, Eric Lefebvre, and Jeff De Luca, introduced the modelling in colour technique in their book, Java Modeling in Color with UML, published in 1999.

Modelling in colour is an object modelling technique. It helps identify and define appropriate, problem domain classes for a software component, application, or system.

In a traditional, layered, object-oriented software component, application, or system, problem domain classes form the most important logical layer of the software.

In more component-based or service-oriented software, problem domain classes help drive the definition and organisation of business services and components. They also help drive the design of the problem domain classes used in the internal implementation of a component or service.

Therefore, any patterns or strategies that enable better and faster identification of problem domain classes are worthwhile learning. The Modelling in Colour technique includes numerous such strategies and patterns.

This article can also be viewed as a Google Knol

Figure 1: Modelling in Colour

Class Archetypes

In business systems, the same general kinds of significant problem domain class keep appearing, no matter what the domain. For, example there are nearly always classes that represent business transactions or interactions of different types such as sales, orders, rentals, bookings, scheduled events, deliveries, submissions, approvals, enquiries, etc. Also there are usually classes that model the parties, places, and things that participate in those business transactions or interactions. For example, there are the people or organisations doing the buying, selling, ordering, submitting, approving, etc. Then there are the products and services being bought, sold, approved, etc. There are also the places like shops, bank branches, websites, etc., where all this is happening.

However, it is not just business systems where these kinds of class appear. In industrial systems we have classes modelling specific types of event and intervals of time such as changes in state of a sensor or switch, a period of time over which a measurement is taken, the length of time a piece of equipment is ramping up to a certain level of performance, and so on. Again there are also typically, party, place and thing classes representing the sensors and devices themselves, human operators supervising the equipment or process in question, and the locations of the various pieces of equipment, etc.

The similarities between all the classes of one of these rough categories are usually not close enough to be generalised into a useful superclass or Java-style interface. However, the similarities are close enough for them to help guide the choice and definition of classes in our designs. Modelling in colour calls these rough categories, class archetypes and recognises four of them.

The four class archetypes are:

The Moment-Interval class archetype that models something that one needs to work with and track for business and legal reasons, something that occurs at a moment in time or over an interval of time. [Coad99]
Examples of Moment-Interval classes include Sale, Rental, Order, Journey, Flight, Meeting, Booking, SensorReading, etc.
The Role class archetype that models a way of participation by a party (person or organization), place or, thing. [Coad99]
Examples of role classes include Applicant, AccountHolder, Approver, Pilot, Cashier, etc.
The Party, Place, Thing class archetype that models someone or something who plays different roles.[Coad99]
Examples of Party classes are Person and Organization. Examples of Place classes include Office, Store, Warehouse, Airport, BankBranch, etc. Thing classes are those that identify individual items such as individual cars, airplanes, DVD's, books, pieces of equipment, etc.
The Description class archetype that 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. [Coad99].
Examples include classes representing product descriptions of all kinds. The difference between a blue and green is the difference between a film and the DVD's on which the film is recorded.

Typical Responsibilities

Because classes of the same class archetype model roughly the same sort of thing, their objects generally need to remember similar sorts of bits of information and perform similar sorts of tasks. Objects of a Moment-Interval class generally remember the date and time they occurred and can tell you if they completed successfully or not, for example.

By examining numerous examples of each class archetype and generalising slightly we can create a rough list of typical operations and attributes for each class archetype. Each attribute or operation in the list represents a typical kind of operation or attribute that we might expect to define for classes of that archetype (see Figure 2).

Figure 2: The four major class archetypes with their typical attributes and operations

Few if any of the classes in a particular model will have examples of all the typical attributes and operations of their class archetypes. If a particular typical attribute or operation is not relevant for a specific class we simply do not define an equivalent attribute or operation for that class. For example, some Moment-Interval classes need the concept of relative priorities and will have the equivalent of a priority attribute. Other Moment-Interval classes do not.

Each typical attribute or operation of a class archetype may match multiple attributes or operations on a specific class. For example a Moment-Interval may need both a major and minor status attribute if it has a complex lifecycle.

The lists of typical attributes and operations are not exhaustive either. There will be attributes and operations in our actual classes that have no equivalent in the relevant class archetype's list. For example a Party class modeling an individual person may contain a retention date attribute indicating when the data must be erased to comply with some legal requirement. There is no equivalent for this attribute in the Party, Place Thing class archetype.

The typical attributes and operations of a class archetype are simply suggestions for specific attributes and operations that we might need in our actual class definitions. They act as prompts and hints of things we should consider when creating or reviewing a class belonging to a particular class archetype.

Another way to think of this is that each operation or attribute of a class archetype acts as a reminder of a typical responsibility for classes of a particular class archetype. If we can identify the class archetypes of the classes in our problem domain, the lists of typical operations and attributes give us a check-list that can help us review or place responsibilities appropriately in our own models. For example, the first attribute in each of the class archetypes is some sort of identification or reference number. This reminds us that objects of classes belonging to any of the class archetypes have a responsibility to enable themselves to be matched to the real-world object that they represent. For example, a cash sale object will typically remember a receipt number as its reference number so that it can be matched to the particular transaction it models. Objects representing cashiers might be assigned a user name to enable them to be matched to their human counterparts when they login, and so on.

Colour Coding Class Archetypes

As shown in figure 2, each class archetype has a colour. Although class archetypes can obviously be used effectively without it, it is this colour coding that gives the technique its name. The colour coding has proved so beneficial in practice that it is well worth the little extra effort required to use it.

The colour makes it easier to learn and remember the class archetypes. It also makes the class archetypes easier to identify in a non-trivial diagram and that helps prevent people, especially those new to object modelling diagrams or are infrequently involved with object modelling such as a project's customers and end users, from being immediately put off when presented with complex diagrams. The colour coding gives them an easier means of engaging with the diagram. For example, they can easily identify and zero in on pink Moment-Interval classes representing the business interactions they are interested in and work outwards from there.

Much of the benefit derived from using object modelling techniques is in the ability to communicate complex analysis and design more easily. The use of colour increases that ability significantly.

For those interested in why the use of colour works so well, Colour Coding Class Archetypes has a further discussion on the use of colour, including what colour to use for each class archetype.

For now, it is enough to know that the four class archetypes are usually assigned the following colours:

Moment-Interval classes are a pastel shade of pink
Role classes are a pastel shade of yellow
Party, Place, Thing classes are a pastel shade of green
Description classes are a pastel shade of blue

Model Archetypes

To fulfill their responsibilities objects frequently need to collaborate with objects of the same or other classes. Therefore, many of the typical responsibilities in class archetypes imply typical associations with other classes and typical ways of interacting with objects of other classes. These typical associations and typical interactions of their objects enable us to combine class archetypes into archetypal problem domain object models. These model archetypes or domain neutral components act as general repeating patterns for our analysis and design models.

Figure 3: The four class archetypes linked together into the basic model archetype

Figure 4: The domain neutral component - the basic model archetype expanded for each flavour of Party, Place and Thing

Using the Domain Neutral Component (DNC) can really help speed up the building of our problem domain object models. Start by identifying one or more Moment-Interval classes in the particular problem domain of interest. Then for each of these in turn, overlay the DNC. Step through each item in the DNC turn replacing it with items specific to this particular problem domain or dropping it if there is no equivalent in this problem domain or it is simply not needed in model.

The DNC can also be very useful in reviewing existing models looking. First, colour in the model by assigning archetypes to each class. Then challenge and justify deviations and omissions from the DNC. However, remember that the DNC is a pattern not a meta-model. A meta-model defines a rigid set of rules for creating compliant models. The DNC does not do this. It is much looser, a set of suggestions and hints. Justifiable deviations from the pattern are allowed, expected, and essential in many cases.

When they first encounter it, many people including myself, are a little skeptical about how applicable the DNC is in practice. There are two reasons I think that the DNC is much more applicable than maybe first expected. Firstly, most business systems are centred around a particular business event or activity or a flow of events and activities in the form of a business process. The Moment-Intervals model these business events and activities. For each business event and activity there are typically different people or organisations involved in different ways. The events and activities usually take place at some location even if, these days, that location is somewhere in cyberspace. Business events and activities are frequently about things being bought, sold, assigned, moved, etc. The Roles and Party, Place, Things model the who, where and with what of the business events and activities. The Descriptions model different sets or categories of the Party, Place, Things involved in the events and activities.

The second reason why I think that the DNC is much more applicable than maybe first expected is a line of thinking triggered by a discussion with an old colleague of mine from TogetherSoft and Borland, Karl Frank. When you step back and think about it for a while, you realise that the DNC is in essence a natural expansion of a UML association between Party, Place and Thing classes. The Moment-Intervals are similar in many ways to the idea of an association class and the Roles are a similar idea applied to the role names found on the ends of the association.

More on model archetypes and the DNC...
More on using the DNC...
More on the DNC's relationship to UML associations...

Summary

As software analysts and designers build more and more object models, they start to collect a set of patterns and strategies of constructs and collaborations that have worked well. They reuse and continuously refine these patterns and strategies as they build new models. Modelling in colour is a technique built on the patterns and strategies that Peter Coad, with his co-authors and colleagues, identified, used and refined over several years of building object models on actual software development projects in the USA and across the world.

The four class archetypes that the technique defines represent four rough categories of class found in many object-oriented software applications and components. The class archetypes suggest typical responsibilities for their classes by listing a set of typical attributes and operations. These in turn imply a typical set of associations to classes of other class archetypes enabling us to build archetypal models and the domain neutral component. The DNC can be used as a template when building new problem domain object models or as a reference when reviewing existing models.

The technique derives its name from the colour coding used to indicate which class archetype a specific class belongs to.

More on moment-intervals...
More on Roles...
More on Descriptions ...
More on Party, Places and Things...