Interactions and Role Identification
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 represented by an Abstract Role. Thus, an AbstractRole is the abstraction of a behaviour in a certain context defined by the organisation and confers a status within this context. Abstract Roles interact according to one or more specific interaction patterns. An Interaction is composed of the event produced by a first role, perceived by a second one, and the reaction(s) produced by the second role. The sequence of events from one role to the other can be iterated several times and includes a not a priori specified number of events and participants. Interacting roles must be defined in the same organisation that provides the interaction context. The status of an Abstract Role is defined as a set
of rights and obligations available to the role, and also defines the way the entity playing the role is perceived by other entities playing another role in the same organisation. Specifically, the status gives the playing entity the right to exercise its capacities (know-how). Another important aspect is that the role (and not the individual, like an agent or an holon, which plays the role) belongs to the organisation. This means that the same individual may participate to an organisation by playing one or more roles that are perceived as different (and not necessarily related) by the organisation. Besides, the same individual can play different roles in other organisations. The goal of each AbstractRole is to contribute to the fulfilment of (a part of) the requirements of the organisation within which it is defined. This also activity 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. AbstractRole is a parametrized class that can be instantiated in Common AbstractRole or Boundary Abstract-Role. This last has been designed to delimit the borders of the designed system.
A Boundary AbstractRole is an AbstractRole located on the boundary between the system and its outside and it is responsible for interactions happening at this border (i.e. GUI, Database, etc).
The associations between requirements and organisations, and the relations between concepts inside the domain ontology constitute the inputs for the Role Identification activity.
The UML profile for class diagram previously introduced to describe ontology, is also used to statically describe organisations. Each role is represented by a stereotyped class and interactions are represented by associations between roles. Roles are positioned inside packages representing organisations they belong to. Constraints about roles (for instance number of instances of the same role) are detailed by using OCL (usually reported by using notes in the diagram). Table 2 details the part of the previous profile related to organisation description and the associated mapping between ASPECS metamodel concepts and UML constructs.
| 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 |
|Table 2: UML Profile Detail for organisation Description |
MAS Metamodel Elements
Define(AbstractRole), Define(Interaction), Relate(Organisation, AbstractRole), Relate(Organisation, Interaction), Relate(AbstractRole, Interaction).
Work to be done
The first task aims at identifying roles; roles can be identified through the study of problem ontology and the hierarchy of previously identified organisations. Responsibilities are then assigned to each newly introduced role. These responsibilities have to correspond to a part of the requirements associated to their organisation. The third task is interaction identification. Interactions can be deduced from the study of the relationship between use case and the associated roles. Finally the last task consists in verifying the goodness of the adopted behavioural decomposition by studying the contributions from organisations at a given level to roles belonging to the upper level. Organisational Design Patterns may contribute to this task by offering a solution that helps in validating the obtained decomposition. When necessary constraints about roles and organisations can be expressed with OCL language.
The first step consists in looking into scenarios that can be deducted from use case diagrams to identify interactions. Let us suppose, for instance that organisation 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 organisation 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 a holonic configuration with interacting roles (usually such a configuration is also useful for organisations identification as it has been said before).
According to the previously identified hierarchy of organisations, the objective is now to decompose each organisation and precise the behavioural contribution of sub-level organisations to an upper-level organisation. In this example we used a top-down behavioural decomposition and studied at each level if it’s really necessary to decompose each role with a sub-level organisation or not. Figure 11 describes the result of this decomposition: the various organisations and their respective contributions.
At the top of the hierarchy, the Game Simulation organisation is decomposed using only one interaction and one role Team. An OCL constraint is added to specify that only two instances of this role are allowed in each instance of this organisation. This role is in charge of simulating the behaviour of a robots soccer team. Its complexity at this level is considered as too high and it will be decomposed into smaller interacting behaviours.
At the second level, the organisation Team Simulation is decomposed in four roles, three roles representing the contributions of previously identified sub-level organisations and an environmental role useful to provide required information about the Game Situation (players and ball position, score, etc). The Strategy Selector role is in charge of determining the best strategy to adopt according to the current situation. Each strategy correspond to a distribution of strategy roles like goalkeeper, near-defender, midfielder, shooter, etc. among the different players. Each robot soccer team is composed of five players. Applying a strategy thus consists in assigning to each player one of the five roles defined by the strategy. The association between player and role defined by the strategy is done by the Role Assigner role. The Players Simulator role is in charge of simulating the behaviour of the various players according to the chosen strategy. The global state of the game (players and ball positions, score, time, etc.) is maintained by the boundary role Game Observer. This role is also in charge of providing required perceptions to the others.
According to the work products of the organisation identification activity, each of the three first roles is associated to a use case and should be decomposed into sub-organisations. But at this step one can already decide that the behaviours granularity is sufficiently detailed. The Role Assigner and Strategy Selection role are considered as sufficiently detailed, the Players Simulator role may be decomposed. This reveals a new level in the hierarchy, and the Player Simulation organisation is introduced. It defines the Player role in charge of simulating the behaviour of a robot playing soccer and one boundary role representing the Play Field and maintaining the state of the game at this level of abstraction.
|Figure 11: Result of the Interaction and Role identification for the Robot soccer simulator example |