Agent-Oriented Programming Languagesjleite/tutorials/wesaac14/wesaac14.pdf · Agent-Oriented Programming Languages Jo~ao Leite1 1Universidade Nova de Lisboa, Portugal [email protected]

Agent-Oriented Programming Languages

Joao Leite1

1Universidade Nova de Lisboa, [email protected]

WESAAC-2014 Tutorial

Joao Leite AOPL Tutorial – WESAAC14 1 / 72

[email protected]

Outline

Introduction

Abstraction in Multi-Agent Programming

BDI Architecture

Agent-Oriented Methodologies

Jason

Introduction to Jason

Reasoning Cycle

Main Language Constructs: Beliefs, Goals, and Plans

Other Language Features

The Jason Platform

Practical Session


Introduction


Agent-Oriented Software Development

Methodologies

Developments in the area of multi-agent systems led to a new

paradigm in software engineering

Requirement ⇒ Analysis ⇒ Design ⇒Implementation ⇒ Test

The aim is to provide high-level abstraction to model anddevelop complex systems

Structural analysis methodologies

Object-oriented methodologies

Agent-oriented methodologies (e.g., Gaia, Prometheus, Tropos)


Agent-Oriented Software Engineering: Gaia


Agent-Oriented Software Engineering: Prometheus


Abstraction in Multi-Agent Systems

Individual Agent Level: Autonomy, Situatedness, Proactivity

Cognitive concepts: beliefs, goals, plans, actions

Deliberation and control: sense/reason/act, reactive/pro-active

Multi-Agent Level: Social and Organisational Structures

Roles: functionalities, activities, and responsibilities

Organisational Rules: constraints on roles and their interactions

Organisational Structures: topology of interaction patterns and

the control of activities

Environment: Resources and Services that agents can access and

control


Agent-Oriented Programming

Proposed by Shoham [JAI, 1993]

Use of mentalistic notions and a societal view of computation

(anthropomorphism)


BDI Architecture

Intentional Stance (Dennett)

Practical Reasoning (Bratman)

IRMA (Bratman, Isreal, Pollack)

PRS (Georgeff, Lansky)

dMARS (Kinny)

BDI Logics and Agent Architecture (Rao, Georgeff)

Wooldridge, Singh, ...


Generic BDI Architecture

BRFGenerate

Options

Action

Beliefs

Intentions

Desires

Filter

Input

Effectors

Output

Sensors


Agent-Oriented Programming Languages

Logic Based

2APL (Dastani et al.)

GOAL (Hindriks et al.)

Jason (Hubner, Bordini et al.)

Java Based

Jade (Bellifemine et al.)

Jadex (Braubach, Pokahr et al.)

Jack (Agent Oriented Software Pty. Ltd.)

Other

(Con)Golog (Levesque et al.), Teamcore/MTDP (Tambe et al.),

MINERVA (Leite et al.), MetateM (Fisher et al.), STAPLE

(Kumar et al.), SOCS (Torroni et al.), Go! (Clark et al.), Agentis

(Agentis Software), CLAIM (El Fallah-Seghrouchni et al.),

IMPACT (Subrahmanian et al.), . . .


Jason


AgentSpeakThe foundational language for Jason

Originally proposed by Rao [Rao, 1996]

Programming language for BDI agents

Elegant notation, based on logic programming

Inspired by PRS (Georgeff & Lansky), dMARS (Kinny), and BDI

Logics (Rao & Georgeff)

Abstract programming language aimed at theoretical results


JasonA practical implementation of a variant of AgentSpeak

Jason implements the operational semantics of a variant of

AgentSpeak

Has various extensions aimed at a more practical programming

language (e.g. definition of the MAS, communication, ...)

Highly customised to simplify extension and experimentation

Developed by Jomi F. Hubner and Rafael H. Bordini


Main Language Constructs and Runtime Structures

Beliefs: represent the information available to an agent (e.g.

about the environment or other agents)

Goals: represent states of affairs the agent wants to bring about

Plans: are recipes for action, representing the agent’s know-how

Events: happen as consequence to changes in the agent’s beliefs

or goals

Intentions: plans instantiated to achieve some goal


