Utenti del registro: docente, tecnico, studente, segreteria

Prima di progettare classi, funzioni e cartelle, dobbiamo capire chi userà il Registro del laboratorio.

Un errore molto comune è partire subito dal codice:

Facciamo una lista di strumenti.
Poi facciamo un bottone.
Poi salviamo in localStorage.

Questo funziona per partire, ma non basta per progettare. Se non sappiamo chi usa il sistema e perché, rischiamo di creare funzioni generiche, nomi confusi e regole messe nel posto sbagliato.

In questa lezione il codice resta quasi fermo. Lavoriamo sul problema.

Obiettivo

Alla fine devi avere una scheda utenti del Registro del laboratorio.

La scheda deve rispondere a domande semplici:

• chi usa il registro;
• quale problema deve risolvere;
• quali azioni compie spesso;
• quali informazioni deve vedere;
• quali errori non deve commettere;
• quali permessi o limiti ha.

Questa scheda non è burocrazia. Serve a scrivere codice più chiaro.

Se capisci che il tecnico chiude una segnalazione di guasto, è più facile capire perché una funzione chiamata chiudiSegnalazioneGuasto non deve stare dentro un click handler della pagina.

Ruolo, persona e dato non sono la stessa cosa

Prima di elencare gli utenti, separiamo tre idee:

Ruolo:
  il punto di vista con cui una persona usa il sistema

Persona:
  una persona reale della scuola

Dato:
  un'informazione registrata dal sistema

Uno studente, per esempio, può essere un dato dentro un prestito anche se non accede direttamente all’applicazione. Questo evita un errore frequente: trasformare ogni persona nominata dal sistema in un account utente.

Nel nostro laboratorio:

• il docente usa la UI per registrare prestiti;
• il tecnico usa la UI per gestire guasti e manutenzione;
• lo studente può comparire nei dati del prestito;
• la segreteria o il referente può consultare riepiloghi;
• il sistema salva strumenti, prestiti e segnalazioni.

Questa distinzione tornerà utile quando parleremo di sicurezza: non tutti quelli che compaiono nei dati devono poter modificare il sistema.

I quattro utenti principali

Per il nostro progetto guida usiamo quattro ruoli.

Non devono diventare subito utenti con login, password e autorizzazioni complesse. In questa fase sono ruoli didattici: servono a capire il sistema.

Docente

Il docente usa il registro per organizzare la lezione.

Vuole sapere se uno strumento è disponibile, se può prestarlo a uno studente, se è già in prestito o se è guasto.

Azioni tipiche:

• cerca uno strumento per nome o categoria;
• registra un prestito;
• chiude un prestito quando lo strumento torna;
• segnala un guasto;
• controlla quali strumenti sono disponibili per una attività.

Informazioni importanti:

• nome dello strumento;
• categoria;
• stato;
• eventuale studente che lo ha in prestito;
• data di inizio del prestito;
• eventuali note sul guasto.

Rischi da evitare:

• prestare due volte lo stesso strumento;
• prestare uno strumento guasto;
• non trovare rapidamente uno strumento durante la lezione;
• vedere messaggi tecnici incomprensibili.

Frasi che possono diventare requisiti:

Il docente deve poter cercare rapidamente uno strumento per nome o categoria.
Il docente deve poter registrare un prestito solo se lo strumento è disponibile.
Il docente deve vedere un messaggio chiaro se il prestito non può essere registrato.

Tecnico di laboratorio

Il tecnico usa il registro per mantenere gli strumenti.

Il suo problema non è solo “prestare”. Il suo problema è capire cosa è rotto, cosa è in manutenzione e cosa può tornare disponibile.

Azioni tipiche:

• vede gli strumenti guasti;
• apre o aggiorna una segnalazione;
• sposta uno strumento in manutenzione;
• segna uno strumento come di nuovo disponibile;
• controlla lo storico essenziale dei problemi.

Informazioni importanti:

• stato dello strumento;
• descrizione del guasto;
• data della segnalazione;
• eventuale priorita;
• note di manutenzione.

