SIF8072 Distributed Artificial Intelligence and Intelligent Agents

1. Lecture 7: Agent-oriented Software Engineering SIF8072 Distributed Artificial IntelligenceandIntelligent Agents http://www.idi.ntnu.no/~agent/ 27 February 2003 Lecturer: Sobah Abbas Petersen Email: sap@idi.ntnu.no

2. Lecture Outline • When is an agent-based solution appropriate? • AOSE Methodologies: • AAII (Kinny) • Gaia (Wooldridge et. al.) • Agent UML (Bauer et. al.) • Layered Agent Pattern Language (Kendall) • Formal Methods for AOSE • Pitfalls in agent development

3. References - Curriculum • Wooldridge: ”Introduction to MAS”, • Chapter 10 • Not in curriculum: • M. Wooldridge, N. R. Jennings, and D. Kinny. The Gaia Methodology for Agent-Oriented Analysis and Design. In Journal of Autonomous Agentsand Multi-Agent Systems. 3(3):285-312. 2000. • Bauer, B., Muller, J. P. and Odell, J., Agent UML: A Formalism for Specifying Multi-agent Interaction, in Proceedings of Agent-oriented Software Engineering, P. Ciancarni and M. Wooldridge (eds.), Springer Verlag, Berlin, 2001, pp. 91-103.

4. Terminology of Agent-Oriented Software Engineering

5. Agent-oriented Software Engineering (AOSE) • Concerns methodologies to support the development of agent systems. • Such methodologies have been successful in the development of OO systems: • e.g. OMT, UML

6. When is an agent-based solution appropriate? • The environment is open, or atleast highly dynamic, uncertain or complex • Agents are a natural metaphor • Distribution of data, control and expertise • Legacy systems

7. Criticisms of Existing Approaches • Approaches such as object-oriented design fail to capture: • An agent’s flexible, autonomous problem-solving behaviour • The richness of an agent’s interactions • The complexity of an agent’s organisational structures

8. Methodology Models Guidelines Agent-oriented Analysis & Design Techniques • An analysis and design methodology is intended to assist in: • Gaining an understanding of a particular system • Designing the system.

9. Model (abstract) Analysis and design process Implementation (concrete/ Detailed) Agent-oriented Models • Agent-oriented models are intended to formalise understanding of a system under consideration.

10. Methodologies • Inspired from O-O methodologies, e.g. • AAII Methodology (Kinny) • Gaia (Wooldridge et. al.) • Agent UML (Odell) • Adapts knowledge engineeringor other techniques, e.g. • DESIRE (Blazer et. al) Methodologies • Methodologies for the analysis and design can be divided into 2 groups.

11. AAII Methodology 1(Kinny et. al.) • Aim: to construct a set of models, which when fully elaborated, define an agent system specification.

12. AAII Methodology External Model (concerned with the agents and relationships between them) Internal Model (concerned with the internals: beliefs, desires, intentions) Agent Model Interaction Model Agent class model Agent instance model AAII Methodology 2

13. weather i j AAII Methodology 3 Methodology Example • Identify relevant roles in domain • Develop an agent class hierarchy • Role: weather monitor • Identify responsibilities for each roles: • Services required • Services provided • Determine goals associated with each service • Goals: • Find out current weather • Make agentj aware of it • Plan: • Send message to agentj • For each goal, determine plan • Determine belief strucure of system • How to represent agenti’sand agentj’sbeliefs

14. Gaia Methodology 1(Wooldridge et. al.) • Motivation: Existing methodologies don’t support agents, in particular, interactions and agent organisations. • Borrows terminology from object-oriented analysis and design. • Encourages the analyst to think of building agent-based systems as a process of organisational design. • Societal view of agents.

15. Requirements Abstract G A I A Model details Concrete Implementation Gaia Methodology 2 • Gaia is: • General: applicable to a range of multi-agent systems • Comprehensive: macro-level (societal) and micro-level (agent) aspects of systems. • Allows an analyst to go systematically from a statement of requirements to a design that is sufficient for implementation.

16. Gaia Methodology 3Concepts

17. Gaia Methodology 4Relationships between Gaia Models Requirements statements Roles Model Interactions Model Analysis Agent Model Services Model Acquaintance Model Design

18. Gaia Methodology 5Roles Model Role Attributes of roles Permissions Activities Responsibilities Protocols Liveliness properties Safety properties

19. Gaia Methodology 6Role Schema • A roles model is comprised of a set of role schema

20. Gaia Methodology 7Interaction Model • The links between the roles are represented in the interaction model. • It contains a set of protocol definitions: • an institutionalised pattern of interaction, e.g. a Dutch auction.

21. Gaia Methodology 8Analysis Process • Objective: to develop an understanding of the system and its structure.

22. Gaia Methodology 9Design Process • Objective: to transfer the abstract models from analysis stage into models of sufficiently low abstraction that can easily be implemented.