Main Architectural Components

Belief base: where beliefs are stored

Set of events: to keep track of events the agent will have to handle

Plan library: stores all the plans currently known by the agent

Set of Intentions: each intention keeps track of the goals the agent is

committed to and the courses of action it chose in order

to achieve the goals for one of various foci of attention

the agent might have


Jason InterpreterBasic Reasoning cycle

perceive the environment and update belief base

process new messages

select event

select relevant plans

select applicable plans

create/update intention

select intention to execute


Jason Rreasoning Cycle

SI

EventsExternal

EventSelected

SE

Beliefs toAdd and

Delete

RelevantPlans

New PlanPush

IntentionUpdated

OS

Applicable

Plans

Means

Intended

EventsExternal

PlanLibrary

Events

InternalEvents

3

checkMail

Intentions

ExecuteIntention

...NewNew

9

BeliefBase

NewIntention

Percepts

act

SelectedIntention

Intentions

Action

Percepts1 2

BUF

10

Events

Context

Check

Event

Unify

BRF

Beliefs

Agent

sendMsg

Beliefs

8

Messages

Plans

perceive

7

5

6

Actions

Beliefs

Suspended Intentions(Actions and Msgs)

...

.send

SocAcc

4

Messages MessagesSM


Symbols

Rectangles: components of the agent state:

belief base

set of events

plan library

set of intentions

Rounded boxes, diamonds, circles: functions used in the reasoning

cycle.


Beliefs — Representation

Syntax

Beliefs are represented by annotated literals of first order logic

functor(term1, ..., termn)[annot1, ..., annotm]

Example (belief base of agent Tom)

red(box1)[source(percept)].

friend(bob,alice)[source(bob)].

lier(alice)[source(self),source(bob)].

˜lier(bob)[source(self)].


Beliefs — Dynamics I

by perception

beliefs annotated with source(percept) are automatically updated

accordingly to the perception of the agent

by intention

the plan operators + and - can be used to add and remove beliefs

annotated with source(self) (mental notes)

+lier(alice); // adds lier(alice)[source(self)]

-lier(john); // removes lier(john)[source(self)]


Beliefs — Dynamics II

by communication

when an agent receives a tell message, the content is a new belief

annotated with the sender of the message

.send(tom,tell,lier(alice)); // sent by bob

// adds lier(alice)[source(bob)] in Tom’s BB

...

.send(tom,untell,lier(alice)); // sent by bob

// removes lier(alice)[source(bob)] from Tom’s BB


Goals — Representation

Types of goals

Achievement goal: goal to do

Test goal: goal to know

Syntax

Goals have the same syntax as beliefs, but are prefixed by

! (achievement goal) or

? (test goal)

Example (Initial goal of agent Tom)

!write(book).


Goals — Dynamics I

by intention

the plan operators ! and ? can be used to add a new goal annotated

with source(self)

...

// adds new achievement goal !write(book)[source(self)]

!write(book);

// adds new test goal ?publisher(P)[source(self)]

?publisher(P);

...


Goals — Dynamics II

by communication – achievement goal

when an agent receives an achieve message, the content is a new

achievement goal annotated with the sender of the message

.send(tom,achieve,write(book)); // sent by Bob

// adds new goal write(book)[source(bob)] for Tom

...

.send(tom,unachieve,write(book)); // sent by Bob

// removes goal write(book)[source(bob)] for Tom


Goals — Dynamics III

by communication – test goal

when an agent receives an askOne or askAll message, the content is a

new test goal annotated with the sender of the message

.send(tom,askOne,published(P),Answer); // sent by Bob

// adds new goal ?publisher(P)[source(bob)] for Tom

// the response of Tom will unify with Answer


Triggering Events — Representation

Events happen as consequence to changes in the agent’s beliefs or

goals

An agent reacts to events by executing plans

Types of plan triggering events

+b (belief addition)

-b (belief deletion)

+!g (achievement-goal addition)

-!g (achievement-goal deletion)

+?g (test-goal addition)

-?g (test-goal deletion)


Plans — Representation

An AgentSpeak plan has the following general structure:

triggering event : context ¡- body.

where:

