Prometheus 2/4

distributed)or outside of the agent part of the system.If done within the agent part
of the system then the Prometheus methodology can be applied,otherwise existing
methodologies can be used.
The online bookstore has the percepts of customers visiting the website,selecting
items,placing orders(using forms),and receiving email from customers,delivery ser-
vices and book suppliers.Actions are bank transactions,sending email,and placing
delivery orders.
In parallel with discovering or specifying(which of these will depend on the situ-
ation)the percepts and actions the developer must start to describe what it is the agent
system should do in a broader sense-the functionalities3 of the system.For example,
in order to define the book store we may need to define functionalities such as“the
book store will provide a personalised interface to customers”and“the book store will
maintain its stock”.These functionalities start to give an understanding of the system-
some sense of its purpose.
It is important in defining functionalities that they be kept as narrow as possible,
dealing with a single aspect or goal of the system.If functionalities are too broad they
are likely to be less adequately specified leading to potential misunderstanding.
In defining a functionality it is important to also define the information that is re-
quired,and the information produced by it.The functionality descriptor produced con-
tains a name,a short natural language description,a list of actions,a list of relevant
percepts,data used and produced and a brief description of interactions with other
functionalities.For example,the following describes the welcomer functionality in the
online bookstore.
Welcomer:provides a customised response to the user when they log into the site.
Actions:provide link to status of existing orders,welcome by name,welcome as new
user,query enjoyment of recent purchases,indicate special offers relevant to interests.
Percepts:Customer accesses site.
Data access:Reads customer information,special offers,and customer interactions
data.Writes customer interactions data.
Interactions:No interactions with other functionalities.
While functionalities focus on particular aspects of the system,use case scenarios
give a more holistic view of the system.The basic idea is borrowed from object oriented
design.However,the use case scenarios are given slightly more structure.
The central part of a use case scenario in Prometheus is the sequence of steps de-
scribing an example of the system in operation.Each step is annotated with the name
of the functionality responsible,as well as information used or produced.These anno-
tations allow cross checking for consistency with the functionality descriptors.
The use case templates which we use contain an identification number,a brief
natural language overview,an optional field called context which indicates when this
scenario would happen,or the start point of the scenario,the scenario itself which is
a sequence of steps,a summary of all the information used in the various steps,and
a list of small variations.Because a scenario captures only one particular sequence of
3
A number of methodologies call these“roles”.We prefer to avoid overloading the term since
it has a similar,but non-identical,meaning in the context of teams of agents.
steps it can be useful to indicate small variations with a brief description.Any major
variations should be a separate use case scenario.
3 Architectural design
The major decision to be made during the architectural design is which agents should
exist.We assign functionalities to agents by analysing the artifacts of the previous phase
to suggest possible assignments of functionalities to agents.These are then evaluated
according to the traditional software engineering criteria of coherence and coupling.
The process of identifying agents by grouping functionalities involves analysing the
reasons for and against groupings of particular functionalities.If functionalities use the
same data it is an indication for grouping them,as is significant interaction between
them.Reasons against groupings may be clearly unrelated functionality or existence on
different hardware platforms.More generally,we seek to have agents which have strong
coherence and loose coupling.
It can be useful at this stage to draw a matrix having all functionalities on one axis
and the properties or relationships on the other axis.Specific properties and relation-
ships that are useful in deriving groupings of functionalities are whether two function-
alities are related,whether they are clearly unrelated,the data used4 and data produced
as well as information received from other functionalities and data that is written by two
(or more)functionalities.The last two columns can be derived from the information in
the previous columns.
In order to evaluate a potential grouping for coupling we use an agent acquaintance
diagram.This diagram simply links each agent with each other agent with which it inter-
acts.A design with fewer linkages is less highly coupled and therefore preferable.The
design for the book store depicted below(on the right)is reasonable,since it indicates
low coupling.A design which produced an acquaintance diagram where each agent
was linked to every other agent would be highly undesirable.Note that Prometheus
uses a consistent notation to depict agents,events,plans,capabilities,etc.This notation
is summarised below,on the left.
A simple heuristic for assessing coherence is whether an agent has a simple descrip-
tive name which encompasses all the functionalities without any conjunctions(“and”).
For example,the shop assistant agent combines the functionalities of visit manager,
client welcomer,query processor,pro-active helper,and customer DB manager;yet it
has a simple descriptive name.
4
Both read(in the case of data stores)and received(in the case of events and messages).
Once a decision has been made as to which agents the system should contain it is
possible to start working out and describing some of the necessary information about
agents.The high level information about each agent is contained in the form of an
agent descriptor,similar to functionality descriptors.Questions which need to be re-
solved about agents at this stage include:How many agents of this type will there be
(singleton,a set number,or multiple based on dynamics of the system,e.g.one sales
assistant agent per customer)?What is the lifetime of the agent?If they are created or
destroyed during system operation(other than at start-up and shut-down),what triggers
this?Agent initialisation-what needs to be done?Agent demise-what needs to be
done?What data does this agent need to keep track of?What events will this agent
react to?
Agent descriptors contain the above information plus the name and description of
the agent,a brief description of ways in which it interacts with other agents and a list
of the functionalities which are incorporated within this agent.For example consider
the following agent descriptor:
Name:Shop assistant agent
Description:greets customer,follows through site,assists with finding books
Cardinality:1/customer.Instantiated on customer arrival at site
Functionalities included:visit manager,client welcomer,query processor,pro-active
helper,customer DB manager.
Reads data:user profile,client orders
Writes data:user profile
Interacts with:cashier(to pay for purchase);warehouse manager(to get price,avail-
ability and to hand over order for shipping)
Consistency checking should be done to ensure that agent descriptors are consistent
with the set of functionality descriptors which have been incorporated within the agent.
Particular items to check are the information,and the agent interactions.If a function-
ality is listed as interacting with another functionality,then this should translate into an
agent interaction,unless the two functionalities are incorporated within the same agent.
At this stage of the design it is important to identify what events(i.e.significant
occurrences)will be generated as a result of information from the environment(the
percepts),either directly or after processing.These are the things the agents will notice,
which will cause them to react in some way.A decision must be made as to which
agents will react to which events.
In order to accomplish the various aims of the system agents will also send messages
to each other.These must also be identified at this stage.It is also necessary to identify
what information fields will be carried in these messages,as this forms the interface
definition between the agents.
If the implementation platform does not provide specialised message types,these
must be specified precisely at this stage to enable modularity in the development of the
detailed design for the individual agents.
Shared data objects(if any)must also be identified at this stage.A good design
will minimise these,but there may be situations where it is reasonable to have shared
data objects.If multiple agents will be writing to shared data objects this will require
significant additional care for synchronisation(as agents operate concurrently with each