ARTIFICIAL INTELLIGENCE

[INTELLIGENT AGENTS PARADIGM]

MULTI-AGENT SYSTEMS DESIGN

Professor Janis Grundspenkis
Riga Technical University
Faculty of Computer Science and Information Technology
Institute of Applied Computer Systems
Department of Systems Theory and Design
E-mail: Janis.Grundspenkis@rtu.lv

Agent development
Practical agent development includes:

Requirements analysis
Design
Implementation
Testing
Deployment
Maintenance

Agent oriented software

New software engineering paradigm proposed by
Schoham
Initial idea is to program agents directly in agents
based concepts like belief, goal plan, etc.
Now agent interactions are becoming central concept

Agents are basic software components in AO

approach like objects in OO

Agent development
Separate research direction agent oriented
software engineering (AOSE)
Tries to answer the question how to develop
software systems whose components are agents

Concepts
Agent oriented (AO) software software
that consists of agents
All steps are similar to OO
OO programming AO programming
OO analysis AO analysis
etc.

When the agents based solution is

suitable?
Agent based solution is suitable if:
The environment is open or at least dynamic, undeterministic
and complex
Systems capable of autonomous actions usually is the only
solution in such environments

Agents are natural metaphor

Many systems can be naturally modelled as agent societies, that
either cooperate to solve complex problems or compete
Including organizations and any commercial or competitive
environment

Distributed data control or competences

In many systems centralized solution is ineffective or impossible

Legacy systems

AOSE methodologies
AOSE is a complex process. It is hard to
handle it without methodological support
Definition: AOSE methodology is a set of
methods used in agent oriented software
development

What should good methodology

provide?

Precisely defined development process

Techniques to carry out each step
Corresponding AOSE concepts
Notation for diagrams/models
CASE tools
Mechanisms/algorithms to get the program
code from the design

Life cycle
Essentially the same as OO
Some methodologies use modified
(majority) use ~ iterative waterfall
We will analyse the following phases

Analysis
Design
Implementation
Testing
Deployment
Maintenance

RUP,

others

Analysis
The requirements must be defined in the form
needed in the following phases
The following techniques are used in the
analysis phase:

Use case modelling

Goal hierarchy
Task hierarchy
Domain modelling/Environment analysis
Ontologies

Use case modelling

Various techniques are used:

Use case diagram

Use case scenarios
Use case maps
Internal use cases

Application similar to OO approach

11

Example of use case diagram

12

Example of use case description

Name
Goal:
Success
scenario

Evaluate solution
Learners knowledge evaluation based on testing results,
learners mistakes detected
1. Learner submits the solution;
2. The solution is compared to the systems solution;
3. Mistakes and their causes are identified;
4. Feedback is generated and provided to the learner;
5. Student model is updated, including results of new testing.

Exceptions:

During the 5th step it is checked, if the learners results are not
too low. If results are too low, the use case Inform teacher is
done.
Preconditions: Problem is generated and given to the learner.
Problem is solved by the system.
Postconditions: Student model is updated;
Feedback is given to the learner.
13

Use case map

Shows how the use case is executed through
agents
It is used to identify the need for
communications between agents
If two consecutive steps are done by different
agents, communications between these agents
are needed

14

Internal use cases

Shows how agents use other agents
The corresponding
message sequence
chart(MSC)

15

Goal modelling
Especially useful in case of goal based
agents
Well understandable by domain experts
Goals rarely change during the development
Goal hierarchy is created as a result

Task decomposition
Similar to goal modelling
Tasks usually are less abstract and in lower level than
goals
Goal model is more suitable for BDI (Belief, Desire,
Intention) and similar agents
Task modelling is more suitable for reactive behaviour
based agents
Corresponding actions/behaviours can be created for each
task
Roles usually correspond to goals
Use cases can be created according to goals

Organisational modelling
Suitable for systems that must be well
integrated into organizations
Organizations structure is modelled
Stakeholders, organizations, their units and
roles as well as interactions among them are
determined

Domain modelling
The environment where the agents will act is
analysed
Domain class model is obtained
Domain ontology is usually created from the
class model
Ontology then is used in communications and
to describe agents knowledge

Design
Design is the phase that differs the most from OO
Usually is split into two stages:
1st stage answers the question: what the agents must do and how do
they interact?

External design of agents

High level design
Architectural design
It can be considered as a design of multi-agent system

2nd stage answers the question: how will the agents achieve their
functionality?

Internal design of agent

Low level design
Detailed design

Agent definition
Can be included in
Analysis phase if the agents are requirements
In design phase if the agents are just a way to implement
requirements

Agents can be defined for

