Variability In Software Product Lines Research Articles

Family-Based and Product-Based Development of Correct-by-Construction Software Product Lines

Software product lines provide systematic software reuse to implement whole product families efficiently. Therefore, they are increasingly used to handle the growing demand of custom-tailored software variants including safety-critical systems as a domain of application. The requirements for safety-critical systems are generally higher and often demand for behavioral correctness to reduce the risk of dangerous situations in-field. However, the high variability of software product lines is still a big challenge for formal methods in general. We argue that the stepwise development approach correctness-by-construction is beneficial compared to post-hoc verification approaches in dealing with the growing variability. Correctness-by-construction uses a set of refinement rules to incrementally create a correct program from a formal specification. In previous work, we already introduced variational correctness-by-construction to develop correct-by-construction software product lines in a product-based way. In this article, we extend our approach in three directions. First, we propose a feature-based specification technique matching the fine-grained specifications of correctness-by-construction. Second, we propose a family-based development approach to show the correctness of the product line as an alternative to the previous product-based approach. Third, we present our usability-improved tool VarCorC implementing our approach. In the evaluation, we compare the product-based development approach to the family-based approach using two case studies implemented with VarCorC.

Embedding Quality into Software Product Line Variability Artifacts

The success of any software product line development project is closely tied to its domain variability management. Whereas a lot of effort has been put into functional variability management by the SPL community, non-functional variability is considered implicit. The result has been dissatisfaction among clients due to resultant poor quality systems. This work presents an integrated requirement specification template for quality and functional requirements at software product line variation points. The implementation of this approach at the analytical description phase increases the visibility of quality requirements obliging developers to implement them. The approach proposes the use of decision tree classification techniques to support the weaving of functional quality attributes at respective variation points. This work, therefore, promotes software product line variability management objectives by proposing new functional quality artifacts during requirements specification phase. The approach is illustrated with an exemplar mobile phone family data storage requirements case study.

Embedding Quality into Software Product Line Variability Artifacts

The success of any software product line development project is closely tied to its domain variability management. Whereas a lot of effort has been put into functional variability management by the SPL community, non-functional variability is considered implicit. The result has been dissatisfaction among clients due to resultant poor quality systems. This work presents an integrated requirement specification template for quality and functional requirements at software product line variation points. The implementation of this approach at the analytical description phase increases the visibility of quality requirements obliging developers to implement them. The approach proposes the use of decision tree classification techniques to support the weaving of functional quality attributes at respective variation points. This work, therefore, promotes software product line variability management objectives by proposing new functional quality artifacts during requirements specification phase. The approach is illustrated with an exemplar mobile phone family data storage requirements case study.

An Enhanced Scalable Design Approach for Managing Large Scale Variability in Software Product Lines (SPLs)

Variability management remained the main challenge for software product line (SPL) adoption since it needs to be efficiently managed at different levels of the SPL development process (for example, requirements analysis, software design, implementation etc.). With the increase in size and complexity of product lines, and the more holistic systems approach to the design process, managing ever-growing variability models has become a challenge and more difficult to handle. Accordingly, tool support for variability management has been gathering increasing momentum over the last two decades and can be considered a key success factor for developing and maintaining SPLs. This work presents a new tool support that exhibits a number of features that enable it to deal with large models. The new tool adopts the Separation of Concerns design principle by providing multiple perspectives to the model, each conveying a different set of information. It can comprise more than 1000 features particularly, showing the browser (structural) View, which is displayed using a mind-mapping visualisation technique (Hyperbolic trees); the development/Edit view where a new feature can be created either based on existing feature or from scratch; the business view where the information related to the project management, cost/benefit analysis, close/open sets of features and others are presented and the dependency view which is displayed graphically using logic gates.

Model-based security analysis of feature-oriented software product lines

