ARTIFICIAL INTELLIGENCE[INTELLIGENT AGENTS PARADIGM]Professor Janis Grundspenkis

Riga Technical UniversityFaculty of Computer Science and Information TechnologyInstitute of Applied Computer SystemsDepartment of Systems Theory and Design

E-mail: Janis.Grundspenkis@rtu.lvMULTI-AGENT SYSTEMS DESIGN

Agent developmentPractical agent development includes:Requirements analysisDesignImplementationTestingDeploymentMaintenance

Agent oriented softwareNew 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

ConceptsAgent oriented (AO) software software that consists of agents

All steps are similar to OOOO programming AO programmingOO analysis AO analysisetc.

When the agents based solution is suitable?Agent based solution is suitable if:The environment is open or at least dynamic, undeterministic and complexSystems capable of autonomous actions usually is the only solution in such environmentsAgents are natural metaphorMany systems can be naturally modelled as agent societies, that either cooperate to solve complex problems or competeIncluding organizations and any commercial or competitive environmentDistributed data control or competencesIn many systems centralized solution is ineffective or impossibleLegacy systems

AOSE methodologiesAOSE 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 processTechniques to carry out each stepCorresponding AOSE conceptsNotation for diagrams/modelsCASE toolsMechanisms/algorithms to get the program code from the design

Life cycleEssentially the same as OOSome methodologies use modified RUP, others (majority) use ~ iterative waterfallWe will analyse the following phasesAnalysisDesignImplementationTestingDeploymentMaintenance

AnalysisThe requirements must be defined in the form needed in the following phasesThe following techniques are used in the analysis phase:Use case modellingGoal hierarchyTask hierarchyDomain modelling/Environment analysisOntologies

Use case modellingVarious techniques are used:Use case diagramUse case scenariosUse case mapsInternal use cases

Application similar to OO approach*

Example of use case diagram*

Learner

Generate learning material

Solve domain problem

Create curriculum

Log in to the system

Generate feedback

Generate problem

Evaluate solution

Update student model

Inform teacher

Administrator

Register learners to the system

Teacher

*Example of use case description

Name Evaluate solutionGoal:Learners knowledge evaluation based on testing results, learners mistakes detectedSuccess scenarioLearner submits the solution;The solution is compared to the systems solution;Mistakes and their causes are identified;Feedback is generated and provided to the learner;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.

Use case mapShows how the use case is executed through agentsIt is used to identify the need for communications between agentsIf two consecutive steps are done by different agents, communications between these agents are needed

*

Internal use casesShows how agents use other agents

The corresponding message sequence chart(MSC)*

Goal modellingEspecially useful in case of goal based agentsWell understandable by domain expertsGoals rarely change during the developmentGoal hierarchy is created as a result

Appropriate learning materials provided

Learner taught and tested

Feedback provided

Generated problems solved by the system

Learners mistakes detected

Appropriate feedback chosen for each mistake

Uniquie problems provided

Teacher informed

Learning materials adapted

Problems generated from domain knowledge

Learner identified

Learners results registered

Results sent to the teacher

Learners knowledge evaluated on the bases of testing results

Task decompositionSimilar to goal modellingTasks usually are less abstract and in lower level than goals

Goal model is more suitable for BDI (Belief, Desire, Intention) and similar agentsTask modelling is more suitable for reactive behaviour based agents

Corresponding actions/behaviours can be created for each taskRoles usually correspond to goalsUse cases can be created according to goals

Organisational modellingSuitable for systems that must be well integrated into organizationsOrganizations structure is modelledStakeholders, organizations, their units and roles as well as interactions among them are determined

Domain modellingThe environment where the agents will act is analysedDomain 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 agentsHigh level designArchitectural designIt can be considered as a design of multi-agent system2nd stage answers the question: how will the agents achieve their functionality?Internal design of agentLow level designDetailed design

Agent definitionCan be included inAnalysis phase if the agents are requirementsIn design phase if the agents are just a way to implement requirementsAgents can be defined forUsersOrganizations/stakeholdersLegacy systemsRolesUse casesTasksTypes of knowledge

Interaction designSpecifies how the agents interact3 possible levelsAcquaintance levelMessages sent among agentsFormal interaction protocolsRequest ProtocolFIPA Contract Net

Acquaintance modelOnly the interacting pairs of agents are definedVery simpleIn many cases insufficient

Messages sentShows what messages are sent among agentsNo ordering and context of messages

Interaction protocolsSpecify order of messages sent and thus the context of every messageFor every message it is defined how the agent can respond to it

De facto standard UML protocol diagramProtocols are reusable

The 2nd stage of the designFor each agent designer must specify:Percepts (including messages received)Actions in the enviroment (including mesages sent), plansKnowledge, beliefsReasoning processArchitecture

Possibly: roles, capabilities, tasks goals

Abstract internal design of agents

Agent

Events

Messages

Reasoner

Beliefs

Messages

Actions in environment

Plans

