ARTIFICIAL INTELLIGENCE [INTELLIGENT AGENTS PARADIGM]

1. 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

2. Agent development • Practical agent development includes: • Requirements analysis • Design • Implementation • Testing • Deployment • Maintenance

3. 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

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

5. 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.

6. 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

7. 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

8. 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

9. 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

10. Analysis • The requirements must bedefinedin 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

11. Use case modelling • Various techniques are used: • Use case diagram • Use case scenarios • Use case maps • Internal use cases • Application similar to OO approach

12. Example of use case diagram

13. Example of use case description

14. 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

15. Internal use cases • Shows how agents use other agents The corresponding message sequence chart(MSC)

16. 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

17. Task decomposition • Similar to goal modelling • Tasks usually are less abstract and in lower levelthan 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

18. 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

19. 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 isused in communications and to describe agent’s knowledge

20. 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

21. 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

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

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

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

25. 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

26. 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

27. Abstract internal design of agents

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

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

30. Examples of tools: PDT and agentTool

31. MASITS and IDK

32. 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 alreadyexist

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

34. 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

35. 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

36. 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

37. Mobile agents • Remote procedure calls(a) in comparison to mobile agents (b):

38. 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

39. 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

40. 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?

41. 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

42. 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 • Interpretablelanguages Compiled languages use machine code that is platform dependant • Dynamic linking Local resource access libraries must provide common interface for different environments

43. Types of mobile agents • Mobile agents can be divided in at least 3 types • Autonomous • Upon request • Active mail agents

44. 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

45. 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

46. ‘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