On the Integration of Roles in the UML

Technical Report No. 214

University of Paderborn, August 2000
Ralph Depke, Gregor Engels, Jochen Malte Kuster
Universitat Paderborn, Fachbereich 17, Warburger Str. 100, D-33098 Paderborn
email: {depke, engels, jkuester}@upb.de, phone: (+49)(0)5251/603357

Abstract. Conventionally, the state space and behavior of an object is determined when the object is
created. Attributes and methods are not allowed to be attached to or retracted from an object during its
lifetime. In other words, it is not feasible for an object to change its type dynamically. Furthermore, it is
not possible to define several different views on an object allowing to exhibit a specific view to another
object and hiding part of its features to a particular object. As a consequence, the concept of an object
does not reflect appropriately real-world entities which may change their behavior and exhibit only part
of their behavior towards another real-world entity. The concept of a role has been considered as an
appropriate step forward to solving these kinds of problems. In this paper, we examine the concept of
roles and elaborate a proposal for the integration of a clear concept of roles in the UML.

Introduction

Objects are entities that encapsulate data and provide services. When being created an object possesses
a fixed set of attributes and methods which are available until deletion of the object. It is not possible to
attach attributes and methods after the object was instantiated or to retract any of them before the object
disappears. The behavior of the object is fixed by the provided methods. This restriction poses a problem
in applications where an entity represented by an object of a specific class evolves over time and changes
its behavior.
Another drawback of the concept of an object results from the property that all public features like
attributes and methods are visible to all other objects in an association. However, often only part of the
behavior of an object is relevant in a particular association and therefore a means of restricting the visibility
to such specific attributes and operations is needed.
These problems of the object concept have already been discussed in the literature and the following
solution has been proposed: an object is allowed to play several roles which may change over lifetime
and an object may be in a specific role in an association with another object. Thus, the concept of a role
allows the description of behavior (by attributes and operations). Behavior defined in form of a role can
then be used for clarifying how an object behaves, over time or towards other objects. As a consequence,
roles enhance object-oriented modeling and make a model more understandable. The UML has evolved
as the standard for object-oriented modeling. UML incorporates several role concepts. The question arises
whether these role concepts fully support the idea of modeling with roles and if not how to define and
integrate a fully elaborated role concept in the UML.
Our objective is to enable modeling with roles in the UML. We start by defining the notion of a role
and establishing requirements for a role concept (see section 2), along with a practical example. These
requirements are then used for examining role concepts of UML. In the following sections, we show how a
clear concept of roles can be integrated in the UML. After the introduction of a new role-of relationship and
a new role class we demonstrate what benefits result and how the concept influences our running example.
The change of diagrams by the use of our roles is described in section 4. In section 5 we show that the
complexity of the metamodel can be reduced when using our notion of a role. Finally, we show how our
role concept relates to existing role concepts in the literature and draw a conclusion of our work.

Modeling with Roles

In this section an example is presented that demonstrates the use of roles. We derive key requirements of
a role concept which can also be found in the literature. Then we examine role concepts of the UML and
show that they do not meet the requirements of a role concept.
2.1

The Notion of a Role and Requirements for a Role Concept

A person in a university serves as our running example in order to illustrate the problems that we mentioned
in the introduction and that we are going to tackle.
From the view of the university a person is an employee. A person can also be a participant or a
lecturer of a course. As a consequence, a person has three different roles and it may hold any combination
of these three roles. That means that there are persons that are employees but not lecturers and there are
other persons that are lecturers and participants. A person may also have several roles of the same type. In
addition, persons do have relationships between each other. One person may be a tutor to another person
who is a Ph.D. student or a B.Sc. student. Therefore, a person may also have the role of a tutor or a student.
Any of the roles a person has demands different attributes and operations that are usually only relevant to
that role. However, behavior of a person is relevant to all of its roles (e. g. the birthdate of a person).
The concept of a role is intuitive and important in the modeling of real world phenomena like the one
presented in our example. We will first give a general definition of the notion of a role and then we explain
what properties of roles can be found in our example. Roles are defined almost consistently throughout the
literature [7, 3] (see our discussion of related work in section 6). According to Kristensen et al., a role of an
object is a set of properties which are important for an object to be able to behave in a certain way expected
by a set of other objects.
This definition is refined by a set of characteristic properties that concepts of roles should support [6,
3]:
visibility: The visibility and also the access to an object is restricted to the attributes and methods of
the role of an object and to the objects visible own features. If a student takes a course he/she knows a
person in the role of a lecturer. Also key features like the persons name are known. But the role of an
employee is not known and thus a student has no access to the salary of the teacher.
dependency: The existence of the role depends on that of the object it belongs to. This is very similar to
composition of objects from other objects. For example, if a person object disappears, so do the roles
the person plays. Roles may also be dependent from roles. For example, a person object who looses
the role employee also looses the role of a tutor.
identity: An object and its roles have one identity. It is manipulated as one entity. As a consequence,
this means that an actual role may not belong to different objects at the same time. There is always one
unique object or role that a role is mapped to.
dynamicity: Roles may be added and removed during the lifetime of an object. In our example, a B.Sc.
student may become a Ph.D. student. Thus one role is deleted and another one is created while the
related person object survives.
multiplicity: Several instances of a role may exist for an object at the same time. A person may be an
employee at two different universities getting two different salaries. On the instance level there are two
roles of the same role type attached to one person object.
abstractivity: Roles can be related to each other by aggregation and generalisation.
A role concept should support as many of these characteristics of roles as possible. These characteristics
can be viewed as requirements for a role concept and each role concept can be checked against these
requirements.
2.2

Current Support for Roles by the UML

In this section, different forms and understandings of roles in the UML are analyzed and it is shown that
these role concepts of UML do not meet the requirements.

3
employee
employer

birthdate : Date
name: Text
program: Text
position: Text

University

tutor

Person

lecturer 1

tutor

PhdStudent
BScStudent

*
participant

Course

Fig. 1. Class diagram of the university example

Rolenames in Associations In UML class diagrams, it is common practice to indicate the perspective of
a class in a relationship by a rolename at the end of an association.
In Figure 1 a class diagram for our example is presented. We distinguish between three different classes
of objects, a Person, a Course and a University class. Roles are modeled as rolenames at the associations.
For example, a Person is an employee in the association with the University.
In the UML, rolenames primarily serve the navigation in class diagrams and for intuitively defining a
role. The behavior of the role implied by a rolename may be specified in an interface class that comprises
a collection of operations. In the UML, behavior specified in an interface can be associated to a rolename
in an association by using an interface specifier.
Interfaces may only have a realization relationship which is depicted as a dashed line with a triangular
arrowhead. A realization relationship between a class and an interface class indicates that the class realizes
the behavior specified in the interface.
As an example of this concept, consider Figure 2. Here, an object of class Person plays the role of an
employee in a relationship with an object of class Company. Role behavior is specified in an Employee
interface. The behavior of the Person class in relation to the Company class is indicated by the interface
specifier of the Person class in the relationship with the class Company.

1 .. *
Person

*
Company

employee: Employee

<<interface>>
Employee
getEmploymentHistory()
getCompensation()
getBenefits()

realization

Fig. 2. Rolenames and interfaces in the UML

The mechanism of a rolename falls short of fully supporting the requirements of roles for the following
reasons. A rolename is only a sort of label and does not directly specify behavior. Behavior can only be
specified in interfaces. As a consequence, a rolename can only be bound to behavior specified in form of
operations, attributes are missing. The visibility property can be considered to hold if rolenames are used
together with interfaces. For example, in Figure 2 the visibility of a Person from the view of a company is
restricted to the behavior given by the interface Employee. A rolenames usage and identity are dependent

on the existence of the designated object. If a Person disappears also its associated rolename employee
does. Dynamicity is also supported because a link to an object may be created or destroyed during the
objects lifetime. For example, a link between a company and a person object can be established in order
to model a persons employment. Concerning multiplicity, rolenames do not provide the necessary means
of type and instance level. We conclude that the rolename mechanism does not fully support role concept
requirements.
Simulating Roles in the UML Other than rolenames there exists also the possibility to simulate roles with
existing mechanisms such as inheritance or aggregation. We now check each of these mechanisms against
the role requirements presented above (for an extended version of simulating roles the reader is referred to
Kristensen et al. [7]).

Course
*

lecturer

participant

