1. capire (o carpire) le esigenze che determinano la necessità di un nuovo sistema informatico;
2. analizzare lo scenario del cliente con particolare attenzione alle risorse disponibili: sia umane (!), sia di carattere tecnologico (parco macchine, connessioni, reti, software utilizzati,…).

Use case view
Eseguita la precedente introduzione, si procede col focalizzare l’attenzione sulla prima vista logica: la Use Case View.
Si tratta di una delle più importanti, sia perché è quella che tipicamente firma il cliente (si consiglia di richiedere l’utilizzo del sangue come inchiostro), sia perché le restanti si occupano di modellare quanto specificato in essa.
La vista Use Case si basa, essenzialmente, sugli omonimi diagrammi, frutto del lavoro di I. Jacobson durante la sua collaborazione con la Ericsson nell’ambito dello sviluppo di un sistema denominato AXE.
Visto il successo riscosso dai diagrammi e percepite le relative potenzialità, i “Tres Amigos” (I. Jacobson, G. Booch e J. Rumbaugh) hanno pensato bene di inglobarli nell’UML.
Gli use case diagram sono utilizzati per dettagliare le singole funzionalità del sistema. A tal fine utilizzano un certo numero di elementi denominati use case!
Qui si corre il rischio di fare confusione! In effetti, la prima vista logica, i relativi diagrammi (o meglio, quelli di maggior rilevo) e alcuni elementi di questi ultimi (quelli che rappresentano le funzioni del sistema), si chiamano tutti, grazie ad un sovrumano lavoro di fantasia, use case!
Per tentare di far chiarezza si consideri la figura 1.
 
 

Figura 1. Struttura della Use case view.

Dunque, la prima vista è composta da più diagrammi, di cui i principali sono gli use case diagram che, a loro volta, permettono di specificare le funzioni del sistema per mezzo di elementi grafici a forma di ellissi, che appunto prendono il nome di use case.
Spesso in questa vista compaiono anche gli “activity “ e i “sequence” diagram (consultare [6]). Entrambi saranno oggetto di articoli futuri. Per ora basti sapere che servono per modellare aspetti dinamici del sistema.
Quando i sequence diagram vengono forniti nella use case view, essi realizzano i cosiddetti “scenario” e rappresentano una versione, ad elevato grado di astrazione, dei flussi di azioni racchiusi dai casi d’uso. Di essi esisteranno delle versioni di maggior dettaglio nella Design View.
Per semplificare al massimo il concetto, è possibile riportare la seguente proporzione: gli “scenario” stanno agli use case come gli oggetti stanno alle classi. 
A lavoro concluso, i diagrammi dei casi d’uso devono rappresentare tutte le funzioni del sistema, a partire dal relativo avvio, o richiesta, che necessariamente deve essere generata da un attore del sistema, fino alla relativa conclusione. 
Gli attori, sono entità esterne al sistema che hanno interesse ad interagire con esso. Pertanto, contrariamente a quanto lascerebbe pensare il nome, e a memorie derivanti dai DFD, gli attori sono sia persone fisiche, sia sistemi o dispositivi hardware che interagiscono con il sistema.
Vale la pena sottolineare, per l’ennesima volta, che a questo livello di analisi, il sistema è visto come una scatola nera, pertanto si deve descrivere cosa fa il sistema senza specificarne il come. L’impegno è proprio nel cercare di isolarsi, di astrarsi il più possibile da dettagli realizzativi. Lo studio dei quali è demandato alle apposite fasi.
 
 
 

Obiettivi
Gli obiettivi da raggiungere quando si esegue l’analisi dei requisiti sono:

1. decidere e descrivere le specifiche funzionali concordate con il cliente, le quali dovrebbero confluire nel contratto che l’azienda sviluppatrice sottoscrive con il cliente;
2. fornire una chiara e consistente descrizione delle funzionalità che il sistema realizzerà, in modo da utilizzarlo anche nelle altri fasi del processo di ingengerizzazione del sistema;
3. generare un modello che consenta di eseguire il test del sistema;
4. disporre, con le varie versioni dello use case, di una traccia dell’evoluzione del sistema e/o dei requisiti utente, che tipicamente si rinnovano ad ogni ciclo lunare!

