aose agent-oriented programming. preliminaries much early research focused on theories of agency...

AOSEAgent-Oriented Programming

Preliminaries

• Much early research focused on theories of agency– How to conceptualize agents?

– What properties should agents have?

– How to formally represent and reason about these properties?

• Two approaches:– Macro Theories: theories that try to analyse and capture how a

group, an organisation, or a society behaves as a whole.

– Micro Theories: theories that try to model how to behave in certain desired ways, as part of the whole.

• Many approaches inspired by the intentional stance…

The Intentional Stance (Dennett)

• Three levels of abstraction can be used to predict and explain the behaviour of an object:– Physical Stance: the domain of physics and chemistry;

concerned with mass, energy, velocity, chemical composition, …• Predicting where a ball will land based on trajectory

– Design Stance: the domain of biology and engineering; concerned with purpose, function and design.

• Predicting that a bird will fly when flapping its wings because this is what wings are for

– Intentional Stance: the domain of software and minds; concerned with belief, thinking, and intent.

• Predicting that the bird will fly away because it knows the cat is coming and it is afraid of being eaten.

Intentional Stance and Agents

• Using the Intentional Stance allows:– Abstraction from the underlying system complexity

• Beliefs and knowledge, wants and desires, fears and joys, …

– Simple to model rational decision-making processes:• X intends to move away from Y because X believes Y is too close and is

afraid of Y.

• The Robot goes to the fridge because it believes that its master wants a beer.

– Sits well with logic:• Believes(X, close(Y)) & Afraid(X, Y) => Intends(X, moveFrom(Y))

• Believes(Robot, wants(master, beer)) =>Intends(Robot,

goto(fridge);get(beer);goto(master);give(beer))

Intentional Stance and Agents

• What mental states should we use?– Wooldridge and Jennings (1995):

• 1: information attitudes, e.g. beliefs and knowledge which pertain to the knowledge the agent has about the environment in which it finds itself.

• 2: pro-attitudes, e.g. desires, intentions, obligation, which concern the actions an agent takes.

– At least one of each is necessary for modeling decision-making

– A defacto standard has emerged:• Beliefs: the current state of the environment• Desires: the agent ideal future state of the environment• Intentions: subset of the desires that the agent commits to

– Known as the Belief-Desire-Intention (BDI) architecture

Agent-Oriented Programming

“Programming in the Intentional Stance”


• Class of programming language introduced in 1993 by Yoav Shoham (Stanford).

OOP AOP

Basic Unit Object Agent

Parameters describing unconstrained beliefs, commitments,state of basic unit capabilities

Process of Computationmessage passing and message passing andresponse methods response methods

Types of Message unconstrained inform, request, offer

Constrains on Methods none honesty, consistency


• AOP System Requirements:– a formal model (language) with clear syntax and semantics for

describing mental states.

– an interpreted programming language in which to define and program agents, with primitive commands (such as request and inform).

– an ”agentifier”, converting neutral devices into programmable agents.

• Shoham illustrates this through a prototype language, known as Agent-0.

AgentSpeak(L)

AgentSpeak(L)

• Devised by Anund Rao in 1995:– Attempts to bridge the gap between theory and practice– One-to-one correspondence between model theory, proof theory

and abstract interpreter. – Based on Belief-Desire-Intention model– based on a restricted first-order language with events and

actions.– agent behavior dictated by programs written in AgentSpeak(L).

• Implementations:– Jason (2004 – Bordini)– AF-AgentSpeak (2010 – Collier).

AgentSpeak(L): Basic Notions

• Beliefs:– Constants (objects/concepts) are represented as lower case

strings– rem, man, ball, …

– Variables are represented as upper case strings– X, Value, …

– Relationships/properties are represented as predicates:• isa(rem, man): represents the fact that rem is a man.• see(ball): represents the fact that the ball can be seen.

• Goals:– What the agent wants to achieve (predicates prefixed with !)

– !see(ball), !goto(rem), …


• Events:– Represent changes to the agents beliefs / goals.

– an event can be• internal, when a subgoal needs to be achieved

• external, when generated from belief updates as a result of perceiving the environment.

– two types of triggering events:• related to the addition (‘+’) and deletion (‘-’) of attitudes (beliefs or

goals).


