skip to main content
research-article
Open Access

REACT-ION: A Model-based Runtime Environment for Situation-aware Adaptations

Published:20 December 2021Publication History

Skip Abstract Section

Abstract

Trends such as the Internet of Things lead to a growing number of networked devices and to a variety of communication systems. Adding self-adaptive capabilities to these communication systems is one approach to reducing administrative effort and coping with changing execution contexts. Existing frameworks can help reducing development effort but are neither tailored toward the use in communication systems nor easily usable without knowledge in self-adaptive systems development. Accordingly, in previous work, we proposed REACT, a reusable, model-based runtime environment to complement communication systems with adaptive behavior. REACT addresses heterogeneity and distribution aspects of such systems and reduces development effort. In this article, we propose REACT-ION—an extension of REACT for situation awareness. REACT-ION offers a context management module that is able to acquire, store, disseminate, and reason on context data. The context management module is the basis for (i) proactive adaptation with REACT-ION and (ii) self-improvement of the underlying feedback loop. REACT-ION can be used to optimize adaptation decisions at runtime based on the current situation. Therefore, it can cope with uncertainty and situations that were not foreseeable at design time. We show and evaluate in two case studies how REACT-ION’s situation awareness enables proactive adaptation and self-improvement.

Skip 1INTRODUCTION Section

1 INTRODUCTION

With increasing network sizes, mobility, and traffic, it becomes a challenging task to achieve goals such as continuously delivering a satisfying service quality. Self-adaptive approaches adapt a system at runtime according to changes in the execution context [61]. A self-adaptive system consists of the managed target system and an adaptation logic managing the target system. Adding self-adaptive capabilities to communication systems—computer networks as well as supporting structures such as overlays or middleware—is a major research focus. For instance, self-adaptive applications in the software-defined networking (SDN) domain can help to reduce management effort and improve the network’s performance [21]. SDN provides possibilities to monitor and reconfigure a network by specifying selectors for packets and corresponding actions. An adaptation logic may use these capabilities for reconfiguring the packet flows at runtime.

Making such communication systems self-adaptive, however, is a challenging task for domain experts, i.e., communication systems developers. First, the distributed nature of those systems requires the collection of monitoring information from multiple hosts and the adaptation of distributed components. Second, communication systems consist of heterogeneous components, e.g., developed in different programming languages. Third, domain experts typically lack knowledge about the development of self-adaptive systems.

Instead of manually integrating self-adaptivity, the domain expert may rely on frameworks or tools. While approaches such as Rainbow [36], SASSY [54], or MUSIC [38] are suitable for the general purpose of engineering self-adaptive systems, they are neither tailored to communication systems, nor support the domain expert adequately in these use cases. To the best of our knowledge, no existing approach supports multiple programming languages, enables decentralized adaptation logics with distributed deployments, and is available as an easy-to-use open source project for domain experts.

Motivated by these observations, we proposed REACT, a Runtime Environment for Adapting Communication SysTems1 in Reference [67] and applied it in a demo case in Reference [66]. REACT supports domain experts in specifying adaptation behavior in a model-based fashion with Clafer [8] and UML. By implementing language-independent interfaces and selecting deployment options, REACT connects to the target system and automatically deploys its integrated feedback loop. Thus, it is applicable to legacy systems as well. REACT is lightweight and easy-to-use while satisfying the specific requirements of adaptive communication systems. To bridge the prevailing gap between self-adaptive systems research and practice [25, 90], we implemented REACT and made it available as an open source project.2

In this article, we present REACT-ION—an extension of REACT that additionally integrates features for providing situation awareness [28] as demanded for self-adaptive systems in Reference [33]. Situation awareness is “the perception of the elements in the environment within a volume of time and space, the comprehension of their meaning, and the projection of their status in the near future” [28]. The core of REACT-ION is a context management module that is able to acquire context data, store it in a context model, and perform reasoning on the data. These features cover the perception aspect of situation awareness. In addition to its internal context reasoning capabilities, REACT-ION is able to disseminate context information to (external) components, which may reason on the data as well. Therefore, REACT-ION provides two options for the comprehension part of situation awareness. As far as projection is concerned, we show in this article how REACT-ION can be used for proactive adaptation. Proactive adaptation typically requires forecasts, i.e., projections of the status in the future. In addition, we use REACT-ION to adapt the underlying adaptation logic (known as self-improvement [48]) to tackle uncertainty [31]. More precisely, we show how it is possible with REACT-ION to make a situation-dependent choice of the feedback loop that is applied for an adaptation.

The remainder of this article is structured as follows. Section 2 reviews related work. Section 3 briefly outlines REACT’s architecture. This section also introduces how REACT’s implementation supports self-adaptivity. Section 4 proposes REACT-ION. It first presents the concept of situation awareness in more detail. Based on this concept, the section describes REACT-ION’s context management module. This includes improved interfaces enabling external systems outside of REACT-ION to use the context information for situation awareness. The section further describes how REACT-ION can be used for proactive adaptation and for self-improvement of adaptation logics. Section 5 first presents a comparative evaluation of REACT and Rainbow. Then, it describes experiments that evaluate REACT-ION and its capabilities for proactive adaptation and self-improvement. Finally, Section 6 summarizes our findings and outlines future work.

Skip 2RELATED WORK Section

2 RELATED WORK

In this section, we review related work. In Section 2.1, we present approaches related to REACT, i.e., frameworks for engineering self-adaptive systems. In Section 2.2, we summarize approaches to situation awareness in self-adaptive systems. These are approaches particularly related to REACT-ION—the extension to REACT presented in this article.

2.1 Engineering Self-adaptive Systems

Engineering of self-adaptive systems is a prominent research area with a large body of excellent related work that we can build upon. We review the research landscape in Reference [49]. Several related approaches perform adaptations based on architectural models (e.g., References [32, 61, 78]) or specify architecture definition languages for self-adaptive systems (e.g., References [23, 27, 51]). Model-based engineering approaches such as [11, 34, 59, 68] often use Dynamic Software Product Lines (DSPLs) with feature models. The [email protected] research proposes to use runtime models that represent the system and environment for reasoning [9, 14]. All of the aforementioned approaches, however, do not offer an implementation explicitly designed to be used by others. Since we design an approach that aims at high applicability for practitioners and fellow researchers, we focus on implementation aspects of related work in the remainder of this section, as summarized in Table 1.

Table 1.

Table 1. Overview of Related Approaches (Depl. = Deployment, Dev. = Development, Eng. = Engine, Eval. = Evaluation, ex. = existing, Sup. = Support)

First, an approach that optimally assists domain experts should support all self-* properties [45]—self-configuration, self-optimization, self-healing, and self-protection—to be suitable for various use cases in communication systems. Second, the integration of a ready-to-use adaptation decision engine, which adapts the communication system based on models, goals, or utilities makes the approach useful for domain experts without extensive knowledge about self-adaptive systems. Third, the support for existing systems is essential to integrate self-adaptivity into legacy systems. Fourth, a use case independent approach is applicable to a wide range of communication systems. We observe that multiple approaches fulfill these requirements. However, FESAS [47] and HAFLoop [94], for instance, provide excellent support with reusable MAPE components, but do not integrate a decision engine.

We aim to support the domain expert during the development process. In this regard, approaches that support multiple programming languages (e.g., Reference [52]) are easier to use. A vast majority of approaches relies on particular programming languages only, with Java being the most frequently used language. In addition, predefined interfaces as introduced by the prominent Rainbow [36] framework allow for connecting the target system easily to the adaptation logic, which is especially important for legacy systems. Rainbow, however, belongs to the approaches [19, 20, 36, 54, 80] that do not specify an easy-to-follow development process.

We argue that an approach that is suitable for large and heterogeneous communication systems must support decentralized control with multiple feedback loops [92]. This typically also encompasses that one feedback loop itself can be separated into several distinct components that may run distributed. Most existing approaches are designed for centralized feedback loops only. As a running system might change over time in an unexpected way, it is helpful to adjust the behavior manually, apply self-improvement [48], or change the deployment at runtime. This is true for communication systems in particular, where, e.g., new components or subsystems may join or leave the system at any time. In several related approaches [5, 19, 20, 36, 69, 79], the influence of the developer already ends with the design process.

Ideally, the source code of the implementation is publicly available and well documented. This helps to foster further research and enables adoption by domain experts in practice. Only a small subset of existing approaches [5, 36, 47, 79, 91, 94] is available at present. Moreover, a comparative evaluation with other approaches highlights the merits of the particular approach and gives users guidance to select the proper approach for their respective communication system. Here, only Rainbow [36] and Zanshin [79] have been compared in Reference [3].

Accordingly, in Reference [67], we proposed REACT, a reusable runtime environment for model-based adaptations in communication systems. REACT contributes to the state of the art thanks to its focus on communication systems and domain expert support. None of the existing approaches offers multi-language support, enables decentralized control as well as distributed deployments, and is available as an open source project. We made the source code of REACT’s implementation available and compared it with Rainbow. A summary of the comparison is provided in Section 5.

2.2 Situation Awareness

This section briefly summarizes research related to REACT-ION—the extension to REACT introduced in this article. It presents approaches on (i) context awareness, (ii) proactive and history-aware adaptation, and (iii) self-improvement and hybrid planning. We focus on implemented approaches excluding general architectures or methodologies.

2.2.1 Context Awareness.

Context is “any information that can be used to characterize the situation of an entity” [1, p. 304]. The interested reader is referred to References [39, 50] for an overview of context-aware systems in general. Particularly relevant for REACT-ION is context management, i.e. the acquisition, modeling, reasoning, and dissemination of context [65]. Prominent approaches such as Aura [37], CARISMA [18], Gaia [71], or PROACTIVE [85] illustrate that context management is a major research focus in the pervasive and context-aware computing domain.

As far as self-adaptive systems are concerned, context awareness and, hence, context management are mostly covered implicitly. Being aware of the context, including the state of the environment and the system itself, is considered as a fundamental property of a self-adaptive system [74]. Context data is often collected via sensor interfaces, e.g., in References [36, 38, 47, 79]. The approach by Fredericks et al. [33] is an example where context is considered explicitly. The approach plans adaptations in the large state space of possible contexts using optimization. At runtime, specific situations are identified and used for finding optimal system configurations with clustering techniques. The authors apply the approach successfully in a real-world navigation scenario. In Reference [44], Képes et al. propose a system for modeling the context of software updates in cyber-physical systems. Based on the context, a situation-aware choice of the optimal time for updates is made. Nakahara et al. [60] propose CoSMOS, an approach for self-adaptive offloading decisions. In their system, the offloading strategy of applications is adapted at runtime based on the context.

2.2.2 Proactive and History-Aware Adaptation.

In this article, we show how REACT-ION’s context management module can be used to perform proactive adaptation (cf. Section 4.2). Related to this, the PROACTIVE project [85] presents an approach for handling proactive system configurations in pervasive computing systems. A constraint satisfaction problem is solved that takes different application requirements into account. In Reference [16], Cámara et al. propose a formal model and algorithm that considers the time required for an adaptation—such as booting an additional server in a cloud scenario—for proactive adaptation. As an extension, Moreno et al. [55] also consider uncertainty and use model checking at runtime for making adaptation decisions. They apply a Markov Decision Process (MDP). One drawback is that the MDP has to be constructed for each adaptation decision. Consequently, in Reference [56], the authors move a large portion of the MDP construction to the offline phase for increasing the adaptation speed. In Reference [77], Shin et al. propose PASTA—a proactive adaptation approach that uses statistical model checking. The approach tackles state explosion by providing an algorithm, a reference architecture, and an open-source implementation.

Closely related to proactive adaptation, history-aware adaptation describes approaches that are time-aware and include time series modeling for reasoning about the next adaptation [73, 84]. In Reference [35], García-Domínguez et al. argue that model-based approaches often use model evolution for integrating changes at runtime. The authors propose an extension of a model query language to keep track of model changes in a scalable way and to annotate “situations of interest” [35]. This enables to easily query the system specifically for annotated situations and can be considered as an indexing approach. Additionally, the approach takes specific model evolution steps into account for determining “time-aware patterns” [35]. A time-aware pattern happens, e.g., if a hierarchical model node does not have children at one time stamp and has some children at another. Accordingly, the system enables to directly query such situations. Comparably, in Reference [73], Sakizloglou et al. propose a (memory-efficient) querying scheme for model history. Their approach has the advantage of enhancing a runtime model with history-aware capabilities and has a strong focus on scalability by including pruning strategies.

2.2.3 Self-Improvement and Hybrid Planning.

