gaia part1

￥￡§¤?|¨§¨
This paper presents a methodology for agent-oriented analysis and
design.The methodology is general,in that it is applicable to
a wide range of multi-agent systems,and comprehensive,in that
it deals with both the macro-level(societal)and the micro-level
(agent)aspects of systems.The methodology is founded on the
view of a system as a computational organisation consisting of var-
ious interacting roles.We illustrate the methodology through a case
study(an agent-based business process management system).

¨"$!&#%')¨(!

Progress in software engineering over the past two decades has pri-
marily been made through the development of increasingly power-
ful and natural abstractions with which to model and develop com-
plex systems.Procedural abstraction,abstract data types,and,most
recently,objects,are all examples of such abstractions.It is our
belief that agents represent a similar advance in abstraction:they
may be used by software developers to more naturally understand,
model,and develop an important class of complex distributed sys-
tems.
If agents are to realise their potential as a software engineer-
ing paradigm,then it is necessary to develop software engineering
techniques that are specifically tailored to them.Existing software
development techniques(for example,object-oriented analysis and
design[1,5])will simply be unsuitable for this task.There is a fun-
damental mismatch between the concepts used by object-oriented
developers(and indeed,by other mainstream software engineer-
ing paradigms)and the agent-oriented view[20,22].In particular,
extant approaches fail to adequately capture an agent’s flexible,au-
tonomous problem-solving behaviour,the richness of an agent’s in-
teractions,and the complexity of an agent system’s organisational
structures.For these reasons,this paper outlines a methodology
that has been specifically tailored to the analysis and design of
agent-based systems.
The remainder of this paper is structured as follows.We begin,
in the following sub-section,by discussing the characteristics of
applications for which we believe our analysis and design method-
ology is appropriate.Section 2 gives an overview of the main con-
cepts used by the methodology.Agent-based analysis is discussed
in section 3,and design in section 4.The methodology is demon-
strated by means of a case study in section 5,where we show how
it was applied to the design of a real-world agent-based system for
business process management[13].Related work is discussed in
section 6,and some conclusions are presented in section 7.
10&!23§(
5746
89@?¨A9B(?|¨)(@|
Before proceeding,it is worth commenting on the scope of our
work,and in particular,on the characteristics of domains for which
we believe the methodology is appropriate.It is intended that the
methodology be appropriate for the development of systems such
as ADEPT[13]and ARCHON[12].These are large-scale real-world
applications,with the following main characteristics:
C
Agents are coarse-grained computational systems,each mak-
ing use of significant computational resources(think of each
agent as having the resources of a UNIX process.)
C
It is assumed that the goal is to obtain a system that max-
imises some global quality measure,but which may be sub-
optimal from the point of view of the system components.
Our methodology is not intended for systems that admit the
possibility of true conflict.
C
Agents are heterogeneous,in that different agents may be im-
plemented using different programming languages and tech-
niques.We make no assumptions about the delivery plat-
form.
C
The overall system contains a comparatively small number
of agents(less than 100).
The methodology we propose is comprehensive,in that it deals
with both the macro(societal)level and the micro(agent)level
aspects of design.It represents an advance over previous agent-
oriented methodologies in that it is neutral with respect to both the
target domain and the agent architecture(see section 6 for a more
detailed comparison).
D
￡
4
!

E9A§F¨§%HPGIH§32A81QH!SR
Our methodology is intended to allow an analyst to go systemat-
ically from a statement of requirements to a design that is suffi-
ciently detailed that it can be implemented directly.In applying
the methodology,the analyst moves from abstract to increasingly
concrete concepts.Each successive move introduces greater imple-
mentation bias,and shrinks the space of possible systems that could
be implemented to satisfy the original requirements statement.
The methodology borrows some terminology and notation from
object-oriented analysis and design,(specifically,FUSION[5]).How-
ever,it is not simply a naive attempt to apply such methods to
agent-oriented development.Rather,our methodology provides an
agent-specific set of concepts through which a software engineer
can understand and model a complex system.In particular,the
methodology encourages a developer to think of building agent-
based systems as a process of organisational design.
The main concepts can be divided into two categories:abstract
and concrete.Abstract entities are those used during analysis to
conceptualise the system,but which do not necessarily have any
direct realisation within the system.Concrete entities,in contrast,
are used within the design process,and will typically have direct
counterparts in the run-time system.
The most abstract entity in our concept hierarchy is the system
—see Figure 1.Although the term“system”is used in its stan-
dard sense,it also has a related meaning when talking about an
agent-based system,to mean“society”or“organisation”.That is,
we think of an agent-based system as an artificial society or organ-
isation.
The idea of a system as a society is useful when thinking about
the next level in the concept hierarchy:roles.It may seem strange
to think of a computer system as being defined by a set of roles,but
the idea is quite natural when adopting an organisational view of the
world.Consider a human organisation such as a typical company.
The company has roles such as“president”,“vice president”,and
so on.Note that in a concrete realisation of a company,these roles
will be instantiated with actual individuals:there will be an indi-
vidual who takes on the role of president,an individual who takes
on the role of vice president,and so on.However,the instantiation
is not necessarily static.Throughout the company’s lifetime,many
individuals may take on the role of company president,for exam-
ple.Also,there is not necessarily a one-to-one mapping between
roles and individuals.It is not unusual(particularly in small or in-
formally defined organisations)for one individual to take on many
roles.For example,a single individual might take on the role of
“tea maker”,“mail fetcher”,and so on.Conversely,there may be
many individuals that take on a single role,e.g.,“salesman”.
A role is defined by three attributes:responsibilities,permis-
sions,and protocols.Responsibilities determine functionality and,
as such,are perhaps the key attribute associated with a role.An ex-
ample responsibility associated with the role of company president
might be calling the shareholders meeting every year.Responsi-
bilities are divided into two types:liveness properties and safety
properties[18].Liveness properties intuitively state that“some-
thing good happens”.They describe those states of affairs that an
agent must bring about,given certain environmental conditions.In
contrast,safety properties are invariants.Intuitively,a safety prop-
erty states that“nothing bad happens”(i.e.,that an acceptable state
of affairs is maintained across all states of execution).An exam-
ple might be“ensure the reactor temperature always remains in the
range 0-100”.
In order to realise responsibilities,a role is usually associated
with a set of permissions.Permissions are the“rights”associated
with a role.The permissions of a role thus identify the resources
that are available to that role in order to realise its responsibilities.
In the kinds of system that we have typically modelled,permissions
tend to be information resources.For example,a role might have
associated with it the ability to read a particular item of informa-
tion,or to modify another piece of information.A role can also
have the ability to generate information.
Finally,a role is also identified with a number of protocols,
which define the way that it can interact with other roles.For ex-
ample,a“seller”role might have the protocols“Dutch auction”and
“English auction”associated with it.
In summary,analysis and design can be thought of as a process
of developing increasingly detailed models of the system to be con-
structed.The main models used in our approach are summarised in
Figure 2,and elaborated in sections 3 and 4.
T
￡

HG UE|(|
The objective of the analysis stage is to develop an understanding
of the system and its structure(without reference to any implemen-
tation detail).In our case,this understanding is captured in the
system’s organisation.In more detail,we view an organisation as
a collection of roles,that stand in certain relationships to one an-
other,and that take part in systematic,institutionalised patterns of
interactions with other roles.To define an organisation,it therefore
suffices to define the roles in the organisation,how these roles re-
late to one another,and how a role can interact with other roles.
The aim of the analysis stage is,therefore,to model the system as
a multi-agent organisation in precisely this way.Thus,the organi-
sation model is comprised of two further models:the roles model
(section 3.1)and the interaction model(section 3.2).
$TWVY￥X6
5Aa`!&G bA|3dc$!#H§AG
The roles model identifies the key roles in the system.Here a role
can be viewed as an abstract description of an entity’s expected
function.In other terms,a role is more or less identical to the notion
of an office in the sense that“prime minister”,“attorney general