the triggering event denotes the events that the plan is meant to

handle

the context represent the circumstances in which the plan can be

used

the body is the course of action to be used to handle the event if

the context is believed true at the time a plan is being chosen to

handle the event


Plans — Operators for Plan Context

Boolean operators

& (and)

| (or)

not (not)

= (unification)

>, >= (relational)

<, <= (relational)

== (equals)

\ == (different)

Arithmetic operators

+ (sum)

- (subtraction)

* (multiply)

/ (divide)

div (divide – integer)

mod (remainder)

** (power)


Plans — Operators for Plan Body

A plan body may contain:

Belief operators (+, -, -+)

Goal operators (!, ?, !!)

Actions (internal/external) and Constraints

Example (plan body)

+rain : time to leave(T) & clock.now(H) & H ¿= T

¡- !g1; // new sub-goal

!!g2; // new goal

?b(X); // new test goal

+b1(T-H); // add mental note

-b2(T-H); // remove mental note

-+b3(T*H); // update mental note

jia.get(X); // internal action

X ¿ 10; // constraint to carry on

close(door).// external action


Plans — Example

+green patch(Rock)[source(percept)]

: not battery charge(low)

¡- ?location(Rock,Coordinates);

!at(Coordinates);

!examine(Rock).

+!at(Coords)

: not at(Coords) & safe path(Coords)

¡- move towards(Coords);

!at(Coords).

+!at(Coords)

: not at(Coords) & not safe path(Coords)

¡- ...

+!at(Coords) : at(Coords).


Plans — Dynamics

The plans that form the plan library of the agent come from

initial plans defined by the programmer

plans added dynamically and intentionally by

.add plan

.remove plan

plans received from

tellHow messages

untellHow


Jason Rreasoning Cycle

SI

EventsExternal

EventSelected

SE

Beliefs toAdd and

Delete

RelevantPlans

New PlanPush

IntentionUpdated

OS

Applicable

Plans

Means

Intended

EventsExternal

PlanLibrary

Events

InternalEvents

3

checkMail

Intentions

ExecuteIntention

...NewNew

9

BeliefBase

NewIntention

Percepts

act

SelectedIntention

Intentions

Action

Percepts1 2

BUF

10

Events

Context

Check

Event

Unify

BRF

Beliefs

Agent

sendMsg

Beliefs

8

Messages

Plans

perceive

7

5

6

Actions

Beliefs

Suspended Intentions(Actions and Msgs)

...

.send

SocAcc

4

Messages MessagesSM


Symbols

Rectangles: components of the agent state:

belief base

set of events

plan library

set of intentions

Rounded boxes, diamonds, circles: functions used in the reasoning

cycle.


Initialization

The initial beliefs initialize the belief base.

This causes belief additions, which are added to the set of events.

So are initial goals.

Plans form the initial plan library.

The set of intentions is empty.


Step 1: Perceiving the environment

Necessary to update beliefs according to the current state of the

environment

Requires a component that can perceive the environment in

symbolic form as a list of literals.

Each literal is a percept.

Implemented by the perceive method.

The environment can be simulated by a Java class.


Step 2: Updating the belief base

Beliefs are updated by a belief update function.

Implemented by the (customizable) buf method.

If p is the set of current percepts and b is the set of literals in thebelief base obtained by the previous perception:1 each literal l in p not currently in b is added to b;2 each literal l in b no longer in p is deleted from b.

Each change generates an external event.


Step 3: Receiving communication from other agents

The agents checks for messages it may have received in its

“mailbox”.

Implemented by the checkMail method.

Only one message is processed at a reasoning cycle.

Such message is returned, among all received and not yet

processed, by the message selection function.

Implemented by methods that can be overridden.


Step 4: Selecting “socially acceptable” messages

The agent selects the messages that can be accepted according to

some “social rules”.

E.g., which agents can provide information, or delegate goals.

Acceptable messages are selected by a social acceptance function.

Implemented by the customizable SocAcc method.


Step 5: Selecting an event

Agents operate handling events.

One event is handled at each cycle.

Selected by a customizable event selection function, which can

define priorities among events.

By default, FIFO policy.


