as a PDF

Transcript

as a PDF

Dipartimento di Informatica e
Scienze dell’Informazione
Logic-Based Specification Environments
for Multi-Agent Systems
by
Viviana Mascardi
Theses Series
DISI-TH-2002-04
DISI, Università di Genova
v. Dodecaneso 35, 16146 Genova, Italy
http://www.disi.unige.it/
Università degli Studi di Genova
Dipartimento di Informatica e
Scienze dell’Informazione
Dottorato di Ricerca in Informatica
Ph.D. Thesis in Computer Science
by
Viviana Mascardi
May, 2002
Dottorato di Ricerca in Informatica
Dipartimento di Informatica e Scienze dell’Informazione
Università degli Studi di Genova
DISI, Università degli Studi di Genova
via Dodecaneso 35
I-16146 Genova, Italy
http://www.disi.unige.it/
Ph.D. Thesis in Computer Science
Submitted by
Viviana Mascardi
DISI, Università degli Studi di Genova, Italy
[email protected]
Date of submission: May 2002
Title:
Advisor:
Prof. Maurizio Martelli
DISI, Università degli Studi di Genova, Italy
[email protected]
Ext. Reviewers:
Prof. Thomas Eiter
Institut und Ludwig Wittgenstein Labor für Informationssysteme,
Knowledge-Based Systems Group, Technische Universität Wien
[email protected]
Prof. Leon Sterling
Department of Computer Science and Software Engineering
The University of Melbourne, Australia
[email protected]
Abstract
Real-world applications are usually characterized by heterogeneous distributed entities that interact following complex coordination protocols and that dynamically and autonomously modify their strategies during this interaction; these systems are extremely difficult to model and
implement, and traditional software engineering tools and techniques are often insufficient to
cope with this complexity. For this reason a new software engineering paradigm, the AgentOriented Software Engineering (AOSE) has joined, over the past ten years, more traditional
approaches. AOSE analyzes and designs systems based on the key abstraction of the agent, an
autonomous entity situated in some environment, able to perceive the environment itself and
to react to changes occurring in it, able to take the initiative when appropriate and capable of
communication with other agents in the system. Different approaches have been studied to engineer multi-agent systems (MAS), comprising structured but non-mathematical methodologies
as well as logic-based ones. ARPEGGIO, an ongoing software engineering international project
involving logic programming groups from USA, Australia and Italy, is designing a logic-based
prototyping environment for engineering this kind of complex applications using mainly (but not
only) logic-based languages.
The focus of this thesis is thus on multi-agent system development environments which use
logic-based approaches to specification and implementation. Our contribution is three-fold:
1. We have described many informal and formal approaches to AOSE, with particular attention to the last ones. We have analyzed different kinds of logics and, for each of them, we
have provided the description and an example of use of one agent specification languages
based on it.
2. We have analyzed some existing MAS Development Kits (MASDKs) to understand which
engineering approach, if any, is more commonly adopted and which could be the desiderata
for a more powerful environment as ARPEGGIO aims to become. We have compared and
drawn a taxonomy of five MASDKs and we have provided rules of thumb to chose the
right MASDK to do the right thing.
3. Finally, we have designed the extension of two logic-based MASDKs, IMPACT and CaseLP,
with new capabilities. IMPACT has been extended to deal with errors (IMPACT errortolerant agents), and CaseLP has been extended to become a multi-language distributed
environment which could integrate, in the future, the IMPACT specification language, thus
taking a first concrete step towards ARPEGGIO’s development.
A Samuele, il mio piccolo sole
Acknowledgements
Writing these acknowledgments was probably the hardest part of my thesis work: there are too
many persons I’d like to thank either for their support in my work or for their importance in my
life, or both.
First of all, I thank my advisor Maurizio Martelli who supported me with his friendship and
guidance and always trusted me.
A special thank to Thomas Eiter and Katrin, his wife: the time I spent in Vienna was one of the
most important periods in my life, both for my professional and personal growth.
I had the privilege to work with Leon Sterling and with V.S. Subrahmanian: I want to thank them
because it was an extremely instructive and pleasant experience.
Thank to Floriano Zini, with whom I started working on CaseLP: we had many stimulating
discussions on agents, logic programming and, during the pauses from work, Guccini’s songs.
The warmest thank to all the friends with whom I shared many years at DISI, in particular Dave,
donna Eva (and Paolo, and their Bonarda!), Floriano, Francesca, Gianna, Giorgio, Giovanna,
Giovanni, donna Isa, Laura, Marco, Paola, Ruben and Walter. They are good and absolutely
amusing friends.
Thanks to my old family, mamma, papà and Francesco, because they always helped me in any
way with their love, encouragement and patience.
My greatest thanks, however, are deserved to my new family. To Davide, because he is my
husband, my best friend, a very sharp colleague and the most amusing companion to enjoy life
with. And to Samuele, our masterpiece, because his five-teeth smile gives us one more reason to
think how lucky we are.
Contents
List of Figures
9
List of Tables
13
Chapter 1
15
Introduction
1.1
Intelligent agents and multi-agent systems . . . . . . . . . . . . . . . . . . . . . 16
1.2
The ARPEGGIO project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.2.1
The ARPEGGIO philosophy . . . . . . . . . . . . . . . . . . . . . . . . 20
1.2.2
The ARPEGGIO partners . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.3
Goals of the thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.4
Overview of the thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Chapter 2
Agent-Oriented Analysis and Design
25
2.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2
UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3
2.2.1
Use case diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.2
Class diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.2.3
Behavior diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.2.4
Interaction diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.2.5
Implementation diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Specification approaches based on UML . . . . . . . . . . . . . . . . . . . . . . 38
1
2.3.1
AUML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.3.2
Automatic synthesis of agent designs in UML . . . . . . . . . . . . . . . 53
2.4
Z . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.5
Specification approaches based on Z . . . . . . . . . . . . . . . . . . . . . . . . 56
2.5.1
2.6
A framework for agency and autonomy . . . . . . . . . . . . . . . . . . 56
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Chapter 3
Formal Methods for Agent-Oriented Software Engineering
60
3.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.2
The running example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.3
Situation calculus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.4
3.3.1
Foundational axioms for situations . . . . . . . . . . . . . . . . . . . . . 65
3.3.2
ConGolog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Modal Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.4.1
3.5
3.6
Deontic Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.5.1
The OS System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.5.2
The KD System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
3.5.3
The IMPACT agent language . . . . . . . . . . . . . . . . . . . . . . . . 81
Dynamic logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
3.6.1
3.7
Concurrent METATEM . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Linear logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
3.8.1
3.9
Dylog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Temporal logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
3.7.1
3.8
AGENT-0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Ehhf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
A comparison among the specification languages . . . . . . . . . . . . . . . . . 108
3.10 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
3.10.1 Pros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
2
3.10.2 Cons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Chapter 4
Frameworks for Multi-Agent Systems Development
114
4.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
4.2
MASDK features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
4.3
4.4
4.2.1
Agent attitudes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
4.2.2
Software engineering support . . . . . . . . . . . . . . . . . . . . . . . 121
4.2.3
Agent and MAS implementation . . . . . . . . . . . . . . . . . . . . . . 122
4.2.4
Technical issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
4.2.5
Economical aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Evaluation of some MASDKs . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
4.3.1
An introduction to the evaluated MASDKs . . . . . . . . . . . . . . . . 126
4.3.2
Feature assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
4.3.3
Agent basic attitudes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
4.3.4
Agent advanced attitudes . . . . . . . . . . . . . . . . . . . . . . . . . . 127
4.3.5
Social ability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
4.3.6
Software engineering support . . . . . . . . . . . . . . . . . . . . . . . 129
4.3.7
Implementation of agents and MAS . . . . . . . . . . . . . . . . . . . . 129
4.3.8
Technical issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
4.3.9
Business issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
4.4.1
Industrial applications . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
4.4.2
Commercial applications . . . . . . . . . . . . . . . . . . . . . . . . . . 138
4.4.3
Entertainment applications . . . . . . . . . . . . . . . . . . . . . . . . . 139
4.4.4
Medical applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
4.5
Application-driven MASDK selection . . . . . . . . . . . . . . . . . . . . . . . 141
4.6
Further issues and related work . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
4.6.1
Other agent-related scenarios . . . . . . . . . . . . . . . . . . . . . . . . 144
3
4.6.2
4.7
Related work on MASDK classification . . . . . . . . . . . . . . . . . . 146
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Chapter 5
IMPACT and its Extension with Error-Tolerant Agents
149
5.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
5.2
Architecture and formal definitions . . . . . . . . . . . . . . . . . . . . . . . . . 150
5.3
5.4
5.5
5.2.1
Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
5.2.2
Corrupted code call atoms . . . . . . . . . . . . . . . . . . . . . . . . . 152
5.2.3
Suspicious code call atoms . . . . . . . . . . . . . . . . . . . . . . . . . 156
Agent state repair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
5.3.1
The repair data structures . . . . . . . . . . . . . . . . . . . . . . . . . 164
5.3.2
Repair action library . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Error-tolerant agent cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
5.4.1
Different methods to implement suspicious and add repbuf . . . . . . 170
5.4.2
Implementing mkrepair . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
5.5.1
5.5.2
5.6
Proposals from the database community . . . . . . . . . . . . . . . 176
and proposals from the agent community . . . . . . . . . . . . . . . 178
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Chapter 6
CaseLP: a Logic-Based Environment for MAS Prototyping
187
6.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
6.2
CaseLP agent model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
6.2.1
6.2.2
6.3
A computational perspective and a descriptive perspective
. . . . . . . . . . . . . . . . . . . . . 188
. . . . . . . . . . . . . . . . . . . . . 190
Hierarchy of abstraction levels . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
6.3.1
Agent role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
6.3.2
Abstract architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
4
6.4
6.5
6.3.3
Concrete architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
6.3.4
Agent class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
6.3.5
Agent instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Development methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
6.4.1
The development methodology main structure . . . . . . . . . . . . . . . 198
6.4.2
Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
6.4.3
Verification and validation stage . . . . . . . . . . . . . . . . . . . . . . 202
6.4.4
Implementation stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
6.4.5
Execution stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Tools and languages provided by CaseLP . . . . . . . . . . . . . . . . . . . . . 204
6.5.1
6.5.2
HEMASL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
6.5.3
UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
6.5.4
CaseLP-Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
6.5.5
AgentOntology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
6.5.6
CaseLP-Ontology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
6.5.7
CaseLP-MASadl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
6.5.8
AgentRules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
6.5.9
ProlAg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
hhf
6.5.10 CaseLP Visualizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
6.5.11 CaseLP shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
6.6
6.7
Relationships among the CaseLP languages . . . . . . . . . . . . . . . . . . . . 223
6.6.1
6.6.2
AgentRules 6.6.3
CaseLP-MASadl, -Protocol, -Ontology 6.6.4
HEMASL hhf
ProlAg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
ProlAg . . . . . . . . . . . . . . . . . . . . . . . . . . 224
UML . . . . . . . . . . . . 226
UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
One application of CaseLP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
5
6.8
6.7.1
The case-study: vehicles monitoring in motorway . . . . . . . . . . . . . 228
6.7.2
Realization of the prototype in CaseLP . . . . . . . . . . . . . . . . . . 231
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Chapter 7
Further Developments: Designing D-CaseLP
238
7.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
7.2
The project purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
7.2.1
Integration of UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
7.2.2
Modeling and integration of roles and interaction protocols . . . . . . . . 240
7.2.3
Integration of new languages for implementing agents . . . . . . . . . . 240
7.2.4
Physical distribution and integration of legacy software . . . . . . . . . . 241
7.2.5
Creation of the final application . . . . . . . . . . . . . . . . . . . . . . 241
7.2.6
Improvement of existing features . . . . . . . . . . . . . . . . . . . . . 241
7.3
The functionalities D-CaseLP will provide . . . . . . . . . . . . . . . . . . . . 242
7.4
Standards taken into account in the D-CaseLP design . . . . . . . . . . . . . . 246
7.5
Tools suitable for implementing D-CaseLP . . . . . . . . . . . . . . . . . . . . 250
7.6
7.5.1
CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
7.5.2
JADE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
7.5.3
CORBA vs JADE for the development of D-CaseLP . . . . . . . . . . 260
Developing D-CaseLP with JADE . . . . . . . . . . . . . . . . . . . . . . . . 265
7.6.1
7.7
Integration of ProlAg and JADE . . . . . . . . . . . . . . . . . . . . . . 266
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Chapter 8
Conclusions
268
8.1
Achieved results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
8.2
Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Bibliography
274
6
Appendix A MASDK Comparison: Details
291
A.1 Agent basic attitudes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
A.2 Agent advanced attitudes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
A.3 Social ability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
A.4 Software engineering support . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
A.5 Implementation of agents and MAS . . . . . . . . . . . . . . . . . . . . . . . . 298
A.6 Technical issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
A.7 Business issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Appendix B MAS modelling in CaseLP: Details
306
B.1 Determine the roles to be played within the MAS . . . . . . . . . . . . . . . . . 306
B.2 Determine the complete standard role model for the MAS . . . . . . . . . . . . . 307
B.3 Group the roles in agent classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
B.4 For each class, determine the most suitable architecture . . . . . . . . . . . . . . 311
B.5 Determine the initial agent instances for each class . . . . . . . . . . . . . . . . 312
Appendix C CaseLP specification languages: Details
314
C.1 HEMASL and its relations with UML . . . . . . . . . . . . . . . . . . . . . . . 314
C.1.1
Formal syntax of HEMASL . . . . . . . . . . . . . . . . . . . . . . . . 314
C.1.2
The use of HEMASL in CaseLP . . . . . . . . . . . . . . . . . . . . . 319
C.2 CaseLP-MASadl and its relations with UML . . . . . . . . . . . . . . . . . . . 343
C.2.1
Formal syntax of CaseLP-MASadl . . . . . . . . . . . . . . . . . . . . 343
C.2.2
The use of CaseLP-MASadl in CaseLP . . . . . . . . . . . . . . . . . 346
C.3 CaseLP-Protocol and its relations with UML . . . . . . . . . . . . . . . . . . . 347
C.3.1
Formal syntax of CaseLP-Protocol . . . . . . . . . . . . . . . . . . . . 347
C.3.2
The use of protocols in CaseLP . . . . . . . . . . . . . . . . . . . . . . 349
C.4 CaseLP-Ontology and its relations with UML . . . . . . . . . . . . . . . . . . 352
C.4.1
Formal syntax of CaseLP-Ontology . . . . . . . . . . . . . . . . . . . 352
7
C.4.2
The use of ontologies in CaseLP . . . . . . . . . . . . . . . . . . . . . 352
C.5 AgentRules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
C.5.1
Formal syntax of AgentRules . . . . . . . . . . . . . . . . . . . . . . . 354
8
List of Figures
1.1
The final, working version of the parking agent. . . . . . . . . . . . . . . . . . . 17
1.2
High-level model of the parking agent. . . . . . . . . . . . . . . . . . . . . . . . 18
1.3
A working prototype for the parking agent. . . . . . . . . . . . . . . . . . . . . 19
1.4
The ARPEGGIO open framework. . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.1
A use case diagram (from [159]). . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2
A class diagram (from [159]). . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3
Aggregation association. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.4
Composition association. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.5
Generalization association. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.6
A statechart diagram (from [159]). . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.7
An activity diagram (from [159]). . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.8
A sequence diagram (from [159]). . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.9
A collaboration diagram (from [159]). . . . . . . . . . . . . . . . . . . . . . . . 35
2.10 A component diagram (from [159]). . . . . . . . . . . . . . . . . . . . . . . . . 37
2.11 A deployment diagram (from [159]). . . . . . . . . . . . . . . . . . . . . . . . . 37
2.12 A generic AIP expressed as a template package (from [161]). . . . . . . . . . . . 39
2.13 More detailed specification of an AIP (from [161]). . . . . . . . . . . . . . . . . 40
2.14 Using packages to express nested protocols (from [161]). . . . . . . . . . . . . . 40
2.15 Application of the template in Figure 2.9 to a particular scenario (from [161]). . . 41
2.16 Basic format for agent communication (from [161]). . . . . . . . . . . . . . . . 42
9
2.17 Extensions for supporting concurrent threads of interaction (from [161]). . . . . . 43
2.18 Activity diagram for a stock sale protocol (from [161]). . . . . . . . . . . . . . . 43
2.19 A statechart indicating valid states and transitions in an order protocol (from [161]). 44
2.20 An activity diagram specifying order processing (from [161]). . . . . . . . . . . 45
2.21 Statecharts that specify order processing behavior for three agents (from [161]). . 46
2.22 Role modeling representing each role with its own lifeline (from [161]). . . . . . 47
2.23 Role modeling where activation bars are labeled with the appropriate role (from
[161]). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.24 Role modeling where the communication acts indicate the requesting role (from
[161]). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.25 An activity diagram with activities labeled with the appropriate agent role (from
[161]). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.26 Dynamic classification (role changes) expressed as notes (from [161]). . . . . . . 50
2.27 Package specifying agents instead of operations as interface points (from [161]). . 50
2.28 Adding mobility to deployment diagrams (from [161]). . . . . . . . . . . . . . . 51
2.29 Representing cloning using sequence and class diagrams (from [161]). . . . . . . 51
2.30 Representing mitosis and reproduction using sequence and activity diagrams
(from [161]). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.31 Representing parasitic and symbiotic relationships using class diagrams (from
[161]). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.32 Representing emergence possibilities using a class diagram (from [161]). . . . . 53
2.33 Sequence diagram and its constraints for an agent-based transaction (from [178]). 53
2.34 The entity hierarchy (from [135]). . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.1
The contract proposal protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.1
Our approach to develop MASDK selection guidelines. . . . . . . . . . . . . . . 116
4.2
Application-driven selection of MASDKs: an example . . . . . . . . . . . . . . 118
5.1
Basic architecture of IMPACT agents. . . . . . . . . . . . . . . . . . . . . . . . 150
5.2
The BDI architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
10
6.1
General CaseLP agent architecture. . . . . . . . . . . . . . . . . . . . . . . . . 189
6.2
Abstraction hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
6.3
Abstract BDI architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
6.4
A class of BDI agents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
6.5
An instance of a BDI agent. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
6.6
The role diagram for the distributed marketplace application. . . . . . . . . . . . 209
6.7
The agent diagram for the distributed marketplace application. . . . . . . . . . . 211
6.8
The protocol diagram for the distributed marketplace application. . . . . . . . . . 213
6.9
Lifeline with an interaction thread. . . . . . . . . . . . . . . . . . . . . . . . . . 214
6.10 Initialization window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
6.11 On-line visualization of execution. . . . . . . . . . . . . . . . . . . . . . . . . . 221
6.12 Off-line tracing of execution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
6.13 Details of an event. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
6.14 Motorway Monitoring Application Architecture. . . . . . . . . . . . . . . . . . . 230
7.1
Use case diagram for the overall functionalities. . . . . . . . . . . . . . . . . . . 246
7.2
Use case diagram for MAS modeling and code creation. . . . . . . . . . . . . . 247
7.3
Use case diagram for the prototype development and testing. . . . . . . . . . . . 248
7.4
The FIPA abstract architecture mapped to instantiations. . . . . . . . . . . . . . 251
7.5
CORBA’s main features (from [196]). . . . . . . . . . . . . . . . . . . . . . . . 253
7.6
The role of an Object Adapter (from [196]). . . . . . . . . . . . . . . . . . . . . 255
7.7
JADE Agent Platform (from [21]). . . . . . . . . . . . . . . . . . . . . . . . . . 258
7.8
Agent communication in CORBA: one possible solution. . . . . . . . . . . . . . 262
B.1 The fruit marketplace application. . . . . . . . . . . . . . . . . . . . . . . . . . 307
B.2 Marketplace role model (from [56]). . . . . . . . . . . . . . . . . . . . . . . . . 308
C.1 The agent diagram for the distributed marketplace application. . . . . . . . . . . 320
C.2 The UML class for the abstract BDI architecture. . . . . . . . . . . . . . . . . . 344
11
C.3 The statechart diagram of the abstract BDI architecture. . . . . . . . . . . . . . . 345
C.4 The UML role diagram corresponding to the CaseLP-MASadl specification. . . 348
C.5 The UML protocol diagram corresponding to the specification. . . . . . . . . . . 351
C.6 The UML class diagram corresponding to the specification. . . . . . . . . . . . . 353
12
List of Tables
3.1
4.1
An evaluation of the advanced agent attitudes. . . . . . . . . . . . . . . . . . . . 128
4.2
An evaluation of the agent social ability. . . . . . . . . . . . . . . . . . . . . . . 129
4.3
An evaluation of software engineering support. . . . . . . . . . . . . . . . . . . 130
4.4
An evaluation of implementation of agents and MAS support. . . . . . . . . . . . 131
4.5
An evaluation of technical issues. . . . . . . . . . . . . . . . . . . . . . . . . . . 132
4.6
Further technical issues (computer environment). . . . . . . . . . . . . . . . . . 133
4.7
An evaluation of business issues. . . . . . . . . . . . . . . . . . . . . . . . . . . 134
5.1
Procedure suscca. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
5.2
Modified agent decision cycle. . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
5.3
Engine for a reactive-proactive CaseLP agent. . . . . . . . . . . . . . . . . . . 185
5.4
Engine for an error-tolerant reactive-proactive CaseLP agent. . . . . . . . . . . 186
6.1
CaseLP methodology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
6.2
Tools and languages supported by the CaseLP methodology. . . . . . . . . . . . 205
6.3
Ontology definition schema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
6.4
Schema of ProlAg implementation of an AgentRules specification. . . . . . . . 225
6.5
Engine for a reactive-proactive agent in ProlAg. . . . . . . . . . . . . . . . . . . 226
6.6
MAS static architecture specified in CaseLP-MASadl. . . . . . . . . . . . . . . 232
6.7
Conversation protocol specified in CaseLP-Protocol. . . . . . . . . . . . . . . 233
hhf
proof system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
13
6.8
MAS dynamics modeling in AgentRules. . . . . . . . . . . . . . . . . . . . . . 233
6.9
MAS implementation in ProlAg. . . . . . . . . . . . . . . . . . . . . . . . . . . 234
6.10 Comparison table of all messages except the alarm ones. . . . . . . . . . . . . . 236
7.1
A comparison between JADE and CORBA. . . . . . . . . . . . . . . . . . . . . 261
7.2
A comparison between different Prolog implementations. . . . . . . . . . . . . . 266
B.1 Fruit marketplace role model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
B.2 Marketplace initial interactions (from [56]). . . . . . . . . . . . . . . . . . . . . 308
B.3 Agent architectures and agent applications. . . . . . . . . . . . . . . . . . . . . 313
14
Chapter 1
Introduction
It’s eight o’clock of one ordinary morning of 2010: Viviana checks Samuele’s electronic diary to see which school books he must carry, prepares his knapsack, takes
the car and takes Samuele to school. She parks her car in a toll-parking and rushes
towards the school without paying: at the end of the month, the bill for the exact
amount of minutes she spent in the city toll-parkings is automatically paid by her
bank. In the classroom, Samuele and his classmate pull out the books from their
knapsacks: the books turn out to be fairly partitioned between them, even if they did
not talk about dividing them Our dissertation starts with this snapshot of close-future familiar life: in our tale the mother, late
as usual, takes advantage of a parking service which allows to park everywhere in the dedicated
parking-slots without worrying to pay, to insert cards, to validate tickets or anything else. She
also enjoys a service provided by her child’s electronic diary which negotiates a fair division of
the school books to carry with his classmate’s electronic diary.
Even if, at the time of writing, the toll-parking service we describe is not available in our city and,
up to our knowledge, elsewhere in the world, and electronic diaries are not able to negotiate yet,
these applications are not science fiction: the components they involve are extremely widespread
and we experience with them almost every day.
In order for the first service to be realized, we may assume that a device able to read the car
plates is located in each parking lot: when one car enters this area, the plate number is read and
the current time is associated with it. When the car leaves the area, its plate number is read again
and it is forwarded to the software which manages the service, together with the total minutes of
stay in the zone. The software accesses a database which maintains information on cars, minutes
already spent in the parking lot, statistical information on the time spent in the parking lots by
this car, and bank account from which withdrawing the money. At the end of the month, the due
15
amount of money is evaluated and the money is withdrawn from the account. We may think that
such a system, besides offering the parking service to citizens, is also able to autonomously alert
the Police if a car, which usually stays no more than two hours, is left in the parking zone for
three days, or if any other anomalous situation occurs.
In the second application, the key issue is the negotiation which takes place between two personal
electronic diaries to find a fair partition of the school books to carry. We may think that this
partition cannot be fixed at the beginning of the school year because the books necessary for the
lessons dynamically change from day to day: also the teachers use an electronic diary to inform
their students of the books required for the next lesson.
All the bricks composing the applications above have a firm technology beyond them and are
part of our daily life: for example, a vehicle monitoring system with devices for reading plate
numbers is installed in the motorway section between Salerno and Reggio-Calabria (Italy), as
described in Section 6.7; electronic diaries are commonly used and, in the last years, they have
been enriched with communication capabilities that allow them to exchange simple messages;
negotiation protocols have been studied for more than forty years. Then, is there anything new
in applications like the ones discussed above?
The novelty in these systems comes from the distribution and heterogeneity of their components, the way these components must be integrated, the amount of interaction among them, the
complexity of the interaction patterns the entities follow, the unpredictability of the resulting
system’s behavior due to the great number of variables influencing it, the autonomy required
to some pieces of software to perform their tasks, their ability to sense and react to changes
occurring in their environment. In a word, the novelty lies in the intelligence either shown by
individual components and emerging from their interaction.
1.1
Intelligent agents and multi-agent systems
Many real-world applications, characterized by the above features, are difficult to be correctly
and efficiently engineered; for this reason a very active research area has been working for almost twenty years for finding abstractions, languages, methodologies and toolkits for modeling,
verifying, validating and finally implementing applications of this kind. The metaphor underlying this research is that the components of complex real-world applications are intelligent agents
which interact exchanging information and collaborate for reaching a common target, or compete
to control some shared resource and to maximize their personal profit, building, in both cases, a
society of agents, or multi-agent system (MAS).
An intelligent agent, according to a classical definition proposed by N. R. Jennings, K. Sycara
and M. Wooldridge in [110], is
16
Software and
physical devices
for recognizing
plate numbers
Local database
of recently-read
plate numbers
Parking agent: both the software for
the agent’s business logic and for external
devices and pakages are the real, final
ones (rectangles represent final software)
Figure 1.1: The final, working version of the parking agent.
“ a computer system, situated in some environment, that is capable of flexible
autonomous actions in order to meet its design objectives.
Situatedness means that the agent receives sensory input from its environment and
that it can perform actions which change the environment in some way.
By autonomy we mean that the system should be able to act without the direct intervention of humans (or other agents), and that it should have control over its own
actions and internal state. [ ] By flexible, we mean that the system is:
responsive: agents should perceive their environment and respond in a timely
fashion to changes that occur in it;
pro-active: agents should be able to exhibit opportunistic, goal-directed behavior and take the initiative when appropriate;
social: agents should be able to interact, when appropriate, with other artificial
agents and humans.”
Now that we have acquired some terminology and concepts from the agents’ and multi-agent systems’ fields, let us go back to Viviana and Samuele’s tale and consider the software engineering
process that allowed them to arrive at school in time, and with the right books.
We start with the first application. We may suppose that the software engineers working at this
application started with specifying a simplified version of it by modeling a parking agent with
the required capabilities for the final agent, sketched in Figure 1.11 , but neglecting aspects such
as integration of external entities and efficiency. In this first model, external entities are roughly
1
In Figures from 1.1 to 1.3 rectangles represent the final version of software and real devices to be integrated in
the application, while ellipses represent components that are only prototyped.
17
Model of the
software and
physical devices
for recognizing
plate numbers
Model of the
local database
of recently-read
plate numbers
High-level prototype of the parking agent:
external devices and software are simulated
(ellipses represent simulated software)
Figure 1.2: High-level model of the parking agent.
approximated by mathematical functions, and the communication is simulated by calling these
functions. The parking agent is specified using some high-level formal language supporting a
proof mechanism for formally verifying agent’s properties, for example moving to a valid state
whatever the input received. This scenario is depicted in Figure 1.2.
Thanks to the promising results obtained from this specification and validation stage, the software engineers go on in their work by building a working prototype of the application. In this
prototype, the parking agent is developed in some language that allows an easy integration of
external software, and its behavior refines the one specified in the previous stage, though still neglecting issues such as efficiency. Instead of modeling the software for plate number recognition
and the database storing cars’ information, they are integrated in the prototype. The execution
of this prototype, depicted in Figure 1.3, gives realistic feedback to the software engineers, who
can modify or improve their choices and strategies, obtaining a good level of confidence in their
correctness.
The prototype obtained in this second stage is close to the final application. The software developers only have to substitute the prototypical parking agent with its final efficient implementation, taking care of implementing the agent coherently with its prototype2. Now the application
of Figure 1.1 is ready, and there are good chances that it is correct.
As far as the second application is concerned, we may suppose that each physical component
has already been developed, and that the negotiation protocol has already been modeled using
some specification language. The task of the software engineers is to use some formal method
to test the absence of deadlocks from this negotiation protocol and in a successive stage to build
a prototype where the existing specification of the negotiation protocol is interfaced with the
2
This step may be source of errors; we assume that the developers have some (in)formal means for verifying that
this implementation is correct with respect to the agent’s prototype.
18
Real software and
physical devices for
recognizing plate
numbers
Real local
database of
recently-read
plate numbers
Prototype of the parking agent (represented by
an ellipse) which integrates final external software
and real devices (represented by rectangles)
Figure 1.3: A working prototype for the parking agent.
software installed in the electronic diaries. For example, the software engineers could initially
model the protocol in a formal language for which an automatic means of proving theorems exists, for example linear logic3 , and prove some properties of the model by executing it. Then,
they could build the prototype using some language more suitable then linear logic for the purpose, adding details that in the linear logic specification had been omitted4. Once this prototype
has been executed and tested, the interaction protocol can be substituted with its implementation,
for developing and deploying the commercial product.
1.2
The ARPEGGIO project
The software engineers’ tasks we illustrated above are characterized by the integration of specifications of agents and interaction protocols, specification of the external software, and implemented software belonging to the final application. We may generalize this situation by supposing that the components to be seamlessly integrated are agents specified in different languages,
agents already implemented, specifications and implementations of interaction protocols, models
of legacy software and the real packages to integrate. Is it possible for a software engineer to
cope with this amount of heterogeneous components? Are there tools and methodologies which
may help her in this hard work?
Some basic ideas for answering these questions can be found in the ARPEGGIO project. ARPEGGIO (Agent based Rapid Prototyping Environment Good for Global Information Organization
[60]) is a joint project that advocates the use of logics and logic programming for the realization
3
See Section 3.8.1 for more details on this topic.
Also this step may be source of errors; however, if the language in which the prototype is implemented is a
logic programming language, the risk of translation errors can be reduced. See Section 6.6.1 for an example.
4
19
of an open MAS framework which supports the specification, rapid prototyping, engineering and
implementation of heterogeneous agent-based software.
1.2.1
The ARPEGGIO philosophy
The philosophy behind ARPEGGIO is sketched in Figure 1.4: we assume to have at our disposal
the components depicted in this figure. At the top of the picture there are some specification
languages: each of them is suitable for specifying a particular aspect of the MAS prototype
architecture and behavior.
The development of a specification is described in the picture by S arrows. The top layer in
Figure 1.4 contains executable specification languages eA to eZ and non-executable specification
languages A to Z. For any specification language, both executable and non-executable, we assume
a (semi)-automatic compiler which can produce an executable form of any specified agent in
a target language. In the initial assumptions of the project this language had to be based on
logic programming because logic programming represents a common denominator among the
partners’ interests and expertise. Now we think that this constraint can be slightly relaxed: the
target language may be either a logic programming language or any other language, provided
that it can be easily interfaced with a logic programming one5 . The C arrows on the left of the
picture represent this compilation step.
If an executable specification language has been used, it is possible to directly interpret the given
specification before compiling and animating it. Both direct execution and animation have the
purpose of providing a better understanding of the system, thus facilitating the refinement of the
specification, until the obtained executable prototype behaves exactly as expected. In Figure 1.4,
the R arrows represent the refinement stage. Once the software engineer is confident enough
in the specification of the system, she may compile it obtaining a system closer to the final
application that incorporates the legacy components.
The bottom rightmost part of Figure 1.4 represents legacy software and data that are integrated
into the prototype; the access to external software is represented by the E lines.
Specification languages can be used not only for defining agents, but also for describing the behavior of external modules6. Using an executable specification language it is possible to develop
an executable specification of an external module, which can be treated as any other legacy software. If the language is not executable, an ad-hoc compilation process can produce a form of the
specification which can be animated (see the C arrow in the right part of the picture).
5
For example, Java could be a target language since bidirectional Java-Prolog interfaces exist, see Section
7.6.1.
6
We distinguish between agents and external modules since the latter are passive pieces of software which
provide functionality without communication capability, autonomy, or, in general, “intelligence”.
20
Exec. Spec.
Lang. eA
Exec. Spec.
Lang. eZ
Exec. Spec.
Lang. eB
.........
S
Spec.
Lang. A
Spec.
Lang. B
Spec.
Lang. C
Spec.
Lang. D
Specification
languages (both
executable and
non-executable
ones)
Spec.
Lang. Z
.........
.........
S
.........
C
C
S
R
Executable MAS
prototype
Multi-agent
system and
external
modules
specifications
External software
module specification
Multi-agent
system
specification
with language F
.........
Multi-agent
system
specification
with language B
S
R
Multi-agent sys.
specification and
execution with
language eZ
.........
Multi-agent sys.
specification and
execution with
language eA
C
R
R
Legacy software,
executable specifications
of external modules
Executable
Specification
E
I
I
E
Multi-agent
system
executable
prototype
and
external
modules
I
I
Legacy
Database
E
I
Agent
implemented
in Lang. L1
I
I
E
Legacy
Module
I
Agent
implemented
in Lang. Ln
I
E
Inter-agent
communication
S
Specification
development
Access to
external software
R
C
Refinement of
the specification
Figure 1.4: The ARPEGGIO open framework.
21
Compilation of
the specification
into an executable
prototype
1.2.2
The ARPEGGIO partners
ARPEGGIO takes contributions from three international logic programming research groups:
the Logic Programming Group at the Computer Science Department of the University of Maryland, USA; the Logic Programming and Software Engineering Group at the Computer Science
& Software Engineering Department of the University of Melbourne, Australia; and the Logic
Programming Group at the Computer Science Department of the University of Genova, Italy.
The American partners of ARPEGGIO have been working for years on the mediation approach
to software integration, developing the mediated system HERMES [134, 2] and the Interactive
Maryland Platform for Agents Collaborating Together (IMPACT) which builds upon it [72, 71,
12].
The Australian partners have developed a great experience in the animation of logic specifications, in order to execute and test them [190], in particular with the PipeDream (PrototypIng
sPEcifcations, Design and REquirements At Melbourne) project. PipeDream aims to improve
the outcomes of requirements analysis by using formal methods, or more precisely mathematical
modeling, to determine, analyze and verify requirements. Logic programming can provide the
basis for a light weight approach to achieving better analysis of specifications.
Finally, our research group has developed CaseLP (Complex Application Specification Environment based on Logic Programming [144, 30]), an experimental environment for building
prototypes of complex and distributed applications modeled as MAS. CaseLP allows to specify
agents using logic languages ( hhf ) and its implementation is based on Prolog. In CaseLP some
efforts have been made to integrate more widely used specification languages with the logic ones,
in order to take advantage of the benefits of logics and logic programming and to reach a wider
group of potential users.
1.3
Goals of the thesis
The goal of this thesis can be summarized as follows:
To take a first concrete step towards the realization of the ARPEGGIO framework
by deeply analyzing the potentialities and limitations of existing specification languages and development environments for agents and MAS, and by using the results
of this analysis to improve two of the systems included in the ARPEGGIO framework,
IMPACT and CaseLP.
Before designing and implementing ARPEGGIO, some issues must be analyzed and understood
to know the real necessities emerging in the agent-oriented software engineering field, to take
22
advantage of existing research results and to exploit existing technologies for our purposes. Besides this, it is also necessary to get a firm understanding of the environments already developed
by the project’s partners in order to integrate them within the ARPEGGIO framework, and to
make them closer to the real needs of ARPEGGIO’s potential users.
Our concrete step towards ARPEGGIO’s development consists in two stages:
a first stage where the state-of-the-art in some agent research domains relevant for the
ARPEGGIO development is surveyed and analyzed;
a second stage where the extension of two of the environments developed by the ARPEGGIO’s partners, IMPACT and CaseLP, is designed according both to the needs emerging
from the previous analysis and to the philosophy behind ARPEGGIO.
During the first stage we will survey, analyze and compare
1. Existing languages for specifying agents, interaction protocols and all the issues relevant
for modeling a MAS. Logic languages deserve our greatest consideration because, as already put in evidence, the common bases of the ARPEGGIO’s partners are logics and logic
programming. Nevertheless, we cannot ignore the more and more widespread use of other
specification languages for specifying software systems in general and MAS in particular.
For this reason, our analysis will include both logic and non-logic languages.
2. Existing agent platforms for prototyping a MAS application, integrating external software,
running and monitoring the prototype execution, supporting the final implementation of the
MAS. We are interested in understanding what the agent community has already achieved
in this direction either to “avoid re-inventing the wheel” and to identify the most useful
functionalities that could be supported by ARPEGGIO.
In the second stage, we will design extensions of
1. IMPACT with capabilities for allowing agents to continue their work even if some error
occurs, and to autonomously recover from these errors.
2. CaseLP with the ability to distribute the execution of agents across a network, to easily integrate different kinds of heterogeneous external software, to integrate UML models
of architectures, roles and interaction protocols, and finally to semi-automatically create
executable agents starting from these models.
23
1.4
Overview of the thesis
The thesis’ structure follows the two stages outlined above: the first three chapters deal with stateof-the-art survey and analysis while the following three chapters are concerned with IMPACT,
CaseLP and their extensions.
Chapter 2 describes some approaches to develop agent systems adopting non-logic languages
and following principled but informal methodologies. We will introduce UML, Z, and some of
their extensions for modeling MAS.
Chapter 3 deals with the use of formal methods for specifying, programming and verifying MAS.
The use of formalisms like the situation calculus, modal logics, temporal logics, deontic logics,
dynamic logics and linear logics is discussed, and agent languages based on them are presented
together with a running example.
Chapter 4 evaluates five existing MAS development environments, among them IMPACT and
CaseLP, by adopting a set of application-driven criteria based on orthogonal dimensions: the
support of agent attitudes, the support to MAS engineering, the support to MAS implementation,
technical and business issues.
Chapter 5 presents an extension of IMPACT agents so that, when an anomalous situation occurs
that causes a corruption of their integrity constraints, they are able to recover from being “corrupted” to being “uncorrupted” and they can continue processing some requests while continuing
to recover.
Chapter 6 synthesizes the results we have obtained with the CaseLP project from 1997, the year
the project started, to the end of 2000, the year we decided to renew the CaseLP environment
by designing D-CaseLP. CaseLP agent model, languages and facilities are discussed and a real
application of the environment is presented.
Chapter 7 describes the design of D-CaseLP (Distributed CaseLP), whose purpose is to overcome some limitations and rigid solutions characterizing CaseLP. The chapter motivates our
design strategies and choices and provides preliminary ideas for the D-CaseLP implementation.
Finally, Chapter 8 concludes this dissertation with a summary of the research results we achieved
and with the future developments of our work.
24
Chapter 2
Agent-Oriented Analysis and Design
2.1
Introduction
In this chapter we review some approaches for developing agent systems adopting some principled but informal methodology. As pointed out in [53], these methodologies can be broadly
divided into two groups:
those that take their inspiration from object-oriented (OO) development, and either extend
existing OO methodologies or adapt OO methodologies to purposes of Agent-Oriented
Software Engineering (AOSE) [45, 118, 205, 162, 66, 20, 116, 163, 201];
those that adapt knowledge engineering or other techniques [32, 135, 104, 55].
The first approach is definitely the most followed one; in particular, there is a growing research
effort in adapting and extending UML to make it suitable to specify agents. For this reason the
rest of this chapter mainly deals with UML (Section 2.2) and with some of its extensions to
cope with agenthood (Section 2.3). Besides the work on UML, it is worthwhile to remember, as
representatives of the first category, the Gaia methodology of M. J. Wooldridge et al. [205] and
the AAII methodology of D. Kinny et al. [118]. As representatives of the second category, we
cite the Cassiopeia methodology of A. Collinot et al. [55], the DESIRE framework of J. Treur
et al. [32]1 and the use of Z for specifying agent systems [135]. In Section 2.4 we will provide
a short overview of Z and in Section 2.5 we will describe how M. Luck et al. have adopted it to
specify agent systems.
1
The DESIRE framework is extensively described in Chapter 4, where it is also compared with other environments for developing agents.
25
Before introducing the UML modeling language and its agent-oriented extensions, we need to
discuss the relationships between agents and objects. A clarifying discussion on this topic comes
from Section 1.2 of [53], summarized in the following paragraph.
Relationships between agents and objects. Objects are computational entities that encapsulate some state, are able to perform actions, or methods on this state, and communicate by
message passing. Agents share some similarities with objects, but they also show many differences:
1. The degree to which agents and objects are autonomous. We must recall that the defining
characteristic of object-oriented programming is the principle of encapsulation, by means
of which an object can be thought of as exhibiting autonomy over its state: it has control
over it. But an object does not exhibit control over it’s behavior. That is, if an object
has a public method m, then other objects can invoke m whenever they wish – once an
object has made a method public, it has no more control over whether or not that method
is executed. Since objects can be assumed to share some “common goal”, it is normal that
they make methods public. But in many types of multi-agent systems, in particular those
that contain agents built by different organizations or individuals, no such common goal
can be assumed. We thus do not think of agents as invoking methods upon one-another,
but rather as requesting actions to be performed. If agent aj requests agent ai to perform
action act, then ai may decide to perform the action or may not; if object oj calls the public
method m of object oi , oi must execute the method.
2. The notion of flexible (reactive, pro-active, social) behavior. Even if it is possible to
build object-oriented programs that show a flexible behavior, this kind of abstraction does
not belong to the standard object model.
3. The standard object model and agent systems differ with respect to the autonomous
thread of control that agents are assumed to have, and (usually) objects have not. Agents
are assumed to be continually active, and typically are engaged in an infinite loop of observing their environment, updating their internal state and selecting and executing an action to perform. In contrast, objects are assumed to be quiescent for most of the time,
becoming active only when another object requires their services by means of method invocation. The work devoted to concurrency in object-oriented languages such as Java and
to active objects is making this third difference between agents and objects smaller than
before.
26
2.2
UML
The Unified Modeling Language (UML) is a language for specifying, visualizing, constructing
and documenting the artifacts of software systems, as well as for business modeling and other
non-software systems. Its development began in late 1994 when G. Booch and J. Rumbaugh of
Rational Software Corporation began their work on unifying the Booch and OMT (Object Modeling Technique) methods. In the fall of 1995, I. Jacobson and his Objectory company joined
Rational and this unification effort, merging in the OOSE (Object-Oriented Software Engineering) method.
In this section we shortly describe the main features of the language: we think that this introduction may prove useful to understand the significance of UML as a general-purpose specification
language, its usefulness for specifying agents (Section 2.3.1), and the technical details of its integration in CaseLP (Section 6.5.3). The complete specification of the 1.3 version, released in
March 2000, can be downloaded from the OMG site [159]. Our introduction is based on this
document.
A UML specification is composed by different diagrams which allow to analyze the problem
from different viewpoints:
use case diagrams
class diagrams
behavior diagrams
– statechart diagrams
– activity diagrams
interaction diagrams
– sequence diagrams
– collaboration diagrams
implementation diagrams
– component diagrams
– deployment diagrams
27
Figure 2.1: A use case diagram (from [159]).
2.2.1
Use case diagrams
A use case diagram (Figure 2.1) shows the relationship among actors and use cases within a
system.
A use case is a kind of classifier representing a coherent unit of functionality provided by a
system, a subsystem, or a class as manifested by sequences of messages exchanged among the
system and one or more outside interactors (called actors) together with actions performed by
the system.
An actor defines a coherent set of roles that users of an entity can play when interacting with
the entity. An actor may be considered to play a separate role with regard to each use case with
which it communicates. The standard icon for an actor is a “stick man” figure with the name of
the actor below the figure.
Use case relationships.
actors and use cases.
There are several standard relationships among use cases or between
Association. The participation of an actor in a use case, i.e. instances of the actor and instances
of the use case communicate with each other. This is the only relationship between actors
and use cases.
Extend. An extend relationship from use case A to use case B indicates that an instance of use
28
Figure 2.2: A class diagram (from [159]).
case B may be augmented (subject to specific conditions specified in the extension) by the
behavior specified by A.
Generalization. A generalization from use case A to use case B indicates that A is a specialization of B.
Include. An include relationship from use case A to use case B indicates that an instance of the
use case A will also contain the behavior as specified by B.
2.2.2
Class diagrams
A class diagram (Figure 2.2) is a graph of classifier elements connected by their various static
relationships. A class diagram may also contain interfaces, packages, relationships, and even
29
instances, such as objects and links. Perhaps a better name would be “static structural diagram”
but “class diagram” is shorter and well established. A class diagram is a graphic view of the
static structural model. The individual class diagrams do not represent divisions in the underlying
model. The adopted notation for a class diagram is as a collection of (static) declarative model
elements, such as classes, interfaces, and their relationships, connected as a graph to each other
and to their contents. Class diagrams may also be organized into packages. The reader with some
experience with Entity-Relationship (ER) Diagrams from the relational databases field will find
a close similarity between them and class diagrams.
An object diagram is a graph of instances, including objects and data values. A static object
diagram is an instance of a class diagram; it shows a snapshot of the detailed state of a system at
a point in time.
A class is the descriptor for a set of objects with similar structure, behavior, and relationships.
A class is drawn as a solid-outline rectangle with three compartments separated by horizontal
lines. The top name compartment holds the class name and other general properties of the class,
including stereotype2 ; the middle list compartment holds a list of attributes; the bottom list compartment holds a list of operations.
An object represents a particular instance of a class. It is shown as a rectangle with two compartments. The top compartment shows the name of the object and its class, all underlined, using the
syntax
objectname : classname
An interface is a specifier for the externally-visible operations of a class, component, or other
classifier (including subsystems) without specification of internal structure. Each interface often
specifies only a limited part of the behavior of an actual class. Interfaces do not have implementation. They lack attributes, states, or associations; they only have operations. Interfaces may
have generalization relationships. An interface is formally equivalent to an abstract class with no
attributes and no methods and only abstract operations.
A template is the descriptor for a class with one or more unbound formal parameters. It defines a
family of classes, each class specified by binding the parameters to actual values. Typically, the
parameters represent attribute types; however, they can also represent integers, other types, or
even operations. Attributes and operations within the template are defined in terms of the formal
parameters so they too become bound when the template itself is bound to actual values.
Associations. Associations are arches between the classifiers in a class diagram. They are
drawn as a solid path connecting two classifier symbols (both ends may be connected to the
same classifier, but the two ends are distinct). The end of an association where it connects to a
2
An extension of the vocabulary of the UML, which allows to create new kinds of building blocks that are derived
from existing ones but that are specific to the problem.
30
Whole
Part
Figure 2.3: Aggregation association.
Part
Whole
Figure 2.4: Composition association.
classifier is called an association end. Most of the interesting information about an association
is attached to its ends, such as multiplicity, ordering, navigability, and so on. Some interesting
associations are
Aggregation. A special form of association that specifies a whole-part relationship between the
aggregate (whole) and a component part. It is represented with an empty diamond as the
association end of the possessing class (Figure 2.3).
Composition. A form of aggregation with strong ownership and coincident lifetime of part with
the whole. The multiplicity of the aggregate end may not exceed one (it is unshared).
Composition may be shown by a solid filled diamond as an association end adornment
(Figure 2.4).
Generalization. The taxonomic relationship between a more general element (the parent) and
a more specific element (the child) that is fully consistent with the first element and that
adds additional information. Generalization is shown as a solid-line path from the child
(the more specific element, such as a subclass) to the parent (the more general element,
such as a superclass), with a large hollow triangle at the end of the path where it meets the
more general element (Figure 2.5).
Note that classes may be themselves “associations” (Association Classes). They are represented
as the other classes are, by means of a solid-outline rectangle with three compartments. The
class is linked to the association it refers to by means of a dotted path. As an example, “Job” and
“Marriage” classes in Figure 2.2 are association classes, and specify the attributes of the relation
between an employee and an employer, and between a wife and a husband, respectively.
Parent
Child
Figure 2.5: Generalization association.
31
Figure 2.6: A statechart diagram (from [159]).
2.2.3
Behavior diagrams
Behavior diagrams are used to define the behavior of a class or a system.
2.2.3.1
Statechart diagrams
A statechart diagram (Figure 2.6) can be used to describe the behavior of a model element
such as an object or an interaction. Specifically, it describes possible sequences of states and
actions through which the element can proceed during its lifetime as a result of reacting to discrete events (e.g., signals, operation invocations). Statechart diagrams represent the behavior
of entities capable of dynamic behavior by specifying their response to the receipt of event instances. Typically, they are used for describing the behavior of classes, but statecharts may also
describe the behavior of other model entities such as use-cases, actors, subsystems, operations,
or methods.
32
Figure 2.7: An activity diagram (from [159]).
33
2.2.3.2
Activity diagrams
An activity diagram (Figure 2.7) is a special case of a statechart diagram in which all (or at
least most) of the states are actions or subactivity states and in which all (or at least most) of
the transitions are triggered by completion of the actions or subactivities in the source states.
The entire activity diagram is attached (through the model) to a class, such as a use case, or to
a package, or to the implementation of an operation. The purpose of this diagram is to focus on
flows driven by internal processing (as opposed to external events). They are used in situations
where all or most of the events represent the completion of internally-generated actions (that is,
procedural flow of control).
2.2.4
Interaction diagrams
Interaction diagrams show patterns of interaction among instances. They come in two forms
based on the same underlying information, specified by an interaction, but each form emphasizing a particular aspect of it: sequence diagrams and collaboration diagrams. Sequence diagrams
show the explicit sequence of stimuli and are better for real-time specifications and for complex
scenarios. Collaboration diagrams show the relationships among instances and are better for
understanding all of the effects on a given instance and for procedural design.
2.2.4.1
Sequence diagrams
A sequence diagram (Figure 2.8) presents an Interaction, which is a set of messages between
ClassifierRoles3 within a Collaboration4 to perform a desired operation or to achieve some result.
A sequence diagram has two dimensions:
1. the vertical dimension represents time and
2. the horizontal dimension represents different objects.
2.2.4.2
Collaboration diagrams
A collaboration diagram (Figure 2.9) shows an interaction organized around the roles in the interaction and their links to each other. Unlike a sequence diagram, a collaboration diagram shows
3
A ClassifierRole describes the properties of an object playing that role and describes the relationships that an
object playing that role has with other objects.
4
A Collaboration defines a set of participants and relationships that are meaningful for a given set of purposes.
The identification of participants and their relationships does not have global meaning. These participants define
roles that objects play when interacting with each other.
34
Figure 2.8: A sequence diagram (from [159]).
Figure 2.9: A collaboration diagram (from [159]).
35
the relationships among the objects playing the different roles. On the other hand, a collaboration diagram does not show time as a separate dimension, so the sequence of interactions and the
concurrent threads must be determined using sequence numbers. A collaboration diagram can
be given in two different forms: either at specification level (the diagram shows ClassifierRoles,
AssociationRoles, and Messages) or at instance level (the diagram shows Objects, Links, and
Stimuli). The former presents the roles and their structure as defined in the underlying collaboration, while the latter focuses on instances that conform to the roles in the collaboration.
2.2.5
Implementation diagrams
Implementation diagrams show aspects of implementation, including source code structure and
run-time implementation structure. They come in two forms:
component diagrams, that show the structure of the code itself and
deployment diagrams, that show the structure of the run-time system.
They can also be applied in a broader sense to business modeling in which the “code” components
are the business procedures and documents and the “run-time structure” is the organization units
and resources (human and other) of the business.
2.2.5.1
Component diagrams
A component diagram (Figure 2.10) shows the dependencies among software components,
including source code components, binary code components, and executable components. For
a business, “software” components are taken in the broad sense to include business procedures
and documents. A component diagram has only a type form, not an instance form.
2.2.5.2
Deployment diagrams
Deployment diagrams (Figure 2.11) show the configuration of run-time processing elements
and the software components, processes, and objects that live on them. Software component instances represent run-time manifestations of code units. Components that do not exist as run-time
entities (because they have been compiled away) do not appear on these diagrams, they should
be shown on component diagrams. For business modeling, the run-time processing elements
include workers and organizational units, and the software components include procedures and
documents used by the workers and organizational units.
36
Figure 2.10: A component diagram (from [159]).
Figure 2.11: A deployment diagram (from [159]).
37
2.3
2.3.1
Specification approaches based on UML
AUML
AUML [161] has been developed to overcome some of the limitations of UML, which is sometimes insufficient to model agents and agent-based systems. Following [161], we describe the
adoption of AUML to specify agent interaction protocols (AIP)5 which are complex enough to
illustrate the nontrivial use of this UML extension.
2.3.1.1
A layered approach to protocols
Figure 2.12 depicts the FIPA6 contract net protocol expressed as a UML sequence diagram. This
diagram provides a basic specification, but more processing detail is often required. For example,
an Initiator agent requests a call for proposal (CFP) from a Participant agent. However, the
diagram stipulates neither the procedure used by the Initiator to produce the CFP request, nor the
procedure employed by the Participant to respond to the CFP. Yet, such details are important for
developing agent-based system specifications. Figure 2.13 illustrates how leveling can express
more detail for any interaction process.
For example, the process that generated the communication act CA-1 could be complex enough
to specify its processing in more detail using an activity diagram. The agent receiving CA-1 has
a process that prepares a response. Finally, leveling can continue “down” until the problem has
been specified adequately to develop or generate code.
2.3.1.2
Level 1: representing the overall protocol
It is desirable for the specification developer to have a set of reusable interaction protocols to be
adopted in different contexts. The UML techniques that best express protocol solutions for reuse
are packages and templates.
Packages. Because protocols can be codified as recognizable patterns of agent interaction, they
become reusable modules of processing that can be treated as first-class notions. For example,
Figure 2.14 depicts two packages. The Purchasing package expresses a simple protocol between a Broker and a Retailer while the Supplying package expresses the protocol between the
Retailer and a Wholesaler. Since many businesses or departments may not need the additional
5
An agent interaction protocol describes a communication pattern as an allowed sequence of messages between
agents and the constraints on the content of those messages.
6
Foundation for Intelligent Physical Agents, see Section 7.4.
38
Figure 2.12: A generic AIP expressed as a template package (from [161]).
39
Figure 2.13: More detailed specification of an AIP (from [161]).
Figure 2.14: Using packages to express nested protocols (from [161]).
40
Figure 2.15: Application of the template in Figure 2.9 to a particular scenario (from [161]).
protocol involving the Wholesaler, two distinct packages can be defined. When a particular
scenario requires the Wholesaler protocol, it can be nested as a separate and distinct package.
Templates. Figure 2.12 illustrates a common kind of behavior that can serve as a solution in
various problem domains: the FIPA Contract Net Protocol. Figure 2.15 applies the FIPA Contract
Net Protocol to a particular scenario involving buyers and sellers. Notice that the Initiator and
Participant agents have become Buyer and Seller agents, the call-for-proposal has become the
seller-rfp, and other modifications have been made.
41
Figure 2.16: Basic format for agent communication (from [161]).
2.3.1.3
Level 2: representing interactions among agents
The most useful UML’s models to represent interactions among agents are the dynamic models,
among which sequence and collaboration diagrams emphasize the chronological sequence of
communications, and activity and statechart diagrams capture the flow of processing in the agent
community. AUML proposes extensions to all of them, but since collaboration diagrams are
semantically equivalent to sequence diagrams, we will not deal with them.
Sequence diagrams. Figure 2.16 depicts some basic elements for agent communication. The
rectangle can express individual agents or sets (i.e., roles or classes) of agents. For example, an
individual agent could be labeled Bob/Customer. Here Bob is an instance of agent playing the
role of customer. To indicate that Bob is a Person – independent of any role he plays – Bob
could be expressed as Bob:Person. The basic format for the box label is agent-name/role:class.
Therefore, we could express all the various situations for Bob, such as Bob/Customer:Person
and Bob/Employee:Person. The rectangular box can also indicate a general set of agents playing a specific role by using the syntax agent-name/role:class without specifying an individual
agent-name. Figure 2.16 extends UML by labeling the arrowed line with an agent communication act (CA), instead of an OO-style message.
Another recommended extension to UML supports concurrent threads of interaction. Figure 2.17
depicts three ways of expressing multiple threads. Figure 2.17 (a) indicates that all threads CA-1
to CA-n are sent concurrently. Figure 2.17 (b) includes a decision box indicating an inclusive or.
Figure 2.17 (c) indicates an exclusive or.
Activity diagrams. Agent interaction protocols can sometimes require specifications with very
clear processing-thread semantics. The activity diagram expresses operations and the events that
42
Figure 2.17: Extensions for supporting concurrent threads of interaction (from [161]).
Figure 2.18: Activity diagram for a stock sale protocol (from [161]).
43
Figure 2.19: A statechart indicating valid states and transitions in an order protocol (from [161]).
trigger them. The example in Figure 2.18 depicts an order processing protocol among several
agents. The activity diagram differs from interaction diagrams because it provides an explicit
thread of control. This is particularly useful for complex interaction protocols that involve concurrent processing.
Statecharts. Figure 2.19 depicts an example of a statechart that governs an Order protocol.
The statechart is not commonly used to express interaction protocols because it is a state-centric
view, rather than an agent- or process-centered view. The state-centric view emphasizes the
permissible states more prominently than the transition agent processing. The primary strength
of the statechart in agent interaction protocols is as a constraint mechanism for the protocol. The
statechart and its states are typically not implemented directly as agents.
2.3.1.4
Level 3: representing internal agent processing
At the lowest level, specification of an agent protocol requires spelling out the detailed processing
that takes place within an agent in order to implement the protocol. In a holarchic model, higherlevel agents (holons) consist of aggregations of lower-level agents. The internal behavior of a
holon can thus be described using any of the Level 2 representations recursively. In addition,
statecharts and activity diagrams can also specify the internal processing of agents that are not
aggregates, as illustrated in the following.
44
Figure 2.20: An activity diagram specifying order processing (from [161]).
45
Figure 2.21: Statecharts that specify order processing behavior for three agents (from [161]).
Activity diagrams. Figure 2.20 depicts the detailed processing that takes place within an Order Processor agent. Here, a sequence diagram indicated that the agent’s process is triggered
by a Place Order CA and ends with the order completed. The internal processing by the Order
Processor is expressed as an activity diagram, where the Order Processor accepts, assembles,
ships, and closes the order. The dotted operation boxes represent interfaces to processes carried
out by external agents as also illustrated in the sequence diagram.
Statecharts. The internal processing of a single agent can also be expressed as statecharts.
Figure 2.21 depicts the internal states and transitions for Order Processor, Invoice Sender,
and Payment Receiver agents. As with the activity diagram above, these agents interface with
each other as indicated by the dashed lines.
46
Figure 2.22: Role modeling representing each role with its own lifeline (from [161]).
2.3.1.5
Other suggested extensions
Besides the AUML extensions for agent interaction protocols, [161] also proposes extensions for
other agent-based notions.
Richer role specification. Expressing the roles (ClassifierRoles) an agent may play in the
course of its interaction with other agents is a vital technique for modelers of agent-based systems, and UML 1.3 already provides some facility for expressing roles by means of the “slash”
notation. This approach, however, could quickly become graphically too complex to be comprehensible even with a small number of involved agents. Figures 2.22 and 2.23, then, illustrate two
new techniques that reduce the visual complexity, yet preserving the same underlying semantics
of the slash notation. Figure 2.22 represents each role with its own lifeline; Figure 2.23 depicts
each agent with a single lifeline, where each activation (the tall thin rectangle) is labeled with
the appropriate role name.
Collaboration diagrams currently have no facility to represent agent roles on interaction lines
within UML 1.3. However, each communication act (or message) could be labeled with the
47
Figure 2.23: Role modeling where activation bars are labeled with the appropriate role (from
[161]).
Figure 2.24: Role modeling where the communication acts indicate the requesting role (from
[161]).
48
Figure 2.25: An activity diagram with activities labeled with the appropriate agent role (from
[161]).
role that is responsible for issuing the request. This technique is illustrated in Figure 2.24. For
example, communication act 1.1 request is sent by agent A playing the role of Customer.
Activity diagrams can also be modified to represent agent roles by associating each activity with
the name of the appropriate ClassifierRole. For example in Figure 2.25, an Order agent accepts,
assembles, ships, and closes orders.
And lastly, changes in roles can be represented on activity diagrams using notes. For example in
Figure 2.26, the Hire Employee activity changes the role of an agent from being a Person to
also being an Employee. Such a technique is currently supported by UML.
Package extension. UML 1.3 employees “lollipops” to indicated interfaces. While this will
suffice for some agent implementations, it will not handle those situations where the agent itself
is the interface. For example in Figure 2.27, a Negotiator agent acts as the interface between the
outside world and the Manufacturing Cell. This would require a small extension to UML.
Deployment diagram extensions. Mobility is an important property for agents as it is for
objects , as well. A way of indicating mobility paths and at-home declarations would be a useful
extension to UML. Figure 2.28 shows how mobility could be added to deployment diagrams.
Other useful agent-based notions. Agents borrow many analogies from nature. For example,
agent cloning is a common agent-based technique. Figure 2.29 illustrates a behavioral and a
structural view of agent cloning.
49
Figure 2.26: Dynamic classification (role changes) expressed as notes (from [161]).
Figure 2.27: Package specifying agents instead of operations as interface points (from [161]).
50
Figure 2.28: Adding mobility to deployment diagrams (from [161]).
Figure 2.29: Representing cloning using sequence and class diagrams (from [161]).
51
Figure 2.30: Representing mitosis and reproduction using sequence and activity diagrams (from
[161]).
Figure 2.31: Representing parasitic and symbiotic relationships using class diagrams (from
[161]).
Mitosis and reproduction are also common techniques for agent-based societies. Figure 2.30
illustrates possible ways of expressing these. Extending the UML to include these notions permanently instead of by stereotype is a recommendation as these are common techniques.
Other notions that are commonly employed are parasitic and symbiotic relationships. Figure
2.31 illustrates some examples of these.
The interaction of many individual agents can give rise to secondary effects where groups of
agents behave as a single entity, or aggregate agent. This phenomenon is know as emergence.
While such occurrences are often unplanned and unexpected, they should be anticipated. In
multi-agent systems, emergence is a core concept and UML should be extended to represent it,
as shown in Figure 2.32.
52
Figure 2.32: Representing emergence possibilities using a class diagram (from [161]).
Figure 2.33: Sequence diagram and its constraints for an agent-based transaction (from [178]).
2.3.2
Automatic synthesis of agent designs in UML
In their short paper Automatic Synthesis of Agent Designs in UML [178], J. Schumann and
J. Whittle discuss an approach for bridging the current gap in UML between requirements, expressed as scenarios, and initial design specification. They are developing an algorithm that will
synthesize specifications from a collection of UML sequence diagrams. The algorithm provides
the following functionalities:
The user may describe scenarios of expected behavior and a statechart combining these
behaviors is generated automatically. Scenarios are merged based on simple specifications
of messages sent between agents, expressed in the UML constraint language OCL.
Scenarios not satisfying all the necessary OCL constraints may contain ambiguous or inconsistent behaviors with respect to other scenarios, and are flagged to the user.
53
The generated statecharts make full use of hierarchy and concurrency making them humanreadable and amenable to modifications, thus supporting iterative development.
2.3.2.1
Synthesis of statecharts designs
Adding semantic information. The lack of semantic content in statechart diagrams makes
them ambiguous and therefore difficult to interpret. To overcome this problem, J. Schumann
and J. Whittle extend statecharts with pre/post-condition style communication specifications in
OCL, as depicted in Figure 2.33. This specification includes the declaration of global state
variables which can be referenced in the pre- and post-conditions. Adding a domain theory
enables a formal comparison of statecharts. Conflicts between statecharts can be automatically
detected using the domain theory, also used for merging sequence diagrams. The constraints
provide necessary information about the ordering of messages in different diagrams, and enable
the detection of loops and the introduction of structure into the generated statecharts.
Generating Statecharts.
The algorithm generating statecharts consists of three individual steps:
1. Conflicts between the given statechart and the domain theory are detected and reported to
the user. A conflict can mean that a scenario does not follow the user’s intended semantics
or the domain theory is incorrect.
2. A set of flat finite state machines (FSMs) is generated (one for each participant in each
scenario). Each FSM focuses on a single agent, A, and describes its behavior w.r.t. the
given statechart. Communications directed away from A are considered as actions taken
by the agent.
3. Finally, all FSMs generated in the last step are combined into a single FSM (i.e., a flat
statechart). During this step, nodes which are similar to each other are merged, using the
domain theory to detect similar nodes. This allows to generate a single flat statechart which
is as compact as possible without violating the constraints given in the statecharts and the
domain theory.
Introducing Hierarchy. In practice, statecharts designs tend to get very large and so the judicious use of hierarchy and orthogonality is crucial to the readability and maintainability of the
designs. The approach discussed in [178] provides several ways for introducing hierarchy into
the generated FSMs: using implicit information present in the domain theory, introducing generalizations, and using information explicitly given by the user (e.g, by means of a UML class
diagram).
54
2.4
Z
In this section we introduce the Z notation that we will use in Section 2.5. The reader can refer
to [188] for more information on the language: it is the de facto standard reference book for Z.
This section is based on its first chapter.
Z is a formal language used both for specifying software modules and for documenting the
design of a program which implements the specification. Z notation helps in achieving these
goals through the use of mathematical data types and of schemas.
Mathematical data types make it possible to reason effectively about the way a specified system
will behave. Z uses the predicate logic notation to abstractly describe the effect of each operation.
Schemas are used to decompose a specification into small pieces. By splitting the specification
into schemas, it is possible to describe it piece by piece. Each piece can be linked with a commentary which informally explains the significance of the formal mathematics. Schemas are
used to describe both static and dynamic aspects of a system. The static aspects include:
the states the system can occupy;
the invariant relationships that are maintained as the system moves from state to state.
The dynamic aspects include:
the operations that are possible;
the relationship between their inputs and outputs;
the changes of state that may take place.
A state space schema looks like the following:
Entity
SuperEntity
attributes Attribute
attributes It has a name (Entity), the declaration of the schema it extends (SuperEntity) and the declaration
of some variables (attributes, which is a set of elements with basic type Attribute) in the part
above the central line, and a set of conditions that variables must meet, appearing below the
central line (attributes cannot be the empty set, in this example). This condition is an invariant
for the system.
55
Autonomous
Agents
Agents
Objects
Entities
Figure 2.34: The entity hierarchy (from [135]).
We do not provide further details on the Z notation since, in the framework for agency and
autonomy we describe below, we limit ourselves to the description of state spaces.
2.5
2.5.1
Specification approaches based on Z
A framework for agency and autonomy
In the paper [135], M. Luck, N. Griffiths and M. d’Inverno describe the construction of an agent
simulation environment strongly based on a formal theory of agent systems, but intended to serve
as a basis for practical development. The specification language adopted to describe the components of this environment is Z. In the rest of the section we will concentrate on the specification
of components, omitting the results of experiments and the implementation details which can be
found in [135].
The four-tiered hierarchy of entities. Entities in the simulation environment are organized
in a four levels hierarchy, depicted in Figure 2.34, comprising entities, objects, agents and autonomous agents. The basic idea underlying this hierarchy is that all components of the world
are entities. Entities can be used to group together attributes for any useful purpose without
adding a layer of functionality. They serve as an abstraction mechanism by which they are regarded as distinct from the reminder of the environment, and which can organize perception. An
object is just something with abilities and attributes and has no further defining characteristics.
An agent is an object that is useful to another agent since it is able to satisfy that agent’s goals.
Autonomous agents are agents that can generate their own goals from motivations. It is possible
to provide a complete formal specification of this view of agents in Z, as presented below. An
56
entity is just something with a non-empty set of attributes that is, typically, used as a template
for more sophisticated components. An object is an entity with the added constraint that it has a
non-empty set of capabilities. Similarly, an agent is an object with a non-empty set of goals and
an autonomous agent is an agent with a non-empty set of motivations. The following schemas
use schema inclusion for incremental definition.
Entity
attributes Attribute
attributes Object
Entity
capableof Action
capableof Agent
Object
goals Goal
goals AutonomousAgent
Agent
motivations Motivation
motivations The agent simulation environment. All entities are situated in the agent simulation environment (ASE) which is taken to be a very simple unit torus. Locations and sizes are determined
in relation to the unit torus, specified in terms of x and y coordinates. All the entities in ASE
are square and may be stationary or may move in some way. It is possible to introduce into the
formal specification subtypes which relate to classes of attributes. For example, the type Size
defines the attributes which specify size, and so on.
Size == Attribute
Location == Attribute
57
Shape == Attribute
Velocity == Attribute
This allows us to formally model ASE entities by adding more detail to the earlier entity schema.
ASEEntity
Entity
size Size
shape Shape
location Location
velocity Velocity
size shape location velocity attributes
The basic dynamic objects can have motions which are linear, circular or random. For example,
a linear object is specified by the following schema.
LinearASOObject
Object
ASEEntity
movebyvelocity capableof
where movebyvelocity is an action to move by a fixed amount in a linear direction determined by the current velocity. The predefined entities allow basic components such as food,
water, barriers and so on, as well as other, more sophisticated, components to be added to the
agent simulation environment in a uniform and elegant manner that is consistent with the formal
framework given earlier.
Agents are objects with goals which are the mental components that drive the intelligent behavior. In a reactive agent architecture, the predefined action sequences are executed to satisfy a goal
in particular conditions. It is a prerequisite of an agent, therefore, that it is able to perceive the
conditions that initiate behavior. In the framework, perception is defined to be a function of goals,
the current environment and the potential view of the environment. Several different agents have
been implemented. These require the inheritance of behaviors from previously defined instances
of agents, or the implementation of new behaviors. Among the behaviors implemented for the
experimental agents designed in ASE are wander, avoid-obstacle, flee and pursue. Formally,
behaviors are precompiled sequences of sets of actions of the following form:
Behavior == (seq( Action))
This allows to specify an action-selection function for an agent, which allows behaviors to be
ordered on priority, allowing a subsumption-like architecture [40, 41, 42, 43].
58
Finally, autonomous agents are defined as agents with a higher-level control provided internally
by motivations. We can specify, for example, motivations like curiosity, safety, fear, hunger and
so on. In a simple agent design we might associate the motivation of curiosity with the goal of
avoiding obstacles which, in turn, is associated with the actions required to achieve such results.
2.6
Conclusions
As noticed in Section 2.1 of [53], the predominant approach to developing methodologies for
MASs is to adapt those developed for object-oriented analysis and design: as an example, the
AAII methodology takes inspiration from J. Rumbaugh’s work, Gaia takes inspiration from FUSION [54], and so on. The most evident advantage of this approach is that concepts, notations
and methods associated with object-oriented analysis and design (and UML in particular) are
increasingly familiar to a mass audience of software engineers. However, there are several disadvantages too. First, the kinds of decomposition that object-oriented methods encourage is at odds
with the kind of decomposition that agent-oriented design encourages. Agents are more coarsegrained computational objects than objects. Agent systems implemented using object-oriented
programming languages will typically contain many objects, but will contain far fewer agents.
Another problem is that object-oriented methodologies simply do not allow us to capture many
aspects of agent systems; for example, it is hard to capture in object models such notions as an
agent pro-actively generating actions or dynamically reacting to changes in their environment,
still less how to effectively cooperate and negotiate with other self-interested agents. AUML
(Section 2.3.1) addresses some of these deficiencies: it proposes extensions to UML for specifying reuse, specialization and composition of existing interaction protocols, concurrent threads of
interaction, richer role models, mobility and cloning of agents, and other useful agent features.
However, it leaves many problems unsolved. At the heart of the problem are the relationships
between agents and objects that we discussed in Section 2.1, which have not been satisfactorily
resolved yet.
59
Chapter 3
Formal Methods for Agent-Oriented
Software Engineering
3.1
Introduction
As pointed out in [53], the use of formal methods is one of the most active areas in the AOSE
field, where formal methods play three roles:
in the specification of systems;
for directly programming systems; and
in the verification of systems.
Formal methods in specification. The current predominant approach to specifying agents has
involved treating them as intentional systems that may be understood by attributing to them mental states such as beliefs, desires and intentions [64, 204, 203]. Following this idea, a number of
approaches for formally specifying agents have been developed, capable of representing beliefs,
goals and actions of agents and the ongoing interaction among them. A theory which explains
how these aspects of agency interact to generate the behavior of an agent is an agent theory. A
large number of logics appear successful to formalize agent theories, among which modal logics
(Section 3.4), temporal logics (Section 3.7), deontic logics (Section 3.5), just to cite some of
them.
Formal methods in implementation. After the system has been specified, it must be implemented in such a way that the implementation respects the given specification. This transforma60
tion can be achieved in at least three ways:
1. manually refine the specification into an executable form via some principled but informal
refinement process;
2. directly execute or animate the abstract specification; or
3. translate or compile the specification into a concrete computational form.
As far as the first direction is concerned, at the time of writing most software developers use
structured but informal techniques to transform specifications into concrete implementations. In
particular, they often use techniques based on top-down refinement. In this approach an abstract
system specification is refined into a number of smaller, less abstract subsystem specifications.
The justification that each step represents a true refinement of the more abstract specification that
preceded it is usually given by informal argument. For functional systems, refinement is a well
understood process: such systems can be specified in terms of pre- and post-conditions [101]
and refinement calculi can be used to take a pre- and post-condition specification and from it
systematically derive an implementation through the use of proof rules [153]. For agent systems,
refinement is not so straightforward because such systems must be specified in terms of their
ongoing behavior. As a consequence, researchers have only just begun to investigate refinement
and design technique for agent-based systems.
Directly executing or animating the abstract specification is definitely more promising, even if it
presents difficulties too. To execute a formula of logic L means generating a logical model ,
L . If the agent had complete control over its environment, the execution
for , such that would reduce to constructive theorem proving. But this assumption is clearly false, and execution
must be thought of as a two players game, where the environment makes something true, the
agent responds by making something else true in the model, the environment plays again making
something true, and so on. The specification represents the goal of the game, which the agent
must keep satisfied and the environment tries to prevent the agent to keep it satisfied. Various
executable or animable languages based on different logics exist: all the languages we discuss in
this chapter are executable or animable since prototypical interpreters have been developed for
each of them, as discussed in Section 3.9.
The third approach, namely compiling the system specification, is the one followed for example
in the situated automata paradigm of S. J. Rosenschein and L. P. Kaelbling [175]. The advantages
of compilation over direct execution are those of compilation over interpretation in mainstream
programming: it is usually more efficient since the “reasoning work” involving symbolic manipulation is done off-line, at compile-time; execution of the compiled system can then be done
with little or no run-time symbolic reasoning.
61
Formal verification. Verification is the process of showing that an implemented system is
correct with respect to its original specification. Approaches to verification can be axiomatic and
semantic. If the programming language in which the system is implemented is axiomatizable,
deductive (axiomatic) verification is possible. Two agent programming languages have been
axiomatized: AGENT-0 and Concurrent METATEM. Otherwise, the model checking semantic
approach can be followed. The model checking problem is, in abstract, quite simple: given a
formula of logic L and a model for L, determine whether or not L . An example of
an executable language which has been used to check models of agent systems is hhf (Section
3.8.1), based on linear logic (Section 3.8).
This chapter provides an overview of some logics and calculi which have proven useful to formalize agent theories. For each logics we introduce, one executable or animable agent language
based on the logics is presented1 , and, for each language, an example is shown. A detailed comparison of the agent languages we analyzed is given in Section 3.9. Up to our knowledge, at
the time of writing no survey exists which provides a complete and deep description on formal
methods for AOSE as this chapter does.
3.2
The running example
To show how to define an agent in the various agent languages we discuss in this paper, we use a
simple seller agent example which follows the communication protocol depicted in Figure 3.1.
The seller agent in a distributed marketplace application may receive a contractProposal message from a buyer agent. According to the amount of stuff required and the price proposed by
the buyer, the seller may accept the proposal, refuse it or try to negotiate a new price by sending
a contractProposal message back to the buyer. The business logic guiding the behavior of the
agent is the following:
if the received message is contractProposal(stuff, amount, proposed-price)
then
– if there is enough stuff in the warehouse and the price is greater or equal than a max
value, the seller accepts the proposal by sending an accept message to the buyer and
concurrently ships the required goods to the buyer2 ;
1
Some languages involve features of more than one logic; for example Concurrent METATEM involves modal
and temporal logic, AGENT-0 is based on modal and deontic logic. The classification we give of agent languages
takes into account the “most relevant component” of the language, but different acceptable classifications could be
provided.
2
If it is not possible to define concurrent actions, answering and shipping goods will be executed sequentially.
62
Seller
Buyer
contractProposal
accept
refuse
contractProposal
acknowledge
accept
refuse
contractProposal
acknowledge
Figure 3.1: The contract proposal protocol.
– if there is not enough stuff in the warehouse or the price is lower or equal than a min
value, the seller agent refuses the proposal by sending a refuse message to the buyer;
– if there is enough stuff in the warehouse and the price is between min and max,
the seller sends a contractProposal to the buyer with a proposed price evaluated as
the means of the price proposed by the buyer and max (we will sometimes omit the
definition of this function, which is not of central interest in our example) .
In our example, the stuff to be exchanged are oranges, with minimum and maximum price 1 and
2 euro respectively. The initial amount of oranges that the seller possesses is 1000.
63
3.3
Situation calculus
The situation calculus (J. McCarthy [147]) has long been a staple of AI research, but only recently
there have been attempts to axiomatize it. The following description is based upon work by
F. Pirri and R. Reiter [168]. sit calc is a second order language with equality. Is has three
disjoint sorts: action for actions, situation for situations and a catch-all sort object for everything
else depending on the domain of application. Apart from the standard alphabet of logical symbols
( "! and # , used with their usual meaning), sit calc has the following alphabet:
Countably infinitely many individual variable symbols of each sort and countably infinitely
many predicate variables of all arities.
Two function symbols of sort situation:
1. A constant symbol S$ , denoting the initial situation.
2. A binary function symbol do % action & situation ' situation. do ( a s ) denotes the
successor situation resulting from performing action a in situation s.
A binary predicate symbol *+% situation & situation, defining an ordering relation on situations. The intended interpretation of situations is as action histories, in which case s * s,
means that s is a proper sub-history of s, .
A binary predicate symbol Poss % action & situation. The intended interpretation of
Poss ( a s ) is that it is possible to perform the action a in the situation s.
Countably infinitely many predicate symbols used to denote situation independent relations and countably infinitely many function symbols used to denote situation independent
functions.
A finite or countably infinite number of function symbols called action functions and used
to denote actions.
A finite or countably infinite number of relational fluents (predicate symbols used to denote
situation dependent relations).
A finite or countably infinite number of function symbols called functional fluents and used
to denote situation dependent functions.
In the axiomatization proposed in [129], axioms are divided in domain independent foundational
axioms for situations and domain axioms. Besides axioms, [129] also introduces basic theories
of actions and a metatheory for the situation calculus which allows to determine when a basic
action theory is satisfiable and when it entails a particular kind of sentences, called regressable
sentences. Here we only discuss domain independent foundational axioms for situations. Since
64
the scope of this chapter is to provide introductory material which can be understood with little
effort, we will address neither domain axioms nor the metatheory for the situation calculus, both
of which require a strong technical background.
3.3.1
Foundational axioms for situations
There are four foundational axioms for the situation calculus, based on [168] but simpler that
the ones presented there. They allow to capture the intuition that situations are finite sequences
of actions where the second order induction principle holds, and that there is a “subsequence”
relation among them. In the following axioms, P is a predicate symbol.
do ( a -" s -.)/
do ( a 0 s01)32
a -3 a04 s -3 s0
(65 P )87 P ( S $")9:(65 a s ); P ( s )42
P ( do ( a s )<)>=?2
(65 s ) P ( s )87
(3.1)
(3.2)
Axiom 3.1 is a unique name axiom for situations: two situations are the same iff they are the
same sequence of actions. Axiom 3.2 is second order induction on situations. The third and
fourth axioms are:
! s *
S$
s * do ( a s, )3@
(3.3)
s A s, 7
(3.4)
Here s A s, is an abbreviation for s * s,1B s s, . The relation * provides an ordering relation on
situations. Intuitively, s * s, means that the action sequence s, can be obtained from the sequence
s by adding one or more actions to the front of s.
The above four axioms are domain independent. They provide the basic properties of situations
in any domain specific axiomatization of particular fluents and actions.
3.3.2
ConGolog
ConGolog is a concurrent programming language based on the situation calculus which includes facilities for prioritizing the concurrent execution, interrupting the execution when certain
conditions become true, and dealing with exogenous actions. As stated by G. De Giacomo,
Y. Lespérance and H. Levesque in [94], the adoption of such a language is a promising alternative to traditional plan synthesis, since it allows high-level program execution [130]. ConGolog
is an extension of the programming language Golog [130]: in Section 3.3.2.1 we present Golog
and in Section 3.3.2 we deal with its extension ConGolog.
65
3.3.2.1
Golog
Golog is a logic-programming language whose primitive actions are those of a background domain theory. It includes the following constructs:
a
Primitive action.
Wait for a condition.
Sequence.
Nondeterministic choice between actions.
Nondeterministic choice of arguments.
Nondeterministic iteration.
DC
(FEG-"HIEJ0")
(FEG-KLEJ08)
M v 7NE
ELO
P
proc P -(RvQ -S).EG- end; 777 proc Pn (<vQ n ).E
n
end; EUT
Procedures.
In the first line, a stands for a situation calculus action with all situation arguments in its parameters replaced by the special constant now. Similarly in the line below stands for a situation
calculus formula with all situation arguments replaced by now. In the following lines, E , possibly
subscripted, ranges over Golog programs.
Program Execution. Given a domain theory V
sequence of actions Q a such that:
VW and a program E the execution task is to find a
Do (FEX S$ do ( Q a S$")<)
where
Do (YEX s s, )
means that program E when executed starting in situation s has s, as a legal terminating situation,
and
do ( Q a s )/ do (<; a -17779 an =Z s )
is an abbreviation for
do ( an do ( an -R7779 do ( a -1 s )[777<)<) .
Since Golog programs can be nondeterministic, there may be several terminating situations for
the same program and starting situation. Do (YEX s s,\) is formally defined by means of the following
inductive definitions:
1. Primitive actions:
def
Do (YEX s s, ) Poss ( a ; s=Z s )] s, do ( a ; s=Z s )
66
2. Wait/test actions:
def
Do (ZDC
s s, ) ^_; s=` s s,
3. Sequence:
def
Do (YEX-"HaEJ0X s s, ) ^# s, , 7 Do (FEG-" s s, , )9 Do (YEJ0 s, , s, )
4. Nondeterministic branch:
def
Do (YEX-LE80X s s,\) Do (YEX-" s s,b)9B Do (FEJ0X s s,\)
5. Nondeterministic choice of argument:
def
# x 7 Do (FEd( x )8 s s, )
Do ( M x 7NE`( x )8 s s, ) c
6. Nondeterministic iteration:
def
P
Do (YELO s s, ) 5 P 7 5 s - P ( s -" s -S)9e5 s -" s0 sfG; P ( s -" s0")9 Do (YEX s0 sf")
2 P ( s -1 s f")>=YTg2 P ( s s,h)
We do not deal with expansion of procedures. The reader can see [130] for the details.
3.3.2.2
ConGolog
ConGolog is an extended version of Golog that incorporates a rich account of concurrency,
handling:
concurrent processes with possibly different priorities;
high-level interrupts and
arbitrary exogenous actions.
The ConGolog language is exactly as Golog, except for the following additional constructs:
if then EX- else EJ0
while DC do E
(FEG-Ki E808)
(FEG-.jRj.EJ0")
Ek
l
m' Eon
Synchronized conditional.
Synchronized loop.
Concurrent execution.
Concurrency with different priorities.
Concurrent iteration.
Interrupt.
67
The constructs if then EG- else E80 and while DC do E are the synchronized versions of the usual
if-then-else and while-loop. They are synchronized in the sense that the test of the condition
does not involve a transition per se: the evaluation of the condition and the first action of
the branch chosen will be executed as a unity. The construct (YEG-piqE80") denotes the concurrent
execution of the actions EG- and EJ0 . (YEX-<jRj<EJ01) denotes the concurrent execution of the actions
EG- and E80 with EG- having higher priority than EJ0 , restricting the possible interleavings of the
two processes: EJ0 executes only when EX- is either done or blocked. The construct Ek is like
nondeterministic iteration, but where the instances of E are executed concurrently rather than in
l
sequence. Finally, m' Ern is an interrupt. It has two parts: a trigger condition and a body
E . The idea is that the body E will execute some number of times. If never becomes true, E will
not execute at all. If the interrupt gets control from higher priority processes when is true, then
E will execute. Once it has completed its execution, the interrupt is ready to be triggered again.
This means that a high priority interrupt can take complete control of the execution.
3.3.2.3
Semantics
The semantics of Golog and ConGolog is given as a transition semantics. Two predicates are
defined which state when a program E can legally terminate in a certain situation s (Final (FEX s ) )
and when a program E in the situation s can legally execute one step, ending in situation s,
with program E , remaining (Trans (YEX s 1E , s, ) ). Final and Trans are characterized by a set of
equivalence axioms, each depending on the structure of the first argument. To give the flavor of
how these axioms look like, we show the ones for empty program nil, atomic action a, testing
DC , nondeterministic branch (FEG-sdEJ08) and concurrent execution (YEG-ri+EJ0") 3 . The reader can find
the complete set of axioms for Final and Trans in [94].
Trans ( nil s REG,b s,b)
Trans ( a s 1EG,b s,b)
Trans (ZDC
s REG,u s,\)
Trans (YEX-vwE80 s REG,x s,b)
Trans (YEX-viDEJ0X s 1E , s, )
@
@
@
@
false
Poss ( a ; s=Y s )[tEG,d nil s,d do ( a ; s=Z s )
_; s=`tEX,d nil s,` s
Trans (YEG-R s 1EX,6 s,\)9B Trans (FEJ0 s 1EXx, s,b)
@
# z
y 7NEX,d{(|y}iDE80")~ Trans (YEG-R s <yz s,\).B
# yz7NEX,d{(YEX-iay[)~ Trans Y( EJ0J s < yz s\, )
The meaning of these axioms is that ( nil s ) does not evolve to any configuration; ( a s ) evolves
in ( nil do ( a ; s=Y s ).) provided that a ; s= is possible in s; (ZDC
s ) evolves to ( nil s ) provided that _; s=
holds; (FEG-KLEJ0X s ) can evolve to (YE , s, ) provided that either (YEG-1 s ) or (FEJ0X s ) can do so; and finally,
3
In order to define axioms properly, programs should be encoded as first order terms. We avoid dealing with this
encoding, and describe axioms as if programs were already first order terms.
68
(YEX-qiE80 s ) can evolve if (YEG-8 s ) and EJ0 remains unchanged or (YEJ0 s ) can evolve and EG- remains
unchanged.
Final ( nil s )
Final ( a s )
Final (ZDC
s )
Final (YEG-vE80 s )
Final (YEG-vi EJ0 s )
@
@
@
@
@
true
false
false
Final (YEX-1 s )9B Final (FEJ0 s )
) Final F( EJ0 s )
Final (YEX-1 s 9
These axioms say that ( nil s ) is a final configuration while neither ( a s ) nor (ZDC
s ) are. (YEG-
EJ0X s ) is final if either (YEG-8 s ) is or (FEJ0X s ) is, while (YEX-_iDE80X s ) is final if both (YEX-" s ) and (YEJ0 s ) are
final.
The possible configurations that can be reached by a program E in situation s are those obtained
by repeatedly following the transition relation denoted by Trans starting from (FEX s ) . The reflexive
transitive closure of Trans is denoted by Trans*. By means of Final and Trans* it is possible to
give a new definition of Do as
def
Do (YEX s s, ) ^#E , 7 Trans _(YEX s RE , s, )9 Final (YE , s, )
3.3.2.4
Implementation
A simple implementation of ConGolog has been developed in Prolog. The definition of the
interpreter is lifted directly from the definitions of Final, Trans and Do given above. The interpreter requires that the program’s precondition axioms, successor state axioms and axioms about
the initial situation be expressible as Prolog clauses. In particular, the usual closed world assumption is made on the initial situation. Section 8 of [94] describes the ConGolog interpreter
in detail and proves its correctness under suitable assumptions. The interpreter is included in
a more sophisticated toolkit which provides facilities for debugging ConGolog programs and
delivering process modeling applications by means of a graphical interface.
3.3.2.5
Example
The program for the seller agent, written in ConGolog, could look like the following. The
emphasized text is used for constructs of the language; the normal text is used for comments.
Lowercase symbols represent constants of the language and uppercase symbols are variables.
Predicate and function symbols are lowercase. These conventions will be respected throughout
all the paper, unless stated otherwise.
69
Primitive actions:
ship(Buyer, Stuff, Required-amount)
The seller agent delivers the Required-amount of Stuff to the Buyer.
send(Sender, Receiver, Message)
Sender sends Message to Receiver.
Situation independent functions:
min-price(Stuff) = Min
The minimum price the seller is willing to take under consideration for Stuff is Min.
max-price(Stuff) = Max
The price for Stuff that the seller accepts without negotiation is equal or greater that
Max.
Primitive fluents:
receiving(Sender, Receiver, Message, S)
Receiver receives Message from Sender in situation S.
storing(Stuff, Amount, S)
The seller stores Amount of Stuff in situation S.
Initial state:
min-price(orange) = 1
max-price(orange) = 2
5 S, R, M, ! receiving(S, R, M, s $ )
storing(orange, 1000, s$ ))
Precondition axioms:
poss(ship(Buyer, Stuff, Required-amount), S) @
storing(Stuff, Amount, S) Amount Required-amount
It is possible to ship stuff if there is enough stuff stored in the department-store.
poss(send(Sender, Receiver, Message), s) @ true
It is always possible to send messages.
Successor state axioms:
poss(A, S) 2
(receiving(Sender, Receiver, Message, do(A, S)) @
(A = send(Sender, Receiver, Message)
70
B (A
Message = empty-msg))
Receiver is receiving a non-empty Message from Sender if Sender sent Message to
Receiver in the previous situation. Otherwise, Receiver picks up an empty message
from its mailbox.
poss(A, S) 2
(storing(Stuff, Amount, do(A, S)) @
(A = ship(Buyer, Stuff, Required-amount) storing(Stuff, Required-amount + Amount, S))
B (A ship(Buyer, Stuff, Required-amount) storing(Stuff, Amount, S)))
The seller has a certain Amount of Stuff if it had Required-amount + Amount of Stuff
in the previous situation and it shipped Required-amount of Stuff, or if it had Amount
of Stuff in the previous situation and it did not ship any Stuff.
We may think that a buyer agent executes a buyer-life-cycle procedure concurrently with the
seller agent procedure seller-life-cycle. buyer-life-cycle defines the actions the buyer agent takes
according to its internal state and the messages it receives. The seller-life-cycle is defined in the
following way.
proc seller-life-cycle
while true do
if receiving(Buyer, seller, contractProposal(Stuff, Required-amount, Price), now)
then
if storing(Stuff, Amount, now)
Amount Required-amount
Price max-price(Stuff)
then ship(Buyer, Stuff, Required-amount)
i send(seller, Buyer, accept(Stuff, Required-amount, Price))
else
if (storing(Stuff, Amount, now)
l
Amount Required-amount)
B Price min-price(Stuff)
then send(seller, Buyer, refuse(Stuff, Required-amount, Price))
else
71
if storing(Stuff, Amount, now)
Amount Required-amount
l
l
min-price(Stuff) Price max-price(Stuff)
then send(seller, Buyer,
contractProposal(Stuff, Required-amount, (Price+max-price(Stuff))/2))
else nil
else nil
3.4
Modal Logic
Modal logic is an extension of classical logic with (generally) a new connective and its derivable counterpart , known as necessity and possibility respectively4. If a formula p is true,
it means that p is necessarily true, i.e. true in every possible scenario, and p means that p is
possibly true, i.e. true in at least one possible scenario. It is possible to define in terms of :
p
!DD! p
so that p is possible exactly when its negation is not necessarily true. In order to give meaning
to and , models for modal logic are usually based on possible words, which are essentially a
collection of connected models for classical logic. The possible worlds are linked by a relation
which determines which worlds are accessible from any given world. It is this accessibility
relation which determines the nature of the modal logic. Each world is given a unique label,
taken from a set S, which is usually countably infinite. The accessibility relation R is a binary
relation on S. The pairing of S and R defines a frame or structure which underpins the model of
modal logic. To complete the model we add an interpretation
h % S & PROP '
P
true false T
of propositional formulae PROP in each state so that

S R h jv a
iff
h ( s a )/
true

This is read as a is true in the model S R h j in world s iff h maps a to true in world s. In general
when a formula is true in a world s in a model M, it is denoted by
s

and if it is true in every world in the set S, it is said to be true in the model, and denoted by

The boolean connectives are given the usual meaning:
4
Our introduction to modal logic is based on [85] by M. Fisher and R. Owens.
72

S R h jv
S R hv
j s
s
B
}2
iff
iff

S R h jK
S R hK
j s
s

or S R h jv s
implies S R h jK s

The frame enters the semantic definition only when the modality is used, as the formula D is
true in a world s exactly when every world t in S which is accessible from s (i.e. such that s R t)
has true. More formally,

S R h jv s
D
iff
for all t S
s R t implies S R h jK t

The models S R h j and the semantics we introduced for connectives are also known as Kripke
models (or structures) and Kripke semantics, respectively [123, 122, 124], from the name of the
author who mainly contributed to develop a satisfactory semantic theory of modal logic.
3.4.1
AGENT-0
The paper Agent-Oriented Programming by Y. Shoham [181] is one of the most cited papers in
the agent community since, as written in its introduction,
This paper proposes a new programming paradigm. The paradigm promotes a societal view of computation, in which multiple “agents” interact with one another.
In this section we first introduce the basic concepts of the agent-oriented programming (AOP)
paradigm, and then we present the AGENT-0 programming language, which is often referred to
as the first agent programming language, even if
the simplifications embodied in AGENT-0 are so extreme that it may be tempting to
dismiss it as uninteresting.
as Y. Shoham himself writes.
AOP. For Y. Shoham, a complete AOP system will include three primary components:
1. A restricted formal language with clear syntax and semantics for describing mental states;
the mental state will be defined uniquely by several modalities, such as belief and commitments.
2. An interpreted programming language in which to define and program agents, with primitive commands such as REQUEST and INFORM.
73
3. An “agentifier” converting neutral devices into programmable agents.
The focus of Y. Shoham’s work is on the second component.
The mental categories upon which the AOP is based are belief and obligation (or commitment).
A third category, which is not a mental construct, is capability. Decision (or choice) is treated as
obligation to oneself.
Since time is basic to the mental categories, it is necessary to specify it. A simple point-based
temporal language is used to talk about time; a typical sentence will be
holding ( robot cup )
t
meaning that the robot is holding the cup at time t.
As far as actions are concerned, they are not distinguished from facts: the occurrence of an action
is represented by the corresponding fact holding.
Beliefs are represented by means of the modal operator B. The general form of a belief statement
is
Bta meaning that agent a believes at time t.
The fact that at time t an agent a commits himself to agent b about sentence
is represented by the
OBLta b A decision is an obligation to oneself, thus
def
DECat f OBLta a f
The fact that at time t agent a is capable of is represented by
CANat Finally, there is an “immediate” version of CAN:
ABLEa def
time h
CANa
where time (ZD) is the outermost time occurring in .
To allow the modalities introduced so far resemble their common sense counterparts, some assumptions are made:
74
Internal consistency: both the beliefs and the obligations are assumed to be internally
consistent.
Good faith: agents commit only to what they believe themselves capable of, and only if
they really mean it.
Introspection: agents are aware of their obligations.
Persistence of mental state: agents have perfect memory of, and faith in, their beliefs, and
only let go on a belief if they learn a contradictory fact. Obligations too should persist, and
capabilities too tend not to fluctuate wildly.
AGENT-0. In AGENT-0 the programmer specifies only conditions for making commitments;
commitments are actually made and later carried out, automatically at the appropriate times.
Commitments are only to primitive actions, those that the agent can directly execute. Before
defining the syntax of commitments, other basic definitions are necessary.
Facts. Fact statements constitute a tiny fragment of the temporal language described in the previous paragraph: they are essentially the atomic objective sentences.
Private actions. The syntax for private actions is
(DO t p-action)
where t is a time point and p-action is a private action name. The effects of private actions
may or may not be visible to other agents.
Communicative actions. There are three types of communicative actions:
(INFORM t a fact)
where t is the time point in which informing takes place, a is an agent name and fact is a
fact statement.
(REQUEST t a action)
where t is a time point, a is an agent name and action is an action statement.
(UNREQUEST t a action)
where t is a time point, a is an agent name and action is an action statement.
Nonaction. A “nonaction” prevents an agent from committing to a particular action.
(REFRAIN action)
Mental conditions. A mental condition is a logical combination of mental patterns, where the
“agent” and “time” arguments are omitted. A mental pattern may assume two forms:
(B fact)
meaning that the agent believes B or
((CMT a) action)
where CMT stands for commitment.
75
Conditional action. The syntax of a conditional action is
(IF mntlcond action)
Message condition. A message condition is a logical combination of message patterns, which
are triples
(From Type Content)
where From is the sender’s name, Type is INFORM, REQUEST or UNREQUEST and Content is a fact statement or an action statement.
Now we are able to provide the syntax of a Commitment rule:
(COMMIT msgcond mntlcond (agent action)*)
where msgcond and mntlcond are respectively message and mental conditions, agent is an agent
name, action is an action statement and * denotes repetition of zero or more times. A program is
simply a sequence of commitment rules preceded by a definition of the agent’s capabilities and
initial beliefs, and the fixing of the time grain.
3.4.1.1
Semantics
No formal semantics for the language is given.
3.4.1.2
Implementation
A prototype AGENT-0 interpreter has been implemented in Common Lisp and has been installed on Sun/Unix, DecStation/Ultrix and Macintosh computers. Both the interpreter and the
programming manual are available to the scientific community. A separate implementation has
been developed by Hewlett Packard as part of a joint project to incorporate AOP in the New
WaveTM architecture.
The AGENT-0 engine is characterized by the following two-steps cycle:
1. Read the current messages and update beliefs and commitments.
2. Execute the commitments for the current time, possibly resulting in further belief change.
Actions to which agents can be committed include communicative ones such as informing and
requesting, as well as arbitrary private actions.
76
3.4.1.3
Example
The AGENT-0 program for the seller agent may look like the following. Variables are preceded
by a “?” mark instead of being uppercase, coherently with the language syntax. Universallyquantified variables are denoted by the prefix “?!”.
timegrain := m
The program is characterized by a time-grain of one minute.
CAPABILITIES := ((DO ?time (ship ?!buyer ?stuff ?required-amount ?!price))
(AND (B (?time (stored ?stuff ?stored-amount)))
( nK ?stored-amount ?required-amount))
The agent has the capability of shipping a certain amount of goods, provided that, at the time
of shipping, it believes that such amount is stored in the department-store.
INITIAL BELIEFS := (0 (stored orange 1000))
(?!time (min-price orange 1))
(?!time (max-price orange 2))
The agent has initial beliefs about the minimum price, maximum price and stored amount of
oranges. The initial belief about stored oranges only holds at time 0, since this amount will
change during the agent’s life, while beliefs about minimum and maximum prices hold whatever
the time.
COMMITMENT RULES := (COMMIT
(?buyer REQUEST
(DO now+1 (ship ?buyer ?stuff ?req-amnt ?price)))
(AND (B (now (stored ?stuff ?stored-amount)))
( nK ?stored-amount ?req-amnt)
(B (?!time (max-price ?stuff ?max)))
( nK ?price ?max))
(?buyer (DO now+1
(ship ?buyer ?stuff ?req-amnt ?price)))
(myself (INFORM now+1 ?buyer
77
(accepted ?stuff ?req-amnt ?price)))
(myself (DO now+1 (update-stuff ?stuff ?req-amnt)))
)
The first commitment rule says that if the seller agent receives a request of shipping a certain
amount of goods at a certain price at time now+1, and if it believes that at time now the required
amount is stored in the department-store and the proposed price is greater than max-price, the
seller agent commits itself to the buyer to ship the goods (ship is a private action) at time now+1,
and decides (namely, commits itself to itself) to inform the buyer that its request has been accepted and to update the stored amount of goods (update-stuff is a private action).
(COMMIT
(?buyer REQUEST
(OR (AND (B (now (stored ?stuff ?stored-amount)))
l
( ?stored-amount ?req-amnt))
(AND (B (?!time (min-price ?stuff ?min)))
l
( ?price ?min)))
(myself (INFORM now+1 ?buyer
(refused ?stuff ?req-amnt ?price)))
)
The second rule says that if the required amount of goods is not present in the departmentstore or the price is too low, the seller agent decides to inform the buyer that its request has been
refused.
(COMMIT
(?buyer REQUEST
(AND (B (now (stored ?stuff ?stored-amount)))
( nK ?stored-amount ?req-amnt)
(B (?!time (max-price ?stuff ?max)))
l
( ?price ?max)
(B (?!time (min-price ?stuff ?min)))
( n ?price ?min))
78
(myself (DO now+1 (eval-mean ?max ?price ?mean-price)))
(myself (REQUEST now+1 ?buyer
(eval-counter-proposal ?stuff ?req-amnt ?mean-price)))
)
Finally, the third rule says that if the price can be negotiated and there is enough stuff in the
department-store, the seller agent evaluates the price to propose to the buyer agent (eval-mean is
a private action) an decides to send a counter-proposal to it.
3.5
Deontic Logic
Deontic logic5 is the logic to reason about ideal and actual behavior. From the 1950s, G. H. Von
Wright [197], H. N. Castañeda [49], C. E. Alchourrón [7] and others developed deontic logic
as a modal logic with operators for permission, obligation and prohibition. Other operators are
possible, such as formalizations of the system of concepts introduced by W. N. Hohfeld in 1913,
containing operators for duty, right, power, liability, etc [102]. Deontic logic has traditionally
been used to analyze the structure of normative law and normative reasoning in law. Recently
it has been realized that deontic logic can be of use outside the area of legal analysis and legal
automatization: it has a potential use in any area where we want to reason about ideal as well as
actual behavior of systems. To give an idea of what deontic logic systems look like, we describe
the ‘OS’ Old System by G. H. Von Wright [197] and the ‘KD’ Standard System of Deontic Logic
by L. Åqvist [169].
3.5.1
The OS System
The OS system is based on two deontic operators: O, meaning obligation, and P meaning permission. Let p be a proposition in the propositional calculus, then Op and Pp are formulae in the
OS deontic logic language.
The system consists of the following axioms and inference rule:
(OS0) All (or enough) tautologies of Propositional Calculus
(OS1) Op @! P ! p
(OS2) Pp B P ! p
5
Our introduction to deontic logic is based on the book Deontic logic in Computer Science edited by JJ. .Ch. Meyer and R. J. Wieringa [148].
79
(OS3) P ( p B q )a@
Pp B Pq
p q
(OS4) Pp Pq
Axiom (OS1) expresses that having an obligation to p is equivalent to not being permitted to
not p; (OS2) states that either p is permitted or not-p is; (OS3) says that a permission to p or
q is equivalent with being permitted that p or being permitted that q; (OS4) asserts that if two
assertions are equivalent, then permission to one implies permission to the other, and vice versa.
Later, it was realized that the system OS is very close to a normal modal logic, enabling a clear
Kripke-style semantics using O as the basic necessity operator, at the expense of introducing the
validity of
(O ) O ( p Bt! p )
stating the existence of an empty normative system, which G. H. Von Wright rejected as an
axiom.
3.5.2
The KD System
The KD System is a Wright-type system including the F (forbidden) operator and consisting of
the following axioms and rules.
(KD0) All (or enough) tautologies of Propositional Calculus
(KD1) O ( p 2
(KD2) Op 2
q )/2
( Op 2
Oq )
Pp
(KD3) Pp @! O ! p
(KD4) Fp @! Pp
(KD5) Modus ponens:
p p q
q
p
(KD6) O-necessitation: Op
Axiom (KD1) is the so called K-axiom; (KD2) is the D-axiom, stating that obligatory implies
permitted; (KD3) states that permission is the dual of obligation and (KD4) says that forbidden is
not permitted. (KD1) holds for any modal necessity operator. Essentially, it states that obligation
is closed under implication. Whether this is desirable may be debatable, but it is a necessary
consequence of the modal approach. Note furthermore that the O-necessitation rule (KD6),
which is also part of the idea of viewing deontic logic as a normal modal logic, implies the
axiom rejected by G. H. Von Wright
80
(O ) O ( p Bt! p )
So, if we want to view deontic logic as a branch of Kripke-style modal logic, we have to commit
ourselves to (O ).
As with other modal logics, the semantics of the standard system is based on the notion of
a possible world. Given a Kripke model S R h j and a world s S we give the following
semantics to the modal operators:

S R h jv j S R hv

j S R hv

s
s
s
Op
Pp
Fp
iff
iff
iff
for all t S s R t implies
exists t S such that s R t
for all t S s R t implies

S R h jK t p
S R h j t p

S R h jg t p
As already stated, the operator O is treated as the basic modal operator : for Op being true
in world s we have to check whether p holds in all the worlds reachable from s, as given by
the relation R. This reflects the idea that something is obligated if it holds in all perfect (ideal)
worlds (relative to the world where one is). This semantics is exactly the same semantics of ,
as defined in Section 3.4. The other operators are more or less derived from O. The operator P
is the dual of O: Pp is true in the world s if there is some world reachable from s where p holds.
Finally, something is forbidden in a world s if it does not hold in any world reachable from s.
3.5.3
The IMPACT agent language
We introduce the IMPACT agent programming language [12, 72, 71, 73] as a relevant example
of use of deontic logic to specify agents. In order to describe this language, we provide a set of
definitions on top of which the language is based.
Agent Data Structures. All IMPACT agents are built “on top” of some existing body of code
specified by the data types or data structures, , that the agent manipulates and by a set of
functions, , that are callable by external programs. Such functions constitute the application
programmer interface or API of the package on top of which the agent is being built.
Based on and supported by a body of software code , we may use a unified language to
query the data structures. If t} is an n-ary function defined in that package, and , 777 , ¡
are terms of appropriate types, then ¢%£(| 8777]<¡J) is a code call. This code call says “Execute
function as defined in package on the stated list of arguments.”
A code call atom is an expression ¤¤w¥ of the form ¦§](|¨¤¤
) or §?©L£¦§](|¨¤¤
) , where is a term
and ¤¤ is a code call.
81
A code call condition is a conjunction of code call atoms and constraint atoms, which may
involve deconstruction operations. They provide a simple, but powerful syntax to access heterogeneous data structures.
Each agent is also assumed to have access to a message box data structure, together with some
API function calls to access it.
At any given point in time, the actual set of objects in the data structures (and message box)
managed by the agent constitutes the state of the agent. We shall identify a state ª with the set
of ground (namely, containing no variables) code calls which are true in it.
Actions. The agent has a set of actions « ( X -"777[ Xn ) , where X -8777[ Xn are variables for parameters that can change its state. Such actions may include reading a message from the message
box, responding to a message, executing a request, updating the agent data structures, etc. Even
doing nothing may be an action. Expressions «¬(6t ) , where t is a list of terms of appropriate types,
are action atoms. Every action « has a precondition ®U¯w°(F«±) (which is a code call condition),
a set of effects (given by an add list ²³´³¨(F«±) and a delete list µ¶°X·.(F«±) of code call atoms) that
describe how the agent state changes when the action is executed, and an execution script or
method consisting of a body of physical code that implements the action.
Notion of Concurrency. The agent has an associated body of code implementing a notion of
concurrency conc ( AS Jªs) . Intuitively, it takes a set of actions AS and the current agent state ª
as input, and returns a single action (which “combines” the input actions together) as output.
Various possible notions of concurrency are described in [72, 192].
Integrity Constraints. Each agent has a finite set ¸ C of integrity constraints that the state ª
of the agent must satisfy (written ª W¸ C), of the form
2
¹ a where is a code call
condition, and ¹ a is a code call atom or constraint atom. Informally, 2
¹ a has the meaning
6
of the universal statement “If is true, then ¹ a must be true.”
Agent Program. Each agent has a set of rules called the agent program specifying the principles under which the agent is operating. These rules specify, using deontic modalities, what the
agent may do, must do, may not do, etc. Expressions O « (6t ) , P « (6t ) , F « (6t ) , Do «¬(6t ) , and W « (6t ) ,
where « ( t ) is an action atom, are called action status atoms. These action status atoms are read
(respectively) as « ( t ) is obligatory, permitted, forbidden, done, and the obligation to do « ( t ) is
waived. If A is an action status atom, then A and ! A are called action status literals. An agent
6
For simplicity, we omit here and in other places safety aspects (see [72, 192] for details).
82
program º
is a finite set of rules of the form:
A»
¹¼
L -`¼¾½X½X½?¼ Ln
(3.5)
where A is an action status atom, ¹ is a code call condition, and L -8777] Ln are action status
literals.
3.5.3.1
Semantics
If an agent’s behavior is defined by a program º , the question that the agent must answer, over
and over again is:
What is the set of all action status atoms of the form Do « ( t ) that are true with respect
to º , the current state ª and the set ¸ C of underlying integrity constraints on agent
states?
This set defines the action the agent must take; [72, 192] provide a series of successively more
refined semantics for action programs that answer this question, that we discuss in a very succinct
form.
Definition 1 (Status Set) A status set is any set S of ground action statusP atoms over the values
from the type domains of a software
package . For any operator Op P Do F O W T , we
P
«m Op (Y«±)¬ S T .
denote by Op ( S ) the set Op ( S )/
Definition 2 (Operator
App¿ À ( S ) ) Let º be an agent program and ª be an agent state. Then,
P
App¿ À ( S )r
Head ( r Á
) 7 r ÂºÃ R ( r 1Á´ S ) is true on ªÃT , where the predicate R ( r 1Á` S ) is
true iff (1) r Á:% A » ¹r¼ L -Ä¼Å½X½X½ ¼ Ln is a ground rule, (2) ª PÈ W¹ , (3) if Li Op (F«±) then
777] n T .
Op (Y«±)¬ S, and (4) if Li Æ! Op (Y«4) then Op (F«±)U Ç S, for all i
Definition 3 (A-Cl ( S ) )È A status set S is deontic and action
closed, if for every ground action « ,
È
it is the case that ( DC ) O «m S implies P «m S, ( AC ) O «m S implies Do «m S, and ( AC Éw)
Do «Ê S implies P «Ë S.
For any
status set S, we denote by A-Cl ( S ) the smallest set S,±Ì
È
( AC ) and ( AC É
) , i.e., action closed.
S such that S, is closed under
Definition 4 (Feasible Status Set) Let º be an agentÈ program and let ª be an agent state. Then,
a status set S is a feasible status set for º on ª , if ( S ) - ( S Í) hold:
È
(S )
7
App¿ À ( S )¬Î S;
Head Ï A ÐÂÑaÒ L ÓwÒÕÔ.ÔSÔLÒ Ln Ö?×
A
83
( S É
)
For any ground action « , the following holds: O «Ø
implies F «Æ Ç S.
( S Ú)
S
S implies W «Ù Ç S, and P «Ø
S
A-Cl ( S ) , i.e., S is action closed;
( S Í) The state ª,£
conc ( Do ( S )88ªs) which results from ª after executing (according to some
execution strategy conc) the actions in Do ( S ) satisfies the integrity constraints, i.e., ªo,4 ¸/Û .
Definition 5 (Groundedness; Rational Status Set) A statusÈ set S is grounded, if no status set
S,g S exists such that S ,IÎ S and S, satisfies conditions ( S ) – ( S Ú) of a feasible status set. A
status set S is a rational status set, if S is a feasible status set and S is grounded.
Definition 6 (Reasonable Status Set) Let º
let S be a status set.
be an agent program, let ª
be an agent state, and
1. If º is positive, i.e., no negated action status atoms occur in it, then S is a reasonable status
set for º on ª , iff S is a rational status set for º on ª .
2. The reduct of º w.r.t. S and ª , denoted by redS (|ºÃJªs) , is the program which is obtained
from the ground instances of the rules in º over ª as follows.
(a) Remove every rule r such that Op (F«±)¬ S for some ! Op (F«±) in the body of r;
(b) remove all negative literals ! Op (F«±) from the remaining rules.
Then S is a reasonable status set for º w.r.t. ª , if it is a reasonable status set of the program
redS (Üº¶JªÝ) with respect to ª .
3.5.3.2
Implementation
The implementation of the IMPACT agent program consists of two major parts, both implemented in Java:
1. the IMPACT Agent Development Environment (IADE for short) which is used by the
developer to build and compile agents, and
2. the run-time part that allows the agent to autonomously update its reasonable status set and
execute actions as its state changes.
The IADE provides a network accessible interface through which an agent developer can specify
the data types, functions, actions, integrity constraints, notion of concurrency and agent program
associated with her agent; it also provides support for compilation and testing.
84
The runtime execution module runs as a background applet and performs the following steps: (i)
monitoring of the agent’s message box, (ii) execution of the algorithm for updating the reasonable
status set and (iii) execution of the actions « such that O « is in the updated reasonable status set.
3.5.3.3
Example
We may suppose that the IMPACT program for the seller agent accesses three software packages:
an oracle database where information on the stored amount of stuff and its minimum and
maximum price is maintained in a stored stuff relation;
a msgbox package that allows agents to exchange messages, as described in Section 3 of
[72]; in particular, it provides the getMessage(Sender) function which allows all tuples
coming from Sender to be read and deleted from the message box of the receiving agent;
and
a mathematical package math providing mathematical functions.
Initial state:
The stored stuff relation initially contains the tuple
l
orange, 1000, 1, 2 n
Actions:
ship(Buyer, Stuff, Req amount)
Pre(ship(Buyer, Stuff, Req amount)) =
in(Old amount, oracle:select(stored stuff.amount, name, =, Stuff)) in(Difference, math:subtract(Old amount, Req amount)) Difference 0
Add(ship(Buyer, Stuff, Req amount)) =
in(Difference, oracle:select(stored stuff.amount, name, =, Stuff))
Del(ship(Buyer, Stuff, Req amount)) =
in(Old amount, oracle:select(stored stuff.amount, name, =, Stuff))
In order for the agent to ship stuff, there must be enough stuff available (precondition
of the action). The effect of shipping is that the amount of available stuff is updated.
We do not provide here the code which realizes this action; we may think that this
code issues an order to physically ship the stuff.
85
sendMessage(Sender, Receiver, Message)
This action accesses the msgbox package putting a tuple in the agent message box.
The msgbox package underlying this action is assumed to ensure that tuples put in the
message box are then delivered to the receiver agent. The precondition of this action
is empty (it is always possible to send a message), the add and delete lists consist in
the updates of the receiver’s mailbox.
The notion of concurrency we adopt is weak concurrent execution. Even if some
problems arise with this kind of concurrency, it has the advantage that deciding
whether a set of actions is weak-concurrent executable is polynomial. As for the
other kinds of executability, deciding whether a set of actions is executable is at least
NP-complete (Theorem 3.1 of [72]).
Integrity constratins:
in(Min, oracle:select(stored stuff.min, name, =, Stuff)) in(Max, oracle:select(stored stuff.max, name, =, Stuff)) 2
l
l
0 Min Max
This integrity constraint says that the minimum price allowed for any stuff must be
greater than zero and lower than the maximum price.
in(Amount, oracle:select(stored stuff.amount, name, =, Stuff)) 2
Amount n 0
This integrity constraint says that the amount of any stuff cannot be lower than zero.
Agent Program:
Do sendMessage(Seller,
Buyer, accept(Stuff, Req amount, Price)) »

in( i, Buyer, Seller, contractProposal(Stuff, Req amount, Price), T j 8 ,
msgbox:getMessage(Sender)),
in(Max, oracle:select(stored stuff.max, name, =, Stuff)),
in(Amount, oracle:select(stored stuff.amount, name, =, Stuff)),
Price nK Max, Amount nK Req amount
This rule says that if all the conditions for accepting a proposal are met (there is enough
stuff in the department store and the proposed price is greater than the Max value), then
the seller send a message to the buyer, saying that it accepts the proposal.
O ship(Buyer, Stuff, Req amount) »
Do sendMessage(Seller, Buyer, accept(Stuff, Req amount, Price))
This rule says that if the seller agent accepts the buyer’s proposal by sending a message to
it, it is then obliged to ship the stuff.
8
The first element of the tuple says that the message is an input message (“i”); the last element is the time.
86
Buyer, refuse(Stuff, Req amount, Price)) »

in( i, Buyer, Seller, contractProposal(Stuff, Req amount, Price), T j ,
in(Min, oracle:select(stored stuff.max, name, =, Stuff)),
l
Price Min
If the price proposed by the buyer is below the Min threshold, then the seller agent refuses
the proposal.
Buyer, refuse(Stuff, Req amount, Price)) »

l
Amount Req amount
The proposal is refused even if there is not enough stuff available.
Buyer, contractProposal(Stuff, Req amount, Means)) »

in(Max, oracle:select(stored stuff.max, name, =, Stuff)),
in(Min, oracle:select(stored stuff.min, name, =, Stuff)),
l
Price n Min, Price Max, Amount n Req amount
in(Means, math:evalMeans(Max, Price))
This rule manages the case the seller agent has to send a contractProposal back to the
buyer, since the proposed price is in between Min and Max and there is enough stuff available.
3.6
Dynamic logic
Our introduction to dynamic logic is based on Section 8.2.5 of [198]. Dynamic logic can be
thought of as the modal logic of action. Unlike traditional modal logics, the necessity and possibility operators of dynamic logic are based upon the kinds of actions available. As a consequence
of this flexibility, it has found use in a number of areas of DAI. We consider the propositional
dynamic logic of regular programs, which is the most common variant. This logic has a sublanguage based on regular expressions for defining action expressions – these composite actions
correspond to Algol-60 programs, hence the name of regular programs.
Let PA be a set of atomic action symbols and p be a propositional formula. The language of
dynamic logic contains all atomic action symbols in PA and, if a and b are formulae in the
dynamic logic language, then also the following are formulae in the language:
87
a H b, meaning doing a and b in sequence;
(aÞ
a , meaning repeating zero or more (but finitely many) iterations of a;
p C , which is an action based on confirming the truth value of proposition p;
; a= p, which means that action a can be executed in all the worlds reacheable from the
current one;

b ) , meaning doing either a or b, whichever works;
a j p, which means that action a can be executed in at least one world reacheable from the
current one.
( a Þ b ) is nondeterministic choice. Although it might sound a little unintuitive, it is logically
clean, even if a nondeterministic program may not be physically executable, because it can require arbitrary lookahead to infer which branch is really taken. As far as p C is concerned, if p is
true, this action succeeds as a noop, i.e. without affecting the state of the world. If p is false, it
fails, and the branch of the action of which it is part is terminated in the failure – it is as if the
branch did not exist.
The semantics of dynamic logic is given with respect to a model that includes a set of states (or
worlds) S, that we indicate with the symbols r, s and t (with subscripts when necessary), related
by possible transitions based on the actions in PA. Let h be the interpretation
P
h % S & PROP '
true false T
which says if a propositional formula belonging to PROP is true or false in a world. Let ßÎ
S & PA & S be a transition relation.
In order to provide the semantics of the language we first define a class of accessibility relations:
s Rà t
s Ra â b t
s Ra ã b t
s Ra t
iff
iff
iff
iff
O
ß3( s <áa t )
exists r such that s Ra r and r Rb t
s Ra t or s Rb t
there exists s$7779 sn such that s s$ and t l
for all i 1äÝ i n si Ra si ã -
sn and

We can now provide the semantics of ; a= p and a j p:

S Rß£ h jK S Rß£ h K
j
s
s
aj p
; a= p
iff
iff

there exists t such that s Ra t and S Rß[ h jK for all t, s Ra t implies S Rß£ h jK t p
88
t
p
3.6.1
Dylog
In a set of papers [96, 97, 14, 15, 17], M. Baldoni, L. Giordano, A. Martelli, V. Patti and
C. Schwind describe an action language and its extension to deal with complex actions. In
this section we provide a short description of the language, taken from [16], and we introduce an
implementation of the language called Dylog.
Primitive actions. In the action language each primitive action a A is represented by a
modality ; a= . The meaning
of the formula ; a=6« is that « holds after any execution of a. The

meaning of the formula a j.« is that there is a possible execution of action a after which « holds.
There is also a modality which is used to denote those formulae holding in all states. A state
consists in a set of fluents representing the agent’s knowledge in that state. They are called fluents
because their value may change from state to state. The simple action laws are rules that allow
to describe direct action laws, precondition laws and causal laws.
Action laws define direct effect of primitive actions on a fluent and allow actions with conditional
effects to be represented. They have the form
å
( Fs ' ; a = F )
where a is a primitive action name, F is a fluent, and Fs is a fluent conjunction, meaning that
action a has effect on F, when executed in a state where the fluent precondition Fs holds.
Precondition laws allow action preconditions, i.e. those conditions which make an action exeå
cutable in a state, to be specified. Precondition
laws
have form

( Fs '
a j true )
meaning that when a fluent conjunction Fs holds in a state, execution of the action a is possible
in that state.
Causal laws are used to express causal dependencies among fluents and, then, to describe indirect
effects of primitive actions. They have the å form
( Fs ' F )
meaning that the fluent F holds if the fluent conjunction Fs holds too.
In the implementation language Dylog the notation is more readable: action laws have the form
a causes F if Fs, precondition laws have the form a possible if Fs and causal laws have the form
F if Fs.
Procedures. Procedures define the behavior of complex actions which are defined on the basis
of other complex actions, primitive actions and test actions. These ones are needed for testing if
some fluent holds in the current state and for expressing conditional complex actions. They are
written as
89
Fs C
where Fs is a fluent conjunction.
of action schemas
of the form
Procedure p$ can be regarded as a collection

p -.j p0"j]777 pn jRæ2
p$"j<
These axioms have the form of rewriting rules as in grammar logics. In Dylog a procedure is
defined as a collection of procedure clauses of the form
p$ is p - , 777 , pn ( n ¢ä)
È
where p$ is the name of the procedure and pi , i 777 n is either a primitive action, or a test
action, a procedure name, or a Prolog goal. Procedures can be recursive and they are executed
in a goal directed way, similarly to standard logic programs.
Planning. A planning problem amounts to determine, given an initial state and a goal Fs , if
there is a sequence of actions that, when executed in the initial state, leads to a state in which Fs
holds. This can be formulated by the query
p j Fs
which asks for a terminating execution of p (i.e. a finite action sequence) leading to a state
where Fs holds. The execution of the above query returns as a side effect an answer which is an
execution trace a -" a 07779 am , i.e. a primitive action sequence from the initial state to the final
one, which represents a linear plan. To achieve this, Dylog provides a metapredicate
plan(p, Fs, as)
where p is a procedure, Fs a goal and as a sequence of primitive actions. The procedure p can be
nondeterministic, and plan will extract from it a sequence as of primitive actions, namely a plan.
Procedure plan works by executing p in the same way as the interpreted language, with a main
difference: primitive actions are executed without any effect on the external environment, and,
as a consequence, they are backtrackable.
Sensing. In general, it is not possible to assume that the value of each fluent in a state is known
to an agent, and it is necessary to represent the fact that some fluents are unknown and to reason
about the execution of actions on incomplete states. To represent explicitly the unknown value
of some fluents, an epistemic operator B is introduced in the language, to represent the beliefs
an agent has on the world. Bf will mean that the fluent f is known to be true, B ! f will mean that
the fluent f is known to be false, and fluent f is undefined in the case both ! Bf and ! B ! f hold.
In the following, u ( f ) stands for ! Bf ! B ! f .
In Dylog there is no explicit use of the operator B but the notation is extended with the test u(f)?.
Thus each fluent can have one of the three values: true, false and unknown. An agent will be
able to know the value of f by executing a sensing action of the form
90
s senses f
meaning that the action s causes to know whether f holds. By applying Dylog’s planning predicate plan to a procedure containing sensing actions a conditional plan is obtained. The branches
of this plan correspond to the different outcomes of sensing actions.
3.6.1.1
Semantics
As discussed in [15], the logical characterization of Dylog can be provided in two steps. First, a
multimodal logic interpretation of a dynamic domain description which describes the monotonic
part of the language is introduced. Then, an abductive semantics to account for non-monotonic
behavior of the language is provided.
Definition 7 (Dynamic domain description) Given a set ç of atomic world actions, a set of
sensing actions, and a set º of procedure names, let èé be a set of simple action clauses for
world actions, èê a set of axioms for sensing actions, and è¿ a set of inclusion axioms È of the
l
l
l
l
form p$_nÆëíì
p -n
p0gn7u7î7
pn nÂë where p$ is a procedure name and pi i 7î7u7u n
are either procedure names or atomic actions or test actions. A dynamic domain description is
a pair (Yè+ S$") , where è is the tuple (YèvéIRèê£1è¿9) and S$ is a consistent and complete set of
epistemic literals representing the beliefs of the agent in the initial state.
Monotonic interpretation of a dynamic domain description. Given a dynamic domain description (Fèo S $1) , let us call Nï¨ Sðñ the propositional modal logic on which (Yè+ S$") is based. The
action laws for primitive actions in èé and the initial beliefs in S$ define a theory fragment
ò
Nï¨ Sðó in hï? Sð> . The axiomatization of Nï¨ Sðñ , called hï? Sðó , contains:
all the axioms for normal modal operators
D (Fô ) , namely, for ô the axiom p 2
S Í?(SD) , namely, the three axioms p 2
;bI=6ë2
l
l
l
èv¿ ;
èvê .
p holds;
p, _( p 2
q )32
(. p 2
; a -ó=Üë , one for each primitive action ai in (Fèo S $1) ;
l
a Þ b nõëp@
a nöë[B
l
b n÷ë , one for each formula ë ;
Conõëe@Âøùë , one for each formula ë ;
a H b nöëe@
l
an
l
b nöë , one for each formula ë ;
91
q ) and p 2
g p;
The model theoretic semantics of the logic Nï¨ Sð is given through a standard Kripke semantics
with inclusion properties among the accessibility relations. More details can be found in [13].
Abductive semantics. The monotonic part of the language does not account for persistency.
In order to deal with the frame problem, it is necessary to introduce a non-monotonic semantics
for the language by making use of an abductive construction: abductive assumptions will be used
to model persistency from one state to the following one, when a primitive action is performed.
In particular, we will assume that a fluent expression F persists through an action unless it is
inconsistent to assume so, i.e. unless ! F holds after the action.
In defining the abductive semantics, the authors adopt (in a modal setting) the style of K. Eshghi
and R. Kowalski’s abductive semantics for negation as failure [76]. They define a new set of
atomic propositions of the form M ; a -ó=ñ; a0<=Z7u7u76; am = F and take them as being abducibles. Their
meaning is that the fluent expression F can be assumed to hold in the state obtained by executing
primitive actions a -" a07î7u7î am . Each abducible can be assumed to hold, provided it is consistent
with the domain description (Yè+ S$") and with other assumed abducibles.
More precisely, in order to deal with the frame problem, they add to the axiom system of U(Fèo S $1)
the persistency axiom schema
; a ->=ñ; a0R=Z7u7î7x; am ->= F M ; a -ó=ñ; a 0<=Y7u7î7x; am -ó=>; am = F 2 ; a -ó=ñ; a 0<=Y7u7î7x; am -ó=>; am = F
where a -" a07u7î7u7î am ( m nØä) are primitive actions, and F is a fluent expression. Its meaning is
that, if F holds after action sequence a -" a07î7u7î am - , and F can be assumed to persist after action
am (i.e., it is consistent to assume M ; a ->=ñ; a 0R=Y7u7î7x; am = F), then we can conclude that F holds after
performing the sequence of actions a -" a 07î7u7u am .
Besides the persistency action schema, the authors provide the notions of abductive solutions for
a dynamic domain description and abductive solutions to a query.
3.6.1.2
Implementation
A logic programming fragment of the language we have discussed so far is defined by a proof
procedure which constructs a linear plan by making assumptions on the possible results of sensing actions. Dylog is actually this logic programming language. The goal directed proof procedure, based on negation as failure, allows a query to be proved from a given dynamic domain
description. The proof procedure is sound and complete with respect to the Kripke semantics of
the modal logics _(Yèo S$") . An interpreter based on this proof procedure has been implemented
in SICStus Prolog. This implementation allows to use Dylog as a programming language for
executing procedures which model the behavior of an agent, but also to reason about them, by
extracting from them linear or conditional plans. Details on the implementation can be found at
the address: http://www.di.unito.it/˜alice/download.html.
92
3.6.1.3
Example
In the following example, the predicate is has its usual meaning in Prolog programs: it allows
to evaluate the value of the expression at its right and checks if this value unifies with the term at
its left. The Dylog’s symbol is for defining procedures is substituted with isp. This is the choice
that Dylog’s developers made in the SICStus Prolog implementation of the language.
Functional fluents:
functionalFluent(storing/2) 9.
functionalFluent(new message/2).
The amount of stuff stored and the new incoming messages are facts which change
during the agent’s life.
Unchangeable knowledge base (Prolog facts):
min-price(orange, 1).
max-price(orange, 2).
The minimum and maximum prices for oranges do not change over time.
Initial observations:
obs(storing(orange, 1000)).
Initially, there are 1000 oranges the seller agent can sell.
Primitive actions:
receive
This action senses if a fluent new message(Sender, Message) is present in the callers’s
mailbox. It is characterized by the following laws and routines10:
Precondition laws:
receive possible if true.
It is always possible to wait for a new message to arrive.
Sensing:
receive senses new message(Sender, Message).
The receive action senses the value of the new message(Sender, Message) functional fluent.
9
The number after the predicate’s name is its arity.
We are basing our communication primitives on those described within the virtual seller agent example, in the
Appendix of [164].
10
93
Sensing routine:
senses routine( , new message, Sender, Message) :- ....
A Prolog routine that we do not show here implements the sensing action by
waiting for messages matching the couple (Sender, Message) in the caller’s mailbox.
This action puts the couple (Sender, Message) in the Receiver’s mailbox by modifying
the state of the new message(Sender, Message) functional fluent of the Receiver’s
agent. For sake of conciseness, we avoid discussing all the details of this action.
ship(Buyer,Stuff, Req Amnt, Price)
This action ships the required stuff to the Buyer agent. It is characterized by the
following action laws and precondition laws:
Action laws:
ship(Buyer, Stuff, Req Amnt, Price)
causes storing(Stuff, Amount)
if ?storing(Stuff, Old Amount) &
(Amount is Old Amount - Req Amnt).
Shipping some stuff causes an update of the stored amount of that stuff.
Precondition laws:
ship(Buyer, Stuff, Req Amnt)
possible if ?storing(Stuff, Old Amount) &
(Old Amount nK Req Amnt).
Shipping stuff is possible if there is enough stuff left.
ship(Buyer, Stuff, Req Amnt)
possible if max-price(Stuff, Max) & (Price nK Max).
Shipping stuff is possible if the price is higher than the maximum price established for that stuff.
Procedures:
seller agent cycle isp
receive &
manage message &
seller agent cycle.
The main cycle for the seller agent consists in waiting for a message, managing it and
starting waiting for a message again.
manage message isp
?new message(Buyer, contractProposal(Stuff, Req Amnt, Price)) &
?storing(Stuff, Old Amount) &
(Old Amount nK Req Amnt) &
94
max-price(Stuff, Max) & (Price nK Max) &
ship(Buyer, Stuff, Req Amnt, Price) &
send(seller, Buyer, accept(Stuff, Req Amnt, Price))
If all conditions are met to ship the stuff, then the stuff is shipped and the seller sends
a message to the Buyer in which it accepts the Buyer’s proposal.
manage message isp
l
(Old Amount Req Amnt) &
send(seller, Buyer, refuse(Stuff, Req Amnt, Price))
If there is not enough stuff, the seller agent refuses to send the stuff.
manage message isp
l
min-price(Stuff, Min) & (Price Min)
send(seller, Buyer, refuse(Stuff, Req Amnt, Price))
If the price is too low, the seller agent refuses to send the stuff.
manage message isp
(Old Amount nK Req Amnt) &
l
max-price(Stuff, Max) & (Price Max) &
min-price(Stuff, Min) & (Price n Min) &
(New Price is (Price + Max) / 2) &
send(seller, Buyer, contractProposal(Stuff, Req Amnt, New Price))
In case the conditions are met to send a counter proposal to the Buyer agent, the seller
sends it with the price it is willing to accept.
3.7
Temporal logic
In this section we define a first-order temporal logic based on discrete, linear models with finite
past and infinite future, called FML [82]. FML introduces two new connectives, ‘until’ (ú ) and
‘since’ ( ), together with a number of other operators definable in terms of ú and , to classical
logic.
Syntax of FML. Well-formed formulae of FML (WFFf ) are generated in the usual way as for
classical logic, starting from a set p of predicate symbols, a set v of variable symbols, a set c
of constant symbols, the quantifiers 5 and # , and the set t of terms (constants and variables).
The set WFFf is defined by:
95
If t -17î7u7u tn are in t
and p is a predicate symbol of arity n, then p ( t -"7u7î7u tn ) is in WFFf .
If A and B are in WFFf , then so are true, false, ! A, A B, A ú B, A B, and ( A ) .
If A is in WFFf and v is in v,
then # v 7 A and 5 v 7 A are both in WFFf .
The other classical connectives are defined in terms of the ones given above, and several other
useful temporal connectives are defined in terms of ú and :
û
ë
ý
û
ë
ë
3ë
ë
þ
Dë
ë
ü is true in the next state
there was a last state, and ü was true in the last state
if there was a last state, then ü was true in that state
ü will be true in some future state
ü was true in some past state
ü will be true in all future states
ü was true in all past states
[false úoë ]
[false ë ]
ý
[!
!3ë ]
[true úoë ]
[true ë ]
[ !øa!3ë ]
[ !3 !3ë ]
Temporal formulae can be classified as follows. A state-formula is either a literal or a boolean
combination of other state-formulae.
Strict future-time formulae are defined as follows:
If A and B are either state or strict future-time formulae, then A ú B is a strict future-time
formula.
If A and B are strict future-time formulae, then ! A, A B, and ( A ) are strict future-time
formulae.
Strict past-time formulae are defined as the past-time duals of strict future-time formulae.
Non-strict classes of formulae include state-formulae in their definition.
Semantics of FML. The models for FML formulae are given by a structure which consists of a
sequence of states, together with an assignment of truth values to atomic sentences within states,
a domain V which is assumed to be constant for every state, and mappings from elements of the
ÿ(Fß£<Vp hc hp ) where ß is the
language to denotations. More formally, a model is a tuple ordered setP of states s$X s -1 s07u7î7 , hc is a map from the constants to V , and hp is a map from N &g p
to V n '
T, F T (the first argument of hp is the index i of the state si ). Thus, for a particular
state s, and a particular predicate p of arity n, h ( s p ) gives truth values to atoms constructed from
n-tuples of elements of V . A variable assignment hv is a mapping from the variables to elements
of V . Given a variable and the valuation function hc , a term assignment vh is a mapping from
terms to V defined in the usual way.
96
The semantics of FML is given by the relation that gives the truth value of a formula in a
model at a particular moment in time i and with respect to a variable assignment.

3.7.1
i
i
i
i
i
i
hv j true
hv j_ false
hv j p ( x -"7î7u7î xn )
hv j Â!aë
hv j ÂërBt
hv j Âë+úU
iff
iff
iff
iff
i hv j ÂëÝI
iff
i hv j ÷5 x 7Në
i hv
j Â# x N7 ë
iff
iff
h p ( i p )( vh ( x -S)87u7î7u vh ( xn ).)/ T
i hv j+Æë

i hv j_ Æë or i hv j_ ö

l
k hv j Æ
for some k such that i k,

l
l
j hv j ë
and for all j, if i j k then

l
for some k such that äs k i, k hv j Æ
l
l
and for all j, if k j i then j hv j ë
for all d Vp i hv ; d Ç x=Üjg
Âë

there exists d V such that i hv ; d Ç x=6j_ Æë
Concurrent METATEM
Concurrent METATEM [84, 83, 86] is a programming language for distributed artificial intelligence based on a linear discrete model of time modeled as an infinite sequence of discrete states
which start at the “beginning of time”. A Concurrent METATEM system contains a number of
concurrently executing agents which are able to communicate through message passing. Each
agent executes a first-order temporal logic specification of its desired behavior. Each agent has
two main components:
an interface which defines how the agent may interact with its environment (i.e., other
agents);
a computational engine, which defines how the agent may act.
An agent interface consists of three components:
a unique agent identifier which names the agent
a set of predicates defining what messages will be accepted by the agent – they are called
environment predicates;
a set of predicates defining messages that the agent may send – these are called component
predicates.
97
Besides environment and component predicates, and agent has a set of internal predicates with
no external effect.
The computational engine of an object is based on the METATEM paradigm of executable temporal logics. The idea behind this approach is to directly executing a declarative agent specification
given as a set of program rules which are temporal logic formulae of the form:
antecedent about past 2 consequent about future
The past-time antecedent is a temporal logic formula referring strictly to the past, whereas the
future time consequent is a temporal logic formula referring either to the present or future. The
intuitive interpretation of such a rule is on the basis of the past, do the future. The individual
METATEM rules are given in the FML logic defined before11 .
3.7.1.1
Semantics
METATEM semantics is the one defined for FML.
3.7.1.2
Implementation
Two implementations of the imperative future paradigm described in this section have been produced. The first is a prototype interpreter for propositional METATEM implemented in Scheme
[81]. A more robust Prolog-based interpreter for a restricted first-order version of METATEM
has been used as a transaction programming language for temporal databases [80]. A reimplementation effort is currently under way, with the aims of developing a small, fast interpreter
upon which simple experiments can be carried out, and developing a compilation based system
providing both improved performance and the opportunity to utilize parallel architectures.
In this section we sketch the interpreter for propositional METATEM. The interpreter for firstorder METATEM is similar but takes into account bindings for variables. The core of the interpreter is a procedure which takes three arguments: a set of rules (i.e. the program) to be run,
a set of states already executed (the history), and a set of commitments. This last argument is
the means by which monotonic changes to the future are effected. The procedure performs the
following steps:
1. The antecedent of each rule is checked against the history, and the consequents of those
rules whose antecedents are satisfied are gathered into a set.
2. The conjunction of the consequents and commitments gives the formula whose truth must
11
Since METATEM rules must respect the past implies future form, FML formulae defining agent rules must be
transformed into this form. This is always possible as demonstrated in [19].
98
be ensured. This formula is rewritten to a normal form given by
n
- i mi
ji - ( pji ù! qji )9
û
ë
i
Here, pji and qji are propositions, and ë
ji
is an (optional) non-strict future-time formula.
3. One of the disjuncts must be forced true according to the strategy in use, for i a, say.
4. A new state is constructed from the
ma
ja - ( pja ù! qja )
and the values of the environment atoms in the new state. A new set of commitments is
given by ë a .
5. The core procedure is called recursively, with the program, the new commitments, and the
old history augmented with the newly constructed states.
3.7.1.3
Example
The interface of the seller agent is the following:
seller(contractProposal)[accept, refuse, contractProposal, ship]
meaning that the seller agent, identified by the seller identifier, is able to recognize a
contractProposal message with its arguments, not specified in the interface, and the
messages it is able to broadcast to the environment12 are accept, refuse, contractProposal, ship, with their arguments.
The internal knowledge base of the seller agent contains the following rigid predicates
(predicates whose value never changes):
The internal knowledge base of the seller agent contains the following flexible predicates
(predicates whose value changes over time):
storing(orange, 1000).
12
The program rules of the seller agent are the following ones (as usual, lowercase symbols
are constants and uppercase ones are variables):
These messages include both communicative acts and actions which modify the environment.
99
5 Buyer. 5 Stuff. 5 Req Amnt. 5 Price.
ý
[contractProposal(Buyer, seller, Stuff, Req Amnt, Price) storing(Stuff, Old Amount) Old Amount n Req Amnt max-price(Stuff, Max) Price nK Max] 2
[ship(Buyer, Stuff, Req Amnt, Price) accept(seller, Buyer, Stuff, Req Amnt, Price)]
If there exists a previous state where a Buyer sent a contractProposal message to
seller, and in that previous state all the conditions are met to accept the Buyer’s
proposal and ship the required stuff, then in the current state these actions (shipping
and accepting) are performed.
ý
[contractProposal(Buyer, seller, Stuff, Req Amnt, Price) storing(Stuff, Old Amount) min-price(Stuff, Min) l
l
Old Amount Req Amnt B Price Min] 2
[refuse(seller, Buyer, Stuff, Req Amnt, Price)]
seller, and in that previous state the conditions are not met to accept the Buyer’s
proposal, then in the current state a refuse message, addressed to the Buyer agent, is
sent.
ý
[contractProposal(Buyer, seller, Stuff, Req Amnt, Price) storing(Stuff, Old Amount) min-price(Stuff, Min) max-price(Stuff, Max) Old Amount n Req Amnt l
Price n Min Price Max New Price (Max + Price) / 2] 2
[contractProposal(seller, Buyer, Stuff, Req Amnt, New Price)]
seller, and in that previous state the conditions are met to send a contractProposal
back to the Buyer agent, with a new proposed price, then in the current state a contractProposal message, addressed to the Buyer agent, is sent.
3.8
Linear logic
This introduction to linear logic is based on [98] by Y. Girard.
100
Linear logic is an extension of usual logic with new connectives:
Exponentials: “!” (of course) and “?” (why not?) express the iterability of an action, i.e.
the absence of any reaction. A means infinite amount of resource A.
Linear implication: – (lolli) is used for causal implication. The relationship between
@ ( A ) – B
linear implication and intuitionistic implication “ 2 ” is A 2 B ^
Conjunctions: (times) and ¼ (with) correspond to radically different uses of the word
“and”. Both conjunctions express the availability of two actions; but in the case of , both
actions will be done, whereas in the case of ¼ only one of them will be performed (we shall
decide which one). Given an action of type A – B and an action of type A – C there will be
no way of forming an action of type A – B C, since once resource A has been consumed
for deriving B, for example, it will be no more available for deriving C. However, there
will be an action A – B ¼ C. In order to perform this action we have to first choose which
among the two possible actions we want to perform, and then do the one selected. This is
an exact analogue of the computer instruction if 777 then 777 else.
Disjunctions: there are two disjunctions in linear logic, (plus), which is the dual of ¼ ,
and , which is the dual of . expresses the choice of one action between two possible
types; in terms of computer science the distinction ¼+Ç corresponds to the distinction
outer/inner determinism. expresses a dependency between two types of actions. is the
symmetric form of – ; in some sense, it is the constructive contents of classical disjunction.
Linear negation: the most important linear connective is linear negation (ó½\) (nil). Since
linear implication will eventually be rewritten as A B, nil is the only negative operation
of logic. Linear negation expresses a duality
action of type A = reaction of type A Neutral elements: there are four neutral elements: 1 (w.r.t.
and 0 (w.r.t. ).
),
(w.r.t.
),
(w.r.t. ¼ )
States and transitions. If we want to represent states and transitions in classical logic, we
have to introduce an extraneous temporal parameter and the formalization
will explain how to
È
pass from state S, modeled as ( S t ) , to a new state S, modeled as ( S,6 t Þ ) . This is very awkward,
and it would be preferable to ignore this ad hoc parameter. In fact, one would like to represent
states by formulae and transitions by means of implications of states, in such a way that S, is
accessible from S exactly when S – S , is provable from the transitions, taken as axioms. But,
in usual logic, the phenomenon of updating cannot be represented. For example, the chemical
equation
É H 0 Þ O0¬' É H0 O
101
can be paraphrased in current language as
H0 and H0 and O0 imply H0 O and H0 O
but this sentence cannot be represented in classical logic because once the starting state has been
used to produce the final one, it cannot be reused. The features which are needed here are “ ”
to represent “and” and “ – ” to represent “imply”. A correct representation will therefore be
H0
H0
O0 – H0 O H0 O
The notion of linear consequence will correspond to the notion of accessible state from an initial
one. States and updates are easily represented in linear logic because certain information can be
erased. What makes it possible is the distinction between formulae A that speak of stable facts
and ordinary ones, that speak about the current state.
Semantics. We limit ourselves to describing the phase semantics of linear logic. It is the
most traditional semantics, but also the less interesting one. For an complete description of
denotational semantics and game semantics the reader is referred to [98] and [26] respectively.
A phase space is a pair ( M o) , where M is a commutative monoid and is a subset of M. Given
two subsets X and Y of M, one can define
P
lolli: X – Y %N
m M such that 5 n X mn Y T
In particular, it is possible to define for each subset X of M its orthogonal X %h X – . A
fact is any subset of M equal to its biorthogonal, or equivalently any subset of the form Y . It is
immediate that X – Y is a fact as soon as Y is a fact.
The operations of linear logic are interpreted as operations on facts: once this is done, the interpretation of the language is more or less immediate.
times: X
par: X
one: 1 %h
plus: X
P
Y %h
Y %h
PÈ
mn such that m X n Y T
( X T
È
where is the neutral element of M
Y %h{( X
with: X ¼ Y %h
zero: 0 %hÂä
Y 9)
X
Y )
Y
13
13
Usually corresponds to the “minimum fact”. Its concrete definition depends on the chosen phase model; for
example, if we take the monoid of integers (Z with addition) as M, and we define as , then corresponds to
the set x such that for each y Z ! x " y × # , namely the empty set.
102
true:
%N
M
of course: X %h
(X
I)
where I is the set of idempotents of M belonging to 1
why not: C X %N{( X I )$
3.8.1
Ehhf
The language % hhf [62, 63] is an executable specification language for modeling concurrent and
resource sensitive systems, based on the general purpose specification logical language Forum
[150]. % hhf is a multiset-based logic combining features of extensions of logic programming
languages like & Prolog, e.g. goals with implication and universal quantification, with the notion
of formulae as resources at the basis of linear logic. A % hhf -program P is a collection of multiconclusion clauses of the form:
A ')( (( (( (((+
( (( ( ( ( ( ( *,*-*
( ((
((
(( ((
( ( (( (( (( ( ( (( (
An
Goal 0
./
( ( ( (( ( ( ( *-*-* ( ( ( (( ( ( ( (( ( ( (( An corresponds to the
where the Ai are atomic formulae, and the linear disjunction A '1( ( ( ( ( ((2
(( ( ( (
(( ( ( (
head of the clause and Goal is its body. Furthermore, A ./ B is a linear implication. Clauses of
this kind consume the resources (formulae) they need in order to be applied in a resolution step.
Given a multiset of atomic formulae (the state of the computation) 354 , a resolution step 35476 38'
can be performed by applying an instance A ' ( (( (( ((( ((( ( ( (( ( ( *,*-* (( (( (( ((( ( ( (( ( ( An .9/ G of a clause in the program
(
(
P, whenever the multiset : consisting of the atoms A '0 *,*-* 0 An is contained in 354 . 38' is then
obtained by removing : from 354 and by adding G to the resulting multiset. In the % hhf interpreter,
instantiation is replaced by unification. At this point, since G may be a complex formula, the
search rules (i.e., the logical rules of the connectives occurring in G) must be exhaustively applied
in order to proceed. Such a derivation corresponds to a branch of the proof tree of the multiset 3 .
represents the current global state, whereas P describes a set of clauses that can be triggered
3
at any point during a computation.
% hhf
provides a way to “guard” the application of a given clause. In the extended type of clauses
G '<;
*-*-* ;
Gm
=
>
A'
( ( ( (( ( ( ( (( ( ( ( *-*-* ( ( ( (( ( ( (( ( ( ( ( (
((((
( ( ( ((
An
.9/
Goal ?@0
the goal-formulae Gi are conditions that must be solved in order for the clause to be triggered.
New components can be added to the current state by using goal-formulae of the form G ' ( (( (( ((( (( ( (( (( ( ( ( GA .
(
In fact, the goal G 'B( ( ( ( (( ( ((( (( (((( (( GA,0DC simply reduces to G 'D0 GA,0DC . Conditions over the current state can
(
be tested by using goal-formulae of the form G '$; GA . In fact, the goal G '9; GA#0DC reduces to
G '0DC and GA#0DC . Thus, one of the two copies of the state can be consumed to verify a contextual
condition. Universal quantification in a goal-formula E x * G can be used to create a new identifier t
which must be local to the derivation tree of the subgoal G F t G xH . Finally, the constant I succeeds
in any context and the constant J is simply removed from the current goal.
103
3.8.1.1
Semantics
The % hhf operational semantics is given by means of a set of rules describing the way sequents
can be rewritten. According to the proof as computation interpretation of linear logic, sequents
represent the state of a computation.
Then sequents assume the following form:
KMLONQPSRT<UWVYX[Z ZM\^]
where _ and C are multi sets of ` -formulae, a is an b -formula, 3 is a multi set of c -formulae,
and : is a multi set of atomic formulae14 .
The rules of % hhf , defined in Table 3.1, are divided into right rules (or search rules) and left rules.
Right rules define the behavior of the various connectives: I is used to manage termination, J
to encode a null statement, ; to split a computation into two branches which share the same
resources, E to encode a notion of hiding, ( ( ( ( ( (( ( (( ((( ( ((( ( to represent concurrent execution, = and –. to
(
augment the resource context (respectively, the unbounded and the bounded context). The left
rules define backchaining over clauses built with the connectives d and ./ . The rule for .9/ is
similar to Prolog rewriting, except that multiple-headed clauses are supported; besides, a clause
can be reusable or not depending on which context it appears in. The rule for d allows to depart
an independent branch in an empty context (this is often useful to verify side conditions or make
auxiliary operations).
The rules bc, verify, empty can be applied if and only if the right-hand side consists of atomic
Vg
formulae, indicated by e ; in the rule move, f
is a set of atomic state formulae. The side
condition > i ? of the hide rule requires that y hji is not present in the signature k ; > ii ? requires
and p are empty, the
> _l0nm80D3o0Dp+? to be a multi-application resolvent for > _l0DCq0er0:s? (if m , 3
bc reduce to an axiom scheme); > iii ? requires kthOa^uY6 : to be provable in Forum. Finally,
G vxw D y , D vzC and then m|{ > C~}1 D ? E , or D v_ and then
> iv ? requires that E d
m{C E .
14
The class of formulae is restricted to two main classes, - and -formulas (D stands for definite clauses and G
for goals):

qZ

Z¡

¨

' ( ( ( ( ( (( ( (( (( ( (
( (( ( (
¨©¨

Z
A
Z¨
ZZ
x
( ( ( ( ( ( ( ( ( (( (( ((
(( ( (
Z
x
¢Z
–
G
Z
H
lZ£¤xZ
A
ZM¥¤Z§¦

Ar
( ( ( ( (( ( ( (( ( ( ( ((
(( (
¨ªZ
x
¨
Z§¥¤Z
Ar
A represents a generic atomic formula, whereas Ar is a rigid atomic formula, i.e., whose top-level functor symbol
is a constant. « -formulas are used to match the final result of a computation.
104
Search Rules
¬®^¯ °²µ´Q¶sº¼ ¼¾
halt
¬®8¯±°³²µ´¶s·¹¸»º½¼ ¼¾
¬®8¯±°²´
y À Á$Â
¶
¯
A yÃ x
¬®^¯±°²´¶8Å
xÆ A
Á
¶
¬®^¯ °²µ´
¸»º¼ ¼¾
AÊ
¶
¬®^¯ °²Î´
¬®^¯±°²µ´
¶
¸
A Ê AË
AÊ
( ( ( ( ( ( (( ((
(
AË
B
¶
sync
¶
¬®^¯±°²´
and
¶
A
¶
¶
¬®´
¶2Ô
B
A
¸Ïº¼ ¼¾
A
Ð
¸»º¼ ¼¾
¸Ïº¼ ¼¾
B –Ñ A
fire
¸»º½¼ ¼¾
Backchaining
¬Ò´
¶
¸»¬®^¯ °²µ´
¬®^¯±°²´
¸»®^¯ °²µ´
¸»ºÇ¼ ¼¾
AË
¸»º½¼ ¼¾
B
¸»º½¼ ¼¾
hide È i É
¸»ºÇ¼ ¼¾
A ÊÍÌ A Ë
¸»ºÇ¼ ¼¾
¬
²Ä¸»º½¼ ¼¾
¬®^¯±°²´
¬®^¯±°²´¶
erase
¬®^¯ °²´¶2¿¹¸»º½¼ ¼¾
Verify
º½¼ ¼Ó
¶
¬Õ¡¯±°²´
bc È ii É
¼ ¼¾
verify È iii É
ÕÖ¼ ¼¾
Move
×YØÙ
¶Ú
¶
¬®Û´
¬Ü®´
¶
º½¼ ¼ × ¸Ï¾
move
× ¸»ºÇ¼ ¼¾
Context Rule
¬Õ§¯±°ÝÞ²´Q¶
G
¼ ¼ÜÕ
¬®^¯ °²µ´
¬ÒO¯±°²´¶
¶2Ô
Table 3.1:
Ô
¼ ¼¾
¼ ¼¾
% hhf
proof system.
105
empty È iv É
augment
3.8.1.2
Implementation
A working interpreter for % hhf has been developed by M. Bozzano in Lambda Prolog, a language originally developed by D. Miller and G. Nadathur15 , which offers support for higherorder abstract syntax, a new and increasingly popular way to view the structure of objects such
as formulae and programs.
The code of the % hhf interpreter can be downloaded from ftp://ftp.disi.unige.it/
person/BozzanoM/Terzo/, where an example implementing the specification described
in [29] is also downloadable.
3.8.1.3
ß
Example
Seller’s initial facts:
storing(orange, 1000).
seller-mail-box([]).
We assume that every agent has a mail-box which all the agents in the system can
update by calling a send predicate. The mailbox of the seller agent is initially empty
(we are using Prolog syntax for lists: [] is the empty list, [H à T] is the list with H as
the head, and T as the tail). The reader interested in the definition of communication
primitives in % hhf can find more details in Chapter 5 of [11].
ß
Seller’s life cycle:
Message. E OtherMessages.
seller-mail-box([Message à OtherMessages]) ( ( ( (( (( (( (( (( ((( (
((
seller-cycle –.
manage(Message) ( ( ( (( ( ( ((( ( ((( ((
(
seller-mail-box(OtherMessages) (( (( ((( ( (((( ( (((( (
(
seller-cycle.
To satisfy the seller-cycle goal, the seller agent must have at least one message in its
mail-box. In this case, it consumes the seller-mail-box([Message à OtherMessages])
and seller-cycle goals and produces the new goals of managing the received message
(manage(Message)), removing it from the mail-box (seller-mail-box(OtherMessages),
where the list of messages does not contain Message any more) and cycling (sellercycle).
E
15
See http://teyjus.cs.umn.edu/ for a recent implementation of the language.
106
ß
Seller’s rules for managing messages:
Buyer. E Stuff. E Req Amnt. E Price.
Old Amount á^{ Req Amnt ;
difference(Old Amount, Req Amnt, Remaining Amnt) ;
max-price(Stuff, Max) ; Price á8{ Max =
manage(contractProposal(Buyer, Stuff, Req Amnt, Price)) (( (( (( ((((( ( ( (( ((
((
storing(Stuff, Old Amount) –.
storing(Stuff, Remaining Amount) ( ( ( (( ((( (( ((( (((( ((
(
ship(Buyer, Stuff, Req Amnt, Price) ( ( ( ( (( ( (((( (( ((( ((
(
send(Buyer, accept(seller, Stuff, Req Amnt, Price).
The goals before the = connective are not consumed by the execution of the rule:
they are used to evaluate values (difference(Old Amount, Req Amnt, Remaining Amnt), defined in some way), to compare values (Old Amount á8{ Req Amnt and
Price á8{ Max) and to get the value of variables appearing in facts that are not
changed by the rule (max-price(Stuff, Max)). In this case, they succeed if the conditions for shipping stuff are met. The goals manage(contractProposal(Buyer, Stuff,
Req Amnt, Price)) and storing(Stuff, Old Amount) are consumed; they are rewritten
in storing(Stuff, Remaining Amount) (the information about stored stuff is updated),
ship(Buyer, Stuff, Req Amnt, Price) (the required amount of stuff is shipped) and
send(Buyer, accept(seller, Stuff, Req Amnt, Price) (the message for informing Buyer
that its proposal has been accepted is sent). The ship predicate will be defined by
some rules that we do not describe here.
E
min-price(Stuff, Min) ; Price â^{ Min =
manage(contractProposal(Buyer, Stuff, Req Amnt, Price)) –.
send(Buyer, refuse(seller, Stuff, Req Amnt, Price).
If the proposed price is too low (min-price(Stuff, Min) ; Price â^{ Min) the Buyer’s
proposal is refused.
E
storing(Stuff, Old Amount) ; Old Amount â Req Amnt =
send(Buyer, refuse(seller, Stuff, Req Amnt, Price).
If there is not enough stuff stored, the Buyer’s proposal is refused.
E
E
Old Amount á^{ Req Amnt ;
min-price(Stuff, Min) ; Price á Min ;
max-price(Stuff, Max) ; Price â Max ;
eval-means(Max, Price, Means) =
107
send(Buyer, contractProposal(seller, Stuff, Req Amnt, Means).
If there is enough stuff and the price proposed by Buyer is between the minimum and
maximum prices established by the seller, the means of Price and Max is evaluated
(eval-means(Max, Price, MeanPrice)) and a contractProposal with this new price is
sent to Buyer.
3.9
A comparison among the specification languages
We compare the agent specification languages introduced so far along different dimensions. The
features we think to be relevant for our comparison are:
ß
ß
Time: is time dealt with explicitly in the language? Are there operators for defining complex timed expressions?
ß
Sensing: does the language provide the constructs for sensing actions (namely, actions
which sense the environment)?
ß
Communication: are communication primitives provided by the language? Is it necessary
for an agent to know details of another agent’s implementation in order to communicate
with it, or communication takes place on a more abstract level?
ß
Procedures: Does the language provide constructs for defining procedures?
ß
Concurrency: Does the language support concurrency of actions within the same agent?
Does it support concurrency among executing agents?
ß
Nondeterminism: Does the language support nondeterminism? In which way?
ß
Semantics: Is a formal semantics of the language defined?
Implementation: Is the language (or at least, a subset of it) implemented?
In the next paragraphs we will analyze the above features in detail.
Time. In Golog and ConGolog time instants are in direct correspondence with situations: s4 is
the agent’s situation at time ã , do > F a 'D0 *ä*å* 0 an Hæ0 s 4D? is the agent’s situation at time n. However, time
is not dealt with explicitly and no operators are provided for managing it. In AGENT-0 time is
included in all the constructs of the language. The operations allowed on time variables are only
mathematical operations (sums and differences). When programming an agent, it is possible to
establish the timegrain of its execution. Time is a central issue in METATEM and Concurrent
108
METATEM specifications: there are a lot of time-based operators (since, until, in the next state,
in the last state, sometimes in the past, sometimes in the future, always in the past, always in
the future) which allow to define complex timed expressions. As far as the other languages are
concerned, time does not appear in expressions of the language either explicitly or implicitly.
Sensing. Even if Dylog is the only language which provides an explicit construct for defining
actions which sense the value of a fluent, all the languages allow to perceive values of atoms that
are present in their knowledge base. Whether this knowledge base correctly maintains a model
of the environment or not, and thus whether it is possible to “‘sense” the surrounding environment or not, depends on the given specification. In our running example, all the agents maintain
the information about the stored amount of oranges locally to their knowledge bases: in a real
application this information should be obtained by physically sensing the environment (the department store, in this case), since nothing ensures that the agent’s information is coherent with
the environment state. It is worthwhile to note that, in a certain sense, the IMPACT agent programming language is the only one which really senses its (software) environment by means of
the code calls mechanism: this mechanism allows an agent to get information by really accessing
external software packages, instead of simulating them.
Communication. The two languages that embed a support to communication are AGENT0 and Concurrent METATEM. Among AGENT-0 language constructs, there are the INFORM,
REQUEST and UNREQUEST communicative actions which constitute a set of performatives
upon which any kind of communication can be built. Unfortunately, for agent A to request
an action to agent B it is necessary to know the exact syntax of the action to require. The
receiver agent has no means for understanding the content of a request and performing an action
consequently, if the action to be performed is not exactly specified as the content of the message
itself. This is clearly a strong limitation, which more recent agent communication languages,
such as KQML [146] and FIPA ACL [88] have overcome. The same limitation affects Concurrent
METATEM: every agent has a communicative interface the other agents in the system must know
in order to exchange information. Moreover, Concurrent METATEM does not provide a set of
speech acts that all the agents recognize: an AGENT-0 agent may not understand the content of
a REQUEST, but it at least knows the REQUEST performative; this is not true for a Concurrent
METATEM agent. The IMPACT language does not provide communication primitives as part of
the language, but among the software packages an agent may access there is a msgbox package
providing message box functionalities. Messages can have any form, adhering to some existing
standard or being defined ad-hoc for the application. As far as the other languages are concerned,
the specification developer has to define her own communication primitives; however, for all the
languages we took under consideration in this review we could find examples describing this
task.
109
Procedures. Golog, its extension ConGolog and Dylog all support the definition of procedures. In ConGolog these procedures are defined by macro expansion into formulae of the situation calculus, while in Dylog they are defined as axioms in the dynamic modal logic. AGENT-0
does not support the definition of procedures, even if in Section 6.3 of [181] macros are used for
readability sake. The macro expansion mechanism is not supported by the AGENT-0 implementation. % hhf supports the definition of procedures as logic programming languages do, by defining
rules for solving a goal. Finally, IMPACT and Concurrent METATEM do not allow the definition
of procedures.
Concurrency. ConGolog provides different constructs for concurrent execution of processes;
these processes may be either internal to a single agent or may represent different agents executing concurrently. Thus, ConGolog supports either concurrency of actions inside an agent
and concurrency of agents. The same holds for % hhf , where it is possible to concurrently execute
either goals internal to a single agent or goals for activating different agents. As an example of
the last case, if different agents were characterized by a cycle like the one depicted for the seller
agent, it would be possible to prove a goal like agent1-cycle ç agent2-cycle ç ... ç agentN-cycle
meaning that agent1 to agentN are executed concurrently. As far as IMPACT it concerned, it
associates a body of code implementing a notion of concurrency to each agent in the system, to
specify how concurrent actions internal to the agent must be executed. Concurrency of agents is
not explicitly specified: the IMPACT language allows the definition of individual agents, not of
agent societies. The converse situation takes place with Concurrent METATEM, where concurrency of internal actions is not supported; a Concurrent METATEM specification defines a set of
concurrently executing agents which are not able to execute internal concurrent actions. Finally,
either Dylog and AGENT-0 do not support any kind of concurrency16 .
Nondeterminism. Both Golog and ConGolog allow for nondeterministic choice between actions, nondeterministic choice of arguments and nondeterministic iteration. Nondeterminism in
the IMPACT language derives from the fact that the feasible, rational and reasonable status sets
giving the semantics to agent programs are not unique, thus introducing nondeterminism in the
agent’s behavior. In Dylog and % hhf nondeterminism is introduced, as in usual logic programming settings, by the presence of more procedures (rules, in % hhf ) defining the same predicate.
The main source of nondeterminism in Concurrent METATEM is due to nondeterministic temporal operators such as “sometimes in the past”, “sometimes in the future”, which do not identify
a specific point in time, but may be verified in a range of instants. Finally, AGENT-0 does not
seem to support any kind of nondeterministic behavior.
16
When we say that a language does not allow the definition of concurrent agents, we mean that its target is not
the specification of a MAS, but the specification of a single agent. The language working interpreter may allow the
execution of more agents by simulating their concurrency or by really activating concurrent threads of execution,
even if this concurrent execution cannot be specified at the language level.
110
Semantics. All the languages discussed in this survey, except from AGENT-0, have a formal
semantics.
Implementation. For all the languages an interpreter is given. Almost all these interpreters are
prototypical ones; the one developed for IMPACT is probably the most robust one, according to
the applications IMPACT has been used for (see the project’s applications page, http://www.
cs.umd.edu/projects/impact/apps.html, for more information.)
3.10
Conclusions
In this section we discuss some pros and cons of the use of logic-based languages for specifying,
programming and verifying agent systems. This section is based on both Section 2 of [204],
where M. Wooldridge and N. Jennings discuss formal theories of agents, and Section 3.4 of [53],
where M. Wooldridge and P. Ciancarini point out some problems arising when using logic-based
languages for defining and executing agent specifications. We also add some considerations of
our own on the use of logic programming for developing MAS prototypes.
3.10.1 Pros
As far as modeling is concerned, we have seen that agents are often modeled in terms of mental
attitudes such as beliefs, desires, intentions, choices and commitments. The main advantage in
using modal logic for modeling intentional systems is that it allows to easily and intuitively represent intentional notions without requiring any special training. The possible world semantics
usually adopted for modal languages has different advantages: it is well studied and well understood, and the associated mathematics of “correspondence theory”’ is extremely elegant. Formal
languages that support temporal operators are a powerful means for specifying sophisticated reactive agents in a succinct fashion, abstracting from details that otherwise should be coped with.
Moreover, since agents are expected to act, languages based on formal theories of action such
as dynamic logic and the situation calculus are extremely suitable to model agents’ ability to
perform actions.
According to the observations above and to the considerations we discussed in Section 2.6, if we
compare logic languages and object-oriented formalisms for the specification of agents we note
that logic languages are definitely more suitable to model agents showing features like autonomy
and pro-activeness. Moreover, we already noticed that the kind of decomposition that objectoriented methods encourage is at odds with the kind of decomposition that agent-oriented design
encourages. Logic languages allow to conceptualize agents in a simpler and more natural way.
111
As far as implementation of a working prototype is concerned, using a logic programming language has different advantages:
ß
ß
MAS execution: the evolution of a MAS consists of non deterministic succession of events;
from an abstract point of view a logic programming language is a non deterministic language in which computation occurs via a search process.
ß
Meta-reasoning capabilities: agents may need to dynamically modify their behavior so as
to adapt it to changes in the environment. Thus, the possibility given by logic programming
of viewing programs as data is very important in this setting.
Rationality and reactiveness of agents: the declarative and the operational interpretation
of logic programs are strictly related to the main characteristics of agents, i.e., rationality
and reactiveness. In fact, we can think of a pure logic program as the specification of the
rational component of an agent and we can use the operational view of logic programs
(e.g. left-to-right execution, use of non-logical predicates) to model the reactive behavior
of an agent. The adoption of logic programming for combining reactivity and rationality
is described in Section 5.5.2.2, based on [119, 120].
3.10.2 Cons
Besides the advantages discussed above, when using formal languages for defining, implementing and verifying agent specifications, a number of problems suggest themselves:
Directly executing agent specifications. When directly executing agent specifications the risk
arises that, if the adopted logics has both a temporal dimension and modalities for referring
to beliefs, desires and so on, models for the logic have ungrounded semantics. That is, the
semantic structures that underpin these logics (typically accessibility relations for each
of the modal operators) have no concrete computational interpretation. As a result, it is
not clear how such agent specification languages might be executed. Another problem is
that execution techniques based on theorem-proving are inherently limited when applied to
sufficiently expressive (first-order) languages, as first-order logic is undecidable. However,
complexity is a problem even in the propositional case.
Automatic synthesis. The techniques for automatic synthesis have been developed primarily
for propositional specification languages. When attempting to extend them to more expressive, first-order specification languages, we again find ourselves coming up against the
undecidability of quantified logic. Even in the propositional case, the theoretical complexity of theorem-proving for modal and temporal logics is likely to limit the effectiveness
of compilation techniques. Another problem with synthesis techniques is that they typically result in finite-state, automata-like machines, which are less powerful than Turing
112
machines. In particular, these systems cannot modify their behavior at run-time. In other
words, they are not able to learn. In Chapter 4 we will see that learning and adapting to
changes occurring in the environment are very relevant features for intelligent agents. The
impossibility to specify this kind of behavior is a strong limitation.
Verification. Axiomatic approaches suffer from two main problems. First, the temporal verification of reactive systems relies upon a simple model of concurrency, where the actions that
programs perform are assumed to be atomic. This assumption does not hold when moving
from programs to agents which generally perform more coarse-grained actions. The second problem is the difficulty of the proof problem for agent specification languages. The
theoretical complexity of proof for many of these logics is quite daunting. As far as model
checking approaches are concerned, the main problem, as already indicated, is the issue of
ungrounded semantics for agent specification languages.
Implementation of agent systems using logic programming. The adoption of logic programming for executing agents specifications suffers from some drawbacks, among which:
ß
ß
Diffusion: logic programming is not very widespread in industrial and commercial
environments; software engineers and software developers tend to be reluctant to use
this programming paradigm.
ß
Distribution and mobility: there are some logic-based languages that support distribution and mobility, for example P. Tarau’s Jinni [194], but the most solid Prolog
implementations, such as SICStus Prolog, provide poor support to these features,
which may prove extremely useful to develop agent-based systems.
External packages integration: the integration of calls to functions/methods written in
foreign languages, which is a very important feature for the development of a sophisticated working prototype close to the final application, is supported by some Prolog
interpreters (for example, SICStus Prolog, by means of the Jasper interface, can integrate Java methods) but interfaces towards packages, such as an Oracle database,
or other software modules, are still extremely rare.
113
Chapter 4
Frameworks for Multi-Agent Systems
Development
4.1
Introduction
In the previous chapters, we have already discussed that one of the main reasons of the agentoriented software paradigm success is that it provides the right level of abstraction for engineering heterogeneous, distributed applications [53, 111, 167], representing a valuable help for
handling their complexity and developing them.
Agents and MASs are more and more successfully deployed and used in practice, even if many
theoretical issues underlying them are not fully understood at this point and subject of current
investigations. The lack of rigorous formal definitions and characterizations of agenthood, and
the unclarity or even disagreement about what constitutes a MAS make the gap between theory
and practice quite evident. More and more environments for developing agents and agent systems
become available, each one adhering more or less faithfully to some existing definition of agent
or adopting one ad-hoc.
Purist researchers may argue that only a very small number of existing general-purpose environments for modeling and developing MAS, which we refer to as MAS development kits (MASDKs) throughout this chapter, can be used to build true agents. Most of these MASKDs associate
with this term a poor meaning, based on the features of the kind of software whose development
is supported, rather than on some generally agreed theoretical definition of agent (which, arguably, is difficult to find).
In this chapter, based on [69], we do not address the problem of what an agent is; many researchers have been working on finding a good answer to this question; see e.g. [91, 31, 110].
The definition proposed by N. R. Jennings, K. Sycara, and M. Wooldridge in [110], which we
114
quoted in Section 1.1, takes into account many relevant agent features, and our work is mainly
guided by their conceptualization. Nonetheless, we are aware that their notion of agent is not
a finally agreed definition and for this reason we avoid discussing which available MASDKs
support the development of agents which really deserve this name, and which ones just provide
rudimentary support, by misusing or even abusing the terminology coming from the agents field.
We just observe that MASDKs exist, and that a MAS developer should take advantage of them
for building a MAS as it seems fit. The developer, before asking
“How should I build an ad-hoc MAS which models and realizes my application?”
should try to answer the question
“Is there any development environment available which suits my application features
and requirements? How can I determine it?”
Because of the evolution of the field and the continuing emergence of new agent environments
and applications, no standard criteria for answering such a question do exist. This leaves us in
a position that while numerous tools are available, providing a wealth of different features and
capabilities, it is a nontrivial and, moreover, laborious task to single out some MASDK which
fits best the need of a MAS application.
In the following sections we aim at providing
ß
ß
some guidelines for MASDK selection performed on an application-driven basis, and
an evaluation of five selected MASDKs.
The last point practically exemplifies our approach to MASDK evaluation, and provides a MAS
developer with support for understanding which MASDK (if any of them) can fit her needs
among the evaluated ones.
Our approach to the development of the guidelines for MASDK selection proceeds in four steps,
which are sketched in Figure 4.1:
Step 1 We compile a list of features that are useful for assessing MASDK properties; this is
the subject of Section 4.2. This list is certainly not complete, as further criteria could be
added: finding a complete and universally agreed set of MASDKs evaluation criteria is
at least as difficult as finding a universally agreed definition of agent. Our list takes into
account important characteristics which are widely recognized to be relevant for defining
agenthood, and includes a set of core criteria.
115
Agent attitudes,
software engineering
support, technical
issues, ....
STEP 1: identification
of MASDK’s characterizing
features
STEP 2: analysis of
existing MASDKs
AgentBuilder, CaseLP,
DESIRE, IMPACT,
Zeus
STEP 3: analysis of
existing domains where
the agent technology is used
Entertainment,
medical care,
telecommunications, ...
STEP 4: guidelines for
identifying a set of MASDKs
for developing the
given application
Will the application be used
for research or commerce?
Is it a simulation?
.....
Figure 4.1: Our approach to develop MASDK selection guidelines.
Step 2 According to the identified features, we analyze and compare five MASDKs: AgentBuilder, CaseLP, DESIRE, IMPACT and Zeus in Section 4.3. These platforms have
different features and properties, and their heterogeneity is useful for testing our evaluation
criteria. As a consequence of this analysis we decided to extend two of these platforms,
CaseLP and IMPACT, to overcome some of the limitations which our comparison put in
evidence.
Step 3 In Section 4.4, we analyze different scenarios where applying agent technology has already proved to be useful. For each of them, we highlight features which should be supported by a MASDK for being profitable in that scenario.
Step 4 Finally, in Section 4.5 we propose a set of selection guidelines based on the features of
the MAS which should be developed. These guidelines aim at helping in the process of
individuating a set of requirements which a MASDK should meet for being suitable to
specific MAS development.
The steps 4 to 2 can be followed, in reversed order, as a top-down approach by the developer
who wants to identify a set of MASDKs which are attractive for building her application. This is
sketched on the following example, depicted in Figure 4.2, which is detailed as follows:
Step 4 The developer uses the guidelines to clarify the scenario to which the application to be
developed belongs. This information will be used in Step 3. Other questions are addressed
to help identifying another set of useful MASDK features which will be used in Step 2.
116
Step 3 Let us suppose the scenario to which the application belongs involves information gathering. The set of features which a MASDK for developing such an application should
support are identified in this step. The “output” of Step 3 will be used in Step 2.
Step 2 Now the developer possesses a set of MASDK features known to be useful for the development of her application. This set derives partly from Step 4 and partly from Step 3.
The developer can use these features as keys to choose a MASDK which meets her needs,
according to the classification that we provide in Section 4.3. Usually, there will be more
than one MASDK that approximates the ideal MASDK for the application to be developed. We do provide guidelines for restricting the set of MASDKs under consideration to
a (small) set of candidates, which have almost equivalent properties; further discrimination
and selection of a single candidate remains with the user.
However, we do not explicitly adopt the developer’s perspective in the following, but develop the
approach from our perspective of a bottom-up approach.
4.2
MASDK features
Because of the different perspectives, the identification of a set of independent, orthogonal features which completely characterize a MASDK seems infeasible. In this section, we describe
five groups of features which, as we believe, are significant enough to understand for what kind
of applications a MASDK may be well-suited.
The aspects we consider are:
1. Agent attitudes. As well known, there is no complete agreement on which attitudes characterize agenthood yet. After all, it seems that reasonably agenthood should be a soft concept
rather than a “hard” Yes/No property. By taking into account existing definitions of agenthood from the literature [110], we individuate a set of “interesting” features and assess, for
any analyzed MASDK, whether it takes them into account or not. We group the attitudes
into basic attitudes, which are close to the very core of agenthood, and advanced attitudes,
which are desirable but not of central interest.
2. Software engineering support. The development of a multi-agent system is a complex task
which greatly benefits from the adoption of a well-defined engineering methodology. Instruments should be available for helping the developer during the modeling and development stages. Not all the MASDKs provide such kind of support, so it is interesting to
understand which of them address the engineering of the MAS development and which do
not. This point is expanded on in Section 4.2.2.
117
STEP 4
Which are the other relevant
features for the application
to be developed?
In which scenario does the
application to be developed
fall into?
It is important to
formally verify properties
Information gathering
STEP 3
Which are the relevant
gathering application?
features for an information
Mobility, learning, security,
ontological analysis support,
sw integration, .......
STEP 2
Which MASDK among the evaluated ones does
support mobility, learning, security, ontological
analysis, sw integration, ..., formal verification?
Mobility is partially supported by IMPACT and Zeus.
Learning is not supported by any MASDK.
Security is partially supported by IMPACT.
Ontological analysis is supported by AgentBuilder,
IMPACT, Zeus and, partially, by CaseLP and DESIRE.
SW integration is addressed by all the MASDKs at
different levels.
Formal verification is addressed by DESIRE and,
partially, by CaseLP.
Figure 4.2: Application-driven selection of MASDKs: an example
118
3. Implementation of agents and MAS. Once the structure of the MAS is clear and mature
enough for implementation, it becomes necessary to understand in which language the
agents will be finally implemented using one MASDK, which debugging facilities the
MASDK provides to implement them, and which standard agent skeletons are eventually
available. These features are mainly related with the way the MASDK helps the developer
in implementing a correctly working MAS with the least effort and in the shortest possible
time (Section 4.2.3).
4. Technical issues. The technical aspects which characterize a MASDK are more or less the
same as those characterizing languages and toolkits for building large, complex software
systems. Typical needs are physical distribution of agents, current agent execution, possibility to let them roam across the network in order to minimize the time/cost of their task,
good performance and finally all the safety, security and error-tolerance issues. Also the
capability of integrating external and/or legacy software in the MAS is crucial for many
applications. Section 4.2.4 expands on this point.
5. Economical aspects. Finally, as pointed out in [176], different issues are of particular interest from a business standpoint. The availability of on-line consulting and training, the
supported platforms, the system requirements etc, will be discussed in Section 4.2.5 as
relevant aspects in the choice among different candidate MASDKs.
4.2.1
Agent attitudes
One of the most general definitions of agent is the one proposed in [110], quoted in Section
1.1, that describes an agent as a situated, autonomous entity capable of flexible (responsive,
proactive and social) actions. Thus, situatedness, autonomy, responsiveness, pro-activeness
and sociality are basic agent attitudes that we take into consideration. Sociality, which is a key
feature in MAS, includes among others the following aspects:
ß
Agent Communication Language. In [92] software agents are defined as
“software ‘components’ that communicate with their peers by exchanging messages in an expressive agent communication language. [ *-*-* ] The salient feature of the language used by agents is its expressiveness. It allows for the exchange of data and logical information, individual commands and scripts.”
Research in the field of Agent Communication Languages (ACLs) is very lively, and it
has led to the establishment of two fully-specified ACLs: the FIPA ACL [88] and KQML
[146]. A MASDK supporting a standard ACL enhances communication standardization
and re-usability of agents in different environments.
119
ß
Information exchange means. This issue can be analyzed from two points of view, reflecting different levels of abstraction. At a high level, the MAS developer may be just interested in the way agents exchange structured information. This can be achieved through
different methods, e.g. via message passing (upon which ACLs are built), by means of a
blackboard, by method invocation, etc.
From a low level point of view, it is useful for the developer to know the data transmission
means used within the MASDK, which allows her to use already available features in
order to maintain certain communication properties. For example, if she knows that data
exchange between agents is based on TCP/IP, then she can avoid to re-implement the basic
safety mechanisms which TCP/IP already ensures.
ß
ß
Coordination protocols. Many protocols for coordination and negotiation among agents
have been proposed (see [108] and [121] for an introduction to the topic); the availability
of a library of coordination protocols in a MASDK avoids to re-invent or just re-implement
already developed strategies.
Human-agent interaction. In order to develop agents which intelligently interact with
human beings [131], advanced capabilities such as speech recognition, natural language
understanding, image recognition, etc, should be provided by the MASDK.
It is desired that besides the above basic attitudes, agents should have further advanced attitudes,
including the following:
ß
ß
Mental attitudes. The agent is conceptualized in terms of mental notions, such as commitments, beliefs, desires, intentions [64].
ß
Deliberative capabilities. The agent explicitly represents its objectives and reasons about
them. This issue is strictly related with the agent’s planning capabilities, namely the ability
to formulate and compare possible plans to solve a goal.
ß
Meta-management. The agent maintains a (nested) model of itself (reflectivity) and of
other agents, and is able to reason about this model.
ß
Emotionality. The agent is ascribed emotional attitudes. Its behavior is guided not only
by its rational goals but also by its emotions [185, 74, 173, 206].
Adaptivity. The agent flexibly changes its strategies to adapt to the evolving environment
and learns from previous experiences.
120
4.2.2
Software engineering support
The following issues are important from a software engineering perspective:
ß
ß
Methodology. A well-defined methodology greatly helps the developer in passing from
the initial informal ideas about the MAS to build the final, working MAS. Following a
clear sequence of steps which gradually face more detailed and concrete aspects of the
application design is a good approach in the development of any application. This is particularly true for the development of MASs, whose complexity can be properly faced and
managed only by following a well-structured approach. For any step of the methodology,
the MASDK should ideally provide languages and tools for its support.
ß
Ontological analysis. Ontologies are content theories about knowledge domains, developed to clarify knowledge structure and enhancing knowledge reuse and standardization
[51]. They represent a powerful means to organize concepts and relations among concepts
in an agent-based application, and to unambiguously describe features and properties of
agents. In particular, ontologies are needed if heterogeneous information sources must be
integrated in the same MAS.
ß
Specification. In the design of a MAS, various aspects must be considered. For example,
it is important to provide an architectural static description of the system (which types of
agents are involved, how many instances for each type, etc.), as well as a description of the
internal functioning of a single agent (which data structures does the agent use, which is the
control flow among these data structures, etc.). Thus, either a set of different specification
languages or a single specification language capable of phrasing different views of the
problem should be supported by the MASDK. The MASDK documentation should provide
suggestions on how to specify the different views of the problem, and possibly how to map
these specifications into the agent implementation language. Since automatic methods for
correctly translating the specification into the agent implementation language are difficult
to realize, some informal hints would be enough, at least for not safety critical applications.
The adoption of a standard and well-known specification language for describing (part of)
the MAS application turns out to be a good choice also to spread the agent technology use.
ß
Verification. When the MAS faces safety-critical problems, it may be necessary to formally verify at least a subset of its properties. In this case, verification mechanisms provided by the MASDK would be helpful.
Prototyping. Usually it is not possible to formally verify the complete behavior of the
MAS. A viable way of testing the MAS design correctness is to build a working prototype
and to analyze its behavior on different, relevant scenarios. If the specification language(s)
previously adopted is (are) executable or animable, the prototype is obtained for free.
121
ß
Summarizing information collection. Strictly related with the ability to build a working
prototype for the MAS application, is the ability to get summarizing information from the
prototype execution run: the possibility to trace some particularly relevant aspects of the
prototype execution (for example, agents state evolution or messages exchange) and to
synthesize them with graphics or tables proves extremely useful for a full understanding
of the application evolution.
ß
Scalability. In order for the developer to build large applications with hundreds of agents
exchanging thousands of messages, it is necessary to know if the MASDK scales to such
dimensions or if it is suitable only for small applications.
ß
Maintainability. To ensure that an application developed with a MASDK does not become
soon obsolete and difficult to update, it is important to know if a continuous maintenance
of the toolkit is provided.
4.2.3
Agent and MAS implementation
As for the implementation of a single agent or of a whole MAS, the following aspects are relevant
at a macro level:
ß
ß
Agents implementation language. After the specification and testing phases are completed and the developer is confident enough in the correctness of the MAS design, it
is time to implement the MAS. The code for the agents may be written either in some
commercial language or in an ad-hoc proprietary language. The skills and personal preferences of the MAS developers, the already developed pieces of code which should be
“agentified”, the efficiency and portability required to the MAS, and yet many other factors will determine whether the agent implementation language provided by a MASDK
suits the application needs or not. For example, if speed of development and efficiency
of the final application are crucial issues, then a MASDK where agents are implemented
in an interpreted rule-based language which the developers do not know and should learn
from scratch is not the best choice.
ß
Physical environment models. When a simulation of some physical process is performed,
the environment where the process takes place must be simulated. A library of explicitly
modeled environments can be provided to the MAS developer.
ß
Agents and MAS definition GUI. A facility which would help the development of (possibly) correct applications is the presence of graphical interfaces which guide and, in some
sense, constraint the definition of the agents and/or of the MAS as a whole.
Agents skeletons. By “agent skeletons” we mean generic agent models which can be
reused in different situations. Models for agents with different architectures (for example
122
reactive, pro-active and BDI architectures1 , *,*-* ), models for agents that play reusable roles
in standard interaction patterns (for example, a model for an agent that plays the “seller”
role in a contract proposal protocol2 ) and models for agents that accomplish generic tasks
fall in this “agent skeletons” category. The availability of agent skeletons helps the agent
developer in building correct applications faster and more easily, since potential sources of
programming errors are reduced.
ß
Utility agents. There are different agents offering services to the MAS community which
do not depend on the particular application domain. For example, broker agents or yellow
and white pages agents can be defined and then integrated in different systems without
requiring any change. For this reason, it is to be hoped that the MASDK already provides them, allowing the MAS developer to concentrate on the domain-dependent agents
definition.
ß
Debugging facilities. Debugging a MAS is, because of its distributed and concurrent
nature, a difficult and complex task in general. For the development of a correct, reliable,
and robust system, automated support in this direction is needed.
4.2.4
Technical issues
The needs arising in different applications have led to the following desired technical MASDK
features:
ß
Mobility. When the agents need to retrieve information which is scattered over different
nodes of a network, mobility may represent an efficient way for achieving this task.
1
In Section 5.5.2 some existing architectures are discussed; more on architectures can be found in Section 6.2.1,
where the CaseLP characterization of an architecture is given.
2
Roles played in interaction patterns can be modeled in agent skeletons by suggesting to the MAS developer
the correct sequence of messages an agent should process and deliver in order to fulfill the role, and by giving
suggestions on which kind of conditions over the current agent state should be verified. For example, if the syntax
of agent programs in a MASDK is the AgentRules’ one depicted in Section C.5.1
on message Message check Condition do ActionList
part of a skeleton for a seller agent in the interaction protocol depicted in Figure 3.1 could look like
on message contractProposal( è parameters é )
check è conditions to verify if the proposal is profitable for you é
è if proposal is profitable é do è some actions é ; send(accept( è parameters é )) XOR
è if proposal is not profitable é do è some actions é ;send(refuse( è parameters é )) XOR
è if proposal can be negotiated é do è some actions é ;send(contractProposal( è parameters
where text included between two
èqé
symbols is a comment.
123
é
))
ß
Distribution. If the agents do not roam across the network, they may however be distributed. The MASDK must provide all the facilities for allowing the agents to reside in
different physical locations and to safely interoperate.
ß
Concurrency. Any agent must possess its own thread of control. Thus, agents find a
natural implementation in concurrently executing processes.
ß
Security. When mobility and distribution come into play, mechanisms are required to ensure security. The agent developer must be sure that her mobile agents will not be damaged
by malicious entities during their roaming, and vice versa that her stationary agents will
not be damaged by malicious mobile agents. Furthermore, information exchanged among
distributed entities must not be intercepted or corrupted.
ß
Error-tolerance. In many domains where agents find an application, such as plant control,
electronic commerce, telecommunications and many others as well, the ability of an agent
of going on working even in case of errors and of autonomously recovering from troubles
should be supported to provide the MAS users with a high-reliable service.
ß
Real-time control. Depending on the application, the need for real-time control and response may arise.
ß
Performance. Having some information on the toolkit’s performance may help understanding if it is suitable for the (eventually “real”) application the developer is going to
build.
ß
Latency. In order to correctly interpret the behavior of the agents in the system, the developer should know if communication channels have some latency, if this latency may be
simulated and if messages can be received in a wrong order with respect to the order they
were sent.
ß
Software integration. It is quite difficult to imagine that a large, complex MAS may be
built completely from scratch. The realistic scenario is a MAS where legacy code should
be seamlessly integrated with newly developed agents and external software packages. The
easy integration of external software and packages within the MAS satisfies the need of
software reuse, which characterizes most of the current software production.
ß
4.2.5
Other issues. Finally, other relevant aspects are the platforms where the MASDK can be
installed, the language in which it is implemented, the system resources it requires, the
availability of trial releases and its cost.
Economical aspects
From a management perspective, the following issues are important:
124
ß
Vendor organization. Knowing the organization providing the MASDK is relevant in the
choice of a product:
“ *,*-* a historical profile of the vendor and the product will be taken into account
so that longevity of the relationship can be assured [176].”
ß
Training, documentation and support. The availability of documentation, as well as
training facilities and immediate on-line help on a 24 hours basis for registered clients are
relevant issues in choosing a MASDK. To quote [176] again,
“The availability of on-site consulting and training for the initial “burn-in” period will set the stage for subsequent relationships. [ *-*-* ] Much knowledge
is gained from a product’s installation base and associated developer groups,
whereby features and quirks can be formally and informally documented.”
4.3
Evaluation of some MASDKs
In this section, we provide an evaluation of five MASDKs, according to the features identified in
Section 4.2. Our evaluation is mainly based on our knowledge, as far as CaseLP and IMPACT
are concerned, and on the available documentation and on the information that some researchers
provided to us3 , as far as the other toolkits are concerned. Some of our judgments may prove not
appropriate or superficial, due to a lack of deep experience with the respective tools. However,
even if some debates and criticisms will arise, we think that our evaluation is useful as a starting
point for finding the right MASDK to do the right thing, to paraphrase J.P. Müller’s influential
paper [155] (see Appendix B.4).
The criteria we followed in selecting the MASDKs for evaluation are subjective, and our choice
does by no way mean that they are preferable or better than other MASDKs. By giving a glance
at some sites providing valuable resource about MASDKs, such as the University of Maryland
Baltimore Campus’s site,4 J. Vidal’s MultiAgent Systems site,5 the AgentBuilder site,6 just to cite
some of them, it appears that there is almost one hundred of agent development environments that
could be evaluated. Initially, we intended to evaluate around forty MASDKs, but this enterprise
soon revealed as a titanic work, and we had to drastically reduce their number. We thus had to
identify a smaller set of MASDKs to start with, and we decided to consider the MASDKs we had
3
See the Credits at page 273.
See http://agents.umbc.edu/Applications_and_Software/Software/index.shtml
for more than 100 links to commercial, academic, and open source software.
5
http://www.multiagent.com/Software/Tools_for_building_MASs/index.html with
links to many different tools for building MASs.
6
http://www.agentbuilder.com/AgentTools/index.html with links and a short description of
26 commercial and 41 academic agent software platforms.
4
125
more knowledge about and that presented a range of interesting features complying at least our
basic agent attitudes, in order to test our approach on non-trivial examples. Our evaluation has
demonstrated that the five MASDKs we chose share some similarities (for example, none of them
allows agent modeling in term of emotional attitudes, none provides a full support to mobility,
all of them take a principled software engineering approach into consideration), but also show
many differences (the MASDKs we evaluated are both commercial and academic ones, facilities
for verification are different from MASDK to MASDK, utility agents are provided only by two
of them, training and support are addressed in different ways, the MASDKs implementation
languages range from object-oriented to logical languages). We think that the five MASDKs we
chose, although not covering all the existing typologies of MASDKs, are heterogeneous enough
to represent an interesting test-bed for our approach. It is part of our future work to extend the
comparison to a larger set of MASDKs.
4.3.1
An introduction to the evaluated MASDKs
The MASDKs we have evaluated are: AgentBuilder; CaseLP; DESIRE; IMPACT; and Zeus.
AgentBuilder7 is a commercial product developed by Reticular Systems, Inc. It consists of two
major components: the development tools and the runtime execution environment. The first
ones are used for analyzing an agent’s problem domain and for creating an agent program that
specifies agent behavior; the run-time system provides a high-performance agent engine that
executes these agent programs.
CaseLP (Complex Application Specification Environment based on Logic Programming [144])
is a research environment developed at the Computer Science Department of Genova University
(Italy). It is mainly conceived as a prototyping tool for agent-applications; it focuses on the
prototype development method, the ability of integrating agents written in different specification
languages, and the ability of simulating the resulting MAS behavior.
The DESIRE (DEsign and Specification of Interacting REasoning components) research program [67]8 is carried out at the Artificial Intelligence Department of Vrije University, Amsterdam, Nederlands. It focuses on the study of compositional multi-agent systems for complex,
distributed tasks. A framework is provided which supports all the development phases of the
compositional MAS.
IMPACT (Interactive Maryland Platform for Agents Collaborating Together [72, 71, 12])9 is a
multinational project whose aim is to define a formal theory of software agents, implement it (or
carefully specify fragments of it) and develop a suite of applications on top of this implementa7
See http://www.agentbuilder.com/Documentation/product.html for a description of the
AgentBuilder products.
8
http://www.cs.vu.nl/vakgroepen/ai/projects/desire/desire.html
9
http://www.cs.umd.edu/projects/impact/
126
tion. The integration of heterogeneous software modules within the same MAS is performed by
adding a semantic wrapper to the bodies of software code, in order to “agentify” them. We have
already introduced the IMPACT programming language in Section 3.5.3 and we will deal with
this framework throughout Chapter 5.
Zeus [39]10 is an environment developed by British Telecommunications, plc. for specifying and
implementing collaborative agents, following a clear methodology and using the software tools
provided by the environment. The Zeus approach to MAS development consists of analysis,
design, realization and runtime support. The first two stages of the methodology are described
in detail in the documentation, but they are not supported by software tools. The last two stages
are supported by software tools.
4.3.2
Feature assessment
We have organized the evaluation and comparison of the MASDKs by using tables. The aim of
this section is to synthesize the results of our analysis and help discovering whether a MASDK
supports a feature in the quickest and easiest way. Tables assign rates to features or text is used.
Where available, references to papers which describe the feature have been added. Where rates
are used, they range over three values, ê , ë and ë , ordered in this way: ê is better than ë ,
which is better than ë . The meaning of ê , ë and ë depends on the evaluated feature and is
shortly explained inside the table. The reader interested in more details may go to Appendix A,
where explanations and further background information is provided. For sake of conciseness, we
limit ourselves to explain the meaning of ratings that appear in the tables: the reader can easily
guess the intended meaning of ratings which were not assigned. (For example, in Table 4.5 no
MASDK deserves a ê rating for the mobility feature: from the explanations we give, it is easy to
understand that this rating can be assigned only to MASDKs that allow to build mobile agents.)
4.3.3
Agent basic attitudes
As for the basic agent attitudes, we have that they are supported by all five MASDKs that we
considered. Thus, in this sense they are all platforms for building agent systems.
4.3.4
Agent advanced attitudes
An observation emerging from Table 4.1 is that the effort in building agents which mimic human
behavior is mainly directed towards the rational aspect of humanity (mental notions, planning,
10
http://www.labs.bt.com/projects/agents/zeus/
127
Mental
Attitudes
(MA)
AgentBuilder
CaseLP
DESIRE
IMPACT
Zeus
Deliberativity
(D)
ì
í
í
í
í
[30]
[38]
[68]
[39, 77]
Reflectivity
(R)
í
í
í
í
í
í
[156]
í
ì
í
í
Emotionality Adaptivity
(A)
(E)
í
í
í
í
í
í
í
í
í
[37]
[68]
í
MA, ì : Agents are conceptualized in terms of mental attitudes.
MA, í : Agents are not conceptualized in terms of mental attitudes, but extensions for modeling
them are provided.
D, ì : The MASDK provides an already developed planner as part of the standard equipment.
D, í : Extensions of the MASDK with a planning system are under study.
D, í : The MASDK does not include any planning system.
R, í : Models for reflective agents are provided.
Other í : feature is not addressed.
Table 4.1: An evaluation of the advanced agent attitudes.
reflectivity) rather than on the human emotional side.11 From the information we got from the
various MASDK teams, it was clear that most of the “rational” attributes had been (at least) taken
into consideration, even if they are not integrated in the toolkit. For example, applications involving planning have been developed using all the toolkits, even if libraries of planning strategies
are provided only by two of them. On the contrary, applications involving emotional agents have
not been developed with any toolkit.
4.3.5
Social ability
Table 4.2 shows that the five MASDKs we have considered do not face issues of HumanComputer Interaction. A rough interpretation of this result, combined with the lack of support
for emotionality evidenced in the previous section, suggests that these MASDKs are not suitable
for developing applications where believable characters interact with human users using some
human-like means of communication (speech, vision, î-î-î ). Even if the set of MASDKs we
are considering is too small for having any statistical relevance, our feeling is that the world of
“believable emotional agents” and the world of “intelligent agents” are still separate, each one
facing only particular aspects of agenthood. We also have the feeling that agents showing a behavior determined by emotions are definitely less addressed than agents which show behaviors
determined by rationality.
11
Recall that in this context, by emotions we mean feelings like anger, envy, pride, etc.
128
ACL
AgentBuilder
CaseLP
DESIRE
KQML [146]
KQML +
FOL lang. [36]
IMPACT
Zeus
ASDL +
FIPA ACL [88]
Information exchange Coordination
means (low level)
Protocols (CP)
RMI, TCP/IP
í
í
internal data structures
internal data structures,
ì [35, 33]
TCP/IP
RMI
í
TCP/IP
ì
Human-Agent
Interact. (HAI)
í
í
í
í
í
ACL: “+” means that the default ACL is the one written, but agents can interact using other ACLs.
FOL lang.: The ACL is based on first order logic.
ASDL: The ACL (Agent Service Description Language) is based on XML.
internal data structures: Information is exchanged through internal data structures.
CP, ì : A library of already-developed coordination protocols is provided.
CP, í : No coordination protocols are provided.
HAI, í : Human-Agent Interaction is not addressed.
Table 4.2: An evaluation of the agent social ability.
4.3.6
The MASDKs that we considered cover many of the issues concerning Software Engineering, as
shown by Table 4.3. Due to the complexity of MASs, support in this direction is perceived as a
must for a toolkit which aims at constructively helping the developer in her hard task.
4.3.7
Implementation of agents and MAS
It emerges from Table 4.4 that all the MASDKs considered lack an explicit model of the surrounding environment. As it will be discussed in Section 4.6, this aspect is mainly concerned
with Artificial Life.
4.3.8
Technical issues
Four results can be extracted from Tables 4.5 and 4.6:
ï
Mobility is not fully supported by any MASDK; IMPACT has integrated this feature, but
some issues are still under consideration, and Zeus can integrate mobile agents, but experimentation in this direction is still at the beginning. Mobility is not considered a characterizing feature of agency, but its importance is growing up quickly. We think that it will be
supported by most MASDKs in a short time.
129
Verif.
(V)
Method Ontology Specific.
(Sp)
(Me)
(O)
AgentBuilder
CaseLP
DESIRE
IMPACT
Zeus
Me, ì :
O, ì :
O, í :
Sp, ì :
Sp, í :
V, ì :
V, í :
V, í :
P, ì :
I, ì :
I, í :
Sc, NA:
Sc, Expr:
Ma, ì :
Ma, í :
Ma, í :
ì
ì
í
ì
í
ì
í
ì
ì
ì
ì
ì
Inform.
collect.
(I)
ì
í
ì
ì
[29]
[75, 113]
í
í
ì
Proto.
(P)
í
ì
ì
í
í
í
ì
ì
í
ì
ì
Scalab.
(Sc)
NA
200
NA
25–30
ð 100
Maint.
(Ma)
ì
í
í
ì
ì
A methodology is described for building an agent system using the MASDK.
The MASDK integrates an ontology manager with graphical interface.
Ontology definition & use studied for specific applications; no ontology manager provided.
Availability of different specification languages for specifying different MAS aspects.
Agents are specified/implemented in a unique executable specification language.
Tools to verify static (and partially, dynamic) properties of components are provided.
Formal verification has been performed on toy examples.
Verification is not addressed.
The MASDK provides tools for running a MAS prototype and visualizing its execution.
It is possible to collect and show summarizing information from the prototype execution.
No tools for collecting/showing summarizing information are provided.
The information is not available.
Applications were developed with Expr agents, and the system worked fine.
Maintenance is ensured (not necessarily for free).
Maintenance does not seem to be very lively, but it exists.
Scarce maintenance is provided to the toolkit.
Table 4.3: An evaluation of software engineering support.
130
Implementation
Language
AgentBuilder
CaseLP
DESIRE
IMPACT
Zeus
RADL
ProlAg
Sys-Des
Act-Rules
Agent Editor
Skeletons
(S)
Env.
model
(EM)
í
í
í
GUI
Utility Ag.
(UA)
[30, 11, 61]
[34]
ì
í
Debugging
(D)
ì
í
ì
í
ì
í
ì
í
ì
í
í
ì
ì
ì
í
í
ì
ì
ì
ì
RADL: object-oriented language extending the languages in [181] and [195].
ProlAg: Agents are programmed in an extension of Prolog.
Sys-Des: Agents are programmed in an (unnamed) formal specification language for system design.
Act-Rules: Ag. programmed in an (unnamed) rule-based language with obligations, permissions, etc.
Agent Editor: Zeus agents are programmed by entering the agents features through the Agent Editor.
S, ì : Many generic models for architectures, roles and tasks have been developed.
S, í : Agent skeletons are not provided, but libraries of reusable components and/or architectures
have been developed.
S, í : Neither agent skeletons nor libraries for reusable components are provided.
EM, í : The MASDK does not explicitly model the surrounding environment.
GUI, ì : The MASDK provides a Graphical User Interface.
UA, ì : The MASDK provides already-developed utility agents.
UA, í : No utility agents are provided.
D, ì : Debugging facilities are provided by the MASDK.
Table 4.4: An evaluation of implementation of agents and MAS support.
131
Mobility Distrib.
(D)
(M)
AgentBuilder
CaseLP
DESIRE
IMPACT
Zeus
M, í
M, í
D, ì
D, í
C, ì
C, í
S, í
:
:
:
:
:
:
:
S, í :
ET, í :
R, í :
R, í :
P, NA:
P, ì :
P, í :
L, NA:
L, ì :
L, í :
Concur. Security
(C)
(S)
Err.-tol. Real-time Perform.
(ET)
(R)
(P)
í
í
NA
í
ì
ì
í
í
í
í
í
í
í
í
ì
ì
í
í
í
ì
ì
í
í
ì
ì
í
[27]
í
í
í
í
í
í
NA
ì [73]
í
Latency
(L)
NA
ì
NA
í
í
The MASDK does not support agent mobility, but experiments in this direction have been done.
No experiments on mobility have been done.
Agents can be transparently distributed across a network of computers.
Agents execute on a single processor.
Agents may run concurrently.
Concurrency is only simulated.
The MASDK does not provide facilities for ensuring security, but theoretical studies on this issue
have been done.
Security is addressed neither from a practical nor from a theoretical point of view.
No support to error-tolerance is provided.
Applications requiring real-time control have been developed with the MASDK, but there is no
evidence that the MASDK is suitable in general for real-time applications.
The tool is not suitable for developing real-time applications.
Complexity issues have been deeply studied; the toolkit has an acceptable performance.
Performance is low.
Latency can be simulated. Otherwise, messages are received as soon as they are sent.
Messages may arrive with delay and in a different order than the one they were sent.
Table 4.5: An evaluation of technical issues.
132
Soft.
Platform
Integrat.
Implement.
language
AgentBuilder
JNI
S, W, L, I
Java
CaseLP
Ecl DB,
Tcl/Tk
W, L
SICS, Ecl
DESIRE
SFP
S, W, L
IMPACT
Zeus
HDB
JDBC +
S, W, L
S, W
Pro, xpce,
Java, C
Java1.2.2
Java
System
resources
133MHz P,
32 MB RAM
133MHz P,
16 MB RAM
500MHz P,
64 MB RAM
DS: 19 MB
133MHz P
Price
Evaluation
releases
F $95
Free ABP
NCA
TBN
NCA
Free CA
TBN
NCA
TBN
All Free
JNI: Modules meeting JNI.
Ecl DB: ECLiPSE DB.
SFP: Programs which communicate through sockets, files, pipes.
HDB: Various heterogeneous databases.
JDBC +: JDBC and other.
S, W, L, I platforms: Solaris, Windows, Linux, IRIX
SICS, Ecl, Pro languages: SICStus Prolog, ECLiPSE, Prolog.
133MHz P, 500MHz P: 133MHz Pentium, 500MHz Pentium
DS 19 MB: Disk Space Required, 19 MB.
F $95: From $95 for the AgentBuilder Academic Lite – Individual Edition.
NCA: Not commercially available.
Free ABP: Free evaluation of Agent Builder Pro.
Free CA: Free for course attendees.
All Free: All existing releases are free.
TBN: To be negotiated.
Table 4.6: Further technical issues (computer environment).
133
Training
(T)
Organization
AgentBuilder
CaseLP
DESIRE
IMPACT
Zeus
T, ì
T, í
D, ì
D, í
S, ì
S, í
S, í
:
:
:
:
:
:
:
Reticular Systems Inc.
CS Dept., Univ. di Genova (Italy)
AI Dept., Vrije Univ. (Nederlands)
Multinational Project
British Telecommunications plc.
Documentation
(D)
Support
(S)
ì
í
ì
í
í
í
ì
í
ì
í
í
ì
ì
í
ì
There MASDK developers organize courses/workshops for training.
No courses for training are organized.
Documentation is easy to find, read and understand. It is written for non-expert people.
Documentation mainly by scientific publications; not easy to understand for unfamiliar readers.
Information providers or mailing lists allow to get support in a very short time.
Support is provided on a “when-it-is-possible” basis.
No support is provided.
ï
Table 4.7: An evaluation of business issues.
ï
Security is addressed only by IMPACT, even if it is not implemented in the toolkit. Since,
in our opinion, mobility requires good security mechanisms for preventing damages caused
or suffered by the mobile agent, we think that the lack of security mechanisms in the
MASDKs we are considering is due to the lack of support of mobility.
ï
Error-tolerance is supported by no toolkit. The applications developed with the toolkits are
not so safety-critical and lucrative as to require error-tolerance, but this feature is surely
relevant for many applications and at least commercial MASDKs should support it.
No MASDK can be labeled as completely suitable for building real-time systems. There
are many reasons for this: agents are often described declaratively, as rule-based systems;
the rules may be executed by an interpreter (like in CaseLP) or compiled into some implementation language. In any case, the efficiency of their execution cannot be comparable
with procedures written ad-hoc for the task. Moreover, the implementation language is
often Prolog or Java, which are not suitable for real-time applications. Finally, even if
this is not stated anywhere, we think that the MASDKs we are considering have been (at
least initially) conceived to simulate real applications, rather than to implement them. The
attention that most MASDKs deserve to prototyping and simulation issues, despite to mobility, security and error-tolerance issues, confirms our opinion, as well as the results on
performance, which is usually low.
134
4.3.9
Business issues
From the results shown in Table 4.7 we may observe that universities provide scarce support,
documentation, and training on the toolkits they develop, while commercial institutions tend
to better advertise their products and provide an easier-to-read documentation. Documentation
is clearly oriented towards people having no or little experience with agents, while university
research teams presumably seem to expect that people interested in their toolkits share some
common knowledge on basic concepts.
4.4
Scenarios
In order to provide some guidelines for deciding which MASDK is best-suited for a particular
application (dealt with in Section 4.5), we first need to identify the characterizing features of
some potential application domains for MAS technology.
Since it almost impossible to consider all the areas where the MAS technology could be applied,
we confine here to analyze some fields where it has already been successfully applied. In particular, we consider the application domains from Section 4 of [110], thus complementing the
considerations there.
Our aim is to outline, for any application domain considered, the most useful features among
those we identified in Section 4.2 that agents in this domain should possess. These features can
be used as keys to search the most suitable MASDKs in Section 4.3.
The set of useful features we identify for any scenario derives from our experience. Since we are
limiting ourselves to the features introduced in Section 4.2, this set is certainly not exhaustive,
and other features may prove relevant for the scenarios which we do not consider here. Furthermore, even under this restriction, we may analyze the quite large domains only superficially. The
analysis in this section is at a general level which needs to be refined for particular scenarios, and
thus only draws a rough picture. Nonetheless, it serves as a starting point for helping a system
developer in choosing a MASDK in an application-driven fashion.
4.4.1
Industrial applications
4.4.1.1
Manufacturing
The adoption of the MAS technology in manufacturing applications has found a large consensus,
since manufacturing enterprise entities may be modeled as interacting agents, cf. [179, 180].
The simulation of the real system is then adopted as a decision support system, or to forecast
future situations and automatically issue some optimal sequence of actions. The agents may be
135
distributed, but mobility is usually not needed. The large amount of variables characterizing a
manufacturing process may lead to very different situations the agents have to cope with. For
this reason, an agent should dynamically plan its behavior according to the current situation,
since providing the agents with pre-defined strategies for all the possible situations may not be
feasible in many situations. Negotiation and coordination protocols are often adopted, and thus
support in this respect from a MASDK would be of great help. Since the final goal of the MAS
is to simulate the behavior of a real system, real-time control and high performance may be
dispensable.
4.4.1.2
Process control
The adoption of autonomous, reactive agents for process control has led to successful results
thanks to their similarity to process controllers which are autonomous reactive systems. The
major advantages of applying agent technology to process control come from the easiness of
reconfiguration and maintenance of distributed and decentralized control architectures. The
complexity of the process task can be mastered by distributed planning and execution. The
ability of agents to take decisions in a timely fashion, when necessary, and of developing longterm plans for less time-critical tasks demonstrates all its potential in this kind of applications.
A good example of the use of MASs for process control is the ARCHON (ARchitecture for
Cooperative Heterogeneous ON-line systems) project [109], described at http://www.ecs.
soton.ac.uk/˜nrj/archon/test_1.html.
4.4.1.3
Telecommunications
The current trend in telecommunications is influenced by a great number of factors. Convergence
of traditional telephony and data network worlds, blurring of boundaries between public and
private networks, and the emergence of the “information super-highway,” all contribute to the
continuous evolution of the telecommunications field. To address the emerging need for a new
technology dealing with all these issues, the agent approach seems very promising.12 In order
to cope with the issues in telecommunication, agents must have high performance and must be
reliable, secure, error-tolerant, and they should act in real-time. If a centralized agent is used
for checking the status of a network, it is necessary to know if messages are exchanged with some
latency and if they may be received in the wrong order. Negotiation capabilities may also prove
useful in order to solve conflicts among different entities interested in providing some network
service, for example, setting up a call [184]. However, the key issue for the adoption of agentbased technology in the telecommunication field is mobility. As pointed out in [23], mobile
12
See http://www.cs.tcd.ie/research_groups/aig/old_pages/iag/survey.html for a
survey on the topic, and the proceedings of the IATA (Intelligent Agents for Telecommunication Applications)
workshops [5, 4].
136
agents prove extremely effective for network management. In particular they can be adopted for
the following tasks.
ï
ï
Network Modeling: mobile code is a convenient vehicle for performing discovery tasks
[177], where “discovery” might target many goals, from finding the devices of the network
to building more detailed models of the network.
ï
Fault Management: mobile agents can be exploited for network diagnosis and for remote
maintenance of heterogeneous elements. Network diagnosis can be performed, for example, by societies of small, biologically inspired and relatively simple agents that need to
cooperate for achieving the intelligence which is needed for diagnosing network faults
[199]. Such agents can incorporate learning techniques, which may improve their future
behavior.
ï
Configuration Management: provisioning services in telecommunication networks is a
complex process, which usually involves several parties. Mobile agents can handle those
tasks in an autonomous way [22], and they can also be adopted to implement plug-andplay network components as shown in [172].
Performance Management: certain aspects of measuring the performance of networks
are difficult if a centralized server is used. Network delays make measurement precision
questionable. Instead of remotely polling network elements, a mobile agent can be dispatched to perform an analysis of the component locally, with more accurate results due to
the absence of delays involved.
4.4.1.4
Transportation systems
The distributed nature of MASs makes them suitable to model applications in the traffic and
transportation management domain which requires interaction among geographically distributed
entities. The real application is often simulated in order to understand how to properly dimension
the transportation services, or to provide a decision support system to humans. The simulation
may involve a large number of agents, thus scalability of the toolkit may have great importance.
A prototypical application in this field, where intelligent agents have been applied with valuable
results, is supply chain management. To quote [179]:
The supply chain of a manufacturing enterprise is a world-wide network of suppliers,
factories, warehouses, distribution centers and retailers through which raw materials are acquired, transformed and delivered to customers [90]. This network also,
in general, involves heterogeneous environments. [ î-î-î ]. Agent based approaches
provide a natural way to design and implement manufacturing enterprise integration and supply chain management within such environments. [ î,î-î ]. However,
137
the security problem resulting from the open architecture of agent based systems,
particularly when using the Internet and the mobile agent technology, has been recognized by both manufacturing enterprises and the researchers in this area.
A related field in which intelligent agents should also be applied is software control for intelligent
autonomous vehicles (as done, for example, in the ARGO project13 ). The basic agent attitudes
situatedness, autonomy, reactiveness and pro-activeness are certainly highly relevant for this
kind of applications. However, they center around intelligent physical agents rather than intelligent software agents, and thus other features, e.g. environmental conditions and ergonomic
capabilities of an agent, may be in the focus of interest.
4.4.2
Commercial applications
4.4.2.1
Information management
One of the most active and promising application fields for agent technology is information
management.14 Two major problems that arise in this field concern information filtering and
information gathering:
ï
ï
Information filtering deals with the identification of incoming information which is relevant and important for a user. A filtering agent, providing this service, is usually stationary
and centralized. It must be autonomous, since it must monitor the user’s actions and provide useful suggestions without being asked to do so. As pointed out by P. Maes [137],
agents of this kind must show learning capabilities in order to provide good suggestions
about interesting information by looking at the user’s behavior. The capability of interacting with the user by means of a high-level interface (speech understanding and natural
language comprehension, for example) should allow non-expert users to benefit from the
agent’s services.
Information gathering is related with finding the information which meets some requirements within a huge amount of data. In this context, mobility can prove really useful: the
agent can ship itself or a clone towards the source of information and perform its research
there without needing to fill up the user’s machine with data to be examined and which
eventually prove uninteresting. The amount of data exchanged over the network will be
usually smaller if the agent is mobile and performs its task on a remote host. Security
must be guaranteed. Also in this case learning capabilities are fundamental in order to
maintain a faithful profile of the user’s interests and needs.
13
http://www.argo.ce.unipr.it/ARGO/english/index.html
http://agents.umbc.edu/aw/Topics/Related_Topics/Information_retrieval_
and_knowledge_management/index.shtml provides more than forty links to related topics.
14
138
In both cases, the application developed is not a simulation, but it is the “real thing”. For this
reason, efficiency, robustness and error-tolerance of the chosen MASDK must be taken into
account. Depending on the particular application domain, integrating an existing software for
extracting semantic information from a text or indexing web pages, just to make an example,
could be necessary. Since the information to be filtered or merged is heterogeneous in format
and language, ontological analysis is usually necessary for achieving the task.
4.4.2.2
Electronic commerce
In principle, the automation of some commerce can be faced by using distributed, mobile,
negotiating agents. They should roam in the network to find the best offers for buying or selling
goods and then engage in a negotiation in order to establish a final price they are willing to pay
or to earn. Security issues and robustness and efficiency of code are also relevant, since the
user wants to be sure that the management of her money is delegated to a reliable agent. For
this reason, error-tolerance may be crucial in this kind of application. The existence of an
ontology of concepts is useful to allow heterogeneous agents to understand each other. Many
commercial companies are already selling products that exploit agent technology for intelligent
e-commerce.15
Another application for intelligent agents in the field of electronic commerce is Internet Auctioning [125]. At present, most business activity on the Internet is limited to publicizing the
business opportunity and catalog based sales, but it will rapidly expand to include the negotiations conducted to settle the price of the goods or commodities being traded. These negotiations
are currently conducted by human intermediaries through various forms of auctions, bidding
systems for awarding contracts, and brokerages, but these activities could be also conducted by
intelligent software agents, with a reduction of the cost and the time required for them. Research
on this topic is quite promising, see [115, 48, 47] for some applications.
4.4.3
Entertainment applications
Entertainment has been a rapidly growing market in computer applications, and led to remarkable
developments which include virtual reality and synthetic characters. One of the main issues
in recent entertainment applications is that the synthetic characters be believable. They should
show human-like emotional attitudes which allow a willing suspension of disbelief in the human
player [87]. These synthetic characters should be able to interact in real-time with the player,
they should learn from this interaction and act accordingly to the player’s preferences and habits.
Even if these applications just involve a simulation of reality, their increasingly wide and lucrative
15
See http://agents.umbc.edu/Agents_for_.../Electronic_commerce/index.shtml
for links to some of these companies and to research projects in this field.
139
marketplace obliges them to be very efficient and robust.
An application domain which can draw from technology for entertainment is training and education. In fact, synthetic characters might be used in simulations of communication and other
social processes, in a way such that the reactive behavior of a human agent in response to the
behavior of a synthetic character can be trained in a virtual environment. In particular, proper
behavior in critical and emergency situations may be improved through such training.
4.4.4
Medical applications
A major obstacle to obtaining a comprehensive view of the health status of a patient is that
the clinical data related to the patient are usually distributed across different medical centers.
Moreover, their formats range from written text and standard data base records to image data like
computer tomographies and radiographies. Agents with the ability to integrate ad-hoc software
for extracting meaningful information from the heterogeneous sources of medical information
could be adopted. They should be distributed across the medical centers, and they should be
able to cooperate for combining the different information coming from different sources, and
present a coherent view, possible in multi-media presentation. The integration of some wellestablished expert system in this MAS could lead to diagnostic capability of the system.
Other issues should be related with constantly monitoring the patient health status: a reactive
agent capable of interpreting the sensory input from a patient and deciding whether the specialist
should be informed provides a valuable help in constant monitoring of critical situations. Also
in this case, the application is not a simulation, thus robustness, reliability and error-tolerance
are relevant issues to consider.
Projects adopting the agent technology for such health-care applications are not yet very widespread.
There are a couple of prototypes, though, which have most of the features highlighted in the previous paragraph:
ï
ï
The Patient Advocate [149] is designed to be an intelligent assistant for patient-centered
health care. Residing on a home computer or special-purpose device and operating within
an extended health-care information network, the Patient Advocate will extend medical
expertise into the outpatient setting. It will have remote access to the patient’s medical
record, an understanding of the patient’s health status and history, and a model of the
patient’s interest in health-related issues, preferences for modes and contents of interaction,
etc.
In [103] an agent-based system is described which was developed to assist in managing the
care process in real-world settings. The agent’s architecture combines a symbolic decision
procedure for decision making with incomplete and conflicting information, the notions of
140
commitments and convention for managing coherent cooperation, and a set of communication primitives for agent interaction.
4.5
Application-driven MASDK selection
In this section, we discuss some interesting questions addressed in [186] about the choice of
the right MASDK for developing an application.16 The suggested answers are based on the
previously identified features of MASDKs and on our analysis of existing scenarios.
What kinds of scenarios are to be developed?
In Section 4.4, we have described different scenarios, highlighting the most relevant agents features for each of them. If the scenario to be developed falls inside an already analyzed class, it is
likely that the individuated relevant features for that class will prove relevant also for the specific
scenario. These features can help in choosing a set of suitable MASDKs for the application. Of
course, this is just a rule of thumb and it should be used as such: the application to be developed may require different features than the described ones. Answering the following questions
should help in refining the set of required features and thus the choice of the right MASDK. It
can also help to find a set of suitable MASDKs when the scenario to be developed does not fall
in any application class of Section 4.4.
What are the scenarios to be used for? For instance, is it a research activity or is there a
practical goal?
If the aim is to develop a commercial application, economic and technical issues play a very
important role on the choice of the MASDK. Users of a commercial application want the application to be robust, reliable, secure, error-tolerant and efficient. In order to assure that these
requirements are met, the application developers need to choose a well-supported MASDK developed by a commercial or a research organization which provides guarantees on the product,
on its constant maintenance and on the customer support. On the other hand, for some kinds of
research activity a less robust MASDK allowing for fast prototyping should be enough, even if
some bugs or inefficiencies may arise.
As far as the MASDKs we analyzed and compared are concerned, CaseLP is not suitable for
developing commercial applications, while AgentBuilder and Zeus seem suitable for both commercial and research activities. IMPACT may be used, besides for research, as a tool for develop16
The first seven questions are literally quoted from Sloman’s paper; the eighth one is ours.
141
ing proprietary applications. We think that DESIRE could be more profitably used for research
activity, even if it provides better technical features and more support than CaseLP.
Is the system being developed a simulation of something else, or is it “the real thing”?
When we analyzed some existing scenarios which use the MAS technology, we have already
seen that there are applications which “simulate something else”, for example manufacturing
or transportation systems, and applications which are “the real thing”, for example agents for
information filtering or for medical applications. Depending on the kind and on the use of the
application, the “simulations” may have less efficiency, less performance and less real-time
constraints than the “real things”. This is true only if the simulation is carried out as an offline process, useful to understand the real application features and to properly dimension the
involved variables, or if it does not involve critical tasks. An agent installed inside a car, which
by running a simulation tries to predict the behavior of other cars in the road and suggests which
driving actions to take, must be both efficient and do this in real-time, and must moreover be
fully reliable!
CaseLP and Zeus can be used when the system being developed is a simulation of something
else; the other three MASDKs, AgentBuilder and IMPACT in particular, can be used to develop
applications which are “the real thing” besides, of course, simulations of real applications.
To what extent are the objectives and design strategies already well understood in advance
of use of the toolkit?
If the objectives and design strategies are not already clear before choosing a MASDK, this may
mean that the software engineering process for the application development is still in its early
phases. Informal specifications are given and a deeper understanding of the design choices is
required before implementing the application. In such a situation a MASDK which provides
a clear development methodology, together with tools and languages for supporting its steps,
may prove useful. It is possible that such MASDK helps in clarifying all the issues related with
the scenario, but proves inadequate for the final implementation of the application. In this case, a
second MASDK may be used for the implementation. The choice of this second MASDK should
become easier thanks to the already performed identification of objectives and design strategies.
The tool which pays more attention to methodological aspects is probably CaseLP, even if all
the five MASDKs we analyzed face software engineering issues and the development methods
they propose can be used to clarify design strategies and choices.
142
Which is more important: ease and speed of development and debugging, or speed of execution of the developed system?
The choice of a framework which allows for “fast development and debugging” strictly depends
on the skills and preferences of the system developers. For this goal, the language which will be
used to specify or implement the agents must be chosen in accordance with the developers habits.
The effort required for learning a new language, even if it allows for faster development, may
be higher than using a language which the developer is familiar with. Determining the trade-off
for this effort depends on the size of the application and the project, and should be carefully
deliberated. Abstracting from the developer’s personal preferences, there are frameworks which
are more suitable for fast prototyping and frameworks which provide better facilities for the
MAS implementation. The first ones could be chosen if ease and speed of development and
debugging is more important than speed of execution of the development system. On the other
hand, if the system needs to be implemented in C++, for example, to meet some efficiency
requirements, the choice of the MASDK will be driven by this necessity.
All the toolkits we analyzed privilege ease and speed of development and debugging rather than
speed of execution of the developed system.
Will thorough testing and collection of performance statistics be required?
If yes, then a MASDK supporting simulation capabilities will be needed.
CaseLP, IMPACT and Zeus allow to collect and show statistical information on the application
execution, while AgentBuilder and DESIRE do not provide facilities for this task.
Is it essential that the developed system be provably correct as in some safety critical applications?
For applications like these, formal verification techniques may be needed. A MASDK should
obviously provide support in this respect, in order to prove properties of agents and MASs.
The only toolkits that provide facilities for verification are CaseLP and DESIRE; CaseLP has
been tested only on toy examples, while DESIRE provides more robust verification capabilities.
Does already developed software exist which can be reused in the new MAS? Is it already
clear how to compose it?
The answer to the first question will be often “yes,” while the answer to the second one will
be often “no.” In this situation, a MASDK which provides facilities for integrating external
143
software and for developing hybrid prototypes (namely, prototypes built up by agents which are
only specified and by already implemented software) would help. In fact, it would allow to clarify
how to integrate existing software in a new application, by testing the behavior of a simplified
prototype. If the (re)usability of external (legacy) software is not yet clear, it is very important to
build prototypes in a flexible and fast way, in order to understand whether the existing component
“fits” the new application as it is, whether it needs to be modified, or whether it can not be reused
at all.
All the MASDKs we analyzed allow the integration of different pieces of external software; in
particular, the integration of external software is a key feature of IMPACT. The suitability of one
MASDK strictly depends on the kind of software to be integrated.
4.6
Further issues and related work
In this section, we first have a look at other agent scenarios, which differ from the “engineering”
ones that we have considered in the previous sections either in nature or in spirit of the agents
involved. We then briefly address related work on MASDK classification in the literature.
4.6.1
Other agent-related scenarios
4.6.1.1
Physical intelligent agents
In this chapter, we have not dealt with scenarios where physical intelligent agents, situated within
the physical world, should be developed. 17 Physical intelligent agents represent a very important
category in the intelligent agents world. However, due to the peculiarities of problems that arise
in their development, they should be treated different from software agents, and other features
and criteria should be taken into account.
4.6.1.2
Digital butlers
Another category of agents whose development has not been discussed in detail involves socalled digital butlers [137]. Such semi-autonomous agents are very specialized on the high-level
interaction with the user for providing a limited set of sophisticated services. This high-level
interaction requires the ability of “understanding each other” by means of speech recognition
and synthesis capabilities, natural language parsing, and artificial vision. Unfortunately, none of
17
See http://agents.umbc.edu/aw/Topics/Physical_Agents/index.shtml for links to various intelligent robots sites, and [152] for an overview of the evolution trend in this field.
144
the MASDKs that we have analyzed explicitly supports these capabilities. Choosing a MASDKs
which makes it easier to integrate external packages (e.g., IMPACT) would help: plugging in an
agent the capability of understanding spoken natural language should be achieved by letting the
agent access the proper external package. Of course, this cannot be as easy as if some dedicated
component for this specific task would be available. On the other hand, a developer has greater
flexibility if among various external packages an appropriate might be chosen. Also selecting
a MASDK which supports the conceptualization of agents in terms of mental and emotional
attitudes, with deliberative and meta-management capabilities, would help: the closer the
agent model to a human being model, the easier the mutual understanding. Despite these very
rough guidelines, we think that it would not be very easy to develop digital butlers using one of
the MASDKs analyzed in Section 4.3. To our knowledge, no ad-hoc toolkits for developing such
agents are currently available.
4.6.1.3
Artificial life
Finally, a third agent-related field which should be considered is artificial life simulation [95].
Artificial life is the discipline studying the behavioral and evolutionary foundations of cognition and intelligence. The research in this field ranges over various subjects, including adaptive
behavior, coordinated perception and action, and evolutionary learning techniques (such as genetic algorithms). Artificial life agents are generally not regarded as intelligent software agents.
Nonetheless, some of the MASDKs that we have analyzed should suit this kind of simulations,
and we think it is worthwhile to spend some words on such a scenario.
Artificial life agents are always situated within a virtual environment which is explicitly modeled. For this reason, a MASDK providing a physical environment model can suite this application. The goals of agents are often implicit and they are achieved by reacting to changes
happening in the environment. There is usually no need to conceptualize the agents in terms of
mental and emotional attitudes, or to add meta-management capabilities to them. However,
the agents should be able to learn and adapt to changes in the surrounding virtual environment.
Agents communicate either explicitly or by obtaining information about other agents through
sensing the environment. If communication takes place via message passing, the communication language is usually at a low level: neither speech acts and complex message structures, nor
sophisticated coordination protocols are usually required. Since artificial life mainly involves
simulation issues, the ability of quickly setting up a simulation, collecting different statistics,
and presenting them in a clear and intelligible way is definitely more relevant than efficiency.
The simulation may be centralized, and issues such as code mobility or integration of external
software are not crucial.
145
4.6.2
Related work on MASDK classification
Important seminal contributions to the development of comparison and selection criteria for agent
tools have been made at the AAAI-98 Workshop on Software Tools for Developing Agents, and in
particular in the papers [186, 133, 176].
A. Sloman [186] poses a set of high-level question about agents tools, which we have addressed
and answered already in Section 4.5. It should be noted that the answers provided by A. Sloman
are different from ours, in particular the first one where we refer to a set of prototypical scenarios (telecommunications, medical care, etc.) for which we highlight some useful features in
Section 4.4. A. Sloman does not refer to any particular application domain. He deeply analyses
what the internal agent architecture should look like, according to the application that should
be developed; this aspect has been dealt with in our work less in detail. A. Sloman also provides some toolkit design options which are relevant according to the questions above, but does
not provide any systematic comparison among existing MASDKs. A. Sloman’s paper and our
work can be considered complementary, since they provide answers to the same questions from
different perspectives.
B. Logan’s paper [133] shares with this chapter the goal of helping the researcher and developer
to choose the most appropriate MASDK for her current problem. It outlines a heuristic mapping
from features of an agent system to toolkits. The classification criteria adopted in [133] are
divided into four groups:
1. the properties of the environment in which the agent system is embedded (observable vs
partially observable; deterministic vs non-deterministic; discrete vs continuous; singleagent system vs multi-agent system);
2. the types of actions it can perform (fallible vs infallible; action utility and cost; action
types);
3. the kind of goals that can be attributed to the agent (autonomous generation of goals;
achievement vs maintenance goals; single vs multiple goals; commitment to goals; utility
of goals; meta-goals); and
4. the kind of beliefs that can be attributed to the agent (consistent, certain, nested propositional beliefs).
B. Logan demonstrates the classification criteria on mail filtering and transportation applications.
However, no comparison of existing MASDKs according to the given criteria is described.
Clearly, while B. Logan’s aim is similar, his criteria and ours are more or less orthogonal. The
criteria in [133] are motivated by an agent architecture model, though, rather than from a whole
agent system model as stands behind our criteria. In this sense, the criteria of B. Logan and
146
ours are complementary, and may be combined in the evaluation of MASKDs in order to get a
fine-grained view of the picture.
The short paper of S. H. Schoepke [176] individuates a set of business, technical, and practical
issues which represent a commercial view of the MASDK selection problem. We followed these
guidelines when we identified the technical and business features described in Section 4.2. The
main difference between S. H. Schoepke’s work and ours is that he only deals with business,
technical, and practical issues and thus only covers a subset of the criteria we have analyzed.
Furthermore, no concrete MASDKs are analyzed.
An approach very similar to ours, but for a different purpose, is pursued by J. P. Müller in
[155]. While we want to find “the right MASDK to do the right thing,” J. P. Müller’s aim is
to find “the right agent architecture to do the right thing.” Apart from their different goals,
J. P. Müller’s approach and ours are very close: after having identified some application areas
for agent technology, he proposes a classification of agents based on the characteristics of the
applications classes identified. Based on the classification, J. P. Müller provides rules of thumb
to help a software engineer or system designer in her choice of the proper agent architecture. The
reader interested in J. P. Müller’s work may find a summary of his paper in Appendix B.4.
4.7
Conclusions
We have made an effort towards providing a methodology and general guidelines for selecting a
multi-agent system development kit (MASDK) in order to realize a multi-agent system, which
takes on an application-driven perspective. We have presented and discussed a number of criteria
and features of agent systems which are relevant to this choice, and have related them to various
common scenarios and application domains. Furthermore, different from related earlier work
in the literature, we have evaluated some available MASDKs on these criteria. In particular, we
examined AgentBuilder, CaseLP, DESIRE, IMPACT, and Zeus as representatives of different
types of MASDKs, with respect to the criteria that we have compiled.
One goal of our work is to help an application developer to understand if any of the MASDKs
considered is suitable for her application. If this turns out not to be the case, then the developer
should apply the evaluation criteria to any other MASDKs, such that a set of potentially usable
MASKDs emerges. Our experience is that this kind of selection support is barely needed, and we
have received encouraging feedback in this matter. Furthermore, our work is also of interest to
the agent researcher, since it provides a handle to classify and compare any generic agent system
tool which she develops to other such tools on a set of established features. We are aware that
our work is not the final word on MASDK selection. However, it makes a contribution to this
important issue on which further research can build upon.
Our work can be extended and augmented in various directions. An obvious direction is to extend
147
our analysis to a larger set of MASDKs which are available. The number of MASKDs available
to date is extremely difficult to assess; about 100 may be a reasonable order of magnitude, but
the number is steadily growing. In a preliminary version of this work, we attempted to scholarly
classify a large number of the existing MASDKs, but eventually had to quit since this would
have become too complex. We believe that a focused selection of a few system representing
different characteristics, as done here, is informative enough to show range of characteristics in
the classification framework.
Another direction, which is orthogonal to the previous one, is to extend and refine the set of
criteria which we fostered for MASDK characterization. Further criteria, including those considered in [133] and [186] could be taken into account. In our work, however, we have confined
to identify a core set of, as we believe, significant features for MASDK characterization. The
set of features may also increase if the range of application areas is enlarged, or if applications
are considered in more detail. We expect, however, that further extensions and refinements will
not lead to a drastic change of the set of core features that we have identified, and thus will not
render our contribution obsolete. Pursuing these and other issues is part of our future work.
Finally, as a side-effect of identifying a set of relevant MASDK features and matching them
against the ones supported by two MASDKs we are almost confident with, CaseLP and IMPACT, we decided to extend both toolkits to overcome some of their limitations. In particular, we
have extended IMPACT with error-tolerance capabilities, and we have designed D-CaseLP, a
distributed version of CaseLP. These extensions are the subjects of the following chapters and
are a relevant contribution of this dissertation: Chapter 5 completes the description of the IMPACT framework started in Section 3.5.3 and illustrates its extension with error-tolerant agents;
Chapter 6 provides a detailed description of CaseLP whose distributed extension design is dealt
with in Chapter 7.
148
Chapter 5
IMPACT and its Extension with
Error-Tolerant Agents
5.1
Introduction
In Section 3.5.3 we have introduced the IMPACT framework and the programming language
it provides to develop agents, while in Chapter 4 we have compared it with other frameworks
and we have discussed the reasons for including error-tolerance as a relevant technical feature in
MAS development. This chapter, based on [70], merges the two issues, showing how we have
extended IMPACT with error-tolerance capabilities.
We start our analysis with observing that, when dealing with frameworks for building agents that
access legacy code, interact with other entities to respond to their requests, and respect some
integrity constraints, two major problems need to be addressed.
1. First, most agent frameworks, including IMPACT, assume that the rules used are sufficient
to appropriately respond to all requests that arrive. Unfortunately, this assumption that the agent
developer covered “all possibilities” is rather optimistic and as unreasonable as an assumption
that all programs in C (or any other programming language) are bug-free. Hence, there is a
question of what to do when an agent is confronted with a situation for which it does not know
how to act.
2. Second, in the case of legacy systems, we note that the legacy system’s existing GUI and
the agent both access and update the same data. Thus, the legacy GUI may alter the agent’s state
in ways that the agent may find unacceptable.
An agent is said to be corrupted if either (i) changes caused by external entities have caused the
agent’s current state to violate one or more integrity constraints, or (ii) the agent is unable to find
149
Action Policy
Security
Messages
In
Messages
Out
Meta-Kn
N
E
T
W
O
R
K
Action
Base
Function Calls
Integrity
Constr.
AGENT
Action
Constr.
Legacy Data
Figure 5.1: Basic architecture of IMPACT agents.
a “valid”1 set of actions to execute in its current state (which may, perhaps, have been caused by
a coding error). We tackle the first problem above — the second is considered only to the extent
that nonexistence of a status set is because of an integrity constraint violation.
We present a theory, architecture and algorithms so that agents may:
1. (Recovery) recover from being “corrupted” to being “uncorrupted” and
2. (Continuity) continue to process some (though perhaps not all) requests while continuing
to recover. This is important when an agent is servicing lots of requests.
5.2
Architecture and formal definitions
In this section, we discuss how to extend the IMPACT architecture shown in Figure 5.1 to handle
the cases where agent errors cause, due to violated integrity constraints, non-existence of valid
status sets, and where an agent’s state can be autonomously updated by a third party.
5.2.1
Architecture
We assume that there is some mechanism that notifies the agent when its state has been changed
by a third party. Thus, we may assume in abstraction that every agent a receives messages of the
following forms:
1
W.r.t. the semantics of the agent we have already introduced in Section 3.5.3 and which is widely discussed in
[72, 192].
150
1. ask ñ b òôóõóöõ÷ , where agent b is asking agent a the answer to a code call atom óÎóöYø¢ù-ú¡ñûò,óÎó÷
resp. óÎóö1øúüûù-ú¡ñûò,óÎóÎ÷ , where û is a term and óõó is ground.
2. tell ñ b ò,óÎóöò ans ÷ , where agent b is telling agent a the answer ans to a code call atom
the previous form.
óÎóö
of
3. done ñ9óÎóöÜò ans ýò ans þ÷ , where óÎóö is a code call atom and ans ýOò ans þ are sets of ground
substitutions. Their meaning is that a third party (which may not be an agent) has updated agent
a’s state so that the answer to óÎóö has changed — the new answer is the old one minus the
substitutions in ans þ plus the substitutions in ans ý .
Errors occur in the agent in one of two situations. In the first, incoming messages of the form
ask ñÿ ÷ or tell ñ9ÿ÷ trigger errors as there is no valid status set associated with the incoming message.
In the second, another entity sends the agent a message of the form done ñ9ÿ÷ and the update
violates the integrity constraints of the agent, leaving it in a state which is invalid.
We deal with these two situations as follows. When an agent developer builds an IMPACT
agent, she needs to perform the following tasks in order to specify how her IMPACT agents must
recover when corrupted. She must specify
1. a set
of repair actions having some properties (see Section 5.2); and,
2. an objective function (to be maximized) used to evaluate the cost of a state. The idea is
that the agent code’s repair component will automatically use repair actions to compute a state
(which satisfies the integrity constraints or generates a valid status set).
Once the user specifies the various components of an agent and specifies the above parameters,
the IMPACT Agent Development Environment should automatically convert the agent components plus the repair components into an executable body of Java bytecode which may then be
deployed.
In order to preserve the continuity property of agents, we propose that whenever an agent’s state
is corrupted by the actions of an external agent, the agent continues to process requests for its
services as long as those requests are not “affected” by the ongoing repairs to the corrupted
part. For example, an agent managing 30 relations in a relational database may find that external
changes have corrupted one relation. In this case, queries that do not access that one relation may
be processed by the agent while the corrupted relation is being repaired.
We proceed as follows. In Section 5.2.2, we address the problem of specifying, given an agent a
and a “corrupted”2 code call atom óÎóö resp. a set of such code call atoms, what other code call
2
By “corrupted” we mean that the current result of the code call atom may lead to an inconsistency in one or more
integrity constraints. A code call atom could turn out to be corrupted either because an external entity has modified
the state in an “uncontrolled” way, or due to a “propagation” of corruptedness, as described in Section 5.2.2.
151
atoms may be potentially corrupted. The method we apply is based on a syntactic analysis of the
agent’s integrity constraints. We then introduce in Section 5.2.3 the notion of “suspiciousness”
for code call atoms. Using this notion, we are able to determine which decisions that an agent
tries to make are affected by these potentially corrupted code calls. This will be central for
recovery in Section 5.4.
5.2.2
Corrupted code call atoms
For determining the code call atoms into which corruptedness of a given set of code call atoms
X propagates via integrity constraints, we take a computational approach and define a procedure
corrcca ñ X ÷ that takes, as input, the set X of code call atoms, and that returns, as output, the set
of code call atoms in integrity constraints which are (potentially) corrupted by X. We need some
preliminary definitions. The first introduces the notion of subsumption for code call atoms.
Definition 8 (Code Call Subsumption) A set of code call atoms X is subsumed by a set of code
X is an instance of some óõóö
Y or its opposite, i.e.,
call atoms Y, written X Y, if each óÎóö
or óõóöÖø róõóö for some substitution . If X (resp., Y) is a singleton set µóõóö ,
óÎóö©ø
óÎóö
we omit parentheses and write óÎóö Y (resp., X 2óÎóö ).
Here, and in the rest of the chapter, we implicitly assume that code call atoms are standardized
apart before unification.
, where is
Example 1 (Subsumption) The code call atoms ù-ú¡ñ»öò,óÎó ÷ and úüûù#ú¡ñ òôóõó
ground, are both subsumed by ù-ú¡ñ ò,óÎó ÷ . Thus, Îù-ú¡ñ»öò,óÎó ÷ò$úüûù-ú¡ñ ò,óÎó ÷
úüûù-ú¡ñ»öò,óÎó õ÷ .
!
!
!
÷
óÎó
Îù-ú§ñ ò,óÎó ÷@ò
We next define how to associate with any code call condition , a set CCA ñ O÷ of code call atoms.
Informally, CCA ñ O÷ is the set of code call atoms occurring somewhere in .
!
!
Definition 9 (Code-Call Atoms Set (CCA ñ O÷ )) For any code call condition
atom set CCA ñ ÷ is inductively defined as follows:
!
!
, the code call
"
if ! is a code call atom '&
#%$ ( if ! is a constraint atom &
CCA !
CCA !*) ,+ CCA !.if ! is a code call condition !/)01!.For any integrity constraint ic 2 3546! , define CCA ic
CCA 3 ,+ CCA ! .
µóÎóö Îò
ñ O÷+ø
óÎóö
ò
ñ
÷
ñ
@÷ò
-î
ñ
a
÷lø
ñ 5÷
ñ
a÷
Corr ñ ic ò,óÎóöÎ÷ defined below describes the set of potentially corrupted code call atoms given that
code call atom óÎóö is corrupted.
152
Definition 10 (Corr ñ ic ò,óÎóöÎ÷ ) For any integrity constraint ic and code call atom
7 8
Corr ñ ic ò,óÎóöõ÷ø
:99
CCA ñ ic ÷
9
;
,+
óÎóö
,
CCA ñ ic ÷
CCA ñ ic ÷
óÎóö and some óÎóö
unify with most general unifier (mgu)
<
î
If óÎóö is considered corrupted, then each code call atom occurring in ic is considered corrupted
as well. Notice that unifiers and most general unifiers (mgu’s) are easily computed, since there
are no nested terms.
Example 2 (Corruptedness) Let us consider the integrity constraint
2 ' '0 ; =4 ;>
Then CCA ic ?
;> @
A BA > @ .
ic
Üù-ú¡ñ ò,óÎó ÷
ñ
÷³ø
ù-ú¡ñ ò,óÎó õ÷
ù#ú¡ñ òôóõó õ÷@î
Îù-ú§ñ ò,óÎó ÷@ò,ù#ú¡ñ òôóõó Î÷@ò-ù-ú¡ñ ò,óÎó õ÷
A '
and Corr ñ ic ò-ù-ú¡ñ
ò,óÎó ÷÷
=
BA Îù-ú§ñ ò,óÎó ÷@ò
ù-ú¡ñ ò,óÎó Î÷ò-ù-ú§ñ ò,óÎó õ÷
We may now define the procedure corrcca ñ X ÷ which computes, given a set X of code call atoms
considered corrupted, the set of all code call atoms considered corrupted as follows.
2
C2 set of code call atoms;
(
old 2
; new 2 X;
while new D old do
old 2 new;
for each ic E C, old do
new 2 new + Corr ic
;
proc corrcca ñ X set of code call atoms ÷
1.
2.
3.
4.
5.
6.
7.
ø
ø
ø
ø
óÎóö
ø
ñ
òôóõóöõ÷
endwhile;
return old.
end proc
Notice that corrcca implements a monotone, inflationary operator over the set of code call atoms,
and terminates on finite input X. Furthermore, the output can be compacted by removing subsumed code call atoms from new.
The reason why we have to iteratively apply the Corr operator in the above procedure is because
errors might be masked. For illustration, consider the following four integrity constraints:
F) 2 '0 ; =4 G ,
I > '0JI K4
,
ic-H2
icLH2
NM ;O =4 MQPSR ,
ic
õù-ú¡ñ ò,óÎó ÷ ù#ú¡ñ òôóõó Î÷
õù-ú¡ñ ò,óÎó õ÷
õù-ú¡ñ ò,óÎó
ø¢ó
Yø
ù-ú¡ñ»öò,óÎó ÷
÷
153
ic
TU2 NM ;O '0
õù-ú¡ñ ò,óÎó
WV ;X =4 MZY[V .
÷ ù#ú¡ñ
òôóõó Î÷
Suppose that in the current state all and only the following code call atoms are true:
'
In the current state ic )
\ >
ù-ú¡ñ»öò,óÎó ÷@ò5ù-ú¡ñ ò,óÎó õ÷ò5ù-ú¡ñ9óõò,óÎó õ÷ò
]_^ O and `a^
and B\ ù-ú¡ñ
ò,óÎó
÷@ò
ù-ú§ñ
X
Üòôóõó Î÷@î
is violated. Then, both ù-ú¡ñ»öò,óÎó ÷
ù-ú§ñ ò,óÎó Î÷ are potentially corrupted, since their evaluation returns a result which causes a violation of an integrity constraint;
at least one of them reflects a condition on the current state which is not coherent with the
agent’s setting. The other integrity constraints are not violated in the current state. As we know
that ù-ú¡ñ»öò,óÎó ÷ is potentially corrupted, its “coherent” result could be possibly false rather
than true. In this case, also ù#ú¡ñÍó òôóõó õ÷ should turn out to be corrupted, since in order to avoid
a violation of ic , it should return false and not true.
;>
-
'
\
We do not know whether ù-ú¡ñ»öò,óÎó ÷ or ù-ú¡ñ ò,óÎó Î÷ is the cause of the violation. Hence, we cannot
exclude that the problem is with ù-ú§ñæöò,óÎó ÷ and that it propagates to ù-ú§ñÍóõò,óÎó õ÷ . Thus, to be on
the safe side, we consider an integrity constraint (potentially) corrupted whenever it contains a
potentially corrupted code call.
L
;>
T
The integrity constraints ic and ic are not violated in the current state, and there is no reason
to suspect that the code call atoms appearing in them are corrupted, since they are completely
unrelated with the corrupted ones.
E
The soundness of this approach is expressed by the following proposition, which states that a
coherent state can be reached from an incoherent one only by changing the return values of
(some) corrupted code call atoms, and by maintaining the return values of the uncorrupted ones.
b
cedfE gb
For any agent state , let
ñ Q÷ be the set of ground instances of integrity constraints from
C which are violated in the state , and let ñ Q÷lø
CCA ñ ic ÷ be the set of code call
ic
atoms in
oñ Y÷ .
cedfE Wb
b
h,dfE gb [i lj kamon
Bh.dfE Wb ,
Proposition 5.2.1 Let Y be any set of code call atoms such that corrcca ñ oñ Y÷÷
there exists an agent state
such that
C and, for any ground code call atom
ø
differ on óÎóö only if óÎóö Y.
b bq
b .p5E
Y. Then,
and
óÎóö ,
b
b b
This means that can be turned into
by modifying the return result for some corrupted code
call atoms, and without changing the results of non-corrupted code call atoms.
bq
Proof. We define a suitable
as follows. Recall that at least one agent state exists which
satisfies all integrity constraints, and let
be an arbitrary such agent state. For any ground code
call atom óÎóö , we define
b p
bsr
ut 8 bsb r pp
ø¢óÎóö
øóÎóöò
øóÎóöò
154
&
if óÎóö Y
otherwise î
b b
Notice that
is well-defined, and differs from only on ground cca’s which are subsumed by
Y. Let ic be any ground instance of some integrity constraint in C. Then, one of the following
two cases applies:
(1) There exists some óÎóö
Y holds. Hence, for each
follows
ø
ic.
bx p
a
w
J
Hence, in both cases
b p
y
ø¢óÎóö
bsr p
h,dfE gb {z CCA ic
bq p ic.
b p
b p|E
ic. Therefore,
bx p
Y. This implies ñ Q÷
iff øóÎóö . It follows
óÎóö
bx p
ø
v
bsr p
( ; hence,
CCA ñ ic ÷ such that óÎóö Y. Then, by definition of corrcca, CCA ñ ic ÷
ø[óÎóö iff
ø[óÎóö . Since
ø
CCA ñ ic ÷ , we have
ic, it
óÎóö
CCA ñ ic ÷ it holds that
(2) For no óÎóö
ic. Similarly, we conclude that
ø
b p
E
ñ
÷8ø
ø
C, which proves the result.
ø
To continue the previous example, let us consider the state where the code call atoms
'
;>
]_^ ;O
ù#ú¡ñæöÜòôóõó ÷@ò5ù-ú¡ñ9óõò,óÎó õ÷@ò5ù-ú¡ñ
ò,óÎó
÷ò
and
Na^ aX
ù-ú¡ñ
ò,óÎó Î÷
are true and all the other code call atoms are false. This is a consistent state, and we can reach it
by simply changing the return value of óÎó such that ù#ú¡ñ òôóõó Î÷ becomes false.
B\ The implementation of corrcca ñ X ÷ which we have described is cautious and considers, in general, a larger set of code call atoms corrupted than may be semantically necessary. By a case
distinction we could get a refined picture in which a minimal set of code calls is viewed as
(potentially) corrupted. In the example above, ù-ú§ñÍóõò,óÎó õ÷ is viewed as corrupted, as well as
ù-ú¡ñ»öò,óÎó ÷ , but we were able to reach a coherent state without changing the values of these code
call atoms. Unfortunately, figuring out a minimal set of code call atoms which need to be touched
becomes quickly expensive and leads to intractability, which is a consequence of the following
result.
>
dfE
cedfE Wb
oñ Y÷ of ground and violated ground integrity conTheorem 5.2.2 Given the sets
and
straints in the current agent state , respectively, and a ground code call atom óÎóö , deciding
whether óÎóö is in some smallest (w.r.t. inclusion) set of ground cca’s X such that, by changing
results is
-hard.
values of cca’s in X only, a consistent state
b
bq
}U~
Proof. (Sketch) A variant of the satisfiability problem can be reduced to this problem. Suppose
C ø
C @ò-î,î-î¡ò Cm is a set of clauses Ci ø Li
Li
Li where each Li j is a propositional
atom a or its negation a. The software package maintains truth assignments to propositional
atoms, and the API û ö <ñ»÷ returns all variables set to true. Suppose a is a distinguished
atom such that an assignment in which a is true satisfies C iff all other atoms are false. Now
let be the agent state in which all atoms are true, and set up for each clause Ci an integrity
constraint Mñ Li ÷
a and Mñ Li j ÷lø
Mñ Li @÷
§ñ Li @÷ where Mñ Li j ÷lø|ù-ú¡ñ»öòû <ö
ñæ÷÷ if Li j ø
úüûù-ú¡ñ»öòû <ö
ñæ÷÷ if Li j ø
a. Then, some of these integrity constraints are violated by . The
cca ù-ú¡ñ»ö #òû <ö <ñ»÷$÷ belongs to some smallest change of ground code call atoms X that turns
)
b

a
y ) '0: - =46 L
a

a
)s

-x
L

r
r

155
a

b
b
b r
cedfE gb
into a consistent state iff C has a satisfying assignment in which a is false. Since deciding the
ñ Q÷ are easily constructed
latter, under the above assumption, is
-hard, and since
and
in polynomial time, the result follows.
5.2.3
}U~
dfE
Suspicious code call atoms
Changing an appropriate subset of the ground instances of corrupted code call atoms will recover
the agent to an “uncorrupted” state. This will be done in the agent cycle by a repair procedure.
However, while this repair is going on, some message(s) might arrive. Rather than simply queuing the message(s) until the agent has recovered, it should:
1. find out whether processing the message interferes with the repair process, and
2. proceed with handling it if this is not the case.
For this purpose, we introduce the notion of “affected” action atom and rule, and the notion of
“suspicious” code calls. Informally, the evaluation of an action atom is affected by a repair if it
accesses a code call atom which is possibly changed by the repair process. The deontic status
(is it permitted? forbidden? to be done? etc) of an action atom might change after the repair
is completed. This also might have an impact on other action atoms whose deontic status is
determined by running the agent program. In particular, a rule in the program that involves an
affected action atom or a corrupted code call atom might propagate affectedness to other action
atoms. The code call atoms in the body of such a rule are considered “suspicious,” since they
enable firing an affected rule.
If we treat at least all corrupted code calls as being suspicious, then any unsuspicious code call
may be safely evaluated in the current agent state, as it (i) is not affected by whatever corrupted
the state and (ii) it will not be affected by any attempt to repair the corrupted part of the state.
Hence, unsuspicious atoms may be safely evaluated even during the repair process. In particular,
if the agent processes a message ask ñ b ò,óÎóöÎ÷ , say, during which it naturally evaluates the code
call atom óÎóö , then the processing of this message does not interfere with the repair of the state
as long as óÎóö is unsuspicious. On the other hand, if óÎóö is suspicious, then processing of a
message should be delayed to avoid potentially incorrect results. A similar rationale applies
when processing messages of the form tell ñ b ò,óÎóöò ans ÷ .
As in case of corrupted code call atoms, we determine suspicious code call atoms by a syntactic
analysis of the agent program. We define a procedure suscca ñ X ÷ which takes, as input, a set X
of code call atoms which subsumes all corrupted ground code call atoms of agent a and returns,
as output, a set of suspicious code call atoms. The procedure operates in two phases: first, it
forwards the propagation of corruptedness, and then it backward propagates possible integrity
156
constraint violations that may arise after the completed repair if the same decisions depending
on óÎóö were taken.
We first define direct affectedness of an action atom by a code call atom.
B
`s; ,+
K ` @
Definition 11 (Directly Affected Action Atom) An action atom ñ t ÷ is directly -affected by
µñ 5ñ û÷$÷÷
µñ
ñ û<÷÷$÷ which
CCA ñ
CCA ñ
some code call atom óÎóö , if there exists a óÎóö
unifies with óÎóö via mgu . We say that ñ t ÷ is directly affected if it is directly -affected for some
.

B
Informally, 5ñ t ÷ is directly -affected, if the status evaluation of its ground instances involves
overlaps with the ground instances of the code call atom óõóö . If óÎóö is corrupted, the value of
the precondition of ñ t ÷ might change by the repair.

We next define affectedness of action atoms from a rule, given sets of affected action and code
call atoms.
Definition 12 (Affected Rule and Action Atom) Let
2 !x0 L ) 0
r A
0
Ln
tÿ#ÿ#ÿ
be a rule, and let AC ñ r ÷ be the set of all action atoms occurring in r. Let X and Y be sets of
action and code call atoms, respectively. Then r is -affected by X ò Y if either
Q
1. some
! ,+
CCA ñ
óÎóö
O÷
!
CCA ñ
unifies with some
O÷
óÎóö
Y with mgu , or
t F AC r is directly -affected by some Y, or
3. t F AC r unifies with some . Bt F X with mgu .
The set AFF r X Y is the union of all AC r such that r is -affected by X Y. The set
CCA r X Y is the union of all CCA r such that r is -affected by X Y. The rule r is affected
by X Y, if it is ( -affected for some . We define AFF r X Y
AC r if such a exists and
2.
ñ
÷
ñ
÷
ñ
÷
ñ
÷
ñ
ñ
ò
ò
ò
óõóö
ò
ñ
÷
÷
ñ
÷
ñ
÷
ò
÷
ò
ò
ñ
AFF ñ r ò X ò Y ÷lø
ò
ò
÷Qø
ñ
÷
otherwise.

Informally, the affectedness set AFF ñ r ò X ò Y ÷ contains the actions atoms into which the affectedness of the actions atoms in X propagates, assuming that the code call atoms in Y are corrupted.
Clearly, AFF ñ r ò X ò Y ÷ subsumes AFF ñ r ò X ò Y ÷ and takes a coarser view in which more ground
atoms are affected, which we may choose for simplicity or efficiency.

We remark that by taking the particular semantics applied to an agent program into account, the
definition of AFF ñ r ò X ò Y ÷ may be further refined. For instance, in the case of reasonable status
set semantics, only the action atom of A needs to be added to AFF ñ r ò X ò Y ÷ if 5ñ t ÷ is from the
body of r.

157

Example 3 (Affectedness) Consider an agent which manages the advertisement policy of a department store by classifying customers as high, medium or low spenders. This classification may
be used to send appropriate advertisements to customers (clearly, in practice more sophisticated
classifications could be applied). A rule in the agent program could be:
2
B A `
r Do ñ ù
ú
§ñ õ÷$÷
` 2'; A' l lP ââââ^ 0
Do ; ¡ ¢ `
ù-ú¡ñ Üòôü
ñÄú
öó
<óûñ
ó
ûÜü
µüúò ö <ò 2ò
õ÷$÷
§ñ õ÷$÷
This rule says that when a new customer is entered in the database, she is assumed to be a
high-spender customer if she has a high salary. The pre, add, and del lists of ú
are
ó
ûÜü
'; _¡ ¢
s ; '; ¡ ¢ £
¤U¥¥ ' ¡ ¢ £
¦ § ; ¡¨ ¢ £
ñú
ñÄú
ó
ñÄú
ó
ó
ûü
§ñ ÷$÷
= notin(P,oracle:all(customers)),
ûÜü
§ñ <÷$÷
= in(P, oracle:all(customers)),
ûÜü
¡ñ <÷÷
= .
(
©
ª
Some examples of -affectedness of r for pairs X Y are:
«N¬'ª®a¯°²±³¢´µa¶ª®·µ´'¸ ¹º*»¼;º¹ º¸_½f±¾'ºµ¼a·_°¨ªl¼;´¹ªÀ¿sª_Á_ÂÂaÂaÂaÂÃÃ@ÄÅ : The code call atom in Y unifies with ¯À°²±`Æª®·µ´¸ ¹ º*»¼;º¹º¸½f±B¾ºµ¼ ·_°fª®¼´¹ªÀ¿sª_Á_ÂaÂaÂÂÂaÃ]Ã under mgu ©KÇÈ C ÇS¢´ µa¶Ä .
2. «N¬'ª®a¯°²±Éº·µaÉºªo·;µ´¸ ¹º»a´¹¹'±W¸_¡¼_½·¢ºµ¼;Ã]ÃÄÅ : ÊF±BtË ÃÌÇÍ°'º;Î ¸¡¼_½·¢ºµ,±ÆÃ is directly © affected by Y since its code call atom unifies with Ï CCA ±ÐKÑÒ ±`ÊC±@½Ë Ã]ÃÃ = a¯À°²±`Æª®·µ´'¸ ¹ºK»
´¹a¹'±Ó¸¡¼½·¢ºµ¼;ÃÃ@Ä under mgu ©KÇÈ C ÇGÉº·;µaÉºÄ .
3. «vÀÔ¨¯_ÉÔ ¼_¾'º°Õº µ²±Ó¼_½º;Ö'ºÃ@Äaª×¬aÅ : the action atom unifies with the one in the head of r under
mgu ©KÇÈ C Çu¼_½º;Ö'ºÄ .
1.
The above notions help us to determine which action atoms may be affected when building the
status set of the agent. Depending on the semantics applied, however, there are different ways to
include an action status atom into a status set:
Ø
Ø
±`Ê/Ã
Under rational and reasonable status set semantics, an action status atom Op
may only
belong to a status set S if it occurs in a rule, or if it is derived by some action or deontic
closure rule (cf. Def. 3 in Section 3.5.3);
under feasible status set semantics, any Op
it occurs in no rule).
±`Ê/Ã
may be included (even in some cases where
Ù
±ÊF± Ë ÃÃ*Ú
We respect this by assuming that in the latter case, the program contains dummy rules P X
P X for every action name . Such rules can easily be added without changing the semantics
±`ÊC± Ë Ã]Ã
Ê
158
proc suscca(X: set of code call atoms
1.
2.
3.
4.
5.
6.
7.
8.
9.
Û*Ü set of code call atoms;
ÜÞÝ5ß ÞÜ Ý
ÜÞÝ|ß
à Ýá
ÜÞÝ à
â ã
ä å æ æ ÛCÝç
á ß
ÜÞÝ àZä å æ æ Û
ÜÞÝ àÌä å æ æ Û
old
;S
X; A
;
while S A old do
old
S A;
for each r
do
if AFF r A X
then
S
CCA r A X ;
begin S
A
A
AFF r A X ;
end;
endwhile;
ÜÞÝ|ß
10. B
;
11. for each
12.
13.
14.
éè åëêt Ûéâ A do
ic âyñ C æ some ò;òósâ CCA åBôCõõ'åBè,Ûaö÷ùø@úWåBè,ÛÓÛ
C ÜÞÝ5ìîí CCA å icïÛFð
ðð ò ò_óûâ CCA å icÛ¨àü CCA å icÛ unify with mgu ï
ò;ò_óyâ CCA åBô õõå{å ê ÛWÛ ö ÷xøoúgåéå ê ÛWÛÓÛ
B ÜÞÝ B àÿ
í {å Xê ï;Û ðð some
ýxþ
ð and ò;òó û â C àZü C unify with mgu ï
endfor;
ÜÞÝ
15. old
S;
16. while S B old do
17.
old
S B;
do
18.
for each r
19.
if AFF r B
then
S
CCA r B
20.
begin S
21.
B
B
AFF r B ;
22.
end;
23. endwhile;
à Ýá
ÞÜ Ý à
â ã
ä å æ ævß_ÛFÝç
á ß
ÜÞÝ àZä å æ ævß_Û ;
ÜÞÝ àÌä å æ væ ß_Û
à ò;ò_óò;òóKâ
24. return S å ø;åBè/å ê ÛWÛWÛ èéå êt Û{â
CCA B .
end proc
Table 5.1: Procedure suscca.
159
and
ýþ
of the program. We are now in a position to define how to compute a set of suspicious code call
atoms from a given set of code call atoms known to be suspicious — the procedure suscca X
defined in Table 5.1 does this.
± Ã
Informally, the suspicious code call atoms are determined as follows. In Phase 1 of the procedure,
we iteratively determine which code call atoms are affected by syntactically examining the rules
of the agent program and starting with the knowledge that the code call atoms in input to the
algorithm are known to be corrupted. The code call atoms in the body of each rule which is
found to be affected become suspicious. At the end of Phase 1, all code call atoms possibly
affected by the corrupted code call atoms are determined — as this might lead to the agent taking
actions which vary dramatically from what the agent developer originally intended, these code
call atoms may have unintended consequences that need to be addressed. Specifically, these
corrupted code call conditions might trigger unintended actions and this needs to be taken care
of.
Ê
We further have to take into account the fact that such an action might interfere with some
other (yet unconsidered) action through an integrity constraint, i.e., some effects of and occur together in an integrity constraint. In such a case, the joint execution of and might not
be possible. If, on the corrupted state, were executed, then on the repaired state could no
longer be executed if must be executed in it.
Ê
Ê
Ê
Ê
À¯ °²±N´'ªl¸a¸;´¨Á_Ã
»¯À°,±`´'ªl¸a¸´Á_Ã
¯À°²±N´'ªl¸a¸;´¨Á_Ã ¯°²± fª®¸¸;´ aÃ
Ê
We illustrate this by an example. Suppose the add list of contains the code call atom
,
while the add list of contains , and there is an integrity constraint ic
and . Assume that in the current (corrupted) state, both
are false, and that is not executed but is, where ic is not an incriminated integrity constraint
involving corrupted code call atoms. Furthermore, assume that in the repaired agent state, were
executed. Then could not be executed simultaneously unless ic would be violated. Hence, in
the repaired state, the agent would compute a status set according to which is not executed. But
, the action taken by the agent on the corrupted
this means that as for the status of state is (possibly) different from the one taken on the repaired state, which is undesired.
°·½¨¯À°²± ¨ªl¸a¸;´ aÃ
¯°²± fª®¸¸;´ aÃ
Ê
¯À°²± ¨ªl¸a¸;´ aÃ
± Ë ©Ã
To eliminate such cases, the procedure suscca computes action atoms X which could lead
to this problem. In Phase 2, it then computes action atoms which may be used in a derivation of
these action atoms. This is done by analyzing in which rules of the program such atoms occur.
means that some t B unifies with some action atom t in the body
Here AFF r B
of rule r. No suspicious code call atoms in the rule body need to be considered since in this
analysis, the effects of possible changes of the result of a code call atom are not relevant (they
have already been considered earlier in Phase 1). Nonetheless, as in Phase 1, the code call atoms
in affected rules become suspicious, since their value might contribute to deriving a problematic
action atom.
± ª ª¬aÃ
C± Ë û Ã
ÊC± Ë Ã
ÊF±BË Ã
After the back propagation, we take care of the fact that for an action atom t B the code
calls in
might be evaluated when computing the status set. Thus, all these code calls are
ÐsÑ;Òa±Ê/Ã
160
also considered to be suspicious if
Ê
was found affected.
Example 4 (Suspiciousness) Let us consider a simple agent s ag that has the integrity constraint ic from Example 2. Suppose the agent program consists of the following rules, and rational status semantics is applied:
s» Do ±`´l± Ã]Ã=Ú ¯À°²±!ªl¸a¸'Á_Ã#"$&Ç(
% ')" F ±`´+*±,'Ã]Ã ,
r -ù» F ±N´.*±,'Ã]Ã*Ú P ±N´®±,'ÃÃ ,
r /» F ±N.´ *±Ó¼;Ã]Ã*Ú ¯À°,±W¼ªl¸a¸Á_Ã"10 Do ±N´.2@Ã ,
r 3Ì» Do ±`.´ 4®Ã=Ú °·½¯À°²,± 'ªl¸a+
¸ 5Ã .
Let ÐsÑÒa±N
´ 6®!± ÃÃCÇ a¯À°²!± ªl¸a¸¯ÃÄ , ¤U¥a¥ ±`´ 6®!± Ã]Ã Ç a¯À°,!± 'ªl¸a¸¤:¯Ã@¥aÄ ¥ , and ¦ Ò§±N´6®± Ã]ÃCÇ a¯À°²±!ªl¸a¸¯Ã@Ä ,
for i 7
furthermore ÐsÑÒa±N.´ 9@Ã=Çua¯À°²,± 'ªl¸a.¸ :ÃÄ ,
±N.´ 9@Ã=Ç ¬ , and
¦ Ò§v±N.´ 9oÃ* ÇÈ8ª -aÄ ¯À,°²and
,± 'ªl¸a.¸ :aÃ@Ä , for j ; /<ª 3Ä .
Suppose we are told that ¯°²±B¾fª®¸¸'Á_Ã is corrupted, and we want to find out the suspicious code
call atoms given this information.
¸ aÃoªl¯°²±B¾fª®¸=¸ 5Ã@Ä .
As already seen, Corr ± ic ªÀ¯À°²±¾¨ªl¸a¸ÁÃÃ=ÇÈa¯À°,±B¾¨ªl¸a¸'Á_Ã@ªÀ¯À°,±B¾¨ªl¸a+
Let us call suscca ± X Ã with X Ç Corr ± ic ªÀ¯À°²±¾¨ªl¸a¸Á_ÃÃ . We iteratively augment the initial sets
S » Ç Corr ± ic ªl¯°²±B¾fª®¸¸Á_Ã]Ã and A » Ç[¬ until we reach a fixpoint.
1. In the first iteration, rule r is affected, and we add to A the action atoms ´ l± pÃ and .´ *_± qÃ ,
since ´ l± X Ã is directly © -affected for ©Ç X Ç ¾Ä by ¯À°²±¾¨ªl¸a¸'ÁÃ . The code call atom
¯À°²!± ªl¸a¸'ÁÃv© = ¯À°,±B¾¨ªl¸a¸Á_Ã from the body of r already occurs in S.
2. In the second iteration, besides rule r also rule r - is affected because .´ *_± q Ã occurs in its
head. The action atom ´ l± qÃ is added to A. No code call atom is added to S.
Phase 1 of suscca ± X Ã terminates now. For computing B, the instances of ic where X Ç p or
X Ç q are relevant, as they contain some code call atoms which occur in the add and delete lists
´ l±¾'Ã we have C Ç?a¯À°²±¾¨ªl¸a¸¯Ãoª¯À°²,± 'ªl¸a¸¯Ã > i Ç
of the action atoms in A. More precisely, for 8ª -?ª /Ä and for ´ l,± 'Ã , .´ *_!± 'Ã we have C Ç a¯°²!± 'ª®¸¸¯
Ã > i@
Ç ;8ª -?ª /Ä . Then, C Ça¯À°,±B¾¨ªl¸a¸¯Ãoª
¯À°²,± 'ªl¸a¸¯A
Ã >iB
Ç ;8ª -?ª /Ä . ¯À°²,± 'ªl¸a¸¯A
Ã >iC
Ç 8ª - unify with the code call atom in the add list
´ l± X Ã and .´ *_± X Ã respectively; they also unify with the code call atom in the delete list of
of ´ l± q Ã and .´ *± q Ã , respectively. Finally, ¯À°²,± 'ªl¸a=¸ 5Ã unifies with the delete list of .´ 2 . As far as
¯À°²±¾¨ªl¸a¸¯A
Ã >iC
Ç 8ª - , they unify with the delete list of ´ l± pÃ and .´ *± pÃ respectively. We thus
obtain B Çu*
´ ®± X Ã , .´ *_± X Ã , ´ l± qÃ , .´ *_± qÃ , .´ 2 , ´ l± pÃ , .´ *± pÃ¨Ä .
Phase 2 of suscca ± X Ã then looks for the rules which are -affected by ± B ª¬aÃ . Note that the only
way for a rule to be -affected by ± B ª¬aÃ is to contain one action status atom unifying with one
r
in B.
161
± ª¬aÃ ; nothing new is added to B; ¯À°²±!ªl¸a¸'ÁÃ is added to S.
2. r - is -affected by ± B ª¬aÃ but nothing new is added to S and B.
3. r / is -affected by ± B ª¬aÃ and ¯À°,±W¼ªl¸a¸Á_Ã is added to S. aD_± s Ã is added to B.
4. r 3 is not -affected by ± B ª×¬aÃ .
At the end of the while loop (only one iteration of this loop adds new things), EZÇ K¯À°,±B¾¨ªl¸a¸Á_Ãoª
¯À°²±¾¨ªl¸a+¸ aÃ@ª¯À°²±¾¨ªl¸a=¸ 5Ã@ª¯À°²!± ªl¸a¸'Á_Ãoª¯À°²±Ó¼ªl¸a¸Á_Ã@Ä .
The return value of S, evaluated adding the preconditions of action status atoms in B, is:
EùÇ e¯À°,±B¾¨ªl¸a¸Á_Ãoª_¯À°²±¾¨ªl¸a.¸ Ã@ª¯À°²±¾¨ªl¸a=¸ 5Ãoª_¯À°,± ªl¸a¸Á_Ãoª_¯À°²±Ó¼ªl¸a¸'ÁÃ@ª_¯°²!± 'ª®¸¸'Á_Ãoª_¯À°²,± 'ªl¸a+¸ aÃ@ª¯À°²!± ªl¸a¸.Ã@ª
¯À°²,± 'ªl¸a.¸ 5ÃÄ .
If we omit subsumed code call atoms we obtain
EùÇ s¯°²± ª®¸¸'Á_Ãoª¯À°,± ªl¸a+¸ aÃoª¯À°,±B¾¨ªl¸a.¸ 5Ãoª¯À°²,± 'ªl¸a.¸ 5ÃÄ
The following theorem states that the procedure suscca ± X Ã — where X is an input set of code
call atoms — returns as output, a set Y of code call atoms having the following property: if an
arbitrary code call atom ¸¸;´ (or its complement) is not unifiable with any code call atom in Y,
then decisions based on ¸a¸´ are not affected by ongoing attempts to repair the code call atoms
in X. That is, action decisions and resulting state changes that involve ¸a¸;´ are isolated from the
1. r is -affected by B
corrupted code call atoms, and would be the same if the state were repaired before running the
agent program.
± ªÀ¯À°,± aº ª×Õ ÿ»;¾'ºµ¼ ·_°¼;Ã]Ã
¯À°,± ª×Õ »¸´µ¼;Ã
For example, if agent a should reply to a message ask b
querying a
,: +F7F .
.
table
, it might do so if the corrupted code call atoms are restricted to
where
is a different table which is currently being repaired, provided that answering this
message doesn’t refer to
.
¾'ºµ¼ ·_°¼
¸;´µ¼
¸;´µ¼
Ù
We need some preliminary definitions. For a (fixed) agent program and a given ground code
call atom
, the influence set IS of
is the smallest set of (ground) actions that contains (1)
all actions directly affected by
and (2) all actions in AC r where r A
GH" L IJ"LKMKMKJ" Ln
is any ground instance of a rule in such that either 1 CCA G or AC r ON IS %
. The
influence set of an arbitrary code call atom, denoted P S
, is the union of all P S
where
is a ground instance of
.
¸a¸;´
¸a¸;´
¸a¸;´ û
¸¸;´
Ù
¸a¸;´
±Ó¸a¸;´Ã
¸a¸;´
± Ã
± éÃ
» Ú
± Ã
Ç ¬
±W¸a¸´ û Ã
Theorem 5.2.3 Let Q be an agent state and let Q r be a repair of Q . Let X be any set of code call
atoms such that corrcca RTSVU WQ VX X. Suppose
is a code call atom not unifiable with any
, and suppose S is a valid status set on Q disregarding YZSVU WQ .
suscca X nor
Then there exists a valid status set S w.r.t. Q r and U C such that Op [ S iff Op Z S holds
for all modalities Op and \ IS
.
¸a¸;´ û
± Ã
± :± Ã]Ã
ùÏ ¸a¸´ û
û
Ê
±Ó¸a¸;áÃ
¸a¸;´
±`ÊéÃ
û
û
Ó± ¸a¸;´ û Ã
û
:± Ã
±`ÊéÃ
ûÇ
±
± û Ã@ª Ã
¸a¸;´ û
Proof. By our assumption, some status set S exists on Q , leading to a state Q r conc Do S ]Q r .
It holds that no action t ^_P S
belongs to P S
for any ground code call
on
ÊC± Ë Ã
±W¸¸;´Ã
162
¸a¸´ û
¸¸;´ û
which Q and Q r are different. Otherwise, since
must be a corrupted code call atom,
is
subsumed by X, and by virtue of Phase 1 of suscca, it follows that
would have an instance
which is subsumed by suscca X . This is in contradiction to the hypothesis on
. Thus, the
value of a status atom Op t in the status sets S and S is computable by accessing only (1)
ground code call atoms on which Q and Q r coincide, and (2) using only other action status atoms
` P S
Op
t such that t aA
for every ground code call atom
on which Q and Q r
are different.
¸a¸;´
± Ã
±ÊF±BË Ã]Ã
Ê û ±BË û Ã
±W¸a¸´ û Ã
û ±`Ê û ±BË û Ã]Ã
¸¸;´
û
¸¸;´ û
Let AF be the set of all (ground) actions which instantiate action atoms in the sets A and B
computed by suscca X . We define the status set S by
± Ã
S û û » ÇÈ Op ±`ÊéÃb Sû > Ê\
ûû
Ã Op ±Ê/Ãb S >Êd ` AF Ä7K
That is, for affected actions we take the status from S û and for non-affected actions from S. We
show that Sû û is a Sem-status set on Q , leading to a state Q û û Ç conc ± Do ± Sû û Ã@]ª Q Ã . Since it
coincides with S on the P S ±Ó¸a¸;´Ã , the result follows.
We first show that Sû û is a feasible status set, i.e., satisfies conditions (S1)–(S4) of Def. 4 of Section
3.5.3. The key fact is that every ground instance r of a rule in Ù satisfies either AC ± r f
Ã e AF or
AC ± r ÃTN AF Ç ¬
Since S and S û satisfies all rules of Ù , it is thus clear that also Sû û satisfies each rule of Ù . Hence,
condition (S1) is satisfied. Since, for any ground action Ê , all action status atom Op ±`ÊéÃ in S û û
belong either to S or to Sû and S ª S û are feasible status sets, it is clear that S û û satisfies the conditions
AF c
r
r
r
(S2) and (S3).
As for (S4), a case analysis yields that every ground instance ic of an integrity constraint in U C is
satisfied by Q r : (i) Assume first that CCA ic contains some corrupted code call. Then all code
calls in ic are corrupted, and only actions where in g AF may change the value of any these
code calls. Thus, for no such action Do
can belong to S h S . Since Q r > ic, it follows that
also Q r > ic. (ii) Assume next that no code call in ic is corrupted, but some action i AF
specifies a change of some code call in ic. Then, by Phase 2 in procedure suscca X , we have
j AF for every action that specifies a change of some code call atom in ic. Again, since
Q r > ic it follows that Q r > ic. (iii) If neither (i) nor (ii) applies, then every code call atom in
ic is uncorrupted and may be changed only by actions d ` AF. Since (i) does not apply, ic is not
violated in state Q , and thus conc Do S ]Q > ic. It follows that Q r > ic. Summarizing, we
have that ic is satisfied in the state Q r . Hence, Q r > kU C, and thus condition (S4) is satisfied.
This shows that S is a feasible status set w.r.t. Q r .
ûû
± Ã
Ê
±`Ê/Ã
ûû Ç
Ê
û
û Ç
± Ã
û Ç
ûû Ç
±
ûû
ûû
± Ã@ª ÌÃ Ç
Ê
Ê
ûû Ç
ûû Ç
ûû
If Sem is rational status set semantics, we must further show that S is grounded, i.e., no proper
subset T l S satisfies (S1–S3). Suppose such a T exists; we shall derive a contradiction.
Assume first that T is smaller than S on the action status atoms set over actions ( ` AF. Then,
ûû
ûû
ûû
ûû
T
» ÇÈ Op ±Ê/Ãb
S
ûû
>Êg AF ÄcJ Op ±Ê/Ã) T û û >Êd ` AF Ä
163
Ê
is a smaller status set T l S which satisfies (S1)–(S3) on state Q : Indeed, note that each ground
instance of rule satisfies either AC r fe AF or AC r mN AF
, and obviously T is deontically
and action consistent and action closed. This would mean that S is not a rational status set on
Q (disregarding YZSVU WQ ), which is a contradiction to the hypothesis. Hence, T must coincide
with S w.r.t. the status of actions not in AF, and thus T is smaller w.r.t. AF. Then, the status set
± Ã
± Ã
:± Ã
ûû
Ç ¬
ûû
ûû
û » ÇÈ Op ±Ê/Ãb T û û >Êg AF Ä[c Op ±Ê/Ã) Sû >Ê( ` AF Ä
û l Sû which satisfies, by similar arguments, (S1)–(S3) on state Q . This
is a smaller status set T means that Sû is not a rational status set on Q , which is a contradiction. Thus, such a T û û can not
exist, which proves that S û û is indeed a rational status set.
If Sem is reasonable status set semantics, we must show that S û û is a rational status set of the
reduct Ù û Ç red n n ±Ùoª Q û Ã . In fact, since every reasonable status set is also rational, S û û is w.r.t. Q
a feasible status set for Ù and thus also for Ù û . Observe that the reduct preserves the key property
Ã e AF or AC ± r HÃ N AF Ç¬ . By similar arguments as above, we thus obtain that
that either AC ± r Z
Sû û is grounded for Ù û . Consequently, Sû û is a reasonable status set of Ù w.r.t. Q .
T
r
r
S
r
r
In particular, this formal result assures us that in case an agent program admits a single status set
in each state (which, e.g., is true for the IMPACT target class of regular agent programs [73]),
then the actions taken in reply to a message must also be taken if the corrupted state were repaired
before.
5.3
Agent state repair
Recall that an agent’s state is characterized by the contents of its data structures. In order for an
agent to automatically handle integrity constraint violations (or lack of a status set), we will add
a special set of data structures to each agent called repair data structures. These data structures
will have their own specialized API function calls.
5.3.1
The repair data structures
The repair data structures contain:
1. A buffer waitbuf consisting of messages that are waiting to be serviced because they involve accesses to part of the agent state that is “corrupted.”
2. A buffer repbuf consisting of corrupted code call atoms.
164
3. A buffer icbuf consisting of (instances of) integrity constraints that are currently undergoing repairs.
4. An auxiliary buffer susbuf which contains the suspicious code call atoms.
5. A set cons state consisting of all ground code call atoms true in a distinguished consistent
state.
6. A set curr state consisting of all ground code call atoms true in the current state.
The repair data structures support the following API functions:
±Ó¸a¸;´Ã
¸a¸;´
¸a¸´
suspicious
: This function takes a code call atom
as input, and returns true if
is implied by the set of code call atoms contained in repbuf under a notion of inference
fixed by the concrete implementation of the function. There are many ways to implement
suspicious
. For example, it may:
±W¸¸;´Ã
¸¸;´
2. check whether ¸¸;´
3. check whether ¸¸;´
1. check whether
is physically present in repbuf or
is an instance of a code call atom in repbuf, or
is implied by repbuf using some set of axioms and some set of
implication rules.
± Ã
suscca X : This is the procedure defined in Section 5.2.3.
±Ó¸a¸;´Ã
¸a¸´
: This function “inserts” the code call atoms corrupted by
into the repair
add repbuf
buffer, such that after insertion, suspicious
returns true if
is from suscca repbuf ,
and returns false otherwise. Its implementation depends on the one of suspicious
,
and different possibilities exist (see Section 5.4.1).
±W¸¸;´ û Ã
¸a¸;´ û
±
±Ó¸a¸;´Ã
It is important to note that the repair data structures and API calls can be included as part of the
IMPACT agent development environment (see [73, 192]) and do not need to be programmed for
each agent by the agent developer.
5.3.2
Repair action library
In addition to the repair data structures, we augment the agent via a set of “repair” actions. Each
agent has a set of actions that may be used to “repair” the agent state. The repair actions can
be implemented as a straightforward extensible dynamic link library provided by the IMPACT
agent development environment.
165
Ã
ª û
Definition 13 Suppose a is an agent and Q ]Q are two states of agent a. Let prq
action library of agent a. Then Q is said to be:
û
be the repair
prqts -reachable from Q iff QÇuQ û ,
1.
prq iý I -reachable from Q , i vxw , iff there is a state Q û û such that Q û û is prq i -reachable from
Q and there is an action Ê in prq which is executable in Q û û and the execution yields Q û .
2.
Q
State
û is prq
-reachable from Q
iff
Q
û is pyq
i -reachable
û
from Q , for some i
vxw .
Intuitively, when we say a state Q is pyq reachable from a given state Q , this means that there
is a sequence of repair actions which allow Q to be transformed into Q . The following example
illustrates this.
û
Example 5 (Simple Grid Scenario) Let us consider a simple scenario where a grid agent manages three robots moving on an n z n grid, n v 2. The repair actions pyq grid are composed by the
actions for moving a robot in one direction (north, south, east, west). We describe the
{ |
action; the others are similar. We assume that the underlying software has a
API
for querying the robot position.
É'· °·µ ½aÔ
£·¼'± · ·½'Ã
É· ° ·µ ½aÔ
Schema: ± {·|·½Ã
ÐsÑ;Ò±É'· °·µ ½ ÔÃ*Ç ¯À°²±£ª×Éaµ¯_Õ»£·¼±{·|·½Ã]Ã#" }£ K ¶~Ç % °
¤U¥¥ ±É'· °·µ ½aÔÃ=ÇÈ¯À°²±£ û ª×Éaµ¯_Õ»;£·¼'±{·;·½Ã]Ã#" £ û KÌÇG£}K[" £ û KÞ¶Ç £}KÞ¶[Á
¦ Ò§v±É· °·µ ½aÔÃ*Ç ¯À°²±£ª×Éaµ¯Õ»£·¼± {|· ·½ÃÃ
Name:
Let
Q be the state

Ýo åWåa æÛæxÜ.åÀÛWÛæ#oåWåaæÛæKÜ;.å7;ÛWÛæ#oåWåaæÛæKÜ+å+;ÛWÛ|
Then

û ÝL]åWåaæoÀÛæ;qÜ+ålÛWÛæoåWåaæÛæKÜ+å7ÛWÛæ#]åWåaæÛæ;KÜ|+å+;ÛWÛ
is prqI -reachable from

Q , while
û û Ý]åWåaæoÀÛæ;KÜ|+ålÛWÛæ#]åWåaæÛæ;KÜ|+å7ÛWÛæ#]åWåW_æoÀÛæ;KÜ+7 å+;ÛWÛ
is prqt -reachable from Q . Both Q û and Q û û are prq -reachable from Q .
166
Definition 14 A set prq of repair actions is said to be complete w.r.t. an agent state Q iff there
exists an prq -reachable state Q such that Q > U C. Furthermore, prq is said to be complete
w.r.t. an agent a, iff prq is complete w.r.t. Q for every state Q of a.
û
û Ç
Intuitively, prq is complete for an agent iff whatever possible state the agent is in, there is always
some way of executing repair actions so that a consistent (w.r.t. integrity constraints) agent state
is obtained. When an agent developer specifies her repair actions, it is critical that they be
complete w.r.t. the rest of the agent.
Example 6 (Grid Scenario Continued) Suppose that in the previous scenario an integrity constraint exists stating that a position can be occupied by at most one robot.
prq
ûû
is complete w.r.t. Q , since there exists a state ( Q ) which is prq grid -reachable from Q and
satisfies the integrity constraints. prq grid is also complete w.r.t. agent grid, it is alway possible
to move, in any agent state, the robots in such a way that they occupy three different positions.
grid
The set of repair actions in the grid example is domain-dependent. In order to provide the system
developer with already defined strategies, we propose some domain-independent sets of repair
actions which can be adopted whatever the context is. They use the repair data structures introduced in Section 5.3.1.
Example 7 (Initialized State Repair Actions prq init ) It is common that an agent a at deployment (and before anyone starts updating it) is in an initial state Q init which satisfies the integrity
constraints. We then may set cons state-set = Q init . The prq
is complete w.r.t. Q init if
we take action
to be defined as follows:
Ç _µ´Ä
µ ´
Name: µ´
Schema: ±NÃ
ÐsÑ;Ò±µ´Ã*Çua¯°²±,ª]µº¾'´'¯_µ»'¸_¡µaµ ¼ ½´;½º±NÃ]Ã#"5¯À°,±aª×µº;¾'´'¯_µ »'¸a·_°¼ ¼½´;½º±NÃ]Ã@Ä
¤U¥¥ ±µ´Ã*ÇÈa¯À°²± aª×µº¾'´'¯µ »¸¡µaµ _¼ ½´;½º±`Ã]ÃoÄ
¦ Ò§v±µ´Ã*ÇÈa¯À°²± 'ª×µº¾'´¯_µ»'¸¡µaµ ¼_½ ´;½'º±`Ã]ÃoÄ
This action can be applied in any state: we assume it is always possible to retrieve the ground
code call atoms characterizing the current state ( ,
) and the consistent state (
). Then, the current state is changed to the consistent
one.
¯°²± ª]µº¾'´'¯_µ »v¸a·_°¼ ¼_½´;½'º±`Ã]Ã
¯À°,± 'ª×µº;¾'´'¯_µ »v¸¡µaµ ¼_½´;½º±`Ã]Ã
Example 8 (Preferred State Repair Actions prq pref ) Preferred state repair actions are exactly
like the above except that the agent developer initializes the cons state-set with a state Q pref
which is known to satisfy the integrity constraints.
167
Example 9 (Rollback Repair Actions prq roll ) In rollback-based repair, at any given instant t
of time, the agent tracks its last known consistent state Q lk and sets cons state-set equal to Q lk .
This is done by the mkrepair function which identifies the proper repair actions to perform for
reaching a consistent state, and updates cons state accordingly. When integrity constraints are
violated, repairs cause the agent state to be reset to the last known consistent state. Thus, the set
of repair actions consists of the single action , which is exactly like that in Examples 7 and 8.
What is different, though, is the content of cons state, which dynamically changes during the
agent’s life cycle. This strategy is usable only when actions are reversible (e.g., an agent that
executes a F . action will probably find it impossible to recall the fax).
µ´
´
Example 10 (IC-Oriented Repair pyq ic ) This repair strategy can be applied under the condition that each integrity constraint with a comparison atom in the head has at least one code
call atom in its body. Suppose a is an agent having integrity constraints ici m i G i , where
i 7 KMKMK n . We now construct repair actions 6 for them:
ª ²ª Ä
µ´
»
µ´6
Schema: ±NÃ
ÐsÑ;Ò±µ´ 6]Ã ÇG¬
U¥¥
±µ´ 6]Ã=Ç |G Ä , if G is a code call atom, and :¥a¥ ±µ´6]Ã*Ç[¬ otherwise.
¦ Ò§v±µ´ 6]Ã=Ç ¬ , if G is a code call atom, and ¦ Ò§]±µ´6]Ã*Çu ¸¸;´Ä , for some ¸a¸;´
Name:
i
i
i
otherwise.
CCA
± Ã
i
Example 11 (IC-Repair with Protected Atoms pyq icp ) A slight variant of the preceding strategy, called prq icp , may include a list of “protected” code call atoms. The repair actions 6
are similar except that 6 ’s delete list may contain only non-protected code call atoms if G i is
a comparison atom. Prior to deployment of an agent, the system must check that each integrity
constraint with a comparison atom in the head has at least one non-protected code call atom in
its body.
µ´
µ´
The following results give us some idea about the difficulty of checking completeness. For concrete statements about complexity, we need some assumptions about the complexity of evaluating
code calls and the domains of different data types. The assumptions we make are similar to those
in the comprehensive analysis of the complexity of agent programs in [71], and request that the
size of an agent state is bounded by a polynomial in the size of the problem input (e.g., this can
be ensured by assuming that the number of arguments in code calls is bounded by a constant,
and that the number of values is polynomial in the input size), and that each code call to an agent
state can be evaluated in polynomial time. For further ramifying assumptions concerning state
changes, we refer to [71].
168
Theorem 5.3.1
1. Checking the completeness of a given set of repair actions prq w.r.t. a
given agent state Q is PSPACE-complete under the above assumptions and undecidable
in general.
2. Checking completeness of a given set of repair actions prq w.r.t. a given agent a is PSPACEcomplete under the above assumptions and undecidable in general.
Proof. (Sketch) The PSPACE upper bound is a consequence of the fact that the size of the agent
state is bounded by a polynomial. The PSPACE lower bounds are explained by the fact that
Turing machines with polynomial work space can be easily encoded to this problem. However,
checking completeness of a set of repair actions with respect to an agent is harder than checking
w.r.t. an agent state. Even if the latter is polynomial, the completeness test w.r.t. an agent might
be undecidable. This can be shown by reducing to this problem e.g. the one of deciding whether
a given SQL-query returns true over all possible instances of a relational database, which is
undecidable (cf. [1]).
An extensible library of complete sets of repair actions may easily be incorporated within IMPACT. The agent developer, once she has specified her agent’s integrity constraints, agent program, etc., can automatically select prq init ¡pyq roll ¡pyq ic repair action strategies. In this case, the
relevant repair actions may automatically be computed and filled in for the agent by the IMPACT
Agent Development Environment.
ª
5.4
ª
Error-tolerant agent cycle
In this section, we specify a solution to the problem of how an agent can recover from corrupted
states while continuing to process requests that are unaffected by ongoing repairs. Note that at
any point in time, the agent’s state may be under repair or not.
±Ã
±Ã
If it is not under repair and a message of the form ask ÿ or tell ÿ arrives, then we attempt to
process the request as usual (nothing needs to be done to account for the repairs). Two possibilities now arise. Either the message yields a valid status set, or not. In the first case, we are done.
Otherwise, we need to add the message to waitbuf and start repairing the state.
If, on the other hand, the agent’s state is being repaired, we need to check whether ongoing repairs
will interfere with processing of the current request. This can be done by checking whether the
code call atom in the message is affected by the ongoing repairs. If so, we must add the message
to the waitbuf buffer, otherwise we can process it, secure in the knowledge that repairs being
made to the agent state are not going to affect decisions depending on the current value of code
call atom. Note that the two cases where the state is not under repair, and the state is under repair
without affecting the incoming message, are both captured by the condition suspicious
. In fact, if the state is not under repair, repbuf is empty, and nothing can be “derived”
F
±W¸¸;´ ©Ã=Ç
´¹¼;º
169
¸a¸;´ ©
¸a¸;´a©
from it (in particular,
cannot be derived). Otherwise, repbuf is not empty but again
cannot be “derived” since it is not involved with the ongoing repairs. These two cases are dealt
with uniformly. We need a few simple definitions.
Ù
be an agent program. Then,
Definition 15 (Sem- and Semi-Sem-Compatible Update) Let
an agent state Q is Sem-compatible with , if a has a Sem-status set w.r.t. Q . Furthermore, Q is
Semi-Sem-compatible with , if it is not Sem-compatible but has a status set w.r.t. Q modulo
condition S 3 of a feasible status set.
± aÃ
Ù
Ù
Ù
We now show how the agent decision cycle given in [72, 192] may be modified so as to handle
the requirements of recovery and continuity. The modified decision cycle, et agent cycle (“et”
stands for error-tolerant), defined in Table 5.2 uses a special procedure mkrepair that takes, as
input, an agent state as well as repbuf, icbuf, waitbuf, and (i) assembles a list of ground action
status atoms whose serial execution is guaranteed to change the agent state to one satisfying all
integrity constraints and (ii) executes this list and causes that waitbuf is flushed, i.e., all buffered
messages are handled.
Here, icbuf contains instances of violated integrity constraints, repbuf represents (perhaps a
superset) of the set of corrupted code calls, and waitbuf contains messages which need to be
serviced/handled. The expression U C ¢ icbuf denotes the set of all integrity constraints which
are ground instances of some integrity constraint in U C but not in icbuf. Note that they can be
described at the non-ground level. Furthermore, Qd msg describes the agent state that updates
the state Q with the message msg.
Let us see how the above algorithm captures our requirements of Recovery and Continuity. Recovery is supported via (i) Steps 8-16 and (ii) Steps 19-23 of the algorithm, where (i) handles
the case when a message that yields no valid status set is encountered, and (ii) is used when an
external update causes integrity constraint violations.
Continuity is supported as well. In Step 6, execution of actions according to S can be safely done
by Theorem 5.2.3, even though possible repairs are going on. In two cases, however, processing
the message is deferred: In Step 3, when it is realized that the current state repair might interfere
with the processing of the message, and in Step 12, after it is realized that the agent program per
se violates some integrity constraints, and thus the state needs repair.
When the state has been repaired, the messages are flushed from the waitbuf buffer. That is, they
are processed one by one and new status sets are computed.
5.4.1
Different methods to implement suspicious and add repbuf
In this section, we propose a couple of alternative ways of implementing the functions suspicious
and add repbuf.
170
proc et agent cycle(a:agent;
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
Ý

:agent-state; msg:message);
å æ×ò;òóÛ
Ý å æ×ò;òóæ Û
å æ×òò_óÛ
ÜÞÝ
|£¤ for some ïyâ ans then insert å waitbuf æ msg Û ;
if suspicious å`ò;òóïÛ,Ý
if msg ask b
or msg tell b
ans then
if msg ask b
then ans id Ý
else
§¦
if some Sem-status set S w.r.t. C ¥ icbuf exists on
msg then
¦
execute the action conc , ~ Do
S
msg
else
§¦
if some Semi-Sem-status set S exists on
msg then
begin
\¦

conc , ¨ Do
S
msg ;
; repbuf
;
icbuf

for each instance ic of an ic
C s.t.
ic do
insert icbuf ic ;
for each
CCA ic do add repbuf
;
å oè
ñ
åBè,Û/â _æ
Û
û
åBè,Ûéâ û _æ
Û
ÜÞÝçß
û
û áÝ û
âsñ
å æ ûÛ
òò_óû'â
å ûÛ
`å ò;òóûÛ
insert å waitbuf æ msg Û ;

mkrepair å û æ repbuf æ icbuf æ waitbuf Û
û ÜÞÝ
ÜÞÝ5ß
å oè
14.
15.
16.
end
17. else
§¦
18. begin X ic ic
C ¥ icbuf and
\¦ msg ic ;
19.
if X
or no Sem-status set for
msg w.r.t. C ¥ icbuf exists then
20.
begin add repbuf
;
21.
for each ic X do insert icbuf ic ;

22.
mkrepair
repbuf icbuf waitbuf
23.
end
§¦
msg w.r.t. C ¥ icbuf and
24.
else compute a Sem-status set S for
\¦
execute the action conc , ¨ Do
S
msg
25. end
ÜÞÝ
Ýç
á ß
âyñ
áÝ
å`ò;ò_óÛ
å æ Û
å æ
æ æ
Û
ñ
â
å oè
åBè,Ûéâ _æ
ñ
Û
end proc
Table 5.2: Modified agent decision cycle.
171
5.4.1.1
A first implementation
As mentioned earlier, there are many ways to implement add repbuf and suspicious. One
simple way is given below. It is important to note that add repbuf and suspicious must be
mutually compatible.
_å`ò;òóÛ
proc suspicious ©
if bª susbuf then return true
else return false.
end proc
ò;òó
_å`òò_óÛ
à
å
proc add repbuf ©
repbuf
repbuf corrcca
susbuf
suscca repbuf
end proc
ÜÞÝ
ÜÞÝ
Û
å`ò;òóÛ
When inserting a message’s code call atom into repbuf, we compute all other corrupted code call
atoms (using the function corrcca defined in Section 5.2.3) and add them to repbuf. Starting
from repbuf we also evaluate the suspicious code call atoms and put them in an auxiliary buffer,
susbuf.
This procedure has the advantage that when evaluating suspicious , all that is needed is a simple subsumption check which is executable in time proportional to the product of the length
of the table and the longest code call atom stored in it. However, it has the disadvantage that
whenever a message is to be inserted, all corrupted and suspicious code calls must be computed.
Hence, insertion is an expensive and space consuming operation. The use of suspicious and
add repbuf is appropriate if we expect the agent’s state to be corrupted infrequently in comparison to the number of messages that can be processed without being concerned about corruption
of the agent state.
5.4.1.2
A second implementation
Another implementation of suspicious and add repbuf would work as follows. When a code
call atom (in a message) causes problems, then we insert the code call atoms corrupted by it
into repbuf without computing the suspicious code call atoms. Later, when a new message is
received, we explicitly determine if it is affected using the suscca function.
å`ò;ò_ó;Û
å
Û
proc suspicious«
if ª suscca repbuf then
return true
else return false.
end proc
òò_ó
å`òò_ó;Û
à
proc add repbuf«
ª repbuf then
if
repbuf
repbuf corrcca
end proc
ò;òóZá
ÜÞÝ
å`òò_óÛ
Unlike the first implementation, this one spends minor effort when inserting code call atoms into
repbuf. However, for each arriving request, it attempts to check if that request is affected by
the ongoing repairs. Thus, in using this application, we may find that repbuf is large (as lots of
172
things are inserted into it) and hence the time for checking if a given request is affected by the
ongoing repairs as in repbuf can be significant. Thus, this method is worth using if the number
of repairs is large and there are few requests.
Implementing mkrepair
5.4.2
The mkrepair procedure (it is a procedure rather than a function in programming language terminology as it has side effects) takes as input, a current agent state Q and values of repbuf, icbuf,
and waitbuf. The procedure does the following:
1. It finds a state Q new that satisfies all the agent’s integrity constraints (and in particular
repairs those in icbuf).
¬
2. It resets icbuf and repbuf to as the integrity constraints are now repaired and as the code
calls causing problems are now no longer causing problems.
3. It then iteratively reinvokes et agent cycle with the messages in waitbuf (they will no
longer trigger errors as the repairs that caused them to originally be placed in waitbuf are
now fixed).
4. It resets waitbuf to
¬
as the waiting messages are now handled.
Steps (2)–(4) above are simple to handle and understand, and hence, in the rest of this section,
we focus on step (1).
It is easy to see that Step (1) may be formulated as a classical AI planning problem. Specifically,
we have a current state and a set of goal states (those where U C is satisfied) and a set prq of
repair actions — we wish to find a sequence of (some) appropriate actions in prq that yield a
goal state. When prq is a complete set of actions, it is possible that there are multiple consistent
states that the agent can transition to. In this situation, the agent should transition to a “best”
repair state w.r.t. some state evaluation function. This again is a classical AI planning problem
[158]. Hence, in this section, we confine ourselves to specify how such a cost function to evaluate
states may be set up. Solutions already proposed in the AI literature [158] may be easily adopted
to actually find a “best” state w.r.t. such a cost function.
± Ã
Definition 16 A state evaluation function, sefa WQ , associated with agent a is one that takes as
input, an agent state Q , and provides as output, an integer.
Definition 17 A state
1.
Q
û >\
Ç U
Q
û of an agent a is optimal w.r.t. an agent state Q
C,
173
iff
Q
2.
û is prq
-reachable from Q , and
3. there is no other agent state
Qt¬ satisfying 1 and 2 such that sefa ±WQ û Ã) sefa ±WQt¬Ã .
± ÌÃ
Example 12 (Optimal Agent State) Reconsider Example 5. Informally, we define sef ®Q
to
return the sum of the Hamming distances between the positions of the three robots. We can
formalize this as follows, assuming an API function “
* ” computing the Hamming
distance between two points * of the integer plane:
ÔÕ¯ ¼½f±£ ®ª]£ @Ã
£ @ª]£
sef ±®QÌÃ=Ç ÔÕ¯ ¼_½f± {®ª¡{*oÃçÔÕ¯a¼_½f± {*_ª¡{2@ÃÔÕ¯ ¼_½f± {2_ª¡{]Ã
and that the results of the code call atoms ¯À°²± {oª×Éaµ¯_Õ»;£·¼'±µ¨ÁÃÃlª¯À°²± {*ª×Éaµ¯_Õ»£·¼±µaÃ]Ãoª and
¯À°²± {2ª×Éaµ¯Õ»£·¼±µ5Ã]Ã describe the agent state. Assume a ¯zA¯ grid and that the current agent
state is

ÝoåWåaæoÀÛæxÜ.åÀÛWÛæ#oåWåaæÛæKÜ;.å7;ÛWÛæ#oåWåW_æoÀÛæKÜ+å+;ÛWÛ|
Then,

û ÝL]åWåaæ° Ûæ;qÜ+ålÛWÛæoåWåaæÛæKÜ+å7ÛWÛæ#]åWå°æ° Ûæ;KÜ|+å+;ÛWÛ
is an optimal state w.r.t. Q , since it satisfies grid’s integrity constraint, it can be reached from
Q through a series of actions from HÉ'· °·;µ ½ Ô , É'· ¼ ·¡½ Ô , É'· ºa´'¼_½ , É· Îº¼_½Ä and, since the
robots are located on three corners of the grid, the sum of their Hamming distances is maximal.
Note that more than one state may be optimal. For example,

û û Ý]åWå°æÛæ;KÜ|+ålÛWÛæ#]åWå°æ° Ûæ;KÜ|+å7ÛWÛæ#]åWåaæÛæ;KÜ+7 å+;ÛWÛ
is another optimal state w.r.t.
Q .
The goal of mkrepair is to take a state Q that violates the agent’s integrity constraints, and to
find a sequence of repair actions which yields an optimal state Q .
û
This is easily seen to be an AI planning problem. However, there is one major difference.
Whereas in AI planning problems, the cost of a plan is typically taken to be the sum of the
costs (or some monotonic function of the costs) of the actions in the plan, in this case, the repair
actions are not being assessed any cost. Instead, each state has an associated “value” captured
by the state evaluation function, and we want to find a reachable state satisfying the integrity
constraints that has the maximal value.
We now specify how we may define the value of a state.
Definition 18 (Variable Specification) Suppose G is a code call condition involving an integer
variable X. Then X +G is a variable specification.
»
174
¢´;½ Ô
We assume the existence of a specialized package
which supports a number of standard
arithmetic functions, including a binary “
” operation on integers and a binary “
” function on points (pairs of integers).
¼_¡ ¢
ÔÕ¯ ¼½
Example 13 (Variable Specification) The expression
±=²³ ³ * O
Ü ]å ³ æ Ü +ålÛWÛö&oå ³ * æ Ü +å7ÛWÛö&oå ±²=³ ³ * !æ ´ó |µ Ü µ 7 . å ³ æ ³ *
ÛWÛ
is a variable specification of ¶7·7{{* , while
¸
»H¯À°²± {º¼+oªv¢´½ ÔC»¼¡ ¢,± ¶7·7{J{*ª¡¶7·7{*<{2oÃÃ"5¯À°,± ¸ ªv¢´½ ÔC»¼¡ ¢,± {º¼7lª¡¶7·7{2<{vÃ]Ã
¸
is a variable specification of . Their intended meaning is to specify the Hamming distance
between Robot { , {# and the sum of the three Hamming distances, respectively.
fÁ
Definition 19 (Math Code Call Conditions and Specifications) A math code call condition with
input variables X X I MKMKMK Xn and output variable X is a code call condition which is safe modulo X,3 contains X and involves only code call atoms accessing
. A math variable specification with input variables X and output variable X is a variable specification whose associated
code call condition is a math code call condition with input variables X and output variable X.
Ç oª ²ª
¢´;½ Ô
Example 14 The variable specification
¸
»w¯À°²± {º¼7®ªv¢´;½ Ô »'¼¡ ¢.±¶7·{{*ª¡¶7·7{*<{2@ÃÃ#"î¯À°²± ¸ ªv¢´;½ Ôÿ»¼¡a¢,±{'º¼+®ª¡¶7·7{2<{]ÃÃ
is a math variable specification with input variables ¶·7{{*ª#¶7·{*<{2ª#¶7·7{2?{ and output variable
V.
Definition 20 (Objective Function Specification) An objective function specification is a pair
X .G math VS I KMKMK VSn where:
« »
ªl ª ,ª
ÄÅ
1. each VSi is a variable specification of the form Xi
»
»+G
i,
and
@ªKMKMK²ª X
2. X +G math is a math variable specification with input variables X I
able X.
n
and output vari-
Example 15 (Objective Function Specification) We continue the grid example and model an
objective function which assigns states where the three robots are more distant higher values. Its
¸
¸
¸
¸
specification would look like
+G}¹<º®»®¼
E E.* E.2 , where
« » lÅ®ªl @ª ª ÀÄ
¸
G}¹<º®»®¼Çu¯°²±{'º¼+®ªv¢´;½aÔC»¼¡ ¢,± ¶7·7{¡{*ª¡¶7·7{*<{2Ã]Ã#"î¯À°²± ªv¢´;½ ÔF»v¼¡a¢,±{'º¼+lª¡¶7·{2<{]Ã]Ã
Informally, this means that after assigning X ½?¾¿¿J¿7¾ Xn values, the code call condition can be reordered such that
an evaluation from left to right is possible (see Section 3.5.3 and [72, 192]).
3
175
¸
E=Ç
¸
E+*FÇ
¸
E+2FÇ
¶·7{{*H»¯À°²± {oª×Éaµ¯_Õ »£·¼±µ¨Á_Ã]Ã#"5¯À°,±{*ª]Éµ¯_Õ
¯À°²± ¶7·7{J{À* ªÓ¢´;½ ÔC»ÔÕ¯a¼_½f± {lª¡{*oÃ]Ã@ª
¶·7{*?{H
2 »¯À°²± {* ª×Éaµ¯_Õ »£·¼±µaÃ]Ã#"5¯À°,±{2ª]Éµ¯_Õ
¯À°²± ¶7·7{*8{À2 ªÓ¢´;½ ÔC»ÔÕ¯a¼_½f± {* ª¡{o2 Ã]Ã@ª
¶·7{2?{F
»¯À°²± {2 ª×Éaµ¯_Õ »£·¼±µ5 Ã]Ã#5
" ¯À°,±{l ª]Éµ¯_Õ
¯À°²± ¶7·7{28{@ ªÓ¢´;½ ÔC»ÔÕ¯a¼_½f± {2 ª¡{] Ã]Ã8K
»`£·¼'±µÃÃ#"
»`£·¼'±µ5ÃÃ#"
»`£·¼'±µ¨ÁÃÃ#"
Intuitively, an objective function specification measures the value of agent state
1. setting vi
Ç(ÀÁ;Â X ©_>[G ©
i
i
is ground and
Q
û >(
Ç G ©aÄ ;
ÇÈ Ç
û by
i
2. grounding out the values of the Xi ’s in G math and setting v
Xi vi >ÆÈÇ i Ç n ;
true w.r.t. Q , where Ã
û
Q
Ä
Ç X Ãf©Ä>ÅG ¨Ã ©
i
is ground and is
3. returning v.
û
Example 16 (Value of the Objective Function) We continue Example 12 by considering Q , Q
and Q . Then, for Q we have that v I É vD Ê- v Ë and thus v Ì3 . For Q , instead,
we have that v I
3 vD
Í v
3 and thus v
Î . The value of Q is also 16 since
v I (3 vD Í v (3 .
ûû
Ç 'ª Ç ª
*Ç 'ª FÇ ª CÇ
5.5
5.5.1
ÌÇ ª QÇ ª QÇ
Ç
Ç
Ç
ûû
û
Related work
Proposals from the database community ÏÏÏ
Sources of information and services are often required to satisfy integrity constraints (ICs). When
the ICs are not satisfied, the source is in an inconsistent state and no interaction between the
source and its users should take place until recovery from inconsistency has been completed.
Though it is clear that excluding users from interacting with the “consistent part” of an inconsistent data source is beneficial in practice, research on providing consistent services over
inconsistent data sources has not been as widespread as one may have imagined.
Reasoning about inconsistent databases has been studied extensively in the context of “paraconsistent” databases, and in the cases of reasoning with multiple knowledge bases [25, 191, 18].
However, there was no notion of an agent decision cycle – for an agent that is a continuously
running process to steadily execute requests even while corrupted, the decision cycle must be
modified so that error-tolerant processing methods can be incorporated into the decision cycle.
This is one of the key contributions of our work.
176
An important effort to deal with consistent query answering in information systems with inconsistent ICs was done by F. Bry [44]. He proposed an approach which makes it possible to
recognize whether an answer to a query has been derived from possibly corrupted data. It exploits a local notion of inconsistency, formalized in terms of minimal logic4 . Data which raise a
violation of an IC are considered potentially corrupted. An answer which cannot be established
(i.e., which is not derivable in minimal logic) without using some potentially corrupted data is
called inconsistent. Conversely, an answer is consistent if it can be computed without using data
involved in IC violation. The paper shows that minimal logic suffices as a foundation of query
answering in positive, definite or disjunctive, deductive databases. However, the problem is not
addressed in the context of an agent system that accesses external data sources via code calls and
where rules involve actions and deontic modalities. Also, the way consistent and inconsistent
answers should be computed is not addressed. This represents a main difference between Bry’s
approach and ours, as we have provided algorithms to evaluate corrupted and affected items,
and formally proved that these items correspond to the intuitive notion of “corruptedness” and
“suspiciousness” resp. “affectedness”.
M. Arenas, L. Bertossi, and J. Chomicki [9] provide a logical characterization of consistent query
answering in relational databases that may be inconsistent with the given ICs. An answer to a
query posed to a database that violates the ICs is “consistent,” if it should be the same as the one
obtained from any minimally repaired version of the database. A method for computing such
answers and an analysis of their properties is provided: on the basis of a query Q, the method
computes, using an iterative procedure, a new query TÐ Q whose evaluation in an arbitrary
database (consistent or inconsistent) returns the set of consistent answers to the original query
Q. TÐ Q is based on the notion of residue in the context of semantic query optimization. The
soundness of the approach is proven, as well as its completeness for particular ICs (binary ICs).
Termination of computing TÐ is also guaranteed under proper conditions. A variant of the TÐ
operator is described in [50], which is proven to be sound, terminating and complete for some
classes of ICs extending those in [9]. In [10] the Annotated Predicate Calculus (APC) is adopted,
a logic where inconsistent information does not unravel logical inference and where causes of
inconsistencies can be reasoned about The inconsistent database is embedded in APC which is
then used to define database repairs and query answers. This approach has been used to help
understanding the results of [9] and to provide a more general algorithm that covers classes of
queries beyond [9]. The main difference between the approach in [9] and ours is the way how
consistent answers are evaluated. In fact, [9] rewrites a query so as to take into account the
ICs, and then evaluates the answers of the rewritten query, which are proved to be consistent
answers of the original one. What we do, instead, is to evaluate whether processing the incoming
message involves “unsafe” data: if not, we process the message as it is (as shown, this yields in
this case the same results as if the ICs would not be violated), otherwise we defer it, A further
complication in our work is that when an external request is made of an agent, the agent state
²± Ã
²± Ã
4
Minimal logic is a constructivistic weakening of classical logic defined in terms of the natural deduction proof
system by Gentzen, deprived of the absurdity rule.
177
may get modified while the repairs are going on.
As for repair of constraint violations, an interesting approach has been proposed in [136], where
basic concepts from model-based diagnosis are adopted to discover minimal sets of simultaneous
reasons for violations of (different) constraints. These reasons indicate possible repair actions
that guarantee to remove the violations. The adopted repair actions depend on the “repair strategy” which the user can choose. The proposed strategies are domain independent and range from
minimal undo or consistent completion of a violating transaction up to user interaction with the
repair process. A sound and complete algorithm for enumerating possible minimal repair transactions for an inconsistent database is also proposed. The repair strategies we have proposed share
with the ones in [136] the goal of allowing the user to choose the strategy which is most suitable
for her application from an application independent library of strategies, eventually specifying
priorities or preferences for use during the repair. The user interaction with the repair process is
briefly sketched in [136], assuming that a suitable environment exists. We think that IMPACT
can be this suitable environment: user interaction with the repair process can be easily performed
in IMPACT’s multi-agent setting.
5.5.2
ÏÏÏ and proposals from the agent community
The problems that we tackled and solved, namely how to let an agent go on working even in case
of inconsistencies within its state, and how to ensure that an agent recovers from a corrupted state
to an uncorrupted one, are in our opinion extremely relevant for the entire agent community,
as we have shown in Chapter 4. Despite to these considerations, we are not aware of agent
architectures, environments or formalisms which allow the development of error-tolerant agents
in the sense we conceive them. For this reason the current section does not deal with proposals
coming for the agent community since no such proposals exist, at least up to our knowledge.
Instead, the section illustrates some architectures for building agents and describes how they
could be extended with error-tolerant capabilities. We do not aim at being exhaustive in our
survey: other papers have already faced this issue [204]. Also, we do not aim at showing in
a rigorous way how recasting our method to existing architectures, since this would require a
great effort and a great amount of time, and this is out of the scope of this dissertation. We
just want to informally exemplify how our approach can be applied to some existing deliberative
architectures to show the flexibility of the approach and to provide suggestions to researchers
who want to extend their framework with error-tolerant agents similar to ours.
5.5.2.1
A. Rao and R. Georgeff’s BDI architecture
The BDI architecture [170] is based on the notion of agents as intentional systems [64]. It is
characterized by the following structures, as depicted in Figure 5.2:
178
Plan
Library
Beliefs
BDI
Engine
Events
Goals
Actions
Intentions
Figure 5.2: The BDI architecture.
Ø
Ø
beliefs, which represent the knowledge of the agents;
Ø
goals which are beliefs, or conjunctions and disjunctions of beliefs, which must be achieved
or tested in the current state;
Ø
plans which contain the procedural knowledge of agents. They are characterized by a
trigger; a context; a body; a maintenance condition; a set of “success actions” and a set of
“failure actions”; and
intentions, which are partially instantiated plans.
A typical BDI engine is characterized by the following cycle
1. observe the world and the agent’s internal state, and update the event queue accordingly;
2. generate possible new plans whose trigger event matches an event in the event queue and
whose context is satisfied;
3. select one from this set of matching plans for execution;
4. push the selected plan onto an existing or new intention stack, according to whether or not
the event is a (sub)goal;
5. select an intention stack, take the topmost plan and execute the next step of this current
plan: if the step is an action, perform it, otherwise, if it is a subgoal, post it on the event
queue.
An extension taking into account the tolerance to errors should modify steps 2, 3 and 5 of the
cycle in order to choose an event from the event queue only if it is safe to process it, to select a
plan for execution only if it is safe to execute it, and to select an intention stack only if the next
step in its topmost plan can be safely executed.
179
Let us suppose that some integrity constraints hold for the beliefs of the agents, and let us suppose
that such constraints are currently violated and a repair is being done on the current state to
recover to a correct one.
Ø
Ø
Step 2: when is it safe to choose an event from the event queue? We say that an event is
error-tolerant if there is at least one error-tolerant plan (see definition below) among the
plans whose trigger event matches the chosen event and whose context is satisfied.
Ø
Step 3: when is it safe to select a plan for execution? In order to decide if a plan is
error-tolerant (namely, it can be safely executed without leading to inconsistencies due to
the repairs which are being made on the state), it is necessary to evaluate the consequences
that executing it should have, before actually executing it. If pushing the selected plan onto
an existing (resp. new) intention stack, and selecting this newly modified (resp. created)
stack5 leads to executing an action which could be affected by some repair, the plan is not
error-tolerant. Giving details of which kind of actions are affected by a repair is out of the
scope of the comparison; the BDI developer can adapt our definitions of affectedness and
corruptedness in the proper way.
Even if in step 3 an error-tolerant plan is chosen, it is possible that in step 5 an intention
stack is chosen which causes problems due to the action to perform, which could interfere
with the repairs currently made. Thus, it is also necessary to consider the error-tolerance
of intention stacks.
Step 5: when is it safe to select an intention stack? Also in this case, it is necessary to
evaluate the consequences that executing the next step of the topmost plan in the stack
should have, before actually executing it. If the action to execute is potentially affected by
some repair, the intention stack cannot be selected (it is not error-tolerant). If at least one
plan can be selected for execution in step 3, that there is at least one error-tolerant intention
stack to chose (the one modified in step 3).
If at a certain moment there are no error-tolerant events in the event queue, the execution cycle
must stop until the repairs have been completed. If no repairs are currently made, all the events
in the event queue are error-tolerant. Given the definitions above, the new BDI cycle could look
like the following:
1. observe the world and the agent’s internal state, and update the event queue consequently;
if some violation of the integrity constraints occurs, start a repair procedure as a concurrent
thread;
2. if at least one error-tolerant event exists in the event queue
5
We can ignore the other intention stacks at this point, since they will be analyzed in step 5 of the cycle.
180
(a) choose an error-tolerant event from the event queue;
(b) generate possible new plans whose trigger event matches the chosen event and whose
context is satisfied;
(c) select one from this set of matching plans for execution, provided that the plan is
error-tolerant;
(d) push the selected plan onto an existing or new intention stack, according to whether
or not the event is a (sub)goal;
(e) select an error-tolerant intention stack, take the topmost plan and execute the next step
of this current plan: if the step is an action, perform it, otherwise, if it is a subgoal,
post it on the event queue.
3. else
(a) interrupt processing events and complete the repair procedure.
5.5.2.2
R. Kowalski and F. Sadri’s Unified Agent Architecture
R. Kowalski and F. Sadri [119, 120] analyze the similarities and differences between rational
and reactive agent architectures and propose a unified architecture which aims to capture both
as special cases. They employ a proof procedure as the thinking component of the agent, which
combines definitions with integrity constraints. It uses definitions, in logic programming manner, for “rational” reduction of goals to subgoals and it uses integrity constraints for reactive,
condition-action rule behaviour. The complete proof reduction procedure given in the papers is
based on the observation that in many cases it is possible to replace a goal G by an equivalent set
of condition-action rules R. The problem of controlling the reasoning process so that it works
correctly with bounded resources is also faced.
The resulting cycle governing the architecture is the following:
1. observe any input coming from the environment at time T;
2. record all input;
3. resume the proof procedure of the current goal statement by first propagating the input6;
4. continue applying the proof procedure for a total of n inference steps;
5. select an atomic action respecting time constraints;
6
The propagation of input replaces the current goal statement with a simpler one, taking into account the observed input and the integrity constraints characterizing the agent’s behaviour.
181
6. execute any such action and record the results.
The extension of such a cycle to take into account error-tolerance may appear complex, at a first
glance, since integrity constraints dynamically evolve during the execution of the cycle itself:
goal reduction replaces goal statements with simpler goal statements which have the form of
integrity constraints. In case of IMPACT agents, the integrity constraints are established once for
all, and we made the same assumption for our error-tolerant extension of the BDI architecture.
We must note that, despite the terminology overloading, R. Kowalski and F. Sadri’s integrity constraints have a different meaning than ours: they just represent a condition to be checked on the
current state, but they do not need to be necessarily satisfied. As shown in various examples from
[119] and [120], the proof procedure goes on also in case the integrity constraint is not satisfied,
and this leads to a new goal which takes into account the integrity constraint unsatisfiability.
Thus, to avoid confusion, let us suppose that a set of Static Integrity Constraints are included
in the knowledge base of R. Kowalski and F. Sadri’s agents, and let us suppose that these Static
Integrity Constraints have the same meaning of IMPACT’s Integrity Constraints: they are established once for all, and if they are violated a repair procedure must immediately start.
The Unified Agent Architecture cycle could be modified as sketched below:
1. observe any input coming from the environment at time T;
2. record all input;
3. check if the new inputs cause some violation to the Static Integrity Constraints: if they are
violated then start a repair procedure as a concurrent thread;
4. evaluate if resuming the proof procedure of the current goal statement leads to some conflict with the current repair procedure; if at least one error-tolerant atomic action (namely,
an action with no relations with the current repairs) turns out to be executable
(a) continue applying the proof procedure for a total of n inference steps;
(b) select any error-tolerant atomic action respecting time constraints;
(c) execute any such action and record the results.
else,
(a) interrupt processing inputs and complete the repair procedure.
The main difficulty in this extension is to understand if conflicts arise between the repair procedure and the proof procedure. As in the IMPACT and BDI extensions, the solution could be to
simulate in advance what should occur by going on with the proof procedure by means of some
syntactic check.
182
5.5.2.3
M. J. Wooldridge’s Computational Multi-Agent System
The architecture depicted in the fourth chapter of M. J. Wooldridge’s Ph.D. Thesis [202] is intended to be a plausible formal model that captures the key features of a wide range of classical
DAI agents and systems. The model is based on some assumptions:
Ø
Ø
agents have significant but finite computational resources;
Ø
agents have a set of explicitly represented beliefs and are able to reason about these beliefs
in accordance with the computational resources afforded to them;
Ø
beliefs are expressed in some logical language;
in addition to being believers, agents can act: in particular, they are capable of communicative actions;
Ñ finally, agents are able to revise their beliefs by means of a belief revision function.
Each agent in the system continuously executes the following cycle:
1. interpret any message received;
2. update beliefs according to previous action and message interpretation;
3. derive deductive closure of belief set;
4. derive set of possible messages, choose one and send it;
5. derive set of possible actions, choose one and apply it.
M. J. Wooldridge defines two execution models for multi-agent systems: in the synchronous one
all the agents in the system begin and complete an execution cycle together; in the more realistic
asynchronous model, where execution is interleaved, at most one agent is allowed to act at any
fixed point of time.
A naif extension of the agent cycle to ensure error-tolerance can be the following:
1. interpret any message received;
2. update beliefs according to previous action and message interpretation;
3. check if the new beliefs violate the agent’s integrity constraints: if they are violated then
start a repair procedure as a concurrent thread;
183
4. derive deductive closure of belief set: if the deductive closure does not contain beliefs
which interfere with the integrity constraints under repair, then
(a) derive set of error-tolerant messages, choose one and send it;
(b) derive set of error-tolerant actions, choose one and apply it;
5. else
(a) interrupt processing received messages and complete the repair procedure.
As usual, we are assuming that each agent has a set of static integrity constraints to be satisfied
in any state. By error-tolerant messages and actions we mean those messages and actions which
do not interfere with the current repair procedure.
5.5.2.4
M. Martelli, V. Mascardi and F. Zini’s CaseLP
CaseLP, introduced in Section 4.3.1 and fully described in the following chapter, is an experimental prototyping environment based on logic programming. CaseLP agents are characterized
by their architecture and the roles they play; there are no a priori assumptions on the agents’
architecture, except from the fact that all the agents possess a mailbox and are able to send and
receive messages. All the architectures described in this section can be simulated in CaseLP7 ,
together with their extensions with error-tolerance capabilities.
To make an example of CaseLP architecture, in Table 5.3 we show the reactive-proactive agent
cycle (“engine”, in CaseLP terminology) described in Section 6.6.2 for the reactive-proactive
architecture. In the original cycle, the agent checks if some message (Msg output), matching
with a defined pattern (Msg input), is present in the mailbox. If such a message exists, the
set Actions1 of “reactive actions” associated to one reactive rule fired by Msg output is
returned (select reactive rule(Msg output, Actions1))), otherwise, the reactive actions are unified with the empty set. In any case, one set of “proactive actions” which can
be performed in the current state is obtained (select proactive rule(Actions2)). A
choice between the actions to perform is made and the chosen actions (Actions) are executed.
Table 5.4 shows how this cycle can be improved to cope with error-tolerance. If a message is received, besides finding out the set of reactive actions to be performed, it is also necessary to check
if the received message violates some integrity constraints (check IC viol(Msg output,
Violation)). If this is the case, a repair procedure is started (start repair procedure).
We may think that this goal launches another thread of execution, in such a way that the repair
7
As an example, [30] describes the implementation of the BDI architecture in CaseLP.
184
engine :async_receive_one(Msg_input, Msg_output),
(Msg_output == no_message ->
Actions1 = [];
select_reactive_rule(Msg_output, Actions1)),
select_proactive_rule(Actions2),
choose(Actions1, Actions2, Actions),
execute(Actions).
Table 5.3: Engine for a reactive-proactive CaseLP agent.
procedure is executed concurrently with the successive actions the engine performs8 . After the
set Actions of actions to perform has been determined, it is necessary to check if they interfere
with the current repairs (check IC interf(Actions, Interference)). If no interference is discovered, it is possible to go on executing actions, otherwise the repair procedure
must be completed.
5.6
Conclusions
Software agent systems that build on top of legacy software in a principled way, and that support
automatic coupling of simple and complex actions to changes in their environment, have a wide
variety of applications in many different fields (see Section 4.4). Nonetheless, it is dangerous to
assume that just because agents are prototyped using a declarative language such as in IMPACT
they will be free of errors. Prolog programs over the years have not been error-free. The history
of programming has shown that bugs in code must always be accounted for.
In an IMPACT based agent system, and for that matter, in any agent system that builds on top
of legacy code, bugs may arise for one of several reasons. First, the agent developer may have
written rules that do not account for all possible states of the agent that arise. Second, the agent
may not be in full control of its state — this is true in legacy applications where the agent is just
one vehicle to access the legacy application’s state. Third, the legacy code on top of which the
agent is being built may itself have bugs, causing unexpected agent states to arise.
With our work we have taken a modest first step toward addressing this extraordinarily difficult
problem. Specifically, we have proposed for the first time (to our knowledge) an agent decision
algorithm that has two good features. First, it incorporates a method for the agent to recover from
8
If the repair is not executed concurrently with other actions, it makes no sense to check whether the actions to
take interfere with the ongoing repairs. Execution of concurrent threads is not supported by the CaseLP environment but it will become a feature of D-CaseLP, see Section 7.
185
engine :async_receive_one(Msg_input, Msg_output),
(Msg_output == no_message ->
Actions1 = [];
(select_reactive_rule(Msg_output, Actions1),
check_IC_viol(Msg_output, Violation))),
(Violation == yes ->
start_repair_procedure;
true),
select_proactive_rule(Actions2),
check_IC_interf(Actions, Interference),
(Interference == yes ->
complete_repair_procedure ;
execute(Actions)).
Table 5.4: Engine for an error-tolerant reactive-proactive CaseLP agent.
a “corrupted” state to an “uncorrupted” one. Second, it allows the agent to continue processing
requests during such a recovery/repair process, as long as such requests are unaffected by the
ongoing repairs. Our contribution is admittedly not a panacea for all problems involving bugs
in agent programs. It handles the case when agent’s don’t have status sets due to violation
of integrity constraints. Such violations may occur because third parties are manipulating the
agent’s state without the agent having any veto on such updates. It also arises when the agent’s
rules are not adequate to deal with such IC violations. However, these scenarios only represent a
small microcosm of the space of errors that can arise when agents are programmed. This forms
a rich avenue for future research.
Even the results we have described in this chapter can be widened in future work. For instance,
rather than considering action atoms as affected, we could view action status atoms as affected,
and determine suspicious code call atoms on the basis of a syntactic analysis of the agent programs similar as described in this chapter. Due to the interplay of the various semantics components of feasible status sets including deontic consistency, action closure and integrity constraints, such a refined approach that provides significant improvement over the one presented
here is much more involved. We plan to study this further in future work.
186
Chapter 6
CaseLP: a Logic-Based Environment for
MAS Prototyping
6.1
Introduction
CaseLP (Complex Applications Specification Environment based on Logic Programming) is
an experimental environment for building prototypes of complex and distributed applications
modeled as MAS. Its main aim is to implement part of the concepts supported by the ARPEGGIO
project [60]; in particular, CaseLP aims at providing a framework for integrating heterogeneous
specifications of agents, both executable and non-executable ones, within the same executable
piece of code. CaseLP represents our first research step towards a real environment for MAS
specification and prototyping. It is a logic-based framework, since it allows to specify agents
using logic languages (Ò hhf ) and its implementation is based on Prolog. Nevertheless, some
efforts have been made to go towards more widely used specification languages, and work for
integrating UML in the environment has been recently done.
This chapter synthesizes the results we obtained from 1997, the year the CaseLP project started
at the Computer Science Department of Genova University, to the end of 2000, the year we
decided to renew the CaseLP environment and we started to design D-CaseLP. The contributions discussed in this chapter have been described in various papers [140, 141, 142, 145, 30,
29, 58, 59, 144, 208, 143, 8, 139, 138] and have been collected in an organic form in F. Zini’s
PhD dissertation [207]. With respect to previous papers and documents on CaseLP, this chapter
aims at describing, in a limited space, all the issues which were involved in the project during
these years; for this reason it organizes all the CaseLP-related concepts in a clear and synthetic
fashion. It also includes some recent refinements described in [61] which contains seminal ideas
exploited in the design of D-CaseLP.
187
6.2
6.2.1
CaseLP agent model
A computational perspective ÓÓÓ
From a computational point of view, the agents we model in CaseLP are characterized by
Ñ a state,
Ñ a program and
Ñ an engine.
The components containing the state and the program of an agent, together with the engine
operating on them, determine the agent’s architecture.
The state includes data that may change during the execution of the agent. For example, the state
of a BDI agent contains its beliefs, goals, intentions and event queue.
The program contains information that does not change during the execution of the agent. For
example, the program of a BDI agent is determined by its plans; they describe the actions the
agent should take according to its current beliefs and the content of the event queue. The actions
an agent is able to perform may be very different, but usually an agent is at least capable of
updating the state and interacting with the environment and with other agents in the MAS by
sending and receiving messages.
Lastly, the engine controls the execution of the agent. We recall the typical BDI engine introduced in Section 5.5 which is characterized by
1. observe the world and the agent’s internal state, and update the event queue accordingly;
2. generate possible new plans whose trigger event matches an event in the event queue and
whose context is satisfied;
3. select one from this set of matching plans for execution;
4. push the selected plan onto an existing or new intention stack, according to whether or not
the event is a (sub)goal;
5. select an intention stack, take the topmost plan and execute the next step of this current
plan: if the step is an action, perform it, otherwise, if it is a subgoal, post it on the event
queue.
188
State
Mailbox
Program
Engine
Figure 6.1: General CaseLP agent architecture.
The engine and the program belong to different abstraction levels: the engine is a meta-interpreter
for the program and the data (state) on which the program operates. The behavior of the agent
is determined by the application of the agent program on the agent state by means of the agent
engine. The content of the program and state components will be expressed using some architecture dependent object language for which the engine provides an interpreter. We do not
commit to any object language, since our model aims at being as general as possible. The only
assumption we make is on the state components: we assume that among them there is a mailbox1
which allows asynchronous communication among agents and between the agents and the external environment. Every CaseLP agent has an architecture which specializes the one depicted in
Figure 6.1.
1
We say that a mailbox must be included among the architecture’s data structures, but it should be an event queue,
like in the BDI architecture, or any other structure which allows to queue and get messages (or, more in general,
events).
189
6.2.2
ÓÓÓ and a descriptive perspective
From a descriptive point of view, an agent is characterized by two domain independent orthogonal features2 :
Ñ its architecture and
Ñ its roles.
In the previous section we have already introduced our definition of architecture. It is determined
by both the agent internal components, containing the agent’s program and state, and the control
flow among them, which we call the engine of the architecture. Paraphrasing N. Wirth’s famous
equation,
Algorithms + Data Structures = Programs
we could say that
Engine + Internal Components = Architecture
To make an example, a BDI architecture is determined by a repository of beliefs, a set of intention
stacks, an event queue, a library of plans and a set of goals (the internal components) and by the
control flow shown in the previous section (the engine).
The architecture is a domain independent feature: agents with the same architecture can be
adopted in very different domains. For a comprehensive review on architectures and their applications the reader may see M. J. Wooldridge and N. R. Jennings’ survey [204].
As far as roles are concerned, for E. Kendall the notion of an agent’s role
focuses on the position and responsibilities of an object within an overall structure
or system [117].
For P. Ciancarini and M. J. Wooldridge [53]
ÔMÔMÔ a role is defined by four attributes: responsibilities, permissions, activities, and
protocols.
2
This characterization can be also found in [132].
190
In our CaseLP descriptive model a role definition is definitely simpler than the ones we quoted,
since it is characterized by the set of services required and provided by an agent playing that role:
Required Services + Provided Services = Roles
To make an example, an agent playing the role of a broker in an agent community may provide
the services register and accomplish-this-task and may require no services (see Section 6.3.1 for
a more interesting characterization of a broker agent). An agent playing the role of a seller, may
provide the sell service and may require the register service to the broker in order to advertise the
goods it sells. A service is identified by its name, and an informal description of the meaning of
that string should be provided. This characterization of roles, though being very simple, allows
us to capture the idea that an agent playing a role must provide services to the other agents; in
order to provide these services, the agent will probably need to use (require) services provided by
them, according to the role it plays. Since an agent is an autonomous entity, it may always decide
that, under particular conditions, a service cannot be provided. For example, the seller role is
characterized by selling goods, but this can be done only if there is a sufficient amount of stuff,
and if the price proposed by the buyer is acceptable. CaseLP offers the means for specifying
roles as well as conversation protocols which may be followed to require and provide services.
Sections 6.5.3 and 6.5.4 describe the languages CaseLP supports for this purpose and show the
example of a distributed marketplace application.
Agent roles, like agent architectures, are domain independent features: a broker agent is always
a broker agent, no matter the application domain it works in. Let us think of a seller agent which
provides the sell service. This is a domain independent service, since it abstracts from the sold
stuff and just deals with the ability of the agent to sell something. Clearly, one should think
of very specific roles such as green-old-cars-seller, providing the sell-only-green-and-old-cars
service. While the seller role can be reused in many different application domains, the green-oldcars-seller cannot. All the literature on roles, which is proliferating in the last years, concentrates
on general and reusable roles which can be used in many domains; in our work we adhere to this
domain independent characterization. Note that roles and architectures are orthogonal concepts:
the same role can be played by agents with different architectures, and agents sharing the same
architecture can play different roles.
Agents characterized by their architecture and the roles they play can be described in CaseLP
at different levels of abstraction, following a methodology which guides the developer from
the informal description of the MAS to the development of a working prototype. In each step
of the method, the user can adopt the most suitable tools and languages among the provided
ones. The next sections deal respectively with these three topics: hierarchy of abstraction levels,
development methodology and tools and languages provided by CaseLP.
191
Subsumption
Bdi
Broker
Seller
Abstract architectures
Reusable
knowledge
Buyer
Bdi-1
Bdi-2
Subs-1
Roles
Concrete architectures
Bdi-2
fruit
buyer
Bdi-1
market
broker
Subs-1
fruit
seller
Domain
specific
knowledge
Agent classes
Broker
Apples
buyer
Apples
Seller
Pear
buyer
Pears
seller
Agent instances
Figure 6.2: Abstraction hierarchy.
6.3
Hierarchy of abstraction levels
In order to ensure modularity, flexibility and reusability in the conceptualization and definition
of heterogeneous agents, we have introduced an abstraction hierarchy, illustrated in Fig 6.2 by
means of an example. It is possible to note two main horizontal layers of knowledge in this hierarchy: the domain independent reusable knowledge and the domain specific one. The reusable
knowledge is related with the two orthogonal concepts introduced in the previous section: architectures and roles. Our architecture model is quite sophisticated, as it will be clear by the
following paragraphs and by Appendix C.1 where some examples are documented. On the other
hand, we have already noticed that the role model is quite trivial in this development stage of
CaseLP: it has become a central issue in the D-CaseLP framework whose design is described
in Chapter 7.
6.3.1
Agent role
A role is characterized by the required and the provided services. As an example, let us consider
the broker role described in [100]. This role allows decoupling of the client and service-provider
(“servers” in the following) by accepting requests from a client, farming out the work to a willing
and available server, and returning results to the client. A broker does not require any service,
and provides the following ones:
192
State
Program
Mailbox
Beliefs
Plans
Goals
Intentions
Engine
The state and program
components are specified
quite informally
Figure 6.3: Abstract BDI architecture.
Ñ register, unregister: provided to both clients and servers.
Ñ accomplish-this-task: provided to clients which want a task to be accomplished.
Ñ assign-me-tasks-to-be-accomplished: provided to servers which want to perform tasks for
other agents.
Clearly, more information could be provided in order to have a complete role model: the protocols associated with the role, its responsibilities, how a role specializes an existing one, how it
aggregates two or more roles, and so on.
6.3.2
Abstract architecture
The abstract architecture defines the components of the architecture and the basic structure of
the engine. It is possible to provide guidelines for the realization of any “macro-instruction”
(procedure) in the engine without necessarily giving all the implementation details.
As an example (Figure 6.3), an abstract architecture for a BDI agent should be characterized by
Ñ a component for beliefs,
Ñ a component for goals,
Ñ a component for intentions and
193
Ñ a component for plans.
We do not need to explicitly say that an event queue is needed, because our general agent architecture already contains this kind of structure, which we named the mailbox. Moreover, at this
stage we do not need to assign a type to the components characterizing the architecture, since
these details will be provided when implementing the concrete architecture.
The engine of the abstract BDI architecture has been described in the previous section. At this
stage we can, for example, specify that the
select one from this set of matching plans for execution
macro-instruction is refined in
select the plan which requires the minimum number of actions to
be completed,
without providing further details.
6.3.3
Concrete architecture
A concrete architecture is defined by starting from an abstract architecture:
Ñ each component is assigned a type chosen among the ones the chosen implementation
language provides;
Ñ each macro-instruction of the engine is implemented.
For example, it should be the case that each intention in one implementation of the BDI architecture, say bdi-1, be a stack of strings, and the intention component be a set of such intentions.
Another concrete BDI implementation, bdi-2, could implement the intention component as a
list of stacks of tuples: despite the differences between this architecture implementation and the
previous one, both of them are BDI architectures and it is reasonable that both of them specialize
the same abstract architecture. Besides differing in the type assigned to the architecture components, bdi-1 and bdi-2 could also differ in the engine implementation, which can specialize the
specification given in the previous abstraction level in different ways.
6.3.4
Agent class
A class (Figure 6.4) is defined by instantiating the components in the concrete architecture which
contain the program of the agent, according to the role the class plays. A class can play one or
more roles; this means that the instances of that class (the agents belonging to that class) have the
potentiality to play these roles, not that they will necessarily play all of them during their life. It
194
State
Program
Mailbox
Beliefs
Plans
Goals
Intentions
Engine
The program components
are filled with the domain
specific knowledge, taking
into account the roles played
by the agents in the class
Figure 6.4: A class of BDI agents.
depends on the internal evolution, which in turn depends on the overall MAS evolution, whether
an agent will switch form a role to another one during its life or not.
Continuing the fruit market example, the application to be developed could need a broker agent
adhering to the bdi-1 implementation of the BDI architecture, which operates in the context of
a fruit market. The corresponding class will be characterized by the bdi-1 plans describing the
behavior of a fruit marker broker agent (see Figures 6.2 and 6.4).
The implementation of a BDI fruit marker broker agent may be different from the implementation of a Subsumption [40, 41, 42, 43] audio-video entertainment broker agent, both due to
architectural differences and the different domains where the agents operate. For this reason,
the implementation of a class is a domain dependent task. Any agent class playing a role must
adhere to the specification of that role, namely, it must require and provide the services specified
by the role. In other words, if we consider the specification of a role as an interface definition, a
class playing that role must implement the role interface. The difference among classes playing
the same role is in the way the services are required/provided, namely, is in the way the interface
is implemented.
6.3.5
Agent instance
Starting from an existing class, the initialization of the architecture components containing the
state identifies an agent instance (Figure 6.5). To complete our simple running example, besides
the bdi-1 fruit market broker agent there should be fruit sellers implementing a Subsumption
195
State
Program
Mailbox
Beliefs
Plans
Goals
Intentions
Engine
The state components
are filled with the initial
knowledge
Figure 6.5: An instance of a BDI agent.
architecture and fruit buyers implementing the bdi-2 architecture. If a buyer is characterized by
the kind of stuff she is currently willing to buy, together with the current available budget and
the current amount of acquired stuff, this information can be stored in the agent state, letting the
possibility to define the bdi-1 fruit buyer class only once, and deriving whatever number of buyer
instances from it. The instances inherit the general buyer behavior from the class, and differ only
in the three beliefs described above: the kind of stuff to buy, the current available budget and the
current amount of acquired stuff.
6.4
Development methodology
We start the discussion on the CaseLP methodology with some considerations on protocols
and ontologies and the reasons why they are not part of the basic descriptive and computational
models of our agents3; we explain why we have not extended the agent role characterization with
protocols and why agents are not described in terms of their ontologies. We also discuss what
do we mean with “full integration” of a language in our toolkit. While reading the next sections,
the reader should take in mind that CaseLP has been mainly conceived as a tool for developing
prototypes of MAS and not final applications. In the following of this chapter we use “MAS
development”, “MAS implementation”, “development of a MAS prototype” interchangeably,
even if only the third sentence really reflects the target of CaseLP. When, for brevity, we talk
3
We recall that our agents are characterized by architecture (engine + data structures) and roles (provided services
+ required services). From a computational point of view, they are characterized by engine, program and state.
196
about languages for implementing the MAS, we always mean “implementing the prototype of
the MAS”.
1. The last extensions of CaseLP were mainly devoted at providing languages for describing more complex role attributes than the ones appearing in the basic “required-provided
services” model. In particular, CaseLP supports the definition of sophisticated protocols,
using both an extension of UML (Section 6.5.3) and a textual language (Section 6.5.4).
Since the work on protocols is quite recent and it is still evolving, they have not been included within the basic attributes of roles yet. Moreover, the languages for defining protocols are not fully integrated in the CaseLP environment: we provide these languages, but
we have no recipes for filling the gap between specifying a protocol and implementing a
MAS prototype where agents communicate according to that protocol. It is up to the MAS
developer to take into account the protocol specification, and trying to adhere to it when
implementing the prototype. We know that this lack of harmonious integration among
the components (specification languages, implementation languages, tools, method) of the
CaseLP environment is one of the major limits of the environment itself, and we are
working to overcome it: the design of the D-CaseLP environment aims at realizing this
goal.
2. Similar considerations hold for ontologies (see Sections 6.5.5 and 6.5.6): the set of ontologies an agent is capable of understanding characterizes the agent itself and should be
included as a relevant attribute in the agent description. We avoided this inclusion because
the real integration of ontologies in CaseLP is still under study. Some valuable work
has been done for extending CaseLP with a language for modeling ontologies [208], but,
as we observed for roles, the gap between the ontology specification stage and the MAS
implementation stage is still to be filled.
3. The languages for modeling other aspects of a MAS (the agent architectures in particular)
have been studied more deeply and for a longer time, and the gap between the high-level
specification and implementation stages is reasonably small. We do not claim that, given
an architecture specification in one high-level specification language, we are able to automatically create the executable code for agents with that architecture: this is not an easy
task, and it could raise formal problems such as proving the consistence between the specification and the implementation which are undecidable in the general case. However, for
some languages supported by CaseLP, we have developed hints for a by-hand translation
into the target executable language which sound reasonably good, even if they are not supported by formal demonstrations. We consider these languages “fully integrated” in the
CaseLP environment.
4. Finally, we observe that some limitations we have highlighted for CaseLP partially affect
other environments for building MAS, for example IMPACT and Zeus. These environments have been developed by serious research groups whose competence in the agent field
197
is widely recognized. Also IMPACT and Zeus, however, lack in fully integrating some of
the languages they provide for modeling agents or other relevant aspects of a MAS.
We have already seen that IMPACT provides a declarative agent programming language
which uses deontic modalities to specify the actions an agent should take or should not
take. The actions are specified by means of preconditions, add and delete lists, and they
have a piece of code associated with them that implements them in the real software environment. How can a developer be sure that the piece of code really satisfies the action
specification? How should this piece of code be developed in order to fulfill the specification? These questions have no answer yet: the gap between an action specification and
implementation is not filled.
As far as Zeus is concerned, its treatment of roles and protocols is clear and well organized; we followed many ideas coming from [56] for our CaseLP extension. Nevertheless, Zeus documentation does not face the problem of how implementing the specified
roles using the tools provided by the environment: it only refers to already developed testcases to take as examples. Also in this case, the gap between protocol specification and
implementation is to be filled.
6.4.1
The development methodology main structure
Developing a MAS prototype using the CaseLP methodology is characterized by the four phases
described in Table 6.1. These four phases are not CaseLP-dependent: they are general enough
to be followed for designing and prototyping a MAS with any MASDK.
The most complex phase is the modeling one since it is necessary to model the domain independent reusable components, to chose which ones are most suitable for the current application and
how they are combined to determine the static structure of the MAS, and finally to model the
domain specific components, which determine the dynamics of the MAS.
The components we consider to be domain independent are
Õ architectures;
Õ roles and
Õ domain independent ontologies.
Ontologies represent the most subtle point here: they cannot be completely domain independent,
otherwise they would be too general to provide some significant information, but they cannot
be completely domain dependent, otherwise they would not be adopted as a tool for letting
heterogeneous systems interoperate in heterogeneous domains. We assume that some ontologies
are domain independent (for example, an ontology which establishes the relationships among
198
——————————————————————————————————————————————————————————Phase 1: Modeling
– Domain independent components modeling
Ö Architecture modeling
Ö Role modeling
Ö Ontology modeling
– Domain analysis and MAS static structure modeling
Ö Choice of the roles to be played
Ö Understanding of the complete standard role model
Ö Choice of the necessary ontologies
Ö Grouping of the roles in agent classes
Ö For each class, choice of the most suitable architecture
Ö Choice of the necessary initial agent instances
– MAS dynamics modeling
Ö Definition of the program for each agent class
Ö Definition of the initial state for each agent instance
Phase 2: Verification and validation
Phase 3: Implementation
Phase 4: Execution
——————————————————————————————————————————————————————————Table 6.1: CaseLP methodology.
199
the agents participating to a protocol is “domain independent” because it can be reused across
different domains), and others are not (for example, an ontology establishing that fruit and cheese
are closer concepts than fruit and flowers may be useful in a marketplace domain, since both
fruit and cheese fall in the “foodstuffs” category, while it may be misleading in a botanical
classification domain). The domain independent ontologies can be defined once and for all,
and adopted in different applications, while the domain dependent ontologies must be defined
according to the specific application domain.
The components which include domain dependent knowledge are
Õ classes of agents;
Õ instances of agents and
Õ domain dependent ontologies.
The rationale behind keeping the domain dependent and independent components modeling separate lies upon reusability and separation of competences among the developers.
Õ Reusability. The domain independent components, once specified or implemented, can
be reused for building prototypes of many different applications. We have already seen
the case of a broker agent, which provides and requires the same services whatever the
application domain is. In the same way, a BDI agent employed for e-commerce has exactly
the same architecture as a BDI agent employed in a personal travel assistance application:
roles, architectures and domain independent ontologies can be defined once and reused
forever.
Õ Separation of competences. Up to now, CaseLP has been used only by its developers:
even if we have developed quite complex applications for important industries and companies (see Section 6.7), we always developed them by ourselves. We played the role of
architectures developers as well as the role of classes and instances developers, since we
had all the required competences in both fields. Nevertheless, in order make CaseLP an
environment which can be used by wider teams, it is conceptually correct to think that the
development of a MAS prototype will involve different people with different skills. There
will be the expert of architectures, the expert of roles, the expert of ontologies, and there
will be the domain experts, which know how to implement the classes and instances of
agents. The two phases we have individuated, together with their sub-phases, support this
separation of skills and abilities and also clarify when an expert must come into play, and
what she must do.
The following sections deal with the four phases of the methodology in detail.
200
6.4.2
Modeling
6.4.2.1
Domain independent components modeling
In this stage of the methodology, the domain independent components are modeled. This stage
can be skipped if all the domain independent components necessary for the application have
already been modeled: these existing models (specifications) can be reused for the current application.
Since CaseLP has been conceived as a tool for building application prototypes, rather than
generic architectures or role patterns, we have no recipes for facing this stage. Clearly, for
developing a MAS we need the proper agent architectures, roles and ontologies, and for this
reason CaseLP provides the tools and languages for modeling them. Nonetheless, we have not
yet developed well-structured guidelines for explaining how to use these languages to model an
architecture (role, ontology) using CaseLP. Our effort has been mainly devoted on explaining
how choosing the right domain independent component for a certain application domain, rather
than on how modeling it.
6.4.2.2
MAS static structure modeling
In this stage, the pre-existing reusable bricks modeled in the previous stage (architectures, roles,
protocols, ontologies) are composed together to provide a static description of the MAS to be
developed. Even if the way these bricks are composed strictly depends on the application domain,
it is not necessary at this point to include domain dependent knowledge. The task of the MAS
developer is to choose the right domain independent components to do the right thing. The steps
to follow to achieve this goal are:
1. determine the roles to be played within the MAS;
2. determine the complete standard role model for the MAS;
3. group the roles in agent classes;
4. for each class, determine the most suitable architecture;
5. determine the necessary initial agent instances.
Some researchers in the agent community have provided suggestions for facing the steps above.
Instead of developing new recipes for this purpose, we have adopted the existing suggestions and
we have adapted them to the CaseLP methodology and framework. We have collected these
informal recipes in Appendix B.
201
6.4.2.3
MAS dynamics modeling
In this modeling stage all the domain dependent behavioral decisions are taken and the specification of how the agents behave to fulfill their roles is given. In particular, the program characterizing the agent classes necessary for the application, as resulting from the previous step, and
the initial state of the different agent instances must be provided.
Since CaseLP supports the definition of agents with different architectures, it is difficult to
provide general guidelines on how to define the program for each agent class, since the program
structure depends on the target language of the architecture chosen for that class, and we make no
assumptions about this language except that there is some mechanism for checking the content
of the mailbox and delivering messages. Since the program must fulfill the role model of the
class it is associated to, the minimum requirement is that
the program provides the mechanisms for managing the incoming messages described by the interaction schema associated to a role model, and reacting to these
messages in the expected way.
Usually the role model does not specify in detail which conditions must be met in order to
manage a message: the “domain knowledge” of the developer comes into play here.
6.4.3
Verification and validation stage
If some of the specification languages used in the previous stages are executable, or if they support some kind of formal proof mechanism, verification and validation of properties are possible
at this early specification stage. For example, suppose that role models are described using a
formalism that supports deadlock detection mechanisms and the analysis of other interesting
properties. The MAS developer will have great benefits from discovering bugs in the chosen role
model before implementing it, or by being sure of the correctness of the protocols she will use
thanks to a formal proof. Since we aim at providing a library of domain independent components, it will be care of the library developer to apply, when possible, verification and validation
techniques to ensure that the components in the library have good properties. However, this
does not prevent the application developer to compose the bricks in the library in some unsafe
way, and for this reason the application developer herself will take advantage of the available
techniques for testing the correctness of her specification. Moreover, the application domain
knowledge (agent program and state) is different for each application and it can be tested only
by the application developer.
202
6.4.4
Implementation stage
After the MAS has been completely specified, either in its static aspects and in the dynamic ones,
the developer must implement a working prototype. The implementation must be coherent with
the specification given in the previous steps. Ensuring this coherence is completely demanded
to the prototype developer, as no automatic tools are provided for this purpose. We have already
discussed the reasons of this limitations, and that it affects other well-established MASDKs.
During the implementation stage, an aspect that we have neglected so far comes into play: the
integration of external software. Two questions must be addressed now.
1. Why did we ignore the integration of external software until now?
In the CaseLP agent model and method discussed in [207], the information that an agent
played the role of interface towards external software was part of the agent model and,
from a methodological point of view, the interpreter4 associated to this interface agent was
specified in an early development stage. Recently we have chosen to delay the choices
about which agents should integrate external software and in which way, to the implementation stage. It seems quite reasonable to us to have a model of the agents that does
not depend on the way they provide their services: what does it change, from a modeling
perspective, to know that a buyer agent interfaces a MATLAB package to perform basic
arithmetic operations? Is it relevant to know that a personal assistant agent has an Oracle
database in the back-end, where it stores information about its owner, rather than a flat
collection of ASCII files? Now, we think that these details become really relevant only
when the integration of the external package must be implemented, and not before. In
the previous steps of the MAS modeling, we can simulate the functionalities provided by
external software, without needing to know the details of the external software. Thus, we
will simulate the knowledge of the personal assistant agent about its owner, and only in
a successive moment we will store this information in the most suitable repository. This
approach has the advantage of avoiding any commitment to very concrete choices until
they need to be addressed in order to develop the prototype. At this time, the developer
will have knowledge enough to take more motivated decisions.
2. How do we face the integration of external software?
We comply with the FIPA Wrapper Agent model. As stated in [89], a wrapper agent allows
other agents to dynamically connect to a software system uniquely identified by a software
description. Client agents can relay commands to the wrapper agent and have them invoked
on the underlying software system. The wrapper agent translates the commands contained
in the requests it receives into operations on the underlying software, and translates the
4
By interpreter we mean the agent program that translates the agent messages into the right query, or procedure
call, or method invocation, and translates the results back in messages understandable by the agents. FIPA calls this
agent a wrapper agent.
203
results back to the clients. FIPA wrapper agents play the same role as the agents we called
interpreter agents in earlier versions of CaseLP.
6.4.5
Execution stage
Once the prototype has been implemented, it must be executed to test all the choices made
during the development stages. According to the resulting behavior of the prototype, some of
these choices can be modified or refined. The modification/refinement may involve decisions
taken in the early modeling stage as well as in the last ones, for example the choices related to
integration of external software. The resulting modified prototype will be executed again and
eventually modified/refined, until it will show the expected behavior.
6.5
Tools and languages provided by CaseLP
CaseLP provides tools and languages for supporting each of the method steps described above.
Some languages are suitable for more than one development step, as shown in Table 6.2.
6.5.1
×
hhf
The linear logic language Ò hhf [62, 63] can be used to specify agent architectures, as well as their
program and state. Specification in Ò hhf are executable, so it is possible to directly interpret the
given specification. The language Ò hhf can be used to well characterize an agent architecture
under a semantic point of view. In fact, linear logics naturally models concurrent and state-based
systems as agent are. Moreover it is useful for proving properties of protocols, as shown in [28].
The features of the language are described in Section 3.8.1, while Section 6.6.1 discusses its
integration in CaseLP.
6.5.2
HEMASL
HEMASL is a procedural meta-language for the specification of both agent architecture and
agent program and state, and it is much closer to widespread existing specification and implementation languages than logic languages such as Ò hhf . It can be considered as a first step towards
defining an “intermediate” language which could make it much easier to animate and incorporate traditional specification languages into CaseLP. The HEMASL “release” we describe in
this section is an upgrade of the one discussed in [139]. Improvements concern:
204
——————————————————————————————————————————————————————————Phase 1: Modeling
– Domain independent components modeling
Ö Architecture modeling:
Ò hhf ; HEMASL; UML.
Ö Roles and protocols modeling:
UML; CaseLP-Protocol.
Ö Ontology modeling:
AgentOntology; CaseLP-Ontology.
– Domain analysis and MAS static structure modeling:
CaseLP-MASadl.
– MAS dynamics modeling
Ö Definition of the program for each agent class:
Ò hhf ; HEMASL; AgentRules.
Ö Definition of the initial state for each agent instance:
Ò hhf ; HEMASL; AgentRules.
Phase 2: Verification and validation:
The Ò hhf interpreter.
Phase 3: Implementation:
ProlAg.
Phase 4: Execution:
CaseLP simulator; CaseLP visualizer.
——————————————————————————————————————————————————————————Table 6.2: Tools and languages supported by the CaseLP methodology.
205
Õ the strong typing of the language;
Õ the syntax of the language, closer to the object-oriented one;
Õ the extension of the language by means of the “template”, “interface” and “subclass” concepts;
Õ the possibility to import UML classes;
Õ the explicit treatment of roles and services provided by the agents.
The detailed description of the language, its formal syntax and an example of use are contained
in Appendix C.1, based on [61].
The basic features of HEMASL make it suitable for agent architecture specification and for
incorporation of heterogeneous agents into the same MAS. Some important characteristics of
HEMASL are presented below.
Agent model. HEMASL supports the agent model we have introduced in Section 6.2.1. Since
this model is an abstraction of many existing architectures, the development of heterogeneous architecture specifications is facilitated.
Hierarchy of abstraction levels. HEMASL provides constructs for specifying a MAS through
the four different levels of abstraction we have introduced in Section 6.3. This helps to
model the heterogeneity of agent services and architectures.
Situatedness and social ability. The ability of an agent to interact with the surrounding environment consists in perceiving the events which take place in the environment and in performing actions which modify it. HEMASL provides an explicit model of the environment
as well as primitives that can be used by agents to sense and modify it. It also provides
constructs for modeling the message exchange among agents.
Operational semantics. The operational semantics of HEMASL is based on the concepts of
“MAS configuration” and “configuration transition”. It defines an abstract interpreter for
the language that can be used to animate specifications within the CaseLP framework5.
HEMASL main features are:
Õ HEMASL type set. HEMASL supports integers, real, boolean, chars and strings as basic
types. Composed types are lists, stacks, queues, sets and tuples. The language supports
type variables and types defined in UML.
5
This abstract interpreter has been designed, but it has not been implemented yet.
206
Õ Typed expressions. For each type the language provides a non-empty set of constants and
a set of operations (methods) which return objects of that type. For example, if lst is a
list, lst.e l() instantiates lst as the empty list and lst.inshlist(e) inserts the element e at the
beginning of lst.
Õ HEMASL statements. HEMASL provides a set of statements which are quite standard
in procedural object-oriented languages, such as conditional statement, while loop, concatenation of instructions, assignment, method call, etc. It also provides some statements
which are more specific of HEMASL as a language for specifying agent architectures,
classes and instances:
– Operations on the abstract architecture components. When specifying an abstract
architecture it is usually not possible to assign a type to the architecture components,
since this information is not available yet; in this case, the components can be assigned type component(T), where component can be later instantiated with set,
list, stack, queue and tuple, and T is a type variable which represents the type of
the component content. Given a variable c with type component(T), it is possible to
perform various operations on c such as
Ö c.e comp(): initializes an empty component;
Ö c.put comp(m, elem): inserts element elem in component c according to the
insertion mode m;
Ö c.del comp(m): deletes one element from the component according to mode
m.
– Operations for communication. Agents can perform the following operations to be
social:
Ö send(receiver, message): delivery of message message to a shared structure
called ether, which can be sensed and modified by all the agents;
Ö receive(sender, message): non-blocking reception of a message message
coming from sender;
Ö sync receive(sender, message): blocking reception of a message message
coming from sender.
– Operations on the environment. Agents can execute actions that modify the surrounding environment by means of the exec(action) statement. The actual modification of the environment is performed by a particular agent which simulates the environment and which modifies it by means of put event(event) and remove event(event) statements. Agents can also sense the environment by means of the perceive(variable) statement.
– Abstract architecture definition. HEMASL provides a strong support to the CaseLP
hierarchy we have described in Section 6.3. In particular, it forces to think in terms
of abstract and concrete architectures, agent classes and agent instances.
207
– Concrete architecture definition. In this stage, the procedures which were undefined at the abstract level are implemented, and the untyped components are assigned
a type.
– MAS creation. Finally, the developer must define the MAS by
Ö defining the classes of agents in the MAS;
Ö initializing the environment;
Ö initializing the ether;
Ö defining and initializing the agent instances.
6.5.3
UML
In Chapter 2 we have described UML and some of its extensions to deal with agent features.
Even if CaseLP is born as a purely logic-based specification environment, we cannot ignore the
current research trends: there are some good reasons for adopting UML as an agent specification
language; we have already discussed them in Section 2.6. Thus, we have spent some time and
effort in extending UML to describe agent architectures and protocols complying our CaseLP
model, and to integrate UML in the CaseLP environment. In this section we describe the preliminary work made in this direction. More results are expected from the D-CaseLP project.
The relationships between the proposed extensions of UML and the CaseLP environment are
discussed in Section 6.6.
Role diagram
The diagram we describe in this section is partly based on the Zeus methodology for agent
specification [56]. A role diagram is a graph of Roles, Actors and Agent Classes connected by
“contains”, “refines” and “uses” relations among them. Figure 6.6 shows the role diagram for the
distributed marketplace application that we will use as running example throughout this section.
Õ Role. We have already discussed what roles are, and which criteria can be followed to
determine which roles are necessary for an application (Appendix B.1). In our extension,
a role is shown as a rectangle with rounded edges. It contains three compartments:
– Name Compartment: the name of the role and, optionally, a short description of it;
– Requires Compartment: the services required to fulfill the role are listed here;
– Provides Compartment: the services provided by the agents which embody this role
are listed here.
208
BUYER
TRADER
SELLER
*
buy_Merchandise
BUYER
SELLER
*
locate_Sellers
register_Sellers
sell_Merchandise
buy_Merchandise
*
buy_Merchandise
sell_Merchandise
sell_Merchandise
*
*
locate_Sellers
*
register_Sellers
BROKER
1
1
register_Sellers
BROKER
locate_Sellers
Figure 6.6: The role diagram for the distributed marketplace application.
209
A service is identified by its name and, eventually, a short description of it. In Figure 6.6,
the rectangles with rounded edges and with the names BUYER, SELLER and BROKER
in the name compartments specify three roles. As an example, the BUYER role provides
the buy Merchandise service and requires the locate Sellers and sell Merchandise
services.
Õ Agent Class. An agent class is a container of roles. It is connected to the roles it may
play by means of a “contains” relation. It only contains one compartment which shows
its name. In Figure 6.6, BUYER, BROKER, SELLER and TRADER are agent classes.
While the first three classes play only one role, identified by the same name of class, the
TRADER class plays both the SELLER and the BUYER roles.
Õ Relations. The elements in the Role Diagram can be linked by means of the following
relations:
– Contains Relation: if this relation links two or more roles, it means that the role
containing the other one will require or provide services to it in some moment of its
existence. If it links a role to an agent class, the class will assume that role during its
existence.
– Generalization Relation: it shows that a role refines another role, in a similar way as
the subclass relation in object-oriented languages.
– Fulfill Relation: it shows that a role role-A fulfills one request of role role-B. It
is denoted by an arrow from role-A to role-B with the name of the service role-A
provides to role-B.
Agent diagram
The agent diagram specifies the architecture of the agents in the MAS, the roles they fulfill
and the relationships among them. It involves the agent architecture, Agent Class and Agent
descriptors, together with relations among them. Figure 6.7 shows the agent diagram for the
distributed marketplace application.
Õ Agent Architecture. The agent architecture is a meta-class of an agent class: the instantiation of an architecture is an agent class. Agent architectures can be specified by refinement.
It is particularly interesting the generalization which relates an abstract architecture to a
concrete architecture, or more abstract architectures which are specified further on at each
step. An architecture is represented by a rectangle containing the following compartments:
– Name Compartment: the name of the architecture;
– Abstraction Level Compartment: the abstraction level of the architecture, abstract or
concrete;
210
BDI_architecture
Reactive_architecture
abstract
abstract
BDI_1
Reactive_1
concrete
concrete
<<instance of>>
<<instance of>>
<<instance of>>
<<instance of>>
Seller
sell_Merchandise:
SellMerchandise
Trader
buy_Merchandise:
BuyMerchandise
Buyer
buy_Merchandise:
BuyMerchandise
sell_Merchandise:
SellMerchandise
Broker
locate_Sellers:
LocateSellers
register_Sellers:
RegisterSellers
Figure 6.7: The agent diagram for the distributed marketplace application.
211
– Operation Compartment: optionally, the operations of the architecture engine can be
listed in this compartment.
Õ Agent Class. An agent class is a descriptor for groups of agents sharing the same behavior.
This concept is very close to that of a UML class in a class diagram, but, in case of an agent
class, the internal structure is not shown. An agent class is defined as a rectangle containing
the following compartments:
– Name Compartment: the name of the agent class and, optionally, a short description;
– Service Realization Compartment: provides the link between the services provided by
the agent class and the methods (procedures, functions) that implement these services
in the agent class implementation. This compartment is not mandatory. It may prove
useful to establish a link between the specification and the implementation of the
agent class.
Õ Agent Instance. It is possible to instantiate an agent class: the instantiation is an agent
instance. It is represented as a rectangle with only one compartment, which shows the
object name and the class to which it belongs, underlined.
Õ Relations. The relations which can be used in the Agent Diagram are:
– Contains Relation: this relation is used when some relevant classes are contained in
an agent class. For example, if the agent is a wrapper, the class which realizes the
interpreter can be contained by the agent class.
– Generalization Relation: defines the single inheritance relation between two agent
classes or two agent architectures.
– Fulfill Relation: if it is necessary to specify or highlight some service fulfillment
relation between agent classes, it is possible to use this kind of relation.
– Instance of Relation: it indicates that a classifier is the instantiation of a class or a
meta-class. It is used to link the agent architectures to the agent classes, and the
agent classes to the agent instances. It is represented as a dotted arrow with the point
on the class and the tail on the instance. The arrow is labeled with the keyword
ØÈØ instance of ÙÈÙ .
Protocol Diagram
This diagram is a simplification of J. Odell’s proposal [160]. Protocols are mapped into a diagram
structurally similar to an interaction diagram. The difference is that in this diagram there are
roles instead of general classifiers. A protocol diagram has the form of a sequence diagram (see
Section 2.2.4.1 and Section 2.3.1.1). The vertical dimension represents time, and the horizontal
212
Seller
Buyer
contractProposal
accept
refuse
contractProposal
acknowledge
accept
refuse
contractProposal
acknowledge
Figure 6.8: The protocol diagram for the distributed marketplace application.
dimension represents the roles participating in the communication. Figure 6.8 shows the contract
proposal protocol diagram we used in Section 3.2.
Õ Roles. “Roles” in a protocol diagram are the roles that will be played by agents participating in the interaction.
Õ Role lifeline. Starting from each role, a vertical bar is drawn which represents the time
during which an agent plays a certain role in an interaction. A lifeline can follow different
paths which can be divided using:
AND parallelism. It is represented by a thick horizontal bar.
OR parallelism. It is represented by a thick horizontal bar with an empty decision diamond (inclusive OR).
Decision. It is represented by a thick horizontal bar with a decision diamond with an X
inside (exclusive OR).
213
Figure 6.9: Lifeline with an interaction thread.
Õ Interaction thread. It is similar to the activation in the UML interaction diagrams and
is represented as a rectangle with the top aligned with the beginning of the operation and
the bottom aligned with the end of the activity on the role lifeline. An interaction thread
represents the time during which the role is performing some action as a reaction to a
received message. Figure 6.9 shows a lifeline with an interaction thread.
Õ Messages. Messages can be divided into two classes: simple messages and complex messages.
Simple messages. The delivery of a message is represented as an arrow from the interaction thread of the sender role to the interaction thread of the receiver role. The arrow
is labeled with a message label, which has the following syntax:
simple-message ::= predecessor guard-condition
sequence-expression communicative-act argument-list
– Predecessor. It is a single natural number followed by “/”. It defines the right
sequence in a parallel construct and may by omitted if empty.
– Guard-condition. It is a boolean expression; the message is sent only if the
guard is true.
– Sequence-expression. It constraints the number of times a message can be sent,
or the temporal sequence of messages.
– Communicative-act. It is a string representing the communicative act of the
message.
– Argument-list. The list of arguments of the message communicative act.
Complex messages. Complex messages are simple messages composed by means of the
logical operator “and”, “or”, “xor”.
214
Õ Parametric protocols. Sometimes it is useful to leave one or more parameters of a protocol uninstantiated; in this way a parametric protocol is obtained. A parametric protocol
cannot be used until all its parameters are instantiated.
Õ Full definition of the MAS in UML. In order to complete the MAS definition it is necessary to
1. Establish the MAS ontology by means of UML classes. Any concept to be represented in the ontology is mapped into a UML class. All these concepts (classes) are
grouped in the same package which represents the ontology.
2. Provide the static structure of the MAS by means of UML class diagrams.
3. Define the behavior of the operations by means of behavior diagrams.
6.5.4
CaseLP-Protocol
The language CaseLP-Protocol is used for describing the conversational model among roles6 .
It is a textual version of the UML protocol diagram described in Section 6.5.3. Appendix C.3.1
shows its syntax. The language supports the following features:
Ú Goto and Label.
Ú Logical connectives between messages.
Ú Switch and different lifepath.
Ú Subconversation.
Ú Guard condition.
Ú Parametric protocols.
Since the language is conceptually identical to the UML protocol diagram, we do not go into
further details.
6
The conversational model is defined among roles, even if the actual conversation is carried out by agents belonging to the classes that play that roles.
215
ontology ontology_name{
concept_name_1 abstract {
name_1: type [constraints]
...
name_n: type [constraints]
}
concept_name_j effective contains:concept_name_h{
...
name_x: concept_name_h [constraints]
}
concept_name_m effective refine:concept_name_1{
...
name_w: type [constraints]
}
}
Table 6.3: Ontology definition schema.
AgentOntology
6.5.5
One almost natural way of modeling an ontology for an agent system based on logic programming is as a 5-tuple
Û
name Ü terms Ü predicates Ü kb Ü constraints Ý
where name identifies the ontology, terms is a set of function symbols, predicates is a set of
predicate symbols to be applied to terms, the knowledge base kb is a set of definite Horn clauses,
and finally constraints is a set of constraints that kb has to satisfy.
This representation allows to define both the domain independent ontology and the domain dependent one. The usage of the AgentOntology language in the CaseLP environment has been
widely discussed in Chapter 4 of [207], where an extensive example of use coming from the
sport field is also shown.
6.5.6
CaseLP-Ontology
Another way to represent ontologies is by means of CaseLP-Ontology, whose complete grammar is described in Appendix C.4.1. The definition of an ontology follows the schema depicted
in Table 6.3.
216
The ontology keyword introduces the definition of concepts belonging to the application domain called ontology name. A concept may be abstract or concrete:
Ú abstract means that the concept is generic and needs to be refined further on;
Ú concrete means that the concept is a concrete entity of the application.
A concept is defined by an attribute list; each attribute is characterized by:
Ú name: used to identify attributes;
Ú type: strings, integers, reals, booleans or any concept previously defined;
Ú optional constraints on the values that an attribute may assume.
A refines relation may be used to establish a hierarchy of concepts.
6.5.7
CaseLP-MASadl
CaseLP-MASadl is a simple architectural description language for MAS that is adopted in
CaseLP for describing the prototype overall architecture in terms of agent roles, classes, instances and their communication links.
In particular it is used to describe
Ú The roles necessary for the application; they are described as
role <RoleName> {
requires <ServiceList>
provides <ServiceList>
}
Ú The satisfaction links among required and provided services.
Ú The hierarchy of roles, defined by means of containment and refinement relations.
Ú The agent classes, their subclasses and their architecture.
Ú The initial agent instances.
The formal syntax of CaseLP-MASadl is described in Appendix C.2.1.
217
6.5.8
AgentRules
AgentRules is a rule-based agent programming language used to define the initial state of agents
and to specify their program. AgentRules is used to program agents with a reactive architecture
(namely, agents which act according to the incoming message and their current state), with a
proactive architecture (namely, agents which act only according to their internal state) and with
a reactive-proactive architecture. It is very close to ProlAg, the logic programming language
that is used in CaseLP for prototype implementation described in the next section and just adds
some syntactic sugar to it, in order to provide prototype developers with a more user-friendly
language.
An agent is given an initial state that is a (possibly empty) set of atomic ground formulae. The
initial state expresses the initial agent’s knowledge about its application domain.
An agent program is a set of reactive and/or proactive rules that define its procedural knowledge. The program of a reactive agent is expressed by means of event-condition-actions rules
while proactive agents behave accordingly to condition-actions (proactive) rules. Programs for
reactive-proactive agents are obtained by using both proactive and reactive rules.
The grammar that defines the syntax of AgentRules is described in Appendix C.5.1.
6.5.9
ProlAg
Once all the agents in the prototype have been specified using the languages and tools described
above, an executable prototype must be implemented to run a simulation. In particular, for each
agent in the system, we must implement its initial state, its program and its engine. Moreover,
for interface agents (“wrapper agents” according to FIPA terminology), the code that defines the
way external software is accessed must be provided.
The CaseLP environment initially used ECLiPSE as the implementation language. Subsequently, a new version of CaseLP adopted SICStus Prolog. In order to be independent from
the typical features of these logic programming language, we present a platform-independent
logical language for the implementation of the agents that are included in a prototype.
ProlAg (Prolog for Agents) is the target language for the implementation of the MAS prototype.
ProlAg extends standard prolog with primitives for safe state update and communication and it is
used to implement state, program, and engine of agents that are incorporated into the prototype.
It can also be used for direct implementation of the agent code, if the developer is an expert of
logic programming.
In ProlAg there are two predicates that allow an agent to update its state.
Ú assert state(Fact) asserts Fact into the agent state. Its implementation is safe
218
since, if the predicate is backtracked, Fact is removed from the state.
Ú retract state(Fact) removes the first fact in the agent’s state that unifies with Fact.
If it is backtracked, Fact is re-asserted.
One predicate allows an agent to send a message.
Ú send(Receiver, Message) sends Message from the calling agent to the Receiver agent.
Three predicates allow an agent to read messages.
Ú sync receive(Message) blocks the agent until a message unifying with Message
enters the mailbox.
Ú async receive one(Msg input, Msg output) searches the agent’s mailbox
for a message unifying with Msg input. If such a message is present, Msg output is
unified with it, otherwise Msg output unifies with the atom no message.
Ú async receive all(List of messages) fetches all the messages in the mailbox of the agent. These messages are unified with List of messages.
As far as the integration of external software is concerned, ProlAg offers no facilities or primitives: the only external modules which can be integrated into the prototypes are those for which
the target implementation languages, SICStus Prolog and ECLiPSE, already provide an interface.
6.5.10 CaseLP Visualizer
The execution of the prototype is based on a round-robin scheduler that simulates the concurrent
execution of the agents by activating in turn all the agents in the MAS. When activated, an agent
executes the cycle that implements its engine and behaves accordingly to the rules defining its
program. When the agent terminates the execution of its cycle, the scheduler activates the next
agent. The CaseLP scheduler controls the global clock of the MAS execution: once all agents
have been activated in succession, the simulation time is increased by one, and another round
starts; this process goes on until the established number of iterations has been reached. The
CaseLP scheduler also manages the delivery of messages: when the current executing agent
sends a message, the scheduler puts in into the mailbox of the receiver, in order that it can
properly receive the message when activated.
219
The CaseLP Visualizer [165] provides the software engineer with a user-friendly GUI to load
the agents into the system, start the execution of the prototype, and trace the events that take
place during simulation.
In order to execute the MAS, the user may initialize the messages that represent the input of the
simulation. The CaseLP Visualizer provides an appropriate window for this aim, as illustrated
in Figure 6.10.
Figure 6.10: Initialization window.
The user can also set the duration of the simulation (expressed in cycles of the MAS global clock)
and the granularity of on-line visualization. In this way the simulation can periodically stop to
visualize the occurred events.
The visualizer allows both on-line and off-line visualization of the MAS execution, focusing on
those events the user is interested in. Two kinds of events can be traced: agent state updates, and
message sending and reception.
While the execution is running, windows for each loaded agent appear on the screen. Information
about state changes and exchanged messages is visualized for each agent. Figure 6.11 presents
a snapshot of the MAS execution. After the execution has ended, it is possible to see a more
detailed trace of the occurred events, as illustrated in Figure 6.12. Exchanged messages and state
updates are shown for each agent. Clicking on an event, it is possible to see more details, as
shown in Figure 6.13.
220
Figure 6.11: On-line visualization of execution.
Both the on-line and off-line visualization modalities provided by the CaseLP Visualizer are
useful to monitor and verify the overall behavior of the prototype, in order to check whether it
behaves correctly or not.
6.5.11 CaseLP shell
Instead of running a simulation using the visualizer, the prototype developer can use the shell to
type in type commands to execute the simulation.
Ú The command compile(Prolag code, Target code) allows the user to translate an agent written in ProlAg into the target logic language.
Ú The command load(Target code, Agent name) loads an agent, previously compiled using the command compile, from a file and inserts it into the system for execution,
identifying the agent with the name Agent name.
Ú The command initialize(List of initial messages) initializes the input
messages for each agent.
Ú The command global parameters(Iter, Min time unit, Out, Verbose)
sets the global simulation parameters. The parameter Iter is the number of iterations
(scheduler cycles) the simulator will perform, expressed in the unit Min time unit;
221
Figure 6.12: Off-line tracing of execution.
Out is the name of the file where all exchanged messages will be collected, and Verbose is a flag setting whether or not the messages have to be visualized on the screen
during the simulation run.
Ú The command net parameters(From ag, To ag,Failure rate, Min latency,
Max latency,Unit) allows to define, for any couple of interacting agents, the failure
rate and the minimum and maximum latency of the communication channel. Min latency
and Max latency are the minimum and maximum values, expressed in Unit, of the delay over the communication channel. The reception time for a message, set by the CaseLP
scheduler, will be in the range from Min latency to Max latency. If, for a couple
of communicating agents, net parameters is not defined, the channel between them
is assumed to be without delay and completely reliable.
Ú The command start simulation starts the execution of the prototype, respecting the
parameters described above.
Ú The command get statistics can be used to collect statistics on the simulation after
its stop. The file where statistics are collected contains, for any simulation interval, the
number of messages received in that interval and the sum of their weights. The total number of exchanged message, the maximum and average number of messages per interval,
the maximum and average weight per interval, and the weight standard deviation are also
provided. In different experiments this information proved useful to evaluate the communication channels occupation, which is of fundamental importance in those applications
where the communication bandwidth is limited such as the one described in Section 6.7.
222
Figure 6.13: Details of an event.
6.6
Relationships among the CaseLP languages
We have already noticed that not all the languages and tools provided by the CaseLP environment are fully integrated in it. This means that not all the possible relations among the CaseLP
languages have been deeply studied, since we say that a language is “integrated” if it is in some
relation with another CaseLP language 7 . In this section we describe the relations which we
have analyzed; studying and formalizing the missing ones is part of our future work.
6.6.1
Þ
hhf
ß
ProlAg
In order to translate an à hhf specification into a ProlAg program, we start with observing that the
à hhf clauses assume the general form
G áâãMãMãJâ Gm
ä
á æ ææ ææ æææ ãMãMãæ æ ææ ææ æææ æ Ané h ê Ü
å A áæ ææ ææ ææ æ ãMãMãææ ææ ææ ææ æ An çè Gmé á#âLãMãMã¡â Gmé k â Ané b
where all the formulae G á8ÜMãMãMãÜ Gm é k Ü A á8ÜMãMããëÜ An é h are atomic. In order to translate a multiconclusion guarded clause C of such a form, we introduce an auxiliary predicate pC , defined
7
For example, it is possible to translate one language in the other one following some (partially) formalized
algorithm.
223
as
pC
ìè retract state å A á ê ÜMããMãëÜ retract state å An ê Ü G á8ÜTãMãMãëÜ Gmé k Ü
assert state å Ané á ê ÜãMããÜ assert state å Ané h ê ã
where retract state and assert state are the state update predicates described in Section 6.5.9.
The execution of retract state å A á ê ÜMãMããëÜ retract state å An ê consumes the atomic formulae A á ,
ãMãMã , An , the proof of G á8ÜTãMãMãëÜ Gmé k tests both the clause guard and the conditions over the
current state, and the actions assert state å Ané á ê ÜããMãÜ assert state å An é h ê add new information
to the state itself.
By applying this transformation to every à
clauses.
hhf
clause, we can obtain a corresponding set of ProlAg
As an example, [30] shows how to translate the engine of a BDI architecture from à
6.6.2
AgentRules ß
hhf
to ProlAg.
ProlAg
Due to their rule-based nature, AgentRules specifications can be easily translated into a form
that can be manipulated by a reactive-proactive engine.
The implementation of an AgentRules specification in ProlAg conforms the schema presented
in Table 6.4. The state of an agent is specified in AgentRules as a set of ground facts B 1,
ãMãMã , B n, that represent the agent’s beliefs. It is immediate to map this AgentRules specification of an agent state into ProlAg atomic ground formulae of the form
fact(Bi) ( íaî i î n).
The program of an agent is defined by two sets of ProlAg clauses. The former corresponds to
the set of reactive, proactive, or reactive-proactive AgentRules clauses. A reactive rule
on message Message check Condition do Actions
is mapped into a ProlAg clause with the following schema
reactive rule(Message, Condition, Actions),
where Message is a term that denotes the triggering message, Condition is a term that
denotes the conjunction of conditions on the agent state and auxiliary conditions, and finally
Actions denotes the sequence of AgentRules atomic actions.
Analogously, it is immediate to define the mapping from proactive AgentRules rules into ProlAg. A reactive rule
224
%%%%%%%%%%%%%%%%%%% Initial state %%%%%%%%%%%%%%%%%%%
fact(B_1).
.........
fact(B_n).
%%%%%%%%%%%%%%%%%%% Program %%%%%%%%%%%%%%%%%%%
reactive_rule(Message_1, Condition_1, Actions_1).
.........
reactive_rule(Message_m, Condition_m, Actions_m).
proactive_rule(Condition_m+1, Actions_m+1).
.........
proactive_rule(Condition_m+k, Actions_m+k).
%%%%%%%%%%%%%%%%%%% Auxiliary predicates %%%%%%%%%%%%%%%%%%%
p_1(..):- .........
.......
p_s(..):- .........
Table 6.4: Schema of ProlAg implementation of an AgentRules specification.
check Condition do Actions
is mapped into a ProlAg clause with the following schema
proactive rule(Condition, Actions),
where Condition is a term that denotes the conjunction of conditions on the agent state and
auxiliary conditions, and Actions denotes the sequence of AgentRules atomic actions.
The second set of clauses p 1, ãMãMã , p s that are included in a ProlAg program corresponds
to the set of AgentRules auxiliary procedure that are used to verify auxiliary conditions.
The engine for a reactive-proactive agent can be implemented in ProlAg as shown in Table 6.5
that we anticipated in Section 5.5.2.4. The predicate engine defines a simple meta-interpreter
for the agent architecture. First, a message is received asynchronously. Then, a fired reactive
rule is selected from the agent program and the set of associated actions is returned. Selection
among proactive rules is also performed, and a set of proactive actions is returned. Finally, a set
of actions is chosen and executed. Obviously, more sophisticated strategies for rules selection
and actions choice can be taken into account in a more complete engine. Moreover, other communication strategies may be implemented. For example, synchronous communication can be
implemented using the available variants of the primitive receive.
225
engine :async receive one(Msg input, Msg output),
(Msg output == no message ->
Actions1 = []
;
select reactive rule(Msg output, Actions1)
),
select proactive rule(Actions2),
execute(Actions).
Table 6.5: Engine for a reactive-proactive agent in ProlAg.
6.6.3
CaseLP-MASadl, -Protocol, -Ontology ß
UML
Translations from CaseLP-MASadl, CaseLP-Protocol and CaseLP-Ontology specifications
into role diagrams, protocol diagrams and class diagrams respectively is almost trivial. The last
two languages have been designed in order to fit the object-oriented paradigm and to be easily translated into the proper UML diagrams; CaseLP-MASadl had been designed some years
before the integration of UML in CaseLP, but it had been conceived in such a way that its
representation by means of role diagrams comes almost for free. We have no semi-automatic algorithms for translating specifications from these three languages into UML, but Appendix C.2.2,
Appendix C.3.2 and Appendix C.4.2 show, by means of the distributed marketplace running example, how intuitive this translation is.
6.6.4
HEMASL ï
UML
HEMASL specifications are translated into a class diagram and a statechart diagram following
an informal set of guidelines.
1. Class diagram. The class diagram contains classes representing the architectures used in
the MAS, the agent classes and instances and the eventual UML classes imported by the
architectures, which, obviously, will not be translated.
Ú Abstract architectures.
They are translated into abstract, active, parametric classes. Components and global
variables are mapped into private attributes of the class. Procedures are mapped into
private operations of the class; the procedures partially specified will be abstract
operations.
226
Ú Concrete architectures.
They are active classes obtained by instantiating the abstract architectures undefined
parameters and by defining the abstract operations of the class.
Ú Agent classes.
They are active classes obtained by instantiating the values of the class attributes
(namely, by instantiating the “program”) of the concrete architectures.
Ú Agent instances.
They are obtained by instantiating the values of the instance attributes (the “state”)
of the agent classes.
2. Statechart diagram. To specify the behaviour of the entities whose static organization is
given as a class diagram, we define a state machine for any procedure defined in HEMASL.
The way this machine can be built is described in Section 8.1.4 of [61].
To exemplify how the translation from HEMASL to UML can be performed, Appendix C.1.2
shows the way a BDI architecture previously specified in HEMASL can be represented by means
of a class and a statechart diagram.
The converse translation from UML to HEMASL is not always possible, since some UML diagrams, such as implementation diagrams or use case diagrams, have no corresponding programming feature in HEMASL. As far as role diagrams, agent architecture diagrams and protocol
diagrams are concerned, they can always be translated into HEMASL by following guidelines
specular to the ones depicted in 6.6.4.
6.7
One application of CaseLP
In this section we describe how we followed the CaseLP methodology proposed in Section 6.4
to design and develop a working prototype of a vehicle monitoring application in collaboration
with Elsag s.p.a., an international company working in several service automation fields8 . The
results described here have been presented in a poster session of the 2nd European Workshop on
Advanced Video-based Surveillance Systems, AVBS 2001 [8].
For Police and Financial Police, the control of wide sections of motorway represents a powerful
means to individuate vehicles of suspects, trace their movements and take the proper actions
consequently. Such control takes place by a distributed network of car detection and licence plate
reading systems, placed at motorway service areas, sending their transit information to control
8
Elsag is involved in the IST project VISOR-BASE (www.vtools.es/visorbase/), with French, Spanish
and Belgian partners, aiming at developing an architecture and prototype applications for advanced video-based
surveillance systems, based on CORBA (www.corba.org).
227
centers and detecting possible matches with suspect plate numbers. Besides law enforcement,
this kind of car monitoring can be useful for vehicle transit control, such as in motorway gates,
parking areas and urban zones with restricted access.
The scenario for vehicle monitoring is extremely complex since it involves a large number of heterogeneous entities. They can be human entities (the policeman who inserts a new plate number
to be monitored or who receives an alarm concerning a suspect vehicle), physical entities (remote
cameras for getting plate numbers images, communication infrastructure) and software ones (the
client interface, the application server and the remote sensor control with image processing for
licence plate reading). The complexity of this scenario and the distinguishing features of the
entities involved in it, namely their heterogeneity, their physical distribution and their autonomy, highlighted the suitability of a MAS approach to the design and development of a working
prototype.
According to these considerations, our research group and Elsag s.p.a have developed a working
prototype of the application using CaseLP. The prototype has been used to improve the application specifications, to properly dimension the communication channels, and finally to provide
a formal specification to be followed during the implementation stage. The implementation has
been completed successfully and the vehicle monitoring apparatus has been installed in the motorway section between Salerno and Reggio-Calabria (Italy); it is currently used by the Italian
Police, Financial Police and by the “Autostrade” (motorway) organization for traffic monitoring.
6.7.1
The case-study: vehicles monitoring in motorway
Elsag has been designing and integrating remote surveillance systems, including automatic detection and reading of licence plates, since 1990. They have been applied in different scenarios,
such as: motorway gates and service areas; parking areas; urban sectors with traffic limitations;
entrance/exits of harbours and commercial areas.
Each application has its own user interface, distributed configuration and database schema; however, they are all based on the “intelligent sensor” called LPR (Licence Plate Recognizer), a
software component hosted in standard PCs equipped with frame grabbers linked to cameras.
The relevant process, called “Oð CR” (Out-door OCR), is applied to each camera’s video flow,
with no need for specific vehicle passing sensors. In fact, motion detection limits the number of
relevant video frames; on each frame, image segmentation localizes the regions of interest; on
each region, character segmentation detects the licence plate characters, if present; the specialized OCR recognizes them; finally, context processing provides feedback to region segmentation
and camera set-up (such as adaptation to changing illumination).
The specific application, which has been modeled as a MAS, implements the monitoring of vehicles entering and exiting the service areas of a motorway section, between Salerno and Reggio
Calabria in Italy, whose specific characteristics are heavy traffic in most days (being a main con228
nection in south Italy) and toll-free transit, sometimes allowing vehicles to enter and exit the
motorway at the service areas themselves.
These peculiarities fostered, more than for other motorway sections, highlighted the need for traffic monitoring with automatic alarm detection, this consisting in detection of signalled vehicles,
such as stolen or improperly used ones. In the rest of description, transit defines a recognized
car plate number with related time/place stamp and reference image (back side of the detected
vehicle), black list is a list of signalled licence plate numbers and alarm is a transit whose licence
plate matches an item in a black list.
The configuration is distributed on a protected TCP/IP WAN, using both cables and satellite links
with limited bandwidth, and includes the following physical and software entities:
Ú Executive Center (EC): client site of motorway management or Police, with one or more
client stations, allows to browse transits, get alarms, visualize vehicle images, modify the
black lists, and require database operations according to users’ privileges.
Ú Application Server: usually centralized on a server machine or server LAN, coordinates
any communication with the Executive Centers and the Surveillance Areas (see below),
dispatches alarms according to ECs’ requests (black lists can be different, so each EC
must get just the alarms of interest) and manages the central transit/alarm database.
Ú Surveillance Area (SA): hosts the peripheral intelligent sensors on one or more PCs in
a LAN, located at a service station, gets video frames from the local cameras, generates
transits and alarms by storing a local black list, sends transits and alarms to the Application
Server.
The communication topology is therefore star-like around the Application Server, with more ECs
and SAs linked to it, as represented in Figure 6.14. Direct links between EC and sensors in SAs
are just used for direct video monitoring, but this function usually employs different cameras and
does not take part in the intelligent alarm system.
Communication takes place by TCP/IP messages with dedicated session protocol. Current evolution is towards higher level, standard middleware such as CORBA between Server and SA,
CORBA or HTTP (Web-based clients) between EC and Server. The main messages between an
EC and the Application Server are:
Ú requests to inquiry/browse/modify the transit database, with related answers;
Ú requests to inquiry/browse/modify the black lists (signalled) database, with related answers. The black lists can be specific of each EC, and each signalled licence plate number
can be limited to a subset of SAs;
229
Figure 6.14: Motorway Monitoring Application Architecture.
Ú incoming alarms requesting attention by operators;
while the main messages between the Application Server and the SAs are:
Ú requests to update each SA’s local black lists. In fact, this allows for fast alarm detection
directly by SAs, while the Server takes care of dispatching alarms to the right ECs;
Ú incoming transit lists;
Ú incoming alarms.
Data allocation (for instance, whether to centralize the database of transits or keep it distributed
on SAs) and communication strategies had to be modeled in advance, in order to take the best
solutions before achieving physical implementation on the real WAN. Besides, modeling each
entity’s behavior was needed to pre-test the entire message exchange system against coherence,
deadlock absence and performance. To this objectives, application prototyping by means of
CaseLP proved to be very effective, as described in the next section. A careful work was
made to make the specification as modular and extensible as possible, keeping into account the
possibility to have more application servers managing and exchanging information coming from
different motorway tracks.
230
6.7.2
Realization of the prototype in CaseLP
6.7.2.1
Modeling
Domain independent components modeling. No domain independent components have been
modeled for this application for the following reasons:
Ú all the agents in the application share a reactive architecture, which had already been
modeled;
Ú at the time of developing the application, the methodology was slightly different and less
emphasis was given to roles, which were considered a domain dependent feature;
Ú there are a few concepts shared by the agents in the application and they are not ambiguous,
thus an ontology is not necessary.
MAS static structure modeling. As introduced in Section 6.7.1, three types of entities have
been identified; the roles they play are the executive center role (ec role), the surveillance area
role (sa role) and the role of the server of both (ec sa server role). In this application, roles
are in a one-to-one correspondence with classes. Thus, we have the EC class, the SA class and
the EC SA SERVER class. One of the reasons for developing a working prototype was to understand whether it was better to maintain a distributed database of monitored transits (different
databases should be maintained by the surveillance areas, each one containing information on the
transits occurred in that specific area) or a centralized one (maintained by the EC SA SERVER,
and containing all the transits occurred in all the surveillance areas).
The static descriptions in the centralized and distributed settings are almost the same, there
are only small differences concerning the monitored transits of plate numbers. In case of a
centralized solution, the surveillance areas asynchronously send an update of transits to the
EC SA SERVER. The frequency of this update is parametric, and different experiments have
been done in order to choose the best one. In this case, when an EC needs informations on
transits, it just interacts with the EC SA SERVER which provides the answer.
If the databases are distributed, the surveillance areas do not send any information on transits
to the EC SA SERVER; when an EC asks the EC SA SERVER for obtaining information on
transits, this query is forwarded to the SAs involved in the query, and the answers are combined
into a unique answer sent to the EC.
In the rest of the section, we deal with the MAS specification for the centralized solution of the
transit database. The specification in the distributed case is quite similar. Table 6.6 describes the
MAS static structure model specified in CaseLP-MASadl.
231
role ec_sa_server_role {
requires: update_plate_trans, update_wanted_plate,
alarm_wanted_plate;
provides: alarm_wanted_plate, wanted_plate,
update_wanted_plate, plate_trans;}
agentrole ec_role {
requires: plate_trans, wanted_plate, alarm_wanted_plate;
provides: update_wanted_plate;}
agentrole sa_role {
requires: update_wanted_plate;
provides: update_plate_trans, alarm_wanted_plate;}
agentclass EC_SA_SERVER {
roles: ec_sa_server_role;
architecture: reactive;}
agentclass EC {
roles: ec_role;
agentclass SA {
roles: sa_role;
agentInstances {
1 ec_sa_server EC_SA_SERVER; 20 ec EC; 23 sa SA;}
link {
ec*.plate_trans <- ec_sa_server.plate_trans;
ec*.wanted_plate <- ec_sa_server.wanted_plate;
ec*.alarm_wanted_plate <- ec_sa_server.alarm_wanted_plate;
sa*.update_wanted_plate <- ec_sa_server.update_wanted_plate;
ec_sa_server.update_wanted_plate <- ec*.update_wanted_plate;
ec_sa_server.update_plate_trans <- sa*.update_plate_trans;
ec_sa_server.alarm_wanted_plate <- sa*.alarm_wanted_plate;}
Table 6.6: MAS static architecture specified in CaseLP-MASadl.
232
Conversation c1
(ec_sa_server.alarm_wanted_plate <- sa*.alarm_wanted_plate)
1) Message: sa --> ec_sa_server
Performative: inform
Content: alarm(Num_plate, Sa_id, Device_id, Time, Image)
Conversation c2
(ec*.alarm_wanted_plate <- ec_sa_server.alarm_wanted_plate)
1) Message: ec_sa_server --> ec
Performative: inform
Content: alarm(Num_plate, Sa_id, Device_id, Time, Image)
Table 6.7: Conversation protocol specified in CaseLP-Protocol.
on message inform(alarm(N_plate, Sa_id, Device_id, Time, Image))
check
ec_interested_in(N_plate, List_of_interested_ec)
do
multicast(
inform(alarm(N_plate, Sa_id, Device_id, Time, Image)),
List_of_interested_ec)
Table 6.8: MAS dynamics modeling in AgentRules.
As far as the conversation model among the agents in the MAS is concerned, we limit ourselves
to describe the conversation related with raising an alarm when a transit of a “wanted” vehicle
takes place in a surveillance area (Table 6.7). The conversation is started by the surveillance
area which recognizes the plate number. An alarm is sent to the ec sa server, that knows which
executive centers were interested in that plate number, and forwards the alarm to them.
MAS dynamics modeling. For describing the procedural knowledge of the agents we used
AgentRules. The fragment of AgentRules code of Table 6.8 describes the actions the ec as server
takes when it receives an alarm from a surveillance area. Coherently with the previous step, one
of the actions the agent performs is to forward the message to the executive centers interested in it.
The reactions to other messages is formalized in a similar fashion. The meaning of this fragment
is that when an alarm is raised, the agent ec as server looks for a fact, asserted in the database
representing its current knowledge or state, which matches with ec interested in(Num plate,
List of interested ec) (uppercase symbols are variables which match with everything).
If it finds it, then it can forward the information related to the alarm to all the interested executive centers, List of interested ec. The communicative action multicast sends a
message to a list of recipients.
233
handle_message(
ask(
content(inform(
alarm(N_plate, Sa_id, Dev_id, Time, Image)),
sender(SA),
receiver(EC_SA_SERVER))) :ec_interested_in(N_plate, List_of_interested_ec),
multicast(inform(
alarm(N_plate, Sa_id, Dev_id, Time, Image)),
List_of_interested_ec).
multicast(Message, [List_of_rec_head|List_of_rec_tail]):send(List_of_rec_head, Message),
multicast(Message, List_of_rec_tail).
multicast(_, []).
Table 6.9: MAS implementation in ProlAg.
6.7.2.2
Verification and validation
Since the high-level language used for specifying the agents is not executable or animable, the
verification step has been skipped, directly going to the prototype implementation.
6.7.2.3
Implementation
For the partners from the industry it was quite surprising the quickness of this phase which required less than one month of one single developer to be completed. The clear formalization of
the agents features, performed following the method steps, greatly helped in making the implementation quicker. In fact it was just necessary to translate the AgentRules code into ProlAg
and to implement the actions the agents had to perform. This was quite an easy task, since
the AgentRules actions were mainly concerned with state updates and message sending, and
ProlAg provides primitives for both of them. The fragment of ProlAg code contained in Table
6.9 describes the rule that the agent ec sa server applies to manage an alarm. This is the implementation in ProlAg of the AgentRules rule given before; the rule for multicast is also
provided.
234
6.7.2.4
Execution
To obtain statistical information from the execution of the prototype, a weight was assigned to
any message which could be exchanged among agents, representing the number of bytes of the
message itself. The weights were evaluated taking into account the overhead due to the TCP/IP
protocol. 34 simulations were executed, 16 using the prototype for the centralized case and
18 using the prototype of the distributed one. The simulations were executed under different
assumptions. The parameters which were changed in the different runs dealt with the frequency
of vehicle transits in a surveillance area, with the frequency of operations required by an operator
in one executive center (queries or updates on the database of “wanted plate numbers”, queries
on the database of vehicles transits, etc...), and finally with the amount of circulating vehicles.
As an example, the frequency of transists could assume the values of one transit every 5, 20 or
40 seconds, the frequency of operations in an executive center could be one every 5, 15 or 25
minutes, and the total number of circulating vehicles could be 1.000.000 or 100.000.
In the centralized case, also the maximum length a batch of transits could reach before being sent
from a surveillance area to the ec sa server, and the maximum time between two successive
updates on transits were left parametric.
Once a simulation is completed, it is possible to establish which kind of messages to monitor. We
got tables concerning only the alarm messages, tables related to all the messages except the alarm
ones, and overall comprehensive tables. We then organized the results of all the simulations to
compare them in the distributed and centralized case and to understand under which conditions
it was preferable one solution or the other one.
Table 6.10 reports a subset of the results taken from the comparison table of all the messages
except the alarm ones. The chars “c” or “d” after the simulation identifiers mean centralized or
distributed respectively. The parameterization of the simulation runs is the following:
Ú Sim 3 c, Sim 11 c and Sim 7 d: one transit in the SAs every 40 seconds; one operation in the ECs every 5 minutes and 1.000.000 circulating vehicles (what changes between
Sim 3 c and Sim 11 c are the maximum allowed batch length and wait time between
two updates);
Ú Sim 4 c, Sim 12 c and Sim 9 d: one transit in SAs every 5 seconds; one operation in
ECs every 5 minutes and 1.000.000 circulating vehicles;
Ú Sim 5 c, Sim 13 c and Sim 10 d: one transit in SA every 40 seconds; one operation
in EC every 25 minutes and 100.000 circulating vehicles.
MMpS (AMpS) stands for “maximum (average) number of messages per time slot”, while
MWpS (AWpS) is the “maximum (average) weight in bytes per time slot”. Finally, WStDev
235
RUN ID
MMpS
AMpS
MWpS
AWpS
WStDev
Sim 3 c
Sim 11 c
Sim 7 d
4
3
6
0.29
0.23
0.88
1488
4916
2132
78.76
148.48
238.98
173.69
688.42
316.57
Sim 4 c
Sim 12 c
Sim 9 d
6
4
6
0.80
0.27
0.83
2940
9220
2132
323.56
291.34
224.69
385.43
1047.55
304.71
Sim 5 c
Sim 13 c
Sim 10 d
4
2
3
0.15
0.09
0.19
1680
4820
1020
52.37
122.70
49.53
149.41
682.78
138.26
Table 6.10: Comparison table of all messages except the alarm ones.
is the standard deviation of messages weight. The time slot length was set to the simulation time
grain, namely one second.
The results obtained from the comparison were the following ones:
1. Coherently with what expected, the behaviour of the alarm messages does not change in
the distributed and centralized cases under the same initial conditions. In fact, the management of alarm messages does not depend on how the database of vehicle transits in the
surveillance areas is organized.
2. As far as the remaining messages are concerned (all the messages except the alarm ones),
the distributed solution turns out to be better than the centralized one, except in the case
of one vehicle transit every 40 seconds and of one operation in an executive center every 5
minutes (first group of results, Sim 7 d, Sim 3 c and Sim 11 c).
3. Under the reasonable assumption of one transit every 40 seconds and one operation every
25 minutes (last group of results, Sim 10 d, Sim 5 c and Sim 13 c), the differences between the centralized and distributed solutions are negligible, provided that the maximum
length of a transit batch and the maximum time between two successive updates of transits
in the centralized setting are chosen properly. Note that the transit interval of 40 seconds
does not represent a very low traffic, this being referred to each entrance/exit lane in a
surveillance area and not to the main motorway lanes.
These results, the last one in particular, helped in deciding to adopt the centralized solution for
the real apparatus. In fact the bandwidth required in this case was always below the threshold
236
due to satellite communication, and it was possible to reuse already developed components.
6.8
Conclusions
In this chapter we have described CaseLP and its use for a real industrial project. CaseLP
has been used for modeling and prototyping many other applications, ranging from freight train
traffic, in collaboration with FS s.p.a., the Italian railway company ([58, 59]), to distributed
health care [166], from distributed database transactions [145], to reverse hybrid mail [57], just
to cite some of them. The logical languages provided by CaseLP to model intelligent agents and
the possibility to use these agent specifications to validate properties of the system and to build a
working prototype represent the main strength of our prototyping environment. We are extremely
confident in the usefulness of logics and logic programming in the area of artificial intelligence
which concerns modeling and prototyping multi-agent systems. Nevertheless, we are aware that
designers and programmers from the industry are not always keen on learning logics and logic
programming to face the development of an application in a principled way. For this reason, in
the last years we started working on the integration of HEMASL and, most important, UML, in
our environment. In this chapter we have described some preliminary work in the direction of
integrating UML in CaseLP; this issue is extremely promising and it is a central aspect in the
design of D-CaseLP. We think that if we will be able to conjugate the intuitiveness of UML
diagrams with the ability to validate specification properties supported by à hhf and the easiness
of rapidly building prototypes using logic programming, we will provide developers of MAS
with a really useful tool for engineering their applications.
237
Chapter 7
Further Developments: Designing
D-CaseLP
7.1
Introduction
In the previous chapter we described CaseLP, its agent model, the hierarchy of abstraction levels, its methodology and the tools and languages it supports. By means of a case study (Section
6.7.1) we have demonstrated that CaseLP can be successfully adopted to model complex applications which require a fast prototyping stage for rapidly getting simulation results. The vehicle
monitoring application that we simulated with CaseLP has been implemented in a section of the
Salerno–Reggio Calabria highway: this result is definitely satisfactory to demonstrate CaseLP
suitability for fast prototyping. Nevertheless, there are issues that deserve some consideration:
Ú We developed the prototype by ourselves. The prototyping stage was surprisingly fast
because we have a great confidence with the logical languages in which the agents are
specified and implemented. It is hard to expect such a confidence from designers in the
industry, who are probably more accustomed to UML and Java than to linear logic and
Prolog.
Ú The data arriving from the cameras located in the Surveillance Areas and their processing
by means of an out-door OCR process have been simulated; reasonable hypothesis on the
number of vehicles passing in the Surveillance Area were made, and the behavior of the
out-door OCR process was assumed to be ideal, with no failures. As far as this application
was concerned, the assumptions we made were acceptable and did not compromise the
results of our simulation, but there may be situations where the prototype of the application
needs to integrate real existing software whose behavior cannot be simulated, for example
because there is no simple mathematical model of the output provided by the software, or
238
because the software itself needs to be tested.
The issues above did not prevent CaseLP from being used, with valuable results, in many different areas as discussed in Section 6.8. Nevertheless, they limit the adoption of our tool to teams
of people who know logic and logic programming1 and who want to develop applications that
need limited integration of external modules.
The aim of the D-CaseLP (Distributed CaseLP) project is to overcome these limitations, allowing the MAS designers to use linear logic and logic programming, if they are confident with
these languages, but also providing them with non-logic specification and implementation languages that may prove more suitable to their needs and experience. In the spirit of the ARPEGGIO philosophy, we want to extend and improve the potentialities of CaseLP by adding new
features and facilities to it, without betraying our firm conviction that a logic-based approach
represents an advantageous solution for the first steps of MAS design and development.
In this chapter, that should be read as an “extended future work” document, we deal with the
framework architecture we have designed and with the development strategies we decided to
follow to implement it, we discuss existing standards for MAS development and we compare
platforms and languages for MASDK implementation. For these reasons, even if the D-CaseLP
project is just at the beginning and no measurable results have been achieved so far, its discussion
may represent a useful case-study on the design of MASDKs and may provide some interesting
contributions to the research community.
7.2
The project purpose
The final aim of the D-CaseLP project is to extend CaseLP with the following issues:
1. Integration of UML.
2. Modeling and integration of roles and interaction protocols.
3. Integration of new languages for implementing agents.
4. Integration of legacy software.
5. Physical distribution of the agents.
6. Support in the creation of the final application.
7. Improvement of existing features.
1
Unfortunately, HEMASL does not represent a solution for this requirement since it is not executable and thus
cannot be used to build a working prototype. The same holds for UML, which is only partly integrated in CaseLP.
239
7.2.1
Integration of UML
We started thinking about the integration of UML in CaseLP some times ago: Sections 6.5.3,
6.6.3 and 6.6.4 describe the extensions we made to UML in order to make it suitable for agent
specification and the relationships among UML and other languages supported by CaseLP. In
CaseLP, however, we did not achieve the goal of obtaining the code of the agents from their
specification in UML, via some kind of translation process. In D-CaseLP we aim at developing a semi-automatic mechanism for building “agent skeletons” (i.e., incomplete agent programs
where some parts must be manually filled by the programmer) starting from UML specifications.
In particular, our idea is to describe roles and interaction protocols the agent must keep to using
UML, and semi-automatically develop agent skeletons whose communication strategy respects
these protocols. Also the agent architectures may undergo this process, being specified using
UML and then being translated into the proper agent skeletons to be filled with the proper behavioral knowledge. Ontologies may be modeled in UML too, and then translated into the proper
representation language.
7.2.2
Modeling and integration of roles and interaction protocols
In the CaseLP descriptive view, an agent is characterized by its architecture and the roles that
it fulfills. In the previous chapter we have discussed the increasing importance that the “role”
concept is gaining as a characterizing feature of agents, and in Appendix B we show how to
determine the necessary roles for an application. Moreover, in Section 2.3.1, we described the
adoption of AUML to specify agent interaction protocols. As we anticipated in Section 7.2.1, we
are putting these components together, in order to understand which extensions of UML are more
suitable for modeling roles and interaction protocols, and how these UML models can be used to
“produce” agent code.
The desire underlying our work is to provide the MAS engineer with a library of interaction
protocols specified in UML2 , let her choose the most suitable ones for the application to be
developed, eventually combine them to produce new protocols and finally help her in creating
the skeleton code for the agents via some semi-automatic mechanism.
7.2.3
Integration of new languages for implementing agents
As we discussed in Section 3.10.1, the implementation of agents using a logic programming
language has many advantages (MAS execution model, meta-reasoning capabilities model, rationality and reactiveness of agents) but it also suffers from some drawbacks (Section 3.10.2).
2
The development of libraries of this kind has recently begun, see [174] and [56]; research at British Telecommunications (BT) is documenting further agent role models catalogs.
240
For these reasons, in the D-CaseLP environment we want to integrate non-logic languages with
logic languages, in order to take advantage of both the paradigms. In particular, we will start with
the integration of Java: thanks to its portability, to the facilities it provides for synchronization
among processes and for distribution and to the work on mobility (see for example the IBM
aglets [127], Concordia [106] by Mitsubishi Electric, Grasshopper [99] by IKV++), we think
that Java is the best candidate for developing non-logic agents. Our opinion is confirmed by
the growing number of agent platforms developed in Java, such as JADE [21] that we will
discuss in Section 7.5.2. By integrating the Java language in D-CaseLP, and by adhering to a
standard agent structure that we will discuss in Section 7.4, we aim at allowing agents developed
by ourselves and by other parties to communicate and interoperate.
7.2.4
Physical distribution and integration of legacy software
The distribution provided by CaseLP is only logical: agents run within the same Prolog thread
of execution and on the same processor, even if we simulate their concurrency and distribution.
This is enough if we want to analyze the problem abstracting from low level network details,
which may be partly simulated too, but it proves insufficient if we want to go beyond the requirements analysis, towards the realization of a product, or if the simulation is computationally
heavy and cannot be run on a single processor. Similar considerations hold for integration of
existing software: in many CaseLP applications the legacy software has been simulated, and
its real output has been substituted by an approximation, based on some model of the software
behavior. We have already seen that this approach is not always feasible, and there are situations
where it is necessary to really integrate the external software to get realistic simulation results.
7.2.5
Creation of the final application
Since we plan to let agents written in Java and agents written in Prolog co-exist and interoperate
within the same D-CaseLP platform, it will be easier for the MAS designers and MAS developers to go towards an application close to the final one. Agents whose behavior must be rapidly
sketched may be written in Prolog; agents whose behavior is already clear may be developed
in Java, obtaining a code which may also be the definitive one. The opportunity to integrate
external software also makes the prototype closer to a working application.
7.2.6
Improvement of existing features
Some features already offered by CaseLP will be changed and/or improved in order to fit the
new D-CaseLP setting:
241
Ú MAS development methodology: the methodology described in Section 6.4 will be modified to guide the specification of roles, interaction protocols, architectures and ontologies
in UML. Since the transition from UML diagrams to Prolog and Java agents will not be
completely automatic, instructions on how to complete this translations will be given.
Ú Library of agent architectures: A library of agent architectures will be developed and made
available to the D-CaseLP users, to allow them choosing the most suitable one according
to the guidelines provided in [155] and summarized in Appendix B.4.
Ú Supported logic languages: after the experience we made with the IMPACT framework,
we became convinced that deontic logic is a very powerful formalism for specifying intelligent agents. We plan to add this formalism to the set of logic languages supported by
CaseLP.
7.3
The functionalities D-CaseLP will provide
In order to clarify the requirements of the D-CaseLP environment, we have developed a function
refinement tree3 for it, including more functionalities than the ones realizable in the close-future.
Our idea is to be as far-seeing as possible, designing D-CaseLP as we would like it to be in the
future, even if the functionalities we can develop in the beginning of the project are just a subset
of the expected ones.
System mission: MAS modeling, prototyping, testing and final development
1. MAS modeling and creation of the code for the MAS prototype
(a) Modeling and integration of reusable (domain independent) components
i. Architectures modeling and integration
ii. Role models modeling and integration
iii. Domain independent ontology modeling and integration
(b) MAS instantiation
i. Choice of the role models necessary for the application
ii. Classes instantiation
A. Choice of roles characterizing each class
3
A function refinement tree (f.r.t.) is a tree which lists the desired functions of the system in a hierarchical
manner. The root represents the overall system mission and the offspring of a node represents the functions that
must be presented to offer higher-level functions. A function refinement tree is a hierarchical presentation of external
system functionalities and not of system structure [200].
242
B. Choice of the architecture characterizing each class
C. Instantiation of the “program” components
iii. Ontologies instantiation
A. Choice of domain independent ontologies necessary for the application
B. Definition of the domain dependent ontologies
iv. MAS instantiation
A. Definition of the agent instances through the instantiation of their “state”
components
(c) Creation of the agents’ code
2. Development and testing of the MAS prototype
(a) Prototype implementation
i.
ii.
iii.
iv.
Configuration
Legacy software integration
Communication support
Mobility support
(b) Prototype execution monitoring
i. Input definition
A. MAS parameters simulation (communication channels, etc.)
B. User and other input simulation
ii. Output interpretation
A. On-line visualization
B. Off-line visualization
3. Final application implementation
4. Final application use
The D-CaseLP toolkit will support its users in four macro-tasks:
1. MAS modeling and creation of the code for the MAS prototype. In order to obtain a running
prototype, it is necessary to model the application to be developed and to create the executable code for the prototypical agents starting from this model. This first functionality’s
purpose is to support the D-CaseLP users from the high-level specification of the necessary components (architectures, roles and interaction protocols, ontologies, agent classes
and instances) to the implementation of the prototypical agents’ code. This macro-task is
divided into three sub-tasks, which in principle can be faced by four different professional
figures:
243
(a) Modeling and integration of reusable (domain independent) components. The domain independent components (architectures, roles and interaction protocols, domain
independent ontologies) can be modeled once for all by people specialized in these
tasks (architecture designer, roles and interaction protocols designer and ontologies
designer, respectively), who may also ignore the final application to be developed.
We talk about “modeling” and “integration” because the domain independent components that will be created may be either modeled in some high-level specification
language, or implemented in the language used to develop the prototype. In the second case, the components will be ready to be integrated into the working prototype.
To make an example, the BDI architecture may be specified in UML or in à hhf , thus
providing a model4 of it, or it may be implemented in Prolog or as a Java class, thus
allowing its direct integration in the final prototype.
(b) MAS instantiation. Once the domain independent components have been made available, the domain expert (application designer) can start the MAS instantiation by
choosing the roles and protocols necessary for the application, the most suitable architectures and the right domain independent ontologies. She will also provide the
domain dependent knowledge to fill the “program” and “state” components in the
agent class. According to the chosen language, the output of this stage can be a
specification to be translated into executable code, or can be the code for running the
prototype.
(c) Creation of the agent’s code. If the MAS instantiation stage has produced a model
of the MAS, but not the executable code for it, it is necessary to apply the methodological guidelines that we are developing together with S. Miglia5 to build the prototypical agent’s code from an high-level specification. This stage will be faced by
the application designer.
2. Development and testing of the MAS prototype. Once the code for the agents will be
available, it will be possible to run the simulation in order to test the prototype behavior.
The functionalities that D-CaseLP will provide are concerned with:
(a) Prototype Implementation. To run the simulation of the prototype it is necessary to
configure it by establishing where the pieces of code of the various agents reside.
It is also necessary to enhance these pieces of code with the capability of really integrating external software: this issue, that may be neglected in the modeling stages,
needs to be faced in the execution stage.
Since the agents belonging to the prototype are usually distributed, they may communicate using different low level communication protocols. These differences are
masked within the agent code, where the communication primitives are the same
4
5
If ñ hhf is used, the model may be executed.
S. Miglia is one of our students currently working at his master thesis.
244
for all the agents: send, sync receive and async receive. To execute
the MAS prototype, these primitives must be implemented, and this implementation
may change from agent to agent according to the low level communication protocol
adopted by the agents.
Finally, mobility support must be provided to let agents migrate in the nodes that
constitute the prototype network.
The four issues above must be faced by the prototype configurator and tester6 who
sets up the infrastructure for allowing the distributed prototypical agents execute and
interoperate.
(b) Prototype execution monitoring. To run the simulation, it is necessary to simulate
the application communication channels features and the incoming input. The communication channels in the real application may be different from the ones used by
the simulator: for example, the simulator may use Remote Method Invocation (RMI)
for the communication between two agents A and B which, in the final application,
will communicate by means of a satellite. The features of the satellite communication (bandwidth, latency, reliability) are surely different from the features of an
RMI communication, and for this reason it may be necessary to simulate the satellite
communication features over the RMI channel.
To execute the prototype it is also necessary to simulate the input coming both from
the environment and from the final users of the application. This may be achieved by
creating a dummy agent which provides an interface towards the MAS configurator
and tester, who will insert the fictitious input.
To follow the prototype execution, an interface showing the messages exchanged by
the agents and the changes taking place in their state components is necessary; the
visualization of this information may be both on-line, to allow a rapid understanding
of the overall MAS behavior, and off-line, for a successive, more refined revision of
the interactions among agents.
3. Final application implementation and use. We think of D-CaseLP as a toolkit that may
assist the application development from the first modeling stages to the implementation
of the final application. To achieve this goal, D-CaseLP will provide guidelines and
support for substituting the prototypical agents with the “real” ones and for allowing them
to communicate using the “real” communication channel. We also hope that our toolkit
will prove useful to provide the final users of the real application with information and
suggestions coming from the experience gained with the prototype.
Figure 7.1 shows the use case diagram for the overall functionalities of D-CaseLP; Figures 7.2
and 7.3 show the use case diagram for the more specialized functionalities of modeling the MAS,
6
In principle, the MAS configurator may be a different person than the one carrying out the experiments, but, for
simplicity, we assume the two roles are assumed by the same individual.
245
Architectures designer
MAS modeling and
code creation
Roles and interaction
protocols designer
MAS prototype
development and
testing
Ontologies designer
Application designer
Final application
implementation
Prototype configurator / tester
Final application developer
Final application
use
D-CaseLP
Final application user
Figure 7.1: Use case diagram for the overall functionalities.
building the prototype code, configuring the prototype and running it. We think that, thanks to
the discussion of the function refinement tree above, these use cases need no further explanation.
7.4
Standards taken into account in the D-CaseLP design
Due to the large amount of academic institutes, companies and industries working in the MAS
field and the increasing effort to build open systems able to interoperate, developing a MAS
prototyping toolkit based on proprietary models and languages which cannot be shared with
other environments appears an obsolete strategy. We decided to design D-CaseLP according to
some recognized standard, to allow interoperation with other environments and to increase the
possibility of adoption of our toolkit beyond the walls of our department.
The organization that spends more effort at standardizing the agents’ abstract architecture, namely
the framework for allowing agents interoperability and reuse, is the Foundation for Intelligent
Physical Agents (FIPA)7 . We quote the introduction to the FIPA’s goals from the FIPA’s home
7
FIPA’s “abstract architecture” must not be confused with the CaseLP “abstract architecture” introduced in Sec-
246
Architectures modeling
<<include>>
Modeling of
reusable comp.
<<include>>
Architectures designer
Roles and protocols
modeling
<<include>>
Ontologies modeling
Roles and interaction
protocol designer
Ontologies designer
Roles choice
<<include>>
Classes instantiat.
<<include>>
MAS instantiation
<<include>>
Ontologies instantiat.
<<include>>
MAS instantiation
Application designer
Creation of
agents’ code
D-CaseLP
Figure 7.2: Use case diagram for MAS modeling and code creation.
247
Configuration
<<include>>
Prototype
implementation
Legacy sw integr.
<<include>>
<<include>>
Communic. support
<<include>>
Mobility support
Prototype
configurator /
tester
Input definition
<<include>>
Prototype
execution
<<include>>
Output interpretation
D-CaseLP
Figure 7.3: Use case diagram for the prototype development and testing.
page, http://www.fipa.org.
FIPA is a non-profit organization, formed in 1996, aimed at producing standards
for the interoperation of heterogeneous software agents. In the production of these
standards, FIPA requires input and collaboration from its membership and from the
agent’s field in general to build specifications that can be used to achieve interoperability between agent-based systems developed by different companies and organizations. This is expressed more formally in FIPA’s official mission statement:
The promotion of technologies and interoperability specifications that facilitate the end-to-end interworking of intelligent agent systems in modern
commercial and industrial settings.
The emphasis here is on practical commercial and industrial uses of agent systems,
but the FIPA also focuses on intelligent or cognitive agents, that is, software systems
that may have the potential for reasoning about themselves and/or other systems that
they encounter.
The core message of FIPA is that through a combination of speech acts, predicate
logic and public ontologies, it is possible to offer standard ways of interpreting comtion 6.3.2: while FIPA’s abstract architecture deals with the way agents interoperate, CaseLP abstract architecture
deals with the agents’ internal model.
248
munication between agents in a way that respects the intended meaning of the communication. This is much more ambitious than, for example, XML, which only aims
to standardize the syntactic structure of documents.
To support this, FIPA has adopted and is working on specifications that range from
architectures to support agents’ communicating with each other, communication languages and content languages for expressing those messages and interaction protocols which expand the scope from single messages to complete transactions. In the
future, there are plans to extend this even further to cope with longer term relationships between agents.
FIPA specifications are mainly concerned with the following issues:
ò The Abstract Architecture, that is the infrastructure on which the agents perform their
operations.
ò The Agent Communication Language, that is the language that agents use to encode the
messages they exchange.
ò The Content Language, that is the language used to encode the content of a message,
namely the part of the message representing the domain dependent component.
ò The Protocols, namely the communication patterns the agent must respect to engage in a
communication.
All these issues are specified so as to adhere to the inspiring principles of FIPA8 :
ò Openness: agents can join or leave an agent system at run time without the need of recompiling or reconfiguring it. Moreover, an agent willing to communicate with another agent
needs to follow the FIPA naming conventions and registration process with the Directory
Facilitator to find the location of another agent.
ò Interoperability: the FIPA standards tend to specify the minimum set of requirements in order to avoid any commitments with particular hardware, operating system or programming
language. The interoperability issue is so important that it is often said that FIPA stands
for Foundation for InterOperable Agents, or Foundation for Interoperable Peer-to-peer
Agents.
ò Explicitness: information and assumptions about the agent system (the role and capabilities
of the agents, the way they interact, the meaning of the message content) should be as much
explicit as possible. In this respect, FIPA provides a number of features:
8
We are quoting the inspiring principles as stated in [52].
249
– the functionalities offered by the agents of a particular Agent Platform are described
explicitly by means of a Directory Facilitator (DF);
– using protocols makes predefined assumptions about interactions explicit;
– for the understanding of the domain-dependent information FIPA prescribes the use
of ontologies: by referring to the same ontology agents give the same meaning to
symbols contained in the messages.
ò External intelligence: FIPA concentrates on standardizing external intelligence or interoperability rather than the internal intelligence, namely the way the internal agent architecture
is structured and the control (“engine”, in CaseLP vocabulary) flows among components.
In order to ensure that these principles are respected, FIPA specifies the Abstract Architecture.
The primary focus of this abstract architecture is to create semantically meaningful message
exchange between agents which may be using different messaging transports, different Agent
Communication Languages, or different content languages. The scope of this architecture includes
ò Message transport interoperability.
ò Supporting various forms of ACL representations.
ò Supporting various forms of content language.
ò Supporting multiple directory services representations.
The abstract architecture proposed by FIPA cannot be directly implemented, but it forms the basis
for the development of concrete architectural specifications. In order for a concrete architectural
specification to be FIPA-compliant, it must include mechanisms for the registration and agent
discovery and inter-agent message transfer. Figure 7.4 shows the abstract architecture mapped to
various concrete realizations.
7.5
Tools suitable for implementing D-CaseLP
To achieve the goals stated in Section 7.2 related to the physical distribution of agents and to the
integration of heterogeneous software, we evaluated two existing products that seemed suitable
for both tasks. Sections 7.5.1 and 7.5.2 introduce CORBA and JADE, respectively, and Section
7.5.3 draws a comparison between them, taking into account the functionalities that we want to
provide with D-CaseLP and highlighting which tool turns out to be closer to our needs.
250
Figure 7.4: The FIPA abstract architecture mapped to instantiations.
251
7.5.1
CORBA
The Common Object Request Broker Architecture (CORBA) is a vendor-independent architecture and infrastructure to ensure interoperability across different operating systems and languages, whose specification is defined by the Object Management Group (OMG). Using the
standard protocol IIOP (Internet Inter-ORB Protocol), a CORBA-based program can interoperate with any other CORBA-based program.
CORBA’s main features9 , as described by S. Vinoski in [196], are:
ò ORB Core,
ò OMG Interface Definition Language (OMG IDL),
ò Interface Repository,
ò Language Mappings,
ò Stubs and Skeletons,
ò Dynamic Invocation and Dispatch,
ò Object Adapters and
ò Inter-ORB Protocols.
Figure 7.5 shows these features and the way the components of CORBA relate to one another.
ORB core. The main purpose of the ORB is to facilitate client/object communication by hiding
the following communication features:
ò Object location: The client does not know where the target object resides.
ò Object implementation: The client does not know how the target object is implemented, in
which language it is written and on which operating system it executes.
ò Object execution state: The client does not know whether the target object it makes a
request on is currently activated (i.e., in an executing process) and ready to accept requests
or not.
ò Object communication mechanisms: The client does not know which communication
mechanisms is used to deliver its request to the target object.
9
The version which we refer to is the 2.0.
252
Figure 7.5: CORBA’s main features (from [196]).
253
To make a request, the client specifies the target object by using an object reference, namely
a locally unique identifier for the object. There are three ways a client can obtain an object
reference:
ò Object creation: A client can create a new object in order to get an object reference.
ò Directory service: A client can invoke a lookup service of some kind in order to obtain
object references. The Naming Service and the Trading Service allow clients to obtain
object references by name or by properties of the object, respectively.
ò Convert to string and back: An application can ask the ORB to turn an object reference
into a string, and this string can be stored into a file or a database. Later, the string can be
retrieved from persistent storage and turned back into an object reference by the ORB.
OMG Interface Definition Language. In order for a client to access the services provided by
a server, it must know the server’s interface: which operations it supports and their syntax. The
OMG IDL is the language used to describe such interfaces. Interfaces are similar to classes in
C++ and interfaces in Java. An important feature of OMG IDL is its language independence.
Since OMG IDL is a declarative language, not a programming language, it forces interfaces to
be defined separately from object implementations. This allows objects to be constructed using
different programming languages and yet still communicate with one another.
Language mappings. OMG IDL does not provide features like control constructs, nor is it
directly used to implement distributed applications. Instead, language mappings determine how
OMG IDL features are mapped to the facilities of a given programming language. The OMG has
standardized language mappings for C, C++, Smalltalk, Ada 95 and Java.
Interface Repository. Often, an OMG IDL specification is compiled or translated into code for
the application’s programming language by following the translation rules for that language, as
defined by its language mapping. Then, this generated code is built directly into the application.
In this way the application’s knowledge of the OMG IDL type system is fixed when it is built.
In some cases this approach is infeasible and it would be much better if the application could
dynamically discover and utilize type information as needed. The CORBA Interface Repository
(IR) allows the OMG IDL type system to be accessed and written at runtime. The main utility
of CORBA IR lies in its support of CORBA dynamic invocation. It can also be used as a source
for generating static support code for applications, as described in the next paragraph.
Stubs and skeletons. In addition to generating programming language types, OMG IDL language compilers and translators also generate client-side stubs and server-side skeletons. A stub
254
Figure 7.6: The role of an Object Adapter (from [196]).
is a mechanism that effectively creates and issues requests on behalf of a client, while a skeleton is a mechanism that delivers requests to the CORBA object implementation. Since they are
translated directly from OMG IDL specifications, stubs and skeletons are normally interfacespecific. Dispatching through stubs and skeletons is often called static invocation, against the
dynamic invocation approach described below.
Dynamic invocation and dispatch. In addition to static invocation via stubs and skeletons,
CORBA supports two interfaces for dynamic invocation: Dynamic Invocation Interface (DII),
which supports dynamic client request invocation, and Dynamic Skeleton Interface (DSI), which
provides dynamic dispatch to objects. The DII and the DSI can be viewed as a generic stub and
generic skeleton, respectively. Each is an interface provided directly by the ORB, and neither is
dependent upon the OMG IDL interfaces of the objects being invoked.
Object adapters. The final subcomponent of CORBA, the Object Adapter (OA), serves as the
glue between CORBA object implementations and the ORB itself. An object adapter is an object
that adapts the interface of another object to the interface expected by a caller. In other words,
it is an interposed object that uses delegation to allow a caller to invoke requests on an object
even though the caller does not know that object’s true interface. The role of an object adapter is
shown in Figure 7.6.
Object adapters represent another aspect of the effort to keep the ORB as simple as possible.
Without object adapters, the ability of CORBA to support diverse object implementation styles
255
would be severely compromised since object implementations would connect themselves directly
to the ORB to receive requests.
Inter-ORB protocols. The last features standardized by CORBA are the inter-ORB protocols: The general ORB interoperability architecture is based on the General Inter-ORB Protocol
(GIOP), which specifies transfer syntax and a standard set of message formats for ORB interoperation over any connection-oriented transport. GIOP is designed to be simple and easy to
implement while still allowing for reasonable scalability and performance. The Internet InterORB Protocol (IIOP) specifies how GIOP is built over TCP/IP transports. The ORB interoperability architecture also provides for other environment-specific inter-ORB protocols (ESIOPs).
ESIOPs allow ORBs to be built for special situations in which certain distributed computing
infrastructures are already in use.
7.5.2
JADE
JADE (Java Agent Development Framework) is a software framework for the development of
multi-agent applications in compliance with the FIPA specifications. Its goal, as stated in [21]
from which we are basing all the JADE section, is to simplify the development of a MAS while
ensuring standard compliance through a comprehensive set of system services and agents. To
achieve such a goal, JADE offers the following features:
ò A FIPA-compliant Agent Platform, including the Agent Management System (AMS), the
default Directory Facilitator (DF) and the Agent Communication Channel (ACC).
ò A distributed agent platform implemented in Java, that can be split on several hosts.
ò A number of FIPA-compliant additional Directory Facilitators that can be started at run
time to build multi-domain environments10.
ò A Java API to send/receive FIPA ACL messages to/from other agents.
ò An implementation FIPA97-compliant of the IIOP protocol.
ò A library of FIPA interaction protocols ready to be used.
ò Support for agent mobility within a JADE agent platform.
ò A library to manage user-defined ontologies and content languages.
10
In JADE terminology, a domain is a logical set of agents, whose services are advertised through a common
facilitator.
256
ò A graphical user interface to manage and monitor several agents and agent platforms from
the same agent.
In Section 7.5.2.1 we will describe JADE as a runtime system for FIPA-compliant Multi Agent
Systems, supporting application agents whenever they need to exploit some feature covered by
the FIPA standard specification, while in Section 7.5.2.2 we will adopt another point of view,
describing JADE as a Java framework for developing FIPA-compliant agent applications.
7.5.2.1
JADE runtime system
Distributed agent platform. JADE includes all the system agents prescribed by the FIPA97
specification to manage an agent platform, namely the ACC, the AMS, and the default DF.
Agents communicate by exchanging FIPA ACL messages. A JADE agent platform is a distributed system that can be split over several hosts with one among them acting as a front end for
inter-platform IIOP communication. A JADE system is made by one or more Agent Containers,
each one living in a separate Java Virtual Machine and communicating using Java RMI. Figure
7.7 shows the architecture of a JADE Agent Platform and its composing elements:
ò Scheduler of behavior. It is the scheduler of behavior inherited by extending the Agent
class.
ò Private message inbox. It contains messages arrived to the agent.
ò Life-cycle manager. It provides the platform with the methods to manage the agent’s life
cycle.
ò Active agent behaviors. It is the set of scheduled behaviors.
ò Application dependent agent resource. They are the components defined by the JADE
agents’ programmers; for example, they may contain the data structures necessary to the
agents to perform their tasks.
Message delivery subsystem. Each JADE agent, in compliance to the FIPA agent model, has a
globally-unique identifier (GUID), that can be used by every other agent to address it. The GUID,
according to FIPA97 specifications, has the form ó agentname ô @ ó platformaddress ô . When
an ACL message is sent to a software agent, three situations can take place:
1. The receiver of the message is on the same container of the same platform. In this case,
Java events are used and the message is simply cloned.
257
Figure 7.7: JADE Agent Platform (from [21]).
2. The receiver is on a different container of the same platform: Java RMI is used, the message is serialized at sender side, a remote method is called and the message is unserialised
at receiver side.
3. Sender and receiver reside on different platforms. In this situation IIOP is used and the
message is sent by means of a remote CORBA call.
Address management and caching. JADE tries to select the most convenient of the three
transport mechanisms above according to agents location. Basically, each container has a table
of its local agents, called the Local-Agent Descriptor Table (LADT), whereas the front-end,
besides its own LADT, also maintains a Global-Agent Descriptor Table (GADT), mapping every
agent into the RMI object reference of its container. JADE uses an address caching technique to
avoid querying the front-end continuously for address information. Besides being efficient, this
is also meant to support agent mobility, where agent addresses can change over time.
Mobility. The new JADE version adds the support for agent mobility by exploiting Java Serialization API and dynamic class loading. This allows to move or clone a JADE agent over
different containers but within the same JADE agent platform.
User-defined ontologies and content languages. While FIPA promotes the use of the FIPA
ACL communication language, it explicitly allows application dependent content languages and
258
ontologies. The last version of JADE lets application programmers create their own content
languages and their ontologies.
Tools for platform management and monitoring. JADE supports agent platform management and debugging of agent societies; the tools for performing these tasks are implemented
as FIPA agents and require no special support. The general management console for a JADE
agent platform is called RMA (Remote Monitoring Agent). The RMA acquires the information
about the platform and executes the GUI commands to modify the status of the platform (creating
agents, shutting down containers, etc.) through the AMS. The Directory Facilitator agent also
has a GUI, with which it can be administered, configuring its advertised agents and services. Finally, JADE provides its users with the Dummy Agent and the Sniffer Agent to inspect message
exchange, interactively test an agent behavior and track messages exchanged within a platform.
7.5.2.2
JADE agent development model
From agent theory to class design. In order for the JADE entities to respect the FIPA definition of agenthood, the following design considerations were made:
ò Agents are autonomous, then they are active objects [128] with at least one Java thread,
to proactively start new conversations, make plans and pursue goals.
ò Agents are social, then intra-agent concurrency is needed.
ò Messages are speech acts, then asynchronous messaging must be used. This also has the
benefit of producing more reusable interactions [183].
ò Agents can refuse accomplishing a task required by other agents, then peer-to-peer communication model is needed, as opposed to client/server systems where the receiver is
supposed to obey the sender.
JADE agent concurrency model. The above considerations help in deciding how many threads
of control are needed in an agent implementation: the autonomy requirement forces each agent
to have at least one thread, and the sociality requirement pushes towards many threads per agent.
JADE adopts the behavior abstraction to model agent tasks: a collection of behaviors are scheduled and executed to carry on agent duties. Behaviors represent logical threads of a software
agent implementation. A general rule for transforming an ordinary Java method into a JADE
behavior is:
1. Turn the method body into an object whose class inherits from Behaviour (see next paragraph).
259
2. Turn method local variables into behavior instance variables.
3. Add the behavior object to agent behavior list during agent start-up.
Using behaviors to build complex agents. The developer implementing an agent must extend
Agent class and implement agent-specific tasks by writing one or more Behaviour subclasses.
User defined agents inherit from their superclass the capability of registering and deregistering
with their platform and a basic set of methods for sending and receiving ACL messages, using
standard interaction protocols, registering with several domains, managing the behavior list. It is
interesting to describe the communication primitives supported by JADE agents, since they are
conceptually the same we provide within the CaseLP framework (see Section 6.5.9):
ò send(): allows sending a FIPA ACL message asynchronously.
ò blockingReceive(): allows to access the agent’s mailbox in blocking mode, letting the
agent wait for incoming messages whose pattern matches the specified one.
ò receive(): allows the agent to retrieve a message matching some pattern from the mailbox.
If no messages matching the pattern are found, the method returns null.
Behaviour is an abstract class that provides the skeleton of the elementary task to be performed.
A subclass of Behaviour, SimpleBehaviour, is used to implement the steps which must be
executed as an atomic unit. Simple behaviors can be composed to form composite behaviors: the
ComplexBehaviour class is itself a Behaviour with some sub-behaviors or children. Finally,
two more subclasses of Behaviour are used to send and receive messages: SenderBehaviour
and ReceiverBehaviour.
7.5.3
CORBA vs JADE for the development of D-CaseLP
This section is based on the comparison between CORBA and JADE drawn by R. Albertoni in
[6]. The comparison is carried out taking into account the support provided to:
1. communication,
2. FIPA’s Message Transport System,
3. FIPA’s Directory Name Service,
4. agents’ distribution,
5. heterogeneous software integration,
260
Functionality
JADE
Communication
peer-to-peer, FIPA-compliant
FIPA’s MTS
FIPA’s DNS
Agents’ distribution
Heterogeneous sw integration
Semantic integration
Mobility
Management and monitoring
Supported, with some MTSs
already implemented
Supported
Supported
Software that can be integrated with Java
Supported
Supported (proprietary implementation)
Supported (RMA, Sniffer
Agent)
CORBA
client-server;
consumer
supplier-
Not supported
It may be implemented
Supported
C, C++, Smalltalk, Ada 95,
Java
Not supported
Not supported
Not supported
Table 7.1: A comparison between JADE and CORBA.
6. semantic integration (ontologies),
7. mobility, and
8. management and monitoring of agent execution.
Table 7.1 summarizes the results of the comparison.
7.5.3.1
Communication
CORBA. Communication in CORBA is based on a client-server model. To implement the DCaseLP communication primitives, send, sync receive and async receive, we may define,
for each D-CaseLP agent, a CORBA placeholder object acting as a server for communication
and maintaining a mailbox the agent can interact with. Figure 7.8 shows this solution. Since a
placeholder must be able to manage more incoming and outcoming messages at the same time,
it may be organized as a set of concurrent threads.
An alternative solution is represented by the standard CORBA Event Service which allows asynchronous communication by means of a supplier-consumer model. The two reception modes for
the consumer, blocking and not blocking, could be adopted to implement the sync receive and
async receive respectively.
261
Figure 7.8: Agent communication in CORBA: one possible solution.
JADE. JADE supports a peer-to-peer communication model, obtained by means of asynchronous message passing. The three communication primitives that we will implement in DCaseLP, namely send, sync receive and async receive, have a one-to-one counterpart in
JADE’s communication primitives send(), blockingReceive() and receive(). The D-CaseLP
primitives may be easily implemented by means of the corresponding JADE ones, provided
that our D-CaseLP agents extend JADE’s Agent class to access the functionalities it provides.
Besides this, it will be necessary a conversion of the message format which is sketched in the
Chapter 4 of [6].
7.5.3.2
FIPA’s Message Transport System
CORBA. No support.
JADE. Once the D-CaseLP communication primitives will be implemented using the JADE
ones, it will be possible to exploit the MTS services that the JADE platform already provides.
In JADE, the transport layer over which the message is sent is transparent to the agents and
is completely managed by the JADE platform. Thus, if we will be able to build D-CaseLP
agents dressed up as JADE agents, we will access all the facilities already provided by the JADE
platform.
262
7.5.3.3
FIPA’s Directory Name Service
CORBA. CORBA offers a Name Service for registering and locating objects by means of
an identifier, and an Object Trade Service which helps in finding objects that provide certain
services. If we use placeholder objects for interfacing the D-CaseLP agents with the CORBA
middleware, it is possible to use the Name Service to locate the placeholder and thus the agent
behind it. Similar considerations hold for for the Object Trade Service.
JADE. The considerations we made for the support to FIPA’s MTS, also hold for the FIPA’s
DNS: JADE provides a DF realized as an agent which is automatically activated when the platform is initialized.
7.5.3.4
Agents’ distribution
CORBA. CORBA is conceived as a middleware for integrating heterogeneous software systems distributed across a network, and thus it obviously supports distribution. What CORBA
lacks in, is the support for the start-up and configuration of the remote objects: the user must
access the remote hosts and activate the necessary processes by hand, using the services offered
by the remote operating system.
JADE. JADE allows to run agents within a distributed platform composed by a main container
and other “normal” containers residing on different hosts. Like CORBA, it does not offer support
for the start-up of remote containers, but this is achieved using simple shell commands, provided
that the remote hosts are reachable via telnet or similar services. As an example, to start-up a
distributed platform over two hosts, hostname1 and hostname2, it will be necessary to access
the first host and launch the command
java jade.Boot -gui -host hostname1
and then, access hostname2 and launch the command
java jade.Boot -container -host hostname1
which will activate the second container, linking it to the main container running on hostname2.
7.5.3.5
Heterogeneous software integration
CORBA. As we wrote in the paragraph “Language mappings”, in Section 7.5.1, OMG has
standardized language mappings for a set of programming languages. Thanks to these standard
263
mappings, CORBA makes the integration of C, C++, Smalltalk, Ada 95 and Java possible.
JADE. JADE’s target is not to integrate external software, but to implement a FIPA-compliant
platform for developing agents written in Java by extending the proper Java classes provided
within the JADE package. However, for all the languages and the software packages which can
be integrated in Java programs, the integration within JADE agents will come for free.
7.5.3.6
Semantic integration
CORBA. No support.
JADE. JADE supports the creation of user-defined content languages and ontologies: every
JADE agent keeps a capability table where the known languages and ontologies are listed. If a
user-defined ontology is defined, the application can register a suitable Java class to play an ontological role, and JADE is able to convert the representation of concepts and their relationships
from frames to user defined Java objects and vice-versa. Acting this way, application programmers can represent their domain specific concepts as familiar Java classes, while still being able
to process them at the agent level (put them within ACL messages, reasoning about them, etc.).
7.5.3.7
Mobility
CORBA. No support.
JADE. We have already written that the new JADE version supports mobility. Currently,
the implementation is completely proprietary and does not allow inter-platform mobility over
the FIPA IIOP standard message transport service. However, FIPA has not yet standardized
mobility specifications; JADE authors are waiting for this standardization to build an effective
and interoperable implementation.
7.5.3.8
Management and monitoring of agent execution
CORBA. No support.
JADE. As far as management is concerned, the Agent Management System is the agent that
exerts supervisory control over access to and use of the platform; it is responsible for maintaining
a directory of resident agents and for handling their life cycle. Thanks to the Remote Monitoring
264
Agent, to the Dummy Agent and to the Sniffer Agent it is possible to monitor the execution of
the agents in the platform.
7.6
Developing D-CaseLP with JADE
According to the results of the comparison between CORBA and JADE described above, we
plan to adopt JADE for implementing D-CaseLP because it offers a set of already developed
facilities which will simplify our work and, moreover, it adheres to FIPA’s abstract architecture
specification.
The reader could ask why do we need to develop D-CaseLP if there is JADE already available.
The reason is that in our plans D-CaseLP will offer more functionalities than the ones offered
by a platform for running and monitoring distributed agents: it will be a complete framework for
supporting all the MAS development stages from the high-level specification to the final product
implementation, together with an associated methodology. To reach our goal and to reuse both
the work done and the experience gained with CaseLP, we need to model our agents according
to the dimensions we discussed in Section 6.2, namely roles and architectures. JADE’s agent
model is different from ours and for this reason we cannot use JADE agents as they are. Moreover, the JADE environment neglects the translation of high-level specification into executable
agents which is crucial in D-CaseLP and, more in general, in the ARPEGGIO project.
In order to use JADE for our purposes, we need to satisfy the following constraints:
ò Constr-1: D-CaseLP agents must extend the Agent JADE class.
ò Constr-2: The agents’ architecture must be expressed in terms of JADE Behaviour class.
Both choices are necessary to make D-CaseLP agents look like JADE agents, at least in the
interface they offer and in the way they are internally structured. This will allow us to take
advantage of all the facilities that JADE offers.
As far as the first choice is concerned, it is not a problem to make a Java agent extend the Agent
class, while it is more tricky to build ProlAg agents that meet this requirement. We shortly
discuss this issue in Section 7.6.1. The second choice implies the development of methodological
guidelines for structuring agent architectures as a set of concurrent behaviors. At the moment
we plan to organize agent architectures in only one behavior: the inclusion of more concurrent
behaviors and the development of the proper methodological guidelines are part of our future
work.
265
Name
SICStus Prolog [182]
SWI-Prolog [193]
BinProlog [24]
tuProlog * [65]
Jinni * [194]
jprolog * [114]
MINERVA * [151]
Type
Comp/bin
Comp/bin
Comp
Int/lib
Interpreter
Interpreter
Comp
License
Commercial
Free software
Commercial
Free for no profit
Commercial
Free software
Commercial
Java interface
Jasper
JPL
Bidirectional via library
Bidirectional via library
Built-in (bidirectional)
Java may call Prolog
Built-in (bidirectional)
Table 7.2: A comparison between different Prolog implementations.
7.6.1
Integration of ProlAg and JADE
Chapter 5 of [6] describes one possible way to integrate ProlAg agents within the JADE platform. Since ProlAg is an extension of Prolog, the first question to answer is which Prolog implementation can be used for developing ProlAg agents to be easily integrated in a Java-based
platform. Table 7.2 summarizes the results of a comparison among different Prolog implementations that provide an interface towards Java. The Prolog implementations marked by an asterisk
are developed in Java. “Comp” stands for compiler, “int” for interpreter, “bin” for binary, “lib”
for library and “transl” for translator. The analysis of these Prolog systems allowed us to identify
tuProlog as the most suitable system for our purposes. tuProlog has been conceived with three
major purposes in mind:
1. offering a minimal and efficient Prolog engine encapsulated within a Java object;
2. allowing the extension of this minimal engine with dynamic libraries;
3. allowing the interaction with Internet components.
tuProlog offers the support for integrating Prolog predicates within a Java program and Java
objects inside Prolog programs. This integration does not exploit Java Native Interface or object
code: it is completely portable because the inferential engine of tuProlog programs is implemented as pure Java objects. Since JADE is developed in Java, it is possible to develop agents
that extend the JADE “Agent” class, satisfying the first condition Constr-1, and that use the
tuProlog “IsoLibrary”, “JavaLibrary” and “MetaLibrary” for calling Prolog (and, in our case,
ProlAg) predicates. JADE agents of this kind may be defined in terms of only one behavior, ResolveEngine, which specializes the JADE CyclicBehaviour by redefining the action() method
so that the agent, when scheduled, may call the predicate defining the agent architecture engine.
In this way, the constraint Constr-2 is satisfied too.
266
7.7
Conclusions
The analysis we carried out on existing MASDKs (Chapter 4) put in evidence one limitation
of CaseLP: its lack of support to real distribution and real concurrency among agents. Nevertheless, the same comparison confirmed us in our opinion that systems for engineering MASs
are really needed to make the agent technology well established, and that CaseLP approach to
tackle this problem was extremely promising.
The D-CaseLP project is born to overcome CaseLP limitations still maintaining and even improving its software engineering features. The project started at the beginning of year 2001. The
results we obtained in one year of work are mainly concerned with the design of the system:
we begun to work with very ambitious ideas in mind, ready to face a long design stage in order
to develop an up-to-date system, able to cope with the users real needs and taking into account
existing standards and technologies. We are very satisfied of the results we obtained:
ò We started studying and understanding FIPA’s specifications: if the importance of FIPA
will continue growing at the current pace, it is likely that only FIPA-compliant frameworks
will have a chance to be widely adopted.
ò We draw an interesting comparison between CORBA and JADE as tools for building
agents: being more general-purpose, CORBA offers less support than JADE for developing agents. When we started analyzing JADE, we discovered with pleasure that it already
faced and solved many of our problems.
ò Finally, we also analyzed different Prolog systems, identifying in tuProlog the most suitable one for our aims. A set of very concrete suggestions on how integrating tuProlog in
JADE has been provided, even if no preliminary version of D-CaseLP has been implemented yet.
To obtain a working version of D-CaseLP some efforts still need to be done. In particular, there
are two main directions to follow:
ò We must implement the ideas that have been designed so far for distributing the computation, for allowing concurrent execution of agents and for easily integrating external
software.
ò We must work on the integration of UML in D-CaseLP, and on the development of libraries of agent architectures.
267
Chapter 8
Conclusions
As we stated in the Introduction, the goal of this thesis was
To take a first concrete step towards the realization of the ARPEGGIO framework
by deeply analyzing the potentialities and limitations of existing specification languages and development environments for agents and MAS, and by using the results
of this analysis to improve two of the systems included in the ARPEGGIO framework,
IMPACT and CaseLP.
We planned to carry out our intent by surveying and analyzing the state-of-the-art of agent specification languages, in particular logic-based ones; by analyzing and comparing some existing
MASDKs according to a set of evaluation criteria developed by ourselves; by deepening our acquaintance with the IMPACT toolkit and extending it according to the results of our MASDKs
comparison; and finally by designing an extension of the CaseLP environment to make it closer
to the ARPEGGIO philosopy.
In the following we summarize the results we achieved for each of the goals above, and in Section
8.2 we outline the next steps to take towards ARPEGGIO’s development.
8.1
Achieved results
Specification languages survey and analysis. In Chapter 2 we provided an overview on both
the UML and Z specification languages, and we discussed extensions to these languages to cope
with agent features. The main usefulness of this survey was to show advantages and drawbacks
of the adoption of informal methods for agent-oriented software engineering, discussed in Section 2.6, and to provide the reader with the means for understanding the technical details of
268
UML’s integration in CaseLP, discussed in Section 6.5.3. However, since our interest is mainly
addressed to logical approaches for agents and MASs specification, execution and verification,
the most original and interesting results we achieved are contained in Chapter 3. In this chapter
we described six formalisms which have proven useful to capture the notion of agenthood: the
situation calculus, modal logic, deontic logic, dynamic logic, temporal logic and linear logic. For
each formalism, we analyzed a concrete language for agent specification and execution based on
that formalism: ConGolog, based on the situation calculus, AGENT-0, based on modal logic,
the IMPACT programming language, which includes deontic operators, Dylog, based on dynamic logic, Concurrent METATEM, based on temporal logic and õ hhf , based on linear logic.
Besides this, we developed examples to show how the concrete languages we discussed can be
used to model agents. These examples are all instances of the same problem, namely which
actions a seller agent must take whenever it receives a proposal from a buyer agent, according to
its internal state and to the current state of the environment. This problem, though being almost
simple, involves issues such as communication and concurrent action execution. Showing how
these issues can be faced in the various languages by means of the same running example proved
extremely useful for a deep understanding of the languages’ similarities and differences. In fact,
another valuable contribution of the survey is the comparison among ConGolog, AGENT-0, the
IMPACT programming language, Dylog, Concurrent METATEM and õ hhf that we carried out
along the following dimensions: management of time, sensing capabilities, communication facilities, constructs to define procedures, support to concurrency and nondeterminism, definition
of a formal semantics and existence of a working interpreter for the language. Up to our knowledge, no such a deep comparison among these languages has ever been carried out. The last
contribution of the chapter is a discussion of advantages and drawbacks of the use of a logical
approach to specification, execution and verification, and of the use of logic programming for
MAS prototyping.
MASDK evaluation and comparison. In Chapter 4 we provided a methodology and general
guidelines for selecting a multi-agent system development kit for realizing a MAS taking on
an application-driven perspective. We defined a number of criteria of agent systems which are
relevant to this choice, and related them to various common scenarios and application domains.
Different from related earlier work in the literature, we also evaluated five existing MASDKs,
AgentBuilder, CaseLP, DESIRE, IMPACT, and Zeus, on these criteria. According to our experience, guidelines for application-driven MASDK selection are barely needed, and we received
encouraging feedback in this matter. We think that our work is also of interest to the agent researcher, since it provides a handle to classify and compare any generic agent system tool which
she develops to other such tools on a set of established features. The MASDKs evaluation and
comparison we carried out, though not covering enough MASDKs to allow statistical conclusions, highlighted the growing attention paid by MASDKs developers to software engineering
issues. We think that the MAS developers have a pressing need of facilities for unburdening
their task, and a toolkit for building a MAS must provide them. For this reason, we think that
269
a framework like ARPEGGIO should be welcome by the agent community. From our analysis
two more issues emerged that guided us in the next stages of our thesis work, concerned with
improving IMPACT and CaseLP functionalities:
ò Apart from CaseLP, all the toolkits support physical distribution of the agents and their
real concurrency. These features are very important because they allow the development
of applications closer to the final one.
ò No toolkit provides support for error-tolerance, though this feature is extremely useful in
various application fields.
According to these issues, we decided to design a new version of CaseLP augmented with the
more “basic” features of distribution and concurrency, and to extend IMPACTwith error-tolerant
capabilities, in order to make it even more solid than it is. The following paragraphs summarize
the results we achieved in these tasks.
IMPACT extension. The need of extending IMPACT with error-tolerant capabilities arises
from our observation that, when dealing with frameworks for building agents that access legacy
code, interact with other entities to respond to their requests, and respect some integrity constraints, two major problems may show up.
1. First, most agent frameworks, including IMPACT, assume that the rules used are sufficient
to appropriately respond to all requests that arrive. Clearly, this assumption is rather optimistic;
the question of what to do when an agent is confronted with a situation for which it does not
know how to act must be addressed in order to develop a reliable framework.
2. Second, in the case of legacy systems, the legacy system’s existing GUI and the agent both
access and update the same data. Thus, the legacy GUI may alter the agent’s state in ways that
the agent may find unacceptable since they violate its integrity constraints.
In Chapter 5 we presented a theory, architecture and algorithms so that agents may:
1. (Recovery) recover from being “corrupted” to being “uncorrupted” and
2. (Continuity) continue to process some (though perhaps not all) requests while continuing
to recover. This is important when an agent is servicing lots of requests.
This contribution is, in our opinion, extremely relevant for the entire agent community, as we
have shown in Chapter 4. Besides, it is surely an original contribution: we are not aware of
agent architectures, environments or formalisms which allow the development of error-tolerant
270
agents in the sense we conceive them. We have demonstrated the generality of our algorithms for
ensuring recovery and continuity by adapting them to different logic-based agent architectures
including CaseLP. Among the issues we plan to address in the future, there is the extension of
D-CaseLP with error-tolerant features.
CaseLP extension. CaseLP represents a first research step towards a real environment for
MAS specification and prototyping. It is a logic-based framework which allows to specify agents
using logic languages (õ hhf ) and its implementation is based on Prolog. In the last years, some
efforts have been made to include more widely used specification languages, UML in particular,
in the framework. In Chapter 6 we organized and synthesized the results we achieved in the four
years we worked at CaseLP design and development [140, 141, 142, 145, 30, 29, 58, 59, 144,
143, 8, 139, 138]: we discussed its agent model, the hierarchy of abstraction levels it supports, its
methodology and the tools and languages it provides for helping the prototype developer in her
task. By means of a case study (Section 6.7.1) we demonstrated that CaseLP can be successfully adopted to model complex applications which require a fast prototyping stage for rapidly
getting simulation results. The vehicle monitoring application we simulated with CaseLP has
been implemented in a section of the Salerno–Reggio Calabria motorway: this concrete result
demonstrates CaseLP suitability for fast prototyping. Nevertheless, according to the results we
obtained from our work on MASDK evaluation and classification, we understood that CaseLP
has some limitations that should be overcome in order to obtain a MASDK which can be used
by wider teams of developers outside the walls of our department. For this reason, at the beginning of year 2001, we started to design the improved version of CaseLP, D-CaseLP. The
D-CaseLP project aims at extending CaseLP by integrating new specification and implementation languages, by physically distributing the agents, and by supporting the development of
the final application. D-CaseLP is conceived as a long-term project: during the first year we
obtained results in the design of some issues above. As a preliminary work, we started studying
and understanding FIPA’s specifications: we plan to make D-CaseLP FIPA-compliant to allow
it interoperate with other FIPA-compliant MASDKs. Besides this, we drew an interesting comparison between CORBA and JADE as tools for building agents. JADE turned out to be closer
to our needs and we plan to adopt it for D-CaseLP development. We also analyzed different
Prolog systems to be integrated in JADE. We identified in tuProlog the most suitable one for
our aims. Finally, a set of very concrete suggestions on how integrating tuProlog in JADE has
been provided. Even if the chapter on D-CaseLP reads more as an “extended future work”
rather than as a documentation of achieved results, we think that the issues faced for designing
D-CaseLP may be interesting and useful for researchers involved in the development of a new
MASDK or in the extension of some existing toolkit.
271
8.2
Future work
Most of the future directions of our work have been already outlined throughout this thesis, in
the “Conclusions” sections at the end of each chapter. Here we shortly summarize them.
MASDK evaluation and comparison. Our work on MASDKs evaluation and comparison can
be augmented in various directions. A first direction is to extend our analysis to a larger set of
existing MASDKs, in order to draw more statistically relevant conclusions than the ones we
obtained in this initial phase. Another direction, which is orthogonal to the previous, is to extend
and refine the set of criteria which we fostered for MASDK characterization.
IMPACT error-tolerant agents improvement. The improvement that can be brought to IMPACT error-tolerant algorithm deals with considering action status atoms as affected, rather than
action atoms. We could make a syntactic analysis of the agent programs similar as the one
described in Chapter 5, obtaining a refined (and much more involved) version of the algorithm.
D-CaseLP development. To obtain a working version of D-CaseLP we must implement the
ideas that have been designed so far for distributing the computation, for allowing concurrent
execution of agents and for easily integrating external software. We also must go on working on
the integration of UML in D-CaseLP, and on the development of libraries of agent architectures.
Extension of D-CaseLP agents with error-tolerant capabilities. In Section 5.5.2.4 we sketched how the IMPACT error-tolerant algorithm can be adapted to CaseLP. Once the implementation of D-CaseLP will be completed, we plan to adapt this algorithm to the new framework.
Integration of IMPACT and D-CaseLP. We think that, in order to implement ARPEGGIO,
we may start with integrating IMPACT and D-CaseLP. After the D-CaseLP development will
be completed, we will attack the problem of allowing agents specified as IMPACT programs
to co-exist and interact with agents written in ProlAg and Java. This should allow us to take
advantage of both IMPACT’s and D-CaseLP’s facilities. This first prototype of the ARPEGGIO
environment should be scalable enough to allow the support of new languages for specifying and
implementing agents without redesigning it. Among the facilities to be supported in a successive
phase, there will be the ones offered by PipeDream (http://goanna.cs.rmit.edu.
au/˜winikoff/pipe/vision.html).
272
Credits
The work described in this thesis was possible thanks to the collaboration of many persons:
my advisor M. Martelli and my external reviewers T. Eiter (Knowledge-Based Systems
Group, University of Technology, Vienna, Austria) and L. Sterling (Department of Computer Science and Software Engineering, University of Melbourne, Victoria, Australia),
who carefully read the thesis and gave me precious suggestions on how improving its
quality;
the president and CEO of Reticular Systems, Inc., D. Ballard; all the participants to
the Zeus mailing list; C. M. Jonker and J. Treur from the DESIRE team; and J. Dix,
T.J. Rogers, and V.S. Subrahmanian from the IMPACT group, who kindly answered to our
numerous questions on AgentBuilder, Zeus, DESIRE and IMPACT respectively, making
it possible to draw the comparison described in Chapter 4;
M. Baldoni (Computer Science Department, University of Turin, Italy), for his clarification
on issues related with Dylog;
M. Bozzano (ITC - IRST, Trento, Italy) and G. Delzanno (Computer Science Department,
University of Genova, Italy), for having provided me with material and knowledge on
linear logic and õ hhf ;
E. Appiani (Elsag s.p.a., Genova, Italy), with whom I had the pleasure to collaborate
during these years in particular for the development of the application depicted in Section
6.7;
the students S. Marini, R. Degl’Innocenti, R. Albertoni and S. Miglia who worked with
enthusiasm and valuable results at the development of CaseLP and D-CaseLP.
Part of the research described in this thesis was carried out while I was visiting the University of
Technology of Vienna, Austria.
273
Bibliography
[1] S. Abiteboul, R. Hull, and V. Vianu, editors. Foundations of Databases. Addison Wesley,
1995.
[2] S. Adali and V. S. Subrahmanian. Intelligent caching in hybrid knowledge bases. In
N. Mars, editor, Proc. of 1995 International Conference on Very Large Knowledge Bases,
pages 247–256, Twente, The Netherlands, 1995. IOS Press.
[3] P. E. Agre and D. Chapman. What are plans for? In P. Maes, editor, Designing Autonomous Agents: Theory and Practice from Biology to Engineering and Back, pages
17–34, Cambridge, MA, 1991. The MIT Press.
[4] S. Albayrak, editor. Proceedings of the Intelligent Agents for Telecommunication Applications, Third International Workshop, IATA ’99, Stockholm, Sweden, 1999. Springer.
LNCS 1699.
[5] S. Albayrak and F. J. Garijo, editors. Proceedings of the Intelligent Agents for Telecommunication Applications, Second International Workshop, IATA ’98, Paris, France, 1998.
Springer. LNCS 1437.
[6] R. Albertoni. D-CaseLP: un ambiente distribuito per l’integrazione di agenti eterogenei.
Master’s thesis, DISI – Università di Genova, Genova, Italy, 2001. In Italian.
[7] C. E. Alchourrón and E. Bulygin, editors. Normative Systems. Springer, 1971.
[8] E. Appiani, M. Martelli, and V. Mascardi. A multi-agent approach to vehicle monitoring
in motorway. Tech. Report DISI TR-00-13, 2000. Poster session of the 2nd European
Workshop on Advanced Video-based Surveillance Systems, AVBS 2001.
[9] M. Arenas, L. Bertossi, and J. Chomicki. Consistent query answers in inconsistent
databases. In Proceedings of PODS’99, pages 68–79, Philadelphia, 1999. ACM Press.
[10] M. Arenas, L. Bertossi, and M. Kifer. Applications of annotated predicate calculus to
querying inconsistent databases. In Proceedings of DOOD’2000, pages 926–941, London,
UK, 2000.
274
[11] A. Aretti. Semantica di sistemi multi-agente in logica lineare. Master’s thesis, DISI –
Università di Genova, Genova, Italy, 1999. In Italian.
[12] K. Arisha, T. Eiter, S. Kraus, F. Ozcan, R. Ross, and V.S. Subrahmanian. IMPACT: A
platform for collaborating agents. IEEE Intelligent Systems, 14(2):64–72, 1999.
[13] M. Baldoni. Normal Multimodal Logics: Automatic Deduction and Logic Programming
Extension. PhD thesis, Dipartimento di Informatica, Università degli Studi di Torino, Italy,
1998. Available at http://www.di.unito.it/˜baldoni.
[14] M. Baldoni, L. Giordano, A. Martelli, and V. Patti. An abductive proof procedure for
reasoning about actions in modal logic programming. In J. Dix, L. M. Pereira, and T. C.
Przymusinski, editors, Proc. of the 2nd International Workshop on Non-Monotonic Extensions of Logic Programming, NMELP’96, pages 132–150. Springer-Verlag, 1997. LNAI
1216.
[15] M. Baldoni, L. Giordano, A. Martelli, and V. Patti. Modal programming language for
representing complex actions. In Proc. of DYNAMICS’98: Transactions and Change in
Logic Databases, pages 1–15, 1998. Technical Report MPI-9808.
[16] M. Baldoni, L. Giordano, A. Martelli, and V. Patti. Modeling agents in a logic action
language. In Proc. of Workshop on Practical Reasoning Agents, FAPR2000, London, UK,
2000.
[17] M. Baldoni, L. Giordano, A. Martelli, and V. Patti. Reasoning about complex actions with
incomplete knowledge: A modal approach. Technical report, Dipartimento di Informatica,
University of Torino, 2000. Technical Report 53/2000.
[18] C. Baral, S. Kraus, J. Minker, and V.S. Subrahmanian. Combining multiple knowledge
bases consisting of first order theories. Computational Intelligence, 8(1):45–71, 1992.
[19] H. Barringer, M. Fisher, D. Gabbay, G. Gough, and R. Owens. Metatem: A framework
for programming in temporal logic. In Proc. of Workshop on Stepwise Refinement of
Distributed Systems: Models, Formalisms, Correctness. Springer-Verlag, 1989. LNCS
430.
[20] B. Bauer, J. P. Müller, and J. Odell. Agent UML: A formalism for specifying multiagent
software systems. In P. Ciancarini and M. Wooldridge, editors, Agent-Oriented Software
Engineering - First International Workshop, AOSE 2000, pages 91–103, Limerick, Ireland, 2000. Springer-Verlag. LNCS 1957.
[21] F. Bellifemine, A. Poggi, and G. Rimassa. Developing multi-agent systems with JADE.
In Intelligent Agents VII, pages 89–103. Springer-Verlag, 2001. LNAI 1986.
275
[22] A. Bieszczad, Y. Li, B. Pagurek, and G. Susilo. Network configuration management in
heterogeneous ATM environments. In S. Albayrak and F. J. Garijo, editors, Intelligent
Agents for Telecommunication Applications. Proceedings of IATA’98, Paris, France, 1998.
Springer. LNAI 1437.
[23] A. Bieszczad, B. Pagurek, and T. White. Mobile agents for network management. IEEE
Communication Surveys, 1(1):2–9, 1998.
[24] BinProlog. BinNet Corporation. http://www.binnetcorp.com/BinProlog/.
[25] H. Blair and V.S. Subrahmanian. Paraconsistent Logic Programming. Theoretical Computer Science, 68:135–154, 1989.
[26] A. Blass. A game semantics for linear logic. Annals of Pure and Applied Logic, 56:183–
220, 1992.
[27] P. Bonatti, S. Kraus, and V. S. Subrahmanian. Secure agents. Computer Science Department Technical Report, CS-TR-4068, University of Maryland, 1999.
[28] M. Bozzano. A Logic-Based Approach to Model Checking of Parameterized and InfiniteState Systems. PhD thesis, Computer Science Department of Genova University, Genova,
Italy, 2002. Technical Report DISI-TH-2002-01.
[29] M. Bozzano, G. Delzanno, M. Martelli, V. Mascardi, and F. Zini. Logic programming
& multi-agent systems: A synergic combination for applications and semantics. In K.R.
Apt, V.W. Marek, M. Truszczynski, and D.S. Warren, editors, The Logic Programming
Paradigm: a 25-Year Perspective, pages 5–32. Springer Verlag, 1999.
[30] M. Bozzano, G. Delzanno, M. Martelli, V. Mascardi, and F. Zini. Multi-agent systems
development as a software engineering enterprise. In G. Gupta, editor, Proc. of First
International Workshop on Practical Aspects of Declarative Languages (PADL’99), pages
46–60, San Antonio, Texas, 1999. Springer-Verlag. LNCS 1551.
[31] J. Bradshaw. Introduction to software agents. In J. Bradshaw, editor, Software Agents,
pages 3–47. AAAI Press/The MIT Press, 1997.
[32] F. Brazier, B. Dunin-Keplicz, N. R. Jennings, and J. Treur. Formal specification of multiagent systems: A real-world case. In Proceedings of the First International Conference
on Multi-Agent Systems (ICMAS-95), pages 25–32, San Francisco, CA, 1995.
[33] F. M. T. Brazier, F. Cornelissen, R. Gustavsson, C. M. Jonker, O. Lindeberg B. Polak, and
J. Treur. A Multi-Agent System Performing One-to-Many Negotiation for Load Balancing
of Electricity Use. Manuscript, 2000.
276
[34] F. M. T. Brazier, F. Cornelissen, C. M. Jonker, and J. Treur. Compositional specification
of a reusable co-operative agent model. International Journal of Cooperative Information
Systems. In press., 1999.
[35] F. M. T. Brazier, C. M. Jonker, and J. Treur. Modelling project coordination in a multiagent framework. In Proceedings of the Fifth Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises, WET ICE’96. IEEE Computer Society Press,
Los Alamitos, 1996.
[36] F. M. T. Brazier, C. M. Jonker, and J. Treur. Compositional design and reuse of a generic
agent model. Applied Artificial Intelligence Journal, pages 491–538, 2000.
[37] F. M. T. Brazier and J. Treur. Compositional modelling of reflective agents. International
Journal of Human-Computer Studies, 1999.
[38] F.M.T. Brazier, B.M. Dunin-Keplicz, J. Treur, and L.C. Verbrugge. Modelling internal
dynamic behaviour of BDI agents. In A. Cesto and P.Y. Schobbes, editors, Proceedings of
the Third International Workshop on Formal Models of Agents, MODELAGE’97. Springer
Verlag, 1999.
[39] British Telecommunications. The ZEUS agent building toolkit. http://www.labs.
bt.com/projects/agents/zeus/.
[40] R. A. Brooks. A robust layered control system for a mobile robot. IEEE Journal of
Robotics and Automation, RA-2:14–23, 1986.
[41] R. A. Brooks. Intelligence without representation. Artificial Intelligence, 47:139–159,
1987.
[42] R. A. Brooks. How to build complete creatures rather than isolated cognitive simulators.
In K. VanLehn, editor, Architectures for Intelligence, pages 225–239. Lawrence Erlbaum
Associates, Hillsdale, NJ, 1991.
[43] R. A. Brooks. Integrated systems based on behaviors. SIGART Bulletin 2, 4(2):46–50,
1991.
[44] F. Bry. Query answering in information systems with integrity constraints. In S. Jajodia,
W. List, G. McGregor, and L. Strous, editors, Integrity and Internal Controls in Information Systems, vol. I: Increasing the confidence in information systems, Proceedings
1997 IFIP WG 11.5 Working Conference on Integriy and Control in Information Systems.
Chapman & Hall, 1997.
[45] B. Burmeister. Models and methodologies for agent-oriented analysis and design. In
K. Fischer, editor, Working Notes of the KI’96 Workshop on Agent-Oriented Programming
and Distributed Systems, 1996.
277
[46] B. Burmeister and K. Sundermeyer. Cooperative problem solving guided by intentions
and perception. In Decentralized A.I., volume 3, North-Holland, 1992.
[47] M. Calisti and B. Faltings. Agent-based negotiations for multi-provider interactions. In
Proceedings of ASA 2000, 2nd International Symposium on Agent Systems and Applications, pages 235–248, Zurich, Switzerland, 2000.
[48] M. Calisti, B. Faltings, and S. Mazziotta. Market-skilled agents for automating the bandwidth commerce. In Proceedings USM 2000, 3rd IFIP/GI International Conference on
Trends towards a Universal Service Market, pages 30–41, Munich, Germany, 2000.
[49] H-N. Castaneda, editor. Thinking and Doing. The Philosophical Foundations of Institutions. Reidel, Dordrecht, 1975.
[50] A. Celle and L. Bertossi. Querying inconsistent databases: Algorithms and implementation. In Proceedings of DOOD’2000, pages 942–956, London, UK, 2000.
[51] B. Chandrasekaran, J. R. Josephson, and V. R. Benjamins. What are ontologies, and why
do we need them. IEEE Intelligent Systems, 14(1):20–26, 1999.
[52] P. Charlton, R. Cattoni, A. Potrich, and E. Mamdani. Evaluating the FIPA standards and
its role in achieving cooperation in multiagent systems. In Proc. of the 33rd Hawaii International Conference on System Sciences (HICSS-33), Maui, HI, 2000. IEEE Computer
Society.
[53] P. Ciancarini and M. Wooldridge. Agent-oriented software engineering: The state of the
art. In P. Ciancarini and M. Wooldridge, editors, Agent-Oriented Software Engineering First International Workshop, AOSE 2000, pages 1–28, Limerick, Ireland, 2000. SpringerVerlag. LNCS 1957.
[54] D. Coleman, P. Arnold, S. Bodoff, C. Dollin, H. Gilchrist, F. Hayes, and P. Jeremaes.
Object-Oriented Development: The FUSION Method. Prentice Hall International, Hemel
Hempstead, England, 1994.
[55] A. Collinot, A. Drogoul, and P. Benhamou. Agent oriented design of a soccer robot team.
In Proceedings of the Second International Conference on Multi-Agent Systems (ICMAS96), pages 41–47, Kyoto, Japan, 1996.
[56] J. Collins and D. Ndumu. ZEUS methodology documentation, part I: The role modelling
guide. Downloadable from http://193.113.209.147/projects/agents.
htm, 1999.
[57] S. Crocè. Un approccio ad agenti per la simulazione di un modello postale. Master’s
thesis, DISI – Università di Genova, Genova, Italy, 1998. In Italian.
278
[58] A. Cuppari, P. L. Guida, M. Martelli, V. Mascardi, and F. Zini. An Agent-Based Prototype for Freight Trains Traffic Management. In P. G. Larsen, editor, Proc. of FMERail
Workshop 5, Toulouse, France, September 1999. Springer-Verlag. A satellite workshop of
FM’99.
[59] A. Cuppari, P. L. Guida, M. Martelli, V. Mascardi, and F. Zini. Prototyping Freight Trains
Traffic Management Using Multi-Agent Systems. In Proc. of IEEE International Conference on Information, Intelligence and Systems, Washington, DC, November 1999. IEEE.
[60] P. Dart, E. Kazmierckaz, M. Martelli, V. Mascardi, L. Sterling, V.S. Subrahmanian, and
F. Zini. Combining logical agents with rapid prototyping for engineering distributed applications. In Proc. 9th International Conference of Software Technology and Engineering
(STEP’99), Pittsburgh, PA, USA, 1999. IEEE Computer Society Press.
[61] R. Degl’Innocenti. UML come linguaggio per specificare agenti: Analisi, estensione ed
integrazione in CaseLP. Master’s thesis, DISI – Università di Genova, Genova, Italy,
2000. In Italian.
[62] G. Delzanno. Logic & Object-Oriented Programming in Linear Logic. PhD thesis, Università di Pisa, Dipartimento di Informatica, 1997. Technical Report TD 2/97.
[63] G. Delzanno and M. Martelli. Proofs as computations in linear logic. Theoretical Computer Science, 258(1–2):269–297, 2001.
[64] D. C. Dennett. The Intentional Stance. MIT Press, Cambridge, MA, USA, 1987.
[65] E. Denti, A. Omicini, and A. Ricci. tuProlog: A lightweight prolog for internet applications and infrastructures. In I. V. Ramakrishnan, editor, Proceedings of Practical Aspects
of Declarative Languages, PADL 2001, pages 184–198, Las Vegas, NV, 2001. SpringerVerlag.
[66] R. Depke, R. Heckel, and J. M. Kuester. Agent-oriented modeling with graph transformation. In P. Ciancarini and M. Wooldridge, editors, Agent-Oriented Software Engineering
- First International Workshop, AOSE 2000, pages 105–119, Limerick, Ireland, 2000.
Springer-Verlag. LNCS 1957.
[67] The DESIRE research programme. http://www.cs.vu.nl/vakgroepen/ai/
projects/desire/desire.html.
[68] J. Dix, VS. Subrahmanian, and G. Pick. Meta Agent Programs. Journal of Logic Programming, 46(1–2):1–60, 2000.
[69] T. Eiter and V. Mascardi. Comparing environments for developing software agents. Technical Report INFSYS RR-1843-01-02, Wien Technical University, 2001. To appear in AI
Communications.
279
[70] T. Eiter, V. Mascardi, and V. S. Subrahmanian. Error tolerant agents. In Computational
Logic: From Logic Programming into the Future. Springer-Verlag, 2001. To appear.
[71] T. Eiter and V.S. Subrahmanian. Heterogeneous active agents, II: Algorithms and complexity. Artificial Intelligence, 108(1-2):257–307, 1999.
[72] T. Eiter, V.S. Subrahmanian, and G. Pick. Heterogeneous active agents, I: Semantics.
Artificial Intelligence, 108(1-2):179–255, 1999.
[73] T. Eiter, V.S. Subrahmanian, and T. Rogers. Heterogeneous active agents, III: Polynomially implementable agents. Artificial Intelligence, 117(1):107–167, 2000.
[74] C. Elliot. The Affective Reasoner: A Process Model of Emotions in a Multi-Agent System.
PhD thesis, Northwestern University. The Institute for Learning Sciences, 1992. Technical
Report No. 32.
[75] J. Engelfriet, C. M. Jonker, and J. Treur. Compositional verification of multi-agent systems
in temporal multi-epistemic logic. In J. P. Müller, M. P. Singh, and A. S. Rao, editors,
Intelligent Agents V, pages 177–194. Springer-Verlag, 1999. LNCS 1555.
[76] K. Eshghi and R. Kowalski. Abduction compared with negation as failure. In Proc.
of International Conference of Logic Programming (ICLP), Lisbon, Portugal, 1989. The
MIT Press.
[77] E. Mangina et al. Multi agent system knowledge representation for power plant. In Proc.
of the International Conference on Intelligent System Application to Power Systems, Budapest, Hungary, 2001.
[78] J. Ferber. Eco-problem solving: How to solve a problem by interactions. In Proceedings
of the 9th workshop on DAI, pages 113–128, 1989.
[79] I. A. Ferguson. TouringMachines: An Architecture for Dynamic, Rational, Mobile Agents.
PhD thesis, Computer Laboratory, University of Cambridge, UK, 1992.
[80] M. Finger, P. McBrien, and R. Owens. Databases and executable temporal logic. In
Proceedings of the ESPRIT Conference, 1991.
[81] M. Fisher. Implementing a prototype metatem interpreter. Technical report, Department
of Computer Science, University of Manchester, 1990. SPEC Project Report.
[82] M. Fisher. A normal form for first-order temporal formulae. In Proc. of Eleventh International Conference on Automated Deduction (CADE), Saratoga Springs, New York, 1992.
280
[83] M. Fisher. Concurrent METATEM – A language for modeling reactive systems. In Parallel Architectures and Language, Europe (PARLE), pages 185–196, Munich, Germany,
1993. Springer-Verlag.
[84] M. Fisher and H. Barringer. Concurrent METATEM processes – A language for distributed
AI. In Proceedings of the European Simulation Multiconference, Copenhagen, Denmark,
1991. SCS Press.
[85] M. Fisher and R. Owens. An introduction to executable modal and temporal logics. In
Executable Modal and Temporal Logics. Springer-Verlag, 1995. LNAI 897.
[86] M. Fisher and M. Wooldridge. Temporal logic programming for distributed AI. In Twelfth
International Workshop of Distributed AI, Hidden Valley Resort, Pennsylvania, 1993.
[87] L. N. Foner. Entertaining agents: A sociological case study. In W. Lewis Johnson and
Barbara Hayes-Roth, editors, Proceedings of the First International Conference on Autonomous Agents (Agents’97), pages 122–129, Marina del Rey, CA, USA, 1997. ACM
Press.
[88] Foundation for Intelligent Physical Agents. FIPA ACL message structure specification.
Approved for experimental, 14-06-2000, 2000.
[89] Foundation for Intelligent Physical Agents. FIPA agent software integration specification.
Approved for experimental, 14-06-2000, 2000.
[90] M. S. Fox, J. F. Chionglo, and M. Barbuceanu. The integrated supply chain management
system. Technical report, 1993.
[91] S. Franklin and A. Graesser. Is it an agent, or just a program?
In J. P. Müller,
M. Wooldridge, and N. R. Jennings, editors, Intelligent Agents III, pages 21–35, Berlin,
Germany, 1997. Springer-Verlag. LNAI 1193.
[92] M. Genesereth and S. Ketchpel. Software agents. Communications of the ACM, 37(7):48–
53, 1994.
[93] M. P. Georgeff and F. F. Ingrand. Decision-making in embedded reasoning systems. In
Proceedings of the 6th International Joint Conference on Artificial Intelligence, pages
972–978, 1989.
[94] G. De Giacomo, Y. Lespérance, and H. J. Levesque. Congolog, a concurrent programming
language based on the situation calculus. Artificial Intelligence, 121:109–169, 2000.
[95] N. Gilbert and K. G. Troitzsch. Simulation for the Social Scientist. Open University Press,
1999.
281
[96] L. Giordano, A. Martelli, and C. Schwind. Dealing with concurrent actions in modal
action logic. In H. Prade, editor, Proc. of ECAI’98, pages 537–541, Brighton, UK, 1998.
John Wiley and Son.
[97] L. Giordano, A. Martelli, and C. Schwind. Ramification and causality in a modal action
logic. Journal of Logic and Computation, 10(5):626–662, 2000.
[98] J. Y. Girard. Linear logic. Theoretical Computer Science, 50(1):1–102, 1987.
[99] Grasshopper agent development platform.
IKV++. http://www.ikv.de/
products/grasshopper/grasshopper.html.
[100] S. C. Hayden, C. Carrick, and Q. Yang. A catalog of agent coordination patterns. In
AGENTS ’99. Proceedings of the Third Annual Conference on Autonomous Agents, pages
412–413, Seattle, WA, 1999.
[101] C.A.R. Hoare. An axiomatic basis for computer programming. Communications of the
ACM, 12(10):576–583, 1969.
[102] W. N. Hohfeld. Fundamental legal conceptions as applied to judicial reasoning. Yale Law
Journal, 23:16–59, 1913.
[103] J. Huang, N. R. Jennings, and J. Fox. An agent-based approach to health care management.
Applied Artificial Intelligence: An International Journal, 9(4):401–420, 1995.
[104] C. A. Iglesias, M. Garijo, J. C. González, and J. R. Velasco. Analysis and design of multiagent systems using MAS-CommonKADS. In M. P. Singh, A. Rao, and M. Wooldridge,
editors, Intelligent Agents IV, Providence, Rhode Island, USA, 1997. Springer-Verlag.
LNAI 1365.
[105] D. Ballard Principal Investigator. Intelligent agents and agent communication languages
for mission operations phase II – Final Report. NASA Goodard Space Flight Center,
Greenbelt, MD. NASA Reference NAS-97018, Reticular Reference 35-9, 1998.
[106] Mitsubishi Electric ITA. Concordia: An infrastructure for collaborating mobile agents. In
First International Workshop on Mobile Agents, Berlin, Germany, 1997.
[107] N. R. Jennings. Towards a cooperation knowledge level for collaborative problem solving.
In Proceedings of the 10th european conference on Artificial Intelligence, pages 224–228,
Vienna, AU, 1992.
[108] N. R. Jennings. Commitments and conventions: The foundation of coordination in multiagent systems. The Knowledge Engineering Review, 8(3):223–250, 1993.
282
[109] N. R. Jennings, E. H. Mamdani, J. Corera, I. Laresgoiti, F. Perriolat, P. Skarek, and L. Z.
Varga. Using archon to develop real-word dai applications. IEEE Expert, 11(6):64–70,
1996.
[110] N. R. Jennings, K. Sycara, and M. Wooldridge. A roadmap of agent research and development. Autonomous Agents and Multi-Agent Systems, 1:7–38, 1998.
[111] N. R. Jennings and M. Wooldridge. Agent-oriented software engineering. In J. Bradshaw,
editor, Handbook of Agent Technology. AAAI/MIT Press, 2001.
[112] C. M. Jonker, J. Treur, and W. de Vries. Compositional verification of agents in dynamic
environments: A case study. In F. van Harmelen, editor, Proc. of the KR98 Workshop on
Verification and Validation of KBS. Morgan Kaufmann, 1998.
[113] C. M. Jonker, J. Treur, and W. de Vries. Reuse and Abstraction in Verification: Agents
Acting in a Dynamic Environment. In P. Ciancarini and M. Wooldridge, editors, AgentOriented Software Engineering - First International Workshop, AOSE 2000, pages 253–
268, Limerick, Ireland, 2000. Springer-Verlag. LNCS 1957.
[114] jprolog. http://www.cs.kuleuven.ac.be/bmd/PrologInJava/.
[115] A. Kashyap. Design and development of a framework for testing and developing internet
auction systems. Master’s thesis, 2000.
[116] E. Kendall. Agent software engineering with role modelling. In P. Ciancarini and
M. Wooldridge, editors, Agent-Oriented Software Engineering - First International Workshop, AOSE 2000, pages 163–169, Limerick, Ireland, 2000. Springer-Verlag. LNCS 1957.
[117] E. A. Kendall. Agent roles and role models: New abstractions for intelligent agent system
analysis and design. In International Workshop on Intelligent Agents in Information and
Process Management, Germany, 1998.
[118] D. Kinny, M. Georgeff, and A. Rao. A methodology and modelling technique for system
of BDI agents. In W. Van de Velde and J. W. Perram, editors, Agents Breaking Away,
pages 56–71. Springer-Verlag, 1996. LNAI 1038.
[119] R. Kowalski and F. Sadri. Towards a unified agent architecture that combines rationality
with reactivity. In Proc. of International Workshop on Logic in Databases, pages 137–149,
San Miniato, Italy, 1996. Springer-Verlag.
[120] R. Kowalski and F. Sadri. An agent architecture that unifies rationality with reactivity.
Technical report, Imperial College, 1997.
[121] S. Kraus. Negotiation and cooperation in multi-agent environments. Artificial Intelligence,
94(1–2):79–97, 1997.
283
[122] S. Kripke. Semantical analysis of modal logic I. Zeitschrift fur math. Logik und Grundlagen der Mathematik, 9:67–96, 1963.
[123] S. Kripke. Semantical considerations on modal logic. Acta Philosophica Fennica, 16:83–
94, 1963.
[124] S. Kripke. Semantical analysis of modal logic II. In The theory of models, Amsterdam,
North-Holland, 1965.
[125] M. Kumar and S. I. Feldman. Internet auctions. Technical report, IBM Research Division,
T.J. Watson Research Center Yorktown Heights, NY 10598.
[126] J. E. Laird, A. Newell, and P. R. Rosenbloom. SOAR: An architecture for general intelligence. Artificial Intelligence, 33(1):1–62, 1987.
[127] D. Lange and M. Oshima. Programming and Deploying Java Mobile Agents with Aglets.
Addison Wesley Longman, 1998.
[128] G. Lavender and D. Schmidt. Active object: An object behavioural pattern for concurrent programming. In J. M. Vlissides, J. O. Coplien, , and N. L. Kerth, editors, Pattern
Languages of Program Design, Reading, MA, 1996. Addison-Wesley.
[129] H. Levesque, F. Pirri, and R. Reiter. Foundations for the situation calculus. Linköping
Electronic Articles in Computer and Information Science, 3(18), 1998.
[130] H. J. Levesque, R. Reiter, Y. Lespérance, F. Lin, and R. B. Scherl. Golog: A logic programming language for dynamic domains. Journal of Logic Programming, 31:59–84,
1997.
[131] H. Lieberman. Autonomous interface agents. In Proceedings of the ACM Conference on
Computers and Human Interface, CHI-97, Atlanta, Georgia, 1997.
[132] J. Lind. MASSIVE: Software Engineering for Multiagent Systems. PhD thesis, University
of the Saarland, 2000.
[133] B. Logan. Classifying agent systems. In Proc. of the AAAI-98 Workshop on Software
Tools for Developing Agents, Wisconsin, USA, 1998.
[134] J. Lu, A. Nerode, and V. S. Subrahmanian. Hybrid knowledge bases. IEEE Transactions
on Knowledge and Data Engineering, 8(5):773–785, October 1996.
[135] M. Luck, N. Griffiths, and M. d’Inverno. From agent theory to agent construction: A case
study. In J. P. Müller, M. Wooldridge, and N. R. Jennings, editors, Intelligent Agents III,
pages 49–64. Springer-Verlag, 1997.
284
[136] U. Lipeck M. Gertz. An extensible framework for repairing constraint violations. In S. Jajodia, W. List, G. McGregor, and L. Strous, editors, Integrity and Internal Controls in Information Systems, vol. I: Increasing the confidence in information systems, Proceedings
1997 IFIP WG 11.5 Working Conference on Integriy and Control in Information Systems,
pages 89–111. Chapman & Hall, 1997.
[137] P. Maes. Agents that reduce work and information overload. Communications of the ACM,
37(7), 1994.
[138] S. Marini, M. Martelli, V. Mascardi, and F. Zini. HEMASL: A Flexible Language to Specify Heterogeneous Agents. In A. Corradi, A. Omicini, and A. Poggi, editors, Proceedings
of WOA 2000. Dagli Oggetti Agli Agenti. Parma, Italy. Pitagora editrice, Bologna, 2000.
[139] S. Marini, M. Martelli, V. Mascardi, and F. Zini. Specification of heterogeneous agent
architectures. In C. Castelfranchi and Y. Lespérance, editors, Intelligent Agents VII, LNAI,
Boston, MA, USA, 2000. Springer-Verlag.
[140] M. Martelli, V. Mascardi, and F. Zini. Applying logic programming to the specification
of complex applications. In M. Falaschi, M. Navarro, and A. Policriti, editors, Proc. of
Appia–Gulp–Prode 1997: Joint Conference on Declarative Programming, pages 491–
499, Grado, Italy, 1997. Extended version.
[141] M. Martelli, V. Mascardi, and F. Zini. CaseLP: A complex application specification environment based on logic programming. In Proc. of ICLP’97 Post Conference Workshop on
Logic Programming and Multi-Agents, pages 35–50, Leuven, Belgium, 1997.
[142] M. Martelli, V. Mascardi, and F. Zini. Towards multi-agent software prototyping. In
H. S. Nwana and D. T. Ndumu, editors, Proc. of The 3rd International Conference and
Exhibition on The Practical Application of Intelligent Agents and Multi-Agent Technology
(PAAM’98), pages 331–354, London, UK, 1998.
[143] M. Martelli, V. Mascardi, and F. Zini. A logic programming framework for componentbased software prototyping. In A. Brogi and P. Hill, editors, Proc. of 2nd International Workshop on Component-based Software Development in Computational Logic
(COCL’99), Paris, France, 1999.
[144] M. Martelli, V. Mascardi, and F. Zini. Specification and simulation of multi-agent systems
in CaseLP. In M. C. Meo and M. Vilares-Ferro, editors, Proc. of Appia–Gulp–Prode 1999:
Joint Conference on Declarative Programming, pages 13–28, L’Aquila, Italy, 1999.
[145] V. Mascardi and E. Merelli. Agent-oriented and constraint technologies for distributed
transaction management. In Proc. of IIA and SOCO, Genova, Italy, 1999. ICSC Academic
Press.
285
[146] J. Mayfield, Y. Labrou, and T. Finin. Evaluation of KQML as an agent communication
language. In Intelligent Agents II. Springer Verlag, 1995. LNAI 1037.
[147] J. McCarthy. Situations, actions and causal laws. Technical report, Stanford University,
1963. Reprinted in Semantic Information Processing, M. Minsky ed., MIT Press, Cambridge, MA, 1968, pp 110-117.
[148] J-J. Ch. Meyer and R. J. Wieringa, editors. Deontic logic in Computer Science. John
Wiley and sons, 1993.
[149] S. Miksch, K. Cheng, and B. Hayes-Roth. An intelligent assistant for patient health care.
In Proceedings of the First International Conference on Autonomous Agent, Marina del
Rey, CA, USA, 1997.
[150] D. Miller. Forum: A multiple-conclusion specification logic. Theoretical Computer Science, 165(1), 1996.
[151] MINERVA. http://www.ifcomputer.co.jp/MINERVA/home_en.html.
[152] H. Moravec. Rise of the robots. Scientific American, pages 124–135, 1999.
[153] C. Morgan, editor. Programming from Specifications (Second Edition). Prentice Hall
International, Hemel Hempstead, England, 1994.
[154] J. P. Müller. The Design of Autonomous Agents – A Layered Approach. Springer-Verlag,
1996. LNAI 1177.
[155] J. P. Müller. The right agent (architecture) to do the right thing. In J. P. Müller, M. P. Singh,
and A. S. Rao, editors, Intelligent Agents V, pages 211–225. Springer-Verlag, 1999. LNCS
1555.
[156] H. Munoz-Avila, J. Dix, D. S. Nau, and Y. Cao. IMPACTing SHOP: Planning in a multiagent environment. In K. Satoh and F. Sadri, editors, CL-2000 Workshop on Computational Logic in Multi-Agent Systems 2000 (CLIMA-00), pages 44–55, London, UK.
[157] D. S. Nau, Y. Cao, A. Lotem, and H. Munoz-Avila. SHOP: Simple hierarchical ordered
planner. In T. Dean, editor, Proceedings of the Sixteenth International Joint Conference
on Artificial Intelligence, IJCAI 99, Stockholm, Sweden, 1999. Morgan Kaufmann.
[158] N.J. Nilsson. Principles of Artificial Intelligence. Morgan Kaufmann, 1980.
[159] Object Modeling Group. Unified Modelling Language Specification, version 1.3, 2000.
OMG document formal/00-03-01.
286
[160] J. Odell, H. Parunak, and B. Bauer. Response to the OMG ANALYSIS & DESIGN TASK
FORCE UML 2.0 REQUEST FOR INFORMATION —- Extending UML for the specification of agent interaction protocols. 1999.
[161] J. Odell, H. V. D. Parunak, and B. Bauer. Extending UML for agents. In AOIS Workshop
at AAAI 2000, 2000.
[162] J. Odell, H. V. D. Parunak, and B. Bauer. Representing agent interaction protocols in
UML. In P. Ciancarini and M. Wooldridge, editors, Agent-Oriented Software Engineering
[163] A. Omicini. SODA: Societies and infrastructures in the analysis and design of agent-based
systems. In P. Ciancarini and M. Wooldridge, editors, Agent-Oriented Software Engineering - First International Workshop, AOSE 2000, pages 185–193, Limerick, Ireland, 2000.
[164] V. Patti. Programming Rational Agents: a Modal Approach in a Logic Programming
Setting. PhD thesis, Dipartimento di Informatica, Università degli Studi di Torino, Italy,
2002.
[165] M. De Pedrini. CaseLP Visualizer: un tool di visualizzazione per sistemi multi-agente
logici. Master’s thesis, DISI – Università di Genova, Genova, Italy, 1998. In Italian.
[166] G. Persano. Gestione distribuita di informazioni mediche mediante tecniche multi-agente.
Master’s thesis, DISI – Università di Genova, Genova, Italy, 1998. In Italian.
[167] C. J. Petrie. Agent-based software engineering. In J. Bradshaw and G. Arnold, editors,
Proceedings of the 5th International Conference on the Practical Application of Intelligent
Agents and Multi-Agent Technology (PAAM 2000), Manchester, UK, 2000. The Practical
Application Company Ltd.
[168] F. Pirri and R. Reiter. Some contributions to the metatheory of the Situation Calculus.
Journal of the ACM, 46:325–361, 1999.
[169] L. Åqvist. Deontic logic. In D. M. Gabbay and F. Guenther, editors, Handbook of Philosophical Logic, Vol II, pages 605–714, Dordrecht / Boston, 1984. Reidel.
[170] A. Rao and R. Georgeff. Modeling rational agents within a pBDI–architecture. In R. Fikes
and E. Sandewall, editors, Proc. of Knowledge Representation and Reasoning (KR&R-91),
pages 473–484, San Mateo, CA, 1991. Morgan Kaufmann.
[171] A. S. Rao and M. Georgeff. BDI agents: from theory to practice. In Proc. of International
Conference on Multi Agent Systems (ICMAS’95), San Francisco, CA, USA, 1995.
287
[172] K. S. Raza. Implementation of plug-and-play printer with mobile agents. Technical report.
[173] W. S. Reilly and J. Bates. Building emotional agents. Technical Report CMU-CS-92-143,
School of Computer science, Canergie Mellon University, Pittsburgh, PA, 1992.
[174] D. Riehle. A role-based design pattern catalog of atomic and composite patterns structured
by pattern purpose. Technical report, Ubilab Technical Report 97.1.1, Union Bank of
Switzerland, Zurich, Switzerland, 1997.
[175] S. J. Rosenschein and L. P. Kaelbling. A situated view of representation and control.
In P. E. Agre and S. J. Rosenschein, editors, Computational Theories of Interaction and
Agency, pages 515–540, Cambridge, MA, 1996. The MIT Press.
[176] S. H. Schoepke. A business view regarding the selection of agent development toolkits.
In Proc. of the AAAI-98 Workshop on Software Tools for Developing Agents, Wisconsin,
USA, 1998.
[177] C. Schramm, A. Bieszczad, and B. Pagurek. Application-oriented network modeling with
mobile agents. In Proc. of the IEEE/IFIP Network Operations and Management Symposium (NOMS ’98), New Orleans, Louisiana, 1998.
[178] J. Schumann and J. Whittle. Automatic synthesis of agent designs in UML. In J. L. Rash,
C. Rouff, W. Truszkowski, D. F. Gordon, and M. G. Hinch, editors, Formal Approaches
to Agent-Based Systems (FAABS 2000), pages 148–162, Greenbelt, MD, 2000. SpringerVerlag.
[179] W. Shen and D. H. Norrie. Agent-based systems for intelligent manufacturing: A state-ofthe-art survey. Knowledge and Information Systems, an International Journal, 1(2):129–
156, 1999.
[180] W. Shen, D. H. Norrie, and J. Barthes. Multi-agent systems for concurrent intelligent
design and manufacturing. Taylor & Francis Group, 2001.
[181] Y. Shoham. Agent-oriented programming. Artificial Intelligence, 60:51–92, 1993.
[182] SICStus Prolog. SICS AB. http://www.sics.se/sicstus.html.
[183] M. P. Singh. Write asynchronous, run synchronous. IEEE Internet Computing, 3(2):4–5,
1999.
[184] N. Skarmeas and K. L. Clark. Process oriented programming for agent based network
management. In Proceedings of ECAI Workshop on Intelligent Agents for Telecomminications Applications (IATA96). IOS Press, 1996.
[185] A. Sloman. Motives, mechanisms, and emotions. Cognition and Emotion, 1(3):217–233,
1987.
288
[186] A. Sloman. What’s an ai toolkit for? In Proc. of the AAAI-98 Workshop on Software Tools
for Developing Agents, Wisconsin, USA, 1998.
[187] A. Sloman and R. Poli. SIM AGENT: A toolkit for exploring agent designs. In Intelligent
Agents II. Springer-Verlag, 1996.
[188] M. Spivey. The Z Notation: A Reference Manual, 2nd edition. Prentice Hall International
Series in Computer Science, 1992.
[189] D. D. Steiner, A. Burt, M. Kolb, and Ch. Lerin. The conceptual framework of MAIö L. In
Pre-Proceedings of MAAMAW’93, Switzerland, 1993.
[190] L. Sterling, P. Ciancarini, and T. Turnidge. On the animation of “not executable” specifications by prolog. International Journal of Software Engineering and Knowledge Engineering, 6(1):63–87, 1996.
[191] V.S. Subrahmanian. Paraconsistent disjunctive deductive databases. Theoretical Computer
Science, 93(1):115–141, 1992.
[192] V.S. Subrahmanian, J. Dix, and T. Eiter et al. Heterogeneous Agent Systems: Theory and
Implementation. MIT Press, 2000.
[193] SWI-Prolog. http://www.swi.psy.uva.nl/projects/SWI-Prolog/.
[194] P. Tarau. Jinni (Java INference engine and Networked Interactor). http://www.
binnetcorp.com/Jinni/.
[195] S. R. Thomas. The PLACA agent programming language. In Intelligent Agents. Agent
Theories, Architectures, and Languages - 1th International Workshop. Springer-Verlag,
1995.
[196] S. Vinosky. CORBA: Integrating diverse applications within distributed heterogeneous
environments. IEEE Communications Magazine, 14(2), 1997.
[197] G. H. von Wright. Deontic logic. Mind, 60:1–15, 1951. Reprinted in G. H. von Wright,
Logical Studies, pp. 58–74. Routledge andn Kegan Paul, London, 1957.
[198] G. Weiss, editor. Multiagent Systems – A Modern Approach to Distributed Artificial Intelligence. MIT Press, Cambridge, MA, USA, 1999.
[199] T. White, B. Pagurek, and F. Oppacher. Connection management using adaptive agents. In
Proc. of the 1998 International Conf. on Parallel and Distributed Processing Techniques
and Applications (PDPTA ’98), Las Vegas, 1998.
[200] R. J. Wieringa. Design methods for reactive systems. 2000.
289
[201] M. Wood and S. A. DeLoach. An overview of the multiagent system engineering methodology. In P. Ciancarini and M. Wooldridge, editors, Agent-Oriented Software Engineering
[202] M. Wooldridge. The Logical Model of Computational Multi–Agent Systems. PhD thesis,
Department of Computation, UMIST, Manchester, UK, 1992.
[203] M. Wooldridge. Reasoning about Rational Agents. The MIT Press, Cambridge, MA,
2000.
[204] M. Wooldridge and N. R. Jennings. Intelligent agents: Theory and practice. The Knowledge Engineering Review, 10(2):115–152, 1995.
[205] W. Wooldridge, N. R. Jennings, and D. Kinny. A methodology for agent-oriented analysis
and design. In Proceedings of the Third International Conference on Autonomous Agents
(Agents99), pages 69–76, Seattle, WA, 1999.
[206] I. Wright. Emotional Agents. PhD thesis, University of Birmingham, 1997.
[207] F. Zini. CaseLP, a Rapid Prototyping Environment for Agent-Based Software. PhD thesis,
Computer Science Department of Genova University, Genova, Italy, 2000. DISI-TH2001-03.
[208] F. Zini and L. Sterling. Designing ontologies for agents. In M. C. Meo and M. VilaresFerro, editors, Proc. of Appia–Gulp–Prode 1999: Joint Conference on Declarative Programming, pages 29–42, L’Aquila, Italy, 1999.
290
Appendix A
MASDK Comparison: Details
This appendix contains a detailed analysis and comparison of the MASDKs introduced in Section 4.3.
A.1
Agent basic attitudes
In spite of the different agent definitions and conceptualizations, all the MASDKs we have analyzed support the definition and implementation of agents which comply to the basic model.
Almost all agents possess a mailbox, and this ensures that they can be social and situated (the
surrounding environment may be sensed through message exchange). The existence of an engine stating the macro-actions an agent performs during its life-cycle ensures the autonomy of
the agent. The reactiveness and pro-activeness of agents is also supported by all the frameworks.
A.2
Agent advanced attitudes
ò Mental attitudes. AgentBuilder agents are conceptualized in terms of behavioral rules,
beliefs, commitments, intentions and capabilities.
The other MASDKs do not conceptualize agents in terms of mental attitudes, but they
allow the definition of agents characterized by mental features:
– [30] describes the specification of the BDI architecture in CaseLP.
– in [38] a generic model for the internal dynamic behavior of BDI agents modeled in
DESIRE is proposed.
291
– [68] extends IMPACT agent programs by beliefs. This is not a real BDI architecture,
but desires and intentions can be implemented through the agent action language and
the IMPACT software code call mechanism.
– [39] and [77] show extensions of the Zeus environment for supporting mental attitudes.
ò Deliberative capabilities. AgentBuilder allows the developer to link a separate planning
module into the basic agent inferencing cycle. The planning modules are not provided
as part of the AgentBuilder toolkit: they must be implemented by the agent’s developer
according to the application features. Examples involving street route path planning have
been developed.
CaseLP and DESIRE do not provide planning facilities. Planning problems have been
addressed for some specific cases but no general planners are provided.
IMPACT is currently being extended with an AI planning system: [156] describes how to
couple an HTN (Hierarchical Task Network) planner into the IMPACT framework. The
idea is to create several specific agents in IMPACT that simulate together an efficient HTN
planner called SHOP ([157] developed independently from D. Nau in the planning community). Once these agents are fully implemented they can be seen as adopting one particular reusable planning strategy.
Zeus agents posses an internal Planner; the Planner reasons about how to obtain goals
using the agent’s database of tasks/capabilities and the publicly known capabilities for
other agents. It is possible to configure the planner length, namely the number of timegrains that the agent will normally plan its activities. Depending on this length, the agents
will be more reactive or more deliberative.
ò Meta-management. From a syntactic point of view, it is possible to define agents whose
beliefs may involve other agent’s beliefs in all the MASDKs we are analyzing.
DESIRE provides a generic model for reflective agents with meta-management capabilities [37].
IMPACT faces this issue with a great rigor and provides a precise semantics to nested
beliefs [68].
ò Emotionality. Emotions are not considered by any MASDK.
ò Adaptivity. Pre-defined learning strategies are provided by no toolkit.
A.3
Social ability
ò Agent Communication Language. AgentBuilder agents communicate in KQML [146].
292
CaseLP agents may communicate using KQML, or whatever language over which they
agree. All the applications developed by now used a simplified version of KQML.
Communication between agents is modeled in DESIRE by the activation of information
links. The ACL shared by the agents is a first-order language described in [36].
IMPACT has a simple, XML-based ACL built-in which serves for exchange of service
offers and requests. However, through custom software packages and proper action any
common ACL can be made available, independent of a particular application.
Zeus agents share a common communication language which is FIPA-compliant [88],
modulo some small differences.1
ò Information exchange means. All the MASDKs under consideration communicate via
message-passing. As far as lower level communication means are concerned, the basic
object to object communications mechanism supported by AgentBuilder is RMI (Remote
Method Invocation). However, it is also possible to directly use TCP/IP sockets. The
coming version of AgentBuilder will provide support for CORBA/IIOP.
CaseLP agents are logically distributed but they are physically centralized, and they run
as a unique process. At the lower level the exchange of information occurs via internal
data structures.
Agents executing within one process of a multi-agent DESIRE system communicate through
internal data structures. Agents executing in different processes of a distributed multi-agent
DESIRE system communicate through TCP/IP.
IMPACT agents exchange messages via Java’s RMI.
Zeus installation requires that each host machine should be capable of TCP/IP communication, but there is no need for any middleware services to be installed.
ò Coordination protocols. AgentBuilder includes a Protocol Manager which provides
tools to specify the messages and conversational protocols between agents. However, no
libraries of protocols are provided.
CaseLP and IMPACT do not provide already implemented coordination protocols or facilities for implementing them.
DESIRE provides generic agent models for coordination and cooperative projects based
on joint intentions and strategic user interaction [35]. In [33] the compositional development method DESIRE has been used to analyze, design, implement and verify a multiagent system capable of negotiation for load management.
The same applies for Zeus, which provides a library of coordination and negotiation protocols.
1
These differences concern the request-forward performative, not implemented in Zeus, the format of addresses,
the absence of resolvers and the low-level communication protocol.
293
ò Human-agent interaction. No MASDK gives support in this direction.
A.4
ò Methodology. AgentBuilder method for constructing intelligent agents is composed by
different steps ranging from the initial organization and control of the development project
to the debugging of executing agents. All the steps are supported by tools and facilities
provided by the toolkit.
The CaseLP environment pays high attention to the MAS specification stage: the steps for
developing a working prototype, starting from a natural language description, are clearly
defined. For each step, tools and languages are provided to support the MAS developer in
her task.
The DESIRE modeling framework provides a design method for compositional multiagent systems involving the analysis of the tasks performed by and between agents. Since
the agent is a compositional entity, the same approach can be followed for specifying the
MAS both at the macro-level (architecture of the overall MAS, interactions among agents)
and at the micro-level (architecture of the single agent, control flow among its internal
components).
The IMPACT framework provides a step-by-step procedure for building an agent by “agentifying” legacy software. This procedure is supported by the IADE (IMPACT Agent Development Environment).
The Zeus methodology consists of four stages: domain analysis, agent design, agent realization and runtime support. No software support is given for domain analysis and agent
design, even if interesting suggestions are provided to face these tasks. The last two steps
are supported by the Zeus Agent Generator and the Zeus Visualizer.
ò Ontological analysis. In both AgentBuilder and Zeus an Ontology Manager (Ontology
Editor, respectively) exists which provides tools for visualizing domain concepts and relationships by means of a graphical representation of them, and their codification for storage
and subsequent retrieval.
The possibility to define ontologies and to exploit the ontological knowledge for a better
structuring of knowledge, enhancing knowledge sharing and reuse, has been studied also
in the CaseLP environment [208]. It is not yet implemented.
As far as DESIRE is concerned, an Ontology Server Agent has been developed in a specific application, but this was not yet added to the generic environment.
The IMPACT Server provides a variety of services that are required by a society of agents
as a whole, rather than by a single agent. Among them are a Type Server, a Thesaurus
294
Server, and an Ontology/Translation Server which allow to organize and relate concepts in
order to reformulate queries with different syntax but with identical semantics.
ò Specification. By specification language we mean a language which allows to describe
agents at a certain level of abstraction, or from a particular point of view. Specifications
written in this language do not need to provide all the details for making the agent work,
since they may abstract from some lower-level details, concentrating on higher-level features. The language used to fully describe the behavior of the agents is called, in this paper,
agent implementation language. Clearly, an executable specification language can be seen
as the agent implementation language. This is what happens with AgentBuilder, DESIRE
and IMPACT: they have a unique declarative specification-implementation language, thus
the two stages of high-level specification and detailed implementation are collapsed into a
unique step.
The CaseLP approach is different: the developer can choose the most suitable specification language from a set of supported ones, to describe both the macroscopic interconnections among agents and their microscopic internal functioning (see [143] for a description
of the languages and [8] for a practical example of use of some of them). Hints for a
semi-automatic translation from some of these languages into the prototype implementation language are also provided. The supported specification languages are not standard,
but the integration of UML into CaseLP is currently under study, and some preliminary
results in this direction have been obtained [61].
Finally, Zeus suggests to adopt UML for the role modeling stage and provides a lot of
examples of role model diagrams for agent roles which can be reused in different applications. No support is provided for the semi-automatic translation of UML specifications
into working Zeus agents.
ò Verification. Support for formal verification of properties is given by DESIRE and, partially, by CaseLP.
DESIRE provides tools to verify and validate static properties of components such as
consistency, correctness and completeness. Some first explorations have been done to
extend verification to dynamic properties [75, 112, 113].
CaseLP agents may be specified in different languages, among which õ hhf ; this is a linear
logic language amenable for formal verification, and a preliminary study on how to use
this language for verifying properties of the system has been described in [29]. Up today
verification has been performed on toy examples, thus it is not clear if the approach can be
extended to more complex scenarios.
In Zeus there are some deadlock prevention algorithms in the communication and scheduling mechanisms, but support for verification of different properties is not provided.
ò Prototyping. AgentBuilder’s Agency Viewer is used to run a set of agents belonging to
the same agency. It allows to follow the communication flow among agents, change the
295
settings for the overall MAS and for the single agents, examine the current status of an
agent.
The CaseLP Visualizer, running under the ECLiPSE version of the toolkit, allows to
follow the execution of the simulation both on-line and off-line. The execution stops when
events to be monitored (which can be message exchange and/or state update) take place;
all the details of the agent state evolution and of message exchange are described to the
user.
DESIRE has an automated prototype generator and provides an execution environment
useful for process visualization.
The IMPACT IADE allows the developer to view how the semantics of an agent program
evolves with respect to the current state of the agent. A test dialog screen allows to test
agent programs prior to execution, while the test execution screen allows to follow the
execution of the program. It is also possible to monitor the agent’s message box and to
follow how concurrent actions are executed.
The Zeus toolkit provides facilities very similar to the AgentBuilder ones; the Visualizer
provides tools useful for inspecting the social relations among agents, the status of the
tasks a set of agents is performing, the internal status of each agents. It is also possible to
dynamically change the current goals, resources and other features of an agent by means
of a Control Tool.
ò Summarizing information collection. The AgentBuilder Agency Viewer allows to save
a Message Log File for later examination. No tools are provided for extracting information
from this Log File which can be examined only manually.
Also CaseLP allows to save messages for later inspection, but it provides both a graphical
and a textual tool for extracting statistical information from them. For example, it is possible to associate a weight to the messages exchanged by the agents and to determine which
is the minimum, maximum and average weight of messages per time slot, their standard
deviation, and so on. This has proven useful for properly dimensioning communication
channels in case of a limited bandwidth [8].
DESIRE does not provide simulation facilities.
The IMPACT Agent Log behaves like a bulletin board where agents can post messages
resp. information. This log is used for record keeping, usage statistics (which are used in
performance analysis/optimization) and process visualization.
The Zeus Statistic Tool allows a user to collate various statistics about a society of agents
on a per agent basis as well as on a community basis. The statistics collected include: the
number of messages and their types sent by the agents over a time period; the number of
messages sent out by the agents in coordinating different goals; the average loading of the
agents; and the coordination versus execution time ratio.
296
ò Scalability. From the documentation on AgentBuilder, we know that AgentBuilder Lite
is well-suited for constructing single-agent stand-alone applications and small agencies.
Developers building large, multi-agent systems should consider AgentBuilder Pro and its
advanced set of tools for agency debug and test. However, we did not get the information
of how many agents running concurrently may AgentBuilder Pro support before having
troubles.
Experiments made with CaseLP [57] have shown that the system can execute simulations with up to 200 agents executing for 60000 time units and exchanging almost 200000
messages. No complex reasoning capabilities were required to the agents involved in this
application and the time required to complete the simulation was extremely high (a couple
of hours).
The IMPACT team did not conduct test on scalability. The biggest MAS they built so far
contains about 25-30 agents. That has worked fine without any problems. When lots of
messages are exchanged, the system works fine. The key things that slow IMPACT down
are:
1. computation time: as IMPACT agents use APIs of existing legacy code, this may be
very fast or very slow, depending on the legacy code.
2. network communication time.
No troubles arose with IMPACT agents process 20-50 concurrent requests.
As far as Zeus is concerned, according to a message contained in the Zeus archive it
seems that the MASDK works fine with lightweight examples, but with more complex
applications, characterized by numbers such as 100 agents running on the same host with
10000 messages sent with a time-grain of 0.01 seconds, problems arise. In particular, since
messages are stored in memory, when many messages are exchanged the application may
run out of heap space. Besides, agents may receive only a small part of the exchanged
messages.
ò Maintainability. All updates to the current version (i.e. 1.1 from 1.0) of both AgentBuilder Lite and AgentBuilder Pro are free of charge. Upgrades to 2.0 from 1.1 of AgentBuilder Lite are available at a discounted price for licensed users of previous versions;
upgrades to 2.0 from 1.1 of AgentBuilder Pro are included in the purchase price. As far
as AgentBuilder Pro is concerned, annual maintenance after the first year is available for
purchase. Pricing for maintenance is 25% of the purchase price of Pro.
The maintenance of the CaseLP system exists, but it is almost slow. As described in
Section 7, a new version of the system is under development but it will take some time
before it will be ready to be released. On the other hand, research on topics related with
CaseLP, in particular on agent specification and implementation languages which could
be included in the system, is very lively. All this thesis work goes in this direction.
297
DESIRE maintainance seems to be slow too: at the time of writing (April 2002) the DESIRE home page (http://www.cs.vu.nl/vakgroepen/ai/projects/desire/)
last update results to be January 3, 2000. Nevertheless, a new course on Componentbased Design of Intelligent Multi-Agent Systems, involving the DESIRE methodology
and toolkit, is scheduled for May 29 - June 4, 2002. This means that the project is still
up-to-date.
The University of Maryland, which developed the IMPACT framework, has recently signed
a contract with a new company to commercialize IMPACT. They will almost certainly provide commercial support and maintainance.
According to what we read in the Zeus mailing list archive, we have the feeling that the
toolkit receives continuous support, debugging and maintainance by the Zeus staff. The
new releases are all free.
A.5
Implementation of agents and MAS
ò Agents implementation language. The AgentBuilder agent programming language is
called RADL (Reticular Agent Definition Language). It is an object-oriented language
extending Y. Shoham’s [181] and S. R. Thomas’ [195] works. The RADL file is automatically produced by the AgentBuilder Toolkit when it is fed with the necessary information
for building an agent. To execute an agent it is necessary to specify which external Java
classes it uses. The Agent Program, composed by the RADL file and some external Java
classes, is executed by the Reticular’s run-time agent engine; the combination of the Agent
Program and the agent engine produces an executable agent.
The CaseLP agent programming language is called ProlAg: it is a standard Prolog enriched with primitives for safe state update and for communication. Two compilers exist
for translating the ProlAg agent code into SICStus Prolog and into ECLiPSE.
DESIRE agents are specified/implemented in a formal specification language for system
design supporting conceptual design through detailed but implementation independent design. An implementation generator automatically translates specifications into code in a
specific implementation environment.
IMPACT agent programs are collections of action rules describing which actions an agent
is permitted (respectively, forbidden, obliged, no more obliged) to take, or which actions
it actually takes, according to the result of an access to the underlying software and/or to
other permissions (obligations, ...) it has. An agent behavior is also determined by the
integrity constrains it must satisfy.
Zeus agents are programmed by entering their characterizing features through the Agent
Editor panel. The agent is ascribed the application-specific tasks it is capable of performing, the rules it can execute, its initial resources, the knowledge about other agents in the
298
system, and so on. The agent code can be automatically generated when all these features
have been defined.
ò Agents skeletons. AgentBuilder does not provide agent skeletons for covering standard
roles and tasks or for implementing different existing architectures. Different reusable architecture models have been developed in CaseLP: in [30] the BDI architecture is modeled
in one of the specification languages supported by CaseLP, õ hhf , and in [11] a model of
the Subsumption architecture [40, 41, 42, 43] in õ hhf is given. In [61] the use of HEMASL
for modeling BDI and reactive agents is discussed. Part of this work in included in Appendix C.1. A great work in the reusable agent skeletons direction has been done by the
DESIRE team: they have developed a number of reusable generic models for architectures
and tasks [34]. For example, generic agent models for autonomous agents with reactive,
pro-active and social behavior have been developed, as well as for reflective agents and
agents based on mentalistic notions. Generic task models for design, diagnosis based on
causal and anti-causal knowledge, and process control are also provided.
IMPACT does not provide standard skeletons, but it supports libraries: for actions and
other functions, execution models, etc.
In Zeus it is possible to equip an agent with a pre-built coordination protocol and interaction strategies; this can be seen as reusing a pre-built skeleton for defining the interaction
behavior the agent will follow when it plays a given role.
ò Physical environment models. No model of the physical environment is explicitly supported by the MASDKs we are analyzing. Each agent has its own model of the physical
environment, and it uses this model to decide how to act.
ò Agents and MAS definition GUI. All the MASDKs provide a GUI for the definition of
the MAS.
ò Utility agents. No already-defined utility agents are provided by AgentBuilder, by CaseLP
and by DESIRE.
The IMPACT Server can be seen as an agent providing utility services such as Registration
Service, for registering the services an agent provides, and Yellow Pages Service, which
accesses the data structures created by the registration server for matching service request
and service availability.
The Zeus utility agents are the Agent Name Servers (ANS), the Facilitators, the Visualizers and the Database Proxies. The ANSs maintain a registry of known agents, enabling
them to map agent identities to a logical network location. The Facilitators help in retrieving agents which provide the required service. The Visualizers are useful for execution
monitoring and debugging. The Database Proxies provide the means of storing persistently the agent session information.
299
ò Debugging facilities. All the toolkits which allow to follow the execution of the MAS
session and to interactively change its parameters, provide in a certain sense the means for
debugging the application. Also the ability to formally verify MAS properties can help in
debugging the application under development.
A.6
Technical issues
ò Mobility. No toolkit supports mobility. From a conceptual point of view, it should not be
so difficult to build mobile agents with the toolkits implemented in Java, since it should be
possible to integrate the code for mobile agents already developed in this language. But,
from a practical point of view, some problems could arise, and maybe this is the reason
why AgentBuilder, IMPACT and Zeus, all implemented in Java, do not support mobile
agents. Some experiments have been done within the Zeus framework, but the answer
to the question “Does Zeus support mobility” is still no. The IMPACT team is maybe
at a better point on dealing with mobile objects, but they are still considering security
and re-initialization issues regarding a mobile Java object thread, thus the support is not
completely reliable yet.
ò Distribution. AgentBuilder, DESIRE, IMPACT and Zeus allow to transparently distribute the agents in the system over a network.
CaseLP allows the realization of a centralized prototype, where distribution is only simulated. D-CaseLP will support real agent distribution.
ò Concurrency. Apart from CaseLP agents, which are activated sequentially by a roundrobin scheduler, all the other MASDKs allow concurrent execution of agents.
ò Security. The only toolkit which faces security issues, at least from a theoretical point of
view, is IMPACT [27]. IMPACT focuses on the ability of agents to follow the
– data security principle: for each data-object in an agent’s state, there may be restrictions on which other agents may read, write, or manipulate that data; and the
– action security principle: for each action in an agent’s repertoire, there may be restrictions on which other agents may utilize those actions.
The mechanisms to support security have not been implemented yet.
ò Real-time control. It is not so easy to tell in advance if a toolkit will be suitable for realtime applications. We know that AgentBuilder and IMPACT have been used for developing such kind of applications (see [105] and http://www.cs.umd.edu/projects/
impact/apps.html, respectively), but it is not enough to say that every time-critical
application can be modeled with them. As far as CaseLP and Zeus are concerned, they
300
are definitely not suitable for implementing real-time applications (at least, with the currently available versions), while the suitability of DESIRE for these applications is not
clear.
ò Performance. CaseLP performance is scarce: we were able to run heavy simulations
involving a large amount of agents and messages, but they required hours to be completed.
As far as IMPACT is concerned, [73] discusses either theoretical complexity and experiments on performance in great detail. In particular, the theoretical complexity results show
that for positive agent programs2 with integrity constraints, the reasonable and feasible
status sets can be polinomially computed. Experimental results show that if the developer
is willing to pay a price at the time an agent is deployed, then she may end up with huge
savings at run time as far as set computation is concerned.
Zeus is implemented in Java. An efficient Java compiler could solve some of the issues
related with the toolkit performance, but, according to many messages collected in the
Zeus archive, the toolkit is perceived as being slow for many time-critical applications.
The Java choice was motivated by portability, which was more important to the Zeus staff
that performance. A group of persons at Metallect Corp. (http://www.metallect.
com/) is working on developing a C++ version of Zeus which will probably enhance its
performance.
ò Latency. The exchange of messages in CaseLP is simulated by writing a message in
the receiver’s mailbox. In this sense, message delivery is immediate. However, latency
can be simulated by explicitly assigning a “minimum latency value” and a “maximum
latency value” to messages flowing from agent A to agent B, for every agent A and agent
B in the system. Whenever agent A sends a message to agent B, the system generates
a random number with uniform distribution in the established range which simulates the
delay between agent A sending the message and agent B receiving it. In a similar way it is
also possible to establish how many messages can be lost due to transmission problems. If
a simulation with latency on channels is run, messages can clearly arrive with a different
order they were sent.
Since IMPACT uses standard networking protocols for messaging instead of inventing a
new one, it may happen that messages are sent with some delay and that they are received
in a different order they were sent.
Zeus messaging is done via TCP/IP which ensures ordering of messages within the same
socket connection. Whereas each Zeus message is sent in its own socket, it is not possible
to rely on the transport mechanism preserving order. Thus, not only messages can be
received with some latency, due network traffic, but they also can be received out of order.
ò Error-tolerance. No toolkit provided support for error-tolerant agents. As a contribution
of this dissertation, IMPACT has been extended in this direction.
2
See Definition 6 in Section 3.5.3.1.
301
ò Software integration. The ability of integrating heterogeneous software is one of the major aims of IMPACT, whose formal theory is based on the concepts of code calls (calls to
external software packages with a well defined API) and code call conditions (conditions
on the objects returned by a code call). The actions an agent can perform are characterized
by preconditions, add and delete lists which involve code call conditions. The semantics
of agent programs provides, in a certain sense, a semantics to the way external software
is accessed. IMPACT has been used to integrate a wide variety of distributed, heterogeneous databases (US Army Logistics Integration Agency’s “Virtual Operations Center”,
see http://www.cs.umd.edu/projects/impact/apps.html).
As far as the other toolkits are concerned, they allow the integration of external software,
but in a less formal way. AgentBuilder agents support JNI. Thus any external software
module meeting JNI requirements can be used.
CaseLP allows the integration of those packages versus which the implementation language (SICStus Prolog or ECLiPSE) provides an interface.
DESIRE can integrate Java, Prolog, or any external program communicating through
sockets, files or pipes.
Zeus can integrate relational databases through JDBC, and other external packages have
been successfully integrated by the users of the toolkit.
ò Other issues.
– AgentBuilder:
÷ Platform required: AgentBuilder requires a Java Virtual Machine capable of
executing Java 1.1.x. It has been tested on Solaris, Windows 95, Windows 98,
Windows NT, Linux, and IRIX platforms.
÷ Implementation language: Java.
÷ System resources required: Hardware: 133 MHz Pentium machine recommended
for Windows 95/98, Windows NT and LINUX platforms.
RAM requirements: Windows 95/98, Windows NT, and LINUX: 16 MB (32 MB
recommended); Solaris: 64 MB.
Disk space requirements: Windows 95/98/ NT: 11 MB; Linux: 15 MB; Solaris:
15 MB.
÷ Price: AgentBuilder Pro: starting from $ 495.00; AgentBuilder Lite: starting
from $ 95.00.
÷ Availability of evaluation releases: an evaluation copy of AgentBuilder Pro is
available.
– CaseLP:
÷ Platform required: CaseLP requires a SICStus Prolog or an ECLiPSE interpreter. The SICStus Prolog implementation has been tested on Linux, Windows
95/98 and Windows NT.
302
÷ Implementation language: SICStus Prolog and ECLiPSE.
÷ System resources required: CaseLP is extremely lightweight, it is sufficient that
the system supports the Prolog interpreter.
÷ Price: CaseLP is not commercially available.
÷ Availability of evaluation releases: since a new distributed version is under development, no copies of the old centralized version are made available; the distributed version of CaseLP will be made available for free.
– DESIRE:
÷ Platform required: DESIRE is actively used on Windows 95/98, NT, 2000. It
will work on any not too old Windows platform. On Linux platforms, it is actively used on Redhat, Suse. It will work on any not too exotic Linux variant.
Finally, it is actively used on Solaris.
÷ Implementation language: Prolog, xpce, C, Java.
÷ System resources required: The GUI requires a screen resolution of at least 1024
by 768 pixels. Depending on the complexity of the application and on performance requirements a reasonably modern hardware configuration will be sufficient (i.e. say 500 MHz pentium III with 64 MB internal memory).
÷ Price: Not commercially available.
÷ Availability of evaluation releases: For those who attend the annual course.
– IMPACT:
÷ Platform required: IMPACT runs on Sparc Ultra 1’s (Solaris), Linux, Windows
95, 98, 2000 and NTWS 4.0.
÷ Implementation language: The Agent Development (AgentDE), Roost, and Message Logger environments are currently implemented via Java 1.2.2. Moreover,
many students in a recent (Fall ‘2000) course ran it from Java 1.3 without difficulty. It should be possible to run it on any system where the Java 1.2.2 (or
1.3) virtual machine run-time code is installed.
÷ System resources required: The Java archive (JAR) file (the IMPACT class library) is currently about 2 Megabytes. Compiled agent size depends on the
program, but typically are about 50K.
A quick test using the Windows NTWS 4.0 platform task monitor shows that
running the following Java applications boosts the system resource load as follows:
ø
ø 19.5 Megs AgentDE
ø 18.5 Megs Local Roost (12 agents)
19.5 Megs Networked Roost (12 agents)
These numbers will vary according to the VM implementation used (Palm tops
have a much smaller VM) and should drop further as the IMPACT code will be
optimized.
303
÷ Price: To be negotiated, depends on the user (company, academia). Licensed by
÷
the Office of Technology Commercialization, University of Maryland, College
Park.
Availability of evaluation releases: To be negotiated.
– Zeus:
÷ Platform required: as Zeus uses the latest Swing GUI components it will run
÷
÷
÷
÷
A.7
on any platform that has a JDK1.2 virtual machine installed. Each host machine should also be capable of TCP/IP communication, but there is no need
for any middleware services to be installed. Zeus has been tested on Windows
95/98/NT4 and Solaris platforms.
Implementation language: Java.
System resources required: There is no need of high-end machine to run Zeus
agents. Tests have been done with a Pentium 133 MHz and SPARC-5s.
Price: Zeus is Open Source software, and can be freely downloaded and distributed under the licensing conditions derived from the Mozilla Public License.
Availability of evaluation releases: all the Zeus releases are free.
Business issues
ò Organization. We have already cited the organizations developing the various MASDKs
in Section 4.3.
ò Training. AgentBuilder provides training at additional cost for the toolkit.
The DESIRE group organizes courses on the design of intelligent multi-agent systems,
based on DESIRE. The last one was held from April 26 to May 2, 2000, the next one will
be held from May 29 to June 4, 2002.
IMPACT organized 3 Workshops for training.
CaseLP and Zeus do not provide any training.
ò Documentation. The documentation provided by AgentBuilder aims at helping a developer to perform her task; for this reason it is easily readable and allows to get an overview
of the system, without facing too many technical details.
As far as CaseLP and DESIRE are concerned, the documentation is mainly constituted
by scientific publications; it is not easy to find some introductory material on the subject,
an no manuals of use are available.
IMPACT and Zeus are described either by simple, introductory material, and by high-level
scientific publications. Probably, the documentation for these toolkits is the most complete
one.
304
ò Support. AgentBuilder email support is free with purchase of the toolkit and telephone
support is also available. We posted some general questions to the information provider
and we got immediate answer.
CaseLP is not yet available in an open public release, thus no support is provided.
DESIRE support depends on the availability of time of the staff. We posted some questions
to the staff and we waited for a couple of weeks to obtain a complete answer.
There is no online/hotline support on a 24h basis for IMPACT.
Finally, we personally experimented the efficiency and usefulness of the Zeus mailing list;
an archive of mails is maintained where one can find an answer to many doubts; we also
posted questions to the mailing list and got answers almost immediately.
305
Appendix B
MAS modelling in CaseLP: Details
This appendix provides the suggestions a developer may follow to face the modeling of the MAS
static structure.
B.1
Determine the roles to be played within the MAS
This section is a summary of [56], which is in turn inspired by the work of E. Kendall [117]. The
definition of an agent role is formalized so that it can be modeled, designed and implemented in
software. The qualifying criteria for roles are:
ò Be modular: a role describes a set of entities that can occupy the same position in a reoccurring structure, hence a role must be modular so that new players can be assigned
without any impact on the rest of the role model.
ò Have high cohesion: to promote modularity a role must have a well-defined set of related
responsibilities and a clearly defined function; the responsibilities must form a cohesive
unit.
ò Be parsimonious: a role should not have extraneous responsibilities.
ò Be complete: a role should not be trivial; trivial roles should be merged with other roles.
ò Have low coupling: dependencies between roles must be minimized.
The MAS developer should sketch the roles to be played within the MAS and the interactions
taking place among them according to these guidelines. In this early stage, there is no need for
referring to standard roles and protocols.
306
Marketpl.
broker
1
2
Fruit
buyer
3
Fruit
seller
4
Figure B.1: The fruit marketplace application.
1
2
3
4
Collaboration
Find Fruit Seller
Fruit Sellers
Fruit buyer offer
Fruit seller response
Explanation
Asks for agents selling fruit
A list of fruit sellers
Message containing the fruit buyer proposal
Seller’s reply to the fruit buyer offer
Table B.1: Fruit marketplace role model.
As an example, consider a fruit marketplace application characterized by apples and pear buyers,
apples and pear sellers and a marketplace broker which tries to accommodate requests and offers.
The MAS developer determines that three roles are necessary in this scenario:
ò fruit buyer,
ò fruit seller,
ò marketplace broker.
Figure B.1 shows this situation, and table B.1 shows the interactions among agents. The notation
is based on [56].
B.2
Determine the complete standard role model for the MAS
In the previous static modeling step it is likely to happen that the sketched role model is strictly
dependent on the application, and that some general and relevant aspects have been forgotten.
At the second modeling stage it is useful to understand if this role model is an instance of some
existing pattern of general applicability, and if it can be modified in order to become such an
instance.
307
Broker
1
5
2
Buyer
3
(Inquirer)
Seller
(Registrant)
4
Figure B.2: Marketplace role model (from [56]).
1
2
3
4
5
Collaboration
Find Request
Find Response
Buyer offer
Seller response
Register
Explanation
Asks for agents selling items of interest
A list of agents matching the desired criteria
Message containing buyer’s proposal
Seller’s reply to a previously submitted offer
Sellers register or de-register their items for sale
Table B.2: Marketplace initial interactions (from [56]).
For example, the developer should discover that the fruit marketplace role model is an instance
of the distributed marketplace role model described in [56] and depicted in Figure B.2 and Table
B.2.
By comparing the two role models, the developer understands that she had forgotten the seller
registration collaboration, which is instead fundamental also in her domain-specific application.
The role model must be re-designed in terms of standard roles and composition of standard roles,
in order to use a standard vocabulary which can be easily understood by other developers and
can be shared by different agent systems by means of standard role ontologies.
The work by E. Kendall [117] represents a first step in this direction. At British Telecommunications (BT), where she works, a catalog of agent role models is being compiled. The objectives
of this research are:
ò to identify categories or types of roles played by agents;
ò to investigate the meaning and significance of agent roles and role modeling;
ò to determine the tools and techniques that are needed for agent role modeling and
ò to uncover and document agent role model patterns that can be employed to model and
design future agent systems.
308
When, after stage 1 of the static modeling phase, there is an informal idea of which roles will be
necessary in the MAS application, the MAS developer should organize these roles according to
the standard existing models. E. Kendall suggests to1 :
ò Look for patterns: Analyst should first look for patterns in the informal role model. For
example, roles that involve open competitive bidding can be addressed by the Contract
Net Role Model. A chain of task dependencies may match the Supply Chain Role Model.
Other role models are provided in [174] and in [56]; moreover, research at BT is documenting further agent role models.
ò Apply heuristic: If all or some of the informal roles are not covered by known patterns,
analyst has to apply general heuristics or rules of thumbs for partitioning. As an example, the analyst should remember that there are different ways to obtain role models from
existing ones:
1. one role model may be an aggregate of other role models;
2. a new role model may be derived from (specialize) one or more base models;
3. individual roles can also be brought together to form role sequences.
B.3
Group the roles in agent classes
Section 1.2 of [56] describes two criteria for assigning roles to agents. According to our model,
we allocate roles to classes of agents and not to agent instances, but this does not change the
applicability of the two metrics proposed in [56]:
1. the sphere of responsibility test and
2. the point of interaction test.
The sphere of responsibility test. This metric is derived from the fact that agents should be
autonomous, i.e. be responsible for the control of resources and provision of services. This
area of control is known as the agent’s sphere of responsibility. Thus when considering what
classes of agents will exist the developer will need to consider how the application domain will
be partitioned, i.e. the degree of coupling between roles. Consider, as an example, a scenario
involving the following roles:
ò entry of user preferences;
1
We are adapting Section 5 of [117] to our methodology.
309
ò negotiation with other traders;
ò provision of trading expertise;
ò payment and ownership exchange.
One solution would be to create one agent class for each role, namely one agent class for interacting with the user, another to interact with other agent classes, a third to provide trading expertise
and a fourth to facilitate the transaction. The appropriateness of this solution just depends on the
nature of the application. Suppose that the user interface is to run on a computer in a trader’s
office and negotiations will be performed by another piece of software on behalf of all traders
in the company. In this scenario there would seem to be two areas of responsibility: a sphere
where activities local to individual traders are supported and a company-wide sphere supporting
activities that are more efficiently centralized. Hence the sphere of responsibility test is simple:
each sphere of responsibility should possess a single agent.
It is also worth noting another factor that may help identify candidate classes of agents: agents
tend to be responsive, i.e. able to perceive their environment and respond accordingly to events
that affect their own sphere of responsibility.
The point of interaction test. The second metric extends the sphere of responsibility by considering the sociality of agents. The purpose of this test is to help separate application resources
from the entities that will use them to provide services. This is particularly relevant to applications where agent systems serve as the interfaces to legacy systems such as databases. For
instance consider a warehouse supply scenario with a stock inventory and several delivery vans.
To fulfill an order the inventory must be queried to verify availability of delivery. It seems unrealistic that the customers interact with the inventory to place an order: it is more likely that
queries would be sent to the inventory’s owner, the warehouse, which would access the inventory
and provide a result. It is also unlikely that the customers contact the delivery vans directly: we
shall assume that vans take their instructions from a delivery schedule that is maintained by a
delivery company that has a contract to delivery goods from the warehouse. This example serves
to illustrate the difference between resources and agents: agents affect resources, interactions
affect agents. This leads to the point of interaction test, which states:
the access point for information, expertise and services is a good agent candidate.
310
B.4
For each class, determine the most suitable architecture
One of the first authors to face to problem of choosing the right agent architecture to do the right
thing was J. P. Müller. In this section we propose some guidelines taken from [155].
J. P. Müller’s approach is based on empirical evidence: he studies existing agent architectures
and the applications that were built using them. Based on this test set, he derives a taxonomy
that classifies agents in terms of classes of applications they appear in, and he defines a set of
guidelines to identify what is the right agent to do the right thing. J. P. Müller assumes that all the
agents belonging to the same application should be given the same architecture: he associates the
most suitable architecture to an entire application. Our approach is more flexible, and we think
that each class of agents within the same application should be associated the right architecture
to. Moreover, J. P. Müller takes into account hardware architectures that are out of the scope of
CaseLP architecture modeling. We have thus adapted the guidelines in order to suit CaseLP
features.
J. P. Müller classifies the architectures in five categories: reactive agents, deliberative agents,
interacting agents, layered approaches and others.
Agent applications are classified along two dimensions, the material state of the agents (hardware and software) and the primary mode of interaction between the agent and its environment
(autonomous agents, multi-agents and assistant agents). The resulting taxonomy consists of six
classes, but we omit here the classes involving hardware agents, thus reducing the number of
classes to three:
ò Autonomous software agents (SW-AU). Software systems that act autonomously and
make decisions in a software environment. An example is a software agent associated with
a workflow.
ò Software assistant agents (SW-AS). Programs that assist a human on the computer screen
or in Personal Digital Assistants, that act on behalf of that human or that entertain the
human.
ò Software multi-agents (SW-MA). Programs that act as entities in a multi-agent system.
They are used for example to solve dynamic and distributed resource allocation problems,
as well as cooperative expert systems applications.
The last step of J. P. Müller’s approach is to address the question: What is the right agent architecture to apply to a specific problem? We quote part of his guidelines for this choice.
1. Check carefully if agents are really needed or whether another programming paradigm,
such as (distributed) objects, will be enough.
311
2. Use Table B.3 for a rough orientation.
3. If the problem requires autonomous software agents, it is possible to choose between some
robust architectures such as dMARS [171] and SOAR [126].
4. If the problem requires software assistant agents, then the agent architecture is definitely
not the first thing to worry about.
5. If the problem requires software multi-agents, then it would be the case to look at any of
the examples presented under the Interacting Agents category in Table B.3.
6. If the domain where the application will run is a software domain, it is likely that the
architecture of choice should:
ò be capable of multi-tasking;
ò de-couple low-level message handling from high-level message interpretation;
ò come with a service model allowing agents to vend services that are internally mapped
into tasks;
ò comply with interoperability standards;
ò have a small footprint.
7. For most interesting applications, neither purely reactive nor purely deliberative applications are useful.
8. If adaptability is crucial for the application, there is not much choice
B.5
ùMùMù
Determine the initial agent instances for each class
At this point, almost all the relevant choices have been made to establish the static architecture
of the MAS. The last decision to take concerns the number of initial necessary agent instances.
As an example, one fruit marketplace application Fruit-1 could require one seller agent, while
another application Fruit-2 could require seven seller agents. The two applications share exactly
the same features and are modeled in the same way except for this last step.
312
Architecture
Applications
Classification
Reference
arcade computer game
distributed problem-solving
SW-AU
SW-MA
[3]
[78]
originally: robotics
air traffic control, business process
enactment and monitoring
general AI problem-solving architecture, autonomous control systems, believable agents
no specific application mentioned,
supports communicative acts
SW-AU
[93]
SW-AU
[171]
SW-AU, SW-AS
[126]
SW-MA
[181] [195]
SW-MA, SW-AS
[107]
SW-AS, SW-AU
[189]
SW-MA
[46]
SW-AU
[79]
SW-MA
[154]
SW-AU
[187]
Reactive
PENGI
ECO model
Deliberative agents
PRS (BDI)
dMARS (BDI)
SOAR
Agent0 / PLACA
Interacting agents
electricity network diagnosis,
workflow management
traffic control systems, personal
digital assistants
production planning, transport
planning
GRATE*
MECCA
COSY
Layered approaches
TouringMachines
INTERRAP
SimAgent
mobile robots and land vehicles
cooperating robots, flexible transport systems, game playing agents,
logistics
humanoid robots or softbots
Table B.3: Agent architectures and agent applications.
313
Appendix C
CaseLP specification languages: Details
The formalization of the languages and the examples presented in this appendix have been developed by R. Degl’Innocenti under the guidance of M. Martelli and myself. They are contained
in his master thesis [61].
C.1
HEMASL and its relations with UML
C.1.1 Formal syntax of HEMASL
NOTES:
“e-s” represents the empty string.
“skip” is the program composed by no instructions.
Strings preceded by // are comments or static semantic constraints.
PROGRAM ::= [IMPORT]“;” ABSTRACT ARCHITECTURE*;
CONCRETE ARCHITECTURE*“;” MAS“.”
IMPORT ::= import “ ú ” UML PACKAGE* “ û ”
ABSTRACT ARCHITECTURE ::= abstract architecture“ ú ”ARCH NAME“ û ”
“ ú ”extends ARCH NAME“ û ”“ ú ” TYPE DECL“;” ABS COMPONENTS“;”
ABS PROCS“;” PROCS“;” ENGINE“ û ”“;”
CONCRETE ARCHITECTURE ::= architecture “ ú ” ARCH NAME “ û ”
is a “ ú ” ARCH NAME “ û ” “ ú ” TYPE DEF“;”
COMPONENTS“;” INIT GLOBAL VARS“;” PROCS “ û ”
MAS ::= MAS “ ú ” AGENT CLASS*“;” INIT ENV ETH“;” AGENTS* “ û ”
AGENT CLASS ::= class agent “ ú ” ARCH NAME “ û ”“,”
“ ú ” CLASS AGENT NAME “ û ”“,”
314
[ ú extends CLASS AGENT NAME û ] ú ROLE PLAYING û
ú INIT COMPONENTS û ;
TYPE DECL ::= type declaration ú DECL TYPE PAR* û ;
DECL TYPE PAR ::= varType T V NAME; ü
typeDef TY NAME : TYPE; ü
INT NAME: INTERFACE; ü
use IMP NAME : IMP TYPE; ü
TY NAME ::= ALPHANUMERIC STRING
IMP TYPE ::= ALPHANUMERIC STRING
T V NAME ::= ALPHANUMERIC STRING
INT NAME ::= ALPHANUMERIC STRING
ABS COMPONENTS ::= components ú DEF ABS COMPS* û
DEF ABS COMPS ::= MODED COMP NAME : ABS TYPE;
ABS TYPE ::= e-s ü PARAM TYPE
PARAM TYPE ::= T V NAME ü TY NAME ü TYPE ü INTERFACE ü IMP TYPE
TYPE ::= int ü real ü bool ü char ü string ü mode ü TYPE CONS ü IMP TYPE
TYPE CONS ::= list (TYPE) ü stack ( TYPE ) ü queue ( TYPE) ü
set (TYPE) ü tupla (NAT, TYPE[,TYPE] )
INTERFACE ::= ALPHANUMERIC STRING //previously defined
MODED ::= agent ü class
ABS PROCS ::= abstract procedures ú ABS PROC* û ;
ABS PROC ::= PROCEDURE NAME(FORMAL PARAMS);
PROCS ::= procedures ú DEF PROC* û
DEF PROC ::= PROCEDURE NAME(FORMAL PARAMS) ú PROG û ;
FORMAL PARAMS ::= FORMAL PARAM [,FORMAL PARAMS]* ü
EMPTY
FORMAL PARAM ::= VARS DECL ü ! VARS DECL
VARS DECL ::= VARS : PARAM TYPE
PROG ::= skip ü
INSTRUCTION ü
INSTRUCTION “;” PROG ü
INSTRUCTION “ ý ” PROG ü
INSTRUCTION “ ü ” PROG
INSTRUCTION ::= if (BOOL) then ú PROG û else ú PROG û endif ü
case (EXP) CASE ELEM+ otherwise ú PROG û endcase ü
while (BOOL) do ú PROG û endwhile ü
send(RECEIVER, CONTENT) ü
receive(SENDER, CONTENT) ü
receive sync(SENDER, CONTENT) ü
exec(CONTENT) ü
put event(EVENT) ü
315
remove event(EVENT) ü
percept(EVENT) ü
decl VARS DECL ü
VARS := EXP ü
PROC CALL ü
COMP INT ü
METHOD CALLING
CASE ELEM ::= VALUE : ú PROG û
PROC CALL ::= PROCEDURE NAME(ACTUAL PARAMS)
ACTUAL PARAMS ::= EXP[,EXP]* ü EMPTY
TYPE DEF ::= type definition ú TYPE DEFS* û
TYPE DEFS ::= TY NAME : TYPE ; ü
T V NAME : TYPE ; ü
INT NAME : TYPE ; ü INTERFACE : TYPE;
ROLE PLAYING ::= role playing ú ROLES û
ROLES ::= ROLENAME [; ROLENAME]
ROLENAME ::= ALPHANUMERIC STRING
COMPONENTS ::= components ú DEF COMP* û
DEF COMP ::= COMP NAME : TYPE; // only for undefined components
ENGINE ::= engine ú DEF GLOBAL VAR* PROG û ;
DEF GLOBAL VAR ::= decl VARS : ABS TYPE;
INIT COMPONENTS ::= ú INIT COMP* û ;
INIT COMP ::= init comp ú DEF INIT COMP* û ;
DEF INIT COMP ::= COMP NAME : TYPE [VALUE];
INIT ENV ETH ::= init ENV[EVENT*]; init ETH[MESSAGGES*]
AGENTS ::= DEF AGENTS*
DEF AGENTS ::= create agent(CLASS AGENT NAME, AGENT NAME)
ú INIT COMP* û
INIT GLOBAL VARS ::= init global vars ú INIT VARS* û
INIT VARS ::= VARS : TYPE := EXP;
EVENT ::= (ALPHANUMERIC STRING, VALUE)
MESSAGGES ::= (SENDER, RECEIVER, CONTENT)
ARCH NAME ::= ALPHANUMERIC STRING
CLASS AGENT NAME ::= ALPHANUMERIC STRING
COMP NAME ::= ALPHANUMERIC STRING
SENDER ::= any ü ALPHANUMERIC STRING
RECEIVER ::= all ü ALPHANUMERIC STRING
CONTENT ::= ALPHANUMERIC STRING
AGENT NAME ::= ALPHANUMERIC STRING
PROCEDURE NAME ::= ALPHANUMERIC STRING
VARS ::= ALPHANUMERIC STRING
316
VALUE ::= EXP
ALPHANUMERIC STRING ::= LETTER ü [LETTER ü DIGIT ü SPC SYM]
LETTER ::= ’a’..’z’ ü ’A’..’Z’
DIGIT ::= ’1’..’9’
SPC SYM::= ’ ’ ü ’-’
*********************EXPRESSIONS*********************
EXP ::= NIL ü
EXP LIST ü
EXP STACK ü
EXP QUEUE ü
EXP SET ü
EXP TUPLA ü
BOOL ü
NAT ü
INT ü
REAL ü
STRING ü
VARS ü
EXP LIST.gethlist() ü
EXP LIST.gettlist() ü
EXP STACK.top stack() ü
EXP QUEUE.getqueue() ü
EXP SET.getset() ü
EXP TUPLA.gettupla(POS, EXP)
EXP LIST ::= //double linked
VARS
EXP STACK ::= //Lifo
VARS
EXP QUEUE ::= //fifo
VARS
EXP SET ::= //unordered
VARS
EXP TUPLA ::= VARS
ORD EXP ::= NAT ü INT ü REAL
BOOL ::= B TERM and BOOL ü
B TERM or BOOL ü
not BOOL ü
B TERM
B TERM ::= false ü
317
true ü
VARS ü
EXP = EXP ü
ORD EXP þ ORD EXP ü
ORD EXP ÿ ORD EXP
NAT ::= NAT TERM + NAT ü NAT TERM - NAT ü NAT TERM
NAT TERM ::= NAT NUM * NAT TERM ü
NAT NUM / NAT TERM ü
NAT NUM
NAT NUM ::= NUMBER ü VARS
INT ::= INT TERM + INT ü INT TERM - INT ü INT TERM
INT TERM ::= INT NUM * INT TERM ü INT NUM / INT TERM ü INT NUM
INT NUM ::= -NUMBER ü +NUMBER ü number ü VARS ü STRING.stringToInt()
REAL ::= REAL TERM + REAL ü REAL TERM - REAL ü REAL TERM
REAL TERM ::= REAL NUM * REAL TERM ü
REAL NUM / REAL TERM ü
REAL NUM
REAL NUM ::= -RNUMBER ü +RNUMBER ü RNUMBER ü VARS
RNUMBER ::= NUMBER.NUMBER ü NUMBER
STRING ::= VARS ü
STRING.append(STRING) ü
STRING.substring(NAT,NAT) ü
STRING.intToString(INT) ü
CHAR ::= charset standard Ascii ü
STRING.charAt(NAT)
MODE ::= NAT ü head ü tail
MODE EXP ::= MODE ü NIL ü EXP
*********************method Calling*********************
METHOD CALLING ::= CALL LIST ü
CALL STACK ü
CALL QUEUE ü
CALL SET ü
CALL TUPLA ü
CALL STRING ü
IMPORTED METHOD CALLS
CALL STRING ::= STRING.new(CHAR+) ü STRING.e string()
CALL LIST ::= EXP LIST.e l() ü
EXP LIST.is e l() ü
EXP LIST.inshlist(EXP) ü
318
EXP LIST.instlist(EXP) ü
EXP LIST.delhlist() ü
EXP LIST.deltlist() ü
EXP LIST..append(EXP LIST,EXP LIST)
CALL STACK ::= EXP STACK.e s() ü
EXP STACK.is e s() ü
EXP STACK.put stack(EXP) ü
EXP STACK.pop stack()
CALL QUEUE ::= EXP QUEUE.e q() ü
EXP QUEUE.is e q() ü
EXP QUEUE.insqueue(EXP) ü
EXP QUEUE.delqueue()
CALL SET ::= EXP SET.e set() ü
EXP SET.is e set() ü
EXP SET.insert(EXP) ü
EXP SET.removeset(EXP)
CALL TUPLA ::= EXP TUPLA.e t(NAT) ü
EXP TUPLA.is e t() ü
EXP TUPLA.puttupla(POS,EXP) ü
EXP TUPLA.deltupla(POS)
COMP INT::= COMP NAME.e comp() ü
COMP NAME.is e comp() ü
COMP NAME.get comp(MODE EXP) ü
COMP NAME.put comp(MODE EXP,EXPRESSION)
COMP NAME.del comp(MODE EXP)
ü
C.1.2 The use of HEMASL in CaseLP
This section describes the distributed marketplace application depicted in Figures 6.6 and 6.7,
that we reproduce in this appendix (Figures C.4 and C.1) for easiness of reading, specified using
HEMASL. Figure C.2 shows the UML class representing the abstract BDI architecture and Figure
C.3 shows the UML statechart diagram for the BDI engine.
abstract architecture
BDI
abstract_architecture {bdi} {
type_declaration {
319
BDI_architecture
Reactive_architecture
abstract
abstract
BDI_1
Reactive_1
concrete
concrete
<<instance of>>
<<instance of>>
<<instance of>>
<<instance of>>
Seller
sell_Merchandise:
SellMerchandise
Trader
buy_Merchandise:
BuyMerchandise
Buyer
buy_Merchandise:
BuyMerchandise
sell_Merchandise:
SellMerchandise
Broker
locate_Sellers:
LocateSellers
register_Sellers:
RegisterSellers
Figure C.1: The agent diagram for the distributed marketplace application.
320
varType
varType
varType
varType
varType
varType
varType
Plan;
Belief;
Intention;
Trigger;
Conditions;
Action;
Event;
}
components {
class plans_component: component(Plan);
agent beliefs_component: component(Belief);
agent intentions_component: component(Intention);
};
abstract_procedures{
get_action(intention : Intention, !action : Action);
get_event_trigger(!trigger : Trigger);
get_plan_trigger(plan : Plan, !trigger : Trigger);
get_cond(plan : Plan, !conditions : Conditions);
get_plan_intention(plan : Plan, !intention : Intention);
percept_event_from_extern();
select_plan(!plan : Plan);
test_cond(conditions : Conditions, !res:bool);
exec_action(action : Action);
}
procedures {
percept_event() {
percept_event_from_extern()
};
plan_triggering() {
decl event_trigger: Trigger;
decl plan_trigger: Trigger;
decl plan: Plan;
decl aux_plans: stack(Plans);
decl empty: bool;
aux_plans.e_s();
empty = events.is_e_comp();
if (empty) then {skip}
else{
selected_event = events.get_comp(GetEventMode);
events.del_comp(DelEventMode);
get_event_trigger(!event_trigger);
empty = plans_component.is_e_comp();
while (not(empty)) do {
plan = plans_component.get_comp(GetPlansCompMode);
get_plan_trigger(plan, !plan_trigger);
if (plan_trigger = event_trigger)
then {
triggered_plans.put_comp(PutTrigPlanMode,plan)
321
} else {skip}
endif;
aux_plans.put_stack(plan);
plans_component.del_comp(DelPlanCompMode);
empty = plans_component.is_e_comp();
} endwhile
while not(aux_plans.is_e_s()) do {
plans_component.put_comp(PutPlansCompMode,aux_plans.top_stack());
aux_plans.pop_stack();
} endwhile
} endif
};
plan_selection() {
decl plan: Plan;
decl conditions: Conditions;
decl res: bool;
decl empty : bool;
empty = triggered_plans.is_e_comp();
plan = triggered_plans.get_comp(GetTrigPlansMode);
get_cond(plan, !conditions);
test_cond(conditions, !res);
if (res) then {selected_plans.put_comp(PutSelPlanMode,plan)}
else {triggered_plans.del_comp(DelTrigPlanMode)}
endif
} endwhile
};
upgrade_intentions_component() {
decl plan: Plan;
decl empty: bool;
decl intention: Intention;
empty = selected_plans.is_e_comp();
if not(empty) then {
select_plan(!plan);
get_plan_intention(plan, !intention);
intentions_component.put_comp(PutIntCompMode, intention)
} else {skip}
};
exec_intention() {
decl actions_list: list(Action);
decl action: Action;
decl empty : bool;
decl intention:Intention;
empty = intentions_component.is_e_comp();
else {
intention = intentions_component.get_comp(GetIntCompMode);
get_action(intention, !action);
322
exec_action(action)
} endif
};
engine
decl
decl
decl
decl
{
events: component(Event);
selected_event: Event;
triggered_plans: component(Plans);
selected_plans: component(Plans);
decl PutPlansCompMode: mode;
decl GetPlansCompMode: mode;
decl DelPlansCompMode: mode;
decl PutIntCompMode: mode;
decl GetIntCompMode: mode;
decl GetEventMode: mode;
decl DelEventMode: mode;
decl PutTrigPlanMode: mode;
decl GetTrigPlanMode: mode;
decl DelTrigPlanMode: mode;
decl PutSelPlanMode: mode;
while (true) do {
percept_event();
plan_triggering();
plan_selection();
upgrade_intentions_component();
exec_intention()
} endwhile
}
};
reactive
abstract_architecture {reactive} {
type_declaration{
varType Rule;
varType Fact;
varType Event;
varType Trigger;
varType Action;
}
components{
facts: component(Fact);
323
rules: component(Rule);
}
abstract_procedures{
get_action(rule: Rule, !action : Action);
get_event_trigger(event : Event, !trigger: Trigger);
get_rule_trigger(rule: Rule, !trigger: Trigger);
exec_action(action: Action, event: Event);
}
procedures{
percept_event(){
};
rules_triggering(){
decl event_trigger: Trigger;
decl rule_trigger: Trigger;
decl rule: Rule;
decl aux_rules: stack(Rule);
decl empty: bool;
decl selected_event:Event
aux_rules.e_s();
empty = events.is_e_comp();
else {
selected_event = events.get_comp(GetEventMode);
events.del_comp(DelEventMode);
get_event_trigger(selected_event, !event_trigger);
empty = rules.is_e_comp();
rule = rules.get_comp(GetRulesMode);
get_rule_trigger(rule, !rule_trigger);
if (rule_trigger = event_trigger) then {
active_rules.put_comp(PutTrigRuleMode,rule);
active_event.put_comp(PutActEventMode,selected_event);
}else {skip}
endif;
aux_rules.put_stack(rule);
rules.del_comp(DelRulesMode);
empty = rules_component.is_e_comp();
} endwhile
while not(aux_rules.is_e_s()) do{
rules.put_comp(PutRulesMode,aux_rules.top_stack());
aux_rules.pop_stack();
} endwhile
} endif
};
exec_action(){
decl rule: Rule;
324
decl action: Action;
decl empty : bool;
empty = active_rules.is_e_comp();
while (not empty) do {
rule := active_rules.get_comp(GetActRuleMode);
active_rules.del_comp(GetActRuleMode);
get_action(rule, !action);
event := active_event.get_comp(GetActEventMode);
exec_action(action, event);
empty = active_rules.is_e_comp();
}endwhile
};
}
engine {
decl active_rules: component(Rules);
decl events: component(Event);
decl active_events:component(Event);
while (true) do{
percept_event();
rules_triggering();
exec_action();
} endwhile
}
}
concrete architecture
BDI
architecture {bdi_1} is a {bdi} {
type_definition{
varType Plan: tupla(3,Trigger, Conditions, Intention);
varType Trigger: string;
varType Conditions: list(Condition);
varType Intention: list(Action);
varType Belief: tupla(2,BelIde,BelValue);
varType Condition: tupla(2,CondType, BelIde);
varType Action: tupla(2,ActType, ActValue);
varType Event:Belief;
Message: Event;
BelIde: string;
BelValue: tupla(4,string,list(string), int, real);
CondType : string;
ActType : string;
ActValue: Belief;
325
}
components {
plans_component: list(Plan);
beliefs_component: list(Belief);
intentions_component: set(Intention);
};
init_global_vars {
events: queue(Event) = e_q;
selected_event = e_t(2);
triggered_plans: list(Plan) = e_l;
selected_plans: list(Plan) = e_l;
PutPlansCompMode = head;
GetPlansCompMode = head;
DelPlansCompMode = head;
PutIntCompMode = NIL;
GetIntCompMode = NIL;
GetEventMode = NIL;
DelEventMode = NIL;
PutTrigPlanMode = head;
GetTrigPlanMode = head;
DelTrigPlanMode = head;
PutSelPlanMode = head;
};
procedures {
/* procedures on the global varieble
"events" */
percept_event_from_extern() {
decl mex: Message;
receive(All, mex);
events.insqueue(mex);
}
get_event_trigger(!trigger : Trigger) {
trigger := selected_event.gettupla(1)
};
get_event_value(!value:BelValue) {
value := selected_event.gettupla(2);
};
/* procedures on the global variable "selected_plans" */
select_plan(!plan : Plan) {
326
plan := selected_plans.gethlist()
};
/* procedures on plans */
get_plan_trigger(plan : Plan, !trigger : Trigger) {
plan_trigger := plan.gettupla(1)
};
get_cond(plan : Plan, !conditions : Conditions) {
conditions := plan.gettupla(2)
};
get_plan_intention(plan : Plan, !intention : Intention) {
intention := plan.gettupla(3)
};
test_cond(conditions : Conditions, !res:bool) {
decl condition:Condition;
decl partRes : bool;
res:true;
partRes:true;
if (conditions.is_e_l()) then {skip}
else{
while (not (conditions.is_e_l() and partRes){
condition := conditions.gethlist();
test_single_cond(condition, partRes)
conditions.delhlist();
} endwhile;
res := partRes;
} endif;
};
test_single_cond (condition : Condition, !res:bool) {
decl auxbel : Belief;
decl data : BelValue;
decl aux_data : BelValue;
decl event_value :ActValue;
decl auxstr:string;
if (condition.gettupla(2) = NIL) then
{skip}
else {get_belief(condition.gettupla(2), !data);} endif;
case condition.gettupla(1)
check_broker: get_event_value(event_value);
if (event_value.gettupla(1)=data.gettupla(1))
then
{res:=true;
strlist:= event_value.gettupla(2);
str:=strlist.gethlist();
strlist.delhlist();
get_belief(str,aux_data);
327
aux_data.puttupla(2,strlist);
auxbel.puttupla(1,str);
auxbel.puttupla(2,aux_data);
put_belief(auxbel);
}
else {res:=false} endif;
wrong_channel: get_event_value(event_value);
if (data.gettupla(1) = event_value.gettupla(1))
then
{res:=false}
else {
res:=true;
send(event_value.gettupla(1), "busy")
} endif;
check_channel: get_event_value(event_value);
get_event_trigger(auxstr);
if (auxstr="propose") then {
if (data = NIL or
data.gettupla(1) = event_value.gettupla(1))
then {
res:= true,
auxbel.puttupla(1,"contract");
auxbel.puttupla(2,event_value);
put_belief_component(auxbel);
} else {res:= false} endif;
} else {
if (data.gettupla(1)=event_value.gettupla(1))
then {res:=true}
}endif;
seller_mode: if (data.gettupla(1) = "sell") then
{res:=true}
else {
res:=false;
} endif;
buyer_mode:if (data.gettupla(1) = "buy") then
{res:=true}
else {
res:=false;
} endif;
is_zero_merch: get_event_value(event_value);
get_belief(eventValue.gettupla(2).gethlist(), aux_data)
if (aux_data.gettupla(3) = 0) then
{res:=true;}
less_eq_ev_int: get_event_value(event_value);
if (event_value.gettupla(3) <= aux_data.gettupla(3))
then {res:=true}
328
great_ev_int: get_event_value(event_value);
if (event_value.gettupla(3) > aux_data.gettupla(3)) then
{res:=true}
less_eq_ev_real: get_event_value(event_value);
if (event_value.gettupla(4) <= aux_data.gettupla(4))
then {res:=true}
else {res:=false}
endif;
great_ev_real: get_event_value(event_value);
if (event_value.gettupla(4) > aux_data.gettupla(4))
then {res:=true}
else {res:=false}
endif;
endcase
};
/* procedures on the component "belief _component" */
get_belief(id: BelIde, !data:Belief) {
decl bel: Belief;
decl aux_bel: stack(Belief);
decl empty: bool;
aux_bel.e_s();
empty:= belief_component.is_e_l();
bel:= belief_component.gethlist();
while (not(id = bel.gettupla(1)) and not(empty)) do {
bel:= belief_component.gethlist()
if (id = bel.gettupla(1)) then {
data := bel;
}
else {
belief_component.delhlist();
aux_bel.put_stack(bel);
} endif
} endwhile;
if (empty) then {data := NIL } else {skip} endif;
while (not(aux_bel.is_e_s())) do {
belief_component.inshlist(top_stack(aux_bel));
aux_bel.pop_stack();
}endwhile
};
get_belief_value(id: BelIde, !data:BelValue) {
decl bel: Belief;
329
decl empty: bool;
aux_bel.e_s();
bel:= belief_component.gethlist();
bel:= belief_component.gethlist()
if (id = bel.gettupla(1)) then {
data := bel.gettupla(2);
}
else {
} endif
} endwhile;
if (empty) then {data := NIL } else {skip} endif;
}endwhile
};
remove_belief(id: BelIde) {
decl bel: Belief;
decl empty:bool;
aux_bel.e_s();
if (not(empty)) then {
bel := belief_component.gethlist();
else {
bel := belief_component.gethlist()
} endif
} endwhile;
if empty then {skip}
else {
} endif
} else {skip}
endif;
330
} endwhile;
};
put_belief_component(belief: Belief) {
decl id: BelIde;
decl bel: Belief;
decl empty:bool;
aux_bel.e_s();
id := belief.gettupla(1);
if not(empty) then {
bel := belief_component.gethlist();
else {bel := belief_component.gethlist()}
endif
} endwhile;
if (empty) then {
belief_component.inshlist(belief)
} else {
} endif
} else {
} endif;
while not(aux_bel.is_e_s()) do {
} endwhile;
};
get_action(intention : Intention, !action : Action) {
if not(intention = e_l) then{
action := intention.gethlist();
intentions_component.removeset(intention);
intention.delhlist();
intentions_component.insert(intention);
}
else {action:= NIL}
endif
}
exec_action(action : Action) {
decl data: BelValue;
decl auxData: BelValue;
decl auxbel: Belief;
331
decl
decl
decl
decl
decl
receiver: string;
strlist: list(string);
name: string;
content: string;
result: boolean;
if action = NIL then skip
else
case action.gettupla(1)
send : get_belief(action.gettupla(2).gettupla(1), auxbel);
if (auxbel = NIL) then {skip;}
else{
get_belief("channel", auxdata);
str:= auxdata.gettupla(1);
send(str, auxbel);
} endif;
skip: skip;
put_bel: data:= action.gettupla(2);
put_belief(data);
rem_bel: name:= action.gettupla(2).gettupla(1);
remove_belief(name);
action: get_belief(action.gettupla(2).gettupla(1), auxbel);
if (auxbel = NIL) then {skip;}
else{exec(auxbel);} endif;
accept: get_belief("agent_name", data);
auxbel.e_t();
auxbel.puttupla(1,"accept");
auxdata.e_t();
auxdata.puttupla(1,data.gettupla(1));
auxbel.puttupla(2,auxdata);
put_belief(auxbel);
refuse: get_belief("agent_name", data);
auxbel.e_t();
auxbel.puttupla(1,"refuse");
auxdata.e_t();
put_belief(auxbel);
ack: get_belief("agent_name", data);
auxbel.e_t();
auxbel.puttupla(1,"ack");
auxdata.e_t();
put_belief(auxbel);
propose: get_belief("mode", data);
str := auxdata.gettupla(1);
get_belief("contract",auxdata);
get_belief(auxdata.gettupla(2).gethlist(),data);
332
if (str="buy") then {
if (auxdata.gettupla(4) < data.gettupla(4)) then
{result:=true;}
else {
result:=false;
put_intention_component(next_seller)
} endif;
} else {
if (auxdata.gettupla(4) > data.gettupla(4)) then
{result:=true;}
else {result:=false;} endif;
}
if (result) then {
auxbel.puttupla(1,"propose");
put_belief(auxbel);
} else {
get_belief("agent_name", data);
str := data.gettupla(1);
auxbel.e_t();
auxbel.puttupla(1,"refuse");
data.e_t();
data.puttupla(1,str);
send(auxdata.gettupla(1), auxbel)
rem_belief("propose");
rem_belief("contract");
} endif
rem_stock: get_belief("contract", auxdata);
str:=auxdata.gettupla(2).gethlist();
get_belief(str, data);
data.puttupla(3,data.gettupla(3)-auxdata.gettupla(3));
auxbel.puttupla(1,data);
put_belief(auxbel);
if (data.gettupla(3) = 0) then{
auxbel.e_t();
auxbel.puttupla(1,"finished");
auxdata.e_t();
strlist.e_l();
strlist.puthlist(str);
get_belief("agent",data);
strlist.puthlist(data.gettupla(1));
auxdata.puttupla(2,strlist);
get_belief("broker",data);
send(data.gettupla(1),auxbel);
} else {skip};
fill_stock: get_belief("contract", auxdata);
333
str:=auxdata.gettupla(2).gethlist();
get_belief(str, data);
data.puttupla(3,data.gettupla(3)-auxdata.gettupla(3));
put_belief(auxbel);
if (data.gettupla(3) = 0) then{
get_belief("need", data);
strlist:= data.gettupla(2);
remove_string(strlist,str);
data.puttupla(2,strlist);
auxbel.puttupla(1,"need");
put_belief(auxbel);
} else {skip};
mod_offer_price: get_belief("mode", data);
if (data.gettupla(1) = "sell") then {
get_belief("contract", data);
if (data = NIL) then{
get_belief("propose", data);
get_belief("sell_start", data);
start:=auxdata.gettupla(4);
get_belief(data.gettupla(2).gethstring(),
auxdata);
data.puttupla(4,auxdata.gettupla(4)*start);
} else{
get_belief("sell_step",auxdata)
data.puttupla(4,
data.gettupla(4)*auxdata.gettupla(4));
} endif;
} else {
get_belief("contract", data);
get_belief("buy_start", data);
start:=auxdata.gettupla(4);
get_belief(data.gettupla(2).gethstring(),
auxdata);
data.puttupla(4,auxdata.gettupla(4)*start);
} else{
get_belief("buy_step",auxdata)
data.puttupla(4,
data.gettupla(4)*auxdata.gettupla(4));
} endif;
}endif;
put_belief(auxbel);
mod_offer_qty: get_belief("contract", data);
334
} else{skip}
get_belief(data.gettupla(2).gethstring(),auxdata);
data.puttupla(3, auxdata.gettupla(3));
put_belief(auxbel);
next_seller: get_belief("need",data);
if (data.gettupla(2).is_e_l()) then {
message to broker;next_seller}
else{
str:=data.gettupla(2).gethlist();
data.gettupla(2).delhlist();
data.gettupla(2).puttlist(str);
get_belief(str,data);
str:=data.gettupla(2).gethlist();
data.gettupla(2).delhlist();
build propose
send(str,propose);
}
change_mode: get_belief("type", auxdata);
if (auxdata.gettupla(1) = "trader" then{
get_belief("mode", auxdata);
if (auxdata.gettupla(1) = "buy") then
{get_belief("stock", data);
if data.gettupla(2) = NIL then {skip}
else {
auxbel.e_t();
auxdata.puttupla(1,"sell");
auxbel.puttupla(1,"mode");
put_belief(auxbel);
} endif;
}
}else {
get_belief("need", data);
if data.gettupla(2) = NIL then {skip}
else {
auxbel.e_t();
auxdata.puttupla(1,"buy");
auxbel.puttupla(1,"mode");
put_belief(auxbel);
put_intention_component(next_seller);
} endif;
} endif;
} else {skip}
endcase
335
endif
}
}
};
Reactive
architecture {react_1} is a {reactive} {
type_definition{
varType Fact: tupla(2,FactIde,Value);
varType Rule: tupla(2,Trigger,Action);
varType Trigger: string;
varType Event: tupla(2,Trigger,evValue);
varType Action: list(string);
Value: list(string);
FactIde: string;
EvValue: tupla(4,string,list(string), int, real);
Message: Event;
}
components {
facts: list(Fact);
rules: list(Rule);
};
init_global_vars {
decl active_rules: queue(Rules);
decl events: queue(Event);
decl active_events: queue(Event);
};
procedures {
percept_event_from_extern() {
decl mex: Message;
receive(All, mex);
events.insqueue(mex);
};
get_action(rule : Rule, !action : Action){
action := rule.gettupla(2);
};
get_rule_trigger(rule : Rule, !trigger : Trigger){
trigger := rule.gettupla(1);
};
get_event_trigger(event: Event, !trigger : Trigger){
trigger = event.gettupla(1);
};
get_event_value()(event: Event, !value : EvValue){
value:= event.gettupla(2);
}
insert_fact(fact:Fact){
336
decl aux_fact : Fact;
decl aux_facts : stack(Fact);
aux_facts.e_s();
if (facts.is_e_l()) then { skip}
else {
while(not(facts.is_e_l())) do {
aux_fact:= facts.gethlist();
if (aux_fact.gettupla(1) = fact.gettupla(1)) then {skip}
else{aux_facts.put_stack(aux_fact)} endif;
facts.delhlist();
}endwhile;
while(not(aux_facts.is_e_s())) do {
aux_fact:= facts.top_stack();
facts.puthlist(aux_fact);
facts.pop_stack();
}endwhile;
} endif;
facts.puthlist(fact);
};
remove_fact(factide:FactIde){
aux_facts.e_s();
if (facts.is_e_l()) then {skip}
else {
if (aux_fact.gettupla(1) = factide) then {skip}
else{aux_facts.put_stack(aux_fact)} endif;
facts.delhlist();
}endwhile;
facts.pop_stack();
}endwhile;
} endif;
};
get_fact(factide:FactIde; !fact:Fact){
aux_facts.e_s();
fact:=NIL;
if (facts.is_e_l()) then {skip}
else {
if (aux_fact.gettupla(1) = factide) then {fact:= aux_fact}
else{skip} endif;
337
aux_facts.put_stack(aux_fact);
facts.delhlist();
}endwhile;
facts.pop_stack();
}endwhile;
} endif;
};
exec_action(action:Action, event:Event){
while (not(action.is_e_l()) do {
exec_single_action(action.gethlist(), event);
action.delhlist();
} endwhile;
}
exec_single_action(action:string, event:Event){
case
put_fact: aux_fact.e_t();
aux_fact.puttupla(1,event.gettupla(2).gettupla(1));
aux_fact.puttupla(2,event.gettupla(2).gettupla(2));
insert_fact(aux_fact);
remove_fact:
remove_fact(event.gettupla(2).gettupla(1));
send: aux_mex.e_t();
get_fact(event.gettupla(2).gettupla(1));
aux_mex.puttupla(1,);
aux_mex.puttupla(2,);
send(event.gettupla(2).gettupla(2).gethlist(),aux_mex);
register: strlist:= event.gettupla(2).gettupla(2);
aux_str:=event.gettupla(2).gettupla(1);
while (not(strlist.is_e_s())) do {
str:= strlist.gethlist();
strlist.delhlist();
get_fact(str,auxfact);
auxfact.puttupla(2, auxfact.gettupla(2).instlist(aux_str));
insert_fact(auxfact);
} endwhile;
finished:
aux_str:=event.gettupla(2).gettupla(2).gethlist();
get_fact(aux_str,aux_fact);
strlist:= aux_fact.gettupla(2);
while (not(strlist.is_e_s())) do {
if (strlist.gethlist()=auxstr) then {skip}
else{aux_strlist.puthlist(strlist.gethlist())} endif;
strlist.delhlist();
}
auxfact.puttupla(2,aux_strlist);
338
put_fact(aux_fact);
query:
while (not aux_str.is_e_l()) do {
get_fact(aux_str.gethlist(), aux_fact);
if (aux_fact.gettupla(2).is_e_l()){skip}
else{
aux_mex.puttupla(1,"find");
aux_mex.puttupla(2, aux_str.gethlist());
aux_mex.puttupla(2,aux_fact.gettupla(2));
send(event.gettupla(2).gettupla(1),aux_mex);
}endif;
aux_str.delhlist();
}endwhile;
}
};
}
};
MAS
MAS {
class_agent {bdi_1}{Buyer}
role_playing{Buyer} {
init_comp{
plans_component:[
(find)[(check_broker)(broker)][(next_seller)(NIL)],
(propose)[(wrong_channel)(channel)][(skip)(NIL)],
(propose)[(buyer_mode)(mode), (check_channel)(channel),
(less_eq_ev_int)(NIL), (less_eq_ev_real)(NIL)]
[(accept)(NIL), (send)(accept,NIL,NIL,NIL)],
(great_ev_int)(NIL), (less_eq_ev_real)(NIL)]
[(mod_offer_qty)(NIL), (propose)(NIL),
(send)(propose,NIL,NIL,NIL)],
(less_eq_ev_int)(NIL), (great_ev_real)(NIL)]
[(mod_offer_price)(NIL), (propose)(NIL),
(great_ev_int)(NIL), (great_ev_real)(NIL)]
[(mod_offer_qty)(NIL), (mod_offer_price)(NIL),
(propose)(NIL), (send)(propose,NIL,NIL,NIL)],
(is_zero_merch)(NIL)]
[(refuse)(NIL), (send)(refuse),
(remove_belief)(contract,NIL,NIL,NIL),
339
(remove_belief)(channel,NIL,NIL,NIL)],
(accept)[(wrong_channel)(channel)][(skip)(NIL)],
(accept)[(buyer_mode)(mode), (check_channel)(channel)]
[(fill_stock)(NIL), (ack)(NIL), (send)(ack,NIL,NIL,NIL)
(remove_belief)(channel,NIL,NIL,NIL)
(next_seller)(NIL)],
(ack)[(wrong_channel)(channel)][(skip)(NIL)],
(ack)[(buyer_mode)(mode), (check_channel)(channel)]
[(fill_stock)(NIL), (remove_belief)(contract,NIL,NIL,NIL),
(refuse)[(wrong_channel)(channel)][(skip)(NIL)],
(refuse)[(buyer_mode)(mode), (check_channel)(channel)]
[(remove_belief)(contract,NIL,NIL,NIL),
(busy)[(wrong_channel)(channel)][(skip)(NIL)],
(busy)[(buyer_mode)(mode), (check_channel)(channel)]
};
}
class_agent {bdi_1}{Seller}
role_playing{Seller} {
init_comp{
plans_component:[
(propose)[(seller_mode)(mode), (check_channel)(channel),
340
(accept)[(seller_mode)(mode), (check_channel)(channel)]
[(less_stock)(NIL), (ack)(NIL), (send)(ack,NIL,NIL,NIL)
(ack)[(seller_mode)(mode), (check_channel)(channel)]
[(less_stock)(NIL), (remove_belief)(contract,NIL,NIL,NIL),
(refuse)[(seller_mode)(mode), (check_channel)(channel)]
];
};
}
class_agent {bdi_1}{Trader}{extends Buyer}
role_playing{Seller; Buyer} {
init_comp{
plans_component:[
(accept)[(seller_mode)(mode), (check_channel)(channel)]
[(less_stock)(NIL), (ack)(NIL), (send)(ack,NIL,NIL,NIL)
(ack)[(seller_mode)(mode), (check_channel)(channel)]
[(less_stock)(NIL), (remove_belief)(contract,NIL,NIL,NIL),
341
(refuse)[(seller_mode)(mode), (check_channel)(channel)]
];
};
}
class_agent {Reactive}{Broker}
role_playing{Broker} {
init_comp{
rules:[
(register)(register),
(finished)(finished),
(search)(query)];
};
}
init_ENV [];
init_ETH [];
create_agent(Buyer,buyer1); {
beliefs_component:[
(need)(NIL,[apple],NIL,NIL),
(buy_step)(NIL,NIL,NIL,0.1),
(buy_start)(NIL,NIL,NIL,0.5),
(agent_name)(buyer1,NIL,NIL,NIL),
(agent_type)(buyer,NIL,NIL,NIL),
(mode)(buy,NIL,NIL,NIL),
(broker)(broker1,NIL,NIL,NIL),
(apple)(buy,[],10,5.2),
(pears)(buy,[],10,4.1),
(channel)(broker1),
(search)(buyer1,[apple,pears], NIL,NIL)];
intentions_component:[
(send)(search)
];
}
create_agent(Seller,seller1); {
beliefs_component:[
(stock)(NIL,[apple],NIL,NIL),
(sell_step)(NIL,NIL,NIL,0.9),
(sell_start)(NIL,NIL,NIL,1.5),
(agent_name)(seller1,NIL,NIL,NIL),
(agent_type)(seller,NIL,NIL,NIL),
(mode)(sell,NIL,NIL,NIL),
(apple)(sell,[],20,5.0),
(channel)(broker1),
(register)(seller1,[apple],NIL,NIL)];
342
(send)(register,NIL,NIL,NIL)
];
}
create_agent(Trader ,trader1); {
beliefs_component:[
(stock)(NIL,[pears],NIL,NIL),
(need)(NIL,[apple],NIL,NIL),
(sell_step)(NIL,NIL,NIL,0.9),
(sell_start)(NIL,NIL,NIL,1.3),
(buy_step)(NIL,NIL,NIL,0.1),
(buy_start)(NIL,NIL,NIL,0.6),
(agent_name)(trader1,NIL,NIL,NIL),
(agent_type)(trader,NIL,NIL,NIL),
(mode)(buy,NIL,NIL,NIL),
(apple)(buy,[],10,5.1),
(pears)(sell,[],10,4.0),
(channel)(broker1),
(search)(buyer1,[apple], NIL,NIL),
(register)(seller1,[pears],NIL,NIL)];
(send)register;
(send)search ];
}
create_agent(Broker ,broker1); {
facts[]
}
}
C.2
CaseLP-MASadl and its relations with UML
C.2.1 Formal syntax of CaseLP-MASadl
MasDescription ::= AgentRoleDefList AgentClassDefList AgentInstancesDef
LinksDefs
AgentRoleDefList ::= AgentRoleDef ü AgentRoleDef AgentRoleDefList
AgentRoleDef ::= role RoleName “ ú ” RoleDef “ û ”
RoleName ::= alphanumeric-string
RoleDef ::= [RoleRelations] RequiredAndProvidedServices
RoleRelations ::= [ contains RoleNameList ] ü [ refine RoleName ]
RoleNameList ::= RoleName ü RoleName RoleNameList
AgentClassDefList ::= AgentClassDef ü AgentClassDef AgentClassDefList
AgentClassDef ::= agentclass AgentClassName “ ú ” ClassDef “ û ”
343
Figure C.2: The UML class for the abstract BDI architecture.
344
Figure C.3: The statechart diagram of the abstract BDI architecture.
345
ClassDef ::= kind “:” Kind “;” roles “:” RoleNameList “;”
architecture “:” Architecture “;” interpreters “:” InterpretersList
Kind ::= logical ü interface ü facilitator ü manager ü . . .
Architecture ::= reactive ü proactive ü bdi ü . . .
InterpretersList ::= Interpreters ü Interpreters InterpretersList
Interpreters ::= alphanumeric-string
RequiredAndProvidedServices ::= [ requires ServicesList“;” ]
[ provides ServicesList“;” ] [ imports ServicesList“;” ]
[ exports ServicesList“;” ]
ServicesList ::= Service ü Service ServicesList
Service ::= alphanumeric-string
AgentInstancesDef ::= agentInstances AgentInstDefList
AgentInstDefList ::= AgentInstDef ü AgentInstDef AgentInstDefList
AgentInstDef ::= NumOfInstances AgentName AgentClassName
NumOfInstances ::= natural-number
LinksDef ::= link LinkList
LinkList ::= Link ü Link LinkList
Link ::= OneToOneLink ü OneToManyLink ü ManyToOneLink
OneToOneLink ::= LinkEnd “ kÿ ” LinkEnd
OneToManyLink ::= LinkEndList “ kÿ ” LinkEnd
ManyToOneLink ::= LinkEnd “ kÿ ” LinkEndList
LinkList ::= LinkEnd ü LinkEnd LinkEndList
LinkEnd ::= [AgentClass[“.”ID]“.”]RoleName“.”Service
C.2.2 The use of CaseLP-MASadl in CaseLP
Below we show the CaseLP-MASadl specification of the distributed marketplace static architecture (text below) and its corresponding role diagram (Figure 6.6).
role Seller {
requires buy_Merchandise,
register_Sellers;
provides sell_Merchandise;
}
role Broker {
provides register_Sellers,
locate_Sellers;
}
role Buyer {
requires locate_Sellers,
sell_Merchandise;
provides buy_Merchandize;
}
agentclass Seller {
roles: Seller;
agentclass Buyer {
roles Buyer;
346
architecture: BDI;
}
agentclass Trader {
roles: Buyer, Seller;
architecture: BDI;
}
architecture: BDI;
}
agentclass Broker {
roles: Broker;
architecture: reactive;
}
agentInstance{
1 seller Seller
1 buyer Buyer
1 broker Broker
}
link{
Seller.buy_Merchandise <- Buyer.buy_Merchandise;
Seller.register_Sellers <- Broker.register_Sellers;
Buyer.locate_Sellers
Buyer.sell_Merchandise
}
C.3
<- Broker.locate_Sellers;
<- Seller.sell_Merchandise;
CaseLP-Protocol and its relations with UML
C.3.1 Formal syntax of CaseLP-Protocol
CONV DEF::= CONVERSATION LIST RELATIONS
CONVERSATION LIST ::= CONVERSATION ü
CONVERSATION CONVERSATION LIST
CONVERSATION ::= Conversation CONV NAME
“(” ROLE.SERVICE “ _ÿ ” ROLE.SERVICE “)” [ PARAMETERS ]
MESSAGE LIST
CONV NAME ::= alphanumeric string
ROLE ::= alphanumeric string
PARAMETERS ::= Parameters “(” PARAM LIST “)”
PARAM LIST ::= PARAM NAME ü PARAM NAME “,” PARAM LIST
PARAM NAME ::= alphanumeric string
MESSAGE LIST ::= MESSAGE ü MESSAGE MESSAGE LIST
MESSAGE ::= ORD“.” [ LIFEPATH ] “)”
Message“:” ROLE “ jÿ ” ROLE
MESSAGE FORM [ CONNECTED MESSAGE LIST ] ü
CAPACITY
347
BUYER
TRADER
SELLER
*
buy_Merchandise
BUYER
SELLER
*
locate_Sellers
register_Sellers
sell_Merchandise
buy_Merchandise
*
buy_Merchandise
sell_Merchandise
sell_Merchandise
*
*
locate_Sellers
*
register_Sellers
BROKER
1
1
register_Sellers
BROKER
locate_Sellers
Figure C.4: The UML role diagram corresponding to the CaseLP-MASadl specification.
348
CONNECTED MESSAGE LIST ::= CONNECTED MESSAGE ü
CONNECTED MESSAGE CONNECTED MESSAGE LIST
CONNECTED MESSAGE ::= CONNECTIVE MESSAGE FORM
ORD ::= NAT // in ascending order for each lifepath
LIFEPATH ::= alphanumeric string // created by a switch
MESSAGE FORM ::= [ “[” GUARD CONDITION “]” ]
Performative “:” PERF; Content “:” CONT“;”
[Goto (LABEL NAME)]
GUARD CONDITION ::= BOOLEAN EXPRESSION.
CONNECTIVE ::= AND ü OR ü XOR
CAPACITY ::= Label LABEL NAME ü
Switch CONNECTIVE (CON LIFE LIST)
CON LIFE LIST ::= CON LIFE ü CON LIFE “,” CON LIFE LIST
CON LIFE ::= CONTENT “ kÿ ” LIFEPATH
RELATIONS ::= Relation RELATION LIST
RELATION LIST ::= RELATION ü RELATION RELATION LIST
RELATION ::= REL NAME“:” CONV NAME REL TYPE
CONV NAME“;”
REL NAME ::= alphanumeric string
REL TYPE ::= sc ORD“.” [ LIFEPATH ] ü sc? ORD“.” [ LIFEPATH ]
C.3.2 The use of protocols in CaseLP
In this section we show the CaseLP-Protocol specification of the protocols adopted in the distributed marketplace application (text below) and its corresponding protocol diagram (Figure
C.5).
Conversation register (Seller.register_Sellers <-- Broker.register_Sellers)
1) message: Seller --> Broker
performative: tell
content: register(Name,Product_1..Product_n)
Conversation update (Seller.register_Sellers <-- Broker.register_Sellers)
1) message: Seller --> Broker
performative: tell
content: finished(Name,Product)
Conversation locate (Buyer.locate_Sellers <-- Broker.locate_Sellers)
1) message: Buyer --> Broker
performative: ask
content: locate(Name,Product_1...Product_n)
349
2) message: Broker --> Buyer
performative: reply
content: located(Product,Name_1..Name_n)
Conversation acquire (Buyer.buy_Merchandise <-- Seller.buy_Merchandise)
label(start)
1) message: Buyer --> Seller
performative: propose
content: BuyerName, Product, Qty, Price
label(seller_reply)
2) message: Seller --> Buyer
performative: busy
content: SellerName;
goto(start)
XOR
message: Seller --> Buyer
performative: accept
XOR
performative: refuse
XOR
content: SellerName, Product, Qty, Price);
Switch(propose -> 3.a) (accept, refuse -> 3.b)
3.a) message: Buyer --> Seller
performative: accept
content: BuyerName;
goto(end)
XOR
message: Buyer --> Seller
performative: refuse
content: BuyerName;
goto(end)
XOR
message: Buyer --> Seller
content: BuyerName, Product, Qty, Price;
goto(seller_reply)
3.b) message: Buyer --> Seller
performative: acknowledge
content: BuyerName
label(end)
4) message: Seller --> Buyer
performative: acknowledge
content: SellerName
350
Seller
Buyer
contractProposal
accept
refuse
contractProposal
acknowledge
accept
refuse
contractProposal
acknowledge
Figure C.5: The UML protocol diagram corresponding to the specification.
351
C.4
CaseLP-Ontology and its relations with UML
C.4.1 Formal syntax of CaseLP-Ontology
ONTOLOGY ::= ontology ONT NAME “ ú ” CONCEPT LIST“ û ”
CONCEPT LIST ::= CONCEPT ü CONCEPT CONCEPT LIST
CONCEPT ::= CON NAME CON TYPE RELATIONS
“ ú ” ATTRIBUTE LIST “ û ”
RELATIONS ::= [contains “ ú ” CON NAME LIST “ û ” ] ü
[ refine: CON NAME ]
CON NAME LIST ::= CON NAME ü CON NAME CON NAME LIST
CON NAME ::= alphanumeric-string.
CON TYPE ::= abstract ü effective
ATTRIBUTE LIST ::= ATTRIBUTE ü ATTRIBUTE ATTRIBUTE LIST
ATTRIBUTE ::= NAME : TYPE [“[”CONSTRAINTS“]”];
NAME ::= alphanumeric-string
TYPE ::= string ü integer ü real ü boolean ü CON NAME
CONSTRAINTS ::= BEXP
BEXP ::= BEXP CONNECTIVE BEXP ü not BEXP ü VALUE ü
VALUE ORDER VALUE ü true ü false
ORDER ::= “ þ ” ü “ ÿ ” ü “=”
CONNECTIVE ::= and ü or ü xor
VALUE ::= PRIMITIVE VALUE ü CON NAME“.”NAME
PRIMITIVE VALUE ::= STRING ü INTEGER ü REAL
C.4.2 The use of ontologies in CaseLP
In this section we show the CaseLP-Ontology specification of concepts belonging to the distributed marketplace application (text below) and its corresponding class diagram (Figure C.6).
ontology marketplace{
merchandise{
name:string;
cost:int [cost>0];
quantity:int [quantity>0 or quantity=0];
}
Contract{
proposer : string [Contract.proposer = AgentName];
product : Merchandise;
}
352
Figure C.6: The UML class diagram corresponding to the specification.
ContractEnd{
reason: string [reason = "accept" or reason = "refuse" or
reason = "acknowledge" or reason = "busy"]
contractName : string;
}
BrokerInfo{
infoType:string [infoType = "subscribe" or infoType = "query" or
infoType = "answer" or infoType = "unsubscribe"];
data: list(string);
}
}
353
C.5
AgentRules
C.5.1 Formal syntax of AgentRules
InitialState ::= nil ü BeliefsList
BeliefsList ::= Belief ü Belief; BeliefsList
Program ::= program InitialState ReactiveRulesList ProactiveRulesList endprogram
ReactiveRulesList ::= nil ü ReactiveRule ü ReactiveRule; ReactiveRulesList
ReactiveRule ::= on message Msg check Condition do ActionsList
ProactiveRulesList ::= nil ü ProactiveRule ü ProactiveRule; ProactiveRulesList
Msg ::= Performative ú content: Content; sender: Sender; receiver:Receiver; û
Condition ::= StateCondition and AuxiliaryCondition
StateCondition ::= true ü Goal
AuxiliaryCondition ::= true ü Goal
Goal ::= A ü A and Goal ü A or Goal
ProactiveRule ::= check Condition do ActionsList
Action ::= assert state(Belief) ü retract state(Belief) ü
send(Msg, Receiver)
354