You are on page 1of 429

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: Rene 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
Paolo Giorgini, University of Trento, Italy
Brian Henderson-Sellers, University of Technology, Sydney,
Australia

Chapter II
Tropos: A Requirements-Driven Methodology for Agent-Oriented
Software .......................................................................................................... 20
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

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
Valrie 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, Telefnica I+D, Spain
Jorge J. Gmez-Sanz, Universidad Complutense de Madrid,
Spain
Philippe Massonet, CETIC, Belgium

Chapter IX
The INGENIAS Methodology and Tools .............................................. 236
Juan Pavn, Universidad Complutense de Madrid, Spain
Jorge J. Gmez-Sanz, Universidad Complutense de Madrid, Spain
Rubn 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
Brian Henderson-Sellers, University of Technology, Sydney,
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 approachminimizing 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
systems 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 understandfacilitating 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
blocksor method fragmentscan 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 applications 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 methodologyeven though it must still address and
incorporate non-agent development requirementsis 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 approacheswhile 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 constraintsmoney, 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 methodologythe 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 rejectionspoiled 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 technologyhere, 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 doesnt. 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 peoplethe
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

Brian Henderson-Sellers
University of Technology, Sydney, Australia

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-
drivenmost 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 & DInverno, 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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Agent-Oriented Methodologies: An Introduction 3

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
4 Giorgini & Henderson-Sellers

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Agent-Oriented Methodologies: An Introduction 5

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,

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
6 Giorgini & Henderson-Sellers

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 MASsarguably, 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Agent-Oriented Methodologies: An Introduction 7

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
8 Giorgini & Henderson-Sellers

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 UMLs 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 differentlyas 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Agent-Oriented Methodologies: An Introduction 9

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 agents 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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
10 Giorgini & Henderson-Sellers

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Agent-Oriented Methodologies: An Introduction 11

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
12 Giorgini & Henderson-Sellers

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Agent-Oriented Methodologies: An Introduction 13

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
14 Giorgini & Henderson-Sellers