Step 6: Retrieving all relevant plans

The relevant plans (i.e., those that can handle the event) are

selected.

The selected plans are those whose triggering event can be unified

with the selected events.

Unification as in Logic Programming.


Step 7: Determining the applicable plans

Out of all the relevant plans, only some are applicable.

Applicability depends on the plan’s context.


Step 8: Selecting one applicable plan

Out of the applicable plans, the agent chooses one to commit to.

The course of action corresponding to chosen plan becomes an

intended means.

The intended means is added to the agent’s set of intentions.

The choice is defined by a customizable option selection function

(or applicable plan selection function).

Intentions are implemented as stacks.

External events generate new intentions, internal events push the

new intended means onto the intention that generated the event.


Step 9: Selecting an intention for further execution

At each cycle, there will be, in general, more than one intended

means to choose from.

At most one can be executed.

This is selected by a customizable intention selection function.

Default policy: round-robin.


Step 10: Executing one step of an intentionEnvironment actions

The action is performed by the agent’s effectors.

The effector will return a feedback to the interpreter about the

action execution.

Action execution can take time: the interpreter suspends the

intention, because the plan’s body must be executed sequentially.

Meanwhile, it can use its time for other tasks.


Step 10: Executing one step of an intentionAchievement goals

The plan execution cannot continue until the goal is achieved.

A goal addition event is generated.

The achievement goal is not removed from the intention’s body

until it is actually achieved, so as to exploit variable unification

during goal achievement.


Step 10: Executing one step of an intentionTest goals

Used to check if a property is believed by the agent, or to retrieve

information.

If the goal succeeds, it can be removed.

Variable instantiations will stay.


Step 10: Executing one step of an intentionMental notes

If the formula is a belief to be added or removed, the interpreter

passes the request to the brf method.

The corresponding event is generated (which requires handling by

the interpreter).

By default, the interpreter adds a source(self) annotation to the

event.


Step 10: Executing one step of an intentionInternal actions

Consist of Java/legacy code to be executed.

Must be encoded in a boolean method, so as to provide feedback

about the action’s success.

Can cause variable instantiation.


Step 10: Executing one step of an intentionExpressions

Expressions are simply executed.

Failure causes the whole plan’s failure.

Unless the information to be checked is only available during plan

execution, expressions are better placed in the context.


Final stage before restarting the cycle

Suspended intentions, waiting for feedback, are placed back in the

intention set if the feedback has become available.

Finished plans are removed from the top of their intention stack.

Finished intention stacks are removed from the set of intentions.


Prolog-like Rules in the Belief Base

Example

likely color(Obj,C) :-

colour(Obj,C)[degOfCert(D1)] &

not (colour(Obj, )[degOfCert(D2)] & D2 ¿ D1) &

not ˜colour(C,B).


Plan Annotations

Like beliefs, plans can also have annotations, which go in the plan

label

Annotations contain meta-level information for the plan, which

selection functions can take into consideration

The annotations in an intended plan instance can be changed

dynamically (e.g. to change intention priorities)

There are some pre-defined plan annotations, e.g. to force a

breakpoint at that plan or to make the whole plan execute

atomically (atomic)

Example (an annotated plan)

@myPlan[chance of success(0.3), usual payoff(0.9),

any other property]

+!g(X) : c(t) ¡- a(X).


Failure Handling: Contingency Plans

Example (an agent blindly committed to g)

+!g : g.

+!g : ... ¡- ... ?g.

-!g : true ¡- !g.


“Higher-Order” Variables

Example (an agent that asks for plans on demand)

-!G[error(no relevant)] : teacher(T)

¡- .send(T, askHow, { +!G }, Plans);.add plan(Plans);

!G.

in the event of a failure to achieve any goal G due to no

relevant plan, asks a teacher for plans to achieve G and then

try G again

The failure event is annotated with the error type, line, source, ...

error(no relevant) means no plan in the agent’s plan library to

achieve G

{ +!G } is the syntax to enclose triggers/plans as terms


Internal Actions

Unlike actions, internal actions do not change the environment

Code to be executed as part of the agent reasoning cycle

AgentSpeak is meant as a high-level language for the agent’s

