## 6 Discussion
### Interpreting Answers to RQs and PQs
#### 6.1.1 Interpreting Answers to RQs  
Interpreting Answers for RQ1  
According to the collected evidence for answering RQ1, the two main approaches to managing reconfigurations are: (i) closed dynamic variability (38%) and (ii) open dynamic variability (57%). Most authors present constraints on modeling variability for closed dynamic variability in either context-aware feature or objective models. Both seek to model possible adaptation rules for the system [24; 48]. Also, there are proposals related to optimization models, for example, a prediction module to plan system adaptations [49], and reasoning engines [50], such as a SAT solver to check the satisfaction of the required reconfiguration concerning the feature model, seeking to analyze if any rule integrated into the model does not break. In the case of open dynamic variability, there are several proposals; where most of them are based on learning future reconfigurations through machine learning [7; 39; 40; 51; 52; 53; 54; 55; 56; 57; 58; 59; 60; 61], or some variant through software agents, generating Multi-Agent Systems Product Lines (MAS-PL) environments to manage the system through autonomous agents [62; 63]. There are proposals associated with modeling constraints, such as [64], which proposes an approach to unify design and runtime adaptation based on aspect-oriented modeling through a metamodel of unified aspects of a platform that performs processes to achieve design and runtime adaptations. The approach associated with collaborative features, proposes a family-based analysis that simulates all product variants of a DSPL simultaneously, at runtime, on recent environmental inputs to obtain an estimate of the quality of service that each variant of the product would have had if it had been run at runtimeref [65]. Finally, the Figure 17 shows an increase in approaches based on open dynamic variability. Also, we can observe a decrease in proposals based on closed dynamic variability. This decrease could be due to the limitations generated by limiting the number of reconfigurations for self-adaptive systems. Interpreting Answers for RQ2  
According to the evidence provided by RQ2, most authors use their own methodology to manage a DSPL environment (61%). Most of these proposals are based on constraints mentioned in the variability modeling, using context-aware feature models, optimization models, or adaptation rules, among others. For example, the DAMASCo proposal seeks to provide reconfiguration to support specific runtime failure situations, grouping services into families that facilitate the selection and use of similar services in case of failures [66]. There are also DevOps-based architectures for reconfiguring self-adaptive systems [67]. The second majority of the work is in the MAPE-K control loop (25%). [PERSON] presents variations of the control loop, including a metamodel to express the variability between the SPL and the self-adaptive system [68]. An instantiated model includes the business requirements, context, and adaptation logic. [PERSON] designs the variability of SPLs with the common variability language (CVL), which communicates with an architectural tool diagram similar to the UML component diagram, which communicates with theThe above classification identifies two main approaches for managing variability: the MAPE-K control loop and FMs. As mentioned in Section 5.1.2, the MAPE-K control loop corresponds to an autonomous control loop. Its main objective is to propose a framework to monitor, analyze, plan and execute reconfigurations in the software, storing the log of each step in a knowledge node, promoting the linkage with Machine Learning techniques. Runtime variability management techniques associated with FMs have several variations, with several approaches having the same goal of managing the runtime variability of a system. Most of these systems store within the models specific variation points that the software can assume.