Lo use case diagram (diagramma dei casi d’uso) in UML

Lo use case diagram, in italiano diagramma dei casi d’uso, fa parte dei diagrammi comportamentali dell’Unified Modelling Language, in breve UML, con cui vengono rappresentati sistemi e processi della programmazione orientata agli oggetti o i processi aziendali. L’UML quindi non è un linguaggio di programmazione, bensì di modellazione. Si tratta di un metodo standardizzato che descrive un sistema pianificato o già esistente mediante diagrammi in cui tutti gli oggetti inclusi sono strutturati e messi in relazione tra di loro.

Registrazione dominio

Più di un semplice nome.

Registra il tuo dominio con IONOS e approfitta di tutte le nostre funzionalità.

E-Mail
SSL Wildcard
Supporto 24/7

Use case diagram: uno dei tanti diagrammi UML

Dato che rappresentare tutti gli oggetti, le relazioni e le procedure in un unico diagramma sarebbe troppo complesso e poco comprensibile, vengono utilizzati 14 tipi di diagramma nell’UML. Si possono suddividere in diagrammi strutturali, diagrammi comportamentali e diagrammi d’interazione, anche se questi ultimi sono un sottogruppo dei diagrammi comportamentali.

Nel caso dei diagrammi strutturali il focus è incentrato sulla rappresentazione 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 raggruppati e visualizzati in maniera gerarchica. I diagrammi comportamentali invece non si occupano di strutture gerarchiche, bensì mostrano lo svolgimento pianificato 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 straordinario, perché rappresenta il comportamento che ci si attende da un sistema o da un software in un determinato caso d’uso. A differenza degli altri diagrammi comportamentali in UML, il diagramma dei casi d’uso è piuttosto statico, perché consente di descrivere solo azione e obiettivo e non la sequenza esatta delle varie procedure e funzionamenti. A tal fine in UML vengono utilizzati altri tipi di diagrammi, per esempio diagrammi di attività per la rappresentazione cronologica delle procedure o diagrammi sequenziali 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 rappresentate le funzioni di un sistema dal punto di vista dell’utilizzatore (chiamato in UML “attore”). Questo attore non deve per forza essere un utente umano; tale ruolo può anche essere attribuito a un sistema esterno che ha accesso ad un altro sistema. Il diagramma dei casi d’uso rappresenta la relazione tra un attore e le sue richieste o aspettative rispetto al sistema, senza descrivere le azioni in corso di svolgimento o metterle in una sequenza logica.

Questa struttura nella pratica è adatta a rappresentare le funzioni principali e/o gli obiettivi di un sistema in maniera chiara. Per questo motivo, nello sviluppo dei software o nella pianificazione 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 considerazione nello sviluppo, di modo che gli attori (e in senso più ampio anche i gestori o committenti) raggiungano il proprio obiettivo senza dover considerare inizialmente la fattibilità dal punto di vista tecnico.

Componenti e struttura del diagramma dei casi d’uso

Al fine di rendere chiaro a colpo d’occhio lo use case diagram, vengono utilizzate componenti standardizzate per la rappresentazione. Ci sono tre elementi essenziali:

  • Attore: gli attori, che si tratti di persone o di sistemi, vengono rappresentati da un’icona che rappresenta degli uomini stilizzati.
  • Sistema: il sistema a cui fa riferimento lo use case viene rappresentato come un rettangolo.
  • Use case: il reale caso d’uso viene rappresentato come un’ellisse, che contiene solitamente il nome del caso d’uso.

Le relazioni tra questi elementi vengono appunto descritte con linee di collegamento, le cosiddette associazioni. 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 utilizzano le righe tratteggiate. Visto che ci sono diversi tipi di associazioni tra casi d’uso, le linee vengono completate tramite una parola chiave che in UML viene chiamata “stereotipo” e viene rappresentata tra doppie parentesi angolate. La punta della freccia indica inoltre la dipendenza tra use case. Si distingue tra due stereotipi:

  • Associazione include: lo use case da cui parte la linea di collegamento tratteggiata include un secondo use case, indicato dalla punta della freccia.
  • Associazione extend: lo use case da cui parte la linea di collegamento tratteggiata può, se sono soddisfatti alcuni presupposti, ampliare lo use case indicato dalla punta della freccia. Non è però obbligatorio.

Mentre l’associazione include ha come presupposto l’esecuzione di entrambi gli use case, l’esecuzione del secondo use case dipende da determinate condizioni nell’associazione extend. Queste condizioni vengono indicate nel diagramma di casi d’uso UML come punto di estensione o extension point. Ciò viene visualizzato in due modi:

  • Completamento 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 stereotipo extend viene collegato tramite linea tratteggiata ad un foglio appunti stilizzato (rettangolo con un angolo piegato) con le etichette “condition” e “extension”. Nella condition viene definita, tra parentesi graffe, qual è la condizione che deve essere soddisfatta perché possa essere realizzato il secondo use case. Nell’extension point si fa riferimento al suo nome nell’ellisse del caso d’uso, di modo che l’estensione venga attribuita in maniera univoca.

Ora conoscete tutte le componenti 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 informazioni di tipo teorico. Per avere un’idea più chiara dell’attuazione 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 distributore automatico.

N.B.

Nella pratica assicuratevi sempre che il vostro diagramma dei casi d’uso non sia troppo confuso. Ciò può accadere molto facilmente se rappresentate molteplici casi in un unico diagramma che sono tra le altre cose collegati con associazioni <<include>> ed <<extend>>. In caso di dubbio è meglio creare un singolo diagramma dei casi d’uso per ciascun use case.

Qui il distributore automatico è il sistema e il cliente della banca l’attore che vuole effettuare lo use case “prelevare denaro”. Ciò è collegato con un’associazione include ad altri due use case ossia “autenticazione” e “controllo PIN e conti”. Se l’autenticazione non ha successo, la richiesta del cliente non può essere soddisfatta. Per fare in modo che i tentativi del cliente non continuino all’infinito, la carta deve essere ritirata se il PIN viene inserito in maniera errata per tre volte. Per il caso d’uso “autenticazione” viene quindi stabilito un extension point con la condizione “PIN errato tre volte”. Se viene soddisfatta questa condizione, entra in azione lo use case “ritiro carta”, collegata tramite associazione extend allo use case “autenticazione”. Il diagramma use case di questo esempio viene rappresentato come segue:

Per offrirti una migliore esperienza di navigazione online questo sito web usa dei cookie, propri e di terze parti. Continuando a navigare sul sito acconsenti all’utilizzo dei cookie. Scopri di più sull’uso dei cookie e sulla possibilità di modificarne le impostazioni o negare il consenso.