Model-Driven Engineering of Self-Adaptive Software with EUREMA

1. INTRODUCTION

• EUREMA combines a domain-specific modeling language and runtime interpreter to specify and execute adaptation engines with multiple feedback loops.Its contributions include evaluating the language by modeling approaches from the literature and quantifying interpreter efficiency.Source: §1 · p. 2
• Feedback-loop diagrams specify activities and runtime models, while layer diagrams show how modules relate to adaptable software.Layer diagrams provide a black-box architectural view; feedback-loop diagrams expose module internals.Source: §1 · p. 2
• EUREMA models remain alive at runtime, where an interpreter executes them and they can be adjusted to evolve feedback loops.The approach also supports the coexistence of self-adaptation and offline adaptation for software evolution.Source: §1 · p. 2
• The article extends earlier EUREMA concepts with layer diagrams and feedback-loop triggers, a layered-architecture approach, and new contributions on requirements, offline adaptation, and evaluation.The earlier version addressed contributions (b), (c), and (d).Source: §1 · p. 2

2. TERMINOLOGY, CONCEPTS, AND REQUIREMENTS

• The external approach separates adaptable software from an adaptation engine, making the feedback loop between them crucial to the architecture.The engine controls the adaptable software through sensing and effecting.Source: §2 · pp. 2–3
• MAPE-K refines a feedback loop into monitor, analyze, plan, and execute activities that share knowledge; the language should model their control flow and triggers.The control flow exposes dependencies among activities, while triggers specify when a loop executes.Source: §2 · p. 3
• Multiple feedback loops require inter-loop coordination and distribution, while their loops and activities also need support for concurrent execution.Loops may address different concerns or decentralize control.Source: §2 · p. 3
• Runtime knowledge includes models used by any adaptation activity, not only models reflecting the adaptable software; evaluation and change models may also be combined.Event-condition-action rules can evaluate a condition and apply actions in one step; monitoring and execution models support the causal connection.Source: §2 · pp. 3–4
• Sensors and effectors connect the engine to adaptable software; the authors assume software provides them and their details are mostly hidden in monitor and execute implementations.Depending on available sensors and effectors, adaptation may be parameter-based, structural, or both.Source: §2 · p. 4
• Layered architectures require runtime reflection of lower-layer feedback loops so higher-layer loops can adapt them, and the language should support both declarative and procedural reflection.Offline adaptation remains necessary because software cannot be expected to automate every evolution need; the language and runtime should support its coexistence with online adaptation.Source: §2 · pp. 4–5

3. STATE OF THE ART IN ENGINEERING ADAPTATION ENGINES

• Frameworks often generate or provide structurally static, predefined single-loop engines, while runtime-model frameworks offer limited flexibility to adjust loop structure.Some allow runtime modification of models, such as replacing adaptation strategies, but do not explicitly model the feedback loop.Source: §3 · p. 5
• Existing approaches to multiple loops offer specific coordination solutions or implementation support, but do not consistently model loops and their coordination at the architectural level.The surveyed approaches include protocols, controllers, and reusable communication components.Source: §3 · pp. 5–6
• Prior layered architectures provide limited runtime adaptation, including fixed layer or loop structures and solutions focused on initial planning or plan generation.The discussion also notes that offline evolution work does not address changing feedback-loop or layer structure.Source: §3 · p. 6
• State-of-the-art approaches do not support all the requirements for engineering adaptation engines; EUREMA aims to unify explicit design, execution, and adaptation of feedback loops.EUREMA does not prescribe loop structure or limit the number of loops or layers.Source: §3 · p. 7
• EUREMA keeps models alive at runtime to execute feedback loops and adjust loops and layers dynamically or through offline adaptation.This contrasts with approaches that explicitly model loops only for design or provide runtime support without explicit loop models.Source: §3 · pp. 6–7

4. FEEDBACK LOOP DIAGRAMS

• EUREMA megamodels capture runtime models, their interplay, and model-operation flow, and remain alive at runtime for executing and evolving feedback loops.The language treats loop knowledge as runtime models and adaptation activities as operations over those models.Source: §4 · p. 7

4.1. Modeling an Individual Feedback Loop

