Brian Henderson-Sellers - Paolo Giorgini-Agent-oriented Methodologies-Idea Group Pub (2005)

TEAM LinG
Agent-Oriented
Methodologies
Brian Henderson-Sellers
University of Technology, Sydney, Australia
Paolo Giorgini
Trento University, Italy
IDEA GROUP PUBLISHING

Hershey • London • Melbourne • Singapore
TEAM LinG
ii
Acquisitions Editor: Renée Davies

Development Editor: Kristin Roth
Senior Managing Editor: Amanda Appicello
Managing Editor: Jennifer Neidig
Copy Editor: Jane Conley
Typesetter: Cindy Consonery
Cover Design: Lisa Tosheff
Printed at: Integrated Book Technology
Published in the United States of America by

Idea Group Publishing (an imprint of Idea Group Inc.)
701 E. Chocolate Avenue
Hershey PA 17033
Tel: 717-533-8845
Fax: 717-533-8661
E-mail: cust@idea-group.com
Web site: http://www.idea-group.com
and in the United Kingdom by

Idea Group Publishing (an imprint of Idea Group Inc.)
3 Henrietta Street
Covent Garden
London WC2E 8LU
Tel: 44 20 7240 0856
Fax: 44 20 7379 3313
Web site: http://www.eurospan.co.uk
Copyright © 2005 by Idea Group Inc. All rights reserved. No part of this book may be reproduced,
stored or distributed in any form or by any means, electronic or mechanical, including photocopying,
without written permission from the publisher.
Product or company names used in this book are for identification purposes only. Inclusion of the
names of the products or companies does not indicate a claim of ownership by IGI of the trademark
or registered trademark.
Library of Congress Cataloging-in-Publication Data
Agent-oriented methodologies / Brian Henderson-Sellers and Paolo Giorgini, editors.

p. cm.
Summary: "The book presents, analyzes and compares the most significant methodological ap-
proaches currently available for the creation of agent-oriented software systems"--Provided by
publisher.
ISBN 1-59140-581-5 (hardcover) -- ISBN 1-59140-586-6 (soft cover) -- ISBN 1-59140-587-4
(ebook)
1. Intelligent agents (Computer software) 2. Object-oriented methods (Computer science) I.
Henderson-Sellers, Brian. II. Giorgini, Paolo.
QA76.76.I58A324 2005
006.3--dc22
2005004542
British Cataloguing in Publication Data

A Cataloguing in Publication record for this book is available from the British Library.
All work contributed to this book is new, previously-unpublished material. The views expressed in this
book are those of the authors, but not necessarily of the publisher.
TEAM LinG
iii
Agent-Oriented
Methodologies
Table of Contents
Foreword ......................................................................................................... vi
James J. Odell
Preface .............................................................................................................. x
Brian Henderson-Sellers, University of Technology, Sydney,
Australia
Paolo Giorgini, University of Trento, Italy
Chapter I
Agent-Oriented Methodologies: An Introduction .................................... 1
Australia
Chapter II
Tropos: A Requirements-Driven Methodology for Agent-Oriented
Software .......................................................................................................... 20
Manuel Kolp, University of Louvain, Belgium
John Mylopoulos, University of Toronto, Canada
Jaelson Castro, Federal University of Pernambuco, Brazil
Chapter III
The Agent-Oriented Methodology MAS-CommonKADS .................... 46
Carlos A. Iglesias, Technical University of Madrid, Spain
Mercedes Garijo, Technical University of Madrid, Spain
Chapter IV
From Requirements to Code with the PASSI Methodology ................. 79
Massimo Cossentino, ICAR-CNR, Italy
TEAM LinG
iv
Chapter V
Prometheus: A Practical Agent-Oriented Methodology .................... 107
Lin Padgham, RMIT University, Australia
Michael Winikoff, RMIT University, Australia
Chapter VI
Multi-Agent Systems as Computational Organizations: The Gaia
Methodology .............................................................................................. 136
Franco Zambonelli, Università di Modena e Reggio Emilia, Italy
Nicholas R. Jennings, University of Southampton, UK
Michael Wooldridge, University of Liverpool, UK
Chapter VII
Engineering Adaptive Multi-Agent Systems: The ADELFE
Methodology .............................................................................................. 172
Carole Bernon, IRIT – University Paul Sabatier, France
Valérie Camps, IRIT – University Paul Sabatier, France
Marie-Pierre Gleizes, IRIT – University Paul Sabatier, France
Gauthier Picard, IRIT – University Paul Sabatier, France
Chapter VIII
The MESSAGE Methodology for Agent-Oriented Analysis and
Design .......................................................................................................... 203
Francisco J. Garijo, Telefónica I+D, Spain
Jorge J. Gómez-Sanz, Universidad Complutense de Madrid,
Spain
Philippe Massonet, CETIC, Belgium
Chapter IX
The INGENIAS Methodology and Tools .............................................. 236
Juan Pavón, Universidad Complutense de Madrid, Spain
Jorge J. Gómez-Sanz, Universidad Complutense de Madrid, Spain
Rubén Fuentes, Universidad Complutense de Madrid, Spain
Chapter X
Towards Radical Agent-Oriented Software Engineering Processes
Based on AOR Modelling ........................................................................ 277
Kuldar Taveter, The University of Melbourne, Australia
Gerd Wagner, Brandenburg University of Technology at Cottbus,
Germany
TEAM LinG
v
Chapter XI
Multi-Agent Systems Engineering: An Overview and Case Study ... 317
Scott A. DeLoach, Kansas State University, USA
Madhukar Kumar, Software Engineer, USA
Chapter XII
Comparison of Ten Agent-Oriented Methodologies .......................... 341
Quynh-Nhu Numi Tran, University of New South Wales, Australia
Graham C. Low, University of New South Wales, Australia
Chapter XIII
Creating a Comprehensive Agent-Oriented Methodology:
Using Method Engineering and the OPEN Metamodel ..................... 368
Australia
About the Authors ..................................................................................... 398
Index ............................................................................................................ 406
TEAM LinG
vi
Foreword
A methodology is a body of methods employed by a discipline. A method is a

procedure for attaining something. While some developers employ a handful of
methods for developing agent-based systems, few have a methodology. Most
developers of agent-based systems use an ad hoc approach—minimizing guide-
lines and assembling a seat-of-the-pants notation and terminology. While this
approach provides maximum flexibility (as illustrated in Figure 1), the quality of
the resulting application is questionable, since any knowledge and experience
gained can not be easily transferred to other projects. Flexibility without control
can hardly be considered a methodology, since any systematic and coordinated
approach to establishing work methods is absent.
To be fair, choosing flexibility should not be considered a developer failing.
Until recently, few methodologies existed from which to choose. This book is
the first to present and explore the ten most prominent methodologies for devel-
oping agent-based systems. It is particularly valuable because readers will find
suggested guidelines, techniques, notations, and terminology. Each of these
methodologies contributes significantly toward aiding the developer.
Figure 1. Methodological approaches fall into three categories (adapted

from Harmsen et al., 1994)
Flexibility Controlled Flexibility Control
• ad hoc development • uniformb uildin g b loc ks s elec ted • one s tan dard methodology
• fe w guid elin es for project situation • rig id g uidelines
• no uniform terminology • guid an ce for each b uildin g b loc k • uniform terminology
• projec t ma na ge men t and measurability • uniform terminolog y • all p roje cts comp ly to same measurable
difficult • uniform, meas ura ble p roje ct man ag ement approach
TEAM LinG
vii
• The Tropos methodology provides guidance for the four major develop-
ment phases of application development. One of its primary contributions
is placing an emphasis on modeling goals and their relationship with the
system’s actors, tasks, and resources.
• MAS-CommonKADS is based on both CommonKADS and object-oriented
(OO)-based methodologies. This enables the developer to build agent-
based systems while leveraging the experience of pre-agent methodolo-
gies and employing familiar techniques and diagrams.
• The PASSI methodology brings a particularly rich development lifecycle
that spans initial requirements though deployment and, in addition, empha-
sizes the social model of agent-based systems.
• From an AI planning-execution perspective, Prometheus provides an es-
pecially rich goal-driven approach for its BDI-like agents. Its methodol-
ogy is used today to develop systems on commercial BDI-based agent
platforms, such as JACK or Agentis.
• Gaia is one of the earliest agent methodologies and now reflects this
experience in Version Two of its approach. Using the analogy of human-
based organizations, Gaia provides an approach that both a developer and
a non-technical domain expert can understand—facilitating their interac-
tion.
• ADELFE is a specialized methodology that emphasizes cooperative agents
that self-organize and possibly result in emergent systems. More specifi-
cally, it addresses designing complex adaptive systems and anticipating
emergence within its software agents.
• Resulting from a two-year, European-funded EURESCOM project, MES-
SAGE extends existing object-oriented methodologies for agent-oriented
applications. Chartered to address telecommunications applications, its
resulting RUP-based approach also supports more general applications.
• The INGENIAS methodology supports a notation based on five metamodels
that define the different views and concepts of a multi-agent system. Us-
ing metamodels provides flexibility for evolving the methodology and adopt-
ing changes to its notation.
• RAP is concerned with distributed information systems (such as enter-
prise resource planning and supply-chain management systems) and places
less emphasis on AI-based systems. The philosophy of the Model Driven
Architecture (MDA) is adopted with the goal that executable software
agents can be generated using RAP artifacts.
• MaSE is a comprehensive methodology that has been used to develop
systems ranging from heterogeneous database integration applications to
biologically based, computer-virus immune systems and cooperative ro-
botics systems. Its hybrid approach can be applied to multi-agent sys-
TEAM LinG
viii
tems that involve implementations, such as distributed human and

machine planning.
In summary, all of the methodologies in this book provide valuable contributions

that aid in the production of thoughtful agent-based applications. Each has its
own unique perspective and approach to developing agent-based systems, while
at the same time overlapping with many of the other approaches. Yet, no one
methodology is useful in every system-development situation (the control ap-
proach depicted on the right of Figure 1).
This book presents the steps and notations for developing a variety of systems.
By putting the methodologies side-by-side, the reader can select those portions
relevant. Chapter 12 aids this process with a comprehensive overview and
comparison of the various methodologies. Wisely, the approach adopted in the
concluding chapter is controlled flexibility. Here, the most valuable building
blocks—or method fragments—can be identified and extracted from each of
the described methodologies and placed into a method repository. Such a re-
pository will provide a broad set of reusable techniques that can be assembled
based on the individual application’s profile.
By providing such a full range of methodologies, this book creates a balance
between being evolutionary and revolutionary. On the one hand, the agent-
based approach is not vastly different from current approaches. If a methodol-
ogy differed radically from current practices, IT developers would experience
difficulty in both understanding and accepting the approach. Furthermore, to
suddenly reject the way we have developed applications for the last three de-
cades would be unreasonable. Much of what we do as application developers
does not change radically because the underlying software infrastructure has a
high degree of stability. On the other hand, the agent-based approach to sys-
tem development does differ from the conventional way of producing IT sys-
tems. Therefore, an agent methodology—even though it must still address and
incorporate non-agent development requirements—is markedly different from
traditional IT practices. Agents bring a new approach to developing systems.
To one extent or another, the methodologies in this book involve identifying and
incorporating those methodological features that make the agent-based approach
possible while exploiting already-recognizable and time-tested processes. This
is important for two reasons. Firstly, we need to communicate clearly to devel-
opers those steps necessary to create a successful agent-based implementa-
tion. Secondly, we must show why agent-based methodologies improve on
traditional approaches—while still addressing those conventional aspects of an
application.
In closing, I would like to say that I highly recommend this book as a guide to
those developers and researchers involved in building agent-based applications.
TEAM LinG
ix
It provides a wealth of guidelines, techniques, and notations for developing a

variety of systems. Hence, I expect that its state-of-the-art approaches will
heavily influence how the next generation of agent-based systems will be de-
veloped.
James J. Odell
Reference
Harmsen, F., Brinkkember, S., & Oei, H. (1994). Situational method engineer-
ing for information system project approaches. In A. A. Verrijn-Stuart &
T. W. Olle (Eds.), Methods and associated tools for the information
systems life cycle (pp. 169-194). Elsevier, Amsterdam: Elsevier.
TEAM LinG
x
Preface
Building software to solve contemporary business problems is no easy task.

Over the last decade there has been an increasing focus on object-oriented
notations and modelling languages, perhaps at the expense of a full method-
ological approach to solving the problem and giving software developers the
tools they need to comprehensively create applications within management and
market constraints—money, time, quality, and so forth. With increasingly so-
phisticated applications being demanded by businesses aiming for a competitive
market advantage, object technologies are being supplemented and comple-
mented by agent technologies. This is especially true in areas such as ambient
intelligence, e-business, Web services, peer-to-peer networks, and
bioinformatics. These areas demand software that is robust, can operate within
a wide range of environments, can evolve over time to cope with changing
requirements, is highly customizable to meet the needs of a wide range of us-
ers, and is sufficiently secure to protect personal data and other assets on be-
half of its stakeholders. To fulfil these requirements, builders of systems need
an appropriate agent-oriented methodology—the topic of this book.
Agent technology, increasing in popularity over the last decade, represents a
concrete response to these new requirements. The main reason for this is that
the agent paradigm, along with its definition of agent as an autonomous and
proactive system capable of interacting with other agents in order to satisfy its
objectives, provides a natural evolution for software systems. Agent-based sys-
tems call for new concepts, tools, and techniques for engineering and managing
software. In particular, we need new software development methodologies that
support the design and implement organizations of agents able to interact with
one another in order to achieve some common or individual goal. However, in
TEAM LinG
xi
contrast to the history of object-oriented methodologies, in which industry played

and is currently playing the major role, most of the agent-oriented methodolo-
gies are proposed by academic researchers and many of them are still in an
early stage of maturity. Nevertheless, the time is ripe for an evaluation of the
state-of-the art of agent-oriented methodologies, before they descend into the
depths of a methodology jungle (as happened with object-oriented methodolo-
gies) that leads to industry rejection—spoiled for choice leads to “no choice”
because it is unclear whether any of the individualistically proposed methodolo-
gies have any industrial future beyond the PhD scholarship or research grant
supporting them in their (typically academic) research phase.
The intent of this book is therefore to give readers an understanding of the
predominant and tested agent-oriented methodologies. The book characterizes
each of these methodologies and compares them in terms of their main fea-
tures. The book is organized as follows. Chapter I introduces what an agent-
oriented methodology is, and it illustrates briefly the ten methodologies described
in the rest of the book. Chapters II through XI, ably summarized by Jim J. Odell
in the Foreword, then describe the methodologies, whereas Chapter XII pre-
sents an evaluation of all ten with a comparison of the methodologies based on
the features-analysis approach. Finally, Chapter XIII illustrates how to create
an agent-oriented methodology using method engineering based on the OPEN
metamodel.
For each methodology, we asked the originators of that methodology to de-
scribe their work in the same way for each chapter. Within the space con-
straints we had given them (in order to maintain a balance across the book), we
asked them to describe the current version of the methodology and then to
illustrate this with a small case study. We also asked them to end their chapter
with a short section to evaluate (from their viewpoint) what the strengths and
weaknesses of their methodological approach are. After all, the authors are
generally in the best position to know what critical issues they, and they alone,
address – which is why they put the effort into creating the methodology in the
first place. They are also in a good position to know the weaknesses, even if
these are often hidden in more “marketing” presentations. Sometimes, omis-
sions are purposeful yet seen by readers as “errors.” So, we also asked the
authors to state what they had omitted and knew they had omitted. When
using abstraction techniques, which underpin methodologies as much as model-
ling, it is inevitable that some omissions and approximations will be used. Stat-
ing such constraints, say of restricted applicability to certain lifecycle stages or
to certain classes of problems, makes the methodology even more valuable
when applied in situations for which it has been designed.
We did not try to rationalize the notation. For many AO methodologies, UML or
extensions thereof are selected. (We take the liberty of assuming that the reader
is familiar with UML and therefore do not define it in this book.) Many in the
TEAM LinG
xii
community are exploring some more formal extensions to UML, such as Agent
UML (AUML); others eschew these proposals and develop their own notation.
Indeed, there is still some debate about whether extended an object-oriented
notation like UML is the right way to go or whether the requirements of the
agent community cannot be satisfied by waiting for the Object Management
Group (OMG) to agree upon an agent-oriented extension to UML (although
such efforts are indeed being discussed in the OMG in collaboration with the
Foundation for Intelligent Physical Agents [FIPA]). We did ask that when au-
thors used non-UML-like notations that they defined them in situ.
While the OO basis of many of these AO methodologies is evident (and dis-
cussed in more detail in Chapter I), it should be noted that a group of method-
ologies use the Rational Unified Process (RUP) as its basis. The terminology
used in RUP, and therefore used in Chapters VII through IX, is not identical to
the terminology used in the other chapters. Again, because of the different
heritage we have not tried to rationalize these differences. We felt that had we
done so, we would have destroyed the very essence of these three method-
ological approaches.
We are aware that much of the agent-oriented methodology development work,
as reported here, has occurred in the realms of academe. Yet, one aim is to be
able to transition these research results into industry. Particularly through our
experiences in chairing various agent-oriented workshops (AOIS, AOSE,
OOPSLA), we have become all too painfully aware of the challenge of
transitioning agent technology into mainstream software development. The
AO community is seen from outside as being undecided as to the basic charac-
teristics of an agent, for example, whether or not to include proactivity and
mobility and, if so, whether this is a binary characteristic or on a grey scale.
From our previous experience with OO methodologies both in research and
industry adoption, it is clear that there is a need for methodology developers to
become aware of each others’ work, to collaborate, to standardize, and to come
up with a generally agreed approach to software development using their pro-
posed new technology—here, agent technology. This book aims to be a first
step in that direction. By presenting each methodology in as similar a light as
possible and by undertaking a feature analysis, we can hope to gain insights, as
researchers, into what works and what doesn’t. As coalescence is encouraged,
these ideas need to be tried out “for real” in industry applications. This is al-
ready beginning to happen, as is reported in some of the chapters in this book.
Nevertheless, a concerted community effort is needed if industry adoption is to
follow successfully.
In addition to presenting each methodology in an easy-to-understand way supple-
mented by an independent analysis (Chapter XII), we also propose a way for-
ward for such a collaborative venture: situational method engineering. Chapter
XIII offers insights into how this might work in the development of more flex-
TEAM LinG
xiii
ible and coherent agent-oriented methodologies. The creation of a standard

repository of method fragments, each of which captures the essence of some
part of the methodology, allows industry adopters to “roll their own” methodol-
ogy and thus establish an agreed in-house methodology specifically suited to
their own peculiar circumstances. There are, to our knowledge, at least two
international projects that are moving in this direction as well as significant
research and standards development in the area of methodology metamodeling
to underpin such a repository in a more formal way. Once established, it would
be anticipated that the necessary tools would be built by third-party software
developers/vendors. When all these pieces fall into place, we can then claim
that agent-orientation is mainstream. At what date in the future this will occur,
we hesitate to forecast; yet, we believe it is inevitable.
In closing, we wish to gratefully acknowledge the authors for their contribu-
tions and their patience in assisting us in putting together this book. We also
owe them double thanks, since all chapters were reviewed by two people—the
chapter authors again. In addition, we wish to thank, as valuable additional
reviewers, John Debenham and Cesar Gonzalez-Perez of the University of
Technology, Sydney. We trust that our joint effort will be a stimulus for industry
in accepting and adopting the agent paradigm in the development of software
systems.
Brian Henderson-Sellers, Sydney, Australia

Paolo Giorgini, Trento, Italy
TEAM LinG
xiv
TEAM LinG
Agent-Oriented Methodologies: An Introduction 1
Chapter I
Agent-Oriented
Methodologies:
An Introduction
Paolo Giorgini
University of Trento, Italy
Abstract
As an introduction to agent-oriented (AO) methodologies, we first describe

the characteristics of both agents and multi-agent systems (MASs). This
leads to a discussion of what makes an AO methodology that can be used
to build an MAS. Finally, we briefly introduce the ten methodologies that
are described in the remaining chapters in this book.
Introduction
A methodology aims to prescribe all the elements necessary for the development
of a software system, especially in the context of commercial applications. Prior
to industry adoption, however, it is necessary for researchers to create that
methodology. This has led to academic and industry researchers creating a large
number of methodological approaches. A decade ago, there were estimated to
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
TEAM LinG
2 Giorgini & Henderson-Sellers
be over a thousand methodological approaches to software development

(Jayaratna, 1994), although these can be grouped into a much smaller number
(around five) of software development approaches (Iivari, Hirschheim, &
Klein, 1999). To these can be added a sixth: agent-oriented (AO) methodologies;
that is, methodological approaches suitable for the development of agent-
oriented or agent-based software.1
In parallel to the growth and availability of object-oriented (OO) systems
development methodologies in the nineties, we are now seeing the burgeoning of
a number of innovative AO methodologies, several of which form the core of this
book. However, in contrast to OO methodologies, the field is not industry-
driven—most AO methodologies are supported by small teams of academic
researchers. Based on an observation that the coalescence of groups of OO
methodologies in the late 1990s led to an increased take-up by industry of the
object-oriented paradigm for system development and project management, this
book aims to encourage first the coalescence and collaboration between
research groups and then, hopefully, more rapid industry adoption of AO
methodological approaches. In other words, most AO methodologies are (at the
time of writing) in an early stage and still in the first context of mostly “academic”
methodologies for agent-oriented systems development, albeit that many of
these methodologies have been tested in small, industrial applications. One
purpose of this book is to identify those predominant and tested AO methodolo-
gies, characterize them, analyse them, and seek some method of unification and
consolidation with the hope that, in so doing, the community of scholars
supporting AO methodologies will soon be able to transfer those innovative ideas
into industry acceptance. This means mimicking the OO transition curve by
seeking consolidation. One means of such consolidation is discussed in the last
chapter of the book: the use of a method engineering framework (e.g., Martin &
Odell, 1995) to create a repository of agent-oriented method fragments.
Agents and Multi-Agent Systems

Defining agents is not straightforward. There are many opinions, some of which
you will see reflected in later chapters of this book (see also discussions in, for
example, Luck, Ashri & D’Inverno, 2004). The key characteristics of agents are
widely understood to be highly autonomous, proactive, situated, and directed
software entities. Other characteristics such as mobility are optional and create
a special subtype of agent; whereas some characteristics cannot be used as
determining factors since they are really grey shades of a scale that encom-
passes both objects and agents.
TEAM LinG
In this context, an autonomous agent is one that is totally independent and can
decide its own behaviour, particularly how it will respond to incoming communi-
cations from other agents. A proactive agent is one that can act without any
external prompts. However, it should be noted that this introduces some
problems, since there is also a large literature on purely reactive agents that
would not be classified as agents with this categorization. Although reactive
agents dominate in some domains, in reality, most agents being designed today
have both proactive and reactive behaviour. Balancing the two is the key
challenge for designers of agent-oriented software systems.
The characteristic of situatedness means that agents are contained totally within
some specific environment. They are able to perceive this environment, be acted
upon by the environment, and, in turn, affect the environment. Finally, the
directedness means that agents possess some well-defined goal and their
behaviour is seen as being directed towards effecting or achieving that goal.
Comparison with objects is often made. Some see agents as “clever objects” or
“objects that can say no.” This means that a hybrid agent+object system is
entirely feasible. Others see agents at a much higher level of abstraction (e.g.,
Milgrom et al., 2001), much in the same way that OO specialists view compo-
nents at a similar more granular level. Indeed, it is still unresolved as to how the
scale of objects, components, and agents are matched and to what extent hybrid
object/component/agent systems are feasible.
Some consequences of these high-level definitions are that agents participate in
decision-making cycles, sometimes labelled as “perceive-decide-act” cycles. To
achieve this, we have to consider other lower-level characteristics such as the
roles that agents play, the metaphor of the agents having a mental state, including
the possession of skills and responsibilities, aptitudes, and capabilities. When
considering their interactions via perceptions and actions with other agents and
the environment, we introduce notions of perceptions, actions, and agent
communication languages. Negotiating skills involve the consideration of con-
tract nets, auction strategies, and the issues of competition versus cooperation.
Defining a Multi-Agent System (MAS) is also not straightforward. However,
almost all the definitions given in the literature conceive a MAS as a system
composed of cooperative or competitive agents that interact with one another in
order to achieve individual or common goals. From the software engineering
point of view, one of the most important characteristics of a MAS is that the final
set of agents is generally not given at design time (only the initial set is specified),
but rather at run time. This basically means that, in practice, MASs are based on
open architectures that allow new agents to dynamically join and leave the system.
The major difference with the OO approach, where objects can also be given at
run time and join and leave the system dynamically, is that agents can do this
autonomously showing proactive behaviors not completely predictable a priori.
TEAM LinG
A MAS contains agents (and not, say, objects); consequently, it too has some of
these typical agent characteristics. Thus key characteristics of a MAS can be
said to be autonomy, situatedness, proactivity, and sociality. Of these, perhaps
proactivity is the most contentious since, as noted above, it is generally agreed
that agents possess various degrees of both proactive and reactive behaviour.
Secondly, autonomy is not a binary characteristic either, since active objects,
used for instance in the context of event-driven programming, can also be said
to exhibit some degree of proactivity. Notwithstanding these two concerns, these
agent characteristics lead to a set of desirable high-level characteristics (Milgrom
et al., 2001) including adaptiveness, flexibility, scalability, maintainability, and
likely emergent behaviour. While these are said to be “desirable” characteristics,
it is perhaps the last of this list that causes most concern. Emergence is usually
linked to Complex Adaptive Systems (CAS) theory. Although there are many
shades of definition of what is meant by emergence in the CAS community, the
general interpretation is that an emergent behaviour is one that cannot be
predicted by inspection of the individual parts. This means that it is not visible
from a bottom-up analysis and, arguably therefore, must be considered at the
system level. Since this sort of emergent behaviour is generally encouraged,
allowing it to emerge unconstrained and unplanned is clearly dangerous in certain
circumstances (whilst beneficial in others). To alleviate this concern of an
uncontrolled and uncontrollable agent system wreaking havoc, clearly emergent
behaviour has to be considered and planned for at the systems level using top-
down analysis and design techniques. This is still an area that is largely unknown
in MAS methodologies. ADELFE starts along this path with its consideration of
adaptive MAS (see Chapter VII for further details) in which agents that
permanently try to maintain cooperative interactions with others.
Many AO methodologies (e.g., Gaia and Tropos) use the metaphor of the human
organization (possibly divided into sub-organizations) in which agents play one or
more roles and interact with each other. Human organization models and
structures are consequently used to design MAS (see, for instance, the use of
architectural patterns in Tropos or the organization models in MAS-
commonKADS). Concepts like role, social dependency, and organizational rules
are used not just to model the environment in which the system will work, but the
system itself. Given the organizational nature of a MAS, one of the most
important activities in an AO methodology results in the definition of the
interaction and cooperation models that capture the social relationships and
dependencies between agents and the roles they play within the system.
Interaction and cooperation models are generally very abstract, and they are
concretized implementing interaction protocols in later phases of the design.
Although the Agent-Oriented Programming (AOP) paradigm was introduced
more than ten years ago by Yoav Shoam in his seminal work (Shoham, 1993), still
there are no AO languages used in practice for developing an MAS. Some tools
TEAM LinG
have been developed in recent years to support the implementation of agents and
multi-agent systems, but still none are based on a proper agent-oriented
language. An interesting and very long list of agent tools is available at the
AgentLink Web site (http://www.agentlink.org). Current agent development
tools are mainly built on top of Java and use the object-oriented paradigm for
implementing software. The methodologies presented in this book do not have as
their main focus the implementation phase, although many of them give some
indications how to do that. The most used developing tools are JACK (AOS,
2000) and JADE (http://www.jade.cselt.it/).
JACK is a commercial agent-oriented development environment built on top of
and fully integrated with Java. It includes all components of the Java develop-
ment environment and also offers specific extensions to implement agent
behaviour. JACK provides agent-oriented extensions to the Java programming
language whereby source code is first compiled into regular Java code before
being executed. In JACK, a system is modelled in terms of agents defined by
capabilities, which in turn are defined in terms of plans (set of actions), events,
beliefs, and other capabilities.
JADE (Java Agent DEvelopment Framework) is a free software framework
fully implemented in the Java language. It allows for the implementation of multi-
agent systems through middleware that complies with the FIPA specifications
and through a set of graphical tools that supports the debugging and deployment
phases. The agent platform can be distributed across machines (which do not
even need to share the same operating system) and the configuration can be
controlled via a remote GUI. The configuration can even be changed at run-time
by moving agents from one machine to another one, as and when required.
AO Methodologies
What is an AO Methodology?
While there is much debate on the use of terminology in various subcultures of

information systems and software engineering, it can be generally agreed (e.g.,
Rolland, Prakash, & Benjamen, 1999) that a “methodology” has two important
components: one that describes the process elements of the approach, and a
second that focuses on the work products and their documentation. The second
of these is more visible in the usage of a methodology, which is why the OO
modelling language UML (OMG, 2001) is so frequently (and totally incorrectly)
equated with “all things OO” or even described as a methodology! A modelling
language such as this or its agent-focused counterpart of AUML (Odell,
TEAM LinG
Parunak, & Bauer, 2000) offers an important contribution but has limited scope
within the context of a methodology. The emphasis placed on the product side
of a methodology tends to vary between different authors, as will be seen in the
remainder of this book. Some use UML/AUML and others eschew this as being
inadequate to support the concepts of agents as described in our earlier section
on Agent and Multi-agent Systems, introducing instead their own individualistic
notation and underpinning concepts. When UML-style diagrams are used, it is
assumed that the reader has some familiarity with this kind of graphical notation2;
otherwise, each author fully defines the notational set of icons being used in that
particular methodological approach.
Although these two main components (process and product support) are
generically agreed upon, it is possible to elaborate a little more since there are
issues of people, social structures, project management, quality, and support
tools. These can be reconciled within the process domain along with concerns
about metrics and standards, organizational procedures and norms and, if
possible, all underpinned by a metamodel and ontology (e.g., Henderson-Sellers,
1995; Rolland & Prakash, 1996).
Any methodology also needs to contain sufficient abstractions to fully model and
support agents and MASs—arguably, simple extensions of OO methodologies
are too highly constrained by the sole focus on objects. Thus, an AO methodology
needs to focus on an organized society of agents playing roles within an
environment. Within such an MAS, agents interact according to protocols
determined by the agents’ roles.
We should also ask what it means for a methodology to be “agent-oriented” in
the sense that we talk of an OO methodology in the context of object technology.
In this case, however, object technology has two foci. In an OO methodology,
we use OO concepts to describe the methodology, which, in turn, can be used
to build object-oriented systems. In contrast, when we speak of an AO
methodology, we generally do not mean a methodology that is itself constructed
on agent-oriented principles but merely one that is oriented towards the creation
of agent-based software. Thus, all the chapters except one follow this “defini-
tion.” Only Tropos (described in detail in Chapter 2) claims to use “agent think”
in its very derivation.
Genealogy of Methodologies
Agent-oriented methodologies have several roots. Some are based on ideas from
artificial intelligence (AI), others as direct extensions of existing OO methodolo-
gies, whilst yet others try to merge the two approaches by taking a more purist
approach yet allowing OO ideas when these seem to be sufficient. Figure 1
TEAM LinG
Figure 1. Direct and indirect influences of object-oriented methodologies

on agent-oriented methodologies
MAS-CommonKADS
(+AI/KE)
INGENIAS MaSE
Tropos
MESSAGE Adelfe
RAP AAII Gaia Agent OPEN
AOR RUP OMT Fusion OPEN
OO
PASSI Prometheus
shows these lineages and influences in what might be called a genealogy of the
ten AO methodologies discussed in this book.
Several methodologies acknowledge a direct descendancy from full OO meth-
ods. In particular, MaSE (DeLoach, 1999; Wood & DeLoach, 2000) acknowl-
edges influences from Kendall, Malkoun and Jiang (1996), as well as an heredity
from AAII (Kinny, Georgeff, & Rao, 1996), which in turns was strongly
influenced by the OO methodology of Rumbaugh and colleagues called OMT
(Rumbaugh, Blaha, Premerlani, Eddy, & Lorensen, 1991). Similarly, the OO
methodology of Fusion (Coleman, Arnold, Bodoff, Dollin, & Gilchrist, 1994) was
said to be highly influential in the design of Gaia (Wooldridge, Jennings, & Kinny,
2000; Zambonelli, Jennings, & Wooldridge, 2003). Two other OO approaches
have also been used as the basis for AO extensions. RUP (Kruchten, 1999) has
formed the basis for ADELFE (Bernon, Gleizes, Picard, & Glize, 2002) and also
for MESSAGE (Caire et al., 2001), which, in turn, is the basis for INGENIAS
(Pavon, Gomez-Sanz, & Fuentes, 2005). More recently, RUP has also been used
as one of the inputs (together with AOR [Wagner, 2003]) for RAP (Taveter &
Wagner, 2005). Secondly, the OPEN approach to OO software development has
been extended significantly to support agents, sometimes called Agent OPEN
(Debenham & Henderson-Sellers, 2003). Finally, two other methodologies
exhibit influences from object-oriented methodological approaches. Prometheus
(e.g., Padgham & Winikoff, 2002a,b), although not an OO descendant, does
suggest using OO diagrams and concepts whenever they exist and are compat-
ible with the agent-oriented paradigm. Similarly, PASSI (2005) merges OO3 and
MAS ideas, using UML as its main notation.
TEAM LinG
Somewhat different is the MAS-CommonKADS methodology (Iglesias, Garijo,

Gonzalez, & Velasco, 1996, 1998). This is the only solidly-AI-based methodology
discussed in this book, yet it also claims to have been strongly influenced by OO
methodologies, notably OMT.
Then there are the methodologies that do not acknowledge any direct genealogi-
cal link to other approaches, OO or AO. Discussed in this book is Tropos
(Bresciani, Giorgini, Giunchiglia, Mylopoulos, & Perini, 2004; Castro, Kolp, &
Mylopoulos, 2002; Giorgini, Kolp, Mylopoulos, & Pistore, 2004). Tropos has a
significant input from i* (Yu, 1995) and a distinct strength in early requirements
modelling, focusing as it does on describing the goals of stakeholders that
describe the “why” as well as the more standard support for “what” and “how.”
This use in Tropos of the i* modelling language (particularly in the analysis and
design phases) gives it a different look and feel from those that use Agent UML
(a.k.a. AUML; Odell et al., 2000) as a notation. It also means that the non-OO
mindset permits users of Tropos to take a unique approach to the modelling of
agents in the methodological context. Other approaches not covered in this book
include Nemo (Huget, 2002), MASSIVE (Lind, 1999), Cassiopeia (Collinot &
Drogoul, 1998; Collinot, Drogoul, & Banhamou, 1996) and CAMLE (Shan &
Zhu, 2004)—although in CAMLE there are some parallels drawn between its
notion of “caste” and the concept of an OO class, as well as some connection
to UML’s composition and aggregation relationships.
Further comparisons of these methodologies are undertaken in Chapter 12,
which complements and extends earlier framework-based evaluative studies of,
for instance, Cernuzzi and Rossi (2002), Dam and Winikoff (2004), Sturm and
Shehory (2004) and Tran, Low and Williams (2004).
Common Terms/Concepts Used in the AO Methodologies
The basic set of concepts underlying agent-oriented (AO) methodologies and the
associated agent terminology are not universally agreed upon. Nevertheless,
there is sufficient agreement to make it worthwhile for us to summarize
commonly agreed upon terms here in Chapter 1 in order that authors of later
chapters need not repeat this material. Bear in mind, however, that each
methodological approach may treat these terms and their underpinning concep-
tual base slightly differently—as will be pointed out when necessary.
Agents are often contrasted with objects and the question —“What makes an agent
an agent and not an object?” – is particularly difficult to answer when one considers
the concepts of “active objects” in an OO modelling language such as the UML.
The novelty of agents is said to be that they are proactive (as well as reactive),
have a high degree of autonomy, and are situated in and interact with their
TEAM LinG
environment (Zambonelli, Jennings, & Wooldridge, 2001), which is sometimes

considered simply as a resource. This introduces (beyond objects) issues to do
with not only the environment itself but also the direct interactions between the
agent(s) and their environment. Thus, interfaces are as or more important in
agents than in objects and, particularly, object-implemented components. When
an agent perceives its environment, perhaps by means of a sensor of some kind,
it is common to model that in terms of percepts. 4 When an agent interacts with
its environment in order to make a change in the environment, it is called an
action. The mechanism by which this is accomplished is often called an effector
(see Chapter VI for further details).
Agent behaviour can be classified as reactive or proactive. A reactive agent
only responds to its environment. These changes are communicated to the agent
as events (although events also occur as a direct result of messages sent from
other agents or indeed sent internally to the agent). Thus, changes in the
environment have an immediate effect on the agent. The agent merely reacts to
changing conditions and has no long-term objectives of itself. In contrast, a
proactive agent has its own objectives. These are usually represented as one or
more goals (e.g., Dardenne, Lamsweerde, & Fickas, 1993; Giorgini et al., 2004;
Kendall & Zhao, 1998). To achieve a goal, it is usual to construct a plan and then
to execute that plan by means of process elements known as actions (or often
as tasks) (Figure 2). In reality, many agents are designed as hybrid agents,
possessing both reactive and proactive characteristics. The challenge then is for
the designer to balance these two very different behaviours in order to create an
overall optimal behaviour.
One well-known agent architecture5 that reflects many of these notions is the
Beliefs, Desires, and Intentions (BDI) architecture of Rao and Georgeff (1995).
Winikoff, Padgham, and Harland (2001) summarize this architecture in terms of
three “abstraction layers” called philosophical (renamed here as psychological),
theoretical, and implementation (Table 1). Beliefs, Desires, and Intentions are
seen as high-level, abstract, externally ascribed characteristics. These three
characteristics are then mapped through to the design or model layer. In
particular, we note in Table 1 that Beliefs represent the agent’s knowledge at
various granularity levels, while Desires, which represent heterogeneous objec-
tives possibly including some conflicts, map to Goals (now a consistent set of
objectives) within the agent, and Intentions are mapped to Committed Goals (a
coherent subset of goals with no conflicts or contradictions). In this table (from
Henderson-Sellers, Tran, & Debenham, 2005), Plans are included specifically to
account for the “how” element not originally formalized in the original BDI
descriptions. Typically, each goal would have a link to at least one plan. These
ideas have been described by Henderson-Sellers et al., 2005) by a metamodel
fragment as shown in Figure 3.
TEAM LinG
Figure 2. Metamodel fragment showing, inter alia, the links between goals
and tasks
{consisten t set of}

Percept Event Belief Goalbank Desire
*
leads to
can
tr i g 1
g er n
ew
Action
(a.k.a. Task) Goal 1 Intention
{ cons ists of}
1
leads to
Plan *
Table 1. Relationships between terminology of BDI model (after Henderson-

Sellers et al., 2005)
Viewpoint Column 3 Column 3 +

Commitment
Psychology Belief Desire Intention Wherewithal
(“how”)
Design/Model World Model Goal Commitment Plan
Implementation Knowledge Base - - Running (or
instantiated)
Plan
The BDI and similar models offer a description of the internal structure of an
agent. However, agents are social entities and thus optimal performance is more
likely from a cluster of agents. This is an MAS or multi-agent system. The
methodologies in this book are aimed at building MASs and not single-agent
systems. A metaphor that is often used is that of the (human) organization, in
which the participating agents are said to exhibit social behaviour. Theories
developed for human organizations are often usefully applied, such as that of
social commitment (Cavedon & Sonenberg, 1998; Yolum & Singh, 2002) and
social norms (Castelfranchi, Dignum, Jonker, & Treur, 2000). Within this social
environment, as with humans, agents are seen to form teams (Cohen &
Levesque, 1991) in which agents play roles (Kendall, 2000). In fact, the notion
of a role, while supported in some OO approaches (e.g., Reenskaug, Wold &
Lehne, 1996; Firesmith & Henderson-Sellers, 2002), is a major differentiating
factor for agents. In fact, in the comparative surveys discussed above and
further in Chapter XII, one common, major classification axis is whether the AO
methodology is a role-based one or not.
TEAM LinG
Figure 3. Metamodel of concepts used in the BDI architecture (after

Henderson-Sellers et al., 2005)
Agent
Characteristic
Agent Agent
External Internal
Characteristic Characteristic
Knowledge
Belief
Repository
Goal or
Desire
Goalbank
Intenti on Commitment
com mi tte d: TRU E com mi tte d: TRU E
1..*
Plan
If agents are operating in a communal workplace, then clearly they need to

communicate even more urgently than do objects. While objects react to
incoming messages and also to events in most modern OO language, agents have
the ability through their autonomy and proactive behaviour to cooperate and
coordinate with each other by the exchange of messages. The major difference
with objects is that agents can receive messages that are not confined to
execution requests but can also consist of information or requests for information
(Faber, 1999). Agent-to-agent communication is a major research area in MAS
behaviour. We note here that the key issues are how to describe agent messages
in terms of interaction and communication protocols, perhaps using a formal,
mathematically based language.
An MAS clearly contains many agents within the contextual environment. In
addition to inter-agent communication, we need to recognize that, within an
MAS, agents need to both compete and cooperate. Although essentially selfish
in their autonomy, agents act like humans: sometimes aiming to fulfil their own
goals at the expense of all other agents/humans but mostly in a more social
structure in which it is recognized that collaboration and sharing of work is
mutually beneficial as well as individualistically profitable. Thus, the notion of
agents organized to work within a social structure is also a very strong driver in
AO methodologies (e.g., Zambonelli et al., 2001). Indeed, some of the method-
ologies discussed in this book argue that their main differentiator is that they
TEAM LinG
address these issues of social structure as a top priority, perhaps downplaying the
discussions about agent infrastructure and whether models such as BDI are
optimum.
Moving from agent infrastructure and communication to process elements, we
should briefly outline the use of various terms such as lifecycle, analysis, design,
and implementation. In the 1970s and 1980s, these terms were generally
understood and related to organizational structure within software development
companies, particularly those using the waterfall approach. This described a
number of “phases,” the totality of which was called the software development
life cycle or SDLC. However, the advent of object technology and OO software
development methodologies throughout the 1990s led to an avoidance of these
terms on the macro-scale.
Analysis is equated to the understanding of something already in existence,
sometimes labelled “discovery.” It relates to the problem space. In contrast,
design is considered as part of the solution space in which various possible
“answers” are considered; thus, it could be labelled “invention” (Booch, 1994).
The argument is that these do not occur sequentially on a timescale of months
but in normal human cognition on a timescale of seconds and highly iteratively.
Together, these two obsolescent phases were frequently called “modelling” in
OO methodologies. This leads to a modelling language such as UML potentially
having an equivalent scope, that is, “analysis” and “design” (although, in reality,
UML is heavily biased towards “design”). This, in turn, often leads to confusion
since clearly the “modelling phase” is a lengthy one in which initially there is more
analysis than design, whereas towards the end of the phase there is more design
than analysis going on. The use of any particular technique or modelling notation
thus shifts in balance from those more useful for “discovery” to those more
focussed on the solution space. Notwithstanding, it is sometimes useful to re-
introduce the analysis and design terms, not as straitjackets for two lengthy
sequential, non-iterative phases, but simply to remind the reader and user of the
methodology of the shifting balance described above. This then permits discus-
sion of more “analysis-type/design-type” techniques under the banner of an
“analysis/design phase.”
Since different methodology authors have different models at a granularity
beneath the overall SDLC, we will not attempt here to prescribe the internal
structure of the SDLC but will leave that to individual chapter authors. An
emerging framework that is hinted at in some chapters is Model-Driven
Architecture (MDA). This is a fairly recent initiative of the Object Management
Group (OMG) that attempts to supply an architectural infrastructure to SDLC
by identifying a Platform-Independent Model (PIM) that avoids any assumptions
about operating system, programming language, hardware, and so forth. This
PIM is then translated (the aim is to eventually be able to do this automatically)
to a Platform Specific Model or PSM (Kleppe, Warmer, & Bast, 2003). The
TEAM LinG
applicability of this to AO methodologies has not yet been fully explored – initial
steps towards this goal are discussed by Taveter and Wagner (2005).
Introducing the Methodologies

The methodologies selected for this volume straddle object-oriented and AI
concepts. We begin with a methodology (Tropos) that avows to use the agent
paradigm in its very design, as well as being appropriate, as all the others in this
book, for the development of software systems aligned with the agent-oriented
paradigm of computing. The next two methodologies to be considered, MAS-
CommonKADS and PASSI, both epitomize the bridging to be undertaken
between OO and AI, while in Prometheus, OO concepts are used when they are
applicable but are otherwise eschewed. Gaia is a methodology that has been
highly influenced by object technology yet retains a truly agent-oriented feel.
The next group of four methodologies centers on specific extensions to the
object-oriented methodology, RUP. The specific agent extensions portrayed
here are ADELFE, which specializes in adaptive agents, MESSAGE (and its
“offspring” INGENIAS) together with RAP, which utilizes not only RUP but
also the modelling language of AOR, created by the same authors. A second OO
influence, that of the older approach of OMT, is seen in our last methodology,
MaSE, which is influenced also by the AAII work of a decade ago and the
influential role modelling work of Kendall and colleagues (Kendall, Malkoun, &
Jiang, 1996).
Acknowledgments
This is Contribution number 04/30 of the Centre for Object Technology Appli-
cations and Research.
References
AOS (2000). JACK Intelligent Agents User Guide, AOS Technical Report,
Agent Oriented Software Pty Ltd, July. Retrieved from: http://
www.jackagents.com/docs/jack/html/index.html
TEAM LinG
Bernon, C., Gleizes, M.-P., Picard, G., & Glize, P. (2002). The ADELFE
methodology for an intranet system design. In P. Giorgini, Y. Lespérance,
G. Wagner, & E. Yu (Eds.), Proceedings of Agent-Oriented Information
Systems, AOIS-2002 (p. 1-15). AOIS.org.
Booch, G. (1994). Object-oriented analysis and design (2nd ed.). Redwood
City, CA: The Benjamin/Cummings Publishing Company, Inc.
Bresciani, P., Giorgini, P., Giunchiglia, F., Mylopolous, J., & Perini, A. (2004).
Tropos: An agent-oriented software development methodology. Autono-
mous Agents and Multi-Agent Systems, 8(3), 203-236.
Burrafato, P. & Cossentino, M. (2002). Designing a multi-agent solution for a
bookstore with the PASSI methodology. In P. Giorgini, Y. Lespérance, G.
Wagner & E. Yu (Eds.), Proceedings of the Agent-Oriented Informa-
tion Systems 2002 (pp. 102-118). AOIS.org.
Caire, G., Coulier, W., Garijo, F., Gomez, J., Pavon, J., Leal, F., Chainho, P.,
Kearney, P., Stark, J., Evans, R., & Massonet, P. (2001). Agent-oriented
analysis using MESSAGE/UML. In M. Wooldridge, G. Wei, & P. Ciancarini
(Eds.), Agent-oriented software engineering II (p. 119-135). LNCS
2222. Berlin: Springer-Verlag.
Castelfranchi, C., Dignum, F., Jonker, C., & Treur, J. (2000). Deliberate
normative agents: Principles and architectures. In N. Jennings & Y.
Lespérance (Eds.), Intelligent agents VI (p. 364-378). Berlin: Springer-
Verlag.
Castro, J., Kolp, M., & Mylopoulos, J. (2002). Towards requirements-driven
information systems engineering: The Tropos project. Information Sys-
tems, 27(6), 365-389.
Cavedon, L. & Sonenberg, L. (1998). On social commitment, roles and preferred
goals. In Proceedings of the Third International Conference on Multi-
Agent Systems (ICMAS), July 3-7, Paris (pp. 80-87). IEEE Computer
Society.
Cernuzzi, L. & Rossi, G. (2002). On the evaluation of agent oriented methodolo-
gies. In Proceedings of OOPSLA 2002 Workshop on Agent-Oriented
Methodologies (pp. 21-30). Sydney, AUS: Centre for Object Technology
Applications and Research.
Chan, K., Sterling, L., & Karunasekera, S. (2004). Agent-oriented software
analysis. In Proceedings of 2004 Australian Software Engineering
Conference (pp. 20-27). Los Alamitos, CA: IEEE Computer Society Press.
Cohen, P.R. & Levesque, H.J. (1991). Teamwork. Nous, 25(4), 487-512.
Coleman, D., Arnold, P., Bodoff, S., Dollin, C., & Gilchrist, H. (1994). Object-
oriented development. The fusion method. Englewood Cliffs, NJ: Prentice
Hall.
TEAM LinG
Collinot, A. & Drogoul, A. (1998). Using the Cassiopeia method to design a

soccer robot team. Applied Artificial Intelligence (AAI) Journal, 12(2-
3), 127-147.
Collinot, A., Drogoul, A., & Benhamou, P. (1996). Agent-oriented design of a
soccer robot team. In Proceedings of the Second International Confer-
ence on Multi-Agent Systems (ICMAS’96) (pp 41-57). Menlo Park, CA:
American Association for Artificial Intelligence.
Cossentino, M. (2005). From requirements to code with the PASSI methodol-
ogy. In B. Henderson-Sellers & P. Giorgini (Eds.), Agent-oriented meth-
odologies (Chapter 4). Hershey, PA: Idea Group.
Cossentino, M. & Potts, C. (2002). A CASE tool supported methodology for the
design of multi-agent systems. In H.R. Ababnia & Y. Mun (Eds.),
Proceedings of the 2002 International Conference on Software Engi-
neering Research and Practice (SERP’02), Las Vegas, June 24-27 (pp.
315-321).
Dam, K.H. & Winikoff, M. (2004). Comparing agent-oriented methodologies. In
P. Giorgini, B. Henderson-Sellers, & M. Winikoff (Eds.), Agent-oriented
systems (pp. 78-93). LNAI 3030. Berlin: Springer-Verlag
Dardenne, A., Lamsweerde, A. v., & Fickas, S. (1993).Goal-directed require-
ments acquisition. Science of Computer Programming, 20, 3-50.
Debenham, J. & Henderson-Sellers, B. (2003). Designing agent-based process
systems - Extending the OPEN Process Framework. In V. Plekhanova
(Ed.), Intelligent agent software engineering (Chapter VIII, pp. 160-
190). Hershey, PA: Idea Group Publishing.
DeLoach, S.A. (1999). Multiagent systems engineering: A methodology and
language for designing agent systems. In Proceedings of the First
International Bi-conference Workshop on Agent-Oriented Informa-
tion Systems (AOIS ’99), May 1, Seattle. AOIS.org.
Faber J. (1999). Multi-agent systems: An introduction to distributed artifi-
cial intelligence. Reading, MA: Addison-Wesley.
Firesmith, D.G. & Henderson-Sellers, B. (2002). The OPEN process frame-
work. Harlow, UK: Addison Wesley.
Giorgini, P., Kolp, M., Mylopoulos, J., & Pistore, M. (2004). The Tropos
methodology: An overview. In F. Bergenti, M.P. Gleizes, & F. Zambonelli
(Eds.), Methodologies and software engineering for agent systems (pp.
89-106). Boston: Kluwer Academic Publishing.
Henderson-Sellers, B. (1995). Who needs an OO methodology anyway? Jour-
nal of Object Oriented Programming, 8(6), 6-8.
TEAM LinG
Henderson-Sellers, B., Tran, Q.-N.N., & Debenham, J. (2005). An etymological

and metamodel-based evaluation of the terms “goals and tasks” in agent-
oriented methodologies. J. Object Technol., 4(2), 131-150.
Henderson-Sellers, B. & Unhelkar, B. (2000). OPEN modeling with UML.
London: Addison-Wesley.
Huget, M.-P. (2002). Nemo: An agent-oriented software engineering method-
ology. In Proceedings of OOPSLA 2002 Workshop on Agent-Oriented
Methodologies (pp. 43-53). Sydney, AUS: Centre for Object Technology
Applications and Research.
Iglesias, C.A., Garijo, M., Gonzalez, J.C., & Velasco, J.R. (1996). A method-
ological proposal for multiagent systems development extending
CommonKADS. In Proceedings of 10th KAW, Banff, Canada. Available
online http://ksi.cpsc.ucalgary.ca/KAW/KAW96/KAW96Proc.html
Iglesias, C.A., Garijo, M., Gonzalez, J.C., & Velasco, J.R. (1998). Analysis and
design of multi-agent systems using MAS-CommonKADS. In M.P. Singh,
A. Rao, & M.J. Wooldridge (Eds.), Intelligent agents IV: Agent theories,
architectures, and languages (LNAI Vol. 1365, pp. 313-326). Berlin:
Springer-Verlag.
Iivari, J., Hirschheim, R., & Klein, H.K. (1999). Beyond methodologies: Keeping
up with information systems development approaches through dynamic
classification. In Proceedings of HICSS 1999 (p. 7044). Los Alamitos,
CA: IEEE Computer Society Press.
Jayaratna, N. (1994). Understanding and evaluating methodologies, NISAD:
A systematic framework. Maidenhead, UK: McGraw-Hill.
Kendall, E.A. (2000). Software engineering with role modelling. In Proceedings
of the Agent-Oriented Software Engineering Workshop (pp. 163-169).
LNCS, Vol. 1957. Berlin: Springer-Verlag.
Kendall, E.A., Malkoun, M.T., & Jiang, C. (1996). A methodology for develop-
ing agent based systems for enterprise integration. In P. Bernus & L.
Nemes (Eds.), Modelling and methodologies for enterprise integra-
tion. London: Chapman and Hall.
Kendall, E.A. & Zhao, L. (1998). Capturing and structuring goals. Presented at the
Workshop on Use Case Patterns, Object Oriented Programming Systems
Languages and Architectures, Vancouver, BC, Canada, October 18-22.
Kinny, D., Georgeff, M., & Rao, A. (1996). A methodology and modelling
techniques for systems of BDI agents. Technical Note 58, Australian
Artificial Intelligence Institute, also published in Proceedings of Agents
Breaking Away, the 7th European Workshop on Modelling Autono-
mous Agents in a Multi-Agent World (MAAMAW’96) (pp. 56-71).
Springer-Verlag.
TEAM LinG
Kleppe, A., Warmer, J., & Bast, W. (2003). MDA explained: The model driven
architecture - Practice and promise. Reading, MA: Addison-Wesley.
Kruchten, P. (1999). The rational unified process. An introduction. Reading,
MA: Addison-Wesley.
Lind, J. (1999). Iterative software engineering for multiagent systems. The
MASSIVE Method. LNAI 1994. Berlin: Springer-Verlag.
Luck, M., Ashri, R., & D’Inverno, M. (2004). Agent-based software develop-
ment. Boston: Artech House.
Martin, J. & Odell, J.J. (1995). Object-oriented methods: Pragmatics and
considerations. Upper Saddle River, NJ: Prentice-Hall.
Milgrom, E., Chainho, P., Deville, Y., Evans, R., Kearney, P., & Massonet, P.
(2001). MESSAGE: Methodology for engineering systems of software
agents. Final guidelines for the identification of relevant problem
areas where agent technology is appropriate. EUROSCOM Project
Report P907. Available online http://www.eurescom.dr/~public-
webspace/P800-series/P815/web/index.htm
Odell, J., Van Dyke Parunak, H., & Bauer, B. (2000). Extending UML for
agents. In G. Wagner, Y. Lesperance & E. Yu (Eds.), Proceedings of
Agent-Oriented Information Systems Workshop (pp. 3-17). 17th Na-
tional Conference on Artificial Intelligence, Austin, TX.
OMG (2001). OMG Unified Modeling Language Specification, Version 1.4.
September 2001. OMG document formal/01-09-68 through 80 (13 docu-
ments). Available online http://www.omg.org
Padgham, L. & Winikoff, M. (2002a). Prometheus: A methodology for develop-
ing intelligent agents. In F. Giunchiglia, J. Odell, & G. Weiß (Eds.), Agent-
oriented Software Engineering III Proceedings of the Third Interna-
tional Workshop on Agent-Oriented Software Engineering (AAMAS’02)
(pp. 174-185). LNCS 2585.
Padgham, L. & Winikoff, M. (2002b). Prometheus: A pragmatic methodology
for engineering intelligent agents. In J. Debenham, B. Henderson-Sellers,
N. Jennings, & J.J. Odell (Eds.), Agent-oriented Software Engineering
III Proceedings of the Workshop on Agent-oriented Methodologies at
OOPSLA 2002, November 4, Seattle (pp. 97-108). Sydney: Centre for
Object Technology Applications and Research.
Pavón, J., Gomez-Sanz, J., & Fuentes, R. (2005). The INGENIAS methodology
and tools. In B. Henderson-Sellers & P. Giorgini (Eds.), Agent-oriented
methodologies (Chapter 4). Hershey, PA: Idea Group.
Rao, A.S. & Georgeff, M.P. (1995). BDI agents: From theory to practice. In
V.R. Lesser & L. Gasser (Eds.), Proceedings of the First International
TEAM LinG
Conference on Multi-Agent Systems, San Francisco (pp. 312-319).

Cambrige, MA: MIT Press.
Rolland, C. & Prakash, N. (1996). A proposal for context-specific method
engineering. In Proceedings of the IFIP WG8.1 Conference on Method
Engineering (pp. 191-208). London: Chapman and Hall.
Rolland, C., Prakash, N., & Benjamen, A. (1999). A multi-model view of process
modelling. Requirements Eng. J., 4(4), 169-187.
Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., & Lorensen, W. (1991).
Object-oriented modeling and design. Englewood Cliffs, NJ: Prentice-
Hall.
Shan, L. & Zhu, H. (2004). Software engineering for multi-agent systems III:
Research issues and practical applications. In R. Choren, A. Garcia, C.
Lucena, & A. Romanovsky (Eds.), Proceedings of the Third Interna-
tional Workshop on Software Engineering for Large-Scale Multi-
Agent Systems, (pp. 144-161). Berlin: Springer-Verlag.
Shoham, Y. (1993). Agent-oriented programming. Artificial Intelligence, 60(1),
51-568.
Sturm, A. & Shehory, O. (2004). A framework for evaluating agent-oriented
methodologies. In P. Giorgini, B. Henderson-Sellers, & M. Winikoff (Eds.),
Agent-oriented systems (pp. 94-109). LNAI 3030. Berlin: Springer-
Verlag.
Taveter, K. & Wagner, G. (2005). Towards radical agent-oriented software
engineering processes based on AOR modelling. In B. Henderson-Sellers
& P. Giorgini (Eds.), Agent-oriented methodologies (Chapter 10). Hershey,
PA: Idea Group.
Tran, Q.-N.N., Low, G., & Williams, M.-A. (2004). A preliminary comparative
feature analysis of multi-agent systems development methodologies. In
Proceedings of AOIS@CAiSE*04, Faculty of Computer Science and
Information, Riga Technical University, Latvia (pp. 386-398).
Wagner, G. (2003). The agent-object relationship metamodel: Towards a unified
view of state and behaviour. Inf. Systems, 28(5), 475-504.
Winikoff, M., Padgham, L., & Harland, J. (2001). Simplifying the development
of intelligent agents. In M. Stumptner, D. Corbett, & M. J. Brooks (Eds.),
Proceedings of the 14th Australian Joint Conference on Artificial
Intelligence (AI’01), Adelaide, 10-14 December (pp. 557-558). LNAI
2256, Springer-Verlag.
Wood, M. & DeLoach, S.A. (2000). An overview of the multiagent systems
engineering methodology. In P. Ciancarini & M. Wooldridge (Eds.),
Proceedings of the 1st International Workshop on Agent-Oriented
TEAM LinG
Software Engineering (AOSE-2000) (pp. 207-222). LNCS 1957, Springer-

Verlag.
Wooldridge, M., Jennings, N.R., & Kinny, D. (2000). The Gaia methodology for
agent-oriented analysis and design. Journal Autonomous Agents and
Multi-Agent Systems, 3, 285-312.
Yolum, P. & Singh, M.P. (2002). Flexible protocol specification and execution:
Applying event calculus planning using commitments. In Proceedings of
the 1st Joint Conference on Autonomous Agents and MultiAgent
Systems (AAMAS) (pp. 527-534). New York: ACM Press.
Yu, E. (1995). Modelling strategic relationships for process reengineering.
PhD Thesis, University of Toronto, Department of Computer Science.
Zambonelli, F., Jennings, N. R., & Wooldridge, M. (2001). Organisational
abstractions for the analysis and design of multi-agent systems. In Pro-
ceedings of the Agent-Oriented Software Engineering Workshop (pp.
235-251). LNCS, Vol. 1957. Berlin: Springer-Verlag.
Zambonelli, F., Jennings, N., & Wooldridge, M. (2003). Developing multiagent
systems: The Gaia methodology. ACM Transactions on Software Engi-
neering and Methodology, 12(3), 317-370.
Endnotes
1
It has also been argued (Chan, Sterling, & Karunasekera, 2004) that use of
AO analysis may be beneficial even if the implementation is not in an AO
language but, say, uses object-oriented design and programming.
2
If not, a useful introduction is to be found in Henderson-Sellers and
Unhelkar (2000)
3
In earlier publications (e.g., Burrafato & Cossentino, 2002; Cossentino &
Potts, 2002) this was not obvious.
4
Since agents are part of the environment, messages received from other
agents can also be considered as percepts.
5
See also discussion in Chapter 10.
TEAM LinG
20 Giorgini, Kolp, Mylopoulos & Castro
Chapter II
Tropos:
A Requirements-Driven
Methodology for
Agent-Oriented Software
Paolo Giorgini
University of Trento, Italy
Manuel Kolp
University of Louvain, Belgium
John Mylopoulos
University of Toronto, Canada
Jaelson Castro
Federal University of Pernambuco, Brazil
Abstract
Software systems of the future will have to perform well within ever-
changing organizational environments. Unfortunately, existing software
development methodologies have traditionally been inspired by programming
concepts rather than organizational ones, leading to a semantic gap
between the system and its operational environment. To reduce this gap, we
propose a software development methodology named Tropos that is founded
TEAM LinG
Tropos: A Requirements-Driven Methodology for Agent-Oriented Software 21
on the i* organizational modeling framework. i* offers the notions of actor,

goal, and (actor) dependency. Tropos uses these concepts as a basis to model
early and late requirements, architectural design, and detailed design for
a software system. The chapter outlines Tropos phases through an e-
business example. The methodology is a good complement to proposals for
agent-oriented programming platforms.
Introduction
Organizational software systems have traditionally suffered from an impedance
mismatch between their outer and inner environments: their operational environ-
ment is understood in terms of actors, responsibilities, objectives, tasks, and
resources, while their inner environment is conceived as a collection of (soft-
ware) modules, entities (e.g., objects, components), data structures, and inter-
faces. This mismatch contributes greatly to poor software quality and to frequent
failures of software system development projects.
One reason for this mismatch is that development methodologies have tradition-
ally been inspired and driven by the programming paradigm of the day. So, during
the era of structured programming, structured analysis and design techniques
were proposed (DeMarco, 1978; Yourdon & Constantine, 1979), while object-
oriented programming has given rise more recently to object-oriented design and
analysis (Booch, Rumbaugh, & Jacobson, 1999; Wirfs-Brock, Wilkerson, &
Wiener, 1990). For structured development techniques, this meant that, through-
out software development, the developer could conceptualize the system in
terms of functions and processes, inputs and outputs. For object-oriented
development, on the other hand, conceptualizations consist of objects, classes,
methods, inheritance, and the like, throughout.
Using the same concepts to align requirements analysis with system design and
implementation makes perfect sense. For one thing, such an alignment reduces
impedance mismatches between different development phases. Moreover, such
an alignment can lead to coherent toolsets and techniques for developing
software. In addition, it can streamline the development process itself.
However, why base such an alignment on implementation concepts? Require-
ments analysis is arguably the most important stage of software development.
This is the phase where technical considerations have to be balanced against
social and organizational ones. This is also the phase where the operational
environment of the system is modeled and analyzed. Not surprisingly, this is also
the phase where the most and costliest errors are introduced compared to other
development phases. Even if (or rather, when) the importance of design and
TEAM LinG
implementation phases wanes sometime in the future, requirements analysis will

remain a critical phase for the development of any software system, answering
the most fundamental of all design questions: “what is the system intended for?”
Latest generation software systems, such as enterprise resource planning
(ERP), groupware, knowledge management, and e-business systems, should be
designed to match their operational environment. For instance, ERP systems
have to implement a process view of the enterprise to meet business goals, tightly
integrating all relevant functions of their operational environment. To reduce as
much as possible the impedance mismatch between the system and its environ-
ment, we outline in this chapter a development framework named Tropos that
is requirements-driven in the sense that it is based on concepts used during early
requirements analysis. To this end, we adopt the concepts offered by i* (Yu,
1995), a modeling framework proposing concepts such as actor (actors can be
agents, positions, or roles), as well as social dependencies among actors,
including goal, softgoal, task, and resource dependencies. These concepts are
used for an e-commerce example to model not just early requirements but also
late requirements, as well as architectural and detailed design. The proposed
methodology spans four phases that can be used sequentially or iteratively
(Kruchten, 2003):
• Early requirements, concerned with the understanding of a problem by

studying an organizational setting.
• Late requirements, where the system-to-be is described within its opera-
tional environment, along with relevant functions and qualities.
• Architectural design, where the system’s global architecture is defined in
terms of subsystems, interconnected through data, control, and other
dependencies.
• Detailed design, where the behavior of each architectural component is
further refined.
The proposed methodology includes techniques for generating an implementa-

tion from a Tropos detailed design. It is very natural to use an agent-oriented
programming platform for the implementation, given that the detailed design is
defined in terms of (system) actors, goals, and inter-dependencies among them.
This chapter is organized as follows: Section The Methodology provides an
overview of the methodology, while Section Case Study describes the case study
to be used for illustration purposes. The next sections present the application of
Tropos to the case study. The final section concludes the chapter discussing
strengths and weaknesses of the methodology.
TEAM LinG
The Methodology
Tropos rests on the idea of using requirements modeling concepts to build a
model of the system-to-be within its operational environment. This model is
incrementally refined and extended, providing a common interface to the various
software development activities. The model also serves as a basis for documen-
tation and evolution of the software system.
In the following, we describe and illustrate the four development phases of the
Tropos methodology: Requirements Analysis (early and late), Architectural
Design and Detailed Design.
Requirements Analysis
Requirement analysis represents the initial phase in most software engineering

methodologies. Requirements analysis in Tropos consists of two phases: Early
Requirements and Late Requirements analysis. Early requirements is con-
cerned with understanding the organizational context within which the system-
to-be will eventually function. Late requirements analysis, on the other hand, is
concerned with a definition of the functional and non-functional requirements of
the system-to-be.
Tropos adopts the i* (Yu, 1995) modeling framework for analyzing require-
ments. In i* (which stands for “distributed intentionality”), stakeholders are
represented as (social) actors who depend on each other for goals to be
achieved, tasks to be performed, and resources to be furnished. The i*
framework includes the strategic dependency model (actor diagram in Tropos)
for describing the network of inter-dependencies among actors, as well as the
strategic rationale model (rationale diagram in Tropos) for describing and
supporting the reasoning that each actor goes through concerning its relation-
ships with other actors. These models have been formalized using intentional
concepts from Artificial Intelligence, such as goal, belief, ability, and commit-
ment (e.g., Cohen & Levesque, 1990). The framework has been presented in
detail in Yu (1995) and has been related to different application areas, including
requirements engineering (Yu, 1993), software processes (Yu, 1994), and
business process reengineering (Yu & Mylopoulos, 1996).
During early requirements analysis, the requirements engineer identifies the
domain stakeholders and models them as social actors who depend on one
another for goals to be fulfilled, tasks to be performed, and resources to be
furnished. Through these dependencies, one can answer why questions, in
addition to what and how, regarding system functionality. Answers to why
TEAM LinG
questions ultimately link system functionality to stakeholder needs, preferences,

and objectives. Actor diagrams and rationale diagrams are used in this phase.
An actor diagram is a graph involving actors who have strategic dependencies
among each other. A dependency represents an “agreement” (called dependum)
between two actors—the depender and the dependee. The depender depends
on the dependee to deliver on the dependum. The dependum can be a goal to
be fulfilled, a task to be performed, or a resource to be delivered. In addition,
the depender may depend on the dependee for a softgoal to be fulfilled.
Softgoals represent vaguely defined goals with no clear-cut criteria for their
fulfillment. Graphically, actors are represented as circles; dependums—goals,
softgoals, tasks and resources—are respectively represented as ovals, clouds,
hexagons, and rectangles; and dependencies have the form depender →
dependum → dependee.
Actor diagrams are extended during early requirements analysis by incremen-
tally adding more specific actor dependencies, discovered by a means-ends
analysis of each goal. This analysis is specified using rationale diagrams. A
rationale diagram appears as a balloon within which goals of a specific actor are
analyzed and dependencies with other actors are established. Goals are decom-
posed into subgoals and positive/negative contributions of subgoals to goals are
specified.
During late requirements analysis, the conceptual model developed during early
requirements is extended to include the system-to-be as a new actor, along with
dependencies between this actor and others in its environment. These dependen-
cies define functional and non-functional requirements for the system-to-be.
Actor diagrams and rationale diagrams are also used in this phase.
Architectural Design
System architectural design has been the focus of considerable research during
the last 15 years that has produced well-established architectural styles and
frameworks for evaluating their effectiveness with respect to particular soft-
ware qualities. Examples of styles are pipes-and-filters, event-based, layered,
control loops, and the like (Shaw & Garlan, 1996). In Tropos, we are interested
in developing a suitable set of architectural styles for multi-agent software
systems. Since the fundamental concepts of a multi-agent system (MAS) are
intentional and social, rather than implementation-oriented, we turn to theories
that study social structures that result from a design process, namely, Organi-
zation Theory and Strategic Alliances. Organization Theory (e.g., Scott, 1998)
describes the structure and design of an organization; Strategic Alliances (e.g.,
Morabito, Sack, & Bhate, 1999) model the strategic collaborations of indepen-
TEAM LinG
dent organizational stakeholders who have agreed to pursue a set of business

goals.
We define an organizational style as a metaclass of organizational structures
offering a set of design parameters to coordinate the assignment of organiza-
tional objectives and processes, thereby affecting how the organization itself
functions (Kolp, Giorgini, & Mylopoulos, 2002). Design parameters include,
among others, goal and task assignments, standardization, supervision and
control dependencies, and strategy definitions.
For instance, Structure-in-5 (Mintzberg, 1992) specifies that an organization is
an aggregate of five sub-structures. At the base level sits the Operational Core,
which carries out the basic tasks and procedures directly linked to the production
of products and services (acquisition of inputs, transformation of inputs into
outputs, distribution of outputs). At the top lies the Strategic Apex, which makes
executive decisions ensuring that the organization fulfills its mission in an
effective way and defines the overall strategy of the organization in its
environment. The Middle Line establishes a hierarchy of authority between the
Strategic Apex and the Operational Core. It consists of managers responsible for
supervising and coordinating the activities of the Operational Core. The Tech-
nostructure and the Support are separated from the main line of authority and
influence the operating core only indirectly. The Technostructure serves the
organization by making the work of others more effective, typically by standard-
izing work processes, outputs, and skills. It is also in charge of applying analytical
procedures to adapt the organization to its operational environment. The Support
provides specialized services, at various levels of the hierarchy, outside the basic
operating work flow (e.g., legal counsel, R&D, payroll, cafeteria). For further
details about architectural styles in Tropos, see Do, Faulkner and Kolp (2003)
and Kolp, Giorgini, and Mylopoulos (2003).
Styles can be compared and evaluated with quality attributes (Shaw & Garlan,
1996), also called non-functional requirements (Chung, Nixon, Yu, & Mylopoulos,
2000), such as predictability, security, adaptability, coordinability, availability,
fallibility-tolerance, or modularity.
To cope with non-functional requirements and select the style for the organiza-
tional setting, we go through a means-ends analysis using the non-functional
requirements (NFRs) framework (Chung et al., 2000). We refine the identified
requirements to sub-requirements that are more precise and evaluate alternative
organizational styles against them.
The analysis for selecting an organizational setting that meets the requirements
of the system to build is based on propagation algorithms. Basically, the idea is
to assign a set of initial labels for some requirements of the graph, about their
satisfiability and deniability, and see how this assignment leads to the labels
propagation for other requirements. In particular, we adopt from Giorgini,
TEAM LinG
Mylopoulos, Nicchiarelli, and Sebastiani (2002) both qualitative and numerical

axiomatization for goal (requirements) modeling primitives and label propagation
algorithms that are shown to be sound and complete with respect to their
respective axiomatization.
Detailed Design
The detailed design phase is intended to introduce additional detail for each
architectural component of a system. It consists of defining how the goals
assigned to each actor are fulfilled by agents with respect to social patterns.
For this step, designers can be guided by a catalogue of multi-agent patterns that
offer a set of standard solutions. Considerable work has been done in software
engineering for defining software patterns (see e.g., Gamma, Helm, Johnson, &
Vlissides, 1995). Unfortunately, little emphasis has been put on social and
intentional aspects. Moreover, proposals for agent patterns that do address these
aspects (see e.g., Aridor & Lange, 1998) are not intended for use at a design
level. Instead, such proposals seem to aim at the implementation phase, when
issues such as agent communication, information gathering, or connection setup
are addressed.
Social patterns in Tropos (Do, Kolp, & Pirotte, 2003) are design patterns
focusing on social and intentional aspects that are recurrent in multi-agent and
cooperative systems. In particular, the structures are inspired by the federated
patterns introduced in Hayden, Carrick and Yang (1999) and Kolp, Giorgini, and
Mylopoulos (2001). We have classified them into two categories: Pair and
Mediation.
The Pair patterns – such as booking, call-for-proposal, subscription, or bidding
– describe direct interactions between negotiating agents. For instance, the
Bidding pattern involves an initiator and a number of participants. The initiator
organizes and leads the bidding process, publishes the bid to the participants, and
receives various proposals. At every iteration, the initiator can accept an offer,
raise the bid, or cancel the process.
The Mediation patterns – such as monitor, broker, matchmaker, mediator,
embassy, or wrapper – feature intermediary agents that help other agents to
reach an agreement on an exchange of services. For instance, in the Broker
pattern, the broker agent is an arbiter and intermediary that requests services
from a provider to satisfy the request of a consumer.
Detailed design also includes actor communication and actor behavior. To
support it, we propose the adoption of existing agent communication languages
like FIPA-ACL (Labrou, Finin, & Peng, 1999) or KQML (Finin, Labrou, &
TEAM LinG
Mayfield, 1997), message transportation mechanisms, and other concepts and

tools. One possibility is to adopt extensions to UML (OMG, 1999), like the Agent
Unified Modeling Language (AUML) (Bauer, Muller, & Odell, 2001; Odell, Van
Dyke Parunak, & Bauer, 2000) proposed by the Foundation for Physical
Intelligent Agents (FIPA)(http;//www.fipa.org) and the OMG Agent Work
group.
We have also proposed and defined a set of stereotypes, tagged values, and
constraints to accommodate Tropos concepts within UML (Mylopoulos, Kolp, &
Castro, 2001) for users who wish to use UML as the notation in Tropos.
Case Study
Media Shop is a store selling and shipping different kinds of media items such
as books, newspapers, magazines, audio CDs, videotapes, and the like. Media
Shop customers (on-site or remote) can use a periodically updated catalogue
describing available media items to specify their order. Media Shop is supplied
with the latest releases from Media Producer and in-catalogue items by Media
Supplier. To increase market share, Media Shop has decided to open up a
Business-to-Consumer (B2C) retail sales front on the Internet. With the new
setup, a customer can order Media Shop items in person, by phone, or through
the Internet. The system has been Medi@ and is available on the World Wide
Web using communication facilities provided by Telecom Cpy. It also uses
financial services supplied by Bank Cpy, which specializes in online transac-
tions. The basic objective for the new system is to allow an online customer to
examine the items in the Medi@ Internet catalogue and place orders. The main
interface of the system is shown in Figure 1.
There are no registration restrictions or identification procedures for Medi@
users. Potential customers can search the online store by either browsing the
catalogue or querying the item database. The catalogue groups media items of
the same type into (sub)hierarchies and genres (e.g., audio CDs are classified
into pop, rock, jazz, opera, world, classical music, soundtrack, and so forth) so
that customers can browse only (sub)categories of interest. An online search
engine allows customers with particular items in mind to search title, author/
artist, and description fields through keywords or full-text search. If the item is
not available in the catalogue, the customer has the option of asking Media Shop
to order it, provided the customer has editor/publisher references (e.g., ISBN,
ISSN), and identifies him/herself (in terms of name and credit card number).
Details about media items include title, media category (e.g., book) and genre
TEAM LinG
Figure 1. Interface of the system
(e.g., science-fiction), author/artist, short description, editor/publisher interna-

tional references and information, date, cost, and sometimes pictures (when
available).
Early Requirements Analysis

The elements described in the previous section are sufficient for producing a first
model of an organizational environment. For instance, Figure 2 depicts the actor
diagram of our Medi@ example. The main actors are Customer, Media Shop,
Media Supplier, and Media Producer. Customer depends on Media Shop to
fulfill his/her goal: Buy Media Items. Conversely, Media Shop depends on
Customer to increase market share and make.” Since the dependum Happy
Customers cannot be defined precisely, it is represented as a softgoal. The
TEAM LinG
Figure 2. Actor diagram for a Media Shop
Increase Depender X Dependee

Market Share
Dependency Goal Task
Actor
Consult Legend Resource Softgoal
Media Items
Catalogue
Buy Media Media Continuous Media Quality Media

Customer Items Shop Supply Supplier Packages Producer
Happy Continuing
Customers Business
Customer also depends on Media Shop to consult the catalogue (task

dependency). Furthermore, Media Shop depends on Media Supplier to supply
media items in a continuous way and get a Media Item (resource dependency).
The items are expected to be of good quality because, otherwise, the Continuing
Business dependency would not be fulfilled. Finally, Media Producer is
expected to provide Media Supplier with Quality Packages.
Figure 3 focuses on one of the (soft)goal dependency identified for Media Shop,
namely, Increase Market Share. To achieve that softgoal, the analysis postu-
lates a goal Run Shop that can be fulfilled by means of a task Run Shop. Tasks
are partially ordered sequences of steps intended to accomplish some (soft)goal.
In Tropos, tasks can be decomposed into subtasks and also goals, whose
collective fulfillment completes the task. In Figure 3, Run Shop is decomposed
into goals Handle Billing and Handle Customer Orders, tasks Manage Staff
and Manage Inventory, and softgoal Improve Service, which together accom-
plish the top-level task. Subgoals and subtasks can be specified more precisely
through refinement. For instance, the goal Handle Customer Orders is fulfilled
either through tasks Order by Phone, Order in Person, or Order by Internet,
while the task Manage Inventory would be collectively accomplished by tasks
Sell Stock and Enhance Catalogue. These decompositions eventually allow us
to identify actors who can accomplish a goal, carry out a task, or deliver some
needed resource for Media Shop. Such dependencies in Figure 3 are, among
others, the goal and resource dependencies on Media Supplier for supplying, in
a continuous way, media items to enhance the catalogue and sell products; the
softgoal dependencies on Customer for increasing market share (by running the
shop) and making customers happy (by improving service); and the task
dependency Accounting on Bank Cpy to keep track of business transactions.
TEAM LinG
Figure 3. Means-ends analysis for the softgoal Increase Market Share
Accounting
Telecom Communication Process

Bank Cpy Cpy Services Medi@ Internet
Increase Orders
Market Share
Run
Shop
Buy Media Handle OrderBy
Items Billing Internet
Run Shop
Media OrderBy
Shop Handle Phone
Customer Customer
Improve
Service Orders
Manage
Staff Select
OrderIn Items
Happy Staff Manage Person
Customers Training Inventory
Be Friendly
Determine
Amount
Satisfy
Customer
Media
Desires Sell Stock Enhance Consult
Supplier
Catalogue Catalogue
Media
Items
Continuing
Business
Depender X Dependee Actor
Dependency Goal Task
Continuing Decomposition link Means-ends link

Supply Legend Resource Softgoal Actor Boundary
Late Requirement Analysis
For our example, the Medi@ system is viewed as a full-fledged actor in the actor
diagram depicted in Figure 4. With respect to the actors previously identified,
Customer depends on Media Shop to buy media items, while Media Shop
depends on Customer to increase market share and make them happy (with
Media Shop service). Media Supplier is expected to supply Media Shop with
media items in a continuous way. It can also use Medi@ to determine new needs
from customers, such as media items not available in the catalogue. Medi@ also
expects to be provided with quality packages by Media Producer. As indicated
earlier, Media Shop depends on Medi@ for processing Internet orders and on
Bank Cpy to process business transactions. Customer, in turn, depends on
Medi@ to place orders through the Internet, to search the database for
TEAM LinG
Figure 4. Refined actor diagram for Media Shop
Availability
Internet Telecom
Services Cpy
Browse
Catalogue
Keyword
Search Find User
Medi@ Process New Needs
On-line
Money
Transactions
Place Order
Customer
Bank Cpy
Security
Accounting
Process
Internet Communication
Adaptability Services
Orders
Continuing
Buy Media Business
Items
Media Shop
Media
Increase Supplier
Media Items
Market Share
Happy Continuing
Customers Supply
keywords, or simply to browse the online catalogue. With respect to relevant

qualities, Customer requires that transaction services be secure and available,
while Media Shop expects Medi@ to be easily adaptable (e.g., catalogue
enhancing, item database evolution, user interface update, and so forth). Finally,
Medi@ relies on Internet services provided by Telecom Cpy and on secure
online financial transactions handled by Bank Cpy.
Although an actor diagram provides hints about why processes are structured in
a certain way, it does not sufficiently support the process of suggesting,
exploring, and evaluating alternative solutions. As late requirements analysis
proceeds, Medi@ is given additional responsibilities and ends up as the dependee
of several dependencies. Moreover, the system is decomposed into several sub-
actors that take on some of these responsibilities. This decomposition and
TEAM LinG
responsibility assignment is realized using the same kind of means-ends analysis

illustrated in Figure 3. Hence, the analysis in Figure 5 focuses on the system itself,
instead of an external stakeholder.
Figure 5 postulates a root task Internet Shop Managed providing sufficient
support (++) (Chung et al., 2000) to the softgoal Increase Market Share. That
task is firstly refined into goals Internet Order Handled and Item Searching
Handled; softgoals Attract New Customer, Secure and Available; and tasks
Produce Statistics and Adaptation. To manage Internet orders, Internet Order
Handled is achieved through the task Shopping Cart, which is decomposed into
subtasks Select Item, Add Item, Check Out, and Get Identification Detail.
These are the main process activities required to design an operational online
shopping cart (Conallen, 2000). The latter (task) is achieved either through sub-
goal Classic Communication Handled dealing with phone and fax orders or
Internet Handled managing secure or standard form orderings. To allow for the
ordering of new items not listed in the catalogue, Select Item is also further
refined into two alternative subtasks, one dedicated to the selection of catalogued
items, the other to back-ordering unavailable products. To provide sufficient
support (++) to the Adaptable softgoal, Adaptation is refined into four subtasks
dealing with catalogue updates, system evolution, interface updates, and system
monitoring. The goal Item Searching Handled might alternatively be fulfilled
through the tasks Database Querying or Catalogue Consulting with respect
to customers’ navigating desiderata, that is, searching with particular items in
mind by using search functions or simply browsing the catalogued products.
In addition, as already pointed out, Figure 5 introduces softgoal contributions to
model sufficient/partial positive (respectively ++ and +) or negative (respectively
— and -) support to softgoals Secure, Available, Adaptable, Attract New
Customers, and Increase Market Share. The result of this means-ends analysis
is a set of (system and human) actors who are dependees for some of the
dependencies that have been postulated.
Resource, task and softgoal dependencies correspond naturally to functional and
non-functional requirements. Leaving (some) goal dependencies between sys-
tem actors and other actors is a novelty. Traditionally, functional goals are
“operationalized” during late requirements (Dardenne, van Lamsweerde, &
Fickas, 1993), while quality softgoals are either operationalized or “metricized”
(Davis, 1993). For example, Billing Processor may be operationalized during
late requirements analysis into particular business processes for processing bills
and orders. Likewise, a security softgoal might be operationalized by defining
interfaces that minimize input/output between the system and its environment, or
by limiting access to sensitive information. Alternatively, the security require-
ment may be metricized into something like “No more than X unauthorized
operations in the system-to-be per year.”
TEAM LinG
Figure 5. Rationale diagram for Medi@
Media
Telecom Process Shop
Internet Process
Cpy On-line
Orders Money
Transactions
++
Bank
Internet Availability Cpy
Services Increase
Market Share Security
Adaptability
++
Customer
Update Produce Internet
Catalogue Statistics Shop Attract New
Managed Customer
Adaptabl e
Browse
++ Catalogue
Internet Item Available
Orders Searching
Adaptation Handled Handled
- Keyword
Secure Search
-
+
System Monitoring
Evolution System + -
Database Catalogue
Querying Consulting Place
Order
+ +
Buy
Update GUI Shopping Secure Media
Cart Form Items
Get Order
Identification
Detail -
Select Item Standard

Add Item Form
Check Out Order
Pick Pre-Order Classic Internet

Available Non Available Communication
Handled Handled
Item Item
Phone Fax
Order Order
Medi@
Find User Media

New Needs Supplier
TEAM LinG
Leaving goal dependencies with system actors as dependees makes sense

whenever there is a foreseeable need for flexibility in the performance of a task
on the part of the system. For example, consider a communication goal
“communicate X to Y.” According to conventional development techniques,
such a goal needs to be operationalized before the end of late requirements
analysis, perhaps into some sort of a user interface through which user Y will
receive message X from the system. The problem with this approach is that the
steps through which this goal is to be fulfilled (along with a host of background
assumptions) are frozen into the requirements of the system-to-be. This early
translation of goals into concrete plans for their fulfillment makes systems fragile
and less reusable.
In our example, we have left three (soft)goals (Availability, Security, Adapt-
ability) in the late requirements model. The first goal is Availability because we
propose to allow system agents to automatically decide at run-time which
catalogue browser, shopping cart, and order processor architecture best fit
customer needs or navigator/platform specifications. Moreover, we would like
to include different search engines, reflecting different search techniques, and
let the system dynamically choose the most appropriate. The second key softgoal
in the late requirements specification is Security. To fulfill this, we propose to
support a number of security strategies in the system’s architecture and let the
system decide at run-time which one is the most appropriate, taking into account
environment configurations, Web browser specifications, and network protocols
used. The third goal is Adaptability, meaning that catalogue content, database
schema, and architectural model can be dynamically extended or modified to
integrate new and future Web-related technologies.
Figure 6 suggests a possible assignment of system responsibilities for Medi@
following the Structure-in-5 style (Do, Faulkner, & Kolp, 2003). It is decom-
posed into five principal actors Store Front, Coordinator, Billing Processor,
Back Store, and Decision Maker. Store Front serves as the Operational
Core. It interacts primarily with Customer and provides him/her with a usable
front-end Web application for consulting and shopping media items. Back Store
constitutes the Support component. It manages the product database and
communicates to the Store Front information on products selected by the user.
It stores and backs up all Web information from the Store Front about
customers, products, sales, orders, and bills to produce statistical information
to the Coordinator. It provides the Decision Maker with strategic informa-
tion (analyses, historical charts, and sales reports).
TEAM LinG
Figure 6. The Medi@ architecture in Structure-in-5
Decision
Maker
Financial Adaptability Authority & Security Strategic

Transaction Management Strategic Management Information
Decision
Billing Handle
Orders & Statistical Back Store
Processor Coordinator Information
Billing
Coordinate Manage
Catalogue
E−Shopping
Browsing
Update &
Back−up
Billing Information
Product
Orders Information
Store Front
The Billing Processor is in charge of handling orders and bills for the
Coordinator and implementing the corresponding procedures for the Store
Front. It also ensures the secure management of financial transactions for the
Decision Maker. As the Middle Line, the Coordinator assumes the central
position of the architecture. It ensures the coordination of e-shopping services
provided by the Operational Core, including the management of conflicts
between itself, the Billing Processor, the Back Store, and the Store Front. To
this end, it also handles and implements strategies to manage and prevent
security gaps and adaptability issues. The Decision Maker assumes the
Strategic Apex role. To this end, it defines the Strategic Behavior of the
architecture, ensuring that objectives and responsibilities delegated to the Billing
Processor, Coordinator, and Back Store are consistent with that global
functionality.
TEAM LinG
Three software quality attributes have been identified as being particularly

strategic for e-business systems (Do, Faulkner, & Kolp, 2003):
1. Adaptability deals with the way the system can be designed using generic
mechanisms to allow web pages to be dynamically changed. It also
concerns the catalogue update for inventory consistency.
The structure-in-5 separates independently each typical component of the

Medi@ architecture isolating them from each other and allowing dynamic
manipulation.
2. Security. Clients, exposed to the Internet are, like servers, at risk in Web
applications. It is possible for Web browsers and application servers to
download or upload content and programs that could open up the client
system to crackers and automated agents. JavaScript, Java applets,
ActiveX controls, and plug-ins represent a certain risk to the system and the
information it manages. Equally important are the procedures checking the
consistency of data transactions.
In the structure-in-5, checks and control mechanisms can be integrated at

different levels assuming redundancy from different perspectives. Contrary to
the classical layered architecture (Shaw & Garlan, 1996), checks and controls
are not restricted to adjacent levels. In addition, since the structure-in-5 permits
the separation of process (Store Front, Billing Processor, and Back Store)
from control (Decision Maker and Monitor), security and consistency of these
two hierarchies can also be verified independently.
3. Availability. Network communication may not be very reliable, causing

sporadic loss of the server. There are data integrity concerns with the
capability of the e-business system to do what needs to be done as quickly
and efficiently as possible, in particular the ability of the system to respond
in time to client requests for its services.
The structure-in-5 architecture prevents availability problems by differentiating

process from control. Also, contrary to the classical layered architecture (Shaw
& Garlan 1996), higher levels are more abstract than lower levels; lower levels
only involve resources and task dependencies while higher ones propose
intentional (goals and softgoals) relationships.
TEAM LinG
Detailed Design
Figure 7 shows a possible use of the patterns for the Store Front component of
the e-business system of Figure 6. In particular, it shows how to realize the
dependencies Manage Catalogue Browsing, Update Information, and Prod-
uct Information from the point of view of the Store Front. The Store Front and
the dependencies are decomposed into a combination of social patterns (Do,
Kolp, & Pirotte, 2003) involving agents, pattern agents, subgoals, and subtasks.
The booking pattern is applied between the Shopping Cart and the Information
Broker to reserve available items. The broker pattern is applied to the Informa-
tion Broker, which satisfies the Shopping Cart’s requests of information by
accessing the Product Database. The Source Matchmaker applies the
matchmaker pattern to locate the appropriate source for the Information
Broker, and the monitor pattern is used to check any possible change in the
Product Database. Finally, the mediator pattern is applied to dispatch the
interactions between the Information Broker, the Source Matchmaker, and
the Wrapper, while the wrapper pattern forms the interaction between the
Information Broker and the Product Database.
Figure 8 shows the remote administrative tool for the information broker of
Figure 7. The customer sends a service request to the broker requesting the
buying or selling of DVDs. He/she chooses which DVDs to sell or buy, selects
the corresponding DVD titles, the quantity, and the deadline (the time-out before
which the broker has to realize the requested service). When receiving the
customer’s request, the broker interacts with the Media Shops. The interactions
between the Broker and the Media Shops are shown in the bottom-right corner
of the figure.
Figure 7. Decomposing the Store Front with social patterns
Shopping
Cart
Handle Provide
Cancelation Item
Request Data
Monitor Notify
Info Update
Broker Fwd Source
Change
Advertise
Source
Location Translate
Profile Query
Customer Response
Locate Mediator Information Product
Source Wrapper
Source Database
Provide
Information
Ask for
Source Route Info
Info
Matchm. Request Advertising
TEAM LinG
Figure 8. The Information Broker of Medi@
To go deeper into the details, the rest of the section only concentrates on the
Store Front actor. Figure 9 depicts a partial, extended UML class diagram
(Castro, Kolp, & Mylopoulos, 2002) focusing on the actor that will be imple-
mented as an aggregation of several CartForms and ItemLines.
To specify the checkout operation identified in Figure 9, extensions of interac-
tion diagrams (Castro et al., 2002) allow us to use templates and packages to
represent checkout as an object, but also in terms of sequence and collaborations
diagrams.
Figure 10 focuses on the protocol between Customer and Shopping Cart that
consists of a customization of the FIPA Contract Net protocol (Odell, Van Dyke
Parunak, & Bauer, 2000). Such a protocol describes a communication pattern
among actors, as well as constraints on the contents of the messages they
exchange. When a Customer wants to check out, a request-for-proposal
message is sent to Shopping Cart, which must respond before a given time-out
(for network security and integrity reasons). The response may refuse to provide
a proposal, submit a proposal, or express miscomprehension. The diamond
symbol with an “X” indicates an “exclusive or” decision. If a proposal is offered,
Customer has a choice of either accepting or cancelling the proposal.
TEAM LinG
Figure 9. Partial class diagram for Store Front
«i* actor»
«i* actor»
CartForm ShoppingCart
CustomerProfiler «i* actor»
«Text» itemCount : integer itemCount : integer
«Text» qty[0..*] : integer tax : currency On−line
«Text» currentTotal : currency taxRate : float Catalogue
«Checkbox» selectItem[0..*] total : currency
0..* totWeight : single
«Submit» Checkout shippingCost : currency
«Submit» AddItem qty[0..*] : integer 0..*
CustomerProfileCard
«Submit» Confirm subTotals[0..*] : currency
«Button» Cancel MediaItem
customerid : long itemCount() notification()
customerName : string «Button»Recalculate calculateTotals() id : long
firstName :string calculateQty() itemNbr : string
getCart() computeWeight()
middleName : string itemTitle : string
buildItemTable() getLineItem() inform()
address : string itemBarCode : OLE
writeTableRow() initializeReport()
tel : string itemPicture : OLE
updateItems() Plans:
e−mail : string category :string
loadCartForm() initialize refuse
dob : date genre : string
updateCartForm() selectItem propose
profession : string addItem succeded description : string
killCartForm()
salary : integer checkout removeItem editor : string
maritalStatus : string 0..* confirm
cancel publisher : string
familyComp[0..1] : integer CustomerData logout failure
date : date
internetPref[0..10] : boolean 1 0..* verifyCC unitPrice : currency
ItemLine not_understood weight : single
entertPref[0..10]:string
0..* 1 getIdentDetails
hobbies[0..5] : string
id : long
comments : string 0..* ItemDetail 1
qty : integer
creditcard# : integer
allowsSubs :boolean
prevPurchase[[0..*] [0..*]]
: string weight() DVD Book Video ... CD CDrom
prevPurchPrice[[0..*] [0..*]] cost()
: integer
Figure 10. Agent interaction protocol focusing on a checkout dialogue
<<i* actor>> <<i* actor>>

Customer Shopping Cart
checkout−request for proposal

Timeout
12/19/00
9:31 53
refuse
FIPA Contract Net Protocol

not−understood Notification
X
Customer, Shopping Cart
propose 12/19/00 at 9:31 53
checkout−rfp, refuse, not−understood,
propose, cancel−proposal
cancel−proposal accept−proposal, succeeded, failure
Decision
X
accept−proposal
succeeded
inform
X
failure
Plan Diagram (See Figure 11)
TEAM LinG
At the lowest level, we use plan diagrams (Kinny & Georgeff, 1996) to specify
the internal processing of atomic actors. Each identified plan is specified as a
plan diagram, which is denoted by a rectangular box. The lower section, the plan
graph, is a state transition diagram. However, plan graphs are not just descrip-
tions of system behavior developed during design. Rather, they are directly
executable prescriptions of how a BDI agent should behave (execute identified
plans) in order to achieve a goal or respond to an event.
The initial transition of the plan diagram is labelled with an activation event
(Press checkout button) and activation condition ([checkout button acti-
vated]), which determine when and in what context the plan should be activated.
Transitions from a state automatically occur when exiting the state and no event
is associated (e.g., when exiting Fields Checking) or when the associated event
occurs (e.g., Press cancel button), provided in all cases that the associated
condition is true (e.g., [Mandatory fields filled]). When the transition occurs,
any associated action is performed (e.g., verifyCC()).
The elements of the plan graph are three types of node: start states, end states,
and internal states; and one type of directed edge: transitions. Start states are
denoted by small filled circles. End states may be pass or fail states, denoted
respectively by a small target or a small no entry sign. Internal states may be
passive or active. Passive states have no substructure and are denoted by a small
open circle. Active states have an associated activity and are denoted by
rectangular boxes with rounded corners. An important feature of plan diagrams
is their notion of failure. Failure can occur when an action upon a transition fails,
when an explicit transition to a fail state occurs, or when the activity of an active
state terminates in failure and no outgoing transition is enabled.
Figure 11 depicts the plan diagram for Checkout, triggered by pushing the
checkout button. Mandatory fields are first checked. If any mandatory fields are
not filled, an iteration allows the customer to update them. For security reasons,
the loop exits after five tries ([I<5]) and causes the plan to fail. Credit card
validity is then checked. Again for security reasons, when not valid, the CC# can
only be corrected three times. Otherwise, the plan terminates in failure. The
customer is then asked to confirm the CC# to allow item registration. If the CC#
is not confirmed, the plan fails. Otherwise, the plan continues: each item is
iteratively registered, final amounts are calculated, stock records and customer
profiles are updated, and a report is displayed. When finally the whole plan
succeeds, the Shopping Cart automatically logs out and asks the Order
Processor to initialize the order. When, for any reason, the plan fails, the
Shopping Cart automatically logs out. At anytime, if the cancel button is pressed
or the time-out is more than 90 seconds (e.g., due to a network bottleneck), the
plan fails and the Shopping Cart is reinitialized.
TEAM LinG
Figure 11. A plan diagram for Checkout
Checkout
Press checkout button [checkout button activated] / shoppingCart.checkout()
[Mandatory fields filled]

/verifyCC() [CC# valid] Press confirm button
Fields Credit Card / confirm()? /confirm() Item
Checking Checking Registering
[Not confirmed]
[i=5] / cancel() Items
[foreach Registered
[[CC# not valid] [i=3] selected item]
[[Not all mandatory
^ [i<3]]
fields filled] ^ [i<5]]
Fields Updated Updated
Fields CC# Stock Records Final Amounts

Updating Correcting Updating Calculating
[foreach
registered item] Records updated Amounts
succeeded / shoppingcart.logout() calculated
[new customer]
Displaying Customer Profile
succeeded Report profile Updating
[report asked]
/ shoppingCart.logout() / initializeReport() updated [Already registered]
pass / orderProcessor. fail /shoppingCart.logout() any [[Cancel button pressed] OR
processOrder(this) [timeout>90 sec]] / shoppingCart.initialize()
Conclusions
We have proposed a development methodology named Tropos, founded on

intentional and social concepts and inspired by early requirements analysis. The
modeling framework views software from five complementary perspectives:
• Social: Who are the relevant actors? What do they want? What are their
obligations? What are their capabilities?
• Intentional: Relevant goals and how they interact. How are they being
fulfilled and by whom?
• Communicational: How do actors communicate with each other?
• Process-oriented: What are the relevant business/computer processes?
Who is responsible for what?
• Object-oriented: What are the relevant objects and classes and their inter-
relationships?
We believe that the methodology is particularly appropriate for generic, compo-

nent-based systems for e-business applications that can be downloaded and used
TEAM LinG
in a variety of operating environments and computing platforms. The require-

ments-driven approach, on which Tropos is based, suggests that the methodology
complements well the proposals for agent-oriented programming environments
(Castro et al., 2002; Perini, Bresciani, Giunchiglia, Giorgini, & Mylopoulos, 2001),
given that the software is defined in terms of (system) actors, goals, and social
dependencies among them. Moreover, it does not force the developer to
operationalize these intentional and social structures early in the development
process, thereby avoiding the hardwiring of solutions into software requirements.
The Tropos methodology is not intended for any type of software. For system
software (such as a compiler) or embedded software, the operating environment
of the system-to-be is an engineering artifact, with no identifiable stakeholders.
In such cases, traditional software development techniques may be most
appropriate. However, a large and growing percentage of software does operate
within open, dynamic organizational environments. For such software, the
Tropos methodology and others in the same family apply and promise to deliver
more robust, reliable, and usable software systems. The Tropos methodology in
its current form is also not suitable for sophisticated software agents requiring
advanced reasoning mechanisms for plans, goals, and negotiations. Further
extensions will be required, mostly at the detailed design phase, to address this
class of software applications.
Much remains to be done to further refine the proposal and validate its usefulness
with very large case studies. We are currently working on the development of
additional formal analysis techniques for Tropos, including goal analysis and
social structures engineering. We are also developing tools that support different
phases of the methodology.
Acknowledgments
We thank all contributors to the Tropos project —in Trento, Toronto, Louvain-
la-Neuve, Recife and elsewhere—for useful comments, discussions, and feed-
back.
References
Aridor, Y. & Lange, D. (1998). Agent design patterns: Elements of agent
application design. Proceedings of the 2nd International Conference on
TEAM LinG
Autonomous Agents, Agents’98, St. Paul, Minnesota, May 9-13 (pp. 108-
115). New York: ACM Press.
Bauer, B., Muller, J., & Odell, J. (2001). Agent UML: A formalism for specifying
multiagent interaction. Proceedings of the 1st International Workshop
on Agent-Oriented Software Engineering, AOSE’00, Limerick, Ireland,
June 10, 2000 (pp. 91-104). Springer.
Booch, G., Rumbaugh, J., & Jacobson, I. (1999). The unified modeling
language: User guide. Reading, MA: Addison-Wesley.
tems, 27(6), 365-389.
Chung, L., Nixon, B., Yu, E., & Mylopoulos, J. (2000). Non-functional
requirements in software engineering. Norwell, MA: Kluwer Publishing.
Cohen, P. & Levesque, H. (1990). Intention is choice with commitment.
Artificial Intelligence, 32(3), 213-261.
Conallen, J. (2000). Building Web applications with UML. Reading, MA:
Addison-Wesley.
Dardenne, A., van Lamsweerde, A., & Fickas, S. (1993). Goal-directed require-
ments acquisition. Science of Computer Programming, 20(1-2), 3-50.
Davis, A. (1993). Software requirements: Objects, functions and states.
Upper Saddle River, NJ: Prentice Hall.
DeMarco, T. (1978). Structured analysis and system specification. Englewood
Cliffs, NJ: Yourdon Press.
Do, T. T., Faulkner, S., & Kolp, M. (2003). Organizational multi-agent architec-
tures for information systems. In Proceedings of the 5th International
Conference on Enterprise Information Systems, ICEIS’03, Angers,
France, April 22-26 (pp. 89-96). EST Setubal.
Do, T. T., Kolp, M. & Pirotte, A. (2003). Social patterns for designing multi-
agent systems. In Proceedings of the 15th International Conference on
Software Engineering and Knowledge Engineering, SEKE’03, San
Francisco, July 1-3 (pp. 103-110). Knowledge System Institute.
Finin, T., Labrou, Y., & Mayfield, J. (1997). KQML as an agent communication
language. In J. Bradshaw (Ed.), Software agents (pp. 291-317). Cam-
bridge, MA: MIT Press.
Gamma, E., Helm, R., Johnson, J., & Vlissides, J. (1995). Design patterns:
Elements of reusable object-oriented software. Reading, MA: Addison-
Wesley.
Giorgini, P., Mylopoulos, J., Nicchiarelli, E., & Sebastiani, R. (2002). Reasoning
with goal models. Proceedings of the 21st International Conference on
TEAM LinG
Conceptual Modeling, ER 2002, Tampere, Finland, October 7-11 (pp.

167-181). Springer.
Hayden, S., Carrick, C., & Yang, Q. (1999). Architectural design patterns for
multiagent coordination. Proceedings of the 3rd International Confer-
ence on Autonomous Agents, Agents’99, Seattle, May 1-5 (pp. 112-113).
ACM Press.
Kinny, D. & Georgeff, M. (1996). Modelling and design of multi-agent systems.
In Proceedings of the 3rd International Workshop on Intelligent
Agents: Agent Theories, Architectures, and Languages, ATAL’96,
Budapest, Hungary (pp. 1-20).
Kolp, M., Giorgini, P., & Mylopoulos, J. (2001). A goal-based organizational
perspective on multi-agents architectures. Proceedings of the 8th Inter-
national Workshop on Intelligent Agents: Agent Theories, Architec-
tures, and Languages, ATAL’01, Seattle, August 1-3 (pp. 128-140).
Springer.
Kolp, M., Giorgini, P., & Mylopoulos, J. (2002). Organizational multi-agent
architectures: A mobile robot example. Proceedings of the 1st Interna-
tional Conference on Autonomous Agents and Multi-Agent Systems,
AAMAS’02, Bologna, Italy.
Kolp, M., Giorgini, P., & Mylopoulos, J. (2003). Organizational patterns for early
requirements analysis. Proceedings of the 15th International Confer-
ence on Advanced Information Systems, CAiSE’03, Velden, Austria,
June 16-18 (pp. 617-632). Springer.
Kruchten, P. (2003). The rational unified process: An introduction. Reading,
MA: Addison-Wesley.
Labrou, Y., Finin, T., & Peng, Y. (1999). The current landscape of agent
communication languages. Intelligent Systems, 14(2), 45-52.
Mintzberg, H. (1992). Structure in fives: Designing effective organizations.
Upper Saddle River, NJ: Prentice-Hall.
Morabito, J., Sack, I., & Bhate, A. (1999). Organization modeling: Innovative
architectures for the 21st century. Upper Saddle River, NJ: Prentice
Hall.
Mylopoulos, J., Kolp, M., & Castro, J. (2001). UML for agent-oriented software
development: The Tropos proposal. Proceedings of the 4th International
Conference on the Unified Modeling Language, UML’01, Toronto,
Canada, October 1-5 (pp. 422-442). Springer.
agents. Proceedings of the 2nd International Bi-Conference Work-
TEAM LinG
shop on Agent-Oriented Information Systems, AOIS’00, Austin, TX,

June 10 (pp. 121-140). Springer.
Object Management Group (OMG) (1999). OMG unified modeling specifica-
tion. Available online http://www.omg.org
Perini, A., Bresciani, P., Giunchiglia, F., Giorgini, P., & Mylopoulos, J. (2001).
A knowledge level software engineering methodology for agent-oriented
programming. Proceedings of the 5th International Conference on
Autonomous Agents, Agents’01, Montreal, Canada, May 28-June 1 (pp.
648-655). Springer.
Scott, W. (1998). Organizations: Rational, natural, and open systems. Upper
Saddle River, NJ: Prentice Hall.
Shaw, M. & Garlan, D. (1996). Software architecture: Perspectives on an
emerging discipline. Upper Saddle River, NJ: Prentice Hall.
Wirfs-Brock, R., Wilkerson, B., & Wiener L. (1990). Designing object-
oriented software. Upper Saddle River, NJ: Prentice Hall.
Yourdon, E. & Constantine, L. (1979). Structured design: Fundamentals of a
discipline of computer program and systems design. Upper Saddle
River, NJ: Prentice Hall.
Yu, E. (1993). Modeling organizations for information systems requirements
engineering. Proceedings of the 1st International Symposium on Re-
quirements Engineering, RE’93, San Jose, CA, January 4-6 (pp. 34-41),
IEEE Computer Society.
Yu, E. (1994). Understanding “why” in software process modeling, analysis and
design. Proceedings of the 16th International Conference on Software
Engineering, ICSE’94, Sorrento, Italy, May 16-21 (pp. 159-168). IEEE
Computer Society.
Yu, E. (1995). Modelling strategic relationships for process reengineering.
PhD thesis, University of Toronto, Department of Computer Science.
Yu, E. & Mylopoulos, J. (1996). Using goals, rules, and methods to support
reasoning in business process reengineering. International Journal of
Intelligent Systems in Accounting, Finance and Management, 5(1), 1-
13.
TEAM LinG
46 Iglesias & Garijo
Chapter III
The Agent-Oriented
Methodology
MAS-CommonKADS
Carlos A. Iglesias
Technical University of Madrid, Spain
Mercedes Garijo
Technical University of Madrid, Spain
Abstract
This chapter introduces the main concepts of the methodology MAS-

CommonKADS that extends object-oriented and knowledge engineering
techniques for the conceptualisation of multi-agent systems. MAS-
CommonKADS defines a set of models (Agent Model, Task Model, Expertise
Model, Coordination Model, Communication Model, Organisation Model,
and Design Model) that together provide a model of the problem to be
solved. Each of the components of the model is a generic component for the
sake of reusability. Readers familiar with object-oriented analysis will find
it easy to apply most of the techniques of MAS-CommonKADS in the
development of multi-agent systems and will be introduced to the application
of knowledge engineering techniques for specifying the knowledge of the
agents.
TEAM LinG
The Agent-Oriented Methodology MAS-CommonKADS 47
Introduction
MAS-CommonKADS is an agent-oriented software engineering methodology
that guides the process of analysing and designing multi-agent systems. MAS-
CommonKADS distinguishes several development phases: conceptualisation,
where the system is conceived as a multi-agent system and where agent
properties of the system are identified; analysis, where different models are
developed in order to analyse the system from different points of view; design,
where the different models are operationally focussed; and development and
testing, which are not addressed explicitly in the methodology.
MAS-CommonKADS (Iglesias, 1998; Iglesias, Garijo, González, & Velasco,
1998) can be used in combination with other methodologies. For example, some
of its conceptualisation techniques, such as Class-Responsibility-Collabora-
tion (CRC) cards (Beck & Cunningham, 1989; Wirfs-Brock, Wilkerson, &
Wiener; 1990) and User-Environment-Responsibility (UER) techniques
(Iglesias & Garijo, 1999) can be used for conceiving a system from an agent
point-of-view and be combined with other methodologies such as Rational
Unified Process (RUP) (Kruchten, 2000) or eXtreme Programming (XP)
(Beck, 1999); or use another agent-oriented methodology. In the same way,
every analysis model can be used in combination with another methodology.
MAS-CommonKADS has as one of its goals to be usable by professionals who
want to include in their projects this new and exciting computation paradigm—
agents. In this way, MAS-CommonKADS extends well-known modelling tech-
niques, such as CRC cards, use cases, Message Sequence Charts (MSC)
(ITU-Z.120, 1996) or Specification and Description Language (SDL) (ITU-
T-Z.100, 1994) diagrams, with new perspectives driven by the agent metaphor.
This makes many of MAS-CommonKADS techniques easy to learn and
practice. The recent addition of MSC and SDL diagrams to Unified Modelling
Language (UML) (Salic, 2004) makes MAS-CommonKADS even easier to
practice with standard object-oriented CASE tools that can be enhanced with
stereotypes for some of the new modelling entities (for example, software actor
or environment).
The MAS-CommonKADS Methodology

The origins of MAS-CommonKADS come from CommonKADS (Schreiber et
al., 1999), a well-known knowledge engineering methodology, and from object-
oriented methodologies such as Object Modelling Technique (OMT)
TEAM LinG
(Rumbaugh, Blaha, Premerlani, & Eddy, 1991), Object-oriented Software

Engineering (OOSE) (Jacobson, Christerson, Jonsson, & Övergaard, 1992) and
Responsibility Driven Design (RRD) (Wirfs-Brock, Wilkerson, & Wiener;
1990). In addition, it includes techniques from protocol engineering such as SDL
and MSC. All these techniques are combined in order to provide support to agent
developers.
MAS-CommonKADS is based on the models of CommonKADS extended and
adapted to agent modelling, including the definition of a new model, the
coordination model, for describing agent interactions.
The software development life cycle in MAS-CommonKADS follows the
phases described below:
• Conceptualisation. Elicitation task in order to obtain a first description of

the problem through the definition of a set of use cases that help to
understand the system and how to test it.
• Analysis. The analysis phase determines the functional requirements of
the system. It describes the system through the development of a set of
models.
• Design. The design phase combines a top-down and bottom-up approach,
reusing developed components and developing new ones, depending on the
targeted agent platform. The design phase takes as an input the analysis
models, which are then operationalised, that is, transformed into specifica-
tions (the design model) ready to be implemented. The internal architecture
of every agent and the “network architecture” of the system are deter-
mined.
• Development and testing. Coding and testing tasks of the previously
defined agents.
• Operation. Maintenance and operation of the system.
The methodology defines the following models (Figure 1):
• Agent model that specifies the agent characteristics: reasoning capabili-

ties, skills (sensors/effectors), services, agent groups, and hierarchies (both
modelled in the organisation model).
• Task model that describes the tasks that the agents can carry out: goals,
decompositions, ingredients, problem-solving methods, and so forth.
• Expertise model that describes the knowledge needed by the agents to
achieve their goals.
TEAM LinG
• Organisation model that describes the organisation into which the MAS
is going to be introduced and the social organisation of the agent society.
• Coordination model that describes the conversations between agents,
their interactions, protocols, and required capabilities.
• Communication model that details the human-software agent interac-
tions and the human factors for developing these user interfaces. This
model uses standard techniques for developing user interfaces and, conse-
quently, it is will not discussed in this chapter.
• Design model that collects the previous models and consists of three
submodels: network design, for designing the relevant aspects of the agent
network infrastructure (required network, knowledge and telematic facili-
ties); agent design, for dividing or composing the agents of the analysis,
according to pragmatic criteria and selecting the most suitable agent
architecture for each agent; and platform design, for selecting the agent
development platform for each agent architecture.
Figure 1. Models of MAS-CommonKADS
TEAM LinG
Conceptualisation
The problem of conceptualisation is the first step towards the identification of the
functional requirements of a system. One of the most extended techniques for
getting a first idea of the system is the Use Case technique. The technique
consists in identifying the possible users of the systems and the possible user
goals, describing ways of achieving these user goals. These textual descriptions
are the use cases. Usually, different use cases can be combined with the
relationships extend (if a use case is an extension of another one) or include (if
a use case is a part of another one). This technique is very simple and intuitive
and has been very successful for requirements elicitation and validation.
The use case technique can also be used for conceptualising a multi-agent
system. Nevertheless, autonomous agents are distinguished because they do not
need a user that supervises their execution. So, while with use cases we have to
answer the question, How is my system used?, we could ask ourselves about
other requirements of our system such as: When and how does my system act
and react to the environment? (environment cases) and What are the goals of the
system? (responsibility or goal cases).
In order to conceptualise an agent-based system, two general techniques are
used in MAS-CommonKADS: the UER cases technique that deals with the
identification of use, reaction, and goal cases of an agent or a multi-agent system,
and the enhanced Class-Collaboration-Responsibility Cards technique that deals
with the identification of responsibilities, plans, and collaborations of an agent.
Both techniques are complementary. The UER technique can be used for both
single-agent or multi-agent systems (for identifying use, reactive, and goal cases
of the whole system). The enhanced CRC cards can only be used for concep-
tualising multi-agent systems, since they guide the definition of collaborative
scenarios.
UER Technique
The User-Environment-Responsibility (UER) technique (Iglesias & Garijo,
1999) combines user, environment and responsibility-driven analysis for concep-
tualising a system from an agent-oriented perspective. This technique can be
used for conceptualising a particular autonomous agent or the general require-
ments of a multi-agent system. The technique analyses the system from three
complementary perspectives: the user perspective, the environment perspective,
and the assigned responsibility perspective.
TEAM LinG
• User-Centred Analysis. The potential users (called actors) of the system

are identified, together with their possible tasks or functions. The result of
this analysis is the set of use cases. This analysis answers the question:
What are the possible uses of the multi-agent system?
• Environment-Centred Analysis. Agents can be situated in an environ-
ment, and this environment needs to be modelled. In particular, we are
interested in modelling how the system can act and react to this environ-
ment. The result of this analysis is the set of reaction cases. This analysis
answers the question: How has the multi-agent system reacted to the
environment?
• Responsibility-Driven Analysis. In contrast to usual software systems,
multi-agent systems can act proactively. The user can desire that the
system has some responsibilities, that is, the user can assign some goals or
responsibilities to the system and the system carries out these responsibili-
ties without a direct demand. This analysis answers the question: What are
the goals of the system? The main difference of goal cases from the use
cases is that the use cases show how the system gives an answer to a user
request, while the goal cases show how the system behaves when some
condition is fulfilled.
The application of the UER technique introduces some of the most relevant
properties of an agent system, such as reactivity and proactiveness in the
conceptualisation of the system.
User-Centred Analysis
A use case describes the possible interactions or uses of a system by a user.

System users are called actors and represent external entities of the system. Use
cases can be combined, pointing out if a use case extends or includes a previous
use case.
User-Centred Analysis consists of the following steps:
• Identify the Actors. It is especially relevant to identify the roles played

by the actors. Each role is considered a different actor. There are two
general kinds of actors: human actors (round head) and software actors
(square head).
• Identify the Use Cases. This process can be carried out by answering the
following questions:
TEAM LinG
o What are the main tasks or functions carried out by each actor?
o What system information is acquired, produced or changed by each
actor?
o Does any actor inform about external changes in the system environ-
ment?
o What information is needed by each system actor?
o Does any actor need to be informed about unexpected changes?
• Group the use cases if they are variations of the same subject (for example,
‘move a heavy stone’ and ‘move a light stone’).
• Determine the interactions of each identified use case.
• Describe the use cases using both a graphical notation and textual tem-
plates.
• Consider every possible exception that can happen during the interactions
and how each affects the use cases.
• Look for relationships among the use cases: extract common parts and note
if a use case adds the interactions of another use case (relationship
“include”) or adds information contained in another use case (relationship
“extends” or “include”).
• Describe the interactions of each scenario, using Message Sequence
Chart (MSC) notation. MSC has been selected because is a standardised,
formal description technique with a textual and graphical grammar. Some
of the relevant features for our purposes are the availability of a language
(High-level MSC, HMSC) for defining the phases of the interaction, and
the definition of operators for expressing alternatives, exceptions, and
concurrence in the same diagram. Although sequence and collaboration
diagrams do not allow the expression of these issues in such an easy way,
they can also be used.
Environment-Centred Analysis
The goal of environment-centred analysis is to identify the relevant objects of the

environment and the possible actions and reactions of the agent. This will be used
later for agent sensor modelling.
Environment-Centred Analysis consists of the following steps:
• Identify objects of the environment. These objects are shown in the use
case diagram as clouds.
TEAM LinG
• Identify the possible events coming from each object and establish a
hierarchy if possible.
• Identify the possible actions each agent can carry out on the environment
objects.
• Describe (in natural language) the reaction cases coming from interaction
with the environment. Describe in detail each possible scenario. Assess if
there are several scenarios arising from the same reaction case and
whether every scenario is autonomous (it is only managed by the agent that
receives the stimuli) or cooperative (it is managed in cooperation with other
agents).
• Group-related reactive cases with the relationships “extends” or “in-
cludes.” For example, “avoid obstacle” can group different scenarios for
avoiding an obstacle depending on its nature and can be avoided in an
autonomous way (e.g., just going to the left of the obstacle) or in a
cooperative way (e.g., asking for help to move it).
• Describe the reactive goal: its name, the activation condition (e.g., a wall
very close), the deactivation condition, and the success and failure condi-
tion (whether the reaction has been effective or not).
Responsibility-Driven Analysis
Responsibility- or goal-driven analysis deals with the definition of the require-

ments of the system that should be fulfilled without the direct interaction with the
user.
Goal-Driven Analysis consists of the following steps:
• Identify responsibilities (goals) of the system that require some action.

Some hints for identifying these goals are:
o Look for non-functional requirements, such as time requirements
(e.g., ‘Give an answer within five minutes’) or security requirements
(e.g., ‘Buy a product in a secure way’). Sometimes the agent needs
to carry out special actions to achieve these goals.
o Describe when some internal variable of the agent can reach an
undesirable value and what action should be carried out (e.g., high/
low temperature or too many processes).
o Describe undesired states, possible failures of the system that should
require action to be avoided.
TEAM LinG
• Describe the proactive goal: its name, its type (persistent, priority, etc.), the
activation condition (e.g., no fuel or idle), the deactivation condition and the
success and failure condition (whether the plan has been effective or not).
• Group related goals using the relationships “extends” or “includes.”
Enhanced CRC Cards and Internal Use Cases
The well-known Class Responsibility Collaboration (CRC) cards technique

(Beck & Cunningham, 1989; Wirfs-Brock, Wilkerson & Wiener; 1990) provides
a method for organising the relevant classes for modelling a system. This
technique was initially used for teaching object fundamentals in a collaborative
environment. The technique consists of filling in cards. Each card has a class
name and two columns. The left column shows the responsibilities of the class,
namely, the tasks the class can perform or knowledge it has, and the right column
show the classes that collaborate to achieve these tasks or obtain this knowledge.
This technique can be easily modified from an agent perspective. A CRC is filled
for each agent class. Each CRC is divided into five columns (Figure 2): goals
assigned, plans for achieving these goals, knowledge needed to carry out the
plans, collaborators in these plans, and services used in the collaboration. The
back side of the CRC is used for annotations or extended description of the front
side.
During this stage the knowledge is collected in an informal way. Later, in the
analysis phase, it will be specified which role the agent plays in the task,
knowledge, coordination, and communication models.
Internal use cases are also based on RDD and its CRC cards. Taking as input
the use cases of the conceptualisation phase and some initial agents, we can think
Figure 2. Enhanced CRC cards

Agent:
Goals Plans Knowledge Collaborator Service
Figure 3. User-environment-responsibility notation
Reactive Goal
Use Case
Case Case
Environment
Software Human
Agent Agent
TEAM LinG
that each agent “uses” other agent(s) and can use these agents with different
roles. In Figure 3, the use case notation is extended for showing human agents
(with the round head) and software agents (with the square head). We try to
reuse such an agent from our agent library, combining in this way the top-down
and bottom-up approach. The external use cases coming from the actors of the
multi-agent system are decomposed in use cases that are assigned to agent roles
of the system.
Analysis
The results of this phase will be the requirements specification of the MAS
through the development of the models previously described, except for the
design model. These models are developed in a risk-driven way, and the steps
are:
• Agent Modelling: developing initial instances of the agent model for

identifying and describing the agents.
• Task Modelling: task decomposition and determination of the goals and
ingredients of the tasks.
• Coordination Modelling: developing the coordination model for describ-
ing the interactions and the coordination protocols between the agents.
• Knowledge Modelling: modelling of the knowledge about the domain,
the agents (knowledge needed to carry out the tasks and their proactive
behaviour), and the environment (beliefs and inferences of the world,
including the rest of the agents).
• Organisation Modelling: developing the organisation model. Depending
on the type of project, it may be necessary to model the organisation of the
enterprise in which the MAS is going to be introduced for studying the
feasibility of the proposed solution. In this case, two instances of the
organisation model are developed—before and after the introduction of the
MAS. This model is also used to model the software agent organisation.
The Agent Model

The agent model acts as a link between the rest of the models of MAS-
CommonKADS, since it collects the capabilities and restrictions of the agents.
TEAM LinG
MAS-CommonKADS proposes different strategies that can be combined in

order to identify the agents of our problem. Some of these techniques are:
• Analysis of the actors of the use cases defined in the conceptualisation

phase. The actors of the use cases delimit the external agents of the system.
Several similar roles (actors) can be mapped onto one agent to simplify the
communication.
• Analysis of the statement of the problem. The syntactic analysis of the
problem statement can help to identify some agents. The candidate agents
are the subjects of the sentences, the active objects. The actions carried out
by these subjects should be developed by the agents as goals (with
initiative) or services (under demand).
• Usage of heuristics. The agents can be identified by determining whether
there is some conceptual distance: knowledge distribution, geographical
distribution, logical distribution, or organisational distribution.
• Initial task and expertise models can help us to identify the necessary
functions and the required knowledge capabilities, resulting in a preliminary
definition of the agents. The goals of the tasks will be assigned to the agents.
• Application of the internal use cases technique—see above.
• Application of the enhanced CRC cards (Figure 2)—see above
Once the agents have been identified, every agent should be further described
using textual templates that collect the main characteristics of the agents, such
as its name, type, role, position, a description, offered services, goals, skills
(sensors and effectors), reasoning capabilities, general capabilities, norms,
preferences, and permissions. The process of filling in these templates helps the
engineer to review his/her understanding of the problem and serves as a means
of communication with the rest of the team.
The Task Model

The task model describes all the activities (so-called tasks) that should be
performed in order to achieve a goal.
Tasks are decomposed following a top-down approach and described in an “and/
or” tree. The description of a task includes its name, its goal, a short description,
input and output ingredients, task structure, its control, frequency of application,
preconditions, and required capabilities of the performers.
TEAM LinG
Figure 4. Task diagram notation
Task 1 Task 2
O Task 4 O
Task 1.1 Task 1.2 Task 1.3 Task 3
Task 3.1 Task 3.2 Task 4.1 Task 4.2
Parallel Sequential Optional task Iterative task

decomposition decomposition
The potential benefits of the development of this model are the documentation
of the activities of the organisation before and after the introduction of the multi-
agent system. This documentation serves to support the maintenance and
management of changes in the organisation and to support project feasibility
assessment.
The graphical notation of this model (Figure 4) follows traditional tree decompo-
sition or, alternatively, a decomposition where optional and iterative tasks are
indicated. It can be also be used to describe whether the tasks can be performed
in a parallel or sequential way. Usually, the first versions of the model use just
the sequential decomposition and refined versions of the model introduce
gradually parallel tasks, optional tasks, or iterative tasks. Alternatively, the
activity diagram of UML can be used for this model.
In case a task is knowledge intensive, it should be further developed in the
expertise model. In the same way, if a task requires the agent interaction or
human interaction, it should be further developed in the coordination model or
communication model, respectively.
The Coordination Model
The coordination model specifies the interactions between the agents of the
multi-agent system. The main components of the coordination model are the
conversations between agents that are initiated to fulfill a goal in a cooperative
TEAM LinG
way. Every conversation is composed of interactions (associated to speech acts)

and follows a conversation protocol. In order to establish a conversation, there
are some capabilities between the agents that maintain this conversation
(capabilities and knowledge) that are specified in this model.
The coordination model has two milestones: (1) definition of the communication
channels and building of a software prototype for testing purposes (as a mock-
up); and (2) analysis of the interactions and determination of complex interac-
tions (with coordination protocols).
The first phase consists of the following steps:
1. Describe the prototypical scenarios between agents using MSC notation.

The conversations are identified, taking as input the results of the tech-
niques used for identifying agents. During this first stage, we will consider
that every conversation consists of just one single interaction and the
possible answer.
2. Represent the events (interchanged messages) between agents in event
flow diagrams (also called service charts). These diagrams collect the
relationships between the agents via services.
3. Model the data interchanged in each interaction. The expertise model can
help us to define the interchanged knowledge structures. These inter-
changed data are shown in the event flow diagram between square
brackets.
4. Model each interaction with the state transition diagrams of Specification
and Description Language (SDL), specifying speech-acts as inputs/
outputs of message events. These diagrams can be validated with the MSC
diagrams.
5. Each state can be further refined in the task or expertise model.
6. Analyse each interaction and determine its synchronisation type: synchro-
nous, asynchronous, or future.
The second phase consists of analysing the interactions for getting more
flexibility (relaxing, for example, the user requirements), taking advantage of the
parallelism, duplicating tasks using different methods, or resolving detected
conflicts. When a cooperation protocol is needed, we should consult the library
of cooperation protocols and reuse a protocol definition. If there is no protocol
suitable for our needs, it is necessary to define a new one. We can use High-
level Message Sequence Charts (HMSC), which are very useful for this
purpose. These diagrams show the road map (phases) of the protocol and how
the different phases (specified with MSC) are combined. A phase can be a
TEAM LinG
simple MSC or another HMSC. The processing of the interactions is described

using SDL state diagrams. It is also necessary to fill in the textual protocol
template specifying the required reasoning capabilities of the participants in the
protocol. These capabilities can be described using one or several instances of
the expertise model. The state diagrams consider three kinds of events: message
events, which are events from other agents using message-passing; external
events, events from the environment perceived through the sensors; and
internal events, events that arise in an agent because of its proactive attitude.
The potential benefits of the development of this model are:
• The development of the coordination model is a means for specifying the

prototypical interactions between the agents working on the resolution of
a problem, together with the interactions with the environment. This model
is used to store the decisions of the structure of communications and the
protocols associated with these communications. The usage of these
descriptions is twofold: the designer can reuse protocols and scenarios, and
the intelligent agent can select them at run time.
• MSC and SDL are formal description techniques with a well-defined syntax
and semantic. The usage of these languages for specifying interactions in
multi-agent systems have been achieved by: (1) defining one signal type for
each possible speech-act (message type); (2) associating a logical expres-
sion to each state name (using commentaries); and (3) considering internal
events (similar to spontaneous transitions) for changes in the mental state
of the agent motivated because of its proactive attitude.
The development of this model can help in the maintenance and testing of a multi-
agent system.
The Expertise Model

The expertise model, which is the focus of CommonKADS, is used for modelling
the reasoning capabilities of the agents to carry out their tasks and achieve their
goals. Normally, several instances of the expertise model should be developed:
modelling inferences on the domain (i.e., how to predict delays in flights,
taxonomies of delays and flights, etc.); modelling the reasoning of the agent (i.e.,
problem-solving methods to achieve a task, character of the agent, etc.); and
modelling the inferences of the environment (how an agent can interpret the
event it receives from other agents or from the world). When we have to develop
TEAM LinG
the reasoning capabilities of an agent, we will reuse previously developed

instances of the expertise model and adapt these instances to the new charac-
teristics of the problem.
The expertise model consists of the development of the application knowledge
(consisting of domain knowledge, inference knowledge, and task knowledge)
and problem-solving knowledge.
The usage of this model can take advantage of the work previously developed,
for example, for developing a planner.
• Domain Knowledge represents the declarative knowledge of the problem,

modelled as concepts, properties, expressions, and relationships using the
Conceptual Modelling Language (CML) or the graphical notation of the
Class Diagrams of UML.
• Inference Knowledge represents the inference steps performed for
solving a task. There is a library of generic inference structures selected
by the task type (diagnosis, assessment, etc.). These generic inference
structures should be adapted to the problem. The inference structure is a
compound of predefined inference types (how the domain concepts can be
used to make inferences, represented as ellipses) and domain roles
(rectangles). This generic inference structure should be adapted to our
problem. After defining the inference structure, it is instantiated into a
similar diagram for the domain.
• Task Knowledge represents the order of the inference structures. The
notation consists of inference structures and task-method inference de-
composition structures.
• Problem-Solving Method: during the design we should specify a Prob-
lem-Solving Method (PSM) for each inference type: how the inference is
carried out. The PSMs are arranged in libraries for reuse. Two generic
kinds of PSMs are defined: autonomous PSMs, when the plan is carried
out by the agent itself, and cooperative PSMs, when the PSM takes into
account the participation of other agents. In addition to defining the PSMs,
there should be defined its assumptions (when a PSM can be selected and
when it is more suitable).
The potential benefits of the development of this model are the utilisation of a
well-known knowledge-level modelling framework, which has been successfully
applied in several projects, and the provision of a library of generic components,
specification languages and software tools.
TEAM LinG
The Organisational Model

CommonKADS defines the organisation model for modelling the organisation in
which the knowledge-based system is going to be introduced. Here the model is
extended in the same way as the agent model for modelling the organisation of
agents. This model shows the static or structural relationships between the
agents, while the coordination model shows the dynamic relationships. The
graphical notation of these models is based on the notation of the Class Diagrams
of UML, adding a stereotype for distinguishing between agents and objects
(Figure 5). The aggregation symbol is used for expressing agent groups.
The agent symbol is that of MOSES (Henderson-Sellers & Edwards, 1994). In
contrast to this and to UML, the upper box does not store the defined attributes
as in UML, but rather the mental state and internal attributes of an agent, such
as their goals, beliefs, plans, and so forth. The lower box stores the external
attributes of the agents: services, sensors, and effectors.
In addition, the relationships between agents are modelled with associations in
which the roles played by the agents are described. Two special associations are
considered: inheritance and group.
The organisation model is used for modelling both the human organisation where
the multi-agent system is going to be developed and the multi-agent society itself.
The main modelling steps are the description of agent (human and software)
relationships, detailing the roles played in every relationship, and the study of the
relationship of the environmental objects with the agents. In the case of software
agent relationships, the model will collect the different use cases developed in the
coordination model, while in the human-software agent case, the system will
collect the use cases developed in the communication model. As a result of this
first analysis, the organisation model will define the static and dynamic relation-
ship between both human and software agents and the roles played by them in
the different interactions (in addition to the required knowledge to be able to
perform those interactions). During this process, inheritance and group relation-
ships between software agents can be modelled as a result of the analysis.
Figure 5. Organisation model notation
⎨
Goals
mental
Plans
state
Beliefs
association
⎨
Sensors
external role role inheritance group
Actuators
interface
Services
TEAM LinG
The inheritance relationship between agents is defined as the union of the values
of the precedent classes for each attribute. For example, an agent class has its
goals and the goals of the precedent agent classes. If an agent defines an
attribute as exclusive, the values are overwritten. The potential benefits of the
development of this model are the specification of the structural relationships
between human and/or software agents, and the relationship with the environ-
ment. The study of the organisation is a tool for the identification of possible
impacts of the multi-agent system when installed. In the same way, this model
can provide information about the functions, workflow, process, and structure of
the organisation that allows the study of the feasibility of the proposed solutions.
This model represents both class-agent diagrams and instance-agent diagrams,
showing the particular relationships with the environment. In contrast with other
paradigms (i.e., object-oriented), the agent-instance diagrams are frequently
more relevant than the class-agent diagrams.
The Design Model

As a result of the analysis phase, an initial set of agents has been determined.
During the design phase, the design model is developed. This phase is extended
for multi-agent systems and consists of the following phases:
• Agent network design: the infrastructure of the multi-agent system (so-

called network model) is determined and consists of network, knowledge,
and coordination facilities. The agents (so-called network agents) that
maintain this infrastructure are also defined, depending on the required
facilities. Some of these required facilities can be:
o Network facilities: agent name service, yellow/white pages ser-
vice, de/registering and subscription service, security level, encryp-
tion and authentication, transport/application protocol, accounting
service, and the like.
o Knowledge facilities: ontology servers, PSM servers, knowledge
representation language translators, and so forth.
o Coordination facilities: available coordination protocols and primi-
tives, protocol servers, group management facilities, facilities for
assistance in coordination of shared goals, police agents for detecting
misbehaviours and the control of the usage of common resources, and
so forth. The result of the common facilities shared by the agents
TEAM LinG
allows the efficient communication between the agents and is ex-

pressed by an ontology, in the same way as a service ontology.
• Agent design: the most suitable architecture is determined for each agent,
and some agents can be introduced or subdivided according to pragmatic
criteria. Each agent is subdivided in modules for user-communication (from
communication model), agent communication (from coordination model),
deliberation and reaction (from expertise, agent, and organisation models),
and external skills and services (from agent, expertise, and task models).
The agent design maps the functions defined in these modules onto the
selected agent architecture. The issue of designing an agent architecture
is not addressed in the methodology, since the agent architecture is provided
by the agent development platform.
• Platform design: selection of the software (multi-agent development
environment) and hardware that is needed (or available) for the system.
The potential benefits of the development of this model are:
• The decisions on the selection of a multi-agent platform and an agent

architecture for each agent are documented.
• The design model collects the information of the previously developed
models and details how these requirements can be achieved.
• The design model for multi-agent systems determines the common re-
sources and needs of the agents and designs a common infrastructure
managed by network agents. This facilitates modularity in the design.
Example Case Study

This case study is based on the work carried out in the European IST project
Collaborator 2000-30045 (Bergenti, Garijo, Poggi, Somacher, & Velasco, 2002),
where a multi-agent system, called COLLABORATOR, has been developed
and is capable of providing modern enterprises with a shared workspace
supporting the activities of virtual teams. The description of the system in this
chapter has been adapted in order to show the main characteristics of the
methodology MAS-CommonKADS.
The COLLABORATOR system is designed to be used by users with different
requirements, profiles, and devices. The users need to interact with each other
TEAM LinG
Figure 6. Screenshot of the Personal Calendar Agent
and with the system itself for preparing collaborative sessions, negotiating the
dates of the sessions, and managing their personal agendas.
The system will be based on a simple Personal Calendar Agent that is in charge
of managing the appointments of a user. The system will try to learn to set up a
new appointment according to its user preferences. In the case of a conflict, the
system will be able to negotiate with other personal agents from the other
participants in the appointment. The system will be running on a PDA (Figure 6).
Conceptualisation
The first phase of the methodology is the conceptualisation. In order to have a

first understanding of the system, we can apply the UER technique resulting in
the diagram shown in Figure 7. Two main actors have been identified: the user
and the personal agent. The user will be able to confirm a meeting. The basic use
case of the Personal Agent will be to negotiate a meeting, because its user wants
to start to schedule a meeting or because another user wants to schedule a
meeting with this user. This negotiation will be done through their personal
agents. From the very beginning, the UER technique also takes into account
some of the agent properties, such as reactivity and proactivity. In this case, one
environment object is identified: the mobile phone. The agent could react to a low
battery state. In addition, the agent has been assigned some responsibilities, such
TEAM LinG
Figure 7. UER cases for the Personal Agent
::Personal Agent
coordinate Avoid low

meeting battery
PA1 ::Personal Agent
coordinate Learn
meeting preferences
PDA
Avoid
coordinate
Calendar
meeting
conflicts
User
as avoiding calendar conflicts (two overlapping appointments) and learning user

preferences, in order to be as autonomous and adaptable as possible.
For every use, goal, and reactive case, the case should be further described,
describing its characteristics. For example, Avoid low battery is a high-priority
goal that is activated when the battery charge is low, deactivated with success
in case of reaching a high level of battery, and deactivated with failure in case
the battery is below some very low level.
Once we have identified the UER cases, they should be described using textual
templates as shown in Figure 8.
Figure 8. Textual template of the reactive case Avoid low battery
reactive-case Avoid low battery

description
The Personal Agent can detect that the PDA has a low level of
battery. In this case he should try to store all the relevant data of
the personal agenda and try to attract the attention of its user
activation-condition
low-battery level
deactivation-condition
recharge in process or plugged in
successful condition
personal gent hibernates before the PDA shutdowns or
the use recharge the batteries
failure condition
out of battery
TEAM LinG
Figure 9. Reactive cases relationship diagram
Figure 10. Extended CRC card
Agent PA Class: Personal Agent
Goals Plans Knowledge Collaborator Service
Avoid Calendar Suggest User Calendar - User

conflicts to choose Ontology
Try to Personal Change

group Agent Appointment
The next step is grouping the cases and studying their relationships. In this
example, we can identify two possible scenarios for avoiding low battery:
periodically reminding the user to recharge the PDA (more frequently in the case
of a low battery) or “shutdown” the PDA (Figure 9). We can also observe that
there is a scenario included in this reactive case: the detection of the battery
level.
Another technique we can use is that of extended CRC cards (Figure 10). Here,
for example, we can select one goal of our agent and define the plans to achieve
it, together with the required knowledge to perform the plans and the potential
collaborations in these plans that could also be autonomous. In case the agent
offers a standard service to other agents, we point out this service.
Analysis
After the conceptualisation phase, we have a first overview of the agents of the
system. In this particular simplified system, we have previously identified one
TEAM LinG
kind of agent: the Personal Agent. During the analysis phase, the engineer can
develop the analysis models that are needed in its problem. Usually, agent and
task model should always be developed. The development of the expertise model
helps the development of intelligent agents. In the case of interaction between
agents, the coordination model should be developed. The communication model
is developed when there is human-agent interaction. The organisation model
helps us to express structural relationships between agents or the human
organisation in which the multi-agent system is going to be introduced.
The models are developed in an iterative way, developing as many instances of
every model as needed and continuously refining the models. Since the models
are composed of artefacts, these artefacts can be easily reused.
Agent Model
From the actors of the conceptualisation phase, we can identify one agent, the
Personal Agent, which can have two roles: Coordinator or Participant. For the
sake of geographic distance and adaptation to the user, every Personal Agent
will be assigned to a single user.
In order to describe the Personal Agent, a textual agent template from the agent
model is filled in as shown in Figure 11, which helps us think about the problem.
Figure 11. Initial textual agent template of the Personal Agent
Agent PersonalAgent
type
Intelligent software agent
roles
Coordinator / Participant
description
Personal Agent of a user, in charge of managing meetings in behalf of its user and
inform its user of new information about the accepted meetings.
Personal agent should classify incoming events in order to learn suitable scheduling
depending on the event type and how the user handles every event type.
reasoning-skills
expertise
knowledge about the meeting domain and categories of events and other users
ability to classify and capability to adapt to user preferences for scheduling
(to be further defined in expertise model)
restrictions
norms
A Personal Agent should notify its user of any change in an appointment.
permissions
A Personal Agent only can be a coordinator in case its user has the rights
to be coordinator
TEAM LinG
Task Model
Now we can proceed to the development of the task model. Every instance of
the task model describes all the related activities to fulfill a goal. In this example,
we will further elaborate one the previously identified use cases: coordinate a
meeting. When a user wants to coordinate (initiate) a meeting, the user should
be allowed to have the role of coordinator for a meeting in that project.
This task can be decomposed as shown in the task diagram (Figure 12). This task
is initiated by the user. It should specify the foreseen length of the meeting, the
project and the required expertise of the participants. The task Collect-
Coordinator-Requirements models all the interaction between the user and the
agent that can help the user to show the available options for his/her decision.
Once the user has assigned the responsibility of coordinating the meeting, the
personal agent should select a range of suitable dates (task 2) based on its user
calendar and then select the attendees for that meeting (task 3). The next step
is to negotiate with the personal agents of the participants a suitable meeting date
as many times as needed (task 4, marked with an asterisk since it is an iterative
task). Finally, the agent should confirm with its user the negotiated date. If it is
suitable, the personal agent informs the other participants of the new appointment
that it is then added to their respective calendars. If the user decides that the
agreed upon date is not suitable, the user can start the task again or finish.
As seen in the previous task decomposition, the process of coordinating a
meeting has been described in a general way and can be reused in other projects.
Some of the tasks are further developed in other models. In particular, tasks 1
Collect Coordinator Requirements and 5.1 Confirm User are refined in the
communication model since they involve human interaction. Task 4.2 Send CFP
/ Receive Answer is refined in the coordination model since it involves agent
interaction. The tasks 2. Select attendees and 4.2. Decide Negotiate / End are
Figure 12. Task Model for coordinating a meeting.

Coordinate
a meeting
1. Collect 2. Select 3. Select

Coordinator 4. Negociate 5. Confirm
range of dates attendees
Requirement
4.2 Send CFP / 4.1 Decide 5.1 Confirm 5.2 Notify

Receive answers Negotiate / End user appointment
TEAM LinG
Figure 13. Task template of the task Select attendees
Task 3. Select attendees

goal
Obtain a set of indispensable and potential participants
Description
The coordinator should select the participants for the meeting based on the
project the meeting belongs to, the topic and the required expertise.
input
Characteristics of the meeting: project, required expertise (keywords), length,
tentative dates (according to availability of the coordinator) and list of
registered users
output
Qualified set of participants that are a subset of the registered users.
The participants are qualified as indispensable, convenient or unnecessary.
precondition
User should be authorised to act as a coordinator and there should be
registered users
supertask
Decide a meeting
subtasks
Decomposition-type
candidate tasks to be further developed in the expertise model since they may
require some reasoning process.
In order to show how a particular task can be described in the task model, the
task 3. Select attendees is described in using a textual task template.
Expertise Model
Instead of detailing further the rest of the tasks of the task model in this iteration,
we are going to illustrate how an instance of the expertise model can be
developed in this case study. We can further develop the task 3. Select
attendees in order to see how an intelligent agent can make this decision. The
expertise model (Schreiber et al., 1999) guides the knowledge-modelling pro-
cess. CommonKADS has a library of generic tasks, independent of the domain,
that can be reused or refined for knowledge intensive tasks. In this case, the
selection of attendees can be considered as a task of Assessment. A task of
assessment has the goal of finding a decision category for a case based on a set
of domain-specific norms. For example, in a loan application, the assessment
determines whether an application results in the loan or not (application-rejected,
accepted-with-risk, or accepted). In our problem, we will have to decide whether
a user would be interested and should participate in a meeting, qualifying him or
her as indispensable, convenient, or unnecessary.
TEAM LinG
Figure 14. Inference diagram of PSM Assessment
case
abstract
abstract specify norms select
case
decision match norm value evaluate norm
The CommonKADS library drives the knowledge acquisition process. Once we

have identified that this task is an Assessment, we can consult the CommonKADS
library and get its inference structure and task method (Figure 14). The inference
diagram illustrates inferences carried out in an assessment task. Ellipses
represent basic inferences and boxes represent knowledge roles. Inference
structures are domain independent, that is, they can be applied (reused) in
different domains without modifications.
We need to map the generic knowledge role to domain classes. In our example,
case represents data about the user and the meeting information, abstracted
case represents an abstraction of the case. For example, we can compare the
required expertise for attending the meeting and the users’ expertise and
determine a degree of expertise of every user for this particular meeting that can
help later to classify him/her. In addition, norms represent the domain knowledge
used in making the decision, for example, the criterion used to determine the
qualification of a user, such as availability on the proposed dates. The knowledge
role norm value represents a particular value of a norm (for example, the user
is available on some of the proposed dates), while decision categories repre-
sents how the user is qualified (indispensable, convenient, or unnecessary).
According to this inference structure, the process of Assessment consists of
obtaining an augmented case from the case we receive, that is, infer information,
specifying a set of criteria (norms) that can be evaluated, and selecting one. This
criterion is evaluated and, depending on this evaluation result, the user is
classified (decision class).
In parallel with the selection and adaptation of the generic task, an initial domain
can be modelled as shown in Figure 15. The degree-expertise is an abstraction
that takes into account the keywords of the user (expertise defined by keywords)
and the required expertise of the meeting.
In addition to this information, it is very important in this task to define the criteria
(norms) that will be applied to decide the qualification of an attendee. Several
criteria have been identified: the availability of the potential attendee on the dates
TEAM LinG
Figure 15. Domain model for selecting attendees

Attendee Meeting proposal
keywords receives keywords
degree-expertise Project
projects length
calendar dates
Figure 16. Hierarchy of criteria for selecting attendees
selection - criterion
dates fits expertise position in

calendar degree project
of the proposed meeting, the degree of expertise of an attendee for a meeting,

and the relationship of the position of the potential attendee in the project as not
member, engineer, project leader, and so forth (Figure 16).
The task method for Assessment (Figure 17) collects the control structure of the
task as can be taken directly from the CommonKADS library.
Once we have defined the control and mapped domain classes onto the identified
knowledge roles, we should specify the primitive inferences.
In our case study, the inference abstract obtains the attribute degree of expertise
of the attendee by comparing the expertise of the attendee and the required
expertise. This inference abstract can assign a degree between 0 and 1 that
represents the number of required keywords that can be attributed to the
attendee. The inference specify generates a list of applicable norms depending
on the case. In this example, it just generates the list of the three identified
criteria. The inference select selects a norm from the list, based on heuristics or
randomly. The inference evaluate determines the degree of satisfaction (not
satisfied, low, medium, high) of a particular criterion. For example, if a user is not
a member of the project, the evaluation is low. The inference match determines
the qualification based on the evaluation of all the criteria.
Once the inferences are specified, the knowledge bases can be filled. For
example: DateFitsCalendar is not-satisfied IMPLIES attendee is unneces-
sary.
TEAM LinG
Figure 17. Method for assessment (Schreiber et al., 1999, p. 132)
TASK assessment;
ROLES:
INPUT: case-description: "The case to be assessed";
OUTPUT: decision: "the result of assessing the case";
END TASK assessment;
TASK-METHOD assessment-with-abstraction;
REALIZES: assessment;
DECOMPOSITION:
INFERENCES: abstract, specify, select, evaluate, match;
ROLES:
INTERMEDIATE:
abstracted-case: "The raw data plus the abstractions";
norms: "The full set of assessment norms";
norm: "A single assessment norm";
norm-value: "Degree of satisfaction of the criterion (not satisfied,
low, medium, high";
evaluation-results: "List of evaluated norms";
CONTROL-STRUCTURE:
WHILE HAS-SOLUTION abstract(case-description -> abstracted-case)
DO
case-description := abstracted-case;
END WHILE
specify(abstracted-case -> norms);
REPEAT
select(norms -> norm);
evaluate(abstracted-case + norm -> norm-value);
evaluation-results := norm-value ADD evaluation-results;
UNTIL
HAS-SOLUTION match(evaluation-results -> decision);
END REPEAT
END TASK-METHOD assessment-with-abstraction;
Coordination Model
Now we will show how to model interactions between agents using the
coordination model. The coordination model describes the conversation between
agents and identifies the services that agents offer to the rest of agents. The
coordination model identifies the needed conversations, usually with the input
from other models. In this case study, we have identified a task 4.1 Send CFP
/ Receive Answer and task 5.2 Notify appointment.
Once a conversation is identified, the next step is to describe the roles of the
participants in the conversation, the interactions and services, and the informa-
tion interchanged in the interaction, and then analyse how every interaction can
TEAM LinG
Figure 18. Message Sequence Chart of negotiating a date
msc FIPA Coordinate Meeting
Coordinator Participants
T propose (range-of-dates)
loop(0,n)
inform (subrange-of-dates)
inform (definitive-date)
be modelled (for example, with or without negotiation, and how the agent should
select one or another protocol). In the case study, there are two identified roles
in this conversation (coordinator and participant). The coordinator sends to the
participants a meeting description with a range of potential dates and receives
in a certain period the answers with subranges of the initial range. Then, the
coordinator decides a date and notifies all participants.
The notation of the model is based on MSC (ITU-Z.120, 1996) for the
interactions and SDL (ITU-T-Z.100, 1994) for processing these interactions.
Alternative notations are UML2.0 Interaction Diagrams, which incorporate
most of the characteristics of MSC and SDL, and AUML Interaction diagrams
(Beuer, Müller, & Odell, 2001).
In order to illustrate the application of other models, we will develop here the task
of the task model. The MSC diagram is shown in Figure 18.
Organisation Model
The organisation model’s agent model uses the organisation model diagram
(Figure 19). In this example, there only two positions in the organisation,
depending on the scheduled meeting: Coordinator or Participant. The organisational
TEAM LinG
Figure 19. Organisation diagram of collaborator
Personal Agent
Goals
Avoid Calendar, Learn Preferences
Beliefs
Preferences
Plans
GroupAppPSM, NegociatePSM, ConfirmPSM
Sensors
Battery
Actuators
Shutdown
Services participant
Schedule
participates in Scheduled
meeting
coordinator
model could also be used for modelling the human positions in the company and
resolve eventual conflicts according to its hierarchical position.
Design
The design model describes the components that satisfy the requirements of the
analysis models. There are three main decisions to be carried out in this model:
platform design, agent network design, and agent design that are collected in a
textual template as shown in Figure 20.
In this case study, the users will be able to see the scheduled meetings in their
PDAs and on the Web. The platform selected was JADE (http://
www.jade.cselt.it) and the extension BlueJADE (Cowan & Griss, 2002) for
deploying JADE as a service of the application server JBoss (http://
www.jboss.org).
The design of the agent network consists of identifying a set of agents that
provide the network, coordination, and knowledge facilities. In this case study,
attending to design considerations, since the users can be off-line, there is a need
to define a new agent, the Session Manager Agent (SMA) that is woken by the
application server when needed (to initiate a new session). In this way, the task
model developed as part of the task model of the Personal Agent is now
reassigned to the Session Manager Agent. We can identify another service, the
TEAM LinG
Figure 20. Design textual templates for Session Manager Agent (SMA)
objects
Platform Collaborator
Languages: Java, Jess
Software: JBoss, JADE, Jess
Network Collaborator
Network-services – FIPA Standard (AMS, DF)
Knowledge-services: none
Coordination services: Resource Manager Service, Session Manager Agent
Agent System Session ManagerAgent

Subsystems:
user-interaction SMAInterface (tasks 1, 5.1; communication model)
reasoning SMAKB tasks 2,3, 4.2, 5.2, expertise model
agent-interaction CoordinatorBehaviour (task 4.1 and 5.2), main-task
SMABehaviour (Coordinating task).
Resource Manager Service, which is used to share and store the calendars
persistently between Personal Agents. Regarding the design of this agent,
collecting the requirements from the analysis models (Agent, Task, Communi-
cation, Coordination, Expertise, and Organisation), this agent has no sensors,
FIPA communications capabilities (FIPA 2002), and only simple reasoning
capabilities. The architecture selected for this agent is a deliberative one, which
can be implemented with JADE using Jess Behaviours.
Conclusions
This chapter has shown the main modelling concepts of MAS-CommonKADS

and how the agent metaphor can be combined with standard object-oriented and
knowledge engineering techniques.
MAS-CommonKADS analyses the multi-agent system from different perspec-
tives (performed tasks, reasoning, agent interaction, user interaction, multi-agent
structure) that provide a description easy to implement in a particular multi-agent
framework.
The main strengths of the methodology are its simplicity, extending in a natural
way the standard software engineering methods. In addition, MAS-
CommonKADS takes into account reusability at all levels of the models, making
it easy to reuse analyses and designs from previous projects. The main
weaknesses of the methodology are its limited support in design, testing, and
coding.
TEAM LinG
There are two supporting tools for applying the methodology, a Java CASE tool
and a Plug-In for Rational Rose.
MAS-CommonKADS has been applied by our research groups in projects of
intelligent network management and development of hybrid, symbolic-
connectionist systems. Other researchers have also successfully applied MAS-
CommonKADS for flights reservation (Arenas & Barrera-Sanabria, 2002),
development of organisational memories (Arenas & Barrera-Sanabria, 2003), e-
learning (Salcedo, 2003), paper review assistant (Marci de Oliveira, 2000), or
simulation of stakeholders (Henesey, Notteboom & Davidsson, 2003).
Acknowledgments
We would like to thank the editors and anonymous reviewers of this chapter for
their comments, all the students who have contributed to its development, and all
the partners of the Collaborator project.
References
Arenas, A. & Barrera-Sanabria, G. (2002). Applying the MAS-CommonKADS
methodology to the Flights reservation problem: Integrating coordinating
and expertise. In Proceedings of 5th Joint Conference on Knowledge-
based Software Engineering. IOS Press.
Arenas, A. & Barrera-Sanabria, G. (2003). Modelling intelligent agents for
organisational memories. In Knowledge-based Intelligent Information
and Engineering Systems, Lecture notes in computer science 2773 (pp.
430-437). Berlin: Springer-Verlag.
Beck, K. (1999). Extreme programming explained: Embrance change.
Boston: Addison-Wesley Professional.
Beck, K. & Cunningham, W. (1989). A laboratory for teaching object-oriented
thinking. In OOPSLA’89 Conference Proceedings, New Orleans, LA,
USA (Vol. 17, pp. 1-6).
Bauer, B., Müller, J. P., & Odell, J. (2001). Agent UML: A formalism for
specifying multiagent interaction. In P. Ciancarini & M. Wooldridge (Eds.),
Agent-oriented software engineering (pp. 91-103). Berlin: Springer-
Verlag.
TEAM LinG
Bergenti, F., Garijo, M., Poggi, A., Somacher, M. & Velasco, J. R. (2002).
Enhancing collaborative work through agents. In VII Convegno
dell’Associazione Italiana per l’Intelligenza Artificiale. Available online
from http://www-dii.ing.unisi.it/aiia2002/paper.htm
Cowan, D. & Griss, M. (2002). Making software agent technology available
to enterprise applications, Technical report HP-2002-211, Hewlett-
Packard Labs.
FIPA (2004). FIPA Agent Communication Language Specifications. Available
online http://www.fipa.org/repository/aclspecs.html
FIPA (2004). The Foundation for Intelligent Physical Agents. Available online
http://www.fipa.org
Henderson-Sellers, B. & Edwards, J.M. (1994). BOOKTWO of object-ori-
ented knowledge: The working object. Sydney: Prentice Hall.
Henesey, L., Notteboom, T., & Davidsson, P. (2003). Agent-based simulation
of stakeholders relations: An approach to sustainable port terminal man-
agement. In Proceedings of the 13th International Association of
Maritime Economist (IAME) Conference, Busan, Korea (pp. 314-331).
Iglesias, C. A. (1998). Definition of a methodology for the development of
multiagent systems. PhD thesis, Technical University of Madrid (in
Spanish).
Iglesias, C. A. & Garijo, M. (1999). UER technique: Conceptualisation for
agent-oriented development. In Proceedings of the 3rd World
Multiconference on Systemics, Cybernetics and Informatics (SCI’99)
and 5th International Conference on Information Systems Analysis
and Synthesis (ISAS’99) (Vol. 5, pp. 535-540). International Institute of
Informatics and Systemics.
Iglesias, C. A., Garijo, M., González, J. C., & Velasco, J. R. (1998). Analysis and
design of multiagent systems using MAS-CommonKADS. In N. Callaos &
M. Torres (Eds.), Intelligent agents IV: Agent theories, architectures
and languages, LNAI 1365 (pp. 313-326). Berlin: Springer-Verlag.
ITU-T-Z.100 (1994). CCITT specification and description language (SDL).
Technical report, ITU-T.
ITU-Z.120 (1996). Message Sequence Chart (MSC). ITU. Z.120. Technical
report, ITU-T. Geneva.
Jacobson, I., Christerson, M., Jonsson, P., & Övergaard, G. (1992). Object-
oriented software engineering. A use case driven approach. New
York: ACM Press.
Kruchten, P. (2000). The rational unified process: An introduction (2 nd ed.).
Reading, MA: Addison-Wesley.
TEAM LinG
Marci de Oliveira, H. (2002). Técnicas para Projeto e Implementaçao de

Agentes de Software, Master Thesis, Universidade Estadual de Maringá,
Brasil.
Rumbaugh, J., Blaha, M., Premerlani, W., & Eddy, V. F. (1991). Object-
oriented modelling and design. Upper Saddle River, NJ: Prentice-Hall.
Salcedo, P. (2003). Inteligencia Artificial Distribuida y Razonamiento basado en
casos en la Arquitectura de un Sistema Basado en el Conocimiento para la
Educación a Distancia. Revista de Ingeniería Informática, 9.
Salic, B. (2004). UML 2.0: Exploiting abstraction and automation. Available
online http://www.sdtimes.com/opinions/guestview_098.htm
Schreiber, G., Akkermans, H., Anjewierden, A., deHoog, R., Shadbolt, N.,
VandeVelde, W. & Wielinga, B. (1999). Knowledge engineering and
management: The commonKADS methodology. Cambridge, MA: MIT
Press.
Wirfs-Brock, R., Wilkerson, B. & Wiener, L. (1990). Designing object-
oriented software. Upper Saddle River, NJ: Prentice-Hall
TEAM LinG
From Requirements to Code with the PASSI Methodology 79
Chapter IV
From Requirements to
Code with the
PASSI Methodology
Massimo Cossentino
ICAR-CNR, Italy
Abstract
A Process for Agent Societies Specification and Implementation (PASSI) is
a step-by-step requirement-to-code methodology for designing and
developing multi-agent societies, integrating design models and concepts
from both object-oriented (OO) software engineering and artificial
intelligence approaches using the UML notation. The models and phases of
PASSI encompass representation of system requirements, social viewpoint,
solution architecture, code production and reuse, and deployment
configuration supporting mobility of agents. The methodology is illustrated
by the well-known Bookstore case study.
Introduction
At present, several methods and representations for agent-based systems have
been proposed (Aridor & Lange, 1998; Bernon, Camps, Gleizes, & Picard, 2004;
Bresciani, Giorgini, Giunchiglia, Mylopoulos, & Perini, 2004; DeLoach & Wood,
TEAM LinG
80 Cossentino
2001; Jennings, 2000; Kendall, Krishna, Pathak, & Suresh, 1998; Zambonelli,
Jennings, & Wooldridge, 2001, 2003). In order to explore them, we shall consider
a relevant aspect in modelling software, that is, fidelity. Robbins, Medvidovic,
Redmiles, and Rosenblum (1998) have defined fidelity as the distance between
a model and its implementation. This means that low fidelity models are problem-
oriented, while high fidelity models are more solution-oriented.
Since agents are still a forefront issue, some researchers have proposed methods
involving abstractions of social phenomena and knowledge (Bernon et al., 2004;
Bresciani et al., 2004; Jennings, 2000; Zambonelli, Jennings, & Wooldridge,
2001, 2003) (low-fidelity models); others have proposed representations involv-
ing implementation matters (Aridor & Lange, 1998; DeLoach & Wood, &
Sparkman, 2001; Kendall et al., 1998) (higher fidelity models).
There exists one response to these proposals, which is to treat agent-based
systems the same as non-agent based ones. However, we reject this idea
because we think it is more natural to describe agents using a psychological and
social language. Therefore, we believe that there is a need for specific methods
or representations tailored for agent-based software. This belief originates from
the related literature. To give an example, Yu and Liu (2000) say that “an agent
is an actor with concrete, physical manifestations, such as a human individual.
An agent has dependencies that apply regardless of what role he/she/it happens
to be playing.” On the other hand, Jennings (2000) defines an agent as “an
encapsulated computer system that is situated in some environment and that is
capable of flexible, autonomous action in that environment in order to meet its
design objectives.” Also, Wooldridge and Ciancarini (2001) see the agent as a
system that enjoys autonomy, reactivity, pro-activeness, and social ability.
Therefore, multi-agent systems (MAS) differ from non-agent based ones
because agents are meant to be autonomous elements of intelligent functionality.
Consequently, this requires that agent-based software engineering methods
encompass standard design activities and representations as well as models of
the agent society.
Two more responses exist. They both argue that agents differ from other
software but disagree about the differences. The first, proposed by supporters
of low-fidelity representations, is that agents are distinguished by their social and
epistemological properties, only these need different abstractions. The second,
proposed by supporters of high-fidelity representations, is that the difference is
in the deployment and interaction mechanisms. With regard to the agent notion,
DeLoach, Wood, and Sparkman (2001) argue that “an agent class is a template
for a type of agent in the system and is analogous to an object class in object-
orientation. An agent is an actual instance of an agent class,” and “… agent
classes are defined in terms of the roles they will play and the conversations in
which they must participate.” This definition in some way conjugates the social-
TEAM LinG
(conversational) and deployment- (implementation) oriented theories and posi-

tions DeLoach, Wood, and Sparkman in the middle.
We also reject these two views in their extreme forms. A designer may want to
work at different levels of detail when modeling a system. This requires
appropriate representations at all levels of detail or fidelity and, crucially,
systematic mappings between them. Because such issues are, at present, not
addressed by any of the existing MAS analysis and design methodologies, we
have decided to create a brand new one.
The methodology we are going to illustrate is named a Process for Agent
Societies Specification and Implementation (PASSI) or “steps” in the Italian
language. It is our attempt at solving the scientific problem arising from the above
considerations. In fact, it is a step-by-step requirement-to-code methodology for
designing and developing multi-agent societies integrating design models and
concepts from both object-oriented (OO) software engineering and MAS, using
the Unified Modeling Language (UML) notation. It is closer to the argument
made above for high-fidelity representations, but addresses the systematic
mapping between levels of detail and fidelity. The target environment we have
chosen is the standard, widely implemented Foundation for Intelligent Physical
Agents (FIPA) architecture (O’Brien & Nicol, 1998; Poslad, Buckle, &
Hadingham, 2000). PASSI is the result of a long period of theoretical studies and
experiments in the development of embedded robotics applications (Chella,
Cossentino, & LoFaso, 2000; Cossentino, Sabatucci, & Chella, 2003).
Figure 1. The models and phases of the PASSI methodology
Initial
Requirements Next Iteration
System Requirements Model Agent Implementation Code Model

Model
Domain Req.
Description Code Reuse
Ag. Structure
Definition
Agent Code
Identification Production
Ag. Behavior
Role Task Description
Identification Specification Society
Agent Test Test
Ontology Role Protocol Deployment

Description Description Description Configuration
Agent Society Model Deployment Model
TEAM LinG
82 Cossentino
The remainder of this chapter is structured as follows. The next section gives a
quick presentation of the methodology’s models and provides a justification for
PASSI. The third section presents the application of PASSI to the “Juul Møller
Bokhandel A/S” case study (Andersen, 1997), giving a detailed description of the
steps and the use of UML notations within each of them. A comparison of PASSI
with the Gaia (Zambonelli, Jennings, & Wooldridge, 2003) and MaSE (DeLoach,
Wood, & Sparkman, 2001) is then given, and some conclusions are presented in
the final section.
A Quick Overview of the

PASSI Methodology
In conceiving this design methodology, we followed one specific guideline: the
use of standards whenever possible. This justifies the use of UML as modeling
language, the use of the FIPA architecture for the implementation of our agents,
and the use of XML in order to represent the knowledge exchanged by the agents
in their messages.
PASSI (Process for Agent Societies Specification and Implementation) is a
step-by-step requirement-to-code methodology for developing multi-agent soft-
ware that integrates design models and philosophies from both object-oriented
software engineering and MAS using (more properly extending) the UML
notation (OMG, 2003b). Because of the specific needs of agent design, the UML
semantics and notation will be used as reference points, but they will be extended,
and UML diagrams will be often used to represent concepts that are not
considered in UML and/or the notation will be modified to better represent what
should be modeled in the specific artifact. The PASSI process is composed of
five process components: System Requirements, Agent Society, Agent Imple-
mentation, Code, and Deployment, and several distinct work definitions within
each of them (Figure 1). Code production is strongly supported by the automatic
generation of a large amount of code thanks to the PASSI ToolKit (PTK) used
to design the system and a library of reusable patterns of code and pieces of
design managed by the AgentFactory application.
In what follows, the five process components will be referred to as models and
the work definitions as phases; in order to clarify the meaning of these terms, we
will provide a parallelism with the Software Process Engineering Metamodel
(SPEM) concepts (SPEM, 2002). Referring to SPEM, we could say that a
process is composed of process components; each process component could be
made by phases (a kind of work definition) that are in turn decomposable into
activities and steps (both activities and steps are again work definitions). In the
TEAM LinG
PASSI process, the element that corresponds to the SPEM process component
is called model, and it is composed of phases (for instance, in Figure 1, we can
see that the System Requirements model is composed of the Domain Require-
ments Description, Agents Identification, … phases). The “models” and “phases”
of PASSI are:
1. System Requirements Model: a model of the system requirements in

terms of agency and purpose. It is composed of four phases:
(a) Domain Requirements Description (D.R.D.): a functional description
of the system using conventional use case diagrams;
(b) Agent Identification (A.Id.): the phase of attribution of responsibili-
ties to agents, represented as stereotyped UML packages;
(c) Role Identification (R.Id.): a series of sequence diagrams exploring
the responsibilities of each agent through role-specific scenarios; and
(d) Task Specification (T.Sp.): specification of the capabilities of each
agent with activity diagrams.
2. Agent Society Model: a model of the social interactions and dependen-
cies among the agents involved in the solution. Developing this model
involves three steps:
(a) Ontology Description (O.D.): use of class diagrams and OCL con-
straints to describe the knowledge ascribed to individual agents and
their communications;
(b) Role Description (R.D.): class diagrams are used to show the roles
played by agents, the tasks involved, communication capabilities, and
inter-agent dependencies; and
(c) Protocol Description (P.D.): use of sequence diagrams to specify the
grammar of each pragmatic communication protocol in terms of
speech-act performatives.
3. Agent Implementation Model: a classical model of the solution architec-
ture in terms of classes and methods; the most important difference with the
common object-oriented approach is that we have two different levels of
abstraction, the social (multi-agent) level and the single-agent level. This
model is composed of the following steps:
(a) Agent Structure Definition (A.S.D.): conventional class diagrams
describe the structure of solution agent classes; and
(b) Agent Behavior Description (A.B.D.): activity diagrams or state-
charts describe the behavior of individual agents.
4. Code Model: a model of the solution at the code level requiring the
following steps to produce it:
TEAM LinG
84 Cossentino
(a) generation of code from the model using one of the functionalities of
the PASSI add-in. It is possible to generate not only the skeletons but
also largely reusable parts of the method’s implementation based on
a library of reused patterns and associated design descriptions; and
(b) manual completion of the source code.
5. Deployment Model: a model of the distribution of the parts of the system
across hardware processing units and their migration between processing
units. It involves one step: Deployment Configuration (D.C.): deployment
diagrams describe the allocation of agents to the available processing units
and any constraints on migration and mobility.
Testing: the testing activity has been divided into two different steps: the
single-agent test is devoted to verifying the behavior of each agent
regarding the original requirements for the system solved by the specific
agent (Caire, Cossentino, Negri, Poggi, & Turci, 2004). During the Society
Test, integration verification is carried out together with the validation of
the overall results of this iteration. The Agent Test is performed on the
single agent before the deployment phase, while the society test is carried
out on the complete system after its deployment.
In the following, each of the above cited models will be discussed in details in a
specific subsection.
The Agent in PASSI
The concept of agent will be central to our discussion and therefore a definition
of what we mean by an agent will be helpful before proceedings.
In PASSI, we consider two different aspects of the agent: during the initial steps
of the design, it is seen as an autonomous entity capable of pursuing an objective
through its autonomous decisions, actions, and social relationships. This helps in
preparing a solution that is later implemented, referring to the agent as a
significant software unit. An agent may undertake several functional roles during
interactions with other agents to achieve its goals. A role is a collection of tasks
performed by the agent in pursuing a sub-goal or offering some service to the
other members of the society. A task, in turn, is defined as a purposeful unit of
individual or interactive behavior. Each agent has a representation of the world
in terms of an ontology that is also referred to in all the messages that the agents
exchange.
TEAM LinG
Figure 2. The agents’ implementation iterations
Agent Implementation Model
Multi-Agent Single-Agent
Agent Structure Agent Structure
Definition Definition
Agent Behavior Agent Behavior

Description Description
Iterations
PASSI is iterative, as are most widely accepted object-oriented methods. There

occur two types of iterations in it. The first one is led by new requirements and
involves all the PASSI models.
The second iteration occurs, involving only modifications to the Agent Implemen-
tation Model. It is characterized by a double level of iteration (see Figure 2). We
need to look at this model as characterized by two views: the multi-agent and
single-agent views. The outer level of iteration (dashed arrows) concerns the
dependencies between multi-agent and single-agent views. The first (multi-
agent) view relates to the agents’ structure (in terms of cooperation and tasks
involved) and behaviors (flows of events depicting cooperation). The second one
instead relates to the single-agent structure (attributes, methods, inner classes)
and behavior (specified in an appropriate way). The inner level of iteration
(Agent Structure Definition – Agent Behavior Description) takes place in both
the multi-agent and single-agent views and concerns the dependencies between
structural and behavioral matters.
As a consequence of this double level of iteration, the Agent Implementation
Model is composed of two steps (A.S.D. and A.B.D.) but yields four kinds of
diagrams, taking into account the multi- and the single-agent views.
A More Detailed Description of PASSI
Throughout the following subsections, we refer to the “Juul Møller Bokhandel A/

S” Case Study (Andersen, 1997) that describes the problems of a small
bookstore coping with rapidly expanding Internet-based book retailers. The
bookstore has a strong business relationship with the Norwegian School of
TEAM LinG
86 Cossentino
Management. Nevertheless, there are communication gaps between them. As

a consequence, the bookseller is in trouble, for example, when pricing the books
(due to a lack of information about the number of attendees of some courses) or
when the School changes the required literature. In addition, there are problems
with the distribution chain. This requires a strong knowledge of distributors’ and
publishers’ processes and practices.
Domain Requirements Description Phase
Although many authors make use of goals in requirements engineering (Antón

& Potts, 1998, Potts, 1999), we prefer the approach coming from Jacobson,
Christerson, Jonsson, and Overgaard (1992), and we describe requirements in
terms of use case diagrams. The Domain Requirements Description Phase, as
a result, is a functional description of the system composed of a hierarchical
series of use case diagrams. Scenarios of the detailed use case diagrams are then
explained using sequence diagrams. Figure 3 shows part of the Domain
Requirements Description diagram depicting our analysis for the bookstore case
study. Stereotypes used here come from the UML standard.
Throughout this chapter, we will only examine one scenario—the one that takes
place every time that the bookstore needs to purchase some books (Provide
Books use case in Figure 3). This may happen, for example, before the beginning
of every semester, so as to provide the store with the requested books and
therefore anticipate the students’ needs; or when some faculty has changed the
required literature or switched a book from “recommended” to “required.” The
scenario begins with the prediction of the students’ needs in order to establish
whether there is a sufficient number of copies of that book in the store or not.
If not, and if the book is needed, a new purchase must be made; this in turn
includes (see Figure 3):
• Definition of the desired quotation (Define Purchase-Money use case) by

the use of an expert system that holds the history of previous purchases,
especially with regard to courses, teachers, number of attendees, books
purchased and books sold, suppliers, time elapsed for negotiation and
delivery, and so forth.
• Negotiation of the price (Negotiate Purchase-Money use case).
• Execution of the order (Carry Out Order).
• Updating of the purchase history archive (Update Purchase History) in
order to increase the knowledge of the purchase expert system.
• Receiving delivery information about the purchase (Receive Delivery) in
order to close the case related to it.
TEAM LinG
Figure 3. A portion of domain requirements description diagram
<<communicate>>
<<extend>>
Keep NSM Needs Updated NSM Courses
Web Server <<include>>
<<include>>
Carry Out Order Carry Out Order By Phone
<<extend>> Clerk
<<include>> <<include>>
Predict Students Needs Provide Books Negotiate Purchase-Money Negotiate Purchase-Money
By Telephone
<<include>>
Define Purchase-Money <<include>>
Supplier
<<include>>
Update Purchase History
<<include>>
Receive Delivery Storekeeper

Record Sale
Agent Identification Phase
If we look at a MAS as a heterogeneous society of intended and existent agents

that in Jackson’s terminology can be “bidden” or influenced but not determinis-
tically controlled (Jackson, 2001), it is more reasonable to locate required
behaviors into units of responsibility from the start. That is why we have put this
phase in the System Requirements Model.
Agents’ identification starts from the use case diagrams of the previous step.
Using our definition of agent, it is possible to see identification as a use case or
a package of use cases in the functional decomposition of the previous phase.
Starting from a sufficiently detailed diagram of the system functionalities (Figure
3), we group one or more use cases into stereotyped packages so as to form a
new diagram (Figure 4). In so doing, each package defines the functionalities of
a specific agent.
Relationships between use cases of the same agent follow the usual UML syntax
and stereotypes (see the “include” relationships in the Purchase Monitor and
Purchase Advisor agents in Figure 4), while relationships between use cases of
different agents are stereotyped as “communicate.”
The convention adopted for this diagram is to direct communication relationships
between agents from the initiator towards the participant.
TEAM LinG
88 Cossentino
Figure 4. The agents identification diagram obtained from the requirements

described in the previous phase
<<Agent>>
PurchaseM onitor
NSM Courses
Web Server <<Agent>>
<<Agent>>
Purchaser ClerkUI
<<Agent>>
<<communicate>>
Keep NSM Needs Updated
PurchaseM anager
<<communicate>> Carry Out Order
Carry Out Order By Telephone
<<include>>
<<communicate>> <<communicate>>
<<communicate>> Clerk
Provide Books
Negotiate Purchase-M oney Negotiate Purchase-M oney By Telep hone
Predict Students Needs
<<communicate>>
<<communicate>>
<<Agent>>
PurchaseAdvisor
Supplier
<<communicate>>
Define Purchase-M oney
<<Agent>>
Update Purchase History StoreUI
<<include>>
Receive Delivery Storekeeper

Record Sale
Note, for example, how the “include” relationship between the use cases
Provide Books and Receive Delivery (Figure 3) turned from “include” into
“communication” and also changed the navigability direction. This reflects the
fact that in an autonomous organization of agents in a distributed system, we can
organize things in a departmental manner, so as to have a StoreKeeper actor that
records any stock’s delivery that occurs. The StoreUI agent may then notify the
Purchase Manager agent of that delivery. In so doing, the Purchase Manager
does not need to keep bothering about the delivery of a stock, but rather it
continues to work while another agent is taking care of this task.
The selection of the use cases that will be part of each agent should be done
pursuing the criteria of functionality coherence and cohesion. These are impor-
tant attributes of the design, and if the adopted agent identification does not
produce a satisfactory result from this point of view, a change in it is strongly
advised. In a limited number of cases (for instance when relevant limits in
communication bandwidth are predictable, as occurs for agents deployed in small
TEAM LinG
and mobile devices), agents should be composed also considering how big are the
information banks they exchange, although this cannot be evaluated at this stage.
The iterative and incremental nature of PASSI provides great help in solving this
problem; an initial hypothesis for agent identification is done and, if problems
occur, it can be changed in successive iterations.
Roles Identification Phase
This phase occurs early in the requirements analysis since we now deal more
with an agent’s externally visible behavior than its structure – only approximate
at this step.
Roles identification (R. Id.) is based on exploring all the possible paths of the
Agents Identification diagram involving inter-agent communication. A path
describes a scenario of interacting agents working to achieve a required behavior
of the system. It is composed of several communication paths. A communication
path is simply a “communicate” relationship between two agents in the above
diagram. Each of them may belong to several scenarios, which are drawn by
means of sequence diagrams in which objects are used to symbolize roles.
Figure 5 shows the already presented scenario, arising when a new purchase is
required from the role Informer of the PurchaseMonitor agent to the role
BooksProvider of the Purchase Manager agent. Although the diagram
resembles an UML sequence diagram, the syntax is a bit different. Each object
in the diagram represents an agent’s role, and we name it with the following
syntax:
<role_name> : <agent_name>
An agent may participate in different scenarios playing distinct roles in each. It

may also play distinct roles in the same scenario (as happens to the Purchaser
and the Purchase Advisor agents in Figure 5). Usually, UML sequence
diagrams begin because of some actor’s action; in PASSI, being agents
autonomous and active, they can trigger a new scenario and actors can appear
later (or not). For this reason, the PurchaseMonitor agent (while playing its
Informer role) can be the first element of this diagram and can fire it.
The messages in the sequence diagram may either signify events generated by
the external environment or communication between the roles of one or more
agents. A message specifies what the role is to do and possibly the data to be
provided or received.
TEAM LinG
90 Cossentino
Figure 5. The roles identification diagram for the scenario in which the
Purchase Monitor agent announces the need for a book purchase
Inf ormer : BooksProv ider : Consultant : Negotiator : OrderPlacer : Deliv ery Notif ier : Recorder :
PurchaseMonitor PurchaseManager PurchaseAdv isor Purchaser : Supplier Purchaser StoreUI PurchaseAdv isor
: Storekeeper
Prov ideTheseBooks
SuggestPurchaseConditions
Try TheseConditions
NegotiateTheseConditionsWithThisSupplier
Y ourBestOf f er?
HereIsMy Best
*[Of f erNotGoodEnough] WhatAboutThis?
That'sTheBestOf f er
Carry OutOrder
WantToBuy
NewDeliv ery
BooksDeliv ered
GotTheBooks
UpdatePurchaseHistory
We can describe the scenario as follows:
• The Informer informs the BooksProvider that the bookstore needs to

purchase a specified stock of books.
• Given a list of suppliers for the needed books, the BooksProvider requests
that the Consultant suggest purchase conditions (number of stocks,
purchase money, etc.) on the basis of past business.
• Whether the Consultant has returned any advice or not, the BooksProvider
gives the Negotiator the data about the supplier with which to negotiate and
the conditions to be negotiated; at the same time, it requests the negotiation
to be started. The BooksProvider is then ready to take care of other
requests that may come from the cooperating agents’ roles.
TEAM LinG
• The Negotiator negotiates via fax or e-mail (this is the case of the present
scenario) and gets the best offer. It then returns it to the BooksProvider.
• The BooksProvider establishes whether the offer is good enough or not,
according to its budget and considerations such as the pricing of the book
and the number of students that would then buy it. In this scenario, we
assume that the offer is good enough and so the BooksProvider proposes
that the OrderPlacer buys the books. Therefore, the BooksProvider is
then ready to take care of other requests.
• When the books are delivered, a notification is then forwarded from the
DeliveryNotifier to the BooksProvider.
The rest of the scenario is straightforward. Data contained in the messages of

the above sequence diagram are specified more in details later in the Ontology
Description phase.
Task Specification Phase
At this step, we focus on each agent’s behavior in order to conceive of a plan

that could fulfil the agent’s requirements by delegating its functionalities to a set
of tasks. Tasks generally encapsulate some functionality that forms a logical unit
of work. For every agent in the model, we draw an activity diagram that is made
up of two swimlanes. The one from the right-hand side contains a collection of
activities symbolizing the agent’s tasks, whereas the one from the left-hand side
contains some activities representing the other interacting agents.
A Task Specification diagram (T.Sp.) (see Figure 6) summarizes what the agent
is capable of doing, ignoring information about roles that an agent plays when
carrying out particular tasks. Relationships between activities signify either
messages between tasks and other interacting agents or communication be-
tween tasks of the same agent. The latter are not speech acts, but rather signals
addressing the necessity of beginning an elaboration, that is, triggering a task
execution or delegating another task to do something. In order to yield an agent’s
T.Sp. diagram, we need to look at all of the agent’s R.Id. diagrams (i.e., all of
the scenarios in which it participates). We then explore all of the interactions and
internal actions that the agent performs to accomplish a scenario’s purpose.
From each R.Id. diagram, we obtain a collection of related tasks. Grouping them
all together appropriately then results in the T.Sp. diagram.
Because drawing a Task Specification diagram for each agent would require too
much space in this chapter, we proceed from now on by focusing on a single
agent: the Purchase Manager. In Figure 6, we can see its T.Sp. diagram. In this
TEAM LinG
92 Cossentino
Figure 6. The tasks of the purchase manager agent
Other agents Purchase Manager agent
PurchaseMonitor.RequestBooks ReceiveDelivery
Notification
Listener
StoreUI.NotifyDelivery
ReceivePurchase
Request
PurchaseAdvisor.Listener
AskForAdvice StartPurchase
AskNegotiation
Purchaser.Listener
AskOrdering
UpdatePurchase
History
NotifyEndOfPurchase
example, we suppose that a Listener task is needed in order to forward incoming

communication to the proper task; this is common in many MAS platforms (for
example, in FIPA-OS [Poslad, Buckle, & Hadingham, 2000]), while this is not
necessary in some others. We decided to present this situation because all the
others can be reduced to this one. Further tasks are needed to handle all the
incoming messages of the R.Id. scenario (see ReceivePurchaseRequest and
ReceiveDeliveryNotification tasks in Figure 6 that correspond to the R.Id.
messages coming from the Purchase Monitor and StoreUI agents, respec-
tively, in Figure 5). Likewise, a task is introduced for each outgoing message (or
series of messages that could be unified in one communication) of the R.Id.
scenario (see AskForAdvice, AskNegotiation, AskOrdering,
UpdatePurchaseHistory, and NotifyEndOfPurchase in Figure 6). In this way,
we dedicate one task to deal with each communication and, if necessary, with
minor other duties (for example, simple elaboration of received data). If a
relevant activity follows/prepares the incoming/outgoing communication, extra
tasks may be introduced to face a better decomposition of the agent (see
StartPurchase task in Figure 6).
TEAM LinG
Ontology Description Phase
In the PASSI methodology, the design of ontology is performed in the Domain

Ontology Description (D.O.D.) Phase and a class diagram is used. Several
works can be found in the literature about the use of UML for modeling ontology
(Bergenti & Poggi, 2000, Cranefield & Purvis, 1999). Figure 7 reports an
example of a PASSI D.O.D. diagram; it describes the ontology in terms of
concepts (categories, entities of the domain), predicates (assertions on proper-
ties of concepts), actions (performed in the domain), and their relationships. This
diagram represents an XML schema that is useful to obtain a Resource
Description Framework (RDF) encoding of the ontological structure. We have
adopted RDF to represent our ontologies, since it is part of both the W3C (1999)
and FIPA (2001) specifications.
Elements of the ontology are related using three UML standard relationships:
• Generalization, which permits the “generalize” relation between two

entities, which is one of the essential operators for constructing an ontology;
• Association, which models the existence of some kind of logical relation-
ship between two entities and allows the specification of the role of the
involved entities in order to clarify the structure; and
• Aggregation, which can be used to construct sets where value restrictions
can be explicitly specified; this originates from the W3C RDF specification
where three types of container objects are enumerated, namely the bag (an
unordered list of resources), the sequence (an ordered list of resources),
and the alternative (a list of alternative values of a property), and is
therefore not UML-compliant.
The example in Figure 7 shows that each Purchase is related to a

SuccessfulNegotiation, a predicate that reports if an order has been issued
(attribute orderIssued is true in this case) as a consequence of a negotiation. It
includes a request from the library (ourRequest) for a specific Stock and an
offer from the supplier (theirBestOffer) for that Stock. Delivery is an example
of action—it describes the activity done by the Supplier of delivering to the
Storekeeper some books listed in an ordered stock.
The Communication Ontology Description (C.O.D.) diagram (Figure 8) is a
representation of the agents’ (social) interactions; this is a class diagram that
shows all agents and all their interactions (lines connecting agents). In designing
this diagram, we start from the results of the A.Id. (Agent Identification) phase.
A class is introduced for each identified agent, and an association is then
TEAM LinG
94 Cossentino
introduced for each communication between two agents (ignoring, for the
moment, distinctions about agents’ roles). Clearly, it is also important to
introduce the proper data structure (selected from elements of the Domain
Ontology Description) in each agent in order to store the exchanged data. The
association line that represents each communication is drawn from the initiator
of the conversation to the other agent (participant) as can be deduced from the
description of their interaction performed in the Role Identification (R.Id.)
phase. According to FIPA standards, communications consist of speech acts
(Searle, 1969) and are grouped by FIPA in several interaction protocols that
define the sequence of expected messages. As a consequence, each communi-
cation is characterized by three attributes, which we group into an association
class. This is the characterization of the communication itself (a communication
Figure 7. The domain ontology diagram
<<concept>>
GoingOnPurchases
+AnOpenPurchase 0..*
<<concept>> <<concept>>
Purchase +PurchaseInfo OpenPurchase
+CourseInfo date : Date remainingStocksToNegotiate : Stocks
<<concept>> 1
Course
courseTitle : String +ANegotiation +StocksToNegotiate
1..*
teacherName : String
numberOfAttendees : Integer <<predicate>> <<concept>>
SuccessfulNegotiation Stocks
orderIssued : Boolean
+textBook 1
<<concept>>
Book
authors : String <<concept>>
title : String SuppliersArchive
edition : String
publisher : String
1..*
+ourRequest
+textBook 1..* +theirBestOffer +ASupplier
+AStock 1..*
<<concept>> <<concept>>
<<action>>
Stock +Stock Supplier
Delivery
1 numberOfItems : Integer Supplier name : String
Actor = Supplier
unitPrice : Integer email : String
Receiver = StoreKeeper +OrderedStock purchaseTime : Date 1 fax : String
deliveryTime : Date phone : String
<<act>> delivery()
+SupplyingStock
<<predicate>>
IsStockSufficient
ACourse : Course
TEAM LinG
Figure 8. The communication ontology diagram
PurchaseAdvisor PurchaseDetails
CourseData QueryForAdvise _past_purchases : History Ontology : Purchase
Ontology : Course Protocol : Query Language : RDF
Language : RDF +Recorder Protocol : Propose
+Consultant
+BooksProvider
+BooksProvider DeliveryNotification
PurchaseAnnouncement
Ontology : Delivery
Protocol : Request PurchaseManager
Language : RDF
_open_purchases : GoingOnPurchases Protocol : Propose
_suppliers_list : Suppliers
+BooksProvider
PurchaseMonitor
+BooksProvider +DeliveryNotifier
_course_info : Course +Informer +BooksProvider
+Books Provider StoreUI
_delivery_details : Delivery
+Negotiator +OrderPlacer
OurRequest
Purchaser
Protocol : Query StockToPurchase
_our_request : Stock
_their_best_offer : Stock Protocol : Propose
StockInfo
Ontology : Stock
Language : RDF
with different ontology, language, or protocol is certainly different from this one)
and its knowledge is used to uniquely refer this communication (which can have,
obviously, several instances at runtime, since it may arise more than once). Roles
played by agents in the interaction (as derived from the R.Id. diagrams) are
reported at the beginning and the end of the association line.
In Figure 8, the PurchaseManager agent starts a conversation (see
QueryForAdvice association class) with the PurchaseAdvisor agent. The
conversation contains the Course ontology, the Query protocol, and the RDF
language. This means that the PurchaseManager wants to perform a speech
act based on the FIPA’s query protocol in order to ask the PurchaseAdvisor for
advice on how to purchase (supplier, number of stocks, number of items per each,
purchase-money) provided the Course information.
Roles Description Phase
This phase models the lifecycle of an agent taking into account its roles, the
collaborations it needs, and the conversations in which it is involved. In this phase,
we can also introduce the social rules of the society of agents (organizational
rules) (Zambonelli, Jennings, & Wooldridge, 2001) and the behavioral laws as
TEAM LinG
96 Cossentino
considered by Newell (1982) in his “social level.” These laws may be expressed
in OCL or other formal or semi-formal manner depending on our needs.
The Roles Description (R.D.) phase yields a class diagram in which classes are
used to represent roles (the UML syntax and notation is here modified slightly
in order to represent agents’ related concepts). Each agent is symbolized by a
package containing its roles’ classes (see Figure 9). Each role is obtained by
composing several tasks in a resulting behavior. In order to show which tasks are
necessary to compose the desired behavior, in this diagram, we put tasks in the
operation compartment of the related role’s class. Each task is related to an
action or a set of actions, and therefore the list of tasks describes what a role is
able to do; it can also be helpful in the identification of reusable patterns. An R.D.
diagram can also show connections between roles of the same agent, represent-
ing changes of role (dashed line with the name [ROLE CHANGE]). This
connection is depicted as a dependency relationship because we want to signify
the dependency of the second role on the first. Sometimes the trigger condition
is not explicitly generated by the first role, but its precedent appearance in the
scenario justifies the consideration that it is necessary to prepare the situation
that allows the second role to start. Conversations between roles are indicated
by solid lines, as we did in the Communication Ontology Diagram, using exactly
the same relationships names; this consistency, like other quality aspects of
Figure 9. The roles description diagram for our scenario
<<Agent>>
Purchase Monitor
Informer : PurchaseMonitor
<<Agent>>
Purchase Advisor RequestBooks() <<Agent>>
LookForChanges() Purchaser
Consultant : PurchaseAdvisor
PurchaseAnnouncement
IdleTask() OurRequest Negotiator : Purchaser
(service)
ReceiveAdviceRequest()
QueryOnHistory() <<Agent>> IdleTask()
Purchase Manager ReceiveNegotiationRequest()
QueryForAdvice Negotiate()
BooksProvider : PurchaseManager
(resource)
(resource)
[ROLE CHANGE] IdleTask()
[ROLE CHANGE]
ReceivePurchaseRequest()
StartPurchase()
AskForAdvise()
StockToPurchase
PurchaseDetails StartNegotiation() OrderPlacer : Purchaser
StartOrdering() (service)
Recorder : PurchaseAdvisor
ReceiveDeliveryNotification() IdleTask()
NotifyEndOfPurchase() ReceiveOrderingRequest()
IdleTask() UpdatePurchaseHistory() Order()
ReceiveRecordingRequest()
UpdateHistory()
DeliveryNotification
<<Agent>>
Store UI
DeliveryNotifier : StoreUI
NotifyDelivery()
TEAM LinG
design, is ensured by the use of PTK (PASSI ToolKit, an open source add-in for
Rational RoseTM) that automatically builds portions of several diagrams and
performs several checks on the inputs provided by the designer to verify their
correctness with regards to the other parts of the design.
We have also considered dependencies between agents (Yu & Liu, 2000).
Agents are autonomous, so they could refuse to provide a service or a resource.
For this reason, the design needs a schema that expresses such matters so as to
explore alternative ways to achieve the goals. In order to realize such a schema,
we have introduced in the Roles Description diagram some additional relation-
ships that express the following kinds of dependency:
• Service dependency: a role depends on another to bring about a goal

(indicated by a dashed line with the service name).
• Resource dependency: a role depends on another for the availability of an
entity (indicated by a dashed line with the resource name).
Protocols Description Phase
As we have seen in the Ontology Description phase and as specified by the FIPA
architecture, an Agent Interaction Protocol has been used for each communica-
tion. In our example, all of them are FIPA standard protocols (FIPA, 2000).
Usually the related documentation is given in the form of AUML sequence
diagrams (Odell, Van Dyke Parunak, & Bauer, 2001). Hence, the designer does
not need to specify protocols on his own. In some cases, however, existing
protocols are not adequate and, subsequently, some dedicated ones need to be
properly designed; this can be done using the AUML diagrams.
Agents Structure Definition Phase
As argued in subsection “Iterations,” this phase influences and is influenced by

the Agent Behavior Description phase as a double level of iteration occurs
between them. The Agent Structure Definition phase produces several class
diagrams logically subdivided into two views: the multi-agent and the single-
agent views. In the former, we call attention to the general architecture of the
system and so we can find agents and their tasks. In the latter, we focus on each
agent’s internal structure, revealing all the attributes and methods of the agent
class together with its inner tasks’ classes (the FIPA-platform classes that will
be coded).
TEAM LinG
98 Cossentino
Figure 10. The multi-agent structure definition diagram for the bookstore
case study
<<Agent>>
ChiefUI
NSM Courses W eb Server <<Agent>> Chief <<Agent>>

PurchaseManager ClerkUI
<<Agent>>
IdleTask() Purchaser
<<Agent>>
PurchaseMonitor ReceivePurchaseRequest()
StartPurchase() IdleTask()
AskForAdvise() ReceiveNegotiationRequest()
RequestBooks()
StartNegotiation() Negotiate()
LookForChanges()
StartOrdering() ReceiveOrderingRequest()
ReceiveDeliveryNotification() Order()
Clerk
NotifyEndOfPurchase()
UpdatePurchaseHistory()
<<Agent>> <<Agent>>
Archive PurchaseAdvisor
<<Agent>>
ShopUI IdleTask()
ReceiveAdviceRequest() Supplier
<<Agent>> QueryOnHistory()
W ebUI ReceiveRecordingRequest()
UpdateHistory()
<<Agent>>
StoreUI
NotifyDelivery()
NSM Student Book Store Employee Storekeeper
Multi-Agent Structure Definition (MASD)
At this stage, one diagram represents the MAS as a whole (Figure 10). The
diagram shows classes, each symbolizing one of the agents identified in the A.Id.
phase. Actors are reported in order to represent significant agents’ interactions
with the environment (for instance through sensing devices or actuators).
Attributes compartments can be used to represent the knowledge of the agent
as already discussed in the Communication Ontology diagram, whereas opera-
tions compartments are used to signify the agent’s tasks.
Single-Agent Structure Definition (SASD)
Here one class diagram (Figure 11) is used for each agent to illustrate the agent’s
internal structure through all of the classes making up the agent, which are the
TEAM LinG
Figure 11. The single-agent structure definition diagram for the purchase
manager agent
AskForAdv ice
Receiv ePurchaseRequest
PurchaseManager - _course_inf o : Course
- _course_inf o : Course StartPurchase - _receiv ed_adv ice : Stocks StartNegotiation
- purchaseInf ormation
- time - _our_request : Stock
+ Receiv ePurchaseRequest() + StartPurchase() + AskForAdv ice() - _their_best_of f er : Stock
- negotiatingConditions + startTask() + startTask() + startTask()
- negotiatedConditions + doneAskForPurchaseAdv () + AskForPurchaseAdv ()
- deliv ery Data + StartNegotiation()
+ handleAdv ice() + startTask()
+ AGENT_TYPE : String = "Purchase Manager" + doneAskNegotiation() + handleTheirBestOf f er()
+ PurchasesManager()
+ registrationFailed()
+ registrationRef used() IdleTask StartOrdering
+ registrationSucceded() - _stock_to_purchase : Stock
Task
+ shutdown() + IdleTask()
+ startTask() + StartOrdering()
+ handleRequest() + startTask()
UpdatePurchaseHistory Receiv eDeliv ery Notif ication

FIPA_Agent
Notif y EndOf Purchase - _deliv ery _details : Deliv ery
- _purchase_to_record : Purchase
+ UpdatePuchaseHistory () + Notif y EndOf Purchase() + Receiv eDeliv ery Notif ication()

+ startTask() + startTask() + startTask()
agent’s main class together with the inner classes identifying its tasks. At this
point, we set up attributes and methods of both the agent class (e.g., the
constructor and the shutdown method when required by the implementation
platform) and the tasks’ classes. The result of this stage is to obtain a detailed
structure of the software, ready to be implemented almost automatically.
Agents Behavior Description Phase
As was seen in the previous phase, this phase influences and is influenced by the
Agent Structure Definition phase in a double level of iterations. The Agent
Behavior Description phase produces several diagrams that are subdivided into
the multi-agent and the single-agent views. In the former, we draw the flow of
events (internal to agents) and communications (among agents) by representing
method invocations and the message exchanges. In the latter, we detail the above
methods.
Multi-Agent Behaviour Description (MABD)
At this stage, one or more activity diagrams are drawn to show the flow of events
between and within both the main agent classes and their inner classes
(representing their tasks). We depict one swimlane for each agent and for each
task. The activities inside the swimlanes indicate the methods of the related
class. Unlike DeLoach, Wood, and Sparkman (2001), we need not introduce a
specific diagram for concurrency and synchronization since UML activity
diagrams’ syntax already supports it.
TEAM LinG
100 Cossentino
The usual transitions of the UML standard are depicted here as signifying either
events (e.g., an incoming message or a task conclusion) or invocation of
methods. A transition is drawn for each message recognized in the preceding
phases (e.g., from the R.Id. diagram). In this kind of transition, we indicate the
message’s performative as it is specified in the Communication Ontology
Description diagram and the message’s content as described in the Domain
Ontology Description diagram. This results in having a comprehensive descrip-
tion of the communication including the exact methods involved.
Figure 12 shows an example of a multi-agent behavior description. The
StartPurchase task of the PurchaseManager agent instantiates the
StartNegotiation task by invoking the newTask super-class method. This has
to be done in order to ask the Purchaser agent to perform a negotiation with a
supplier. The invocation of the StartNegotiation task implies its startTask
method to be invoked (according to the FIPA-OS implementation platform we
have used). What the startTask method does is send a message to the
Purchaser agent. This contains the Request performative (as required by the
FIPA Request protocol) and the content OurRequest (coming from the D.O.D.
diagram, Figure 7). The handleRequest method of the Purchaser’s IdleTask
task receives the incoming communication and sends it to the
ReceiveNegotiationRequest task after this one has been instantiated as above.
When a task completes its job, the done method is invoked.
This kind of diagram often becomes very huge and difficult to draw/read. In
order to deal with this problem, an extended version of it has been presented in
Caire et al. (2004) where the revised syntax supports different levels of detail.
Figure 12. An example of multi-agent behaviour description diagram

PurchaseManager.StartPurchase Purch aseManag er.StartN eg otiation Purchaser.Id leTask Pu rchaser.R eceiveNegotiation Request Purchaser:N egotiate
StartPurchase.
StartPurchase newT ask( Neg oti ate )
StartNegotiation.
StartNegotiation
StartNegotiation. m essage( OurRe quest; q uery-i f )

startTask IdleTask.
handleRequest newT ask( Recei veNego ti atio nReque st )
ReceiveNegotiationRequest.
ReceiveNegotiationRequest
ReceiveNegotiationRequest.
startTask newT ask( Neg oti ate )
Negotiate.
Negotiate
Negotiate.
message( Ou rReque st; i nform ) startTask
StartNegotiation
.handleInform do ne()
StartP urchase.done ReceiveNegotiationRequest.
d one()
AskNegotiation doneNegotiate
TEAM LinG
Single-Agent Behaviour Description (SABD)
This phase is quite a common one as it involves implementation of methods,

exactly the ones introduced in the SASD diagrams. Designers are free to
describe them in the most appropriate way (for example, using flow charts, state
diagrams, or semi-formal text descriptions).
Code Reuse Phase
In this phase, we try to reuse predefined patterns of agents and tasks. With the
term pattern, we do not only mean code but also design diagrams. As a matter
of fact, the reuse process typically takes place in some CASE tool environment,
where the designer looks more at diagrams detailing a pattern’s libraries than
rough code. So we prefer to look at patterns as pieces of design and code to be
reused in the process of implementing new systems.
We have extended the Rational Rose UML CASE tool by developing an add-in
supporting PASSI (PTK) and a specific pattern reuse application (AgentFactory).
PTK and AgentFactory are complementary and responsible for two different
stages of the design-implementation activities: initially, PTK helps in compiling
the PASSI diagrams, then AgentFactory is used to generate the agents’ code
when patterns have been used in the design. PTK initial releases were able to
generate agents’ code, but this duty has been, more recently, assigned to the
AgentFactory application. It works in this way: the PTK (PASSI ToolKit) add-
in can export the multi-agent system model to AgentFactory or generate the code
for just the skeletons of the designed agents, behaviors, and other classes
included in the project. AgentFactory code generation capabilities (Cossentino,
Sabatucci, Sorace, & Chella, 2003) are much more advanced than similar
functions of PTK; AgentFactory can, very quickly, create complex multi-agent
systems by using patterns from a large repository and can also provide the design
documentation of the composed agents. The tool can work online as a Web-
based application, but can also be used as a stand-alone application. This
approach has proven quite flexible (Cossentino, Sabatucci, & Chella, 2003) in
reusing patterns, thanks to its binding of design elements to code.
Due to the most common FIPA-compliant implementation platforms that del-
egate a specific task for each specific communication, it has turned out that in
our applications, which are mainly JADE or FIPA-OS based, some of the most
useful patterns are the ones that could be categorized as interaction patterns.
Our patterns (whose discussion is out of the scope of this chapter) result from
the composition of three different aspects of a multi-agent system:
TEAM LinG
102 Cossentino
1. the static structure of one or more agent(s) or parts of them (i.e. behaviors);
2. the description of the dynamic behavior expressed by the previously cited
elements; and
3. the program code that realizes both the static structure (skeletons) and the
dynamic behavior (inner parts of methods) in a specific agent platform
context (for example JADE).
In reusing patterns from our repository, the designer can select the generic
agent pattern (that has the capability of registering itself to the basic platform
services), and he/she can introduce it in the actual project. In this way, with a few
mouse clicks, he/she created a totally new agent, the design diagram has been
updated (although with some limitations due to the actual level of integration
between Rational Rose and AgentFactory), and the agent’s code is properly
functional.
The repository also includes a list of behaviors that can be applied to existing
agents. For example, we have behaviors dedicated to deal with the initiator/
participant roles in the most common communications. When a pattern is
introduced in the design, not only are some diagrams (like the structural and
behavioral one of the implementation level) updated. but the resulting code also
contains large portions of inner parts of methods; the result is a highly affordable
and quick development production process.
Code Completion Phase
This phase is the classical work of the programmer, who just needs to complete
the body of the methods yielded to this point, by taking into account the design
diagrams.
Deployment Configuration Phase
The Deployment Configuration (D.C.) phase has been thought to comply with
the requirements of detailing the agents’ positions in distributed systems or more
generally in mobile-agents’ contexts.
The Deployment Configuration diagram is a UML deployment diagram and
illustrates the location of the agents (the implementation platforms and process-
ing units where they live), their movements, and their communication support.
The standard UML notation is useful for representing processing units (by
boxes), agents (by components), and the like. What is not supported by UML is
the representation of the agent’s mobility, which we have done by means of a
TEAM LinG
syntax extension consisting of a dashed line with a move_to stereotype connect-

ing an agent reported in both its initial and final positions.
Discussion
Methodologies differ in commitments about the target agent architecture.
PASSI is a requirement-to-code analysis and design methodology characterized
by an iterative step-by-step refinement of the system, producing at its final stage
a concrete design and implementation based on the FIPA architecture. Gaia, by
contrast, regards the output of the analysis and design process as an abstract
specification that necessitates being further developed by extra lower-level
design methodologies. So does MaSE, but, on the other hand, it goes further in
the design process if compared with Gaia. Now, one might think that a general
approach such as Gaia is more advantageous, given the present proliferation of
agent technologies. However, PASSI does not lead to a narrow scope concrete
technology but rather actually yields executable code for a concrete and
increasingly utilized standard architecture such as FIPA.
A key issue in modeling multi-agent system is the conversation among agents.
In order to obtain a proper model of conversation, it would be desirable to have
an ontology description of the system. Excluding PASSI, none of the other
methodologies compared throughout this book specifically addresses such a
matter (to be more precise, Dileo, Jacobs, and DeLoach [2002] have recently
proposed a method to introduce ontology in MaSE). The PASSI Ontology
Description phase describes the society of agents taking into account its
ontological point of view. As counterpart, in MaSE, there is a detailed description
of conversations by means of complementary state automata (couples of
Communication Class Diagram) representing agents’ state involved in commu-
nication. Together, the complementary sides of conversation make up a protocol
definition. As for Gaia, a definition of protocols is provided in the Interaction
Model.
Conclusion and Further Work

The methodology proposed here has proved successful with multi-agent and
distributed systems, both in robotics and information systems. It has been used
in several research projects and in the Software Engineering course at the
University of Palermo for final assignments. Students and researchers appreci-
TEAM LinG
104 Cossentino
ated the step-by-step guidance provided by the methodology and have found it
rather easy to learn and to use. Among the most appreciated features, we can
list: (1) the ease of transition for designers coming from the object-oriented
world, since the initial parts of PASSI adopt concepts of requirements analysis
that are very common in that context; (2) the multiple views that permit an easy
analysis of complex systems from many different aspects; (3) the support of a
specific design tool (PTK, an add-in for Rational Rose), and (4) the patterns
reuse that allows a rapid development of MASs. The implementation environ-
ments that we have used were based on the FIPA architecture in accordance
with the aim of adopting standards whenever possible. We are now working on
the enhancement of the CASE tool supporting PASSI and on the enlargement of
the pattern repository in order to further increase the productivity of the PASSI
developer.
References
Andersen, E. (1997). Juul Møller Bokhandel A/S. Norwegian School of
Management. Available online http://www.espen.com/papers/jme.pdf
Antón, A.I. & Potts, C. (1998). The use of goals to surface requirements for
evolving systems. In Proceedings of International Conference on
Software Engineering (ICSE ’98) (pp. 157-166).
Aridor, Y. & Lange, D.B. (1998). Agent design patterns: Elements of agent
application design. In Proceedings of the Second International Confer-
ence on Autonomous Agents (pp. 108-115).
Bergenti, F. & Poggi A. (2000). Exploiting UML in the design of multi-agent
systems. In Proceedings of First International Workshop Engineering
Societies in the Agents World.
Bernon, C., Camps, V., Gleizes, M-P., & Picard, G. (2004). Tools for self-
organizing applications engineering. In Proceedings of the First Interna-
tional Workshop on Engineering Self-Organising Applications (ESOA).
Springer-Verlag.
Bresciani, P., Giorgini, P., Giunchiglia, F., Mylopoulos, J., & Perini, A. (2004).
TROPOS: An agent-oriented software development methodology. Jour-
nal of Autonomous Agents and Multi-Agent Systems, 8(3), 203-236.
Caire, G., Cossentino, M., Negri, A., Poggi, A., & Turci, P. (2004). Multi-agent
systems implementation and testing. In Proceedings of the Agent Tech-
nology to Agent Implementation Symposium (AT2AI-04).
TEAM LinG
Chella, A., Cossentino, M., & Lo Faso, U. (2000). Designing agent-based

systems with UML. In Proceedings of International Symposium on
Robotics and Automation ISRA2000.
Cossentino, M., Sabatucci, L., & Chella, A. (2003). A possible approach to the
development of robotic multiagent systems. In Proceedings of IEEE/WIC
IAT’03 Conference.
Cossentino, M., Sabatucci, L., Sorace, S., & Chella, A. (2003). Patterns reuse
in the PASSI methodology. Fourth International Workshop Engineer-
ing Societies in the Agents World.
Cranefield, S. & Purvis, M. (1999). UML as an ontology modelling language. In
Proceedings of the Workshop on Intelligent Information Integration at
16th International Joint Conference on Artificial Intelligence (IJCAI-
99).
DeLoach, S. A., & Wood, M. (2001). Developing multi-agent systems with
agentTool. Intelligent Agents VII - Proceedings of the 7th International
Workshop on Agent Theories, Architectures, and Languages
(ATAL2000). Springer Lecture Notes in AI. Berlin: Springer Verlag.
DeLoach, S.A., Wood, M.F., & Sparkman, C.H. (2001). Multi-agent systems
engineering. International Journal on Software Engineering and Knowl-
edge Engineering, 11(3), 231-258.
DiLeo, J., Jacobs, T. & DeLoach, S. (2002). Integrating ontologies into multi-
agent systems engineering. In Proceedings of the Fourth International
Conference on Agent-Oriented Information Systems (AIOS-2002).
FIPA. (2000). Communicative Act Library Specification. FIPA Document
#FIPA00037. Available online http://www.fipa.org/specs/fipa00037/
FIPA. (2001). FIPA RDF Content Language Specification. FIPA Document
FIPA XC00011B. Retrieved from http://www.fipa.org/specs/ fipa00011/
XC00011B.html
Jackson, M. (2001). Problem frames: Analyzing and structuring software
development problems. Reading, MA: Addison Wesley.
Jacobson, I., Christerson, M., Jonsson, P., & Overgaard, G. (1992). Object-
oriented software engineering: A use case driven approach. Reading,
MA: Addison-Wesley.
Jennings, N.R. (2000). On agent-based software engineering. Artificial Intel-
ligence, 117, 277-296.
Kendall, E. A., Krishna, P. V. M., Pathak, C. V., & Suresh, C. B. (1998).
Patterns of intelligent and mobile agents. In Proceedings of the Second
International Conference on Autonomous Agents (pp. 92-99).
TEAM LinG
106 Cossentino
Newell, A. (1982). The knowledge level. Artificial Intelligence, 18, 87-127.

O’Brien, P. & Nicol, R. (1998). FIPA - Towards a standard for software agents.
BT Technology Journal, 16(3), 51-59.
Odell, J., Van Dyke Parunak, H., & Bauer, B. (2001). Representing agent
interaction protocols in UML. In Agent-Oriented Software Engineering
(pp. 121-140). Berlin: Springer-Verlag.
OMG. (2003a). Software Process Engineering Metamodel Specification. Ver-
sion 1.0.
OMG. (2003b). Unified Modeling Language Specification. Version 1.5.
Poslad S., Buckle, P., & Hadingham, R. (2000). The FIPA-OS agent platform:
Open source for open standards. In Proceedings of the 5th International
Conference and Exhibition on the Practical Application of Intelligent
Agents and Multi-Agents (pp. 355-368).
Potts, C. (1999). ScenIC: A strategy for inquiry-driven requirements determina-
tion. In Proceedings of IEEE Fourth International Symposium on
Requirements Engineering (RE’99) (pp. 58-65).
Robbins, J., Medvidovic, N., Redmiles, D., & Rosenblum, D. (1998). Integrating
architecture description languages with a standard design method. In
Proceedings of the Twentieth International Conference on Software
Engineering (ICSE ’98) (pp. 209-218).
Searle, J.R. (1969). Speech acts. Cambridge, UK: Cambridge University Press.
SPEM (2002). Software Process Engineering Metamodel Specification. Ver-
sion 1.0. OMG document 02-11-04.
W3C. (1999). Resource Description Framework. (RDF), Model and Syntax
Specification. W3C Recommendation 22-02-1999. Available online http:/
/www.w3.org/TR/1999/REC-rdf-syntax-19990222/
Wooldridge, M. & Ciancarini, P. (2001). Agent-oriented software engineering:
The state of the art. In P. Ciancarini & M. Wooldridge (Eds.), Agent-
oriented software engineering, No.1957 in LNCS (pp. 1-28). Berlin:
Springer-Verlag.
Yu, E. & Liu, L. (2000). Modelling trust in the i* strategic actors framework. In
Proceedings of the 3rd Workshop on Deception, Fraud and Trust in
Agent Societies at Agents 2000.
Zambonelli, F., Jennings, N., & Wooldridge, M. (2001). Organizational rules as
an abstraction for the analysis and design of multi-agent systems. Journal
of Knowledge and Software Engineering, 11(3), 303-328.
Zambonelli, F., Jennings, N., & Wooldridge, M. (2003). Developing multiagent
TEAM LinG
Prometheus: A Practical Agent-Oriented Methodology 107
Chapter V
Prometheus:
A Practical Agent-Oriented
Methodology
Lin Padgham
RMIT University, Australia
Michael Winikoff
RMIT University, Australia
Abstract
We present the Prometheus methodology for designing agents and multi-

agent systems. The methodology is intended to be practical; in particular,
it aims to be complete and detailed, and to be usable by industrial software
developers and undergraduate students. We present the methodology using
a case study, describe existing tools that support both design and
implementation, and report on experiences with using Prometheus, including
our experiences in teaching Prometheus to an undergraduate class over the
past few years. These experiences provide evidence that Prometheus is
usable by its intended target audience.
TEAM LinG
108 Padgham & Winikoff
Introduction
“One of the most fundamental obstacles to the take-up of agent
technology is the lack of mature software development methodolo-
gies for agent-based systems” (Luck, McBurney, & Preist, 2004, p.
224).
It is widely accepted in the agent research community that a key issue in the
transition of agents from research labs to industrial practice is the need for a
mature software engineering methodology for specifying and designing agent
systems. In this chapter, we describe the Prometheus1 methodology that aims to
address this need.
In developing the Prometheus methodology, there are a number of motivating
considerations that have influenced (and continue to influence) the evolution of
Prometheus and the choices made in its development.
• First and foremost, Prometheus is intended to be a practical methodology.

As such, it needs to be both complete and detailed. Prometheus has to be
sufficiently complete in that it must cover a range of activities from
requirements specification through to detailed design; and it has to be
sufficiently detailed in that it must provide detailed guidance on how to
perform the various steps that form the process of Prometheus.
• Prometheus needs to support (but not be limited to) the design of agents that
are based on goals and plans. We believe that a significant part of the
benefits that can be gained from agent-oriented software engineering
comes from the use of goals and plans to realise agents that are flexible and
robust.
• The methodology should facilitate tool support, and tool support should be
(freely) available.
• Prometheus needs to be usable by industrial software developers and
undergraduate students, not researchers and post-graduate students. In
particular, it is important that these groups use the methodology and that
their experiences and feedback help guide the development and improve-
ment of the methodology.
These features of Prometheus distinguish it from existing methodologies such as

those described in the other chapters of this book, as well as, for example,
Brazier, Dunin-Keplicz, Jennings, and Treur (1997); Burmeister (1996); Bush,
Cranefield, and Purvis (2001); Collinot, Drogoul, and Benhamou (1996); Drogoul
TEAM LinG
and Zucker (1998); Elammari and Lalonde (1999); Glaser (1996); Kendall,
Malkoun, and Jiang (1995); Kinny and Georgeff (1996); Kinny, Georgeff, and
Rao (1996); Lind (2001); Sturm, Dori, and Shehory (2003); and Varga, Jennings,
and Cockburn (1994). We shall not attempt to compare Prometheus to existing
methodologies in this chapter; comparisons of Prometheus with other method-
ologies can be found in Dam (2003); Dam and Winikoff (2003); and Sudeikat,
Braubach, Pokahr, and Lamersdorf (2004). Other comparisons of agent-
oriented methodologies include Cernuzzi and Rossi (2002); Shehory and Sturm
(2001); Sturm and Shehory (2003), and, of course, Chapter 12 of this book.
In the remainder of this chapter, we describe the Prometheus methodology
incorporating a case study, and then discuss the strengths and weaknesses of
Prometheus before concluding. Our description of Prometheus is necessarily
brief – for a full description see Padgham and Winikoff (2004).
The Prometheus Methodology

Before we present Prometheus, it is important to consider the question “what is
a methodology?” This is not just an academic exercise: if we view a methodology
as consisting purely of notations for describing designs or as consisting only of
a high-level process, then we end up with a very different result.
We adopt a pragmatic stance; rather than debating what should and should not
be considered part of a methodology, we simply include in Prometheus every-
thing that we think is necessary. In particular, the Prometheus methodology
includes a description of concepts for designing agents, a process, a number of
notations for capturing designs, as well as many “tips” or techniques that give
advice on how to carry out the steps of Prometheus’ process – in accordance
with the more generic definitions in Chapter 1.
Since design is a human activity that is inherently about tradeoffs, rather than
about finding the single best design (which often does not exist), it is not possible
to provide hard and fast rules. However, it is important to provide detailed
techniques and guidelines for carrying out steps.
We would like to stress that Prometheus is a general purpose methodology.
Although the detailed design phase makes some assumptions about the agent
architecture, the rest of the methodology does not make these assumptions. It is
not possible to provide a detailed methodology that proceeds to detailed design
and towards implementation without making some assumptions. For example,
Tropos, like Prometheus, also targets systems that are based on the Belief Desire
Intention (BDI) model.
TEAM LinG
Agent Concepts
Before we proceed to present the process, notations, and techniques that are
associated with the Prometheus methodology, we summarize the concepts used
here (Winikoff, Padgham, & Harland, 2001) (see also Chapter 1).
The reason why it is important to consider and discuss concepts is that the
concepts are the foundation upon which a software engineering methodology
builds. For instance, object-oriented methodologies assume that the designer is
familiar with concepts such as objects, classes, and inheritance. The concepts
that are appropriate for designing agents are, not surprisingly, different from
those that are used for objects. Whereas the concepts of object-oriented
programming are well-known, those associated with agent-oriented program-
ming are not, and so we feel that it is useful and important to discuss them.
In considering what concepts are appropriate for designing agent systems, we
take as a starting point the definition of an intelligent agent. We take the standard
definition of an agent as being software that is situated in an environment,
autonomous, reactive to changes in its environment, proactive in its pursuit of
goals and social (Wooldridge, 2002). We extend this definition by adding to the
list of desired properties of agents being flexible (having multiple ways of
achieving goals) and robust (being able to deal with various forms of failure)
(Padgham & Winikoff, 2004).
Based on these properties, we identify a number of concepts that are used to
design and implement agents. An agent’s interface with its environment is
expressed in terms of percepts and actions. Proactive agents pursue goals, and
reactive agents respond to events (“significant occurrences”). Agents have
beliefs and plans. Finally, social agents use messages to communicate, and
these messages are collected in interaction protocols.
Our experience with teaching agent concepts has been that the concept set
discussed is sufficient to design BDI style agent systems and also easier to
understand than, for example, the standard BDI concepts (particularly inten-
tions).
Prometheus, as a methodology, is intended to be able to support the design of BDI
systems, although it is not limited to such; all but the lowest level of design, leading
into code, can be used equally well for non-BDI systems. However, the lowest
level needs to be modified to accommodate the particular style of implementation
platform being targeted. For instance, if building JADE agents, the lowest level
would specify behaviours rather than plans, and there would be some changes
in details.
TEAM LinG
Overview of the Prometheus Methodology
We now turn to consideration of the overall structure of the Prometheus

methodology. The Prometheus methodology consists of three phases (see
Figure 1):
• System Specification: where the system is specified using goals and use
case scenarios; the system’s interface to its environment is described in
terms of actions, percepts, and external data; and functionalities are
defined.
• Architectural design: where agent types are identified; the system’s overall
structure is captured in a system overview diagram; and use case scenarios
are developed into interaction protocols.
• Detailed design: where the details of each agent’s internals are developed
and defined in terms of capabilities, data, events, and plans; process
diagrams are used as a stepping stone between interaction protocols and
plans.
Figure 1. The phases of the Prometheus methodology

Architectural Specification
Scenarios Goals Functionalities Actions &

Percepts
Data Coupling &

Interaction Agent Acquaintance
Diagrams
Design
Interaction Agent System

Protocols Descriptors Overview
Processes Capability Agent

Descriptors Overview
Detailed
Design
Plan Data Event Capability

Descriptors Descriptors Descriptors Overview
TEAM LinG
Each of these phases includes models that focus on the dynamics of the system,
(graphical) models that focus on the structure of the system or its components,
and textual descriptor forms that provide the details for individual entities.
In the following sections, we briefly describe the processes and models associ-
ated with each of the three phases, as well as discussing some specific
techniques. Due to space limitations and the desire to describe all of the
methodology, this chapter cannot present all of Prometheus in complete detail
along with a full running example. We have done our best to make this chapter
a “stand-alone” description of the methodology, but due to space limitations
certain aspects of the methodology (such as process diagrams) have not been
covered, and the running example that we use is only sketched out. For more
information on Prometheus, including a complete description and running ex-
ample, see Padgham and Winikoff (2004).
Case Study
In order to help explain the Prometheus methodology, we will use a case study
of a meeting scheduler system as a running example. This case study was set as
the main assignment for our undergraduate class, Agent Oriented Program-
ming and Design, in the second half of 2003. Students were given a high-level
description of a calendar system and were required to produce a design using
Prometheus and to implement the system using JACK2. The description of the
system provided was essentially the following.
The calendar system supports the scheduling, rescheduling, and

cancellation of meetings involving users. When a meeting is re-
quested with certain users the system attempts to find a suitable time.
Finding such a time may fail, may require that existing meetings are
moved automatically, or may create a double booking for certain
users that must be manually resolved.
Each user has his or her own application instance with which he or
she interacts. These applications can contain multiple agents that
interact with the applications of other users to coordinate and
schedule meetings.
In scheduling meetings, some users may be essential to the meeting
and others may not be essential. If an essential user pulls out of a
meeting after it is set (or cannot make a proposed time), then the
meeting needs to be rescheduled.
Setting or rescheduling meetings may be impossible without chang-
ing existing meetings. When doing this, care should be taken to
TEAM LinG
avoid creating a “cascade” where, in order to schedule meeting A,

meeting B is moved, which creates a clash with meeting C, which is
moved creating a clash with D, and so on. Some possibilities for
dealing with this situation include: (a) assigning priorities to
meetings (and in particular marking some meetings as not movable
or only manually movable); (b) using the heuristic that when a clash
is created, only a meeting with fewer people (or perhaps with less
senior people) will be moved.
The system should allow users to nominate when they are available
(and when they are not available) and should also allow for certain
constraints to be specified, such as only scheduling a maximum of
4 hours of meetings on a certain day (e.g., to allow time to prepare
a lecture). Or, more generally, only scheduling N hours of meetings
in a certain time period (M days).
Parts of the design that we present in this chapter are reproduced with
permission from the work of a student (John Sietsma) as part of the course and
was developed using an earlier version of the Prometheus Design Tool.
Specifically, the functionalities, data coupling diagram (slightly modified), agent
grouping, system overview diagram, and agent overview diagram are taken from
John’s design.
System Specification
System specification begins with a rough idea of the system, which may be simply
a few paragraphs of description, and proceeds to define the requirements of the
system in terms of:
• The goals of the system;

• Use case scenarios;
• Functionalities; and
• The interface of the system to its environment, defined in terms of actions
and percepts.
We would like to stress that these are not considered in sequence. Rather, work
on one of these will lead to further ideas on another. For example, the goals of
the system are a natural starting point for developing use case scenarios.
Conversely, developing the details of the scenarios often suggests additional
TEAM LinG
subgoals that need to be considered. Thus, system specification is an iterative

and non-linear process.
System Goals
Since agents are proactive and have goals, it is natural to consider using goals to
describe requirements3. The process for capturing the goals of the system begins
by capturing an initial set of goals from the high-level system description. For
example, given the description of the case study in the previous section, we can
extract an initial set of goals (and subgoals) such as:
• schedule meeting
• reschedule meeting
• cancel meeting
• find suitable time
• avoid cascade
• meet user preferences
• manage user availability
• manage meetings
• track essential participants
• interact with user
• track contacts
These initial goals are then developed into a more complete set of goals by
considering each goal and asking how that goal could be achieved (van
Lamsweerde, 2001), which identifies additional subgoals. For example, by asking
how a suitable meeting time can be found, we may realise that this involves a
subgoal of negotiating with other users.
As well as finding additional goals, the set of goals is also revised as common
subgoals are identified. For example, since the subgoals associated with sched-
uling and re-scheduling are identical, we choose to merge these two goals into
the goal “(re)schedule meeting.” We also make (re)scheduling meetings and
cancelling meetings into subgoals of managing meetings. These changes (and a
few others) result in the following (revised) set of goals and subgoals.
• manage meetings
• (re)schedule meetings
TEAM LinG
• find meeting time

• propose time meeting user preferences
• negotiate with other users
• cancel meeting
o determine essential participants
o update essential participants
• manage user availability
o update available times
o update preferences
• track contacts
o update contact
o add contact
o retrieve contact details
• communicate with other users
• interact with user
o remind user of meeting
• learn user preferences
Figure 2. Goal diagram (including additional goals from use case scenario
development)
TEAM LinG
This set of goals is not complete; it is merely a first draft. Indeed, as is often the
case, developing use case scenarios (Section “Use Case Scenarios”) suggests
additional goals that are included in the goal diagram (see Figure 2).
Functionalities
As we revise the groupings of goals, we are attempting to identify what we term

“functionalities” – coherent chunks of behavior that will be provided by the
system. A functionality encompasses a number of related goals, percepts that
are relevant to it, actions that it performs, and data that it uses. Functionalities
can be thought of as “abilities” that the system needs to have in order to meet
its design objectives; indeed, often functionalities of the system end up as
capabilities of agents in the system.
An initial set of functionalities is identified by considering groupings of goals. The
functionalities are often then revised as a result of considering the agent types
(done as part of architectural design).
In the case study, the top-level goal of manage meetings was made into the
Meeting Manager functionality, but the specific subgoals of proposing a
meeting time and negotiating were split off into separate functionalities (Meeting
Scheduler and Negotiator, respectively) because the associated ability was
relatively complex and could be cleanly separated from other aspects of
managing meetings. Each of the other top-level goals corresponds to a single
functionality, yielding the following functionalities (taken from John Sietsma’s
design):
• Meeting Manager: Manages meeting information. Encompasses all goals

associated with the top-level goal of manage meetings except for propose
time meeting user preferences and negotiate with other users.
• Meeting Scheduler: Schedules meetings subject to provided constraints
and user habits/preferences. Encompasses the goal propose time meeting
user preferences.
• Negotiator: Negotiates with other users to determine meeting times. This
differs from Meeting Scheduler in that Negotiator is about inter-user
constraints, whereas Meeting Scheduler is concerned only with the
constraints of a single user. Encompasses the goal negotiate with other
users.
• Contact Manager: In charge of managing contact information for other
users. Encompasses the goal track contacts and its subgoals.
• Contact Notify: Provides a means of communicating with other users.
Encompasses the goal communicate with other users and its subgoals.
TEAM LinG
• User Interaction: Interacts with the user (as opposed to interacting with
other users, which is done by Contact Notify). Encompasses the goal
interact with user and its subgoals except for remind user of a meeting.
• User Notify: Reminds user of events. Differs from User Interaction in
that (a) it uses a range of communication media such as SMS, e-mail and
so on, but also (b) waits for conditions to arise and reminds the user, rather
than receiving input from the user. Encompasses the goal remind user of
a meeting.
• User Information Manager: Manages information about the user such as
his/her preferences. Encompasses the goal manage user availability and
its subgoals.
• User Monitor: Observes user, attempting to learn his habits. Encompasses
the goal learn user preferences.
Functionalities are described using descriptors. These are just textual forms that
capture necessary information. In addition to a (brief) natural language descrip-
tion, the descriptor form for a functionality includes the goals that are related to
it, the actions that it may perform, and “triggers” – situations that will trigger
some response from the functionality. Triggers may include percepts but more
generally will include events as well. Finally, the descriptor form also includes
notes on the information used and produced by the functionality.
Use Case Scenarios
The third aspect of system specification is use case scenarios4. Use case
scenarios (sometimes abbreviated to “scenarios”) are a detailed description of
one particular example sequence of events associated with achieving a particular
goal or with responding to a particular event.
Scenarios are described using a name, description, and a triggering event.
However, the core of the scenario is a sequence of steps. Each step consists of
the functionality that performs that step, the name of the step, its type (one of
ACTION, PERCEPT, GOAL, SCENARIO or OTHER) and, optionally, the information used
and produced by that step.
In addition, scenarios often briefly indicate variations. For example, when
scheduling a meeting, a scenario may include a step that selects a preferred time
from a list of possible times. A variation of this scenario might be where there
is only a single time when all participants are available. In this case, the selection
step is omitted.
An example of a scenario descriptor for scheduling a meeting is given in the
following.
TEAM LinG
Name: New meeting scheduled

Description: The user adds a new meeting.
Trigger: New meeting requested by user
Steps:
# Type Name Functionality Data

1 PERCEPT Request meeting User Interaction
2 GOAL Propose time meeting user Meeting MeetDB(R),
preferences Scheduler Prefs(R)
3 GOAL negotiate with other users Negotiator MeetDB(R),
Prefs(R)
4 GOAL update user's diary Meeting Manager MeetDB(W)
5 GOAL inform others of meeting Contact Notify
6 OTHER wait for day of meeting
7 GOAL remind user of meeting User Notify MeetDB(R),
Prefs(R)
8 GOAL remind others of meeting Contact Notify ContactInfo(R)
Variations:
• Steps 2-3 may be repeated in order to obtain agreement.
• If agreement on a meeting time is not reached then steps 4-8 are replaced with notifying
the user that the meeting could not be scheduled.
• The meeting can be rescheduled or cancelled during step 6 (waiting).
Key:
• MeetDB(R) = Meetings Database read
• Prefs(R) = User Preferences read
• MeetDB(W) = Meetings Database written
• ContactInfo(R) = Contact Information read
In developing this use case scenario the additional goals get user preferences,
update user’s diary, inform others of meeting and remind others of meeting
were identified.
System Interface: Actions and Percepts
Finally, the environment within which the agent system will be situated is defined.
This is done by describing the percepts available to the system, the actions that
it will be able to perform, as well as any external data that are available and any
external bodies of code.
When specifying percepts, we also consider percept processing. Often per-
cepts will need to be processed in some way to extract useful information. For
example, raw image data indicating that a fire exists at a certain location may not
be significant if the agent is already aware of this fire. When agents are situated
TEAM LinG
in physical environments, then percept processing can be quite involved, for

example, extracting features of interest from camera images. Similarly, actions
may also be complex and require design.
In the case study, the system interacts with the user (and with other users) and
so the percepts correspond to different requests from the user. Actions
correspond to sending information back to the user (or other users) and
reminding users of meetings.
In the architectural design phase, the focus is on:
• Deciding on the agent types in the system: where agent types are identified
by grouping functionalities based on considerations of coupling; these are
explored using a coupling diagram and an agent acquaintance diagram.
Once a grouping is chosen, the resulting agents are described using agent
descriptors.
• Describing the interactions between agents using interaction diagrams
and interaction protocols: where interaction diagrams are derived from
use case scenarios; these are then revised and generalised to produce
interaction protocols.
• Designing the overall system structure: where the overall structure of the
agent system is defined and documented using a system overview diagram.
This diagram captures the agent types in the system, the boundaries of the
system and its interfaces in terms of actions and percepts, but also in terms
of data and code that are external to the system.
Deciding on Agent Types
Selecting the agent types that will exist in the system is perhaps the most
important decision that is made in this phase. Ideally, each agent type should be
cohesive and coupling between agents should be low.
In Prometheus, an agent type is formed by combining one or more functionalities.
Different groupings of functionalities give alternative designs that are evaluated
based on the cohesiveness of the agent types and the degree of coupling between
agents. For example, when considering a grouping of functionalities, if two
functionalities are clearly related, then it might make sense to group them
together in the same agent type. Conversely, if two functionalities are clearly not
related, then they should perhaps not be grouped in the same agent type.
TEAM LinG
Similarly, if two functionalities need the same data, then they should perhaps be
grouped together.
A useful tool for suggesting groupings of functionalities is the data coupling
diagram. This depicts each functionality and each data repository showing
where functionalities read and write data. An arrow from functionality to data
denotes reading. It is often fairly easy to extract some constraints on the design
by visually examining a data coupling diagram.
Figure 3 shows a data coupling diagram5 for the functionalities in the meeting
scheduler. In this case, the student chose to create four agent types:
• UserInterface: combining the functionalities of User Interaction and

User Notify. This grouping made sense because both functionalities are
concerned with interaction with the user.
• ContactTracker: based on the Contact Manager functionality and includ-
ing the Contact Information database. Although the Contact Notify
functionality could have been included in this agent type, it interacts more
with the functionalities concerned with scheduling meetings and so was
grouped with them in the Meetings agent.
• Meetings: combining the functionalities of Meeting Scheduler, Meeting
Manager, Negotiator, and Contact Notify, and including the Meetings
Database. These functionalities are both related and interact with each
other.
Figure 3. Data coupling diagram
TEAM LinG
• UserManager: combining the User Monitor and User Information

Manager functionalities; and including the User Habits and User Prefer-
ences databases 6.
The process of deriving agent types by grouping functionalities, with the aid of
a data coupling diagram, can often suggest possible changes to the functionalities.
For example, suppose that the design includes two functionalities that are
unrelated, and we would like to put them in two different agent types. However,
the two functionalities both read a particular data source; for instance, in the
grouping given, the User Interaction functionality within the UserInterface
agent reads the Meetings Database. We could change one of the functionalities
so that rather than read the data source directly, it sends a message to another
agent requesting the information.
The result of this process is a number of possible designs, each design consisting
of a grouping of functionalities into agent types. We now need to select a design.
One technique that is useful in comparing the coupling of different alternatives
is the use of agent acquaintance diagrams. An agent acquaintance diagram
shows the agent types and the communication pathways between them. Agent
acquaintance diagrams provide a convenient visualization of the coupling be-
tween the agent types—the higher the link density, the higher the coupling.
For example, the agent acquaintance diagram in Figure 4 shows the agent types
and the communication pathways between them. This is believed to be a
reasonable degree of coupling; the UserInterface agent needs to communicate
with all of the other agent types, but most of the other agent types don’t
communicate.
Once agent types have been decided upon, they are documented using an agent
descriptor. In addition to capturing the interface of the agent, what goals it
achieves, what functionalities were combined to form it, and with what protocols
the agent is involved, the descriptor prompts the designer to think about lifecycle
issues: When are instances of this agent type created? When are they destroyed?
What needs to be done when agents are created/destroyed?
Figure 4. Agent acquaintance diagram
TEAM LinG
Agent Interactions
The next step in the architectural design is to work on the interactions between
agents. These are developed using interaction diagrams and interaction proto-
cols. Specifically, the notations used are a simplified variant of UML sequence
diagrams for interaction diagrams and the revised version of Agent-UML
(AUML) (Huget et al., 2003) for interaction protocols7.
Interaction diagrams are derived from use case scenarios using a fairly mechani-
cal process (although not completely mechanical). In essence, if step N is
performed by an agent A, and this is followed by step N+1 performed by a
different agent B, then a message needs to be sent from A to B. For example, in
the use case scenario given earlier, step 1 is a percept that is received by the User
Interaction functionality that has been grouped into the UserInterface agent
type, and step 2 is a goal of the Meeting Scheduler functionality that has been
grouped into the Meetings agent type. Therefore, assuming a single agent of
each of the two types, in between step 1 and step 2, there is a message from the
UserInterface agent to the Meetings agent.
Like use case scenarios, interaction diagrams show example interactions rather
than all possible interactions. In order to define plans that will handle all
necessary interactions, we use interaction protocols to capture all possible
sequences of messages.
Often an interaction protocol will combine a number of interaction diagrams. For
example, if there are three interaction diagrams corresponding to different cases
of scheduling a meeting, then there will be an interaction protocol that covers all
cases and that subsumes the interaction diagrams. When looking at the use case
scenarios, we also consider the documented variations of these scenarios.
Another useful technique for developing interaction protocols is to consider each
point in the interaction sequence and ask “What else could happen here?” If the
interaction diagram shows an example sequence where a request for possible
meeting times is replied to with a number of possible times, then an alternative
possibility is that there won’t be any meeting times available.
The interaction protocols are accompanied with descriptors for both the proto-
cols and for the messages. These descriptors capture additional information such
as the information carried by a message.
Overall System Structure
Finally, the overall architecture of the system is captured using a system

overview diagram. The system overview diagram is one of the most important
design artifacts produced in Prometheus and is often a good starting point when
TEAM LinG
Figure 5. Example of a system overview diagram
trying to understand the structure of a system. The system overview diagram

shows agents, percepts, actions, messages, and external data as nodes (see
Figure 5). Directed arrows between nodes indicate messages being sent and
received by agents, actions being performed by agents, percepts being received
by agents, and data being read and written by agents. The system overview
diagram collects information from the various descriptors (especially the agent
descriptors) and presents it in a more easily understood form.
Figure 5 shows the overall design of the system. It depicts the four agent types
identified and also shows the messages between them, percepts received by the
UserInterface agent, and data read and written.
Detailed Design
Detailed design consists of:
• Developing the internals of agents, in terms of capabilities (and, in some

cases directly in terms of events, plans, and data). This is done using agent
overview diagrams and capability descriptors.
TEAM LinG
• Developing process diagrams from interaction protocols.

• Developing the details of capabilities in terms of other capabilities as well
as in terms of events, plans, and data. This is done using capability overview
diagrams and various descriptors. A key focus is developing plan sets to
achieve goals and ensuring appropriate coverage.
Capabilities (Busetta, Rönnquist, Hodgson, & Lucas, 2000; Padgham & Lambrix,
2005) are a structuring mechanism akin to modules. A capability can contain
plans, data, and events. It can also contain other capabilities allowing for a
hierarchical structure. In identifying the capabilities that each agent type
contains, one usually starts by considering a capability for each functionality that
was grouped in the agent type. This initial detailed design is then refined by
merging capabilities that are similar and small, splitting capabilities that are too
large, and adding capabilities that correspond to common “library” code.
The structure of each agent is depicted by an agent overview diagram. This is
similar to the system overview diagram except that it does not contain agent
nodes and does not (usually8) contain protocol nodes. However, the agent
overview diagram does (usually) contain capability nodes and (sometimes) plan
nodes.
Figure 6. Example of an agent overview diagram: Meeting agent
TEAM LinG
Developing the internal structure of an agent (or capability) is done using a

refinement process that begins with the interface of the agent: the data that it
reads and writes, the incoming and outgoing messages, the percepts it receives,
and actions it performs. Then, for each part of the agent’s interface, we consider
to what capability or plan it connects. In addition to connecting the interface of
the agent to internal plans and/or capabilities, additional internal messages and
data are introduced as needed.
For example, in developing the internals of the Meeting agent (see Figure 6) we
begin by considering its interface: the messages that it sends and receives, and
the data that it reads and writes. Some of the messages are concerned with
adding, deleting, or searching for meetings. Based on the original functionalities,
we introduce the capability ManageMeetings that receives these messages and
that reads and writes the MeetingsDB. Other messages concern proposing a
meeting time based on the user preferences. These are handled by the
CreateMeetingSchedule capability. The two capabilities communicate using
internal messages (RequestScheduleMeeting and MeetingSchedule), which
are now introduced.
During the architectural design phase, the system’s dynamics were described
using interaction protocols. These are global in that they depict the interaction
between the agents from a “bird’s-eye view.” In the detailed design phase, we
develop process diagrams based on the interaction protocols. The process
diagrams depict local views for each agent. Typically, each interaction protocol
will have multiple process diagrams corresponding to the viewpoints of different
agents. The notation that we use for process diagrams is an extension of UML
activity diagrams (OMG, 2001); for more details see Padgham and Winikoff
(2004, Chapter 8).
The design of each agent is, usually, in terms of capabilities. These capabilities
are then refined in turn. Eventually the design of how each agent achieves its
goals is expressed in terms of plans, events, and data. At this point, the design
process needs to make certain assumptions about the implementation platform.
Specifically, we assume that the agents are implemented using a platform that
supports plans that are triggered by goals. Such platforms include PRS (Georgeff
& Lansky, 1986), JAM (Huber, 1999), JACK (Busetta et al., 1998), Jadex9, and
Jason 10.
The final part of detailed design develops data, events, and plans. This is similar
to developing the internals of agents in terms of capabilities but with a few
additional considerations.
For events, we identify the information that is carried by the event. For example,
a request to schedule a meeting would include information on who should attend
the meeting, the priority of the meeting and perhaps what date is desired. For
each plan we identify its trigger (what event causes the plan to run) and the plan’s
TEAM LinG
context condition and then develop the plan’s body. The plan’s context condition
specifies the situations in which it is appropriate to use the plan. The plan’s body
describes how the plan operates and is often a sequence of steps which include
subgoals.
A given event can trigger multiple plans, and an important consideration relates
to this: for a given event, will there always be at least one plan that handles it and
that will be applicable? If so, then we say that the event is covered. This is
important because an uncovered event will fail to be handled. Where there is a
(typically single) plan with a context condition that is always true, then the event
is trivially covered. In other situations, coverage can be checked by considering
the context conditions of the set of plans that handles the event type in question.
A related notion is that of overlap: if a given event might have more than one
applicable plan, then there is overlap.
Plans are described using a descriptor, which also prompts the designer to
consider whether the plan can fail and, if so, whether the failure will be detected,
as well as what should be done to clean up upon failure.
Tool Support
We have attempted to stress the iterative nature of design, both across the
phases of Prometheus and within phases. One consequence of the iterative
nature is that the design is often modified. As the design becomes larger, it
becomes more difficult to ensure that the consequences of each change are
propagated and that the design remains consistent11.
Perhaps the simplest example of introduced inconsistency is renaming an entity
and failing to rename it everywhere it is mentioned. Other forms of inconsistency
that can be easily introduced when making changes to a design include adding
a message to an agent in the system overview diagram but failing to ensure that
the message appears in the agent overview diagram of that agent type, or adding
an incoming message to an agent but forgetting to add a plan to handle the
message.
Our experience, and the experience of students who used the Prometheus
methodology in its earlier days, was that developing designs by hand (using only
standard tools such as word processors and generic diagram editors) is quite
error prone and that tool support is invaluable. As a result, the Prometheus
Design Tool (PDT) was developed.
The Prometheus Design Tool (see Figure 7) allows users to create and modify
Prometheus designs. It ensures that certain inconsistencies cannot be introduced
and provides cross checking that detects other forms of inconsistency. The tool
TEAM LinG
Figure 7. The Prometheus design tool (PDT)
can also export individual design diagrams and generate a report that contains the
complete design. For more details on tool support for Prometheus, see Padgham
and Winikoff (2002). The Prometheus Design Tool is freely available12 and
further functionality is under development.
Another tool that supports the Prometheus methodology is the JACK Develop-
ment Environment (JDE) (see Figure 8), which provides a design tool that allows
Prometheus-style overview diagrams to be drawn. The JDE can then generate
skeleton code from these diagrams and ensures that changes made to the code
are reflected in the design diagrams and vice versa. This facility has proven quite
useful.
Finally, Sudeikat et al. (2004) mention that they have developed a tool that takes
a PDT design and generates from it a Jadex agent definition file. This tool is
notable in that it was developed completely independently from the Prometheus
and PDT developers.
TEAM LinG
Figure 8. The JACK development environment (JDE)
Strengths and Weaknesses
As discussed in the introduction, Prometheus aims to be a practical methodology

that can be used by undergraduate students and industry practitioners. The
(anecdotal) evidence supports our belief that we have succeeded in this regard,
and this is a key strength of Prometheus.
Prometheus has been developed over a number of years. During this time, it has
been taught to undergraduate students, used by students doing summer projects,
and taught at industry workshops. These activities yielded feedback that has
been valuable in refining and improving the methodology.
On the industrial side, a prototype weather-alerting system developed by Agent
Oriented Software for the Australian Bureau of Meteorology (Mathieson,
Dance, Padgham, Gorman, & Winikoff, 2004) used Prometheus overview
diagrams to capture and document the design. These diagrams were produced
using the JACK Development Environment (JDE).
In order to obtain a slightly more reliable assessment of Prometheus, we have on
two occasions set summer projects 13 where a student was given a written
description of the Prometheus methodology, intentionally limited support from
staff members, and was instructed to design and build an agent system. During
the 2001/2002 Christmas vacation, a second-year student produced a design and
TEAM LinG
implementation for a Holonic manufacturing system. During the 2002/2003

Christmas vacation, a different student produced a detailed design for a tourism
application. These experiences contrast with pre-Prometheus experiences
where graduate students struggled to design agent systems and required
considerable support from staff.
In our teaching, we have found that the Prometheus methodology has made a
significant difference. Before the methodology had been developed, graduate
students struggled to design and implement reasonable agent systems, whereas
now we are successfully teaching Prometheus and JACK in a one-semester
course. This course, which is taught to undergraduate students, sees most of
them successfully design and build reasonable agent systems within the period
of a semester.
These experiences provide evidence that Prometheus is useful as well as usable
by its intended target audience. Another strength of the Prometheus methodol-
ogy is the possibility and existence of tool support.
However, Prometheus is not without weaknesses. Its support for the social
aspect of agents is currently focused on the lowest common denominator:
messages and protocols. Extending the methodology to support more specific
types of agent interaction and relationships, such as teams of agents (Cohen &
Levesque, 1991) and open societies of agents, is one of the areas on which we
are currently focusing. The area of software methodologies for designing open
agent systems is quite new and exciting. Existing work that we intend to build on
includes Juan, Pearce, and Sterling (2002); Huget (2002); and Mathieu, Routier,
and Secq (2003).
Prometheus also does not deal at all with mobile agents. This has not been a
priority as we do not see mobility as central for intelligent agent systems.
However, if a developer is designing a system where mobility is a significant
aspect, then Prometheus is likely to be inadequate as a design methodology.
Prometheus covers the system specification, high-level design, and detailed
design activities with some discussion of implementation issues. There has also
been some work on using design models to help in debugging agent systems
(Poutakidis, Padgham, & Winikoff, 2002, 2003; Padgham, Winikoff, & Poutakidis,
2005). However, the support for implementation, testing, and debugging is limited
at the moment. Also, Prometheus currently has less focus on early requirements
and analysis of business processes than a methodology such as Tropos. These
are, however, all areas in which Prometheus is undergoing development and can
be expected to evolve.
Finally, Prometheus is not based on UML. This can be regarded as being either
a strength or a weakness. From the point of view of developing a methodology
that is well-suited to designing agents, we feel that not starting with a perspective
that is very object-centric has been a good decision. On the other hand, UML is
TEAM LinG
clearly the standard notation 14, with which most developers are familiar. We
have tried to build on aspects of UML and object-oriented design where
appropriate, although we note that there are other approaches that do this to a
greater extent (e.g., Papasimeon & Heinze, 2001; Wagner, 2002).
Conclusions
We have briefly presented the Prometheus methodology for designing intelligent
software agents and agent systems. The methodology provides detailed guid-
ance in terms of processes as well as notations. It is not intended to be
prescriptive, but is rather an approach that has evolved out of experience and that
the authors expect to be further adapted, refined, and developed to suit the needs
of agent software developers.
Recent years have seen a substantial growth of activity in the area of software
engineering methodologies suited to an agent programming paradigm. As these
mature and develop and are increasingly used beyond the immediate sphere of
the developers, we expect them to bear fruit in terms of increased use of agent
technology and more widespread familiarity with building of agent systems.
Acknowledgments
We would like to acknowledge the support of the Australian Research Council
(ARC) under Grant CO010693415 and its continuation, Grant LP045348616. We
would also like to thank John Sietsma, James Harland, John Thangarajah, and
David Poutakidis of RMIT University; Ralph Rönnquist, Andrew Lucas, An-
drew Hodgson, Paul Maisano, and Jamie Curmi of Agent Oriented Software;
and the many students and workshop participants who have provided comments,
examples, and feedback. The Prometheus Design Tool was initially developed
by Anna Edberg and Christian Andersson. Further development has been by
Claire Hennekam and Jason Khallouf.
References
Brazier, F. M. T., Dunin-Keplicz, B. M., Jennings, N. R., & Treur, J. (1997).
DESIRE: Modelling multi-agent systems in a compositional formal frame-
work. Int Journal of Cooperative Information Systems, 6(1), 67-94.
TEAM LinG
Burmeister, B. (1996). Models and methodology for agent-oriented analysis and

design. Working Notes of the KI’96 Workshop on Agent Oriented
Programming and Distributed Systems, September 17-19, Dresden.
Retrieved March 22, 2005, from http://www.dfki.uni-kl.dr/dfkidok/pub-
lications/D/96/06/abstract.html
Busetta, P., Howden, N., Rönnquist, R., & Hodgson, A. (2000). Structuring BDI
agents in functional clusters. In Agent theories, architectures, and
languages (ATAL-99) (pp. 277-289). LNCS 1757. Berlin: Springer-
Verlag.
Busetta, P., Rönnquist, R., Hodgson, A., & Lucas, A. (1998). JACK intelligent
agents - Components for intelligent agents in Java. Technical report, Agent
Oriented Software Pty. Ltd, Melbourne, Australia. Retrieved March 22,
2005, from http://www.agent-software.com
Bush, G., Cranefield, S., & Purvis, M. (2001). The Styx agent methodology. The
Information Science Discussion Paper Series 2001/02, Department of
Information Science, University of Otago, New Zealand. Retrieved March
25, 2005, from http://www.business.otago.ac.nz/infosci/pubs/papers/
dps2001.htm
Cernuzzi, L. & Rossi, G. (2002). On the evaluation of agent oriented modeling
methods. In J. Debenham, B. Henderson-Sellers, N. Jennings, & J. Odell
(Eds.), Proceedings of the OOPSLA 2002 Workshop on Agent-Ori-
ented Methodologies, Seattle, Washington (pp. 21-30).
Cohen, P. R. & Levesque, H. J. (1991). Teamwork. Nous, 25(4), 487-512.
Collinot, A., Drogoul, A., & Benhamou, P. (1996). Agent oriented design of a
soccer robot team. In Proceedings of the Second International Confer-
ence on Multiagent Systems (ICMAS’96) (pp. 41-57). AAAI Press.
Dam, K. H. (2003). Evaluating agent-oriented software engineering meth-
odologies. Master’s Thesis, School of Computer Science and Information
Technology, RMIT University, Melbourne, Australia (Supervisors: Michael
Winikoff and Lin Padgham).
Dam, K. H. & Winikoff, M. (2003). Comparing agent-oriented methodologies.
In P. Giorgini & M. Winikoff (Eds.), Proceedings of the Fifth Interna-
tional Bi-Conference Workshop on Agent-Oriented Information Sys-
tems, Melbourne, Australia, (pp. 52-59).
Drogoul, A. & Zucker, J. (1998). Methodological issues for designing multi-
agent systems with machine learning techniques: Capitalizing experiences
from the robocup challenge. Technical Report LIP6 1998/041, Laboratoire
d’Informatique de Paris 6.
Elammari, M. & Lalonde, W. (1999). An agent-oriented methodology: High-
level and intermediate models. In G. Wagner & E. Yu (Eds.), Proceedings
TEAM LinG
of the 1st International Workshop on Agent-Oriented Information

Systems, June 14-15, Heidelberg, Germany. Retrieved March 25, 2005,
from http.//www.aois.org
Georgeff, M. P. & Lansky, A. L. (1986). Procedural knowledge. Proceedings
of the IEEE Special Issue on Knowledge Representation, 74 (pp. 1383-
1398).
Glaser, N. (1996). The CoMoMAS methodology and environment for multi-
agent system development. In C. Zhang & D. Lukose (Eds.), Multi-agent
systems methodologies and applications (pp. 1-16). Second Australian
Workshop on Distributed Artificial Intelligence, LNAI 1286. Berlin:
Springer-Verlag.
Huber, M. J. (1999). JAM: A BDI-theoretic mobile agent architecture. In
Proceedings of the Third International Conference on Autonomous
Agents, (Agents’99), Seattle, Washington (pp. 236-243).
Huget, M.-P. (2002). Nemo: An agent-oriented software engineering method-
ology. In J. Debenham, B. Henderson-Sellers, N. Jennings, & J. Odell
(Eds.), Proceedings of the OOPSLA 2002 Workshop on Agent-Ori-
ented Methodologies, Seattle, Washington (pp. 41-53).
Huget, M.-P., Bauer, B., Odell, J., Levy, R., Turci, P., Cervenka, R., & Zhu, H.
(2003). FIPA modeling: Interaction diagrams. FIPA Working Draft (ver-
sion 2003-07-02). Retrieved March 25, 2005, from: http://www.auml.org.
“Working Documents.”
Juan, T., Pearce, A., & Sterling, L. (2002). ROADMAP: Extending the Gaia
methodology for complex open systems. In Proceedings of the First
International Joint Conference on Autonomous Agents and Multi-
Agent Systems (AAMAS 2002) (pp. 3-10). New York: ACM Press.
Kendall, E. A., Malkoun, M. T., & Jiang, C. H. (1995). A methodology for
developing agent based systems. In C, Zhang & D. Lukose (Eds.), First
Australian Workshop on Distributed Artificial Intelligence, November
13, Canberra, Australia (pp. 85-89).
Kinny, D. & Georgeff, M. (1996). Modelling and design of multi-agent systems.
In Intelligent Agents III: Proceedings of the Third International
Workshop on Agent Theories, Architectures, and Languages (ATAL-
96). LNAI 1193. Berlin: Springer-Verlag.
Kinny, D., Georgeff, M., & Rao, A. (1996). A methodology and modelling
technique for systems of BDI agents. In Proceedings of the Seventh
European Workshop on Modelling Autonomous Agents in a Multi-
Agent World (MAAMAW-96), Eindhoven, The Netherlands, January (pp.
56-71). Springer.
TEAM LinG
Lind, J. (2001). Interative software engineering for multiagent systems: The

MASSIVE method. Springer.
Luck, M., McBurney, P., & Preist, C. (2004). A manifesto for agent technology:
Towards next generation computing. Autonomous Agents and Multi-
Agent Systems, 9(3), 203-252.
Mathieson, I., Dance, S., Padgham, L., Gorman, M., & Winikoff, M. (2004). An
open meteorological alerting system: Issues and solutions. In V. Estivill-
Castro (Ed.), Proceedings of the 27th Australasian Computer Science
Conference (pp. 351-358), Dunedin, New Zealand.
Mathieu, P., Routier, J.-C., & Secq, Y. (2003). Towards a pragmatic method-
ology for open multi-agent systems. In Proceedings of the 14th Interna-
tional Symposium on Methodologies for Intelligent Systems (ISMIS)
(pp. 206-210), Maebashi City, Japan.
OMG (2001). OMG Unified Modeling Language Specification, Version 1.4,
September, OMG document formal/01-09-68 through 80 (13 documents).
Retrieved March 25, 2005, from http://www.omg.org
Padgham, L. & Lambrix, P. (2005). Formalisations of capabilities for BDI-
agents. Autonomous Agents and Multi-Agent Systems, 10(3), 249-271.
Padgham, L. & Winikoff, M. (2002). Prometheus: A pragmatic methodology for
engineering intelligent agents. In J. Debenham, B. Henderson-Sellers, N.
Jennings & J. Odell (Eds.), Proceedings of the OOPSLA 2002 Workshop
on Agent-Oriented Methodologies, Seattle, Washington (pp. 97-108).
Padgham, L. & Winikoff, M. (2004). Developing intelligent agent systems: A
practical guide. New York: John Wiley & Sons.
Padgham, L., Winikoff, M., & Poutakidis, D. (2005). Adding debugging support
to the Prometheus methodology. Engineering Applications of Artificial
Intelligence, Special issue on Agent-oriented Software Development,
18(2), 173-190.
Papasimeon, M. & Heinze, C. (2001). Extending the UML for designing JACK
agents. In Proceedings of the Australian Software Engineering Con-
ference (ASWEC 01), Canberra, Australia, August 27-28 (p. 89). IEEE
Press.
Poutakidis, D., Padgham, L., & Winikoff, M. (2002). Debugging multi-agent
systems using design artifacts: The case of interaction protocols. In
Proceedings of the First International Joint Conference on Autono-
mous Agents and Multi Agent Systems (AAMAS’02), Bologna, Italy, July
15-19 (pp. 960-967). ACM Press.
Poutakidis, D., Padgham, L., & Winikoff, M. (2003). An exploration of bugs and
debugging in multi-agent systems. In Proceedings of the 14th Interna-
TEAM LinG
tional Symposium on Methodologies for Intelligent Systems (ISMIS)

(pp. 628-632), Maebashi City, Japan.
Shehory, O. & Sturm, A. (2001). Evaluation of modeling techniques for agent-
based systems. In Proceedings of the Fifth International Conference
on Autonomous Agents (pp. 624-631). New York: ACM Press.
Sturm, A., Dori, D., & Shehory, O. (2003). Single-model method for specifying
multi-agent systems. In J. S. Rosenschein, T. Sandholm, M. Wooldridge, &
M. Yokoo (Eds.), Autonomous Agents and Multi-Agent Systems (AAMAS)
(pp.121-128). New York: ACM Press.
Sturm, A. & Shehory, O. (2003). A framework for evaluating agent-oriented
methodologies. In P. Giorgini & M. Winikoff (Eds.), Proceedings of the
Fifth International Bi-Conference Workshop on Agent-Oriented In-
formation Systems (pp. 60-67), Melbourne, Australia.
Sudeikat, J., Braubach, L., Pokahr, A., & Lamersdorf, W. (2004). Evaluation of
agent-oriented software methodologies: Examination of the gap between
modeling and platform. In P. Giorgini, J. Müller, & J. Odell (Eds.), Agent
Oriented Software Engineering (AOSE).
van Lamsweerde, A. (2001). Goal-oriented requirements engineering: A guided
tour. In Proceedings of the 5th IEEE International Symposium on
Requirements Engineering (RE’01) (pp. 249-263), Toronto, Ontario,
Canada.
Varga, L. Z., Jennings, N. R., & Cockburn, D. (1994). Integrating intelligent
systems into a cooperating community for electricity distribution manage-
ment. Int.Journal of Expert Systems with Applications, 7(4), 563-579.
Wagner, G. (2002). A UML profile for external AOR models. In Third
International Workshop on Agent-Oriented Software Engineering.
Winikoff, M., Padgham, L., & Harland, J. (2001). Simplifying the development
of intelligent agents. In AI2001: Advances in Artificial Intelligence. 14th
Australian Joint Conference on Artificial Intelligence (pp. 555-568).
LNAI 2256. Berlin: Springer-Verlag.
Wooldridge, M. (2002). An introduction to multiagent systems. Chichester,
UK: John Wiley & Sons.
TEAM LinG
Endnotes
1
Named after the Titan who was, amongst other things, the protector of
mankind. Prometheus, according to Greek mythology, stole fire from
Zeus and gave it as a gift to humanity; an act for which he was punished.
(http://www.greekmythology.com)
2
JACK Intelligent AgentsTM is a commercial agent development platform
developed by Agent Oriented Software.
3
In fact, there are also other reasons for considering goal-oriented require-
ments (van Lamsweerde, 2001).
4
The terminology used is not consistent with UML. Since Prometheus uses
scenario instances (“scenarios” in UML) and does not have anything
corresponding to UML’s Use Case Diagram, there is no need to distinguish
between two concepts.
5
The diagram is slightly modified from the one that was prepared by the
student.
6
These are renamed in the final version of the design to UserHabitsDB and
UserPreferencesDB, respectively.
7
Other notations that could be used for this purpose include the original
version of AUML and Petri nets.
8
Although it may make sense to allow protocol nodes in agent overview
diagrams, the current version of the Prometheus Design Tool does not
support this.
9
http://vsis-www.informatik.uni-hamburg.de/projects/jadex
10
http://jason.sourceforge.net
11
In the general sense, not in the formal sense of a logical theory being
consistent.
12
The Prometheus Design Tool is available from http://www.cs.rmit.edu.au/
agents/pdt
13
Summer projects are done by undergraduate students over eight weeks, full
time during the summer non-teaching period.
14
It is important to note that UML is only a notation, not a methodology.
15
Simplifying the Development of Agent-Oriented Systems, ARC SPIRT
Grant, 2001-2003.
16
Advanced Software Engineering Support for Intelligent Agent Sys-
tems, ARC Linkage Grant, 2004-2006.
TEAM LinG
136 Zambonelli, Jennings & Wooldridge
Chapter VI
Multi-Agent Systems as
Computational
Organizations:
The Gaia Methodology
Franco Zambonelli
Università di Modena e Reggio Emilia, Italy
Nicholas R. Jennings
University of Southampton, UK
Michael Wooldridge
University of Liverpool, UK
Abstract
The multi-agent system paradigm introduces a number of new design/

development issues when compared with more traditional approaches to
software development and calls for the adoption of new software engineering
abstractions. To this end, in this chapter, we elaborate on the potential of
analyzing and architecting complex multi-agent systems in terms of
computational organizations. Specifically, we identify the appropriate
organizational abstractions that are central to the analysis and design of
such systems, discuss their role and importance, and show how such
abstractions are exploited in the context of the Gaia methodology for multi-
agent systems development.
TEAM LinG
Multi-Agent Systems as Computational Organizations: The Gaia Methodology 137
Introduction
In the past few years, multi-agent systems (MASs) have been recognized as an
effective software engineering paradigm for designing and developing complex
software systems (Jennings, 2001; Wooldridge & Jennings, 1995). In fact, the
key characteristics of MASs (i.e., autonomy, situatedness, proactivity, and
sociality [Wooldridge & Jennings, 1995]) are well suited to tackling the emerging
complexities of modern software scenarios for a number of reasons. Firstly, the
autonomy of the application components (i.e., the ability for an agent to decide
what actions it should take at what time [Wooldridge & Jennings, 1995]) reflects
the decentralized nature of modern distributed systems (Tennenhouse, 2000) and
can be considered as the natural extension to the notions of modularity and
encapsulation for systems that are owned by different stakeholders (Parunak,
1997). Secondly, the flexible way in which agents operate (balancing reactive
behaviour in response to the environment in which they are situated, with
proactive behaviour towards the achievement of their design objectives
[Wooldridge & Jennings, 1995]) is suited to the dynamic and unpredictable
situations in which software is now expected to operate (Zambonelli, Jennings,
Omicini, & Wooldridge, 2001). Finally, the high-level, dynamic, and social nature
of multi-agent interactions is appropriate to open systems in which the constitu-
ent components and their interaction patterns constantly change (Estrin, Culler,
Pister, & Sukjatme, 2002).
In this chapter, we firstly elaborate on the organizational metaphor and present
and discuss the various organizational abstractions that come into play in the
design and development of a complex MAS. In particular, we show that an
organization is more than simply a collection of roles (as most methodologies
assume) and that, in order to effectively build an MAS in organizational terms,
a variety of additional organization-oriented abstractions needs to be devised and
placed in the context of a methodology. In addition, we discuss how the presented
organizational abstractions are effectively and coherently exploited in the Gaia
methodology. Specifically, the Gaia methodology (fully described in Zambonelli,
Jennings, & Wooldridge, 2003) both promotes a simple and clear to manage the
development process and exploits the appropriate organizational abstractions in
the process of developing MASs.
The chapter is organized as follows. The next section introduces the organiza-
tional metaphor and describes the organizational abstractions that are to be
exploited in agent-oriented software engineering. Following that, we detail how
these abstractions are exploited in Gaia in order to provide a methodology for the
analysis and design of MASs. The next section clarifies these concepts with the
use of a simple case study, followed by a discussion of the weaknesses and
strengths of the Gaia methodology. The chapter ends with our conclusions.
TEAM LinG
Computational Organizations and

Organizational Abstractions
From here on, we take it as given that modern software scenarios suit a modeling
approach based on autonomous, situated agents that interact in flexible ways (an
argument already well developed in Chapter I and in the literature [Jennings,
2001; Zambonelli et al., 2003]). Given this position, the next challenge is to
understand which further abstractions complete the agent-oriented mindset and
may lead to the definition of a useful methodology for agent-oriented software
development.
Characterization and Motivations
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, Dorigo, & Theraulaz, 1999) has shown to be
useful in efficiently solving complex distributed problems such as routing and
distributed sorting; physical metaphors (Abelson et al., 2000, Mamei, Zambonelli,
& Leonardi, 2003), focusing on the spontaneous reshaping of a system’s
structure, may have useful applications in pervasive and mobile computing; and
societal metaphors have been effectively applied in robotics applications (Collinot,
Drogoul, & Benhamou, 1996; Moses & Tennenholtz, 1995) and in the under-
standing and control of highly-decentralized systems (Hattori, Ohguro, Yokoo,
Matsubara, & Yoshida, 1999).
Our approach focuses on the development of medium- to large-size systems,
possibly situated in open and dynamic environments, that have to guarantee
predictable and reliable behaviors. For these kinds of systems, we believe the
most appropriate metaphor is that of an organization (Demazeau & Rocha
Costa, 1996; Fox, 1981; Handy, 1976; Zambonelli, Jennings, Omicini, &
Wooldridge, 2001), in which:
• A software system is conceived as the computational instantiation of a

(possibly open) group of interacting and autonomous individuals (agents).
• Each agent can be seen as playing one or more specific roles: it has a well-
defined set of responsibilities or subgoals in the context of the overall
system and is responsible for pursuing these autonomously. Such subgoals
may be both altruistic (to contribute to a global application goal) or
opportunistic (for an agent to pursue its own interests).
TEAM LinG
• Interactions are no longer merely an expression of inter-dependencies;

rather, they are seen as a means for an agent to accomplish its role in the
system. Therefore, interactions are clearly identified and localized in the
definition of the role itself and help to characterize the overall structure of
the organization and the position of the agent in it.
• The evolution of the activities in the organization, deriving from the
autonomous execution of agents and from their interactions, determines the
achievement of the application goal. This may be a global goal identified a
priori (as, for example, in a workflow management systems where altruistic
agents contribute to the achievement of a specific cooperative project) or
a goal related to the satisfaction of individual goals (as, for example, in
agent-mediated auctions, whose purpose is to satisfy the needs of buyer
and seller agents), or both (as, for example, in network enterprises
exploiting market mechanisms to improve efficiency).
The organizational perspective leads to a general architectural characterization

of an MAS as depicted in Figure 1. Although some simpler systems may be
viewed as a single organization, as soon as the complexity increases, modularity
and encapsulation principles suggest dividing the system into different sub-
organizations (the dashed ellipses in Figure 1), with a subset of the agents being
possibly involved in multiple organizations. In each organization, an agent can
play one or more roles, to accomplish which agents typically need to interact
with each other to exchange knowledge and coordinate their activities. These
interactions occur according to patterns and protocols dictated by the nature of
the role itself (i.e., they are institutionalized by the definition of the role). In
addition, the MAS is typically immersed in an environment (i.e., an ensemble of
resources, represented by the grey ellipse in Figure 1) with which the agents may
need to interact in order to accomplish their roles. Interactions with the
environment occur via some sorts of sensors and effectors (i.e., mechanisms
enabling agents to perceive and act upon some part of the environment). That
portion of the environment that agents can sense and effect (represented by the
darker ellipses inside the environment in Figure 1) is determined by the agent’s
specific role, as well as by its current status.
The organizational metaphor—other than being a natural one for human devel-
opers who are continuously immersed in a variety of organizational settings and
opening up the possibility of re-using a variety of studies and experiences related
to real-world organizations (Handy, 1976; Mintzberg, 1979)—appears to be
appropriate for a wide range of software systems. On the one hand, some
systems are concerned with controlling and supporting the activities of some
(possibly open) real-world organization (e.g., manufacturing control systems,
workflow management and enterprise information systems, and electronic
TEAM LinG
Figure 1. Multi-agent systems as computational organizations (Jennings,

2001; Zambonelli, Jennings, & Wooldridge, 2001). A multi-agent system
can be abstracted as a set of interacting sub-organizations with a subset of
the agents possibly belonging to multiple organizations. In each
organization, agents can play one or more roles and interact with each
other to exchange knowledge and coordinate their activities. In addition,
the multi-agent system is typically immersed in an environment with which
agents interact via various kinds of sensors and effectors.
Organization
Inter-agent Agent
Interactions Agent
Agent
Agent
Agent Agent
Access to the
Environment
Environment
marketplaces). Therefore, an organization-based design may reduce the con-

ceptual distance between the software system and the real-world system it has
to support. On the other hand, other software systems, even if they are not
associated with any pre-existing, real-world organization, may have to deal with
problems for which human organizations could act as a fruitful source of
inspiration, having already been shown to produce effective solutions (e.g.,
resource sharing, task assignment, and service negotiation). More generally,
whenever a software system is complex enough to warrant an agent-based
approach and still require a significant degree of predictability and reliability in
all its parts, the organizational metaphor may be the most appropriate one. In fact,
by relying on agents playing well-defined roles and interacting according to
institutionalized patterns, the organizational metaphor promotes both micro-level
TEAM LinG
(at the agents’ level) and macro-level (at the system level) control over the
design and understanding of the overall system behavior. Other metaphors (e.g.,
ant colonies and artificial societies), by focusing on the achievement of an
average macro-level behavior of the system, often sacrifice the micro-level
aspects (i.e., individual agents matter little or not at all). While this may be
acceptable in, say, wide-area file-sharing applications and heuristic allocation
systems, it is definitely not acceptable in manufacturing control systems,
enterprise information systems, or electronics marketplaces, where each agent
is important in its own right.
The characterization of an MAS of Figure 1 highlights the most basic abstrac-
tions that characterize a computational organization and that can be appropri-
ately 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 those
above and that, we believe, need to be considered in their own right: organiza-
tional rules and organizational structures (Zambonelli et al., 2003). In what
follows, we elaborate on these abstractions, which are the basic building blocks
of the Gaia methodology.
The Environment
An 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 determin-
ing 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. In other cases, the environment will be a virtual one,
including such things as enterprise information systems, Web services, and
database management systems.
Whatever the case, an explicit modeling of the environment is very important: not
taking it into account (as, for example, in the earlier versions of Gaia methodology
[Wooldridge, Jennings, & Kinny, 2000]) may complicate the overall design and
may introduce mismatches between the MAS design and its actual operation. In
particular, for both physical and computational environments, the following
issues come to the fore when considering an explicit environmental modeling
phase:
TEAM LinG
• Evaluating what environmental resources agents can effectively access.

Constraints may exist with respect to the possibility of accessing and
manipulating resources, and the environment model should therefore
distinguish between the existence and the accessibility of a resource. Also,
since the environment may be characterized by its own dynamics, it may be
the case that some of the resources are ephemeral in nature or are only
intermittently available. These dynamics may need to be identified, mod-
eled, and evaluated against technological capabilities to cope with them.
• Evaluating how the agents should perceive the environment, namely what
representation of the environment is appropriate in a given situation. Such
a choice is naturally dependent on the available technologies and on the pre-
existing scenarios. In a manufacturing scenario, for example, the choice
may depend on whether sensors are passive or active, leading to a
characterization of the environment in terms of either a data world or a
service world.
• Evaluating what should actually be considered as part of the environment.
The existence of active entities with which the agents in the MAS will have
to interact (e.g., computer-based sensors in a manufacturing scenario or
active databases in a Web scenario) means a decision has to be made about
what should be viewed as an agent and what should be viewed in terms of
dynamic environmental resources. In other words, the distinction between
the agent and the environment is not always clear cut and may require an
analysis in its own right.
Summarizing, the environment of an MAS should not be implicitly assumed—its

characteristics must be identified, modeled, and possibly shaped to meet appli-
cation-specific purposes.
Roles and Interactions
In general terms, the role of an agent defines what it is expected to do in the

organization, both in concert with other agents and in respect to 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 (Demazeau &
Rocha Costa, 1996; Ferber and Gutknecht, 1998; Wooldridge et al., 2000).
Organizational role models precisely describe all the roles that constitute the
computational organization. They do this in terms of their functionalities,
TEAM LinG
activities, and responsibilities, as well as in terms of their interaction protocols

and patterns.
Organizational interaction models describe the protocols that govern the interac-
tions between the roles. Moreover, the interaction model describes the charac-
teristics 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, DeLoach, & Sparkman,
2001) (including the earlier versions 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 on below – motivates our
introduction of the notions of organizational rules and organizational structures.
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 exploita-
tion of these skills.
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 an MAS should identify the constraints that the
actual organization, once defined, will have to respect. Typically, such con-
straints: (1) spread horizontally over all the roles and protocols (or, equivalently,
over the identified preliminary roles and protocols), or (2) express relations and
constraints between roles, between protocols, or between roles and protocols
(Esteva, Rodriguez-Aguilar, Sierra, Garcia, & Arcos, 2001). Although, in an
actual organization, such constraints are likely to be somehow enacted by some
agents playing roles and interacting, they cannot readily 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
TEAM LinG
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 identifica-
tion of global organizational rules allows the system designer to explicitly define:
(1) whether and when to allow new agents to enter the organization and, once
accepted, what their position should be; and (2) which behaviors 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 organizational
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.
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 organiza-
tion 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 in-
clude collectives of peers, multi-level and multi-divisional hierarchies (Fox,
1981), as well as more dynamic structures deriving from market-oriented
models. 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 an MAS is more appropriately derived from the
explicit choice of an appropriate organizational structure and, given this, we
believe organizational structures should be viewed as first-class abstractions in
their own right. This argument (which is conventional in architecture-centered
software design [Shaw & Garlan, 1996]) calls for a specific design choice not
to be (generally) anticipated in the analysis phase but, rather, to exploit
information collected during analysis. In the specific context of MAS develop-
ment, the argument is motivated by several considerations:
TEAM LinG
• Although the organizational structure of an MAS may be directly inspired

by the structure of the real-world system that the MAS must support,
automate, or monitor (consider, for example, enterprise information sys-
tems and workflow management systems), this should not automatically
imply that the organization of the software system should always mimic that
of the real-world system. This is so for several reasons. Firstly, the real
world organization may not necessarily be so well structured. Secondly, the
issues that may have driven a human organization towards the adoption of
a particular structure may not necessarily apply to the agent organization.
Thirdly, the mere presence of software may introduce changes in the real-
world organization. Of course, it may be the case that some specific
substructures in a real-world organization are necessarily preserved at the
MAS level and, thus, come predefined from the analysis phase. However,
this should not be considered the general case and should not prevent
developers from explicitly addressing the organizational structure issue.
• Starting from the organizational structure may prevent optimizing the
overall efficiency of the organization and may prevent subsequent optimi-
zations and changes. This consideration assumes a particular emphasis in
dynamic applications scenarios (e.g., virtual enterprises [Ricci, Omicini, &
Denti, 2002], global [Bonabeau et al., 1999] and pervasive computing
[Estrin et al., 2002]) where a system may need to frequently adapt its
organizational structure to the prevailing situation, possibly at run-time and
in an unsupervised way (Kephart & Chess, 2003). Although this chapter
does not explicitly deal with dynamic and unsupervised re-organizations,
the methodological approach we propose (by making the definition of the
organizational structure an explicit design decision) facilitates off-line
reorganization and paves the way for supporting dynamic online reorgani-
zation.
• The organization, once defined, has to respect its organizational rules.
Starting from a predefined organizational structure – by assuming we know
in advance what it should be or by committing a priori to a given
organizational structure – can make it difficult to have the organizational
rules respected and enforced. It is more natural for the choice of the
organizational structure to follow from the identification of the organiza-
tional rules.
As an additional note related to organizational structures, we believe that despite

the huge number of structures that can possibly be conceived, a (comparatively)
small subset of these structures is likely to be used most of the time. This opens
up significant opportunities both for re-use and for the exploitation of catalogues
of agent-oriented organizational patterns – including use cases reporting on
efficiency, robustness, degree of openness, and ease of enactment of organiza-
TEAM LinG
tional structures—to support designers in choosing the most appropriate organi-

zational structure for their problem.
Currently, in the area of agent-oriented software engineering, most pattern-
related work focuses on detailed design patterns (Kendall, 2001). In the near
future, we expect more research and studies to be carried out in the area of
architectural, organization-oriented patterns in order to extend the specific
studies already performed in this area (Fox, 1981) and to adapt those studies
performed in the area of organization management (Handy, 1976; Mintzberg,
1979) for exploitation in agent-oriented methodologies.
The Gaia Methodology

The Gaia methodology exploits the organizational abstractions presented in the
above section and, taking into account the specific issues associated with the
exploitation of such abstractions, defines a coherent design process for MAS
development. In other words, Gaia prescribes following an ordered sequence of
steps, the ordered identification of a set of organizational models, and an
indication of the interrelationships, guiding developers towards the development
of an MAS.
An overview of the abstractions and models involved in the Gaia process, to be
detailed later, is given in Figure 2. The Gaia process starts with the analysis
phase, whose aim is to collect and organize the specification, which is the basis
for the design of the computational organization (which implies defining an
environmental model, preliminary roles and interaction models, and a set of
organizational rules). Then, the process continues with the architectural phase,
aimed at defining the system organizational structure in terms of its topology and
control regime (possibly exploiting design patterns), which, in turn, helps to
identify complete roles and interaction models. Eventually, the detailed design
phase can begin. Its aim is to produce a detailed, but technology-neutral,
specification of an MAS (in terms of an agent model and a services model) that
can be easily implemented using an appropriate agent-programming framework.
Before detailing the Gaia process, we want to emphasize that:
• Gaia does not directly deal with particular modeling techniques. It proposes
but does not commit to specific techniques for modeling (e.g., roles,
environment, and interactions).
• Gaia does not directly deal with implementation issues. Although specific
technology platforms may introduce constraints over design decisions, this
TEAM LinG
Figure 2. Models of the Gaia methodology and their relations in the Gaia
process
Requirements
COLLECTION OF
REQUIREMENTS
Subdivide System into

Sub-organizations
ANALYSIS
Environmental
Model
Preliminary Preliminary
Role Model Interaction Model
Organizational
Rules
GAIA
SCOPE
ARCHITECTURAL
DESIGN
Organizational Structure
Organizational
Patterns
Role Model Interaction Model
DETAILED
DESIGN Agent Model Services Model
IMPLEMENTATION
issue is not dealt with by Gaia. A typical example relates to environmental

modeling: if the environmental resources are of a passive nature, one
cannot rely on having agents perceive them in terms of events. However,
generally speaking, these situations should be known at the time of
requirements capture.
• Gaia does not explicitly deal with the activities of requirements capture and
modeling, and specifically not of early requirements engineering.
TEAM LinG
The Analysis Phase
The main goal of the analysis phase is to organize the collected specifications and
requirements for the system-to-be into an environmental model, preliminary role
and interaction models, and a set of organizational rules for each of the (sub-
organizations) composing the overall system.
The Organizations
The first step in Gaia’s analysis is concerned with determining whether multiple
organizations have to co-exist in the system and become autonomous, interacting
MASs. Identifying such organizations is reasonably easy if the system specifi-
cation already identifies them, or the system mimics the structure of the real
world, involving multiple, interacting organizations. However, even if neither of
these conditions hold, modularity concerns may suggest considering the system
in terms of multiple organizations, for the sake of splitting the global complexity
of a problem into a set of smaller more manageable components (Simon, 1957).
Generally speaking, such sub-organizations can be found when there are portions
of the overall system that (1) exhibit a behavior specifically oriented towards the
achievement of a given sub-goal, (2) interact loosely with other portions of the
system, or (3) require competencies that are not needed in other parts of the
system.
The Environmental Model
The environmental model in Gaia is intended to make explicit the characteristics

of the environment in which the MAS-to-be will be immersed. The consider-
ations made in the previous section should be useful in this process.
Clearly, once the characteristics of the environment have been devised, they
must be properly represented. It is difficult to provide general modeling abstrac-
tions and general modeling techniques because, as already stated, the environ-
ments for different applications can be very different in nature and also because
they are somehow related to the underlying technology. To develop a reasonably
general approach (without the ambition for it to be universal), we suggest treating
the environment in terms of abstract computational resources, such as
variables or tuples, made available to the agents for sensing (e.g., reading their
values), for effecting (e.g., changing their values) or for consuming (e.g.,
extracting them from the environment).
Following such identification, the environmental model (in its simplest form) can
be viewed as a list of resources, each associated with a symbolic name,
TEAM LinG
characterized by the type of actions that the agents can perform on it, and
possibly associated with additional textual comments and descriptions. A graphi-
cal notation representing such a list of resources in an abstract space (as, e.g.,
in Figure 2) may also assist in the case of distributed applications or in the case
of applications intended to operate in the context of some physically situated
process.
Clearly, in realistic development scenarios, the analyst would choose to provide
a more detailed and structured view of environmental resources, depending on
their specific nature. For instance, a technical document would be represented
by a data structure including information such as authors, title, keywords, and so
on. Also, it is worth pointing out that more specific modeling techniques may be
better adopted depending on specifications and technological constraints. For
instance, the development of Web-based information based on XML documents
(as may be the case in a conference management system) might profit from an
environmental model by preserving the already available XML data representa-
tion and simply enriching it with annotations related to how the MAS will access
these structures.
The Preliminary Role Model
The analysis phase is not intended to design the actual organization of the MAS
(this is the purpose of the subsequent architectural design phase). However,
even without knowing what the structure of the organization will be, it is possible,
in most cases, to identify some characteristics of the system that are likely to
remain the same independently of the actual organizational structure. In particu-
lar, this equates to identifying the “basic skills” that are required by the
organization to achieve its goals, as well as the basic interactions that are
required for the exploitation of these skills. Such identification activities may
even be facilitated if a goal-oriented early requirements analysis has already
modeled the characteristics of the system in terms of actors involved and their
goals.
Given the identification of the basic skills and of their basic interaction needs,
respectively, the analysis phase can provide a preliminary definition of the
organization’s roles and protocols. However, this definition cannot be completed
at this stage. In fact, the basic skills (or preliminary roles) can only truly become
organizational roles when it is known how and with which other roles they will
interact. This, in turn, requires the definition of the global organizational
structure. Analogously, the basic interaction needs (or preliminary protocols)
can only be fully defined as organizational protocols when the adoption of an
organizational structure clarifies which roles these protocols will involve, when
their execution will be triggered, and by whom. In addition, the design phase is
TEAM LinG
likely to introduce additional roles and protocols, directly derived from the
adopted organizational structure and, therefore, not identified in the analysis
phase.
As anticipated in the previous section, it may also be the case that the need to
adopt specific organizational substructures in a system derives from specific
requirements, in which case at least some of the roles and protocols may assume
an already complete definition even at this stage.
To represent (preliminary) roles, Gaia adopts an abstract, semi-formal, descrip-
tion to express their capabilities and expected behaviors. These are represented
by two main attribute classes:
• Permissions are mainly aimed at: (1) identifying the resources that can
legitimately be used to carry out the role—intuitively, they say what can be
spent while carrying out the role; and (2) stating the resource limits within
which the role must operate—intuitively, they say what can’t be spent
while carrying out the role. In general, permissions relate agent roles to the
environment in which they are situated; in order to carry out a role, an agent
will typically have to access environmental resources and possibly change
or consume them. However, they can also be used to represent the
knowledge the agent can possibly have or have received from communi-
cations with other roles. To represent permissions, Gaia makes use of the
same notation adopted for representing environmental resources; that is, it
lists the resources to be accessed by a role and their attributes. However,
the attributes associated with resources no longer represent what can be
done with such resources (i.e., reading, writing, or consuming) from the
environmental perspective, but rather what agents playing the role must be
allowed to do to accomplish the role and what they must not be allowed to
do.
• Responsibilities determine the expected behavior of a role and, as such,
are perhaps the key attribute associated with a role. In Gaia, responsibilities
are divided into two types: liveness properties and safety properties
(Manna & Pnueli, 1995). Liveness properties intuitively state that “some-
thing good happens,” that is, describe those states of affairs that an agent
must bring about, given certain conditions. In contrast, safety properties are
invariants. Intuitively, a safety property states that “nothing bad happens,”
that is, that an acceptable state of affairs is maintained. The most widely
used formalism for specifying liveness and safety properties is temporal
logic, and the use of such a formalism has been strongly advocated for use
in agent systems. Although it has undoubted strengths as a mathematical
tool for expressing liveness and safety properties, there is always some
doubt about the viability of such formal tools for use in everyday software
TEAM LinG
engineering practices. Therefore, without excluding the possibility of using

such a formalism, Gaia proposes an alternative approach based on simple
regular expressions for liveness properties and simple predicates over the
role variables for safety properties. This is likely to make Gaia’s roles easier
to define and understand by a wider audience.
With all these definitions in place, it is now possible to precisely define the Gaia
(preliminary) roles model. A roles model is comprised of a set of role schema,
one for each role in the system. A role schema draws (i.e., lists) together the
various attributes discussed above into a single place (see Zambonelli et
al.[2003] for several examples of Gaia role schemata). In the case of the
preliminary role model, such a schema may simply leave some of its parts
undefined, to be later completed in the architectural design phase.
Preliminary Interaction Model
The Gaia interaction model captures the dependencies and relationships be-
tween the various roles in the MAS organization in terms of one protocol
definition for each type of inter-role interaction. Since the roles model is still
preliminary at this stage, the corresponding protocols model must also necessar-
ily be preliminary, for the same reasons.
In Gaia, 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, to focus attention on the
essential nature and purpose of the interaction, rather than on the precise
ordering of particular message exchanges (cf. the interaction diagrams of
Objectory or the scenarios of Fusion [Coleman et al., 1994]).
A protocol definition consists of the following attributes:
• Protocol name: brief textual description capturing the nature of the

interaction (e.g., “information request.” “schedule activity X’,” and “assign
task Y”);
• Initiator: the role(s) responsible for starting the interaction;
• Partner: the responder role(s) with which the initiator interacts;
• Inputs: information used by the role initiator while enacting the protocol;
• Outputs: information supplied by the protocol responder during interaction;
and
• Description: textual description explaining the purpose of the protocol and
the processing activities implied in its execution.
TEAM LinG
Of course, a more detailed protocol definition (including, for example, the

sequencing of messages within the protocol) can be added at any time to
complement our rather conceptual definition and provide more specific guide-
lines for design and implementation. For example, this could be achieved using
the AUML notation (Bauer, Muller, & Odell, 2001; Odell, Van Dyke Parunak,
& Bock, 2001).
The Organizational Rules
The preliminary roles and interaction models capture the basic characteristics,
functionalities, and interaction patterns that the MAS system must realize,
independently of any predefined organizational structure. However, as previ-
ously stated, there may be general relationships between roles, between proto-
cols, and between roles and protocols that are best captured by organizational
rules. In Gaia, the perspective on organizational rules is consistent with that on
roles’ responsibilities—organizational rules are considered responsibilities of
the organization as a whole. Accordingly, it is possible to distinguish between
safety and liveness organizational rules. The former refer to the invariants that
must be respected by the organization for it to work coherently; the latter express
the dynamics of the organization (i.e., how the execution must evolve). In
particular:
• Liveness rules define how the dynamics of the organization should evolve
over time. These can include, for example, the fact that a role can be played
by an entity only after it has played a given previous role or that a given
protocol may execute only after some other protocol. In addition, liveness
organizational rules can relate to other liveness expressions belonging to
different roles, that is, relating the way different roles can play specific
activities.
• Safety rules define time-independent global invariants for the organization
that must be respected. These can include, for example, the fact that a given
role must be played by only one entity during the organization’s lifetime or
that two roles can never be played by the same entity. In addition, they can
relate to other safety rules of different roles or to expressions of the
environmental variables in different roles.
Due to their similar nature, organizational rules can be expressed by making use
of the same formalisms adopted for specifying liveness and safety rules for roles
(i.e., regular expressions, predicates, temporal logics).
TEAM LinG
Organizational rules and their correct identification are fundamental to the design
phase because they constrain the definition of the actual organizational and
restrict the number of proper implementations of an organization, that is, of those
actual organizational structures that respect the organizational rules. In addition,
the definition of organizational rules is necessary when the system is open. In this
case, organizational rules are important to analyze (1) whether and when a new
agent can be admitted into the organization and which roles it is allowed to play,
and (2) which kinds of protocols can be initiated by the members of the
organization and when, and which kinds of protocols are an expression of
legitimate self-interest. As a final note, the identification of organizational rules
clearly shows that collecting and defining the system specifications may also
imply discovering which agents have to be present in the organization. Some of
the organizational rules for roles are likely to be reflected in the design phase,
driving, for example, the number of agents to be instantiated and the number of
roles to be played by a single agent. However, although some of these design
decisions may become clear well before the design phase, the analysis phase
should still disregard the presence of agents and only focus on the more abstract
concept of roles.
The Design Phase: Architectural Design
The output of the Gaia analysis phase systematically documents all the functional
(and to some extent, non-functional) characteristics that the MAS has to
express, together with the characteristics of the operational environment in
which the MAS will be situated. These structured specifications are then used
in architectural design to identify an efficient and reliable way to structure the
MAS organization and to complete the preliminary role and interaction models.
It is worth emphasizing that while the analysis phase is mainly aimed at
understanding what the MAS will have to be, the design phase is where
decisions have to be made about the actual characteristics of the MAS.
Therefore, even if some of the activities in design (i.e., the completion of the role
and interaction models) appear to be aimed at refining the outputs of the analysis,
they in fact rely on actual decisions about the organizational structure and lead
to a modeling of the MAS’s actual characteristics starting from the specifica-
tions.
Of course, any real-world project faces the difficult task of identifying when the
analysis phase can be considered complete (i.e., mature enough for design
decisions to be taken). In most cases, only the initiation of design activities
enables missing or incomplete specifications to be identified or conflicting
requirements to be noted. In either case, such findings typically require a
TEAM LinG
regression back to earlier stages of the development process. Gaia is not exempt
from such problems, although it promotes an earlier identification of them by
making explicit some decisions that are implicit in other methodologies (i.e., the
architectural design).
Choosing the Organizational Structure
The choice of the organizational structure is a highly critical phase in MAS

development, affecting all subsequent phases. Unfortunately, as is always the
case with architectural design, it is not possible to identify a precise and formal
approach with which to obtain the “best” design. Nevertheless, a design
methodology could and should give guidelines to help the designer make choices.
First, organizational theory states that any member of an organization—whether
a human being, a hardware component, or a software agent—exhibits bounded
rationality (Simon, 1957); that is, the amount of information it is able to store and
process in a given amount of time is limited. Therefore, for an organization to
work efficiently, it must not overload its members. Whenever the problem of
bounded rationality is likely to affect the organization, the organization has to
enlarge its resources (i.e., of its members), so as to better distribute the workload
among them. The fact that organizations of different sizes may require different
organizational topologies derives from the coordination costs that are incurred as
the number of members in the organization increases.
As a general guideline, the simplest organization topology that makes it possible
to properly handle the computational and coordination complexity should be
chosen. At one extreme, a single-member organization experiences no coordi-
nation costs and has the advantage of extreme simplicity, although in most cases
it is impossible to charge a single agent with all the duties. When an organization
is composed of only a few members, the coordination costs can be sufficiently
low that collective decisions among all the members are possible. The resulting
organizational network is a collective of peers in which all members, although
possibly committed to different roles, have the same authority over the global
organization. When the size of the organization increases still further, the
members of the collective can no longer bear the increased coordination costs
and a hierarchical topology must be adopted. In the hierarchy, the organization’s
members are freed from the duty of handling the coordination activities because
a leader member assumes responsibility for them. As the organization’s size
increases further, a collective leadership may be needed to handle the increased
coordination costs, or a multi-level hierarchy may emerge. In general, any
composition of the basic structures can be adopted for the definition of the overall
organizational structure. Also, in some cases, hybrid organizational networks can
emerge. For example, a collective of peers can be ruled by a leader for a limited
TEAM LinG
portion of its global coordination needs, while maintaining the capability of direct
peer-to-peer coordination for others (or, equivalently, a leader in a hierarchy can
take charge of a limited set of coordination activities, leaving subordinate
members to directly coordinate with one another for the remaining ones).
The control regime handling the interactions between the members of the
organization is somewhat orthogonal to the organizational topology, but it may
also somehow influence the organizational efficiency (although in a less signifi-
cant and direct way than the topology does). In a collective of peers, for example,
the control regime can be based either on a workload partitioning regime (in
which each of the peers has the same role and provides the same services) or
on a workload specialization (in which each of the peers provides a specific
service/activity). The two solutions, depending on the specific application
characteristics, may lead to different coordination costs, thus influencing orga-
nizational efficiency; when large numbers of similar tasks have to be performed,
work partitioning is better at reducing complexity and coordination costs; when
the overall workload derives from a few complex activities, work specialization
may incur lower coordination costs. Similar considerations may apply to different
control regimes applied to different topologies. For instance, it is possible to opt
for a hierarchy in which the main goal of the leader is to coordinate the activities
of the subordinates so as to obtain a sensible partitioning (i.e., load balancing) of
work among them. Alternatively, it is possible to opt for a hierarchy in which each
subordinate is specialized to supply either a specific service or product and in
which the leader is in charge of the allocation of resources and services so that
each subordinate can work at its full load. In the case of very large organizations
and when competitive and self-interested behavior are likely to emerge, both the
cooperative control regimes of collectives and the authoritative control regimes
of hierarchies are often ineffective. This is because of the unavoidable ineffi-
ciencies of multi-level hierarchies (or of hierarchies with high fan-out). In such
cases, a control regime based on market models for the distribution of workloads
and the supply of services needs to be adopted.
Organizational Rules
Another factor impacting on the choice of the organizational structure (primarily

of the control regime) is the need for the MAS to respect organizational rules and
to be able to enact them during execution. Some types of organizational rules,
typically safety ones, may express very direct and intuitive constraints directly
driving the adoption of specific organizational structures (e.g., constraints
specifying that two roles have to be played by the same agent or that the same
agent cannot play two specific roles concurrently). Clearly, in these cases, and
whatever the specific topology adopted, the control regime must be tuned so as
TEAM LinG
to distribute tasks in the organization in respect of the constraints. In the

conference management example, the fact that a submitted paper has to be
reviewed by at least three different reviewers simply rules out the possibility,
during review assignments, to consider a work partitioning regime for the sake
of load balancing.
The most significant case in which organizational rules impact on the organiza-
tional structure is in the presence of competitive and self-interested behavior. In
such cases, not only is it necessary that the adopted structure of a system respect
the organizational rules, but also that the adopted structure promotes their active
enactment. In fact, on the one hand, agents that dynamically enter an organiza-
tion may be unaware of the local rules while, on the other hand, self-interested
agents may strive to opportunistically ignore such rules to achieve their own
specific aims. In such cases, the organizational structure and specifically the
control regime of interactions must be shaped so as to make it possible to enact
some form of control over the execution of foreign and self-interested agents (or,
equivalently, to control which agents can play a specific role and how they play
it) so that the organizational rules are respected overall.
In summary, the enforcement of some organizational rules may have a significant
effect on the computational or coordination costs. Thus, organizational rules may
impact on the choice of the organization topology. For instance, consider a
liveness rule that forces a specific ordering on the execution of a set of
interaction protocols involving a group of agents. In this case, the adoption of a
simple collective of peers as a basic topology would impose so much load on each
of the agents to control the enactment of the rule that a designer would do better
to opt for a hierarchy, with a leader in charge of controlling the protocols’
execution sequence.
Let us now come to the influence of the real-world organization. Very often, an
MAS is intended to support the structure of a real-world organization. Therefore,
in general, the structure of the real-world organization acts as an attracting force
in the definition of the organizational structure, with a natural tendency to define
it so as to mimic/reflect the real-world structure. Notable examples are agent-
based systems for computer-supported cooperative work (CSCW), in which
agents are associated with each of the team members and in which agents
usually have to cooperate according to the interaction patterns of the real-world
organization. In a similar way, in agent-based systems for electronic commerce,
the patterns of interactions between the agents and their organizational roles are
likely to reflect those that can be found in human commercial transactions.
Having the structure of the MAS reflect the structure of the real-world
organization may be important for the sake of conceptual simplicity; in several
cases this may also come as a requirement, at least for some portions of the
structure. However, it is not always the case that this attracting force should be
accommodated.
TEAM LinG
Since the construction of an MAS necessarily implies an in-depth analysis of the

corresponding real-world organization, it often happens that this process uncov-
ers inefficiencies in the real-world organization. These inefficiencies may simply
be related to the fact that the organizational structure is not appropriate for the
size and objectives of the organization, or it may be more subtle. The latter case
includes the discovery of role underloads (e.g., the duties of a member of the
organization are significantly lower than those with which it could cope) or role
ambiguities (e.g., some members of the organization do not have a well-defined
role or they misunderstand the responsibilities). In such cases, and when the
designer of the system does not have the authority to modify and improve the
real-world organization, it is still possible to improve its software counterpart.
In addition, the availability of software systems to support the work of teams and
organizations tends to strongly impact the way of working and the real-world
organizational structure itself, even if it were previously efficient (a phenomenon
that applies to all information technology placed in this situation). Once the
members of the organization can have part of the work delegated to agents, their
role in the organization can become underloaded, and the whole real-world
organization may be forced to re-think its structure to face the reduced
computational and coordination costs in a more efficient way. Where possible,
this problem has to be taken into account in the design of the software system.
However, since the problem is most likely to show its effect over time, after the
MAS has entered its life in the real-world organization, the designer may be
forced to tune the chosen organizational structure of the MAS to these new
needs.
Exploiting Organizational Patterns
Whatever the specific factors that may determine the choice of an organizational
structure, it is likely that similar issues have been faced in the past and have led
to similar considerations and choices. This is the stage where the availability of
a catalogue of possibly modular and composable “organizational structures,”
describing in much more detail than we have done how and when to exploit a
specific structure, will greatly help the designer (Shaw & Garlan, 1996) and will
effectively complement our general guidelines. In fact, the guidelines we have
described are intended to be of help in evaluating the right trade-off in a rather
coarse-grained taxonomy of structures and control regimes. However, they
consider neither a number of variations on the theme that could be conceived, nor
a number of non-functional aspects possibly affecting such a more detailed
choice (e.g., mobility, security, resilience). The specific identification of these
variations and their impact on specific non-functional aspects may be well
supported by a structured catalogue of organizational structures. This will help
TEAM LinG
the designer to re-use both well-documented and motivated design choices and
the design work related to the representation of such a structure.
Representing the Organizational Structure
Once the identification of a suitable organizational structure for the MAS is

complete, the designer has to determine how to effectively represent it. In this
context, we suggest the coupled adoption of a formal notation and a more intuitive
graphical representation.
The obvious means by which to formally specify an organization is to explicate
the inter-role relationships that exist within it (to represent the topology of the
organizational structure) and their types (to represent the control regime of the
organization). We emphasize that there is no universally accepted ontology of
organizational relationships. Nevertheless, as a first pass towards a more
complete characterization and formalization, we can identify certain types of
relationships that are likely to frequently occur in MAS organizations. To give a
few examples: a control relationship may identify an authority relationship of
one role over another, in which a role can (partially) control the actions of another
role; a peer relationships may express the fact that two roles have equal status;
a dependency relation may express the fact that one role relies on some
resources or knowledge from other roles for its accomplishment. In any case,
these exemplar relationship types are neither mutually exclusive (e.g., a control
relationship may also imply a dependency relationship, and a dependency
relationship may exist between peers), nor claim to define a complete set (other
types of relationships can be identified).
For all the above representations to be useful to developers, they must be
properly detailed with a description of the semantics of the relations (i.e., of the
protocol and activities involved in such relations, as detailed in the following
subsection) and with any additional textual comments that could possibly enrich
the notation and make it more comprehensible.
Since the formal representation of the relationship may not be sufficiently
intuitive for all practitioners, a graphical representation may be used to comple-
ment it. Such a representation can simply reduce to the depiction of roles in terms
of “blocks,” connected by annotated arrows, to represent relations and their
types. Coupling such a graphical representation of roles and their relations with
the graphical representations of the environmental model (representing in an
abstract way the operational environment in which the MAS will be situated and
its resources) can lead to a complete and intuitive graphical representation of all
the entities involved in the MAS, of their interactions with each other and with
the operational environment (something that will appear very similar to the
general – intuitive – representation of an MAS in Figure 1).
TEAM LinG
Again, we emphasize that Gaia, per se, is not intended to commit to the adoption
of a specific notation. With regard to organizational structure, in addition to the
simple representational methods described above, other notations and graphical
representation can be adopted to describe and represent roles and their interac-
tions (e.g., AUML diagrams [Odell et al., 2001]).
Completion of Role and Interaction Models
Once the organizational structure is defined, the preliminary role and interaction
models (as identified in the analysis phase) can be transformed into complete
roles and interactions models (describing in detail the characteristics of all roles
and stages involved in the MAS that will actually be produced). In fact, with the
organizational structure identified, the designer knows which roles will have to
interact with which others (as derived from the organization topology) and which
protocols will have to be executed (as derived from the control regime of the
organization). Thus, the completion of the role and protocol model amounts to:
• Defining all the activities in which a role will be involved, as well as its
liveness and safety responsibilities;
• Defining organizational roles – those whose presence was not identified
in the analysis phase and whose identification derives directly from the
adoption of a given organizational structure;
• Completing the definition of the protocols required by the application, by
specifying which roles the protocol will involve; and
• Defining organizational protocols – those whose identification derives
from the adopted organizational structure.
The complete definition of the roles and protocols can exploit the representation
already introduced with respect to the preliminary roles and protocols. However,
if compared with the already discussed preliminary roles and protocols, the main
difference is that the complete representation now includes all the characteris-
tics of roles and protocols (i.e., for roles, the full identification of activities and
services, and for protocols, the complete identification of the involved roles).
With regard to roles and protocols whose definition directly derives from the
adoption of a specific structure (and that were not identified in the analysis
phase), their representation has to be defined from scratch (or by exploiting
templates from catalogues of organizational patterns).
When completing the preliminary role and interaction models, it is important to
clearly preserve the distinction between those characteristics that are “intrinsic”
TEAM LinG
(i.e., independent of the use of the role/protocol in a specific organizational

structure) and those characteristics that are “extrinsic” (i.e., derived from the
adoption of a specific organizational structure).
The above separation—that for the sake of simplicity could also be preserved as
a comment to the textual description of the protocols—assumes a fundamental
importance in the perspectives of re-use and design for change. If the definition
of a role clearly specifies the logical separation between the two parts, and the
implementation of the role somehow does the same, this enables the role be re-
used in different systems, independently of the specific organizational structure.
This distinction also means that changes in the organizational structure can be
made without forcing system developers to re-design and re-code agents from
scratch. Furthermore, if the implementation of the role, other than maintaining a
clear separation between intrinsic and extrinsic characteristics, also supports
dynamic changes in the agent structure (as, for example, in frameworks
supporting the run-time modification of the roles played by agents), the approach
could promote the definition and implementation of systems capable of dynami-
cally changing their internal organizational structure—by having agents re-adapt
their extrinsic part to fit into a new organizational structure—in response to
changed conditions. However, dealing with such dynamic re-organizations
would require the multi-agent system to monitor its execution and make decisions
about its re-structuring, and these are issues that are beyond the scope of this
chapter and of the current version of Gaia.
Once completed, the roles and interaction models represent an operational
description of the MAS organization that could be effectively exploited, possibly
with the support of the environmental model (to get a better idea of the
characteristics of the MAS operational environment), for the detailed design of
the MAS.
The Design Phase: Detailed Design
The detailed design phase is responsible for eventually identifying the agent
model and the services model that, in turn, act as guidelines for the actual
implementation of agents and their activities.
Definition of the Agent Model
In the Gaia context, an agent is an active software entity playing a set of agent
roles. Thus, the definition of the agent model amounts to identifying which agent
classes are to be defined to play specific roles and how many instances of each
class have to be instantiated in the actual system.
TEAM LinG
Typically, as previously outlined, there may be a one-to-one correspondence

between roles and agent classes—a given role will be played by an instance of
an agent of a class in charge of implementing that role. Such a correspondence
naturally derives from the methodological process that was adopted in which the
concept of role has implicitly assumed ever greater concreteness, especially
during the identification of the organizational structure. However, given that (1)
the organizational efficiency is not affected, (2) bounded rationality problems do
not emerge, and (3) this does not violate organizational rules, a designer can
choose to package a number of closely related and strongly interacting roles in
the same agent class for the purposes of convenience. There is obviously a trade-
off between the coherence of an agent class (how easily its functionality can be
understood), the efficiency considerations that come into play when designing
agent classes, and the need to minimize mismatches with the real-world
organization that the system intends to support.
The agent model of Gaia can be defined using a simple diagram (or table)
specifying for each agent class which roles will map to it. In addition, the agent
model can document the instances of a class that will appear in the MAS. This
can be done by annotating agent classes with qualifiers from Fusion (Coleman
et al., 1994). In any case, it is worth highlighting that the agent model of Gaia is
of use in driving the static assignment of roles to agent classes in which the
implementation of the agent class is assumed to hardwire the code to implement
one or more roles. Of course, if the implementation adopts a framework enabling
agents to dynamically assume roles, the concept of the agent class of Gaia (and
so the Gaia agent model) would no longer be of use.
As a final note, inheritance is given no part in Gaia’s agent models, since our
experience is that an MAS typically contains only a comparatively small number
of roles and classes, making inheritance of little use in design. Of course, when
it comes to actually implementing agents, inheritance will be used in the normal
object-oriented fashion.
The Services Model
As its name suggests, the aim of the Gaia services model is to identify the
services associated with each agent class or, equivalently, with each of the roles
to be played by the agent classes. Thus, the services model applies both in the
case of static assignment of roles to agent classes and in the case where agents
can dynamically assume roles.
While in OO terms a service would roughly correspond to an operation, agent
services are not available for other agents in the same way that an object’s
operations are available for another object to invoke. Rather, due to the
intrinsically active nature of an agent, a service is better thought of as a single,
TEAM LinG
coherent block of activity in which an agent will be engaged. Such a service does
not necessarily have to be triggered by external requests (i.e., the agent is
autonomous in its activities), nor does an external request necessarily trigger a
service (autonomy also implies there are internal decision capabilities).
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-condi-
tions, and post-conditions. Inputs and outputs to services will be derived in an
obvious way from both the protocols model (for services involving the elaboration
of data and knowledge exchange between agents) and the environmental model
(for services involving the evaluation and modification of environmental re-
sources). Pre- and post-conditions represent constraints on the execution and
completion of services, respectively. These are derived from the safety proper-
ties of a role, as well as from the organizational rules, and may involve constraints
on the availability and the specific values assumed by either environmental
resources or data and knowledge from other agents.
The services that compose an agent are derived from the list of protocols,
activities, responsibilities, and liveness properties of the roles it implements. At
one extreme, there will be at least one service for each parallel activity of
execution that the agent has to execute. However, even for sequential activities
of execution, there may be a need to introduce more services to represent
different phases of the agent lifecycle.
The Gaia services model does not prescribe an implementation for the services
it documents. Rather, 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 operations in an object-oriented language or as
Web services. Alternatively, a service may be decomposed into a number of
operations and implemented accordingly.
Final Result of the Gaia Process
After the successful completion of the Gaia design process, developers are
provided with a well-defined set of agent classes to implement and instantiate,
according to the defined agent and services model. As already stated, Gaia does
not deal with implementation issues and considers the output of the design phase
as a specification that can be picked up by using a traditional method or that could
be implemented using an appropriate agent-programming framework. These
considerations rely on the assumption that specific technological constraints
(e.g., those that may occur with regard to modeling and accessing to the
environment) are identified earlier in the process.
TEAM LinG
As an additional note, although the above methodology is explicitly conceived for

open-agent systems, its outcomes can also be exploited by:
• Third-party developers of agents, whenever they intend to have their

agents execute in other organizations, as may be the case for agents that
are used in agent-based marketplaces;
• Agent users, whenever they wish to exploit their personal assistant agents
in the context of specific workgroup applications.
In both cases, assuming that the developers of the existing MAS have made all
the Gaia models publicly available, an agent developer will be able to check
whether its agent can enter the system and, if so, to what rules and procedures
it needs to conform.
A Case Study
As an example of an open system that is suitable for development using the Gaia
methodology, we consider an agent-based system for supporting the manage-
ment of an international conference.
Setting up and running a conference is a multi-phase process, involving several
individuals and groups. During the submission phase, authors send papers and are
informed that their papers have been received and have been assigned a
submission number. In the review phase, the program committee (PC) has to
handle the review of the papers, contacting potential referees and asking them
to review a number of the papers (possibly by bidding on papers). Eventually,
reviews come in and are used to decide about the acceptance or rejection of the
submissions. In the final phase, authors need to be notified of these decisions and,
in case of acceptance, must be asked to produce a revised version of their
papers. The publisher has to collect these final versions and print the proceed-
ings.
Analysis
The conference management problem naturally leads to a conception of the

whole system as a number of different MAS organizations, one for each phase
of the process. Therefore, the first step of the Gaia process is quite trivial for this
application.
TEAM LinG
The environmental resources to be handled by the agents in the MAS are

basically papers and review forms. Thus, a minimal environmental model implies
identifying the characteristics of papers (e.g., author, title, keywords) and of
review forms (i.e., marks) that are of interest to the applications and modeling
the environment as a container of papers and review forms.
In each organization, the corresponding MAS can be viewed as being made up
of agents that are associated with the persons involved in the process (authors,
PC chair, PC members, reviewers) to support their work. These agents
represent the active part of the system and are clearly associated with specific
roles. In other words, the roles played by each agent reflect the ones played by
the associated person in the conference organization. Therefore, on this basis,
the analysis phase for this application consists of formalizing the preliminary
identification of such roles (the roles of reviewer, PC Chair, PC Member, author,
etc.) by identifying the permissions and the responsibilities of these roles. For
instance, the role of reviews collector in charge of selecting reviewers and
assigning papers to them (a role that can be assigned to either the PC Chair or
the PC members depending on the actual organization of the conference) will
have the permission to read papers and review forms but not to change them. In
addition, it will have the responsibility of selecting reviewers for a given set of
papers and of collecting reviews (as a liveness property), as well as ensuring that
each paper receives at least three reviews (as a safety property). The identifi-
cation of such roles will also enable us to identify and formalize a preliminary set
of interaction protocols (e.g., the role reviews collector will also identify an
interaction with agents playing the role of reviewer).
Depending on the actual organizational structures, different actors (e.g., the PC
Chair, the PC Members, or external reviewers) will be called upon to play such
roles and will interact in different ways with each other. Moreover, the actual
organizational structure, defined in the design phase, may also require additional
roles to be introduced. For example, a big conference may opt to subdivide the
submitted papers among a set of co-chairs according to their competence. In this
case, an additional role, in charge of partitioning the submitted papers according
to the defined criterion, must be added to the organization. This is likely to
influence the definition of the protocols and to require the definition of further
protocols (e.g., protocols to achieve some form of load balancing on the
partitions). For these reasons, the identification of roles and protocols in the case
study is necessarily preliminary, to be finalized in the design phase once the
actual organizational structure is identified.
Coming to organizational rules, a variety of constraints can be identified that
underpin the actual activity of the conference management organization. Just to
make a few examples: an author cannot act as a reviewer for his or her own
paper; the role of reviewer must be played at least three times for each of the
TEAM LinG
submitted papers by three different agents; the role in charge of setting up the
conference program can only be played after the role in charge of collecting all
the reviews has been played. All these constraints cannot be expressed simply
in terms of responsibilities of single roles; rather, they need to spread across
several roles and must therefore be expressed as global rules to be respected by
the MAS organization as a whole.
Once the analysis phase is completed, the first important design step is to identify
the actual organizational structure. In the case of the conference management
examples, several considerations should drive this choice:
• The complexity of the problem (i.e., the expected number of papers

submitted to the conference) typically influences the adopted structure of
the real-world organization and, consequently, should be considered as a
starting point towards the identification of the MAS organizational struc-
ture.
• The identified organizational rules may suggest alternative choices to that
of mimicking the structure of the real-world organization. For instance, to
guarantee that each paper is assigned to at least three reviewers requires
some form of global coordination that, even if potentially possible, could be
extremely expensive if the PC chair has decided to make PC members
autonomously select (or bid for) the papers they will review. A better
alternative would be to opt for a centralized control over the assignment of
papers to PC members.
• The availability of a software system automating several portions of the
process could significantly reduce the human load of the conference
organization (based on which the real-world organization has planned to
organize the process). This can, in turn, suggest the adoption—both in the
real-world and in the MAS organization—of a totally different structure
than the one that was originally planned.
Once the above considerations have been taken into account, they will eventually
enable a suitable organizational structure to be identified. Based on this, the
preliminary roles and interaction protocols can be completed and the final
organization of the MAS can be properly represented in a complete form (i.e.,
including all the involved roles and protocols and their interactions with the
environmental resources).
TEAM LinG
Detailed Design
The detailed design includes identifying the actual agents that will be called on
to play the above identified roles. In this case study, the typical one-to-one
mapping of roles-to-agents does not necessarily apply. For instance, an agent
called to play the role of PC Chair could also, concurrently, play the role of PC
Member. An agent playing the role of PC member could, in turn, play the role of
author and of reviewer. The detailed design phase is responsible for evaluating
these possibilities with respect to the bounded rationality of agents (and of their
human counterparts) and the organizational rules.
Once the agents are identified, the last step is to identify the services that will
compose them, according to the guidelines presented in the previous section. For
example, an agent playing simply a reviewer role will typically imply the
sequential execution of a number of phases (receive a paper, review it, send back
its review form), all of which can be implemented as a single long-term service.
The input of the service will be a request for reviewing a paper. The output of
the service will be the completed review form. A pre-condition on the execution
of the service could be that the same agent has not already executed that service
a maximum number of times (i.e., is not already reviewing the maximum allowed
number of papers). The post-condition is that the review form has been correctly
completed. However, since there are several potential outcomes of the initial
receive paper phase (e.g., a reviewer may also refuse to review a paper), the
design would be better to split the larger long-term service into a set of smaller
ones (e.g., by separating the service associated with the reception of a paper to
review from the one associated with the review itself, in which case the latter
service is only executed after a paper has been accepted for review). Similar
considerations may apply to the other agents in the MAS.
Discussion
The Gaia methodology is based on a well-founded organizational metaphor and
exploits in a clean and rational way a suitable set of organizational abstractions.
Therefore, we consider Gaia to be an effective general-purpose methodology for
the development of an MAS in a large set of scenarios (from distributed
workflow management systems, to systems for the control of physical and
manufacturing processes). In addition to this first, very important, characteristic,
other key advantages of Gaia can be identified:
TEAM LinG
• Gaia, by relying on a careful analysis of the organizational metaphor,

identifies and integrates into the development process a number of abstrac-
tions and models that—despite being very important for the effective
development of MASs—are not taken into account (or are underestimated)
by most of the current agent-oriented methodologies.
• Gaia, while adopting an organizational metaphor that naturally fits the needs
and the characteristics of MASs and of modern distributed systems,
proposes a design process that is coherent and broadly similar to the ones
that are currently widely adopted in traditional software development (i.e.,
object-oriented and component-based software development). Therefore,
by bringing all the specific advantages of agent-oriented computing into a
rather traditional software development process, Gaia can facilitate the
promotion of agent-oriented software engineering as a mainstream soft-
ware engineering paradigm.
• Gaia does not commit to any special-purpose notations for its models. It
suggests the adoption of some simple and intuitive notations without
excluding the possibility of coupling these notations with more formally
grounded notations (such as AUML, temporal logic, or whatever might be
of use in specific contexts). This choice makes Gaia very likely to be
accepted by the majority of developers (who typically do not like to manage
formalisms) without preventing the adoption of a more rigorous approach
to MAS development.
• Gaia’s design process promotes a design for change perspective and may
facilitate, in the future, the development of dynamic MASs in which the
organizational structure, the roles played by the agents in the MASs, and the
characteristics of the operational environment are allowed to dynamically
change during the execution of the system.
However, we are also aware of a number of limitations in the current version of

the Gaia methodology:
• Gaia does not deal directly with implementation issues. Such a radical
choice, driven by conceptual simplicity and generality, may not always be
practical. In fact, it may be the case that specific technology platforms may
introduce constraints over design decisions and may require being taken
into account during analysis and design. A trivial example relates to
environmental modeling: if the environmental resources are of a passive
nature, one cannot rely on having agents perceive them in terms of events.
Gaia—by neglecting such implementation issues—has no way of handling
them.
TEAM LinG
• Gaia does not deal with the activities of requirements capture and modeling
and, specifically, of early requirements engineering. We are aware of the
importance of such activities and of the ongoing work in this area.
Nevertheless, we believe that Gaia could fit and be easily integrated with
modern goal-oriented approaches to requirements engineering (Castro,
Kolp, & Mylopoulos, 2002), whose abstractions closely match those of
agent-oriented computing. However, the problem of requirements engi-
neering, fully elaborated by other methodologies (cf. the Tropos and PASSI
methodologies described elsewhere in this book) has still not been deeply
analyzed in the context of Gaia.
• Gaia suggests a rather sequential approach to software development,
proceeding linearly from analysis to design and implementation. However,
software development has often to deal with unstable requirements, wrong
assumptions, or missing information. This requires the designer to step back
from the current activities and, perhaps, re-think some of the decisions. As
it stands, however, there are no explicit structures or processes in Gaia for
doing this and for supporting a more flexible and iterative process.
Conclusions and Future Work

In this chapter, we have focused on the key idea of conceiving complex MASs
in terms of a computational organization. On this basis, we have analyzed the
potential of the organizational metaphor and the abstractions it supports and have
shown how these abstractions have been coherently integrated in the definition
of the Gaia methodology. Despite the fact that we consider the Gaia methodol-
ogy, in its current state, to be an effective tool to promote and support the
development of MASs, we are also aware that it has a number of limitations
(analyzed in the previous section). To this end, further work is needed to improve
the Gaia methodology. Such work can possibly rely on integrating specific
approaches of other methodologies to enlarge the practical applicability of Gaia,
as well as the widespread acceptance of the agent-oriented software engineer-
ing paradigm.
TEAM LinG
References
Abelson, H., Allen, D, Coore, D., Hanson, C., Homsy, G., Knight, T., Napal, R.,
Rauch, F., Sussmann, G. &. Weiss, R. (2000) Amorphous computing.
Communications of the ACM, 43(5), 43-50.
Bauer, B., Muller, J.P., & Odell, J. (2001). Agent UML: A formalism for
specifying multi-agent software systems. International Journal of Soft-
ware Engineering and Knowledge Engineering, 11(3), 207-230.
Bonabeau, E., Dorigo, M., & Theraulaz, G. (1999). Swarm intelligence. From
natural to artificial systems. Oxford, UK: Oxford University Press.
tems, 27(6), 365-389.
Coleman, D., Arnold, P., Bodoff, S., Dollin, D., Gilchrist, H., Hayes, F., &
Jeremas, P. (1994). Object-oriented development: The FUSION method.
Hemel Hampstead, UK: Prentice-Hall International.
Collinot, A. Drogoul, A., & Benhamou, P. (1996). Agent-oriented design of a
soccer robot team. In Proceedings of the 2nd International Conference
on Multi-agent Systems, Kyoto, Japan (pp. 41-47). Los Alamitos, CA:
IEEE Computer Society Press.
Demazeau, Y. & Rocha Costa, A.C. (1996). Populations and organizations in
open multi-agent systems. In Proceedings of the 1st National Sympo-
sium on Parallel and Distributed AI.
Esteva, M., Rodriguez-Aguilar, J.A., Sierra, C., Garcia, P., & Arcos, J.L.
(2001). On the formal specifications of agent institutions. In Agent-
Mediated Electronic Commerce, Volume 991, LNCS (pp. 126-147).
Berlin: Springer-Verlag.
Estrin, D., Culler, D., Pister, K., & Sukjatme, G. (2002). Connecting the physical
world with pervasive networks. IEEE Pervasive Computing, 1(1), 59-69.
Ferber, J. & Gutknecht, O. (1998). A meta-model for the analysis and design of
organizations in multi-agent systems. In Proceedings of the 3rd Interna-
tional Conference on Multi-Agent Systems, June, Paris (pp.128-135).
Los Alamitos, CA: IEEE Computer Society Press.
Fox, M.S. (1981). An organizational view of distributed systems. IEEE Trans-
actions on Systems, Man, and Cybernetics, 11(1), 70-80.
Handy, C. (1976). Understanding organizations. London: Penguin Books.
Hattori, F., Ohguro, T., Yokoo, M., Matsubara, S., & Yoshida, S. (1999).
Socialware: Multiagent systems for supporting network communities.
Communications of the ACM, 42(3), 55-61.
TEAM LinG
Jennings, N.R. (2001). An agent-based approach for building complex software

systems. Communications of the ACM, 44(4), 35-41.
Kendall, E.A. (2001). Agent software engineering with role modelling. In
Proceedings of the 1st International Workshop on Agent-Oriented
Software Engineering. Volume 1957 LNCS (pp. 163-170). Berlin: Springer-
Verlag.
Kephart, J.O. & Chess, D.M. (2003). The vision of autonomic computing. IEEE
Computer, 36(1), 41-50.
Lind, J. (2001). Iterative software engineering for multiagent systems: The
MASSIVE method, Volume 1994 LNCS. Berlin: Springer-Verlag.
Mamei, M., Zambonelli, F., & Leonardi, L. (2003). Distributed motion coordina-
tion in co-fields. In Proceedings of the 6th Symposium on Autonomous
Decentralized Systems, April, Pisa (pp. 63-70). Los Alamitos, CA: IEEE
Computer Society Press.
Manna, Z. & Pnueli, A. (1995). Temporal verification of reactive systems –
Safety. Berlin: Springer-Verlag.
Mintzberg, H. (1979). The structuring of organizations: A synthesis of the
research. Englewood Cliffs, NJ: Prentice Hall.
Moses, Y. & Tennenholtz, M. (1995). Artificial social systems. Computers and
Artificial Intelligence, 14(3),533-562.
Odell, J., Van Dyke Parunak, H., & Bock, C. (2001). Representing agent
interaction protocols in UML. In Proceedings of the 1st International
Workshop on Agent-Oriented Software Engineering, Volume 1957
LNCS (pp. 121-140). Berlin: Springer-Verlag.
Parunak, V. (1997). Go to the ant: Engineering principles from natural agent
systems. Annals of Operations Research, 75, 69-101.
Ricci, A., Omicini, A., & Denti, E. (2002). Agent coordination infrastructures for
virtual enterprises and workflow. International Journal of Cooperative
Information Systems, 11(3), 335-380.
Shaw, M. & Garlan, D. (1996). Software architectures: Perspectives on an
emerging discipline. Englewood Cliffs, NJ: Prentice Hall.
Simon, H. A. (1957). Models of man. New York: Wiley.
Tennenhouse, D. (2002). Embedding the Internet: Proactive computing. Com-
munications of the ACM, 43(5), 36-42.
Wood, M., DeLoach, S.A., & Sparkman, C. (2001). Multiagent system engi-
neering. International Journal of Software Engineering and Knowl-
edge Engineering, 11(3), 231-258.
TEAM LinG
Wooldridge, M. & Jennings, N.R. (1995). Intelligent agents: Theory and

practice. The Knowledge Engineering Review, 10(2), 115-152.
Wooldridge, M., Jennings, N.R., &.Kinny, D. (2000). The Gaia methodology for
agent-oriented analysis and design. Journal of Autonomous Agents and
Multi-Agent Systems, 3(3), 285-312.
Zambonelli, F., Jennings, N.R., Omicini, A., & Wooldridge, M. (2001). Agent-
oriented software Engineering for Internet applications. In A. Omicini, F.
Zambonelli, M. Klusch, & R. Tolksdorf (Eds.), Coordination of Internet
agents: Models, technologies, and applications (pp. 326-346). Berlin:
Springer-Verlag.
Zambonelli, F., Jennings, N.R., & Wooldridge, M. (2001). Organizational
ceedings of the 1st International Workshop on Agent-Oriented Soft-
ware Engineering, Volume 1957 LNCS (pp. 253-252). Berlin: Springer-
Verlag.
Zambonelli, F., Jennings, N.R., & Wooldridge, M. (2003). Developing multiagent
TEAM LinG
172 Bernon, Camps, Gleizes & Picard
Chapter VII
Engineering Adaptive
Multi-Agent Systems:
The ADELFE Methodology
Carole Bernon
IRIT – University Paul Sabatier, France
Valérie Camps
Marie-Pierre Gleizes
Gauthier Picard
Abstract
This chapter introduces the ADELFE methodology, an agent-oriented

methodology dedicated to the design of systems that are complex, open, and
not well-specified. The need for its development is justified by the theoretical
background given in the first section, which also gives an overview of the
concepts on which multi-agent systems developed with ADELFE are based.
A methodology is composed of a process, a notation, and tools. Tools are
presented in the second section and the process in the third one, using an
information system case study to better visualize how to apply this process.
TEAM LinG
Engineering Adaptive Multi-Agent Systems: The ADELFE Methdology 173
The last part of the chapter assesses strengths and limitations of ADELFE.
We note that its main strength is also its main limitation—it is a specialized
methodology, especially suited to the development of software with emergent
functionalities.
Introduction
Usually, classical design of computational systems requires some important
initial knowledge in the sense that the exact purposes of the system and every
interaction to which it may be confronted in the future have to be known.
However, at the same time, today’s problems are becoming more and more
complex (e.g., information searching on the Internet, mobile robots moving in the
real world). Indeed, systems that are able to deal with such problems are also
becoming open and complex; they are immersed in a dynamical environment;
they are often incompletely specified and, especially, an a priori known algorithm
does not exist to find a solution. Classical approaches then become inadequate
and a new way to tackle such problems is necessary.
Our research work, for several years now, has essentially focused on these kinds
of systems and has led us to propose Adaptive Multi-Agent Systems (AMAS)
as an answer (Camps, Gleizes, & Glize, 1998; Capera, Georgé, Gleizes & Glize,
2003; Gleizes, Georgé & Glize, 2000; Piquemal-Baluard, Camps, Gleizes, &
Glize, 1996). These systems are composed of agents that permanently try to
maintain cooperative interactions with others. We have built, with success,
several systems based on the use of adaptive agents in different areas. To ease
and promote this kind of programming, we then developed the ADELFE
methodology, the aim of which is to help and guide designers when developing
AMAS.
The remainder of this section briefly presents the foundation of adaptive multi-
agent systems and then explains how to implement adaptation in such systems.
After that, the main characteristics of ADELFE, as well as the context of its
presentation, are given.
Theoretical Background: Adaptive Multi-Agent Systems
In a general way, when conceiving a system, a designer wants it to realize the

right function; the system must be “functionally adequate.” But openness and
dynamics are sources of unexpected events and an open system plunged into a
dynamic environment has to be able to adapt to these changes, to self-organize.
TEAM LinG
If every component of a system is endowed with the capability to locally

rearrange its interactions with others, this ability of self-organization at the
lowest level permits changes in the global function without coding this modifica-
tion at the upper level of the system. Self-organization is a means to make the
system adapt but also to overcome complexity. If a system is complex and its
algorithm unknown, it is impossible to code its global function. This function has
then to emerge at the macro level (the system level) from the interactions at the
micro level (component level). Moreover, this global function cannot be known
at the component level, and a component just needs some local criteria to
rearrange its interactions. A proven theorem on functional adequacy says that
“For any functionally adequate system in a given environment, there is a system
having a cooperative internal medium which realizes an equivalent function”
(Camps, Gleizes, & Glize, 1998, p. 8). In other words, it is sufficient to build a
system whose components have a cooperative attitude to make it realize an
expected function. Cooperation is the local criterion that enables a component
to find the right place within the organization and that ensures that the system
taken as a whole is functionally adequate.
Highly relevant to our work in the agent domain, this theory has been mapped
onto multi-agent systems1 giving rise to what we call Adaptive Multi-Agent
Systems (AMAS).
Implementation of Self-organization: Cooperative Agents
Any agent in an AMAS follows a specific lifecycle that consists of three steps:
• The agent gets perceptions from its environment;

• It autonomously uses them to decide what to do in order to reach its own
goal; and
• It acts to realize the action on which it has previously decided.
More precisely, each agent follows this lifecycle while trying to keep cooperative
local interactions with others.
These cooperative agents are equipped with five modules to represent their
“physical,” “cognitive,” or “social” capabilities (Picard, 2003). Each module
represents a specific resource for the agent during its “perceive-decide-act”
lifecycle. The first four modules are quite classical in an agent model (Brazier,
Jonker, & Treur, 1999; Wooldridge, 2002); the novelty comes from the fifth one:
TEAM LinG
• The skill module represents knowledge on specific fields that enables

agents to realize their partial function. No technical constraints are required
to design and develop skills. For example, they can be represented as a
classical or fuzzy knowledge base of facts and rules on particular domains.
They can also be decomposed into an MAS at a lower level to support
learning if they need to evolve.
• The representation module enables an agent to create its own representa-
tion about itself, other agents, or the environment it perceives. For example,
representations can be implemented as a classical or fuzzy knowledge
base. As with skills, representations can be decomposed into an MAS when
learning capabilities on representations are needed.
• The interaction module is composed of perceptions and actions. Percep-
tions represent the inputs the agent receives from its environment. Actions
represent the outputs and the way the agent can act on its physical
environment, its social environment, or itself (considering learning actions,
for example). Both perceptions and actions may have different granularities—
from simple effectors providing activation for a robot to semantically
complex message sending for social agents.
• The aptitude module provides capabilities to reason on perceptions, skills,
and representations – for example, to interpret messages. For example,
these aptitudes can be implemented as inference engines if skills and
representations are coded as knowledge bases.
• The cooperation module embeds local rules to be locally “cooperative.”
Being cooperative does not mean that an agent is always helping other
agents or that it is altruistic, but only that it is able to recognize states that
it judges opposed to what it knows as being an “ideal cooperation” (that is
to say fulfilling three conditions: all perceived signals are understood,
reasoning on them leads to conclusions and these conclusions are useful).
These states are called “cooperation failures” or Non Cooperative Situa-
tions (NCS). From an observer’s viewpoint, the whole system is able to
detect any non-cooperative state coming either from the occurrence of
novelty or resulting from feedback returned by the environment concerning
a previously erroneous response of the system.
This theory has been applied to many projects: foraging ant simulation (Topin et
al., 1999), knowledge management, e-commerce (Gleizes, Glize, & Link-Pezet,
2000), flood forecasting (Georgé, Gleizes, Glize, & Régis, 2003), routing in
telephonic network, mechanical design, bio-informatics, and so forth. To ease
our future work, design tools were required. They were also needed to promote
this kind of programming towards designers not accustomed to developing
AMAS.
TEAM LinG
The Methodology ADELFE: Context of Presentation
It was soon recognized that even though several agent-oriented methodologies

already existed (Iglesias, Garijo, & Gonzalez, 1998; Wood & DeLoach, 2000),
none was suited to handle complexity, dynamics, openness, or software adapta-
tion. This led us to develop a toolkit—ADELFE—to work on some aspects not
already considered by existing methodologies and to support the AMAS theory
that has been briefly introduced above (Bernon, Camps, Gleizes, & Picard,
2002). ADELFE is an acronym that, translated from French, means “toolkit to
develop software with emergent functionality.”
In a general way, a methodology is made up of a process, some notations, and
tools to support these notations and/or help the developer (Shehory & Sturm,
2001). ADELFE provides a specific process adapted from an interpretation of
the Rational Unified Process (RUP) (Kruchten, 2000) according to the Neptune
Project (http://www.neptune.irit.fr). Some additions have been made to take
into account specificities of the AMAS theory, for example, the characterization
of the environment of the system, the identification of cooperation failures, and
so forth.
In the third section of this chapter, each of these extensions is exemplified
relating to a particular case study. The chosen case study consists of designing
a system that enables end-users and service providers to get in touch when they
share common centres of interest in a dynamic and distributed context (such as
the problem described in Gleizes et al. [2000]). The main requirement of such an
electronic information system is to enable (1) end-users to find relevant
information for a given request, and (2) information providers to have their
information proposed to relevant end-users.
More precisely, the system has to provide:
• Personalized assistance and notification for the end-users;

• Propagation of requests between the actors of the system;
• Propagation of new information only to potentially interested end-users;
and
• Acquisition of information about end-users’ real interests, in a general
manner, and about the information offers of providers.
We are clearly situated in a system where every end-user and service provider
has an individual goal: to answer the request he/she has to solve. Each end-user
and service provider does not know the global function of the system. The system
is strongly open because a great number of appearances or disappearances of
TEAM LinG
end-users and/or service providers may occur. Moreover, an algorithmic solution

is not known. In this context, classical approaches to tackle such a problem
cannot be applied. Using an AMAS in such a context is clearly relevant—we can
say that such a system is functionally adequate when a satisfied end-user wants
to use services of the system again, and when each service is fully used, namely,
in the most profitably way for the supplier.
Although ADELFE is an agent-oriented methodology suited to develop applica-
tions based on the AMAS technology, it does not assume that the designer is
specialized in this field. Therefore, some additional notations are provided as well
as some tools to help or guide the designer throughout the process application.
An overview of these different tools is given in the next section. The process
of ADELFE is expounded upon in the third section, by using the case study
as illustration. Strengths and weaknesses of ADELFE are finally presented,
along with some omissions that were intentionally made when defining this
methodology.
Tools Linked with ADELFE

To help in its use, ADELFE is based on “standards” such as the RUP and UML;
it also uses AUML2 (Odell, Van Dyke Parunak, & Bauer, 2000) to express agent
interaction protocols. However, being based on standards is not sufficient, and
tools are also required. This section gives an overview of the three main tools
integrated into the ADELFE toolkit:
• A tool that analyzes answers given by the designer to tell him/her if using
the AMAS technology is useful to implement the target system;
• OpenTool, a graphical modelling tool that supports the UML notation and
that has been modified to integrate new stereotypes and AUML interaction
protocols; and
• An interactive tool that describes the process and helps the designer to
apply it.
The AMAS Adequacy Tool
Not every designer needs to use the AMAS theory to build a system. Indeed, if
the algorithm required to solve the task is already known, if the task is not
complex, or if the system is closed and nothing unexpected can occur, this kind
TEAM LinG
of programming is completely useless and a more adapted one can then be

considered. Thus, ADELFE gives the designer a tool to study the adequacy of
the AMAS technology more easily.
This adequacy is studied at two levels: the global one (system) and the local one
(components). At the system level, eight criteria are studied:
1. Is the global task incompletely specified? Is an algorithm a priori unknown?

2. Is the correlated activity of several entities needed to solve the problem?
3. Is the solution generally obtained by repetitive tests? Are different attempts
required before finding a solution?
4. Can the system environment evolve? Is it dynamic?
5. Is the system functionally or physically distributed? Are several physically
distributed components needed to solve the global task? Or is a conceptual
distribution needed?
Figure 1. Overview of the AMAS adequacy tool
TEAM LinG
6. Are a great number of components needed?

7. Is the studied system non-linear?
8. Finally, is the system evolutionary or open? Can new components appear
or disappear dynamically?
And at the component level, three more criteria are used:
9. Does a component have only a limited rationality?

10. Is a component “big” or not? Is it able to do many actions, to reason a lot?
Does it need significant abilities to perform its own task?
11. Can the behaviour of a component evolve? Does it need to adapt to the
changes of its environment?
These questions are asked of designers using a graphical interface as visualized

in Figure 1. A designer uses a slider to answer a question by giving a rate among
20 possibilities ranging from “yes” to “no.” His/her answers are then analyzed
by the support decision tool. The two areas at the bottom of the graphical tool
window show the answers of ADELFE regarding the global level and the local
one. By clicking on those areas, an interpretation of the results can be obtained.
OpenTool Modified for ADELFE
OpenTool is a graphical modelling tool supporting the UML notation; it is

developed and commercialized by our project partner, TNI-Valiosys, and is
embedded in the ADELFE toolkit. This tool permits applications modelling while
assuring that the produced models are valid.
On the one hand, some deficiencies exist in the UML notation for dealing with
the specific modules composing a cooperative agent. On the other hand, AUML
diagrams to model interaction protocols between agents are needed and must be
supported by the tools linked with ADELFE. OpenTool has thus been modified
to allow expression of cooperation failures, to deal with the components of an
agent that constitute its behaviour, and to embed some AUML diagrams.
Expressing the Behaviour of an Agent through Stereotypes
Two solutions were available to express the behaviour of agents: extending the
meta-model or using a UML profile (Desfray, 2000). The former solution has not
TEAM LinG
been chosen because concepts concerning the agent domain or the multi-agent
one are not so well defined and set; many points of view still exist. It is therefore
difficult to “dictate” an agent or a multi-agent architecture.
We thus chose the latter solution by defining nine stereotypes to show how an
agent is formed and/or how its behaviour is expressed. They are defined and
embedded into OpenTool and rules (written in the OTScript language linked with
OpenTool) are given to govern their use:
• The first stereotype, «cooperative agent», expresses that an entity is an

agent that has a cooperative attitude and can be used to build AMAS. An
agent is implemented using a class stereotyped with «cooperative agent»
that must have methods (perceive, decide, act) that simulate the agent’s
lifecycle.
• As introduced in the previous section, modules are related to a cooperative
agent and stereotypes have been associated with each one of these
modules: «skill», «aptitude», «representation», «interaction», «perception»,
«actions» (perceptions and actions are specific interactions), and «coopera-
tion».
• The ninth stereotype, «characteristic», is used to tag an intrinsic or physical
property of a cooperative agent (for example, the address of a service
provider). A characteristic can be accessed or called anytime during the
lifecycle. It can also be accessed or called by other agents (for example,
if an end-user wants to know the address of a service provider).
A class called CooperativeAgent is the base class of all these stereotypes (see the
third section, devoted to the process of ADELFE). The «cooperative agent»
stereotype can only be applied to a class inheriting from that one. The last eight
stereotypes can be applied to attributes and/or methods of this class. Attributes
correspond to the data manipulated in the modules composing a cooperative
agent; methods are means to access or act on these attributes.
More details about those stereotypes and the rules linked with them (e.g., an
agent inherits from a super-class called CooperativeAgent, methods stereotyped
with «cooperation» are always called during the decision phase of an agent, etc.)
can be found in Picard (2003).
Integrating the AUML Notation
Agents’ interactions and languages are specified by using the AUML interaction
protocol model (Odell, Van Dyke Parunak, & Bauer, 2001). To fit with AMAS
TEAM LinG
specificities, the model has been extended and included in OpenTool functionalities
(Bernon et al., 2004).
The first extension concerns the non-determinism of OR or XOR nodes. AUML
remains vague concerning the decision process that manages these nodes. In
ADELFE, an «aptitude»-stereotyped method is attached to the node. This
method specifies the agent method that chooses the message to send or the
action to do.
The second extension highlights the cooperative attitude of an agent. When
receiving a message, an agent may detect a Non Cooperative Situation. To
specify this detection and enable its processing, a «cooperation»-stereotyped
method can be attached to the reception point of the message.
The Interactive Tool
The first functionality of the ADELFE interactive tool is to be a guide by

describing the process; each stage of the process is depicted and exemplified by
Figure 2. The ADELFE Interactive Tool – A general view showing the four
main windows: (1) Manager interface, (2) WorkProduct interface, (3)
Description interface, and (4) Example interface. The optional Synthesis
and Glossary interfaces are not shown on this figure.
TEAM LinG
applying it to a tutorial application. This tool also provides a means to support the
adopted notations and draw the needed diagrams by integrating the customized
version of OpenTool. It verifies the project consistency by displaying what
stages can be done depending on what has been already done or what documents
have been produced so far. Finally, the AMAS adequacy tool is linked with this
interactive tool to support the AMAS technology.
This interactive tool is composed of several interfaces (Bernon et al., 2004):
• A “Manager” interface (window #1, Figure 2) indicates, for the different

opened projects, the different stages that designers have to follow when
applying the methodology. Designers can backtrack in the methodology
process as they wish, but some stages can be inaccessible (written in grey)
depending on the progress state of the current opened project. Clicking on
a stage name displays the related information in the other windows.
• A “WorkProduct” interface (window #2, Figure 2) dynamically lists the
work products that have been produced (written in green) or that still have
to be produced regarding the current progress when applying the method-
ology.
• A “Description” interface (window #3, Figure 2) explains stages compos-
ing the methodology process. The description text can contain flags
showing that OpenTool or the AMAS adequacy tool must be used. The
designer has then to click on the corresponding icon in the toolbar (#5,
Figure 2) to launch it. The interactive tool is able to communicate with
OpenTool to make the designer access the right diagram depending on the
stage it is following.
• An “Example” interface (window #4, Figure 2) shows how the current
stage has been applied to the tutorial application.
• An optional “Synthesis” interface shows a global view and an abstract of
the already made stages.
• An optional “Glossary” interface explains the terms used in the methodol-
ogy and defines the stereotypes that have been added to UML.
This interactive tool can be downloaded from the ADELFE Web site (http://
www.irit.fr/ADELFE). This site constitutes an online and simplified version of
the interactive tool.
TEAM LinG
The Process of ADELFE

The primary objective of the ADELFE method is to cover all the phases of a
classical software design—from the requirements to the deployment. A well-
known process, the RUP, has been tailored to take into account specificities
coming from the design of adaptive multi-agent systems. Phases are called
WorkDefinitions (WDi), Activities (Aj) or Steps (Sk), following the vocabulary
of the Object Management Group’s (OMG) Software Process Engineering
Metamodel (SPEM) (OMG, 2002), which has been used to express the ADELFE
process (Gleizes, Millan, & Picard, 2003). Only the requirements, analysis, and
design work definitions require modifications in order to be adapted to AMAS,
others appearing in the RUP remaining the same. This section gives a theoretical
and sequential description of these three WDs, but, of course, a designer may
back track between the different stages, like in the RUP.
The stages that are specific to the AMAS technology are marked with a bold font
in the description tables below. For reasons of clarity, their theoretical descrip-
tion is sometimes followed by a practical application to the information system
case study (see first section).
WD1 & WD2: Preliminary and Final Requirements
With respect to an object-oriented methodology, ADELFE adds nothing to

preliminary requirements (WD1) as described by the RUP. The aim still consists
of studying the customer needs to produce a document on which both the
customer and the designer agree.
Table 1. WD1 & WD2 – Preliminary and Final Requirements in ADELFE –

Their aim is to define the system such as the customer wants it to be.
WD1: Preliminary requirements WD2: Final requirements

A1: Define user requirements A6: Characterize environment
A2: Validate user requirements S1: Determine entities
A3: Define consensual requirements S2: Define context
A4: Establish keywords set S3: Characterize environment
A5: Extract limits and constraints A7: Determine use cases
S1: Draw an inventory of use cases
S2: Identify cooperation failures
S3: Elaborate sequence diagrams
A8: Elaborate UI prototypes
A9: Validate UI prototypes
TEAM LinG
A6 – Characterize the Environment
Unlike classical approaches, the environment of the system is central in the

AMAS theory. Actually, the adaptation process of the system depends on the
interactions between the system and its environment. Therefore, during the final
requirements (WD2), before determining use cases, the environment must be
studied by the designer. One activity (A6) is then added to the RUP to
characterize the environment of the system. This characterization begins by
identifying the entities that interact with the system and constraints on these
interactions (A6-S1). An entity is an actor in the UML sense and may be
described as being active or passive in ADELFE. An active entity may behave
autonomously and is able to act in a dynamical way with the system. A passive
entity can be considered as a resource by the system; it may be used or modified
by active ones but cannot change in an autonomous way. This distinction
between entities is essential because agents composing the system, which are
not a priori known at this stage, will be found among active ones.
In the case study, we can only find active entities, each one representing an end-
user or a service provider who has subscribed to the system. An end-user seeks
a relevant service provider according to his/her centres of interest, while a
provider tries to find potentially interested end-users according to his/her
proposed services. Due to the space limitation, the case study cannot be entirely
and precisely studied in this chapter; as these two actions are totally symmetric,
we will only focus on the search for a service.
In the next step (A6-S2), the context is studied through the interactions between
entities and the system. This step adds no special notation and uses UML
collaboration or sequence diagrams.
Finally, the designer must describe the environment with terms inspired from
Russel and Norvig (1995) (A6-S3). Thus the environment may be:
• Accessible (as opposed to “inaccessible”) if the system can obtain com-

plete, accurate, and up-to-date information about the state of its environ-
ment. For example, an environment such as the Internet is not an accessible
one because knowing all about it is impossible.
• Continuous (as opposed to “discrete”) if the number of possible actions and
perceptions in the environment is infinite. For example, in a real environ-
ment like the Internet, the number of actions that can be performed by users
can be unbounded.
• Deterministic (as opposed to “non deterministic”) if an action has a single
and certain effect. The next state of the environment is completely
determined by the current state. By its very nature, the real physical world
is a non-deterministic environment.
TEAM LinG
• Dynamic (as opposed to “static”) if its state depends upon actions of the
system that is within this environment but is also dependent on the actions
of some other processes. So, changes cannot be predicted by the system.
For example, the Internet is a highly dynamic environment.
In the case study, the environment of the system consists of end-users and
service providers who have subscribed to the system. Each of them exerts
pressure on the system (by submitting requests to find relevant service providers
or to seek potential customers), and the system has to adapt itself to these
constraints. Reorganizing interaction links between entities representing end-
users and service providers is a way for the system to adapt to its environment.
For the reasons previously given, the environment can be described as inacces-
sible, continuous, non-deterministic and highly dynamic.
A7- S2: Identify Cooperation Failures
The next activity is a classical one in which use cases are identified from the point
of view of the MAS user (A7). But ADELFE is only interested in “cooperative
agents” that enable building AMAS. At this point, designers must also begin to
think about the events that can be “unexpected” or “harmful” for the system,
because these situations can lead to Non Cooperative Situations at the agent
level. These “cooperation failures” can be viewed as a kind of exception. To take
this aspect into account, the determination of use cases has been modified by
Figure 3. (Simplified) Use case for the information system – Two cooperation
failures may be identified
TEAM LinG
adding a step (A7-S2) in which cooperation failures must be highlighted within

the previously identified use cases (A7-S1), using a specific notation (dotted
arrows) added to and then supported by OpenTool.
In the case study, two main cooperation failures may occur (see Figure 3). The
first one may appear during a request when the service provider replying to the
end-user request is unavailable. The second may appear during an offer process
if the targeted end-user has disappeared. The remainder of this second work
definition is classical and will not be described here.
WD3: Analysis
Domain analysis is a static view and an abstraction of the real world established
from previous requirements and remains the same as in the RUP (A10). By
studying the previously defined use cases and scenarios, the analyst identifies the
components of his/her system. This identification is more or less complex
depending on the studied applications (Georgé et al., 2003; Shehory & Sturm,
2001) and aims at clustering the different identified components into a prelimi-
nary class diagram.
A11: Verify the AMAS Adequacy
As outlined in the introduction section, not every designer needs AMAS theory
to build a system. Thus, a new and appropriate activity is added to the process
to study the adequacy of the AMAS technology (A11) through the tool previously
described. This adequacy must be studied at two levels (A11-S1 & A11-S2),
through a certain number of criteria:
• At the global level, to answer the question “is a system implementation using
AMAS needed?”
• At the local level, to try to answer the question “do some components need
to be implemented as AMAS?” That is, is some decomposition or recursion
useful during design?
If a positive answer is given by the tool in the former case, the designer can
continue applying the process. Furthermore, if the tool shows the same need at
the components level, ADELFE must be applied again to these components that
will be considered as AMAS themselves because they need to evolve.
TEAM LinG
Table 2. WD3 – Analysis in ADELFE – Its aim is to enable the designer to

structure his/her system in terms of components and interactions between
these components.
A10: Analyze the domain A12: Identify agents

S1: Identify classes S1: Study entities in the domain context
S2: Study interclass relationships S2: Identify potentially cooperative entities
S3: Construct preliminary class diagrams S3: Determine agents
A11: Verify the AMAS adequacy A13: Study interactions between entities
S1: Verify it at the global level S1: Study active/passive entities relationships
S2: Verify it at the local level S2: Study active entities relationships
S3: Study agent relationships
Even though some features of the case study application (a priori unknown
algorithm, open and dynamic environment, evolutionary system, etc.) may meet
the essential characteristics within the remit of the AMAS theory, the adequacy
tool has been used to reinforce this idea. The values given to the different
questions (see the description of the tool in the introductory section) are
respectively 17, 16, 11, 19, 20, 12, 5, 19, 17, 15, and 13. Values given to criteria
1, 3, 5, and 7 express the fact that this problem is a complex and open one for
which no well-established algorithm exists. The second and fourth values show
that, at this point, the designer does not know exactly how to implement a
solution.
The positive result given by ADELFE can be seen on the Figure 1. Using an
AMAS is relevant for solving this case study; using AMAS for some components
of the system is also relevant. This latter result will lead us to apply the process
again once the agents have been identified (WD4) to possibly find other entities
and consequently agents. We will only focus here on the entities representing
end-users and service providers; other entities present in the real developed
system will not be taken into account.
A12: Identify Agents
In ADELFE, agents are not considered as being known in advance; therefore,

the designer must identify them in a new activity (A12) in which the previously
identified entities will be studied and evaluated. If an entity shows some specific
properties (autonomy, local goal to pursue, interactions with others, partial view
of its environment, ability to negotiate), it may be a potential cooperative entity
(A12-S1). Indeed, this does not concern all active entities. Some of them could
autonomously evolve without having a goal, for example, an autonomous
TEAM LinG
resource such as pheromones or active objects. In that case, they are not
potentially cooperative and will remain simple objects without becoming agents.
To actually be a cooperative agent, a potential cooperative entity must be prone
to cooperation failures. By studying its interactions with its environment and with
other entities, the designer has then to determine if this entity may encounter such
situations that will be considered as Non Cooperative Situations at the agent level
(A12-S2). The entities verifying all these criteria will be identified as agents and
the classes related to them marked with the specific «cooperative agent»
stereotype (A12-S3).
In the case study, the active entities identified in A6-1 can be considered as
agents because of their properties. Such entities are autonomous, have a local
goal to pursue (to find a relevant service provider or to make targeted advertise-
ment), have a partial view of their environment (other active entities), or may
interact with others to target the search more effectively. They are then
potentially cooperative. Furthermore, since the system is open, new entities may
appear or disappear, and they may not be able to communicate as they should
(e.g., an entity does not understand requests from a new entity). In that case, an
active entity is prone to cooperation failures and can be viewed as a cooperative
agent. Each end-user (or service provider) is then represented within the system
by an agent called TransactionAgent (TA).
A13 - S3: Study Agent Relationships
Interactions between all the identified entities are then studied in the last activity
of this work definition (A13). Studying relationships between passive and active
entities or between solely active ones is done by using UML collaboration or
sequence diagrams in a standard way. However, in the last step of this activity,
protocol diagrams are used to express relations between all the existing agents
(A13-S3). These diagrams can be built using OpenTool modified to support
AUML.
The AUML protocol diagram, shown in Figure 4, expresses the way in which the
system responds to an end-user’s request. The end-user TA, which represents
the end-user, tries to satisfy the request by finding a relevant service provider
TA. If it does not have any relevant partner, it asks a special address provider
TA for partner addresses. Since every TA is cooperative, when a TA judges
itself incompetent to respond to a received request, it will not discard this request;
rather, it will send it again to another TA that is competent from its point of view.
Every TA having the same cooperative behaviour, the request may be propa-
gated a limited number of times, step-by-step.
TEAM LinG
Figure 4. An AUML Protocol Diagram for the Case Study – It expresses the
way in which the system answers an end-user’s request.
WD4: Design
This design work definition is an important stage because the recursive charac-
terization of an AMAS is identified at this stage and can lead to the identification
of other agents at a lower level. This may imply one design process for each new
identified level of the system.
The first activity identifies the detailed architecture for the system with
packages, sub-systems, objects, agents, and relations between them to produce
a class diagram in which the predefined CooperativeAgent class and the «coop-
erative agent» stereotype will appear (A14).
In the case study, the TransactionAgent’s (TA’s) goal is to find relevant TAs
according to the request that its associated end-user or service provider
submitted for solution. To represent these TAs, a class called TA has been
TEAM LinG
Table 3. WD4 – Design in ADELFE – Its aim is to define the system

architecture.
A14: Study detailed architecture and multi-agent model A16: Design agents
S1: Determine packages S1: Define skills
S2: Determine classes S2: Define aptitudes
S3: Use design-patterns S3: Define interaction languages
S4: Elaborate component and class diagrams S4: Define world representations
A15: Study interaction languages S5: Define Non Cooperative Situations
A17: Fast prototyping
A18: Complete design diagrams
S1: Enhance design diagrams
S2: Design dynamic behaviours
defined. This class inherits from the CooperativeAgent class and therefore
contains four mandatory methods: run, perceive, decide, and act. It is also tagged
with the «cooperative agent» stereotype.
A15: Study Interaction Languages
The designer has then to study interaction languages to define, in a new activity
(A15), the way in which agents interact. If agents interact in order to commu-
nicate, for each scenario defined in A7 & A13, information exchanges between
agents must be described using AUML protocol diagrams. Languages that
enable interactions between agents may be implemented by a set of classes or
by a design pattern, including specific agent communication tools such as an
implementation of Foundation for Intelligent Physical Agents (FIPA) Agent
Communication Language (ACL). As they are generic models, protocol dia-
grams are attached to packages and not to classes. If no direct communication
exists between agents (e.g., they communicate in an indirect manner via the
environment by modifying it), defining an interaction language is useless. Indeed,
this step only aims at detailing the protocol used by agents to communicate and
does not give any means to implement these interactions.
A16: Design Agents
The next activity is also specific to ADELFE and added to the RUP (A16) to let
the designer refine the «cooperative agent»-stereotyped classes he/she has
previously defined (during A12 & A15). The different modules composing an
agent must be given in this activity, as well as their physical properties (e.g.,
TEAM LinG
weight, color, etc.). Each step composing this activity must be applied to every
previously identified agent.
A16 – S1: Design Skills

Methods and attributes describing the skills of an agent must be given and
stereotyped with «skill» (A16-S1).
In the case study, the skills of a TA are those of the entity it represents. For
example, TAs communicate by forwarding the current request according to their
representations, in order to find a relevant service provider to solve this request.
When the TA of a relevant service provider is found, this TA must then use a
method to ask the service provider to give a response to the request. This method
getInfo is tagged with the «skill» stereotype, that is, «skill» Info getInfo (Request
request).
A16 – S2: Design Aptitudes

Aptitudes of an agent must be provided, also using attributes and methods
stereotyped with «aptitude» (A16-S2).
In the case study, aptitudes enable a TA to modify its representations and to
interpret a received request. For example, when an end-user makes a request,
his/her TA has to update its representations to learn the new centres of interest
of its end-user. The method updateMyBelief enables the representations to be
changed and is tagged with the «aptitude» stereotype, that is, «aptitude» int
updateMyBelief (Request request).
A16 – S3: Design Interaction Languages

Among the protocols identified during A15, the designer chooses those used by
an agent to interact with others. Assigning an interaction protocol to an agent
automatically associates a state-machine with this agent. Attributes and methods
linked with an interaction protocol must be stereotyped with «interaction» (A16-
S3).
In the case study, messages exchanged between TAs deal with the requests to
be resolved. Physical exchanges of these requests can be made using the
mailbox concept, a buffer enabling asynchronous communication. Therefore, the
attribute mailbox of a TA is tagged with the «interaction» stereotype, that is,
«interaction» MailBox myMailBox.
The only way to interact is by means of message passing. The methods relating
to these message exchanges that are used during the perception phase (respec-
tively the action phase) are stereotyped with «perception» (respectively with
TEAM LinG
«action»). For example, the method used by a TA to get a message from its
mailbox is tagged by the «perception» stereotype, that is, «perception» Message
getMessage().
The method to send messages is stereotyped with «action», that is, «action»void
sendMessage (Message AMessage, Reference Dest).
A16 – S4: Design Representations

Attributes and methods that enable an agent to create its own representation
about itself, other agents, or the environment it perceives are identified and
stereotyped with «representation» (A16-S4).
In the case study, representations that an agent possesses about itself or about
other TAs may evolve at runtime and they have then to be adjusted. We choose
to use an AMAS to implement them. When a TA receives a request, it has to
query its representation on itself to know if it is relevant to solve this request. The
class TA needs the following attribute to access this component, that is,
«representation» LocalBelief MyBelief.
A16 – S5: Design Characteristics

In the next step (A16-S5), the intrinsic or physical properties of an agent have
to be described and tagged by the «characteristic» stereotype.
In the case study, the physical address of a TA, called myReference, represents
the address of the TA in the system, that is «characteristic» Reference MyReference;
and the method to get its value is: «characteristic» Reference getReference(char
*Name).
A16 – S6: Design Non Cooperative Situations

This is the most important step in this activity because the ability to detect and
remove Non Cooperative Situations is specific to cooperative agents (A16-S5).
A model (cf. Table 4) is available to help the designer to enumerate all the
situations that seem to be “harmful” for the cooperative social attitude of an
agent. It reminds the designer that these situations belong to several types (such
as ambiguity, uselessness, etc.) and are dependent on some conditions (one or
several) that may be fulfilled or not when the agent is performing a certain phase
in its lifecycle (perception, decision, action).
In the case study, if we only consider the decision phase, three NCS can be
identified. All of them depend on only one condition as shown in Table 5.
After having identified every NCS an agent could encounter, the designer fills
up a second type of table (see Table 6) that describes each NCS. This description
TEAM LinG
Table 4. Generic Non Cooperative Situations – Different kinds of generic

NCS exist. This table helps the designer to identify the involved ones
depending on the agent’s lifecycle step and the fulfilled conditions.
Condition 1 not fulfilled Condition 1 fulfilled

Condition 2 not Condition 2 Condition 2 not Condition 2
fulfilled fulfilled fulfilled fulfilled
Incomprehension? Incomprehension? Incomprehension? Incomprehension?
Perception
Ambiguity? Ambiguity? Ambiguity? Ambiguity?
Incompetence? Incompetence? Incompetence? Incompetence?
Decision
Unproductiveness? Unproductiveness? Unproductiveness? Unproductiveness?
Concurrence? Concurrence? Concurrence? Concurrence?
Action Conflict? Conflict? Conflict? Conflict?
Uselessness? Uselessness? Uselessness? Uselessness?
Table 5. Table 4 Partially Filled up for the Case Study – Only the “decision”
phase is considered.
A TA cannot extract any A TA can extract an A TA can extract several

informative content from informative content from informative content from the
the received message only one part of the received message
received message
Decision Total Incompetence Partial incompetence Ambiguity
may be only a textual one to be a guide to find afterwards the methods related
to the detection and removal of the NCS. This table contains:
• The state of this agent when detecting this NCS,

• A textual description of the NCS,
• Conditions describing the different elements permitting local detection of
the NCS, and
• The actions linked to this NCS which describe what an agent has to do to
remove it.
If the designer wants to be more precise and formal, he/she may also specify
what attributes and methods will be used to express the state, conditions, and
actions. Rules embedded in OpenTool will verify the consistency of their
stereotyping. To express a state, only the «perception», «characteristic» or
«representation» stereotypes will be used. Those stereotypes used to express
conditions will be «perception» or «representation», and methods and attributes
related to actions must be stereotyped with «action» or «skill».
TEAM LinG
For the case study, the main task in this step is to fill up the table describing each
NCS that a TA may encounter. Four situations have been highlighted and are
textually described below.
Table 6. Description of the NCS that a TA may encounter
Name Total incompetence

State Receipt of a request
An agent faces total incompetence when it cannot associate any meaning to the message it
Description received: this may be due to an error in transmission or if the transmitter gets a wrong belief
about it.
During the interpretation phase the agent compares the received request with its own
Conditions representation (words matching) and cannot extract any informative content from the
message; it has not the necessary competence.
Because the agent is cooperative, the misunderstood message is not ignored; the agent will
Actions transmit the message to an agent that seems to be relevant according to its representations
on others.
Name Partial incompetence

An agent is faced with partial incompetence when only one part of the received message
Description
has a meaning for it.
Conditions representation (words matching) and can extract an informative content from only a part of
the message.
The receiving agent sends back the partial answer associated with the understood part of
Actions
the message. It sends the other part of the request to a more relevant agent.
Name Ambiguity
An ambiguity occurs when the content of a received request is incomplete either because
Description the sender gets a bad description of the receiver’s tasks or because the specification of the
message is wrong.
Conditions representation (words matching) and can extract several informative contents from the
message.
An agent is supposed to intentionally and spontaneously send understandable data to the
others. Therefore, the receiver of an ambiguous message sends back all its interpretations
Actions
of the received request. The initial sender is then able to choose the most pertinent one and
update its representation about the receiver’s skills.
Name Concurrence
Description A situation of concurrence occurs when two agents have similar skills for a given task.
During the interpretation phase, the agent compares the received request with its own
representation (words matching). If it can extract an informative content from only a part of
Conditions the request, the agent compares this request with the representation it has about other
agents to find rival agents. An agent A competes with an agent B, from B’s point of view, if
A can extract informative content from the same part of the request as B.
Redundancy is beneficial when an agent has not been able to reach its aim or to accept a
Actions
task it has been asked to undertake. In these cases, it refers the problem to its rival(s).
TEAM LinG
For each table, at least one «cooperation»-stereotyped method has to be defined.

This method corresponds to the NCS detection and will be expressed using the
state and the conditions (i.e. methods and attributes) that are stereotyped with
«perception», «representation» or «characteristic». If several actions are possible
to remove the detected NCS, another method to choose the action to be
undertaken must be defined. This method is stereotyped with «cooperation». If
only one action is possible, the definition of this second method is useless: this
action will always be executed.
A17: Fast Prototyping
Once the behaviour of the agents involved in the concerned AMAS is defined,
the simulation functionality of OpenTool enables the designer to test them in a
new activity (A17).
This functionality of OpenTool requires a dynamic model (state-chart) for each
simulated entity (object or agent). The customized version of OpenTool is able
to automatically transform a protocol diagram (a particular generic sequence
diagram) into a state-chart. As agents’ behaviours are modelled as AIP protocol
diagrams, OpenTool is then able to simulate this behaviour by running a state-
machine. Therefore, uselessness or inconsistency of protocols, existence of
deadlocks in these protocols, or uselessness or exhaustiveness of methods can
be tested, for instance. This is done by creating the simulation environment using
a UML collaboration diagram in which instances of involved agents are carrying
out the generic protocol, and then, implementing some methods (using the
OTScript language that is the set-based action language of OpenTool) that will
be tested. If the behaviour of an agent is not adequate, the designer has to work
again on it to improve it.
The last activity of the design work definition consists in finalizing the detailed
architecture by enriching class diagrams (A18-S1) and then developing the state-
chart diagrams that are needed to design dynamic behaviours (A18-S2). The
objective is to highlight the different changes of state of an entity when it is
interacting with others. For «cooperative agent»-stereotyped classes that al-
ready have state-machine(s) (coming from A16-S3), the new identified states
have to appear in a new state-machine. This latter will be concurrent with the
first one(s).
By now, ADELFE is only able to guide the designer until this point. The next work
definitions would be those that are stipulated in the RUP: implementation and
test.
TEAM LinG
Strengths and Weaknesses of ADELFE
Strengths of ADELFE
Generally, agent-based and multi-agent based software gives a solution for

complex applications in which the environment is generally constrained. How-
ever, today’s and tomorrow’s applications are complex and open ones; they
evolve in an unpredictable environment, like the Internet, and represent the next
challenge for building software. To take up this challenge, it is necessary to
develop new models, tools, and methodologies.
The main strength of ADELFE (and its specificity) is to provide a methodology
to design Adaptive Multi-Agent Systems coupled with a theory for those
systems. According to the theory (Gleizes et al., 2000), self-organization by
cooperation enables an MAS to adapt itself and to realize a function that it is not
directly coded within its agents. ADELFE is thus a specialized methodology that
deals with only a certain kind of agents—cooperative ones—to build systems in
which the global function emerges from the interactions between these agents.
ADELFE is based on “standards” such as the RUP, UML, or AUML notations
to promote agent-oriented programming in an industrial world where object-
oriented software engineering is the norm.
Furthermore, as previously seen, ADELFE provides some tools, notably the
interactive tool that helps the designer to not only follow and apply the process
but also to produce the different artifacts needed during the process lifecycle.
OpenTool, the graphical modelling tool linked with ADELFE, supports the UML
notation and has been modified to integrate some AUML diagrams. For industry,
it is very important to know very early whether the system to be developed
justifies some investment in a new methodology or technique. Therefore,
ADELFE guides the developer in making the decision as to if and where AMAS
technology is required in the system being developed. This explains the impor-
tance of the adequacy checking in the analysis workflow and the adequacy tool
that analyses criteria given by the designer to decide if this technology is useful.
If the application is not suited to AMAS technology, the designer could use
another agent-oriented methodology.
ADELFE does not suppose that the agents in the designed system are known in
advance and offers a specific activity and some criteria to help the designer to
identify what entities in the system require implementation as agents. To decide
whether entities should be considered as agents, their features must be studied
as well as the interactions and the cooperation failures they may have.
TEAM LinG
The autonomous behaviour of an agent, which results from its perceptions,

knowledge, and beliefs, is very difficult to define in complex systems and in
dynamic systems. Actually it is very difficult to enumerate all possible actions for
each state of the environment. ADELFE specifically deals with AMAS;
following the theory, it only deals with a specific kind of agent architecture. The
methodology then provides cooperative agent architecture and some means to
endow an agent with a cooperative behaviour. Skills or representations of a
cooperative agent may evolve if this agent has to adjust them. In that case, they
will be implemented using AMAS, and the developer may reuse the entire
methodology to develop a part of the behaviour of an agent—ADELFE is a
recursive or iterative methodology. Finally, the greatest difficulty in this behaviour
definition is to identify Non Cooperative Situations that an agent may encounter,
and some models are given to help the designer to find these.
An automatic transformation from collaboration diagrams into state-machines
has been added to OpenTool to allow their simulation. Once the agents are
defined, this specific activity may be used to test the behaviour of an agent to
improve it if needed.
Modularity is also an important strength of ADELFE. It has been based on an
interpretation of the RUP by adding some specific activities and steps, namely,
those related to the AMAS technology. The process of ADELFE can then be
decomposed into fragments that may be reused in other agent-oriented method-
ologies 3. It would also be easier to integrate pieces coming from other method-
ologies into ADELFE. For instance, if the AMAS technology is useless, it would
be interesting to guide the designer towards a step of another methodology more
suited for his/her problem.
Limitations of ADELFE
The main strength of ADELFE could also be its major limitation; it is specialized
and therefore cannot be used to design all the existing applications or to model
all types of agents (e.g., BDI). For instance, to design a system such as
simulation software, embedding it within another system such as a simulation
platform, would be needed. Preliminary steps would therefore be required to
design the whole simulation software by studying the most external system and
expressing the needs of the user simulation (such as statistical results, observa-
tion algorithms, etc.). Nevertheless, this limitation by specialization is lessened
by integrating the AMAS adequacy verification activity into the process.
Furthermore, this limit could also be removed by coupling another methodology
with ADELFE. It would then be interesting to have a more general methodology
TEAM LinG
coupled with ADELFE in order to take into account both problem solving and
simulation software design.
Some activities could be improved, especially the fast prototyping one. For the
moment, it only enables the designer to test the behaviour of the defined agents
and validate them according to the specifications. We would like to improve this
activity to provide greater help during the design and implementation of agents.
The designer would be able to interact with the system during its design for
improving the behaviour of agents by adding or removing some parts of it.
Some work definitions are still lacking. At the present time, no operational tool
such as a platform or a set of software tools is coupled to ADELFE to guide
implementation, testing, or deployment.
The interactive tool is linked with OpenTool and verifies the production of
artifacts to make the designer progress in the process application. Although there
is no automated tool for consistency checking of the different activities results,
it is a future targeted improvement.
Finally a disadvantage of ADELFE is common to all design methods, the
graphical modelling tool is complex, and sometimes the designer may find it
difficult to use.
Purposeful Omissions
Some purposeful omissions were made in ADELFE, mainly due to the fact that
ADELFE tries to constrain the agent behaviour with a cooperative attitude.
Therefore, the role notion is useless because designers have only to focus on the
ability an agent possesses to detect and solve cooperation failures. If a designer
gives roles to agents, by describing a task or protocols, he/she will establish a
fixed organization for these agents. However, a fixed organization in an AMAS
is not welcomed because this organization must evolve to allow the system to
adapt.
Neither does the goal notion appear. The goal an agent has to achieve is modelled
by its skills, aptitudes, and representations; using the term “goal” in one of the
ADELFE models is not useful.
Using an ontology can be motivated by the agent granularity and may become
useful if agents are coarse-grained. But according to the AMAS theory, if agents
have to adapt themselves to their environment, they are also able to adapt to the
other agents. This adaptation can lead agents to learn to understand each other
making the use of ontology not essential in ADELFE.
TEAM LinG
Conclusions
This chapter devoted to the ADELFE methodology has first presented the
theoretical background that led to the development of this specialized method-
ology. Unpredictable situations due to interactions between agents or to the
openness of the environment are locally processed by agents composing the
system. Locally processing these cooperation failures is enough to change the
system organization, without relying on the knowledge of the global function that
must be obtained, and therefore to make the system adapt.
The ADELFE toolkit also provides some tools that have been briefly presented
in a second part: an interactive tool to help the designer to follow the process, a
graphical modelling tool to support the use of the dedicated notation, and an
AMAS adequacy tool to warn the designer if the problem is not suited to this kind
of technology.
The process of ADELFE is based on the RUP and uses UML and AUML
notations. It has been described in the third section of this chapter, using an
information system case study to better visualize how to apply the different
stages.
ADELFE aims at promoting a specific kind of MAS and is not a general
methodology. This specificity is its main strength but also one of its limitations.
Therefore, a first perspective of this work would be to define “fragments” that
could be interrelated with others, coming from different complementary method-
ologies. That would enable a designer to build his/her own methodology (adapted
to his/her particular needs) from different existing ones. A second perspective
of our work in the engineering domain would also be to endow ADELFE with a
tool that would automatically transform a meta-model into a model depending on
a target platform in the spirit of OMG’s Model-Driven Architecture (MDA)
initiative4.
Acknowledgments
We would like to thank the support of the French Ministry of Economy, Finance,
and Industry, as well as our partners: TNI-Valiosys Ltd. (for their customization
of Open-Tool), ARTAL technologies Ltd., and the IRIT software engineering
team (for their help and work on UML and SPEM).
TEAM LinG
References
Bernon, C., Camps, V., Gleizes, M-P., & Picard, G. (2004). Tools for self-
organizing applications engineering. In G. Di Marzo Serugendo, A.
Karageorgos, O. F. Rana, & F. Zambonelli (Eds.), First International
Workshop on Engineering Self-Organizing Applications (ESOA),
Melbourne, Australia (pp. 283-298). LNCS 2977, Berlin: Springer-Verlag.
Bernon, C., Gleizes, M-P., Peyruqueou, S., & Picard, G. (2002). ADELFE, a
methodology for adaptive multi-agent systems engineering. In P. Petta, R.
Tolksdorf, & F. Zambonelli (Eds.), Third International Workshop “En-
gineering Societies in the Agents World” (ESAW), LNAI 2577 (pp. 156-
169). Berlin: Springer-Verlag.
Brazier, F. M. T., Jonker, C. M., & Treur, J. (1999). Compositional design and
reuse of a generic agent model. In Proceeding of Knowledge Acquisition
Workshop (KAW’99), Banff, Canada.
Camps, V., Gleizes, M-P., & Glize, P. (1998). A self-organization process based
on cooperation theory for adaptive artificial systems. In Proceedings of
the First International Conference on Philosophy and Computer
Science “Processes of Evolution in Real and Virtual Systems”, Krakow,
Poland (pp. 2-4).
Capera, D., Georgé, J-P., Gleizes, M-P., & Glize, P. (2003). The AMAS theory
for complex problem solving based on self-organizing cooperative agents.
In Proceedings of the First International Workshop on Theory and
Practice of Open Computational Systems (TAPOCS03@WETICE 2003),
Linz, Austria (pp. 383-388). IEEE Computer Society.
Desfray, P. (2000). UML profiles versus metamodel extensions: An ongoing
debate. OMG’s UML Workshops: UML in the .com Enterprise: Mod-
eling CORBA, Components, XML/XMI and Metadata Workshop, No-
vember. Available online http://www.omg.org/news/meetings/workshops/
uml_presentations.htm
Georgé J-P., Gleizes, M-P., Glize, P., & Régis, C. (2003). Real-time simulation
for flood forecast: An adaptive multi-agent system STAFF. In Proceed-
ings of the AISB’03 symposium on Adaptive Agents and Multi-Agent
Systems, University of Wales, Aberystwyth (pp. 109-114). Society for the
Study of Artificial Intelligence and the Simulation of Behaviour.
Gleizes, M-P., Georgé, J-P., & Glize, P. (2000). A theory of complex adaptive
systems based on co-operative self-organisation: Demonstration in elec-
tronic commerce. In Proceedings of the Self-Organisation in Multi-
Agent Systems Workshop (SOMAS), Milton Keynes, UK, July 27-28.
TEAM LinG
Gleizes, M-P., Glize, P. & Link-Pezet, J. (2000). An adaptive multi-agent tool for
electronic commerce. In the Proceedings of the IEEE 9th International
Workshops on Enabling Technologies: Infrastructure for Collabora-
tive Enterprises (WET ICE’00), Gaithersburg, Maryland (pp. 59-66).
IEEE Computer Society.
Gleizes, M-P., Millan, T., & Picard, G. (2003a). ADELFE: Using SPEM notation
to unify agent engineering processes and methodology. IRIT Internal
Report 2003-10-R.
Iglesias, C.A., Garijo, M. & Gonzalez, J.C. (1998). A survey of agent-oriented
methodologies. In Proceedings of the Fifth International Workshop,
ATAL ’98, LNAI 1555, Paris, July 4-7 (pp. 317-330). Berlin: Springer-
Verlag.
Kruchten, P. (2000). The rational unified process: An introduction. Reading,
MA: Addison Wesley.
agents. In Proceedings of the Agent Oriented Information Systems
(AOIS) Workshop at the 17th National Conference on Artificial
Intelligence (AAAI), Austin, Texas (pp. 3-17).
Odell, J., Van Dyke Parunak, H., & Bauer, B. (2001). Representing agent
interaction protocols in UML. In Proceedings of the First International
Workshop on Agent-Oriented Software Engineering (AOSE’00), Lim-
erick, Ireland, pp. 121-140. Berlin: Springer-Verlag.
OMG. (2002). Software Process Engineering Metamodel Specification.
Available online http://cgi.omg.org/docs/formal/02-11-14.pdf
Picard, G. (2003). UML stereotypes definition and AUML notations for ADELFE
methodology with OpenTool. Proceedings of the First European Work-
shop on Multi-Agent Systems (EUMAS’03), Oxford, UK.
Piquemal-Baluard, C., Camps, V., Gleizes, M.-P., & Glize, P. (1996). Properties
of individual cooperative attitude for collective learning. In Proceedings of
the Seventh European Workshop on Modelling Autonomous Agents in
a Multi-Agent World (MAAMAW’96), Eindhoven, The Netherlands,
January 22-25, position paper.
Russel, S. & Norvig, P. (1995). Artificial intelligence: A modern approach.
Englewood Cliffs, NJ: Prentice Hall Series.
based systems. In Proceedings of the Fifth International Conference
on Autonomous Agents (pp. 624-631). New York: ACM Press.
Topin, X., Fourcassie, V., Gleizes, M-P., Theraulaz, G., Régis, C., & Glize, P.
(1999). Theories and experiments on emergent behaviour: From natural to
TEAM LinG
artificial systems and back. In Proceedings of the European Conference

on Cognitive Science, Siena, October 27-30.
Wood, M. & DeLoach, S. (2000). An overview of the multiagent systems
engineering methodology. In Proceedings of the First International
Workshop on Agent-Oriented Software Engineering (AOSE’00), Lim-
erick, Ireland (pp. 207-221). Berlin: Springer- Verlag.
Wooldridge, M. (2002). An introduction to multi-agent systems. New York:
Wiley.
Endnotes
1
Agents and MASs notions are introduced in Chapter I.
2
See Chapter I for more details about modelling languages.
3
Ed. As will be discussed in Chapter XIII.
4
Some hints about MDA are given in Chapter I.
TEAM LinG
The MESSAGE Methodology for Agent-Oriented Analysis and Design 203
Chapter VIII
The MESSAGE
Methodology for
Agent-Oriented
Analysis and Design
Francisco J. Garijo
Telefónica I+D, Spain
Jorge J. Gómez-Sanz
Universidad Complutense de Madrid, Spain
Philippe Massonet
CETIC, Belgium
Abstract
This chapter presents the MESSAGE agent-oriented software engineering

methodology and illustrates it in an analysis and design case study. The
methodology covers MAS analysis and design and is intended for use in
mainstream software engineering departments. MESSAGE integrates into a
coherent AOSE methodology basic agent-related concepts (such as
organisation, role, goal, interaction, and task) that have so far been
studied largely in isolation. The MESSAGE notation extends the UML with
agent knowledge-level concepts and diagrams with notations for viewing
them. The proposed diagrams extend UML class and activity diagrams. The
TEAM LinG
204 Garijo, Gómez-Sanz & Massonet
MESSAGE analysis and design process is based on the Rational Unified

Process (RUP). The methodology distinguishes high-level from detailed
design. An organisation-driven approach is presented for detailed design,
where the global architecture of the MAS is derived from the structure and
behaviour of the organisations that interact. Experimentation with the
methodology shows that it supports the analysis and design of multi-agent
systems that are flexible and adapt to specific kind of changes in a
heterogeneous and dynamic environment.
Introduction
The agent-oriented (AO) approach promises the ability to construct flexible
systems with complex and sophisticated behaviour by combining highly modular
components. When several of these components interact, the intelligence of
these components—the agents—and their capacity for social interaction results
in a multi-agent system (MAS) with capabilities beyond those of a simple “sum”
of the capabilities of the individual agents.
The availability of agent-oriented software engineering (AOSE) methodologies
is a pre-requisite for engineering commercial MASs. The MESSAGE method-
ology covers the MAS analysis and design phases of the software engineering
lifecycle. It is designed for use in mainstream software engineering departments
that develop complex distributed applications. It is a genuinely agent-oriented
methodology, but also builds upon the achievements of software engineering
(SE), and is consistent with current SE best practice. MESSAGE grounds agent-
oriented concepts in the same underlying semantic framework as that used by
UML, and uses UML-based notation whenever appropriate.
MESSAGE (Caire, Courlier et al., 2001, 2002) extends UML by contributing
agent knowledge-level concepts, such as organization (Zambonelli, Jennings, &
Wooldridge, 2001), role (Kendall, 2000), goal (Dardenne, Lamsweerde, &
Fickas, 1993; Giorgini, Kolp, Mylopoulos, & Pistore, 2004) and task (Omicini,
2000), and diagrams with notations for viewing them. The work is illustrated in
a complete agent case study going through the phases of analysis and design.
The plan of the chapter is as follows. The next section describes the MESSAGE
modelling language and process, followed by a section that describes the analysis
case study and illustrates some of the graphical notation proposed. The high-level
design case study is then presented. Next, we illustrate the organization-driven
detailed design process. The final section presents an evaluation of MESSAGE
based on analysis, design, and implementation experimentations.
TEAM LinG
The MESSAGE Methodology

The MESSAGE methodology has adopted the Rational Unified Process (RUP)
(Kruchten, 1999) as a generic software engineering project lifecycle frame-
work. This allows MESSAGE to incorporate the body of software development
knowledge – life cycles, activities, tasks, notations in UML (such as Use Case
Models, Class Diagrams, Interaction Diagrams, State Transition Diagrams), and
supporting UML tools - which can be applied for agent-oriented development.
MESSAGE follows the iterative and incremental approach of RUP that involves
progressive refinement of the requirements, plan, design, and implementation. It
focuses on the elaboration phase where the core system architecture and high-
risk factors need to be identified. The architecture is elaborated using a collection
of agent-related models and graphical notations. Specific guidelines for the
creation and stepwise refinement of these models during analysis and design are
also provided. In summary, MESSAGE extends UML with new agent-related
concepts and graphical notations and enriches and adapts the RUP process
model for agent-based analysis and design. MESSAGE also includes guidelines
and examples on how to apply the methodology (Milgrom et al., 2001).
The MESSAGE refinement process is described in Figure 2. MESSAGE
analysis results in a collection of models describing the system to be developed
and its environment. The following five views on the models have been defined
to help the modeler focus on coherent subsets of the multi-agent system:
Organization, Goals/Task, Agent/Role, Interaction, and Domain. Similar divi-
sions can be found in MAS-CommonKADS (Iglesias, Mercedes Garijo, Gonzalez,
& Velasco, 1998), Vowel Engineering (Demazeau, 2001) and GAIA (Wooldridge,
Jennings, & Kinny, 2000).
At this point we may remark on the distinction between view and model in this
methodology, which differs from MASSIVE (Lind, 2001). A view in MASSIVE
and MESSAGE could be understood as a projection of the complete model onto
a particular subject. A model is a container for the concepts that specifies that
subject. MASSIVE considers that there is only one model whereas MESSAGE
requires several. There is, for example, one Organization Model, but many
views of this model that show different parts of the same concept. A view can
be an acquaintance diagram showing the acquaintance relationships among
different agents in the organization, or a task workflow diagram showing how
functionality is distributed among different actors within an organization.
The Organization model describes the overall structure of the MAS. It shows
concrete entities (Agents, Organizations, Roles, Resources) in the system and its
environment and coarse-grained relationships between them (aggregation, power,
and acquaintance relationships). The Goal/Task model describes the goals the
MAS and its constituent agents try to attain and the tasks they must accomplish
in order to satisfy the goals.
TEAM LinG
The Agent/Role model focuses on the individual agents and roles. For each
agent/role, it uses schemata supported by diagrams to describe its characteris-
tics, such as the Goals for which an agent is responsible, the events it needs to
sense, the resources it controls, the Tasks it knows how to perform, “behaviour
rules,” and the like. The agent model contains a detailed and comprehensive
description of each individual agent and role within the MAS.
The Interaction model is concerned with agent interactions with human users and
other agents. For each interaction among agents/roles, the initiator, it shows the
collaborators, the motivator (generally a goal the initiator is responsible for), the
relevant information supplied/achieved by each participant, and the events that
trigger the interaction, together with other relevant effects of the interaction
(e.g., an agent becoming responsible for a new goal).
The Domain (information) model shows the domain-specific entities and rela-
tions that are relevant for the system under development.
The above models contain the data that defines the system and that is repre-
sented in the views. The MESSAGE meta-model is defined as an M-2 Layer
meta-model using the MOF four-layer architecture (OMG, 2000). The MES-
SAGE meta-model provides the concepts, the underlying structure, and the rules
for producing application models.
Figure 1 shows the main agent-related meta-concepts (Caire, Coulier, et al.,
2002; EURESCOM P907, 2003), for example, an Agent is an atomic autonomous
entity that is capable of performing some (potentially) useful function. In these
diagrams, each concept is related to others using labeled associations, denoting
the semantics of the association.
The MESSAGE concepts extend UML concepts by means of the MOF
generalization primitive. For instance, the agent concept extends the MESSAGE
Entity that extends the UML classifier concept.
During design, the analysis models are refined into computational entities that
can be implemented in an agent platform. Two distinct phases of design are
considered: high-level and detailed design. The first phase involves identifying an
agent architecture, assigning roles to agents, and describing how the application
services are provided in terms of tasks. The tasks can be decomposed into direct
actions on the agent’s internal representation of the environment, and commu-
nicative actions to send and receive messages according to interaction protocols.
The interactions between roles identified in analysis are detailed using interaction
protocols. Detailed design deals with computational representations of the
entities modelled in high-level design. During this second phase, the refinement
process continues to determine how entities can be implemented. In MESSAGE,
two approaches are considered: organization-driven and the agent platform-
driven design. This process is illustrated in Figure 2.
TEAM LinG
Figure 1. Agent-related MESSAGE meta-concepts
Goal Role
Provides
AimsToAchieve ServiceTo Service
Plays
Information
Entity Agent
Implements
Perceives
Acquaintance
Describes Performs
Action Task
Describes Event
StateOf
Generates
GeneratedBy
ChangeOfState
Resource Affects DirectAction

DirectAction Communicative
Communicative
Action
Action
Figure 2. MESSAGE modelling process description
ANALYSIS MODEL
TSP
TSP
Parent KM Parent KM
pane sy stem
pane sy stem
< < Wish > > < < Wish > >
1 1 1 ..*
1 1 1 ..*
1..*
Structure Tra veller Structure Tra veller
1 ..*
KM
A dmin-
istrativ e
Sales
Sys te m pane A ss is ted
pane A ss is ted
Sys te m Team A dmin -

A dmin - Team istrator
KM Sales Sys te m
istrativ e A dmin -
Sys te m Team
Team istrator 1..* 1 ..*
1 1
Tra vel
Catalog
1..* 1 ..* Sales -
1 1 Book ing Tra vel
per son
Tra vel D atabas e D atabas e
LEVEL 0
Catalog
Sales -
Book ing Tra vel
per son
D atabas e D atabas e
Initiator Collaborator
Parent <<participation>> <<participation>>
KM Travelling TSP
Sys te m pane system TA Gatherer Request 1 Assistant
A dmin i - A dmin - Tra veler
stra tor istratio n << Wish >>
Team
Structure Tra veller
pane A ss is ted Travel

KM
Sales -
per son
1 Requirement 1
Sys te m
Tra velling Tra vel Bes t Trav el Tra vel

Retrieves tr avel Store s boo kin g s
Sen ds Requ ir ements A rr angeme nts A rr angeme nt A rr angeme nt
Travel
ar rang ements
K now n G athere d I den
Id entif
tified
ied Selected
LEVEL 1
1..* 1..*
Tra vel Arrangement
Tra vel Book ing
Catalog
D atabas e D atabas e Child
pane TSP TA Gatherer TA Selector
Assistant
LEVEL N
REFINES
DESIGN MODEL
HIGH LEVEL DESIGN
Travelling <<provision>> Travelling-
Personal Arrangements
Travel TSP Sales PTA arrangement-
Provided Assistant selection
Agent
Booking Request Diagnosed
TravelRequirement TravelArrangement Formulated
<<wish>> <<play>> TSP Airline
Booking Booking Not Understood
Provide Travelling TSP Refuse
Flight Services Booking Get travel Send / Score travel Request, TA Booking Request Booking Request
Availability Provider <<play>> Manager Arrange- Receive arrange- Submitted Cancelled
ments TAs ments
<<accesses>> < < per for mance > >
Agree Failure
<<provision>> < < per for mance > > Agree
<<manages>>
Not-understood Booking Request
Flight Booking Request
ProvideTravel Confirmed
Destinations Traveler Agreed
Arrangement
s TSP TA TA Refuse
Requirements Assistant Selector
Gatherer Inform
REFINES
DETAILED LEVEL
ORGANIZATION DESIGN
AGENT PLATFORM
AGENT PLATFORM
ORGANIZATION
DRIVEN
DRIVEN DESIGN DRIVEN DESIGNDRIVEN
TEAM LinG
MESSAGE Concepts and Notation
The MESSAGE modelling language is based on RUP notations that are, in turn,
based on UML. MESSAGE extends the basic UML concepts of Class and
Association with knowledge-level agent-centric concepts and modelling views
(Caire, Coulier, et al., 2001). The most important agent-related concepts are the
following.
• Agent: An Agent is an atomic autonomous entity that is capable of

performing some (potentially) useful function. The functional capability is
captured as the agent’s services. The quality of autonomy means that an
agent’s actions are not solely dictated by external events or interactions, but
also by its own motivation. We capture this motivation in an attribute named
purpose. The purpose will, for example, influence whether an agent agrees
to a request to perform a service and also the way it provides the service.
• Organization: An Organization is a group of Agents working together to
a common purpose. It is a virtual entity in the sense that the system has no
individual computational entity corresponding to an organization; its ser-
vices are provided and purpose achieved collectively by its constituent
agents. It has structure expressed through power relationships (e.g.,
superior-subordinate relationships) between constituents, plus behaviour/
coordination mechanisms expressed through Interactions between con-
stituents.
• 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. Roles
can also be used as indirect references to Agents. This is useful in defining
re-usable patterns.
• Goal: A Goal associates an Agent with a state. If a Goal instance is present
in the Agent’s working memory, then the Agent intends to bring about the
state referenced by the Goal.
The main types of activity are:
• 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 pre-condition is valid, then one
can expect the associated post-condition to hold when the Task is com-
TEAM LinG
pleted. Composite Tasks can be expressed in terms of causally linked sub-

tasks (which may have different performers from the parent Task). Tasks
can be modelled as state machines, so that, for example, UML activity
diagrams can be used to show temporal dependencies of sub-tasks.
• Interaction and Interaction Protocol: An Interaction is characterized by
more than one participant and the purpose that 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 to 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.
The MESSAGE notation is based on UML. Agent-related concepts are defined

as level 2 meta-models using OMG’s meta-model Facility, MOF (OMG, 2000).
The organization model, for example, is defined as an M-2 Layer meta-model
using the MOF four-layer architecture. One of the practical advantages of this
approach is that UML tools, which will help engineers to create, manage, and
reuse object-oriented application models, can interpret MOF meta-models to
provide tool support for analysis and design using MESSAGE.
Figure 3 shows the graphical syntax of some of the above-mentioned level-1
concepts. The Assignment meta-relationship is specialized into “Play: Agent x
Role,” “Wish: Agent x Goal,” “Perform: Agent/Role x Task,” “Participates: Role
x Interaction,” “Implements: Task x Service,” and “Provides: Agent/Role/
Organization x Service.”
Figure 3. MESSAGE graphical notations
Agent Role Organization
Implication Assignment
Goal Task Service
Acquaintance DataFlow
Interaction Structure
TEAM LinG
Analysis
The purpose of analysis is to produce a system specification (or analysis model)

that describes the problem to be solved (i.e., the requirements). It is represented
as an abstract model in order to (1) understand the problem better, (2) confirm
that this is the right problem to solve (validation), and (3) facilitate the design of
the solution. It must therefore be related both to the statement of requirements
and to the design model (which is an abstract description of the solution). MAS
analysis focuses on defining the domain of discourse and describing the
organizations involved in the MAS, their goals, and the roles they have defined
to satisfy them.
High-level goals are decomposed and satisfied in terms of services provided by
the roles. The interactions between roles that are needed to satisfy the goals are
also described. The analysis models are produced by stepwise refinement.
Analysis Process
The analysis model is produced by stepwise refinement. The top level of

decomposition is referred to as level 0. This initial level is concerned with defining
the system to be developed with respect to its stakeholders and environment. The
system is viewed as a set of organizations that interact with resources, actors,
or other organizations. Actors may be human users or other existing agents.
Subsequent stages of refinement result in the creation of models at level 1, level
2, and so on.
At level 0, the modelling process starts building the Organization and the Goal/
Task models. These models then act as inputs for creating the Agent/Role and
the Domain models. Finally, the Interaction model is built using input from the
other models. The level 0 model gives an overall view of the system, its
environment, and its global functionality. The granularity of level 0 focuses on the
identification of entities and their relationships according to the meta-model.
More details about the internal structure and the behaviour of these entities are
progressively added in the next levels.
In level 1, the structure and the behaviour of entities such as organization, agents,
tasks, and goals domain entities are defined. Additional levels might be defined
for analyzing specific aspects of the system dealing with functional requirements
and non-functional requirements, such as performance, distribution, fault toler-
ance, and security. There must be consistency between subsequent levels.
Several strategies are possible for refining level 0 models. Organization-centred
approaches focus on analyzing overall properties, such as system structure, the
services offered, global tasks and goals, main roles, and resources. The agents
TEAM LinG
needed for achieving the goals appear naturally during the refinement process.
Then, cooperation, possible conflicts, and conflict resolution may be analyzed.
Agent-centred approaches focus on the identification of agents needed for
providing the system functionality. The most suitable organization is identified
according to system requirements. Interaction-oriented approaches suggest
progressive refinement of interaction scenarios that characterize the internal and
external behaviour of the organization and agents. These scenarios are the
source for characterizing task, goal, messages, protocols, and domain entities.
Goal/task-decomposition approaches are based on functional decomposition.
System roles, goals, and tasks are systematically analyzed in order to determine
the resolution conditions, problem-solving methods, decomposition, and failure
treatment. Task preconditions, task structures, task output, and task post-
condition may determine what Domain Entities are needed. Agents playing roles
must perform tasks to meet their goals. Consequently, looking at the overall
structure of goal and tasks in the Goal/task view, decisions can be made on the
most appropriate agents and organization structure for achieving those goals/
tasks.
The experience in MESSAGE shows that the different views of the system leave
the analyst free to choose the most appropriate strategy. In practice, a combi-
nation of refinement strategies with frequent feedback loops are used. The
analysis process might start with the Organization View (OV), then switch to the
Agent View and continue with the Interaction View. The results of the analysis
of specific interaction scenarios may lead to the reconsideration of part of the
OV and thus to further refinement and adaptation of OV constituents.
Design
The purpose of design is to define computational entities that represent the MAS
appearing at the analysis level. In general, the artifacts produced in each of the
analysis models need to be transformed into computational entities that can be
implemented. Analysis entities are thus translated into subsystems, interfaces,
classes, operation signatures, algorithms, objects, object diagrams, and other
computational concepts.
High-Level Design Process
The design process consists of a series of iterative activities for transforming

analysis models into design artifacts. The transformation process is highly
dependent on the level of abstraction of the analysis entities. As analysis agents
TEAM LinG
are defined in generic terms, during design it may be necessary to refine them
into one or more computational entities. There are situations in which agents
identified during analysis are not implemented in design. This happens when
analysis agents are refined into simple classes in design, and when agents from
the analysis correspond to very well-known software components such as
access systems, notification servers, database wrappers, proxies, and so on. In
such situations, it is better to consider analysis agents as resources. On the other
hand, analysis agents will be implemented in design when the complexity of the
refinement requires an agent architecture.
MESSAGE distinguishes between high-level and detailed design to keep the
models implementation independent and thus avoid taking into account the
complexity of the specific concepts and constraints of a target agent platform,
such as the agent architecture and the knowledge representations.
In high-level design, the analysis model is refined to produce the initial version
of the MAS architecture and its computing behaviour defined with design
artifacts. Four steps are proposed:
1. Assigning roles to agents. Organization roles identified in analysis should be

assigned to agents in order to assess their computational tractability.
Design decisions are strongly dependent on the designer’s views and
experience, although heuristic criteria might be applied, for example,
assigning to an agent a single complex role, grouping similar functional roles
and assigning them to an agent.
2. Providing services with tasks. If any analysis workflow diagrams in the
Organization Model (OM) have been defined, they can be further refined
in this stage. The refinement process should specify the relationships
between services and tasks, tasks and goals, and goals to roles.
3. Refining the interaction protocols. This step involves refining the interac-
tions identified in analysis. Interactions can be modelled in terms of
interaction protocols (Odell, Parunak, & Bauer, 2001) and UML state-
charts. This modelling takes into account the interactions between roles, the
assignment of agents to roles, and the implementation of services in terms
of tasks, direct actions, and communicative actions.
4. Interaction role behaviour specification with statecharts. This step involves
modelling the behaviour of the roles in an interaction protocol. The result
will establish relationships between the interaction model, the agents
behaviour model, and the overall functionality of the organization
TEAM LinG
Detailed Design Process
The low-level design process assumes that the developer is thinking about
possible implementations. This process implies consideration of different map-
pings, from high-level design concepts to computational elements provided by the
target development platforms. By computational, we mean having an application
program interface with an externally known behaviour. These elements may
already exist, for example, as a software library, or will need to be developed
from scratch. The MESSAGE methodology has been evaluated with two
complementary design approaches.
The first design approach is driven by the MAS organization The design process
is driven by the Organization Model in order to assign responsibilities, to define
agent interactions, and to model social knowledge.
The second approach is agent-platform-oriented and considers that each agent
can be mapped to a class. This is mainly derived from the application of most
agent models supported by agent building tools, such as Jade (Bellifemine, Poggi,
& Rimassa, 2001), in which there is one agent class from which to derive the
specific agent type.
Organization-Driven Detailed Design Process
The Organization Model provides a high-level view of the system with all the
elements needed for structuring its computational entities. The organization itself
may or may not be present as a computational element at the end of the design.
The Organization Model shows which roles need to interact, their communication
needs, and what social knowledge is required from each agent in order to satisfy
the system goals, that is, the organization goals. Individual realization of tasks or
service provision is easier to design than collective realization.
The steps proposed to achieve organization driven design are as follows:
• Defining the multi-agent system architecture. The Organization Model

defines a preliminary architectural framework where the principal comput-
ing entities are the agents. The agents’ environment is made up of the rest
of the computing entities, which are used by agents or have direct or indirect
relationships with them. Design packages are structured according to the
OM: Tasks, Goals, Resources, Workflows, and Agents within Organization
Structures, each of which might be refined separately. They might be
directly translated into computational units. The Organization Model im-
poses constraints upon agent relationships, common tasks, and global goals.
TEAM LinG
Figure 5. Organization diagram view (acquaintance relationships) (notation

as in Figure 3)
System
Admini- Admin- Traveler
strator istration
Team
KM Sales-
System person
Retrieves travel Stores bookings

Sends
arrangements
Travel
Travel Booking Catalog
Database Database
Figure 5 shows the acquaintance relationships in the level 0 organization

diagram. The KM system interacts with two roles, the System Administrator and
the Salesperson, and with two external systems (resources), the Travel Data-
base to retrieve travel arrangements and the Booking Database to insert the
bookings requested by salesperson on behalf of Travelers. Moreover, it interacts
with the Administrative Team to prepare the bills that will be sent to travellers.
A Salesperson interacts with Travelers to gather travel requirements and provide
travel arrangements. It should be noted that the Salesperson does not interact
directly with the Travel Database and the Booking Database. All these interac-
tions are carried out through the KM system.
Goals, Roles, and Services
Organizations have high-level goals that the roles need to satisfy by providing and
requesting services. The organization goals can be decomposed using goal
decomposition techniques into goals that can be directly satisfied in terms of the
services that are offered by a role. For example, the “Traveler Assisted” goal
of the traveller is partially satisfied by the goal “TA Gathered” of the “TA
Gatherer” role, together with its goals “Best TA identified” and “TA Selected”
of the “TA Selector” role. The services that need to be provided to satisfy these
goals are “TA Gathering” and “Best TA Selection.”
TEAM LinG
These constraints should be satisfied under behavioural changes and

organizational dependencies.
• Selecting an agent architecture. Agents are designed as instantiations of a
specific kind of agent architecture, whose complexity depends on the roles
that have been assigned to the agents in the organization and the kind of
relationships with other agents (e.g., whether interactions involve complex
protocols or not). In MESSAGE, there have been experiments with
cognitive (BDI agents) and reactive architectures (state-machine-based
agents).
• Specifying the agent’s behaviour and interfaces. This includes the agent’s
domain and social knowledge. This is defined using the structure and the
relationships of the Organization Model. It supports reasoning about other
agent’s actions, about the society itself, and the social constraints upon an
agent’s actions (Garijo, Gómez-Sanz, Pavón, & Massonet, 2001)
• Using conventional software engineering modelling techniques can help to
detail internal agent architecture behaviour. For instance, sequence dia-
grams can be used to clarify interactions, activity diagrams to model the
sequence of states reached by agents when performing tasks, and use
cases to detail the expected functionality of the final system.
• Defining the agent society infrastructure. The infrastructure consists of
available resources, dependence relationships among agents, capabilities
of other agents, or assigned tasks. We have called those computing entities
that are not agents and are used by the agents to obtain information for
achieving their objectives “resources.” Examples of resources are: data-
bases, protocol stacks, text-to- speech translators, speech processors,
visualization systems, syntactic analyzers, and the like.
The Organization Model supports designers in rationalizing and working in

parallel on the refinement work. It also guides the refinement process and helps
to maintain consistency among analysis entities, design entities, and system
requirements.
Agent-platform Detailed Design
Another approach to the transition from high-level design to low-level design is

to define a mapping between the implementation-independent MESSAGE
analysis/design concepts and the target implementation-dependent concepts. A
case study on the transition (Massonet, Deville, & Neve, 2002) between a
MESSAGE design and a FIPA- compliant agent implementation toolkit was
carried out with the JADE framework (Bellifemine et al., 2001) and the Jess
TEAM LinG
are several teams in the TSP. At level 0, the system under development, namely,
the KM System, is seen itself as an organization that will be analyzed at level 1.
Goal
The goal of the TSP is to assist the traveller. This could be understood as the TSP
arranging a restaurant, renting a room in a hotel, providing information on tourist
places, and so forth. This goal is very generic and will be refined in level 1. Level
0 is kept simple in order to clearly separate the first idea of the system from its
refinement.
Domain
The domain can be conveniently described using UML class diagrams to model
the classes, their associations, and their attributes. Examples of classes that
model domain entities and relationships are: “Travel Requirement” (TR), which
is composed of a set of “Transfer Requirements” (TsR) that specify an origin,
a destination, and a time frame; a “Travel Arrangement” (TA), which is
composed of a set of “Transfer Arrangement” (TsA) that refers to a “Flight
Occurrence.” A flight occurrence refers to a flight from an origin to a destination
on a specific date. A TA can match a TR if all TsR match the TsA.
Figure 4. Organization diagram view (structural relationships) (notation

as in Figure 3)
TSP
1 1 1..* 1..*
Admin- System
KM istrative Sales
System Team Admin-
Team istrator
1..* 1..*
1 1
Travel
Catalog
Sales-
Booking Travel
person
Database Database
TEAM LinG
Delegation structure diagrams, workflow diagrams, and textual agent/role

schemata are useful for describing the Agent/Role view. The term structure is
used to emphasize the fact that it is an extended class diagram that describes the
structure. UML provides an aggregation relation (diamond-headed line) to
express a relationship between a composite entity and its constituents. 1 How-
ever, it is rarely the case that the parent-constituent relationship is simply one of
aggregation. The structural framework into which the constituents must fit is
usually important. The structure concept is introduced in order to describe such
frameworks in a reusable way. In the case of a goal/task diagram, it expresses
how a goal of an organization is decomposed into , which are then assigned to the
Organization’s constituents.
A delegation structure diagram shows how the subgoals obtained decomposing
a goal of an organization are assigned to the agents/roles included in the
organization. Clearly this diagram is strictly related to (and must be consistent
with) both the goal decomposition diagram showing the decomposition of the
organization goal and the organization diagram showing the agents/roles inside
the organization.
Figure 6 shows a delegation structure diagram. Only the root and the leaves of
the decomposition of the parent organization goal are shown. Similarly, a
workflow diagram shows the roles in an organization that must perform the tasks
necessary to implement a given service provided by the organization. An
example of this type of diagram is shown later in Figure 9.
Figure 6. Delegation structure diagram view (notation as in Figure 3)
Parent KM
pane system
<< Wish >>
Structure Traveller
pane Assisted
Travelling Travel Best Travel Travel

Requirements Arrangements Arrangement Arrangement
Known Gathered Identified Selected
Child
pane TSP TA Gatherer TA Selector
Assistant
TEAM LinG
Interactions
This view highlights which, why, and when agents/roles need to communicate,
leaving all the details about how the communication takes place to the design
process.
The interaction view is typically refined through several iterations as long as new
interactions are discovered. It can be conveniently expressed by means of a
number of interaction diagrams. These diagrams are interaction centric (i.e.,
there is one
such diagram for each interaction) and show the initiator, the responders, and the
motivator (often a goal of the initiator) of an interaction, plus other optional
information such as the trigger condition and the information achieved and
supplied by each participant. Figure 7 shows as an example the interaction
diagram describing the Traveling Request interaction between the TA Gatherer
and the TSP Assistant roles.
The details of the interaction protocol and the messages that are exchanged
between roles can be represented using an AUML sequence diagram (Bauer,
Müller, & Odell, 2001). The modelling of an interaction protocol is on the border
between analysis and design. The interaction can be detailed either in analysis
or in design. The analysis stops here, but more iterations could be made.
Figure 7. Interaction diagram view (notation as in Figure 3)
Initiator Collaborator
<<participation>> <<participation>>
Travelling TSP
TA Gatherer Request 1 Assistant
Travel
1 Requirement 1
Travel 1..*
1..*
Arrangement
TEAM LinG
rule-based system for reasoning (Friedman-Hill, 2002). It was illustrated on a

subset of the case study described in the next section and showed how the high-
level agent concepts of the analysis and design modelling language could help
structure the agent implementation that is usually based on a simpler set of agent
concepts. The case study showed that high-level design decisions were easier
to make using MESSAGE than using the implementation-dependent concepts.
This approach is not described further in this chapter.
Analysis: Travel Agent Case Study

This section shows how the development process and notation can be applied to
the case study. The first step should be to identify the level 0. This level requires
identifying first the organization involved and the goals it pursues.
• Context: traveling from one location to another involves creating a travel

plan with a very tight schedule. It might involve taking a taxi from one’s
home to the airport, taking a flight to an intermediate location, taking a
connecting flight to the final destination where a rented car has been booked
and can be picked up to drive to the hotel where reservations have been
made. Unfortunately for the traveler, many things can go wrong with a
travel plan.
• Requirements: Given the fact that many travellers will soon have wireless
terminals, the efficiency of the traveling process can be improved by
developing a system (distributed both in these terminals and in the terrestrial
network) that:
• gathers travel requirements from the traveller;
• assists in identifying and arranging relevant travel services offered by
the travel service providers;
• assists with the booking of travel tickets; and
• monitors that the travel arrangement is carried out as planned by
providing alerts and notifications of changes to arranged travels.
Organizations
Figure 4 describes structural relationships in a level 0 organization diagram. The

diagram shows that the Knowledge Management (KM) system is owned by the
Travel Sales Person system (TSP). A Salesperson is part of a team and there
TEAM LinG
Figure 9. Task workflow view
<<provision>> Travelling-
PTA arrangement-
selection
TravelRequirement TravelArrangement
Get travel Send / Score travel

Arrange- Receive arrange-
ments TAs ments
<<performance>>
<<performance>>
TSP TA TA
Assistant Gatherer Selector
with the services it provides, the roles that it plays, together with the tasks and
resources upon which it relies.
Implementing Services with Tasks
Once the agents have been assigned to roles, the services can be implemented
in terms of tasks. Figure 9 shows the workflow of tasks that is needed for the
PTA agent to provide the “TA selection” service to the traveller. The input to
the “Get TAs” task of the “TSP Assistant” role is a TR using the object flow
UML notation. The output is a set of TAs that is sent to the “TA Gatherer” role,
which then passes them to the “TA Selector” role to rank them.
Interaction Protocols
This step involves refining the definition of interactions made during analysis.
Based on the interactions between roles, the assignment of agents to roles, and
the implementation of services in terms of tasks, direct actions, and communica-
tive actions, the interactions can be modelled in terms of interaction protocols and
UML statecharts. Figure 10 shows how the interaction between the “TSP
Booking Manager” and the “Airline Booking” roles can be modelled with a FIPA
TEAM LinG
Figure 10. Partial request interaction protocol
TSP Airline
Booking Booking
Request, TA
Agree
Not-understood
Refuse
request interaction protocol. A TA is passed as the content of the request

message.
Interactions Roles Defined with State Machines
This step involves modelling the behaviour of the roles in an interaction protocol.
Figure 11 shows how the “TSP Booking Manager” role’s behaviour can be
modelled for the request interaction protocol. When a booking request is refused
or not understood, it is diagnosed and a decision is made to either cancel the
request or retry the request.
Figure 11. TSP booking manager state chart
Booking Request Diagnosed

Formulated
Not Understood
Refuse
Booking Request Booking Request
Submitted Cancelled
Failure
Agree
Booking Request Booking Request

Agreed Confirmed
Inform
TEAM LinG
High Level Design Example

The transition from analysis to high-level design requires identifying the agents
for achieving the system functionality, deciding their computing model, and
specifying the behaviour of the overall organization in computational terms. To
achieve these goals, we will use the four step method that was presented
previously in the high level design section. Examples of the four steps are
described in the following sections.
Identifying Agents and Assigning Roles
Agents are identified based on the description of the organizations and the use
of some heuristic: at one extreme, for each organization there can be one agent,
assigned all the roles in the multi-agent application; at the other extreme, there
is one agent per role.
In this case study, a personal travel agent (PTA) was created for the traveller,
a TSP agent was created for the TSP organization, and an airline agent was
created for the airline organization. Assigning roles to agents has an impact on
the design of the interactions. For example, since the “TSP Sales Assistant” and
“TSP Booking Manager” need to interact and are played by the same agent, they
do not need to interact using interaction protocols. Figure 8 shows the TSP agent
Figure 8. Agent diagram view (notation as in Figure 3)
Travelling
Personal Arrangements
Travel TSP Sales
Provided Assistant
Agent
<<play>>
<<wish>>
Provide Travelling TSP

Flight Services Booking
Availability Provider <<play>> Manager
<<accesses>>
<<provision>>
<<manages>>
Flight ProvideTravel
Destinations Traveler Arrangements
Requirements
TEAM LinG
Organization-Driven
Detailed Design Example
At the detailed design stage, MESSAGE considers two approaches: the agent-
platform-driven and the organization-driven. An agent-platform-driven design
(Massonet et al., 2002) is based on the mapping between the high-level design
concepts and the target platform. However, this may not be possible when the
agent platform is not known in advance or when the agent platform does not
satisfy the computing requirements of the target computing infrastructure. This
section focuses on the organization-driven approach.
Organizational Model
The Organization Model defines the architectural framework for achieving

design activities. Figure 12 shows the system architecture as an MAS organiza-
tion. The package structure is derived from the organization meta-model.
Once the organization has been modeled, the developer can proceed with
selecting an agent architecture, detailing the specification of the agent’s
behaviour and defining the agent society’s infrastructure.
Figure 12. Organization-based architecture
<<Organisation>>
TravelAssistanceAgency
pursues
is structured has worlkflowss
<<Organisation purposes>>
Organisation Purposes <<Workflow>>
ManagementW
<<Organisation Structure>> <<Workflow>> contains
UPATravelServicesOrganisation Workflow
is structured
contains
<<Workflow>>
<<Organisation Structure>> ProvidingTravelInfo&NotifW
UPATravelInfoNotificationOrganisation
contains uses
contains contains contains
Resources
contains contains
contains
<<Agent Definition>>
UPAFlightInfo&NotificationAssistantAg <<Agent Definition>>
UPAAirlineInfoDeskAg UPAAirportInfoDeskAg
UPATrialAccessAg <<Agent Definition>> <<Agent Definition>> <<Agent Definition>>
UPACustomerAccessAg UPAInformationFinderAg UPAInformationCommunicatorAg
TEAM LinG
Selecting an Agent Architecture
Selection criteria are dependent on the functionality to be achieved but also on

other non-functional criteria such as adaptability, robustness, performance,
security, and so forth. One solution experimented with in MESSAGE consists of
defining a family of design patterns in UML, which are instances of the meta-
models and incorporate computing models derived from previous engineering
experiences (Garijo, Tous, Matias, Corley, & Tesselaar, 1998; Walshe et al.,
2000). Design models for agents are component-based (OMG, 2002; Szyperski,
1997) and cover the more popular styles of agent architecture, such as reactive
and cognitive architecture. These elements belong to conventional software
engineering and their application towards the construction of an agent architec-
ture could be further discussed. However, this knowledge is very useful for
evaluating agent architectures that are available in the agent literature, such as
Garijo, Bravo, Gonzalez, and Bobadilla (2003), Wooldridge and Jennings (1995),
Huhns and Singh (1997), and Weiss (1999). These architectures can also be
evaluated with the insight of agent patterns, such as the mediator pattern or the
bidding pattern (Do, Kolp, Hoang, & Pirotte, 2003; Kolp, Do, Faulkner, &
Hoang, 2004).
Figure 13. Cognitive agent pattern
Cognitive
Cognitive Agent
Agent
Management
Decission
MangementIntfCognitive Agent KnowledgePProcessor
rocessor Rules
+ IinitIInterfaces()
D omain
UseControlInterfaceCognitiveAg
UseControlInterfaceCognitiveAg
( from Knowledge Processor ) Objectives
O bjetives
Perception +insertBelieve
insertBelieve
() ()
Perception
PerceptiontIntfCognitive Agent
A ction
T asks
T asks
+ iInsertMessage()
InternalPerceptionIntfCognitiveAg ent
IInternalPerceptionIntfCognitiveAgent
+insertDomainObject
insertDomainObject
() () () Messaging Adapter
Messaging
MessagingAdapter
Adapter
(from action )
TEAM LinG
Agent components provide an external view that is made up of their external

interfaces and a uniform internal structure (Figure 13). There are two types of
interfaces: (1) agent management interfaces providing methods to activate, stop,
delete, and monitor the agent; and (2) an agent communication interface to allow
agent interaction with different entities that can be either agents using agent
communication languages (ACL) or computing entities in the environment (for
example, Web servers, data bases, call managers, messaging servers, mail
servers, directory services, and so forth).
The agent’s internal structure is formed by the necessary subsystems to perform
the perception-assimilation-control-act cycle. These subsystems are defined as
internal components encapsulating an agent’s specific functionality and commu-
nicating through standard interfaces. A great variety of agent models can be
obtained, depending on the characteristics of their perception mechanism, their
control process or their actuation model.
The personal user agent (PUA) architecture is based on the Cognitive Agent
pattern (Figure 13) implementing a BDI cognitive processor. The rationale for
this choice is the need for reasoning and inference mechanisms to gather travel
requirements from the traveller and to provide advice and guidance in identifying
and arranging relevant travel. Once the architectural model is selected, the next
step is to define the knowledge needed to achieve the agent functionality.
Detailed Specification of Agent Behaviour
PUA behaviour specification consists of defining the corresponding knowledge

in each package of the agent architecture:
• Domain knowledge. It is obtained by refining the corresponding analysis

model classes.
• Objectives. PUA objectives are expressed with and/or trees of goals.
Each goal corresponds to either an analysis goal or a refinement of an
analysis goal.
• Tasks and actions. They represent methods or procedures to obtain the
information required to achieve the objectives. Actions are computing
primitives that allow the agent to get new beliefs by different mechanisms
such as inference processes, acting over the environment assimilating
incoming information, and communicating with other agents.
• Strategy and decision making. The decision model is declarative. Strategy
and tactic rules might be defined for controlling the generation of objectives,
choosing the most suitable tasks to achieve a particular objective, and
TEAM LinG
Figure 14. Agent goal decomposition into tasks

<<produce>>
CreateNewNo Notification
AllowUserDefineFlightNotificationG tificationT Created
<<satisfy>>
CreateVisualResourcesNotificationDefinitionG GatherNotificationDataAndValidateG
<<satisfy>>
<<satisfy>>
<<satisfy>>
CreateNotificationDefinition CreateNotificationD
WindowWithCorrectionT efinitionWindowT ValidateNotific
ationDataT
<<produce>> <<produce>>
NotificationWin NotificationVali NotificationVAlida

dowCreated dationFailed tionSucceeded
changing the focus of the resolution process by suspending the resolution

of an objective and selecting a new one.
• Specific diagrams showing the relationships among goal, tasks, actions, and
facts, which might solve the goals, are defined. These diagrams are easily
translated into rules in the implementation phase.
An example is shown in Figure 14. It is interpreted as follows: The goal

GatherNotificationDataG will be satisfied when valid notification data has been
obtained. To get this notification two subgoals might be solved:
CreateVisualResourcesNotificationDefinitionG and GatherNotificationData
AndValidateG.
Defining the Agent Society Infrastructure
This consists of describing the organization resources. Resources are computing

entities that are not agents but that are used by the agents to obtain information
for achieving their objectives. Agents can use resources based on resource
patterns, which offer standard interfaces as shown in Figure 15. This facilitates
the management, use, and deployment on the different processors.
TEAM LinG
Figure 15. Resource pattern
ResourceManagementInterface ResourceUse
ResourceUserInterface
+ Start()
+ Stop()
+ End()
+ Continue() Resource
+ Monitoring()
Experiences and Evaluation of

MESSAGE
The MESSAGE methodology was evaluated in two case studies. The case
studies were conducted in two phases: Analysis and Development, that is,
Design and Implementation. An assessment of the methodology based on this
experience was then performed. Two case study scenarios were selected for
Analysis:
• Universal Personal Assistant for Travel (UPA4T): a task-specific

instantiation of a generic personal assistant application; and
• Adaptive Customer Service OSS (ACSOSS): a decentralized OSS applica-
tion performing end-to-end coordination within a customer service business
process.
The UPA4T case study was carried through to design and to different partial
implementations.
MESSAGE’s agent-centred concepts proved to be a sufficiently complete set of
construction primitives for the case study problems. Using the views of the
system as building patterns helps developers obtain a complete specification of
the MAS. The case studies confirmed that the methodology supports the analysis
and design of multi-agent systems that are autonomous and can be deployed in
a dynamic and heterogeneous environment.
MESSAGE has been the basis for new proposals, such as INGENIAS (Pavón
& Gómez-Sanz, 2003), which refines the different MESSAGE meta-models and
adds more tool support, and RT-MESSAGE (Julian & Botti, 2004), which adds
extensions to deal with real-time constraints.
TEAM LinG
Further experience in Telefonica I+D applying MESSAGE to develop telephony-

based conversational services has led to the development of an agent-based
library and support tools for component creation, retrieval, management and
reuse. The BOGAR_LN library (Garijo, Bravo et al., 2003) provides application
developers with four categories of reusable component models: Agent Organi-
zation models, Agent models, Resource models, and Basic computing entities.
Evaluation experiments showed that using MESSAGE and the BOGAR_LN
library components allows substantial reduction in development time and effort
(65% less). Cost reduction is achieved without minimizing or bypassing activities
like design, documentation, and testing.
Strengths and Focus of the Methodology
The methodology supports the analysis and design of multi-agent systems that
are flexible and adapt to specific kind of changes described below in a
heterogeneous and dynamic environment. The case studies showed that MES-
SAGE supports architectures where:
• Agent instances of defined agent classes can come and go during the
lifetime of a multi-agent system. This is modelled in the interaction and
agent models by describing the roles that participate in an interaction and
the agents capable of playing those roles.
• Services come and go during the lifetime of an MAS. This is modelled by
describing which organizations/roles/agents provide a given service. How-
ever, the precise ways in which a published service can be changed during
the MAS’s lifetime depend on the specifics of each agent toolkit.
• Agents can change the way they provide a service. This is modelled by
separating the description of the service from the way it is implemented in
terms of tasks. The service could be provided in different ways using an
inference engine that optimizes certain criteria. If it has been designed to
do so, an agent could even cooperate with other agents to help them provide
the service that was previously provided alone during the lifetime of the
system.
• Agents communicate in an environment with information heterogeneity.
This is handled by a shared ontology for the MAS. This shared ontology is
derived from the domain model that was captured during analysis. Agents
then communicate using the common ontology to which the internal
heterogeneous information of the different agents can be mapped.
TEAM LinG
• Agents display goal-oriented behaviour and thus adapt their behaviour for
continuous optimization of design-time and run-time goals. This is possible
by modelling which tasks an agent is capable of performing and translating
them into rules for a rule-based engine or planner. There are no specific
means for modelling rules in MESSAGE other than the concept of task with
its pre- and post-conditions.
Most of these features are supported by the agent toolkits and were evaluated
in the case studies. The assumption is made that these toolkits provide the basic
agent infrastructure, such as matchmaking mechanisms for finding services,
ontology support, or communication primitives.
The methodology provided sufficient separation of concerns between multi-
agent considerations such as coordination and communication and the internal
agent design. The MESSAGE models and associated diagrams (Organization,
Goal, Agent/Role, Interaction, Workflow, and Domain) mostly support modelling
the multi-agent considerations. Modeling the internal structure and behaviour of
agents was mostly supported by agent pattern reuse, together with existing UML
diagrams such as statecharts, activity, and class diagrams.
Weaknesses and/or Purposeful Omissions
The MESSAGE design modelling language is less mature than the analysis
language, and the integration of the MESSAGE analysis and design processes
into RUP is not fully finalized. Furthermore, some of the more difficult issues
related to the dynamic behaviour of multi-agent systems were not explicitly
addressed.
The question of dynamic behaviour of multi-agent systems could be relevant for
many of the analysis and design modelling concepts (meta-classes and meta-
associations). Some of them were identified but not studied in detail. The implicit
assumption in the MESSAGE methodology is that all of the meta-model concepts
are static; that is, new classes (instances of MESSAGE meta-classes) and
associations (instances of MESSAGE meta-associations) cannot be added at
run-time, only instances of them. This does not mean that an agent system
designed with MESSAGE cannot display some degree of dynamic behaviour and
adapt to specific kind of changes in the environment as described above, for
example, by using rules to replan behaviour.
A methodology should provide explicit modelling support for the dynamic aspects
of multi-agent systems. Consider the following examples of dynamic behaviour
that are difficult to model with MESSAGE:
TEAM LinG
• An agent changes roles dynamically. In this case, an agent would be able

to stop playing a role and could also start playing new roles dynamically
during the lifetime of the multi-agent system.
• An agent interacting with another could be asked to play their roles (e.g.,
buyer and seller) in a more efficient manner by using a new interaction
protocol for the same interaction.
• As the multi-agent system evolves, the ontology might have to be extended
dynamically with new concepts. Agents would need to learn how to use the
new ontology concepts.
• New agent classes could be added during the lifetime of the MAS providing
new services that could be accessed using new interaction protocols.
Existing agents would need to learn how to use these new services.
Modeling these kinds of changes was considered in the methodology but not
addressed. One of the main reasons they were not addressed is that they were
difficult to assess experimentally in the case studies. Most of the agent toolkits
do not provide any explicit support for this kind of dynamic behaviour. Most of
the above mentioned changes would require design time changes, recompilation.
and redeployment of an agent-based application with most current agent-
oriented toolkits. For example, in the JADE toolkit, there is no support for
changing the interaction protocols, providing new agent classes, or modifying the
ontology during the execution of the system. These are design-time choices that
are compiled into the application and cannot be changed without modifying the
design, recompiling, and redeploying.
Another issue that was not sufficiently studied was the availability of an analysis
and design pattern library associated with the methodology. This aspect has been
partially covered in Garijo, Bravo et al. (2003), although the number and the type
of patterns should be extended. For example, specific coordination and negotia-
tions patterns between agents could be used to allow for continuous optimization.
Although agent-centred concepts and notations have proved to be suitable for
analysis and design, developers also need guidelines and support for other stages
of the life cycle such as requirements, implementation, testing, and deployment.
Conclusions
Analysis focuses on describing the organizations involved in the multi-agent
system, agent goals, and the roles defined to satisfy them. The high-level goals
TEAM LinG
were decomposed and satisfied in terms of services provided by roles. The

interactions between roles that are needed to satisfy the goals were also
described.
Agents were identified during design based on the description of the organiza-
tions and were assigned all the organization’s roles in the multi-agent application.
Services could then be implemented in terms of tasks that were decomposed into
direct actions on the agent’s internal representation of the environment, plus
communicative actions to send and receive messages in inter-action protocols.
The interactions between roles identified in analysis were detailed in terms of
interaction protocols. The design description is an implementation-independent
conceptual description of the system.
Organization-driven detailed design helps developers to define the computational
behaviour of the overall system by stepwise refinement. The refinement process
is agent centred. The organization model facilitates component-based develop-
ment and reusability. It also helps to maintain consistency among analysis
entities, design entities, and system requirements.
Viewing agents as reusable software components provides several advantages:
(1) applications are developed by selecting and assembling the appropriate
components; (2) integration and inter-operability among agents, standard com-
ponent-ware technology, and supporting tools is assured; and (3) developers
unfamiliar with agent concepts and notations may choose agent-based compo-
nents to fulfill specific functionality of their applications. This permits agent
technology to be easily assimilated into current engineering practice.
MESSAGE, as it stands, is not a complete, mature agent-oriented methodology.
It does, however, make some significant practical contributions to the state of the
art (Caire, Coulier et al., 2001, 2002) that are likely to influence ongoing initiatives
in this area, for example, Agent UML (Odell, Parunak, & Bauer, 2000) or the
FIPA modelling and methodology standardization activities. In particular, the
graphical notation/diagram set, which extends UML class and activity diagrams,
is a practical and concrete result that could be taken up widely.
Acknowledgments
This work was supported by EURESCOM (http://www.eurescom.de) Project
P907. The editing of parts of this chapter was supported by the Spanish Ministry
for Science and Technology (TIC2002-04516-C03-03) and FEDER, and the
Walloon region under contract Convention EP1A12030000012 N DGTRE
130023.
TEAM LinG
References
Barbier, F., Henderson-Sellers, B., Le Parc-Lacayrelle, A., & Bruel, J.-M.
(2003). Formalization of the whole-part relationship in the Unified Modeling
Language. IEEE Trans. Software Eng., 29(5), 459-470.
Bauer, B., Müller, J. P., & Odell, J. (2001). Agent UML: A formalism for
specifying multiagent interaction. International Journal of Software
Engineering and Knowledge Engineering (IJSEKE), 11(3), 207-230.
Bellifemine, F., Poggi, A., & Rimassa, G. (2001). JADE: A FIPA2000 compliant
agent development environment. In Proceedings of the Fifth Interna-
tional Conference on Autonomous Agents (Agents 2001), Montreal,
Canada (pp. 216-217). ACM Press.
Caire, G., Coulier, W., Garijo, F., Gomez-Sanz, J., Pavon, J., Leal, F., Chainho,
P., Kearney , P. E., Stark, J., Evans, R., & Massonet, P. (2001). Agent-
oriented analysis using MESSAGE/UML. LNCS 2222, Berlin: Springer-
Verlag.
Caire, G., Coulier, W., Garijo, F., Gomez-Sanz, J., Pavon, J., Leal, F., Chainho,
P., Kearney , P. E., Stark, J., Evans, R., & Massonet, P. (2002). EURESCOM
P907: MESSAGE - Methodology for Engineering Systems of Software
Agents, http://www.eurescom.de/public/projects/P900-series/p907/
default.asp
Cook, S. (2005). UML2.0 – Trying to have it both ways in UML – the Good, the
Bad or the Ugly? – Perspectives from a panel of experts. Software and
Systems Modelling, 4(1), 4.
Dardenne, A., Lamsweerde, A. v., & Fickas, S. (1993). Goal-directed require-
ments acquisition. Science of Computer Programming, 20, 3-50.
Demazeau, Y. (2001). La méthode VOYELLES, dans Systèmes Multi-Agents:
Des Théories Organisationnelles aux Applications Industrielles. Oslo,
Norway: Hermès.
Do, T. T., Kolp, M., Hoang, T. T. H., & Pirotte, A. (2003). A Framework for
Design Patterns for Tropos. Paper presented at the Proceedings of the
17th Brazilian Symposium on Software Engineering (SBES 2003),
Maunas, Brazil, October.
EURESCOM P907. (2003). Methodology for agent-oriented software engineer-
ing (final) 9/20/2001. Retrieved March 29, 2005, from http://
www.eurescom.de/~public-webspace/P900-series/P907/index.htm
Friedman-Hill, E. (2002). Java Expert System Shell (JESS). Retrieved March
29, 2005, from http://herzberg.ca.sandia.gov/jess/
TEAM LinG
Garijo, F., Bravo, S., Gonzalez, J., & Bobadilla, E. (2003). BOGAR_LN: An
agent-based component framework for developing multi-modal services
using natural language. Paper presented at the CAEPIA, LNAI, (Vol. 3040,
pp. 207-220). Berlin: Springer-Verlag,
Garijo, F. Gómez-Sanz, J. J., Pavón, J., & Massonet, P. (2001). Multi-agent
system organization. An engineering perspective. Paper presented at the
Modelling Autonomous Agents in a Multi-Agent World, Annecy, France,
May.
Garijo, F., Tous, J., Matias, J. M., Corley, S., & Tesselaar, M. (1998). Develop-
ment of a multi-agent system for cooperative work with network negotia-
tion capabilities. In S. Albayrak (Ed.), Intelligent agents for telecommu-
nication applications, LNCS, (Vol. 1437, pp. 204-219). Berlin: Springer-
Verlag.
Giorgini, P., Kolp, M., Mylopoulos, J., & Pistore, M. (2004). The Tropos
methodology: An overview. In F. Bergenti, M. P. Gleizes, & F. Zambonelli
(Eds.), Methodologies and software engineering for agent systems.
Boston: Kluwer Academic Publishing.
Huhns, M. & Singh, M. (1997). Agents and multiagent systems: Themes,
approaches, and challenges. In M. Huhns & M. Singh (Eds.), Reading in
agents (pp. 1-23). San Francisco: Morgan Kaufmann Publishers.
Iglesias, C., Mercedes Garijo, M., Gonzalez, J. C., & Velasco, J. R. (1998).
Analysis and design of multiagent systems using MAS-CommonKADS. In
M. P. Singh, A. Rao, & M. J. Wooldridge (Eds.), Intelligent Agents IV
(LNAI Volume 1365 ed., pp. 313-327). Berlin: Springer-Verlag.
Julian, V. & Botti, V. (2004). Developing real-time multi-agent systems.
Integrated Computer Aided Engineering Journal, 11(2), 135-149.
Kendall, E. A. (2000). Software engineering with role modelling. In Proceed-
ings of the Agent-Oriented Software Engineering, LNCS, Vol.1957 (pp.
163-169). Berlin: Springer-Verlag.
Kolp, M., Do, T. T., Faulkner, S., & Hoang, H. T. T. (2005). Introspecting agent
oriented design patterns. In Handbook of Software Engineering and
Knowledge Engineering (Vol. III). World Publishing. Forthcoming 2005.
Kruchten, P. (1999). The rational unified process. Reading, MA: Addison-
Wesley.
Lind, J. (2001). Iterative software engineering for multiagent systems: The
MASSIVE method. Berlin; New York: Springer-Verlag.
Massonet, P., Deville, Y., & Neve, C. (2002). From (AOSE) methodology to
agent implementation. In Proceedings of the First International Joint
Conference on Autonomous Agents and Multiagent Systems (pp. 27-
34). New York: ACM Press.
TEAM LinG
Milgrom, E., Chainho, P., Deville, Y., Evans, R., Kearney, P., & Massonet, P.
(2001). Methodology for agent oriented software engineering, Final
Guidelines for the identification of relevant problem areas where
agent technology is appropriate. EURESCOM Project P907. Retrieved
March 29, 2005, from http://www.eurescom.de/~public-webspace/P900-
series/P907/D2FinalReviewed.zip
Odell, J., Parunak, H. V. D., & Bauer, B. (2000). Extending UML for agents.
Paper presented at the Agent-Oriented Information Systems Workshop
at the 17th National Conference on Artificial Intelligence,
Odell, J., Parunak, V., & Bauer, B. (2001). Representing agent interaction
protocols in UML. In P. Ciancarini & M. J. Wooldridge (Eds.), Agent-
oriented software engineering. Proceedings of the First International
Workshop (AOSE 2000). LNAI, (Vol. 1957, pp. 121-140). Berlin: Springer-
Verlag.
OMG. (2000). MOF. Meta Object Facility (specification) (No. V.1.4. for-
mal). Retrieved March 29, 2005, from http://www.omg.org/technology/
documents/formal/mof.htm
OMG. (2002). CORBA Component Model v3.0. Retrieved March 29, 2005,
from http://www.omg.org/library/schedule/CORBA_ Component_
Model_RFP.htm
Omicini, A. (2000). SODA, societies and infrastructures in the analysis and
design of agent-based systems. In Agent-Oriented Software Engineer-
ing, LNCS, Vol. 1957 (pp. 185-193). Berlin: Springer-Verlag.
Pavón, J. & Gómez-Sanz, J. (2003). Agent-oriented software engineering with
INGENIAS. Proceedings of the International Central and Eastern
European Conference on Multi-Agent Systems (CEEMA ’03), Prague,
Czech Republic (LNCS, Vol. 2691, pp. 394-304). Springer-Verlag.
Szyperski, C. (1997). Beyond object-oriented programming. Reading, MA:
Addison-Wesley.
Walshe, D., Kennedy, J., Corley, S., Koudouridis, G., F. Van Laenen, Ouzounis,
V., et al. (2000). An interoperable architecture for agent-oriented workflow
management. Proceedings of the International Conference on Artifi-
cial Intelligence (IC-AI 2000), Monte Carlo Resort, Las Vegas. CSREA-
Press.
Weiss, G. (1999). Multiagent systems. A modern approach to distributed
artificial intelligence. Cambridge, MA: The MIT Press.
Wooldridge, M. J., & Jennings, N. R. (1995). Agent theories, architectures,
and languages: A survey. New York: Springer-Verlag,
TEAM LinG
236 Pavón, Gómez-Sanz & Fuentes
Chapter IX
The INGENIAS
Methodology and Tools
Juan Pavón
Jorge J. Gómez-Sanz
Rubén Fuentes
Abstract
INGENIAS provides a notation for modeling multi-agent systems (MAS) and

a well-defined collection of activities to guide the development process of
an MAS in the tasks of analysis, design, verification, and code generation,
supported by an integrated set of tools—the INGENIAS Development Kit
(IDK). These tools, as well as the INGENIAS notation, are based on five
meta-models that define the different views and concepts from which a
multi-agent system can be described. Using meta-models has the advantage
of flexibility for evolving the methodology and adopting changes to the
notation. In fact, one of the purposes in the conception of this methodology
is to integrate progressive advances in agent technology, towards a
standard for agent-based systems modeling that could facilitate the adoption
of the agent approach by the software industry. The chapter presents a
summary of the INGENIAS notation, development process, and support
tools. The use of INGENIAS is demonstrated in an e-business case study.
This case study includes concerns about the development process, modeling
with agent concepts, and implementation with automated code generation
facilities.
TEAM LinG
Wooldridge, M., Jennings, N. R., & Kinny, D. (2000). The Gaia methodology for
ceedings of the Agent-Oriented Software Engineering, LNCS, Vol.
1957 (pp. 235-251). Berlin: Springer-Verlag.
Endnote
1
Ed. This is a known weakness of UML. See, for example, Barbier,
Henderson-Sellers, Le Parc-Lacayrelle, and Bruel (2003) and Cook (2005).
TEAM LinG
The INGENIAS Methodology and Tools 239
2000). The difference with this proposal compared to existing ones is how these
viewpoints are defined and built, and how they are integrated into the MAS
development process.
INGENIAS viewpoints can be complemented with extensions of known nota-
tions, such as UML use case diagrams or UML collaboration diagrams. The
extension consists of introducing new non-UML elements and associating them
with UML entities. In the case study, readers can find use case diagrams used
to depict roles (Figure 12), while interaction entities (Figure 18) appear linked
to use cases.
Viewpoint Definition
Each viewpoint is described using a meta-modeling language, in our case

GOPRR (Lyytinen & Rossi, 1996). GOPRR stands for Graph, Object, Property,
Role, and Relationship, which are the primitives for describing the meta-models.
We could have used MOF (OMG, 2000), but it turned out to be too complex for
our needs. With this meta-modeling language, we specify how to generate a
particular view of the system. The result of applying a meta-modeling language
is a meta-model. Meta-models are also instantiated to form the concrete
problem-domain views (readers can check OMG [2000] to have a more accurate
perspective on what is meta-modeling).
In INGENIAS, for each generic entity in the meta-model (e.g., meta-classes),
the engineer looks for specific types of entities (e.g., classes) in the current
problem domain that share the features specified in the meta-model (relation-
ships with other entities and related attributes). The final result is a view of the
system under development that is compliant with the meta-model. This section
presents a simplified version of these meta-models by showing the entities with
their graphical representation and their relationships informally, in order to make
figures easier to understand. Readers interested in the meta-model specification
can download it from the INGENIAS site at http://ingenias.sourceforge.net.
The meta-models that we defined are the result of experience gained in several
projects, each one validated with the development of an agent-based application:
MESSAGE (Caire et al., 2001) defined the general framework for MAS
specification and the initial identification of five viewpoints; Communications
Management Process Integration Using Software Agents (Gomez-Sanz,
Garijo, & Pavón, 2000) tested the application of BDI architecture for agent
behaviour; and Personalized Services for Integrated Internet Information
(Gómez-Sanz, Pavón, & Díaz-Carrasco, 2003) made insights in the organization
and scalability issues of MAS. Also, we have extensively used the viewpoints
specification to build tools that support the development activities—more
TEAM LinG
Introduction
As can be seen in this book, there are several methodologies proposed to support
a systematic way of developing an MAS. Each one of them starts by assuming
its own model of agents and proposing a convenient method of realizing the MAS.
This diversity, in principle, benefits agent research by providing different points
of view and, therefore, promoting experimentation with agent concepts. On the
other hand, this diversity may be a constraint to facilitate the adoption of agent
technology by the software industry and to integrate advances in the field.
New methodologies try to deal with this multiplicity of solutions by meta-
modeling techniques applied to the development process and to the specification
method. The goal is to finish with a set of agreed-upon concepts and MAS-
building methods as a common framework to focus agent research. However,
achieving this goal will take time and experimentation. Therefore, today, we are
working with notations in contact evolution, support tools to cope with these
changes, and development methods that have to be applied and verified in a short
time.
INGENIAS assumes the need of evolving in order to adopt or change concepts
as agent technology progresses and to incorporate this ongoing research into a
stable body of knowledge. This approach is based on:
• Open source CASE tools. These tools are available freely to the commu-
nity, so that the development method can be validated and replicated, which
is the nature of software engineering.
• A notation that can be extended and refined. Meta-modeling primitives
allow us to generalize or specialize concepts, aggregate new ones, or refine
existing ones. There has been a significant effort to integrate results of
agent research into a coherent recipe of how to define an MAS. Conse-
quently, this is not just a personal view of MAS-building but an integrative
approach.
• There is a detailed and experimented development process. A develop-
ment process is usually misunderstood in this area as a guideline. In
INGENIAS, a developer will find concrete activities to be executed, an
account of the results to be obtained, support tools to produce these results,
and a lifecycle to organize all of them.
• Implementation concerns. The methodology dedicates an important effort
to consider how to translate specifications into code automatically.
INGENIAS proposes to include the development of a customized code
generation procedure as one of the development tasks.
TEAM LinG
The presentation of INGENIAS here follows the basic structure of other

chapters in this book. We first present the principles of the methodology, with
focus on the INGENIAS constructs for modeling an MAS. There is also a brief
description of the INGENIAS Development Kit (IDK) tools. The third section
illustrates the use of INGENIAS in terms of a software process that follows the
Unified Software Development Process model (Jacobson, Booch, & Rumbaugh,
1999) for the development of a case study of a bookshop expanding its business
to the Web. Finally, we evaluate the methodology, taking into account our
experience in the development of different MAS applications.
The Methodology
This part explains how to generate a specification of the MAS and its implemen-
tation. We built the specification of the MAS considering several viewpoints.
The concepts for describing each viewpoint are detailed in the next section.
Reading that section is important because it clarifies the graphical notation that
will be used throughout the case study. The instantiation of these viewpoints with
concrete problem entities is addressed with a development process, which is
explained in the section on the INGENIAS process. Implementation of the
resulting specification is detailed in the same section and demonstrated later on
in the case study.
Modeling MAS with INGENIAS
The object-oriented software developer has to deal with classes, interfaces,

objects, inheritance, and the like; the agent-oriented software developer can use
those concepts and others such as agent, organization, goal, task, mental state,
resource, and so forth. In INGENIAS, we want to promote the use of these
concepts from analysis to implementation. So as to manage the complexity of the
MAS specification, we propose organizing these concepts in five viewpoints:
organization, agent, goals/tasks, interactions, and environment. These view-
points basically correspond to those already defined in MESSAGE concepts and
views, as our previous work was in that project. In INGENIAS, we have refined
MESSAGE concepts and views, established relationships among them, and
identified activities in the development process to generate MAS specifications.
The use of views to specify a system has been used also in the works of Vowel
engineering (Demazeau, 2001), MAS-CommonKADS (Iglesias, Mercedes
Garijo, Gonzalez, & Velasco, 1998), and Gaia (Wooldridge, Jennings, & Kinny,
TEAM LinG
specifically, graphical model editors, documentation generation, and code gen-

eration for different target platforms and validation tools.
Organization Viewpoint
The organization describes the framework where agents, resources, tasks, and
goals coexist. It is defined by its structure, functionality, and social relationships.
From a structural viewpoint, the organization is a set of entities with relationships
of aggregation and inheritance. The organization structure defines a decompo-
sition of the MAS in groups and workflows (see Figure 1).
Groups may contain agents, roles, resources, or applications. Groups are useful
when the number of elements in an MAS increases. Assignment of such
elements to a group obeys some organizational purpose, because the grouping
facilitates the definition of workflows or because its members have some
common characteristics.
The functionality of the organization is defined by its purpose and tasks. An
organization has one or more goals and depends upon its agents to perform the
necessary tasks to achieve them. How these tasks are related and who is
responsible of their execution are defined in workflows.
Figure 1. Elements of the organization viewpoint (Structural description of

a MAS organization)
Organization
pursues
Goal
decomposes Group
workflow
Application
decomposes
plays
Agent Role Resource
TEAM LinG
Figure 2. Elements of the organization viewpoint (Workflow definition)
workflow
connect
task task
responsible
uses Consumes/produces
Application Resource
Agent Role Interaction
Workflows define associations among tasks and general information about their
execution (Figure 2). For instance, for each task, a workflow defines its results,
the agent or role responsible for its execution, and the resources that are
required. This is useful to gain knowledge on the relationships between agents
through tasks, and the assignment and availability of resources in an organization.
Social relationships can be established at different levels—between organiza-
tions, groups, agents, or roles. There are service relationships (for instance,
client-server relationship), conditional or unconditional subordination, and so on.
Social rules state restrictions on the interactions between entities in the organi-
zation.
Agent Viewpoint
An agent here is a program that follows the rationality principle (Newell, 1982)
and that processes knowledge. The rationality principle says that an agent will
execute those actions that make it achieve its goals.
The agent viewpoint (Figure 3) is concerned with the functionality of each agent:
purpose (what goals an agent is committed to pursue), responsibilities (what
tasks it has to execute), and capabilities (what roles it plays). The behaviour of
the agent is defined through three components:
TEAM LinG
Figure 3. Elements of the agent viewpoint
pursues plays
Goal Agent Role
has
responsible
Mental
has M
Concrete State
Agent task
P
modifies
Fact
Belief Event
• Mental state: an aggregation of mental entities such as goals, believes,

facts, and compromises. Each agent has an initial mental state represented
by an association of the agent to a mental state entity. There can be only
one such association. To express mental states over the lifetime of an agent,
we use another concept, the concrete agent, associated with mental state
entities (e.g., Figure 24).
• Mental state manager: which provides for operations to create, destroy,
and modify mental entities.
• Mental state processor: which determines how the mental state evolves,
described in terms of rules, planning, and so forth.
The mental state can be seen as all the information that allows the agent to make
decisions. This information is managed and processed in order to produce agent
decisions and actions made by the mental state manager (M) and processor (P).
The mental state processor makes the decision of which task to execute, while
the mental state manager provides the operations to create, destroy, and modify
the elements of the mental state and their relationships.
Tasks/Goals Viewpoint
The tasks/goals viewpoint (Figure 4) considers the decomposition of goals and

tasks, and describes the consequences of performing a task and why it should be
TEAM LinG
Figure 4. Elements of the tasks/goals viewpoint
Preconditions
Postconditions
Fact A
consumes
F
Task Fact C
produces
Fact B consumes F
F
uses uses produces
Modifies/affects
Resource goal
Application Application
<<Environment>> <<Internal>> Interaction
- method - method
Depends/decomposes into
performed (i.e., it justifies the execution of tasks as a way to satisfy goals). For
each task, it determines what elements are required and what outputs are
expected. To identify which goals are influenced by a task execution, there are
satisfaction and failure relationships. Finally, the tasks/goals viewpoint explains
how a solved goal affects other existing goals by using decomposition and
dependency relationships. It is useful to know that in solving a subgoal, a
supergoal can be solved too.
Diagrams from this view can be used to explain how the mental state processor
and manager work. In INGENIAS, how a task affects the mental state of an
agent can be represented within a goal/task view. Therefore, a developer can
define special tasks expressing what to do when new elements appear in the
mental state (tasks defining mental state management functionality) or tasks that
produce special entities representing the next task to execute (tasks for mental
state processor functionality description).
Interaction Viewpoint
The interaction viewpoint addresses the exchange of information or requests

between agents, or between agents and human users. The definition of an
interaction requires the identification of:
TEAM LinG
any assistance is possible when the size of the development is small. When it is
bigger, satisfying dependencies may consume most of the development effort.
To alleviate those dependencies, we propose to generate the specification in a
stepwise refinement following a conventional software engineering development
process. This process has been customized to produce the elements that our
MAS specification needs.
Initially, INGENIAS considers the Unified Software Development Process
(USDP) (Jacobson, Booch, & Rumbaugh, 1999) as its software development
process and defines a set of interrelated activities (around one hundred) that can
lead the developer to the final MAS specification. These activities are organized
in UML activity diagrams showing the dependencies between them. Instead of
presenting all of these activities here, this section focuses on the expected results
throughout the development. Readers interested in the details can consult the
original work in (Gomez-Sanz, 2002), available only in Spanish, or consult the
Web site http://ingenias.sourceforge.net
Figure 8 summarizes the results obtained in each phase of the USDP for analysis
and design activities, applied to INGENIAS MAS specification. Details about
how to apply analysis and design activities will be provided in this section.
Throughout the chapter, references to specific parts of the development process
will follow the pattern workflow-phase (for instance, design-elaboration).
Figure 8. Results of analysis and design phases of the development process
PHASES
Inception Elaboration Construction
Generate use cases and identify their Refined use cases and interactions Refinements on existing
actors associated to them models to cover use cases
A Sketch a system architecture with an Agent models that detail elements of
N
organization model. the system architecture.
A Generate enviroment models to Workflows and tasks in organization
L
represent results from requirement models
Y Models of tasks and goals to highlight
gathering stage
S
control constraints (main goals, goal
I
WORKFLOWS
decomposition)
S
Refinements of environment model to
include new environment elements
Generate prototypes perhaps with
D rapid application development tool Refinements in workflows Generate new models
E such as ZEUS or Agent Tool or code Interaction models that show how
Social relationships that
S generators from the IDK. Sometimes tasks are executed.
regulate organizational behavior
I this prototyping limits to concrete Models of tasks and goals that
G aspects and uses a more reflect dependencies and needs
N conventional technology identified in workflows and how system
goals are achieved
Agent models to show required
mental state patterns
TEAM LinG
• Actors in the interaction: who plays the role of initiator and who are the
collaborators. There should be at least one collaborator and only one
initiator.
• Interaction specification: a specification should detail how the interaction
is constructed at runtime. This refers to the protocol followed along the
interaction, but it also may include the mental attitudes that agents should
observe and actions triggered on delivering or receiving a message.
• Context of the interaction: the goals the interaction pursued and the
mental states its participants go through when the interaction starts, during
its execution, and at the end. Goals of the interaction and its participants do
not need to be the same, but they should have something in common (e.g.,
the goals pursued by agents are subgoals of the interaction goal). Common-
alities may be represented by means of a goal/task diagram (see Figure 4).
• Nature of the interaction: the nature of the interaction refers to the
attitude of interaction participants: do they negotiate, cooperate, perform
distributed planning, and so forth. This nature is detailed in the hierarchy
defined by Huhns and Stephens (2000). Knowing the nature in advance
may help in locating a proper protocol or in identifying control constraints.
Figure 5 shows the elements participating in the interaction viewpoint. For each
interaction, there is an associated interaction specification that can be special-
ized as the developer needs. INGENIAS does not use a single formalism for
interaction specification. It admits different notations for specifying interactions,
Figure 5. Elements of the interaction viewpoint
Goal
Pursues
Pursues Is detailed with
SPECIFICATION
Pursues Interaction
Intiated by Collaborates in
Pursues
GRASIA UML AUML
Spec Collaboration Protocol
diagram diagram
Agent Role
TEAM LinG
Figure 6. Elements of a GRASIA interaction specification
Task
Task
Interaction unit
Initiates Colaborates
Speech act
Iterates
Agent Interaction unit Agent
Colaborates Initiates
Interaction unit
Role Speech act Role

Precedes
Interaction unit Interaction unit Interaction unit
Precedes Precedes
Speech act Speech act
such as Agent UML (http://www.auml.org) protocol diagrams, UML collabo-

ration diagrams, or our own GRASIA diagrams (detailed in Figure 6). Different
specifications are linked with the interaction.
There are some aspects of the interaction that are not explained properly by
UML or AUML, especially the intentional stance of each agent. For this purpose,
we developed our own version of UML collaboration diagrams and named them
GRASIA interaction diagrams (see Figure 6). These diagrams explain the
interaction in terms of a set of interaction units. An interaction unit may be a
message passing action, a shared-space tuple reading or writing, a remote
procedure call, or just a reference to another interaction.
By making these interaction units explicit, we can detail how they are ordered
(a unit precedes another or there is an iteration of several of them, for instance),
who starts the communication act (initiates), and who is supposed to attend this
message (collaborates). This distinction also allows the discussion of what
mental states are required in order to decide to send a message or to accept an
incoming one. These mental states can be expressed in many ways, but we tend
to use more frequently agent diagrams (Figure 3) to represent one. Figure 6 also
denotes that when receiving and/or sending a message, the agent can perform
a task.
TEAM LinG
Environment Viewpoint
Finally, the environment viewpoint (Figure 7) defines the entities with which the
MAS interacts, which can be:
• Resources: the elements required by tasks that do not provide a concrete

API. Examples of resources are the CPU, File descriptors, or memory.
Resources are assigned to agents or groups in the current system.
• Other agents (from other existing organizations) that satisfy the rationality
principle (Newell, 1982). The agents in the MAS interact with these agents
to satisfy system goals.
• Applications: normally, they offer some (local or remote) API. Their main
use is to express the perception and action of the agents; applications
produce events that can be observed. Agents define their perception
indicating to which events they listen. In addition, agents act on the
environment by invoking the methods or procedures that applications
define. An application can be labelled as environment (the application
wraps an existing software in the target system) or as internal (the
application wraps software developed for the current system).
Figure 7. Elements of the environment viewpoint
Group
Application
Is assigned Is assigned
Application Application
<<Environment>> <<Internal>> Resource Perceives
- method - method environment
through
Is assigned Is assigned
Agent
Role Agent
TEAM LinG
Figure 7 shows that an agent defines its perception through applications.

Perception can be conceived as the notification of events occurring in the
application or as the polling of the application state through its methods in order
to look for concrete changes. More complex systems may need other types of
perception, but so far we found that our case studies use only these two.
Applications and resources may be handled by groups, roles, or agents. When a
resource or an application is assigned to an agent, group, or role, these are
responsible by controlling its use and access. In the case of the group, the access
is granted for any agent or role belonging to the same group. Externals may
require interacting with some group role or agent in other to gain access.
Dependencies Among Viewpoints
Developers should be aware that there are elements that may appear in different
views in a specification. This repetition of entities across different views induces
dependencies among views. This feature is a consequence of the definition of
system views and may be a source of inconsistency in a specification. For
instance, the same task entity can appear in an agent view, a task/goal view, an
organization view, and an interaction view. Therefore, to completely define a
task, creating different diagrams for different views is required. If the developer
fails to create all of these diagrams, the system specification may be incomplete.
On the other hand, if the developer creates all required diagrams, and a task is
assigned to one role in an organization view and another, different role in an agent
view, it could be interpreted that the specification is not consistent.
In order to deal with those dependencies, the original work of INGENIAS
(Gomez-Sanz, 2002) suggested that some tests to be manually applied for each
view. These tests were formulated as rules, showing for each element which
other views may be used to complement its definition. These tests were
incorporated inside of INGENIAS development process in the form of validation
activities and can be consulted at http://grasia.fdi.ucm.es/ingenias.
The INGENIAS Process
The INGENIAS Process helps developers to produce an MAS specification and

its implementation. In a simple development, generating a specification would be
a matter of identifying valid domain-problem entities, taking into account the
elements that each view needs and that have been described in the previous
section. This approach would be limited by the inherent dependencies among
different views. Adding a new piece of information would imply creating
diagrams for the different views or modifying existing ones. Doing this without
TEAM LinG
Despite having a well-defined collection of products, in a real system, there are

a considerable number of diagrams to describe an MAS. Figure 8 serves as a
guide to establish what elements to produce first and which later. The products
themselves are generated through a set of activities organized into activity
diagrams, one for each viewpoint in the analysis and design. These diagrams
turned out to be a useful tool to deal with the iterative features of the USDP. At
the beginning of an iteration, a developer would start from the initial state of the
activity diagram, executing the activities in order, and producing elements until
the final state. The level of detail would be indicated by the current stage
according to the results referred to in Figure 8.
Readers may have noticed that Figure 8 deals mainly with modeling. Implemen-
tation in INGENIAS is considered a translation of a specification to operational
code, that is, an automated code generation process. This code generation
process is not a piece of software that the INGENIAS Development Kit (IDK)
includes by default. INGENIAS intends to enable a customizable code genera-
tion process (detailed in following sections).
Development Process Activities
Each viewpoint in INGENIAS is constructed following two sets of activities

structured into activity diagrams. One set aims at elaborating the view at the
analysis level, whereas the other focuses on the design. In total, a developer has
ten activity diagrams that propose around one hundred activities to follow. These
activities have been numbered to help developers in applying them. Their
enumeration is unique within a viewpoint. This means that there are five activities
numbered as activity number 1, one for each viewpoint.
In general, identified activities are coarse grained and later exploded into more
fine- grained activities. Figure 9 shows those that will lead to an analysis
viewpoint of agents. Starting from the initial state, the developer consults the
information of each activity to know which elements should be produced and
how. For instance, activity 2 aims at identifying the agent functionality according
to the tasks it can execute, the roles it plays, and the goals it pursues.
At the end of the workflow, the resulting model will have to be validated, since
many of the elements of this viewpoint may also appear in other viewpoints as
well. So, a goal in this viewpoint may trigger further research with associated
tasks in a task/goal viewpoint.
Figure 10 shows fine-grained activities for the activity number 2, where the
developer has to decide whether discovering tasks or goals first is most useful.
If tasks are identified first, then goals could be the states achieved by these tasks
and each task would have a single goal associated. Later, there should be
TEAM LinG
study, and assume that the rest is feasible. Naturally, in a more realistic case,
more aspects should be tested and some comparatives should be made in order
to make a decision. According to the USDP, this kind of task is needed in the
inception stage, which is dedicated to the verification of the feasibility of the
development.
Implementation
Only a few agent-oriented methodologies discuss implementation issues. This is

almost limited to those that have tool support (e.g., MaSE [DeLoach, 2001], Zeus
[Nwana, Ndumu, Lee, & Collis, 1999], ADELFE [Picard & Gleizes, 2004]).
INGENIAS bases its implementation proposal on facilities from the IDK that
map specification elements into computational entities. In the agent domain,
relevant computational entities could be agent architectures, MAS architectures,
or agent platforms. This mapping is performed in the IDK by modules.
A module in INGENIAS is responsible for generating code from the specifica-
tion. This specification can be taken directly from the specification editor (see
the support tool section) or from an XML file. A module takes as input a set of
templates of code and fills them in with information extracted from an INGENIAS
specification. A module, then, is built of:
• A set of templates. Usually, they are templates of code that are made
concrete with data from the specification. These templates are XML
documents so they can be applied to different programming languages. The
DTD of these documents aims at highlighting the pieces of code that will
be replaced with information from the diagrams. Basic tags in the DTD are:
repeat, which means that a portion of code has to be duplicated and
instantiated with different data, and v, which means that it has to be
replaced with a concrete piece of information.
• A graph traversal algorithm. The MAS specification is viewed as a set
of graphs that can be traversed using a customized API. This API considers
graphs as containers of entities that are interconnected through n-ary
relationships.
• A data structure to be filled. During graph traversal, the developer has to
extract meaningful information from the specification and put it into a
special data structure required by the code generation framework. This
data structure is based on the DTD that defined the template, so that the
replacement is easier to program.
TEAM LinG
Figure 10. Details of the activities involved in determining functionality

that will help the agent to achieve its goals
2. Associate tasks or roles to the agent to enable goal achievement
2.b Identify main

functionality
2.a Identify the goals of
each agent
2.c Associate goals with

functionality
[NO]
[ NO ]
Is there a way of
satisfying each goal?
[YES]
[ YES ]
Analysis and Design
During analysis-inception (analysis workflow and inception phase), the focus is

on defining an organization model that sketches the structure of the MAS and
identifies its main components. This result, equivalent to an initial MAS architec-
ture, is later refined in the analysis-elaboration phase to identify the goals of the
organization and relevant tasks with respect to these goals, to be performed by
each agent in the organization. Task execution has to be justified in terms of
organizational goals or an agent’s goals (with task-goal models). This leads to
identifying the results needed to consider a goal as being satisfied or not. In the
design-elaboration phase, more detail is added by defining workflows between
the different agents (with organization models), completing workflow definition
with agent interactions (with interaction models), and refining the agent’s mental
state as a consequence (with agent models). According to the USDP, the goal
of the elaboration phase is to generate a stable architecture. This architecture
arises from the study, during the elaboration phase, of a subset of initial use
cases. Remaining use cases, which are supposed to deal with special situations
but do not provide changes in the system architecture, are left to the construction
phase.
Design-Inception has no activity-based assistance. According to Figure 8, it
deals with technology issues related to the feasibility of the development. It is
hard to establish what to test or what to prototype. In our experience, it is better
to focus on concrete aspects, communications, and user interaction in our case
TEAM LinG
algorithms that work with meta-models. Finally, analysts generate specifications

and use the modules to test their correctness using the prototype as a model.
Validation and Verification
Currently, INGENIAS supports validation using modules with further work

under way on verification and validation using Activity Theory (AT) (Fuentes,
Gómez, & Pavón, 2003); only verification is included in the standard IDK
distribution.
In general, any module can provide verification capabilities if a developer follows
the basic instructions for module construction. Modules have to traverse a
specification looking for elements indicated in the templates used. If these
elements do not appear, or appear differently from the way the template requires,
then the module should stop and produce error messages. These error messages
should indicate what error triggered it and suggest some solution, such as adding
specific information, defining responsibilities for agents, or removing some
elements, like duplicated tasks. The experience, when following guidelines for
module construction, is that modules support the developer in completing the
specification.
Validation and Verification results with Activity Theory (AT) (Leontiev, 1978)
establish the suitability of social theories to study MASs. AT is a framework for
the study of human societies that considers all labor as simultaneously individual
and social. The social component includes the actual society in which a subject
carries out the activity and also the historical development of those activities.
Evolution is the result of changes introduced by organizations in their activities
to solve contradictions. A contradiction in AT is a tension between elements in
the activity and can be caused by several reasons, such as different objectives,
ways of use, or needs.
AT helps in requirements elicitation (Fuentes, Gómez-Sanz, & Pavón, 2004) and
the analysis of contradictions ( Fuentes, Gómez-Sanz, & Pavón, 2003). In both
cases, the idea is to use UML-based representations of AT concepts to represent
contradiction patterns and requirements. These techniques are currently
being tested within this methodology, incorporating these concepts into the
INGENIAS process in future releases.
Support Tools
The INGENIAS Development Kit (IDK) is a set of tools that supports the
development process in INGENIAS. The IDK offers two kind of tools: a visual
editor and modules. The visual editor works as a modeling tool (Figure 11) that
TEAM LinG
Figure 9. Activities to produce an agent viewpoint for analysis
1.Identify agents using the rationality

principple
principle
3. Identify relevant intelligence or autonomy concerns with

respect current problem domain
2. Associate tasks or roles to the agent to enable goal

achievement
4. Determine requirements to observe for the

mental state manager and mental processor
Analysis agent viewpoint complete

8. Check that the model is coherent and End
perform appropriate modificationsif not
discussion about whether resulting goals do influence each other or not. On the
other hand, if goals are discovered first, it should be studied how to achieve the
state identified by the goal. If the goal is too generic, there could be many
candidate tasks or none. In the latter case, a refinement of the generic goal would
be needed. In the former case, a task-selection criterion should be described.
Achieving a goal may also involve the collaboration of other agents. This would
be represented by playing a role involved in an interaction or by executing a task
that produces an interaction, for instance.
Activity 2.c in Figure 10 tests the appropriateness of identified tasks and goals.
In principle, tasks can satisfy goals, make them fail, modify them, create them,
or destroy them. In addition, a goal may be indirectly satisfied due to the success
of its subgoals. It may be that a new goal is already subsumed by another pre-
existing one or that the execution of certain tasks already satisfies more than one
goal, including the new one. Such situations may lead to the conclusion that the
new goal does not improve the design.
TEAM LinG
Module development starts in the design-inception stage with the development

of a prototype. It follows an iterative prototype generation process that runs in
parallel with the main stream. Using IDK tools, developers grow the initial
prototype, incorporating new specification elements at each iteration:
1. Initial prototype. Every iteration starts with a prototype candidate that

implements a part of a concrete aspect of the specification. For instance,
if the aspect is communication, it can support agents that implement a
simple protocol. From here, the prototype solution can be reused to
implement all the interactions defined in the specification the same way, but
automatically.
2. Integrate with code generation facilities. The prototype is converted
into code templates. This way of implementation provides a double feed-
back: from specification to implementation by providing information to
generate the code, and from implementation to specification by providing a
computational model that can be used to verify the code.
a. Validate the module with the specification. Initial effort is invested
in checking that the specification is traversed properly and that the
module extracts the information it should.
b. Verifying the specification with the module. Once the prototype is
integrated with the IDK facilities, it is possible to state whether the
specification is correct according to the information that the template
needs. It would not be correct if the graph traversal that the module
needs cannot be executed due to lack of information in the specifica-
tion (missing elements or relationships, missing fields in the entities,
and the like). It would not be correct either if the graph traversal is
successful but the information extracted was not correct (for in-
stance, a number was expected and a string was found).
3. Generate another prototype. When the module is operative, it is applied
to the complete specification to produce a new prototype. This prototype is
modified again to partially incorporate other aspects. In this case, it would
be the execution of tasks on receiving or sending a message. The result
would be the initial prototype of the next iteration.
As a result, the IDK has influenced our initial version of the INGENIAS
development process. It has induced some new roles: module developer,
prototype developers, and analysts. Prototype developers produce the initial
versions of small parts of the system according to the identified needs. Module
developers adapt these prototypes to modules, generating templates and the
TEAM LinG
Figure 11. INGENIAS visual editor supports analysis and design of an

MAS. This tool permits packaging diagrams, cut & paste, zoom, automatic
layout, editing properties of components, taking snapshots, and navigating
through the specification, among others. Also, there are special components
that link one diagram to other, and text notes to clarify diagrams. Finally,
developers can save or load their projects, which are stored in XML format.
supports the notation presented in the second section of this chapter. Modules
have been presented already as the core of the code generation facilities.
The IDK is associated with the definition of the views, the meta-models, through
a XML representation of meta-model concepts, relationships, diagrams, and
graphical representation. Therefore, it is easy to make changes in the meta-
models without affecting the functionality of the IDK. This feature enables the
decoupling between the methodology and these tools, and, at the same time, it
facilitates experimentation with agent concepts.
The IDK is fully implemented in Java and distributed under GNU General Public
License and can be downloaded from http://ingenias.sourceforge.net. It is
distributed together with a reference manual that includes detailed information
about how to develop a module, how to create and modify diagrams, and a
description of the meta-models that implement the tool.
TEAM LinG
Applying the Development Process
As in other methodologies, the first steps have a great importance since they bias
the rest of the development. Here, first steps imply deciding what kind of
diagrams to be created first and, therefore, which are the first identified
concepts. In Figure 8, it is suggested to start with an organization model, a UML
use case model, and an environment model. These diagrams were selected
because they represent a counterpart in the agent domain to the diagrams needed
in the USDP inception phase. However, developers have the freedom to select
others, taking into account their backgrounds. Though activities would remain
the same, selecting other diagrams determines other different development
processes where activities are executed in a different order and whose products
follow different abstraction levels. To assist developers in that situation, we
include a subsection here. That section indicates briefly what other diagrams
should be detailed according to how the process is started.
When following the instructions from Figure 8, the process is quite straightfor-
ward. Developers should determine the kind of product to generate (i.e., an agent
diagram), the phase involved (i.e., inception), and the workflow stage (i.e.,
analysis). With this information, the developer consults one of the ten activity
diagrams and applies the activities in order to obtain the requested result.
Sometimes, especially at the beginning of the process, the activity diagram
produces too much information. In our experience, the best advice is to use
Figure 8 as a guideline and avoid executing those activities that lead to
information not needed in the current stage. Therefore, Figure 8 controls the level
of abstraction and the activity diagram indicates how to obtain the required
information.
To give readers a feeling of how the development process works, we have added
references to the activities along the experiment. These are explained briefly.
Providing full details of all existing activities is not possible here because of space
constraints. For more information, readers are invited to visit http://
ingenias.sourceforge.net.
Activities are executed within the USDP. The USDP states that it may be
necessary to iterate over different phases until the system is finalized. Hence,
several analyses may occur along the development.
In our methodology, the process ends when there is a functional system that
satisfies user requirements. These are identified with use cases at the beginning.
TEAM LinG
Analysis-Inception Stage
In this stage, the analyst has to demonstrate the feasibility and convenience of
building the system. This implies the definition of key functionality, first. This is
achieved by identifying use cases (Figure 12), four in our case. The main
functionality deals with how to sell a book to the customer, how to obtain new
books from publishers, how to know in advance which books should include a
discount, and informing students of the availability of these books. These use
cases are associated with role entities by means of participates relationships.
We could try to organize these roles with organization diagrams, but these
diagrams would show little information at this moment. We preferred to leave
this to the end of the section where more entities can be integrated. Nevertheless,
three main organizations can be identified: the publisher, the bookshop, and the
business school.
Next, it should be determined what existing resources and applications should be
reused by the new system. We obtain this information by elaborating on the
environment diagrams (Figure 13) that describe the existing system, according
Figure 12. Initial set of use cases and participating roles
TEAM LinG
Figure 13. Initial elements identified in the environment of the MAS (To
check notation, see Figure 7)
to the activities defined in Figure 14. In the same diagrams, the identified
applications will determine the perception of the agent. To better understand the
kind of perception, we have allowed ourselves to propose the existence of three
types of agents.
Figure 13 shows that agents are connected with proprietary applications to obtain
information about their users. In this case, the analyst decides that interaction
with users will be realized with Web technology, so an application server is
needed. This application server is represented by an environment application
entity. This entity captures the operations that a user may request to its agent and
vice versa.
Figure 14. Activities to produce environment models in the analysis-

inception stage (Results of these activities are shown in Figure 13)
Activity Result
Identify applications from the environment (1.a) A set of applications
Associate operations on the applications (2) Operations on the applications
Determine perception of the agents (6) Associations between agents and applications
TEAM LinG
It is assumed that organizations participating in the case study own databases.

We represent these databases as application entities. By connecting databases
with agents, we enable agents to detect, for instance, when one item from the
stock is running out. Databases could provide events that trigger agent actions
or else agents could poll the database to obtain relevant information about the
current state.
The next step is to organize identified applications, resources, and roles into
organizations. These organizations are produced with a similar set of activities,
which are described in Figure 15. Figure 16 shows the organization that
represents the Juul bookshop. This bookshop has two main roles: the buyer and
the sales responsible. These roles were identified in Figure 12.
Figure 15. Activities to produce an organization model in the analysis-

inception stage
Activity Result
Identify groups (1.a) A set of groups
Generate members (1.b) Elements that constitute groups
Identify goals (2c) Goals associated to organizations
Figure 16. Initial representation of Juul Bookshop organization (To check

notation, see Figure 1)
TEAM LinG
Starting the Process: Recommendations
Though the INGENIAS methodology defines deliverables and activities to

produce an MAS model for each viewpoint, there may be five different starting
points for the development. Each one deserves special consideration:
• Environment. If the MAS to be developed will coexist with other

software—usually non-agent based software—identifying this software in
the first place is recommended. By using environment models, the devel-
oper can consider dependencies with legacy and proprietary software from
the beginning. We tend to include elements like application servers or
databases, which are very common in today’s developments. Once these
elements have been identified, the developer can determine how the
agent’s perception can be defined in terms of these applications and what
functionality these applications can provide.
• Interaction. Researchers used to the object-oriented paradigm may prefer
to use interactions and use cases. Interactions in this approach are similar
to those in UML, but they include direct associations with tasks and agent
mental states, so these interactions can enable further refinements with
agent views or tasks and goal views.
• Organization. The organization of an MAS defines its system architec-
ture. Top-down system-subsystem identification is a traditional technique
in software engineering that could be applied using this view. The system
could be the organization, and the subsystems each group in the organiza-
tion. Interfaces of subsystems and system would be the roles belonging to
each group. Interface operations would be the tasks and workflows
belonging to the organization, and they would be assigned to roles with
responsibility relationships.
• Agents. Initially determining system agents is a risky decision. Our
experience is that it is very easy to fall into a situation where everything
is an agent. Instead, we think it is better to start with roles and, later on,
assign them to agents. However, if the MAS has to interact with already
existing agents, perhaps it is a good idea to determine what can be expected
from these agents before doing anything else. In such situations, there is a
high risk of duplicating functionality already present in these agents; hence,
the need to know first what they can do.
• Tasks and goals. This may reflect a functional approach. The developer
identifies a set of tasks (and their expected output) that the system must
execute. However, this approach may make it difficult to justify system
goals, because they would be identified by asking why should the agent
TEAM LinG
execute this task?, which is not intuitive and compliant with a rational
approach (an agent executes a task because it wants to satisfy one of its
goals). An alternative is to identify the states that the system must reach
by determining the system goals.
Case Study: An E-Business Application

As a case study to illustrate the INGENIAS methodology, we present here the
Juul Møller Bokhandel A/S described by Anderson (1997), because it deals with
some interesting agent features and applications, such as supply chain manage-
ment, negotiation, workflows, enterprise modelling, and user modelling. It
describes a bookshop that sells books to university students. The company has
an agreement with professors and students to obtain a list of books used in their
courses and sell them at special prices. The bookseller is considered as an
organization in which there are departments in charge of sales and departments
in charge of logistics. This organization has to negotiate with other organizations
and publishers to acquire books at the best prices and within specific timing
constraints. It can also negotiate for special arrangements for certain books that
are needed for specific courses. Sales can be conventional or through the
Internet.
In this case study, the goal is to define an electronic sales system. Figure 16
shows a first approach to the organization of the bookshop. The Juul Møller
Bokhandel A/S bookshop (from now on, the Juul bookstore) is modelled initially
as two departments: Logistics and ESales. The first is responsible for delivering
goods to customers and receiving books from publishers. The second is respon-
sible for interacting with customers and providing representatives that interact
with other publishers.
During the case study, the reader will find references to different activities.
These come from the development activity diagrams and can be accessed at
http://ingenias.sourceforge.net. The notation of each diagram has been noted
in the caption of each figure and is detailed on the INGENIAS Web site.
The construction phase, according to the USDP, deals mainly with the develop-
ment of those use cases not considered in the elaboration phase. These remaining
use cases should correspond to concrete situations that do not modify the key
functionality. Therefore, and also due to space limitations, we omit the construc-
tion phase here, though we may make this information available in our Web site.
TEAM LinG
According to the specifications, there are other organizations as well: a publisher

and a business school. They would be represented as the example from Figure
16: defining groups, associating goals, and existing resources.
Design-Inception Stage
There are no activities applicable here, since it is a very domain-specific stage.

Figure 8 declares that in this stage a developer builds some prototypes with a
rapid application tool or explores concrete aspects of the problem to test different
technologies. In this case study, we dedicate this stage to start the development
of the code generation module and to create some example Web pages to
illustrate user interaction.
Code generation module development starts by exploring how a session-oriented
communication mechanism could be implemented with our target platform,
JADE. The goal was constructing a small prototype that implemented a simple
protocol in JADE, such as three message exchanges among three agents. This
system is intended to test how communication management could take place and,
later, how BDI concepts could be translated to the prototype. The prototype
development took some time and was not finished in this stage. As mentioned in
the implementation section, its development runs in parallel with the main stream
of the case study, the generation of the system specification. In the end, the effort
resulted in asimple agent architecture able to manage different conversations
with different agents at the same time. This architecture will be introduced later,
along with its role in the code generation module.
The Web pages are aimed at showing the functionality to be implemented. This
effort served to clarify what each kind of user expected from the system. We
were more interested in the workflow of actions in the system than in the data
itself. We wanted to create pages where users executed the actions they were
supposed to and where we could examine the outputs. These initial experiments
were used later in our servlet based workflow simulator, a module able to
reproduce the workflow of activities from the specification in a servlet.
Analysis-Elaboration Stage
In the elaboration stage, in each iteration, the analyst reorganizes use cases,
putting together related cases and discovering new ones. Though new use cases
may appear, this process converges, according to the USDP, to a point where
few use cases appear. In fact, use cases that represent key functionality
constitute a small percentage of the whole application. Here we just consider
those already presented in Figure 12.
TEAM LinG
Figure 17. Activities for generating initial specification of interactions in

the analysis-elaboration stage
Activity Result
Identify goals for performing an interaction (1) A set of goals
Identify nature of interaction (3) Category of interaction
Identify participants in interaction (2c) A set of participants
Generate an initial specification (4) Collaboration diagrams
In the refinement, we show an extension of UML use case diagrams that

introduces interaction entities into these diagrams. For each use case, a new
interaction entity is created (Figure 18) and associated with it. Each interaction
is considered independently, studying the goals it pursues and the actors involved.
As an example, the interaction in Figure 19 has as its goal that the bookseller
knows which book titles are more interesting to the school. This goal was
identified by asking what state should I reach by executing this interaction.
In the interaction, a professor will start the process and the sales representative
of the bookshop will collaborate. The professor and the representative will each
Figure 18. Result of a refinement of initial use cases and their association
with interactions. It is a UML use case with associated interactions. (The
meaning of the interaction symbol is given in Figure 5.)
TEAM LinG
Figure 19. Initial description of the interaction” obtain book list” (To
have different reasons to participate in this interaction. This will be discussed

soon. The interaction is first detailed using a collaboration diagram, not shown
here, with three messages: the professor offers a list of interesting books, the
representative filters this list, taking into account the prices it can obtain in the
sales market, and then the professor provides a final list of the filtered books.
Later, this initial collaboration diagram will be transformed into a GRASIA
diagram (Figure 6).
Now it is time to think about two things: what goals justify the participation of
these roles in the interaction, and what tasks will satisfy these goals. These
questions are answered by the activities from Figure 21. Starting from the goal
Bookshop knows what material is required, we refine the goal discovered in
the interaction definition and create tasks to satisfy it. In this case, we assume
that the goal identified in the interaction is a subgoal of two goals pursued by
participating roles. These goals are collected into a separate diagram, organizing
them with goal decomposition relationships and establishing dependencies
among them. New goals may appear, but, as also with use cases, our experience
says that there is a convergence point where no more goals appear. In other
diagrams, goals are related with tasks representing plans for goal satisfaction
(Figure 20).
Figure 20 shows an initial assignment of tasks to a previous goal identified in
Figure 19. The first task assignment is relatively intuitive. Elaborate University
Book List produces a first draft of the list of books used in the school. To
elaborate this list, it seems natural to access the school database and see what
books are being used in each subject. This list is filtered by the bookshop, in the
task Evaluate Interest Of Books, to produce a ranking of books according to the
price it can get from other publishers and current stock. Here we assume that
TEAM LinG
all the information can be obtained from the bookshop database, but we could
also say that a negotiation should be started with some publishers to see what
prices they offer. This could be done by saying that the task produces an
interaction. Filter books takes the book evaluation and produces a preprocessed
book list. Later, Elaborate Book List would produce the final list of books to be
bought. Again, the bookshop database may be required to generate a detailed list
of the prices and books.
Readers should be aware that, in determining the role of these tasks, we need to
elaborate other diagrams, such as organization diagrams and agent diagrams, in
order to determine who is responsible for executing these tasks. Later, in the
design, these tasks will be composed into workflows.
After identifying tasks, new resources, roles, and applications tend to appear. As
in the analysis-inception, we collect them into a refinement of the organization,
as shown in Figure 22.
Figure 22 shows that the organization has several workflows, one per interaction.
These workflows will collect tasks identified previously in diagrams such as
Figure 20. The Obtains books from Publisher workflow details how the
bookshop contacts the publisher, negotiates a price, and arranges a delivery. The
Provide book list workflow details the tasks involved in obtaining the discount
book list. The Organization Management workflow describes the tasks that
Figure 22. Refinement of the Juul organization to include new items

discovered (To check notation, see Figure 1)
TEAM LinG
Figure 20. Goal-task relationships. These relationships will be refined

later to determine their nature (To check notation, see Figure 4)
Figure 21. Activities to refine task and goals in the analysis-elaboration

stage
Activity Result
Identify tasks and goals (1) A set of goals and tasks
Decompose goals (4) Goal decomposition
relationships
Associate goals and tasks (2) Relationships among tasks and
goals
Decompose tasks (3) Task decomposition
relationships
Determine relationships Dependency relationships
amongs goals (5). among goals
Associate tasks and Instances of WFProduce
interactions(6.a) connecting task and
Interaction entities
Relate tasks with its products Instances of WFProduce and
(6.c) and inputs (6.b) WFConsume
Associate tasks and Instances of WFUse
applications (6.d). connecting applications and
tasks
TEAM LinG
coordinate internal work within an organization. The Sell books through

Internet workflow collects the tasks needed to get the order from the user,
create a bill, and deliver a book. By executing these workflows, the organization
will be able to achieve its main goal: sell books.
Design-Elaboration Stage
The design-elaboration stage adds another level of detail by describing how

interactions occur, why, and what is the relationship between interactions, tasks,
and the mental state of each agent. Also, in the design, the developer tries to
describe aspects of its mental state management with the same notation. This
way, a developer may say that a task produces the goals that direct the behaviour
of an agent, or that old facts should be removed.
Our recommendation in the design is to refine goals and workflows at the same
time. Workflows clarify the relationships among tasks into different participants
Figure 23. GRASIA interaction diagram detailing tasks and interaction

units to elaborate a list of discounts on books (To check notation, see
Figure 6)
TEAM LinG
of an interaction. The interaction, on the other hand, highlights when tasks are
executed and the mental states required from the agents to start and continue
interactions. Goals are refined by determining when a goal is satisfied and when
it has failed.
Figure 23 shows a more elaborate view of the interaction from Figure 19 using
interaction units to abstract the communication technology and to include details
about the speech act (FIPA, 2001)—inform in this case, which is used in addition
to mental attitudes of participants. These will be explained later. Also, the
interaction allocates tasks, determining when the tasks from Figure 20 are
started.
The initial mental attitude of the professor (Figure 24) is referred to in an attribute
in the UIInitiates relationship. In this case, the mental attitude appears. Figure
24 shows that, in order to obtain a book list, there should be an event indicating
that there is a new book in the school database and a goal in the pending state.
Pending state means that this goal has no assigned task yet and has not yet been
refined into subgoals. The event would appear because there is a perception
relationship between the agent playing the role professor and the business
school database, similar to those identified in Figure 13 between the bookshop
agent and the bookshop database.
Proceeding in the same way with each actor of the interaction, we obtain a list
of mental states to be achieved in runtime from an initial one. These mental states
are the result of executing tasks. Therefore, the study of mental states and
associated tasks could be continued within the goal/task view. Tasks could be
examined also from the point of view of workflows. Figure 25 shows a workflow
created with the tasks identified in the interaction view and the goal/task view.
This workflow explains how to obtain a list of books from the business school.
Figure 24. Mental state required to start a obtain book list interaction (To
TEAM LinG
Figure 26. JADE-based agent architecture. It reuses JADE behaviours to

implement protocols.
AddNewConv
Agent
SimpleBehavior ersation
(from co...
(from behaviors)
creates
manages RemoveFinished
StateBehavior JADEAgent Cyc licBehavior
Conversations (from behaviors)
(from jade) creates
sends a receives a
creates
message with message with
0.. *
0..*
SyncRe
SyncSender DetectNotProcess
ceiver
edMessages
modifies modifies
current state current state
<<Interface>> triggers changes
StateUpdater in the mental st ate MentalState
Internally, this agent has three basic behaviours:
• Detect messages not being processed and allocate them into a data
structure.
• Create behaviours to deal with messages not processed and that are known
to the agent.
• Remove behaviours to handle protocols that are already finished.
The idea is to add State behaviour as demanded by internal processes of the

agent, as a result of initiating an interaction, or by external processes, as a result
of receiving a request to start an interaction. A benefit of this approach is a better
use of resources and the introduction of the concept of conversation manage-
ment that makes an agent able to handle several conversations at the same time.
This architecture was created ad hoc, taking these requirements as a guideline
and trying to implement one protocol with three states and three participants.
Once the prototype worked, we translated the code into templates, such as that
in Figure 27. The translation process, basically, traverses an interaction diagram
determining in which interaction units a concrete actor participates. With these
units, it generates a state machine that takes into account a subset of the states
considered in the global interaction. The template from Figre 27 is instantiated
for each interaction that the agent can start. The data used in this instantiation
TEAM LinG
Figure 25. Workflow interconnecting tasks identified in Figure 20 (To

Finally, again, new pieces of information that affect the analysis model of the
organization should be reconsidered. It is unlikely that new workflows will
appear, although there could be new goals, resources, or applications.
Implementation
Implementation of different elements from the specification leads us to develop

some of the current modules that are included in the current IDK distribution. In
this chapter, we focus on how a JADE-based communication is generated
automatically from the specification. This effort was initiated in the design-
inception stage as a set of experiments aimed at obtaining an agent architecture.
The result is shown in Figure 26. The architecture is biased by JADE compo-
nents, since it necessitates using special classes to send or receive messages.
This architecture uses State behaviour as a customized implementation of a
state machine. This state machine can start two kinds of behaviours, which are
responsible for sending and receiving messages. Each instance of a state
machine can handle a kind of protocol, and the agent can handle several
instances of the same state machine at the same time. Also, the agent can start
these state machines on demand.
TEAM LinG
Figure 27. Part of the template responsible for sending messages in a State
behaviour specialization
@repeat id="sendaction"@
if (sequence.equals("@v@iud@/v@")&& options.length>0) {
int count=0;
@repeat id="nextstates"@
if (options[count].equals("@v@possibleiu@/v@")){
boolean alldefined=true;
@repeat id="condfacts"@
Fact @v@label@/v@=getAgent().getFact("@v@type@/v@");
alldefined=alldefined && @v@label@/v@!=null;
@/repeat@
@repeat id="condevents"@
Event @v@label@/v@=getAgent().getEvent("@v@type@/v@");
@/repeat@
@repeat id="condgoals"@
StateGoal @v@label@/v@=getAgent().getGoal("@v@type@/v@");
@/repeat@
if (alldefined && @v@condition@/v@){
sb.setState(options[count]);
}
}
count++;
@/repeat@
processed = true;
}
@/repeat@
are those of the interaction itself (obtained from Figure 23), the next interaction
unit to be executed, and the mental attitude required in the agent in order to
execute the task (which are obtained from Figure 24). So agents in the interaction
have a partial knowledge of its current state, which makes interaction more
efficient than having a global state shared among several agents.
Just as an example, Figure 28 shows the result of instantiating the template with
data from Figure 27 and Figure 24. At present, Figure 28 says that the interaction
will not be started until there is a goal labeled Bookshop_knows_what_
material_is_required and an event labelled ThereIsANewBookInSubject.
With respect to the verification of the specification, this template forces the
specification to define mental states for agents initiating an interaction and to
identify a condition or/and some mental entities, such as Goals or Facts. It could
do even more, such as determining if the goal can appear in the mental state of
the agent in the future. Instead of applying temporal logics, what this module does
TEAM LinG
Figure 28. Instantiated template from the Figure 27 (Source code shown
here is only a part of the whole program)
if (options[count].equals("inform_library_of_book_list")){
Boolean alldefined=true;
Event
newBookEvent=getAgent().getEvent("ThereIsANewBookInSchoolDatabase");
alldefined=alldefined && fact!=null;
StateGoal
goal=getAgent().getGoal("Bookshop_knows_what_material_is_required");
alldefined=alldefined && goal!=null;
if (alldefined && true){
sb.setState(options[count]);
}
}
count++;
processed=true
Figure 29. Failures in the specification detected with the JADE module
is detect instances of this goal in the initial mental state of the agent (described
in another diagram) or if the agent is responsible for a task producing it.
Figure 29 shows an example of the errors that produce the current JADE module
included in the distribution. This is not as precise as formal methods, although it
is more intuitive for developers of average skill. Also, performing this kind of
verification does not prevent the application of formal methods to perform
further checking of the system and ensuring that the agent will have a determined
mental state in the future.
Conclusions
The INGENIAS methodology is the result of experience in developing agent-
based applications during the last five years. We have found that the use of a
methodology is the key to the control and management of the development
TEAM LinG
ments and determine how many instances of each element shall exist. At
the moment, there is no support for deployment or component diagrams in
the current version of INGENIAS. Instead, INGENIAS delegates this task
to existing UML compliant development tools.
• Code generation. When there is a new target platform, it is necessary to
define the code generation templates. Though there is a generalized method
for generating code from the specification, there are still open issues in the
process. Developers have to participate, actively customizing how the
marked-up sources are rewritten using the specification generated with the
INGENIAS graphical language. This can be tiresome, particularly when
the developer has never developed an MAS and does not know in advance
which agent architecture to use or how an agent platform works.
• Specification correctness. Currently, the IDK applies mainly a module-
based verification and assists the user in the diagram construction activi-
ties. Due to this assistance, all diagrams are built correctly with regard to
existing meta-models. Ongoing work is being carried out to ensure the
correctness of specifications in two other aspects: coherence of diagrams
and the presence of inconsistencies. To ensure coherence between dia-
grams, INGENIAS already defines a set of rules that follow the pattern “if
an element of type X appears in the diagram of type Y, then it also has
to appear in some diagrams of type W and Z.” These rules are defined
in the original thesis work by Gómez-Sanz (2002). At present, the set of
rules is verified manually by developers during the development process,
but work is being done to make this automatic. INGENIAS is also applying
automated consistency checking using models defined with Activity Theory
(R. Fuentes et al., 2003). Activity Theory is useful because the behaviour
of agents is defined in similar terms to human and social behaviour.
Acknowledgments
This work has been supported by the Spanish Council of Science and Technology
(TIC2002-04516-C03-03).
References
Andersen, E. (2001). Juul Moller Bokhandel A/S. Retrieved April 1, 2005,
from Espen Andersen Web site http://www.espen.com/papers/index.html
TEAM LinG
Caire, G., Leal, F., Chainho, P., Evans, R., Garijo, F., Gomez-Sanz, J. J., et al.
(2001). Agent-oriented analysis using MESSAGE/UML. In Proceedings
of the Second International Workshop on Agent-Oriented Software
Engineering (AOSE 2001), LNCS 2222 (pp. 119-135). Berlin: Springer-
Verlag.
DeLoach, S. (2001). Analysis and design using MaSE and agentTool. In
Proceedings of the 12th Midwest Artificial Intelligence and Cognitive
Science Conference (MAICS 2001), Miami University, Oxford, Ohio,
March.
Demazeau, Y. (2001). La méthode VOYELLES, dans Systèmes Multi-Agents.
Des Théories Organisationnelles aux Applications Industrielles. Oslo,
Norway: Hermès.
FIPA. (2001). FIPA ACL message structure specification (No. 00061 stan-
dard). Retrieved April 1, 2005, from FIPA Web site http://www.fipa.org/
specs/fipa00061/
Fuentes, R., Gómez-Sanz, J. J., & Pavón, J. (2003). Activity theory for the
analysis and design of multi-agent systems. In Proceedings of the Fourth
International Workshop on Agent Oriented Software Engineering
(AOSE 2003), Lecture Notes in Computer Science 2935 (pp. 110-122).
Berlin: Springer-Verlag.
Fuentes, R., Gómez-Sanz, J. J., & Pavón, J. (2004). Towards requirements
elicitation in multi-agent systems. In Proceedings of Cybernetics and
Systems 2004, the 17th European Meeting on Cybernetics and Systems
Research (EMCSR 2004), Vienna, Austria, April (pp. 582-587). Austrian
Society for Cybernetic Studies.
Gomez-Sanz, J. J. (2002). Modelado de Sistemas Multi-Agente. PhD thesis,
Universidad Complutense de Madrid, Madrid.
Gomez-Sanz, J. J., Garijo, F., & Pavón, J. (2000). Intelligent interface agents
behaviour modelling. In Proceedings of the Mexican International
Conference on Artificial Intelligence (MICAI 2000), Acapulco, Mexico,
April, (LNAI 1793, pp. 598-609). Berlin: Springer-Verlag.
Gómez-Sanz, J., Pavón, J., & Díaz-Carrasco, A. (2003). The PSI3 agent
recommender system. In Proceedings of the International Conference
on Web Engineering, ICWE 2003, LNCS 2722 (pp. 30-39). Berlin:
Springer-Verlag.
Huhns, M. N. & Stephens, L. M. (2000). Multiagent systems and societies of
agents. In G. Weiss (Ed.), Multiagent systems (pp. 79-120). Cambridge,
MA: MIT Press.
Iglesias, C., Mercedes Garijo, M., Gonzalez, J. C., & Velasco, J. R. (1998).
Analysis and design of multiagent systems using MAS-CommonKADS. In
TEAM LinG
M. P. Singh, A. Rao, & M. J. Wooldridge (Eds.), Intelligent Agents IV

(LNAI Volume 1365 ed., pp. 313-328). Berlin: Springer-Verlag.
Jacobson, I., Booch, G., & Rumbaugh, J. (1999). The unified software
development process. Reading, MA: Addison-Wesley.
Leontiev, A. N. (1978). Activity, consciousness, and personality. Englewood
Cliffs, NJ: Prentice Hall.
Lyytinen, K. S. & Rossi, M. (1996). METAEDIT+: A fully configurable multi-
user and multi-tool CASE and CAME Environment. In P. Constantopoulos,
J. Mylopoulos & Y. Vassiliou (Eds.), Proceedings of the 8th Interna-
tional Conference on Advances in Information System Engineering
(Vol. 1080, pp. 1-21). Berlin: Springer-Verlag.
Newell, A. (1982). The knowledge level. Artificial Intelligence, 18, 87-127.
Nwana, H. S., Ndumu, D. T., Lee, L. C., & Collis, J. C. (1999). ZEUS: A toolkit
for building distributed multi-agent systems. Applied Artificial Intelli-
gence Journal, 1(13), 129-185.
OMG. (2000). Meta Object Facility (MOF)(specification) (No. V.1.3. for-
mal). Retrieved April 1, 2005, from OMG Web site http://www.omg.org/
cgi-bin/doc?formal/00-04-03
Picard, G. & Gleizes, M. P. (2004). The ADELFE methodology: Designing
adaptive cooperative multi-agent systems. In F. Bergenti, M. P. Gleizes, &
F. Zambonelli (Eds.), Methodologies and software engineering for
agent systems. Boston: Kluwer Academic Publishing.
Wooldridge, M., Jennings, N. R., & Kinny, D. (2000). The Gaia methodology for
TEAM LinG
process of an MAS and helps to identify the elements and relationships that make
up the MAS.
INGENIAS offers to the agent developer a methodology and tools to build agent-
based applications, from analysis specification to implementation in code. An
agent developer can start depicting an organization for the MAS, which identifies
its main goal and basic entities. The main goal can be decomposed in a goal/task
diagram. Interactions between entities can be described in several interaction
diagrams. At the end, the developer has created several diagrams, which are
stored as XML files and can be used later by the code generation tools to produce
the code for a target agent platform.
INGENIAS is original with respect other methodologies in several respects:
• It defines a conceptual framework where different research approaches

can be allocated. By using meta-models, core existing concepts can be
expanded with new ones.
• It truly considers analysis, design, testing, and implementation of an MAS
in a generalized way. The implementation has been illustrated with an
example of module definition.
• The development process itself provides tools to verify and validate the
specification. Usually there is a gap between the specification and the final
implementation, but in this proposal, all evolve at the same time. The
specification is used to detect elements to be present in the implementation,
and the implementation procedure is used to validate the specifications.
This methodology is currently being used mainly for educational and research
purposes in several universities in Spain. Our current goal is to develop new
modules and case studies, improving the tools to be applicable in software
industry environment and in alignment with FIPA standards.
We have identified four main open issues that will be covered in new releases
of INGENIAS:
• Primitives to express algorithms. INGENIAS encapsulates algorithms in

tasks and describes only its inputs and outputs. To express algorithms
directly, two alternatives are being considered: creating custom primitives
to express algorithms, or linking with better methods to express algorithms,
such as UML sequence diagrams or UML activity diagrams.
• Explicit representation of deployments. INGENIAS can reuse UML
deployment and component diagram specifications. These diagrams make
it possible to associate specification elements with implementation ele-
TEAM LinG
Towards Radical Agent-Oriented Software Engineering Processes 277
Chapter X
Towards Radical
Agent-Oriented
Software Engineering
Processes Based on
AOR Modelling
Kuldar Taveter
The University of Melbourne, Australia*
Gerd Wagner
Brandenburg University of Technology at Cottbus, Germany
Abstract
This chapter proposes a new agent-oriented software engineering process

called RAP, which follows the Rational Unified Process (RUP) in many
ways, but is based on Agent-Object-Relationship (AOR) modelling instead
of object-oriented modelling. The chapter briefly presents the foundational
ontology that supports the methodology and introduces the RAP/AOR
viewpoint modelling framework. It then describes the modelling from the
interaction, information, and behavior aspects of the framework by using
a case study of business-to-business electronic commerce. Finally, the
chapter describes an implementation approach based on the Model Driven
TEAM LinG
280 Taveter & Wagner
process automation and supply-chain management systems) for the business

domain and not so much with Artificial Intelligence (AI) systems.2 This
difference implies that we are not so ambitious about capturing human-like
intelligence features such as desires and intentions, or sophisticated forms of
proactive behaviour. Rather, in RAP/AOR we focus on declarative models of
communication and interaction founded on reactive behaviour and on the basic
mental state components of beliefs, perceptions, and commitments.
Note that perceptions, as the mental state component that is the basis of
communication and interaction, have been neglected in the popular Belief-
Desire-Intention (BDI) model (Rao & Georgeff, 1991). Following the logic-
based AI tradition, which is only interested in reasoning/thinking and tends to
ignore other cognitive aspects and activities, the BDI paradigm has treated
beliefs and reasoning as primary and perceptions and communication as second-
ary. However, as has been pointed out in the speech act theory (Austin, 1962),
in reality, it is the other way around: communication is primary, and the concepts
of beliefs and assertions are based on communication. In some BDI approaches,
perceptions are indeed treated as beliefs. However, this is clearly unsatisfactory,
both conceptually and technically. The perception of an event can indeed be
mapped into a corresponding “event has happened” belief; but we cannot assume
that this is the case with all perceptions, since this would not be the case with
irrelevant perceptions and would lead to an overflow of the belief/knowledge
base of an agent. Conceptually, perceptions are transient (and are consumed by
the attention process), while beliefs are persistent.
In comparison with recent techniques and notations for creating executable
business process specifications based on Web Services (WS) (http://www.w3.org/
2002/ws/), such as BPEL4WS (http://www-106.ibm.com/developerworks/
webservices/library/ws-bpel/) and BPML (BPML, 2002), the difference be-
tween an approach based on WS and an agent-oriented approach like RAP/AOR
should first be clarified. Even though Web Services Description Language
(WSDL) (W3C, 2004) allows the representation of a message sequence
consisting of, for example, receiving a message and replying to it, this is far from
the dynamics of agent communication protocols like Contract Net standardized
by the Foundation for Intelligent Physical Agents (FIPA) (http://www.fipa.org/
). Secondly, in principle, an interface to a software agent can be embedded in a
WS-based interface that seems to be in line with the Web Services Architecture
(WSA) of the World Wide Web Consortium (W3C, 2003), according to which
services are provided by software agents.
An essential objective of the RAP/AOR methodology is to enhance team
productivity by agent-based work process management including both (well-
structured) workflows and spontaneous interactions among team members and
their software assistants. This issue is not covered in the present version of RAP/
AOR but will be the topic of future work.
TEAM LinG
The RAP/AOR methodology can be viewed as an agent-oriented refinement of

the Unified Software Development Process proposed by Jacobson, Booch, and
Rumbaugh (1999) and its commercial complement, the Rational Unified
Process (RUP) (Kruchten, 1999). It aims at achieving more agility than the
RUP by using simulation for early testing of analysis and design models.
Agile methodologies, such as the Extreme Programming proposal of Beck
(1999), have received much attention recently (Fowler, 2003). They emphasize
the value of lightweight ad hoc processes based on test-case-based development
and rapid prototyping and de-emphasize the value of detailed modelling on which
they blame the heavy weight and inflexibility of traditional methodologies and the
RUP. While we acknowledge the significance of agility, we disagree with their
analysis that blames modelling as the source of inflexibility. Rather, we agree
with the Model-Driven Architecture (MDA, http://www.omg.org/mda/) ap-
proach of the Object Management Group (OMG) where modelling is identified
as the core of state-of-the-art software engineering that is scientifically well-
founded. When a model-driven approach includes early testing of models by
means of simulation, agility is achieved even without setting a focus on code and
rapid prototyping.
We are aware of two other agent-oriented methodologies that also claim to
follow the RUP.
The ADELFE methodology described in (Bernon, Glaizes, Peyruqueou, &
Picard, 2002) is targeted at the engineering of adaptive multi-agent systems to
be used in situations where the environment is unpredictable or the system is
open. This niche methodology is based on the Adaptive Multi-Agent Systems
(AMAS) theory (Capera, Georgé, Gleizes, & Glize, 2003) and shares, with RAP/
AOR, prototyping by simulation.
The MESSAGE methodology (Evans et al., 2001) has been developed for the
particular needs of the telecommunications industry. The analysis model views
of MESSAGE can be compared to the viewpoint aspects of RAP/AOR: the
organization view and interaction view are subsumed under the interaction
viewpoint aspect, the goal/task view and agent/role view roughly correspond to
the behaviour aspect, and the domain view corresponds to the information
aspect. Although both MESSAGE and RAP/AOR have business processes as
a starting point, for business process modelling MESSAGE employs UML
activity diagrams that are, in our opinion, not truly agent-oriented. The reason is
that it is questionable to model the invocations of activities in the spheres of
responsibility of different “actor objects” (agents) as state transitions, as it is
done between “swim lanes” in activity diagrams because “actor objects,” which
are independent of each other, do not share states.
Unlike these two RUP-based agent-oriented methodologies, RAP/AOR is more
concerned with distributed agent-based information systems (such as business
TEAM LinG
The RAP/AOR Methodology

The RAP/AOR methodology emphasizes the importance of precise modelling of
the problem domain at hand for achieving an agent-based information system
with the required functionality. The preciseness of domain modelling is ensured
by the ontological foundation of the RAP/AOR methodology. It defines concepts
such as physical agent, non-agentive object, action event, social moment, and
institutional agent. Based on the ontological foundation, AORML introduces a
graphical notation for modelling the structure of an agent’s mental state,
comprising the modelling of agent types, their internal and external object types,
action and non-action event types, and commitment/claim types. Additionally,
AORML introduces reaction rules as its most important behaviour modelling
element.
The RAP/AOR viewpoint modelling framework enables viewing and modelling
a problem domain from the interaction, information, and behaviour viewpoint
aspects. Different kinds of models/diagrams are used for modelling from
different aspects, such as agent diagrams and interaction-frame diagrams of
AORML and use-case diagrams of UML from the interaction aspect, agent
diagrams from the information aspect, and goal-based use-case models, interac-
tion-pattern diagrams, and AORML activity diagrams from the behaviour
aspect. The RAP/AOR viewpoint modelling framework also distinguishes
between the abstraction levels of conceptual domain modelling, computational
design, and implementation. At the level of conceptual domain modelling, we
adopt the perspective of an external observer who is observing the (prototypical)
agents and their interactions in the problem domain under consideration. At the
levels of computational design and implementation, we adopt the internal (first-
person) view of a particular agent to be modelled and implemented, for example,
as an agentified information system (i.e., an information system represented
as one or more software agents).
Ontological Foundations of the RAP/AOR Methodology
The ontological foundation of the RAP/AOR concepts is provided by the Unified

Foundational Ontology (UFO) proposed by Guizzardi and Wagner (2005). In
addition to a foundation layer, called UFO-A, and the perdurant ontology layer
UFO-B, UFO includes an agent ontology layer, UFO-C, which is the basis of
AORML. UFO-C is summarized in the form of a UML class diagram in Figure
1, and in the form of a controlled English vocabulary presented below. While
beliefs and perceptions are categorized as mental moments (endurants that
existentially depend on one agent, their “bearer”), commitments are categorized
as social moments (endurants that existentially depend on several agents).
TEAM LinG
Architecture (MDA) and Extended Markup Language (XML). The

methodology is aimed at the creation of distributed socio-technical systems
consisting of both humans and technical, including software, components
that may, in turn, include software agents.
Introduction
A Radical Agent-Oriented Process (RAP) defines a software engineering
process1 using the Agent-Object-Relationship (AOR) modelling language pro-
posed by Wagner (2003a). In AOR modelling, the agents in a problem domain
are distinguished from the non-agentive objects. The agents’ actions, event
perceptions, commitments, and claims, as well as their rights and duties, are
explicitly included in the models.
The RAP/AOR methodology is based on Wagner (2003a) and Taveter (2004a).
Wagner (2003a) presents an agent-oriented approach to the conceptual model-
ling of organizations and organizational information systems, called AOR mod-
elling, where an entity is either an agent, an event, an action, a claim, a
commitment, or an ordinary object, and where special relationships between
agents and events, actions, claims, and commitments supplement the fundamen-
tal association, aggregation, and generalization relationship types of Entity-
Relationship (ER) and UML class modelling. Business processes are viewed as
social interaction processes emerging from the behaviour of the participating
agents. In the proposed approach, behaviour is primarily modelled by means of
interaction patterns expressed in the form of reaction rules that are visualized in
interaction pattern diagrams.
Taveter (2004a) proposes an integrated business modelling technique—the
Business Agents’ Approach—that is based on AOR modelling. Taveter (2004a)
emphasizes that in addition to being a technological building block, an agent is an
important modelling abstraction that can be used at different logical levels in the
creation and development of an information system. The Business Agents’
Approach suggests an elaboration of the existing business modelling frameworks
– six perspectives of agent-oriented business modelling for distributed domains.
These perspectives are the organizational, informational, interactional, func-
tional, motivational, and behavioural perspective. The Business Agents’ Ap-
proach covers modelling from all the perspectives mentioned by employing a
combination of goal-based use cases, the AOR Modelling Language (AORML),
and Object Constraint Language (OCL), forming a part of UML 2.0 (OMG,
2003b). The Business Agents’ Approach also extends the graphical notation of
AORML by activity diagrams that are executable and enable to represent
models of several or all perspectives in just one diagram.
TEAM LinG
We include this summary of UFO in this chapter because we want to give the
reader an idea of what a foundational ontology is and how it can help in
establishing a modelling method. The reader should know, however, that, lacking
the necessary space, we cannot treat this topic in greater depth here.
The most important concepts for the purposes of the RAP/AOR methodology,
presented in controlled English, are:
• physical agent: physical object that creates action events affecting

other physical objects, that perceives events, possibly created by other
physical agents and to which we can ascribe a mental state
Examples: a dog; a human; a robot
• action event: event that is created through the action of an agent
• agent creates action event: designated relationship
• agent perceives event: designated relationship
• non-agentive object: physical object that is not a physical agent
Examples: a chair; a mountain
• communicating agent: agent that creates communicative action events
directed to other communicating agents and that perceives communica-
tive action events that possibly lead to changes in its mental state
• social moment: moment individual that is existentially dependent on more
than one communicating agent
Examples: a commitment; a joint intention
• communicative action event: action event by which a communicating
agent, the sender, sends a message to one or more other communicating
agents, the receivers
• message: social moment that is exchanged between communicating
agents in a communicative action event
• communicating agent sends message to communicating agent: desig-
nated relationship
Inverse relationship: communicating agent receives message from
communicating agent
• sender: role name that refers to the first argument of the communicating
agent sends message to communicating agent relationship type
• receiver: role name that refers to the second argument of the communicat-
ing agent sends message to communicating agent relationship type
• institutional agent: social fact (Searle, 1995) that is an aggregate
consisting of communicating agents (its internal agents, which share a
TEAM LinG
Figure 1. The main categories of UFO-C described as a MOF/UML model
PhysicalObject
(from UFO-A)
*
MomentIndividual Event
(from UFO-A) (from UFO-B)
perceives
{disjoint}
{disjoint}
Intrinsic Non-Agentive
Moment Object Non-Action
ActionEvent
* Event
* 1 creates *
inheres in
Physical
MentalMoment
Agent 1..*
Communicative
{disjoint} Message
ActionEvent
* * 1
Belief Perception
*
! bears
Communicating Sender 1
SocialMoment
PhysicalAgent
* 2..* Receiver
Communicating
{disjoint}
Agent
1..*
Commitment Institutional
Agent * InternalAgent
collective mental state), and that acts, perceives, and communicates

through them
Examples: a business unit; a voluntary association
• agent: endurant that is either a physical agent, an institutional agent or
a software agent
Note that the term agent is defined as an abstraction that subsumes physical
agents, social agents, and software agents. Since software entities are difficult
to understand ontologically (in which sense does a software entity exist in the real
world?), the category of software agents is not included in the current version
of UFO. But even if no ontological account of software agents is provided by the
foundational ontology, it may still be of great value for a software engineering
method, such as RAP/AOR, since it can help to motivate and explain the choice
of its modelling constructs and to provide guidelines on how to use a modelling
language. For instance, UFO provides an account of the meaning of roles on the
basis of its distinction between role type and base type (see the following). Role
modelling is an important issue in all agent-oriented modelling methods.
TEAM LinG
There are two basic types of AOR models: external and internal models. An
external AOR model adopts the perspective of an external observer who is
looking at the (prototypical) agents and their interactions in the problem domain
under consideration. In an internal AOR model, we adopt the internal (first-
person) view of a particular agent to be modelled. While a (business) domain
model corresponds to an external model, a design model (for a specific agentified
information system) corresponds to an internal model that can be derived from
the external one.
Figure 3 shows the most important elements of external AOR mental state
structure modelling. In order to restore compatibility with the diagram notation
of UML 2.0 (OMG, 2003b), the graphical shape for an agent type has been
changed in this chapter from a round-cornered rectangle, which has been used
previously but which is now the UML symbol for an action/activity, to the shape
shown in Figure 3 (see also the agent types Buyer and Seller in Figure 4). In
AORML, we have overloaded this shape, which stands for a “subsystem” in
UML 2.0 (OMG, 2003b), with different semantics by using it as a graphical
symbol for the <<AgentType>> stereotype of the base class Class of UML. In
other words, an agent type is viewed as a UML class instead of a “subsystem.”
An external AOR diagram, as represented in Figure 3, depicts the agent types
and instances (if applicable) of a problem domain, together with their internal
agent types and instances, their beliefs about objects and external agents, and the
relationships among agents and/or objects.
As has been shown by Wagner (2003b), mental state structure modelling in
AORML can be defined as a UML Profile, that is, it is a conservative extension
of UML class modelling.
Figure 3. The core mental state structure modelling elements of external

AOR diagrams
sends
Message Type
Agent
Type
External
Object Type receives
Internal Non-Communicative
does Action Event Type
Object Type
Commitment/Claim
Type
perceives
Action Event Type
Non-Action
perceives Event Type
TEAM LinG
According to Figure 3, the graphical notation of AORML distinguishes between

an action event type and a non-action event type and between a communica-
tive action event (or message) type and a non-communicative action event type.
Figure 3 also reflects that a commitment/claim type is coupled with the action
event type whose instance fulfills the corresponding commitment (or satisfies the
claim). Please note that for the sake of simplicity, in AORML, a communicative
action event is identified with a message while in the UFO-C ontology depicted
in Figure 1 they form different categories.
The most important behaviour modelling elements of AORML are reaction
rules, which are used to express interaction patterns. In symbolic form, a
reaction rule is defined as a quadruple ε, C → α, P where ε denotes an event
term (the triggering event), C denotes a logical formula (the mental state
condition), α denotes an action term (the triggered action), and P denotes a
logical formula (specifying the mental effect or post-condition).
As is shown in the legend of Figure 4, a reaction rule is visualized as a circle with
incoming and outgoing arrows drawn within the agent rectangle whose reaction
pattern it represents. Each reaction rule has exactly one incoming arrow with a
solid arrowhead that specifies the triggering event type. In addition, there may
be ordinary incoming arrows representing mental state conditions (referring to
corresponding instances of other entity types). There are two kinds of outgoing
arrows: one for specifying mental effects (changing beliefs and/or commit-
ments) and one for specifying the performance of (physical and communicative)
actions. An outgoing arrow with a double arrowhead denotes a mental effect. An
outgoing connector to an action event type denotes the performance of an action
of that type.
As an example, Figure 4 shows an interaction pattern diagram that specifies
the reaction rule R1 for a Seller’s behaviour in response to perceiving a
communicative action event of the type request PurchaseOrder. Both the mental
state condition and mental effect of the reaction rule are presented as expres-
sions in the Object Constraint Language (OCL) of UML 2.0 (OMG, 2003b)
attached to the corresponding arrows. The pre-condition for providing the Buyer
with the requested product is the availability of the ProductItem whose checking
in the internal database of the Seller is specified with the help of the correspond-
ing status predicate isAvailable and the OCL expression productID =
globalProductIdentifier. The post-condition representing the mental effect is
expressed as inventory = inventory@pre - requestedQuantity. The post-condition
affects the representation of the corresponding ProductItem in the Seller’s
internal database by decreasing its attribute inventory by the value of the attribute
requestedQuantity of the message received.
TEAM LinG
UFO distinguishes between different kinds of entity types as shown in Figure 2.

These distinctions are defined as follows:
• sortal type: type that provides an identity criterion for determining if two
instances are the same
Examples: Person; Student; City
• mixin type: type that is not a sortal type and can be partitioned into disjoint
subtypes, which are sortal types with different identity criteria
Examples: Agent; Customer; Product
• base type: sortal type that is rigid (all its instances are necessarily its
instances)
Examples: Mountain; Person
• phase type: sortal type that is anti-rigid (its instances could also not be
instances of it without losing their identity) and that is an element of a
subtype partition of a base type
Examples: Town and Metropolis are phase subtypes of City; Baby,
Teenager and Adult are phase subtypes of Person
• role type: sortal type that is anti-rigid and for which there is a relation-
ship type such that it is the subtype of a base type formed by all instances
participating in the relationship type
Examples: DestinationCity as a role subtype of City; Student as a role
subtype of Person
We understand a mixin type as a union of other types that does not have a uniform
identity criterion for all its instances. Many mixin types are role mixin types, that
is, mixin types that can be partitioned into role subtypes. For instance, Customer
is a role mixin type: it can be partitioned into PersonalCustomer and
CorporateCustomer, both of which are role subtypes (of Person and Corpora-
tion, respectively).
Note that an actor (more precisely, actor type) is an agent role type. For
instance, the actor type CEO is a role subtype of the base type Person. In many
cases, an actor type is an agent role mixin type. For instance, the actor type
BookingClerk can be partitioned into HumanBookingClerk (being a role subclass
of Person) and SoftwareAgentBookingClerk (being a role subclass of
SoftwareAgent).
In the RAP/AOR methodology, we view the autonomy of an agent as a relative
rather than an absolute characteristic. An institutional agent consisting of
internal agents is thus autonomous in relation to other institutional agents, at least
TEAM LinG
Figure 2. Different kinds of types in UFO-A
Entity
Type
{disjoint}
SortalType MixinType
{disjoint}
BaseType RoleType PhaseType
to some degree. The autonomy of an internal agent is even not always desired
in systems of the kind this methodology targets. For example, an autonomous
agent could reject commitments arising from its duties, which is something we
would not want for a communicating internal agent (e.g., a software agent)
forming a part of an institutional agent (e.g., a company). However, we may
allow that an internal agent makes its own prioritization decisions, which could
also be viewed as a kind of autonomy.
The AOR Modelling Language
AORML is used as the main graphical description for work products of RAP/
AOR. We thus describe it first as a prelude to our use of it in the methodology
itself.
AORML is based on an ontological distinction between active and passive
entities, that is, between agents and (non-agentive) objects of the real world. The
agent metaphor subsumes artificial (software and robotic), natural (human and
animal), and social/institutional agents (groups, organizations, etc.).
In AORML, an entity is an agent, an event, an action, a claim, a commitment, or
an ordinary object. Only agents can communicate, perceive, act, make commit-
ments, and satisfy claims. Objects are passive entities with no such capabilities.
In addition to human and artificial agents, AORML also includes the concept of
institutional agents, which are composed of a number of other agents that act
on their behalf. Organizations and organizational units are important examples of
institutional agents.
TEAM LinG
Figure 4. An interaction pattern: when receiving a PurchaseOrder, the Seller

provides the Buyer with a product according to the PurchaseOrder if there are
products available.
Buyer Seller
inventory =
request PurchaseOrder inventory@ pre -
R1 requestedQuantity
globalProductIdentifier productID =
requestedQuantity globalProductIdentifier
provideProduct
(PurchaseOrder)
Product
Item
productID
outgoing inventory
message
action isAvailable
triggering
RR
mental event
effect mental
state
condition
The RAP/AOR Viewpoint Modelling Framework
The RAP/AOR viewpoint modelling framework described in Table 1 is based on

the perspectives of agent-oriented business modelling proposed by Taveter
(2004a) which is, in turn, rooted in the ideas of the Zachman framework (Sowa
& Zachman, 1992). The RAP/AOR viewpoint modelling framework is also well-
aligned with the MDA (http://www.omg.org/mda/) framework of OMG. It
consists of a matrix with three rows representing different abstraction levels and
three columns representing the viewpoint aspects interaction, information, and
behaviour. Each cell in this matrix represents a specific viewpoint, such as
Conceptual Interaction Modelling, Computational Information Design, or
Behaviour Implementation.
In the literature, the concept of viewpoints has been used differently in different
approaches. For example, the MDA defines only three viewpoints: computation-
independent modelling (CIM), platform-independent modelling (PIM), and plat-
form-specific modelling (PSM). We consider these viewpoints as viewpoint
dimensions and call them abstraction levels. Another approach, the Reference
Model for Open Distributed Processing (RM-ODP) (Putnam & Boehm, 2001)
defines five viewpoints. The correspondences between the MDA and RM-ODP
viewpoints and the Zachman and the RAP/AOR viewpoint modelling frame-
works are summarized in Table 2.
TEAM LinG
Table 1. The RAP/AOR viewpoint modelling framework

Viewpoint models Viewpoint aspect
Abstraction level Interaction Information Behaviour
Conceptual AOR Agent Diagrams, UML Use AOR Agent AOR Interaction Pattern
Domain Modelling Case Diagrams, AOR Interaction Diagrams Diagrams, Goal-Based
Frame Diagrams, AOR Interaction Use Case Models,
Sequence Diagrams AOR Activity Diagrams
Platform- UML Use Case Diagrams, AOR AOR Agent AOR Reaction Pattern
Independent Reaction Frame Diagrams, User Diagrams Diagrams, AOR Internal
Computational Interface Design Models, Security Activity Diagrams, UML
Design Models, UML Class Diagrams, State Machine Diagrams
UML Interaction Diagrams
Platform-Specific UML Class UML Class Diagrams
UML Deployment Diagrams
Implementation Diagrams
Table 2. RAP/AOR stakeholders and the corresponding viewpoint names in

other frameworks
Abstraction level Audience/Stakeholders Viewpoint Names

MDA RM-ODP Zachman
Conceptual owners/customers, users, domain CIM Enterprise Rows 1+2
Domain Modelling experts
Computational systems analysts, software PIM Information + Row 3
Design architects Computational
Implementation programmers, database PSM Engineering + Rows 4+5
implementers, system integrators Technology
Normally, in a software engineering project, one or more views are created for
each viewpoint, using the respective modelling language(s). A view is a diagram
or a model of another kind, like a tabular use case or a textual description. Thus,
a viewpoint-modelling framework defines the collection of engineering docu-
ments created and used in a software engineering project. In the following, we
briefly describe different viewpoints of the framework
Domain-Interaction Viewpoint
The domain-interaction viewpoint (Column 1 in Table 1) concerns the analysis

and modelling of active entities, that is, of agent types and instances and
relationships, as well as the interactions and communication between them.
The domain-interaction viewpoint comprises organization modelling. The pur-
poses of organization modelling are to identify:
TEAM LinG
a. the organization(s) of the problem domain;

b. the relevant organizational units of which each organization to be modelled
consists;
c. the roles3 included by the organizational units; and
d. the types of relationships occurring between these agent types.
According to Zambonelli, Jennings, and Wooldridge (2001), among the five types
of relationships that can be identified between institutional agent types and/or
role types, control, benevolence, and dependency relationships are the most
relevant ones to modelling interactions between agents. Control relationships
identify the authority structures within an organization. Benevolence relation-
ships identify agents with shared interests. Dependency relationships exist
between agents because of resource restrictions where the depender depends
on the dependee for the availability of a physical or an informational resource.
For example, in Figure 5 there is the isBenevolentTo relationship between
instances of the role types Seller and Buyer.
The domain-interaction viewpoint is described with the help of four views:
1. AOR Agent Diagrams;

2. UML Use Case Diagrams;
3. AOR Interaction Frame Diagrams; and
4. AOR Interaction Sequence Diagrams.
Types of organizational units and roles can be represented by AOR agent

diagrams where different agent types may relate to each other through the
relationships of generalization and aggregation. An AOR agent diagram
depicts the agents and agent types of a problem domain, together with their
internal agents and agent types and the relationships among them. An agent
diagram, like the one shown in Figure 5, includes all agent (role) types of a
business domain. An important purpose of an agent diagram is to describe all
stakeholders that are involved in the business processes to be supported by the
socio-technical business system and to give an overview of the business system
viewed as a multi-agent system.
A use case is defined as the specification of a sequence of actions, including
variants, that a system (or other entity) can perform, interacting with actors of
the system (OMG, 2003b). Since the system is itself an actor 4 (Cockburn,
1997a), the model of interaction between an “actor” and a “system” of a use case
can also be applied in agent-oriented modelling. A UML use-case diagram, for
example, the diagram represented in Figure 6, thus shows the relationships
TEAM LinG
commerce
Buyer 1 Seller
0..*
PurchaseOrder/Confirmation RFQ/Quote
Clerk Clerk
requestedResponseDate
ProductLineItem
QuoteLineItem
requestedQuantity <<isBenevolentTo>>
Software Software
requestedUnitPrice 0..* 1 1 0..* isSubstituteProductAcceptable
Agent Agent
globalProductUnitOfMeasureCode requestedQuantity
globalProductIdentifier globalProductUnitOfMeasureCode
shippedQuantity globalProductIdentifier

unitPrice unitPrice
Seller
Substitute 1 Substitute
0..*
Product
ProductReference Invoice ProductReference
Item
ProductItem
globalProductSubstitution- 1 0..* billToAccount 0..* 1 globalProductSubstitution-
OfSeller ReasonCode
ReasonCode globalPaymentTermsCode
globalProductIdentifier totalInvoiceAmount globalProductIdentifier
1
1 1 InvoiceLineItem
ProductLineItem QuoteLineItem
totalLineItemAmount
StatusCode StatusCode
isAccept isBid
isReject isNoBid
0..*
isPending isPending
Towards Radical Agent-Oriented Software Engineering Processes
Figure 5. The agent diagram of the domain of business-to-business electronic
291
TEAM LinG
Figure 6. A use case diagram showing the types of interactions between

agents of the types Buyer and Seller
Seller
Quote
Order
Buyer Pay
Figure 7. The interaction frame between agents of the types Buyer and Seller
Buyer Seller
request
RFQ/Quote
inform
RFQ/Quote
request
PurchaseOrder/
Confirmation
inform
PurchaseOrder/
Confirmation
provideProduct
(PurchaseOrder)
provideProduct
(PurchaseOrder)
request
Invoice
payForProduct
(Invoice)
payForProduct
(Invoice)
TEAM LinG
among two actors which are respectively an initiator and a responder in

interactions. The use cases represented in the domain interaction viewpoint are
business use cases (Cockburn, 2001), because they summarize the types of
interactions between a customer, which can be a human agent or an institutional
agent, and the business, which is an institutional agent.
According to Wagner (2003a), an AOR interaction-frame diagram provides a
static picture of the possible interactions between two (types of) agents without
modelling any specific process instance. An interaction-frame diagram de-
scribes in more detail the types of interactions summarized by the corresponding
use case. An interaction-frame diagram, like the one represented in Figure 7,
consists of various types of communicative action events, non-communicative
action events, commitments/claims (coupled with the corresponding types of
action events), and non-action events. Agents of the problem domain share the
entity types mentioned.
An AOR interaction-sequence diagram, like the one shown in Figure 8, depicts
(some part of) a prototypical instance of an interaction process. An interaction
Figure 8. An interaction sequence between the agent instances BuyerA and

SellerB
BuyerA SellerB
1
request RFQ/Quote
globalProductIdentifier =
"1247"
2
inform
RFQ/Quote
3
request
PurchaseOrder/
Confirmation
4
inform
PurchaseOrder/
Confirmation
5
provideProduct
(PurchaseOrder)
6
request
Invoice
7
payForProduct
(Invoice)
TEAM LinG
process is a sequence of action events and non-action events, performed and

perceived by agents and following a set of rules (or protocol) that specifies the
type of the interaction process. Agents may interact with their inanimate
environment or they may interact with each other.
Domain-Information Viewpoint
Representing the domain-information viewpoint (Column 2 in Table 1) for the

focus organization(s) can be regarded as creating a domain ontology that
provides a common framework of knowledge for the agents of the organization(s)
and external agents connected to the organization(s). Each agent of the problem
domain can see only a part of the ontology; that is, each agent views the ontology
from a specific perspective.
The domain-information viewpoint is described with the help of one view—AOR
Agent Diagrams.
In addition to describing agent types, an AOR agent diagram, like the one
represented in Figure 5, describes object types of the problem domain, as well
as their relationships to agent types and with each other. Each agent has beliefs
about its internal agents, about its “private” objects, and about all external agents
and shared objects that are related to it.
Domain-Behaviour Viewpoint
The domain-behaviour viewpoint (Column 3 in Table 1) addresses the modelling

of an agent’s functionality (what functions the agent has to perform), as well as
of the agent’s behaviour (when, how, and under what conditions work has to be
done). In the models of the domain-behaviour viewpoint, a modeller may abstract
away from particular internal agent types, like SoftwareAgent in Figure 5, and
create models of behaviour for the corresponding institutional agent types, like
Buyer and Seller in Figure 5. The domain-behaviour viewpoint is described with
the help of three views:
1. AOR Interaction-Pattern Diagrams;

2. Goal-Based Use Case Models; and
3. AOR Activity Diagrams.
AOR interaction-pattern diagrams, like the one depicted in Figure 4, focus on

general interaction patterns expressed by means of a set of reaction rules
defining an interaction process type. In an interaction-pattern diagram, the
TEAM LinG
actions performed by one agent may be, at the same time, the events perceived
by another agent. Figure 4 demonstrates that an interaction-pattern diagram can
visualize the reaction chains that arise by one reaction triggering another.
However, for adequate modelling of business processes, interaction-pattern
diagrams are not sufficient because they do not allow modelling of action
sequences. For this reason, we will introduce activities as a glue to connect the
actions of an agent within a business process to each other.
Actor types (or agent role types) are always characterized by goals because,
as noted by Kueng and Kawalek (1997, p. 19), “human activity is inherently
purposeful.” In a business domain, a human or an institutional agent acting in the
role of a “customer” has a goal of having something accomplished. To achieve
its goal, the agent uses some service provided by another agent. An agent’s
autonomy implied by a benevolence relationship between the service provider
and a service requester means that the service provider performs the service
requested if it is able to do so, but the service provider also has an option to
refuse the service request. Even though the agent requesting the service may
not explicitly communicate its goals to the service provider agent, the latter
always “internalizes” the whole or a part of the customer’s goal in an attempt to
provide the service. For example, assuming that a customer has a goal of renting
a car, the goal of a car rental company is to provide the customer with a car,
which is, of course, a subgoal of the company’s higher level goal—to earn money
through renting cars. The car rental company tries to achieve this higher level
goal by “internalizing” as many customer goals as possible.
The “internalizations” of the goals of customers by service providers can be
modelled in different ways. For example, in the i* framework proposed by Yu
(1995), a customer’s goal can be captured by representing a goal dependency
where a depender (i.e., a customer) depends on the dependee (i.e., a service
provider) to bring about a certain state in the world. In the same framework,
setting and achieving of the corresponding internal goal by the dependee can be
modelled through a means-ends link, indicating a relationship between an
internal goal to be achieved and a means for attaining it, which is usually
performing a task (activity). As another example, in the KAOS framework
described by Lamsweerde (2003), goals of agents are “operationalized” into
specifications of services to be performed by an agent.
In our approach, we capture the goals of “customers” and their “internalizations”
by service providers by employing goal-based use case models. Use cases as
such were originally introduced by Jacobson (1992). Cockburn (1997a, 1997b)
proposed an extended version of use cases that he calls “use cases with goals.”
He elaborated goal-based use cases in Cockburn (2001). While a graphical UML
use-case diagram in the domain-interaction viewpoint summarizes types of
interactions between an external actor and the focus agent (the “system”), a
tabular goal-based use case models the behaviour of the focus agent.
TEAM LinG
Table 3. A goal-based use case for the business process type “Process the
request for a quote”
USE CASE 1 Process the request for a quote.

Goal of the To receive from the seller the quote.
Primary Actor
Goal of the Focus To provide the buyer with the quote.
Actor
Scope & Level Seller, primary task.
Success End The buyer has received from the seller the quote.
Condition
Primary Actor Buyer.
Secondary Actors
Triggering event A request for a quote by the buyer.
DESCRIPTION Step Action
1 Check and register the availability of the product items included in the
request for a quote.
2 Send the quote to the buyer.
A goal-based use case, such as the use case represented in Table 3, consists of
a primary actor, the system under discussion, and a secondary actor. We will
call the system under discussion the actor in focus. In the domain-behaviour
viewpoint, where use cases describe the types of an organization’s business
processes, the actor in focus is the organization itself or an organization unit.
According to Cockburn (2001), the external primary actors are the actors
whose goals the organization is to satisfy. They include the company’s customers
and perhaps their suppliers. The external primary actors form a part of the
company’s stakeholders that includes the company shareholders, customers,
vendors, and government regulatory agencies. A secondary or a supporting
actor is an external actor that provides a service to the agent in focus, so that
the latter could achieve its goals. In parallel with the identification of primary
actors, the triggering events created by them to which the organization must
respond should be identified (Cockburn, 2001).
Internal and external actors in goal-based use cases straightforwardly corre-
spond to internal and external agents in AOR modelling. According to Cockburn
(1997a), each actor has a set of responsibilities that have been assigned to it
by external authorities. To carry out those responsibilities, it sets some goals. An
agent’s responsibility is realized as an activity that the agent performs in
response to perceiving an event of the corresponding type. The relationship
between an agent’s responsibilities, goals, and activities is illustrated by the
RAP/AOR metamodel fragment shown in Figure 9.
An activity is defined using workflow terminology as an uninterruptible amount
of work that is performed in a non-zero span of time by an actor (Eshuis, Jansen,
TEAM LinG
Figure 9. The relationship between an agent’s responsibilities, goals and

activities
1
0..* 1 has>
Event <perceives Agent 1
1..* 2 1
triggers> <raises includes> has>
1 0..* 0..* 0..*

1
Reaction 0..* Agent 1 <implies 1
starts> Activity Responsibility
Rule 1 0..1 has> Goal
1 1
1 1
<is realized as
& Wieringa, 2002). Each activity belongs to some activity type. An activity type
(or task in Yu [1995]), like “Manage quoting,” is defined as a prototypical job
function in an organization that specifies a particular way of doing something
(Yu, 1995). It seems natural to allow specifying the start of an activity in the
action part of a reaction rule. In other words, an instance of an activity type is
created by means of a reaction rule in response to perceiving an event, which is
also reflected by the RAP/AOR metamodel fragment represented in Figure 9.
We define an AOR activity diagram, like the one shown in Figure 10, by making
the definition provided in UML 2.0 (OMG, 2003b) slightly more precise as a
Figure 10. An incomplete model of the quoting business process type from
the perspective of Seller
Buyer Seller
request
R1
RFQ/Quote
Manage quoting
(q : Quote)
Process product item s q.quoteLineItem .forAll->

(q : Quote) (quoteLineItem StatusC ode.isBid or
quoteLineItem StatusCode.isNoBid)
Confirm quote
inform (q : Quote)
RFQ/Quote
TEAM LinG
specification of parameterized behaviour that is expressed as a flow of execution

via a sequencing of subordinate activities whose primitive elements are individual
epistemic, physical, and communicative actions. As Figure 9 reflects, there are
two activity border events (start-of-activity and end-of-activity) implicitly
associated with the beginning and end of each activity. An activity border event
starts either a subactivity or a subsequent activity or triggers a reaction rule. The
start-of-activity event type is graphically represented by an empty circle with
the outgoing arrow to the symbol of the subactivity type or internal reaction rule.
The end-of-activity event type is visualized by drawing a triggering arrow from
the activity-type symbol to either the symbol of the next activity type or to the
symbol of the reaction rule triggered by an activity of the corresponding type.
The goal tied to an activity is defined as a condition or state of affairs in the world
that the agent would like to achieve (Yu, 1995). When a goal-based use case is
transformed into an activity diagram, the goal of the focus actor of the use case
is attached to the diagram’s outermost activity. The pre-condition of an activity
is a necessary condition that must be true when the activity is started. Pre-
conditions and goals may refer to status or intensional predicates of entity types.
They are defined for activity types by means of OCL.
Viewpoints of Design
As explained in section “The AOR Modelling Language,” an interacting system

(or agent), as a subject in its domain, does not have an objective but rather a
subjective view of the domain. This is reflected in RAP/AOR by a computa-
tional-design model, in which the internal (subjective) perspective of the system
to be built is adopted, in contrast to the external (objective) perspective adopted
in a conceptual domain model. For instance, in the transformation of a domain-
information model into an information-design model for a specific agent, the
objective term action event is mapped onto the two indexical subjective terms,
action (if performed by the agent under consideration) and event (if performed
by other agents). Likewise, the objective term message is mapped onto the two
subjective terms, incoming message and outgoing message. This mapping is
also called internalization in RAP/AOR.
External models of the conceptual domain modelling level are thus transformed
into internal models of the level of platform-independent computational design.
In particular, AOR agent diagrams are refined into more detailed agent diagrams
and business use cases are turned to system use cases. Analogously, AOR
interaction-frame diagrams are mapped to reaction-frame diagrams, AOR
interaction-pattern diagrams to reaction-pattern diagrams, and AOR activity
diagrams to internal activity diagrams.
TEAM LinG
The Role of Simulation in the RAP/AOR Methodology
We have shown in Wagner and Tulba (2003) that, with some minor extensions,
AOR models can be used for a certain form of agent-based discrete event
simulation called Agent-Object-Relationship Simulation (AORS). In RAP/
AOR, we employ AORS for achieving more agility in the software engineering
process by getting feedback from the execution of models before they are
implemented in a target technology platform.
AORS allows animating and testing both AOR domain-interaction and -behaviour
models and AOR interaction and behaviour design models.
As has been shown in Taveter (2004a), simulation of behaviour models is
facilitated by the executability of complete and incomplete AOR activity
diagrams. An AORS system, for example, the implementation described in Luin,
Tulba, and Wagner (2004), includes an environment simulator that is responsible
for simulating exogenous events and the causality laws of the physical environ-
ment. Other actors of the problem domain can be simulated with various degrees
of realism.
The Core Disciplines of the RAP/AOR Methodology
The seven core software engineering disciplines of RAP/AOR, based on those

of RUP, are:
1. Domain modelling;
2. Requirements engineering;
3. Design;
4. Simulation;
5. Implementation;
6. Test; and
7. Deployment.
The first three disciplines listed above can be represented as the following task
sequence divided between different viewpoints:
1. Domain-interaction viewpoint:
1.1. Model agent types and instances of the problem domain and relation-
ships between them by using an AOR agent diagram.
TEAM LinG
1.2. Model possible interaction types between agents of the problem

domain by UML use cases.
1.3. Refine possible interaction types between agents of the problem
domain by AOR interaction-frame diagrams.
1.4. Model prototypical interaction processes of the problem domain by
AOR interaction-sequence diagrams.
2. Domain-behaviour viewpoint:
2.1. Model the behaviours of agents of the problem domain by goal-based
use cases.
2.2. Model the behaviours of agents of the problem domain by AOR
reaction-pattern diagrams (optional).
2.3. Transform goal-based use cases into AOR activity diagrams.
2.4. Refine AOR activity diagrams by more detailed behavioural con-
structs.
2.5. Complement goal-based use cases by the elements corresponding to
the behavioural constructs introduced.
3. Domain information viewpoint:
3.1. Model object types and instances of the problem domain and relation-
ships between them by using an AOR agent diagram.
4. Design interaction, behaviour, and information viewpoints:
4.1. Turn AOR interaction-frame diagrams into AOR-reaction frame
diagrams.
4.2. When needed, complement AOR-reaction frame diagrams with user-
interface design models and security models.
4.3. Turn AOR-interaction pattern diagrams into AOR reaction-pattern
diagrams (optional).
4.4. Turn AOR activity diagrams into internal AOR activity diagrams.
4.5. Refine AOR agent diagrams of the conceptual domain-modelling
level into AOR agent diagrams of the computational-design level.
In large development projects, there will be a team for each of the seven
disciplines stated above.
The Phases of a RAP/AOR Development Project
Jacobson, et al. (1999) and Kruchten (1999) have pointed out that a software
development project has two dimensions: the temporal sequence of project
TEAM LinG
Table 4. Project phases with predominant software engineering disciplines
Project Phase Predominant Disciplines

Inception domain modelling & requirements engineering
Elaboration design & simulation
Construction implementation & test
Transition deployment
phases, and the composition of the overall development process of analysis,

design, simulation, implementation, and test activities carried out iteratively in
each phase. In RAP/AOR, we follow the distinction between four project
phases: inception, elaboration, construction, and transition, each of which
has one or two predominant software engineering disciplines according to Table
4. An important topic of our future work is aligning the phases of the RAP/AOR
development project with the Software Process Engineering Metamodel Speci-
fication (SPEM, 2002) so that a phase would be a specialization of WorkDefinition
such that its precondition defines the phase entry criteria and its goal defines the
phase exit criteria.
Case Study
Our case study is about the business process type of quoting in business-to-
business electronic commerce that is based on the RosettaNet standard (http:/
/www.rosettanet.org/). The RosettaNet’s “Request Quote” Partner Interface
Process® (PIP) enables a buyer to request a product quote from a provider and
a provider to respond with a quote. The prices and product availability reflected
in a quote may be influenced by an existing or potential relationship between a
buyer and provider. We now discuss the conceptual modelling of this problem
domain in terms of the RAP/AOR viewpoint modelling framework. We also
briefly address the computational design of a business-to-business process
automation system for the problem domain.
The Interaction Aspect
At the level of conceptual domain modelling (Row 1 in Table 1), the interaction
aspect (Column 1 in Table 1) is captured by conceptual AOR- interaction
models that are represented by using the following views: AOR agent diagrams,
TEAM LinG
UML use-case diagrams, AOR interaction-frame diagrams, and AOR interac-

tion-sequence diagrams.
At the level of computational design (Row 2 in Table 1), the interaction aspect
is captured by AOR reaction-frame diagrams.
The agent diagram of Figure 5 represents the agent role types Buyer and Seller
of the case study, with their respective internal agent types Clerk and SoftwareAgent.
For simplicity, other relevant agent types like Bank have been omitted in the
figure. There is the isBenevolentTo relationship between instances of the role
types Seller and Buyer in Figure 5. This relationship typically appears between a
service provider and requester.
A use-case diagram as depicted in Figure 6 summarizes the types of interactions
between two agents of the type Buyer and Seller, which act as a service requester
and provider, respectively. Interactions between a service requester and pro-
vider are further refined in the interaction-frame diagram in Figure 7, which
covers the business process types of quoting, ordering, and invoicing between
instances of the agent role types Buyer and Seller The interaction frame
represented in Figure 7 contains types of communicative action events (mes-
sages) such as request PurchaseOrder/Confirmation, which is used for ordering,
non-communicative action event types like provideProduct, and types of commit-
ments/claims coupled with them. Each communicative action event type is
prefixed by one of two functions of message types5: request, by which a sender
requests the receiver to perform a communicative or physical action or both, and
inform, which identifies a communicative action performed in reply to a request
or independently.
Interaction-frame diagrams may be complemented by interaction-sequence
diagrams, which depict prototypical instances of interaction processes. The
interaction-sequence diagram in Figure 8 represents instances of the business
process types of quoting, ordering, and invoicing between the agents BuyerA and
SellerB.
An interaction-frame diagram of the conceptual domain-modelling level can be
turned into a reaction-frame diagram of the computational-design level by the
process of internalization, which was briefly described in an earlier section,
“Viewpoints of Design.” In that process, the external AOR model is transformed
into an internal AOR model for the (type of) focus agent for which an agentified
information system is to be developed (typically an organization or an organiza-
tional unit). For example, Figure 11 represents the reaction frame created for an
instance of the agent role type Seller. This model has been obtained from the
interaction frame shown in Figure 7.
TEAM LinG
is performed to those belonging to the instance of Quote that is identified by the

value of the input parameter q. When all subactivities of the type “Process
product item” have ended, the enclosing activity of the type “Process product
items” also ends.
The subactivity “Process product item” in Figure 12 checks the availability of the
given product item that is specified by the input parameter item of the type
QuoteLineItem. If the product item corresponding to the instance of QuoteLineItem
is available in the quantity requested, the status of the QuoteLineItem is set to
isBid. In the opposite case, the status of the QuoteLineItem is changed to isNoBid.
In both cases, the attributes of the QuoteLineItem are updated accordingly.
Figure 12. The complete behaviour model of the quoting business process
type from the perspective of Seller
Buyer Seller
request
RFQ/Quote
R1 C
Manage quoting
(q : Quote)
Quote
Process product items
(q : Quote)
QuoteLineItem
QuoteLineItem
StatusCode
R2 {quote = q} isBid
isNoBid
Process product
item isPending
(item:
QuoteLineItem) U
R3 U
ProductItem
{isAvailable productID
(item.requestedQuantity) and unitPrice
productID = itemsAvailable
item.globalProductIdentifier} isAvailable
(Integer)
Clerk
R4 approveQuote
Confirm quote
(q : Quote)
inform
R5
RFQ/Quote
TEAM LinG
Figure 11. The reaction frame for an agent of the type Seller
Seller
Buyer
request
RFQ/Quote
inform
RFQ/Quote
request
PurchaseOrder/
Confirmation
inform
PurchaseOrder/
Confirmation
provideProduct
(PurchaseOrder)
provideProduct
(PurchaseOrder)
request
Invoice
payForProduct
(Invoice)
payForProduct
(Invoice)
The Information Aspect
At the level of conceptual domain modelling (Row 1 in Table 1), the information
aspect (Column 2 in Table 1) is captured by conceptual AOR information
models, which are represented by AOR agent diagrams.
The conceptual information model of the problem domain of business-to-
business electronic commerce is represented in the agent diagram in Figure 5.
The figure shows that the object types PurchaseOrder/Confirmation, RFQ/Quote,
and Invoice are shared between agents of the types Buyer and Seller, while the
TEAM LinG
object types ProductItemOfSeller and ProductItem are represented exclusively

within agents of the types Buyer and Seller, respectively. It is important to
emphasize here that a shared object type does not imply that all the agents whose
types are connected by an association to it have the same beliefs about it, or, in
other words, that there is a common extension of it shared by all agents. For
example, different instances of the agent role type Buyer in Figure 5 hold different
sets of instances of RFQ/Quote.
Instances of the object type Seller within an instance of Buyer represent
information about the corresponding instances of the agent type Seller. An object
of the type QuoteLineItem in Figure 5 satisfies one of the following status
predicates: isBid, isNoBid, and isPending, while an object of the type
ProductLineItem represented in the same figure is characterized by the status
predicate isAccept, isReject, or isPending.
At the level of computational design (Row 2 in Table 1), the information aspect
is captured by detailed AOR agent diagrams that include, for example, the types
of attributes and the identifiers for agent and object types.
The Behaviour Aspect
While the interaction aspect deals with the communication and interactions
between the agents, the behaviour aspect (Column 3 in Table 1) addresses the
agents’ reactions to the communicative and non-communicative action events
and non-action events perceived by them. At the level of conceptual modelling
(Row 1 in Table 1), the behaviour aspect is captured by the conceptual AOR
behaviour models that are represented by means of the following views: AOR
interaction-pattern diagrams, goal-based use-case models and AOR activity
diagrams.
At the level of computational design (Row 2 in Table 1), the behaviour aspect is
captured by AOR reaction-pattern diagrams and AOR internal activity dia-
grams.
Figure 4 serves as an example of an interaction-pattern diagram specifying the
reaction rule R1 for a Seller’s behaviour in response to perceiving a communi-
cative action event of the type request PurchaseOrder.
A goal-based use case can be triggered by an internal or external actor. For
example, the use case “Issue a request for a quote” with the buyer in focus is
triggered by the buyer’s internal actor “clerk,” while the use case “Process the
request for a quote” presented as an example in Table 3 is triggered by receiving
a request from a buyer for a quote. The use case (“Process the request for a
quote”) in Table 3 is modelled from the perspective of a buyer with the seller in
focus (scope), which means that the goal of the use case is the so-called user
TEAM LinG
goal, the goal of the actor (i.e., a buyer) trying to get work (primary task) done
(Cockburn, 1997a). The buyer is therefore the external primary actor of the use
case. Since the goal of the primary actor is “internalized” by the actor in focus,
unlike Cockburn, we also include the goal of the focus actor in a goal-based use
case, as is reflected by Table 3.
As shown in Taveter (2004a), a goal-based use case can be straightforwardly
turned into sequences and hierarchies of activity types whose instances are
performed by an agent. For example, an activity diagram as shown in Figure 10
corresponds to the use case represented in Table 3. In the figure, an activity of
the type “Manage quoting,” which is visualized as a roundtangle, is started by
reaction rule R1 in response to receiving a message containing a request for a
quote. As shown in Figure 10, an activity of the type “Manage quoting” consists
of sequential subactivities of the types “Process product items” and “Confirm
quote.”
For each activity type represented in Figure 10 can be defined the goal that its
instances try to achieve. The goal defined for the outermost activity type, which
is “Manage quoting” in Figure 10, corresponds to the focus actor’s goal of the
respective goal-based use case. For example, the goal of an activity of the type
“Process product items” is represented informally as “For each product item
included by the request for a quote is known whether it is to be bid or not.” This
goal can be formalized by means of OCL in terms of the input parameter declared
for the corresponding activity type, as is represented in Figure 10. Input
parameters defined for activity types represent the dataflow through the
activities.
Next, activity diagrams obtained from goal-based use cases are elaborated by
introducing into them behavioural constructs by means of reaction rules.
Taveter (2004a) has shown that AORML extended by activity modelling allows
the representation of 16 out of 19 behavioural workflow patterns as defined in
the benchmark proposal of van der Aalst, ter Hofstede, Kiepuszewski and
Barros (2003). The complete behavioural model of the quoting business process
type from the perspective of the agent role type Seller is represented in Figure
12. As the figure shows, the behavioural model shown in Figure 10 has been
complemented by the behavioural constructs of the types “For-each loop” and
“Starting an activity by means of two (or more) events.” In addition, elementary
epistemic, physical, and communicative actions that make up the activity types
“Process product item” and “Confirm quote” have been specified.
According to the behavioural construct of the type “For-each loop” represented
in Figure 12, upon the start of an activity of the type “Process product items,” its
subactivity of the type “Process product item” is performed for each instance of
the object type QuoteLineItem for which the pre-condition quote = q evaluates to
true. The pre-condition limits the set of QuoteLineItems for which the subactivity
TEAM LinG
The behavioural construct of the type “Starting an activity by means of two (or
more) events” represented in Figure 12 specifies that, upon the end of an activity
of the type “Process product items,” if the agent perceives an approval of the
quote by an internal human agent of the type Clerk, an activity of the type
“Confirm quote” is started. An activity of the given type is thus started only after
events of all the specified types have occurred. In Figure 12, such events are the
ending event of the previous activity and an approval of the quote by a human
agent instance of the type Clerk.
Since goal-based use cases also serve to document business process types
modelled by activity diagrams, in Table 5, the use case “Process the request for
Table 5. A goal-based use case for the business process type “Process the
request for a quote”
USE CASE 2 Process the request for a quote.
Goal of the To receive from the seller the quote.
Primary Actor
Goal of the Focus To provide the buyer with the quote.
Actor
Scope & Level Seller, primary task.
Success End The buyer has received from the seller the quote.
Condition
Secondary Actors
Triggering event A request for a quote by the buyer.
1 For each product item included in the request for a quote: process
product item (Use Case 3).
2 The quote has been approved by the clerk: send the quote to the buyer.
Table 6: The subfunction “Process product item”
USE CASE 3 Process product item.

Goal of the
Primary Actor
Goal of the To decide bidding of the product item.
Focus Actor
Scope & Level Seller, subfunction.
Pre-conditions
Success End The bidding of the product item has been decided.
Condition
Secondary Actors
Trigger
1 The product item is available in the quantity requested: the product
item is to be bid which is registered in the quote.
EXTENSIONS Step Branching Action
1a The product item is not available in the quantity requested: the product
item is not to be bid which is registered in the quote.
TEAM LinG
a quote,” which was originally represented in Table 3, has been complemented

by the <condition> elements corresponding to the behavioural constructs
introduced. Please note that a subfunction6 of the primary task “Process the
request for a quote” presented in Table 6 contains the main (success) scenario
(Cockburn, 2001), and one extension scenario (Cockburn, 2001) that starts by
stating where it picks up in the main scenario and what conditions are different.
Simulation
Taveter (2004a) demonstrated that AORML extended by activities is the first

agent-oriented modelling language where partially specified behaviour models
by activity diagrams can be executed. For example, in our case study, both an
incomplete conceptual AOR behaviour model of the quoting business process
type represented in Figure 10 and the complete behaviour model represented in
Figure 12 can be executed. This facilitates iterative business modelling that is the
state-of-the-practice. Using executable process models jointly with an Agent-
Object-Relationship Simulation (AORS) system, as described in Wagner and
Tulba (2003), permits the creation of powerful simulation environments. For this
purpose, as well as for the creation of actual agentified information systems, the
approach of transforming models into implementations described in the “Imple-
mentation and Tools” section can be employed.
Implementation and Tools

The RAP/AOR methodology complies with the principles of the MDA frame-
work of OMG (http://www.omg.org/mda/). According to the overview of MDA
provided in Klasse Objecten (http://www.klasse.nl/english/mda/mda-
introduction.html), the MDA process defines three steps:
1. First, a model at a high level of abstraction that is independent of any

implementation technology is built. This is called a Platform Independent
Model (PIM). In the RAP/AOR methodology, the models listed in Row 2
of Table 1 form the PIM.
2. Next, the PIM is transformed into one or more Platform Specific Models
(PSM). A PSM is tailored to specify the PIM in terms of the implementation
constructs that are available in one specific implementation technology. In
the RAP/AOR methodology, the PSM can be respresented by the models
listed in Row 3 of Table 1.
TEAM LinG
3. The final step is to transform a PSM to code. Because a PSM fits its
technology very closely, this transformation is rather trivial. The complex
step is the one in which a PIM is transformed into a PSM.
In principle, the transformation from a PIM into a PSM can be performed for
each software system to be built (e.g., an agentified information system)
separately. However, in the RAP/AOR methodology, we advocate an approach
where executable AOR models are transformed into equivalent XML-based
representations that are then interpreted and executed by software agents. In the
case study of automating business-to-business processes, which we described
in our case study, this is crucial because new business process types emerge and
old ones frequently change, as a result of which specifications of business
process automation systems are in constant flux.
In order to facilitate generation of XML-based representations of business
process models, we have developed the corresponding XML Schema (http://
www.w3.org/XML/Schema) whose instances describe business process types
in a machine-interpretable way. By using the schema, it is possible to represent
business process types from different perspectives. For example, the models of
the quoting business process type created in our case study are transformed into
two XML-based representations that describe the quoting business process type
from the perspectives of the agent role types Seller and Buyer.
Figure 13. The business process automation system

Model
business
process Integrated
type Business Process
in the Editor
User User extended
AORML (CONE)
Maintainer
business process
Description of
type in XML
Interact Interact
with agent with agent
Instantiate
ACL
business Business Process
process type (...)
message Interpreter
JADE JADE Interpret Representations of
agent agent business process business process
ACL
Invoke agent types
message
CRM ERP EAI

System System System
TEAM LinG
The Integrated Business Process Editor allows graphical descriptions of busi-

ness process types expressed in AORML to be transformed into their represen-
tations in XML. Even though the XML-based representations of a business
process type are generated automatically, as a rule, some manual tailoring of
process-specific interfaces must be performed. This occurs between the
Business Process Interpreter and enterprise systems of the company. Enterprise
systems can include the Enterprise Resource Planning (ERP), Customer Rela-
tionship Management (CRM), and Enterprise Application Integration (EAI)
systems shown in Figure 13. After the generation and tailoring have been
accomplished, a business process type is ready to be interpreted by the Business
Process Interpreter, which works in cooperation with the software agent
representing the corresponding party. The latter has been implemented using the
Java Agent DEvelopment Framework (JADE) (http://jade.cselt.it/) agent plat-
form. Agents communicate with each other using messages in the Agent
Communication Language (ACL) defined by FIPA (http://www.fipa.org/),
which is based on speech acts (Austin, 1962). As Figure 13 illustrates, an agent
representing a party first invokes the Business Process Interpreter to read the
description of the business process type, as requested by the agent’s human user,
and to create its internal representation of the business process type. Thereafter,
when the agent receives a message or “perceives” an input by a human user
through the Graphical User Interface (GUI), the agent invokes the Business
Process Interpreter to act according to the process type description. When the
Business Process Interpreter acts, it, in turn, invokes the JADE agent and
displays messages through the agent’s GUI.
Strength and Weakness of the

RAP/AOR Methodology
At present, it is difficult to evaluate the RAP/AOR methodology, mainly because
some of its components—in particular, certain model transformations and
related tools—have not yet been fully developed. Consequently, a lack of tool
support and field testing reports is a weakness of the proposed methodology at
the time of writing this chapter. On the other hand, the experience gained in the
case study discussed and in implementing the tool support discussed in “Imple-
mentation and Tools” section have been encouraging and lead us to believe that
RAP/AOR is a natural extension of RUP+UML offering higher level modelling
constructs.
TEAM LinG
In the prototype application represented in Figure 13, inter-organizational

business process types are described in the (extended by activities) AORML by
means of the Integrated Business Process Editor. The latter has been developed
as an extension to the COnceptual Network (CONE) Ontology Editor of VTT
Information Technology. Figure 14 shows a snapshot of the model of the
RosettaNet-based quoting business process type that has been created by using
the editor from the perspective of Seller. Please note that since the older version
of AORML was originally defined on the basis of UML 1.5 (OMG, 2003a),
Figure 14 uses the old graphical notations for agents and activities in AORML.
Note also that the models represented in Figure 14 are external AOR models—
the process of internalization briefly described in section, “Viewpoints of
Design,” is performed implicitly when subjective XML-representations are
generated from an objective model of a business process type. In other words,
due to the implicit internalization, CIM serves as the starting point instead of
PIM.
Figure 14. The quoting business process type from the perspective of Seller
modelled by the Integrated Business Process Editor
TEAM LinG
Not supporting the design of proactive behaviour may be seen either as a

weakness or as a strength. It is certainly a weakness from an AI point of view;
however, we consider it to be a strength since the agents we want to design as
components of large-scale cross-enterprise distributed information systems do
not need proactive behaviour, nor do they need any other form of sophisticated
human-like intelligence. Rather, such agents typically have a complicated
structure of beliefs and commitments and a reactive behaviour based on them,
both of which can be captured by the RAP/AOR methodology.
Two particular strengths of the proposed methodology are its ontological
foundation and its use of simulation for achieving more agility. Another strength
is the possibility to represent the models of the interaction, information, and
behaviour viewpoint aspects in just one integrated diagram. This overcomes the
model multiplicity problem (Peleg & Dori, 2000), which is that, to understand
the system being studied and the way it operates and changes over time, the
reader must concurrently refer to various models.
An important open issue for RAP/AOR is the potential for an operational
commitment concept for designing and controlling business-to-business interac-
tions. The basic assumption of AOR modelling that, in addition to beliefs and
perceptions, commitments are the third mental state component that is important
for understanding and designing agent-to-agent interactions, has not yet been
validated in novel technologies and practical applications.
Conclusions
In this chapter, we have introduced the RAP/AOR methodology for agent-
oriented information systems engineering. Unlike many other agent-oriented
methodologies, RAP/AOR is not intended to be used in the development of AI
agent systems; rather, it targets the development of large-scale distributed and
cross-enterprise business information systems that may include or even consist
of software agents. RAP/AOR is an agent-oriented extension of RUP+UML by
adding the mental state structure modelling constructs of agents, events, actions,
commitments, and claims, and by adding the behaviour modelling constructs of
reaction rules and activities. Additionally, these modelling constructs fit well with
MDA. In particular, they yield a higher level PIM language that allows a more
direct mapping of CIM elements to PIM elements.
TEAM LinG
B. Henderson-Sellers, & G. Low (Eds.), AOIS-2004 (LNAI, Vol. 3508, pp.

Jacobson, I. (1992). Object-oriented software engineering: A use-case
driven approach. Reading, MA: Addison-Wesley.
Jacobson, I., Booch, G., & Rumbaugh, J. (1999). Unified software develop-
ment process. Reading, MA: Addison-Wesley.
Kruchten, P. (1999). Rational unified process – An introduction. Reading,
MA: Addison-Wesley.
Kueng, P. & Kawalek, P. (1997). Goal-based business process models: Creation
and evaluation. Business Process Management Journal, 3(1), 17-38.
Lamsweerde, A. van. (2003). From system goals to software architecture. In M.
Bernardo & P. Inverardi (Eds.), Formal methods for software architec-
tures (LNCS 2804, Vol. 2804, pp. 25-43). Berlin: Springer-Verlag.
Luin, J., van, Tulba, F., & Wagner, G. (2004). Remodelling the beer game as an
agent-object-relationship simulation. In Proceedings of Workshop 2003:
Agent-Based Simulation 5, Lisbon, Portugal, May 3-5 (pp. 174-179). SCS
European Publishing House.
OMG (2003a). Unified modeling language specification. March 2003, Version
1.5. Retrieved September 28, 2004, from http://www.omg.org/cgi-bin/
doc?formal/03-03-01
OMG (2003b). Unified modeling language: Superstructure. Version 2.0, August
2003. Retrieved September 25, 2004, from http://www.omg.org/cgi-bin/
doc?ptc/2003-08-02
Peleg, M. & Dori, D. (2000). The model multiplicity problem: Experimenting with
real-time specification methods. IEEE Transactions on Software Engi-
neering, 26(8), 724-759.
Putman, J. & Boehm, B. (2001). Architecting with RM-ODP. Upper Saddle
River, NJ: Prentice Hall.
Rao, A. S. & Georgeff, M. P. (1991). Modeling rational agents within a BDI-
architecture. In J. Allen, R. Fikes, & E. Sandewall (Eds.), Proceedings of
the Second International Conference on Knowledge Representation
and Reasoning (KR-91), Boston, April (pp. 473-484). San Mateo, CA:
Morgan Kaufmann.
Searle, J. R. (1995). The construction of social reality. New York: Free Press.
Sowa, J. F. & Zachman, J. A. (1992). Extending and formalizing the framework for
information systems architecture. IBM Systems Journal, 31(3), 590-616.
SPEM: Software Process Engineering Metamodel Specification. November
2002, Version 1.0. Retrieved October 20, 2004, from http://www.omg.org/
docs/formal/02-11-14.pdf
TEAM LinG
Taveter, K. (2004a). A multi-perspective methodology for agent-oriented

business modelling and simulation. PhD thesis, Tallinn University of
Technology, Estonia. (ISBN 9985-59-439-8).
Taveter, K. (2004b). From business process modelling to business process
automation. In J. Cordeiro & J. Filipe (Eds.), Computer-supported
activity coordination – Proceedings of the 1st International Workshop
on Computer Supported Activity Coordination (CSAC 2004). In con-
junction with ICEIS 2004, Porto, Portugal, April 13-14 (pp. 198-210).
Setubal, Portugal: INSTICC Press.
van der Aalst, W.M.P., ter Hofstede, A.H.M., Kiepuszewski, B., & Barros,
A.P. (2003). Workflow patterns. Distributed and Parallel Databases,
14(3), 5-51.
Wagner, G. (2003a). The agent-object-relationship meta-model: Towards a
unified view of state and behavior. Information Systems, 28(5), 475-504.
Available online at http://aor.rezearch.info/
Wagner, G. (2003b). A UML profile for external AOR models. In F.Giunchiglia,
J. Odell, & G. Weiss (Eds.), Agent-Oriented Software Engineering III,
Third International Workshop, AOSE 2002. Bologna, Italy, July 15,
Revised Papers and Invited Contributions, (LNCS, Vol. 2585, pp. 138-
Wagner, G. & Tulba, F. (2003). Agent-oriented modeling and agent-based
simulation. In P. Giorgini & B. Henderson-Sellers, (Eds.), Conceptual
modeling for novel application domains (LNCS, Vol. 2814, pp. 205-
W3C (2003). Web Services Architecture (WSA). W3C Working Draft, 8
August 2003. Retrieved September 29, 2004, from http://www.w3.org/TR/
2003/WD-ws-arch-20030808/
W3C (2004). Web Services Description Language (WSDL) Version 2.0 Part 1:
Core Language. W3C Working Draft, 3 August 2004. Retrieved Septem-
ber 27, 2004, from http://www.w3.org/TR/2004/WD-wsdl20-20040803/
Yu, E. (1995). Modeling strategic relationships for process reengineering.
PhD thesis, Department of Computer Science, University of Toronto,
Canada.
abstractions for the analysis and design of multi-agent systems. In P.
Ciancarini & M. Wooldridge (Eds.), Agent-oriented software engineer-
ing, (LNCS 1957, Vol. 1957, pp. 127-141). Berlin: Springer-Verlag.
TEAM LinG
References
Austin, J. (1962). How to do thing with words. Urmson Editor, Oxford, UK:
Clarenson Press.
Beck, K. (1999). Extreme programming explained: Embrace change. India-
napolis, IN: Addison-Wesley Professional.
Bernon, C., Glaizes, M-P., Peyruqueou, S., & Picard, G. (2002). ADELFE, a
methodology for adaptive multi-agent systems engineering. In P. Petta, R.
Tolksdorf, & F. Zambonelli (Eds.), Engineering societies in the agents
world III: Third International Workshop (ESAW 2002), Madrid, Sep-
tember 16-17, revised papers (Vol. 2577, pp. 156-169). LNAI 2577. Berlin:
Springer-Verlag.
BPML (2002). Business Process Modeling Language 1.0 and Business Process
Modeling Notation 0.9. (2002). Retrieved September 4, 2004, from http:/
/www.bpmi.org
Capera, D., Georgé, J-P., Gleizes, M-P., & Glize, P. (2003). The AMAS theory
for complex problem solving based on self-organizing cooperative agents.
In Proceedings of the 12th IEEE International Workshops on Enabling
Technologies: Infrastructure for Collaborative Enterprises (WETICE
’03), Linz, Austria, June 9-11 (pp. 383-388). IEEE Press.
Cockburn, A. (1997a, Sept). Goals and use cases. Journal of Object-Oriented
Programming, 10(5), 56-62.
Cockburn, A. (1997b, Nov/Dec). Using goal-based use cases. Journal of
Object-Oriented Programming, 10(7), 56-62.
Cockburn, A. (2001). Writing effective use cases. Reading, MA: Addison-
Wesley.
Eshuis, R., Jansen, D. N., & Wieringa, R. J. (2002). Requirements-level
semantics and model checking of object-oriented statecharts. Require-
ments Engineering Journal, 7(4), 243-263.
Evans, R., Kearney, P., Stark, J., Caire, G., Garijo, F. J., Gomez Sanz, J. J.,
Pavon, J., Leal, F., Chainho, P., & Massonet, P. (2001). MESSAGE:
Methodology for engineering systems of software agents. EURESCOM
Technical Information, 2001. Retrieved August 31, 2004, from http://
www.eurescom.de/~pub-deliverables/P900-series/P907/TI1/p907ti1.
pdf
Fowler, M. (2003). The new methodology. Retrieved September 4, 2004, from
http://martinfowler.com/articles/newMethodology.html#N400315
Guizzardi, G. & Wagner, G. (2005). Towards ontological foundations for agent
modelling concepts using the Unified Foundational Ontology. In P. Bresciani,
TEAM LinG
Endnotes
*
The author has done the work reported in this chapter partially as an
employee of the Technical Research Centre of Finland (VTT Information
Technology) from where he is currently on leave.
1
Strictly speaking, the RAP defines a process type family whose members
are process types that can be instantiated by different process individu-
als. It is common practice, though, to use the term “process” ambiguously
both at the level of types and at the level of instances.
2
The RAP/AOR methodology has, for example, been used for creating a
prototypical system for the automation of business-to-business processes
described in Taveter (2004b).
3
A role can be understood as an “abstract characterization of the behaviour
of a social actor within some specialized context or domain of endeavor”
(Yu, 1995), such as the role Seller.
4
Henceforth, we use the terms “actor” and “agent” as synonyms.
5
These functions are actually speech acts (Austin, 1962).
6
A subfunction is a use case that is below the main level of interest of the
primary actor.
TEAM LinG
Multi-Agent Systems Engineering 317
Chapter XI
Multi-Agent Systems
Engineering:
An Overview and
Case Study
Scott A. DeLoach
Kansas State University, USA
Madhukar Kumar
Software Engineer, USA
Abstract
This chapter provides an overview of the Multi-agent Systems Engineering

(MaSE) methodology for analyzing and designing multi-agent systems.
MaSE consists of two main phases that result in the creation of a set of
complementary models that get successively closer to implementation.
MaSE has been used to design systems ranging from a heterogeneous
database integration system to a biologically based, computer virus-
immune system to cooperative robotics systems. The authors also provide a
case study of an actual system developed using MaSE in an effort to help
demonstrate the practical aspects of developing systems using MaSE.
TEAM LinG
318 DeLoach & Kumar
Introduction
This chapter describes the Multi-agent Systems Engineering (MaSE) methodol-
ogy for analyzing and designing multi-agent systems. MaSE was originally
designed to develop closed, general purpose, heterogeneous multi-agent sys-
tems. MaSE has been used to design systems ranging from a heterogeneous
database integration system to a biologically based, computer virus-immune
system to cooperative robotics systems. While the multi-agent systems designed
by MaSE are typically closed (the number and type of all agents are known a
priori), the number of agents is unlimited, although, practically, the number of
types of different agents is limited to something less than 50.
MaSE uses the abstraction provided by multi-agent systems to help designers
develop intelligent, distributed software systems. MaSE views agents as a
further abstraction of the object-oriented paradigm where agents are a special-
ization of objects. Instead of simple objects, with methods that can be invoked
by other objects, agents coordinate with each other via conversations and act
proactively to accomplish individual and system-wide goals. Agents are a
convenient abstraction that allows designers to handle intelligent and non-
intelligent system components equally within the same framework.
MaSE builds on existing object-oriented techniques and applies them to the
specification and design of multi-agent systems. Many of the models developed
with MaSE are similar to models defined in the Unified Modeling Language.
However, the semantics of the models are often specialized for the multi-agent
setting.
MaSE was designed to be used to analyze, design, and implement multi-agent
systems by proceeding in an orderly fashion through the development lifecycle
(DeLoach, Wood, & Sparkman, 2001). MaSE has been automated via an
analysis and design environment called agentTool, which is a tool that supports
MaSE and helps guide the system designer through a series of models, from high-
level goal definition to automatic verification, semi-automated design generation,
and finally to code generation.
The MaSE methodology consists of two main phases that result in the creation
of a set of complementary models. The phases and the respective models that
result at the end of each phase are listed below. While presented sequentially,
the methodology is, in practice, iterative. The intent is to free the designer to
move between steps and phases such that with each successive pass, additional
detail is added and, eventually, a complete and consistent system design is
produced.
TEAM LinG
Phases Models
1. Analysis Phase Goal Hierarchy
a. Capturing Goals Use Cases, Sequence Diagrams
b. Applying Use Cases Concurrent Tasks, Role Model
c. Refining Roles
2. Design Phase Agent Class Diagrams
a. Creating Agent Classes Conversation Diagrams
b. Constructing Conversations Agent Architecture Diagrams
c. Assembling Agent Classes Deployment Diagrams
d. System Design
Analysis Phase
The first phase in developing a multi-agent system using the MaSE method-
ology is the analysis phase. The goal of the MaSE analysis phase is to define
a set of roles that can be used to achieve the system-level goals. These roles are
defined explicitly via a set of tasks, which are described by finite state models.
This process is captured in three steps: capturing goals, applying use cases, and
refining roles.
Capturing Goals
The purpose of the first step in the analysis phase is to capture goals of the system
by extracting the goals from a set of system requirements. The initial system
requirements may exist in many forms including informal text and tell the
designer about how the system should function based on specific inputs and the
system state. The MaSE methodology uses these requirements to define goals
in two specific sub-steps: Identifying goals and Structuring goals.
Identifying Goals
The main purpose of this step is to derive the overall system goal and its subgoals
from the initial set of requirements. This is done by first extracting scenarios from
the requirements and then identifying the goals of the scenarios. These initial
scenarios are usually abstract in nature and are critical to the entire system.
Therefore, the goals identified from these scenarios are at a very high level.
These high-level goals then serve as the basis of analysis of the entire system.
The roles defined later in the analysis phase must support one of these goals.
Later, if the analyst defines a role that does not support one of these goals, either
TEAM LinG
322 DeLoach & Kumar
MaSE is built on the assumption that the system goals will be satisfied if each goal
maps to a role, and every role is played by at least one agent class. In general,
the mapping of goals to roles involves a one-to-one mapping. However, the
developer may choose to allow a role to be responsible for multiple goals for the
sake of convenience or efficiency. At this stage, the developer may also choose
to combine several roles; although this will most certainly increase the complex-
ity of the individual roles, it can significantly simplify the overall design.
In MaSE, goal refinement is captured in a Role Model (Kendall, 1998). In this
model, the roles are represented by a rectangle, while a role’s tasks are
represented by ovals attached to them. The arrows between tasks designate
communication protocols, with arrows pointing from the initiator of the protocol
toward the responder. Solid lines represent external communication (role-to-
role), while dashed lines indicate internal communication between tasks belong-
ing to the same role instance.
Once the roles are decomposed into a set of tasks, the individual tasks are
designed to achieve the goals for which the role is responsible. It is important to
note here that roles should not share tasks with other roles. Sharing a task among
different roles indicates improper role decomposition. If the analyst believes that
a task needs to be shared, then a separate role should be created for that task.
This will allow the task to be incorporated into different agent classes, thus being
effectively shared.
Concurrent Task Model
After the roles are defined, the analyst must define the details of each task in the
role model. Task definition is performed via a Concurrent Task Diagram, which
is based on finite state automata. Semantically, each task is assumed to run
concurrently and may communicate with other tasks either internally or exter-
nally. Taken collectively, the set of tasks for a specific role should define the
behavior required for that role.
A concurrent task consists of a set of states and transitions. The states in the
concurrent tasks represent the internal functioning of an agent while transitions
define the communication between tasks. Every transition in the model has a
source state, destination state, trigger, guard condition, and transmissions. The
transitions use the syntax
trigger [guard] ˆ transmission(s)
If there are multiple transmissions required, they can be concatenated using a

semicolon (;) as a separator; however, no ordering is implied. In general, events
TEAM LinG
320 DeLoach & Kumar
the role is not needed or the initial set of goals was incomplete and a new goal
must be added.
Structuring Goals
After the goals have been identified, the second step is to categorize and
structure them into a goal tree. The result is a Goal Hierarchy Diagram whose
nodes represent goals and arcs define goal/subgoal relationships. The Goal
Hierarchy Diagram is acyclic; however, there some subgoals that may have
more that one parent goal.
To structure the goals, the analyst first identifies the main goal of the system. In
the case where there is more than one main goal, those goals must be summarized
as one high-level goal that is decomposed into a set of subgoals that are easier
to manage and understand. To decompose a goal into subgoals, the developer
must analyze what must be done to achieve the parent goals. A subgoal should
support its parent goal by describing a subgoal that must be achieved in order to
achieve the parent goal.
Although superficially similar, goal decomposition is different from function
decomposition since goals define what tasks must be done instead of how a task
is achieved, which is functional decomposition. Thus, goal decomposition should
stop when the designer thinks that any further decomposition will result in
functions and not subgoals. MaSE goal decomposition is similar to the KAOS
approach (van Lamsweerde & Letier, 2000) except that MaSE goals do not have
to be strictly AND-refined or OR-refined.
There are four types of goals in a Goal Hierarchical Diagram: summary goals,
partitioned goals, combined goals, and non-functional goals. Any goal or subgoal
can take on the attributes of any one, or more, of these types of goals. The four
types of goals are described below.
1. Summary Goal. A summary goal encapsulates a set of existing “peer” goals

to provide a common parent goal for the set. This often happens at the
highest level of the Goal Hierarchical Diagram when a goal may be needed
to support multiple high-level goals.
2. Non-Functional Goal. As the name suggests, non-functional goals are
derived from non-functional requirements of the system, such as maintain-
ing reliability or response times of the system. These goals need not directly
support the overall functional goals of the system. When a non-functional
goal is discovered, a new branch is generally created under the overall
system goal, which can then be decomposed into either functional or non-
functional sub-goals.
TEAM LinG
Conversations are modeled using two different Conversation Class Diagrams,

one for the initiator and the other for the responder. These diagrams are based
on finite state automata and use states and transitions to define the inter-agent
communication, similar to concurrent tasks. The transitions in the conversation
diagrams use a slightly different syntax
rec-mess(args1) [cond] / action ˆ trans-mess(args2)
This means that that if the message rec-mess is received with the arguments
args1 and the condition cond holds true, then the method action is called and
the message trans-mess is sent with arguments args2.
Conversations are derived from the concurrent tasks of the analysis phase, based
on the roles the agents are required to play. Thus, each task that defines an
external conversation (outside the role) ends up becoming one or more conver-
sation between agents. However, if all task communication is internal (within the
same role) or with roles that are performed by the same agent, then the
communication translates into internal function or method calls. Generally,
however, concurrent tasks translate into multiple conversations, as they require
communication with more than one agent class.
During this stage, the designer also needs to take into account other factors
besides the basic protocols defined in the concurrent tasks. For example, what
should an agent do if it does not receive the message it was expecting? Perhaps
the communication medium was disabled or the other agent failed. Therefore, the
designer should attempt to make conversations robust enough to handle potential
run-time errors.
Assembling Agent Classes and Deployment Design
The last two stages in MaSE involve the internal design of the agent classes and
the system-level design. The first of these stages, Assembling Agent Classes,
involves two steps, defining the agents’ architecture and defining the individual
components of the architecture. MaSE does not assume any particular agent
architecture and attempts to allow a wide variety of existing and new architec-
tures to be used. Thus, the designer has the choice of either using pre-existing
agent architecture like Beliefs, Desires, and Intentions (BDI) or creating a new
architecture from scratch. The same goes for the architecture components. The
step of assembling agents result in an Agent Architecture Diagram in which the
components are represented by rectangular boxes connected to either inner or
outer agent connectors. The inner-agent connectors, represented by thin arrows
define visibility between components, while the outer agent connectors, repre-
TEAM LinG
3. Combined Goal. While analyzing the goals of a system, often a number of

subgoals are discovered in a hierarchy that are identical or very similar and
can be grouped into a combined goal. This often results when the same
basic goal is a subgoal of two different goals. In this case, the combined goal
becomes a subgoal of both the goals.
4. Partitioned Goal. A partitioned goal is one of a set of goals that collectively
meet a parent goal. This is identical to the notion of a KAOS conjunctive
goal.
Once the goals have been identified and structured, the developer is ready to
move to the next step of the MaSE analysis phase, applying use cases.
Applying Use Cases
In this step, the goals and subgoals are translated into use cases. These use cases
typically capture the scenarios discovered in the previous step by providing a
textual description and a set of sequence diagrams that are similar to the UML
sequence diagrams. The main difference between MaSE sequence diagrams
and UML is that in MaSE they are used to represent sequences of events
between roles instead of objects. The events sent between roles are used in later
steps to help define the communications between the agents that will be
eventually playing these roles.
The use case at this stage helps the developer in representing desired system
behaviors and sequences of events. When the use cases are converted to
sequence diagrams, the roles that are identified become the initial set of roles that
will be used in the next step of refining roles.
While not all requirements can be captured as use cases, the developer should
try to represent the critical requirements as either positive or negative use cases.
Positive use cases define the desired system behaviors, and negative use cases
describe a breakdown or an error in the system. Both are useful in defining roles
that must be played in the system.
Refining Roles
With the Goal Hierarchy Diagram and use cases in place, the analyst is ready to
move to the next step, Refining Roles. This step involves further defining roles
by associating them with specific tasks. The roles produced from this step are
defined in such a way as to ensure that each system goal is accounted for and
form the building blocks for the agents that will eventually populate the system.
TEAM LinG
sent as triggers or transmissions are associated with events sent to tasks within
the same role instance, thus allowing for internal task coordination. To represent
messages sent between agents, however, two special events—send and receive
—are used.
The send event is used to represent a message sent to another agent and is
denoted by send(message, agent) while a receive event, denoted by
receive(message, agent), is used to define a message received from another
agent. The message itself consists of a performative, the intent of the message
along with a set of parameters. It is also possible to send the same message to
several agents at the same time using multicasting by using a group name of the
agents as compared to the name of a single agent.
Task states may contain activities that represent internal reasoning, reading a
percept from sensors, or performing actions via actuators. More than one
activity may be included in a single state and they are performed in an
uninterruptible sequence, which, when combined with states and transitions,
gives a general computational model. Once inside a state, the task remains there
until the activity sequence is complete. Variables used in activity and event
definitions are visible within the task, but not outside of the task or within
activities. All messages sent between roles and events sent between tasks are
queued to ensure that all messages are received even if the agent or task is not
in the appropriate state to handle the message or event immediately.
Once a transition is enabled, it is executed instantaneously. If multiple transitions
are enabled, then internal events are handled first, external messages (the send/
receive events) are next, and the transitions with guard conditions only are last
(DeLoach, 2000).
To reason about time, the Concurrent Task Model provides a built-in timer
activity. An agent can define a timer using the setTimer activity, t = setTimer(time).
The setTimer activity takes a time as input and returns a timer that will timeout
in exactly the time specified. The timer that can then be tested via the timeout
activity, timeout(t), which returns a Boolean value, to see if it has “timed out.”
Design Phase
In the analysis phase, a set of goals was derived and used to create a set of use
cases and sequence diagrams that described basic system behavior. These
models were then used to develop a set of roles and tasks that showed how the
goals should be achieved. The purpose of the design phase is to take those roles
and tasks and to convert them into a form that is more amenable to implemen-
tation, namely, agents and conversations. The MaSE design phase consists of
TEAM LinG
326 DeLoach & Kumar
sented by dashed arrows, define external connections to resources like other

agents effectors, databases, and so on. A more detailed discussion of this step
can be found in Robinson (2000).
The last step in building a multi-agent system using the MaSE methodology is to
decide on the actual configuration of the system, which consists of deciding the
number and types of agents in the system and the platforms on which they should
be deployed. These decisions are documented in a Deployment Diagram, which
is very similar to a UML Deployment Diagram and is used for much the same
purpose. In a Deployment Diagram, agents are represented by three-dimen-
sional boxes, while rectangles with dashed lines represent physical computing
platforms. The lines between agents represent the actual lines of communication
between the agents. In a dynamic multi-agent system in which agents move or
are created and destroyed, the Deployment Diagrams are used to show
snapshots of possible system configurations.
Example Case Study:

Multi-Agent Research Tool (MART)
To show how to use the MaSE methodology outlined above, this section presents
an example of using MaSE to develop an actual multi-agent system. The Multi-
agent Research Tool (MART) was developed as part of a MS project at Kansas
State University and is being considered for distribution by a private company.
The analysis and design was performed using the agentTool development
environment, with the implementation being done in Java.
Overview
Writing articles is an important part of work for a researcher at a university or

a content provider working for a media company. While writing research or news
articles, the author often conducts searches on the World Wide Web (WWW)
to unearth relevant information that can be used to write the article. However,
when an author is writing an article, it is often a distraction to stop writing, visit
a few search engines, conduct keyword searches, retrieve relevant information,
and then incorporate it into the article. This is not very efficient, especially when
the author has to deliver the article by a specific deadline.
The motivation for developing a Multi-agent Research Tool (MART) was to
develop a tool that helps authors to research while writing an article without
wasting valuable time. This means that the research tool should not only be smart
TEAM LinG
324 DeLoach & Kumar
four steps. These steps include designing agent classes, developing conversation
between the agents, assembling agents, and finally deploying the agents at
system-level design.
Construction of Agent Classes
The first step in the design phase involves designing the individual agent classes,
which is documented in an Agent Class Diagram. In this step, the designer maps
each role defined in the analysis phase to at least one agent class. Since roles are
derived from the system goals and are responsible for achieving them, enforcing
the constraint that each role is assigned to at least one agent class in the system
helps to ensure that the goals are actually implemented in the system. In general,
an agent class can be thought of as a template for creating the actual agent
instances that will be part of the multi-agent system. These templates are defined
in terms of the roles they play and the protocols they use to coordinate with other
agents.
The first step in constructing agent classes is to assign roles to the agent classes.
If the designer chooses to assign more than one role to the same agent class, the
roles may be performed either concurrently or sequentially. The assignment of
roles to agents allows the multi-agent organization to be easily modified, since the
roles can be manipulated modularly. This allows the designer to manipulate the
design to account for various software engineering principles, such as functional
or temporal cohesion.
Once the agents are created by identifying the roles they will be playing, the
conversations between agents are designed accordingly. For example, if two
roles, R1 and R2, that shared a communication protocol were assigned to agent
classes A1 and A2 respectively, then A1 and A2 would require a conversation
(to implement the protocol) between them as well.
The Agent Class Diagram that results from this step is similar to object-oriented
class diagrams. They are different in that (1) agent classes are defined by the
roles they play instead of their attributes and methods, and (2) the relationships
between agent classes are always conversations.
Constructing Conversations
Once the agent classes have been defined and the required conversations
identified, the detailed design of the conversations is undertaken. These details
are extracted from the communications protocols identified in the analysis phase.
TEAM LinG
and efficient in conducting searches, but that it should also be able to work in the
background and, at the same time, be non-intrusive to the user. Moreover, since
use of the Internet has become commonplace, it is assumed that a person using
MART has access to the Internet. It would be more useful if the research tool
could use distributed computing to retrieve research material and present it to the
user whenever he/she decides to view or use them. Based on the nature of the
original motivation, it was decided to build MART as a multi-agent system since
the location and numbers of the various components within the local network
would not be known in advance. Since MART was developed using the MaSE
methodology, the decision to use the agentTool development environment—a
software engineering tool that directly supports MaSE analysis and design—was
straightforward.
Developing Goals of the System
In the first step of the Analysis Phase, the following goals were defined based
on the requirements for the MART system, as presented above. As shown in
Figure 1, the overall goal of the system is to produce the results of a search for
keywords from the user’s article. This goal is partitioned into four subgoals:
ranking and refining the keywords used in the search, searching the Web for
results, producing and presenting the result to the user, and managing the entire
system.
The rank and refine search keywords goal is partitioned into two subgoals:
reading user keywords and ranking the keywords. The goal, search the Web, is
also partitioned; however, it has only one subgoal, namely, search Web sites.
Although not technically required, this goal structure was adopted so that future
versions could add additional goals that could include searching other types of
Figure 1. MART system goals
TEAM LinG
328 DeLoach & Kumar
information sources such as databases located on the host computer and/or local
network. Finally, the goal produce results is partitioned into three subgoals that
allow for reading raw results, refining the raw results, and producing the final
results that will be presented to the user.
Applying Use Case
After defining the goals, three primary use cases were generated based on the
three main subgoals (1.1, 1.2, and 1.3 in Figure 1). These use cases are Refine
and Rank Keywords, Search the Web, and Generate Results. Each is
presented in detail below.
Refine and Rank Keywords
The Refine and Rank Keywords use case defines how the system should behave
when it is initially asked to perform as search. As shown in Figure 2, the manager
of the search process asks the reader to read the predefined user preferences
and keywords and then asks the ranker to rank the keywords that were returned.
The user preferences define exactly how the user prefers the search to be
conducted while the keywords are the specific words on which the user wants
the search to be conducted. These keywords are then ranked in terms of
relevance to the article the user is currently writing.
Figure 2. Sequence diagram for “Refine and Rank Keywords” use case
TEAM LinG
Figure 3. Sequence diagram for the use case “Search the Web”
Search the Web
As shown in Figure 3, the Search the Web use case defines the basic search
process of the system once a set of keywords has been developed. Each
searcher agent is asked to search its known Web sites for a specific set of
keywords. Exactly where and how each searcher conducts its search is not
known to the manager. However, once results are received back by the searcher
agents, the results are returned to the controller, who tabulates the results for a
variety of searchers.
Generate Results
The sequence diagram in Figure 4 shows that the manager, once it has the raw
results, sends a message to the result generator along with the raw results. The
result generator refines the results by extracting duplicates and providing proper
formatting and then sends back the finished product back to the manager.
Figure 4. Sequence diagram for the use case “Generate results”
TEAM LinG
330 DeLoach & Kumar
Figure 5. MART role model
Refining Roles
The role diagram depicts how the different goals are mapped to the roles of the
system. Figure 5 shows that the controller has many tasks that collaborate with
the other roles in order to read keywords, perform a search, and generate the
finished product. The numbers inside rectangles (roles) indicate the goals for
which they are responsible. For example, the Controller role is responsible for
goal 1.4 from Figure 1, which is the goal of managing the system.
As discussed above, the solid lines connecting the different roles represent the
communication between the roles. The dotted line between tasks in the Sleuth
role (the makeRaw protocol) shows that it is an internal communication between
tasks within the same role instance (agent). The makeRawResults task is
invoked by the rawResults task of the Sleuth once it receives the searchTheWeb
request from the controller.
Concurrent Task Model
Once the Role Model has been constructed, a concurrent task model was defined
for each task in the role model. For example, showKeywords is a task for the
KeywordsReader role. An example of a concurrent task model for
showKeywords is shown in Figure 6. The task starts when a readPrefs message
is received from an agent named controller. After receiving the message, the
user preferences are read via the activity readPreferences() in the readPreferences
state. Upon completion of the activity, the task enter the readKeywords state
TEAM LinG
Figure 6. The showKeywords task for role KeywordsReader
where it gets the keywords from the user via the readKeywords() activity. If the
keywords list is empty (null), then the task ends without sending a response.
Otherwise, the task sends the set of keywords back to the controller.
Constructing Agent Classes
After all the tasks from the Role Model have been defined via concurrent task
diagrams, the analysis phase ended and the design phase commenced. The first
step of the design phase is to define the basic system architecture using an Agent
Class Diagram. The initial task was to create agent classes and assign them
specific roles to play.
The Agent Class Diagram shown in Figure 7 shows that MART has five different
agents: AgentManager, AgentKey, AgentProducer, AgentGoogle, and
AgentTeoma. The lines connecting the agents represent the conversations
between the agents. For example, searchTheWeb is a conversation that is
initiated by AgentManager. searchTheWeb is unique in that it exists between the
AgentManager and two different agent types: AgentGoogle and AgentTeoma.
Actually, both of these agent types implement the Sleuth role, and the conver-
sation can be directed from the AgentManager to either agent type requesting
them to conduct a search and return raw results. The agent classes in Figure 7
TEAM LinG
Figure 12. Simplified UML class model for MART
design was implemented by integrating all the agent components into a single
class (one class for each agent type). This resulted in the simplified class
structure shown in Figure 12.
The system architecture is shown in Figure 13, where each agent class is
represented as a package. Obviously, multiple versions of each agent may exist.
The KeyObjectPackage, which is accessed by each of the agents, includes shared
definitions of data objects passed between agents. The diagram also includes a
user-defined stereotype «conversation» to denote the existence of conversations
between the various agent packages. The system was implemented using the
agentMom agent-oriented middleware system, which inherently supports the
concept of conversations as defined in MaSE (Mekprasertvit, 2004).
TEAM LinG
334 DeLoach & Kumar
Figure 11. Deployment diagram for MART
components do not communicate directly (they are derived from the

showKeywords and rankedKeywords tasks in Figure 5), there is not a visibility
connection between them.
The last step in the design of the MART system was to develop the overall
system deployment design. The MART Deployment Diagram, as shown in
Figure 11, was created as an example of how the MART system could be
deployed. As the MART system is designed to be deployed in a number of
settings, this deployment is notional. Typically, the AgentKey and AgentManager
agents are started on the user’s computer while the AgentGoogle and AgentTeoma
agents must be pre-deployed on local network computers (the AgentProducer
agent may be deployed anywhere on the local network as well).
Refining the Object Model
After completing the analysis and design for MART, the implementation of the
system began. As the system analysis and design was performed using agentTool,
the first step was to verify that the conversations were correct and deadlock
free. After this step was completed, the code generation capabilities of agentTool
were employed to generate the initial code, which included stubs for each agent,
each component, and each side of the conversations. Generally, each agent
component is implemented as a single class. However, due to the simplicity of
the components defined during the Assembling agents step, each agent class
TEAM LinG
Figure 8. Conversation model for rankKeywords Initiator
Figure 9. Conversation model for rankKeywords Responder
Assembling Agents and Deployment
After developing the conversations required for MART, the next step was
constructing the individual components of the agent classes. As discussed
earlier, there is a choice of either using either pre-existing agent architectures or
creating an application-specific architecture. Because the MART agents were
simple, it was decided that a simple application-specific architecture was the best
approach for MART. Each concurrent task was mapped directly to an internal
component in the architecture, thus making the internal agent design directly
reflect the roles and tasks of the analysis model. An example of component
structure of the AgentKey agent class is shown in Figure 10.
The attributes and methods of the showKeywords component are derived
directly from the showKeywords task defined in Figure 6, with the exception of
the conv_r_readUserPreferences method. The conv_r_readUserPreferences method
was created to initiate the readUserPreferences conversation. When the agent
wants to start the readUserPreferences conversation, it calls the method, which
contains all the implementation dependent code for handling the conversation.
The rankedKeywords component was derived similarly. Because these two
Figure 10. Components of AgentKey
TEAM LinG
336 DeLoach & Kumar
Figure 13. MART packages
Strengths and Weaknesses
Strengths
MaSE is a comprehensive methodology for building multi-agent systems. It has

been used to develop both software multi-agent systems and multi-agent
cooperative robotic systems (DeLoach, Matson, & Li, 2003). One of the major
strengths of MaSE is that it provides guidance throughout the entire software
development lifecycle—from requirements elicitation through to implementa-
tion.
Firstly, MaSE is independent of any particular agent architecture or underlying
environment. While the example above does not use pre-existing agent architec-
tures, MaSE does allow the task and conversation behavior to be implemented
in any architecture the designer wishes. For example, Robinson (2000) has
defined a variety of agent architectures using MaSE components including
reactive, BDI (Belief Desires and Intentions), knowledge-based, and planner
based.
The sequence of interrelated MaSE models allows the developer to track the
mapping of entities from one model to the next. This is most readily apparent in
the mapping of goals to roles, roles to agents, and communications protocols to
conversations. This mapping allows the developer to move between models,
TEAM LinG
showing that the entities defined in previous models are implemented success-
fully in the current model. It also provides an excellent tool for tracking down
system errors. If a particular goal is not being successfully achieved, the
developer can track that goal directly to the responsible role and then on the
implementing agent classes.
Often in multi-agent approaches, developers are allowed to specify behavior and
agent communications protocols; however, the relationship between the two is
not always clear. MaSE provides a way of directly defining the relationship
between agent communication protocols and the internal behavior of the agent.
This relationship is captured in the concurrent task diagrams and is carried over
to agent conversation diagrams. By studying a set of concurrent tasks, it
becomes evident how the communications between roles, and eventually agents,
directly affects and is affected by the results of the communication. For instance,
in Figure 6, it is clear that the computation (the readPreferences activity) starts
after receiving the readPrefs message, and the results of the readKeywords
activity determine whether the userKeywords message is even sent.
MaSE is also supported by the agentTool development environment. AgentTool
is a software engineering tool built to help designers create multi-agent systems
using the MaSE methodology. Using agentTool, a multi-agent system can be
developed by following the MaSE steps in both the analysis and design phases.
Since agentTool is a graphical-based tool, all the diagrams and the models
described in the MaSE methodology are created using the tool. During each step
of system development, the various analysis and design diagrams are available
via agentTool and the developer is allowed to move freely back and forth
between models in the various MaSE steps. A developer may also use agentTool
to verify a conversation at any point by using the conversation verification
capability (Lacey & DeLoach, 2000), which uses the Spin model checker
(Holzmann, 1997) to check for deadlocks, as well as non-progress loops, syntax
errors, unused messages, or unused states. If an error exists, the verification
results are presented textually to the developer as well as by directly highlighting
the offending conversation diagram. AgentTool includes developing support for
semi-automatic transformations that convert a set of analysis models into the
appropriate design models (Sparkman, DeLoach, & Self, 2001). To initiate the
process, the designer assigns roles to specific agent classes and then applies the
semi-automated transformations. There are three transformation stages. In
stage one, the transformations determine to which protocol individual concurrent
task events belong. Next, the transformations create internal components for
each concurrent task associated with the agent class. In the final stage, the
conversations are extracted from the concurrent tasks and placed in conversa-
tion diagrams.
TEAM LinG
332 DeLoach & Kumar
Figure 7. MART agent class diagram
represent independent processes operating in their own thread of control. These

agents could be placed on different machines and still be able to talk to each other
using the conversations defined in the system.
Constructing Conversations
After creating the agent classes and documenting them via the Agent Class
Diagram, the individual communication between the agents was defined, based
on the protocols between the appropriate roles from which they were derived.
Each resulting conversation was documented using a pair of Conversation
Diagrams, which are similar to and can be derived from the concurrent tasks
models developed during the analysis phase (Sparkman, DeLoach, & Self, 2001).
Each conversation is represented from the initiator’s and the responder’s points
of view. For example, the conversation rankKeywords from the above diagram
has the agent class AgentManager as the initiator and agent class AgentKey as
the responder. The diagrams are show below in Figure 8 and Figure 9. Taken
together, the diagrams show that the initiator sends the rankKey message with the
parameter keywords to the responder and then waits until a rankedKey message
is returned along with the ranked set of keywords via the message parameter. The
responder side of the conversation is quite similar, with the messages sent by the
initiator being received and the messages received by the initiator being sent. The
obvious difference between the two is that the responder side includes an
activity, rankKeywords(), that is called to actually perform the ranking process.
TEAM LinG
338 DeLoach & Kumar
Weaknesses
While MaSE provides many advantages for building multi-agent systems, it is not
perfect. It is based on a strong top-down software engineering mindset, which
makes it difficult to use in some application areas. First, MaSE is not currently
appropriate for the development of open multi-agent systems. Since MaSE
predefines the communications protocols between agent classes, the resulting
system assumes that any agents trying to participate in the system implicitly
know what those protocols are. In addition, MaSE does not inherently support the
use of different ontologies, although an extension to MaSE by DiLeo, Jacobs, and
DeLoach (2002) does incorporate the notion of ontologies into MaSE and
agentTool. In general, however, MaSE implicitly defines an ontology that is
embedded in the task communication protocols and is implemented within each
agent.
The MaSE notion of conversations can also be somewhat bothersome, as they
tend to decompose the protocols defined in the analysis phase into small, often
extremely simple pieces when the original protocol involves more than two
agents. This often results in conversations with only a single message. This
makes comprehending how the individual conversations fit together more
difficult.
MaSE also tends to produce multi-agent systems with a fixed organization.
Agents developed in MaSE tend to play a limited number of roles and have a
limited ability to change those roles, regardless of their individual capabilities.
Recent trends in multi-agent systems are towards the explicit design and use of
organizations, which allow heterogeneous agents to work together within well-
defined roles to achieve individual and system-level goals. In multi-agent teams,
the use of roles and goals allows the agents to perform their duties in an efficient
and effective manner that allows the team to optimize its overall performance.
In most multi-agent design methodologies, including MaSE, the system designer
analyzes the possible organizational structure and then designs one organization
that will suffice for most anticipated scenarios. Unfortunately, in dynamic
applications—where the environment as well as the agents may change—a
designer can rarely account for or even consider all possible situations.
Ideally, a multi-agent team would be able to design its own organization at
runtime. To accomplish this, MaSE would have to be extended to be able to
analyze and design multi-agent organizations. While MaSE already incorporates
many of the required organizational concepts such as goals, roles, and the
relations between these entities, it cannot currently be used to define a true multi-
agent organization.
TEAM LinG
Conclusions
MaSE provides a detailed approach to the analysis and design of multi-agent
systems. MaSE combines several established models into a comprehensive
methodology. It also provides a set of transformation steps that shows how to
derive new models from the existing models thus guiding the developer through
the analysis and design process.
MaSE has been successfully applied in many graduate-level projects as well as
several research projects. The Multi-agent Distributed Goal Satisfaction Project
used MaSE to design the collaborative agent framework to integrate different
constraint satisfaction and planning systems. The Agent-Based Mixed-Initiative
Collaboration Project also used MaSE to design a multi-agent system focused on
distributed human and machine planning. MaSE has been used successfully to
design an agent-based heterogeneous database system as well as a multi-agent
approach to a biologically based computer virus-immune system. More recently,
we applied MaSE to a team of autonomous, heterogeneous search and rescue
robots (DeLoach, Matson, & Li, 2003). The MaSE approach and models worked
very well. The concurrent tasks mapped nicely to the typical behaviors in robot
architectures. MaSE also provided the high-level, top-down approach missing in
many cooperative robot applications.
Future work on MaSE will focus on specializing it for use in adaptive multi-agent
and cooperative robotic systems based on an organizational theoretic approach.
We are currently developing an organizational model that will provide the
knowledge required for a team of software or hardware agents to adapt to
changes in their environment and to organize and re-organize to accomplish team
goals. Much of the information needed in this organizational model—goals, roles
and agents—is already captured in MaSE. However, we will have to extend
MaSE analysis to capture more detail on roles, including the capabilities required
to play roles.
References
DeLoach, S.A. (2000). Specifying agent behavior as concurrent tasks:
Defining the behavior of social agents. Technical Report, U.S. Air
Force Institute of Technology, AFIT/EN-TR-00-03.
DeLoach, S.A., Matson, E.T., & Li, Y. (2003). Exploiting agent oriented
software engineering in cooperative robotics search and rescue. The
International Journal of Pattern Recognition and Artificial Intelli-
gence, 17(5), 817-835.
TEAM LinG
340 DeLoach & Kumar
DeLoach, S.A., Wood, M.F., & Sparkman, C.H. (2001). Multiagent systems
engineering. The International Journal of Software Engineering and
Knowledge Engineering, 11(3), 231-258.
DiLeo, J., Jacobs, T., & DeLoach, S.A. (2002). Integrating ontologies into
multiagent systems engineering. In Proceedings of the Fourth Interna-
tional Bi-Conference Workshop on Agent-Oriented Information Sys-
tems (AOIS 2002) at AAMAS ’02, Bologna, Italy, July 16. Available from
http://CEUR-WS.org/Vol-59
Holzmann, G.J. (1997). The model checker spin. IEEE Transactions on
Software Engineering, 23(5), 279-295.
Kendall, E. (1998). Agent roles and role models: New abstractions for multiagent
system analysis and design. In Proceedings of the International Work-
shop on Intelligent Agents in Information and Process Management,
Bremen, Germany, September.
Lacey, T.H. & DeLoach, S.A. (2000). Automatic verification of multiagent
conversations. In Proceedings of the 11th Annual Midwest Artificial
Intelligence and Cognitive Science Conference, University of Arkan-
sas, Fayetteville, April 15-16 (pp. 93-100). AAAI Press.
Mekprasertvit, C. (2004). AgentMom user’s manual. Kansas State University.
Retrieved June 30, 2004, from http://www.cis.ksu.edu/~sdeloach/ai/
software/agentMom_2.0/
Robinson, D. (2000). A component based approach to agent specification.
Master’s Thesis. AFIT/GCS/ENG/00M-22. School of Engineering, Air
Force Institute of Technology, Wright-Patterson AFB.
Sparkman, C.H., DeLoach, S.A., & Self, A.L. (2001). Automated derivation of
complex agent architectures from analysis specifications. In Proceedings
of the Second International Workshop on Agent-Oriented Software
Engineering, (AOSE 2001), Springer Lecture Notes in Computer
Science (Vol. 2222, pp. 188-205).
van Lamsweerde, A. & Letier, E. (2000). Handling obstacles in goal-oriented
requirements engineering. IEEE Transactions on Software Engineering,
26(10), 978-1005.
TEAM LinG
342 Tran & Low
Introduction
This chapter presents an evaluation and comparison of the 10 agent-oriented
software engineering (AOSE) methodologies discussed in the preceding chap-
ters. The objective is to assist researchers and practitioners in selecting the most
appropriate methodology for a particular application. In order to achieve this, we
discuss the similarities and differences between the methodologies, noting their
strengths and weaknesses with regard to their support for multi-agent systems
(MAS) development. This comparison is not a straightforward task, considering
the heterogeneity of the methodologies in terms of their scope, approaches,
terminology, development activities, and modelling notations.
The evaluation and comparison are conducted using the feature analysis
approach. Feature Analysis is the most common and cost-effective approach
compared to other evaluation techniques such as survey, case study, and field
experiment (Siau & Rossi, 1998). Feature analysis employs a checklist of
evaluation criteria to assess and compare methodologies based on selected
methodological features.
We have adopted the feature analysis framework proposed by Tran, Low, and
Williams (2003). This framework was developed from a synthesis of previous
evaluation efforts and is capable of assessing AOSE methodologies from both
the dimensions of conventional system development methodologies and those
specific to AOSE. Its evaluation criteria are comprehensive, case-generic, and
multi-dimensional, covering AOSE methodology’s process, techniques, and
models.
We will describe the evaluation framework in more detail in the next section. The
section entitled “Comparative Analysis” presents the evaluation and comparison
of the 10 AOSE methodologies, using the framework.
The Evaluation Framework

The selected evaluation framework was formed by identifying and integrating
the evaluation criteria from various feature analysis frameworks, including those
for assessing conventional system development methodologies – namely Wood,
Pethia, Gold, and Firth (1988), Jayaratna (1994), Olle, Sol, and Tully (1983), and
the Object Agency Inc. (1995), and those for evaluating AOSE methodologies
– namely Shehory and Sturm (2001), O’Malley and DeLoach (2001), Cernuzzi
and Rossi (2002), and Sabas, Badri, and Delisle (2002). The former category
provides a well-established list of generic system engineering features to be
TEAM LinG
Comparison of Ten Agent-Oriented Methodologies 341
Chapter XII
Comparison of Ten
Agent-Oriented
Methodologies
Quynh-Nhu Numi Tran
University of New South Wales, Australia
Graham C. Low
University of New South Wales, Australia
Abstract
This chapter provides a comparison of the 10 agent-oriented software

engineering methodologies presented in the preceding chapters. An
evaluation framework comprising process-related, technique-related, model-
related and supportive-feature criteria is used in this comparison. As each
application entails a different set of requirements that indicate which
evaluation criteria are the most important and should be supported by the
chosen methodology, the “best” methodology is dependent on the target
application. The results provide a useful framework to assist the developer
in selecting the most appropriate methodology for any target application.
TEAM LinG
344 Tran & Low
• Development lifecycle: What development lifecycle best describes the

methodology (e.g., waterfall or iterative)?
• Coverage of the lifecycle: What phases of the lifecycle are covered by the
methodology (e.g., analysis, design, and implementation)?
• Development perspective: What development perspective is supported
(i.e., top-down, bottom-up or hybrid)?
• Application domain: Is the methodology applicable to any application
domain (i.e., domain independent) or to a specific domain (i.e., domain
dependent)?
• Size of MAS: To what size of MAS is the methodology suited (i.e., small,
medium, or large MAS)?
• Agent nature: Does the methodology support agents of any architecture,
reasoning mechanism, and/or knowledge representation (i.e., heteroge-
neous agents), or only agents of a particular type (i.e., homogeneous
agents)?
• Support for verification and validation: Does the development process
of the methodology contain rules to allow for the verification and validation
of the correctness of the developed models and specifications?
• Steps in the development process: What are the steps (i.e., tasks and
activities) that the methodology specifies for its development process?
• Models and notational components: What models (and/or notational
components) are generated from each step?
• Definition of inputs and outputs: Are inputs and outputs to each process
step defined?
• Ease of understanding of the process steps: Are the process steps easy
to understand?
• Usability of the methodology: Are the process steps easy to follow?
• Refinability: Do the process steps provide a clear path for refining the
methodology’s models through gradual stages to reach an implementation
or, at least, for clearly connecting the implementation level to the design
specification?
• Approach towards MAS development: What is the methodology’s:
a. generic MAS development approach (e.g., OO approach or knowl-
edge-engineering approach)?
b. approach towards using “role” in MAS development? Does the
methodology employ the concept of “role” in MAS analysis and
design? If so, what is the approach to the identification of roles (e.g.,
goal-oriented approach, behaviour-oriented approach, or organiza-
tion-oriented approach)?
TEAM LinG
Figure 1. Structure of the evaluation framework
Fe ature Analysis Framework

Process Related Supportive Feature
Criteria Technique Related Model Related Criteria
Criteria Criteria
considered, while the latter presents various agent-oriented and MAS-specific

aspects for assessment. We have also added several evaluation criteria that are
not yet included in existing frameworks, for example, “approach towards MAS
development,” “support for mobile agents,” and “support for ontology.” A survey
had been conducted to substantiate the relevance of the proposed criteria and to
make the necessary refinements to the criteria specification.
The structure of the framework is shown in Figure 1. Its criteria are grouped into
four categories:
• Process-Related Criteria: evaluating an AOSE methodology’s develop-

ment process.
• Technique-Related Criteria: assessing the methodology’s techniques to
perform development steps and/or to produce models and notational
components.
• Model-Related Criteria: examining the capabilities and characteristics of
the methodology’s models and notational components.1
• Supportive-Feature Criteria: evaluating a variety of high-level method-
ological capabilities.
This structure highlights the framework’s attention to all three major components
of a system development methodology—process, models, and techniques.
Each evaluation criterion is accompanied by one or more questions to guide and
assist the evaluator. A detailed specification of the criteria is presented below.
Process-Related Criteria
Process-Related Criteria look at the applicability of the methodology, the steps

provided for its development process, and the development approach followed
by the methodology.
TEAM LinG
346 Tran & Low
the quality of notational components, and the agent characteristics supported by

the models.
• Concepts: What concepts are the methodology’s models capable of

expressing/capturing?
• Completeness/Expressiveness: Are the models of the methodology ca-
pable of representing the system from different perspectives, capturing all
necessary aspects such as static and dynamic aspects, and system- and
agent-level aspects?
• Formalization/Preciseness of notational components:
a. Are syntax and semantics of the notational components clearly
defined?
b. Are examples of the notational components presented?
• Model derivation: Do explicit process and guidelines exist for transform-
ing models into other models or for partially creating a model from
information present in another model?
• Consistency:
a. Are there rules and guidelines to ensure consistency between the
levels of abstractions within each model (i.e., internal consistency)
and between different models?
b. Are models represented in a manner that allows for consistency
checking between them?
• Complexity:
a. Is there a manageable number of concepts expressed in each model/
notational component?
b. Are the notational components notation semantically and syntacti-
cally simple?
• Ease of understanding of models: Are the models and notational compo-
nents clear and easy to understand?
• Modularity: Does the methodology and its models promote modularity in
the design of agents and the system?
• Abstraction: Does the methodology allow for producing models at various
levels of detail and/or abstraction?
• Autonomy: Can the models support and represent the autonomous feature
of agents (i.e., the ability to act without direct intervention of humans or
others, and to control their own states and behaviour)?
TEAM LinG
Since different evaluators may use different terms and/or descriptions of the
steps expected from an AOSE methodology, it was deemed advisable to provide
a “standard” framework of process steps that serves as an assessment
checklist for the criterion “Steps in the development process.” This framework
would provide a means of ensuring consistency not only between different
evaluators of the same methodology but also for the comparative analysis of
different methodologies.
To date, no study has been found that identifies this “standard” framework of
steps. We investigated the development process of the existing AOSE method-
ologies. We extracted the major steps from each development process and
synthesize them into a coherent super list. To verify the validity of our
recommended steps, we conducted a survey of experts for their opinions on the
importance of these steps. The survey confirmed the importance of all the
proposed steps to the development of MAS.
The proposed list of AOSE steps is used in Tables 2a to 2j (in the section
“Comparison regarding Steps and Techniques Related Criteria”) as a “yard-
stick” for evaluating and comparing the 10 methodologies in terms of the
criterion, “Steps in the development process.”
Technique-Related Criteria
Technique-Related Criteria assess the availability and usability of the techniques

provided by a methodology for the execution of its process steps and/or for the
development of its models and notational components.
• Availability of techniques and heuristics:

a. What are the techniques used to perform each process step?
b. What are the techniques used to produce each model and notational
component (i.e., modelling techniques)?
• Ease of understanding of techniques: Are the techniques easy to
understand?
• Usability of techniques: Are the techniques easy to follow?
• Provision of examples: Are examples of the techniques provided?
Model-Related Criteria
Model Related Criteria evaluate the various aspects of a methodology’s models

and notational components, including the concepts represented by the models,
TEAM LinG
• Adaptability: Can the models support and represent the adaptability

feature of agents (i.e., the ability to learn and improve with experience)?
• Cooperative behaviour: Can the models support and represent the
cooperative behaviour of agents (i.e., the ability to work together with other
agents to achieve a common goal)?
• Inferential capability: Can the models support and represent the inferen-
tial capability feature of agents (i.e., the ability to reason and act on abstract
task specifications)?
• Communication ability: Can the models support and represent a “knowl-
edge-level” communication ability (i.e., the ability to communicate with
other agents with language resembling human-like speech acts)?
• Personality: Can the models support and represent the personality of
agents (i.e., the ability to manifest attributes of a “believable” human
character)?
• Reactivity: Can the models support and represent the reactivity of agents
(i.e., the ability to selectively sense and act in a timely manner)?
• Temporal continuity: Can the models support and represent temporal
continuity of agents (i.e. persistence of identity and state over long periods
of time)?
• Deliberative behaviour: Can the models support and represent the
deliberative behaviour of agents (i.e., the ability to decide in a deliberation,
or proactiveness)?
• Concurrency: Can the models support and represent the concurrency in
agent processing (e.g., achievement of concurrent goals or participation in
concurrent interactions)?
• Human Computer Interaction: Do the models represent human users and
the user interface?
• Models Reuse: Does the methodology provide, or make it possible to use,
a library of reusable models?
Among the 21 Model-Related Criteria, “concepts” is the most complicated

criterion, since different evaluators may have different descriptions of the
concepts modelled by the same AOSE methodology. As such, an evaluator
would appreciate the existence of a “standard” framework of AOSE concepts
that serves as an assessment checklist for the evaluation.
Similar to the “standard” framework of steps in the “Process Related Criteria”
section, the research determined a set of concepts that are commonly modelled
by AOSE methodologies, and conducted a survey of AOSE practitioners and
TEAM LinG
348 Tran & Low
experts 2 to confirm the importance of the proposed concepts to the MAS

development process.
The proposed list of concepts is used in Table 4 (section “Comparison regarding
Model Related Criteria”) as a “yardstick” for evaluating and comparing the 10
methodologies in terms of criterion “concepts.”
Supportive-Feature Criteria
Supportive-Feature Criteria assess the various high-level, supplementary fea-

tures of an AOSE methodology. The features considered include the availability
of software tools and the support for ontology, mobile agents, and open systems.
• Software and methodological support: Is the methodology supported by

tools and libraries?
• Open systems: Does the methodology provide support for open systems
(i.e., open systems that allow for dynamic addition/removal of agents)?
• Dynamic structure: Does the methodology provide support for dynamic
structure (i.e., the methodology allows for dynamic reconfiguration of the
system)?
• Agility and robustness: Does the methodology provide support for agility
and robustness (e.g., the methodology captures normal processing and
exception processing, provides techniques to analyze system performance
for all configurations, or provides techniques to detect and recover from
failures)?
• Support for conventional objects: Does the methodology provide support
for the use/integration of conventional objects in an MAS (e.g., the
methodology addresses how objects can be used in an MAS and how agents
can interface with these objects)?
• Support for mobile agents: Does the methodology provide support for the
use/integration of mobile agents in a MAS (e.g., the methodology models
which/when/how agent should be mobile)?
• Support for ontology: Does the methodology provide support for the use
and specification of ontology in an MAS (i.e., ontology-based agent
systems)?
TEAM LinG
Comparative Analysis
Comparison Regarding Process-Related Criteria
In this section, the 10 AOSE methodologies are evaluated and compared using
the set of Process-Related Criteria listed in section “Process Related Criteria,”
except for criteria “Steps in the development process,” “Models and nota-
tional components,” and “Definition of inputs and outputs,” which will be
discussed alongside the Technique-Related Criteria in the section entitled,
“Comparison regarding Steps and Techniques Related Criteria.” The results of
the comparative analysis are summarised in Table 1.
The 10 methodologies either adopt a formally defined, prominent development
lifecycle (e.g., ADELFE, RAP, MESSAGE, and INGENIAS) or informally
describe their lifecycle paradigm (e.g., GAIA, TROPOS, PROMETHEUS, and
MASE). In both cases, the development process of all methodologies involves
a high degree of iteration within and/or across the development phases.
INGENIAS is found to provide the best support for refinability, as all of its
models are incrementally refined and expanded throughout the Analysis and
Design phases to reach an implementation. All other methodologies develop
different models during different phases of their development process. How-
ever, they all provide a path or, at least, encourage the need for refining these
models within the corresponding phase.
With regard to the generic MAS development approach (i.e., Part a. of the
criterion “Approach towards MAS development”), most methodologies follow
the object-oriented-based approach (denoted as “OO”); that is, they take
inspiration from the OO paradigm and seek to adapt or extend the conventional
OO approaches and techniques (e.g., use cases, interaction protocol modelling,
and design patterns) and/or OO modelling notation (e.g., UML and OMT)
(Iglesias, Garijo, &Gonzalez, 1999). MAS-CommonKADS is the only method-
ology that adopts the knowledge-engineering-based approach (denoted as
“KE”), meaning it borrows techniques from the knowledge-engineering litera-
ture. TROPOS is an exception because it is built upon the i* modelling
framework developed by Yu (1995).
Regarding the approach towards using “role” in MAS development (i.e., Part
b. of the criterion “Approach towards MAS development”), we classified an
AOSE methodology as non-role-oriented (“NRO”) if it does not involve the use
of the concept “role” anywhere in the MAS development process. A role-
oriented (“RO”) methodology, on the other hand, employs “role” as a major
modelling concept. For RO methodologies, we identified the approach used by
TEAM LinG
MAS-
GAIA TROPOS PROMETHEUS PASSI ADELFE MASE RAP MESSAGE INGENIAS
COMMONAKADS
Iterative within Iterative across

Unified
each phase but and within all Rational
Development Iterative and Cyclic risk-driven Iterative across all Iterative across all software
sequential phases (except Unified Process RUP RUP
lifecycle incremental process phases phases development
between for coding and (RUP)
process
phases deployment)
350 Tran & Low
Analysis, Analysis, Analysis,

Coverage of Analysis and Analysis and Analysis and Analysis and Analysis and Analysis and
Analysis and Design Design and Design and Design and
the lifecycle Design Design Design Design Design Design
Implementation Implementation Implementation
Development Top-down Top-down Hybrid Bottom-up Bottom-up Top-down Top-down Hybrid Hybrid Hybrid
perspective
Dependent –
Independent Independent
Dependent - Independent distributed
Independent Independent Independent (network (collaborative
adaptive (distributed organizational
(business (e-business Independent (distributed management, information
Independent systems planning, database IS
Application process systems, ( holonic robotics operational filtering,
(Flight reservation, (adaptive integration system, (supply chain
domain management, knowledge manufacturing, applications, support systems, personal
automatic control) intranet system, computer virus management,

GIS, traffic management, online bookstore) online knowledge computer
timetabling immune system, enterprise
simulation) health IS) bookstore) management management,
system) automatic control ) resource
systems) robot battles)
planning)
Not specified, Not specified, Not specified,
<= 100 agent Not specified, but
Size of MAS Not specified Any size Not specified but possibly any <= 10 agent classes Any size but possibly any but possibly any
classes possibly any size
size size size
Not specified but
BDI-like Agents with
Agent nature Heterogeneous Heterogeneous BDI-like agents Heterogeneous Adaptive possibly Reactive agents Heterogeneous
agents goals and states
heterogeneous
Support for Mentioned but no

Mentioned as
explicit
verification No Yes Yes Yes Yes Yes No future Yes
steps/guidelines
and validation enhancement
provided
Ease of
understanding High High High High High High High High High High
of the process
steps
Table 1. Comparison regarding process-related criteria
Usability of the Medium Medium Medium High High High High Medium Medium High
methodology
Refinability Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
Approach a. i*
a. OO a. KE a. OO a. OO a. OO a. OO a. OO a. OO a. OO
modelling
towards MAS b. RO (OrO) b. NRO b. NRO b. RO b. NRO b. RO (GO) b. RO b. RO b. RO
framework
(GO and BO)
development b. NRO
TEAM LinG
the methodologies to identify roles (cited within parentheses in Table 1). Three
potential approaches for role identification are:
• Goal-Oriented approach (“GO”), where roles are identified from the

analysis of system goals;
• Behaviour-Oriented approach (“BO”), where roles are derived from low-
level system behaviours and tasks; and
• Organization-Oriented approach (“OrO”), where roles are revealed from
system organizational structure.
Comparison Regarding Steps and Techniques-Related

Criteria
In this section, the 10 methodologies are compared according to the four

Technique- Related Criteria (presented in the section of the same name) and the
three remaining Process- Related Criteria (i.e., “Steps in the development
process,” “Models and notational components,” and “Definition of inputs
and outputs”). The evaluation of techniques is coupled with the assessment of
each step and each model because techniques are typically provided in conjunc-
tion with steps and models.
Tables 2a to 2j present our evaluation findings for each of the 10 AOSE
methodologies. The columns represent the evaluation criteria, except for the first
column, which lists a set of “Steps” that serve as an assessment checklist. These
steps have been mentioned in the “Process-Related Criteria” section as the
“standard” steps for the MAS development process.
It should be noted that these steps are not presented in any order. Different
methodologies may perform the steps in different chronological order and in
different phases. If a methodology is found to support a particular step, this
support is denoted as either Explicit (“E”) or Implicit (“I”). The former applies
if the methodology specifies the step as a significant, distinct activity in its
development process. The latter incurs when the step is implicitly fulfilled as part
of another step or only briefly mentioned by the methodology. If a step is implicit,
there may not be sufficient information for us to evaluate the remaining
Technique-Related Criteria, such as “Availability of techniques [for step]” or
“Usability of techniques [for step]” (these fields are therefore left blank). If a
step is supported in conjunction with (or as part of) another step, this other step
will be indicated in the square brackets []. If an AOSE methodology contains a
significant step that is not included in the list, this step will be added as an “Extra”
item at the bottom of the list.
TEAM LinG
352 Tran & Low
Table 2a. Evaluation of GAIA steps and techniques
GAIA
for modelling
understanding
components?
Supported?
Examples
Techniques
Techniques
Notational
Ease of
Outputs?
Usability
Steps
Models/
for step
Inputs/
1. Identify system goals
2. Identify system Specified as “liveness Each liveness responsibility is
tasks/behaviour I [4] Role model O responsibilities” of roles made up of “actions” and/or H M Y
“protocols”
3. Specify use case scenarios
4. Identify roles Identify roles from individuals, Model each role by its
departments/offices or sub- “responsibilities” (including
E Role model B H H Y
organizations in the target system “liveness” and “safety”) and
“permissions”
5. Identify agent classes Agent model Typically one-to-one mapping Show identifier of agent classes
E B H H Y
between roles and agent classes and their respective roles
6. Model domain
conceptualization
7. Specify acquaintances Acquaintance Identify acquaintances from Role, Show agent classes and
between agent classes E model B Agent and (inter-role) Interaction communication paths between H M Y
models them
8. Define interaction Only specifies protocols for inter- Specify purpose, initiator,
protocols role interactions. Each protocol responder, inputs, outputs and
Interaction defines an institutionalized (informal) processing description
E O H H Y
model pattern of interaction with no for each inter-role protocol
detailed sequences of exchanged
messages
9. Define content of
exchanged messages
10.Specify agent
architecture
11.Define agent mental
attitudes (e.g. goals, beliefs,
plans, commitments …)
12.Define agent behavioural Identify agents’ services by Show inputs, outputs, pre-
interface (e.g. capabilities, analyzing their roles’ condition, and post-condition for
E Service model B H H Y
services, contracts…) responsibilities, actions and each agent’s service
protocols.
13.Specify system
architecture (i.e. overview of
all components and their
connections)
14.Specify organizational Choose a structure that optimizes Specify organizational
structure/control the organizational efficiency and dependencies between roles
regime/inter-agent social Organizational simplicity, respects
E B H H Y
relationships structure model organizational rules, and reflects
the structure of real world
organization.
15.Model MAS environment Identify abstract computational Specify a symbolic name, types
(e.g. resources, facilities, Environmental resources (e.g. tuples/variables) of actions permitted on each
E B H M Y
characteristics) model that are available to agents for environmental resource and their
sensing, effecting or consuming textual/structural descriptions
16.Specify agent- Implicitly indicates that agents
environment interaction interact with environment via
I[15]
mechanism sensors and affectuators. No
additional information provided
17.Specify agent inheritance Aggregation occurs when an Show an aggregate agent class as
and aggregation agent class is composed of the the parent of the children classes
I[5] Agent model B roles that make up other agent in the tree structure of Agent H H N
classes. Does not consider model
inheritance
18.Instantiate agent classes Specify numbers of instances for
E [5] Agent model O each agent class by annotating the H M Y
class with qualifiers from Fusion
19.Specify agent instances
deployment
Extra: Specify Identify rules that must be Model safety and liveness
organizational rules respected by the organization for organizational rules
Organizational it to work coherently, and specify
E rules B how the dynamics of the H H Y
specifications organization should evolve over
time. Can refer to roles’ safety
and liveness responsibilities.
Extra: Identify initial sub- At the beginning of Analysis,
organizations determine whether multiple
E B organizations have to co-exist in H H Y
the system and become
autonomous interacting MASs
TEAM LinG
Table 2d. Evaluation of PROMETHEUS steps and techniques
PROMETHEUS
for modelling
components?
Supported?
understanding
Examples
Techniques
Techniques
Notational
Outputs?
Usability
Steps
Models/
for step
Ease of
Inputs/
1. Identify system goals Capture initial goals from high-level
E Goal diagram B system description and decompose H H Y
these goals into subgoals
2. Identify system tasks/ Identify a set of functionalities by Describe each functionality in
behaviour Functionality considering groupings of goals. terms of its goals, actions,
E B H H Y
descriptor percepts/events and potential data
read/written
3. Specify use case scenarios Identify sequences of steps that
Use case Annotate each step with associated
E B describe how the system achieves a H H Y
descriptor functionality and data read/written
goal or responds to an event
4. Identify roles
5. Identify agent classes Assign functionalites to agent class Describe each agent class in terms
Agent class based on the criteria of strong of its functionalites, goals, events,
E B H H Y
descriptor coherence and loose coupling actions, and data read/written,
cardinality, agent lifetime).
6. Model domain
conceptualization
7. Specify acquaintances Whenever there is a step in a use case Show the core interaction channels
between agent classes that involves functionality from a between agents using sequence
Interaction new agent, there must be an diagrams
E B H H Y
diagrams interaction pathway from a
previously involved agent and this
new agent
8. Define interaction protocols Elaborate each complex interaction Show all variations of interaction
Interaction with protocol by analyzing use case sequences that are valid in the
E[7] B H H Y
protocols scenarios system. Each protocol may be split
into smaller chunks
9. Define content of exchanged Interaction Analyze use case scenarios
I
messages diagrams and B H L Y
[7, 8]
protocols
10.Specify agent architecture Agent Show the top-level view of an
overview agent’s internals, including top-
E diagram B level capabilities, events H H Y
connecting these capabilities, and
data objects internal to the agent
11.Define agent mental attitudes Recursively decompose each agent’s Describe each agent “plan” in
Plan
(e.g., goals, beliefs, plans, capability (step 12) into plans, events terms of input/output events,
descriptor,
commitments …) E[12] B connecting plans, data read/written actions and messages. Describe H H Y
Data
by plans and sub-capabilities. each “data object” used by the
descriptor
agent with fields and methods.
12.Define agent behavioural Identify agent “capabilities” by Describe each capability in terms
interface (e.g., capabilities, Capability analyzing functionalities assigned to of subcapabilities, plans, events
E B H H Y
services, contracts…) diagram the agent and data read/written in Capability
diagram
13.Specify system architecture Describe how the system as a whole Show an overview of all agent
(i.e. , overview of all components System will function classes in the system, messages
and their connections) E overview B connecting classes, shared data H H Y
diagram objects and percepts/actions with
the environment
14.Specify organizational
structure/control regime/inter-
agent social relationships
15.Model MAS environment System There may be data objects existing in Show and link shared data objects
(e.g., resources, facilities, E overview O the environment that must be shared to agents in System overview H M Y
characteristics) diagram among agents (e.g. , databases) diagram
16.Specify agent-environment Percepts Specify raw data available to the Specify percepts and actions for
interaction mechanism descriptor, system as “percepts” and activities each system functionality in
E B H H Y
Actions performed by the system on the Percepts and Actions descriptors
descriptor environment as “actions”
17.Specify agent inheritance and
aggregation
18.Instantiate agent classes Agent class Specify cardinality for each agent
I[5] O H L N
descriptor in its Agent class descriptor
deployment
TEAM LinG
Table 2b. Evaluation of TROPOS steps and techniques
TROPOS
for modelling
components?
Supported?
understanding
Examples
Techniques
Techniques
Notational
Outputs?
Usability
Steps
Models/
for step
Ease of
Inputs/
1. Identify system goals In Early Requirements, identify goals Show goal dependencies among
and softgoals of stakeholders, and stakeholders and system in Actor
Actor
perform means-end analysis to diagram. Show how goals can be
diagram,
E B determine how these goals can be fulfilled (through subgoals, tasks, H H Y
Rationale
fulfilled. In Late Requirements, focus and goal/task/resource
diagram
on the target system and how it can dependencies) in Rationale
fulfil the assigned goals. diagram.
2. Identify system Perform means-end analysis to Show task dependencies among
Actor
tasks/behaviour identify tasks to achieve goals during stakeholders and system in Actor
diagram,
E[1] B both Early and Late Requirements diagram. Show how goals are H H Y
Rationale
achieved through tasks in
diagram
Rationale diagram.
4. Identify roles
5. Identify agent classes Depending on the chosen Show sub-actors within each
organizational structure (step 14), system actor and
decompose the system into subgoal/task/resource dependencies
Actor actors, each of which can be among them
E B H H Y
diagram recursively refined into sub-actors
(can consult catalogues of agent
patterns for this activity). Assign sub-
actors to agents.
6. Model domain
conceptualization
7. Specify acquaintances Sequence Identify interactions between agents
between agent classes diagrams, to fulfil particular tasks
E B H M Y
Collaboration
diagrams
8. Define interaction protocols Elaborate each inter-agent interaction
Sequence in greater detail (e.g., by introducing
E[7] B H H Y
diagrams additional or refined exchanged
messages)
9. Define content of exchanged Model each message as a
I[7,8] H M Y
messages communication act in ACL
10.Specify agent architecture BDI agent TROPOS adopts BDI model for
I
architecture agent architecture
11.Define agent mental attitudes Define agent’s “plans” to achieve a Specify Plan diagrams at a directly
Plan
(e.g., goals, beliefs, plans, goal, perform a task, or respond to a executable level. Represent
diagrams,
commitments …) E B (communicative) event. Identify resource entities as component H M Y
Agent class
resource entities that are incorporated classes of an agent class in Agent
diagram
in the agent’s knowledge base class diagram
12.Define agent behavioural
interface (e.g., capabilities,
services, contracts…)
13.Specify system architecture
(i.e., overview of all components
and their connections)
14.Specify organizational Select a suitable organizational Specify how well each alternative
Non-
structure/control regime/inter- structure style (e.g., from the set organizational structure style
functional
agent social relationships E B proposed by TROPOS) by evaluating fulfils the system’s softgoals H H Y
requirement
its quality attributes against the
model
system’s softgoals.
15.Model MAS environment Model environment via
(e.g., resources, facilities, Actor stakeholders and their goal/
I[1,2] B H H Y
characteristics) diagram task/resource dependencies with
the system
16.Specify agent-environment
interaction mechanism
aggregation
18.Instantiate agent classes
deployment
Extra: Implementation Generate BDI agents by mapping
agent’s resources, goal/softgoal, and
plans onto BDI agent belief, desire,
E BDI agents B and intentions, which can in turn be H H Y
directly implemented by JACK
database relations, Goal Event, and
Plans.
TEAM LinG
356 Tran & Low
Table 2e. Evaluation of PASSI steps and techniques
PASSI
for modelling
components?
Supported?
understanding
Examples
Techniques
Techniques
Notational
Outputs?
Usability
Steps
Models/
for step
Ease of
Inputs/
2. Identify system Follow standard requirements Specify functionality as use cases in Use
System
tasks/behaviour elicitation techniques in OO or case diagrams
E requirements O
scenario-based teleological
model
methods such as GBRAM
3. Specify use case scenarios System Develop a hierarchical series of use case
E[2] requirements B diagrams. The uppermost serves as a H H Y
model context diagram
4. Identify roles Identify roles for each agent by For each inter-agent interaction scenario,
exploring all the possible develop a Role identification diagram to
System scenarios of inter-agent specify the roles that agents play during
requirements interaction (captured in Agent the interaction. Describe roles with a
E model, Agent B identification diagram – step 5) Role description diagram, which shows H H Y
society their agents, role changes within an
model agent, roles’ tasks, roles’ interactions and
dependencies.
5. Identify agent classes System Package use cases into agents Show agents, their respective use cases,
E requirement B and interaction paths between use cases H M Y
model in Agent identification diagram
6. Model domain Specify concepts/entities that Represent domain ontology as an XML
Agent society
conceptualization E O define the domain’s schema or class diagram in Domain H M Y
model
knowledge. ontology diagram
7. Specify acquaintances System Agent acquaintances are reflected via the
between agent classes I[5] requirement B interaction paths between use cases in H H Y
model Agent identification diagram
8. Define interaction protocols Select and refine protocol for Document each protocol in Protocol
each agent acquaintance by description diagram (which may be
Agent society consulting e.g., FIPA library. AUML sequence diagram). Specify
E B H H Y
model Should also specify the identifier of protocol and ontology for
ontology used with the each agent acquaintance in
protocol Communication ontology diagram.
9. Define content of Specify messages’ Model exchanged messages (including
exchanged messages performatives as required by their performatives and contents) as
Agent
the interaction protocol (step transitions between agents in the Multi-
I implementati B H H Y
8), and messages’ contents by agent behaviour description diagram
on model
using concepts defined in
Domain ontology diagram.
10.Specify agent architecture Define agent structure as being Specify data structures and methods of
Agent composed of one main agent the agent and its tasks in the main agent
E implementati B class and a set of inner classes, class and task classes respectively. H H Y
on model each representing a task of the
agent
11.Define agent mental Agent Specify agent “knowledge” by Model knowledge as agent data
attitudes (e.g. , goals, beliefs, implementati using the concepts defined in structures in Single-agent structure
I[10] B H M Y
plans) on model Domain ontology diagram definition diagram
(step 6)
12.Define agent behavioural System Agent’s capabilities are Show all tasks of an agent in a Task
interface (e.g., capabilities, requirements represented by its tasks, which specification diagram. Further describe
services) model, Agent can be identified by analyzing each method required to achieve each
E B H H Y
implementati its roles and interactions task in Single-agent behaviour
on model described in Role identification description (using flow charts, state
diagrams (step 4) diagrams or text description)
13.Specify system architecture Agent Show all agent classes, their knowledge,
E implementati B tasks and connections with external H H Y
on model actors in Multi-agent structure diagram
structure/inter-agent social
relationships
15.Model MAS environment
17.Specify agent inheritance
and aggregation
19.Specify agent instances Show processing units, agents in each
deployment Deployment unit, agent movements, and units/agents
E O H L N
model connections in Deployment configuration
diagram.
Extra: Code reuse, code Try to reuse predefined
E Code model B H M N
completion patterns of agents and tasks
TEAM LinG
354 Tran & Low
Table 2c. Evaluation of MAS-COMMONKADS steps and techniques
MAS-COMMONKADS
for modelling
components?
Supported?
understanding
Examples
Techniques
Techniques
Notational
Outputs?
Usability
Steps
Models/
for step
Ease of
Inputs/
1. Identify system goals Perform responsibility/goal-driven Describe each goal with type,
analysis during Conceptualization activiation/deactivation condition and
E Goal case B H H Y
phase to identify responsibilities success/failure condition.
(goals) of the system
2. Identify system Decompose tasks following a top- Show tasks in an and/or tree. Describe
tasks/behaviour down approach each task in terms of inputs, outputs,
E Task model O H H N
task structure, required capabilities of
performer and preconditions.
3. Specify use case scenarios Perform user-centered analysis
during Conceptualization phase to
E Use case B Conventional OO techniques H H Y
identify potential users and how the
system processes a user request
4. Identify roles
5. Identify agent classes Analyze various sources e.g., use Describe each agent in terms of type,
cases, statement problems, role, position, description, services,
heuristics, initial Task and Expertise goals, plans, knowledge, collaborates,
E Agent model B H M Y
models skills, reasoning capabilities, general
capabilities norms, preferences and
permissions.
6. Model domain Specify domain conceptualization as Represent concepts, properties,
E Expertise
conceptualization O agent’s domain knowledge expressions and relationships in the H M Y
[11] model
domain using e.g. class/object diagrams
7. Specify acquaintances Identify prototypical conversations Model conversations by using Message
between agent classes between agents by analyzing the Sequence Charts and Event flow
Coordination
E B results of techniques used for diagrams H H Y
model
identifying agents (e.g., use cases,
heuristics, task model, CRC cards).
8. Define interaction protocols Identify protocols for complex Model protocols using high level
Coordination conversations by consulting existing Message Sequence Charts. Model the
E[7] B H H Y
model libraries and reuse protocol processing states of an agent during a
definitions protocol using State transition diagrams
9. Define content of Analyze use cases and Expertise Model data interchanged in each
Coordination
exchanged messages E[8] B model interaction in terms of data structures H H Y
model
specified in Expertise model
10.Specify agent architecture Select an appropriate architecture
and map the elements defined in
Coordination, Expertise, Agent and
E Design model B H L N
Task models onto modules of the
architecture. No techniques or
models are discussed
11.Define agent mental Specify domain knowledge, task Describe each type of knowledge in
attitudes (e.g. , goals, beliefs, knowledge, inference knowledge Domain knowledge ontology, Inference
Expertise
plans, commitments …) E B and problem solving knowledge for diagrams, Task knowledge specification H M Y
model
each agent or Problem solving method
diagrams/templates.
12.Define agent behavioural Agent model; Identify services that an agent offers to
interface (e.g., capabilities, I Organization O other agents and document this in Agent H L Y
services, contracts…) model Model and/or Organization Model
13.Specify system architecture Show all agents, objects and their
(i.e. , overview of all Organisation relationships (e.g., inheritance,
E B H M Y
components and their model association, agent-object relationship)
connections)
14.Specify organizational Model organizational relationships are
Organisation
structure/control regime/inter- I as association relationships annotated H L Y
model
agent social relationships with roles (of each involved agent)
15.Model MAS environment Perform environment-centered Describe the reaction cases coming from
(e.g. , resources, facilities, analysis during Conceptualization interaction of agents with objects in the
characteristics) phase to identify objects in the environment
Reaction
environment and potential events
cases;
E B coming from each object and actions H M N
Design model
performed by agents on each object.
Identify networking, knowledge and
coordination facilities.
17.Specify agent inheritance Specify aggregation relationships for
and aggregation agent groups, and inheritance
E Organisation
B relationships for agents that inherit H M Y
[13] model
from the values of the precedent
agents
18.Instantiate agent classes I Organisation Mentioned but no techniques Develop organization model for both
O H L N
[13] model discussed agent classes and agent instances
deployment
TEAM LinG
Table 2f. Evaluation of ADELFE steps and techniques
ADELFE
for modelling
components?
Supported?
understanding
Examples
Techniques
Techniques
Notational
Outputs?
Usability
Steps
Models/
for step
Ease of
Inputs/
2. Identify system tasks/ Use case Identify the different functionality the Express each functionality as a
E[3] O H H Y
behaviour model system has to carry out use case
3. Specify use case scenarios Apart from identifying use cases, need to
Use case
E B also highlight the possible cooperation Conventional OO techniques H H Y
model
failures in the identified use cases
4. Identify roles
5. Identify agent classes First, decompose system into entities. Show entities and their
Determine which entities fit to be agents, relationships in Preliminary
i.e., whether they are autonomous, goal- class diagram. Update this
Software
directed, dynamic, and need to deal with diagram to indicate which
E architecture B H H Y
unpredictable events. If an agent needs to classes are agents
document
be adaptive/evolving, it should be
decomposed into a collective of sub-
agents.
6. Model domain
conceptualization
7. Specify acquaintances Software Identify potential interaction Model interaction relationships
between agent classes architecture relationships between agents, and also with sequence diagrams or
E B H M Y
document between agents and non-agent collaboration diagrams
active/passive entities
8. Define interaction protocols Analyze each use case (step 4) and Elaborate each interaction
interaction scenarios (step 7) relationship with a protocol
Interaction
diagram that specifies
E languages B H M Y
information exchanges
document
between agents and between
agents and non-entities
9. Define content of Interaction As above. Also select the communication
exchanged messages E[8] languages B languages for specifying the messages H M Y
document
10.Specify agent architecture Agent architecture should contain 5 Model each agent in terms of
Detailed
components: representations, social the 5 listed components
E architecture O H H Y
attitudes, interaction languages,
document
aptitudes, and skills
11.Define agent mental “Representations” are agent’s beliefs Specify attributes and methods
attitudes (e.g. , goals, beliefs, about itself and environment. “Social for agent’s representations.
plans, commitments …) Detailed attitudes” contain rules for dealing with Select protocols for agent’s
E architecture B non-cooperative situations. “Interaction interaction languages from the H H Y
document languages” involve protocols used by the set defined in step 8. Specify
agent. non-cooperative situations and
rules for cooperative attitudes.
12.Define agent behavioural Detailed “Skills” are capabilities that an agent Specify methods and/or
interface (e.g., capabilities, E architecture B brings to its collective. “Aptitudes” are attributes for agent’s “skills” H M Y
services, contracts…) document agent’s capabilities on its knowledge. and “aptitudes”
13.Specify system architecture Define the system architecture in terms Generate a Class diagram for
Detailed
(i.e. , overview of all of packages and classes (of agents and each package
E architecture H H Y
components and their objects). Should use design patterns
document
connections) and/or re-usable components
15.Model MAS environment Identify active and passive entities in the
(e.g. , resources, facilities, Environment environment; characterize the system’s
characteristics) E definition B environment as being accessible or not, H H Y
document deterministic or not, static or dynamic,
and discrete or continuous
16.Specify agent-environment Agents interact with environment via
Detailed
interaction mechanism percepts and actions, implicitly specified
I[10] architecture O H L N
in agents’ “skills”, “aptitudes” and
document
“interactions”.
17.Specify agent inheritance Detailed Show aggregation relationships
I[13]
and aggregation architecture O between agents in Class H M Y
document diagrams
deployment
Extra: Elaborate and validate Specify the GUIs through which users Use any basic drawing tools
UI prototypes E UI prototype B will interact with the systems, and H M Y
relationships between GUIs
Extra: Code reuse, code Investigate (at the global level) whether a Answer a number of questions
completion AMAS is required to implement the regarding both levels
AMAS
E B system, and (at the local level) whether H H Y
adequacy test
some agents are needed to be
implemented like AMAS
TEAM LinG
358 Tran & Low
Table 2g. Evaluation of MASE steps and techniques
MASE
for modelling
components?
Supported?
understanding
Examples
Techniques
Techniques
Notational
Outputs?
Usability
Steps
Models/
for step
Ease of
Inputs/
1. Identify system goals Analyze initial system Hierarchically organize goals in
Goal hierarchy specifications, e.g., technical the order of importance. All
E B H H Y
diagram documents, user stories and use subgoals should relate functionally
cases. to their parent.
2. Identify system tasks/ Extended role Identify tasks that each role should Attach tasks to roles in Extended
E [4] B H H Y
behaviour diagram perform to achieve goals role diagram
3. Specify use case scenarios Use case
E B Conventional OO techniques Conventional OO techniques H H Y
diagrams
4. Identify roles Typically one-to-one mapping Show roles, their related goals and
E Role diagram B between goals and roles communication paths between H H Y
roles
5. Identify agent classes Agent class Group roles into agent classes Show agent classes, related roles,
E B H H Y
diagram and acquaintances between agents
6. Model domain
conceptualization
7. Specify acquaintances Any communication paths between
between agent classes I Agent class 2 roles indicate acquaintances
B H H Y
[5] diagram between their respective agent
classes
8. Define interaction protocols Specify conversations between Produce a Communication class
Communication agents by analyzing inter-role diagram (which is a finite state
E B H H Y
class diagrams interactions in use cases, and task machine) for each participant in
descriptions in Task state diagrams the conversation
9. Define content of Analyze inter-role interactions in Model messages as transitions
exchanged messages Communication use cases, and task descriptions in between states in Communication
E[8] B H H Y
class diagrams Task state diagrams class diagram. Specify
performatives and parameters
10.Specify agent architecture Agent class Refer to the work of Robinson Refer to the work of Robinson
E architecture O (2000) (2000) H M Y
diagram
11.Define agent mental Specify how a role/agent can fulfil Depict the task processing as a
attitudes (e.g. ,goals, beliefs, a task with a structured set of finite state machine
Task state
plans, commitments …) I[4] B activities and communications. H M Y
diagram
This implicitly represents an
agent’s plan for achieving tasks.
(i.e. ,overview of all
components and their
connections)
(e.g. ,resources, facilities,
characteristics)
and aggregation
18.Instantiate agent classes Deployment Similar to instantiating objects Show numbers and types of agents
E B H H Y
diagram from object classes
19.Specify agent instances Consider message traffic between Show locations of agents (e.g.,
deployment E Deployment agents and processing power hostname and address)
B H H Y
[19] diagram available on particular machines
and required by particular agents
TEAM LinG
Table 2h. Evaluation of RAP steps and techniques
RAP
for modelling
components?
Supported?
understanding
Examples
Techniques
Techniques
Notational
Outputs?
Usability
Steps
Models/
for step
Ease of
Inputs/
1. Identify system goals Goal-based Define goal for each type of activity Document the goals for each actor
E[2] use case B performed by agents (see step 2) in each goal-based use case. H H Y
Model
2. Identify system tasks/ Identify the types of activities to be Model each activity type with a
Goal-based
behaviour performed by each agent goal-based use case, which is later
E use case B H H Y
elaborated with an activity
Model
diagram.
3. Specify use case scenarios Develop a use case for each
Goal-based activity type of agent, specifying
E[1,2
use case B the involved agents, their goals, H H Y
]
Model trigger event, and actions of the
primary agent.
4. Identify roles Show all agent roles and their
I Agent Model O H M Y
respective internal agents
5. Identify agent classes Only define a system entity as an Show all agents in the system and
agent class if it can communicate, their role types
E Agent Model O perceive, act, make commitments and H L Y
satisfy claims. Otherwise, view it as a
passive object class
6. Model domain This model captures all
Information
conceptualization I information objects, thus reflecting
Model
the domain conceptualization
7. Specify acquaintances Agent acquaintances are captured
Interaction
between agent classes E B via communicative action events H M Y
Model
between agents
8. Define interaction protocols
9. Define content of Model exchanged messages as
exchanged messages Interaction communicative action event.
I[7] B H M Y
Model Passing parameters are specified in
the content of messages.
10.Specify agent architecture
11.Define agent mental Information Specify beliefs, commitments and Model agent beliefs as data objects
attitudes (e.g. , goals, beliefs, Model reaction rules for each agent that are shared or owned privately
plans, commitments …) (belief, by the agents. Model each reaction
commitment) rule by specifying the triggering
E Behaviour B event for the reaction and the H H Y
Model output action (i.e., change of
(reaction beliefs/commitments or
rule) performance of an action).

(i.e. , overview of all
connections)
(e.g., resources, facilities,
characteristics)
and aggregation
18.Instantiate agent classes UML
E Deployment O M L N
Diagram
deployment
TEAM LinG
360 Tran & Low
Table 2i. Evaluation of MESSAGE steps and techniques
MESSAGE
for modelling
components?
Supported?
understanding
Examples
Techniques
Techniques
Notational
Outputs?
Usability
Steps
Models/
for step
Ease of
Inputs/
1. Identify system goals Analyze organization chart, company Show a hierarchy of goal
Goal/Task
E B goals description and business processes decomposition in Goal H H Y
model
diagram
2. Identify system tasks/ Identify services that can be performed Describe the flow of tasks to
behaviour Goal/Task by roles to satisfy goals, and tasks that achieve a service in a
E[1] B H H Y
model can be implemented to fulfil these Workflow diagram
services
4. Identify roles Associate roles to goals in
Delegation structure diagram,
Agent /Role
E B and to services and tasks in H M Y
model
Workflow diagrams. Describe
each role with Role Schema
5. Identify agent classes Agent /Role Assign roles to agents based on the Describe each agent with an
model designer’s experience and heuristics Agent Schema and an Agent
E B diagram (which shows the H M Y
associated roles, goals, tasks,
and assessed data sources)
6. Model domain Incrementally add domain concepts and Specify concepts as classes in
Domain
conceptualization E B relations to Domain model as they are UML class diagram H M Y
model
needed in other models
7. Specify acquaintances Specify acquaintances between
Organization
between agent classes E B roles/agents in Organisation H M Y
Model
model.
8. Define interaction protocols Incrementally built from Analysis to May model each protocol with
Design. In Analysis phase, only need to AUML protocol diagrams or
highlight which, why, and when roles UML statechart. Can model
Interaction communicate. In Design phase, elaborate the behaviour of eachagent/role
E B H H Y
model each interaction considering the in a protocol with statecharts
assignment of roles to agents and
implementation of services in terms of
tasks
9. Define content of exchanged Define each message in
Interaction
messages I[8] O appropriate ACL in protocol H L N
model
diagrams.
10.Specify agent architecture Select an architecture that suits the Specify architecture
E B functional requirements of agents (e.g., components/layers, depending H H Y
cognitive versus reactive) on the chosen architecture
11.Define agent mental attitudes Depending on the agent architecture, Model domain entities (for
(e.g. ,goals, beliefs, plans, various categories of knowledge may domain knowledge), social
commitments …) need to be specified, including domain constraints (for social
knowledge, social knowledge and knowledge), and rules,
E B H H Y
behaviour knowledge. These can be objectives, and tasks (for
determined by analyzing the Domain behaviour knowledge)
model, Organization model, and probably using UML notation
Goal/Task model.
13.Specify system architecture System Derive system architecture from Show all system components
(i.e. , overview of all components E[14] architecture B Organization Model as a package structure H H Y
and their connections) diagram
14.Specify organizational Incrementally built from Analysis to Show stakeholders/users,
structure/control regime/inter- Design. Start by analyzing organization agents/roles, resources, sub-
agent social relationships Organization chart and business process organizations and relationships
E B H H Y
model documentation bet them (e.g. , power/peer-to-
peer organizational
relationships, acquaintances)
15.Model MAS environment Identify resources that agents use, control Show resources and their
Organization
(e.g., resources, facilities, I[14] O or receive input from (e.g. , databases, relationships with agents in H L N
model
characteristics) computational resources) Organization model
aggregation
18.Instantiate agent classes Mentioned but no techniques/models
I[5] L L N
provided
deployment
TEAM LinG
Table 2j. Evaluation of INGENIAS steps and techniques
INGENIAS
for modelling
components?
Supported?
understanding
Examples
Techniques
Techniques
Notational
Outputs?
Usability
Steps
Models/
for step
Ease of
Inputs/
1. Identify system goals Identify goals from system Show goals, goal-subgoals
Goals and
E B requirements or objectives associable dependencies and goals-tasks H H Y
Tasks model
to agents associations
2. Identify system tasks/ Derive tasks from system Show tasks, tasks’ pre-conditions,
Goals and
behaviour E[1] B requirements or from goals post-conditions, and goals-tasks H H Y
Tasks model
associations
3. Specify use case scenarios Use case
E O Incrementally identified and refined Conventional OO techniques H H Y
diagrams
4. Identify roles Agent model, Identify roles from the analysis of Show roles as actors of
Organization workflows and tasks in Organization workflows/tasks in Organization
I[5,14
model, B model (step 14) and interactions (step model, as participants in H M Y
,8]
Interaction 8) Interaction model, and associated
model to agents in Agent model
5. Identify agent classes Apply “rationality principle” on Describe each agent in terms of its
E Agent model B system components to identify roles, goals, tasks, mental states, H H Y
agents. and control structure/process.
6. Model domain
conceptualization
7. Specify acquaintances In Analysis phase, identify Show participants (agents/roles)
between agent classes Interaction significant interactions between and goals pursued by each
E B H H Y
model actors (i.e., agents/roles) and initial interaction
schemes of exchanged info.
8. Define interaction protocols In Design phase, elaborate each Specify exchanged elements and
Interaction interaction with detailed description order of their execution (e.g. ,
E[7] B H H Y
model of exchanged elements (e.g., iteration, concurrency, branching)
messages, tuples, method calls)
9. Define content of exchanged For each message, show name of
Interaction
messages E[8] B operation, parameters, guards and H M Y
model
annotation of sequence
10.Specify agent architecture
11.Define agent mental attitudes Determine agent’s “mental states” Represent mental states in terms of
(e.g. , goals, beliefs, plans, from analysis of goals, tasks, and goals, tasks, facts, or any other
commitments …) interactions. Define the “control” of entity that helps in state
E Agent model B agent to assure desired transitions description. Agent goals can be H H Y
between its mental states modelled as initial state. Can
model agent control as algorithms
or complex deliberative process
13.Specify system architecture Implicitly reflected in the
(i.e., overview of all components Organization Organization model where all
I[14] B H H Y
and their connections) model system components and their
connections are shown
14.Specify organizational Incrementally identify and refine the Show how system components are
structure/control regime/inter- org. structure in terms of system grouped, their social dependencies
agent social relationships Organization components (i.e. , agents, roles, (e.g., subordination and client-
E B H H Y
model resources, and applications) and server relations), task/workflow
social dependencies among them assignment, and resources
used/produced.
15.Model MAS environment Identify resources and applications in Model resources and applications
(e.g., resources, facilities, the environment by analyzing system as objects. Specify internal states
Environment
characteristics) E B requirements and agent requirements and operations for applications, H H Y
model
and initial states, category, and
limit of consumption for resources.
16.Specify agent-environment Determine how agents perceive Represent agent’s perception
interaction mechanism outputs of applications in the mechanism as a type of association
Environment
E[15] B environment. Possible perception relationship between the agent and H H Y
model
mechanisms: sampling or notification an application in Environment
model
aggregation
deployment
Extra: Implementation Map the system design components
to concrete components in the
E H H Y
development framework and generate
codes using code-generation tools
TEAM LinG
362 Tran & Low
Table 3. Comparison regarding steps and usability of techniques
COMMONKADS
PROMETHEUS
INGENIAS
MESSAGE
Steps
TROPOS
ADELFE
MASE
PASSI
GAIA
MAS-
RAP
1. Identify system goals H H H H H H H
2. Identify system tasks/
behaviour
M H H H H H H H H H
3. Specify use case scenarios H H H H H H H
4. Identify roles H H H M M M
5. Identify agent classes H H M H M H H L M H
6. Model domain
conceptualization
M M M
7. Specify acquaintances
between agent classes
M M H H H M H M M H
8. Define interaction
protocols
H H H H H M H H H
9. Define content of
exchanged messages
M H L H M H M L M
10.Specify agent architecture L H H H M H
11.Define agent mental
attitudes (e.g. , goals, beliefs, M M H M H M H H H
plans, commitments …)
interface (e.g., capabilities, H L H H M
(i.e. , overview of all
M H H H H H
connections)
structure/control regime/inter- H H L H H
(e.g. , resources, facilities, M H M M H L H
characteristics)
H L H
and aggregation
H M M
18.Instantiate agent classes M L L H L L
deployment
L H
All methodologies are found to specify outputs for their supported steps (denoted
as “O” in the column “Inputs/Outputs”), while most methodologies specify
inputs as well (denoted as “B,” indicating “both”).
The ease of understanding and usability of the steps are evaluated as either
High (“H”), Medium (“M”), or Low (“L”).
We summarize the comparison in Table 3, where only the assessment of the
criterion “Usability of techniques” is shown for each step of the methodolo-
gies.
Comparison Regarding Model-Related Criteria
The assessment of the criterion “Concepts” is presented in Table 4, while the

comparative analysis of other model-related criteria is summarized in Table 5.
TEAM LinG
MAS-
Concepts GAIA TROPOS PROMETHEUS PASSI ADELFE MASE RAP MESSAGE INGENIAS
COMMONAKDS
Actor diagram, Goal hierarchy Goal-based use Goal/Task Goals & Tasks
System goal Goal cases Goal diagram
Rationale diagram diagram case model model model
Actor diagram, Functionality System requirement Extended role Goal-based use Goal/Task Goals & Tasks
System task/behaviour Role model Task model Use case model
Rationale diagram descriptor model diagram case model model model
System requirement Goal-based use
Use case scenario Use cases Use case descriptor Use case model Use case diagram Use case diagram
model case model
System requirement Agent model,
Agent/Role
Role Role model model, Agent society Role diagram Agent Model Organization model,
model
model Interaction model
Domain Information
Expertise model Agent society model Domain model
conceptualization model
Agent class System requirement Detailed architecture Goal-based use
Agent goal/task Actor diagram Agent model Agent model
descriptor model document case model
Agent class Agent/Role
Agent-role assignment Agent model Agent model Agent society model Agent Model Agent model
diagram model
* (can be recorded in
As resources in each Agent
Agent Detailed architecture Information mental states, but
agent in Agent class Expertise model Data descriptor implementation
belief/knowledge document model not mentioned in
diagram model
methodology)
Agent Agent model; Detailed architecture
Service model Capability diagram Agent society model
capability/service Organization model document
Agent plan/reasoning Agent
Task state Behaviour
rule/problem solving Plan diagram Expertise model Plan descriptor implementation Agent model

diagram model
method model
As events in State
Interaction
Agent percept/ event transition diagrams of Percepts descriptor
model
Coordination Model
Agent Agent class
Agent overview Detailed architecture
Agent architecture BDI architecture Design model implementation architecture
diagram document
model diagram
Sequence
Acquaintance System requirement Software architecture Agent class Interaction Organization
Agent acquaintance diagram/Collaboration Coordination model Interaction diagrams Interaction model
model model document diagram model model
Table 4. Comparison regarding concepts
diagram
Interaction Interaction languages Communication Interaction
Interaction protocol Sequence diagram Coordination model Interaction protocols Agent society model Interaction model
model document class diagram model
Sequence Agent
Content of exchanged Interaction diagrams Interaction languages Communication Interaction Interaction
diagram/Collaboration Coordination model implementation Interaction model
messages & protocols document class diagram model model
diagram model
Inter-agent Information
contract/commitment model
Agent System
System overview Detailed architecture
System architecture Organization model implementation architecture Organization model
diagram document
model diagram
Organizational Organizational
Non-functional Organization
structure/inter-agent structure Organization model Organization model
requirements framework model
social relationship model
Environment Environmental Organization model; System overview Environment Organization
Environment model
resource/facility model Design model diagram definition document model
Environment Environment
characterisation definition document
Agent aggregation Detailed architecture
Agent model Organization model
relationship document
Agent inheritance
Organization model
relationship
Agent class Deployment
Comparison of Ten Agent-Oriented Methodologies
Agent instantiation Agent model Organization model

descriptor diagram
UML
Agent instances Deployment
Deployment model Deployment
deployment diagram
diagram
363
TEAM LinG
364 Tran & Low
Table 5. Comparison regarding model related criteria
COMMONKADS
PROMETHEUS
INGENIAS
MESSAGE
TROPOS
ADELFE
MASE
PASSI
GAIA
MAS-
RAP
Completeness/Express
M H H H H H H M M H
iveness
Formalization/ a. H a. H a. M a. H a. H a. H a. H a. H a. H a. H
Preciseness b. Y b. Y b. Y b. Y b. Y b. Y b. Y b. Y b. Y b. Y
Model derivation Y Y Y Y Y Y Y Y Y Y
a. Y a. Y a. N a. Y a. Y a. Y a. Y a. N a. N a. Y
Consistency b. Y b. Y b. Y b. Y b. Y b. Y b. Y b. Y b. Y b. Y
a. Y a. Y a. Y a. Y a. Y a. Y a. Y a. Y a. Y a. N
Complexity b. Y b. Y b. Y b. Y b. Y b. Y b. Y b. Y b. Y b. N
Ease of understanding H H H H H H H H H M
Modularity Y Y Y Y Y Y Y Y Y Y
Abstraction Y Y Y Y N Y Y Y Y Y
Autonomy Y Y Y Y Y Y Y Y Y Y
Adaptability P N N N N Y N N P P
Cooperative
Y Y Y Y Y Y Y Y Y Y
behaviour
Communication
N Y Y Y Y Y Y Y Y Y
ability
Inferential capability N Y Y Y Y Y P P Y Y
Reactivity P Y Y Y Y Y Y Y Y Y
Deliberative
Y Y Y Y Y Y Y N Y Y
behaviour
Personality N N N N N N N N N N
Temporal continuity N N N N N N N N N Y
Concurrency N N N N Y N Y N N N
Human Computer
N Y Y Y Y Y N Y Y Y
Interaction
Models Reuse Y P Y P Y P Y P P P
Y: Yes N: No P: Possibly
The “Concepts” criterion in Table 4 evaluates the modelling capability of an

AOSE methodology by examining which concepts the methodology’s models are
capable of capturing/representing. A list of “standard” AOSE concepts is used
as an assessment checklist, as previously mentioned. If a methodology supports
the modelling of a particular concept, we indicated the name of the model or
notational component (i.e., diagram) that represents that concept. If a concept
appears in many different models or diagrams within the methodology, we only
specified the model or diagram that represents the concept as the principal
modelling element.
Comparison Regarding Supportive-Feature Criteria
This comparative assessment of the methodologies in terms of their high-level,

additional features is summarized in Table 6.
TEAM LinG
Table 6. Comparison regarding supportive related criteria
COMMONKADS
PROMETHEUS
INGENIAS
MESSAGE
TROPOS
ADELFE
MASE
PASSI
GAIA
MAS-
RAP
Software and
methodological N N N Y Y Y Y Y Y Y
support
Open systems Y N N N N Y N N N N
Dynamic structure N N N N Y N P N N N
Agility and robustness N N Y Y N Y Y Y N N
Support for
N N N Y N Y N Y Y Y
conventional objects
Support for mobile
N N N N Y N N N N N
agents
Support for ontology N N Y N Y N N N Y N
Y: Yes N: No P: Possibly
Conclusions
This chapter has presented an evaluation and comparison of the 10 AOSE

methodologies described in Chapters 2-11 of this book. Overall, it is impossible
(and not recommended) to determine which methodology is the best among these
10. The decision should depend on the target application. Each application entails
a different set of requirements that indicate which evaluation criteria are the
most important and should be supported by the chosen AOSE methodology.
When considering which methodology to adopt for a particular application, we
recommend ranking the required features that the methodology should support.
Tables 1-6 provide a useful framework to compare potential methodologies
against the required list of features.
Despite our efforts to provide a comprehensive and objective comparison, we
acknowledge the following limitations:
• Our evaluation has been solely based upon the available documentation of
the methodologies and their documented case studies, examples, and
projects. We have not personally applied any of these methodologies on a
real project. An optimal comparison would be to use the 10 methodologies
on the same application(s).
• Some evaluation criteria are subjective in nature, particularly the usability
and understandability of the methodologies’ process steps, techniques, and
models.
TEAM LinG
368 Henderson-Sellers
Chapter XIII
Creating a
Comprehensive
Agent-Oriented
Methodology :
Using Method Engineering
and the OPEN Metamodel
Abstract
While individual agent-oriented methodologies are useful for restricted
situations, a more flexible approach can be found in the use of situational
method engineering. Using an underpinning metamodel, a repository of
method fragments can be built up and, from this, a selected number of
fragments can be abstracted to form an organization-specific or project-
specific methodology. As an example, we demonstrate the use of the OPEN
metamodel and repository, as extended to support agent-oriented conceptual
thinking. Re-creation of existing methodologies, such as Prometheus, is
demonstrated with further enhancements from other methodologies such as
Tropos and Gaia.
TEAM LinG
366 Tran & Low
The comparative analysis provided in this chapter is one step towards the
development of a unified, standardized AOSE framework that may be formed by
merging the various existing AOSE methodologies with some extensions. A first
step towards this, using the principles of method engineering, is described in the
next chapters.
References
Cernuzzi, L. & Rossi, G. (2002). On the evaluation of agent-oriented modeling
methods. In Proceedings of the OOPSLA Workshop on Agent-Oriented
Methodologies, Seattle, November 4-8 (pp. 21-33). University of Tech-
nology, Sydney: Centre for Object Technology Applications and Research.
Iglesias, C.A., Garijo, M., & Gonzalez, J.C. (1999). A survey of agent-oriented
methodologies. In Proceedings of the 5th International Workshop on
Intelligent Agents V: Agent Theories, Architectures, and Languages
(ATAL-98), Paris, July 4-7 (pp. 317-330). Springer-Verlag.
Jayaratna, N. (1994). Understanding and evaluating methodologies - NIMSAD
a systematic framework. Maidenhead, UK: McGraw-Hill.
The Object Agency Inc. (1995). A comparison of object-oriented development
methodologies. Retrieved November 9, 2003, from http://www.toa.com/
smnn?mcr.html
Olle, T.W., Sol, H.G., & Tully, C.J. (1983). Information systems design
methodologies – A feature analysis. Amsterdam: Elsevier Science
Publishers.
O’Malley, S.A. & DeLoach, S.A. (2001). Determining when to use an agent-
oriented software engineering paradigm. In Proceedings of the 2nd
International Workshop on Agent-Oriented Software Engineering
(AOSE 2001), Montreal, Canada, May 29 (pp. 188-205). Springer-Verlag.
Robinson, D.J. (2000). A component-based approach to agent specification.
Master’s Thesis, School of Engineering, Air Force Institute of Technology,
Wright-Patterson AFB OH.
Sabas, A., Badri, M., & Delisle, S. (2002). A multidimensional framework for the
evaluation of multi-agent system methodologies. In Proceedings of the
6th World Multiconference on Systemics, Cybernetics and Informatics
(SCI 2002), Orlando, July 14-18 (pp. 211-216). Orlando: International
Institute of Informatics and Systemics.
based systems. In Proceedings of the 5th International Conference on
TEAM LinG
Autonomous Agents, Montreal, Canada, May 28-June 1 (pp. 624-631).

ACM Press.
Siau, K. & Rossi, M. (1998). Evaluation of information modeling methods – A
review. In Proceedings of the 31 st Annual Hawaii International Con-
ference on System Sciences, Hawaii, January 6-9 (pp. 314-322). IEEE
Computer Society.
Tran, Q.N., Low, G., & Williams, M.A. (2003). A feature analysis framework
for evaluating multi-agent system development methodologies. In Pro-
ceedings of the 14th International Symposium on Methodologies for
Intelligent Systems ISMIS’03, Maebashi, Japan, October 28-31 (pp. 613-
617). Springer-Verlag.
Wood, B., Pethia, R., Gold, L.R., & Firth, R. (1988). A guide to the assessment
of software development methods. Technical Report CMUSEI-88-TR-8,
SE. Software Engineering Institute, Carnegie Mellon University, Pitts-
burgh, PA.
Yu, E. (1995). Modeling strategic relationships for process reengineering.
PhD thesis, University of Toronto, Department of Computer Science,
Toronto, Canada.
Endnotes
1
Models are differentiated from notational components in that models are
conceptual constructs that underlie the graphical or textual depictions,
which are notational components (e.g. diagrams, tabular schemas). Each
model can be depicted by many notational components (e.g., an Interaction
Model may be depicted by a set of Sequence Diagrams and/or State
Charts).
2
This is the same survey as that conducted for validating the framework of
“standard” AOSE steps in the section on “Process Related Criteria.”
TEAM LinG
Creating a Comprehensive Agent-Oriented Methodology 369
Introduction
Individual methodologies, such as those described so far in this book, are often
created with specific purposes in mind, for example, particular domains, particu-
lar segments of the lifecycle. Used within those constraints, they are ideally
suited. However, users often make the assumption that a methodology is not in
fact constrained but, rather, is universally applicable. This can easily lead to
“methodology failure” and the total rejection of methodological thinking by
software development organizations (e.g., Avison & Fitzgerald, 2003).
The search for a one-size-fits-all methodology has been long and will, ultimately,
always be fruitless (e.g., Cockburn, 2000). If the creation of a single universally
applicable methodology is an unattainable goal, then we must ask how we might
create a methodological environment in which the various demands of different
software developers might be satisfied simultaneously. It is argued here that
such flexibility might be best obtained by the use of method engineering,
preferably based on an underlying metamodel. Formalizing methodological
concepts and constraints with a metamodel in this way allows us to identify two
component parts of a methodology: (1) the process, and (2) various products
created and/or used in the process (Rolland, Prakash, & Benjamen, 1999).
Although all the chapters in this book deal with the broader term of “methodol-
ogy” (i.e., process plus product), for our case study in this chapter, we will focus
only on the “process” part of a methodology. A second assumption we make here
is that an agent-oriented (AO) methodology can be formulated as a particular
extension of an object-oriented (OO) methodology. In the context of method
engineering and the earlier chapters of this book, we will demonstrate that this
is a reasonable assumption.
In the following sections, we introduce situational method engineering as an
effective approach for constructing a site-specific methodology that may be
tailored or customized for individual projects in the context of OPEN, particularly
as it has been partially extended to support agent-oriented software develop-
ment. In the next section (CASE STUDY), we demonstrate how such method-
ology construction works with a simple case study and, finally, we conclude with
a research and technology transfer agenda to facilitate the creation, finalization,
and technology transfer of such a “standardized” approach in the context of the
adoption of agent-oriented methodologies in an industrial context.
TEAM LinG
fragment in the repository, there is such a conceptual definition in the metamodel.

The repository (of method fragments) thus contains numerous instances gener-
ated from each of the classes in the metamodel (Figure 2).
Although some method fragments have a specific bias, for example, to object
technology, to systems engineering, to business modelling, or to traditional
procedural programming using a language such as COBOL, the repository as a
whole can be independent of technological paradigms. It is thus reasonable, as
we shall do here, to begin with a repository populated by a mixture of OO-biased
fragments and OO-independent fragments (e.g., for project management) and
add new agent-biased fragments prior to constructing an organization-specific or
a project-specific AO methodology from these many fragments.
Creating a project-specific methodology is currently one of the more difficult and
time-consuming jobs of the method engineering approach, since the method
engineer has to understand the methodology, the organization, the environment,
and the software project in order to select the appropriate fragments from the
repository to use on the project, in addition to understanding the rules of
construction. Traditionally, this process is carried out using predefined organiza-
tional requirements and the experience and knowledge of the method engineer
or process engineer (e.g., Fitzgerald, Russo, & O’Kane, 2003), although
significant tool support is likely in the near future (Saeki, 2003).
In the next section, we see how this is accomplished using one particular method
engineering framework, OPEN.
A Method Engineering Framework:

OPEN
With future commercial adoption in mind, the first choice must be for a
methodology framework with an underpinning metamodel and an existing
extensive catalogue of method fragments. Here, we use Object-oriented Pro-
cess, Environment, and Notation or OPEN, 3 which is both described in an
extensive set of books (e.g., Firesmith & Henderson-Sellers, 2002; Graham,
Henderson-Sellers, & Younessi, 1997; Henderson-Sellers, Simons, & Younessi,
1998) and is used in industrial applications (e.g., Serour, Henderson-Sellers,
Hughes, Winder, & Chow, 2002). The OPEN metamodel contains a number of
conceptual entities modelled by object-oriented classes, typically described using
the UML notation. Those concepts most relevant to the creation of an AO
methodology standard as an extension of the existing OO methodological
repository are (1) Task, (2) Technique, and (3) Work Product. Each of these
TEAM LinG
Situational Method Engineering

Method engineering (Brinkkemper, 1996; Kumar & Welke, 1992), more appro-
priately called situational method engineering or SME (Ter Hofstede & Verhoef,
1997), recognizes the fact (often ignored as noted above) that seeking to develop
an all-encompassing methodology appropriate for all situations is foolish. Rather,
SME seeks to model methodological processes and products by isolating
conceptual method fragments (van Slooten & Hodes, 1996) that are coherent
portions of a methodology. These fragments act as methodological “building
blocks”—examples might be a particular technique to identify agent types or the
Figure 1. The methodologist is responsible for the methodology metamodel,

creating a significant number (but not necessarily all) of the method
fragments in the repository and the guidelines for construction. The user
(often the in-house method engineer) uses the construction guidelines and
the contents of the repository (to which they are at liberty to add new
fragments) in order to create a “personalized development methodology”
attuned to a specific project or context.
Project
meets the needs

of a specific
Personalized <<instance of>>

Methodology metamodel
Development
Methodology
provides elements provides

for the construction of definitions of
Repository of Predefined Method Fragments
describes how
to use the
Construction Guidelines
user methodologist
TEAM LinG
Creating a Comprehensive Agent-Oriented Methodology 371
way to use a sequence diagram in AUML (Odell, Van Dyke Parunak, & Bauer,
2000). These method fragments thus effectively allow a methodology to be
extended by incorporating elements from other methodologies (e.g., Ralyté &
Rolland, 2001). In other words, from these method fragments can be constructed
a specialized methodology appropriate for each and every situation.
The methodologist publishes the method fragments, usually contained in a
repository1 together with some construction guidelines (Brinkkemper, Saeki, &
Harmsen Klooster, Brinkkemper, Harmsen, & Wijers, 1997; Ralyté & Rolland,
2001; Ralyté, Rolland, & Deneckère, 2004); and the user (usually an in-house
method engineer) uses these construction guidelines to create the organization-
specific or project-specific methodology within the organizational context and
constraints (Figure 1). In the case where an organization develops software in
a single domain, that constructed methodology may suffice for all developments;
for other commercial developers, the constructed methodology may need to be
project-specific.
Ideally, the elements in an SME repository should be compliant with (in fact,
generated from) a set of concepts described by a metamodel (Henderson-
Sellers, 2003; Ralyté & Rolland, 2001), which is a high-level description of the
rules that govern the kinds of method fragments that are allowable. For instance,
in the metamodel there may be an entity (often represented as a class) called
Task.2 This definition describes the characteristics and rules of all tasks (for
example, that they must be accomplished by a person using a special technique).
From this Task concept in the metamodel can then be generated (usually by
instantiation) very many kinds of tasks, for example, a task to create a class
diagram, a task to identify the use cases, and so on. For each kind of method
Figure 2. For each concept in the metamodel, many instances can be

generated and stored in the repository.
Metamodel Repository of method fragments
Concept A
...
Concept B Example 1 Example 2
Concept A Concept A
...
Concept C Example 1 Example 2
Concept B Concept B
Concept D
...
Example 1 Example 2
Concept C Concept C
...
Example 1 Example 2
Concept D Concept D
TEAM LinG
Each of these five metaclasses has many subclasses in the detailed metamodel
(see Appendix G of Firesmith & Henderson-Sellers, 2002). From each of the
leaves in the metamodel hierarchy can be generated one or more method
fragments, which are, of course, instances of classes in the metamodel,
documented and stored in the OPEN repository
Each method fragment is described in a standardized way—examples of task
descriptions, for instance, are found in the Appendix to this chapter. These
descriptions are found in the books on OPEN (e.g., Firesmith & Henderson-
Sellers, 2002; Graham et al., 1997; Henderson-Sellers< Simons, & Younessi,
1998), on Web sites (http://www.open.org.au and http://www.donald-
firesmith.com) and, in the future, in software tools (e.g., Nguyen & Henderson-
Sellers, 2003). These repositories provide an extensive collection of fragments
that can be further extended to support changes in technology, for instance, as
described in this chapter, to offer additional methodology support for the novel
aspects of agent-oriented software development.
Method Fragment Selection
Having created the OPEN repository of method fragments, method engineering

(or SME) is then used to construct a site-specific or project-specific methodol-
ogy by selecting appropriate method fragments from this OPEN repository and
using the supplied guidelines (see Firesmith & Henderson-Sellers, 2002, for
details) for helping organizations to adopt OPEN for their information system
development projects. These guidelines offer advice on the selection of specific
fragments based on the notion of deontic matrices.
A deontic matrix (Figure 3) is a two-dimensional matrix of values that represent
the possible or likely relationship between each pair of method fragments in
OPEN. Deontic matrices are used to link Activities and Tasks; Tasks and
Techniques; Producers and Tasks; Tasks and Work Products; Producers and
Work Products; and Work Products and Languages. The actual values in this
matrix will vary depending upon a number of factors such as project size,
organizational culture, domain of the application to be developed, and the skills
and preferences of the development team. These values are currently evaluated
by hand although, as noted above, tool support is currently under development.
For example, the possibility value for using the OPEN Task “ Evaluate quality”
to help fulfil the Activity “Verification and Validation (V&V)” might be assessed
as being “Recommended” (one of the five prescribed values).
Once completed, the deontic matrices give guidance on the most appropriate
selection of method fragments. Although five levels are suggested in Figure 3
(the default in OPEN), for a specific project binary values are often used.
However, as an organization matures, a wider range of deontic values can be
TEAM LinG

Brian Henderson-Sellers - Paolo Giorgini-Agent-oriented Methodologies-Idea Group Pub (2005)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Brian Henderson-Sellers - Paolo Giorgini-Agent-oriented Methodologies-Idea Group Pub (2005)

Uploaded by

Copyright:

Available Formats

TEAM LinG

IDEA GROUP PUBLISHING

Acquisitions Editor: Renée Davies

Published in the United States of America by

and in the United Kingdom by

Library of Congress Cataloging-in-Publication Data

Agent-oriented methodologies / Brian Henderson-Sellers and Paolo Giorgini, editors.

British Cataloguing in Publication Data

About the Authors ..................................................................................... 398

Index ............................................................................................................ 406

A methodology is a body of methods employed by a discipline. A method is a

Figure 1. Methodological approaches fall into three categories (adapted

tems that involve implementations, such as distributed human and

In summary, all of the methodologies in this book provide valuable contributions

It provides a wealth of guidelines, techniques, and notations for developing a

Building software to solve contemporary business problems is no easy task.

contrast to the history of object-oriented methodologies, in which industry played

ible and coherent agent-oriented methodologies. The creation of a standard

Brian Henderson-Sellers, Sydney, Australia

As an introduction to agent-oriented (AO) methodologies, we first describe

be over a thousand methodological approaches to software development

Agents and Multi-Agent Systems

While there is much debate on the use of terminology in various subcultures of

Figure 1. Direct and indirect influences of object-oriented methodologies

AOR RUP OMT Fusion OPEN

Somewhat different is the MAS-CommonKADS methodology (Iglesias, Garijo,

Common Terms/Concepts Used in the AO Methodologies

environment (Zambonelli, Jennings, & Wooldridge, 2001), which is sometimes

{consisten t set of}

Table 1. Relationships between terminology of BDI model (after Henderson-

Viewpoint Column 3 Column 3 +

Figure 3. Metamodel of concepts used in the BDI architecture (after

If agents are operating in a communal workplace, then clearly they need to

Introducing the Methodologies

Collinot, A. & Drogoul, A. (1998). Using the Cassiopeia method to design a

Henderson-Sellers, B., Tran, Q.-N.N., & Debenham, J. (2005). An etymological

Conference on Multi-Agent Systems, San Francisco (pp. 312-319).

Software Engineering (AOSE-2000) (pp. 207-222). LNCS 1957, Springer-

on the i* organizational modeling framework. i* offers the notions of actor,

implementation phases wanes sometime in the future, requirements analysis will

• Early requirements, concerned with the understanding of a problem by

The proposed methodology includes techniques for generating an implementa-

Requirement analysis represents the initial phase in most software engineering

questions ultimately link system functionality to stakeholder needs, preferences,

dent organizational stakeholders who have agreed to pursue a set of business

Mylopoulos, Nicchiarelli, and Sebastiani (2002) both qualitative and numerical

Mayfield, 1997), message transportation mechanisms, and other concepts and

Figure 1. Interface of the system

(e.g., science-fiction), author/artist, short description, editor/publisher interna-

Early Requirements Analysis

Figure 2. Actor diagram for a Media Shop

Increase Depender X Dependee

Buy Media Media Continuous Media Quality Media

Customer also depends on Media Shop to consult the catalogue (task

Figure 3. Means-ends analysis for the softgoal Increase Market Share

Telecom Communication Process

Continuing Decomposition link Means-ends link

Late Requirement Analysis

Figure 4. Refined actor diagram for Media Shop

keywords, or simply to browse the online catalogue. With respect to relevant

responsibility assignment is realized using the same kind of means-ends analysis

Figure 5. Rationale diagram for Medi@

Select Item Standard