Model-Driven Engineering of Self-Adaptive Software with EUREMA

by   Thomas Vogel, et al.
Universität Potsdam

The development of self-adaptive software requires the engineering of an adaptation engine that controls the underlying adaptable software by feedback loops. The engine often describes the adaptation by runtime models representing the adaptable software and by activities such as analysis and planning that use these models. To systematically address the interplay between runtime models and adaptation activities, runtime megamodels have been proposed. A runtime megamodel is a specific model capturing runtime models and adaptation activities. In this article, we go one step further and present an executable modeling language for ExecUtable RuntimE MegAmodels (EUREMA) that eases the development of adaptation engines by following a model-driven engineering approach. We provide a domain-specific modeling language and a runtime interpreter for adaptation engines, in particular feedback loops. Megamodels are kept alive at runtime and by interpreting them, they are directly executed to run feedback loops. Additionally, they can be dynamically adjusted to adapt feedback loops. Thus, EUREMA supports development by making feedback loops explicit at a higher level of abstraction and it enables solutions where multiple feedback loops interact or operate on top of each other and self-adaptation co-exists with offline adaptation for evolution.



page 1

page 2

page 3

page 4


A language for feedback loops in self-adaptive systems: Executable runtime megamodels

The development of self-adaptive software requires the engineering of pr...

Requirements and Assessment of Languages and Frameworks for Adaptation Models

Approaches to self-adaptive software systems use models at runtime to le...

mRUBiS: An Exemplar for Model-Based Architectural Self-Healing and Self-Optimization

Self-adaptive software systems are often structured into an adaptation e...

A Testing Scheme for Self-Adaptive Software Systems with Architectural Runtime Models

Self-adaptive software systems (SASS) are equipped with feedback loops t...

Tigris: a DSL and Framework for Monitoring Software Systems at Runtime

The understanding of the behavioral aspects of a software system is an e...

Adaptation and Abstract Runtime Models

Runtime adaptability is often a crucial requirement for today's complex ...

The Role of Models and Megamodels at Runtime

In model-driven software development a multitude of interrelated models ...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

Self-adaptation capabilities are required for many modern software systems that are self-aware, context-aware, mission-critical, or ultra-large-scale to dynamically adapt their configuration in response to changes in the system itself, the environment, or the requirements [Cheng et al. (2009), de Lemos et al. (2013)]. The development of self-adaptive software following the external approach [Salehie and Tahvildari (2009)] separates the software into the adaptable software and the adaptation engine. In between both, a feedback loop ensures that the adaptation engine dynamically adjusts the adaptable software if needed. This separation decouples the engine from the adaptable software but it makes the feedback loop a crucial element of the overall software architecture [Shaw (1995), Müller et al. (2008), Brun et al. (2009)] and therefore essential for engineering an adaptation engine in the external approach.

In this article, we present a model-driven engineering (MDE) approach called ExecUtable RuntimE MegAmodels (EUREMA) that enables the specification and execution of adaptation engines for self-adaptive software with multiple feedback loops. The EUREMA language eases the development of adaptation engines by supporting a domain-specific modeling solution and the EUREMA runtime interpreter supports the execution of adaptation engines and feedback loops. Moreover, EUREMA explicitly maintains the runtime models used within an adaptation engine, the interplay between these models, and the adaptation activities working on these models. Thus, the maintenance and evolution of runtime models and adaptation activities continues at runtime beyond the initial development of the software.

The EUREMA modeling language is specific for adaptation engines and it provides two types of diagrams to specify them. A behavioral feedback loop diagram (FLD) is used to model a feedback loop or individual adaptation activities and runtime models of a loop. An FLD is considered as a megamodel module specification encapsulating the details of a partial or complete feedback loop. A structural layer diagram (LD) describes how the megamodel modules and the adaptable software are related to each other in an instance situation of the self-adaptive software. Thus, an LD provides an architectural view that considers feedback loops encapsulated in modules as black boxes while white-box views are provided by FLDs. Hence, EUREMA models specify feedback loops and their structuring in adaptation engines. These models make the feedback loops explicit in the architectural design of self-adaptive software and they are kept alive at runtime and executed by an interpreter. This supports the seamless design, development, execution, and even adaptation of feedback loops.

This article discusses EUREMA with its following contributions: (a) we thoroughly discuss requirements for adaptation engines, (b) feedback loops and their coordinated execution are explicitly modeled, (c) a feedback loop’s knowledge is explicitly captured by runtime models, (d) EUREMA models are kept alive at runtime and they are directly executed by an interpreter, which leverages adaptive feedback loops in layered architectures, (e) self-adaptation and off-line adaptation co-exist for evolving self-adaptive software, and (f) we evaluate EUREMA by modeling state-of-the-art approaches to self-adaptive software from literature and by quantifying the runtime efficiency of the interpreter.

This article is a revised and extended version of [Vogel and Giese (2012a)] that introduced the initial concepts of EUREMA and therefore only addressed the contributions (b), (c), and (d). In contrast, this article refines them by extending the language with layer diagrams (LDs) including feedback loop triggers, and by proposing a sound approach for layered architectures. Therefore, this article entirely presents the novel contributions (a), (e), and (f).

The rest of the article is structured as follows. Foundations and requirements for self-adaptive software are discussed in Section 2 and related work in Section 3. We introduce the EUREMA concepts as proposed by [Vogel and Giese (2012a)] in Section 4 and discuss the novel concepts in Section 5. We present technical details in Section 6, discuss design decisions and the requirements coverage in Section 7, and evaluate EUREMA in Section 8. Finally, we conclude the article and outline future work.

2 Terminology, Concepts, and Requirements

In this section, we clarify relevant terminology and concepts of self-adaptive software and we discuss core requirements for engineering such software. As the external approach is typically adopted in self-adaptive software [Salehie and Tahvildari (2009)], we consider this approach as depicted in Figure 3. It assumes a basic architecture that splits the self-adaptive software into the adaptation engine and the adaptable software while the former one controls (sensing and effecting) the latter one. The adaptable software realizes the domain logic and the engine implements the adaptation logic as a feedback loop, which constitutes self-adaptation.

Thus, the engineering of adaptation engines and feedback loops is essential for the external approach. This requires a modeling language and techniques to design, implement, run, and maintain such an engine with its feedback loops. In the following, we discuss corresponding requirements (R) for self-adaptive software, particularly for a modeling language.

Feedback Loops

Separating the adaptation engine from the adaptable software makes the feedback loop between them a crucial element of the architecture, which has to be made explicit in the design of self-adaptive software [Brun et al. (2009), Müller et al. (2008), Shaw (1995)]. Thus, feedback loops have to be explicitly modeled (R1). A more detailed view of the feedback loop is provided by the MAPE-K cycle (Monitor/Analyze/Plan/Execute-Knowledge)  [Kephart and Chess (2003)]  depicted in Figure 3. The feedback loop is refined to four adaptation activities sharing knowledge. The adaptable software is monitored and analyzed, and if changes are required, adaptation is planned and executed to this software.

As sketched in Figure 3, the modeling language should support the specification of adaptation activities that form a feedback loop. This includes the intra-loop coordination [Vromant et al. (2011)] (R2) by means of the control flow for these activities, which makes the execution dependencies between individual activities explicit. Moreover, the language should address when a feedback loop should be executed, for example, by capturing triggering conditions (R3).

Additionally, multiple feedback loops have to be considered [Kephart and Chess (2003), Weyns et al. (2012)] to handle different concerns such as failures and performance [Kephart et al. (2007), Vogel and Giese (2010)] or to decentralize control [Weyns et al. (2013)]. The language should therefore support the modeling of multiple, interacting feedback loops. This imposes the need for inter-loop coordination [Vromant et al. (2011)] (R4) and distribution (R5) of feedback loops. Moreover, besides specifying feedback loops, the language should support the concurrent execution (R6) of the feedback loops and activities based on the specifications.

Figure 1: External approach
Figure 2: MAPE-K
Figure 3: Runtime Models

In MAPE-K, the adaptation activities are the computations performing self-adaptation and the knowledge refers to data used by these computations. This motivates the explicit treatment of the knowledge that is refined in our case to a set of runtime models. While MC.2009.326 consider only runtime models that reflect the adaptable software, we take a broader perspective and consider all models that are used by any adaptation activity. Thus, analysis rules and adaptation strategies are examples for further runtime models. Based on a literature review, we proposed a categorization of runtime models for feedback loops in [Vogel et al. (2011)], which is depicted in an extended version in Figure 3.

Reflection Models reflect the adaptable software and its environment, and they are updated by monitoring the software and environment. Thereby, Monitoring Models map system-level observations to the abstraction level of reflection models. The reflection models are analyzed to identify adaptation needs by applying Evaluation Models that, for example, define constraints on reflection models. If adaptation needs have been identified, the planning activity devises a plan prescribing the adaptation on the reflection models. Planning is specified by Change Models describing the adaptable software’s variability space. Evaluation models such as utility preferences guide the exploration of this space to find an appropriate adaptation. Finally, the execute activity enacts the planned adaptation on the adaptable software based on Execution Models that refine model-level adaptation to system-level adaptation.

Evaluation and change models do not have to be strictly separate models, which is exemplified by event-condition-action rules that address the analyze (evaluating the condition) and the plan (applying the actions) activities in one step. Thus, we combine them to Adaptation Models [Vogel and Giese (2012b)]. Monitoring and execution models are concerned with the synchronization of the adaptable software and the reflection models. This is known as the causal connection [Maes (1987)] such that we consider them as Causal Connection Models.

This categorization shows that different kinds of runtime models are simultaneously used in a feedback loop, which should be captured by a modeling language for such loops (R7).

Sensors and Effectors

The adaptation engine and the adaptable software are connected by sensors and effectors (cf. Figure 3). Thus, the modeling language has to cover when the monitor and execute activities that use the sensors and effectors are activated to maintain the causal connection between the reflection models and the adaptable software. Since sensors and effectors usually depend on the specific adaptable software, we—and others like GarCHSS04 and 1555028—assume that they are provided by the software and that most of their details are hidden in the implementation of the monitor and execute activities. This assumption is motivated by programming language and middleware platforms that have recognized the need for runtime management by supporting the development of sensors and effectors or already providing them through application programming interfaces. Examples are the Java Management Extensions (JMX) or the OSGi platform.

Depending on the available sensors and effectors, parameter or structural adaptation, or a combination of both [McKinley et al. (2004)] can be realized. Parameter adaptation changes variables and structural adaptation the architecture of the adaptable software. Focusing on software architectures, we especially require support for structural adaptation (R8).

Layered Architecture

Feedback loops might have to operate on top of each other, which results in layers of feedback loops, in order to realize adaptive [Isermann et al. (1992), Kokar et al. (1999)] or hierarchical control schemes [Findeisen et al. (1980), Hestermeyer et al. (2004)], robot software [Gat (1997)], or the reference architecture of Kramer&Magee2007.

In such layered architectures, a feedback loop at a higher layer can adapt the feedback loop at the layer below. Therefore, some form of reflection of the lower-layer feedback loop has to be provided at runtime enabling the adaptation of this loop [Andersson et al. (2009)].

Thus, the modeling language should leverage layered architectures by supporting adaptable feedback loops and reflection models representing these loops for structural adaptation (R9). In this context, declarative and procedural reflection [Maes (1987)] should be supported. In declarative reflection, a separate representation of the program is maintained and used for meta-computations such as adaptation. Procedural reflection maintains no separate representation and uses directly the program for meta-computations. Finally, the language should support feedback loops that adapt lower-layer loops by operating on the reflection models.

Offline Adaptation

Though self-adaptation promises that the software adjusts itself by automating adaptation activities otherwise performed offline for evolution, we cannot expect that software is able to cope with all needs for evolution and to fully automate all kinds of offline activities. Thus, besides an adaptation engine realizing (online) self-adaptation, the engine’s co-existence with offline adaptation is required [Gacek et al. (2008), Andersson et al. (2013)]. Similar to SEfSAS2-process, we consider an adaptation activity to be offline if it is performed externally to the self-adaptive software as typically done today in development environments. If an activity is performed internally to the software, we refer to online activities. Hence, the language and its runtime environment should support the co-existence of online and offline adaptation for evolving self-adaptive software (R10).