• An FLD specifies operations, control flow, runtime models, and model usage; the self-repair example synchronizes a software-reflecting architectural model before analysis and possible repair.The analysis checks for failures; planning selects repair strategies and Effect synchronizes the architectural changes to the software.Source: §4.1 · pp. 8–9

4.2. Modularizing Feedback Loop Diagrams

• Separate FLDs can encapsulate activities and be invoked as complex operations, enabling reusable parts and abstraction while preserving the loop’s functionality.FLD initial and final states map to the invoking operation’s entry and exit compartments; the depth of abstraction is unrestricted.Source: §4.2 · pp. 9–10

4.3. Modeling Multiple Feedback Loops and their Coordination

• Distinct FLDs can model separate concerns, while a coordinating FLD makes execution order explicit to address potential interference between loops.The examples coordinate self-repair and self-optimization loops.Source: §4.3 · pp. 10–11

4.3.1. Sequencing Complete Feedback Loops.

• Sequential coordination prioritizes repair before optimization, then chooses whether optimization starts with analysis or monitoring based on whether repair adapted the software.If repair makes no adaptation, the next loop can reuse the shared, already-updated reflection model; after an adaptation, optimization monitors its effects.Source: §4.3.1 · pp. 11–12

4.3.2. Sequencing Adaptation Activities of Feedback Loops.

• A second design shares monitoring and execution while sequencing concern-specific analysis and planning; operation implementations must resolve conflicting proposed adaptations.The self-repair plan may modify the shared architectural model, so subsequent self-optimization analysis and planning must account for that proposal before Effect applies changes.Source: §4.3.1 · p. 12, §4.3.2 · pp. 12–13

5. LAYER DIAGRAMS

• LDs complement behavioral FLDs by structurally representing the loops employed in a software instance, their interrelationships, and their triggering conditions.This extension addresses what FLDs alone do not structurally reflect.Source: §5 · pp. 13–14
• LD partitions represent software layers, with FLD instances shown as white-tab packages and software modules outside EUREMA as black-tab packages.Dotted arrows represent sensing or effecting; solid arrows represent usage relationships between megamodel modules.Source: §5 · p. 13
• An LD can label modules with the adaptation activities they realize, while use relationships bind model operations to invoked modules or implementations.The self-repair example places the loop at Layer-1, sensing and effecting the adaptable software at Layer-0.Source: §5 · pp. 13–14

5.1. Triggering Conditions for Feedback Loops

• A trigger condition can require specified events from a sensed module and a minimum delay since the loop’s previous run before execution begins.The example starts self-repair on a runtime-exception event after ten seconds have elapsed, entering the Monitor state.Source: §5.1 · p. 14
• The period sets the minimum time between termination of one run and the start of the next, delaying eligible runs until the interval has elapsed.The delay allows an earlier adaptation to take effect and can reduce thrashing from proliferating events.Source: §5.1 · pp. 14–15
• Events and period are optional individually but at least one is required; instances are non-reentrant, and triggers may be event-driven or periodic.Events occurring during a run are queued; event-driven triggers support reactive adaptation, while periodic triggers support proactive adaptation.Source: §5.1 · p. 15

5.2. Variability Modeling

• Encapsulating loops or activities as megamodel modules and relating them in LDs exposes variation points that can be switched at design time or dynamically at runtime.These variation points represent architectural variability of feedback loops.Source: §5.2 · p. 15
• Alternative analysis FLDs with the same signature can implement one complex operation, allowing a use relationship to be rerouted to the selected analysis module.The example switches from Self-repair-A to Self-repair-A2, which uses a different analysis technique.Source: §5.2 · p. 15
• LDs can also capture alternative software modules for a basic operation and change which implementation the operation is bound to.The paper describes this binding change as another way to exploit variability.Source: §5.2 · p. 15

5.3.1. Independent Execution of Multiple Feedback Loops.

• Independent loops can run concurrently when they have distinct triggers and no interference; layer diagrams make their instances and triggers visible.The example uses self-repair and self-optimization loops sensing and effecting mRUBiS, with separate triggering conditions.Source: §5.3 · p. 16, §5.3.1 · p. 16

5.3.2. Coordinated Execution of Multiple Feedback Loops.

