A New Parameter for Product Configuration in Software Product Lines

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.

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.

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.

Automated diagnosis of feature model configurations

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 lines enable reuse of shared software across a family of products. As new products are built in the product line, new features are added. The features are units of functionality that provide services to users. Unwanted feature interactions, wherein one feature interferes with another feature’s operation, is a significant problem, especially as large software product lines evolve. Detecting feature interactions is a time-consuming and difficult task for developers. Moreover, feature interactions are often only discovered during testing, at which point costly re-work is needed. This paper proposes a similarity-based method to identify unwanted feature interactions much earlier in the development process. It uses knowledge of prior feature interactions stored with the software product line’s feature model to help find unwanted interactions between a new feature and existing features. The paper describes the framework and algorithms used to detect the feature interactions using three path similarity measures and evaluates the approach on a real-world, evolving software product line. Results show that the approach performs well, with 83% accuracy and 60% to 100% coverage of feature interactions in experiments, and scales to a large number of features.

Software Product Line Engineering aims to ensure the correctness, completeness and consistency among its artifacts and the specified domain, in order to prevent the spread of defects for the products derived from this domain. Among initial artifacts of a software product line, feature models are artifacts generated in various domain engineering approaches. Although software inspection is highlighted as an effective review activity for detection of defects in software artifacts, mainly in the early models of software projects, a recent quasi-systematic review of literature indicated a lack of techniques to support the inspection of software product line artifacts, which include features models. Thus, this paper presents FMCheck, a checklist-based inspection technique to support the detection of defects on feature models. This technique was developed to be configurable and to be applied on several extensions of the original feature model notation presented by FODA approach, including the Odyssey-FEX notation, in particular. FMCheck was submitted to a proof of concept and to a further in vitro feasibility study, in which it could be seen the feasibility of FMCheck application and also that inspections applying FMCheck are more effective than ad-hoc inspections, when applied on four distinct domains.

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.

BackgroundThe software product lines (SPL) enable development teams to fully address a systematic reuse of shared assets to deliver a family of similar software products. Mobile applications are an obvious candidate for employing an SPL approach. This paper presents our research outcomes, based on empirical data from an industry-level development project. Two development teams were confronted with the same functionalities set to be delivered through a family of native mobile applications for Android and iOS.MethodsEmpirical data was gathered before, during and after a year of full-time development. The data demonstrate the impact of a SPL approach by comparing the SPL and non-SPL multiple edition development. One family of products (Android apps) was developed using an SPL approach, while another (iOS apps), functionally the same, was developed without employing an SPL approach. The project generated a volume of raw and aggregated empirical data to support our research questions.ResultsThe paper reports a positive impact of an SPL approach on product quality (internal and external) and feature output per week. As data shows, it also increases the delivery of functionalities (240% in 6 more editions), while investing the same amount of effort needed for a single-edition development. As a result of system-supported separation of development and production code, developers had a high confidence in further development. On the other hand, the second team delivered less new functionalities, only two new application editions, and lower software quality than the team that manages multi-edition development by employing an SPL approach.

A systematic mapping study on software product line evolution: From legacy system reengineering to product line refactoring

Software Product Lines (SPL) are systematic approach to develop families of similar software products by explicating their commonalities and variability, e.g., in a feature model. Using techniques from model-driven development, it is then possible to automatically derive a concrete product from a given configuration (i.e., selection of features). However, this is problematic for interactive applications with complex user interfaces (UIs) as automatically derived UIs often provide limited usability. Thus, in practice, the UI is mostly created manually for each product, which results in major drawbacks concerning efficiency and maintenance, e.g., when applying changes that affect the whole product family. This paper investigates these problems based on real-world examples and analyses the development of product families from a UI perspective. To address the underlying challenges, we propose the use of abstract UI models, as used in HCI, to bridge the gap between automated, traceable product derivation and customized, high quality user interfaces. We demonstrate the feasibility of the approach by a concrete example implementation for the suggested model-driven development process.

Lately, the demand for mobile applications development has increased significantly mainly due to growth of use of mobile devices and the need to port existing web applications. To reduce development’s time and cost, Software Product Lines (SPLs) have also been used in the context of mobile applications. However, the existing SPLs do not worry about supporting the development of mobile applications corresponding to the existing Web applications, as it is desirable to have access to the information and main features of these applications in mobile devices. In face of this problem, this paper discusses the motivation and presents the evolution from a SPL in the e-Gov Web (e-Gov Web SPL) domain to a SPL in the mobile domain (e-Gov Mobile SPL) having in mind the need to supply market demand. The conducted evolution was supported by the PLUS approach (Product Line UML-Based Software Engineering) and by the features model. Furthermore, this work debates the main results obtained through some e-Gov Mobile SPL instantiations in the precision livestock domain.KeywordsSoftware Product LineEvolutione-GovWebMobile

Feature models are widely used for describing the variability of a software product line. A feature model contains a tree of features and a set of constraints over these features, which define valid feature combinations. In the industrial practice, large feature models containing hundreds of features and constraints are common. Furthermore, in a hierarchical product line a feature model can be related to other feature models through inter-model constraints. Due to the model size and complexity, understanding industrial feature models is a challenging task.In this paper, we describe the feature model understanding challenges reported by feature model developers at Robert Bosch GmbH. To support the developers in model understanding, we extend the idea of a feature implication graph to feature relation graph by abstracting groups of implications to feature relations. A transitively closed relation graph shows all modeled and implicit feature relations and spans all related feature models. The graph is also used to identify modeling problems, such as false optional or dead features, and to show the derivation of any implicit relation or problem from the modeled constraints. In a case study at Bosch, we evaluate the use of feature relation graph for model understanding. We propose further use cases of the graph, supporting model maintenance, evolution and configuration.

Software product lines are able to describe multiple products sharing a common base of features and are commonly described as feature models. For complex software product lines, automatic analyses are required to ensure validity and to improve the interactive configuration process. Modern SAT solvers are vital components for the validation process of feature models. The increasing variability of software product lines implies the need to use more expressive solvers like SMT solvers. To assist the development of feature modeling tools, we compare SAT and SMT solvers for the automated analysis of feature models. During this thesis, we create an abstract data type to formally define analyses for feature model defects and their explanations. The result shows that SAT solvers are more efficient at detecting the defects, while SMT solvers can find explanations for them multiple times faster. Feature models can be further expanded by attaching attributes to features. Such attributes may contain a numerical value. Additionally, one attribute can be defined for multiple features. In this thesis, we aim to support the interactive configuration process, by providing the range of the sum of values for an attribute. Such ranges depend on the remaining choices in a configuration of the product line. We provide an exact computation using SMT and an approximation using a heuristic. The evaluation results show that an SMT solver is not suitable for supporting interactive configuration. However, the approximated ranges of the provided heuristic were very close to the exact ones.

Trusted Product Lines