Tesi informatica 2026: documentare codice e progetto software in UML per la commissione

Hai scritto migliaia di righe di codice, il tuo sistema funziona, e ora ti trovi davanti al momento più temuto: trasformare tutto quel lavoro tecnico in una tesi che la commissione riesca a capire, valutare e apprezzare. La documentazione software — e in particolare i diagrammi UML — è il ponte tra il tuo progetto e chi lo esamina. Fatta bene, dimostra non solo che il tuo codice funziona, ma che hai pensato al design in modo strutturato e professionale.

Questo articolo ti guida passo dopo passo nella documentazione di una tesi di informatica nel 2026: quali diagrammi UML includere, come strutturare i capitoli, dove inserire il codice sorgente, e come presentare tutto questo alla commissione del Politecnico di Milano, di Bologna, della Sapienza o di qualsiasi altro ateneo italiano.

Perché UML nella tesi di informatica

UML — Unified Modeling Language — è uno standard ISO (ISO/IEC 19501) per la modellazione visuale dei sistemi software. Non è un linguaggio di programmazione: è un linguaggio grafico che descrive la struttura e il comportamento di un sistema in modo indipendente dall’implementazione. Per questo è lo strumento perfetto per la tesi: permette a qualsiasi commissario — anche a chi non conosce Python, Java o il tuo framework specifico — di capire come hai costruito il sistema.

Presentare una tesi di informatica senza diagrammi UML è come consegnare un progetto di architettura senza piante e sezioni: il costruttore potrebbe anche capire di cosa hai bisogno, ma non può valutare la qualità del design. I diagrammi UML dimostrano che hai affrontato la progettazione in modo metodico prima di scrivere il codice — o che sei stato capace di ricostruirla a posteriori con altrettanta chiarezza.

I 5 diagrammi UML essenziali per una tesi di laurea

UML definisce 14 tipi di diagrammi divisi in strutturali e comportamentali. Per una tesi di laurea in informatica non servono tutti: ne bastano cinque, scelti in base alle caratteristiche del tuo progetto.

1. Diagramma dei casi d’uso (Use Case Diagram)

Il diagramma dei casi d’uso descrive le funzionalità del sistema dalla prospettiva dell’utente. Mostra gli attori (persone o sistemi esterni che interagiscono con il tuo software), le funzionalità principali (casi d’uso) e le relazioni tra di essi. È il diagramma da inserire per primo: orienta il lettore su cosa fa il sistema ancor prima di spiegare come è costruito.

Quando usarlo: sempre, anche per sistemi semplici. Un’applicazione web con area pubblica e area riservata avrà almeno due attori (Visitatore, Utente Autenticato) e una manciata di casi d’uso chiari.

Dove metterlo nella tesi: all’inizio del capitolo di analisi dei requisiti, subito dopo la descrizione testuale dei requisiti funzionali.

2. Diagramma delle classi (Class Diagram)

Il diagramma delle classi è il cuore della documentazione strutturale. Mostra le classi del sistema, i loro attributi, i metodi e le relazioni (ereditarietà, composizione, associazione, dipendenza). Per la commissione, è il diagramma che rivela la qualità del tuo design orientato agli oggetti.

Suggerimento pratico: non includere tutte le classi di un progetto grande in un unico diagramma: il risultato è illeggibile. Crea diagrammi parziali per sottosistemi (modulo autenticazione, modulo pagamenti, modulo reportistica) e un diagramma di alto livello che mostri solo le relazioni tra i componenti principali.

Dove metterlo: nel capitolo di progettazione, con una sezione dedicata per ogni sottosistema o layer architetturale.

3. Diagramma di sequenza (Sequence Diagram)

Il diagramma di sequenza modella l’interazione tra oggetti nel tempo, mostrando la sequenza dei messaggi scambiati per realizzare uno specifico scenario o caso d’uso. È il diagramma che dimostra che hai pensato al flusso delle operazioni in modo rigoroso.

Quanti includerne: scegli i 2-4 scenari più significativi del tuo sistema. Per un e-commerce potrebbe essere il processo di checkout; per un sistema di autenticazione, il flusso login-JWT-refresh. Non servono diagrammi di sequenza per ogni caso d’uso.

Dove metterlo: nel capitolo di progettazione, subito dopo il diagramma delle classi per i sottosistemi corrispondenti.

4. Diagramma delle componenti (Component Diagram)

