SEPLMay 27

Generalized Software Product Line Extraction

arXiv:2605.2898922.7h-index: 4
AI Analysis

This work addresses the tight coupling of SPL extraction to specific technological spaces and IDEs, aiming to enable reuse and adoption of heterogeneous development environments, but the contribution is incremental as it combines existing concepts.

The authors propose a general, workbench-agnostic protocol for extracting feature models from software artifacts and deriving software products, implemented with a prototypical architecture using Neverlang, Java, Go, Prolog, and JavaScript. The approach is demonstrated on language product lines, showing applicability while preserving workbench-agnosticism.

Software product line (SPL) engineering has been successfully applied to software development by obtaining software systems as compositions of modular features. Existing approaches to SPL engineering, however, are typically bound to a specific technological space (such as, a programming language and a composer) and integrated development environment (IDE), and rely on extraction mechanisms that make strong assumptions on the underlying technological space. This tight coupling hinders reuse, evolution, and adoption of heterogeneous development environments. We propose a general, workbench-agnostic protocol for extracting feature models from existing software artifacts and for configuring and deriving software products. The protocol follows a bottom-up approach based on lightweight dependency units called "atoms", and organizes the extraction and configuration process around an SPL server (workbench-independent) and an SPL client with a workbench-specific backend and a generic frontend. The protocol makes few assumptions on the underlying software artifacts and is therefore applicable to varied SPLs. The applicability of this approach is presented through a prototypical implementation of the architecture in which several subsystems interact and can be swapped freely without affecting the others. In particular, we focus on the application of such a protocol in the context of language product lines (LPLs), demonstrating its applicability to concrete scenarios while preserving workbench-agnosticism. From bottom to top, the implementation comprises: Neverlang language artifacts, a Java SPL client backend, an agnostic and reusable SPL server written in Go and Prolog, and a JavaScript SPL client frontend.

Foundations

The foundational work for this paper's niche, ranked by how specifically the neighbourhood builds on it — not by global fame.

Your Notes