A knowledge level software engineering methodology for agent oriented programming.
Our goal in this paper is to introduce and motivate a methodology, called \emph{Tropos}, for building agent oriented software systems. Tropos is based on two key ideas. First, the notion of agent and all the related mentalistic notions (for instance: beliefs, goals, actions and plans) are used in all phases of software development, from the early analysis down to the actual implementation.  Second, Tropos covers also the very early phases of requirements analysis, thus allowing for a deeper understanding of the environment where the software must operate, and of the kind of interactions that should occur between software and human agents. The methodology is illustrated with the help of a case study.
INTRODUCTION
Agent oriented programming (AOP, from now on) is most
often motivated by the need of open architectures that continuously
change and evolve to accommodate new components
and meet new requirements. More and more, software
must operate on different platforms, without recompilation,
and with minimal assumptions about its operating environment
and its users. It must be robust, autonomous and
proactive. Examples of applications where AOP seems most
suited and which are most quoted in the literature [15] are
electronic commerce, enterprise resource planning, air-traffic
control systems, personal digital assistants, or book travel
arrangements, and so on.
To qualify as an agent, a software or hardware system is
often required to have properties such as autonomy, social
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
AGENTS'01, May 28-June 1, 2001, Montr- eal, Quebec, Canada.
ability, reactivity, proactivity. Other attributes which are
sometimes requested are mobility, veracity, rationality, and
so on. The key feature which makes it possible to implement
systems with the above properties is that, in this paradigm,
programming is done at a very abstract level, more precisely,
following Newell, at the knowledge level [13]. Thus, in AOP,
we talk of mental states, of beliefs instead of machine states,
of plans and actions instead of programs, of communication,
negotiation and social ability instead of interaction and I/O
functionalities, of goals, desires, and so on. Mental notions
provide, at least in part, the software with the extra flexibility
needed in order to deal with the complexity intrinsic
in the applications mentioned in the first paragraph. The
explicit representation and manipulation of goals and plans
allows, for instance, for a run-time "adjustment" of the system
behavior needed in order to cope with unforeseen cir-
cumstances, or for a more meaningful interaction with other
human and software agents. 1
We are defining a software development methodology, called
Tropos, which will allow us to exploit all the flexibility
provided by AOP. In a nutshell, the two key and novel features
of Tropos are the following:
1. The notion of agent and all the related mentalistic notions
are used in all phases of software development,
from the first phases of early analysis down to the
actual implementation. In particular our target implementation
agent language and system is JACK [3],
an agent programming platform, based on the BDI
(Beliefs-Desires-Intentions) agent architecture.
2. A crucial role is given to the earlier analysis of requirements
that precedes prescriptive requirements specifi-
cation. We consider therefore much earlier phases than
the phases supported in, for instance, OOP software
engineering methodologies. One such example are the
1 AOP is often introduced as a specialization or as a "natu-
ral development" of Object Oriented Programming (OOP),
see for instance [14, 11, 15]. In our opinion, the step from
OOP to AOP is more a paradigm shift than a simple spe-
cialization. Also those features of AOP which can be found
in OOP languages, for instance, mobility and inheritance,
take in this context a different and more abstract meaning.
methodologies based on UML [2] where use case analysis
is proposed as an early activity, followed by architectural
design. As described in detail below, this
move is crucial in order to achieve our objectives.
Our goal in this paper is to introduce and motivate the
Tropos methodology, in all its phases. The presentation
is carried out with the help of a running example. The
example considered is a fragment of a substantial software
system (which, in its full implementation, is requiring various
man years of work) developed for the government of
Trentino (Provincia Autonoma di Trento, or PAT). The system
(which we will call throughout the eCulture system) is a
web-based broker of cultural information and services for the
province of Trentino, including information obtained from
museums, exhibitions, and other cultural organizations and
events. It is the government's intention that the system be
usable by a variety of users, including Trentinos and tourists
looking for things to do, or scholars and students looking for
material relevant to their studies.
The paper is structured as follows. Section 2 introduces
the five basic steps of the Tropos methodology, namely, early
requirement analysis, late requirements analysis, architectural
design, detailed design, and implementation. The five
Tropos phases are then described, as applied in the context
of the eCulture system example, in Sections 3, 4, 5, 6 and 7.
The conclusions are presented in section 8.
This paper follows on two previous papers, [12] and [4],
which provide some motivations behind the Tropos project,
and an early glimpse of how the methodology works. With
respect to these earlier papers much more emphasis has been
put on the issue of developing knowledge level specifications.
2. THE TROPOS METHODOLOGY:
AN

