The word, role,  pops up every now and then when reading about software design. Peter Coad, in his modeling in color technique, defines a role as a way that someone, some place or some thing participates. Rebecca Wirfs-Brock's, in her Responsibility-Driven Design approach, defines a role as a set of responsibilities, where a responsibility is an obligation to perform a task or know information. Most books and tutorials on the Unified Modeling Language(UML) will use the role word at the place where they introduce the actor element drawn on use case diagrams.

A Visit to the Movies or the Theatre

Of course, roles are not something exclusive to software design. There are obvious parallels in theatre or movies where we frequently talk about roles:

• abstract roles such as the hero and the villain, or a leading role, and supporting role, for example.
  
  
• the more specific kind of role of the actual characters in the script of a particular movie or play. For example, we can talk of Captain James T. Kirk as a role played by William Shatner in the original Star Trek television series and movies. It is doubtful whether many actors will play the role of Captain Kirk in a movie or TV show.  Until Star Trek XI, it was almost unthinkable that anyone except William Shatner would. In contrast, the number of different actors that have played the role of Shakespeare's Romeo must be in the thousands.
  
  
• the different roles of one particular character within a movie or play. For example, the hero in the Superman movies not only has a role as a superhero but also as a journalist.
  
  
• the role of a character in a particular scene. In one scene the character might have the role of a defender protecting another character. In another they might be playing the role of an attacker, lover, jilted partner, murderer, murder victim, etc.
  
  
• at the most granular level, the role of each character in every interaction with someone or something else. For example, if one of the characters asks a question of another then that character could be said to be playing the role of a 'person asking a question' and the character they are asking the question of is playing a role of ' a person being asked a question'. Of course, at this level, it should not be necessary to explain to the actor or the audience what role each actor is playing in each verbal exchange because hopefully it is obvious from the script.

Archetypal Role Classes and Actors in Software

Just as in movies and theatre, roles in software can be considered at different levels of abstraction or granularity. For example, the modelling in colour technique is aimed at a suitably high-level of abstraction. The kinds of objects it is concerned about tend to be the more significant problem domain objects. At this level, roles model the real-world roles that people, places and things play as they participate in such things as business events, transactions, activities and other kinds of interaction.  Here, a role may end up being modeled as a class within a software system or component. According to the 'modeling in color' technique, these role classes typically have similar kinds of attributes and operations, and relate to other classes in typical ways.

Figure 1: An archetypal role class

Alternatively, if the role is trivial, not having properties and behaviour of its own, it may simply be a label on the end of an association in a UML class diagram  (see From UML Association to the Domain Neutral Component for a further comparison of the two).

Peter Coad defines a role as a way of participating and likens a role to a hat that can be worn. People often say they are having to wear multiple hats meaning that they are having to play multiple roles. In defining classes for a piece of software in a language like Java, C#, Objective-C, C++, etc, it is important to distinguish between roles and role-players (hats and hat-wearers) when the same person, organization, place or thing can perform multiple roles (participate in events and activities in different ways) in the software. Typically, one class is required to represent the role-player and additional distinct classes for each of the roles played. Not doing so can lead to misuse of inheritance and fragile or clumsy designs (see Challenge Multi-colored Inheritance in Model Archetypes).

For each role, different sets of characteristics or attributes and behaviour of the role-player are relevant or important. When those attributes and behaviour are only relevant to a single specific role then those attributes and behaviour are best modelled as attributes and behaviour of the role class itself. If the attributes and behaviour are relevant to most if not all the roles played then the attributes and behaviour can generally be considered attributes and behaviour of the role-player class.

To be an Actor or not to be

A good UML use case model of a business application identifies actors at a similar level of abstraction to 'modeling in color' role classes ... and I will not bother resisting the temptation to point out that calling these elements actors is an annoying abuse of the English language. They should be called something like user roles. Most of the UML books and references end up writing phrases like 'an actor is a role'. No! Actors are not roles. Actors play roles. They are role-players. The actor George Clooney is not actually Batman; he plays the role of Batman (and not nearly as well as Michael Keaton or Christian Bale in my humble opinion but that is beside the point).

It is quite easy to compare the similarities of a use case, with that of a scene in a play or movie. The movie script describes the sequence of interactions between the characters (roles played by actors) in the scene. A use case describes the sequence of interactions between the user roles (UML actors) and the software system. A good scene has a well-defined purpose adding something to the main plot or a sub-plot of the movie or play. A good use case has a well-defined purpose that results in something of value to a user of the system ... and so on.

It would be obviously wrong in a movie script to refer to the wrong level of role in a particular scene. We expect a script to be written in terms of the characters in the movie:

Annabel: Why are leaving me?
Dirk: Because I don't love you anymore?
Annabel (sobs): But why?

