Ciclo di Vita del Software: Metodologie, UML e Pattern
Dalla crisi del software del '68 ai team Scrum moderni: come si organizza un progetto reale, come si modella con UML prima di scrivere codice e come si misura la qualità con ISO 25010, SOLID e design pattern. Caso di studio: la biblioteca scolastica.
Ogni volta che apri un'app sul telefono, prenoti un biglietto online o usi il registro elettronico, stai usando il risultato finale di un processo: qualcuno ha analizzato un problema, progettato una soluzione, scritto codice, verificato che funzionasse e continua a mantenerlo nel tempo. Quel processo ha un nome — ciclo di vita del software — e un insieme di strumenti e regole che lo rendono gestibile anche quando il progetto coinvolge decine di persone e centinaia di migliaia di righe di codice.
1. Ingegneria del software e metodologie di sviluppo
L'ingegneria del software è la disciplina che applica principi tecnici, metodi sistematici e strumenti di gestione allo sviluppo, manutenzione e dismissione del software, per produrre sistemi affidabili ed efficienti entro vincoli di tempo e costo. Il termine nasce nel 1968 alla NATO Conference, come risposta alla "software crisis".
1.1 Il ciclo di vita del software (SDLC)
Il Software Development Life Cycle è l'insieme delle fasi che un prodotto attraversa. Ciò che distingue le metodologie non è la presenza delle fasi — servono quasi sempre tutte — ma come sono organizzate nel tempo.
| Fase | Obiettivo | Output tipico |
|---|---|---|
| Analisi requisiti | Capire cosa deve fare il sistema e per chi | Documento requisiti funzionali / non funzionali |
| Progettazione | Definire architettura, moduli, dati, interfacce | Diagrammi UML, schema dati, design doc |
| Implementazione | Scrivere il codice sorgente | Codice versionato su Git |
| Test / verifica | Trovare difetti prima del rilascio | Piano test, report bug |
| Rilascio | Rendere disponibile agli utenti | Versione in produzione |
| Manutenzione | Correggere, adattare, migliorare | Patch, nuove versioni |
1.2 Il modello a cascata (Waterfall - Royce 1970)
Sequenza rigida: si passa alla fase successiva solo quando la precedente è completata e "congelata". È intuitivo ma fragile: se un requisito era interpretato male, l'errore emerge in fase di test, quando correggerlo costa 10x.
In classe vi dico sempre: Io ho pensato di fare così quando spiego Waterfall — lo disegno come una cascata vera. Se all'interrogazione vi chiedono "quando ha senso?", dite "quando i requisiti sono congelati, esempio software per dispositivi medicali certificati". Io lo farei così per ricordarlo: Waterfall = ghiaccio, Agile = acqua che si adatta. In Tecnologia questa metafora vale oro perché vi fa distinguere subito rigidità vs adattività.
Confondere "metodologia" con "linguaggio". Waterfall e Scrum dicono quando e come organizzarsi, non in che linguaggio programmate. Potete fare Scrum in Python, Java o anche solo su carta.
1.3 Modelli iterativi, incrementali e a spirale (Boehm 1986)
Ripetizione
Stesso ciclo analisi→test ripetuto, ogni volta raffini la soluzione precedente.
Consegne
Dividi il sistema in incrementi funzionali, ciascuno rilasciato separatamente.
Rischio
Ogni giro: obiettivi, analisi rischi, prototipo, pianificazione giro successivo.
1.4 Le metodologie agili e Scrum
Manifesto Agile (2001): privilegia persone e interazioni, software funzionante, collaborazione col cliente, risposta al cambiamento. Scrum organizza tutto in sprint di 1-4 settimane con un incremento potenzialmente rilasciabile.
| Elemento Scrum | Cos'è in pratica |
|---|---|
| Product Owner | Rappresenta il cliente, decide cosa ha priorità |
| Scrum Master | Facilita, rimuove ostacoli, protegge il team |
| Development Team | Progetta, codifica, testa |
| Product Backlog | Lista prioritaria di tutte le funzionalità |
| Sprint Backlog | Sottoinsieme scelto per lo sprint |
| Daily Scrum | 15 min al giorno per sincronizzarsi |
| Increment | Prodotto funzionante a fine sprint |
Sprint 1: solo ricerca libri. Sprint 2: aggiungiamo prestito. Sprint 3: notifiche scadenza. In Tecnologia questo approccio vi insegna a non voler fare tutto subito: prima funzionante, poi completo. È la stessa logica con cui a scuola facciamo i progetti di laboratorio.
1.5 Cascata o agile? Confronto
| Criterio | Waterfall | Agile / Scrum |
|---|---|---|
| Requisiti | Definiti e congelati all'inizio | Evolvono nel tempo |
| Consegna | Una sola, a fine progetto | Incrementale ogni sprint |
| Cambiamento | Costoso, rilavorazione | Previsto e incentivato |
| Documentazione | Estesa e formale | Just enough |
| Adatto a | Requisiti stabili, normati | Prodotti digitali, incertezza |
2. Il linguaggio di modellizzazione UML
UML (Unified Modeling Language) è il linguaggio grafico standard OMG / ISO 19505 per visualizzare, specificare e documentare sistemi OO. Nasce nel 1997 dall'unione di Booch, Jacobson, Rumbaugh — i "tre amigos". Non è un metodo, è un linguaggio comune per evitare ambiguità.
UML 2.5 ha 14 diagrammi divisi in strutturali (classi, oggetti, componenti, deployment) e comportamentali (casi d'uso, sequenza, attività, stati). A scuola vi bastano 3: casi d'uso, classi, sequenza.
2.1 Diagramma dei casi d'uso (Use Case)
Rappresenta le funzionalità dal punto di vista di chi usa il sistema. Attore = persona o sistema esterno. Caso d'uso = ovale con valore per l'attore. Sistema = rettangolo che racchiude tutto.
Chi usa?
Studente, Bibliotecario, ma anche sistema esterno come email gateway.
Cosa fa?
Cerca libro, Prenota libro, Gestisce catalogo — sempre verbo + oggetto.
Come si legano?
Include = sempre richiamato, Extend = solo in condizioni particolari.
Io ho pensato di fare così per farvi ricordare i casi d'uso: vi faccio disegnare prima gli omini stilizzati (attori) e poi chiedo "cosa vuole fare questo omino?". Io lo farei così anche alla verifica: se finite con 15 ovali, avete sbagliato — per la biblioteca bastano 4-5 casi d'uso principali. In Tecnologia l'eccesso è errore quanto la mancanza.
Studente → Cerca libro, Prenota libro, Restituisce libro. Bibliotecario → Gestisce catalogo, Cerca libro (anche lui). Prenota libro «include» Invia promemoria (scadenza). Se il libro è in ritardo, parte «extend» Applica sanzione.
2.2 Diagramma delle classi
È il diagramma strutturale più usato: ogni classe = rettangolo con nome, attributi, operazioni. Fondamentale per Tecnologia perché collega direttamente OOP e progettazione.
| Relazione | Simbolo | Significato |
|---|---|---|
| Associazione | Linea semplice | Collaborano, si conoscono |
| Aggregazione | Rombo vuoto | "Ha un" debole — parti esistono senza tutto |
| Composizione | Rombo pieno | "Ha un" forte — parti non esistono senza tutto |
| Generalizzazione | Triangolo vuoto | Ereditarietà "è un" |
| Molteplicità | 1..*, 0..1 | Quante istanze coinvolte |
Mettere la dataScadenza dentro Libro o dentro Studente. No: la scadenza appartiene alla relazione tra i due in un momento preciso. Serve una classe associativa Prestito. Se all'interrogazione vi chiedo "dove metto la data?", la risposta è sempre: nella classe che rappresenta l'associazione.
Utente (abstract) id, nome —→ Studente (classe) e Docente (materia) ereditano. Utente 1 — 0..* Prestito (dataInizio, dataScadenza, estendi()). Prestito 1 — 1 Libro (ISBN, titolo, autore). Questa estrutura rende il codice leggibile e manutenibile.
2.3 Diagramma di sequenza
Mostra come gli oggetti si scambiano messaggi nel tempo. Lifeline verticale, messaggi orizzontali dall'alto al basso.
2.4 Altri diagrammi quando servono
Attività = flusso con decisioni e parallelismi (utile per sanzioni ritardo). Stati = come Prestito passa da "attivo" a "in ritardo" a "restituito". Componenti / Deployment = moduli e loro distribuzione su server. In un progetto scolastico, i tre visti bastano.
3. Qualità del software e pattern
Qualità ≠ "mi piace". È misurabile tramite ISO/IEC 25010 — 8 caratteristiche scomponibili in sotto-caratteristiche con metriche interne (sul codice) ed esterne (in esecuzione).
3.1 ISO/IEC 25010 — le 8 caratteristiche
Idoneità funzionale
Fa ciò che deve fare? Completezza, correttezza, appropriatezza.
Efficienza prestazionale
Tempo risposta, uso risorse, capacità.
Compatibilità
Coesiste, interoperabile con altri sistemi.
Usabilità
Imparabilità, operabilità, estetica UI — cruciale in Tecnologia didattica.
Affidabilità
Maturità, disponibilità, tolleranza guasti, recuperabilità.
Sicurezza
Confidenzialità, integrità, non ripudio — dati studenti.
Manutenibilità
Modularità, riusabilità, modificabilità, testabilità — dove SOLID aiuta.
Portabilità
Adattabilità, installabilità, sostituibilità.
3.2 Principi SOLID (Robert C. Martin)
| Principio | In breve | Perché conta in Tecnologia |
|---|---|---|
| S - Single Responsibility | Una classe = un motivo per cambiare | Prestito non deve anche inviare email |
| O - Open/Closed | Estendibile senza modificare esistente | Nuovo canale notifica senza toccare Prestito |
| L - Liskov | Sottoclasse sostituisce superclasse | Studente ovunque c'è Utente |
| I - Interface Segregation | Molte interfacce specifiche meglio di una gigante | Non costringere Docente a metodi da Studente |
| D - Dependency Inversion | Dipendi da astrazioni, non concrezioni | Prestito dipende da interfaccia Notifica, non da Email |
3.3 Design pattern GoF (Gamma, Helm, Johnson, Vlissides 1994)
23 pattern in 3 categorie: soluzioni consolidate a problemi ricorrenti. Non regole, ma vocabolario condiviso.
| Categoria | Problema | Pattern noti |
|---|---|---|
| Creazionali | Come creare oggetti flessibilmente | Singleton, Factory Method, Abstract Factory, Builder |
| Strutturali | Come comporre classi in strutture grandi | Adapter, Decorator, Facade, Composite |
| Comportamentali | Comunicazione e responsabilità tra oggetti | Observer, Strategy, Template Method, Command |
Io ho pensato di fare così per i miei corsi di Tecnologia: non vi chiedo di memorizzare 23 pattern, ma di riconoscerne 2 a fondo. Io lo farei così: per ogni pattern chiedetevi "che problema risolve?" non "come è fatto il diagramma?". Observer = "devo avvisare molti quando uno cambia". Singleton = "deve esistere una sola connessione DB". Se li raccontate così all'interrogazione, dimostrate che pensate da progettisti, non da pappagalli.
Singleton (creazionale): una sola istanza globale — utile per connessione DB catalogo.
Observer (comportamentale): soggetto 1-a-molti, notifica automatica — perfetto per promemoria scadenza.
Un pattern non è obbligatorio. Usarlo dove non serve rende il codice più complesso del necessario, più difficile da leggere e mantenere. In Tecnologia vi insegno a valutare: prima soluzione semplice, poi pattern se risolve davvero meglio. Un buon progettista riconosce il problema, non applica pattern a caso.
4. Studio di un caso: sistema prenotazione biblioteca scolastica
Mettiamo insieme tutto: requisiti → metodologia → modellazione UML → pattern e qualità. È lo stesso schema di qualunque progetto reale, cambia la scala, non la logica.
4.1 Fase 1 — Raccolta requisiti
| Tipo | Requisito |
|---|---|
| Funzionale | Studente cerca libro per titolo, autore o ISBN |
| Funzionale | Studente prenota libro disponibile |
| Funzionale | Sistema invia promemoria 1 giorno prima scadenza |
| Funzionale | Bibliotecario CRUD su catalogo |
| Non funzionale | Ricerca < 1s (efficienza) |
| Non funzionale | Usabile senza formazione (usabilità) |
| Non funzionale | Dati personali protetti (sicurezza) |
Perché in verifica vi chiedo di classificare. "Cerca per titolo" = funzionale (cosa fa). "Tempo <1s" = non funzionale (come lo fa). In Tecnologia questa distinzione vi allena a pensare come Product Owner: prima cosa deve fare, poi quanto bene.
4.2 Fase 2 — Scelta metodologia
Per biblioteca scolastica, requisiti semplici ma soggetti a piccoli aggiustamenti quando utenti provano il sistema → agile leggero a sprint di 2 settimane, non Waterfall rigido che congela tutto prima di mostrare nulla.
| Sprint | Obiettivo | Backlog |
|---|---|---|
| Sprint 1 | Catalogo e ricerca base | Modello Libro, ricerca titolo/autore/ISBN |
| Sprint 2 | Prenotazione e gestione prestiti | Classe Prestito, associazione Studente-Libro |
| Sprint 3 | Notifiche e ruolo bibliotecario | Observer per promemoria, CRUD catalogo |
4.3 Fase 3 — Modellazione UML
I diagrammi della sezione 2 sono esattamente quelli prodotti qui prima di scrivere codice: casi d'uso (Studente/Bibliotecario), classi (Utente/Studente/Docente/Prestito/Libro), sequenza (scenario prenotazione). Condivisi con Product Owner per validare interpretazione.
Io ho pensato di fare così nei progetti di lab: prima casi d'uso su foglio, poi classi, poi sequenza. Io lo farei così perché ogni diagramma risponde a una domanda diversa: cosa vuole l'utente? con quali oggetti lo realizzo? chi parla con chi nel tempo? Se li fate in quest'ordine in Tecnologia, evitate di disegnare classi che poi non usate mai.
4.4 Fase 4 — Pattern e qualità
Sprint 3: "invia promemoria" = problema canonico di Observer. Prestito non deve sapere come notifica (email, push, SMS), notifica solo i suoi osservatori quando scadenza vicina. Estendibile → rispetta Open/Closed.
ISO 25010: per biblioteca interna prioritizziamo usabilità (interfaccia semplice), affidabilità (non perdere prenotazioni), sicurezza (dati scolastici). Portabilità e compatibilità meno critiche.
Avete visto come tutto torna: metodologia agile vi permette di rimandare la scelta del canale di notifica a Sprint 3, UML vi fa capire chi è il soggetto e chi l'osservatore, SOLID vi dice che Prestito deve dipendere da astrazione Notifica, Observer vi dà la soluzione pronta. Non sono capitoli separati — è un unico flusso di progettazione.
5. Riepilogo e concetti chiave
Ragazzi, se dovessi sintetizzare in due frasi per Tecnologia: Io ho pensato di fare così questo percorso perché voglio che usciti da qui sappiate distinguere "cosa serve pianificare" da "cosa serve disegnare" da "cosa serve programmare bene". Io lo farei così al vostro posto: prendete il diagramma delle classi della biblioteca e provate a codificarlo in un linguaggio che conoscete, aggiungendo un secondo osservatore SMS senza toccare Prestito — se ci riuscite, avete capito SOLID e Observer in un colpo solo.
6. Verifica e autovalutazione
🔬 Attività pratica
Sulla base del caso biblioteca:
- Elenca requisiti funzionali e non funzionali aggiuntivi che mancano (es. limite prestiti simultanei) e giustifica perché sarebbero non funzionali o funzionali.
- Disegna il diagramma delle classi aggiungendo una classe Sanzione collegata a Prestito con composizione: quando Prestito viene eliminato, cosa succede a Sanzione?
- Scrivi lo pseudocodice del diagramma di sequenza per il caso "Restituzione libro con ritardo" includendo Observer per notifica al bibliotecario.
- Quale caratteristica ISO 25010 diventa critica se la biblioteca passa da sistema interno a servizio online per tutte le scuole della provincia? Argomenta.
- 1) Limite 3 prestiti simultanei = funzionale (regola di business). Disponibilità 99.5% = non funzionale (affidabilità).
- 2) Composizione Prestito ◆— Sanzione significa ciclo vita legato: se cancello Prestito restituito con sanzione pagata, ha senso cancellare anche Sanzione, ma se devo tenere storico, meglio aggregazione. Scelta dipende da requisito!
- 3) Restituzione attiva controllo data, se ritardo crea Sanzione e notifica bibliotecario via Observer.
- 4) Se diventa servizio provinciale: sicurezza, scalabilità prestazionale, compatibilità (browser diversi), portabilità (cloud).