Today's software systems are too complex to ensure security after the fact – security has to be built into systems by design. To this end, model-based techniques such as UMLsec support the design-time specification and analysis of security requirements by providing custom model annotations and checks. Yet, a particularly challenging type of complexity arises from the variability of software product lines. Analyzing the security of all products separately is generally infeasible. In this work, we propose SecPL, a methodology for ensuring security in a software product line. SecPL allows developers to annotate the system design model with product-line variability and security requirements. To keep the exponentially large configuration space tractable during security checks, SecPL provides a family-based security analysis. In our experiments, this analysis outperforms the naive strategy of checking all products individually. Finally, we present the results of a user study that indicates the usability of our overall methodology.

Approach for Managing Variability in Database Schema

The variability in software product lines is well studied, but this study is well neglected at the level of the databases. This insufficiency drives us to work on the modelling and the implementation of the variability in the databases in SPLs. Therefore, our contribution is proposing an approach to manage variability in database schemas. In this approach, we will focus primarily on modelling variability in the conceptual databases schemas at the domain engineering level. We will use model-driven engineering to ensure the different data models transformation to obtain a variable database model. Then, we will deal with application engineering by managing variability at the logical database schema through a configuration to obtain a variable relational database schema. Moreover, we proposed extensions for a metamodel to support the variability notions proposed. We also offer a tool support to apply and automate our approach and to test case studies.

Performance variability in software product lines: proposing theories from a case study

In the software product line research, product variants typically differ by their functionality and quality attributes are not purposefully varied. The goal is to study purposeful performance variability in software product lines, in particular, the motivation to vary performance, and the strategy for realizing performance variability in the product line architecture. The research method was a theory-building case study that was augmented with a systematic literature review. The case was a mobile network base station product line with capacity variability. The data collection, analysis and theorizing were conducted in several stages: the initial case study results were augmented with accounts from the literature. We constructed three theoretical models to explain and characterize performance variability in software product lines: the models aim to be generalizable beyond the single case. The results describe capacity variability in a base station product line. Thereafter, theoretical models of performance variability in software product lines in general are proposed. Performance variability is motivated by customer needs and characteristics, by trade-offs and by varying operating environment constraints. Performance variability can be realized by hardware or software means; moreover, the software can either realize performance differences in an emergent way through impacts from other variability or by utilizing purposeful varying design tactics. The results point out two differences compared with the prevailing literature. Firstly, when the customer needs and characteristics enable price differentiation, performance may be varied even with no trade-offs or production cost differences involved. Secondly, due to the dominance of feature modeling, the literature focuses on the impact management realization. However, performance variability can be realized through purposeful design tactics to downgrade the available software resources and by having more efficient hardware.

Variability Modeling for Customizable Saas Applications

Most of current Software-as-a-Service (SaaS) applications are developed as customizable service-oriented applications that serve a large number of tenants (users) by one application instance. The current rapid evolution of SaaS applications increases the demand to study the commonality and variability in software product lines that produce customizable SaaS applications. During runtime, Customizability is required to achieve different tenants' requirements. During the development process, defining and realizing commonalty and variability in SaaS applications' families is required to develop reusable, flexible, and customizable SaaS applications at lower costs, in shorter time, and with higher quality. In this paper, Orthogonal Variability Model (OVM) is used to model variability in a separated model, which is used to generate simple and understandable customization model. Additionally, Service oriented architecture Modeling Language (SoaML) is extended to define and realize commonalty and variability during the development of SaaS applications.

A Case Study on a Quality Assurance Process for a Scientific Framework

In the quality assurance of scientific frameworks, both the special characteristics of scientific software and the large variability in frameworks must be accounted for. In previous research, the authors developed a process for handling the variability of a framework using software product line variability modeling. They described the design of a quality assurance process for scientific frameworks. This article reports on a case study analyzing the feasibility and acceptance by developers for two parts of the quality assurance process: variability model creation and desk-checking. The main results of the case study are that variability modeling is feasible for the development; however, a different variability modeling language is needed to be able to represent all important aspects. This study found acceptance of variability modeling and desk-checking.

FAMILIAR: A domain-specific language for large scale management of feature models

