Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Andrea Santi Ph.D Defence

No description
by

Andrea Santi

on 12 April 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Andrea Santi Ph.D Defence

Engineering Agent-Oriented
Technologies and Programming Languages for Computer Programming and Software Development Introduction Context Objectives
& Contribution Evolution of Hardware Architectures Internet Evolution
&
Pervasive Connection Availability Single core CPUs Multi-core CPUs (2, 4, ..) Many-core CPUs Smart mobile devices Concurrency & distribution
Context-dependent interactions
Management of asynchronous events ...
... and their integration with autonomous behaviors
... "The Free Lunch is over. Now welcome to the Jungle."
[Sutter & Larus 2005, Sutter 2012] These evolutions are having a fundamental impact in software development New issues to tackle in mainstream programming "The free lunch is over.
Now welcome to the Jungle."

[Sutter & Larus 2005, Sutter 2012] Pervasive Affecting how people think & engineer programs everyday It is not only about mechanisms ... to improve performances, to be reactive, etc. It is (also) about conceptual modeling, design & abstractions Need for a paradigm shift in software development Looking for proper abstractions that ... Actor-oriented and Object-Oriented Concurrent Programming (OOCP) approaches are becoming more and more mainstream Roots back into the '70s '80s by Hewitt, Aga, Yonezawa Soon pervasively used for every-day programming Main examples Scala actors & Akka [Haller & Odersky 2012, Gupta 2012]
Erlang [Armstrong 2010]
DART [Bracha 2011] , HTML Web Worker [W3C 2010]
... [msg_a] [create] [msg_b] Abstract view of an actor system [Karmani & Aga 2011] "Although the simplicity of the actor model is appealing, these problems with message order, message delivery, and coordination between sequences of concurrent actions also help us appreciate the programming value of more complex concurrent languages."

[Mitchel 2002, Concepts of Programming Languages] Keeping old paradigms, languages & way of thinking, adding specific mechanisms/extensions Hiding concurrency, decentralization etc. Mainstream programming languages + "small" extensions/libraries QPar [Microsoft 2012]
C++ & Fortran Intel Compilers [Intel 2011]
... "help building concurrent programs just as object-oriented abstractions help build large component-based programs"
[Sutter & Larus 2005] Avoiding (somehow) to embrace the change Behavior governed by the actor event loop Actors are rooted on the reactivity principle Objective: devising a prog. paradigm conceptually extending actors & OOCP with a set of high-level prog. abstractions inspired to agents and Multi-Agent Systems (MASs) Method: the simpAL project Identifying paradigm's essential concepts & abstractions Agent-Oriented Programming: the Current Situation The idea of Agent-Oriented Programming is not new Main current acceptations are (D)AI contexts The first paper about AOP is dated 1993 [Shoham 1993].. Emphasis on theoretical issues No focus on principles of general-purpose computer programming No significant impacts on mainstream research in prog. languages & software development In particular all the work on These works have been the fundamental background & starting point for our work A second macro-group, concerning the construction of our answer to the "Free Lunch is over" call Agent models & architectures Agent-oriented programming models The JaCa platform [Ricci & Santi 2011] In detail... JaCa
&
JaCaMo Towards simpAL JaCa & JaCaMo: Weaknesses & Limitations No explicit notion of type for the main progr. abstractions Still missing important features of general-purpose programming For all the programming dimensions => No static error detection Lack of a seamless integration with object/functional-oriented layer Support for polymorphism? Currently based on low-level integration mechanisms Conclusion
&
Future Work Increasing the level of abstraction to ease modeling / design / programming Integration of different interaction models Human-inspired abstractions Tasks as first-class concept Integrating autonomous + reactive behaviors Agents vs. Actors => shifting from reactivity to pro-activity From an event loop to control loop Direct + indirect form of communications Background Metaphor: an Abstract Representation Rooted on human-inspired conceptual models Agents & Artifacts (A&A) meta-model [Omicini et al. 2008] Belief-Desire Intention (BDI) Agent Model [Rao & Georgeff 1995] Autonomous task-oriented & event-driven Comm. with other agents via speech acts BDI-inspired computational model The simpAL
Programming Model Use & observe the shared environment write cake
decoration supervise cake creation tell about an urgent call use the clock update the scheduler use the archive to search delegate a new task to do Provide functionalities via operations Tools created, shared & used by agents while doing their tasks Non-autonomous entities Expose state via observable properties Possibly distributed in different network nodes Defining the topology of the environment Logical containers of agents & artifacts An Object-Oriented Layer is also present Java model/language adopted in simpAL For data structures & related (transformational) computations Data used in agents & artifacts are represented in terms of Object-Oriented abstractions Tasks as first-class state-full entities Input & output parameters Task type definition Message exchanged: understands & talks-about Instantiated given a task type by a creator Assigned from an assigner to an assignee The assignee can complete or fail the task Task outcome observable by the assigner task FindFiles {
input-params {
content: Content
}
output-params {
fileList: List<File>
}
} task KeepTemperature {
input-params {
user-view: View
}
understands {
newThreshold: double
}
} simpAL agents are rooted on the proactivity principle Behavior governed by the agent control loop Plan's main elements Agent script = collection of plans & beliefs for playing a role Task type Plan body Context Complete control on ongoing activities Further Aspects Performance
Analysis Cloud & Mobile Computing E.g. automatic parallelization Direction I Direction II Actor model = unification of objects + concurrency Comeback of the Actor Model Overview of the Actor Model An Actor's Computational Model PickMsgFromMsgQueue() SelectHandler(msg) Execute(method) How to engineer
&
program these systems? Still missing foundational principles & features Is the reactivity principle enough? Computing is not only reacting to events How integrate autonomy and reactivity? How model active behaviors? Modularity & composition? Are asynch. interactions enough? Typing & error-checking? Extensibility & reusability => inheritance anomaly problem [Matsuoka&Yonezawa, 1993] Coordination? Complex form of communications? Long term task T Reactive behavior React to a react! message public class TestActor1 extends Actor {
int c=0;
@message
public void doTaskT() { send(self(), "doingTa"); }

@message
public void doingTa() { send(self(), "doingTb"); ta(); }

@message
public void doingTb() { send(self(), "doingTc"); tb(); }

@message
public void doingTc() { tc(); }

@message
public void react() { call(stdout, "println","react! " + c); }
...
} Articulated in: Ta, Tb, Tc sub-tasks Printing a message in stdout A classic bounded buffer Need for ad-hoc coordination protocols public class BoundedBuffer extends Actor {

private List<WaitingProducer> waitingProducers;
private List<WaitingProducerEntry> waitingConsumers;
...
public BoundedBuffer(Integer bufferSize) { ... }

@message
public void put(ActorName sender, Integer elem) {
if (isFull()){
/* Add prod to waitingProducers */
} else {
doPutInBuffer(elem);
send(sender, "ackPut");
if (!waitingConsumers.isEmpty()){
/* Awaken waiting cons */
send(waitingConsumers.poll(), "ackGet", doGetFromBuffer());
}}}

@message
public void get(ActorName sender) {
if(isEmpty()){
/* Add cons to waitingConsumers */
} else {
send(sender, "ackGet", doGetFromBuffer());
if (!waitingProducers.isEmpty()){
/* Awaken waiting prod */
WaitingProducerEntry entry = waitingProducers.poll();
doPutInBuffer(entry.getElement());
send(entry.getProducer(), "ackPut");
}}}

private void doPutInBuffer(Integer elem){ ... }
private Integer doGetFromBuffer(){ ... }
private boolean isFull(){ ... }
private boolean isEmpty(){ ... } public class TestActor0 extends Actor {
int c=0;
@message
public void doTaskT() {
ta(); tb(); tc();
}

@message
public void react() {
call(stdout, "println","react! " + c);
}

private void ta(){ c++; }
private void tb(){ c++; }
private void tc(){ c++; }
} Simple (but wrong) solution Correct solution Autonomous behavior Actor Model: Weaknesses & Limitation Mixing Autonomy & Reactivity Actor Model: Weaknesses
&
Limitations Agent-Oriented Programming (AOP) Engineering of the simpAL programming language & the ecosystem at its support Compiler Distributed runtime Integrated Development Environment (IDE) Many APLs and platforms developed [Bordini et al., 2005, 2006, 2009] The study & engineering of integrated agent-oriented technologies & frameworks for developing intelligent software systems A first macro-group about The JaCaMo framework [Boissier et al. 2013] Contributions 1/2 Contributions 2/2 Exploited & evaluated in several domains & research projects Programming approaches & development platforms for engineering MASs Key feature: synergistic & integrated programming models JaCa [Ricci & Santi 2011] JaCaMo [Boissier et al. 2013] CArtAgO: for programming softw. environments Jason: for programming BDI agents JaCa Moise: for programming organizations JaCa Synergistic programming approaches for MAS development are effective In general MAS programming become easier ... ... and finally programs more compact & terse => exploiting inter-dimensions links defined at the programming level However, shifting from (D)AI contexts to general-purpose computer programming (as expected) several weaknesses and limitations arise ... JaCa & JaCaMo: Summing Up JaCa & JaCaMo + => prints always react! 3 => prints react! 0/1/2/3 + Modularity? Extensibility? Reuse? simpAL: Key Ideas in a Slide Agents operations:
-setTime
-setAlarm obs props:
-time
-alarm operations:
-addTask
-delTask obs props:
-workflow operations:
-addNote
-... obs props:
-noteList
-drawings Workspaces The Data Model Overview of
simpAL Tasks Defining what have to be executed Beliefs Plans Agent Scripts Defining how to execute a task: what actions to do and when Variable-like typed information items Plans & beliefs for playing a role Agents in simpAL: Concepts Roles Defining agents' type Task Model & Definition Set of tasks an agent must be able do role Thermostat {

task AchieveTemperature { ... }

task KeepTemperature { ... }

} Grouping Related Tasks: Roles Roles define a notion of type for agents Two main outcomes [Ricci & Santi 2012] Example of Thermostat role Error checking Principle of substitutability Agent Computational Model Inspired by the BDI model Conceptual extension of the actor event loop [Ricci & Santi 2012] Program Agents' Behavior: Scripts & Plans Plans are modules of procedural knowledge Design goal: seamless integration of autonomous + reactive behaviors Can describe any combination of sequence of actions + reactions = actions to be taken if/when/every-time some event/condition hold Event: change of a belief (about env, about actions,...) Context: condition over the belief base Action: internal + external (artifact operations) Syntactic sugar to code frequent patterns (e.g. a1; a2 => sequence) Possibly organized in nested action rule blocks Event : Context => Action [label] The Plan Model agent-script Therm1 implements Thermometer {

plan-for KeepTemperature context: !test { ... }
plan-for AchieveTemperature context: test { ... }
plan-for AchieveTemperature { ... }

} Set of action rules specifying when to do what agent-script TestScript implements RoleR {
c: int = 0;

plan-for TaskT {
#completed-when: is-done tc

do-task new-task Ta();
do-task new-task Tb();
do-task new-task Tc() #act: tc

when told this-task.react => {
#using: console@main
println(msg: "react! "+c)
}
}

plan-for Ta { c = c + 1 }
plan-for Tb { c = c + 1 }
plan-for Tc { c = c + 1 }
} Mixing Autonomy & Reactivity in simpAL role RoleR {

task TaskT {
input-params {
react: java.lang.String;
}

task Ta { }
task Tb { }
task Tc { }

} Programming the Artifacts in simpAL Programming Artifacts Usage interface
=
artifact type Artifact template
=
concrete impl. usage-interface CounterUI {
obs-prop count;
operation inc();
} artifact Counter implements CounterUI {
init (startVal: int){
count = startVal;
}
operation inc() { count++; }
} Computational model inspired by monitors Programming the Agents in simpAL Exploiting Tasks as First Class Entities agent-script DummyScript implements DummyRole {

plan-for MyTask{
otherTask: MyOtherTask = new-task(...);
do-task otherTask;
...
when changed obsProp => {
if (! is-done otherTask;) {
drop-task otherTask
} else {
/* do something else */
}
}

} agent-script DummyScript2 implements DummyRole2 {

plan-for MyTask2{
taskToDelegate: MyOtherTask2 = new-task(...);
assign-task taskToDelegate to: peer;
...
when is-done taskToDelegate => {
/* now I can go on doing something else... */
}
}

} One operation in execution per time Operation execution is transactional agent-script CounterUser implements CounterUserUI {

plan-for IncUntilStopped {
#using: counter, view

{
#to-be-repeated
inc() on counter
}

when stopPressed on view => {
#using: console@main
println(msg: "stop pressed!")
}
} Event-driven Programming Without Inversion of Control artifact BoundedBuffer implements BufferUI {

elems: Item[]; numMaxElems: int; first: int; last: int;

init (maxElems: int) {
numMaxElems = maxElems; first = 0; last = 0; nElems = 0;
elems = new-obj Item[numMaxElems];
}

operation put (item: Item) {
await nElems < numMaxElems;
nElems = nElems + 1;
elems[last] = item;
last = (last + 1) % numMaxElems;
}

operation get (item: Item #out) {
await nElems > 0;
nElems = nElems - 1;
item = elems[first];
first = (first + 1) % numMaxElems;
}
} Example of Coordination Artifact Coordination Among Actors A classic bounded buffer Agents can simply use the artifact Encapsulation of the coord. strategy Based on the await construct usage-interface BufferUI {

obs-prop nElems: int;

operation put (item: Item);

operation get (item: Item #out);
} role CounterUser {

task IncUntilStopped {
input-params {
counter: CounterUI;
view: GUI;
}

} Behavior encapsulation No listeners/callbacks => no inversion of control Support for Distributed Programming Organization model & instance to define Distributed Runtime Infrastructure Integrated Development Environment Application topology Static set of agents & artifacts for each workspace Deploy configurations specified separately Programming Distributed Multi-Agent Systems in simpAL [Santi & Ricci 2012] Typing Support: More Details Error checking Principle of substituability A basic type notion also for the overall app = organization model For both agents & artifacts Agent side: scripts VS roles, correct use of artifacts, ... Artifact side: template VS usage interfaces, referencing existing obs props, ... Overview & Objectives Objective: investigate the overhead of the agent control architecture Two different test scenarios Test machine Comparison with reference actor & agent-oriented technologies Jason [Bordini & Hubner 2007] Erlang [Armstrong 2010] ActorFoundry [Karmani & Agha 2009] Thread-ring [Computer Language Benchmark Game] An ad-hoc test about integrating active + reactive behaviors [Ricci & Santi 2012] Intel Core 2 Duo P8400 2.26GHZ (dual core), 3GiB RAM Thread-Ring Test Peer1 Peer2 Peer3 ... 503 peers connected in a ring Passing a token for N times N = 10K, 100K, 1M, 10M Ad-hoc Test [Ricci & Santi 2012] Extension of the abstract example integrating autonomy & reactivity Task T & react! message repeated for N times N = 10K, 100K, 1M, 10M Ongoing & Future Work Programming model Formalizations Evaluation & Testing Introducing a cooperative notion of task Introducing & extending important features: sub-typing, inheritance polymorphism... Language operational semantics Type system Implementation & tools Applying in practice the language, besides first experiments Performing new benchmarks Compiler, runtime, IDE ???TODO??? Autonomy + reactivity in a single module Organization side: org instance VS org model Summing Up Tutor & co-tutor : Antonio Natali & Alessandro Ricci External reviewers Rem Collier, University College Dublin (UCD) Amal El Fallah Seghrouchni, University Pierre and Marie Curie – Paris 6 (LIP6 – CNRS) Dissertation title: Engineering Agent-Oriented Technologies and Programming Languages for Computer Programming and Software Development PhD in Electronics, Computer Science and Telecommunications XXV Cycle - Doctor Europaeus Research collaborations University College Dublin, Dublin - Irelan (2012) Ecole Nationale Supérieure des Mines, St-Etienne - France (2011) Candidate: Andrea Santi Define how achieve a task AOP as a possible answer to the "free lunch is over" call ...
Full transcript