Developing Multiagent Systems: The Gaia Methodology

Source: Franco Zambonelli, Nicholas R. Jennings, Michael Wooldridge; ACM Transactions on Software Engineering and Methodology 12(3) · 2003

Given the suitability of a modeling approach based on autonomous, situated agents that interact in flexible ways, there is a need to understand which further abstractions inspired by which metaphor complete the agent-oriented mindset.

In recent years, researchers in the area of MASs have proposed a number of different approaches for modeling systems based on different metaphors, none of which can reasonably claim to be general purpose. For instance: the ant algorithms metaphor [Bonabeau et al. 1999; Babaoglu et al. 2002] has shown to be useful in efficiently solving complex distributed problems such as routing and distributed sorting; physical metaphors [Abelson et al. 2000; Mamei et al. 2003], focusing on the spontaneous reshaping of a system’s structure, may have useful applications in pervasive and mobile computing; societal metaphors have been effectively applied in robotics applications [Moses and Tennenholtz 1995; Collinot et al. 1996] and in the understanding and control of highlydecentralized systems [Hattori et al. 1999; Ripeani et al. 2002]. Our approach focuses on the development of medium to large size systems, possibly dived in open and dynamic environments, and that have to guarantee predictable and reliable behaviors. For these kinds of systems, we believe the most appropriate metaphor is that of a human organization [Handy 1976; Fox 1981; Demazeau and Rocha Costa 1996; Zambonelli et al. 2001a], in which:

3.3 Organizational Abstractions The characterization of a MAS of Figure 1 highlights the most basic abstractions that characterize a computational organization and that can be appropriately exploited in the analysis and design phases: the environment in which the MAS is immersed; the roles to be played by the different agents in the organization; and the interactions between these roles. In addition, we have identified two further abstractions that are often implicitly integrated into the above ones and that, we believe, need to be considered in their own right: organizational rules and organizational structures.

3.3.1 The Environment. A MAS is always situated in some environment and we believe this should be considered as a primary abstraction during the analysis and design phases. Generally speaking, identifying and modeling the environment involves determining all the entities and resources that the MAS can exploit, control or consume when it is working towards the achievement of the organizational goal. In some cases, the environment will be a physical one, including such things as the temperature in a room, the status of a washing machine or the average speed of cars on a motorway. This is the case in the manufacturing pipeline, where the agents are intended to control the correct processing and the global flux of the items in the pipeline. In other cases, the environment will be a virtual one, including such things as enterprise information systems, web services, and database management systems. This is the case of the conference management system, where agents execute in an environment populated by papers, review forms and digital libraries. Whatever the case, an explicit modeling of the environment is very important: not taking it into account (as, e.g., in the previous version of Gaia methodology [Wooldridge et al. 2000]) may complicate the overall design and may introduce mismatches between the MAS design and its actual operation. For instance, in the conference management example, the lack of environmental modeling would imply considering specific application agents as repositories of papers and review forms and as being in charge of explicitly transferring them to other agents. This is a more complex solution than that of explicitly modeling an environmental data repository, and conceptually farther from the likely operating environment (a world of Websites from which agents can access papers and review forms).

Summarizing, the environment of a MAS should not be implicitly assumed: its characteristics must be identified, modeled, and possibly shaped to meet application-specific purposes.

3.3.2 Roles and Interactions. The role of an agent defines what it is expected to do in the organization, both in concert with other agents and in respect of the organization itself. Often, an agent’s role is simply defined in terms of the specific task that it has to accomplish in the context of the overall organization. However, our notion of a role is much more precise; it gives an agent a well-defined position in the organization, with an associated set of expected behaviors [Wooldridge et al. 2000; Ferber and Gutknecht 1998; Demazeau and Rocha Costa 1996]. Organizational role models precisely describe all the roles that constitute the computational organization. They do this in terms of their functionalities, activities, and responsibilities, as well as in terms of their interaction protocols and patterns. Organizational interaction models describe the protocols that govern the interactions between the roles. Moreover, the interaction model describes the characteristics and dynamics of each protocol (e.g., when, how, and by whom a protocol has to be executed). Most approaches to MAS modeling [Lind 2001; Wood et al. 2001], (including the first version of Gaia [Wooldridge et al. 2000]), consider role and interaction models as the sole organizational abstractions upon which to base the entire development process. Consequently, the analysis and design process starts directly with the identification and definition of role and interaction models. However, although role and interaction models can be useful to fully describe an existing organization, they are of limited value in building an organization. In fact, before the design process can define an actual organization (to be possibly described in terms of role and interaction models), there is a need to identify how the organization is expected to work and which kind of organization (among several possible ones) best fits the requirements identified in the analysis phase. This observation—elaborated below—motivates our introduction of the notions of organizational rules and organizational structures.

