2.1 Running example: a conference management system

As a running example, let us consider an agent-based system for supporting the process of producing the technical program for an international conference (Cernuzzi & Zambonelli, Reference Cernuzzi and Zambonelli2006). The process may be subdivided into three phases.

First, the submission phase: the program committee chair (PC-Chair) and the organizers prepare and distribute the call for papers. The authors submit their papers which are classified. A submission number is assigned to each paper and the authors are notified.

Second, the review phase: the PC-Chair distributes the papers among the PC-Members and collects their reviews. The PC-Chair decides on the acceptance/rejection of the papers, and then notifies the decision to the authors.

Third, the publishing phase: the PC-Chair prepares the conference program including all the accepted papers. The authors of the accepted papers have to produce a revised version of their papers and send it to the publisher in charge of composing the proceedings.

Each phase involves different actors and may be supported by one MAS. In each MAS, software agents will be naturally associated with the actors involved in the process (authors, PC-Chair, PC-Members, reviewers) to support their work in the conference sub-organization. This may require the agents to interact both directly with each other (according to patterns that will reflect the patterns of interactions in the real-world organizations), and indirectly (via exchanges of papers and review forms). Indeed, the types and roles of the agents involved as well as the structure of the organizations and of inter-agent interactions naturally derive from the structure of the real-world organization. Nevertheless, for a conference, the overall structure of the real-world organization may dramatically vary from year to year for different reasons. Among them, the more relevant aspect is the number of submitted papers (which to some extent determines the size of the conference). Thus, the need to change the structure of the management process may be forced by the need to keep it manageable. This is particularly true for the reviewing phase, which involves a large number of actors, with different duties and variously interacting with each other.

Let us first assume that the conference organizers expect a limited number of submissions (small size conference), and then decide to organize the review process around a simple hierarchy in which the PC-Chair distributes the papers among all the PC-Members and waits for the reviews.

Now let us assume that the number of submissions is higher than expected, reaching a middle size conference, which may be organized with a limited number of Co-Chairs (two or three instead of a single PC-Chair). At this point, Co-Chairs may decide to distribute among them the papers according to a peer-to-peer negotiation process before assigning each paper to PC-Members. The resulting structure may be considered a hybrid organization in which the upper level (corresponding to all the different Co-Chairs) adopts a peer-to-peer approach while the PC-Members are hierarchically subordinated to the Co-Chairs’ paper assignments.

Finally, let us assume that the number of submissions is much higher than expected (large size conference). At this point, the conference organizers may decide to adopt a different structure, that is, a multilevel hierarchy, implying some change also in the underlying MAS supporting the process. In a multilevel hierarchy, the PC-Chair will have to play a new previously unidentified role of ReviewPartitioner, in order to partition papers by areas and distribute each group to specifically appointed Vice-Chairs, each one in charge of handling papers in his/her area of competence.

Another interesting aspect in the example of Conference Management System is that information about what the size of the conference will be (and thus about the most proper organizational structure to adopt) is generally available only a few days before the review process has to begin, that is, when the papers are being submitted. This could force a dramatically fast restructuring in the organization and, if the process is supported by an MAS, requires an extremely fast adaptation of the MAS structure. These problems, to different extents, are common in all those software systems devoted to support processes in an increasingly dynamic economy.

2.2 Adaptation

There exist different types of changeable systems, which in general may be classified into two categories:

• • Adaptable system: able to be modified by an external agent (with respect to a set of environmental states). In such systems, structural organization adaptation may be reached by adding, deleting, or modifying their structural elements (e.g. roles, dependencies, norms, ontologies, communication primitives).

• • Adaptive system: able to change itself by modifying its organizational design obtained by dynamic variation in emergent societies resulting from changes in the interaction between agents.

The changes in the organization are usually called adaptive changes (whether they occur within an adaptable or an adaptive system) and they may occur due to different reasons. Usually, environment changes and natural system evolution require adaptation of organizational structures. Moreover, MAS may also have to deal with changing goals. As a result, an adaptation of the organizational perspective in an MAS has to consider both the representation of the purpose and how this purpose is achieved through a control regime (norms and organizational rules).

Reorganization of organizations should therefore describe situations in which the operational behavior of the organization changes, due to changes in the social structure of the society, that is, roles, relationships, norms, or interaction patterns. In the example of the Conference Management System, such a situation may arise for the unpredicted large number of submitted papers. Moreover, in this case, we have to consider the problem of how one MAS can inspect and get feedbacks from the real-world organization to which it belongs in order to adapt accordingly.