23. Gaia Methodology 10Example • To provide customers with a quote for installing a network to deliver a particular type of telecommunications service. • Several departments are involved: • Customer Service Dept. (CSD) • Design Dept. (DD) • Legal Dept. (LD) • Customer Vetting (CV) Reference: Wooldridge et. al. 2000.

24. Offer quote Capture requirements Customer contacts CSD Map requirements to service portfolios Design solution Vet Customer Offer quote Check legality Customer LD CSD DD CV Gaia Methodology 11Example

25. Roles Customer (cust) Customer Handler (CH) Quote Manager (QM) Customer Vetter (CV) Network Designer (ND) Legal Advisor (LA) CSD CV DD LD Gaia Methodology 12Example • Analysis stage: Identify roles and interaction models

26. Gaia Methodology 13Example • Interaction Model: For role Quote Manager (QM) Get requirements Cust Is service legal? QM LA Offer service to customer Is customer satisfactory? CH CV

27. Gaia Methodology 14Shortcomings of Gaia • Organisation structure is static – cannot be changed at run-time. • Abilities of agents and services they provide are also static. • Suitable for a small number of agent types.

28. Let’s take a minute…… • Discuss with your neighbour the agent model (agent types), the service model and the acquaintance model for this example.

29. Agent UML 1Rationale • Agent UML is an extension of UML. • It is not a methodology, rather a language for documenting models of systems. • Rationale for agent UML: UML is insufficient for modelling agents for the following reasons: • Compared to objects, agents are active. • Agents do not only act in isolation, but in cooperation and coordination with other agents.

30. Agent UML 2Limitations of UML • The definition of agent interaction protocols is a part of defining the dynamic part of an agent system. • Some limitations of UML:

31. Agent UML 3Proposed Modifications • Support for expressing concurrent threads ofinteraction, enabling UML to model agent protocols such as the CNET. • A notion of “role” that extends that provided in UML, in particular to allow an agent playing several roles.

32. Agent UML 4Agent Interaction Protocols • An agent interaction protocol describes • A communication pattern with • An allowed sequences of messages between agents having different roles • Constraints on the contents of messages • A semantic that is consistent with the communicative act within a communication pattern • Thus, the proposed modifications are aimed at supporting this.

33. Manager X Potential contractors cfp refuse deadline not-understood x propose reject-proposal x accept-proposal cancel inform Agent UML 5Contract Net Protocol

34. Design Patterns • Design patterns are recurring patterns of programming code or components of the software architecture. • The purpose of using design patterns is to increase re-use and quality of code in the development of the system.

35. The Layered Agent Pattern Language 1 • How can agent behaviour be best organised and structured into software? • What software architecture best supports the behaviour of agents? • Kendall proposed a layered agent pattern

36. The Layered Agent Pattern Language 2 • Agents should be decomposed into layers because: • Higher level, or more sophisticated behaviour, depends on lower level capabilities. • Layers only depend on their neighbours. • There is 2-way information flow between the neighbouring layers. • 7 layers were identified based on the agent’s real world.

37. The Layered Agent Pattern Language 3 When collaborating agents are in different locations, this layer is required for message transmission and reception. Mobility Agent formulates a message for another agent, translating it into other semantics. Translation Collaboration Agent determines how to collaborate with another agent. Actions Actions are carried out. Pending actions are queued here. Reasoning Agent determines what to do. Beliefs Agent’s models of itself and its environment. Sensory Agent gathers sensory input from its environment.

38. The Layered Agent Pattern Language 4

39. Formal Methods in AOSE 1 What role is played by logic in the development of agent systems? It can be used for: • Specification of a system • Directly (automatically) programming a system • Once specified, the system must be implemented. 3 Possibilities: • Manual refinement of the specifications. • Direct execution of the specification. • Compilation, transform specifications into code using some automatic synthesis process. • Verification of a system

40. Formal Methods in AOSE 2 • Verification of a system: • Once the system is developed, we need to show that the system is correct with respect to the specification. Verification Approaches • Axiomatic • Deductive verification: • Take the concrete program and derive a logical theory that represents the behaviour of the program. • Semantic • Model checking: • Reverse engineer a program to create a logical model, then check if the (formal) specification is valid in this model.

41. Pitfalls of Agent Development 1 • “While agent-based systems are becoming increasingly well understood, multi-agent system development is not.”(Wooldridge & Jennings, 1999) • Little efforthas been devoted to understanding the pragmatics of multi-agent systems development.

42. Pitfalls of Agent Development 2

43. Summary • AOSE methodologies are close to existing Software Engineering methodologies (e.g. OO) methodologies. • AOSE methodologies are inspired by either OO techniques or knowledge engineering techniques. • Main difference is focus on interaction and behavior

44. Next Lecture:Mobile Agents • Wooldridge: ”Introduction to MAS”, • Chapter 10