Sintesi Tecnica: Verso l'Identificazione Automatica dei Sintomi di Violazione dell'Erosione Architetturale

1. Definizione del Problema

L'erosione dell'architettura del software si verifica quando il sistema implementato diverge dalla sua architettura prevista, portando a un degrado della manutenibilità, delle prestazioni e della sostenibilità. Sebbene esistano vari sintomi di erosione (strutturali, qualitativi ed evolutivi), i sintomi di violazione — istanze in cui il codice viola principi, pattern o decisioni di progettazione — sono gli indicatori più immediati che richiedono attenzione.

Tradizionalmente, l'identificazione di queste violazioni si affida all'analisi statica del codice o alla revisione manuale di artefatti testuali. Tuttavia, gli strumenti di analisi statica spesso soffrono di una rilevazione limitata dei tipi di violazione, di un supporto linguistico ristretto e dell'incapacità di catturare le sfumature semantiche. L'identificazione manuale attraverso le code review è accurata ma laboriosa, richiede molto tempo ed è soggetta a errori umani. Nonostante la ricchezza di informazioni contenute nei commenti delle code review riguardanti le decisioni architettoniche, nessun studio precedente aveva investigato l'identificazione automatica dei sintomi di violazione specificamente all'interno di artefatti testuali come i commenti delle code review.

2. Metodologia

Lo studio impiega un approccio empirico multi-fase per valutare la fattibilità dell'automazione del rilevamento dei sintomi di violazione dai commenti delle code review.

2.1 Costruzione del Dataset

• Fonte: Commenti delle code review da quattro progetti open-source: OpenStack (Nova, Neutron) e Qt (Base, Creator), raccolti tramite l'API REST di Gerrit tra il 2014 e il 2020.
• Etichettatura: È stato estratto un dataset di 21.583 commenti. Quattro ricercatori hanno etichettato manualmente 606 commenti come "sintomi di violazione" (classe positiva) e 606 come "non violazioni" (classe negativa) per creare un set di addestramento bilanciato. L'accordo tra gli annotatori (Cohen's Kappa) è stato di 0,857.
• Test Set Sbilanciato: È stato costruito un separato test set non utilizzato di 150 commenti (7 violazioni, 143 non violazioni) per simulare le condizioni del mondo reale a bassa prevalenza (~4,7% di tasso positivo).

2.2 Fase 1: Classificazione ML/DL

Gli autori hanno addestrato e valutato i classificatori utilizzando tre tecniche di word embedding pre-addestrate: word2vec, fastText e GloVe.

• Machine Learning (ML): Sono stati testati cinque algoritmi: Support Vector Machine (SVM), Logistic Regression (LR), Decision Tree (DT), Bernoulli Naive Bayes (NB) e k-Nearest Neighbor (kNN).
• Deep Learning (DL): È stato addestrato un modello TextCNN.
• Apprendimento d'Insieme (Ensemble Learning): Una strategia di voto di maggioranza (Hard Voting) è stata applicata per combinare le previsioni dei singoli classificatori.
• Ottimizzazione degli Iperparametri: La ricerca a griglia (Grid search) è stata utilizzata per i modelli ML. Per il DL, le impostazioni specifiche includevano embedding a 200 dimensioni, un tasso di apprendimento di 0,001 e un dropout di 0,25.
• Gestione dello Sbilanciamento: Tecniche di apprendimento cost-sensitive (ad es. pesatura delle classi, campionamento SMOTE, matrici di costo) sono state applicate ai dati di addestramento per affrontare il naturale sbilanciamento nel test set.

2.3 Fase 2: Validazione

• Qualitativa: Un sondaggio online (24 risposte) e interviste semi-strutturate (6 partecipanti) sono stati condotti con professionisti coinvolti nelle code review originali per valutare l'utilità percepita dell'approccio automatizzato.
• Quantitativa: È stato eseguito un esperimento controllato con 35 sviluppatori (gruppi di Controllo vs. Sperimentale). Il gruppo Sperimentale ha ricevuto suggerimenti generati dai classificatori che evidenziavano potenziali sintomi di violazione. La metrica è stata la proporzione di violazioni correttamente identificate e corrette.

2.4 Fase 3: Confronto con LLM

Tre Large Language Models (LLM) allo stato dell'arte sono stati valutati utilizzando il prompt engineering (apprendimento Zero-shot e Few-shot con 2, 4, 6 e 10 esempi):

• GPT-4o (Proprietario)
• Qwen-3 (Open-weight)
• DeepSeek-R1 (Open-source MoE)
  Sono state utilizzate strategie di prompting attente ai costi per mitigare il bias verso la classe maggioritaria nell'impostazione sbilanciata.

3. Risultati Chiave

3.1 Prestazioni ML/DL (RQ1 & RQ2)

