a conceptual framework for behavioural adaptation @ leicester 2011

Alberto Lluch Lafuente, Roberto Bruni, Andrea Corradini,Fabio Gadducci, Ugo Montanari, GianLuigi Ferrari, Andrea VandinLeicester, September 21st, 2011

A conceptual frameworkfor behavioural adaptation

[email protected]

1A framework for adaptation

2Reflective rule-based programming

3Context-oriented programming

0ASCENS in a nutshell

In this talk we present the framework and two paradigms for modelling and programming adaptive systems, discussing how they fit into the framework:

1) Rewriting systems with meta-programming facilities (reflection in this case).

2) Context-Oriented Programming.


A framework for adaptation

Reflective rule-based programming

Context-oriented programming





autonomicservicecomponentensembles

emergent behaviour, swarms, ...

( = )

what is ascens ?

European project on

...open-ended, highly parallel, massively distributed systems...

...made of self-awaress, self-adaptive, self-expressive, self-*, autonomic components.- ascens-ist.eu

ensembles

Robot Swarms

E-vehicles

...build ensembles in a way that combines software engineering,formal methods and autonomic, adaptive, self-aware systems.

- ascens-ist.eu

goal



Reflective Rule-based Programming

Context-Oriented Programming




our sources of inspiration

IBM's AC/MAPE-K

MAUDE

CONTEXT-ORIENTED PROGRAMMING

EU Projects (S-CUBE, CASCADAS, ALLOW,...)

SCEL

(META)KLAIM

SELF-ADAPTATION PATTERNS

Architecture-Based Approach to Self-AdaptiveSoftware (Medvidovic-Rosenblum)

Our framework is the result of discussions, brainstorms, past ASCENS meetings, readings and all that (within WP2).

Among the sources of inspiration we mention: IBM's AC/MAPE-K, Projects around adaptation (like S-CUBE, CASCADAS, ALLOW), programming paradigms (like context-oriented), foundational models (like rewriting logic), etc.

And of course ASCENS stuff like SCEL (and its predecessors KLAIM, META-KLAIM), WP4 framework for adaptation patterns, Matthias thoughts on adaptation, etc.

3 ingredients of AC

CComponent-based approach

SSeparation of concerns

RReflective computation

Our framework is the result of discussions, brainstorms, past ASCENS meetings, readings and all that (within WP2).

Among the sources of inspiration we mention: IBM's AC/MAPE-K, Projects around adaptation (like S-CUBE, CASCADAS, ALLOW), programming paradigms (like context-oriented), foundational models (like rewriting logic), etc.

And of course ASCENS stuff like SCEL (and its predecessors KLAIM, META-KLAIM), WP4 framework for adaptation patterns, Matthias thoughts on adaptation, etc.

The act of modifying behaviour...

- WP4, (c.f. framework for self-adaptation and self-expression in ASCENS)

adaptation

One of our starting points was W4's definition of (behavioural) adaptation.

adaptable

Something whose behaviourcan be modified

- WP2

From the definition of adaption we derive the definition of adaptability (the ability of being adaptable).

adaptable program =

CONTROLDATA

control+ data

Into a Adaptable Program = Control + Control Data + Data paradigm, where part of the control logic is exhibited as data (the control data) that can be modified (e.g. by a manager).

Of course any ordinary computational model or language can be used just by considering that part of the data governs the cotrol (e.g. flag variables). However a separation of concerns is fundamental to facilitate e.g. specification, analysis, development, etc.

As an analogy think about the difference between OO languages (C++) and programming in OO-style in ordinary languages (e.g. C).

adaptable program =

CONTROLDATA

CONTROLDATA

MANAGER

control+ data+ control data

SCR

Into a Adaptable Program = Control + Control Data + Data paradigm, where part of the control logic is exhibited as data (the control data) that can be modified (e.g. by a manager).