OVERVIEW

Tropos is intended to support five phases of software development

ffl Early requirements, concerned with the understanding
of a problem by studying an existing organizational
setting; the output of this phase is an organizational
model which includes relevant actors and their respective
dependencies. Actors, in the organizational set-
ting, are characterized by having goals that, in iso-
lation, they would be unable to achieve; the goals are
achievable in virtue of reciprocal means-end knowledge
and dependencies [19].
ffl Late requirements, where the system-to-be is described
within its operational environment, along with relevant
functions and qualities; this description models
the system as a (small) number of actors, which have
a number of social dependencies with other actors in
their environment.
ffl Architectural design, where the system's global architecture
is defined in terms of subsystems, interconnected
through data and control flows; in our frame-
work, subsystems are represented as actors while data
and control interconnections correspond to actor de-
pendencies. In this step we specify actor capabilities
and agents types (where agents are special kinds of
actors, see below). This phase ends up with the specification
of the system agents.
ffl Detailed design, where each agent of the system architecture
is defined in further detail in terms of internal
and external events, plans and beliefs and agent communication
protocols.
Implementation, where the actual implementation of
the system is carried out in JACK, consistently with
the detailed design.
The idea of paying attention to the activities that precede
the specification of the prescriptive requirements, such as
understanding how the intended system would meet the organizational
goals, is not new. It was first proposed in the
requirements engineering literature (see for instance [7, 18]).
In particular we adapt ideas from Eric Yu's model for requirements
engineering, called i *, which offers actors, goals
and actor dependencies as primitive concepts [18]. 2 The
main motivation underlying this earlier work was to develop
a richer conceptual framework for modeling processes which
involve multiple participants (both humans and computers).
The goal was to have a more systematic reengineering of pro-
cesses. One of the main advantages is that, by doing this
kind of analysis, one can also capture not only the what or
the how but also the why a piece of software is developed.
This, in turn, allows for a more refined analysis of the system
dependencies and, in particular, for a much better and
uniform treatment not only of the system's functional requirements
but also of the non-functional requirements (the
latter being usually very hard to deal with).
Neither Yu's work, nor, as far as we know, any of the
previous work in requirements analysis was developed with
AOP in mind. The application of these ideas to AOP, and
the decision to use mentalistic notions in all the phases of
analysis, has important consequences. When writing agent
oriented specifications and programs one uses the same notions
and abstractions used to describe the behavior of the
human agents, and the processes involving them. The conceptual
gap from what the system must do and why, and
what the users interacting with it must do and why, is reduced
to a minimum, thus providing (part of) the extra
flexibility needed to cope with the complexity intrinsic in
the applications mentioned in the introduction.
Indeed, the software engineering methodologies and specification
languages developed in order to support OOP essentially
support only the phases from the architectural design
downwards. At that moment, any connection between the
intentions of the different (human and software) agents cannot
be explicitly specified. By using UML, for instance, the
software engineer can start with the use case analysis (possi-
bly refined by developing some activity diagrams) and then
moves to the architectural design. Here, the engineer can
do static analysis using class diagrams, or dynamic analysis
using, for instance, sequence or interaction diagrams. The
target is to get to the detail of the level of abstraction allowed
by the actual classes, methods and attributes used
to implement the system. However, applying this approach
and the related diagrams to AOP misses most of the advantages
coming for the fact that in AOP one writes programs
at the knowledge level. It forces the programmer to translate
goals and the other mentalistic notions into software level
notions, for instance the classes, attributes and methods ofi * has been applied in various application areas, including
requirements engineering [17], business process reengineering
[21], and software modeling processes [20].
cCultural
infrastructure
System
usable
spent
services
increase
internet
taxes well
enjoy visit
System
eCulture
Visitor
eCulture
Museum
Citizen
internet use
available
available
provide
get cultural
information
dependee
depender dependum
goal softgoal
actor
goal dependency