topic : Text

registrationno: Int

Person
birthdate : Date
name: Text

Fig. 3. Simulating roles by multiple inheritance

interfaces: We refine our argumentation regarding rolenames and interface specifiers. If roles are identified with interfaces then they are not able to have state and thus to have attributes. As a consequence,
multiplicity of roles is not possible because it depends on the state of the role. The methods that realize
the interface remain accessible through the whole life of an object. Therefore dynamicity of roles can
also not be realized by interfaces.
multiple inheritance: If an object inherits from all its role objects then public attributes and methods
are visible to all other objects during the lifetime of the objects. Therefore, the visiblity and dynamicity
properties of roles get lost. Multiplicity of roles is also apparently not supported by this simulation. For
example, in Figure 3 a person allways has attributes of both the lecturer and the participant role and a
person can only be participant in one course.
aggregation: Roles depend on the object they belong to. This kind of dependency demands the role,
i.e. the part object to disappear when the object does. In an aggregation relationship the part objects
may exist independently of the aggregate object. In order to support this property the variant of aggregation named composition is the more appropriate, because it respects this kind of dependency. The
visibility of public features of a roles base object can only be obtained indirectly, because attributes
and methods are only accessible through navigation to the base object. For example, in Figure 4 the
persons attributes birthdate and name are not directly accessible to the employer.
We conclude that there exist no appropriate mechanisms in the UML for simulating roles. The composition relationship fulfills most criteria of roles but the behavior of the part objects lacks a roles ability to
access its base object directly.

Person
tutor

birthdate : Date
name: Text

*
employer
University

employee

salary : Int

PhdStudent
beginStudies : Time

Fig. 4. Simulating roles by composition

Roles in Collaborations Finally, UML 1.3 incorporates the notion of classifier roles in collaboration diagrams. According to UML 1.3 [9], a collaboration describes how an operation or a classifier is realized
by a set of classifiers and associations used in a specific way. In UML 1.3 (see [9], page 3-113), it is distinguished between two forms of a collaboration diagram, one at an instance level and one at specification
level. Instance level collaboration diagrams do not include any mechanisms for role modeling. A collaboration diagram at specification level shows the roles defined within a collaboration and consists of class boxes
for the classifier roles and lines for the association roles. According to UML 1.3, a classifier role specifies
a restricted view of a classifier (usually a class) and an association role specifies a restricted view of an
association used in a collaboration. Consequently, a collaboration specifies a view of a model of classifiers
and imposes restrictions on the participating instances of classifiers: Each instance of a classifier has to
conform to the corresponding classifier role. A classifier role may be realized by instances of one or more
classifiers (usually classes) which is indicated by a list of classifiers behind the classifier role. Additionally,
an interaction between classifier roles can be specified by attaching messages to the association roles. On
the instance level the stimuli have to conform to this interaction.
In Figure 5, the collaboration diagram at specification level contains the named classifier role Teacher
which is realized by an instance of the Person class. All referred classes must be specified in a class diagram.
The classifier role Teacher has different rolenames like employee, lecturer, tutor, each representing the role
of the Teacher (classifier) role in a specific association.

/ Teacher : Person
employee *

employer

tutor
1

student

/ Student : Person

1 lecturer

: University

participant

taken course

*
given course

: Course

Fig. 5. Collaboration diagram at specification level, taken from [9]

Again, we check the concept of a classifier role against role requirements. Classifier roles specify a view
on a classifier (usually a class), possibly with attributes and operations. They are thus conformant to the
definition of a role consisting of operations and attributes although features of classifier roles often remain
implicit in collaboration diagrams. By specifying a view on a class classifier roles provide the means of
restricting the visibility and access to an object. For example, in Figure 5 a person in the role of a teacher

has attributes and methods that differ from those of a person in the role of a student. Nonetheless, the
relationship of a classifier role and the class can only be expressed in textual form and only in collaboration
diagrams. Dynamicity is not supported by classifier roles because they only occur in collaboration diagrams
and there is no means of modeling how a classifier role changes its base class. Concerning multiplicity, a
multiplicity indicator which gives an upper bound for the element count of the set of objects can be added to
a classifier role. In Figure 5 there could be a limit on the number of persons playing the role of a teacher. But
in this way it is not possible to express that there are multiple instances of roles and its features related to
a single base object. Therefore the modeling of multiple classifier roles becomes impossible. Concerning
abstractivity, inheritance of classifier roles can be modeled in collaboration diagrams. Altogether, only
some role properties are supported by collaboration diagrams on specification level.
In the next section we will introduce a concept of roles in the UML in order to meet the requirements
formulated above.

