Il formalismo dei casi d‘uso è senza dubbio uno standard de facto di analisi dei requisiti utente. Abbiamo visto nell‘articolo precedente quanti e quali sono i modelli dei casi uso, oltre a perché, come e quando realizzarli. In questo articolo analizzeremo un esempio concreto.

Introduzione

In questo articolo presentiamo alcune parti di un reale sistema al fine di fornire una base concreta alla precedente trattazione. In particolare, abbiamo scelto di prendere come riferimento un sistema per il commercio elettronico: tutti i lettori ne hanno sicuramente utilizzato uno. Si tratta del classico sito internet che permette agli utenti registrati, “comodamente seduti nella poltrona di casa”, di visionare il catalogo degli articoli disponibili ed, eventualmente, di effettuare un ordine di acquisto.

Ecco l‘esempio

Si supponga che il processo di sviluppo del software disegnato preveda tutte e tre le versioni di modello dei casi d‘uso. Nel modello dei casi d‘uso di business sarebbe possibile trovare i seguenti casi d‘uso divisi per attore:

Figura 1 – Tabella con il possibile elenco di servizi presenti nell‘intera area business di un sito per il commercio elettronico

Abbiamo introdotto la tabella di figura 1 con l‘unico scopo di evidenziare come un‘intera area business operino un gran numero di attori (detti appunto attori business) interessati alla fruizione di svariati servizi, molti dei quali non sono contemplati dal sistema da realizzare.

Nel diagramma di Figura 2 è riportato un esempio relativo a due casi d‘uso del relativo modello di business. Si può notare che la notazione grafica utilizzata è leggermente diversa: sia nell‘icona degli attori, sia in quella dei casi d‘uso è presente una barretta obliqua. Si tratta di stereotipi utilizzati proprio per indicare la natura business di questi elementi.

Figura 2 – Pianificazione vendita nuovo articolo: un esempio di use case business

Da un breve analisi dell‘elenco sommario dei casi d‘uso riportati in Figura 1 è possibile effettuare una serie di deduzioni:

1. Sono presenti diversi attori e casi d‘uso fuori scope per il sistema da sviluppare che comunque sono interessanti per comprendere il business, istruire personale neo-assunto, progettare altri sistemi;
2. Sono presenti diversi casi d‘uso che, verosimilmente, appartengono a diversi domini. Per esempio, è abbastanza legittimo attendersi un dominio relativo al sito internet vero e proprio, un altro relativo alla gestione dei dati, e così via.

Il passo successivo consiste nel realizzare i casi d‘uso a livello di dominio. Pertanto è necessario trascurare i casi d‘uso relativi a processi umani e a servizi che non si intende realizzare e dividere i casi d‘uso nei diversi domini.
Supponendo di non voler realizzare anche il sistema per la gestione del marketing, customer care e a supporto del manager prodotti, restano (apparentemente) due domini: sito per il commercio elettronico vero e proprio e sistema di gestione dei dati. È importante suddividere i casi d‘uso per dominio in quanto ciascuno di essi dà  vita ad un diverso sistema.
A questo punto si potrebbe analizzare un use case come il seguente per la compilazione degli ordini di acquisto.

Figura 3 – Caso d‘uso: compila ordine di acquisto

Come specificato in precedenza, quantunque i diagrammi dei casi d‘uso forniscano un ottimo ausilio al difficile processo di analisi dei requisiti non funzionali, da soli risultano assolutamente insufficienti per analizzare e documentare le diverse importantissime informazioni celate dietro il nome di ogni servizio. A tal fine è necessario associare a ciascun diagramma un documento con la specifica del comportamento dinamico. Si consideri l‘esempio riportato di seguito (figg. 4, 5, 6, 7). Questo descrive dettagliatamente molte altre importanti informazioni, come cosa fare nel caso in cui tutto funzioni correttamente, quali solo le condizioni che non permettono di terminare con successo il caso d‘uso, quali procedure avviare per la relativa gestione, etc.

Figura 4 – Use case

Figura 5 – Scenario principale

Figura 6 – Scenari alternativi e di eccezione

Figura 7 – Evoluzione del caso d‘uso

Alcune considerazioni

Dall‘analisi della specifica del caso d‘uso è possibile evidenziare che non ci sono tentativi di verificare condizioni di errore del sistema e di descriverne la gestione richiesta. Per esempio non si tenta di gestire errori di connessione al database, di scrittura informazioni, etc. Questo essenzialmente per due motivi:

