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


Typical Operations

The typical operations of Role 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 associations of Role 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

Follow me on Twitter...