{"id":197,"date":"2012-04-20T08:47:09","date_gmt":"2012-04-20T06:47:09","guid":{"rendered":"http:\/\/www.hpi.uni-potsdam.de\/giese\/gforge\/mdelab\/?page_id=197"},"modified":"2021-09-01T09:54:11","modified_gmt":"2021-09-01T07:54:11","slug":"morisia","status":"publish","type":"page","link":"https:\/\/www.hpi.uni-potsdam.de\/giese\/public\/mdelab\/mdelab-projects\/software-engineering-for-self-adaptive-systems\/morisia\/","title":{"rendered":"Models at Runtime for Self-Adaptive Software"},"content":{"rendered":"

\"morisia_235x85\"<\/p>\n

In this project, we investigate the role of\u00a0<\/span>Mo<\/strong>dels at <\/span>R<\/strong>unt<\/span>i<\/strong>me for <\/span>S<\/strong>elf-Adapt<\/span>i<\/strong>ve Softw<\/span>a<\/strong>re (MORISIA), i.e., models that are used in feedback\u00a0loops to enable self-adaptation. This\u00a0has resulted in a model-driven framework that follows the concepts of the external approach<\/em>, MAPE-K<\/em>, and runtime models<\/em>.<\/span><\/p>\n

<\/p>\n

Concepts<\/strong><\/h3>\n

The so called\u00a0<\/span>external approach (cf. Figure 1) splits the software into the domain and adaptation logic, respectively, the adaptable software and the adaptation engine, which promotes separation of concerns. The domain logic implements the domain functionality for the end users, while the adaptation logic implements a feedback loop that controls the runtime adaptation of the domain logic. Both logics are integrated by well-defined sensors and effectors.<\/span><\/p>\n

As shown in Figure 1, the adaptation engine is refined by a blueprint\u00a0for self-adaptive systems, called MAPE-K, that has been proposed by Kephart and Chess [1]. The blueprint considers four adaptation activities that monitor and analyze the adaptable software, and if needed, plan and execute adaptations to the adaptable software while sharing some knowledge.<\/p>\n

\"FeedbackLoopsAndModels\"<\/a>

Figure 1: External Approach (left), MAPE-K (middle), Runtime Models (right)
Figure taken from [3]<\/p><\/div>\n

In the scope of this project, we refined the knowledge<\/em> to a set of runtime models that are used in the feedback loop. We investigated which kind of runtime models are required to reflect the adaptable software as well as to specify the adaptation logic, i.e., the four MAPE activities. This has resulted in a categorization of runtime models [2] that is shown in Figure 1.\u00a0As stated in [3]:<\/p>\n

\"Reflection Models<\/em> reflect the adaptable software and its environment, and they are\u00a0updated by monitoring the software and environment. Thereby, Monitoring Models<\/em>\u00a0map system-level observations to the abstraction level of reflection models. The reflection models are analyzed to identify adaptation needs by applying Evaluation Models<\/em>\u00a0that, e.g., define constraints on reflection models. If adaptation needs have been identified, the planning activity devises a plan prescribing the adaptation on the reflection\u00a0models. Planning is specified by Change Models<\/em> describing the adaptable software\u2019s\u00a0variability space. Evaluation models such as utility preferences guide the exploration\u00a0of this space to find an appropriate adaptation. Finally, the execute activity enacts the\u00a0planned adaptation on the adaptable software based on Execution Models<\/em> that refine\u00a0model-level adaptation to system-level adaptation.
\nEvaluation and change models do not have to be strictly separate models, which is\u00a0exemplified by event-condition-action rules that address the analyze (evaluating the\u00a0condition) and the plan (applying the actions) activities in one step. Thus, we combine\u00a0them to Adaptation Models<\/em> [4]. Monitoring and execution models\u00a0are concerned with the synchronization of the adaptable software and the reflection\u00a0models. This is known as the causal connection such that we consider\u00a0them as Causal Connection Models<\/em>.\"<\/p>\n

Based on the ideas of the external approach, MAPE-K, and runtime models used in feedback loops, we develop a model-driven framework for engineering self-adaptive software.<\/p>\n

Framework Overview<\/strong><\/h3>\n

The following figure taken from [5] depicts an overview on the framework.<\/p>\n

\"\"<\/a>

Figure 2: Overview on the Models@run.time Framework for Self-Adaptive Software Systems
Figure taken from [5]<\/p><\/div>\n

The Managed System<\/em> is the adaptable subsystem\/software that contains the domain logic. It can be monitored and adapted through Sensors<\/em> and Effectors<\/em> that maintain a so called Source Model<\/em>. This model is a causally connected self-representation to the managed system, i.e., changes of the managed system are reflected in the model, and changes of the model are reflected to the managed system.\u00a0 To ease this causal connection, the source model is at the same abstraction level as the sensors and effectors, which makes the source model complex, detailed, and platform-specific as it covers multiple concerns and it is rather related to the solution space of the managed systems. This makes the source model laborious and difficult to use by autonomic managers. However, the source model enables the application of model-driven engineering techniques on top of it.
\nTherefore, multiple Target Models<\/em> are derived and incrementally synchronized with the source model. With respect to the source model, a target model is less complex, at a higher level of abstraction, and platform-independent as it focuses on a specific concern such as performance or failures and it is related to problem space of the managed system. Thus, target models provide problem space oriented views on the managed system, i.e., knowledge that is\u00a0 used by autonomic managers\/adaptation engines to perform the feedback loop's adaptation activities (MAPE).<\/p>\n

Source and target models are synchronized with each other in both directions:<\/p>\n