Bernon, C., Gleizes, M.-P., Picard, G., & Glize, P. (2002). The ADELFE
methodology for an intranet system design. In P. Giorgini, Y. Lesprance,
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. Lesprance, 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.
Lesprance (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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Agent-Oriented Methodologies: An Introduction 15

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 (ICMAS96) (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 (SERP02), 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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
16 Giorgini & Henderson-Sellers

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 (MAAMAW96) (pp. 56-71).
Springer-Verlag.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Agent-Oriented Methodologies: An Introduction 17

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., & DInverno, 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 (AAMAS02)
(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.
Pavn, 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
18 Giorgini & Henderson-Sellers

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 (AI01), 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Agent-Oriented Methodologies: An Introduction 19

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
22 Giorgini, Kolp, Mylopoulos & Castro

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 systems 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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Tropos: A Requirements-Driven Methodology for Agent-Oriented Software 23

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
24 Giorgini, Kolp, Mylopoulos & Castro

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 actorsthe 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; dependumsgoals,
softgoals, tasks and resourcesare 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-

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Tropos: A Requirements-Driven Methodology for Agent-Oriented Software 25

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,

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
26 Giorgini, Kolp, Mylopoulos & Castro

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, &

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Tropos: A Requirements-Driven Methodology for Agent-Oriented Software 27

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
28 Giorgini, Kolp, Mylopoulos & Castro

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Tropos: A Requirements-Driven Methodology for Agent-Oriented Software 29

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
30 Giorgini, Kolp, Mylopoulos & Castro

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Tropos: A Requirements-Driven Methodology for Agent-Oriented Software 31

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
32 Giorgini, Kolp, Mylopoulos & Castro

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Tropos: A Requirements-Driven Methodology for Agent-Oriented Software 33

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
34 Giorgini, Kolp, Mylopoulos & Castro

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 systems 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.

Architectural Design
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).

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Tropos: A Requirements-Driven Methodology for Agent-Oriented Software 35

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
EShopping
Browsing
Update &
Backup
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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
36 Giorgini, Kolp, Mylopoulos & Castro

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Tropos: A Requirements-Driven Methodology for Agent-Oriented Software 37

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 Carts 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
customers 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
38 Giorgini, Kolp, Mylopoulos & Castro

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Tropos: A Requirements-Driven Methodology for Agent-Oriented Software 39

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 Online
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 ButtonRecalculate 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:
email : 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

checkoutrequest for proposal


Timeout
12/19/00
9:31 53
refuse

FIPA Contract Net Protocol


notunderstood Notification
X
Customer, Shopping Cart
propose 12/19/00 at 9:31 53
checkoutrfp, refuse, notunderstood,
propose, cancelproposal
cancelproposal acceptproposal, succeeded, failure

Decision
X
acceptproposal

succeeded
inform
X
failure
Plan Diagram (See Figure 11)

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
40 Giorgini, Kolp, Mylopoulos & Castro

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Tropos: A Requirements-Driven Methodology for Agent-Oriented Software 41

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
42 Giorgini, Kolp, Mylopoulos & Castro

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 elsewherefor 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Tropos: A Requirements-Driven Methodology for Agent-Oriented Software 43

Autonomous Agents, Agents98, 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, AOSE00, 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.
Castro, J., Kolp, M., & Mylopoulos, J. (2002). Towards requirements-driven
information systems engineering: The Tropos project. Information Sys-
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, ICEIS03, 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, SEKE03, 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
44 Giorgini, Kolp, Mylopoulos & Castro

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, Agents99, 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, ATAL96,
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, ATAL01, 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,
AAMAS02, 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, CAiSE03, 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, UML01, Toronto,
Canada, October 1-5 (pp. 422-442). Springer.
Odell, J., Van Dyke Parunak, H., & Bauer, B. (2000). Extending UML for
agents. Proceedings of the 2nd International Bi-Conference Work-

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Tropos: A Requirements-Driven Methodology for Agent-Oriented Software 45

shop on Agent-Oriented Information Systems, AOIS00, 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, Agents01, 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, RE93, 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, ICSE94, 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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

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, Gonzlez, & 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)

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
48 Iglesias & Garijo

(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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The Agent-Oriented Methodology MAS-CommonKADS 49

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
50 Iglesias & Garijo

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The Agent-Oriented Methodology MAS-CommonKADS 51

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:

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
52 Iglesias & Garijo

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The Agent-Oriented Methodology MAS-CommonKADS 53

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
54 Iglesias & Garijo

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The Agent-Oriented Methodology MAS-CommonKADS 55

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 developedbefore 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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
56 Iglesias & Garijo

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 techniquesee 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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The Agent-Oriented Methodology MAS-CommonKADS 57

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
58 Iglesias & Garijo

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The Agent-Oriented Methodology MAS-CommonKADS 59

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
60 Iglesias & Garijo

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The Agent-Oriented Methodology MAS-CommonKADS 61

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
62 Iglesias & Garijo

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The Agent-Oriented Methodology MAS-CommonKADS 63

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
64 Iglesias & Garijo

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The Agent-Oriented Methodology MAS-CommonKADS 65

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
66 Iglesias & Garijo

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The Agent-Oriented Methodology MAS-CommonKADS 67

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
68 Iglesias & Garijo

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The Agent-Oriented Methodology MAS-CommonKADS 69

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
70 Iglesias & Garijo

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The Agent-Oriented Methodology MAS-CommonKADS 71

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
72 Iglesias & Garijo

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The Agent-Oriented Methodology MAS-CommonKADS 73

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, Mller, & 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 models 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
74 Iglesias & Garijo

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The Agent-Oriented Methodology MAS-CommonKADS 75

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
76 Iglesias & Garijo

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 OOPSLA89 Conference Proceedings, New Orleans, LA,
USA (Vol. 17, pp. 1-6).
Bauer, B., Mller, 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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The Agent-Oriented Methodology MAS-CommonKADS 77

Bergenti, F., Garijo, M., Poggi, A., Somacher, M. & Velasco, J. R. (2002).
Enhancing collaborative work through agents. In VII Convegno
dellAssociazione Italiana per lIntelligenza 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 (SCI99)
and 5th International Conference on Information Systems Analysis
and Synthesis (ISAS99) (Vol. 5, pp. 535-540). International Institute of
Informatics and Systemics.
Iglesias, C. A., Garijo, M., Gonzlez, 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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
78 Iglesias & Garijo

Marci de Oliveira, H. (2002). Tcnicas para Projeto e Implementaao 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
Educacin a Distancia. Revista de Ingeniera Informtica, 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

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,

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

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-

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
From Requirements to Code with the PASSI Methodology 81

(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 (OBrien & 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
82 Cossentino

The remainder of this chapter is structured as follows. The next section gives a
quick presentation of the methodologys models and provides a justification for
PASSI. The third section presents the application of PASSI to the Juul Mller
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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
From Requirements to Code with the PASSI Methodology 83

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:

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

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 methods 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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
From Requirements to Code with the PASSI Methodology 85

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 Mller 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

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 (Antn


& 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 scenariothe 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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
From Requirements to Code with the PASSI Methodology 87

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 Jacksons 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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

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 stocks 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
From Requirements to Code with the PASSI Methodology 89

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 agents 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 agents 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 actors 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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
From Requirements to Code with the PASSI Methodology 91

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 agents behavior in order to conceive of a plan


that could fulfil the agents 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 agents 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 agents
T.Sp. diagram, we need to look at all of the agents 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 scenarios 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

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).

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
From Requirements to Code with the PASSI Methodology 93

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 actionit 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
From Requirements to Code with the PASSI Methodology 95

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 FIPAs 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

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 roles 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()

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
From Requirements to Code with the PASSI Methodology 97

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
agents 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).

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

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 agents tasks.

Single-Agent Structure Definition (SASD)

Here one class diagram (Figure 11) is used for each agent to illustrate the agents
internal structure through all of the classes making up the agent, which are the

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
From Requirements to Code with the PASSI Methodology 99

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()

agents 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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

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
messages performative as it is specified in the Communication Ontology
Description diagram and the messages 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 Purchasers 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
From Requirements to Code with the PASSI Methodology 101

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 patterns 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:

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

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 agents 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 agents mobility, which we have done by means of a

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
From Requirements to Code with the PASSI Methodology 103

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-

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

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 Mller Bokhandel A/S. Norwegian School of
Management. Available online http://www.espen.com/papers/jme.pdf
Antn, 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).

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
From Requirements to Code with the PASSI Methodology 105

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
IAT03 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).

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
106 Cossentino

Newell, A. (1982). The knowledge level. Artificial Intelligence, 18, 87-127.


OBrien, 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 (RE99) (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
systems: The Gaia methodology. ACM Transactions on Software Engi-
neering and Methodology, 12(3), 417-470.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Prometheus: A Practical Agent-Oriented Methodology 109

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
110 Padgham & Winikoff

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 agents 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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Prometheus: A Practical Agent-Oriented Methodology 111

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 systems 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 systems 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 agents 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
112 Padgham & Winikoff

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Prometheus: A Practical Agent-Oriented Methodology 113

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
Johns 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
114 Padgham & Winikoff

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Prometheus: A Practical Agent-Oriented Methodology 115

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)

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
116 Padgham & Winikoff

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 Sietsmas
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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Prometheus: A Practical Agent-Oriented Methodology 117

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
118 Padgham & Winikoff

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 users 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Prometheus: A Practical Agent-Oriented Methodology 119

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.

Architectural Design

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
120 Padgham & Winikoff

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Prometheus: A Practical Agent-Oriented Methodology 121

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 typesthe 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 dont
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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
122 Padgham & Winikoff

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 wont 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Prometheus: A Practical Agent-Oriented Methodology 123

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
124 Padgham & Winikoff

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, Rnnquist, 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Prometheus: A Practical Agent-Oriented Methodology 125

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 agents 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 systems dynamics were described
using interaction protocols. These are global in that they depict the interaction
between the agents from a birds-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 plans

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
126 Padgham & Winikoff

context condition and then develop the plans body. The plans context condition
specifies the situations in which it is appropriate to use the plan. The plans 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Prometheus: A Practical Agent-Oriented Methodology 127

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
128 Padgham & Winikoff

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Prometheus: A Practical Agent-Oriented Methodology 129

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
130 Padgham & Winikoff

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 Rnnquist, 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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Prometheus: A Practical Agent-Oriented Methodology 131

Burmeister, B. (1996). Models and methodology for agent-oriented analysis and


design. Working Notes of the KI96 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., Rnnquist, 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., Rnnquist, 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 (ICMAS96) (pp. 41-57). AAAI Press.
Dam, K. H. (2003). Evaluating agent-oriented software engineering meth-
odologies. Masters 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
dInformatique de Paris 6.
Elammari, M. & Lalonde, W. (1999). An agent-oriented methodology: High-
level and intermediate models. In G. Wagner & E. Yu (Eds.), Proceedings

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
132 Padgham & Winikoff

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, (Agents99), 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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Prometheus: A Practical Agent-Oriented Methodology 133

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 (AAMAS02), 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-

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
134 Padgham & Winikoff

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. Mller, & 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 (RE01) (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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Prometheus: A Practical Agent-Oriented Methodology 135

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 UMLs 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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
138 Zambonelli, Jennings & Wooldridge

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 systems
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).

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Multi-Agent Systems as Computational Organizations: The Gaia Methodology 139

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 agents
specific role, as well as by its current status.
The organizational metaphorother 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
140 Zambonelli, Jennings & Wooldridge

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Multi-Agent Systems as Computational Organizations: The Gaia Methodology 141

(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:

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
142 Zambonelli, Jennings & Wooldridge

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 assumedits


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 agents 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,

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Multi-Agent Systems as Computational Organizations: The Gaia Methodology 143

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 constraintscaptured in our concept of organizational

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
144 Zambonelli, Jennings & Wooldridge

rulesis 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 organizations 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 roleswhere the former is in charge
of assigning work to the latter and of load balancing their activitiesimplicitly
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:

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Multi-Agent Systems as Computational Organizations: The Gaia Methodology 145

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-

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
146 Zambonelli, Jennings & Wooldridge

tional structuresto 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Multi-Agent Systems as Computational Organizations: The Gaia Methodology 147

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
148 Zambonelli, Jennings & Wooldridge

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 Gaias 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,

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Multi-Agent Systems as Computational Organizations: The Gaia Methodology 149

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
organizations 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
150 Zambonelli, Jennings & Wooldridge

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 roleintuitively, they say what can be
spent while carrying out the role; and (2) stating the resource limits within
which the role must operateintuitively, they say what cant 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Multi-Agent Systems as Computational Organizations: The Gaia Methodology 151

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 Gaias 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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
152 Zambonelli, Jennings & Wooldridge

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 responsibilitiesorganizational 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 organizations 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).

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Multi-Agent Systems as Computational Organizations: The Gaia Methodology 153

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 MASs 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
154 Zambonelli, Jennings & Wooldridge

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 organizationwhether
a human being, a hardware component, or a software agentexhibits 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 organizations
members are freed from the duty of handling the coordination activities because
a leader member assumes responsibility for them. As the organizations 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Multi-Agent Systems as Computational Organizations: The Gaia Methodology 155

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
156 Zambonelli, Jennings & Wooldridge

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Multi-Agent Systems as Computational Organizations: The Gaia Methodology 157

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
158 Zambonelli, Jennings & Wooldridge

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).

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Multi-Agent Systems as Computational Organizations: The Gaia Methodology 159

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
160 Zambonelli, Jennings & Wooldridge