A New Concept of Roles in the UML

For supporting the modeling of more elaborate properties of roles we introduce a new role-of relationship
in the UML. By use of this new relationship collaboration roles can be completly removed from the UML.
We introduce the semantics and the notation of the new relationship similar to the definitions in the UML
specification. Thereafter, we illustrate the use of the role-of relationship within a practical example and we
check the role requirements that we introduced in section 2.1.
3.1

The role-of relationship

Notation In a class diagram, a role-of relationship is displayed as an association with a full-filled triangle
on the side of the base class, see figure 6. In an object diagram, a role-of link is displayed as a link with a
full-filled triangle on the side of the base object.
Abstract syntax and semantics The role-of relationship is a directed relationship between two different classes, the base class and the role class, with the semantics that objects of the base class may play the
role defined by the role class. This means that an object of the base class may acquire and abandon behavior
defined in its role classes or, in other words, the whole can be seen from different changing viewpoints,
depending on the role the object plays. On the instance level, a role-of link connects an object of the base
class with an object of the role class.
Similar to other relationships, a role-of relationship may be adorned at the association ends with a cardinality. The cardinality at the base class is defined to be always one. The cardinalities impose restrictions
on object diagrams similar to those of ordinary associations. A role-of relationship between two classes
induces lifetime restrictions on instances of these classes. The lifetime of the instance of the role class is
directly dependent of the lifetime of the instance of the base class it is connected to by the corresponding
role-of link. The role-of relationship is defined to be a transitive one, i.e., a role of an objects role is also
one of the objects roles. Concerning the features of the base class and the role class, the role-of relationship requires that the sets of features of role class and base class are disjoint. The role-of relationship
causes public features of the base class to be visible in the role class. As the role-of relationship is a special
relationship, the base class has access to the public features of the role class.
The role-of relationship has a semantics which combines elements of generalization and composition.
In opposite to the inheritance relationship a part of the state and the behavior of an object can be acquired
after creation of an object and abandoned before disposal. Moreover, multiple role objects can be attached
to one base object. Cardinalities at role classes constrain the number of role instances, similar as known
from composition. Note that, other than generalization, a role-of relationship is also depicted in object
diagrams. This is because roles are objects on their own and they do only contain part of the attributes
they have access to. The other accessible attributes belong to the roles base classes. In opposite to the
composition relationship the state, the associations and the behavior of the base object are accessible in its
role objects in the same way as features of superclasses in an inheritance relationship. Shortly speaking,
the role-of relationship is structural equal to composition and supports the behavior of generalization.

3.2

The role-of Relationship in Class Diagrams

Applying the role-of relationship repeatedly for a role class taking the position of a base class leads to
the construction of so-called role hierarchies, see figure 6. Concerning the visibility of features, as this
relationship is a transitive one, this implies that an object of a role class may access all features of classes
which are above itself in the role hierarchy. This requires that all features of a role class are disjoint to the
features of a base class in order for being able to uniquely address features. This visibility of features of a
base class in a role class forms one of the main parts of the role-of relationship semantics. It allows us to
model an entity of the real world from different viewpoints, depending on the role it is in.

Person
name : Text
{overlapping}

v
*
*

Employee

University

salary : Integer

1
*

Student

Tutor

Teacher

tutor

startOfStudies : Date

tutorialTime : Time
tutorialSubject : Text

preferredSubject : Text

student

0..3

lecturer

{disjoint}

supervisor

BScStudent

PhdStudent

thesisTopic : Text

thesisTopic : Text

Rector

0..5

politicalParty : Text

supervised

Course

Fig. 6. Using the role-of relationship in a class diagram

