Concepts and Guidelines of Feature Modeling for Product Line Software 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.

In this paper we identify key challenges a medium-sized software organization is facing in migrating towards Software Product Line Engineering (SPLE). The software engineering context of the company is characterized by a two-fold access to the market - core customer driven product enhancement and product development for a broader, anonymous market - and the embedding of software engineering in multi-disciplinary systems and solutions engineering.Based on a characterization of the business, the software product subject to migration towards SPLE, and the goals and background of the SPLE initiative, seven key challenges with respect to the migration are identified. These challenges relate to process diversity in the face of multiple reuse approaches; the management of requirements and variability; the integration of requirements traceability and variability management; legacy software and discipline vs. software-specific modularization; integration with systems engineering; costing and pricing models; and project vs. product documentation.

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.

Feature models are widely used to model commonalities and variabilities among products during software product line development. Feature configurations are generated by selecting the features to be included in individual products. Automated tools to identify errors or inconsistencies in the feature models and configurations are essential to successful software product line engineering. This paper proposes a verification technique and tool based on semantic web technologies such as OWL, SWRL and Protege API. This approach checks the feature model and configuration based on predefined rules and provides information on existence of errors as well as the kinds of those errors. This approach is extensible due to ease of rule modification and may be easily applied to other environments because semantic web technologies can be easily integrated with other programming environments. This paper demonstrates how various semantic web-related technologies can support automatic verification of one kind of software development artifact, the feature model.

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.

In software product line engineering (SPLE), commonality and variability across products of a product line domain are captured typically by a feature model. Reusable components are then developed from features. However, mapping features to components remains a complex task requiring a systematic way of exploring and analyzing various concerns arising from inadequate/insufficient domain assumptions. Essentially, those concerns prevent SPLE from achieving various quality attributes. This paper proposes a problem frames-based approach to addressing this problem. An elevator product line example is used to demonstrate the feasibility of the approach.

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.

Software product lines (PLs) are large, complex systems, demanding high maintainability and enhanced flexibility. Nonetheless, in the state of the art PL methods, features are scattered and tangled throughout the system components, leading to poor maintainability. Additionally, the majority of PL methods support manual product composition, while the implementation of feature-level variability in PL products influences the system's conceptual integrity. Generative programming techniques do enhance flexibility, but on the cost of maintainability. The feature-architecture mapping (FArM) method provides a stronger mapping between features and the architecture. It is based on a series of transformations on the initial PL feature model. During these transformations, architectural components are derived, encapsulating the business logic of each transformed feature and having interfaces reflecting the feature interactions. The flexibility of FArM architectures is supported through the explicit integration of plug-in mechanisms. The methodology is evaluated in the context of a wireless handheld device PL.

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 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.

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.

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

In recent years, there has been a growing interest in cloud technologies. Using current cloud solutions, it is however difficult to create customizable multi-tenant applications, especially if the application must support varying Quality of Service (QoS) guarantees. Software Product Line Engineering (SPLE) and feature modeling techniques are commonly used to address these issues in non-cloud applications, but these techniques cannot be ported directly to a cloud context, as the common approaches are geared towards customization of on-premise deployed applications, and do not support multi-tenancy. In this paper, we propose an architecture for the development and management of customizable Software as a Service (SaaS) applications, built using SPLE techniques. In our approach, each application is a composition of services, where individual services correspond to specific application functionalities, referred to as features. A feature-based methodology is described to abstract and convert the application information required at different stages of the application life-cycle: development, customization and deployment. We specifically focus on how development feature models can be adapted ensuring a one-to-one correspondence between features and services exists, ensuring the composition of services yields an application containing the corresponding features. These runtime features can then be managed using feature placement techniques. The proposed approach enables developers to define significantly less features, while limiting the amount of automatically generated features in the application runtime stage. Conversion times between models are shown to be in the order of milliseconds, while execution times of management algorithms are shown to improve by 5 to 17% depending on the application case.

Software product line development is a compromise between customer requirements, existing product line architectural constraints and commercial needs. Managing variability is the key to a successful product line development. Product line models of requirements and features can be constructed that contain variation points. New products can be driven by making requirement selections from a product line model of requirements but as the product line evolves selections are constrained by the design of the existing product line architecture and the cost of making these changes. We present a set of rules that map the selection constraint values of requirements to the selection constraint values of features which in turn map on to the selection constraint values of architectural assets. We illustrate the application of the rules using a worked example.