Search

The past few years saw the rise of microservices studies and best practices, along with wide industrial adoption of this architectural style. We now witness the birth of another challenging topic: microservices quality. Like other kinds of architectures, also microservices suffer from erosion and technical debt, whose symptoms can be the appearance of microservices smells, which impact negatively on the system's quality, by hindering, for example, its maintainability. In this paper we propose a tool called Aroma, to reconstruct microservices architectures and detect microservices smells, based on the dynamic analysis of microservices execution traces. We describe the main features of the tool, the strategies adopted for microservice smells detection and the first preliminary experimentation.

In this paper, we share our experience in designing and running a project-based exam for a Software Engineering course at the undergraduate level. We underline the teaching objectives and content of the course which aim to prepare students for the industrial environment, e.g., various design perspectives on the project, software quality assurance and evaluation, tools for development and software quality assessment, project management and team work. We present our project-based exam and summarize hints on its design, organization, and evaluation. Project examples are also introduced.

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.

Technical debt is candidate to be the next buzzword in software engineering, and the number of studies evaluating the technical debt of software projects is increasing. A particular and dangerous type of debt is the architectural debt, i.e., the consequences of sub-optimal design decisions. Currently, there are no studies about the evaluation of architectural debt in MultiAgent Systems (MAS) and platforms. Hence, in this paper we propose the analysis of four well-known MAS development platforms, with the aim of evaluating their architectural debt and open the discussion in this field. We exploit a tool, named Arcan, developed for architectural smell detection and for the computation of an architectural debt index. The results show that MAS development platforms are subjected to architectural debt, and in particular to the presence of Cyclic Dependency smells. However, there is evidence that the minimum amount of debt is reached when developers report “bug fixes” and “Improvements”.

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.

Architectural technical debt (TD) is the most significant type of TD in industrial practice. Our goals in this study were to better understand the phenomenon of architectural smells, help practitioners better manage them, and offer relevant support to researchers

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.

Technical debt (TD) has been recognized as an important quality problem for both software architecture and code. The evolution of TD techniques over the past years has led to a number of research and commercial tools. In addition, the increasing trend of opportunistic reuse (as opposed to systematic reuse), where developers reuse code assets in popular repositories, is changing the way components are selected and integrated into existing systems. However, reusing software opportunistically can lead to a loss of quality and induce TD, especially when the architecture is changed in the process. However, to the best of our knowledge, no studies have investigated the impact of opportunistic reuse in TD. In this paper, we carry out an exploratory study to investigate to what extent reusing components opportunistically negatively affects the quality of systems. We use one commercial and one research tool to analyze the TD ratios of three case systems, before and after opportunistically extending them with open-source software.

Technical debt indexes are metrics for assessing the quality of a software system. Both academic and commercial tools have begun to provide computations of such indexes based on design violations and smells (e.g., cycles among system elements). When computing a debt index for a given project, a common use case is that engineers look at the index values for spotting design issues that negatively affect system evolution and quality. In this context, those smells being critical for the system architecture should be promptly identified soastoe valuate proper remediation actions. However, the interpretation of an index value in terms of problematic smells is usually a manual and labor-intensive task for engineers. To help with this task, we propose a tool called Sen4Smells that performs an automated sensitivity analysis for a given debt index based on the evolution of both the index values and the corresponding smells across (past) system versions. The Sen4Smells output is a ranking of smells that, due to their variations or instability, are major contributors to the debt index, and thus, can impact on architecture quality. Sen4Smells is designed as a pipeline that combines information from existing tools for smell detection, predefined d ebt i ndex f ormulas, and the Sobol method for sensitivity analysis. As a demonstration of the tool functionality, we briefly present implementations for the Arcan and Sonargraph tools with their respective debt indexes.

Architectural anomalies, also known as architectural smells, represent the violation of design principles or decisions that impact internal software qualities with significant negative effects on maintenance, evolution costs and technical debt. Architectural smells, if early removed, have an overall impact on reducing a possible progressive architectural erosion and architectural debt. Some tools have been proposed for their detection, exploiting different methods, usually based only on static analysis. This work analyzes how dynamic analysis can be exploited to detect architectural smells. We focus on two smells, Hub-Like Dependency and Cyclic Dependency, and we extend an existing tool integrating dynamic analysis. We conduct an empirical study on ten projects. We compare the results obtained comparing a method featuring dynamic analysis and the original version of Arcan based only on static analysis to understand if dynamic analysis can be successfully used. The results show that dynamic analysis helps identify missing architectural smells instances, although its usage is hindered by the lack of test suites suitable for this scope.

