Casi d’uso (Use Cases)

I casi d’uso (use cases) sono descrizioni di come può essere usato un sistema, così come le si può leggere in un manuale utente.

Il concetto di caso d’uso è stato proposto da Ivar Jacobson, uno degli autori principali di UML, per la prima volta nel 1987. Ma la diffusione del termine avviene a partire dal 1992, con la pubblicazione del libro “Object-Oriented Software Engineering. A Use Case Driven Approach”.

Si tratta, essenzialmente, di una tecnica per scoprire, chiarificare e concordare i requisiti di un sistema. Usare i casi d’uso significa:

  1. Individuare chi (persone, o altri sistemi “esterni”) dovrà usare il sistema
  2. Chiedersi quali sono gli obiettivi che intendono conseguire usando il sistema (all’incirca, un caso d’uso per ogni obiettivo)
  3. Approfondire, in termini di descrizione di scenari concreti, ciascuna modalità d’uso, chiarendo il modo in cui inizia, le risposte che l’utilizzatore si attende dal sistema, la sequenza di passi con cui l’interazione si svolge, eventuali altri soggetti (esterni al sistema) coinvolti.

Ragionare con i committenti (e le altre parti interessate al sistema, come gli utilizzatori) in termini di casi d’uso (cioè di “storie” concrete di utilizzo) agevola notevolmente la scoperta dei requisiti ed il loro progressivo chiarimento. E costituisce un ottimo punto di partenza per le attività di analisi e design, implementazione e test del sistema.

Oltre che nel settore dello sviluppo software, i casi d’uso vengono utilizzati anche in contesti di business process modeling (e business process reengineering).

Nel 2016 Jacobson ha proposto una estensione teorica per adattare meglio i casi d’uso allo sviluppo agile: gli Use Case 2.0.

Diffusione dei casi d’uso

E’ stata da subito notevole.
La proposta di Jacobson è stata subito accettata dalla grande maggioranza degli altri esperti di sviluppo software, sia come un modo più efficace di lavorare alla gestione dei requisiti, che come il punto di partenza ottimale per l’analisi e il design. E i casi d’uso – use cases – sono diventati una componente fondamentale di UML, nonché di tutti i processi di tipo iterativo.

La diffusione dei casi d’uso ha però evidenziato alcuni problemi relativi al loro ambito di applicazione. Ed alcuni errori da evitare nel loro utilizzo.

Ambito di applicazione dei casi d’uso

I casi d’uso vanno bene per descrivere i requisiti di ogni sistema? No.

I casi d’uso vanno bene per descrivere tutte le funzionalità di un sistema? No.

Qualcuno, iper-semplificando, pensa che i casi d’uso siano adatti a descrivere tutti i requisiti, tutte le possibili funzionalità, tutti i possibili sistemi. Non è vero.

I casi d’uso vanno bene per descrivere le modalità di utilizzo di un sistema:

  • che abbia interazioni significative con qualcuno o qualcosa di esterno ad esso (gli attori)
  • in cui le interazioni siano di tipo operativo e strutturato

Esistono altre tipologie di sistemi, per le quali i casi d’uso sono meno adatti. Alcuni esempi:

  • Data warehouse
  • CAD (Computer-Aided Design)
  • Sistemi la cui complessità sia legata alla logica interna, non alle interazioni con l’esterno

Per queste tipologie di sistemi, e consimili, i casi d’uso possono essere definiti, ma non possono aiutare a specificare la maggior parte dei requisiti.

Formazione sui casi d’uso

Altri materiali