Moment-Interval Class Archetype: Typical Responsibilities

The moment-interval class archetype with typical attributes, operations and associations

Typical Attributes

The typical attributes of Moment-Interval classes include:

The referenceNumber Attribute

Moment-Intervals usually need the capability to be matched with a paper document. We typically do this by printing a unique string of characters on the paper artifacts and making Moment-Interval objects responsible for remembering that same string of characters.

For example, a Moment-Interval class representing a sale must be able to be matched with the receipt or invoice issued for that sale. Therefore we include a receiptNumber or invoiceNumber attribute in our Sale class and ensure that it is included on any receipts or invoices printed for that Sale.

The receiptNumber or  invoiceNumber are more specific names for a reference number. Therefore, the referenceNumber attribute of the Moment-Interval class archetype reminds us that whenever we identify a Moment-Interval class we should ask whether it or not it needs some sort of reference number attribute and related accessor method. Our software is normally required to generate the value for the reference number of a new moment-interval object, and once set it is not normally ever changed. Therefore, it is not usual to need a modifier method for a referenceNumber attribute.

The referenceNumber attribute is an example of an identification responsibility. All the class archetypes have a similar typical responsibility but there are some subtle differences between them. More on identification responsibilities...

Related Operations: None
Related Associations: None

The dateOrDateTimeOrInterval Attribute

Obviously, because we are modelling some moment or interval of time, we are highly likely to need to remember when the moment-interval occurred. Although obvious the dateOrDateTimeOrInterval attribute reminds us that Moment-Interval classes are responsible for recording the necessary date and time information about when their moment or interval occurs. 

The dateOrDateTimeOrInterval attribute also reminds us to ask exactly what needs to be remembered in this respect. For example a Moment-Interval class representing a car rental is responsible for remembering both the start and end date and time of the rental. In contrast, a Moment-Interval class representing a cash sale is likely to only be responsible for remembering a single date and time value, the date and time the sale was made. The time of day the sale was made might only need be accurate to the nearest minute. However, the time that a sensor reading changed in an industrial system might need to be accurate to the nearest millisecond. 

Despite these differences we can safely say that we would typically expect to find one or more attributes and related accessor and modifier operations in a Moment-Interval class for recording the date or time information.

Related Operations: complete, cancel
Related Associations: None

The purpose Attribute

Related role and role-player classes answer the who, where and with what of a Moment-Interval but it is typically left to the Moment-Interval itself to answer why. For example: Why is this loan required? Why does the purchaser want this service? Why are we holding this meeting?

Sometimes we do not really care why a Moment-Interval is happening or it is too hard to collect the reason for a Moment-Interval. For example, in a simple cash sale in a supermarket the point of sale system does not really need to know why a person is buying what they are buying. Even if management would like that information it is unlikely that a customer will want to spend the time giving that information to the cashier. The people waiting in the queue behind them certainly will not want them to do so.

In some cases the Moment-Interval class itself is so specific that it provides the purpose information by definition. For example, the purpose of a CarLoan class is likely to be to purchase a car.

The modelling in colour book [Coad99] does not list purpose as a responsibility of a Moment-Interval class but as it has appeared many times in practice I have added it to my list. Therefore, I am never surprised when a Moment-Interval class defines a text-based attribute, an attribute that takes an enumerated value, or a mixture of both, with suitable accessor and modifier operations to record the purpose of the Moment-Interval.

Related Operations: cancel
Related Associations: None

The priority Attribute

Not all objects of the same Moment-Interval class are necessarily equal in importance. Some are have higher priority than others. Some need to be processed, reviewed, or completed before others. In these situations, it is the responsibility of our Moment-Interval objects to know how important they are in relation to each other. Therefore we should expect to find we frequently need some sort of priority attribute and related accessor and modifier operations in our Moment-Interval classes.

Related Operations: None
Related Associations: None

The status Attribute

Moment-Intervals frequently represent events and activities that have some sort of life cycles. These can be as simple as a basic three state life-cycle of in progress, completed, or canceled. On the other hand, they can be complex life-cycles involving loops, concurrent sub-states, and conditional branches.

Remembering current and previous states, and enabling and enforcing valid transitions from one state to another is therefore a typical responsibility of a Moment-Interval class. At a minimum we expect some sort of status attribute and a number of state-change operations such as complete() and cancel() to appear in Moment-Interval classes. Alternatively, we could end up with an implementation of the state design pattern [GoF].