• Plans:– the basic abilities of an agent (i.e. how it can affect its

environment).

te : ct <- h

• Where:– te - triggering event (denoting the purpose for that plan)– ct - a conjunction of belief literals representing a context.– h - a sequence of basic actions or (sub)goals that the agent

has to achieve (or test) when the plan, if applicable, is chosen for execution.


• Example Plans:– “If we believe a concert by artist A will take place at venue V and

we like A, adopt an achievement goal to book tickets for the concert.”

+concert (A,V) : likes(A) <-

!book_tickets(A,V).

– “If we have a goal to book tickets and the phone is not busy, call the venue and adopt an achievement goal to choose seats.”

+!book_tickets(A, V) : ¬busy(phone) <-

call(V);

!choose seats(A,V).


• Intentions: plans the agent has chosen for execution.– Represented as a stack.

– Intentions are executed one step at a time:• query or change the beliefs• perform an action on the external world• suspend the execution until a certain condition is met• submit new goals.

– The operations performed by a step may generate new events, which, in turn, may start new intentions.

– An intention succeeds when all its steps have been completed. It fails when certain conditions are not met or actions being performed report errors.

AgentSpeak(L): Interpreter Design

• An AgentSpeak(L) agent combines:– A set of events

• Events can be either internal (interpreter events) or external (environment events)

– A set of intentions:• A stack of partially instantiated plans

– Three selection functions:• SE (the event selection function): selects a single event from

the set of events• SO: selects an “option” (i.e., an applicable plan) from a set of

applicable plans• SI: selects one particular intention from the set of intentions.

AgentSpeak(L): Interpreter Design

Summary

• AgentSpeak(L) is a theoretical (but computationally tractable) AOP language.

• The central concept in AgentSpeak(L) is the notion of a partial plan that can be applied to resolve some triggering condition in some context.

• AgentSpeak(L) says nothing about communication.

• But, AgentSpeak(L) has been used as a basis to explore a range of more advanced concepts (cooperation, organisation, …)

Agent Factory and Agent Speak

AF-AgentSpeak

• Built using the Agent Factory Common Language Framework.• Standard Logic Framework• Planning Framework• Eclipse Integration• Debugger Support

• Extended version of AgentSpeak(L)• Basic language implemented with some minor changes to syntax• Extended suite of plan operators• Environment Model based on sensors, actions, and modules• Integrated FIPA ACL based communication

Basic Logic Concepts

• Variables: begin with a ?– ?name is the variable name

• Functions:– happy is a constant (function of arity 0)– fatherof(?x) is an unbound function of

arity 1– motherof(Coral) a bound function of arity 1

• Lists:– [] the empty list– [tanya, coral] list containing two terms– head([tanya, coral]) head of the list (tanya)– tail([tanya, coral]) head of the list (coral)– merge([tanya], [coral]) a combined list ([tanya, coral])


• Arithmetic Operations ( +, -, *, / ):– Constant Terms have implicit types– 1 + 2 evaluated to 3– ?x / 5 evaluated to 2 (assuming ?x =

10)– 10.0 / 4 evaluated to 2.5

• Comparison Operators ( >, <, ==, != ):– ?x > 5 if ?x is greater than 5

• Strings:– “a string” quotes “ override syntax– “?x is “ + ?x string concatenation


• Predicates:– isa(rem, man)– ~isa(rem, woman)– children(rem, [tanya, coral])

• Conjunctions:– has(?x) & ~poisonous(?x) & likes(rem, ?x)

• Special values:– true– false

Environment Model

• Sensing and Acting:– Sensors: Java Classes that convert raw data into predicates.– Actions: Java Classes that do things (primitives)

• Resources:– Modules: Java Classes that model internal resources that are

private to the agent (possibly combined with relevant sensors and actions).

– Platform Services: Shared platform-level resources (interaction via sensors and actions)

Environment Model

• Sensors and Actions are the same for most languages:– Unique identifier– Supports addition / removal of beliefs– Supports retrieval of references to resources– Core API provided for all languages

• Modules are somewhat similar:– Can contain aggregations of related sensors and actions

(Custom APIs)– Can encapsulate the interface to a platform service

Planning Components

// Belief state query (? In AgentSpeak(L))

query(isa(rem, ?x))

// Print Hello World

.println(“Hello World”)