Il diagramma delle componenti mostra l’architettura macroscopica del sistema: i moduli software, i database, i servizi esterni e le interfacce tra di essi. Per un progetto con architettura a microservizi, API REST o architettura client-server, questo diagramma è fondamentale per mostrare come le parti si collegano.

Dove metterlo: all’inizio del capitolo di architettura del sistema, come prima visione d’insieme prima di scendere nei dettagli delle classi.

5. Diagramma di attività (Activity Diagram)

Simile a un flowchart avanzato, il diagramma di attività modella i processi e i flussi di lavoro. È utile per documentare algoritmi complessi, processi con condizioni e rami paralleli, o workflow di business che il sistema implementa. La commissione lo trova particolarmente leggibile perché la notazione è intuitiva anche per chi non ha un background tecnico approfondito.

Quando usarlo: per documentare logiche di business complesse, processi multi-step o flussi che coinvolgono più attori in parallelo. Non è necessario per funzionalità semplici.

Struttura dei capitoli: dove va cosa

La struttura più consolidata per una tesi di informatica — adottata con variazioni minori al Politecnico di Milano, all’Università di Bologna e alla Sapienza — prevede i seguenti capitoli:

Capitolo 1 — Introduzione

Contesto del problema, motivazione del progetto, obiettivi specifici, struttura della tesi. Non includere qui alcun diagramma UML. Lunghezza indicativa: 3-6 pagine per tesi triennali, 5-10 per magistrali.

Capitolo 2 — Stato dell’arte

Revisione della letteratura e delle tecnologie esistenti: framework, librerie, soluzioni simili a quella che hai sviluppato. Include tabelle comparative tra alternative, non diagrammi UML.

Capitolo 3 — Analisi dei requisiti

Qui entrano i diagrammi dei casi d’uso. Descrivi prima i requisiti funzionali in forma testuale (tabella con ID, descrizione, priorità), poi illustrali con i casi d’uso UML. Includi anche i requisiti non funzionali (performance, sicurezza, scalabilità).

Capitolo 4 — Architettura e progettazione

Questo è il capitolo più tecnico e ricco di UML. Strutturalo così:

• 4.1 Architettura del sistema: diagramma delle componenti, scelte architetturali (MVC, microservizi, REST), stack tecnologico.
• 4.2 Modello dei dati: diagramma entità-relazione (ER) o schema del database, con commento delle scelte di normalizzazione.
• 4.3 Progettazione dei moduli: diagrammi delle classi per sottosistema, con spiegazione delle relazioni principali.
• 4.4 Flussi principali: diagrammi di sequenza per gli scenari chiave, diagrammi di attività per i processi complessi.

Capitolo 5 — Implementazione

Descrivi le scelte implementative più significative con frammenti di codice brevi (5-20 righe) e spiegati. Non incollare qui blocchi di codice lunghi: quelli vanno in appendice. Includi screenshot dell’interfaccia utente, log di test, metriche di performance misurate.

Capitolo 6 — Test e validazione

Test unitari, test di integrazione, test di sistema. Tabelle con casi di test, input, output attesi e risultati effettivi. Se hai usato strumenti di testing automatizzato (JUnit, pytest, Cypress), mostra il report di copertura.

Capitolo 7 — Conclusioni

Risultati raggiunti, limiti del progetto, possibili sviluppi futuri. Nessun nuovo diagramma.

Appendici

Le appendici contengono tutto il materiale tecnico dettagliato che ingombrerebbe il corpo principale: il codice sorgente completo (o le parti più significative), la documentazione delle API, le istruzioni di installazione, i log di test completi, le interviste o i questionari se il progetto include ricerca qualitativa.

Come documentare il codice sorgente

Il codice sorgente è il prodotto principale del tuo lavoro, ma nella tesi il suo ruolo è di supporto alla narrazione — non il contrario. Ecco come gestirlo in modo professionale.

Commenti nel codice (Javadoc, Docstring, JSDoc)

Il codice che allegate alla tesi — sia come appendice che come repository GitHub — deve essere commentato con lo standard del linguaggio che hai usato. Per Java usa Javadoc, per Python i docstring PEP 257, per JavaScript/TypeScript JSDoc. Questi commenti servono a due scopi: rendono il codice leggibile per la commissione tecnica, e dimostrano che hai lavorato con metodo professionale.

