Towards autonomic software product lines

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.

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

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.

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.

Many organizations report dramatic benefits from the adoption of software product line practice. Organizations that have established software engineering process discipline are better poised to succeed with product lines. While we acknowledge that there are different paths to successful process discipline, in this technical note, we concentrate on approaches based on the Capability Maturity Model Integration (CMMI) models. We describe practices that are most crucial to product line success. While some of these relate directly to the CMMI models process areas, others are uniquely important to product lines. In this technical note, we first present fundamental concepts of software product lines. We then describe important product line practices as they have been documented in A Framework for Software Product Line Practice (framework). We next present an overview of the CMMI models, followed by a description of the general relationships between the framework and CMMI models. We amplify this comparison with a detailed example showing the relationship between configuration management practices in CMMI and in the framework. We conclude by describing the ways in which organizations can build upon their process improvement efforts to achieve success with product lines and realize additional benefits through the use of both technologies.

To tame the complexity of engineering customizable software, systems are built as families of products that share a common core. As customers desire the automatic and smart adjusting of their software to various contexts of operation, runtime reconfiguration capabilities need to be added. In this extended abstract, we sketch reengineering challenges to be tackled when evolving classic software product lines into such dynamic software product lines.

As a software product line evolves, it typically introduces new features and includes new products over time. A known cause of software aging in product lines is the introduction of new features that interact in unplanned and even risky ways with the existing features. This can lead to failures, performance degradation, and hazardous states in a new product. Software product line developers currently identify new, unwanted feature interactions primarily in the testing of each new product. This incurs significant costs, comes late in development, and does not exploit the knowledge of prior feature interactions within a product line. The contribution of our paper is to leverage knowledge of prior feature interactions in a product line, together with similarity measures between the features in known feature interactions and the new features, in order to detect similar feature interactions in a new product much earlier in the development process. Results from application to a case study from the literature show that this approach accurately detected 73% of feature interactions. This small study suggests that using similarity measures at the feature level within a product line to detect problematic interactions involving a new feature can effectively reduce this cause of aging in a software product line.

The goal of a software product line is to create a suitable platform for fast and easy production of software for same market segment. However, a software product line is limited because it needs to meet new stakeholder requirements either through upgrades or the introduction of new technologies. A Multi Product Line aims at deriving new software products from reuse of a set of features provided by several heterogeneous software product lines without modifying or altering the independent operation of the same. This paper presents a study about the application of Multi Product Lines in the software development process. It shows some domains that illustrate applications of multi product lines principle in the process and the product. Also, the main current challenges in applying multi product line in software engineering are described. This paper aims to show the importance and usefulness of applying multi product lines approaches in Software Engineering.

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.

At the heart of product line development is the assumption that through structured reuse later products will be of a higher quality and require less time and effort to develop and test. This thesis presents empirical results from two case studies aimed at assessing the quality aspect of this claim and exploring fault prediction in the context of software product lines. The first case study examines pre-release faults and change proneness of four products in PolyFlow, a medium-sized, industrial software product line; the second case study analyzes post-release faults using pre-release data over seven releases of four products in Eclipse, a very large, open source software product line.;The goals of our research are (1) to determine the association between various software metrics, as well as their correlation with the number of faults at the component/package level; (2) to characterize the fault and change proneness of components/packages at various levels of reuse; (3) to explore the benefits of the structured reuse found in software product lines; and (4) to evaluate the effectiveness of predictive models, built on a variety of products in a software product line, to make accurate predictions of pre-release software faults (in the case of PolyFlow) and post-release software faults (in the case of Eclipse).;The research results of both studies confirm, in a software product line setting, the findings of others that faults (both pre- and post-release) are more highly correlated to change metrics than to static code metrics, and are mostly contained in a small set of components/ packages. The longitudinal aspect of our research indicates that new products do benefit from the development and testing of previous products. The results also indicate that pre-existing components/packages, including the common components/packages, undergo continuous change, but tend to sustain low fault densities. However, this is not always true for newly developed components/packages. Finally, the results also show that predictions of pre-release faults in the case of PolyFlow and post-release faults in the case of Eclipse can be done accurately from pre-release data, and furthermore, that these predictions benefit from information about additional products in the software product lines.