3 State of the Art in Engineering Adaptation Engines

In the following, we review state-of-the-art approaches for engineering adaptation engines with respect to the requirements discussed in the previous section.

There exists a lot of work on feedback loops to control systems, like in autonomic computing that applies control theory to parameter adaptation of software [Hellerstein et al. (2004), Kokar et al. (1999)]. However, self-adaptation oftentimes considers dynamic software architectures [McKinley et al. (2004)] (R8), which prevents a direct application of control theory and requires new means for engineering. Popular means are frameworks that use some form of models [Salehie and Tahvildari (2009)]. Such frameworks employ models to specify self-adaptation as mappings of assertions to adaptation actions [Schmidt et al. (2008)] or as transitions between configurations of the adaptable software [Bencomo and Blair (2009)]. These models are used for generating partial adaptation engines to ease development. However, the resulting engines supporting single feedback loops are structurally static and pre-defined by the frameworks. The models do not make the feedback loop explicit (R1) and they are not kept alive at runtime (R7) to execute (R6) or dynamically adjust (R9) the engine.

In contrast, frameworks such as Rainbow [Garlan et al. (2004)], MADAM [Floch et al. (2006)], MUSIC [Rouvoy et al. (2009)], DiVA [Morin et al. (2009a), Morin et al. (2009b)], or GRAF [Amoui et al. (2012)] maintain runtime models that specify the adaptation and capture the feedback loop’s knowledge (R7). These models can be modified at runtime by engineers, especially to replace adaptation strategies to adjust the adaptation logic. However, support for dynamically adjusting a feedback loop (R9) is limited since these frameworks support only single loops, whose structuring of adaptation activities cannot be adjusted in contrast to specific models consumed by the activities. Additionally, the runtime models do not explicitly specify feedback loops (R1) because these frameworks prescribe single feedback loops and just offer customization points, like to inject adaptation strategies. This is motivated by their focus to reduce efforts for developing adaptation engines at the expense of limited flexibility. Thus, when developing a specific self-adaptive software, these frameworks do not support feedback loops that are entirely and individually designed by engineers for the specific case.

All the approaches discussed so far do not support adaptation engines with multiple feedback loops (R4). Kephart+2007 consider interactions between two feedback loops that manage competing concerns by a solution “established through trial and error” [Kephart et al. (2007), p. 24] for one specific case. In contrast, a generic coordination protocol is presented by Oliveira+2012, which supports mutual exclusive access to knowledge and the triggering among the loops. However, the protocol is restricted as a loop may only trigger another loop from the execute but not from the monitor, analyze, or plan activities. Thus, directly coordinating, for example, the individual analyses is not supported. In [Gueye et al. (2012)], the coordination between feedback loops is realized by a controller that decides which loop may exclusively operate. This decision is specified by coordination models and policies used for generating the controller. However, these models do not specify the feedback loops and their coordination at the architectural level of self-adaptive software (R1). Other approaches addressing multiple loops are implementation frameworks that aim at reducing development efforts without prescribing a specific coordination mechanism. Vromant+2011 provide reusable components for the distributed communication among feedback loops or adaptation activities. ChengWICSA2004 provide an abstraction layer between the adaptable software and the feedback loops, through which all loops have consistent access and knowledge about the software. However, this layer does not coordinate the feedback loops.

All of the approaches discussed so far provide specific and pre-defined solutions or generic implementation support, which results in feedback loops whose structure cannot be dynamically adapted. Such adaptation is addressed by layered architectures, in which a higher-layer feedback loop adjusts the feedback loop at the layer below (R9). In our previous work on Mechatronic UML, we extended UML to specify and generate a hierarchical scheme that addresses control, reconfiguration, and planning by distinct feedback loops at different layers [Hestermeyer et al. (2004)]. However, the adaptation is defined before deployment and cannot be dynamically changed, especially since the models are not kept alive at runtime (R7). Heaven2009 propose a similar three-layer architecture, in which plans generated by the highest layer are executed by the middle layer to generate new configurations for the lowest layer. Thus, a layer adjusts another layer by providing new plans or configurations. However, the solution focuses on synthesizing initial plans before deployment but it does not support replanning at runtime and thus the highest-layer feedback loop adapting the middle layer. In contrast, PLASMA [Tajalli et al. (2010)] supports adapting the middle layer in a similar architecture. However, the extent of this adaptation is not clear since the middle layer architecture is predefined by engineers. The focus of PLASMA is to automate plan generation and enactment while the employed feedback loops, adaptation activities, and knowledge are not explicitly modeled for all layers (R1). Finally, the numbers of layers (three) and feedback loops for each layer (one) seem to be immutable. Thus, multiple feedback loops for a layer, or (dynamically) changing the number of feedback loops and layers are not supported.

Such extensive changes can be seen as an evolution of the self-adaptive software performed through offline adaptation (R10). GGH08_ag discuss the idea of having two intertwined feedback loops for self-adaptation and offline adaptation but they present no working solution. As discussed previously, frameworks utilizing runtime models often support changing those models, for example, to replace adaptation strategies at runtime. Morin+2009 claim to support evolution as changes performed manually on runtime models in the development environment. They propose an initial solution in [Morin et al. (2009c)], which, however, does not consider changes in the structure or number of feedback loops or layers.

All approaches discussed so far do not make the feedback loops, their adaptation activities, runtime models, and coordination explicit in the architectural design (R1). In this context, only a few approaches exist. We [Hebig et al. (2010)] proposed a UML profile to make feedback loops and the interplay of multiple loops explicit in the design, however, without capturing the loops’ individual adaptation activities (R2) and runtime models (R7). In contrast, Weyns+2012 present a formal reference model that captures feedback loops including the activities and models. The goal of the reference model is to support engineering by studying early design alternatives. However, the models created by both approaches are used for the architectural design but they are not kept alive at runtime, for example, for execution (R6).

Summing up, state-of-the-art approaches for engineering self-adaptive software aim at reducing development efforts by generating adaptation engines or providing frameworks. The resulting engines often consist of single feedback loops whose structure is rather static and predefined. This limits their adaptation during development, dynamically in layered architectures, and offline by engineers. In general, there exist only preliminary work on layered architectures (R9) and offline adaptation (R10). Moreover, approaches providing runtime support for self-adaptation (R6) do not address the explicit modeling of feedback loops (R1). Thus, they do not consider runtime models such as executable megamodels that describe feedback loops and leverage the adaptation of feedback loops. In contrast, approaches tackling the explicit modeling (R1) are focused on the design and they do not provide any runtime support based on these models (R6). Thus, state-of-the-art approaches do not support all the requirements for engineering adaptation engines discussed in Section 2.

In contrast, we propose a seamless approach whose modeling language supports the explicit design (R1), execution (R6), and adaptation (R9, R10) of feedback loops. Thereby, EUREMA improves the state of the art concerning frameworks because it does not prescribe any structure of the adaptation activities or feedback loops and it does not limit the number of feedback loops or layers. In contrast to existing modeling languages, EUREMA provides improvements by keeping the models alive at runtime for executing feedback loops and for adjusting feedback loops and layers either dynamically or by offline adaptation.

4 Feedback Loop Diagrams

This section discusses the EUREMA language for engineering adaptation engines as introduced in [Vogel and Giese (2012a)]. The language is based on the concept of megamodels originating from the research field of model management in MDE. A megamodel refers to a model that contains other models and relationships between these models while the relationships constitute operations such as model transformations [Barbero et al. (2007), Bézivin et al. (2003), Bézivin et al. (2004), Favre (2005)]. EUREMA adopts this generic concept for specifying and executing feedback loops by considering the feedback loop’s knowledge as runtime models and the individual adaptation activities as model operations working these runtime models.

Therefore, EUREMA (mega)models explicitly specify feedback loops by capturing the runtime models, the interplay and usage of these models, and the flow of model operations. Moreover, EUREMA models are kept alive at runtime for executing feedback loops. Thereby, megamodel concepts are leveraged at runtime to explicitly maintain and evolve the runtime models and model operations beyond the initial development of the feedback loops.

To discuss EUREMA and all of its modeling concepts, we keep the adaptable software abstract to cover different variants of adaptation engines instead of a specific engine for a specific software. We consider a component-based application as the adaptable software, which is adaptable at the architectural level. Tackling adaptation at the architectural level is a popular approach [Garlan et al. (2004), Morin et al. (2009b)] as it provides promising abstractions for parameter and structural adaptation [McKinley et al. (2004)]. Nevertheless, most examples in this article are extended and generalized scenarios of our earlier work [Vogel and Giese (2010), Vogel et al. (2010)] that used an online marketplace, recently extended to mRUBiS[Vogel (2013)], as an application example. However, EUREMA has not been used in our earlier work that just proposed a code-based and static solution for structuring the adaptation activities and runtime models of the feedback loops. In contrast, EUREMA proposes a model-driven and flexible approach to specify, execute, and adapt feedback loops.

4.1 Modeling an Individual Feedback Loop

To model a feedback loop with its adaptation activities and runtime models, the EUREMA language provides a behavioral feedback loop diagram (FLD). Such a diagram specifies a feedback loop by means of operations, the control flow of operations, runtime models, and the model usage by operations. For instance, a feedback loop supporting self-repair capabilities by automatically recovering the adaptable software from failures at runtime is specified by the FLD depicted in Figure 5. This FLD is framed and labeled with its name Self-repair.

Figure 4: FLD for Self-repair
Figure 5: Concrete syntax for FLDs

The concrete syntax of FLDs is shown in Figure 5. Initial and final states are special operations that define the entry and exit points for executing a feedback loop instance. A destruction state is a final state that destroys the instance when this state is reached. Adaptation activities are specified as model operations represented by hexagon block arrows labeled with their names. A model operation has at least one named exit compartment, one for each return status of the operation. At runtime, the implementation of the operation determines the return status and therefore, which compartment is activated to continue the control flow. Complex model operations abstract from and invoke adaptation activities modeled in other FLDs, which will be discussed in Section 4.2. The control flow between operations is specified by solid arrows and can be exclusively branched by a decision node (diamond element) and conditions. The language for these conditions refers to counter and timing information about the execution of the feedback loop, which is discussed in detail in [Vogel and Giese (2013)]. Thus, conditions use generic information about EUREMA concepts to branch the control flow while the different exit compartments of operations may depend on information only known internally to user-defined runtime models and operation implementations. Model operations work on runtime models represented by rectangles and the usage of models as input or output is depicted by dotted arrows. Finally, an FLD model can be used as a runtime model within another FLD, which will be discussed in Section 5.4.

To support the engineer’s perception of FLDs, the elements can be substantiated by labels or stereotypes. Model operations are assigned to the typical steps of a feedback loop: Monitor, Analyze, Plan, and Execute. Models are stereotyped based on the purpose they serve in self-adaptive software, which resulted from the categorization of runtime models discussed in Section 2: MonitoringModel, ExecutionModel, CausalConnectionModel, ReflectionModel, EvaluationModel, ChangeModel, and AdaptationModel. Finally, the usage of models by operations is substantiated to creating, destroying, writing, reading, and annotating models. While reading a model does not have any side effects, writes modify the model in a way that potentially affects the adaptable software, and annotations to a model enrich a model without affecting the software.

With the FLD of Figure 5, we modeled the extended self-repair scenario from [Vogel and Giese (2010)]. The Update and Effect operations use triple graph grammar rules (TGG Rules) that specify by means of model transformation rules how the Architectural Model reflecting the adaptable software (mRUBiS) is synchronized with the software. Thus, monitoring the software, the Update operation keeps the Architectural Model up-to-date. The Check for failures operation performs analysis by applying Failure analysis rules on the Architectural Model. These rules define checks to identify critical failures. If no failures are found, the feedback loop terminates in the state Analyzed. Otherwise, adaptation is required to repair them. At first, a decision is made whether further analysis is needed. This is the case when the condition holds, which checks whether the last execution of the Check for failures operation that has identified no failures happened more than five consecutive executions in the past. Thus, the past five runs of the loop did not repair the failures. The plan activity uses the analysis results annotated by the analyze operations to the Architectural Model to select suitable Repair strategies. The selected strategies change the Architectural Model to prescribe a reconfiguration of the software. This reconfiguration is executed by the Effect operation that synchronizes the Architectural Model changes to the software, which terminates one run of the feedback loop.

