Mostriamo adesso un esempio pratico e ragionato per la modellazzione di diagrammi dei casi d’uso in uno scenario un po’ più ampio utilizzando tutte e tre le relazioni che abbiamo presentato nel capitolo precedente. Facendo un paragone con i diagrammi delle classi: questi diagrammi rispettano la struttura del nostro progetto e perciò la modellazzione non presenta molte libertà e quindi modellazzioni effettuate da persone diverse potranno avere solo delle leggere differenze. I diagrammi dei casi d’uso invece hanno un grado di libertà altissimo in quanto non viene specificato quante operazioni devono essere inserite all’interno di un caso d’uso e quindi un diagramma effettuato da persone diverse potranno essere molto diversi. Per quanto riguarda il frazionamento dei casi d’uso non esiste una regola vera e propria, ma si tende a raggiungere un grado di frazionamento adeguato per una lettura semplice del diagramma. Vediamo adesso il diagramma dei casi d’uso che si vuole eseguire.
Si vuole descrivere il processo di acquisto su un sito e-commerce e la relativa gestione. Il navigatore sfoglia il catalogo dei prodotti on-line, selezionando quello desiderato. Al momento del pagamento, se l’utente è già registrato, viene richiesto di effettuare il login e dopo i dati relativi alla carta di credito. Se non è registrato l’utente si deve registrare. Una volta pagato, l’ordine viene generato e l’addetto alle spedizione spedisce l’oggetto e aggiorna lo stato dell’acquisto effettuato dal cliente. L’admin del sito invece si occupa dell’aggiornamento del catalogo e quindi ha la possibilità di modificare prodotti, aggiungerli e rimuoverli dal catalogo. Il cliente in ogni momento può vedere lo stato dei suoi acquisti effettuando il login al sito.
Come nel caso dei diagrammi delle classi è importante leggere il testo con attenzione ed analizzare passo passo le funzionalità richieste. I diagrammi dei casi d’uso sono più semplici da realizzare in quanto l’individuazione degli attori è banale e l’identificazione dei casi d’uso sono legati alle azioni compiute dall’attore e spesso anche alle parole può, deve, deve avere la possibilità di, etc. etc. Iniziando l’analisi del problema è facile individuare il primo attore: il cliente. Dunque le operazioni che il cliente compie sono: lettura del catalogo, selezione prodotto, pagamento e la possibilità di guardare lo stato degli ordini. Per iniziare creeremo un caso d’uso relativo alla selezione prodotto che includerà un’altro caso d’uso ovvero la gestione della lettura del catalogo. Per esempio quest’ultimo caso d’uso gestirà l’animazione, magari in flash, che simula una pagina sfogliata ad ogni click del mouse dell’utente. Il diagramma risultante sarà il seguente:
Il cliente poi potrà acquistare il prodotto che ha inserito precedentemente nel carrello della spesa. Ragioniamo un attimo su questo caso d’uso che risulta il più complesso da gestire: nel caso in cui l’utente sia registrato, prima del pagamento, viene richiesto il login mentre nel caso in cui l’utente non sia registrato viene richiesta la registrazione. Iniziamo modellando il secondo scenario, relativo alla mancata registrazione dell’utente. In questo caso il caso d’uso acquisto prodotto avrà un comportamente opzionale in quanto viene richiesta la registrazione e, rileggendo le definizioni delle associazioni possibili tra cosa d’uso, vedremo che quella corretta sarà un’estensione. Dunque il caso d’uso acquisto prodotto avrà un’estensione nel caso d’uso registrazione utente. Il diagramma relativo in UML sarà il seguente:
Facendo una considerazione sul tipo di associazione utilizzata, l’estensione, è evidente che è quella corretta in quanto l’inclusione del caso d’uso registrazione utente avrebbe richiesto la registrazione, anche agli utenti già registrati, ogni volta che viene effettuato un prodotto. Per quanto riguarda la specializzazione, possiamo dire che sarebbe stato corretto usarla ma il diagramma, in caso di modifiche future, sarebbe stato meno facile da modificare. Inoltre la definizione del caso d’uso registrazione utente ne permette il riuso nel caso venissero introdotte nel sito nuove funzionalità che richiedono la registrazione dell’utente.
