Role Class Model
In computer science, the role class model is a role analysis pattern described (but not invented ) by Francis G. Mossé in his article on Modelling Roles. 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 - 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 is a possible way to go. See also. Francis G. Mossé has described other solutions to the role problem.