Model-Driven Engineering of Adaptation Engines for Self-Adaptive Software: Executable Runtime Megamodels

Transcription

1 Model-Diven Engineeing of Adaptation Engines fo Self-Adaptive Softwae: Executable Runtime Megamodels Thomas Vogel, Holge Giese Technische Beichte N. 66 des Hasso-Plattne-Instituts fü Softwaesystemtechnik an de Univesität Potsdam

2

3 Technische Beichte des Hasso-Plattne-Instituts fü Softwaesystemtechnik an de Univesität Potsdam

4

5 Technische Beichte des Hasso-Plattne-Instituts fü Softwaesystemtechnik an de Univesität Potsdam 66 Thomas Vogel Holge Giese Model-Diven Engineeing of Adaptation Engines fo Self-Adaptive Softwae Executable Runtime Megamodels Univesitätsvelag Potsdam

6 Bibliogafische Infomation de Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek vezeichnet diese Publikation in de Deutschen Nationalbibliogafie; detailliete bibliogafische Daten sind im Intenet übe abufba. Univesitätsvelag Potsdam Am Neuen Palais 10, Potsdam Tel.: +49 (0) / Fax: [email protected] Die Schifteneihe Technische Beichte des Hasso-Plattne-Instituts fü Softwaesystemtechnik an de Univesität Potsdam wid heausgegeben von den Pofessoen des Hasso-Plattne-Instituts fü Softwaesystemtechnik an de Univesität Potsdam. ISSN (pint) ISSN (online) Das Manuskipt ist uhebeechtlich geschützt. Online veöffentlicht auf dem Publikationsseve de Univesität Potsdam URL URN un:nbn:de:kobv:517-opus Zugleich geduckt eschienen im Univesitätsvelag Potsdam: ISBN

7 Abstact The development of self-adaptive softwae equies the engineeing of an adaptation engine that contols and adapts the undelying adaptable softwae by means of feedback loops. The adaptation engine often descibes the adaptation by using untime models epesenting elevant aspects of the adaptable softwae and paticula activities such as analysis and planning that opeate on these untime models. To systematically addess the inteplay between untime models and adaptation activities in adaptation engines, untime megamodels have been poposed fo self-adaptive softwae. A untime megamodel is a specific untime model whose elements ae untime models and adaptation activities. Thus, a megamodel captues the inteplay between multiple models and between models and activities as well as the activation of the activities. In this aticle, we go one step futhe and pesent a modeling language fo ExecUtable RuntimE MegAmodels (EUREMA) that consideably eases the development of adaptation engines by following a model-diven engineeing appoach. We povide a domain-specific modeling language and a untime intepete fo adaptation engines, in paticula fo feedback loops. Megamodels ae kept explicit and alive at untime and by intepeting them, they ae diectly executed to un feedback loops. Additionally, they can be dynamically adjusted to adapt feedback loops. Thus, EUREMA suppots development by making feedback loops, thei untime models, and adaptation activities explicit at a highe level of abstaction. Moeove, it enables complex solutions whee multiple feedback loops inteact o even opeate on top of each othe. Finally, it leveages the co-existence of self-adaptation and off-line adaptation fo evolution. Keywods Model-Diven Engineeing, Modeling Languages, Modeling, Models at Runtime, Megamodels, Model Execution, Self-Adaptive Softwae, Adaptation Engines, Feedback Loops i

8

9 Contents 1 Intoduction State-of-the-At in Engineeing Adaptation Engines Appoach: EUREMA ExecUtable RuntimE MegAmodels Contibution Outline Teminology, Concepts, and Requiements Feedback Loops Knowledge & Runtime Models Sensos and Effectos & Monito and Execute Layeed Achitectue Off-line Adaptation Modeling a Feedback Loop Oveview of the EUREMA Language Modeling a Single Feedback Loop Tigge fo Feedback Loops Modulaizing Feedback Loop Diagams Modeling Multiple Feedback Loops Independent Feedback Loops Coodination of Multiple Feedback Loops Sequencing Complete Feedback Loops Sequencing Analysis and Planning of Feedback Loops iii

10 5 Modeling Layeed Achitectues Declaative Reflection Use-defined Reflection Models Pocedual Reflection EUREMA-based Reflection Models Modeling Off-line Adaptation 33 7 Execution Metamodel and Execution Semantics (1) Adaptation Activities, Runtime Models, and Feedback Loops (2) Layeed Achitectues (3) Execution Metamodel and Intepete Implementation Discussion and Evaluation Requiements Coveage Application of MDE Techniques in EUREMA Application of the EUREMA Language Rainbow DiVA PLASMA Discussion Runtime Chaacteistics of the EUREMA Intepete Conclusion and Futue Wok 53 Bibliogaphy 55 iv

11 List of Figues 2.1 Extenal appoach MAPE-K Multiple feedback loops and inte-loop coodination Runtime models fo feedback loops Layeed achitectue fo an adaptation engine Off-line adaptation of self-adaptive softwae Feedback Loop Diagam (FLD) fo MAPE-K Laye Diagam (LD) fo MAPE-K FLD fo Self-epai LD fo Self-epai Concete syntax of the EUREMA language fo (a) FLDs and (b) LDs FLD fo the analyze activity of self-epai Complex model opeation FLD fo the Self-epai feedback loop using a complex model opeation depicted in Figue 3.7b to invoke the analysis activity defined in the FLD shown in Figue LD fo Self-epai Vaiability fo a complex model opeation Vaiability fo a model opeation FLD fo Self-optimization LD fo two feedback loops FLD fo Self-management-1: sequencing complete feedback loops by invoking the selfepai loop (Figue 3.8) followed by the self-optimization loop (Figue 4.1) v

12 4.4 LD fo Self-management Analyze and plan activities of (a) self-epai and (b) self-optimization FLD fo Self-management-2: sequencing the analysis and planning activities of the self-epai (cf. Figue 4.5a) and self-optimization (cf. Figue 4.5b) feedback loops LD fo Self-management FLD fo Self-epai-stategies Layeed feedback loops fo self-epai: the :Self-epai-stategies module at Laye-2 senses and effects the :Self-epai module at Laye FLD fo Self-epai-stategies Layeed feedback loops fo self-epai: the :Self-epai-stategies-2 module at Laye-2 senses and effects the :Self-epai module at Laye Sequence diagam descibing the logical behavio of layeed feedback loops Initial LD FLD fo Self-epai-patch The ule to change the initial LD shown in Figue The esult of applying the ule depicted in Figue 6.3 on the LD depicted in Figue Had-wied legacy module EUREMA tigge fo a legacy module Metamodel of the EUREMA language FLD fo Rainbow LD fo Rainbow FLD fo DiVA LD fo DiVA FLD fo the Configuation Manage of DiVA FLD fo the Adaptation laye in PLASMA LD fo PLASMA FLD fo the Planning laye of PLASMA Aveage CPU Load of the code-based solution (Code) and EUREMA (Intepete) Intepete ovehead by means of the diffeences in aveage CPU loads vi

13 Chapte 1 Intoduction Self-adaptation capabilities ae equied fo many moden softwae systems that ae self-awae, contextawae, mission-citical, o ulta-lage-scale in ode to dynamically adapt thei configuation in esponse to changes in the system itself, the envionment, o the equiements [Cheng et al. 2009; de Lemos et al. 2013]. The development of self-adaptive softwae following the extenal appoach [Salehie and Tahvildai 2009] sepaates the softwae into the adaptable softwae and the adaptation engine. In between both, a feedback loop ensues that the adaptation engine dynamically adjusts the adaptable softwae in esponse to changing equiements and obseved changes in the adaptable softwae and its opeational envionment. This sepaation eases the development because it decouples the adaptable softwae fom the adaptation engine, and both ae integated by well-defined senso and effecto intefaces. Howeve, the feedback loop then becomes a cucial element of the oveall softwae achitectue, which has to be undestood and explicitly designed fo engineeing self-adaptive softwae [Shaw 1995; Mülle et al. 2008; Bun et al. 2009]. Additionally, even multiple feedback loops might have to be consideed [Kephat and Chess 2003; Bazie et al. 2009; Weyns et al. 2012]. On the one hand, the adaptation engine may not necessaily employ only a single feedback loop but athe multiple of them in paallel to handle diffeent concens such as self-epai o self-optimization, to distinguish between localized and global adaptation, o to decentalize contol in geneal. On the othe hand, thee ae also cases whee the feedback loops have to opeate on top of each othe as, fo example, needed fo the diffeent layes of the efeence achitectue fo self-managed systems poposed by Kame and Magee [2007]. Futhemoe, sepaating the adaptation engine fom the adaptable softwae makes the knowledge about the adaptable softwae, which is used by the adaptation engine, anothe cucial element in developing self-adaptive softwae. This knowledge concens epesentations of the unning adaptable softwae, thei synchonization with the unning adaptable softwae though sensos and effectos, and the way adaptation is analyzed and planned. Regading the analysis and planning of adaptation, this includes the stategic knowledge detemining how to identify and handle adaptation needs like pefomance poblems. While taditionally achitectue desciption languages ae employed fo such epesentations in selfadaptive softwae at untime [Oeizy et al. 1998; Galan et al. 2004; Geogas et al. 2009], untime models [Fance and Rumpe 2007; Blai et al. 2009] that follow model-diven engineeing (MDE) pinciples and that leveage the benefits of MDE fo untime abstactions of the adaptable softwae ae 1

14 2 1 Intoduction emeging today [Moin et al. 2009a; Vogel and Giese 2010; Song et al. 2011]. It is futhe likely that the adaptation engine does not only employ a single untime model but athe multiple and specialized models at the same time to handle diffeent concens such as failues o pefomance. Likewise, Blai et al. [2009, p.25] have obseved that in pactice, it is likely that multiple [untime] models will coexist and that diffeent styles of models may be equied to captue diffeent system concens. This makes it necessay to simultaneously conside multiple untime models and the inteplay between them when engineeing and executing adaptation engines [Vogel et al. 2011]. Finally, it cannot be expected that the self-adaptive softwae automates and takes ove all the adaptation activities that ae usually pefomed off-line in the context of maintenance and evolution. Thus, besides ealizing an adaptation engine fo the self-adaptation, a solution fo the co-existence of such an engine with off-line adaptation, and thus, with typical maintenance and evolution is equied [Gacek et al. 2008; Andesson et al. 2013]. All these aspects constitute coe equiements fo self-adaptive softwae, which have to be consideed when engineeing adaptation engines. 1.1 State-of-the-At in Engineeing Adaptation Engines In the following, we eview state-of-the-at appoaches and show that they do not simultaneously suppot all the coe equiements fo engineeing adaptation engines as just outlined, namely making feedback loops explicit in the design of self-adaptive softwae, and suppoting multiple feedback loops, layeed achitectues fo feedback loops, and the co-existence of self-adaptation and off-line adaptation, while exploiting untime models and MDE. Thee exists a lage body of wok on feedback loops to contol systems. In paticula, autonomic computing has achieved esults by applying concepts of contol theoy to untime paamete adaptation of softwae systems [Koka et al. 1999; Hellestein et al. 2004]. Howeve, self-adaptation oftentimes consides dynamic softwae achitectues in addition to paametes [McKinley et al. 2004], which pevents a diect application of contol theoy concepts and equies new means fo engineeing adaptation engines. A popula way to enginee self-adaptive softwae ae famewok-based appoaches that use some fom of models (cf. [Salehie and Tahvildai 2009]). Fo example, famewoks employ models to specify selfadaptive softwae including the adaptation as mappings of assetions to adaptation actions [Schmidt et al. 2008] o as tansitions between configuations of the adaptable softwae [Bencomo and Blai 2009]. These models ae used fo geneating patial code fo adaptation engines to simplify thei development. The stuctue of the esulting engines suppoting single feedback loops ae static and pe-defined by these famewoks. Moeove, the ceated models do not make the feedback loop explicit and they ae not kept alive at untime, fo example, to execute and dynamically adjust the adaptation engine. In contast, famewoks like Rainbow [Galan et al. 2004], MADAM [Floch et al. 2006], MUSIC [Rouvoy et al. 2009], DiVA [Moin et al. 2008, 2009a,b], o GRAF [Amoui et al. 2012] maintain untime models that specify the adaptation and captue the knowledge used by the feedback loops. These models can be modified at untime by enginees, especially to eplace adaptation stategies to adjust the adaptation logic. Howeve, suppot fo dynamically adjusting a feedback loop is limited since these famewoks suppot only single feedback loops, whose stuctuing of adaptation activities cannot be adjusted at untime in contast to specific models, like adaptation stategies, consumed by the activities. Additionally, the untime models do not explicitly specify complete feedback loops because each of these famewoks pescibe a single feedback loop and just offes customization points, like to inject adaptation stategies. This is motivated by thei focus to educe development effots fo adaptation

15 1.1 State-of-the-At in Engineeing Adaptation Engines 3 engines at the expense of limited flexibility. Thus, when developing a specific self-adaptive softwae, these famewoks do not suppot feedback loops that ae entiely and individually designed by enginees fo the specific case. All the appoaches discussed so fa suppot adaptation engines with single feedback loops and do not addess multiple, inteacting feedback loops. Kephat et al. [2007] conside inteactions between two feedback loops that manage competing concens (enegy consumption vs. pefomance). Fo this specific case, they popose a coodination solution based on utility functions that has been established though tial and eo [Kephat et al. 2007, p.24]. In contast, a geneic synchonization potocol fo multiple feedback loops is pesented by de Oliveia et al. [2012], which suppots mutual exclusive access to knowledge and the asynchonous tiggeing among feedback loops. Howeve, the potocol is esticted since a feedback loop may only tigge anothe loop fom the execute activity but not fom the monito, analyze, o plan activities. Thus, diectly coodinating, e.g., the analysis activities of multiple feedback loops is not suppoted. In [Gueye et al. 2012], the coodination between multiple feedback loops is ealized by a distinct contolle that decides which feedback loop may exclusively pefom an adaptation based on the states of the othe loops. This decision is exactly specified by automata models descibing the states of the feedback loops and by a coodination policy, which ae used fo geneating the contolle. Howeve, these models do not specify the feedback loops and thei coodination at the achitectual level of self-adaptive softwae. Othe appoaches addessing multiple feedback loops ae implementation famewoks that aim at educing development effots without pescibing a specific solution fo the inteaction o coodination. Vomant et al. [2011] povide eusable components that suppot the distibuted communication among multiple feedback loops o adaptation activities. Cheng et al. [2004] povide an abstaction laye between the adaptable softwae and multiple feedback loops. Though this laye, all feedback loops have consistent access and knowledge about the adaptable softwae. Fo a case study, they apply a specific coodination solution fo two feedback loops ensuing that only one loop is active at any time. All of the appoaches discussed so fa, eithe addessing single o multiple feedback loops, eithe povide specific and pe-defined solutions o geneic implementation suppot, which esults in adaptation engines whose stuctue cannot be dynamically adapted at untime. Dynamically adapting feedback loops is addessed by appoaches adopting layeed achitectues, whee a highe-laye feedback loop adjusts the feedback loop at the laye below. In ou pevious wok on Mechatonic UML [Bumeste et al. 2004, 2008] fo the model-diven development of self-optimizing mechatonic systems, we extended UML to specify and geneate a hieachical self-adaptation scheme that addesses contol, had eal-time econfiguation, and soft eal-time planning by distinct feedback loops at diffeent layes [Hestemeye et al. 2004]. Howeve, the adaptation is defined befoe deployment and cannot be evolved though off-line adaptation at untime, among othes, since the models ae not kept alive at untime. Sykes et al. [2008] and Heaven et al. [2009] popose a thee-laye achitectue that distinguishes between component-based contol, achitectual (e)configuation, and high-level task (e)planning. Plans geneated by the highest laye ae executed by the middle laye that geneates new configuations fo the lowest laye. Howeve, the cuent solution focuses on synthesizing initial plans befoe the system is stated, but it does not suppot task eplanning at untime. Thus, the highestlaye feedback loop adapting the middle laye has not been ealized. In contast, PLASMA [Tajalli et al. 2010] suppots eplanning and adapting the middle laye in a simila, layeed achitectue. Howeve, the extent of this adaptation is not clea since the achitectue of the middle laye is pe-defined by enginees. Moeove, the focus of PLASMA is to povide a famewok that automates the geneation and enactment of plans while the employed feedback loops, thei adaptation activities, and knowledge ae not explicitly modeled fo all layes. Finally, the numbe of layes (thee) and the numbe of feedback loops fo each laye (one) seem to be immutable in these appoaches [Sykes et al. 2008; Heaven et al. 2009; Tajalli et al. 2010]. Thus, multiple feedback loops fo a laye, o (dynamically) changing the numbe of layes and feedback loops ae not suppoted.

16 4 1 Intoduction Changing the numbe of layes and feedback loops can be seen as an extensive adaptation evolving the self-adaptive softwae. Besides adapting itself, self-adaptive softwae has to be open fo off-line adaptation by means of maintenance and evolution [Andesson et al. 2013]. Gacek et al. [2008] discuss the idea of having two intetwined feedback loops fo self-adaptation and off-line adaptation, but they do not pesent a solution ealizing this idea. As discussed above, famewoks utilizing untime models often suppot to change those models, e.g., to add o emove adaptation stategies at untime. In this context, though focusing on self-adaptation, Moin et al. [2009a] claim to suppot evolution as changes pefomed manually on untime models, which is not substantiated to an integated co-existence that popely executes those changes to the unning system. In this context, they popose an initial step in [Moin et al. 2009c]: an enginee changes models in the development envionment, while the same kind of models ae also used by the adaptation engine at untime. Assuming thee is no self-adaptation in pogess, these changes ae executed to the unning system only if the system fulfills constaints defined by the enginee. Howeve, changes that affect the stuctue of the adaptation engine s feedback loop, the numbe of feedback loops, o the numbe of layes ae not consideed. All appoaches discussed so fa do not make the feedback loops, thei adaptation activities and (untime) models, and thei inteactions o coodination explicit in the achitectual design of self-adaptive softwae. A few appoaches exist that addess the explicit modeling of feedback loops when designing self-adaptive softwae. In [Hebig et al. 2010], we poposed a UML pofile to make feedback loops and the inteplay of multiple feedback loops explicit in achitectual design and analysis using UML models. A feedback loop is modeled at the abstaction level of contolles, thus abstacting fom individual adaptation activities and untime models. In contast, Weyns et al. [2012] pesent a fomal efeence model fo self-adaptive systems that suppots the desciption of feedback loops including adaptation activities and untime models used by the activities. The goal of the efeence model is to suppot the systematic engineeing of self-adaptive systems by poviding a means to fomally descibe and evaluate design altenatives ealy in the development pocess. The models ceated by both appoaches [Hebig et al. 2010; Weyns et al. 2012] ae used fo the achitectual design when developing self-adaptive softwae, but they ae not used at untime fo opeating o adapting the softwae. Summing up, state-of-the-at appoaches fo engineeing self-adaptive softwae aim at educing development effots by geneating adaptation engines o poviding eusable famewoks fo the engines. The esulting adaptation engines often consist of single feedback loops, whose stuctue is athe static and pe-defined by the famewoks. This limits thei adaptation eithe duing development, dynamically in layeed achitectues at untime, o though evolution (off-line adaptation). In geneal, thee exist only peliminay wok on layeed achitectues fo self-adaptive softwae and on the co-existence of selfadaptation and off-line adaptation. Moeove, appoaches poviding untime suppot fo self-adaptive softwae do not addess the explicit modeling of the feedback loops o thei adaptation activities and knowledge. Thus, even when multiple untime models ae used fo the knowledge within a feedback loop, these models and thei inteplay ae not explicitly addessed duing design and opeation of the self-adaptive softwae. State-of-the-at famewoks do not conside untime models, like untime megamodels, that descibe whole feedback loops and leveage the execution and adaptation of feedback loops. In contast, appoaches tackling the explicit modeling of feedback loops ae focused on the design of self-adaptive softwae and they do not povide any untime suppot that leveage those models at untime fo executing o adjusting the softwae. Thus, state-of-the-at appoaches do not simultaneously suppot all the coe equiements fo engineeing adaptation engines as peviously outlined. 1.2 Appoach: EUREMA ExecUtable RuntimE MegAmodels Fo self-adaptive softwae that is diven by untime models, we poposed in [Vogel et al. 2011] the geneic idea to utilize untime megamodels that have untime models as thei elements and that