1. Si tratta di problemi a elevata connotazione tecnica di cui gli utenti tipici non hanno competenza sufficiente per specificarne i dettagli della gestione. Pertanto è anche conveniente non appesantire i casi d‘uso con queste nozioni estranee alle competenze dei fruitori principali dei casi d‘uso: ancora gli utenti.
2. Il capo architetto dovrebbe redigere un documento in cui specificare le procedure da attuare per gestire situazioni di errori di sistema. Queste, tipicamente, richiedono non solo dettagli tecnici, ma anche scelte architetturali. Per esempio si potrebbe decidere di utilizzare un‘applicazione di gestione degli errori a cui il sistema dovrebbe inviare un messaggio ogni qualvolta un problema tecnico viene rilevato; oppure disporre di software in grado di monitorare i file di log dei vari sistemi e quindi individuare record relativi a gravi problemi riscontrati. Questo tra l‘altro evita di dover ripetere le stesse informazioni in ogni caso d‘uso con gravi ripercussioni qualora la strategia di gestione dei problemi di sistema dovesse cambiare.

Apparentemente la specificazione del precedente caso d‘uso non presenta anomalie. Nella realtà  però sporadicamente si verifica il caso di dover realizzare sia il sistema web per il commercio elettronico, sia il sistema di back-office. Molto più frequente è il caso di dover integrare il sistema web con un preesistente software di gestione del back office (legacy). Questa evenienza fa sì che feedback architetturali assumano un ruolo molto importante nel processo di analisi dei requisiti utente. In particolare, ciòo determina sia la necessità  di aggiornare i casi d‘uso modellati, sia di aggiungerne altri.
Per esempio, nel caso del caso d‘uso per la compilazione degli ordini, potrebbe rendersi necessario aggiungere ulteriori passi atti a specificare l‘invio degli ordini al sistema di legacy.
Per quanto riguarda nuovi casi d‘uso, potrebbe risultare necessario prevedere prevederne altri quali

• Riconciliazione ordini.
• Ricezioni feedback relativo allo stato di avanzamento degli ordini (molti ordini sono effettuati nel sito internet e poi inviati al sistema di legacy il quale ne effettua la gestione). Le informazioni relative all‘avanzamento degli ordini (accettato, evaso, merce spedita, etc.), tuttavia, devono essere comunicate indietro al sito web in quanto gli utenti accedono a quest‘ultimo per ricevere informazioni sullo stato di avanzamento dei propri ordini.
• Un intero dominio (ossia un altro insieme di casi d‘uso) relativo al sistema di wrapping del legacy system necessario a far dialogare quest‘ultimo con il sistema web.

I lettori più attenti avranno notato come anche la politica di gestione della comunicazione tra sistema web e legacy system (ancora una volta scelte architetturali) influenzi notevolmente la modellazione dei casi d‘uso. In particolare è possibile optare per una delle seguenti scelte architetturali:

1. i due sistemi mantengono sincronizzate le varie informazioni attraverso scambio di messaggi;
2. il sistema web, ogni qualvolta necessiti delle informazioni, accede al legacy system per reperirle (si considerino sistemi per la prenotazione di biglietti aerei).

La prima strategia richiede di realizzare tutta una serie di casi d‘uso necessari per lo scambio e il processamento dei messaggi; la seconda richiede di inserire passi aggiuntivi nei i casi d‘uso realizzati al livello di dominio.

Conclusioni

Questo semplice esempio pratico dimostra come sulla base della versione finale del modello dei casi d‘uso, definita di sistema, sia possibile svolgere le successive fasi del processo di sviluppo del software.
Questo esempio dovrebbe aver chiarito definitivamente sia l‘importanza di ricevere feedback di carattere architetturale per la produzione dei casi d‘uso, sia come ciò non significhi assolutamente includere all‘interno dei casi d‘uso il “modo pratico” di implementare i requisiti.

Riferimenti

[1] Luca Vetti Tagliati, “UML e Ingegneria Del Software. Dalla Teoria Alla Pratica”, HOPS/Tecniche Nuove, 2003

[2] IEEE Recommended Practice for Software Requirements Specifications IEEE Std 830-1998

[3] Frank Armour – Granville Miller, “Advanced Use Case Modelling. Software Systems”, Addison Wesley

[4] Ivar Jacobson, “Object Oriented Sofware Engineering. A Use Case Approach”, Addison Wesley

[5] Michael Jackson, “Software Requirements And Specification”, Addison Wesley

[6] Alistair Cockburn, “Writing Effective Use Cases”, Addison Wesley