Product Line Variability Research Articles

Systematic Evaluation of Software Product Line Architectures

The architecture of a software product line is one of its most important artifacts as it represents an abstraction of the products that can be generated. It is cru- cial to evaluate the quality attributes of a product line architecture in order to: increase the productivity of the product line process and the quality of the products; provide a means to understand the potential behavior of the products and, consequently, decrease their time to market; and, improve the handling of the product line variability. The evaluation of product line architecture can serve as a basis to analyze the managerial and economical values of a product line for software managers and architects. Most of the current research on the evaluation of product line architecture does not take into account metrics directly obtained from UML models and their variabilities; the met- rics used instead are dif fi cult to be applied in general and to be used for quantitative analysis. This paper presents a Systematic Evaluation Method for UML-based Soft- ware Product Line Architecture, the SystEM-PLA. SystEM-PLA differs from current research as it provides stakeholders with a means to: (i) estimate and analyze potential products; (ii) use predefined basic UML-based metrics to compose quality attribute metrics; (iii) perform feasibility and trade-off analysis of a product line architecture with respect to its quality attributes; and, (iv) make the evaluation of product line architecture more flexible. An example using the SEI's Arcade Game Maker (AGM) product line is presented as a proof of concept, illustrating SystEM-PLA activities. Metrics for complexity and extensibility quality attributes are defined and used to perform a trade-off analysis.

Formal Modeling of Product-Line Variant Requirements

Formal verification of variant requirements has gained much interest in the software product line (SPL) community. Feature diagrams are widely used to model product line variants. However, there is a lack of precisely defined formal notation for representing and verifying such models. This paper presents an approach to modeling and verifying SPL variant feature diagrams using first-order logic. It provides a precise and rigorous formal interpretation of the feature diagrams. Logical expressions can be built by modeling variants and their dependencies by using propositional connectives. These expressions can then be validated by any suitable verification tool. A case study of a Computer Aided Dispatch (CAD) system variant feature model is presented to illustrate the verification process.

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.

Defining variability in activity diagrams and Petri nets

Control flow models, such as UML activity diagrams or Petri nets, are widely accepted modeling languages used to support quality assurance activities in single system engineering as well as software product line (SPL) engineering. Quality assurance in product line engineering is a challenging task since a defect in a domain artifact may affect several products of the product line. Thus, proper quality assurance approaches need to pay special attention to the product line variability. Automation is essential to support quality assurance approaches. A prerequisite for automation is a profound formalization of the underlying control flow models and, in the context of SPLs, of the variability therein.In this paper, we propose a formal syntax and semantics for defining variability in Petri nets. We use these extended Petri nets as a foundation to formally define variability in UML activity diagrams; UML activity diagrams serve as a basis for several testing techniques in product line engineering. We illustrate the contribution of such a formalization to assurance activities in product line engineering by describing its usage in three application examples.

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

Analyzing evolution of variability in a software product line: From contexts and requirements to features

Context In the long run, features of a software product line (SPL) evolve with respect to changes in stakeholder requirements and system contexts. Neither domain engineering nor requirements engineering handles such co-evolution of requirements and contexts explicitly, making it especially hard to reason about the impact of co-changes in complex scenarios. Objective In this paper, we propose a problem-oriented and value-based analysis method for variability evolution analysis. The method takes into account both kinds of changes (requirements and contexts) during the life of an evolving software product line. Method The proposed method extends the core requirements engineering ontology with the notions to represent variability-intensive problem decomposition and evolution. On the basis of problemorientation, the analysis method identifies candidate changes, detects influenced features, and evaluates their contributions to the value of the SPL. Results and Conclusion The process of applying the analysis method is illustrated using a concrete case study of an evolving enterprise software system, which has confirmed that tracing back to requirements and contextual changes is an effective way to understand the evolution of variability in the software product line.

FORMS: Feature-Oriented Reverse Engineering-based Middleware Specialization for Product-Lines

Supporting the varied software feature requirementsof multiple variants of a software product-line while promotingreuse, forces product line engineers to use general-purpose and feature-rich middleware platforms. However, each product variant now incurs memory footprint and performance overhead due to the feature-richness of the middleware along with the increased cost of its testing and maintenance. To address this tension, this paper presents FORMS ( F eature- O riented R everse E ngineering for M iddleware S pecialization), which is a framework to automatically specialize general-purpose middleware for product-line variants. FORMS provides a novel model-based approach to map product-line variant-specific feature requirements to middleware-specific features, which in turn are used to reverse engineer middleware source code and transform it to specialized forms resulting in vertical middleware decompositions. Empirical results evaluating memory footprint reductions (40%) and feature reductions (60-76%) are presented along with qualitative assessment of discrepancies in modularization of contemporary middleware.

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.

The DOPLER meta-tool for decision-oriented variability modeling: a multiple case study

The variability of a product line is typically defined in models. However, many existing variability modeling approaches are rigid and don't allow sufficient domain-specific adaptations. We have thus been developing a flexible and extensible approach for defining product line variability models. Its main purposes are to guide stakeholders through product derivation and to automatically generate product configurations. Our approach is supported by the DOPLER (Decision-Oriented Product Line Engineering for effective Reuse) meta-tool that allows modelers to specify the types of reusable assets, their attributes, and dependencies for their specific system and context. The aim of this paper is to investigate the suitability of our approach for different domains. More specifically, we explored two research questions regarding the implementation of variability and the utility of DOPLER for variability modeling in different domains. We conducted a multiple case study consisting of four cases in the domains of industrial automation systems and business software. In each of these case studies we analyzed variability implementation techniques. Experts from our industry partners then developed domain-specific meta-models, tool extensions, and variability models for their product lines using DOPLER. The four cases demonstrate the flexibility of the DOPLER approach and the extensibility and adaptability of the supporting meta tool.

