The Moment-Interval Class Archetype

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 modelling 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 to which 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).

 

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.   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 modelling a moment in time and one modelling 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-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 rents a car" or "The salesperson must not sell discounted products". Usually the related noun pops up in other related requirements 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 sequences in the order in which they occur. For example, in a retail store a cashier may have to start a session on a cash register before they can start recording sales.   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 modelling 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. Figure3: 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.

 

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...

 

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 software development tools like Borland Together.

 

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. 

 

The Other Class Archetypes

In addition to the Moment-Interval Class Archetype, Peter Coad defines three other class archetypes:

• 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.