17 1.3 Contibution 5 descibe the pocessing of these models by adaptation activities as model opeations. 1 In this aticle, we go one step futhe and pesent a complete MDE appoach called ExecUtable RuntimE MegAmodels (EUREMA) that enables the specification and execution of complex adaptation engines fo self-adaptive softwae diectly suppoting feedback loops and untime models. The EUREMA language consideably eases the development of adaptation engines by suppoting a domain-specific modeling solution and the EUREMA untime intepete suppots the execution of the adaptation engines, in paticula the feedback loops. Moeove, EUREMA explicitly maintains the diffeent untime models, the inteplay between these models, and the model opeations pefoming adaptation activities and woking on these models. Thus, the maintenance of untime models and model opeations continues beyond the initial development-time of the softwae. The poposed EUREMA modeling language is specific fo the development of adaptation engines fo self-adaptive softwae and is based on geneal modeling concepts fo stuctual and behavioal diagams. Theefoe, EUREMA suppots two types of diagams to specify and descibe adaptation engines: A behavioal feedback loop diagam (FLD) is used to model a complete feedback loop o individual adaptation activities and untime models of a feedback loop. An FLD is consideed as a megamodel module that encapsulates the details of a feedback loop o adaptation activities. A stuctual laye diagam (LD) descibes how the diffeent megamodel modules and the adaptable softwae ae elated to each othe in a concete situation of the self-adaptive softwae. Thus, an LD povides an abstact and complete view of an instance of the self-adaptive softwae by eflecting its achitectue. This achitectual view consides feedback loops as black boxes encapsulated in megamodel modules, while white-box views on megamodel modules ae povided by FLDs. Thus, EUREMA models specify feedback loops and thei stuctuing in adaptation engines. Theeby, the models make the feedback loops explicit in the achitectual design of the self-adaptive softwae and they ae kept alive at untime and executed by an intepete, which suppots the design and the execution of adaptation engines. 1.3 Contibution This aticle discusses the EUREMA appoach with the following majo contibutions: (a) we thooughly discuss equiements fo adaptation engines and feedback loops diven by untime models, which has influenced the design of the EUREMA language, (b) using the EUREMA language, feedback loops ae explicitly specified at a highe level of abstaction by captuing the inteplay of adaptation activities and untime models as well as the inteactions between multiple feedback loops, (c) the knowledge used within a feedback loop is efined to multiple untime models that ae captued by EUREMA models, (d) EUREMA models specifying feedback loops ae kept alive at untime, which leveages layeed achitectues fo dynamically adjusting the feedback loops, (e) the co-existence of self-adaptation with off-line adaptation is intoduced to suppot evolution of the self-adaptive softwae by dynamic layes, and (f) we evaluated EUREMA by discussing how EUREMA addesses the equiements, by modeling thee appoaches to self-adaptive softwae fom the liteatue, and by quantifying the untime pefomance of the intepete fo EUREMA models. This aticle is a evised and extended vesion of [Vogel and Giese 2012a] that intoduced the basic concepts of the EUREMA language and theefoe initially addessed the contibutions (b), (c), and (d). In contast, this aticle efines these contibutions by extending the language with tigges fo feedback loops and with laye diagams (LDs) poviding achitectual views of the self-adaptive softwae. Finally, 1 In the eseach field of MDE and in paticula of model management fo model-diven softwae development, a megamodel efes to a model that has models as its elements and that captues the elationships between the contained models by means of model opeations, like model tansfomations (cf. [Babeo et al. 2007; Bézivin et al. 2003, 2004; Fave 2005]).

18 6 1 Intoduction this aticle pesents the novel contibutions (a), (e), and (f) that have not been discussed in the initial pape. In contast to the state-of-the-at in engineeing self-adaptive softwae, we popose a seamless modeldiven engineeing appoach. The modeling language suppots the design as well as the execution of feedback loops in adaptation engines. Theeby, EUREMA impoves the state-of-the-at concening famewoks because it does not pescibe any stuctue of the adaptation activities o feedback loops and it does not limit the numbe of feedback loops o layes in layeed achitectues. In contast to existing modeling languages fo self-adaptive softwae, EUREMA povides impovements by keeping the models alive at untime fo executing and adjusting feedback loops eithe dynamically o by off-line adaptation. 1.4 Outline The est of the aticle is stuctued as follows. The next section discusses in detail the teminology, the basic concepts, and the coe equiements fo self-adaptive softwae. Then, we intoduce the basic EUREMA concepts fo modeling single and multiple feedback loops in Sections 3 and 4, espectively. These concepts ae efined fo layeed achitectues of adaptation engines in Section 5 and fo the coexistence of self-adaptation and off-line adaptation in Section 6. We discuss the execution of EUREMA models in Section 7 and evaluate EUREMA in Section 8. Finally, the aticle concludes and outlines futue wok.

19 Chapte 2 Teminology, Concepts, and Requiements In this section, we claify teminology, intoduce elevant coe concepts of self-adaptive softwae, and efine the coe equiements fo engineeing self-adaptive softwae as outlined in the intoduction (Section 1). The extenal (achitectual) appoach is typically adopted in self-adaptive softwae [Salehie and Tahvildai 2009]. Thus, this aticle consides this appoach as depicted in Figue 2.1. It assumes a basic achitectue that splits the self-adaptive softwae into the adaptation engine and the adaptable softwae while the fome one contols (sensing and effecting) the latte one. The adaptable softwae ealizes the domain logic, and the adaptation engine implements the adaptation logic as a feedback loop, which constitutes self-adaptation. Self-Adaptive Softwae Adaptation Engine (Adaptation Logic) Sensing Effecting Adaptable Softwae (Domain Logic) Fig. 2.1: Extenal appoach Adaptation Engine Analyze Plan Knowledge Monito Execute Sensos Effectos Adaptable Softwae Fig. 2.2: MAPE-K Thus, the engineeing of adaptation engines and feedback loops is essential fo the extenal appoach to self-adaptive softwae. This equies a modeling language to design and specify adaptation engines and elated techniques to suppot the implementation and execution. In the following, we efine the geneal equiements fo self-adaptive softwae as discussed in the intoduction (Section 1) fo the paticula case of a modeling language fo specifying, implementing, and executing adaptation engines. Theefoe, we will discuss equiements with espect to feedback loops and thei explicit specification, untime models used as the knowledge within feedback loops, sensos and effectos, layeed achitectues fo adaptation engines, and the co-existence of off-line adaptation and self-adaptation. 7

20 8 2 Teminology, Concepts, and Requiements 2.1 Feedback Loops The sepaation between the adaptation engine and the adaptable softwae makes the feedback loop between the adaptable softwae and the adaptation engine a cucial element of the oveall achitectue, which has to be made explicit in the design and analysis of self-adaptive softwae (cf. [Shaw 1995; Koka et al. 1999; Hellestein et al. 2004; Mülle et al. 2008; Bun et al. 2009]). Thus, feedback loops have to be explicitly modeled. A moe detailed view of the extenal appoach and the feedback loop between the adaptable softwae and the adaptation engine is povided by the MAPE-K cycle (Monito/Analyze/Plan/Execute- Knowledge) as poposed by Kephat and Chess [2003] and depicted in Figue 2.2. The adaptation engine (called Autonomic Manage in [Kephat and Chess 2003]) is efined to fou adaptation activities shaing a common knowledge base. The adaptable softwae (called Managed System in [Kephat and Chess 2003]) is monitoed and analyzed, and if changes ae equied, adaptation is planned and executed to this softwae. As sketched in Figue 2.2, the modeling language should suppot the specification of adaptation activities that fom a feedback loop. This includes the coodination of activities within one feedback loop, which is called inta-loop coodination by Vomant et al. [2011], by means of the contol flow fo these activities. By explicitly specifying adaptation activities, the contol flow makes the odeing and dependencies between individual activities explicit and it enables the well-defined coodination and execution of a whole feedback loop. Moeove, it has to be specified when a feedback loop should be executed, i.e., the language should captue tiggeing conditions fo initiating the execution of feedback loops. Examples ae time o event-based tigges as well as combinations of them. Additionally, even multiple feedback loops might have to be consideed [Kephat and Chess 2003; Bazie et al. 2009; Weyns et al. 2012]. On the one hand, the adaptation engine may not necessaily employ only a single feedback loop but athe multiple of them in paallel to handle diffeent concens such as self-epai o self-optimization [Kephat et al. 2007; Vogel et al. 2009, 2010; Vogel and Giese 2010; Fey et al. 2012], to distinguish between localized and global adaptation [Cheng et al. 2004; de Oliveia et al. 2012; Gueye et al. 2012], o to decentalize contol in geneal [Vomant et al. 2011; Weyns et al. 2013]. The language should theefoe suppot the modeling of multiple, inteacting, and potentially distibuted feedback loops and thei coodination. Thus, as sketched in Figue 2.3, besides modeling multiple feedback loops also means fo inte-loop coodination (cf. [Vomant et al. 2011]) and distibution ae equied. Analyze Plan Analyze Plan Knowledge Knowledge Monito Execute Monito Execute Adaptable Softwae Fig. 2.3: Multiple feedback loops and inte-loop coodination Futhemoe, besides specifying feedback loops, the language should suppot the execution of feedback loops based on the specifications. This includes concuency to simultaneously execute multiple feedback loops o the incemental execution of adaptation activities within a feedback loop. Moeove, the language suppot fo execution also has to cove the othe cases, like eflection, that ae discussed late.

21 2.2 Knowledge & Runtime Models Knowledge & Runtime Models In the MAPE-K cycle, the adaptation activities ae the computations pefomed fo self-adaptation while the knowledge base povides the infomation equied fo these computations. It has been obseved by Weyns et al. [2012, p.8:56] that though thee is a shaed undestanding on the diffeent types of computations in a MAPE-K [... feedback loop], the ole of knowledge is less clea. This motivates the explicit teatment of the knowledge pat that is substantiated in ou case to a set of specific kinds of untime models to leveage benefits of MDE fo untime adaptation (cf. [Fance and Rumpe 2007; Blai et al. 2009]). Blai et al. [2009, p.23] define a untime model as a causally connected selfepesentation of the associated system that emphasizes the stuctue, behavio, o goals of the system fom a poblem space pespective. Since this definition is focused on untime models that eflect the adaptable softwae, we take a boade pespective on untime models by consideing all models that ae used on-line by any adaptation activity of a feedback loop. Thus, analysis ules and adaptation stategies ae examples fo futhe untime models. Based on a compehensive liteatue eview, we poposed a categoization of untime models in [Vogel et al. 2011], which is depicted in an extended vesion in Figue 2.4. Evaluation Models Change Models Adaptation Models Analyze Plan Evaluation Models Change Models Reflection Models Causal Connection Models Monito Execute Monitoing Models Execution Models Monitoing Models Execution Models Fig. 2.4: Runtime models fo feedback loops Reflection Models eflect the adaptable softwae and its envionment. The monito obseves the adaptable softwae and its envionment, and updates the eflection models. Theeby, Monitoing Models ae used that specify the mapping of system-level obsevations to the abstaction level of eflection models. The eflection models ae analyzed to identify adaptation needs. Evaluation Models specify the easoning, e.g., by defining constaints that ae checked on the eflection models. If adaptation needs have been identified, the planning activity devises a plan pescibing the adaptation on the eflection models. Planning is specified by Change Models descibing the adaptable softwae s vaiability space. Evaluation models, like utility pefeences, guide the exploation of this space to find an appopiate adaptation, e.g., by evaluating altenative options fo adaptation based on thei utilities. Finally, the execute activity enacts the planned adaptation on the adaptable softwae based on Execution Models that efine model-level adaptation to system-level adaptation. Evaluation and change models do not have to be stictly sepaate models, which is exemplified by eventcondition-action ules that addess the analyze (evaluating the condition) and the plan (applying the actions) activities in one step. Thus, we might combine evaluation and change models to Adaptation Models (see the ight hand side of Figue 2.4) specifying the analysis and planning activities that ae concened with decision-making fo adaptation [Vogel and Giese 2012b]. Monitoing and execution models ae concened with the synchonization of the adaptable softwae and the eflection models. This is known as the causal connection [Maes 1987] playing a majo ole in self-adaptive softwae [Andesson et al. 2009], such that we conside them as Causal Connection Models. This categoization, which efines the abstact notion of the knowledge base used in MAPE-K and extends ou initial poposal [Vogel et al. 2011], shows that multiple and diffeent kinds of untime

22 10 2 Teminology, Concepts, and Requiements models ae used simultaneously in a feedback loop. Consequently, we equie a language that is able to captue diffeent kinds of untime models, how individual adaptation activities use these models, and how this usage effects the execution of activities. 2.3 Sensos and Effectos & Monito and Execute The adaptation engine and the adaptable softwae ae connected by sensos and effectos (cf. Figue 2.2). Thus, the modeling language has to cove when the monito and execute activities, that use these sensos and effectos, espectively, ae activated to maintain the causal connection between the eflection models and the adaptable softwae at untime (cf. Section 2.2). This includes updating the eflection models accoding to obseved senso data, and changing the adaptable softwae accoding to the planned adaptation in the eflection models. Since sensos and effectos usually depend on the specific adaptable softwae, we assume that they ae povided by the adaptable softwae and that most of thei details can be hidden in the implementation of the monito and execute activities. Howeve, fo tiggeing conditions of feedback loops, the language should suppot efeencing senso data, e.g., to chaacteize senso events that should initiate the execution of a feedback loop. Pogamming language and middlewae platfoms have ecognized the need fo untime management [CAC 2002; Issany et al. 2007] by suppoting the development of sensos and effectos o aleady poviding them though application pogamming intefaces (APIs). Examples of such platfoms ae Java Management Extensions (JMX) 1 fo Java, the GlassFish 2 application seve, o the OSGi 3 platfom. Additionally, wok as been done to enich such standad management APIs, e.g., fo GlassFish [Buhn and Witz 2007; Buhn et al. 2008]. Thus, we can assume that softwae ealized fo such platfoms povide sensos and effectos, which make the softwae obsevable and adaptable. Besides ou wok [Vogel et al. 2010; Vogel and Giese 2010], othe appoaches to adaptive softwae [Cheng 2008; Moin et al. 2009b; Song et al. 2011] also ely on this assumption. Depending on the available sensos and effectos, paamete adaptation, stuctual adaptation, o even a combination of both [McKinley et al. 2004] can be ealized. An adaptation engine may obseve paametes o the stuctue of the adaptable softwae though sensos. Likewise, the adaptation though effectos may change paametes o the stuctue of the adaptable softwae. In paticula, when focusing on adaptation at the level of softwae achitectues, we equie sensos and effectos suppoting stuctual adaptation. In addition, but only elevant fo advanced cases in which the monito and execute activities of feedback loops ae adapted, the sensos and effectos might have to be adapted as well. This has been investigated especially fo adaptive monitoing [Ramiez et al. 2010; Villegas and Mülle 2010; Ehles and Hasselbing 2011; Villegas et al. 2013]. This equies that the modeling language should also wok fo cases whee the adaptable softwae is dynamically instumented by adding, emoving, o changing sensos and effectos. Finally, fo layeed achitectues as discussed in the following, adaptation engines ae themselves subject to adaptation. In this case, the engines have to povide sensos and effectos to obtain eflective views of them as a basis fo adaptation [Andesson et al. 2009]. Theefoe, the modeling language fo specifying feedback loops should suppot ceating and maintaining eflective views of feedback loops. 1 JMX Instumentation and Agent Specification, v1.4, ( ) 2 Seve fo the Java Entepise Edition (Java EE), ( ) 3 OSGi Coe Release 5 Specification, OSGi Entepise Release 5 Specification, ( )

23 2.4 Layeed Achitectue Layeed Achitectue In addition to inta-loop and inte-loop coodination as aleady discussed, thee ae also cases whee the feedback loops have to opeate on top of each othe (cf. Figue 2.5). Laye n Evaluation Models Change Models Laye 2 Reflection Models Analyze Plan Monito Execute Monitoing Models Execution Models Evaluation Models Change Models Evaluation Models Change Models Laye 1 Analyze Reflection Models Plan Analyze Reflection Models Plan Monito Execute Monito Execute Monitoing Models Execution Models Monitoing Models Execution Models Laye 0 Adaptable Softwae Fig. 2.5: Layeed achitectue fo an adaptation engine Such a layeed achitectue is needed fo ealizing adaptive contol schemes [Isemann et al. 1992; Astom and Wittenmak 1994; Koka et al. 1999], hieachical contol achitectues [Findeisen et al. 1980; Kephat and Chess 2003], layeed achitectues as poposed fo obot softwae [Gat 1997], the efeence achitectue fo self-managed softwae systems [Kame and Magee 2007], o hieachical stuctues with intenal layes employed fo the softwae of self-optimizing mechatonic systems [Hestemeye et al. 2004]. Though the achitectue poposed by Gat [1997], Kame and Magee [2007], o adaptive contol schemes [Isemann et al. 1992; Astom and Wittenmak 1994; Koka et al. 1999] usually consist of thee o fewe layes, thee ae also appoaches having potentially a highe numbe of layes [Findeisen et al. 1980; Hestemeye et al. 2004]. In a layeed achitectue fo adaptation engines, besides coodinating feedback loops at diffeent layes, a feedback loop at a highe laye can adapt the feedback loop at the laye below. Theefoe, some fom of eflection of the lowe-laye feedback loop has to be povided at untime, which enables the adaptation of this feedback loop [Andesson et al. 2009]. If paamete adaptation is equied, it would be sufficient that the highe-laye loop can change some vaiables of the lowe-laye loop, like theshold values that effect the analysis and planning activities. Howeve, fo stuctual adaptation, the highelaye feedback loop has to opeate on a eflection model stuctually epesenting the feedback loop at the laye below and not only the feedback loop s paametes. Thus, the modeling language should leveage layeed achitectues by suppoting adaptable feedback loops at Layes 1..n and the povision of eflection models epesenting these feedback loops (in contast to eflection models epesenting the adaptable softwae discussed in Section 2.2) to enable thei stuctual adaptation by highe-laye feedback loops. In this context, declaative and pocedual eflection as poposed by Maes [1987] fo pogamming languages should be suppoted. In declaative eflection, a sepaate epesentation of the pogam is maintained and used fo meta-computations, like adaptation. In contast, pocedual eflection maintains no sepaate epesentation and the pogam is diectly used by meta-computations. Additionally, the language should suppot specifying feedback

24 12 2 Teminology, Concepts, and Requiements loops at Layes 2..n that pefom paamete and stuctual adaptation of the feedback loops at the layes below by opeating on the coesponding eflection models. 2.5 Off-line Adaptation Finally, the pomise of self-adaptive softwae is that the softwae is able to adjust itself and thus, that it automates and takes ove some of the adaptation activities that ae usually pefomed off-line in the context of maintenance and evolution. Howeve, it cannot be expected that self-adaptive softwae is able to cope with all needs fo evolution itself and thus, to fully automate and take ove all equied off-line adaptation activities. Evaluation Models Change Models Analyze Plan Reflection Models Development and Maintenance Envionment Evaluation Models Monito Execute Monitoing Models Execution Models Change Models Evaluation Models Change Models Analyze Plan Analyze Plan Reflection Models Reflection Models Monito Execute Monito Execute Monitoing Models Execution Models Monitoing Models Execution Models Adaptable Softwae Fig. 2.6: Off-line adaptation of self-adaptive softwae Consequently, besides ealizing a softwae with an adaptation engine fo the self-adaptation, a solution fo the co-existence of such an engine with off-line adaptation, and thus with typical maintenance and evolution is equied [Gacek et al. 2008; Moin et al. 2009c; Andesson et al. 2013]. Simila to [Andesson et al. 2013], we conside an adaptation activity to be off-line if it is pefomed extenally to the unning self-adaptive softwae as it is typically done today in development o maintenance envionments. In contast, if an adaptation activity is pefomed intenally to the self-adaptive softwae, we efe to on-line adaptation. Of paticula inteest is the enactment of an adaptation that has been analyzed and planned off-line to the unning self-adaptive softwae. Thus, the execute activity is pefomed on-line, while at the same time feedback loops might be opeating fo self-adaptation. Theefoe, the language and its untime envionment should suppot the co-existence of self-adaptation and maintenance/evolution, fo example, by poviding an inteface to monito the adaptation engine and to integate adaptations that have been analyzed and planned off-line to the unning self-adaptive softwae fo on-line execution. As depicted in Figue 2.6, such a co-existence has to suppot that the adaptable softwae can be adjusted at untime even though multiple feedback loops opeate on top of it, and that the feedback loops at diffeent layes can be adjusted at untime. These adjustments ae adaptations analyzed and planned off-line by enginees in a Development and Maintenance Envionment and executed on-line to the unning self-adaptive softwae.

25 Chapte 3 Modeling a Feedback Loop This section intoduces the EUREMA modeling language fo engineeing adaptation engines in selfadaptive softwae. The language is based on the concept of megamodels that oiginates fom the eseach field of model management in model-diven softwae development. A megamodel efes to a model that contains othe models and elationships between these contained models while the elationships constitute opeations woking on these models, like a model tansfomation [Babeo et al. 2007; Bézivin et al. 2003, 2004; Fave 2005]. EUREMA adopts this geneic concept fo specifying and executing feedback loops in self-adaptive softwae by consideing the feedback loop s knowledge as untime models and the individual adaptation activities as model opeations woking on these untime models. Thus, EUREMA (mega)models explicitly specify feedback loops by captuing the untime models, the inteplay between these models, and the flow of adaptation activities opeating on these untime models. Moeove, EUREMA models ae kept alive at untime fo executing feedback loops. Theeby, megamodel concepts ae leveaged at untime such that a feedback loop s untime models and adaptation activities ae explicitly maintained at untime beyond the initial development-time of the self-adaptive softwae. The poposed EUREMA modeling language is specific fo the engineeing of adaptation engines fo self-adaptive softwae and based on geneal modeling concepts fo behavioal and stuctual diagams. Theefoe, EUREMA povides two types of diagams: (1) A behavioal feedback loop diagam (FLD) is used to model a complete feedback loop o pats of a loop by means of individual adaptation activities and untime models. An FLD constitutes a megamodel module that encapsulates the details of a feedback loop o adaptation activities. (2) A stuctual laye diagam (LD) descibes how the diffeent megamodel modules and the adaptable softwae ae elated to each othe in a concete situation of the self-adaptive softwae. Thus, an LD povides an abstact and complete view of an instance of the self-adaptive softwae esticted to its achitectue. This view consides feedback loops as black boxes encapsulated in megamodel modules, thei elationships to each othe and to the adaptable softwae, while white-box views of megamodel modules ae povided by FLDs. In the following, we discuss the EUREMA language and its diagam types, and we show by illustative examples how a feedback loop can be specified by EUREMA models. 3.1 Oveview of the EUREMA Language The EUREMA language we ae poposing specifies a feedback loop in an FLD by means of models, model opeations, and the contol flow between opeations. The language shaes chaacteistics with 13