Per poter realizzare la vista dei casi d’uso, è necessario definire il sistema, identificare correttamente gli attori, definire le funzioni dei vari diagrammi, determinare le relazioni tra use-case ed, infine, validare il sistema. Pertanto si tratta di un'attività che richiede un'elevata interazione con il cliente e con le persone che rappresentano gli attori del sistema stesso.
Sebbene ogniqualvolta venga proposto uno strumento dedicato all’analisi concettuale di un sistemi, si afferma che esso possa essere facilmente compreso dal cliente (vedi diagrammi E-R e/o DFD), nella realtà ciò si verifica molto raramente. Almeno questa è la personale esperienze dell’autore! Pertanto l’analisi dei requisiti deve essere comunque espressa anche per mezzo di altri strumenti, quali per esempio un buon documento in linguaggio naturale.
L’UML, comunque, prevede di descrivere il comportamento interno di un use case per mezzo del relativo flusso di eventi, che specifica quando un use case inizia, quando termina, quando interagisce con un attore, quali oggetti vengono scambiati, ecc. 
Dunque, il ruolo dei vari diagrammi viene in qualche modo dimensionato a rappresentarne una sorta di overview.
La speranza è che, utilizzando un formalismo grafico, il tutto risulti più accattivante, immediato e comprensibile al cliente.
Chiaramente, non è pensabile di riuscire, attraverso una serie di grafici, a descrivere tutti i dettagli del sistema, e si sa che una deficienza nell’analisi dei requisiti può, già da sola, causare l’insuccesso di un intero progetto.
 
 
 

Fruitori della use case view
La vista use case è di interesse per una nutrita schiera di tecnici e figure professionali differenti.
In primo luogo vi sono i clienti: la use case view specifica le funzionalità del sistema e come esso dovrà essere utilizzato. Dunque è necessario per riuscire a carpire le reali necessità del cliente, i suoi sogni più o meno consci, eventuali reticenze…
Poi, è necessaria al team di sviluppatori poiché fornisce le direttive su come realizzare il modello.
Altra categoria di utilizzatori è costituita dalle persone che dovranno effettuare le verifiche finali (note anche come test di sistema): l’utilizzo di tale vista consente di assicurare che il sistema prodotto realizzi pienamente ciò che è stato sancito con il cliente.
Per finire, si vuole escludere i commerciali? Ma certo che no! Anzi, sarebbe auspicabile che i commerciali e gli addetti al marketing gli dessero un’occhiata, giusto quel tanto che basta per capire di cosa si sta parlando!
Si potrebbe “addirittura” correre il rischio di evitare di vendere congelatori agli esquimesi ed impianti di riscaldamento agli africani!
 
 

Use case diagram
Come già riportato in precedenza, una vista use-case viene realizzata per mezzo di una serie di diagrammi, la maggior parte dei quali è costituita da use case diagram. Ciascuno di essi è composto da attori, da use case e da relazioni che legano tali elementi. Inoltre, ciascun diagramma deve essere corredato dalla relativa descrizione.
 
 
 

Il sistema
Anche se può sembrare un’attività piuttosto banale, il primo passo consiste nello stabilire il confine del sistema. Non sempre è così facile come può sembrare, in quanto non sempre si riesce a determinare se talune attività è meglio eseguirle manualmente o automatizzarle: vi è mai capitato che un operatore vi dicesse che un’attività x prima dell’introduzione del computer la svolgeva in pochi secondi e dopo gli ci volevano ore?
Un’altra considerazione da farsi è quanto grande si vuole realizzare il sistema nelle sue prime versioni.
Una buona idea è quella di identificare le funzionalità ritenute indispensabili: il “core” del nuovo sistema.
Procedendo in questo modo, è possibile concentrarsi su un insieme limitato di funzioni per riuscire a realizzare una soddisfacente prima versione del sistema. Raggiunto l’obiettivo e convinto il cliente della qualità del lavoro prodotto, si possono aggiungere (altro giro altro fiorino) le altre funzioni ritenute di secondaria importanza.
Questo approccio, basato sul metodo “Iterative and Incremental” (consultare [6]), tipicamente incontra il consenso del cliente: sebbene nel complesso si trovi a sborsare una somma superiore, lo fa a rate!
Infine, anche se non viene specificatamente enunciato nell’UML, è consigliabile redigere, fin dai primi incontri con il cliente, una sorta di glossario delle terminologie utilizzate nel relativo ambiente. Ciò è molto utile sia per esser certi della mancanza di ambiguità, sia per favorire il lavoro del restante personale coinvolto nel ciclo di vita del sistema (dalla prima realizzazione alle successive manutenzioni).
Il sistema dovrebbe essere evidenziato per mezzo di un rettangolo che contenga i use case di cui è composto e lasci all’esterno gli attori: un vero e proprio confine. Per esigenze di “rendering” grafico (e lacune dei tools), viene quasi sempre omesso.
 
 
 
 
 

Figura 2. Esempio di un digramma use-case di un ipotetico (ed improbabile) esercizio di noleggio CD.

 
 

Gli attori
Un attore è una persona o qualcosa che interagisce con il sistema: un’entità che utilizza il sistema. Pertanto un attore può inviare o ricevere messaggi dal sistema, ossia può scambiare informazioni con esso.
Nel linguaggio grafico UML essi sono rappresentati per mezzo di omini stilizzati, ribattezzati in gergo tecnico “scarabocchi” (o più teneramente “scarabocchietti”), con il relativo nome riportato alla base.
Non necessariamente un attore deve essere una persona fisica, anche altri sistemi o dispositivi hardware possono assumere il ruolo di attore. Se per esempio si dovesse modellare un sistema in grado di monitorare il livello dell’acqua di una rete di canali, i sensori derogati a comunicare i dati raccolti (livello dell’acqua, quantità di pioggia, …), avrebbero la dignità di essere elevati al ruolo di attori. Per esempio, si consideri la figura seguente (figura 3), in cui sia l’operatore del centro, sia i vari sensori e dispositivi sono degli attori per il sistema oggetto di studio.
 
 

Figura 3. Frammento di use case per la gestione automatica di un sistema di canali

 
 
 

Figura 4. Esempio di impiego di un diagramma use-case per modellare un sistema d’arma

 

Ancora, se si dovesse modellare un sistema d’arma missilistico (vedere figura 4), gli operatori, i “radar”, il sistema di lancio, gli eventuali missili lanciati, sarebbero tutti attori del sistema, in quanto trasmettono o ricevono informazione a o dal sistema.
L’esempio illustrato, sebbene risulti essere una notevole semplificazione, è stato riportato sia per evidenziare come l’UML si adatti a rappresentare sistemi diversi dai classici applicativi, sia per rifuggire dagli inflazionatissimi esempi… Si preferiva l’esempio della biblioteca!? (Si provi ad indovinare quali sono state le esperienze militari dell’autore!) Dovrebbe essere ormai chiaro che un attore, in ultima analisi, è una particolare classe e non una sua istanza (oggetto).
Quando si esegue l’analisi dei requisiti è necessario compiere uno sforzo di astrazione: un attore rappresenta un ruolo e non uno specifico individuo, anche perché, in talune realtà organizzative (specie quelle di medio-piccole dimensioni) una stessa persona può “recitare” più ruoli, oppure, uno stesso ruolo “logico” può essere suddiviso tra più dipendenti!
Gli attori comunicano con il sistema inviando o ricevendo messaggi: forniscono lo “stimolo” agli use case; ciò equivale a dire che ogni use case deve essere necessariamente avviato da un’esplicita richiesta di un attore.
Una tecnica utilizzata per semplificare il processo di individuazione degli attori consiste nel classificarli in primari e secondari. I primari sono quelli che utilizzano le funzioni proprie del sistema, e pertanto vengono anche definiti attivi; i secondi fruiscono informazioni o si occupano di manutenere il sistema: ricevono dati statistici, eseguono backup, effettuano l’amministrazione degli utenti, e così via. Questi sono i cosiddetti attori secondari o passivi.
Per esempio, nell’ambito delle assicurazioni, la persona che segue l’evoluzione di una pratica è sicuramente un attore primario, mentre un manager che utilizza il sistema per generare dei rapporti sull’andamento della società può essere considerato secondario. La differenza sostanziale tra i due tipi è che mentre gli attori primari avviano delle funzionalità proprie del sistema, i secondi ne ricevono dei messaggi ma non forniscono mai un vero e proprio stimolo!
 
 

Relazioni tra attori: generalizzazione
Negli use case l’unica relazione che può essere utilizzata per illustrare un comportamento comune tra attori è la generalizzazione. In sostanza ciò significa che un attore “specializzato” eredita il comportamento di un altro e lo estende in qualche maniera. Per esempio si consideri un ipotetico sistema con due attori: operatore e amministratore. L’amministratore risulta caratterizzato dallo svolgere tutte le funzioni dell’operatore, ed in più un insieme di funzioni aggiuntive ritenute sensibili per il sistema. In questo caso, si potrebbe asserire che l’attore amministratore eredita dall’attore operatore.
Ancora, con riferimento alla figura 4, si può vedere che un radar di identificazione, svolge tutti i compiti di un comune radar ed in più, lo specializza, in quanto ha dei metodi che consentono di verificare se la traccia fornitagli rappresenta un amico o un nemico. Tali radar vengono comunemente indicati con l’acronimo IFF (Identificator Fiend or Foe).
A dir il vero, tipicamente non sono in grado di stabilire se una traccia sconosciuta rappresenti effettivamente un nemico (almeno che non si tratti di un missile in avvicinamento!) e pertanto dovrebbero essere indicati con l’acronimo IFU.
Un altro legame che talvolta viene evidenziato tra gli attori di un use case diagram è “un’associazione semplice” che indica che il sistema viene utilizzato fisicamente da un attore che, però, fa le veci di un altro.
Per esempio, (vedere figura 2) nel caso del cliente che si reca nel negozio per noleggiare un CD, è il commesso ad utilizzare fisicamente il sistema, ma in realtà è il cliente che comunica degli stimoli al sistema, e ne riceve le risposte.
 
 

