Le relazioni nei diagrammi dei casi d’uso sono in numero nettamente inferiore rispetto ai diagrammi delle classi. Per quanto riguarda le relazioni esistenti tra gli attori, l’unica ammessa è la generalizzazione/specializzazione. Il concetto di questa relazione è identico a quello espresso nei diagrammi delle classi infatti la specializzazione di un attore è una sorta di qualificazione più specifica dell’attore stesso. E’ possibile anche avere una relazione di generalizzazione/specializzazione tra casi d’uso ed in questo caso il caso d’uso derivato risulterà più specifico e descrittivo. Facciamo adesso un esempio in UML di generalizzazione/specializzazione tra attori e casi d’uso:
Esistono altre due relazioni, applicabili solo ai casi d’uso, che sono l’inclusione e l’estensione.
Inclusione
Per quanto riguarda l’inclusione si tratta di includere qualche cosa all’interno di un caso d’uso. Un po’ come avviene quando programmate e includete all’interno del vostro pragramma una libreria o una classe. Quel qualche cosa che viene incluso in un caso d’uso è un’altro caso d’uso che svolge qualche operazione necessaria affinchè l’esecuzione del caso d’uso includente venga eseguita in maniera corretta. In UML l’inclusione viene rappresentata con una linea tratteggiata con una freccia ad una estremità che punta al caso d’uso che vogliamo includere e sopra la linea tratteggiata è presente lo stereotipo include. Facciamo adesso un esempio pratico dell’uso di una inclusione. Riallacciandosi all’esempio dello sportello bancomat nel quale è possibile sia ritirare denaro che stampare il saldo possiamo dire che entramebe le operazioni possono essere eseguite solo se il PIN inserito è corretto. A questo punto non avrebbe senso descrivere, in ambo le operazioni, il processo di verifica del PIN e dunque basterà definire il caso d’uso verifica PIN ed includerlo nei casi d’uso relativi al prelievo di contanti e la stampa del saldo. In UML avremo il diagrama seguente:
La progettazione del sistema seguendo questa logica di modularità è molto importante per la robustezza e la manutenzione del codice. Infatti se per esempio si cambiasse il meccanismo della verifica del PIN, in questa maniera dovremo solo andare a modificare il caso d’uso relativo, viceversa avremo dovuto modificare tutti i casi d’uso che al loro interno avevano la verifica del PIN della carta. Dunque è buona norma, per le operazioni di base, presenti in molti casi d’uso, di creare un caso d’uso a parte e poi includerlo quando necessario.
Estensione
L’ultima relazione che andremo a vedere è l’estensioe di un caso d’uso. Anche questo tipo di relazione è molto utilizzata perchè, come dice la parola stessa, permette di estendere il comportamento di un caso d’uso base con un altro caso d’uso. Il caso d’uso che viene esteso rimane comunque perfettamente funzionante anche senza l’estensione e semplicemente nel flusso delle operazioni si definiscono dei punti di estensione ai quali il caso d’uso di estensione si aggancia. Quando, nel flusso dell’operazione, si arriva a questi punti di estensione e si verifica una certa condizione il caso d’uso d’estensione viene eseguito, altrimenti no. Dunque l’estensione non è altro un comportamento opzionale che ha il caso d’uso che viene esteso. Per continuare sull’esempio dello sportello bancomat immaginiamo di dover prelevare dei contanti. Dopo aver selezionato l’importo il terminale richiede se si vuole o meno stampare la ricevuta e se l’utente accetta la ricevuta viene stempata. Di fatto il caso d’uso preleva contanti viene esteso con il caso d’uso stampa ricevuta se il cliente risponde in maniera affermativa alla richiesta della stampa. In UML l’estensione viene rappresentata come una linea tratteggiata con una freccia ad una estremità in direzione del caso d’uso che è soggetto all’estensione e sopra la linea tratteggiata è presente lo stereotipo extend. Vediamo in UML il diagramma dei casi d’uso dello scenario sopra descritto:
