1. SIF8072 Distributed Artificial Intelligence and Intelligent Agents
Lecture 7:
Agent-oriented Software Engineering
SIF8072 Distributed Artificial Intelligence and Intelligent Agents
27 February 2003
Lecturer: Sobah Abbas Petersen

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 Agents and Multi-Agent Systems. 3(3):
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

4. Terminology of Agent-Oriented Software Engineering
1. All issues of agent-oriented software engineering + how and what agents compute
2. All software engineering where agents are involved
3. All systems that are developed using agents (~OOD)
4. Programming with agents (~OOP)

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
Agents are a natural metaphor: the idea of an agent is seen as a natural metaphor. e.g. As personal digital assistants in meeting organisations, partners in a virtual organisation and players in games.
Distribution of data, control and expertise: centralised solution id difficult or impossible. E.g. Distributed databases, health care service. Explain the different components: control, data dn expertise.
Legacy systems: software that is technologically obsolete, but functionally essential to an organisation. Use wrappers – an agent layer functionality to enable them to communicate with other software components.

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. 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.
Models
Guidelines
Methodology

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

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

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 2 AAII Methodology External Model Internal Model
(concerned with the agents and relationships between them)
Internal Model
(concerned with the internals: beliefs, desires, intentions)
Agent Model
Agent class model
Agent instance model
Interaction Model
Each agent class has atleast 3 attributes: belifs, desires and intentions.
Analyst can override inherited attributes.

13. AAII Methodology 3 Methodology Example i j Role: weather monitor
Identify relevant roles in domain
Develop an agent class hierarchy
Role: weather monitor i j
weather
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
Belief structure of system: info requirements for each goal and plan
For each goal, determine plan
Determine belief strucure of system
How to represent agenti’s and agentj’s beliefs

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. Gaia Methodology 2 Requirements G A I Implementation 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.
Requirements
Implementation G A I
Model
details
Concrete
Abstract

16. Gaia Methodology 3 Concepts
Abstract Concepts
(used during analysis to conceptualise the system)
Concrete Concepts
(used within the design process)
Roles
Permissions
Responsibilities
Protocols
Activities
Liveliness Properties
Safety properties
Agent types
Services
Acquaintances

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

18. Gaia Methodology 5 Roles Model
Attributes of roles
Permissions
Activities
Responsibilities
Protocols
A role has 4 attributes:
Permissions: rights associated with a role, resources that are available.
Activities: computations to be carried out by the agent.
Protocols: interactions with other roles. E.g. Role is a seller in an English auction.
Responsibility determines functionality of role. 2 kinds of responsibilities:
Liveliness properties: states if affairs the agent must bring about
Safety properties: acceptable states of affairs that must be maintained.
Liveliness properties
Safety properties

19. Gaia Methodology 6 Role Schema
A roles model is comprised of a set of role schema
Role Schema:
Name of Role
Description
Protocols and activities
Permissions
Responsibilities
Liveliness
safety
short description of the role
protocols and activities in which the role plays a part
”rights” associated with the role
liveliness responsibilities
Safety responsibilities

20. Gaia Methodology 7 Interaction 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 8 Analysis Process
Objective: to develop an understanding of the system and its structure.
Steps
Output
1. Identify roles
Roles model
2. For each role, identify associated protocols
Interaction model
3. Using the protocol/interaction model as basis, elaborate role model
Fully elaborated roles model (with permissions, responsibilities, etc.)
4. Iterate 1-3

22. Gaia Methodology 9 Design Process
Objective: to transfer the abstract models from analysis stage into models of sufficiently low abstraction that can easily be implemented.
Step
Output
1. Create agent model
Agent model
(identifies agent types)
2. Develop service model
Service model
(identifies main services required to realise agent’s role)
3. Develop acquaintance model from interaction model and agent model.
Acquaintance model
(documents the lines of communication between the agents )

23. Gaia Methodology 10 Example
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)
For a complete description of the example, see M. Wooldridge, N. R. Jennings, and D. Kinny. The Gaia Methodology for Agent-Oriented Analysis and Design. In Journal of Autonomous Agents and Multi-Agent Systems. 3(3):
Reference: Wooldridge et. al