I casi d’uso
Un use case rappresenta una funzionalità completa così come viene percepita da un attore.
Esso è definito come una sequenza di azioni che il sistema esegue per produrre un risultato osservabile per un particolare attore. Le caratteristiche (fondamentali) che devono possedere gli use case sono:

• essere sempre avviati da un attore, il quale fornisce lo stimolo, sia direttamente e sia indirettamente;
• produrre dei risultati osservabili per un attore;
• essere completi.

Descrizione dei casi d’uso (Flow of Events).
I casi d’uso vengono descritti per mezzo dei flussi di eventi (Flow of Events). Essi descrivono cosa un sistema fa ma non dicono assolutamente nulla sul come (sorpresi?).
Il comportamento dei singoli use case deve essere descritto per mezzo di un linguaggio sufficientemente semplice da poter essere facilmente compreso anche da personale non tecnico.
All’interno dei flussi di eventi è necessario esplicitare chiaramente quando uno use case inizia, quando finisce, quando interagisce con gli attori, quali oggetti scambia, il flusso base e quelli alternativi. (Non manca proprio nulla!)
Si consideri l’esempio dell’interazione di un acquirente con un “POS” per la validazione dello stesso.

 FLUSSO PRINCIPALE:

AVVIO:  Il sistema si dispone a far digitare all’utente il PIN. (Le altre operazioni sono già state espletate);
FLUSSO:
1. L’utente digita il PIN;
2. Sottomette il codice inserito (Pressione del tasto “enter”);
3. Il sistema esegue la procedura di validazione del PIN;
4. Se il PIN è corretto il sistema abilita l’esecuzione della transazione.  TERMINE:
Il sistema valida il PIN;

FLUSSO:
1. L’utente può, in ogni istante, cancellare una transazione (pressione del tasto cancel);

FLUSSO:
1. L’utente può, in ogni istante, abortire la digitazione del PIN (pressione del tasto “cancel”);

FLUSSO:
1. L’utente imposta per tre volte consecutive un PIN non valido; 
2. Il sistema cancella la transazione e va in blocco temporaneo.

Figura 5. Esempio di generalizzazione. Validazione utente

Quanto testé asserito vale anche per l’esempio di figura 6.
 
 

Figura 6. Esempio di generalizzazione. Reperimento dati verbale

Per ciò che concerne la relazione di Inclusione si ritiene opportuno evidenziarne brevemente la genesi.
Inizialmente si trattava di uno stereotipo della relazione di Generalizzazione, e pertanto veniva rappresentato per mezzo dello stesso simbolo grafico con affianco l’etichetta “<<uses>>” (nome dello stereotipo). Allo stato attuale le cose sono un po’ cambiate, e l’Inclusione si è (magicamente) trasformata in un prototipo della relazione di dipendenza; pertanto dovrebbe essere rappresentato da una freccia tratteggiata con l’etichetta “<<include>>.
A dir il vero una spiegazione formale esiste: non si può trattare di una relazione di Generalizzazione “semplicemente” perché lo use case “utilizzatore” non può assolutamente essere sostituito al posto dello use case “utilizzato”. Quindi la condizione fondamentale della Generalizzazione viene a mancare!
Per ciò che concerne la rappresentazione grafica della relazione di Inclusione, è da notare che, per esempio, “Rational Rose 98” non permette di collegare tra loro use case per mezzo di relazioni di dipendenza e quindi non permette di rappresentare correttamente questa relazione!
Brevemente, una relazione di Dipendenza (freccia tratteggiata) indica che una modifica all’oggetto “indipendente” (destinatario della freccia) implica la variazione dell’oggetto “dipendente”.

