Un diagramma UML delle classi rappresenta classi e relazioni statiche; classi, attributi e molteplicità dipendono dai requisiti.
La progettazione software trasforma requisiti e vincoli in un modello che aiuta a discutere la struttura del sistema. Un diagramma UML delle classi rappresenta classi, proprietà e relazioni statiche; può servire a pianificare il software o a documentare un progetto esistente. È una descrizione e uno strumento di comunicazione, non il programma eseguibile né la prova che un requisito sia stato testato. Un requisito è più utile quando si può verificare con un criterio osservabile, per esempio registrare data di inizio e scadenza di un prestito.
Per una biblioteca si possono introdurre Utente, Copia e Prestito. Il prestito collega una persona a una copia e può contenere le date che descrivono l’evento. Se si modella un titolo distinto dalle singole copie, Libro e Copia sono entità diverse: la scelta dipende dalle regole richieste. La molteplicità della relazione va dichiarata coerentemente con tali regole. Per esempio, uno stesso utente può avere più prestiti nel tempo; ciò non implica che ogni copia possa essere prestata contemporaneamente a più utenti.
Attributi e responsabilità non si assegnano con una ricetta universale. Se dataRestituzione descrive la chiusura di un singolo prestito, collocarla in Prestito permette di mantenere lo storico dell’evento. Le associazioni indicano collegamenti tra classi e le molteplicità chiariscono quante istanze possono partecipare. Un modello troppo concentrato in una classe generica rischia di rendere opache le responsabilità; la soluzione concreta va valutata in rapporto ai requisiti, e non è sufficiente il nome della classe per garantire qualità o testabilità.
Attività: per il requisito “registrare la restituzione di una copia”, proponi classi, attributi e associazioni. Una soluzione plausibile usa Prestito e Copia e aggiunge dataRestituzione al Prestito; esplicita le molteplicità e le assunzioni, compresa la differenza tra Libro e Copia se pertinente. Scrivi quindi un test che crea un prestito aperto, registra la restituzione e verifica che la data sia presente e che l’evento rimanga consultabile. Il diagramma documenta il modello; il test eseguito verifica il comportamento.
- Il diagramma delle classi descrive classi e relazioni statiche per progettare o documentare software.
- Attributi e molteplicità si scelgono in base ai requisiti; una Copia può essere distinta da Libro.
- Un diagramma non è codice eseguibile né sostituisce il test del comportamento.
Metti alla prova quello che hai letto
Nel modello proposto, dove si colloca naturalmente la data di restituzione che chiude un prestito?
- Nell’evento Prestito
- Nel nome del Libro
- Come testo non collegato al modello
- Sempre nella classe Utente
Soluzione e spiegazione
Nell’evento Prestito. La data descrive la chiusura del singolo evento; la scelta resta coerente con i requisiti e il modello adottato.
Fonti
- Unified Modeling Language (UML) 2.5.1, specifica PDF — Object Management Group (OMG)
- Unified Modeling Language Class and Sequence Diagrams — Oregon State University Open Textbook
Nota editoriale
Confronto assistito documentato; revisione docente necessaria
Solo diagramma delle classi, non tutte le notazioni UML né implementazione. Proposta editoriale, non prescrizione del syllabus.