CASI D’USO – Perché dietro ad ogni analisi si nasconde una soluzione

“Poniamo sempre molta attenzione nello sviluppo dei casi d’uso. Questo ci permette di procedere con chiarezza, semplicità e velocità alla ricerca delle migliori soluzioni”

Amiamo porre sempre tante energie nelle prime fasi in quanto questo ci permette di avere ben chiari quali sono gli obiettivi del nostro cliente e di conseguenza identificare quelle che sono le necessarie azioni di sviluppo da realizzare per raggiungere il risultato. Risultato, che ricordiamo essere condiviso con il Cliente in quanto parte attiva ed integrante di tutto il processo.
Compreso questo, possiamo proiettarci verso il modulo successivo, che è quello dedicato alle modalità di utilizzo del sistema da parte dei suoi utilizzatori (attori), i cosiddetti “casi d’uso”.

Cosa sono e perché sono importanti?

Introdotti in UML (Unified Modeling Language) nel 1992 da Ivar Jacobson, ricercatore informatico svedese, che sviluppò la metodologia OOSE (Object- Oriented Software Engineering), conferendogli notorietà internazionale nel campo delle metodologie a oggetti.

Per casi d’uso quindi, si intende la rappresentazione di un insieme di interazioni tra un attore ed un processo che consentono all’utilizzatore di raggiungere il suo obiettivo e/o di svolgere la propria mansione. Questa descrizione viene realizzata a fronte dello sviluppo di una serie di requisiti da parte dell’attore stesso nei confronti del sistema da conseguire. Ciò permette di precisare quali siano le azioni, con relativa verifica d’insieme dell’utilizzatore, e se combaciano alle sue aspettative.

Tale definizione viene quindi utilizzata durante la raccolta dei requisiti così da poter guidare le attività di controllo prodotti del progetto.

Una delle particolari distinzioni apportate da noi, come valore aggiunto apprezzato dai nostri clienti, è di affiancare anche una descrizione testuale in quanto solo il disegno dei diagrammi potrebbe essere non sufficientemente chiaro nelle varie interazioni. Di fatti, nel definire i casi d’uso con una chiara identificazione dell’obiettivo e una sua descrizione dettagliata ed articolata, al contrario del solo diagramma che protrebbe non precisare ciò che il miglioramento di sistema dovrà eseguire.

Ogni passaggio deve svolgere un’azione ben precisa e corrispondente ad una dettagliata sequenza.

Per essere più approfonditi ed esaustivi in quello di cui abbiamo parlato nei pragrafi precedenti, di seguito riportiamo uno schema grafico di un esempio di caso d’uso, da parte di un operatore che deve effettuare la stampa di un’etichetta.