Abstract

Architectural smells may substantially increase maintenance effort and thus require extra attention for potential refactoring. While we currently understand this concept and have identified different types of such smells, we have not yet studied their evolution in depth. This is necessary to inform their prioritisation and refactoring. This study analyses the evolution of individual architectural smell instances over time, and the characteristics that define these instances. Three different types of architectural smells are taken into consideration and mined from a total of 524 versions across 14 different projects. The results show how different smell types differ in multiple aspects, such as their growth rate, the importance of the affected elements over time in the dependency network of the system, and the time each instance affects the system. They also cast valuable insights on what aspects are the most important to consider during prioritisation and refactoring activities.

Highlights

  • In recent years, there has been increasing interest on the concept of architectural smells (AS): issues in the architecture that often cause extra maintenance effort [1]

  • This causes the number of cycles among packages to increase, and since the number of classes per package increases over time in most of the systems analysed the smell density on packages is bound to increase as well

  • A similar pattern emerges for UD smells, which are constantly introduced in the system and have a growing trend

Read more

Summary

Introduction

There has been increasing interest on the concept of architectural smells (AS): issues in the architecture that often cause extra maintenance effort [1]. Several studies have explored this concept and identified different types of such smells [1], [2], [3], [4]. There is no work tracking the individual smell instances along system evolution. We need to study the evolution of AS in detail because AS are a different type of “affliction” than code smells: they usually involve more elements than code smells, they affect the system at a different scale, and they require more effort to be refactored [1]. The current theoretical knowledge on code smells cannot be applied to AS

Objectives
Results
Conclusion
Full Text
Published version (Free)

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call