Constructing Intelligent
Agents Using Java
Joseph P. Bigus & Jennifer Bigus
Wiley, 2001
Ch.1 Introduction
Events, Conditions, and Actions
Agents vs. Objects
Taxonomies of Agents
Using Java for Intelligent Agents
Introduction
Events, Conditions, and Actions
Agents vs. Objects
Taxonomies of Agents
Using Java for Intelligent Agents
Events, Conditions, and
Actions
To deal with events
Anything that happens to change the environment
Anything of which the agent should be aware
To recognize conditions
What the event means
What the significance of the event is
To take actions
Assistance for user
Level of trust
Introduction
Events, Conditions, and Actions
Agents vs. Objects
Taxonomies of Agents
Using Java for Intelligent Agents
Agents vs. Objects
Distributed objects
Applications defined by objects, data, and
methods
Interactions between objects explicitly
defined
Actions performed by using other objects
No initiation of actions
Agents vs. Objects (cont.)
Multiagent system
Collection of software entities that
autonomously perform actions
Complex internal state and goals
Own decisions
Ability of dynamical role changes
Agents vs. Objects (cont.)
Achieving a single application goal
Functions provided by objects
Cooperation
Working
Method calls
Conversations
Communication
Buttons to be pushed
Entity to push the buttons
Introduction
Events, Conditions, and Actions
Agents vs. Objects
Taxonomies of Agents
Using Java for Intelligent Agents
Taxonomies of Agents
Agency, Intelligence, and Mobility
Processing Strategies
Processing Functions
Agency, Intelligence, and
Mobility
Agency
Degree of autonomy the software agent
has in representing the user
Purpose
to represent the user
to help the user
to guide the user
to take actions on the user’
s behalf
Agency, Intelligence, and
Mobility (cont.)
Intelligence
Ability of the agent to capture and apply
application domain specific knowledge and
processing to solve problems
Mobility
Ability of moving between systems in a
network
Concern about security and cost
Processing Strategies
Reflex agents
No internal models of the world
Response based only on external stimuli
Emergent behavior resulted from the
interactions of simple individual agents
Behavior grounded in physical sensor data
and NOT operating in the artificial symbol
space
Processing Strategies (cont.)
Deliberative agents
Domain knowledge
Planning capability
Active cooperation
Collaborative agents
Problem solving by working together
Communication
Ability of solving large problems
Processing Strategies (cont.)
Beliefs, desires, and intensions (BDI)
Belief
knowledge about the state of the world
what the agent believes to be true about the world
Desires
Assignments of goodness to states of the world
Goals
Intentions
What course of action to take
Committed plans
BDI Agents
beliefs (B), desires (D) (or goals (G)), intentions (I)
Systems and formalisms that give primary importance to
intentions are often referred to as BDI-architectures.
intentions
“partial plans of action that the agent is committed to execute to
fulfill her goals”
temporal sequences of an agent's beliefs and goals
Anand S. Rao and Michael P. Georgeff, “ Modeling Rational
Agents within a BDI-Architecture,”Proceedings of the 2nd
International Conference on Principles of Knowledge
Representation and Reasoning
Processing Functions
User interface agents
Search agents
Information agents
Filter agents
etc.
Intelligent agents are software programs
with an attitude.
Introduction
Events, Conditions, and Actions
Agents vs. Objects
Taxonomies of Agents
Using Java for Intelligent Agents
Using Java for Intelligent
Agents
Autonomy
Separate process or thread
Communication with other programs
Event-processing mechanism
Intelligence
Hard-coded procedural
Object-oriented logic
Sophisticated reasoning and learning capabilities
Mobility
Portable bytecodes and Java archive (JAR)
Ch.2 Problem Solving Using
Search
Defining the Problem Search Application
State space Bread-First Search
Search Strategies Depth-First Search
Breadth-First Search Heuristic Search
Depth-First Search Genetic Algorithms
SearchNode class
Defining the Problem
To clearly and succinctly define what it
is we are trying to do
Do we want to find the best possible route
for a trip or any one that will get us to our
destination?
Can we wait several hours or days for an
answer?
“Representation, representation,
representation”
State Space
Combination of the initial state and the set of
operators
Path
the sequence of states produced by the valid
application of operators from the initial state
Goal state
Effective search algorithms
Traversal of the state space in a controlled,
systematic manner
Heuristic, informed, or directed searches
Search Strategies
Breadth-first search
Depth-first search
Breadth-First Search
1. Create a queue and add the first
SearchNode to it.
2. Loop:
1. If the queue is empty, quit.
2. Remove the first SearchNode from the queue.
3. If the SearchNode contains the goal state, then
exit with the SearchNode as the solution.
4. For each child of the current SearchNode, add
the new SearchNode to the back of the queue.
Depth-First Search
1. Create a queue and add the first
SearchNode to it.
2. Loop:
1. If the queue is empty, quit.
2. Remove the first SearchNode from the queue.
3. If the SearchNode contains the goal state, then
exit with the SearchNode as the solution.
4. For each child of the current SearchNode, add
the new SearchNode to the front of the queue.
SearchNode Class
Data member
label
state
oper — definition of the operation that created the
state of the object
links — references to all other SearchNode objects
depth — distance from the start
expanded — whether the node is expanded or not
tested — whether the node is tested or not
cost — current accumulated cost or any other cost
traceTextArea — displaying trace information
SearchNode Class (cont.)
Methods
constructors — to initialize the depth, links, and
oper and to set the Boolean flags to false
test/set/get methods
addLink() — to add link to a single SearchNode
object
reset() — to reset the node depth and the
Boolean flags before starting a search
setDisplay() — to display trace information
expand() — to build a search tree from the initial
search graph
Search Application
Classes
SearchApp
SearchFrame
Search package — Fig.2.4
Search algorithms
Breadth-first search
Depth-first search
Iterated deepening
Best-first search
Genetic algorithm
Agent-Based Software
Engineering
Jennings and Wooldridge
Issues
N. R. Jennings (1999) "Agent-Oriented Software
Engineering" Proc. 12th Int Conf on Industrial and
Engineering Applications of AI, Cairo, Egypt, 4-10.
(Invited paper)
Wooldridge, N. R. Jennings, and D. Kinny (1999) "A
Methodology for Agent-Oriented Analysis and Design"
Proc. 3rd Int Conference on Autonomous Agents
(Agents-99) Seattle, WA, 69-76.
Issues
M. J. Wooldridge and N. R. Jennings, (1999)
"Software Engineering with Agents: Pitfalls and
Pratfalls" IEEE Internet Computing 3 (3) 20-27.
N. R. Jennings (1999) "Agent-based Computing:
Promise and Perils" Proc. 16th Int. Joint Conf. on
Artificial Intelligence (IJCAI-99), Stockholm, Sweeden.
(Computers and Thought award invited paper) 1429-
1436.
M. J. Wooldridge and N. R. Jennings (1998) "Pitfalls
of Agent-Oriented Development" Proc 2nd Int. Conf.
on Autonomous Agents (Agents-98), Minneapolis,
USA, 385-391.
Agent-Based Software
Engineering
Background & Motivation
Methodology
Roles
Analysis
Design
Case Study
Background
Definition
an agent is an encapsulated computer system
that is situated in some environment, and that is
capable of flexible, autonomous action in that
environment in order to meet its design
objectives
Background
Agents are:
clearly identifiable problem solving entities with
well-defined boundaries and interfaces;
situated (embedded) in a particular environment
designed to fulfill a specific purpose
autonomous
capable of exhibiting flexible problem solving
behavior in pursuit of their design objectives
Motivation
Most problems require or involve multiple
agents to represent
the decentralized nature of the problem,
the multiple loci of control,
the multiple perspectives, or the competing
interests.
Moreover, the agents will need to interact
with one another:
either to achieve their individual objectives
or to manage the dependencies that ensue from
being situated in a common environment.
Motivation (cont.)
Two points that qualitatively differentiate
agent interactions from those that occur in
other software engineering paradigms:
Agent-oriented interactions occur through a high-
level (declarative) agent communication language.
As agents are flexible problem solvers, operating
in an environment over which they have only
partial control and interactions need to be handled
in a similarly flexible manner.
Motivation (cont.)
To show agent-oriented decompositions are
an effective way of partitioning the problem
space of a complex system
To show that the key abstractions of the
agent-oriented mindset are a natural means
of modeling complex systems
To show the agent-oriented philosophy for
dealing with organizational relationships is
appropriate for complex systems
Motivation (cont.)
The techniques for tackling complexity in
software (by Booch):
Decomposition: The most basic technique for
tackling large problems is to divide them into
smaller, more manageable chunks each of which
can then be dealt with in relative isolation.
Abstraction: The process of defining a simplified
model of the system that emphasizes some of the
details or properties, while suppressing others.
Organization: The process of identifying and
managing the interrelationships between the
various problem solving components.
Merits of Agent-Oriented
Decomposition
At any given level, sub-systems work together to
achieve the functionality of their parent system.
Moreover, within a sub-system, the constituent
components work together to deliver the overall
functionality.
Given this fact, it is entirely natural to modularize the
components in terms of the objectives they achieve.
The individual components should localize and
encapsulate their own control.
Merits of Agent-Oriented
Decomposition (cont.)
The policy of deferring to run-time
decisions about component interactions
facilitates the engineering of complex
systems in two ways.
Problems associated with the coupling of
components are significantly reduced.
The problem of managing control
relationships between the software
components is significantly reduced.
Merits of Agent-Oriented
Decomposition (cont.)
It is apparent that a natural way to
modularize a complex system is in terms
of multiple, interacting, autonomous
components that have particular
objectives to achieve.
Appropriateness of Agent-
Oriented Abstractions
Sub-systems naturally correspond to agent
organizations.
The interplay between the sub-systems and
between their constituent components is
most naturally viewed in terms of high-level
social interactions.
They also require collections of components
to be treated as a single conceptual unit
when viewed from a different level of
abstraction.
Need for Flexible Management of
Changing Organizational Structures
Explicit representations are made of organizational
relationships and structures.
Agent-based systems have the mechanisms for
flexibly forming, maintaining and disbanding
organizations.
The notion of a primitive component can be varied
according to the needs of the observer.
Such structures provide a variety of stable
intermediate forms, that, as already indicated, are
essential for rapid development of complex systems.
Methodology
To provide an agent-specific set of
concepts through which a software
engineer can understand and model a
complex system.
To encourage a developer to think of
building agent-based systems as a
process of organizational design.
Methodology (cont.)
The main concepts can be divided into
two categories: abstract and concrete.
Abstract entities — used during analysis to
conceptualize the system
Concrete entities — used within the design
process, and will typically have direct
counterparts in the run-time system.
Methodology (cont.)
The most abstract entity in our concept hierarchy is
the system — see Figure 1.
Roles
The idea of a system as a society is useful
when thinking about the next level in the
concept hierarchy.
A role is defined by three attributes:
responsibilities, permissions, and protocols.
Responsibilities determine functionality and are
the key attribute associated with a role.
Responsibilities are divided into two types:
liveness properties and safety properties
Roles
Three attributes of a role:
In order to realize responsibilities, a role is
usually associated with a set of permissions.
Permissions are the “ rights”associated
with a role.
A role is also identified with a number of
protocols, which define the way that it can
interact with other roles.
Methodology (cont.)
Analysis and design — a process of developing
increasingly detailed models of the system to be
constructed.
Analysis
Captured in the system's organization.
To view an organization as a collection of roles
that stand in certain relationships to one another and
that take part in systematic, institutionalized patterns of
interactions with other roles.
To define an organization — to define how a role
can interact with other roles.
The aim of the analysis stage — to model the
system as a multigent organization in precisely
this way
The organization model — comprised of two
further models:
the roles model and the interaction model
Roles Model
To identify the key roles in the system
Viewed as an abstract description of an
entity's expected function.
Characterized by two types of attribute:
permissions/rights associated with the role
responsibilities of the role
Permissions
Two aspects of permissions associated with a
role:
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;
they state the resource limits within which the role
executor must operate --- intuitively, they say
what can't be spent while carrying out the role.
Responsibilities
The functionality of a role is defined by its
responsibilities.
These responsibilities can be divided into two
categories: liveness and safety responsibilities.
Roles Model
Consisting of a set of role schemata
Example
Interaction Model
Protocol definitions consist of the following set of
attributes:
purpose: brief description of the nature of the interaction
initiator: the role(s) responsible for starting the interaction;
responder: the role(s) with which the initiator interacts;
inputs: information used by the role initiator while enacting
the protocol;
outputs: information supplied by/to the protocol responder
during the course of the interaction;
processing: brief description of any processing the protocol
initiator performs during the course of the interaction;
Interaction Model
Analysis Process
1. Identify the roles in the system.
Output: A prototypical roles model --- a list of the key roles
that occur in the system
2. For each role, identify and document the associated
protocols. 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
4. Iterate stages (1)--(3).
Design
The agent-oriented analysis and design process is
concerned with
how a society of agents cooperate to realize the system
level goals
what is required of each individual agent in order to do this.
The design process involves generating three models
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.
The acquaintance model documents the acquaintances for
each agent type.
Design Process
Create an agent model:
aggregate roles into agent types, and refine to
form an agent type hierarchy;
document the instances of each agent type using
instance annotations.
Develop a services model, by examining
protocols and safety and liveness properties
of roles.
Develop an acquaintance model from the
interaction model and agent model.
Case Study
The particular application is providing customers with
a quote for installing a network to deliver a particular
type of telecommunications service.
This activity involves the following departments:
the customer service division (CSD),
the design division (DD),
the legal division (LD) and
the various organizations who provide the out-sourced
service of vetting customers (VCs).
The process is initiated by a customer contacting the
CSD with a set of requirements.
Case Study (cont.)
In parallel to capturing the requirements, the CSD
gets the customer vetted.
If the customer fails the vetting procedure, the quote
process terminates.
Assuming the customer is satisfactory, their
requirements are mapped against the service
portfolio.
If they can be met by a standard off-the-shelf item
then an immediate quote can be offered.
Case Study (cont.)
In the case of bespoke services, however, the
process is more complex.
DD starts to design a solution to satisfy the
customer's requirements and whilst this is occurring
LD checks the legality of the proposed service.
If the desired service is illegal, the quote process
terminates.
Assuming the requested service is legal, the design
will eventually be completed.
DD then informs CSD of the quote.
CSD, in turn, informs the customer.
The business process then terminates.
Case Study (cont.)
Case Study (cont.)
Case Study (cont.)
Case Study (cont.)
Pitfalls M. J. Wooldridge and N. R.
Jennings, (1999)
"Software Engineering with
Agents: Pitfalls and Pratfalls“
Political pitfalls IEEE Internet Computing 3
You oversell agents. (3) 20-27.
You get dogmatic about agents
Management pitfalls
You don’
t know why you want agents
You want generic solutions
Conceptual pitfalls
You believe in silver bullets
You forget agents are software
You forget agents are multithreaded software
Pitfalls (cont.)
Analysis and design pitfalls
You ignore related technology
Your design doesn’ t exploit
concurrency
You ignore legacy
Agent-level pitfalls
You want your own agent
architecture
Your agents use too much AI
Your agents use no AI
Pitfalls (cont.)
Society-level pitfalls
You see agents everywhere
You have too few agents
You obsess on infrastructure
Your agents interact too freely
Your system lacks structure
Background and Detail Studies
N. R. Jennings and M Wooldridge (2002) "Agent-Oriented
Software Engineering" in Handbook of Agent Technology (ed. J.
Bradshaw) AAAI/MIT Press. (to appear)
F. Zambonelli, N. R. Jennings, A. Omicini and M. Wooldridge
(2001) "Agent-Oriented Software Engineering for Internet
Applications" in Coordination of Internet Agents (eds. A. Omicini,
F. Zambonelli, M. Klusch and R. Tolksdorf) Springer Verlag, 326-
346.
M. Wooldridge, N. R. Jennings, and D. Kinny (2000) "The Gaia
Methodology for Agent-Oriented Analysis and Design" Journal of
Autonomous Agents and Multi-Agent Systems 3 (3) 285-312.
Background and Detail Studies
N. R. Jennings, K. Sycara and M. Wooldridge (1998) "A
Roadmap of Agent Research and Development" Int Journal of
Autonomous Agents and Multi-Agent Systems 1 (1) 7-38.
N. R. Jennings and M. J. Wooldridge (1998) "Applications of
Intelligent Agents" in Agent Technology: Foundations,
Applications, and Markets (eds. N. R. Jennings and M.
Wooldridge) 3-28
Nice reading:
Amund Tveit. A survey of Agent-Oriented Software Engineering.
Proceedings of the First NTNU Computer Science Graduate
Student Conference. Norwegian University of Science and
Technology, May 2001.
[Link]
ering/