24. Gaia Methodology 11 Example
Customer contacts CSD
Capture requirements
Vet Customer
Map requirements to service portfolios
Offer quote
Design solution
Check legality
CSD DD
Customer LD CV
A role has 4 attributes:
Permissions: rights associated with a role, resources that are available.
Activities: computations to be carried out by the agent.
Protocols: interactions with other roles. E.g. Role is a seller in an English auction.
Responsibility determines functionality of role. 2 kinds of responsibilities:
Liveliness properties: states if affairs the agent must bring about
Safety properties: acceptable states of affairs that must be maintained.

25. Gaia Methodology 12 Example
Analysis stage: Identify roles and interaction models
Roles
Customer
Handler
(CH)
Quote
Manager
(QM)
CSD
Vetter
(CV) CV
Network
Designer
(ND) DD
Legal
Advisor
(LA) LD
(cust)
For a complete description of the example, see M. Wooldridge, N. R. Jennings, and D. Kinny. The Gaia Methodology for Agent-Oriented Analysis and Design. In Journal of Autonomous Agents and Multi-Agent Systems. 3(3):

26. Gaia Methodology 13 Example
Interaction Model: For role Quote Manager (QM)
Get requirements
Cust
Is service legal? QM LA
Offer service to
customer
Design Process:
Map roles to agent types.
Develop service model.
Develop acquaintance model.
See reference to see a description of the complate example.
Is customer
satisfactory? CH CV

27. Gaia Methodology 14 Shortcomings 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 1 Rationale 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 2 Limitations of UML
The definition of agent interaction protocols is a part of defining the dynamic part of an agent system.
Some limitations of UML:
UML
Description
Limitations
Interaction Diagrams
Defines behaviour of groups of objects
Not suitable for describing the types of complex interactions between agents
State Diagrams
Define all possible states of an object
Suitable for a single object, but not for a group of cooperating objects
Activity Diagrams
Course of events or actions for several agents OK

31. Agent UML 3 Proposed Modifications
Support for expressing concurrent threads of interaction, 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 4 Agent 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.
Reference: 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

33. Agent UML 5 Contract Net Protocol
Potential
contractors
Manager X
cfp x
refuse
not-understood
propose
reject-proposal
accept-proposal
cancel
inform
deadline
Manager X – could be an agent named Manager X, playing the role manager, and of class seller.
Potential contractors could be of class consumer.

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
Mobility
When collaborating agents are in different locations, this layer
is required for message transmission and reception.
Translation
Agent formulates a message for another agent, translating it into
other semantics.
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
Problem
Solution
Pattern(s)
How can agents collaborate without direct knowledge of each other?
Encapsulate agent interaction in a Facilitator that coordinates agents within a given society
Facilitator
How can an agent adapt to the needs of a human user?
Provide the agent with parametric user models and sensors to to monitor the user’s actions
Interface agent
Facilitator: e.g. Collaboration layer
Interface agent: sensory layer, translation layer

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
Reference for this is Wooldridge, chapter 12, Section 12.8

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.
Axiomatic verification – relies on the syntactic proof.
Model checking – based on the semantics of the specification language.

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 effort has been devoted to understanding the pragmatics of multi-agent systems development.
Reference: M. Wooldridge and N. R. Jennings. Pitfalls of Agent-Oriented Development. In K. P. Sycara and M. Wooldridge, editors: Agents '98: Proceedings of the Second International Conference on Autonomous Agents ACM Press, May 1998.

42. Pitfalls of Agent Development 2
Political
You can oversell agents or fail to see where agents may usefully be applied.
Management
You don’t know why you want agents or what your agents are good for. E.g. Starting an agent project without any clear goals.
Conceptual
You believe that agents are a silver bullet.
Analysis and design
While developing an agent system, the % of the system that is agent-specific (e.g. Negotiation or coordination) is very small.
Micro (agent) level
You decide you want your own architecture , you use too much or too little AI. (”Useful first” strategy)
Macro (society) level
You see agents everywhere, too many or too few agents.
Implementation
You ignore de facto standards (e.g. KQML in agent communication)
Reference: M. Wooldridge and N. R. Jennings. Pitfalls of Agent-Oriented Development. In K. P. Sycara and M. Wooldridge, editors: Agents '98: Proceedings of the Second International Conference on Autonomous Agents ACM Press, May 1998.

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