Una relazione di Inclusione indica che lo use case base (l’utilizzatore) incorpora esplicitamente il comportamento di un altro use case (l’utilizzato). In questo tipo di relazione, lo use case utilizzato non può vivere di vita propria ma deve essere necessariamente istanziato come parte di un altro caso d’uso.
Lo use case “utilizzato” ha visione completa del suo utilizzatore con il quale può scambiare parametri e comunicare risultati.
La relazione di Inclusione è molto utile perché evita di dover ripetere più volte uno stesso flusso di sequenza. In particolare, per specificare, nel flusso dello use case utilizzatore, il punto in cui inserire quello dello use case incluso è sufficiente premettere l’identificatore “include” seguito dal nome dello use case. 
Si consideri l’esempio riportato in figura 7. Nella descrizione del flusso degli eventi del caso d’uso “Visualizzazione saldo”, dovrà comparire (verosimilmente molto in alto) l’inclusione dello use case “Validazione utente” e quindi la clausola “include (Validazione utente)”.
 
 

Figura 7. Esempio di use case di uno sportello Bankomat

Una relazione di Estensione tra use case indica che quello di base (l’estensore) incorpora implicitamente il comportamento di un altro use case (l’esteso), in un punto specificato intrinsecamente dalla relazione stessa. La differenza sostanziale tra la relazione di Estensione e quella di Inclusione è che, in questo caso, ha senso che lo use case esteso viva di vita propria, e che sotto determinate condizioni, il suo comportamento venga esteso da un altro use case.
Al fine di evitare di rendere inutilmente complicati i diagrammi dei casi d’uso, non è assolutamente necessario che un use case estenda completamente un altro, o che ne “erediti” tutti gli attributi e le operazioni. È possibile che ciò avvenga parzialmente. E’ sufficiente che nello use case “estensore” siano presenti delle “zone”, in cui il comportamento dell’esteso venga “variato”: tali sezioni vengono dette “punti di estensione”. All’interno di uno use case possono essere presenti diversi “punti di estensione”.
Spesso, le relazioni di estensione sono utilizzate per modellare delle parti di use case, che rappresentano delle azioni facoltative del comportamento del sistema. In questo modo è possibile distinguere il comportamento opzionale da quello obbligatorio.
Altre volte si ricorre alle relazioni di Estensione per modellare separatamente sotto-flussi, che possono essere eseguiti unicamente al verificarsi di specifiche condizioni.
Naturalmente (è appena il caso di ripeterlo…Però potrebbe sempre esserci un programmatore-geologo intento nella lettura!), l’utilizzo principale della relazione di Estensione consiste nel modellare diversi flussi i quali, in funzione di un’esplicita interazione con l’utente, vengono ripetuti in opportuni punti del flusso di eventi di altri use case.
La relazione di Estensione è un ulteriore stereotipo della relazione di dipendenza (non poteva essere altrimenti!). Pertanto viene rappresentata graficamente per mezzo di una freccia tratteggiata corredata dall’etichetta “<<extend>>”.
 
 
 
 

Figura 8. Esempio di relazione di estensione

Come si può osservare dalla figura 8, la funzione di “inserto straordinario fattura” estende il caso d’uso “Inserimento nuova fattura”. Il comportamento aggiuntivo è relativo alla “forzatura” del codice fattura il quale, nel caso d’uso “estensore” non viene prelevato dal sistema bensì viene impostato dall’utente. Altra considerazione da farsi è che la funzione “Insert new invoice” ha motivo di esistere indipendentemente dall'esistenza di relazioni di estensione.
Organizzare use case estraendo il comportamento comune (utilizzo delle relazioni di Inclusione) e distinguendo le varianti  (relazione di Estensione)  è  molto  importante per creare diagrammi semplici, bilanciati e comprensibili… Così come raccomandano i “Tres Amigos”!
 

Relazioni tra casi d’uso ed attori
Un attore può essere connesso con uno use case solo attraverso una relazione di assegnazione. Ciò indica che l’attore e lo use case comunichino tra loro inviando o ricevendo messaggi.
Chiaramente uno stesso attore può fornire diversi stimoli al sistema (avviare vari casi d’uso), così come può fruire informazioni provenienti da diversi use case.
 
 