README e documentazione del repository

Se includi un link al repository GitHub nella tesi (e dovresti, per un progetto che continuerà a esistere dopo la laurea), assicurati che il README contenga: descrizione del progetto, prerequisiti, istruzioni di installazione, istruzioni per avviare il progetto, descrizione delle variabili d’ambiente, link alla documentazione API. Un commissario tecnico potrebbe clonare il repository durante la discussione.

Snippet di codice nel corpo della tesi

Quando inserisci frammenti di codice nel corpo della tesi, segui queste convenzioni:

• Usa un font monospazio (Courier New, Consolas, JetBrains Mono) con dimensione leggermente inferiore al testo principale.
• Aggiungi il numero di riga se il codice è più di 5 righe.
• Indica il linguaggio e il file di riferimento in un’intestazione sopra il blocco.
• Ogni snippet deve essere accompagnato da almeno 2-3 righe di spiegazione nel testo.

Documentazione delle API

Se hai sviluppato un’API REST, documenta gli endpoint con metodo HTTP, URL, parametri, corpo della richiesta, risposta attesa e codici di errore. Il formato OpenAPI (Swagger) è lo standard de facto: genera la documentazione automaticamente dal codice e inserisci il YAML in appendice o in un link dedicato.

Strumenti per creare diagrammi UML

Non serve software costoso per creare diagrammi UML di qualità professionale. Ecco le opzioni principali usate dagli studenti italiani nel 2026:

draw.io / diagrams.net (gratuito)

Lo strumento più diffuso tra gli studenti universitari. Interfaccia drag-and-drop, supporto nativo per tutti i diagrammi UML, esportazione in PNG, SVG e PDF. Si integra con Google Drive e Confluence. È sufficiente per tesi triennali e magistrali standard.

PlantUML (gratuito, open source)

PlantUML genera diagrammi UML da testo semplice, con una sintassi simile al markdown. Il vantaggio principale è che i diagrammi sono versionabili come codice in un repository Git: ogni modifica al diagramma è tracciabile. Ottimo se usi LaTeX per la tesi, perché si integra nativamente con la pipeline di compilazione. Se la tua tesi ha anche una componente di analisi dati, lo stesso principio di tracciabilità si estende all’intero documento: vedi il workflow riproducibile con R Markdown e Overleaf per gestire codice, output e testo in un’unica pipeline versionabile.

Esempio di diagramma di sequenza in PlantUML:

@startuml
actor Utente
Utente -> Frontend : login(email, password)
Frontend -> AuthService : authenticate(email, password)
AuthService -> Database : findUserByEmail(email)
Database --> AuthService : UserEntity
AuthService --> Frontend : JWT token
Frontend --> Utente : redirect dashboard
@enduml

Lucidchart (freemium)

Interfaccia professionale, ottima collaborazione in tempo reale — utile se lavori con un co-relatore o un tutor aziendale. Il piano gratuito limita a tre documenti e alla collaborazione con un altro utente; per la tesi è generalmente sufficiente.

Visual Paradigm Community Edition (gratuito)

La scelta degli studenti di ingegneria del software che vogliono uno strumento CASE completo. Supporta la generazione di codice stub dai diagrammi delle classi e la reverse engineering del codice in diagrammi UML. La curva di apprendimento è più ripida, ma il risultato è più preciso formalmente.

Mermaid.js (gratuito, integrato in GitHub)

Mermaid è una libreria JavaScript che genera diagrammi da testo markdown. GitHub e GitLab la renderizzano automaticamente nei file README.md e nei wiki. Per chi documenta il progetto direttamente nel repository, Mermaid è la soluzione più fluida.

Come presentare il progetto alla commissione

La discussione della tesi di informatica ha una dinamica diversa da quella delle tesi umanistiche: i commissari tecnici si aspettano che tu possa rispondere a domande sul codice, spiegare scelte architetturali e difendere le tue decisioni progettuali. Ecco come prepararti.

Le slide della presentazione

Le slide devono seguire la stessa struttura della tesi, condensata. Per una presentazione di 10-15 minuti, usa circa 12-18 slide. La struttura consigliata:

