SIF8072 Distributed Artificial Intelligence

andIntelligent Agents

http://www.idi.ntnu.no/~agent/

27 February 2003

Lecture 7: Agent-oriented Software Engineering

Lecturer: Sobah Abbas Petersen

Email: sap@idi.ntnu.no

Lecture Outline

1. When is an agent-based solution appropriate?

2. AOSE Methodologies:

1. AAII (Kinny)

2. Gaia (Wooldridge et. al.)

3. Agent UML (Bauer et. al.)

4. Layered Agent Pattern Language (Kendall)

3. Formal Methods for AOSE

4. Pitfalls in agent development

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

Terminology of Agent-Oriented Software Engineering

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

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

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

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

Agent-oriented Models

• Agent-oriented models are intended to formalise

understanding of a system under consideration.

Model(abstract)

Implementation(concrete/Detailed)

Analysisand design

process

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)

AAII Methodology 1(Kinny et. al.)

• Aim: to construct a set of models, which

when fully elaborated, define an agent

system specification.

AAII Methodology 2

AAII Methodology

External 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

AAII Methodology 3

•Identify relevant roles in domain

•Develop an agent class hierarchy

•Role: weather monitor

i jweather

•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

•For each goal, determine plan

•Plan:

•Send message to agentj

•Determine belief strucure of system•How to represent agenti’s and

agentj’s beliefs

Methodology Example

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.

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.

Requirements

Implementation

GAIA

Modeldetails

Concrete

Abstract

Gaia Methodology 3Concepts

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

Gaia Methodology 4Relationships between Gaia Models

Requirements

statements

Roles

Model

Interactions

Model

Agent

Model

Services

Model

Acquaintance

Model

Analysis

Design

Gaia Methodology 5Roles Model

Role

Attributes of roles

Permissions Activities Responsibilities Protocols

Liveliness

properties

Safety

properties

Gaia Methodology 6Role 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

• A roles model is comprised of a set of role schema

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.

Gaia Methodology 8Analysis Process

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

• Objective: to develop an understanding of the system and its structure.

Gaia Methodology 9Design Process

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 )

• Objective: to transfer the abstract models from analysis stage into models of

sufficiently low abstraction that can easily be implemented.

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.

Gaia Methodology 11Example

Customer contacts CSD

Capture requirements

Vet Customer

Map requirements

to service portfolios

Offer quote

Design solution

Check legality

Offer quote

CSD

DD

Customer

LD

CV

Gaia Methodology 12Example

• Analysis stage: Identify roles and interaction models

Roles

CustomerHandler (CH)

QuoteManager(QM)

CSD

Customer Vetter(CV)

CV

NetworkDesigner(ND)

DD

Legal Advisor(LA)

LD

Customer (cust)

Gaia Methodology 13Example

• Interaction Model: For role Quote Manager (QM)

QM

Cust

LA

CHCV

Get requirements

Is customer satisfactory?

Is service legal?

Offer service to customer

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.

Let’s take a minute……

• Discuss with your neighbour the agent

model (agent types), the service model

and the acquaintance model for this

example.

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.

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:

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

Agent UML 3Proposed 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.

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.

Potential contractors

Manager X

cfp

x

refuse

not-understood

propose

reject-proposal

accept-proposal

cancel

inform

deadline

x

Agent UML 5Contract Net Protocol

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.

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

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.

The Layered Agent Pattern Language 3

Mobility

Translation

Collaboration

Actions

Reasoning

Beliefs

Sensory Agent gathers sensory input from its environment.

Agent formulates a message for another agent, translating it into other semantics.

Agent’s models of itself and its environment.

Agent determines what to do.

Actions are carried out. Pending actions are queued here.

Agent determines how to collaborate with another agent.

When collaborating agents are in different locations, this layer is required for message transmission and reception.

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

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:

1. Manual refinement of the specifications.

2. Direct execution of the specification.

3. Compilation, transform specifications into code using some automatic synthesis

process.

• Verification of a system

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.

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.

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)

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

Next Lecture:

Mobile Agents

• Wooldridge: ”Introduction to MAS”,

– Chapter 10