Search

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”.

Architectural Technical Debt (ATD) is considered as the most significant type of TD in industrial practice. In this study, we interview 21 software engineers and architects to investigate a specific type of ATD, namely architectural smells (AS). Our goal is to understand the phenomenon of AS better and support practitioners to better manage it and researchers to offer relevant support. The findings of this study provide insights on how practitioners perceive AS and how they introduce them, the maintenance and evolution issues they experienced and associated to the presence of AS, and what practices and tools they adopt to manage AS., Submitted and accepted to IEEE Software special issue on Technical Debt. This is a preprint

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.

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.

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.

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 (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.

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.

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.