practical reasoning and internal actions can be used for invoking

legacy code elegantly

Internal actions can be defined by the user in Java

libname.action name(. . .)


Standard Internal Actions

Standard (pre-defined) internal actions have an empty library name

.print(term1, term2, . . .)

.union(list1, list2, list3)

.my name(var)

.send(ag,perf ,literal)

.intend(literal)

.drop intention(literal)

Many others available for: printing, sorting, list/string operations,

manipulating the beliefs/annotations/plan library, creating agents,

waiting/generating events, etc.


The Jason Platform


Communication Infrastructure

Various communication and execution management infrastructures can

be used with Jason:

Centralised: all agents in the same machine,

one thread by agent, very fast

Centralised (pool): all agents in the same machine,

fixed number of thread,

allows thousands of agents

Jade: distributed agents, FIPA-ACL

Saci: distributed agents, KQML

... others defined by the user (e.g. AgentScape)


Definition of a Simulated Environment

There will normally be an environment where the agents are

situated

The agent architecture needs to be customised to get perceptions

and act on such environment

We often want a simulated environment (e.g. to test an MAS

application)

This is done in Java by extending Jason’s Environment class


Interaction with the Environment Simulator

EnvironmentSimulator

Agent Architecture

executeAction

getPercepts

changepercepts

Reasoner

perceive

act


MAS Configuration Language I

Simple way of defining a multi-agent system

Example (MAS that uses JADE as infrastructure)

MAS my˙system –

infrastructure: Jade

environment: robotEnv

agents:

c3po;

r2d2 at jason.sourceforge.net;

bob #10; // 10 instances of bob

classpath: ”../lib/graph.jar”;

˝


MAS Configuration Language II

Configuration of event handling, frequency of perception,

user-defined settings, customisations, etc.

Example (MAS with customised agent)

MAS custom –

agents: bob [verbose=2,paramters=”sys.properties”]

agentClass MyAg

agentArchClass MyAgArch

beliefBaseClass jason.bb.JDBCPersistentBB(

”org.hsqldb.jdbcDriver”,

”jdbc:hsqldb:bookstore”,

...

˝


Jason Customisations

Agent class customisation:

selectMessage, selectEvent, selectOption, selectIntetion, buf, brf,

...

Agent architecture customisation:

perceive, act, sendMsg, checkMail, ...

Belief base customisation:add, remove, contains, ...

Example available with Jason: persistent belief base (in text files, in

data bases, ...)


jEdit Plugin


Eclipse Plugin


Mind Inspector


After a 30 min break...The Lab Session


http://centria.di.fct.unl.pt/˜jleite/wesaac14


Conclusions


Conclusions

More than a decade of research on agent-oriented programminglanguages.

Many languages and platforms

Various undergraduate and graduate programmes use them for

practical courseworkIntegration with languages for organizations and environments

tomorrow’s course on Multi-Agent Programming by Jomi Fred

Hubner

Friday’s course on Organisation-Oriented Programming by Olivier

Boissier

Still a lot to do...

Develop better tools for automatic generation, testing and

verification.

Take these languages and platforms to the next (industrial) level.

Maybe you can help!


Activities

Books: Multi-Agent Programming (2005 and 2009, Springer),

Specification and Verification of Multi-Agent Systems (2010,

Springer).

Workshops: EMAS, ProMAS, DALT, LADS, Agere!, Dagstuhl

seminars on Multi-Agent Programming.

Tutorials: Multi-Agent and Organisation Programming at AAMAS

and EASSS

Special Issues: JAAMAS and IJAOSE

Technical Fora: Multi-Agent Programming TFG


Bibliography I

Rao, A. S. (1996).

Agentspeak(l): Bdi agents speak out in a logical computable language.In de Velde, W. V. and Perram, J. W., editors, MAAMAW, volume 1038 of Lecture Notesin Computer Science, pages 42–55. Springer.


Documents

Agent-Oriented Programming Languagesjleite/tutorials/wesaac14/wesaac14.pdf · Agent-Oriented Programming Languages Jo~ao Leite1 1Universidade Nova de Lisboa, Portugal [email protected]