gaia part2
of the United States”,or“secretary of state for Education”are all
offices.
e
Such roles(or offices)are characterised by two types of
attribute:
C
The permissions/rights associated with the role.
A role will have associated with it certain permissions,relat-
ing to the type and the amount of resources that can be ex-
ploited when carrying out the role.In our case,these aspects
are captured in an attribute known as the role’s permissions.
C
The responsibilities of the role.
A role is created in order to do something.That is,a role has
a certain functionality.This functionality is represented by
an attribute known as the role’s responsibilities.
gf9AS2h()|i|(!
|
The permissions associated with a role have two aspects:
C
they identify the resources that can legitimately be used to
carry out the role—intuitively,they say what can be spent
while carrying out the role;
C
they state the resource limits within which the role execu-
tor must operate—intuitively,they say what can’t be spent
while carrying out the role.
In general,permissions can relate to any kind of resource.In a hu-
man organisation,for example,a role might be given a monetary
budget,a certain amount of person effort,and so on.However,in
our methodology,we think of resources as relating only to the in-
formation or knowledge the agent has.That is,in order to carry out
a role,an agent will typically be able to access certain information.
Some roles might generate information;others may need to access
a piece of information but not modify it,while yet others may need
to modify the information.We recognise that a richer model of
resources is required for the future,although for the moment,we
restrict our attention simply to information.
We use a formal notation for expressing permissions that is
based on the FUSION notation for operation schemata[5,pp26–31].
We illustrate this notation below.
p`8A|i&F!
|q(H¤q(G()¨(8A|
The functionality of a role is defined by its responsibilities.These
responsibilities can be divided into two categories:liveness and
safety responsibilities.
Liveness responsibilities are those that,intuitively,state that
“something good happens”.Liveness responsibilities are so called
because they tend to say that“something will be done”,and hence
that the agent carrying out the role is still alive.Liveness responsi-
bilities tend to follow certain patterns.For example,the guaranteed
response type of achievement goal has the form“a request is always
followed by a response”.The infinite repetition achievement goal
has the form“x will happen infinitely often”.Note that these types
of requirements have been widely studied in the software engineer-
ing literature,where they have proven to be necessary for capturing
properties of reactive systems[18].
In order to illustrate the various concepts associated with roles,
we will use a simple running example of a“coffee filler”role—
the purpose of this role is to ensure that a coffee pot is kept full of
coffee for a group of workers.Examples of liveness responsibilities
for a CoffeeFiller role might be:
C
whenever the coffee is empty,fill it up;
C
whenever fresh coffee is brewed,make sure the workers know
about it.
In our model,an agent’s liveness properties are specified via a live-
ness expression,which defines the“life-cycle”of the role.Liveness
expressions are similar to the life-cycle expression of FUSION[5],
which are in turn essentially regular expressions.Our liveness
properties have an additional operator,“ω”,for infinite repetition
(see Table 1 for more details).They thus resembleω-regular ex-
pressions,which are known to be suitable for representing the prop-
erties of infinite computations[20].
Liveness expressions define the potential execution trajectories
through the various activities and interactions(i.e.,over the pro-
tocols)associated with the role.The general form of a liveness
expression is:
RoleName
x
expression
where RoleName is the name of the role whose liveness properties
are being defined,and expression is the liveness expression defining
the liveness properties of RoleName.The atomic components of a
liveness expression are protocols—we define protocols below.
To illustrate liveness expressions,consider again the above-
mentioned responsibilities of the CoffeeFiller role:
CoffeeFiller
x y
Fill
?
InformWorkers
?
CheckStock
?
AwaitEmpty
?
ω
This expression says that CoffeeFiller consists of executing the pro-
tocol Fill,followed by the protocol InformWorkers,followed by the
protocols CheckStock and AwaitEmpty.These four protocols are then
repeated infinitely often.For the moment,we shall treat the pro-
tocols simply as labels for interactions and shall not worry about
how they are actually defined(this matter will be returned to in
section 3.2).
Complex liveness expressions can be made easier to read by
structuring them.A simple example illustrates how this is done:
CoffeeFiller
x y
All
?
ω
All
x
Fill
?
InformWorkers
?
CheckStock
?
AwaitEmpty
In many cases,it is insufficient simply to specify the liveness
responsibilities of a role.This is because an agent,carrying out
a role,will be required to maintain certain invariants while exe-
cuting.For example,we might require that a particular agent tak-
ing part in an electronic commerce application never spends more
money than it has been allocated.These invariants are called safety
conditions,because they usually relate to the absence of some un-
desirable condition arising.
Safety requirements in our methodology are specified by means
of a list of predicates.These predicates are typically expressed over
the variables listed in a role’s permissions attribute.Returning to
our CoffeeFiller role,an agent carrying out this role will generally be
required to ensure that the coffee stock is never empty.We can do
this by means of the following safety expression:
C
coffeeStock
?
0
By convention,we simply list safety expressions as a bulleted list,
each item in the list expressing an individual safety responsibility.
It is implicitly assumed that these responsibilities apply across all
states of the system execution.If the role is of infinitely long dura-
tion(as in the CoffeeFiller example),then the invariants must always
be true.
It is now possible to precisely define the roles model.A roles
model is comprised of a set of role schemata,one for each role in
the system.A role schema draws together the various attributes
discussed above into a single place(Figure 3).An exemplar in-
stantiation is given for the CoffeeFiller role in Figure 4.This schema
indicates that CoffeeFiller has permission to read the coffeeMaker pa-
rameter(that indicates which coffee machine the role is intended to
keep filled),and the coffeeStatus(that indicates whether the ma-
chine is full or empty).In addition,the role has permission to
change the value coffeeStock.
$TV D￥X6
A
?¨§A"§)¨(!
?c?!#'9AG
There are inevitably dependencies and relationships between the
various roles in a multi-agent organisation.Indeed,such interplay
is central to the way in which the system functions.Given this
fact,interactions obviously need to be captured and represented in
the analysis phase.In our case,such links between roles are repre-
sented in the interaction model.This model consists of a set of pro-
tocol definitions,one for each type of inter-role interaction.Here a
protocol can be viewed as an institutionalised pattern of interaction.
That is,a pattern of interaction that has been formally defined and
abstracted away from any particular sequence of execution steps.
Viewing interactions in this way means that attention is focused on
the essential nature and purpose of the interaction,rather than on
the precise ordering of particular message exchanges(cf.the inter-
action diagrams of OBJECTORY[5,pp198–203]or the scenarios of
FUSION[5]).
Our approach means that a single protocol definition will typi-
cally give rise to a number of message interchanges in the run time
system.For example,consider an English auction protocol.This
involves multiple roles(sellers and bidders)and many potential pat-
terns of interchange(specific price announcements and correspond-
ing bids).However at the analysis stage,such precise instantiation
details are unnecessary,and too premature.
In more detail,protocol definitions consist of the following set
of attributes:
C
purpose:brief description of the nature of the interaction
(e.g.“information request”,“schedule activity”and“assign
task”);
C
initiator:the role(s)responsible for starting the interaction;
C
responder:the role(s)with which the initiator interacts;
C
inputs:information used by the role initiator while enacting
the protocol;
C
outputs:information supplied by/to the protocol responder
during the course of the interaction;
C
processing:brief description of any processing the protocol
initiator performs during the course of the interaction;
By means of an illustration,consider the Fill protocol,which forms
part of the CoffeeFiller role(Figure 5).This states that the pro-
tocol Fill is initiated by the role CoffeeFiller and involves the role
CoffeeMachine.The protocol involves CoffeeFiller putting coffee in
the machine named coffeeMaker,and results in CoffeeMachine be-
ing informed about the value of coffeeStock.We will see further
examples of protocols in section 5.
$TqVT?￥X6
?A￡
HG EU|i(3|f??!EbA||
The analysis stage of the methodology can now be summarised:
1.Identify the roles in the system.
Output:A prototypical roles model—a list of the key roles
that occur in the system,each with an informal,unelaborated
description.
2.For each role,identify and document the associated proto-
cols.Protocols are the patterns of interaction that occur in
the system between the various roles.
Output:An interaction model,which captures the recurring
patterns of inter-role interaction.
3.Using the protocol model as a basis,elaborate the roles model.
Output:A fully elaborated roles model,which documents
the key roles occurring in the system,their permissions and
responsibilities,and the protocols in which they take part.
4.Iterate stages(1)–(3).
??0A8|(?
The aim of a“classical”design process is to transform the ab-
stract models derived during the analysis stage into models at a
sufficiently low level of abstraction that they can be easily imple-
mented.This is not the case with agent-oriented design,however.
Rather,our aim is to transform the analysis models into a suffi-
ciently low level of abstraction that traditional design techniques
(including object-oriented techniques)may be applied.To put it
another way,the agent-oriented analysis and design process is con-
cerned with how a society of agents cooperate to realise the system-
level goals,and what is required of each individual agent in order
to do this.Actually how an agent realises its services is beyond
the scope of the methodology,and will depend on the particular
application domain.
The design process involves generating three models(see Fig-
ure 2).The agent model identifies the agent types that will make up
the system,and the agent instances that will be instantiated from
these types.The services model identifies the main services that
will be associated with each agent type.Finally,the acquaintance
model documents the acquaintances for each agent type.
?
?V?￥X6
dA1￡H?A
e¨?c!?'#9AG
The purpose of the agent model is to document the various agent
types that will be used in the system under development,and the
agent instances that will realise these agent types at run-time.
An agent type is best thought of as a set of agent roles.There
may in fact be a one-to-one correspondence between roles(as iden-
tified in the roles model—see section 3.1)and agent types.How-
ever,this need not be the case.A designer can choose to package
a number of closely related roles in the same agent type for the
purposes of convenience.Efficiency will also be a major concern
at this stage:a designer will almost certainly want to optimise the
design,and one way of doing this is to aggregate a number of agent
roles into a single type.An example of where such a decision may
be necessary is where the“footprint”of an agent(i.e.,its run-time
requirements in terms of processor power or memory space)is so
large that it is more efficient to deliver a number of roles in a single
agent than to deliver a number of agents each performing a single
role.There is obviously a trade-off between the coherence of an
agent type(how easily its functionality can be understood)and the
efficiency considerations that come into play when designing agent
types.The agent model is defined using a simple agent type tree,
in which root nodes correspond to roles,(as defined in the roles
model),and other nodes correspond to agent types.If an agent type
t1 has children t2 and t3,then this means that t1 is composed of the
roles that make up t2 and t3.
We document the agent instances that will appear in a system
by annotating agent types in the agent model(cf.the qualifiers from
FUSION[5]).An annotation n means that there will be exactly
n agents of this type in the run-time system.An annotation m
??
n
means that there will be no less than m and no more than n instances
of this type in a run-time system(m
f
n).An annotation
g
means
that there will be zero or more instances at run-time,and
h
means
that there will be one or more instances at run-time.
Note that inheritance plays no part in our agent models.Our
view is that agents are coarse grained computational systems,and
an agent system will typically contain only a small number of roles
and types,with often a one-to-one mapping between them.For
this reason,we believe that inheritance has no useful part to play
in the design of agent types.(However,when it comes to actually
implementing agents,inheritance may be used in the normal OO
fashion.)
?
V D￥X6
?A$i9Abj(EAbh|?c!?'#9AG
As its name suggests,the aim of the services model is to identify
the services associated with each agent role,and to specify the main
properties of these services.By a service,we mean a function of
the agent.In OO terms,a service would correspond to a method;
however,we do not mean that services are available for other agents
in the same way that an object’s methods are available for another
object to invoke.Rather,a service is simply a single,coherent block
of activity that an agent will engage in.
For each service that may be performed by an agent,it is nec-
essary to document its properties.Specifically,we must identify
the inputs,outputs,pre-conditions,and post-conditions of each ser-
vice.Inputs and outputs to services will be derived in an obvious
way from the protocols model.Pre-and post-conditions represent
constraints on services.These are derived from the safety proper-
ties of a role.Note that by definition,each role will be associated
with at least one service.
The services that an agent will perform are derived from the
list of protocols and responsibilities associated with a role,and in
particular,from the liveness definition of a role.For example,re-
turning to the coffee example,there are four protocols associated
with this role:Fill,InformWorkers,CheckStock,and AwaitEmpty.There
will be at least one service associated with each protocol.In the
case of CheckStock,the service(which may have the same name),
will take as input the stock level and some threshold value,and will
simply compare the two.The pre-and post-conditions will both
state that the coffee stock level is greater than 0–this condition is
one of the safety conditions of the CoffeeFiller.
The services model does not prescribe an implementation for
the services it documents.The developer is free to realise the ser-
vices in any implementation framework deemed appropriate.For
example,it may be decided to implement services directly as meth-
ods in an object-oriented language.Alternatively,a service may be
decomposed into a number of methods.
?
qV?T￥X6
?Ak￡El?§%§(
?¨
EmAdc!$H#§AG
The final design model is probably the simplest:the acquaintance
model.Acquaintance models simply define the communication
links that exist between agent types.They do not define what mes-
sages are sent or when messages are sent—they simply indicate
that communication pathways exist.In particular,the purpose of
an acquaintance model is to identify any potential communication
bottlenecks,which may cause problems at run-time(see section 5
for an example).It is generally regarded as good practice to en-
sure that systems are loosely coupled,and the acquaintance model
can help in doing this.On the basis of the acquaintance model,it
may be found necessary to revisit the analysis stage and rework the
system design to remove such problems.
An agent acquaintance model is simply a graph,with nodes
in the graph corresponding to agent types and arcs in the graph
offices.
e
Such roles(or offices)are characterised by two types of
attribute:
C
The permissions/rights associated with the role.
A role will have associated with it certain permissions,relat-
ing to the type and the amount of resources that can be ex-
ploited when carrying out the role.In our case,these aspects
are captured in an attribute known as the role’s permissions.
C
The responsibilities of the role.
A role is created in order to do something.That is,a role has
a certain functionality.This functionality is represented by
an attribute known as the role’s responsibilities.
gf9AS2h()|i|(!
|
The permissions associated with a role have two aspects:
C
they identify the resources that can legitimately be used to
carry out the role—intuitively,they say what can be spent
while carrying out the role;
C
they state the resource limits within which the role execu-
tor must operate—intuitively,they say what can’t be spent
while carrying out the role.
In general,permissions can relate to any kind of resource.In a hu-
man organisation,for example,a role might be given a monetary
budget,a certain amount of person effort,and so on.However,in
our methodology,we think of resources as relating only to the in-
formation or knowledge the agent has.That is,in order to carry out
a role,an agent will typically be able to access certain information.
Some roles might generate information;others may need to access
a piece of information but not modify it,while yet others may need
to modify the information.We recognise that a richer model of
resources is required for the future,although for the moment,we
restrict our attention simply to information.
We use a formal notation for expressing permissions that is
based on the FUSION notation for operation schemata[5,pp26–31].
We illustrate this notation below.
p`8A|i&F!
|q(H¤q(G()¨(8A|
The functionality of a role is defined by its responsibilities.These
responsibilities can be divided into two categories:liveness and
safety responsibilities.
Liveness responsibilities are those that,intuitively,state that
“something good happens”.Liveness responsibilities are so called
because they tend to say that“something will be done”,and hence
that the agent carrying out the role is still alive.Liveness responsi-
bilities tend to follow certain patterns.For example,the guaranteed
response type of achievement goal has the form“a request is always
followed by a response”.The infinite repetition achievement goal
has the form“x will happen infinitely often”.Note that these types
of requirements have been widely studied in the software engineer-
ing literature,where they have proven to be necessary for capturing
properties of reactive systems[18].
In order to illustrate the various concepts associated with roles,
we will use a simple running example of a“coffee filler”role—
the purpose of this role is to ensure that a coffee pot is kept full of
coffee for a group of workers.Examples of liveness responsibilities
for a CoffeeFiller role might be:
C
whenever the coffee is empty,fill it up;
C
whenever fresh coffee is brewed,make sure the workers know
about it.
In our model,an agent’s liveness properties are specified via a live-
ness expression,which defines the“life-cycle”of the role.Liveness
expressions are similar to the life-cycle expression of FUSION[5],
which are in turn essentially regular expressions.Our liveness
properties have an additional operator,“ω”,for infinite repetition
(see Table 1 for more details).They thus resembleω-regular ex-
pressions,which are known to be suitable for representing the prop-
erties of infinite computations[20].
Liveness expressions define the potential execution trajectories
through the various activities and interactions(i.e.,over the pro-
tocols)associated with the role.The general form of a liveness
expression is:
RoleName
x
expression
where RoleName is the name of the role whose liveness properties
are being defined,and expression is the liveness expression defining
the liveness properties of RoleName.The atomic components of a
liveness expression are protocols—we define protocols below.
To illustrate liveness expressions,consider again the above-
mentioned responsibilities of the CoffeeFiller role:
CoffeeFiller
x y
Fill
?
InformWorkers
?
CheckStock
?
AwaitEmpty
?
ω
This expression says that CoffeeFiller consists of executing the pro-
tocol Fill,followed by the protocol InformWorkers,followed by the
protocols CheckStock and AwaitEmpty.These four protocols are then
repeated infinitely often.For the moment,we shall treat the pro-
tocols simply as labels for interactions and shall not worry about
how they are actually defined(this matter will be returned to in
section 3.2).
Complex liveness expressions can be made easier to read by
structuring them.A simple example illustrates how this is done:
CoffeeFiller
x y
All
?
ω
All
x
Fill
?
InformWorkers
?
CheckStock
?
AwaitEmpty
In many cases,it is insufficient simply to specify the liveness
responsibilities of a role.This is because an agent,carrying out
a role,will be required to maintain certain invariants while exe-
cuting.For example,we might require that a particular agent tak-
ing part in an electronic commerce application never spends more
money than it has been allocated.These invariants are called safety
conditions,because they usually relate to the absence of some un-
desirable condition arising.
Safety requirements in our methodology are specified by means
of a list of predicates.These predicates are typically expressed over
the variables listed in a role’s permissions attribute.Returning to
our CoffeeFiller role,an agent carrying out this role will generally be
required to ensure that the coffee stock is never empty.We can do
this by means of the following safety expression:
C
coffeeStock
?
0
By convention,we simply list safety expressions as a bulleted list,
each item in the list expressing an individual safety responsibility.
It is implicitly assumed that these responsibilities apply across all
states of the system execution.If the role is of infinitely long dura-
tion(as in the CoffeeFiller example),then the invariants must always
be true.
It is now possible to precisely define the roles model.A roles
model is comprised of a set of role schemata,one for each role in
the system.A role schema draws together the various attributes
discussed above into a single place(Figure 3).An exemplar in-
stantiation is given for the CoffeeFiller role in Figure 4.This schema
indicates that CoffeeFiller has permission to read the coffeeMaker pa-
rameter(that indicates which coffee machine the role is intended to
keep filled),and the coffeeStatus(that indicates whether the ma-
chine is full or empty).In addition,the role has permission to
change the value coffeeStock.
$TV D￥X6
A
?¨§A"§)¨(!
?c?!#'9AG
There are inevitably dependencies and relationships between the
various roles in a multi-agent organisation.Indeed,such interplay
is central to the way in which the system functions.Given this
fact,interactions obviously need to be captured and represented in
the analysis phase.In our case,such links between roles are repre-
sented in the interaction model.This model consists of a set of pro-
tocol definitions,one for each type of inter-role interaction.Here a
protocol can be viewed as an institutionalised pattern of interaction.
That is,a pattern of interaction that has been formally defined and
abstracted away from any particular sequence of execution steps.
Viewing interactions in this way means that attention is focused on
the essential nature and purpose of the interaction,rather than on
the precise ordering of particular message exchanges(cf.the inter-
action diagrams of OBJECTORY[5,pp198–203]or the scenarios of
FUSION[5]).
Our approach means that a single protocol definition will typi-
cally give rise to a number of message interchanges in the run time
system.For example,consider an English auction protocol.This
involves multiple roles(sellers and bidders)and many potential pat-
terns of interchange(specific price announcements and correspond-
ing bids).However at the analysis stage,such precise instantiation
details are unnecessary,and too premature.
In more detail,protocol definitions consist of the following set
of attributes:
C
purpose:brief description of the nature of the interaction
(e.g.“information request”,“schedule activity”and“assign
task”);
C
initiator:the role(s)responsible for starting the interaction;
C
responder:the role(s)with which the initiator interacts;
C
inputs:information used by the role initiator while enacting
the protocol;
C
outputs:information supplied by/to the protocol responder
during the course of the interaction;
C
processing:brief description of any processing the protocol
initiator performs during the course of the interaction;
By means of an illustration,consider the Fill protocol,which forms
part of the CoffeeFiller role(Figure 5).This states that the pro-
tocol Fill is initiated by the role CoffeeFiller and involves the role
CoffeeMachine.The protocol involves CoffeeFiller putting coffee in
the machine named coffeeMaker,and results in CoffeeMachine be-
ing informed about the value of coffeeStock.We will see further
examples of protocols in section 5.
$TqVT?￥X6
?A￡
HG EU|i(3|f??!EbA||
The analysis stage of the methodology can now be summarised:
1.Identify the roles in the system.
Output:A prototypical roles model—a list of the key roles
that occur in the system,each with an informal,unelaborated
description.
2.For each role,identify and document the associated proto-
cols.Protocols are the patterns of interaction that occur in
the system between the various roles.
Output:An interaction model,which captures the recurring
patterns of inter-role interaction.
3.Using the protocol model as a basis,elaborate the roles model.
Output:A fully elaborated roles model,which documents
the key roles occurring in the system,their permissions and
responsibilities,and the protocols in which they take part.
4.Iterate stages(1)–(3).
??0A8|(?
The aim of a“classical”design process is to transform the ab-
stract models derived during the analysis stage into models at a
sufficiently low level of abstraction that they can be easily imple-
mented.This is not the case with agent-oriented design,however.
Rather,our aim is to transform the analysis models into a suffi-
ciently low level of abstraction that traditional design techniques
(including object-oriented techniques)may be applied.To put it
another way,the agent-oriented analysis and design process is con-
cerned with how a society of agents cooperate to realise the system-
level goals,and what is required of each individual agent in order
to do this.Actually how an agent realises its services is beyond
the scope of the methodology,and will depend on the particular
application domain.
The design process involves generating three models(see Fig-
ure 2).The agent model identifies the agent types that will make up
the system,and the agent instances that will be instantiated from
these types.The services model identifies the main services that
will be associated with each agent type.Finally,the acquaintance
model documents the acquaintances for each agent type.
?
?V?￥X6
dA1￡H?A
e¨?c!?'#9AG
The purpose of the agent model is to document the various agent
types that will be used in the system under development,and the
agent instances that will realise these agent types at run-time.
An agent type is best thought of as a set of agent roles.There
may in fact be a one-to-one correspondence between roles(as iden-
tified in the roles model—see section 3.1)and agent types.How-
ever,this need not be the case.A designer can choose to package
a number of closely related roles in the same agent type for the
purposes of convenience.Efficiency will also be a major concern
at this stage:a designer will almost certainly want to optimise the
design,and one way of doing this is to aggregate a number of agent
roles into a single type.An example of where such a decision may
be necessary is where the“footprint”of an agent(i.e.,its run-time
requirements in terms of processor power or memory space)is so
large that it is more efficient to deliver a number of roles in a single
agent than to deliver a number of agents each performing a single
role.There is obviously a trade-off between the coherence of an
agent type(how easily its functionality can be understood)and the
efficiency considerations that come into play when designing agent
types.The agent model is defined using a simple agent type tree,
in which root nodes correspond to roles,(as defined in the roles
model),and other nodes correspond to agent types.If an agent type
t1 has children t2 and t3,then this means that t1 is composed of the
roles that make up t2 and t3.
We document the agent instances that will appear in a system
by annotating agent types in the agent model(cf.the qualifiers from
FUSION[5]).An annotation n means that there will be exactly
n agents of this type in the run-time system.An annotation m
??
n
means that there will be no less than m and no more than n instances
of this type in a run-time system(m
f
n).An annotation
g
means
that there will be zero or more instances at run-time,and
h
means
that there will be one or more instances at run-time.
Note that inheritance plays no part in our agent models.Our
view is that agents are coarse grained computational systems,and
an agent system will typically contain only a small number of roles
and types,with often a one-to-one mapping between them.For
this reason,we believe that inheritance has no useful part to play
in the design of agent types.(However,when it comes to actually
implementing agents,inheritance may be used in the normal OO
fashion.)
?
V D￥X6
?A$i9Abj(EAbh|?c!?'#9AG
As its name suggests,the aim of the services model is to identify
the services associated with each agent role,and to specify the main
properties of these services.By a service,we mean a function of
the agent.In OO terms,a service would correspond to a method;
however,we do not mean that services are available for other agents
in the same way that an object’s methods are available for another
object to invoke.Rather,a service is simply a single,coherent block
of activity that an agent will engage in.
For each service that may be performed by an agent,it is nec-
essary to document its properties.Specifically,we must identify
the inputs,outputs,pre-conditions,and post-conditions of each ser-
vice.Inputs and outputs to services will be derived in an obvious
way from the protocols model.Pre-and post-conditions represent
constraints on services.These are derived from the safety proper-
ties of a role.Note that by definition,each role will be associated
with at least one service.
The services that an agent will perform are derived from the
list of protocols and responsibilities associated with a role,and in
particular,from the liveness definition of a role.For example,re-
turning to the coffee example,there are four protocols associated
with this role:Fill,InformWorkers,CheckStock,and AwaitEmpty.There
will be at least one service associated with each protocol.In the
case of CheckStock,the service(which may have the same name),
will take as input the stock level and some threshold value,and will
simply compare the two.The pre-and post-conditions will both
state that the coffee stock level is greater than 0–this condition is
one of the safety conditions of the CoffeeFiller.
The services model does not prescribe an implementation for
the services it documents.The developer is free to realise the ser-
vices in any implementation framework deemed appropriate.For
example,it may be decided to implement services directly as meth-
ods in an object-oriented language.Alternatively,a service may be
decomposed into a number of methods.
?
qV?T￥X6
?Ak￡El?§%§(
?¨
EmAdc!$H#§AG
The final design model is probably the simplest:the acquaintance
model.Acquaintance models simply define the communication
links that exist between agent types.They do not define what mes-
sages are sent or when messages are sent—they simply indicate
that communication pathways exist.In particular,the purpose of
an acquaintance model is to identify any potential communication
bottlenecks,which may cause problems at run-time(see section 5
for an example).It is generally regarded as good practice to en-
sure that systems are loosely coupled,and the acquaintance model
can help in doing this.On the basis of the acquaintance model,it
may be found necessary to revisit the analysis stage and rework the
system design to remove such problems.
An agent acquaintance model is simply a graph,with nodes
in the graph corresponding to agent types and arcs in the graph