Self-improvement is the “adjustment of the adaptation logic to handle former unknown circumstances or changes” [48, p. 2] in the environment or the target system. We review self-improvement approaches in Reference [48]. ActivFORMS [91] follows the Three-layer Architecture(3LA) proposed by Kramer and Magee in Reference [46]. The architecture includes an additional goal management layer that adapts the adaptation logic. Hence, the goal management layer represents the self-improvement mechanism. PLASMA [81] uses two models that capture the possible system states and the architecture of the target system. It also uses a specific layer for generating new plans in the case of changing high-level goals or failing components. FUSION [30] is a utility-based approach that adapts the knowledge base of the adaptation logic. The FESAS Adaptation Logic Manager (ALM) [72] encompasses an additional MAPE-K-based layer on top of an adaptation logic. This additional feedback loop performs self-improvement of the underlying adaptation logic.

In this article, we use REACT-ION for hybrid planning. Hybrid planning describes a form of self-improvement where the feedback loop for adaptation is chosen at runtime (among several alternatives). In References [62, 63], Pandey et al. specifically define the hybrid planning problem and investigate multiple planning alternatives for balancing adaptation quality and adaptation speed. EUREMA [88] proposes a model-based engineering approach for specifying adaptation logics. Additional trigger conditions can be used at runtime to select the feedback loop that should be executed. In Reference [43], the authors propose a reinforcement learning-based approach for improving the decision-making system of a robot, which is similar to hybrid planning. HAFLoop [94] extends FESAS [47] with the explicit option to adapt the adaptation logic component’s parameters and structure in a reusable way. This also permits having multiple parallel adaptation logic components and restructuring them at runtime according to changing contexts and system goals.

Skip 3REACT: A Reusable Runtime Environment for Adaptive Communication Systems Section

3 REACT: A Reusable Runtime Environment for Adaptive Communication Systems

We briefly introduce REACT’s architecture and internal feedback loop based on Reference [67] in this section, before we present REACT-ION—the extension for situation awareness—in Section 4.

3.1 REACT’s Architecture

In contrast to self-adaptation frameworks that offer a standard way to build self-adaptive applications, we refer to REACT as a runtime environment, i.e., a platform that is additionally able to plan and execute adaptations based on user-specified adaptation behavior. REACT includes a feedback loop as well as interfaces for connecting target systems. Potential target systems in the communication systems domain are overlay networks such as peer-to-peer systems and underlay networks, e.g., in SDN scenarios. However, REACT could possibly be used in other application domains as well. The feedback loop follows the MAPE-K architecture that consists of components for (i) Monitoring the system and the environment, (ii) Analyzing the monitored data for necessary adaptations, (iii) Planning the adaptations, and (iv) Executing the adaptations in the target system as well as (v) a shared Knowledge base [45]. The feedback loop uses information stored in the knowledge for reasoning. It receives sensor information from the communication system as an input and determines the required adaptations as an output via interfaces. Figure 1 shows REACT’s architecture on top of a communication system using a UML-like notation. The MAPE components and the knowledge service are generic internal parts of REACT and are independent from the use case. These gray parts in Figure 1 are encapsulated in a ready-to-use fashion and do not require any programming effort from the domain expert. The white boxes represent the specifications and the effector implementation that have to be provided by the domain expert.

Fig. 1.

Fig. 1. REACT’s architecture in a UML-like notation. It consists of one or multiple MAPE feedback loop(s) connected to instance(s) of the knowledge service with the adaptation options specification and target system specification provided by the domain expert. REACT’s reusable feedback loop uses the adaptation options specification to solve the current adaptation problem and maps it to the target system with the target system specification. The target system connects to REACT via well-defined sensor and effector interfaces.

As models provide a sufficient level of expressiveness while being easy to use for domain experts, we selected a model-based approach for REACT’s feedback loop. By creating the models at design time, the domain expert tailors the feedback loop to the respective use case. Thus, the domain expert is able to integrate self-adaptivity into the target system by only providing the models used as decision criteria. These models are then used by the readily provided internal feedback loop of the runtime environment. REACT requires two models:

(1) The adaptation options specification is an explicit representation of valid reconfiguration options. It thus describes the problem space with a structural modeling language, including constraints.

(2) The target system specification models the architecture of the target system, i.e., the solution space. After solving a problem in the problem space, REACT maps the result to the solution space according to the target system specification.

With these two models, REACT is able to perform architectural as well as parametric adaptation [53]. The separation of the two models decouples the specification of the reconfiguration behavior from the target system and its architecture. REACT uses the live sensor data provided by the communication system together with the adaptation options specification to adapt the system to the desired target state. REACT’s internal MAPE components themselves are reusable, since they are working with arbitrary adaptation options specifications and target system specifications.

To connect to the underlying communication system, REACT provides programming language independent sensor and effector interfaces (ISensor and IEffector). The sensor receives live context information from different parts of the communication system and forwards it to the feedback loop. The effector transfers the result of the feedback loop to the respective part of the communication system. The exposed IKnowledgeService interface can be used by domain experts to update the specifications stored in a knowledge service instance at runtime. This may be necessary due to two reasons. First, complexity and uncertainty may lead to situations that were not foreseeable at design time [83]. Second, environmental changes may necessitate model changes. The IKnowledgeService interface thus allows, for instance, REACT to be connected to a self-improvement [48] module that continuously learns and improves the models. Multiple instances of the MAPE-K components and the sensor can be distributed on different machines, as the communication between the components is handled by REACT. Thus, this enables high scalability and allows distributed deployments and decentralized control. Fully decentralized or hybrid patterns, as described in Reference [92], are realizable.

3.2 Enabling Self-adaptivity with REACT

In this section, we summarize the implementation of REACT and how it achieves self-adaptivity. First, we describe how domain experts use a model-based specification approach for self-adaptation with REACT. Second, we explain REACT’s integrated feedback loop that leverages the model-based specification without human intervention. Third, we show how REACT makes decentralized control, distributed deployment, and changes at runtime possible.

3.2.1 Modeling.

An essential part of REACT are the models of the adaptation behavior (adaptation options specification) and of the target system (target system specification). The domain expert provides these models at design time and may update them at runtime. REACT uses the models at runtime to adapt the target system. REACT supports adaptation options specifications in the structural specification language Clafer (CLAss, FEature, Reference) [8]. There are multiple reasons to use Clafer. First, it is a well-established approach applied in different domains [4, 8], which is available as an open source project and extensively documented. Second, Clafer provides lightweight modeling capabilities with just a minimal set of concepts. Thus, Clafer makes modeling accessible to users from different domains without large modeling experience. Third, Clafer provides model verification and validation [7]. By using Clafer, REACT offers the possibility for advanced static analysis as presented in Reference [89]. Thus, we can make sure that no contradictions exist in the Clafer specifications and that each possible sensor input leads to valid adaptation decisions.

A Clafer-based model is created using a single type of element, named Clafer. A Clafer represents a type, an attribute, a relationship, an instance, or a combination of these. Each Clafer has a name and is either top-level or nested under other Clafers. Nesting is expressed using indentation. We illustrate Clafer’s basic modeling capabilities with the following use case from a cloud server management scenario, where a domain expert uses REACT to implement adaptive behavior. Based on the context dimensions (i) number of running servers, (ii) total number of servers, and (iii) average response time, REACT launches additional servers adaptively if required. The launch of an additional server happens if the average response time exceeds a threshold value (here 75) and additional servers are available. Listing 1 shows an exemplary adaptation options specification in Clafer for this use case. Line 1 contains a (top-level) Clafer named ServerLauncher that describes that an additional cloud server should be started. Clafers may have cardinalities, while the default cardinality is 1. By adding 0..1 to Line 1, we specify that model instances are valid with either none or only one ServerLauncher Clafer. Clafers may be abstract. An abstract Clafer “aggregates commonalities” [4] like a class in object-oriented programming. Hence, a Clafer can inherit from an abstract Clafer and use abstract Clafers like a type. The lines 2–5 describe an abstract entity of type Context with integer attributes. A solution of this problem space requires to have exactly one instance of this Clafer with all attributes set. Lines 6 and 7 define the auxiliary Clafers ExtraServers and HighRT that state whether it is possible to start an additional server and whether the response time is high. In addition, a Clafer model may contain constraints in brackets. Lines 8 and 9 specify constraints that set the auxiliary Clafers ExtraServers and HighRT according to the context. Line 10 is the adaptation rule stating that the ServerLauncher Clafer should be present in a model instance if the response time is high and more servers are available.

REACT uses separate models for the adaptation behavior, which is modeled in Clafer, and the target system. Hence, REACT needs a mapping from the problem space to the solution space, which represents the target system. For this purpose, REACT uses the target system specification, which the domain expert provides in UML as class diagrams. In many cases, a UML model of a target system might already exist and be ready to use as a target system specification for REACT. This considerably decreases development effort. In addition, an automated creation of a UML model from source code can also reduce the time for modeling. REACT parses the UML class diagram as an XML file complying with the UML 2 Abstract Syntax Metamodel by the Object Management Group. Due to this standardized format, the domain expert can create the XML file manually or use a graphical editor that offers an export in this format such as Papyrus.3 In the cloud server management example with its adaptation options specification in Listing 1, the simplest UML model only contains a single class named ServerLauncher. An instance of this UML model indicates if the corresponding class should be present in the target system or not.

3.2.2 Integrated Feedback Loop.

The previous section describes the modeling of the adaptation options specification in Clafer and the target system specification in UML. Now, we show how REACT autonomously leverages these use case dependent models to achieve self-adaptivity. Figure 2 shows the behavior of REACT’s integrated MAPE-K feedback loop in the aforementioned cloud server management example. The feedback loop starts as soon as new sensor information is received via the sensor interface in JSON format. In the example, this sensor data ❶ is context information about the cloud system. The received information is handed over to the monitoring component.

Fig. 2.

Fig. 2. An adaptation cycle of REACT for the cloud server management example. The analyzer maps the JSON-based sensor information to the adaptation options specification in Clafer. The planner evaluates the model and finds a valid instance. Here, it adds a ServerLauncher Clafer as starting a new server is desired. The effector maps the plan to the target system specification in UML and transfers the adaptation to the target system.

REACT allows domain experts to choose from multiple integrated monitoring strategies. In the default strategy, the monitor parses the raw JSON data and hands it to the analyzer as a map ❷. REACT offers an aggregation strategy that additionally aggregates information from multiple sensors and a windowing strategy that applies a sliding window approach to the incoming sensor values. An IMonitoringStrategy interface further makes it possible for advanced users to create, share, and integrate custom monitoring strategies.

The analyzer fetches the adaptation options specification ❸ from the knowledge service. It uses the abstract Clafers specified in the adaptation options specification to create concrete Clafers from the monitoring data. To achieve this mapping, the original sensor data contains type attributes. REACT uses these type attributes to map the monitoring data objects to the correct abstract Clafers in the adaptation options specification. In the exemplary case, the type has the value Context and REACT therefore maps it to the Context Clafer in the adaptation options specification ❸. The concrete Clafers are then forwarded to the planning component ❹.

REACT’s planner merges the generated Clafers with the adaptation options specification to the problem specification. The problem specification thus contains the global constraints of the adaptation options specification and the current constraints imposed by the sensor data. Now, REACT solves this problem specification as a constraint-satisfaction problem (CSP) with Chocosolver [70], a Java-based library for constraint programming. Hence, the solver finds a model instance ❺ that satisfies all constraints. In the exemplary case, this model instance would either contain or not contain the ServerLauncher Clafer, which constitutes the adaptation decision.

The planning result in the form of concrete Clafers is then passed to the executor, which maps the Clafers to the target system specification ❻. REACT maps the Clafers by name to the classes or parameters of the UML model and creates a UML instance. In the example, the created ServerLauncher Clafer (note the missing 0..1 cardinality in ❺) is mapped to the class ServerLauncher of the target system specification. REACT transforms the UML instance to a language-independent representation. Finally, the executor passes this representation via the effector interface ❼ to the target system, where adaptations will take place. The integrated feedback loop of REACT works with arbitrary adaptation options specifications and target system specifications and is thus applicable to a wide range of scenarios.

3.2.3 Communication and Deployment.

We showed how REACT makes it possible to build self-adaptive communication systems or integrate self-adaptive behavior into a legacy system while only demanding two models from the domain expert and low programming effort. Another main strength of REACT is its ability to run distributed. To achieve this, REACT’s internal communication interfaces between MAPE components, knowledge service, and sensor/effector interfaces are specified in ZeroC Ice’s Interface Definition Language [41]. Ice is a well-established framework for creating Remote Procedure Call (RPC) bindings to many programming languages. For supporting distribution, runtime change of the deployment, and bootstrapping, REACT’s MAPE-K components and sensors are integrated into OSGi bundles with iPOJO [29]. The domain expert deploys the system with a key-value-based configuration file for each component. REACT’s OSGi runtime then instantiates one component for each available key-value-based configuration file on a host. Thus, domain experts can deploy the feedback loop easily in a distributed way. For setting up the connections to the successor and knowledge component(s), REACT uses Multicast DNS in local networks or a Consul4 registry for automatic setup, or manual IP address and port specifications.

