Peter Coad's 'Modeling in color' defines four archetypes. The first of these, the Moment-Interval class archetype, models something that occurs at a moment in time or over an interval of time. If it happens, it is pink!

The Moment-Interval class archetype is one of four class archetypes in Peter Coad's 'modeling in color' technique.

Peter Coad defines a Moment-Interval class as modeling 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].

For a class to belong to the Moment-Interval class archetype it must firstly be some recognisable instant (moment) in time or duration (interval) of time, an event or activity that we can give a name. However, this is not sufficient. The class must also be an moment or interval that we need to work with or remember in our field of endeavour (our problem domain). If the instant or period of time is not relevant to the domain that we are working in, then the concept is either not worth representing in our software or the concept, in our domain, belongs to a different class archetype.

Therefore, in a retail point of sale domain, a sale is a good example of some moment or instant in time that we need to remember. A rental in a car hire domain is a good example of some interval of time, the start and end of the interval are important in our problem domain. In contrast, the lifetime of a customer or employee is not an interval of time that we need to track or work with in either of these examples so we should not model customers or employees with Moment-Interval classes (we should model them with Role classes instead because they are ways in which people participate in our domain).

Figure 1: Moment-Interval Class Archetype with Moment-Interval Detail

When looking for Moment-Interval classes for a particular piece of software, we need to consider things like significant events and activities, business transactions, steps in a process, or interactions within a business relationship that are within the scope our software system, application, or component.

In business systems this means items such as sales, rentals, leases, authorizations to do or use something, and submissions, approvals and rejections of items like applications for loans, insurance claims, or licenses of various types. Other examples include planned or scheduled events such as the scheduled running of training courses, steps in a sales pipeline, or the tasks in a project plan.

For industrial systems we need to consider events like a change in the position of a switch, a sensor reading exceeding a specified limit, the push of a button on a control panel, and so on. We would also need to look for intervals such as that needed to spin or ramp up a piece of equipment to a particular speed, temperature or pressure, or the interval over which a set of sensor reading are taken, and so on.

In the classic board game, Cluedo (Clue in the USA), a key moment-interval is the killing of Dr. Black (or Mr. Boddy in the US version) by one of six characters in the game. We recognise the type of the moment-interval and refer to it as a murder and know it to have taken place just before the start of the game.

Like all four class archetypes in 'modeling in color', Moment-Intervals are assigned a specific color. Although, not essential, it is this color-coding that gives the technique its name and so much more effective as a means of communication than traditional UML-style diagrams. Moment-Interval classes are pink (pastel red).

Moment-Intervals represent happenings that take place that our software is interested in, interactions and business between people, places and things. In other words, if it happens, it is pink! Pink happens!

Moments or Intervals?

We only need one class archetype to represent both moments and intervals because the differences in typical responsibilities, operations, attributes and associations between a class modeling a moment in time and one modeling an interval of time are not significant.

In many cases we could model a moment in time as an interval quite happily. However, we do not because, in the case of something like a sale in a basic retail store, the difference in time between the start and end of a sale is not interesting. To model the sale as a interval would only add unnecessary complexity. In contrast, in a supermarket where the management might want to know measurements like the minimum, average, and maximum time it takes a cashier to process a trolley full of groceries, it might make sense to model a sale as an interval instead of a moment. Also, while a retail store may only need to record when sales transactions happen to the nearest second, a real-time industrial system we may need to know the exact millisecond that an event occurred.

For poor Dr. Black in the Cluedo game, we only need to know that the moment-interval of his murder has happened sometime in the very recent past, and from the game player's perspective there is no interest in how long the murder took. From Dr. Black's point of view, we hope it was instantaneous and not a long drawn out interval of time.

This level of imprecision in what we need to remember about when a moment-interval happens is one example of why we do not attempt to produce a super-class or Java/C#-style interface for all moment-intervals.

Nouns and Verbs

Like any other class, a Moment-Interval class should be named with a noun.

In most introductory books on object-oriented analysis and design, it is suggested that nouns in statements of requirements such as use case specifications are good candidates for classes. However, when hunting for Moment-Interval classes there are occasions when this is not sufficient and we also have to consider the verbs too. This is because the names of Moment-Interval classes often have a verb form that identifies an activity or a process that leads to the moment in time or is performed during the interval of time.

For example, an object of a Sale class is the result of a selling activity, and an object of a Rental class is related to the activity of renting. The noun approach could miss these Moment-Intervals if requirements statements are phrased like, "The customer is only allowed to rent a pre-selected make of car" or "The salesperson must not sell discounted products". The sale and rental appear as verbs in these requirements statements. Usually we get away with this because the related noun pops up in other related requirements statements like "The rental must not exceed two weeks" or "An invoice must be issued for every sale" but there is no guarantee that it will.

Prior and Next Moment-Intervals

The frequent relationship between Moment-Interval classes and activities in a process means that we can often arrange related Moment-Interval classes into one or more time-ordered sequences. For example, in a retail store a cashier may have to start a Session on a cash register before they can start recording a Sale.

We call Moment-Intervals that happen before or after a particular Moment-Interval, prior Moment-Intervals and next Moment-Intervals respectively. This is often shortened to prior MI and next MI for convenience.

In some cases, a prior Moment-Interval may need to exist before a Moment-Interval can take place. For example, a Sale Moment-Interval may be needed before a Delivery Moment-Interval can be performed. In these cases, it is reasonably obvious that objects modeling deliveries will need to be able to check that there is an associated sale object.

Figure 2: Some Cash Sale Moment-Intervals

In a more complex cases the relationships between Moment-Intervals are not a simple straight sequence. For example, in a training course management system, once a particular training course is scheduled, students can register to attend the course, and instructor assigned to teach the course. However, the course could be canceled or one or more students could pull out before attending. Also a different instructor could be assigned to teach the class for some reason. These next MI's can occur in different orders so instead of a sequence of Moment-Interval classes we connect the possible different next MI's directly to the main Moment-Interval class, the ScheduledCourse class in this example.

Figure 3: Some Training Course Management Moment-Intervals

In an industrial system such as a power generation plant, a complex spinning up process could move through a number of different intervals before the various bits of equipment are performing at the desired level. There are a number of similarities and subtle differences between a set of related Moment-Interval classes and the classic Gang of Four State design pattern.

The Moment-Interval Class Archetype and the GoF State Design Pattern...

Moment-Interval Details

Moment-Interval classes often need supporting detail classes because there might be multiple things of different kinds involved in the Moment-Interval that need to be recorded or worked with. For example, a sale in a retail store is likely to comprise a number of different quantities of different kinds of grocery item. In the case of a stereotypical software developer from the last century, the sale would probably include various quantities of cola, frozen pizzas, bars of chocolate, jars of coffee, and sugar, etc.

Therefore, as well as a Sale class the model will need a SaleDetail class that is related to the Sale class by a composition (whole-part) relationship. These Moment-Interval Detail classes (MI-Detail for short), typically remember information about the quantity of a particular type of object involved in the Moment-Interval, and can calculate the contribution that objects of that type make towards the Moment-Interval.

In general, MI-Detail objects occur at the same time as the parent Moment-Interval object. However, there can be exceptions. For example a single rental transaction could rent several items, some of which need to be returned before others. The end of the rental as a whole therefore coincides with the return of the final item.


Moment-Interval classes typically connect to role classes. These in turn connect to party, place or thing classes representing entities that may or may not play those roles. Then the party, place or thing (PPT) classes typically connect to Description classes that further categorise them. Theses links form the basic Domain-Neutral or archetypal model shape as shown below.

Basic domain

neutral or archetypal model shape

Figure 4: Basic domain neutral or archetypal model shape

Essentially, the shape provides for different kinds of party, place or thing to participate in recognised ways (roles) in some event or activity (moment-interval).

Complex moment-intervals such as commercial loan arrangements can involve a number of different parties or places participating in sophisticated ways. If not careful, the class representing the moment-interval can grow too large. One of the reasons the class may grow too large is a need to snapshot current information from role, PPT and Description classes to capture values at the time of the moment-interval.

Another reason might simply be significant amounts of constraints and calculations in the way a number of the PPT classes participate in the moment-interval.

