Problem Frames-Based Approach to Achieving Quality Attributes in Software Product Line Engineering

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.

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.

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 a paradigm to promote systematic software reuse. A Feature Model (FM) is a common means to illustrate the commonality and variability of software products in a family. In most existing FM extraction approaches, keywords in the requirement document or certain types of system behavior or external events are considered features. The resulting FM is a combination of user activities and system actions (SAs), making it hard to understand. In this paper, we present an automatic approach to generate a product line FM from multiple requirement documents. We consider user activity and SAs separately in our approach and focus on the expected behaviors of the software system, together with the data being processed. The resulting FM clearly illustrates the expected functionalities of the software system and their variability in the product line. We also compared our approach with existing techniques by processing the same textual documents, and noted improvements in our results.

Context. From recent works on product properties resulting from configurations and the optimisation of these properties, one comes quickly to more complex challenges such as multi-objective optimisation, conflicting objectives, multiple stakeholders, and conflict resolution. The intuition is that Software Product Line Engineering (SPLE) can draw from other disciplines that deal with decision spaces and complex decision scenarios.Objectives. We aim to (1) explore links to such disciplines, (2) systematise and compare concepts, and (3) identify opportunities, where SPLE approaches can be enriched.Method. We undertake an exploratory study: Starting from common SPLE activities and artefacts, we identify aspects where we expect to find corresponding counterparts in other disciplines. We focus on Multiple Criteria Decision Analysis (MCDA), Multi-Objective Optimisation (MOO), and Design Space Exploration (DSE), and perform a comparison of the key concepts.Results. The resulting comparison relates SPLE activities and artefacts to concepts from MCDA, MOO, and DSE and identifies areas where SPLE approaches can be enriched. We also provide examples of existing work at the intersections of SPLE with the other fields. These findings are aimed to foster the conversation on research opportunities where SPLE can draw techniques from other disciplines dealing with complex decision scenarios.

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.

Recent research on software product line engineering has led to several search-based frameworks for reverse engineering feature models. The most common fitness function utilized maximizes the number of matched products with an oracle set of products. However, to calculate this fitness each product defined by the chromosome has to be enumerated using a SAT solver and this limits scalability to product lines with fewer than 30 features. In this paper we propose \(\textit{SAT}_{\textit{ff}}\), a fitness function that simulates validity by computing the difference between constraints in the chromosome and oracle. In an empirical study on 101 feature models comparing \(\textit{SAT}_{\textit{ff}}\) with two existing fitness functions that use the enumeration technique we find that \(\textit{SAT}_{\textit{ff}}\) shows a significant improvement over one, and no significant difference with the other one. We also find that \(\textit{SAT}_{\textit{ff}}\) requires only 7 % of the runtime on average scaling to feature models with as many as 97 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.

Structuring the modeling space and supporting evolution in software product line engineering

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.

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.

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.

Due to ever-evolving software developments processes, companies are motivated to develop desired quality products quickly and effectively. Industries are now focusing on the delivery of configurable systems to provide several services to a wide range of customers by making different configurations in a single largest system. Nowadays, component-based systems are highly demanded due to their capability of reusability and restructuring of existing components to develop new systems. Moreover, product line engineering is the major branch of the component-based system for developing a series of systems. Software product line engineering (SPLE) provides the ability to design several software modifications according to customer needs in a cost-effective manner. Researchers are trying to tailor the software product line (SPL) process that integrates agile development technologies to overcome the issues faced during the execution of the SPL process such as delay in product delivery, restriction to requirements change, and exhaustive initial planning. The selection of suitable components, the need for documentation, and tracing back the user requirements in the agile-integrated product line (APL) models still need to improve. Furthermore, configurable systems demand the selected features to be the least dependent. In this paper, a hybrid APL model, quality enhanced application product line engineering (QeAPLE) is proposed that provides support for highly configurable systems (HCS) by evaluating the dependency of features before making the final selection. It also has a documentation and requirement traceability function to ensure that the product meets the desired quality. Two-fold assessments are undertaken to validate the suggested model, with the proposed model being deployed on an active project. After that, we evaluated the proposed model performance and effectiveness using after implementing it in a real-world environment and compared the results with an existing method using statistical analysis. The results of the experimental study proofs that the proposed model is practically and statistically significant as compared to the existing method in terms of effectiveness and participants’ performance. Hence, the statistical results of the comparative analysis show that the proposed model improved ease of understanding and adaptability, required effort, high-quality achievement, and version management are significant i.e., more the 50% as compared to the exiting method i.e., less than 50%. The proposed model offers to assist in the development of a highly configurable system that achieves the needed quality. Therefore, the proposed model manages the variation identification, versions control, components dependency for correct selection of components, and validation activities from domain engineering to application engineering.

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.

IBED: Combining IBEA and DE for optimal feature selection in software product line engineering