Individuazione degli elementi degli use case.
Prima di avviare il processo di identificazione dei casi d’uso, conviene aver eseguito l’analogo processo relativo agli attori. Il modo migliore per individuare i casi d’uso consiste nell’interrogarsi sui flussi di dati aventi come oggetto appunto gli attori.
Come prima cosa bisogna stabilire quali funzioni siano richieste al sistema da ogni singolo attore e per quale motivo.
Poi, si può procedere cercando di scoprire se un attore abbia bisogno di manipolare (memorizzare, leggere, aggiornare… ) particolari informazioni del sistema, non fornite dai casi d’uso già identificati.
A questo punto si può passare ad analizzare gli eventi, ed in particolare, si deve verificare che non esistano, da parte degli attori, necessità di notificare eventi al sistema, non ancora analizzate.
L’ultimo quesito da derimere (e qui si alimenta il sentimento dell’ottimizzazione tipico degli ingegneri) è se è possibile semplificare, o rendere più efficiente, il lavoro quotidiano degli utenti, introducendo funzionalità non ancora previste.
Per completare l’opera, è necessario spostare l’attenzione dagli attori al sistema, per verificare se esistano flussi di input/output necessari al sistema e non forniti dall’insieme dei casi d’uso identificati.
 
 

 Verifiche dei casi d’uso.
Verificare una vista use-case significa sostanzialmente eseguire due processi di test: verifica vera e propria e validazione. Il primo processo serve a confermare che la vista sia stata realizzata correttamente ed in accordo alle specifiche raccolte; mentre la validazione deve accertare se il sistema, così come lo si è progettato, sia effettivamente ciò di cui il cliente e gli utenti finali abbiano bisogno.
I processi di validazione dovrebbero essere eseguiti regolarmente, non appena ogni singolo processo è terminato, e nel contesto degli use case, non appena i primi diagrammi siano disponibili. Essi andrebbero sottoposti e discussi con il cliente. Pertanto, implicitamente, sono i clienti e gli utenti finali che eseguono la validazione.
L’obiettivi del processo di validazione è dimostrare che il modello sia corretto, completo, rispondente alle aspettative del sistema,… A tal fine è necessario assicurarsi che i fruitori non tecnici dei diagrammi siano effettivamente in grado di comprenderli. 
Da tener presente che, in generale, l’obiettivo delle verifiche non dovrebbe essere solo quello di assicurare che tutto funzioni correttamente e sia rispondente, bensì dovrebbe consistere nel individuare eventuali incongruenze ed  errori. Un buon processo di verifica dovrebbe evidenziare problemi: meglio iterare più volte la progettazione di uno use case che ridursi a correre ai ripari a progetto ultimato!
 
 
 

Metodologia “Walking the use case”.
Una tecnica di validazione dei use case diagram molto utilizzata negli U.S.A. (non poteva essere altrimenti!) è quella che prende il nome di “Walking the use case”. Si tratta di un gioco di ruolo, da “praticare” in gruppo (gli americani fanno tutto o quasi in gruppo!), in cui diverse persone recitano il ruolo degli attori presenti dei diagrammi d’uso! 
La loro esperienza li rende in grado anche di recitare il ruolo di attori non umani, come:  sensori, radar, missili… Tale tecnica viene presa così seriamente che, durante la simulazione di un sistema si parla con voce metallica!
Il gioco comincia con gli “partecipanti” che studiano le loro parti, e quindi sottopongono al sistema gli stimoli previsti dall’attore che stanno impersonando. Gli sviluppatori non prendono parte attiva del gioco, essi ne sono gli arbitri. Armati di blocchetti, pardon di portatili, prendono nota di ciò che accade e cercano di individuare le deficienze… Quelle del sistema ovviamente!
Attraverso l’utilizzo di questa tecnica, tipicamente, si evidenzia che talune alternative non sono sufficientemente dettagliate, che taluni stimoli risultano lacunosi, ecc.
 
 

Possibili anomalie degli use case

• Eccessiva scomposizione

 

 

Molti progettisti approdano all’UML dopo aver maturato esperienza e successi con la metodologia di analisi, nota con il nome di “analisi strutturata”, e pertanto tendono a riadattare al nuovo formalismo gli ormai consolidati schemi mentali. Ciò però, non genera sempre buoni risultati. Spesso il vecchio modo di operare porta ad organizzare gli use case come si faceva con i DFD: si realizza un primo use case molto generale, poi si produce tutta una serie di diagrammi che aumentano il dettagliano delle singole funzioni. Si prosegue fino a giungere ad use case abbastanza elementari o addirittura “atomici”. Ciò, a dir il vero, non è uno stile prettamente O.O., e tende a causare alcuni inconvenienti. In primo luogo si corre il rischio di far somigliare gli use case all’organizzazione del codice. Pertanto, la scomposizione funzionale porta a ragionare in termini di eccessivo dettaglio, dimenticando che non c’è alcun bisogno che la struttura interna (il disegno) del sistema assomigli a quella esterna. Si pecca di mancata astrazione, ci si lega immediatamente al “come” realizzare le funzioni! Altri problemi possono essere legati al tempo che si perde per realizzare i vari diagrammi.  Scomponendo ogni singolo use case, ottimizzandolo, conferendogli un opportuno aspetto grafico e così via, si utilizza tempo preziose che potrebbe essere sfruttato proficuamente per le altre attività. Nelle fasi iniziali è più importante analizzare i rischi più elevati, demandando i dettagli alle fasi successive.