Related Operations: complete, cancel
Related Associations: None

The total Attribute

Calculating various totals and performing other aggregating calculations is also a typical responsibility of objects of Moment-Interval classes. A Sale class representing sales comprising of a number of different items is responsible for calculating the total of the sale, the total tax to be paid, and so on. A Moment-Interval class representing a scan of a set of sensors in some industrial system might also be responsible for calculating maximum, average and minimum values for the set of sensor readings.

Once a Moment-Interval is finished, these calculated totals usually only change in error correction scenarios and those are hopefully infrequent. Therefore , the result of the calculations can be stored in one or more total attributes rather than recalculated each time the value is needed. 

Alternatively, a total could be built up in a more event-driven way. For example, instead of waiting until all the different items have been added to an object of the Sale class and then calculating the total, we could instead update the total attribute as each item is added.

Related Operations:  calculateTotal
Related Associations: Moment-Interval - MI-Detail

Typical Operations

The typical operations of Moment-Interval classes include:

The addRemoveDetail Operation

A Moment-Interval often has sets of related detail objects that we call Moment-Interval Details or MI-Details for short.  For example, an order object is likely to have one or more line item objects associated with it. Therefore we should expect some operations to manage the collection of details including adding and removing details from the Moment-Interval. The addRemoveDetail operation in the Moment-Interval class archetype serves as a reminder of this.

Related attributes:  None
Related associations:  Moment-Interval - MI-Detail

The calculateTotal Operation

Calculating various totals and performing other aggregating calculations is a typical responsibility of objects of Moment-Interval classes. A Sale class representing sales comprising of a number of different items is responsible for calculating the total of the sale, the total tax to be paid, and so on. A Moment-Interval class representing a scan of a set of sensors in some industrial system might also be responsible for calculating maximum, average and minimum values for the set of sensor readings. We can, therefore, expect to find one or more calculateTotal() kinds of operation in a Moment-Interval class.

It is often more efficient to cache the result of a calculateTotal() operation in an attribute within the Moment-Interval so that we do not have to perform the calculation each time we need to use the value of the result. It can be useful, therefore, to code the calculateTotal() to first check to see if the result is stored in some sort of  total attribute and only preform the actual calculation if the result does not exist. If the calculation is performed the result is stored in the total attribute and in both cases the value of the total attribute is returned to the caller.

Note: There are times when you might want to force the recalculation of the total and a recalculateTotal() operation is also needed. The other problem with this approach is that it changes the calculateTotal() operation from a query function to one that modifies the contents of  the Moment-Interval object. This can cause confusion in a transactional system because the user is expecting to only need read-only access to the Moment-Interval to acquire the total. It may be possible to make the total attribute transient but in most cases doing this will reduce the use of the cached value too much because the value will be lost each time the Moment_Interval object is moved out of memory onto disk . In a transactional system, therefore, it may be easier to add an accessor method that can be used to simply retrieve the value of the total attribute. This can be used whenever it is known that the value has been calculated without having to worry about whether the Moment-Interval needs to be writable or not.

Related Attributes: total
Related Associations:  Moment-Interval - MI-Detail, Moment-Interval - NextMI

The complete Operation

The complete operation reminds us to check if we need operations to mark the successful conclusion of a moment or interval. At a minimum we may need to set the end date or time of an interval. We may also need to set a status attribute to indicate that the moment or interval has successfully completed.

Where a Moment-Interval has a set of complex MI-Details objects, we may need to iterate across these and perform some sort of complete() operation on each of them. We would need to do this if the MI-Details:

• has some sort of status attribute of its own,
• needs to copy information from an associated class of another class archetype to remember what that information was at the time of the Moment-Interval. For example, a line item object may need to remember the unit price, and any discounting information at the time of the order  if  an associated product only holds current pricing information.
• needs to confirm (commit) resources that it has requested (locked) while in the Moment-Interval was in progress. For example, a MI-Detail object modeling a particular type of room reservation in a hotel block booking Moment-Interval may need to commit to the number of rooms of that type that it might have tentatively allocated while the Moment-Interval was in progress.