Figure

1: An actor diagram specifying the stake-holders
of the eCulture project and their main goal
dependencies.
class diagrams. The consequent negative effect is that the
former notions must be reintroduced in the programming
phase, for instance when writing JACK code: the programmer
must program goals, beliefs, and plans, having lost the
connection with the original mentalistic notions used in the
early and late requirements. The work on AUML [1, 10],
though relevant in that it provides a first mapping from
OOP to AOP specifications, is an example of work suffering
from this kind of problem.
In the following sections we present the five Tropos phases
as applied in the context of the eCulture system example.
3. EARLY REQUIREMENTS
During early requirements analysis, the requirements engineer
models and analyzes the intentions of the stakehold-
ers. Following i *, in Tropos the stakeholders' intentions
are modeled as goals which, through some form of a goal-oriented
analysis, eventually lead to the functional and non-functional
requirements of the system-to-be. Early requirements
are assumed to involve social actors who depend on
each other for goals to be achieved, tasks to be performed,
and resources to be furnished. Tropos includes actor diagrams
for describing the network of social dependency relationships
among actors, as well as rationale diagrams for
analyzing and trying to fulfill goals through a means-ends
analysis. 3 These primitives are formalized using intentional
concepts from AI, such as goal, belief, ability, and commitment

An actor diagram is a graph, where each node represents
an actor, and a link between two actors indicates that one
actor depends, for some reason, on the other in order to attain
some goal. We call the depending actor the depender
and the actor who is depended upon the dependee. The
object around which the dependency centers is called the
In i * actor diagrams are called strategic dependency mod-
els, while rationale diagrams are called strategic rationale
models.
internet use
System
build
citizens
increase
services
reasonable
expenses
taxes well
provide
educate
eCultural
provide
interesting
systems
funds for
cultural IS
System
offer
inexpensive
infrastructure
funding
museums for
own systems
eCulture
Museum
services
good
internet
infrastructure
available
good cultural
services
spent
available
eCulture

Figure

2: A rational diagram for PAT. The rectangular
box added to a dependency, models a resource
dependency.
dependum (see, e.g., Figure 1). By depending on another
actor for a dependum, an actor is able to achieve goals that
it would otherwise be unable to achieve on its own, or not
as easily, or not as well. At the same time, the depender
becomes vulnerable. If the dependee fails to deliver the de-
pendum, the depender would be adversely affected in its
ability to achieve its goals.
In our eCulture example we can start by informally listing
(some of) the stakeholders:
ffl Provincia Autonoma di Trento (PAT), that is the government
agency funding the project; their objectives
include improving public information services, increase
tourism through new information services, also encouraging
Internet use within the province.
ffl Museums, that are cultural information providers for
their respective collections; museums want government
funds to build/improve their cultural information ser-
vices, and are willing to interface their systems with
the eCulture system.
ffl Visitors, who want to access cultural information before
or during their visit to Trentino to make their visit
interesting and/or pleasant.
ffl (Trentino) Citizens, who want easily accessible infor-
mation, of any sort.
These stakeholders correspond to actors in an actor dia-
gram. Notice that citizens and visitors correspond to (hu-
man) agents while this is not the case for the other two stake-
holders. Museums and PAT correspond, rather, to roles. An
actor is an agent, a role or a position, according to the fact
that the actor is a well identified (human or software) entity
(agent), it is a function (role) that can be played by an
agent, or collects a set of roles that are usually played by a
single agent (position).

Figure