In both cases, when the system needs to change its organization in order to meet radically changing goals or to adjust to changing environmental/resource constraints, this change can be achieved through the reallocation of roles and associations.

Independent of the type of reorganization, since an MAS is subject to changes in its structure and control regime, it is necessary to find methods and techniques to model and manage the needed flexibility for such evolutionary systems. Several research efforts are being devoted to study and promote self-organization in complex software systems and, specifically, self-adaptive capabilities for MASs (Zambonelli & Omicini, Reference Zambonelli and Omicini2004; Zambonelli et al., Reference Zambonelli, Gleizes, Mamei and Tolksdorf2005). These studies explore the possibility for complex MASs to either exploit adaptive self-organization phenomena or to promote self-inspection and self-reorganization in order to preserve specific functional and non-functional characteristics despite environmental contingencies. A number of algorithms and tools are becoming available, but the time for deployment of self-adaptive software systems and MASs has not yet come. In addition, it is worth outlining that, even if effective mechanisms of self-adaptation were available, the problem of having an MAS properly capturing not only the internal needs of efficiency but also the external needs of the stakeholders remains open. How can one MAS inspect and get feedback from the real-world organization to which it belongs in order to adapt accordingly?

Moreover, adaptive systems concern emergent organization structures that cannot be predicted at design time and thus changes cannot be guided. In this case, the support of a methodology may be centered just on the documentation of the particular organization structures the MAS assumes in a specific moment. Nevertheless, in adaptable MASs, the organization structure at a specific time is defined by the designer. This is a typical example of design decision that may be more naturally supported by almost any software engineering methodology, including the AOSE ones.

A possible way to anticipate such types of changes is to let the designers or agents choose a specific organization structure among predefined catalogs of different organizations which may be adopted by the MAS. In this case, such catalogs may be created using the abstraction, the models, and the notations proposed by an AOSE methodology. Nevertheless, it may be hard to really predict all possible situations.

Another possible way is to design self-adaptive MASs which are able to reconfigure themselves according to the changes in the real-world organization structure. In addition, in this case, up to now it has been very hard to design systems whose behavior may evolve in a controlled and reliable way. Therefore, a reasonable compromise solution is to have a methodology that facilitates the design of an MAS with a different structure. Such a solution is also to some extent a pre-request for future realizations of self-adaptive MASs.

2.3 Choosing the organizational structure