Rischi da evitare:

• perdere una segnalazione;
• rimettere disponibile uno strumento ancora guasto;
• confondere “guasto” con “in manutenzione”;
• modificare dati senza lasciare traccia minima.

Frasi che possono diventare requisiti:

Il tecnico deve poter vedere tutti gli strumenti guasti.
Il tecnico deve poter segnare uno strumento come in manutenzione.
Il tecnico deve poter riportare disponibile uno strumento solo dopo aver chiuso il problema.

Studente

Lo studente non è per forza un utente che accede al sistema.

Nel nostro laboratorio può essere una persona collegata a un prestito. Questo è già un dettaglio importante: una persona può apparire nel dominio anche se non usa direttamente la UI.

Azioni possibili:

• chiede un prestito;
• restituisce uno strumento;
• segnala che qualcosa non funziona;
• chiede se uno strumento e disponibile.

Informazioni importanti:

• nome e cognome;
• classe o gruppo;
• strumento ricevuto;
• data del prestito;
• stato del prestito.

Rischi da evitare:

• associare un prestito a uno studente non identificabile;
• chiudere un prestito sbagliato;
• registrare dati personali non necessari.

Frasi che possono diventare requisiti:

Ogni prestito deve indicare a quale studente o gruppo è associato.
Non devono essere registrati più dati personali del necessario.
Uno studente non deve poter modificare direttamente lo stato di uno strumento.

Segreteria o referente

La segreteria, o un referente di laboratorio, non lavora sempre sul dettaglio operativo.

Potrebbe avere bisogno di una vista riassuntiva:

• quanti strumenti ci sono;
• quanti sono disponibili;
• quanti sono guasti;
• quanti sono in prestito;
• quali categorie sono più usate;
• quali problemi ricorrono.

Nel corso base questa parte può restare semplice. Non serve costruire un cruscotto avanzato. Serve però capire che non tutti gli utenti guardano il sistema con lo stesso scopo.

Frasi che possono diventare requisiti:

Il referente deve poter vedere un riepilogo degli stati degli strumenti.
Il referente deve poter capire quanti strumenti non sono utilizzabili.
Il riepilogo non deve permettere modifiche accidentali ai prestiti.

Non tutti fanno tutto

Una domanda utile è:

Questo utente deve poter fare questa azione?

Esempi:

• il docente registra un prestito;
• il tecnico cambia lo stato da guasto a in manutenzione;
• lo studente non modifica direttamente lo stato dello strumento;
• la segreteria consulta riepiloghi, ma non gestisce ogni prestito.

Per ora non trasformiamo queste differenze in un sistema di permessi completo.

Le annotiamo. Nel modulo sulla sicurezza potranno diventare vincoli più espliciti.

Puoi usare una matrice semplice:

| Azione | Docente | Tecnico | Studente | Referente |
| --- | --- | --- | --- | --- |
| Cercare strumenti | sì | sì | forse, tramite richiesta | sì |
| Registrare prestito | sì | forse | no | no |
| Chiudere prestito | sì | forse | no | no |
| Aprire segnalazione guasto | sì | sì | forse, tramite docente | no |
| Mettere in manutenzione | no | sì | no | no |
| Vedere riepilogo | sì | sì | no | sì |

Questa tabella non è ancora autorizzazione tecnica. È una mappa didattica: ci dice quali azioni appartengono a quali ruoli.

Scheda pratica

Crea un file nel progetto o nel README chiamato:

docs/utenti.md

Se non hai ancora una cartella docs, puoi aggiungere una sezione nel README.

Compila questa struttura:

# Utenti del Registro del laboratorio

## Docente

Problema principale:

Azioni frequenti:
- ...

Informazioni necessarie:
- ...

Errori da evitare:
- ...

## Tecnico di laboratorio

Problema principale:

Azioni frequenti:
- ...

Informazioni necessarie:
- ...

Errori da evitare:
- ...

## Studente

Problema principale:

Azioni frequenti:
- ...

