As Antoni Olivé once said, you’re nobody in the field of Conceptual Modeling until you’ve published your own paper on how to model the role concept. This is mine: Conceptual Modelling Patterns for Roles, Journal on Data Semantics V pp 158-184, co-authored with Ruth Raventós.

The work is not new at all. In fact, it even predates the start of this blog which explains why it was never featured here. Nevertheless, my opinion on the best way to model such a complex concept as Roles has not changed and after this twitter conversation brought the topic back to my mind I thought it was worth to talk about it.

Roles are meant to capture the dynamic and temporal aspects of real-world objects. The role concept has been used with many semantic meanings: dynamic class, aspect, perspective, interface or mode. This paper identifies common semantics of different role models found in the literature. Moreover, it presents a set of conceptual modelling patterns for the role concept that includes both the static and dynamic aspects of roles. In particular, we propose the Role as Entity Types conceptual modelling pattern to deal with the full role semantics.

A conceptual modelling pattern is aimed at representing a specific structure of knowledge that appears in different domains. The use of these patterns eases the definition of roles in conceptual schemas. In addition, we describe the design of schemas defined by using the patterns in order to implement them in any object-oriented language.

You can freely download the full Role Modeling pdf or keep reading for a short summary of the concepts discussed in the paper.

Introduction to the Role modeling construct

The role concept appears frequently in many different domains of the real world, since we can find entity types in each domain that present some properties that evolve over time. There is not a uniform and globally accepted definition of roles. The first commonly credited definition of roles in a data model goes back to the 70s when Bachman and Dayas proposed the role data model. They defined a role as “a defined behaviour pattern that may be assumed by entities of different kinds”. Since then, many other definitions and additional semantics have been proposed.

For instance, to Dahchour et al. in, the concept of role is “a generic relationship for conceptual modeling that relates a class of objects (e.g., people) and classes of roles (e.g., students, employees) for those objects. The relationship is meant to capture temporal aspects of real-world objects”. To Papazoglou and Krämer a role “ascribes properties that possibly vary over time. The purpose of a role is to model different representation alternatives for the same object in terms of both structure and behavior“.

To sum up, we could state that roles are useful to model the properties and behaviour of entities that evolve over time. The entity type Person is an illustrative example. During his or her life, a person may play different roles, for example he or she may become a student, an employee, a project manager, and so forth. Besides this, a person may have different properties and behaviours depending on the role or roles he/she is playing at a certain time.

For instance, let us consider the following scenario, which will serve as a recurrent example in the following pages: let Maria be a person (with a name, phone number, birthdate, country, age, sex and full address), who starts a degree (Maria plays the role of student). After some years of study, she registers to a second university program (Maria plays twice the role of student) and starts to work in a company (Maria plays the role of employee). In that company she may become a project manager (now, Maria through her employee role, plays the role of project manager). If in the future, Maria became a department manager, now Maria through her employee role would play a new role, department manager.

For each role we are interested in recording a set of properties specific for that role. As employee we are interested in: her employee number, category, company phone number, working status and the expiration date of her contract. As a project manager we are interested in information about the project she manages (the project name, the start date and the tasks it involves). Moreover, roles share properties with the main entity type. For instance, when considering Maria as employee we also want to know her name, even though the name is not an explicit property of employee.

Figure 1 shows the different relationships that are involved in the scenario introduced above. Note that, in this situation, if we ask for the value of a property of Maria the answer is not trivial because it depends on the role or roles she is playing. For instance, if we ask for her telephone number, the answer may be her personal number (since Maria is a person) or her company phone number (since Maria is an employee).

Despite its importance, the possibilities that conceptual modelling languages offer to deal with roles are very limited and cover only a very small part of their features. For instance, the ER model considers roles as named places in a relationship; UML considers that a role is an association end; in Description Logics roles only denote binary relationships between individuals; in Nijssen’s information analysis method (NIAM)  and in its descendants as Object-Role Modeling (ORM)  each fact type (relationship) involves a number of roles, hence, roles are named placed in the relationships.