Of course any ordinary computational model or language can be used just by considering that part of the data governs the cotrol (e.g. flag variables). However a separation of concerns is fundamental to facilitate e.g. specification, analysis, development, etc.

As an analogy think about the difference between OO languages (C++) and programming in OO-style in ordinary languages (e.g. C).

which control data?

CONTROLCONTROLDATA

rules?contexts?interactions?policies?etc.

What is control data?

This depends on the computational model or language.

For instance, some natural choices might be

rules in rewrite systemscontexts in contex-oriented paradigmspolicies in policy-driven approaches/SCEL?etc.

smells like control data...

Models: HO -calculus, MetaKlaim, HO Petri nets, Rewriting Logic, HO Graph Grammars, Logic Programming, etc.

Languages: reflection,aspects, monads,effects, contexts, etc.

etc.

Many foundational models have variants with meta/higher-order/reflective features where control data and adaptation are more naturally represented than in the core models.

We mention some examples (connected to the expertise of WP2).

desiderata 1: compositional

C0CD0

C1

CD1

...

Now, we have two main desiderata for the adaptation framework.

The first one is that it should be hierarchical in the sense that managers should be adaptable themselves to allow building adaptation towers.

Adaptation of the adaptation is what WP4 calls self-expression (if I understood well).

internal feedback loops

CONTROLCONTROLDATA

INTERNALMANAGER

This seems conformant with WP4's control loop patterns like the external feedback loop pattern.

external feedback loops

CONTROLCD

EXTERNALCONTROLLERCD

...or the internal feedback loop pattern

(un)desiderata?

CCD

C

CD

CCD

reciprocal management?

self management?(no separation of concerns)

Now, we have two main desiderata for the adaptation framework.

The first one is that it should be hierarchical in the sense that managers should be adaptable themselves to allow building adaptation towers.

Adaptation of the adaptation is what WP4 calls self-expression (if I understood well).

desiderata 2: MAPE-K compliance

MonitorExecute

Knowledge

Analyze

Plan

AUTONOMIC MANAGER

MANAGED ELEMENT

Control Data

Control Data

Control

The second desiderata is that the framework should be flexible enough to capture/follow the MAPE-K scheme.

Why? Since it is widely accepted as a scheme for autonomic computing and we have at the moment no argument against it.

MAPE-K towers

ME

K

A

P

MANAGED ELEMENT

CD

ME

K

A

P

CD

ME

K

A

P

CD

CD






Context-Oriented Programming




reflection tower

A rewriting framework like rewriting logic enjoys what is called reflection tower.

At the ground level, a rewrite theory (e.g. software module) let us infer a computation step from a term (e.g. program state) t into t'.

A universal theory U let us infer the computation at the meta-level, where theories and terms are meta-represented as terms.

The process can be repeated again and again as U itself is a rewrite theory.

reflection tower





reflection tower





reflection tower





adaptation tower

This suggests the following adaptation tower.

At each level, theories are composed by some immutable part and some part subject to modification, i.e. the control data.

A natural choice for control data are subsets of rules.

At the level 1, computations steps can modify both the term t and the control data of level 0.

Idem for higher levels.

adaptation tower






adaptation tower






the tower in the framework

...

Such tower naturally fits in the hierarchical structure of the framework.

http://www.springerlink.com/content/3lcycpvew20fcl9q/

We have applied the general schema to some toy examples, modelling them in Maude with some concrete syntax (object oriented/actor model).

In the meantime we have discovered that there is a paper by Jos Meseguer and Carolyn Talcott which essentially coincides in main idea of using reflection to program adaptive systems.

The coincidence suggests that this is indeed the natural way to program adaptive systems in Maude.

mobility

CONTROLDATA

CONTROLDATA

MANAGER

The main ideas of Meseguer&Talcot approach is to follow a russian dolls approach (nested components) with logical reflection.

This enables (in adition to adaptivity) the ability of modelling mobility, e.g. by sending meta-representation of objects around.