The following is obviously using roles at a too detailed level.

Jilted lover: Why are leaving me?
Jilter: Because I don't love you anymore?
Jilted lover (sobs): But why?

And this is equally useless

Heroine: Why are leaving me?
Main Male Lead: Because I don't love you anymore?
Heroine (sobs): But why?

It is less obvious but equally useless to do the same sort of thing when drawing use cases. A UML actor called system user is not likely to be useful. It is like the second bad script example above, a too coarse-grain level of role. For a use case called select product, a UML actor called Product Selector, is unhelpful because, like the first bad script example, the role is at too fine-grain a level.

Roles in Object Interactions

Similarly to movies and the theatre, we can consider roles at finer levels of granularity. Each object participating in the implementation of a particular feature or system responsibility plays a role in that interaction. Trygve M. H. Reenskaug is one of the most well known exponents of the ideas surrounding this level of role in software. It is the level of role that the more academic books on UML are talking about when discussing sequence diagrams.

Here each object participating in the sequence diagram is responsible for performing a set of tasks or for knowing information needed to make that interaction happen. Most types of object in a piece of software will take part in multiple different interactions and the set of tasks needed in any particular interaction is likely to be smaller than all the tasks that the object can perform. For example, an object representing a line item has the task of providing a sub-total in a sequence that calculates the total price for the order. In contrast, the same line item object participates in a different way in a sequence that collates the information on an invoice for that order. In other words, each object has a specific role to play in each different sequence or interaction and that role is characterised by the subset of that object's behaviour and data needed in that particular interaction.

Comparing these different subsets of behaviour and data can help determine whether a class definition is a good one or not. Do objects of a class have clearly distinct subsets of information and behaviour across the interactions in which they are involved? In other words, can we divide the object interactions in which objects of a class participate into groups where the members are the only interactions that use a particular subset of the object's properties and operations? If the answer is yes, then we need to look carefully at the class of object because it would seem to be combining two very distinct roles, and possibly concepts, together.

Service and Operation Parameters

We can go further and examine the role played by the different types of object as they are passed as parameters into or returned as results from an operation. Here again only a certain subset of the objects features are needed in each different operation and these characterise the role being played by that object in this situation.

Within is a single piece of objected-oriented software, we generally pass the memory address of an object when we sue it as a parameter to an operation on another object. We do not care that the called operation only needs one or two properties of the object or only calls one or two of the passed object's operations.

However, when it comes to passing an object between address spaces such as in a Service-Oriented Architecture (SOA), or distributed-object situation, we definitely do care. We have to serialise any objects passed as parameters into messages. Serialising the parameter object itself is rarely a problem, it is all the other objects that it has references to and the objects that those reference and so on, that are problem. How do we keep the amount of serialized data to a reasonable amount, especially if the service we are calling only uses one or two pieces of the main object? Enterprise-soa efforts that attempt to  directly use class or data definitions from a traditional, monolithic object or data model as parameters to operations in a SOA or distributed-object situation struggle because the model cannot answer this question.

A similar situation exists when we want to display objects in a user interface. It is common here, to use some of Data Transfer Object (DTO) pattern where the DTO contains only the subset of attributes and behaviour of a large domain object that are need to be displayed in a GUI panel or dynamically generated web page. Essentially, the DTO represents the role that the Domain Object is playing as part of the display. The attributes and behaviour of the DTO represent the subset of the domain object that are relevant in this context. In addition:

• The values of the attributes are fully derived from those of the domain object.
  
• The subset of attributes and behaviour are fully constrained by that of the domain object.
  
• The values of any additional attributes in the DTO that are not present in the Domain Object have to be fully derivable from the values of attributes that are.

The definition of the DTO is obviously dependent upon that of the Domain object and we can draw a dependency relationship between the DTO and the Domain object. However, a UML dependency does not convey the type of dependency. To do this we need to add a stereotype to the dependency,  <<constrains>> maybe. Then we need to define some rules in the form of constraints that apply for that stereotype including, for example:

1. an attribute with the same in the DTO as in the Domain object holds the same value, has a compatible type and the same multiplicity.
2. an attribute with a name that does not appear in Domain object must have a rule that derives it's value from the Domain Object.

A similar pattern can be used for large enterprise SOA installations concerned about data consistency. The classes or data definitions in the enterprise object or data model can be considered as role-players that constrain the contents of objects or data definitions that represent them in calls to services. Simple tools that validate the constraints between the central model and the definitions of service parameters are generally not beyond the skill of most organisations to produce if they are sophisticated enough to be engaged in an enterprise-wide SOA effort.

Conclusion

Class models, use case diagrams, object interactions, services ... the idea of roles pops up usefully almost everywhere in software design.