Systematic Management of Variability in UML-based Software Product Lines

Systematic Management of Variability in UML-based Software Product Lines

Automated analysis of feature models 20 years later: A literature review

Software product line engineering is about producing a set of related products that share more commonalities than variabilities. Feature models are widely used for variability and commonality management in software product lines. Feature models are information models where a set of products are represented as a set of features in a single model. The automated analysis of feature models deals with the computer-aided extraction of information from feature models. The literature on this topic has contributed with a set of operations, techniques, tools and empirical results which have not been surveyed until now. This paper provides a comprehensive literature review on the automated analysis of feature models 20 years after of their invention. This paper contributes by bringing together previously disparate streams of work to help shed light on this thriving area. We also present a conceptual framework to understand the different proposals as well as categorise future contributions. We finally discuss the different studies and propose some challenges to be faced in the future.

적응형 소프트웨어를 위한 프로덕트 라인 아키텍처 개발

최근의 유비쿼터스 컴퓨팅 환경에서 요구되는 새로운 패러다임의 소프트웨어인 적응형 소프트웨어는 외부 환경 즉 문맥의 변화를 인식하고 자신의 운영 상태를 평가하여 스스로 동작행위를 바꾸는 능력을 가진 소프트웨어이다. 적응형 소프트웨어를 개발하기 위해서는 문맥에 대한 분석 및 설계와 더불어 동적인 문맥에 따라 적절히 대응할 수 있는 소프트웨어의 구조 및 행위를 설계하는 과정이 필요하다. 이것은 일반적인 소프트웨어보다 소프트웨어가 적응해야 하는 상황을 모델링 하는 기술이 필요하기 때문에 더 많은 노력이 필요하다. 본 논문에서는 재사용을 통해 개발의 효율성을 높이고자 적응형 소프트웨어를 위한 프로덕트 라인 아키텍처와 아키텍처 산출물의 템플릿을 제안한다. 아키텍처 산출물들은 프로덕트 라인의 공통성과 가변성을 명시적으로 표현하여 체계적인 핵심자산의 재사용 활동을 지원한다. In the latest intelligent computing environments, the self-adaptive software, as new software paradigm, which modifies its own behavior in response to changes in its operating environment is needed. To develop the self-adaptive software, it is necessary to analyze and design the context of software as well as the structure and the behavior of software. We need more efforts for self-adaptive software development than for traditional software development because we need more activities and technologies like context modeling and adaptation to develop the self-adaptive software. In this paper, we present the product line architecture for self-adaptive software and templates of artifacts to improve the efficiency of development through a reuse methodology. The artifacts of the architecture support the systematic reuse activities of core assets by expressing the commonality and variability of product line.

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.

Approach to modelling feature variability and dependencies in software product lines

Product line software engineering empowers high-level constructive software reuse by exploiting commonality and managing variability among the member products in a product family. A new feature-oriented method has been proposed to model feature variability and dependencies in software product lines. To conquer the complexity of the modelling, the modelling is decomposed into two views - a feature tree view and a dependency view. The main focus of this work is on the dependency view. Feature dependencies have very strong implications on the configurations of member products in a product line. Currently existing feature-oriented approaches do not facilitate feature dependency modelling in a scalable way. A matrix-based approach is developed to maintain the information about feature dependencies, and to accommodate the generation of feature dependency diagrams. Instead of using an overall feature dependency diagram, the authors decompose an overall diagram into a set of individual feature dependency diagrams that is capable of facilitating more effective configurations for the member products in a product line. The approach is scalable for constantly evolved product lines and supports easy detection of conflicting feature dependencies.

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.

Modelling and using product line variability in automotive systems

Although the product line approach for automotive systems is promising because it gains significant economies of scope, it requires systematic planning and continuous management of variability throughout the development process. The authors discuss the value of variability in product lines and describe their approach to modeling and using variability, which evolved from their work at Bosch.

Product line variability support by FORM and Mecano model integration

A product line definition must cover several systems, for this reason additional requirements are included as product line assets during domain engineering. Generic assets are presented to cover all components the product line instances are built from, and their corresponding composition rules. These generic assets embrace common and variable product aspects supporting the variability in product line definition and instantiation.This paper is devoted to present the problem of handling product line variability in every life-cycle stage by the integration of the ideas of the domain engineering method FORM (Feature-Oriented Reuse Method) and the Mecano Model, which defines a coarse-grained reusable element structure.

Implementing product line variabilities

Software product lines have numerous members. Thus, a product line infrastructure must cover various systems. This is the significant difference to usual software systems and the reason for additional requirements on the various assets present during software product line engineering. It is imperative that they support the description of the product line as a whole, as well as its instantiation for the derivation of individual products. Literature has already addressed how to create and instantiate generic product line assets, such as domain models and architectures to generate instance specific ones [1, 2, 3], yet little attention has been given on how to actually deal with this genericity at the code level. This paper addresses the issue of handling product line variability at the code level. To this end various implementation approaches are examined with respect to their use in a product line context.