1. Titolo e contesto del problema (1 slide)
2. Obiettivi del progetto (1 slide)
3. Panoramica dello stack tecnologico (1 slide)
4. Architettura del sistema — diagramma delle componenti (1-2 slide)
5. Casi d’uso principali — screenshot dell’interfaccia (2-3 slide)
6. Progettazione — diagramma delle classi semplificato (1-2 slide)
7. Risultati e metriche (1-2 slide)
8. Limiti e sviluppi futuri (1 slide)
9. Ringraziamenti (1 slide)

Demo live: sì o no?

Al Politecnico di Milano e alla Sapienza, la demo live del software è sempre ben accolta se stabile. Al Politecnico di Torino, alcune commissioni preferiscono un video preregistrato per evitare problemi tecnici. Chiedi al tuo relatore quale approccio è usuale nel tuo dipartimento. Se fai una demo live, testa tutto sul laptop che userai in aula almeno il giorno prima, con il proiettore se possibile.

Domande tecniche frequenti della commissione

Preparati a rispondere a queste domande senza doverle cercare nella tesi:

• Perché hai scelto questo linguaggio/framework e non un’alternativa?
• Come gestisce il sistema il caso di errore X?
• Quali sono le limitazioni di scalabilità dell’architettura attuale?
• Come hai testato il sistema?
• Cosa cambieresti nel design, con il senno di poi?
• Come hai gestito la sicurezza dei dati degli utenti?

Esempi da atenei italiani: Politecnico, Bologna, Sapienza

Politecnico di Milano — Ingegneria Informatica

Il Politecnico pubblica linee guida esplicite per la tesi sul portale PoliTesi. Per le tesi di ingegneria informatica magistrale, la struttura attesa prevede un capitolo di background separato dallo stato dell’arte, e una sezione di analisi comparativa tra le soluzioni tecniche valutate prima di scegliere l’architettura finale. I diagrammi UML devono usare la notazione standard senza varianti informali. La commissione include tipicamente docenti di reti, sistemi e basi di dati — quindi le domande tecniche sono calibrate su questi ambiti.

Università di Bologna — Informatica

Bologna ha una tradizione forte di tesi con componente sperimentale. Il capitolo di valutazione deve includere metriche quantitative (tempo di risposta, throughput, utilizzo della memoria) con test ripetibili, non solo screenshot. I diagrammi di sequenza sono particolarmente apprezzati per documentare i protocolli di comunicazione in tesi su sistemi distribuiti.

Sapienza Università di Roma — Ingegneria Informatica e Automatica

Alla Sapienza, le tesi di ingegneria informatica includono spesso una sezione di analisi della complessità algoritmica (notazione O) per i componenti critici. Il dipartimento di informatica ha linee guida più flessibili sulla struttura rispetto agli altri atenei, ma richiede un abstract in italiano e uno in inglese, e una sezione “Related Work” in stile paper scientifico.

Errori da evitare

1. Diagrammi creati dopo il codice senza riflessione

Il difetto più facile da riconoscere per la commissione: i diagrammi UML mostrano esattamente la struttura del codice, inclusi nomi di variabili non significativi, dipendenze circolari e violazioni di principi come Single Responsibility. I diagrammi devono mostrare il design ideale — se il codice si discosta per necessità pratiche, spiegalo nel testo.

2. Diagrammi delle classi con troppe informazioni

Un diagramma con 40 classi, tutti gli attributi e tutti i metodi listati è inutile: nessuno riesce a leggerlo. Filtra: includi solo le classi e le relazioni rilevanti per la discussione del capitolo corrente. Gli attributi privati di implementation detail possono essere omessi.

3. Codice sorgente nel corpo della tesi senza spiegazione

Incollare blocchi di codice di 50 righe senza un singolo commento esplicativo non dimostra competenza — dimostra che non sai cosa è importante spiegare. Ogni snippet nel corpo della tesi deve essere preceduto da una spiegazione di cosa fa e perché è rilevante.

4. Ignorare i requisiti non funzionali

Una tesi che documenta solo le funzionalità del sistema senza discutere performance, sicurezza e manutenibilità è incompleta. Anche per un progetto accademico, inserisci almeno un paragrafo sui requisiti non funzionali e su come le scelte architetturali li soddisfano o li tradeoff.

5. Non allineare i diagrammi con il codice consegnato

Se la tesi mostra una classe UserService con un metodo authenticate() e nel codice consegnato quella classe si chiama AuthManager con il metodo login(), la commissione tecnica lo noterà. Verifica che nomi e strutture nei diagrammi corrispondano esattamente al codice finale.

FAQ