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 in the object modelling in colour 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 the possible contents for each of the compartments and the exact syntax for that content.
 |
| 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 viable.
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.
 | |
|
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. Multiple stereotypes are separated by commas. 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.
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 a 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 does have 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 to be used only on small diagrams.
- UML 2.0 adds the complications of collaboration roles and parts to the the mix making the notation harder to learn.
- The use of collaborations to show the structure, interaction and use of a design pattern is again far too rigid 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
This 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 |
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.
 |
| emplate classes for the four class archetypes plus Moment-Interval Detail with typical associations |
Obviously if modelling 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 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. Angle brackets and guillemots are the default way of showing a stereotype but stereotypes can also be shown by a change of graphic symbol or shape.
In the figure below, 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 |
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 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. This approach has grown in popularity recently and is used in UML 2.0 to good effect but, 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 much.
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 subset of UML class and seqeunce diagram notation most frequently used. 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 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 problem of colourblind people not being able to distinguish 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.
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 Archetype Colours
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 modelling 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 better communication framework for business and development to collaboratively explore and explain requirements for software systems and components.
Secondly, for designers and 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, and many of us have used the expression, "it just feels right" to justify an analysis or design decision. 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 in a UML diagram. 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 in a diagram 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.
Once you have watched colour television or seen colour photographs, few want to return to black and white except for nostalgic reasons. In the same way, most people once they have experienced object modelling in colour do not 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 (www.ncscolour.com )
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:
- 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
Comments
Write New Comment ▼
Write New Comment
Sorry! This knol's owner(s) have blocked you from editing, making suggestions, or commenting here.