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
Summary
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
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Disclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.