1 shows the actors involved in the eCulture project
and their respective goals. In particular, PAT is associated
with a single relevant goal: increase internet use, while
Visitor and Museum have associated softgoals, enjoy visit
and provide cultural services respectively. Softgoals are
distinguished from goals because they don't have a formal
definition, and are amenable to a different (more qualita-
tive) kind of analysis (see [5] for a detailed description of
softgoals). Citizen wants to get cultural information and
depends on PAT to fulfill the softgoal taxes well spent, a
high level goal that motivates more specific PAT's respon-
sibilities, namely to provide an Internet infrastructure, to
deliver on the eCulture system and make it usable too.
The early requirements analysis goes on extending the
actor diagram by incrementally adding more specific actor
dependencies which come out from a means-ends analysis
of each goal. We specify this analysis using rationale diagrams

Figure

2 depicts a fragment of one such diagram,
obtained by exploding part of the diagram in Figure 1,
where the perspective of PAT is modeled. The diagram appears
as a balloon within which PAT's goals are analyzed
and dependencies with other actors are established. This
example is intended to illustrate how means-ends analysis is
conducted. Throughout, the idea is that goals are decomposed
into subgoals and positive/negative contributions of
subgoals to goals are specified. Thus, in Figure 2, the goals
increase internet use and eCulture system available
are both well served by the goal build eCulture System.
The (high level) softgoal taxes well spent gets two positive
contributions, which can be thought as justifications
for the selection of particular dependencies. The final result
of this phase is a set of strategic dependencies among
actors, built incrementally by performing means-ends analysis
on each goal, until all goals have been analyzed. The
later it is added, the more specific a goal is. For instance, in
the example in Figure 2 PAT's goal build eCulture system
is introduced last and, therefore, has no subgoals and it is
motivated by the higher level goals it fulfills. 4
4. LATE REQUIREMENTS
During late requirement analysis the system-to-be (the
eCulture System in our example) is described within its operating
environment, along with relevant functions and qual-
ities. The system is represented as one or more actors which
have a number of dependencies with the actors in their en-
vironment. These dependencies define all functional and
non-functional requirements for the system-to-be.

Figure

3 illustrates the late requirements actor diagram
where the eCulture System actor has been introduced. The
PAT depends on it to provide eCultural services, one of
the PAT's subgoals discovered during the means-end analysis
depicted in Figure 2. The softgoal usable eCulture
system, for which Citizen depends on PAT (see Figure 1),
has been delegated by PAT to the eCulture system. More-
over, the eCulture System is expected to fulfill other PAT
softgoals such as extensible eCulture system, flexible
In rationale diagrams one can also introduce tasks and resources
and connect them to the fulfillment of goals.
System
available
flexible
temporal
eCulture
scalable
available
eCultural
usable
eCulture
provide
provide
eCulture
educational
eCulture
System
eCulture
user friendly
System
eCulture
info services
technology
provide
services
System
use internet
System
usable
System
System
eCulture
extensible
eCultural
services
services
eCultural
logistic info cultural info
portable
make
reservations
virtual
visit
provide

Figure

3: A fragment of the actor diagram including
the PAT and the eCulture System actors; the rationale
diagram for the eCulture System is detailed within
the balloon.
eCulture system, and use internet technology. The balloon
in Figure 3 shows how two of the PAT's dependums can
be further analyzed from the point of view of the eCulture
System. The goal provide eCultural services is decomposed
(AND decomposition) into four subgoals: make re-
servation, provide info, educational services and virtual
visit that can be further specified along a subgoal
hierarchy. For instance, the types of information that the
system has to provide are both logistical (timetables and visiting
instructions for museums), and cultural (for instance,
cultural content of museums and special cultural events).
The rationale diagram includes also a softgoal analysis.
The usable eCulture system softgoal has two positive (+)
contributions from user friendly eCulture system and available
eCulture system. This latter softgoal in turns
specifies the following three basic non-functional require-
ments: system portability, scalability, and availability over
time.
Starting from this analysis, the system-to-be actor can
be decomposed into sub-actors that take on the responsibility
of fulfilling one or more goals of the system. Figure 4
shows the resulting eCulture System actor diagram: the
eCulture System depends on the Info Broker to provide
info, on the Educational Broker to provide educational
services, on the Reservation Broker to make reserva-
tion, on the Virtual Visit Broker to provide virtual
interfacing
provide
system
educational
Broker
interface
eCulture
Educational
System
services
Broker
Info
Broker
System
Manager
System
Interface
Manager
Interface
User
Manager
make
reservations
virtual
visits
provide info
interfacing
user
Virtual
Visit
Reservation
Broker

