Up to now, a characterization of the environment where the system will be running after it is developed as well as the tasks of the target system have been specified without committing to a particular technology to solve the given task. In this section, we will now look at this and start with modeling the system according to the role concept of the multiagent programming paradigm. We will not only discuss the problem of finding role abstractions given the functional and physical constraints of the problem specification, but we will also look at the problem of how to assign particular role(s) to agents of the target system.
A major problem in the field of sociology is the delimitation of roles that occur within a society. In the design of a multiagent system, the software engineer is faced with the problem of role delimitation as well. He or she is given a functional specification and is the asked to transform this functional specification into a society of interacting roles.
In this section, we are concerned with the definition of the functional roles within the multiagent system, i.e. roles that are defined in terms of the tasks that must be carried out. A second group of roles in a multiagent system called interaction roles are prototypical roles that are used in the definition of interaction protocols that are used within the multiagent system. In the contract-net protocol, for example, the generic interaction roles manager and bidder must be implemented according to the particular context. Interaction roles, - despite of their name - however, are not a genuine part of the role view and are therefore discussed in the Interaction view .
In the course of defining the functional requirements of the target system, it is recommended to build a task hierarchy of the problem domain. Usually, this process leads to a task tree with the overall system task as the root of the tree that is decomposed into several sub-tasks. The leaves of the tree are either atomic activities that can be handled by a single problem solver or they are joint activities that require the collaboration of several problem solvers. The activities of the second group are handled in the Interaction view whereas the activities of the first group are subject to this view.
Each of the atomic activities given in the task tree is specified on an algorithmic level that uses the abstractions of the formal model to describe a particular problem solving strategy. The basic capabilities that are defined here will later be combined and used as the basis for the role delimitation process.
There are three potential ways to achieve this goal. The first approach is the classical top-down processing of the functional specifications. The specifications are decomposed into hierarchical sub-groups and these groups are then declared as the roles. This approach has the advantage that it is straightforward and that it usually leads to satisfactory results. Unfortunately, the approach assumes that the designer has the full flexibility in grouping the functionally decomposed units. However, this assumption does not hold for example in the case of a robotic application where the physical entities limit or even define the functional grouping.
Therefore, the designer may decide to go the other way round, namely to follow a bottom-up approach to identify the roles within the system. This approach starts from the physical grouping that is usually determined by the environmental context of the target system or by the physical capabilities of the existing entities and tries to create the interactions that fulfill the functional requirements. The idea is to apply linguistic case theory analysis on an informal task description as it is e.g. given by the Task view. First of all, Linguistic Case Theory assigns a set of slots to each entity in the problem domain. These slots are typically filled with nouns associated to each verb in the informal description and each slot reflects the semantic connection of the role inhibitor to others. The verb and the collected nouns then become potential candidates for role descriptions. Although this approach is in accordance with the organizational or physical constraints of the target system, in its pure form it is only applicable if such a physical grouping really exists.
In the MASSIVE design method, I have tried to combine the advantages of these two approaches and to avoid their limitations as far as possible. First of all, we need a new definition that combines the role concepts according to both strategies.
Definition[Role] A role is a logical grouping of atomic activities according to the physical constraints of the operational environment of the target system.
The above definition tries to combine the top-down and the bottom-up approach towards role delimitation by equally weighting the existing functional and physical groupings. The idea is to integrate the functional decomposition and the physical structure into a common role that fulfills the functional as well as the physical requirements. The resulting micro process for role modeling in MASSIVE is pretty much straightforward:
Thus, the two rules of thumb clearly relate to the concepts of coupling and cohesion.
Role assignment is the process of mapping roles onto agents. By defining agents as the sum of the agent architecture and the potential roles the agent can play, we are now faced with the task to group the roles in way such that each group of roles can be played by a single agent.
This role assignment within a multiagent system can either be static, i.e. the agent is assigned a particular role at system start-up or it can by dynamic, i.e. the role assignment to an agent can change during the agents lifetime. Furthermore, an agent can play its different roles sequentially or it can have several roles at the same time.
Static role assignment has the advantage that the system designer need not think about how the agents internal state changes during a role change can be modeled. The agent is bound to a fixed task and no intra-agent conflicts of any kind can occur. However, static role assignment is not feasible if different roles share particular resources, for example cognitive structures. The knowledge transfer from one agent to another can be prohibitive for a static role assignment and so a dynamic scheme must be applied.
Dynamic role assignment becomes a very difficult problem if all agents have the same capabilities and the role assignment process should be arranged by the agents themselves. However, generic interaction protocol for the dynamic assignment process exist.