Checklist-Based Inspection Technique for Feature Models Review

Version control (VC) and Software Product Line Engineering (SPLE) are two software engineering disciplines to manage variability in time and variability in space. In this paper, a thorough comparison of VC and SPLE is provided, showing that both disciplines imply a number of desirable properties. As a proof of concept for the combination of VC and SPLE, we present SuperMod, a tool realizes an existing conceptual framework that transfers the iterative VC editing model to SPLE. The tool allows to develop a software product line in a single-version workspace step by step, while variability management is completely automated. It offers familiar version control metaphors such as check-out and commit, and in addition uses the SPLE concepts of feature models and feature configuration the definition of logical variability and to define the logical scope of a change. SuperMod has been implemented in a model-driven way and primarily targets EMF models as software artifacts. We successfully apply the tool to a standard SPLE example.

Product line software engineering (PLSE) is an emerging software engineering paradigm, which guides organizations toward the development of products from core assets rather than the development of products one by one from scratch. In order to develop highly reusable core assets, PLSE must have the ability to exploit commonality and manage variability among products from a domain perspective. Feature modeling is one of the most popular domain analysis techniques, which analyzes commonality and variability in a domain to develop highly reusable core assets for a product line. Various attempts have been made to extend and apply it to the development of software product lines. However, feature modeling can be difficult and time-consuming without a precise understanding of the goals of feature modeling and the aid of practical guidelines. In this paper, we clarify the concept of features and the goals of feature modeling, and provide practical guidelines for successful product line software engineering. The authors have extensively used feature modeling in several industrial product line projects and the guidelines described in this paper are based on these experiences.

Software Product Line Engineering (SPLE) is an approach for software reuse. It concerns to produce customized software products as atomic or composite services to be reused in SOA-based applications. A common set of artifacts is used to build these services in a planned and managed way. The main purpose of SPLE is to explore commonalities and variabilities. The SPLE approach provides a strategic software reuse that can produce quality Software as a Service (SaaS) while cutting cost and reducing time-to-market. This paper proposes a process to construct services as Software Product Lines by using Model Driven techniques. The process combines the use of maps, visual techniques for SPL modeling, especially features diagrams and MD techniques. In addition to the process, we have developed a tool to support map, feature, and class diagrams modeling.

Automating feature model refactoring: A Model transformation approach

Software product line (SPL) engineering has emerged to become a mature domain for maximizing reuse within the context of a family of related software products. Within the process of SPL, the variability and commonality among the different products within the scope of a family is captured and modeled into a system's `feature model'. Currently, there are no architecture description languages (ADLs) that support the relationship between the feature model domain and the system architecture domain, leaving a gap which significantly increases the complexity of analyzing the system's architecture and insuring that it complies with its set feature model and variability requirements. In this paper we present ADLARS, an architecture description language that supports the relationship between the system's feature model and the architectural structures in an attempt to alleviate the aforementioned problem. The link between the two spaces also allows the automatic generation of product architectures from the family reference architecture

The goal of a Software Product Line (SPL) is to provide a set of reusable software assets for the rapid production of a software systems family aimed at a specific market segment. The main objective of SPL engineering is to construct, as automatically as possible, specific products after selecting the particular set of features that must be included in them. Unlike traditional engineering of single systems, SPL engineering often requires dealing with three different languages at each stage of the software lifecycle: (1) a language for specifying the variability of the SPL (e.g. a feature model); (2) a language for designing the reusable software assets (e.g. UML 2.0); and (3) a language that specifies how these reusable assets must be composed for constructing specific products. There are currently available enough languages for variability specification and software assets design, but there is a general lack of languages for specifying and automating the composition of these assets. This paper presents as a novel contribution a process to engineer this kind of language. The process produces an editor and a compiler, which automates the composition of reusable assets, for a particular language. To explain this process a language has been developed to compose reusable assets of architectural models.

Software product family or line is a software engineering paradigm that systematizes reuse. In software product line engineering, two phases are distinguished: domain engineering which is in charge of developing a common infrastructure and assets and application engineering which makes use of those assets to generate the products. One of the key aspects of product lines is variability and its management. However, the main focus has been on functional variability and quality variability in software product lines has not received so much attention by researchers. In a product line different members of the line may require different levels of a quality requirement, for instance they could differ in terms of their availability, security, reliability, etc. Due to this variability, quality evaluation in software product lines is much more complicated that in single-systems. One alternative is to evaluate all the products of a line but it is very expensive and ways of reducing evaluation efforts are necessary. In this direction, the paper presents a method for facilitating cost-effective quality evaluation of a product line taking into consideration variability on quality attributes.

Towards Software Product Lines Optimization Using Evolutionary Algorithms

