Ecco alcune domande che sono state poste frequentemente nel mondo UML: Cos’è un diagramma dei casi d’uso? Perché il diagramma dei casi d’uso? o semplicemente, Perché i casi d’uso? Alcune persone non sanno cosa sia un caso d’uso, mentre il resto sottovaluta l’utilità dei casi d’uso nello sviluppo di un buon prodotto software. Il diagramma dei casi d’uso è sottovalutato? Spero che troverete la risposta una volta finito di leggere questo articolo.
Cos’è un diagramma dei casi d’uso? Un diagramma dei casi d’uso UML è la forma principale di requisiti di sistema/software per un nuovo programma software in via di sviluppo. I casi d’uso specificano il comportamento atteso (cosa), e non il metodo esatto per farlo accadere (come). I casi d’uso, una volta specificati, possono essere denotati sia nella rappresentazione testuale che in quella visiva (cioè il diagramma dei casi d’uso). Un concetto chiave della modellazione dei casi d’uso è che ci aiuta a progettare un sistema dalla prospettiva dell’utente finale. È una tecnica efficace per comunicare il comportamento del sistema nei termini dell’utente specificando tutti i comportamenti del sistema visibili esternamente.
Un diagramma dei casi d’uso è solitamente semplice. Non mostra i dettagli dei casi d’uso:
Riassume solo alcune delle relazioni tra casi d’uso, attori e sistemi.
Non mostra l’ordine in cui i passi sono eseguiti per raggiungere gli obiettivi di ogni caso d’uso.
Come detto, un diagramma dei casi d’uso dovrebbe essere semplice e contenere solo poche forme. Se il vostro contiene più di 20 casi d’uso, probabilmente state abusando del diagramma dei casi d’uso.
La figura qui sotto mostra la gerarchia dei diagrammi UML e il posizionamento dell’UML Use Case Diagram. Come potete vedere, i diagrammi dei casi d’uso appartengono alla famiglia dei diagrammi comportamentali.
Si noti che:
Ci sono molti diagrammi UML diversi che servono a scopi diversi (come si può vedere dall’albero dei diagrammi UML sopra). Puoi descrivere quei dettagli in altri tipi di diagrammi UML e documenti, e farli collegare dai casi d’uso.
I casi d’uso rappresentano solo i requisiti funzionali di un sistema. Altri requisiti come le regole di business, i requisiti di qualità del servizio, e i vincoli di implementazione devono essere rappresentati separatamente, di nuovo, con altri diagrammi UML.
Origine dei casi d’uso
In questi giorni la modellazione dei casi d’uso è spesso associata a UML, anche se è stata introdotta prima che UML esistesse. La sua breve storia è la seguente:
Nel 1986, Ivar Jacobson ha formulato per la prima volta tecniche di modellazione testuale e visuale per specificare i casi d’uso.
Nel 1992 il suo libro co-autore Object-Oriented Software Engineering – A Use Case Driven Approach ha aiutato a rendere popolare la tecnica per catturare i requisiti funzionali, specialmente nello sviluppo del software.
Scopo del diagramma dei casi d’uso
I diagrammi dei casi d’uso sono tipicamente sviluppati nella fase iniziale dello sviluppo e le persone spesso applicano la modellazione dei casi d’uso per i seguenti scopi:
Specificare il contesto di un sistema
Catturare i requisiti di un sistema
Convalidare un’architettura di sistema
Guidare l’implementazione e generare casi di test
Sviluppato da analisti insieme a esperti di dominio
Diagramma dei casi d’uso a colpo d’occhio
Una forma standard di diagramma dei casi d’uso è definita nell’Unified Modeling Language come mostrato nell’esempio di Use Case Diagram qui sotto:
Come identificare i casi d’uso?
L’identificazione dei casi d’uso, e poi il processo di elicitazione basato sullo scenario continua chiedendo quale valore visibile all’esterno e osservabile che ogni attore desidera. Le seguenti domande possono essere poste per identificare i casi d’uso, una volta che gli attori sono stati identificati (Schneider e Winters – 1998):
Quali funzioni vorrà l’attore dal sistema?
Il sistema memorizza informazioni? Quali attori creeranno, leggeranno, aggiorneranno o cancelleranno queste informazioni?
Il sistema ha bisogno di notificare ad un attore i cambiamenti nello stato interno?
Ci sono degli eventi esterni che il sistema deve conoscere? Quale attore informa il sistema di questi eventi?
Suggerimenti per il diagramma dei casi d’uso
Ora, controlla i suggerimenti qui sotto per vedere come applicare efficacemente i casi d’uso nel tuo progetto software.
Strutturare e organizzare sempre il diagramma dei casi d’uso dalla prospettiva degli attori.
I casi d’uso dovrebbero iniziare in modo semplice e nella vista più alta possibile. Solo allora possono essere raffinati e dettagliati ulteriormente.
I diagrammi dei casi d’uso sono basati sulla funzionalità e quindi dovrebbero concentrarsi sul “cosa” e non sul “come”.