Interactions and Role Identification (IRI) aims at decomposing a global behavior embodied by an organization into smaller interacting behaviors. Each of these finer grained behaviors will be exhibited by a Role. Interacting roles must be defined in the same organization that provides the interaction context. The goal of each Role is to contribute to the fulfillment of (a part of) the requirements of the organization it belongs to.

This activity also aims at completing the system delimitation started in the domain requirements description activity. Before trying to develop a system, the perimeter of the application has to be defined. Role is a parametrized class that can be instantiated in Common Role (often called just Role) or Boundary Role. This latter has been designed to work at the borders of the designed system. Boundary Roles can be, for instance, used to control external sensors/effectors or to interact with other agent-based and non-agent-based systems. The resulting diagram is a class diagram where classes represent roles (stereotypes are used to differentiate common and boundary roles), packages represent organizations and relationships describes interactions among roles or contributions (to the achievement of a goal) from one organization to another. Performing this activity is usually an iterative process coordinated with the following Scenarios Description one. In this latter, the elements (mainly roles) here depicted from a structural point of view are exploited in their dynamical behavior.



Role identification aims at decomposing a global behavior embodied by an organization into smaller interacting behaviors. Each of these fine grained behaviors will be represented by a role.


The associations between requirements and organizations, and the relations between concepts inside the domain ontology constitute the inputs for the Role Identification activity.


To describe the static structure of an organization an UML profile for class diagram is used. Each role is represented by a stereotyped class and interactions are represented by associations between roles.

MAS Meta-Model Elements

Define(AbstractRole), Define(Interaction), Relate( Organization, AbstractRole), Relate(Organization, Interaction), Relate( AbstractRole, Interaction).

Work to be done

Role and Interactions are deduced from the set of text descriptions of the system usage scenarios, and from the previously identified organizations. The use of Organizational Design Patterns can also offer a good way to validate the behavioral decomposition by trying to match the current solution to an already well-know one.

Methodological Guidelines

The first step consists in looking into scenarios that can be deduced from use case diagrams to identify interactions. Let us suppose, for instance that organization O1 is assigned to fulfill requirements represented by use cases A and B. Use case B has an ’include’ relationship with use case C assigned to organization O2. This encourages the designer to explore the possibility of a scenario where a role of O2 interacts with another role of O1 in order to provide to O1 the result of a capacity that belongs to O2. Another guideline for roles identification consists in looking at the structure of the ontology in order to find elements that suggest some hierarchical structure that could evoke an holonic configuration with interacting roles (usually such a configuration is also useful for organizations identification as it has been said before).

Suggested notation

The previous UML profile for class diagram introduced to describe ontology, is also used to statically describe organizations. Table 1 details the part of this profile related to organization description and the associated mapping between ASPECS meta-model concepts and UML constructs.

Table 1: UML Profile Detail for organization Description

ASPECS Item UML Construct UML Stereotype
AbstractRole Class role
BoundaryRole Class boundary role
AbstractCapacity Class capacity
Organisation Package organisation
Interaction Association interaction
Interaction Association Class interaction
Requirement Note description
Non functional Requirement Note description
This page was last modified on 1 August 2010, at 15:21. This page has been accessed 16,655 times.
Copyright 2010-2018 © IRTES Institute - UPR EA 7274 - Université de Technologie de Belfort-Montbéliard - Privacy policy