This example illustrates how adaptation activities can be considered as abstract model operations working on runtime models. Besides the control flow between the operations, the interplay between operations and runtime models is made explicit as the models are the basis for coordinating the activities. Thus, this interplay is similar to dependencies among adaptation activities that are relevant for properly specifying and executing a feedback loop.

4.2 Modularizing Feedback Loop Diagrams

Besides modeling a feedback loop in a single FLD, EUREMA supports modular specifications. Individual adaptation activities are specified in distinct FLDs that can be composed to form a feedback loop. This provides further abstractions that ease the modeling and perception of feedback loops by engineers. Parts of a loop can be abstracted in dedicated FLDs and referenced by other FLDs. This additionally supports reusability of such parts.

Figure 6: FLD for the self-repair analysis
Figure 7: FLD invoking the Self-repair-A FLD

For instance, the analyze activity of the self-repair feedback loop (cf. Figure 5) can be specified in an FLD called Self-repair-A (cf. Figure 7). This activity has one initial state (Start) and two final states reflecting whether failures have been identified (Failures) or not (OK). This FLD can be (re)used by other FLDs such as the Self-repair loop shown in Figure 7. Therefore, we introduce the concept of a complex model operation. Such an operation defines a signature to synchronously invoke an FLD by referring to the initial and final states of the FLD. In the example, based on the initial and final states of the Self-repair-A FLD, the complex model operation Analyze in Figure 7 has one entry (Start) and two exit compartments (Failures and OK). Thus, initial and final states of an FLD are mapped to entry and exit compartments, respectively. This ensures that the feedback loop using a complex operation can properly invoke an FLD and properly resume execution after the invocation. If an FLD specifies exactly one initial or final state, the entry or exit points for execution are uniquely defined and the entry or exit compartments of the complex operation can be omitted. In the example, the entry compartment of the complex model operation could have been omitted.

Moreover, the complex operation Analyze uses the Architectural Model (cf. Figure 7) that can be considered as a parameter when invoking the Self-repair-A FLD while the other runtime models used in the Self-repair-A FLD are encapsulated by this FLD. Considering self-adaptive software that evolves throughout its lifetime, EUREMA adopts a dynamic typing approach in contrast to a static and explicit type system for FLDs and operations. Finally, a complex operation is labeled with an icon to distinguish it from basic model operations in FLDs and to reveal that it invokes another FLD. Thus, a complex operation used in an FLD abstracts from another FLD and it synchronously invokes the abstracted FLD when being executed.

Overall, the specifications of the self-repair feedback loop as the FLDs of Figure 5 or Figures 7 and 7 are equivalent considering functionality. The only difference is the number of used FLDs, which is motivated by design decisions concerning abstraction and modularity. Besides the analyze activity, each of the four MAPE activities can be specified in distinct FLDs and a high-level FLD integrates them to a feedback loop. In general, the depth of abstraction and invocation relationships is not restricted. This leverages different abstraction levels for modeling and further assists engineers in understanding feedback loops.

4.3 Modeling Multiple Feedback Loops and their Coordination

Figure 8: FLD for Self-optimization

We discuss now how EUREMA supports multiple feedback loops in self-adaptive software, particularly to handle multiple concerns such as self-repair or self-optimization. Each concern is managed by an individual feedback loop since each concern requires its specific runtime models and operations. Therefore, we extend our example of the self-adaptive software employing a self-repair feedback loop (cf. Section 4.2) with a self-optimization feedback loop as specified by the FLD in Figure 8. Similar to the self-repair loop, the Update and Effect operations synchronize the Architectural Model with the adaptable software. Besides the Architectural Model, the analyze and plan activities use a Queueing Model to identify bottlenecks in the adaptable software and reasonable values for parameters given by the Parameter variability model to adjust the configuration of the software, which aims for resolving the bottlenecks. Finally, the self-optimization loop has two initial states either initiating the loop with the monitor or the analyze activity.

In general, EUREMA supports the specification of multiple feedback loops by distinct FLDs. However, employing multiple loops raises questions of possible interferences. Concerns such as failures and performance are typical competing, like healing a failure results in a system with decreased performance. Such interferences require coordination. In EUREMA, the coordination of multiple feedback loops is explicitly modeled with an FLD that synchronizes the execution of the feedback loops. In the following, we discuss two basic design alternatives for coordinating the self-repair and self-optimization feedback loops.

4.3.1 Sequencing Complete Feedback Loops

A simple way to coordinate two feedback loops is to execute them sequentially. This is specified by the Self-management-1 FLD in Figure 9 that uses complex model operations to synchronously invoke the individual feedback loops. In this self-management example, a higher priority is assigned to repairing failures than to optimizing performance since optimizing the performance of a failing system is not reasonable. Therefore, the self-repair feedback loop is executed before the self-optimization loop.

Figure 9: FLD for Self-management-1

In the FLD, Repair invokes the self-repair loop (Figure 7) to start execution in the state Monitor. Thus, the monitor and analyze activities are carried out to update and check the Architectural Model for failures. If no failures are identified, the self-repair loop does not plan and execute any adaptation and terminates in the state Analyzed. In this case, the subsequent self-optimization loop may immediately start with the analyze activity because the self-repair’s monitor has already updated the shared Architectural Model. Thus, the complex operation Optimize invokes the self-optimization loop (Figure 8) to begin execution in the state Analyze (cf. the control flow connecting the Repair and Optimize operations). If no bottlenecks have been identified, the self-optimization feedback loop terminates in the state Analyzed. Otherwise, it performs the plan and execute activities, and terminates in the state Executed.

On the other hand, if the self-repair feedback loop identifies failures, it plans and executes an adaptation to the adaptable software and terminates in the state Executed. This requires that the subsequent self-optimization feedback loop (Figure 8) performs monitoring to observe the effects of this adaptation. Therefore, Optimize invokes the self-optimization loop to begin execution in the state Monitor (cf. the control flow connecting the Repair and Optimize operations). After carrying out the monitor and analyze activities, the self-optimization feedback loop either terminates or, if required, plans and executes an adaptation.

This coordination design synchronizes different feedback loops by sequentially executing them based on priorities and by using the adaptable software for synchronization. Thus, an adaptation performed by one feedback loop is executed to the software before another loop starts execution with the monitor activity to observe the adaptation effects. However, if a feedback loop does not perform any adaptation of the reflection model and software, the subsequent loop may skip the monitoring and start with the analyze activity since the previous loop already performed the monitoring to update the shared reflection model.

4.3.2 Sequencing Adaptation Activities of Feedback Loops

The other design alternative for coordinating multiple feedback loops synchronizes them in shared monitor and execute activities and sequentially executes the individual analyze and plan activities. For the example, this is specified by the Self-management-2 FLD in Figure 10. The Update and Effect operations synchronize the Architectural Model with the adaptable software. This model is shared by the individual, concern-specific analyze and plan activities of the self-repair and self-optimization loops (cf. complex operations RepairAP and OptimizeAP) that are specified in individual FLDs shown in Figure 11. Thus, analysis and planning for the self-repair are executed before the analysis and planning for the self-optimization. The Architectural Model is only modified by the self-repair’s plan activity if the related analyze activity has identified failures. These modifications are a planned adaptation to repair the failures, i.e., they are applied in the model but not effected to the adaptable software. If the model has not been modified, there are no conflicting adaptations possible. Otherwise, the adaptations proposed for the self-repair must be handled by the subsequent analyze and plan activities for the self-optimization, which requires coordination.

Figure 10: FLD for Self-management-2
Figure 11: Analyze and plan activities of the self-repair (left) and the self-optimization (right)

While EUREMA coordinates the execution of the individual activities/operations, in this case by strictly sequencing them for self-repair and self-optimization, the implementations of these operations are responsible for establishing a consensus on conflicting adaptations, in this case by considering the adaptation proposed for self-repair as an invariant for the self-optimization. In general, a consensus can be reached, for example, by mechanisms based on utility functions [Cheng et al. (2006)] or concepts of coordination and agreement in distributed systems such as voting [Coulouris et al. (2011)]. Such mechanisms are handled by the implementations of the model operations as they typically depend on internals of user-defined runtime models that are black boxes for EUREMA. Thus, the concrete mechanisms are transparent for EUREMA that focuses on providing execution support for these operations.

Considering the FLD in Figure 10, when the self-optimization’s analyze and plan activities terminate, the Effect operation is executed if adaptations are proposed in the Architectural Model by the self-repair’s or the self-optimization’s plan activities. Thus, at least one of the complex model operations RepairAP or OptimizationAP must terminate in the state Planned. Otherwise, the Self-management-2 module terminates in the state Analyzed because no critical failures and no bottlenecks have been identified, which does not require any adaptation.

5 Layer Diagrams

While FLDs support the behavioral specification and coordinated execution of feedback loops, EUREMA so far does not structurally reflect all FLDs employed in a self-adaptive software as well as their interrelationships and triggering. Therefore, we extend EUREMA in this article with layer diagrams (LDs) that provide an architectural view. This view refers to an instance situation of the software and it captures the employed feedback loops, their relationships to each other and to the adaptable software, and their triggering conditions.

This is exemplified for the self-repair example by the LD in Figure 13. It specifies that an instance of the Self-repair feedback loop as specified by the corresponding FLD (cf. Figure 7) is located at Layer-1 and directly senses and effects the running :mRUBiS instance at Layer-0. As defined by the concrete syntax (cf. Figure 13), partitions in LDs represent the layers of the self-adaptive software, which contain modules. An instance of an FLD constitutes a megamodel module that encapsulates the details of a concrete feedback loop or adaptation activities. Such a module is depicted as a package with a white tab in an LD since EUREMA provides white-box views of megamodel modules by means of the FLDs. In contrast, a package with a black tab represents software modules that are not specified by EUREMA, like an instance of the adaptable software. Sense and effect relationships between modules are reflected by dotted arrows, either labeled with r (for reading the sensed module) or w/a (for writing/annotating the effected module), respectively. A sense relationship is labeled with a triggering condition for the sensing module, which will be discussed in Section 5.1.

Figure 12: LD for Self-repair
Figure 13: Concrete syntax for LDs

Usage relationships between megamodel modules are modeled in LDs to make the dependencies between FLDs explicit. The example LD (cf. Figure 13) explicitly shows that the :Self-repair module defined by the FLD in Figure 7 uses the :Self-repair-A module defined by the FLD in Figure 7. A use relationship is reflected by a solid arrow and it is labeled with the name of the corresponding complex model operation (Analyze in this example) to bind this operation of the invoking module (:Self-repair in this example) to the concrete module (:Self-repair-A in this example) to be invoked. The same mechanism is used to bind basic model operations to their implementations that are black boxes for EUREMA and therefore modeled as software modules in LDs. An FLD specifies when a basic model operation should be executed, which runtime models are used as input and output, and the operation’s return states while the concrete implementations of such operations have to be provided by software modules. When executing a basic operation as part of a megamodel module (FLD instance), EUREMA invokes the software module to which the operation is bound by a use relationship in the LD and labeled with the operation name. So far and in the following examples, we omit the modeling of software modules implementing basic model operations in LDs since they are just required for binding the operations to their implementations. This is relevant for the execution but they provide no further information relevant for the design of feedback loops.

Finally, the LD shows by the labels M..PE and A that the :Self-repair module realizes the monitor, plan, and execute activities and the :Self-repair-A module the analyze activity. Inspired by SEfSAS2-decentral, we use such labels to indicate which adaptation activities are realized by a megamodel module as defined in an FLD. Thus, an FLD instance encapsulates the behavioral specification of a feedback loop or individual adaptation activities in a megamodel module. The LD considers such modules as black boxes and describes in which layers they are located and the relationships to other megamodel or software modules. Therefore, an LD provides an abstract and structural view, which supports the architectural design of self-adaptive software and complements the FLDs as behavioral views of feedback loops.

