Continuiamo adesso la realizzazione del nostro progetto. Abbiamo gestito il caso in cui l’utente acquisti il prodotto e non sia registrato, adesso bisogna gestire il caso in cui l’utente, già registrato, effettua il login e il nostro sistema verifica username e password inserite. Potremo inserire il controllo delle credenziali direttamente all’interno del caso d’uso acquisto prodotto, ma la verifica delle credenziali è necessaria anche per il caso d’uso visualizza stato dell’ordine e per i casi d’uso relativi all’admin del sito. Dunque la soluzione più corretta e per così dire, più ingegneristica, è quella di definire un caso d’uso verifica username e password per poi effettuare un’inclusione in tutti i casi d’uso che lo richiedono. In UML avremo:
Per quanto riguardo il caso d’uso acquisto prodotto sarebbe possibile estenderlo per fornire una ricevuta del pagamento all’utente come abbiamo fatto nell’esercizio dello sportello del bancomat. Semplicemente verranno definiti due punti di estensioni diversi, per i due casi d’uso, all’interno del flusso del caso d’uso principale. Per quanto riguarda l’ultimo caso d’uso relativo all’attore cliente definiamo visualizza stato dell’ordine che includerà il caso d’uso verifica username e passoword per garantire un login corretto al sito.
Abbiamo dunque terminato la modellazione del diagramma dei casi d’uso per quanto riguarda l’attore cliente. Adesso vediamo i casi d’uso relativi agli attori:addetto alle spedizioni e admin. Per come è stato descritto il problema i due attori non hanno operazioni in comuni e si potrebbe identificarli come due entità a se stanti. Ma visto che entrambi sono dei dipendenti del sito di e-commerce e in un futuro potrebbero compiere alcune operazioni in comune è più opportuno creare un attore dipendente e poi effettuare una specializzazione per quanto riguarda l’admin e l’ addetto spedizioni. Per quanto riguarda quest’ultimo, l’operazione di spedizione può essere identificata da un semplice caso d’uso spedizione, mentre per quanto riguarda l’operazione di aggiornamento dello stato dell’ordine è opportuno creare un caso d’uso aggiornamento stato ordine che include però il caso d’uso relativo alla verifica delle credenziali. In UML il diagramma è il seguente:
Per quanto riguarda l’attore admin vediamo che le operazioni che compie richiedono tutte la verifica delle credenziali. Un primo approccio al problema potrebbe essere quello di identificare ogni operazione con un caso d’uso ed in ogni caso d’uso includere la verifica delle credenziali. Seppur questo approccio sia perfettamente corretto ha il grandissimo difetto di appesantire, dal punto di vista visivo, il diagramma che andremo ad analizzare e se ipotizziamo che l’admin possa eseguire un numero elevato di operazioni la progettazione, così come è stata proposta, non è attuabile. La soluzione migliore è quella di inserire un caso d’uso relativo all’accesso al pannello di amministrazione nel quale includeremo la verifica delle credenziali. A questo punto estenderemo questo caso d’uso nelle operazioni descritte nel testo del problema. In questa maniera, includiamo una sola volta la verifica delle credenziali, e potremo estendere il caso d’uso tante volte quante saranno le operazioni che l’admin può compiere. Dunque, a questo punto, mostriamo la visione d’insieme dei casi d’uso relativo all’attore cliente:
E questo è il diagramma relativo all’attore dipendente:
Il caso d’uso relativo alla verifica delle credenziali è identico per entrambi i diagrammi e quest’ultimi sono stati scissi per esigenza di formattazione. Come si può notare dunque, la modellazzione dei diagrammi dei casi d’uso, permette una buona libertà d’azione e dunque è possibile progettare il tutto come meglio si crede. E’ una buona norma progettare il diagramma in ottica di estensioni future del sistema (nel nostro caso la specializzazione dall’attore dipendente) per rendere il processo di modifica e di integrazione di altri moduli il più semplice possibile.