If we need to capture a significant amount of information about the completion of a moment or interval  then we may want to model that as a separate next Moment-Interval class. For example, if we load or hold a significant number of incomplete moments or intervals in memory, defining significant amounts of information about completion in the main Moment-Interval class could waste a considerable amount of memory and slow down loading times.

Related attributes: dateOrDateTimeOrInterval, status
Related associations: Moment-Interval - NextMI, Moment-Interval - MI-Detail

The cancel Operation

The cancel operation reminds us to check if we need operations to mark the unsuccessful conclusion or aborting of a moment or interval. Just as for the complete() operation, we may need to set the end date or time of an interval. We may also need to set a status attribute to indicate that the moment or interval has successfully completed.  

Where a Moment-Interval has a set of complex MI-Details objects, we may need to iterate across these and perform some sort of complete() operation on each of them. We would need to do this if the MI-Details:

• has some sort of status attribute of its own,
• needs to copy information from an associated class of another class archetype to remember what that information was at the time of the Moment-Interval. For example, a line item object may need to remember the unit price, and any discounting information at the time of the order  if  an associated product only holds current pricing information.
• needs to release resources that it has requested (locked) while in the Moment-Interval was in progress. For example, a MI-Detail object modeling a particular type of room reservation in a hotel block booking Moment-Interval may need to release the number of rooms of that type that it might have tentatively allocated while the Moment-Interval was in progress.

If we need to capture a significant amount of information about the cancellation of a moment or interval  then we may want to model that as a separate next Moment-Interval class. For example, if we load or hold a significant number of moments or intervals in memory, defining significant amounts of information about cancellation in the main Moment-Interval class could waste a considerable amount of memory and slow down loading times. In these cases, the reason for the cancellation often needs to be captured and this would map to the purpose attribute of the next Moment-Interval class.

Related attributes: dateOrDateTimeOrInterval, status, purpose
Related associations: Moment-Interval - NextMI, Moment-Interval - MI-Detail

The generateNextMI Operation

The generateNextMI() operation is an example of the Gang of Four factory method design pattern. It represents operations that create, initialise and associate related Moment-Interval objects that occur subsequently to this Moment-Interval object. For example, in an internet or mail order processing system, there might be a generateDelivery() operation in an Order class that creates an instance of a Delivery class, initialises the Delivery object with information derived from the Order object and associates the Order object with the Delivery object..

Related attributes: None
Related associations: Moment-Interval - NextMI

The assessWRTPriorMI Operation

One of the typical responsibilities of a Moment-Interval object is to make some sort of assessment about its performance with respect to prior Moment-Interval. For example, if the previous Moment-Interval was some sort of planned activity and this Moment-Interval the actual activity, an assessment operation to check whether this Moment-Interval was performed to plan would be typical. Another example might be a series of Moment-Intervals modeling bookings for a show and a subsequent Moment-Interval modeling the performance of the show itself with an assessWRTPriorMI() operation that assesses what percentage of people who made bookings actually turned up to see the show.

Related attributes: None
Related associations: Moment-Interval - PriorMI

The assessWRTNextMI Operation

The converse of the assessWRTPriorMI(), this operation reminds us that one of the typical responsibilities of a Moment-Interval object is to make some sort of assessment about its performance with respect to subsequent Moment-Interval. For example, if the previous Moment-Interval was some sort of planned activity and this Moment-Interval the actual activity, an assessment operation to check whether this Moment-Interval was performed to plan would be typical. Another example might be a series of Moment-Intervals modeling bookings for a show and a subsequent Moment-Interval modeling the performance of the show itself with an assessWRTPriorMI() operation that assesses what percentage of people who made bookings actually turned up to see the show.

Related attributes: None
Related associations: Moment-Interval - NextMI

The listInstances Operation

The listInstances() operation is a class scope operation. It reminds us that a typical responsibility of a Moment-Interval class, like those of any of the class archetypes, is to be able to search for, find, and list subsets of its instances that match some set of criteria.

Related attributes: None
Related associations: None

The assessAcrossInstances Operation

The assessAcrossInstances() operation is a class scope operation. It reminds us that a typical responsibility of a Moment-Interval class, like those of any of the class archetypes, is to be able to assess the performance of a subset of its instances that match some set of criteria.

Related attributes: None
Related associations: None

Typical Associations

The typical attributes of Moment-Interval classes include:

The Moment-Interval - MI-Detail Composition

A Moment-Interval often has sets of related detail objects that we call Moment-Interval Details or MI-Details for short. For example, an order will often comprise several line items and would be modelled as an Order class with a composition association to a LineItem class. Similarly a flight may comprise several legs (e.g. London  to New York,  New York to Dallas, Dallas to San Francisco) and be modelled as a Flight class with a composition association to a FlightLeg class.

Related attributes: None
Related operations: addRemoveDetail, calculateTotal, complete, cancel

 The Moment-Interval - Party Role Association

This association reminds us to consider if we need to consider who is involved in a moment or interval and in what ways.  For example, at  who is the seller and who is the buyer in a sale, or who is the applicant  in a loan application.

This type of association is replicated for each different participant in the Moment-Interval that we need to track. However,  the need to track, is an important qualification. For example, for a simple point-of-sale system in a basic retail store, unless there is some sort of loyalty card scheme in operation., we are not likely to be able to capture much about a customer even if we have a reason to. In this example, we would not include this kind of participant in the model.

In other cases,  one of the parties involved is implied. For example, in a straight-forward  loan application system, the lender is normally the organization that is running the system and is the same for all the loan applications. There is no need to explicitly link each loan application to an object representing the role of the organization as a lender; the link is implied. However, we may want to link each loan application to the member of staff that represented the organization in the preparation of the loan application.

Related attributes: None
Related operations: None

The Moment-Interval - Place Role Association

This association reminds us to consider if we need to remember where the moment or interval took place.  For example, at what branch of the bank a loan was applied for, or which shop in a retail chain was a product bought at.

Generally, a Moment-Interval has one associated place. However, there is a common exception where a Moment-Interval represents a movement of someone or something.  For example, a flight,  a taxi ride, a delivery, a shipment, etc. In these cases, we need to know origin and destination. Sometimes theses are no more than a street address and can be held in an attribute of the Moment-Interval. Sometimes, however, we need two associations to place Role objects to model the start and end points of the journey.

The place Role class provides the Moment-Interval with a view of a place that is specific to it. It may also hold extra information that is specific to the role that the place is playing in the Moment-Interval. It can hide details of the place that are not relevant to the Moment-Interval. If, however, a Place class is only playing one role in a system then defining a separate Place Role class may be overkill. In these cases, the Place Role class can be dropped and the Moment-Interval connected directly to the relevant Place class.

In some examples, where a kind of Moment-Interval takes place is either not important, is derivable from a prior Moment-Interval, or is implicit in the kind of Moment-Interval. In these cases, the association is not included in the model.

Related attributes: None
Related operations: None

The MI-Detail - Thing Role Association

This association reminds us to consider what things are involved in the moment or interval.

The thing Role class provides the Moment-Interval with a view of something that is specific to it. It may also hold extra information that is specific to the role that thing is playing in the Moment-Interval. It can hide details of the thing that are not relevant to the Moment-Interval. If, as is commonly the case, a Thing class is only playing one role in a system then defining a separate Thing Role class may be overkill. In these cases, the Thing Role class can be dropped and the Moment-Interval connected directly to the relevant Place class.

In some examples,  we are not interested in tracking individual things. Instead we are interested in tracking a quantity of a type of thing. For,example,  in a sale of potatoes we are not usually interested in precisely which potato was sold in transaction. What we are usually interested in, is how heavy the quantity of potatoes was in each transaction. IN these cases, we can drop the Thing Role and Thing classes from our model and connect the MI-Detail directly to the Thing Description class.

Also, note, that where there is no need for MI-Details in a model we may connect the Thing Role, Thing or Thing Description classes directly to the Moment-Interval class as appropriate. However, this is not typical because the need for MI-Details objects is usually driven from the need to connect different kinds of things to a Moment-Interval and the absence of MI-Detail classes is usually because there are no things involved in the Moment-Interval.

Related attributes: None
Related operations: None

The Moment-Interval  - PriorMI Association

This association reminds us to consider whether there are other types of related Moment-Interval that happen before the one we are considering.

Related attributes: None
Related associations: None

The Moment-Interval - NextMI Association

This association reminds us to consider whether there are other types of related Moment-Interval  that happen after the one we are considering.

Related attributes: None
Related associations: None