Figure

4: The system actor diagram. Sub-actors
decomposition for the eCulture System.
visit, and on the System Manager to provide interface.
Furthermore each sub-actor can be further decomposed in
sub-actors responsible for the fulfillment of one or more sub-goals

At this point of the analysis we can look into the actor diagram
for a direct dependency between the Citizen, which
plays the role of system user, and the eCulture System. In
other words we can now see how the former Citizen's goal
get cultural information can be fulfilled by the current
eCulture System. The rational diagram of this goal depen-
dency, see Figure 5, provides a sort of use-case analysis [9].
5. ARCHITECTURAL DESIGN
The architectural design phase consists of three steps:
1. refining the system actor diagram
2. identifying capabilities and
3. assigning them to agents.
In the first step the system actor diagram is extended according
to design patterns [8] that provide solutions to heterogeneous
agents communication and to non-functional re-
quirements. 5 Figure 6 shows the extended actor diagram
with respect to the Info Broker. 6 The User Interface
Manager and the Sources Interface Manager are responsible
for interfacing the system to the external actors Citizen
and Museum respectively.
The second step consists in capturing actor capabilities
from the analysis of the tasks that actors and sub-actors will
carry on in order to fulfill functional requirements (goals).
A capability is the set of events, plans and beliefs necessary
for the fulfillment of actor goals. Figure 7 shows
5 In this step design patterns for agent systems are mapped
to actor diagrams.
6 For the sake of readability we do not show all the actors
needed to take into account other non-functional require-
ments, e.g., system extensibility and user friendliness.
source
query result
Citizen
area
search
information
info about
specification
area
get cultural
eCulture
System
information
classify
search by
synthesize
geographical
area results search by
keywords
search by
area
Museum
get info on
area
query
sources
find info
sources
search by
time period

Figure

5: Rationale diagram for the goal get
cultural information. Hexagonal shapes model
tasks. Task decomposition links model task-subtask
relationships. Goal-task links are a type of means-ends
links.
an example for the Info Broker actor analysis, with respect
to the goal of searching information by topic area.
The Info Broker is decomposed into three sub-actors: the
Area Classifier, the Results Synthesizer, and the Info
Searcher. The Area Classifier is responsible for the classification
of the information provided by the user. It depends
on the User Interface Manager for the goal interfacing
to users. The Info Searcher depends on the Area Classifier
to have (thematic) area information that the user
is interested in, and depends on the Sources Interface
Manager for the goal interfacing to sources (the Museum).
The Results Synthesizer depends on the Info Searcher
for the information concerning the pending query (query
information) and on the Museum to have the query results.
Manager
Citizen
Interface
User Sources
Interface
Manager
Broker
Info
interfacing
to users to sources
interfacing
to the
System
interfacing
eCulture eCulture
System
interfacing
to the
Museum

Figure

Extended actor diagram, Info Broker.
Interface
Manager
Sources
Citizen
query
results
interfacing
interfacing
interfacing
to the
eCulture
System System
area
to sources
to the
Synthesizer
Broker
specification
area
eCulture
information
Results
Info
Classifier
Area
information
query
information
area
Searcher
Info
Museum
Interface
User
Manager
interfacing
to users

Figure

