Class Archetypes and the Unified Modeling Language (UML)

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 class archetypes, 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 (see figure 1).

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 (see figure 2).

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 and separated by commas if there are more than one. 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.

Our template classes look like those in figure 3.

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. We can also add a template class for Moment-Interval Detail classes (see figure 4).

Figure 4: Template 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