Guiding the evolution of product-line configurations

Nieke, Michael; Sampaio, Gabriela; Thüm, Thomas; Seidl, Christoph; Teixeira, Leopoldo; Schaefer, Ina

doi:10.1007/s10270-021-00906-w

Cited by 11 publications

(4 citation statements)

References 56 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…It consists only of bijections between the algorithms' code and the corresponding feature. Analyzing the impact of the evolution operations on past configurations is part of our perspectives inspired by the preliminary work of Nieke et al [36].…”

Section: From the Requirements To The Spl Paradigmmentioning

confidence: 99%

Evolvable SPL management with partial knowledge

Amraoui

Blay–Fornarino

Collet

et al. 2022

Proceedings of the 26th ACM International Systems and Software Product Line Conference - Volume A

View full text Add to dashboard Cite

In Machine Learning (ML), the resolution of anomaly detection problems in time series presents a great diversity of practices as it can correspond to many different contexts. These practices cover both grasping the business problem and designing the solution itself. By practice, we designate explicit and implicit steps toward resolving a problem, while a solution corresponds to a combination of algorithms selected for their performance on a given problem. Two related issues arise. The first one is that the practices are individual and not explicitly mutualized. The second one is that choosing one solution over another is all the more difficult to justify because the space of solutions and the evaluation criteria are vast and evolve rapidly with the advances in ML. To solve these issues and tame the evolving diversity in ML, a Software Product Line (SPL) approach can be envisaged to represent the variable set of solutions. However, this requires characterizing an ML business problem through an explicit set of criteria and justifying one ML solution over all others. The resolution of anomaly detection problems is thus different from finding the best configuration workflow from past configurations but lies more in guiding the configuration towards a solution that may never have been studied before. This paper proposes an SPL approach that capitalizes on past practices by exploiting a variability-aware representation to detect new criteria and constraints when practices adopt different solutions to seemingly similar problems. We report on the evaluation of our approach using a set of applications from the literature and an ML software company. We show how the analysis of practices makes it possible to consolidate the knowledge contained in the SPL.

show abstract

Section: From the Requirements To The Spl Paradigmmentioning

confidence: 99%

Evolvable SPL management with partial knowledge

Amraoui

Blay–Fornarino

Collet

et al. 2022

Proceedings of the 26th ACM International Systems and Software Product Line Conference - Volume A

View full text Add to dashboard Cite

show abstract

“…Thus, updating configurations after SPL evolution is required to keep them up-to-date. A method, such as guided configuration evolution [16], is required to define configuration update operations by domain engineers who know how configurations are affected by a change.…”

Section: Degree Of Variability (Obs 7)mentioning

confidence: 99%

Experiences with Constructing and Evolving aSoftware Product Line with Delta-Oriented Programming

Nieke

Hoff

Schaefer

et al. 2022

Proceedings of the 16th International Working Conference on Variability Modelling of Software-Intensive Systems

Self Cite

View full text Add to dashboard Cite

A Software Product Line (SPL) captures families of closely related software variants. The configuration options of an SPL are represented by features. Typically, SPLs are developed in a featurecentric manner and, thus, require different development methods and technologies from developing software products individually. For developers of single systems, this means a shift in paradigm and technology. Especially with invasive variability realization mechanisms, such as Delta-Oriented Programming (DOP), centering development around configurable features realized via source code transformation is commonly expected to pose an obstacle, but concrete experience reports are lacking. In this paper, we investigate how DOP and cutting-edge SPL development tools are picked up by non-expert developers. To this end, we report on our experiences from a student capstone SPL development project. Our results show that participants find easy access to SPL development concepts and tools. Based on our observations and the participants' practices, we define guidelines for developers using DOP. CCS CONCEPTS• Software and its engineering → Software product lines; Software evolution.

show abstract

“…At the industrial scale, product line models may include hundreds of features (Shahin et al, 2021). However, in some cases, they could be larger than expected and may contain thousands of features such as the automotive product line model cited in the work of Pett et al (2019), and the linux kernel which is one of the largest software product lines currently available, reaching 21, 000 features (Nieke et al, 2022). In such cases, the number of potential configurations can be large too.…”

Section: Introductionmentioning

confidence: 99%