Apart from distributed deployment, REACT further supports changes of the adaptation options specification, the target system specification, and the deployment at runtime. REACT allows to use an RPC at runtime to add models remotely to the knowledge service. Hence, a domain expert can change the self-adaptive behavior without interruptions. The domain expert can also change the deployment or re-locate REACT’s components. After updating the configuration files, REACT’s OSGi containers reconfigure automatically.

Skip 4REACT-ION: Situation Awareness with REACT Section

4 REACT-ION: Situation Awareness with REACT

In this article, we present REACT-ION—an extension for REACT that achieves situation awareness. Situation awareness can be defined as“the perception of the elements in the environment within a volume of time and space, the comprehension of their meaning, and the projection of their status in the near future” [28]. Accordingly, the three levels of situation awareness consist of (i) perception, (ii) comprehension, and (iii) prediction [28]. Situation awareness has already been applied in the ubiquitous and pervasive computing domain, mainly with a focus on the perception and comprehension levels (e.g., see Reference [93]). Fredericks et al. have studied and discussed the usefulness of situation awareness in self-adaptive systems in Reference [33]. REACT-ION supports all three levels of situation awareness. First, it extends REACT with perception by providing a context management module (cf. Section 4.1). As the comprehension of a situation is dependent on the use case and scenario, the context manager is also able to distribute context information for supporting the domain expert to reason about it and integrate arbitrary situation recognition techniques. For addressing the projection, we show how REACT-ION can be used to adapt a target system proactively (cf. Section 4.2). As soon as situations can be determined, this information can be used for adapting the adaptation logic (i.e., self-improvement [48]) to tackle uncertainty [31]. Thus, we exemplarily apply hybrid planning with multiple feedback loops (cf. Section 4.3). This enables the domain expert to choose a feedback loop based on the current situation of the system. As REACT-ION is an optional extension, domain experts are free to disable it for use cases that require a lightweight deployment of REACT.

4.1 Context Management Module

REACT-ION provides a context management module as a foundation for situation awareness. The integration of this context management module has two implications. First, it paves the way toward proactivity as well as self-improvement [48] with REACT, i.e., adapting the adaptation logic. The context manager is able to collect and distribute the context to an external software component such as a machine learning pipeline. This external component may reason on the data to infer the current situation. Based on the situation, the external component is then able to modify the REACT-based system with REACT’s well-integrated options for runtime modification (cf. Section 3.1). Second, context management may accelerate adaptation. If the context has been similar in the past, then REACT-ION may skip the planning process and perform the same adaptation again.

4.1.1 Architecture.

In Reference [65], Perera et al. define the context life cycle, which describes how context information is processed in a context-aware system. The life cycle consists of four phases: acquisition, modeling, reasoning, and dissemination. The acquisition phase describes how the context data is gathered from several sources such as physical or virtual sensors. In the second phase (context modeling), this context data is transformed into a “meaningful” representation, i.e., the context model. This context model “identifies a concrete subset of the context that is realistically attainable [...] and able to be exploited in the execution of the task” [42]. Usually, a context model consists of multiple context attributes that contain an identifier, a type, a value, and optional properties. With the help of the context model, the system performs context reasoning—the third phase of the life cycle. In this phase, the system exploits the context model to gain new knowledge or improve its performance [13]. For instance, a situation-aware system may infer the current situation from the context model and adapt accordingly. In the final phase of the life cycle (dissemination), the system distributes the context information to external components, either initiated by a query or a subscription.

We design REACT-ION’s Context Manager along the four phases of the context life cycle. Thus, the context manager consists of four components with clear responsibilities. These four components are Acquisition, Storage, Reminiscence, and Distribution. They are responsible for context acquisition, modeling, reasoning, and dissemination, respectively. Figure 3 shows the architecture of REACT-ION including the context manager. In the following, we introduce how REACT-ION performs the four phases of the life cycle.

Fig. 3.

Fig. 3. Architecture of REACT-ION including the optional context manager module. The context manager encompasses four components: Acquisition, Storage, Reminiscence, and Distribution. AOS: adaptation options specification, TSS: target system specification.

The context acquisition process starts at REACT-ION’s ISensor interface that receives sensor data from the target system. This data may originate from multiple physical or virtual sensors. As REACT-ION is a generic runtime environment that is applicable to a wide range of use cases, it has to be able to collect context data from diverse sensors. To achieve this, REACT-ION includes the standardized ISensor interface. The data sources connect to REACT-ION via this interface and provide context data in JSON format according to the adaptation options specification (cf. Figure 2 and Section 3.2.2). The analyzer forwards the current context information to the knowledge service. The acquisition component of the context manager is now responsible for receiving the context information from the knowledge service and prepares it for storage in the context model.

The Storage component contains the context model. It covers the second phase of the context life cycle. Approaches for context modeling range from simple key-value pairs over model-based approaches (e.g., Reference [18]) to ontology-based approaches (e.g., Reference [71]). REACT-ION uses a database for context modeling, which allows for fast and simple storage and retrieval of large amounts of context information [65]. In addition to the context information, the database stores the corresponding adaptation decisions of REACT-ION.

As far as the third phase of the context life cycle (reasoning) is concerned, REACT-ION offers two options. First, the internal Reminiscence component is able to decide whether the current context has been sensed in the past. In this case, REACT-ION skips the planning phase of its feedback loop and executes the previously planned adaptation. If a context is unknown, then the context is added to the context model and the loop continues. Accordingly, the executor sends the corresponding target system specification to the knowledge component, which forwards it to the context manager. This enables to use this adaptation in future loop executions that skip the planning phase. The configuration file of the analyzer (cf. Section 3.2.3) allows domain experts to enable or disable this behavior. As slight deviations in a numerical context dimension should be interpreted as a similar context, the Reminiscence component uses absolute thresholds. Only if the new value differs from a previous value by more than this absolute value, it will be considered as a new state. The thresholds are configurable at design time and at runtime. Second, an external component may reason on the context information. For this purpose, REACT-ION is able to disseminate the context information to external components, which is the last phase of the context life cycle.

In REACT-ION, the Distribution component is responsible for context dissemination. This component communicates with external software that, e.g., reasons on the context information to detect the current situation. REACT-ION requires a flexible solution that is applicable in many use cases. Thus, the Distribution component is able to work both subscription- and query-based. It disseminates (new) context information and planned adaptations via a publish/subscribe system. External components may also query the Storage component—and, hence, also the context model—via this publish/subscribe system.

4.1.2 Implementation.

For context acquisition, the context information in form of Clafers created in the analyzer is used as foundation. All Clafers in the adaptation options specification without a corresponding element in the UML-based target system specification represent the context. The Storage component includes a MySQL5 database with one or multiple tables for the context and one table for the adaptations. REACT-ION automatically generates the table structures at the system start based on the adaptation options specification and the target system specification. The adaptation options specification already pre-defines a suitable schema for the SQL-based context table(s) to store the context information. In the example shown in Figure 2, this would lead to a single context table named Context with three integer attributes representing the servers, maxServers, and responseTime attributes as columns. In addition to simple data types, the Clafer language also includes abstract Clafers that describe complex types, similar to classes in object-oriented programming. REACT-ION creates a separate table for each abstract Clafer if such Clafers are part of the context information. The separate tables include a foreign key relation to the main context table. The adaptations table contains an entry for each parameter of all components in the target system specification. A foreign key relation in the adaptations table references the corresponding context in the context table. In the example in Figure 2, the component column of the adaptations table would either be empty or contain the String ServerLauncher.

The Reminiscence component contains a map structure that stores the configurable percentage thresholds for numerical context dimensions. REACT-ION offers an interface to adjust these thresholds at runtime via a method in the IKnowledgeService interface (cf. Section 3.1). This is beneficial in use cases where the frequency of planning should be adjusted at runtime, e.g., to skip the planning phase more often when the computational load for the REACT-based feedback loop is high.

The Distribution component uses the Message Queuing Telemetry Transport (MQTT) protocol to provide a lightweight publish/subscribe solution. The usage of the well-established protocol enables an intuitive communication of external components with REACT-ION’s context management module. We use Eclipse Mosquitto6 for the MQTT broker and Eclipse Paho7 as the Java library for communicating with the broker. If the context distribution is enabled via a method in the IKnowledgeService interface (cf. Section 3.1), then the module connects to an MQTT broker and publishes events. REACT-ION allows domain experts to start a local MQTT broker or to connect to an external one.

The context management module offers a foundation for several sophisticated use cases with REACT-ION. In the following, we investigate two options. First, we show in Section 4.2 how REACT-ION achieves proactive adaptation based on the context management module. Second, we show in Section 4.3 how context-awareness can be used as foundation for self-improvement with REACT-ION.

4.2 Proactive Adaptation with REACT-ION

Self-adaptive systems either perform reactive or proactive adaptation [49]. Traditionally, many self-adaptive systems only adapt after a change in the target system has been detected, which makes them reactive. This has several disadvantages such as slower adaptation to changes, which may—in the worst case—lead to a failing target system. Proactive adaptation aims at avoiding such situations in the first place [39, 49]. In general, for performing proactive adaptation, the system context has to be known [85]. REACT-ION’s context management module covers this requirement. In this section, we show how proactive adaptation can be achieved with REACT-ION.

Proactive adaptation with REACT-ION requires three steps: (i) communicating the context to a prediction system, (ii) predicting future context, and (iii) using the prediction to plan adaptations. In REACT-ION’s context management module, the context is represented as a Clafer-based specification, which is transformed into a context database. Hence, the context management module provides a history of context information in a structured way in its Storage component. In addition, the Distribution component is able to communicate with external prediction and learning systems. Thus, REACT-ION’s context management module is suitable to perform the first step of proactive adaptation.

The choice of the prediction system for step (ii) is highly dependent on the use case. Domain experts are able to easily connect their prediction system of choice to REACT-ION’s context management module via the platform-independent publish/subscribe system. Often, time series forecasting is used for prediction [96]. In Section 5.2, we therefore show how to connect a REACT-based self-adaptive system to the Telescope [95] time series forecasting framework to make context predictions.

REACT-ION offers two options to use the prediction for proactive adaptation in step (iii): an implicit and an explicit approach. For the implicit approach, the prediction system sends the predictions to REACT-ION via the ISensor interface. Instead of the current context information, REACT-ION uses the prediction for the usual planning process. Consequently, REACT-ION adapts the system based on the predicted information instead of the current context, which results in proactive adaptation. This approach leads to minimal effort for domain experts, since adaptation options specification and target system specification do not need to be changed. On the downside, this approach may lead to bad adaptation decisions as it only relies on—possibly inaccurate—predictions. Thus, REACT-ION also offers the explicit approach, where the predicted context is added to the adaptation options specification. In this case, the adaptation decisions are based on both the current context and the predicted context. Even though this approach requires additional modeling overhead, it enables domain experts to influence how the predictions are incorporated into the decision-making process.

4.3 Self-Improvement with REACT-ION

REACT-ION’s context management module enables domain experts to introduce situation awareness to their system. Additionally, REACT-ION offers the option to modify the feedback loop at runtime (cf. Section 3.1). When combining both, domain experts are able to modify the feedback loop based on the current situation, i.e. to apply self-improvement. Self-improvement is important as complexity and uncertainty may lead to situations that were not foreseeable at design time [83]. Examples for such situations include a significant change in the system’s environment or user group (hence, the users’ objectives) or the requirement to add or update adaptation decision rules through learning.

REACT-ION offers three options for self-improvement. First, the adaptation options specification and the target system specification may be adjusted at runtime (cf. Section 3.1) based on the current situation. This leads to a change of the reconfiguration behavior. Second, the deployment of REACT-ION’s MAPE-K components is changeable at runtime (cf. Section 3.2.3). For instance, in high load situations, analyzer and planner may be migrated to separate machines. Third, several MAPE-K loops might exist simultaneously and might be used for different situations. In this section, we show how REACT-ION is able to achieve self-improvement in this case.

In the literature, many approaches for analyzing and planning in self-adaptive systems exist. The approaches differ in their adaptation speed, ease of use, applicability for many use cases, and memory consumption. We propose to combine several reasoning approaches and to choose the suitable feedback loop based on the current situation. The reconfiguration behavior of a REACT-based system is modeled in Clafer and UML. Planning happens by solving a constraint-satisfaction problem (cf. Section 3.2). This approach is easy-to-use for domain experts but may lead to considerable overhead in terms of computational complexity and memory footprint.

