Capire codice altrui: una visione d'insieme rapida con l'UML

Architettura software e UML

Lei prende in carico un software scritto da qualcun altro. La documentazione è quasi inesistente, i commenti sono obsoleti e chi conosceva il codice non c'è più. Eppure deve correggere errori e integrare nuove funzioni – e in tempi brevi.

Il primo riflesso è leggere un file dopo l'altro. Ci vuole molto tempo e si ottengono soprattutto dettagli. Si procede più rapidamente con un'immagine dell'insieme: quali parti esistono, come sono collegate e che cosa succede in quale ordine? Proprio a questo serve l'UML, lo Unified Modeling Language.

Statica e dinamica: due punti di vista sullo stesso codice

L'UML conosce quattordici tipi di diagramma. Per entrare in un codice altrui ne bastano pochi. Si dividono in due gruppi: i diagrammi della statica mostrano la pianta, i diagrammi della dinamica mostrano lo svolgimento. Solo insieme danno una visione d'insieme.

Come procedere

1. Cercare i punti di ingresso. Dove inizia il programma? Nel software desktop sono comandi, voci di menu, pulsanti o eventi. Annoti i tre-cinque processi davvero importanti per il Suo compito.
2. Disegnare la statica. Parta da una classe che conosce già e ne segua le relazioni. Disegni solo le classi che appartengono ai Suoi processi. Attributi e metodi li inserisca solo quando Le servono.
3. Disegnare la dinamica. Percorra nel debugger ogni processo importante e lo fissi come diagramma di sequenza: un riquadro per ogni oggetto coinvolto, una freccia per ogni chiamata, il tempo scorre dall'alto verso il basso. Se un processo ha più passi o modalità di funzionamento, è utile anche un diagramma di stato.
4. Affiancare i diagrammi. Ora vede ciò che il codice da solo non mostra: classi che fanno la stessa cosa. Processi che calcolano più volte gli stessi dati. Dipendenze che puntano nella direzione sbagliata.
5. Parlare con gli esperti. Mostri i diagrammi a chi usa o cura il software. Cinque riquadri alla lavagna chiariscono spesso in pochi minuti ciò per cui nel codice servono giorni.

Leggere i diagrammi delle classi: sono le linee a decidere

Una classe è un riquadro con fino a tre scomparti: nome, attributi, metodi. La parte interessante sta tra i riquadri. Una linea continua significa «conosce». Un rombo vuoto significa «ha»: la parte può vivere senza il tutto, come un albero senza bosco. Un rombo pieno significa «è composto da»: la parte vive e muore con il tutto, come un ramo con il suo albero. Un triangolo vuoto indica l'ereditarietà, cioè «è un». Una freccia tratteggiata significa «usa».

Tre regole aiutano nella lettura: il rombo sta dalla parte del tutto, il triangolo dalla parte della superclasse, la punta della freccia dalla parte di ciò che è conosciuto. Alle estremità di una linea si trovano le molteplicità, ad esempio 1, 0..1 o 0..*.

Dalla pratica: calibrazione in 3 passi invece di 5

Un grande produttore internazionale di sensori ci ha chiesto di prendere in carico il software di calibrazione per scanner laser a ruota di specchi. Il fornitore precedente aveva cessato il lavoro. Il codice sorgente era a malapena leggibile e in parte offuscato. La calibrazione era composta da cinque passi che installatori di sistema, integratori e assistenza eseguono in tutto il mondo a ogni messa in servizio.

Abbiamo esaminato il codice passo dopo passo e rappresentato la struttura statica e i processi dinamici come modello UML. È emerso rapidamente che diversi passi di calibrazione si sovrapponevano. Nel codice era quasi impossibile accorgersene, nel diagramma invece sì. Abbiamo quindi riallineato matematicamente i passi tra loro ed eliminato quelli superflui. Oggi la calibrazione richiede tre passi invece di cinque. Poiché viene eseguita molto spesso in tutto il mondo, ciò fa risparmiare diverse migliaia di ore di lavoro all'anno.

Errori tipici

• Tutto in un'unica immagine. Un diagramma con quaranta riquadri non lo legge nessuno. Meglio tre piccoli diagrammi, ciascuno con una domanda a cui risponde.
• Solo generare. Molti strumenti generano diagrammi delle classi dal codice con un clic. È un buon punto di partenza, ma non ancora una visione d'insieme. Quella nasce solo selezionando e tralasciando.
• Solo la statica. Un diagramma delle classi mostra che cosa esiste, ma non che cosa succede. Il lavoro doppio nei processi lo trova solo nel diagramma di sequenza o di stato.
• Il rombo dalla parte sbagliata. Il rombo appartiene al tutto. Se sta dalla parte della parte, all'improvviso è la foglia a possedere l'albero.
• Composizione dove c'è solo un riferimento. Non ogni riferimento nel codice è possesso. Verifichi chi crea un oggetto e chi lo rilascia.
• Diagrammi che invecchiano. Un diagramma che non corrisponde più al codice è peggio di nessun diagramma. Lo mantenga piccolo e lo aggiorni quando il processo cambia.

Fonti: Ebi F. Eilber, AutoCAD .NET API (libro tecnico, uscita prevista nel 2027), capitolo «Leggere l'UML»; caso di studio «Calibrazione di laser a ruota di specchi: 3 passi invece di 5», Casi di studio Cadida.