(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 separationthat for the sake of simplicity could also be preserved as
a comment to the textual description of the protocolsassumes 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 structureby having agents re-adapt
their extrinsic part to fit into a new organizational structurein 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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Multi-Agent Systems as Computational Organizations: The Gaia Methodology 161

Typically, as previously outlined, there may be a one-to-one correspondence


between roles and agent classesa 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 Gaias 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 objects
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,

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
162 Zambonelli, Jennings & Wooldridge

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Multi-Agent Systems as Computational Organizations: The Gaia Methodology 163

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
164 Zambonelli, Jennings & Wooldridge

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Multi-Agent Systems as Computational Organizations: The Gaia Methodology 165

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.

Architectural Design

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 adoptionboth in the
real-world and in the MAS organizationof 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).

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
166 Zambonelli, Jennings & Wooldridge

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:

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Multi-Agent Systems as Computational Organizations: The Gaia Methodology 167

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 thatdespite being very important for the effective
development of MASsare 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.
Gaias 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.
Gaiaby neglecting such implementation issueshas no way of handling
them.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
168 Zambonelli, Jennings & Wooldridge

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Multi-Agent Systems as Computational Organizations: The Gaia Methodology 169

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.
Castro, J., Kolp, M., & Mylopoulos, J. (2002). Towards requirements-driven
information systems engineering: The Tropos project. Information Sys-
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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
170 Zambonelli, Jennings & Wooldridge

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Multi-Agent Systems as Computational Organizations: The Gaia Methodology 171

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
abstractions for the analysis and design of multi-agent systems. In Pro-
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
systems: The Gaia methodology. ACM Transactions on Software Engi-
neering and Methodology, 12(3), 417-470.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
172 Bernon, Camps, Gleizes & Picard