26 14 3 Modeling a Feedback Loop flowchats and data flow diagams: models ae the data that epesent, e.g., the adaptable softwae, and model opeations oganized in a contol flow ae computations that use and wok on models. As an example, an opeation can be an engine that checks constaints defined in a model on an achitectual model of the adaptable softwae. We modeled the MAPE-K feedback loop with EUREMA to give an oveview of the language. Figue 3.1 shows the FLD that is famed and labeled with its name MAPE-K. This feedback loop has an initial and a final state (Stat and Executed, espectively) as enty and exit points fo its execution. The adaptation activities of MAPE-K ae specified as model opeations that ae epesented by hexagon block aows and labeled with thei names (Monito, Analyze, Plan, and Execute). Each opeation has an exit compatment that specifies the opeation s etun status, like monitoed of the Monito opeation. The contol flow between opeations is explicitly specified by solid aows. Opeations wok on untime models epesented by ectangles and the usage of models as inputs o outputs is depicted by dotted aows. Thus, this megamodel specifies the sequential execution of the fou adaptation activities Monito, Analyze, Plan, and Execute that opeate all on the Knowledge that is captued in a untime model. MAPE-K Stat Monito monitoed Analyze analyzed Knowledge Plan changes planned Execute done Executed Laye-0 Laye-1 <tigge> :MAPE-K :Adaptable Softwae Fig. 3.1: Feedback Loop Diagam (FLD) fo MAPE-K Fig. 3.2: Laye Diagam (LD) fo MAPE-K Since we conside adaptation engines with potentially multiple feedback loops and a layeed achitectue (cf. Section 2), feedback loops ae located at a cetain laye and they have elationships o dependencies to othe feedback loops o to the adaptable softwae. To popely design, analyze, and undestand adaptation engines with multiple feedback loops in layeed achitectues, an abstact and complete view of the self-adaptive softwae is equied, which makes all feedback loops and thei elationships to othe feedback loops o to the adaptable softwae visible. Theefoe, EUREMA povides the laye diagam (LD) as it shown fo MAPE-K in Figue 3.2. This diagam eflects an instance view of the self-adaptive softwae and it specifies that an instance of the MAPE-K feedback loop is located at Laye-1 and that it diectly senses and effects the Adaptable Softwae instance at Laye-0. Sensing elationships ae eflected by dotted aows with filled aowheads, effecting elationships by dotted aows with hollow aowheads. A feedback loop that is specified by an FLD in EUREMA is depicted as a package with a white tab. In contast, a package with a black tab epesents (softwae) modules, like the adaptable softwae, that ae not specified by EUREMA. Finally, patitions in LDs epesent the layes of the self-adaptive softwae. In geneal, a feedback loop modeled with EUREMA equies the specification of a tigge that detemines when an instance of the feedback loop should be executed. In EUREMA, tigges fo a feedback loop efe to occuences of events emitted fom the modules (adaptable softwae o feedback loops) that ae obseved by the feedback loop. Thus, a tigge is defined in the LD by annotating the coesponding sensing elationship though which events ae emitted and obseved. Consideing the LD fo MAPE-K (Figue 3.2), the tigge is annotated to the aow epesenting the sensing elationship between the :MAPE-K feedback loop and the :Adaptable Softwae. Since the MAPE-K feedback loop is a bluepint, we omit details of tigges hee, but we discuss them fo the following examples. Summing up the oveview of the EUREMA language, white-box views and theefoe detailed behavioal specifications of feedback loops ae addessed by FLDs (e.g., Figue 3.1), while an LD povides a

27 3.2 Modeling a Single Feedback Loop 15 complete stuctual view of an instance of the self-adaptive softwae with black-box views of feedback loops (e.g., Figue 3.2). In the following, we discuss EUREMA in detail fo advanced cases of adaptation engines and feedback loops, which also enhances and efines the modeling language fo both types of diagams. 3.2 Modeling a Single Feedback Loop To discuss EUREMA in detail, we conside a component-based application to be the adaptable softwae. We assume that the application is adaptable at the achitectual level by changing paamete values of components, by adding/emoving components fom the achitectue, and by changing the composition of components. Tackling adaptation at the achitectual level is a popula appoach [Oeizy et al. 1998, 2008; Galan et al. 2004; Moin et al. 2009a] as it povides pomising abstactions fo paamete and stuctual adaptation [McKinley et al. 2004]. We keep the adaptable softwae geneic and abstact in this aticle because we do not want to discuss a specific adaptation engine fo a specific concen and adaptable softwae. In contast, we want to cove diffeent vaiants and equiements fo adaptation engines, which allows us to discuss the whole spectum of modeling concepts in EUREMA. At fist, self-epai capabilities should be added to the adaptable softwae by a feedback loop as shown in the LD in Figue 3.4. The FLD depicted in Figue 3.3 specifies the behavio of the Self-epai feedback loop that aims fo automatically ecoveing the adaptable softwae fom failues. Since this FLD specifies all adaptation activities fo self-epai, i.e., the monito, analyze, plan and execute activities (MAPE), the :Self-epai megamodel module in the LD is labeled with MAPE. Inspied by [Weyns et al. 2013], we use such labels to indicate which adaptation activities ae ealized by a megamodel module as defined in the FLD. Self-epai <<EvaluationModel>> Failue analysis ules <<Analyze>> failues Check fo no failues failues <<Monito>> updated Update model Monito w a [ELSE] Analyzed [C_SINCE(no failues) > 5] <<ReflectionModel>> Achitectual Model <<MonitoingModel>> <<ExecutionModel>> TGG Rules <<EvaluationModel>> Deep analysis ules <<Analyze>> Deep check fo failues a w detailed esults <<ChangeModel>> Repai stategies <<Plan>> Repai epaied <<Execute>> Effect done Executed Laye-0 Laye-1 RtException; 10s; Monito; MAPE :Self-epai :Adaptable Softwae Fig. 3.3: FLD fo Self-epai Fig. 3.4: LD fo Self-epai Initial state Final state Destuction state Model Contol flow t1 Opeation Model t2 Complex Model Opeation t1 t2 [condition1] [condition2] FLD Model Model usage Laye Laye Layes Megamodel Module Softwae Module Relationships <tigge> senses effects <va> uses (a) FLDs (b) LDs Fig. 3.5: Concete syntax of the EUREMA language fo (a) FLDs and (b) LDs In contast to the FLD fo MAPE-K (Figue 3.1), this FLD employs efined concepts of the language, whose concete syntax is depicted in Figue 3.5. The efined concepts enable the exclusive banching of

28 16 3 Modeling a Feedback Loop the contol flow. Theefoe, a model opeation may have moe than one etun status and thus, moe than one exit compatment used fo continuing the contol flow. At untime, the implementation of the model opeation detemines the etun status and theefoe, which exit compatment is activated. Moeove, the contol flow can be exclusively banched using the decision node (diamond element) and conditions. The language fo these conditions efes to counte and timing infomation about the execution of the feedback loop. Thus, conditions ae geneic and use execution infomation elated to EUREMA concepts to banch the contol flow, while the diffeent exit compatments of model opeations may depend on domain-specific infomation only known intenally to use-defined untime models and model opeation implementations. The othe concepts of the concete syntax fo FLDs and LDs have aleady been outlined in Section 3.1 o they will be discussed in the est of the aticle. Additionally, to suppot the modele s peception of FLDs, elements in FLDs can be substantiated by labels o steeotypes. Model opeations ae assigned to the typical adaptation activities of a feedback loop: Monito, Analyze, Plan, and Execute (cf. Section 2.1). Models ae steeotyped based on the pupose they seve in self-adaptive softwae, which esulted fom a categoization of untime models discussed in Section 2.2: MonitoingModel, ExecutionModel, CausalConnectionModel, ReflectionModel, EvaluationModel, ChangeModel, and AdaptationModel. Finally, the use of models by model opeations is substantiated to ceating, destoying, witing, eading, and annotating models. While eading a model does not have any side effects, wites modify the model in a way that potentially affects the adaptable softwae, and annotations to a model enich a model without affecting the adaptable softwae. With the FLD depicted in Figue 3.3, we modeled an extended vesion of the self-epai setting used in [Vogel and Giese 2010]. The Update and Effect opeations use tiple gaph gamma ules (TGG Rules) that specify by means of model tansfomation ules how the Achitectual Model eflecting the adaptable softwae is synchonized with the unning softwae. Thus, based on obsevations of the unning softwae, the Update opeation keeps the Achitectual Model up-to-date. The following analysis is conducted by the Check fo failues opeation that employs Failue analysis ules on the Achitectual Model. These ules define checks and constaints to identify citical failues. If no citical failues ae identified, the feedback loop teminates. Othewise, adaptation is equied to epai these failues. At fist, a decision is made whethe futhe analysis is needed. This is the case when the condition holds, which checks whethe the last execution of the Check fo failues opeation that has identified no failues happened moe than five consecutive executions in the past. Thus, the past five uns of the feedback loop wee not able to epai the failues and a moe thoough analysis may povide useful infomation fo the planning activity. This planning activity uses the analysis esults annotated by the pevious opeations to the Achitectual Model to select suitable Repai stategies. The selected stategies change the Achitectual Model to pescibe a econfiguation of the unning adaptable softwae. This econfiguation is executed to the adaptable softwae by the Effect opeation that synchonizes the changes on the Achitectual Model to the adaptable softwae and that finally teminates one un of the feedback loop. This example illustates how adaptation activities can be consideed as abstact model opeations that wok on untime models. Besides the contol flow between multiple opeations, the inteplay between opeations and untime models has to be made explicit because the models ae the basis fo coodinating diffeent adaptation activities within a feedback loop. Thus, this inteplay is simila to dependencies between adaptation activities, which ae elevant fo popely specifying and executing feedback loops in EUREMA.

29 3.3 Tigge fo Feedback Loops Tigge fo Feedback Loops In geneal, an EUREMA specification of a feedback loop includes a tigge that detemines when an instance of the feedback loop should be executed. We conside occuences of events as tigges fo feedback loop instances. Events ae emitted fom modules that ae eithe the adaptable softwae o feedback loops. We assume that the events ae modeled in a type hieachy that is efeenced by tigge specifications. Theeby, a tigge specification fo a feedback loop may only efe to events emitted fom those modules that ae sensed by the feedback loop. Thus, tigges ae specified in LDs by annotating the coesponding sensing elationships that eveal the flow of events fom one module to anothe module. This is exemplified in the LD in Figue 3.4 that defines a tigge fo the :Self-epai feedback loop sensing the :Adaptable Softwae. The tigge specification RtException; 10s; Monito; defines that the :Selfepai feedback loop stats execution if the :Adaptable Softwae emits an event of type RtException notifying about a untime exception in the adaptable softwae, and when ten seconds since the last execution of the :Self-epai feedback loop have expied. Finally, Monito points to the initial state of the self-epai feedback loop (cf. FLD in Figue 3.3), in which the execution should stat. In geneal, EUREMA suppots a simple language fo specifying tigges. A tigge fo a feedback loop instance consists of thee pats: <events>; <peiod>; <initialstate>;. The fist pat, <events>, efes to a list of event types. If an event of one of these types occus, the tigge is activated. The second pat, <peiod>, defines the minimal time peiod between two consecutive uns of the feedback loop instance, which is measued as the time elapsed between the temination of the pevious un and the beginning of the next un. Thus, even if the equied event occus befoe the specified time peiod has elapsed, the next un of the feedback loop instance will be delayed until the time peiod eventually has elapsed. Delaying the execution of the feedback loop instance avoids thashing effects due to the polifeation of events and it allows the adaptation being executed by the pevious un of the feedback loop instance to take effect in the self-adaptive softwae. Likewise, selecting specific event types in the <events> pat of a tigge also seves as a filte that avoids the execution of a feedback loop instance fo evey occuing event. Finally, the thid and thus the last pat of a tigge, <initialstate>, efes to the initial state as defined in the FLD, in which the feedback loop instance should stat its execution. The fist two pats of a tigge specification ae optional, but one of them must be pesent. If no <events> ae specified, the <peiod> must be defined, which esults in a tigge that peiodically executes the feedback loop instance. If no <peiod> is defined, the <events> must be specified and the tigge executes the feedback loop instance when the coesponding events have occued and the cuent un of the instance has teminated. In EUREMA, an instance of a feedback loop is not eentant, and thus, any events that occu while the feedback loop instance is unning ae queued. Thus, thee ae no concuent executions of the same feedback loop instance. 3.4 Modulaizing Feedback Loop Diagams Besides modeling a complete feedback loop in a single FLD, EUREMA suppots the modula specification of feedback loops. Thus, individual adaptation activities of a feedback loop ae specified in distinct FLDs that can be composed to fom a complete feedback loop. The motivation fo a modula specification is twofold. Fist, it povides futhe abstactions fo the enginee. Specifying a moe complex feedback loop also makes the elated FLD complex and had to compehend. To ease the modeling and peception of feedback loops in EUREMA, pats of a feedback loop can be abstacted, modeled in dedicated FLDs, and efeenced by othe FLDs. Second, this suppots options fo euse and

30 18 3 Modeling a Feedback Loop vaiability modeling. Pats of a feedback loop that ae specified in dedicated FLDs can be eused in othe feedback loops o they can be eplaced by altenative pats specified in othe FLDs. The latte leveages the modeling of vaiability fo feedback loops in an adaptation engine. Fo instance, the analysis activity of the Self-epai feedback loop depicted in Figue 3.3 can be abstacted and specified in its own FLD called Self-epai-A as shown in Figue 3.6. This analysis activity has one initial state (Stat) and two final states eflecting whethe citical failues have been identified (Failues) o not (OK). This FLD can be (e)used and invoked as a megamodel module by othe FLDs. Theefoe, we intoduce the concept of a complex model opeation, which is shown fo the Self-epai-A FLD in Figue 3.7. Self-epai-A <<EvaluationModel>> Failue analysis ules Stat <<Analyze>> failues Check fo no failues failues a OK [ELSE] [C_SINCE(no failues) > 5] <<ReflectionModel>> Achitectual Model <<EvaluationModel>> Deep analysis ules <<Analyze>> Deep check fo failues a detailed esults Failues Stat <va> <<ReflectionModel>> Achitectual Model a (a) Failues OK <va> <<ReflectionModel>> Achitectual Model a (b) Failues OK Fig. 3.6: FLD fo the analyze activity of self-epai Fig. 3.7: Complex model opeation A complex model opeation defines a signatue to invoke a megamodel module defined by an FLD. In geneal, a signatue efes to the initial and final states of the coesponding FLD and to untime models that have to be povided as paametes of the invocations. In the example, based on the initial and final states of the Self-epai-A FLD (Figue 3.6), the complex model opeation shown in Figue 3.7a has one enty compatment called Stat and two exit compatments called Failues and OK. Thus, initial and final states of an FLD ae mapped to enty and exit compatments of a complex model opeation, espectively. This ensues that the feedback loop using a complex model opeation can popely invoke a module by defining the initial state fo stating the execution of the module, and that it can popely esume execution afte the invoked module has teminated by efeing to the final states. If an FLD specifies exactly one initial o final state, the enty o exit points fo execution ae uniquely defined such that the enty o exit compatments of the complex model opeation can be omitted. This is depicted in Figue 3.7b that shows the complex model opeation fo the Self-epai-A FLD, which omits the explicit enty compatment since the FLD has exactly one initial state. In geneal, the enty (exit) compatments of a complex model opeation have to be a subset of the initial (final) states of the coesponding FLD. Howeve, all those final states that ae eachable fom the initial states selected fo enty compatments must be selected fo exit compatments. Moeove, the signatue of an FLD defines which untime models have to be povided as paametes when invoking a module. In the example, it is the Achitectual Model as shown in Figue 3.7, while the othe untime models used in the Self-epai-A megamodel module, namely Failue analysis ules and Deep analysis ules, ae povided by the module itself. Since we conside self-adaptive softwae that evolves thoughout its lifetime, EUREMA adopts a dynamic typing appoach in contast to a static type system fo megamodel modules and complex model opeations. Finally, a complex model opeation is labeled with an icon, a small ounded ectangle, to distinguish it fom the othe type of model opeations in FLDs and to eveal that it uses and invokes anothe megamodel module defined by an FLD. Moeove, when using a complex model opeation in an FLD, it must be given a name fo the vaiable <va> (cf. Figue 3.7), which is bound to a concete megamodel module that actually should be invoked. Fo example, to (e)use the analysis activity by means of the FLD shown in Figue 3.6, one of the complex model opeations depicted in Figue 3.7 can be used like a nomal model opeation in any othe

31 3.4 Modulaizing Feedback Loop Diagams 19 FLD specifying a feedback loop. Figue 3.8 depicts the FLD fo the Self-epai feedback loop that uses the complex model opeation, named Analyze, to invoke the analysis activity. Thus, a complex model opeation used in an FLD abstacts fom anothe FLD and it synchonously invokes the adaptation activities specified in the abstacted FLD when being executed. Thus, an FLD used by anothe FLD does not need a tigge specification as its execution is tiggeed by an explicit call when the coesponding complex model opeation is executed. Self-epai <<Monito>> updated Update model w Monito <<Analyze>> Analyze a Failues OK Analyzed <<ReflectionModel>> Achitectual Model <<MonitoingModel>> <<ExecutionModel>> TGG Rules <<ChangeModel>> Repai stategies <<Plan>> Repai w epaied <<Execute>> Effect done Executed Laye-0 Laye-1 RtException; 10s; Monito; Analyze A :Self-epai-A M..PE :Self-epai :Adaptable Softwae Fig. 3.8: FLD fo the Self-epai feedback loop using a complex model opeation depicted in Figue 3.7b to invoke the analysis activity defined in the FLD shown in Figue 3.6. Fig. 3.9: LD fo Self-epai Usage elationships between megamodel modules defined by FLDs ae dependencies that have to be made explicit, which is addessed in EUREMA by stuctual LDs. The LD fo the self-epai example shown in Figue 3.9 explicitly models that the :Self-epai feedback loop uses the :Self-epai-A module. A usage elationship is eflected by a solid aow with a filled aowhead and it is labeled by the vaiable name of the coesponding complex model opeation (Analyze in this example) to bind the opeation to the concete megamodel module (:Self-epai-A in this example) to be invoked. Moeove, the LD shows by the labels M..PE and A attached to megamodel modules that the :Self-epai module diectly ealizes the monito, plan, and execute activities, while the analyze activity has been extacted and ealized by the :Self-epai-A module. Altogethe, the specification of the self-epai feedback loop as shown in Figues 3.6, 3.8, and 3.9 is equivalent to the specification shown in Figues 3.3 and 3.4 consideing functionality. The FLD shown in Figue 3.8 also has the same tigge specification as the FLD shown in Figue 3.3. The only diffeence is the numbe of FLDs used fo the specification, which is motivated by design decisions concening appopiate abstactions and modulaity. Fo example, besides the analysis activity, all adaptation activities of a feedback loop can be specified in distinct FLDs, and a high-level FLD compising fou complex model opeations fo each activity (monito, analyze, plan, and execute) integates all the coesponding FLDs. In geneal, the depth of the abstaction and the elated invocation elationships ae not esticted. This leveages diffeent abstaction levels fo modeling feedback loops and it assists softwae enginees in modeling and undestanding feedback loops. Moeove, it suppots euse of feedback loop fagments and it eveals vaiation points in feedback loops. Assuming we have modeled an additional analysis activity called Self-epai-A2 in a distinct FLD, which employs a diffeent analysis technique than the activity Self-epai-A, both activities ae altenative analyses to be used by the Self-epai feedback loop. This constitutes a vaiation point eflected in the LD in Figue If the FLDs of both altenatives have the same signatue, both of them can be used by the same complex model opeation. Then, to switch between these altenatives, it is sufficient to change the binding between the complex model opeation and the megamodel module, e.g., by e-outing the usage elationship Analyze to point to :Self-epai-A2 instead of :Self-epai-A in the LD (cf. Figue 3.10).

32 20 3 Modeling a Feedback Loop A :Self-epai-A :selfrepai.monitoimpl Laye-0 Laye-1 RtException; 10s; Monito; M..PE :Self-epai :Adaptable Softwae Analyze A :Self-epai-A2 Laye-0 Laye-1 RtException; 10s; Monito; M..PE :Self-epai :Adaptable Softwae Update :selfrepai. LightWeightMonitoImpl Fig. 3.10: Vaiability fo a complex model opeation Fig. 3.11: Vaiability fo a model opeation The same idea is applied in EUREMA to bind an (atomic) model opeation to the softwae module actually implementing the behavio of this opeation. EUREMA models and in paticula FLDs specify when a model opeation should be executed, which untime models ae used as input and output, and the etun states of the opeation. Thus, model opeations in FLDs have to be bound to softwae modules poviding implementations fo these opeations. The LD in Figue 3.11 depicts an example showing that the Update opeation of the :Self-epai module is bound to an implementation, the softwae module :selfrepai.monitoimpl. Thus, when the Update opeation is executed, this softwae module is invoked with the untime models specified as input of the opeation in the FLD (Figue 3.8), namely the Achitectual Model and the TGG Rules. Softwae modules ae typically code-based o eused MDE tools, like a model synchonization engine in this paticula case. Thus, softwae modules ae not modeled by EUREMA and theefoe, they ae epesented in LDs by packages with black tabs. Likewise to altenative megamodel modules fo complex model opeations (cf. Figue 3.10), altenative softwae modules fo atomic model opeations can be modeled in LDs, like shown in Figue The softwae module :selfrepai.lightweightmonitoimpl is an altenative fo the :selfrepai.monitoimpl module, and the Update opeation can be bound to one of them and switch between them by ediecting the usage elationship Update fom one softwae module to the othe one. In the examples so fa and in the following ones, we omit the modeling of softwae modules in LDs since they just define the binding of model opeations to thei implementations, which is elevant fo the execution, but they ae consideed as black boxes by EUREMA and povide no futhe infomation elevant fo the design of feedback loops. In geneal, such vaiations points at the level of megamodel modules specified by FLDs o softwae modules consideed as black boxes eify vaiants fo the design and execution of feedback loops and adaptation engines. Moeove, they can be leveaged at untime to adjust feedback loops by switching between these vaiants, like between diffeent analysis techniques o between diffeent implementations of model opeations. Summing up, specifying adaptation engines in multiple FLDs suppots modula design and diffeent abstaction levels fo feedback loops, euse of feedback loops fagments, and identifying and exploiting vaiability of feedback loops duing design and execution of self-adaptive softwae.

