gaia part3

corresponding to communication pathways.Agent acquaintance
models
e
are directed graphs,and so an arc a
n
b indicates that a will
send messages to b,but not necessarily that b will send messages
to a.An acquaintance model may be derived in a straightforward
way from the roles,protocols,and agent models.
?
V
?
￥X6
mA?0A8|(?

?f"$!@8A)||
The design stage of the methodology can now be summarised:
1.Create an agent model:
C
aggregate roles into agent types,and refine to form an
agent type hierarchy;
C
document the instances of each agent type using in-
stance annotations.
2.Develop a services model,by examining protocols and safety
and liveness properties of roles.
3.Develop an acquaintance model from the interaction model
and agent model.
po￡
4
9|?Ai?¨H%#'HUsqr7§%i|(

bA||e?f!?EbA|e|?c

9H?A§32A

¨
This section briefly illustrates how the methodology can be applied,
through a case study of the analysis and design of an agent-based
system for managing a British Telecom business process(see[13]
for more details).For reasons of brevity,we omit some details,and
aim instead to give a general flavour of the analysis and design.
The particular application is providing customers with a quote
for installing a network to deliver a particular type of telecommu-
nications service.This activity involves the following departments:
the customer service division(CSD),the design division(DD),the
legal division(LD)and the various organisations who provide the
out-sourced service of vetting customers(VCs).The process is ini-
tiated by a customer contacting the CSD with a set of requirements.
In parallel to capturing the requirements,the CSD gets the cus-
tomer vetted.If the customer fails the vetting procedure,the quote
process terminates.Assuming the customer is satisfactory,their re-
quirements are mapped against the service portfolio.If they can
be met by a standard off-the-shelf item then an immediate quote
can be offered.In the case of bespoke services,however,the pro-
cess is more complex.DD starts to design a solution to satisfy the
customer’s requirements and whilst this is occurring LD checks the
legality of the proposed service.If the desired service is illegal,the
quote process terminates.Assuming the requested service is legal,
the design will eventually be completed and costed.DD then in-
forms CSD of the quote.CSD,in turn,informs the customer.The
business process then terminates.
Moving from this behavioural description of the system’s oper-
ation to an organisational view is comparatively straightforward.In
many cases there is a one to one mapping between departments and
roles.Thus,the VC’s,the LD’s,and the DD’s behaviour are cov-
ered by the roles CustomerVetter,LegalAdvisor,and NetworkDesigner
respectively.CSD’s behaviour falls into two distinct roles:one
acting as an interface to the customer(CustomerHandler),and one
overseeing the process inside the organisation(QuoteManager).The
final role is that of the Customer who requires the quote.Figure 6
defines the role QuoteManager—we omit other role definitions in
the interests of brevity.The definition of the VetCustomer protocol
is given in Figure 7.
Turning to the design stage,an agent model for this application
is given in Figure 8.As this figure illustrates,the implemented sys-
tem contains five agent types,with two roles(CustomerHandler and
QuoteManager)being aggregated into agent type CustomerService-
DivisionAgent.The acquaintance model for this domain is defined
in Figure 9.(We omit the services model in the interests of brevity.)
t
p`§AGb?¨A9v#wu!HxR
As a result of the development and application of robust agent
technologies,there has been a surge of interest in agent-oriented
methodologies and modelling techniques in the last few years.Many
approaches,such as[3,16]take existing OO modelling techniques
or methodologies as their basis,seeking either to extend and adapt
the models and define a methodology for their use,or to directly ex-
tend the applicability of OO methodologies and techniques,such as
design patterns,to the design of agent systems.Other approaches
build upon and extend methodologies and modelling techniques
from software and knowledge engineering,or provide formal,com-
positional modelling languages[2]suitable for the verification of
system structure and function.A valuable survey can be found
in[10].
These approaches usually do not attempt to unify the analysis
and design of a MAS with its design and implementation within a
particular agent technology.They either regard the output of the
analysis and design process as an abstract specification to which
traditional lower-level design methodologies may be applied(as
proposed in this paper),or else they allow some architectural com-
mitment to be made during analysis or design,but fall short of a
full elaboration of the design within the chosen framework.Of the
approaches mentioned above,only the AOM approach of[16,15]
makes a strong commitment to a particular agent architecture and
proposes a design elaboration and refinement process that leads to
directly executable agent specifications.Given the proliferation of
available agent technologies,there are clearly advantages to a more
general approach,as proposed here.However,a disadvantage may
be a need for iteration of the entire process if the lower-level design
process reveal issues that are best resolved at the agent-oriented
level.
Despite this difference in scope,there are many similarities be-
tween the AOM approach and that proposed here.The former was
developed to fulfill the need for a principled approach to the speci-
fication of complex multi-agent systems based on the belief-desire-
intention(BDI)technology of the Procedural Reasoning System
(PRS)and the Distributed Multi-Agent Reasoning System(DMARS)
[17,6].
The AOM methodology takes as its starting point object-oriented
modelling techniques,as exemplified by[19,1],and adapts and ex-
tends them with agent concepts.The methodology itself is aimed
at the construction of a set of models which,when fully elaborated,
define an agent system specification.The main separation in the
models developed is between the external and internal models.The
external models present a system-level view:the main components
visible in these models are agents themselves,and they are primar-
ily concerned with agent relationships and interactions,including
inheritance and aggregation relationships that allow abstraction of
agent structure.In contrast,the internal models which are associ-
ated with each distinct agent class are entirely concerned with the
internals of agents:their beliefs,goals,and plans.
There are two primary external models;the agent model,which
describes agent classes and instances,and the interaction model,
which captures communications and control relationships between
agents.The agent model is further divided into an agent class
model and an agent instance model.These two models define the
agent classes and instances that can appear,and relate these to one
another via inheritance,aggregation,and instantiation relations.
Agent classes define various attributes possessed by agents,and
amongst these are attributes defining the agent’s sets of beliefs,
goals,and plans.The analyst is able to define how these attributes
are overridden during inheritance.For example,it is assumed that
by default,inherited plans have lower priority than those in sub-
classes.The analyst may tailor these properties as desired.
The internal models,which represent the beliefs,goals and plans
of particular agent classes,are direct extensions of OO object mod-
els(beliefs,goals)and dynamic models(plans).Thus,for exam-
ple,an object model is used to describe the objects about which
an agent will have beliefs,and the properties of those beliefs,such
as whether they have open-or closed-world semantics.Dynamic
models,extended with notions of failure and various other attributes,
are used to directly represent an agent’s plans.These models are
thus quite specific to the BDI architecture employed in DMARS.By
contrast,the external models are applicable to any BDI agent ar-
chitecture.The methodology is aimed at elaborating the models
described above.
A particular feature of the methodology is its emphasis on the
use of abstract agent classes as the means to group roles during
analysis and model refinement,which permits decisions about the
boundaries of concrete agents to be deferred to a late stage of the
design process.
Note that the analysis process will be iterative,as in traditional
methodologies.The outcome will be a model that comprises spec-
ifications in the form required by the DMARS agent architecture.
As a result,the move from end-design to implementation using
DMARS is relatively simple.
It can be seen that there are many similarities between the AOM
external models and the models proposed in this paper.However,
the notion of responsibility used in the AOM models is quite in-
formal:safety and liveness requirements are not made explicit at
an abstract level,and they lack the notion of permissions used to
capture resource usage,which is instead captured implicitly by the
belief structure of individual agents.By contrast,the protocols that
define the permitted interactions between agents may be developed
to a greater degree of detail within the AOM approach,for example
as in[14],whereas here protocols are employed as more generic
descriptions of behaviour that may involve entities not modelled as
agents,such as the coffee machine.Another significant difference
is the use in AOM of inheritance between agent classes which is
not permitted by the methodology proposed here,as it is of limited
value without a specific architectural commitment.
The
?
definition and use of various notions of role,responsibility,
interaction,team and society or organization in particular methods
for agent-oriented analysis and design has also inherited or adapted
much from more general uses of these concepts within multi-agent
systems,including organization-focussed approaches such as[9,7,
11]and sociological approaches such as[4].However,it is beyond
the scope of this paper to compare our definition and use of these
concepts with this heritage.
?
4
!

bG%§i|(!

?|

?#§I%&{¨
6
9A?uwH!xR
In this paper,we have described a methodology we have developed
for the analysis and design of agent-based systems.The key con-
cepts in this methodology are roles,which have associated with
them responsibilities,permissions,and protocols.Roles can inter-
act with one another in certain institutionalised ways,which are
defined in the protocols of the respective roles.
There are many issues remaining for future work.Perhaps most
importantly,our methodology does not attempt to deal with truly
open systems,in which agents may not share common goals.This
class of systems represents arguably the most important applica-
tion area for multi-agent systems,and it is therefore essential that
our methodology should be able to deal with it.Another aspect of
agent-based analysis and design that requires more work is the no-
tion of an organisational structure.At the moment,such structures
are only implicitly defined within our methodology—within the
role and interaction models.However,direct,explicit representa-
tions of such structures will be of value for some applications.For
example,if agents are used to model large organisations,then these
organisations will have an explicitly defined structure.Represent-
ing such structures may be the only way of adequately capturing
and understanding the organisation’s communication and control
structures.More generally,the development of organisation design
patterns might be useful for reusing successful multi-agent system
structures(cf.[8]).Finally,we believe that a successful methodol-
ogy is one that is not only of pragmatic value,but one that also has
a well-defined,unambiguous formal semantics.While the typical
developer need never even be aware of the existence of such a se-
mantics,it is nevertheless essential to have a precise understanding
of what the concepts and terms in a methodology mean[21].