A copy of this work was available on the public web and has been preserved in the Wayback Machine. The capture dates from 2020; you can also visit <a rel="external noopener" href="https://hal.archives-ouvertes.fr/hal-02952741/file/Evolution_in_Dynamic_Software_Product_Lines.pdf">the original URL</a>. The file type is <code>application/pdf</code>.
<i title="ACM Press">
<a target="_blank" rel="noopener" href="https://fatcat.wiki/container/kaprbx3mnjhm5i3ju6teggzole" style="color: black;">Proceedings of the 19th International Conference on Software Product Line - SPLC '15</a>
Many software systems today provide support for adaptation and reconfiguration at runtime, in response to changes in their environment. Such adaptive systems are designed to run continuously and may not be shut down for reconfiguration or maintenance tasks. The variability of such systems has to be explicitly managed, together with mechanisms that control their runtime adaptation and reconfiguration. Dynamic software product lines (DSPLs) can help to achieve this. However, dealing with<span class="external-identifiers"> <a target="_blank" rel="external noopener noreferrer" href="https://doi.org/10.1145/2791060.2791101">doi:10.1145/2791060.2791101</a> <a target="_blank" rel="external noopener" href="https://dblp.org/rec/conf/splc/QuintonRVGB15.html">dblp:conf/splc/QuintonRVGB15</a> <a target="_blank" rel="external noopener" href="https://fatcat.wiki/release/szlhakchlzbozlx3mqu2x7ylb4">fatcat:szlhakchlzbozlx3mqu2x7ylb4</a> </span>
more »... is particularly challenging in a DSPL, as changes made at runtime can easily lead to inconsistencies. This paper describes the challenges of evolving DSPLs using an example cyber-physical system for home automation. We discuss the shortcomings of existing work and present a reference architecture to support DSPL evolution. To demonstrate its feasibility and flexibility, we implemented the proposed reference architecture for two different DSPLs: the aforementioned cyber-physical system, which uses feature models to describe its variability, and a runtime monitoring infrastructure, which is based on decision models. To assess the industrial applicability of our approach, we also implemented the reference architecture for a real-world DSPL, an automation software system for injection molding machines. Our results provide evidence on the flexibility, performance and industrial applicability of our approach. 1 runtime, which can easily lead to inconsistencies among running components. Specifically, it is challenging to maintain the consistency between the problem space and the solution, the variability model and the running system, as well as the runtime adaptation mechanisms. Many approaches have been proposed for managing the evolution of software product lines 5 , ranging from verification techniques to ensure consistent evolution, to model-based frameworks dedicated to the evolution of feature-based variability models 6 . For example, an interesting research thread proposes evolution templates for co-evolving a variability model and related software artifacts 3,7,8 . Model-checking approaches are used to guarantee the consistency of a variability model after evolution 9,10 . Furthermore, approaches for comparing the set of possible products before and after the evolution of a product line have been proposed 11,12 . These approaches, however, are limited regarding support for DSPL evolution, as they focus on guaranteeing the consistency of the evolved DSPL variability model but fail to ensure that the evolution is consistent with the DSPLs actual implementation and adaptation mechanisms. FIGURE 1 Overview of different types of changes (manual, or automated) and the respective triggers (triggered by a human, or by the environment) that can have an impact on the system. Certain scenarios are part of other research areas as well, but a DSPL needs to consider multiple different scenarios alongside with the PL variability model. There are three evolution scenarios in a DSPL context (cf. Fig. 1) . First, the change and the related adaptation are triggered manually, e.g., when updating the code base. Second, the change can be performed manually, while the adaptation is automated e.g., in a build automation or DevOps process. Finally, both the change and the adaptation can be triggered automatically, which is the case for self-adaptive systems where evolving environment implies a reconfiguration of the system. Besides the area of (dynamic) software product lines, considerable effort has been made in the domain of (self-)adaptive systems to efficiently adapt to changes in the environment, or recover from errors introduced in a running system. Examples range from autonomous vehicles or robots 13 , to self-managing and self-adapting web services and IoT systems 14 . Self-adaptive systems (often using a MAPE-K 15 approach) react to changes in the environment to, for example, optimize throughput and reduce resource consumption by updating the configuration or architecture of the system. Automated build and deployment solutions (DevOps) on the other hand are triggered by (manual) changes in the program's source code and ensuring proper re-deployment of the system, sometimes in an incremental manner and/or at runtime. However, while these solutions provide important contributions to (self)-adaptivity and self-repair of systems at runtime, what sets them apart from a DSPL is their lack of explicitly modeling the variability of the system. This is important as the the running system must to be consistent with its counterpart described, for example, in a feature model (cf. Fig. 1 ). Existing DSPL approaches are typically based on ad-hoc adaptation mechanisms that need to be maintained manually to keep them consistent with the problem and solution spaces during evolution 16 . Proper evolution support is, however, crucial to guarantee the consistency of the DSPL and of the (potential) adaptations of the running system 17 . Furthermore, existing approaches typically only support one particular variability management approach and are not flexible enough to allow their use in different domains and for different types of systems, using diverse implementation techniques. A variability model-agnostic approach is still missing that facilitates the evolution of problem and solution spaces, together with the runtime adaptation mechanisms, and also checks the consistency of the resulting products. Based on our work on runtime reconfiguration of monitoring systems 18,19 and on the dynamic evolution of the architecture of DSPLs 20 , we sketched some general issues related to DSPL evolution in a short paper 21 . The research described here builds on this short paper. Specifically, we developed a flexible approach to support DSPL evolution based on a reference architecture, that can be implemented to support the evolution of a concrete (type of) DSPL. The reference architecture describes the capabilities needed for detecting changes made to running systems, for automating the update of variability models, and for detecting inconsistencies among all the relevant elements of a DSPL. Specifically, our reference architecture guides the development of change detection, model update, and consistency checking solutions to support evolution in a concrete DSPL. The key contributions of this paper are (i) a flexible approach, based on a reference architecture, to implement evolution support for a DSPL, (ii) implementations of the reference architecture for two different DSPLs in different domains -one cyber-physical system and one runtime monitoring system, both using different means for variability management, (iii) an evaluation of the feasibility and performance of our approach by
<a target="_blank" rel="noopener" href="https://web.archive.org/web/20201108174725/https://hal.archives-ouvertes.fr/hal-02952741/file/Evolution_in_Dynamic_Software_Product_Lines.pdf" title="fulltext PDF download" data-goatcounter-click="serp-fulltext" data-goatcounter-title="serp-fulltext"> <button class="ui simple right pointing dropdown compact black labeled icon button serp-button"> <i class="icon ia-icon"></i> Web Archive [PDF] <div class="menu fulltext-thumbnail"> <img src="https://blobs.fatcat.wiki/thumbnail/pdf/3f/42/3f42ec19960d67d90cebd7ca265bf65132ea426d.180px.jpg" alt="fulltext thumbnail" loading="lazy"> </div> </button> </a> <a target="_blank" rel="external noopener noreferrer" href="https://doi.org/10.1145/2791060.2791101"> <button class="ui left aligned compact blue labeled icon button serp-button"> <i class="external alternate icon"></i> acm.org </button> </a>