analisi-disegno.com
I casi d'uso sono semplici da leggere, e sono comprensibili da chiunque.
Sia per i non informatici (committenti, utenti) che per gli informatici, una descrizione delle modalità di utilizzo del sistema basata sui casi d'uso permette di capire cosa fa il sistema molto più velocemente e in profondità, rispetto alle tradizionali documentazioni di requisiti o specifiche di analisi.
E non è neppure difficile scriverli. Scrivere i casi d'uso è come scrivere il manuale utente: si specifica la "storia" di un utilizzo del sistema, descrivendo le interazioni tra il sistema e il mondo esterno (utilizzatori, altri sistemi). Un lavoro da scrittore di manuali tecnici, ma che per gli utilizzi normali può essere svolto da chiunque abbia una padronanza normale della lingua.
Il problema vero, con i casi d'uso, è capire bene cosa sono, e soprattutto a cosa servono:
Bisogna evitare di ripetere con i casi d'uso gli errori delle specifiche di analisi tradizionali: tomi di carta che il committente non ha il coraggio di leggere, e che se legge non è sempre in grado di capire fino in fondo, per riscontrare errori ed omissioni.
Rispetto alle specifiche di analisi tradizionali, i casi d'uso hanno un vantaggio di fondo, in termini di comunicazione. Le specifiche funzionali tradizionali descrivono funzioni interne del sistema, in modo tipicamente astratto; i casi d'uso descrivono delle storie di utilizzo, in modo tipicamente concreto, sotto forma di dialogo: cosa fa l'utente, cosa risponde il sistema, ecc.
Purtroppo, molti analisti utilizzano i casi d'uso come se scrivessero una specifica di analisi tradizionale, e ricadono in descrizioni astratte di funzionalità poco leggibili e validabili. Di seguito, gli errori più frequenti
I casi d'uso hanno uno specifico ambito di applicazione. Servono a descrivere la logica di interazione tra il sistema e ciò che è esterno ad esso.
Alcuni, invece, utilizzano i casi d'uso per descrivere i diversi step di una procedura batch, o le funzioni elementari di creazione, lettura, aggiornamento ed eliminazione di ogni entità del sistema. In altri termini, i casi d'uso vengono usati in una logica di vera e propria scomposizione funzionale, per la quale non sono adeguati.
In questo modo, si perdono completamente tutti i vantaggi dei casi d'uso, sotto il profilo della comunicazione con il committente e gli altri stakeholders. E' opportuno ricordare che i casi d'uso devono fornire una descrizione degli utilizzi del sistema, non descrivere a livello atomico ogni singola funzione del sistema: non bisogna usare i casi d'uso come se si stesse seguendo un approccio di analisi strutturata.
I casi d'uso servono a descrivere la logica di interazione tra il sistema e ciò che è esterno ad esso. Non a specificare la logica interna di una qualunque funzionalità o di una qualunque parte di sistema. Esistono altre tecniche molto più adeguate, per farlo. Ad esempio i diagrammi di flusso (flow-chart), presenti anche in UML con il nome di activity diagram.
In molti sistemi, di media o elevata complessità, vengono individuate e definite parecchie centinaia, se non migliaia di casi d'uso (in particolare, quando ci si avvale in modo sistematico dei meccanismi di associazione previsti da UML - include, extend, specializzazione).
Pensate al povero committente che dovrebbe validare centinaia o migliaia di casi d'uso corrispondenti a funzionalità "elementari" del sistema!
(Se vi trovate in una situazione del genere: raggruppate più casi d'uso "atomici" in storie più aggregate (casi d'uso "business"), che descrivano gli utilizzi del sistema ad un livello significativo per il committente, e presentate le storie aggregate per la validazione.)
I diagrammi UML dei casi d'uso forniscono una mappa visuale degli utilizzi del sistema. Utile, anche se non indispensabile.
I diagrammi non servono alla validazione da parte dei committenti e delle altre parti interessate a comprendere le modalità di utilizzo del sistema. Ed hanno un'utilità molto limitata anche per chi deve realizzare il software.
Si tratta di un errore molto comune, e non sono rare le situazioni in cui gli analisti spendono molto tempo a lavorare sui diagrammi invece di descrivere i casi d'uso in modo approfondito a livello testuale.
Un sintomo significativo dell'eccessiva enfasi sui diagrammi è l'utilizzo sistematico dei meccanismi di associazione UML - include, extend, specializzazione. La grande maggioranza degli esperti ritiene tali meccanismi perniciosi (con la parziale eccezione dell'"include"), in quanto:
Le descrizioni dei casi d'uso rivestono un'importanza fondamentale, sia per chiarire e concordare i requisiti che come input per chi deve realizzare il sistema. Ma non raggiungono l'obiettivo quando:
Pagina introduttiva casi d'uso
analisi-disegno.com , servizi e materiali per lo sviluppo dei sistemi software, a cura di Adriano Comai.