Formalizing interactive staged feature model configuration

Feature model is a popular formalism for describing the commonality and variability of a software product line in terms of features. Feature models symbolise a presentation of the possible application configuration space, and can be customised based on specific domain requirements and stakeholder goals. As feature models are becoming increasingly complex, it is desired to provide automatic support for customised analysis and verification based on the specific goals and requirements of stakeholders. This paper first presents feature model slicing based on the requirements of the users. We then introduce three-valued abstraction of behaviour models based on the slicing unit. Finally, based on multi-valued model checker, a case study was conducted to illustrate the effectiveness of our approach.

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.

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 text-based approach to feature modelling: Syntax and semantics of TVL

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

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.

According to a survey of Indonesian pet healthcare service users, only 19% of pet health applications are used since the functions offered by the applications are insufficient to meet the needs of the users. Developing feature model for the pet health application domain is the goal of this research. Using a mixed-methods approach, this research examined nine pet health apps which are available on Google Play and the App Store, observed 30 pet health service consumers through surveys using purposive sampling, and conducted document analyses. The Feature Oriented Domain Analysis (FODA) approach is applied within the Software Product Line Engineering (SPLE) framework. The result of this research is a pet health application domain feature model consisting of five non-functional requirements and 45 functional requirements. With an average assessment score of 96%, domain experts have determined that the feature model implementation in this study is in line with user needs.

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.

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

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.

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.

Automating feature model refactoring: A Model transformation approach

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.