Taking into account the complexity of the notion of role and the lack of support for roles in present conceptual modelling languages, it is clear that patterns to define such a common construct are needed in conceptual modelling.

Ideal Properties of a Role Modeling Solution

To account for the complexity of the notion of roles and variety of semantics found in them, we describe below the set of features that roles should meet, most of which have been identified by Steinmann .  In our case, these features are the forces that influence and should be resolved by the pattern.

We describe them by using some examples related to the scenario introduced above:

1. A role comes with its own properties and behaviour, i.e., an instance of Employee has its own properties which may be different from the ones of the entity type that plays such a role.
2. An instance of a role is related to a unique instance of its entity type and its existence depends on the entity type to which it is associated to, i.e., it is not possible to have an instance of Student not related to an instance of Person. Although a fundamental characteristic, there exist proposals considering that a role should remain unconnected to any entity type, for instance, to model the salary of a vacant position for department manager [‎36]. This work does not address such possibility.
3. An entity may play different roles simultaneously, i.e., an instance of Person may play simultaneously the role of Student and Employee.
4. An instance of an entity type may play several instances of the same role type at the same time. For instance, a person that registers to more than one university has multiple instances of Student related to it.
5. An entity may acquire and relinquish roles dynamically, i.e., a person may become a student, after some years become an employee, finish his/her studies, become a project manager, start another program and so forth.
6. The sequence in which roles may be acquired and relinquished can be subject to restrictions, i.e., a person may not become an employee after he/she has retired or when he/she is also studying two degrees. Note that this does not prevents an employee from studying two degrees in the future. The restriction needs to be true only when hiring the employee.
7. Roles can play roles. This mirrors that an instance of Person can play the role of Employee and an instance of Employee can also play de role of ProjectManager.
8. Role identity. Each instance of a role has its own role identifier, which is different from that of all other instances of the entity to which is associated with. This solves the so-called counting problem introduced by Wieringa et al in [‎44]. It refers to the fact that we need to distinguish the instances of the roles from the instances of the entity types that play them. For example, if we want to count the number of people that are students in a university (i.e., every person who is registered to at least a program in such university), the total number is less than the number of registered students in such university (in this case a person is counted twice if he or she is registered at two programs).
9. Roles do not inherit properties from their entity types. Instead, instances of roles have access to some properties of their corresponding entities i.e., Student may adopt name and address properties of Person but neither religion nor marital status properties. Therefore, the Student role cannot use the last two referred properties.
10. Relationship independency. A role is meaningful even out of the context of a relationship. E.g., a person may play the role of student or employee without necessarily being tied to a university or a company
11. Common role for unrelated types. A set of unrelated types may play the same role [‎3]. For instance, a project manager may be the role of both employee and external service provider.
12. Sharing structure and behavior. Roles may have some common structure and behavior. For instance, the constraint that Maria may not become an employee before she is 16 years old should apply also to project manager.

Our solution: Roles as Entity Types

Previous existing patterns covered only a subset of the required role features. We propose to use our Role as Entity types pattern when the full expressivity of the role concept is needed. The basic aim of the pattern is to represent roles as an entity type related to the entity type playing the role by means of a special kind of relationship type, the RoleOf relationship type.

We believe there is not a fundamental difference between roles and entity types since roles have their own properties and identity. Therefore, when using this pattern we represent roles as entity types with their own attributes, relationships and generalisation/specialisation hierarchies. For practical reasons, we call role entity types (or simply role if the context is clear) the entity types that represent roles and natural entity types (or simply entity types) the entity types that may play those roles.

We define the relationship between a role entity type and its natural entity type by means of a new generic relationship type, the RoleOf relationship. A generic relationship type is a relationship type that may have several realizations in a domain.  Each realization of this generic relationship type is a specific relationship type relating a natural entity type to a role entity type to indicate that the natural entity type may play the role represented by the role entity type.

In the relationship type we also specify the properties (attributes and associations) of the natural entity type that are adopted by the role entity type. Note that, since roles may play other roles, the same entity type may appear as a role entity type in a RoleOf relationship and as a natural entity type in a different RoleOf relationship. Although this representation may be expressed in many conceptual modelling languages, in this work, we only adapt it to UML and OCL.

