Modeling Roles in UML
The Five-Role Strategy
A series of Five Analysis Patterns to model roles in UML [1]
Abstract
The Five-Role Strategy is a set of five typical solutions to typical Role problems commonly found in the software engineering analysis of various problem domains. Those typical solutions are called Role Patterns. There are five such patterns, commonly represented with UML class diagrams. They model solutions for Roles as found in Business, Engineering, Software, and Systems problem domains. The UML class diagrams representing those Role Patterns are made up of classes and their relationships, each class representing a distinct concept. The technique that consists of selecting the best Role Pattern for each Role problem is called The Five-Role Strategy. These five Role Patterns are: the Inheritance Roles, the Association Roles, the Role Classes, the Role Class Generalization, and the Object Roles. Each of those five role patterns is made up of a specific combination of classes, associations, and inheritance. These Role Patterns are considered under two different, complementary angles: the problem they solve and how they are structured.
Role Examples
Human Resource problem domains typically describe the multiple roles a person may be responsible for. For instance, a person may be an employee, a stockholder, a Board member, an insured person, a dependent, or a guarantor. Many of such roles could be assumed by the same person, and some could mutually exclude each other. There is a Role Pattern that best addresses each of the above role cases.
Origins
These Role Strategies were originally designed and classified by Francis G. Mossé while teaching UML Analysis in Chicago, in 1998. But like all other Analysis, Design, or Systems Architecture Patterns, it is understood that the same or similar patterns may have been discovered, invented, copied, or applied by other analysts or developers, whether their work was being published or not.
The Five Role Analysis Patterns, in a Nutshell
| # | Role Pattern | Use that pattern to model |
|---|---|---|
| 1 | Inheritance Roles | Mutually exclusive roles that cannot be changed and may have attributes or methods |
| 2 | Association Roles | Simple roles that can be changed but do not need any attributes or methods |
| 3 | Role Classes | Elaborated roles that can be changed and typically have attributes or methods |
| 4 | Role Class Generalization | Elaborated roles that can be changed and share common, general attributes and methods |
| 5 | Object Roles | Each role is an instance of a single Role class. Its attribute values like name can be edited at any time. |
I. The Inheritance Role Pattern
One could easily think of Roles as types. For instance, a company that supplies products would be understood as a vendor. On the other hand, if it buys products, then it's known as a Customer. That makes two different types of companies: vendors and customers. This concept could lead to the following model fragment:
 |
In plain English, this model tells us there exist two different types of companies: customers and vendors. Customers buy products whereas vendors supply them. Because inheritance is being used, a company cannot be both a vendor and a customer; it is either one or the other. These two roles are mutually exclusive. And once the choice of a given role is made, it is final. Whether this is good or bad depends on the problem domain you’re modeling. In this case, you cannot get supplies from a customer nor can you accept orders from a Vendor. If all that matches the Problem Domain, then this Inheritance-based solution is perfect. |
| Now let’s express the same solution for this example in an abstract way, using a metamodel. | |
 | A metamodel provides a general answer, and models that describe a concrete example are instances of metamodels. Because metamodels supply a general answer, they are also called patterns.
In this metamodel, "Subject" is an abstraction of Company in the concrete model we discussed above.
In this diagram, the inheritance relationship is qualified further with a property string, {many subclasses/roles}. It expresses that the models based on this metamodel will typically have multiple Role classes. Our example above has two. This metamodel describes the Inheritance Role solution, our first Role pattern. |
| Metamodel 1: Inheritance Role Pattern | |
Notice the above Inheritance Role does not allow a base class to play multiple roles. A company can be either a vendor or a customer--not both. If modeled that way, a person can be either a dentist or a landlord--not both. This type of limitation may not work for some problem domains. We're about to investigate several solutions that are more flexible.
II. The Association Role Solution | |
| Roles are names given to base classes (companies, persons, documents, ...) only according to what they do in relation to other classes. We could simply say: a role is played by a class within the context of its relationship with other classes. The UML Associations offer Association Roles, as depicted in the next figure. Notice that Vendor and Customer are simply association roles. | |
 | With this solution, a company can either sell or buy any product. It can therefore be considered as a customer or a vendor, at any time as well as at the same time. All it takes is a link (association instance) to allow a company object to play the role of a customer and/or a vendor for a specific product instance.
A company’s Role is simply based on what it does, not what it is. This solution pertains to cases where Roles do not need additional attributes. For example, whether it is a Customer or a Vendor, all the Company attributes are always pertinent and sufficient. But if say Vendors would need an additional attribute like "specialties" that Customers do not have, then this solution would not be adequate. We would need a Role Class, as described later in this article. |
| Now, the above diagram is just an example, and we need to generalize as shown below. | |
 | "Company" is a "Subject" class, and "Product" is an "Object" class. Our Metamodel, built with "Subject" and "Object", is an abstract model. Our model above using "Company" and "Product" would simply be an instance of that metamodel.
