Prometheus 4/4

information an event carries assumes that events are composite objects able to carry
information,and so on.
The plan descriptors we use provide an identifier,the triggering event type,the
plan steps as well as a short natural language description,a context specification in-
dicating when this plan should be used and a list of data read and written.
Event descriptors are used to fully specify all events,including those identified ear-
lier.The event descriptor should identify the purpose of the event and any data that
the event carries.We also indicate for each event whether it is expected to be covered
and whether it is expected to be unambiguous.An event is covered if there is always at
least one handling plan which is applicable;that is,for any situation,at least one of the
matching plans will have a true context condition.An event is unambiguous if there is
always at most one handling plan which is applicable.
Data descriptors should specify the fields and methods of any classes used for data
storage within the system.If specialised data structures are provided for maintaining
beliefs,these should also be specified.
An additional artifact that is completed(and checked)at this point is the data dic-
tionary.The data dictionary should be started at the beginning of the project and devel-
oped further at each stage.The data dictionary is important in ensuring consistent use
of names(for example,what is called“delivery info”in one place in the design should
not be called“deliv.information”elsewhere).One option is to organise the data dic-
tionary into separate sections for agents,capabilities,plans,events and data,organised
alphabetically within sections.The other option is to have a flat alphabetical structure.
With tool support multiple views(automatically generated)can be provided.
5 Discussion and conclusions
We have briefly described the key aspects of the Prometheus methodology.The method-
ology has been in use for several years and has been taught in industry workshops(most
recently at the Australian AI conference,2001).The methodology has been in use for
several years as a teaching tool.The feedback we have received indicates that it provides
substantial guidance for the process of developing the design and for communicating
the design within a work group.With student projects it is abundantly clear that the
existence of the methodology is an enormous help in thinking about and deciding on
the design issues,as well as conveying the design decisions.
One of the advantages of this
methodology is the number of places
where automated tools can be used for
consistency checking across the vari-
ous artifacts of the design process.For
example,the input and output events
for an agent must be the same on the
system overview diagram and on the
agent overview diagram.Agent Ori-
ented Software has constructed a sup-
port tool for the methodology that al-
lows design diagrams to be drawn and generates corresponding skeleton code(in
JACK).
We are also investigating how some of the design artifacts,such as the protocol
definitions,and the capability diagrams,can be used for providing debugging and trac-
ing support within the implemented system[21].Having a design methodology which
can be used through to testing and debugging is clearly advantageous in terms of an
integrated and complete methodology.
Other areas for future work include:clearer integration of goals as a first class con-
cept,extensions to the graphical notation to allow percepts,actions,goals,and(some)
sequencing information to be specified;introduction of social concepts(teams,roles);
and investigating the commonalities and differences with various extensions of UML to
agents[19,20].Additionally,we intend to integrate Prometheus with the agent concepts
we have identified[26].
Acknowledgements:We would like to acknowledge the support of Agent Ori-
ented Software Pty.Ltd.and of the Australian Research Council(ARC)under grant
CO0106934.We would also like to thank James Harland and Jamie Curmi for com-
ments on drafts of this paper.