Quality Assurance in Agent-Based Systems

Quality Assurance in Agent-Based Systems
Current State and Open Problems
Preprint Nr. 4, 2002
Cornelius Wille, Reiner R. Dumke, Stanimir Stojanov*)
Otto-von-Guericke-Universität Magdeburg, , Postfach 4120,
D-39016 Magdeburg, Germany, Tel.: +49-391-67-18664, Fax: +49-391-67-12810,
Email: {dumke, wille}@ivs.cs.uni-magdeburg.de
*)
University of Plovdiv, Dept. of Mathematics and Informatics,
4000 Plovdiv, 236 Bulgaria blv., Bulgaria
Email: [email protected]
Contents
1
Introduction ............................................................................................................. 1
1.1
Software Quality and Agent-based Systems ................................................................ 1
1.2
Foundations on Agent-based Systems.......................................................................... 5
1.2.1 Software Agents ........................................................................................................... 5
1.2.2 Multi-Agent Systems (MAS) ....................................................................................... 8
1.2.3 Agent Communication ................................................................................................. 9
1.2.4 Agent Interaction and Co-operation............................................................................. 17
1.2.5 Agent Minds, Intentions, Motivations and Negotiations
20
1.2.6 Agent Mobility ............................................................................................................. 26
1.2.7 Agent Communities and Organisations........................................................................ 27
1.2.8 MAS Architectures....................................................................................................... 30
1.3
The MAS Development Process .................................................................................. 41
1.3.1 MAS Development Methodologies.............................................................................. 41
1.3.2 MAS Specification ....................................................................................................... 52
1.3.3 MAS Design and Implementation................................................................................ 56
2
2.1
2.2
2.3
2.4
Evaluation und Measurement Aspects of Agent-based Systems .......... 60
3
Agent Types ............................................................................................................. 68
4
Acronyms.................................................................................................................. 70
5
MAS Web Links..................................................................................................... 73
6
References ................................................................................................................ 75
Empirical Aspects of Agent-based Systems................................................................. 60
Experiences of Agent-based System Development...................................................... 62
Related Work in Measurement of Software Agent and Agent-based Systems ............ 63
Open Problems and Intentions of Quality Assurance in MAS..................................... 66
1
1 INTRODUCTION
1.1 Software Quality and Agent-based Systems
In introducing new techniques or technologies, the main aspects of investigation are addressed
to their functionality in the new application area and are based on the experimentation with
new paradigms (tools, languages, middleware and architectures). Software Agents provide
new means to implement flexible and intelligent communication systems with an autonomous
aspect of sensoring, understanding, negotiation, decision, and action. But, like in the objectoriented software development, that will be understood just now with help of more and more
quantified experience in the area of software agents we can only establish some special
remarks about complexity or efficiency (“Thus it is already a good bet that the software
engineering of tomorrow will be ‘agent-oriented’, just as that of today is beginning to be
‘object-oriented’.” [Ferber 99, p. 8]). The conversion shift from an object to an agent is
shown in a simplified manner in Figure 1.
Agent
memories, knowledge,
skill, character
Object/Class
memories
features,
adaptation,
negotiation, learning,
action, co-operation
features
Figure 1: Main characteristics of an object/class and an agent
Wooldridge et al. [Wooldridge 01] describe the difference between objects and agents in the
following manner (see also [Brenner 98] and [Murch 00])
•
•
•
agents embody stronger notion of autonomy than objects, and in particular, they decide for
themselves whether or not to perform an action or request from another agent;
agents are capable of flexible (reactive, pro-active, social) behavior, and the standard
object model has nothing to say about such types of behavior;
a multi-agent system is inherently multi-threaded, in that each agent is assumed to have at
least one thread of control.
[Huhns 01] characterises the difference of essential aspects of the programming features and
paradigms as following.
Concept
Abstraction
Building Blocks
Computation Model
Design Paradigm
Architecture
Models of Behaviour
Terminology
Object language
Class
Object
Method/Message
Interaction Patterns
Inheritance and Polymorphism
Designing and Using
Engineer
Multiagent language
Society
Agent
Perceive/Reason/Act
Co-operative Interaction
Managers, Assistants, and Peers
Enabling and Enacting
Activate
Table 1: Features of programming languages and paradigms
2
The mapping between object-oriented programming (OOP) and agent-oriented programming
(AOP) is given in [Lind 01] as described in the following table.
Characteristic
Structural
Elements
Relations
OOP
abstract class
class
class variables
methods
collaboration (uses)
composition (has)
inheritance (is)
instantiation
AOP
generic role
domain specific role
knowledge, belief
capabilities
negotiation
holonic agents
role multiplicity
domain-specific role + individual
knowledge
service matchmaking
polymorphism
Table 2: Mapping OOP to AOP
Obviously, we can establish a more complex structure or architecture of such agent-based
systems. Moreover:
•
•
•
•
How can we use some experience in software measurement and evaluation of the
object-oriented software development?
Which kinds and contents are the new measurement aspects for agent-based
systems?
Which characteristics of software agents are measurable and which of them
should be measured necessarily?
How can we install measurement aspects in agent-based systems to control the
efficiency of software agents?
A lot of questions and problems exist in the development of agent-based systems and there are
not enough satisfying answers now. [Jennings 98, p. 19] writes: “There is little in the way of
production-quality software support for building agent applications, and still less general
understanding of the issues that need to be addressed when building such systems. Worse,
most of today’s agent systems are built from scratch, using bespoke tools and techniques,
which cannot easily be applied to other types of systems. This is particularly worrying
because a lot of infrastructure is required before the main components of an agent system can
be built. At the moment, most developers rebuild this infrastructure from scratch in every new
case; this process is clearly not sustainable.”
Software measurement and evaluation as a key technology for software quality assurance
should consider the following components and aspects of agent-based systems:
•
•
•
The analysis and evaluation of the product characteristics of an agent-based
system such as architecture, design artefacts, code, documentation and run time
aspects,
The investigation of the agent-based system development process in the different
parts of life cycle characteristics and management aspects,
The consideration of the resources which are necessary to develop and maintain
agent-based systems and are divided in personnel, software and hardware
resources.
3
However, the metrics situation in the OOSE area has not changed essentially since the
following study from 1997 [Dumke 97]. The charts below characterise the facilities and the
situation in the OO metrics area. Note, that the charts provide only an approximate overview
about the metrics situation. We use pc for the process metrics, pr for the product metrics, and
rs for the resources metrics.
System Model Granularity
Class
#metrics
Component
#metrics
OO System
#metrics
50
50
50
40
40
40
30
30
30
20
20
20
10
10
10
pc
pr
rs
pc
pr
rs
pc
pr
rs
Life Cycle Phase Related
OOA
#metrics
OOD
#metrics
OOP
#metrics
50
50
50
40
40
40
30
30
30
20
20
20
10
10
10
pc
pr
rs
pc
pr
rs
pc
pr
rs
Measurement Area Related
(Model-based) Metrics
(Empirical-based) Measures
#metrics
#metrics
50
50
40
40
30
30
20
20
10
10
pc
pr
rs
pc
pr
rs
Figure 2: Situation of OO software metrics
Currently, software agents are a new technique without detailed quantified knowledge about
the technology. This paper will give first ideas of possible aspects in software quality
assurance of agent-based systems.
4
1.2 Foundations on Agent-based Systems
In the field of software agents, we have to consider a sharp increase of knowledge and
applications. Interesting areas of agent applications are (see also [Jennings 98])
•
•
•
•
solving new types of problems such as open systems, complex system and
ubiquity,
improving the efficiency of software development through distribution of data,
control, expertise or resources,
industrial applications like process control, manufacturing, air traffic control,
information management, electronic commerce, and health care,
entertainment on the area of distributed games, interactive theatre and cinema.
We try to give an overview of the area of software agents that is required to explain and to
define the software quality assurance aspects.
1.2.1 Software Agents
We are agree with the definition of software agents by [Maes 94]: “Autonomous agents are
computational systems that inhabit some complex dynamic environment, sense and act
autonomously in this environment, and by doing so realise a set of goals or tasks for which
they are designed.” This definition considers the important aspects of software agents and
their environment which is necessary for any (autonomous) action. The general types of these
interactions with the environment are shown in the Figure 3.
External
Environment
Factors
Outgoing messages
(to human, agent or
other controller)
Agent
Inference Engine
Incoming
messages from
other agents
Internal World State
Actions on the
environment
Figure 3: Agents interactions with the environment [Hayzelden 99, p. 10]
A general taxonomy of agents is given in the Figure 4 which can be found in most of the
books about software agents.
Autonomous agents
Biological agents
Robotic agents
Computational agents
Software agents
Task specific agents
Entertainment agents
Figure 4: Taxonomy of autonomous agents
5
Artificial life agents
Viruses
A software agent can have certain aspects of the behaviour as described in the Table 3.
Property
Social ability
Autonomy
Reactivity
Adaptability
Agent
Granularity
Degrees
Learning
Pro-activity
Description
A software agent is able to use communication as a basis to signal interest
or information to either homogeneous or heterogeneous agents that
constitute a part of its environment. The agent may work toward a single
global goal or separate individual goals.
Agents should operate without the intervention of external elements (other
agents or humans). They have some kind of control over their actions and
internal states.
Agents perceive their environment and respond in a timely fashion to
changes that may occur.
Agents are characterized by their flexibility, adaptation, and facility to set
up their own goals based on their implicit purpose (interests). One of the
major characteristics of agents is their ability to acquire and process
information about the situation, both spatially and temporally.
Agents may have degrees of complexity; Most simple agents are
characterized by the lack of intelligence regarding their behavior. These
agents are called reactive. More complex agents are called cognitive or
intelligent agents. They are characterized by their ability to know their
environment, to act on themselves and on the environment; their observed
behavior is a consequence of their perception, knowledge, and interactions.
Either the agency itself may perform some learning ability (as a society) or
each individual agent may be embedded with a learning algorithm (e.g. a
Neural Network or their re-enforcement algorithm). Learning often allows
the agent to alter its future action sequences and behavior such that future
mistakes can be alleviated. Learning is often a factor that provides an
agent's ability to demonstrate adaptive behavior.
Agents should exhibit goal directed behavior such that their performed
actions cause beneficial changes to the environment. This capability often
requires the agent to anticipate future situations (e.g. using prediction)
rather than just simply responding to changes within their environment.
Table 3: Properties of software agents by [Hayzelden 99, p.5/6]
On the other hand, we can combine the agents characteristics to define special kinds of
software agents and agent communities (see Figure 5 adapted from [Darbyshire 00]).
Autonomy
pro-active
reactive
passive
preference
reasoning
learning
Intelligence
with humans
with agents
Social ability
Figure 5: 3D model of agent characteristics
6
In order to define all aspects of the behaviour of an agent based on the 3D characteristics, we
will cite the definition by [Ferber 99, p. 9] of general (software) agents:
“An agent is a physical or virtual entity, which is capable of acting in an
environment, which can communicate directly with other agents, which is
driven by a set of tendencies (in the form of individual objectives or of a
satisfaction/survival function which it tries to optimise), which possesses
resources of its own, which is capable of perceiving its environment (but to
a limited extent), which has only a partial representation of this
environment (and perhaps none at all), which possesses skills and can offer
services, which may be able to reproduce itself, whose behaviour tends
towards satisfying its objectives, taking account of the resources and skills
available to it and depending on its perception, its representations and the
communications it receives.”
In the most complex case we can establish the following components as a static architecture
description of an agent as shown in the Figure 6. This software agent could have all the
characteristics and facilities which are described in Table 3 above.
Influences
Intentions/
Collaboration
Administration/
Co-ordination
Inputs/
Perceptions
Outputs/
Reactions
Tasks/
Goals
Action/
Co-operation
Negotiation/
Communication
Knowledge/
Experience
Reflections
Figure 6: Components of a general software agent
Hence, software quality assurance of software agents includes aspects such as the quality of
the capability of acting in an environment, the level of communication with other agents, the
quantities of the driven aspects by a set of tendencies, the characteristics of possessed
resources, the kind of capability of perceiving its environment, the characteristics of the
agent-based partial representation of this environment, the quality of the possessed skills and
offered services, the level of the ability to reproduce itself, the kind of the behaviour towards
satisfying its objectives, taking account of the resources.
In the next section we will describe the general characteristics of agent-based systems in a
short form. Afterwards, we describe the detailled facilities of software agents considering the
different existing system and approaches.
7
1.2.2 Multi-Agent Systems (MAS)
Software agents can build communities in a special domain area. Such systems are defined as
multi-agent systems and we will cite [Ferber 99, p. 11] again:
“The term 'multi-agent systems' (or MAS) is applied to a system comprising
the following elements:
• An environment, E, that is, a space which generally has a volume.
• A set of objects, O. These objects are situated, that is to say, it is
possible at a given moment to associate any object with a position in
E. These objects are passive, that is, they can be perceived, created,
destroyed and modified by the agents.
• An assembly of agents, A, which are specific objects (A ⊆ O),
representing the active entities of the system.
• An assembly of relations, R, which link objects (and thus agents) to
each other.
• An assembly of operations, Op, making it possible for the agents of A
to perceive, produce, consume, transform and manipulate objects
from O.
• Operators with the task of representing the application of these
operations and the reaction of the world to this attempt at
modifications, which we shall call the laws of the universe.”
In the manner of the software agent representation, we describe the (static) architecture of a
MAS in a simplified kind of visualisation in Figure 7. Software agents can handle in different
cities together with other agents and can operate or work with objects.
Influences
Agenta
City A
Agentb
User
Customer
Results
Object2
Object1
City B
City C
Agentc
Reflections
Environment (Network)
Figure 7: Components of a multi-agent system
8
Benefits
Hence, software quality assurance of MAS includes the aspects such as reliability,
availability and usability of the environment, the appropriateness and size of the objects, the
structure and efficiency of the agents communities, the performance of the agents operations,
and the stability of the user interaction with the MAS.
1.2.3 Agent Communication
In order to describe the kinds of agent communication, we can establish the general situation
in shifting from the interactions between objects (from the object-oriented software
development point of view) and between agents which is intimated in Figure 8.
Agent1
Object1
Agent2
Object2
Messages
Interaction based
on a communication language
Figure 8: Kinds of communication between objects and between agents
Intentions of communication are information and conversation and can be expressed by the
communication medium based on messages, communication languages and conversation
languages.
Some kinds of an agent communication language (ACL) [Singh 98] are the main aspect in
the interaction between software agents. Examples of communication languages or
technologies are described in following.
¾ ACML: The Agent Communication Markup Language was defined by Grosof et
al. [Grosof 00] and is based of the FIPA ACL and the XML. This ACML is used
in order to combine the ACL standards with the business rules and existing XML
related business process descriptions. The following DTD fragment of ACML
gives a short impression of this approach.
<?xml version=”pre-1.0” encoding=”US-ASCII”?>
<!ENTITY % messagetp “accept-proposal | agree |
cancel |
cfp | confirm | disconfirm | failure | inform |
inform-if | inform-ref | not-understood |
propose |
query-if | query-ref| refuse | reject-proposal |
request | request-when | request-whenever |
subscribe”>
<!ELEMENT message (messagetype, messageparameter* )>
<!ELEMENT messagetype (%messagetp;)>
<!ELEMENT messageparameter (sender | receiver |
content |
reply-with | reply-by | in-reply-to | envelop |
9
language | ontology | protocol | conversationid)>
<!ELEMENT sender (agentname)>
.
.
.
¾ Agent-0: This is the first member of the Agent Oriented Programming (AOP)
family and executes the loop comprising two steps [Papadopoulos 01]:
-
During the first step incoming messages are gathered and the mental state of
the agent is updated appropriately,
-
During the second step commitments (e. g. guarantees that the agent will
carry out an action at a certain time) are executed using capabilities (actions
the agent is able to perform).
Another approach is Agent-K which combines the message passing functionality
of Agent-0 with the format of KQML.
¾ COOL: The CO-Ordination Language was developed by Barbuceanu et al.
[Barbuceanu 00] in order to consolidate of conversation concepts. An example of
this language which describes a customer conversation is given in the following.
(def-conversation-plan ‘customer-conversation’
:content-language ‘list
:speech-act-language ‘kqml
:initiate-state ‘start
:final-states ‘(rejected failed satisfied)
:control ‘interactive-choice-control-ka
:rules ‘(start cc1)
(proposed cc-13 cc-2)
(working cc-5 cc-4 cc-3)
(counterp cc-9 cc-8 cc-7 cc-6)
(asked cc-10)
(accepted cc-12 cc-11))
¾ FLBC: This Formal Language for Business Communication developed by
[Moore 00] is based on the XML (see also [Glushko 99]) and has deep
foundations in speech act theory. The following example of a FLBC message
gives a short characterisation of this language.
<?xml
version0”1.0”
encoding=”UTF-8”
standalone=”no”?>
<!DOCTYPE flbcMsg SYSTEM
“http://wwwpersonal.umich.edu/~samoore/research/
flbcMsg.dtd”>
<flbcMsg msgID=”M”>
<simpleAct speaker=”A” hearer=”B”>
<illocAct force=”F” vocab=”N” language=”L”>
X
</illocAct>
10
</simpleAct>
<context>
<resources>
<actors>
<person id=”A”/> <person id=”B”/>
</actors>
</resources>
<respondingTo message=”V”/>
</context>
</flbcMsg>
¾ GroupLog: GroupLog is an agent co-ordination language (see [Papadopoulos 01])
and is based on an extended Horn Clauses formalism. The agents are process
models which receive messages and react to them by invoking appropriate
methods. The following example of a group communication shows the syntactic
elements of GroupLog.
group meet_schedule {
context().
interface(begin).
meet_schedule(Id) : begin :members(meet_schedule(Id), [H,I]),
rd(meet_schedule(Id), meet(MeetId)),
H
<<
begin(I,MeetId)
||
I
begin(H,MeetId)
| meet_schedule(Id).
meet_schedule(Id) : new | meet_schedule(Id).
}
<<
H and I are the agents which communicate (‘<<’) in the MeetId group.
¾ JADL: The JIAC Agent Description Language has been designed in order to
support the Java Intelligent Agent Componentware (JIAC) for implementing
MAS for telematic and telecommunication applications. The background of JADL
consists of a toolkit that includes an agent development environment, an agent
debugger, a marketplace monitor, an agent navigator, and a remote
administration tool (see [Liu 01]).
¾ Java: Of course, Java is not really an agent communication language. But their
Web facilities (the classes URL, Thread, Server, Datagram etc.) allow us to
implement agent-like systems which include a communication part, e. g.
-
Generic Mobil Agents [Wong 99]) as a set of Java classes for constructing
heterogeneous agent-based systems,
-
Jada [Rossi 01] as a co-ordination language for Java that can be used to coordinate parallel/distributed components,
-
JATLite [Jeon 00] as an infrastructure for agent implementation based on a
message routing concept,
11
-
JavaSpace [Freeman 99] for building agent-like communities in predefined
environments (spaces),
-
Jini [Arnold 99] as a collection of interacting Java programs in order to
keep reliability and simplicity to the construction of networked devices and
services,
-
Software Aglets [Lange 98] as an IBM product for implementing mobile
agent systems.
¾ KIF: The Knowledge Interchange Format [KIF 98] is a language designed for use
in the interchange of knowledge among disparate computer systems (created by
different programmers, at different times, in different languages, and so forth).
The syntax of KIF can be described in three layers: the basic characters, the
combination of these characters as lexemes, and the combined lexemes as
expressions. In KIF can be used functions and relations about numbers,
characters, strings, and lists. The following KIF expression defines the characters
and gives a little impression of the language syntax.
(defrelation character (?x) :=
(exists ((?n natural-number))
(and (>= ?n 0) (< ?n 128) (= (code-char ?n)
?x))))
¾ KLAIM: The Kernel Language for Agent Interaction and Mobility (see
[Papadopoulos 01] is a Linda variant. A KLAIM program is a net, comprising a
set of nodes. Each node in the net describes an allocated environment that maps
symbolic locality references as a set of running processes to actual tuple spaces.
The following KLAIM code example gives us an impression of this kind of ACL:
def Client = out(Q)@1 ; nil
def Q = in(‘foo’,!X)@self ; out(‘foo’,X+1)@self ; nil
def Server = in(!P)@self ; eval(P)@self ; nil
KLAVA (see [Rossi 01]) is an implementation of KLAIM in Java. [Nicola 00]
discusses the semantics of KLAIM.
¾ KQML: The Knowledge Query and Manipulation Language [Labrou 97] offers a
variety of message types (performatives) that express an attitude regarding the
content of the exchange between agents. Performatives can also assist agents in
finding other agents that can process their requests. In order to obtain a general
impression of this language, we cite from [Labrou 97] the following simple
KQML example: An agent A sends the following performatives to agent B. The
:in-reply-to suggests that the ask-all follows a relevant advertise
message
(ask-all
:sender
:receiver
:in-reply-to
:reply-with
:language
12
A
B
id0
id1
Prolog
:ontology
:content
foo
‘‘bar(X,Y)’’)
and agent B replies with the following KQML message
(tell
:sender
:receiver
:in-reply-to
:reply-with
:language
:ontology
:content
B
A
id1
id2
Prolog
foo
‘‘[bar(a,b), bar(c,d)]’’)
The :sender wish to know if the :content is true of the receiver. True of
the :receiver is taken to mean that either the <expression> matches a
sentence in the receivers knowledge base or is probable by the :receiver.
¾ LGI: The Law-Governed Interaction was developed at the Rutgers University
(USA) and is a co-ordination mechanism that allows to build an open group of
distributed active entities (agents, processes) (see [Bryce 01]). The agents interact
with each other , with confidence that an explicitly specified policy (the law of the
group) is strictly observed by each of its members. The three types of
communication in LGI are between the agent and the controller and between
controllers.
¾ Little-JIL: The Little-JIL is a visual language of agent co-ordination (see
[Papadopoulos 01]). This language has been designed to address in particular the
problem of knowledge discovery in databases which is helpful in Web
environments in order to regard aspects such as traffic analysis, fraud detection
etc. In Little-JIL an agent is a special resource associated with a step as a
representation of a process.
¾ LuCe: The Logic Tuple Centres (see [Rossi 01]) is a co-ordination model, system
and technology for the construction of multi-agent systems involving autonomous,
pro-active, possibly heterogeneous agents. LuCe is logic-based and exploits
Prolog both as the inter-agent communication language and as the co-ordination
language.
¾ MAI2L: The Multi-agent Language [Haugeneder 98] consists of four aspects such
as characters (char) representing the agent action or plan, preconditions (pre)
which contain operations for knowledge access and for setting conditions on that
knowledge, procedures (proc) for composing flow structures, and effects (eff)
which characterise the successful execution of the procedure. The following
MAI2L example only shows the syntactical meaning of this language.
plan(cnet(TaskType,BestBid),
chars = Mgr, Bdrs,
proc = (Mgr:cn_make_proposal(TaskType,Specs) &
Bdrs:CallForBids = Mgr:propose(Bdrs,Specs)
&
Mgr(!timeout -> Bids) =
13
Bdrs(refine_bids(Specs,CallForBids\sender,B
ids) &
refine(CallForBids\sender,Bid)) &
Mgr:cn_eval_bids(Bids,BestBid,RestBids,Time
Outs) &
. . .
eff = Mgr(-cc),Bdrs:(-cc)).
¾ MIF: The Market Internet Format was defined in order to support e-commerce
(see [Papadopoulos 01]). In MIF agents share a common language which is a
formalised subset of commerce communication. Typical MIF expression of
interest for e-commerce transactions are the following:
(def car “trade-object”
color (instance “red”))
. . . )
(instance “contract”
data(interval 1/1/2000 1/1/2001)
buyer(instance “person”
(name “John Brown”)
(address ...) ...)
goods(instance “car”
color(instance “red”) ...)
¾ PLACA: The Planning Communication Agents language (see [Papadopoulos 01])
includes the following syntactic structures:
-
INTEND x: intending to make sentence x true by adding it to the list of
intentions,
ADOPT x: adopting the intention, plan x to the intention, and plan list,
DROP x: dropping the intention, and plan x,
the set CAN-DO x, CAN-ACHIEVE x, PLAN-DO x, PLANACHIEVE x, and PLAN-NOT-DO x which are truth statements used in
mental conditions.
¾ sACL: The small Agent Communication Language is defined by Pitt et al. [Pitt
00] in order to describe the appropriateness of a general semantic framework for
the interpretation of ACLs. sACL is based on speech acts and is defined as a 3tuple 〈Perf, Prot, reply 〉 given by specifying
Perf = {inform, query, command,
request,
agree, cancel, fail, null }
acknowledge,
end,
Prot = { yesno_query, confirmation, commitment, datasync, no_protocol } .
The protocols can be used by one agent to communicate with another in order to:
-
query another agent about the value of some proposition,
inform an agent of some proposition and receive
acknowledgement,
14
an
-
synchronise data with another agent about the value of some
proposition,
ask an agent if it will undertake some action.
¾ Telescript: Telescript was the first system to bring network agents into the public
conscience. The first version of Telescript was developed before the Internet and
networks has change dramatically. In order to see some facilities in Telescript we
will chose an example from [Cockayne 97]. Based on the class definitions for
Telescript agents, we can general define a meeting as follows
meeting: sponsored op (
agent: protected Telename;
_class: protected Classname;
petition: protected Petition) Object|Nil
throws MeetingDenied =
{ throw MeetingDenied();
nil
}
The operation op is special because the engine itself requests it whenever a
meeting is requested of an agent. The operation may throw an exception. Indeed
the shopping agent always throws a member of the predefined MeetingDenied
class.
¾ TRUCE: This script language is a co-ordination language that supports roles,
groups and dynamic agents at collaboration time (see [Papadopoulos 01]). The coordination is defined by a protocol specification. Every instruction in a script has
two components: the action to be executed and a set of collaborators that
participate in carrying out this action. A simple example of a co-ordination
scenario is given in the following.
protocol selling-protocol {
when { $selling=true {
sellers.if {myturn=true} {
set $”current-sellers”=_me;
}
retract {selling-protocol};
facilitator.set {$selling} false;
auction {facilitator, $”current-seller”
{byuers, sellers} };
recover {selling-protocol};
facilitator.proceed {$”current-seller”};
}
}
The facilitator, byuers and sellers are the bound to agent names in
this script.
¾ WARREN-ACL: The ACL of the Carnegy Mellon University MAS system
shortly described in [Petrie 01] is based on the essential KQML characteristics. A
simple example is given in the following.
15
(monitor
:SENDER barney
:RECEIVER news-agent
:LANGUAGE simple-query
:ONTOLOGY news
:REPLY-WITH ibm-query-2
:NOTIFICATION-DEADLINE (30 minutes)
:CONTENT (query news
:CLAUSES
(=
$newsgroups
``dow-jones.indust.earningsprojections´´)
(= subject ``IBM´´)
:OUTPUT :ALL) )
¾ 3APL: 3APL is an acronym of An Abstract Agent Programming Language
[Hendriks 00] and was extended by two pairs as communication primitives: the
pair tell and ask, and the pair req and offer. The first pair uses the
exchange information between agents and the second pair is used to communicate
requests between agents. A simple example which described a meeting planning is
given in following and should given only a general impression of this language.
reply(Host) <- true |
begin
offer(Host,
meet(MeetId,
MeetTime,
MeetLedngth,Attendants);
req(Host, ∃ MeetTime1 • epmeet(MeetId,MeetTime1,
MeetLength,Attendants, MeetTime));
reply(Host)
end
ask(Host, confirm(MeetId,MeetTime))
A semantic part of agent communication involves several messages between two or more
agents and is called as agent conversation. An example of an agent conversation is shown by
[Bush 00] which is based on the MAS architecture standard FIPA (Foundation for Intelligent
Physical Agents, see below) and described in the following figure.
Agent B
request
Agent A:
agree
Agent A:
success
refuse
not-understood
failure
Figure 9: FIPA request conversation protocol
Another modelling of agent conversation is well-known as protocol of Winograd & Flores
described in [Singh 00] (see also [Greaves 00], [Philipps 00] and [Vongkasem 00]). The state
chart of this conversation is given in the following diagram.
16
A: Declare
A:Request
1
B: Promise
B: Assert
2
A: Declare
3
A: Counter
4
B: Renege
7
B: Reject
A: Withdraw
B: Counter
5
A: Withdraw
A: Accept
A: Withdraw
8
6
9
A: Reject
B: Withdraw
Figure 10: Conversation for action between the agents A and B ( : final nodes)
Commitments can be associated with each state in this protocol which means if B makes a
promise to A without any explicit request from A, in terms of commitments, we can see that
the protocol above effectively begins from the state 6.
The publicly shared constraints on the potentially unbounded universe of possible
semantically coherent ACL message sequence which could be used to achieve a goal
characterises the functional role of the conversation policies [Greaves 00].
Hence, software quality assurance of agent communication addresses the aspects such as the
level of the communication, the intensity or frequency of the communication, the useroriented semantics of the ACL, the appropriateness of the ACL, and the guarantee of the
conversion principles.
1.2.4 Agent Interaction and Co-operation
The communication between agents is mostly embedded in common intentions such as
collaboration or co-operation. Kinds of agent interactions for a successful or conflicting
situation are described in [Ferber 99, p. 66] and is shown in the following Table 4 (see also
[Miles 01]).
Category
Indifference
Co-operation
Antagonism
Situation
Independence
Simple
collaboration
Obstruction
Co-ordinated
collaboration
Pure
individual
competition
Pure
collective
competition
Individual conflicts
over resources
Collective conflicts
over resources
Goals
Resources
Skills
compatible
compatible
sufficient
sufficient
sufficient
insufficient
compatible
compatible
insufficient
insufficient
sufficient
insufficient
incompatible
sufficient
sufficient
incompatible
sufficient
insufficient
incompatible
insufficient
sufficient
incompatible
insufficient
insufficient
Table 4: Situations in agents interaction
17
The activities between agents require a general goal to produce some of the expected results.
The main technology to keep this collaboration is called distribute allocation of tasks. Coordination and collaboration needs basic principles of management, such as co-ordination.
The empirical reasons for agents co-ordination are defined by [Hayzelden 99] as: “Firstly to
prevent chaos. In general no agent possesses a global view of the entire agency to which it
belongs, as this is simply not feasible in any community of reasonable complexity.
Consequently, agents only have local views, goals and knowledge which, may interfere with,
rather than support other agent’s actions. Secondly, to meet global constraints: Agents
performing network management may have to respond to certain failures within seconds and
others within hours. Co-ordinating agent behaviour is therefore essential to meet such global
constraints. Agents in a MAS possess different capabilities and expertise: Therefore, agents
need to be co-ordinated in just the same way that different specialists need to co-ordinate
their capabilities. Agent’s actions are frequently interdependent and hence an agent may need
to wait on another agent to complete its task before executing its own. These mutually
dependent activities need to be co-ordinated.”
The four main kinds of co-ordination by [Ferber 99, p. 409] are (see also [Durfee 01]) the coordination by synchronisation, the co-ordination by planning, the co-ordination by reaction,
the co-ordination by regulation. The co-ordination can be context-dependent. [Cabri 00]
classifies two kinds of these dependencies
•
The environment-dependent co-ordination which considers aspects like enforcing
security, handling heterogeneity, and supporting open interactions.
•
The application-dependent co-ordination which is addressed to the facilitating access,
exchanging knowledge or implementing co-ordination protocols.
The co-operation can be the largest context of interaction. In the literature we find the
common definition of co-operation as
Co-operation = collaboration + co-ordination of actions + resolution of conflicts .
Based on this intention we require from an agent co-operation that additional agents are
helpful for increasing the performance level (like as SciAgents [Drashansky 99]) or in
avoiding potential conflicts.
On the other hand, software agent’s behaviour is based on three main types of agent coupling
such as [Ferber 99, p. 113]:
1. Fixed coupling: each component has a role or perhaps several roles from which it does not
shift,
2. Variable coupling: the relationships between agents can evolve, but within a framework of
very specific mechanism,
3. Evolutionary coupling: this kind of coupling characterises a variable organisation
structure where the agents can evolve as a function of performance etc.
The intention of the agents co-operation is to achieve a (user) goal as a description of the
world state. Based upon a set of actions it can perform, the agent can construct a variety of
plans for achieving this goal. The agent commits to the ‘ideal’ plan by adding the actions
called for by the plan to a schedule of events, and executes the plan according to the schedule.
Such co-operation requires some of the following capabilities or components [Haugeneder
98]:
18
•
Agent body: which is needed to be able to change the world through actions,
•
Agent communicator: which is necessary to communicate with other agents,
•
Agent head: this is necessary that the agent have knowledge of how to plan its actions,
achieve its goals.
The agent knowledge can be described in the following figure (see also [Sun 00]).
Planning
Scheduling
Distributed plan
Shared goals
Tasks
Goal activation
Execution
Changes in World State
Figure 11: Process view of several distributed agents
Software agents can be characterised relating to the summarised agent facilities and skills in
an organisation. We can divide agents organisation in non-redundant vs. redundant and
specialised vs. generalist forms.
The following description is dedicated to the action and behaviour of software agents. The
action of agents can be modelled in the following six kinds by [Ferber 99, p. 148]:
1. Action as transformation of a global state: this approach is based on the classical AI
planning theory. The general description of this state-based action can be defined as
σ1 = Exec(op(A, L1 , L2), σ2)
where are A the agent, σ1 and σ2 the different states (old and new) and L1 and L2 the
different agent locations (old and new). The transformation itself was described by stripslike operators which are based on the description of the direction related to the
dimensions.
2. Action as response to influences: An agent is actually making a gesture or influences. The
results of these gestures are obtained by application of the laws of the universe. The latter
is the response of the environment, which acts by combining all the influences it receives
from agents, and then deducing from them a new global state in conformity with its own
particular nature. Action and reaction can be defined generally on the base of the
influences Γ and the states Σ as
Exec: Op × Σ → Γ, especially Exec(op,σ) = γ .
19
3. Action as computing processes: Methods of this kind of action description are finite-state
automata, register automata, petri nets, and other forms of algorithm descriptions.
4. Action as local modification: In local models, action is considered as being a local
modification which is propagated along a net of automata. The cellular automata is a kind
of this description.
5. Action as physical displacement: Models relating to this kind of action definition are
(physical) space description, and potential field presentations.
6. Action as command: This description form is based on control theory and cybernetics
which apply a particular command theory.
Some investigations consider the action of actors which are threats models as a simpler kind
of agents (see [Agha 01]). The actor-based models are the foundation of the Cyborgs (cyber
organism) (see also [Bradshaw 01]). The co-operation of software agents can be based on
agent teams. In order to build an agent team [Yoshimura 00] defines the following activities:
“Specify what a team is capable of doing (i.e., what roles it can fulfil); specify which
components are needed to form a particular type of team; specify the co-ordinated behaviour
among the team members; and specify some team knowledge.” Further aspects of team
building is related to the automated team formation and the special task structures in team and
subteams.
In MAS software agents play different roles such as matchmaker, brokers, facilitator or
mediator. This kind of agents is known as middle agent that can be characterised by its core
skills of providing basic mediation services to the considered agent society, co-ordinating
these services according to given protocols, conventions, and policies, and ensuring reliable
service mediation in terms of levelled quality of services as well as trust management within
and across multiagent systems borders.
On the other hands, security aspects play an essential role in agent co-operating. An agent
management must provide basic mechanisms for identifying agents (authentication) and for
verifying the privileges of agents in the shared space (authorisation) (see [Bryce 01]). The
application of agent-based systems for communities was called by [Hattori 99] as socialware.
Hence, the software quality assurance of agents co-operation must considers the aspects
such as the efficiency of the agents interaction, the level of the co-ordination, the quality of the
agent coupling, the reliability of the agent components, the appropriateness of the kinds of
agent actions, the effectiveness of the agent teams and communities, and the level of successes
of consideration the user goals.
1.2.5 Agent Minds, Intentions, Motivations and Negotiations
The next consideration is directed on the states of the (artificial) minds of software agents.
This view is related to the mental states and intentions of software agents. Mental states are
based on the cognition concept which consider several types of cognition as interactional,
representational, conative, organisational and other cognition.
On the other hand, the source of actions are agent motivations. Relating to the dimensions of
organisations, we can distinguish between personal, environmental, social and
representational kinds of motivations. As a special case, we can establish the commitment as
a solution of relational and social motivations under special constraints. Another aspect of
motivation is the intention which is defined by [Ferber 99, p. 298] as: “We say that an agent x
has the intention of carrying out an action a which we denote as intention(x,a) if x has as its
20
goal that a proposition P about a state of the world should be true (denoted goal(x,P) ) and
that the following conditions should be satisfied: x believes that P forms part of the
consequences of a; x believes that P is not currently true; x believes that it is capable of doing
a; x believes that a will be possible, and thus that P can be satisfied.”
Agent intention or motivations are also a reason for agent negotiation in order to keep some
tasks of a collaboration. [Katoh 00] defines some kinds of negotiation protocols which
consider risks of successful agent co-operation. This investigations led to the kinds of
software agents as risk averse, risk neutral and risk seeking agents.
A general characterisation of the agent behaviour as agents roles is described by Kendall
comparing the facets of objects and agents roles in the following table [Kendall 01].
Role model
Responsibilities
Objects
Services, tasks
Agents
Services, tasks, goals, obligations,
interdictions
Collaborators
Roles it interacts with
Roles in interact with
External interfaces
Access to services
Access to services
Relationships to other roles Aggregation, generalisation, re- Aggregation, specialisation, generafinement, role sequences
lisation, role sequences
Expertise
Ontology,
inferencing,
problem
solving, knowledge
Co-ordination and
Protocol,
conflict
resolution,
negotiation
knowledge of why other roles are
related, permissions
Other
Resources, learning/adaptability
Table 5: Facets of objects and agents roles
[Preist 99] distinguishes three main approaches of negotiation strategies such as
•
•
•
The rule based approach where the negotiation strategy is coded into the agent using a set
of rules specifying how they should bargain, and when they should or shouldn’t accept a
deal.
The game theoretic approach which is based on the economic analysis of a negotiation
problem which is used to propose an appropriate negotiation protocol and strategy.
The adaptive behaviour approach where simple agents adapt their strategy by observing
the behaviour of the marketplace and their current performance.
Some concrete agent negotiations has been defined by Zacharia [Zacharia 01] for e-commerce
agents in the following manner:
•
The buying agent, which tries to maximise the following Cobb-Douglas utility function
U = (1 – P)1-I OI
•
where P is the price the buyer will pay, normalised by his budget cap (Pactual/Pcap) so that
it is between 0 and 1, I is the importance of the problem to the buyer, and O is the
outcome of the problem in the range [0,1], where 1 is perfect and 0 is terrible.
The selling agent, which can executes the derivative follower’s price based on
P = LastContractPrice + Sup * random1 - Sdn * random2 * idle
21
where is assumed that the price bids are increased by a fixed step Sup for the next period
and was decreased by Sdn if a deliberative follower fails to receive a contract.
Special examples of agents for electronic marketplaces are defined by [Barbosa 01] as buyer
agent, seller agent and (between them) as intermediary agent. Their algorithm are described
as following
•
The algorithms of the buyer agent’s perception based on the
- Active transactional model:
M1:if know what want
then inform product details are offer
then M2: choose the product
That fits better;
Visualize options and choose
With whom negotiate;
Start negotiation
if Complete transaction
then finish transaction
else goto M1
else M3: information is saved for
seller’s evaluation
else inform the kind of the product;
if inform product functionality offer
then goto M2 else goto M3
-
Passive transactional model:
M1:iter until intermediary agent contact
if the product interest
then start negotiation
if complete transaction
then finish transaction
else goto M1
else answer is no
•
The algorithms of the seller agent’s perception based on the
-
Active transactional model:
-
M1: choose what announce
iter wait for demand
if demand
then visualize possible buyers;
start negotiation;
if complete transaction
then finish transaction
else goto M1
Passive transactional model:
M1: iter until intermediary agent contact
if sell the product
22
then give information;
start negotiation;
if complete transaction
then finish transaction
else goto M1
else answer is no
•
The algorithm of the intermediary agent based on a general transactional model:
if received request of demand
then if offered product found
then show the buyer;
M1: intermediate negotiation;
Save negotiation results;
M2: if buyer profile for
Suggestion suitable
then notify the buyer
else goto M1
else show answer the lack
else (~ of demand)
if buyer not satisfied found
then contact the buyer;
goto M1
else save product and characteristics;
goto M2
An essential aspect in agent’s negotiation consists in their possible conflict management. The
following model by [Tessier 01] describes the conflict handling for agents.
Conflict
avoidance
Goal
adaptation
Conflict
recognition
Conflict
diagnosis
Conflict
resolution
Conflict
process
analysis
Belief
update
Conflict
management
Negotiation
Figure 12: Conflict handling action model
A general classification of conflict resolution modes is defined by [Aïmeur 01] as
•
•
•
Negotiation: as a discussion procedure established between two opposed parts for the
purpose of reaching a common agreement.
Mediation: as a negotiation between two opposed parts in the presence of a third neutral
part which will facilitate the research of a solution to the conflict.
Arbitration: where conflicting parts leave it to a third part decision.
23
[Jung 01] developed a system for multi-agent teamwork called CONSA (Collaborative
Negotiation System based on Argumentation) to resolve conflicts. The key idea in CONSA is
to cast conflict resolution as an explicit common team goal. CONSA includes three stages of
argumentation. We assume that the team member Aj generates a proposal π. Then the
argumentation stages are
1. Opening stage:
(a) A team member Aj detects a conflict with π.
(b) If Aj believes joint action not beneficial to resolving conflict, terminate, return;
(c) Else Aj communicates with team members to establish team operator to resolve
current conflict.
2. Argumentation stage:
(a) Any member Ak in the current team operator may generate proposal to resolve
conflict,
(b) Other team members evaluate-proposal.
(c) If no conflict/coincidence found, accept the proposal and got to step 3.
(d) Else if proposal found to conflict/coincide; continue argument if cost-benefit-wise
useful, else accept the proposal and goto step 3.
3. Closing stage:
(a) If suggested proposal accepted, then terminate conflict-resolution team operator;
(b) Else if the conflict resolution found unachievable or irrelevant, terminate conflictresolution team operator.
A special model for agent operation is well-known as belief desire intention (BDI) model.
[Georgeff 98] describes the three components in this model as follows:
•
beliefs are components of an agent-based system which can represent environment
information they was updated after each sensing action,
•
desires are components which include information about the objectives what priorities or
payoffs are associated with the various current objectives,
•
intentions are components which include the information of the system state to represent
the currently chosen course of action.
The BDI agent architecture of Kinny described in [Pitt 00] is shown in the following figure.
Belief (fact)
Database
Plan
Library
Sensors
User/Agent
Interface
Interpreter
(Reasoning
System)
Environment
24
Actuators
Desires
(Goals)
Intention
Structures
Figure 13: BDI agent architecture
These models are the background of the agents negotiation in order to arrive special goals or
intentions. A well-known example of this negotiation is the haggle protocol (see [Pitt 00a])
which is illustrated by the finite state diagram shown in the following figure.
buyer: query_if
0
seller: inform
1
seller:agree
2
buyer:inform
9
seller:agree
9
Figure 14: The Haggle protocol
In order to manage the BDI process, [Brazier 99] defines the following control hierarchy
shown in the figure 15.
own process control
Belief determination
intended goal
determination
desire determination
intention and commitment
determination
goal determination
plan determination
committed goal
determination
intended plan
determination
committed plan
determination
Figure 15: Task hierarchy of own process control within a BDI agent
[Jain 99] defines the sphere of commitment between agents as SoCom. In order to keep a
successful co-operation, the SoCom manager was created for efficient e-commerce
applications.
Hence, the software quality assurance of agent minds, intentions and negotiation should
consider the aspects such as the level of negotiation, the success rate of negotiations, the
25
effeciency of the agent roles, the appropriateness of the negotiation strategies, the
effectiveness of the BDI application.
1.2.6 Agent Mobility
The general aspects and priciples of agent mobility is shown in the charts of the following
figure.
App
Host A
Service
RPC-based approach
App
Host B
Service
Send agent
App
Service
App
Mobile Agent-based approach
Service
Disconnect
App
Service
Recconnect
and return
Figure 16: Principles of Agent Mobility
In order to keep the agent’s mobility, most of the agent-moving work must be done in the host
or network. Knapik defines the following activities by the host ([Knapik 98], p. 203):
•
“Network and mobility support is responsible for moving files to and from addresses.
These files contain agents, which must be executed at each host.
•
Verify that the agent has all right codes embedded the header.
•
Discern the capabilities of an agent, and determine whether an agent can execute or
whether it is safe to execute. This could mean parsing the agent’s source code to find any
references to forbidden global variables or functions that aren’t understood. The agent
must know what functions the host supports, and call only those functions, or the host
must be able to load a personality that is indicated in the agent header.
•
Perform information, resource, and data access functions, such as getting current time,
customer record, and so on.
•
If an agent runs amok, stop it and send it back to its user to be analyzed, then change
permissions such that the user’s agents are not longer welcome.”
Li defines a “secure route structure” for mobile agents in the following manner [Li 00]: “An
agent’s route is defined as a sequence of [c0, ..., cn]. Each of ci, for 0 ≤ i ≤ n, represents the IP
address of a host. The route indicates the itinerary of an agent, who will visit each host in the
same order as the sequence.” Furthermore, this sequence is a structure because of the eligible
26
paths in the network. This basic structure can be extended by any quality information such as
performance, cost etc. (see also [Stefano 00]).
Hence, the software quality assurance of agent mobility addresses the aspects such as the
performance of agent movements, the appropriateness of the visited cities, the knowledge
about the requirements and supports of the different cities.
1.2.7 Agents Communities and Organisations
The system of co-operating agents can be built as agent organisations (see also [Case 01] and
[Valera 01]). We cite the definition of [Ferber 99, p. 88]: “An organisation can be defined as
an arrangement of relationships between components or individuals which produces a unit, or
system, endowed with qualities not apprehended at the level of the components or individuals.
The organisation links, in an interrelational manner, diverse elements or events or individuals,
which thenceforth become the components of a whole. It ensures a relatively high degree of
interdependence and reliability, thus providing the system with the possibility of lasting for a
certain length of time, despite chance disruptions.” The key functions of an agent
organisation – also defined by Ferber – are described in the following.
The representational function frepr comprises the generality of functions for modelling the
environment and other organisations as well as the memorisation of any events which may
have affected the organisation. The role associated with the representational function is that of
archivist.
The organisational function forg relates to everything concerning the management of the
activity of an organisation, and in particular to the planning, allocation and following up of
tasks, the co-ordination of actions and the management of obligations. A large number of
roles are associated with this function, in particular those of customer, mediator, planner and
co-ordinator.
The conative function fcon refers to the sources, limits and selection of the activities of
organisations and is divided into three sub-functions: the motivational function, the external
function and the decision function. One of an associated role of this function is the decisionmaker.
The interaction function finter serves to create the link between an organisation and that which
surrounds. The roles associated with this function are those of interface (observer, executive
and communicator).
The productive or operative function foper concerns the primitive activities which have to be
brought into play to solve a problem or carry out a piece of work.
The vegetative or preservative function fvege deals with the preservation of both structure and
agents, with the acquisition and maintenance of resources, and with the tasks carried out to
maintain and reproduce the organisation.
The schematic representation of the different functions of an organisation is shown in figure
17 which demonstrates the possible interactions of these functions [Ferber 99].
27
Cognitive
function
Vegetative
function
Productive
function
Co-ordination
function
Representational
function
Interface
function
Figure 17: Types of functions of an organisation
For the interaction between organisations, [Ferber 99, p. 96] defined five types of dimensions:
(1) The physical dimension (φ) deals with the implementation, the architecture of the
organisation and its personal resources.
(2) The social dimension (σ) concerns the place and thus the role of an organisation in a
higher-level organisation.
(3) The relational dimension (α) is concerned with interactions, with the exchanges which an
organisation may have with other organisations on the same level, and with its
communications and their co-ordination.
(4) The environmental dimension (χ) is linked to the organisation’s capacities to act, perceive
and reason in relation to the surrounding world.
(5) The personal dimension or dimension of the self (ω) represents everything which relates to
the essence of the organisation.
Figure 18 gives a simplified presentation of these dimension analysis of agent organisations
including a mapping of the organisational functions by [Ferber 99, p. 105] for two kinds of
agent organisation: the reactive organisation ReactOrg and the communicative organisation
ComOrg. The notification of the function means their presence and the function written in
square brackets means their optionality.
Social: σ
ComOrg(frepr,[ forg, fcon , foper ])
Relational: α
Environmental: χ
28
Self: ω
ComOrg(forg, fcon, finter,[ foper])
ReactOrg(forg, fcon, finter, foper, fvege)
ReactOrg([ fcon ])
ComOrg([ foper ])
ComOrg(frepr, [ forg ])
Physical: φ
ReactOrg(forg, fcon, finter, foper, fvege)
ComOrg(frepr, forg, fcon, finter, foper)
Figure 18: Aspects of analysing of organisations
Software agents in organisations could be observed for different kind of reasons. The
observation of the software agents should have no influences on their operationality.
Therefore, [Moro 00] defines some kinds of synchronisation (also called correlation
strategies) relating to the considered agent events such as
•
•
•
“Temporal correlation, events coming at close times are grouped together, and the firing
of a grouped event is performed when an internal clock sends its tic.
Size correlation, events are put into a buffer and sent when the buffer becomes full.
Data correlation, events carry some information that is used both to classify them and to
decide when to send a grouped event.”
In this context, we can establish seven types of agent organisational relationships shown in
Table 6 after [Ferber 99, p. 111].
Relationships
Acquaintance
Communicational
Subordination
Operative
Informational
Conflictual
Competitive
Static
Master/slave
Dependency between tasks
Dependency between knowledge
-
Dynamic
Service demand/request
Obligation to do
Validation obligation
-
Table 6: Organisational relationships
[Ferber 99, p. 225] describe three general types of modelling the intentions of agents:
•
The interactional system: This kind of modelling is addressed to the actions such us active
and passive perceptions and defines the elementary and complex features.
•
The representational system: This kind of modelling considers the representation, the
beliefs and the knowledge of agent-based systems. The types of beliefs can also be
divided in the organisational grids of analysis as environmental (χ), social (σ), relational
(α) and personal (ω).
29
•
The conative system: This model determines the action that the agent should undertake, on
the basis of the data and knowledge available to it, in order to maintain a function, while
preserving its structural integrity and its actions in such a way that the organisation of
which it forms part also preserve its structural integrity.
Hence, the software quality assurance of agent organisations must consider the aspects such
as the appropriateness of the different organisation functions, the level of the different
organisation dimensions, the effectiveness of the interoperations in an agent organisation, and
the performance of the agents correlation.
1.2.8 MAS Architectures
In order to investigate the software agent quality, we must consider the different kinds of
agent-based system architectures. These kinds of architectures lead us to the quantity
characteristics of agent systems and give us the possibility of agents and systems evaluation
based on real system parameters such as system structure, complexity and coupling (see also
[Vidahl 01]). Kinds of agent architectures are described by [Hayzelden 99] as the reactive
agent architecture, where the agents based on this type of architecture generally do not have
an internal representation of the environment; the deliberative agent architecture, where an
agent that conforms to this architecture generally has a richer internal representation of its
operational environment; the hybrid agent architecture that is a coupling of the two above
architectures.
Types of agent architectures according to [Ferber 99, p. 127] are described in the following
Table 7. This table includes more details about the component structure.
Type of
architecture
Horizontal
modular
Blackboard
Subsumption
Competitive
tasks
Production
rules
Classifiers
Connectionist
Dynamic
system
Multi-agent
Approach
Horizontal
functional
Functional
Vertical
functional
Vertical
functional
Functional
Vertical
functional
Vertical
functional
Vertical
functional
Object/
functional
Type of
component
Module
Subordination
structure
Hierarchical
Coupling
structure
Fixed (but
progressive)
Variable
Fixed
Constitution
Task
Primitive task
Hierarchical (Meta)
Hierarchical
Task + primitive
actions
Rule
Hierarchical
(Competition)
Hierarchical (Meta)
Variable
Predefined
Variable
Predefined
Rule
Hierarchical
Evolutionary
Predefined
Formal neuron
Egalitarian
Predefined
Stimulicommand
Agent
Egalitarian
Fixed (by
weight)
Fixed (but
progressive)
Variable
Egalitarian
Predefined
Predefined
Predefined
Emergent
Emergent
Table 7: Main agent architectures by Ferber
A general characterisation of future communication systems is given by [Nwana 99] including
the software agent technology shown in the following figure.
User Interface Agents
Agent Interoperability/Middleware Layer
Network Service Layer
30
Telecommunication Network Layer
Figure 19: A layered architecture of agent-based communications systems
The FIPA Agent Management Reference Model (see [Bellavista 01]) is described in the
following figure.
Domain
Agents
Agent Platform A
Internal Platform Message Transport
ACL
Interfaces
Wrapper
Management
Agent
Agent
Communication
Directory
Facilitator
Communication Channel (ORB)
Figure 20: FIPA Agent Management Reference Model
Now, we will present some examples of an agent architecture. The network community
support system Shine is based on the following software agent architecture [Yoshida 00].
user
Application
Interface
Planner
other agents
Post
Person Database
Figure 21: The internal structure of a Shine agent
[Laufmann 98] defines a functional agent model which includes the following general
components.
general
knowledge
and behaviour
31
“internal”
capability
modules
“external” interactions
with other agents
communication
and interaction
Agent Core
task-specific
knowledge
and behaviour
protocol and
language
modules
“internal”
resource and
skill modules
Fig. 22: Coarse-grained agent functional model
A special agent description for an intelligent agent is defined by [Evans 99] in the following
manner (KB stands for knowledge base).
Agent Comm.
Module
Task
List
Negotiation
Skills
Agenda
Attention focus
Situation
Assessor
Agent Comm.
Module
Low Level
Skills
Self
Model
World
KB
High Level Capabilities
Skill KB
Agent
Model
Contexts
World view
Figure 23: Intelligent agent internals
This is an example of an intra-agent structure where the MAS architectures are descriptions
of the inter-agent structures. Examples of MAS architectures are presented in the following.
The general architecture of the OMG MASIF (Mobil Agent System Interoperability Facility)
is shown in the following figure (see [Bellavista 01]).
Region
Agent System
Place
32
Enhanced Agent
Services
Agents
MAF Agent
System
Basic Agent
Services
MAF
Finder
Communication Channel (ORB)
System-specific
MASIF-compliant
Figure 24: OMG MASIF interfaces
The general MAS infrastructure RETSINA (Reusable Task Structure based Intelligent
Network Agents) by Sycara et al. described in [Shehory 01] is shown in the following figure.
USER1
Goals and Task
Specification
USER2
USER h
Results
Interface Agent 1
Interface Agent 2
Interface Agent k
Task
Proposed Situation
Task
TaskAgent 1
TaskAgent 2
TaskAgent j
Conflict
Resolution
Information
Request
Reply
Service Request
Information Integration
Advertisement
InfoAgent 1
MiddleAgent 1
InfoAgent n
Info Source 1
Info Source 2
Info Source k
Figure 25: The RETSINA multi-agent infrastructure
The multi-agent system architecture is based on the concrete requirements of their
implementation. An example of an Agent Service Layer (ASL) by [Evans 99] is shown in
Figure 26 without any comments.
C++
Sicstus Prolog
CLIPS
Java
KQML
33
Jess
ASL
JASL
Orbix
OrbixWeb
TCP/IP
Figure 26: ASL architecture description
The general MAS infrastructure ADEPT (Advanced Decision Environment for Process Tasks)
by Norman et al. described in [Shehory 01] is shown in the following figure.
Agency 5
Agency 8
Agency 6
Responsible
agent 8
Communication
Agency 7
Responsible
agent 4
Agency 4
Communication
Agency 3
Agency 1
Agency 2
Figure 27: The ADEPT multi-agent organisation
A simple description of the main components of an agent-based system by [Nwana 98] is
shown in Figure 28 which is used over an interface agent.
co-operate
collaborative
agents
learning
smart
agents
interface
agents
autonomous software system
Figure 28: A part view of an agent typology
In Figure 29 we will show another architecture defined by [Busuioc 99] which is addressed to
the management of telecommunication systems (see also [Fricke 01]).
portable PC
mobile phone
34
PDA
customer agent
service agent
service agent
service supplier agents
service supplier agents
Network domain
Cell agent
fixed network agent (FNA)
FNA
FNA
FNA
Agent Platform
Figure 29: The agent platform architecture by Busuioc
The kinds of agent architectures should be the source for deriving model parameters and
aspects for agent system evaluations.
An example of a MAS architecture in order to support a workflow enactment service is given
in the following figure [Divitini 01].
Agent Manager
Workflow
Enactment
Service
Agent
Agent
Agent
Connection
Server
Invoked
Application
Figure 30: An agent-based architecture for Wokflow Enactment Service
[Kühnel 01] defines the following general relation model between the agent aspects and
components which can be a basis for different kinds of MAS architectures.
Knowledge Base
Situation
Option
matches
reach
35
Information
Capability
Goal
fulfil
Plan
current
Request
id
ActionInvocation
Intention
Commitment
Task
Schedule
id
Action
starts
runs
TimePoint
Controller
loads
current
Executor
Interaction
Management
Components
owns
Motivation
Expertise
knows
uses
State
other
Figure 31: Relations between MAS data structures and components
Some kinds of software agents that are working in the Web [Thuraisingham 01] are retrieval
agents, mobile agents, filter agents, locator agents and situation monitoring agents. A typical
architecture of agents in the Web is described in the following figure (see also [Kearney 98]).
Data Sources
Retrieves Data
For Client
Retrieval
Agents
Locator
Agents
Locates Data
for Client
Informs
Retrieval
Agents
Internet / Web
Client
Figure 32: Agents and the Web
Tewari and Maes defines a MAS architecture in order to evaluate the effectiveness and
quality of the heterogeneous resources in electronic markets ([Tewari 01], see also [Maes
99]). The main components of this Multi-Attribute Resource Intermediary (MARI) system are
described in the following figure.
Internet
HTML Interface
36
User Interface Manager (UIM)
Buyer Valuation Manager (BVM) Seller Valuation Manager (SVM)
Valuation Function Generalizer (VFG)
Valuation Function Trainer (VFT)
User Notification
Manager (UNM)
Market Cycle Manager (MCM)
Optimisation Heuristic Manager (OHM)
Active User List
Match Maker (MM)
User Status Manager
(USM)
Transaction
Partner List
Buyer
Pool
Seller
Pool
Database Manager (DM)
Figure 33: Architecture of the MARI system
A simplified architecture of a MAS for telecommunication is developed by [Huhns 98] and is
shown in the following figure.
User
DB1
Graphical Interaction Agent
Transaction Scheduling Agent
Schedule Repairing Agent
Scheduling Processing Agent
DB2
...
DBn
Figure 34: Multi-agent system for relaxed processing of telecommunication
transactions
A MAS architecture based on the application view is described as Human-Centred Virtual
Machine (HCVM) in [Koshla 00] shown in the following figure.
Problem Solving Agent Layer
Intelligent Hybrid Agent Layer
37
Intelligent Agent Layer
Expert
System
Agent
Software Agent Layer
Distributed
Comm. &
Processing
Agent
Fuzzy
Logic
Agent
Media Agent
Supervised
Neural
Network
Agent
Object Layer
XML Agent
Self Organizing Agent
Genetic Algorithm Agent
Fusion
Agent
Global Preprocessing
Phase Agent
Combination
Agent
Decomposition
Phase Agent
Control Phase
Agent
Transformation
Agent
Decision
Postprocessing
Phase Agent Phase Agent
Figure 35: The five layers of the HCVM
A special example of a so-called upper respiratory decision media agent is described in the
following table (see [Koshla 00]).
Parent Agent
Goals:
Tasks:
Task Constraints:
Invoking Condition:
Precondition:
Postcondition:
Communicates with:
HCVM media agent
Effective/accurate symptomology gathering
Establish practitioner’s location in the system
Correlate symptomatic data to argumentative diagnosis knowledge
Determine symptoms
Map symptom characteristics to media artefacts
Determine media layout
Map symptomatic data to antecedents of rules and input vector of supervised
neural networks
Medical practitioner’s context, symptom data characteristics,
media characteristics information processing/task context,
media layout (e.g. visual, text)
Request from upper respiratory diagnosis decision agent C
Trained Medical practitioner, Problem solving phase: decision, diagnosis,
availability of image/graphic, audio and text objects
Multimedia upper respiratory diagnosis symptom display
Upper respiratory diagnosis decision agent C, graphic and audio objects
Table 8: The HCVM media agent
Parent Agent
Communication
Constructs
Linguistic/nonlinguistic
features:
External and Tools:
HCVM media agent
Inform: upper respiratory symptomology to decision agent C
Psychological scale and representing dimensions of symptoms,
symptom for upper respiratory infection cluster C
Software: Graphic object, audio objects, text object
Domain: Symptomology images, sound effects
Design: Multimedia symptom analysis and design techniques
38
Internal Tools:
Planning and sequencing media generation, display and co-ordination
actions
Generate and display upper respiratory symptomatic elaborate images,
abstract sound effects and representative text,
Generate & Display logarithmic sliding temperature scale and other
perception based sliding scales for acute Otitis Media symptoms,
Generate & Display abstract image icon to establish practitioner’s location
in the system (e.g. potential diagnosis state)
Display feedforward neural network graphics for reasoning (not
implemented)
Actions:
Table 8: The HCVM media agent (Cont.)
A special kind of MAS is defined in [Umeda 00] as argument-based agent system which is
based on co-operative reasoning with argumentation protocols.
The Nomad architecture of an eAuctionHouse is defined by [Sandholm 00] as follows.
User’s
TCP/IP
connection
Replies to user
Request for
bids, setting
up auctions etc.
User’s
Web browser conn.
H
T
M
L
Inter
face
eAuctionHouse
Auction
database
Connection
manager
Auction
engine
Web system
Request for automaInterface for tically generated agent
specifying
agents
Agent
generator
Agent
database
Create agent
from template
Agent
manager
User’s
TCP/IP
connection
Create user-programmed Java agent
Agent dock
Communication
with user
Nomad
Figure 36: The Nomad architecture within eAuctionHouse
[Massoud 00] describes the potential architecture of industrial systems with critical aspects
such as security, performance, reliability, and robustness. The following figure 37 shows this
general architecture.
Vulnerability
Assessment
agents
Hidden failure
monitoring
agents
Reconfiguration
agents
Restoration
agents
Event
Planning
39
identification
agents
agents
Triggering events
Event/alarm
filtering
agents
Plans/decision
Model
update
agents
Update model
Command
interpretation
agents
Check
consistency
Events/alarms
Controls
Fault isolation
agents
Inputs
Frequency
stability agents
.........Inhibition signal ........
Protection
agents
Generation
agents
Controls
Power system
Figure 37: The multi-agent system architecture
This design organises the agents in three layers:
1. The reactive layer (bottom) consists of agents that perform programmed self-healing
actions that require an immediate response.
2. The agents in the co-ordination layer (middle) include heuristic knowledge to identify
which triggering event from the reactive layer is urgent, important, or resource
consuming.
3. The deliberative layer (top) consists of cognitive agents that have goals and explicit plans
that let them achieve their goals. The goals of agents in this layer are dependability,
robustness, and self healing.
The application of mobile agents in order to keep security aspects is described in [Romão 01]
based on the definition of a proxy certificate (see Figure 38), where CA stands for certification
authority and C for certificate.
Cardholder(C) certificate
Proxy certificate
C Identity
C
pub key
C Identity
CA
Agent
Signature
pub key
C
Signature
Figure 38: Cardholder binding with a proxy certificate
The signature verification based on this agent related structure shows the following figure.
CA certificate
Cardholder(C) certificate
CA Identity
C Identity
40
CA
pub key
CA
C
Signature
pub key
CA
Signature
Proxy certificate
C Identity
Signed document
Agent
pub key
C
Agent
Signature
Signature
Figure 39: Signature verification with proxy certificates
Hence, the software quality assurance of MAS architectures addresses the aspects such as
the efficiency of the MAS layers, the reliability of the MAS components, the appropriateness
of the chosen platform, the performance of the co-ordination and planning in the MAS, the
usability of the MAS interface, the effectiveness of the MAS integration, the manageability of
the MAS structure, the appropriateness of the MAS architecture granularity.
1.3 The MAS Development Process
1.3.1 MAS Development Methodologies
The MAS development process is embedded in the general view of the Agent-Oriented
Software Engineering (AOSE). Another description as Agent-Based Software Engineering
(ABSE) is a refinement of some aspects of AOSE based upon practical experience in agent
building [Petrie 01]. Currently, we can establish: “Although many Multi-Agent Systems
(MAS for short) have been designed, there is a crucial lack concerning specification and
development methodologies.”[Hilaire 00]
Some of the agent-oriented system development technologies and methodologies are (see also
[Knapik 98], [Koblick 99], Parunak 99], [Papazoglou 01], and [Stojanov 00a]):
¾ AAII: This methodology has been created by the Australian AI Institute for developing
agent-based systems for a decade (see [Wooldridge 01]). The main technologies involve
in this methodology are the belief-desire-intention technology, the procedural reasoning
system (PRS) and the multi-agent reasoning system (DMARS). The main steps of the AAII
methodology are
1. Identification of the roles in the application domain and development of the agent
class hierarchy.
41
2. Identification of the responsibilities associated with each role, the services
required by and provided by the role, and then determine the goals associated with
each service.
3. Determination of the plans for each goal that may be used to achieve it, and the
context conditions under which each plan is appropriate.
4. Determination of the belief structure of the system – the information requirements
for each plan and goal.
¾ AAOSA: The Adaptive Agent Oriented Software Architecture is a software methodology
that proposes the break-up of complex software into a community of simpler,
independent, collaborating, adaptive, message-driven components such as AAOSA
agents. Each agent is comprised of a black box section (specialities) and a white box
section (communications) (see [Wooldridge 01]). The predefined communication is based
on a standard inter-agent message field. The co-ordination between agents uses ambiguity
resolution methods.
¾ ABROSE: The Agent Based Brokerage Services in Electronic Commerce framework
includes the following objectives (see [Wooldridge 01]):
1. Dynamic knowledge capture,
2. Usage of multi-agent system to represent the knowledge base,
3. Navigation and information retrieval through a graphical interface (also supported
by agent technology),
4. Utilisation of Java and CORBA as implementation technologies,
5. Usage of collaborative agents to optimise intermediation,
6. Evaluation of agent technology implications in information brokerage and
commercial applications,
7. Java, CORBA, and SNMP usage to implement the management architecture.
In ABROSE, the MAS is concerned with the brokerage functionality for e-commerce
activity. Buyers and sellers are represented by proactive, autonomous, and co-operative
agents.
¾ ADK: The AgentBean Development Kit (see [Papadopoulos 01]) is a component-based
framework for developing mobile multi-agent systems with some emphasis on network
and system management issues. An agent composes one of the following three sets:
1. Navigational components which are responsible for managing the internity of the
agent,
2. Performer components which consider the management tasks that should be
executed at the host of the currently visited place,
3. Reporter components which are responsible for delivering agent’s results to
designated destinations.
¾ Agents in Z: The framework approach of Luck and d’Inverno uses the Z language and
defines a four-tier hierarchy of the entities that can exist in an agent-based system (see
[Wooldridge 01]). They defines this four levels as kinds of system components as
1. Entities which are inanimate objects which have attributes such as colour weight
and position,
2. Objects to be entities that have capabilities,
42
3. Agents which are defines to be objects that have goals and thus are in some sense
active,
4. Autonomous agent which are defined to be agent with motivations.
¾ Agent UML: This methodology by Odell et al. uses the Unified Modeling Language
(UML) in order to support the agent system development (see [Bauer 01] and [Odell 01]).
The proposed modifications include:
• Support for expressing concurrent threads of interaction thus enabling UML to
model contract protocols,
• A notion of “role” that extends UML to allow the modeling of an agent playing
many roles.
Concretely the following connector types are defined in order to extend the UML
sequence diagram for the possibilities of interactions in the agent lifelines and agent
threads.
X
query
request
X
X
AND
XOR
not understood
OR
example of XOR
Figure 40: Connector types and their use
¾ Burmeister: This approach is described in [Lind 01] as a development method for MAS
based on object-oriented techniques. This method is limited to systems of co-operative,
directly communicating software agents. The model approach includes three process
descriptions: the agent model, the organisational model, and the co-operation model. The
agent model of this approach describes the internal states, i. e. the goals or plans, of the
agents and thus models the dynamics in the small. The interactions are modelled by
protocols based on KQML messages.
¾ Cassiopeia: This approach of Collinot et al. is essentially bottom up (see [Wooldridge
01]). The methodology proposes three steps:
1. Identification of the elementary behaviours that are implied by the overall system
task,
2. Identification of the relationships between elementary behaviours,
3. Identification of the organisational behaviours of the system which includes the
grouping of the agents themselves.
¾ DESIRE: This framework by Treur et al. is developed for the design and formal
specification of compositional systems (see [Wooldridge 01]). DESIRE has associated
with it a graphical editor and other tools to support the development of agent systems.
43
¾ Formal methods for AOSE: Formal methods in software engineering are helpful for the
specification, direct programming and verification of software systems (see [Wooldridge
01]). These approaches intend the following details:
•
Specification: The formal specification of agent-based systems is directed on the
aspects of beliefs, goals, actions and ongoing interaction. The most successful
approaches are based on the temporal modal logic. Two examples of these
approaches are the Cohen-Levesque theory of intentions and the Rao-Georgeff
belief-desire-intention model. Problems can appear by the semantics of the
specification languages based on this logic. Possible world semantics imply that
agents are logically perfect reasoners, and they have infinite resources available
for reasoning. No real agent has these properties. On the other hand, possible
world semantics are generally ungrounded. That is, there is usually no precise
relationship between the abstract accessibility relations that are used to
characterise an agent’s state, and any concrete computational model.
•
Directly programming: Usually, the implementation of a MAS specification can
be achieved by transformation in a programming language. Therefore, a
specification was refined manually in order to fulfil the necessary information for
code generation. The two kinds of implementation are the direct execution of the
specification (as simulation) or the compilation of the specification and the
program realisation.
•
Verification: The verification of the MAS system development can be realised by
deductive verification (based on an axiomatic system such as Hoare’s calculus) or
by model checking as a semantic approach in which was proved if a formula of a
language (the specification) is valid to a predefined semantic model.
¾ Gaia: The Gaia methodology (the name comes from a Gaia hypothesis that all the
organisms in the earth acting together to regulate the earth’s environment) is developed by
Wooldridge et al. [Wooldridge 01] and is intended to allow an analyst to go systematically
from a statement of requirements to a design that is sufficiently detailed and that can be
implemented directly. The Gaia approach consists of two general concepts:
a) The abstract concept including the roles, permissions, responsibilities, protocols,
activities, liveness properties, and safety properties,
b) The concrete concept involves the agent types, the services and the acquaintances.
¾ IMPACT: The Imperative Maryland Platform for Agents Collaborating Together (see
[Klusch 01]) supports multi-agent interactions and agent interoperability in an application
independent manner. IMPACT provides the yellow-pages server, the registration server,
the type server and the thesaurus as human interface. The services of agents are described
in a special markup service description language.
¾ IMPS: The Internet-based Multi Agent Problem Solving (see [Papadopoulos 01]) is a
compositional platform for developing Internet multi-agent systems. IMPS uses problem
solving methods and supports multi-agent systems with a knowledge library which can be
distributed over the Internet. The agent level architecture contains two kinds of server
agents: the extraction agent and the ontology construction agent which are used for
providing on-demand knowledge to inference agents.
44
¾ JGram: This approach supports the rapid development of multi-agents systems (see
[Papadopoulos 01]). Agents’ services are defined in the JDL (JGram Description
Language) and will be automatically converted into Java source templates. Cooperation
between agents is based on pipelining where an agent may dynamically delegate tasks to
other agents and chain together their results. JGram slates are the base for agent
communication and are passed over from one agent to another for the purpose of
accessing and if necessary modifying the entries in it.
¾ Kinny/Georgeff Approach: This approach is also described in [Lind 01], p. 82 ff., and is
based on an object-oriented development method for BDI agents and BDI-based MAS.
The underlying model includes an external viewpoint with the agent model and the
interaction model and an internal viewpoint with the goal model and the plan model in
order to keep the BDI paradigm. Furthermore, formal definitions for beliefs and goals are
provided but the system dynamics are not explicitly modelled in the method.
¾ MALINA: MALINA (Multi-Agent Local Integrated Network Associations) is an
environment for the development of multi-agent applications and it is a more precise
extension of the concepts given in [Stojanov 96], [Stojanov 98], [Stojanov 00]. This is a
more common approach to intelligent agents and multi-agent systems, an approach that
does not focus just on the agents’ ability to “think” or to make the agent very clever, but
also embraces all constitutive parts of one multi-agent system in a vast technology for the
development of distributed applications in a very short time. The technology supports a
bottom-up approach for developing multi-agents applications. MALINA is specified in the
following three levels:
•
Abstract level – at this level a hypothetical infrastructure which provides the
theoretical framework of the technology is defined.
•
Conceptual level – conceptions are decomposition and detailisation of the
hypothetical infrastructure in order to prepare the development of supporting
programming tools and an appropriate developing environment The following
four conceptions which are a basis for the developing environment of the
technology are founded. The Abstract Agent Architecture specifies the
architecture of an abstract generic agent by help of which the agents of different
applications can be configured. The AgentCities specify a static infrastructure for
multi-agent applications. The AgentAssociation provides various possibilities for
building agents associations. The MobileServices give different ways for
automatic generation of mobile agents.
•
Development level – this level includes the development tool for the technology.
In the MALINA technology the abstract agent is a genetic structure with the following
main parts: agent machine including the agent interface, agent local control,
functionality (specialisation) of the agent and agent mentality. Agent interfaces consist
of perceptive and influence mechanisms. Using its sensors the agent receives
information from other agents and from the multi-agent environment. In our technology
that is the city in which the agent lives. Each agent sends information to the other agents
through its effectors, and using the effectors it is capable to change the environment or
to operate into the city employing its functionality and specialisation or its social role. It
is not enough just to send and receive information through sensors and effectors.
45
Mechanisms for processing and understanding these information are needed. In the
abstract agent architecture we have separated this process over two phases:
•
Agent training – during the configuration of the operational agent the designer has
to “teach” the agent what it should do according to received performative
(influencing the adaptation performance and the learning performance).
•
Run time processing – this is a practical mechanism for reasoning that enables the
agent to use all knowledge obtained during the training (influencing the cooperation performance and the suitability performance).
In the MALINA technology the agents can communicate with each other through
KQML (see [Finin 94], [Labrou 97]). The agent meta-level is the part from the abstract
agent that deals with the processing of the received requests (in form of KQML
performatives) and with the construction of the answers (also KQML performatives).
The Agent Cities concept specifies one open infrastructure for modelling multi-agent
systems in distributed environment. An application could be considered as a set of
different “cities”. Each city includes logically related agents. A city can be constructed
in three steps: specification and identification of the city, definition of the agent
locations and distribution of the agents over the city. Each operational agent after its
configuration is put into a given city and as an inhabitant of this city the agent
participates in the social life of the city. But to perform any social activities agents need
mechanisms to communicate with one another and with the institutions of the city. That
is why, when the cities are created, they have to be put into operation by means of
defining some communication mechanisms. The city consists of three main parts (see
Fig. 41), where MCC stands for Mobility Conditions Check, MA for Mobility
Assignment, AR for Agents Relocation, and SI for Static Infrastructure.
In the MALINA technology we propose a measurement and evaluation module which
implements some ideas of the approach proposed in this paper. By means of appropriate
metrics we try to gather quantity data for the evaluation of the agent behaviour (the
local aspect) and of the features of the multi-agents application as a whole (the global
aspect). By the local aspect we intend to improve the operation of the separated agent
and the loading of their local resources. We distinguish different kinds of resources –
devices, system software, information sources etc. The main goal of the global aspect is
the optimisation of the static infrastructure of multi-agents application and the effective
use of the global resources. The two aspects tie close together in relation to some
metrics.
Mobility Assistant
MCC
Measurement and
Evaluation System
MA
46
AR
SI
In the technological framework two kinds of measurements are possible - off-line and
on-line measurements. The off-line measurements will be accomplished during the
“agents’ teaching” phase which is a part of the testing. The measurement data are
visible for the designers of the multi-agents application. In this way they can improve
with help of development tools the technology of the static infrastructure of the system.
For the support of the off-line measurements we are going to define a new set of
specialised KQML-performatives. The on-line measurements and evaluations take place
during the running of the application (run-time measurements). The gathered data are
used mainly for supplying of the city’s mobility module. This kind of the measurements
is transparent for the application designers and users. They cause dynamically changes
of the system which can be only booked.
¾ MAS-CommonKADS: This approach from Iglesias described in [Lind 01], p. 85 ff., is a
general purpose multi-agent analysis and design method based on the so-called
CommonKADS design method which supports most aspects of a knowledge-based
systems (KBS) project. The method describes KBS development from two perspectives:
the result perspective that captures a set of models for different aspects and the
environment, and the project management perspective that includes features of a riskdriven generic spiral life cycle model. The CommonKADS extends the method by adding
techniques from object-orientation (OMT, OOSE, RDD) and protocol engineering (SDL,
MSC) and tailoring them towards the specific requirements of MAS. The model hierarchy
of this approach is shown in the following figure relating to the analysis and design
phases.
ANALYSIS:
Agent model
Task model
Expertise model
47
Co-ordination model
Organisational model
DESIGN:
Application model
Architectural model
Platform model
Figure 42: Hierarchical set of models in the MAS-CommonKADS approach
¾ MaSE: The Multiagent Systems Engineering methodology takes an initial system
specification and produces a set of formal design documents in a graphically based style
[Wood 01]. The general steps are shown in the following figure.
Requirements
Goal Hierarchy
Capturing Goals
Use Cases
Applying Use Cases
ANALYSIS
Sequence
Diagrams
Concurrent
Tasks
Roles
Agent Classes
Conversations
Refining Roles
Creating Agent
Classes
Constructing
Conversations
DESIGN
Agent
Architecture
Deployment
Diagrams
Assembling
Agent Classes
System Design
Figure 43: The MaSE methodology
¾ MASSIVE: The development method of MultiAgent SystemS Iterative View Engineering
was created in an European project in order to support the whole development process of
MAS construction and implementation [Lind 01]. The general MASSIVE view system is
described in the figure 44.
MASSIVE is an iterative development method. The fundamental building blocks are socalled knowbbles as a term being comprised of “knowledge” and “bubbles”. The
48
MASSIVE method is based on an experience factory and uses some helpful technologies
for a considerable implementation such as aspect-oriented programming.
Environment
View
Task
View
System Perspective
Developer Perspective
Agent
Architecture
Architectural
View
Functional
Nonfunctional
Basic Capabilities
System
View
System
Architecture
GUI,
Exception
Handling
Delimination
Deployment,
Performance
Engineering
Dimensions
Structures
Protocol
Design
Society
View
Role
View
Assignment
Generic
Interaction
Structures
Interaction
View
Figure 44: The MASSIVE view system
The UML activity diagram in figure 45 gives an overview about the MASSIVE process.
These main steps of MASSIVE include the usage of the experience dates which will be
used and updated during the developement of MAS in different projects.
not ok
ok
Implement
Apply
Evaluate
not reusable
code exists
no
49
Check Experience
Select Micro
Process Model
Construct
Reuse
yes
fail
First Iteration?
no Experience
exists
Adapt for Reuse
E. exists
Select Test Case
Run Test
Check
Experience
Reuse not ok
Change Code
Reuse ok
No further Test Cases
Project not
Further Test
Cases exist
ok
Select View
Re-Engineer
complete
Project complete
Update Experience
Figure 45: The MASSIVE methodology process description
¾ MStreams: The Mobile Streams is a middleware platform for the development of
distributed multi-agents systems (see [Papadopoulos 01]). It is suitable for applications
that require dynamic configuration. The components (namely mobile agents) synchronise
their co-operation by means of sending and receiving events.
¾ PageSpace: The PageSpace platform (see [Papadopopulos 01]) is a meta-architecture or
reference architecture for developing Internet agents-based application. The composed set
of distributed agents are conceived as comprising three layers: the client layer, the server
layer and the application layer. PageSpace distinguishes some kinds of agents, such as
user interface agents, application agents (that manage the running of some application),
gateway agents (that provide access to the outside world), kernel agents (that perform
management and control tasks) etc.
¾ SIM_AGENT: The SIM_AGENT toolkit [Sloman 99] allows the construction of agents
in which each agent has a multi-component architecture, in which different components
operate in parallel, using different kinds of mechanisms. These can include neural nets or
other reactive mechanisms alongside AI symbol manipulating mechanisms, used for
solving complex planning problems, or for certain metamanagement tasks. A factory
automation system could use a set of reactive procedures to handle routine management
and a deliberative planner to handle novel problems, such as the production of a new
product.
¾ SODA: The Societies in Open and Distributed Agent spaces is a methodology for the
analysis and design of Internet-based applications as multi-agent systems [Omicini 01].
SODA concentrates on inter-agent issues, like the engineering of societies and
infrastructures for multi-agent systems. The main development steps are:
•
Analysis: the role model, the resource model, the interaction model, and the
outcome,
50
•
Design: the agent model, the society model, the environment model, and the
outcome.
Some of these development approaches are evaluated in [Lind 01] based on the following
characteristics:
•
•
•
•
•
Generality: i. e. the range of multi-agent systems that is supported or the commitment to a
particular technology or agent architecture,
Flexibility: which covers aspects such as the extensibility of the method or support for
different process models or tools,
Granularity: captures the level of detail by which system aspect can be modelled and the
supported levels of abstraction,
Formality: e. g. the use of formal methods or well defined semantics of modelling
elements and finally,
Tool support: which summarise available tools for a particular method.
Based on these aspects the following evaluation is derived shown in table 9 (adapted to a
scale of 1 (low) until 10 (high)).
Method
Burmeister
Kinny/Georgeff
DISIRE
MAS-CommonKADS
Gaia
Generality
7
3
9
6
9
Flexibility
4
5
2
8
4
Granularity
3
2
7
10
5
Formality
2
4
6
3
6
Tool support
1
2
2
2
1
Table 9: Evaluation of chosen MAS development methods
Hence, the software quality assurance must be an element of the MAS development
methodologies itself. Therefore, we present an overview about the situation in the following
table which is only based on the description in the literature that we have considered and thus
can be incomplete.
MAS Development
Methodology
AAII
AAOSA
ABROSE
ADK
Agents in Z
Agent UML
Burmeister
Evaluation of
Software Quality
Quality Aspects
Measurement Usage
(more than Testing)
no
no
no
no
no
yes
no
yes
no
no
no
no
no
no
Metrics Repository or
Experience Factory
no
no
no
no
no
no
no
Table 10: SQA characteristics of some MAS development methodologies
MAS Development
Methodology
Evaluation of
Software Quality
Quality Aspects
Measurement Usage
(more than Testing)
Cassiopeia
no
no
DESIRE
no
yes
Formal Methods of AOSE
no
no
Gaia
no
yes
IMPACT
no
yes
51
Metrics Repository or
Experience Factory
no
no
no
no
no
IMPS
JGram
Kinny/Georgeff
MALINA
MAS-CommonKADS
MaSE
MASSIVE
MStreams
PageSpace
SIM_AGENT
SODA
no
no
no
yes
no
no
no
no
no
no
yes
no
no
yes
no
no
yes
no
no
no
no
no
no
no
no
no
yes
no
no
no
Table 10: SQA characteristics of some MAS development methodologies (Cont.)
In the next two sections we will consider some special techniques of MAS specification,
design and implementation and their characteristics according SQA.
1.3.2 MAS Specification
In the following we will consider some special techniques of agent or MAS specification
which are mostly formally.
[Hennessy 99] uses the Milner’s π-calculus in order to define agents as located threads in a
MAS environment. In [Lumpe 00] a modified form of the π-calculus was used in order to
define the object composition language PICCOLA. Objects are a composition of parallel
running agents which are bundled with some restricted locations that serve as the state of the
object.
As another example of these behaviour description, we will give a short overview about the
characteristics of formal specification of software agents. [Sewell 99] describes a two-level
architecture of mobile agents based on the π-Calculus. The main definitions are
•
the agent creation:
•
the agent migration: migrate to s → P .
agent a = P in Q ,
An example of agent behaviour is given in following without any comments.
agent b =
new d in
iflocal <a> c ! d → 0 else 0
in
c ? x → x!
[Li 00] defines an Information Gathering Agent (IGA) which performs the task of collecting
and filtering information. The IGA should be autonomous, social able, reactive and proactive.
A formal description of an intelligent agent is defined by Hendriks et al. [Hendriks 00]
according to the following definitions:
52
•
An intelligent agent is a tuple 〈a, Π, σ, Γ 〉 where a is the name of the agent, Π ⊆ Goal is
called the goal base, σ ∈ ℒ is called the belief base, and Γ ⊆ Rule is a set of plan rules,
also called the rule base.
•
Let ℬ be a set of basic action symbols with typical elements a, a‘, and ℒ be a first-order
language. The set of goals Goal is defined by:
(1) If a ∈ ℬ and t1, t2, ..., tn ∈ T, then a(t1, t2, ..., tn ) ∈ Goal;
(2) At ∈ Goal;
(3) if ϕ ∈ ℒ, then ϕ ? ∈ Goal; and
(4) if π1, π2 ∈ Goal, then (π1; π2 ), (π1 + π2 ) ∈ Goal.
•
The set of plan rules Rule is defined by: if p(t), π ∈ Goal and ϕ ∈ ℒ, then p(t) ← ϕ |
π ∈ Rule. If p(t) ← ϕ | π is a rule, then p(t) is called the head of the rule, ϕ is called the
guard of the rule, and π is called the body of the rule.
A formal model of specification based on Z is given in [Hilaire 00]. The following example
gives a general impression of this kind of formalisation. We consider the following statebased model of concurrent use of two doors.
DOOR1:
deactivate1/inLL
opened
closed
activate1
DOOR2:
deactivate2/outLL
opened
closed
activate2(someoneInLL)
Figure 46: State-based model of the two doors
Therefore, we can define (in Z) the following system characteristics about this model
described in figure 46 that gives us an impression of the agents specification.
LoadLock
someoneInLL: ℝ
INIT
¬ someonInLL
53
inLL
∆ someoneInLL
someoneInLL’
outLL
∆ someoneInLL
¬ someoneInLL’
¬⋄ (instate(DOOR1.opened) ∧ instate(DOOR2.opened)
Role
behavior
attributes: ℙ Attribute
stimulus: ℙ Event
actions: ℙ Action
Interaction
orig == first roles
dest == second roles
roles: Role × Role
content: Event
∀ e ∈ msg•
(e ∈ (dest.stimulus)
∧ (e ∈ orig.actions))
Organization
behavior
roles: ℙ Role
env: ℙ envRole
interactions: ℙ Interaction
∀ i ∈ interactions • (i.orig ∈ roles ∧ i.dest ∈ roles)
A formal model of co-ordination by [Tolksdorf 00]:
“The system to be co-ordinated is represented by a set of decision variables
V = {v1, ..., vn } with values from a set of domains D = {D1, ..., Dn}. Any coordination process leads to an instantiation x of decision variables from
decision space X. In quantitative formal models, a global utility function U:
X → ℜ is associated with each of these instantiations that models how good
54
the system is co-ordinated. The model can be analysed to find an optimum y
∈ X such that ∀x ∈ X : U(x) ≤ U(y), meaning that there is no instantiation
that provides better co-ordination.
For a qualitative mode, a set D of constraints {C1, ..., Cm} is used. The
notion of a consistent instantiation x of decision variables from decision
space is defined by X as y ⊨ C1 ∧ ... ∧ Cm.”
A formal model of agents as an algebra of itineraries is defined by [Loke 01] as follows. Let
A, O and P be finite sets of agent, action and place symbols, respectively. Itineraries
(denoted by ℑ) are now formed as follows representing the null activity, atomic activity,
parallel, sequential, nondeterministic, conditional nondeterministic behaviour, and have the
the following syntax:
ℑ ::= 0 | Aap | (ℑ || ℑ) | (ℑ ⊕ ℑ ) | (ℑ | ℑ ) | (ℑ :Π ℑ )
where A ∈ A, a ∈ O, p ∈ P, ⊕ is an operator which combines an agent with its clone to form
a new agent, an Π is an operator which returns a Boolean value to model conditional
behaviour. The definitions of Π and ⊕ are application-specific. Especially, the atomic activity
includes the mobility characteristics of the agent A which moved his place to p based on the
(mobile) activity a. The parallel, nondeterministic etc. descriptions are related to the agents
execution in a special manner.
In general, formal definition of agent-based systems can be realised by using the process
algebra. [Peled 01] defines such a system as follows. An agent in process algebra is an
abstract description of a system. Process algebra suggests a syntax for describing agents.
Agents are described as term (just as in first order logic), using operators such as sequential
and parallel composition, and nondeterministic choice. The semantics of process algebra
describes how agents evolve (i.e., process or change) during the computation. In process
algebra, there is usually no explicit notion of a state as a mapping of variables to values. An
agent is itself a representation of a state – after executing an action, an agent evolves into
another agent. As an example of agent description the CCS (Calculus of Communicating
Systems) by Milner [Milner 89] can be used. Let α denote an arbitrary element of the action
set, R denote an action subset, f denote a mapping from actions to actions and C denote an
agent variable. Then the definition of an agent in BNF has the form
agent ::= α.agent | agent + agent | agent || agent | agent \ R | agent[f] | (agent) | C | 0
where ‘+’ stands for agents sequence and ‘||’ for a parallel composition of agents.
Indeed, the conglomerate of formal approaches for agent-based systems in [Meyer 99] is a
typical description of the current situation of heterogeneity in this area. We can establish a lot
of interesting and appropriate formal approaches which are not compatible for a whole formal
model and do not consider the technological aspects of MAS.
Hence, the software quality assurance in MAS specification must include methods or
techniques to keep them. The possibility of evaluation can be realised in the formal
specification languages through
55
•
attributing or parsing based on attributed grammars or meta languages,
•
transformations or relations based on homomorphisms into the emprical data set,
•
tuple extensions of the agent description based on quality characteristics or
metrics.
1.3.3 MAS Design and Implementation
In the following we give some examples of techniques in the design of agent-based systems.
An overview about some design methods is given in [Griss 01].
The SDL diagram can be used as an appropriate modelling technique for multi-agent system
components of input and output. The following figure 47 describes the general architecture of
multi-agent systems by [Ferber 99, p. 211].
Agent A1
Message
routing
unit
Agent A2
. . .
Agent An
Figure 47: Architecture of communicating multi-agent systems
Heinz et al. define an UML-based approach for specifying the agent behaviour [Heinz 00]. He
creates an agent use case as “a collection of scenarios about the agent’s interaction with a
system. Each scenario describes a sequence of events which the agent initiates. ... The
diagrammatic notation for an agent use case is the same for a standard UML use case.”
[Laufmann 98] intends for the development of agent-based systems the implementation of an
model of co-ordination which should be explicit, reusable, minimal size and complexity,
wholly separable and readily extensible.
[Janca 98] defines an agent design model which consists of the following main components
or levels as shown in figure 48.
56
Knowledge
Skills
Interfaces
Figure 48: Agent design model
As a special tool support for agent execution, [Georgeff 98] describes a BDI interpreter as
follows:
initialize_state()
repeat
options := option-generator(event-queue);
selected-options := deliberate(options);
update-intentions(selected-options);
execute();
get-new-external-events();
drop-successful-attitudes();
drop-impossible-attitudes();
end repeat
Yoshioka et al. define secure migration patterns in order to modelling the security aspects of
mobile agents [Yoshioka 01]. These patterns are described as sequence charts.
In order to support the MAS design process, [Deugo 01] defines different types of agent
design patterns which are addressed to the following problems:
1.
2.
3.
4.
5.
Blackboard pattern: to ensure the cohesion of a group of specialised agents,
Meeting pattern: to co-ordinate the agents tasks and mediate their activities,
Market maker pattern: to match up buyers and sellers of goods (services or resources),
Master-slave pattern: to delegate subtasks and co-ordinate their execution,
Negotiating agent pattern: to detect and resolve conflicting intentions between agents,
In [Lind 01] a special diagram called sociogram was created and described in order to explain
the MAS structure for a special situation which is shown in the figure 49 and where T is a set
of partitions of the environment for the agent, D is a database that contains the agent’s
acquired knowledge, and A is a set of possible actions of the agent.
reports to
T
D
A
T
controls
D
A
share resources
57
T
D
A
knows
T
T
D
A
knows
D
A
T
D
A
Figure 49: A sociogram of an MAS structure
Sim and Chan have developed a Testbed for agent-based information brokering systems what
is shown is the following figure [Sim 01].
Seller agent
Buyer agent
Blackboard
Advertisement
Queue
Result Queue
Connection
Queue
Record Agent
Recommendation
Agent
Request
Queue
Broker Agent
Record
Database
E-Mail to potentional
Buyers
WWW
Figure 50: An agent-based information brokering testbed
Examples of agent-based system development tools are (see [Kühnel 01] and [Poggi 01]):
•
AgentBuilder (www.agentbuilder.com),
•
ABE (www.research.ibm.com/iagents/ibm_agents.html),
•
Intelligent Agent Factory (www.bitpix.com/iaf/iafintro/iafintro.htm),
58
•
JACK (www.agent-software.com.au/jack.html),
•
JADE (sharon.cselt.it/projects/jade/)
•
JAFMAS (www.ececs.uc.edu/~abaker/JAFMAS/),
•
JAT (java.stanford.edu/java_agent/html/),
•
Zeus (www.labs.bt.com/projects/agents/research/collaborative.htm).
An overview about vendors of intelligent agent technologies is given in [Guilfoyle 98].
Hence, the software quality assurance in MAS design must include techniques and methods
such as
•
attributing the design languages, components or patterns,
•
integration of the evaluation in the different MAS components by agent roles and
responsibilities,
•
extension of the design tools by measurement and evaluation components,
•
involving of evaluation and measurement techniques in the designed agents or
MAS itself.
In order to characterise the empirical bases for MAS measurement and evaluation, we will
present some experience in the next section.
2 EVALUATION AND MEASUREMENT ASPECTS OF
AGENT-BASED SYSTEMS
2.1 Empirical Aspects of Agent-based Systems
Software agents can be applied to solve new types of problems such as [Jennings 98. p. 6/7]
59
•
•
•
dynamic open systems: the structure of the system itself is capable of changing
dynamically and its components are not known in advance, can change over time, and
may be highly heterogeneous,
complex systems: agents represent a powerful tool for making systems modular which is
one kind of the possibility to create and implement such systems,
ubiquity: agents should be autonomous, proactive, responsive, and adaptive to solve basic
problems in co-operation with the user.
But, we can note that the very nature of the agent-based paradigm leads to a number of
problems such as [Jennings 98, p. 10]
•
•
•
no overall system controller which keep global constraints and avoids livelocks and
deadlocks,
no global perspective related to the whole system or to the complete global knowledge,
trust and delegation of agents seeking guidance during the time that work on their behalf.
Integrating software agents in large-scale systems like cyberspace the following difficulties
[Tambe 00] remain:
1. enabling a software developer to locate and recruit relevant agents in the
distributed cyberspace environment is a key challenge;
2. it is unlikely that the recruited agents were built to work together, so appropriate
interagent co-ordination is difficult; the problem is not only in the potentially
large modifications in an open, distributed environment, the problem is
exacerbated if such modifications must be repeated for each new integration;
3. the integrated system must be made robust despite the uncertainties of the
environment, such as dynamic agent failures or unavailability (or dynamic
availability).
On the other hand, we can defined some essential empirical aspects for the evaluation of
multi-agent systems:
•
•
the volume and structure of an agent environment E,
the position in E of the objects O which are active. The status perceived, created,
destroyed and modified of the objects which are passive,
• the level of the assembly of agents, A, which are specific objects, representing the active
entities of the system,
• the intensity of the relations, R, which link objects (and thus agents) to each other,
• the performance of the operations, Op, making it possible for the agents of A to perceive,
produce, consume, transform and manipulate objects from O,
• the complexity of the operators with the task of representing the application of these
operations and the reaction of the world to this attempt at modifications, which we shall
call the laws of the universe.
Some of the experience of multi-agents systems by [Hayzelden 99] are defined as benefits of
the MAS as:
•
“to address problems that are too large for a centralized single agent, for example
because of resource limitations or for robustness concerns (the ability to recover from
fault conditions or unexpected events);
60
•
to enable the reduction of processing costs - it is less expensive (in hardware terms) to use
a large number of inexpensive processors than a single processor with equivalent
processing power;
to allow for the interconnecting and interoperation of multiple existing legacy systems,
e.g. expert systems, decision support systems, legacy network protocols;
to improve scalability - the organizational structure of the agents can dynamically change
to reflect the dynamic environment - i.e. as the network grows in size the agent
organization can re-structure by agents altering their roles, beliefs and actions that they
perform;
to provide solutions to inherently distributed problems, for example, telecommunications
control, air traffic control and workflow management;
to provide solutions which draw from distributed information sources; and
to provide solutions where the expertise is distributed;”
•
•
•
•
•
A general empirical estimation of the success of agents interaction is described in [Ferber 99,
p. 61] as: “We shall consider an interaction situation as being an assembly of behaviors
resulting from the grouping of agents which have to act in order to attain their objectives,
with attention being paid to the more or less limited resources which are available to them
and to their individual skills.”
A detailed definition of a successful agent interaction is defined by [Ferber 99, p. 62] as: “The
goal of an agent, A, is incompatible with that of another agent, B, if agents A and B have, as
their respective goals to be achieved, the states described by p and q respectively, and if p ⇒
¬ q, that satisfies is: (goal (A, p)) ⇒ ¬ satisfies (goal (B, q)).”
Indicators of a co-operative activity by Bourdon in [Ferber 99, p. 71/72] are:
(1) “the co-ordination of actions, which concerns the adjustment of the direction of agents’
actions in time and space;
(2) the degree of parallelism, which depends on the distribution of tasks and their
concurrent execution;
(3) the sharing of resources, which concerns the use of resources and skills;
(4) the robustness of the system, which concerns the system’s aptitude for making up for
any failure by an agent;
(5) the non-redundancy of actions, which characterises the low rate of redundant activities;
(6) the non-persistence of conflicts, which testifies to the small number of blocking
situations.”
The general characteristics of the agent action and behaviour leads us to the following
general empirical aspects of this kind of agent analysis:
•
•
The action characteristics of performance, complexity and quality based on the different
types of forms of agent actions (transformation, influences, processes, modifications,
displacement and command.
The general types of agents with or without memory and knowledge (tropistic agents
and hysteretic agents).
Finally, we define some empirical characteristics related to the mental state and the minds of
software agents as follows:
•
•
The structure and the complexity of the current multi-agent system (interactional,
representational and conative).
The intensity of the motivation of the different kinds of software agents .
61
•
•
The appropriateness of the commitments of agents related to the general system
intention.
The relationship of the software agent intention to each other.
Based on the short remarks in section 1.2.4, we define some empirical characteristics of agent
co-operation and collaboration:
•
•
•
•
•
The level and intensity of communication between software agents.
The kind and the quality of co-ordination between interacting agents.
The intention of collaboration as the basis of the evaluation of agents efficiency.
The volume and the efficiency of the co-operation.
The increase of the agent facilities and knowledge during the collaboration.
Empirical aspects of agents in telecommunication systems by [Hayzelden 99]: “Although
allocation of resources is a major factor to consider when applying agents to
telecommunications there are many others, including: What communication does the agent
have with other agents - try to minimize inter-agent communication so that action resolution
is reached more rapidly? Where should the agent(s) be located (the agent location
granularity)? One agent per node, one per physical link, one to represent each connection?
Should the agents be stationary or mobile? What view of the network does the agent have (the
agent control granularity)? Is it beneficial to have the agent aware of other indirectly related
events occurring in the agents locality. What degree of dependency should there be between
the agents in the system? If an agent 'dies', is the system still robust?”
2.2 Experiences of the Agent-based System Development
Empirical aspects of the software agent technology by [Hayzelden 99]: “There are a number
of obstacles in the way of the wider take-up of agent technology. Chief among these are the
following:
•
Lack of interoperation standards:
We noted at several points throughout this article that work is underway to develop
communication standards for agent systems - the FIPA initiative is probably the best
known of these. Such standards will be essential if agent technology is to achieve its full
potential. At the time of writing, however, there are several other essentially competing
standards for agent communication under development, including the Knowledge Query
and Manipulation Language (KQML), as well as the ongoing Object Management
Group (OMG) effort to standardize on distributed object technology, and the WorldWide Web consortium's Extensible Markup Language (XML). Experience (in particular,
the OSI experience) suggests that interoperation standards in information technology
cannot be dictated - they tend to emerge and are dictated largely by the marketplace. It
therefore remains to be seen what impact agent interoperation standards such as FIPA
will have, and whether they will indeed lead to a greater take-up of agent technology.
•
Lack of methodologies for agent-based development:
Developing any distributed system is difficult - such systems are amongst the most
complex general class of software systems to design and implement. Multi-agent
systems add to the inherent complexity of distributed systems by having heterogeneous,
62
autonomous components, potentially designed and implemented by many different
individuals and organizations. As a result, the multi-agent systems tend to exhibit
unpredictable non-linear behavior, which can be very hard to understand. In order to
master this complexity, methodologies are required for agent systems that enable a
designer to model and understand multi-agent behavior.
•
Lack of understanding of the fit between system and problem:
Agents have been deployed in many application domains, with very different properties.
One of the most important tasks facing the agent research community is to achieve a
better understanding of the characteristics of an application domain that imply an
agent-based solution is appropriate. Too often, agents are applied to a particular
problem without good reason.”
[Schoder 00] describes the general situation in MAS development in following manner: “In
our view, the technical aspects of mobile agents are not the only aspects requiring close
attention. The real challenges lie in complementary concepts for the (self-) control of
populations of mobile agents, such as multiagent systems, able to provide solutions for
application areas characterized by inherently decentralized information. Coping with all of
these challenges will provide the raison d’être and fulfill the promise of mobile agent
technology.”
Also, [Jennings 98, p. 19] defines an agent development bottleneck in the following manner:
„There is little in the way of production-quality software support for building agent
applications, and still less general understanding of the issues that need to be addressed when
building such systems. Worse, most of today’s agent systems are built from scratch, using
bespoke tools and techniques, which cannot easily be applied to other types of system. This is
particularly worrying because a lot of infrastructure is required before the main components
of an agent system can be built. At the moment, most developers rebuild this infrastructure
from scratch in every new case; this process is clearly not sustainable.“
Finally, we can establish new dynamic architectures, new complex components, and new
distributed design technologies, but also new kinds of problems in the area of software
agents.
2.3 Related Work in Measurement of Software Agent and Agent-Based
Systems
We will consider some of the examples about agents measurement in the literature in the
following. In a first description, we will consider the general experience by [Wooldridge 99]
as
•
Political pitfalls: “Agents are a powerful, natural metaphor for conceptualizing,
designing, and implementing many complex, distributed applications. Some tasks,
however, are simply beyond the scope of automation. Indeed, many of the systems that
have been built using agent technology could likely have been built just as easily with
nonagent techniques.
63
. . . Another form of dogma associated with agents relates to their definition. Most agent
developers have their own opinion on exactly what constitutes an agent – and no two
developers appear to share exactly the same opinion.”
•
Management pitfalls: Managers “don’t know why you want agents”. . . . “Another
common pitfall is devising an architecture or testbed that supposedly enables a whole
range of potential systems to be built when what is actually required is a bespoke design
to tackle a single application.”
•
Conceptual pitfalls: The developers “believe in silver bullets”, . . . “forgot that agents are
software”, and “forgot that agents are multithreaded software.”
•
Analysis and design pitfalls: The designer “ignore related technologies”, . . .their “design
doesn’t exploit concurrency”, and it was “ignore legacy”.
•
Agent-level pitfalls: “You want your own agent architecture. . . . Your agents use too
much AI” or “Your agents use no AI”.
•
Society-level pitfalls: Typical extreme views are: “You see agents everywhere” or “You
have too few agents.” This can leads to “obsessing on infrastructure” and a lacking
system structure where the “agents interact too freely.”
Now, we will cite some kinds of software agent measurement approaches addressed to the
MAS product, MAS developement process, and the underlying resources.
Product measurement and evaluation:
•
Coalition evaluation: [Katoh 00] defines a MAS based on a loose coalition which
represents the relations of co-operation among agents by a function of subjective
information of an agent to another one. This function defines a threshold to evaluate
agents whether it should co-operate or not. The measurement of this kind of coalition
considers dynamic properties such as reliability, ability and busyness and is related to the
agent performance.
•
Co-ordination evaluation: [Tolksdorf 00] gives an order scaled evaluation of the coordination of a MAS based on the characteristics interactor distinction, orthogonality of
the co-ordination model, coupling between interactors, interactor autonomy, externality,
awareness, stability, reliability, scalability and usability.
•
Distributed decision measurement of co-ordination: [Barber 00] considers the five types
of agent co-ordination as arbitration, negotiation, mediation, voting and self-modification.
The different kinds of evaluation of these co-ordination types are based on the effort for
searching an agent, for voting and on the voting effort itself.
•
Load management: [Gustavsson 99] describes a simulation of an auction for load
management based on utility agents and customer agents for energy regulation of
HomeBots.
•
Performance evaluation: [Evans 99] defines some formula to estimate the response time,
the time of delay to notify, delete, create and commit by software agents (see also
[Dikaiakos 01], [Dumke 01], and [Wille 01]).
64
•
RPC performance: Based on the Agent Tcl (a mobile-agent system whose agents can be
written in Tcl, Java and Scheme), [Kotz 97] defines the mobility on RPCs which is created
by an Agent Interface Definition Language (AIDL). On the basis of some prototypes the
RPC performance was measured relating to the client stub time, communication time, and
local call time.
•
Size estimation: [Evans 99] executes the total number of links within a network and
within special region boundaries.
•
Utility evaluation: [Tewari 01] describes a user utility function modelling in order to
improve electronic markets. Implementing a Buyer or Seller Valuation Manager (B/SVM)
is based on some generic utility functions such as (ax ± b) or (ax2 ± bx ±c) where x is a
place-holder variable for a value of the flexible attribute over its permissible range and a,
b, c represent arbitrary, non-negative constants. Tewari and Maes initiate some first
applications of this model.
•
Usability level: [Devlin 01] considers a speech technology agent and uses the two
evaluation methods as MUMMS (Measuring the Usability of Multi-Media Software) and
TAM (Technology Acceptance Model) in order to measure some detailed aspects such as
usefulness, efficiency, helpfulness and learnability.
Process measurement and evaluation:
•
ACL evaluation: [Singh 98] defines some criteria to evaluate agent communication
languages for an appropriate use.
•
Behaviour simulation: The MECCA system [Gerber 99] implements a component to
simulate the agents scenarios and interactions.
•
Modelling of agent-based systems: [Falchuk 98] describes twenty icons for the different
types of software agents and six types for the kinds of interactions for a better usability of
the agent-based system modelling.
•
Reasonableness of agent deriving: [Joshi 98] defines a measure for the reasonableness to
automatically generate exemplars to learn the mapping from a problem to an agent.
Resources measurement and evaluation:
•
MAS platform evaluation: [Ricordel 00] describes an evaluation of different MAS
platforms like AgentBuilder, Jack, MadKit and Zeus based on the evaluation criteria for
the support of the analysis, design and development. Each of these criteria is divided in the
subcriteria completeness, applicability, complexity and reusability.
•
Middleware evaluation: [Poslad 99] describes a (nominal) evaluation of the middleware
aspects in agent-based systems.
•
Paradigm evaluation: [Wong 99] motivates for mobile agent implementation with Java.
65
•
Resource allocation simulation: [Bredin 01] defines a simulation model for the resource
allocation for mobil-agent systems. The simulation is based on a swarm simulation system
and evaluates the effectiveness of resource-allocation of a mobil agent during the
switching different cities.
•
Vendor evaluation: [Guilfoyle 98] gives an overview about the CASE level of vendors
using the agent technology.
2.4 Open Problems and Intentions of Quality Assurance in MAS
In the following we summarise the ideas of consideration of software quality assurance
considerations of MAS and MAS development described in the first chapter (see also [Dumke
97a], [Schneidewind 02], and [Weinberg 92]).
SQA intentions of software agents and MAS:
The software quality assurance of software agents includes the aspects such as the quality of
the capability of acting in an environment, the level of communication with other agents, the
quantities of the driven aspects by a set of tendencies, the characteristics of possessed
resources, the kind of capability of perceiving its environment, the characteristics of the
agent-based partial representation of this environment, the quality of the possessed skills and
offered services, the level of the ability to reproduce itself, the kind of the behaviour towards
satisfying its objectives, taking account of the resources.
The software quality assurance of MAS includes the aspects such as reliability, availability
and usability of the environment, the appropriateness and size of the objects, the structure
and efficiency of the agents communities, the performance of the agents operations, and the
stability of the user interaction with the MAS.
The software quality assurance of agent communication addresses the aspects such as the
level of the communication, the intensity or frequency of the communication, the useroriented semantics of the ACL, the appropriateness of the ACL, and the guarantee of the
conversion principles.
The software quality assurance of agents co-operation must considers the aspects such as the
efficiency of the agents interaction, the level of the co-ordination, the quality of the agent
coupling, the reliability of the agent components, the appropriateness of the kinds of agent
actions, the effectiveness of the agent teams and communities, and the level of successes of the
user goal consideration.
The software quality assurance of agent minds, intentions and negotiation should consider
the aspects such as the level of negotiation, the success rate of negotiations, the effeciency of
the agent roles, the appropriateness of the negotiation strategies, the effectiveness of the BDI
application.
The software quality assurance of agent mobility addresses the aspects such as the
performance of agent movements, the appropriateness of the visited cities, the knowledge
about the requirements and supports of the different cities.
66
The software quality assurance of agent organisations must consider the aspects such as the
appropriateness of the different organisation functions, the level of the different organisation
dimensions, the effectiveness of the interoperations in an agent organisation, the performance
of the agents correlation.
The software quality assurance of MAS architectures addresses the aspects such as the
efficiency of the MAS layers, the reliability of the MAS components, the appropriateness of
the chosen platform, the performance of the co-ordination and planning in the MAS, the
usability of the MAS interface, the effectiveness of the MAS integration, the manageability of
the MAS structure, the appropriateness of the MAS architecture granularity.
SQA intentions of MAS development:
The software quality assurance must be an element of the MAS development methodologies
itself.
Furthermore, the software quality assurance in MAS specification must include methods or
techniques to keep them. The possibility of evaluation can be realised in the formal
specification languages through
•
attributing or parsing based on attributed grammars or meta languages,
•
transformations or relations based on homomorphisms into the emprical data set,
•
tuple extensions of the agent description based on quality characteristics or metrics.
Remarkable, the software quality assurance in MAS design must include techniques and
methods such as
•
attributing the design languages, components or patterns,
•
integration of the evaluation in the different MAS components by agent roles and
responsibilities,
•
extension of the design tools by measurement and evaluation components,
•
involving of evaluation and measurement techniques in the designed agents or MAS
itself.
The concrete methods and techniques of SQA are necessary to be selectable by considering
the current paradigm, the type of MAS application, and the platform requirements.
67
3 AGENT TYPES
The following list includes the kinds or types of software agents cited in this paper with the
reference number as page in this preprint.
A
AAOSA agent, 40
Abstract generic agent, 44
Agent community, 25
Agent design pattern, 55
Agent organisation, 27
Agent training, 44
Agent team, 18
Application agent, 48
Artificial life agent, 4
Autonomous agent, 4, 41
Event identification agent, 38
Expert system agent, 36
Extraction agent, 43
F
Fault isolation agent, 38
Filter agent, 34
Fixed network agent, 33
Frequency stability agent, 38
Fusion agent, 36
Fuzzy logic agent, 36
B
BDI agent, 23, 43
Biological agent, 4
Broker agent, 56
Buyer agent, 20, 56
Buying agent, 20
G
Gateway agent, 48
Generation agent, 38
Genetic algorithm agent, 36
Global processing phase agent, 36
Graphical interaction agent, 35
C
Cell agent, 33
Coarse-grained agent, 30
Cognitive agent, 38
Collaborative agent, 32
Combination agent, 36
Command interpretation agent, 38
Computational agent, 4
Control phase agent, 36
Co-operative agent, 41
Customer agent, 33
H
HCVM media agent, 37
Heterogeneous agent, 5, 12
Hidden failure monitoring agent, 38
Holonic agent, 2
Hybrid agent, 28
I
Individual agent, 5
Inference agent, 43
Info agent, 31
Information gathering agent, 51
Intelligent agent, 30, 51
Intelligent network agent, 31
Intelligent physical agent, 15
Interface agent, 31, 32
Intermediary agent, 20
D
Decision phase agent, 36
Decomposition phase agent, 36
Deliberative agent, 28
Distributed Comm. & Processing agent, 36
Dynamic agent, 13
E
Entertainment agent, 4
Event/alarm filtering agent, 38
K
Kernel agent, 48
68
L
Locator agent, 34
Service supplier agent, 33
Shine agent, 30
Situation monitoring agent, 34
Smart agent, 32
Software agent, 4
Supervised neural network agent, 36
M
MAF agent, 31
Media agent, 36
Middle agent, 18, 31
Mobile agent, 25, 34, 38, 50
Model update agent, 38
T
Task agent, 31
Task specific agent, 4
Telescript agent, 13
Transformation agent, 36
Transaction scheduling agent, 35
N
Network agent, 13
O
Ontology construction agent, 43
U
Upper respiratory decision agent, 36
User interface agent, 29, 48
P
Parent agent, 36
Planning agent, 38
Postprocessing phase agent, 36
Proactive agent, 41
Protection agent, 38
V
Vulnerability assessment agent, 38
X
XML agent, 36
R
Reactive agent, 28
Reconfiguration agent, 38
Record agent, 56
Responsible agent, 32
Restoration agent, 38
Retrieval agent, 34
Risk averse agent, 19
Risk neutral agent, 19
Risk seeking agent, 19
Robotic agent, 4
S
Scheduling processing agent, 35
Scheduling repairing agent, 35
SciAgent, 17
Self organizing agent, 36
Seller agent, 20, 56
Selling agent, 20
Server agent, 43
Service agent, 33
69
4 ACRONYMS
A
AAII
AAOSA
ABE
ABROSE
ABSE
ACML
ACL
ADEPT
ADK
AIDL
AOP
AOSE
AR
ASL
Australian Artificial Intelligence Institute
Adaptive Agent Oriented Software Architecture
Agent Building Environment
Agent-Based Brokerage Services in Electronic Commerce
Agent-Based Software Engineering
Agent Communication Markup Language
Agent Communication Language
Advanced Decision Environment for Process Tasks
AgentBean Development Kit
Agent Interface Definition Language
Agent-Oriented Programming
Agent-Oriented Software Engineering
Agent Relocation
Agent Service Layer
B
BDI
BVM
Belief Desire Intention
Buyer Valuation Manager
C
CA
CCS
COOL
CORBA
Certification Authority
Claculus of Communicating Systems
CO-Ordination Language
Common Object Request Broker Architecture
D
DESIRE
DM
DMARS
DEsign and Specification of Interacting REasoning components
Database Manager
Multi-Agent Reasoning System
E
ECOMAS
Evolutionary Computation and Multi-Agent Systems
F
FIPA
FLBC
FNA
Foundation for Intelligent Physical Agents
Formal Language for Business Communication
Fixed Network Agent
H
HCVM
Human-Centred Virtual Machine
I
IGA
IMPACT
IMPS
Information Gathering Agent
Imperative Maryland Platform for Agents Collaborating Together
Internet-based Multi Agent Problem Solving
J
JADE
Java Agent DEvelopment
70
JADL
JAFMAS
JAT
JDL
JIAC
JIAC Agent Description Language
JAva-based Framework for Multi-Agent Systems
Java Agent Template
JGram Description Language
Java Intelligent Agent Componentware
K
KADS
KB
KBS
KIF
KLAIM
KQML
Knowledge Analysis and Design System
Knowledge Base
Knowledge-Based System
Knowledge Interchange Format
Kernel Language for Agent Interaction and Mobility
Knowledge Query and Manipulation Language
L
LGI
Low-Governed Interaction
M
MA
MadKit
MALINA
MARI
MAS
MaSE
MASIF
MASSIVE
MCC
MCM
MIF
MM
MUMMS
Mobility Assignment
Multi-agent development Kit
Multi-Agent Local Integrated Network Associations
Multi-Attribute Resource Intermediary
Multi-Agent System
Multiagent Systems Engineering
Mobil Agent System Interoperability Facility
Multi-Agent SystemS Iterative View Engineering
Mobolity Conditions Check
Market Cycle Manager
Market Internet Format
Match Maker
Measuring the Usability of Multi-Media Software
O
OHM
OOA
OOD
OOP
OOSE
ORB
Optimisation Heuristic Manager
Object-Oriented Analysis and specification
Object-Oriented Design
Object-Oriented Programming
Object-Oriented Software Engineering
Object Request Broker
P
PDA
PICCOLA
PLACA
PRS
Personal Digital Assistent
Pi Calculus based Composition LAnguage
PLAnning Communication Agents language
Procedural Reasoning System
R
RATSINA
RPC
Reusable Task Structure based Intelligent Network Agents
Remote Procedure Call
71
S
sACL
SDL
SI
SNMP
SODA
SQA
SVM
small ACL
Specification and Design Language
Static Infrastructure
Simple Nedtwork Management Protocol
Societies in Open and Distributed Agent spaces
Software Quality Assurance
Seller Valuation Manager
T
TAM
Technology Acceptance Model
U
UIM
UML
UNM
USM
User Interface Manager
Unified Modeling Language
User Notification Manager
User Status Manager
V
VFG
VFT
Valuation Function Generalizer
Valuation Function Trainer
3APL
An Abstract Agent Programming Language
72
5 MAS WEB LINKS
We will give a presentation about some of the plenty of Web sites related to software agents
divided in general information, systems and projects.
URLs to general information about software agents:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
http://www.agent.org/
http://www.agentcom.org/agent.com/
http://cui.unige.ch/tios/msgr/agents/overview.html
http://ivs.cs.uni-magdeburg.de/~dumke/STV/ST3-06.html
http://www.cs.bham.ac.uk/~amw/agents/index.html
http://www.irisa.fr/prive/sahai/
http://www.media.mit.edu/~nelson/research/routes-coopagents/
http://www.sics.se/ps/abc/survey.html
http://www.compinfo.co.uk/tpagnt.htm
http://www.informatik.th-darmstadt.de/~fuenf/work/agenten/agenten.html
http://www.ai.iit.nrc.ca/subjects/Agents.html
http://www.cs.wpi.edu/Research/airg/Agents-hotlist.html
http://www.Agent-Link.org
http://www.csee.embc.edu/aw/
URLs about agents implementation languages:
•
•
•
•
•
•
•
•
AgentBuilder Framework: http://www.agentbuilder.com/
Agent-Tcl: http://www.cs.dartmouth.edu/~agent/agenttcl.htm
KQML: http://www.cs.umbc.edu/kqml/papers/
Obliq: http://www.research.digital.com/SRC/personal/Luca_Cardelli/Obliq/Obliq.html
Python: http://www.python.org/
Safe-Tcl: http://www.smli.com/research.tct
Scheme-48: http://photo.net/~jar/s48.html
Telescript: http://www.genmagic.com/Telescript/Whitepaper/wp4/whitepaper-4.html
URLs about agent-based system development and standards:
•
•
•
•
•
•
•
•
•
•
•
•
•
FIPA specifications: http://www.fipa.org/
Grashopper platform: http://www.ivk.de/
IBM Aglets: http://www.trl.ibm.co.jp/aglets/
Java-to-go: http://ptolemy.eecs.berkeley.edu/~wli/group/java2go/java-to-go.html
JAFMAS toolkit: http://www.esecs.uc.edu/~abaker/JAFMAS
JATLite toolkit: http://java.standford.edu/
JINI framwwork: http://java.sun.com/products/jini/index.html
MARI: http://www.media.mit.edu/gtewari/MARI/
OMG standards: http://www.omg.org/
SE: http://www.cs.vu.nl/~treur/SIG.meth0.html
SIM-Agent: ftp://ftp.cs.bham.ac.uk/pub/dist/poplog/
Voyager: http://www.pts.com/voyager.cfm
WinWin model: http://sunset.usc.edu/WinWin/winwin.html
URLs about agent-based systems:
•
•
•
•
•
AgentBuilder: http://www.agentbuilder.com/
AgentCAC (control for ATM network): http://www.elec.qmw.ac.uk/dai/projects/ agentCAC/
Assistant systems: http://lieber.www.media.mit.edu/people/lieberary/letizia/letizia.mov
BT Mobile agents for routing: http://www.labs.bt.com/library/papers/
Cooperation systems: http://www.firefly.com
73
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
CyberAgent: http://www.ftp.com/cyberagents/
ECOMAS: http://www.csm.uwe.ac.uk/~rsmith/ECOMAS/agent_toolkit_list_(courtesi_of_bt).htm
E-Commerce: http.//www.shopfido.com/, http://www.jango.com, http://b5www.berkom.de/ ABROSE/
Frictionless ValueShopper: http://compare.frictionless.com/
HP 'Ants based routing: http://www-uk.hpl.hp.com/
HP Market based control: http://www.hpl.hp.com/techreports/98/
Jack: http://www.agent-software.com.au/
MadKit: http://www.madkit.org/
Meta browser: http://www.metacrawler.com/, http://meta.rrzn.uni-hannover.de
NetChaser: http://osweb.iit.unict.it/ARCA/
News watcher: http://www.backweb.com/, http://www.pointcast.com/
Personalogic: http://www.personalogic.com
PYTHIA: http://www.cs.purdue.edu/research/cse/pythia/
Retrievel agents: http://www.verity.com/
Tele-MACS: http://www.agentcom.org/agentcom/
Telescript-based definition of personell shares portfolios: http://www.genmagic.com/
TINA-C homepage: http://www.tinac.com/
Zeus: http://www.labs.bt.com/projects/agents/zeus/
URLs about projects relating to software agents:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
ABROSE project: http://b5www.berkom.de/ABROSE/
ACT IMPACT project: http://www.acts-impact.org/impact/
DFG, Germany: http://www.wirtschaft.tu-ilmenau.de/wi/wi2/ECAT2000-AOSM/
dMARS project: http://www.aaii.oz.au/proj/dMARS-prod-brief.html
Eurescom project: http://www.euroescom.de/public/Projects/
MAGNA Project: http://www.fokus.gmd.de/oks/research/magna_e.html
MAS in Project Management: ftp://fireflow.com/Agent98.zip
MIT Media Lab: http://agents.www.media.mit.edu/groups/agents/
Stanford University: http://logic.stanford.edu/
Tacoma (Norway/U.S.A.): http://www.cs.uit.no/DOS/Tacoma/
University of Kaiserslautern: http://www.uni-kl.de/AG-Nehmer/Ara/
University of Potsdam: http://samuel.cs.uni-potsdam.de/soft/taxt/home.html#mission
WARREN project: http://www-2.cs.cmu.edu/~softagents/warren.html
WebCrawler: http://info.webcrawler.com/mak/projects/robots/robots.html
URLs about software agent related conferences and communities:
•
•
•
•
•
•
•
AgentLink: http://www.agentlink.org/newsletter/
Agent Systems in the ECBS: http://www.agentlink.org/
Agents 2000: http://www.iiia.csic.es/agents2000/
Canadian workshop: http://www.acs.ucalgary.ca/~wshen/workshop1.htm
DAI Digest: http://www.cs.cmu.edu/~softagents/DAIlist/
Overview: http://www.csee.embc.edu/aw/Conferences_and_workshops/index.shtml
UMBC AgentNews: http://agents.umbc.edu/agentnews/
74
6 REFERENCES
[Agha 01] Agha, G.; Jamali, N.; Varela, C.: Agent Naming and Coordination: Actor Based Models and
Infrastructures. In: [Ominici 01], pp. 225-246
[Aïmeur 01] Aïmeur, E.: Strategic Use of Conflicts in Tutoring Systems. In [Tessier 01], pp. 223-250
[Arnold 99] Arnold, K.; O’Sullivan, B.; Scheifler, R. W.; Waldo, J.; Wollrath, A.: The Jini Specification.
Addison Wesley Publ., 1999
[Barber 00] Barber, K. S.; Han, D. C.; Liu, T. H.: Coordinating Distributed Decision Making Using Reusable
Interaction Specification. In: Zhang/Soo: Design and Applications of Intelligent Agents, Lecture Notes in
Artificial Intelligence 1881, Springer Publ. 2000, pp. 1-15
[Barbosa 01] Barbosa, G. P.; Silva, F. Q. B.: An Electronic Marketplace Architecture Based on Technology of
Intelligent Agents and Knowledge. In [Liu 01], pp. 39-58
[Barbuceanu 00] Barbuceanu, M.; Lo, W.: Conversation Oriented Programming for Agent Interaction. In:
[Dignum 00], pp. 220-234
[Basili 86] Basili, V. R. et al.: Experimentation in Software Engineering. IEEE Transactions on Software
Engineering, 12(1986)7, pp. 733-743
[Bauer 01] Bauer, B.; Müller, J. P.; Odell, J.: Agent UML: A Formalism for Specifying Multiagent Software
Systems. In: [Ciancarini 01], pp. 91-103
[Bellavista 01] Bellavista, P.; Magedanz, T.: Middleware Technologies: CORBA and Mobile Agents. In:
[Ominici 01a], pp. 110-152
[Bradshaw 01] Bradshaw, J.M. et al.: Terraforming Cyberspace. IEEE Computer, July 2001, S. 48-56
[Brazier 99] Brazier, F.; Dunin-Kepliz, B.; Treur, J.; Verbrugge, R.: Modelling Internal Dynamic Behaviour of
BDI Agents. In [Meyer 99], pp. 36-56
[Bredin 01] Bredin, J.; Kotz, D.; Rus, D.; Maheswaran, R. T.; Immer, C.; Basar, T.: A Market-Based Model for
Resource Allocation in Agent Systems. In: [Ominici 01a], pp. 426-442
[Brenner 98] Brenner, W. et al.: Intelligente Softwareagenten – Grundlagen und Anwendungen. Springer Publ.,
1998
[Bryce 01] Bryce, C.; Cremonini, M.: Coordination and Security on the Internet. In [Ominici 01a], pp. 274-298
[Bush 00] Bush, G.; Purvis, M.; Cranefiled, S.: Experience in the Development of an Agent Architecture. . In:
Zhang/Soo: Design and Applications of Intelligent Agents, Lecture Notes in Artificial Intelligence 1881,
Springer Publ. 2000, pp. 76-87
[Busuioc 99] Busuioc, M. N.: Distributed Intelligent Agents – A solution for the Management of Complex
Telecommunications Services. In [Hayzelden 99, S. 112-129]
[Cabri 00] Cabri, G.; Leonardi, L.; Zambonelli, F.: Context-Dependency in Internet-Agent Co-ordination. . In:
Omicini/Tolksdorf/Zambonelli: Engineering Societies in the Agent World, Lecture Notes in Artificial
Intelligence 1972, Springer Publ. 2000, pp. 51-63
[Case 01] Case, S.; Azarmi, N.; Thint, M.; Ohtani, T.: Enhancing E-Communities with Agent-Based Systems.
IEEE Computer, July 2001, S. 64-69
[Ciancarini 01] Ciancarini, P.; Wooldridge, M. J.: Agent-Oriented Software Engineering. Springer Publ., 2001
[Cockayne 97] Cockayne, W.; Zyda, M.: Mobile Agents. Manning Publ., 1997 (see also
http://www.manning.com/Cockayne/)
[Collins 01] Collins, J. et al.: Decision Processes in Agent-Based Automated Contracting. IEEE Internet
Computing, March/April 2001, S. 61-72
[Darbyshire 00] Darbyshire, P.; Lowry, G.: An Overview of Agent Technology and its Application to Subject
Management. Proc. of the IRMA International Conference, Anchorage, Alaska, May 21-24, 2000, pp.
509-512
[Devlin 01] Devlin, M.; Scott, T.: Using a Speech Technology Agent as an Interface for E-Commerce. In [Liu
01], pp. 332-346
[Deugo 01] Deugo, D.; Weiss, M.; Kendall, E.: Reusable Patterns for Agent Coordination. In: [Ominici 01], pp.
347-368
[Dignum 00] Dignum, F.; Greaves, M.: Issues in Agent Communication. Lecture Notes in Computer Science
1916, Springer Publ., 2000
[Dikaiakos 01] Dikaiakos, M.D.; Samaras, G.: Performance Evaluation of Mobile Agents: Issues and
Approaches. In: Dumke et al.: Performance Engineering, Lecture Notes in Computer Science 2047, pp.
148-166
[Divitini 01] Divitini, M.; Hanachi, C.; Sibertin-Blanc, C.: Inter-Organizational Workflows for Enterprise
Coordination. In: [Ominici 01], pp. 369-398
[Drashansky 99] Drashansky, T.; Houstis, E. N.; Ramakrishnan, N.; Rice, J. R.: Networked Agents for Scientific
Computing. Comm. of the ACM, 42(1999)3, pp. 48-54
[Dumke 97] Dumke, R.; Foltin, E.: Metrics-based Evaluation of Object-Oriented Software Development
Methods. Preprint Nr. 10, Otto-von-Guericke University of Magdeburg, 1997
75
[Dumke 97a] Dumke, R., R.; Grigoleit, H.: Usefulness of CAME tools in software quality assurance. in Hawkins
et a.: Software Quality Management, MEP Publ., London, pp. 291-303
[Dumke 00] Dumke, R.; Koeppe, R.; Wille, C.: Software Agent Measurement and Self-Measuring Agent-Based
Systems. Preprint Nr. 11, Fakultät für Informatik, Otto-von-Guericke-Universität Magdeburg, 2000
[Dumke 00a] Dumke, R.; Schmietendorf, A.; Stojanov, S.: Komponentenorientierte Entwicklung verteilter
Multiagenten-Applikationen. Tagungsband des 2. Workshop komponentenorientierte betriebliche
Anwendungssysteme (WKBA 2), Februar 2000, Wien, S. 69-79
[Dumke 01] Dumke, R.; Wille, C.: Performance Engineering für Software-Agenten. Tagungsband des 2.
Workshop Performance Engineering, 26.4.01, München, S. 33-46
[Durfee 01] Durfee, H.E.: Scaling Up Agent Coordination Strategies. IEEE Computer, July 2001, S. 39-46
[Evans 99] Evans, R. et al.: A Multi-Agent System Architecture for Scalable Management of High Performance
Networks: Applying Arms Length Autonomy. In [Hayzelden 99, pp. 86-111]
[Falchuk 98] Falchuk, B.; Karmouch, A.: Visual Modeling for Agent-Based Applications. IEEE Computer,
December 1998, pp. 31-38
[Ferber 99] Ferber, J.: Multi-Agent Systems – An Introduction to Distributed Artificial Intelligence. Addison
Wesley Publ., 1999
[Finin 94] Finin, T.; Weber, J.; Wiederhold, G.; Genesereth, M.: Specification of the KQML AgentCommunication Language. The DARPA Knowledge Sharing Initiative External Interfaces Working
Group, University of Toronto, 1994
[Freeman 99] Freeman, E.; Hupfer, S.; Arnold, K.: JavaSpaces – Principles, Patterns, and Practice. Addison
Wesley Publ., 1999
[Fricke 01] Fricke, S.; Bsufka, K.; Keiser, J.; Schmidt, T.; Sesseler, R.; Albayrak, S.: Agent-Based Telematic
Services and Telecom Applications. Comm. of the ACM, 44(2001)4, pp. 43-48
[Georgeff 98] Georgeff, M.; Rao, A.: Rational Software Agents: From Theory to Practice. In: [Jennings 98, pp.
139-160]
[Gerber 99] Gerber, C. et al.: Resource Adaptation for a Scalable Agent Society in the MoTiV-PTA Domain. In
[Hayzelden 99, pp. 183-206]
[Glushko 99] Glushko, R. J.; Tenenbaum, J. M.; Meltzer, B.: An XML Framework for Agent-based E-commerce.
Comm. of the ACM, 42(1999)3, pp. 106-114
[Greaves 00] Greaves, M.; Holmback, H.; Bradshaw, J.: What Is a Conversation Policy? In. [Dignum 00], pp.
118-131
[Griss 01] Griss, M.L.; Pour, G.: Accelerating Development with Agent Components. IEEE Computer, May
2001, S. 37-43
[Grosof 00] Grosof, B. N.; Labrou, Y.: An Approach to Using XML and a Rule-Based Content Language with an
Agent Communication Language. In: [Dignum 00], pp. 96-117
[Guilfoyle 98] Guilfoyle, C.: Vendors of Intelligent Agent Technologies: A Market Overview. In [Jennings 98,
pp. 91-104]
[Gustavsson 99] Gustavsson, R.: Agents with Power. Comm. of the ACM, 42(1999)3, pp. 41-47
[Hattori 99] Hattori, F.; Ohguro, T.; Yokoo, M.; Matsubara, S.; Yoshida, S.: Socialware: Multiagent System for
Supporting Network Communities. Comm. of the ACM, 42(1999)3, pp. 55-61
[Haugeneder 98] Haugeneder, H.; Steiner, D.: Co-operating Agents: Concepts and Applications. In: [Jennings
98], pp. 175-202
[Hayzelden 99] Hayzelden, A.L.G.; Bigham, J.: Software Agents for Future Communication Systems. Springer
Publ., 1999
[Heinz 00] Heinz, C.; Papasimeon, M.; Goss, S.: Specifying Agent Behavior with Use Cases. . In: Zhang/Soo:
Design and Applications of Intelligent Agents, Lecture Notes in Artificial Intelligence 1881, Springer
Publ. 2000, pp. 128-142
[Hendriks 00] Hendriks, K. V.; de Boer, F. S.; van der Hoek, W.; Meyer, J. C.: Semantics of Communication
Agents Based on Deduction and Abduction. In [Dignum 00], pp. 63-79
[Hennessy 99] Hennessy, M.; Riely, J.: Type-Safe Execution of Mobile Agents in Autonomous Networks. In:
Vitek/Jensen: Secure Internet Programming, LNCS 1603, Springer Publ., 1999, pp. 95-115
[Hilaire 00] Hilaire, V.; Koukam, A.; Gruer, P.; Müller, J.: Formal Specification and Prototyping of Multi-agent
Systems. . In: Omicini/Tolksdorf/Zambonelli: Engineering Societies in the Agent World, Lecture Notes in
Artificial Intelligence 1972, Springer Publ. 2000, pp. 114-127
[Huhns 01] Huhns, M., N.: Interaction-Oriented Programming. In: [Wooldridge 01], pp. 29-44
[Huhns 98] Huhns, M. N.; Singh, M. P.: Managing Heterogeneous Transaction Workflows with Co-operating
Agents. In: [Jennings 98], pp. 219-239
[Jain 99] Jain, A. K.; Aparicio IV, M.; Singh, M. P.: Agents for Process Coherence in Virtual Enterprises.
Comm. of the ACM, 42(1999)3, pp. 62-69
[Janca 98] Janca, P. C.; Gilbert, D.: Practical Design of Intelligent Agent Systems. In: [Jennings 98, pp. 73-89]
[Jennings 01] Jennings, N.R.: An Agent-Based Approach for Building Complex Software Systems. Comm. Of the
ACM, 44(2001)4, S. 35-41
76
[Jennings 98] Jennings, N. R.; Wooldridge, M. J.: Agent Technology – Foundation, Applications, and Markets.
Springer Publ., 1998
[Jeon 00] Jeon, H.; Petrie, C.; Cutkosky, M. R.: JATLite: A Java Agent Infrastructure with Message Routing.
Internet Computing, March/April 2000, pp. 87-96
[Joshi 98] Joshi, A.; et al.: Multiagent system support of networked scientific computing. Internet Computing,
May/June 1998, pp. 69-83
[Jung 01] Jung, M.; Tambe, M.: Conflicts in Agent Teams. In [Tessier 01], pp. 153-168
[Katoh 00] Katoh, T.; Kinoshita, T.; Shiratori, N.: Dynamic Properties of Multiagent Based on a Mechanism of
Loose Coalition. . In: Zhang/Soo: Design and Applications of Intelligent Agents, Lecture Notes in
Artificial Intelligence 1881, Springer Publ. 2000, pp. 16-30
[Kearney 98], Kearney, P.: Personal Agents: A Walk on the Client Side. In: [Jennings 98, pp. 125-136
[Kendall 01] Kendall, E. A.: Agent Software Engineering with Role Modelling. In: [Ciancarini 01], pp. 163-169
[KIF 98] Knowledge Interchange Language: http://logic.stanford.edu/kif/kif.html
[Klusch 01] Klusch, M.; Sycara, K.: Brokering and Matchmaking for Coordination of Agent Societies: A Survey.
In: [Ominici 01a], pp. 197-224
[Knapik 98] Knapik, M.; Johnson, J.: Developing Intelligent Agents for Distributed Systems. McGraw-Hill, 1998
[Koblick 99] Koblick, R.: Concordia. Comm. Of the ACM, 42(1999)3, pp. 96-99
[Koshla 00] Koshla, R.; Sethi, I. K.; Damiani, E.: Intelligent Multimedia Multe-Agent Systems – A Human
Centered Approach. Kluwer Academic Publishers, 2000
[Kotz 97] Kotz, D.; Gray, R.; Nog, S.; Rus, D.; Chwala, S.; Cybenko, G.: AGENT TCL: Targeting the Needs of
Mobile Agents. Internet Computing, July/August 1997, pp. 58-66
[Kühnel 01] Kühnel, R.: Agentenbasierte Softwareentwicklung. Addison-Wesley Publ., 2001
[Lange 98] Lange, D. B.; Oshima, M.: Programming and Developing Java Mobile Agents with Aglets. AddisonWesley Publ., 1998
[Labrou 97] Labrou, Y.; Finin, T.: A Proposal for a new KQML Specification. University of Maryland Baltimore
County, 1997 (http://www.cs.umbc.edu/kqml/)
[Laufmann 98] Laufmann, S.C.: Agent Software for Near-Term Success in Distributed Applications. In:
[Jennings 98, pp. 49-69]
[Li 00] Li, T.; Seng, C.; Lam, K.: A Secure Route Structure forInformation Gathering Agent. . In: Zhang/Soo:
Design and Applications of Intelligent Agents, Lecture Notes in Artificial Intelligence 1881, Springer
Publ. 2000, pp. 101-114
[Lind 01] Lind, J.: Iterative Software Engineering for Multiagent Systems. LNAI 1994, Springer Publ., 2001
[Liu 01] Liu, J.; Ye, Y.: E-Commerce Agents – Marketplace Solutions, Security Issues, and Supply and Demand.
LNAI 2033, Springer Publ., 2001
[Loke 01] Loke, S. W.; Zaslavski, A.: Towards Distributed Workflow Enactment with Itineraries and Mobile
Agent Management. In [Liu 01], pp. 283-294
[Lumpe 00] Lumpe, M.; Ackermann, F.; Nierstrasz, O.: A Formal Language for Composition. In:
Leavens/Sitaraman: Foundations of Component-Based Systems, Cambridge Press, 2000, pp. 69-90
[Maes 94] Maes, P.: Agents that Reduce Work and Information Overload. CACM, 37/1994)7, pp. 84-86
[Maes 99] Maes, P.; Guttman, R. H.; Moukas, A. G.: Agents That Buy and Sell. Comm. of the ACM, 42(1999)3,
pp. 81-91
[Massoud 00] Massoud, A.: Toward Self-Healing Infrastructure Systems. IEEE Computer, August 2000, pp. 4453
[Meyer 99] Meyer, J. C.; Schobbens, P.: Formal Models of Agents. LNAI 1760, Springer Publ., 1999
[Miles 01] Miles, S.; Joy, M.; Luck, M.: Designing Agent-Oriented Systems by Analysing Agent Interactions. In:
Wooldridge/Ciancarini: Agent-Oriented Software Engineering, Lecture Notes in Computer Science 1957,
Springer Publ., 2001, S. 171-183
[Milner 89] Milner, R.: Communication and Concurrency. Prentice Hall Publ., 1989
[Moore 00] Moore, S. A.: On Conversation Policies and the Need for Exceptions. In: [Dignum 00], pp. 144-159
[Moro 00] Moro, G.; Viroli, M.: On Observing and Constraining Active Systems. In:
Omicini/Tolksdorf/Zambonelli: Engineering Societies in the Agent World, Lecture Notes in Artificial
Intelligence 1972, Springer Publ. 2000, pp. 34-50
[Müller 01] Müller, J.: Konzeption und prototypische Implementation einer Qualitätsbewertung für
agentenbasierte Softwaresysteme am Beispiel der Software-Aglets. Diplomarbeit, Universität Magdeburg,
2001
[Murch 00] Murch, R.; Johnson, T.: Agententechnologie: Die Einführung. Addison Wesley Publ., 2000
[Nicola 00] Nicola, R. de; Ferrari, G.; Pugliese, R.: Types as Specifications of Access Policies. In:
Leavens/Sitaraman: Foundations of Component-Based Systems, Cambridge Press, 2000, pp. 117-146
[Nwana 98] Nwana, H. S.; Ndumu, D. T.: A Brief Introduction to Software Agent Technology. In: [Jennings 98],
pp. 29-47
[Nwana 99] Nwana, H. S.; Ndumu, D. T.: Agents of Change in Future Communication Systems. In: [Hayzelden
99], pp. 58-85
77
[Odell] Odell, J. J.; Parunak, H. v. D.; Bauer, B.: Representing Agent Interaction Protocols in UML. In:
[Ciancarini 01], pp. 121-140
[Ominici 01] Ominici, A.: SODA: Societies and Infrastructures in the Analysis and Design of Agent-Based
Systems. In: [Ciancarini 01], pp. 185-193
[Ominici 01a] Ominici, A.; Zambonelli, F.; Klusch, M.; Tolksdorf, R.: Coordination of Internet Agents –
Models, Technologies, and Applications. Springer Publ., 2001
[Papadopoulos 01] Papadopoulos, G. A.: Models and Technologies for the Coordination of Internet Agents: A
Survey. In: [Omicini 01a], pp. 25-56
[Papazoglou 01] Papazoglou, M.P.: Agent-Oriented Technology in Support of E-Business. Comm. of the ACM,
44(2001)4, S. 71-77
[Parunak 00] Parunak, H. van D.; Brueckner, S.; Sauter, J.; Matthews, R.S.: Distinguishing Environmental and
Agent Dynamics: A Case Study in Abstraction and Alternate Modeling Technologies. In: Ominici et al.:
Engineering Societies in the Agent World. Lecture Notes in Artificial Intelligence 1972, Springer Publ.,
2000, S. 19-33
[Peled 01] Peled, D. A.: Software Reliability Methods. Springer Publ., 2001, p. 215 ff.
[Petrie 01] Petrie, C.: Agent-Based Software Engineering. In. [Ciancarini 01], pp. 59-75
[Phillips 00] Phillips, L. R.; Link, H. E.: The Role of Conversation Policy in Carrying Out Agent Conversations.
In: [Dignum 00], pp. 132-143
[Pitt 00] Pitt, J.; Mamdani, A.: Communication Protocols in Multi-agent Systems: A Development Method and
Reference Architecture. In: [Dignum 00], pp. 160-177
[Pitt 00a] Pitt, J.; Mamdani, A.: Some Legal Aspects of Inter-agent Communication: From the Sincerity
Condition to ‘Ethical’ Agents. In: [Dignum 00], pp- 46-62
[Poggi 01] Poggi, A.; Rimassa, G.: Adding Extensible Synchronization Capabilities to the Agent Model of a
FIPA Compliant Agent Platform. In: [Ciancarini 01], pp. 307-321
[Poslad 99] Poslad, S. et al.: Agent-Oriented Middleware for Integrating Customer Network Services. In
[Hayzelden 99], pp. 221-246
[Preist 99] Preist, C.: Economic Agents for Automated Trading. In [Hayzelden 99], pp. 207-219
[Romão 01] Romão, A.; Mira da Silve, M.: Secure Mobile Agent Digital Signature with Proxy Certificates. In
[Liu 01], pp. 206-220
[Ricordel 00] Ricordel, P.; Demazeau, Y.: From Analysis to Deployment: A Multi-agent Platform Survey. In:
Ominici et al.: Engineering Societies in the Agent World. Lecture Notes in Artificial Intelligence 1972,
Springer Publ., 2000, S. 93-105
[Rossi 01] Rossi, D.; Cabri, G.; Denti, E.: Tuple-based Technologies for Coordination. In: [Ominici 01a], pp.
83-109
[Sandholm 00] Sandholm, T.; Huai, Q.: Nomad: Mobile Agent System for an Internet-Based Auction House.
Internet Computing, March/April 2000, pp. 80-86
Schneidewind 02] Schneidewind, N. F.: Body of Knowledge for Software Quality Measurement. IEEE
Computer, February 2002, pp. 77-83
[Schoder 00] Schoder, D.; Eymann, T.: The Real Challenges of Mobile Agents. Comm. Of the ACM, 43(2000)6,
pp. 111-112
[Sewell 99] Sewell, P. et al.: Location-Independent Communication for Mobile Agents: A Two-Level
Architecture. In: Bal/Cardelli: Internet Programming Languages. LNCS 1686, Springer Publ., 1999, pp.
1-31
[Shehory 01] Shehory, O.: Software Architecture Attributes of Multi-agent Systems. In: [Ciancarini 01], pp. 7790
[Sim 01] Sim, K. M.; Chan, R.: A Brokering Protocol for Electronic Trading. In [Liu 01], pp. 83-105
[Singh 98] Singh, M. P.: Agent Communication Languages: Rethinking the Principles. IEEE Computer, , Dec.
1998, pp. 40-47
[Singh 00] Singh, M. P.: A Social Semantics for Agent Communication Languages. In: [Dignum 00], pp. 31-45
[Sloman 99] Sloman, A.; Logan, B.: Building Congitively Rich Agents Using the SIM_AGENT Toolkit. Comm.
of the ACM, 42(1999)3, pp. 71-77
[Solingen 99] Solingen, v. R.; Berghout, E.: The Goal/Question/Metric Method. McGraw Hill Publ., 1999
[Stefano 00] Stefano, A. di, Santoro, C.: NetChaser: Agent Support for Personal Mobility. Internet Computing,
March/April 2000, pp. 74-79
[Stojanov 96] Stojanov, S.: A Multi-Agent System for the Solution of Statistical Problems. Workshop
“Concurrency, Specification and Programming”, 25-27.09.1996, Berlin, 181-189.
[Stojanov 98] Stojanov, S.; Kumurdjieva, M.: MASTT-Technology and Its Application in Electronic Commerce
Systems. Workshop “Concurrency, Specification & Programming”, September 28-30 1998, Berlin
[Stojanov 00] Stojanov, S.; Kumurdjieva,M.; Dimitrov, E.; Schmietendorf, A.: Technologicak Framework for
Development of Agent-based Applications, Workshop "Concurrency, Specification & Programming",
October 9-11 2000, Berlin, 299-311
78
[Stojanov 00a] Stojanov, S., Ganchev, I. A multi-agent technology for creating of information systems for
electronic commerce, Second South Eastern European Conference on e-commerce, 24-26 October 2000,
Sofia, 92-96
[Sun 00] Sun, R.; Qi, D.: Rationality Assumption and Optimality of Co-Learning. In: Zhang/Soo: Design and
Applications of Intelligent Agents. Lecture Notes in Artificial Intelligence, Springer-Verlag, 2000, S. 6175
[Tambe 00] Tambe, M.; Pynadath, D. V.; Chauvat, N.: Building Dynamic Agent Organizations in Cyberspace.
Internet Computing, March/April 2000, pp. 65-73
[Tessier 01] Tessier, C.; Chaudron, L.; Müller, H.: Conflicting Agents – Conflict Management in Multi-Agent
Systems. Kluwer Academic Publisher, 2001
[Tessier 01a] Tessier , C.; Müller, H.; Fiorino, H.; Chaudron, L. : Agents’ Conflict: New Issues. In [Tessier01],
pp. 1-30
[Tewari 01] Tewari, G.; Maes, P.: A Generalized Platform for the Specification, Valuation, and Brokering of
Heterogeneous Resources in Electronic Markets. In: [Liu 01], pp. 7-24
[Thuraisingham 01] Thuraisingham, B.: Web Data Management and Electronic Commerce. CRC Press, 2000
[Tolksdorf 00] Tolksdorf, R.: Models of Coordination. . In: Omicini/Tolksdorf/Zambonelli: Engineering
Societies in the Agent World, Lecture Notes in Artificial Intelligence 1972, Springer Publ. 2000, pp. 7892
[Umeda 00] Umeda, Y.; Yamashita, M.; Inagaki, M.; Sawamura, H.: Argumentation as a Social Computing
Paradigm. . In: Zhang/Soo: Design and Applications of Intelligent Agents, Lecture Notes in Artificial
Intelligence 1881, Springer Publ. 2000, pp. 46-60
[Valera 01] Valera, F.; Vergara, J. E. L. de; Moreno, J. I.; Villagra, V. A.; Berrocal, J.: Communication
Management Experiences in E-Commerce. Comm. of the ACM, 44(2001)4, p. 63-69
[Vidahl 01] Vidahl, J.M.; Buhler, P.A.; Huhns, M.N.: Inside an Agent. IEEE Internet Computing, Jan./Febr.
2001, S. 82-86
[Vongkasem 00] Vongkasem, L.; Chaib-draa, B.: ACL as a Joint Project between Participants: A Preliminary
Report. In: [Dignum 00], pp. 235-248
[Weinberg 92] Weinberg, G., M.: Quality Software Management. Vol. I and II, Dorset House Publ., New York,
1992
[Wille 01] Wille, C.; Dumke, R.; Stojanov, S.: Performance Engineering in Agent-Based Systems – Concepts,
Modelling and Examples. In Dumke/Abran: Current Trends in Software Measurement. Shaker Publ.,
Aachen, Germany, 2001, pp. 153-181
[Wohlin 00] Wohlin, C. et al.: Experimentation in Software Engineering: An Introduction. Kluwer Academic
Publ., 2000
[Wong 99] Wong, D.: et al.: Java-Based Mobile Agents. CACM, 42(1999)3, pp. 92-105
[Wood 01] Wood, M.F.; DeLoach, S.A.: An Overview of the Multiagent Systems Engineering Methodology. In:
Ciancarini/Wooldridge: Agent-Oriented Software Engineering, Lecture Notes in Computer Science 1957,
Springer-Verlag, 2001, S. 207-221
[Wooldridge 01] Wooldridge, M. J.; Ciancarini, P.: Agent-Oriented Software Engineering: The State of the Art.
In: Ciancarini/Wooldridge: Agent-Oriented Software Engineering, Lecture Notes in Computer Science
1957, Springer-Verlag, 2001, S. 1-28
[Wooldridge 99] Wooldridge, M. J.; Jennings, N. R.: Software Engineering with Agents: Pitfalls and Pratfalls.
Internet Computing, May/June 1999, pp. 20-27
[Yoshida 00] Yoshida, S,; Kamei, K.; Ohguro, T.; Kuwabara, K.; Funakoshi, K.: Building a Network Community
Support System on the Multi-agent Platform Shine. . In: Zhang/Soo: Design and Applications of
Intelligent Agents, Lecture Notes in Artificial Intelligence 1881, Springer Publ. 2000, pp. 88-100
[Yoshimura 00] Yoshimura, K.; Rönnquist, R.; Sonenberg, L.: An Approach to Specifying Coordinated Agent
Behavior. . In: Zhang/Soo: Design and Applications of Intelligent Agents, Lecture Notes in Artificial
Intelligence 1881, Springer Publ. 2000, pp. 115-127
[Yoshioka 01] Yoshioka, N.; Tahara, Y.; Ohsuga, A.; Honiden, S.: Security for Mobile Agents. In: [Ciancarini
01], pp. 223-234
[Zacharia 01] Zacharia, G.; Evgeniou, T.; Moukas, A.; Boufounus, P.; Maes, P.: Economics of Dynamic Pricing
in a Reputation Brokered Agent Mediated Marketplace. In: [Liu 01], pp. 25-38
79