Debugging reversibile: riavvolgere il software

Una serie di interviste dedicate all’innovazione tecnologica e al pensiero progettuale: esploriamo le storie dietro invenzioni e soluzioni che rispondono a sfide reali. Un’occasione per approfondire processi creativi, approcci metodologici e impatti concreti sul mercato e sulla società.

L'articolo è di Francesca Montuschi, del Settore della comunicazione e informazione del dipartimento.

In sistemi complessi, concorrenti e distribuiti, la capacità di individuare e correggere un errore rappresenta una condizione necessaria e imprescindibile per la sostenibilità dell’intero ecosistema digitale. Il debugging – l’insieme delle tecniche utilizzate per individuare e sanare errori nel software, al quale, secondo stime consolidate, gli sviluppatori dedicano circa metà del loro tempo – diventa particolarmente critico quando il software è concorrente, ovvero caratterizzato da più flussi di esecuzione simultanei. Alcuni errori emergono solo in condizioni rarissime, dovute a specifici intrecci tra esecuzioni parallele, difficili da riprodurre e ancora più difficili da analizzare. 

Nei contesti reali, inoltre, una parte crescente del software si basa su componenti opache o proprietarie, per le quali il codice sorgente non è disponibile. In questo quadro si inserisce il progetto europeo REGRADE-CS, coordinato da Ivan Lanese, professore al Dipartimento di Informatica – Scienza e Ingegneria dell’Università di Bologna, il quale da oltre un decennio conduce studi sul debugging reversibile. 

Debugging reversibile ovvero riavvolgere il film. Giusto? 

Nel debugging tradizionale l’osservazione procede solo in avanti, ma il punto in cui l’errore si manifesta raramente coincide con il punto della sua origine. Il debugging reversibile consente invece di tornare indietro lungo l’esecuzione, analizzando la sequenza di eventi che ha condotto allo stato errato e facilitando l’individuazione della causa del malfunzionamento. 

Nell’industria, e non solo, si ha spesso a che fare con componenti proprietarie, servizi esterni o software sviluppato al di fuori della propria sfera di controllo. Come è possibile fare debugging reversibile quando il codice sorgente non è completamente accessibile? 

Il debugging reversibile tradizionale presuppone di disporre di tutte le informazioni necessarie per ricostruire l’esecuzione all’indietro. Il nostro approccio, invece, consiste nel lavorare per approssimazioni informate: se non si hanno tutte le informazioni, è comunque possibile utilizzare quelle disponibili per restringere il campo delle possibilità. In altre parole, anche se non si conosce esattamente quale esecuzione abbia portato allo stato errato, è spesso possibile escluderne alcune e concentrarsi su un sottoinsieme compatibile con le osservazioni effettuate. Questo approccio, detto grey box debugging, si colloca tra la white box e la black box: alcune componenti sono pienamente accessibili, altre solo parzialmente osservabili.  

I metodi formali consentono di dimostrare proprietà precise del software, ma sono difficili da applicare su larga scala e a sistemi complessi. Il debugging, invece, rappresenta uno strumento fondamentale quando si osserva un comportamento errato senza disporre di una dimostrazione formale. Sono tra loro complementari? 

Sì. I metodi formali sono tecniche matematiche che permettono di dimostrare proprietà del software, ad esempio che un sistema non andrà mai in deadlock. Il loro grande vantaggio è che, una volta dimostrata una proprietà, questa vale per tutte le possibili esecuzioni. Il problema è che tali tecniche sono difficili da applicare a sistemi molto grandi e complessi. Il debugging, invece, entra in gioco quando si osserva un comportamento senza avere necessariamente una dimostrazione formale. I due approcci non sono alternativi, ma complementari. I metodi formali vengono utilizzati sulle parti più sensibili, per esempio in ambito aerospaziale, mentre il debugging resta fondamentale per l’analisi e la manutenzione del sistema nel suo insieme. 

L’intelligenza artificiale viene ormai utilizzata anche per individuare bug, soprattutto in ambito di sicurezza. In questo senso, possiamo considerarla una forma di debugging automatizzato? 

Esistono molti limiti. L’AI opera in modo statistico e probabilistico, cercando pattern nei dati, e non segue necessariamente una logica sequenziale come quella umana. Questo la rende efficace nel riconoscere anomalie, ma meno adatta a fornire spiegazioni causali chiare. Nel debugging, e in particolare nel debugging reversibile, comprendere perché qualcosa è accaduto è spesso più importante che sapere semplicemente che qualcosa non funziona. 

Uno dei nodi della ricerca sul debugging reversibile riguarda la sua industrializzazione, ovvero la scalabilità.  

Trasformare prototipi accademici in strumenti utilizzabili su centinaia di migliaia di righe di codice, e architetture complesse rappresenta una sfida tutt’altro che risolta. Nonostante ciò, l’impatto potenziale è significativo, soprattutto per le Pmi, che spesso operano con software non interamente sotto il loro controllo. Disporre di strumenti in grado di ridurre tempi e costi di individuazione degli errori può fare la differenza in termini di qualità, affidabilità e competitività. 

A livello europeo, il debugging è considerato una priorità strategica? 

Non in modo diretto. Il debugging è una tecnologia abilitante trasversale: riguarda qualunque sviluppo software, ma raramente viene percepito come un problema autonomo. A livello europeo si tende a investire maggiormente in sicurezza, intelligenza artificiale o efficienza energetica, poiché godono di una maggiore visibilità pubblica. Tuttavia, quando un problema diventa centrale per la società, le soluzioni spesso risiedono in studi avviati molti anni prima. Il debugging reversibile ne è un esempio emblematico: una linea di ricerca nata da esigenze teoriche che oggi si confronta con problemi concreti di affidabilità, sostenibilità ed evoluzione del software. 

La reversibilità è un paradigma centrale nella sua ricerca. Lo sta applicando anche allo sviluppo di computazioni energeticamente più efficienti. 

La computazione reversibile implica che le operazioni possano essere eseguite sia in avanti sia all’indietro senza perdita di informazione. Dal punto di vista fisico, questo aspetto è rilevante perché la perdita di informazione è strettamente legata alla dissipazione di energia sotto forma di calore. L’obiettivo è sfruttare la reversibilità lungo l’intera catena computazionale, dal software fino all’hardware, al fine di ottenere benefici energetici concreti e misurabili.

Riproduzione riservata © copyright 

Hai qualcosa da raccontarci? Desideri essere intervistato?

La redazione web del dipartimento è sempre alla ricerca di nuovi contenuti.

Scrivi una mail a disi-redazioneweb@unibo.it