33 Chapte 4 Modeling Multiple Feedback Loops Having pesented the modeling of a single feedback loop, this section discusses how EUREMA addesses the modeling of multiple feedback loops fo an adaptation engine. Multiple feedback loops ae likely to be employed in a self-adaptive softwae if multiple concens, like self-epai o self-optimization, have to be handled, if locality is elevant, like localized and global adaptation, o if contol should be decentalized. In the following, we conside the case of multiple concens. Each concen is handled by an individual feedback loop, because each concen equies its specific untime models and model opeations. Based on ou example discussed so fa, the self-adaptive softwae employs a self-epai feedback loop to handle failues at untime (cf. Section 3) and it should be additionally equipped with a self-optimization feedback loop to manage pefomance. This additional loop is specified in the FLD shown in Figue 4.1. Fom the modeling pespective, the Self-optimization feedback loop is quite simila to the self-epai loop. The Update and Effect opeations synchonize the Achitectual Model with the adaptable softwae fo monitoing and fo executing adaptation. A diffeence to the self-epai feedback loop is that the self-optimization feedback loop has two initial states eithe initiating the loop with the monito o the analyze activity. Moeove, in contast to the self-epai feedback loop, the analysis and planning activities of the self-optimization feedback loop do not only use the Achitectual Model to exchange infomation but additionally a Queueing Model. It is used to identify bottlenecks in the adaptable softwae o easonable values fo paametes given by the Paamete vaiability model to adjust the configuation of the adaptable softwae, which aims fo esolving the identified bottlenecks. The self-optimization feedback loop should be tiggeed in its initial state Monito when the load on the adaptable softwae s platfom inceases, which causes a LoadIncease event, and when 60s afte the last execution of this feedback loop have expied. This is specified by the tigge in the LD shown in Figue 4.2. In geneal, EUREMA suppots the specification of multiple feedback loops by distinct FLDs. Howeve, employing multiple feedback loops in a self-adaptive softwae aises questions of possible intefeences o inteactions between these feedback loops, which might equie coodination of these feedback loops. These questions ae discussed in the following. 4.1 Independent Feedback Loops Assuming thee ae no intefeences between multiple feedback loops used in an adaptation engine, e.g., because the diffeent concens ae not competing o conflicting, the coesponding feedback loops 21

34 22 4 Modeling Multiple Feedback Loops Self-optimization <<EvaluationModel>> Queueing Model Analyze <<Analyze>> no bottlenecks Bottleneck identification bottleneck <<Monito>> Update Monito w updated model w w Analyzed <<ReflectionModel>> Achitectual Model <<MonitoingModel>> <<ExecutionModel>> TGG Rules <<ChangeModel>> Paamete vaiability <<Plan>> Adjust adjusted paams w <<Execute>> Effect done Executed Laye-0 Laye-1 MAPE :Self-optimization LoadIncease 60s; Monito; RtException; 10s; Monito; :Adaptable Softwae A :Self-epai-A Analyze M..PE :Self-epai Fig. 4.1: FLD fo Self-optimization Fig. 4.2: LD fo two feedback loops can be specified and executed completely independent fom each othe. Both feedback loops have individual tigges that might be activated concuently. Consequently, the feedback loops might un concuently and thee is no diect inteaction o coodination between them. This is specified in the LD depicted in Figue 4.2 that shows two feedback loops sensing and effecting the adaptable softwae. In contast to the LD depicted in Figue 3.9 fo the case of a single feedback loop, this LD just adds the :Self-optimization feedback loop in paallel to the :Self-epai feedback loop within the same laye. Each of the two feedback loops maintains an Achitectual Model eflecting the adaptable softwae by the monitoing activity (cf. FLDs in Figues 3.8 and 4.1). By monitoing the adaptable softwae and updating the achitectual model, a feedback loop can obseve the adaptation executed to the adaptable softwae by the othe feedback loop. Thus, based on the monitoing, both feedback loops indiectly inteact, but thee ae no diect inteactions between the two feedback loops in place. 4.2 Coodination of Multiple Feedback Loops Though the concuent and independent execution of multiple feedback loops is conceivable, thee ae usually intefeences o inteactions between feedback loops that have to handled by coodinating adaptations of the diffeent loops. Fo example, thee ae typical concens that ae competing, like failues and pefomance, which might esult in conflicting adaptations. The self-epai feedback loop might pefom an adaptation to heal a failue in the adaptable softwae, which might degade the softwae s pefomance contolled by the self-optimization feedback loop. The othe way aound, an adaptation to optimize the pefomance might cause failues in the adaptable softwae. Such potential conflicts equie the coodination of the feedback loops. In EUREMA, the coodination of multiple feedback loops is explicitly modeled with FLDs. Such megamodel modules coodinate othe modules that specify individual feedback loops by synchonizing thei execution. In the following, we discuss two basic design altenatives fo coodinating two feedback loops, in paticula fo self-epai (Figue 3.8) and self-optimization (Figue 4.1). Both altenatives ae modeled with FLDs and they ensue the coodinated execution of the feedback loops eithe by sequencing complete feedback loops o individual adaptation activities of the diffeent feedback loops.

35 4.2 Coodination of Multiple Feedback Loops Sequencing Complete Feedback Loops A simple way to coodinate two feedback loops is to execute them sequentially. This is specified in the FLD depicted in Figue 4.3, which uses complex model opeations to synchonously invoke the individual feedback loops. Coveing multiple capabilities, like self-epai and self-optimization, leads towad selfmanagement, which motivated the name of the FLD. Explicitly coodinating multiple feedback loops facilitates the shaing of untime models o even adaptation activities among the loops. As specified by the FLD depicted in Figue 4.3, both feedback loops use the same instances of the Achitectual Model and TGG Rules. Moeove, they shae the monitoing activity in cetain situations whee one feedback loop also pefoms the monitoing fo the othe loop as discussed in the following. A :Self-epai-A Analyze Self-management-1 Selfmanage Monito Repai <<MonitoingModel>> <<ExecutionModel>> TGG Rules Analyzed Executed w Analyze Monito <<ReflectionModel>> Achitectual Model Optimize w Analyzed Executed Self-managed Laye-0 Laye-1 MAPE :Self-optimization Optimize RtException, LoadIncease; 35s; Self-manage; :Self-management-1 :Adaptable Softwae M..PE :Self-epai Repai Fig. 4.3: FLD fo Self-management-1: sequencing complete feedback loops by invoking the self-epai loop (Figue 3.8) followed by the self-optimization loop (Figue 4.1). Fig. 4.4: LD fo Self-management-1 In this self-management example, a highe pioity is assigned to epaiing failues than to optimizing the pefomance because failues ae often moe hamful than slow esponse times. Moeove, optimizing the pefomance of a failing system befoe the failues have been epaied is not easonable. Theefoe, the self-epai feedback loop is executed befoe the self-optimization loop. In the FLD shown in Figue 4.3, Repai invokes the self-epai feedback loop as specified by the FLD in Figue 3.8 to stat in its initial state Monito. Thus, the monitoing and analysis activities ae caied out, while the fist one updates the Achitectual Model to eflect the cuent state of the adaptable softwae, and the latte one analyzes this model fo failues. Depending on whethe citical failues have been found o not, the feedback loop eithe continues with the following adaptation activities o it teminates, espectively. This influences the subsequent execution of the self-optimization feedback loop. If no failues have been identified, the self-epai feedback loop does not need to plan and execute any adaptation and it teminates in the state Analyzed. The subsequent self-optimization feedback loop may immediately stat with the analysis activity because the monitoing activity of the pevious self-epai loop aleady updated the shaed Achitectual Model and no adaptation has been pefomed by the self-epai loop on this model and the adaptable softwae. Thus, the complex model opeation Optimize in Figue 4.3 invokes the Self-optimization loop that begins execution in the initial state Analyze (cf. the contol flow that connects the exit compatment Analyzed of the Repai opeation to the enty compatment Analyze of the Optimize opeation). If no bottlenecks have been identified, the self-optimization feedback loop teminates in the state Analyzed. Othewise, it caies out the plan and execute activities, and teminates in the state Executed. On the othe hand, if the self-epai feedback loop has identified failues, it plans and executes changes to the adaptable softwae and it teminates in the state Executed (cf. Figue 3.8). Thus, the adaptable softwae has been adapted, which equies that the subsequent self-optimization feedback loop

36 24 4 Modeling Multiple Feedback Loops pefoms the monitoing activity to obseve the effects of this adaptation. Thus, the self-optimization loop is invoked by the complex model opeation Optimize shown in Figue 4.3 to begin execution in the initial state Monito (cf. the contol flow that connects the exit compatment Executed of the Repai opeation to the enty compatment Monito of the Optimize opeation). Afte caying out the monitoing and analyze activities, the self-optimization feedback loop eithe teminates o, if equied, pefoms the plan and execute activities simila to the pevious case. This coodination design synchonizes diffeent feedback loops by sequentially executing them and by using the adaptable softwae as a synchonization point if one loop pefoms an adaptation. Thus, an adaptation pefomed by one feedback loop is executed to the adaptable softwae befoe anothe feedback loop stats its execution with the monitoing activity to obseve the executed adaptation and its effects. If a feedback loop does not pefom any adaptation, the subsequent loop may stat ight away with the analysis activity. Thus, thee is no need fo the subsequent feedback loop to pefom the monitoing activity because the pevious feedback loop aleady pefomed the monitoing and it has not adapted the eflection model (the Achitectual Model in ou example) and the adaptable softwae. Othewise, monitoing would be equied fo obseving the effects of the executed adaptation. By modeling the coodination in an FLD (Figue 4.3), the coodination becomes explicit at the achitectual level and visible in the LD as shown in Figue 4.4. The :Self-management-1 module uses the :Self-epai and :Self-optimization modules though the complex model opeations Repai and Optimize that ae bound to the coesponding modules. The LD also highlights that the :Self-management-1 module itself does not pefom any adaptation activity because it has no label in contast to the labels MAPE fo :Self-optimization and M..PE fo :Self-epai. Thus, the :Self-management-1 just synchonizes the othe modules in sensing and effecting the adaptable softwae. Consequently, the execution of the :Self-epai and :Self-optimization feedback loops is not tiggeed individually and both feedback loops do not need any tigge specification. In contast, a tigge is specified fo the :Self-management-1 module that activates the execution of these two feedback loops by synchonously invoking them with complex model opeations. As specified in the LD in Figue 4.4, the tigge fo the :Self-management-1 module combines the individual tigges of the self-epai and selfoptimization feedback loops discussed befoe. Thus, the :Self-management-1 module is executed if an event of type RtException indicating potential failues o LoadIncease indicating potential pefomance poblems in the adaptable softwae occus, and when at least 35s afte the pevious execution of this module have elapsed. 1 As discussed below, this tigge is also used fo the othe design altenative Sequencing Analysis and Planning of Feedback Loops The othe design altenative fo coodinating multiple feedback loops synchonizes the feedback loops in shaed monito and execute activities, while the individual analyze and plan activities ae executed sequentially. Theefoe, in the example of coodinating the self-epai (Figue 3.8) and the selfoptimization (Figue 4.1) feedback loops, the analyze and plan activities of each of these loops ae specified in dedicated FLDs as shown in Figue 4.5. In simple tems, the analyze and plan activities have just been cut out fom the above FLDs and no changes have been done to thei specifications. 1 To keep the example simple, we have chosen a peiod of 35s fo the coodinated execution of both feedback loops as a compomise of the individual peiods of 10s fo the self-epai and 60s fo the self-optimization loop. Howeve, the example can be extended to suppot these individual peiods: the peiod fo the :Self-management-1 module can be set to 10s and thus, the self-epai loop is executed in the same peiod by the opeation Repai (cf. Figue 4.3). To execute the self-optimization loop with a peiod of 60s, decision nodes can be added between the opeations Repai and Optimize in Figue 4.3 to check whethe 60s since the last execution of the Optimize opeation have elapsed. If this is the case, the Optimize opeation will be executed, othewise it will be skipped and potentially executed in the next un of :Self-management-1. Thus, EUREMA does not equie that coodinated feedback loops must be executed with the same fequency.

37 4.2 Coodination of Multiple Feedback Loops 25 Self-epai-AP <<EvaluationModel>> Failue analysis ules <<Analyze>> failues Check fo no failues failues Analyze a Analyzed [ELSE] [C_SINCE(no failues) > 5] <<ReflectionModel>> Achitectual Model <<EvaluationModel>> Deep analysis ules <<Analyze>> Deep check detailed esults fo failues a w (a) Self-epai <<Plan>> Repai <<ChangeModel>> Repai stategies epaied Planned Self-optimization-AP <<EvaluationModel>> Queueing Model Analyze w w Analyzed <<ReflectionModel>> Achitectual Model (b) Self-optimization <<ChangeModel>> Paamete vaiability <<Plan>> Adjust adjusted paams w Planned Fig. 4.5: Analyze and plan activities of (a) self-epai and (b) self-optimization. The coodination of the self-epai and self-optimization feedback loops, specifically of thei analyze and plan activities, is specified in the Self-management-2 FLD depicted in Figue 4.6. Likewise to the pevious examples, the Update and Effect opeations synchonize the Achitectual Model with the adaptable softwae espectively fo monitoing and fo executing adaptation. Since the self-epai and the self-optimization feedback loops wok on the same instance of the Achitectual Model, they shae the monito and execute activities. Howeve, the analyze and plan activities ae specific fo the addessed concens, namely failues and pefomance, and they decide if and how the system should be adapted. Thus, they must coodinate each othe to tackle competing concens and as a consequence potentially conflicting adaptations. Self-management-2 <<Monito>> Update Self-manage <<Analyze>> <<Plan>> RepaiAP <<Analyze>> no bottlenecks Bottleneck identification bottleneck updated model w Planned w <<Analyze>> <<Plan>> OptimizeAP Analyzed Planned <<ReflectionModel>> Achitectual Model w <<MonitoingModel>> <<ExecutionModel>> TGG Rules [ELSE] Analyzed [C_SINCE( RepaiAP::Planned) = 0] <<Execute>> Effect done Self-managed Laye-0 Laye-1 AP :Self-optimization-AP OptimizeAP RtException, LoadIncease; 35s; Self-manage; :Adaptable Softwae AP :Self-epai-AP RepaiAP M..E :Self-management-2 Fig. 4.6: FLD fo Self-management-2: sequencing the analysis and planning activities of the self-epai (cf. Figue 4.5a) and self-optimization (cf. Figue 4.5b) feedback loops. Fig. 4.7: LD fo Self-management-2 Theefoe, the analyze and plan activities fo self-epaiing failues ae executed befoe the analyze and plan activities fo self-optimizing pefomance. This is modeled in the FLD (Figue 4.6) by complex model opeations sequentially and synchonously invoking the modules specifying the analyze and plan activities fo both concens as depicted in Figue 4.5. The Achitectual Model is only modified by the self-epai s plan activity if the elated analyze activity has identified citical failues in the adaptable softwae. These modifications ae planned adaptations in ode to epai the failues and they have been applied at the model level but they have not been effected to the adaptable softwae. The subsequent analyze and plan activities of the self-optimization feedback loop use the Achitectual Model that has been potentially modified by the self-epai s plan activity. If the model has not been modified, thee ae no conflicting adaptations. Othewise, the adaptations poposed by the self-epai feedback loop must be handled by the self-optimization loop. This is detemined by the implementation of the model opeations of the feedback loops. Conceivable solutions ae that the self-optimization feedback loop must adhee to the adaptation planned by the self-epai feedback loop, o the othe way

38 26 4 Modeling Multiple Feedback Loops aound, that it just has to conside the planned adaptation as a poposal and it may evoke the poposal in ode to independently plan its own adaptation. Moeove, compomises between adaptations planned by both feedback loops ae conceivable, e.g., based on utility functions. Consideing the FLD in Figue 4.6, when the self-optimization s analyze and plan activities teminate, the Effect opeation is executed if adaptations ae poposed in the Achitectual Model by the selfepai s o the self-optimization s plan activities. Thus, at least one of the complex model opeations RepaiAP o OptimizationAP must teminate in the state Planned. Othewise, the Self-management-2 loop teminates in the state Analyzed because no citical failues and no bottlenecks have been identified, which does not equie any adaptation to be planned and executed to the adaptable softwae. The coesponding LD fo this design altenative to coodinate the two feedback loops is depicted in Figue 4.7. The :Self-management-2 module senses and effects the adaptable softwae and it uses the :Self-epai-AP and :Self-optimization-AP modules though the complex model opeations RepaiAP and OptimizeAP, espectively. Likewise to the othe coodination design, the :Self-management-2 module equies a tigge defining when it should be executed, while the :Self-epai-AP and :Self-optimization-AP modules ae synchonously invoked by the :Self-management-2 module using complex model opeations. Fo the :Self-management-2 module, the same tigge can be used as fo the :Self-management-1 module discussed above. The LD of this coodination design highlights by the label M..E that the :Self-management-2 module pefoms the monito and execute activities, while the analyze and plan activities (AP) ae pefomed by the :Self-optimization-AP and :Self-epai-AP modules. This section and the pevious one have discussed how adaptation engines ae specified in EUREMA by means of behavioal FLDs defining feedback loops and LDs poviding stuctual views of adaptation engines. Theeby, the coodination of multiple feedback loops can be specified with the same modeling concepts as used fo specifying individual feedback loops. In paticula, modeling the coodination with FLDs and LDs shows how the coodination can be explicitly specified at a high-level of abstaction. The coodination is achieved by executing inteacting feedback loops o inteacting adaptation activities of diffeent loops in a contolled manne by sequential and synchonous invocations though complex model opeations. Explicitly modeling the coodination enables the shaing of untime models, like eflection models, o adaptation activities, like monitoing, among multiple feedback loops. This potentially educes the monitoing costs at untime. Moeove, if coodination among feedback loops is not equied, EUREMA suppots the specification and execution of individual feedback loops completely independent fom each othe.

39 Chapte 5 Modeling Layeed Achitectues So fa we have discussed the modeling of feedback loops fo adaptation engines with a single laye. Howeve, as agued in Section 2.4, thee ae paticula cases, like adaptive contol, whee feedback loops have to opeate on top of each othe. This calls fo a layeed achitectue of adaptation engines, which oganizes feedback loops in layes. A feedback loop at a highe laye contols a feedback loop at the laye diectly below, while the feedback loops at the lowest laye of an adaptation engine diectly contol the adaptable softwae. Contolling a feedback loop equies adaptable feedback loops that can be adjusted by means of paamete o stuctual adaptation. While fo paamete adaptation it is often sufficient that a highelaye feedback loop obseves and adapts individual vaiables of the lowe-laye feedback loop, stuctual adaptation equies achitectual views. Such views can be povided by eflection models epesenting adaptable feedback loops. In the following, we discuss how layeed achitectues fo adaptation engines ae modeled in EUREMA and how eflection models and adaptation of feedback loops ae suppoted by EUREMA. Feedback loops specified by EUREMA ae adaptable by constuction because EUREMA models ae kept alive at untime as feedback loop specifications and they ae executed by an intepete. The EUREMA intepete is able to cope with dynamic changes of EUREMA models at untime and even while executing these models. EUREMA suppots adaptation of feedback loops that efe to concepts of the EUREMA modeling language. As eflected in LDs, a feedback loop can be adapted by changing the binding between complex model opeations and megamodel modules that ae defined by FLDs, and between model opeations and softwae modules implementing these opeations. This has been discussed in Section 3.4 and exemplified by the LDs depicted in Figues 3.10 and Additionally, LDs define the tigge fo a feedback loop instance that can be dynamically adjusted by adapting its paametes <events>, <peiod>, and <initialstate>. Thus, types of events whose occuences tigge a feedback loop instance can be added o emoved fom the tigge specification, the peiod of a tigge can be adjusted, and finally, a diffeent initial state of the feedback loop can be chosen fo initiating the execution. All these kinds of adaptation modify the tigge specification o the composition among megamodel and softwae modules, but they do change intenals of a module. While EUREMA completely abstacts fom intenals of softwae modules, intenals of megamodel modules and theefoe feedback loops as defined by FLDs can be dynamically modified. Adapting intenals of a feedback loop concens EUREMA concepts used in FLDs, namely untime models and model opeations including thei contol flow and usage of untime models. Thus, EUREMA suppots to dynamically adjust untime models used within a feedback loop, e.g., to eplace the eval- 27

40 28 5 Modeling Layeed Achitectues uation and change models that detemine the analyze and plan activities. Moeove, model opeations can be adjusted by adding, emoving, o eplacing them. This typically equies the adaptation of the contol flow eflected by links between model opeations, and the usage of untime models eflected by links between model opeations and untime models. Besides this stuctual adaptation, the contol flow can be adjusted by paamete adaptation when decision nodes ae used. Decision nodes enable the conditional banching of the contol flow that can be adapted by changing the conditions of individual banches. In layeed achitectues of adaptation engines, such adaptations of feedback loops ae conducted by othe feedback loops opeating at highe layes. In EUREMA, the modeling of highe-laye feedback loops that adapt lowe-laye feedback loops is simila to modeling any feedback loop as discussed in Section 3. Howeve, a paticula aspect is the ceation and maintenance of eflective views of adaptable feedback loops, which ae used by highe-laye feedback loops as a basis fo adaptation. This will be discussed by the following example. We conside the self-adaptive softwae with self-epai capabilities as discussed in Section 3. Thus, as shown by the LD in Figue 3.9, the self-epai feedback loop diectly senses and effects the adaptable softwae. This feedback loop aims fo automatically healing failues in the adaptable softwae by applying pe-defined epai stategies (cf. FLD in Figue 3.8). Howeve, these epai stategies need not to be able to handle all kinds of failues. This would equie that all kinds of failues could have been anticipated when developing and deploying these stategies, which is usually not the case given the uncetainty concening self-adaptive systems and thei envionments. Thus, the epai stategies defined in a untime model have to be maintained and adapted at untime. This task can be assigned to anothe feedback loop that synthesizes new epai stategies on demand and povides them to the selfepai feedback loop. Thus, the othe feedback loop is located at a highe laye because it adapts the self-epai feedback loop and it pefoms time-consuming computations to synthesize new stategies. Besides sensing and effecting elationships between feedback loops at diffeent layes, diffeent time scales of feedback loops ae a basic citeia fo placing feedback loops in diffeent layes (cf. [Kame and Magee 2007]). A feedback loop ealizing ugent o fequent adaptations must wok at shote time scales and thus, it is placed at a lowe laye. In contast, a feedback loop pefoming long-tem o complex planning that is athe aely equied often wok at longe time scales, which places the loop at a highe laye. In the following, we discuss two options of the highe-laye feedback loop fo ou self-epai example, eithe applying declaative eflection (Section 5.1) o pocedual eflection (cf. Section 5.2). In declaative eflection, use-defined eflection models can be applied, while in pocedual eflection, the EUREMA models that specify feedback loops ae diectly used as eflection models. 5.1 Declaative Reflection Use-defined Reflection Models At fist, we discuss the option of declaative eflection between layeed feedback loops. The highe-laye feedback loop employing a use-defined eflection model and contolling the self-epai feedback loop is specified by the FLD Self-epai-stategies shown in Figue 5.1. The monito activity obseves the self-epai feedback loop and maintains the Self-epai Model that eflects the self-epai loop. Using this eflection model, the analyze activity checks the success ates of the existing epai stategies and the plan activity synthesize new epai stategies. These new stategies eplace the cuent stategies in the eflection model. This eplacement is enacted to the self-epai feedback loop by the execute activity that emoves the untime model defining the cuent Repai stategies and adds the untime model defining the new stategies to the coesponding instance of the FLD shown in Figue 3.8. This adaptation equips the self-epai feedback loop with a new untime model that specifies the newly synthesized epai stategies to be used fom now on.