• Mancanza di astrazione

 

 

Spesso, nel tentativo di analizzare un sistema molto complesso, al fine di circoscrivere il fattore di rischio, si tenta di procedere per prototipi successivi. Tale approccio, che correttamente applicato può dare i suoi buoni frutti, (a patto che i prototipi non diventino magicamente versioni definitive) talune volte può generare diversi problemi. L’idea alla base è molto semplice: poiché esistono validi strumenti per realizzare in breve tempo una serie di interfacce utente, è possibile pensare di costruire un primissimo prototipo basato sulle sole schermate di interazione utente/applicativo. Si tratta di un vero e prototipo “usa e getta”, da utilizzare al solo scopo di catturare i requisiti del cliente. Pertanto lo use case viene realizzato in base al prototipo e alle osservazioni scaturite dai colloqui con il cliente. I vantaggi derivanti da tale approccio sono che si porta il cliente a ragionare su qualcosa di concreto, si riesce ad isolarsi dai dettagli e si fornisce una proiezione di come sarà il sistema.Gli svantaggi possono essere diversi. In primo luogo si rischia di ingenerare nel cliente l’idea che il sistema sia ormai pressoché pronto, e che quindi, la relativa progettazione sia giunta alle fasi finali. Mentre invece manca ancora tutto! A quel punto non c’è nulla da fare: tutti i tentativi di convincere il cliente del contrario tendono a cadere nel vuoto! Un altro inconveniente è che si rischia di legarsi troppo al prototipo, di non analizzare aspetti ritenuti di secondaria importanza, e di sottostimare i tempi. Un’idea potrebbe essere quella di presentare un “prototipo” composto di soli disegni, magari realizzati per mezzo di carta e penna, o documento elettronico! Resta comunque forte il timore che, anche in questo caso, si possano trovare commerciali in grado di trasformarlo magicamente, nel giro di pochi secondi, in prodotto finito!
 

• Eccessiva astrazione

 

 

Tutti coloro che operano nel settore dell’Object Oriented in maniera seria, prima o poi, tendono a diventare adepti della “setta dell’astrazione”: ogni cosa può essere “astratta” (anche i famigliari)! Operare secondo tali schemi mentali è più che positivo, però va tenuto presente che l’eccessiva astrazione dei casi d’uso può generare non pochi problemi. Non va mai dimenticato che i principali fruitori della use case view sono i clienti, e pertanto, uno degli obiettivi fondamentali della vista è appunto facilitare lo scambio informativo tra cliente e team di analisti: non a caso si utilizzano gli scarabbocchietti! Da tener presente che i clienti, molto raramente, si trovano a loro agio quando il discorso si eleva sul piano dell’astratto. Ciò può generare anche inutili perdite di tempo nel tentativo di illustrare, spiegare e argomentare, le varie astrazioni. Pertanto, astrarre i diagrammi più di quanto sia effettivamente necessario potrebbe confondere inutilmente il cliente e, in ultima analisi, limitare o addirittura inibire, l’instaurazione di un dialogo costruttivo. La parola d’ordine per gli use case è sicuramente la concretezza: la mancanza di astrazione a questo livello non incide minimamente sul livello di astrazione delle restanti viste!

