No code anomaly is an island anomaly agglomeration as sign of product line instabilities

Abstract

A software product line (SPL) is a set of systems that share common and varying features. To provide large-scale reuse, the components of a SPL should be easy to maintain. Therefore, developers have to identify anomalous code structures – i.e., code anomalies – that are detrimental to the SPL maintainability. Otherwise, SPL changes can eventually propagate to seemly-unrelated features and affect various SPL products. Previous work often assume that each code anomaly alone suffices to characterize SPL maintenance problems, though each single anomaly may represent only a partial, insignificant, or even inexistent view of the problem. As a result, previous studies have difficulties in characterizing anomalous structures that indicate SPL maintenance problems. In this paper, we study the surrounding context of each anomaly and observe that certain anomalies may be interconnected, thereby forming so-called anomaly agglomerations. We characterize three types of agglomerations in SPL: feature, feature hierarchy, and component agglomeration. Two or more anomalies form an agglomeration when they affect the same SPL structural element, i.e. a feature, a feature hierarchy, or a component. We then investigate to what extent non-agglomerated and agglomerated anomalies represent sources of a specific SPL maintenance problem: instability. We analyze various releases of four feature-oriented SPLs. Our findings suggest that a specific type of agglomeration indicates up to 89% of sources of instability, unlike non-agglomerated anomalies.