41 5.1 Declaative Reflection Use-defined Reflection Models 29 Self-epai-stategies <<EvaluationModel>> Repai stategies analysis ules <<Monito>> Obseve Adapt <<Analyze>> Check checked success ate w a <<ReflectionModel>> Self-epai Model <<ChangeModel>> Repai stategies synthesis ules updated model <<Plan>> Synthesize new synthesized epai stategies w <<Execute>> Replace eplaced stategies Adapted Laye-2 Laye-0 Laye-1 MAPE :Self-epai-stategies Afte[Deep check fo failues]; Adapt; M..PE :Self-epai RtException; 10s; Monito; :Adaptable Softwae Analyze A :Self-epai-A Fig. 5.1: FLD fo Self-epai-stategies Fig. 5.2: Layeed feedback loops fo self-epai: the :Self-epai-stategies module at Laye-2 senses and effects the :Self-epai module at Laye-1. As defined by the LD depicted in Figue 5.2, an instance of the Self-epai-stategies feedback loop is located at Laye-2 and it senses and effects the :Self-epai feedback loop at Laye-1. Sensing and effecting the :Self-epai module also includes the sensing and effecting of the :Self-epai-A module because the fome uses the latte. Such a usage elationship is simila to an inclusion, i.e., the :Self-epai module includes the :Self-epai-A module. The tigge fo the :Self-epai-stategies module may efe to the sensed modules :Self-epai and :Self-epai-A. In this example, the tigge efes to the event Afte[Deep check fo failues] (cf. Figue 5.2) that is emitted by the EUREMA intepete. While executing a feedback loop defined by an FLD, the intepete synchonously emits two types of events: Befoe[opName] and Afte[opName] events ae emitted befoe and espectively afte any model opeation is executed, while opname efes to the name of the coesponding opeation. In the example, the :Self-epai-stategies module is synchonously executed by stating in its initial state Adapt when the Deep check fo failues model opeation of the :Self-epai-A module has been executed. This model opeation is only executed if moe than five consecutive uns of the self-epai feedback loop at Laye-1 wee not able to epai the failues. This indicates that the cuent epai stategies ae not able to heal the failue and new stategies ae equied. A paticula aspect of this layeing of feedback loops is that the Self-epai-stategies feedback loop utilizes a use-defined eflection model, called Self-epai Model (cf. Figue 5.1). This eflection model is use-defined because its metamodel can be use-defined and it is maintained by use-defined model opeations fo the monito and execute activities. In the example of the Self-epai-stategies feedback loop, the Obseve and Replace stategies opeations ae concened with the synchonization of the Self-epai Model and the contolled self-epai feedback loop. Thus, the enginee may decide which infomation about the contolled feedback loop is coveed by the eflection model as well as the abstaction level of the model. Howeve, she must ensue the causal connection between the eflection model and the eflected feedback loop by defining and implementing model opeations fo the monito and execute activities. This is simila to managing the causal connection between eflection models and the adaptable softwae as discussed fo the examples in Sections 3 and 4. In this case, the adaptable pat of the self-adaptive softwae ae feedback loops specified by EUREMA models that ae executed by the EUREMA intepete at untime. Thus, sensos and effectos povided by EUREMA can be used to obseve and adjust feedback loops by means of the EUREMA models that ae kept alive at untime. Fo sensing EUREMA models, they can be queied and events emitted by the EUREMA intepete and the MDE infastuctue 1 notifying about the execution and changes of 1 EUREMA and its models ae based on the Eclipse Modeling Famewok (EMF) that povides an event mechanism notifying about changes in EMF models.

42 30 5 Modeling Layeed Achitectues these models can be used. Fo effecting EUREMA models, basic means to change models can be used, like changing attibute values of nodes, o adding and emoving nodes and elationships. Such basic sensos and effectos can be used by the enginee to implement model opeations fo the monito and execute activities that maintain the causal connection between a feedback loop esp. EUREMA models and the use-defined eflection model. The advantage of use-defined eflection models is that the highe-laye feedback loop may un decoupled fom the lowe-laye feedback loop since the eflection model is kept sepaate fom the EUREMA model specifying and executing the lowe-laye loop. Thus, two sepaate epesentations of the lowelaye loop ae used: EUREMA models fo specifying and executing the loop, and use-defined eflection models fo adapting the loop. Howeve, the disadvantage is that both epesentation have to be synchonized to each othe, which ensues the causal connection. Howeve, this synchonization can be simplified since both epesentations ae models confoming to MDE pinciples, i.e., they have potentially diffeent metamodels but the same meta-metamodel. Thus, one-to-one copies of EUREMA models as eflection models can be diectly povided by EUREMA, while MDE techniques can be employed, like model synchonization techniques [Giese and Wagne 2009], to keep both models with individual metamodels consistent to each othe. The geneal applicability of model synchonization techniques fo untime eflection models has been shown in [Vogel et al. 2010; Vogel and Giese 2010]. 5.2 Pocedual Reflection EUREMA-based Reflection Models The othe option fo layeed achitectues applies pocedual eflection between the feedback loops. Thus, the highe-laye feedback loop diectly uses EUREMA models as eflection models of the contolled self-epai feedback loop. Thus, no sepaate epesentation of the self-epai feedback loop is maintained by the highe-laye feedback loop and the EUREMA models used fo specifying and executing the self-epai feedback loop ae also used fo adapting it. The coesponding highe-laye feedback loop is defined by the FLD Self-epai-stategies-2 shown in Figue 5.3. This FLD shows the eflection model feedbackloopmodel, which is labeled with an icon, a small ounded ectangle, to highlight that this model is diectly the EUREMA model used fo specifying and executing the contolled self-epai feedback loop. This eflection model is used by the Self-epai-stategies-2 feedback loop to adapt the self-epai feedback loop. Since the Self-epai-stategies-2 feedback loop does not maintain a sepaate epesentation of the self-epai feedback loop, the causal connection is ensued by constuction. Thus, thee is no need fo explicit monito and execute activities ealizing the causal connection. In contast, the FLD fo the Self-epai-stategies-2 just defines the analyze and plan activities, simila to the Self-epai-stategies feedback loop shown in Figue 5.1. Howeve, in this case the analyze and plan activities ae additionally steeotyped with Monito and Execute, espectively, since the monito and execute activities ae implicitly ealized by them. The LD shown in Figue 5.4 shows the :Self-epai-stategies-2 module at Laye-2 that senses and effects the :Self-epai module at Laye-1. The tigge fo the :Self-epai-stategies-2 module is the same as fo the :Self-epai-stategies module discussed in Section 5.1, and even both LDs depicted in Figues 5.2 and 5.4 ae quite simila except of one aspect. Since the :Self-epai-stategies-2 module as specified by the FLD in Figue 5.3 uses an EUREMA model as the eflection model called feedbackloopmodel, this eflection model must be bound to a concete EUREMA model at untime. This binding is defined in the LD by the usage elationship named feedbackloopmodel that binds eflection model used in the :Self-epai-stategies-2 module to the EUREMA model and in paticula the FLD instance defining the :Self-epai module. Thus, fo adapting the self-epai feedback loop, the :Self-epai-stategies-2 module opeates on the FLD instance of the Self-epai feedback loop, whose initial specification is shown in Figue 3.8. Theeby, it also uses the instance of the FLD Self-epai-A, whose initial

43 5.2 Pocedual Reflection EUREMA-based Reflection Models 31 Self-epai-stategies-2 <<EvaluationModel>> Repai stategies analysis ules Adapt <<Monito>> <<Analyze>> Check success ate checked a <<Plan>> <<Execute>> synthesized Synthesize new epai stategies <<ReflectionModel>> feedbackloopmodel <<ChangeModel>> Repai stategies synthesis ules w Adapted Laye-2 Laye-0 Laye-1 MAPE :Self-epai-stategies-2 Afte[Deep check fo failues]; Adapt; M..PE :Self-epai RtException; 10s; Monito; :Adaptable Softwae Analyze feedbackloopmodel A :Self-epai-A Fig. 5.3: FLD fo Self-epai-stategies-2 Fig. 5.4: Layeed feedback loops fo self-epai: the :Self-epai-stategies-2 module at Laye-2 senses and effects the :Self-epai module at Laye-1. specification is shown in Figue 3.6, because this FLD is used and theefoe included in the Self-epai FLD. In geneal, the FLDs shown in the figues of this aticle ae initial specifications of feedback loops since they ae kept alive at untime and they might be dynamically adapted, which changes the initial specification. In ou example, the highe-laye feedback loop adapts the self-epai feedback loop by eplacing untime models that define epai stategies used by the self-epai feedback loop. The sequence diagam depicted in Figue 5.5 illustates this behavio by descibing the logical inteactions between the layeed feedback loops and thei adaptation activities. The gay-shaded instances eflect modules, like the adaptable softwae o feedback loops, and the hollow instances individual model opeations of feedback loops. To keep the sequence diagam simple, we omitted the execution of the initial and final states of the megamodel modules, which ae technically specific kinds of model opeations. By :RtException events emitted by the :Adaptable Softwae, the tigge of the :Self-epai feedback loop is activated to stat executing the loop (a). The :Self-epai loop executes the :Update opeation, followed by the :Analyze opeation (b). The latte one is a complex model opeation that invokes the :Self-epai-A module (c), that sequentially executes the :Check fo failues and :Deep check fo failues opeations (d). Afte the :Deep check fo failues opeations has been executed, the tigge of the Laye-2 feedback loop is activated and the :Self-epai-stategies-2 feedback loop is synchonously executed (e). This feedback loop instance sequentially executes the :Check success ate and :Synthesize new epai stategies opeations (f). The latte opeation povides new epai stategies to the :Repai opeation of the :Self-epai feedback loop (g). In EUREMA, this povision of new epai stategies is actually done by adapting the FLD instance epesenting the :Self-epai module, in paticula eplacing the untime model defining the cuent stategies with a new untime model defining the new stategies. Then, the :Self-epai-stategies-2 feedback loop, the :Self-epai-A module, and the :Analyze opeation consecutively teminate (h). Afte the analyze activity, the :Self-epai feedback loop sequentially executes the plan and execute activities by means of the :Repai and :Effect opeations (i). The :Repai opeation applies the new epai stategies povided by the :Self-epai-stategies-2 feedback loop and the :Effect opeations enacts the adaptation on the :Adaptable Softwae (j). The advantage of diectly using EUREMA models as eflection models of feedback loops at untime is that the causal connection is ensued by constuction. This avoids the development of monito and execute activities fo highe-laye feedback loops and the need fo specific sensos and effectos to ceate and maintain eflection models of feedback loops. Howeve, by using the same model of a feedback loop fo specifying and executing as well as adapting the feedback loop, the adaptation cannot be decoupled fom the specification and execution. Thus,

44 32 5 Modeling Layeed Achitectues Fig. 5.5: Sequence diagam descibing the logical behavio of layeed feedback loops any adaptation pefomed by the highe-laye feedback loop is immediately enacted to the lowe-laye feedback loop.

45 Chapte 6 Modeling Off-line Adaptation As we have outlined in Section 2.5, we cannot assume that the self-adaptation capabilities of the adaptation engine even with layeed feedback loops ae sufficient to automatically handle all adaptation needs ove time. Theefoe, we need a solution fo the co-existence of self-adaptation and off-line adaptation. In this context, a softwae enginee typically analyzes and plans an adaptation off-line in the development/maintenance envionment followed by executing this adaptation on-line to the self-adaptive softwae. Such an adaptation can be a patch developed by an enginee to evolve the softwae in a way the capabilities of the adaptation engine is not able to accomplish. Fo instance, we discussed the need to evolve change models at untime, like the epai stategies fo ou self-epai example in Section 5. Assuming thee is no highe-laye feedback loop in place that manages the evolution of the epai stategies (cf. Figue 6.1), an enginee may develop new stategies and povide them as a patch to the self-adaptive softwae. In the following, we discuss the elated suppot by EUREMA. A softwae enginee may etieve snapshots of EUREMA models, as visualized by LDs and FLDs, employed in the adaptation engine of the unning self-adaptive softwae to monito and analyze the adaptation pocess. In ou example, based on the LD shown in Figue 6.1, which descibes the cuent achitectue of the self-adaptive softwae, and the elated FLDs instances of the :Self-epai and :Self-epai-A modules eflecting the feedback loop, the enginee identifies the need fo new epai stategies and develops them. EUREMA suppots the subsequent execution of the adaptation, which is simila to a patch enacting the new epai stategies in the adaptation engine. Laye-0 Laye-1 RtException; 10s; Monito; Analyze A :Self-epai-A M..PE :Self-epai :Adaptable Softwae Self-epai-patch Execute <<ExecutionModel>> New epai stategies <<Execute>> Replace eplaced epai stategies w <<ReflectionModel>> feedbackloopmodel Replaced Fig. 6.1: Initial LD Fig. 6.2: FLD fo Self-epai-patch 33

46 34 6 Modeling Off-line Adaptation Theefoe, an FLD specifying the execution of the adaptation o patch has to be modeled off-line and aftewads executed on-line in the adaptation engine. This is exemplified by the FLD shown in Figue 6.2 that specifies the Self-epai-patch. It defines a single model opeation that eplaces the epai stategies in the feedbackloopmodel eflecting and specifying the self-epai feedback loop. Thus, the untime model New epai stategies is linked into the EUREMA model of the self-epai feedback loop visualized in Figue 3.8 and the cuent untime model Repai stategies is emoved. Then, the patch pocess teminates in a destuction state, denoted by a coss, which is a special final state of an FLD. It defines that an instance of the Self-epai-patch module is executed exactly once and when it eaches the final state, it is destoyed and eased. Having defined the Self-epai-patch in the FLD, this module must be integated into the adaptation engine of the unning softwae fo execution. Thus, it must be added to the LD (cf. Figue 6.1) visualizing the EUREMA untime model epesenting the cuent self-adaptive softwae s achitectue. Theefoe, the Self-epai-patch module is uploaded to the adaptation engine though an inteface povided by the EUREMA intepete. Additionally, a ule as depicted in Figue 6.3 has to be specified and uploaded. This ule specifies how the Self-epai-patch module should be integated into the layeed achitectue eflected by the LD in Figue 6.1. The elements of this ule that ae annotated with ++ ae added to the EUREMA model as visualized by this LD if a match fo the ule s elements having no annotation is found in the model. Laye-2 ++ E :Self-epai-patch Afte[Monito]; Execute; feedbackloopmodel Laye-2 E :Self-epai-patch Afte[Monito]; Execute; feedbackloopmodel Laye-0 Laye-1 M..PE :Self-epai Laye-0 Laye-1 RtException; 10s; Monito; M..PE :Self-epai :Adaptable Softwae Analyze A :Self-epai-A Fig. 6.3: The ule to change the initial LD shown in Figue 6.1 Fig. 6.4: The esult of applying the ule depicted in Figue 6.3 on the LD depicted in Figue 6.1 By applying the ule, a match is found fo the :Self-epai module at Laye-1. Thus, the :Self-epai-patch module is added to the model and connected by sensing and effecting elationships to the :Self-epai module. Accoding to the idea of layeed achitectues (cf. Section 2.4), the :Self-epai-patch module is added to Laye-2 because it adapts the self-epai feedback loop by eplacing epai stategies. Moeove, the eflection model feedbackloopmodel used fo adaptation by the :Self-epai-patch module (cf. FLD in Figue 6.2) is bound to the FLD instance used fo executing the self-epai feedback loop (cf. FLD in Figue 3.8). This esults into the layeed achitectue depicted in Figue 6.4. While the :Self-epai-patch module is integated into the layeed achitectue, the :Self-epai module may continuously un to pefom self-adaptation. The :Self-epai-patch module will be executed afte the integation has been done and its tigge is activated. The tigge Afte[Monito]; Execute; intecepts the execution of the :Self-epai module afte this module has executed its initial state in ode to execute the :Self-epai-patch module fo injecting the new epai stategies into the :Self-epai module. As discussed above fo the FLD of the patch module, the :Self-epai-patch module will be executed exactly once and it will be destoyed and emoved fom the layeed achitectue aftewads. The esulting achitectue is the same as the one befoe applying the patch (cf. Figue 6.1) except that new epai stategies that have been developed off-line ae now used by the self-epai feedback loop.

47 35 This example shows how EUREMA suppots the integation and execution of adaptation that have been planned and developed off-line by enginees. Theeby, the same modeling concepts of FLDs as fo specifying feedback loops ae used fo specifying the execution of an off-line adaptation. Likewise to the example of applying a patch to the adaptation engine, an enginee may specify a complete feedback loop off-line by FLDs, which ae then uploaded and integated to the adaptation engine. In contast to the patch module that is added to the layeed achitectue, executed once, and then emoved fom the achitectue, the feedback loop modules emain in the achitectue until it is eventually emoved by futue (off-line) adaptations. Assuming the enginee has developed mechanisms to automatically synthesize new epai stategies in ou self-epai example, she may delegate the maintenance of the epai stategies to the adaptation engine. Thus, she specifies a coesponding feedback loop fo Laye-2 using FLDs and integates this feedback loop module to the adaptation engine simila to the way it was done fo the patch module. This esults in a layeed achitectue with a hieachy of feedback loops, which we discussed in Section 5. Thus, the achitectue of the self-adaptive softwae evolves fom a two-laye achitectue (cf. Figue 6.1) to a thee-laye achitectue (cf. Figues 5.2 o 5.4). Thus, EUREMA addesses the need to evolve self-adaptive softwae by adding o emoving feedback loops at diffeent layes of the adaptation engine. This is ealized by means of adaptation analyzed and planned off-line, but enacted on-line to the unning softwae. This suppots adaptation of self-adaptive softwae, which has not been anticipated when initially developing and deploying the softwae. In ou example, the need to maintain epai stategies was not anticipated, but it can be coveed by continuously patching the adaptation engine o by integating a highe-laye feedback loop. Futhemoe, EUREMA povides basic suppot to integate legacy softwae modules in adaptation engines. Such modules ae teated as black boxes by EUREMA in contast to megamodel modules that ae specified by FLDs. Thus, EUREMA just addesses the activation of legacy modules by modeling sensing and effecting elationships in LDs. Fo example, Figue 6.5 defines the native tiggeing of the :legacy.self-optimization module, which is contolled by glue code that had-wies the legacy module to the adaptable softwae. Thus, the EUREMA intepete cannot intefee o suppot off-line adaptation. Laye-0 Laye-1 MAPE :legacy. Self-optimization native :Adaptable Softwae Laye-0 Laye-1 MAPE :legacy. Self-optimization LoadIncease; 60s; legacy.selfoptimization.main() :Adaptable Softwae Fig. 6.5: Had-wied legacy module Fig. 6.6: EUREMA tigge fo a legacy module Howeve, if it is possible to tigge the legacy module based on events simila to tiggeing feedback loops in EUREMA (cf. Section 3.3), a tigge fo the legacy module can be specified and the EUREMA intepete contols the tiggeing of the legacy module. This is exemplified in Figue 6.6 that defines the tigge LoadIncease; 60s; legacy.self-optimization.main() fo the :legacy.self-optimization module. Thus, the EUREMA intepete tigges the legacy module with a peiod of 60s when an event of type LoadIncease occus by invoking the method legacy.self-optimization.main(). In this case, the intepete contols the activation of the legacy module, which enables decommissioning the legacy module fo migating the adaptation engine to employ megamodel modules defined by the EUREMA language. This migation can be ealized by the capabilities fo off-line adaptation povided by EUREMA.

48

