t2. organization and environment oriented programming

28
Organisation and Environment Oriented Programming Olivier Boissier 1 , Rafael H. Bordini 2 , Jomi F. H¨ ubner 3 , Alessandro Ricci 4 1 EMSE, France [email protected] 2 PUC-RS, Brazil [email protected] 3 DAS-UFSC, Brazil [email protected] 4 University of Bologna, Italy [email protected] European Agent Systems Summer School May, 2012 — Valencia, Spain Outline of the course Introduction EOP About Environment Oriented Programming A&A and CArtAgO OOP About Organisation Oriented Programming Moise Conclusions Practical Exercise: a hands-on lab session! Introduction Introduction EOP OOP Conclusion Abstractions in Multi-Agent Systems role org mission schema ORGAMISATION LEVEL AGENT LEVEL ENDOGENOUS ENVIRONMENT LEVEL wsp artifact network node EXOGENOUS ENVIRONMENT agent 4 / 165 Introduction EOP OOP Conclusion Abstractions in Multi-Agent Systems Individual Agent Level: autonomy, situatedness Cognitive Concepts: beliefs, desires, goals, intentions, plans Reasoning Cycle: sense/reason/act, reactive/pro-active behaviour Environment Level: resources and services that agents can access and control; sensing and acting in an environment Social and Organisation Level: cooperation, coordination, regulation patterns Roles: rights, responsibilities, ... Organisational Rules: constraints on roles and their interactions, norms, deadlines, ... Organisational Structures: topology of interaction patterns and relations over activity control 5 / 165 Introduction EOP OOP Conclusion Agent Oriented Programming Proposed by Shoham [Shoham, 1993] Use of mentalistic notions and a societal view of computation (anthropomorphism) Levels of abstraction: Agents – Organisations – Environment Programming languages for agents have developed a lot since then, but still not a mature paradigm Programming languages/platforms for organisation and environment are also being developed Some agent development platforms have a formal basis Many influenced by the BDI agent architecture 6 / 165

Upload: easss-2012

Post on 10-May-2015

545 views

Category:

Education


4 download

DESCRIPTION

14th European Agent Systems Summer School

TRANSCRIPT

Page 1: T2. Organization and Environment oriented programming

Organisation and Environment

Oriented Programming

Olivier Boissier1, Rafael H. Bordini2,Jomi F. Hubner3, Alessandro Ricci4

1EMSE, [email protected]

2PUC-RS, [email protected]

3DAS-UFSC, [email protected]

4University of Bologna, [email protected]

European Agent Systems Summer SchoolMay, 2012 — Valencia, Spain

Outline of the course

Introduction

EOP

About Environment Oriented ProgrammingA&A and CArtAgO

OOP

About Organisation Oriented ProgrammingMoise

Conclusions

Practical Exercise: a hands-on lab session!

Introduction

Introduction EOP OOP Conclusion

Abstractions in Multi-Agent Systems

roleorgmission

schema

ORGAMISATIONLEVEL

AGENTLEVEL

ENDOGENOUSENVIRONMENTLEVELwsp

artifact

network node

EXOGENOUS ENVIRONMENT

agent

4 / 165

Introduction EOP OOP Conclusion

Abstractions in Multi-Agent Systems

Individual Agent Level: autonomy, situatedness

Cognitive Concepts: beliefs, desires, goals, intentions, plansReasoning Cycle: sense/reason/act, reactive/pro-activebehaviour

Environment Level: resources and services that agents canaccess and control; sensing and acting in an environment

Social and Organisation Level: cooperation, coordination,regulation patterns

Roles: rights, responsibilities, ...Organisational Rules: constraints on roles and theirinteractions, norms, deadlines, ...Organisational Structures: topology of interaction patternsand relations over activity control

5 / 165

Introduction EOP OOP Conclusion

Agent Oriented Programming

Proposed by Shoham [Shoham, 1993]

Use of mentalistic notions and a societal view ofcomputation (anthropomorphism)

Levels of abstraction: Agents – Organisations – Environment

Programming languages for agents have developed a lotsince then, but still not a mature paradigm

Programming languages/platforms for organisation andenvironment are also being developed

Some agent development platforms have a formal basis

Many influenced by the BDI agent architecture

6 / 165

Page 2: T2. Organization and Environment oriented programming

Introduction EOP OOP Conclusion

BDI Architecture

Intentional Stance (Dennett)

Practical Reasoning (Bratman)

IRMA (Bratman, Isreal, Pollack)

PRS (George↵, Lansky)

dMARS (Kinny)

BDI Logics and Agent Architecture (Rao, George↵)

Wooldridge, Singh, ...

7 / 165

Introduction EOP OOP Conclusion

Programming Languages for Cognitive Agents

Programming Languages for Multi-Agent SystemsE.g., Jason, Jadex, JACK, 2APL, GOAL, Brahms, JIAC, Agent

Factory, MetateM, Golog variants, ...

Architecture to represent an agent mental state:

Beliefs: information available to agent (e.g., about theenvironment or other agents)Goals: states of a↵airs that the agent wants to achieveEvents: changes in agents beliefs or goalsCapabilities: reusable modules of activities that the agentcan performPlans: reasoning about courses of action to achieve goalsRules: reasoning about beliefs

8 / 165

Introduction EOP OOP Conclusion

Programming Languages for Cognitive Agents

Some steps of a Reasoning Cycle:

Determining Relevant Plans for Handling EventsSelect a Plan for ExecutionExecute Part of an Intended PlansHandle Plan Failures

Agent Interpreter is an infinite loop of such reasoning cycles.The architecture and reasoning cycle together with the agentprogram (specially plans) determine the behaviour of the agent.

9 / 165

Introduction EOP OOP Conclusion

Programming Languages/Platforms for Organisations

Concepts used to specify the state of an organisation:

Agents, Roles, GroupsNorms, Obligations, Prohibitions, Permissions, ViolationsDependency, Power, Delegation, Information flow relationsDeadlines, Sanctions, Rewards

Management Infrastructure to control and coordinateagent behaviour at run-time:

Endogenous: The control is a part of the agent programExogenous: The control is performed by an external system

Monitoring Agent BehaviourEnforcing Organisational RulesRegimenting Organisational Rules

10 / 165

Introduction EOP OOP Conclusion

Programming Languages/Platforms for Environments

Artifacts to represent the state of the environment

Access to Databases/Services/etc., Coordination, InteractionEnvironment “objects”, i.e., non-proactive entities

Processing Operations on Artifacts

Realising the e↵ects of environments actionsProviding events related to sensing the environmentSynchronising agent actions

At the right level of abstraction for a multi-agent system

11 / 165

Introduction EOP OOP Conclusion

Hands-on Part of this Course

We will use JaCaMo

First fully operational, unified platform covering the 3 mainlevels of abstractions for multi-agent oriented programming

JaCaMo = Jason + CArtAgO + Moise

http://jacamo.sourceforge.net

http://jason.sourceforge.net

http://cartago.sourceforge.net

http://moise.sourceforge.net

More than the sum of 3 successful platforms

Revealing the full potential of Multi-Agent OrientedProgramming

12 / 165

Page 3: T2. Organization and Environment oriented programming

Environment OrientedProgramming— EOP —

Outline

2 Environment ProgrammingWhy Environment Programming in MASBasic LevelAdvanced LevelA&A and CArtAgOConclusions and Wrap-up

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Back to the Notion of Environment in MAS

The notion of environment is intrinsically related to thenotion of agent and multi-agent system

“An agent is a computer system that is situated in some

environment and that is capable of autonomous action in

this environment in order to meet its design

objective” [Wooldridge, 2002]“An agent is anything that can be viewed as perceiving

its environment through sensors and acting upon the

environment through e↵ectors.

” [Russell and Norvig, 2003]

Including both physical and software environments

15 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Single Agent Perspective

ENVIRONMENT

feedback

actions

percepts

effectors / actuators

sensors

action to

do

PERCEPTION

DECISION

ACTION

Perception

process inside agent inside of attaining awareness orunderstanding sensory information, creating perceptsperceived form of external stimuli or their absence

Actions

the means to a↵ect, change or inspect the environment

16 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Multi-Agent Perspective

In evidence

overlapping spheres of visibility and influence..which means: interaction

17 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Why Environment Programming

Basic level

to create testbeds for real/external environmentsto ease the interface/interaction with existing softwareenvironments

Advanced levelto uniformly encapsulate and modularise functionalities ofthe MAS out of the agents

typically related to interaction, coordination, organisation,securityexternalisation

this implies changing the perspective on the environment

environment as a first-class abstraction of the MASendogenous environments (vs. exogenous ones)programmable environments

18 / 165

Page 4: T2. Organization and Environment oriented programming

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Environment Programming: General Issues

Defining the interface

actions, perceptionsdata-model

Defining the environment computational model &architecture

how the environment worksstructure, behaviour, topologycore aspects to face: concurrency, distribution

Defining the environment programming model

how to program the environment

19 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Basic Level Overview

actions

percepts

SIMULATED

WORLD

OR

INTERFACE

OR

WRAPPER TO

EXISTING

TECHNOLOGY

EXTERNAL

WORLD(PHYSICAL OR

COMPUTATIONAL)

MAS ENVIRONMENT

REAL WORLD(PHYSICAL OR

COMPUTATIONAL)

mimicking

Example:

JAVA

PLATFORMAGENTS

MAS

20 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Basic Level: Features

Environment conceptually conceived as a single monoliticblock

providing actions, generating percepts

Environment APIto define the set of actions and program actionscomputational behaviour

which include the generation of percepts

typically implemented using as single object/class in OO suchas Java

method to execute actionsfields to store the environment state

available in many agent programming languages/frameworks

e.g., Jason, 2APL, GOAL, JADEX

21 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

An Example: Jason [Bordini et al., 2007]

Flexible Java-based Environment APIEnvironment base class to be specialised

executeAction method to specify action semanticsaddPercept to generate percepts

UserEnvironment

AgentArchitecture

getPercepts

changepercepts

executeAction

+init(String[] args)+stop()

+getPercepts(String agName): List<Literal>+executeAction(String agName, Structure action): boolean

+addPercept(String agName, Literal p)+removePercept(String agName, Literal p)...

-globalPercepts: List<Literal>-agPercepts: Map<String,List<Literal>>

Environment

+init(String[] args)+executeAction(String agName, Structure action): boolean

UserEnvironment

22 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

MARS Environment in Jason

public class MarsEnv extends Environment { private MarsModel model; private MarsView view; public void init(String[] args) { model = new MarsModel(); view = new MarsView(model); model.setView(view); updatePercepts(); } public boolean executeAction(String ag, Structure action) { String func = action.getFunctor(); if (func.equals("next")) { model.nextSlot(); } else if (func.equals("move_towards")) { int x = (int)((NumberTerm)action.getTerm(0)).solve(); int y = (int)((NumberTerm)action.getTerm(1)).solve(); model.moveTowards(x,y); } else if (func.equals("pick")) { model.pickGarb(); } else if (func.equals("drop")) { model.dropGarb(); } else if (func.equals("burn")) { model.burnGarb(); } else { return false; } updatePercepts(); return true; } ...

...

/* creates the agents perception * based on the MarsModel */ void updatePercepts() {

clearPercepts(); Location r1Loc = model.getAgPos(0); Location r2Loc = model.getAgPos(1); Literal pos1 = Literal.parseLiteral ("pos(r1," + r1Loc.x + "," + r1Loc.y + ")"); Literal pos2 = Literal.parseLiteral ("pos(r2," + r2Loc.x + "," + r2Loc.y + ")");

addPercept(pos1); addPercept(pos2);

if (model.hasGarbage(r1Loc)) { addPercept(Literal.parseLiteral("garbage(r1)")); }

if (model.hasGarbage(r2Loc)) { addPercept(Literal.parseLiteral("garbage(r2)")); } }

class MarsModel extends GridWorldModel { ... } class MarsView extends GridWorldView { ... } }

23 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Jason Agents Playing on Mars

// mars robot 1

/* Initial beliefs */

at(P) :- pos(P,X,Y) & pos(r1,X,Y).

/* Initial goal */

!check(slots).

/* Plans */

+!check(slots) : not garbage(r1) <- next(slot); !!check(slots).+!check(slots).

+garbage(r1) : not .desire(carry_to(r2)) <- !carry_to(r2). +!carry_to(R) <- // remember where to go back ?pos(r1,X,Y); -+pos(last,X,Y); // carry garbage to r2 !take(garb,R); // goes back and continue to check !at(last); !!check(slots)....

...

+!take(S,L) : true <- !ensure_pick(S); !at(L); drop(S).

+!ensure_pick(S) : garbage(r1) <- pick(garb); !ensure_pick(S).+!ensure_pick(_).

+!at(L) : at(L).+!at(L) <- ?pos(L,X,Y); move_towards(X,Y); !at(L).

24 / 165

Page 5: T2. Organization and Environment oriented programming

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Another Example: 2APL [Dastani, 2008]

2APL

BDI-based agent-oriented programming language integratingdeclarative programming constructs (beliefs, goals) andimperative style programming constructs (events, plans)

Java-based Environment API

Environment base classimplementing actions as methods

inside action methods external events can be generated to beperceived by agents as percepts

25 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Example: Block-world Environment in 2APL

package blockworld;

public class Env extends apapl.Environment {

public void enter(String agent, Term x, Term y, Term c){...}

public Term sensePosition(String agent){...}

public Term pickup(String agent){...}

public void north(String agent){...}

...

}

26 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

2APL Agents in the block-world

BeliefUpdates: { bomb(X,Y) } RemoveBomb(X,Y){ not bomb(X,Y) } { true } AddBomb(X,Y) { bomb(X,Y) } { carry(bomb) } Drop( ) { not carry(bomb)} { not carry(bomb) } PickUp( ) { carry(bomb) }

Beliefs: start(0,1). bomb(3,3). clean( blockWorld ) :- not bomb(X,Y) , not carry(bomb).

Plans: B(start(X,Y)) ; @blockworld( enter( X, Y, blue ), L )

Goals: clean( blockWorld )

PG-rules: clean( blockWorld ) <- bomb( X, Y ) | { goto( X, Y ); @blockworld( pickup( ), L1 ); PickUp( ); RemoveBomb( X, Y ); goto( 0, 0 ); @blockworld( drop( ), L2 ); Drop( ) }...

...

PC-rules: goto( X, Y ) <- true | { @blockworld( sensePosition(), POS ); B(POS = [A,B]); if B(A > X) then { @blockworld( west(), L ); goto( X, Y ) } else if B(A < X) then { @blockworld( east(), L ); goto( X, Y ) } else if B(B > Y) then { @blockworld( north(), L ); goto( X, Y ) } else if B(B < Y) then { @blockworld( south(), L ); goto( X, Y ) } }

...

27 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Environment Interface Stardard – EIS Initiative

Recent initiative supported by main APL researchgroups [Behrens et al., 2010]

GOAL, 2APL, GOAL, JADEX, JASON

Goal of the initiativedesign and develop a generic environment interface standard

a standard to connect agents to environments... environments such as agent testbeds, commercialapplications, video games..

Principles

wrapping already existing environmentscreating new environments by connecting already existingappscreating new environments from scratch

Requirements

genericreuse

28 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

EIS Meta-Model

By means of the Env. Interface agents perform actions andcollect percepts

actually actions/percepts are issued to controllable entities inenvironment modelrepresent the agent bodies, with e↵ectors and sensors

29 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Environment Interface Features

Interface functions

attaching, detaching, and notifying observers (software designpattern);registering and unregistering agents;adding and removing entities;managing the agents-entities-relation;performing actions and retrieving percepts;managing the environment

Interface Intermediate language

to facilitate data-exchangeencoding percepts, actions, events

30 / 165

Page 6: T2. Organization and Environment oriented programming

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Advanced Level Overview

Vision: environment as a first-class abstraction inMAS [Weyns et al., 2007, Ricci et al., 2010b]

application or endogenous environments, i.e. thatenvironment which is an explicit part of the MASproviding an exploitable design & programming abstractionto build MAS applications

Outcomedistinguishing clearly between the responsibilities of agent andenvironment

separation of concerns

improving the engineering practice

31 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Three Support Levels [Weyns et al., 2007]

Basic interface support

Abstraction support level

Interaction-mediation support level

32 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Basic Interface Support

The environment enables agents to access the deploymentcontext

i.e. the hardware and software and external resources withwhich the MAS interacts

33 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Abstraction Support

Bridges the conceptual gap between the agent abstractionand low-level details of the deployment context

shields low-level details of the deployment context

34 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Interaction-Mediation Support

Regulate the access to shared resources

Mediate interaction between agents

35 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Environment Definition Revised

Environment definition revised [Weyns et al., 2007]

The environment is a first-class abstraction that provides thesurrounding conditions for agents to exist and that mediates boththe interaction among agents and the access to resources

36 / 165

Page 7: T2. Organization and Environment oriented programming

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Research on Environments for MAS

Environments for Multi-Agent Systems research field /E4MAS workshop series [Weyns et al., 2005]

di↵erent themes and issues (see JAAMAS SpecialIssue [Weyns and Parunak, 2007] for a good survey)

mechanisms, architectures, infrastructures,applications [Platon et al., 2007, Weyns and Holvoet, 2007,Weyns and Holvoet, 2004, Viroli et al., 2007]

the main perspective is (agent-oriented) software engineering

Focus of this tutorial: the role of the environmentabstraction in MAS programming

environment programming

37 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Environment Programming

Environment as first-class programmingabstraction [Ricci et al., 2010b]

software designers and engineers perspectiveendogenous environments (vs. exogenous one)programming MAS =programming Agents + programming Environment

..but this will be extended to include OOP in next part

Environment as first-class runtime abstraction for agents

agent perspectiveto be observed, used, adapted, constructed, ...

Defining computational and programmingframeworks/models also for the environment part

38 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Computational Frameworks for EnvironmentProgramming: Issues

Defining the environment interface

actions, percepts, data modelcontract concept, as defined in software engineering contexts(Design by Contract)

Defining the environment computational model

environment structure, behaviour

Defining the environment distribution model

topology

39 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Programming Models for the Environment: Desiderata

Abstraction

keeping the agent abstraction level e.g. no agents sharing andcalling OO objectse↵ective programming models for controllable and observablecomputational entities

Modularity

away from the monolithic and centralised view

Orthogonality

wrt agent models, architectures, platformssupport for heterogeneous systems

40 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Programming Models for the Environment: Desiderata

Dynamic extensibility

dynamic construction, replacement, extension of environmentpartssupport for open systems

Reusability

reuse of environment parts for di↵erent kinds of applications

41 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Existing Computational Frameworks

AGRE / AGREEN / MASQ [Stratulat et al., 2009]AGRE – integrating the AGR (Agent-Group-Role)organisation model with a notion of environment

Environment used to represent both the physical and socialpart of interaction

AGREEN / MASQ – extending AGRE towards a unifiedrepresentation for physical, social and institutionalenvironmentsBased on MadKit platform [Gutknecht and Ferber, 2000a]

GOLEM [Bromuri and Stathis, 2008]Logic-based framework to represent environments for situatedcognitive agentscomposite structure containing the interaction betweencognitive agents and objects

A&A and CArtAgO [Ricci et al., 2010b]introducing a computational notion of artifact to design andimplement agent environments

42 / 165

Page 8: T2. Organization and Environment oriented programming

A&A and CArtAgO

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Agents and Artifacts (A&A) Conceptual Model:Background Human Metaphor

WHITEBOARDartifact

ARCHIVEartifact

COM. CHANNELartifact

TASK SCHEDULERartifact

RESOURCE artifact

CLOCKartifact

BAKERY

workspace

agents can joindynamically the workspace

44 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

A&A Basic Concepts [Omicini et al., 2008]

Agents

autonomous, goal-oriented pro-active entitiescreate and co-use artifacts for supporting their activities

besides direct communication

Artifactsnon-autonomous, function-oriented, stateful entities

controllable and observable

modelling the tools and resources used by agents

designed by MAS programmers

Workspaces

grouping agents & artifactsdefining the topology of the computational environment

45 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

A&A Programming Model Features [Ricci et al., 2007b]

Abstraction

artifacts as first-class resources and tools for agents

Modularisation

artifacts as modules encapsulating functionalities, organizedin workspaces

Extensibility and openness

artifacts can be created and destroyed at runtime by agents

Reusability

artifacts (types) as reusable entities, for setting up di↵erentkinds of environments

46 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

A&A Meta-Model in More Detail [Ricci et al., 2010b]

Artifact

Operation

Observable Event

generate

Agentuse

perceive

Workspace

Environment

ObservableProperty

update

perceive

observe

Manual

has

consult

link

create

dispose

link

join

quit

47 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Artifact Abstract Representation

OperationX(Params)

...

ObsPropName(Args)

...

SIGNALS

USAGE

INTERFACE

OBSERVABLE

PROPERTIES

OperationY(Params)

...

LINK

INTERFACE

OPERATIONS

48 / 165

Page 9: T2. Organization and Environment oriented programming

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

A World of Artifacts

put

n_items 0

max_items 100

get

a bounded buffer

inc

count 5

reset

a counter

switch

state true

a flag

setTodo

last_todo ...

cancelTodo

next_todo check_plant

an agenda

...

GetLastTradePrice

a Stock Quote Web Service

availablestate

...wsdl

postEvent

registerForEvs

clearEvents

an event service

query

createTable

addRecord

a data-base

...

1001n_records

table_names ...

... ...

in

rd

out

a tuple space

49 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

A Simple Taxonomy

Individual or personal artifactsdesigned to provide functionalities for a single agent use

e.g. an agenda for managing deadlines, a library...

Social artifacts

designed to provide functionalities for structuring andmanaging the interaction in a MAScoordination artifacts [Omicini et al., 2004], organisationartifacts, ...

e.g. a blackboard, a game-board,...

Boundary artifactsto represent external resources/services

e.g. a printer, a Web Service

to represent devices enabling I/O with users

e.g GUI, console, etc.

50 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Actions and Percepts in Artifact-Based Environments

Explicit semantics defined by the (endogenous)environment [Ricci et al., 2010c]

success/failure semantics, execution semanticsdefining the contract (in the SE acceptation) provided by theenvironment

actions ! artifacts’ operationthe action repertoire is given by the dynamic set of operationsprovided by the overall set of artifacts available in the workspacecan be changed by creating/disposing artifacts

action success/failure semantics is defined by operationsemantics

percepts ! artifacts’ observable properties + signalsproperties represent percepts about the state of the environmentsignals represent percepts concerning events signalled by theenvironment

51 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Interaction Model: Use

op(Params)

ValuePropName

ValuePropName...

...

AGENT

op(parms)action

Performing an action corresponds to triggering the executionof an operation

acting on artifact’s usage interface

52 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Interaction Model: Operation execution

OPERATION EXECUTIONop(Params)

ValuePropNameValue...

...

SIGNALS OBS PROPERTIESCHANGE

AGENT

op(parms)action

action completion- with success or failure -

a process structured in one or multiple transactional steps

asynchronous with respect to agent...which can proceed possibly reacting to percepts and

executing actions of other plans/activities

operation completion causes action completionaction completion events with success or failure, possibly withaction feedbacks

53 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Interaction Model: Observation

Belief base(or alike)

PropName(Value).PropName(Value).... ValuePropName

ValuePropName...

focus

AGENTOBSERVER

Agents can dynamically select which artifacts to observe

predefined focus/stopFocus actions

54 / 165

Page 10: T2. Organization and Environment oriented programming

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Interaction Model: Observation

AGENTOBSERVER

Belief base(or alike)

PropName(Value).PropName(Value).... ValuePropName

ValuePropName...

use

By focussing an artifactobservable properties are mapped into agent dynamicknowledge about the state of the world, as percepts

e.g. belief base

signals are mapped as percepts related to observable events

55 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Artifact Linkability

WSP-X WSP-Y

linkedOp

Basic mechanism to enable inter-artifact interactionlinking artifacts through interfaces (link interfaces)

operations triggered by an artifact over an other artifact

Useful to design & program distributed environments

realised by set of artifacts linked togetherpossibly hosted in di↵erent workspaces

56 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Artifact Manual

Agent-readable description of artifact’s......functionality

what functions/services artifacts of that type provide

...operating instructions

how to use artifacts of that type

Towards advanced use of artifacts by intelligentagents [Piunti et al., 2008]

dynamically choosing which artifacts to use to accomplishtheir tasks and how to use themstrong link with Semantic Web research issues

Work in progress

defining ontologies and languages for describing the manuals

57 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

CArtAgO

Common ARtifact infrastructure for AGent Openenvironment (CArtAgO) [Ricci et al., 2009b]

Computational framework / infrastructure to implement andrun artifact-based environment [Ricci et al., 2007c]

Java-based programming model for defining artifactsset of basic API for agent platforms to work withinartifact-based environment

Distributed and open MASworkspaces distributed on Internet nodes

agents can join and work in multiple workspace at a time

Role-Based Access Control (RBAC) security model

Open-source technology

available at http://cartago.sourceforge.net

58 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Integration with Agent Languages and Platforms

Integration with existing agent platforms [Ricci et al., 2008]

by means of bridges creating an action/perception interfaceand doing data binding

Outcome

developing open and heterogenous MASintroducing a further perspective on interoperability besidesthe ACL’s one

sharing and working in a common work environmentcommon object-oriented data-model

59 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

JaCa Platform

Integration of CArtAgO with Jason language/platform

a JaCa program is a dynamic set of Jason agents workingtogether in one or multiple CArtAgO workspaces

Mappingactions

Jason agent external actions are mapped onto artifacts’operations

percepts

artifacts’ observable properties are mapped onto agent beliefsartifacts’ signals are mapped as percepts related toobservable events

data-model

Jason data-model is extended to manage also (Java) objects

60 / 165

Page 11: T2. Organization and Environment oriented programming

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Example 1: A Simple Counter Artifact

class Counter extends Artifact { void init(){ defineObsProp("count",0); } @OPERATION void inc(){ ObsProperty p = getObsProperty("count"); p.updateValue(p.intValue() + 1); signal("tick"); }}

inc

count 5

Some API spots

Artifact base class@OPERATION annotation to mark artifact?s operationsset of primitives to work define/update/.. observablepropertiessignal primitive to generate signals

61 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Example 1: User and Observer Agents

!create_and_use.

+!create_and_use : true <- !setupTool(Id); // use inc; // second use specifying the Id inc [artifact_id(Id)].

// create the tool+!setupTool(C): true <- makeArtifact("c0","Counter",C).

!observe.

+!observe : true <- ?myTool(C); // discover the tool focus(C).

+count(V) <- println(“observed new value: “,V).

+tick [artifact_name(Id,”c0”)] <- println(“perceived a tick”).

+?myTool(CounterId): true <- lookupArtifact(“c0”,CounterId).

-?myTool(CounterId): true <- .wait(10); ?myTool(CounterId).

OBSERVER(S)USER(S)

Working with the shared counter

62 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Pre-defined Artifacts

Each workspace contains by default a predefined set ofartifacts

providing core and auxiliary functionalitiesi.e. a pre-defined repertoire of actions available to agents...

Among the othersworkspace, type: cartago.WorkspaceArtifact

functionalities to manage the workspace, including securityoperations: makeArtifact, lookupArtifact, focus,...

node, type: cartago.NodeArtifact

core functionalities related to a nodeoperations: createWorkspace, joinWorkspace, ...

console, type cartago.tools.Console

operations: println,...

blackboard, type cartago.tools.TupleSpace

operations: out, in, rd, ...

....

63 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Example 2: Coordination Artifacts – A Bounded Bu↵er

public class BoundedBuffer extends Artifact { private LinkedList<Item> items; private int nmax; void init(int nmax){ items = new LinkedList<Item>(); defineObsProperty("n_items",0); this.nmax = nmax; }

@OPERATION void put(Item obj){ await("bufferNotFull"); items.add(obj);

getObsProperty("n_items").updateValue(items.size()); }

@OPERATION void get(OpFeedbackParam<Item> res) { await("itemAvailable"); Item item = items.removeFirst();

res.set(item);getObsProperty("n_items").updateValue(items.size());

}

@GUARD boolean itemAvailable(){ return items.size() > 0; }

@GUARD boolean bufferNotFull(Item obj){ return items.size() < nmax; }}

put

n_items 5

get

Basic operation featuresoutput parameters to represent action feedbackslong-term operations, with a high-level support forsynchronization (await primitive, guards)

64 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Example 2: Producers and Consumers

item_to_produce(0).!produce.

+!produce: true <- !setupTools(Buffer); !produceItems.

+!produceItems : true <- ?nextItemToProduce(Item); put(Item); !!produceItems.

+?nextItemToProduce(N) : true <- -item_to_produce(N); +item_to_produce(N+1).

+!setupTools(Buffer) : true <- makeArtifact("myBuffer","BoundedBuffer", [10],Buffer).

-!setupTools(Buffer) : true <- lookupArtifact("myBuffer",Buffer).

!consume.

+!consume: true <- ?bufferReady; !consumeItems. +!consumeItems: true <- get(Item); !consumeItem(Item); !!consumeItems.

+!consumeItem(Item) : true <- .my_name(Me); println(Me,": ",Item). +?bufferReady : true <- lookupArtifact("myBuffer",_). -?bufferReady : true <-.wait(50); ?bufferReady.

PRODUCERS CONSUMERS

65 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Remarks

Process-based operation execution semantics

action/operation execution can be long-termaction/operation execution can overlapkey feature for implementing coordination functionalities

Operation with output parameters as action feedbacks

66 / 165

Page 12: T2. Organization and Environment oriented programming

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Action Execution & Blocking Behaviour

Given the action/operation map, by executing an action theintention/activity is suspended until the correspondingoperation has completed or failed

action completion events generated by the environment andautomatically processed by the agent/environment platformbridgeno need of explicit observation and reasoning by agents toknow if an action succeeded

However the agent execution cycle is not blocked!

the agent can continue to process percepts and possiblyexecute actions of other intentions

67 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Example 3: Internal Processes – A Clock

public class Clock extends Artifact {

boolean working; final static long TICK_TIME = 100;

void init(){ working = false; }

@OPERATION void start(){ if (!working){ working = true; execInternalOp("work"); } else { failed("already_working"); } }

@OPERATION void stop(){ working = false; }

@INTERNAL_OPERATION void work(){ while (working){ signal("tick"); await_time(TICK_TIME); } }}

!test_clock.

+!test_clock <- makeArtifac("myClock","Clock",[],Id); focus(Id); +n_ticks(0); start; println("clock started.").

@plan1+tick: n_ticks(10) <- stop; println("clock stopped.").

@plan2 [atomic]+tick: n_ticks(N) <- -+n_ticks(N+1); println("tick perceived!").

CLOCK CLOCK USER AGENT

Internal operationsexecution of operations triggered by other operationsimplementing controllable processes

68 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Example 4: Artifacts for User I/O – GUI Artifacts

setValue

value 16.0

user

ok

closed

agent

Exploiting artifacts to enable interaction between humanusers and agents

69 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Example 4: Agent and User Interaction

public class MySimpleGUI extends GUIArtifact { private MyFrame frame; public void setup() { frame = new MyFrame(); linkActionEventToOp(frame.okButton,"ok"); linkKeyStrokeToOp(frame.text,"ENTER","updateText"); linkWindowClosingEventToOp(frame, "closed"); defineObsProperty("value",getValue()); frame.setVisible(true); }

@INTERNAL_OPERATION void ok(ActionEvent ev){ signal("ok"); }

@OPERATION void setValue(double value){ frame.setText(""+value); updateObsProperty("value",value); } ... @INTERNAL_OPERATION void updateText(ActionEvent ev){ updateObsProperty("value",getValue()); }

private int getValue(){ return Integer.parseInt(frame.getText()); }

class MyFrame extends JFrame {...}}

!test_gui.

+!test_gui <- makeArtifact("gui","MySimpleGUI",Id); focus(Id).

+value(V) <- println("Value updated: ",V). +ok : value(V) <- setValue(V+1).

+closed <- .my_name(Me); .kill_agent(Me).

GUI ARTIFACT USER ASSISTANT AGENT

70 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Other Features

Other CArtAgO features not discussed in this lecturelinkability

executing chains of operations across multiple artifacts

multiple workspaces

agents can join and work in multiple workspaces, concurrentlyincluding remote workspaces

RBAC security model

workspace artifact provides operations to set/change theaccess control policies of the workspace, depending on theagent roleruling agents’ access and use of artifacts of the workspace

...

See CArtAgO papers and manuals for more information

71 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

A&A and CArtAgO: Some Research Explorations

Designing and implementing artifact-based organisationInfrastructures

JaCaMo model and platform (which is the evolution of theORA4MAS infrastructure [Hubner et al., 2009c])

Cognitive stigmergy based on artifactenvironments [Ricci et al., 2007a]

cognitive artifacts for knowledge representation andcoordination [Piunti and Ricci, 2009]

Artifact-based environments forargumentation [Oliva et al., 2010]

Including A&A in AOSE methodology [Molesini et al., 2005]

Defining a Semantic (OWL-based) description of artifactenvironments ( CArtAgO-DL)

JaSa project = JASDL + CArtAgO-DL

...

72 / 165

Page 13: T2. Organization and Environment oriented programming

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Applying CArtAgO and JaCa

Using CArtAgO/JaCa for building real-world applications andinfrastructures

Some examplesJaCa-Android

implementing mobile computing applications on top of theAndroid platform using JaCa [Santi et al., 2011]http://jaca-android.sourceforge.net

JaCa-WS / CArtAgO-WS

building SOA/Web Services applications usingJaCa [Ricci et al., 2010a]http://cartagows.sourceforge.net

JaCa-Web

implementing Web 2.0 applications using JaCahttp://jaca-web.sourceforge.net

73 / 165

Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up

Wrap-up

Environment programming

environment as a programmable part of the MASencapsulating and modularising functionalities useful foragents’ work

Artifact-based environmentsartifacts as first-class abstraction to design and programcomplex software environments

usage interface, observable properties / events, linkability

artifacts as first-order entities for agents

interaction based on use and observationagents dynamically co-constructing, evolving, adapting theirworld

CArtAgO computational framework

programming and executing artifact-based environmentsintegration with heterogeneous agent platformsJaCa case

74 / 165

Organisation OrientedProgramming— OOP —

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Abstractions in Multi-Agent Systems

roleorgmission

schema

ORGAMISATIONLEVEL

AGENTLEVEL

ENDOGENOUSENVIRONMENTLEVELwsp

artifact

network node

EXOGENOUS ENVIRONMENT

agent

76 / 165

Outline

3 Organisation Oriented Programming (OOP)FundamentalsMotivationsSome OOP approachesFocus on theMoise frameworkMoise Organisation Modelling Language (OML)Moise Organisation Management Infrastructure (OMI)Moise integration with agents & environment

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Organisation in MAS – a definition

What is an organisation?

Pattern of agent cooperation

with a purposesupra-agentemergent orpredefined (by designer or agents)

78 / 165

Page 14: T2. Organization and Environment oriented programming

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Organisation in MAS – a definition

What is an organisation?

Pattern of agent cooperation

with a purposesupra-agentemergent orpredefined (by designer or agents)

78 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Introduction: Some definitions

Organisations are structured, patterned systems of activity,knowledge, culture, memory, history, and capabilities that aredistinct from any single agent [Gasser, 2001] Organisations are supra-individual phenomenaA decision and communication schema which is applied to a set ofactors that together fulfill a set of tasks in order to satisfy goalswhile guarantying a global coherent state [Malone, 1999] definition by the designer, or by actors, to achieve a purposeAn organisation is characterised by: a division of tasks, adistribution of roles, authority systems, communication systems,contribution-retribution systems [Bernoux, 1985] pattern of predefined cooperationAn arrangement of relationships between components, whichresults into an entity, a system, that has unknown skills at the levelof the individuals [Morin, 1977] pattern of emergent cooperation

79 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Perspective on organisations from EASSS’05 Tutorial (Sichman, Boissier)

Agents know about organisation

Agents don’t know about organisation

���������� ������Organisation Specification Observed Organisation

Designer / Observer Bottom-up Top-down Organisation Entity

Agent Centred

Organisation Centred

80 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Perspective on organisations from EASSS’05 Tutorial (Sichman, Boissier)

Agents know about organisation

Agents don’t know about organisation

Agent Centred Swarms, AMAS, SASO Self-organisations …

Organisation is observed. Implicitly programmed in Agents, Interactions, Environment.

Social Reasoning Coalition formation Contract Net Protocol … Organisation is observed. Coalition formation mechanisms programmed in Agents.

AOSE MASE, GAIA, MESSAGE, …

Organisation is a design model. It is hard-coded in Agents

TAEMS, STEAM, AGR MOISE+, OPERA, …

Organisation-Oriented Programming of MAS

Organisation Centred ���������� ������Organisation Specification Observed Organisation

Designer / Observer Bottom-up Top-down Organisation Entity

81 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Organisation Oriented Programming (OOP)

Organisation Entity

OrganisationSpecification

Agent

Agent

Agent

Programming outsidethe agents

Using organisationalconcepts

To define a cooperativepattern

Program = Specification

By changing thespecification, we canchange the MAS overallbehaviour

82 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Organisation Oriented Programming (OOP)

Organisation Entity

OrganisationSpecification

Agent

Agent

Agent First approach

Agents read the programand follow it

82 / 165

Page 15: T2. Organization and Environment oriented programming

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Organisation Oriented Programming (OOP)

Organisation Entity

OrganisationSpecification

Agent

Agent

Agent

Second approach

Agents are forced tofollow the program

Agents are rewarded ifthey follow the program

...

82 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Organisation Oriented Programming (OOP)

Organisation Entity

OrganisationSpecification

Agent

Agent

Agent

Second approach

Agents are forced tofollow the program

Agents are rewarded ifthey follow the program

...

82 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Organisation Oriented Programming (OOP)

Organisation Entity

OrganisationSpecification

Agent

Agent

Agent

Components

Programming language(OML)

Platform (OMI)

Integration to agentarchitectures andenvironment

82 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Components of OOP:Organisation Modelling Language (OML)

Declarative specification of the organisation(s)

Specific constraints, norms and cooperation patternsimposed on the agents

Based on an organisational model

e.g. AGR [Ferber and Gutknecht, 1998],TeamCore [Tambe, 1997],Islander [Esteva et al., 2001],Moise+ [Hubner et al., 2002],Opera [Dignum and Aldewereld, 2010],2OPL [Dastani et al., 2009a],...

83 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Components of OOP:Organisation Management Infrastructure (OMI)

Coordination mechanisms, i.e. support infrastructure

e.g. MadKit [Gutknecht and Ferber, 2000b],Karma [Pynadath and Tambe, 2003],...

Regulation mechanisms, i.e. governance infrastructure

e.g. Ameli [Esteva et al., 2004],S-Moise+ [Hubner et al., 2006],ORA4MAS [Hubner et al., 2009b],...

Adaptation mechanisms, i.e. reorganisation infrastructure

84 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Components of OOP:Integration mechanisms

Agent integration mechanismsallow agents to be aware of and to deliberate on:

entering/exiting the organisationmodification of the organisationobedience/violation of normssanctioning/rewarding other agents

e.g. J -Moise+ [Hubner et al., 2007], Autonomy basedreasoning [Carabelea, 2007], ProsA2 Agent-based reasoningon norms [Ossowski, 1999], ...

Environment integration mechanismstransform organisation into embodied organisation so that:

organisation may act on the environment (e.g. enact rules,regimentation)environment may act on the organisation (e.g. count-as rules)

e.g [Piunti et al., 2009b], [Okuyama et al., 2008]

85 / 165

Page 16: T2. Organization and Environment oriented programming

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Motivations for OOP:Applications point of view

Current applications show an increase in

Number of agentsDuration and repetitiveness of agent activitiesHeterogeneity of the agentsNumber of designers of agentsAgent ability to act and decideOpenness, scalability, dynamism

More and more applications require the integration of humancommunities and technological communities (ubiquitous andpervasive computing), building connected communities(ICities) in which agents act on behalf of users

Trust, security, ..., flexibility, adaptation

86 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Motivations for OOP:Constitutive point of view

Organisation helps the agents to cooperate with otheragents by defining common cooperation schemes

global tasksprotocolsgroups, responsibilities

e.g. ‘to bid’ for a product on eBay is an institutional action onlypossible because eBay defines rules for that very action

the bid protocol is a constraint but it also creates the action

e.g. when a soccer team wants to play match, the organisationhelps the members of the team to synchronise actions, toshare information, etc

87 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Motivations for OOP:Normative point of view

MAS have two properties which seem contradictory:

a global purposeautonomous agents

While the autonomy of the agents is essential, it may causeloss in the global coherence of the system and achievement ofthe global purpose

Embedding norms within the organisation of an MAS is away to constrain the agents’ behaviour towards the globalpurposes of the organisation, while explicitly addressing theautonomy of the agents within the organisation

Normative organisatione.g. when an agent adopts a role, it adopts a set of behavioural

constraints that support the global purpose of theorganisation.It may decide to obey or disobey these constraints

88 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Motivations for OOP:Agents point of view

An organisational specification is required to enable agents to“reason” about the organisation:

to decide to enter into/leave from the organisation duringexecution

Organisation is no more closed

to change/adapt the current organisation

Organisation is no more static

to obey/disobey the organisation

Organisation is no more a regimentation

89 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Motivations for OOP:Organisation point of view

An organisational specification is required to enable theorganisation to “reason” about itself and about the agents inorder to ensure the achievement of its global purpose:

to decide to let agents enter into/leave from theorganisation during execution

Organisation is no more closed

to decide to let agents change/adapt the currentorganisation

Organisation is no more static and blind

to govern agents behaviour in the organisation (i.e. monitor,enforce, regiment)

Organisation is no more a regimentation

90 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Some OOP approaches

AGR/Madkit [Ferber and Gutknecht, 1998]

STEAM/Teamcore [Tambe, 1997]

ISLANDER/AMELI [Esteva et al., 2004]

Opera/Operetta [Dignum and Aldewereld, 2010]

PopOrg [Rocha Costa and Dimuro, 2009]

2OPL [Dastani et al., 2009a]

...

91 / 165

Page 17: T2. Organization and Environment oriented programming

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

AGR [Ferber and Gutknecht, 1998]

Agent Group Role (previously known as AALAADIN)

Agent: Active entity that plays roles within groups. An agentmay have several roles and may belong to several groupsGroup: set of agents sharing common characteristics, i.e.context for a set of activities. Two agents cant communicatewith each other if they dont belong to the same groupRole: Abstract representation of the status, position,function of an agent within a group

OMI: the Madkit platform

92 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

AGR OML

Interaction protocol

Group structure Role 1..* 1

contains

source

participant

1

*

1..*

* Role dependency Role properties *

1

1 1

target

Agent

Group

*

1..*

*

1..*

is member of

plays

1

described by 1 1

initiator 1

Agent level

Organization level

93 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

AGR OML Modelling Dimensions

P E

Environment

B

B: agents’ possible behaviors P: agents’ behaviors that lead to global purpose E: agents’ possible behaviors constrained by the environment OS: agents’ possible behaviors structurally constrained by the organization

OS

Structural Specification

94 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

STEAM [Tambe, 1997]

Shell for TEAMwork is a general framework to enable agentsto participate in teamwork

Di↵erent applications: Attack, Transport, Robocup soccerBased on an enhanced SOAR architecture and 300 domainindependent SOAR rules

Principles:

Team synchronisation: Establish joint intentions, Monitorteam progress and repair, Individual may fail or succeed inown roleReorganise if there is a critical role failureReassign critical roles based on joint intentionsDecision theoretic communication

Supported by the TEAMCORE OMI

95 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

STEAM OML [Tambe, 1997]

TASK FORCE

ORDERS OBTAINER

SAFETY INFO OBTAINER

FLIGHT TEAM

ROUTE PLANNER

ESCORT TRANSPORT

HELO1 HELO2 HELO1 HELO2

Organization: hierarchy of roles that may be filled by agents or groups of agents.

[TASK FORCE]

[TASK FORCE] [TASK FORCE] [TASK FORCE]

[ORDERS OBTAINER]

[TASK FORCE] [ESCORT] [TRANSPORT]

[TASK FORCE]

EVACUATE

PROCESS ORDERS

EXECUTE MISSION

LANDING ZONE MANEUVERS

OBTAIN ORDERS

FLY-FLIGHT PLAN

MASK OBSERVE PICKUP

FLY-CONTROL ROUTE

Team Plan: •  initial conditions, •  term. cond. : achievability, irrelevance, unachievability •  team-level actions.

96 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

STEAM OML Modelling Dimensions

E

Environment

P

Structural Specification

OF Functional Specification

OS

B

B: agents’ possible behaviors P: agents’ behaviors that lead to global purpose E: agents’ possible behaviors constrained by the environment OS: agents’ possible behaviors structurally constrained by the organization OF: agents’ possible behaviors functionally constrained by the organization

97 / 165

Page 18: T2. Organization and Environment oriented programming

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

ISLANDER

Based on di↵erent influences: economics, norms, dialogues,coordination

electronic institutions

Combining di↵erent alternative views: dialogical, normative,coordination

Institution Description Language:

Performative structure (Network of protocols)Scene (multi-agent protocol)RolesNorms

Ameli as OMI

98 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

ISLANDER OML: IDL [Esteva et al., 2001]

Performative Structure

(define-institution soccer-server as dialogic-framework = soccer-df performative-structure = soccer-pf norms = ( free-kick coach-messages … )

)

99 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

ISLANDER OML Modelling Dimensions

E

Environment

P

B

B: agents’ possible behaviors P: agents’ behaviors that lead to global purpose E: agents’ possible behaviors constrained by the environment OS: agents’ possible/permitted/obliged behaviors structurally constrained by the organisation OI: agents’ possible/permitted/obliged behaviors interactionally constrained by the organisation

OI Structural Specification

OS

Dialogical Specification

100 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

2OPL slides from Dastani

The aim is to design and develop a programming language tosupport the implementation of coordination mechanisms in termsof normative concepts.

An organisation

determines e↵ect of external actions

normatively assesses e↵ect of agents’ actions (monitoring)

sanctions agents’ wrongdoings (enforcement)

prevents ending up in really bad states (regimentation)

101 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Programming Language for Organisations

Example (Train Station)

Facts:

– -at˙platform , -in˙train , -ticket ˝

Effects:

– -at˙platform ˝ enter – at˙platform ˝,

– -ticket ˝ buy˙ticket – ticket ˝,

– at˙platform , -in˙train ˝

embark

– -at˙platform, in˙train ˝

Counts˙as rules:

– at˙platform , -ticket ˝ =¿ – viol˙ticket ˝,

– in˙train , -ticket ˝ =¿ – viol˙—˙ ˝

Sanction˙rules:

– viol˙ticket ˝ =¿ – fined˙10 ˝

102 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

2OPL Modelling Dimension

103 / 165

Page 19: T2. Organization and Environment oriented programming

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Summary

Several models

Several dimensions on modelling organisation

Structural (roles, groups, ...)Functional (global plans, ....)Dialogical (scenes, protocols, ...)Normative (norms)

104 / 165

TheMoise Framework

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Moise Framework

OML (language)

Tag-based language(issued fromMoise [Hannoun et al., 2000],Moise+ [Hubner et al., 2002],MoiseInst [Gateau et al., 2005])

OMI (infrastructure)

developed as an artifact-based working environment(ORA4MAS [Hubner et al., 2009b] based on CArtAgOnodes, refactoring of S-Moise+ [Hubner et al., 2006] andSynai [Gateau et al., 2005])

Integrations

Agents and Environment (c4Jason, c4Jadex[Ricci et al., 2009c])Environment and Organisation ([Piunti et al., 2009a])Agents and Organisation (J -Moise+ [Hubner et al., 2007])

106 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Moise Modelling Dimensions

E

Environment

P

OF Functional Specification

Global goals, plans, Missions, schemas, preferences

B Structural Specification

Groups, links, roles Compatibilities, multiplicities inheritance

OS

Normative Specification Permissions, Obligations Allows agents autonomy!

107 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Moise OML meta-model (partial view)

Agent Goal

MissionRole

Group

Social Scheme

createdelete

adoptleave

createdelete

agent's actionscompositionassociation

Cardinalities are not represented

concept mapping

Norm

Goal

commit leave

achieve

StructuralSpecification

NormativeSpecification

FunctionalSpecification

108 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Moise OML

OML for defining organisation specification and organisationentity

Three independent dimensions [Hubner et al., 2007]( well adapted for the reorganisation concerns):

Structural: Roles, GroupsFunctional: Goals, Missions, SchemesNormative: Norms (obligations, permissions, interdictions)

Abstract description of the organisation for

the designersthe agents

J -Moise+ [Hubner et al., 2007]the Organisation Management Infrastructure

ORA4MAS [Hubner et al., 2009b]

109 / 165

Page 20: T2. Organization and Environment oriented programming

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Moise OML Structural Specification

Specifies the structure of an MAS along three levels:

Individual with RoleSocial with LinkCollective with Group

Components:

Role: label used to assign rights and constraints on thebehavior of agents playing itLink: relation between roles that directly constrains theagents in their interaction with the other agents playing thecorresponding rolesGroup: set of links, roles, compatibility relations used todefine a shared context for agents playing roles in it

110 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Structural Specification Example

Graphical representation of structural specification of 3-5-2 Joj Team

111 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Moise OML Functional Specification

Specifies the expected behaviour of an MAS in terms ofgoals along two levels:

Collective with SchemeIndividual with Mission

Components:Goals:

Achievement goal (default type). Goals of this type shouldbe declared as satisfied by the agents committed to them,when achievedMaintenance goal. Goals of this type are not satisfied at aprecise moment but are pursued while the scheme is running.The agents committed to them do not need to declare thatthey are satisfied

Scheme: global goal decomposition tree assigned to a group

Any scheme has a root goal that is decomposed into subgoals

Missions: set of coherent goals assigned to roles withinnorms

112 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Functional Specification Example

score a goal

m1

go towards the opponent field

m1, m2, m3

get the ball

be placed in the middle field

be placed in the opponent goal area kick the ball to (agent committed to m2)

go to the opponent back line

kick the ball to the goal area

shot at the opponent’s goal

m1

m1

m2 m2

m2

m3

m3

Key

goalmissions

success rate parallelismchoicesequence

Scheme

Organizational EntityLucio

Cafu

Rivaldo

m1

m2

m3

Graphical representation of social scheme “side attack” for joj team

113 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Goal States

waiting

satisfiedimpossible

enabled

waiting initial state

enabled goal pre-conditions are satisfied &scheme is well-formed

satisfied agents committed to the goal have achieved it

impossible the goal is impossible to be satisfied

114 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Moise OML Normative Specification

Explicit relation between the functional and structuralspecifications

Permissions and obligations to commit to missions in thecontext of a role

Makes explicit the normative dimension of a role

115 / 165

Page 21: T2. Organization and Environment oriented programming

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Norm Specification – example

role deontic mission TTF

back obliged m1 get the ball, go ... 1 minuteleft obliged m2 be placed at ..., kick ... 3 minuteright obliged m2 1 dayattacker obliged m3 kick to the goal, ... 30 seconds

116 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Organisational Entity

norrmative groups

roles

structural

schemas

missions

functional

group instances role

player

schema instances

mission player

agents

purpose

Organisation specification

Organisation Entity

links norms

117 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Organisation Entity Dynamics

1 Organisation is created (by the agents)

instances of groupsinstances of schemes

2 Agents enter into groups adopting roles3 Groups become responsible for schemes

Agents from the group are then obliged to commit tomissions in the scheme

4 Agents commit to missions

5 Agents fulfil mission’s goals

6 Agents leave schemes and groups

7 Schemes and groups instances are destroyed

118 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Organisation management infrastructure (OMI)

Responsibility

Managing – coordination, regulation – the agents’ executionwithin organisation defined in an organisational specification

OrganisationSpecification OMI

AgentAgentAgentAgent

(e.g. MadKit, AMELI, S-Moise+, ...)

119 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Organisational artifacts in ORA4MAS

System

Agent

GroupArtifact

SchemeArtifact

SchemeArtifact

Agent

Agent

Agent

Agent

Agent

based on A&A andMoiseagents create and handleorganisational artifacts

artifacts in charge ofregimentations,detection and evaluationof norms compliance

agents are in charge ofdecisions aboutsanctions

distributed solution

120 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

ORA4MAS – GroupBoard artifact

GroupBoard

Specification

Players

Schemes

adoptRole

leaveRole

addScheme

removeScheme

Formation status

Observable Properties:

specification: thespecification of the group inthe OS (an object of classmoise.os.ss.Group)

players: a list of agentsplaying roles in the group.Each element of the list is apair (agent x role)

schemes: a list of schemeidentifiers that the group isresponsible for

121 / 165

Page 22: T2. Organization and Environment oriented programming

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

ORA4MAS – GroupBoard artifact

GroupBoard

Specification

Players

Schemes

adoptRole

leaveRole

addScheme

removeScheme

Formation status

Operations:

adoptRole(role): the agentexecuting this operationtries to adopt a role in thegroup

leaveRole(role)

addScheme(schid): thegroup starts to beresponsible for the schememanaged by theSchemeBoard schId

removeScheme(schid)

122 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

ORA4MAS – SchemeBoard artifact

SchemeBoard

Specification

Players

Goals

Obligations

commitMission

leaveMission

goalAchieved

setGoalArgument

Groups

Observable Properties:

specification: thespecification of the schemein the OS

groups: a list of groupsresponsible for the scheme

players: a list of agentscommitted to the scheme.Each element of the list is apair (agent, mission)

goals: a list with thecurrent state of the goals

obligations: list ofobligations currently activein the scheme

123 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

ORA4MAS – SchemeBoard artifact

SchemeBoard

Specification

Players

Goals

Obligations

commitMission

leaveMission

goalAchieved

setGoalArgument

Groups

Operations:

commitMission(mission)and leaveMission:operations to “enter” and“leave” the scheme

goalAchieved(goal): definesthat some goal is achievedby the agent performing theoperation

setGoalArgument(goal,argument, value): definesthe value of some goal’sargument

124 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Organisational Artifact Architecture

OrganisationArtifact

NPL Interpreter

NOPLProgram

GroupState

NPLEngine

ObligationsState

Organisation Specificatoin

translates

Signals (o = obligation(to whom, reason, what, deadline)):

obl created(o): the obligation o is created

obl fulfilled(o): the obligation o is fulfilled

obl unfulfilled(o): the obligation o is unfulfilled

obl inactive(o): the obligation o is inactive

norm failure(f ): the failure f has happened125 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Environment integration

Organisational Artifacts enable organisation and environmentintegration

Embodied organisation [Piunti et al., 2009a]

Env. Artifact Org. Artifactcount-as

enact

count-as

status: ongoing work

126 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Environment integration: constitutive rules

Count-As rule

An event occurring on an artifact, in a particular context, maycount-as an institutional event

transforms the events created in the working environmentinto activation of an organisational operation

indirect automatic updating of the organisation

Enact rule

An event produced on an organisational artifact, in a specificinstitutional context, may “enact” change and updating of theworking environment (i.e., to promote equilibrium, avoidundesiderable states)

Installing automated control on the working environment

Even without the intervention of organisational/sta↵ agents(regimenting actions on physical artifacts, enforcingsanctions, ...) 127 / 165

Page 23: T2. Organization and Environment oriented programming

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Agent integration

Agents can interact with organisational artifacts as withordinary artifacts by perception and action

Any Agent Programming Language integrated withCArtAgO can use organisational artifacts

Agent integration provides some “internal” tools for the agentsto simplify their interaction with the organisation:

maintenance of a local copy of the organisational state

production of organisational events

provision of organisational actions

128 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

J -Moise: Jason +Moise

Agents are programmed with Jason

BDI agents (reactive planning) – suitable abstraction level

The programmer has the possibility to express sophisticatedrecipes for adopting roles, committing to missions,fulfilling/violating norms, ...

Organisational information is made accessible in the mentalstate of the agent as beliefs

Integration is totally independent of thedistribution/communication layer

129 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

J -Moise: Jason +Moise– General view

Jason-CArtAgo Agent

Plan Library

Belief Base

Organisational Workspace (CArtAgO)

Intentions

J-Moise+����� ��������������������

130 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Organisational actions in Jason I

Example (GroupBoard)...

joinWorkspace(”ora4mas”,O4MWsp);

makeArtifact(

”auction”,

”ora4mas.nopl.GroupBoard”,

[”auction-os.xml”, auctionGroup, false, true ],

GrArtId);

adoptRole(auctioneer);

focus(GrArtId);

...

131 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Organisational actions in Jason II

Example (SchemeBoard)...

makeArtifact(

”sch1”,

”ora4mas.nopl.SchemeBoard”,

[”auction-os.xml”, doAuction, false, true ],

SchArtId);

focus(SchArtId);

addScheme(Sch);

commitMission(mAuctioneer)[artifact˙id(SchArtId)];

...

132 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Organisational perception

When an agent focus on an Organisational Artifact, theobservable properties (Java objects) are translated to beliefs withthe following predicates:

specification

play(agent, role, group)

commitment(agent, mission, scheme)

goalState(scheme, goal, list of committed agents, list ofagent that achieved the goal, state of the goal)

obligation(agent,norm,goal,dead line)

....

133 / 165

Page 24: T2. Organization and Environment oriented programming

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Organisational perception – example

134 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Handling organisational events in Jason

Whenever something changes in the organisation, the agentarchitecture updates the agent belief base accordingly producingevents (belief update from perception)

Example (new agent entered the group)

+play(Ag,boss,GId) ¡- .send(Ag,tell,hello).

Example (change in goal state)

+goalState(Scheme,wsecs,˙,˙,satisfied)

: .my˙name(Me) & commitment(Me,mCol,Scheme)

¡- leaveMission(mColaborator,Scheme).

Example (signals)

+normFailure(N) ¡- .print(”norm failure event: ”, N).

135 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Typical plans for obligations

Example

+obligation(Ag,Norm,committed(Ag,Mission,Scheme),DeadLine)

: .my˙name(Ag)

¡- .print(”I am obliged to commit to ”,Mission);

commit˙mission(Mission,Scheme).

+obligation(Ag,Norm,achieved(Sch,Goal,Ag),DeadLine)

: .my˙name(Ag)

¡- .print(”I am obliged to achieve goal ”,Goal);

!Goal[scheme(Sch)];

goal˙achieved(Goal,Sch).

+obligation(Ag,Norm,What,DeadLine)

: .my˙name(Ag)

¡- .print(”I am obliged to ”,What,

”, but I don’t know what to do!”).

136 / 165

Introduction EOP OOP Conclusion Introduction Motivations OOP Moise

Summary –Moise

Ensures that the agents follow some of the constraintsspecified for the organisation

Helps the agents to work together

The organisation is interpreted at runtime, it is nothardwired in the agents code

The agents ‘handle’ the organisation (i.e. their artifacts)

It is suitable for open systems as no specific agentarchitecture is required

All available as open source at

http://moise.souceforge.net

137 / 165

Conclusions

Introduction EOP OOP Conclusion

Putting the Pieces Together

BELIEFSGOALSPLANS

INTERNALEVENTS

ACTIONSPERCEPTIONS

AGENTS

MISSIONS

ROLES

DEONTIC RELATIONS

GROUPS

NORMS

SANCTIONSREWARDS

ORGANISATIONS

RESOURCES

LEGACY

SERVICES OBJECTS

ENVIRONMENTS

COMMUNICATIONLANGUAGES

INTERACTIONPROCOLS

SPEECH ACTS

INTERACTIONS

MOISE Framework

JASON Agent Prog. Language

JADE Platform

CarTaGO Platform?

139 / 165

Page 25: T2. Organization and Environment oriented programming

Introduction EOP OOP Conclusion

Exploiting Orthogonality

Treating AOP & EOP & OOP as orthogonal dimensionsimproving separation of concerns

using the best abstraction level and tools to tackle thespecific dimensions, avoiding design pitfalls, such as usingagents to implement either non-autonomous entities (e.g., ablackboard agent) or a collection of autonomous entities(group agent)

promoting openness and heterogeneity

E.g., heterogeneous agents working in the same organisation,heterogeneous agents working in the same environment, thesame agent working in di↵erent and heterogeneousorganisations, the same agent working in di↵erentheterogeneous environments

Outcome from a programming point of view

code more clean and understandableimproving modularity, extensibility, reusability

140 / 165

Introduction EOP OOP Conclusion

Beyond Orthogonality: Synergetic Integration

Exploiting one dimension to e↵ectively design and programalso aspects related to the other dimensions

for instance, using the environment to design, implement andrepresent at runtime the organisation infrastructure

Designing and implementing MAS behaviours that are basedon explicit bindings between the di↵erent dimensions

for instance, exploiting events occurring in the environment torepresent events that have an e↵ect at the institutional orsocial level

141 / 165

Introduction EOP OOP Conclusion

Exploiting Synergy between the A/E Dimensions

Mapping

agent actions into environment operations (e.g. CArtAgO)environment observable state/events into agent beliefs

Outcome

agents with dynamic action repertoireuniformly implementing any mechanisms (e.g. coordinationmechanism) in terms of actions/percepts

no need to extend agents with special purpose primitives

exploiting a new type of agent modularity, based onexternalization [Ricci et al., 2009a]

142 / 165

Introduction EOP OOP Conclusion

Exploiting Synergy on A/O Integration

Normative deliberative agents

possibility to define mechanisms for agents to evolve withinan organisation/several organisationspossibility to define proper mechanisms for deliberating on theinternalisation/adoption/violation of norms

Reorganisation, adaptation of the organisation

possibility to define proper mechanisms fordiagnosing/evaluating/refining/defining organisations

“Deliberative” Organisations

possibility to define dedicated organisational strategies for theregulation/adaptation of the organisation behaviour(organisational agents)

143 / 165

Introduction EOP OOP Conclusion

Exploiting Synergy between the E/O Dimensions

Grounding the organisation infrastructure

implemented using environment abstractions... that agents perceive then as first-class entities of theirworld

Mapping

organisational state reified by the environment computationalstateorganisational actions/perceptions reified by actions/perceptson the environment stateorganisational functionalities encapsulated by suitablydesigned environment abstractions

Outcome

“the power is back to agents” [Hubner et al., 2009c]by perceiving and acting upon that environment, agents canreason and dynamically adapt the organisation infrastructure

144 / 165

Introduction EOP OOP Conclusion

E/O Synergy Example: Implementing Regimentation

Exploiting the environment role of enabler and mediator ofagent interaction

by providing actions and generating percepts

�! natural place where to embed and enforceorganisational rules and norms

a↵ecting action execution behaviour and percepts generation

Examplessimple: a game-board artifact in an artifact-basedenvironment

providing agents actions to make movesencapsulating and enforcing the rules of the game

complex: fully-fledged institutions

reified into properly programmed environments

145 / 165

Page 26: T2. Organization and Environment oriented programming

Introduction EOP OOP Conclusion

E/O Synergy Example: Implementing Constitutive Rules

Exploiting the environment to create, represent, and managedependencies and rules that are meaningful at theorganisational level

A main example: implementing constitutiverules [Searle, 1997]

events occurring in concrete environments conveyed as socialand institutional eventstypically represented in the form X counts as Y in Can example: reaching the environment state S counts asachieving the organisational goal G

The integration E/O allows for naturally design andimplementation of these kinds of rules

without adding any further concepts wrt the ones belongingto the E/O dimensions

146 / 165

Introduction EOP OOP Conclusion

A proposal: JaCaMo

Artifact

Operation Agent

Workspace

Work Environment

Manual

has

use

generateupdate

createdispose

link

consult

joinquit

Belief

Goal

Plan

External Action Internal Action

MissionRole

GroupSocial Scheme

createdelete

adoptleave

createdelete

commit leave

perceive

Trigger eventObservable Property

Norm

Goal

Action

Observable Event

Agentdimension

Environmentdimension

Organisationdimension

agent's actionscompositionassociationdependency concept mapping

dimension border

Lege

nd

147 / 165

Introduction EOP OOP Conclusion

Ongoing and Related Research

Unifying agents, environments and organisation perspectives

Volcano platform [Ricordel and Demazeau, 2002]MASK platform [Occello et al., 2004]MASQ [Stratulat et al., 2009], extending AGRE andAGREENEmbodied organisations [Piunti, 2010]Situated E-Institutions [Campos et al., 2009]

Normative programming andinfrastructures [Hubner et al., 2009a,Tinnemeier et al., 2009, Dastani et al., 2009b]

148 / 165

Page 27: T2. Organization and Environment oriented programming

References[Behrens et al., 2010] Behrens, T., Bordini, R., Braubach, L., Dastani, M.,

Dix, J., Hindriks, K., Hbner, J., and Pokahr, A. (2010). An interface

for agent-environment interaction. In In Proceedings of InternationalWorkshop on Programming Multi-Agent Systems (ProMAS-8).

[Bernoux, 1985] Bernoux, P. (1985). La sociologie des organisations.Seuil, 3eme edition.

[Bordini et al., 2007] Bordini, R., Hubner, J., and Wooldridge, M. (2007).

Programming Multi-Agent Systems in AgentSpeak Using Jason. Wiley-

Interscience.

[Bromuri and Stathis, 2008] Bromuri, S. and Stathis, K. (2008). Situating

Cognitive Agents in GOLEM. In Weyns, D., Brueckner, S., and De-

mazeau, Y., editors, Engineering Environment-Mediated Multi-AgentSystems, volume 5049 of LNCS, pages 115–134. Springer Berlin / Hei-

delberg.

[Campos et al., 2009] Campos, J., Lopez-Sanchez, M., Rodriguez-Aguilar,

J. A., and Esteva, M. (2009). Formalising situatedness and adaptation

in electronic institutions. In Coordination, Organizations, Institutionsand Norms in Agent Systems IV, volume 5428/2009 of LNCS. SpringerBerlin / Heidelberg.

[Carabelea, 2007] Carabelea, C. (2007). Reasoning about autonomy inopen multi-agent systems - an approach based on the social power the-ory. in french, ENS Mines Saint-Etienne.

[Dastani, 2008] Dastani, M. (2008). 2APL: a practical agent programming

language. Autonomous Agent and Multi-Agent Systems, 16(3):214–248.

[Dastani et al., 2009] Dastani, M., Tinnemeier, N., and Meyer, J.-J. C.

(2009). A programming language for normative multi-agent systems.

In Multi-Agent Systems: Semantics and Dynamics of OrganizationalModels. IGI-Global.

[Dignum and Aldewereld, 2010] Dignum, V. and Aldewereld, H. (2010).

Operetta: Organization-oriented development environment. In Proceed-ings of LADS @ MALLOW 2010, pages 14–20.

[Esteva et al., 2001] Esteva, M., Rodriguez-Aguiar, J. A., Sierra, C., Gar-

cia, P., and Arcos, J. L. (2001). On the formal specification of elec-

tronic institutions. In Dignum, F. and Sierra, C., editors, Proceedingsof the Agent-mediated Electronic Commerce, LNAI 1191, pages 126–

147, Berlin. Springer.

[Esteva et al., 2004] Esteva, M., Rodrıguez-Aguilar, J. A., Rosell, B., and

L., J. (2004). AMELI: An agent-based middleware for electronic insti-

tutions. In Jennings, N. R., Sierra, C., Sonenberg, L., and Tambe, M.,

editors, Proc. of the 3rd Int. Joint Conf. on Autonomous Agents andMulti-Agent Systems (AAMAS’04), pages 236–243, New York, USA.

ACM.

[Ferber and Gutknecht, 1998] Ferber, J. and Gutknecht, O. (1998). A

meta-model for the analysis and design of organizations in multi-agents

systems. In Demazeau, Y., editor, Proceedings of the 3rd Interna-tional Conference on Multi-Agent Systems (ICMAS’98), pages 128–

135. IEEE Press.

[Gasser, 2001] Gasser, L. (2001). Organizations in multi-agent systems.

In Pre-Proceeding of the 10th European Worshop on Modeling Au-tonomous Agents in a Multi-Agent World (MAAMAW’2001), Annecy.

[Gateau et al., 2005] Gateau, B., Boissier, O., Khadraoui, D., and Dubois,

E. (2005). Moiseinst: An organizational model for specifying rights and

duties of autonomous agents. In Third European Workshop on Multi-Agent Systems (EUMAS 2005), pages 484–485, Brussels Belgium.

[Gutknecht and Ferber, 2000a] Gutknecht, O. and Ferber, J. (2000a). The

MADKIT agent platform architecture. In Agents Workshop on Infras-tructure for Multi-Agent Systems, pages 48–55.

[Gutknecht and Ferber, 2000b] Gutknecht, O. and Ferber, J. (2000b). The

MadKit agent platform architecture. In Agents Workshop on Infras-tructure for Multi-Agent Systems, pages 48–55.

[Hannoun et al., 2000] Hannoun, M., Boissier, O., Sichman, J. S., and

Sayettat, C. (2000). Moise: An organizational model for multi-agent

systems. In Monard, M. C. and Sichman, J. S., editors, Proceedings ofthe International Joint Conference, 7th Ibero-American Conference onAI, 15th Brazilian Symposium on AI (IBERAMIA/SBIA’2000), At-ibaia, SP, Brazil, November 2000, LNAI 1952, pages 152–161, Berlin.

Springer.

[Hubner et al., 2009a] Hubner, J. F., Boissier, O., and Bordini, R. H.

(2009a). Normative programming for organisation management infras-

tructures. In MALLOW Workshop on Coordination, Organization,Institutions and Norms in Agent Systems in Online Communities(COIN-MALLOW 2009).

[Hubner et al., 2009b] Hubner, J. F., Boissier, O., Kitio, R., and Ricci, A.

(2009b). Instrumenting multi-agent organisations with organisational

artifacts and agents: “Giving the organisational power back to the

agents”. Autonomous Agents and Multi-Agent Systems. DOI-URL:

http://dx.doi.org/10.1007/s10458-009-9084-y.

[Hubner et al., 2009c] Hubner, J. F., Boissier, O., Kitio, R., and Ricci, A.

(2009c). Instrumenting Multi-Agent Organisations with Organisational

Artifacts and Agents. Journal of Autonomous Agents and Multi-AgentSystems.

[Hubner et al., 2002] Hubner, J. F., Sichman, J. S., and Boissier, O.

(2002). A model for the structural, functional, and deontic specifica-

tion of organizations in multiagent systems. In Bittencourt, G. and Ra-

malho, G. L., editors, Proceedings of the 16th Brazilian Symposium onArtificial Intelligence (SBIA’02), volume 2507 of LNAI, pages 118–128,

Berlin. Springer.

[Hubner et al., 2006] Hubner, J. F., Sichman, J. S., and Boissier, O.

(2006). S-MOISE+: A middleware for developing organised multi-agent

systems. In Boissier, O., Dignum, V., Matson, E., and Sichman, J. S., ed-

itors, Coordination, Organizations, Institutions, and Norms in Multi-Agent Systems, volume 3913 of LNCS, pages 64–78. Springer.

[Hubner et al., 2007] Hubner, J. F., Sichman, J. S., and Boissier, O.

(2007). Developing Organised Multi-Agent Systems Using the MOISE+

Model: Programming Issues at the System and Agent Levels. Agent-Oriented Software Engineering, 1(3/4):370–395.

[Malone, 1999] Malone, T. W. (1999). Tools for inventing organizations:

Toward a handbook of organizational process. Management Science,45(3):425–443.

[Molesini et al., 2005] Molesini, A., Omicini, A., Denti, E., and Ricci, A.

(2005). SODA: A roadmap to artefacts. In Dikenelli, O., Gleizes, M.-

P., and Ricci, A., editors, 6th International Workshop “EngineeringSocieties in the Agents World” (ESAW’05), pages 239–252, Kusadası,

Aydın, Turkey. Ege University.

[Morin, 1977] Morin, E. (1977). La methode (1) : la nature de la nature.Points Seuil.

[Occello et al., 2004] Occello, M., Baeijs, C., Demazeau, Y., and Koning,

J.-L. (2004). MASK: An AEIO toolbox to design and build multi-agent

systems. In et al., C., editor, Knowledge Engineering and Agent Tech-nology, IOS Series on Frontiers in AI and Applications. IOS press, Am-

sterdam.

[Okuyama et al., 2008] Okuyama, F. Y., Bordini, R. H., and

da Rocha Costa, A. C. (2008). A distributed normative infras-

tructure for situated multi-agent organisations. In Baldoni, M., Son,

T. C., van Riemsdijk, M. B., and Winiko�, M., editors, DALT, volume

5397 of Lecture Notes in Computer Science, pages 29–46. Springer.

[Oliva et al., 2010] Oliva, E., McBurney, P., Omicini, A., and Viroli, M.

(2010). Argumentation and artifacts for negotiation support. Interna-tional Journal of Artificial Intelligence, 4(S10):90–117. Special Issue

on Negotiation and Argumentation in Artificial Intelligence.

[Omicini et al., 2008] Omicini, A., Ricci, A., and Viroli, M. (2008). Ar-

tifacts in the A&A meta-model for multi-agent systems. AutonomousAgents and Multi-Agent Systems, 17(3):432–456.

[Omicini et al., 2004] Omicini, A., Ricci, A., Viroli, M., Castelfranchi, C.,

and Tummolini, L. (2004). Coordination artifacts: Environment-based

coordination for intelligent agents. In Proc. of the 3rd Int. Joint Conf.on Autonomous Agents and Multi-Agent Systems (AAMAS’04), vol-

ume 1, pages 286–293, New York, USA. ACM.

[Ossowski, 1999] Ossowski, S. (1999). Co-ordination in Artificial AgentSocieties: Social Structures and Its Implications for AutonomousProblem-Solving Agents, volume 1535 of LNAI. Springer.

[Piunti, 2010] Piunti, M. (2010). Embodied organizations: a unifying per-

spective in programming agents, organizations and environments. PhD

thesis.

[Piunti and Ricci, 2009] Piunti, M. and Ricci, A. (2009). Cognitive ar-

tifacts for intelligent agents in mas: Exploiting relevant information

residing in environments. In Knowledge Representation for Agentsand Multi-Agent Systems (KRAMAS 2008), volume 5605 of LNAI.Springer.

1

Page 28: T2. Organization and Environment oriented programming

[Piunti et al., 2009a] Piunti, M., Ricci, A., Boissier, O., and Hubner, J.(2009a). Embodying organisations in multi-agent work environments. InIEEE/WIC/ACM International Conference on Web Intelligence andIntelligent Agent Technology (WI-IAT 2009), Milan, Italy.

[Piunti et al., 2009b] Piunti, M., Ricci, A., Boissier, O., and Hubner, J. F.(2009b). Embodied organisations in mas environments. In Braubach,L., van der Hoek, W., Petta, P., and Pokahr, A., editors, Proceedings of7th German conference on Multi-Agent System Technologies (MATES09), Hamburg, Germany, September 9-11, volume 5774 of LNCS, pages115–127. Springer.

[Piunti et al., 2008] Piunti, M., Ricci, A., Braubach, L., and Pokahr,A. (2008). Goal-directed interactions in artifact-based mas: Jadexagents playing in CARTAGO environments. In Proc. of the 2008IEEE/WIC/ACM Int. Conf. on Web Intelligence and IntelligentAgent Technology (IAT’08), volume 2. IEEE Computer Society.

[Platon et al., 2007] Platon, E., Mamei, M., Sabouret, N., Honiden, S.,and Parunak, H. V. (2007). Mechanisms for environments in multi-agentsystems: Survey and opportunities. Autonomous Agents and Multi-Agent Systems, 14(1):31–47.

[Pynadath and Tambe, 2003] Pynadath, D. V. and Tambe, M. (2003). Anautomated teamwork infrastructure for heterogeneous software agentsand humans. Autonomous Agents and Multi-Agent Systems, 7(1-2):71–100.

[Ricci et al., 2010a] Ricci, A., Denti, E., and Piunti, M. (2010a). A plat-form for developing SOA/WS applications as open and heterogeneousmulti-agent systems. Multiagent and Grid Systems International Jour-nal (MAGS), Special Issue about “Agents, Web Services and Ontolo-gies: Integrated Methodologies”. To Appear.

[Ricci et al., 2007a] Ricci, A., Omicini, A., Viroli, M., Gardelli, L., andOliva, E. (2007a). Cognitive stigmergy: Towards a framework basedon agents and artifacts. In Weyns, D., Parunak, H. V. D., and Michel,F., editors, Environments for MultiAgent Systems III, volume 4389 ofLNAI, pages 124–140. Springer.

[Ricci et al., 2008] Ricci, A., Piunti, M., Acay, L. D., Bordini, R., Hubner,J., and Dastani, M. (2008). Integrating artifact-based environmentswith heterogeneous agent-programming platforms. In Proceedings of7th International Conference on Agents and Multi Agents Systems(AAMAS08).

[Ricci et al., 2009a] Ricci, A., Piunti, M., and Viroli, M. (2009a). Ex-ternalisation and internalization: A new perspective on agent modu-larisation in multi-agent system programming. In Dastani, M., Fallah-Seghrouchni, A. E., Leite, J., and Torroni, P., editors, LADS, volume6039 of Lecture Notes in Computer Science, pages 35–54. Springer.

[Ricci et al., 2010b] Ricci, A., Piunti, M., and Viroli, M. (2010b). Environ-ment programming in multi-agent systems – an artifact-based perspec-tive. Autonomous Agents and Multi-Agent Systems. Published Onlinewith ISSN 1573-7454 (will appear with ISSN 1387-2532).

[Ricci et al., 2009b] Ricci, A., Piunti, M., Viroli, M., and Omicini, A.(2009b). Environment programming in CArtAgO. In Bordini, R. H., Das-tani, M., Dix, J., and El Fallah-Seghrouchni, A., editors, Multi-AgentProgramming: Languages, Platforms and Applications, Vol. 2, pages259–288. Springer Berlin / Heidelberg.

[Ricci et al., 2009c] Ricci, A., Piunti, M., Viroli, M., and Omicini, A.(2009c). Environment programming in CArtAgO. In Multi-Agent Pro-gramming: Languages,Platforms and Applications,Vol.2. Springer.

[Ricci et al., 2010c] Ricci, A., Santi, A., and Piunti, M. (2010c). Actionand perception in multi-agent programming languages: From exogenousto endogenous environments. In In Proceedings of International Work-shop on Programming Multi-Agent Systems (ProMAS-8).

[Ricci et al., 2007b] Ricci, A., Viroli, M., and Omicini, A. (2007b). TheA&A programming model & technology for developing agent environ-ments in MAS. In Dastani, M., El Fallah Seghrouchni, A., Ricci, A.,and Winiko�, M., editors, Programming Multi-Agent Systems, volume4908 of LNAI, pages 91–109. Springer Berlin / Heidelberg.

[Ricci et al., 2007c] Ricci, A., Viroli, M., and Omicini, A. (2007c).CArtAgO: A framework for prototyping artifact-based environments inMAS. In Weyns, D., Parunak, H. V. D., and Michel, F., editors, En-vironments for MultiAgent Systems III, volume 4389 of LNAI, pages67–86. Springer. 3rd International Workshop (E4MAS 2006), Hakodate,Japan, 8 May 2006. Selected Revised and Invited Papers.

[Ricordel and Demazeau, 2002] Ricordel, P. and Demazeau, Y. (2002).VOLCANO: a vowels-oriented multi-agent platform. In Dunin-Kepliczand Nawarecki, editors, Proceedings of the International Conferenceof Central Eastern Europe on Multi-Agent Systems (CEEMAS’01),volume 2296 of LNAI, pages 252–262. Springer Verlag.

[Rocha Costa and Dimuro, 2009] Rocha Costa, A. C. d. and Dimuro, G.(2009). A minimal dynamical organization model. In Dignum, V., edi-tor, Multi-Agent Systems: Semantics and Dynamics of OrganizationalModels, chapter XVII, pages 419–445. IGI Global.

[Russell and Norvig, 2003] Russell, S. and Norvig, P. (2003). ArtificialIntelligence, A Modern Approach (2nd ed.). Prentice Hall.

[Santi et al., 2011] Santi, A., Guidi, M., and Ricci, A. (2011). Jaca-android: An agent-based platform for building smart mobile applica-tions. In Languages, Methodologies and Development Tools for Multi-agent systems, volume 6822 of LNAI. Springer Verlag.

[Searle, 1997] Searle, J. R. (1997). The Construction of Social Reality.Free Press.

[Shoham, 1993] Shoham, Y. (1993). Agent-oriented programming. Artif.Intell., 60(1):51–92.

[Stratulat et al., 2009] Stratulat, T., Ferber, J., and Tranier, J. (2009).MASQ: towards an integral approach to interaction. In AAMAS (2),pages 813–820.

[Tambe, 1997] Tambe, M. (1997). Towards flexible teamwork. Journal ofArtificial Intelligence Reseearch, 7:83–124.

[Tinnemeier et al., 2009] Tinnemeier, N., Dastani, M., Meyer, J.-J., andvan der Torre, L. (2009). Programming normative artifacts with declar-ative obligations and prohibitions. In IEEE/WIC/ACM InternationalJoint Conference on Web Intelligence and Intelligent Agent Technol-ogy (WI-IAT 2009).

[Viroli et al., 2007] Viroli, M., Holvoet, T., Ricci, A., Schelfthout, K., andZambonelli, F. (2007). Infrastructures for the environment of multiagentsystems. Autonomous Agents and Multi-Agent Systems, 14(1):49–60.

[Weyns and Holvoet, 2004] Weyns, D. and Holvoet, T. (2004). A formalmodel for situated multi-agent systems. Fundamenta Informaticae,63(2-3):125–158.

[Weyns and Holvoet, 2007] Weyns, D. and Holvoet, T. (2007). A referencearchitecture for situated multiagent systems. In Environments for Mul-tiagent Systems III, volume 4389 of LNCS, pages 1–40. Springer Berlin/ Heidelberg.

[Weyns et al., 2007] Weyns, D., Omicini, A., and Odell, J. J. (2007). Envi-ronment as a first-class abstraction in multi-agent systems. AutonomousAgents and Multi-Agent Systems, 14(1):5–30.

[Weyns and Parunak, 2007] Weyns, D. and Parunak, H. V. D., editors(2007). Special Issue on Environments for Multi-Agent Systems, vol-ume 14 (1) of Autonomous Agents and Multi-Agent Systems. SpringerNetherlands.

[Weyns et al., 2005] Weyns, D., Parunak, H. V. D., Michel, F., Holvoet,T., and Ferber, J. (2005). Environments for multiagent systems: State-of-the-art and research challenges. In Weyns, D., Parunak, H. V. D.,Michel, F., Holvoet, T., and Ferber, J., editors, Environment for Multi-Agent Systems, volume 3374, pages 1–47. Springer Berlin / Heidelberg.

[Wooldridge, 2002] Wooldridge, M. (2002). An Introduction to Multi-Agent Systems. John Wiley & Sons, Ltd.

2