Research Challenges in SAS

The domain of SAS provides numerous challenges still to be faced in research. Therefore, this section lists specific challenges for SAS in the domain of mobile de- vices, which are addressed in the remainder of this thesis. The scope of this thesis is restricted by the introduction of certain limitations and assumptions. Therefore, the Research Challenges (RCs) of (i) a systematic engineering, (ii) flexibility at runtime, (iii) autonomy, and (iv) intrusiveness are introduced in the following.

RC1: Systematic Engineering.

“A major challenge [. . . in the development of adaptation mecha- nisms . . . ] is to accommodate a systematic engineering approach that integrates control-loop approaches with decentralized agent inspired approaches.” [CLG+_09]

This quotation highlights the importance of a systematic engineering approach for SAS. This implies a consistent development methodology from requirement engineering, e.g., goal modelling, over an a-priori specification of the common knowledge basis, e.g., policies to describe the adaptation behavior, to the con- tinuous update and extension of this knowledge at runtime. Since the usage of a feedback loop, i.e., MAPE-K, is state of the art to control SAS, a systematic engineering approach has to be integratable into such a loop. Although this quo- tation highlights the importance of a decentralized applicability, this issue is not addressed further in the remainder of this thesis.

I ntr od uction F und

ament RC2: Flexibility at Runtime. To cope with the dynamically changing contexts, an adaptation is specified explicitly or implicitly. In an explicit speci- fication all adaptation possibilities are assumed to be known and integrated into the knowledge model. For example, an explicit specification covers all contextual situations depicted in Figure 2.2. Therefore, a mobile device is capable to adapt to all these contextual situations. However, if a new contextual situation emerges at runtime, e.g., entering an airplane or combining two existing contexts such as home and couch, the mobile device is not able to adapt to this context on its own. In contrast, an implicit specification is an incomplete specification and intends to cover a basic set of contextual situations with the ability to extend and update the knowledge at runtime. For example, the contextual situations home and couch are specified individually. If the specification is implicit, the mobile device is able to adapt to a combination of both situations either completely autonomous or with the assistance of the user. Hence, such a specification is more flexible and open to new contextual situations, emerging at runtime. However, the result of such an adaptation that is derived on-demand at runtime is not always predictable. An important research issue is to provide certain flexibility within the adaptation process to cope with unknown contextual situations [BMSG+_{09]. At the same}

time an adaptation has to be reliable and foreseeable [ALMW09], i.e., such that an adaptation exposes always the same behavior.

RC3: Autonomous Adaptation. An autonomous adaptation implies a process without any interaction with external actors, e.g., a user or developer. Therefore, the adaptation process has to evaluate the context and derive neces- sary adaptation strategies on its own [SSH06]. Especially for mobile devices the user experience is of importance. Hence, an adaptation of a mobile device should not bother the user. The adaptation has to be executed automatically and should be transparent to the user [Har06].

RC4: Non-intrusive Adaptation.

“In highly dynamic systems, e.g., mobile systems, where the envi- ronmental parameters change frequently, the overhead of adaptation due to frequent changes in the system could be so high that the sys- tem ends up in thrashing. [However, . . . ] responsiveness is a crucial property in real-time software systems [. . . ]" [CLG+_09]

This quotation refers to the effects an adaptation process imposes on the system. The more resources are utilized within any of the MAPE-K tasks, the more likely the system starts thrashing up to the point of a complete system failure. Although these effects are mitigated by scaling the hardware resources of the system, e.g., more memory, bigger CPU, etc., such a solution is either costly or infeasible. Es- pecially mobile devices are constrained in their resources, i.e., the battery will be drained eventually. Thus, SAS for mobile devices have to operate resource-effi- cient to cope with the high frequency of dynamic contextual changes.

RC5: Predictability of Adaptations. A prediction of contextual changes may be used to optimize the adaptation process, e.g, by pre-computing an adap-

&

als

tation or by harmonizing a sequence of adaptations. However, a prediction of an adaptation or a sequence of adaptations for a mobile device is complicated due to the broad spectrum of contextual situations and the spontaneous, unforeseeable behavior of a user [MSRJ12].

Limitations and Assumptions. In the remainder of this thesis I address the research challenges RC1 to RC5 with a specific focus on the plan task based on a common knowledge model. Note that the approach is designed to operate on resource constrained devices, i.e., mobile devices. In this regard, I neglect details about the monitoring, analyze, and execute tasks of MAPE-K but assume them as a provided black-box, which is accessible to retrieve certain information or execute certain tasks. Hence, I also do not explicitly address intersecting topics, e.g., con- text reasoning, dynamic class loading, feedback evaluation, and information correlation.

Mobile devices are heterogeneous in their characteristics, e.g., one device sup- ports LTE whereas another device does not. To handle such heterogeneity in a systematic manner, software product lines are used. The next section introduces the domain of software product line engineering. Furthermore, an extension of software product line engineering is introduced that focuses on the systematic management of runtime adaptations.