Search

There are numerous commercial tools and research prototypes that offer support for measuring technical debt. However, different tools adopt different terms, metrics, and ways to identify and measure technical debt. These tools offer diverse features, and their popularity / community support varies significantly. Therefore, (a) practitioners face difficulties when trying to select a tool matching their needs; and (b) the concept of technical debt and its role in software development is blurred. We attempt to clarify the situation by comparing the features and popularity of technical debt measurement tools, and analyzing the existing empirical evidence on their validity. Our findings can help practitioners to find the most suitable tool for their purposes, and researchers by highlighting the current tool shortcomings.

Although architectural smells are one of the most studied type of architectural technical debt, their impact on maintenance effort has not been thoroughly investigated. Studying this impact would help to understand how much technical debt interest is being paid due to the existence of architecture smells and how this interest can be calculated. This work is a first attempt to address this issue by investigating the relation between architecture smells and source code changes. Specifically, we study whether the frequency and size of changes are correlated with the presence of a selected set of architectural smells. We detect architectural smells using the Arcan tool, which detects architectural smells by building a dependency graph of the system analyzed and then looking for the typical structures of the architectural smells. The findings, based on a case study of 31 open-source Java systems, show that 87% of the analyzed commits present more changes in artifacts with at least one smell, and the likelihood of changing increases with the number of smells. Moreover, there is also evidence to confirm that change frequency increases after the introduction of a smell and that the size of changes is also larger in smelly artifacts. These findings hold true especially in Medium–Large and Large artifacts.

Design patterns are recommended solutions for typical software design problems, with an extensively studied and documented impact on various quality factors. Flaws in design at a higher levels of abstraction are manifested in architectural smells. Some of those smells, similarly to code smells, can reduce the expected advantages of design patterns or even prevent their proper implementation. In this paper we study if and how design patterns and architectural smells are related, and how this knowledge could be exploited in practice. We present an empirical study with an analysis of 16 design patterns and 3 architectural smells in 60 open source Java systems. We analyze their diffuseness and correlation, and we extract association rules that describe their presence and dependencies. We demonstrate that there exist relationships between architectural smells and design patterns, both at the class and package levels. Some smells appear falsely positive, as they result from conscious decisions made by programmers, while the application of some patterns can be a cause of certain smells. Our results provide evidence that design patterns and architectural smells are related and affect each other. With knowledge about the relationships, programmers can avoid the side effects of applying some design patterns.

Today, software development is characterized by keywords such as collaborative, teamwork, distributed, agile, dynamic, qualitative and tool-supported among many others. In this paper, we present our experience in teaching three software development tools often used in industry in a software engineering course for undergraduate students: GitHub, SonarQube, and Microsoft Project. The main reasons behind the use of these tools during the development of a software project were: (1) students become familiar with examples of tools adopted in industry and academia, (2) students are enabled to collaborate in teams for the achievement of a common goal, and (3) students become aware of the management tasks needed by a project developed in teams. We exploited these tools in the software engineering course in the last three academic years. The students feedback on using these tools gathered through a questionnaire was positive. Students were enthusiastic in learning about new tools and their support for software development and management. In this paper we summarize the students feedback during three academic years and the lessons we have learned from their feedback.

Bad design decisions in software development can progressively affect the internal quality of a software system, causing architecture erosion. Such bad decisions are called Architectural Smells (AS) and should be detected as soon as possible, because their presence heavily hinders the maintainability and evolvability of the software. Many detection approaches rely on software analysis techniques which inspect the structure of the system under analysis and check with rules the presence of AS. However, some recent approaches leverage natural language processing techniques to recover semantic information from the system. This kind of information is useful to detect AS which violate "conceptual" design principles, such as the separation of concerns one. In this research study, I propose two detection strategies for AS detection based on code2vec, a neural model which is able to predict semantic properties of given snippets of code.

Architectural smells represent symptoms of problems at architectural level that can negatively impact internal software qualities and lead to architectural debt. Detecting architectural smells and identifying the most critical ones is the key to prioritize refactoring efforts and prevent software architecture erosion. In this paper we focus our attention on three architectural smells based on dependency issues, called Cyclic Dependency, Unstable Dependency, and Hub-Like Dependency. Moreover, we evaluate the PageRank and Criticality of these smells through the analysis of six projects. PageRank is a measure that estimates whether an architectural smell is located in an important part of the project, where the importance is evaluated according to how many parts of a project depend on the one involved in the architectural smell. We describe a case study on the analysis of the possible relation existing between the PageRank and Criticality of the smells. The results show how the two measures can be both used to locate the architectural smells that need particular inspections and attention.

With the introduction of microservice architecture, many investigate how to migrate their legacy systems into this architectural paradigm. The migration process requires the recovery of the project architecture to be migrated together with the knowledge necessary to understand how to decompose the code and obtain new microservices. At the moment, this process is realized mostly manually. This paper introduces an approach to identify candidate microservices in monolithic Java projects, implemented in a tool named Arcan and the validation of the approach in an industrial setting. The approach involves static analysis of the system architecture, architectural smell detection and topic detection, a text mining method used here to model software domains starting from code analysis. We report the feedbacks we get from an experienced industrial developer who carried out the migration described in the case study. From this collaboration with industry we collected useful information to enhance the approach, improve the tool and replicate the study.

Different indexes have been proposed to evaluate software quality and technical debt. Usually these indexes take into account different code level issues and several metrics, well known software metrics or new ones defined ad hoc for a specific purpose. In this paper we propose and define a new index, more oriented to the evaluation of architectural violations. We describe in detail the index, called Architectural Debt Index, that we integrated in a tool developed for architectural smell detection. The index is based on the detection of architectural smells, their criticality and their history. Currently only dependency architectural smells have been considered, but other architectural debt indicators can be considered and integrated in the index computation.

Code smells are sub-optimal coding circumstances such as blob classes or spaghetti code - they have received much attention and tooling in recent software engineering research. Higher-up in the abstraction level, architectural smells are problems or sub-optimal architectural patterns or other design-level characteristics. These have received significantly less attention even though they are usually considered more critical than code smells, and harder to detect, remove, and refactor. This paper describes an open-source tool called Arcan developed for the detection of architectural smells through an evaluation of several different architecture dependency issues. The detection techniques inside Arcan exploit graph database technology, allowing for high scalability in smells detection and better management of large amounts of dependencies of multiple kinds. In the scope of this paper, we focus on the evaluation of Arcan results carried out with real-life software developers to check if the architectural smells detected by Arcan are really perceived as problems and to get an overall usefulness evaluation of the tool.

Code smells represent well known symptoms of problems at code level, and architectural smells can be seen as their counterpart at architecture level. If identified in a system, they are usually considered more critical than code smells, for their effect on maintainability issues. In this paper, we introduce a tool for the detection of architectural smells that could have an impact on the stability of a system. The detection techniques are based on the analysis of dependency graphs extracted from compiled Java projects and stored in a graph database. The results combine the information gathered from dependency and instability metrics to identify flaws hidden in the software architecture. We also propose some filters trying to avoid possible false positives.