3.3.3 Organizational Rules. In the requirements capture phase of MAS development, it is certainly possible to identify the basic skills (functionalities and competences) required by the organization, as well as the basic interactions that are required for the exploitation of these skills. In the case of the manufacturing pipeline, it is easy to identify the need for agents to act as “stage controllers”; in the conference management case study, it is easy to recognize the need for agents to act as “authors,” “reviewers,” “PC Chair,” and so on. Although such an analysis can lead to the identification of a preliminary version of the role and interaction models, this identification cannot and should not be used to produce complete models. In fact, before being able to fully characterize the organization, the analysis of a MAS should identify the constraints that the actual organization, once defined, will have to respect. Typically, such constraints: (i) spread horizontally over all the roles and protocols (or, which is the same in this context, over the identified preliminary roles and protocols), or (ii) express relations and constraints between roles, protocols, or between roles and protocols [Esteva et al. 2001]. Although, in an actual organization, such constraints are likely to be somehow enacted by some agents playing some roles and interacting somehow, they can hardly be expressed in terms of individual roles or individual interaction protocols (in the same way, that social conventions and company directives horizontally influence our social life and our work, but cannot be associated with any specific actor). Thus, the explicit identification of such constraints—captured in our concept of organizational rules—is very important for the correct understanding of the characteristics that the organization-to-be must express and for the subsequent definition of the system structure by the designer. The explicit identification of organizational rules is also important in the context of open systems. With the arrival of new, previously unknown, and possibly self-interested agents, the overall organization must be able to enforce its internal coherency despite the dynamic and untrustworthy environment. The identification of global organizational rules allows the system designer to explicitly define: (i) whether and when to allow new agents to enter the organization, and, once accepted, what their position should be; and (ii) which behaviours should be considered as a legitimate expression of self-interest, and which among them must be prevented by the organization. In this context, organizational rules may also drive the designer towards the definition of the specific organization structure that most eases the enforcement of the organizational rules and, for instance, can facilitate the prevention of undesirable behavior on the part of the unknown agents. In the manufacturing pipeline example, all the different stages must maintain the same speed of flow of items in the pipeline. This requirement is most simply expressed in terms of a global organizational rule, rather than replicating it as a requirement for each and every role in the organization (as, e.g., the previous version of Gaia and any methodology not making explicit use of organizational rules would have required). In the conference management system, there are a number of rules that drive the proper implementation of the organization. As notable examples: an agent should be prevented from playing both the role of author and reviewer of the same paper; PC members should not be in charge of collecting the reviews for their own papers. Neither of these constraints can easily be expressed in terms of properties or responsibilities associated to single roles or protocols and, if so, they would notably increase the complexity of roles and protocol description. Instead, they represent global organizational rules.

3.3.4 Organizational Structures. A role model describes all the roles of an organization and their positions in that organization. Therefore, a role model also implicitly defines the topology of the interaction patterns and the control regime of the organization’s activities. That is, it implicitly defines the overall architecture of the MAS organization (i.e., its organizational structure). For example, a role model describing an organization in terms of a “master role” and “slave roles”—where the former is in charge of assigning work to the latter and of load balancing their activities—implicitly defines an organizational structure based on a hierarchical topology and on a load partitioning control regime. Other exemplar organizational structures include collectives of peers, multilevel and multidivisional hierarchies [Fox 1981], as well as more dynamic structures deriving from market-oriented models [Kolp et al. 2002]. All these organizations can be modeled in terms of a role model. However, while the role model may define the organizational structure in an implicit way, the structure of a MAS is more appropriately derived from the explicit choice of an appropriate organizational structure, and organizational structures should be viewed as first-class abstractions in their own right. This argument (which is conventional in architecture-centered software design [Bass et al. 2003, Shaw and Garlan 1996]) calls for a specific design choice not to be (generally) anticipated to the analysis phase, but rather should exploit information collected during analysis. In the specific context of MAS development, the argument is motivated by several considerations: