![](bg2.png)
ing the business by facilitating communication and
analysis. Moreover, if an organization holds a docu-
mented view on its business objects and their rela-
tionships, then this information may assist later reus-
ing the same business object across organizational
units and in other business processes.
However, properly identifying the business ob-
jects of an organization is not a simple task, espe-
cially when reuse is a concern. For instance, the
same business object may be manipulated by multi-
ple different activities in different business contexts.
On the one hand, each business object relates to a set
of multiple other business objects. This leads to a
highly connected relationship graph for every busi-
ness object, which may not be easy to document or
understand. On the other hand, a business object
exhibits different behavior according to the relation-
ships it has at a given time. For example, the same
entity depicting a business product plays different
roles when relating to a financial activity or to a
manufacturing activity, meaning that the object’s
visible attributes, methods and behavior as a whole,
may be different, depending on the object’s active
relationships. Furthermore, the specific usage con-
text of a business object also defines it behavior. For
example, in a given context, a business object may
behave as an activity when being executed by an
actor, and, in other context, it may behave as a busi-
ness entity when being inspected by an audit activ-
ity.
Despite these issues, identifying an organiza-
tion’s business objects and specifying their behavior
so that reuse is facilitated is fundamental to partition
the universe of process modeling into different areas
of concern, each of which can then be handled and
documented independently. In order to address these
problems, this paper proposes a set of organizational
concepts, modeled as business objects, where their
relationships are specified through the roles the ob-
jects play. A role describes the behavior of an object
in a specific relationship and context, i.e., how an
object is involved in a situation or what responsibili-
ties it has. These concepts are represented by object-
oriented constructs and are illustrated as a meta-
model using the Unified Modeling Language
(UML). This approach allows modeling a business
process by (1) depicting the individual structure of
business objects and (2) describing business object
relationships according to the usage contexts of the
objects.
The remaining of this paper is structured as fol-
lows: next section reviews role and business process
modeling. Section 0 describes how role modeling
can be used along with business process modeling to
increase its expressive power along with some ex-
amples of application. Finally, section 0 outlines
future work and draws some conclusions.
2 ROLE MODELING
From the perspective of sociological role theory, an
organization is a system of interactions between en-
tities constrained by norms and expectations. Enti-
ties can occupy a number of social positions and
play the roles associated with these positions. Inter-
actions are determined by the relationships among
the roles, and constitute the structural aspect of the
social system. They also include norms and rules
designed to regulate the behavior of entities so that
the goals of the system can be achieved. From this
viewpoint, the analysis and design of an organiza-
tional system should focus on the three building
blocks of a social system: the roles, the relationships
among roles and the regulations that constrain them.
Role theory defines concepts such as role and posi-
tion in order to specify the organizational structure.
In this perspective, Biddle and Thomas define a role
as a collection of rights and duties relating to a posi-
tion (Biddle 1979).
2.1 Roles and Software Engineering
Sociological role theory deals with collaboration and
coordination of actors, focusing on the position and
responsibilities of an element within an organization
or system. Nonetheless, the concept of role is also a
well-established modeling principle in computer
science that aims at separating multiple crosscutting
concerns existing in a given domain. It is used in
methodologies such as RM-ODP (ISO 1995) and
especially in object-oriented frameworks (Gottlob
1996, Kendall 1999, Halpin 2001). Here, a role is
defined as a set of its properties which are important
for an object to behave in a certain way as expected
by other objects. Therefore, a role translates the ex-
pectations other objects have upon an object. Roles –
just like objects – can be abstracted and later reused
as types, since they capture the similar behavior
properties of a class of individuals. Hence, there
may be several instances of a role at a given time.
Likewise, roles can also be decomposed and special-
ized and serve as a basis for reuse.
Roles emphasize on describing how objects in-
teract with each other. While classes define the
common capabilities of individual objects or in-
stances, roles focus on the responsibilities of ele-
ments within a system or organization. A role model
identifies the structure of elements and describes it
as a structure of roles. A role model is similar to a
UML collaboration diagram since both capture the
interactions between objects in a given scenario.
However, a UML collaboration diagram is subordi-
nated to class diagrams and is based on instances of
a specific application; its potential for reuse is thus
ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION
110