Modelling in Colour: Typical Responsibilities

Classes belonging to each of the particular class archetypes tend to have similar responsibilities. Therefore, for each class archetype we can build up a list of typical responsibilities. Once we have these lists we can use them as checklists for responsibilities of classes in our own problem domain object models. For example, if we know a Moment-Interval class typically has a responsibility to remember when the Moment-Interval occurred, when we create a new Moment-Interval class in our own problem domain object models we immediately know to ask what date and time information objects of the class need to hold.

The checklists of typical responsibilities for the class archetypes help us clarify requirement details and may identify missing requirements. For example, if we have a Priority responsibility on our checklist for Moment-Interval classes we can ask domain experts and check requirement sources to see if we need that responsibility in any of the Moment-Interval classes in our own problem domain model.

Responsibilities of the Moment-Interval class archetype

The typical responsibilities of Moment-Interval classes include:

1. Identification: typically the ability to be matched with a paper document such as a receipt, invoice, application form or legal contract.
2. Date and Time: remembering when the Moment-Interval occurred.
3. Purpose: recording why the Moment-Interval has happened.
4. Priority: knowing how important a Moment-Interval is in relation to others.
5. Status: knowing which of a finite number of states or modes the Moment-Interval is in at any given time and the rules for switching states or modes.
6. Calculation of Totals: knowing how to calculate various totals.
7. Assessment: interacting with prior and subsequent Moment-Interval objects to assess performance in some way.
8. Factory: creating objects of subsequent related Moment-Intervals.
9. Collaboration: knowing objects of other class archetypes representing the who, where and with what of the Moment-Interval.

Responsibilities of the Role class archetype

The typical responsibilities of Role classes include:

1. Authorization: remembering the authorization code, license number, and associated information that allows the role-player to perform this role.
2. Status: determining whether its role player is available and able to play this role for a particular Moment-Interval.
3. Assessment: assessing the role player's performance across a set of Moment-Intervals in which they have participated in this role.
4. Collaboration: knowing its role-player and the sets of Moment-Intervals in which it has participated or is participating.

Responsibilities of the Party, Place, Thing class archetype

The typical responsibilities of Party, Place, Thing classes include:

1. Identification: being able to be matched with their real-world counterpart.
2. Custom Values: remembering characteristics of individual parties, places and things that differ from standard or default values.
3. Role management: ensuring the set of roles played at any one time is legal and valid.
4. Collaboration: knowing the Roles which it has played or is playing and any Descriptions that categorise it and provide default values and behaviour.

Responsibilities of the Description class archetype

The typical responsibilities of Description classes include:

1. Identification: remembering external and internal identifiers for categories of described object.
2. Default Values and Behaviour: remembering the default values for properties of the objects it describes and providing default behaviour for those objects.
3. Searching: finding one of the objects they describe including finding ones that are free to play a particular Role in a particular Moment-Interval.
4. Assessment: assessing the performance of the set of described objects as they play their different roles in various Moment-Intervals.
5. Collaboration: knowing the sets of Party, Place, Things or Moment-Intervals that they describe.

Rebecca Wirfs-Brock defines a software responsibility as an obligation to perform a task or know information [Wirfs-Brock]. Peter Coad used to talk about operations of a class being what objects of that class did, the attributes of a class being what objects of that class knew about themselves, and the associations of a class being who, in terms of other objects, objects of that class knew [Coad97]. In other words, the responsibilities of an object are eventually expressed as a combination of operations, attributes and associations defined for that type of object. So when we say that we notice similar responsibilities appearing in our object models we usually mean that similar kinds and mixtures of operations, attributes and associations are turning up again and again. It also means that when we say a class will typically have a certain responsibility, we imply that the class will typically need to have a certain set and mixture of operations attributes and associations.

In practice, after building a few models, most people find it easier to remember the typical operations, attributes, associations of class archetypes than lists of responsibilities for each class archetype. Our checklists therefore become lists of typical operations, associations and attributes that act as reminders or placeholders for the typical responsibilities of each class archetype.

Common Class Level Responsibilities

There are a couple of class-level responsibilities that are common regardless of which archetype a class belongs. They are:

1. List Instances Responsibility
   In our initial problem domain models we assume that a class belonging to any of the archetypes knows about all the instantiated objects of that class. One of the responsibilities of any class belonging to any of the class archetypes, therefore, is to create various lists of its objects according to different specified criteria. This includes being able to locate a particular object of that class by some sort of unique reference identifier if one exists.
   
   Therefore, we would expect to find one or more operations named something like listInstances() in any class belonging to one of the class archetypes.
   
   
2. Assess Across Instances Responsibility
   Not only is a class responsible for listing its objects, it is also responsible for making performance assessments for sets of its objects. This is typically done by invoking an assessment service on each object in turn and aggregating the results.
   
   Therefore, we would expect to find one or more operations named something like assessAssessInstances() in any class belonging to one of the class archetypes.

Details of Common or Similar Responsibilities

Identification/Authorisation

Objects of any class archetype frequently need to be matched with the artifacts that represent them in the real problem domain.

For Moment-Intervals this typically means they need to be able to identify themselves with one or more paper documents. For example, a Moment-Interval class representing a sale must be able to be matched with the receipt or invoice issued for that sale. 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 the case of the sale, we would normally call that string of characters the invoice or receipt number.

To perform the duties or obtain the privileges of a role, a person, place or thing often requires some sort of authorisation. Where the authorisation process is outside the scope of our problem domain, a Role class becomes responsible for remembering the authorization code, license number, and associated information. For example, objects of a Pilot class might be responsible for remembering the pilot's license number of the person playing that role. Another example is a username or user id for a SystemUser role. In this case, not only does the existence of a valid username and user id authorise the role-player to use the system, it also serves as a means of matching a person using the system with the role object that represents a way they participate in the system. This dual purpose is typical of this sort of information in Role classes.

