Role Class Model
In computer science, the role class model is a role analysis pattern[1] described (but not invented [2]) by Francis G. Mossé in his article on Modelling Roles.[3] The role class pattern provides the ability for a class to play multiple roles and to embed the role characteristic in a dedicated class.
In our society, as we built it, roles are everywhere. Anyone trying to work in a team to create something has a role. In cinematography, many different persons take part in the creation of a film: the film director, the producer, actors, play writer(s), etc. Even our State organisations are based on various roles. In a Republic, you have a President, Ministers, Deputies, etc.
Dealing with these situations is one of the problems encountered most during object-oriented analysis. Francis G. Mossé has identified 5 role analysis patterns that can be used to solve most role related problems: Role Inheritance, Association Roles, Role Classes, Generalised Role Classes and Association Class Roles. They all have various degrees of constraints, flexibility or power, which together offer a complete solution to most role-related problems.
Intent
A model that allows a class to play one or more roles at the same time. A role - as defined by Francis Mossé in Modelling Roles[3] - is a concept of a purpose that a class could have in a certain context.
Context
The following example is given:
Many persons work on a film, each of them with a different role. At the difference of other concepts, a person is not restricted to one role. One could be both the director and a character in a film. Modelling roles for such a concept would require that a class could play more than a single role.
A solution using inheritance to conceptualise a role - cf. the Inheritance Role Model - is not possible, as this would allow a person to play only a single role. As one can see in Figure 1 below, the inheritance role model says that a character, who is a person, is playing in a film. But there is no way to say that the person playing the character is also the director. Because, the inheritance makes a character a person in general, not a particular person.
Problem
As explained in Context, using inheritance to play more than one role cannot be considered, because a class could not play two roles at the same time in such a context (cf. the Inheritance Role Model).
The expectation is to have a model where a class could be seen as more than one concept or role, and where attributes specific to one of those concepts can be specified.
Solution
A solution to the previous problem could be to use the Association Role Model, which could create an association between a person and a film. However, specific information on each role could not be stored in such a case. The role class model provides the flexibility of the association with role-specific attributes and even class operations, if needed.
This meta model - in Figure 2 - shows the role class like an element linking the Client and the BaseClass. For the Client interacting with the Role is like interacting with the Base Class itself, but from the perspective, it is expecting. The advantage having the role as a class is that attributes can be bound to it.
Another situation where the Role pattern is interesting is when you've the following situation:
Then you realise that as a contract holder, the Person has specific attributes. The holder UML role becomes a dedicated class ContractHolder with these specific attributes. Note that in that case that the multiplicity near Person and Contract are always 1. It means that you've one ContractHolder object for each association between a Contract and a Person.
Real-world example
Cinema
A simple application of the role class model in a real example is in the 7th art (see Figure 3), the cinematography. This art involves a creation (the Film) and people to create it. Each person has a different role in the film, they could be actors and play characters, they could be director or scenarist, etc. A person is not limited to one role in a film, they can be both actors and directors and even more. For example, the film Scoop (2006) has been directed by Woody Allen, he is also the scenarist and he plays the role of Sid Waterman.
In Figure 4, one can see in more detail the role that each person can play in a film. From the film, it is possible to ask the list of crews and cast that help elaborated it. Each person has one or more roles (e.g. actor, director, producer, cameraman, etc.) in the film and can participate in more than one film. A person could even be an actor in a film and a producer in another. One advantage of using a role class in the case of the actor role is that the character qualities can be stored within the role. This is true for the actor role, this is also true for other roles, however maybe not all.
Only a few of the possible role have been modelled in Figure 4. One remark easily visible is that not all the role needs attributes and using the role class model for all of them is unnecessary (like for the Director role). In addition, there is a lot of redundancy between each role class. Redundancy in computer science means more work in maintenance, which is not wished.
Strengths and weaknesses
The employment of this model depends on the business process. The analysis pattern "Role Class Model" offers a possibility to employ a model with linking between a base class and the client. In addition inheritance is not a part of the solution because of the flexibility of zero or multiple roles (role-specific attributes and operations). Strength implies also its counterpart's weakness. The problem of the role class model is the redundancy, for example the method getName is visible in all of the role classes described in Figure 4. If this is considered inconvenient, the role class generalisation model as defined in Modelling Roles[3] is a possible way to go.
See also
Francis G. Mossé[3] has described other solutions to the role problem.
- Role Inheritance
- Association Roles
- Generalized Role Classes
- Association Class Roles
- Association Class Roles with role type, which is a refinement of the previous.
- Referential transparency
References
- ↑ Fowler, Martin (1997-07-20). "Dealing with Roles". Analysis Pattern. http://www.martinfowler.com/apsupp/roles.pdf. Retrieved 2007-01-16.
- ↑ There are a citation about it in the book Business Modeling With UML: Business Patterns at Work by Magnus Penker (Author), Hans-Erik Eriksson chapter:
...Its origin is unknown, but this pattern has been invoked to model mine-clearance systems used by the United Nations. A description of the concepts underlying this pattern can be found in Murray R. Cantor's book, Object-Oriented Project Management with UML (John Wiley & Sons, Inc., 1998).
- ↑ 3.0 3.1 3.2 3.3 Francis G. Mossé (September 2002). "Modeling Roles - A Practical Series of Analysis Patterns". Journal of Object Technology, vol. 1, no. 4. pp. 27–37. http://www.jot.fm/issues/issue_2002_09/column2. Retrieved 2006-12-28.
Further reading
- Fowler, Martin (1996-11-27). Analysis Patterns: Reusable Object Models. Addison-Wesley. ISBN 0-201-89542-0. An introduction to object-oriented analysis with conceptual models
- Raventós, Ruth and Cabot, Jordi (2006). Conceptual Modelling Patterns for Roles. Journal on Data Semantics V. http://www.lsi.upc.edu/~jcabot/papers/JODS05.pdf. Retrieved 2007-01-16.[|permanent dead link|dead link}}]
- Department of Computer Science (2004). "Usage of Roles in Patterns". Analysis Pattern. University of Illinois at Urbana-Champaign. http://wiki.cs.uiuc.edu/AnalysisPatterns/Asita+%3A+Usage+of+Roles+in+Patterns. Retrieved 2007-01-16.
- chromatic (2006-08-31). "Usage of Roles in Patterns". Technical. O'Reilly Media. http://www.oreillynet.com/onlamp/blog/2006/08/roles_composable_units_of_obje.html. Retrieved 2007-01-16.
Related links
- Actor-Role Pattern, A JPA Implementation https://web.archive.org/web/20071105232543/http://www.ibstaff.net/fmartinez/?p=16
 |  |
