Towards a Better Understanding of Software Features and Their Characteristics

Abstract

The notion of features is commonly used to describe, structure, and communicate the functionalities of a system. Unfortunately, features and their locations in software artifacts are rarely made explicit and often need to be recovered by developers. To this end, researchers have conceived automated feature-location techniques. However, their accuracy is generally low, and they mostly rely on few information sources, disregarding the richness of modern projects. To improve such techniques, we need to improve the empirical understanding of features and their characteristics, including the information sources that support feature location. Even though, the product-line community has extensively studied features, the focus was primarily on variable features in preprocessor-based systems, largely side-stepping mandatory features, which are hard to identify. We present an exploratory case study on identifying and locating features. We study what information sources reveal features and to what extent, compare the characteristics of mandatory and optional features, and formulate hypotheses about our observations. Among others, we find that locating features in code requires substantial domain knowledge for half of the mandatory features (e.g., to connect keywords) and that mandatory and optional features in fact differ. For instance, mandatory features are less scattered. Other researchers can use our manually created data set of features locations for future research, guided by our formulated hypotheses.

A Study of Feature Scattering in the Linux Kernel

“…It is not completely clear, however, how these syntactic code extensions, which aim at realizing configurability, relate to semantic code extensions, that is, units of functionality from a domain-oriented view. Understanding this relationship constitutes an interesting future research question [44].…”

“…To avoid feature-location efforts, researchers have proposed to use embedded annotations to record feature locations directly in the code (similar to ifdefs) together with respective tooling and case studies [56][57][58][59]. Notably, Krüger et al [44] manually annotated feature locations of mandatory features in the open-source 3d printer firmware Marlin and found that their code-level characteristics differ from optional features. Specifically, mandatory features are less scattered, probably since they align better with the software architecture.…”

The state of adoption and the challenges of systematic variability management in industry

“…to record and later analyze variability decisions (railway, imaging technology, and traffic control case), such as rationales for introducing variability. It was also stated that recording information about refactorings would be helpful, preferably using embedded annotations (Ji et al 2015;Andam et al 2017;Abukwaik et al 2018;Seiler and Paech 2017;Krueger et al 2018aKrueger et al , 2019a. The recording should explicitly relate refactorings to either the introduction of new functionality (features) or to maintenance.…”

“…As such, a feature modeling process is needed, that supports obtaining a feature model from a diverse set of variability information sources (Bécan et al 2016;Davril et al 2013;Krueger et al 2019a), integrated with feature-model management, merging, and synthesis techniques (Acher et al 2010, b, She et al 2011. Our cases express that functional evolution is well reflected in commit messages (e.g., bug fix information, new feature implementations, new branches), which confirms some insights that commit messages are a good source for feature identification (Krueger et al 2018a(Krueger et al , 2019aZhou et al 2018).…”

“…Variant-rich systems are especially common in traditional engineering domains including automotive, industrial automation, and telecommunication. In addition, recent trends, such as the Internet of Things (IoT) (Atzori et al 2010), cyberphysical systems (Krüger et al 2017;Romero et al 2015) or robotics (Garcia et al 2019), further increase the need for customization.…”