To represent the RoleOf relationship we use the standard extension mechanisms provided by UML, such as stereotypes, tags and constraints. We represent the RoleOf generic relationship type by means of the «RoleOf» stereotype. The base class of the stereotype is the Association metaclass, which represents association relationships among classes. Each specific relationship type is labelled with this stereotype. The stereotype also permits the definition of the properties the role adopts from the natural entity type. They are represented with a multivalued attribute, called adoptedProperties. Figure 6 shows the definition of the «RoleOf» stereotype

As an example, figure 7 shows the running example introduced before using this pattern. Note that all roles are represented as entity types with a «RoleOf» relationship type relating the role with is entity type. For instance, the role Student is represented as an entity type related to Person through a «RoleOf» relationship type. In the relationship type it is also indicated that student adopts the properties: name, address, phone# and country from Person (its natural entity type). Employee participates in three «RoleOf» relationship types, one as a role of Person and the other ones as a natural entity type playing the role of ProjectManager and DepartmentManager.

Properties adopted by the role from its natural entity type may be considered as implicit properties of the role entity type. Nevertheless, in order to facilitate the use of these adopted properties (for instance, when writing OCL expressions) we may need to include them explicitly in the role entity type. In this case, we add an extra property in the role entity type for each adopted property. These extra properties are labeled with the «adopted» stereotype to distinguish them from the own properties of the role entity type. In addition, they are automatically derived and added to the schema.

So far, we have introduced a representation of the static part of the Roles as Entity Types Pattern. Nevertheless, this is not enough since role instances may be added or removed dynamically from an entity during its lifecycle and this addition or removal may be subjected to user-defined restrictions.

Since roles are represented as entity types we may define constraints on roles in the same way we define constraints on entity types. Some of the constraints are inherent to our role representation (for example, that a person must play the role of Employee to play the role of ProjectManager, is already enforced by the schema). Other restrictions may be expressed by means of the predefined constraints of the UML. For example, to restrict that an Employee cannot play more than twice the ProjectManager role simultaneously, it is enough to define a cardinality constraint in the relationship type. The definition of the rest of constraints requires the use of a general-purpose language, commonly OCL in the case of UML, see the full paper for details.

Note that the pattern achieves most of the role features outlined before:

1. Ownership. As roles are represented as entity types, they may have their own properties.
2. Dependency. The cardinality ‘1’ with the tag {readOnly} ensures that all role instances depend on a unique instance of the natural entity type.
3. Diversity. Entity types may have many RoleOf relationships.
4. Multiplicity. This is obtained by defining a cardinality greater than one in the RoleOf relationship.
5. Dinamicity. Entities are related to their roles through an association. Thus, an entity may acquire or retract instances of a role at any time.
6. Control. The sequence in which roles may be acquired and relinquished can be subjected to restrictions, including creation-time and deletion-time constraints.
7. Roles can play roles. Roles are represented by ordinary entity types. So, they can be participants of a RoleOf relationship.
8. Role identity. As roles are represented as entity types, their instances have their own identifier.
9. Adoption. The adoptedProperty tag of the RoleOf relationship allows the definition of the adopted properties.
10. Relationship independency. As entity types, roles are independent from relationship types.
11. Different roles may share structure and behavior. As entity types we can define generalization relationships between roles.

As a trade-off, our pattern does not directly support the remaining feature (11. Common role for unrelated types). However it can be easily represented. For instance, if we need ProjectManager to be the role of both Employee and ExternalServiceProvider, we could define a common supertype for Employee (understood as InternalServiceProvider) and ExternalServiceProvider, called ServiceProvider, which plays the role of ProjectManager.

An alternative is to define two different RoleOf relationship types, one between ProjectManager and Employee and another one between ProjectManager and ExternalServiceProvider. Both relationship types are specified with a xor constraint to prevent a project manager being an employee and an external service provider at the same time. ServiceProvider is not needed. On the other hand, the management of the adopted properties is more complex.