[Paper Review] IsiSPL: Toward an Automated Reactive Approach to build Software Product Lines

Nicolas Hlad, Abdelhak-Djamel Seriai+1 more|arXiv (Cornell University)|Jul 1, 2021

Advanced Software Engineering Methodologies30 references4 citations

TL;DR

This paper proposes isiSPL, a reactive, automated approach for building and maintaining Software Product Lines (SPLs) through quasi-automatic integration of new product artefacts and configurable code generation. It enables developers to maintain a white-box SPL via annotated source code and formal context analysis, achieving 100% accurate product reproduction in validation with ArgoUML-SPL and Sudoku-SPL.

ABSTRACT

Over the past decades, Software Product Lines (SPLs) have demonstrated the benefits of systematic reuse to increase software development productivity and software product quality. Of the three adoption approaches, i.e. extractive, proactive and reactive, the reactive approach seems the most suitable for software development in practice. The strength of this approach is that it remains close to classical software development practices. In fact, it avoids a complete analysis of the business domain and its variability (i.e. proactive approach), and avoids requiring a set of product variants that covers this domain (i.e. extractive approach). Nevertheless, despite these advantages, we believe that the main obstacle of the reactive approach adoption is the lack of automation of its re-engineering process. This paper proposes isiSPL: a reactive-based approach that facilitates both construction and maintenance of an SPL. The construction of the SPL is based on a quasi-automatic process. The maintenance of the SPL can be made on a white-box SPL implementation, generated by isiSPL. isiSPL is based on two steps: first, the identification and integration of the artefacts of a newly created product into the structure of the SPL; second, the selection of a set of artefacts and their composition to generate a new product that can either partially or completely meet the requirements provided for a product intended by a developer. We have implemented isiSPL and validated its integration and generation using the two different sets of products from ArgoUML-SPL and Soduko-SPL.

Motivation & Objective

• Address the low adoption of Software Product Lines (SPLs) due to challenges in construction and maintenance, particularly in industrial settings.
• Overcome the limitations of proactive and extractive SPL approaches by proposing a reactive, iterative method that aligns with standard software development practices.
• Facilitate both SPL construction and long-term maintenance by enabling developers to work on a transparent, annotated SPL implementation.
• Provide a non-invasive, automated pipeline for integrating new product artefacts and generating new products based on requirements.
• Enable both product managers and developers to use the same variability model and annotated code for configuration and evolution.

Proposed method

• Apply formal context analysis (FCA) to extract variability relationships—implication, mutual exclusion, co-occurrence, and common/optional artefacts—from source code and artefacts.
• Represent the SPL as a white-box implementation using annotated code, where each statement is treated as a first-class artefact, enabling direct developer manipulation.
• Build an artefact tree per source file, which is pruned during product generation to produce only the required artefacts for a specific product.
• Integrate new product artefacts into the SPL structure through a quasi-automatic process that preserves existing variability constraints.
• Generate new products by selecting and composing relevant artefacts based on developer-provided requirements, ensuring correctness via the formal variability model.
• Use a two-phase process: (1) integration of new artefacts into the SPL, and (2) configuration and generation of a new product from selected artefacts.

Experimental results

Research questions

• RQ1 How can a reactive SPL approach be automated to reduce manual effort in integration and generation while maintaining correctness?
• RQ2 What techniques enable a white-box SPL implementation that supports both product generation and developer-driven maintenance?
• RQ3 How can variability relationships (e.g., implication, mutual exclusion) be automatically discovered from source code and artefacts without requiring prior feature models?
• RQ4 Can isiSPL achieve 100% accurate product reproduction using only annotated code and formal context analysis?
• RQ5 Can isiSPL support both product managers and developers in SPL configuration and evolution through a unified, maintainable representation?

Key findings

• isiSPL achieves 100% accurate product reproduction in validation with ArgoUML-SPL and Sudoku-SPL, indicating no loss or error during integration and generation.
• The use of annotated code as a first-class representation enables direct, intuitive maintenance of the SPL by developers, overcoming the black-box limitations of prior extractive tools.
• Formal context analysis successfully captures key variability relationships (implication, mutual exclusion, co-occurrence) at the artefact level, forming a solid basis for configuration validation.
• isiSPL’s two-phase process—artefact integration followed by configurable generation—proves effective and non-invasive in real-world SPL use cases.
• By treating each statement as an individual artefact, isiSPL avoids code duplication and enables fine-grained control over product composition.
• Compared to ECCO and But4Reuse, isiSPL provides a more maintainable, white-box SPL representation that supports both evolution and configuration.