Consistency checking for the evolution of cardinality-based feature models

Quinton, Clément; Pleuss, Andreas; Berre, Daniel Le; Duchien, Laurence; Botterweck, Goetz

doi:10.1145/2648511.2648524

Cited by 20 publications

(14 citation statements)

References 23 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…In [7], we carried out a systematic review about model defects that may appear in software product lines during their evolution. As a result of this review, we listed the different model defects addressed in literature, such as inconsistency [1]- [3], incorrectness [6], ambiguity [4], and unsafety [5]. A complementary study based on field experience helped us decide to focus on a specific defect, which is feature duplication.…”

Section: Background and Motivationmentioning

confidence: 99%

See 1 more Smart Citation

Detecting Feature Duplication in a CRM Product Line

Khtira¹

2020

JSW

View full text Add to dashboard Cite

Many defects may arise during software product lines such as inconsistency, incorrectness and ambiguity. In our work, we are interested in a specific defect, which is duplication in features since it has received little attention in literature. In previous work, we proposed a conceptual framework that describes the different processes to follow in order to produce duplication-free feature models. We also implemented a tool support called FDDetector based on this framework with the aim of detecting and correcting duplication introduced in feature models by new product line evolutions. To evaluate this tool, we have adopted a CRM product line as a case study. In this paper, we explain the motivations behind choosing a case study from the CRM field, and we present the results of a test performed on an evolution related to this product line.

show abstract

Section: Background and Motivationmentioning

confidence: 99%

“…Duplication is among many other defects (e.g. inconsistency [1]- [3], ambiguity [4], unsafety [5], incorrectness [6]) that may occur in software product lines during their evolution [7]. This defect consists of having the same element repeated many times in a software artefact.…”

Section: Introductionmentioning

confidence: 99%

Detecting Feature Duplication in a CRM Product Line

Khtira¹

2020

JSW

View full text Add to dashboard Cite

show abstract

“…In contrast, our methodology addresses evolution of the FM itself. Quinton et al [16] mainly consider the impact of evolution on cardinality consistencies and, thus, the consistency of the FM. Gamez et al [10] automatically create new configurations of evolved FMs and they measure the change impact by means of a difference between the old configuration and the new configuration.…”

Section: Related Workmentioning

confidence: 99%

Guaranteeing Configuration Validity in Evolving Software Product Lines

Nieke

Seidl

Schuster

2016

Proceedings of the Tenth International Workshop on Variability Modelling of Software-Intensive Systems

View full text Add to dashboard Cite

Software Product Lines (SPLs) are an approach to capture families of closely related software systems in terms of commonalities and variabilities where individual variants are defined by configurations of selected features. Specific (partial) configurations may be of particular importance to SPL manufacturers, e.g., if they are very popular or used by major customers. SPLs are subject to evolution, which may inadvertently break existing configurations, e.g., if a previously selected feature does no longer exist. This is problematic as it may delay or completely prevent creation of previously existing important variants causing monetary loss and customer dissatisfaction. In this paper, we present a method to lock specific configurations to ensure their validity during evolution of the SPL. For this, we present Temporal Feature Models (TFMs) and dedicated evolution operations as a semantic-enriched first-class notion for evolution of feature models, which we use to assess the impact on existing configurations. Using the presented method, it is possible to guarantee that locked configurations remain valid during SPL evolution and make statements on which part of the evolution would break the configurations. CCS Concepts •Software and its engineering → Software notations and tools; Software evolution;

show abstract

“…Analyses [2] can be used after evolution to detect potential anomalies such as dead or false-optional features (see Table 1). Additional analyses are required to check the consistency of the variability model with respect to cardinalities [14]. Existing approaches and tools can also be applied to check the consistency of the solution space, where similar anomalies can arise [12].…”

Section: Intraspatial Consistencymentioning

confidence: 99%

“…We are currently working on the Updater UI, the Consistency Checker, and the Inconsistency Viewer. For the latter two we adapt the approach proposed in [14] and combine it with the consistency checker described in [19]. Our current prototype already supports identifying problem space elements (decisions) without relation to any asset and resolves these inconsistencies automatically.…”

Section: Solution Architecturementioning

confidence: 99%

Evolution in dynamic software product lines

Quinton

Rabiser

Vierhauser

et al. 2015

Proceedings of the 19th International Conference on Software Product Line

Self Cite

View full text Add to dashboard Cite

In many domains systems need to run continuously and cannot be shut down for reconfiguration or maintenance tasks. Cyber-physical or cloud-based systems, for instance, thus often provide means to support their adaptation at runtime. The required flexibility and adaptability of systems suggests the application of Software Product Line (spl) principles to manage their variability and to support their reconfiguration. Specifically, Dynamic Software Product Lines (dspl) have been proposed to support the management and binding of variability at runtime. While spl evolution has been widely studied, it has so far not been investigated in detail in a dspl context. Variability models that are used in a dspl have to co-evolve and be kept consistent with the systems they represent to support reconfiguration even after changes to the systems at runtime. In this short paper we present a classification of the required operations for jointly evolving problem and solution space in a dspl. We analyze the impact of such operations on the consistency of a dspl and propose an approach to deal with the described issues. We describe a runtime monitoring system used in the domain of industrial automation software as an example of a dspl evolving at runtime to motivate and explain our work.

show abstract

Consistency checking for the evolution of cardinality-based feature models

Cited by 20 publications

References 23 publications

Detecting Feature Duplication in a CRM Product Line

Detecting Feature Duplication in a CRM Product Line

Guaranteeing Configuration Validity in Evolving Software Product Lines

Evolution in dynamic software product lines

Contact Info

Product

Resources

About