The Role class archetype is one of four class archetypes in Peter Coad's 'modeling in color' technique.
Peter Coad defines a Role class as modelling a way of participation by a party (person or organization), place or, thing. [Coad99]
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. We use a role class to encapsulate data and behaviour that is specific to a role being played. This is not only useful in breaking down larger classes into more manageable chunks, but also encourages the use of composition instead of inheritance where a party, place or thing may play multiple roles at the same time.
Figure 1: The Role Class Archetype
When buliding object-oriented software we find 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.
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].
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.
Occasionally Things that we need to deal within our software play multiple roles. At a manufacturer the products being made have a role in their manufacture and another role in their sale and delivery.
In the classic board game, Cluedo (Clue in the USA), we have six characters with names like Colonel Mustard and Mrs. White. One of these characters is the murderer of Dr. Black (Mr. Boddy in the US version). There are nine rooms, one of which is the scene of the crime, and six things, one of which is the murder weapon. Murderer is a role played by a person. The crime scene is a role played by a place, and the murder weapon is a role played by a thing. The person, place or thing playing the role is often referred to as the role-player.
Finding Role Classes
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.
Note: It is unfortunate that UML 2.x continues to abuse the term 'actor'. In movies and the theatre, actors are not roles; actors play roles. The actor is Michael Keaton, one of the roles he has played is Batman. Those explaining UML use cases are always having to say unintuitive things like 'actors are roles played by users'.
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.
Typically it is best to place properties and behaviour that are specific to a particular role that a role-player is playing in a role class rather than in the role-player's class. On occasions where someone, some place or something always and only ever plays one role in a software system, it can make sense to collapse the role-player and role classes into the role-player class.
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.
Figure 3: Roles for people in a simple retail store system
Modelling In Colour: The Role Class ArchetypeConceptually 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.
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.
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 Role Class Archetype
The Role class archetype is the second of the four class archetypes defined by the modeling in color technique. Role classes model a way of participation by a party (person or organization), place or, thing. We sometimes talk of people wearing more than one hat when they have multiple responsibilities. Roles model those hats.
Typical Responsibilities of Roles
Like all the class archetypes in modeling in color, the true usefulness of the Role class archetype in identifying and reviewing problem domain classes is due to its typical responsibilities, and the lists of typical attributes, operations and associations that represent those responsibilities.
The Party, Place, Thing Class Archetype
The third of the four class archetypes defined by the modeling in color technique, is the Party, Place, Thing class archetype. These classes model someone or something who plays different roles. They are the role players. If Roles classes are the hats, then Party, Place, Thing classes are the hat wearers. If you can converse with it, pick it up, or stand in it, then it is likely to be an example of a party, place or thing.
The Description Class Archetype
The fourth and last class archetype defined by the modeling in color technique, is the Description class archetype. This class archetype models a catalog-entry-like description. It is a collection of values that apply again and again. It also provides behavior across the collection of all things that correspond to its description. It categorizes objects of other classes according to different values.
Reference Number Attributes in Class Archetypes
Each of the four class archetypes has a set of attributes that we might typically expect to find in classes belonging to that archetype. In each case, this set includes some sort of reference number attribute. While they all might seem very similar, and serve similar purposes, some subtle differences exist.
Accelerated Problem Domain Analysis
Peter Coad's 'Modeling in Color' technique uses the idea of class archetypes to build understanding of a problem domain quickly. Jeff De Luca's Feature-Driven Development approach defines a collaborative process that works beautifully with modeling in color. Domain experts and developers work together on a daily basis to build an overall, initial, 'just enough' domain model that is then used to build a much better initial product backlog or features list.
Linking together the typical associations between class archetypes presents us with a pattern of classes we call a model archetype or domain neutral component. We can display this with the Party, Place, Thing class archetype as a single class to give a basic model archetype. Alternatively we can explode the Party, Place, Thing class into its three flavors and produce a larger more comprehensive domain neutral component that is even more useful. Model archetypes can be used to rapidly build new problem domain models or review and revise existing problem domain models.
Class Archetypes, UML and Color
Class archetypes can be used without the color coding quite happily. Color can be used to highlight items in diagrams with great effect without the use of class archetypes. The combination of the two, however, provides a much deeper means of communication. The color-coding 'layers' into the diagram. It provides a means to quickly and effectively engage with a non-trivial diagram. You can 'step back' from the diagram and examine the patterns of linked colored classes, 'zooming in' on textual detail as needed. After modeling in color for a while, you wonder how you were ever satisfied with black and white diagrams.
From UML Association to the Domain Neutral Component
Karl Frank and I were in Denver, USA, giving a modeling in color workshop for a client. One evening Karl asked me what if any relationship I thought there was between roles in the Domain Neutral Component (DNC) and role labels on a UML association. The subsequent discussion sparked a train of thought that further convinced me of the simple, effectiveness of using the domain neutral component.