Formal Framework for Adaptive Multi-Agent Systems
Wenpin Jiao, Minghui Zhou, and Qianxiang Wang
Institute of Software, Faculty of Information Science and Technology
Peking University, Beijing 100871, China
{jwp, zhmh, wqx}@cs.pku.edu.cn
Abstract
Evolution of software challenges multi-agent systems
to be adaptive and the adaptation capabilities should be
provided at both the agent level and the system level. In
this paper, we study the adaptation of multi-agent systems
from the system level and describe a formal framework
for multi-agent systems with adaptation capabilities. In
the framework, agents are indirectly inter-connected via
roles and interaction protocols are defined as entities
independent of agents and roles. Thus agents, roles, and
interaction protocols involved in multi-agent systems
need not always adjust their behaviors or specifications
to adapt to the changes of system structures and
interaction protocols.
1. Introduction
With the widespread of the Internet, software systems
become more and more open and dynamic. Not only the
structures and the behaviors of software systems are
evolving all the time. For instance, in multi-agent systems,
agents may join in (or withdraw from) the systems timely;
which may result in the evolution of structures; and
meanwhile interactions among agents may change
dynamically, which will be reflected in the evolution of
the behaviors of agents. These dynamic characteristics
challenge multi-agent systems to be adaptive and flexible.
For a multi-agent system, adaptation represents the
ability of the multi-agent system to recognize and
response to unanticipated internal and external dynamics,
which is a key capability for the system to improve and
adjust its behavior to the evolution.
In [16], evolutions are classified into two categories,
knowledge and structure evolution. From the point of
view of agents involved in a dynamic evolving multi-agent
system, evolutions are actually about changing of agents
themselves and their environment.
• Evolution of individual agents. This category of
evolution is usually reflected via the change of the
internal states of agents or services provided by
agents.
• Evolution of the system. This category of evolution
may impact the behaviors of more than one agent.
For instance, when the system’s structure evolves,
the interaction destinations of agents may be altered
correspondingly. When interaction protocols
change, the order and content of message sequences
transmitted between agents may need to be
redefined.
To adapt to the evolution, multi-agent systems should
make some adjustments or changes correspondingly, such
as re-organizing, adding/removing agents, redefining
interaction protocols, and altering services provided by
agents.
For component-based systems, [11] surveys a
collection of requirements for component adaptation such
as transparency, flexibility, language independence, etc.
From our perspective, a multi-agent system with good
adaptability should at least satisfy the following criteria
while adjusting its structure or behavior.
1) Transparency. Some special kinds of adaptations of
agents should be transparent to other agents. For
instance, other agents need not to be concerned with
an agent’s internal adjustment if the adjustment does
not affect the agent’s external behavior. If
interaction protocols among agents are fixed, the
adaptation of join, withdrawal, or replacement of an
agent should not put impacts on the behaviors of
other agents involved in the interaction protocols,
i.e., other agents need not adjust their behaviors if
roles they are adhered to do not altered.
2) Impact localization. If the adaptation does not result
in the re-organization of the whole system’s
organizational structure, the behaviors of agents
who are not related with the adaptation should be
unaffected.
Currently, there has been much research on agent
adaptability [5][7][8][12][14][18]. To embody adaptation
in a multi-agent system, the techniques they used are
usually based on machine learning or decision-making [3],
but many of them are focused on centralized processes to
formulate models or strategies. Meanwhile, there has also
been much practice on developing adaptive agents. For
example, in [21], a component-based design technique is
used to build adaptive agents. However, most of research
work is mainly concerned with the adaptation of
individual agents.
We believe that adaptation should be provided at both
the agent level and the system level and further that
adaptation at the system level will minimize the impact of
system level adjustments on individual agents.
In this paper, we study the adaptation of multi-agent
systems from the organizational level, where multi-agent
systems are viewed as organizations comprised of agents.
• We employ a type of dynamic role-filling
mechanism to model organizational adaptation, in
which abstract protocols are defined on roles and
agents interact via playing roles. Thus if roles
involved in the organization are not altered, the join,
withdrawal, or replacement of agents will not affect
the behaviors of other agents.
• Meanwhile, we define interaction protocols as
entities independent of roles and agents. Then
agents need not to adjust their behavior
specifications even if interaction protocols have
changed.
To describe the adaptation framework for multi-agent
systems, we use a variant of the standard pi-calculus, the
polyadic pi-calculus [17]. In the pi-calculus, it allows link
names to be sent and received as values, which is very
suitable for describing software with dynamic
configurations. In particular, in the polyadic pi-calculus,
both single names and tuples can be sent along links,
which provides powerful means of defining abstractions
of pi-calculus processes and checking type compatibilities
of parameters. Thus, the pi-calculus can be used to model
dynamic changing agents and multi-agent systems and the
polyadic pi-calculus can act as a formalism to describe
interaction protocols involving at least two participants
simultaneously.
In the pi-calculus, there are only two kinds of entities:
processes and channels, where processes are active
components of a system and they communicate with each
other through ports (or names) connected via channels. In
the pi-calculus, all of data, channels and variables are
names. The processes in the pi-calculus have the
following forms.
P ::= ∑i∈I π i • Pi
|
P |Q
|
!P
|
(νx ) P
|
[ x = y ]P
π ::= x( y ) | x y | τ
Where, I is a finite set and summation ∑i∈I π i • P
represents that one of these I processes will be selected to
execute according to the outside environment and when I
= ∅ we mark ∑i∈I π i • P as 0, which is inert. x( y ) and x y
represent that name y will be input/output along channel x,
respectively, whereas τ represents a silent action. P | Q
represents the parallel composition of two processes of P
and Q. When P = x( y ) • P' and Q = xz • Q ' , the parallel
composition of these processes may synchronize on x and
then yield the derivative P ' { z y} | Q ' , where P ' { z y} means
all free occurrences of y in P will be replaced by z. The
above parallel computation can be represented via the
z ( y )|zz
reduction rule as x ( y ) • P | xz • Q 
→ P ' { z y} | Q ' . ! P
represents any number of copies of P. (νx) P represents
introducing a new channel x with scope P, where v is the
constriction operator. [ x = y ]P represents that process P
will proceed if x and y are the same channel, where [x = y]
is the matching operator.
The main features of the polyadic pi-calculus different
from the (monadic) pi-calculus are that prefixes x( y ) and
x y are defined on vectors and that the forms for
abstractions and concretions are added. We use x , y , …
to stand for vectors of names, with length | x |, | y |, … .
The standard form for an abstraction F can be represented
as follows.
def
F = (λ x ) P
And the standard form for a concretion C can be
represented as follows.
def
C = (ν y )[ x ]P ( y ⊆ x )
The arity of the abstraction F or concretion C is just the
length of the vector x in its standard form.
Then pseudo-application F•C of an abstraction to a
concretion, in which F and C have equal arity, can be
defined as follows.
F ⋅ C def
= (ν z )( P{ y x} | Q )
where x ∩ z = φ and | x | = | y | .
In the following sections, Section 2 describes the core
conceptual model of the framework for multi-agent
systems and some concepts related to the model. And then
Section 3 formally defines the framework and its
components. In Section 4, we study two examples of
multi-agent systems, in which one is with a dynamic
configuration and the other confronts with different
interaction protocols. In the last section, we discuss some
of related work and conclude our work.
2. Concepts
2.1. Agent
By now, there is no common accepted agent definition.
However, an agent can generally be considered as an
active communicating entity, which has many features,
such as autonomy, pro-activity, and social ability, and can
provide services via interactions with other agents or the
environment [9][15].
2.2. Role
In multi-agent systems, the role focuses on the position
and responsibilities of an agent within an overall structure
or system [13]. A role can be characterized as a collection
of responsibilities, permissions, and interaction protocols.
Every role involved in a multi-agent system must be
handled by at least one agent. And each agent can play
one or more roles [9][10].
2.3. Interaction Protocol
An interaction protocol indicates what roles are
involved in the interaction, how they interact with each
other step by step, and what content they transmit while
interacting. While implementing their responsibilities via
cooperation, roles must adapt at least one interaction
protocol.
2.4. Core Conceptual Model
The core conceptual model for our adaptive multiagent systems is shown in figure 1.
Agent
To handle role
Role Assignment Manager
To be assigned
Role
To participate in IP
Interaction Protocol
Manager
To involve roles
Interaction
Protocol
Figure 1. The core conceptual model for adaptive
multimulti-agent systems
In the model, there are some new features.
• We define a Role Assignment Manager (RAM) for
linking agents and roles together, i.e., agents are
related to roles via RAM.
• The Interaction Protocol Manager (IPM) is
dedicated to gather all participant roles involved in
an interaction protocol and guarantee that all
required participants of the protocol are present. To
achieve this, once an initiator role notifies IPM that
it is to initiate an interaction protocol IPM will
notify all of other participants to join in the
execution of the protocol. By assistance of IPM,
roles do not even need to know who their
interaction destination roles are.
• Traditionally, an interaction protocol is a property
pertained to roles using it to interact with each other
and there should be an implementation existed in
every participant simultaneously. Thus the change
of an interaction protocol may result in the changes
of the behavior specifications of all participants. In
our conceptual mode, interaction protocols are
parted from roles and agents. Roles and agents need
not implement any concrete interaction protocols
but just define references to the interaction
protocols, and thus no matter how the interaction
protocols evolve, the changes will not affect the
behavior specifications of roles or agents.
• There are no direct connections or interactions
among agents, i.e., agents interact with each other
indirectly via roles and interaction protocols
attached to the roles.
• Agents are only concerned with what roles they are
playing and interacting. They need not care about
how roles interact with other roles via interaction
protocols and what agents are playing their
interlocutor roles. Thus, they need not modify their
behavior specifications even if the agents who are
playing the interlocutor roles are altered.
To simplify the analysis of the adaptation of systems, we
require the model satisfying the following constraints.
• A role must be played by some agent. Thus, if there
exist a role and an agent playing the role, when the
agent withdraws from the system, there must be
another agent taking the place of the withdrawn
agent to handle the role.
• One role has only one responsibility and uses only
one interaction protocol.
• If an interaction protocol is used by two different
groups of roles, there should be two instances of the
protocol. For simplicity, we would rather consider
the two instances as two different interaction
protocols. Thus, every use of an interaction protocol
has a corresponding entity and a unique
identification.
3. Formal Framework of Adaptive MultiAgent Systems
In this section, we will formalize those components
occurring in the conceptual model in the polyadic picalculus and then use them to form a formal definition for
multi-agent systems with adaptation. While defining the
pi-calculus processes, we let a1, a2, … range over
identifications of agents, r1, r2, … represent roles, and p1,
p2, … denote interaction protocols. Then prefixes such as
a(x), r(x), p and their co-names have the following
denotations.
• a (r ) denotes that agent a plays role r and a(x) is to
query which role agent a plays.
• r (a ) means that role r is played by agent a and r (x)
is to query by which agent role r is played.
• p is used in the initiator role to activate protocol p
whilst p is used in other roles to respond the run of
the protocol.
• Conventionally, s is like a pointer to a Service
provided by an agent and s is the reference to the
pointer. Similarly, z is like a pointer to an Action
defined by an interaction protocol and z is the
reference to the pointer.
3.1. The Role Assignment Manager (RAM)
The responsibilities of RAM include:
• To assign roles to agents.
• To answer queries about what role an agent is
handling.
Formally, suppose that RAM assigns r1 to a1, r2 to a2, and
so on1, RAM can be defined as the following pi-calculus
process.
RAM =!a1 (r1 ) |!a 2 (r2 ) | 3.2. The Interaction Protocol Manager (IPM)
IPM is to gather all participants to execute an
interaction protocol when the interaction protocol is
requested to run by the initiator role.
Suppose the interaction protocol p1 is one of the
protocol managed by IPM and it involves N participants,
r1, r2, …, rN. Then IPM can be formally defined as a
polyadic pi-calculus process, in which a concretion of the
interaction protocol process is included, as follows.
IPM =!( p1 ⋅ p1 p1 ⋅ [ r1 r2 rN ]τ ) | N −1
Intuitively, IPM always waits for a request from the
initiator role (via p1) to activate the protocol and once it
receives that request it will notify other participants (via
p1 ) to take part in running the protocol. At last, when
IPM is sure that all participants are present and ready, it
will activate the protocol through the concretion
[r1r2 m rN ]τ .
3.3. Agents
In our formal model, agents are to play roles and
provide services to implement the responsibilities of roles,
and agents need not care about how to interact with other
agents, which is decided by roles they play.
Suppose there is an agent a to provide a series of
services such as S1, S2, …Sn and each service will be used
to implement a responsibility of some role. Then to
provide services via roles, the agent should know first
what roles it plays and then how the services and
responsibilities are linked together. Agent a can be
formally defined as the following pi-calculus process.
A = (v x, s )a( x1 ) ⋅ x1 ( s1 ) ⋅ s1 ⋅ S1 | where the agent first obtains the role assigned by RAM
1
Usually, an agent may play more than one role, i.e., several roles may
be assigned to a single agent. The agent may obtain more than one
answer simultaneously when an agent queries what role it plays. To
solve this problem, we can assign an agent more than one identification
and let each one identification be corresponded to only one role.
and then outputs a pointer to a service via x1 to the role it
plays. The pointer to the service will be connected to the
responsibility of the role.
3.4. Roles
In our framework, a role, which can be played by
agents many times sequentially, is composed of three
components.
• A responsibility which will be implemented as a
service provided by an agent.
• An interaction protocol used while fulfilling its
responsibility. Since an interaction protocol usually
involves several participants among whom there
must exist a participant acting as the initiator to
initiate the run of the protocol, the role must be
identified as either the initiator or the responder of
the protocol.
• Actions related to the interaction protocol.
Suppose that role r will be involved in an interaction
protocol, p, and acts as the initiator of the protocol (or the
first party involved in the protocol). Then role r can be
formally defined as the following pi-calculus process.
R = ((vx)r ( x) ⋅ x | p ⋅ !Step) ⋅ R
Step = zι
where the role first obtains the agent appointed to play it
by RAM and then gets the pointer to a service to
implement its responsibility. Meanwhile, the role notifies,
via p , IPM to activate the interaction protocol p and then
waits for instructions of interactions step by step from the
interaction protocol. zι is used to get a pointer to the
interaction instruction of next step from the interaction
protocol.
And if role r just acts as a normal participant instead of
the initiator of the protocol, role r can be formally defined
as follows.
R = ((vx)r ( x) ⋅ x | p ⋅ !Step) ⋅ R
Step = z j
where the subscript j occurring in z j indicates that role r
is the jth (j > 1) party involved in the protocol.
3.5. Interaction Protocols
An interaction protocol must be related to and run by
roles, and similarly, the interaction protocol can be
instantiated many times sequentially. Suppose the
interaction protocol p involves N participants, r1, r2, …,
rN, in which r1 acts as the initiator, and M steps. Then the
protocol can be formally defined as an abstraction of a
polyadic pi-calculus process.
P = (v x)(λ x)( Step1 ⋅ Step 2 ⋅ m ⋅ Step m ) ⋅ P
(| x |= n)
Step j = z ι ⋅ Act1 j | z 2 ⋅ Act 2 j | m | z n ⋅ Act nj
(1 ≤ j ≤ m)
where each step of the protocol defines a collection of
actions and by referring to the pointers (i.e., zι, z2, …), the
protocol tells each participant how to act respectively2
3.6. Multi-Agent Systems
By combining all components described in the
conceptual model, we can formally define a multi-agent
system as a composition process of those pi-calculus
processes defined previously.
Suppose there are N roles involved in the multi-agent
system, M (M ≤ N) agents to play these roles, and K (K ≤
N/2) interaction protocols related with the roles. Then the
system can be defined as follows.
MAS = A1 |…| Am | RAM | R1 |…| Rn | IPM | P1 |…| Pk
4. Case Studies
4.1. Agent-Based Fault-Tolerate System Based on
Client/Server Architecture
In such a system, to prevent the system from going
down because of the primary server’s failures, a backup
(or secondary) server is always engaged in and ready for
taking the place of the primary server to provide services
once the primary server dies due to its failures. Figure 2
shows the dynamics of the system’s configuration.
The Primary
Server
The Primary
Server
Client
Client
The Backup
Server
The Backup
Server
Figure
Figure 2. Dynamic configuration
configurations
onfigurations of the C/S system
when the primary server is alive or down
In this system, there are generally three main entities
(agents), a client, a primary server, and a backup server.
• The client requests services from the servers. From
the point of view of the client, it does not care who
replies its requests provided that its requests can be
always satisfied.
2
Generally, a role involved in an interaction protocol not only
communicates with other roles through the actions specified by the
protocol but also possesses internal computations. To define internal
computations of a role and combine those computations with
communications, we can modify the definitions of roles and interaction
protocols by adding pointers to the computations in the definition of
roles and references to the pointers in the definition of protocols
(Suppose the role is the ith (i > 1) party involved in the protocol.).
,
and
R = ((vx) r ( x) ⋅ x | p ⋅ ! Step | c ⋅ Comput | c ⋅ Comput | l) ⋅ R
i1
1
i2
2
P = (v x)(λ x)( Step1 ⋅ Step 2 ⋅ l ⋅ Step m ) ⋅ P
(| x |= n)
Step j = z ι ⋅ c1 j ⋅ Act1 j | z 2 ⋅ c 2 j ⋅ Act 2 j | l | z n ⋅ c nj ⋅ Act nj
(1 ≤ j ≤ m)
, where
cij is a pointer to an internal computation and cij is a reference to the
pointer.
• For the primary server, it may go down at any time
while providing services and go up again once it
recovers and is ready for responding requests.
• For the backup server, it will take the place of the
primary server when the primary server goes down
and abdicate its responsibility to let the primary
server be engaged in providing services when the
primary server goes up.
In addition, we define a special agent to monitor the states
of the two servers, especially the primary server’s states of
being going down or up.
• The monitor is always on-line and monitoring the
current state of the primary server. The monitor will
notify the backup server to join in or withdraw from
the system when it notices that the primary server
has been down or up.
To simplify the formalization of the system, we assume
that no matter when the primary server or the backup
server goes up into the system, the primary (or backup)
server will always start from a new round of run of the
interaction protocol. Thus some of requests of the client
may be unprocessed and lost when the primary server
goes down.
Correspondingly, there are two main roles involved in
the system, a client and a server, and the interaction
protocol used between the client and the servers is based
on request/reply mode.
Then the agents, the roles, the interaction protocol, and
the system can be defined formally in the polyadic picalculus respectively.
4.1.1. Agents. There are four agents, the client, the
primary server, the backup server, and the monitor,
involved in the system and they are formally defined
respectively as follows.
The Client = (vx, s )c( x) ⋅ x( s ) ⋅ s ⋅ Request
The Primary Server = (vx, s ) ps ( x) ⋅ x( s ) ⋅ s ⋅ Service | down | up
The Backup Server = psdead ⋅ (vx, s )bs ( x) ⋅ x( s ) ⋅ s ⋅ Service
The Monitor =!(down ⋅ psdead ⋅ TheBackupServer | up ⋅ ThePrimaryServer )
When the primary server goes down (e.g., the primary
server process generates the signal “DOWN” through
down ), the monitor will notify the backup server to start
to take the place of the primary server to provide services
(e.g., making the backup server be aware that the primary
server is dead via psdead ). And when the primary server
recovers from failures and sends out the signal “UP” via
up , the monitor will wake up the primary server process
and the backup server will leave the stage automatically.
4.1.2. Roles. There are two roles, a client and a server,
occurring in the system.
Client = ((vx)client ( x) ⋅ x | r 2 protocol ⋅ !CStep ) ⋅ Client
CStep = zι
Server = ((vx) server ( x) ⋅ x | r 2 protocol ⋅ ! SStep ) ⋅ Server
=
TheClient | up | (vx, s)bs ( x) ⋅ x( s ) ⋅ s ⋅ Service | TheBackupServer |
up ⋅ ThePrimaryServer | TheMonitor |
SStep = z 2
RAM | Client | Server | IPM | R 2 Protocol
4.1.3. Interaction Protocol. There is only one interaction
protocol between the two roles of client and server, by
which the client requests services from the server and the
server provides services. Then the interaction protocol
between the client and the server, R2Protocol, in which the
client acts as the initiator, can be defined formally as
follows.
R 2 Protocol = ((vx1 , x 2 )(λx1 , x 2 )( Step1 ⋅ Step 2 )) ⋅ R 2 Protocol
Step1 = (vx) z ι ⋅ request ( r ) | z 2 ⋅ requst ( x)
Step 2 = (vy) z ι ⋅ reply ( y ) | z 2 ⋅ reply (a )
where the client first sends out a request to activate the
run of the protocol and then the server returns the answer
once after it receives the request and generates the answer
for replying the request.
4.1.4. RAM and IPM. In the system, the client will play
the role of client, and either the primary server or the
backup server will handle the role of server.
RAM =!c(client ) |! ps ( server) |!bs ( server)
The IPM is responsible for running only one protocol in
the system.
IPM =!( r 2 protocol ⋅ r 2 protocol ⋅ [c, s ]τ )
4.1.5. Multi-Agent System. At last, the multi-agent
system can be defined as a composition of all component
processes described above.
MAS = TheClient | ThePrimary Server | TheBackupS erver |
TheMonitor | RAM |
Client | Server | IPM | R 2 Protocol
4.1.6. Analysis. In this system, because the primary server
may go down unexpectedly, the configuration of the
system may change dynamically.
1. At first, the backup server is engaged in providing
services in the system.
MAS
=
=
TheClient | ThePrimary Server | TheBackupServer |
Note that ps(x) has be substituted with bs(x), which
means the backup server will be assigned the role of
server.
3. When the primary server goes up, it will generate
the signal “UP” through up . The backup server will
automatically withdraw from the system to give the
way to the primary server. Before the primary server
starts to provide services, it will wait for the backup
server to finish replying the client’s request.
=
TheClient | TheBackupS erver | ThePrimary Server | TheMonitor |
RAM | Client | Server | IPM | R 2 Protocol
Then with the primary server’s going down and up, the
system evolves dynamically and returns to its original
configuration eventually.
In this case, the client and the interaction protocol are
not affected during the change of the system’s
configuration, i.e., the adjustment of the system to adapt
to the configuration’s dynamics is transparent to the client
and the interaction protocol.
To adjust the system to be a fault-tolerate one, we
defined a new agent, the monitor. As we have noticed, the
adding of the monitor only affected the definitions of the
primary server and the backup server; and for those
entities not directly related to the two server agents, such
as the Client, the R2Protocol, and the two roles, the
adjustment of adding did not impact their definitions.
4.2. Password-based Authentication System
To be authenticated and admitted to enter such a
system, a user should provide his user-name and
password. The system usually involves two roles, a user
and a server, and a login protocol to ask the user to
provide his user-name and password.
Suppose that the login procedure requires the user to
input his user-name and password in two sequential steps.
Then the interaction protocol can be defined as follows.
TheMonitor | RAM | Client | Server | IPM | R 2 Protocol
LoginProtocol1 = ((vx1 , x 2 )(λx1 , x 2 )( Step1 ⋅ Step 2 )) ⋅ LoginProtocol1
TheClient | (vx, s) ps( x) ⋅ x( s ) ⋅ s ⋅ Service | down | up |
Step1 = (vx) z ι ⋅ usrname(usr ) | z 2 ⋅ usrname( x)
TheBackupServer |
down ⋅ psdead ⋅ TheBackupServer | up ⋅ ThePrimaryServer |
TheMonitor | RAM | Client | Server | IPM | R 2 Protocol
2. When the primary server goes down, it will generate
the signal “DOWN” through down . Then the
monitor will activate the backup server via port
psdead and the backup server will handle the role
of server. If the primary server dies, the request of
the client will be discarded if it has not been
processed by the primary server yet.
Step 2 = (vy) z ι ⋅ passwd ( pwd ) | z 2 ⋅ passwd ( y )
Now, let us consider the following change of the system.
Assume that the old server was replaced and the new
server adapts a new login procedure which requires the
user to enter user-name and password in one step. To
minimize the impact on agents involved in the system, we
can redefine the login protocol as follows.
LoginProtocol 2 = ((vx1 , x2 )(λx1 , x2 ) Step1 ) ⋅ LoginProtocol 2
Step1 = (vx, y ) z ι ⋅ login(usr , pwd ) | z 2 ⋅ login( x, y )
Furthermore, even if the server requires the user to enter
user-name and password sequentially in two steps and
then processes them at once, we need just modify the
protocol as follows.
LoginProtocol3 = ((vx1 , x2 )(λx1 , x2 ) Step1 ⋅ Step2 ) ⋅ LoginProtocol 3
Step1 = zι ⋅ usrname(usr ) | z 2 ⋅ τ
Step2 = (vx, y) zι ⋅ passwd ( pwd ) |
usrname( x) ⋅ passwd ( y ) ⋅ login( x, y ) | z 2 ⋅ login( x, y )
where the new protocol is responsible for combining username with password and then transferring the combination
to the server.
Since the interaction protocol is independent of agents
and roles and the change of the protocol does not affect
the number of the participants, any other components in
the system need not adjust their behaviors or be redefined
to adapt to the change of the protocol.
5. Conclusions
To develop flexible complex systems, we must cope
with rapid and unforeseeable change of software systems
themselves and their environment. Nowadays, many
researches have focused on the adaptations of software
systems and many methods and frameworks have been
proposed from different perspectives to model and design
systems.
However, most of research work is processing in the
field of component-based software development
[1][2][4][6][19][20]. For example, in [1], the authors
explore an approach, embodied in an implementation
language for software architecture, to aid in the
development and evolution of ubiquitous computing
systems. When using the language to express software
architectures, programmers can define custom connectors,
which are useful in many different contexts and can be
used to implement ubiquitous computing applications. In
[2], the authors address the problem concerning dynamic
architectures, in which composition of interacting
components changes during the computations of the
systems, and they provide a modeling approach
combining description of both dynamic aspects and
steady-state behavior of a system at the architectural level
while maintaining a separation of concerns. To model a
fault-tolerant client-server system as we have done in the
first example, the authors define a Configuror to achieve
the changes to the architectural topology. The Configuror
is something like the Monitor defined in our example, but
its definition is more complex by far then that of the
Monitor. Furthermore, to compose the fault-tolerate
system with the Configuror, both the components (e.g.,
the client and the servers) and the connector among the
components have to be redefined in order to interact with
the Configuror properly. [4] presents a formal
methodology for adapting components with mismatching
interaction behavior. To connect two components
together, an adaptor is defined and specified as a mapping
between actions and parameters of the two components.
However, this methodology is designed specially for the
situation that each of two components has got an
implementation of the same interaction protocol. When an
interaction protocol changes, both components and the
adaptor have to be redefined and implemented.
Differently, in our framework, interaction protocols are
independent entities and their change does not demand
that agents or roles modify their specifications.
In this paper, we studied the adaptation of multi-agent
systems starting from the system level. Once a multi-agent
system is with the capability of adaptation, entities
(including agents, roles, and interaction protocols)
involved in the system need not always adjust their
behaviors and specifications to adapt to the changes of the
system.
• In our formal framework for multi-agent systems,
agents are only connected with roles and
responsible for providing services to implement the
responsibilities of roles. Thus any changes
occurring in some agents will not put impacts on
other agents’ behaviors.
• When the global structure of a system changes (e.g.,
the first case shows a multi-agent system with
dynamic configurations), an agent (e.g., the client)
need not adjust its behavior if the role that agent is
playing is not affected by the change of the system’s
structure. Furthermore, an interaction protocol need
not be modified if roles connected with the protocol
are not altered.
• Agents and interaction protocols need not be
concerned with the adding or removal of an agent
because the adding or removal of the agent will not
impact roles involved in multi-agent systems.
• Interaction protocols in our formal framework are
independent entities and roles supposed to be
involved in need not enclose implementations of
interaction protocols. Thus the changes of
interaction protocols are isolated from and
transparent to agents and roles and will not affect
the behavior specifications of agents and roles.
Nevertheless, in our current adaptation framework for
multi-agent systems, we do not take the adaptation and
internal computation capabilities of individual agents into
consideration. At next stage, we will study to blend the
two level adaptations into a uniform framework and
further explore the properties of the framework.
References
[1]. Aldrich, J., Sazawal, V., Chambers, C., and Notkin, D.
Architecture-Centric Programming for Adaptive Systems. In
proceedings of ACM SIGSOFT Workshop on Self-Healing
Systems (WOSS'02), Charleston, SC, November 2002.
[2]. Allen, R., Douence, R., and Garlan, D. Specifying and
Analyzing Dynamic Software Architectures, Lecture Notes in
Computer Science 1382, 1998, pp: 21-37.
[3]. Barber, K. S., Goel, A., and Martin, C. E. Dynamic adaptive
autonomy in multiagent systems. Journal of Experimental and
Theoretical Artificial Intelligence, Vol.12, No.2, pages 129-147,
2000.
[4]. Bracciali, A., Brogi, A., and Canal, C. Systematic
component adaptation. Electronic Notes in Theoretical
Computer Science, Vol. 66, No.4, 2002.
[5]. Brazier, F. M. T., and Wijngaards, N. J. E. Automated
servicing of agents. AISB journal, Vol.1, No.1, 2001, pp: 5-20.
[6]. Charra O. and Senart A. Adaptable and extensible bindings
in distributed environments In Proceedings of the 4th European
Research Seminar on Advances in Distributed Systems
(ERSADS'2001), Bertinoro, Italy. May 2001, pp: 239-244.
Intelligence (eds. G. M. P. O'Hare and N. R. Jennings), Wiley,
1996, pp:187-210.
[13]. Kendall, E. A. Agent Roles And Role Models: New
Abstractions For Intelligent Agent System Analysis And Design.
In Proceedings of the 1999 ACM SIGPLAN conference on
Object-oriented programming, systems, languages, and
applications, Colorado, US, ACM Press, 1999, pp.353-369.
[14]. Klein, M. Supporting conflict resolution in cooperative
design systems. IEEE Transactions on Systems, Man, and
Cybernetics, 21(6), 1991. pp:1379-1390.
[15]. Letier E. and van Lamsweerde A. Agent-based tactics for
goal-oriented requirement elaboration. Proceedings ICSE’2002,
24th International Conference on Software Engineering, ACM
Press, May 2002.
[7]. Decker, K. and Sycara, K. Intelligent adaptive information
agents. Journal of Intelligent Information Systems, No. 9, 1997,
pp. 239 – 260.
[16]. Marcenac, P. and Calderoni, S. Self-organization in agentbased simulation, in Poster Proceedings of the 8th European
Workshop of Modelling Autonomous Agents in a MultiAgent
World, Eds. Magnus Boman, Walter Van de Velde and Staffan
Hägg, Ronneby, Sweden, May 1997, pp. 116-131.
[8]. Fatima, S. S. and Uma, G. An Adaptive Organizational
Policy for Multi Agent Systems --- AASMAN. In Proceedings
of the Third International Conference on Multi-Agent Systems,
ICMAS'98, Paris, France: IEEE Computer Society. 1998,
pp:120-127.
[17]. Milner, R. The polyadic π-calculus: A tutorial. In W.
Brauer, F.L. Bauer and H. Schwichtenberg, editors, Logic and
Algebra of Specification. Springer-Verlag, 1993.
[9]. Ferber, J. and Gutknecht, O. A meta-model for the analysis
and design of organizations in multi-agent systems. Third
International Conference on Multi-Agent Systems (ICMAS ’98)
Proceedings. IEEE Computer Society, 1998.
[10]. Ferber, J., Gutknecht, O., Jonker, C., Muller J., and Treur
J. Organization Models and Behavioural Requirements
Specification for multi-Agent System. In Proc. of the ECAI
2000 Workshop on Modelling Artificial Societies and Hybrid
Organizations. 2000.
[11]. Heineman, G. T. An Evaluation of Component Adaptation
Techniques, 2nd Annual Workshop on Component-Based
Software Engineering, Los Angeles, CA., May 1999.
[12]. Jennings, N. R. Coordination Techniques for Distributed
Artificial Intelligence, in Foundations of Distributed Artificial
[19]. Tambe, M. Towards flexible teamwork. Journal of
Artificial Intelligence Research (JAIR), 7, 1997, pp.83--124.
[20]. Tambe, M., Pynadath, D. V., and Chauvat, N. Building
Dynamic Agent Organizations in Cyberspace. IEEE Internet
Computing, Vol.4, No.2,2000, pp: 65-73.
[21]. Tambe, M., Pynadath, D. V., Chauvat, N., Das, A., and
Kaminka, G. A. Adaptive agent integration architectures for
heterogeneous team members. In Proceedings of the
International Conference on Multiagent Systems8, Boston, MA,
2000, pp: 301--30.
[22]. Vincent, R., Horling, B., and Lesser, V. An Agent
Infrastructure to Build and Evaluate Multi-agent Systems: The
Java Agent Framework and Multi-agent System Simulator.
Lecture Notes in Computer Science 1887, 2001.