Prometheus 3/4

other).Often what at first appears to be a shared data object can be reconceptualised as
a data source managed by a single agent,with information provided to other agents
as they need it.Alternatively each agent may have its own version of the information,
without there being any need for a single centralised data object.Data objects should
be specified using traditional object oriented techniques.
bo
The system overview dia-
gram ties together the agents,
events and shared data objects.It
is arguably the single most im-
portant artifact of the entire de-
sign process,although of course it
cannot really be understood fully
in isolation.By viewing this dia-
gram we obtain a general under-
standing of how the system as a
whole will function.Messages be-
tween agents can include a reply,
although this is not shown explic-
itly on the diagram.Looking further at agent descriptors provides any additional detail
needed to understand the high level functioning of the system.
The final aspect of the architectural design is to specify fully the interaction be-
tween agents.Interaction diagrams are used as an initial tool for doing this,while fully
specified interaction protocols are the final design artifact.
Interaction diagrams are borrowed directly from object oriented design,showing
interaction between agents rather than objects.One of the main processes for devel-
oping interaction diagrams is to take the use cases developed in the specification phase
and to build corresponding interaction diagrams.Wherever there is a step in the use case
which involves a functionality from a new agent there must be some interaction from
a previously involved agent to the newly participating agent.While it is not possible
to automatically derive the interaction diagrams from the use cases,substantial consis-
tency checking is possible.Figure 1(left)shows an interaction diagram for a scenario
of buying a book at our electronic bookstore.It depicts the user requesting a particular
book from the sales assistant which checks the details with the warehouse then replies.
The user decides to buy the book and places an order;the sales assistant checks for
delivery options,confirms them with the user,checks the user’s credit card details with
the cashier,and then places the order and thanks the user.In addition to deriving inter-
action diagrams from use cases,each of the major environmental events should have an
associated interaction diagram.
Interaction diagrams,like use cases,give only a partial picture of the system’s be-
haviour.In order to have a precisely defined system we progress from interaction dia-
grams to interaction protocols which define precisely which interaction sequences are
valid within the system.
Figure 1(right)shows the protocol for the credit check portion of the interaction
diagram shown in figure 1(left).Because protocols must show all variations they are
often larger than the corresponding interaction diagram and may need to be split into
smaller chunks.We use the AUML notation[19]to specify protocols,
Consistency checking should be done between protocols and interaction diagrams,
the system overview diagram,and use cases.With the appropriate tools,much of this
consistency checking can be automated.
4 Detailed design
Detailed design focuses on developing the internal structure of each of the agents and
how it will achieve its tasks within the system.It is at this stage of the design that
the methodology becomes specific to agents that use user-defined plans,triggered by
goals or events,such as the various implementations of Belief,Desire,Intention(BDI)
systems(e.g.PRS,dMARS,JAM,or JACK).A number of details regarding the im-
plementation platform also become evident at this stage when looking at any particular
design.However,the principles are easily adapted to the specifics of whichever devel-
opment platform has been chosen,as long as it is within the broad general category of
agents which use plans and react to events.
The focus of the detailed design phase is on defining capabilities(modules within
the agent),internal events,plans and detailed data structures.A progressive refinement
process is used which begins by describing agents’internals in terms of capabilities.The
internal structure of each capability is then described,optionally using or introducing
further capabilities.These are refined in turn until all capabilities have been defined.At
the bottom level capabilities are defined in terms of plans,events,and data.
The functionalities from the specification phase provide a good initial set of capa-
bilities,which can be further refined if desired.Sometimes there is also functionality
akin to“library routines”which is required in multiple places-either within multiple
agents,or within multiple capabilities within a single agent.Such functionality should
also be extracted into a capability which can then be included into other capabilities or
agents as required.
Capabilities are allowed to be nested within other capabilities and thus this model
allows for arbitrarily many layers within the detailed design,in order to achieve an
understandable complexity at each level.
Each capability should be described by a capability descriptor which contains in-
formation about the external interface to the capability-which events are inputs and
which events are produced by(as inputs to other capabilities).It also contains a natu-
ral language description of the functionality,a unique descriptive name,information
regarding interactions with other capabilities,or inclusions of other capabilities,and
a reference to data read and written by the capability.We use structured capability
descriptor forms containing the above fields.
The agent overview diagram provides the top level view of the agent internals.It
is very similar in style to the system overview diagram,but instead of agents within a
system,it shows capabilities within an agent.This diagram shows the top level capabil-
ities of the agent and the event or task flow between these capabilities,as well as data
internal to the agent.By reading the relevant capability descriptors,together with the
diagram,it is possible to obtain a clear high level view of how the modules within the
agent will interact to achieve the overall tasks of the agent as described in the agent
descriptor from the architectural design.
The agent overview diagram below is for a warehouse manager agent in the elec-
tronic bookstore.This agent has the capabilities of tracking stock,placing orders for
new stock and organising delivery of books to clients.
A further level of detail is
provided by capability diagrams
which take a single capability and
describe its internals.At the bot-
tom level these will contain plans,
with events providing the connec-
tions between plans,just as they do
between capabilities and between
agents.At intermediate levels they
may contain nested capabilities or
a mixture of capabilities and plans.
These diagrams are similar in style to the system overview and agent overview diagram,
although plans are constrained to have a single incoming(triggering)event.
Just as the agent overview diagram should be checked for consistency with the sys-
tem overview(in terms of incoming and outgoing events),so each capability overview
diagram should be checked against its enclosing context-either the agent overview,or
another capability overview.
The final design artifacts required are the individual plan,event and data descriptors.
These descriptions provide the details necessary to move into implementation.Exactly
what are the appropriate details for these descriptors will depend on aspects of the
implementation platform.For example if the context in which a plan type is to be used
is split into two separate checks within the system being used(as is the case in JACK)
then it is appropriate to specify these separately in the descriptor.Fields regarding what