Party, Place, Things are also responsible for being able to be matched with their real-world counterpart. For Things this normally means remembering a serial number of some sort. For Places this is often an address, lot or bin number, or set of coordinates of some kind. For organizations there is normally some legally required registration number that can be used. However, when it comes to uniquely identifying for people, we can rapidly find ourselves in a quagmire of political correctness, regulations, and policies and have to be a little more careful.

Like the objects they describe, the individual categories represented by Description objects frequently have unique identification codes or numbers. They also often have names and longer textual descriptions to supplement the codes or id numbers. Descriptions frequently have two kinds of identification number, one that is set by an external standards body, regulatory agency, or manufacturer and one that is assigned internally within an organisation. These two types of identity number are analogous to the manufacturers' identifier and the catalogue entry number for a particular item within a product catalogue respectively.

Therefore, we expect that classes belonging to our four archetypes will define one or more attributes with suitable accessor and modifier operations to implement their identification responsibility. For example, we would expect a Moment-Interval class to have some sort of referenceNumber attribute, a Role class to have some sort of assignedNumber attribute, a Party, Place, Thing class to have some sort of identityNumber, and a Description class to have both some sort of type attribute and some sort of itemNumber attribute to model external and internal identifying numbers respectively. We would also expect a Description class to have some sort of description attribute so its objects can hold a longer textual explanation of the category they are describing.

More on identification responsibilities...

Status

Objects of both Moment-Interval and Role classes frequently have a responsibility to remember which of a number of states or modes they are in at the current time.

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 involving loops, concurrent substates, 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 many Moment-Interval classes. Alternatively, we could end up with an implementation of the state design pattern [GoF].

The status responsibility of a Role class is usually simple. Typically a Role class is responsible for determining whether its role player is available and able to play this particular role for a given Moment-Interval. A role-player might be so busy with other Moment-Intervals that they are unable to participate in another at the moment. Alternatively the role player may have stopped playing the role or been forbidden to play the role temporarily for some reason. In some cases, the role player may not be qualified to participate in a particular Moment-Interval. For example, a role player may not be senior enough to play the role of approver of loan applications for over a certain amount of money.

We, therefore, expect some sort of status attribute and some sort of isAvailable() operation to be required by many of our Role classes.

Assessment

Moment-Interval classes are often related to other Moment-Interval classes that happen before or after them in time. Therefore objects of Moment-Interval classes are typically responsible for interacting with prior and subsequent Moment-Interval objects to assess their performance in some way. Operations called assessWRTPriorMI() and assessWRTNextMI() act as reminders for these responsibilities (WRT is short for with respect to). Originally these were called mi_assessWRTPrior() and MI_assessWRTNext(). However, the MI_ prefix contradicts most modern naming standards and conventions. I prefer to use the more conventional MI suffix for operations that remind us of responsibilities involving next and prior Moment-Intervals

A Role class is also typically responsible for assessing the role player's performance across a set of Moment-Intervals in which they have participated. The set of Moment-Intervals over which the assessment is made is often those that have occurred within a particular time-period such as a week, month, quarter, or accounting year. We therefore expect to often need some sort of assessAcrossMIs() operations in our Role classes.

A Party, Place, Thing class is also typically responsible for assessing the role player's performance across all the roles they play and expect some sort of assessAcrossRoles() operations in many of our Party, Place, and Thing classes.

A Description class is also typically responsible for assessing the performance of the set of described objects as they play their different roles in various Moment-Intervals so some sort of assessAcrossPPTs() operations are likely to be needed in our Description classes.

Collaboration

Moment-Intervals are typically responsible for remembering who was involved and how, where, and with what when the Moment-Interval happened. Therefore, Moment-Intervals are typically required to collaborate with related Role classes and therefore we can expect associations between Moment-Interval classes and Role classes.

A Role class is typically expected to know which Moment-Intervals the role-player has participated in that role. Therefore, we should expect to find some sort of listMI() operations in our Role class and associations between Role classes and related Moment-Interval classes.

A Party, Place, and Thing object needs to know and manage the set of Roles that it is playing. Therefore we can expect associations between Party, Place and Thing classes and related Role classes. We can also expect associations between Party, Place, and Thing classes and Description classes that provide common, standard and default values and behaviour for objects of the Party, Place, and Thing classes.

Description objects typically need to know and the set of Party, Place, Thing objects that they are describing so we expect associations between Description classes and related Party, Place and Thing classes.

Factory

Moment-Intervals are often responsible for creating objects of subsequent related Moment-Intervals.

Typical Operations, Attributes and Associations

The typical responsibilities of each of the class archetypes leads us to the following lists of typical operations, attributes, and associations:

This table is not particularly easy to remember. It would be better if we had some more concise, graphical way of representing this information.

Class Archetypes and UML

UML is the most popular industry standard for representing object-oriented analysis and design ideas in graphical form. Therefore, if we are building problem domain object models and want to use class archetypes, it is highly likely we will want a way to indicate the class archetype of a class in UML.
More about Class Archetypes and UML...

More on...

• Layers of classes...
  
  
• The JMCU book and the history of modelling in colour...
  
  
• Typical responsibilites, operations and attributes...
  
  
• Colour coding class archetypes...
  
  
• Model archetypes and the DNC....
  
  
• Using the domain neutral component...
  
  
• From UML assocaition to DNC...