In Figure 6, a refined version of the example in figure 1 is presented, making use of the role-of relationship. A Person may have the roles of an Employee, and a Student. The Employee role has got the role of a
Teacher and a Tutor. Note that, similarly to constraints used in a generalization relationship, overlapping
and disjoint constraints may be used for the role-of relationship. In this example, the role-of relationship
between Employee and Person and Student and Person is modeled as an overlapping one and thereby allows
a Person to simultaneously have both roles.
The role Student is also base class of the roles Ph.D. student and B.Sc. student. Thus, it is possible
to model that, for example, a student aims to get multiple B.Sc. degrees. If the student has got all those
degrees he/she looses the roles of class B.Sc. student and could possibly get the role Ph.D. student. The
disjoint constraint does not allow a student to be both a B.Sc. student and a Ph.D. student. Dynamicity and
multiplicity of roles have just been demonstrated and abstractivity is to follow. A rector of a university is
modeled as a special kind of teacher but a teacher is not able to become a rector. The classes teacher and
rector exclude each other. The visibility of the Persons attributes is restricted by roles appropriately. For
example, the university class is associated with the employee role class of Person and thus attributes like
the preferred subject of the Teacher role class remain invisible.
Representing roles as classes allows the modeling of attributes and operations specific to a role. Moreover, the introduction of role classes and the role-of relationship allows the modeling of dependencies and
relationships between role classes. For example, it is now possible to model that a Student (a person with

a student role) has got two different relationships, one with his/her Teachers and one with his/her Tutor.
Note also that now cardinalities between roles can be precisely visualized: A Person instance with the role
of a Student has exactly one link to a Person with a Tutor instance but may have any number of links to
a Person with a Teacher role. Furthermore, the establishment of a role-of link enables the modeling of
multiple role instance of one role class. For example, a Person may be employed by different employers
and therefore several role instances of the role class Employee might exist for one and the same base class
instance Person.
3.3

Checking Requirements of the role-of relationship

We will now check that the role-of relationship and role classes fulfill important role characteristics outlined
above. With regards to visibility, a role object restricts the external access to the public features (attributes
and methods) of the role object itself and to the public features of the base object. If a base object is itself
a role object the visibilty is extended to all base objects of the role object. Other roles (represented by
other role objects) belonging to an object are not visible except those roles that lie on a path to the root
class of the role hierarchy. The dependency of a role from the object is achieved by the semantics of the
role-of relationship which explicitly states lifetime dependency, i.e. a role object automatically disappears
together with its base object. Concerning dynamicity of roles, role objects are ordinary objects that have
an additional role-of relationship to a base object. Thus roles can be dynamically retracted from one base
object and then be attached to another object. The multiplicity of roles is obtained by the cardinality at the
role-of relationship. Finally, abstractivity of roles is possible because roles modeled as role classes may
be related to each other by generalization or aggregation.

Impacts on the Diagrams

The role-of relationship is not only effective in class diagrams but also in other kinds of diagrams. We
show that collaboration roles can be substituted by our new concept if only structural aspects are modeled.
We explain how sequence diagrams are affected by the role-of relationship and we also give some remarks
regarding use case and statechart diagrams.
4.1

The role-of Relationship in Collaboration Diagrams

takeOnNewJob(salary)

1. assignSalary(salary)
3. assignSkills(s)

prof: Person
Name = Meier

{new}
2. s := getSkills()

u1:University

e1:Employee
salary = 70000
skills = cs, math

e2:Employee {new}

{new}
u2:University

salary = 20000
skills = cs, math

Fig. 7. Modeling the dynamics of roles

Collaboration diagrams exist in two forms, at specification level and at instance level. It arises the
question what effects the introduction of the role-of relationship has on these diagrams. First, we will
deal with collaboration diagrams at instance level, then collaboration diagrams at specification level are
discussed.

Collaboration diagrams at instance level are object collaborations whose behavior is determined by the
attached message flow. In order to visualize an object and its roles, the role-of link is used. With help of
the role-of link, it is now possible to model that an object acquires and abandons roles during its lifetime.
In Figure 7, it is modeled how a Person being in the role of an Employee becomes another Employee at
another employer.

Person
name : Text

v
*

University

Employee

Person

salary : Integer

name : Text

v
1

Teacher

Tutor

preferredSubject : Text
1

Student
startOfStudies : Date

tutorialTime : Time
tutorialSubject : Text

lecturer

student
*

Course

Fig. 8. Class diagram representing collaboration diagram on specification level