Chapter VII

Engineering Adaptive
Multi-Agent Systems:
The ADELFE Methodology
Carole Bernon
IRIT University Paul Sabatier, France

Valrie Camps
IRIT University Paul Sabatier, France

Marie-Pierre Gleizes
IRIT University Paul Sabatier, France

Gauthier Picard
IRIT University Paul Sabatier, France

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

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 limitationit 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, todays 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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
174 Bernon, Camps, Gleizes & Picard

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:

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Engineering Adaptive Multi-Agent Systems: The ADELFE Methdology 175

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 observers 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, & Rgis, 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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
176 Bernon, Camps, Gleizes & Picard

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 toolkitADELFEto 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Engineering Adaptive Multi-Agent Systems: The ADELFE Methdology 177

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 relevantwe 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
178 Bernon, Camps, Gleizes & Picard

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Engineering Adaptive Multi-Agent Systems: The ADELFE Methdology 179

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
180 Bernon, Camps, Gleizes & Picard

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 agents
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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Engineering Adaptive Multi-Agent Systems: The ADELFE Methdology 181

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
182 Bernon, Camps, Gleizes & Picard

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Engineering Adaptive Multi-Agent Systems: The ADELFE Methdology 183

The Process of ADELFE


The primary objective of the ADELFE method is to cover all the phases of a
classical software designfrom 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 Groups (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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
184 Bernon, Camps, Gleizes & Picard

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Engineering Adaptive Multi-Agent Systems: The ADELFE Methdology 185

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
186 Bernon, Camps, Gleizes & Picard

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Engineering Adaptive Multi-Agent Systems: The ADELFE Methdology 187

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
188 Bernon, Camps, Gleizes & Picard

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-users 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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Engineering Adaptive Multi-Agent Systems: The ADELFE Methdology 189

Figure 4. An AUML Protocol Diagram for the Case Study It expresses the
way in which the system answers an end-users 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 TransactionAgents (TAs) 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
190 Bernon, Camps, Gleizes & Picard

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.,

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Engineering Adaptive Multi-Agent Systems: The ADELFE Methdology 191

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
192 Bernon, Camps, Gleizes & Picard

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, actionvoid
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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Engineering Adaptive Multi-Agent Systems: The ADELFE Methdology 193

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 agents 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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
194 Bernon, Camps, Gleizes & Picard

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


State Receipt of a request
An agent is faced with partial incompetence when only one part of the received message
Description
has a meaning for it.
During the interpretation phase the agent compares the received request with its own
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
State Receipt of a request
An ambiguity occurs when the content of a received request is incomplete either because
Description the sender gets a bad description of the receivers tasks or because the specification of the
message is wrong.
During the interpretation phase the agent compares the received request with its own
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 receivers skills.

Name Concurrence
State Receipt of a request
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 Bs 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).

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Engineering Adaptive Multi-Agent Systems: The ADELFE Methdology 195

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
196 Bernon, Camps, Gleizes & Picard

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, todays and tomorrows 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 agentscooperative onesto 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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Engineering Adaptive Multi-Agent Systems: The ADELFE Methdology 197

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 agentADELFE 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
198 Bernon, Camps, Gleizes & Picard

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Engineering Adaptive Multi-Agent Systems: The ADELFE Methdology 199

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 OMGs 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).

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
200 Bernon, Camps, Gleizes & Picard

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 (KAW99), 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. OMGs 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., & Rgis, C. (2003). Real-time simulation
for flood forecast: An adaptive multi-agent system STAFF. In Proceed-
ings of the AISB03 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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Engineering Adaptive Multi-Agent Systems: The ADELFE Methdology 201

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 ICE00), 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.
Odell, J., Van Dyke Parunak, H., & Bauer, B. (2000). Extending UML for
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 (AOSE00), 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 (EUMAS03), 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 (MAAMAW96), Eindhoven, The Netherlands,
January 22-25, position paper.
Russel, S. & Norvig, P. (1995). Artificial intelligence: A modern approach.
Englewood Cliffs, NJ: Prentice Hall Series.
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.
Topin, X., Fourcassie, V., Gleizes, M-P., Theraulaz, G., Rgis, C., & Glize, P.
(1999). Theories and experiments on emergent behaviour: From natural 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
202 Bernon, Camps, Gleizes & Picard

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 (AOSE00), 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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

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
Telefnica I+D, Spain

