The Role Class Archetype
Role classes answer the question of how people, places, and things are involved in the Moment-Intervals we have identified for our software application, system , or component. In other words, role classes model the ways of participating in Moment-Intervals.
|
People and organizations frequently play multiple different roles that are of interest within our problem domain, either concurrently or over a period of time. Examples of roles played by individual people include employee, cashier, driver, pilot, and manager. Examples of roles played by organizations include law firm, bank, vendor, supplier, and manufacturer. Places 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. Occasionally Things play multiple roles. At a manufacturer the products being made have a role in their manufacture and another role in their sale and delivery. |
 Figure 1: The Role Class Archetype |
Some people talk about having to wear multiple hats, a woman who is a house-wife, mother, and a career-woman for example, or a software developer that also has to contribute as a requirements analyst, and tester. In identifying Role classes we are looking for these hats [Coad98].
To identify Role classes we look at each of our Moment-Interval classes and ask who is doing what in this Moment-Interval, where is this happening, and what things are involved?
Another good source of Role classes are actors from UML use case diagrams. Actors in UML use case diagrams show who is doing what with the system. If our software needs to work with or track anything about one of the actors then it is likely we will need a Role class to model that. It is unfortunate that UML continues to abuse the term 'actor'. because in movies and theatre, actors play roles but those explaining UML use cases are always having to say unintuitive things like 'actors are roles played by users'.
Typical Responsibilities
Like all the class archetypes, 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.
More on typical responsibilities of Role classes...
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
However, the super classes only make sense if there are truly things in common between people and organisations in our problem domain. Even if conceptually if there appears to be common attributes, associations, and operations, the detail of these can differ so much between people and organizations that it becomes very difficult to create useful generalised versions that. If there is little or no client code that we can write once that can be used in both cases, the super classes are just adding unnecessary complexity.
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.
Conceptually this is a very straight forward model to understand and there is a good separation of responsibilities. However, in larger systems this strategy could result in a large number of Role classes each of which the role player class, the Person class in this example, has to know specifically. This is not is not as loosely coupled as we would ideally like.
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
Modeling 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 modeling 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.
More on typical responsibilities of Role classes...
More on the typical attributes, operations and associations of Role classes..
The Moment-Interval Class Archetype
The Party, Place, Thing Class Archetype
The Description Class Archetype