Conclusioni
In questo articolo è stata illustrata, per quanto possibile, la prima vista dello Unified Modeling Language, la use case view, calandola nel contesto di pertinenza: l’analisi dei requisiti.
Sebbene le problematiche connesse con questa fase del ciclo di vita del software siano ben note a tutti, e alquanto riconducibili alla difficoltà di instaurare una corretta piattaforma di dialogo con il cliente, sembrerebbe (con particolare riferimento alla cronaca recente) che si continuino a commettere gli stessi errori…“Errare humanum est, perseverare diabolicum est!”
La trattazione è stata imperniata sull’illustrazione degli use case diagram e su come essi siano utilizzati per descrivere i requisiti funzionali di un sistema. Tali diagrammi sono descritti in termini di attori, use case e relazioni tra tali elementi.
Un attore è un’entità esterna al sistema e rappresenta un insieme coerente di ruoli che l’attore recita quando interagisce con i casi d’uso del sistema. Esso può essere sia un operatore umano, sia un sistema.
Un caso d’uso specifica il comportamento di un sistema (sottosistema o parte di esso) fornendo la descrizione di un insieme di sequenze di azioni, corredate dalle relative varianti, che il sistema esegue per produrre un risultato osservabile per un attore.
Durante la trattazione, laddove possibile, si è sono evidenziate sia le differenze tra le diverse versioni dello Unified Modeling Language, sia tra questa metodologia di analisi e le precedenti, illustrando gli errori che comunemente si compiono utilizzando lo UML 
Si vuole ricordare (per l’ennesima volta) che in questa fase del ciclo di vita del Software è necessario concentrarsi su cosa il sistema deve fare e non sul come!
A conclusione si può affermare che la use case view, con i relativi diagrammi, rappresenta un ottimo strumento, estremamente versatile, semplice da comprendere per affrontare il processo dell’analisi dei requisiti.
Come al solito, le difficoltà che si possono incontrare non sono tanto imputabili al modello, quanto alla complessità oggettiva ed intrinseca del processo di analisi dei requisiti. Sfortunatamente, sapere disegnare correttamente un modello non significa essere buoni analisti!
 

Bibliografia

• [1] The Unified Modeling Language User Guide Grady Booch, James Rumbaugh, Ivar Jacobson Addison Wesley 

 

 

Questo libro vanta il primato di essere stato scritto dai progettisti originali del linguaggio, sebbene sia conosciuto come “Grady’s book”, dal nome del suo primo autore. La mancanza di una sua copia (magari autografata!) può generare giudizi di scarsa professionalità per coloro che operano nel settore della progettazione O.O... Ciò però, costituisce una condizione necessaria, ma non sufficiente, in quanto bisogna, assolutamente, aggiungere una copia del [3] e una del [4]. Sono soldi spesi bene! Forse, il limite del libro, se proprio se ne vuole trovare uno, è quello di essere poco accessibile ad un pubblico non espertissimo di progettazione O.O. Un altro piccolo inconveniente è che, probabilmente, taluni esempi possano sembrare di carattere accademico: poco rispondenti alle problematiche del mondo reale.
 

• [2] UML Toolkit Hans-Erik Eriksson, Magnus Penker Wiley

 

 

Questo libro si fa particolarmente apprezzare per via del taglio pratico dello stesso. Illustra in modo semplice il linguaggio, attraverso numerosi esempi, limitando le digressioni di carattere teorico. Si suppone infatti, che coloro che si occupano di progettazione O.O. abbiano una certa familiarità con i relativi concetti. Chissà perché si ha la sensazione che non sia sempre così! Naturalmente, studiare libri che illustrano gli aspetti teorici dell’informatica, è sempre qualcosa più che auspicabile. È altresì vero però, che coloro che non hanno tempo da perdere, per la lettura di concetti arcinoti, gradiscono arrivare rapidamente al nocciolo. Ciò spesso equivale a strappare alle nottate lavorative ore preziose per il sonno.
 

• [3] The Unified Modeling Language Reference Manual Grady Booch, James Rumbaugh, Ivar Jacobson Addison Wesley

 

 

Il commento da riportare per questo libro, noto per come “Rumbaugh’s book”, è sostanzialmente equivalente a quanto riportato per il primo. Esso però offre un livello di difficoltà decisamente inferiore, e pertanto dovrebbe essere più accessibile. Come suggerisce il nome, si tratta di un manuale, per cui ne rispetta la tipica struttura.
 

• [4] Design Patterns: Elements of Reusable Object-Oriented Software Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Grady Booch Addison Wesley.

 

 

Si tratta di un ottimo libro che bisogna assolutamente avere se si vuole lavorare nell’ambito della progettazione O.O. . I “pattern” riportati, forniscono un ottimo ausilio al processo di disegno del software. L’utilizzo del libro contribuisce ad aumentare la produttività, fornisce soluzioni chiare, efficienti e molto eleganti. La fase di disegno del software, spesso, si riduce ad individuare e personalizzare i “pattern” che risolvono la problematica specifica. Si è di fronte ad una nuova frontiera della progettazione O.O.: il riutilizzo di parti del progetto. L’unica pecca imputabile, è che i vari diagrammi non sempre rispettano il formalismo UML
 

• [5] www.omg.org 

 

 

Si tratta del sito ufficiale del Object Managment Group.
 

• [6] www.mokabyte.it Numero 34 (Ottobre 1999) UML e lo sviluppo del software.

Luca Vetti Tagliati è raggiungibile all’indirizzo di e-mail : Luca.VT@usa.net