We now integrate an alternative reasoning approach into REACT-ION. This approach relies on context feature models (CFMs) [40, 75] for specifying the problem space. A CFM is a hierarchical tree-like model. It specifies the reconfiguration space of a self-adaptive system including the adaptations based on the context. While the left subtree represents the configuration features and attributes of the system, the right subtree represents context features and context attributes. Constraints between both subtrees resemble the reconfiguration behavior. Figure 4 shows a small example CFM of a smartphone reconfiguring its wireless connectivity. In the shown model, the system can turn on the LTE and/or Wifi features for providing the Wireless Connectivity feature. The context includes the current latency of the connection and the location of the phone. The phone can either be Away or at Home. Accordingly, the shown constraints turn Wifi on at home, and off when being away. Finally, if using the Wifi connection results in a higher latency than , then the LTE connection is enforced for decreasing the latency.

Fig. 4.

Fig. 4. Exemplary CFM that represents the reconfiguration space of the wireless connectivity of a smartphone. Depending on the constraints, it determines the selection of LTE or Wifi for providing wireless connectivity.

CFMs can be translated into Boolean satisfiability (SAT) problems or mixed-integer linear programming (MILP) problems [89]. While SAT problems can be solved relatively fast with lower expressiveness, MILP problems can be applied to specifically state integer or real parameters and optimize the results using multi-objective optimization. Figure 5 shows REACT-ION’s architecture with CFM-based reasoning. The knowledge consists of the CFM specified with CardyGAn [76], which models the problem space, and a (UML) class diagram, which models the solution space. In the monitoring step, the sensor data is preprocessed. In the analyzing phase, the right subtree of the CFM—the context—is instantiated. Based on this context information, the planning component transforms the CFM and the context instance to a SAT or MILP problem resulting in a complete system configuration including the system features. Finally, the executing phase creates a class diagram instance of the solution space from the completed CFM. For more information on this feedback loop, the interested reader is referred to Reference [89].

Fig. 5.

Fig. 5. Architecture and functionality of REACT-ION using the CFM-based feedback loop. The knowledge consists of a CFM representing the problem space, a class diagram representing the solution space, and an explicit mapping between both. The boxes attached to the MAPE functionalities show the results of each component [89]. The context manager is omitted here.

Deploying both the Clafer-based feedback loop and the CFM-based loop simultaneously has several advantages. For instance, it might be beneficial to execute the CFM-based reasoning approach with a SAT solver if the target system is in a critical state. While the result might not be optimal, it could be good enough for bringing the system back into a non-critical state as fast as possible. At the same time, a more complex Clafer-based planner could be executed as well, which provides an optimized solution later. Hence, situation awareness enabled by the context management module may improve adaptation decisions at runtime by selecting the suitable feedback loop or by executing multiple loops in parallel. In Section 5.3, we evaluate self-improvement with REACT-ION in a case study in which we use the Clafer-based and the CFM-based feedback loops simultaneously.

Skip 5EVALUATION Section

5 EVALUATION

We evaluate REACT and its extension REACT-ION in three experiments. First, Section 5.1 compares REACT with Rainbow [36]—a well-known and frequently applied framework for model-based adaptation. This section summarizes the essential findings from the evaluation of REACT in Reference [67]. Second, Section 5.2 builds upon the extensions of this article and evaluates proactive adaptations with REACT-ION in a smart grid use case. Third, Section 5.3 outlines the evaluation of applying different feedback loops as part of REACT-ION which enables the system to select feedback loops at runtime for self-improvement. Finally, Section 5.4 discusses potential threats to validity.

5.1 Comparison of REACT and Rainbow

In our first experiment, we compare REACT with the well-known Rainbow framework [36] in terms of development effort, performance, and features.

Rainbow—the baseline approach: The Rainbow framework uses software architectures and a reusable infrastructure to support self-adaptation of software systems, with components implementing each aspect of the MAPE-K loop. Probes are used to extract information from the target system that update the model via gauges, which abstract and aggregate low-level information to detect architecture-relevant events and properties. The adaptation manager, on receiving the adaptation trigger, chooses the “best” adaptation plan—on the basis of stakeholder utility preferences and the current state of the system, as reflected in the models—to execute, and passes it on to the strategy executor, which executes the strategy on the target system via effectors. The underlying decision making model is based on decision theory and utility [24]; varying the utility preferences allows the adaptation engineer to affect which strategy is selected. Each strategy, which is written using the Stitch adaptation language [23], is a multi-step pattern of adaptations in which each step evaluates a set of condition-action pairs and executes an action, namely, a tactic, on the target system with variable execution time. As a framework, Rainbow can be customized to support self-adaptation for a wide variety of system types. Furthermore, the flexibility of the framework has enabled not only the multi-object trade-off selection of strategies among competing objectives that is embodied in Stitch, but has also supported research into online adaptation planning [15], predictive proactive adaptation [57], and human-machine cooperation [17].

SWIM—the use case: We deploy Rainbow and REACT with the SEAMS exemplar SWIM (Simulator for Web Infrastructure and Management) [58], which represents a cloud system. SWIM [58] offers a reproducible way for evaluating adaptation logics in a web server environment. The SWIM exemplar consists of multiple simulated web servers connected to a round-robin load balancer. The load balancer distributes simulated requests and the corresponding server simulates the execution. Each web server response can contain optional content (e.g., advertisements), which increases the response time but also leads to additional revenue for the web site operator. The percentage of the requests with optional content is described as dimmer value. The overall goal of the system is thus continuously reaching a fixed response time goal, while maximizing the revenue with the optional content and minimizing the cost for the servers. Accordingly, there are two ways of adapting the running system: (1) Adding or removing servers, and (2) controlling the number of responses with optional content, represented by the dimmer value.

In this experiment, we compare Rainbow and REACT from the perspective of a domain expert. To provide the best experience for the domain expert, Rainbow and REACT should (i) be usable with low effort, (ii) lead to fast adaptations, and (iii) provide sufficient capabilities to introduce the desired self-adaptive behavior. Thus, we answer three research questions in the following that evaluate the (i) development effort (RQ1.1), (ii) performance (RQ1.2), and (iii) features (RQ1.3) of both Rainbow and REACT.

RQ1.1:

How does REACT compare to the state of the art in terms of development effort?

As far as development effort is concerned, two metrics influence the domain expert’s experience: the source lines of code (SLOC) required to achieve self-adaptivity and the number of different programming languages, tools, and technologies she needs to be familiar with. Both metrics apply to (i) specifying the adaptive behavior and (ii) implementing the interfaces to SWIM.

As shown in Table 2, we observe that specifying the adaptive behavior with REACT requires considerably fewer SLOC. The domain expert has to write 152 SLOC in two files with clear responsibilities. To achieve the same behavior with Rainbow, the domain expert has to write 593 SLOC in six files using various programming/specification languages. Next, we assess the development effort for the interface implementation (cf. Table 3). We measure that REACT requires 200 SLOC and Rainbow requires 204 SLOC. However, REACT requires fewer (configuration) files for setting up the connection. In addition, due to its language-independent interfaces, domain experts can use their preferred language. We acknowledge that SLOC as a metric might have its shortcomings, however, it is frequently applied as a metric to provide an estimation of the development effort (e.g., in References [24, 47, 86]).

Table 2.
RainbowREACT
ArtefactSLOCLanguageArtefactSLOCLanguage
Strategies and tactics113StitchAdaptation options specification123Clafer
Utilities55YAML
Architecture Model261YAMLTarget system specification38XML
128ACME
25DTD
11XML
Total593Total152

Table 2. SLOC Measurements of the Modeling in Rainbow and REACT

Table 3.
RainbowREACT
ArtefactSLOCLanguageArtefactSLOCLanguage
Probes91PerlInterfaces200Python
68YAML
Effectors9Bash
25YAML
Utility Files11Bash
Total204Total200

Table 3. SLOC Measurements of the Interface Implementations of Rainbow and REACT

RQ1.2:

How well does REACT perform compared to the state of the art?

We run the “1998 World Cup Web Site Access Logs” trace provided by SWIM 10 times with REACT and Rainbow. Figure 6 presents the average runtimes per MAPE activity as well as their average sum. REACT considerably outperforms Rainbow in the monitoring and analyzing phase with regards to execution time. The design considerations for Rainbow—to (i) hold an exact architecture model of the target system, (ii) update the model when new sensor data is available, (iii) periodically check for issues including an analysis where the problem is located in the model, and (iv) trigger an adaptation accordingly—allow a more complex analysis of the target system architecture at the cost of slower adaptations. The total execution time of an adaptation cycle in REACT is determined to a very high degree by the planner component. This is not surprising, as the planner executes Chocosolver to find a valid model instance. Clafer itself scales well with increasing problem size even with models of several thousand Clafers [6, p. 84]. In Rainbow, the complex problem analysis in the monitoring and analyzing component accelerates planning. The planner only uses the utility function and expected outcomes for selecting one of the specified strategies instead of running a solver. In total, REACT’s average adaptation cycle execution requires in comparison to in Rainbow. Thus, we argue that REACT is well-applicable in scenarios where fast adaptation is required.

Fig. 6.

Fig. 6. Average run times of the MAPE activities of REACT and Rainbow.

RQ1.3:

How do REACT and Rainbow differ in terms of capabilities?

Rainbow has its strengths in more in-depth analysis using its architecture model and a less complex planning phase as a result. In addition, it is utility-based with the possibility to weight optimization goals, which may considerably reduce a domain expert’s effort in scenarios with multiple goals. REACT, however, offers runtime modifications of the adaptation behavior, decentralized control, and multi-language support. Accordingly, if there is the need for weighted optimization and a central deployment without overly strict timing requirements, Rainbow is a good choice. If there is no need for weighted optimization, and the requirement for decentralized deployments and fast execution, then REACT is a good candidate.

5.2 Proactive Adaptation

In the next experiments, we evaluate REACT-ION. First, we apply proactive adaptation with REACT-ION in a smart grid scenario as prediction and proactive adaptation is an important aspect for situation awareness [28].

The smart grid consists of multiple households that consume power and multiple power sources that produce the same. The goal of the smart grid is to be self-sufficient. If the energy consumers require more power than available, then the required power is taken from the general power lines outside of the smart grid. Analogously, excess power is transferred to the surrounding power lines. A domain expert uses REACT-ION to implement adaptive behavior in the smart grid with two goals. First, the smart grid should activate at least as many power sources as needed to fulfill the current power demand. This is the primary goal. Second, the production of excess power—by activating too many power sources—should be kept at a minimum if possible.

We simulate the scenario with the Python-based smart grid simulator Mosaik.8 The simulation includes 10 households, which consume power based on realistic usage profiles. Additionally, 40 power sources produce power. Immediately after activating the power sources, they produce power at a constant rate. Each simulation run simulates a time period of two weeks in steps of 15 min. We execute 30 runs with different household power profiles, each once with reactive adaptation and once with proactive adaptation.

We implement proactive adaptation based on REACT-ION’s context management module as described in Section 4.2. We connect REACT-ION to Telescope [95]—an R-based software for univariate time-series forecasting—for predicting the future power consumption. Telescope uses the data of the first week for predicting the second week. The adaptation options specification in Clafer activates power sources based on the currently required power, the number of already running power sources, and a predicted power requirement for the next simulation step. When applying reactive adaptation, this prediction value is not used. The horizon of Telescope is set to 1, i.e., only the power consumption in the following simulation step—the next 15 min—is predicted.

In this experiment, we answer two research questions. First, we investigate whether proactive adaptation with REACT-ION leads to benefits compared to reactive adaptation (RQ2.1). As the overall goal of REACT-ION is to achieve situation awareness, we discuss how proactivity relates to situation awareness in this case study (RQ2.2).

RQ2.1:

How does the system performance improve when applying proactive adaptations using REACT-ION?

Figure 7(a) compares the average number of overloads for reactive and proactive adaptation. An overload occurs if the power production in the smart grid is lower than the power consumption. Reducing the number of overloads is the primary goal in this experiment. We observe that proactive adaptation with REACT-ION is able to decrease the number of overloads from 230 to 203 on average in comparison to reactive adaptation. We therefore conclude that proactive adaptation is superior to reactive adaptation in this use case. Figure 7(b) shows the excess power produced in the smart grid. Since activating power sources increases the production step-wise and not continuously, proactive adaptation leads to more excess power.

Fig. 7.

Fig. 7. Average number of overloaded simulation steps (a) and the average power delta (b) of the reactive and the proactive approach.