Jorge J. Gmez-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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
204 Garijo, Gmez-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 componentsthe agentsand 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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The MESSAGE Methodology for Agent-Oriented Analysis and Design 205

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
206 Garijo, Gmez-Sanz & Massonet

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 agents 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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The MESSAGE Methodology for Agent-Oriented Analysis and Design 207

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
208 Garijo, Gmez-Sanz & Massonet

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 agents services. The quality of autonomy means that an
agents 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) Classa 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 Agents 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-

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The MESSAGE Methodology for Agent-Oriented Analysis and Design 209

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 OMGs 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
210 Garijo, Gmez-Sanz & Massonet

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The MESSAGE Methodology for Agent-Oriented Analysis and Design 211

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
212 Garijo, Gmez-Sanz & Massonet

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 designers 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The MESSAGE Methodology for Agent-Oriented Analysis and Design 213

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The MESSAGE Methodology for Agent-Oriented Analysis and Design 217

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
214 Garijo, Gmez-Sanz & Massonet

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 agents behaviour and interfaces. This includes the agents
domain and social knowledge. This is defined using the structure and the
relationships of the Organization Model. It supports reasoning about other
agents actions, about the society itself, and the social constraints upon an
agents actions (Garijo, Gmez-Sanz, Pavn, & 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
216 Garijo, Gmez-Sanz & Massonet

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
218 Garijo, Gmez-Sanz & Massonet

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
Organizations 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The MESSAGE Methodology for Agent-Oriented Analysis and Design 219

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,
Mller, & 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The MESSAGE Methodology for Agent-Oriented Analysis and Design 215

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 ones
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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The MESSAGE Methodology for Agent-Oriented Analysis and Design 221

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
222 Garijo, Gmez-Sanz & Massonet

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 roles 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
220 Garijo, Gmez-Sanz & Massonet

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The MESSAGE Methodology for Agent-Oriented Analysis and Design 223

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 agents
behaviour and defining the agent societys 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>>
<<Agent Definition>>
UPAAirlineInfoDeskAg UPAAirportInfoDeskAg

<<Agent Definition>>
UPATrialAccessAg <<Agent Definition>> <<Agent Definition>> <<Agent Definition>>
UPACustomerAccessAg UPAInformationFinderAg UPAInformationCommunicatorAg

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
224 Garijo, Gmez-Sanz & Massonet

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 )

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The MESSAGE Methodology for Agent-Oriented Analysis and Design 225

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 agents 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 agents 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
226 Garijo, Gmez-Sanz & Massonet

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The MESSAGE Methodology for Agent-Oriented Analysis and Design 227

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.
MESSAGEs 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 (Pavn
& Gmez-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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
228 Garijo, Gmez-Sanz & Massonet

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 MASs 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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The MESSAGE Methodology for Agent-Oriented Analysis and Design 229

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:

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
230 Garijo, Gmez-Sanz & Massonet

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The MESSAGE Methodology for Agent-Oriented Analysis and Design 231

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 organizations roles in the multi-agent application.
Services could then be implemented in terms of tasks that were decomposed into
direct actions on the agents 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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
232 Garijo, Gmez-Sanz & Massonet

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., Mller, 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 mthode VOYELLES, dans Systmes Multi-Agents:
Des Thories Organisationnelles aux Applications Industrielles. Oslo,
Norway: Herms.
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/

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The MESSAGE Methodology for Agent-Oriented Analysis and Design 233

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. Gmez-Sanz, J. J., Pavn, 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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
234 Garijo, Gmez-Sanz & Massonet

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.
Pavn, J. & Gmez-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,

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
236 Pavn, Gmez-Sanz & Fuentes

Chapter IX

The INGENIAS
Methodology and Tools
Juan Pavn
Universidad Complutense de Madrid, Spain

Jorge J. Gmez-Sanz
Universidad Complutense de Madrid, Spain

Rubn Fuentes
Universidad Complutense de Madrid, Spain

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 toolsthe 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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The MESSAGE Methodology for Agent-Oriented Analysis and Design 235

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., & Wooldridge, M. (2001). Organisational
abstractions for the analysis and design of multi-agent systems. In Pro-
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).

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

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, & Pavn, 2000) tested the application of BDI architecture for agent
behaviour; and Personalized Services for Integrated Internet Information
(Gmez-Sanz, Pavn, & Daz-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 activitiesmore

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The INGENIAS Methodology and Tools 237

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
238 Pavn, Gmez-Sanz & Fuentes

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,

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
240 Pavn, Gmez-Sanz & Fuentes

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The INGENIAS Methodology and Tools 241

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 levelsbetween 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:

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
242 Pavn, Gmez-Sanz & Fuentes

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The INGENIAS Methodology and Tools 243

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:

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
248 Pavn, Gmez-Sanz & Fuentes

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
244 Pavn, Gmez-Sanz & Fuentes

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The INGENIAS Methodology and Tools 245

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
246 Pavn, Gmez-Sanz & Fuentes

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The INGENIAS Methodology and Tools 247

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The INGENIAS Methodology and Tools 249

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
252 Pavn, Gmez-Sanz & Fuentes

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The INGENIAS Methodology and Tools 251

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 agents 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 agents 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
254 Pavn, Gmez-Sanz & Fuentes

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,
Gmez, & Pavn, 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, Gmez-Sanz, & Pavn, 2004) and
the analysis of contradictions ( Fuentes, Gmez-Sanz, & Pavn, 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
250 Pavn, Gmez-Sanz & Fuentes

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The INGENIAS Methodology and Tools 253

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The INGENIAS Methodology and Tools 255

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
256 Pavn, Gmez-Sanz & Fuentes

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The INGENIAS Methodology and Tools 259

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
260 Pavn, Gmez-Sanz & Fuentes

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The INGENIAS Methodology and Tools 261

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)

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The INGENIAS Methodology and Tools 257

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


