Modelling in colour is an object modelling technique. It helps identify and define appropriate, problem domain classes for a software component, application, or system.
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. In addition, 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. When you are new to object modelling or infrequently involved with object modelling, you can be immediately put off when first presented with a complex diagram. The colour makes it easier to engage with the diagram. This helps people such as a project's customers and end users contribute to the modelling process. For example, they can easily identify and initially focus 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 fulfil 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, are a little sceptical about how applicable the DNC is in practice. I certainly was. There are two reasons I think that the DNC is much more applicable than maybe first expected. Firstly, most business systems are centred on 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. Frequently business events and activities are about buying, selling, assigning, and moving things. 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.
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 technique introduces the idea of a class archetype and derives its name from the colour coding used to indicate to which class archetype a specific class belongs.
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. Use the DNC as a template to build better problem-domain object models quicker. In addition, use it as a reference when reviewing existing models.
The four class archetypes defined by the modelling in colour technique are:
- The Moment-Interval Class Archetype
- The Role Class Archetype
- The Party, Place, Thing Class Archetype
- The Description Class Archetype
Related Books
- 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
Write New Comment ▼
Write New Comment
Sorry! This knol's owner(s) have blocked you from editing, making suggestions, or commenting here.