In addition to proactive and reactive adaptation, it is also feasible to apply a static configuration with a fixed number of power sources. With such a static configuration, it is trivial to optimize either the number of overloads or the excess power. For instance, a high number of power sources may reduce the number of overloads to 0. The other extreme would be to produce no power at all, which would optimize the amount of excess power. Balancing the two goals with a static configuration, however, is not feasible due to two reasons. First, choosing a suitable static configuration manually is challenging itself. Second, such a configuration would be tailored to a certain situation and would not adapt to context changes. Overall, we therefore conclude that proactive adaptation with REACT-ION and Telescope is able to anticipate increases in power consumption and to activate power sources accordingly. This not only helps to improve the stability of the grid but also contributes to its resilience.

RQ2.2:

How does proactive adaptation contribute to situation awareness?

According to Reference [28], prediction is an important requirement for situation awareness, i.e., the requirement to foresee changes in the situation and react accordingly, e.g., through proactive adaptation. However, our evaluation shows a second facet in the relation of situation awareness and proactive adaptation. Figure 8 depicts an excerpt of an exemplary simulation run. The first 5 h of the excerpt show the strengths of situation awareness: Through prediction of the new demand (i.e., the new situation) and proactive adaptation, the production is increased in advance to avoid overloads. However, sudden peaks in the power consumption—as shown between 7:45 and 8:15—are difficult to predict. In these situations, it is important to decide if an adaptation decision should be reactive or proactive. When integrating proactive adaptation, the reliability of the predictions/forecasts is a relevant metric. If the predictions are not reliable in a specific situation, then reactive adaptation might still be the better option. The reason for this is that—in this case—the best known adaptation for the situation is performed rather than applying an adaptation for a situation that might not happen. This potentially decreases system performance even stronger as a reactive, delayed adaptation would impact performance. Further, reactive adaptation is required as backup for unknown situations. For the smart grid scenario, the current situation of COVID-19 lockdowns would be such an example, because it creates completely different situations—people stay at home at times when they would usually be at work/school—that the prediction/forecasting framework did not encounter and hence was not able to learn. Consequently, it is important to integrate a situation-aware choice whether to apply proactive or reactive adaptation, depending on the reliability of the prediction.

Fig. 8.

Fig. 8. Excerpt of the timeline of an exemplary run of the proactivity evaluation. Note: Starting at 5:45 reactive and proactive production are equal.

5.3 Self-Improvement with REACT-ION and Multiple Feedback Loops

In this experiment, we deploy five MAPE-K feedback loops with different reasoning approaches as proposed in Section 4.3. Similar to Section 5.1, REACT-ION adapts a cloud server deployment provided by the SWIM exemplar in this case study.

Experimental Setup: We deploy five MAPE-K feedback loops with REACT-ION. These feedback loops either use the planning approach that solves a CSP (cf. Section 3) or the planning approach that uses a CFM as introduced in Section 4.3. The feedback loops differ in their solver implementations and in the specification of the reconfiguration options. The first feedback loop (CFM-based (SAT)) is CFM-based. It transforms the CFM into a Boolean satisfiability problem and solves it with the SAT4J [12] solver. The second feedback loop (CFM-based (MILP, Simplified)) is also CFM-based but transforms the CFM into a MILP problem. It solves the MILP problem with the CPLEX9 solver. For reasons of comparability, we use the same problem specification for this feedback loop as for the first feedback loop. This means that several additional modeling features that the MILP solver is able to handle (in comparison to the SAT solver) are not used here. The third feedback loop (CSP-based (Simplified)) uses REACT’s original reasoning approach that solves a CSP. Similar to the previous loop, we use the same problem specification as for CFM-based (SAT). Again, this leaves several strengths of the CSP-based approach (e.g., extensive modeling capabilities) unused but makes it possible to compare the pure execution time of the planning approaches. The fourth feedback loop (CFM-based (MILP)) is CFM-based and transforms the CFM into a MILP problem. Thus, it is similar to the second feedback loop. However, we now apply a specification of the reconfiguration behavior that exhausts the additional capabilities and expressiveness of a MILP problem in comparison to a SAT problem. For instance, there is no restriction on Boolean variables only, which was required for the SAT solver. The fifth feedback loop (CSP-based) is CSP-based. In contrast to the third feedback loop, it uses a more sophisticated problem specification that exploits the additional features of Clafer.

In the scenario, the 30-min ClarkNet [26] trace provided with SWIM is used. Every run is repeated 20 times, and the context of the system is fetched every 10 s. By comparing the different feedback loops with regards to adaptation quality and adaptation speed (RQ3), we show the benefits of choosing the reasoning approach based on the current situation. Therefore, we measure the average planning time and the average utility. The utility is provided by SWIM and describes the quality of the adaptation decisions.

RQ3:

Is self-improvement with REACT-ION able to combine the advantages of several reasoning approaches with regards to adaptation quality and adaptation speed?

Figure 9 shows the results of the experiment with regards to the utility (Figure 9(a)) and planning time (Figure 9(b)). As far as the quality of the adaptation decisions is concerned, we observe in Figure 9(a) that CFM-based (MILP) and CSP-based considerably outperform the three other planning approaches that use the basic problem specification. We conclude that the improved modeling capabilities of CFM-based (MILP) and CSP-based lead to better adaptations. When comparing the remaining three planning approaches that use the same simple specification, we observe that CFM-based (SAT) leads to the highest utility. We argue that the faster adaptation is the reason for this. Figure 9(b) shows that CFM-based (SAT) leads to the fastest adaptations. It is 10% faster than CFM-based (MILP, Simplified) and 73% faster than CSP-based (Simplified), even though they are using the same specification. The difference is even larger for more sophisticated specifications in CFM-based (MILP) and CSP-based. Therefore, the feedback loop that uses CFM-based (SAT) reacts more promptly to changes in the load and is thus able to achieve higher utilities than the other approaches with the simple specification. Still, more sophisticated specifications lead to even higher utility values.

Fig. 9.

Fig. 9. Average utility per feedback loop type (a) and corresponding average planning times (b).

Answering RQ3, we therefore conclude that there is a clear tradeoff between planning time and adaptation quality. If fast adaptations are required, then employing CFM-based (SAT) or a MILP solver with a restricted SAT-based specification (CFM-based (MILP, Simplified)) is possibly the better choice. This, however, comes at the cost of worse adaptation decisions in comparison to CFM-based (MILP) and CSP-based. As there is no planning approach that dominates the others with regards to both planning time and adaptation quality, the optimal choice depends on the current situation. With REACT-ION, such a change of the planning approach based on the situation at runtime is possible. REACT-ION’s context management module distributes context information to external components that determine the current situation. Due to REACT-ION’s options for self-improvement, it is possible to change the reasoning approach based on the determined situation at runtime. We therefore argue that situation awareness with REACT-ION increases the flexibility of planning. In situations where fast adaptations are important (e.g., in a critical state of the system), the system may use the fastest planning approach. When fast adaptations are less important, the system may in contrast use a more sophisticated planning approach to achieve a higher adaptation quality. A third option would be to use multiple loops at the same time, e.g., to get a result as fast as possible, and, simultaneously, run in the background another solver that tries to identify a better solution. The system may choose this option when the current situation allows the additional planning effort, e.g., in terms of memory footprint and computational load. We acknowledge that the integration of multiple feedback loops could lead to conflicts. Still, this may be a valuable option in a situation-aware system that chooses the planning approach depending on the current situation. Selecting, handling, and coordinating multiple feedback loops that run in parallel is an interesting field for future research.

5.4 Threats to Validity

We identify the following threats to validity for our evaluation results. We measure SLOC and the number of different languages to show REACT’s low development effort for domain experts. Even though SLOC are frequently used as a metric (e.g., in References [24, 47, 86]), a future user study with domain experts who apply REACT in different scenarios would strengthen validity. This work is further limited to a comparison with Rainbow. Future research may include a comparison to other frameworks such as SASSY [54] or StarMX [5] in additional use cases from the communication systems domain. As far as situation awareness with REACT-ION is concerned, only Telescope [95] as external prediction approach has been applied, and we omit a comparison of several approaches for prediction. Moreover, we focus in this work on compositional self-improvement. As future work, we aim at evaluating further situation-aware self-improvement options besides compositional adaptations. This includes parametric adaptation, i.e., changing the models autonomously as well as deployment changes of the adaptation logic. These deployment changes could, e.g., result in moving the computationally intensive planner to faster machines at runtime in high-load situations. Finally, we acknowledge that situation awareness, proactive adaptation, and self-improvement are broad terms. REACT-ION covers only a part of the spectrum that these terms potentially contain.

Skip 6CONCLUSION Section

6 CONCLUSION

In this article, we present REACT-ION, a reusable runtime environment for model-based adaptations in communication systems that supports situation awareness. REACT-ION is an extension of REACT, which integrates a MAPE-K feedback loop that leverages a Clafer and a UML model provided by the domain expert to autonomously achieve self-adaptivity. Due to its support for multiple programming languages, decentralized control, distributed deployments, and runtime modifications, REACT is well-applicable for adapting overlay and underlay networks. We compared REACT to the well-known Rainbow framework, showing that it is easy-to-use for domain experts and suitable for use cases that require fast adaptations. REACT-ION extends REACT with a context management module, which can be used for providing situation awareness capabilities, executing proactive adaptations, and performing self-improvement. We applied proactive adaptations using REACT-ION and showed the possibility to run multiple REACT-ION-based feedback loops. This capability can be used for self-improvement by selecting a specific feedback loop based on the current system situation.

As future work, we plan to integrate additional interfaces that allow developers to directly use own analyzing and planning techniques such as machine learning or a different specification language such as Stitch [22] instead of Clafer. As verification and validation (V&V) is an important research challenge [22, 25], we plan to add verification of dynamic properties such as runtime V&V techniques and guarantees according to costs into REACT, e.g., using model-checking methods. This will ensure the correctness of the models and REACT will give certain runtime guarantees. Future work additionally includes a user study with domain experts that further investigates the development effort. Focussing on such empirical evidence with practitioners has been identified as general challenge for further self-adaptive systems research [90]. For prediction, we integrated the Telescope [95] framework as an external prediction approach. We plan to investigate possibilities to provide a standardized solution for prediction/forecasts as part of REACT-ION itself. For example, it might be possible to integrate a recommendation system for time series forecasting (e.g., Reference [96]), which autonomously chooses the best suitable algorithm depending on the data characteristics.

Skip ACKNOWLEDGMENTs Section

ACKNOWLEDGMENTs

We thank Veronika Lesch (University of Würzburg) for the initial implementation of the Java-R-Bridge and our former students Marc Guldner, Erik Penther, and Johannes Schaum for their valuable contributions.

Footnotes

  1. 1 This article is an extended version of previous work published in the Proceedings of the 1st IEEE International Conference on Autonomic Computing and Self-Organizing Systems (ACSOS 2020).

    Footnote
  2. 2 Available here: https://github.com/martinpfannemueller/REACT.

    Footnote
  3. 3 https://www.eclipse.org/papyrus/.

    Footnote
  4. 4 https://www.consul.io/.

    Footnote
  5. 5 https://www.mysql.com.

    Footnote
  6. 6 https://mosquitto.org/.

    Footnote
  7. 7 https://www.eclipse.org/paho/.

    Footnote
  8. 8 https://mosaik.offis.de/.

    Footnote
  9. 9 http://www.ibm.com/analytics/cplex-optimizer.

    Footnote

