The Role Class Archetype

Figure 1: The Role Class Archetype

Places that are of interest in our software may also play multiple different roles, although somewhat less frequently than people and organizations. For example, an airport may play roles as a freight, passenger, and military airport. A particular building might play the roles of a shop, a residence, a warehouse, or location of mobile phone transmitter for example.

Finding Role Classes

Typical Responsibilities

More on the typical attributes, operations and associations of Role classes..

Party Roles

Although places and things do quite quite often play multiple roles in a software application, system, or component, by far the most common player of roles are people and organizations.  For  reasons of brevity, we group individual people and organizations under the heading of parties, so that instead of having to write person and/or organization everywhere we can simply write party instead. Obviously this is the sort of party referred to in legal contracts or law suites rather than the sort of party you attend at Christmas or on birthdays.

Generally, a role can only be played by a person or it can only be played by an organization. However, occasionally there are roles that can be played by either a person or an organization such as customer, loan applicant, account holder, and investor. Care needs to be taken here. People and organisations are often so different from a business or legal perspective that even if the role is called the same name, the differences in information and behaviour needed when it is played by an organization and when it is played by a person frequently require two different Role classes to model them.

Conceptually we could build the following model:

Figure 2: Person and Organisation roles as specializations of a Party role

Modelling Numerous Roles

In larger systems there may well be a significant number of roles played by parties. One example is complex business automation systems where a number of different employees need to perform particular activities throughout the process. Even for a simple retail store system, the number of recognised roles played by staff can rapidly grew to half a dozen if the scope system includes inventory management, and accounting functions.  One way to model these different user roles is to separate attributes and operations that are specific to each role into separate role classes and  associate each role class with a Person class as shown below. 

Figure 3: Roles for people in a simple retail store system

A slightly modified approach introduces an abstract superclass for the individual role classes. We link the Person class to zero or more instances of the role superclass. This super class contains anything that is common across all the role classes. Often this is just the knowledge of who the role-player is. Now objects of the Person class hold a collection of different role objects but the Person class only needs to know specifically about the PersonRole class.

The multiplicity of one on the association between the PersonRole and the Person classes ensures each role object knows its role-player object. Typically this link would be established by passing the Person object as a parameter to the constructor of the Role classes or the factory methods responsible for creating objects of the Role classes.

Figure 4: Roles inheriting from a PersonRole superclass

In their book, Streamlined Object Modeling, Jill Nicola, Mark Mayfield and Mike Abney place the  responsibility for knowing whether a particular role can be played by a role player object with the role rather than the role player. It might seem more intuitive for the Person class, the role player in our example, to be responsible for the roles that it plays but this could very easily lead to the Person class again having to know about every Role class it could play and the rules about when it can play each of those roles. The result would be tight coupling between the Person class and all the Role classes. This is something we are striving to avoid.

There are four types of check that a Role object may need to do to ensure it can be played by a role player class.  Firstly the role player object must be of the right type. This is trivial in our example because there is only one role player class that our roles can be played by, the Person class. This constraint is built into the model by the association between the Person class and the PersonRole class (note the multiplicity of one at the Person end of the association). If, like the Party class in Figure 2,  the role player class has sub-classes and the role can only be played by only some of those sub-classes then this check needs more work.

The second type of check that a role object may need to make before it can be played by a role player is to ensure that the role player object qualifies for the role. For example, it may be the case that anyone wanting to be a manager in the store must be over eighteen years old but other employees can be younger especially if working part-time. In this case, the Role objects need to check that the Person object wanting to play that role is old enough. Since, a role object must know it's role player object, this sort of check is usually reasonably straight-forward to implement.

The third type of check that a role object needs to make before it can be played by a role player is more difficult. There are problem domains where, if a role-player is already playing a particular role, they cannot play another particular role due to business or legal reasons.  For example, consider an organisation running promotional prize draws. If a person has a role as an employee with that organisation then they are not allowed to play a role as an entrant in the prize draw.