Needs for mass customization and economies of scale have pushed engineers to develop Software Product Lines (SPLs). SPLs are families of products sharing commonalities and exhibiting differences, built by reusing software assets abstractly represented by features. Feature models describe the constraints that link the features and allow the configuration of tailored software products. Common SPLs involve hundreds, even thousands of features, leading to billions of possible software products. As a result, testing a product line is challenging due to the enormous size of the possible products. Existing techniques focus on testing based on the product line's feature model by selecting a limited set of products to test. Being created manually or reverse-engineered, feature models are prone to errors impacting the generated test suites. In this paper, we examine ability of test suites to detect such errors. In particular, we propose two mutation operators to derive erroneous feature models (mutants) from an original feature model and assess the capability of the generated original test suite to kill the mutants. Experimentation on real feature models demonstrate that dissimilar tests suites have a higher mutant detection ability than similar ones, thus validating the relevance of similarity-driven product line testing.

A software product line (SPL) usually involves a shared set of core assets and a series of application products. To ensure consistency, the evolution of the core assets and all the application products should be coordinated and synchronized under a unified evolution process. Therefore, SPL evolution often involves cross-product propagation and synchronization besides application derivation based on core assets, presenting quite different characteristic from the evolution of individual software products. As software architectures, including the product line architecture (PLA) and application architectures, play a central role in SPL engineering and evolution, architecture-based evolution analysis is a natural way for analyzing and managing SPL evolution. In this paper, we explore common practices of architecture evolution and the rationale behind in industrial SPL development. To this end, we conduct a case study with Wingsoft examination system product line (WES-PL), an industrial product line with an evolution history of eight years and more than 10 application products. In the case study, we reviewed the evolution history of WES-PL architecture and analyzed several typical evolution cases. Based on the historical analysis, we identify some special problems in industrial SPL practice from the aspect of architecture evolution and summarize some useful experiences about SPL evolution decisions to complement classical SPL methodology. On the other hand, we also propose some possible improvements for the evolution management in WES-PL.

Automated diagnosis of feature model configurations

Two mechanisms widely used in the Software Product Lines (SPL) Engineering are the feature model and the conditional compilation. The former models the variability in the problem space and the latter realizes it in the solution space. Even though the research community know that the feature model imposes a number of constraints to the product line implementation, there is a lack of support to co-evolve problem space and solution space. In this paper, we present an exploratory study whether problem space constraints are considered at source code level of #ifdef-based SPL implementations. In order to accomplish our goal, we developed a preliminary approach to check problem and solution spaces in a prototype tool (fclcheck). The results show a lack of realization of feature model constraints while implementing variation points with that mechanism. We also evaluated the scalability of the approach and the recoverability of the tool.

A Software Product Line (SPL) is a set of systems that share a group of manageable features and satisfy the specific needs of a particular domain. The features of an SPL can be used in variable combinations to derive product variants in the SPL domain. Because SPLs promote product development through reuse, it is vital to have a means to measure their quality in terms of quality attributes like complexity, reusability,… In this paper, we propose a set of metrics to evaluate the quality of an SPL at three levels: the feature model, design and code. We adapted a set of metrics for software quality and defined new metrics to deal with the inherent characteristics of SPLs, specifically the feature model and the traceability between features, design and code. Furthermore, to assist in interpreting the quality of a given SPL, we conducted an empirical study over ten open source SPLs to identify thresholds for the proposed metrics.

Software product line (SPL) is a software engineering paradigm for software development. A software product within a product line often has specific functionalities that are not common to all other products within the product line. Those specific functionalities are termed “variant features” in a product line. SPL paradigm involves the modeling of variant features. However, little work in SPL investigates and addresses the modeling of variant features specific to user interface (UI). Unified Modeling Language (UML) is the de facto modeling language for object-oriented software systems. It is known that UML needs better support in modeling UIs. Thus, much research developed UML extensions to improve UML support in modeling UIs. Yet little of this work is related to developing such extensions for modeling UIs for SPLs in which variant features specific to UI modeling must be addressed. This research develops a UML extension -Web User Interface Modeling Language (WUIML) to address these problems. WUIML defines elements for modeling variant features specific to user interfaces for Web-based SPLs. The model elements in WUIML extend from the metaclass and BasicActivity of the UML2.0 metamodel. WUIML integrates the modeling of variant features specific to user interfaces to UML. For example, in a Web-based patient registration software product line, member products targeting British users may use British date format in the user interface, while member products targeting United States users may use United States date format in the user interface. Thus, this is a variant feature for this product line. WUIML defines a model element, XOR, to represent such exclusive or conditions in a product line user interface model. WUIML would reduce SPL engineers’ efforts needed in UI development. To validate the WUIML research outcome, a case study was conducted. The results of this empirical study indicate that modeling UIs for Web-based SPLs using WUIML is more effective and efficient than using standard UML.

In the face of development of a software-intensive products family in a domain, Software Product Line Engineering (SPLE) itself is a best practice that has been representatively demonstrated by the cases inducted into Software Product Line Hall of Fame. SPLE best practice is supported by various and vivid meta best practices generated from concrete activities through solution finding processes. This paper describes the evolution of the FISCAN MTMSIS software product line, nominated to the Hall of Fame at SPLC 2010. FISCAN applies SPLE in the security inspection domain and has identified SPLE best practices through years of experience in the past. This paper discusses some representative best practices and the lessons we learned during the process. More work, both development and research, are still in progress on the platform of the MTMSIS software product line and FISCAN will continue to apply SPLE in the future.