5.1 Triggering Conditions for Feedback Loops

Besides specifying a feedback loop with FLDs, a triggering condition is required to determine when an instance of the feedback loop should be executed. In EUREMA, we especially consider the occurrences of events as triggers. These events are emitted by modules that are either adaptable software or feedback loop instances. A triggering condition for a feedback loop instance may only refer to events emitted from those modules that are sensed by this instance. This avoids that the feedback loop instance is triggered by events related to modules that are of no interest to the instance. Thus, we specify triggering conditions in LDs by annotating them to the corresponding sense relationships that reveal the flow of events from one module to another module. This is exemplified by the LD in Figure 13 that defines a triggering condition for the :Self-repair feedback loop sensing the :mRUBiS system. The condition RtException; 10s; Monitor; defines that the :Self-repair loop starts execution if the :mRUBiS system emits an event of type RtException notifying about a runtime exception, and when ten seconds since the last execution of this loop have expired. Finally, Monitor points to the initial state of the feedback loop (cf. Figure 7), in which the execution starts.

EUREMA supports a simple language for triggering conditions consisting of three parts: events;period; initialState;. The first part (events) refers to a list of events that have to be modeled in EUREMA. Therefore, the EUREMA metamodel (cf. Section 6) provides the concepts of Event and EventType to model events in a hierarchy of event types. At runtime, these events as part of triggering conditions are matched against events actually emitted by modules. For instance, in our prototype we employ an infrastructure that makes software realized with Enterprise Java Beans 3 technology, such as our mRUBiS system [Vogel (2013)], observable and adaptable and that emits events using the Java Messaging Service (JMS) to notify about changes in the running software [Vogel and Giese (2010)]. Such JMS events are then matched against the events modeled in EUREMA and used in triggering conditions. If a match has been identified, the trigger of the feedback loop instance is activated.

The second part (period) defines the minimal time period between two consecutive runs of the feedback loop instance, which is measured as the time elapsed between the termination of the previous run and the beginning of the next run. Thus, if the required event that activates the trigger occurs before the specified time period has elapsed, the next run will be delayed until the period eventually has elapsed. Delaying the execution avoids thrashing effects due to the proliferation of events and it allows the adaptation being executed by the previous run to take effect in the adaptable software. Likewise, selecting specific events in the first part of the triggering condition also serves as a filter that avoids the execution of a loop instance for every event emitted by the sensed module. Finally, the third part (initialState) just refers to the initial state, in which the instance should start its execution.

The first two parts of a condition are optional, but one of them must be specified. If no events are specified, the period must be defined, which results in a trigger that periodically executes the feedback loop instance. If no period is defined, the events must be specified and the trigger executes the instance when the corresponding events have occurred and the current run of the instance has terminated. In EUREMA, a feedback loop instance is not reentrant, and therefore, any events that occur while the instance is running are queued. Thus, there are no concurrent executions of the same feedback loop instance. While an event-driven trigger supports reactive adaptation, a periodical trigger makes proactive adaptation possible by executing the loop instance before the adaptable software emits any event.

5.2 Variability Modeling

Figure 14: LD with variability
Figure 15: LD for the independent execution

Encapsulating feedback loops or individual adaptation activities defined by FLDs in megamodel modules and explicitly modeling such modules and their relationships in LDs reveals variation points in the adaptation engine. Such variability can be made visible in LDs and exploited to switch between variants, either during the design or dynamically at runtime.

For instance, having encapsulated the analyze activity of the self-repair feedback loop in a dedicated module (cf. :Self-repair-A in the LD of Figure 13), we assume that we have modeled an additional analyze activity (Self-repair-A2) in a distinct FLD, which employs a different analysis technique than Self-repair-A. Both activities are then alternative analyses to be used by the self-repair feedback loop. This constitutes a variation point in the architectural design reflected in the LD in Figure 15. If the FLDs of both alternatives have the same signature (cf. Section 4.2), both of them can be used by the same complex model operation. Then, to switch between these alternatives, it is sufficient to change the binding between the complex model operation and the megamodel module, for example, by re-routing the use relationship Analyze to point to :Self-repair-A2 instead of :Self-repair-A in the LD.

EUREMA applies the same idea to leverage variability for basic model operations. LDs capture alternative software modules implementing a basic operation and the binding of the operation to one alternative. Similar to changing a binding of a complex operation to a megamodel module, the binding of a basic operation to a software module can be changed.

In general, such variations points of modules reify architectural variability of feedback loops in LDs. This variability can be exploited to specify and evaluate alternative feedback loop designs or to adjust feedback loops at runtime by switching between variants.

5.3 Modeling Multiple Feedback Loops

Employing multiple feedback loops in an adaptation engine, the relationships between these feedback loops should be captured, particularly concerning the execution. Therefore, it should be visible at the architectural level if multiple feedback loop instances are executed independently from each other or in a coordinated manner. Modeling the coordinated execution with FLDs has been discussed in Section 4.3, however, without considering the architectural level and the independent execution that cannot be explicitly covered by FLDs.

5.3.1 Independent Execution of Multiple Feedback Loops

Based on the example of employing a self-repair and a self-optimization feedback loop (cf. Section 4.3), we assume that there are no interferences between these loops such that they can be executed independently. Thus, instances of both loops have individual triggers that might be activated at the same time and the instances might even run concurrently. This is specified by the LD in Figure 15 showing two independent feedback loop instances sensing and effecting the mRUBiS system. While the triggering condition of the :Self-repair module has been discussed in Section 5.1, the :Self-optimization module should be triggered in its initial state Monitor when the load on the mRUBiS system increases, causing a LoadIncrease event, and with a period of 60s. Based on the different triggering conditions, both modules run independently from each other and without any direct interactions as these modules are not interrelated in the LD.

In general, an LD explicitly shows if multiple feedback loop instances are employed and executed independently. This would not be visible solely using FLDs as they do not reflect the triggering conditions and all of the modules employed in the adaptation engine.

5.3.2 Coordinated Execution of Multiple Feedback Loops

Though the independent execution of multiple feedback loops is conceivable, there are sometimes interferences between them that have to handled by coordination. This has been discussed and modeled by FLDs in Section 4.3, which, however, do not make the employed feedback loop instances and their coordinated execution visible at the architectural level. We have discussed two basic mechanisms to coordinate two feedback loops, either by completely sequencing them (cf. Section 4.3.1) or by sequencing the individual analyze and plan activities (cf. Section 4.3.2). Both mechanisms are specified by FLDs (Self-management-1 and Self-management-2, respectively) that invoke the individual FLDs defining the feedback loops by complex model operations.

Figure 16: LD for Self-management-1
Figure 17: LD for Self-management-2

To make this coordination explicit at the architectural level, LDs as shown in Figures 17 and 17 are used. They show the modules whose execution is coordinated through invocations by the :Self-management-1 and :Self-management-2 modules. Therefore, the use relationships in the LDs make the invocation relationships among the modules explicit such as the Repair relationship showing that the :Self-management-1 module invokes the :Self-repair module. Moreover, the modules :Self-management-1 and :Self-management-2 realizing the coordinated execution require triggering conditions as shown in the LDs. These conditions combine the individual conditions of the self-repair and self-optimization feedback loops discussed before.

Finally, the LD of Figure 17 highlights that the :Self-management-1 module does not perform any adaptation activity since it has no label in contrast to the :Self-optimization and :Self-repair modules with their labels MAPE and M..PE. But the other example (cf. Figure 17) shows that the :Self-management-2 module performs the monitor and execute activities (M..E) while the analyze and plan activities (AP) are performed by the other modules. Thus, an LD reflects all employed feedback loop instances and the modules coordinating the execution of these instances. This makes the coordinated execution visible at the architectural level.

5.4 Modeling Layered Feedback Loops

As argued in Section 2, there are particular cases, in which feedback loops are layered. A feedback loop at a higher layer adapts a feedback loop at the layer directly below. This requires adaptable feedback loops and appropriate reflections of these feedback loops.

Feedback loops specified by EUREMA are adaptable by construction because EUREMA models as feedback loop specifications and visualized by FLDs are kept alive at runtime and they are executed by an interpreter. The EUREMA interpreter is able to cope with dynamic changes of EUREMA models at runtime and even while executing these models. EUREMA supports dynamic adaptation of feedback loops with respect to the FLD concepts. Thus, EUREMA supports dynamically adjusting runtime models used within a feedback loop, for example, to replace the change models that define the planning. Model operations can be adjusted by adding, removing, or replacing them. This typically requires adapting the usage of runtime models and the control flow. Besides such structural adaptations, the control flow can be adjusted by parameter adaptation of conditions used for decision nodes.

Such adaptations of feedback loops are conducted by other feedback loops operating at higher layers. In EUREMA, the modeling of higher-layer loops is similar to modeling any feedback loop as discussed in Section 4. However, a particular aspect is the reflection model that represents the lower-layer loop and that is needed by the higher-layer loop for adaptation. Therefore, two variants corresponding to the idea of procedural and declarative reflection [Maes (1987)] are supported, which will be discussed for the following example.

The self-adaptive software with its repair feedback loop as specified by the FLD in Figure 7 and the LD in Figure 13 automatically heals failures in the adaptable software by applying pre-defined repair strategies. However, these strategies need not to be able to handle all failures since it is usually impossible to anticipate all kinds of failures when developing and deploying these strategies given the uncertainty in self-adaptive systems and their environments. Thus, the repair strategies defined in a runtime model have to be maintained and adapted at runtime. This task can be assigned to a higher-layer feedback loop that synthesizes new strategies on demand and provides them to the self-repair feedback loop.

5.4.1 Procedural Reflection

Keeping EUREMA models alive at runtime, the models specifying and executing the lower-layer feedback loop can be directly used as a reflection model by the higher-layer loop. Thus, the higher-layer loop does not maintain a separate representation and one representation is used to specify, execute, and adapt the lower-layer loop.

For the example, the corresponding higher-layer loop is defined by the Self-repair-strategies FLD in Figure 19. It contains the reflection model feedbackLoopModel, which is labeled with an icon to highlight that this model is directly an EUREMA model as visualized by an FLD, particularly, the FLD that specifies and executes the self-repair loop (cf. Figure 7). This model is used to check the success rate of the repair strategies and to synthesize new strategies that are directly provided to the self-repair loop by changing the model. Applying procedural reflection, the causal connection is ensured by construction and there is no need for explicit monitor and execute activities in the Self-repair-strategies loop. These activities are implicitly realized by the analyze and plan activities (cf. related stereotypes in Figure 19).

At runtime, the feedbackLoopModel reflecting the self-repair feedback loop has to be bound to the specific FLD instance executing this loop. This is defined by the LD in Figure 19 showing the :Self-repair-strategies module at Layer-2 that senses and effects the :Self-repair module at Layer-1. The binding of the feedbackLoopModel to the specific FLD instance of the :Self-repair module is defined by the use relationship having the name as the reflection model. To adapt the self-repair loop, the :Self-repair-strategies module operates on this FLD instance, whose specification is shown in Figure 7. Thereby, it also operates on the instance of the Self-repair-A FLD shown in Figure 7 because this FLD is used and therefore included by the Self-repair FLD. In general, to dynamically adapt a lower-layer feedback loop, a higher-layer loop changes the FLD instance that specifies and executes the lower-layer loop. Thus, all FLDs shown in this article are initial specifications of feedback loops since they are kept alive at runtime and they might be dynamically changed at runtime.

Figure 18: FLD for Self-repair-strategies
Figure 19: LD for Self-repair-strategies

The triggering condition of the :Self-repair-strategies module (cf. Figure 19) is similar to the conditions discussed in Section 5.1. It refers to an event, namely After[Deep check for failures], emitted by the sensed modules, particularly by the EUREMA interpreter when executing the :Self-repair and :Self-repair-A modules. In general, the interpreter synchronously emits two types of events when executing an FLD instance: Before[opName] and After[opName] events are emitted before and respectively after any model operation is executed while opName refers to the name of the operation. This supports intercepting the execution of a (lower-layer) feedback loop to synchronously execute another (higher-layer) feedback loop. In the example, the :Self-repair-strategies module is triggered after executing the self-repair’s Deep check for failures operation. This is the case if more than five consecutive runs of the self-repair loop were not able to repair the failures, which indicates the need for new repair strategies.