Software architecture has been a key research area in the software engineering community due to its significant role in creating high-quality software. The trend of developing product lines rather than single products has made the software product line a viable option in the industry. Software product line architecture (SPLA) is regarded as one of the crucial components in the product lines, since all of the resulting products share this common architecture. The increased popularity of software product lines demands a process maturity evaluation methodology. Consequently, this paper presents an architecture process maturity model for software product line engineering to evaluate the current maturity of the product line architecture development process in an organization. Assessment questionnaires and a rating methodology comprise the framework of this model. The objective of the questionnaires is to collect information about the SPLA development process. Thus, in general this work contributes towards the establishment of a comprehensive and unified strategy for the process maturity evaluation of software product line engineering. Furthermore, we conducted two case studies and reported the assessment results, which show the maturity of the architecture development process in two organizations.

In Dynamic Software Product Lines (DSPLs) product configuration occurs at runtime. Modelling variability and configuring the product in DSPLs should consider the context and non-functional requirements (NFRs) satisfaction. ConG4DaS (Contextual Goal models For Dynamic Software product lines) is a Requirements Engineering (RE) approach for DSPL which supports (i) modelling of variability with goals, NFRs, contexts and the relationship between them; and (ii) offers a product configuration based on contexts, NFRs and their priority and interactions. In this paper, we present a survey evaluation of ConG4DaS with RE and DSPL researchers in regard to the perceived usefulness. In the survey, both RE and DSPL researchers perceived ConG4DaS as useful for modelling and configuring DSPLs. However, the RE group gave more positive answers than the his study presents the report about a case study on the application of REACT-M (Requirements Evolution in Agile ContexT - Management), an agile method to support software requirements management, in a real software development environment. This case study assessed the strengths, weaknesses, opportunities, and threats related to the assets that make up REACT-M, namely: work products, life cycle, roles, and ceremonies. About the results, it was observed that REACT-M was effective, simple to use, strongly collaborative, suitable, user centered and goal oriented. Thus, achieved its main purpose to evolve the requirements of a software product in iteratively, efficiently and under of the agile mindset. The results contribute to the software industry by providing empirical data about the use of a agile method to software requirements management, which can serve as a reference for organizations seeking the adoption of agile methods related to the requirements area, as well as to provide the scientific community with a better empirical understanding of the relationship between requirements and agile methodDSPL group.

Software Product Lines (SPLs) are families of similar software products built from a common set of features. As the number of products of an SPL is potentially exponential in the number of its features, the model checking problem is harder than for single software. A practical way to face this exponential blow-up is to reuse common behaviour between products. We previously introduced Featured Transition Systems (FTS), a mathematical model that serves as a basis for efficient SPL model checking techniques. In this paper, we present ProVeLines, a product line of verifiers for SPLs that incorporates the results of over three years of research on formal verification of SPLs. Being itself a product line, our tool is flexible and extensible, and offers a wide range of solutions for SPL modelling and verification.

Software product lines are a successful approach to software reuse. To a significant extent, the development of product lines is complicated by crosscutting concerns. This is especially true for product line configuration. Aspect-oriented programming can often help to develop product lines more effectively, but this is not always so. This paper shows it is possible to sublimate the expert knowledge about using aspect-oriented programming in product line development in the form of independently applicable guidelines by proposing an approach to expressing such guidelines. A complete guideline entitled Implementing Mandatory Features with no Crosscutting Concerns is presented as an example. The guidelines have been evaluated in a product line case study that confirmed their applicability. The results of this study obtained by the application of a number of metrics are provided and discussed in the paper.

This report explains the challenges experienced as Overwatch Textron Systems transitioned to a software product line approach. Overwatch Textron Systems provides both software products and custom software development in the domain of intelligence planning, collection and analysis to the U.S. Government and its allies. This report: a) Describes the approach taken to transition Overwatch Textron Systems to a product line organization. b) Provides an overview of the Overwatch Textron Systems software product line; the Overwatch Intelligence Center. c) Describes the product line architecture that is key to the Overwatch Intelligence Center software product line. d) Provides a summary of the lessons learned during the transition.