Goals

ImplementationChoose the implementation platformConvert the concepts used in the design to ones used in the implementation platformImplement the system in the chosen platformGenerate code from the design (if possible)Complete the generated code

Development toolsTools for diagram drawingCrosschecking among diagramsDiagram transformations/partial generation of diagrams and/or elementsMain function: code generation

Examples of tools: PDT and agentTool

MASITS and IDK

TestingThe most weakly developed phase

At the same time, testing of distributed systems is complex

Usually (adapted) classical methods are usedFor example, black box methods can be used for any system

Specific tools like JADE Test Suite already exist

DeploymentDefine particular instances of each agent, their location and migrationAllows to easily change the system without changing the design

A1: Author

PCM1: PCMember

A2: Author

A3: Author

Chair: PCChair

DataBase:DB

MaintenanceEssentially the same as in OO approach

Additionally, agents give openness and high modularity to the systemsOpenness allows to change functionality by adding/removing agentsHigh modularity simplifies change implementation into separate parts of the system

Summary of current situationMany different methodologies existNo single methodology is usable for all kinds of agentsWeak coupling with the implementation platformsMany steps are still unclear, for example, testingSpecific purpose methodologies are developed to fit needs of specific types of systems

Mobile agentsAgents that are capable to move themselves over the networkCodeInternal stateThe idea is to provide an alternative to remote procedure callsExample of remote procedure callV=B.m(args)Communication is synchronousWhat 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 agentsRemote procedure calls (a) in comparison to mobile agents (b):

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

Lots of problems must be solved to develop software platforms for mobile agentsSecurity for both hosts and agentsHeterogeneity of hostsDynamic coupling

Host securityWe 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 spaceAccess rights to the host PC must be definedMany actions may be safe in one case and malicious in other. For example, sending an e-mail usually, but not always, is safe

Host securityMany agent languages (like TELESCRIPT) limit the amount of memory and CPU that is available to mobile agentsSafe parallel processor is a solution. It can be given to an agent that executes in the separate address space i.e. in quarantineSome 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 securityAgents code is privateWe want to sent our code without allowing the receiver to determine its goal and thus our objectivesAgent can be modified without the owner knowing itCryptography can protect agent during the migrationVarious digital signatures based on checksums are used to check if the agent is modified

Host heterogenityIf 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 environmentsThus we needInterpretable languages Compiled languages use machine code that is platform dependantDynamic linkingLocal resource access libraries must provide common interface for different environments

Types of mobile agentsMobile agents can be divided in at least 3 typesAutonomousUpon requestActive mail agents

Autonomous mobile agentsAutonomous 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 requestThe host runs the agent only if it explicitly requests itThe best known example is Java object included in the HTML codeThe 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

*d slaidu redakcij iznk, ka is tiei tpat atkrtojas vlk. Varbt jizem?*Slaidos lietoju sasinjumus AO- aentorienttsOO-objektorientts***Visi faktori, protams, nav obligti. s ir vienkri neformlas lietas, kas paldz saprast, vai aenti vartu bt nodergiLegacy systems ideja tda, ka aenti var tikt izmantoti mantoto sistmu integrcijai katrs aents tad ir savas mantots sistmas prstvis (eng. Wrapper).**Process- visi veicamie soi (mazliet vienkrojot)*Vai, ja nelieto iterat. densjritumu, tad vismaz fzes apraksta saska ar to.**aj un daos nkamajos slaidos tulkoanai izmantoju gada slaidus. Vismaz man liekas labki. Atirba ir taj, ka katram ir dots piemrs, jo dieml izrds, ka vismaz msu studenti ne prk labi zina s lietas.

****Ar o vlk izmanto komunikcijas identificanai*****Zemk lmea apakpunkti ir dadie nosaukumi, ko lieto dadas metodoloijas, lai apzmtu attiecgo stadiju*Aenti ir prasba, ja veidojam sistmu, kur katrs aents kaut ko prstv, piemram, veidojam izsoles sistmu, kur aenti msu viet kaut ko iegdjas.Ko nozm aentus defint atbilstoi kaut kam? Piemram, ja definjam lietoanas gadjumiem, tad grup ldzgus lietoanas gadjumus un katrai grupai izveido atbilstou aentu.***Piemr doti nosttie predikti**eit metodoloijas oti atiras, td dodu tikai oooti abstraktu skatjumu**Lielk problma: metodoloijas un platformas biei izmanto dadus konceptus un ne vienmr ir skaidrs, k izveidoto projektjumu implementt konkrt vid. Piemram, BDI aentus JADE implementt ir gandrz neiespjami.**PDT Prometheus Design Tool (prometheus metodoloija)agentTool- MaSE jeb Multi-agent Software Engineering metodoloijai*IDK Ingenias Development Kit (Ingenias metodoloija)*JADE test suite automtiskas testanas risinjums JADE aentiem. Testtjaents test prjos aentus.*Piemr konferences vadbas sistmas aenti**************