(Created page with 'Interactions and Role Identification (IRI) aims at decomposing a global behaviour embodied by an organisation into smaller interacting behaviours. Each of these finer grained beh…')
Line 15: Line 15:
elements (mainly roles) here depicted from a structural point of view are exploited
elements (mainly roles) here depicted from a structural point of view are exploited
in their dynamical behavior.
in their dynamical behavior.
 +
 +
 +
== Goal ==
 +
 +
 +
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.
 +
 +
 +
== Input ==
 +
 +
 +
The associations between requirements and organizations, and the relations
 +
between concepts inside the domain ontology constitute the inputs for the Role
 +
Identification activity.
 +
 +
 +
== Output ==
 +
 +
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 assocations 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 belogs 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 profil 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.
 +
 +
 +
{| class="frametable"
 +
|+ 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
 +
|}

Revision as of 15:26, 29 July 2010

Interactions and Role Identification (IRI) aims at decomposing a global behaviour embodied by an organisation into smaller interacting behaviours. Each of these finer grained behaviours will be exhibited by a Role. Interacting roles must be defined in the same organisation that provides the interaction context. The goal of each Role is to contribute to the fulfilment of (a part of) the requirements of the organisation 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 parametrised 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 organisations and relationships describes interactions among roles or contributions (to the achievement of a goal) from one organisation 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.


Contents

Goal

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.


Input

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


Output

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 assocations 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 belogs 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 profil 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.


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
Table 1: UML Profile Detail for organization Description
ASPECS Item UML Construct UML Stereotype
Copyright 2010-2019 © IRTES Institute - UPR EA 7274 - Université de Technologie de Belfort-Montbéliard - Privacy policy