Lo use case diagram, in italiano diagramma dei casi d’uso, fa parte dei diagrammi com­por­ta­men­ta­li dell’Unified Modelling Language, in breve UML, con cui vengono rap­pre­sen­ta­ti sistemi e processi della pro­gram­ma­zio­ne orientata agli oggetti o i processi aziendali. L’UML quindi non è un lin­guag­gio di pro­gram­ma­zio­ne, bensì di mo­del­la­zio­ne. Si tratta di un metodo stan­dar­diz­za­to che descrive un sistema pia­ni­fi­ca­to o già esistente mediante diagrammi in cui tutti gli oggetti inclusi sono strut­tu­ra­ti e messi in relazione tra di loro.

Registra il tuo dominio
  • Domain Connect gratuito per una con­fi­gu­ra­zio­ne facile del DNS
  • Cer­ti­fi­ca­to SSL Wildcard gratuito
  • Pro­te­zio­ne privacy inclusa

Use case diagram: uno dei tanti diagrammi UML

Dato che rap­pre­sen­ta­re tutti gli oggetti, le relazioni e le procedure in un unico diagramma sarebbe troppo complesso e poco com­pren­si­bi­le, vengono uti­liz­za­ti 14 tipi di diagramma nell’UML. Si possono sud­di­vi­de­re in diagrammi strut­tu­ra­li, diagrammi com­por­ta­men­ta­li e diagrammi d’in­te­ra­zio­ne, anche se questi ultimi sono un sot­to­grup­po dei diagrammi com­por­ta­men­ta­li.

Nel caso dei diagrammi strut­tu­ra­li il focus è in­cen­tra­to sulla rap­pre­sen­ta­zio­ne di tutti gli elementi di un sistema e sulle relazioni che questi hanno tra di loro. Un tipico esempio è il diagramma di classe, dove gli elementi vengono rag­grup­pa­ti e vi­sua­liz­za­ti in maniera ge­rar­chi­ca. I diagrammi com­por­ta­men­ta­li invece non si occupano di strutture ge­rar­chi­che, bensì mostrano lo svol­gi­men­to pia­ni­fi­ca­to o reale dei processi, come lo si attende dall’uso del programma o del software. In questi diagrammi quindi è l’elemento dinamico a essere in evidenza.

Il diagramma dei casi d’uso in questo gruppo è un caso straor­di­na­rio, perché rap­pre­sen­ta il com­por­ta­men­to che ci si attende da un sistema o da un software in un de­ter­mi­na­to caso d’uso. A dif­fe­ren­za degli altri diagrammi com­por­ta­men­ta­li in UML, il diagramma dei casi d’uso è piuttosto statico, perché consente di de­scri­ve­re solo azione e obiettivo e non la sequenza esatta delle varie procedure e fun­zio­na­men­ti. A tal fine in UML vengono uti­liz­za­ti altri tipi di diagrammi, per esempio diagrammi di attività per la rap­pre­sen­ta­zio­ne cro­no­lo­gi­ca delle procedure o diagrammi se­quen­zia­li per lo scambio di messaggi tra vari elementi di un sistema.

Il diagramma dei casi d’uso nella pratica

Con un diagramma dei casi d’uso vengono rap­pre­sen­ta­te le funzioni di un sistema dal punto di vista dell’uti­liz­za­to­re (chiamato in UML “attore”). Questo attore non deve per forza essere un utente umano; tale ruolo può anche essere at­tri­bui­to a un sistema esterno che ha accesso ad un altro sistema. Il diagramma dei casi d’uso rap­pre­sen­ta la relazione tra un attore e le sue richieste o aspet­ta­ti­ve rispetto al sistema, senza de­scri­ve­re le azioni in corso di svol­gi­men­to o metterle in una sequenza logica.

Questa struttura nella pratica è adatta a rap­pre­sen­ta­re le funzioni prin­ci­pa­li e/o gli obiettivi di un sistema in maniera chiara. Per questo motivo, nello sviluppo dei software o nella pia­ni­fi­ca­zio­ne di nuovi processi aziendali, spesso uno dei primi passi è quello di creare un diagramma dei casi d’uso. Esso infatti evidenzia in maniera semplice e chiara quali casi d’uso debbano essere tenuti in con­si­de­ra­zio­ne nello sviluppo, di modo che gli attori (e in senso più ampio anche i gestori o com­mit­ten­ti) rag­giun­ga­no il proprio obiettivo senza dover con­si­de­ra­re ini­zial­men­te la fat­ti­bi­li­tà dal punto di vista tecnico.

Com­po­nen­ti e struttura del diagramma dei casi d’uso

Al fine di rendere chiaro a colpo d’occhio lo use case diagram, vengono uti­liz­za­te com­po­nen­ti stan­dar­diz­za­te per la rap­pre­sen­ta­zio­ne. Ci sono tre elementi es­sen­zia­li:

  • Attore: gli attori, che si tratti di persone o di sistemi, vengono rap­pre­sen­ta­ti da un’icona che rap­pre­sen­ta degli uomini sti­liz­za­ti.
  • Sistema: il sistema a cui fa ri­fe­ri­men­to lo use case viene rap­pre­sen­ta­to come un ret­tan­go­lo.
  • Use case: il reale caso d’uso viene rap­pre­sen­ta­to come un’ellisse, che contiene so­li­ta­men­te il nome del caso d’uso.