• Coordinated loops can sequence whole feedback loops or sequence their analyze and plan activities through coordinating modules.The two mechanisms are specified in feedback loop diagrams that invoke the individual loops’ diagrams.Source: §5.3.1 · p. 16
• Layer diagrams expose the invocation relationships between coordinating modules and the feedback loop modules they invoke.The diagrams also show the triggers that combine conditions from the individual loops.Source: §5.3.2 · pp. 16–17
• A coordinating module may either perform no adaptation activities or perform monitor and execute while the other modules perform analyze and plan.Self-management-1 has no adaptation-activity label; Self-management-2 performs M..E while the other modules perform AP.Source: Figure 17 · p. 16, §5.3.2 · p. 17

5.4. Modeling Layered Feedback Loops

• EUREMA feedback loop models remain alive at runtime, so an interpreter can dynamically change their structure, operations, runtime-model usage, control flow, or decision conditions.Such adaptations may be performed while the models are executing.Source: §5.4 · p. 17

5.4.1. Procedural Reflection.

• A higher-layer loop can use the lower-layer loop’s executing EUREMA model as its reflection model, avoiding a separate representation.This procedural reflection ensures the causal connection by construction; the example uses the model to assess repair success and provide synthesized strategies to the self-repair loop.Source: §5.4.1 · pp. 17–18
• Procedural reflection couples adaptation to execution, so higher-layer changes are enacted immediately in the lower-layer loop.The shared model cannot be adapted independently of the loop that it specifies and executes.Source: §5.4.1 · p. 19

5.4.2. Declarative Reflection.

• Declarative reflection keeps a separate, user-defined model of the lower-layer loop, allowing the higher-layer loop to be decoupled from its execution.Monitor and execute activities maintain and apply that model, while analyze and plan use it to assess and change repair strategies.Source: §5.4.2 · p. 19
• The user-defined reflection model can select its information and abstraction level, but engineers must implement synchronization to preserve its causal connection to the loop.A layer diagram indicates procedural reflection when the model is bound to a module and declarative reflection when it is not.Source: §5.4.2 · pp. 19–20

5.5. Off-line Adaptation

• Offline evolution uses snapshots of runtime EUREMA models for engineering analysis and planning, then loads the resulting models into the interpreter for online execution.The adaptation is treated as a loop split between online monitor and execute activities and offline analyze and plan activities.Source: §5.5 · p. 20

5.5.1. Adding and Removing Feedback Loops.

• Engineers can add or remove loops and change module bindings or triggers by dynamically modifying the layer diagram.An integration rule can add a higher-layer module and its relationships; consistent reconfiguration may delay existing modules, and trigger conditions coordinate execution.Source: §5.5.1 · p. 21, Figure 22 · p. 21

5.5.2. Changing a Running Feedback Loop.

• A running loop can be patched by a temporary higher-layer module that replaces its repair strategies and is removed after its one-time execution.The patch process is specified by an uploaded feedback loop diagram with a destruction state.Source: §5.5.2 · pp. 21–22

5.5.3. Support for Adapting Legacy Feedback Loops.

• Legacy feedback-loop modules are treated as black boxes, and the interpreter can deactivate them when they can be triggered like EUREMA loops.This supports migration to feedback loops specified as megamodel modules.Source: §5.5.2 · p. 22

5.5.4. Changing the Adaptable Software.

• An offline update can replace a component in the adaptable software through a temporary module that reconfigures the architecture and synchronizes with the running repair loop.The module is removed after reconfiguration to avoid interference with the repair loop.Source: §5.5.4 · p. 22

6. METAMODEL AND INTERPRETER IMPLEMENTATION

• EMF implements the metamodel and interpreter, while a basic profile mechanism supplies diagram stereotypes and labels and JavaCC implements branching-condition syntax.The stereotypes and labels do not affect execution semantics.Source: §6 · p. 23
• The interpreter can run independently of the Eclipse workbench and supports user-defined EMF runtime models, dynamic model loading and unloading, and snapshot export.It handles runtime models as inputs or outputs of model-operation executions.Source: §6 · p. 23
• The interpreter fully supports executing feedback loop diagrams and almost fully supports layer diagrams, but layer diagrams are not yet explicitly maintained as runtime models.Multiple and layered loops can execute; making the layer diagram an explicit runtime model is ongoing work.Source: §6 · p. 23

7.1. Design Decisions

