Role Class Archetype: Typical Responsibilities

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.

Typical attributes, operations, and associations of Role class archetypes

Typical Attributes

The typical attributes of Role classes include:

The assignedNumber Attribute

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.

User names and user id's that help authenticate a user of a system are another common example of an assignedNumber attribute in a role class. Often the users chose these themselves or a standard security process/policy defines them (e.g. my university user name was defined for me and consisted of my first name followed by the first letter of my surname followed by the year I hoped to graduate).

Places and things sometimes play roles in our system too and the assigned number attribute continues to be typically useful. For example, in the United Kingdom, a building used as a public house (pub) must be licensed to serve alcohol. The building is the role player, the role it is playing is a pub or bar, and the value of the role's assignedNumber attribute is the license number. Certificates may also be issued for devices indicating that they have been tested and found fit for their intended use. The device is the role-player, the role is the use to which the device is to be put, and the certificate number is the value of the assignedNumber attribute

Related Operations: None
Related Associations: None

The status Attribute

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.

Related Operations: isAvailable
Related Associations: None

Typical Operations

The typical operations of Role classes include:

The isAvailable Operation

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.

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

The listMIs Operation

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.

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

The assessAcrossMIs Operation

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.

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

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 associations of Role classes include:

 The Role - Moment-Interval Association

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

Related attributes: None
Related operations: isAvailable,  listMIs, assessAcrossMIs

 The Role - Party, Place, Thing Association

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.

Related attributes: None
Related operations: None