TEAM LinG
i
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: Development Editor: Senior Managing Editor: Managing Editor: Copy Editor: Typesetter: Cover Design: Printed at:
Renée Davies Kristin Roth Amanda Appicello Jennifer Neidig Jane Conley Cindy Consonery Lisa Tosheff 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:
[email protected] 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 approaches 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 Valérie Camps, IRIT – University Paul Sabatier, France Marie-Pierre Gleizes, IRIT – University Paul Sabatier, France Gauthier Picard, IRIT – University Paul Sabatier, France Chapter VIII The MESSAGE Methodology for Agent-Oriented Analysis and Design .......................................................................................................... 203 Francisco J. Garijo, Telefónica I+D, Spain Jorge J. Gómez-Sanz, Universidad Complutense de Madrid, Spain Philippe Massonet, CETIC, Belgium Chapter IX The INGENIAS Methodology and Tools .............................................. 236 Juan Pavón, Universidad Complutense de Madrid, Spain Jorge J. Gómez-Sanz, Universidad Complutense de Madrid, Spain Rubén Fuentes, Universidad Complutense de Madrid, Spain Chapter X Towards Radical Agent-Oriented Software Engineering Processes Based on AOR Modelling ........................................................................ 277 Kuldar Taveter, The University of Melbourne, Australia Gerd Wagner, Brandenburg University of Technology at Cottbus, Germany
TEAM LinG
v
Chapter XI Multi-Agent Systems Engineering: An Overview and Case Study ... 317 Scott A. DeLoach, Kansas State University, USA Madhukar Kumar, Software Engineer, USA Chapter XII Comparison of Ten Agent-Oriented Methodologies .......................... 341 Quynh-Nhu Numi Tran, University of New South Wales, Australia Graham C. Low, University of New South Wales, Australia Chapter XIII Creating a Comprehensive Agent-Oriented Methodology: Using Method Engineering and the OPEN Metamodel ..................... 368 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 approach—minimizing guidelines 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 developing 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 • ad hoc development • fe w guid elin es • no uniform terminology • projec t ma na ge men t and measurability difficult
Controlled Flexibility • uniformb uildin g b loc ks s elec ted for project situation • guid an ce for each b uildin g b loc k • uniform terminolog y • uniform, meas ura ble p roje ct man ag ement
Control • one s tan dard methodology • rig id g uidelines • uniform terminology • all p roje cts comp ly to same measurable approach
TEAM LinG
vii
•
The Tropos methodology provides guidance for the four major development phases of application development. One of its primary contributions is placing an emphasis on modeling goals and their relationship with the system’s actors, tasks, and resources.
•
MAS-CommonKADS is based on both CommonKADS and object-oriented (OO)-based methodologies. This enables the developer to build agentbased systems while leveraging the experience of pre-agent methodologies and employing familiar techniques and diagrams.
•
The PASSI methodology brings a particularly rich development lifecycle that spans initial requirements though deployment and, in addition, emphasizes the social model of agent-based systems.
•
From an AI planning-execution perspective, Prometheus provides an especially rich goal-driven approach for its BDI-like agents. Its methodology 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 humanbased organizations, Gaia provides an approach that both a developer and a non-technical domain expert can understand—facilitating their interaction.
•
ADELFE is a specialized methodology that emphasizes cooperative agents that self-organize and possibly result in emergent systems. More specifically, it addresses designing complex adaptive systems and anticipating emergence within its software agents.
•
Resulting from a two-year, European-funded EURESCOM project, MESSAGE 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. Using metamodels provides flexibility for evolving the methodology and adopting changes to its notation.
•
RAP is concerned with distributed information systems (such as enterprise 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 robotics 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 approach depicted on the right of Figure 1). This book presents the steps and notations for developing a variety of systems. By putting the methodologies side-by-side, the reader can select those portions relevant. Chapter 12 aids this process with a comprehensive overview and comparison of the various methodologies. Wisely, the approach adopted in the concluding chapter is controlled flexibility. Here, the most valuable building blocks—or method fragments—can be identified and extracted from each of the described methodologies and placed into a method repository. Such a repository will provide a broad set of reusable techniques that can be assembled based on the individual application’s profile. By providing such a full range of methodologies, this book creates a balance between being evolutionary and revolutionary. On the one hand, the agentbased approach is not vastly different from current approaches. If a methodology 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 decades 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 system development does differ from the conventional way of producing IT systems. Therefore, an agent methodology—even though it must still address and incorporate non-agent development requirements—is markedly different from traditional IT practices. Agents bring a new approach to developing systems. To one extent or another, the methodologies in this book involve identifying and incorporating those methodological features that make the agent-based approach possible while exploiting already-recognizable and time-tested processes. This is important for two reasons. Firstly, we need to communicate clearly to developers those steps necessary to create a successful agent-based implementation. Secondly, we must show why agent-based methodologies improve on traditional approaches—while still addressing those conventional aspects of an application. In closing, I would like to say that I highly recommend this book as a guide to those developers and researchers involved in building agent-based applications.
TEAM LinG
ix
It provides a wealth of guidelines, techniques, and notations for developing a variety of systems. Hence, I expect that its state-of-the-art approaches will heavily influence how the next generation of agent-based systems will be developed. James J. Odell
Reference Harmsen, F., Brinkkember, S., & Oei, H. (1994). Situational method engineering 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 methodological approach to solving the problem and giving software developers the tools they need to comprehensively create applications within management and market constraints—money, time, quality, and so forth. With increasingly sophisticated applications being demanded by businesses aiming for a competitive market advantage, object technologies are being supplemented and complemented 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 users, and is sufficiently secure to protect personal data and other assets on behalf of its stakeholders. To fulfil these requirements, builders of systems need an appropriate agent-oriented methodology—the topic of this book. Agent technology, increasing in popularity over the last decade, represents a concrete response to these new requirements. The main reason for this is that the agent paradigm, along with its definition of agent as an autonomous and proactive system capable of interacting with other agents in order to satisfy its objectives, provides a natural evolution for software systems. Agent-based systems 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 methodologies 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 methodologies) that leads to industry rejection—spoiled for choice leads to “no choice” because it is unclear whether any of the individualistically proposed methodologies 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 features. The book is organized as follows. Chapter I introduces what an agentoriented 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 presents 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 describe their work in the same way for each chapter. Within the space constraints 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, omissions 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 modelling, it is inevitable that some omissions and approximations will be used. Stating 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 authors used non-UML-like notations that they defined them in situ. While the OO basis of many of these AO methodologies is evident (and discussed in more detail in Chapter I), it should be noted that a group of methodologies 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 methodological 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 characteristics 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 proposed new technology—here, agent technology. This book aims to be a first step in that direction. By presenting each methodology in as similar a light as possible and by undertaking a feature analysis, we can hope to gain insights, as researchers, into what works and what doesn’t. As coalescence is encouraged, these ideas need to be tried out “for real” in industry applications. This is already 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 supplemented by an independent analysis (Chapter XII), we also propose a way forward 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” methodology 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 contributions and their patience in assisting us in putting together this book. We also owe them double thanks, since all chapters were reviewed by two people—the chapter authors again. In addition, we wish to thank, as valuable additional reviewers, John Debenham and Cesar Gonzalez-Perez of the University of Technology, Sydney. We trust that our joint effort will be a stimulus for industry in accepting and adopting the agent paradigm in the development of software systems. Brian Henderson-Sellers, Sydney, Australia Paolo Giorgini, Trento, Italy
TEAM LinG
xiv
TEAM LinG
Agent-Oriented Methodologies: An Introduction 1
Chapter I
Agent-Oriented Methodologies: An Introduction Paolo Giorgini University of Trento, Italy 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 agentoriented 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 industrydriven—most AO methodologies are supported by small teams of academic researchers. Based on an observation that the coalescence of groups of OO methodologies in the late 1990s led to an increased take-up by industry of the object-oriented paradigm for system development and project management, this book aims to encourage first the coalescence and collaboration between research groups and then, hopefully, more rapid industry adoption of AO methodological approaches. In other words, most AO methodologies are (at the time of writing) in an early stage and still in the first context of mostly “academic” methodologies for agent-oriented systems development, albeit that many of these methodologies have been tested in small, industrial applications. One purpose of this book is to identify those predominant and tested AO methodologies, characterize them, analyse them, and seek some method of unification and consolidation with the hope that, in so doing, the community of scholars supporting AO methodologies will soon be able to transfer those innovative ideas into industry acceptance. This means mimicking the OO transition curve by seeking consolidation. One means of such consolidation is discussed in the last chapter of the book: the use of a method engineering framework (e.g., Martin & Odell, 1995) to create a repository of agent-oriented method fragments.
Agents and Multi-Agent Systems Defining agents is not straightforward. There are many opinions, some of which you will see reflected in later chapters of this book (see also discussions in, for example, Luck, Ashri & D’Inverno, 2004). The key characteristics of agents are widely understood to be highly autonomous, proactive, situated, and directed software entities. Other characteristics such as mobility are optional and create a special subtype of agent; whereas some characteristics cannot be used as determining factors since they are really grey shades of a scale that encompasses 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 communications 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 components 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 contract 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 topdown 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 MAScommonKADS). 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 development 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 multiagent 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 MASs—arguably, simple extensions of OO methodologies are too highly constrained by the sole focus on objects. Thus, an AO methodology needs to focus on an organized society of agents playing roles within an environment. Within such an MAS, agents interact according to protocols determined by the agents’ roles. We should also ask what it means for a methodology to be “agent-oriented” in the sense that we talk of an OO methodology in the context of object technology. In this case, however, object technology has two foci. In an OO methodology, we use OO concepts to describe the methodology, which, in turn, can be used to build object-oriented systems. In contrast, when we speak of an AO methodology, we generally do not mean a methodology that is itself constructed on agent-oriented principles but merely one that is oriented towards the creation of agent-based software. Thus, all the chapters except one follow this “definition.” 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 methodologies, 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) MaSE
INGENIAS
Tropos
MESSAGE Adelfe RAP AOR
AAII RUP
OMT
Gaia Fusion
Agent OPEN 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 methods. In particular, MaSE (DeLoach, 1999; Wood & DeLoach, 2000) acknowledges 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 compatible 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 genealogical link to other approaches, OO or AO. Discussed in this book is Tropos (Bresciani, Giorgini, Giunchiglia, Mylopoulos, & Perini, 2004; Castro, Kolp, & Mylopoulos, 2002; Giorgini, Kolp, Mylopoulos, & Pistore, 2004). Tropos has a significant input from i* (Yu, 1995) and a distinct strength in early requirements modelling, focusing as it does on describing the goals of stakeholders that describe the “why” as well as the more standard support for “what” and “how.” This use in Tropos of the i* modelling language (particularly in the analysis and design phases) gives it a different look and feel from those that use Agent UML (a.k.a. AUML; Odell et al., 2000) as a notation. It also means that the non-OO mindset permits users of Tropos to take a unique approach to the modelling of agents in the methodological context. Other approaches not covered in this book include Nemo (Huget, 2002), MASSIVE (Lind, 1999), Cassiopeia (Collinot & Drogoul, 1998; Collinot, Drogoul, & Banhamou, 1996) and CAMLE (Shan & Zhu, 2004)—although in CAMLE there are some parallels drawn between its notion of “caste” and the concept of an OO class, as well as some connection to UML’s composition and aggregation relationships. Further comparisons of these methodologies are undertaken in Chapter 12, which complements and extends earlier framework-based evaluative studies of, for instance, Cernuzzi and Rossi (2002), Dam and Winikoff (2004), Sturm and Shehory (2004) and Tran, Low and Williams (2004).
Common Terms/Concepts Used in the AO Methodologies The basic set of concepts underlying agent-oriented (AO) methodologies and the associated agent terminology are not universally agreed upon. Nevertheless, there is sufficient agreement to make it worthwhile for us to summarize commonly agreed upon terms here in Chapter 1 in order that authors of later chapters need not repeat this material. Bear in mind, however, that each methodological approach may treat these terms and their underpinning conceptual base slightly differently—as will be pointed out when necessary. Agents are often contrasted with objects and the question —“What makes an agent an agent and not an object?” – is particularly difficult to answer when one considers the concepts of “active objects” in an OO modelling language such as the UML. The novelty of agents is said to be that they are proactive (as well as reactive), have a high degree of autonomy, and are situated in and interact with their
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 agent’s knowledge at various granularity levels, while Desires, which represent heterogeneous objectives 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
Percept
{consisten t set of}
Figure 2. Metamodel fragment showing, inter alia, the links between goals and tasks
Belief
Event
Desire
Goalbank *
leads to
can
tr i g g
Action (a.k.a. Task)
1
er n ew
Goal { cons ists of}
1
Intention
1 leads to
Plan
*
Table 1. Relationships between terminology of BDI model (after HendersonSellers et al., 2005) Viewpoint
Column 3
Psychology
Belief
Desire
Design/Model Implementation
World Model Goal Knowledge Base -
Column 3 + Commitment Intention Commitment -
Wherewithal (“how”) Plan 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 Internal Characteristic
Agent External Characteristic
Belief
Knowledge Repository
Desire
Goal or Goalbank
Intenti on
Commitment
com mi tte d: TRU E
com mi tte d: TRU E 1 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 methodologies 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 reintroduce 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 discussion 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, MASCommonKADS 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 Applications 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. Lespérance, G. Wagner, & E. Yu (Eds.), Proceedings of Agent-Oriented Information Systems, AOIS-2002 (p. 1-15). AOIS.org. Booch, G. (1994). Object-oriented analysis and design (2nd ed.). Redwood City, CA: The Benjamin/Cummings Publishing Company, Inc. Bresciani, P., Giorgini, P., Giunchiglia, F., Mylopolous, J., & Perini, A. (2004). Tropos: An agent-oriented software development methodology. Autonomous Agents and Multi-Agent Systems, 8(3), 203-236. Burrafato, P. & Cossentino, M. (2002). Designing a multi-agent solution for a bookstore with the PASSI methodology. In P. Giorgini, Y. Lespérance, G. Wagner & E. Yu (Eds.), Proceedings of the Agent-Oriented Information Systems 2002 (pp. 102-118). AOIS.org. Caire, G., Coulier, W., Garijo, F., Gomez, J., Pavon, J., Leal, F., Chainho, P., Kearney, P., Stark, J., Evans, R., & Massonet, P. (2001). Agent-oriented analysis using MESSAGE/UML. In M. Wooldridge, G. Wei, & P. Ciancarini (Eds.), Agent-oriented software engineering II (p. 119-135). LNCS 2222. Berlin: Springer-Verlag. Castelfranchi, C., Dignum, F., Jonker, C., & Treur, J. (2000). Deliberate normative agents: Principles and architectures. In N. Jennings & Y. Lespérance (Eds.), Intelligent agents VI (p. 364-378). Berlin: SpringerVerlag. Castro, J., Kolp, M., & Mylopoulos, J. (2002). Towards requirements-driven information systems engineering: The Tropos project. Information Systems, 27(6), 365-389. Cavedon, L. & Sonenberg, L. (1998). On social commitment, roles and preferred goals. In Proceedings of the Third International Conference on MultiAgent Systems (ICMAS), July 3-7, Paris (pp. 80-87). IEEE Computer Society. Cernuzzi, L. & Rossi, G. (2002). On the evaluation of agent oriented methodologies. 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). Objectoriented 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(23), 127-147. Collinot, A., Drogoul, A., & Benhamou, P. (1996). Agent-oriented design of a soccer robot team. In Proceedings of the Second International Conference on Multi-Agent Systems (ICMAS’96) (pp 41-57). Menlo Park, CA: American Association for Artificial Intelligence. Cossentino, M. (2005). From requirements to code with the PASSI methodology. In B. Henderson-Sellers & P. Giorgini (Eds.), Agent-oriented methodologies (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 Engineering Research and Practice (SERP’02), Las Vegas, June 24-27 (pp. 315-321). Dam, K.H. & Winikoff, M. (2004). Comparing agent-oriented methodologies. In P. Giorgini, B. Henderson-Sellers, & M. Winikoff (Eds.), Agent-oriented systems (pp. 78-93). LNAI 3030. Berlin: Springer-Verlag Dardenne, A., Lamsweerde, A. v., & Fickas, S. (1993).Goal-directed requirements 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. 160190). 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 Information Systems (AOIS ’99), May 1, Seattle. AOIS.org. Faber J. (1999). Multi-agent systems: An introduction to distributed artificial intelligence. Reading, MA: Addison-Wesley. Firesmith, D.G. & Henderson-Sellers, B. (2002). The OPEN process framework. 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? Journal 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 agentoriented 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 methodology. 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 methodological 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 developing agent based systems for enterprise integration. In P. Bernus & L. Nemes (Eds.), Modelling and methodologies for enterprise integration. 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 Autonomous Agents in a Multi-Agent World (MAAMAW’96) (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., & D’Inverno, M. (2004). Agent-based software development. 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/~publicwebspace/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 National 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 documents). Available online http://www.omg.org Padgham, L. & Winikoff, M. (2002a). Prometheus: A methodology for developing intelligent agents. In F. Giunchiglia, J. Odell, & G. Weiß (Eds.), Agentoriented Software Engineering III Proceedings of the Third International Workshop on Agent-Oriented Software Engineering (AAMAS’02) (pp. 174-185). LNCS 2585. Padgham, L. & Winikoff, M. (2002b). Prometheus: A pragmatic methodology for engineering intelligent agents. In J. Debenham, B. Henderson-Sellers, N. Jennings, & J.J. Odell (Eds.), Agent-oriented Software Engineering III Proceedings of the Workshop on Agent-oriented Methodologies at OOPSLA 2002, November 4, Seattle (pp. 97-108). Sydney: Centre for Object Technology Applications and Research. Pavón, J., Gomez-Sanz, J., & Fuentes, R. (2005). The INGENIAS methodology and tools. In B. Henderson-Sellers & P. Giorgini (Eds.), Agent-oriented methodologies (Chapter 4). Hershey, PA: Idea Group. Rao, A.S. & Georgeff, M.P. (1995). BDI agents: From theory to practice. In V.R. Lesser & L. Gasser (Eds.), Proceedings of the First International
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: PrenticeHall. 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 International Workshop on Software Engineering for Large-Scale MultiAgent 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: SpringerVerlag. Taveter, K. & Wagner, G. (2005). Towards radical agent-oriented software engineering processes based on AOR modelling. In B. Henderson-Sellers & P. Giorgini (Eds.), Agent-oriented methodologies (Chapter 10). Hershey, PA: Idea Group. Tran, Q.-N.N., Low, G., & Williams, M.-A. (2004). A preliminary comparative feature analysis of multi-agent systems development methodologies. In Proceedings of AOIS@CAiSE*04, Faculty of Computer Science and Information, Riga Technical University, Latvia (pp. 386-398). Wagner, G. (2003). The agent-object relationship metamodel: Towards a unified view of state and behaviour. Inf. Systems, 28(5), 475-504. Winikoff, M., Padgham, L., & Harland, J. (2001). Simplifying the development of intelligent agents. In M. Stumptner, D. Corbett, & M. J. Brooks (Eds.), Proceedings of the 14th Australian Joint Conference on Artificial Intelligence (AI’01), Adelaide, 10-14 December (pp. 557-558). LNAI 2256, Springer-Verlag. Wood, M. & DeLoach, S.A. (2000). An overview of the multiagent systems engineering methodology. In P. Ciancarini & M. Wooldridge (Eds.), Proceedings of the 1st International Workshop on Agent-Oriented
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, SpringerVerlag. 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 Proceedings 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 Engineering 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 everchanging 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 ebusiness 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 environment is understood in terms of actors, responsibilities, objectives, tasks, and resources, while their inner environment is conceived as a collection of (software) modules, entities (e.g., objects, components), data structures, and interfaces. 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 traditionally 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 objectoriented 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, throughout 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? Requirements 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 environment, 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 operational environment, along with relevant functions and qualities.
•
Architectural design, where the system’s global architecture is defined in terms of subsystems, interconnected through data, control, and other dependencies.
•
Detailed design, where the behavior of each architectural component is further refined.
The proposed methodology includes techniques for generating an implementation 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 documentation 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 concerned with understanding the organizational context within which the systemto-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 requirements. 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 relationships with other actors. These models have been formalized using intentional concepts from Artificial Intelligence, such as goal, belief, ability, and commitment (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 actors—the depender and the dependee. The depender depends on the dependee to deliver on the dependum. The dependum can be a goal to be fulfilled, a task to be performed, or a resource to be delivered. In addition, the depender may depend on the dependee for a softgoal to be fulfilled. Softgoals represent vaguely defined goals with no clear-cut criteria for their fulfillment. Graphically, actors are represented as circles; dependums—goals, softgoals, tasks and resources—are respectively represented as ovals, clouds, hexagons, and rectangles; and dependencies have the form depender → dependum → dependee. Actor diagrams are extended during early requirements analysis by incrementally 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 decomposed 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 dependencies 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 software 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, Organization 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 organizational 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 Technostructure 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 standardizing 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 organizational 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 transactions. 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 international 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 Market Share
Depender
X Dependee Dependency
Goal
Task
Resource
Softgoal
Actor Consult Catalogue
Customer
Buy Media Items
Happy Customers
Media Items
Media Shop
Continuous Supply
Legend
Media Supplier
Quality Packages
Media Producer
Continuing 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 postulates 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 accomplish 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 Cpy
Bank Cpy
Communication Services
Process Internet Orders
Medi@
Increase Market Share
Run Shop
Handle Billing
Buy Media Items
OrderBy Internet
Run Shop Customer
Media Shop
Improve Service
Manage Staff
Staff Training
Happy Customers
Manage Inventory
Be Friendly Satisfy Customer Desires
Media Supplier
OrderBy Phone
Handle Customer Orders
Select Items
OrderIn Person
Determine Amount
Sell Stock
Enhance Catalogue
Consult Catalogue
Media Items
Continuing Business
Continuing Supply
Depender
X Dependee Dependency
Actor
Goal
Task
Resource
Softgoal
Decomposition link Means-ends link Legend
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
Browse Catalogue
Keyword Search
Internet Services
Medi@
Place Order
Telecom Cpy
Process On-line Money Transactions
Customer
Find User New Needs
Bank Cpy Security
Adaptability
Accounting Process Internet Orders
Communication Services Continuing Business
Buy Media Items Media Shop Increase Market Share
Media Items
Happy Customers
Continuing Supply
Media Supplier
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 subactors 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 subgoal 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 system 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 requirement 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@
Telecom Cpy
Process Internet Orders
Internet Services
Adaptability
Process On-line Money Transactions Availability
Increase Market Share
Media Shop
++
Bank Cpy
Security
++ Update Catalogue
Customer
Internet Shop Managed
Produce Statistics
Attract New Customer
Adaptabl e ++
Internet Orders Handled
Adaptation
+
Database Querying
-
Catalogue Consulting
Place Order +
+ Shopping Cart
Update GUI
Pick Available Item
Keyword Search
+
Monitoring System
Select Item
-
Secure
System Evolution
Browse Catalogue
Available
Item Searching Handled
Add Item
Get Identification Detail
Standard Form Order
Check Out
Pre-Order Non Available Item
Classic Communication Handled
Phone Order
Buy Media Items
Secure Form Order
Internet Handled
Fax Order
Medi@
Find User New Needs
Media 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, Adaptability) in the late requirements model. The first goal is Availability because we propose to allow system agents to automatically decide at run-time which catalogue browser, shopping cart, and order processor architecture best fit customer needs or navigator/platform specifications. Moreover, we would like to include different search engines, reflecting different search techniques, and let the system dynamically choose the most appropriate. The second key softgoal in the late requirements specification is Security. To fulfill this, we propose to support a number of security strategies in the system’s architecture and let the system decide at run-time which one is the most appropriate, taking into account environment configurations, Web browser specifications, and network protocols used. The third goal is Adaptability, meaning that catalogue content, database schema, and architectural model can be dynamically extended or modified to integrate new and future Web-related technologies.
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 decomposed 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 information (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 Transaction
Adaptability Management
Handle Orders & Billing
Billing Processor
Authority & Strategic Decision
Coordinator
Coordinate E−Shopping Billing
Orders
Store Front
Security Management
Strategic Information
Statistical Information
Manage Catalogue Browsing
Back Store
Update & Back−up Information
Product Information
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 Product 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 Information Broker, which satisfies the Shopping Cart’s requests of information by accessing the Product Database. The Source Matchmaker applies the matchmaker pattern to locate the appropriate source for the Information Broker, and the monitor pattern is used to check any possible change in the Product Database. Finally, the mediator pattern is applied to dispatch the interactions between the Information Broker, the Source Matchmaker, and the Wrapper, while the wrapper pattern forms the interaction between the Information Broker and the Product Database. Figure 8 shows the remote administrative tool for the information broker of Figure 7. The customer sends a service request to the broker requesting the buying or selling of DVDs. He/she chooses which DVDs to sell or buy, selects the corresponding DVD titles, the quantity, and the deadline (the time-out before which the broker has to realize the requested service). When receiving the customer’s request, the broker interacts with the Media Shops. The interactions between the Broker and the Media Shops are shown in the bottom-right corner of the figure. Figure 7. Decomposing the Store Front with social patterns Shopping Cart Provide Item Data
Handle Cancelation Request
Advertise Source Location Locate Source
Notify Update
Monitor
Info Broker
Fwd Source Change
Profile Customer
Source Matchm.
Mediator
Query Information Source
Route Info Request
Ask for Info Advertising
Translate Response Wrapper
Product Database
Provide Information
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 implemented as an aggregation of several CartForms and ItemLines. To specify the checkout operation identified in Figure 9, extensions of interaction 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
CustomerProfiler
ShoppingCart
«Text» itemCount : integer «Text» qty[0..*] : integer «Text» currentTotal : currency «Checkbox» selectItem[0..*] «Submit» Checkout «Submit» AddItem «Submit» Confirm «Button» Cancel «Button»Recalculate
0..* CustomerProfileCard customerid : long customerName : string firstName :string middleName : string address : string tel : string e−mail : string dob : date profession : string salary : integer maritalStatus : string familyComp[0..1] : integer internetPref[0..10] : boolean entertPref[0..10]:string hobbies[0..5] : string comments : string creditcard# : integer prevPurchase[[0..*] [0..*]] : string prevPurchPrice[[0..*] [0..*]] : integer
getCart() buildItemTable() writeTableRow() updateItems() loadCartForm() updateCartForm() killCartForm() 0..* CustomerData 1
ItemLine id : long qty : integer allowsSubs :boolean
On−line Catalogue 0..* MediaItem id : long itemNbr : string itemTitle : string itemBarCode : OLE itemPicture : OLE category :string genre : string description : string editor : string publisher : string date : date unitPrice : currency weight : single
ItemDetail
0..* Book
DVD
weight() cost()
«i* actor»
itemCount : integer tax : currency taxRate : float total : currency totWeight : single shippingCost : currency qty[0..*] : integer subTotals[0..*] : currency itemCount() notification() calculateTotals() calculateQty() computeWeight() inform() getLineItem() initializeReport() Plans: refuse initialize selectItem propose succeded addItem removeItem checkout confirm cancel failure logout 0..* verifyCC not_understood getIdentDetails 0..* 1
Video
1 ...
CD
CDrom
Figure 10. Agent interaction protocol focusing on a checkout dialogue <
> Customer
<> Shopping Cart
checkout−request for proposal refuse
Timeout 12/19/00 9:31 53 FIPA Contract Net Protocol
not−understood
X
Notification
propose cancel−proposal Decision
X
accept−proposal
succeeded X failure
Customer, Shopping Cart 12/19/00 at 9:31 53 checkout−rfp, refuse, not−understood, propose, cancel−proposal accept−proposal, succeeded, failure
inform 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 descriptions 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 activated]), 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()
Fields Checking
[Mandatory fields filled] /verifyCC() Credit Card Checking [i=5]
[[Not all mandatory fields filled] ^ [i<5]]
[[CC# not valid] ^ [i<3]]
[i=3]
Press confirm button /confirm()
[Not confirmed] / cancel()
Item Registering Items Registered
[foreach selected item]
Updated
Fields Updated Fields Updating
[CC# valid] / confirm()?
CC# Correcting
[foreach registered item] succeeded / shoppingcart.logout()
Stock Records Updating
Final Amounts Calculating
Records updated
Amounts calculated
[new customer] succeeded / shoppingCart.logout()
Displaying Report
pass / orderProcessor. processOrder(this)
profile [report asked] / initializeReport() updated fail /shoppingCart.logout()
Customer Profile Updating
[Already registered]
any [[Cancel button pressed] OR [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 interrelationships?
We believe that the methodology is particularly appropriate for generic, component-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 requirements-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, Louvainla-Neuve, Recife and elsewhere—for useful comments, discussions, and feedback.
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, Agents’98, St. Paul, Minnesota, May 9-13 (pp. 108115). New York: ACM Press. Bauer, B., Muller, J., & Odell, J. (2001). Agent UML: A formalism for specifying multiagent interaction. Proceedings of the 1st International Workshop on Agent-Oriented Software Engineering, AOSE’00, Limerick, Ireland, June 10, 2000 (pp. 91-104). Springer. Booch, G., Rumbaugh, J., & Jacobson, I. (1999). The unified modeling language: User guide. Reading, MA: Addison-Wesley. Castro, J., Kolp, M., & Mylopoulos, J. (2002). Towards requirements-driven information systems engineering: The Tropos project. Information Systems, 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 requirements 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 architectures for information systems. In Proceedings of the 5th International Conference on Enterprise Information Systems, ICEIS’03, Angers, France, April 22-26 (pp. 89-96). EST Setubal. Do, T. T., Kolp, M. & Pirotte, A. (2003). Social patterns for designing multiagent systems. In Proceedings of the 15th International Conference on Software Engineering and Knowledge Engineering, SEKE’03, San Francisco, July 1-3 (pp. 103-110). Knowledge System Institute. Finin, T., Labrou, Y., & Mayfield, J. (1997). KQML as an agent communication language. In J. Bradshaw (Ed.), Software agents (pp. 291-317). Cambridge, MA: MIT Press. Gamma, E., Helm, R., Johnson, J., & Vlissides, J. (1995). Design patterns: Elements of reusable object-oriented software. Reading, MA: AddisonWesley. 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 Conference on Autonomous Agents, Agents’99, Seattle, May 1-5 (pp. 112-113). ACM Press. Kinny, D. & Georgeff, M. (1996). Modelling and design of multi-agent systems. In Proceedings of the 3rd International Workshop on Intelligent Agents: Agent Theories, Architectures, and Languages, ATAL’96, Budapest, Hungary (pp. 1-20). Kolp, M., Giorgini, P., & Mylopoulos, J. (2001). A goal-based organizational perspective on multi-agents architectures. Proceedings of the 8th International Workshop on Intelligent Agents: Agent Theories, Architectures, and Languages, ATAL’01, Seattle, August 1-3 (pp. 128-140). Springer. Kolp, M., Giorgini, P., & Mylopoulos, J. (2002). Organizational multi-agent architectures: A mobile robot example. Proceedings of the 1st International Conference on Autonomous Agents and Multi-Agent Systems, AAMAS’02, Bologna, Italy. Kolp, M., Giorgini, P., & Mylopoulos, J. (2003). Organizational patterns for early requirements analysis. Proceedings of the 15th International Conference on Advanced Information Systems, CAiSE’03, Velden, Austria, June 16-18 (pp. 617-632). Springer. Kruchten, P. (2003). The rational unified process: An introduction. Reading, MA: Addison-Wesley. Labrou, Y., Finin, T., & Peng, Y. (1999). The current landscape of agent communication languages. Intelligent Systems, 14(2), 45-52. Mintzberg, H. (1992). Structure in fives: Designing effective organizations. Upper Saddle River, NJ: Prentice-Hall. Morabito, J., Sack, I., & Bhate, A. (1999). Organization modeling: Innovative architectures for the 21st century. Upper Saddle River, NJ: Prentice Hall. Mylopoulos, J., Kolp, M., & Castro, J. (2001). UML for agent-oriented software development: The Tropos proposal. Proceedings of the 4th International Conference on the Unified Modeling Language, UML’01, Toronto, Canada, October 1-5 (pp. 422-442). Springer. 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, AOIS’00, Austin, TX, June 10 (pp. 121-140). Springer. Object Management Group (OMG) (1999). OMG unified modeling specification. Available online http://www.omg.org Perini, A., Bresciani, P., Giunchiglia, F., Giorgini, P., & Mylopoulos, J. (2001). A knowledge level software engineering methodology for agent-oriented programming. Proceedings of the 5th International Conference on Autonomous Agents, Agents’01, Montreal, Canada, May 28-June 1 (pp. 648-655). Springer. Scott, W. (1998). Organizations: Rational, natural, and open systems. Upper Saddle River, NJ: Prentice Hall. Shaw, M. & Garlan, D. (1996). Software architecture: Perspectives on an emerging discipline. Upper Saddle River, NJ: Prentice Hall. Wirfs-Brock, R., Wilkerson, B., & Wiener L. (1990). Designing objectoriented 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 Requirements Engineering, RE’93, San Jose, CA, January 4-6 (pp. 34-41), IEEE Computer Society. Yu, E. (1994). Understanding “why” in software process modeling, analysis and design. Proceedings of the 16th International Conference on Software Engineering, ICSE’94, Sorrento, Italy, May 16-21 (pp. 159-168). IEEE Computer Society. Yu, E. (1995). Modelling strategic relationships for process reengineering. PhD thesis, University of Toronto, Department of Computer Science. Yu, E. & Mylopoulos, J. (1996). Using goals, rules, and methods to support reasoning in business process reengineering. International Journal of Intelligent Systems in Accounting, Finance and Management, 5(1), 113.
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 MASCommonKADS that extends object-oriented and knowledge engineering techniques for the conceptualisation of multi-agent systems. MASCommonKADS 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. MASCommonKADS distinguishes several development phases: conceptualisation, where the system is conceived as a multi-agent system and where agent properties of the system are identified; analysis, where different models are developed in order to analyse the system from different points of view; design, where the different models are operationally focussed; and development and testing, which are not addressed explicitly in the methodology. MAS-CommonKADS (Iglesias, 1998; Iglesias, Garijo, González, & Velasco, 1998) can be used in combination with other methodologies. For example, some of its conceptualisation techniques, such as Class-Responsibility-Collaboration (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 techniques, such as CRC cards, use cases, Message Sequence Charts (MSC) (ITU-Z.120, 1996) or Specification and Description Language (SDL) (ITUT-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 objectoriented 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 specifications (the design model) ready to be implemented. The internal architecture of every agent and the “network architecture” of the system are determined.
•
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 capabilities, 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 interactions and the human factors for developing these user interfaces. This model uses standard techniques for developing user interfaces and, consequently, 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 facilities); 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 conceptualising 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 conceptualising a system from an agent-oriented perspective. This technique can be used for conceptualising a particular autonomous agent or the general requirements 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 environment, and this environment needs to be modelled. In particular, we are interested in modelling how the system can act and react to this environment. 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 responsibilities 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 environment?
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 templates.
•
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 “includes.” 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 condition (whether the reaction has been effective or not).
Responsibility-Driven Analysis Responsibility- or goal-driven analysis deals with the definition of the requirements 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
Use Case
Software Agent
Human Agent
Reactive Case
Goal Case 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
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 describing the interactions and the coordination protocols between the agents.
•
Knowledge Modelling: modelling of the knowledge about the domain, the agents (knowledge needed to carry out the tasks and their proactive behaviour), and the environment (beliefs and inferences of the world, including the rest of the agents).
•
Organisation Modelling: developing the organisation model. Depending on the type of project, it may be necessary to model the organisation of the enterprise in which the MAS is going to be introduced for studying the feasibility of the proposed solution. In this case, two instances of the organisation model are developed—before and after the introduction of the MAS. This model is also used to model the software agent organisation.
The Agent Model The agent model acts as a link between the rest of the models of MASCommonKADS, 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 technique—see above.
•
Application of the enhanced CRC cards (Figure 2)—see above
Once the agents have been identified, every agent should be further described using textual templates that collect the main characteristics of the agents, such as its name, type, role, position, a description, offered services, goals, skills (sensors and effectors), reasoning capabilities, general capabilities, norms, preferences, and permissions. The process of filling in these templates helps the engineer to review his/her understanding of the problem and serves as a means of communication with the rest of the team.
The Task Model The task model describes all the activities (so-called tasks) that should be performed in order to achieve a goal. Tasks are decomposed following a top-down approach and described in an “and/ or” tree. The description of a task includes its name, its goal, a short description, input and output ingredients, task structure, its control, frequency of application, preconditions, and required capabilities of the performers.
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 2
Task 1
Task 1.1
Task 1.2
Task 1.3
Task 3
Task 3.1
O
Task 4 O
Task 3.2
Task 4.1
Task 4.2
O Parallel decomposition
Sequential decomposition
Optional task
Iterative task
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 multiagent 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 decomposition 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 mockup); and (2) analysis of the interactions and determination of complex interactions (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 techniques 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 interchanged 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: synchronous, 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 Highlevel 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 expression 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 multiagent 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 characteristics 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 decomposition structures.
•
Problem-Solving Method: during the design we should specify a Problem-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 relationship 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 relationships between software agents can be modelled as a result of the analysis. Figure 5. Organisation model notation mental state
⎨
Goals Plans Beliefs
external interface
⎨
Sensors Actuators Services
association role
role
inheritance
group
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 environment. 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 (socalled 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 service, de/registering and subscription service, security level, encryption 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 primitives, 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 expressed 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 resources 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 meeting
PA1 ::Personal Agent
Avoid low battery
coordinate meeting
Learn preferences
coordinate meeting
Avoid Calendar conflicts
PDA
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 Goals Avoid Calendar conflicts
Class: Personal Agent Plans
Knowledge
Suggest User to choose
Calendar Ontology
Try to group
Collaborator
Service
User
Personal Agent
Change 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 CollectCoordinator-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 Coordinator Requirement
2. Select range of dates
3. Select attendees
4.2 Send CFP / Receive answers
4. Negociate
4.1 Decide Negotiate / End
5. Confirm
5.1 Confirm user
5.2 Notify 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 process. 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
decision
abstract case match
specify
norm value
norms
select
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 represents 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 keywords degree-expertise projects calendar
Meeting proposal receives
keywords Project length dates
Figure 16. Hierarchy of criteria for selecting attendees selection - criterion
dates fits calendar
expertise degree
position in 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 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
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 information 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
T
Participants
propose (range-of-dates) loop(0,n) inform (subrange-of-dates)
inform (definitive-date)
be modelled (for example, with or without negotiation, and how the agent should select one or another protocol). In the case study, there are two identified roles in this conversation (coordinator and participant). The coordinator sends to the participants a meeting description with a range of potential dates and receives in a certain period the answers with subranges of the initial range. Then, the coordinator decides a date and notifies all participants. The notation of the model is based on MSC (ITU-Z.120, 1996) for the interactions and SDL (ITU-T-Z.100, 1994) for processing these interactions. Alternative notations are UML2.0 Interaction Diagrams, which incorporate most of the characteristics of MSC and SDL, and AUML Interaction diagrams (Beuer, Müller, & Odell, 2001). In order to illustrate the application of other models, we will develop here the task of the task model. The MSC diagram is shown in Figure 18.
Organisation Model The organisation model’s agent model uses the organisation model diagram (Figure 19). In this example, there only two positions in the organisation, depending on the scheduled meeting: Coordinator or Participant. The organisational
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 coordinator
Scheduled meeting
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, Communication, 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 perspectives (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, MASCommonKADS 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, symbolicconnectionist systems. Other researchers have also successfully applied MASCommonKADS for flights reservation (Arenas & Barrera-Sanabria, 2002), development of organisational memories (Arenas & Barrera-Sanabria, 2003), elearning (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 Knowledgebased Software Engineering. IOS Press. Arenas, A. & Barrera-Sanabria, G. (2003). Modelling intelligent agents for organisational memories. In Knowledge-based Intelligent Information and Engineering Systems, Lecture notes in computer science 2773 (pp. 430-437). Berlin: Springer-Verlag. Beck, K. (1999). Extreme programming explained: Embrance change. Boston: Addison-Wesley Professional. Beck, K. & Cunningham, W. (1989). A laboratory for teaching object-oriented thinking. In OOPSLA’89 Conference Proceedings, New Orleans, LA, USA (Vol. 17, pp. 1-6). Bauer, B., Müller, J. P., & Odell, J. (2001). Agent UML: A formalism for specifying multiagent interaction. In P. Ciancarini & M. Wooldridge (Eds.), Agent-oriented software engineering (pp. 91-103). Berlin: SpringerVerlag.
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 dell’Associazione Italiana per l’Intelligenza Artificiale. Available online from http://www-dii.ing.unisi.it/aiia2002/paper.htm Cowan, D. & Griss, M. (2002). Making software agent technology available to enterprise applications, Technical report HP-2002-211, HewlettPackard 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-oriented 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 management. In Proceedings of the 13th International Association of Maritime Economist (IAME) Conference, Busan, Korea (pp. 314-331). Iglesias, C. A. (1998). Definition of a methodology for the development of multiagent systems. PhD thesis, Technical University of Madrid (in Spanish). Iglesias, C. A. & Garijo, M. (1999). UER technique: Conceptualisation for agent-oriented development. In Proceedings of the 3rd World Multiconference on Systemics, Cybernetics and Informatics (SCI’99) and 5th International Conference on Information Systems Analysis and Synthesis (ISAS’99) (Vol. 5, pp. 535-540). International Institute of Informatics and Systemics. Iglesias, C. A., Garijo, M., González, J. C., & Velasco, J. R. (1998). Analysis and design of multiagent systems using MAS-CommonKADS. In N. Callaos & M. Torres (Eds.), Intelligent agents IV: Agent theories, architectures and languages, LNAI 1365 (pp. 313-326). Berlin: Springer-Verlag. ITU-T-Z.100 (1994). CCITT specification and description language (SDL). Technical report, ITU-T. ITU-Z.120 (1996). Message Sequence Chart (MSC). ITU. Z.120. Technical report, ITU-T. Geneva. Jacobson, I., Christerson, M., Jonsson, P., & Övergaard, G. (1992). Objectoriented 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). Técnicas para Projeto e Implementaçao de Agentes de Software, Master Thesis, Universidade Estadual de Maringá, Brasil. Rumbaugh, J., Blaha, M., Premerlani, W., & Eddy, V. F. (1991). Objectoriented modelling and design. Upper Saddle River, NJ: Prentice-Hall. Salcedo, P. (2003). Inteligencia Artificial Distribuida y Razonamiento basado en casos en la Arquitectura de un Sistema Basado en el Conocimiento para la Educación a Distancia. Revista de Ingeniería Informática, 9. Salic, B. (2004). UML 2.0: Exploiting abstraction and automation. Available online http://www.sdtimes.com/opinions/guestview_098.htm Schreiber, G., Akkermans, H., Anjewierden, A., deHoog, R., Shadbolt, N., VandeVelde, W. & Wielinga, B. (1999). Knowledge engineering and management: The commonKADS methodology. Cambridge, MA: MIT Press. Wirfs-Brock, R., Wilkerson, B. & Wiener, L. (1990). Designing objectoriented 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 problemoriented, 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 involving 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 objectorientation. 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 positions DeLoach, Wood, and Sparkman in the middle. We also reject these two views in their extreme forms. A designer may want to work at different levels of detail when modeling a system. This requires appropriate representations at all levels of detail or fidelity and, crucially, systematic mappings between them. Because such issues are, at present, not addressed by any of the existing MAS analysis and design methodologies, we have decided to create a brand new one. The methodology we are going to illustrate is named a Process for Agent Societies Specification and Implementation (PASSI) or “steps” in the Italian language. It is our attempt at solving the scientific problem arising from the above considerations. In fact, it is a step-by-step requirement-to-code methodology for designing and developing multi-agent societies integrating design models and concepts from both object-oriented (OO) software engineering and MAS, using the Unified Modeling Language (UML) notation. It is closer to the argument made above for high-fidelity representations, but addresses the systematic mapping between levels of detail and fidelity. The target environment we have chosen is the standard, widely implemented Foundation for Intelligent Physical Agents (FIPA) architecture (O’Brien & Nicol, 1998; Poslad, Buckle, & Hadingham, 2000). PASSI is the result of a long period of theoretical studies and experiments in the development of embedded robotics applications (Chella, Cossentino, & LoFaso, 2000; Cossentino, Sabatucci, & Chella, 2003).
Figure 1. The models and phases of the PASSI methodology Initial Requirements
Next Iteration
System Requirements Model Domain Req. Description
Agent Implementation Model Ag. Structure Definition
Agent Identification Role Identification
Ontology Description
Task Specification
Role Description
Agent Society Model
Ag. Behavior Description
Protocol Description
Code Model Code Reuse
Code Production
Agent Test
Society Test
Deployment Configuration
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 methodology’s models and provides a justification for PASSI. The third section presents the application of PASSI to the “Juul Møller Bokhandel A/S” case study (Andersen, 1997), giving a detailed description of the steps and the use of UML notations within each of them. A comparison of PASSI with the Gaia (Zambonelli, Jennings, & Wooldridge, 2003) and MaSE (DeLoach, Wood, & Sparkman, 2001) is then given, and some conclusions are presented in the final section.
A Quick Overview of the PASSI Methodology In conceiving this design methodology, we followed one specific guideline: the use of standards whenever possible. This justifies the use of UML as modeling language, the use of the FIPA architecture for the implementation of our agents, and the use of XML in order to represent the knowledge exchanged by the agents in their messages. PASSI (Process for Agent Societies Specification and Implementation) is a step-by-step requirement-to-code methodology for developing multi-agent software 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 Implementation, 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 Requirements 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 responsibilities 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 dependencies among the agents involved in the solution. Developing this model involves three steps: (a) Ontology Description (O.D.): use of class diagrams and OCL constraints 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 architecture 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 statecharts 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 method’s implementation based on a library of reused patterns and associated design descriptions; and (b) manual completion of the source code. 5.
Deployment Model: a model of the distribution of the parts of the system across hardware processing units and their migration between processing units. It involves one step: Deployment Configuration (D.C.): deployment diagrams describe the allocation of agents to the available processing units and any constraints on migration and mobility. Testing: the testing activity has been divided into two different steps: the single-agent test is devoted to verifying the behavior of each agent regarding the original requirements for the system solved by the specific agent (Caire, Cossentino, Negri, Poggi, & Turci, 2004). During the Society Test, integration verification is carried out together with the validation of the overall results of this iteration. The Agent Test is performed on the single agent before the deployment phase, while the society test is carried out on the complete system after its deployment.
In the following, each of the above cited models will be discussed in details in a specific subsection.
The Agent in PASSI The concept of agent will be central to our discussion and therefore a definition of what we mean by an agent will be helpful before proceedings. In PASSI, we consider two different aspects of the agent: during the initial steps of the design, it is seen as an autonomous entity capable of pursuing an objective through its autonomous decisions, actions, and social relationships. This helps in preparing a solution that is later implemented, referring to the agent as a significant software unit. An agent may undertake several functional roles during interactions with other agents to achieve its goals. A role is a collection of tasks performed by the agent in pursuing a sub-goal or offering some service to the other members of the society. A task, in turn, is defined as a purposeful unit of individual or interactive behavior. Each agent has a representation of the world in terms of an ontology that is also referred to in all the messages that the agents exchange.
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 Definition
Agent Structure Definition
Agent Behavior Description
Agent Behavior 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 Implementation 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 (multiagent) view relates to the agents’ structure (in terms of cooperation and tasks involved) and behaviors (flows of events depicting cooperation). The second one instead relates to the single-agent structure (attributes, methods, inner classes) and behavior (specified in an appropriate way). The inner level of iteration (Agent Structure Definition – Agent Behavior Description) takes place in both the multi-agent and single-agent views and concerns the dependencies between structural and behavioral matters. As a consequence of this double level of iteration, the Agent Implementation Model is composed of two steps (A.S.D. and A.B.D.) but yields four kinds of diagrams, taking into account the multi- and the single-agent views.
A More Detailed Description of PASSI Throughout the following subsections, we refer to the “Juul Møller Bokhandel A/ S” Case Study (Andersen, 1997) that describes the problems of a small bookstore coping with rapidly expanding Internet-based book retailers. The bookstore has a strong business relationship with the Norwegian School of 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 (Antón & Potts, 1998, Potts, 1999), we prefer the approach coming from Jacobson, Christerson, Jonsson, and Overgaard (1992), and we describe requirements in terms of use case diagrams. The Domain Requirements Description Phase, as a result, is a functional description of the system composed of a hierarchical series of use case diagrams. Scenarios of the detailed use case diagrams are then explained using sequence diagrams. Figure 3 shows part of the Domain Requirements Description diagram depicting our analysis for the bookstore case study. Stereotypes used here come from the UML standard. Throughout this chapter, we will only examine one scenario—the one that takes place every time that the bookstore needs to purchase some books (Provide Books use case in Figure 3). This may happen, for example, before the beginning of every semester, so as to provide the store with the requested books and therefore anticipate the students’ needs; or when some faculty has changed the required literature or switched a book from “recommended” to “required.” The scenario begins with the prediction of the students’ needs in order to establish whether there is a sufficient number of copies of that book in the store or not. If not, and if the book is needed, a new purchase must be made; this in turn includes (see Figure 3): •
Definition of the desired quotation (Define Purchase-Money use case) by the use of an expert system that holds the history of previous purchases, especially with regard to courses, teachers, number of attendees, books purchased and books sold, suppliers, time elapsed for negotiation and delivery, and so forth.
•
Negotiation of the price (Negotiate Purchase-Money use case).
•
Execution of the order (Carry Out Order).
•
Updating of the purchase history archive (Update Purchase History) in order to increase the knowledge of the purchase expert system.
•
Receiving delivery information about the purchase (Receive Delivery) in order to close the case related to it.
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
<>
Keep NSM Needs Updated
NSM Courses Web Server
<<extend>> <>
Carry Out Order
<>
Carry Out Order By Phone <<extend>>
<>
Predict Students Needs
Clerk
<>
Provide Books
Negotiate Purchase-Money Negotiate Purchase-Money By Telephone
<>
Define Purchase-Money
<>
Supplier <>
Update Purchase History <>
Receive Delivery
Storekeeper
Record Sale
Agent Identification Phase If we look at a MAS as a heterogeneous society of intended and existent agents that in Jackson’s terminology can be “bidden” or influenced but not deterministically 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
<>
PurchaseM onitor
NSM Courses Web Server
<>
<>
ClerkUI
Purchaser
<>
<>
Keep NSM Needs Updated
PurchaseM anager
<>
<> Carry Out Order
<>
<> Provide Books
Carry Out Order By Telephone
<>
Clerk
Negotiate Purchase-M oney Negotiate Purchase-M oney By Telep hone
Predict Students Needs
<> <> <>
PurchaseAdvisor Supplier Define Purchase-M oney
Update Purchase History
<>
<>
StoreUI
<> Receive Delivery
Storekeeper
Record Sale
Note, for example, how the “include” relationship between the use cases Provide Books and Receive Delivery (Figure 3) turned from “include” into “communication” and also changed the navigability direction. This reflects the fact that in an autonomous organization of agents in a distributed system, we can organize things in a departmental manner, so as to have a StoreKeeper actor that records any stock’s delivery that occurs. The StoreUI agent may then notify the Purchase Manager agent of that delivery. In so doing, the Purchase Manager does not need to keep bothering about the delivery of a stock, but rather it continues to work while another agent is taking care of this task. The selection of the use cases that will be part of each agent should be done pursuing the criteria of functionality coherence and cohesion. These are important 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 agent’s externally visible behavior than its structure – only approximate at this step. Roles identification (R. Id.) is based on exploring all the possible paths of the Agents Identification diagram involving inter-agent communication. A path describes a scenario of interacting agents working to achieve a required behavior of the system. It is composed of several communication paths. A communication path is simply a “communicate” relationship between two agents in the above diagram. Each of them may belong to several scenarios, which are drawn by means of sequence diagrams in which objects are used to symbolize roles. Figure 5 shows the already presented scenario, arising when a new purchase is required from the role Informer of the PurchaseMonitor agent to the role BooksProvider of the Purchase Manager agent. Although the diagram resembles an UML sequence diagram, the syntax is a bit different. Each object in the diagram represents an agent’s role, and we name it with the following syntax: : An agent may participate in different scenarios playing distinct roles in each. It may also play distinct roles in the same scenario (as happens to the Purchaser and the Purchase Advisor agents in Figure 5). Usually, UML sequence diagrams begin because of some actor’s action; in PASSI, being agents autonomous and active, they can trigger a new scenario and actors can appear later (or not). For this reason, the PurchaseMonitor agent (while playing its Informer role) can be the first element of this diagram and can fire it. The messages in the sequence diagram may either signify events generated by the external environment or communication between the roles of one or more agents. A message specifies what the role is to do and possibly the data to be provided or received.
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 : PurchaseMonitor
BooksProv ider : PurchaseManager
Consultant : PurchaseAdv isor
Negotiator : Purchaser
: Supplier
OrderPlacer : Purchaser
Deliv ery Notif ier : StoreUI
: Storekeeper
Recorder : PurchaseAdv isor
Prov ideTheseBooks SuggestPurchaseConditions
Try TheseConditions
NegotiateTheseConditionsWithThisSupplier Y ourBestOf f er? HereIsMy Best
*[Of f erNotGoodEnough] WhatAboutThis?
That'sTheBestOf f er
Carry OutOrder WantToBuy
BooksDeliv ered
NewDeliv ery
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 agent’s behavior in order to conceive of a plan that could fulfil the agent’s requirements by delegating its functionalities to a set of tasks. Tasks generally encapsulate some functionality that forms a logical unit of work. For every agent in the model, we draw an activity diagram that is made up of two swimlanes. The one from the right-hand side contains a collection of activities symbolizing the agent’s tasks, whereas the one from the left-hand side contains some activities representing the other interacting agents. A Task Specification diagram (T.Sp.) (see Figure 6) summarizes what the agent is capable of doing, ignoring information about roles that an agent plays when carrying out particular tasks. Relationships between activities signify either messages between tasks and other interacting agents or communication between tasks of the same agent. The latter are not speech acts, but rather signals addressing the necessity of beginning an elaboration, that is, triggering a task execution or delegating another task to do something. In order to yield an agent’s T.Sp. diagram, we need to look at all of the agent’s R.Id. diagrams (i.e., all of the scenarios in which it participates). We then explore all of the interactions and internal actions that the agent performs to accomplish a scenario’s purpose. From each R.Id. diagram, we obtain a collection of related tasks. Grouping them all together appropriately then results in the T.Sp. diagram. Because drawing a Task Specification diagram for each agent would require too much space in this chapter, we proceed from now on by focusing on a single agent: the Purchase Manager. In Figure 6, we can see its T.Sp. diagram. In this
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
PurchaseAdvisor.Listener
ReceivePurchase Request
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, respectively, 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 properties 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 relationship between two entities and allows the specification of the role of the involved entities in order to clarify the structure; and
•
Aggregation, which can be used to construct sets where value restrictions can be explicitly specified; this originates from the W3C RDF specification where three types of container objects are enumerated, namely the bag (an unordered list of resources), the sequence (an ordered list of resources), and the alternative (a list of alternative values of a property), and is therefore not UML-compliant.
The example in Figure 7 shows that each Purchase is related to a SuccessfulNegotiation, a predicate that reports if an order has been issued (attribute orderIssued is true in this case) as a consequence of a negotiation. It includes a request from the library (ourRequest) for a specific Stock and an offer from the supplier (theirBestOffer) for that Stock. Delivery is an example of action—it describes the activity done by the Supplier of delivering to the Storekeeper some books listed in an ordered stock. The Communication Ontology Description (C.O.D.) diagram (Figure 8) is a representation of the agents’ (social) interactions; this is a class diagram that shows all agents and all their interactions (lines connecting agents). In designing this diagram, we start from the results of the A.Id. (Agent Identification) phase. A class is introduced for each identified agent, and an association is then
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 communication 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 <> GoingOnPurchases
+AnOpenPurchase <> Purchase +CourseInfo date : Date <> Course courseTitle : String teacherName : String numberOfAttendees : Integer
+textBook
+PurchaseInfo
1 1..*
+ANegotiation
+StocksToNegotiate
<<predicate>> SuccessfulNegotiation orderIssued : Boolean
<> Stocks
1
<> Book authors : String title : String edition : String publisher : String +textBook
0..*
<> OpenPurchase remainingStocksToNegotiate : Stocks
1..*
<> Delivery Actor = Supplier Receiver = StoreKeeper <> delivery()
<> SuppliersArchive
+theirBestOffer
+ourRequest
1..* +ASupplier
+AStock
<> Stock 1 numberOfItems : Integer unitPrice : Integer +OrderedStock purchaseTime : Date deliveryTime : Date
+Stock Supplier 1
1..*
<> Supplier name : String email : String fax : String phone : String
+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
CourseData Ontology : Course Language : RDF
QueryForAdvise Protocol : Query
PurchaseAdvisor _past_purchases : History +Consultant +BooksProvider
PurchaseAnnouncement Protocol : Request
PurchaseMonitor _course_info : Course
+BooksProvider PurchaseManager _open_purchases : GoingOnPurchases _suppliers_list : Suppliers
+BooksProvider +Informer +Books Provider
OurRequest Protocol : Query
+Recorder
PurchaseDetails Ontology : Purchase Language : RDF Protocol : Propose
+Negotiator
+BooksProvider
DeliveryNotification Ontology : Delivery Language : RDF Protocol : Propose
+BooksProvider +DeliveryNotifier StoreUI _delivery_details : Delivery
+OrderPlacer
Purchaser _our_request : Stock _their_best_offer : Stock
StockToPurchase Protocol : Propose
StockInfo Ontology : Stock Language : RDF
with different ontology, language, or protocol is certainly different from this one) and its knowledge is used to uniquely refer this communication (which can have, obviously, several instances at runtime, since it may arise more than once). Roles played by agents in the interaction (as derived from the R.Id. diagrams) are reported at the beginning and the end of the association line. In Figure 8, the PurchaseManager agent starts a conversation (see QueryForAdvice association class) with the PurchaseAdvisor agent. The conversation contains the Course ontology, the Query protocol, and the RDF language. This means that the PurchaseManager wants to perform a speech act based on the FIPA’s query protocol in order to ask the PurchaseAdvisor for advice on how to purchase (supplier, number of stocks, number of items per each, purchase-money) provided the Course information.
Roles Description Phase This phase models the lifecycle of an agent taking into account its roles, the collaborations it needs, and the conversations in which it is involved. In this phase, we can also introduce the social rules of the society of agents (organizational rules) (Zambonelli, Jennings, & Wooldridge, 2001) and the behavioral laws as 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 role’s class. Each task is related to an action or a set of actions, and therefore the list of tasks describes what a role is able to do; it can also be helpful in the identification of reusable patterns. An R.D. diagram can also show connections between roles of the same agent, representing 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 <> Purchase Monitor Informer : PurchaseMonitor <> Purchase Advisor
<> Purchaser
RequestBooks() LookForChanges()
Consultant : PurchaseAdvisor IdleTask() ReceiveAdviceRequest() QueryOnHistory()
PurchaseAnnouncement OurRequest
(service)
<> Purchase Manager QueryForAdvice
BooksProvider : PurchaseManager
(resource) [ROLE CHANGE]
Recorder : PurchaseAdvisor IdleTask() ReceiveRecordingRequest() UpdateHistory()
IdleTask() ReceivePurchaseRequest() StartPurchase() AskForAdvise() PurchaseDetails StartNegotiation() StartOrdering() ReceiveDeliveryNotification() NotifyEndOfPurchase() UpdatePurchaseHistory()
Negotiator : Purchaser IdleTask() ReceiveNegotiationRequest() Negotiate()
(resource) [ROLE CHANGE] StockToPurchase (service)
OrderPlacer : Purchaser
IdleTask() ReceiveOrderingRequest() Order()
DeliveryNotification <> 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 relationships 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 communication. 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 singleagent views. In the former, we call attention to the general architecture of the system and so we can find agents and their tasks. In the latter, we focus on each agent’s internal structure, revealing all the attributes and methods of the agent class together with its inner tasks’ classes (the FIPA-platform classes that will be coded).
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 <> ChiefUI NSM Courses W eb Server
<> PurchaseMonitor RequestBooks() LookForChanges()
<> Archive
<> PurchaseManager
Chief <> Purchaser
IdleTask() ReceivePurchaseRequest() StartPurchase() AskForAdvise() StartNegotiation() StartOrdering() ReceiveDeliveryNotification() NotifyEndOfPurchase() UpdatePurchaseHistory()
<> ShopUI <> W ebUI
<> ClerkUI
IdleTask() ReceiveNegotiationRequest() Negotiate() ReceiveOrderingRequest() Order()
Clerk
<> PurchaseAdvisor IdleTask() ReceiveAdviceRequest() QueryOnHistory() ReceiveRecordingRequest() UpdateHistory()
Supplier
<> StoreUI NSM Student
Book Store Employee
NotifyDelivery()
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 operations compartments are used to signify the agent’s tasks.
Single-Agent Structure Definition (SASD) Here one class diagram (Figure 11) is used for each agent to illustrate the agent’s internal structure through all of the classes making up the agent, which are the 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
PurchaseManager - purchaseInf ormation - time - negotiatingConditions - negotiatedConditions - deliv ery Data + AGENT_TYPE : String = "Purchase Manager" + PurchasesManager() + registrationFailed() + registrationRef used() + registrationSucceded() + shutdown()
FIPA_Agent
AskForAdv ice
Receiv ePurchaseRequest - _course_inf o : Course + Receiv ePurchaseRequest() + startTask() + doneAskForPurchaseAdv ()
- _course_inf o : Course - _receiv ed_adv ice : Stocks
StartPurchase + StartPurchase() + startTask() + AskForPurchaseAdv () + handleAdv ice() + doneAskNegotiation()
IdleTask + IdleTask() + startTask() + handleRequest()
UpdatePurchaseHistory - _purchase_to_record : Purchase + UpdatePuchaseHistory () + startTask()
StartNegotiation - _our_request : Stock - _their_best_of f er : Stock
+ AskForAdv ice() + startTask()
+ StartNegotiation() + startTask() + handleTheirBestOf f er()
StartOrdering - _stock_to_purchase : Stock
Task
+ StartOrdering() + startTask()
Receiv eDeliv ery Notif ication Notif y EndOf Purchase + Notif y EndOf Purchase() + startTask()
- _deliv ery _details : Deliv ery + Receiv eDeliv ery Notif ication() + startTask()
agent’s main class together with the inner classes identifying its tasks. At this point, we set up attributes and methods of both the agent class (e.g., the constructor and the shutdown method when required by the implementation platform) and the tasks’ classes. The result of this stage is to obtain a detailed structure of the software, ready to be implemented almost automatically.
Agents Behavior Description Phase As was seen in the previous phase, this phase influences and is influenced by the Agent Structure Definition phase in a double level of iterations. The Agent Behavior Description phase produces several diagrams that are subdivided into the multi-agent and the single-agent views. In the former, we draw the flow of events (internal to agents) and communications (among agents) by representing method invocations and the message exchanges. In the latter, we detail the above methods.
Multi-Agent Behaviour Description (MABD) At this stage, one or more activity diagrams are drawn to show the flow of events between and within both the main agent classes and their inner classes (representing their tasks). We depict one swimlane for each agent and for each task. The activities inside the swimlanes indicate the methods of the related class. Unlike DeLoach, Wood, and Sparkman (2001), we need not introduce a specific diagram for concurrency and synchronization since UML activity diagrams’ syntax already supports it. 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 message’s performative as it is specified in the Communication Ontology Description diagram and the message’s content as described in the Domain Ontology Description diagram. This results in having a comprehensive description of the communication including the exact methods involved. Figure 12 shows an example of a multi-agent behavior description. The StartPurchase task of the PurchaseManager agent instantiates the StartNegotiation task by invoking the newTask super-class method. This has to be done in order to ask the Purchaser agent to perform a negotiation with a supplier. The invocation of the StartNegotiation task implies its startTask method to be invoked (according to the FIPA-OS implementation platform we have used). What the startTask method does is send a message to the Purchaser agent. This contains the Request performative (as required by the FIPA Request protocol) and the content OurRequest (coming from the D.O.D. diagram, Figure 7). The handleRequest method of the Purchaser’s IdleTask task receives the incoming communication and sends it to the ReceiveNegotiationRequest task after this one has been instantiated as above. When a task completes its job, the done method is invoked. This kind of diagram often becomes very huge and difficult to draw/read. In order to deal with this problem, an extended version of it has been presented in Caire et al. (2004) where the revised syntax supports different levels of detail.
Figure 12. An example of multi-agent behaviour description diagram PurchaseManager.StartPurchase
StartPurchase. StartPurchase
Purch aseManag er.StartN eg otiation
Purchaser.Id leTask
Pu rchaser.R eceiveNegotiation Request
Purchaser:N egotiate
newT ask( Neg oti ate )
StartNegotiation. StartNegotiation
StartNegotiation. startTask
m essage( OurRe quest; q uery-i f )
IdleTask. handleRequest
newT ask( Recei veNego ti atio nReque st )
ReceiveNegotiationRequest. ReceiveNegotiationRequest ReceiveNegotiationRequest. startTask
newT ask( Neg oti ate )
Negotiate. Negotiate
StartP urchase.done AskNegotiation
StartNegotiation .handleInform d one()
Negotiate. startTask
message( Ou rReque st; i nform )
ReceiveNegotiationRequest. doneNegotiate
do ne()
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 pattern’s libraries than rough code. So we prefer to look at patterns as pieces of design and code to be reused in the process of implementing new systems. We have extended the Rational Rose UML CASE tool by developing an add-in supporting PASSI (PTK) and a specific pattern reuse application (AgentFactory). PTK and AgentFactory are complementary and responsible for two different stages of the design-implementation activities: initially, PTK helps in compiling the PASSI diagrams, then AgentFactory is used to generate the agents’ code when patterns have been used in the design. PTK initial releases were able to generate agents’ code, but this duty has been, more recently, assigned to the AgentFactory application. It works in this way: the PTK (PASSI ToolKit) addin 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 Webbased 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 delegate 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 agent’s code is properly functional. The repository also includes a list of behaviors that can be applied to existing agents. For example, we have behaviors dedicated to deal with the initiator/ participant roles in the most common communications. When a pattern is introduced in the design, not only are some diagrams (like the structural and behavioral one of the implementation level) updated. but the resulting code also contains large portions of inner parts of methods; the result is a highly affordable and quick development production process.
Code Completion Phase This phase is the classical work of the programmer, who just needs to complete the body of the methods yielded to this point, by taking into account the design diagrams.
Deployment Configuration Phase The Deployment Configuration (D.C.) phase has been thought to comply with the requirements of detailing the agents’ positions in distributed systems or more generally in mobile-agents’ contexts. The Deployment Configuration diagram is a UML deployment diagram and illustrates the location of the agents (the implementation platforms and processing units where they live), their movements, and their communication support. The standard UML notation is useful for representing processing units (by boxes), agents (by components), and the like. What is not supported by UML is the representation of the agent’s mobility, which we have done by means of a 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 connecting 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 communication. 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 environments that we have used were based on the FIPA architecture in accordance with the aim of adopting standards whenever possible. We are now working on the enhancement of the CASE tool supporting PASSI and on the enlargement of the pattern repository in order to further increase the productivity of the PASSI developer.
References Andersen, E. (1997). Juul Møller Bokhandel A/S. Norwegian School of Management. Available online http://www.espen.com/papers/jme.pdf Antón, A.I. & Potts, C. (1998). The use of goals to surface requirements for evolving systems. In Proceedings of International Conference on Software Engineering (ICSE ’98) (pp. 157-166). Aridor, Y. & Lange, D.B. (1998). Agent design patterns: Elements of agent application design. In Proceedings of the Second International Conference 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 selforganizing applications engineering. In Proceedings of the First International 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. Journal 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 Technology 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 IAT’03 Conference. Cossentino, M., Sabatucci, L., Sorace, S., & Chella, A. (2003). Patterns reuse in the PASSI methodology. Fourth International Workshop Engineering 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 (IJCAI99). 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 Knowledge Engineering, 11(3), 231-258. DiLeo, J., Jacobs, T. & DeLoach, S. (2002). Integrating ontologies into multiagent 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). Objectoriented software engineering: A use case driven approach. Reading, MA: Addison-Wesley. Jennings, N.R. (2000). On agent-based software engineering. Artificial Intelligence, 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. O’Brien, P. & Nicol, R. (1998). FIPA - Towards a standard for software agents. BT Technology Journal, 16(3), 51-59. Odell, J., Van Dyke Parunak, H., & Bauer, B. (2001). Representing agent interaction protocols in UML. In Agent-Oriented Software Engineering (pp. 121-140). Berlin: Springer-Verlag. OMG. (2003a). Software Process Engineering Metamodel Specification. Version 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 determination. In Proceedings of IEEE Fourth International Symposium on Requirements Engineering (RE’99) (pp. 58-65). Robbins, J., Medvidovic, N., Redmiles, D., & Rosenblum, D. (1998). Integrating architecture description languages with a standard design method. In Proceedings of the Twentieth International Conference on Software Engineering (ICSE ’98) (pp. 209-218). Searle, J.R. (1969). Speech acts. Cambridge, UK: Cambridge University Press. SPEM (2002). Software Process Engineering Metamodel Specification. Version 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.), Agentoriented 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 Engineering 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 multiagent 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 methodologies 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 improvement 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 methodologies can be found in Dam (2003); Dam and Winikoff (2003); and Sudeikat, Braubach, Pokahr, and Lamersdorf (2004). Other comparisons of agentoriented 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 everything 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 programming are not, and so we feel that it is useful and important to discuss them. In considering what concepts are appropriate for designing agent systems, we take as a starting point the definition of an intelligent agent. We take the standard definition of an agent as being software that is situated in an environment, autonomous, reactive to changes in its environment, proactive in its pursuit of goals and social (Wooldridge, 2002). We extend this definition by adding to the list of desired properties of agents being flexible (having multiple ways of achieving goals) and robust (being able to deal with various forms of failure) (Padgham & Winikoff, 2004). Based on these properties, we identify a number of concepts that are used to design and implement agents. An agent’s interface with its environment is expressed in terms of percepts and actions. Proactive agents pursue goals, and reactive agents respond to events (“significant occurrences”). Agents have beliefs and plans. Finally, social agents use messages to communicate, and these messages are collected in interaction protocols. Our experience with teaching agent concepts has been that the concept set discussed is sufficient to design BDI style agent systems and also easier to understand than, for example, the standard BDI concepts (particularly intentions). 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 system’s interface to its environment is described in terms of actions, percepts, and external data; and functionalities are defined.
•
Architectural design: where agent types are identified; the system’s overall structure is captured in a system overview diagram; and use case scenarios are developed into interaction protocols.
•
Detailed design: where the details of each agent’s internals are developed and defined in terms of capabilities, data, events, and plans; process diagrams are used as a stepping stone between interaction protocols and plans.
Detailed Design
Architectural Specification Design
Figure 1. The phases of the Prometheus methodology
Scenarios
Goals
Functionalities
Actions & Percepts
Data Coupling & Agent Acquaintance
Interaction Diagrams Interaction Protocols
Agent Descriptors
System Overview
Processes
Capability Descriptors
Agent Overview
Plan Descriptors
Data Descriptors
Event Descriptors
Capability 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 associated 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 example, 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 Programming 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 requested 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 changing 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 John’s design.
System Specification System specification begins with a rough idea of the system, which may be simply a few paragraphs of description, and proceeds to define the requirements of the system in terms of: •
The goals of the system;
•
Use case scenarios;
•
Functionalities; and
•
The interface of the system to its environment, defined in terms of actions and percepts.
We would like to stress that these are not considered in sequence. Rather, work on one of these will lead to further ideas on another. For example, the goals of the system are a natural starting point for developing use case scenarios. Conversely, developing the details of the scenarios often suggests additional
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 scheduling 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 Sietsma’s design): •
Meeting Manager: Manages meeting information. Encompasses all goals associated with the top-level goal of manage meetings except for propose time meeting user preferences and negotiate with other users.
•
Meeting Scheduler: Schedules meetings subject to provided constraints and user habits/preferences. Encompasses the goal propose time meeting user preferences.
•
Negotiator: Negotiates with other users to determine meeting times. This differs from Meeting Scheduler in that Negotiator is about inter-user constraints, whereas Meeting Scheduler is concerned only with the constraints of a single user. Encompasses the goal negotiate with other users.
•
Contact Manager: In charge of managing contact information for other users. Encompasses the goal track contacts and its subgoals.
•
Contact Notify: Provides a means of communicating with other users. Encompasses the goal communicate with other users and its subgoals.
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 description, 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 1 PERCEPT Request meeting 2 GOAL Propose time meeting preferences 3 GOAL negotiate with other users 4 5 6 7
GOAL GOAL OTHER GOAL
8 GOAL
Functionality User Interaction user Meeting Scheduler Negotiator
update user's diary inform others of meeting wait for day of meeting remind user of meeting
Meeting Manager Contact Notify
remind others of meeting
Contact Notify
User Notify
Data MeetDB(R), Prefs(R) MeetDB(R), Prefs(R) MeetDB(W) MeetDB(R), Prefs(R) ContactInfo(R)
Variations: • Steps 2-3 may be repeated in order to obtain agreement. • If agreement on a meeting time is not reached then steps 4-8 are replaced with notifying the user that the meeting could not be scheduled. • The meeting can be rescheduled or cancelled during step 6 (waiting). Key: • MeetDB(R) = Meetings Database read • Prefs(R) = User Preferences read • MeetDB(W) = Meetings Database written • ContactInfo(R) = Contact Information read
In developing this use case scenario the additional goals get user preferences, update user’s diary, inform others of meeting and remind others of meeting were identified.
System Interface: Actions and Percepts Finally, the environment within which the agent system will be situated is defined. This is done by describing the percepts available to the system, the actions that it will be able to perform, as well as any external data that are available and any external bodies of code. When specifying percepts, we also consider percept processing. Often percepts 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 including 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 Preferences 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 between the agent types—the higher the link density, the higher the coupling. For example, the agent acquaintance diagram in Figure 4 shows the agent types and the communication pathways between them. This is believed to be a reasonable degree of coupling; the UserInterface agent needs to communicate with all of the other agent types, but most of the other agent types don’t communicate. Once agent types have been decided upon, they are documented using an agent descriptor. In addition to capturing the interface of the agent, what goals it achieves, what functionalities were combined to form it, and with what protocols the agent is involved, the descriptor prompts the designer to think about lifecycle issues: When are instances of this agent type created? When are they destroyed? What needs to be done when agents are created/destroyed? Figure 4. Agent acquaintance diagram
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 protocols. 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 mechanical process (although not completely mechanical). In essence, if step N is performed by an agent A, and this is followed by step N+1 performed by a different agent B, then a message needs to be sent from A to B. For example, in the use case scenario given earlier, step 1 is a percept that is received by the User Interaction functionality that has been grouped into the UserInterface agent type, and step 2 is a goal of the Meeting Scheduler functionality that has been grouped into the Meetings agent type. Therefore, assuming a single agent of each of the two types, in between step 1 and step 2, there is a message from the UserInterface agent to the Meetings agent. Like use case scenarios, interaction diagrams show example interactions rather than all possible interactions. In order to define plans that will handle all necessary interactions, we use interaction protocols to capture all possible sequences of messages. Often an interaction protocol will combine a number of interaction diagrams. For example, if there are three interaction diagrams corresponding to different cases of scheduling a meeting, then there will be an interaction protocol that covers all cases and that subsumes the interaction diagrams. When looking at the use case scenarios, we also consider the documented variations of these scenarios. Another useful technique for developing interaction protocols is to consider each point in the interaction sequence and ask “What else could happen here?” If the interaction diagram shows an example sequence where a request for possible meeting times is replied to with a number of possible times, then an alternative possibility is that there won’t be any meeting times available. The interaction protocols are accompanied with descriptors for both the protocols 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, Rönnquist, Hodgson, & Lucas, 2000; Padgham & Lambrix, 2005) are a structuring mechanism akin to modules. A capability can contain plans, data, and events. It can also contain other capabilities allowing for a hierarchical structure. In identifying the capabilities that each agent type contains, one usually starts by considering a capability for each functionality that was grouped in the agent type. This initial detailed design is then refined by merging capabilities that are similar and small, splitting capabilities that are too large, and adding capabilities that correspond to common “library” code. The structure of each agent is depicted by an agent overview diagram. This is similar to the system overview diagram except that it does not contain agent nodes and does not (usually8) contain protocol nodes. However, the agent overview diagram does (usually) contain capability nodes and (sometimes) plan nodes.
Figure 6. Example of an agent overview diagram: Meeting agent
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 agent’s interface, we consider to what capability or plan it connects. In addition to connecting the interface of the agent to internal plans and/or capabilities, additional internal messages and data are introduced as needed. For example, in developing the internals of the Meeting agent (see Figure 6) we begin by considering its interface: the messages that it sends and receives, and the data that it reads and writes. Some of the messages are concerned with adding, deleting, or searching for meetings. Based on the original functionalities, we introduce the capability ManageMeetings that receives these messages and that reads and writes the MeetingsDB. Other messages concern proposing a meeting time based on the user preferences. These are handled by the CreateMeetingSchedule capability. The two capabilities communicate using internal messages (RequestScheduleMeeting and MeetingSchedule), which are now introduced. During the architectural design phase, the system’s dynamics were described using interaction protocols. These are global in that they depict the interaction between the agents from a “bird’s-eye view.” In the detailed design phase, we develop process diagrams based on the interaction protocols. The process diagrams depict local views for each agent. Typically, each interaction protocol will have multiple process diagrams corresponding to the viewpoints of different agents. The notation that we use for process diagrams is an extension of UML activity diagrams (OMG, 2001); for more details see Padgham and Winikoff (2004, Chapter 8). The design of each agent is, usually, in terms of capabilities. These capabilities are then refined in turn. Eventually the design of how each agent achieves its goals is expressed in terms of plans, events, and data. At this point, the design process needs to make certain assumptions about the implementation platform. Specifically, we assume that the agents are implemented using a platform that supports plans that are triggered by goals. Such platforms include PRS (Georgeff & Lansky, 1986), JAM (Huber, 1999), JACK (Busetta et al., 1998), Jadex9, and Jason 10. The final part of detailed design develops data, events, and plans. This is similar to developing the internals of agents in terms of capabilities but with a few additional considerations. For events, we identify the information that is carried by the event. For example, a request to schedule a meeting would include information on who should attend the meeting, the priority of the meeting and perhaps what date is desired. For each plan we identify its trigger (what event causes the plan to run) and the plan’s
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 plan’s body. The plan’s context condition specifies the situations in which it is appropriate to use the plan. The plan’s body describes how the plan operates and is often a sequence of steps which include subgoals. A given event can trigger multiple plans, and an important consideration relates to this: for a given event, will there always be at least one plan that handles it and that will be applicable? If so, then we say that the event is covered. This is important because an uncovered event will fail to be handled. Where there is a (typically single) plan with a context condition that is always true, then the event is trivially covered. In other situations, coverage can be checked by considering the context conditions of the set of plans that handles the event type in question. A related notion is that of overlap: if a given event might have more than one applicable plan, then there is overlap. Plans are described using a descriptor, which also prompts the designer to consider whether the plan can fail and, if so, whether the failure will be detected, as well as what should be done to clean up upon failure.
Tool Support We have attempted to stress the iterative nature of design, both across the phases of Prometheus and within phases. One consequence of the iterative nature is that the design is often modified. As the design becomes larger, it becomes more difficult to ensure that the consequences of each change are propagated and that the design remains consistent11. Perhaps the simplest example of introduced inconsistency is renaming an entity and failing to rename it everywhere it is mentioned. Other forms of inconsistency that can be easily introduced when making changes to a design include adding a message to an agent in the system overview diagram but failing to ensure that the message appears in the agent overview diagram of that agent type, or adding an incoming message to an agent but forgetting to add a plan to handle the message. Our experience, and the experience of students who used the Prometheus methodology in its earlier days, was that developing designs by hand (using only standard tools such as word processors and generic diagram editors) is quite error prone and that tool support is invaluable. As a result, the Prometheus Design Tool (PDT) was developed. The Prometheus Design Tool (see Figure 7) allows users to create and modify Prometheus designs. It ensures that certain inconsistencies cannot be introduced and provides cross checking that detects other forms of inconsistency. The tool
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 Development 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 methodology 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 guidance in terms of processes as well as notations. It is not intended to be prescriptive, but is rather an approach that has evolved out of experience and that the authors expect to be further adapted, refined, and developed to suit the needs of agent software developers. Recent years have seen a substantial growth of activity in the area of software engineering methodologies suited to an agent programming paradigm. As these mature and develop and are increasingly used beyond the immediate sphere of the developers, we expect them to bear fruit in terms of increased use of agent technology and more widespread familiarity with building of agent systems.
Acknowledgments We would like to acknowledge the support of the Australian Research Council (ARC) under Grant CO010693415 and its continuation, Grant LP045348616. We would also like to thank John Sietsma, James Harland, John Thangarajah, and David Poutakidis of RMIT University; Ralph Rönnquist, Andrew Lucas, Andrew 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 framework. 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 KI’96 Workshop on Agent Oriented Programming and Distributed Systems, September 17-19, Dresden. Retrieved March 22, 2005, from http://www.dfki.uni-kl.dr/dfkidok/publications/D/96/06/abstract.html Busetta, P., Howden, N., Rönnquist, R., & Hodgson, A. (2000). Structuring BDI agents in functional clusters. In Agent theories, architectures, and languages (ATAL-99) (pp. 277-289). LNCS 1757. Berlin: SpringerVerlag. Busetta, P., Rönnquist, R., Hodgson, A., & Lucas, A. (1998). JACK intelligent agents - Components for intelligent agents in Java. Technical report, Agent Oriented Software Pty. Ltd, Melbourne, Australia. Retrieved March 22, 2005, from http://www.agent-software.com Bush, G., Cranefield, S., & Purvis, M. (2001). The Styx agent methodology. The Information Science Discussion Paper Series 2001/02, Department of Information Science, University of Otago, New Zealand. Retrieved March 25, 2005, from http://www.business.otago.ac.nz/infosci/pubs/papers/ dps2001.htm Cernuzzi, L. & Rossi, G. (2002). On the evaluation of agent oriented modeling methods. In J. Debenham, B. Henderson-Sellers, N. Jennings, & J. Odell (Eds.), Proceedings of the OOPSLA 2002 Workshop on Agent-Oriented 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 Conference on Multiagent Systems (ICMAS’96) (pp. 41-57). AAAI Press. Dam, K. H. (2003). Evaluating agent-oriented software engineering methodologies. Master’s Thesis, School of Computer Science and Information Technology, RMIT University, Melbourne, Australia (Supervisors: Michael Winikoff and Lin Padgham). Dam, K. H. & Winikoff, M. (2003). Comparing agent-oriented methodologies. In P. Giorgini & M. Winikoff (Eds.), Proceedings of the Fifth International Bi-Conference Workshop on Agent-Oriented Information Systems, Melbourne, Australia, (pp. 52-59). Drogoul, A. & Zucker, J. (1998). Methodological issues for designing multiagent systems with machine learning techniques: Capitalizing experiences from the robocup challenge. Technical Report LIP6 1998/041, Laboratoire d’Informatique de Paris 6. Elammari, M. & Lalonde, W. (1999). An agent-oriented methodology: Highlevel 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. 13831398). Glaser, N. (1996). The CoMoMAS methodology and environment for multiagent system development. In C. Zhang & D. Lukose (Eds.), Multi-agent systems methodologies and applications (pp. 1-16). Second Australian Workshop on Distributed Artificial Intelligence, LNAI 1286. Berlin: Springer-Verlag. Huber, M. J. (1999). JAM: A BDI-theoretic mobile agent architecture. In Proceedings of the Third International Conference on Autonomous Agents, (Agents’99), Seattle, Washington (pp. 236-243). Huget, M.-P. (2002). Nemo: An agent-oriented software engineering methodology. In J. Debenham, B. Henderson-Sellers, N. Jennings, & J. Odell (Eds.), Proceedings of the OOPSLA 2002 Workshop on Agent-Oriented 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 (version 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 MultiAgent 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 (ATAL96). 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 MultiAgent 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 MultiAgent 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. EstivillCastro (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 methodology for open multi-agent systems. In Proceedings of the 14th International 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 BDIagents. 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 Conference (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 Autonomous Agents and Multi Agent Systems (AAMAS’02), Bologna, Italy, July 15-19 (pp. 960-967). ACM Press. Poutakidis, D., Padgham, L., & Winikoff, M. (2003). An exploration of bugs and debugging in multi-agent systems. In Proceedings of the 14th Interna-
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 agentbased 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 Information Systems (pp. 60-67), Melbourne, Australia. Sudeikat, J., Braubach, L., Pokahr, A., & Lamersdorf, W. (2004). Evaluation of agent-oriented software methodologies: Examination of the gap between modeling and platform. In P. Giorgini, J. Müller, & J. Odell (Eds.), Agent Oriented Software Engineering (AOSE). van Lamsweerde, A. (2001). Goal-oriented requirements engineering: A guided tour. In Proceedings of the 5th IEEE International Symposium on Requirements Engineering (RE’01) (pp. 249-263), Toronto, Ontario, Canada. Varga, L. Z., Jennings, N. R., & Cockburn, D. (1994). Integrating intelligent systems into a cooperating community for electricity distribution management. 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 requirements (van Lamsweerde, 2001).
4
The terminology used is not consistent with UML. Since Prometheus uses scenario instances (“scenarios” in UML) and does not have anything corresponding to UML’s Use Case Diagram, there is no need to distinguish between two concepts.
5
The diagram is slightly modified from the one that was prepared by the student.
6
These are renamed in the final version of the design to UserHabitsDB and UserPreferencesDB, respectively.
7
Other notations that could be used for this purpose include the original version of AUML and Petri nets.
8
Although it may make sense to allow protocol nodes in agent overview diagrams, the current version of the Prometheus Design Tool does not support this.
9
http://vsis-www.informatik.uni-hamburg.de/projects/jadex
10
http://jason.sourceforge.net
11
In the general sense, not in the formal sense of a logical theory being consistent.
12
The Prometheus Design Tool is available from http://www.cs.rmit.edu.au/ agents/pdt
13
Summer projects are done by undergraduate students over eight weeks, full time during the summer non-teaching period.
14
It is important to note that UML is only a notation, not a methodology.
15
Simplifying the Development of Agent-Oriented Systems, ARC SPIRT Grant, 2001-2003.
16
Advanced Software Engineering Support for Intelligent Agent Systems, 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 multiagent 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 constituent 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 organizational 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 system’s structure, may have useful applications in pervasive and mobile computing; and societal metaphors have been effectively applied in robotics applications (Collinot, Drogoul, & Benhamou, 1996; Moses & Tennenholtz, 1995) and in the understanding 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 welldefined 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 suborganizations (the dashed ellipses in Figure 1), with a subset of the agents being possibly involved in multiple organizations. In each organization, an agent can play one or more roles, to accomplish which agents typically need to interact with each other to exchange knowledge and coordinate their activities. These interactions occur according to patterns and protocols dictated by the nature of the role itself (i.e., they are institutionalized by the definition of the role). In addition, the MAS is typically immersed in an environment (i.e., an ensemble of resources, represented by the grey ellipse in Figure 1) with which the agents may need to interact in order to accomplish their roles. Interactions with the environment occur via some sorts of sensors and effectors (i.e., mechanisms enabling agents to perceive and act upon some part of the environment). That portion of the environment that agents can sense and effect (represented by the darker ellipses inside the environment in Figure 1) is determined by the agent’s specific role, as well as by its current status. The organizational metaphor—other than being a natural one for human developers 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 Interactions
Agent Agent
Agent
Agent Agent
Agent
Access to the Environment
Environment
marketplaces). Therefore, an organization-based design may reduce the conceptual 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 abstractions that characterize a computational organization and that can be appropriately exploited in the analysis and design phases: the environment in which the MAS is immersed; the roles to be played by the different agents in the organization; and the interactions between these roles. In addition, we have identified two further abstractions that are often implicitly integrated into those above and that, we believe, need to be considered in their own right: organizational 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 determining all the entities and resources that the MAS can exploit, control, or consume when it is working towards the achievement of the organizational goal. In some cases, the environment will be a physical one, including such things as the temperature in a room, the status of a washing machine, or the average speed of cars on a motorway. 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, modeled, 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 preexisting scenarios. In a manufacturing scenario, for example, the choice may depend on whether sensors are passive or active, leading to a characterization of the environment in terms of either a data world or a service world.
•
Evaluating what should actually be considered as part of the environment. The existence of active entities with which the agents in the MAS will have to interact (e.g., computer-based sensors in a manufacturing scenario or active databases in a Web scenario) means a decision has to be made about what should be viewed as an agent and what should be viewed in terms of dynamic environmental resources. In other words, the distinction between the agent and the environment is not always clear cut and may require an analysis in its own right.
Summarizing, the environment of an MAS should not be implicitly assumed—its characteristics must be identified, modeled, and possibly shaped to meet application-specific purposes.
Roles and Interactions In general terms, the role of an agent defines what it is expected to do in the organization, both in concert with other agents and in respect to the organization itself. Often, an agent’s role is simply defined in terms of the specific task that it has to accomplish in the context of the overall organization. However, our notion of a role is much more precise; it gives an agent a well-defined position in the organization, with an associated set of expected behaviors (Demazeau & Rocha Costa, 1996; Ferber and Gutknecht, 1998; Wooldridge et al., 2000). Organizational role models precisely describe all the roles that constitute the computational organization. They do this in terms of their functionalities,
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 interactions between the roles. Moreover, the interaction model describes the characteristics and dynamics of each protocol (e.g., when, how, and by whom a protocol has to be executed). Most approaches to MAS modeling (Lind, 2001; Wood, 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 exploitation 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 constraints: (1) spread horizontally over all the roles and protocols (or, equivalently, over the identified preliminary roles and protocols), or (2) express relations and constraints between roles, between protocols, or between roles and protocols (Esteva, Rodriguez-Aguilar, Sierra, Garcia, & Arcos, 2001). Although, in an actual organization, such constraints are likely to be somehow enacted by some agents playing roles and interacting, they cannot readily be expressed in terms of individual roles or individual interaction protocols (in the same way that social conventions and company directives horizontally influence our social life and our work but cannot be associated with any specific actor). Thus, the explicit identification of such constraints—captured in our concept of organizational 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
rules—is very important for the correct understanding of the characteristics that the organization-to-be must express and for the subsequent definition of the system structure by the designer. The explicit identification of organizational rules is also important in the context of open systems. With the arrival of new, previously unknown and possibly selfinterested agents, the overall organization must be able to enforce its internal coherency despite the dynamic and untrustworthy environment. The identification of global organizational rules allows the system designer to explicitly define: (1) whether and when to allow new agents to enter the organization and, once accepted, what their position should be; and (2) which behaviors should be considered as a legitimate expression of self-interest, and which among them must be prevented by the organization. In this context, organizational rules may also drive the designer towards the definition of the specific organizational structure that most eases the enforcement of the organizational rules and, for instance, can facilitate the prevention of undesirable behavior on the part of the unknown agents.
Organizational Structures A role model describes all the roles of an organization and their positions in that organization. Therefore, a role model also implicitly defines the topology of the interaction patterns and the control regime of the organization’s activities. That is, it implicitly defines the overall architecture of the MAS organization (i.e., its organizational structure). For example, a role model describing an organization in terms of a “master role” and “slave roles”—where the former is in charge of assigning work to the latter and of load balancing their activities—implicitly defines an organizational structure based on a hierarchical topology and on a load-partitioning control regime. Other exemplar organizational structures include collectives of peers, 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 development, 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 systems 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 realworld 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 optimizations 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 reorganization.
•
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 organizational 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 organizaCopyright © 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 structures—to support designers in choosing the most appropriate organizational structure for their problem. Currently, in the area of agent-oriented software engineering, most patternrelated 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 Role Model
Preliminary Interaction Model
Organizational Rules
GAIA SCOPE ARCHITECTURAL DESIGN
Organizational Structure Organizational Patterns
DETAILED DESIGN
Role Model
Interaction Model
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 (suborganizations) composing the overall system.
The Organizations The first step in Gaia’s analysis is concerned with determining whether multiple organizations have to co-exist in the system and become autonomous, interacting MASs. Identifying such organizations is reasonably easy if the system specification 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 considerations 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 abstractions and general modeling techniques because, as already stated, the environments 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 graphical 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 representation 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 particular, this equates to identifying the “basic skills” that are required by the organization to achieve its goals, as well as the basic interactions that are required for the exploitation of these skills. Such identification activities may even be facilitated if a goal-oriented early requirements analysis has already modeled the characteristics of the system in terms of actors involved and their goals. Given the identification of the basic skills and of their basic interaction needs, respectively, the analysis phase can provide a preliminary definition of the organization’s roles and protocols. However, this definition cannot be completed at this stage. In fact, the basic skills (or preliminary roles) can only truly become organizational roles when it is known how and with which other roles they will interact. This, in turn, requires the definition of the global organizational structure. Analogously, the basic interaction needs (or preliminary protocols) can only be fully defined as organizational protocols when the adoption of an organizational structure clarifies which roles these protocols will involve, when their execution will be triggered, and by whom. In addition, the design phase is 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, description to express their capabilities and expected behaviors. These are represented by two main attribute classes: •
Permissions are mainly aimed at: (1) identifying the resources that can legitimately be used to carry out the role—intuitively, they say what can be spent while carrying out the role; and (2) stating the resource limits within which the role must operate—intuitively, they say what can’t be spent while carrying out the role. In general, permissions relate agent roles to the environment in which they are situated; in order to carry out a role, an agent will typically have to access environmental resources and possibly change or consume them. However, they can also be used to represent the knowledge the agent can possibly have or have received from communications 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 “something 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 Gaia’s roles easier to define and understand by a wider audience. With all these definitions in place, it is now possible to precisely define the Gaia (preliminary) roles model. A roles model is comprised of a set of role schema, one for each role in the system. A role schema draws (i.e., lists) together the various attributes discussed above into a single place (see Zambonelli et al.[2003] for several examples of Gaia role schemata). In the case of the preliminary role model, such a schema may simply leave some of its parts undefined, to be later completed in the architectural design phase.
Preliminary Interaction Model The Gaia interaction model captures the dependencies and relationships between 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 necessarily 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 guidelines 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 previously stated, there may be general relationships between roles, between protocols, and between roles and protocols that are best captured by organizational rules. In Gaia, the perspective on organizational rules is consistent with that on roles’ responsibilities—organizational rules are considered responsibilities of the organization as a whole. Accordingly, it is possible to distinguish between safety and liveness organizational rules. The former refer to the invariants that must be respected by the organization for it to work coherently; the latter express the dynamics of the organization (i.e., how the execution must evolve). In particular: •
Liveness rules define how the dynamics of the organization should evolve over time. These can include, for example, the fact that a role can be played by an entity only after it has played a given previous role or that a given protocol may execute only after some other protocol. In addition, liveness organizational rules can relate to other liveness expressions belonging to different roles, that is, relating the way different roles can play specific activities.
•
Safety rules define time-independent global invariants for the organization that must be respected. These can include, for example, the fact that a given role must be played by only one entity during the organization’s lifetime or that two roles can never be played by the same entity. In addition, they can relate to other safety rules of different roles or to expressions of the environmental variables in different roles.
Due to their similar nature, organizational rules can be expressed by making use of the same formalisms adopted for specifying liveness and safety rules for roles (i.e., regular expressions, predicates, temporal logics).
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 MAS’s actual characteristics starting from the specifications. 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 organization—whether a human being, a hardware component, or a software agent—exhibits bounded rationality (Simon, 1957); that is, the amount of information it is able to store and process in a given amount of time is limited. Therefore, for an organization to work efficiently, it must not overload its members. Whenever the problem of bounded rationality is likely to affect the organization, the organization has to enlarge its resources (i.e., of its members), so as to better distribute the workload among them. The fact that organizations of different sizes may require different organizational topologies derives from the coordination costs that are incurred as the number of members in the organization increases. As a general guideline, the simplest organization topology that makes it possible to properly handle the computational and coordination complexity should be chosen. At one extreme, a single-member organization experiences no coordination costs and has the advantage of extreme simplicity, although in most cases it is impossible to charge a single agent with all the duties. When an organization is composed of only a few members, the coordination costs can be sufficiently low that collective decisions among all the members are possible. The resulting organizational network is a collective of peers in which all members, although possibly committed to different roles, have the same authority over the global organization. When the size of the organization increases still further, the members of the collective can no longer bear the increased coordination costs and a hierarchical topology must be adopted. In the hierarchy, the organization’s members are freed from the duty of handling the coordination activities because a leader member assumes responsibility for them. As the organization’s size increases further, a collective leadership may be needed to handle the increased coordination costs, or a multi-level hierarchy may emerge. In general, any composition of the basic structures can be adopted for the definition of the overall organizational structure. Also, in some cases, hybrid organizational networks can emerge. For example, a collective of peers can be ruled by a leader for a limited
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 significant 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 organizational 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 inefficiencies 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 organizational 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 organization 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 agentbased 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 uncovers 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 complement 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 interactions (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 characteristics 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 separation—that for the sake of simplicity could also be preserved as a comment to the textual description of the protocols—assumes a fundamental importance in the perspectives of re-use and design for change. If the definition of a role clearly specifies the logical separation between the two parts, and the implementation of the role somehow does the same, this enables the role be reused 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 dynamically changing their internal organizational structure—by having agents re-adapt their extrinsic part to fit into a new organizational structure—in response to changed conditions. However, dealing with such dynamic re-organizations would require the multi-agent system to monitor its execution and make decisions about its re-structuring, and these are issues that are beyond the scope of this chapter and of the current version of Gaia. Once completed, the roles and interaction models represent an operational description of the MAS organization that could be effectively exploited, possibly with the support of the environmental model (to get a better idea of the characteristics of the MAS operational environment), for the detailed design of the MAS.
The Design Phase: Detailed Design The detailed design phase is responsible for eventually identifying the agent model and the services model that, in turn, act as guidelines for the actual implementation of agents and their activities.
Definition of the Agent Model In the Gaia context, an agent is an active software entity playing a set of agent roles. Thus, the definition of the agent model amounts to identifying which agent classes are to be defined to play specific roles and how many instances of each class have to be instantiated in the actual system. 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 classes—a given role will be played by an instance of an agent of a class in charge of implementing that role. Such a correspondence naturally derives from the methodological process that was adopted in which the concept of role has implicitly assumed ever greater concreteness, especially during the identification of the organizational structure. However, given that (1) the organizational efficiency is not affected, (2) bounded rationality problems do not emerge, and (3) this does not violate organizational rules, a designer can choose to package a number of closely related and strongly interacting roles in the same agent class for the purposes of convenience. There is obviously a tradeoff between the coherence of an agent class (how easily its functionality can be understood), the efficiency considerations that come into play when designing agent classes, and the need to minimize mismatches with the real-world organization that the system intends to support. The agent model of Gaia can be defined using a simple diagram (or table) specifying for each agent class which roles will map to it. In addition, the agent model can document the instances of a class that will appear in the MAS. This can be done by annotating agent classes with qualifiers from Fusion (Coleman et al., 1994). In any case, it is worth highlighting that the agent model of Gaia is of use in driving the static assignment of roles to agent classes in which the implementation of the agent class is assumed to hardwire the code to implement one or more roles. Of course, if the implementation adopts a framework enabling agents to dynamically assume roles, the concept of the agent class of Gaia (and so the Gaia agent model) would no longer be of use. As a final note, inheritance is given no part in Gaia’s agent models, since our experience is that an MAS typically contains only a comparatively small number of roles and classes, making inheritance of little use in design. Of course, when it comes to actually implementing agents, inheritance will be used in the normal object-oriented fashion.
The Services Model As its name suggests, the aim of the Gaia services model is to identify the services associated with each agent class or, equivalently, with each of the roles to be played by the agent classes. Thus, the services model applies both in the case of static assignment of roles to agent classes and in the case where agents can dynamically assume roles. While in OO terms a service would roughly correspond to an operation, agent services are not available for other agents in the same way that an object’s operations are available for another object to invoke. Rather, due to the intrinsically active nature of an agent, a service is better thought of as a single, 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-conditions, 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 resources). Pre- and post-conditions represent constraints on the execution and completion of services, respectively. These are derived from the safety properties 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 management 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 proceedings.
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 identification 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 structure.
•
The identified organizational rules may suggest alternative choices to that of mimicking the structure of the real-world organization. For instance, to guarantee that each paper is assigned to at least three reviewers requires some form of global coordination that, even if potentially possible, could be extremely expensive if the PC chair has decided to make PC members autonomously select (or bid for) the papers they will review. A better alternative would be to opt for a centralized control over the assignment of papers to PC members.
•
The availability of a software system automating several portions of the process could significantly reduce the human load of the conference organization (based on which the real-world organization has planned to organize the process). This can, in turn, suggest the adoption—both in the real-world and in the MAS organization—of a totally different structure than the one that was originally planned.
Once the above considerations have been taken into account, they will eventually enable a suitable organizational structure to be identified. Based on this, the preliminary roles and interaction protocols can be completed and the final organization of the MAS can be properly represented in a complete form (i.e., including all the involved roles and protocols and their interactions with the environmental resources).
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 abstractions and models that—despite being very important for the effective development of MASs—are not taken into account (or are underestimated) by most of the current agent-oriented methodologies.
•
Gaia, while adopting an organizational metaphor that naturally fits the needs and the characteristics of MASs and of modern distributed systems, proposes a design process that is coherent and broadly similar to the ones that are currently widely adopted in traditional software development (i.e., object-oriented and component-based software development). Therefore, by bringing all the specific advantages of agent-oriented computing into a rather traditional software development process, Gaia can facilitate the promotion of agent-oriented software engineering as a mainstream software engineering paradigm.
•
Gaia does not commit to any special-purpose notations for its models. It suggests the adoption of some simple and intuitive notations without excluding the possibility of coupling these notations with more formally grounded notations (such as AUML, temporal logic, or whatever might be of use in specific contexts). This choice makes Gaia very likely to be accepted by the majority of developers (who typically do not like to manage formalisms) without preventing the adoption of a more rigorous approach to MAS development.
•
Gaia’s design process promotes a design for change perspective and may facilitate, in the future, the development of dynamic MASs in which the organizational structure, the roles played by the agents in the MASs, and the characteristics of the operational environment are allowed to dynamically change during the execution of the system.
However, we are also aware of a number of limitations in the current version of the Gaia methodology: •
Gaia does not deal directly with implementation issues. Such a radical choice, driven by conceptual simplicity and generality, may not always be practical. In fact, it may be the case that specific technology platforms may introduce constraints over design decisions and may require being taken into account during analysis and design. A trivial example relates to environmental modeling: if the environmental resources are of a passive nature, one cannot rely on having agents perceive them in terms of events. Gaia—by neglecting such implementation issues—has no way of handling them.
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 engineering, 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 methodology, 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 engineering 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 Software 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 Systems, 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 Symposium 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 AgentMediated 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 International 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 Transactions 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: SpringerVerlag. 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 coordination 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. Communications of the ACM, 43(5), 36-42. Wood, M., DeLoach, S.A., & Sparkman, C. (2001). Multiagent system engineering. International Journal of Software Engineering and Knowledge 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). Agentoriented 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 Proceedings of the 1st International Workshop on Agent-Oriented Software Engineering, Volume 1957 LNCS (pp. 253-252). Berlin: SpringerVerlag. Zambonelli, F., Jennings, N.R., & Wooldridge, M. (2003). Developing multiagent systems: The Gaia methodology. ACM Transactions on Software Engineering 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 Valérie 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 limitation—it is a specialized methodology, especially suited to the development of software with emergent functionalities.
Introduction Usually, classical design of computational systems requires some important initial knowledge in the sense that the exact purposes of the system and every interaction to which it may be confronted in the future have to be known. However, at the same time, today’s problems are becoming more and more complex (e.g., information searching on the Internet, mobile robots moving in the real world). Indeed, systems that are able to deal with such problems are also becoming open and complex; they are immersed in a dynamical environment; they are often incompletely specified and, especially, an a priori known algorithm does not exist to find a solution. Classical approaches then become inadequate and a new way to tackle such problems is necessary. Our research work, for several years now, has essentially focused on these kinds of systems and has led us to propose Adaptive Multi-Agent Systems (AMAS) as an answer (Camps, Gleizes, & Glize, 1998; Capera, Georgé, Gleizes & Glize, 2003; Gleizes, Georgé & Glize, 2000; Piquemal-Baluard, Camps, Gleizes, & Glize, 1996). These systems are composed of agents that permanently try to maintain cooperative interactions with others. We have built, with success, several systems based on the use of adaptive agents in different areas. To ease and promote this kind of programming, we then developed the ADELFE methodology, the aim of which is to help and guide designers when developing AMAS. The remainder of this section briefly presents the foundation of adaptive multiagent 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 modification 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 representation 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. Perceptions 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 Situations (NCS). From an observer’s viewpoint, the whole system is able to detect any non-cooperative state coming either from the occurrence of novelty or resulting from feedback returned by the environment concerning a previously erroneous response of the system.
This theory has been applied to many projects: foraging ant simulation (Topin et al., 1999), knowledge management, e-commerce (Gleizes, Glize, & Link-Pezet, 2000), flood forecasting (Georgé, Gleizes, Glize, & Régis, 2003), routing in telephonic network, mechanical design, bio-informatics, and so forth. To ease our future work, design tools were required. They were also needed to promote this kind of programming towards designers not accustomed to developing AMAS. 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 adaptation. This led us to develop a toolkit—ADELFE—to work on some aspects not already considered by existing methodologies and to support the AMAS theory that has been briefly introduced above (Bernon, Camps, Gleizes, & Picard, 2002). ADELFE is an acronym that, translated from French, means “toolkit to develop software with emergent functionality.” In a general way, a methodology is made up of a process, some notations, and tools to support these notations and/or help the developer (Shehory & Sturm, 2001). ADELFE provides a specific process adapted from an interpretation of the Rational Unified Process (RUP) (Kruchten, 2000) according to the Neptune Project (http://www.neptune.irit.fr). Some additions have been made to take into account specificities of the AMAS theory, for example, the characterization of the environment of the system, the identification of cooperation failures, and so forth. In the third section of this chapter, each of these extensions is exemplified relating to a particular case study. The chosen case study consists of designing a system that enables end-users and service providers to get in touch when they share common centres of interest in a dynamic and distributed context (such as the problem described in Gleizes et al. [2000]). The main requirement of such an electronic information system is to enable (1) end-users to find relevant information for a given request, and (2) information providers to have their information proposed to relevant end-users. More precisely, the system has to provide: •
Personalized assistance and notification for the end-users;
•
Propagation of requests between the actors of the system;
•
Propagation of new information only to potentially interested end-users; and
•
Acquisition of information about end-users’ real interests, in a general manner, and about the information offers of providers.
We are clearly situated in a system where every end-user and service provider has an individual goal: to answer the request he/she has to solve. Each end-user and service provider does not know the global function of the system. The system is strongly open because a great number of appearances or disappearances of
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 relevant—we can say that such a system is functionally adequate when a satisfied end-user wants to use services of the system again, and when each service is fully used, namely, in the most profitably way for the supplier. Although ADELFE is an agent-oriented methodology suited to develop applications 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 agent’s lifecycle.
•
As introduced in the previous section, modules are related to a cooperative agent and stereotypes have been associated with each one of these modules: «skill», «aptitude», «representation», «interaction», «perception», «actions» (perceptions and actions are specific interactions), and «cooperation».
•
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 methodology.
•
A “Description” interface (window #3, Figure 2) explains stages composing 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 methodology 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 design—from the requirements to the deployment. A wellknown process, the RUP, has been tailored to take into account specificities coming from the design of adaptive multi-agent systems. Phases are called WorkDefinitions (WDi), Activities (Aj) or Steps (Sk), following the vocabulary of the Object Management Group’s (OMG) Software Process Engineering Metamodel (SPEM) (OMG, 2002), which has been used to express the ADELFE process (Gleizes, Millan, & Picard, 2003). Only the requirements, analysis, and design work definitions require modifications in order to be adapted to AMAS, others appearing in the RUP remaining the same. This section gives a theoretical and sequential description of these three WDs, but, of course, a designer may back track between the different stages, like in the RUP. The stages that are specific to the AMAS technology are marked with a bold font in the description tables below. For reasons of clarity, their theoretical description 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 A1: Define user requirements A2: Validate user requirements A3: Define consensual requirements A4: Establish keywords set A5: Extract limits and constraints
WD2: Final requirements A6: Characterize environment S1: Determine entities S2: Define context S3: Characterize environment 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 enduser 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 complete, accurate, and up-to-date information about the state of its environment. 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 environment 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 endusers 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 inaccessible, 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 preliminary 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 S1: Identify classes S2: Study interclass relationships S3: Construct preliminary class diagrams A11: Verify the AMAS adequacy S1: Verify it at the global level S2: Verify it at the local level
A12: Identify agents S1: Study entities in the domain context S2: Identify potentially cooperative entities S3: Determine agents A13: Study interactions between entities S1: Study active/passive entities relationships 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 advertisement), have a partial view of their environment (other active entities), or may interact with others to target the search more effectively. They are then potentially cooperative. Furthermore, since the system is open, new entities may appear or disappear, and they may not be able to communicate as they should (e.g., an entity does not understand requests from a new entity). In that case, an active entity is prone to cooperation failures and can be viewed as a cooperative agent. Each end-user (or service provider) is then represented within the system by an agent called TransactionAgent (TA).
A13 - S3: Study Agent Relationships Interactions between all the identified entities are then studied in the last activity of this work definition (A13). Studying relationships between passive and active entities or between solely active ones is done by using UML collaboration or sequence diagrams in a standard way. However, in the last step of this activity, protocol diagrams are used to express relations between all the existing agents (A13-S3). These diagrams can be built using OpenTool modified to support AUML. The AUML protocol diagram, shown in Figure 4, expresses the way in which the system responds to an end-user’s request. The end-user TA, which represents the end-user, tries to satisfy the request by finding a relevant service provider TA. If it does not have any relevant partner, it asks a special address provider TA for partner addresses. Since every TA is cooperative, when a TA judges itself incompetent to respond to a received request, it will not discard this request; rather, it will send it again to another TA that is competent from its point of view. Every TA having the same cooperative behaviour, the request may be propagated 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-user’s request.
WD4: Design This design work definition is an important stage because the recursive characterization 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 «cooperative agent» stereotype will appear (A14). In the case study, the TransactionAgent’s (TA’s) goal is to find relevant TAs according to the request that its associated end-user or service provider submitted for solution. To represent these TAs, a class called TA has been
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 S1: Determine packages S2: Determine classes S3: Use design-patterns S4: Elaborate component and class diagrams A15: Study interaction languages
A16: Design agents S1: Define skills S2: Define aptitudes S3: Define interaction languages S4: Define world representations 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 communicate, 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 diagrams 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» (A16S3). 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 (respectively 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, «action»void sendMessage (Message AMessage, Reference Dest). A16 – S4: Design Representations Attributes and methods that enable an agent to create its own representation about itself, other agents, or the environment it perceives are identified and stereotyped with «representation» (A16-S4). In the case study, representations that an agent possesses about itself or about other TAs may evolve at runtime and they have then to be adjusted. We choose to use an AMAS to implement them. When a TA receives a request, it has to query its representation on itself to know if it is relevant to solve this request. The class TA needs the following attribute to access this component, that is, «representation» LocalBelief MyBelief. A16 – S5: Design Characteristics In the next step (A16-S5), the intrinsic or physical properties of an agent have to be described and tagged by the «characteristic» stereotype. In the case study, the physical address of a TA, called myReference, represents the address of the TA in the system, that is «characteristic» Reference MyReference; and the method to get its value is: «characteristic» Reference getReference(char *Name). A16 – S6: Design Non Cooperative Situations This is the most important step in this activity because the ability to detect and remove Non Cooperative Situations is specific to cooperative agents (A16-S5). A model (cf. Table 4) is available to help the designer to enumerate all the situations that seem to be “harmful” for the cooperative social attitude of an agent. It reminds the designer that these situations belong to several types (such as ambiguity, uselessness, etc.) and are dependent on some conditions (one or several) that may be fulfilled or not when the agent is performing a certain phase in its lifecycle (perception, decision, action). In the case study, if we only consider the decision phase, three NCS can be identified. All of them depend on only one condition as shown in Table 5. After having identified every NCS an agent could encounter, the designer fills up a second type of table (see Table 6) that describes each NCS. This description
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 agent’s lifecycle step and the fulfilled conditions.
Perception Decision Action
Condition 1 not fulfilled Condition 2 not Condition 2 fulfilled fulfilled Incomprehension? Incomprehension? Ambiguity? Ambiguity? Incompetence? Incompetence? Unproductiveness? Unproductiveness? Concurrence? Concurrence? Conflict? Conflict? Uselessness? Uselessness?
Condition 1 fulfilled Condition 2 not Condition 2 fulfilled fulfilled Incomprehension? Incomprehension? Ambiguity? Ambiguity? Incompetence? Incompetence? Unproductiveness? Unproductiveness? Concurrence? Concurrence? Conflict? Conflict? Uselessness? Uselessness?
Table 5. Table 4 Partially Filled up for the Case Study – Only the “decision” phase is considered. A TA cannot extract any informative content from the received message Decision
Total Incompetence
A TA can extract an informative content from only one part of the received message Partial incompetence
A TA can extract several informative content from the received message 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 State Description Conditions Actions
Name State Description Conditions Actions
Name State Description Conditions
Actions
Name State Description Conditions
Actions
Total incompetence Receipt of a request An agent faces total incompetence when it cannot associate any meaning to the message it 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 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 transmit the message to an agent that seems to be relevant according to its representations on others.
Partial incompetence Receipt of a request An agent is faced with partial incompetence when only one part of the received message has a meaning for it. During the interpretation phase the agent compares the received request with its own 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 the message. It sends the other part of the request to a more relevant agent.
Ambiguity Receipt of a request An ambiguity occurs when the content of a received request is incomplete either because the sender gets a bad description of the receiver’s tasks or because the specification of the message is wrong. During the interpretation phase the agent compares the received request with its own 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 of the received request. The initial sender is then able to choose the most pertinent one and update its representation about the receiver’s skills.
Concurrence Receipt of a request 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 the request, the agent compares this request with the representation it has about other agents to find rival agents. An agent A competes with an agent B, from B’s point of view, if A can extract informative content from the same part of the request as B. Redundancy is beneficial when an agent has not been able to reach its aim or to accept a 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 statemachine. 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 statechart 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 already 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. However, today’s and tomorrow’s applications are complex and open ones; they evolve in an unpredictable environment, like the Internet, and represent the next challenge for building software. To take up this challenge, it is necessary to develop new models, tools, and methodologies. The main strength of ADELFE (and its specificity) is to provide a methodology to design Adaptive Multi-Agent Systems coupled with a theory for those systems. According to the theory (Gleizes et al., 2000), self-organization by cooperation enables an MAS to adapt itself and to realize a function that it is not directly coded within its agents. ADELFE is thus a specialized methodology that deals with only a certain kind of agents—cooperative ones—to build systems in which the global function emerges from the interactions between these agents. ADELFE is based on “standards” such as the RUP, UML, or AUML notations to promote agent-oriented programming in an industrial world where objectoriented 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 importance 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 agent—ADELFE is a recursive or iterative methodology. Finally, the greatest difficulty in this behaviour definition is to identify Non Cooperative Situations that an agent may encounter, and some models are given to help the designer to find these. An automatic transformation from collaboration diagrams into state-machines has been added to OpenTool to allow their simulation. Once the agents are defined, this specific activity may be used to test the behaviour of an agent to improve it if needed. Modularity is also an important strength of ADELFE. It has been based on an interpretation of the RUP by adding some specific activities and steps, namely, those related to the AMAS technology. The process of ADELFE can then be decomposed into fragments that may be reused in other agent-oriented methodologies 3. It would also be easier to integrate pieces coming from other methodologies 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, observation 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 methodology. 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 methodologies. That would enable a designer to build his/her own methodology (adapted to his/her particular needs) from different existing ones. A second perspective of our work in the engineering domain would also be to endow ADELFE with a tool that would automatically transform a meta-model into a model depending on a target platform in the spirit of OMG’s Model-Driven Architecture (MDA) initiative4.
Acknowledgments We would like to thank the support of the French Ministry of Economy, Finance, and Industry, as well as our partners: TNI-Valiosys Ltd. (for their customization of Open-Tool), ARTAL technologies Ltd., and the IRIT software engineering team (for their help and work on UML and SPEM).
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 selforganizing 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 “Engineering Societies in the Agents World” (ESAW), LNAI 2577 (pp. 156169). Berlin: Springer-Verlag. Brazier, F. M. T., Jonker, C. M., & Treur, J. (1999). Compositional design and reuse of a generic agent model. In Proceeding of Knowledge Acquisition Workshop (KAW’99), Banff, Canada. Camps, V., Gleizes, M-P., & Glize, P. (1998). A self-organization process based on cooperation theory for adaptive artificial systems. In Proceedings of the First International Conference on Philosophy and Computer Science “Processes of Evolution in Real and Virtual Systems”, Krakow, Poland (pp. 2-4). Capera, D., Georgé, J-P., Gleizes, M-P., & Glize, P. (2003). The AMAS theory for complex problem solving based on self-organizing cooperative agents. In Proceedings of the First International Workshop on Theory and Practice of Open Computational Systems (TAPOCS03@WETICE 2003), Linz, Austria (pp. 383-388). IEEE Computer Society. Desfray, P. (2000). UML profiles versus metamodel extensions: An ongoing debate. OMG’s UML Workshops: UML in the .com Enterprise: Modeling CORBA, Components, XML/XMI and Metadata Workshop, November. Available online http://www.omg.org/news/meetings/workshops/ uml_presentations.htm Georgé J-P., Gleizes, M-P., Glize, P., & Régis, C. (2003). Real-time simulation for flood forecast: An adaptive multi-agent system STAFF. In Proceedings of the AISB’03 symposium on Adaptive Agents and Multi-Agent Systems, University of Wales, Aberystwyth (pp. 109-114). Society for the Study of Artificial Intelligence and the Simulation of Behaviour. Gleizes, M-P., Georgé, J-P., & Glize, P. (2000). A theory of complex adaptive systems based on co-operative self-organisation: Demonstration in electronic commerce. In Proceedings of the Self-Organisation in MultiAgent 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 Collaborative Enterprises (WET ICE’00), Gaithersburg, Maryland (pp. 59-66). IEEE Computer Society. Gleizes, M-P., Millan, T., & Picard, G. (2003a). ADELFE: Using SPEM notation to unify agent engineering processes and methodology. IRIT Internal Report 2003-10-R. Iglesias, C.A., Garijo, M. & Gonzalez, J.C. (1998). A survey of agent-oriented methodologies. In Proceedings of the Fifth International Workshop, ATAL ’98, LNAI 1555, Paris, July 4-7 (pp. 317-330). Berlin: SpringerVerlag. 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 (AOSE’00), Limerick, 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 Workshop on Multi-Agent Systems (EUMAS’03), Oxford, UK. Piquemal-Baluard, C., Camps, V., Gleizes, M.-P., & Glize, P. (1996). Properties of individual cooperative attitude for collective learning. In Proceedings of the Seventh European Workshop on Modelling Autonomous Agents in a Multi-Agent World (MAAMAW’96), Eindhoven, The Netherlands, January 22-25, position paper. Russel, S. & Norvig, P. (1995). Artificial intelligence: A modern approach. Englewood Cliffs, NJ: Prentice Hall Series. Shehory, O. & Sturm, A. (2001). Evaluation of modeling techniques for agentbased systems. In Proceedings of the Fifth International Conference on Autonomous Agents (pp. 624-631). New York: ACM Press. Topin, X., Fourcassie, V., Gleizes, M-P., Theraulaz, G., Régis, C., & Glize, P. (1999). Theories and experiments on emergent behaviour: From natural to
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 (AOSE’00), Limerick, 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 Telefónica I+D, Spain Jorge J. Gómez-Sanz Universidad Complutense de Madrid, Spain Philippe Massonet CETIC, Belgium
Abstract This chapter presents the MESSAGE agent-oriented software engineering methodology and illustrates it in an analysis and design case study. The methodology covers MAS analysis and design and is intended for use in mainstream software engineering departments. MESSAGE integrates into a coherent AOSE methodology basic agent-related concepts (such as organisation, role, goal, interaction, and task) that have so far been studied largely in isolation. The MESSAGE notation extends the UML with agent knowledge-level concepts and diagrams with notations for viewing them. The proposed diagrams extend UML class and activity diagrams. The
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, Gómez-Sanz & Massonet
MESSAGE analysis and design process is based on the Rational Unified Process (RUP). The methodology distinguishes high-level from detailed design. An organisation-driven approach is presented for detailed design, where the global architecture of the MAS is derived from the structure and behaviour of the organisations that interact. Experimentation with the methodology shows that it supports the analysis and design of multi-agent systems that are flexible and adapt to specific kind of changes in a heterogeneous and dynamic environment.
Introduction The agent-oriented (AO) approach promises the ability to construct flexible systems with complex and sophisticated behaviour by combining highly modular components. When several of these components interact, the intelligence of these components—the agents—and their capacity for social interaction results in a multi-agent system (MAS) with capabilities beyond those of a simple “sum” of the capabilities of the individual agents. The availability of agent-oriented software engineering (AOSE) methodologies is a pre-requisite for engineering commercial MASs. The MESSAGE methodology 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 agentoriented 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 framework. 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 highrisk 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 divisions 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, Gómez-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 characteristics, 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 relations that are relevant for the system under development. The above models contain the data that defines the system and that is represented 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 MESSAGE meta-model provides the concepts, the underlying structure, and the rules for producing application models. Figure 1 shows the main agent-related meta-concepts (Caire, Coulier, et al., 2002; EURESCOM P907, 2003), for example, an Agent is an atomic autonomous entity that is capable of performing some (potentially) useful function. In these diagrams, each concept is related to others using labeled associations, denoting the semantics of the association. The MESSAGE concepts extend UML concepts by means of the MOF generalization primitive. For instance, the agent concept extends the MESSAGE Entity that extends the UML classifier concept. During design, the analysis models are refined into computational entities that can be implemented in an agent platform. Two distinct phases of design are considered: high-level and detailed design. The first phase involves identifying an agent architecture, assigning roles to agents, and describing how the application services are provided in terms of tasks. The tasks can be decomposed into direct actions on the agent’s internal representation of the environment, and communicative 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 platformdriven 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
AimsToAchieve
Provides ServiceTo
Plays
Information Entity
Agent
Implements
Perceives
Acquaintance
Performs
Describes
Action
Event
Describes StateOf
GeneratedBy ChangeOfState
Service
Task
Generates
Communicative Communicative Action Action
Resource Affects DirectAction DirectAction
Figure 2. MESSAGE modelling process description ANALYSIS MODEL TSP
TSP
Parent pane
Parent pane
KM sy stem
KM sy stem
< < Wish > > 1 1
1
Book ing D atabas e
1..*
istrator
Tra vel Catalog
1 ..*
A dministrativ e Team
KM Sys te m
Sys te m A dmin -
1 ..*
1
1
1 ..*
Sales Team
Team
1
Tra vel Catalog
1 ..*
A dmin istrativ e
KM Sys te m
1..*
1
A dmin
-
Tra veler
KM system << Wish >>
Team
Store s
Structure pane
Sales -
TA Gatherer
<<participation>>
Tra veller
Tra velling Requ ir ements
Sen ds
K now n
Tra vel A rr angeme nts G athere d
Bes t Trav el A rr angeme nt I den Id entif tified ied
Tra vel A rr angeme nt Selected
1..*
Tra vel Tra vel
Book ing
D atabas e
D atabas e
Catalog
Child pane
TSP TA Gatherer Assistant
Collaborator <<participation>> TSP 1 Assistant
Travelling Request
Travel 1 Requirement 1
A ss is ted
per son boo kin g s
ar rang ements
Tra veller A ss is ted
LEVEL 0 Initiator
Parent pane
istratio n
KM Sys te m tr avel
< < Wish > >
Structure pane
Tra veller A ss is ted
Sales per son
Tra vel D atabas e
A dmin i stra tor
Sys te m A dmin istrator
Sales per son
Tra vel D atabas e
Sys te m
Retrieves
Structure pane
1..*
Sales Team
1 ..*
1
Book ing D atabas e
Travel Arrangement
LEVEL 1
1..*
TA Selector
LEVEL N REFINES Travelling Arrangements Provided
Personal Travel Agent
<<wish>>
TSP Sales Assistant <>
TSP Travelling Booking Services Provider <> Manager
Provide Flight Availability <>
<<manages>> Flight Destinations
Traveler Requirements
<<provision>> ProvideTravel Arrangement s
PTA
<<provision>> Travellingarrangementselection
TravelRequirement TravelArrangement
Get travel Arrangements
Send / Receive TAs
DESIGN MODEL HIGH LEVEL DESIGN
TSP Booking
Airline Booking Request, TA
Score travel arrangements
Agree
< < per for mance > >
< < per for mance > >
Not-understood TSP Assistant
TA Gatherer
TA Selector
Refuse
Booking Request Formulated Booking Request Submitted
Diagnosed
Not Understood Refuse Booking Request Cancelled Failure
Agree Booking Request Agreed
Booking Request Confirmed
Inform
REFINES DETAILED LEVEL DESIGN ORGANIZATION AGENT PLATFORM AGENT PLATFORM ORGANIZATION DRIVEN DESIGN DRIVEN DESIGNDRIVEN 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
208 Garijo, Gómez-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 agent’s services. The quality of autonomy means that an agent’s actions are not solely dictated by external events or interactions, but also by its own motivation. We capture this motivation in an attribute named purpose. The purpose will, for example, influence whether an agent agrees to a request to perform a service and also the way it provides the service.
•
Organization: An Organization is a group of Agents working together to a common purpose. It is a virtual entity in the sense that the system has no individual computational entity corresponding to an organization; its services 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 constituents.
•
Role: The distinction between Role and Agent is analogous to that between Interface and (object) Class—a Role describes the external characteristics of an Agent in a particular context. An Agent may be capable of playing several roles, and multiple Agents may be able to play the same Role. Roles can also be used as indirect references to Agents. This is useful in defining re-usable patterns.
•
Goal: A Goal associates an Agent with a state. If a Goal instance is present in the Agent’s working memory, then the Agent intends to bring about the state referenced by the Goal.
The main types of activity are: •
Task: A Task is a knowledge-level unit of activity with a single prime performer. A task has a set of pairs of Situations describing pre- and postconditions. 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 subtasks (which may have different performers from the parent Task). Tasks can be modelled as state machines, so that, for example, UML activity diagrams can be used to show temporal dependencies of sub-tasks. •
Interaction and Interaction Protocol: An Interaction is characterized by more than one participant and the purpose that the participants collectively must aim to achieve. The purpose typically is to reach a consistent view of some aspect of the problem domain, to agree to terms of a service, or to exchange results of one or more services. An Interaction Protocol defines a pattern of MESSAGE exchange associated with an Interaction.
The MESSAGE notation is based on UML. Agent-related concepts are defined as level 2 meta-models using OMG’s meta-model Facility, MOF (OMG, 2000). The organization model, for example, is defined as an M-2 Layer meta-model using the MOF four-layer architecture. One of the practical advantages of this approach is that UML tools, which will help engineers to create, manage, and reuse object-oriented application models, can interpret MOF meta-models to provide tool support for analysis and design using MESSAGE. Figure 3 shows the graphical syntax of some of the above-mentioned level-1 concepts. The Assignment meta-relationship is specialized into “Play: Agent x Role,” “Wish: Agent x Goal,” “Perform: Agent/Role x Task,” “Participates: Role x Interaction,” “Implements: Task x Service,” and “Provides: Agent/Role/ Organization x Service.” Figure 3. MESSAGE graphical notations
Agent
Goal
Interaction
Role
Task
Organization
Implication
Assignment
Acquaintance
DataFlow
Service
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, Gómez-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 tolerance, 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 postcondition 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 combination 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, Gómez-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 designer’s views and experience, although heuristic criteria might be applied, for example, assigning to an agent a single complex role, grouping similar functional roles and assigning them to an agent.
2.
Providing services with tasks. If any analysis workflow diagrams in the Organization Model (OM) have been defined, they can be further refined in this stage. The refinement process should specify the relationships between services and tasks, tasks and goals, and goals to roles.
3.
Refining the interaction protocols. This step involves refining the interactions identified in analysis. Interactions can be modelled in terms of interaction protocols (Odell, Parunak, & Bauer, 2001) and UML statecharts. 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 mappings, 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 computing 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 imposes 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 Administrator
Administration Team
Salesperson
KM System Retrieves travel arrangements Travel Database
Traveler
Stores bookings
Booking Database
Sends Travel Catalog
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 Database 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 interactions 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, Gómez-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 agent’s behaviour and interfaces. This includes the agent’s domain and social knowledge. This is defined using the structure and the relationships of the Organization Model. It supports reasoning about other agent’s actions, about the society itself, and the social constraints upon an agent’s actions (Garijo, Gómez-Sanz, Pavón, & Massonet, 2001)
•
Using conventional software engineering modelling techniques can help to detail internal agent architecture behaviour. For instance, sequence diagrams 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: databases, 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, Gómez-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..* Travel Catalog
1
1
KM System
Administrative Team
1 Booking Database
1 Travel Database
1..* Sales Team
1..* System Administrator
1..* Salesperson
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, Gómez-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 However, it is rarely the case that the parent-constituent relationship is simply one of aggregation. The structural framework into which the constituents must fit is usually important. The structure concept is introduced in order to describe such frameworks in a reusable way. In the case of a goal/task diagram, it expresses how a goal of an organization is decomposed into , which are then assigned to the Organization’s constituents. A delegation structure diagram shows how the subgoals obtained decomposing a goal of an organization are assigned to the agents/roles included in the organization. Clearly this diagram is strictly related to (and must be consistent with) both the goal decomposition diagram showing the decomposition of the organization goal and the organization diagram showing the agents/roles inside the organization. Figure 6 shows a delegation structure diagram. Only the root and the leaves of the decomposition of the parent organization goal are shown. Similarly, a workflow diagram shows the roles in an organization that must perform the tasks necessary to implement a given service provided by the organization. An example of this type of diagram is shown later in Figure 9.
Figure 6. Delegation structure diagram view (notation as in Figure 3) Parent pane
KM system << Wish >>
Structure pane
Child pane
Traveller Assisted
Travelling Requirements Known
Travel Arrangements Gathered
TSP Assistant
TA Gatherer
Best Travel Arrangement Identified
Travel Arrangement Selected
TA Selector
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, Müller, & Odell, 2001). The modelling of an interaction protocol is on the border between analysis and design. The interaction can be detailed either in analysis or in design. The analysis stops here, but more iterations could be made.
Figure 7. Interaction diagram view (notation as in Figure 3)
Collaborator
Initiator <<participation>>
<<participation>>
Travelling Request
TA Gatherer
1
TSP Assistant
Travel 1 Requirement 1
1..*
Travel Arrangement
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 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 highlevel agent concepts of the analysis and design modelling language could help structure the agent implementation that is usually based on a simpler set of agent concepts. The case study showed that high-level design decisions were easier to make using MESSAGE than using the implementation-dependent concepts. This approach is not described further in this chapter.
Analysis: Travel Agent Case Study This section shows how the development process and notation can be applied to the case study. The first step should be to identify the level 0. This level requires identifying first the organization involved and the goals it pursues. •
Context: traveling from one location to another involves creating a travel plan with a very tight schedule. It might involve taking a taxi from one’s home to the airport, taking a flight to an intermediate location, taking a connecting flight to the final destination where a rented car has been booked and can be picked up to drive to the hotel where reservations have been made. Unfortunately for the traveler, many things can go wrong with a travel plan.
•
Requirements: Given the fact that many travellers will soon have wireless terminals, the efficiency of the traveling process can be improved by developing a system (distributed both in these terminals and in the terrestrial network) that: •
gathers travel requirements from the traveller;
•
assists in identifying and arranging relevant travel services offered by the travel service providers;
•
assists with the booking of travel tickets; and
•
monitors that the travel arrangement is carried out as planned by providing alerts and notifications of changes to arranged travels.
Organizations Figure 4 describes structural relationships in a level 0 organization diagram. The diagram shows that the Knowledge Management (KM) system is owned by the Travel Sales Person system (TSP). A Salesperson is part of a team and there 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>> PTA TravelRequirement
Get travel Arrangements
Travellingarrangementselection
TravelArrangement
Send / Receive TAs
<>
<>
TSP Assistant
Score travel arrangements
TA Gatherer
TA 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 communicative 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, Gómez-Sanz & Massonet
Figure 10. Partial request interaction protocol TSP Booking
Airline Booking Request, TA Agree Not-understood Refuse
request interaction protocol. A TA is passed as the content of the request message.
Interactions Roles Defined with State Machines This step involves modelling the behaviour of the roles in an interaction protocol. Figure 11 shows how the “TSP Booking Manager” role’s behaviour can be modelled for the request interaction protocol. When a booking request is refused or not understood, it is diagnosed and a decision is made to either cancel the request or retry the request. Figure 11. TSP booking manager state chart
Booking Request Formulated
Diagnosed Not Understood Refuse Booking Request Cancelled
Booking Request Submitted
Failure
Agree Booking Request Agreed
Booking Request 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, Gómez-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 Arrangements Provided
Personal Travel Agent
TSP Sales Assistant
<<wish>> Provide Flight Availability
Travelling Services Provider
<> <<manages>> Flight Destinations
Traveler Requirements
<>
<>
TSP Booking Manager
<<provision>> ProvideTravel Arrangements
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 agentplatform-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 organization. The package structure is derived from the organization meta-model. Once the organization has been modeled, the developer can proceed with selecting an agent architecture, detailing the specification of the agent’s behaviour and defining the agent society’s infrastructure. Figure 12. Organization-based architecture <> TravelAssistanceAgency pursues
is structured
has worlkflowss
<> Organisation Purposes <> UPATravelServicesOrganisation
<<Workflow>> Workflow
is structured
contains
contains <<Workflow>> ProvidingTravelInfo&NotifW
<> UPATravelInfoNotificationOrganisation
contains contains
contains
<<Workflow>> ManagementW
contains contains
uses contains
Resources
contains <> UPAFlightInfo&NotificationAssistantAg
<> UPATrialAccessAg
<> UPAAirlineInfoDeskAg
<> UPACustomerAccessAg
<> UPAAirportInfoDeskAg
<> 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, Gómez-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 metamodels 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 architecture 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 Agent Cognitive Agent
Management KnowledgePProcessor rocessor
MangementIntfCognitive Agent
+ IinitIInterfaces()
Decission Rules
D omain
UseControlInterfaceCognitiveAg UseControlInterfaceCognitiveAg ( from Knowledge Processor )
PerceptiontIntfCognitive Agent
Perception Perception
Objectives O bjetives
insertBelieve +insertBelieve () () 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 agent’s internal structure is formed by the necessary subsystems to perform the perception-assimilation-control-act cycle. These subsystems are defined as internal components encapsulating an agent’s specific functionality and communicating 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, Gómez-Sanz & Massonet
Figure 14. Agent goal decomposition into tasks AllowUserDefineFlightNotificationG <<satisfy>>
CreateVisualResourcesNotificationDefinitionG
GatherNotificationDataAndValidateG
<<satisfy>>
<<satisfy>>
<<satisfy>>
CreateNotificationDefinition WindowWithCorrectionT
<<produce>>
<<produce>> Notification CreateNewNo Created tificationT
CreateNotificationD efinitionWindowT
ValidateNotific ationDataT
<<produce>>
NotificationWin dowCreated
NotificationVali dationFailed
NotificationVAlida 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
+ Start() + Stop() + End() + Continue() + Monitoring()
ResourceUse ResourceUserInterface
Resource
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 application performing end-to-end coordination within a customer service business process.
The UPA4T case study was carried through to design and to different partial implementations. MESSAGE’s agent-centred concepts proved to be a sufficiently complete set of construction primitives for the case study problems. Using the views of the system as building patterns helps developers obtain a complete specification of the MAS. The case studies confirmed that the methodology supports the analysis and design of multi-agent systems that are autonomous and can be deployed in a dynamic and heterogeneous environment. MESSAGE has been the basis for new proposals, such as INGENIAS (Pavón & Gómez-Sanz, 2003), which refines the different MESSAGE meta-models and adds more tool support, and RT-MESSAGE (Julian & Botti, 2004), which adds extensions to deal with real-time constraints.
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, Gómez-Sanz & Massonet
Further experience in Telefonica I+D applying MESSAGE to develop telephonybased 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 Organization 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 MESSAGE 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. However, the precise ways in which a published service can be changed during the MAS’s lifetime depend on the specifics of each agent toolkit.
•
Agents can change the way they provide a service. This is modelled by separating the description of the service from the way it is implemented in terms of tasks. The service could be provided in different ways using an inference engine that optimizes certain criteria. If it has been designed to do so, an agent could even cooperate with other agents to help them provide the service that was previously provided alone during the lifetime of the system.
•
Agents communicate in an environment with information heterogeneity. This is handled by a shared ontology for the MAS. This shared ontology is derived from the domain model that was captured during analysis. Agents then communicate using the common ontology to which the internal heterogeneous information of the different agents can be mapped.
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 multiagent 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 metaassociations). 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, Gómez-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 agentoriented 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 negotiations 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 organizations and were assigned all the organization’s roles in the multi-agent application. Services could then be implemented in terms of tasks that were decomposed into direct actions on the agent’s internal representation of the environment, plus communicative actions to send and receive messages in inter-action protocols. The interactions between roles identified in analysis were detailed in terms of interaction protocols. The design description is an implementation-independent conceptual description of the system. Organization-driven detailed design helps developers to define the computational behaviour of the overall system by stepwise refinement. The refinement process is agent centred. The organization model facilitates component-based development 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 component-ware technology, and supporting tools is assured; and (3) developers unfamiliar with agent concepts and notations may choose agent-based components 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, Gómez-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., Müller, J. P., & Odell, J. (2001). Agent UML: A formalism for specifying multiagent interaction. International Journal of Software Engineering and Knowledge Engineering (IJSEKE), 11(3), 207-230. Bellifemine, F., Poggi, A., & Rimassa, G. (2001). JADE: A FIPA2000 compliant agent development environment. In Proceedings of the Fifth International 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). Agentoriented analysis using MESSAGE/UML. LNCS 2222, Berlin: SpringerVerlag. 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 requirements acquisition. Science of Computer Programming, 20, 3-50. Demazeau, Y. (2001). La méthode VOYELLES, dans Systèmes Multi-Agents: Des Théories Organisationnelles aux Applications Industrielles. Oslo, Norway: Hermès. Do, T. T., Kolp, M., Hoang, T. T. H., & Pirotte, A. (2003). A Framework for Design Patterns for Tropos. Paper presented at the Proceedings of the 17th Brazilian Symposium on Software Engineering (SBES 2003), Maunas, Brazil, October. EURESCOM P907. (2003). Methodology for agent-oriented software engineering (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. Gómez-Sanz, J. J., Pavón, J., & Massonet, P. (2001). Multi-agent system organization. An engineering perspective. Paper presented at the Modelling Autonomous Agents in a Multi-Agent World, Annecy, France, May. Garijo, F., Tous, J., Matias, J. M., Corley, S., & Tesselaar, M. (1998). Development of a multi-agent system for cooperative work with network negotiation capabilities. In S. Albayrak (Ed.), Intelligent agents for telecommunication applications, LNCS, (Vol. 1437, pp. 204-219). Berlin: SpringerVerlag. 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 Proceedings 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: AddisonWesley. 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. 2734). 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, Gómez-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/P900series/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.), Agentoriented software engineering. Proceedings of the First International Workshop (AOSE 2000). LNAI, (Vol. 1957, pp. 121-140). Berlin: SpringerVerlag. OMG. (2000). MOF. Meta Object Facility (specification) (No. V.1.4. formal). 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 Engineering, LNCS, Vol. 1957 (pp. 185-193). Berlin: Springer-Verlag. Pavón, J. & Gómez-Sanz, J. (2003). Agent-oriented software engineering with INGENIAS. Proceedings of the International Central and Eastern European Conference on Multi-Agent Systems (CEEMA ’03), Prague, Czech Republic (LNCS, Vol. 2691, pp. 394-304). Springer-Verlag. Szyperski, C. (1997). Beyond object-oriented programming. Reading, MA: Addison-Wesley. Walshe, D., Kennedy, J., Corley, S., Koudouridis, G., F. Van Laenen, Ouzounis, V., et al. (2000). An interoperable architecture for agent-oriented workflow management. Proceedings of the International Conference on Artificial Intelligence (IC-AI 2000), Monte Carlo Resort, Las Vegas. CSREAPress. 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 Pavón, Gómez-Sanz & Fuentes
Chapter IX
The INGENIAS Methodology and Tools Juan Pavón Universidad Complutense de Madrid, Spain Jorge J. Gómez-Sanz Universidad Complutense de Madrid, Spain Rubén Fuentes Universidad Complutense de Madrid, Spain
Abstract INGENIAS provides a notation for modeling multi-agent systems (MAS) and a well-defined collection of activities to guide the development process of an MAS in the tasks of analysis, design, verification, and code generation, supported by an integrated set of tools—the INGENIAS Development Kit (IDK). These tools, as well as the INGENIAS notation, are based on five meta-models that define the different views and concepts from which a multi-agent system can be described. Using meta-models has the advantage of flexibility for evolving the methodology and adopting changes to the notation. In fact, one of the purposes in the conception of this methodology is to integrate progressive advances in agent technology, towards a standard for agent-based systems modeling that could facilitate the adoption of the agent approach by the software industry. The chapter presents a summary of the INGENIAS notation, development process, and support tools. The use of INGENIAS is demonstrated in an e-business case study. This case study includes concerns about the development process, modeling with agent concepts, and implementation with automated code generation facilities. 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 Proceedings 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 notations, 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 (relationships with other entities and related attributes). The final result is a view of the system under development that is compliant with the meta-model. This section presents a simplified version of these meta-models by showing the entities with their graphical representation and their relationships informally, in order to make figures easier to understand. Readers interested in the meta-model specification can download it from the INGENIAS site at http://ingenias.sourceforge.net. The meta-models that we defined are the result of experience gained in several projects, each one validated with the development of an agent-based application: MESSAGE (Caire et al., 2001) defined the general framework for MAS specification and the initial identification of five viewpoints; Communications Management Process Integration Using Software Agents (Gomez-Sanz, Garijo, & Pavón, 2000) tested the application of BDI architecture for agent behaviour; and Personalized Services for Integrated Internet Information (Gómez-Sanz, Pavón, & Díaz-Carrasco, 2003) made insights in the organization and scalability issues of MAS. Also, we have extensively used the viewpoints specification to build tools that support the development activities—more
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 metamodeling techniques applied to the development process and to the specification method. The goal is to finish with a set of agreed-upon concepts and MASbuilding 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 community, 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. Consequently, this is not just a personal view of MAS-building but an integrative approach.
•
There is a detailed and experimented development process. A development 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 Pavón, Gómez-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 implementation. 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 viewpoints 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 Pavón, Gómez-Sanz & Fuentes
specifically, graphical model editors, documentation generation, and code generation 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 decomposition 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
plays Agent
Role
decomposes
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 Agent
Role
Resource Interaction
Workflows define associations among tasks and general information about their execution (Figure 2). For instance, for each task, a workflow defines its results, the agent or role responsible for its execution, and the resources that are required. This is useful to gain knowledge on the relationships between agents through tasks, and the assignment and availability of resources in an organization. Social relationships can be established at different levels—between organizations, 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 organization.
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 Pavón, Gómez-Sanz & Fuentes
Figure 3. Elements of the agent viewpoint
plays
pursues
Role
Agent
Goal has
Concrete Agent
Fact
Mental State
has
responsible
M P
task
modifies 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 Fact A F
Postconditions consumes Task
produces
Fact B consumes
Fact C F
F uses
Application <<Environment>> - method
Application <> - method
uses
produces Modifies/affects
Resource
goal Interaction
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 Pavón, Gómez-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
WORKFLOWS
Inception
A N A L Y S I S
D E S I G N
Generate use cases and identify their actors Sketch a system architecture with an organization model. Generate enviroment models to represent results from requirement gathering stage
Generate prototypes perhaps with rapid application development tool such as ZEUS or Agent Tool or code generators from the IDK. Sometimes this prototyping limits to concrete aspects and uses a more conventional technology
Elaboration Refined use cases and interactions associated to them Agent models that detail elements of the system architecture. Workflows and tasks in organization models Models of tasks and goals to highlight control constraints (main goals, goal decomposition) Refinements of environment model to include new environment elements Refinements in workflows Interaction models that show how tasks are executed. Models of tasks and goals that reflect dependencies and needs identified in workflows and how system goals are achieved Agent models to show required mental state patterns
Construction Refinements on existing models to cover use cases
Generate new models Social relationships that regulate organizational behavior
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 Pavón, Gómez-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). Commonalities 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 specialized 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 Spec
Agent
UML Collaboration diagram
AUML Protocol diagram
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
Agent
Speech act
Interaction unit Colaborates
Role
Colaborates
Initiates
Speech act
Agent
Iterates Interaction unit
Role Precedes
Interaction unit
Precedes
Precedes Speech act
Interaction unit
Interaction unit
Speech act
such as Agent UML (http://www.auml.org) protocol diagrams, UML collaboration 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 Pavón, Gómez-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 Is assigned
Is assigned
Application
Application
<<Environment>>
<>
- method
- method
Is assigned
Resource
Application
Perceives environment through
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. Implementation 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 generation 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 Pavón, Gómez-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 specification. 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 architecture, is later refined in the analysis-elaboration phase to identify the goals of the organization and relevant tasks with respect to these goals, to be performed by each agent in the organization. Task execution has to be justified in terms of organizational goals or an agent’s goals (with task-goal models). This leads to identifying the results needed to consider a goal as being satisfied or not. In the design-elaboration phase, more detail is added by defining workflows between the different agents (with organization models), completing workflow definition with agent interactions (with interaction models), and refining the agent’s mental state as a consequence (with agent models). According to the USDP, the goal of the elaboration phase is to generate a stable architecture. This architecture arises from the study, during the elaboration phase, of a subset of initial use cases. Remaining use cases, which are supposed to deal with special situations but do not provide changes in the system architecture, are left to the construction phase. Design-Inception has no activity-based assistance. According to Figure 8, it deals with technology issues related to the feasibility of the development. It is hard to establish what to test or what to prototype. In our experience, it is better to focus on concrete aspects, communications, and user interaction in our case
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 Pavón, Gómez-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, Gómez, & Pavón, 2003); only verification is included in the standard IDK distribution. In general, any module can provide verification capabilities if a developer follows the basic instructions for module construction. Modules have to traverse a specification looking for elements indicated in the templates used. If these elements do not appear, or appear differently from the way the template requires, then the module should stop and produce error messages. These error messages should indicate what error triggered it and suggest some solution, such as adding specific information, defining responsibilities for agents, or removing some elements, like duplicated tasks. The experience, when following guidelines for module construction, is that modules support the developer in completing the specification. Validation and Verification results with Activity Theory (AT) (Leontiev, 1978) establish the suitability of social theories to study MASs. AT is a framework for the study of human societies that considers all labor as simultaneously individual and social. The social component includes the actual society in which a subject carries out the activity and also the historical development of those activities. Evolution is the result of changes introduced by organizations in their activities to solve contradictions. A contradiction in AT is a tension between elements in the activity and can be caused by several reasons, such as different objectives, ways of use, or needs. AT helps in requirements elicitation (Fuentes, Gómez-Sanz, & Pavón, 2004) and the analysis of contradictions ( Fuentes, Gómez-Sanz, & Pavón, 2003). In both cases, the idea is to use UML-based representations of AT concepts to represent contradiction patterns and requirements. These techniques are currently being tested within this methodology, incorporating these concepts into the INGENIAS process in future releases.
Support Tools The INGENIAS Development Kit (IDK) is a set of tools that supports the development process in INGENIAS. The IDK offers two kind of tools: a visual editor and modules. The visual editor works as a modeling tool (Figure 11) that 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 Pavón, Gómez-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 perform appropriate modificationsif not
End
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 preexisting 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 feedback: 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.
3.
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 specification (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 instance, a number was expected and a string was found).
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 metamodels 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 Pavón, Gómez-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 straightforward. 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 Pavón, Gómez-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 analysisinception 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 analysisinception stage Activity Identify groups (1.a) Generate members (1.b) Identify goals (2c)
Result A set of groups Elements that constitute groups 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 software—usually non-agent based software—identifying this software in the first place is recommended. By using environment models, the developer can consider dependencies with legacy and proprietary software from the beginning. We tend to include elements like application servers or databases, which are very common in today’s developments. Once these elements have been identified, the developer can determine how the agent’s perception can be defined in terms of these applications and what functionality these applications can provide.
•
Interaction. Researchers used to the object-oriented paradigm may prefer to use interactions and use cases. Interactions in this approach are similar to those in UML, but they include direct associations with tasks and agent mental states, so these interactions can enable further refinements with agent views or tasks and goal views.
•
Organization. The organization of an MAS defines its system architecture. 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 organization. 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 Pavón, Gómez-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 Møller Bokhandel A/S described by Anderson (1997), because it deals with some interesting agent features and applications, such as supply chain management, negotiation, workflows, enterprise modelling, and user modelling. It describes a bookshop that sells books to university students. The company has an agreement with professors and students to obtain a list of books used in their courses and sell them at special prices. The bookseller is considered as an organization in which there are departments in charge of sales and departments in charge of logistics. This organization has to negotiate with other organizations and publishers to acquire books at the best prices and within specific timing constraints. It can also negotiate for special arrangements for certain books that are needed for specific courses. Sales can be conventional or through the Internet. In this case study, the goal is to define an electronic sales system. Figure 16 shows a first approach to the organization of the bookshop. The Juul Møller Bokhandel A/S bookshop (from now on, the Juul bookstore) is modelled initially as two departments: Logistics and ESales. The first is responsible for delivering goods to customers and receiving books from publishers. The second is responsible 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 development 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 construction 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 Pavón, Gómez-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 Pavón, Gómez-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 Pavón, Gómez-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 amongs goals (5).
Dependency relationships among goals
Associate tasks and interactions(6.a)
Instances of WFProduce connecting task and Interaction entities
Relate tasks with its products (6.c) and inputs (6.b)
Instances of WFProduce and WFConsume
Associate tasks and applications (6.d).
Instances of WFUse 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 Pavón, Gómez-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 Pavón, Gómez-Sanz & Fuentes
Figure 26. JADE-based agent architecture. It reuses JADE behaviours to implement protocols. Agent (from co...
SimpleBehavior (from behaviors)
AddNewConv ersation
creates manages
StateBehavior
sends a message with
0.. *
0..* SyncSender
modifies current state
JADEAgent (from jade)
receives a message with
creates
RemoveFinished Conversations
Cyc licBehavior (from behaviors)
creates
SyncRe ceiver
DetectNotProcess edMessages
modifies current state <> 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 management 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 designinception 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 components, 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 Pavón, Gómez-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 agentbased 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 Pavón, Gómez-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 modulebased verification and assists the user in the diagram construction activities. 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 diagrams, INGENIAS already defines a set of rules that follow the pattern “if an element of type X appears in the diagram of type Y, then it also has to appear in some diagrams of type W and Z.” These rules are defined in the original thesis work by Gómez-Sanz (2002). At present, the set of rules is verified manually by developers during the development process, but work is being done to make this automatic. INGENIAS is also applying automated consistency checking using models defined with Activity Theory (R. Fuentes et al., 2003). Activity Theory is useful because the behaviour of agents is defined in similar terms to human and social behaviour.
Acknowledgments This work has been supported by the Spanish Council of Science and Technology (TIC2002-04516-C03-03).
References Andersen, E. (2001). Juul Moller Bokhandel A/S. Retrieved April 1, 2005, from Espen Andersen Web site http://www.espen.com/papers/index.html 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: SpringerVerlag. DeLoach, S. (2001). Analysis and design using MaSE and agentTool. In Proceedings of the 12th Midwest Artificial Intelligence and Cognitive Science Conference (MAICS 2001), Miami University, Oxford, Ohio, March. Demazeau, Y. (2001). La méthode VOYELLES, dans Systèmes Multi-Agents. Des Théories Organisationnelles aux Applications Industrielles. Oslo, Norway: Hermès. FIPA. (2001). FIPA ACL message structure specification (No. 00061 standard). Retrieved April 1, 2005, from FIPA Web site http://www.fipa.org/ specs/fipa00061/ Fuentes, R., Gómez-Sanz, J. J., & Pavón, J. (2003). Activity theory for the analysis and design of multi-agent systems. In Proceedings of the Fourth International Workshop on Agent Oriented Software Engineering (AOSE 2003), Lecture Notes in Computer Science 2935 (pp. 110-122). Berlin: Springer-Verlag. Fuentes, R., Gómez-Sanz, J. J., & Pavón, J. (2004). Towards requirements elicitation in multi-agent systems. In Proceedings of Cybernetics and Systems 2004, the 17th European Meeting on Cybernetics and Systems Research (EMCSR 2004), Vienna, Austria, April (pp. 582-587). Austrian Society for Cybernetic Studies. Gomez-Sanz, J. J. (2002). Modelado de Sistemas Multi-Agente. PhD thesis, Universidad Complutense de Madrid, Madrid. Gomez-Sanz, J. J., Garijo, F., & Pavón, J. (2000). Intelligent interface agents behaviour modelling. In Proceedings of the Mexican International Conference on Artificial Intelligence (MICAI 2000), Acapulco, Mexico, April, (LNAI 1793, pp. 598-609). Berlin: Springer-Verlag. Gómez-Sanz, J., Pavón, J., & Díaz-Carrasco, A. (2003). The PSI3 agent recommender system. In Proceedings of the International Conference on Web Engineering, ICWE 2003, LNCS 2722 (pp. 30-39). Berlin: Springer-Verlag. Huhns, M. N. & Stephens, L. M. (2000). Multiagent systems and societies of agents. In G. Weiss (Ed.), Multiagent systems (pp. 79-120). Cambridge, MA: MIT Press. Iglesias, C., Mercedes Garijo, M., Gonzalez, J. C., & Velasco, J. R. (1998). Analysis and design of multiagent systems using MAS-CommonKADS. In 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 Pavón, Gómez-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 multiuser and multi-tool CASE and CAME Environment. In P. Constantopoulos, J. Mylopoulos & Y. Vassiliou (Eds.), Proceedings of the 8th International 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 Intelligence Journal, 1(13), 129-185. OMG. (2000). Meta Object Facility (MOF)(specification) (No. V.1.3. formal). 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 agentbased 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 BeliefDesire-Intention (BDI) model (Rao & Georgeff, 1991). Following the logicbased 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 secondary. 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 between 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 (wellstructured) 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/) approach of the Object Management Group (OMG) where modelling is identified as the core of state-of-the-art software engineering that is scientifically wellfounded. 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 agent’s mental state, comprising the modelling of agent types, their internal and external object types, action and non-action event types, and commitment/claim types. Additionally, AORML introduces reaction rules as its most important behaviour modelling element. The RAP/AOR viewpoint modelling framework enables viewing and modelling a problem domain from the interaction, information, and behaviour viewpoint aspects. Different kinds of models/diagrams are used for modelling from different aspects, such as agent diagrams and interaction-frame diagrams of AORML and use-case diagrams of UML from the interaction aspect, agent diagrams from the information aspect, and goal-based use-case models, interaction-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 (firstperson) 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 proposed 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 modelling of organizations and organizational information systems, called AOR modelling, 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 fundamental association, aggregation, and generalization relationship types of EntityRelationship (ER) and UML class modelling. Business processes are viewed as social interaction processes emerging from the behaviour of the participating agents. In the proposed approach, behaviour is primarily modelled by means of interaction patterns expressed in the form of reaction rules that are visualized in interaction pattern diagrams. Taveter (2004a) proposes an integrated business modelling technique—the Business Agents’ Approach—that is based on AOR modelling. Taveter (2004a) emphasizes that in addition to being a technological building block, an agent is an important modelling abstraction that can be used at different logical levels in the creation and development of an information system. The Business Agents’ Approach suggests an elaboration of the existing business modelling frameworks – six perspectives of agent-oriented business modelling for distributed domains. These perspectives are the organizational, informational, interactional, functional, motivational, and behavioural perspective. The Business Agents’ Approach 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 communicative 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: designated 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 communicating 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 (from UFO-A)
{disjoint}
Non-Agentive Object *
inheres in
MentalMoment
1
*
creates Physical Agent
! bears *
2..*
Communicative ActionEvent
*
Message *
1
* Communicating PhysicalAgent {disjoint}
Commitment
*
1..*
Perception
SocialMoment
Non-Action Event
ActionEvent
{disjoint} Belief
Event (from UFO-B)
perceives
{disjoint} Intrinsic Moment
*
Institutional Agent
Sender
1
Communicating Agent *
Receiver 1..*
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 (firstperson) 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 <> 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
External Object Type
Commitment/Claim Type
Message Type
Agent Type receives
Internal Object Type
does
Non-Communicative Action Event Type
perceives Action Event Type perceives
Non-Action 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 communicative 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 commitments) and one for specifying the performance of (physical and communicative) actions. An outgoing arrow with a double arrowhead denotes a mental effect. An outgoing connector to an action event type denotes the performance of an action of that type. As an example, Figure 4 shows an interaction pattern diagram that specifies the reaction rule R1 for a Seller’s behaviour in response to perceiving a communicative action event of the type request PurchaseOrder. Both the mental state condition and mental effect of the reaction rule are presented as expressions 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 corresponding status predicate isAvailable and the OCL expression productID = globalProductIdentifier. The post-condition representing the mental effect is expressed as inventory = inventory@pre - requestedQuantity. The post-condition affects the representation of the corresponding ProductItem in the Seller’s internal database by decreasing its attribute inventory by the value of the attribute requestedQuantity of the message received.
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 relationship 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 Corporation, 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 commitments, 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 request PurchaseOrder
R1
globalProductIdentifier requestedQuantity
inventory = inventory@ pre requestedQuantity productID = globalProductIdentifier
provideProduct (PurchaseOrder)
Product Item
action mental effect
RR
outgoing message triggering event mental state condition
productID inventory isAvailable
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 wellaligned 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: computationindependent modelling (CIM), platform-independent modelling (PIM), and platform-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 frameworks 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 Abstraction level Conceptual Domain Modelling PlatformIndependent Computational Design Platform-Specific Implementation
Viewpoint aspect Interaction Information AOR Agent Diagrams, UML Use AOR Agent Case Diagrams, AOR Interaction Diagrams Frame Diagrams, AOR Interaction Sequence Diagrams UML Use Case Diagrams, AOR AOR Agent Reaction Frame Diagrams, User Diagrams Interface Design Models, Security Models, UML Class Diagrams, UML Interaction Diagrams UML Class UML Deployment Diagrams Diagrams
Behaviour AOR Interaction Pattern Diagrams, Goal-Based Use Case Models, AOR Activity Diagrams AOR Reaction Pattern Diagrams, AOR Internal Activity Diagrams, UML State Machine Diagrams UML Class Diagrams
Table 2. RAP/AOR stakeholders and the corresponding viewpoint names in other frameworks Abstraction level Conceptual Domain Modelling Computational Design Implementation
Audience/Stakeholders owners/customers, users, domain experts systems analysts, software architects programmers, database implementers, system integrators
MDA CIM PIM PSM
Viewpoint Names RM-ODP Zachman Enterprise Rows 1+2 Information + Computational Engineering + Technology
Row 3 Rows 4+5
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 documents 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 purposes 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 relationships identify agents with shared interests. Dependency relationships exist between agents because of resource restrictions where the depender depends on the dependee for the availability of a physical or an informational resource. For example, in Figure 5 there is the isBenevolentTo relationship between instances of the role types Seller and Buyer. The domain-interaction viewpoint is described with the help of four views: 1.
AOR Agent Diagrams;
2.
UML Use Case Diagrams;
3.
AOR Interaction Frame Diagrams; and
4.
AOR Interaction Sequence Diagrams.
Types of organizational units and roles can be represented by AOR agent diagrams where different agent types may relate to each other through the relationships of generalization and aggregation. An AOR agent diagram depicts the agents and agent types of a problem domain, together with their internal agents and agent types and the relationships among them. An agent diagram, like the one shown in Figure 5, includes all agent (role) types of a business domain. An important purpose of an agent diagram is to describe all stakeholders that are involved in the business processes to be supported by the socio-technical business system and to give an overview of the business system viewed as a multi-agent system. A use case is defined as the specification of a sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system (OMG, 2003b). Since the system is itself an actor 4 (Cockburn, 1997a), the model of interaction between an “actor” and a “system” of a use case can also be applied in agent-oriented modelling. A UML use-case diagram, for example, the diagram represented in Figure 6, thus shows the relationships Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
1
totalLineItemAmount
1 InvoiceLineItem
0..* billToAccount globalPaymentTermsCode totalInvoiceAmount
Invoice
<>
0..*
1
1
Product Item
Software Agent 1
0..*
QuoteLineItem StatusCode
globalProductSubstitutionReasonCode globalProductIdentifier
Substitute ProductReference
isSubstituteProductAcceptable requestedQuantity globalProductUnitOfMeasureCode globalProductIdentifier unitPrice
QuoteLineItem
isPending
isPending
isNoBid
0..*
0..*
ProductItem OfSeller
1
Seller
Software Agent
0..*
requestedResponseDate
RFQ/Quote
isReject
1
Clerk
Seller
isBid
1
0..*
Clerk
1
isAccept
ProductLineItem StatusCode
globalProductSubstitutionReasonCode globalProductIdentifier
Substitute ProductReference
requestedQuantity requestedUnitPrice globalProductUnitOfMeasureCode globalProductIdentifier shippedQuantity unitPrice
ProductLineItem
PurchaseOrder/Confirmation
Buyer
Towards Radical Agent-Oriented Software Engineering Processes 291
Figure 5. The agent diagram of the domain of business-to-business electronic commerce
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
292 Taveter & Wagner
Figure 6. A use case diagram showing the types of interactions between agents of the types Buyer and Seller
Seller Quote
Order
Buyer
Pay
Figure 7. The interaction frame between agents of the types Buyer and Seller Buyer
Seller request RFQ/Quote
inform RFQ/Quote request PurchaseOrder/ Confirmation inform PurchaseOrder/ Confirmation provideProduct (PurchaseOrder) provideProduct (PurchaseOrder)
request Invoice
payForProduct (Invoice) payForProduct (Invoice)
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
293
among two actors which are respectively an initiator and a responder in interactions. The use cases represented in the domain interaction viewpoint are business use cases (Cockburn, 2001), because they summarize the types of interactions between a customer, which can be a human agent or an institutional agent, and the business, which is an institutional agent. According to Wagner (2003a), an AOR interaction-frame diagram provides a static picture of the possible interactions between two (types of) agents without modelling any specific process instance. An interaction-frame diagram describes in more detail the types of interactions summarized by the corresponding use case. An interaction-frame diagram, like the one represented in Figure 7, consists of various types of communicative action events, non-communicative action events, commitments/claims (coupled with the corresponding types of action events), and non-action events. Agents of the problem domain share the entity types mentioned. An AOR interaction-sequence diagram, like the one shown in Figure 8, depicts (some part of) a prototypical instance of an interaction process. An interaction Figure 8. An interaction sequence between the agent instances BuyerA and SellerB BuyerA
SellerB request RFQ/Quote
1
globalProductIdentifier = "1247" 2 inform RFQ/Quote request PurchaseOrder/ Confirmation 4
3
inform PurchaseOrder/ Confirmation
5 provideProduct (PurchaseOrder) 6 request Invoice 7 payForProduct (Invoice)
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
294 Taveter & Wagner
process is a sequence of action events and non-action events, performed and perceived by agents and following a set of rules (or protocol) that specifies the type of the interaction process. Agents may interact with their inanimate environment or they may interact with each other.
Domain-Information Viewpoint Representing the domain-information viewpoint (Column 2 in Table 1) for the focus organization(s) can be regarded as creating a domain ontology that provides a common framework of knowledge for the agents of the organization(s) and external agents connected to the organization(s). Each agent of the problem domain can see only a part of the ontology; that is, each agent views the ontology from a specific perspective. The domain-information viewpoint is described with the help of one view—AOR Agent Diagrams. In addition to describing agent types, an AOR agent diagram, like the one represented in Figure 5, describes object types of the problem domain, as well as their relationships to agent types and with each other. Each agent has beliefs about its internal agents, about its “private” objects, and about all external agents and shared objects that are related to it.
Domain-Behaviour Viewpoint The domain-behaviour viewpoint (Column 3 in Table 1) addresses the modelling of an agent’s functionality (what functions the agent has to perform), as well as of the agent’s behaviour (when, how, and under what conditions work has to be done). In the models of the domain-behaviour viewpoint, a modeller may abstract away from particular internal agent types, like SoftwareAgent in Figure 5, and create models of behaviour for the corresponding institutional agent types, like Buyer and Seller in Figure 5. The domain-behaviour viewpoint is described with the help of three views: 1.
AOR Interaction-Pattern Diagrams;
2.
Goal-Based Use Case Models; and
3.
AOR Activity Diagrams.
AOR interaction-pattern diagrams, like the one depicted in Figure 4, focus on general interaction patterns expressed by means of a set of reaction rules defining an interaction process type. In an interaction-pattern diagram, the 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
295
actions performed by one agent may be, at the same time, the events perceived by another agent. Figure 4 demonstrates that an interaction-pattern diagram can visualize the reaction chains that arise by one reaction triggering another. However, for adequate modelling of business processes, interaction-pattern diagrams are not sufficient because they do not allow modelling of action sequences. For this reason, we will introduce activities as a glue to connect the actions of an agent within a business process to each other. Actor types (or agent role types) are always characterized by goals because, as noted by Kueng and Kawalek (1997, p. 19), “human activity is inherently purposeful.” In a business domain, a human or an institutional agent acting in the role of a “customer” has a goal of having something accomplished. To achieve its goal, the agent uses some service provided by another agent. An agent’s autonomy implied by a benevolence relationship between the service provider and a service requester means that the service provider performs the service requested if it is able to do so, but the service provider also has an option to refuse the service request. Even though the agent requesting the service may not explicitly communicate its goals to the service provider agent, the latter always “internalizes” the whole or a part of the customer’s goal in an attempt to provide the service. For example, assuming that a customer has a goal of renting a car, the goal of a car rental company is to provide the customer with a car, which is, of course, a subgoal of the company’s higher level goal—to earn money through renting cars. The car rental company tries to achieve this higher level goal by “internalizing” as many customer goals as possible. The “internalizations” of the goals of customers by service providers can be modelled in different ways. For example, in the i* framework proposed by Yu (1995), a customer’s goal can be captured by representing a goal dependency where a depender (i.e., a customer) depends on the dependee (i.e., a service provider) to bring about a certain state in the world. In the same framework, setting and achieving of the corresponding internal goal by the dependee can be modelled through a means-ends link, indicating a relationship between an internal goal to be achieved and a means for attaining it, which is usually performing a task (activity). As another example, in the KAOS framework described by Lamsweerde (2003), goals of agents are “operationalized” into specifications of services to be performed by an agent. In our approach, we capture the goals of “customers” and their “internalizations” by service providers by employing goal-based use case models. Use cases as such were originally introduced by Jacobson (1992). Cockburn (1997a, 1997b) proposed an extended version of use cases that he calls “use cases with goals.” He elaborated goal-based use cases in Cockburn (2001). While a graphical UML use-case diagram in the domain-interaction viewpoint summarizes types of interactions between an external actor and the focus agent (the “system”), a tabular goal-based use case models the behaviour of the focus agent. Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
296 Taveter & Wagner
Table 3. A goal-based use case for the business process type “Process the request for a quote” USE CASE 1 Goal of the Primary Actor Goal of the Focus Actor Scope & Level Success End Condition Primary Actor Secondary Actors Triggering event DESCRIPTION
Process the request for a quote. To receive from the seller the quote. To provide the buyer with the quote. Seller, primary task. The buyer has received from the seller the quote. Buyer. A request for a quote by the buyer. Step Action 1 Check and register the availability of the product items included in the request for a quote. 2 Send the quote to the buyer.
A goal-based use case, such as the use case represented in Table 3, consists of a primary actor, the system under discussion, and a secondary actor. We will call the system under discussion the actor in focus. In the domain-behaviour viewpoint, where use cases describe the types of an organization’s business processes, the actor in focus is the organization itself or an organization unit. According to Cockburn (2001), the external primary actors are the actors whose goals the organization is to satisfy. They include the company’s customers and perhaps their suppliers. The external primary actors form a part of the company’s stakeholders that includes the company shareholders, customers, vendors, and government regulatory agencies. A secondary or a supporting actor is an external actor that provides a service to the agent in focus, so that the latter could achieve its goals. In parallel with the identification of primary actors, the triggering events created by them to which the organization must respond should be identified (Cockburn, 2001). Internal and external actors in goal-based use cases straightforwardly correspond to internal and external agents in AOR modelling. According to Cockburn (1997a), each actor has a set of responsibilities that have been assigned to it by external authorities. To carry out those responsibilities, it sets some goals. An agent’s responsibility is realized as an activity that the agent performs in response to perceiving an event of the corresponding type. The relationship between an agent’s responsibilities, goals, and activities is illustrated by the RAP/AOR metamodel fragment shown in Figure 9. An activity is defined using workflow terminology as an uninterruptible amount of work that is performed in a non-zero span of time by an actor (Eshuis, Jansen,
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
297
Figure 9. The relationship between an agent’s responsibilities, goals and activities
Event 1..*
1
0..* 1
Agent 1
2
triggers>
includes>
1
Reaction Rule
has>
1
has>
0..*
0..*
1 1
starts>
0..1
Activity
0..* 1
has>
1
1
Agent Goal
0..* 1
Responsibility 1
& Wieringa, 2002). Each activity belongs to some activity type. An activity type (or task in Yu [1995]), like “Manage quoting,” is defined as a prototypical job function in an organization that specifies a particular way of doing something (Yu, 1995). It seems natural to allow specifying the start of an activity in the action part of a reaction rule. In other words, an instance of an activity type is created by means of a reaction rule in response to perceiving an event, which is also reflected by the RAP/AOR metamodel fragment represented in Figure 9. We define an AOR activity diagram, like the one shown in Figure 10, by making the definition provided in UML 2.0 (OMG, 2003b) slightly more precise as a
Figure 10. An incomplete model of the quoting business process type from the perspective of Seller Buyer
Seller
request RFQ/Quote
R1
Manage quoting (q : Quote)
Process product item s (q : Quote)
inform RFQ/Quote
q.quoteLineItem .forAll-> (quoteLineItem StatusC ode.isBid or quoteLineItem StatusCode.isNoBid)
Confirm quote (q : Quote)
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
298 Taveter & Wagner
specification of parameterized behaviour that is expressed as a flow of execution via a sequencing of subordinate activities whose primitive elements are individual epistemic, physical, and communicative actions. As Figure 9 reflects, there are two activity border events (start-of-activity and end-of-activity) implicitly associated with the beginning and end of each activity. An activity border event starts either a subactivity or a subsequent activity or triggers a reaction rule. The start-of-activity event type is graphically represented by an empty circle with the outgoing arrow to the symbol of the subactivity type or internal reaction rule. The end-of-activity event type is visualized by drawing a triggering arrow from the activity-type symbol to either the symbol of the next activity type or to the symbol of the reaction rule triggered by an activity of the corresponding type. The goal tied to an activity is defined as a condition or state of affairs in the world that the agent would like to achieve (Yu, 1995). When a goal-based use case is transformed into an activity diagram, the goal of the focus actor of the use case is attached to the diagram’s outermost activity. The pre-condition of an activity is a necessary condition that must be true when the activity is started. Preconditions and goals may refer to status or intensional predicates of entity types. They are defined for activity types by means of OCL.
Viewpoints of Design As explained in section “The AOR Modelling Language,” an interacting system (or agent), as a subject in its domain, does not have an objective but rather a subjective view of the domain. This is reflected in RAP/AOR by a computational-design model, in which the internal (subjective) perspective of the system to be built is adopted, in contrast to the external (objective) perspective adopted in a conceptual domain model. For instance, in the transformation of a domaininformation model into an information-design model for a specific agent, the objective term action event is mapped onto the two indexical subjective terms, action (if performed by the agent under consideration) and event (if performed by other agents). Likewise, the objective term message is mapped onto the two subjective terms, incoming message and outgoing message. This mapping is also called internalization in RAP/AOR. External models of the conceptual domain modelling level are thus transformed into internal models of the level of platform-independent computational design. In particular, AOR agent diagrams are refined into more detailed agent diagrams and business use cases are turned to system use cases. Analogously, AOR interaction-frame diagrams are mapped to reaction-frame diagrams, AOR interaction-pattern diagrams to reaction-pattern diagrams, and AOR activity diagrams to internal activity diagrams.
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
299
The Role of Simulation in the RAP/AOR Methodology We have shown in Wagner and Tulba (2003) that, with some minor extensions, AOR models can be used for a certain form of agent-based discrete event simulation called Agent-Object-Relationship Simulation (AORS). In RAP/ AOR, we employ AORS for achieving more agility in the software engineering process by getting feedback from the execution of models before they are implemented in a target technology platform. AORS allows animating and testing both AOR domain-interaction and -behaviour models and AOR interaction and behaviour design models. As has been shown in Taveter (2004a), simulation of behaviour models is facilitated by the executability of complete and incomplete AOR activity diagrams. An AORS system, for example, the implementation described in Luin, Tulba, and Wagner (2004), includes an environment simulator that is responsible for simulating exogenous events and the causality laws of the physical environment. Other actors of the problem domain can be simulated with various degrees of realism.
The Core Disciplines of the RAP/AOR Methodology The seven core software engineering disciplines of RAP/AOR, based on those of RUP, are: 1.
Domain modelling;
2.
Requirements engineering;
3.
Design;
4.
Simulation;
5.
Implementation;
6.
Test; and
7.
Deployment.
The first three disciplines listed above can be represented as the following task sequence divided between different viewpoints: 1.
Domain-interaction viewpoint: 1.1. Model agent types and instances of the problem domain and relationships between them by using an AOR agent 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
300 Taveter & Wagner
1.2. Model possible interaction types between agents of the problem domain by UML use cases. 1.3. Refine possible interaction types between agents of the problem domain by AOR interaction-frame diagrams. 1.4. Model prototypical interaction processes of the problem domain by AOR interaction-sequence diagrams. 2.
Domain-behaviour viewpoint: 2.1. Model the behaviours of agents of the problem domain by goal-based use cases. 2.2. Model the behaviours of agents of the problem domain by AOR reaction-pattern diagrams (optional). 2.3. Transform goal-based use cases into AOR activity diagrams. 2.4. Refine AOR activity diagrams by more detailed behavioural constructs. 2.5. Complement goal-based use cases by the elements corresponding to the behavioural constructs introduced.
3.
Domain information viewpoint: 3.1. Model object types and instances of the problem domain and relationships between them by using an AOR agent diagram.
4.
Design interaction, behaviour, and information viewpoints: 4.1. Turn AOR interaction-frame diagrams into AOR-reaction frame diagrams. 4.2. When needed, complement AOR-reaction frame diagrams with userinterface design models and security models. 4.3. Turn AOR-interaction pattern diagrams into AOR reaction-pattern diagrams (optional). 4.4. Turn AOR activity diagrams into internal AOR activity diagrams. 4.5. Refine AOR agent diagrams of the conceptual domain-modelling level into AOR agent diagrams of the computational-design level.
In large development projects, there will be a team for each of the seven disciplines stated above.
The Phases of a RAP/AOR Development Project Jacobson, et al. (1999) and Kruchten (1999) have pointed out that a software development project has two dimensions: the temporal sequence of project 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
301
Table 4. Project phases with predominant software engineering disciplines Project Phase Inception Elaboration Construction Transition
Predominant Disciplines domain modelling & requirements engineering design & simulation implementation & test deployment
phases, and the composition of the overall development process of analysis, design, simulation, implementation, and test activities carried out iteratively in each phase. In RAP/AOR, we follow the distinction between four project phases: inception, elaboration, construction, and transition, each of which has one or two predominant software engineering disciplines according to Table 4. An important topic of our future work is aligning the phases of the RAP/AOR development project with the Software Process Engineering Metamodel Specification (SPEM, 2002) so that a phase would be a specialization of WorkDefinition such that its precondition defines the phase entry criteria and its goal defines the phase exit criteria.
Case Study Our case study is about the business process type of quoting in business-tobusiness electronic commerce that is based on the RosettaNet standard (http:/ /www.rosettanet.org/). The RosettaNet’s “Request Quote” Partner Interface Process® (PIP) enables a buyer to request a product quote from a provider and a provider to respond with a quote. The prices and product availability reflected in a quote may be influenced by an existing or potential relationship between a buyer and provider. We now discuss the conceptual modelling of this problem domain in terms of the RAP/AOR viewpoint modelling framework. We also briefly address the computational design of a business-to-business process automation system for the problem domain.
The Interaction Aspect At the level of conceptual domain modelling (Row 1 in Table 1), the interaction aspect (Column 1 in Table 1) is captured by conceptual AOR- interaction models that are represented by using the following views: AOR agent diagrams,
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
302 Taveter & Wagner
UML use-case diagrams, AOR interaction-frame diagrams, and AOR interaction-sequence diagrams. At the level of computational design (Row 2 in Table 1), the interaction aspect is captured by AOR reaction-frame diagrams. The agent diagram of Figure 5 represents the agent role types Buyer and Seller of the case study, with their respective internal agent types Clerk and SoftwareAgent. For simplicity, other relevant agent types like Bank have been omitted in the figure. There is the isBenevolentTo relationship between instances of the role types Seller and Buyer in Figure 5. This relationship typically appears between a service provider and requester. A use-case diagram as depicted in Figure 6 summarizes the types of interactions between two agents of the type Buyer and Seller, which act as a service requester and provider, respectively. Interactions between a service requester and provider are further refined in the interaction-frame diagram in Figure 7, which covers the business process types of quoting, ordering, and invoicing between instances of the agent role types Buyer and Seller The interaction frame represented in Figure 7 contains types of communicative action events (messages) such as request PurchaseOrder/Confirmation, which is used for ordering, non-communicative action event types like provideProduct, and types of commitments/claims coupled with them. Each communicative action event type is prefixed by one of two functions of message types5: request, by which a sender requests the receiver to perform a communicative or physical action or both, and inform, which identifies a communicative action performed in reply to a request or independently. Interaction-frame diagrams may be complemented by interaction-sequence diagrams, which depict prototypical instances of interaction processes. The interaction-sequence diagram in Figure 8 represents instances of the business process types of quoting, ordering, and invoicing between the agents BuyerA and SellerB. An interaction-frame diagram of the conceptual domain-modelling level can be turned into a reaction-frame diagram of the computational-design level by the process of internalization, which was briefly described in an earlier section, “Viewpoints of Design.” In that process, the external AOR model is transformed into an internal AOR model for the (type of) focus agent for which an agentified information system is to be developed (typically an organization or an organizational unit). For example, Figure 11 represents the reaction frame created for an instance of the agent role type Seller. This model has been obtained from the interaction frame shown in Figure 7.
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
306 Taveter & Wagner
is performed to those belonging to the instance of Quote that is identified by the value of the input parameter q. When all subactivities of the type “Process product item” have ended, the enclosing activity of the type “Process product items” also ends. The subactivity “Process product item” in Figure 12 checks the availability of the given product item that is specified by the input parameter item of the type QuoteLineItem. If the product item corresponding to the instance of QuoteLineItem is available in the quantity requested, the status of the QuoteLineItem is set to isBid. In the opposite case, the status of the QuoteLineItem is changed to isNoBid. In both cases, the attributes of the QuoteLineItem are updated accordingly. Figure 12. The complete behaviour model of the quoting business process type from the perspective of Seller Seller
Buyer
request RFQ/Quote
R1
C
Manage quoting (q : Quote)
Quote
Process product items (q : Quote)
QuoteLineItem QuoteLineItem StatusCode
R2
{quote = q}
isBid isNoBid
Process product item (item: QuoteLineItem)
isPending
U
U
R3
ProductItem productID {isAvailable (item.requestedQuantity) and unitPrice itemsAvailable productID = item.globalProductIdentifier} isAvailable (Integer)
R4
approveQuote
Clerk
Confirm quote (q : Quote)
inform RFQ/Quote
R5
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
303
Figure 11. The reaction frame for an agent of the type Seller Seller Buyer request RFQ/Quote
inform RFQ/Quote request PurchaseOrder/ Confirmation inform PurchaseOrder/ Confirmation provideProduct (PurchaseOrder) provideProduct (PurchaseOrder)
request Invoice
payForProduct (Invoice) payForProduct (Invoice)
The Information Aspect At the level of conceptual domain modelling (Row 1 in Table 1), the information aspect (Column 2 in Table 1) is captured by conceptual AOR information models, which are represented by AOR agent diagrams. The conceptual information model of the problem domain of business-tobusiness electronic commerce is represented in the agent diagram in Figure 5. The figure shows that the object types PurchaseOrder/Confirmation, RFQ/Quote, and Invoice are shared between agents of the types Buyer and Seller, while the
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
304 Taveter & Wagner
object types ProductItemOfSeller and ProductItem are represented exclusively within agents of the types Buyer and Seller, respectively. It is important to emphasize here that a shared object type does not imply that all the agents whose types are connected by an association to it have the same beliefs about it, or, in other words, that there is a common extension of it shared by all agents. For example, different instances of the agent role type Buyer in Figure 5 hold different sets of instances of RFQ/Quote. Instances of the object type Seller within an instance of Buyer represent information about the corresponding instances of the agent type Seller. An object of the type QuoteLineItem in Figure 5 satisfies one of the following status predicates: isBid, isNoBid, and isPending, while an object of the type ProductLineItem represented in the same figure is characterized by the status predicate isAccept, isReject, or isPending. At the level of computational design (Row 2 in Table 1), the information aspect is captured by detailed AOR agent diagrams that include, for example, the types of attributes and the identifiers for agent and object types.
The Behaviour Aspect While the interaction aspect deals with the communication and interactions between the agents, the behaviour aspect (Column 3 in Table 1) addresses the agents’ reactions to the communicative and non-communicative action events and non-action events perceived by them. At the level of conceptual modelling (Row 1 in Table 1), the behaviour aspect is captured by the conceptual AOR behaviour models that are represented by means of the following views: AOR interaction-pattern diagrams, goal-based use-case models and AOR activity diagrams. At the level of computational design (Row 2 in Table 1), the behaviour aspect is captured by AOR reaction-pattern diagrams and AOR internal activity diagrams. Figure 4 serves as an example of an interaction-pattern diagram specifying the reaction rule R1 for a Seller’s behaviour in response to perceiving a communicative action event of the type request PurchaseOrder. A goal-based use case can be triggered by an internal or external actor. For example, the use case “Issue a request for a quote” with the buyer in focus is triggered by the buyer’s internal actor “clerk,” while the use case “Process the request for a quote” presented as an example in Table 3 is triggered by receiving a request from a buyer for a quote. The use case (“Process the request for a quote”) in Table 3 is modelled from the perspective of a buyer with the seller in focus (scope), which means that the goal of the use case is the so-called user
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
305
goal, the goal of the actor (i.e., a buyer) trying to get work (primary task) done (Cockburn, 1997a). The buyer is therefore the external primary actor of the use case. Since the goal of the primary actor is “internalized” by the actor in focus, unlike Cockburn, we also include the goal of the focus actor in a goal-based use case, as is reflected by Table 3. As shown in Taveter (2004a), a goal-based use case can be straightforwardly turned into sequences and hierarchies of activity types whose instances are performed by an agent. For example, an activity diagram as shown in Figure 10 corresponds to the use case represented in Table 3. In the figure, an activity of the type “Manage quoting,” which is visualized as a roundtangle, is started by reaction rule R1 in response to receiving a message containing a request for a quote. As shown in Figure 10, an activity of the type “Manage quoting” consists of sequential subactivities of the types “Process product items” and “Confirm quote.” For each activity type represented in Figure 10 can be defined the goal that its instances try to achieve. The goal defined for the outermost activity type, which is “Manage quoting” in Figure 10, corresponds to the focus actor’s goal of the respective goal-based use case. For example, the goal of an activity of the type “Process product items” is represented informally as “For each product item included by the request for a quote is known whether it is to be bid or not.” This goal can be formalized by means of OCL in terms of the input parameter declared for the corresponding activity type, as is represented in Figure 10. Input parameters defined for activity types represent the dataflow through the activities. Next, activity diagrams obtained from goal-based use cases are elaborated by introducing into them behavioural constructs by means of reaction rules. Taveter (2004a) has shown that AORML extended by activity modelling allows the representation of 16 out of 19 behavioural workflow patterns as defined in the benchmark proposal of van der Aalst, ter Hofstede, Kiepuszewski and Barros (2003). The complete behavioural model of the quoting business process type from the perspective of the agent role type Seller is represented in Figure 12. As the figure shows, the behavioural model shown in Figure 10 has been complemented by the behavioural constructs of the types “For-each loop” and “Starting an activity by means of two (or more) events.” In addition, elementary epistemic, physical, and communicative actions that make up the activity types “Process product item” and “Confirm quote” have been specified. According to the behavioural construct of the type “For-each loop” represented in Figure 12, upon the start of an activity of the type “Process product items,” its subactivity of the type “Process product item” is performed for each instance of the object type QuoteLineItem for which the pre-condition quote = q evaluates to true. The pre-condition limits the set of QuoteLineItems for which the subactivity
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
307
The behavioural construct of the type “Starting an activity by means of two (or more) events” represented in Figure 12 specifies that, upon the end of an activity of the type “Process product items,” if the agent perceives an approval of the quote by an internal human agent of the type Clerk, an activity of the type “Confirm quote” is started. An activity of the given type is thus started only after events of all the specified types have occurred. In Figure 12, such events are the ending event of the previous activity and an approval of the quote by a human agent instance of the type Clerk. Since goal-based use cases also serve to document business process types modelled by activity diagrams, in Table 5, the use case “Process the request for Table 5. A goal-based use case for the business process type “Process the request for a quote” USE CASE 2 Goal of the Primary Actor Goal of the Focus Actor Scope & Level Success End Condition Primary Actor Secondary Actors Triggering event DESCRIPTION
Process the request for a quote. To receive from the seller the quote. To provide the buyer with the quote. Seller, primary task. The buyer has received from the seller the quote. Buyer. A request for a quote by the buyer. Step Action 1 For each product item included in the request for a quote: process product item (Use Case 3). 2 The quote has been approved by the clerk: send the quote to the buyer.
Table 6: The subfunction “Process product item” USE CASE 3 Goal of the Primary Actor Goal of the Focus Actor Scope & Level Pre-conditions Success End Condition Primary Actor Secondary Actors Trigger DESCRIPTION EXTENSIONS
Process product item. To decide bidding of the product item. Seller, subfunction. The bidding of the product item has been decided. Buyer. Step 1 Step 1a
Action The product item is available in the quantity requested: the product item is to be bid which is registered in the quote. Branching Action The product item is not available in the quantity requested: the product item is not to be bid which is registered in the quote.
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
308 Taveter & Wagner
a quote,” which was originally represented in Table 3, has been complemented by the elements corresponding to the behavioural constructs introduced. Please note that a subfunction6 of the primary task “Process the request for a quote” presented in Table 6 contains the main (success) scenario (Cockburn, 2001), and one extension scenario (Cockburn, 2001) that starts by stating where it picks up in the main scenario and what conditions are different.
Simulation Taveter (2004a) demonstrated that AORML extended by activities is the first agent-oriented modelling language where partially specified behaviour models by activity diagrams can be executed. For example, in our case study, both an incomplete conceptual AOR behaviour model of the quoting business process type represented in Figure 10 and the complete behaviour model represented in Figure 12 can be executed. This facilitates iterative business modelling that is the state-of-the-practice. Using executable process models jointly with an AgentObject-Relationship Simulation (AORS) system, as described in Wagner and Tulba (2003), permits the creation of powerful simulation environments. For this purpose, as well as for the creation of actual agentified information systems, the approach of transforming models into implementations described in the “Implementation and Tools” section can be employed.
Implementation and Tools The RAP/AOR methodology complies with the principles of the MDA framework of OMG (http://www.omg.org/mda/). According to the overview of MDA provided in Klasse Objecten (http://www.klasse.nl/english/mda/mdaintroduction.html), the MDA process defines three steps: 1.
First, a model at a high level of abstraction that is independent of any implementation technology is built. This is called a Platform Independent Model (PIM). In the RAP/AOR methodology, the models listed in Row 2 of Table 1 form the PIM.
2.
Next, the PIM is transformed into one or more Platform Specific Models (PSM). A PSM is tailored to specify the PIM in terms of the implementation constructs that are available in one specific implementation technology. In the RAP/AOR methodology, the PSM can be respresented by the models listed in Row 3 of Table 1.
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
3.
309
The final step is to transform a PSM to code. Because a PSM fits its technology very closely, this transformation is rather trivial. The complex step is the one in which a PIM is transformed into a PSM.
In principle, the transformation from a PIM into a PSM can be performed for each software system to be built (e.g., an agentified information system) separately. However, in the RAP/AOR methodology, we advocate an approach where executable AOR models are transformed into equivalent XML-based representations that are then interpreted and executed by software agents. In the case study of automating business-to-business processes, which we described in our case study, this is crucial because new business process types emerge and old ones frequently change, as a result of which specifications of business process automation systems are in constant flux. In order to facilitate generation of XML-based representations of business process models, we have developed the corresponding XML Schema (http:// www.w3.org/XML/Schema) whose instances describe business process types in a machine-interpretable way. By using the schema, it is possible to represent business process types from different perspectives. For example, the models of the quoting business process type created in our case study are transformed into two XML-based representations that describe the quoting business process type from the perspectives of the agent role types Seller and Buyer. Figure 13. The business process automation system
User
User Maintainer
JADE agent
Interact with agent
ACL message
ACL message
Instantiate business process type (...)
JADE agent
Integrated Business Process Editor (CONE) Description of business process type in XML
Interact with agent
Model business process type in the extended AORML
Interpret business process Invoke agent
CRM System
Business Process Interpreter Representations of business process types
ERP System
EAI 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
Towards Radical Agent-Oriented Software Engineering Processes
311
The Integrated Business Process Editor allows graphical descriptions of business process types expressed in AORML to be transformed into their representations in XML. Even though the XML-based representations of a business process type are generated automatically, as a rule, some manual tailoring of process-specific interfaces must be performed. This occurs between the Business Process Interpreter and enterprise systems of the company. Enterprise systems can include the Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), and Enterprise Application Integration (EAI) systems shown in Figure 13. After the generation and tailoring have been accomplished, a business process type is ready to be interpreted by the Business Process Interpreter, which works in cooperation with the software agent representing the corresponding party. The latter has been implemented using the Java Agent DEvelopment Framework (JADE) (http://jade.cselt.it/) agent platform. Agents communicate with each other using messages in the Agent Communication Language (ACL) defined by FIPA (http://www.fipa.org/), which is based on speech acts (Austin, 1962). As Figure 13 illustrates, an agent representing a party first invokes the Business Process Interpreter to read the description of the business process type, as requested by the agent’s human user, and to create its internal representation of the business process type. Thereafter, when the agent receives a message or “perceives” an input by a human user through the Graphical User Interface (GUI), the agent invokes the Business Process Interpreter to act according to the process type description. When the Business Process Interpreter acts, it, in turn, invokes the JADE agent and displays messages through the agent’s GUI.
Strength and Weakness of the RAP/AOR Methodology At present, it is difficult to evaluate the RAP/AOR methodology, mainly because some of its components—in particular, certain model transformations and related tools—have not yet been fully developed. Consequently, a lack of tool support and field testing reports is a weakness of the proposed methodology at the time of writing this chapter. On the other hand, the experience gained in the case study discussed and in implementing the tool support discussed in “Implementation and Tools” section have been encouraging and lead us to believe that RAP/AOR is a natural extension of RUP+UML offering higher level modelling constructs.
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
310 Taveter & Wagner
In the prototype application represented in Figure 13, inter-organizational business process types are described in the (extended by activities) AORML by means of the Integrated Business Process Editor. The latter has been developed as an extension to the COnceptual Network (CONE) Ontology Editor of VTT Information Technology. Figure 14 shows a snapshot of the model of the RosettaNet-based quoting business process type that has been created by using the editor from the perspective of Seller. Please note that since the older version of AORML was originally defined on the basis of UML 1.5 (OMG, 2003a), Figure 14 uses the old graphical notations for agents and activities in AORML. Note also that the models represented in Figure 14 are external AOR models— the process of internalization briefly described in section, “Viewpoints of Design,” is performed implicitly when subjective XML-representations are generated from an objective model of a business process type. In other words, due to the implicit internalization, CIM serves as the starting point instead of PIM.
Figure 14. The quoting business process type from the perspective of Seller modelled by the Integrated Business Process Editor
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
312 Taveter & Wagner
Not supporting the design of proactive behaviour may be seen either as a weakness or as a strength. It is certainly a weakness from an AI point of view; however, we consider it to be a strength since the agents we want to design as components of large-scale cross-enterprise distributed information systems do not need proactive behaviour, nor do they need any other form of sophisticated human-like intelligence. Rather, such agents typically have a complicated structure of beliefs and commitments and a reactive behaviour based on them, both of which can be captured by the RAP/AOR methodology. Two particular strengths of the proposed methodology are its ontological foundation and its use of simulation for achieving more agility. Another strength is the possibility to represent the models of the interaction, information, and behaviour viewpoint aspects in just one integrated diagram. This overcomes the model multiplicity problem (Peleg & Dori, 2000), which is that, to understand the system being studied and the way it operates and changes over time, the reader must concurrently refer to various models. An important open issue for RAP/AOR is the potential for an operational commitment concept for designing and controlling business-to-business interactions. The basic assumption of AOR modelling that, in addition to beliefs and perceptions, commitments are the third mental state component that is important for understanding and designing agent-to-agent interactions, has not yet been validated in novel technologies and practical applications.
Conclusions In this chapter, we have introduced the RAP/AOR methodology for agentoriented information systems engineering. Unlike many other agent-oriented methodologies, RAP/AOR is not intended to be used in the development of AI agent systems; rather, it targets the development of large-scale distributed and cross-enterprise business information systems that may include or even consist of software agents. RAP/AOR is an agent-oriented extension of RUP+UML by adding the mental state structure modelling constructs of agents, events, actions, commitments, and claims, and by adding the behaviour modelling constructs of reaction rules and activities. Additionally, these modelling constructs fit well with MDA. In particular, they yield a higher level PIM language that allows a more direct mapping of CIM elements to PIM elements.
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
314 Taveter & Wagner
B. Henderson-Sellers, & G. Low (Eds.), AOIS-2004 (LNAI, Vol. 3508, pp. 2804). Berlin: Springer-Verlag. Jacobson, I. (1992). Object-oriented software engineering: A use-case driven approach. Reading, MA: Addison-Wesley. Jacobson, I., Booch, G., & Rumbaugh, J. (1999). Unified software development process. Reading, MA: Addison-Wesley. Kruchten, P. (1999). Rational unified process – An introduction. Reading, MA: Addison-Wesley. Kueng, P. & Kawalek, P. (1997). Goal-based business process models: Creation and evaluation. Business Process Management Journal, 3(1), 17-38. Lamsweerde, A. van. (2003). From system goals to software architecture. In M. Bernardo & P. Inverardi (Eds.), Formal methods for software architectures (LNCS 2804, Vol. 2804, pp. 25-43). Berlin: Springer-Verlag. Luin, J., van, Tulba, F., & Wagner, G. (2004). Remodelling the beer game as an agent-object-relationship simulation. In Proceedings of Workshop 2003: Agent-Based Simulation 5, Lisbon, Portugal, May 3-5 (pp. 174-179). SCS European Publishing House. OMG (2003a). Unified modeling language specification. March 2003, Version 1.5. Retrieved September 28, 2004, from http://www.omg.org/cgi-bin/ doc?formal/03-03-01 OMG (2003b). Unified modeling language: Superstructure. Version 2.0, August 2003. Retrieved September 25, 2004, from http://www.omg.org/cgi-bin/ doc?ptc/2003-08-02 Peleg, M. & Dori, D. (2000). The model multiplicity problem: Experimenting with real-time specification methods. IEEE Transactions on Software Engineering, 26(8), 724-759. Putman, J. & Boehm, B. (2001). Architecting with RM-ODP. Upper Saddle River, NJ: Prentice Hall. Rao, A. S. & Georgeff, M. P. (1991). Modeling rational agents within a BDIarchitecture. In J. Allen, R. Fikes, & E. Sandewall (Eds.), Proceedings of the Second International Conference on Knowledge Representation and Reasoning (KR-91), Boston, April (pp. 473-484). San Mateo, CA: Morgan Kaufmann. Searle, J. R. (1995). The construction of social reality. New York: Free Press. Sowa, J. F. & Zachman, J. A. (1992). Extending and formalizing the framework for information systems architecture. IBM Systems Journal, 31(3), 590-616. SPEM: Software Process Engineering Metamodel Specification. November 2002, Version 1.0. Retrieved October 20, 2004, from http://www.omg.org/ docs/formal/02-11-14.pdf 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
315
Taveter, K. (2004a). A multi-perspective methodology for agent-oriented business modelling and simulation. PhD thesis, Tallinn University of Technology, Estonia. (ISBN 9985-59-439-8). Taveter, K. (2004b). From business process modelling to business process automation. In J. Cordeiro & J. Filipe (Eds.), Computer-supported activity coordination – Proceedings of the 1st International Workshop on Computer Supported Activity Coordination (CSAC 2004). In conjunction with ICEIS 2004, Porto, Portugal, April 13-14 (pp. 198-210). Setubal, Portugal: INSTICC Press. van der Aalst, W.M.P., ter Hofstede, A.H.M., Kiepuszewski, B., & Barros, A.P. (2003). Workflow patterns. Distributed and Parallel Databases, 14(3), 5-51. Wagner, G. (2003a). The agent-object-relationship meta-model: Towards a unified view of state and behavior. Information Systems, 28(5), 475-504. Available online at http://aor.rezearch.info/ Wagner, G. (2003b). A UML profile for external AOR models. In F.Giunchiglia, J. Odell, & G. Weiss (Eds.), Agent-Oriented Software Engineering III, Third International Workshop, AOSE 2002. Bologna, Italy, July 15, Revised Papers and Invited Contributions, (LNCS, Vol. 2585, pp. 138149). Berlin: Springer-Verlag. Wagner, G. & Tulba, F. (2003). Agent-oriented modeling and agent-based simulation. In P. Giorgini & B. Henderson-Sellers, (Eds.), Conceptual modeling for novel application domains (LNCS, Vol. 2814, pp. 205216). Berlin: Springer-Verlag. W3C (2003). Web Services Architecture (WSA). W3C Working Draft, 8 August 2003. Retrieved September 29, 2004, from http://www.w3.org/TR/ 2003/WD-ws-arch-20030808/ W3C (2004). Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language. W3C Working Draft, 3 August 2004. Retrieved September 27, 2004, from http://www.w3.org/TR/2004/WD-wsdl20-20040803/ Yu, E. (1995). Modeling strategic relationships for process reengineering. PhD thesis, Department of Computer Science, University of Toronto, Canada. Zambonelli, F., Jennings, N. R., & Wooldridge, M. (2001). Organisational abstractions for the analysis and design of multi-agent systems. In P. Ciancarini & M. Wooldridge (Eds.), Agent-oriented software engineering, (LNCS 1957, Vol. 1957, pp. 127-141). 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
Towards Radical Agent-Oriented Software Engineering Processes
313
References Austin, J. (1962). How to do thing with words. Urmson Editor, Oxford, UK: Clarenson Press. Beck, K. (1999). Extreme programming explained: Embrace change. Indianapolis, IN: Addison-Wesley Professional. Bernon, C., Glaizes, M-P., Peyruqueou, S., & Picard, G. (2002). ADELFE, a methodology for adaptive multi-agent systems engineering. In P. Petta, R. Tolksdorf, & F. Zambonelli (Eds.), Engineering societies in the agents world III: Third International Workshop (ESAW 2002), Madrid, September 16-17, revised papers (Vol. 2577, pp. 156-169). LNAI 2577. Berlin: Springer-Verlag. BPML (2002). Business Process Modeling Language 1.0 and Business Process Modeling Notation 0.9. (2002). Retrieved September 4, 2004, from http:/ /www.bpmi.org Capera, D., Georgé, J-P., Gleizes, M-P., & Glize, P. (2003). The AMAS theory for complex problem solving based on self-organizing cooperative agents. In Proceedings of the 12th IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE ’03), Linz, Austria, June 9-11 (pp. 383-388). IEEE Press. Cockburn, A. (1997a, Sept). Goals and use cases. Journal of Object-Oriented Programming, 10(5), 56-62. Cockburn, A. (1997b, Nov/Dec). Using goal-based use cases. Journal of Object-Oriented Programming, 10(7), 56-62. Cockburn, A. (2001). Writing effective use cases. Reading, MA: AddisonWesley. Eshuis, R., Jansen, D. N., & Wieringa, R. J. (2002). Requirements-level semantics and model checking of object-oriented statecharts. Requirements Engineering Journal, 7(4), 243-263. Evans, R., Kearney, P., Stark, J., Caire, G., Garijo, F. J., Gomez Sanz, J. J., Pavon, J., Leal, F., Chainho, P., & Massonet, P. (2001). MESSAGE: Methodology for engineering systems of software agents. EURESCOM Technical Information, 2001. Retrieved August 31, 2004, from http:// www.eurescom.de/~pub-deliverables/P900-series/P907/TI1/p907ti1. pdf Fowler, M. (2003). The new methodology. Retrieved September 4, 2004, from http://martinfowler.com/articles/newMethodology.html#N400315 Guizzardi, G. & Wagner, G. (2005). Towards ontological foundations for agent modelling concepts using the Unified Foundational Ontology. In P. Bresciani, Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
316 Taveter & Wagner
Endnotes *
The author has done the work reported in this chapter partially as an employee of the Technical Research Centre of Finland (VTT Information Technology) from where he is currently on leave.
1
Strictly speaking, the RAP defines a process type family whose members are process types that can be instantiated by different process individuals. It is common practice, though, to use the term “process” ambiguously both at the level of types and at the level of instances.
2
The RAP/AOR methodology has, for example, been used for creating a prototypical system for the automation of business-to-business processes described in Taveter (2004b).
3
A role can be understood as an “abstract characterization of the behaviour of a social actor within some specialized context or domain of endeavor” (Yu, 1995), such as the role Seller.
4
Henceforth, we use the terms “actor” and “agent” as synonyms.
5
These functions are actually speech acts (Austin, 1962).
6
A subfunction is a use case that is below the main level of interest of the primary actor.
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 Engineering
317
Chapter XI
Multi-Agent Systems Engineering: An Overview and Case Study Scott A. DeLoach Kansas State University, USA Madhukar Kumar Software Engineer, USA
Abstract This chapter provides an overview of the Multi-agent Systems Engineering (MaSE) methodology for analyzing and designing multi-agent systems. MaSE consists of two main phases that result in the creation of a set of complementary models that get successively closer to implementation. MaSE has been used to design systems ranging from a heterogeneous database integration system to a biologically based, computer virusimmune system to cooperative robotics systems. The authors also provide a case study of an actual system developed using MaSE in an effort to help demonstrate the practical aspects of developing systems using MaSE.
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
318 DeLoach & Kumar
Introduction This chapter describes the Multi-agent Systems Engineering (MaSE) methodology for analyzing and designing multi-agent systems. MaSE was originally designed to develop closed, general purpose, heterogeneous multi-agent systems. MaSE has been used to design systems ranging from a heterogeneous database integration system to a biologically based, computer virus-immune system to cooperative robotics systems. While the multi-agent systems designed by MaSE are typically closed (the number and type of all agents are known a priori), the number of agents is unlimited, although, practically, the number of types of different agents is limited to something less than 50. MaSE uses the abstraction provided by multi-agent systems to help designers develop intelligent, distributed software systems. MaSE views agents as a further abstraction of the object-oriented paradigm where agents are a specialization of objects. Instead of simple objects, with methods that can be invoked by other objects, agents coordinate with each other via conversations and act proactively to accomplish individual and system-wide goals. Agents are a convenient abstraction that allows designers to handle intelligent and nonintelligent system components equally within the same framework. MaSE builds on existing object-oriented techniques and applies them to the specification and design of multi-agent systems. Many of the models developed with MaSE are similar to models defined in the Unified Modeling Language. However, the semantics of the models are often specialized for the multi-agent setting. MaSE was designed to be used to analyze, design, and implement multi-agent systems by proceeding in an orderly fashion through the development lifecycle (DeLoach, Wood, & Sparkman, 2001). MaSE has been automated via an analysis and design environment called agentTool, which is a tool that supports MaSE and helps guide the system designer through a series of models, from highlevel goal definition to automatic verification, semi-automated design generation, and finally to code generation. The MaSE methodology consists of two main phases that result in the creation of a set of complementary models. The phases and the respective models that result at the end of each phase are listed below. While presented sequentially, the methodology is, in practice, iterative. The intent is to free the designer to move between steps and phases such that with each successive pass, additional detail is added and, eventually, a complete and consistent system design is produced.
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 Engineering Phases 1. Analysis Phase a. Capturing Goals b. Applying Use Cases c. Refining Roles 2. Design Phase a. Creating Agent Classes b. Constructing Conversations c. Assembling Agent Classes d. System Design
319
Models Goal Hierarchy Use Cases, Sequence Diagrams Concurrent Tasks, Role Model Agent Class Diagrams Conversation Diagrams Agent Architecture Diagrams Deployment Diagrams
Analysis Phase The first phase in developing a multi-agent system using the MaSE methodology is the analysis phase. The goal of the MaSE analysis phase is to define a set of roles that can be used to achieve the system-level goals. These roles are defined explicitly via a set of tasks, which are described by finite state models. This process is captured in three steps: capturing goals, applying use cases, and refining roles.
Capturing Goals The purpose of the first step in the analysis phase is to capture goals of the system by extracting the goals from a set of system requirements. The initial system requirements may exist in many forms including informal text and tell the designer about how the system should function based on specific inputs and the system state. The MaSE methodology uses these requirements to define goals in two specific sub-steps: Identifying goals and Structuring goals.
Identifying Goals The main purpose of this step is to derive the overall system goal and its subgoals from the initial set of requirements. This is done by first extracting scenarios from the requirements and then identifying the goals of the scenarios. These initial scenarios are usually abstract in nature and are critical to the entire system. Therefore, the goals identified from these scenarios are at a very high level. These high-level goals then serve as the basis of analysis of the entire system. The roles defined later in the analysis phase must support one of these goals. Later, if the analyst defines a role that does not support one of these goals, either
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
322 DeLoach & Kumar
MaSE is built on the assumption that the system goals will be satisfied if each goal maps to a role, and every role is played by at least one agent class. In general, the mapping of goals to roles involves a one-to-one mapping. However, the developer may choose to allow a role to be responsible for multiple goals for the sake of convenience or efficiency. At this stage, the developer may also choose to combine several roles; although this will most certainly increase the complexity of the individual roles, it can significantly simplify the overall design. In MaSE, goal refinement is captured in a Role Model (Kendall, 1998). In this model, the roles are represented by a rectangle, while a role’s tasks are represented by ovals attached to them. The arrows between tasks designate communication protocols, with arrows pointing from the initiator of the protocol toward the responder. Solid lines represent external communication (role-torole), while dashed lines indicate internal communication between tasks belonging to the same role instance. Once the roles are decomposed into a set of tasks, the individual tasks are designed to achieve the goals for which the role is responsible. It is important to note here that roles should not share tasks with other roles. Sharing a task among different roles indicates improper role decomposition. If the analyst believes that a task needs to be shared, then a separate role should be created for that task. This will allow the task to be incorporated into different agent classes, thus being effectively shared.
Concurrent Task Model After the roles are defined, the analyst must define the details of each task in the role model. Task definition is performed via a Concurrent Task Diagram, which is based on finite state automata. Semantically, each task is assumed to run concurrently and may communicate with other tasks either internally or externally. Taken collectively, the set of tasks for a specific role should define the behavior required for that role. A concurrent task consists of a set of states and transitions. The states in the concurrent tasks represent the internal functioning of an agent while transitions define the communication between tasks. Every transition in the model has a source state, destination state, trigger, guard condition, and transmissions. The transitions use the syntax trigger [guard] ˆ transmission(s) If there are multiple transmissions required, they can be concatenated using a semicolon (;) as a separator; however, no ordering is implied. In general, events Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
320 DeLoach & Kumar
the role is not needed or the initial set of goals was incomplete and a new goal must be added.
Structuring Goals After the goals have been identified, the second step is to categorize and structure them into a goal tree. The result is a Goal Hierarchy Diagram whose nodes represent goals and arcs define goal/subgoal relationships. The Goal Hierarchy Diagram is acyclic; however, there some subgoals that may have more that one parent goal. To structure the goals, the analyst first identifies the main goal of the system. In the case where there is more than one main goal, those goals must be summarized as one high-level goal that is decomposed into a set of subgoals that are easier to manage and understand. To decompose a goal into subgoals, the developer must analyze what must be done to achieve the parent goals. A subgoal should support its parent goal by describing a subgoal that must be achieved in order to achieve the parent goal. Although superficially similar, goal decomposition is different from function decomposition since goals define what tasks must be done instead of how a task is achieved, which is functional decomposition. Thus, goal decomposition should stop when the designer thinks that any further decomposition will result in functions and not subgoals. MaSE goal decomposition is similar to the KAOS approach (van Lamsweerde & Letier, 2000) except that MaSE goals do not have to be strictly AND-refined or OR-refined. There are four types of goals in a Goal Hierarchical Diagram: summary goals, partitioned goals, combined goals, and non-functional goals. Any goal or subgoal can take on the attributes of any one, or more, of these types of goals. The four types of goals are described below. 1.
Summary Goal. A summary goal encapsulates a set of existing “peer” goals to provide a common parent goal for the set. This often happens at the highest level of the Goal Hierarchical Diagram when a goal may be needed to support multiple high-level goals.
2.
Non-Functional Goal. As the name suggests, non-functional goals are derived from non-functional requirements of the system, such as maintaining reliability or response times of the system. These goals need not directly support the overall functional goals of the system. When a non-functional goal is discovered, a new branch is generally created under the overall system goal, which can then be decomposed into either functional or nonfunctional sub-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
Multi-Agent Systems Engineering
325
Conversations are modeled using two different Conversation Class Diagrams, one for the initiator and the other for the responder. These diagrams are based on finite state automata and use states and transitions to define the inter-agent communication, similar to concurrent tasks. The transitions in the conversation diagrams use a slightly different syntax rec-mess(args1) [cond] / action ˆ trans-mess(args2) This means that that if the message rec-mess is received with the arguments args1 and the condition cond holds true, then the method action is called and the message trans-mess is sent with arguments args2. Conversations are derived from the concurrent tasks of the analysis phase, based on the roles the agents are required to play. Thus, each task that defines an external conversation (outside the role) ends up becoming one or more conversation between agents. However, if all task communication is internal (within the same role) or with roles that are performed by the same agent, then the communication translates into internal function or method calls. Generally, however, concurrent tasks translate into multiple conversations, as they require communication with more than one agent class. During this stage, the designer also needs to take into account other factors besides the basic protocols defined in the concurrent tasks. For example, what should an agent do if it does not receive the message it was expecting? Perhaps the communication medium was disabled or the other agent failed. Therefore, the designer should attempt to make conversations robust enough to handle potential run-time errors.
Assembling Agent Classes and Deployment Design The last two stages in MaSE involve the internal design of the agent classes and the system-level design. The first of these stages, Assembling Agent Classes, involves two steps, defining the agents’ architecture and defining the individual components of the architecture. MaSE does not assume any particular agent architecture and attempts to allow a wide variety of existing and new architectures to be used. Thus, the designer has the choice of either using pre-existing agent architecture like Beliefs, Desires, and Intentions (BDI) or creating a new architecture from scratch. The same goes for the architecture components. The step of assembling agents result in an Agent Architecture Diagram in which the components are represented by rectangular boxes connected to either inner or outer agent connectors. The inner-agent connectors, represented by thin arrows define visibility between components, while the outer agent connectors, repreCopyright © 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 Engineering
321
3.
Combined Goal. While analyzing the goals of a system, often a number of subgoals are discovered in a hierarchy that are identical or very similar and can be grouped into a combined goal. This often results when the same basic goal is a subgoal of two different goals. In this case, the combined goal becomes a subgoal of both the goals.
4.
Partitioned Goal. A partitioned goal is one of a set of goals that collectively meet a parent goal. This is identical to the notion of a KAOS conjunctive goal.
Once the goals have been identified and structured, the developer is ready to move to the next step of the MaSE analysis phase, applying use cases.
Applying Use Cases In this step, the goals and subgoals are translated into use cases. These use cases typically capture the scenarios discovered in the previous step by providing a textual description and a set of sequence diagrams that are similar to the UML sequence diagrams. The main difference between MaSE sequence diagrams and UML is that in MaSE they are used to represent sequences of events between roles instead of objects. The events sent between roles are used in later steps to help define the communications between the agents that will be eventually playing these roles. The use case at this stage helps the developer in representing desired system behaviors and sequences of events. When the use cases are converted to sequence diagrams, the roles that are identified become the initial set of roles that will be used in the next step of refining roles. While not all requirements can be captured as use cases, the developer should try to represent the critical requirements as either positive or negative use cases. Positive use cases define the desired system behaviors, and negative use cases describe a breakdown or an error in the system. Both are useful in defining roles that must be played in the system.
Refining Roles With the Goal Hierarchy Diagram and use cases in place, the analyst is ready to move to the next step, Refining Roles. This step involves further defining roles by associating them with specific tasks. The roles produced from this step are defined in such a way as to ensure that each system goal is accounted for and form the building blocks for the agents that will eventually populate the system. 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 Engineering
323
sent as triggers or transmissions are associated with events sent to tasks within the same role instance, thus allowing for internal task coordination. To represent messages sent between agents, however, two special events—send and receive —are used. The send event is used to represent a message sent to another agent and is denoted by send(message, agent) while a receive event, denoted by receive(message, agent), is used to define a message received from another agent. The message itself consists of a performative, the intent of the message along with a set of parameters. It is also possible to send the same message to several agents at the same time using multicasting by using a group name of the agents as compared to the name of a single agent. Task states may contain activities that represent internal reasoning, reading a percept from sensors, or performing actions via actuators. More than one activity may be included in a single state and they are performed in an uninterruptible sequence, which, when combined with states and transitions, gives a general computational model. Once inside a state, the task remains there until the activity sequence is complete. Variables used in activity and event definitions are visible within the task, but not outside of the task or within activities. All messages sent between roles and events sent between tasks are queued to ensure that all messages are received even if the agent or task is not in the appropriate state to handle the message or event immediately. Once a transition is enabled, it is executed instantaneously. If multiple transitions are enabled, then internal events are handled first, external messages (the send/ receive events) are next, and the transitions with guard conditions only are last (DeLoach, 2000). To reason about time, the Concurrent Task Model provides a built-in timer activity. An agent can define a timer using the setTimer activity, t = setTimer(time). The setTimer activity takes a time as input and returns a timer that will timeout in exactly the time specified. The timer that can then be tested via the timeout activity, timeout(t), which returns a Boolean value, to see if it has “timed out.”
Design Phase In the analysis phase, a set of goals was derived and used to create a set of use cases and sequence diagrams that described basic system behavior. These models were then used to develop a set of roles and tasks that showed how the goals should be achieved. The purpose of the design phase is to take those roles and tasks and to convert them into a form that is more amenable to implementation, namely, agents and conversations. The MaSE design phase consists 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
326 DeLoach & Kumar
sented by dashed arrows, define external connections to resources like other agents effectors, databases, and so on. A more detailed discussion of this step can be found in Robinson (2000). The last step in building a multi-agent system using the MaSE methodology is to decide on the actual configuration of the system, which consists of deciding the number and types of agents in the system and the platforms on which they should be deployed. These decisions are documented in a Deployment Diagram, which is very similar to a UML Deployment Diagram and is used for much the same purpose. In a Deployment Diagram, agents are represented by three-dimensional boxes, while rectangles with dashed lines represent physical computing platforms. The lines between agents represent the actual lines of communication between the agents. In a dynamic multi-agent system in which agents move or are created and destroyed, the Deployment Diagrams are used to show snapshots of possible system configurations.
Example Case Study: Multi-Agent Research Tool (MART) To show how to use the MaSE methodology outlined above, this section presents an example of using MaSE to develop an actual multi-agent system. The Multiagent Research Tool (MART) was developed as part of a MS project at Kansas State University and is being considered for distribution by a private company. The analysis and design was performed using the agentTool development environment, with the implementation being done in Java.
Overview Writing articles is an important part of work for a researcher at a university or a content provider working for a media company. While writing research or news articles, the author often conducts searches on the World Wide Web (WWW) to unearth relevant information that can be used to write the article. However, when an author is writing an article, it is often a distraction to stop writing, visit a few search engines, conduct keyword searches, retrieve relevant information, and then incorporate it into the article. This is not very efficient, especially when the author has to deliver the article by a specific deadline. The motivation for developing a Multi-agent Research Tool (MART) was to develop a tool that helps authors to research while writing an article without wasting valuable time. This means that the research tool should not only be smart Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
324 DeLoach & Kumar
four steps. These steps include designing agent classes, developing conversation between the agents, assembling agents, and finally deploying the agents at system-level design.
Construction of Agent Classes The first step in the design phase involves designing the individual agent classes, which is documented in an Agent Class Diagram. In this step, the designer maps each role defined in the analysis phase to at least one agent class. Since roles are derived from the system goals and are responsible for achieving them, enforcing the constraint that each role is assigned to at least one agent class in the system helps to ensure that the goals are actually implemented in the system. In general, an agent class can be thought of as a template for creating the actual agent instances that will be part of the multi-agent system. These templates are defined in terms of the roles they play and the protocols they use to coordinate with other agents. The first step in constructing agent classes is to assign roles to the agent classes. If the designer chooses to assign more than one role to the same agent class, the roles may be performed either concurrently or sequentially. The assignment of roles to agents allows the multi-agent organization to be easily modified, since the roles can be manipulated modularly. This allows the designer to manipulate the design to account for various software engineering principles, such as functional or temporal cohesion. Once the agents are created by identifying the roles they will be playing, the conversations between agents are designed accordingly. For example, if two roles, R1 and R2, that shared a communication protocol were assigned to agent classes A1 and A2 respectively, then A1 and A2 would require a conversation (to implement the protocol) between them as well. The Agent Class Diagram that results from this step is similar to object-oriented class diagrams. They are different in that (1) agent classes are defined by the roles they play instead of their attributes and methods, and (2) the relationships between agent classes are always conversations.
Constructing Conversations Once the agent classes have been defined and the required conversations identified, the detailed design of the conversations is undertaken. These details are extracted from the communications protocols identified in the analysis phase.
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 Engineering
327
and efficient in conducting searches, but that it should also be able to work in the background and, at the same time, be non-intrusive to the user. Moreover, since use of the Internet has become commonplace, it is assumed that a person using MART has access to the Internet. It would be more useful if the research tool could use distributed computing to retrieve research material and present it to the user whenever he/she decides to view or use them. Based on the nature of the original motivation, it was decided to build MART as a multi-agent system since the location and numbers of the various components within the local network would not be known in advance. Since MART was developed using the MaSE methodology, the decision to use the agentTool development environment—a software engineering tool that directly supports MaSE analysis and design—was straightforward.
Developing Goals of the System In the first step of the Analysis Phase, the following goals were defined based on the requirements for the MART system, as presented above. As shown in Figure 1, the overall goal of the system is to produce the results of a search for keywords from the user’s article. This goal is partitioned into four subgoals: ranking and refining the keywords used in the search, searching the Web for results, producing and presenting the result to the user, and managing the entire system. The rank and refine search keywords goal is partitioned into two subgoals: reading user keywords and ranking the keywords. The goal, search the Web, is also partitioned; however, it has only one subgoal, namely, search Web sites. Although not technically required, this goal structure was adopted so that future versions could add additional goals that could include searching other types of Figure 1. MART system goals
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
328 DeLoach & Kumar
information sources such as databases located on the host computer and/or local network. Finally, the goal produce results is partitioned into three subgoals that allow for reading raw results, refining the raw results, and producing the final results that will be presented to the user.
Applying Use Case After defining the goals, three primary use cases were generated based on the three main subgoals (1.1, 1.2, and 1.3 in Figure 1). These use cases are Refine and Rank Keywords, Search the Web, and Generate Results. Each is presented in detail below.
Refine and Rank Keywords The Refine and Rank Keywords use case defines how the system should behave when it is initially asked to perform as search. As shown in Figure 2, the manager of the search process asks the reader to read the predefined user preferences and keywords and then asks the ranker to rank the keywords that were returned. The user preferences define exactly how the user prefers the search to be conducted while the keywords are the specific words on which the user wants the search to be conducted. These keywords are then ranked in terms of relevance to the article the user is currently writing.
Figure 2. Sequence diagram for “Refine and Rank Keywords” use case
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 Engineering
329
Figure 3. Sequence diagram for the use case “Search the Web”
Search the Web As shown in Figure 3, the Search the Web use case defines the basic search process of the system once a set of keywords has been developed. Each searcher agent is asked to search its known Web sites for a specific set of keywords. Exactly where and how each searcher conducts its search is not known to the manager. However, once results are received back by the searcher agents, the results are returned to the controller, who tabulates the results for a variety of searchers.
Generate Results The sequence diagram in Figure 4 shows that the manager, once it has the raw results, sends a message to the result generator along with the raw results. The result generator refines the results by extracting duplicates and providing proper formatting and then sends back the finished product back to the manager.
Figure 4. Sequence diagram for the use case “Generate results”
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
330 DeLoach & Kumar
Figure 5. MART role model
Refining Roles The role diagram depicts how the different goals are mapped to the roles of the system. Figure 5 shows that the controller has many tasks that collaborate with the other roles in order to read keywords, perform a search, and generate the finished product. The numbers inside rectangles (roles) indicate the goals for which they are responsible. For example, the Controller role is responsible for goal 1.4 from Figure 1, which is the goal of managing the system. As discussed above, the solid lines connecting the different roles represent the communication between the roles. The dotted line between tasks in the Sleuth role (the makeRaw protocol) shows that it is an internal communication between tasks within the same role instance (agent). The makeRawResults task is invoked by the rawResults task of the Sleuth once it receives the searchTheWeb request from the controller.
Concurrent Task Model Once the Role Model has been constructed, a concurrent task model was defined for each task in the role model. For example, showKeywords is a task for the KeywordsReader role. An example of a concurrent task model for showKeywords is shown in Figure 6. The task starts when a readPrefs message is received from an agent named controller. After receiving the message, the user preferences are read via the activity readPreferences() in the readPreferences state. Upon completion of the activity, the task enter the readKeywords state
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 Engineering
331
Figure 6. The showKeywords task for role KeywordsReader
where it gets the keywords from the user via the readKeywords() activity. If the keywords list is empty (null), then the task ends without sending a response. Otherwise, the task sends the set of keywords back to the controller.
Constructing Agent Classes After all the tasks from the Role Model have been defined via concurrent task diagrams, the analysis phase ended and the design phase commenced. The first step of the design phase is to define the basic system architecture using an Agent Class Diagram. The initial task was to create agent classes and assign them specific roles to play. The Agent Class Diagram shown in Figure 7 shows that MART has five different agents: AgentManager, AgentKey, AgentProducer, AgentGoogle, and AgentTeoma. The lines connecting the agents represent the conversations between the agents. For example, searchTheWeb is a conversation that is initiated by AgentManager. searchTheWeb is unique in that it exists between the AgentManager and two different agent types: AgentGoogle and AgentTeoma. Actually, both of these agent types implement the Sleuth role, and the conversation can be directed from the AgentManager to either agent type requesting them to conduct a search and return raw results. The agent classes in Figure 7 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 Engineering
335
Figure 12. Simplified UML class model for MART
design was implemented by integrating all the agent components into a single class (one class for each agent type). This resulted in the simplified class structure shown in Figure 12. The system architecture is shown in Figure 13, where each agent class is represented as a package. Obviously, multiple versions of each agent may exist. The KeyObjectPackage, which is accessed by each of the agents, includes shared definitions of data objects passed between agents. The diagram also includes a user-defined stereotype «conversation» to denote the existence of conversations between the various agent packages. The system was implemented using the agentMom agent-oriented middleware system, which inherently supports the concept of conversations as defined in MaSE (Mekprasertvit, 2004). Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
334 DeLoach & Kumar
Figure 11. Deployment diagram for MART
components do not communicate directly (they are derived from the showKeywords and rankedKeywords tasks in Figure 5), there is not a visibility connection between them. The last step in the design of the MART system was to develop the overall system deployment design. The MART Deployment Diagram, as shown in Figure 11, was created as an example of how the MART system could be deployed. As the MART system is designed to be deployed in a number of settings, this deployment is notional. Typically, the AgentKey and AgentManager agents are started on the user’s computer while the AgentGoogle and AgentTeoma agents must be pre-deployed on local network computers (the AgentProducer agent may be deployed anywhere on the local network as well).
Refining the Object Model After completing the analysis and design for MART, the implementation of the system began. As the system analysis and design was performed using agentTool, the first step was to verify that the conversations were correct and deadlock free. After this step was completed, the code generation capabilities of agentTool were employed to generate the initial code, which included stubs for each agent, each component, and each side of the conversations. Generally, each agent component is implemented as a single class. However, due to the simplicity of the components defined during the Assembling agents step, each agent class 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 Engineering
Figure 8.
Conversation model for rankKeywords Initiator
Figure 9.
Conversation model for rankKeywords Responder
333
Assembling Agents and Deployment After developing the conversations required for MART, the next step was constructing the individual components of the agent classes. As discussed earlier, there is a choice of either using either pre-existing agent architectures or creating an application-specific architecture. Because the MART agents were simple, it was decided that a simple application-specific architecture was the best approach for MART. Each concurrent task was mapped directly to an internal component in the architecture, thus making the internal agent design directly reflect the roles and tasks of the analysis model. An example of component structure of the AgentKey agent class is shown in Figure 10. The attributes and methods of the showKeywords component are derived directly from the showKeywords task defined in Figure 6, with the exception of the conv_r_readUserPreferences method. The conv_r_readUserPreferences method was created to initiate the readUserPreferences conversation. When the agent wants to start the readUserPreferences conversation, it calls the method, which contains all the implementation dependent code for handling the conversation. The rankedKeywords component was derived similarly. Because these two Figure 10. Components of AgentKey
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
336 DeLoach & Kumar
Figure 13. MART packages
Strengths and Weaknesses Strengths MaSE is a comprehensive methodology for building multi-agent systems. It has been used to develop both software multi-agent systems and multi-agent cooperative robotic systems (DeLoach, Matson, & Li, 2003). One of the major strengths of MaSE is that it provides guidance throughout the entire software development lifecycle—from requirements elicitation through to implementation. Firstly, MaSE is independent of any particular agent architecture or underlying environment. While the example above does not use pre-existing agent architectures, MaSE does allow the task and conversation behavior to be implemented in any architecture the designer wishes. For example, Robinson (2000) has defined a variety of agent architectures using MaSE components including reactive, BDI (Belief Desires and Intentions), knowledge-based, and planner based. The sequence of interrelated MaSE models allows the developer to track the mapping of entities from one model to the next. This is most readily apparent in the mapping of goals to roles, roles to agents, and communications protocols to conversations. This mapping allows the developer to move between models,
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 Engineering
337
showing that the entities defined in previous models are implemented successfully in the current model. It also provides an excellent tool for tracking down system errors. If a particular goal is not being successfully achieved, the developer can track that goal directly to the responsible role and then on the implementing agent classes. Often in multi-agent approaches, developers are allowed to specify behavior and agent communications protocols; however, the relationship between the two is not always clear. MaSE provides a way of directly defining the relationship between agent communication protocols and the internal behavior of the agent. This relationship is captured in the concurrent task diagrams and is carried over to agent conversation diagrams. By studying a set of concurrent tasks, it becomes evident how the communications between roles, and eventually agents, directly affects and is affected by the results of the communication. For instance, in Figure 6, it is clear that the computation (the readPreferences activity) starts after receiving the readPrefs message, and the results of the readKeywords activity determine whether the userKeywords message is even sent. MaSE is also supported by the agentTool development environment. AgentTool is a software engineering tool built to help designers create multi-agent systems using the MaSE methodology. Using agentTool, a multi-agent system can be developed by following the MaSE steps in both the analysis and design phases. Since agentTool is a graphical-based tool, all the diagrams and the models described in the MaSE methodology are created using the tool. During each step of system development, the various analysis and design diagrams are available via agentTool and the developer is allowed to move freely back and forth between models in the various MaSE steps. A developer may also use agentTool to verify a conversation at any point by using the conversation verification capability (Lacey & DeLoach, 2000), which uses the Spin model checker (Holzmann, 1997) to check for deadlocks, as well as non-progress loops, syntax errors, unused messages, or unused states. If an error exists, the verification results are presented textually to the developer as well as by directly highlighting the offending conversation diagram. AgentTool includes developing support for semi-automatic transformations that convert a set of analysis models into the appropriate design models (Sparkman, DeLoach, & Self, 2001). To initiate the process, the designer assigns roles to specific agent classes and then applies the semi-automated transformations. There are three transformation stages. In stage one, the transformations determine to which protocol individual concurrent task events belong. Next, the transformations create internal components for each concurrent task associated with the agent class. In the final stage, the conversations are extracted from the concurrent tasks and placed in conversation diagrams.
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
332 DeLoach & Kumar
Figure 7. MART agent class diagram
represent independent processes operating in their own thread of control. These agents could be placed on different machines and still be able to talk to each other using the conversations defined in the system.
Constructing Conversations After creating the agent classes and documenting them via the Agent Class Diagram, the individual communication between the agents was defined, based on the protocols between the appropriate roles from which they were derived. Each resulting conversation was documented using a pair of Conversation Diagrams, which are similar to and can be derived from the concurrent tasks models developed during the analysis phase (Sparkman, DeLoach, & Self, 2001). Each conversation is represented from the initiator’s and the responder’s points of view. For example, the conversation rankKeywords from the above diagram has the agent class AgentManager as the initiator and agent class AgentKey as the responder. The diagrams are show below in Figure 8 and Figure 9. Taken together, the diagrams show that the initiator sends the rankKey message with the parameter keywords to the responder and then waits until a rankedKey message is returned along with the ranked set of keywords via the message parameter. The responder side of the conversation is quite similar, with the messages sent by the initiator being received and the messages received by the initiator being sent. The obvious difference between the two is that the responder side includes an activity, rankKeywords(), that is called to actually perform the ranking process.
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
338 DeLoach & Kumar
Weaknesses While MaSE provides many advantages for building multi-agent systems, it is not perfect. It is based on a strong top-down software engineering mindset, which makes it difficult to use in some application areas. First, MaSE is not currently appropriate for the development of open multi-agent systems. Since MaSE predefines the communications protocols between agent classes, the resulting system assumes that any agents trying to participate in the system implicitly know what those protocols are. In addition, MaSE does not inherently support the use of different ontologies, although an extension to MaSE by DiLeo, Jacobs, and DeLoach (2002) does incorporate the notion of ontologies into MaSE and agentTool. In general, however, MaSE implicitly defines an ontology that is embedded in the task communication protocols and is implemented within each agent. The MaSE notion of conversations can also be somewhat bothersome, as they tend to decompose the protocols defined in the analysis phase into small, often extremely simple pieces when the original protocol involves more than two agents. This often results in conversations with only a single message. This makes comprehending how the individual conversations fit together more difficult. MaSE also tends to produce multi-agent systems with a fixed organization. Agents developed in MaSE tend to play a limited number of roles and have a limited ability to change those roles, regardless of their individual capabilities. Recent trends in multi-agent systems are towards the explicit design and use of organizations, which allow heterogeneous agents to work together within welldefined roles to achieve individual and system-level goals. In multi-agent teams, the use of roles and goals allows the agents to perform their duties in an efficient and effective manner that allows the team to optimize its overall performance. In most multi-agent design methodologies, including MaSE, the system designer analyzes the possible organizational structure and then designs one organization that will suffice for most anticipated scenarios. Unfortunately, in dynamic applications—where the environment as well as the agents may change—a designer can rarely account for or even consider all possible situations. Ideally, a multi-agent team would be able to design its own organization at runtime. To accomplish this, MaSE would have to be extended to be able to analyze and design multi-agent organizations. While MaSE already incorporates many of the required organizational concepts such as goals, roles, and the relations between these entities, it cannot currently be used to define a true multiagent 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
Multi-Agent Systems Engineering
339
Conclusions MaSE provides a detailed approach to the analysis and design of multi-agent systems. MaSE combines several established models into a comprehensive methodology. It also provides a set of transformation steps that shows how to derive new models from the existing models thus guiding the developer through the analysis and design process. MaSE has been successfully applied in many graduate-level projects as well as several research projects. The Multi-agent Distributed Goal Satisfaction Project used MaSE to design the collaborative agent framework to integrate different constraint satisfaction and planning systems. The Agent-Based Mixed-Initiative Collaboration Project also used MaSE to design a multi-agent system focused on distributed human and machine planning. MaSE has been used successfully to design an agent-based heterogeneous database system as well as a multi-agent approach to a biologically based computer virus-immune system. More recently, we applied MaSE to a team of autonomous, heterogeneous search and rescue robots (DeLoach, Matson, & Li, 2003). The MaSE approach and models worked very well. The concurrent tasks mapped nicely to the typical behaviors in robot architectures. MaSE also provided the high-level, top-down approach missing in many cooperative robot applications. Future work on MaSE will focus on specializing it for use in adaptive multi-agent and cooperative robotic systems based on an organizational theoretic approach. We are currently developing an organizational model that will provide the knowledge required for a team of software or hardware agents to adapt to changes in their environment and to organize and re-organize to accomplish team goals. Much of the information needed in this organizational model—goals, roles and agents—is already captured in MaSE. However, we will have to extend MaSE analysis to capture more detail on roles, including the capabilities required to play roles.
References DeLoach, S.A. (2000). Specifying agent behavior as concurrent tasks: Defining the behavior of social agents. Technical Report, U.S. Air Force Institute of Technology, AFIT/EN-TR-00-03. DeLoach, S.A., Matson, E.T., & Li, Y. (2003). Exploiting agent oriented software engineering in cooperative robotics search and rescue. The International Journal of Pattern Recognition and Artificial Intelligence, 17(5), 817-835. Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
340 DeLoach & Kumar
DeLoach, S.A., Wood, M.F., & Sparkman, C.H. (2001). Multiagent systems engineering. The International Journal of Software Engineering and Knowledge Engineering, 11(3), 231-258. DiLeo, J., Jacobs, T., & DeLoach, S.A. (2002). Integrating ontologies into multiagent systems engineering. In Proceedings of the Fourth International Bi-Conference Workshop on Agent-Oriented Information Systems (AOIS 2002) at AAMAS ’02, Bologna, Italy, July 16. Available from http://CEUR-WS.org/Vol-59 Holzmann, G.J. (1997). The model checker spin. IEEE Transactions on Software Engineering, 23(5), 279-295. Kendall, E. (1998). Agent roles and role models: New abstractions for multiagent system analysis and design. In Proceedings of the International Workshop on Intelligent Agents in Information and Process Management, Bremen, Germany, September. Lacey, T.H. & DeLoach, S.A. (2000). Automatic verification of multiagent conversations. In Proceedings of the 11th Annual Midwest Artificial Intelligence and Cognitive Science Conference, University of Arkansas, Fayetteville, April 15-16 (pp. 93-100). AAAI Press. Mekprasertvit, C. (2004). AgentMom user’s manual. Kansas State University. Retrieved June 30, 2004, from http://www.cis.ksu.edu/~sdeloach/ai/ software/agentMom_2.0/ Robinson, D. (2000). A component based approach to agent specification. Master’s Thesis. AFIT/GCS/ENG/00M-22. School of Engineering, Air Force Institute of Technology, Wright-Patterson AFB. Sparkman, C.H., DeLoach, S.A., & Self, A.L. (2001). Automated derivation of complex agent architectures from analysis specifications. In Proceedings of the Second International Workshop on Agent-Oriented Software Engineering, (AOSE 2001), Springer Lecture Notes in Computer Science (Vol. 2222, pp. 188-205). van Lamsweerde, A. & Letier, E. (2000). Handling obstacles in goal-oriented requirements engineering. IEEE Transactions on Software Engineering, 26(10), 978-1005.
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
342 Tran & Low
Introduction This chapter presents an evaluation and comparison of the 10 agent-oriented software engineering (AOSE) methodologies discussed in the preceding chapters. The objective is to assist researchers and practitioners in selecting the most appropriate methodology for a particular application. In order to achieve this, we discuss the similarities and differences between the methodologies, noting their strengths and weaknesses with regard to their support for multi-agent systems (MAS) development. This comparison is not a straightforward task, considering the heterogeneity of the methodologies in terms of their scope, approaches, terminology, development activities, and modelling notations. The evaluation and comparison are conducted using the feature analysis approach. Feature Analysis is the most common and cost-effective approach compared to other evaluation techniques such as survey, case study, and field experiment (Siau & Rossi, 1998). Feature analysis employs a checklist of evaluation criteria to assess and compare methodologies based on selected methodological features. We have adopted the feature analysis framework proposed by Tran, Low, and Williams (2003). This framework was developed from a synthesis of previous evaluation efforts and is capable of assessing AOSE methodologies from both the dimensions of conventional system development methodologies and those specific to AOSE. Its evaluation criteria are comprehensive, case-generic, and multi-dimensional, covering AOSE methodology’s process, techniques, and models. We will describe the evaluation framework in more detail in the next section. The section entitled “Comparative Analysis” presents the evaluation and comparison of the 10 AOSE methodologies, using the framework.
The Evaluation Framework The selected evaluation framework was formed by identifying and integrating the evaluation criteria from various feature analysis frameworks, including those for assessing conventional system development methodologies – namely Wood, Pethia, Gold, and Firth (1988), Jayaratna (1994), Olle, Sol, and Tully (1983), and the Object Agency Inc. (1995), and those for evaluating AOSE methodologies – namely Shehory and Sturm (2001), O’Malley and DeLoach (2001), Cernuzzi and Rossi (2002), and Sabas, Badri, and Delisle (2002). The former category provides a well-established list of generic system engineering features to be
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
Comparison of Ten Agent-Oriented Methodologies
341
Chapter XII
Comparison of Ten Agent-Oriented Methodologies Quynh-Nhu Numi Tran University of New South Wales, Australia Graham C. Low University of New South Wales, Australia
Abstract This chapter provides a comparison of the 10 agent-oriented software engineering methodologies presented in the preceding chapters. An evaluation framework comprising process-related, technique-related, modelrelated and supportive-feature criteria is used in this comparison. As each application entails a different set of requirements that indicate which evaluation criteria are the most important and should be supported by the chosen methodology, the “best” methodology is dependent on the target application. The results provide a useful framework to assist the developer in selecting the most appropriate methodology for any target application.
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
344 Tran & Low
•
Development lifecycle: What development lifecycle best describes the methodology (e.g., waterfall or iterative)?
•
Coverage of the lifecycle: What phases of the lifecycle are covered by the methodology (e.g., analysis, design, and implementation)?
•
Development perspective: What development perspective is supported (i.e., top-down, bottom-up or hybrid)?
•
Application domain: Is the methodology applicable to any application domain (i.e., domain independent) or to a specific domain (i.e., domain dependent)?
•
Size of MAS: To what size of MAS is the methodology suited (i.e., small, medium, or large MAS)?
•
Agent nature: Does the methodology support agents of any architecture, reasoning mechanism, and/or knowledge representation (i.e., heterogeneous agents), or only agents of a particular type (i.e., homogeneous agents)?
•
Support for verification and validation: Does the development process of the methodology contain rules to allow for the verification and validation of the correctness of the developed models and specifications?
•
Steps in the development process: What are the steps (i.e., tasks and activities) that the methodology specifies for its development process?
•
Models and notational components: What models (and/or notational components) are generated from each step?
•
Definition of inputs and outputs: Are inputs and outputs to each process step defined?
•
Ease of understanding of the process steps: Are the process steps easy to understand?
•
Usability of the methodology: Are the process steps easy to follow?
•
Refinability: Do the process steps provide a clear path for refining the methodology’s models through gradual stages to reach an implementation or, at least, for clearly connecting the implementation level to the design specification?
•
Approach towards MAS development: What is the methodology’s: a.
generic MAS development approach (e.g., OO approach or knowledge-engineering approach)?
b.
approach towards using “role” in MAS development? Does the methodology employ the concept of “role” in MAS analysis and design? If so, what is the approach to the identification of roles (e.g., goal-oriented approach, behaviour-oriented approach, or organization-oriented approach)?
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
Comparison of Ten Agent-Oriented Methodologies
343
Figure 1. Structure of the evaluation framework Fe ature Analysis Framework Process Related Criteria
Technique Related Criteria
Model Related Criteria
Supportive Feature Criteria
considered, while the latter presents various agent-oriented and MAS-specific aspects for assessment. We have also added several evaluation criteria that are not yet included in existing frameworks, for example, “approach towards MAS development,” “support for mobile agents,” and “support for ontology.” A survey had been conducted to substantiate the relevance of the proposed criteria and to make the necessary refinements to the criteria specification. The structure of the framework is shown in Figure 1. Its criteria are grouped into four categories: •
Process-Related Criteria: evaluating an AOSE methodology’s development process.
•
Technique-Related Criteria: assessing the methodology’s techniques to perform development steps and/or to produce models and notational components.
•
Model-Related Criteria: examining the capabilities and characteristics of the methodology’s models and notational components.1
•
Supportive-Feature Criteria: evaluating a variety of high-level methodological capabilities.
This structure highlights the framework’s attention to all three major components of a system development methodology—process, models, and techniques. Each evaluation criterion is accompanied by one or more questions to guide and assist the evaluator. A detailed specification of the criteria is presented below.
Process-Related Criteria Process-Related Criteria look at the applicability of the methodology, the steps provided for its development process, and the development approach followed by the methodology.
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
346 Tran & Low
the quality of notational components, and the agent characteristics supported by the models. •
Concepts: What concepts are the methodology’s models capable of expressing/capturing?
•
Completeness/Expressiveness: Are the models of the methodology capable of representing the system from different perspectives, capturing all necessary aspects such as static and dynamic aspects, and system- and agent-level aspects?
•
Formalization/Preciseness of notational components: a.
Are syntax and semantics of the notational components clearly defined?
b.
Are examples of the notational components presented?
•
Model derivation: Do explicit process and guidelines exist for transforming models into other models or for partially creating a model from information present in another model?
•
Consistency:
•
a.
Are there rules and guidelines to ensure consistency between the levels of abstractions within each model (i.e., internal consistency) and between different models?
b.
Are models represented in a manner that allows for consistency checking between them?
Complexity: a.
Is there a manageable number of concepts expressed in each model/ notational component?
b.
Are the notational components notation semantically and syntactically simple?
•
Ease of understanding of models: Are the models and notational components clear and easy to understand?
•
Modularity: Does the methodology and its models promote modularity in the design of agents and the system?
•
Abstraction: Does the methodology allow for producing models at various levels of detail and/or abstraction?
•
Autonomy: Can the models support and represent the autonomous feature of agents (i.e., the ability to act without direct intervention of humans or others, and to control their own states and behaviour)?
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
Comparison of Ten Agent-Oriented Methodologies
345
Since different evaluators may use different terms and/or descriptions of the steps expected from an AOSE methodology, it was deemed advisable to provide a “standard” framework of process steps that serves as an assessment checklist for the criterion “Steps in the development process.” This framework would provide a means of ensuring consistency not only between different evaluators of the same methodology but also for the comparative analysis of different methodologies. To date, no study has been found that identifies this “standard” framework of steps. We investigated the development process of the existing AOSE methodologies. We extracted the major steps from each development process and synthesize them into a coherent super list. To verify the validity of our recommended steps, we conducted a survey of experts for their opinions on the importance of these steps. The survey confirmed the importance of all the proposed steps to the development of MAS. The proposed list of AOSE steps is used in Tables 2a to 2j (in the section “Comparison regarding Steps and Techniques Related Criteria”) as a “yardstick” for evaluating and comparing the 10 methodologies in terms of the criterion, “Steps in the development process.”
Technique-Related Criteria Technique-Related Criteria assess the availability and usability of the techniques provided by a methodology for the execution of its process steps and/or for the development of its models and notational components. •
Availability of techniques and heuristics: a.
What are the techniques used to perform each process step?
b.
What are the techniques used to produce each model and notational component (i.e., modelling techniques)?
•
Ease of understanding of techniques: Are the techniques easy to understand?
•
Usability of techniques: Are the techniques easy to follow?
•
Provision of examples: Are examples of the techniques provided?
Model-Related Criteria Model Related Criteria evaluate the various aspects of a methodology’s models and notational components, including the concepts represented by the models, Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
Comparison of Ten Agent-Oriented Methodologies
347
•
Adaptability: Can the models support and represent the adaptability feature of agents (i.e., the ability to learn and improve with experience)?
•
Cooperative behaviour: Can the models support and represent the cooperative behaviour of agents (i.e., the ability to work together with other agents to achieve a common goal)?
•
Inferential capability: Can the models support and represent the inferential capability feature of agents (i.e., the ability to reason and act on abstract task specifications)?
•
Communication ability: Can the models support and represent a “knowledge-level” communication ability (i.e., the ability to communicate with other agents with language resembling human-like speech acts)?
•
Personality: Can the models support and represent the personality of agents (i.e., the ability to manifest attributes of a “believable” human character)?
•
Reactivity: Can the models support and represent the reactivity of agents (i.e., the ability to selectively sense and act in a timely manner)?
•
Temporal continuity: Can the models support and represent temporal continuity of agents (i.e. persistence of identity and state over long periods of time)?
•
Deliberative behaviour: Can the models support and represent the deliberative behaviour of agents (i.e., the ability to decide in a deliberation, or proactiveness)?
•
Concurrency: Can the models support and represent the concurrency in agent processing (e.g., achievement of concurrent goals or participation in concurrent interactions)?
•
Human Computer Interaction: Do the models represent human users and the user interface?
•
Models Reuse: Does the methodology provide, or make it possible to use, a library of reusable models?
Among the 21 Model-Related Criteria, “concepts” is the most complicated criterion, since different evaluators may have different descriptions of the concepts modelled by the same AOSE methodology. As such, an evaluator would appreciate the existence of a “standard” framework of AOSE concepts that serves as an assessment checklist for the evaluation. Similar to the “standard” framework of steps in the “Process Related Criteria” section, the research determined a set of concepts that are commonly modelled by AOSE methodologies, and conducted a survey of AOSE practitioners and
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
348 Tran & Low
experts 2 to confirm the importance of the proposed concepts to the MAS development process. The proposed list of concepts is used in Table 4 (section “Comparison regarding Model Related Criteria”) as a “yardstick” for evaluating and comparing the 10 methodologies in terms of criterion “concepts.”
Supportive-Feature Criteria Supportive-Feature Criteria assess the various high-level, supplementary features of an AOSE methodology. The features considered include the availability of software tools and the support for ontology, mobile agents, and open systems. •
Software and methodological support: Is the methodology supported by tools and libraries?
•
Open systems: Does the methodology provide support for open systems (i.e., open systems that allow for dynamic addition/removal of agents)?
•
Dynamic structure: Does the methodology provide support for dynamic structure (i.e., the methodology allows for dynamic reconfiguration of the system)?
•
Agility and robustness: Does the methodology provide support for agility and robustness (e.g., the methodology captures normal processing and exception processing, provides techniques to analyze system performance for all configurations, or provides techniques to detect and recover from failures)?
•
Support for conventional objects: Does the methodology provide support for the use/integration of conventional objects in an MAS (e.g., the methodology addresses how objects can be used in an MAS and how agents can interface with these objects)?
•
Support for mobile agents: Does the methodology provide support for the use/integration of mobile agents in a MAS (e.g., the methodology models which/when/how agent should be mobile)?
•
Support for ontology: Does the methodology provide support for the use and specification of ontology in an MAS (i.e., ontology-based agent systems)?
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
Comparison of Ten Agent-Oriented Methodologies
349
Comparative Analysis Comparison Regarding Process-Related Criteria In this section, the 10 AOSE methodologies are evaluated and compared using the set of Process-Related Criteria listed in section “Process Related Criteria,” except for criteria “Steps in the development process,” “Models and notational components,” and “Definition of inputs and outputs,” which will be discussed alongside the Technique-Related Criteria in the section entitled, “Comparison regarding Steps and Techniques Related Criteria.” The results of the comparative analysis are summarised in Table 1. The 10 methodologies either adopt a formally defined, prominent development lifecycle (e.g., ADELFE, RAP, MESSAGE, and INGENIAS) or informally describe their lifecycle paradigm (e.g., GAIA, TROPOS, PROMETHEUS, and MASE). In both cases, the development process of all methodologies involves a high degree of iteration within and/or across the development phases. INGENIAS is found to provide the best support for refinability, as all of its models are incrementally refined and expanded throughout the Analysis and Design phases to reach an implementation. All other methodologies develop different models during different phases of their development process. However, they all provide a path or, at least, encourage the need for refining these models within the corresponding phase. With regard to the generic MAS development approach (i.e., Part a. of the criterion “Approach towards MAS development”), most methodologies follow the object-oriented-based approach (denoted as “OO”); that is, they take inspiration from the OO paradigm and seek to adapt or extend the conventional OO approaches and techniques (e.g., use cases, interaction protocol modelling, and design patterns) and/or OO modelling notation (e.g., UML and OMT) (Iglesias, Garijo, &Gonzalez, 1999). MAS-CommonKADS is the only methodology that adopts the knowledge-engineering-based approach (denoted as “KE”), meaning it borrows techniques from the knowledge-engineering literature. TROPOS is an exception because it is built upon the i* modelling framework developed by Yu (1995). Regarding the approach towards using “role” in MAS development (i.e., Part b. of the criterion “Approach towards MAS development”), we classified an AOSE methodology as non-role-oriented (“NRO”) if it does not involve the use of the concept “role” anywhere in the MAS development process. A roleoriented (“RO”) methodology, on the other hand, employs “role” as a major modelling concept. For RO methodologies, we identified the approach used by
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
Heterogeneous
Independent (e-business systems, knowledge management, health IS)
Not specified BDI-like agents
Independent (business process management, GIS, traffic simulation)
<= 100 agent classes
Heterogeneous
Application domain
Size of MAS
Agent nature
Approach towards MAS development
Refinability
Usability of the methodology
Support for verification and validation Ease of understanding of the process steps
Not specified, but possibly any size
Top-down
Top-down
Development perspective
a. OO b. RO (OrO)
Yes a. i* modelling framework b. NRO
Yes
Medium
a. KE b. NRO
Yes
Medium
High
High
High
Medium
Mentioned but no explicit steps/guidelines provided
Yes
Independent (Flight reservation, automatic control)
Hybrid
Analysis and Design
No
Analysis and Design
Analysis and Design
Coverage of the lifecycle
Cyclic risk-driven process
Iterative and incremental
Iterative within each phase but sequential between phases
Development lifecycle
MASCOMMONAKADS
TROPOS
GAIA
a. OO b. NRO
Yes a. OO b. RO
Yes
High
High
High
High
Yes
Heterogeneous
Not specified
Independent (distributed robotics applications, online bookstore)
a. OO b. NRO
Yes
a. OO b. RO (GO)
Yes
High
High
High
High
Yes
Yes
a. OO b. RO
Yes
Medium
High
No
Reactive agents
Adaptive
Not specified but possibly heterogeneous
a. OO b. RO (GO and BO)
Yes
Medium
High
Mentioned as future enhancement
Heterogeneous
a. OO b. RO
Yes
High
High
Yes
Agents with goals and states
Not specified, but possibly any size
Not specified, but possibly any size Any size
<= 10 agent classes
Not specified, but possibly any size
Independent (collaborative information filtering, personal computer management, robot battles)
Independent (network management, operational support systems, knowledge management systems)
Independent (distributed planning, database integration system, computer virus immune system, automatic control )
Dependent adaptive systems (adaptive intranet system, timetabling system)
Dependent – distributed organizational IS (supply chain management, enterprise resource planning)
Hybrid
Analysis, Design and Implementation
Unified software development process
INGENIAS
Hybrid
Analysis and Design
RUP
MESSAGE
Hybrid
Analysis and Design
RUP
RAP
Top-down
Analysis and Design
Iterative across all phases
MASE
Top-down
Analysis, Design and Implementation
Analysis, Design and Implementation Bottom-up
Rational Unified Process (RUP)
ADELFE
Iterative across and within all phases (except for coding and deployment)
PASSI
Yes
BDI-like agents
Any size
Independent ( holonic manufacturing, online bookstore)
Bottom-up
Analysis and Design
Iterative across all phases
PROMETHEUS
350 Tran & Low
Table 1. Comparison regarding process-related criteria
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
Comparison of Ten Agent-Oriented Methodologies
351
the methodologies to identify roles (cited within parentheses in Table 1). Three potential approaches for role identification are: •
Goal-Oriented approach (“GO”), where roles are identified from the analysis of system goals;
•
Behaviour-Oriented approach (“BO”), where roles are derived from lowlevel system behaviours and tasks; and
•
Organization-Oriented approach (“OrO”), where roles are revealed from system organizational structure.
Comparison Regarding Steps and Techniques-Related Criteria In this section, the 10 methodologies are compared according to the four Technique- Related Criteria (presented in the section of the same name) and the three remaining Process- Related Criteria (i.e., “Steps in the development process,” “Models and notational components,” and “Definition of inputs and outputs”). The evaluation of techniques is coupled with the assessment of each step and each model because techniques are typically provided in conjunction with steps and models. Tables 2a to 2j present our evaluation findings for each of the 10 AOSE methodologies. The columns represent the evaluation criteria, except for the first column, which lists a set of “Steps” that serve as an assessment checklist. These steps have been mentioned in the “Process-Related Criteria” section as the “standard” steps for the MAS development process. It should be noted that these steps are not presented in any order. Different methodologies may perform the steps in different chronological order and in different phases. If a methodology is found to support a particular step, this support is denoted as either Explicit (“E”) or Implicit (“I”). The former applies if the methodology specifies the step as a significant, distinct activity in its development process. The latter incurs when the step is implicitly fulfilled as part of another step or only briefly mentioned by the methodology. If a step is implicit, there may not be sufficient information for us to evaluate the remaining Technique-Related Criteria, such as “Availability of techniques [for step]” or “Usability of techniques [for step]” (these fields are therefore left blank). If a step is supported in conjunction with (or as part of) another step, this other step will be indicated in the square brackets []. If an AOSE methodology contains a significant step that is not included in the list, this step will be added as an “Extra” item at the bottom of the list.
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
352 Tran & Low
Table 2a. Evaluation of GAIA steps and techniques
B
5. Identify agent classes 6. Model domain conceptualization 7. Specify acquaintances between agent classes
E
E
8. Define interaction protocols
9. Define content of exchanged messages 10.Specify agent architecture 11.Define agent mental attitudes (e.g. goals, beliefs, plans, commitments …) 12.Define agent behavioural interface (e.g. capabilities, services, contracts…) 13.Specify system architecture (i.e. overview of all components and their connections) 14.Specify organizational structure/control regime/inter-agent social relationships 15.Model MAS environment (e.g. resources, facilities, characteristics) 16.Specify agentenvironment interaction mechanism 17.Specify agent inheritance and aggregation
18.Instantiate agent classes
Acquaintance model
B
B
E
Interaction model
O
E
Service model
B
E
Organizational structure model
B
E
Environmental model
B
I[5]
Agent model
B
E [5]
Agent model
O
E
Organizational rules specifications
I[15]
19.Specify agent instances deployment Extra: Specify organizational rules
Extra: Identify initial suborganizations
Agent model
E
B
B
Identify roles from individuals, departments/offices or suborganizations in the target system
Model each role by its “responsibilities” (including “liveness” and “safety”) and “permissions” Show identifier of agent classes and their respective roles
Typically one-to-one mapping between roles and agent classes Identify acquaintances from Role, Agent and (inter-role) Interaction models Only specifies protocols for interrole interactions. Each protocol defines an institutionalized pattern of interaction with no detailed sequences of exchanged messages
Show agent classes and communication paths between them Specify purpose, initiator, responder, inputs, outputs and (informal) processing description for each inter-role protocol
Identify agents’ services by analyzing their roles’ responsibilities, actions and protocols.
Show inputs, outputs, precondition, and post-condition for each agent’s service
Choose a structure that optimizes the organizational efficiency and simplicity, respects organizational rules, and reflects the structure of real world organization. Identify abstract computational resources (e.g. tuples/variables) that are available to agents for sensing, effecting or consuming Implicitly indicates that agents interact with environment via sensors and affectuators. No additional information provided Aggregation occurs when an agent class is composed of the roles that make up other agent classes. Does not consider inheritance
Specify organizational dependencies between roles
Identify rules that must be respected by the organization for it to work coherently, and specify how the dynamics of the organization should evolve over time. Can refer to roles’ safety and liveness responsibilities. At the beginning of Analysis, determine whether multiple organizations have to co-exist in the system and become autonomous interacting MASs
Specify a symbolic name, types of actions permitted on each environmental resource and their textual/structural descriptions
Show an aggregate agent class as the parent of the children classes in the tree structure of Agent model Specify numbers of instances for each agent class by annotating the class with qualifiers from Fusion
Examples
Role model
Each liveness responsibility is made up of “actions” and/or “protocols”
Usability
E
3. Specify use case scenarios 4. Identify roles
Specified as “liveness responsibilities” of roles
Ease of
O
understanding
Role model
Techniques for modelling
I [4]
Techniques for step
Inputs/ Outputs?
1. Identify system goals 2. Identify system tasks/behaviour
Models/ Notational components?
Steps
Supported?
GAIA
H
M
Y
H
H
Y
H
H
Y
H
M
Y
H
H
Y
H
H
Y
H
H
Y
H
M
Y
H
H
N
H
M
Y
H
H
Y
H
H
Y
Model safety and liveness organizational rules
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
Comparison of Ten Agent-Oriented Methodologies
355
Table 2d. Evaluation of PROMETHEUS steps and techniques
E
Functionality descriptor
B
E
Use case descriptor
B
E
Agent class descriptor
B
E
Interaction diagrams
B
E[7]
Interaction protocols
B
4. Identify roles 5. Identify agent classes
6. Model domain conceptualization 7. Specify acquaintances between agent classes
8. Define interaction protocols
9. Define content of exchanged messages
I [7, 8]
10.Specify agent architecture E 11.Define agent mental attitudes (e.g., goals, beliefs, plans, commitments …) 12.Define agent behavioural interface (e.g., capabilities, services, contracts…) 13.Specify system architecture (i.e. , overview of all components and their connections) 14.Specify organizational structure/control regime/interagent social relationships 15.Model MAS environment (e.g., resources, facilities, characteristics) 16.Specify agent-environment interaction mechanism 17.Specify agent inheritance and aggregation 18.Instantiate agent classes 19.Specify agent instances deployment
Interaction diagrams and protocols Agent overview diagram
B
Plan descriptor, Data descriptor
B
E
Capability diagram
B
E
System overview diagram
B
E
E
I[5]
System overview diagram Percepts descriptor, Actions descriptor Agent class descriptor
O
B
O
Examples
understanding
H
H
Y
Describe each functionality in terms of its goals, actions, percepts/events and potential data read/written
H
H
Y
Annotate each step with associated functionality and data read/written
H
H
Y
Assign functionalites to agent class based on the criteria of strong coherence and loose coupling
Describe each agent class in terms of its functionalites, goals, events, actions, and data read/written, cardinality, agent lifetime).
H
H
Y
Whenever there is a step in a use case that involves functionality from a new agent, there must be an interaction pathway from a previously involved agent and this new agent Elaborate each complex interaction with protocol by analyzing use case scenarios
Show the core interaction channels between agents using sequence diagrams
H
H
Y
H
H
Y
H
L
Y
H
H
Y
H
H
Y
H
H
Y
H
H
Y
H
M
Y
H
H
Y
H
L
N
Capture initial goals from high-level system description and decompose these goals into subgoals Identify a set of functionalities by considering groupings of goals. Identify sequences of steps that describe how the system achieves a goal or responds to an event
Analyze use case scenarios
B
E[12]
Techniques for modelling
B
Techniques for step
Goal diagram
Usability
3. Specify use case scenarios
E
Ease of
2. Identify system tasks/ behaviour
Inputs/ Outputs?
1. Identify system goals
Models/ Notational components?
Steps
Supported?
PROMETHEUS
Recursively decompose each agent’s capability (step 12) into plans, events connecting plans, data read/written by plans and sub-capabilities. Identify agent “capabilities” by analyzing functionalities assigned to the agent Describe how the system as a whole will function
There may be data objects existing in the environment that must be shared among agents (e.g. , databases) Specify raw data available to the system as “percepts” and activities performed by the system on the environment as “actions”
Show all variations of interaction sequences that are valid in the system. Each protocol may be split into smaller chunks
Show the top-level view of an agent’s internals, including toplevel capabilities, events connecting these capabilities, and data objects internal to the agent Describe each agent “plan” in terms of input/output events, actions and messages. Describe each “data object” used by the agent with fields and methods. Describe each capability in terms of subcapabilities, plans, events and data read/written in Capability diagram Show an overview of all agent classes in the system, messages connecting classes, shared data objects and percepts/actions with the environment
Show and link shared data objects to agents in System overview diagram Specify percepts and actions for each system functionality in Percepts and Actions descriptors
Specify cardinality for each agent in its Agent class descriptor
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
Comparison of Ten Agent-Oriented Methodologies
353
Table 2b. Evaluation of TROPOS steps and techniques
3. Specify use case scenarios 4. Identify roles 5. Identify agent classes
6. Model domain conceptualization 7. Specify acquaintances between agent classes
E
Actor diagram
B
E
Sequence diagrams, Collaboration diagrams
B
Sequence diagrams
B
8. Define interaction protocols E[7] 9. Define content of exchanged messages 10.Specify agent architecture
Show sub-actors within each system actor and goal/task/resource dependencies among them
Identify interactions between agents to fulfil particular tasks Elaborate each inter-agent interaction in greater detail (e.g., by introducing additional or refined exchanged messages)
I[7,8] I
11.Define agent mental attitudes (e.g., goals, beliefs, plans, commitments …)
BDI agent architecture
E
Plan diagrams, Agent class diagram
B
12.Define agent behavioural interface (e.g., capabilities, services, contracts…) 13.Specify system architecture (i.e., overview of all components and their connections) 14.Specify organizational structure/control regime/interagent social relationships
E
Nonfunctional requirement model
B
I[1,2]
Actor diagram
B
15.Model MAS environment (e.g., resources, facilities, characteristics)
Depending on the chosen organizational structure (step 14), decompose the system into subactors, each of which can be recursively refined into sub-actors (can consult catalogues of agent patterns for this activity). Assign subactors to agents.
16.Specify agent-environment interaction mechanism 17.Specify agent inheritance and aggregation 18.Instantiate agent classes 19.Specify agent instances deployment Extra: Implementation E
BDI agents
B
TROPOS adopts BDI model for agent architecture Define agent’s “plans” to achieve a goal, perform a task, or respond to a (communicative) event. Identify resource entities that are incorporated in the agent’s knowledge base
Select a suitable organizational structure style (e.g., from the set proposed by TROPOS) by evaluating its quality attributes against the system’s softgoals.
Generate BDI agents by mapping agent’s resources, goal/softgoal, and plans onto BDI agent belief, desire, and intentions, which can in turn be directly implemented by JACK database relations, Goal Event, and Plans.
Examples
B
Usability
Actor diagram, Rationale diagram
Show goal dependencies among stakeholders and system in Actor diagram. Show how goals can be fulfilled (through subgoals, tasks, and goal/task/resource dependencies) in Rationale diagram. Show task dependencies among stakeholders and system in Actor diagram. Show how goals are achieved through tasks in Rationale diagram.
understanding
E[1]
In Early Requirements, identify goals and softgoals of stakeholders, and perform means-end analysis to determine how these goals can be fulfilled. In Late Requirements, focus on the target system and how it can fulfil the assigned goals. Perform means-end analysis to identify tasks to achieve goals during both Early and Late Requirements
Ease of
2. Identify system tasks/behaviour
Techniques for modelling
B
1. Identify system goals
Techniques for step
E
Actor diagram, Rationale diagram
Inputs/ Outputs?
Models/ Notational components?
Steps
Supported?
TROPOS
H
H
Y
H
H
Y
H
H
Y
H
M
Y
H
H
Y
Model each message as a communication act in ACL
H
M
Y
Specify Plan diagrams at a directly executable level. Represent resource entities as component classes of an agent class in Agent class diagram
H
M
Y
H
H
Y
H
H
Y
H
H
Y
Specify how well each alternative organizational structure style fulfils the system’s softgoals Model environment via stakeholders and their goal/ task/resource dependencies with the 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
356 Tran & Low
Table 2e. Evaluation of PASSI steps and techniques
1. Identify system goals 2. Identify system tasks/behaviour 3. Specify use case scenarios
E
System requirements model, Agent society model
B
E
System requirement model
B
E
Agent society model
O
I[5]
System requirement model
B
E
Agent society model
B
I
Agent implementati on model
B
E
Agent implementati on model
B
4. Identify roles
5. Identify agent classes 6. Model domain conceptualization 7. Specify acquaintances between agent classes 8. Define interaction protocols
9. Define content of exchanged messages
10.Specify agent architecture
11.Define agent mental attitudes (e.g. , goals, beliefs, plans) 12.Define agent behavioural interface (e.g., capabilities, services)
13.Specify system architecture 14.Specify organizational structure/inter-agent social relationships 15.Model MAS environment 16.Specify agent-environment interaction mechanism 17.Specify agent inheritance and aggregation 18.Instantiate agent classes 19.Specify agent instances deployment Extra: Code reuse, code completion
I[10]
E
Agent implementati on model System requirements model, Agent implementati on model
B
B
E
Agent implementati on model
B
E
Deployment model
O
E
Code model
B
Identify roles for each agent by exploring all the possible scenarios of inter-agent interaction (captured in Agent identification diagram – step 5)
Package use cases into agents Specify concepts/entities that define the domain’s knowledge.
Select and refine protocol for each agent acquaintance by consulting e.g., FIPA library. Should also specify the ontology used with the protocol Specify messages’ performatives as required by the interaction protocol (step 8), and messages’ contents by using concepts defined in Domain ontology diagram. Define agent structure as being composed of one main agent class and a set of inner classes, each representing a task of the agent Specify agent “knowledge” by using the concepts defined in Domain ontology diagram (step 6) Agent’s capabilities are represented by its tasks, which can be identified by analyzing its roles and interactions described in Role identification diagrams (step 4)
Try to reuse predefined patterns of agents and tasks
Examples
B
Usability
System requirements model
Ease of
E[2]
Follow standard requirements elicitation techniques in OO or scenario-based teleological methods such as GBRAM
understanding
O
Techniques for modelling
System requirements model
Techniques for step
E
Inputs/ Outputs?
Models/ Notational components?
Steps
Supported?
PASSI
Specify functionality as use cases in Use case diagrams Develop a hierarchical series of use case diagrams. The uppermost serves as a context diagram For each inter-agent interaction scenario, develop a Role identification diagram to specify the roles that agents play during the interaction. Describe roles with a Role description diagram, which shows their agents, role changes within an agent, roles’ tasks, roles’ interactions and dependencies. Show agents, their respective use cases, and interaction paths between use cases in Agent identification diagram Represent domain ontology as an XML schema or class diagram in Domain ontology diagram Agent acquaintances are reflected via the interaction paths between use cases in Agent identification diagram Document each protocol in Protocol description diagram (which may be AUML sequence diagram). Specify identifier of protocol and ontology for each agent acquaintance in Communication ontology diagram. Model exchanged messages (including their performatives and contents) as transitions between agents in the Multiagent behaviour description diagram Specify data structures and methods of the agent and its tasks in the main agent class and task classes respectively. Model knowledge as agent data structures in Single-agent structure definition diagram Show all tasks of an agent in a Task specification diagram. Further describe each method required to achieve each task in Single-agent behaviour description (using flow charts, state diagrams or text description) Show all agent classes, their knowledge, tasks and connections with external actors in Multi-agent structure diagram
Show processing units, agents in each unit, agent movements, and units/agents connections in Deployment configuration diagram.
H
H
Y
H
H
Y
H
M
Y
H
M
Y
H
H
Y
H
H
Y
H
H
Y
H
H
Y
H
M
Y
H
H
Y
H
H
Y
H
L
N
H
M
N
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
354 Tran & Low
Table 2c. Evaluation of MAS-COMMONKADS steps and techniques
Task model
O
E
Use case
B
E
Agent model
B
E [11]
Expertise model
O
3. Specify use case scenarios
4. Identify roles 5. Identify agent classes
6. Model domain conceptualization 7. Specify acquaintances between agent classes
E
Coordination model
B
E[7]
Coordination model
B
E[8]
Coordination model
B
8. Define interaction protocols
9. Define content of exchanged messages 10.Specify agent architecture
11.Define agent mental attitudes (e.g. , goals, beliefs, plans, commitments …) 12.Define agent behavioural interface (e.g., capabilities, services, contracts…) 13.Specify system architecture (i.e. , overview of all components and their connections) 14.Specify organizational structure/control regime/interagent social relationships 15.Model MAS environment (e.g. , resources, facilities, characteristics)
E
Design model
B
E
Expertise model
B
I
Agent model; Organization model
O
E
Organisation model
B
I
Organisation model
E
16.Specify agent-environment interaction mechanism 17.Specify agent inheritance and aggregation
18.Instantiate agent classes 19.Specify agent instances deployment
Reaction cases; Design model
B
E [13]
Organisation model
B
I [13]
Organisation model
O
Perform user-centered analysis during Conceptualization phase to identify potential users and how the system processes a user request Analyze various sources e.g., use cases, statement problems, heuristics, initial Task and Expertise models Specify domain conceptualization as agent’s domain knowledge Identify prototypical conversations between agents by analyzing the results of techniques used for identifying agents (e.g., use cases, heuristics, task model, CRC cards). Identify protocols for complex conversations by consulting existing libraries and reuse protocol definitions Analyze use cases and Expertise model Select an appropriate architecture and map the elements defined in Coordination, Expertise, Agent and Task models onto modules of the architecture. No techniques or models are discussed Specify domain knowledge, task knowledge, inference knowledge and problem solving knowledge for each agent
Perform environment-centered analysis during Conceptualization phase to identify objects in the environment and potential events coming from each object and actions performed by agents on each object. Identify networking, knowledge and coordination facilities.
Specify aggregation relationships for agent groups, and inheritance relationships for agents that inherit from the values of the precedent agents Mentioned but no techniques discussed
Examples
E
Usability
2. Identify system tasks/behaviour
Perform responsibility/goal-driven analysis during Conceptualization phase to identify responsibilities (goals) of the system Decompose tasks following a topdown approach
Ease of
B
understanding
Goal case
Techniques for modelling
Inputs/ Outputs?
E
1. Identify system goals
Techniques for step
Models/ Notational components?
Steps
Supported?
MAS-COMMONKADS
H
H
Y
Show tasks in an and/or tree. Describe each task in terms of inputs, outputs, task structure, required capabilities of performer and preconditions.
H
H
N
Conventional OO techniques
H
H
Y
H
M
Y
H
M
Y
H
H
Y
H
H
Y
H
H
Y
H
L
N
H
M
Y
H
L
Y
H
M
Y
H
L
Y
H
M
N
H
M
Y
H
L
N
Describe each goal with type, activiation/deactivation condition and success/failure condition.
Describe each agent in terms of type, role, position, description, services, goals, plans, knowledge, collaborates, skills, reasoning capabilities, general capabilities norms, preferences and permissions. Represent concepts, properties, expressions and relationships in the domain using e.g. class/object diagrams Model conversations by using Message Sequence Charts and Event flow diagrams Model protocols using high level Message Sequence Charts. Model the processing states of an agent during a protocol using State transition diagrams Model data interchanged in each interaction in terms of data structures specified in Expertise model
Describe each type of knowledge in Domain knowledge ontology, Inference diagrams, Task knowledge specification or Problem solving method diagrams/templates. Identify services that an agent offers to other agents and document this in Agent Model and/or Organization Model Show all agents, objects and their relationships (e.g., inheritance, association, agent-object relationship) Model organizational relationships are as association relationships annotated with roles (of each involved agent) Describe the reaction cases coming from interaction of agents with objects in the environment
Develop organization model for both agent classes and agent instances
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
Comparison of Ten Agent-Oriented Methodologies
357
Table 2f. Evaluation of ADELFE steps and techniques
E
6. Model domain conceptualization 7. Specify acquaintances between agent classes
E
Software architecture document
Software architecture document
B
B
8. Define interaction protocols
9. Define content of exchanged messages
E
Interaction languages document
B
E[8]
Interaction languages document
B
Detailed architecture document
O
10.Specify agent architecture E 11.Define agent mental attitudes (e.g. , goals, beliefs, plans, commitments …)
12.Define agent behavioural interface (e.g., capabilities, services, contracts…) 13.Specify system architecture (i.e. , overview of all components and their connections) 14.Specify organizational structure/control regime/interagent social relationships 15.Model MAS environment (e.g. , resources, facilities, characteristics) 16.Specify agent-environment interaction mechanism 17.Specify agent inheritance and aggregation 18.Instantiate agent classes 19.Specify agent instances deployment Extra: Elaborate and validate UI prototypes Extra: Code reuse, code completion
E
Detailed architecture document
B
E
Detailed architecture document
B
E
Detailed architecture document
E
Environment definition document
B
I[10]
Detailed architecture document
O
Detailed architecture document
O
UI prototype
B
I[13]
E
E
AMAS adequacy test
B
Examples
B
4. Identify roles 5. Identify agent classes
Usability
E
Use case model
Ease of
O
understanding
Use case model
Techniques for modelling
E[3]
Techniques for step
Models/ Notational components?
1. Identify system goals 2. Identify system tasks/ behaviour 3. Specify use case scenarios
Inputs/ Outputs?
Steps
Supported?
ADELFE
Identify the different functionality the system has to carry out Apart from identifying use cases, need to also highlight the possible cooperation failures in the identified use cases
Express each functionality as a use case
H
H
Y
Conventional OO techniques
H
H
Y
First, decompose system into entities. Determine which entities fit to be agents, i.e., whether they are autonomous, goaldirected, dynamic, and need to deal with unpredictable events. If an agent needs to be adaptive/evolving, it should be decomposed into a collective of subagents.
Show entities and their relationships in Preliminary class diagram. Update this diagram to indicate which classes are agents
H
H
Y
Identify potential interaction relationships between agents, and also between agents and non-agent active/passive entities Analyze each use case (step 4) and interaction scenarios (step 7)
Model interaction relationships with sequence diagrams or collaboration diagrams
H
M
Y
H
M
Y
H
M
Y
H
H
Y
H
H
Y
H
M
Y
H
H
Y
H
H
Y
H
L
N
H
M
Y
H
M
Y
H
H
Y
As above. Also select the communication languages for specifying the messages Agent architecture should contain 5 components: representations, social attitudes, interaction languages, aptitudes, and skills “Representations” are agent’s beliefs about itself and environment. “Social attitudes” contain rules for dealing with non-cooperative situations. “Interaction languages” involve protocols used by the agent. “Skills” are capabilities that an agent brings to its collective. “Aptitudes” are agent’s capabilities on its knowledge. Define the system architecture in terms of packages and classes (of agents and objects). Should use design patterns and/or re-usable components
Identify active and passive entities in the environment; characterize the system’s environment as being accessible or not, deterministic or not, static or dynamic, and discrete or continuous Agents interact with environment via percepts and actions, implicitly specified in agents’ “skills”, “aptitudes” and “interactions”.
Specify the GUIs through which users will interact with the systems, and relationships between GUIs Investigate (at the global level) whether a AMAS is required to implement the system, and (at the local level) whether some agents are needed to be implemented like AMAS
Elaborate each interaction relationship with a protocol diagram that specifies information exchanges between agents and between agents and non-entities
Model each agent in terms of the 5 listed components Specify attributes and methods for agent’s representations. Select protocols for agent’s interaction languages from the set defined in step 8. Specify non-cooperative situations and rules for cooperative attitudes. Specify methods and/or attributes for agent’s “skills” and “aptitudes” Generate a Class diagram for each package
Show aggregation relationships between agents in Class diagrams
Use any basic drawing tools Answer a number of questions regarding both levels
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
358 Tran & Low
Table 2g. Evaluation of MASE steps and techniques
2. Identify system tasks/ behaviour 3. Specify use case scenarios 4. Identify roles 5. Identify agent classes 6. Model domain conceptualization 7. Specify acquaintances between agent classes
E [4] E
10.Specify agent architecture 11.Define agent mental attitudes (e.g. ,goals, beliefs, plans, commitments …) 12.Define agent behavioural interface (e.g., capabilities, services, contracts…) 13.Specify system architecture (i.e. ,overview of all components and their connections) 14.Specify organizational structure/control regime/interagent social relationships 15.Model MAS environment (e.g. ,resources, facilities, characteristics) 16.Specify agent-environment interaction mechanism 17.Specify agent inheritance and aggregation 18.Instantiate agent classes 19.Specify agent instances deployment
Conventional OO techniques
B
Typically one-to-one mapping between goals and roles
Show roles, their related goals and communication paths between roles Show agent classes, related roles, and acquaintances between agents
Role diagram
E
Agent class diagram
B
I [5]
Agent class diagram
B
E
Communication class diagrams
B
E[8]
Communication class diagrams
B
E
Agent class architecture diagram
O
I[4]
Task state diagram
B
E
Deployment diagram
B
Deployment diagram
B
E [19]
Group roles into agent classes
Any communication paths between 2 roles indicate acquaintances between their respective agent classes Specify conversations between agents by analyzing inter-role interactions in use cases, and task descriptions in Task state diagrams Analyze inter-role interactions in use cases, and task descriptions in Task state diagrams Refer to the work of Robinson (2000) Specify how a role/agent can fulfil a task with a structured set of activities and communications. This implicitly represents an agent’s plan for achieving tasks.
Similar to instantiating objects from object classes Consider message traffic between agents and processing power available on particular machines and required by particular agents
Produce a Communication class diagram (which is a finite state machine) for each participant in the conversation Model messages as transitions between states in Communication class diagram. Specify performatives and parameters Refer to the work of Robinson (2000) Depict the task processing as a finite state machine
Show numbers and types of agents Show locations of agents (e.g., hostname and address)
Examples
Conventional OO techniques
Usability
B
B
Ease of
Hierarchically organize goals in the order of importance. All subgoals should relate functionally to their parent. Attach tasks to roles in Extended role diagram
understanding
Analyze initial system specifications, e.g., technical documents, user stories and use cases. Identify tasks that each role should perform to achieve goals
B
E
8. Define interaction protocols
9. Define content of exchanged messages
Extended role diagram Use case diagrams
Techniques for modelling
Goal hierarchy diagram
Techniques for step
E
1. Identify system goals
Inputs/ Outputs?
Models/ Notational components?
Steps
Supported?
MASE
H
H
Y
H
H
Y
H
H
Y
H
H
Y
H
H
Y
H
H
Y
H
H
Y
H
H
Y
H
M
Y
H
M
Y
H
H
Y
H
H
Y
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
Comparison of Ten Agent-Oriented Methodologies
359
Table 2h. Evaluation of RAP steps and techniques
1. Identify system goals 2. Identify system tasks/ behaviour
E[1,2 ]
Goal-based use case Model
B
I
Agent Model
O
3. Specify use case scenarios
4. Identify roles 5. Identify agent classes
O
E
Agent Model
6. Model domain conceptualization
I
Information Model
7. Specify acquaintances between agent classes
E
Interaction Model
B
I[7]
Interaction Model
B
8. Define interaction protocols 9. Define content of exchanged messages 10.Specify agent architecture 11.Define agent mental attitudes (e.g. , goals, beliefs, plans, commitments …)
E
12.Define agent behavioural interface (e.g., capabilities, services, contracts…) 13.Specify system architecture (i.e. , overview of all components and their connections) 14.Specify organizational structure/control regime/interagent social relationships 15.Model MAS environment (e.g., resources, facilities, characteristics) 16.Specify agent-environment interaction mechanism 17.Specify agent inheritance and aggregation 18.Instantiate agent classes 19.Specify agent instances deployment
E
Information Model (belief, commitment) Behaviour Model (reaction rule)
UML Deployment Diagram
Model each activity type with a goal-based use case, which is later elaborated with an activity diagram. Develop a use case for each activity type of agent, specifying the involved agents, their goals, trigger event, and actions of the primary agent. Show all agent roles and their respective internal agents Show all agents in the system and their role types
Only define a system entity as an agent class if it can communicate, perceive, act, make commitments and satisfy claims. Otherwise, view it as a passive object class
Model exchanged messages as communicative action event. Passing parameters are specified in the content of messages. Specify beliefs, commitments and reaction rules for each agent
B
O
This model captures all information objects, thus reflecting the domain conceptualization Agent acquaintances are captured via communicative action events between agents
Model agent beliefs as data objects that are shared or owned privately by the agents. Model each reaction rule by specifying the triggering event for the reaction and the output action (i.e., change of beliefs/commitments or performance of an action).
Examples
B
Identify the types of activities to be performed by each agent
Usability
Goal-based use case Model
Document the goals for each actor in each goal-based use case.
Ease of
E
Define goal for each type of activity performed by agents (see step 2)
understanding
B
Techniques for modelling
Goal-based use case Model
Techniques for step
E[2]
Inputs/ Outputs?
Models/ Notational components?
Steps
Supported?
RAP
H
H
Y
H
H
Y
H
H
Y
H
M
Y
H
L
Y
H
M
Y
H
M
Y
H
H
Y
M
L
N
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
360 Tran & Low
Table 2i. Evaluation of MESSAGE steps and techniques
E[1]
Goal/Task model
B
E
Agent /Role model
B
3. Specify use case scenarios 4. Identify roles
5. Identify agent classes E 6. Model domain conceptualization 7. Specify acquaintances between agent classes
E E
Agent /Role model
Domain model Organization Model
B
B
10.Specify agent architecture
E
Interaction model
B
I[8]
Interaction model
O
E
B
E
B
11.Define agent mental attitudes (e.g. ,goals, beliefs, plans, commitments …)
12.Define agent behavioural interface (e.g., capabilities, services, contracts…) 13.Specify system architecture (i.e. , overview of all components and their connections) 14.Specify organizational structure/control regime/interagent social relationships
15.Model MAS environment (e.g., resources, facilities, characteristics) 16.Specify agent-environment interaction mechanism 17.Specify agent inheritance and aggregation 18.Instantiate agent classes 19.Specify agent instances deployment
E[14]
System architecture diagram
B
E
Organization model
B
I[14]
Organization model
O
I[5]
Assign roles to agents based on the designer’s experience and heuristics
Incrementally add domain concepts and relations to Domain model as they are needed in other models
B
8. Define interaction protocols
9. Define content of exchanged messages
Identify services that can be performed by roles to satisfy goals, and tasks that can be implemented to fulfil these services
Incrementally built from Analysis to Design. In Analysis phase, only need to highlight which, why, and when roles communicate. In Design phase, elaborate each interaction considering the assignment of roles to agents and implementation of services in terms of tasks
Select an architecture that suits the functional requirements of agents (e.g., cognitive versus reactive) Depending on the agent architecture, various categories of knowledge may need to be specified, including domain knowledge, social knowledge and behaviour knowledge. These can be determined by analyzing the Domain model, Organization model, and Goal/Task model.
Show a hierarchy of goal decomposition in Goal diagram Describe the flow of tasks to achieve a service in a Workflow diagram Associate roles to goals in Delegation structure diagram, and to services and tasks in Workflow diagrams. Describe each role with Role Schema Describe each agent with an Agent Schema and an Agent diagram (which shows the associated roles, goals, tasks, and assessed data sources) Specify concepts as classes in UML class diagram Specify acquaintances between roles/agents in Organisation model. May model each protocol with AUML protocol diagrams or UML statechart. Can model the behaviour of eachagent/role in a protocol with statecharts
Define each message in appropriate ACL in protocol diagrams. Specify architecture components/layers, depending on the chosen architecture Model domain entities (for domain knowledge), social constraints (for social knowledge), and rules, objectives, and tasks (for behaviour knowledge) probably using UML notation
Derive system architecture from Organization Model
Show all system components as a package structure
Incrementally built from Analysis to Design. Start by analyzing organization chart and business process documentation
Show stakeholders/users, agents/roles, resources, suborganizations and relationships bet them (e.g. , power/peer-topeer organizational relationships, acquaintances) Show resources and their relationships with agents in Organization model
Identify resources that agents use, control or receive input from (e.g. , databases, computational resources)
Mentioned but no techniques/models provided
Examples
Usability
Analyze organization chart, company goals description and business processes
understanding
B
Techniques for modelling
Techniques for step
Goal/Task model
Ease of
2. Identify system tasks/ behaviour
E
Inputs/ Outputs?
1. Identify system goals
Models/ Notational components?
Steps
Supported?
MESSAGE
H
H
Y
H
H
Y
H
M
Y
H
M
Y
H
M
Y
H
M
Y
H
H
Y
H
L
N
H
H
Y
H
H
Y
H
H
Y
H
H
Y
H
L
N
L
L
N
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
Comparison of Ten Agent-Oriented Methodologies
361
Table 2j. Evaluation of INGENIAS steps and techniques
3. Specify use case scenarios
E
4. Identify roles I[5,14 ,8] 5. Identify agent classes 6. Model domain conceptualization 7. Specify acquaintances between agent classes
10.Specify agent architecture 11.Define agent mental attitudes (e.g. , goals, beliefs, plans, commitments …)
12.Define agent behavioural interface (e.g., capabilities, services, contracts…) 13.Specify system architecture (i.e., overview of all components and their connections) 14.Specify organizational structure/control regime/interagent social relationships
15.Model MAS environment (e.g., resources, facilities, characteristics) 16.Specify agent-environment interaction mechanism
B
E
Agent model
B
E
Interaction model
B
8. Define interaction protocols
9. Define content of exchanged messages
O
E[7]
Interaction model
B
E[8]
Interaction model
B
E
Agent model
B
I[14]
Organization model
B
E
Organization model
B
E
Environment model
B
E[15]
Environment model
B
17.Specify agent inheritance and aggregation 18.Instantiate agent classes 19.Specify agent instances deployment Extra: Implementation E
H
Y
H
H
Y
H
H
Y
H
M
Y
H
H
Y
H
H
Y
H
H
Y
For each message, show name of operation, parameters, guards and annotation of sequence
H
M
Y
Represent mental states in terms of goals, tasks, facts, or any other entity that helps in state description. Agent goals can be modelled as initial state. Can model agent control as algorithms or complex deliberative process
H
H
Y
H
H
Y
H
H
Y
H
H
Y
H
H
Y
H
H
Y
Incrementally identified and refined
Conventional OO techniques Show roles as actors of workflows/tasks in Organization model, as participants in Interaction model, and associated to agents in Agent model Describe each agent in terms of its roles, goals, tasks, mental states, and control structure/process.
In Analysis phase, identify significant interactions between actors (i.e., agents/roles) and initial schemes of exchanged info. In Design phase, elaborate each interaction with detailed description of exchanged elements (e.g., messages, tuples, method calls)
Determine agent’s “mental states” from analysis of goals, tasks, and interactions. Define the “control” of agent to assure desired transitions between its mental states
Incrementally identify and refine the org. structure in terms of system components (i.e. , agents, roles, resources, and applications) and social dependencies among them Identify resources and applications in the environment by analyzing system requirements and agent requirements Determine how agents perceive outputs of applications in the environment. Possible perception mechanisms: sampling or notification
Map the system design components to concrete components in the development framework and generate codes using code-generation tools
Examples
H
Show goals, goal-subgoals dependencies and goals-tasks associations Show tasks, tasks’ pre-conditions, post-conditions, and goals-tasks associations
Identify roles from the analysis of workflows and tasks in Organization model (step 14) and interactions (step 8) Apply “rationality principle” on system components to identify agents.
understanding
B
Use case diagrams Agent model, Organization model, Interaction model
Identify goals from system requirements or objectives associable to agents Derive tasks from system requirements or from goals
Techniques for modelling
E[1]
Goals and Tasks model
Techniques for step
B
Inputs/ Outputs?
Goals and Tasks model
Usability
2. Identify system tasks/ behaviour
E
Ease of
1. Identify system goals
Models/ Notational components?
Steps
Supported?
INGENIAS
Show participants (agents/roles) and goals pursued by each interaction Specify exchanged elements and order of their execution (e.g. , iteration, concurrency, branching)
Implicitly reflected in the Organization model where all system components and their connections are shown Show how system components are grouped, their social dependencies (e.g., subordination and clientserver relations), task/workflow assignment, and resources used/produced. Model resources and applications as objects. Specify internal states and operations for applications, and initial states, category, and limit of consumption for resources. Represent agent’s perception mechanism as a type of association relationship between the agent and an application in Environment 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
362 Tran & Low
ADELFE
MASE
RAP
MESSAGE
INGENIAS
H H
PASSI
4. Identify roles 5. Identify agent classes 6. Model domain conceptualization 7. Specify acquaintances between agent classes 8. Define interaction protocols 9. Define content of exchanged messages 10.Specify agent architecture 11.Define agent mental attitudes (e.g. , goals, beliefs, plans, commitments …) 12.Define agent behavioural interface (e.g., capabilities, services, contracts…) 13.Specify system architecture (i.e. , overview of all components and their connections) 14.Specify organizational structure/control regime/interagent social relationships 15.Model MAS environment (e.g. , resources, facilities, characteristics) 16.Specify agent-environment interaction mechanism 17.Specify agent inheritance and aggregation 18.Instantiate agent classes 19.Specify agent instances deployment
M
PROMETHEUS
1. Identify system goals 2. Identify system tasks/ behaviour 3. Specify use case scenarios
MASCOMMONKADS
GAIA
Steps
TROPOS
Table 3. Comparison regarding steps and usability of techniques
H
H
H
H
H
H
H
H
H
H
H
H
H
H
H
H
H
H
H
M
H
H H M
H
H H H
H M L
M M
H M H
M
H
M
H
M M H
M
M
H
H
H
M
H
H
H
H
M
H
M
H
L
H
M
H
L
H
H
H
M
M
M
H
M
H
M
L
H
H
M
M
H
H
H
H
H
H
L
M
H
M
H
M
M
L
M
H
H
L
M
M
H
H
H
L
M
H H
H
H
H
H
H
H
L
H H
M L
H L
L
L
H
All methodologies are found to specify outputs for their supported steps (denoted as “O” in the column “Inputs/Outputs”), while most methodologies specify inputs as well (denoted as “B,” indicating “both”). The ease of understanding and usability of the steps are evaluated as either High (“H”), Medium (“M”), or Low (“L”). We summarize the comparison in Table 3, where only the assessment of the criterion “Usability of techniques” is shown for each step of the methodologies.
Comparison Regarding Model-Related Criteria The assessment of the criterion “Concepts” is presented in Table 4, while the comparative analysis of other model-related criteria is summarized in Table 5. Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
Interaction model
Interaction protocol
Agent model
Agent model
Environment characterisation Agent aggregation relationship Agent inheritance relationship
Agent instantiation
Agent instances deployment
Environmental model
Environment resource/facility
Organization model
Organization model
Organization model
Organization model; Design model
Organization model
Non-functional requirements framework
Organizational structure model
Organizational structure/inter-agent social relationship
Coordination model
Sequence diagram/Collaboration diagram
Organization model
Coordination model
Sequence diagram
Coordination model
Sequence diagram/Collaboration diagram
Agent class descriptor Deployment model
Agent implementation model
System overview diagram
System overview diagram
Agent implementation model
Agent society model
System requirement model
Agent implementation model
Agent implementation model
Agent society model
Agent implementation model
Agent society model
System requirement model
Agent society model
System requirement model System requirement model System requirement model, Agent society model
PASSI
Interaction diagrams & protocols
Interaction protocols
Interaction diagrams
Agent overview diagram
Percepts descriptor
As events in State transition diagrams of Coordination Model Design model
Plan descriptor
Capability diagram
Data descriptor
Agent class descriptor
Use case descriptor
Functionality descriptor
Goal diagram
PROMETHEUS
Expertise model
Agent model; Organization model
Expertise model
BDI architecture
Plan diagram
As resources in each agent in Agent class diagram
Agent model
System architecture
Inter-agent contract/commitment
Content of exchanged messages
Acquaintance model
Service model
Agent model
Agent acquaintance
Agent architecture
Agent percept/ event
Agent capability/service Agent plan/reasoning rule/problem solving method
Agent belief/knowledge
Agent-role assignment
Agent model
Use cases
Task model
Goal cases
MASCOMMONAKDS
Agent goal/task Actor diagram
Actor diagram, Rationale diagram Actor diagram, Rationale diagram
TROPOS
Expertise model
Role model
Role model
GAIA
Domain conceptualization
Role
Use case scenario
System task/behaviour
System goal
Concepts
MASE
Environment definition document Detailed architecture document
Environment definition document
Detailed architecture document
Interaction languages document
Deployment diagram
Deployment diagram
Communication class diagram
Agent class diagram Communication class diagram
Software architecture document
Agent class architecture diagram
Task state diagram
Agent class diagram
Role diagram
Use case diagram
Goal hierarchy diagram Extended role diagram
Interaction languages document
Detailed architecture document
Detailed architecture document
Detailed architecture document
Detailed architecture document
Use case model
Use case model
ADELFE
RAP
UML Deployment diagram
Information model
Interaction model
Interaction model
Interaction model
Behaviour model
Information model
Agent Model
Information model Goal-based use case model
Agent Model
Goal-based use case model Goal-based use case model Goal-based use case model
Organization model
Organization model
System architecture diagram
Interaction model
Interaction model
Organization model
Agent/Role model
Domain model
Agent/Role model
Goal/Task model Goal/Task model
MESSAGE
INGENIAS
Environment model
Organization model
Organization model
Interaction model
Interaction model
Interaction model
Agent model
* (can be recorded in mental states, but not mentioned in methodology)
Agent model
Agent model
Agent model, Organization model, Interaction model
Use case diagram
Goals & Tasks model Goals & Tasks model
Comparison of Ten Agent-Oriented Methodologies 363
Table 4. Comparison regarding concepts
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
364 Tran & Low
Completeness/Express iveness Formalization/ Preciseness Model derivation Consistency Complexity Ease of understanding Modularity Abstraction Autonomy Adaptability Cooperative behaviour Communication ability Inferential capability Reactivity Deliberative behaviour Personality Temporal continuity Concurrency Human Computer Interaction Models Reuse
Y: Yes
INGENIAS
MESSAGE
RAP
MASE
ADELFE
PASSI
PROMETHEUS
MASCOMMONKADS
TROPOS
GAIA
Table 5. Comparison regarding model related criteria
M
H
H
H
H
H
H
M
M
H
a. H b. Y Y a. Y b. Y a. Y b. Y H Y Y Y P
a. H b. Y Y a. Y b. Y a. Y b. Y H Y Y Y N
a. M b. Y Y a. N b. Y a. Y b. Y H Y Y Y N
a. H b. Y Y a. Y b. Y a. Y b. Y H Y Y Y N
a. H b. Y Y a. Y b. Y a. Y b. Y H Y N Y N
a. H b. Y Y a. Y b. Y a. Y b. Y H Y Y Y Y
a. H b. Y Y a. Y b. Y a. Y b. Y H Y Y Y N
a. H b. Y Y a. N b. Y a. Y b. Y H Y Y Y N
a. H b. Y Y a. N b. Y a. Y b. Y H Y Y Y P
a. H b. Y Y a. Y b. Y a. N b. N M Y Y Y P
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
N
Y
Y
Y
Y
Y
Y
Y
Y
Y
N P
Y Y
Y Y
Y Y
Y Y
Y Y
P Y
P Y
Y Y
Y Y
Y
Y
Y
Y
Y
Y
Y
N
Y
Y
N N N
N N N
N N N
N N N
N N Y
N N N
N N Y
N N N
N N N
N Y N
N
Y
Y
Y
Y
Y
N
Y
Y
Y
Y
P
Y
P
Y
P
Y
P
P
P
N: No
P: Possibly
The “Concepts” criterion in Table 4 evaluates the modelling capability of an AOSE methodology by examining which concepts the methodology’s models are capable of capturing/representing. A list of “standard” AOSE concepts is used as an assessment checklist, as previously mentioned. If a methodology supports the modelling of a particular concept, we indicated the name of the model or notational component (i.e., diagram) that represents that concept. If a concept appears in many different models or diagrams within the methodology, we only specified the model or diagram that represents the concept as the principal modelling element.
Comparison Regarding Supportive-Feature Criteria This comparative assessment of the methodologies in terms of their high-level, additional features is summarized in Table 6. Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
Comparison of Ten Agent-Oriented Methodologies
365
Y: Yes
MASCOMMONKADS
PROMETHEUS
PASSI
ADELFE
MASE
RAP
MESSAGE
INGENIAS
Support for ontology
TROPOS
Software and methodological support Open systems Dynamic structure Agility and robustness Support for conventional objects Support for mobile agents
GAIA
Table 6. Comparison regarding supportive related criteria
N
N
N
Y
Y
Y
Y
Y
Y
Y
Y N N
N N N
N N Y
N N Y
N Y N
Y N Y
N P Y
N N Y
N N N
N N N
N
N
N
Y
N
Y
N
Y
Y
Y
N
N
N
N
Y
N
N
N
N
N
N
N
Y
N
Y
N
N
N
Y
N
N: No
P: Possibly
Conclusions This chapter has presented an evaluation and comparison of the 10 AOSE methodologies described in Chapters 2-11 of this book. Overall, it is impossible (and not recommended) to determine which methodology is the best among these 10. The decision should depend on the target application. Each application entails a different set of requirements that indicate which evaluation criteria are the most important and should be supported by the chosen AOSE methodology. When considering which methodology to adopt for a particular application, we recommend ranking the required features that the methodology should support. Tables 1-6 provide a useful framework to compare potential methodologies against the required list of features. Despite our efforts to provide a comprehensive and objective comparison, we acknowledge the following limitations: •
Our evaluation has been solely based upon the available documentation of the methodologies and their documented case studies, examples, and projects. We have not personally applied any of these methodologies on a real project. An optimal comparison would be to use the 10 methodologies on the same application(s).
•
Some evaluation criteria are subjective in nature, particularly the usability and understandability of the methodologies’ process steps, techniques, and models.
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
368
Henderson-Sellers
Chapter XIII
Creating a Comprehensive Agent-Oriented Methodology :
Using Method Engineering and the OPEN Metamodel Brian Henderson-Sellers University of Technology, Sydney, Australia
Abstract While individual agent-oriented methodologies are useful for restricted situations, a more flexible approach can be found in the use of situational method engineering. Using an underpinning metamodel, a repository of method fragments can be built up and, from this, a selected number of fragments can be abstracted to form an organization-specific or projectspecific methodology. As an example, we demonstrate the use of the OPEN metamodel and repository, as extended to support agent-oriented conceptual thinking. Re-creation of existing methodologies, such as Prometheus, is demonstrated with further enhancements from other methodologies such as Tropos and Gaia. Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
366 Tran & Low
The comparative analysis provided in this chapter is one step towards the development of a unified, standardized AOSE framework that may be formed by merging the various existing AOSE methodologies with some extensions. A first step towards this, using the principles of method engineering, is described in the next chapters.
References Cernuzzi, L. & Rossi, G. (2002). On the evaluation of agent-oriented modeling methods. In Proceedings of the OOPSLA Workshop on Agent-Oriented Methodologies, Seattle, November 4-8 (pp. 21-33). University of Technology, Sydney: Centre for Object Technology Applications and Research. Iglesias, C.A., Garijo, M., & Gonzalez, J.C. (1999). A survey of agent-oriented methodologies. In Proceedings of the 5th International Workshop on Intelligent Agents V: Agent Theories, Architectures, and Languages (ATAL-98), Paris, July 4-7 (pp. 317-330). Springer-Verlag. Jayaratna, N. (1994). Understanding and evaluating methodologies - NIMSAD a systematic framework. Maidenhead, UK: McGraw-Hill. The Object Agency Inc. (1995). A comparison of object-oriented development methodologies. Retrieved November 9, 2003, from http://www.toa.com/ smnn?mcr.html Olle, T.W., Sol, H.G., & Tully, C.J. (1983). Information systems design methodologies – A feature analysis. Amsterdam: Elsevier Science Publishers. O’Malley, S.A. & DeLoach, S.A. (2001). Determining when to use an agentoriented software engineering paradigm. In Proceedings of the 2nd International Workshop on Agent-Oriented Software Engineering (AOSE 2001), Montreal, Canada, May 29 (pp. 188-205). Springer-Verlag. Robinson, D.J. (2000). A component-based approach to agent specification. Master’s Thesis, School of Engineering, Air Force Institute of Technology, Wright-Patterson AFB OH. Sabas, A., Badri, M., & Delisle, S. (2002). A multidimensional framework for the evaluation of multi-agent system methodologies. In Proceedings of the 6th World Multiconference on Systemics, Cybernetics and Informatics (SCI 2002), Orlando, July 14-18 (pp. 211-216). Orlando: International Institute of Informatics and Systemics. Shehory, O. & Sturm, A. (2001). Evaluation of modeling techniques for agentbased systems. In Proceedings of the 5th 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
Comparison of Ten Agent-Oriented Methodologies
367
Autonomous Agents, Montreal, Canada, May 28-June 1 (pp. 624-631). ACM Press. Siau, K. & Rossi, M. (1998). Evaluation of information modeling methods – A review. In Proceedings of the 31 st Annual Hawaii International Conference on System Sciences, Hawaii, January 6-9 (pp. 314-322). IEEE Computer Society. Tran, Q.N., Low, G., & Williams, M.A. (2003). A feature analysis framework for evaluating multi-agent system development methodologies. In Proceedings of the 14th International Symposium on Methodologies for Intelligent Systems ISMIS’03, Maebashi, Japan, October 28-31 (pp. 613617). Springer-Verlag. Wood, B., Pethia, R., Gold, L.R., & Firth, R. (1988). A guide to the assessment of software development methods. Technical Report CMUSEI-88-TR-8, SE. Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA. Yu, E. (1995). Modeling strategic relationships for process reengineering. PhD thesis, University of Toronto, Department of Computer Science, Toronto, Canada.
Endnotes 1
Models are differentiated from notational components in that models are conceptual constructs that underlie the graphical or textual depictions, which are notational components (e.g. diagrams, tabular schemas). Each model can be depicted by many notational components (e.g., an Interaction Model may be depicted by a set of Sequence Diagrams and/or State Charts).
2
This is the same survey as that conducted for validating the framework of “standard” AOSE steps in the section on “Process Related Criteria.”
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
Creating a Comprehensive Agent-Oriented Methodology
369
Introduction Individual methodologies, such as those described so far in this book, are often created with specific purposes in mind, for example, particular domains, particular segments of the lifecycle. Used within those constraints, they are ideally suited. However, users often make the assumption that a methodology is not in fact constrained but, rather, is universally applicable. This can easily lead to “methodology failure” and the total rejection of methodological thinking by software development organizations (e.g., Avison & Fitzgerald, 2003). The search for a one-size-fits-all methodology has been long and will, ultimately, always be fruitless (e.g., Cockburn, 2000). If the creation of a single universally applicable methodology is an unattainable goal, then we must ask how we might create a methodological environment in which the various demands of different software developers might be satisfied simultaneously. It is argued here that such flexibility might be best obtained by the use of method engineering, preferably based on an underlying metamodel. Formalizing methodological concepts and constraints with a metamodel in this way allows us to identify two component parts of a methodology: (1) the process, and (2) various products created and/or used in the process (Rolland, Prakash, & Benjamen, 1999). Although all the chapters in this book deal with the broader term of “methodology” (i.e., process plus product), for our case study in this chapter, we will focus only on the “process” part of a methodology. A second assumption we make here is that an agent-oriented (AO) methodology can be formulated as a particular extension of an object-oriented (OO) methodology. In the context of method engineering and the earlier chapters of this book, we will demonstrate that this is a reasonable assumption. In the following sections, we introduce situational method engineering as an effective approach for constructing a site-specific methodology that may be tailored or customized for individual projects in the context of OPEN, particularly as it has been partially extended to support agent-oriented software development. In the next section (CASE STUDY), we demonstrate how such methodology construction works with a simple case study and, finally, we conclude with a research and technology transfer agenda to facilitate the creation, finalization, and technology transfer of such a “standardized” approach in the context of the adoption of agent-oriented methodologies in an industrial context.
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
372
Henderson-Sellers
fragment in the repository, there is such a conceptual definition in the metamodel. The repository (of method fragments) thus contains numerous instances generated from each of the classes in the metamodel (Figure 2). Although some method fragments have a specific bias, for example, to object technology, to systems engineering, to business modelling, or to traditional procedural programming using a language such as COBOL, the repository as a whole can be independent of technological paradigms. It is thus reasonable, as we shall do here, to begin with a repository populated by a mixture of OO-biased fragments and OO-independent fragments (e.g., for project management) and add new agent-biased fragments prior to constructing an organization-specific or a project-specific AO methodology from these many fragments. Creating a project-specific methodology is currently one of the more difficult and time-consuming jobs of the method engineering approach, since the method engineer has to understand the methodology, the organization, the environment, and the software project in order to select the appropriate fragments from the repository to use on the project, in addition to understanding the rules of construction. Traditionally, this process is carried out using predefined organizational requirements and the experience and knowledge of the method engineer or process engineer (e.g., Fitzgerald, Russo, & O’Kane, 2003), although significant tool support is likely in the near future (Saeki, 2003). In the next section, we see how this is accomplished using one particular method engineering framework, OPEN.
A Method Engineering Framework: OPEN With future commercial adoption in mind, the first choice must be for a methodology framework with an underpinning metamodel and an existing extensive catalogue of method fragments. Here, we use Object-oriented Process, Environment, and Notation or OPEN, 3 which is both described in an extensive set of books (e.g., Firesmith & Henderson-Sellers, 2002; Graham, Henderson-Sellers, & Younessi, 1997; Henderson-Sellers, Simons, & Younessi, 1998) and is used in industrial applications (e.g., Serour, Henderson-Sellers, Hughes, Winder, & Chow, 2002). The OPEN metamodel contains a number of conceptual entities modelled by object-oriented classes, typically described using the UML notation. Those concepts most relevant to the creation of an AO methodology standard as an extension of the existing OO methodological repository are (1) Task, (2) Technique, and (3) Work Product. Each of these
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
370
Henderson-Sellers
Situational Method Engineering Method engineering (Brinkkemper, 1996; Kumar & Welke, 1992), more appropriately called situational method engineering or SME (Ter Hofstede & Verhoef, 1997), recognizes the fact (often ignored as noted above) that seeking to develop an all-encompassing methodology appropriate for all situations is foolish. Rather, SME seeks to model methodological processes and products by isolating conceptual method fragments (van Slooten & Hodes, 1996) that are coherent portions of a methodology. These fragments act as methodological “building blocks”—examples might be a particular technique to identify agent types or the Figure 1. The methodologist is responsible for the methodology metamodel, creating a significant number (but not necessarily all) of the method fragments in the repository and the guidelines for construction. The user (often the in-house method engineer) uses the construction guidelines and the contents of the repository (to which they are at liberty to add new fragments) in order to create a “personalized development methodology” attuned to a specific project or context.
Project meets the needs of a specific
Personalized Development Methodology
<>
provides elements for the construction of
Methodology metamodel
provides definitions of
Repository of Predefined Method Fragments describes how to use the
Construction Guidelines
user
methodologist
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
Creating a Comprehensive Agent-Oriented Methodology
371
way to use a sequence diagram in AUML (Odell, Van Dyke Parunak, & Bauer, 2000). These method fragments thus effectively allow a methodology to be extended by incorporating elements from other methodologies (e.g., Ralyté & Rolland, 2001). In other words, from these method fragments can be constructed a specialized methodology appropriate for each and every situation. The methodologist publishes the method fragments, usually contained in a repository1 together with some construction guidelines (Brinkkemper, Saeki, & Harmsen Klooster, Brinkkemper, Harmsen, & Wijers, 1997; Ralyté & Rolland, 2001; Ralyté, Rolland, & Deneckère, 2004); and the user (usually an in-house method engineer) uses these construction guidelines to create the organizationspecific or project-specific methodology within the organizational context and constraints (Figure 1). In the case where an organization develops software in a single domain, that constructed methodology may suffice for all developments; for other commercial developers, the constructed methodology may need to be project-specific. Ideally, the elements in an SME repository should be compliant with (in fact, generated from) a set of concepts described by a metamodel (HendersonSellers, 2003; Ralyté & Rolland, 2001), which is a high-level description of the rules that govern the kinds of method fragments that are allowable. For instance, in the metamodel there may be an entity (often represented as a class) called Task.2 This definition describes the characteristics and rules of all tasks (for example, that they must be accomplished by a person using a special technique). From this Task concept in the metamodel can then be generated (usually by instantiation) very many kinds of tasks, for example, a task to create a class diagram, a task to identify the use cases, and so on. For each kind of method Figure 2. For each concept in the metamodel, many instances can be generated and stored in the repository. Metamodel
Repository of method fragments
Concept A Concept B
Concept C Concept D
Example 1 Concept A
Example 2 Concept A
...
Example 1 Concept B
Example 2 Concept B
...
Example 1 Concept C Example 1 Concept D
Example 2 Concept C Example 2 Concept D
... ...
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
374
Henderson-Sellers
Each of these five metaclasses has many subclasses in the detailed metamodel (see Appendix G of Firesmith & Henderson-Sellers, 2002). From each of the leaves in the metamodel hierarchy can be generated one or more method fragments, which are, of course, instances of classes in the metamodel, documented and stored in the OPEN repository Each method fragment is described in a standardized way—examples of task descriptions, for instance, are found in the Appendix to this chapter. These descriptions are found in the books on OPEN (e.g., Firesmith & HendersonSellers, 2002; Graham et al., 1997; Henderson-Sellers< Simons, & Younessi, 1998), on Web sites (http://www.open.org.au and http://www.donaldfiresmith.com) and, in the future, in software tools (e.g., Nguyen & HendersonSellers, 2003). These repositories provide an extensive collection of fragments that can be further extended to support changes in technology, for instance, as described in this chapter, to offer additional methodology support for the novel aspects of agent-oriented software development.
Method Fragment Selection Having created the OPEN repository of method fragments, method engineering (or SME) is then used to construct a site-specific or project-specific methodology by selecting appropriate method fragments from this OPEN repository and using the supplied guidelines (see Firesmith & Henderson-Sellers, 2002, for details) for helping organizations to adopt OPEN for their information system development projects. These guidelines offer advice on the selection of specific fragments based on the notion of deontic matrices. A deontic matrix (Figure 3) is a two-dimensional matrix of values that represent the possible or likely relationship between each pair of method fragments in OPEN. Deontic matrices are used to link Activities and Tasks; Tasks and Techniques; Producers and Tasks; Tasks and Work Products; Producers and Work Products; and Work Products and Languages. The actual values in this matrix will vary depending upon a number of factors such as project size, organizational culture, domain of the application to be developed, and the skills and preferences of the development team. These values are currently evaluated by hand although, as noted above, tool support is currently under development. For example, the possibility value for using the OPEN Task “ Evaluate quality” to help fulfil the Activity “Verification and Validation (V&V)” might be assessed as being “Recommended” (one of the five prescribed values). Once completed, the deontic matrices give guidance on the most appropriate selection of method fragments. Although five levels are suggested in Figure 3 (the default in OPEN), for a specific project binary values are often used. However, as an organization matures, a wider range of deontic values can be Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
Creating a Comprehensive Agent-Oriented Methodology
375
Figure 3. A core element of OPEN is a two-dimensional relationship between each pair of methodology elements, here shown for Activities and Tasks. Each Activity may require one or more Tasks. For each combination of Activity and Task, an assessment can be made of the likelihood of the occurrence of that combination using five levels of possibility. Some combinations can be identified as mandatory (M), others as recommended (R), some as being optional (O), some are discouraged (D) but may be used with care, and other combinations that are forbidden (F).
Tasks
Activities 1 2 3 4 5 6 7 8 9 10 11 . .
A
B
C
D
E
.
M D D F F R D D R O F .
D D D O M R R F R D M .
F F O O O M F M D O O .
F F O O D R M D R O F .
F D D F F O O D R R D .
. . . . . . . . . . . .
. 5 levels of possibility M = mandatory R = recommended O = optional D = discouraged F = forbidden
useful. For example, rather than mandating a specific OPEN Technique to realize a Task (and therefore forbidding all others), an option may be given to the development team to use one of several—the one(s) they are “happiest” with. In this context, the management might permit a range of Techniques to identify agent types within the Task: “Construct the agent model” from, say, use cases, robustness analysis, textual analysis, role modelling, collaborations analysis, and intelligent agent identification. Indeed, different sections of the team may have varying preferences and skill sets. In addition, increasingly sophisticated teams will wish to see their process mature commensurately. Using the deontic matrix approach, new method fragments are easily added to an organization’s existing methodology. Thus, the SME approach also provides implicit support for Software Process Improvement (SPI).
Methodology Construction using OPEN While it is possible to construct a process4 either top-down or bottom up, let us here demonstrate the process construction process in a top-down fashion. In this example, we first identify a number of Activities that state high-level “jobs to be done” and connect them to form a problem-specific or organization-specific OPEN process architecture. The “process” itself is seen in the workflow
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
Creating a Comprehensive Agent-Oriented Methodology
373
metaclasses can be instantiated to create numerous instances (of Task, Technique, and Work Product, respectively), all of which are stored in the OPEN repository. It is thus highly compatible with the ideas of method engineering and process construction as described above. From this framework, OPEN-compliant methodologies can be created by instantiation from the metamodel to be used in actual organization and software projects. In other words, the method engineer/process engineer has to create an instance of OPEN that is suitable for use on a specific project or for a specific software development organizational unit. A company-customized OPEN version is then “owned” by the organization, becoming its own internal standard, while retaining compatibility with the global OPEN user community.
OPEN’s Metamodel The OPEN metamodel defines five main, high-level classes of kinds of method fragments: •
Work Product: anything of value that is produced, used, or modified during the process of development. Work Products are the result of producers (usually people) executing Work Units and are used either as input to other Work Units or delivered to a client. Despite the name (viz. “products”), they also include externally supplied (e.g., by a user) pre-existing artefacts used as inputs to Work Units.
•
Producer: entity responsible for creating, evaluating, iterating, and maintaining Work Products—typically a person, but could also be a software tool or even a piece of hardware.
•
Work Unit: a functionally cohesive operation that is performed by a Producer. There are three major classes of Work Unit: Activity, Task, and Technique. Activities and Tasks are statements at different levels of granularity of what needs to be done. Techniques, on the other hand, delineate the how. Because of their visible and tangible nature, Work Products, and especially those that are deliverable, are of particular interest to project managers. They also provide an alternative to Tasks in project tracking.
•
Language: a medium for documenting a Work Product, for example, natural language, UML, Java.
•
Stage: an identified and managed duration within the process or a point in time at which some achievement is recognized. Stages describe when things happen in the software development lifecycle.
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
376
Henderson-Sellers
between these Activities. To meet the demands of the specific organization or specific project, permissible sequences of events or paths through the process are pre-specified by the organization’s process engineer. In OPEN’s contractdriven life-cycle model (Graham, 1995), movement between Activities is permissible only when the Activity’s post-condition is completed and the next Activity’s precondition is met (Graham et al., 1997). These contracts, created by the process engineer, consist of testing criteria, deliverables, quality standards, and so on. Activities in OPEN are coarse, granular descriptions of what needs to be done. The combination of Activity objects with forward and backward links form the process. Scheduling comes from the planning Activities and Tasks combined with the project management elements embodied in the appropriate Tasks. A specific process instantiation may concentrate on a single project or on a programme of several projects, which introduces new foci such as domain modelling and reuse, as well as resource allocation. Also focussing on the “what” is the OPEN Task, which offers much more detail than the OPEN Activity and provides project management support. While OPEN’s Tasks are like Activities in the sense that they describe jobs to be done (but not how to do them), they are different in that Activities are conceptual, while Tasks, as the smallest unit of work that can be project-managed and result in a deliverable, are linked to a project management mindset. In addition, the idea that business culture should be adapted to fit a specific methodology is not good business sense, despite its prevalence in many of the marketed methodologies to date. When using IT and its dependent parts, such as methodologies, it is critical that they fit the business and not the other way around.
Support for Agents While OPEN was originally developed for systems development in an objectoriented context, in recent years method fragments have begun to be developed for application to agent-oriented systems (Debenham & Henderson-Sellers, 2003; Henderson-Sellers & Debenham, 2003). This chapter describes the current (mid-2004) extent of support for agent-oriented software development. Extending OPEN to support agent-oriented software development is relatively straightforward. It requires the identification of any new (or amended) Tasks, Techniques, Work Products, Producers, and so on. These are found by examination of existing AO methodologies such as those described in detail in this book. To date, we have evaluated Tropos (Henderson-Sellers, Giorgini, & Bresciani, 2003; Henderson-Sellers, Giorgini, & Bresciani, 2004a), MASE (Tran, HendersonSellers and Debenham, 2004), Gaia (Henderson-Sellers, Debenham, & Tran,
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
378
Henderson-Sellers
Figure 4. Lifecycle constructed for the case study of a Prometheusstyle agent-oriented methodology Early Requirements Engineering
System Specification
Architectural Design
Detailed Design
Implementation
Figure 5. A portion of the matrix linking Tasks and Techniques for the extended Prometheus case study (Note that the OPEN, rather than the Prometheus, names are used for some of these Tasks (for details see Henderson-Sellers, Tran, & Debenham, 2004a)) Technique Abstract class identification Abstraction utilization Agent internal design AND/OR decomposition Class naming Collaborations analysis Control architecture Context modelling CRC card modelling . Delegation analysis Event modelling Intelligent agent identification Means-end analysis Prototyping Relationship modelling Responsibility identification Role modelling State modelling Textual analysis Timeboxing 3-layer BDI model
1
2
3
Tasks 4 5
6
7
Y Y Y Y Y Y Y Y Y Y Y Y Y
Y Y Y Y Y
Y Y Y Y Y Y Y Y Y Y
Y Y Y Y Y Y
Y
Y
Y Y
Key:
1. Model dependencies for actors and goals; 2. Construct the agent model; 3. Design agent internal structure; 4. Model the agent’s environment; 5. Model responsibilities; 6. Model permissions; 7. Code
For each of these five activities, we can then identify a number of Tasks. Then, in turn, we can identify appropriate Techniques for each Task. Figure 5 shows actual values in the matrix linking Tasks and Techniques. We only show a small portion of the full matrix (only 7 Tasks and 21 Techniques) because of space restrictions and have also chosen to restrict this example to binary values to illustrate the SME approach to methodology construction by eschewing some of the potentially obfuscating detail. It is readily seen how some of the Techniques are appropriate for more than just one Task and, conversely, that any one Task is often affected by more than one Technique. In other words, the model is a many-to-many one. Use of this matrix can also identify method components that have been introduced but turn out not to be useful in this particular context, for example, the Technique of Abstract class identification in the first row of 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
Creating a Comprehensive Agent-Oriented Methodology
377
2004), Prometheus (Henderson-Sellers, Tran, & Debenham, 2004a), Cassiopeia (Henderson-Sellers, Tran, & Debenham, 2004b), the Agent Factory (HendersonSellers, Tran, Debenham, & Gonzalez-Perez, 2004) and CAMLE (GonzalezPerez, Henderson-Sellers, Debenham, Low, & Tran, 2004). For each individual AO methodology, we have analysed the original methodological description for method fragments and then have identified which of these method fragments are already supported in the published books and papers on (non-Agent) OPEN and which fragments (mostly Tasks, Techniques, and Work Products as it turns out) need to be added to the repository. In only one case, that of Tropos, did we find it necessary to add a new Activity, that activity being Early Requirements Engineering. We identified a significant number of new Tasks and subtasks (described in the Appendix), together with many new Techniques and Work Products. It should be noted that, at the time of writing, each addition had been done effectively in vacuo in the sense that the work to integrate and rationalize these new method fragments between and across the various AO methodologies still remains to be undertaken and is the topic of an ongoing research project (2004-2006).
Case Study In this case study, we will show how to construct a methodology that is similar to Prometheus (Padgham & Winikoff, 2002) but fills some of the omissions in that methodology, particularly by including consideration of early requirements engineering, as described in Tropos (Bresciani, Giorgini, Giunchiglia, Mylopolous, & Perini, 2004). In addition, it is stated that developers prefer to develop their agents in terms of responsibilities and permissions as promulgated in Gaia (Wooldridge, Jennings, & Kinny, 2000; Zambonelli, Jennings, & Wooldridge, 2003). Prometheus reports that it follows a RUP approach to “applying an iterative process over clearly delineated phases” (Padgham & Winikoff, 2004, p. 23), these phases being named System specification, Architectural design, and Detailed design. This methodology also implicitly includes a Construction phase. However, in terms of OPEN, it is unclear whether these four phases are really equivalent to RUP’s phases or are perhaps better equated to RUP’s disciplines (also known as workflows), which would mean that in OPEN they would be best modelled as Activities. In this case, the overall software development lifecycle model, based on Prometheus plus Tropos’ Early Requirements Engineering, is strongly linear (Figure 4) with iterations occurring within the OPEN Activities.
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
Creating a Comprehensive Agent-Oriented Methodology
379
Figure 6. Matrix values linking Work Products and Tasks for the case study’s constructed methodology (only a small fraction of the full matrix is shown in order to save space) Work Product Agent Class Descriptor Agent Acquaintance Diagram Agent Overview Diagram Capability Diagram Role Model Role Schema (Tropos) Goal Diagram (Tropos) Actor Diagram UML Sequence Diagram
1
2
3
Tasks 4 5
6
7
Y Y Y
Y Y Y Y Y Y
.
Y Y Y Y
Key:
1. Model dependencies for actors and goals; 2. Construct the agent model; 3. Design agent internal structure; 4. Model the agent’s environment; 5. Model responsibilities; 6. Model permissions; 7. Code
Similarly, Work Products can be linked to various Tasks. Some of the work products are unique to Prometheus, but that methodology also advocates reuse of existing UML diagrams when appropriate. In addition, because we are using Tropos’ Early Requirements Activity and OPEN’s broader support for the full lifecycle of systems development, the Work Products linked in Figure 6 to Tasks (again restricted to just seven of the many Tasks) go beyond those contained in the published Prometheus approach. Thus, we have effectively extended Prometheus by incorporating new method fragments, some from Tropos and others from the pre-agent repository published for OPEN (e.g., Firesmith & Henderson-Sellers, 2002).
Creating the Future for AO Methodologies While there is a good academic future for uncoordinated development of a suite of individualistic agent-oriented methodologies, this is inappropriate for future industry adoption. Industry needs broadly accepted “standard” approaches – ones that are widely and well supported and likely to persist for a significant period of time. The proposal made in this chapter is that an excellent way to achieve solidarity, to continue to support innovation, and, at the same time, to create an industry-
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
380
Henderson-Sellers
acceptable methodological approach is by the use of situational method engineering. Since there is already an industry-accepted SME-based repository of method fragments available in the form of OPEN, the use of OPEN as an initial framework for this development is advocated. The OPEN repository has already been enhanced by a significant number of method fragments gleaned from individual and original AO-focussed methodological approaches, as discussed in the subsection on “Support for Agents”. This will continue as further AO methodologies are analysed – the near future will see the incorporation of concepts from, at least, the BDI model of Rao and Georgeff (1995), PASSI (e.g., Cossentino & Potts, 2002, and Chapter 8 here), ADELFE (e.g., Bernon, Gleizes, Picard, & Glize, 2002, and Chapter 2 here), INGENIAS (Gomez-Sanz & Pavon, 2003, and Chapter 4 here), MESSAGE (e.g., Caire et al., 2001, and Chapter 7 here) and RAP (e.g., Wagner, 2003, and Chapter 10 here). At the same time, rationalization of similar method fragments derived from these various AO methodologies will occur and better integration with the OO method fragments of OPEN as detailed in, for example, Firesmith and Henderson-Sellers (2002) will be pursued. This will be facilitated by study of the various classification frameworks published in recent years, such as Cernuzzi and Rossi (2002), Sturm and Shehory (2004), Dam and Winikoff (2004) and Tran and Low (Chapter 12 of this book). In addition, conceptual modelling work, particularly in the product domain, from TAO (Silva & Lucena, 2004) will be used to maintain a rigorous and academically defensible underpinning theory to the extended OPEN repository and metamodel. Methodology testing is notoriously difficult but is a necessary part of ensuring that the quality of the methodology “product” is high, particularly for widespread industry adoption. Using in-house tool support, we aim to evaluate the emerging (Agent) OPEN repository in industrial settings, probably using an Action Research methodology (Avison, Lau, Myers, & Nielsen, 1999) to gather and analyse qualitative results. Other possible community efforts could be instigated. For example, intercomparison of approaches, not only theoretically as, for instance, in the preceding chapter, but also on a test example (e.g., Yu & Cysneiros, 2002) and, preferably, in industry situations, might yield significantly improved understanding of what works and what is less successful. Similarly, such intercomparison could reveal any significant weak points in agent-oriented methodology research and help researchers target areas where results are likely to be the most fruitful. The ultimate result of the substantial efforts of the various AO methodology teams, as exemplified by the chapters in this volume, complemented by method engineering techniques will be the consolidation of the agent-oriented methodological community’s contribution to the better development of commercial software systems.
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
Creating a Comprehensive Agent-Oriented Methodology
383
Henderson-Sellers, B. (2003). Method engineering for OO system development. Comm. ACM, 46(10), 73-78. Henderson-Sellers, B. & Debenham, J. (2003). Towards OPEN methodological support for agent-oriented systems development. In B.H. Far, S. Rochefort, & M. Moussavi (Eds.), Proceedings of the First International Conference on Agent-Based Technologies and Systems, University of Calgary, Canada (pp. 14-24). University of Calgary. Henderson-Sellers, B., Debenham, J., & Tran, Q.-N.N. (2004). Adding agentoriented concepts derived from GAIA to Agent OPEN. In Advanced Information Systems Engineering: 16th International Conference, CAiSE 2004, Riga, Latvia, June (pp. 98-111). Berlin: Springer-Verlag. Henderson-Sellers, B., Giorgini, P., & Bresciani, P. (2003). Evaluating the potential for integrating the OPEN and Tropos metamodels. In B. Al-Ani, H.R. Arabnia, & Y. Mun (Eds.), Proceedings of SERP ‘03 (pp. 992-995). Las Vegas, NV: CSREA Press. Henderson-Sellers, B., Giorgini, P., & Bresciani, P. (2004). Enhancing agent OPEN with concepts used in the Tropos methodology. In Proceedings of Engineering Societies in the Agents World IV. 4th International Workshop, ESAW 2003 (LNAI 3071, pp. 328-345). Berlin: SpringerVerlag. Henderson-Sellers, B., Simons, A.J.H., & Younessi, H. (1998). The OPEN toolbox of techniques. Harlow, UK: Addison-Wesley. Henderson-Sellers, B., Tran, Q.-N.N., & Debenham, J. (2004a). Incorporating elements from the Prometheus agent-oriented methodology in the OPEN Process Framework. In Proceedings of AOIS@CAiSE’04 (pp. 370-385). Riga Technical University, Latvia. Faculty of Computer Science and Information. Henderson-Sellers, B., Tran, Q.-N.N. & Debenham, J. (2004b). Method engineering, the OPEN Process Framework and Cassiopeia, In Proceedings of Symposium on Professional Practice in AI (pp. 263-272), Toulouse, France, August 22-27. Norwell. MA: Kluwer. Henderson-Sellers, B., Tran, Q.-N.N., Debenham, J., & Gonzalez-Perez, C. (2005). Agent-oriented information systems development using OPEN and the agent factory. Information Systems Development Advances in Theory, Practice and Education: 13th International Conference on Information Systems Development, ISD 2004, Vilnius, Lithuania, September 9-11 (pp. 149-16). New York: Kluwer Acadmic / Plenum Publishers. Klooster, M., Brinkkemper, S., Harmsen, F., & Wijers, G. (1997). Intranet facilitated knowledge management: A theory and tool for defining situCopyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
Creating a Comprehensive Agent-Oriented Methodology
381
Acknowledgments I wish to acknowledge financial support from the University of Technology, Sydney, Australia, under its Research Excellence Grants Scheme. Thanks to John Debenham and Cesar Gonzalez-Perez for offering comments on an earlier version of this chapter. This is Contribution number 04/24 of the Centre for Object Technology Applications and Research.
References Avison, D. & Fitzgerald, G(2003). Where now for development methodologies. Comm. ACM, 46(1), 79-82. Avison, D.E., Lau, F., Myers, M., & Nielsen, P.A. (1999). Making academic research more relevant. Communications of the ACM, 42(1), 94-97. Bernon, C., Gleizes, M.-P., Picard, G., & Glize, P. (2002). The ADELFE methodology for an intranet system design. In P. Giorgini, Y. Lespérance, G. Wagner, & E. Yu (Eds.), Agent-Oriented Information Systems 2002, Proceedings of AOIS-2002 (pp. 1-15). AOIS.org. Bresciani, P., Giorgini, P., Giunchiglia, F., Mylopolous, J., & Perini, A. (2004). Tropos: An agent-oriented software development methodology. Autonomous Agents and Multi-Agent Systems, 8(3), 203-236. Brinkkemper, S. (1996). Method engineering: engineering of information systems development methods and tools. Inf. Software Technol., 38(4), 275280. Brinkkemper, S., Saeki, M., & Harmsen, F. (1998). Assembly techniques for method engineering. In Proceedings of CAISE 1998 (pp. 381-400). Berlin: Springer-Verlag. 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, LNCS 2222 (pp. 119135). Berlin: Springer-Verlag. Cernuzzi, L. & Rossi, G. (2002). On the evaluation of agent oriented methodologies. In Proceedings of OOPSLA 2002 Workshop on Agent-Oriented Methodologies, Centre for Object Technology Applications and Research, Sydney, Australia (pp. 21-30).
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
382
Henderson-Sellers
Cockburn, A.S. (2000). Selecting a project’s methodology. IEEE Software, 17(4), 64-71. Cossentino, M. & Potts, C. (2002). A CASE tool supported methodology for the design of multi-agent systems. In H.R. Ababnia & Y. Mun (Eds.), Presented at the 2002 International Conference on Software Engineering Research and Practice: Proceedings of the International Conference on Software Engineering Research and Practice (SERP’02), Las Vegas, June 24-27 (pp. 315-321) Dam, K.H. & Winikoff, M. (2004). Comparing agent-oriented methodologies. In P. Giorgini, B. Henderson-Sellers, & M. Winikoff (Eds.), Agent-Oriented Systems, LNAI 3030 (pp. 778-93). Berlin: Springer-Verlag. 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. 160190). Hershey, PA: Idea Group Publishing. Durfee, E.H. (2001). Scaling up agent coordination strategies. IEEE Computer, 34(7), 39-46. Finin, F., Labrou, Y., & Mayfield, J. (1997). KQML as an agent communication language. In J. Bradshaw (Ed.), Software agents (pp. 291-316). Cambridge, MA: MIT Press. Firesmith, D.G. & Henderson-Sellers, B. (2002). The OPEN process framework. Harlow, UK: Addison Wesley. Fitzgerald, B., Russo, N.L., & O’Kane, T. (2003). Software development method tailoring at Motorola. Comm. ACM, 46(4), 65-70. Gomez-Sanz, J. & Pavon, J. (2003). Agent oriented software engineering with INGENIAS. In V. Marik, J. Müller, & M. Pechoucek (Eds.), Multi-agent systems and applications III. The Third International Central and Eastern European Conference on Multi-Agent Systems (CEEMAS 2003), Prague, Czech Republic, June, (LNCS 2691, pp. 394-403). Berlin: Springer-Verlag. Gonzalez-Perez, C., Henderson-Sellers, B., Debenham, J., Low, G.C., & Tran, Q.-N.N. (2004). Incorporating elements from CAMLE in the OPEN repository. In The Intelligent Information Process II: Proceedings of IIP, Beijing, October 21-23 (pp. 55-64). New York: Springer. Graham, I. (1995). A non-procedural process model for object-oriented software development. Report on Object Analysis and Design, 1(5), 10-11. Graham, I., Henderson-Sellers, B., & Younessi, H. (1997). The OPEN process specification. 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
384
Henderson-Sellers
ational methods. In Proceedings of CAISE 1997 (pp. 303-317). Berlin: Springer Verlag. Kraus, S. (2001). Strategic negotiation in multiagent environments. Cambridge, MA: MIT Press. Kumar, K. & Welke, R.J. (1992). Method engineering: A proposal for situationspecific methodology construction. In W.W. Cotterman & J.A. Senn (Eds.), Systems analysis and design: A research agenda (pp. 257-269). New York: John Wiley and Sons. Müller, J.P. (1996). The design of intelligent agents. Berlin: Springer-Verlag. Nguyen, V.P. & Henderson-Sellers, B. (2003). OPENPC: A tool to automate aspects of method engineering. In Proceedings of ICSSEA 2003, Paris, December 2-4 (pp. 1-8). ICSSEA. Odell, J. (2000). Objects and agents: How do they differ? JOOP, 13(6), 50-53. Odell, J. (2001). Key issues for agent technology. JOOP, 13(9), 23-27, 31. Odell, J., van dyke Parunak, H., & Bauer, B. (2000). Extending UML for agents. In G. Wagner, Y. Lesperance, & E. Yu (Eds.), Proceedings of AgentOriented Information Systems Workshop, 17th National Conference on Artificial Intelligence (pp. 3-17). Austin, TX. OMG (2002). Software Process Engineering Metamodel Specification, Version 1.0, Object Management Group, formal/02-11-14, Nov 2002. Padgham, L. & Winikoff, M. (2002). Prometheus: A pragmatic methodology for engineering intelligent agents. In J. Debenham, B. Henderson-Sellers, N. Jennings, J.J. Odell (Eds.), Proceedings of the Workshop on Agentoriented Methodologies at OOPSLA 2002, November 4, Seattle (pp. 97108). Sydney: Centre for Object Technology Applications and Research. Padgham, L. & Winikoff, M. (2004). Developing intelligent agent systems: A practical guide. Chichester, UK: John Wiley & Sons. Pavón, J., Gomez-Sanz, J., & Fuentes, R. (2005). The INGENIAS methodology and tools. In B. Henderson-Sellers & P. Giorgini (Eds.), Agent-oriented methodology, Chapter 4. Hershey, PA: Idea Group Publishing. Ralyté, J. & Rolland, C. (2001). An assembly process model for method engineering. In Proceedings of the 13th Multi International Conference on Advanced Information Systems Engineering, CAISE’01, Interlaken, Switzerland. June 6-8. LNCS2068 (pp. 267-283). Berlin: Springer-Verlag. Ralyté, J., Rolland, C., & Deneckère, R. (2004). Towards a meta-tool for change-centric method engineering: A typology of generic operators. In A. Persson & J. Stirna (Eds.), Proceedings of CAiSE2004). LNCS 3084 (pp. 202-218). 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
Creating a Comprehensive Agent-Oriented Methodology
385
Rao, A.S. & Georgeff, M.P. (1995). BDI agents: From theory to practice. In V.R. Lesser & L. Gasser (Eds.), Proceedings of First International Conference on Multi Agent Systems, San Francisco (pp. 312-319). Cambridge, MA: MIT Press. Reenskaug, T., Wold, P., & Lehne, O.A. (1996). Working with objects. The OOram software engineering manual. Greenwich, CT: Manning. Rolland, C., Prakash, N., & Benjamen, A. (1999). A multi-model view of process modelling. Requirements Eng. Journal, 4(4), 169-187. Saeki, M. (2003). CAME: The first step to automated software engineering. In Proceedings of Process Engineering for Object-Oriented and Component-Based Development. OOPSLA 2003 Workshop, (pp. 7-18). Centre for Object Technology Applications and Research, Sydney, Australia. Serour, M., Henderson-Sellers, B., Hughes, J., Winder, D., &Chow, L. (2002). Organizational transition to object technology: Theory and practice. In Z. Bellahsène, D. Patel, & C. Rolland (Eds.), Object-Oriented Information Systems (LNCS 2425, pp. 229-241). Berlin: Springer-Verlag. Silva, V. & Lucena, C. (2004). From a conceptual framework for agents and objects to a multi-agent system modeling language. Autonomous Agents and Multi-Agent Systems, 9(1-2), 145-189. Standards Australia (2004). Standard metamodel for software development methodologies, AS4651-2004, 23 August. Sydney, NSW: Standards Australia International. Sturm, A. & Shehory, O. (2004). A framework for evaluating agent-oriented methodologies. In P. Giorgini, B. Henderson-Sellers, & M. Winikoff (Eds.), Agent-oriented Systems, LNAI 3030 (pp. 94-109). Berlin: SpringerVerlag. Ter Hofstede, A.H.M. & Verhoef, T.F. (1997). On the feasibility of situational method engineering. Information Systems, 22, 401-422. Tran, Q.-N.N., Henderson-Sellers, B., & Debenham, J. (2004). Incorporating the elements of the MASE methodology into Agent OPEN. In I. Seruca, J. Cordeiro, S. Hammoudi, & J. Filipe (Eds.), Proceedings of ICEIS2004 (Vol. 4, pp. 380-388). Setubal, Portugal: INSTICC Press. van Slooten, K. & Hodes, B. (1996). Characterizing IS development projects. In S. Brinkkemper, K. Lyytinen, & R. Welke (Eds.), Proceedings of the IFIP TC8 Working Conference on Method Engineering: Principles of method construction and tool support (pp. 29-44). London: Chapman& Hall. Wagner, G. (2003). The agent-object relationship metamodel: Towards a unified view of state and behaviour. Inf. Systems, 28(5), 475-504.
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
388
Henderson-Sellers
SUBTASK NAME: Define actuator module Typical supportive techniques: Environmental evaluation Explanation: Define for each agent the primitive actions that can be directly executed by the agent on the environment. To promote reusability, sets of primitive actions can be packaged into actuator components that are later bound to agents. SUBTASK NAME: Define perceptor module Typical supportive techniques: Environmental evaluation Explanation: Define for each agent its required sensing abilities and mechanisms needed to convert raw data/percepts to beliefs. To promote reusability, sensing abilities and mechanisms can be packaged into perceptor components that are later associated to agents. TASK NAME: Determine agent communication protocol Focus: Agent interactions Typical supportive techniques: FIPA KIF compliant language Explanation: Communication protocols underpin the interaction protocols by determining the actual form of messages plus languages and ontologies to be used for their coding. KQML Knowledge Query and Manipulation Language (KQML) is an example of an agent communication language (ACL) (Finin, Labrou, & Mayfield, 1997), a second being the Foundation for Intelligent Physical Agents (FIPA)’s ACL (Odell, 2000). Both are based on speech acts. If agent A wishes to tell agent B something, it does so by posting a message to agent B’s message area (direct inter-agent communication is also possible, but infrequently utilized) (Odell, 2001). TASK NAME: Determine agent interaction protocol Focus: Agent interactions Typical supportive techniques: Contract nets Explanation: The agent interaction protocol determines how the agents in a system may converse (Kraus, 2001). It specifies what they are allowed to “say” to each other. Agents may cooperate or compete with each other (Durfee, 2001). For competitive agents, the objective of the interaction protocol may be to maximise the utility of the individual agents. Since agents are cooperative, a key issue in designing the interaction protocol for cooperative agents is to ensure that the whole system behaves in a coherent way without stifling the autonomy of the individual agents. Another issue
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
Creating a Comprehensive Agent-Oriented Methodology
387
between any pair of agents. The construction of agent conversations can be accomplished by identifying all possible states and transitions, which are themselves in turn derived from an analysis of the sequence diagrams and tasks. TASK NAME: Construct the agent model Focus: Static architecture Typical supportive techniques: Control architecture; Intelligent agent identification Explanation: An analogue of the “agent model,” analogous to the “object model” in an OO approach, needs to be constructed as the main description of the static architecture. This model shows the agents, their interfaces, and their connectivity with other agents and objects being designed. TASK NAME: Define ontologies Focus: Domain conceptualization Typical supportive techniques: Domain analysis Explanation: A conceptualization of the target application domain needs to be specified. This conceptualization should contain all the concepts, entities, and relationships that exist in the domain and that are relevant to the needs of agents in the system (e.g., communication and internal processing needs). TASK NAME: Design agent internal structure Focus: Internal structure of agents Typical supportive techniques: 3-layer BDI model; Agent internal design; Reactive reasoning Explanation: Using an appropriate model for the internal agent architecture, such as the BDI model, the internal structure of each agent needs to be determined, depending on the agent’s reasoning paradigm (e.g., deliberative or reactive) and complexity. If a hybrid architecture is used, then both Event-Condition-Action (ECA) rules and Inference (I) rules may be needed. If using a BDI architecture, then goals and plans will be needed (see Agent OPEN Tasks: Model goals and Model plans). With two new subtasks 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
Creating a Comprehensive Agent-Oriented Methodology
389
for cooperative agent interaction is how to coordinate their activities, particularly when access to resources is limited; this is achieved with a coordination protocol (e.g., Wobcke & Sichanie, 2000). A common strategy for cooperative interaction protocols is the decomposition and distribution of tasks. This may be achieved by a “delegation strategy” (q.v.) coupled with the contract net mechanism with focussed addressing. TASK NAME: Determine control architecture Focus: Internal agent architecture Typical supportive techniques: Activity scheduling; Belief revision of agents; Commitment management; Control architecture; Task selection by agents Explanation: In a typical three-layer, BDI hybrid-agent architecture, the control architecture may be non-deterministic; that is, options are evaluated based on the agent’s beliefs. These options plus existing commitments lead to committed goals. Once a goal is identified (and committed to), a plan needs to be developed and effected. TASK NAME: Determine delegation strategy Focus: Internal agent architecture Typical supportive techniques: Agent delegation strategies Explanation: The delegation strategy is part of the interaction protocol; it determines “what should be delegated to whom.” Each agent manages the work of its user and deals with the delegation of responsibility for subprocesses to other agents. This delegation is achieved by inviting a selected set of nodes to bid for work. A bid from a node contains information on the preferred constraints that that user presently has, together with information about that user’s work — including an estimate of the cost, in time, that that user may incur. A delegation strategy may attempt to balance some of the three conflicting principles: maximising payoff, maximising opportunities for poor performers to improve, and balancing workload (Wooldridge & Jennings, 1998). Various delegation strategies are available. TASK NAME: Determine reasoning strategies for agents Focus: Internal agent architecture Typical supportive techniques: Deliberative reasoning: plans; Reactive reasoning: ECA rules Explanation: There are several reasoning strategies. The best known are deliberative, reactive, and hybrid (Müller, 1996). For example, the agents used for process management are three-layer, BDI hybrid agents 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
390
Henderson-Sellers
exhibit both deliberative and reactive reasoning. In other applications, it may be possible to use just one of these forms of reasoning. For example, in agent terms an expert system is a reactive system. TASK NAME: Determine security policy for agents Focus: Agent security Typical supportive techniques: No specific techniques identified to date Explanation: Distributed systems attract additional security risks. This is particularly true for an agent-oriented system when agents are (potentially, at least) mobile (a future OPEN Task “Model agent mobility”). Risks include unauthorized disclosure or alteration, denial of service, and spoofing (Odell, 2001). A policy must be determined on how to access resources in a secure manner. Most policies are based on agent identity, itself based on the notion of credential. TASK NAME: Determine system operation Focus: System level Typical supportive techniques: Activity scheduling; Commitment management; Learning strategies for agents; Belief revision of agents; Task selection by agents Explanation: Determining the system operation for agents remains a research issue. By including the Task here into the OPEN Process Framework, we are acknowledging the need for such a Task and affiliated Techniques even though the details of these are not yet fully understood or described, currently being the focus of much research worldwide. TASK NAME: Gather performance knowledge Focus: Performance Typical supportive techniques: Learning strategies for agents; Performance evaluation Explanation: To deal with selection and delegation, performance knowledge is gathered. This comprises performance statistics on the operation of every agent, plan, and activity. A set of basic parameters is described here. More recent work includes observations on the relationships between the human users in the system, in particular the extent to which one human can trust or rely on another.
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
386
Henderson-Sellers
Wobcke, W. & Sichanie, A. (2000). Personal diary management with fuzzy preferences. In Proceedings of the Fifth International Conference on the Practical Application of Intelligent Agents and Multi-Agents (pp. 105-120). Manchester, UK: The Practical Application Company. Wooldridge, M. & Ciancarini, P. (2001). Agent-oriented software engineering: The state of the art. In P. Ciancarini & M. Wooldridge (Eds.), Agentoriented software engineering (pp. 1-28). Berlin: Springer-Verlag. Wooldridge, M. & Jennings, N.R. (1998). Pitfalls of agent-oriented development. In K.P. Sycara & M. Wooldridge (Eds.), Proceedings of the 2nd International Conference on Autonomous Agents, Minneapolis/St. Paul, MN (pp. 385-391). New York: ACM Press. Wooldridge, M., Jennings, N.R., & Kinny, D. (2000). The Gaia methodology for agent-oriented analysis and design, J. Autonomous Agents and MultiAgent Systems, 3(3), 285-312. Yu, E. & Cysneiros, L. (2002). Agent-oriented methodologies - Towards a challenge exemplar. In P. Giorgini, Y. Lespérance, G. Wagner, & E. Yu (Eds.), Agent-Oriented Information Systems 2002, Procs. AOIS-2002 (pp. 47-63). AOIS.org. Zambonelli, F., Jennings, N., & Wooldridge, M. (2003). Developing multiagent systems: The Gaia methodology. ACM Transaction on Software Engineering and Methodology, 12(3), 317-370.
Appendix: New Tasks and Subtasks for Agent OPEN In this appendix are collected together all the newly proposed Tasks and Subtasks for OPEN. These have been identified in the study of the various extant AO methodologies and are listed here, as is normal OPEN practice, in alphabetical order. TASK NAME: Construct agent conversations Focus: Detailed agent-agent interactions Typical supportive techniques: Collaborations analysis; Interaction modelling; Scenario development; State modelling Explanation: Interactions and their protocols are modelled in agent-oriented systems by conversations that formally define the coordination protocol
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
Creating a Comprehensive Agent-Oriented Methodology
391
TASK NAME: Identify emergent behaviour Focus: System level Typical supportive techniques: No specific techniques identified to date Explanation: Emergent properties are those properties that exist at the system level but that cannot be predetermined by inspection of the properties of the individual elements of the system. For example, a colony of ants has an overall behaviour not reflected in the behaviour of any one individual, whose behaviour when studied appears to be almost random. Since these emergent properties are not deterministic, there is a challenge for the designer in identifying likely emergent behaviour. Such emergent behaviour is often critical for the success of a system. TASK NAME: Identify system behaviours Focus: Modelling of system functionality Typical supportive techniques: Functional analysis techniques such as CRC modelling, Scenario development, Hierarchical task analysis, Responsibility identification, Service identification. Explanation: Elementary activities required to fulfil the system’s goals and/or tasks need to be identified. These will later be performed by the system actors (in this case, agents) to achieve the collective goals and/or tasks. TASK NAME: Identify system organization Focus: System level Typical supportive techniques: Environmental evaluation; Role modelling Explanation: It is necessary to identify what are the agents in the system, what are their roles, to whom they report (in the system or in the environment), to what extent and with which other agents they communicate, and to which databases do they have access. Evaluating the system organization for an MAS is highly analogous to the problem of identifying how a (human) office works. With five new subtasks of: SUBTASK NAME: Determine agents’ organizational behaviours Typical supportive techniques: Collaborations analysis; Control Architecture; Contract nets; Market Mechanisms
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
392
Henderson-Sellers
Explanation: Activities to be performed, or rules to be adhered to, by each agent when playing its organizational role need to be specified. These activities and rules define how the agent behaves and coordinates with other agents when the organization is formed, changed, or dissolved. SUBTASK NAME: Determine agents’ organizational roles Typical supportive techniques: Collaborations analysis; Control Architecture; Contract nets; Market Mechanisms Explanation: At run-time, agents can dynamically organize/re-organize themselves. Roles of each agent within this dynamic organization should be predicted at the design time. For example, if agents need to form dynamic groups at run-time, organizational roles of “group initiator” and “group participant” need to be assigned to agents. SUBTASK NAME: Identify sub-organizations Typical supportive techniques: No specific techniques identified to date Explanation: This task analyses the target system organization to identify suborganizations that co-exist as autonomous interacting MASs. SUBTASK NAME: Define organizational rules Typical supportive techniques: Responsibility identification Explanation: This subtask is focussed on modelling the responsibilities of the organization as a whole in terms of liveness and safety organizational rules. SUBTASK NAME: Define organizational structures Typical supportive techniques: No specific techniques identified to date Explanation: This subtask is focussed on selecting an organizational structure that offers the most appropriate topology and control regime. TASK NAME: Model actors Focus: People, other systems, and roles involved Typical supportive techniques: Business process modelling; Soft systems analysis Explanation: While the concept of actors in OO systems already exists (and is supported in the original OPEN), the Tropos methodology extends the OO notion of an actor beyond that of a single person/system/role interacting with a system to that of a more general entity that has strategic goals 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
394
Henderson-Sellers
With two new subtasks of: SUBTASK NAME: Model responsibilities Typical supportive techniques: Role modelling Explanation: This subtask models the accepted OO responsibilities (knowing, doing, enforcing) but classified in terms of liveness and safety properties, which are relevant to agents rather than objects. SUBTASK NAME: Model permissions Typical supportive techniques: Responsibility identification; Role modelling Explanation: Permissions are associated with the responsibilities allocated to each agent role. TASK NAME: Model capabilities for actors Focus: Capability of each actor in the system Typical supportive techniques: Capabilities identification and analysis Explanation: The capability of an actor represents its ability to define, choose, and execute a plan (for the fulfilment of a goal), given specific external environmental conditions and a specific event (Bresciani et al., 2004). Capability modelling commences after the architecture has been designed, subsequent to an understanding of the system sub-actors and their interdependencies. Each system sub-actor must be provided with its own individual capabilities, perhaps with additional “social capabilities” for managing its dependencies with other actors/sub-actors. Previously modelled goals and plans generally now become an integral part of the capabilities. Capabilities can be depicted using (Tropos) Capability Diagrams and Plan Diagrams (q.v.). TASK NAME: Model dependencies for actors and goals Focus: How/if an actor depends on another for goal achievements Typical supportive techniques: Agent delegation analysis; Contribution analysis Explanation: In Tropos, a dependency may exist between two actors so that one actor depends in some way on the other in order to achieve its own goal—a goal that cannot otherwise be achieved or not as well or as easily without involving this second actor. Similarly, a dependency between two actors may exist for plan execution or resource availability (Bresciani et al.,
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
Creating a Comprehensive Agent-Oriented Methodology
395
2004). The actors are named, respectively, the depender and the dependee, while the dependency itself centres around the dependum. Dependencies can be depicted using (Tropos) Actor Diagrams and, in more detail, in Goal Diagrams (q.v.). TASK NAME: Model goals Focus: Actor’s strategic interests Typical supportive techniques: Contribution analysis; AND/OR decomposition; Means-end analysis Explanation: A goal represents an actor’s strategic interests (Bresciani et al., 2004) – Tropos recommends both hard and soft goals. Modelling goals requires the analysis of those actor goals from the viewpoint of the actor itself. The rationale for each goal relative to the stakeholder needs to be analysed. Goals may be decomposed into subgoals, either as alternatives or as concurrent goals. Plans may also be shown together with their decomposition, although details of plans are shown in a Plan Diagram (q.v.). Goals can be depicted using (Tropos) Goal Diagrams (q.v.). TASK NAME: Model plans Focus: Means to achieve goals Typical supportive techniques: AND/OR decomposition; Contribution analysis; Means-end analysis Explanation: A plan represents the means by which a goal can be satisfied or, in the case of a soft goal, satisficed (Bresciani et al., 2004). Plan modelling complements goal modelling (q.v.) and rests on reasoning techniques analogous to those used in goal modelling. Plans can be depicted using (Tropos) Goal Diagrams and Plan Diagrams (q.v.). TASK NAME: Model the agent’s environment Focus: System level Typical supportive techniques: Business process modelling; Environmental resources modelling; Role modelling Explanation: Agents, unlike objects, are situated in an environment—they interact with it by observing and by changing it. The “robot” paradigm is often used to illustrate the difference between agents and objects – an agent’s “sensors” and “effectors” are physical or virtual devices by which it interacts with its 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
Creating a Comprehensive Agent-Oriented Methodology
393
intentionality within the system or organizational setting (Bresciani et al., 2004), including also, for example, whole organizations, organizational units, and teams. Actors in Tropos can represent either agents (both human and artificial) or roles or positions (a set of roles, typically played by a single agent). This new Task thus considerably extends the existing concepts related to traditional OO actors. To model an actor, one must identify and analyse actors of both the environment and the system (or system-to-be). Tropos encourages the use of this Task in the early requirements phase for the modelling of domain stakeholders and their intentions as social actors. Actors can be depicted using (Tropos) Actor Diagrams (q.v.). TASK NAME: Model agent knowledge Typical supportive techniques: Deliberative reasoning; Domain analysis; Reactive reasoning; Rule modeling. Explanation: For each agent, elements of knowledge that allow the agent to reason and to interact need to be defined. These include domain-specific, task-specific, inference and problem-solving knowledge. TASK NAME: Model agent relationships Typical supportive techniques: Generalization and inheritance identification; Multiple inheritance; Relationship modelling Explanation: Aggregation relationships need to be defined for agents that are composed of sub-agents, while inheritance relationships are needed for agents that inherit from the attributes of their superclasses (e.g., inherited goals or knowledge). TASK NAME: Model agents’ roles Focus: Agent design Typical supportive techniques: Responsibility identification; Role modelling Explanation: A good metaphor for assisting in agent design is identifying what roles they are intended to play. Roles are applied to agents by, for example, Wooldridge and Ciancarini (2001) in much the same way as they are applied to objects in OOram (Reenskaug, Wold, & Lehne, 1996) and supported in OPEN (Henderson-Sellers et al., 1998). In Gaia (Wooldridge et al., 2000), roles are defined by four attributes. Responsibilities are similar to those defined for objects but classified by liveness and safety properties. A set of permissions is then allocated to each agent to support these responsibilities. Computations are performed by a set of internal Actions (also called Activities5), and there are a number of associated Protocols that govern external Interactions. This task focusses on the identification of the roles per se, together with this associated attribute set. Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
396
Henderson-Sellers
With three new subtasks of: SUBTASK NAME: Model environmental resources Typical supportive techniques: Environmental evaluation; Environmental resources modellings Explanation: Environmental resources are abstract computational resources that are available to agents for sensing, effecting, or consuming. SUBTASK NAME: Model events Typical supportive techniques: Event modelling Explanation: This task focusses on modelling the events that result from changes in the environment, which are then recognized by the agent itself as an input to its own internal reasoning. SUBTASK NAME: Model percepts Typical supportive techniques: Environmental evaluation Explanation: This task focusses on modelling the percept component of the agent’s environment. TASK NAME: Specify shared data objects Focus: Data storage Typical supportive techniques: Appropriate database-focussed techniques Explanation: Synchronization is required if several agents write to the same data storage object. Appropriate data-sharing mechanisms are needed. TASK NAME: Undertake agent personalization Focus: Agent design Typical supportive techniques: Environmental evaluation Explanation: In process management, Web, and CSCW applications, agents often represent actual people. People may undertake tasks in their business with different styles (say, within an office environment). The software agent must reflect the style of the person it is representing. Since these differences may be significant, this is an important task, which contributes to the overall agent 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
Creating a Comprehensive Agent-Oriented Methodology
397
There is also one subtask to be added to an existing (non AO) OPEN Task: SUBTASK NAME: Determine MAS infrastructure facilities MAIN TASK: Create a system architecture (Firesmith & Henderson-Sellers, 2002, p.273) Typical supportive techniques: Environmental evaluation Explanation: Facilities required to support the operation of an MAS as a whole and of its constituent agents should be identified, as well as how they are managed (e.g., by agents).
Endnotes 1
Sometimes called a methodbase (e.g., Brinkkemper, 1996; Ralyté & Rolland, 2001; Ter Hofstede & Verhoef, 1997).
2
For greater accuracy, Task should be renamed TaskKind, as in AS4651 (Standards Australia, 2004). However, for the present discussion, we will retain the (slightly ambiguous) name of Task.
3
Another choice might be OMG’s SPEM (OMG, 2002) or the Australian Standard 4651 (SMSDM) (Standards Australia, 2004), but these only provide a metamodel and have no associated method fragments.
4
As noted earlier, here we focus on the process component of a methodology and neglect, for the present, the product component. We will thus use the word “process” rather than “methodology” in the ensuing discussion.
5
Note that this is an entirely different meaning to word Activity from that as used in OPEN.
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
398 About the Authors
About the Authors Brian Henderson-Sellers is director of the Centre for Object Technology Applications and Research and professor of information systems at the University of Technology, Sydney (UTS). He has authored 11 books on object and agent technology and is well known for his work in methodologies (MOSES, COMMA, OPEN, OOSPICE) and in OO metrics. Dr. Henderson-Sellers has been regional editor of Object-Oriented Systems, a member of the editorial board of Object Magazine/Component Strategies and Object Expert for many years and is currently on the editorial board of Journal of Object Technology and Software and Systems Modelling and editor of the International Journal of Agent-Oriented Software Engineering. He was the founder of the Object-Oriented Special Interest Group of the Australian Computer Society (NSW Branch) and chairman of the Computerworld Object Developers’ Awards committee for ObjectWorld 94 and 95 (Sydney). He is a frequent, invited speaker at international OT and AO conferences. In 1999, he was voted number three in the Who’s Who of Object Technology (Handbook of Object Technology, CRC Press, Appendix N). He has recently been a member of the review panel for the OMG’s Software Process Engineering Model (SPEM) standards initiative and a member of the UML2.0 review team. He is also codeveloper of Australian Standard 4651-2004 for a standard metamodel for software development methodologies. In July 2001, Dr. Henderson-Sellers was awarded a Doctor of Science (DSc) from the University of London for his research contributions in object-oriented methodologies. Paolo Giorgini is researcher in computer science at the University of Trento. His research interests include agent-oriented software engineering, multi-agent system modeling and design, knowledge representation, and conceptual modeling. Dr. Giorgini has worked on the development of requirements and design languages for agent-based systems, and the application of knowledge representation techniques to software repositories and software 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
400 About the Authors
Council. He is now chairing the Foundation for Intelligent Physical Agents (FIPA) technical committee on development methodologies, and the AgentLink III technical forum group on Agent-Oriented Software Engineering (AOSE). His research interests mainly deal with AOSE and robotics. Scott DeLoach received a BS in computer engineering from Iowa State University (1982) and an MS and PhD in computer engineering from the Air Force Institute of Technology (1987 and 1996, respectively). After retiring from the U.S. Air Force in 2001, he became an assistant professor in the Department of Computing and Information Sciences at Kansas State University. His research focuses on applying software engineering methods, techniques, and models to the design and development of intelligent and autonomous multi-agent and cooperative robotic systems. Rubén Fuentes has been an assistant professor at Universidad Complutense de Madrid, Spain, since 2002. He has been working as consultant in database systems for four years. He is now a member of the grasia! research group on agent technologies at the same university. His main interests are multi-agent systems methodologies and incorporating the use of techniques from social sciences. Francisco J. Garijo received a PhD in applied mathematics from the University of Paris VI (1978) and a PhD in computer science from Universidad del Pais Vasco, Spain (1981). Since 1989, he has been at Telefónica I+D where he leads a group involved in distributed computing for advanced networks and multi agent systems. Garijo has participated in several European R&D projects—ESPRIT, RACE, IST, and EURESCOM, and national projects in the fields of software engineering, service creation, and service management in telecommunication networks, and artificial intelligence (dialogue management systems, language design, distributed systems, and intelligent multi-agent systems). He has been an associate professor of computer science and artificial intelligence at several Spanish universities including Universidad del Pais Vasco, Universidad Politecnica de Catalunya, and Universidad Carlos III de Madrid. He has also collaborated with the UE as an expert evaluator for R&D Programs* *ESRPRIT Long term research and FET. Garijo has co-edited several Springer-Verlag books on MAS technology and published more than 50 scientific papers in international conference proceedings, book chapters, and reviewed journals. He was chairman of the Spanish Artificial Intelligence Association (AEPIA) (1992-2001). He also served as a PC member of the main conferences in AI and multi-agent systems, such as IJCAI, ECCAI, ICMAS, MAAMAW, Agents, IBERAMIA AEPIA, and others. At present, he is a member of the executive committee of IBERAMIA Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
About the Authors 399
His publication list includes refereed journal and conference proceedings papers and four edited books. He has served as chair and program committee member for international conferences or several organizations, including, CoopIS, ER, CAiSE, AAMAS, EUMAS, AOSE, AOIS, and ISWC. He is also the editor of the International Journal of Agent-Oriented Software Engineering. *
*
*
*
*
Carole Bernon is a lecturer at the University Paul Sabatier in Toulouse (France), where she obtained a PhD in computer science in the distributed systems field. In the last few years, her research centres of interest have been multi-agent systems, specifically, adaptive ones, and agent-oriented software engineering. Valérie Camps received her PhD in computer science from the University Paul Sabatier (Toulouse, France) (1998). She is currently a lecturer at the same university. She has been working on multi-agent systems for the past ten years. Her interests include adaptive complex systems, self-organization, learning, information retrieval, and behaviors modelling. Jaelson Castro is an adjunct professor at Universidade Federal de Pernambuco, Brazil, where he leads the Requirements Engineering Laboratory. His research interests include requirements engineering, multi-agent systems, software architecture, object-oriented analysis and design, and aspect-oriented development. He acted as co-chair of the Workshop on Software Engineering for Large-Scale Multi-Agent Systems (2002), conference chair of the Fourth International Conference on the Unified Modeling Language (2001), co-chair of the Workshop from SofTware Requirements to Architectures (2001), co-chair of the Workshop on Interactive System Development and Object Models (1999), and served twice as conference chair of the Brazilian Software Engineering Symposium (1995 and 2004). He has published more than 100 papers and book chapters. He is a member of the IEEE Computer Society and the Brazilian Computer Society. Massimo Cossentino received his Laurea degree in electronics engineering from the University of Palermo (1993), defending a thesis on the design and development of e-learning applications. He received a PhD in computer science engineering from the University of Palermo (2001), with a thesis on the design of multi-agent systems. Since the end of 2001, he has been a staff researcher of the Instituto di Calcolo e Reti ad Alte Prestazioni of the Italian National Research Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
About the Authors 401
(IBERAMIA groups the Artificial Intelligence Societies from Spanish and Portuguese speaking countries: Central and South America countries, Spain and Portugal). Mercedes Garijo is associate professor at the Department of Telematic Systems Engineering of the Technical University of Madrid where she received her MD and PhD in telecommunication engineering. She teaches at the School of Telecommunication Engineering (undergraduate, postgraduate, and doctorate levels) in computer science and communications topics. Her recent research interests have focused on artificial intelligence and software engineering, mainly in the development of methodologies and tools for agents design, and their application in network management and Web services. She has been responsible for several research and development projects funded by EC and Spanish government. Marie-Pierre Gleizes is a lecturer at the University Paul Sabatier of Toulouse (France). She works on adaptive multi-agent systems and, in particular, methodologies to design this kind of systems. She participated in several program committees (including RFIA, JFSMA, MAAMAW, AAMAS, ESAW, SELMAS, COOP, etc.) and she is co-chair of the Technical Forum Group on selforganization in multi-agent systems in Agentlink III. Jorge J. Gómez-Sanz obtained a PhD in computer science from Universidad Complutense de Madrid, Spain (2002). He works as an associate professor in the Facultad de Informática of the same university, lecturing students in objectoriented programming and other engineering subjects. Currently, he belongs to the grasia! research group and is one of its founders. His research is centered on multi-agent systems development according to agent-oriented software engineering practices. A main result of this research was his PhD, which defined the INGENIAS methodology and its support tools. He has also participated in European agent-related projects such as DEMOS (IST-1999-20530), PSI3 (IST-1999-11056) and MESSAGE (Eurescom P907). Carlos A. Iglesias is an associate professor at the Technical University of Madrid, where he is investigating agent-oriented methodologies at the Intelligent Systems Group. He holds a PhD and BSc in telematic system engineering from the Technical University of Madrid. He teaches at undergraduate, postgraduate, and doctorate levels on several computer science topics (telematics, software engineering, and intelligent systems). He has been actively involved in research projects funded by National and European programs, as well as by private companies. He has published several papers in technical magazines, book chapters, and international conference 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
402 About the Authors
Manuel Kolp is an associate professor in information systems at the University of Louvain, Belgium, and an invited associate professor with the University of Brussels. His research work deals with agent oriented and social architectures for e-business systems. He is also a lead investigator on several projects for industries, public administrations, and enterprises dealing with knowledge, information, and data systems. Before that, he was a post-doctoral fellow with the Department of Computer Science and an invited lecturer with the Faculty of Information Studies at the University of Toronto. He has been actively involved in the organization committee of different international conferences, including UML 2001, CAiSE 2002, and VLDB 2004. Nick Jennings is a professor of computer science in the 5*-rated School of Electronics and Computer Science, Southampton University, where he carries out basic and applied research in agent-based computing. He is deputy head of school (research), head of the Intelligence, Agents, Multimedia Group (which consists of some 120 research staff and postgraduate students) and is also the chief scientific officer for Lost Wax. He has published more than 250 articles and six books on various facets of agent-based computing and holds two patents (three more pending). He is in the top 100 or so most-cited computer scientists (out of 750,000) according to the CiteSeer digital library and has received a number of awards for his research, including: the Computers and Thought Award (the premier award for a young AI scientist) in 1999 (this is the only time in the Award’s 30-year history that it was given to someone based in Europe), an IEE Achievement Medal in 2000, and the ACM Autonomous Agents Research Award in 2003. He is a fellow of the British Computer Society, the Institution of Electrical Engineers, and the European artificial intelligence association (ECCAI), and a member of the UK Computing Research Committee (UKCRC). Graham C. Low is a professor of information systems at the University of New South Wales, Australia. He received a PhD from the University of Queensland, Australia. His main research interests include agent-oriented software engineering, distributed systems, software process, software sizing and productivity, and software quality. Prior to joining the school in 1987, he had more than 10 years’ MIS experience in the industry. John Mylopoulos holds the Bell Laboratories Chair in information systems in the Department of Computer Science, University of Toronto. His research interests include semantic data models, requirements engineering, and knowledge management. He is the recipient of the first Outstanding Services Award given by the Canadian AI Society (CSCSI), a co-recipient of the Most Influential Paper Award of the 1994 International Conference on Software Engineering, 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
About the Authors 405
pervasive computing, agent-oriented software engineering, and self-organization in distributed systems engineering. In these areas, he has published more than 130 papers in international fora, co-edited seven books, received several best paper awards, and has been invited speaker and tutorialist in several international conferences and workshops. He is member of the program committee of several major conferences and workshops. He is the co-founder of the workshop series on “Engineering Societies in the Agents’ World” and of “Engineering Self-Organising Applications.” He has been member of the management committee of the European Network of Excellence «Agentlink II» (2000-2003) and, within the same network, coordinator of the Special Interest Group on «Methodologies and Software Engineering for Agent Systems». He is a member of IEEE, ACM, AIIA, and TABOO.
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
About the Authors 403
fellow of the American Association for AI (AAAI) and a past president of the VLDB Endowment. He is co-editor-in-chief of the Requirements Engineering Journal, and has served as program co-chair of IJCAI (1991), program chair of the International IEEE Symposium of Requirements Engineering (1997), and general chair of the Very Large Databases Conference (2004). Lin Padgham is an associate professor at the RMIT School of Computer Science and Information Technology, where she is leader of the Intelligent Information Systems Discipline and of the Intelligent Agents Group. She has worked in the United States, Sweden, and Australia, and earned her PhD from Linkoping University, Sweden. During the last eight years she has worked in the area of intelligent agents, working on a number of industry collaborative projects. She has developed and taught courses in agent technology and has also given invited tutorials on agent development. She has recently published the book, Developing Intelligent Agent Systems: A Practical Guide, together with Michael Winikoff. She is on the editorial board of The Journal for Autonomous Agents and Multi Agent Systems, and on the board of Autonomous Agents, as well as on program committees for major conferences such as AAMAS and IJCAI. Gauthier Picard received his BSc and MSc degrees in computer science from the University Paul Sabatier of Toulouse, France (2001). He is currently a PhD student at the same university, in the Institute of Research in Computer Science (IRIT), where his research interests include the design of self-organizing multiagent systems and the study of emergent phenomena. Kuldar Taveter (PhD, Eng.) is currently based at The University of Melbourne, Australia, on leave from his position as a research scientist at VTT Information Technology, Finland, which acts as a mediator between academy and industry. His main research interests are agent-oriented modelling and agent-based business process automation and supply-chain management based on it. He has also conducted research on business rules and electronic commerce by means of agents and ontologies. Quynh-Nhu Numi Tran is a PhD candidate in information systems at the University of New South Wales, Australia. Her dissertation is on the development of an agent-oriented methodology for multi-agent systems where ontology plays a central role in the design and operation of the systems. The methodology improves on the existing agent-oriented methodologies and frameworks in that it provides explicit support for the specification and use of ontology in 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
404 About the Authors
Gerd Wagner is the professor of Internet technology at the Brandenburg University of Technology at Cottbus, Germany. His research interests include agent-oriented modelling and agent-based simulation, foundational ontologies, (business) rule technologies, and the Semantic Web. He is an active member of the European research network REWERSE.net and of the international standardization effort RuleML.org. Michael Winikoff is a senior lecturer at RMIT’s School of Computer Science and Information Technology. Together with Lin Padgham, he has been working in the field of intelligent agents for the last five years. They have recently written the book Developing Intelligent Agent Systems: A Practice Guide (Wiley), which describes the Prometheus methodology. Michael was co-chair of the Workshop on Agent-Oriented Information Systems at the international conference on Autonomous Agents and Multi-Agent Systems (AAMAS) (2002 and 2003). Michael Wooldridge is head of department and professor of computer science in the Department of Computer Science, University of Liverpool, UK. He has been active in the research and development of multi-agent systems for more than ten years, and is internationally known for his work in this area. Professor Wooldridge has published more than 100 articles in the theory and practice of agent-based systems; his research monograph, “Reasoning about Rational Agents,” was published by The MIT Press in 2000, and his introductory textbook An Introduction to Multiagent Systems was published by Wiley in 2002. He has also edited 11 books in the subject area. He has served on many program committees for conferences and workshops in the area, is general chair of the Second International Conference on Autonomous Agents and Multi-agent Systems (AAMAS) held in Melbourne, Australia (July 2003), and is an elected director of the International Foundation for Multi-Agent Systems (IFMAS). He is also editor-in-chief of the International Journal of Autonomous Agents and Multi-Agent Systems (Kluwer), and an editorial board member for the Journal of Applied AI (Taylor & Francis), Journal of Applied Logic (Elsevier), Knowledge, Rationality, and Action (Kluwer), and The Knowledge Engineering Review (Cambridge). He is founder and associate coordinator of AgentLink, the EC-funded European Network of Excellence in the area of agent-based computing (http://www.AgentLink.org/). Franco Zambonelli has been associate professor at the University of Modena and Reggio Emilia since 2001. He obtained the Laurea degree in electronic engineering (1992) and a PhD in computer science (1997), both from the University of Bologna. His current research interests include distributed 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
406 Index
Index A AAII 7 abstract computational resources 148 abstraction 346 abstraction levels 288 action event 282 action event type 287 actions 9 activities in ADELFE 183 activity 296 activity diagram 297 activity theory (AT) 254 activity type 297 actor 21, 51 actor diagrams 24 actor in focus 296 adaptability 36, 347 adaptive customer service OSS (ACSOSS) 227 adaptive multi-agent systems (AMAS) 173, 174, 279 ADELFE 4, 7, 13, 252 ADELFE limitations 197 ADELFE methodology 172, 183, 279 ADELFE process 183 ADELFE strengths 196 agent 208 agent architectures 252 agent behaviour 9, 225 agent classes 324, 331
Agent Communication Language (ACL) 190 agent design 63 agent diagrams 245 agent identification 93 agent identification phase 87 agent implementation model 83 agent in PASSI 84 agent interaction protocol 97 agent interactions 122 agent model 46, 48, 55, 67, 160 agent modelling 55 agent nature 344 agent network design 62 agent platforms 252 agent role types 295 agent society infrastructure 226 agent society model 83 agent types 119 Agent Unified Modeling Language (AUML) 27, 122 agent viewpoint 241 agent-based systems 156 agent-object-relationship (AOR) modelling 277 agent-object-relationship simulation (AORS) 299 agent-oriented (AO) approach 204 agent-oriented (AO) methodologies 1 agent-oriented analysis 203 agent-oriented conceptual thinking 368
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
Index 407
agent-oriented methodologies 1, 46, 341, 368 agent-oriented programming 110 agent-oriented programming and design 112 agent-oriented programming (AOP) paradigm 5 agent-oriented software 20, 128 agent-oriented software engineering (AOSE) 204, 277, 342 agent-platform detailed design 214 agent-UML (AUML) 27, 122 agent/role model 206 AgentFactory 82 agents behavior description phase 99 agents structure definition phase 97 agent’s working memory 208 aggregation 93 AMAS adequacy tool 177 analysis 12, 47, 66, 210 analysis phase 148, 319 analysis-elaboration stage 262 analysis-inception stage 259 ant algorithms metaphor 138 AO methodologies 2, 5, 379 AOR 7, 13 AOR activity diagrams 294 AOR agent diagram 290 AOR agent diagrams 290 AOR interaction frame diagrams 290 AOR interaction sequence diagrams 290 AOR interaction-frame diagram 293 AOR interaction-pattern diagrams 294 AOR interaction-sequence diagram 293 AOR modelling 277 AOR Modelling Language 285, 298 AOSE methodology 203, 345 application domain 344 aptitude module 175 architectural design 22, 24, 34, 111, 119, 153, 166 artificial intelligence (AI) 7, 280 association 93 AUML 6, 371 AUML notation 180 Australian Bureau of Meteorology 128 autonomous agent 3
autonomous individuals 138 autonomous PSMs 60 autonomy 4, 346 availability 36
B base type 284 BDI paradigm 280 behaviour 3 behaviour aspect 304 behaviour implementation 288 behaviour-oriented approach 351 belief-desire-intention (BDI) model 109, 280 beliefs 280 beliefs, desires, and intentions (BDI) architecture 9 benevolence relationships 290 bidding 26 BOGAR_LN library 228 booking 26 BooksProvider 91 broker 26 business process interpreter 311 business use cases 293 business-to-consumer (B2C) 27
C call-for-proposal 26 CAMLE 8 Cassiopeia 8 characteristic of situatedness 3 class-responsibility-collaboration (CRC) 47 class-responsibility-collaboration (CRC) cards 47, 54 code completion phase 102 code generation facilities 253 code model 83 code reuse phase 101 coherence of an agent 161 collaborator 63 collect-coordinator-requirements 68 combined goal 321 commitment/claim type 287 commitments 280 common terms 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
408 Index
communicating agent 282 communication ability 347 communication model 46, 49 communication ontology description (C.O.D.) 93 communicative action event 282, 287 comparisons of these methodologies 8 complex adaptive systems (CAS) theory 4 complexity 346 computation-independent modelling (CIM) 288 computational information design 288 computational organizations 136, 138 computer-supported cooperative work (CSCW) 156 concepts 109 conceptual interaction modelling, 288 Conceptual Modelling Language (CML) 60 COnceptual Network (CONE) 310 conceptualisation 47, 48, 50, 64 concurrency 347 concurrent task model 322 consistency 346 consultant 90 contact manager 116, 120 ContactTracker 120 contradiction 254 contradiction patterns 254 control regime 144 control relationship 158 control relationships 290 conversations 324 cooperation module 175 cooperative agents 174 cooperative behaviour 347 cooperative PSMs 60 cooperative agent 180 coordination facilities 62 coordination model 46, 49, 57, 72 coordination modelling 55 customer relationship management (CRM) 311
D data coupling diagram 120 data structure 252
defining agents 2 deliberative behaviour 347 delivery 93 DeliveryNotifier 91 dependency 21, 290 dependency relation 158 dependency relationships 290 deployment configuration (D.C.) 102 deployment configuration phase 102 deployment design 325 deployment model 84 description 151 descriptors 117 design 12, 74, 211 design aptitudes 191 design characteristics 192 design model 46, 49, 62 design of the agent network 74 design phase 323 design process 146 design representations 192 design techniques 21 design-elaboration stage 267 design-inception stage 262 designing agent systems 110 detailed design 22, 26, 37, 111, 123, 160, 166 development 47 development lifecycle 344 domain (information) model 206 domain information viewpoint 300 domain knowledge 60 domain requirements description phase 86 domain-behaviour viewpoint 294, 300 domain-information viewpoint 294 domain-interaction viewpoint 289, 299 dynamic structure 348
E e-business application 258 early requirements 22 early requirements analysis 28 effectors 139 electronic commerce 156 embassy 26 emergence 4
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
New Releases from Idea Group Reference
Idea Group REFERENCE
The Premier Reference Source for Information Science and Technology Research ENCYCLOPEDIA OF
ENCYCLOPEDIA OF
DATA WAREHOUSING AND MINING
INFORMATION SCIENCE AND TECHNOLOGY AVAILABLE NOW!
Edited by: John Wang, Montclair State University, USA Two-Volume Set • April 2005 • 1700 pp ISBN: 1-59140-557-2; US $495.00 h/c Pre-Publication Price: US $425.00* *Pre-pub price is good through one month after the publication date
Provides a comprehensive, critical and descriptive examination of concepts, issues, trends, and challenges in this rapidly expanding field of data warehousing and mining A single source of knowledge and latest discoveries in the field, consisting of more than 350 contributors from 32 countries
Five-Volume Set • January 2005 • 3807 pp ISBN: 1-59140-553-X; US $1125.00 h/c
ENCYCLOPEDIA OF
DATABASE TECHNOLOGIES AND APPLICATIONS
Offers in-depth coverage of evolutions, theories, methodologies, functionalities, and applications of DWM in such interdisciplinary industries as healthcare informatics, artificial intelligence, financial modeling, and applied statistics Supplies over 1,300 terms and definitions, and more than 3,200 references
DISTANCE LEARNING
April 2005 • 650 pp ISBN: 1-59140-560-2; US $275.00 h/c Pre-Publication Price: US $235.00* *Pre-publication price good through one month after publication date
Four-Volume Set • April 2005 • 2500+ pp ISBN: 1-59140-555-6; US $995.00 h/c Pre-Pub Price: US $850.00* *Pre-pub price is good through one month after the publication date
MULTIMEDIA TECHNOLOGY AND NETWORKING
ENCYCLOPEDIA OF
ENCYCLOPEDIA OF
More than 450 international contributors provide extensive coverage of topics such as workforce training, accessing education, digital divide, and the evolution of distance and online education into a multibillion dollar enterprise Offers over 3,000 terms and definitions and more than 6,000 references in the field of distance learning Excellent source of comprehensive knowledge and literature on the topic of distance learning programs Provides the most comprehensive coverage of the issues, concepts, trends, and technologies of distance learning
April 2005 • 650 pp ISBN: 1-59140-561-0; US $275.00 h/c Pre-Publication Price: US $235.00* *Pre-pub price is good through one month after publication date
www.idea-group-ref.com
Idea Group Reference is pleased to offer complimentary access to the electronic version for the life of edition when your library purchases a print copy of an encyclopedia For a complete catalog of our new & upcoming encyclopedias, please contact: 701 E. Chocolate Ave., Suite 200 • Hershey PA 17033, USA • 1-866-342-6657 (toll free) • [email protected]
TEAM LinG
Index 409
engineering adaptive multi-agent systems 172 enhanced CRC cards 54 enterprise application integration (EAI) 311 enterprise resource planning (ERP) 22, 311 environment 141 environment viewpoint 246 environment-centred analysis 52 environmental model 148 expertise model 46, 48, 59, 69 eXtended Markup Language (XML) 278 external events 59 external primary actors 296 eXtreme Programming (XP) 47, 279
F fast prototyping 195 feature analysis approach 342 FIPA architecture 97 FIPA specifications 5 “flight occurrence” 216 Foundation for Intelligent Physical Agents (FIPA) 27, 190, 280 functionalities 116 fuzzy knowledge 175
G Gaia 7, 13, 238, 368 Gaia analysis 153 Gaia context 160 Gaia interaction model 151 Gaia methodology 136, 141, 146, 164 Gaia process 162 Gaia services model 161 generalization 93 generic system engineering 342 goal 3, 9, 21, 22, 108, 208 goal hierarchy diagram 320 goal-based use case models 294 goal-oriented approach 351 goal-oriented behaviour 229 graph traversal algorithm 252 graphical user interface (GUI), 311
H high-level message sequence charts (HMSC) 58 human computer interaction 347
I i* 8, 21 incoming message 298 inference knowledge 60 inferential capability 347 information aspect 303 informer 90 INGENIAS 7, 13, 227 INGENIAS development kit (IDK) 236, 249 INGENIAS methodology 236 INGENIAS notation 236 INGENIAS process 247 initial prototype 253 initiator 151 inputs 151 institutional agent 282, 283, 286 interaction 209, 239 interaction aspect 301 interaction diagrams 119 interaction languages 190, 191 interaction model 159, 206 interaction module 175 interaction pattern diagram 287 interaction patterns 287 interaction protocol 110, 119, 209, 221 interaction viewpoint 243 interactions 139, 141 interactions roles 222 interactive tool 181 interchanged messages 58 internal events 59 internal use cases 54 iterations 85
J JACK 5, 112, 125 JACK development environment (JDE) 127, 128 JADE agents 110 JADE framework 215
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
Index 411
object-oriented process, environment, and notation 372 object-oriented programming 110 object-oriented software developer 238 object-oriented software engineering (OOSE) 48 ontology 63 ontology description phase 93 OO software development methodologies 12 OPEN 7 OPEN process architecture 375 OPEN repository 373, 374 open source CASE tools 237 open systems: 348 OPEN task 376 open-agent systems 164 OPEN-compliant methodologies 373 OPEN contract-driven life-cycle model 376 OPEN metamodel 373 OpenTool 179 operational core 25 operational environment 21 OrderPlacer 91 organisation model 46, 49, 55, 61, 73, 205, 223 organization 138, 148, 208 organization management 266 organization theory 24 organization viewpoint 240 organization-driven detailed design 223 organization-oriented approach 351 organizational abstractions 138 organizational environments 20 organizational metaphor 139 organizational patterns 157 organizational perspective 139 organizational protocols 159 organizational roles 159 organizational rules 141, 143, 152, 155 organizational software systems 21 organizational structure 141, 144, 154, 158 OTScript language 180 outgoing message 298 outputs 151 overall system structure 122
P pair patterns 26 parameters 323 partitioned goal 321 partner 151 Partner Interface Process® (PIP) 301 PASSI 13, 81 PASSI methodology 82 PASSI ToolKit (PTK) 82 peer relationships 158 “perceive-decide-act” lifecycle 174 percept processing 118 perceptions 280 percepts 9 permissions 150 personal agents 75 personal travel agent (PTA) 220 phase type 284 physical agent 282, 283 physical metaphors 138 physical object 282 plan 9, 10, 108 platform design 63 platform specific model (PSM) 13 platform-independent model (PIM) 13, 288 platform-specific modelling (PSM) 288 power relationships 208 preliminary definition 149 preliminary interaction model 151 preliminary protocols 149 preliminary role model 149 preliminary roles 149 primary actor 296 proactive agent 3 proactivity 4 problem-solving method (PSM) 60 process 109 process-related criteria 343 processor 242 producer 373 program committee (PC) 164 Prometheus 13, 107 Prometheus design tool (PDT) 126 Prometheus methodology 107, 109 protocol name 151 protocols description phase 97
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
410 Index
JADEX 125 JAM 125 JASON 125 Java Agent DEvelopment framework (JADE) 5, 74 Jess behaviours 75
K knowledge engineering 46 knowledge facilities 62 knowledge modelling 55 knowledge-based system 61
L late requirement analysis 30 late requirements 22 lifecycle 121, 174 liveness properties 150 liveness rules 152
M MAS architectures 252 MAS-CommonKADS 4, 8, 13, 46, 47, 55, 205, 238 MAS-CommonKADS methodology 47 MaSE 7, 14 MASSIVE 8, 205 matchmaker 26 Medi@ 27 Media Producer 27 Media Shop 27 mediation patterns 26 mediator 26 meeting manager 116 meeting scheduler 116 mental moments 281 mental state manager 242 MESSAGE 7, 13, 204, 239 MESSAGE analysis and design 204 message events 59 MESSAGE methodology 203, 279 MESSAGE modelling language 208 MESSAGE notation 203 message sequence charts (MSC) 47 metaphor of the human organization 4
method engineering 370 method fragment selection 374 methodology testing 380 middle line 25 mixin type 284 mobile computing 138 model derivation 346 model multiplicity problem 312 model-driven architecture (MDA) 13, 277, 279 model-related criteria 343, 345 modularity 346 monitor 26 MOSES 61 multi-agent behaviour description (MABD) 99 multi-agent research tool (MART) 326 multi-agent societies 79 multi-agent structure definition (MASD) 98 multi-agent system (MAS) 1, 3, 80, 136, 137, 230, 236, 342 multi-agent systems engineering (MaSE) 317, 318
N negotiator 91, 116 Nemo 8 “network architecture” 48 network facilities 62 non cooperative situations (NCS) 175, 192 non-action event type 287 non-agentive object 282 non-communicative action event type 287 non-functional goal 320 non-functional requirements (NFRs) framework 25 notations 109
O Object Management Group (OMG) 13, 183, 279 object modelling technique (OMT) 47 object-oriented (OO) systems development methodology 2 object-oriented development 21
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
412 Index
PRS 125 purchase 93 purchase advisor 95 purchase manager 91 purchase monitor 92
R radical agent-oriented process (RAP) 7, 278 RAP/AOR development project 300 RAP/AOR methodology 278, 281 RAP/AOR viewpoint modelling framework 277, 288 Rational Unified Process (RUP) 7, 13, 47, 204, 277 reaction rules 287 reactive agents 3 real-world organization 156 receiver 282 reference model for open distributed processing (RMODP) 288 representation module 175 requirements 254 requirements analysis 21, 23 requirements-driven methodology 20 resource 9, 22 resource manager service 75 responsibility driven design (RRD) 48 responsibility-driven analysis 53 role 208 role schema 151 role type 284 roles 239 roles description (R.D.) 96 roles description phase 95 roles identification phase 89
S safety properties 150 safety rules 152 secondary actor 296 security 36 self-organization 174 sender 282 sensors 139 service charts 58
service provider 180 services model 161 session manager agent (SMA) 74 simulation 308 single-agent behaviour description (SABD) 101 single-agent structure definition (SASD) 98 situatedness 4 situational method engineering or SME 370 skill module 175 social moment 281, 282 social/institutional agents 285 sociality 4 societal metaphors 138 softgoal 22 software agent 283 software development 21 software development life cycle (SDLC) 12 software development methodology 20 software process engineering metamodel (SPEM) 82, 183 software system 138 sortal type 284 Specification and Description Language (SDL) 47, 58 state machines 222 steps in ADELFE 183 stereotypes 179 storekeeper 93 storeUI agents 92 strategic alliances 24 strategic apex 25 strategic dependencies 24 strategic dependency model 23 strategic rationale model 23 structure-in-5 25 structured analysis 21 structured programming 21 subscription 26 SuccessfulNegotiation 93 summary goal 320 supplier 93 support tools 254 supporting actor 296 supportive-feature criteria 343, 348 system goals 114
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
Index 413
system interface 118 system requirements model 83 system specification 111, 113
T “TA Gatherer” 221 “TA Selector” 221 task 22, 208, 371 task knowledge 60 task model 46, 48, 56, 68 task modelling 55 task specification phase 91 tasks 9 tasks/goals viewpoint 242 technique-related criteria 343, 345 techniques 109 temporal continuity 347 testing 47, 84 tool support 108, 126, 252 topology 144 “transfer arrangement” (TsA) 216 “transfer requirements” (TsR) 216 “travel arrangement” (TA) 216 “travel requirement” (TR) 216 triggering events 296 triggers 117 Tropos 4, 6, 8, 20, 109, 368 “TSP booking manager” 220 “TSP sales assistant” 220
U UER technique 50 UFO-A 281 UFO-B 281 UFO-C 281 UML 6 UML use case diagrams 290 unified foundational ontology (UFO) 281 Unified Modeling Language (UML) 47, 81, 318 unified software development process 238, 279 universal personal assistant for travel (UPA4T) 227 use case scenarios 113, 117 use cases 47
user information manager 117, 121 user interaction 117 user monitor 117, 121 user notify 117 user-centred analysis 51 user-environment-responsibility (UER) 47 user-environment-responsibility (UER) technique 50 UserInterface 120, 121 UserManager 121
V validation 254, 344 verification 254, 344 viewpoint 239 vowel engineering 238
W Web services (WS) 280 Web Services Description Language (WSDL) 280 work definitions in ADELFE 183 work product 373 work units 373 workflow-phase 248 wrapper 26
X XML schema 309
Z Zeus 252
Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
TEAM LinG