Collaboration diagrams at specification level allow the modeling of ClassifierRoles and how they are
related in a system (e. g. Figure 5). In our approach, the introduction of specific role classes and the role-of
relationship allows the modeling of the static aspects already in class diagrams. As a consequence, specification level collaboration diagrams are only necessary for defining views in which also the interaction
between objects is specified. In Figure 8 a part of the class diagram or, in other words, a view on the class
diagram in Figure 6 substitutes the collaboration diagram on specification level in Figure 5. In the class
diagram the information about the owners of the roles is more explicit than in collaboration diagrams. A
more fine-grained modeling of the static structure is possible in class diagrams because role classes can
also be roles of other role classes, i.e. role hierarchies of a class are not possible in collaboration diagrams
on specification level.
4.2

The role-of Relationship in Sequence Diagrams

A sequence diagram presents the message flow between objects with respect to a timeline. In this context,
it arises the problem how to express a role-of link between two objects in this diagram form. Other than in
collaboration diagrams at instance level, these links are not displayed in a sequence diagram. However, the
visualization of such a link is important because on the contrary to ordinary links a role instance has access
to attributes and operations of its base class instance. We therefore make use of big dashed brackets which
group an object and its role objects in a sequence diagram.
In Figure 9, the application of the boundary is presented. In this sequence diagram, it is modeled how
a Person takes on a new job. The brackets uniquely assign the two Employee role objects to the Person
object p1 but not to p2. This grouping does increase the readability of the sequence diagrams because the
message getName() that is sent to the Employee e2 is implictly propagated to the Person p1 and not to the
Person p2.

10

e1:Employee

p1: Person

u2:University

p2: Person

takeOnNewJob(salary)

e2:Employee
getSkills()
assignSkills()

getName()

Fig. 9. Grouping of an object and its role objects

4.3

Roles in Use Case Diagrams

In use case diagrams an actor may be considered to play a separate role with regard to each use case with
which it communicates (UML specification [9], page 3-92). In order to make these roles explicit the names
of the roles are attached to the associations between the actor and its use cases. In Figure 10 an example
is shown. An actors roles can now be introduced into a class diagram as classes that are associated to the
actor class by a role-of relationship. In this way modeling of roles in use case diagrams gets more precise.

University
fix salary
employee

Person

PhdStudent

submit
thesis

Fig. 10. Roles in a use case diagram

4.4

Roles and Statechart Diagrams

Statechart diagrams are assigned to classes in order to specify allowed sequences of method calls on the
objects of the class. Regarding the statechart of a role class the behavior (methods) and the dynamics (state
charts) of its base classes must be taken into consideration. Methods of the base class can also be called
on its role objects. Thus, these methods have to be integrated in the roles statecharts and the sequences
of object method calls still have to be compatible with the objects statechart. The projections of the roles
statecharts have to be equal to the statechart of the base object.
For example, in Figure 11 the two substates of the statechart describe the behavior of the base class
and its role class which are depicted in the left. In the bottom compartment of the statechart the dynamics
of the role class and above the base objects dynamics is given. If in the roles statechart the roles own
methods are identified and if then the roles methods are eliminated this projection becomes equal to the
base objects statechart in the top compartment.

11
takeCourse()

Student
takeCourse()
succeedExams()
succeedInExams()

takeCourse()

PhdStudent
succeedInExams()
getThesisTopic()
writeThesis()
getThesisTopic()

writeThesis()

Fig. 11. Statechart diagram for an object and its role

Integration of the Role Concept in the UML

