The Gaia Methodology for Agent-Oriented Analysis and Design
Progress in software engineering over the past two decades has been made through the development of increasingly powerful and natural high-level abstractions with which to model and develop complex systems. Procedural abstraction, abstract data types, and, most recently, objects and components are all examples of such abstractions. Agents represent a similar advance in abstraction: they may be used by software developers to more naturally understand, model, and develop an important class of complex distributed systems.
If agents are to realize their potential as a software engineering paradigm, then it is necessary to develop software engineering techniques that are specifically tailored to them. Existing software development techniques (for example, object-oriented analysis and design) are unsuitable for this task. There is a fundamental mismatch between the concepts used by object-oriented developers and the agent-oriented view. For these reasons, Here is introduced a methodology called Gaia, which has been specifically tailored to the analysis and design of agent-based systems.
2. Conceptual Framework
Gaia is intended to allow an analyst to go systematically from a statement of requirements to a design that is sufficiently detailed that it can be implemented directly. The requirements capture phase is independent of the paradigm used for analysis and design. In applying Gaia, the analyst moves from abstract to increasingly concrete concepts. Each successive move introduces greater implementation bias, and shrinks the space of possible systems that could be implemented to satisfy the original requirements statement. Analysis and design can be thought of as a process of developing increasingly detailed models of the system to be constructed. The main models used in Gaia are summarized in Figure 1:
Gaia borrows some terminology and notation from object-oriented analysis and design. However, it is not simply a naive attempt to apply such methods to agent-oriented development. Rather, it provides an agent-specific set of concepts through which a software engineer can understand and model a complex system. In particular, Gaia encourages a developer to think of building agent-based systems as a process of organizational design.
The main Gaia’s concepts can be divided into two categories: abstract and concrete; abstract and concrete concepts are summarized in Table 1:
Abstract entities are those used during analysis to conceptualize the system, but which do not necessarily have any direct realization within the system. Concrete entities, in contrast, are used within the design process, and will typically have direct counterparts in the run-time system.
The objective of the analysis stage is to develop an understanding of the system and its structure (without reference to any implementation detail). This understanding is captured in the system’s organization. An organization is viewed as a collection of roles, that stand in certain relationships to one another, and that take part in systematic, institutionalized patterns of interactions with other roles – see Figure 2:
The most abstract entity in concept hierarchy is the system. Although the term “system” is used in its standard sense, it also has a related meaning when talking about an agent-based system, to mean “society” or “organization”. The idea of a system as a society is useful when thinking about the next level in the concept hierarchy: roles.
A role is defined by four attributes: responsibilities, permissions, activities, and protocols.
Responsibilities determine functionality and, as such, are perhaps the key attribute associated with a role. An example responsibility associated with the role of company president might be calling the shareholders meeting every year. Responsibilities are divided into two types: liveness properties and safety properties. Liveness properties intuitively state that “something good happens”. They describe those states of affairs that an agent must bring about, given certain environmental conditions. In contrast, safety properties are invariants. Intuitively, a safety property states that “nothing bad happens” (i.e., that an acceptable state of affairs is maintained across all states of execution). An example might be “ensure the reactor temperature always remains in the range 0-100”. In order to realize responsibilities, a role has a set of permissions. Permissions are the “rights” associated with a role. The permissions of a role thus identify the resources that are available to that role in order to realize its responsibilities. In the kinds of system that have been typically modeled, permissions tend to be information resources. For example, a role might have associated with it the ability to read a particular item of information, or to modify another piece of information. A role can also have the ability to generate information.
The *activities* of a role are computations associated with the role that may be carried out by the agent without interacting with other agents.
Finally, a role is also identified with a number of protocols, which define the way that it can interact with other roles. For example, a “seller” role might have the protocols “Dutch auction” and “English auction” associated with it; the Contract Net Protocol is associated with the roles “manager” and “contractor”.
Thus, the organization model in Gaia is comprised of two further models: the roles model (section 3.1) and the interaction model (section 3.2).
3.1. The Roles Model.
The roles model identifies the key roles in the system. Here a role can be viewed as an abstract description of an entity’s expected function. In other terms, a role is more or less identical to the notion of an office in the sense that “prime minister”, “attorney general of the United States”, or “secretary of state for Education” are all offices. Such roles (or offices) are characterised by two types of attribute:
A role will have associated with it certain permissions, relating to the type and the amount of resources that can be exploited when carrying out the role. In our case, these aspects are captured in an attribute known as the role’s permissions.
- The permissions/rights associated with the role.
A role is created in order to do something. That is, a role has certain functionality. This functionality is represented by an attribute known as the role’s responsibilities.
Permissions. The permissions associated with a role have two aspects: _ they identify the resources that can legitimately be used to carry out the role — intuitively, they say what can be spent while carrying out the role; _ they state the resource limits within which the role executor must operate – intuitively, they say what can’t be spent while carrying out the role.
In general, permissions can relate to any kind of resource. In a human organization, for example, a role might be given a monetary budget, a certain amount of person effort, and so on. However, in Gaia resources are thought as relating only to the information or knowledge the agent has.
Responsibilities. The functionality of a role is defined by its responsibilities. These responsibilities can be divided into two categories: liveness and safety responsibilities.
Liveness responsibilities are those that, intuitively, state that “something good happens”. Liveness responsibilities are so called because they tend to say that “something will be done”, and hence that the agent carrying out the role is still alive. Liveness responsibilities tend to follow certain patterns. For example, the guaranteed response type of achievement goal has the form “a request is always followed by a response”. The infinite repetition achievement goal has the form “x will happen infinitely often”.
- The responsibilities of the role.
3.2. The Interaction Model
There are inevitably dependencies and relationships between the various roles in a multiagent organization. Indeed, such interplay is central to the way in which the system functions. Given this fact, interactions obviously need to be captured and represented in the analysis phase. In Gaia, such links between roles are represented in the interaction model.
This model consists of a set of protocol definitions, one for each type of inter-role interaction. Here a protocol can be viewed as an institutionalized pattern of interaction. That is, a pattern of interaction that has been formally defined and abstracted away from any particular sequence of execution steps. Viewing interactions in this way means that attention is focused on the essential nature and purpose of the interaction, rather than on the precise ordering of particular message exchanges.
This approach means that a single protocol definition will typically give rise to a number of message interchanges in the run time system. However at the analysis stage, such precise instantiation details are unnecessary, and too premature. A protocol definition consists of the following attributes:
- purpose: brief textual description of the nature of the interaction;
- initiator: the role(s) responsible for starting the interaction; _ responder: the role(s) with which the initiator interacts; _ inputs: information used by the role initiator while enacting the protocol;
- outputs: information supplied by/to the protocol responder during the course of the interaction;
- processing: brief textual description of any processing the protocol initiator performs during the course of the interaction.
3.3. The Analysis Process
The analysis stage of Gaia can now be summarized:
1. Identify the roles in the system. Roles in a system will typically correspond to:
Output: A prototypical roles model — a list of the key roles that occur in the system, each with an informal, unelaborated description.
2. For each role, identify and document the associated protocols. Protocols are the patterns of interaction that occur in the system between the various roles. For example, a protocol may correspond to an agent in the role of BUYER submitting a bid to another agent in the role of SELLER.
Output: An interaction model, which captures the recurring patterns of inter-role interaction.
3. Using the protocol model as a basis, elaborate the roles model.
Output: A fully elaborated roles model, which documents the key roles occurring in the system, their permissions and responsibilities, together with the protocols and activities in which they participate.
4. Iterate stages (1)–(3).
- individuals, either within an organization or acting independently;
- departments within an organization; or
- organizations themselves.
The aim of a “classical” design process is to transform the abstract models derived during the analysis stage into models at a sufficiently low level of abstraction that they can be easily implemented. This is not the case with agent-oriented design, however. Rather, the aim in Gaia is to transform the analysis models into a sufficiently low level of abstraction that traditional design techniques (including object-oriented techniques) may be applied in order to implement agents. To put it another way, Gaia is concerned with how a society of agents cooperate to realize the system-level goals, and what is required of each individual agent in order to do this. Actually how an agent realizes its services is beyond the scope of Gaia, and will depend on the particular application domain.
The Gaia design process involves generating three models (see Figure 1). The agent model identifies the agent types that will make up the system, and the agent instances that will be instantiated from these types. The services model identifies the main services that are required to realize the agent’s role. Finally, the acquaintance model documents the lines of communication between the different agents.
4.1. The Agent Model
The purpose of the Gaia agent model is to document the various agent types that will be used in the system under development, and the agent instances that will realize these agent types at run-time. An agent type is best thought of as a set of agent roles. There may in fact be a one-to-one correspondence between roles (as identified in the roles model—see section 3.1) and agent types. However, this need not be the case. A designer can choose to package a number of closely related roles in the same agent type for the purposes of convenience. Efficiency will also be a major concern at this stage: a designer will almost certainly want to optimize the design, and one way of doing this is to aggregate a number of agent roles into a single type. An example of where such a decision may be necessary is where the “footprint” of an agent (i.e., its run-time requirements in terms of processor power or memory space) is so large that it is more efficient to deliver a number of roles in a single agent than to deliver a number of agents each performing a single role. There is obviously a trade-off between the coherence of an agent type (how easily its functionality can be understood) and the efficiency considerations that come into play when designing agent types. The agent model is defined using a simple agent type tree, in which leaf nodes correspond to roles, (as defined in the roles model), and other nodes correspond to agent types. If an agent type t1 has children t2 and t3, then this means that t1 is composed of the roles that make up t2 and t3.
The agent instances that will appear in a system are documented by annotating agent types in the agent model. An annotation n means that there will be exactly n agents of this type in the run-time system. An annotation m..n means that there will be no less than m and no more than n instances of this type in a run-time system (m _ n). An annotation means that there will be zero or more instances at run-time, and _ means that there will be one or more instances at run-time. Note that inheritance plays no part in Gaia agent models. The view is that agents are coarse grained computational systems, and an agent system will typically contain only a comparatively small number of roles and types, with often a one-to-one mapping between them. For this reason, inheritance is believed to have no useful part to play in the design of agent types. (Of course, when it comes to actually implementing agents, inheritance may be used to great effect, in the normal object-oriented fashion.)
4.2. The Services Model
As its name suggests, the aim of the Gaia services model is to identify the services associated with each agent role, and to specify the main properties of these services. By a service, is meant a function of the agent. In OO terms, a service would correspond to a method; however, we do not mean that services are available for other agents in the same way that an object’s methods are available for another object to invoke. Rather, a service is simply a single, coherent block of activity in which an agent will engage. It should be clear there every activity identified at the analysis stage will correspond to a service, though not every service will correspond to an activity.
For each service that may be performed by an agent, it is necessary to document its properties. Specifically, we must identify the inputs, outputs, pre-conditions, and post-conditions of each service. Inputs and outputs to services will be derived in an obvious way from the protocols model. Pre- and post-conditions represent constraints on services.
These are derived from the safety properties of a role. Note that by definition, each role will be associated with at least one service.
The services that an agent will perform are derived from the list of protocols, activities, responsibilities and the liveness properties of a role.
The developer is free to realize the services in any implementation framework deemed appropriate. For example, it may be decided to implement services directly as methods in an object-oriented language. Alternatively, a service may be decomposed into a number of methods.
4.3. The Acquaintance Model
The final Gaia design model is probably the simplest: the acquaintance mode. Acquaintance models simply define the communication links that exist between agent types. They do not define what messages are sent or when messages are sent – they simply indicate that communication pathways exist. In particular, the purpose of an acquaintance model is to identify any potential communication bottlenecks, which may cause problems at runtime. It is good practice to ensure that systems are loosely coupled, and the acquaintance model can help in doing this. On the basis of the acquaintance model, it may be found necessary to revisit the analysis stage and rework the system design to remove such problems.
An agent acquaintance model is simply a graph, with nodes in the graph corresponding to agent types and arcs in the graph corresponding to communication pathways. Agent acquaintance models are directed graphs, and so an arc a->b indicates that a will send messages to b, but not necessarily that b will send messages to a. An acquaintance model may be derived in a straightforward way from the roles, protocols, and agent models.
4.4. The Design Process
The Gaia design stage can now be summarized:
1. Create an agent model:
2. Develop a services model, by examining activities, protocols, and safety and liveness
properties of roles.
3. Develop an acquaintance model from the interaction model and agent model.
- aggregate roles into agent types, and refine to form an agent type hierarchy;
- document the instances of each agent type using instance annotations.
5. Conclusions and Further Work.
In this article, we have described Gaia, a methodology for the analysis and design of agent-based systems. The key concepts in Gaia are roles, which have associated with them responsibilities, permissions, activities, and protocols. Roles can interact with one another in certain institutionalized ways, which are defined in the protocols of the respective roles. There are several issues remaining for future work.
(c) Michael Wooldridge, Nicholas R. Jennings, David Kinny "The Gaia Methodology for Agent-Oriented Analysis and Design"
- Self-Interested Agents. Gaia does not explicitly attempt to deal with systems in which agents may not share common goals. This class of systems represents arguably the most important application area for multiagent systems, and it is therefore essential that a methodology should be able to deal with it.
- Dynamic and open systems. Open systems — in which system components may join and leave at run-time, and which may be composed of entities that a designer had no knowledge of at design-time — have long been recognized as a difficult class of system to engineer.
- Organization structures. Another aspect of agent-based analysis and design that requires more work is the notion of an organizational structure. At the moment, such structures are only implicitly defined within Gaia — within the role and interaction models. However, direct, explicit representations of such structures will be of value for many applications. For example, if agents are used to model large organizations, then these organizations will have an explicitly defined structure. Representing such structures may be the only way of adequately capturing and understanding the organization’s communication and control structures. More generally, the development of organization design patterns might be useful for reusing successful multi-agent system structures.
- Cooperation Protocols. The representation of inter-agent cooperation protocols within Gaia is currently somewhat impoverished. In future work, we will need to provide a much richer protocol specification framework.
- International Standards. Gaia was not designed with any particular standard for agent communication in mind (such as the FIPA agent communication language). However, in the event of wide scale industrial take-up of such standards, it may prove useful to adapt our methodology to be compatible with such standards.
- Formal Semantics. Finally, we believe that a successful methodology is one that is not only of pragmatic value, but one that also has a well-defined, unambiguous formal semantics. While the typical developer need never even be aware of the existence of such semantics, it is nevertheless essential to have a precise understanding of what the concepts and terms in a methodology mean.
6. Further Development Of Gaia
Gaia Methodology was used as a basis for Message Methodology:
You can download full description of Gaia Methodology with examples here:
Here is represented a full map of Gaia Methodology: