Use Case Diagram

In questo esempio si cercherà di modellare, tramite gli use case diagrams, una macchina self-service per alimenti e bevande. La principale funzione di una siffatta macchina è, ovviamente, quella di permettere ad un utente di acquistare un prodotto alimentare (cioccolata, succo di frutta, ecc.).
Ogni utente che interagisca con la macchina potrà, certamente, dire che la principale funzione (e quindi il principale use case) della macchina stessa potrà essere definita come : "Acquisto di un prodotto".

Proviamo ad esaminare ogni possibile scenario all'interno di questo use case. Gli scenari che ne derivano saranno, naturalmente, scaturiti dalle conversazioni con l'utente.

Lo use case "Acquista un prodotto"

L'actor in questo use case è il cliente.
Il cliente vuole comprare alcuni dei prodotti offerti dalla macchina self-service. Per prima cosa egli dovrà inserire delle monete all'interno della macchina, poi selezionare il tipo di prodotto (o più di uno, se la macchina lo consente) e quindi ricevere dalla macchina la lista dei prodotti scelti prima di procedere all'acquisto vero e proprio. Lo use case per tale tipo di scenario può essere il seguente:

Ma, se ci si pensa un attimo più approfonditamente, vengono alla mente altri tipi di scenari. è possibile che la macchina self-service non sia in grado, ad un certo momento, di fornire uno o più prodotti oppure che la macchina non abbia a disposizione l'esatto numero di monete per fornire il resto al cliente.
Ci si deve chiedere: Ci è stato chiesto di gestire questi tipi di scenari?

Se la risposta è affermativa, torniamo un attimo indietro al momento in cui il cliente inserisce le monete nella macchina ed effettua la selezione. Supponiamo allora che la macchina, a questo punto, non sia in grado di soddisfare la richiesta del cliente. In tal caso sarà preferibile presentare un messaggio al cliente che lo informi che la macchina non ha come disponibile il prodotto scelto e che permetta al cliente stesso di effettuare una nuova scelta o richiedere la restituzione delle monete.

Se, invece, si è verificato lo scenario in cui è stato fornito un errato ammontare di monete, si suppone che la macchina restituirà l'importo originale di soldi al cliente. La precondizione, in tal caso, è il cliente (affamato o assetato!) e la post condizione è il prodotto acquistato o la restituzione dei soldi.

Quanto descritto rappresenta lo scenario di un use case dal punto di vista di un utente (e quindi di un actor). Ma potrebbero esserci anche altri tipi di actors. Per esempio, un fornitore di prodotti deve essere in grado rifornire la macchina e il proprietario della macchina deve poter recuperare le monete accumulate. Questo ci induce a creare almeno altri due use case che chiameremo: "Ricarica la Macchina" e "Ritira le Monete". Andiamo ad esaminarli entrambi simulando un' intervista con il fornitore e con il proprietario.

Lo use case "Ricarica la Macchina"

Le azioni che un fornitore dovrà compiere ad intervalli di tempo regolari (diciamo una o due settimane) sono:

• Il fornitore disattiva la macchina
• Apre il contenitore dei prodotti
• Riempie ogni scompartimento fino alla massima capacità (Si potrebbe anche supporre che il fornitore riempia la macchina tenendo conto delle maggiori preferenze dei clienti)
• Alla fine, il fornitore chiude il contenitore dei prodotti e riattiva la macchina

In questo caso, potremmo dire che la precondizione è rappresentata dal trascorrere dell'intervallo di tempo tra una ricarica e l'altra e la post condizione è data dal fatto che il fornitore ottiene un nuovo insieme di potenziali clienti.
Lo use case diagram, in questo caso, è rappresentato dalla seguente figura:

Lo use case "Ritira Le Monete"

Il responsabile per questo Use Case è il proprietario della macchina. In effetti, tuttavia, questi potrebbe coincidere con il fornitore. I passi che il proprietario della macchina deve fare sono uguali a quelli del fornitore ma la differenza consiste nel fatto che il proprietario non ha a che fare con i prodotti ma con i soldi.
Quando l'intervallo di tempo tra un ritiro e l'altro è trascorso, il proprietario della macchina ritira l'ammontare di monete che si è depositato nella macchina
La post condizione, in tal caso, è rappresentata dai soldi ritirati dal proprietario.

Lo use case che descrive tale scenario è, dunque, rappresentato nella figura seguente:

Molti dei passi necessari allo Use Case "Ritira le monete" (disattivare la macchina, aprire il contenitore, ecc.) sono uguali a quelli visti per lo use case "Ricarica la macchina". Questo è un buon motivo per avvalerci dell'utilizzo dell'inclusion. Combiniamo allora i due passi: Disattiva la macchina e apre il contenitore in uno use case che denominiamo: "Disattiva la macchina". Alla stessa maniera definiamo un nuovo Use case che chiamiamo "Riattiva la Macchina" che inglobi i passi di chiudere il contenitore e riattivare la macchina.
Otterremo:

Cerchiamo ora di raffinare ulteriormente i nostri use cases.

Lo use case "Ricarica la macchina" potrebbe essere la base per un altro use case: "Ricarica la macchina in base alle vendite". Qui, il fornitore può riempire gli scompartimenti non più in modo uniforme per ogni prodotto ma in base alle vendite dei singoli prodotti. Questo rappresenta un buon esempio di extension di un use case.

Dopo l'inclusion e l'extension così definiti, lo use case "Ricarica la macchina" può diventare:

Possiamo anche utilizzare la generalizzazione guardando gli actors: fornitore e proprietario. Sarà possibile definire un Actor più generico (Agente del Fornitore) che inglobi molte delle caratteristiche del Proprietario e del Fornitore.
Tale generalizzazione è mostrata nella figura che segue:

Un esempio di generalizzazione di un Actor

La figura sopra mostra il diagramma finale completo per la macchina self service.