The advantage of directly using EUREMA models as reflection models of feedback loops is that the causal connection is ensured by construction. This avoids the development of monitor and execute activities for higher-layer loops, which create and maintain reflection models of lower-layer loops. However, by using the same model of a loop for executing as well as adapting it, the adaptation cannot be decoupled from the execution. Thus, any adaptation performed by the higher-layer loop is instantaneously enacted to the lower-layer loop.

5.4.2 Declarative Reflection

In declarative reflection, a higher-layer feedback loop employs a user-defined reflection model of the lower-layer feedback loop. Thus, two representations of the lower-layer loop are maintained, one for specifying and executing it, and one for adapting it. To realize the example we used for discussing procedural reflection, the higher-layer loop is specified by the FLD in Figure 21. The monitor activity observes the self-repair loop and maintains the Self-repair Model that reflects the self-repair loop. Using this reflection model, the analyze activity checks the success rates of the current repair strategies. The plan activity synthesizes new strategies that replace the current ones in the reflection model. This replacement is enacted to the :Self-repair module (instance of the FLD from Figure 7) by the execute activity that replaces the Repair strategies runtime model in this module.

Figure 20: FLD for Self-repair-strategies-2
Figure 21: LD for Self-repair-strategies-2

As defined by the LD in Figure 21, an instance of the Self-repair-strategies-2 feedback loop at Layer-2 senses and effects the :Self-repair feedback loop including the :Self-repair-A activity at Layer-1. A particular aspect of this layering is that the higher-layer loop utilizes a user-defined reflection model (cf. Self-repair Model in Figure 21) such that no binding of this model has to be specified in the LD. This model is user-defined because its metamodel can be user-defined and it is maintained by user-defined model operations for the monitor and execute activities. Thus, the engineer may decide which information about the lower-layer loop is covered by the reflection model as well as the abstraction level of the model. However, she must ensure the causal connection between the reflection model and the reflected feedback loop by defining and implementing model operations for the monitor and execute activities.

Therefore, sensors and effectors provided by EUREMA can be used to observe and adjust feedback loops by means of the EUREMA models. For sensing EUREMA models, they can be queried and events notifying about the execution and changes of these models are emitted by the EUREMA interpreter and the MDE infrastructure, in particular the Eclipse Modeling Framework (EMF). For effecting EUREMA models, basic means to change models are provided such as changing attribute values, or adding and removing nodes and relationships.

The advantage of user-defined reflection models is that the higher-layer feedback loop may run decoupled from the lower-layer loop since the reflection model is kept separate from the EUREMA model specifying and executing the lower-layer loop. However, the disadvantage is that both representations have to be synchronized to each other to ensure the causal connection. Nevertheless, this synchronization can be simplified since both representations are models conforming to MDE principles, that is, they have potentially different metamodels but the same meta-metamodel. Thus, one-to-one copies of EUREMA models can be directly provided as reflection models or MDE techniques such as model synchronization to keep both models consistent to each other can be employed. The applicability of such techniques for runtime reflection models has been shown in [Vogel et al. (2010), Vogel and Giese (2010)].

Overall, LDs explicitly reflect the feedback loops at individual layers and whether procedural or declarative reflection is employed among them. If a reflection model is bound to a megamodel module (FLD instance) by a use relationship in the LD, procedural reflection is employed. If no such binding is defined, declarative reflection is employed.

5.5 Off-line Adaptation

As motivated in Section 2, self-adaptive software must support the co-existence of on-line and off-line adaptation to ensure its long-term evolution. On-line adaptation refers to activities performed by the adaptation engine, and off-line adaptation to activities performed by engineers to maintain the software. Evolving self-adaptive software considers scenarios such as (1) adding or removing feedback loops from the running software, and changing (2) running feedback loops, (3) legacy feedback loops, and (4) the running adaptable software. The rationale of our approach to the co-existence is to interpret such evolution steps as feedback loops split up into on-line monitor and execute and off-line analyze and plan activities.

We support on-line monitoring by observing and exporting snapshots of EUREMA models including the runtime models that are used within the feedback loops. Since EUREMA models as visualized by FLDs and LDs are directly used for executing adaptation engines, they innately reflect the running feedback loops and the runtime architecture of the self-adaptive software. These snapshots are transferred to the development environment and support the engineer in analyzing the software and planning an adaptation offline. Planning includes modeling the enactment of the adaptation with EUREMA. The resulting models are loaded up to the EUREMA interpreter that dynamically instantiates and executes these models. This executes the adaptation on-line to the running software and accomplishes the evolution step. A particular issue is to execute on-line such an adaptation while feedback loops are operating in the adaptation engine. This requires a coordinated execution, which is explicitly specified by EUREMA models. In the following, we discuss EUREMA’s support for the co-existence using the four evolution scenarios we just outlined above.

5.5.1 Adding and Removing Feedback Loops

Assuming the example self-adaptive software that only employs the self-repair feedback loop, we have discussed the need for a higher-layer feedback loop that maintains the repair strategies in Section 5.4. This need should be addressed by an off-line adaptation that equips the software with the higher-layer loop.

Observing and analyzing the running self-repair feedback loop by means of the EUREMA models (LD in Figure 13 and instances of the FLDs from Figures 7 and 7), their execution, and the contained runtime models, an engineer identifies the need to maintain the repair strategies as failures are continuously identified. Having developed mechanisms to automatically synthesize repair strategies, the engineer may delegate the maintenance of the strategies to the adaptation engine by specifying offline a corresponding feedback loop with EUREMA. This results in the FLD of Figure 19 that was discussed in Section 5.4.

Figure 22: A rule integrating a module

The engineer loads up this FLD to the adaptation engine together with a rule defining how this FLD should be integrated as a megamodel module into the engine’s architecture. The architecture is reflected by the LD in Figure 13 and the integration is defined by a graph transformation rule111EUREMA does not define or prescribe the language for such integration rules. Theoretically, any mechanism can be used that specifies changes of a model. We apply a mechanism based on graph transformations. (cf. Figure 22) changing this LD. The rule’s elements that are annotated with ++ are added to the LD if a match for its elements having no annotation is found in the LD. Thus, the EUREMA interpreter instantiates the uploaded FLD to the :Self-repair-strategies module and applies the rule. This identifies a match for the :Self-repair module at Layer-1, adds the :Self-repair-strategies module at Layer-2, establishes the sense and effect relationships between both modules, and binds the feedbackLoopModel used in the :Self-repair-strategies module to the :Self-repair module (cf. Section 5.4). Overall, this results in a three-layer architecture reflected by the LD in Figure 19. While a module is integrated into the engine, the already existing modules may operate without any impact except of delays. Such delays are caused by supporting consistent architectural reconfiguration in a quiescent state. Then, the execution of a new module is coordinated with the other modules by a triggering condition as defined in the integration rule (e.g., Figure 22). As discussed in Section 5.4, such a trigger for a megamodel module that senses another megamodel module enables the exclusive execution by intercepting the execution of the lower-layer module to run the higher-layer module. This enables the exclusive and therefore synchronized execution of the modules to coordinate the online execution of an offline adaptation with running feedback loops.

In general, an LD is used at runtime as a procedural reflection model of the self-adaptive software, which can be dynamically changed to adjust the adaptation engine. This is accomplished in the context of off-line adaptation by applying an integration rule (cf. Figure 22) while it is conceivable to employ another adaptation engine on top of the engine reflected by the LD. The following dynamic changes of adaptation engines are supported. Layers and megamodel modules (FLDs instances) can be added and removed from the engine. An individual module can be adapted by changing the bindings between its complex model operations and other megamodel modules, and between its basic model operations and software modules implementing these operations. This has been discussed in Section 5.2 in the context of variability that can now be exploited at runtime. These adaptations change the number and composition of modules in flexible layers of the engine. Finally, LDs reflect the triggering conditions of megamodel modules that can be dynamically changed.

5.5.2 Changing a Running Feedback Loop

This scenario addresses changes of an already running feedback loop by an offline adaptation similar to a patch. Thus, in contrast to the previous scenario, the uploaded FLD does not specify a feedback loop but a patch process. For instance, an engineer has developed offline new repair strategies and she specifies a patch process to just replace the strategies employed in the running self-repair feedback loop. The upload, integration, and execution of this FLD is identical to the previous scenario. The only difference is that the patch process is executed only once and then removed from the adaptation engine. This is accomplished by specifying a destruction state in the FLD (cf. Section 4.1). This scenario exemplifies that by dynamic layers, feedback loops running in a certain layer can be dynamically changed by megamodel modules temporarily operating at the next higher layer to enact an off-line adaptation. Due to the similarities with the previous scenario, we refer to the technical report [Vogel and Giese (2013)] for more details.

5.5.3 Support for Adapting Legacy Feedback Loops

EUREMA provides basic support for adapting legacy software modules realizing feedback loops. EUREMA handles such modules as black boxes since they are not specified by FLDs and it just addresses their activation by reflecting them in LDs. If it is possible to trigger legacy modules similar to EUREMA feedback loops, the EUREMA interpreter can control their activation. Therefore, the interpreter can decommission legacy modules to migrate the adaptation engine to megamodel modules specified by EUREMA. This migration can be realized by off-line adaptation, especially to add and remove feedback loops (cf. Section 5.5.1). For more details on triggering legacy modules we refer to the technical report [Vogel and Giese (2013)].

5.5.4 Changing the Adaptable Software

Besides the adaptation engine, off-line adaptation may directly target the running adaptable software. For instance, a component of the adaptable software should be replaced as an improved version has been developed off-line due to maintenance requests. Since the employed self-repair feedback loop (cf. Figure 13) is not able to replace a specific component, such an update has to be realized by another module.

Therefore, the engineer models the update by the FLD shown Figure 23. By monitoring, the Create model operation creates the Architectural Model reflecting the adaptable software. This model is used to reconfigure the architecture at the model level by applying rules defining the replacement of the specific component. The Effect operation

Figure 23: Updating the adaptable software

loads the new component, executes the reconfiguration prescribed in the model to the adaptable software, and finally destroys the architectural model. Similar to the scenario that patches a feedback loop (cf. Section 5.5.2), this FLD is loaded up, integrated, and executed once in the adaptation engine. Moreover, the execution is synchronized with the running self-repair feedback loop to avoid interferences while the adaptable software is reconfigured by the new module that is removed from the engine after the reconfiguration. As discussed for the different scenarios, by reflection, dynamic layers, and dynamically (un)loading of FLD, EUREMA supports off-line adaptation to evolve self-adaptive software, particularly in a way that has not been anticipated when initially deploying the software.

6 Metamodel and Interpreter Implementation

While the EUREMA metamodel and its execution semantics are discussed in our technical report [Vogel and Giese (2013)] due to space constraints, we briefly discuss the implementation of the metamodel and interpreter in this section.

Both have been developed with the Java-based Eclipse Modeling Framework (EMF). The stereotypes and labels of FLD and LD elements are not directly supported by the metamodel since they do not influence the execution semantics and therefore the EUREMA interpreter. However, they are introduced in EUREMA by a basic profile mechanism to use them in the EUREMA editor when modeling FLDs and LDs. The language for expressing conditions to exclusively branch the control flow in FLDs is defined by a grammar, implemented with the Java Compiler Compiler (JavaCC), and embedded in EUREMA.

Our interpreter implementation only relies on EMF and it may run standalone and decoupled from the Eclipse workbench. Nevertheless, the interpreter provides full support for user-defined, EMF-based runtime models used within feedback loops. For example, the interpreter manages the handling of runtime models as input or output of model operation executions. Moreover, EUREMA models as well as user-defined runtime models can be dynamically (un)loaded and exported as snapshots for off-line use. Concerning EUREMA models, the interpreter currently provides full support for executing FLDs and almost full support for the LD. So far, multiple and layered feedback loops as defined in an LD can be executed but the LD is only implicitly maintained to support off-line adaptation [Hanysz (2013)]. Currently, we are addressing this aspect by making the LD an explicit runtime model.