49 Chapte 7 Execution In this section, we discuss the execution of feedback loops specified by EUREMA. Theefoe, we pesent the metamodel because it pecisely defines the EUREMA modeling language and it is the basis fo opeationalizing EUREMA models by defining the execution semantics. Finally, we povide basic infomation about the metamodel and intepete implementations. 7.1 Metamodel and Execution Semantics In geneal, a metamodel defines a modeling language by means of its abstact syntax while fo visual modeling a concete syntax based on the abstact syntax is employed. In this aticle so fa, we used EUREMA s concete syntax as shown in Figue 3.5 to visually model feedback loops and adaptation engines in FLDs and LDs. In the following, we discuss the undelying metamodel that defines the EUREMA language and that is the basis fo executing coesponding models by the EUREMA intepete. Conceptually, the EUREMA language coves (1) the specification of adaptation activities, untime models, and feedback loops (the enginee ceates FLDs), (2) the specification of layeed achitectues of self-adaptive softwae (the enginee ceates LDs), and (3) the execution of EUREMA models (the EUREMA intepete executes these models). These thee aspects can be identified in the metamodel of the EUREMA language depicted in Figue 7.1: the elements shaded light-gay ae concened with (1), the hollow elements with (2), while all of these elements and additionally the elements shaded dak-gay ae elevant fo (3) (1) Adaptation Activities, Runtime Models, and Feedback Loops Fo this aspect, the coe concept is the megamodel as visualized by an FLD, which specifies a complete o patial feedback loop including its untime models and adaptation activities/opeations. Thus, a Megamodel contains Models and diffeent kinds of Opeations. Opeations ae linked with each othe by Tansitions defining the contol flow between opeations. Each Tansition connects exactly one souce to one taget opeation. Opeations and tansitions ae the Executable elements of all MegamodelElements. The diffeent opeation types used in a megamodel ae the following: at least one InitialOpeation and one FinalOpeation ae equied, which ae the megamodel s initial and final states, espectively. A 37

50 38 7 Execution Fig. 7.1: Metamodel of the EUREMA language

51 7.1 Metamodel and Execution Semantics 39 FinalOpeation can be destuctive defining that the instance of the megamodel is executed exactly once and aftewads immediately destoyed. DecisionOpeations enable the banching of the contol flow based on Conditions that ae annotated to a DecisionOpeation s outgoing OpeationTansitions (see the FLD in Figue 3.6 fo an example). The megamodel s actual behavio is defined by OpeationBehavio s, eithe ModelOpeations o MegamodelCalls, that use Models as Input o Output. ModelOpeations ae atomic computation units, fo which implementations have to be povided (cf. Softwae element). MegamodelCalls ae the complex model opeations to invoke a Megamodel that specifies eithe pats of the same feedback loop o a complete and diffeent feedback loop. This enables modula megamodels fo descibing a feedback loop (cf. Section 3.4) and the coodination of multiple loops (cf. Sections 4.2). A model used by opeations is eithe a RuntimeModel o a MegamodelPoxy. A RuntimeModel can be an abitay model as an instance of an abitay metamodel, while a MegamodelPoxy efes to a megamodel as an instance of the EUREMA metamodel. While all examples of megamodels shown as FLDs in this aticle employ untime models, an EUREMA megamodel is used as a (eflection) model by anothe megamodel in layeed achitectues (cf. feedbackloopmodel in the FLD shown in Figue 5.3) (2) Layeed Achitectues The second aspect is concened with the achitectue of a specific instance of a self-adaptive softwae by means of the employed feedback loops, thei elationships to each othe and to the adaptable softwae. This is specified in LDs and addessed by the hollow elements of the EUREMA metamodel (cf. Figue 7.1). A layeed Achitectue is modeled by multiple Laye s each of them containing Modules. Modules ae concete instances of feedback loops o softwae components that ae employed within the self-adaptive softwae. Modules may monito and adapt each othe, which is epesented by Sensing and Effecting elationships between modules. SoftwaeModules instantiating Softwae epesent the adaptable softwae, legacy adaptation components, o implementations of a megamodel s ModelOpeations, which ae all consideed as black boxes in EUREMA (see LDs in Figues 6.5, 6.6, and 3.11 fo examples). The implementation attibute efes to infomation on how to initiate an execution of a legacy component o an opeation implementation. A MegamodelModule is an instance of a complete o patial feedback loop that is specified by a Megamodel in an FLD. Theeby, the specification of a feedback loop by means of the FLD is diectly used as the instance model of the feedback loop to be executed. In EUREMA, the specification of a feedback loop and the instance model of the feedback loop collapse because feedback loop instances can be individually adapted in layeed achitectues (cf. Section 5) o by off-line adaptation (cf. Section 6) by changing thei individual specifications. Technically, if a feedback loop should be instantiated multiple times, copies of the oiginal specification ae ceated fo each instance and wapped in Megamodel- Modules to povide an identifiable context fo the instance. When instantiating a feedback loop esp. its megamodel in a module, the dependencies to othe modules have to be esolved. Thus, ModelOpeations must be bound to SoftwaeModules implementing the opeations, MegamodelCalls, i.e., the complex model opeations, must be bound to Megamodel- Modules as tagets of the invocations, and MegamodelPoxies epesenting megamodels used within the instantiated feedback loop must be bound to MegamodelModules as concete megamodels. These bindings ae defined in LDs by use elationships labeled with the name of the element to be bound (see LDs in Figues 3.10, 3.11, and 5.4 fo examples). Finally, tigges fo activating modules ae specified in LDs (cf. Section 3.3). A tigge may specify a peiod of activation and Events of use-defined types, whose occuences cause the activation. Theeby, a tigge of a module efes to a Sensing elationship though which the events can be obseved. Thus,

52 40 7 Execution the module, fo which the tigge is specified, senses anothe module that emits the coesponding events. Tigges ae eithe SoftwaeModuleTigge s fo legacy adaptation components as discussed in Section 6, o MegamodelModuleTigge s fo feedback loop instances, which point to the initial opeation fo stating execution (cf. Section 3.3) (3) Execution Fo the last aspect, the execution of EUREMA models by the intepete, additionally the metamodel elements shaded dak-gay ae elevant (cf. Figue 7.1). The RuntimeEnvionment fo a layeed Achitectue manages the execution of MegamodelModules by maintaining an ExecutionContext fo each MegamodelModule. This context points to the cuently executed Opeation o Tansition and it maintains ExecutionInfomation, especially count and time, fo these Executables. The time attibute epesents the timestamp when the opeation o tansition has been executed the last time. Fo a tansition, the count attibute eflects the numbe how often the souce opeation of the tansition has been executed without taking the coesponding tansition but anothe outgoing tansition. If the coesponding tansition is taken, count is eset to 0. This infomation is maintained by the intepete and used in expessing Conditions fo exclusively banching the contol flow, which ae evaluated by the intepete. Fo example, a counte can be compaed with a constant to banch the contol flow in a megamodel as it is shown in the FLD in Figue 3.3. Fo conditions, basic aithmetic and boolean opeations on time and count ae cuently suppoted. The language fo expessing conditions is defined by a gamma and it is kept geneic to clealy sepaate the abstaction levels between a megamodel and its contained models and opeations. The intepete woks at the level of megamodels and it consides the individual models and opeations as black boxes. Since conditions ae evaluated by the intepete, they must not utilize intenal concepts of the models o opeations. Othewise, it would equie that the intepete must access such concepts, which would couple the intepete implementation to the specific implementations of the models o opeations. In the end, this would pevent euse of the intepete fo diffeent self-adaptive systems. Howeve, if moe advanced o application-specific conditions ae needed, they can be modeled by appopiate outgoing OpeationTansitions that can be seen as etun states of opeations and fo which time and count ae maintained. In this case, the opeation s implementation decide on the state the opeation teminates in, while the intepete may futhe banch the contol flow based on the time and count attibutes of the etun state. Finally, the ModelResouces epesent the mateialized models and megamodels used in the untime envionment fom a technical point of view. The URI of a esouce is the unifom esouce identifie pointing to a location, fom which the model o megamodel can be loaded. Concening the execution semantics of EUREMA models, we distinguish between the behavioal FLDs and stuctual LDs. An FLD specifies the behavio of a feedback loop as a megamodel that contains a flow of opeations woking on untime models. Fo a specific feedback loop instance, the megamodel is instantiated once and this instance is eused if the feedback loop instance is executed multiple times. A megamodel instance encapsulated in a MegamodelModule is not eentant and theefoe, at most a single thead of contol is active within the module. Moeove, all opeations of a megamodel instance ae executed synchonously and thus, also the invocations of othe megamodel instances by complex model opeations ae synchonous. A tigge of a MegamodelModule that efes to events emitted fom the adaptable softwae activates the megamodel instance asynchonously. A synchonous activation equies specific sensos of the adaptable softwae, which need not to be povided by the adaptable softwae, and it would block the execution of the unning adaptable softwae, which is usually not desiable. Howeve, a tigge of a megamodel module does not activate the megamodel instance while the instance is cuently unning. Any events that potentially effect the tigge ae queued and pocessed when the instance has teminated execution. An example fo such a tigge is discussed in Section 3.3.

53 7.2 Metamodel and Intepete Implementation 41 In contast, a tigge of a megamodel module that efes to events emitted fom anothe megamodel module activates the module synchonously. Thus, the execution of the module that emitted the event is blocked until the module activated by the coesponding event has teminated. This scenaio has been discussed fo layeed feedback loops in Section 5. Thus, concuent executions of inteelated megamodel modules o individual opeations ae not suppoted. This avoids the need of synchonization mechanisms to ensue consistency by esticting concuency. Theefoe, the EUREMA intepete executes an FLD instance by stepwise executing its opeations and following tansitions between opeations. The contol flow is exactly defined as a sequence of opeation and it may only be exclusively banched by decision nodes and conditions. When executing an opeation, the intepete povides the models that ae used as input and it maintains the models used as output by the opeation. Thus, any model being the output of one opeation can be the input of anothe opeation. Oveall, this esults in simple execution semantics of EUREMA models and in a lightweight intepete that just has to cope with the geneal concepts of a megamodel, namely opeations and models. The LDs povided by the EUREMA language ae not executable like FLDs since they ae stuctual diagams and specify the achitectue instance of the self-adaptive softwae. Thus, an LD can be consideed as a eflection model of the oveall self-adaptive softwae that focuses on the employed modules and the elationships between modules. The EUREMA intepete maintains the LD of the coesponding self-adaptive softwae at untime to obseve and adapt the adaptation engine by means of off-line adaptation (cf. Section 6). Thus, the EUREMA intepete ealizes a causal connection between the LD and the adaptation engine. This is simila to model-based adaptation of the adaptable softwae whee an achitectual untime model of the softwae is used as the basis fo econfiguation. 7.2 Metamodel and Intepete Implementation The EUREMA metamodel and its intepete have been developed with the Eclipse Modeling Famewok (EMF). Figue 7.1 shows the complete metamodel we use in the implementation. The steeotypes of opeation and model elements in FLDs, the labels of model usage elements in FLDs, and the labels of module elements in LDs ae not diectly suppoted by the metamodel because they do not influence the execution semantics. Thus, they ae not elevant fo the EUREMA intepete. Howeve, they ae intoduced in the EUREMA language by using a pofile mechanism. The language fo expession conditions to exclusively banch the contol flow in FLDs is defined by a gamma and implemented with the Java Compile Compile (JavaCC). Ou intepete implementation only elies on EMF and it may un standalone and decoupled fom the Eclipse wokbench. Nevetheless, the intepete povides full suppot fo use-defined, EMF-based untime models used within feedback loops. Fo example, the intepete manages the handling of untime models as input o output of model opeation executions. Concening EUREMA models, the intepete cuently povides full suppot fo executing FLDs and patial suppot fo maintaining an LD. The patial suppot enables the execution of multiple and layeed feedback loops as defined in an LD, but so fa, it does not suppot the dynamic adaptation of the layeed achitectue by means of changing the LD at untime. Cuently, we ae addessing this aspect by integating the LD as an explicit untime model into the intepete in ode to completely suppot off-line adaptation.

54

55 Chapte 8 Discussion and Evaluation To evaluate the EUREMA appoach fo executable untime megamodels specifying and executing adaptation engines fo self-adaptive softwae, we fist discuss EUREMA s coveage of the equiements we identified in Section 2. Then, we outline the benefits of EUREMA that ae leveaged by the application of MDE techniques and we apply the EUREMA language to model example appoaches fom the liteatue. The latte demonstates that the language is expessive enough to captue state-of-the-at appoaches to self-adaptive softwae and thei specific vaiants of feedback loops and untime models. Finally, we epot about expeiences concening the untime chaacteistics of the EUREMA intepete. 8.1 Requiements Coveage In this section, we discuss the extent EUREMA fulfills the equiements fo self-adaptive softwae that we pesented in Section 2. Theeby, we also discuss details concening elated wok fo modeling languages that could not have been addessed in Section 1.1 due to the missing intoduction of the EUREMA concepts. By the FLDs, EUREMA suppots almost all of the equiements fo feedback loops that we identified in Section 2.1. The feedback loops ae explicitly modeled accoding to the abstact scheme established by the MAPE-K bluepint that has been efined to model individual adaptation activities and untime models. This makes the feedback loops visible in the design and analysis of self-adaptive softwae, which enables the modeling and evaluation of altenative designs as, e.g., discussed fo vaiability of feedback loops in Section 3.4. FLDs futhe suppot the modeling of inta-loop coodination by defining the contol flow between adaptation activities and the usage of shaed untime models by the activities. To execute feedback loops as specified by FLDs, tigges ae specified and assigned to concete feedback loops in LDs. Thus, when modeling the achitectue of a concete self-adaptive softwae in an LD, EUREMA addesses tiggeing conditions as these condition might be specific to the concete adaptable softwae and employed feedback loops. Moeove, multiple feedback loops and the inte-loop coodination of these loops ae suppoted by EUREMA. Individual feedback loops and thei coodination ae modeled by FLDs, while the LDs eflect the abstact sense, effect, and use elationships between these loops. EUREMA addesses the execution of feedback loops by poviding an executable modeling language and an intepete fo this language (cf. Section 7), while suppoting eflective feedback loops (cf. Section 5). Howeve, we ae cuently not addessing concuency of feedback loops and thei adaptation activities, and the incemental execution of adaptation activities in the sense that all activities of a loop 43

56 44 8 Discussion and Evaluation continuously pocess a steam of events unning though the loop. Thus, loops and activities ae executed sequentially and stepwise, i.e., one afte the othe. Moeove, EUREMA is cuently esticted to non-distibuted adaptation engines while the engine may un on a diffeent node than the adaptable softwae. Thus, the equiement of distibuting feedback loops is not fulfilled by EUREMA. EUREMA models as visualized by FLDs and LDs do not ealize themselves the untime models used as knowledge within feedback loops, but they suppot the elated equiements identified in Section 2.2. The FLDs captue the diffeent untime models employed in a feedback loop and how they ae used by adaptation activities. Theeby, the EUREMA language does not estict the kinds of untime models by means of thei metamodels as well as pupose. Fo example, the pupose of untime models is epesented by steeotypes that ae not pat of the coe EUREMA language as defined by the metamodel in Section 7 but they ae pat of an additional, customizable pofile. Moeove, EUREMA models ae kept alive at untime. Thus, they become untime models that can be used as eflection models in FLDs. Moeove, EUREMA untime models encapsulated in megamodel modules and the elationships between these modules ae captued in LDs. In paticula, the use of an EUREMA model as a eflection model is captued when layeing feedback loops (cf. Section 5). Concening the equiements fo sensos and effectos as well as the monito and execute activities discussed in Section 2.3, which ae elevant fo connecting a feedback loop to an adaptable subsystem, EUREMA abstacts fom senso and effecto details to avoid its coupling to a specific technology, platfom, o type of the adaptable softwae. Theefoe, EUREMA poposes the explicit modeling of monito and execute activities, whose implementations have to cope with the senso and effecto details. Sensos details ae only evealed by senso events used fo specifying tiggeing conditions of feedback loops. Thus, EUREMA models and thei adaptability suppot static as well as dynamic instumentation if this is popely eflected by the monito and execute activities, thei untime models, and implementations. The EUREMA appoach suppots both, paamete and stuctual adaptation of the adaptable softwae and feedback loops. Fo the adaptable softwae, adaptation is implemented by appopiate adaptation activities and thei untime models, while EUREMA manages the coodination of activities and models to fom feedback loops. Fo adaptable feedback loops, adaptation efes to the concepts of the EUREMA language when using EUREMA models as eflection models. Thus, by changing the stuctue o paametes of EUREMA models, adaptation of feedback loops is ealized (cf. Section 5). Adaptable feedback loops ae cucial fo layeed achitectues (cf. Section 2.4), whee feedback loops opeate at diffeent layes. EUREMA suppots the individual specification of feedback loops at diffeent layes by FLDs, while an LD defines the oveall achitectue by stuctuing the feedback loops in diffeent layes. Moeove, EUREMA suppots declaative and pocedual eflection of feedback loops, eithe by employing use-defined eflection models (cf. Section 5.1) o EUREMA models as visualized by FLDs (cf. Section 5.2) as eflection models. Oveall, this enables adaptive contol schemes and hieachical contol achitectues without esticting the numbe of layes o feedback loops. Finally, based on a layeed achitectue, EUREMA suppots off-line adaptation in co-existence to selfadaptation as equied in Section 2.5. EUREMA models ae used to specify the enactment of adaptation that has been analyzed and planned off-line. Then, the concepts of the layeed achitectue enables the integation of these models to the untime envionment, whee these models ae executed by the intepete to enact the adaptation (cf. Section 6). To summaize, EUREMA coves almost all of the equiements identified in Section 2 by poviding an MDE solution that employs executable untime megamodels fo specifying and executing feedback loops and fo eflecting and adapting feedback loops in layeed achitectues o by off-line adaptation. Theeby, the megamodels explicitly captue the untime models used in the adaptation engine. In paticula, the language design of EUREMA leveages suppot fo the equiements. We biefly discuss majo language design decisions in EUREMA with espect to standad modeling languages. The

57 8.2 Application of MDE Techniques in EUREMA 45 EUREMA language is specific fo the development of adaptation engines fo self-adaptive softwae, but it is based on geneal modeling concepts fo stuctual and behavioal diagams. The EUREMA language fo FLDs shaes chaacteistics with Activities of the UML [Object Management Goup 2011]. Both languages povide behavioal diagams with espect to modeling flows of actions (in UML) o opeations (in EUREMA). Howeve, in contast to EUREMA, UML does not povide megamodel concepts as fist class entities, like a model being itself an element in anothe model. This is equied to explicitly captue the untime models used within a feedback loop and in paticula to captue the nesting of EUREMA models, i.e., the use of EUREMA models as eflection models within anothe EUREMA model. Moeove, the EUREMA language fo LDs boows concepts fom UML concening stuctual diagams, in paticula UML Packages and UML Objects [Object Management Goup 2011]. Howeve, EUREMA employs concepts specific fo self-adaptive softwae simila to domain-specific languages in geneal. Thus, an LD in EUREMA descibes all modules within an adaptation engine and how they ae elated to each othe and to the adaptable softwae by means of use, sense, and effect elationships. Finally, the language fo LDs has similaities with the UML pofile we poposed in [Hebig et al. 2010]. This UML pofile focuses on captuing intefeences between feedback loops. In contast, LDs specify the opeational use, sense, and effect elationships between modules, while intefeences between modules ae addessed by explicitly modeling inte-loop coodination. 8.2 Application of MDE Techniques in EUREMA By adopting an MDE appoach, EUREMA aims at leveaging benefits of MDE to the untime envionment fo self-adaptation. On the one hand, as discussed in the pevious section, EUREMA exploits MDE pinciples by means of its modeling language, untime megamodels, and intepete to addess the equiements fo self-adaptive softwae. On the othe hand, EUREMA makes the untime models used as knowledge within feedback loops explicit. This additionally leveages MDE techniques at untime to pefom individual adaptation activities within a feedback loop. Moeove, the EUREMA modeling language tagets a easonable abstaction level simila to the level of softwae achitectues. Thus, adaptation activities ae consideed as abstact model opeations, which enables the integation and euse of existing MDE techniques and implementations fo ealizing and pefoming these opeations esp. adaptation activities. Fo example, in ou pevious wok [Vogel et al. 2009, 2010; Vogel and Giese 2010], we employed an existing model synchonization engine to maintain an achitectual untime model eflecting the adaptable softwae, and an Object Constaint Language (OCL) engine to check achitectual constaints on this model. Such engines can be consideed as eusable implementations fo adaptation activities. Thus, the monito and execute activities may utilize a model synchonization engine at untime, and the analyze activity an OCL engine. This exemplifies that the development effots fo implementing adaptation activities can be educed by integating and eusing existing engines fom MDE. Moeove, since such engines ae geneic and they completely extenalize the use-defined inputs in models, like OCL expessions, these models become untime models, which ae then made explicit in FLDs and amenable fo adaptation by EUREMA. Fo example, the OCL expessions can be dynamically adapted without having to change the OCL engine. This potentially simplifies the development of adaptable feedback loops. Summing up, EUREMA diectly exploits MDE pinciples fo specifying, executing, and adapting feedback loops, while it enables enginees to exploit MDE pinciples fo implementing individual adaptation activities that ae modeled as model opeations in FLDs.

