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.
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 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:
- sono una specifica che deve essere validata dai committenti e da altre eventuali parti interessate (stakeholders), come presupposto per la realizzazione del sistema
- costituiscono l’input primario per lo sviluppo del software, e per il test funzionale.
Bisogna evitare di ripetere con i casi d’uso gli errori delle specifiche di analisi tradizionali:
tomi che il committente non riesce a leggere, e che 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 spesso astratto. Invece 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:
1: usarli per descrivere le funzionalità interne del sistema, anziché le modalità di utilizzo del sistema da parte di soggetti esterni al sistema (gli “attori”).
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 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 descrivere come verrà usato il sistema, non specificarne a livello atomico ogni singola funzione interna. Non bisogna, cioè, 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 più adeguate, per farlo. Ad esempio i diagrammi di flusso (flow-chart), presenti anche in UML con il nome di activity diagram.
2: frammentarli in modo eccessivo
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, che descrivano gli utilizzi del sistema ad un livello significativo per il committente, e presentate le storie aggregate per la validazione.)
3: dare troppa importanza ai diagrammi
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à 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 dettagliare i casi d’uso a livello testuale.
Un sintomo dell’eccessiva enfasi sui diagrammi è l’utilizzo sistematico dei meccanismi di associazione UML – include, extend, specializzazione. La grande maggioranza degli esperti ritiene tali meccanismi dannosi (con la parziale eccezione della “include”), in quanto:
- Costituiscono una delle cause principali di frammentazione dei casi d’uso
- Generano confusione: è sempre possibile trattare una specifica situazione usando più di uno dei tre meccanismi
- Favoriscono l’opinione – scorretta – che la scelta di utilizzare l’uno o l’altro dei tre meccanismi fornisca qualche indicazione sulle scelte implementative.
4: descrizioni improprie
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:
- sono troppo sintetiche
- non “raccontano una storia” di utilizzo (come avviene in un manuale utente scritto
in modo chiaro), ma descrivono una funzionalità in termini astratti - descrivono la logica interna di funzionamento del sistema, anziché le sue interazioni con i soggetti esterni (gli attori)
- infarciscono la descrizione delle interazioni con indicazioni di livello tecnico relative ai singoli campi di input e output, ai relativi data type, ai controlli da effettuare, alla specifica di algoritmi…