What is a software product line (SPL)?

To the best of our knowledge, the product line concept and its characteristics came from the automobile industry. Henry Ford introduced product lines to car manufacturing in 1913, hoping to meet the great demand of the time. Product lines introduced two characteristics: platform and variability. A SPL is defined by (Clements et al. 2005) as "a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission".

Benefits for adopting SPLs

As (Pohl et al. 2005) highlighted with clarity, the benefits and motivation for implementing a SPL are many: reduced maintenance effort, reduced complexity, increased reusability and better cost estimatives are only a few examples of the benefits.

SPL development strategies

The Software Product Line Engineering (SPLE) is the paradigm responsible for the development and study of SPL. Plenty of technologies are used in SPLE as facilitators, making the SPL creation process easier. From these technologies, we can highlight: component-based architecture, software project patterns and the object-oriented paradigm (Van der Linden et al. 2007).

A model for SPLE, illustrated in below was proposed by (Pohl et al. 2005); this model is divided between domain engineering and application engineering, which are described below.

Domain Engineering

Domain Engineering focus on the definition of the SPL scope and common assets generation, from requirements to testing, that compose the SPL platform.

Application Engineering

Common and variable assets developed in the Domain Engineering are combined with specific assets to create a SPL product.

The SPL re-engineering process

In the SPL context, re-engineering is used to transform a system, system family, or system variants into a software product line as illustrated in the figure below. According to Assunção et al. 2017, the SPL re-engineering process is composed of three main phases:

• Detection: during the detection phase, the variabilities and commonalities of the products are identified and extracted through the use of feature retrieval techniques. These characteristics are represented in the form of features. Techniques and methods used during this phase aim to extract data from artifacts, such as class diagrams and source code.

• Analysis: is where the information extracted is used to design and organize the functional features into a variability model. This model is usually a feature model diagram.

• Transformation: is when artifacts linked with these features, such as source code and requirements list, are managed and modified in order to create the SPL.

Variability Management

Regarding the management of SPL variability, there a few strategies that may be adopted. We find however, that using feature models/diagrams allows a good description and understanding of the SPL being re-engineered.

A feature may be defined as an aspect, quality or characteristic of one or more softwares which are visible to the end user (Kang et al. 1990).

FODA

The first known feature notation, the Feature Oriented Domain Analysis (FODA) was proposed by Kang et al. 1990. This notation introduced some concepts that were extended in future notations. Those concepts include: mandatory, alternative and optional features. These three types of features are illustrated in the figure below which represents the feature model of a car.

In this example, the mandatory features must be present in the final product, optional features may be selected or not based on the user desires, and only one alternative feature must be selected from each alternative group.

Generative Programming

Czarnecki et al, 2000 proposed a notation for modeling features called Generative Programming. The main difference from the FODA notation was the introduction of the Or-Features. Or-Features are similar to alternatives, the only difference is the possibility to select more than one Or-feature from each Or-Group to be present in the final product. The image below represents two Or-Group of the GP notation.

Which notation should be used?

There is not a ideal notation to be used, the work presented in Seidl et al. 2016 made a comparison between most of existing feature notations, the work also presents a feature model of feature notations (figure below), allowing the user to create its own notation according to his needs.

We recommend the users of our process to use an already created notation, such as FODA or GP, how to choose them however may not be a simple task. Some factors such as the characteristics (software or hardware) of the systems being re-engineered may impact in the selection of the notation. There are some tools that may be used which may reduce the complexity of creating a feature diagram, FeatureIDE for instance comes with GP notation as default.