7 Discussion of Design Decision and Requirements Coverage

In this section, we discuss EUREMA by means of its fundamental design decisions that lead to the presented language and its coverage of the requirements identified in Section 2.

7.1 Design Decisions

The language design of EUREMA is motivated by the requirements for engineering self-adaptive software (cf. Section 2). With the FLD, we aim for an explicit specification of feedback loops (R1). According to the MAPE-K blueprint, a feedback loop consists of adaptation activities sharing knowledge. This calls for language concepts that describe these activities and the knowledge that we refined to a set of runtime models. This further requires concepts that make runtime models first class citizens of the models that specify feedback loops. Therefore, we applied generic megamodel concepts to the language design of FLDs. A megamodel refers to a model that contains other models and relationships between these models. The relationships can be substantiated to operations that manipulate these models [Barbero et al. (2007), Bézivin et al. (2003), Bézivin et al. (2004), Favre (2005)]. Thus, models are first class elements of a megamodel. Consequently, we consider an FLD as a megamodel describing the adaptation activities as operations that work on runtime models (R7). Hence, operations and runtime models are the main language concepts of FLDs. To make the FLDs executable (R6) and to address the intra-loop coordination (R2), we extended these concepts with the control flow among the activities and the usage of models by the activities. This explicitly defines the workflow of activities and the data that is consumed or produced by these activities. Using these concepts, an individual feedback loop can be specified by FLDs. Moreover, these concepts are sufficient to specify multiple feedback loops and their coordinated execution such that no further concepts are required for inter-loop coordination (R4). Finally, we designed FLDs to be runtime models. Keeping feedback loop specifications alive at runtime and interpreting them leverage adaptable feedback loops in layered architectures (R9) and the provision of reflection models for such loops. This promises flexible adaptation engines.

While the FLDs address the behavioral specification of feedback loops, they do not provide a structural view of the self-adaptive software. For instance, our initial idea for EUREMA’s approach to layered architectures as presented in [Vogel and Giese (2012a)] was only based on FLDs. Therefore, it had the following drawbacks. First, it only considered the triggering of a higher-layer feedback loop by an explicit invocation from the lower-layer loop. This required the anticipation of the higher-layer loop in the lower-layer loop. Second, it did not make the individual layers of the adaptation engine explicit such that it was not visible which feedback loop is located at which layer or which loop adapts which other loop. Third, it just considered procedural reflection among feedback loops. To address these issues, we substantially modified EUREMA by introducing LDs that complement the behavioral view provided by FLDs. The LD concepts are motivated by layered architectures for self-adaptive software with multiple feedback loops. Therefore, we introduced the layers that contain modules, particularly instances of feedback loops as specified by FLDs. Furthermore, to be open for adaptation behavior specified by other languages, we extended the concepts of modules to any software component such as legacy adaptation activities. Moreover, we introduced operational relationships among modules to describe dependencies and to support the execution. These are the use relationship to enable modular modules and their usage by each other, and the sense and effect relationships. The latter two make explicit which modules control which other modules. Such relationships are needed to reason about dependencies such as interferences between feedback loops. In this context, an LD also constitutes a megamodel that primarily contains FLD instances and relationships among them.

Besides specifying a layered architecture, we designed the LD to be a runtime model that can be used as a procedural reflection model of the adaptation engine. Therefore, the LD provides an instance view of the self-adaptive software that can be adjusted at runtime. The goal of this decision was to facilitate off-line adaptation (R10). Finally, the triggering conditions (R3) for feedback loops are defined in the LD because they usually depend on other modules or require coordination with other modules. Thus, we decided not to define the triggering conditions in the FLDs that typically consider individual feedback loops.

The proposed EUREMA modeling language as used in FLDs and LDs is specific for engineering feedback loops, which makes EUREMA a domain-specific modeling language (DSML). We propose a DSML instead of using an existing general-purpose software modeling language such as UML [Object Management Group (2011)] to clearly separate the adaptation logic (adaptation engine and feedback loops) from the domain logic (adaptable software). This avoids intertwining of the adaptation and domain logic and promotes separation of concerns as proposed by the external approach (cf. Section 2), which promises more maintainable and reusable designs [Salehie and Tahvildari (2009)]. Nevertheless, FLDs share concepts with flowcharts and data flow diagrams such as UML Activities. FLDs and UML Activities are similar with respect to modeling flows of actions (in UML) or operations (in EUREMA). However, in contrast to EUREMA, UML does not provide megamodel concepts as first class entities, like a model being itself an element in another model. Likewise, the LD borrows concepts from UML, particularly UML Packages and UML Objects. However, LDs focus on domain-specific concepts and elements such as layers, megamodel and software modules, and operational use, sense, and effect relationships among modules, which clearly separates the adaptation logic from the domain logic. Additionally, we propose a lean metamodel for EUREMA (cf. [Vogel and Giese (2013)]

) resulting in a light-weight and efficient interpreter that probably cannot be easily achieved for the complex UML metamodel.

With EUREMA we adopt an MDE approach to leverage benefits of MDE to the runtime environment as generally discussed by France+Rumpe2008. On the one hand, EUREMA exploits MDE principles by means of its executable modeling language and interpreter. On the other hand, EUREMA makes the feedback loop’s knowledge explicit by runtime models. This additionally leverages MDE techniques at runtime to perform individual adaptation activities of a feedback loop. As EUREMA is designed to target a reasonable abstraction level similar to the level of software architectures, adaptation activities are considered as abstract model operations. This enables the integration and reuse of existing MDE techniques and implementations for realizing and performing such activities.

For example, we employed an existing model synchronization engine for the monitor and execute activities to maintain an architectural runtime model of the adaptable software, and an Object Constraint Language (OCL) engine for the analyze activity to check architectural constraints on this model [Vogel et al. (2010), Vogel and Giese (2010)]. Such engines can be considered as reusable implementations for adaptation activities. This exemplifies that the development efforts for adaptation activities can be reduced by integrating and reusing existing engines from MDE. Moreover, since such engines are generic and they completely externalize the user-defined inputs in models such as OCL expressions, these models become runtime models. EUREMA makes such runtime models explicit in FLDs and amenable for adaptation. For example, the OCL expressions can be dynamically adapted without having to change the OCL engine. This potentially simplifies the development of adaptable feedback loops. Thus, EUREMA directly exploits MDE principles for specifying, executing, and adapting feedback loops while it enables engineers to exploit MDE principles for implementing individual adaptation activities that are modeled as operations in FLDs.

We designed EUREMA to be reusable such that it abstracts from sensor and effector details of the adaptable software. This avoids its coupling to the technology, platform, or type of a specific software. In contrast, EUREMA proposes the explicit modeling of monitor and execute activities, whose implementations have to cope with these details. Sensors details are only revealed by sensor events that are used in triggering conditions of feedback loops. Thus, we require that appropriate sensors, effectors, and activity implementations are available to realize parameter or structural adaptation (R8). EUREMA then supports the modeling and coordinated execution of the activities in a feedback loop.

7.2 Requirements Coverage

As just discussed, the design of EUREMA is motivated by the requirements for engineering self-adaptive software identified in Section 2. These requirements reflect the state-of-the-art issues that are discussed for self-adaptive software in research and EUREMA provides concepts for almost all of them. FLDs cover the explicit modeling of individual or multiple feedback loops (R1), their intra-loop (R2) and inter-loop coordination (R4), and their, however, non-concurrent execution (R6) (cf. Section 4). Thereby, FLDs can capture arbitrary runtime models and their usage in feedback loops without restricting the kinds of models by means of their metamodels and purpose (R7). An LD covers the layered architecture of an instance of the self-adaptive software, which consists of all employed FLD instances, their triggering (R3), and their relationships to each other and to the adaptable software (cf. Section 5). Besides FLDs, this further makes the feedback loops visible in the design of self-adaptive software (R1) and shifts the abstraction level of feedback loops and their coordinated execution to the architectural level. Moreover, by LDs and keeping executable FLD instances alive at runtime, adaptive or hierarchical control schemes in layered architectures are enabled (R9) (cf. Section 5.4). Additionally, keeping the LD alive at runtime enables dynamic layered architectures, which supports off-line adaptation for the long-term evolution of self-adaptive software (R10) (cf. Section 5.5). Finally, EUREMA addresses parameter and structural adaptation (R8) if corresponding sensors, effectors, and implementations of adaptation activities are available. Then, EUREMA supports the modeling and coordinated execution of these activities.

Overall, EUREMA covers all of the requirements except of distribution (R5) and the entirely concurrent execution (R6). Thus, adaptation engines cannot be distributed and interdependent feedback loops and their adaptation activities cannot be executed concurrently. Nevertheless, EUREMA provides concepts for almost all issues as reflected by the requirements and currently discussed in the research literature on self-adaptive software such that it addresses a wide range of state-of-the-art problems for self-adaptive software.

8 Evaluation

Besides experimenting with mRUBiS [Vogel (2013)] as an application example, we evaluate EUREMA by applying its language to state-of-the-art approaches to self-adaptive software and by investigating the runtime characteristics of its interpreter. This demonstrates the expressiveness of the language and the runtime efficiency of the interpreter, respectively.

8.1 Application of the EUREMA Language

In this section, we investigate the expressiveness of the EUREMA language by examples. Therefore, we applied it to state-of-the-art approaches from literature, namely, Rainbow [Garlan et al. (2004)], DiVA [Morin et al. (2009a)], and PLASMA [Tajalli et al. (2010)]. In this article, we will discuss the application to PLASMA that proposes a three-layer architecture for plan-based adaptation. This resulted in the following EUREMA diagrams. The LD in Figure 25 defines the layered architecture with the adaptable application at the lowest layer. The feedback loop in the middle layer adapts the application and the highest-layer feedback loop (re)generates plans to be executed by the two lower layers.

Figure 24: LD for PLASMA
Figure 25: FLD for the Adaptation layer in PLASMA

The middle-layer loop is defined by the FLD in Figure 25. The Collector-1 operation monitors the application and maintains the Application Architecture Model reflecting the application. This model is used by the Adaptation Analyzer to execute the Adaptation Plan provided by the higher-layer loop. This plan specifies the adaptation to move the current application architecture to the target architecture defined in the Target Application Architecture Model. Additionally, the Adaptation Analyzer analyzes any deviations in the current application architecture and resolves them to align it with the target architecture. Therefore, reconfiguration commands (Actions-1) are created and executed by the Admin-1 operation on the application.

Figure 26: FLD for the Planning layer in PLASMA

The higher-layer feedback loop defined by the FLD in Figure 26 is executed when plans are generated initially or when replanning is required. The Application Planner uses a domain model of the application (Application Domain Description) and the initial and goal states of the application (Application Problem Description), which are all provided by the architect. The planner creates an Application Plan to be executed by the application at the lowest layer and the Target Application Architecture Model prescribing the application architecture that is able to execute the application plan. Moreover, the architect provides the Target Adaptation Architecture Model defining the target architecture of the middle-layer feedback loop, which is also reflected in the Adaptation Domain Description used by the Adaptation Planner. This planner additionally uses the Application Architecture Model maintained by the middle-layer feedback loop and the newly created Target Application Architecture Model to derive an Adaptation Plan defining how to move the current architecture of the application to the target architecture. Then, the following operations adapt the middle-layer loop to enable the execution of the generated adaptation plan. The Collector-2 operation updates the Adaptation Architecture Model reflecting the middle-layer feedback loop by monitoring. The Analyzer adds the Adaptation Plan and the Target Application Architecture Model to this model in order to provide them to the middle-layer loop. Moreover, based on the current and target architectures of the middle-layer loop, reconfiguration commands (Action-2) are generated to adapt this loop, for example, to replace the Adaptation Analyzer (cf. Figure 25) with a version that is able to execute the new adaptation plan. Finally, the Admin-2 operation adapts the middle-layer loop by executing the reconfiguration commands and synchronizing the Adaptation Architecture Model.

