Identifying and Evaluating Software Architecture Erosion

When it is necessary to evaluate software quality, it is possible to consider different features: such as code smells, architectural smells and metrics. Code smells are symptoms of possible problems at code level that can be removed through different refactoring techniques and can be used as surface indicators of design problems. Instead, architectural smells can be seen as their counterpart at the architecture level. Architectural smells can derive from commonly used architectural decisions, intentional or not, that negatively impact internal software quality with large effects on software maintainability. If identified in a system, they are usually considered more critical than code smells, due to their effect on maintainability issues. For what concerns code smells and metrics, many tools have been developed, both open source and commercial. Architectural smells (AS) received less attention, even if some tools have been developed. During my thesis, I focused my attention on architectural smells detection, architectural smell refactoring and a definition of a new quality index. I have developed an architectural smells detection tool with a focus on the detection of architectural smells, that I call instability architectural smells. The instability architectural smells have an impact on the Instability metric, that it is the effort to change a package without impact other packages within the application, software evolution and maintainability. I have identified six architectural smells: Unstable Dependency, Implicit Cross Package Dependency, Hub-Like Dependency, Cyclic Dependency, Multiple Architectural Smell and Specification-Implementation Violation. The Implicit Cross Package Dependency is detected at file level using the development history and the others are detected both at class and/or package level. The tool, called Arcan, detects all these smells. I have developed Arcan through an evaluation of different dependency issues. I also worked on the prediction of architectural smells and their impact on system’s quality using the development history. I studied techniques to spot rules among architectural smells to forecast possible problems in the future, by applying machine learning algorithms on the history data of several open source projects. When that architecture and design process are compromised by poor or hasted design choices, the architecture is often subject to different architectural problems or anomalies, that can lead to software faults, failures or quality downfalls such as a progressive architecture erosion. Systems erode over time when they evolve bringing architectural erosion and degradation of applications, and the challenge to keep the intended architecture aligned with code is still hard when software engineers must deal with obsolescence and maintenance. In order to combat obsolescence and rigidity of designs, the metaphor of Technical Debt (TD) sign debt) introduced by Cunningham to explain the causes and need of refactoring, covers an important role for software maintenance. Some tools offer some kind of Technical Quality Index, e.g., Technical Debt Index, that offers an evaluation of the overall quality of an analyzed project.. In most cases, the available Indexes are not directly useful when evaluating a single project. These Indexes are in particular useful on a relative scale; in the case a single team evaluates an entire portfolio of applications and to rank new projects with respect to the old/existing ones. In this context, I worked on the definition of a new TD index through Arcan, with a focus on architectural smell detection and the severity evaluation of each architectural smell (i.e., severity measures the negative impact on the project), and I experimented this new index on a large dataset of projects.

Quando è necessario valutare la qualità del software, è possibile prendere in considerazione diversi aspetti: ad esempio i code smell, gli architectural smell e le metriche. I code smell sono sintomi di possibili problemi a livello di codice, i quali possono essere rimossi attraverso diverse tecniche di refactoring e possono essere considerati come sintomi di problemi a livello di design. La controparte dei code smell a livello architetturale sono gli architectural smell: questi possono nascere a partire da decisioni architetturali comunemente adottate che impattano negativamente la qualità interna del software, con pesanti conseguenze sulla mantenibilità dello stesso. Per quanto riguarda code smell e metriche, sono stati sviluppati molti tool, sia di carattere commerciale che open source. Lo studio degli architectural smell ha ricevuto meno attenzione, pochi tool sono stati sviluppati per la loro rilevazione. Nel corso della mia tesi, ho concentrato l’attenzione sulla rilevazione e rimozione degli smell architetturali; inoltre mi sono occupato della definizione di un nuovo indice di qualità. Ho sviluppato un tool per la rilevazione di architectural smell, in particolare per quelli che ho definito instability architectural smell. Quesi smell impattano la metrica che riguarda l’instabilità, cioè l’impegno necessario per modificare un package senza influenzare altri package all’interno dell’applicazione, l’evoluzione del software stesso e la sua mantenibilità. Ho identificato sei architectural smell: Unstable Dependency, Cross Package Dependency, Hub Like Dependency, Cyclic Dependency, Multiple Architectural Smell and Specification-Implementation Violation. Lo smell chiamato Implicit Cross Package Dependency viene rilevato a livello di file usando la storia dello sviluppo software, mentre gli altri sono rilevati sia a livello di classe che a livello di package. Il tool, di nome Arcan, rileva tutti gli smell citati. Sono interessato alla rilevazione di architectural smell e al loro impatto sulla qualità del sistema attraverso l’uso della storia dello sviluppo software. Ho studiato alcune tecniche per estrarre regole dalla presenza di architectural smell in modo da prevedere possibili problemi futuri. Ho applicato algoritmi di apprendimento automatico sui dati della storia dello sviluppo di molti progetti open source. Quando i processi che portano alla definizione del design e dell’architettura sono compromessi dall’adozione di decisioni precarie o frettolose, l’architettura è spesso soggetta a molti problemi e anomalie: queste possono portare a guasti e fallimenti software oppure al tracollo della qualità, come per esempio una progressiva erosione dell’architettura. I sistemi software sono soggetti all’erosione nel tempo quando evolvono portando con sé un’architettura e un’applicazione degradata; la sfida di mantenere l’architettura definita in fase di progettazione allineata con il codice vero e proprio è ancora più ardua quando gli ingegneri software devono confrontarsi con l’obsolescenza e la manutenzione del software. Alcuni tool offrono tipologie di Indice di Qualità, come il Technical Debt, che propone una valutazione della qualità generale del software sotto analisi. Il termine Technical Debt Index(TDI) fa riferimento a tutti i tipi di indice di qualità calcolati dai tool. Nella maggior parte dei casi, gli indici disponibili non offrono un’immediata utilità nella valutazione di singoli progetti. Questi indici sono invece particolarmente utili quando un solo team si trova a dover valutare un intero portfolio applicativo e classificare nuovi progetti rispetto progetti più vecchi/già esistenti. Ho lavorato alla definizione di un nuovo TD index sfruttando il tool Arcan, concentrandomi sulla valutazione della severità degli architectural smell dove la severità misura l’impatto negativo di un singolo smell sul progetto.