ARTIFICIAL INTELLIGENCE [INTELLIGENT AGENTS PARADIGM]

ARTIFICIAL INTELLIGENCE[INTELLIGENT AGENTS PARADIGM]

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: [email protected]

MULTI-AGENT SYSTEMS DESIGN

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 RUP, others (majority) use ~ iterative waterfall

• We will analyse the following phases– Analysis

– Design

– Implementation

– Testing

– Deployment

– Maintenance

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

Learner

Generate learning material

Solve domain problem

Log in to the system

<<extend>>

Generate feedback

Generate problem

Evaluate solution

Update student model

Create curriculum

Inform teacher

<<include>>

<<include>>

Administrator

Register learners to the

system

<<include>>

Teacher

13

Example of use case description

Name Evaluate solutionGoal: Learner’s knowledge evaluation based on testing results,

learner’s mistakes detectedSuccess scenario

1. Learner submits the solution;2. The solution is compared to the system’s 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 learner’s 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.

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 agentsThe 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 resultAppropriate learning materials provided

Learner taught and tested

Generated problems solved by the

system

Learner’s mistakes detected

Appropriate feedback chosen for

each mistake

Learning materials adapted

Problems generated from domain knowledge

Learner identified

Learner’s results registered

Results sent to the teacher

Uniquie problems provided

Teacher informedFeedback provided

Learner’s knowledge evaluated on the bases

of testing results

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

• Organization’s 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 agent’s 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

Agent

Events

Messages

Reasoner

Beliefs

Messages

Actions in environment

Plans

Goals

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

A1: AuthorPCM1:

PCMember A2: Author A3: Author

Chair: PCChair

DataBase:DB

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 callV=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• Agent’s 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 e-money)

• 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