A conceptual framework for behavioural adaptation @ Leicester 2011

Editor's Notes

• #3: 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.
• #4: 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.
• #9: 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.
• #10: 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.
• #11: 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.
• #12: One of our starting points was W4's definition of (behavioural) adaptation.
• #13: From the definition of adaption we derive the definition of “adaptability” (the ability of being adaptable).
• #14: 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).
• #15: 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).
• #16: What is control data? This depends on the computational model or language. For instance, some natural choices might be “ rules” in rewrite systems “ contexts” in contex-oriented paradigms “ policies” in policy-driven approaches/SCEL? etc.
• #17: 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).
• #18: 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).
• #19: This seems conformant with WP4's control loop patterns like the “external feedback loop” pattern.
• #20: ...or the “internal feedback loop” pattern
• #21: 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).
• #22: 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.
• #23: 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.
• #24: 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.
• #25: 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.
• #26: 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.
• #27: 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.
• #28: 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.
• #29: 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.
• #30: 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.
• #31: 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.
• #32: Such tower naturally fits in the hierarchical structure of the framework.
• #33: 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.
• #34: 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.
• #35: Adaptation is achieved by rules like this, which is essentially a specialisation of the abstract presentation of the “adaptation tower”.
• #36: 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.
• #37: 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”).
• #38: 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).
• #39: Many languages have been extended to adopt the context oriented paradigm.
• #40: In ContextJ, variations are specified with so-called “layers”. Essentially, they are specialized method implementations: one for each known layer.
• #41: Context-dependent computation is achieved with a sort of dynamic dispatching mechanism.
• #42: Context-dependent computation is achieved with a sort of dynamic dispatching mechanism.
• #43: 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.
• #44: 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.
• #47: 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.