Consistency-preserving evolution planning on feature models

Abstract

A software product line (SPL) enables large-scale reuse in a family of related software systems through configurable features. SPLs represent a long-term investment so that their ongoing evolution becomes paramount and requires careful planning. While existing approaches enable to create an evolution plan for an SPL on feature-model (FM) level, they assume the plan to be rigid and do not support retroactive changes. In this paper, we present a method that enables to create and retroactively adapt an FM evolution plan while preventing undesired impacts on its structural and logical consistency. This method is founded in structural operational semantics and linear temporal logic. We implement our method using rewriting logic, integrate it within an FM tool suite and perform an evaluation using a collection of existing FM evolution scenarios. CCS CONCEPTS• Software and its engineering → Software product lines; Software evolution; Software notations and tools.

Modular Soundness Checking of Feature Model Evolution Plans

“…It is a collaboration between the University of Oslo and the German university Technische Universität Braunschweig. The overarching goal of the project is to create methodology for the long-term evolution planning of SPLs, and we have published a paper [7] giving methods for verifying soundness of feature model evolution plans (FMEPs), as well as a framework for expressing and verifying logical relationships and dependencies between the spatial and temporal components of the plan. This soundness verification method lets us detect paradoxes in a feature model evolution plan, and has been integrated into the SPL planning tool DarwinSPL 1 to make intermediate plan change possible; that is, modifying an earlier stage of the plan instead of adding to the latest stage.…”

“…Such a change is exemplified in Figure 1.1, where the plan is changed by adding B at time 3. In the method created in [7], the process of changing the plan and verifying the change happens in the following way: 1) Introduce B at time 3…”

“…Although we have formalized the feature model evolution plan in our previous work [7], change to such a plan has not been addressed formally. The goal of this thesis is to formalize plan change and create an analysis method which verifies it, leveraging the knowledge that a change affects only parts of the plan.…”

“…The formal structural requirements (well-formedness rules) to a feature model as specified in [7], are WF1 A feature model has exactly one root feature.…”

“…We have published a semantics for these edit operations along with a formal definition of a feature model, letting us formally define a sound plan [7]. The semantics is formalized as a set of structural operational semantic rules, detailing exactly which conditions must be fulfilled for an operation to be applied, and the way to construct the resulting feature model after applying it.…”