58 46 8 Discussion and Evaluation 8.3 Application of the EUREMA Language In the following, we descibe thee appoaches fom liteatue using the EUREMA language. The fist appoach, Rainbow [Galan et al. 2004], is based on achitectue desciption language (ADL) techniques, and the second one, DiVA [Moin et al. 2009a] on MDE techniques. Nevetheless, ou language can captue both appoaches and the techniques they apply. Both appoaches employ exactly one feedback loop, while the thid appoach, PLASMA [Tajalli et al. 2010], suppots layeed feedback loops Rainbow The Rainbow famewok [Galan et al. 2004; Cheng 2008] is an achitectue-based appoach to selfadaptation. Its majo goal is the cost-effective development of self-adaptive softwae by poviding a eusable infastuctue fo adaptation engines. The infastuctue povides seveal customization options to addess specifics of the adaptable softwae when developing the engine. Howeve, it pescibes the achitectue of an adaptation engine by suppoting exactly one feedback loop as shown in the LD in Figue 8.2 and whose adaptation activities ae stuctued in a pedefined way. We modeled this pedefined feedback loop in the FLD depicted in Figue 8.1. In contast to this diagam, the models descibing Rainbow in [Galan et al. 2004; Cheng 2008] povide achitectual views that do not make the untime models used within the famewok explicit. Rainbow Stat <<Monito>> system Gauges changed <<Analyze>> Achitectue Evaluato <<Monito>> model Model updated Manage w w violations no violations <<ChangeModel>> Adaptation Stategies Analyzed <<ReflectionModel>> Achitectue Model <<Plan>> Adaptation stategy selected Manage <<ChangeModel>> Utility Pefeences <<ReflectionModel>> Envionment Model c <<ExecutionModel>> Selected Stategy d <<Execute>> Stategy done Executo Effected Laye-0 Laye-1 MAPE :Rainbow :Adaptable Softwae Fig. 8.1: FLD fo Rainbow Fig. 8.2: LD fo Rainbow Fo monitoing, Gauges abstact fom the sensos of the adaptable softwae to collect data, like aveage esponse times, elevant fo concens that should be handled by the self-adaptation mechanism. Gauges notify the Model Manage about changes in the adaptable softwae by poviding Gauge Events that eflect those changes at the abstaction level of the Achitectue Model and Envionment Model. Thus, the model manage diectly uses these events to update the achitectue model if the unning system o the esouce utilization have changed, o the envionment model if esouces ae added o emoved fom the system. In Figue 8.1, the gauge events ae eflected by a gay-shaded element since Rainbow does not explicitly eflect them in a model. Wheneve, the model manage updates the achitectue model, it tigges the Achitectue Evaluato that analyzes this model by applying Rules/Constaints. Rules and constaints ae specified as pat of the achitectue model and not by a distinct evaluation model. Howeve, to make these ules and constaints visible in the feedback loop s stuctue, we depict them by a gay-shaded element. Rules o constaints check, e.g., whethe monitoed esponse times exceeds a given theshold. The feedback loop teminates if no ule o constaint is violated. Othewise, the Adaptation Manage is executed to plan adaptation. Theefoe, based on given Utility Pefeences among multiple concens and the cuent eflection models, a Selected Stategy fom the epetoie Adaptation Stategies is chosen. Stategies ae simila to event-condition-action ules specifying a econfiguation. The selected stategy is the

59 8.3 Application of the EUREMA Language 47 most pomising one to addess the adaptation needs constained by the utility pefeences. Finally, the Stategy Executo enacts the selected stategy by mapping and executing it on the effectos of the adaptable softwae. To popely execute a stategy, the executo uses the achitectue model and the envionment model to identify softwae elements o esouces, espectively, which ae efeenced by the stategy to be executed. Changes of the adaptable softwae caused by executing the stategy ae eflected in the achitectue model by the next un of the monitoing activity when the feedback loop is executed again. The Rainbow famewok is based on the ADL Acme to descibe the achitectue and envionment models. Rules and constaints as pat of the achitectue model ae specified by Acme pedicates in a fist-ode pedicate logic. Adaptation stategies and utility pefeences ae defined in Stitch [Cheng and Galan 2012]. Though Rainbow does not employ untime models that follow MDE pinciples, the EUREMA language is able to captue Rainbow s feedback loop, while making the ADL and Stitch models explicit in the achitectual design DiVA The goal of the DiVA (Dynamic Vaiability in complex, Adaptive systems) poject is to manage dynamic vaiability in adaptive systems. Theefoe, a model-diven appoach to specify and execute self-adaptive softwae has been poposed [Moin et al. 2008, 2009a,b]. MDE techniques and untime models dive DiVA s feedback loop, which makes this appoach an inteesting candidate fo ou modeling appoach. Likewise to Rainbow, DiVA employs a single feedback loop as modeled in the LD shown in Figue 8.4. We modeled this feedback loop by the FLD as depicted in Figue 8.3. DiVA Stat <<EvaluationModel>> Reasoning Model <<Monito>> ctx change CEP <<ChangeModel>> Aspect Models <<Analzye>> <<Plan>> aspects selected Reasoning Engine no change Monitoed w <<ReflectionModel>> Context Model w c <<ChangeModel>> Selected Aspects <<Plan>> Model Weave woven <<ReflectionModel>> Achitectue Model d c <<ReflectionModel>> Taget Configuation <<EvaluationModel>> Invaiants <<Analyze>> Configuation Checke d violations no violations <<Execute>> Effect Canceled Done Effected Laye-0 Laye-1 :Configuation Manage Effect :DiVA MAP.. :Adaptable Softwae E Fig. 8.3: FLD fo DiVA Fig. 8.4: LD fo DiVA In DiVA, event-diven sensos ae used to monito the adaptable softwae and its opeational context. A complex event pocesso (CEP) analyzes and filtes senso events to update the Achitectue Model and the Context Model that eflect the adaptable softwae and the context, espectively. Since the context dives the adaptation in DiVA, the monitoing activity teminates the feedback loop if thee is no elevant context change. Othewise, the Reasoning Engine is tiggeed to find a new taget configuation suitable fo the cuent context. Theefoe, easoning is pefomed on the achitectue and context models, which is guided by a Reasoning Model and Aspect Models. Aspect models define the vaiability of the system by means of featues. The easoning model specifies the ule- o goalbased analysis mechanism to detemine which aspects should be activated o de-activated on the cuent configuation. These Selected Aspects ae woven o emoved by the Model Weave fom the achitectue model to actually obtain the Taget Configuation descibed in a newly ceated model. Befoe enacting this taget configuation, the Configuation Checke validates it by evaluating Invaiants. If any invaiant is violated, the configuation checke discads the taget configuation and teminates the feedback loop. Othewise, the complex model opeation Effect invokes the Configuation Manage as defined in the

60 48 8 Discussion and Evaluation FLD shown in Figue 8.5. This invocation executes the adaptation by moving the adaptable softwae fom the cuent configuation eflected by the achitectue model to the taget configuation. Configuation Manage <<ReflectionModel>> Achitectue Model Stat <<Execute>> Compae <<ReflectionModel>> Taget Configuation c <<ExecutionModel>> Match Model c <<ExecutionModel>> Diff Model d <<Execute>> Scipt Geneato d <<ExecutionModel>> Reconfiguation Scipt c compaed geneated d <<Execute>> Enact enacted Done Fig. 8.5: FLD fo the Configuation Manage of DiVA To enact the taget configuation on the adaptable softwae, the Compae activity compaes the achitectue model with the taget configuation to obtain a Match Model and a Diff Model (cf. Figue 8.5). These model descibe the common espectively the diffeent model elements of the achitectue model and the taget configuation. Thus, they epesent which achitectual elements should emain unchanged and which elements should change when moving fom the cuent to the taget configuation. This infomation is used by the Scipt Geneato to ceate a Reconfiguation Scipt that is finally executed by the Enact opeation using the effectos of the adaptable softwae. Modeling DiVA with the EUREMA language shows that the language is able to captue feedback loops that ae diven by MDE pinciples and techniques in contast to feedback loops based on ADL techniques, like in Rainbow. Since both appoaches just employ a single feedback loop, we model in the following an appoach fo layeed feedback loops PLASMA The PLASMA appoach [Tajalli et al. 2010] poposes a thee-laye achitectue fo plan-based adaptation. The coesponding pape focuses on the geneation of plans fo adapting softwae applications, while the behavio of the employed feedback loops and untime models ae often not clealy discussed. This complicated the modeling of PLASMA s feedback loops with the EUREMA language and esulted in the following diagams. The LD shown in Figue 8.7 defines the layeed achitectue with the adaptable application at the lowest laye. The feedback loop in the middle laye adapts the application and the highest-laye feedback loop (e)geneates plans to be executed by the two lowe layes. Monito Adaptation <<Monito>> collected Collecto-1 <<ReflectionModel>> Taget Application Achitectue Model w <<ChangeModel>> Adaptation Plan <<Analzye>> <<Plan>> Adaptation Analyze actions deived <<ReflectionModel>> Application Achitectue Model c <<ExecutionModel>> Actions-1 d <<Execute>> Admin-1 actions executed Executed Laye-2 Laye-0 Laye-1 MAPE :Planning MAPE :Adaptation :Application Fig. 8.6: FLD fo the Adaptation laye in PLASMA Fig. 8.7: LD fo PLASMA The middle-laye feedback loop, called Adaptation, is defined by the FLD in Figue 8.6. The Collecto-1 opeation monitos the adaptable application and maintains the Application Achitectue Model eflecting the application. This eflection model is used by the Adaptation Analyze that executes the

61 8.3 Application of the EUREMA Language 49 Adaptation Plan povided by the highe-laye feedback loop. This plan defines the adaptation to move the cuent application achitectue to the taget achitectue as defined in the Taget Application Achitectue Model by the highe-laye feedback loop. Additionally, the Adaptation Analyze analyzes any deviations in the cuent application achitectue and esolves them to align it with the taget achitectue. Theefoe, econfiguation commands (Actions-1) ae ceated and executed by the Admin-1 opeation on the adaptable application. Planning <<ChangeModel>> Application Poblem Desciption Plan <<Plan>> Application Planne <<ExecutionModel>> Application Plan <<ReflectionModel>> Application Domain Desciption planned c c <<ReflectionModel>> Taget Application Achitectue Model <<ReflectionModel>> Application Achitectue Model <<ReflectionModel>> Adaptation Domain Desciption <<Plan>> Adaptation Planne c planned <<ExecutionModel>> Adaptation Plan <<ReflectionModel>> Taget Adaptation Achitectue Model <<Monito>> collected Collecto-2 w <<Analzye>> <<Plan>> Analyze <<ReflectionModel>> Adaptation Achitectue Model w <<ExecutionModel>> Actions-2 c actions deived <<Execute>> Admin-2 actions executed Planned Fig. 8.8: FLD fo the Planning laye of PLASMA The highe-laye Planning feedback loop defined by the FLD depicted in Figue 8.8 is executed when plans ae geneated initially o when eplanning is equied due to changing goals. The Application Planne uses a domain model of the application (Application Domain Desciption) and the initial and goal states of the application (Application Poblem Desciption), which ae both povided by the achitect and which ae manually changed if system goals change. The planne ceates an Application Plan to be executed by the application located at the lowest laye and the Taget Application Achitectue Model pescibing the application achitectue that is able to execute the application plan. Moeove, the achitect povides the Taget Adaptation Achitectue Model defining the taget achitectue of the middle-laye feedback loop, which is also eflected in the Adaptation Domain Desciption used by the Adaptation Planne. This planne additionally uses the Application Achitectue Model maintained by the middle-laye feedback loop and the newly ceated Taget Adaptation Achitectue Model to deive an Adaptation Plan fo moving the cuent achitectue of the adaptable application to the taget achitectue. Then, the following opeations adapt the middle-laye feedback loop to enable the execution of the geneated adaptation plan. The Collecto-2 opeation updates the Adaptation Achitectue Model eflecting the middle-laye feedback loop by monitoing. The Analyze adds the Adaptation Plan and the Taget Adaptation Achitectue Model to this model in ode to povide them fo the middle-laye feedback loop. Moeove, based on the cuent and taget achitectues of the middle-laye loop, econfiguation commands (Action-2) ae geneated to adapt this feedback loop, e.g., to eplace the Adaptation Analyze (cf. Figue 8.6) with a vesion that is able to execute the new adaptation plan. Finally, the Admin-2 opeation adapts the middle-laye feedback loop by executing the econfiguation commands and by poviding the new adaptation plan and taget application achitectue model to this feedback loop. Oveall, the EUREMA language is able to captue PLASMA s layeed achitectue and its feedback loops. Howeve, the pope modeling of PLASMA is had to assess as the untime models ae only implicitly maintained by the employed middlewae and thei handling is not made explicit by PLASMA. Thus, we deived as fa as possible the diffeent untime models and thei usage by opeations fom infomal desciptions in [Tajalli et al. 2010].

62 50 8 Discussion and Evaluation Discussion The esults of modeling Rainbow, DiVA, and PLASMA demonstate that the EUREMA language is expessive enough to captue these state-of-the-at appoaches to self-adaptive softwae and diffeent vaiants of feedback loops. Theeby, we coveed cases whee feedback loops ae diven by ADL o MDE techniques and whee single as well as layeed feedback loops ae employed. Futhemoe, the obtained EUREMA models clealy chaacteize the feedback loops, adaptation activities, and untime models of the appoaches, which is typically neglected. Howeve, the evidence that the EUREMA language is expessive enough to specify abitay feedback loops is limited since we only coveed thee exemplay appoaches. Thus, these findings cannot be genealized to any self-adaptive softwae. Moeove, modeling these thee famewoks with EUREMA is the initial step fo e-engineeing and migating them towad a flexible EUREMA-based solution. Typically, all of these famewoks have a modula design, which makes it staightfowad to extact these modules as EUREMA model opeations. Howeve, the untime models ae often only implicitly maintained, which makes it difficult to make them explicit as poposed by EUREMA. Nevetheless, if this is feasible, the inteplay of the modules and untime models can be flexibly addessed by EUREMA instead of pedefining it by a famewok. This potentially leveages EUREMA s benefits fo these famewok-based appoaches. 8.4 Runtime Chaacteistics of the EUREMA Intepete Finally, we evaluate the EUREMA intepete by discussing its untime chaacteistics. Theefoe, we conducted expeiments to quantify the load and ovehead of the intepete compaed to a codebased solution to execute the self-epai feedback loop as defined by the FLDs depicted in Figues 3.8 and 3.6. Fo the expeiments, we consideed the case of the self-epai feedback loop, in which each un of the feedback loop always identifies failues. Moeove, a wam-up phase taking place befoe the actual measuements executes the feedback loop instance moe than five times, such that the condition banching the contol flow in the FLD depicted in Figue 3.6 is always fulfilled and the Deep check fo failues opeation is executed in each un. Thus, fo the measuements, all five opeations of the self-epai feedback loop (namely, Update, Check fo failues, Deep check fo failues, Repai, and Effect) ae executed in each un of the loop instance. As implementations fo these model opeations, we povided softwae modules as mocks that have untime models as input as it is defined in the FLDs. Moeove, all untime models that ae the output of any model opeation ae aleady used as input of the same opeation. Thus, no new models ae poduced by the mocks. In contast, all untime models ae pe-defined and they ae not changed at all by the mocks. Each mock can be assigned a peiod of time, fo which it geneates load to simulate computations of the model opeations. To evaluate the untime chaacteistics of the EUREMA intepete, we implemented a code-based solution in Java that executes the self-epai feedback loop. This solution does not use any EUREMA model as visualized by the FLDs fo the self-epai feedback loop. In contast, the execution is hadcoded by sequentially invoking the five mocks, one fo each model opeation of the self-epai feedback loop. Moeove, this code-based solution povides the untime models equied as input fo invoking the mocks. The expeiments we conducted ae configued by two paametes. Fist, the peiod of time assigned to the mocks defines the intenal computation time of the model opeations. The same peiod of time is assigned to all mocks fo one expeiment and they vay fo the diffeent expeiments. This esults in fou goups of expeiments, eithe assigning a peiod of 0ms, 5ms, 10ms, o 20ms to all mocks. Since the self-epai feedback loop has five model opeations, this constitutes a total computation time of eithe 0ms, 25ms, 50ms, o 100ms fo one un of the feedback loop instance. The second paamete is

63 8.4 Runtime Chaacteistics of the EUREMA Intepete 51 the fequency of consecutive uns of the feedback loop instance, which detemines the execution ate of the instance. The fequency is defined by its ecipocal, i.e., the peiod of time between two consecutive activations of the same feedback loop instance. Fo each of the fou goups of expeiments, we vaied the peiod stating fom 15ms and doubling it until 960ms. Fo example, a peiod of 15ms means that the feedback loop instance is executed evey 15ms, which is only feasible if the total computation time of the feedback loop plus the ovehead of the code-based solution o the EUREMA intepete is below 15ms. Fo each feasible combination of these two paametes, we measued the load of the Java vitual machine fo the code-based solution and the EUREMA intepete while executing the self-epai feedback loop fo a total time of ten minutes. The esults of the expeiments 1 ae depicted in Figues 8.9 and 8.10 and discussed in the following Aveage CPU Load [%] Code/0ms Code/25ms Code/50ms Code/100ms Intepete/0ms Intepete/25ms Intepete/50ms Intepete/100ms Peiod [ms] Fig. 8.9: Aveage CPU Load of the code-based solution (Code) and EUREMA (Intepete) Figue 8.9 visualizes the aveage CPU load of the code-based solution (solid gay lines) and the EUREMA intepete (dashed black lines) fo the diffeent fequencies of executing the feedback loop instance. Moeove, each gaph efes to a specific total computation time of the feedback loop instance (see legend). Based on this figue, we may geneally obseve that the aveage load deceases fo both solutions and all computation times of the feedback loop instance, if the peiod between consecutive uns of the feedback loop instance inceases. This obsevation is not supising since unning a feedback loop less fequently is supposed to cause less load. Moeove, we may obseve that the EUREMA intepete causes slightly moe load than the codebased solution when the computation time of the feedback loop is 0ms (cf. gaphs Code/0ms and Intepete/0ms in Figue 8.9). Howeve, fo the othe cases of the computation time (25ms, 50ms, and 100ms), thee is no appaent diffeences between the loads of the code-based solution and the intepete, and the coesponding gaphs fo these thee cases ovelap. Thus, the ovehead of the intepete is noticeable fo the hypothetical case that the feedback loop does not pefom any computations (computation time is 0ms) and theefoe, does not cause any load. 1 The expeiments wee conducted on the following platfom: quad-coe CPU (Intel Coe i5-2400, 3.10GHz), 8GB RAM, Ubuntu (Kenel ), Java SE Runtime Envionment , and Eclipse Modeling Famewok (EMF) Runtime and Tools The CPU load has been measued by the monitoing capabilities of Java VisualVM povided with the Java Development Kit 6 ( ).

64 52 8 Discussion and Evaluation To futhe investigate the ovehead of intepeting EUREMA models in contast to the code-based solution, we calculated the ovehead as the diffeence between the aveage loads of the intepete and the aveage loads of the code-based solution. This is depicted in Figue 8.10 fo the fequency peiods fom 60ms to 960ms. We may obseve that fo all cases the ovehead of the EUREMA intepete with espect to the code based solution is always below 0.2% and tends to decease with inceasing fequency peiods. This assumptions is suppoted by the ovehead we pedicted (cf. pediction gaph in Figue 8.10), which is the aveage ovehead based on all measuements fo all fequencies and computation times, and nomalized fo the fequencies. 0.2 Diffeences in aveage CPU loads [%] ms 25ms 50ms 100ms Pediction Peiod [ms] Fig. 8.10: Intepete ovehead by means of the diffeences in aveage CPU loads Summing up, the expeiments of quantifying the untime chaacteistics of the EUREMA intepete show that the ovehead of intepeting EUREMA models is negligible. In paticula, the hypothetical case when the feedback loop s opeations do not pefom any intenal computations evealed the pue load caused by the EUREMA intepete. The aveage of this pue load was fo all expeiments below 1% (cf. Figue 8.9). Thus, in absolute tems, the EUREMA intepete woks efficiently fo the consideed case of executing the EUREMA models specifying the self-epai feedback loop. Moeove, employing the EUREMA intepete and accepting its ovehead povides the flexibility to dynamically adapt feedback loops as discussed in Sections 5 and 6. The validity of the expeiments is theatened since we implemented the altenative, code-based solution, such that the compaison between the code-based solution and the EUREMA intepete needs futhe investigations. Howeve, we have shown that the intepete woks efficiently in absolute tems by causing a negligible aveage load (cf. pevious paagaph). Anothe theat of validity is the use of the specific feedback loop as defined in the FLDs depicted in Figues 3.8 and 3.6. Nevetheless, we think that this specific feedback loop is a typical feedback loop since it follows the MAPE pinciple like the example appoaches we modeled in Section 8.3. Moeove, the complexity of the specific feedback loop by means of numbes of model opeations and untime models can be questioned and how the intepete behaves fo lage EUREMA models. Thus, the scalability of the intepete needs to be futhe investigated. Howeve, state-of-the-at appoaches (cf. Section 8.3) do not employ significantly moe complex feedback loops than the self-epai feedback loop with espect to the diffeent sizes of the FLDs.

65 Chapte 9 Conclusion and Futue Wok In this aticle, we pesented EUREMA, a model-diven appoach fo engineeing adaptation engines of self-adaptive softwae. By executable untime megamodels, EUREMA povides a domain-specific modeling language to specify feedback loops and an intepete to execute the loops. Theeby, the EUREMA language suppots the explicit specification of individual adaptation activities and untime models as well as complete feedback loops by modula megamodels. Moeove, the inteplay and coodination between multiple feedback loops can be captued and layes of feedback loops can be specified and ealized to dynamically adjust the adaptation engine. Additionally, the co-existence of off-line adaptation and self-adaptation is suppoted by uploading megamodel modules, which specify adaptation activities o complete feedback loops, into the adaptation engine and by activating them to execute the off-line adaptation. We evaluated EUREMA by discussing equiements fo adaptation engines, the language by modeling state-of-the-at appoaches to self-adaptive softwae, and the intepete by investigating its untime chaacteistics. In EUREMA, the megamodels specifying feedback loops ae kept alive at untime and they ae executed by an intepete. This povides the equied flexibility to cope with changes of the megamodels at untime when dynamically adjusting the adaptation engine. This is necessay fo stacking feedback loops in layeed achitectues o fo executing off-line adaptation. In this context, EUREMA diectly suppots eflective feedback loops by using its megamodels diectly as eflection models. This avoids the development of specific sensos, effectos, and opeations to obtain and maintain eflective views of feedback loops. Nevetheless, an enginee may take this effot in ode to utilize use-defined eflection models of feedback loops in EUREMA. In contast to existing wok on self-adaptive softwae, EUREMA is a seamless appoach that coves the specification as well as the execution of adaptation engines by an executable modeling language, coesponding untime models, and an intepete. Related appoaches on modeling languages fo selfadaptive softwae povide no untime suppot fo thei models, while elated wok on famewoks fo self-adaptive softwae does not suppot the explicit modeling of feedback loops. Moeove, famewoks do not povide the flexibility fo thei uses in stuctuing use-defined adaptation activities to fom single o multiple feedback loops in an abitay numbe of layes. In this context, EUREMA does not impose any estiction on enginees when developing adaptation engines. As futue wok, we plan to futhe elaboate the modeling language and the intepete. With espect to EUREMA models and thei execution, we want to study the equiements fo adaptation engines that ae cuently not addessed by EUREMA. Thus, we want to investigate an event-diven, incemental pocessing of adaptation activities and concuency in geneal, howeve, without tackling the distibution of adaptation engines. Futhemoe, we want to investigate the integation of model-based analysis techniques to ease the modulaity and euse of model fagments, like model opeations, and fo analyzing 53

