Typical Responsibilities of Role Classes

The typical responsibilities of Role classes expressed as typcial attributes, operations and associations.

The Role class archetype is one of four class archetypes in Peter Coad's 'modeling in color' object-oriented analysis and design technique.

A Role class models a way of participation by a party (person or organization), place or, thing. [Coad99]

Like all the class archetypes in 'modeling in color', the usefulness of the Role 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.

Role typical responsibilities
Figure 1: The Typical Responsibilities of a Role

Typical Attributes

Like all four of the class archetypes, Role objects have items of data that they are typcially responsible for remembering. These include remembering any assigned identifying numbers for the role, and the status of that role.

The typical attributes of the Role class archetype remind us to consider these responsibilities when defining a Role class. The actual attributes that they inspire are usually implemented as properties in languages such as Java, C# and Objective-C.

Name	Description	Related Operations	Related Associations
assignedNumber	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 or license number, and associated information. For example, objects of a Pilot class might be responsible for remembering the pilot 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.	None	None
status	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.	isAvailable	None

Name

Description

Related Operations

Related Associations

assignedNumber

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 or license number, and associated information. For example, objects of a Pilot class might be responsible for remembering the pilot 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.

None

status

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.

isAvailable

None

Typical Operations

The typical operations of Moment-Interval classes include:

Name	Description	Related Attributes	Related Associations
isAvailable	One of the common responsibilities of a Role class is to determine whether it is in a fit state to participate in a particular Moment-Interval. For example, an IT support person may not be available to handle a reported problem because he or she is busy on a previous or more importantproblem. This should be indicated by the result of invoking an isAvailable() operation on the Role object representing that IT support person.	None	Role - Moment-Interval
listMIs	This operation reminds us to check to see if a Role class needs any operations that return subsets of the Moment-Intervals in which the Role participates. These operations may take a set of criteria as parameters that define the subset of Moment-Intervals that should be returned.	None	Role - Moment-Interval
assessAcrossMIs	Role classes are frequently responsible for performing some sort of assessment across the lists of Moment-Intervals in which they have participated. The assessAcrossMIs() operation in the Role class archetype is a reminder of that typical responsibility.	None	Role - Moment-Interval
listInstances	The listInstances() operation is a class scope operation. It reminds us that a typical responsibility of a Role 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
assessAcrossInstances	The assessAcrossInstances() operation is a class scope operation. It reminds us that a typical responsibility of a Role 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
Role - Moment-Interval	Since a Role is a way something participates, there is typically associations between a Role and the Moment-Intervals in which it participates.	None	isAvailable listMIs assessAcrossMIs
Role - Party, Place, Thing	A Role is a way in which someone, some place or some thing participates, so there is typically an association from the Role to the Party, Place, Thing class that is playing the role. Roles often provide a view of the role-player that is customised for the Moment-Intervals in which the Role participates. For example, a Role might contain proxy operations for those of its role-player that are used by the Moment-Interval so that the Moment-Interval classes do not need to know anything about the role-player class itself. The Role class will also typically have attributes for information about the role-player that is only relevant when that role is being played.	None	None

Name

Description

Related Attributes

Related Operations

Role - Moment-Interval

Since a Role is a way something participates, there is typically associations between a Role and the Moment-Intervals in which it participates.

None

isAvailable

listMIs

assessAcrossMIs

Role - Party, Place, Thing

A Role is a way in which someone, some place or some thing participates, so there is typically an association from the Role to the Party, Place, Thing class that is playing the role.

Roles often provide a view of the role-player that is customised for the Moment-Intervals in which the Role participates. For example, a Role might contain proxy operations for those of its role-player that are used by the Moment-Interval so that the Moment-Interval classes do not need to know anything about the role-player class itself. The Role class will also typically have attributes for information about the role-player that is only relevant when that role is being played.

None