Requirements for Self-improvement at Runtime

plementation support in form of a reference architecture (cf. requirement RDev2)

and reusable implementation artifacts (cf. research question RQ1 ) with runtime support for self-improvement (cf. research question RQ2 ) through a well-defined

development process and development tools (requirement RDev7).

5.3. Requirements for Self-improvement at Runtime

As demanded by research question RQ2 and RQ3, the FESAS Frame- work should be complemented by an approach for self-improvement, i.e., meta- adaptation of the adaptation logic at runtime. On the one hand, this approach should be integrated with the FESAS Framework. On the other hand, to not lim- iting its reusability, it should be self-contained so that it can be integrated with other frameworks for developing SASs. As the self-improvement logic is a ded- icated reusable element, this thesis presents the approach for self-improvement separated from the FESAS Framework, however, the reader should always keep in mind that both are an integrated system to support the whole lifecycle of SASs. Based on the shortcomings we identified in [226] and [227] (cf. Section 4.3), we define the following requirements for an approach that enables self-improvement within SASs:

RSI1: Meta-adaptation mechanisms As reasoning for meta-adaptation seems

to be application-specific (cf. [226, 227]), the approach (i) should support modules for parametric and structural self-improvement and (ii) modules must be exchangeable.

RSI2: External control Implementation may not be intertwined with the adap-

tation logic and, therefore, supports different types of adaptation logics. RSI3: Monitoring Generic monitoring mechanisms should support developers.

RSI4: Proactive reasoning The approach should offer generic prediction pro-

cedures which can be easily integrated into specific reasoning modules. RSI5: Flexible control The approach requires to support centralized, decentral-

ized, and hybrid control structures for self-improvement.

RSI6: Integration To offer a generic and reusable approach for integrating the

5.3. Requirements for Self-improvement at Runtime

In the following, we describe these requirements in detail. Self-improvement through meta-adaptation of the adaptation logic can have various characteris- tics. In general, adaptation mechanisms are divided in (i) parameter adaptation, (ii) context adaptation, or (iii) structural adaptation (including the exchange of algorithms) [229, 254]. However, as we focus on adapting the adaptation logic, we neglect context adaptation here. The choice of the meta-adaptation tech- nique depends on specific objectives, the meta-adaptation should address. As we showed in Section 4.3, the reason for self-improvement is application-specific. In accordance, Gui et al. identified that most adaptation frameworks do not provide clearly defined modules for adaptation reasoning [161]. Further, the im- plementation of meta-adaptation mechanisms may be application-specific, too.

Requirement RSI1.i claims to support different self-improvement mechanisms.

Therefore, the system has also to support exchangeability of self-improvement

modules for specific applications (requirement RSI1.ii).

The control for self-improvement can be (i) intertwined with the system – here: the adaptation logic – or (ii) implemented in external elements. [342, 401] de- scribe trade-offs of an additional layer for self-improvement: increased execution time, complexity, risk of failure, and better control. In a layered approach for self-improvement, this means the reaction time for self-improvement is higher in contrast to the one for normal self-adaptation of the adaptation logic. The adaptation logic can still react to problems in the managed resources and adapt them, however, these adaptations might be non-optimal. Further, the changes performed by the self-improvement layer are more substantial. Consequently, the increased reaction time for self-improvement resulting from the layered ap- proach can be neglected. The complexity might be increased with an additional layer as further interactions are necessary. This is definitely a shortcoming which also introduces a higher risk of failure. The alternative would be an internal approach: The integration of the self-improvement functionality into the (dis- tributed) adaptation logic of a SAS. In [128], the authors showed that an external approach offers a better maintainability. Further, [342] states that an external approach improves implementation control. Last, the additional layer offers gen-

eral applicability supporting requirement RSI1 for exchangeability of elements

that demands this flexibility. Therefore, requirement RSI2 claims an external

approach for the control instance for self-improvement.

5.3. Requirements for Self-improvement at Runtime

The self-improvement approach has to provide mechanisms to monitor meta-

adaptation triggers (requirement RSI3), such as failures in the resources or con-

text changes [229]. As we discussed in [226], those triggers for self-improvement are the context of the system, the managed resources, or the user(s), i.e., changing goals. For example, concept drift – i.e., a substantial change over time of the sta- tistical properties of the relevant variables – can make the model in the adaptation logic obsolete and, in this case, analysis for triggers delivers faulty results. Addi- tionally, triggers can change over time. Hence, proactive analysis of data – which

can recognize concept drift – must be supported (requirement RSI4). Further,

proactive reasoning enables proactive meta-adaptation and can reduce delays as meta-adaptation can happen faster than reactive meta-adaptation [229]. How- ever, the support of reactive meta-adaptation as back-up mechanism if proactive meta-adaptation fails – e.g., a situation was wrongly predicted – is still necessary. Control within an adaptation logic can be decentralized, hybrid, or central- ized [401]. A decentralized approach benefits from higher robustness but intro- duces coordination overhead. A centralized approach reduces coordination over- head at the cost of having a potential performance bottleneck and single point of failure. Our analysis in [226] showed that most approaches for self-improvement are centralized. Centralization simplifies to have a global view on the system, which is necessary for self-improvement. However, interaction patterns such as the ones presented by Weyns et al. [401] can be applied to the adaptation control for self-improvement. Decentralized settings may perform faster meta-adaptation decisions in large systems. Consequently, approaches for self-improvement should

support centralized and decentralized coordination patterns (requirement RSI5).

The approaches analyzed in Chapter 4 offer either development support for SASs or for self-improvement. Except FUSION [112] and EUREMA [377, 380], none of them offer an integrated approach. We claim that this is necessary for accessing the full potential. Accordingly, the ALM should be integrated with the development approach for the adaptation logic to offer a continuous workflow for developers. Further, this increases reusability as approaches or algorithms for self-adaptation might be reused for self-improvement. Supporting research

question RQ3, requirement RSI6 demands an end-to-end development support

for integrating the development of the adaptation logic with the logic for self- improvement.

6. A Framework for Engineering Reusable and