66 54 9 Conclusion and Futue Wok specifications of feedback loops. Finally, the executability of the EUREMA models makes them amenable fo simulation in ode to validate and test adaptation engines duing the development of self-adaptive softwae. Simulation may, fo example, help in developing and efining feedback loop designs, like adaptation stategies fo econfiguing the adaptable softwae.

67 Bibliogaphy Special Issue on Adaptive middlewae. Communications of the ACM Seies, vol. 45, 6. ACM Pess. Amoui, M., Deakhshanmanesh, M., Ebet, J., and Tahvildai, L Achieving dynamic adaptation via management and intepetation of untime models. Jounal of Systems and Softwae 85, 12, Andesson, J., Baesi, L., Bencomo, N., de Lemos, R., Gola, A., Inveadi, P., and Vogel, T Softwae Engineeing Pocesses fo Self-Adaptive Systems. In Softwae Engineeing fo Self-Adaptive Systems II, R. de Lemos, H. Giese, H. A. Mülle, and M. Shaw, Eds. LNCS Seies, vol Spinge, Andesson, J., de Lemos, R., Malek, S., and Weyns, D Reflecting on self-adaptive softwae systems. In Poc. of the ICSE Wokshop on Softwae Engineeing fo Adaptive and Self-Managing Systems (SEAMS). IEEE Compute Society, Astom, K. J. and Wittenmak, B Adaptive Contol 2nd Ed. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA. Babeo, M., Fabo, M. D., and Bézivin, J Taceability and Povenance Issues in Global Model Management. In Poc. of 3d Wokshop on Taceability (ECMDA-TW) Bencomo, N. and Blai, G Using Achitectue Models to Suppot the Geneation and Opeation of Component-Based Adaptive Systems. In Softwae Engineeing fo Self-Adaptive Systems, B. Cheng, R. de Lemos, H. Giese, P. Inveadi, and J. Magee, Eds. LNCS Seies, vol Spinge, Bézivin, J., Gead, S., Mulle, P.-A., and Rioux, L MDA components: Challenges and Oppotunities. In Fist Intl. Wokshop on Metamodelling fo MDA Bézivin, J., Jouault, F., and Valduiez, P On the Need fo Megamodels. In Poc. of the Wokshop on Best Pactices fo Model-Diven Softwae Development. Blai, G., Bencomo, N., and Fance, R. B Compute 42, 10, Bazie, F. M. T., Kephat, J. O., Paunak, H. V. D., and Huhns, M. N Agents and Sevice- Oiented Computing fo Autonomic Computing: A Reseach Agenda. IEEE Intenet Computing 13, 3, Buhn, J., Niklaus, C., Vogel, T., and Witz, G Compehensive suppot fo management of Entepise Applications. In Poc. of the 6th ACS/IEEE Intl. Confeence on Compute Systems and Applications (AICCSA). IEEE Compute Society, Buhn, J. and Witz, G MKenel: a manageable kenel fo EJB-based systems. In Poc. of the 1st Intl. Confeence on Autonomic Computing and Communication Systems (Autonomics). ICST (Institute fo Compute Sciences, Social-Infomatics and Telecommunications Engineeing), ICST, Bussels, Belgium, Belgium,

68 56 BIBLIOGRAPHY Bun, Y., Seugendo, G. D. M., Gacek, C., Giese, H. M., Kienle, H. M., Litoiu, M., Mülle, H. A., Pezzè, M., and Shaw, M Engineeing Self-Adaptive Systems though Feedback Loops. In Softwae Engineeing fo Self-Adaptive Systems, B. H. C. Cheng, R. Lemos, H. Giese, P. Inveadi, and J. Magee, Eds. LNCS Seies, vol Spinge, Bumeste, S., Giese, H., Münch, E., Obeschelp, O., Klein, F., and Scheidele, P Tool Suppot fo the Design of Self-Optimizing Mechatonic Multi-Agent Systems. Intenational Jounal on Softwae Tools fo Technology Tansfe (STTT) 10, 3, Bumeste, S., Giese, H., and Obeschelp, O Hybid UML Components fo the Design of Complex Self-optimizing Mechatonic Systems. In Poc. of 1st Intl. Confeence on Infomatics in Contol, Automation and Robotics (ICINCO), H. Aaujo, A. Vieia, J. Baz, B. Encanacao, and M. Cavalho, Eds. INSTICC Pess, Cheng, B. H., de Lemos, R., Giese, H., Inveadi, P., Magee, J., Andesson, J., Becke, B., Bencomo, N., Bun, Y., Cukic, B., Seugendo, G. D. M., Dustda, S., Finkelstein, A., Gacek, C., Geihs, K., Gassi, V., Kasai, G., Kienle, H. M., Kame, J., Litoiu, M., Malek, S., Miandola, R., Mülle, H. A., Pak, S., Shaw, M., Tichy, M., Tivoli, M., Weyns, D., and Whittle, J Softwae Engineeing fo Self-Adaptive Systems: A Reseach Roadmap. In Softwae Engineeing fo Self-Adaptive Systems, B. H. Cheng, R. de Lemos, H. Giese, P. Inveadi, and J. Magee, Eds. LNCS Seies, vol Spinge, Cheng, S.-W Rainbow: Cost-Effective Softwae Achitectue-Based Self-Adaptation. Ph.D. thesis, School of Compute Science, Canegie Mellon Univesity, Pittsbugh, USA. Cheng, S.-W. and Galan, D Stitch: A language fo achitectue-based self-adaptation. Jounal of Systems and Softwae 85, 12, Cheng, S.-W., Huang, A.-C., Galan, D., Schmel, B., and Steenkiste, P An Achitectue fo Coodinating Multiple Self-Management Systems. In Poc. of the 4th Woking IEEE/IFIP Confeence on Softwae Achitectue (WICSA). IEEE Compute Society, de Lemos, R., Giese, H., Mülle, H. A., Shaw, M., Andesson, J., Litoiu, M., Schmel, B., Tamua, G., Villegas, N. M., Vogel, T., Weyns, D., Baesi, L., Becke, B., Bencomo, N., Bun, Y., Cukic, B., Desmaais, R., Dustda, S., Engels, G., Geihs, K., Goeschka, K., Gola, A., Gassi, V., Inveadi, P., Kasai, G., Kame, J., Lopes, A., Magee, J., Malek, S., Mankovskii, S., Miandola, R., Mylopoulos, J., Niestasz, O., Pezzè, M., Pehofe, C., Schäfe, W., Schlichting, R., Smith, D. B., Sousa, J. P., Tahvildai, L., Wong, K., and Wuttke, J Softwae Engineeing fo Self-Adaptive Systems: A second Reseach Roadmap. In Softwae Engineeing fo Self-Adaptive Systems II, R. de Lemos, H. Giese, H. A. Mülle, and M. Shaw, Eds. LNCS Seies, vol Spinge, de Oliveia, F. A., Shaock, R., and Ledoux, T Synchonization of Multiple Autonomic Contol Loops: Application to Cloud Computing. In Poc. of the 14th Intl. Confeence on Coodination Models and Languages (COORDINATION), M. Sijani, Ed. LNCS Seies, vol Spinge, Ehles, J. and Hasselbing, W A Self-adaptive Monitoing Famewok fo Component-Based Softwae Systems. In Poc. of the 5th Euopean Confeence on Softwae Achitectue (ECSA), I. Cnkovic, V. Guhn, and M. Book, Eds. LNCS Seies, vol Spinge, Fave, J.-M Foundations of Model (Diven) (Revese) Engineeing : Models Episode I: Stoies of The Fidus Papyus and of The Solaus. In Language Engineeing fo Model-Diven Softwae Development. Numbe in Dagstuhl Semina Poc. IBFI. Findeisen, W., Bailey, F., Bdys, M., Malinowski, K., Tatjewski, P., and Wozniak, A Contol and Coodination in Hieachical Systems. Intenational seies on applied systems analysis. J. Wiley.

69 BIBLIOGRAPHY 57 Floch, J., Hallsteinsen, S., Stav, E., Eliassen, F., Lund, K., and Gjoven, E Using Achitectue Models fo Runtime Adaptability. IEEE Softwae 23, 2, Fance, R. and Rumpe, B Model-diven Development of Complex Softwae: A Reseach Roadmap. In Poc. of the ICSE Wokshop on the Futue of Softwae Engineeing (FOSE). IEEE Compute Society, Fey, S., Diaconescu, A., and Demeue, I. M Achitectual Integation Pattens fo Autonomic Management Systems. In Poc. of the 9th IEEE Intl. Confeence and Wokshops on the Engineeing of Autonomic and Autonomous Systems (EASe). Gacek, C., Giese, H., and Hada, E Fiends o Foes? A Conceptual Analysis of Self-Adaptation and IT Change Management. In Poc. of the ICSE Wokshop on Softwae Engineeing fo Adaptive and Self-Managing Systems (SEAMS). ACM, Galan, D., Cheng, S.-W., Huang, A.-C., Schmel, B., and Steenkiste, P Rainbow: Achitectue- Based Self-Adaptation with Reusable Infastuctue. Compute 37, 10, Gat, E On Thee-Laye Achitectues. In Atificial Intelligence and Mobile Robots, D. Kotenkamp, R. P. Bonasso, and R. Muphy, Eds. MIT/AAAI Pess. Geogas, J. C., Hoek, A., and Taylo, R. N Using Achitectual Models to Manage and Visualize Runtime Adaptation. Compute 42, 10, Giese, H. and Wagne, R Fom model tansfomation to incemental bidiectional model synchonization. Softwae and Systems Modeling 8, 1, Gueye, S. M. K., De Palma, N., and Rutten, E Coodinating Enegy-awae Administation Loops Using Discete Contol. In Poc. of the 8th Intl. Confeence on Autonomic and Autonomous Systems (ICAS). IARIA, Heaven, W., Sykes, D., Magee, J., and Kame, J A Case Study in Goal-Diven Achitectual Adaptation. In Softwae Engineeing fo Self-Adaptive Systems, B. H. Cheng, R. de Lemos, H. Giese, P. Inveadi, and J. Magee, Eds. LNCS Seies, vol Spinge, Hebig, R., Giese, H., and Becke, B Making Contol Loops Explicit When Achitecting Self- Adaptive Systems. In Poc. of the 2nd Intl. Wokshop on Self-Oganizing Achitectues (SOAR). ACM, Hellestein, J. L., Diao, Y., Paekh, S., and Tilbuy, D. M Feedback Contol of Computing Systems. John Wiley & Sons. Hestemeye, T., Obeschelp, O., and Giese, H Stuctued Infomation Pocessing Fo Selfoptimizing Mechatonic Systems. In Poc. of 1st Intl. Confeence on Infomatics in Contol, Automation and Robotics (ICINCO), H. Aaujo, A. Vieia, J. Baz, B. Encanacao, and M. Cavalho, Eds. INSTICC Pess, Isemann, R., Lachmann, K.-H., and Matko, D Adaptive contol systems. Pentice Hall Intenational seies in systems and contol engineeing. Pentice Hall, New Yok. Issany, V., Capouscio, M., and Geogantas, N A Pespective on the Futue of Middlewaebased Softwae Engineeing. In Poc. of the ICSE Wokshop on the Futue of Softwae Engineeing (FOSE). IEEE Compute Society, Kephat, J. O., Chan, H., Das, R., Levine, D. W., Tesauo, G., Rawson, F., and Lefugy, C Coodinating Multiple Autonomic Manages to Achieve Specified Powe-Pefomance Tadeoffs. In Poc. of the 4th Intl. Confeence on Autonomic Computing (ICAC). IEEE Compute Society, Kephat, J. O. and Chess, D The Vision of Autonomic Computing. Compute 36, 1,

70 58 BIBLIOGRAPHY Koka, M. M., Baclawski, K., and Eaca, Y. A Contol Theoy-Based Foundations of Self- Contolling Softwae. Intelligent Systems and thei Applications 14, 3, Kame, J. and Magee, J Self-Managed Systems: an Achitectual Challenge. In Poc. of the ICSE Wokshop on the Futue of Softwae Engineeing (FOSE). IEEE, Maes, P Concepts and expeiments in computational eflection. In Confeence poceedings on Object-oiented pogamming systems, languages and applications (OOPSLA). ACM, McKinley, P., Sadjadi, S. M., Kasten, E. P., and Cheng, B. H Composing Adaptive Softwae. IEEE Compute 37, 7, Moin, B., Baais, O., Jézéquel, J.-M., Fleuey, F., and Solbeg, A. 2009a. Suppot Dynamic Adaptation. Compute 42, 10, Run.time to Moin, B., Baais, O., Nain, G., and Jézéquel, J.-M. 2009b. Taming Dynamically Adaptive Systems using models and aspects. In Poc. of the 31st Intl. Confeence on Softwae Engineeing (ICSE). IEEE Compute Society, Moin, B., Fleuey, F., Bencomo, N., Jézéquel, J.-M., Solbeg, A., Dehlen, V., and Blai, G An Aspect-Oiented and Model-Diven Appoach fo Managing Dynamic Vaiability. In Poc. of the 11th Intl. Confeence on Model Diven Engineeing Languages and Systems (MODELS), K. Czanecki, I. Obe, J.-M. Buel, A. Uhl, and M. Völte, Eds. LNCS Seies, vol Spinge, Moin, B., Ledoux, T., Hassine, M. B., Chauvel, F., Baais, O., and Jézéquel, J.-M. 2009c. Unifying Runtime Adaptation and Design Evolution. In Poc. of the 9th IEEE Intl. Confeence on Compute and Infomation Technology (CIT) - Volume 02. IEEE Compute Society, Mülle, H. A., Pezzè, M., and Shaw, M Visibility of contol in adaptive systems. In Poc. of the 2nd Intl. Wokshop on Ulta-lage-scale Softwae-intensive Systems (ULSSIS). ACM, Object Management Goup OMG Unified Modeling Language (OMG UML), Supestuctue, Vesion Oeizy, P., Medvidovic, N., and Taylo, R. N Achitectue-based untime softwae evolution. In Poc. of the 20th Intl. Confeence on Softwae Engineeing (ICSE). IEEE Compute Society, Oeizy, P., Medvidovic, N., and Taylo, R. N Runtime softwae adaptation: famewok, appoaches, and styles. In Companion of the 30th Intl. Confeence on Softwae Engineeing (ICSE). ACM, Ramiez, A. J., Cheng, B. H., and McKinley, P Adaptive Monitoing of Softwae Requiements. In Poc. of the 1st Intl. Wokshop on [email protected] (RE@RunTime). IEEE Compute Society, Rouvoy, R., Baone, P., Ding, Y., Eliassen, F., Hallsteinsen, S., Loenzo, J., Mamelli, A., and Scholz, U MUSIC: Middlewae Suppot fo Self-Adaptation in Ubiquitous and Sevice-Oiented Envionments. In Softwae Engineeing fo Self-Adaptive Systems, B. Cheng, R. de Lemos, H. Giese, P. Inveadi, and J. Magee, Eds. LNCS Seies, vol Spinge, Salehie, M. and Tahvildai, L Self-adaptive softwae: Landscape and eseach challenges. ACM Tans. Auton. Adapt. Syst. 4, 2, Schmidt, D., White, J., and Gokhale, A Simplifying autonomic entepise Java Bean applications via model-diven engineeing and simulation. Softwae and Systems Modeling 7, 1, Shaw, M Beyond objects: A softwae design paadigm based on pocess contol. ACM SIGSOFT Softwae Engineeing Notes 20, 1,

71 BIBLIOGRAPHY 59 Song, H., Huang, G., Chauvel, F., Xiong, Y., Hu, Z., Sun, Y., and Mei, H Suppoting untime softwae achitectue: A bidiectional-tansfomation-based appoach. Jounal of Systems and Softwae 84, 5, Sykes, D., Heaven, W., Magee, J., and Kame, J Fom goals to components: a combined appoach to self-management. In Poc. of the Intl. Wokshop on Softwae Engineeing fo Adaptive and Self-managing Systems (SEAMS). ACM, 1 8. Tajalli, H., Gacia, J., Edwads, G., and Medvidovic, N PLASMA: a plan-based layeed achitectue fo softwae model-diven adaptation. In Poc. of the IEEE/ACM Intl. Confeence on Automated Softwae Engineeing (ASE). ACM, Villegas, N. and Mülle, H. A Managing Dynamic Context to Optimize Smat Inteactions and Sevices. In The Smat Intenet - Cuent Reseach and Futue Applications, M. Chignell, J. Cody, J. Ng, and Y. Yesha, Eds. LNCS Seies, vol Spinge, Villegas, N. M., Tamua, G., Mülle, H. A., Duchien, L., and Casallas, R DYNAMICO: A Refeence Model fo Govening Contol Objectives and Context Relevance in Self-Adaptive Softwae Systems. In Softwae Engineeing fo Self-Adaptive Systems II, R. de Lemos, H. Giese, H. A. Mülle, and M. Shaw, Eds. LNCS Seies, vol Spinge, Vogel, T. and Giese, H Adaptation and Abstact Runtime Models. In Poc. of the 5th ICSE Wokshop on Softwae Engineeing fo Adaptive and Self-Managing Systems (SEAMS). ACM, Vogel, T. and Giese, H. 2012a. A Language fo Feedback Loops in Self-Adaptive Systems: Executable Runtime Megamodels. In Poc. of the 7th Intl. Symposium on Softwae Engineeing fo Adaptive and Self-Managing Systems (SEAMS). IEEE Compute Society, Vogel, T. and Giese, H. 2012b. Requiements and Assessment of Languages and Famewoks fo Adaptation Models. In Models in Softwae Engineeing (MoDELS 2011 Wokshops). LNCS Seies, vol Spinge, Vogel, T., Neumann, S., Hildebandt, S., Giese, H., and Becke, B Model-Diven Achitectual Monitoing and Adaptation fo Autonomic Systems. In Poc. of the 6th IEEE/ACM Intl. Confeence on Autonomic Computing and Communications (ICAC). ACM, Vogel, T., Neumann, S., Hildebandt, S., Giese, H., and Becke, B Incemental Model Synchonization fo Efficient Run-Time Monitoing. In Models in Softwae Engineeing (MoDELS 2009 Wokshops). LNCS Seies, vol Spinge, Vogel, T., Seibel, A., and Giese, H The Role of Models and Megamodels at Runtime. In Models in Softwae Engineeing (MoDELS 2010 Wokshops). LNCS Seies, vol Spinge, Vomant, P., Weyns, D., Malek, S., and Andesson, J On inteacting contol loops in selfadaptive systems. In Poc. of the 6th Intl. Symposium on Softwae Engineeing fo Adaptive and Self-Managing Systems (SEAMS). ACM, Weyns, D., Malek, S., and Andesson, J FORMS: Unifying efeence model fo fomal specification of distibuted self-adaptive systems. ACM Tans. Auton. Adapt. Syst. 7, 1, 8:1 8:61. Weyns, D., Schmel, B., Gassi, V., Malek, S., Miandola, R., Pehofe, C., Wuttke, J., Andesson, J., Giese, H., and Goeschka, K On Pattens fo Decentalized Contol in Self-Adaptive Systems. In Softwae Engineeing fo Self-Adaptive Systems II, R. de Lemos, H. Giese, H. A. Mülle, and M. Shaw, Eds. LNCS Seies, vol Spinge,

72

73 Aktuelle Technische Beichte des Hasso-Plattne-Instituts Band ISBN Titel Autoen / Redaktion Scalable Compatibility fo Embedded Real-Time components via Language Pogessive Timed Automata Cybe-Physical Systems with Dynamic Stuctue: Towads Modeling and Veification of Inductive Invaiants Theoies and Inticacies of Infomation Secuity Poblems Coveing o Complete? Discoveing Conditional Inclusion Dependencies Viete Deutsche IPv6 Gipfel 2011 Undestanding Cyptic Schemata in Lage Extact-Tansfom-Load Systems The JCop Language Specification MDE Settings in SAP: A Desciptive Field Study Industial Case Study on the Integation of SysML and AUTOSAR with Tiple Gaph Gammas Quantitative Modeling and Analysis of Sevice-Oiented Real-Time Systems using Inteval Pobabilistic Timed Automata Poceedings of the 4th Many-coe Applications Reseach Community (MARC) Symposium An Abstaction fo Vesion Contol Systems Web-based Development in the Lively Kenel Einfühung von IPv6 in Untenehmensnetzen: Ein Leitfaden Advancing the Discovey of Unique Column Combinations Data in Business Pocesses Stefan Neumann, Holge Giese Basil Becke, Holge Giese Anne V. D. M. Kayem, Chistoph Meinel (Eds.) Jana Bauckmann, Ziawasch Abedjan, Ulf Lese, Heiko Mülle, Felix Naumann Chistoph Meinel, Haald Sack (Hsg.) Alexande Albecht, Felix Naumann Malte Appeltaue, Robet Hischfeld Regina Hebig, Holge Giese Holge Giese, Stephan Hildebandt, Stefan Neumann, Sebastian Wätzoldt Chistian Kause, Holge Giese Pete Töge, Andeas Polze (Eds.) Matthias Kleine, Robet Hischfeld, Gilad Bacha Jens Lincke, Robet Hischfeld (Eds.) Wilhelm Boeddinghaus, Chistoph Meinel, Haald Sack Ziawasch Abedjan, Felix Naumann Andeas Meye, Segey Sminov, Mathias Weske Adaptive Windows fo Duplicate Detection Uwe Daisbach, Felix Naumann, Sascha Szott, Olive Wonnebeg CSOM/PL: A Vitual Machine Poduct Line Michael Haupt, Stefan Ma, Robet Hischfeld

74 ISBN ISSN