REFERENCES

  1. [1] Abowd Gregory D., Dey Anind K., Brown Peter J., Davies Nigel, Smith Mark, and Steggles Pete. 1999. Towards a better understanding of context and context-awareness. In Proceedings of the 1st International Symposium on Handheld and Ubiquitous Computing (HUC’99). Springer, Berlin, 304307. DOI: DOI: https://doi.org/10.1007/3-540-48157-5_29 Google ScholarGoogle ScholarCross RefCross Ref
  2. [2] Amoui Mehdi, Derakhshanmanesh Mahdi, Ebert Jürgen, and Tahvildari Ladan. 2012. Achieving dynamic adaptation via management and interpretation of runtime models. J. Syst. Softw. 85, 12 (2012), 27202737. DOI: DOI: https://doi.org/10.1016/j.jss.2012.05.033 Google ScholarGoogle ScholarCross RefCross Ref
  3. [3] Angelopoulos Konstantinos, Souza Vitor E. Silva, and Pimentel João. 2013. Requirements and architectural approaches to adaptive software systems: A comparative study. In Proceedings of the 8th International Symposium on Software Engineering for Adaptive and Self-Managing Systems (SEAMS’13). IEEE, Piscataway, NJ, 2332. DOI: DOI: https://doi.org/10.1109/SEAMS.2013.6595489 Google ScholarGoogle ScholarCross RefCross Ref
  4. [4] Antkiewicz Michal, Bak Kacper, Czarnecki Krzysztof, Diskin Zinovy, Zayan Dina, and Wasowski Andrzej. 2013. Example-driven modeling using clafer. In Proceedings of the 16th International Conference on Model Driven Engineering Languages and Systems (MoDELS’13). ACM/IEEE, New York, NY/Piscataway, NJ, 3241.Google ScholarGoogle Scholar
  5. [5] Asadollahi Reza, Salehie Mazeiar, and Tahvildari Ladan. 2009. StarMX: A framework for developing self-managing Java-based systems. In Proceedings of the ICSE Workshop on Software Engineering for Adaptive and Self-Managing Systems (SEAMS’09). IEEE, Piscataway, NJ, 5867. DOI: DOI: https://doi.org/10.1109/SEAMS.2009.5069074 Google ScholarGoogle ScholarCross RefCross Ref
  6. [6] Bak Kacper. 2013. Modeling and Analysis of Software Product Line Variability in Clafer. Ph.D. Dissertation. University of Waterloo, Ontario, Canada.Google ScholarGoogle Scholar
  7. [7] Bak Kacper, Czarnecki Krzysztof, and Wasowski Andrzej. 2010. Feature and meta-models in clafer: Mixed, specialized, and coupled. In Proceedings of the 3rd International Conference on Software Language Engineering (SLE’10). Springer, Berlin, Heidelberg, 102122. DOI: DOI: https://doi.org/10.1007/978-3-642-19440-5_7 Google ScholarGoogle ScholarCross RefCross Ref
  8. [8] Bak Kacper, Diskin Zinovy, Antkiewicz Michal, Czarnecki Krzysztof, and Wasowski Andrzej. 2016. Clafer: Unifying class and feature modeling. Softw. Syst. Model. 15, 3 (2016), 811845. DOI: DOI: https://doi.org/10.1007/s10270-014-0441-1 Google ScholarGoogle ScholarCross RefCross Ref
  9. [9] Bencomo Nelly, France Robert B., Cheng Betty, and Aßmann Uwe (Eds.). 2014. [email protected]—Foundations, Applications, and Roadmaps. Springer, Berlin. DOI: DOI: https://doi.org/10.1007/978-3-319-08915-7Google ScholarGoogle ScholarCross RefCross Ref
  10. [10] Bencomo Nelly, Grace Paul, Flores-Cortés Carlos A., Hughes Danny, and Blair Gordon S.. 2008. Genie: Supporting the model driven development of reflective, component-based adaptive systems. In Proceedings of the 30th International Conference on Software Engineering (ICSE’08). ACM, New York, NY, 811814. DOI: DOI: https://doi.org/10.1145/1368088.1368207 Google ScholarGoogle ScholarCross RefCross Ref
  11. [11] Bencomo Nelly, Sawyer Peter, Blair Gordon S., and Grace Paul. 2008. Dynamically adaptive systems are product lines too: Using model-driven techniques to capture dynamic variability of adaptive systems. In Proceedings of the 12th International Software Product Lines Conference (SPLC’08). IEEE, Piscataway, NJ, 2332.Google ScholarGoogle Scholar
  12. [12] Berre Daniel Le and Parrain Anne. 2010. The Sat4j library, release 2.2. J. Satisfiabil. Boolean Model. Comput. 7, 2-3 (2010), 59–6. DOI: DOI: https://doi.org/10.3233/SAT190075Google ScholarGoogle ScholarCross RefCross Ref
  13. [13] Bikakis Antonis, Patkos Theodore, Antoniou Grigoris, and Plexousakis Dimitris. 2007. A survey of semantics-based approaches for context reasoning in ambient intelligence. In Proceedings of the European Conference on Ambient Intelligence (AmI’07). Springer, Berlin, 1423. DOI: DOI: https://doi.org/10.1007/978-3-540-85379-4_3Google ScholarGoogle Scholar
  14. [14] Blair Gordon S., Bencomo Nelly, and France Robert B.. 2009. Models@ run.time. IEEE Comput. 42, 10 (2009), 2227. DOI: DOI: https://doi.org/10.1109/MC.2009.326 Google ScholarGoogle ScholarCross RefCross Ref
  15. [15] Cámara Javier, Garlan David, Schmerl Bradley R., and Pandey Ashutosh. 2015. Optimal planning for architecture-based self-adaptation via model checking of stochastic games. In Proceedings of the 30th Annual ACM Symposium on Applied Computing (SAC’15). ACM, New York, NY, 428435. DOI: DOI: https://doi.org/10.1145/2695664.2695680 Google ScholarGoogle ScholarCross RefCross Ref
  16. [16] Cámara Javier, Moreno Gabriel A., and Garlan David. 2014. Stochastic game analysis and latency awareness for proactive self-adaptation. In Proceedings of the 9th International Symposium on Software Engineering for Adaptive and Self-Managing Systems (SEAMS’14). ACM, New York, NY, 155164. DOI: DOI: https://doi.org/10.1145/2593929.2593933 Google ScholarGoogle ScholarCross RefCross Ref
  17. [17] Cámara Javier, Moreno Gabriel A., and Garlan David. 2015. Reasoning about human participation in self-adaptive systems. In Proceedings of the 10th International Symposium on Software Engineering for Adaptive and Self-Managing Systems (SEAMS’15). ACM, New York, NY, 146156. DOI: DOI: https://doi.org/10.1109/SEAMS.2015.14 Google ScholarGoogle ScholarCross RefCross Ref
  18. [18] Capra Licia, Emmerich Wolfgang, and Mascolo Cecilia. 2003. CARISMA: Context-aware reflective middleware system for mobile applications. IEEE Trans. Softw. Eng. 29, 10 (2003), 929945. DOI: DOI: https://doi.org/10.1109/TSE.2003.1237173 Google ScholarGoogle ScholarDigital LibraryDigital Library
  19. [19] Cardellini Valeria, Casalicchio Emiliano, Grassi Vincenzo, Iannucci Stefano, Presti Francesco Lo, and Mirandola Raffaela. 2012. MOSES: A framework for QoS driven runtime adaptation of service-oriented systems. IEEE Trans. Softw. Eng. 38, 5 (2012), 11381159. DOI: DOI: https://doi.org/10.1109/TSE.2011.68 Google ScholarGoogle ScholarCross RefCross Ref
  20. [20] Cetina Carlos, Giner Pau, Fons Joan, and Pelechano Vicente. 2008. A model-driven approach for developing self-adaptive pervasive systems. In Proceedings of the 3rd Workshop on [email protected]. 97106.Google ScholarGoogle Scholar
  21. [21] Charalambides Marinos, Pavlou George, Flegkas Paris, Wang Ning, and Tuncer Daphné. 2011. Managing the future internet through intelligent in-network substrates. IEEE Netw. 25, 6 (2011), 3440. DOI: DOI: https://doi.org/10.1109/MNET.2011.6085640Google ScholarGoogle ScholarCross RefCross Ref
  22. [22] Cheng Betty H. C., Eder Kerstin I., Gogolla Martin, Grunske Lars, Litoiu Marin, Müller Hausi A., Pelliccione Patrizio, Perini Anna, Qureshi Nauman A., Rumpe Bernhard, Schneider Daniel, Trollmann Frank, and Villegas Norha M.. 2011. Using models at runtime to address assurance for self-adaptive systems. In [email protected]—Foundations, Applications, and Roadmaps. Springer, Berlin, 101136. DOI: DOI: https://doi.org/10.1007/978-3-319-08915-7_4Google ScholarGoogle Scholar
  23. [23] Cheng Shang-Wen and Garlan David. 2012. Stitch: A language for architecture-based self-adaptation. J. Syst. Softw. 85, 12 (2012), 28602875. DOI: DOI: https://doi.org/10.1016/j.jss.2012.02.060 Google ScholarGoogle ScholarDigital LibraryDigital Library
  24. [24] Cheng Shang-Wen. 2004. Rainbow: Cost-effective software architecture-based self-adaptation. Ph.D. Dissertation. Carnegie Mellon University, Pittsburgh, PA. Google ScholarGoogle ScholarDigital LibraryDigital Library
  25. [25] Lemos Rogério de, Giese Holger, Müller Hausi A., Shaw Mary, Andersson Jesper, Litoiu Marin, Schmerl Bradley, Tamura Gabriel, Villegas Norha M., Vogel Thomas, Weyns Danny, Baresi Luciano, Becker Basil, Bencomo Nelly, Brun Yuriy, Cukic Bojan, Desmarais Ron, Dustdar Schahram, Engels Gregor, Geihs Kurt, Göschka Karl M., Gorla Alessandra, Grassi Vincenzo, Inverardi Paola, Karsai Gabor, Kramer Jeff, Lopes Antónia, Magee Jeff, Malek Sam, Mankovskii Serge, Mirandola Raffaela, Mylopoulos John, Nierstrasz Oscar, Pezzè Mauro, Prehofer Christian, Schäfer Wilhelm, Schlichting Rick, Smith Dennis B., Sousa Joao Pedro, Tahvildari Ladan, Wong Kenny, and Wuttke Jochen. 2010. Software engineering for self-adaptive systems: A second research roadmap. In Software Engineering for Self-Adaptive Systems II. Springer, Berlin, 132. DOI: DOI: https://doi.org/10.1007/978-3-642-35813-5_1 Google ScholarGoogle ScholarCross RefCross Ref
  26. [26] Dilley John. 1996. Web server workload characterization. HP Lab. Tech. Report 24 (1996), 116. DOI: DOI: https://doi.org/10.1145/233008.233034Google ScholarGoogle Scholar
  27. [27] Dowling Jim and Cahill Vinny. 2001. The K-component architecture meta-model for self-adaptive software. In Proceedings of the 3rd International Conference on Metalevel Architectures and Separation of Crosscutting Concerns (REFLECTION’01). Springer, Berlin, 8188. DOI: DOI: https://doi.org/10.1007/3-540-45429-2_6 Google ScholarGoogle ScholarCross RefCross Ref
  28. [28] Endsley Mica R.. 1995. Toward a theory of situation awareness in dynamic systems. Hum. Factors 37, 1 (1995), 3264. DOI: DOI: https://doi.org/10.1518/001872095779049543Google ScholarGoogle ScholarCross RefCross Ref
  29. [29] Escoffier Clément, Hall Richard S., and Lalanda Philippe. 2007. iPOJO: An extensible service-oriented component framework. In Proceedings of the International Conference on Services Computing (SCC’07). IEEE, Piscataway, NJ, 474481. DOI: DOI: https://doi.org/10.1109/SCC.2007.74Google ScholarGoogle ScholarCross RefCross Ref
  30. [30] Esfahani Naeem, Elkhodary Ahmed M., and Malek Sam. 2013. A learning-based framework for engineering feature-oriented self-adaptive software systems. IEEE Trans. Softw. Eng. 39, 11 (2013), 14671493. DOI: DOI: https://doi.org/10.1109/TSE.2013.37 Google ScholarGoogle ScholarCross RefCross Ref
  31. [31] Esfahani Naeem and Malek Sam. 2010. Uncertainty in self-adaptive software systems. In Software Engineering for Self-Adaptive Systems II(Lecture Notes in Computer Science, Vol. 7475). Springer, Berlin, 214238. DOI: DOI: https://doi.org/10.1007/978-3-642-35813-5_9Google ScholarGoogle Scholar
  32. [32] Floch Jacqueline, Hallsteinsen Svein O., Stav Erlend, Eliassen Frank, Lund Ketil, and Gjørven Eli. 2006. Using architecture models for runtime adaptability. IEEE Softw. 23, 2 (2006), 6270. DOI: DOI: https://doi.org/10.1109/MS.2006.61 Google ScholarGoogle ScholarDigital LibraryDigital Library
  33. [33] Fredericks Erik M., Gerostathopoulos Ilias, Krupitzer Christian, and Vogel Thomas. 2019. Planning as optimization: Dynamically discovering optimal configurations for runtime situations. In Proceedings of the 13th International Conference on Self-Adaptive and Self-Organizing Systems (SASO’19). IEEE, Piscataway, NJ, 110. DOI: DOI: https://doi.org/10.1109/saso.2019.00010Google ScholarGoogle ScholarCross RefCross Ref
  34. [34] Gámez Nadia, Fuentes Lidia, and Troya José M.. 2015. Creating self-adapting mobile systems with dynamic software product lines. IEEE Softw. 32, 2 (2015), 105112. DOI: DOI: https://doi.org/10.1109/MS.2014.24Google ScholarGoogle ScholarCross RefCross Ref
  35. [35] García-Domínguez Antonio, Bencomo Nelly, Ullauri Juan Marcelo Parra, and Paucar Luis Hernán García. 2019. Querying and annotating model histories with time-aware patterns. In Proceedings of the 22nd International Conference on Model Driven Engineering Languages and Systems (MODELS’19). ACM/IEEE, New York, NY/Piscataway, NJ, 194204. DOI: DOI: https://doi.org/10.1109/MODELS.2019.000-2Google ScholarGoogle ScholarCross RefCross Ref
  36. [36] Garlan David, Cheng Shang-Wen, Huang An-Cheng, Schmerl Bradley R., and Steenkiste Peter. 2004. Rainbow: Architecture-based self-adaptation with reusable infrastructure. IEEE Comput. 37, 10 (2004), 4654. DOI: DOI: https://doi.org/10.1109/MC.2004.175 Google ScholarGoogle ScholarCross RefCross Ref
  37. [37] Garlan David, Siewiorek Daniel P., Smailagic Asim, and Steenkiste Peter. 2002. Project aura: Toward distraction-free pervasive computing. IEEE Pervasive Comput. 1, 2 (2002), 2231. DOI: DOI: https://doi.org/10.1109/MPRV.2002.1012334 Google ScholarGoogle ScholarCross RefCross Ref
  38. [38] Hallsteinsen Sven, Geihs Kurt, Paspallis Nearchos, Eliassen Frank, Horn Geir, Lorenzo Jorge, Mamelli Alessandro, and Papadopoulus George A.. 2012. A development framework and methodology for self-adapting applications in ubiquitous computing environments. J. Syst. Softw. 85, 12 (2012), 28402859. DOI: DOI: https://doi.org/10.1016/j.jss.2012.07.052 Google ScholarGoogle ScholarCross RefCross Ref
  39. [39] Handte Marcus, Schiele Gregor, Majuntke Verena, Becker Christian, and Marrón Pedro José. 2012. 3PC: System support for adaptive peer-to-peer pervasive computing. ACM Trans. Autonom. Adapt. Syst. 7, 1 (2012), 119. DOI: DOI: https://doi.org/10.1145/2168260.2168270 Google ScholarGoogle ScholarCross RefCross Ref
  40. [40] Hartmann Herman and Trew Tim. 2008. Using feature diagrams with context variability to model multiple product lines for software supply chains. In Proceedings of the Software Product Line Conference (SPLC’08). IEEE, Piscataway, NJ, 1221. DOI: DOI: https://doi.org/10.1109/SPLC.2008.15 Google ScholarGoogle ScholarCross RefCross Ref
  41. [41] Henning Michi. 2004. A new approach to object-oriented middleware. IEEE Internet Comput. 8, 1 (2004), 6675. DOI: DOI: https://doi.org/10.1109/MIC.2004.1260706 Google ScholarGoogle ScholarCross RefCross Ref
  42. [42] Henricksen Karen. 2003. A framework for context-aware pervasive computing applications. Ph.D. Dissertation. The University of Queensland, Brisbane, Australia.Google ScholarGoogle Scholar
  43. [43] Hrabia Christopher-Eyk, Lehmann Patrick Marvin, and Albayrak Sahin. 2019. Increasing self-adaptation in a hybrid decision-making and planning system with reinforcement learning. In Proceedings of the 43rd Annual Computer Software and Applications Conference (COMPSAC’19). IEEE, Piscataway, NJ, 469478. DOI: DOI: https://doi.org/10.1109/COMPSAC.2019.00073Google ScholarGoogle ScholarCross RefCross Ref
  44. [44] Képes Kálmán, Leymann Frank, and Zimmermann Michael. 2020. Situation-aware updates for cyber-physical systems. In Proceedings of the 14th Symposium and Summer School on Service-Oriented Computing (SummerSOC’20). Springer, Berlin, Heidelberg, 1232. DOI: DOI: https://doi.org/10.1007/978-3-030-64846-6_2Google ScholarGoogle ScholarCross RefCross Ref
  45. [45] Kephart Jeffrey O. and Chess David M.. 2003. The vision of autonomic computing. Computer 36, 1 (2003), 4150. DOI: DOI: https://doi.org/10.1109/MC.2003.1160055 Google ScholarGoogle ScholarDigital LibraryDigital Library
  46. [46] Kramer Jeff and Magee Jeff. 2007. Self-managed systems: An architectural challenge. In Proceedings of the Future of Software Engineering Symposium (FOSE’07). IEEE, Piscataway, NJ, 259268. DOI: DOI: https://doi.org/10.1109/FOSE.2007.19 Google ScholarGoogle ScholarCross RefCross Ref
  47. [47] Krupitzer Christian, Roth Felix Maximilian, Becker Christian, Weckesser Markus, Lochau Malte, and Schürr Andy. 2016. FESAS IDE: An integrated development environment for autonomic computing. In Proceedings of the International Conference on Autonomic Computing (ICAC’16). IEEE, Piscataway, NJ, 1524. DOI: DOI: https://doi.org/10.1109/ICAC.2016.49Google ScholarGoogle ScholarCross RefCross Ref
  48. [48] Krupitzer Christian, Roth Felix Maximilian, Pfannemüller Martin, and Becker Christian. 2016. Comparison of approaches for self-improvement in self-adaptive systems. In Proceedings of the International Conference on Autonomic Computing (ICAC’16). IEEE, Piscataway, NJ, 308314. DOI: DOI: https://doi.org/10.1109/ICAC.2016.18Google ScholarGoogle ScholarCross RefCross Ref
  49. [49] Krupitzer Christian, Roth Felix Maximilian, VanSyckel Sebastian, Schiele Gregor, and Becker Christian. 2015. A survey on engineering approaches for self-adaptive systems. Pervasive Mob. Comput. 17 (2015), 184206. DOI: DOI: https://doi.org/10.1016/j.pmcj.2014.09.009 Google ScholarGoogle ScholarDigital LibraryDigital Library
  50. [50] Lim Brian Y. and Dey Anind K.. 2010. Toolkit to support intelligibility in context-aware applications. In Proceedings of the 12th International Conference on Ubiquitous Computing (UbiComp’10). ACM, New York, NY, 1322. DOI: DOI: https://doi.org/10.1145/1864349.1864353 Google ScholarGoogle ScholarCross RefCross Ref
  51. [51] Magee Jeff, Dulay Naranker, Eisenbach Susan, and Kramer Jeff. 1995. Specifying distributed software architectures. In Proceedings of the 5th European Software Engineering Conference (ESEC’95). Springer, Berlin, Heidelberg, 137153. DOI: DOI: https://doi.org/10.1007/3-540-60406-5_12 Google ScholarGoogle ScholarCross RefCross Ref
  52. [52] Malek Sam, Edwards George, Brun Yuriy, Tajalli Hossein, Garcia Joshua, Krka Ivo, Medvidovic Nenad, Mikic-Rakic Marija, and Sukhatme Gaurav S.. 2010. An architecture-driven software mobility framework. J. Syst. Softw. 83, 6 (2010), 972989. DOI: DOI: https://doi.org/10.1016/j.jss.2009.11.003 Google ScholarGoogle ScholarCross RefCross Ref
  53. [53] McKinley Philip K., Sadjadi Seyed Masoud, Kasten Eric P., and Cheng Betty. 2004. Composing adaptive software. IEEE Comput. 37, 7 (2004), 5664. DOI: DOI: https://doi.org/10.1109/MC.2004.48 Google ScholarGoogle ScholarCross RefCross Ref
  54. [54] Menascé Daniel A., Gomaa Hassan, Malek Sam, and Sousa João Pedro. 2011. SASSY: A framework for self-architecting service-oriented systems. IEEE Softw. 28, 6 (2011), 7885. DOI: DOI: https://doi.org/10.1109/MS.2011.22 Google ScholarGoogle ScholarCross RefCross Ref
  55. [55] Moreno Gabriel A., Cámara Javier, Garlan David, and Schmerl Bradley R.. 2015. Proactive self-adaptation under uncertainty: A probabilistic model checking approach. In Proceedings of the 10th Joint Meeting on Foundations of Software Engineering (ESEC/FSE’15). ACM, New York, NY, 112. DOI: DOI: https://doi.org/10.1145/2786805.2786853 Google ScholarGoogle ScholarCross RefCross Ref
  56. [56] Moreno Gabriel A., Cámara Javier, Garlan David, and Schmerl Bradley R.. 2016. Efficient decision-making under uncertainty for proactive self-adaptation. In Proceedings of the International Conference on Autonomic Computing (ICAC’16). IEEE, Piscataway, NJ, 147156. DOI: DOI: https://doi.org/10.1109/ICAC.2016.59Google ScholarGoogle ScholarCross RefCross Ref
  57. [57] Moreno Gabriel A., Cámara Javier, Garlan David, and Schmerl Bradley R.. 2018. Flexible and efficient decision-making for proactive latency-aware self-adaptation. ACM Trans. Autonom. Adapt. Syst. 13, 1 (2018), 3:1–3:36. DOI: DOI: https://doi.org/10.1145/3149180 Google ScholarGoogle ScholarCross RefCross Ref
  58. [58] Moreno Gabriel A., Schmerl Bradley R., and Garlan David. 2018. SWIM: An exemplar for evaluation and comparison of self-adaptation approaches for web applications. In Proceedings of the 13th International Symposium on Software Engineering for Adaptive and Self-Managing Systems (SEAMS’18). ACM, New York, NY, 137143. DOI: DOI: https://doi.org/10.1145/3194133.3194163 Google ScholarGoogle ScholarCross RefCross Ref
  59. [59] Morin Brice, Barais Olivier, Jézéquel Jean-Marc, Fleurey Franck, and Solberg Arnor. 2009. Models@ Run.time to support dynamic adaptation. IEEE Comput. 42, 10 (2009), 4451. DOI: DOI: https://doi.org/10.1109/MC.2009.327 Google ScholarGoogle ScholarCross RefCross Ref
  60. [60] Nakahara Flávio Akira and Beder Delano Medeiros. 2018. A context-aware and self-adaptive offloading decision support model for mobile cloud computing system. J. Ambient Intell. Humaniz. Comput. 9, 5 (2018), 15611572. DOI: DOI: https://doi.org/10.1007/s12652-018-0790-7Google ScholarGoogle ScholarCross RefCross Ref
  61. [61] Oreizy Peyman, Gorlick Michael M., Taylor Richard N., Heimbigner Dennis, Johnson Gregory, Medvidovic Nenad, Quilici Alex, Rosenblum David S., and Wolf Alexander L.. 1999. An architecture-based approach to self-adaptive software. IEEE Intell. Syst. Appl. 14, 3 (1999), 5462. DOI: DOI: https://doi.org/10.1109/5254.769885 Google ScholarGoogle ScholarCross RefCross Ref
  62. [62] Pandey Ashutosh, Moreno Gabriel A., Cámara Javier, and Garlan David. 2016. Hybrid planning for decision making in self-adaptive systems. In Proceedings of the International Conference on Self-Adaptive and Self-Organizing Systems (SASO’16). IEEE, Piscataway, NJ, 130139. DOI: DOI: https://doi.org/10.1109/SASO.2016.19Google ScholarGoogle ScholarCross RefCross Ref
  63. [63] Pandey Ashutosh, Ruchkin Ivan, Schmerl Bradley R., and Cámara Javier. 2017. Towards a formal framework for hybrid planning in self-adaptation. In Proceedings of the 12th International Symposium on Software Engineering for Adaptive and Self-Managing Systems (SEAMS’17). IEEE, Piscataway, NJ, 109115. DOI: DOI: https://doi.org/10.1109/SEAMS.2017.14 Google ScholarGoogle ScholarCross RefCross Ref
  64. [64] Parekh Janak J., Kaiser Gail E., Gross Philip, and Valetto Giuseppe. 2006. Retrofitting autonomic capabilities onto legacy systems. Cluster Comput. 9, 2 (2006), 141159. DOI: DOI: https://doi.org/10.1007/s10586-006-7560-6 Google ScholarGoogle ScholarCross RefCross Ref
  65. [65] Perera Charith, Zaslavsky Arkady B., Christen Peter, and Georgakopoulos Dimitrios. 2014. Context aware computing for the Internet of Things: A survey. IEEE Commun. Surv. Tut. 16, 1 (2014), 414454. DOI: DOI: https://doi.org/10.1109/SURV.2013.042313.00197Google ScholarGoogle ScholarCross RefCross Ref
  66. [66] Pfannemüller Martin, Breitbach Martin, Krupitzer Christian, Becker Christian, and Schürr Andy. 2020. Enhancing a communication system with adaptive behavior using REACT. In Proceedings of the International Conference on Autonomic Computing and Self-Organizing Systems Companion (ACSOS-C’20). IEEE, Piscataway, NJ, 228229. DOI: DOI: https://doi.org/10.1109/ACSOS-C51401.2020.00062Google ScholarGoogle ScholarCross RefCross Ref
  67. [67] Pfannemüller Martin, Breitbach Martin, Krupitzer Christian, Weckesser Markus, Becker Christian, Schmerl Bradley, and Schürr Andy. 2020. REACT: A model-based runtime environment for adapting communication systems. In Proceedings of the International Conference on Autonomic Computing and Self-Organizing Systems (ACSOS’20). IEEE, Piscataway, NJ, 6574. DOI: DOI: https://doi.org/10.1109/ACSOS49614.2020.00027Google ScholarGoogle ScholarCross RefCross Ref
  68. [68] Pfannemüller Martin, Krupitzer Christian, Weckesser Markus, and Becker Christian. 2017. A dynamic software product line approach for adaptation planning in autonomic computing systems. In Proceedings of the International Conference on Autonomic Computing (ICAC’17). IEEE, Piscataway, NJ, 247254. DOI: DOI: https://doi.org/10.1109/ICAC.2017.18Google ScholarGoogle ScholarCross RefCross Ref
  69. [69] Preisler Thomas, Dethlefs Tim, and Renz Wolfgang. 2015. Middleware for constructing decentralized control in self-organizing systems. In Proceedings of the International Conference on Autonomic Computing (ICAC’15). IEEE, Piscataway, NJ, 325330. DOI: DOI: https://doi.org/10.1109/ICAC.2015.56 Google ScholarGoogle ScholarCross RefCross Ref
  70. [70] Prud’homme Charles, Fages Jean-Guillaume, and Lorca Xavier. 2017. Choco Documentation. TASC-LS2N CNRS UMR 6241, COSLING S.A.S. Retrieved from http://www.choco-solver.org.Google ScholarGoogle Scholar
  71. [71] Román Manuel, Hess Christopher K., Cerqueira Renato, Ranganathan Anand, Campbell Roy H., and Nahrstedt Klara. 2002. A middleware infrastructure for active spaces. IEEE Pervasive Comput. 1, 4 (2002), 7483. DOI: DOI: https://doi.org/10.1109/MPRV.2002.1158281 Google ScholarGoogle ScholarCross RefCross Ref
  72. [72] Roth Felix Maximilian, Krupitzer Christian, and Becker Christian. 2015. Runtime evolution of the adaptation logic in self-adaptive systems. In Proceedings of the International Conference on Autonomic Computing (ICAC’15). IEEE, Piscataway, NJ, 141142. DOI: DOI: https://doi.org/10.1109/ICAC.2015.20 Google ScholarGoogle ScholarCross RefCross Ref
  73. [73] Sakizloglou Lucas, Ghahremani Sona, Barkowsky Matthias, and Giese Holger. 2020. A scalable querying scheme for memory-efficient runtime models with history. In Proceedings of the 23rd International Conference on Model Driven Engineering Languages and Systems (MODELS’20). ACM, New York, NY, 175186. DOI: DOI: https://doi.org/10.1145/3365438.3410961 Google ScholarGoogle ScholarCross RefCross Ref
  74. [74] Salehie Mazeiar and Tahvildari Ladan. 2009. Self-adaptive software: Landscape and research challenges. ACM Trans. Autonom. Adapt. Syst. 4, 2 (2009), 142. DOI: DOI: https://doi.org/10.1145/1516533.1516538 Google ScholarGoogle ScholarCross RefCross Ref
  75. [75] Saller Karsten, Lochau Malte, and Reimund Ingo. 2013. Context-aware DSPLs: Model-based runtime adaptation for resource-constrained systems. In Proceedings of the Software Product Line Conference (SPLC’13). ACM, New York, NY, 106113. DOI: DOI: https://doi.org/10.1145/2499777.2500716 Google ScholarGoogle ScholarCross RefCross Ref
  76. [76] Schnabel Thomas, Weckesser Markus, Kluge Roland, Lochau Malte, and Schürr Andy. 2016. CardyGAn: Tool support for cardinality-based feature models. In Proceedings of the 10th International Workshop on Variability Modelling of Software-intensive Systems (VaMoS’16). ACM, New York, NY, 3340. DOI: DOI: https://doi.org/10.1145/2866614.2866619 Google ScholarGoogle ScholarCross RefCross Ref
  77. [77] Shin Yong-Jun, Cho Eunho, and Bae Doo-Hwan. 2021. PASTA: An efficient proactive adaptation approach based on statistical model checking for self-adaptive systems. In Fundamental Approaches to Software Engineering(Lecture Notes in Computer Science, Vol. 12649). Springer, Berlin, 292312. DOI: DOI: https://doi.org/10.1007/978-3-030-71500-7_15Google ScholarGoogle ScholarCross RefCross Ref
  78. [78] Sicard Sylvain, Boyer Fabienne, and Palma Noel De. 2008. Using components for architecture-based management: The self-repair case. In Proceedings of the 30th International Conference on Software Engineering (ICSE’08). ACM, New York, NY, 101110. DOI: DOI: https://doi.org/10.1145/1368088.1368103 Google ScholarGoogle ScholarCross RefCross Ref
  79. [79] Souza Vítor Estêvão Silva. 2012. Requirements-based Software System Adaptation. Ph.D. Dissertation. University of Trento, Trento, Italy.Google ScholarGoogle Scholar
  80. [80] Swanson Jacob, Cohen Myra B., Dwyer Matthew B., Garvin Brady J., and Firestone Justin. 2014. Beyond the rainbow: Self-adaptive failure avoidance in configurable systems. In Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering. ACM, New York, NY, 377388. DOI: DOI: https://doi.org/10.1145/2635868.2635915 Google ScholarGoogle ScholarCross RefCross Ref
  81. [81] Tajalli Hossein, Garcia Joshua, Edwards George, and Medvidovic Nenad. 2010. PLASMA: A plan-based layered architecture for software model-driven adaptation. In Proceedings of the International Conference on Automated Software Engineering (ASE’10). ACM, New York, NY, 467476. DOI: DOI: https://doi.org/10.1145/1858996.1859092 Google ScholarGoogle ScholarCross RefCross Ref
  82. [82] Tomforde Sven. 2011. An architectural framework for self-configuration and self-improvement at runtime. Ph.D. Dissertation. University of Hannover, Hannover, Germany. DOI: DOI: https://doi.org/10.15488/7766Google ScholarGoogle Scholar
  83. [83] Tomforde Sven and Müller-Schloer Christian. 2013. Incremental design of adaptive systems. J. Ambient Intell. Smart Environ. 6, 2 (2013), 179198. DOI: DOI: https://doi.org/10.3233/AIS-140252 Google ScholarGoogle ScholarCross RefCross Ref
  84. [84] Ullauri Juan Marcelo Parra, García-Domínguez Antonio, Paucar Luis Hernán García, and Bencomo Nelly. 2020. Temporal models for history-aware explainability. In Proceedings of the 12st System Analysis and Modelling Conference (SAM’20). ACM, New York, NY, 155164. DOI: DOI: https://doi.org/10.1145/3419804.3420276 Google ScholarGoogle ScholarCross RefCross Ref
  85. [85] VanSyckel Sebastian, Schäfer Dominik, Schiele Gregor, and Becker Christian. 2013. Configuration management for proactive adaptation in pervasive environments. In Proceedings of the International Conference on Self-Adaptive and Self-Organizing Systems (SASO’13). IEEE, Piscataway, NJ, 131140. DOI: DOI: https://doi.org/10.1109/SASO.2013.28 Google ScholarGoogle ScholarCross RefCross Ref
  86. [86] Vogel Thomas. 2018. Model-Driven Engineering of Self-Adaptive Software. Ph.D. Dissertation. University of Potsdam, Potsdam, Germany.Google ScholarGoogle Scholar
  87. [87] Vogel Thomas and Giese Holger. 2012. A language for feedback loops in self-adaptive systems: Executable runtime megamodels. In Proceedings of the 7th International Symposium on Software Engineering for Adaptive and Self-Managing Systems (SEAMS’12). IEEE, Piscataway, NJ, 129138. DOI: DOI: https://doi.org/10.1109/SEAMS.2012.6224399 Google ScholarGoogle ScholarCross RefCross Ref
  88. [88] Vogel Thomas and Giese Holger. 2014. Model-driven engineering of self-adaptive software with EUREMA. ACM Trans. Autonom. Adapt. Syst. 8, 4 (2014), 133. DOI: DOI: https://doi.org/10.1145/2555612 Google ScholarGoogle ScholarCross RefCross Ref
  89. [89] Weckesser Markus, Lochau Malte, Ries Michael, and Schürr Andy. 2018. Mathematical programming for anomaly analysis of clafer models. In Proceedings of the 21st International Conference on Model Driven Engineering Languages and Systems (MODELS’18). ACM, New York, NY, 3444. DOI: DOI: https://doi.org/10.1145/3239372.3239398 Google ScholarGoogle ScholarCross RefCross Ref
  90. [90] Weyns Danny. 2019. Software engineering of self-adaptive systems. In Handbook of Software Engineering. Springer, Berlin, 399443. DOI: DOI: https://doi.org/10.1007/978-3-030-00262-6_11Google ScholarGoogle ScholarCross RefCross Ref
  91. [91] Weyns Danny and Iftikhar M. Usman. 2019. ActivFORMS: A model-based approach to engineer self-adaptive systems. Retrieved from https://arXiv:1908.11179.Google ScholarGoogle Scholar
  92. [92] Weyns Danny, Schmerl Bradley, Grassi Vincenzo, Malek Sam, Mirandola Raffaela, Prehofer Christian, Wuttke Jochen, Andersson Jesper, Giese Holger, and Göschka Karl M.. 2010. On patterns for decentralized control in self-adaptive systems. In Software Engineering for Self-Adaptive Systems II. Springer, Berlin, 76107. DOI: DOI: https://doi.org/10.1007/978-3-642-35813-5_4Google ScholarGoogle Scholar
  93. [93] Ye Juan, Dobson Simon, and McKeever Susan. 2012. Situation identification techniques in pervasive computing: A review. Pervasive Mob. Comput. 8, 1 (2012), 3666. DOI: DOI: https://doi.org/10.1016/j.pmcj.2011.01.004 Google ScholarGoogle ScholarCross RefCross Ref
  94. [94] Zavala Edith, Franch Xavier, Marco Jordi, and Berger Christian. 2020. HAFLoop: An architecture for supporting highly adaptive feedback loops in self-adaptive systems. Future Gener. Comput. Syst. 105 (2020), 607630. DOI: DOI: https://doi.org/10.1016/j.future.2019.12.026Google ScholarGoogle ScholarCross RefCross Ref
  95. [95] Züfle Marwin, Bauer André, Herbst Nikolas, Curtef Valentin, and Kounev Samuel. 2017. Telescope: A hybrid forecast method for univariate time series. In Proceedings of the International Work-Conference on Time Series Analysis.Google ScholarGoogle Scholar
  96. [96] Züfle Marwin, Bauer André, Lesch Veronika, Krupitzer Christian, Herbst Nikolas, Kounev Samuel, and Curtef Valentin. 2019. Autonomic forecasting method selection: Examination and ways ahead. In Proceedings of the International Conference on Autonomic Computing (ICAC’19). IEEE, Piscataway, NJ, 167176. DOI: DOI: https://doi.org/10.1109/ICAC.2019.00028Google ScholarGoogle ScholarCross RefCross Ref