• Miglior Classificatore: Tra gli approcci ML/DL, il classificatore SVM con embedding word2vec ha ottenuto le prestazioni più elevate sul dataset bilanciato (F1-score: 0,808, Precision: 0,789, Recall: 0,828).
• Impatto degli Embedding: Gli embedding di parole a 200 dimensioni hanno generalmente superato i modelli a 100 e 300 dimensioni. Gli embedding fastText hanno prodotto risultati relativamente buoni per i modelli DL (TextCNN).
• Ensemble: I classificatori ensemble che utilizzano il voto di maggioranza hanno generalmente migliorato le prestazioni rispetto ai singoli classificatori ML (ad es. miglioramenti dell'F1-score fino al 13,10%). Tuttavia, l'ensemble non ha migliorato costantemente i classificatori DL (TextCNN).
• Robustezza allo Sbilanciamento: In condizioni naturali di bassa prevalenza, i modelli SVM cost-sensitive hanno mantenuto alti punteggi Macro-F1 (0,816), dimostrando efficacia in scenari realistici. L'analisi della significatività statistica (test di Friedman) ha confermato che le differenze di prestazione non erano dovute a variazioni casuali.

3.2 Prestazioni LLM (RQ4)

• Superiorità: I migliori classificatori basati su LLM hanno superato gli approcci ML/DL tradizionali.
• Top Performer: Il modello GPT-4o con un'impostazione 2-shot ha raggiunto l'F1-score più alto (0,851) e l'accuratezza (0,848) tra tutti i modelli valutati.
• Limitazioni dell'Ensemble: A differenza del ML/DL, l'ensemble di LLM (tra modelli o impostazioni di shot) non ha migliorato costantemente le prestazioni e talvolta le ha degradate, probabilmente a causa dell'alto livello di base dei singoli LLM e del potenziale di amplificazione delle allucinazioni.

3.3 Validazione Pratica (RQ3)

• Feedback dei Professionisti: Il 66,7% dei rispondenti al sondaggio ha concordato che i sintomi identificati rappresentavano potenziali violazioni architettoniche. La maggior parte ha concordato che l'approccio potesse aiutare a localizzare e dare priorità ai problemi più velocemente rispetto alla revisione manuale.
• Esperimento Controllato: Fornire suggerimenti sui sintomi di violazione ha migliorato significativamente i tassi di rilevamento degli sviluppatori. Il tasso di identificazione e correzione corretta delle violazioni (Categoria 1) è aumentato dal 13,0% (Controllo) al 29,4% (Sperimentale). Il tasso di rilevamento complessivo (Categoria 1 + 2) è passato dal 25,9% al 64,7%, un miglioramento relativo del 150%.

4. Contributi Chiave

1. Dimostrazione della Fattibilità: Il primo studio a dimostrare la fattibilità dell'identificazione automatica dei sintomi di violazione dell'architettura dai commenti delle code review utilizzando ML, DL e LLM.
2. Confronto Completo: Un rigoroso confronto tra 15 classificatori ML, 4 classificatori DL e 3 LLM attraverso diverse dimensioni di embedding e impostazioni di shot.
3. Approfondimenti Validati dai Professionisti: Evidenza empirica da sondaggi, interviste e un esperimento controllato che conferma che i suggerimenti automatizzati migliorano significativamente le prestazioni degli sviluppatori nel rilevamento di problemi architettonici.
4. Dataset e Strumenti: Il rilascio di un dataset etichettato di violazioni architettoniche dalle code review e del pacchetto di replica per supportare la ricerca futura.

5. Significato e Rivendicazioni

Il documento sostiene che l'identificazione automatica dei sintomi di violazione funge da livello complementare alla moderna code review, offrendo avvisi precoci per prevenire l'integrazione di codice che devia dall'architettura prevista.

• Per i Professionisti: L'approccio offre uno strumento pratico per ridurre il carico cognitivo nell'identificazione di problemi architettonici, aiutando i team a dare priorità al refactoring e a mantenere l'integrità architettonica.
• Per la Ricerca: Lo studio evidenzia che, sebbene gli LLM (specificamente GPT-4o) offrano attualmente prestazioni superiori, gli approcci ML tradizionali (SVM con word2vec) rimangono altamente efficaci e più efficienti in termini di costi per compiti specifici di classificazione del testo, specialmente quando le risorse computazionali sono limitate.
• Metodologico: Il lavoro colma il divario tra la verifica teorica della conformità dell'architettura e i flussi di lavoro pratici degli sviluppatori, sfruttando il ricco contesto semantico presente nelle discussioni delle code review.

Gli autori concludono che, sebbene rimangano sfide riguardanti i falsi positivi e i costi di integrazione, le prove quantitative e qualitative supportano fortemente l'integrazione di tali tecniche automatizzate nei cicli di vita dello sviluppo del software per migliorare la sostenibilità del sistema.