7: Actor diagram for capability analysis, Info Broker.
Capabilities can be easily identified by analyzing the diagram
in Figure 7. In particular each dependency relationship
gives place to one or more capabilities triggered by external
events. Table 1 lists the capabilities associated to the
extended actor diagram of Figure 7. They are listed with
respect to the system-to-be actors, and then numbered in
order to eliminate possible copies whereas.
Actor Name N Capability
Area Classifier 1 get area specification form
classify area
3 provide area information
4 provide service description
Info Searcher 5 get area information
6 find information source
7 compose query
8 query source
9 provide query information
provide service description
query information
get query results
12 provide query results
synthesize area query results
provide service description
Sources Interface 14 wrap information source
Manager provide service description
User Interface 15 get user specification
Manager user specification
get query results
present query results to the user
provide service description

Table

1: Actors capabilities
Agent Capabilities
Query Handler 1, 3, 4, 5, 7, 8, 9, 10, 11, 12
Classifier 2, 4
Searcher 6, 4
Synthesizer 13, 4
Wrapper 14, 4
User Interface Agent 15, 16, 17, 18, 4

Table

2: Agent types and their capabilities
The last step of the architectural design consists in defining
a set of agent types and in assigning to each agent one
or more different capabilities (agent assignment). Table 2
reports the agents assignment with respect to the capabilities
listed in Table 1. The capabilities concern exclusively
the task search by area assigned to the Info Broker. Of
course, many other capabilities and agent types are needed
in case we consider all the goals and tasks associated to the
complete extended actor diagram.
In general, the agents assignment is not unique and depends
on the designer. The number of agents and the capabilities
assigned to each of them are choices driven by
the analysis of the extended actor diagram and by the way
in which the designer thinks the system in term of agents.
Some of the activities done in architectural design can be
compared to what Wooldridge et al. propose to do within
the Gaia methodology [16]. For instance, what we do in actor
diagram refinement can be compared to "role modeling"
in Gaia. We instead consider also non-functional require-
ments. Similarly, capability analysis can be compared to
"protocols modeling", even if in Gaia only external events
are considered.
evaluate query
results
present empty
results present query
results
E:(empty result set)
Query results
EE: inform(SIA, UIA, query results)

Figure