Index Terms

  1. REACT-ION: A Model-based Runtime Environment for Situation-aware Adaptations

          Recommendations

          Comments

          Login options

          Check if you have access through your login credentials or your institution to get full access on this article.

          Sign in

          Full Access

          • Published in

            cover image ACM Transactions on Autonomous and Adaptive Systems
            ACM Transactions on Autonomous and Adaptive Systems  Volume 15, Issue 4
            December 2020
            153 pages
            ISSN:1556-4665
            EISSN:1556-4703
            DOI:10.1145/3505195
            Issue’s Table of Contents

            Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for third-party components of this work must be honored. For all other uses, contact the owner/author(s).

            Publisher

            Association for Computing Machinery

            New York, NY, United States

            Publication History

            • Published: 20 December 2021
            • Accepted: 1 September 2021
            • Revised: 1 August 2021
            • Received: 1 January 2021
            Published in taas Volume 15, Issue 4

            Permissions

            Request permissions about this article.

            Request Permissions

            Check for updates

            Qualifiers

            • research-article
            • Refereed

          PDF Format

          View or Download as a PDF file.

          PDF

          eReader

          View online with eReader.

          eReader

          HTML Format

          View this article in HTML Format .

          View HTML Format
          About Cookies On This Site

          We use cookies to ensure that we give you the best experience on our website.

          Learn more

          Got it!