The feature model formalism has become the de facto standard for managing variability in software product lines (SPLs). In practice, developing an SPL can involve modeling a large number of features representing different viewpoints, sub-systems or concerns of the software system. This activity is generally tedious and error-prone. In this article, we present FAMILIAR a Domain-Specific Language (DSL) that is dedicated to the large scale management of feature models and that complements existing tool support. The language provides a powerful support for separating concerns in feature modeling, through the provision of composition and decomposition operators, reasoning facilities and scripting capabilities with modularization mechanisms. We illustrate how an SPL consisting of medical imaging services can be practically managed using reusable FAMILIAR scripts that implement reasoning mechanisms. We also report on various usages and applications of FAMILIAR and its operators, to demonstrate their applicability to different domains and use for different purposes.

A variability-aware module system

Module systems enable a divide and conquer strategy to software development. To implement compile-time variability in software product lines, modules can be composed in different combinations. However, this way, variability dictates a dominant decomposition. As an alternative, we introduce a variability-aware module system that supports compile-time variability inside a module and its interface. So, each module can be considered a product line that can be type checked in isolation. Variability can crosscut multiple modules. The module system breaks with the antimodular tradition of a global variability model in product-line development and provides a path toward software ecosystems and product lines of product lines developed in an open fashion. We discuss the design and implementation of such a module system on a core calculus and provide an implementation for C as part of the TypeChef project. Our implementation supports variability inside modules from #ifdef preprocessor directives and variable linking at the composition level. With our implementation, we type check all configurations of all modules of the open source product line Busybox with 811~compile-time options, perform linker check of all configurations, and report found type and linker errors -- without resorting to a brute-force strategy.

Model checking software product lines with SNIP

We present SNIP, an efficient model checker for software product lines (SPLs). Variability in software product lines is generally expressed in terms of features, and the number of potential products is exponential in the number of features. Whereas classical model checkers are only capable of checking properties against each individual product in the product line, SNIP exploits specifically designed algorithms to check all products in a single step. This is done by using a concise mathematical structure for product line behaviour, that exploits similarities and represents the behaviour of all products in a compact manner. Specification of an SPL in SNIP relies on the combination of two specification languages: TVL to describe the variability in the product line, and fPromela to describe the behaviour of the individual products. SNIP is thus one of the first tools equipped with specification languages to formally express both the variability and the behaviours of the products of the product line. The paper assesses SNIP and suggests that this is the first model checker for SPLs that can be used outside the academic arena.

Framework for Evolving Software Product Line

Software product line engineering is an approach that develops and maintains families of products while taking advantage of their common aspects and predicted variabilities. Indeed, software product lines (SPL) are an important means for implementing software variability which is the ability of a system to be efficiently extended, changed, customized or configured for use in a particular context. Variability needs in software are constantly increasing because variability moves from mechanics and hardware to software and design decisions are delayed as long as economically feasible. Numerous SPL construction approaches are proposed. Different in nature, these approaches have nevertheless some common disadvantages. We have proceeded to an in-depth analysis of existing approaches for the construction of Software Product Line within a comparison framework in order to identify their drawbacks. We suggest overcoming these drawbacks by an improvement of the tool support for these approaches and for their interactivity with their users. We propose to study a particular software product line which is ERP as experimentation. SPL engineering is considered as unavoidable approaches to support reuse in systems development, as a viable and important software development paradigm. It allows to companies to realize a real improvements in time to market, cost, productivity, quality and flexibility. In fact, SPL techniques are explicitly capitalizing on commonality. They try formally to manage the variations of the products in the product line. To understand the problem of variability in software product lines, we've studied a number of references to provide an overview of the current activities in this area. The reference (28) presents a model for product line variability. They try to model variability by feature model, which describes functional and nonfunctional requirements of the product line. This feature model structures the common and variable features. The architectural variability model is described by architectural variation points. The reference (3) presents the variability as the key to software reuse and he asserts that variability can be associated with different abstraction levels of development (from requirement specification to running code). They propose a

Assessing the maintainability of software product line feature models using structural metrics