Overall, the EUREMA language is able to capture PLASMA’s architecture and feedback loops. However, the proper modeling of PLASMA is hard to assess since PLASMA only implicitly maintains the runtime models in a middleware and it does not make their usage by the loops and the triggers of the loops explicit. Thus, we derived as far as possible the runtime models and their usage from [Tajalli et al. (2010)] but we omitted the triggers.

Besides PLASMA, we applied the EUREMA language to Rainbow and DiVA, which is discussed in our technical report [Vogel and Giese (2013)]. The results of modeling these three examples demonstrate that the EUREMA language is expressive enough to capture these state-of-the-art approaches and different variants of feedback loops. These variants especially concern the techniques that drive the feedback loops (architecture description languages in PLASMA and Rainbow, and MDE in DiVA) and the number of feedback loops (two layered feedback loops in PLASMA, and single feedback loops in Rainbow and DiVA). Though these examples provide only limited evidence for the expressiveness of the EUREMA language, we have already shown at the conceptual level that EUREMA is expressive enough to addresses a wide range of state-of-the-art problems for self-adaptive software (cf. Section 7.2).

8.2 Runtime Characteristics of the EUREMA Interpreter

Finally, we evaluate the EUREMA interpreter by discussing its runtime characteristics. We conducted experiments to quantify the load and overhead of the interpreter compared to a code-based solution to execute the self-repair feedback loop defined by the FLDs in Figures 7 and 7. For the experiments, we considered the case, in which each run of the feedback loop instance always identifies failures. Moreover, a warm-up phase taking place before the actual measurements executes the instance more than five times, such that the condition branching the control flow in the FLD depicted in Figure 7 is always fulfilled. Thus, for the measurements, all of the five basic model operations of the self-repair feedback loop are executed in each run of the instance. As implementations for these model operations, we provided software modules as mocks that have runtime models as input as it is defined in the FLDs. Moreover, all runtime models that are the output of any model operation are already used as input of the same operation. Thus, no new models are produced by the mocks. In contrast, all runtime models are pre-defined and they are not changed at all by the mocks. Each mock can be assigned a duration, for which it generates load to simulate computations of the model operations.

To evaluate the runtime characteristics of the EUREMA interpreter, we implemented a code-based solution in Java that executes the self-repair feedback loop. This solution does not use any EUREMA model but it hard-codes the execution by sequentially invoking the five mocks, one for each model operation of the self-repair feedback loop. Moreover, this code-based solution provides the runtime models required as input for invoking the mocks.

The experiments are configured by two parameters. First, the duration assigned to the mocks defines the internal computation time of the model operations. The same duration is assigned to all mocks for one experiment and they vary for the different experiments. This results in four groups of experiments, either assigning a duration of 0ms, 5ms, 10ms, or 20ms to each mock. Since the self-repair feedback loop has five basic model operations, this constitutes a total computation time of either 0ms, 25ms, 50ms, or 100ms for one run of the feedback loop instance. The second parameter is the frequency of consecutive runs of the instance, which determines the execution rate. The frequency is defined by its reciprocal, that is, the period of time between two consecutive activations of the instance. For each of the four groups of experiments, we varied the period starting from 15ms and doubling it until 960ms. For example, a period of 15ms means that the feedback loop instance is executed every 15ms, which is only feasible if the total computation time of the feedback loop plus the overhead of the code-based solution or the EUREMA interpreter is below 15ms.

For each feasible combination of these two parameters, we measured the load of the Java virtual machine for the code-based solution and the EUREMA interpreter while executing the self-repair feedback loop for a total time of ten minutes. The results of the experiments222 The experiments were conducted on the following platform: quad-core CPU (Intel Core i5-2400, 3.10GHz), 8GB RAM, Ubuntu 12.04 (Kernel 3.2.0-33), Java SE Runtime Environment 1.6.0_31, and Eclipse Modeling Framework (EMF) Runtime and Tools 2.7.2. The CPU load has been measured by the monitoring capabilities of Java VisualVM provided with the Java Development Kit 6 (1.6.0_31). are depicted in Figures 28 and 28.

Figure 27: Average CPU Load of the code-based solution (Code) and EUREMA (Interpreter)
Figure 28: Interpreter overhead by means of the differences in average CPU loads

Figure 28 visualizes the average CPU load of the code-based solution (solid gray lines) and the EUREMA interpreter (dashed black lines) for the different frequencies of executing the feedback loop instance. Moreover, each graph refers to a specific total computation time of the feedback loop instance (see legend). Based on this figure, we may generally observe that the average load decreases for both solutions and all computation times of the feedback loop instance if the period between consecutive runs of the feedback loop instance increases. This observation is not surprising since running a feedback loop less frequently is supposed to cause less load. Moreover, we may observe that the EUREMA interpreter causes slightly more load than the code-based solution when the computation time of the feedback loop is 0ms. However, for the other cases of the computation time, there are no apparent differences between the loads of the code-based solution and the interpreter, and the corresponding graphs overlap. Thus, the overhead of the interpreter is noticeable for the hypothetical case that the feedback loop does not perform any computations and therefore, the computations do not cause any load.

To further investigate the overhead, we calculated the overhead as the difference between the average loads of the interpreter and the average loads of the code-based solution for each case of the total computation time (cf. Figure 28). We may observe that for all cases the overhead of the EUREMA interpreter with respect to the code-based solution is always below 0.2 percentage points and tends to decrease with increasing frequency periods. This assumptions is supported by the overhead we predicted (cf. Prediction graph), which is the average overhead based on all measurements for all frequencies and computation times, and normalized for the frequencies.

Summing up, the experiments show that the overhead of interpreting EUREMA models is negligible. In particular, the hypothetical case when the feedback loop’s operations do not perform any internal computations revealed the pure load caused by the EUREMA interpreter. The average of this pure load was for all experiments below 1% (cf. Interpreter/0ms graph in Figure 28). Thus, in absolute terms, the EUREMA interpreter works efficiently for the considered case of executing the EUREMA models specifying the self-repair feedback loop. Moreover, employing the EUREMA interpreter and accepting its overhead provides the flexibility to dynamically adapt feedback loops as discussed in Sections 5.4 and 5.5.

The validity of the experiments is threatened since we implemented the alternative, code-based solution, such that the comparison of this solution with the EUREMA interpreter needs further investigations. Nevertheless, we have shown that the interpreter works efficiently in absolute terms by causing a negligible average load (cf. previous paragraph). Another threat of validity is the specific self-repair feedback loop we used. However, we think that this feedback loop is a typical one since it follows the MAPE-K principle like the state-of-the-art approaches (Rainbow, DiVA, and PLASMA) [Vogel and Giese (2013)]. Moreover, the complexity of the specific feedback loop by means of the numbers of model operations and runtime models can be questioned and how the interpreter behaves for larger EUREMA models. Thus, the scalability of the interpreter, which is determined by the specific EUREMA models and not by the EUREMA language, needs to be further investigated though state-of-the-art approaches (cf. VG-TR13) do not employ significantly more complex feedback loops with respect to the size of the FLDs.

9 Conclusion and Future Work

In this article, we presented EUREMA, a model-driven approach for engineering adaptation engines for self-adaptive software. EUREMA provides a domain-specific modeling language to specify and an interpreter to execute feedback loops. In contrast to existing work on self-adaptive software, EUREMA is a seamless approach that covers the specification and the execution of adaptation engines. Related approaches on modeling languages provide no runtime support for their models while related work on frameworks does not support the explicit modeling of feedback loops. Moreover, frameworks do not provide the flexibility for their users in structuring user-defined adaptation activities to form arbitrary feedback loops in an arbitrary number of layers. In this context, EUREMA does not impose any restriction.

The EUREMA language supports the explicit modeling of feedback loops and their coordinated execution. Thereby, the runtime models as the feedback loop’s knowledge are explicitly captured. Moreover, EUREMA models are kept alive at runtime, which leverages layers of feedback loops for dynamically adjusting the adaptation engine as well as evolving the self-adaptive software by offline adaptation. Therefore, this article has discussed EUREMA with respect to the requirements reflecting state-of-the-art problems for self-adaptive software and EUREMA provides concepts for almost all of them. This demonstrates that EUREMA is expressive enough to cover a wide range of problems for self-adaptive software at the conceptual level. To complete the evaluation, we further investigated the expressiveness by examples. Therefore, we modeled three state-of-the-art approaches from the literature. Finally, we evaluated the EUREMA interpreter by quantifying its runtime characteristics, which shows evidence that the interpreter works efficiently and is applicable at runtime.

