Maintaining feature traceability with embedded annotations

Abstract

Features are commonly used to describe functional and nonfunctional aspects of software. To effectively evolve and reuse features, their location in software assets has to be known. However, locating features is often difficult given their crosscutting nature. Once implemented, the knowledge about a feature's location quickly deteriorates, requiring expensive recovering of these locations. Manually recording and maintaining traceability information is generally considered expensive and error-prone. In this paper, we argue to the contrary and hypothesize that such information can be effectively embedded into software assets, and that arising costs will be amortized by the benefits of this information later during development. We test this hypothesis in a study where we simulate the development of a product line of cloned/forked projects using a lightweight code annotation approach. We identify annotation evolution patterns and measure the cost and benefit of these annotations. Our results show that not only the cost of adding annotations, but also that of maintaining them is small compared to the actual development cost. Embedding the annotations into assets significantly reduced the maintenance cost because they naturally co-evolve with the assets. Our results also show that a majority of these annotations provides a benefit for feature-related code maintenance tasks, such as feature propagation and migrating clones into a platform.

A Study of Feature Scattering in the Linux Kernel

“…Since they are not optional, their locations are usually not explicitly recorded in the source code and instead need to be recovered-a discipline called feature location [50][51][52][53][54][55]. 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.…”

Towards a Better Understanding of Software Features and Their Characteristics

“…Here, a feature represents a functionality (or concern) in a system, regardless of whether it is an optional or mandatory functionality in the case of a product line. Such features and their locations are rarely documented, for example with feature-traceability databases [30] or embedded feature annotations [18], wherefore recovering their locations is costly and error-prone [37]. Even automated or semiautomated feature-location techniques require substantial manual effort (e.g., for calibration or for finding so-called seeds from which they can start exploring code) and fall short in accuracy [32].…”

“…When a system evolves over time, the knowledge of features and their locations quickly fades, which then needs to be recovered. In fact, feature location [3,10,23,32] is one of the most common and expensive tasks in software engineering [5,18,28,37].…”

Exposing Runtime Information through Source Code Annotations

“…Ji et al [24] assessed the cost of manually annotating features in source code via specially formatted comments. According to the study they performed, the cost of adding and maintaining such annotations is small compared to the cost of the whole development process.…”