// Loop through the values 0, 1, …, 9 and print them out

?i = 0,

while (?i < 10) {

.print(?i + “ “),

?i = ?i + 1

} // plan failure

try {

// plan expansion .fail

foreach (workerId(?x)) { } recover {

.send(request, ?x, sayHello) .println(“failed”),

} stop

// list creation }

?idList = list[ ?x | workerId(?x) ]

Core API

• Actions:– .abolish(?belief): remove the specified belief from the belief set.– .send(?perf, ?rec, ?content): send the given content using the

specified performative to the specified reciever.– .print(?string): print the string to the console.– .println(?string): print the string to the console and start a new

line.– .fail: Generate a failed action.– .nil: do nothing.– .bind(?serviceId): bind the agent to the given platform service.

• Sensors:– .services: set of beliefs about the bound platform services.– .inbox: set of beliefs about messages that have been received.– .self: set of beliefs about the agent (name + Agent Identifier).

Basic AF-AgentSpeak Examples

AF-AS Examples

• “Hello World” Agent

#agent alive

+initialized : true <-

.println(“Hello World”);

public class Main { public static void main(String[] args) { Map<String, String> designs = new HashMap<String,String(); designs.put("alive", "alive.aspeak“); new AgentSpeakDebugConfiguration(“test“,designs).

configure(); } }

• NOTES:– The initialize event is generated by the interpreter to allow plan rules to

be invoked on the first iteration

AF-AS Examples

• “Hello 10 Times” Agent

#agent alive10

// Print Hello World


?i = 0,

while (?i < 10) {

.println(“Hello World”),

?i = ?i + 1

};

AF-AS Examples

#agent Ping

+friend(?name, ?addr) : true <-

.send(request, agentID(?name, ?addr), ping);

+message(request, ?sender, ping) : true <-

.send(inform, ?sender, pong);

+message(inform, ?sender, pong) : true <-

.send(request, ?sender, ping);

• NOTES:– The message(…) event is generated when a message is

received.– The friend(…) event is an initial event passed by the main

method.

Example: FIPA Request Protocol

Protocol Overview

• Usage: Requesting an activity / service be performed

• Example: implement a protocol and develop two simple task tasks:– Drinking beer task: prints

“Mmmm tasty beer”– Time task: returns the time

in the form time(?h, ?m, ?s)

Example

• The example consists of two agents:– requester.aspeak: this agent is the participant and performs the

tasks– requestee.aspeak: this agent is the initiator and requests that

the tasks be performed.

• First I will discuss requester implementation and then the requestee implementation.– Both programs will be preceded by explanations.

Requester

• A protocol can be viewed as having a “main” flow together with a number of “exceptional” flows (a flow is a sequence of messages).– For the request protocol, the main flow is where the participant

agrees to perform the task, performs the task successfully, and tells the initiator that the task has been performed.

– The first exceptional flow relates to the case where the participant refuses the request.

– The second exceptional flow relates to the case where the requested task fails.

• Let’s look at each flow individually…

Requester (MAIN)

• For the request protocol, the main flow can be encoded through a single rule:

+message(request, ?initiator, ?task) : canDo(?task) <-

+performingTask(?initiator, ?task),

.send(agree, ?initiator, ?task),

try {

!performTask(?initiator, ?task)

} recover {

.send(failure, ?initiator, ?task)

}

-performingTask(?initiator, ?task);

• When the agent receives the “request” message for ?task, if it believes that is canDo(?task), then the main flow is followed (actions in italics).

Requester (MAIN)





try {


} recover {


}


• First, it adopts a belief that it is performing the task, and then it sends a message to the initiator agreeing to perform the task.

Requester (MAIN)





try {


} recover {


}


• Now it performs the task by raising the !performTask(…) goal.

Requester (MAIN)

• Default behaviour for performTask(…):

+!performTask(?agentID, ?task) : true <-

.fail;

– If this rule is triggered then there is no implementation of the task, so the agent views the task as having failed.

• Drink beer task:

+!performTask(?agentID, drink(beer)) : name(?name) <-

.println("[" + ?name + "] Mmmm tasty beer"),

.send(inform, ?agentID, done(drink(beer)));

– The agent prints out “[<name>] Mmmm tasty beer” and informs the initiator that the task is done.

– This rule must be written before the default rule (see full code)

Requester (MAIN)





try {


} recover {


}


• Finally, the agent drops the performingTask(…) belief.

Requester (FAILURE)





try {


} recover {


}


• NOTE: the failure exceptional flow is implemented here by the try {…} recover {…} operator.– if the agent fails to perform the task, then the recovery plan involves

the agent sending a failure message to the initiator.

Requester (REFUSE)

• For the request protocol, the refuse exceptional flow can be encoded through a single rule:

+message(request, ?initiator, ?task) : ~canDo(?task) <-

.send(refuse, ? initiator, ?task);

• Here, the participant refuses to perform a requested task if it does not have the belief canDo(?task).

Requester (CANCEL)

• In our discussion of the basic protocol, we did not consider how to cancel a request.– Doing this requires that we make use of a previously un-described feature

of AF-AgentSpeak that is not part of the basic AgentSpeak language.– Specifically, we associate a maintenance condition (see code in bold

below) with the rule that implements each task. If this condition becomes false, the agent causes the associated intention to fail.

+!performTask(?initiator, drink(beer)) : name(?name) <-

[performingTask(?initiator,drink(beer))]


.send(inform, ?initiator, done(drink(beer)));

• For the performTask(…) rules, the maintenance condition is that you believe that you are performing the task.

Requester (CANCEL)

• Now, we can add a rule for handling cancellation requests:

+message(cancel, ?initiator, protocol(request, ?task)) : performingTask(?initiator, ?task) <-


– This rule basically has the effect of removing the performingTask(…) belief whenever the participant receives a request to cancel a task that it is currently performing.

– The side effect of removing this belief is that the maintenance condition on the !performTask(…) rule becomes false, causing the agent to fail the intention.

– The last thing we need to do is to modify our MAIN flow to cater for the task that the !performTask(…) rule has been intentionally failed…

Requester (CANCEL)

• The updated rule is:




try {


} recover {

if (performingTask(?initiator, ?task)) {


}

}


• The full code is presented on the next slide.

Requester (Code)

#agent requester




try {


} recover {

if (performingTask(?initiator, ?task)) .send(failure, ?initiator, ?task)

}


+message(request, ?initiator, ?task) : ~canDo(?task) <-

.send(refuse, ?initiator, ?task);

+message(cancel, ?initiator, protocol(request, ?task)) : performingTask(?initiator, ?task) <-


canDo(drink(beer));

+!performTask(?initiator, drink(beer)) : name(?name) <- [performingTask(?initiator, drink(beer))]


.send(inform, ?initiator, done(drink(beer)));

+!performTask(?initiator, ?task) : true <-

.fail;

Requestee

• For the requestee, the protocol flows are not so complicated:– Send a request for the participant to drink beer.– If this request is completed successfully, send a request for the

participant to drink wine.– Notice that the agent identifier uses the address: “local:localhost”.

• This can now be used for agents on the same platform

• The full code for the requestee is:#agent requestee


.send(request, agentID(requester, addresses("local:localhost")), drink(beer));

+message(inform, ?agentID, done(drink(beer))) : true <-

.send(request, agentID(requester, addresses("local:localhost")), drink(wine));

Deployment

public class Main {

public static class DebugConfig extends AgentSpeakDebugConfiguration {

public DebugConfig() { super(“afas", null); }

public void configure() {

super.configure();

addAgent("requester", “acre/requester.aspeak");

addAgent("requestee", “acre/requestee.aspeak");

}

}

public static void main(String[] args) {

new DebugConfig().configure();

}

}

Summary

• The participant code has been designed to be extensible.– To add another task, all you need to do is add a canDo(…)

belief, and implement a !performTask(…) rule.– Example: time

canDo(tell_time);

+!performTask(?initiator, tell_time) : name(?name) & time(?h, ?m, ?s) <-

[performingTask(?initiator, tell_time)]

.send(inform, ?initiator, result(tell_time, time(?h, ?m, ?s)));

– NOTE: The inform message this case is result(?task, ?value) which corresponds to the inform-result message in the protocol.

aose agent-oriented programming. preliminaries much early research focused on theories of agency...

Documents

physical stance

trajectorydesign stance

forintentional stance

afraid of y

theories of agencyhow

macro theories

micro theories

programmable agents