Though the Association Role solution is remarkably simple, it is known to solve many of the Role problems. Always think of this one first, and if it does not offer enough, e.g.: role-dependent attributes, consider the other options covered in this article. Notice how many relationships you can have. In our Company/Product example, we had two: buying as a customer or selling as a vendor. This metamodel links a note to the association stating there may possibly be many such relationships. Any number of such associations is possible, each with their own role as needed. In our Company/Product example, we could easily add more roles. For example, we could have a "Manufacturer" role. The association name could be: "produces". So, a Company who produces Products is a Manufacturer. That would be our third association. In cases where the simple Association Role strategy suffices but people don't know about it, they end up adding classes and/or attributes that will complicate the model and lead to confusion. |
| Metamodel 2: The Association Role Pattern, an instance of which would be a class diagram following this structure as a template. | |
| The following diagram shows another example using Association Roles. Its annotations show all the model elements pertaining to Associations. This is an easy way to learn about UML Associations. | |
 Notice that Associations are always named with meaningful verbs so that they may be read in plain English. For instance, the "Owns" Association is read as: "A Person Owns (zero or more) Buildings". We may also read it in the other direction, from Building to Person and by replacing "Owns" with "Is Owned By". That would give: "A Building Is Owned By one Person. | |
The multiplicity symbols in UML class diagrams are:
Though this example exhibits two Association Roles per association, they are optional. We use them when they are necessary to express key concepts, clarify the meaning of the Association itself, or, obviously, when a role must be spelled out. | |
III. The Role Class Pattern
| The Role Class Pattern provides a solution that offers attributes for each Role while remaining flexibility.
The Role Inheritance Pattern (Metamodel I) did offer attributes for each Role, but it wasn't flexible. For instance, it would not allow a Company to be both a Customer and a Vendor, or possibly none of them. The Association Role Pattern (Metamodel II) offered all the flexibility we might need, but no Role-specific attributes. Here is a solution example where each Role has its own attributes but is flexible enough to let a Company assume any roles, all of them, or none. |
 Due to the association multiplicities, a Company may assume any role, all of them, or none. It is therefore a very flexible solution. Because each role is represented by a class, there can be attributes specific to each role. For example, a Customer role will come with two attributes: area of interest and credit rating. Each role (Customer or Vendor) is linked to only one Company; these roles are dedicated to a single subject. However, any role can be linked to any number of objects. For instance, a Vendor may supply 0 or more Products. This solution gives both flexibility (due to the associations) and functionality (thanks to the role attributes). We will see soon that it can still be improved, but let's review the metamodel first. |
 "Subject" correspond to the example's "Company" class, and "Object" corresponds to the example's "Product" class. "Role" is the abstraction for both "Customer" and "Vendor" roles. |
IV. The Role Class Generalization Pattern |
 |
 |
V. The Object Role Pattern |
| The examples we’ve seen assume all the possible roles are known. When the system is implemented, only these roles can be used. For instance, a company can only take the role of a vendor, a customer, or a broker. Though these roles can be dynamically assigned, they cannot be dynamically created. We can assign any role to a Company, but it will have to be one of the roles already present in the system. In other words, it will have to be an existing class.
Classes aren't created dynamically—but objects are. The following example shows how we can dynamically create new roles with objects. For that, we create a class that abstracts all the useful attributes of a role, e.g.: "name" and "description", that will be given specific values when the class is instantiated into an Object Role. |
|
| For example, a Role object could have the following attribute values: "Customer" for Name, and "A legal entity that buys our products" for Description. Another Role object could have "Vendor" for Name and "A legal entity that produces and delivers our products". Role objects are instantiated on demand and whenever a new Role is needed.
The next step is to associate the Object-based Role with the rest of our model, namely what we called "Subject" (of the Role) and "Object" *of the Role in our previous metamodels. Associations and Association Classes are typically used to that effect. Below is an example where a "Role Assignment" Association Class connects the Object Role called "Role" with "Company" and "Product". |
|
| In this case, roles are created on demand. To specify a company supplies a specific product, then one just needs to create an instance of Role—a link object—and link the proper product to the right company. That role link object can be named whatever one desires it to be: vendor, customer, broker, etc.
Notice an interesting feature in this role association class example: the Time Period. Business rules often require relationships to be specified for a specific time period. The association class role solution is flexible and powerful. Notice that the concept of roles is modeled—not roles themselves. This model is more abstract than models that deal with explicit roles. In general, higher levels of abstraction bring greater simplicity and flexibility. Let us then build the general solution for this pattern; its Metamodel. |
|
Conclusion: the Role Modeling Strategy |
| If a role is sufficiently described with a name, then the simplest model element, the Association Role, can be used. If a role needs to be described with more attributes like "name", "description", etc., it must be modeled with a class. That role must then be connected to who plays it (the "Subject") and what it is played against (the "Object"). That relationship will be modeled according to the complexity of its requirements, the simplest being an Association, the more elaborated being an Association Class, a Generalization (Inheritance), or a combination of the two.
The best model is the simplest solution that covers all the requirements, and whoever models Roles is very likely to find the optimum solution in one of the above five Role Patterns:
|
References
|
This article "Modeling Roles in UML" is from Wikipedia. The list of its authors can be seen in its historical and/or the page Edithistory:Modeling Roles in UML. Articles copied from Draft Namespace on Wikipedia could be seen on the Draft Namespace of Wikipedia and not main one.
