analisi-disegno.com

Homepage  | Blog | Per essere avvisati in caso di nuovi documenti | In English

Errori da evitare nell'utilizzo dei casi d'uso

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:

• 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.

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. Quelle descrivevano delle funzioni interne del sistema, in modo tipicamente astratto; questi 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 fosse una specifica di analisi tradizionale, esattamente con lo stesso stile, e ricadono in descrizioni astratte di funzionalità poco leggibili e validabili.

--->Errore 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.

Eppure mi sono imbattuto, in diverse organizzazioni, nell'utilizzo dei 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 utilizzati in una logica di vera e propria scomposizione funzionale.

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 utilizzare i casi d'uso come se si stesse seguendo un approccio di analisi strutturato.

--->Errore 2: frammentarli in modo eccessivo

In molti sistemi, di complessità media o medio-alta, vengono individuate e definite parecchie centinaia, addirittura migliaia di casi d'uso (quando vengono utilizzati in modo sistematico i 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! Un consiglio, se vi siete trovati 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.

--->Errore 3: dare troppa importanza ai diagrammi

I diagrammi UML dei casi d'uso rappresentano solo una mappa visuale degli utilizzi del sistema. Utile, ma 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:

• Costituiscono una delle cause principali di frammentazione dei casi d'uso
• Non sono ortogonali. Più semplicemente, è sempre possibile trattare una specifica situazione di variante utilizzando uno o l'altro dei tre meccanismi, indifferentemente.
• Favoriscono l'opinione - scorretta - che la scelta di utilizzare l'uno o l'altro dei tre meccanismi fornisca una qualche indicazione relativa alle scelte implementative di chi dovrà realizzare il sistema.

--->Errore 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...
  

Torna a pagina introduttiva casi d'uso

analisi-disegno.com, servizi e materiali per lo sviluppo dei sistemi software, a cura di Adriano Comai.