softwareusually non-agent based softwareidentifying 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 todays developments. Once these
elements have been identified, the developer can determine how the
agents 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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
258 Pavn, Gmez-Sanz & Fuentes

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 Mller 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 Mller
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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
262 Pavn, Gmez-Sanz & Fuentes

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The INGENIAS Methodology and Tools 263

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.)

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
264 Pavn, Gmez-Sanz & Fuentes

Figure 19. Initial description of the interaction obtain book list (To
check notation, see Figure 5)

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
266 Pavn, Gmez-Sanz & Fuentes

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)

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The INGENIAS Methodology and Tools 265

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The INGENIAS Methodology and Tools 267

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)

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
268 Pavn, Gmez-Sanz & Fuentes

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
check notation, see Figure 3)

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
270 Pavn, Gmez-Sanz & Fuentes

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The INGENIAS Methodology and Tools 269

Figure 25. Workflow interconnecting tasks identified in Figure 20 (To


check notation, see Figure 2)

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The INGENIAS Methodology and Tools 271

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@");
alldefined=alldefined && @v@label@/v@!=null;
@/repeat@
@repeat id="condgoals"@
StateGoal @v@label@/v@=getAgent().getGoal("@v@type@/v@");
alldefined=alldefined && @v@label@/v@!=null;
@/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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
272 Pavn, Gmez-Sanz & Fuentes

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
274 Pavn, Gmez-Sanz & Fuentes

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 Gmez-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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The INGENIAS Methodology and Tools 275

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 mthode VOYELLES, dans Systmes Multi-Agents.
Des Thories Organisationnelles aux Applications Industrielles. Oslo,
Norway: Herms.
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., Gmez-Sanz, J. J., & Pavn, 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., Gmez-Sanz, J. J., & Pavn, 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., & Pavn, 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.
Gmez-Sanz, J., Pavn, J., & Daz-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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
276 Pavn, Gmez-Sanz & Fuentes

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
agent-oriented analysis and design. Journal of Autonomous Agents and
Multi-Agent Systems, 3(3), 285-312.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
The INGENIAS Methodology and Tools 273

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-

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Towards Radical Agent-Oriented Software Engineering Processes 279

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Towards Radical Agent-Oriented Software Engineering Processes 281

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 agents 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).

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
278 Taveter & Wagner

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 techniquethe
Business Agents Approachthat 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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
282 Taveter & Wagner

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Towards Radical Agent-Oriented Software Engineering Processes 283

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
286 Taveter & Wagner

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Towards Radical Agent-Oriented Software Engineering Processes 287

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 Sellers 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 Sellers
internal database by decreasing its attribute inventory by the value of the attribute
requestedQuantity of the message received.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
284 Taveter & Wagner

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

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Towards Radical Agent-Oriented Software Engineering Processes 285

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
288 Taveter & Wagner

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.

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
Towards Radical Agent-Oriented Software Engineering Processes 289

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:

Copyright 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

TEAM LinG
290 Taveter & Wagner

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-tec