Term Paper
Compare and Contrast five major Agent Oriented Software Engineering
methodologies in the areas of Cooperation & Interaction,
Organization/Organizational Design, Communications, Collaboration &
Coordination
Submitted by Padmaja Havaldar
CIS 890 – Dr. Scott Deloach
Abstract:
Software agents provide a new way of analyzing, designing, and implementing complex software
systems. Currently, the agent-oriented approach to software development is gaining recognition
outside of the research phase and is being widely used in the development of large-scale
industrial applications. The need then arises for systematic methodologies to guide and support
developers through the various stages of software development. Many agent-oriented
methodologies have been proposed which attempt to solve the complexity of multi agent systems,
but this diversity of methodologies may hinder progress if they are not well understood.
This paper presents an analysis of five agent oriented software engineering methods, namely,
MaSe, AgentUML, MESSAGE, Gaia, and SODA in terms of their conceptual foundations. Each
method is described explaining their role in cooperation and interaction between agents, their
organizational design, communications, collaboration and coordination. We consider how these
various methodologies compare to each other.
1. Introduction:
Agents and multi-agent systems are currently one of the most interesting research fields in the
computer science community. A Multi agent system is one where different agents communicate
to achieve their goals, agents being an autonomous and intelligent piece of software. AgentOriented Software Engineering (AOSE) is being described as a new paradigm [1] for the research
field of Software Engineering. But in order to become a new paradigm for the software industry,
robust and easy-to-use methodologies and tools have to be developed [2].
AOSE Methodologies are an organized, documented set of procedures and guidelines for one or
more phases of the software life cycle. They provide a language or notation and a step-by-step
approach to agent based software. In this paper I will present an overview of five agent oriented
software engineering methodologies. The focus is on comparing these methodologies on the basis
of their organizational design, communications, collaboration, coordination, cooperation and
interaction between agents. Section 2 of this paper briefly describes these concepts. The rest of
the paper is organized as follows: Section 3 describes the Gaia methodology and it’s conceptual
framework, section 4 describes the MaSe methodology. In section 5 and 6, we will look at the
MESSAGE and SODA methodologies in terms of their conceptual foundations and in section 7,
I will describe the AgentUML methodology. Section 8 deals with comparison between the
methodologies and section 9 summarizes the paper in the conclusion.
2. About the conceptual framework:
In a multi-agent system, agents come together to form a kind of abstract society; hence their
interaction, coordination, cooperation, collaboration and communication play an important role in
solving problems that no single agent can handle on its own. This paper analyses the abovementioned methodologies in terms of these concepts along with their organizational design. I will
briefly explain the motives of these concepts.
An interaction occurs when two or more agents are brought into a dynamic relationship through a
set of reciprocal actions. This action may be direct through other agents or through the
environment [5]. Interaction is a necessary element for the development of social organizations.
In Cooperation, the goals of agents are compatible and the chances of one of the agents surviving
are enhanced by the other agent. The agents cooperate among themselves to reach their goals
even though there is a competition over who gets to reach their goals. Since the agents cooperate,
tasks have to be allocated. This forms the essence of collaboration. When we allocate tasks, the
need arises to coordinate the agent’s actions in order to avoid conflicts. There are various
coordination protocols to ensure efficient conversation between agents. An organizational design
is an arrangement of relationships between components that produce a system with qualities and
capabilities beyond those of the individual components [5]. We can look at it like a class of
organizations. There are specific roles assigned to the agent classes and there is a set of
relationships between the roles. Communications form the basis of interaction between agents in
muti agent systems. It is carried out in the form of signals between agents and both the agents
should comprehend these signals.
3. The Gaia Methodology:
Wooldridge, Jennings and Kinny [3] present the Gaia methodology for agent-oriented analysis
and design. Gaia is a general methodology that supports both the micro-level (agent structure)
and macro-level (agent society and organization structure) of agent development. The motivation
behind Gaia is that existing methodologies fail to represent the autonomous and problem-solving
nature of agents; they also fail to model agents' ways of performing interactions and creating
organizations. Using Gaia, software designers can systematically develop an implementationready design based on system requirements.
The first step in the Gaia analysis process is to find the roles in the system, and the second is to
model interactions between the roles found. Roles, in the organization, consist of four attributes:
responsibilities, permissions, activities and protocols. Responsibilities are of two types: liveness
properties - the role has to add something good to the system and safety properties - prevent and
disallow that something bad happens to the system. Permissions represent what the role is
allowed to do, in particular, which information it is allowed to access. Activities are tasks that a
role performs without interacting with other roles. Protocols are the specific patterns of
interaction, e.g. a seller role can support different auction protocols, e.g. ``English auction''. Gaia
has formal operators and templates for representing roles and their belonging attributes; it also
has schemas that can be used for the representation of interactions.
In the Gaia design process, the first step is to map roles into agent types, and then to create the
right number of agent instances of each type. The second step is to determine the services model
needed to fulfill a role in one or several agents, and the final step is to create the acquaintance
model for the representation of communication between the agents. It identifies possible
communication bottlenecks but does not define messages or when they are sent.
4. The MaSe Methodology:
The Multi agent Systems Engineering (MaSe) methodology, builds upon the work of many agent
based approaches for analyzing, designing and building multi agent systems and combines them
into a complete end-to-end methodology.[6] MaSE is similar to Gaia with respect to generality
and the application domain supported, but in addition MaSE goes further regarding support for
automatic code creation through the MaSE tool. The motivation behind MaSE is the current lack
of proven methodology and industrial-strength toolkits for creating agent-based systems. The goal
of MaSE is to lead the designer from the initial system specification to the implemented agent
system [2].
The MaSE methodology is divided into seven sections (phases. Capturing goals, the first phase,
transforms the initial system specification into a structured hierarchy of system goals. This is
done by first identifying goals based on the initial system specification's requirements, and then
ordering the goals according to importance in a structured and topically ordered hierarchy.
Applying Use Cases, the second phase of the organizational design, creates use cases and
sequence diagrams based on the initial system specification. A use case presents the logical
interaction paths between various roles in and the system itself. Sequence diagrams are used to
determine the minimum number of messages that have to be passed between roles in the system.
The third phase is refining roles; it creates roles that are responsible for the goals defined in phase
one. In general each goal is represented by one role, but a set of related goals may map to one
role. Together with the roles, the agents collaborate by creating set of tasks; the tasks define how
to solve goals related to the role. The fourth phase, creating agent classes, maps roles to agent
classes in an agent class diagram. This diagram resembles object class diagrams, but the semantic
of relationships is high-level conversation as opposed to the object class diagrams' inheritance of
structure. The fifth phase, constructing conversations, defines a coordination protocol in the form
of state diagrams that define the conversation state for interacting agents. In the sixth phase,
assembling agent classes, the internal functionality of agent classes is created. The final phase,
system design creates actual agent instances based on the agent classes and the final result is
presented in a deployment diagram [2].
A system must be arranged in a Deployment Diagram before it can be implemented in
code. This is due to the differences between agents and agent classes. An agent requires
information such as a hostname or address to participate in a multiagent system. A
Deployment Diagram also offers another opportunity for the designer to tune the system.
Agents can be arranged among various machine configurations in order to better use
available processing power of network bandwidth. A final element to consider is
automatic code generation. The MaSE methodology is concerned with actually
engineering agent systems. As such, all of the steps of the methodology work toward that
end. Code generation is not a part of MaSE at this time, but is assumed to happen just
after this phase [6].
MaSE aims at providing completely automatic code generation based on the deployment diagram
in the future.
5. AgentUML:
As Agent oriented software engineering is becoming popular in the industry it is necessary to
relate it to the object oriented technology, which is already accepted by the industry. The UML
(Unified Modeling language) is an object-oriented graphical modeling language with welldefined syntax and semantics. It helps you specify, visualize, and document models of software
systems, including their structure and design, in a way that meets all of these requirements. The
UML is an extensible language, which allows new constraints to be added to address new issues
in software development without changing the original syntax and semantics. Therefore it is
extended to support the distinctive requirements of multi-agent systems giving rise to the Agent
UML methodology. AUML has extended UML’s interaction diagrams to handle agent interaction
protocols.
The AUML protocol description represents an interaction, a set of messages exchanged among
different agent roles within collaboration to affect a desired behavior of other roles or agent
instances. An agent interaction protocol (AIP) describes a communication pattern as an allowed
sequence of messages between agents and the constraints on the content of those messages, for
example: the FIPA contract net protocol.
Elements of protocol diagrams:

Agent roles
In UML, role is an instance focused term. In the framework of agent oriented
programming by Agent-role a set of agents satisfying distinguished properties, interfaces,
service descriptions or having a distinguished behavior are meant. Agents can perform
various roles within one interaction protocol.

Agent Lifelines and Threads of Interaction
The agent lifeline in protocol diagrams defines the time period during which an agent
exists, represented by dotted vertical lines. The lifeline starts when the agent of a given
agent role is created and ends when it is destroyed.

Nested and Interleaved Protocols
Because protocols can be codified as recognizable patterns of agent interaction, they
become reusable modules of processing that can be treated as first-class notions.

Extended Semantics of UML Messages
The main purpose of protocols is the definition of communicative patterns, i.e., patterns
of messages sent from one agent role to another.

Input and Output Parameters for Nested Protocols
Nested Protocols can be defined either within or outside a protocol diagram where it is
used or outside another protocol diagram. The input parameters of nested protocols are
threads of interaction which are carried on in the nested protocol and messages which are
received from other protocols.

Protocol Templates
The purpose of protocol templates is to create reusable patterns for useful protocol
instances.
UML’s dynamic models are useful for expressing interactions among agents. Interaction
diagrams capture the structural patterns of interactions among objects. Sequence diagrams are
one member of this family; collaboration diagrams are another. The two diagrams contain the
same information [8].
Figure 1depicts some basic elements for agent communication. The rectangle can express
individual agents or sets (i.e., roles or classes) of agents. The basic format for the box label is
agent-name/role: class.
The rectangular box can also indicate a general set of agents playing a specific role. To specify
that the role is to be played by a specific class of agent, the class name would be appended.
Fig 1: Basic format for agent communication in AUML
AUML provides tools for specifying agent interaction protocols, representing the internal
behavior of an agent, representing role specification, packages with agent interfaces,
and deployment diagrams indicating mobility
6. The SODA (Societies and Infrastructures in the Analysis
and Design of Agent-based Systems) Methodoloy:
The notion of society should play a central role in agent-oriented soft-ware engineering as a firstclass abstraction around which complex systems can be designed and built as multi-agent
systems. Agents are not simple software components to be first built, then combined: they are
goal-driven individuals, who assume to live and interact with other individuals within a society.
An effective agent-oriented methodology was needed for the analysis and design of agent
societies. The SODA agent-oriented methodology for the analysis and design of Internet-based
systems is based on the core notion of task. SODA promotes the separation of individual and
social issues, and focuses on the social aspects of agent-oriented software engineering Since it
intentionally does not address intra-agent issues, SODA is not a complete methodology, and
focuses instead on the social aspects of agent-oriented software engineering, by exploiting
coordination models and technologies [ 9].
Agents in a multi-agent system interact by living and working within their environment,
and by relating with other agents. We cannot analyze social organizations without accounting for
interactions. Correspondingly, inter-agent aspects in multi-agent systems basically amount to two
strongly related issues: the social and the environment one.
In the organizational design, the SODA analysis phase exploits three different models:

The role model – the application goals are modeled in terms of the tasks to be
achieved, which are associated to roles and groups

The resource model – the application environment is modeled in terms of the services
available, which are associated to abstract resources

The interaction model – the interaction involving roles, groups and resources is
modeled in terms of interaction protocols, expressed as information required and
provided by roles and resources, and interaction rules, governing interaction within
groups. In all, the results of the SODA analysis phase are expressed in terms of
roles, groups, and resources.
SODA just concentrates on inter-agent issues, like the engineering of societies and infrastructures
for multi-agent systems. Since this conceptually covers all the inter-actions within an agent
system, the design phase of SODA deeply relies on the notion of coordination model [9]
The SODA design phase is based on three strictly related models:

the agent model – individual and social roles are mapped upon agent classes

the society model – groups are mapped onto societies of agents, which are designed and
organised around coordination abstractions

the environment model – resources are mapped onto infrastructure classes, and associated
to topological abstractions.
In all, the results of the SODA design phase are expressed in terms of agent classes, societies of
agents, and infrastructure classes [9].
7. The MESSAGE (Methodology for Engineering Systems of
Software Agents) methodology:
MESSAGE is an AOSE methodology, which builds upon current software engineering practices
covering analysis and design of Multi Agent Systems, which is appropriate for use in mainstream
software engineering departments. MESSAGE aims to combine the best features on agentUML
and Gaia and to define an agent-oriented methodology that encompasses requirements analysis
and design It has well defined concepts and a notation that is based on UML whenever
appropriate. MESSAGE extends UML by contributing agent knowledge level concepts, and
diagrams with notations for viewing them. The diagrams extend UML class and activity
diagrams. The MESSAGE modeling language shares a common metamodelling language (metametamodel) with UML. It extends the UML metamodel with ’knowledge level’ agent-oriented
concepts.
The MESSAGE methodology consists of applicability guidelines, a modeling notation, and a
process for analysis and design of agent systems [10]
Knowledge-level concepts: MESSAGE concepts and describes different views on the analysis.
Most of the MESSAGE knowledge level entity concepts fall into the main categories:
Agent: An Agent is an atomic autonomous entity that is capable of performing some (potentially)
useful function.
Organization: An Organization is a group of Agents working together to a common purpose.
Role: The distinction between Role and Agent is analogous to that between Interface and (object)
Class: a Role describes the external characteristics of an Agent in a particular context. An Agent
may be capable of playing several roles, and multiple Agents may be able to play the same Role.
Resource: Resource is used to represent non-autonomous entities such as databases or external
programs used by Agents. Standard object-oriented concepts are adequate for modeling
Resources.
Task: A Task is a knowledge-level unit of activity with a single prime performer. A task has a set
of pairs of Situations describing pre- and post-conditions. If the Task is performed when a
precondition is valid, then one can expect the associated post condition to hold when the Task is
completed.
Interaction and Interaction Protocol: The MESSAGE concept of Interaction borrows heavily
from the Gaia methodology [6]. An Interaction by definition has more than one participant, and a
purpose which the participants collectively must aim to achieve. The purpose typically is to reach
a consistent view of some aspect of the problem domain, to agree terms of a service or to
exchange results of one or more services. An Interaction Protocol defines a pattern of Message
exchange associated with an Interaction.
Goal: A Goal associates an Agent with a Situation. If a Goal instance is present in the Agent’s
working memory, then the Agent intends to bring about the Situation referenced by the Goal.
MESSAGE defines a number of views that focus on overlapping sub-sets of entity and
relationship concepts.
Organization view (OV) – This shows ConcreteEntities (Agents, Organizations, Roles,
Resources) in the system and its environment and coarse-grained relationships between them
(aggregation, power, and acquaintance relationships).
Goal/Task view (GTV) – This shows Goals, Tasks, Situations and the dependencies among
them.
Agent/Role view (AV) – This focuses on the individual Agents and Roles. For each agent/role it
uses schemata supported by diagrams to its characteristics such as what Goals it is responsible
for, what events it needs to sense, what resources it controls, what Tasks it knows how to
perform, etc.
Interaction view (IV) – For each interaction among agents/roles, shows the initiator, the
collaborators, the motivator (generally a goal the initiator is responsible for), the relevant
information supplied/achieved by each participant, the events that trigger the interaction, other
relevant effects of the interaction.
Domain view (DV) – Shows the domain specific concepts and relations that are relevant for the
system under development
8. Comparison between methodologies:
The Gaia methodology requires that inter-agent relationships (organization) and agent abilities
are static at run-time. But with comparison to MaSe, domain restrictions of MaSE are similar to
those of Gaia's, but in addition it requires that agent-interactions are one-to-one and not multicast.
MaSe is more detailed than the Gaia methodology. Both Gaia and MaSe are based on roles. Mase
uses goals and use cases while Gaia provides no help in defining roles. MaSe provides detailed
description of the actual communication patterns and data in the conversation diagrams while in
Gaia, the acquaintance model defines the lines of communication between agents.
I observed that so far no empirical tests have been carried out to evaluate the benefits of the
AGENT UML framework. But we see two concrete advantages of these extensions: Firstly, they
make it easier for users who are familiar with object-oriented software development but new to
developing agent systems to understand what multiagent systems are about, and to understand the
principles of looking at a system as a society of agents rather than a distributed collection of
objects. Secondly, the time spent for design can be reduced by a minor amount, which grows with
the number of agent-based projects.
GAIA represents an extension of the software engineering approach and has a solid social
foundation. AUML on the other hand, represents the pure software engineering approach and is
an extension of the standard software engineering approach - UML
As far as SODA is concerned, the main reference for the development of SODA is represented by
the pioneering work on Gaia [3]. Gaia was the first agent-oriented software engineering
methodology that explicitly took into account societies (there, mainly referred to as
organizations) as first-class entities, by providing a coherent conceptual framework for the
analysis and design of multi-agent systems. Even though at an early stage of its development,
SODA addresses some of the shortcomings of Gaia, which does not suit well open systems, In
addition, SODA is the first agent-oriented methodology to explicitly take the agent environment
into account, and provide engineers with specific abstractions and
procedures for the design of agent infrastructures.
While applying existing software engineering concepts, AgentUML (AUML) for example defines
extensions to UML with notations suited for agent concepts. Although this notation is useful and
has been adopted within MESSAGE, it does not have the concept of agent at its centre, i.e.
specifying an object’s behavior in terms of interaction protocols does not make it an agent. These
methodologies define a number of models for analysis and design such as. The Gaia methodology
has two analysis models and three design models. While the analysis models are based on welldefined concepts, these only represent a subset of the concepts required for agent-oriented
analysis. MESSAGE combines the best features of the above approaches.
9. Conclusion:
This paper presented five agent oriented software engineering methodologies and discussed their
conceptual foundations like interaction, cooperation, collaboration, organizational design etc
wherever applicable. A comparison of the methodologies can be made, which was the intent of
the paper, to come up with a better understanding of the methodologies.
Section 1 was the introduction to this paper, section 2 explained briefly the conceptual framework
on which the methodologies were discussed in the paper, section 3 described the Gaia
methodology, section 4 and 5 explained the MaSe and AgentUML methodologies respectively,
section 6 described SODA methodology and section 7 discussed the MESSAGE methodology. A
comparison between methodologies was discussed in Section 8.
References:
1.LindJ. “Issues in Agent-Oriented Software Engineering”
The First International Workshop on Agent-Oriented Software Engineering (AOSE 2000), 2000.
2.TveitAmud;“A survey of Agent-OrientedSoftwareEngineering”
[www.jfipa.org/publications/AgentOrientedSoftwareEngineering
3.Wooldridge M. J., Jennings N. R. and Kinny D; “The Gaia methodology for agent-oriented analysis and
design”. Autonomous Agents and Multi-Agent Systems ,3(3):285312, September 2000.
4.Andrea Omicini :”SODA: Societies and Infrastructures in the Analysis and Design of Agent-based
Systems)”
5. Dr. Deloach’s 890 lecture notes:”www.cis.ksu.edu/~sdeloach/890”
6. Mark F. Wood Scott A. DeLoach, “An Overview of the Multiagent Systems Engineering Methodology”
7. Bernhard Bauer, Jörg P. Müller, James Odell + Siemens; “Agent UML: Formalism for Specifying
Multiagent Interaction”
8. James J. Odell* H. Van Dyke Parunak† Bernhard Bauer‡; “Representing Agent Interaction Protocols in
UML”
9. Omicini Andrea; “SODA: Societies and Infrastructures in the Analysis and Design of Agent-based
Systems”
10. Giovanni Caire, Francisco Leal, Paulo Chainho, Richard Evans:
“Agent Oriented Analysis using MESSAGE/UML”