The approach focuses on actor models which are not very dissimilar from the SCEL/KLAIM paradigms.

adaptation

CONTROLDATA

CONTROLDATA

MANAGER

Adaptation is achieved by rules like this, which is essentially a specialisation of the abstract presentation of the adaptation tower.








http://arxiv.org/abs/1105.0069v1

GianLugi Ferrari (WP2 member) and his collaborators within WP1 have made some efforts to survey the paradigm with the purposes of 1) evaluate the key aspects to be integrated into SCEL, 2) asses the conceptual framework.

The most insightful reading was Ghezzi's et al. paper Context-Oriented Programming: A paradigm for Autonomic Computing, where several approache/languagess to COP are discussed and compared to aspect oriented languages (another paradigm promoted as suitable for autonomic computing).

context-oriented programming

AA'A''

The main idea of COP is that computation depends on the context of execution, where context means any computationally accessible information (e.g. enviromental data drawn from sensors).

In the figure we see that the computational entity A evolves into A' if under the blue context, while it would evolve into A'' if under the green context.

The chunks of behaviours associated to contexts are called variations.

Adaptation is achieved by activating or disactivating variations (e.g. in reaction to events).

context-oriented languages

ContextL(isp)

ContextPy(thon)

ContextR(uby)

ContextS(malltalk)

ContextScheme

ContextJ(ava)

ContextErlang

...

Many languages have been extended to adopt the context oriented paradigm.

contextJ

class bot {private void go(void); void go(void){set_speed(normal); }

layer surface{void go(void){all_wheel_drive();set_speed(fast); }}

layer darkness{void go(void){proceed(); /* propagation */turn_lights_on();set_speed(slow); }}}

In ContextJ, variations are specified with so-called layers.

Essentially, they are specialized method implementations: one for each known layer.

dynamic dispatching

darknesssurfacemeteor_stormwith(surface){with(darkness){with(meteor_storm){go();}}}

Active Variation Stack

Context-dependent computation is achieved with a sort of dynamic dispatching mechanism.

layers as control data

darknesssurfacemeteor_stormwith(this.layers()){go();}

bot.set_layers(...);

Context-dependent computation is achieved with a sort of dynamic dispatching mechanism.

MAPE-K in COP

The COP variant of ContextJ does also fit in the MAPE-K framework as explained by Ghezi et al., essentially thanks to a reflective API that allows to access the active variations.





CONCLUSION

*In this talk we present the framework and two paradigms for modelling and programming adaptive systems, discussing how they fit into the framework:



summary

We have presented a conceptual framework for adaptation:compositional (hierarchical);

explicit control-data;

MAPE-K compliant.

Assessment with foundational models and paradigms:e.g. reflective logical frameworks;

e.g. context-oriented languages;

What's next?

formal components

MonitorExecute

Knowledge

Analyze

Plan

AUTONOMIC MANAGER

MANAGED ELEMENT

Control Data

Control Data

Control

model checking,logical inference



xmey

mezu

?

?

...

one idea

Under which context conditions can I reach my goal? via model checking based on unification/narrowing.

devise plans to reach context conditions (subgoals or requirements on collaborating components).

THANKS A LOT!

[email protected]/in/albertolluch

Seite

add presenter in foot line

Future Emerging Technologies

www.ascens-ist.eu


Seite


Seite

Cliccate per modificare il formato del testo del titoloTitle [Arial 24pt]

Cliccate per modificare il formato del testo della strutturaSecondo livello strutturaTerzo livello strutturaQuarto livello strutturaQuinto livello strutturaSesto livello strutturaSettimo livello strutturaOttavo livello struttura

Nono livello strutturaFirst level [Arial 20pt]

Second level [Arial 18pt]

Third level [Arial 18pt]

Fourth level [Arial 16pt]

Fifth level [Arial 16pt]


a conceptual framework for behavioural adaptation @ leicester 2011

Technology