Informazioni necessarie:
- ...

Errori da evitare:
- ...

## Segreteria o referente

Problema principale:

Azioni frequenti:
- ...

Informazioni necessarie:
- ...

Errori da evitare:
- ...

Per ogni ruolo scrivi frasi concrete, non etichette generiche.

Debole:

Docente: usa il registro.

Utile:

Docente: durante la lezione deve registrare rapidamente il prestito di uno strumento disponibile, senza modificare manualmente gli array dei dati.

La seconda frase contiene contesto, azione, vincolo e rischio.

Dal ruolo al codice

Ora colleghiamo la scheda al progetto.

Se nella scheda del docente scrivi:

Il docente deve poter registrare un prestito solo se lo strumento e disponibile.

Stai iniziando a vedere una regola.

Quella frase non deve diventare subito un bottone. Prima diventa una regola da modellare:

Uno strumento può essere prestato solo se il suo stato è disponibile.

Poi, più avanti, diventerà codice nel dominio o in un caso d’uso.

Esempio di trasformazione:

Frase utente:
Il tecnico deve poter riportare disponibile uno strumento dopo la manutenzione.

Possibile regola:
Uno strumento in manutenzione può tornare disponibile quando la manutenzione è conclusa.

Possibile caso d'uso:
ChiudiManutenzioneStrumento

Possibile informazione necessaria:
id strumento, nota conclusiva, data chiusura

Questa catena è il motivo per cui parliamo di utenti prima di parlare di classi. I nomi del codice dovrebbero nascere dal linguaggio del problema, non dalla fantasia del momento.

Errore comune

Non scrivere utenti troppo generici:

Utente: usa il sistema.

Non serve a nulla.

Meglio:

Docente: durante la lezione deve trovare rapidamente uno strumento e registrare un prestito senza modificare manualmente i dati.

Questa frase contiene gia:

• contesto;
• azione;
• limite;
• rischio.

Altri errori comuni:

• confondere il docente con “admin”;
• chiamare tutto utente;
• descrivere solo schermate e bottoni;
• ignorare chi subisce gli effetti del sistema, come lo studente associato a un prestito;
• inserire subito login e ruoli tecnici anche se il laboratorio non li richiede ancora.

In questa fase non ci serve un sistema di permessi completo. Ci serve capire il problema.

Esercizio guidato

Prendi una frase per ogni ruolo e trasformala in tre elementi:

## Dal ruolo alla regola

Ruolo:

Frase concreta:

Possibile regola:

Possibile azione del sistema:

Dato necessario:

Esempio:

Ruolo:
Docente

Frase concreta:
Il docente deve sapere se un tablet è già in prestito prima di assegnarlo a un altro studente.

Possibile regola:
Uno strumento già in prestito non può essere prestato di nuovo.

Possibile azione del sistema:
RegistraPrestito

Dato necessario:
stato dello strumento, prestito aperto, studente associato

Cosa produrre

Alla fine della lezione devi avere:

• una scheda utenti completa;
• almeno quattro ruoli descritti;
• per ogni ruolo, almeno tre azioni;
• per ogni ruolo, almeno due rischi da evitare;
• almeno tre frasi che potrebbero diventare regole del dominio;
• una matrice semplice ruoli/azioni.

Domande di comprensione

Rispondi per iscritto:

• Perché non conviene partire subito da bottoni e schermate?
• Qual è la differenza tra uno studente come utente e uno studente come dato?
• Quale ruolo ha più bisogno di gestire manutenzione e guasti?
• Quale frase sugli utenti può diventare una regola di dominio?
• Perché non introduciamo subito un sistema completo di permessi?

Controllo finale

La lezione è completata quando puoi rispondere sì:

• so chi usa il registro;
• so perché lo usa;
• so quali azioni sono frequenti;
• so quali informazioni servono davvero;
• ho distinto chi usa la UI da chi appare nei dati;
• ho trovato almeno tre possibili regole partendo dagli utenti.

Nella prossima lezione trasformiamo gli utenti in azioni principali del sistema.