Subsequent Roles

The fourth type of check required to see if a role-player can play a particular role is when to play one particular role, the role-player must already be playing another particular role. For example, to be a user of certain systems within an organisation, a person may have to be an employee of that organisation. The once they have a user account, that person may then be able to perform several different roles within the system.

We can build this constraint into the model using a subsequent role pattern. Instead of linking the role directly to the role-player we link it to the enabling role. 

Figure 5: Roles classes with subsequent and enabling role constraints built into the model structure

In the example above, the constraint, 'A person must be an employee before they can use the system', is modeled as a subsequent role.  Instead of being linked directly to the Person role-player class, the SystemUser role class is linked to the Employee role class. Now for a Person object to be able to play a SystemUser role they must first play an Employee role. Once a Person object  is indirectly associated with a SystemUser role object it can be given further roles (Cashier, Admin, Manager, InventoryClerk, etc).

Modelling subsequent roles in this way has the advantage the constraint is modeled explicitly through associations rather than being left to code or an external policy. However, this only works if the constraint will never change. Imagine a system that is used only by employees but now needs to be opened up to allow internet users limited access. The example model above would need to be restructured.

Roles vs. authorizations and permissions

Often a role can be little more than a name for a particular combination of application permissions, assignments or authorizations. In these cases, we could use a more generic role class instead and derive the specific roles from  associated permissions, assignments or authorizations.

For example, a person playing an employee role could be assigned to manage one or more departments for a time. The assignment makes them a manager. A Point Of Sale system user may be authorized to work on a particular cash-register. That authorization makes them a cashier. In general many user 'roles' can be modeled as a single User role class associated with a particular combination of permissions (operations that the person playing that role may perform).

Figure 6: Roles as collections of authorizations and assignments

Modelling permissions/authorizations reduces the number of  role classes making it easier to manage inter-role constraints. The downside is that we have bigger, more complex role classes requiring deductive logic to identify business roles.

Using a Rules or Policy Engine

For large enterprise systems with many complex combinations of permissions and access rules, it may be more cost-effective to have the User role class delegate to a commercially available or proven open-source permissions directory or rules engine.

In the example model below, the SystemUser class requests a list of permissions from the rules engine when the user logs on. The SystemUser class hides the use of the rules engine from the rest of the system.

Figure 7: Roles with separate security engine

A separate permissions or  rules engine may offer more flexible administration of permissions policies. It may also offer an opportunity to standardise on a particular technology across a number of components, systems or applications. It may also be cheaper to buy a commercial product or set up a proven open-source offering than building one in house.

Of course this needs to be weighed up against any potential performance overhead when accessing the engine ,the complexity and potential additional cost of deploying, configuring, and administering the engine.

There is almost never a single right design. We assess the benefits and design, picking the one that we believe to be the most appropriate and, of course, the best answer may actually end up being a combination of two or three of the possible designs we consider.

The Class Archetype Formerly Known As...

In 1997, Peter Coad, with David North and Mark Mayfield, published the second edition of their book,  Object Models: Strategies, Patterns, & Applications. Page 435 describes a small object model pattern called 'Actor-Participant'. Today this is reflected in the Party, Place, Thing and Role class archetypes.  In Streamlined Object Modeling: Patterns, Rules and Implementations, Jill Nicola, Mark Mayfield, and Mike Abney refer to the same collaboration as the 'Actor-Role' pattern.  

There is, of course, the problem with the use of the term actor from its misuse within UML.and use case modelling in general. Actors of use cases actually map far closer to Roles than they do to the role playing classes of the Party, Place, Thing class archetype. Calling the role-playing archetype, Party, Place, Thing, eliminates the possible confusion with the different meanings of the term actor. It is also a constant reminder that roles can be played by places and things as well as people and organisations.

The Other Class Archetypes

• The Moment-Interval Class Archetype 
• The Party, Place, Thing  Class Archetype
• The Description Class Archetype