Che cos’e un caso d’uso nel laboratorio

Un caso d’uso e una operazione significativa del sistema.

Nel Registro del laboratorio, esempi di casi d’uso sono:

• registrare uno strumento;
• cercare strumenti;
• registrare un prestito;
• chiudere un prestito;
• aprire una segnalazione di guasto.

Un caso d’uso non e un bottone.

Un caso d’uso non e una regola singola del dominio.

Un caso d’uso e il pezzo di applicazione che coordina i passaggi necessari per ottenere un risultato.

Obiettivo

Alla fine devi saper spiegare:

• che cosa fa un caso d’uso;
• che cosa non deve fare;
• perche sta nel livello Application;
• perche deve essere indipendente dalla UI;
• quali casi d’uso servono al Registro del laboratorio.

Dal bisogno alla operazione

Prendiamo una frase del modulo sui requisiti:

Il docente puo registrare un prestito per uno strumento disponibile.

Questa frase puo diventare il caso d’uso:

RegistraPrestito

Il caso d’uso dovra coordinare vari passaggi:

1. ricevere i dati necessari;
2. trovare lo strumento;
3. verificare che lo strumento possa essere prestato;
4. creare il prestito;
5. aggiornare lo stato dello strumento;
6. salvare prestito e strumento;
7. restituire un risultato comprensibile.

Nessuno di questi passaggi richiede di sapere quale bottone e stato premuto.

Dove sta il caso d’uso

Nella nostra architettura didattica:

Presentation / UI
Application
Domain
Infrastructure

il caso d’uso sta in:

Application

Perche?

Perche coordina l’operazione.

Non contiene il markup della pagina. Non decide il colore dei messaggi. Non salva direttamente in localStorage se possiamo evitarlo. Non inventa regole che appartengono al dominio.

Chiama il dominio e usa l’infrastruttura attraverso funzioni o oggetti dedicati.

Il caso d’uso non e la UI

Nel programma fragile potremmo avere:

buttonRegistraPrestito.addEventListener("click", () => {
  const strumentoId = inputStrumento.value;
  const assegnatario = inputStudente.value;

  const strumento = strumenti.find((item) => item.id === strumentoId);

  if (strumento.stato !== "disponibile") {
    messaggio.textContent = "Strumento non disponibile";
    return;
  }

  prestiti.push({
    id: crypto.randomUUID(),
    strumentoId,
    assegnatario,
    stato: "aperto",
  });

  strumento.stato = "in_prestito";
  localStorage.setItem("strumenti", JSON.stringify(strumenti));
  localStorage.setItem("prestiti", JSON.stringify(prestiti));
  messaggio.textContent = "Prestito registrato";
});

Funziona, ma mescola tutto:

• legge input dalla UI;
• cerca dati;
• applica regole;
• crea dati;
• modifica stato;
• salva;
• mostra messaggi.

Il caso d’uso serve a togliere questa operazione dal click handler.

Una forma piu chiara

La UI puo fare:

const risultato = registraPrestito({
  strumentoId,
  assegnatario,
  data: oggi,
});

Il caso d’uso puo fare:

export function registraPrestito(comando) {
  // coordinamento dell'operazione
}

Il nome comando indica i dati necessari per chiedere una operazione.

Non e obbligatorio usare questo nome, ma e utile:

const comando = {
  strumentoId: "s-001",
  assegnatario: "Luca 3A",
  data: "2026-05-09",
};

Input e output

Un caso d’uso riceve input semplici.

Esempio:

{
  strumentoId: "s-001",
  assegnatario: "Luca 3A",
  data: "2026-05-09"
}

Restituisce un risultato.

Esempio:

{
  prestito: {
    id: "p-001",
    strumentoId: "s-001",
    assegnatario: "Luca 3A",
    stato: "aperto"
  },
  strumento: {
    id: "s-001",
    stato: "in_prestito"
  }
}

Oppure puo restituire solo cio che serve alla UI.

L’importante e che non restituisca elementi HTML.

Che cosa non deve conoscere

Un caso d’uso non dovrebbe conoscere:

• document.querySelector;
• addEventListener;
• innerHTML;
• classi CSS;
• testo preciso dei bottoni;
• struttura della pagina;
• dettagli di localStorage, se stiamo separando l’infrastruttura.

Un caso d’uso puo conoscere:

• input dell’operazione;
• funzioni del dominio;
• archivi o funzioni per leggere e salvare dati;
• errori applicativi o di dominio.

Lista dei casi d’uso del corso

Per il Registro del laboratorio useremo questi casi d’uso:

RegistraStrumento
CercaStrumenti
RegistraPrestito
ChiudiPrestito
ApriSegnalazioneGuasto

Sono abbastanza pochi da restare gestibili, ma abbastanza ricchi da mostrare architettura vera.

Esercizio

Per ogni frase indica se e:

UI
Dominio
Caso d'uso
Infrastructure

Frasi:

1. Il docente clicca "Registra prestito".
2. Uno strumento guasto non puo essere prestato.
3. RegistraPrestito trova lo strumento, verifica le regole e salva il prestito.
4. Gli strumenti vengono letti da localStorage.
5. La lista mostra "Nessuno strumento trovato".
6. ChiudiPrestito chiude un prestito aperto e aggiorna lo stato finale dello strumento.

Possibile soluzione:

1. UI
2. Dominio
3. Caso d'uso
4. Infrastructure
5. UI
6. Caso d'uso

Cosa produrre

Alla fine della lezione devi avere:

• una lista dei casi d’uso del progetto;
• per ogni caso d’uso, una frase che spiega lo scopo;
• una nota su quali dati riceve;
• una nota su quale risultato produce;
• almeno tre cose che il caso d’uso non deve conoscere.

Spiegazione guidata per studiare

Questa lezione va studiata su due piani. Il primo è il comportamento visibile del Registro del laboratorio: che cosa vede o fa l’utente quando registra uno strumento, cerca un dispositivo, apre un prestito o segnala un guasto. Il secondo è il confine architetturale: dove deve stare il codice che rende possibile quel comportamento.

Per che cos’e un caso d’uso nel laboratorio, il punto centrale è questo: Un caso d’uso coordina un’operazione completa: riceve un comando, legge ciò che serve, applica regole, salva il risultato e restituisce un esito.

Il rischio tipico è far diventare il caso d’uso una seconda UI o un secondo database. Deve coordinare, non mostrare HTML e non conoscere dettagli tecnici di salvataggio. Per evitarlo, non partire dal file che hai già aperto nell’editor. Parti dalla domanda: “quale responsabilità sto modificando?”. Se la risposta riguarda una regola del laboratorio, guarda il dominio. Se riguarda una sequenza di operazioni, guarda i casi d’uso. Se riguarda salvataggio, file, localStorage, API o database, guarda l’infrastruttura. Se riguarda input, pulsanti, form e messaggi, guarda la Presentation.

Il tempo è breve: non provare a fare tutto, punta a capire il concetto e produrre un risultato piccolo. Alla fine della lezione lo studente non deve ricordare una definizione a memoria: deve saper indicare un punto del progetto, spiegare perché quel codice sta lì e mostrare una verifica del comportamento.

Passo per passo nel progetto

1. Rileggi il titolo della lezione e riscrivilo come domanda pratica. Per esempio: “dove deve stare questa regola?”, “chi deve salvare questo dato?”, “come verifico questo errore?”.
2. Apri solo i file necessari. Se devi toccare più di tre file, fermati e scrivi prima una mini-mappa.
3. Definisci input e output del caso d’uso.
4. Leggi i dati attraverso un archivio o una dipendenza esplicita.
5. Chiama le regole del dominio.
6. Salva il risultato senza sapere come funziona la persistenza concreta.
7. Aggiorna una nota breve nel README o negli appunti se hai cambiato un confine del progetto.

Esempio da leggere lentamente

Questo esempio serve a ragionare, non a incollare codice senza capire:

function registraPrestito(comando, archivioStrumenti, archivioPrestiti) {
  const strumento = archivioStrumenti.trovaPerId(comando.strumentoId);
  verificaStrumentoPrestabile(strumento);
  const prestito = apriPrestito(strumento.id, comando.nomePersona);
  archivioPrestiti.salva(prestito);
  archivioStrumenti.salva({ ...strumento, stato: "in_prestito" });
  return prestito;
}

Leggilo chiedendoti che cosa cambierebbe se domani sostituissimo la pagina web con una CLI, oppure localStorage con un’API. Se l’esempio continua ad avere senso senza riscrivere tutto, il confine è probabilmente buono. Se invece un dettaglio tecnico si propaga in molti file, il progetto sta tornando fragile.

Prova di comprensione

Prima di chiudere la lezione, rispondi per iscritto a queste domande:

• Qual è la responsabilità principale trattata in questa lezione?
• In quale livello del progetto dovrebbe stare?
• Quale errore faresti se cercassi la soluzione più veloce?
• Quale piccolo test, controllo manuale o esempio dimostra che hai capito?
• Che cosa deve restare facile da cambiare dopo questa lezione?

Una risposta accettabile non deve essere lunga. Deve però usare parole concrete del Registro: strumento, prestito, stato, archivio, caso d’uso, messaggio, test.

Controllo finale

La lezione e completata quando puoi rispondere si:

• so distinguere caso d’uso e bottone;
• so distinguere caso d’uso e regola di dominio;
• so perche il caso d’uso sta in Application;
• posso chiamare un caso d’uso senza aprire il browser;
• ho nominato i casi d’uso principali del Registro.

Nella prossima lezione separiamo meglio regola di dominio e coordinamento applicativo.