After introducing the role-of relationship it arises the need for an adaptation of the UML metamodel in
order to enable the usage of these concepts for the following reason: The role-of relationship is a special
form of relationship which is a mixture of generalization and composition and therefore cannot be expressed as a stereotype of those. In order to explain this in more detail the function of stereotypes has to be
made clear. By use of a stereotype an existing modeling element of the UML is further qualified by tagged
values and/or constraints (UML specification [9], page 2-68). The role-of relationship can not be defined
as a stereotype of the inheritance relationship because role objects are not instances of their base objects.
The composition relationship is another candidate relationship to be stereotyped. Because the semantics
of a roles behavior is extended to the direct access of the base objects features it is not possible to use
constraints that only allow restrictions on already defined behavior.
Role hierarchies are a concept that immediately results from the introduction of the role-of relationship.
Thus we introduce role classes into the metamodel that yield correct role hierarchies. Concerning the
distinction of a role class and an ordinary class, we take the position that RoleClasses are a specialization
of Class because also on the class level they can not be used independent of a base class. Note here that in
other modeling languages roles are part of the metamodel as well on the core level [4].
In Figure 12, it is presented how an extension of the metamodel may look like supporting the role
concept defined above. A RoleClass is introduced for modeling role classes. They are a specialization of
Class. The role-of relationship is modeled as a specialization of Association and connects RoleClasses with
base classes where a base class can either be an ordinary Class or a RoleClass. The role-of relationship
between Class and RoleClass models the dependency of a RoleClass on a a Class. A role class always
has exactly one base class. Modeling the Role-Of-Relationship as a subclass of Association induces that
a role-of relationship is just a special association with all association semantics (navigability, rolenames
etc.).
Constraints and characteristics of the role-of relationship as defined above must be expressed either in
the metamodel or by using additional OCL-constraints which we will sketch. One constraint of the role-of
relationship is that the cardinality at the base class end is always one. Every role object plays its role at
most to one other (role) object. Thus the aggregation attribute of the association end must be set to the
value composite. Role classes are part of a role hierarchy which is acyclic. This constraint is expressed by
OCL formulas:
not self.allBases includes(self )
base : Class
base = self.roleif ication.base
allBases : Set(Class)
allBases = self.base union(self.base.allBases)
Another characteristics is the disjointness of features of role classes in a role hierarchy which must be
expressed in the OCL in a similar way. Concerning the visibility of features of the base class in its role

12

Classifier

Association
Class
+base

+subjectification

isActive:Boolean

1..*

Role-Of
Relationship

{XOR}
1

RoleClass

+base

*
+subjectification

+roleification

1
+role

Fig. 12. Adapting the metamodel - part of core

classes and the delegation of messages from a role class to the base class, the part regarding behavior elements in the semantics part of UML specification has to be adapted. For example, the CallAction for a role
class demands that invocation of operations can also happen in a base class and not only in the role class.
Lifetime restrictions implied by a base class on its role classes cannot be defined in the metamodel but have
to be described in the semantics part of the specification.
Up to now we have enlarged the metamodel but in the part regarding collaborations the metamodels
complexity can be reduced strongly. Collaboration diagrams currently make heavy use of ClassifierRoles
which represent a view on a Classifier (see above). Currently, ClassifierRoles only exist in collaboration diagrams and have a semantics different from our RoleClasses: On the contrary to ClassifierRoles,
RoleClasses are instantiable classes and features of a RoleClass and its corresponding base class must be
disjoint. We have shown above that our concept of role-of relationship together with RoleClasses allows a
more detailed modeling of a class and its roles. We therefore recommend to substitute ClassifierRole with
Class in the metamodel of collaboration diagrams which leads to a substantial simplification of this part of
the metamodel. In particular, one is now forced to directly model role classes of a class with all features.
As a consequence, implicit declarations of roles (which can be done through ClassifierRoles without directly enumerating operations) is no longer possible. Our proposal has a trade-off because the behavioral
restrictions defined by interactions in collaboration diagrams on specification level can not be transfered to
class diagrams.

Concepts of Role Modeling in the Literature

We give an overview of related work on object oriented modeling of roles. Kappel et al. [5] introduce a
roleOf relationship between classes. One class is to play a role of the other, i.e. there is a mapping of the
role class to the base class given by the roleOf relationship. A role class does not inherit from the base
class. However, messages not understood by an instance of the role class are delegated to the instance of
the base class and thus this can be seen as inheritance on the instance level. By this mechanism, a role class
has access to instance variables and methods of its base class. Gottlob et al. [3] introduce role hierarchies
to model how an entity may evolve over time. A role hierarchy shows how entities might evolve over time.
It consists of a root type which must be a class type and role types related to each other by the roleOf
relationship which is the same as in Kappel et al. [5]. Several instances of a role type can belong to one
instance of a class type if the role type is qualified by an additional attribute. Kristensens approach [6, 7]
is similar to the one of Gottlob et al. [3] though a roleOf relationship only exists implicitly. Role classes
in structural diagrams are attached as bubbles to the base classes. Kristensen introduces the notion of
roleification as a kind of specialisation similar to inheritance. A role object has all own properties and
those of the base object but only own properties may be modified via the role.

