Like all the class archetypes in 'modeling in color', the usefulness of the Moment-Interval class archetype in and building object models is due to its typical responsibilities. The list of typical attributes represent the typical values that objects of this class archetype remember about themselves. The list of typical operations represent the typical questions that objects of this class archetype can answer and the services that they typically provide.The list of typical associations represent the other objects that objects of this class archetype typically know about and collaborate with.
Figure 1: The Typical
Responsibilities
of a Moment-Interval
Typical Attributes
Moment-Interval objects have items of data that they are typcially responsible for remembering. These include remembering a unique reference numbers for the moment-interval, the dates and times that the moment-interval occurs, the reason why the moment-interval is happening, how important it is relative to other moment-intervals, the current status of the moment-interval, and any totals calculated for the moment-interval.The typical attributes (usually implemented as properties in languages such as Java, C# and Objective-C) of the Moment-Interval class archetype remind us to consider these responsibilities when defining a Moment-Interval class.
| Name |
Description |
Related
Operations |
Related
Associations |
|---|---|---|---|
|
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 in some sort of reference number attribute. Examples are receipt and invoice numbers. |
None |
None |
|
|
Obviously, because we are modeling 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. |
None |
||
|
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? |
None |
||
|
|
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. |
None |
None |
|
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. |
None |
||
|
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. |
Typical Operations
The typical operations of Moment-Interval classes include:
| Name |
Description |
Related Attributes |
Related Associations |
|---|---|---|---|
|
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. |
None |
||
|
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. |
|||
|
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. |
|||
|
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. |
|||
|
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. |
None |
||
|
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. |
None |
||
|
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. |
None |
||
|
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. |
None |
None |
|
|
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.
|
None |
None |
Typical Associations
The typical attributes of Moment-Interval classes include:
| Name |
Description |
Related
Attributes |
Related
Operations |
|---|---|---|---|
|
Moment-Interval - MI-Detail |
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. |
None |
|
|
Moment-Interval -
Party Role |
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. |
None |
None |
|
Moment-Interval - Place Role |
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. |
None |
None |
|
MI-Detail - Thing Role |
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. |
None |
None |
|
Moment-Interval - PriorMI
|
This association reminds us to consider whether there are other types of related Moment-Interval that happen before the one we are considering.
|
None |
|
|
Moment-Interval - NextMI
|
This association reminds us to consider whether there are other types of related Moment-Interval that happen after the one we are considering. |
None |