Modelling in Colour: Model Archetypes

To fulfill their typical responsibilities classes of a particular class archetype need to collaborate with other classes of either the same archetype or of another archetype. This means that there are typical associations between classes that belong to class archetypes. For example:

A Role class will typically be associated with the Moment-Interval classes that it participates in and, over time, a Role class usually may participate in a number of the same kinds of Moment-Intervals. Therefore there is typicality a one to many association between a Role class and Moment-Interval class.
Party, Place, Thing classes obviously need to be associated with the Role classes that model the way they participate in Moment-Intervals. Typically for each of the Roles that a Party, Place Thing might play they either play the role or do not. Therefore, the association between a Party, Place, or Thing class and a particular Role classes is most often a one to zero or one relationship.
Description classes usually categorise Party, Place, or Things classes and each instance of the Description class describes zero or more objects of the associated Party, Place, or Thing class.

This leads to the following class diagram which is taken from [Coad 99] with the modifications as described in Typical Responsibilities.

The obvious questions to ask about a Moment-Interval are when, where, who, what, and why? Through the Roles that they play, the Party, Place, Thing class archetype provides us with answers to these questions:

Who is involved with a particular Moment-Interval? This is answered by Party classes via the roles they play.
Where is this Moment-Interval occurring? This is answered by Place classes via the roles they play.
What else is involved in or affected by this Moment-Interval? This is answered by Thing classes via the roles they play.

The question of when is answered by the date and time responsibility of the Moment-Interval class represented by the dateOrDateTimeOrInterval attribute. That leaves us with the why.

The question of why is a little harder to answer as it is often implicit form the context or unimportant from the software's perspective. For example, we may not need to understand why a particular sale was made beyond the fact that the buyer needed or wanted to make the purchase. Even if it would be nice to do so, it can be hard to elicit this sort of information. However, where we can and if we need to, the answer is provided by the purpose responsibility of the Moment-Interval class represented by a purpose attribute.

In some cases, the whole of a system revolves around a single kind of Moment-Interval but mostly there are several different kinds of Moment-Interval that need to be modelled. Some Moment-Intervals naturally follow others and the Moment-Interval classes of a system can be associated to each other in one or more flows of time. For example, a Moment-Interval modelling a Delivery would follow and be related to a Moment-Interval modelling the Sale for which the delivery is needed. When you consider that the name of a Moment-Interval class is often the noun form of a business activity or action (e.g. Sale - Selling, Rental - renting, Payment - paying, Approval - approving, etc.) it is not surprising to note that a flow of Moment-Intervals often models the structure of a business process with the other class archetypes providing the who, what and where of the process. In business process automation projects, modelling with class archetypes naturally follows from high-level business process modeling and tends to be more effective than purely modeling activity and action flow because the latter often suffers from many of the drawbacks of the 1970's practice of designing with flowcharts.

Adding the idea of a flow of related Moment-Interval classes over time by providing associations from a Moment-Interval to PriorMI and NextMI Moment-Interval classes, splitting the Party, Place, Thing archetype into its three flavours and repeating the connections in the previous diagram for each flavour leads us to the archetypal model template that Peter Coad called the Domain Neutral Component [Coad 99]. One important extra detail to note is that the Thing flavour of the Party, Place Thing class archetype typically connects to the MI-Details of a Moment-Interval rather than to the main Moment-Interval.

Domain Neutral Component (larger detailed image)

My version of the Domain Neutral Component differs from the Modeling in Color book in a few small ways due to preferences developed in using and teaching it over the last few years:

In the Modeling in Color book [Coad 99] the association between the MI Detail and the Thing Role is a many to many relationship. In practice I have found that it is far more often a many to one relationship and my version of the diagram reflects this.
The Modeling in Color book [Coad 99] has a planned-actual association linking objects of a Moment-Interval to itself. Although a valid pattern it is not one I have found useful in practice in anything like the frequency of the other parts of the diagram so I tend to leave it off while still recognising it as useful in certain circumstances.
I have omitted the plug-in points of the Modeling in Color book[Coad 99] from the diagram because they represent the application of design patterns at lower level than the rest of the Domain Neutral Component.

Using the DNC

The Domain Neutral Component can really help speed up the building of outline object models of our problem domains. The way we do this is to begin by looking for some Moment-Intervals in our problem domain. Then we overlay the Domain Neutral Component
More on using the DNC...

More on...