13

Albano et al. [1] describe how their Fibonacci language supports objects with roles that are used as
interfaces to an objects attributes and methods. Steimann [11] examines roles in the UML and emphasizes
the similarity of roles and interfaces. In contrary, we consider roles that have attributes and also mulitplicity
demands roles to be instantiable which can not be done with interfaces Riehle et al. [10] emphasize the use
of roles in separate role models in order to relate role types. Role types that are appropriately related to each
other are then composed to classes. By use of our role classes role models can be built as class diagrams.
Relations between roles can be expressed as (stereotyped) associations.
Our own approach for a clear concept of roles in the UML relies mainly on the approach of Kappel [5]
et al. and Gottlob et al. [3] and also Kristensen [6]. However, our approach can be viewed as an extension
of their work because our concept of a role elaborates on the visibility properties of roles. Furthermore, we
have extended the concept of roles to collaboration and sequence diagrams.

Conclusion

In this paper, we have presented an UML extension for modeling an object and its roles. After a thorough
discussion of the concept of roles we have identified several shortcomings of the current role concept of
UML. Therefore, a role-of relationship has been introduced which allows the modeling that one class is a
role of another one. We have demonstrated how this new relationship allows the modeling of all important
aspects of roles such as visibility, dependency, dynamicity, multiplicity and role hierarchies. As the role-of
relationship induces a special semantics on the classes it connects we had to slightly extend the current
metamodel. Future work is to be done regarding the integration of roles in state chart diagrams. We also
started to introduce roles for the modeling of agent based systems [2, 8].

References
1. A. Albano, R. Bergamini, G. Ghelli, and R. Orsini. An Object Data Model with Roles. In Rakesh Agrawal,
Sean Baker, and David Bell, editors, Very large data bases, VLDB 93: proceedings of the 19th International
Conference on Very Large Data Bases, August 2427, 1993, Dublin, Ireland, pages 3951, Palo Alto, Calif., USA,
1993. Morgan Kaufmann Publishers.
2. Ralph Depke, Reiko Heckel, and Jochen Malte Kuster. Requirement Specification and Design of Agent-Based
Systems with Graph Transformation, Roles and UML. In Proc. ICSE Workshop on Agent-oriented Software
Engineering, Limerick, Ireland, June 2000.
3. Georg Gottlob, Michael Schrefl, and Brigitte Rock. Extending Object-Oriented Systems with Roles. ACM Transactions on Information Systems, 14(3):268296, July 1996.
4. Brian Henderson-Sellers, Colin Atkinson, and Don Firesmith. Viewing the OML as a Variant of the UML. In
R. France and B. Rumpe, editors, <<UML>>99 - The Unified Modeling Language, LNCS, pages 4966. SV,
1999.
5. Gerti Kappel and Michael Schrefl. Objektorientierte Informationssysteme. Springer-Verlag, Wien, 1996.
6. Bent B. Kristensen. Object Oriented Modeling with Roles. In Proceedings of the 2nd International Conference on
Object-Oriented Information Systems (OOIS95), Dublin, Ireland, 1995, pages 5771, London, 1996. Springer.
7. Bent B. Kristensen and Kasper sterbye. Roles: Conceptual Abstraction Theory and Practical Language Issues.
Theory and Practice of Object Sytems, 2(3):143160, 1996.
8. J.M. Kuster. Visual Modeling of Agent-Based Systems: A Role-Oriented Approach Using the UML. diploma
thesis, University of Paderborn, Germany, 2000.
9. Object Management Group. OMG Unified Modeling Language Specification Version 1.3, June 1999. Available
under http://www.rational.com/uml/resources/documentation/index.jtmpl.
10. Dirk Riehle and Thomas Gross. Role Model Based Framework Design and Integration. ACM SIGPLAN Notices,
33(10):117133, October 1998.
11. Friedrich Steimann. Role = Interface, A Merger of Concepts. Journal of Object-Oriented Programming, 2001. To
Appear.