As future work, we plan to further elaborate EUREMA by considering the requirements for self-adaptive software we are currently not addressing. Thus, we want to investigate the concurrent execution of interdependent feedback loops and the distribution of adaptation engines in the context of a multi-robot system. Furthermore, we want to investigate the integration of model-based techniques to analyze and simulate modular feedback loop specifications. Finally, we want to further evaluate EUREMA by conducting empirical studies.


  • Amoui et al. (2012) Amoui, M., Derakhshanmanesh, M., Ebert, J., and Tahvildari, L. 2012. Achieving dynamic adaptation via management and interpretation of runtime models. J. Syst. Softw. 85, 12, 2720–2737.
  • Andersson et al. (2013) Andersson, J., Baresi, L., Bencomo, N., de Lemos, R., Gorla, A., Inverardi, P., and Vogel, T. 2013. Software Engineering Processes for Self-Adaptive Systems. In Software Engineering for Self-Adaptive Systems II. Lecture Notes in Computer Science, vol. 7475. Springer, 51–75.
  • Andersson et al. (2009) Andersson, J., de Lemos, R., Malek, S., and Weyns, D. 2009. Reflecting on self-adaptive software systems. In Proceedings of the Workshop on Software Engineering for Adaptive and Self-Managing Systems. IEEE, 38–47.
  • Barbero et al. (2007) Barbero, M., Fabro, M. D., and Bézivin, J. 2007. Traceability and Provenance Issues in Global Model Management. In Proceedings of the 3rd Workshop on Traceability. 47–55.
  • Bencomo and Blair (2009) Bencomo, N. and Blair, G. 2009. Using Architecture Models to Support the Generation and Operation of Component-Based Adaptive Systems. In Software Engineering for Self-Adaptive Systems. Lecture Notes in Computer Science, vol. 5525. Springer, 183–200.
  • Bézivin et al. (2003) Bézivin, J., Gerard, S., Muller, P.-A., and Rioux, L. 2003. MDA components: Challenges and Opportunities. In Proceedings of the 1st International Workshop on Metamodelling for MDA. 23–41.
  • Bézivin et al. (2004) Bézivin, J., Jouault, F., and Valduriez, P. 2004. On the Need for Megamodels. In Proceedings of the Workshop on Best Practices for Model-Driven Software Development.
  • Blair et al. (2009) Blair, G., Bencomo, N., and France, R. B. 2009. Models@run.time. Computer 42, 10, 22–27.
  • Brun et al. (2009) Brun, Y., Serugendo, G. D. M., Gacek, C., Giese, H., Kienle, H., Litoiu, M., Müller, H. A., Pezzè, M., and Shaw, M. 2009. Engineering Self-Adaptive Systems through Feedback Loops. In Software Engineering for Self-Adaptive Systems. Lecture Notes in Computer Science, vol. 5525. Springer, 48–70.
  • Cheng et al. (2009) Cheng, B. H., de Lemos, R., Giese, H., Inverardi, P., Magee, J., Andersson, J., Becker, B., Bencomo, N., Brun, Y., Cukic, B., Serugendo, G. D. M., Dustdar, S., Finkelstein, A., Gacek, C., Geihs, K., Grassi, V., Karsai, G., Kienle, H. M., Kramer, J., Litoiu, M., Malek, S., Mirandola, R., Müller, H. A., Park, S., Shaw, M., Tichy, M., Tivoli, M., Weyns, D., and Whittle, J. 2009. Software Engineering for Self-Adaptive Systems: A Research Roadmap. In Software Engineering for Self-Adaptive Systems. Lecture Notes in Computer Science, vol. 5525. Springer, 1–26.
  • Cheng et al. (2006) Cheng, S.-W., Garlan, D., and Schmerl, B. 2006. Architecture-based Self-adaptation in the Presence of Multiple Objectives. In Proceedings of the Workshop on Software Engineering for Adaptive and Self-Managing Systems. ACM, 2–8.
  • Cheng et al. (2004) Cheng, S.-W., Huang, A.-C., Garlan, D., Schmerl, B., and Steenkiste, P. 2004. An Architecture for Coordinating Multiple Self-Management Systems. In Proceedings of the 4th Working Conference on Software Architecture. IEEE, 243–252.
  • Coulouris et al. (2011) Coulouris, G., Dollimore, J., Kindberg, T., and Blair, G. 2011. Distributed Systems: Concepts and Design 5th Ed. Addison-Wesley.
  • de Lemos et al. (2013) de Lemos, R., Giese, H., Müller, H. A., Shaw, M., Andersson, J., Litoiu, M., Schmerl, B., Tamura, G., Villegas, N. M., Vogel, T., Weyns, D., Baresi, L., Becker, B., Bencomo, N., Brun, Y., Cukic, B., Desmarais, R., Dustdar, S., Engels, G., Geihs, K., Goeschka, K., Gorla, A., Grassi, V., Inverardi, P., Karsai, G., Kramer, J., Lopes, A., Magee, J., Malek, S., Mankovskii, S., Mirandola, R., Mylopoulos, J., Nierstrasz, O., Pezzè, M., Prehofer, C., Schäfer, W., Schlichting, R., Smith, D. B., Sousa, J. P., Tahvildari, L., Wong, K., and Wuttke, J. 2013. Software Engineering for Self-Adaptive Systems: A second Research Roadmap. In Software Engineering for Self-Adaptive Systems II. Lecture Notes in Computer Science, vol. 7475. Springer, 1–32.
  • de Oliveira et al. (2012) de Oliveira, F. A., Sharrock, R., and Ledoux, T. 2012. Synchronization of Multiple Autonomic Control Loops: Application to Cloud Computing. In COORDINATION. Lecture Notes in Computer Science, vol. 7274. Springer, 29–43.
  • Favre (2005) Favre, J.-M. 2005. Foundations of Model (Driven) (Reverse) Engineering : Models – Episode I: Stories of The Fidus Papyrus and of The Solarus. In Language Engineering for Model-Driven Software Development. Number 04101 in Dagstuhl Seminar Proceedings. IBFI.
  • Findeisen et al. (1980) Findeisen, W., Bailey, F., Brdys, M., Malinowski, K., Tatjewski, P., and Wozniak, A. 1980. Control and Coordination in Hierarchical Systems. J. Wiley.
  • Floch et al. (2006) Floch, J., Hallsteinsen, S., Stav, E., Eliassen, F., Lund, K., and Gjorven, E. 2006. Using Architecture Models for Runtime Adaptability. IEEE Softw. 23, 2, 62–70.
  • France and Rumpe (2007) France, R. and Rumpe, B. 2007. Model-driven Development of Complex Software: A Research Roadmap. In Proceedings of the Workshop on the Future of Software Engineering. IEEE, 37–54.
  • Gacek et al. (2008) Gacek, C., Giese, H., and Hadar, E. 2008. Friends or Foes? – A Conceptual Analysis of Self-Adaptation and IT Change Management. In Proceedings of the Workshop on Software Engineering for Adaptive and Self-Managing Systems. ACM, 121–128.
  • Garlan et al. (2004) Garlan, D., Cheng, S.-W., Huang, A.-C., Schmerl, B., and Steenkiste, P. 2004. Rainbow: Architecture-Based Self-Adaptation with Reusable Infrastructure. Computer 37, 10, 46–54.
  • Gat (1997) Gat, E. 1997. On Three-Layer Architectures. MIT/AAAI Press.
  • Gueye et al. (2012) Gueye, S. M. K., De Palma, N., and Rutten, E. 2012. Coordinating Energy-aware Administration Loops Using Discrete Control. In Proceedings of the 8th International Conference on Autonomic and Autonomous Systems. IARIA, 99–106.
  • Hanysz (2013) Hanysz, M. 2013. Integrating Offline and Online Adaptations of Self-Adaptive Software Systems. M.S. thesis, Hasso Plattner Institute, University of Potsdam, Germany.
  • Heaven et al. (2009) Heaven, W., Sykes, D., Magee, J., and Kramer, J. 2009. A Case Study in Goal-Driven Architectural Adaptation. In Software Engineering for Self-Adaptive Systems. Lecture Notes in Computer Science, vol. 5525. Springer, 109–127.
  • Hebig et al. (2010) Hebig, R., Giese, H., and Becker, B. 2010. Making Control Loops Explicit When Architecting Self-Adaptive Systems. In Proceedings of the 2nd International Workshop on Self-Organizing Architectures. ACM, 21–28.
  • Hellerstein et al. (2004) Hellerstein, J. L., Diao, Y., Parekh, S., and Tilbury, D. M. 2004. Feedback Control of Computing Systems. John Wiley & Sons.
  • Hestermeyer et al. (2004) Hestermeyer, T., Oberschelp, O., and Giese, H. 2004. Structured Information Processing For Self-optimizing Mechatronic Systems. In Proceedings of the 1st International Conference on Informatics in Control, Automation and Robotics. INSTICC Press, 230–237.
  • Isermann et al. (1992) Isermann, R., Lachmann, K.-H., and Matko, D. 1992. Adaptive control systems. Prentice Hall International series in systems and control engineering. Prentice Hall, New York.
  • Kephart et al. (2007) Kephart, J. O., Chan, H., Das, R., Levine, D. W., Tesauro, G., Rawson, F., and Lefurgy, C. 2007. Coordinating Multiple Autonomic Managers to Achieve Specified Power-Performance Tradeoffs. In Proceedings of the 4th International Conference on Autonomic Computing. IEEE, 24–33.
  • Kephart and Chess (2003) Kephart, J. O. and Chess, D. 2003. The Vision of Autonomic Computing. Computer 36, 1, 41–50.
  • Kokar et al. (1999) Kokar, M. M., Baclawski, K., and Eracar, Y. A. 1999. Control Theory-Based Foundations of Self-Controlling Software. Intell. Syst. Appl. 14, 3, 37–45.
  • Kramer and Magee (2007) Kramer, J. and Magee, J. 2007. Self-Managed Systems: an Architectural Challenge. In Proceedings of the Workshop on the Future of Software Engineering. IEEE, 259–268.
  • Maes (1987) Maes, P. 1987. Concepts and experiments in computational reflection. In Proceedings of the Conference on Object-oriented Programming Systems, Languages and Applications. ACM, 147–155.
  • McKinley et al. (2004) McKinley, P., Sadjadi, S. M., Kasten, E. P., and Cheng, B. H. 2004. Composing Adaptive Software. IEEE Computer 37, 7, 56–64.
  • Morin et al. (2009a) Morin, B., Barais, O., Jézéquel, J.-M., Fleurey, F., and Solberg, A. 2009a. Models@ Run.time to Support Dynamic Adaptation. Computer 42, 10, 44–51.
  • Morin et al. (2009b) Morin, B., Barais, O., Nain, G., and Jézéquel, J.-M. 2009b. Taming Dynamically Adaptive Systems using models and aspects. In Proceedings of the 31st International Conference on Software Engineering. IEEE, 122–132.
  • Morin et al. (2009c) Morin, B., Ledoux, T., Hassine, M. B., Chauvel, F., Barais, O., and Jézéquel, J.-M. 2009c. Unifying Runtime Adaptation and Design Evolution. In Proceedings of the 9th International Conference on Computer and Information Technology. IEEE, 104–109.
  • Müller et al. (2008) Müller, H. A., Pezzè, M., and Shaw, M. 2008. Visibility of control in adaptive systems. In Proceedings of the 2nd International Workshop on Ultra-large-scale Software-intensive Systems. ACM, 23–26.
  • Object Management Group (2011) Object Management Group. 2011. OMG Unified Modeling Language (OMG UML), Superstructure, Version 2.4.1.
  • Rouvoy et al. (2009) Rouvoy, R., Barone, P., Ding, Y., Eliassen, F., Hallsteinsen, S., Lorenzo, J., Mamelli, A., and Scholz, U. 2009. MUSIC: Middleware Support for Self-Adaptation in Ubiquitous and Service-Oriented Environments. In Software Engineering for Self-Adaptive Systems. Lecture Notes in Computer Science, vol. 5525. Springer, 164–182.
  • Salehie and Tahvildari (2009) Salehie, M. and Tahvildari, L. 2009. Self-adaptive software: Landscape and research challenges. ACM Trans. Auton. Adapt. Syst. 4, 2, 1–42.
  • Schmidt et al. (2008) Schmidt, D., White, J., and Gokhale, A. 2008. Simplifying autonomic enterprise Java Bean applications via model-driven engineering and simulation. Softw. Syst. Model. 7, 1, 3–23.
  • Shaw (1995) Shaw, M. 1995. Beyond objects: A software design paradigm based on process control. ACM SIGSOFT Softw. Engin. Notes 20, 1, 27–38.
  • Tajalli et al. (2010) Tajalli, H., Garcia, J., Edwards, G., and Medvidovic, N. 2010. PLASMA: a plan-based layered architecture for software model-driven adaptation. In Proceedings of the International Conference on Automated Software Engineering. ACM, 467–476.
  • Vogel (2013) Vogel, T. 2013. Modular Rice University Bidding System (mRUBiS). (Last accessed 12/13).
  • Vogel and Giese (2010) Vogel, T. and Giese, H. 2010. Adaptation and Abstract Runtime Models. In Proceedings of the Workshop on Software Engineering for Adaptive and Self-Managing Systems. ACM, 39–48.
  • Vogel and Giese (2012a) Vogel, T. and Giese, H. 2012a. A Language for Feedback Loops in Self-Adaptive Systems: Executable Runtime Megamodels. In Proceedings of the 7th International Symposium on Software Engineering for Adaptive and Self-Managing Systems. IEEE, 129–138.
  • Vogel and Giese (2012b) Vogel, T. and Giese, H. 2012b. Requirements and Assessment of Languages and Frameworks for Adaptation Models. In Models in Software Engineering. Lecture Notes in Computer Science, vol. 7167. Springer, 167–182.
  • Vogel and Giese (2013) Vogel, T. and Giese, H. 2013. Model-Driven Engineering of Adaptation Engines for Self-Adaptive Software: Executable Runtime Megamodels. Tech. rep. 66, Hasso Plattner Institute at the University of Potsdam, Germany.
  • Vogel et al. (2010) Vogel, T., Neumann, S., Hildebrandt, S., Giese, H., and Becker, B. 2010. Incremental Model Synchronization for Efficient Run-Time Monitoring. In Models in Software Engineering. Lecture Notes in Computer Science, vol. 6002. Springer, 124–139.
  • Vogel et al. (2011) Vogel, T., Seibel, A., and Giese, H. 2011. The Role of Models and Megamodels at Runtime. In Models in Software Engineering. Lecture Notes in Computer Science, vol. 6627. Springer, 224–238.
  • Vromant et al. (2011) Vromant, P., Weyns, D., Malek, S., and Andersson, J. 2011. On interacting control loops in self-adaptive systems. In Proceedings of the 6th International Symposium on Software Engineering for Adaptive and Self-Managing Systems. ACM, 202–207.
  • Weyns et al. (2012) Weyns, D., Malek, S., and Andersson, J. 2012. FORMS: Unifying reference model for formal specification of distributed self-adaptive systems. ACM Trans. Auton. Adapt. Syst. 7, 1, 8:1–8:61.
  • Weyns et al. (2013) Weyns, D., Schmerl, B., Grassi, V., Malek, S., Mirandola, R., Prehofer, C., Wuttke, J., Andersson, J., Giese, H., and Goeschka, K. 2013. On Patterns for Decentralized Control in Self-Adaptive Systems. In Software Engineering for Self-Adaptive Systems II. Lecture Notes in Computer Science, vol. 7475. Springer, 76–107.