• FLDs treat activities as operations on runtime models and add control flow and model usage to specify executable, coordinated feedback loops.Keeping FLDs alive at runtime supports adaptable feedback loops and reflection models.Source: §7.1 · pp. 23–24
• LDs add layers, modules, and use, sense, and effect relationships, making loop placement, control dependencies, and triggering conditions explicit.As runtime models, LDs provide an adjustable instance view intended to facilitate offline adaptation.Source: §7.1 · p. 24
• EUREMA’s domain-specific diagrams separate adaptation logic from domain logic, while its megamodel concepts distinguish FLDs from UML activity flows.The lean metamodel supports an interpreter described as efficient compared with what could be achieved for UML’s complex metamodel.Source: §7.1 · pp. 24–25
• EUREMA applies MDE at design and runtime, allowing existing model-based engines for activities to be integrated and reused.For example, OCL expressions used in analysis can be adapted without changing the OCL engine.Source: §7.1 · p. 25

7.2. Requirements Coverage

• FLDs and LDs cover individual and multiple loops, coordination, arbitrary runtime models, layered and hierarchical control, and offline adaptation for long-term evolution.Parameter and structural adaptation are supported when suitable sensors, effectors, and activity implementations are available.Source: §7.2 · pp. 25–26
• EUREMA covers the identified requirements except distribution and entirely concurrent execution, so adaptation engines cannot be distributed and interdependent loops cannot run concurrently.It supports these adaptation activities when corresponding sensors, effectors, and implementations are available.Source: §7.2 · p. 26

8.1. Application of the EUREMA Language

• The PLASMA middle-layer loop monitors application architecture, uses plans from the higher layer, and executes reconfiguration commands to align the application with its target architecture.The Adaptation Analyzer uses the plan and the Admin-1 operation executes the generated commands.Source: §8.1 · pp. 26–27
• For PLASMA, a higher-layer planner generates application and adaptation plans and can reconfigure the middle-layer loop to execute a new adaptation plan.The Planning-layer FLD in Figure 26 represents this higher-layer loop.Source: §8.1 · p. 27, Figure 26 · p. 27
• PLASMA fidelity is difficult to assess because its runtime models and their use are implicit, so the evaluation omits triggers and derives model usage as far as possible.Interpreter scalability for larger EUREMA models also requires further investigation, and the code-based comparison needs further investigation.Source: §8.1 · p. 27, §8.2 · pp. 29–30
• Modeling PLASMA, Rainbow, and DiVA demonstrates EUREMA can capture varied feedback-loop drivers and both layered and single-loop designs.The examples span architecture description languages in PLASMA and Rainbow, MDE in DiVA, and two layered loops in PLASMA versus single loops in Rainbow and DiVA.Source: §8.1 · pp. 27–28

8.2. Runtime Characteristics of the EUREMA Interpreter

• The interpreter experiment compares a Java implementation that sequentially invokes five mocks with EUREMA across mock durations of 0, 5, 10, and 20ms and varied run periods.The loop runs for ten minutes per feasible parameter combination; mock durations correspond to total computation times of 0, 25, 50, or 100ms per run.Source: §8.2 · p. 28
• Interpreter overhead stays below 0.2 percentage points, and its average pure load is below 1% for the tested self-repair loop.The overhead comparison is shown in Figure 28; Figure 27 reports the pure load for the 0ms case.Source: Figure 28 · p. 29, §8.2 · p. 29, Figure 27 · p. 29

• EUREMA provides a model-driven approach with a language to specify and an interpreter to execute feedback loops.Source: §9 · p. 30
• Unlike related approaches, EUREMA covers specification and execution, explicitly models feedback loops, and permits arbitrary user-defined loops across any number of layers.Related modeling languages lack runtime support, while frameworks do not explicitly model feedback loops or offer this structuring flexibility.Source: §9 · p. 30
• Runtime models capture feedback-loop knowledge and remain alive, supporting layered loops that dynamically adjust the adaptation engine and enable offline software evolution.Source: §9 · p. 30
• EUREMA covers almost all stated requirements conceptually; examples model three literature approaches, and runtime measurements indicate the interpreter works efficiently and is applicable at runtime.Source: §9 · p. 30
• Future work includes interdependent-loop concurrency, distributing engines in a multi-robot system, model-based analysis and simulation, and empirical evaluation.Source: §9 · p. 30