Users
Organizations/stakeholders
Legacy systems
Roles
Use cases
Tasks
Types of knowledge

Interaction design
Specifies how the agents interact
3 possible levels
Acquaintance level
Messages sent among agents
Formal interaction protocols
Request Protocol
FIPA Contract Net

Acquaintance model
Only the interacting pairs of agents are
defined
Very simple
In many cases insufficient

Messages sent
Shows what messages are sent among
agents
No ordering and context of messages

Interaction protocols
Specify order of messages
sent and thus the context
of every message
For every message it is
defined how the agent can
respond to it
De facto standard UML
protocol diagram
Protocols are reusable

The 2nd stage of the design

For each agent designer must specify:
Percepts (including messages received)
Actions in the enviroment (including mesages
sent), plans
Knowledge, beliefs
Reasoning process
Architecture
Possibly: roles, capabilities, tasks goals

Abstract internal design of agents

Implementation
Choose the implementation platform
Convert the concepts used in the design to
ones used in the implementation platform
Implement the system in the chosen
platform
Generate code from the design (if possible)
Complete the generated code

Development tools
Tools for diagram drawing
Crosschecking among diagrams
Diagram transformations/partial generation
of diagrams and/or elements
Main function: code generation

Examples of tools: PDT and agentTool

MASITS and IDK

Testing
The most weakly developed phase
At the same time, testing of distributed systems is
complex
Usually (adapted) classical methods are used
For example, black box methods can be used for any
system

Specific tools like JADE Test Suite already exist

Deployment
Define particular instances of each agent, their location
and migration
Allows to easily change the system without changing the
design

Maintenance
Essentially the same as in OO approach
Additionally, agents give openness and high
modularity to the systems
Openness allows to change functionality by
adding/removing agents
High
modularity
simplifies
change
implementation into separate parts of the system

Summary of current situation

Many different methodologies exist
No single methodology is usable for all kinds
of agents
Weak coupling with the implementation
platforms
Many steps are still unclear, for example,
testing
Specific purpose methodologies are developed
to fit needs of specific types of systems

Mobile agents
Agents that are capable to move themselves over the
network
Code
Internal state

The idea is to provide an alternative to remote procedure

calls
Example of remote procedure call
V=B.m(args)
Communication is synchronous
What happens if the process B does not return value?
Network connection remains open?

Alternative: send mobile agent to the process B to execute

the needed operations in the common address space

Mobile agents

Remote procedure calls (a) in comparison to mobile agents

(b):

Mobile agents
Why needed?
Effective usage of low bandwidth networks
(smartphones, tablets, etc.)

Lots of problems must be solved to develop

software platforms for mobile agents
Security for both hosts and agents
Heterogeneity of hosts
Dynamic coupling

Host security
We do not want to execute unknown software on our
computers, because it is dangerous:
If the programming language supports pointers, then
there is a risk to damage the computers address space
Access rights to the host PC must be defined
Many actions may be safe in one case and malicious in
other. For example, sending an e-mail usually, but not
always, is safe

Host security
Many agent languages (like TELESCRIPT) limit the
amount of memory and CPU that is available to mobile
agents
Safe parallel processor is a solution. It can be given to an
agent that executes in the separate address space i.e. in
quarantine
Some languages allow to check security characteristics of
the agent upon recieving
Hosts must process with crashed software. What to tell the
owner if his software has crashed?

Agent security
Agents code is private
We want to sent our code without allowing the
receiver to determine its goal and thus our objectives
Agent can be modified without the owner knowing it
Cryptography can protect agent during the migration
Various digital signatures based on checksums are
used to check if the agent is modified

Host heterogenity
If the agents capable to execute only on one kind of
machines (Mac, PC, etc.) are not sufficient then we need
an infrastructure allowing them to execute in different
environments

Thus we need
Interpretable languages
Compiled languages use machine code that is
platform dependant
Dynamic linking
Local resource access libraries must provide
common interface for different environments

Types of mobile agents

Mobile agents can be divided in at least 3
types
Autonomous
Upon request
Active mail agents

Autonomous mobile agents

Autonomous mobile agents can choose by
themselves where to migrate as well as when
and what to do at the destination based on
the available resources (something like emoney)
Such agents can be implemented in
languages that offer command go. The best
known example of such language is
TELESCRIPT

Mobility upon request

The host runs the agent only if it explicitly

requests it
The best known example is Java object included
in the HTML code
The browser opens html page that contains
applets small Java software. These applets are
downloaded together with the webpage and are
executed in the client PC

Active mail agents

Scripts are sent by e-mail messages
Upon receiving the e-mail the agent is
unpacked and executed. E-mail becomes
active instead of passive