Un'architettura software è erosa (o degradata) se mostra una progressiva perdita di integrità strutturale a causa di violazioni dei principi di progettazione. I sistemi erosi soffrono di Architectural Technical Debt (ATD), lo sforzo aggiuntivo richiesto agli sviluppatori per gestire i difetti causati dall'erosione. Un sintomo dell'accumulo di ATD è la presenza di Architectural Smells (AS), decisioni di software design che hanno un impatto negativo sulla qualità interna del sistema software. I sistemi affetti da AS soffrono di maggiori costi di manutenzione e sono più difficili da evolvere. Questa tesi indaga sei diversi tipi di AS che violano diversi principi di design in progetti Java monolitici Open-Source e industriali. Identifichiamo gli AS con il nostro strumento, Arcan, e introduciamo la sua nuova estensione per la rappresentazione dei software concerns. Discutiamo poi gli AS dal punto di vista dei professionisti, cercando di riassumere come gli AS sono percepiti e validando i risultati di Arcan. Riportiamo anche i risultati dei nostri studi empirici riguardanti l'evoluzione e la correlazione di AS e ATD. Infine, presentiamo i nostri primi risultati riguardanti la migrazione e la manutenzione di architetture a microservizi, con particolare attenzione al rilevamento degli odori dei microservizi., A software architecture is eroded (or degraded) if it shows a progressive loss of structural integrity due to design principle violations which leads to the deviation of the implemented architecture from the intended architecture. Eroded systems suffer from Architectural Technical Debt (ATD), the additional effort required by developers to manage the shortcomings caused by the erosion. A symptom of the accumulation of ATD is the presence of Architectural Smells (AS), design decisions that impact negatively on the internal system quality. Systems affected by AS suffer from higher maintenance costs and are harder to evolve. This thesis investigates six different types of AS violating different design principles in Open-Source and industrial monolithic Java projects. We identify AS with our tool, Arcan, and introduce its new extension for the representation of software concerns. We then discuss AS from the point of view of practitioners, trying to summarise how AS are perceived and validating Arcan results. We also report the results of our empirical studies concerning AS and ATD evolution and correlation. Finally, we present our first results concerning the migration and maintenance of microservices architectures, with a focus on the detection of microservices smells.

We observed a great and increasing interest in the last few years towards the evaluation of technical debt of software projects, in particular in the direction of code and architectural debt evaluation. This kind of analysis has not yet been performed for IoT projects. Hence, in this paper we start this exploration through the analysis of four Open Source IoT projects. We focus our attention on architectural debt and we exploit a tool, called Arcan, developed for architectural smell detection and for the computation of an architectural debt index. The results show that also IoT projects are subjected to architectural debt, and in particular to the presence of Cyclic Dependency and Unstable Dependency smells. However, there is evidence that the continuous refactoring of the code helps in avoiding the increase of debt, hence also developers of IoT projects should schedule periodical clean-ups of their code.

With the adoption of microservices architectural styles, practitioners started noticing increasing pitfalls in managing and maintaining such architectures, with the risk of introducing architectural debt. Previous studies identified different microservice smells (also named anti-patterns) that harm microservices architectures. However, according to our knowledge, there are no tools that can automatically detect microservice smells, so their identification is left to the experience of the developer. In this paper, we extend an existing tool developed for the detection of architectural smells to explore microservices architecture through the detection of three microservice smells: Cyclic Dependencies, Hard-Coded Endpoints, and Shared Persistence. We detected the smells on five open-source projects implemented with microservices and manually validated the precision of the detection results. This work aims to open new perspectives on facing and studying architectural debt in the field of microservices architectures.

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.

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.

Architectural smells can be detrimental to system maintainability and evolvability, and represent a source of architectural debt. Thus, it is very important to be able to understand how they evolved in the past and to predict their future evolution. In this paper, we evaluate if the existence of architectural smells in the past versions of a project can be used to predict their presence in the future. We analyzed four Java projects in 295 Github releases and we applied four different supervised learning models for the prediction in a repeated cross-validation setting. We found that historical architectural smell information can be used to predict the presence of architectural smells in the future. Hence, practitioners should carefully monitor the evolution of architectural smells and take preventative actions to avoid introducing them and stave off their progressive growth.

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.

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.

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.