Identifying and Evaluating Software Architecture Erosion
Riccardo Roveda · BOA (University of Milano-Bicocca) · 2018
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.