One way to keep a moment-interval class to a manageable size is to ensure subsequent moment-intervals are split out into their own classes.

Another strategy is to split out Participation classes from the main moment-interval class. These are MI-Detail classes that sit between the main moment-interval class and a particular role class. Participation classes encapsulate the data and behaviour specific to the way a role participates in the main moment-interval. This might include any values from the role class or its role-player that need to be snapshot at the time of the moment-interval.

For example, in a loan arrangement domain, a Brokerage MI-Detail class could encapsulate all the data (current rate of commission, for example) and behaviour (calculate total commission, for example), and sit between the main LoanArrangement moment-interval class and the associated Broker role class.

Participation classes are a form of MI-Detail class because they take place at the same time as the main moment-interval. If a Participation class needs to track a begin or end date/time, then it is most likely better thought of as a subsequent or prior Moment-Interval.

When used to hold snapshot values, the participation class can easily act as a proxy retrieving current values from the associated role and role-player classes while the moment-interval is in progress or under construction. Then once the moment-interval is complete or cancelled, the participation class makes copies of the values and from then on returns the copied values when requested by the main moment-interval. This can significantly simplify the interface for the main moment-interval class. For example, the actual commission paid to a Cruise booking-agent may depend on a number of factors such as whether or not the customer shows up for the cruise or the cruise is canceled. Once the cruise is done the amount of the commission to be paid becomes fixed (see figure 5 )

Factoring out a participation calls

from a MI

Figure 5: Factoring out a participation calls from a MI

It is interesting to compare participation classes with the transaction classes from the Streamlined Object Modeling approach. Here separate transaction collaboration pattern player are snapped together to form a larger combined transaction. Participation classes essentially keep the individual transaction pattern players as individual classes and link them to a separate combined transaction class.

Typical Responsibilities

Like all the class archetypes, the usefulness of the Moment-Interval class archetype in reviewing and building object models is due to its typical responsibilities, and the lists of typical attributes, operations and associations that represent those responsibilities.

More on the typical attributes, operations and associations of Moment-Interval classes...

Two Flavors of MI

After a short while working with them, most people realize that Moment-Interval classes come in two general flavors: those that model a type of interaction between some combination of people, organisations, places and things, and those that track the changes over time to a value or set of values.

The reason there is only one class archetype for these two cases, is that the Moment-Interval classes tracking changes in value do actually represent one or more interactions between people, organisations, places and things. The difference is that the process of arriving at that value change is outside the scope of our system, and therefore the participants are not modeled in our software. This generally leaves a very simple Moment-Interval class associated to a single Thing or Description class.

For example, a Moment-Interval class called Price might track the change over time in the price of a particular product. This class will likely have a single, many-to-on association with the Product class. It looks very different from a Moment-Interval class used to track sales. Objects of this Sale class are likely to be linked to other objects modelling the customer, the store where the sale took place, and the products purchased.

However, a change of price to a product does not just happen, some business decision is made by someone, some informal or formal business process is followed to suggest, approve and implement the price change. It is simply that this process is not of interest to a basic Point-Of-Sales system; all it is interested in is the result of that process, the price change with its effective date.

If the scope of the Point-Of-Sales system were to expand to cover the price change process, the Price class would similarly expand to look more like the typical Moment-Interval class at the centre of the archetypal domain model.

The Class Archetype Previously Known As...

In Peter Coad's earlier books [Coad97] Moment-Interval classes were called Transaction classes because they tend to represent business transactions in business systems. Calling the archetype Business Transactions, however, is too specific because it excludes the events and activities in non-business software like industrial, engineering, scientific and real-time applications, and other software development tools.

Just calling the class archetype the Transaction archetype is also confusing because that term has a very specific, well-established meaning in the world of database management systems (DBMS). Some have suggested event-activity would be a better name but both event and activity are names that are already heavily used in the software industry.

There's not a moment to lose!
Captain Jack Aubrey, Royal Navy,
Patrick O'Brian's Aubrey and Maturin books