8: Capability diagram using the AUML activity
diagram. Ovals represent plans, arcs internal
and external events.
6. DETAILED DESIGN
The detailed design phase aims at specifying agent capabilities
and interactions. The specification of capabilities
amounts to modeling external and internal events that trigger
plans and the beliefs involved in agent reasoning. Practical
approaches to this step are often used. 7 In the paper
we adapt a subset of the AUML diagrams proposed in [1].
In particular:
1. Capability diagrams. The AUML activity diagram allows
to model a capability (or a set of correlated ca-
pabilities), from the point of view of a specific ac-
tor. External events set up the starting state of a
capability diagram, activity nodes model plans, transition
arcs model events, beliefs are modeled as ob-
jects. For instance, Figure 8 depicts the capability diagram
of the query results capability of the User
Interface Agent.
2. Plan diagrams. Each plan node of a capability diagram
can be further specified by AUML action diagrams.
3. Agent interaction diagrams. Here AUML sequence diagrams
can be exploited. In AUML sequence diagrams,
agents corresponds to objects, whose life-line is independent
from the specific interaction to be modeled
(in UML an object can be created or destroyed during
the interaction); communication acts between agents
correspond to asynchronous message arcs. It can be
shown that sequence diagrams modeling Agent Inter-action
Protocols, proposed by [10], can be straightforwardly
applied to our example.
7 For instance the Data-Event-Plan diagram used by JACK
developer. Ralph R-onnquist, personal communication.
7. IMPLEMENTATION USING A BDI AR-
The BDI platform chosen for the implementation is JACK
Intelligent Agents, an agent-oriented development environment
built on top and fully integrated with Java. Agents in
JACK are autonomous software components that have explicit
goals (desires) to achieve or events to handle. Agents
are programmed with a set of plans in order to make them
capable of achieving goals.
The implementation activity follows step by step, in a natural
way, the detailed design specification described in section
6. In fact, the notions introduced in that section have a
direct correspondence with the following JACK's constructs,
as explained below:
Agent. A JACK's agent construct is used to define the
behavior of an intelligent software agent. This includes
the capabilities an agent has, the types of messages and
events it responds to and the plans it uses to achieve
its goals.
Capability. A JACK's capability construct can include
plans, events, beliefs and other capabilities. An agent
can be assigned a number of capabilities. Furthermore,
a given capability can be assigned to different agents.
JACK's capability provides a way of applying reuse
concepts.
ffl Belief. Currently, in Tropos, this concept is used only
in the implementation phase, but we are considering
to move it up to earlier phases. The JACK's database
construct provides a generic relational database. A
database describes a set of beliefs that the agent can
have.
ffl Event. Internal and external events specified in the
detailed design map to the JACK's event construct.
In JACK an event describes a triggering condition for
actions.
ffl Plan. The plans contained into the capability specification
resulting from the detailed design level map
to the JACK's plan construct. In JACK a plan is
a sequence of instructions the agent follows to try to
achieve goals and handle designed events.
As an example, the definition for the UserInterface agent,
in JACK code, is as follows:
public agent UserInterface extends Agent -
#has capability GetQueryResults;
#has capability ProvideUserSpecification;
#has capability GetUserSpecification;
#has capability PresentQueryResults;
#handles event InformQueryResults;
#handles event ResultsSet;
The capability PresentQueryResults, analyzed in detail in
the previous section (see Figure 8) is defined as follows:
public capability PresentQueryResults
extends Capability -
#handles external event InformQueryResults;
#posts event ResultsSet;
#posts event EmptyResultsSet;
#private database QueryResults();
#private database ResultsModel();
#uses plan EvaluateQueryResults;
#uses plan PresentEmptyResults;
#uses plan PresentResults;
8. CONCLUSIONS
In this paper we have proposed Tropos, a new software
engineering methodology which allows us to exploit the advantages
and the extra flexibility (if compared with other
programming paradigms, for instance OOP) coming from
using AOP. The two main intuitions underlying Tropos are
the pervasive use, in all phases, of knowledge level specifi-
cations, and the idea that one should start from the very
early phase of early requirements specification. This allows
us to create a continuum where one starts with a set of mentalistic
notions (e.g., beliefs, goals, plans), always present in
(the why of) early requirements, and to progressively convert
them into the actual mentalistic notions implemented in an
agent oriented software. This direct mapping from the early
requirements down to the actual implementation allows us to
develop software architectures which are "well tuned" with
the problems they solve and have, therefore, the extra flexibility
needed in the complex applications mentioned in the
introduction.
Several open points still remain. The most important are:
we should be able to use concepts such as beliefs and events
as early as possible in the Tropos methodology; we should
be able to exploit adaptation and reuse concepts during all
the activities in the development process, as well as to support
an iterative process; we should be able to extend the
Tropos process also to other important activities of software
engineering, such as testing, deployment and maintenance.
9.

ACKNOWLEDGMENTS

The knowledge that Paolo Busetta has of JACK has been
invaluable. Without him this paper would have been much
harder to write. We'd like to thank also Ralph R-onnquist
and Manuel Kolp for their helpful comments.
10.



--R

Agent UML: A formalism for specifying multiagent interaction.
The Unified Modeling Language User Guide.
Jack intelligent agents - components for intelligent agents in java
Developing agent-oriented information systems for the enterprise


"goal"
Architectural design patterns for multiagent coordination.


On agent-based software engineering
Tropos: A Framework for Requirements-Driven Software Development
The knowledge level.

Intelligent agents: Theory and practice.
The Gaia methodology for agent-oriented analysis and design
Modeling organizations for information systems requirements engineering.
Modeling Strategic Relationships for Process Reengineering.
"A-R" - modeling strategic actor relationships for business process reengineering
Understanding 'why' in software process modeling
Using goals
--TR
Agent-oriented programming
Goal-directed requirements acquisition
Understanding MYAMPERSANDldquo;whyMYAMPERSANDrdquo; in software process modelling, analysis, and design
Modelling strategic relationships for process reengineering
The Unified Modeling Language user guide
On agent-based software engineering
The Gaia Methodology for Agent-Oriented Analysis and Design
From E-R to "A-R" - Modelling Strategic Actor Relationships for Business Process Reengineering

