Sto studiando per un esame di ingegneria del software, per la laurea triennale in informatica, il che significa reimparare UML un’altra volta. Lo conosco da 25 anni e l’ho usato professionalmente per 15, da quando un mio vecchio datore di lavoro automotive mi mandò a un corso su Enterprise Architect.

Ricordo ancora chi ne era entusiasta: i formatori EA, il cui stipendio dipendeva da quanto io amassi lo strumento (o meglio, da quanto lo amasse il mio capo), e un tipo particolare di architetto: quelli promossi in silenzio lontano dal codice perché a programmare non erano granché, e che come architetti si rivelavano poi esattamente altrettanto bravi. UML dava loro qualcosa che la codebase non aveva mai concesso: un deliverable che nessuno poteva falsificare. Il codice viene testato. Il codice va in produzione oppure no. Un diagramma se ne sta lì, con l’aria di essere lavoro.

In 15 anni la mia esperienza onesta è che l’UML formale ha creato più attrito che valore. Una delle poche eccezioni è il sequence diagram. I nostri vivono come PlantUML, testo nel repo, versionato e diffabile come tutto il resto. Quello è UML come comunicazione, non come modello condannato a essere tenuto in sincrono. Nel momento in cui un diagramma pretende di essere la fonte di verità, comincia a mentire, perché si scosta dal codice più in fretta di quanto chiunque abbia voglia di mantenerlo.

Ed ecco la parte che mi colpisce ADESSO, mentre ci studio sopra: lavoro ancora nell’automotive, e siamo orgogliosamente conformi ASPICE. L’industria che ha trasformato la modellazione formale in una religione. Eppure. La conformità non richiede modellazione formale. ASPICE chiede risultati: requisiti, architettura, design e soprattutto tracciabilità bidirezionale tra di essi. Non chiede UML, SysML o Enterprise Architect. Un assessor competente verifica che i risultati reggano e che la tracciabilità sopravviva, non che tu abbia scelto la notazione “giusta”.

Ecco quindi cosa facciamo davvero. Tutta la nostra documentazione di ingegneria del software vive in Sphinx, nel repo. La tracciabilità è imposta da script nella CI/CD. Una pull request non viene mergiata se la tracciabilità è rotta. È tutto qui il punto. Non abbiamo fatto della tracciabilità qualcosa da ispezionare prima di un audit. L’abbiamo resa un invariante mantenuto per costruzione. Il costo di tenere onesti i collegamenti ricade su chi cambia il codice, nel momento in cui lo cambia, col contesto ancora fresco, invece che su un quality engineer costretto a fare archeologia mesi dopo. Più rigoroso che mantenere a mano le matrici dentro EA, proprio perché è codice eseguibile invece di un diagramma da contemplare.

Gli architetti che non sapevano programmare tutto questo non avrebbero potuto costruirlo. Serve trattare la conformità come un problema di ingegneria, non di documentazione. E gli architetti che ho adesso sono prima di tutto ottimi programmatori.

Ristudiare UML mi ha ricordato quanto sono fortunato a stare nel team in cui sto. Non perché la teoria sia sbagliata, il bisogno a cui risponde è reale. Ma perché questo team ha tenuto il 5% che comunica e ha buttato via il 95% che recita il rigore davanti a un pubblico. Non lo do per scontato.

Se il tuo “modello” esiste solo per essere mostrato a un assessor, non è ingegneria. È teatro con uno stencil UML.

Pubblicato originariamente su LinkedIn, in inglese.

Ultima modifica 16/06/2026