The Moment-Interval Class Archetype
Modeling in color defines four archetypes. The first of these, the Moment-Interval class archetype, represents significant interactions between people, places an things. If something happens and we are interested in it, it is usually an object of a Moment-Interval class.

Typical Responsibilities of Moment-Intervals
Like all the class archetypes in modeling in color, the true usefulness of the Moment-Interval class archetype in identifying and reviewing problem domain classes is due to its typical responsibilities, and the lists of typical attributes, operations and associations that represent those responsibilities.
Read more about this...

Historic Values
In business software it is often necessary to remember the values of objects at the time a business transaction took place. For example, the price of a product may change over time and it may be necessary to remember the price used in a sale of the product. There are two fundamentally different ways of satisfying this requirement and a good number of variations between the two extremes
Read more about this...

Moment-Intervals and GoF State Pattern
The Moment-Interval class archetype lists a status attribute as a typical attribute for this kind of class. The Gang of Four State pattern provides an alternative to a simple attribute for implementing state-driven behavior. In fact, there are a number of interesting comparisons and differences between the GoF State pattern and Moment-Interval classes that can be made.
Read more about this...

The Role Class Archetype
The Role class archetype is the second of the four class archetypes defined by the modeling in color technique. Role classes model a way of participation by a party (person or organization), place or, thing. We sometimes talk of people wearing more than one hat when they have multiple responsibilities. Roles model those hats.
Read more about this...

The Party, Place, Thing Class Archetype
The third of the four class archetypes defined by the modeling in color technique, is the Party, Place, Thing class archetype. These classes model someone or something who plays different roles. They are the role players. If Roles classes are the hats, then Party, Place, Thing classes are the hat wearers. If you can converse with it, pick it up, or stand in it, then it is likely to be an example of a party, place or thing.
Read more about this...

The Description Class Archetype
The fourth and last class archetype defined by the modeling in color technique, is the Description class archetype. This class archetype 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. It categorizes objects of other classes according to different values.
Read more about this...

Reference Number Attributes in Class Archetypes
Each of the four class archetypes has a set of attributes that we might typically expect to find in classes belonging to that archetype. In each case, this set includes some sort of reference number attribute. While they all might seem very similar, and serve similar purposes, some subtle differences exist.
Read more about this...

Accelerated Problem Domain Analysis
Peter Coad's 'Modeling in Color' technique uses the idea of class archetypes to build understanding of a problem domain quickly. Jeff De Luca's Feature-Driven Development approach defines a collaborative process that works beautifully with modeling in color. Domain experts and developers work together on a daily basis to build an overall, initial, 'just enough' domain model that is then used to build a much better initial product backlog or features list.
Read more about this...

FDD and 'modeling in color' Workshops
Help give your next software development project a better start, or correct the course of a wayward project. Now available in the USA, UK, and continental Europe.
Read more about this...

Model Archetypes and Domain Neutral Components
Linking together the typical associations between class archetypes presents us with a pattern of classes we call a model archetype or domain neutral component. We can display this with the Party, Place, Thing class archetype as a single class to give a basic model archetype. Alternatively we can explode the Party, Place, Thing class into its three flavors and produce a larger more comprehensive domain neutral component that is even more useful. Model archetypes can be used to rapidly build new problem domain models or review and revise existing problem domain models.
Read more about this...

Class Archetypes, UML and Color
Class archetypes can be used without the color coding quite happily. Color can be used to highlight items in diagrams with great effect without the use of class archetypes. The combination of the two, however, provides a much deeper means of communication. The color-coding 'layers' into the diagram. It provides a means to quickly and effectively engage with a non-trivial diagram.  You can 'step back' from the diagram and examine the patterns of linked colored classes, 'zooming in' on textual detail as needed. After modeling in color for a while, you wonder how you were ever satisfied with black and white diagrams.
Read more about this...

From UML Association to the Domain Neutral Component
Karl Frank and I were in Denver, USA, giving a modeling in color workshop for a client. One evening Karl asked me what if any relationship I thought there was between roles in the Domain Neutral Component (DNC) and role labels on a UML association. The subsequent discussion sparked a train of thought that further convinced me of the simple, effectiveness of using the domain neutral component.
Read more about this...

Follow me on Twitter...