Home > Research > Publications & Outputs > No Code Anomaly is an Island

Electronic data

  • icsr17-v31

    Accepted author manuscript, 883 KB, PDF document

Links

Text available via DOI:

View graph of relations

No Code Anomaly is an Island: Anomaly Agglomeration as Sign of Product Line Instabilities

Research output: Contribution in Book/Report/Proceedings - With ISBN/ISSNConference contribution/Paperpeer-review

Published
  • Eduardo Fernandes
  • Gustavo Vale
  • Leonardo Sousa
  • Eduardo Figueiredo
  • Alessandro Fabricio Garcia
  • Jaejoon Lee
Close
Publication date29/05/2017
Host publicationICSR 2017: Mastering Scale and Complexity in Software Reuse
EditorsGoetz Botterweck, Claudia Werner
PublisherSpringer
Pages48-64
Number of pages16
ISBN (electronic)9783319568560
ISBN (print)9783319568553
<mark>Original language</mark>English

Publication series

NameLecture Notes in Computer Science
PublisherSpringer
Volume10221

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 maintain-ability. 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 pa-per, 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.