scribes "a system’s awareness of its own self-awareness" [216, p. 8], in which self-awareness is defined similar to self-adaptation (cf. [216]).
In accordance to these definitions, in our understanding, a system can only self-improve if the adaptation control itself changes. Otherwise, the adaptation control can neither handle unknown situations nor improve the performance of adaptations. In contrast, self-optimization changes the managed resources but not the adaptation control. The same is true for hierarchical self-optimizing ap- proaches (e.g., [193] or [154]) as the hierarchy offers decision-making on different levels but does not change the adaptation control mechanism in a substantial way. The increasing importance of self-improvement is reflected in the research community by arising workshops, such as the International Workshop on Self- Improving System Integration. This thesis contributes to this research with an inclusion of a generic reusable approach to self-improvement at runtime.
2.2. Self-adaptive Systems
The term Self-adaptive System encompasses, in its broadest definition, dif- ferent types of systems which are able to adapt themselves, such as the ad- justment of the human eye to the conditions in the environment. A narrower definition just refers to Self-adaptive Software (Systems). When using the term Self-adaptive System in this work, the second, more specific meaning of Self- adaptive Software System is addressed. However, often these terms are used interchangeably [76,229,278]. The literature provides several definitions of SASs. The following gives a comparison of definitions in order to show the evolution and variety of SASs. Additionally, it presents the system model of such systems. One of the first definitions of SASs is presented by Laddaga in a DARPA Broad Agency Announcement on SASs in 1997 and became later the first commonly agreed definition:
Self Adaptive Software evaluates its own behavior and changes behav- ior when the evaluation indicates that it is not accomplishing what the software is intended to do, or when better functionality or performance is possible. [233, p. 17]
2.2. Self-adaptive Systems
Two years later, Oreizy et al. define SASs in a similar way:
Self-adaptive software modifies its own behavior in response to changes in its operating environment. By operating environment, we mean anything observable by the software system, such as end-user in- put, external hardware devices and sensors, or program instrumen- tation. [278, p. 55]
In contrast to Laddaga, Oreizy et al. include user input explicitly as change reason. In 2009, Salehie et al. summarize the core of SASs to be as follows:
The key point in self-adaptive software is that its life-cycle should not be stopped after its development and initial set up. This cycle should be continued in an appropriate form after installation in order to eval- uate the system and respond to changes at all time. Such a closed-loop deals with different changes in user requirements, configuration, secu- rity, and a number of other issues. [320, p. 4]
This way, the authors point out the importance of the capability of a SAS to make and implement decisions at runtime without an interruption of the system. Hence, the capability to improve the system at runtime in regard to unfore- seen events becomes an important characteristic. The participants of the first Dagstuhl seminar on Software Engineering for Self-adaptive Systems agreed on the following, quite generic definition:
[Self-adaptive systems] are able to adjust their behaviour in response to their perception of the environment and the system itself. [76, p. 1] Additionally, the participants of the Dagstuhl seminar clarified the term self :
The "self" prefix indicates that the systems decide autonomously (i.e., without or with minimal interference) how to adapt or organize to accommodate changes in their contexts and environments. [56, p. 49] In contrast to this non-specific view, a recent definition from a Dagstuhl sem- inar on verification in SASs focuses on the triggers for adaptation:
Self-adaptive software systems adapt to changes in the environment, in the system itself, in their requirements, or in their business objec- tives. [328, p. 1]
2.2. Self-adaptive Systems
The collection of definitions is not exhaustive but shows that the perception
of SAS in literature varies in the details of what triggers adaptation. First,
definitions as the one from Oreizy et al. [278] focus on changes in the environment. This is for the understanding of SASs in this thesis not enough, as changes in the system itself – leading to self-healing – are not included. Hence, to distinguish from context-aware systems, this thesis includes changes in the system. Second, some authors as [328] detail the elements that might be changed. However, this might be too narrow. Further, different understandings of these elements might limit the applicability of the definitions, e.g., for the definition of [328] it is not clear, whether the user is responsible for the change in business objectives or it is part of the environment. In contrast, the third category of definitions is rather generic regarding the adaptation reasons. Additionally, the third category shifts from self-adaptive software systems to self-adaptive systems, which highlights the fact that these systems not only adapt software but also hardware resources. Hence, this thesis follows the definition of the first Dagstuhl seminar:
[Self-adaptive systems] are able to adjust their behaviour in response to their perception of the environment and the system itself. The "self" prefix indicates that the systems decide autonomously (i.e., without or with minimal interference) how to adapt or organize to accommodate changes in their contexts and environments. ( [76, p. 1]; [56, p. 49])
From an architectural point of view, a SAS is composed of two parts: a manag- ing system as well as a managed system [76, 96, 328]. For both elements, different terms are present in literature. The managed system is often denoted as man- aged resources (e.g., [229]), managed elements (e.g., [198]), adaptable subsystem (e.g., [327]), or system under observation and control (e.g., [361]). In this thesis, we use the term managed resources. The managed resources are a set of re-
sources M R = {mr1, ..., mrn } with mri as any kind of software and hardware,
e.g., servers, laptops, smart phones, robots, or unmanned vehicles. In litera- ture, the terms control mechanism (e.g., [327]), observer/controller (e.g., [361]), adaptation logic (e.g., [229]), autonomic manager (e.g., [198]), or adaptation con- trol (e.g., [167]) are used interchangeably for the managing system. This thesis
uses the term adaptation logic. The adaptation logic AL = {al1, ..., aln} is
a set of software modules ali that observes the environment and the managed
resources, analyzes the need for adaptation, plans such adaptations as well as
2.2. Self-adaptive Systems
Adaptation Logic
Managed Resources
Figure 2.3.: System model of a SAS from an architectural point of view (adapted version: in contrast to [328], the adaptation effects the environment).
controls the execution of the adaptation. Hence, the common SAS is defined as
a tuple SAS = (AL, M R) with the adaptation logic AL and the managed
resources MR [229]. Figure 2.3 shows the architectural model of a SAS.
Our survey [229] showed that most approaches do not sufficiently include con- text. Whereas most approaches monitor the context, explicit adaptation of con- text is often not included and the environment remains uncontrollable for the adaptation logic [11]. This can lead to undesired adaptation results especially in system domains with mobile systems. Therefore, this thesis uses the concept of context-altering SAS as proposed in [229]. The context-altering SAS does not just (accidentally) affect the environment, but it deliberately adapts it through mod- eling context and context-altering capabilities as a construct to enables reasoning
about it1. This extends the SAS to a triple SAS = (AL, M R, Ctx) with the
adaptation logic AL, the managed resources MR, and the context Ctx. Different context variables – e.g., temperature, noise, location, or available devices – define the physical context [329]. Additionally, users, social interactions, or their task define the user context [329]. They are influenced via actuators of the managed
resources. Therefore, the context is modeled as set Ctx = {ctx1, ..., ctxn} where
each ctxi symbolizes a context variable, e.g., the temperature.