The Moment-Interval Class Archetype
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].
This article can also be viewed as a Google Knol
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 endeavor (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 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).
|
Therefore, when looking for Moment-Interval classes 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 and approvals or rejections of 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 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, the interval over which a set of sensor reading are taken, and so on. Moments or IntervalsWe 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 of no interest and 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. |
 Moment-Interval Class Archetype
with Moment-Interval Detail
|
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.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 the deliveries will need to be able to check that there is an associated sale object.
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 also be canceled or one or more students 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 poosible different next MI's directly to the main Moment-Interval class, the ScheduldeCourse class in this example.
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.
More on Moment-Intervals and the 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.
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.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 typical responsibilities of Moment-Interval classes...
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.
More on typical responsibilities of Moment-Interval classes...
More on the typical attributes, operations and associations of Moment-Interval classes...