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.