Le relazioni tra questi elementi vengono appunto descritte con linee di col­le­ga­men­to, le co­sid­det­te as­so­cia­zio­ni. Una linea tracciata tra attore e use case rende chiaro che l’attore e il caso d’uso descritto nell’ellisse sono in relazione tra di loro. Per la relazione tra diversi casi d’uso si uti­liz­za­no le righe trat­teg­gia­te. Visto che ci sono diversi tipi di as­so­cia­zio­ni tra casi d’uso, le linee vengono com­ple­ta­te tramite una parola chiave che in UML viene chiamata “ste­reo­ti­po” e viene rap­pre­sen­ta­ta tra doppie parentesi angolate. La punta della freccia indica inoltre la di­pen­den­za tra use case. Si distingue tra due ste­reo­ti­pi:

  • As­so­cia­zio­ne include: lo use case da cui parte la linea di col­le­ga­men­to trat­teg­gia­ta include un secondo use case, indicato dalla punta della freccia.
  • As­so­cia­zio­ne extend: lo use case da cui parte la linea di col­le­ga­men­to trat­teg­gia­ta può, se sono sod­di­sfat­ti alcuni pre­sup­po­sti, ampliare lo use case indicato dalla punta della freccia. Non è però ob­bli­ga­to­rio.

Mentre l’as­so­cia­zio­ne include ha come pre­sup­po­sto l’ese­cu­zio­ne di entrambi gli use case, l’ese­cu­zio­ne del secondo use case dipende da de­ter­mi­na­te con­di­zio­ni nell’as­so­cia­zio­ne extend. Queste con­di­zio­ni vengono indicate nel diagramma di casi d’uso UML come punto di esten­sio­ne o extension point. Ciò viene vi­sua­liz­za­to in due modi:

  • Com­ple­ta­men­to dell’ellisse del caso d’uso: sotto il nome del caso d’uso viene nominato e descritto in breve il possibile extension point.
  • Foglio appunti: lo ste­reo­ti­po extend viene collegato tramite linea trat­teg­gia­ta ad un foglio appunti sti­liz­za­to (ret­tan­go­lo con un angolo piegato) con le etichette “condition” e “extension”. Nella condition viene definita, tra parentesi graffe, qual è la con­di­zio­ne che deve essere sod­di­sfat­ta perché possa essere rea­liz­za­to il secondo use case. Nell’extension point si fa ri­fe­ri­men­to al suo nome nell’ellisse del caso d’uso, di modo che l’esten­sio­ne venga at­tri­bui­ta in maniera univoca.

Ora conoscete tutte le com­po­nen­ti di cui avete bisogno per creare un vostro diagramma use case.

Un esempio di diagramma dei casi d’uso

Fino a qui avete ricevuto molte in­for­ma­zio­ni di tipo teorico. Per avere un’idea più chiara dell’at­tua­zio­ne pratica vi mostriamo di seguito la creazione di un diagramma dei casi d’uso facendo l’esempio di un cliente di una banca che vuole prelevare denaro da un di­stri­bu­to­re au­to­ma­ti­co.

N.B.

Nella pratica as­si­cu­ra­te­vi sempre che il vostro diagramma dei casi d’uso non sia troppo confuso. Ciò può accadere molto fa­cil­men­te se rap­pre­sen­ta­te mol­te­pli­ci casi in un unico diagramma che sono tra le altre cose collegati con as­so­cia­zio­ni <<include>> ed <<extend>>. In caso di dubbio è meglio creare un singolo diagramma dei casi d’uso per ciascun use case.

Qui il di­stri­bu­to­re au­to­ma­ti­co è il sistema e il cliente della banca l’attore che vuole ef­fet­tua­re lo use case “prelevare denaro”. Ciò è collegato con un’as­so­cia­zio­ne include ad altri due use case ossia “au­ten­ti­ca­zio­ne” e “controllo PIN e conti”. Se l’au­ten­ti­ca­zio­ne non ha successo, la richiesta del cliente non può essere sod­di­sfat­ta. Per fare in modo che i tentativi del cliente non con­ti­nui­no all’infinito, la carta deve essere ritirata se il PIN viene inserito in maniera errata per tre volte. Per il caso d’uso “au­ten­ti­ca­zio­ne” viene quindi stabilito un extension point con la con­di­zio­ne “PIN errato tre volte”. Se viene sod­di­sfat­ta questa con­di­zio­ne, entra in azione lo use case “ritiro carta”, collegata tramite as­so­cia­zio­ne extend allo use case “au­ten­ti­ca­zio­ne”. Il diagramma use case di questo esempio viene rap­pre­sen­ta­to come segue:

Vai al menu prin­ci­pa­le