--CTR
Jorge J. Gmez-Sanz , Juan Pavn , Francisco Garijo, Meta-models for building multi-agent systems, Proceedings of the 2002 ACM symposium on Applied computing, March 11-14, 2002, Madrid, Spain
Ghassan Beydoun , Cesar Gonzalez-Perez , Graham Low , Brian Henderson-Sellers, Synthesis of a generic MAS metamodel, ACM SIGSOFT Software Engineering Notes, v.30 n.4, July 2005
Haibin Zhu , MengChu Zhou, Methodology first and language second: a way to teach object-oriented programming, Companion of the 18th annual ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications, October 26-30, 2003, Anaheim, CA, USA
Rubn Fuentes , Jorge J. Gmez-Sanz , Juan Pavn, Integrating agent-oriented methodologies with UML-AT, Proceedings of the fifth international joint conference on Autonomous agents and multiagent systems, May 08-12, 2006, Hakodate, Japan
Haralambos Mouratidis , Paolo Giorgini , Gordon Manson, Modelling secure multiagent systems, Proceedings of the second international joint conference on Autonomous agents and multiagent systems, July 14-18, 2003, Melbourne, Australia
Fausto Giunchiglia , John Mylopoulos , Anna Perini, The tropos software development methodology: processes, models and diagrams, Proceedings of the first international joint conference on Autonomous agents and multiagent systems: part 1, July 15-19, 2002, Bologna, Italy
Franco Zambonelli , Nicholas R. Jennings , Michael Wooldridge, Developing multiagent systems: The Gaia methodology, ACM Transactions on Software Engineering and Methodology (TOSEM), v.12 n.3, p.317-370, July
Anthony Karageorgos , Simon Thompson , Nikolay Mehandjiev, Agent-Based System Design for B2B Electronic Commerce, International Journal of Electronic Commerce, v.7 n.1, p.59-90, Number 1/Fall 2002
Liliana Ardissono , Anna Goy , Giovanna Petrone , Marino Segnan, A multi-agent infrastructure for developing personalized web-based systems, ACM Transactions on Internet Technology (TOIT), v.5 n.1, p.47-69, February 2005
Anthony Karageorgos , Nikolay Mehandjiev , Simon Thompson, RAMASD: a semi-automatic method for designing agent organisations, The Knowledge Engineering Review, v.17 n.4, p.331-358, December 2002
Greg Brown , Betty H. C. Cheng , Heather Goldsby , Ji Zhang, Goal-oriented specification of adaptation requirements engineering in adaptive systems, Proceedings of the 2006 international workshop on Self-adaptation and self-managing systems, May 21-22, 2006, Shanghai, China
Anna Perini , Angelo Susi , Fausto Giunchiglia, Coordination specification in multi-agent systems: from requirements to architecture with the Tropos methodology, Proceedings of the 14th international conference on Software engineering and knowledge engineering, July 15-19, 2002, Ischia, Italy
Paolo Bresciani , Anna Perini , Paolo Giorgini , Fausto Giunchiglia , John Mylopoulos, Tropos: An Agent-Oriented Software Development Methodology, Autonomous Agents and Multi-Agent Systems, v.8 n.3, p.203-236, May 2004
Jaelson Castro , Manuel Kolp , John Mylopoulos, Towards requirements-driven information systems engineering: the Tropos project, Information Systems, v.27 n.6, p.365-389, September 2002
Manuel Kolp , Paolo Giorgini , John Mylopoulos, Multi-Agent Architectures as Organizational Structures, Autonomous Agents and Multi-Agent Systems, v.13 n.1, p.3-25, July      2006
agent-based software engineering;design methodologies