A software product line is a unified representation of a set of conceptually similar software systems that share many common features and satisfy the requirements of a particular domain. Within the context of software product lines, feature models are tree-like structures that are widely used for modeling and representing the inherent commonality and variability of software product lines. Given the fact that many different software systems can be spawned from a single software product line, it can be anticipated that a low-quality design can ripple through to many spawned software systems. Therefore, the need for early indicators of external quality attributes is recognized in order to avoid the implications of defective and low-quality design during the late stages of production. In this paper, we propose a set of structural metrics for software product line feature models and theoretically validate them using valid measurement-theoretic principles. Further, we investigate through controlled experimentation whether these structural metrics can be good predictors (early indicators) of the three main subcharacteristics of maintainability: analyzability, changeability, and understandability. More specifically, a four-step analysis is conducted: (1) investigating whether feature model structural metrics are correlated with feature model maintainability through the employment of classical statistical correlation techniques; (2) understanding how well each of the structural metrics can serve as discriminatory references for maintainability; (3) identifying the sufficient set of structural metrics for evaluating each of the subcharacteristics of maintainability; and (4) evaluating how well different prediction models based on the proposed structural metrics can perform in indicating the maintainability of a feature model. Results obtained from the controlled experiment support the idea that useful prediction models can be built for the purpose of evaluating feature model maintainability using early structural metrics. Some of the structural metrics show significant correlation with the subjective perception of the subjects about the maintainability of the feature models.

Managing Variability in Software Product Lines

A software product line (SPL) is a set of software-intensive systems that share a common set of features for satisfying a particular market segment needs. SPLs can reduce development costs, shorten time-to-market, and improve product quality by reusing core assets for project-specific customizations. To enable reuse on a large scale, SPL engineering (SPLE) identifies and manages commonalities and variations across a set of system artifacts such as requirements, architectures, code components, and test cases.Variability management (VM) is a fundamental SPLE activity that explicitly represents software artifact variations for managing dependencies among variants and supporting their instantiations throughout the SPL life cycle. Managing variability involves extremely complex and challenging tasks, which must be supported by effective methods, techniques, and tools.

Evaluating formal properties of feature diagram languages

Feature diagrams (FDs) are a family of popular modelling languages, mainly used for managing variability in software product lines. FDs were first introduced by Kang et al. as part of the feature-oriented domain analysis (FODA) method back in 1990. Since then, various extensions of FODA FDs were devised to compensate for purported ambiguity and lack of precision and expressiveness. Recently, the authors surveyed these notations and provided them with a generic formal syntax and semantics, called free feature diagrams (FFDs). The authors also started investigating the comparative semantics of FFD with respect to other recent formalisations of FD languages. Those results were targeted at improving the quality of FD languages and making the comparison between them more objective. The previous results are recalled in a self-contained, better illustrated and better motivated fashion. Most importantly, a general method is presented for comparative semantics of FDs grounded in Harel and Rumpe's guidelines for defining formal visual languages and in Krogstie et al.'s semiotic quality framework. This method being actually applicable to other visual languages, FDs are also used as a language (re)engineering exemplar throughout the paper.

Modeling variability in software product lines with the variation point model

A major challenge for software reuse is developing components that can be reused in several applications. This paper describes a systematic method for providing components that can be extended through variation points, as initially specified in the software requirements. Allowing the reuser or application engineer to extend components at pre-specified variation points creates a more flexible set of components. The existing variation point methods do not provide enough design detail for the reuser. This paper introduces a method called the Variation Point Model (VPM), which models variation points at the design level, beginning with the common requirements. The product line approach provides a systematic approach for software reuse. A challenge with the product line approach is to model the variability between the core assets and the applications. This paper describes the VPM and how it is used for modeling four different approaches to variability, modeling variability using parameterization, modeling variability using information hiding, modeling variability using inheritance, and modeling variability using variation points. VPM allows a reuser or application engineer to extend components at pre-specified variation points. For this to be possible, a variation point must be modeled such that the reuser has enough knowledge to build a variant.