A relevant issue in the organizational perspective to deal specifically with adaptive changes is the choice of an appropriate organizational structure for a specific MAS. There are a number of (nearly orthogonal) forces that may drive the identification of an appropriate organizational structure. Such forces, considering the goals of the organization, include: the need to achieve organizational efficiency (or, equivalently, the need for the MAS to properly handle the computation and coordination complexity of a problem); the need to respect organizational rules (reflecting the control regime); and the need to minimize the distance from the real-world organization. All of these forces may contrast the desire to keep the design simple (for a more detailed discussion on the topic, the reader should refer to (Zambonelli et al., Reference Zambonelli, Wooldridge and Jennings2003). In the Conference Management System example, the organizational rules may be quite stable (e.g. the number of reviews for each paper; the conflict of interest, etc.) while the organizational efficiency and the proximity to the real-world organization are strongly related to the number of submitted papers.

Accordingly, whenever the forces driving the design choice of the organization structure change (or whenever their relative weights change), the original design choice may become inadequate. Thus, some adaptation to the organizational structure may be required to preserve the functional and non-functional requirements compliance of the MAS.

The choice of the organizational structure issue introduces the question about who can do this. The appropriate structure can be decided by designers or specific agents with the responsibility to control the overall organization. In both cases, normally the structure is decided externally and imposed on the MAS. Meanwhile, in other systems that are able to change autonomously, the structure may be directly proposed by specific agents or may be selected from a catalog of structure types predefined by designer or special agents. Hence, in both cases, the decision corresponds to agent/s of the MAS.

Another relevant issue is how to obtain the appropriate organizational structure. A possible way is by the continuous evolution of the structure self-controlled by agents and looking for a stable architecture. Likewise is the pre-designed evolution controlled by designers (Allen et al., Reference Allen, Douence and Garlan1997). In those cases in which agents are in charge of making a decision, it is important that they have adequate skills to achieve this. In this sense (Colman and Han, Reference Colman and Han2004) introduce the idea of the organizational management role, a specific role which is in charge of maintaining the representation or making a decision about restructuring the organization. In all the cases, an interesting issue is how AOSE methodologies support agent engineers in dealing with the adaptive changes, and the consequent problem of choosing an adequate organizational structure during the lifetime of the MAS. That is, it may be interesting to analyze how existing AOSE methodologies enable designers and developers to rapidly rework the structure of an MAS in order for it to suit novel needs.

3.1 A design-for-change perspective to support changes in organizational structures

Agent engineers and developers need the support of AOSE methodologies that explicitly cover all the aspects related to the definition of an organizational structure and the associated control regime, and therefore facilitate possible reorganizations during the evolution of the system.

To promote adaptability in MASs, the AOSE methodology process needs to incorporate some interesting principles of software engineering, namely: incrementality, modularity, and separation of concerns (applied in this case to the organizational perspective). Such principles have been considered critical factors in other software engineering areas (Booch, Reference Booch1994; Ghezzi et al., Reference Ghezzi, Jazayeri and Mandrioli1991; Rumbaugh et al., Reference Rumbaugh, Blaha, Premerlani, Eddy and Lorensen1991; Meyer, Reference Meyer1997; Sommerville, Reference Sommerville2007) and have to be applied both to the models and the process proposed by an AOSE methodology.

First of all, let us focus on the models. As we have seen in Section 2, any organization consists of structural and interactional aspects. Both aspects require to be explicitly specified during the design process. Therefore, in order to capture the structural aspect, an AOSE methodology will have to consider models for partitioning the whole system into groups of agents, specifying the relationships among these groups and, for each group, the roles participating in with their relationships, and thus modeling the topology of the global MAS and of any sub-organization in the MAS. Moreover, for each role, it is relevant to specify its goals and norms, which determine to a great extent the control structure.

However, to capture the interactional aspect, an AOSE methodology will have to include models for the patterns of interactions and norms and rules governing roles, agents, groups of agents, and the overall organization (i.e. the control regime). The lack of an explicit model of the structure and of the control regime of organizations makes it harder for agent engineers to adopt pre-designed organization structures and patterns available from a catalog.

Complementary, relevant considerations have to be taken into account on the processes proposed by the AOSE methodologies. A methodology should clearly separate those aspects of the system that are intrinsic to the definition of the problem itself from those that derive from contingent choices based on the actual characteristics of the operational environment and/or the real-world organization, particularly in the process of designing and developing an MAS. For example, in the Conference Management example, this means separating those functionalities and interdependencies intrinsic in a process of reviewing (e.g. functionalities of PC-Chair and of reviewers, and protocols for sending back review forms) from those that instead derive from a specific contingent choice (e.g. separating the role of PC-Member from that of the reviewers, and relying on paper bidding for assigning reviews). In that way, whenever unexpected changes occur, designers and developers are facilitated in identifying where to focus in order to restructure the MAS as needed without impacting on the whole system. This means that the analysis should not be affected by changes in the architectural/organization design.

In addition, separation of concerns has to be applied in order to differentiate inter-agent organizational aspects from intra-agent ones. This separation may facilitate in restructuring the MAS organization without having to rethink all of its roles and agents.

Finally, the process proposed by the adopted methodology may strongly influence the effectiveness of accommodating the needed adaptations. In effect, if a methodology prescribes too many steps to define an organizational structure or specify interaction patterns that influence the general behavior of the MAS, this implies less flexibility for the adaptive changes.

Therefore, some critical factors for an AOSE methodology to promote adaptability in MAS development are:

• • To prescribe the explicit modeling of the organizational structure (including sub-organizations) and control regime;

• • To separate functional requirement modeling from organizational structure modeling;

• • To differentiate intra-agents from the inter-agent organizational aspects;

• • To adopt a flexible and incremental process;

• • To exploit modularity in order to facilitate reuse and to constrain the changes to the strictly necessary components;

• • To promote a simple process (that does not prescribe too many steps and iterations to obtain the design models).

Taking into account such criteria, several AOSE methodologies proposed in the literature simply do not identify a clear separation between the intrinsic aspects of an MAS and the architectural aspects. For instance, methodologies such as Roadmap (Juan et al., Reference Juan, Pearce and Sterling2002), Prometheus (Padgham & Winikoff, Reference Padgham and Winikoff2002), MaSE (DeLoach et al., Reference DeLoach, Wood and Sparkman2001), AOR (Wagner, Reference Wagner2003), and DESIRE (Brazier et al., Reference Brazier, Jonker and Treur2002) simply consider the organizational structure to stem in an implicit way from the identification of roles/agents and their interactions, without promoting any modularity and separation of concerns. Accordingly, they inherently have some problems in dealing with adaptations of MAS organizational structures.

Other proposed AOSE methodologies explicitly face the problem of structuring the organization of the MAS enforcing somewhat some degree of modularity and separation of concerns that make them more suitable for adaptable changes. In the following discussion, we shall analyze some of the more recognized AOSE methodologies.

3.2 Gaia

The Gaia methodology (Zambonelli et al., Reference Zambonelli, Wooldridge and Jennings2003) explicitly focuses on using organizational abstractions to drive the analysis and design of MASs. It models both the macro (social) aspect and the micro (agent internals) aspects of an MAS. Moreover, Gaia devotes a special effort to model the organizational structure and to specify the organizational rules that govern the global behavior of the agents in the organization avoiding conflict based on self-interest actions.

Gaia prescribes clearly separating the analysis phase, where the basic characteristics of the system-to-be are captured and organized, from the architectural design phase, where all the results of the analysis are put at work to identify the most suitable organizational structure. The above clear separation, together with the specific structuring of the analysis phase and of its models, is an important factor to facilitate adaptive changes.

The result of the analysis phase in Gaia is very modular, clearly separating the basic characteristics/functionalities of the systems, (i.e. the preliminary roles and interaction models) from characteristics of the operational environment (i.e. the environmental model) and from any additional constraints that the MAS will have to respect (i.e. the organizational rules). This implies that whenever contingencies calls for a rethinking of some of the MAS specifications, the clear separation of concerns of the Gaia analysis models is likely to avoid a global rethinking of the whole analysis and, depending on the types of contingencies, promote a local tuning of a limited set of models. For instance, some functional change in how a sub-task is expected to be achieved will impact on the preliminary role model only; some changes in the global constraints that the MAS has to respect impy changes in the organizational rules only.

The prescriptions to explicitly model the organizational structure and to delay its identification to the architectural design phase are also of paramount importance. In fact, more than the outcome of the analysis, it is the choice of a specific organizational structure that is more likely to be affected by contingencies. Besides properly structuring the functional requirements of the analysis phase, the choice of a specific organizational structure has to take into account and is affected by a number of non-functional requirements and by various characteristics of the operational environment. Thus, whenever contingencies call for adaptive changes in the MAS, it is very likely that these contingencies will call for a new organizational structure, which in Gaia can be selected without globally affecting the design.

In fact, the analysis outcome of Gaia is a set of preliminary role and interaction models that exhibit no dependencies on a specific organizational structure. In the architectural design phase, after having chosen a specific organizational structure, the roles and interaction models can be finalized. Consequently, it is possible in the final role and interaction models to clearly identify those which are intrinsic to the systems (i.e. those already identified from the analysis that may be considered as functional roles and interactions) from those that derive from the adoption of a specific organizational structure. Accordingly, whenever contingencies call for a new organizational structure, the designer is clearly facilitated in determining which parts of the system require some sort of redesign and which parts, instead, can be left unchanged. For example, if a designer is forced to switch from the small conference design to the large conference design, due to the modularity of Gaia models and the clear separation from the analysis and architectural design phase, the designer can easily reuse all previously identified models of the analysis, reapplying them in the sub-hierarchies of Vice-Chairs and PC-Members, and introducing the new role of ReviewPartitioner to define the upper level of the hierarchy.

Thus, even if Gaia does not yet define any specific guideline for adaptive maintenance, its structuring of the development process somewhat facilitates adaptive changes, and also enables an effective reuse of previous experiences and models. In fact, an expert designer can easily apply known organizational structures possibly being supported by the availability of catalogs of organizational patterns in the context of a particular system, so as to more easily choose and specify a specific organizational structure for an MAS-to-be, and eventually easily reshape the organizational structure of an existing system that requires some adaptation.

3.3 Tropos

The Tropos (Bresciani et al., Reference Bresciani, Giorgini, Giunchiglia, Mylopoulos and Perini2004; Giorgini et al., Reference Giorgini, Kolp, Mylopoulos and Castro2005) framework aims at building agent-oriented software that operates within a dynamic environment. A curious thing is that the Greek etymology of the word means easily changeable/adaptable. Tropos is mainly requirement-driven, adopting the i* organizational modeling framework (Yu, Reference Yu1995), and views the information systems as social structures which are a collection of social actors, human or software, which act as agents, positions, or roles and have social dependencies among them.

Tropos supports four phases of software development mainly based on the actor, dependency, goal, and plan models. The early requirements analysis is concerned with the understanding of the problem through studying an organizational setting focusing on the intentions of stakeholders. Late requirements analysis results in a requirements specification that describes all functional and non-functional requirements for the system-to-be. In the architectural design, the system's global architecture, according to a specific architectural style, is defined in terms of subsystems, and interconnected through data and control flows that are modeled as dependencies. Finally, in the detailed design phase, additional details are introduced to define how the components present in the architectural model are going to fulfill its responsibilities according to the design patterns.

All analysis of system requirements in Tropos is based on the goals that must be achieved by the system-to-be, and on the identification of the actors (whether humans or agents) that should be considered to achieve these goals. These requirements are modeled in the goal and actor diagrams. Once all goals are identified and assigned to specific actors, the design phase aims both at producing the organizational structure of the systems (i.e. identifying relationships between agents) and at detailing the specific characteristics of the composing agents. To produce a software architecture, during architectural design Tropos concentrates on the key system actors, defined during late requirements analysis, and their responsibilities. These include the desired functionality of the system-to-be, as well as a number of related quality requirements (not functional requirements). Moreover, the analysis allows the evaluation of several alternative architectural styles, represented as operationalized softgoals, facilitating the designer in choosing a specific organizational structure.

An interesting aspect of Tropos is the definition of the organizational structure, which seems to be a key point for promoting adaptive organizational changes. Nevertheless, the topology (the organizational structure that we have referred to in this paper) of the global organization of the system-to-be is not explicitly modeled in Tropos. It is implicitly obtained by the dependence relations among goals of the different actors (including the system). Therefore, an explicit representation of the global structure, which is more likely to be affected by contingencies, may help agent engineers to accommodate adaptive changes.

However, some kind of changes in the control regime (i.e. those related to the interactions among agents) may be modeled by means of the actor and goal diagrams in terms of changes in the dependencies.

The incremental and partially iterative process promoted by Tropos is somewhat interesting to facilitate changes at the design time and, at some extent, after implementation of the MAS. However, whenever contingencies call for a rethinking of the global organization of the MAS, Tropos prescribes a return to actors and goal diagrams and possibly implies a global rethinking of the whole analysis effort, which is based on these two main models. In effect, having the general goal of distributing the papers among reviewers in the case of a large size conference, the designers have to introduce the new role of ReviewPartitioner in the actor models and its associated objectives and plans in the goal model. This influences all the successive phases proposed in the Tropos process.

3.4 INGENIAS

INGENIAS (Gómez-Sanz and Pavón, Reference Gómez-Sanz and Pavón2003; Pavón et al., Reference Pavón, Gómez-Sanz and Fuentes2005) proposes a refinement approach that follows the Unified Software Development Process (Jacobson et al., Reference Jacobson, Booch and Rumbaugh1999). In INGENIAS, the general approach to specify MAS is to divide the problem in more concrete aspects that form different views of the system. Such meta-models allow the designers to incrementally define the architecture and the functionalities of the MAS, by focusing on different points of view during development. INGENIAS considers five different models (instances of meta-models that describe system views): Agent, Interaction, Tasks and Goals, Organization, and Environment.

During the analysis phase, a meta-model acts as a guideline for the analyst, by indicating which entities have to be identified. In the design phase, the meta-model is refined, by identifying new components and relationships among them, in order to achieve the appropriate level of detail. The organizational viewpoint describes a framework where agents, resources, tasks, and goals coexist. It is defined by its structure, functionality, and social relationships. The organizational structure defines a decomposition of the MAS into groups and workflows. Such general structures are enriched by the workflows, related to the way to cover the functionalities, and the social relationships which can be established at different levels between organizations, groups, agents, or roles. Social rules state restrictions on the interactions between entities in the organization.

Complementary, the interaction model, describes how interaction among agents takes place with special emphasis on the protocol that follows the interaction. Such relationships clarify organization behavior and specify which constraints exist in the interaction among agents. Nevertheless, it is not clear if it is possible to specify rules which prevent malicious behaviors. Therefore, we consider that the modeling of the organizational structure is adequately covered and that the social relationships of dependency complemented with the protocols specification cover not only the main aspects of modeling the control regime but also the general organizational rules.

The incremental approach adopted by INGENIAS makes it somewhat suitable for accommodating possible changes arising during the design and the development process. Whenever contingencies call for a rethinking of some of the MAS specifications, the separation of the modeling activities in different views may facilitate in avoiding a global rethinking of the whole solution. Specifically, possible adaptive changes are more likely to affect the choice of a specific organizational structure, the modeling of which is strongly related to the organization and interaction models. The organizational view describes how the system components are grouped together, which indicates the interaction among the agents, and considers the satisfaction of a set of goals. In the analysis–inception phase, organization models are produced to sketch how the MAS looks like (the MAS architecture) with an organizational model. This result is refined in the analysis–elaboration phase to identify the common goals of the agents and relevant tasks to be performed by each agent. In the design–elaboration phase, designers add workflows among the different agents to improve the organization model. Finally, in the design–construction phase, social relationships of dependency (in the form of subordination and client–server relationships) are defined. Considering the scenarios of the running example, to deal with the change in the structure of the organization, designers have to redo a lot of workflows in order to obtain the new models. In effect, it implies passing again from the analysis–inception (with the sketch of the new MAS architecture) phase up to the design–elaboration (with the definition of dependencies) phase to obtain a modified organizational model. Moreover, this approach would be limited by the inherent dependencies among different views.

As we have seen, the process of designing and developing MAS with INGENIAS is well structured, incremental, and considers complementary perspectives in the high number of workflows it proposes. At the same time, the process is quite complex due to the many activities the designers have to perform in order to produce the different models before the developing stage. Hence, for the case of adaptive changes claimed by different circumstances, the process proposed by INGENIAS tends to reduce the facility to easily accommodate such changes.

3.5 Process for Agent Societies Specification and Implementation

The Process for Agent Societies Specification and Implementation (PASSI) methodology (Cossentino and Sabatucci, Reference Cossentino and Sabatucci2004) is based on several years of experiences in modeling and developing robot systems and with the aim of designing MAS in an iterative-incremental approach.

PASSI is constituted of five main models (System Requirements, Agent Society, Agent Implementation, Code, and Deployment) and facilitates a clear separation in perspectives of the design process of MAS. The five perspectives considered are:

• • The Architectural perspective: abstraction of the whole system as a set of functionalities and their logical implementation;

• • The Social perspective: to capture the society of agents that interact to reach the goals of the system;

• • The Knowledge perspective: focusing on each single agent, and its functional and behavior details;

• • The Resource perspective: oriented toward the reuse of patterns of agents and their tasks;

• • The Computer perspective: considering the spreading of the files that constitute the agent-based system and the influence of the available hardware platform.

Clearly, the two main perspectives related to the adaptable organizational issues mentioned above are the Social and the Architectural ones.

The Architectural perspective covers the system requirements and the agent implementation models. However, the first one only focuses on the functional description of the system, starting from the traditional use-case modeling with scenario specifications, and then identifying the agents and specifying their roles and tasks, without explicitly considering the goals of the MAS. The Agent Structure Definition phase captures the general relationships among agents of the system by means of a class diagram. To some extent, such diagram is related to the organizational structure of the MAS but it does not adequately cover relevant aspects like topology. Consequently, it may not be so easy to accommodate possible adaptive changes in the organizational structure during the evolution of the MAS.

In the Social perspective, some complementary aspects of the relationships and dependencies among agents (taking into account their roles) are captured in the Role Description phase. The authors state that in the same phase the social rules and behavioral laws of the society of agents may be expressed; however, in the bibliography, we have not found any available examples. Moreover, the interaction among agents is covered in the Protocol Description phase and the communications aspects are partially captured in the Communication Ontology Description diagram. In addition, relevant aspects of each single agent are captured by means of the Agent Behavior Description phase. However, in your best known, no stress is devoted either to the global organizational structure or to the general rules governing the overall system.

Considering the PASSI process, incrementality toward different iterations can in general help in accommodating changes during the design time. However, if adaptations arise after the deployment of the MAS, the great number of phases in a cycle may require a long time before accommodating the changes in a new prototype code. As an example, for distributing the papers among reviewers in the case of a large size conference, the designers have to introduce the new role of ReviewPartitioner. This change does not affect the Agent Identification model (it holds the agent PC-Chair with different instances for the General Chair and the Vice-Chairs), but agent designers have to define a new role in the Role Identification step, which is part of the System Requirements Model and the Agent Society Model. Moreover, the Role Description, the Tasks Specification, the Agent Structural Definition, and the Agent Behavior Description (including the multiagent description and the single-agent description diagrams) phases need to be modified accordingly.

Therefore, we consider some limitations of adaptive changes. The first one is that in PASSI not all the aspects of organizational structure are explicitly modeled (or at least the lack of enough information on the specification of the control regime). The second limitation would be the vast number of steps and models that need to be modified to accommodate changes to the global MAS organization. Nevertheless, an Agile version of PASSI has been proposed (Chella et al., Reference Chella, Cossentino, Sabatucci and Seidita2004) which preserves the iterative and incremental nature, but by following the ideas of agile processes, it leads to a quicker process more oriented to code delivery than to documentation production.

3.6 Organizational Model for Normative Institutions

OMNI (Organizational Model for Normative Institutions; Dignum et al., Reference Dignum, Vázquez-Salceda and Dignum2005) is a framework for modeling different types of MAS ranging from closed to open flexible systems, especially emphasizing the organizational and normative perspective. This framework is composed of three dimensions, namely, Normative, Organizational, and Ontological. OMNI considers three different levels of abstraction: abstract (similar to the first step of the requirement analysis), concrete (analysis and design process), and implementation (in a given multiagent architecture). For our purpose, we focus the discussion on the concrete level, which is strongly related to the analysis and design of MAS.

The concrete level of the Organizational dimension specifies an Organizational Model by means of the social and interaction structures. The social structure consists of roles and groups (set of roles) and is represented in terms of a role hierarchy with the specification of role dependencies (bidding, request, and delegation). These characteristics may help to better capture the structure of the MAS. The interaction structure specifies the transition relationship between a set of scenes. Each scene describes the roles involved, the interaction pattern, the desired results, and the norms regulating the interaction.

These structures need to be connected with the role norms, scene norms, and transition norms, defined in the normative dimension, and with the ontologies and communication languages defined in the Ontological dimension.

In the Normative dimension abstract, norms are iteratively refined into more concrete norms, which are then translated into the rules, violations, and sanctions that implement them. Such a dimension covers the control regime specification. Finally, in the Ontological dimension, OMNI describes both the content (domain ontologies) and the communication acts that define the interaction languages used in the organizational model.

The structure of the organization is explicitly modeled in the Organizational Model according to the predefined types of society (market, hierarchy, or network) and the identification of the basic roles and of the interaction structure. Since OMNI is proposed for open societies of agents, the structure model is partially reduced to the predefined types of society. Complementary, one of the strong points of OMNI, is the normative dimension which covers the norms and rules for both agents and the organization and, in addition, the violation cases and corresponding sanctions for such norms. Consequently, in this dimension, it is easy to accommodate adaptive changes.

However, the process implicitly adopted by OMNI applies the modularity principle and makes a clear separation of the organizational structure from the control regime (normative dimension) perspectives. Moreover, it allows the designer to model them in an incremental way during the concrete level of abstraction. Considering the running example, to accommodate the structural changes for the case of switching from a small to a large size conference, the designers have to introduce the new role of ReviewPartitioner and some interactions. Both are considered in different steps of the Organizational Model and imply changes in the Role Hierarchy graph and the Role Dependencies graph. Nevertheless, OMNI does not prescribe separation between the functionalities and the organizational structural design, which is obtained by associating objectives and roles and decomposing them into sub-roles (both are jointly carried on in the concrete level), and between inter-agent and intra-agent organizational aspects. Thus, when adaptive changes call for modification in the organizational structure, designers have to devote consistent effort to adapt the overall organizational dimension at the concrete level, and particularly the role hierarchy as well as the role dependency models.

3.7 Discussion and open issues

Current methodologies for MASs design focus on the analysis of the initial requirements and their consequences for MAS design, but do not often provide explicit guidelines for reorganization and adaptation of the organizational structure later on. As we have seen, to facilitate the accommodation of adaptive changes in the MAS organizations, different aspects have to be considered.

Two directly related abstractions that are necessary in modeling the organizational perspective are the organizational structure and the control regime (Fox, Reference Fox1981), which govern the general behavior of the MAS. As discussed in the previous subsections, whenever methodologies do not subscribe to explicitly model organizational structures and the control regime, it can be more difficult to accommodate their probable changes. All the surveyed methodologies cover those aspects to different extents. More specifically, they cover the organization structure specification, but PASSI and Tropos would need to explicitly model the topology to better help agent engineers to accommodate adaptive changes. In the control regime specification, Gaia and INGENIAS offer the most interesting approaches, with PASSI proving very promising (but agent researchers and engineers need more clear documentation and examples).

Furthermore, as stated in Section 3.1, the application of some interesting principles strongly adopted in traditional software engineering may facilitate the building of adaptable and adaptive MAS. Among them, design-for-change, incrementality, modularity, and separation of concerns seem to be very relevant. Each methodology analyzed so far covers such aspects in a different way. Gaia prescribes a good separation of concerns, focusing specifically on a separation between the general functional and not functional requirements and the organizational ones. However, its incremental process is based on a waterfall-like model and consequently is not iterative. Tropos promotes an incremental and partially iterative process that is somewhat interesting to facilitate adaptive changes of the MAS. Still, the separation of concerns for the organizational perspective is not so clear and possibly implies a global rethinking of the whole analysis to accommodate adaptive changes. INGENIAS adopts an incremental approach and the separation of the modeling activities into different views, which may facilitate in reorganizing adaptable MAS. Nevertheless, the process proposed by INGENIAS implies passing again from the analysis-inception phase up to the design-elaboration phase to obtain a modified organization model. PASSI is intrinsically incremental-iterative driven but prescribes a great number of phases in the process cycle, which implies a great effort to accommodate changes. Moreover, PASSI facilitates a clear separation in perspectives of the design process of MAS, but we consider a limitation for adaptive changes that not all the aspects of organizational structure are explicitly modeled.

Other general considerations can be made on the design and construction processes for adaptable MAS. A first consideration is that most of the methodologies are concerned with the analysis and design processes only (Cernuzzi et al., Reference Cernuzzi, Cossentino and Zambonelli2005); few are trying to cover the development and deployment of the system; fewer yet are concerned with the maintenance stage of the system. Thus, even when a methodology is more suitable for a design-for-change perspective, specific attention to the maintenance process and definition of proper guidelines for change and adaptation are lacking, which is a great limitation for modern methodologies. It is also worth outlining that the dynamism of modern scenarios and the need for nearly continuous adaptive changes make the traditional waterfall software process model, upon which most methodologies explicitly or implicitly rely, very unsuitable (Cernuzzi et al., Reference Cernuzzi, Cossentino and Zambonelli2005). Evolutionary process models and, more specifically, agile extreme process models may better facilitate engineers in the design and building of adaptable MAS. However, current agile and extreme software process models focus on small-to-medium size projects, and they are not yet ready to tackle the complexity of developing large-scale adaptable and adaptive MAS.

Despite such considerations, different open issues may be envisioned for methodologies to better capture the organization perspective in MAS design. One of them is related to the notations adopted for modeling the organizational structures. In our opinion, this is an open issue for all the methodologies. The challenge is the need to combine the advantage of organizational theory notations with the representation of MAS abstractions. In this sense, an interesting suggestion may be offered by the Agent Modeling Language (AML) approach (Cervenka et al., Reference Cervenka, Trencansky and Calisti2006), which devotes special attention to the social/organizational aspects introducing different diagrams to capture the social structure, the social behavior, and the social attitudes. One of its main contributions is its powerful notation being specified as a conservative extension of UML 2.0. Still, AML is a modeling language more than a complete methodology that, perhaps, may be integrated in a more organic and structured approach as offered by some existing or new agent-oriented methodology.

Another interesting open issue is related to the different organizational styles (i.e. the way to describe a type of organization by using specific organizational abstractions and notations). In effect, we know that the structure may influence resource access and allocation, the coordination pattern, the authority relationships, the data flow among agents as well as other system characteristics. However, more efforts are necessary to better understand the influence of the organizational styles on the MAS organizational structure (and the adaptability for eventual changes) and on the organizational patterns.