I casi d'uso sono storie scritte, utilizzate per scoprire e registrare i requisiti.
La figura mostra l'influenza tra alcuni elaborati UP, con un'enfasi sui casi d'uso testuali.
Esempio: in generale i casi d'uso sono storie scritte, testuali, di qualche attore che usa un sistema per raggiungere degli obiettivi, ecco un esempio in formato breve.
Elabora vendita (Process Sale): un cliente arriva alla cassa con alcuni articoli da acquistare. Il cassiere utilizza il sistema POS per registrare ogni articolo acquistato. Il sistema mostra il totale e i dettagli per ogni articolo. Il cassiere inserisce informazioni sul pagamento, che il sistema convalida e registra. Il sistema aggiorna l'inventario. Il cliente riceve dal sistema una ricevuta e poi se ne va con gli articoli acquistati
I casi d'uso non sono diagrammi, ma testo. Un errore comune è concentrarsi sui diagrammi UML quando si tratta dei casi d'uso, che hanno un valore secondario.
Alcune definizioni:
Un attore è qualcosa o qualcuno dotato di comportamento, come una persona (con un ruolo), un sistema informatico, o un'organizzazione; per esempio: un cassiere o il sistema per la gestione dell'inventario.
Detta anche istanza di caso d'uso, è una sequenza specifica di azioni e interazioni tra il sistema e alcuni attori. Uno scenario descrive una particolare storia nell'uso del sistema, ovvero un percorso attraverso il caso d'uso. Per esempio, un possibile scenario è quello che prevede di effettuare un acquisto, che va a buon fine, pagando in contanti. Un altro scenario potrebbe essere relativo a un acquisto fallito, perché non è stata concessa l'autorizzazione a un pagamento con carta.
Un caso d'uso è una collezione di scenari correlati, sia di successo che di fallimento, che descrivono un attore che usa un sistema per raggiungere un obiettivo specifico.
Esempio in formato informale di caso d'uso che contiene scenari alternativi.
Gestisci restituzione
Scenario principale di successo: un cliente arriva la cassa con alcuni articoli da restituire. Il cassiere utilizza il sistema POS per registrare ciascun articolo restituito...
Scenari alternativi:
1. Se il cliente aveva pagato con carta, e l'operazione di rimborso sulla relativa carta è stata respinta, allora il cliente viene informato e rimborsato in contanti.
2. Se il codice identificativo dell'articolo non viene trovato nel sistema, il sistema notifica il cassiere suggerendo l'inserimento manuale del codice.
3. Se il sistema rileva un fallimento nella comunicazione con il sistema esterno di gestione della contabilità, ...
Casi d'uso e il modello di casi d'uso di UP...
In UP i casi d'uso sono documenti di testo, non diagrammi, e la modellazione dei casi d'uso è un atto di scrittura testi, non di disegno di digrammi.*
Il modello dei casi d'uso non è l'unico elaborato per i requisiti di UP. Ci sono anche le Specifiche Supplementari, il Glossario, la Visione, le Regole di Business (che saranno affrontati successivamente).
I casi d'uso non sono orientati agli oggetti; quando li si scrive, non si sta facendo analisi Orientata agli Oggetti. Questo non è un problema, anzi rende i casi d'uso largamente applicabili e ne aumenta l'utilità. Infatti, i casi d'uso non costruiscono un modo chiave per rappresentare i requisiti come input utile per l'Analisi e il Design Orientato agli Oggetti (OOA/D). Da qui deriva il fatto che eventuali diagrammi non hanno alcuna freccia, ma solo line di collegamento/interazione.
Il perché dei casi d'uso...
I casi d'uso sono semplici. Comprensibili da qualsiasi tipo di cliente. Inoltre sono applicabili a diverse situazioni: dal un gioco, ad un sistema matematico, ad uno gestionale. Inoltre essi mettono in risalto gli obiettivi degli utenti e il loro punto di vista, essi offrono una risposta a domande come: chi usa il sistema? Quali sono gli scenari tipici di utilizzo? Quali i loro obiettivi?. Quando si modella un caso d'uso non ci si deve in nessun modo preoccupare di aspetti secondari (come i diagrammi dei casi d'uso, le relazioni tra i casi d'uso, i package dei casi d'uso,..), si deve essere concentrati solo sullo scrivere i casi d'uso.
I casi d'uso sono soprattutto requisiti funzionali, che indicando il comportamento del sistema. I casi d'uso non sono i requisiti del sistema, come per esempio potrebbero essere, sotto-forma di elenchi e/o note. I casi d'uso servono proprio per ridurre materiale di questo tipo.
Tipi di attori...
Un attore è qualcosa dotato di comportamento.
- Attore primario: utilizza direttamente i servizi del sistema
- Attore finale: vuole che il sistema sia utilizzato affinché vengano raggiunti degli obiettivi: per esempio il cliente che richiede la costruzione del sistema.
- Attore di supporto: offre un servizio (per esempio, informazioni) al sistema, un esempio è il servizio informatico di autorizzazione dei pagamenti con carta di credito. Spesso è un sistema informatico, ma potrebbe anche essere un ente o una persona.
- Attore fuori scena: c'entra con il comportamento del caso d'uso (e del sistema), ma non è un attore primario/finale/di supporto. Un esempio è l'ente governativo interessato al pagamento delle imposte.
Diversi formati di casi d'uso...
- Breve: riepilogo conciso di un solo paragrafo, relativo allo scenario principale di successo del sistema. Va usato durante l'analisi iniziale dei requisiti
- Informale: più paragrafi, scritti in modo informale, relativi a diversi scenari. Va usato come il formato breve, ma con poco più dettagli
- Dettagliato: tutti i passi e le variazioni sono scritti nel dettaglio; ci sono anche delle sezioni di supporto, come le pre-condizioni e le garanzie di successo. Va usato quando sono stati trovati numerosi casi d'uso e sono stati scritti in formato breve, alcuni casi d'uso (circa il 10%) che hanno valore maggiore e che sono più significativi dal punti di vista dell'architettura vengono scritti in formato dettagliato. E poi, nelle iterazioni successive, anche gli altri casi d'uso verranno via via scritti in formato dettagliato.