Porfirio Tramontana » 4.Casi d'uso

Generalità

L’analisi dei casi d’uso viene impiegata durante la fase di analisi per modellare il comportamento esterno del sistema da sviluppare, senza dover specificare come tale comportamento viene realizzato.

• Il sistema viene visto, al suo interno, come una scatola nera (black box);
• Il comportamento del sistema è analizzato dal punto di vista dei suoi possibili utenti
  • Per questo motivo si presta particolarmente ad essere compilato a valle di interviste al committente.

La tecnica dei casi d’uso è parte integrante della specifica di UML – Unified Modeling Language

• UML verrà trattato diffusamente in seguito.

Caso d’Uso (segue)

Un caso d’uso può essere descritto tramite un insieme di scenari di interazione tra gli utilizzatori ed il sistema. Esempio:

• il cliente richiede l’elenco dei prodotti;
• il sistema propone i prodotti disponibili;
• il cliente sceglie i prodotti che desidera;
• il sistema fornisce il costo totale dei prodotti selezionati;
• il cliente conferma l’ordine;
• il sistema comunica l’accettazione dell’ordine.

L’attenzione è rivolta all’interazione, non alle attività interne al sistema.

Esempio: sistema di acquisti on-line

Esempio: centralina telefonica per ufficio

Descrizione di un caso d’uso

Definisce cosa accade nel sistema in seguito all’evento di innesco (scenario):

• come e quando il caso d’uso inizia;
• chi inizia il caso d’uso;
• interazione tra attore/i e caso d’uso e cosa viene scambiato;
• come e quando c’è bisogno di dati memorizzati o di memorizzare dati;
• come e quando il caso d’uso termina.

Sono previsti scenari normali e scenari alternativi (o eccezionali).
Stili di descrizione:

• testuali, con un flusso chiaro di eventi da seguire;
• diagrammatici: diagramma di stato, di sequenza, di interazione
  • Essendo diagrammi utili anche in fase di progettazione, verranno presentati in futuro.

La descrizione dei casi d’uso con pre e post-condizioni

Nome del caso d’uso

Attori coinvolti  (primari – che avviano il caso d’uso e secondari)

Descrizione breve

Pre-condizioni: specificano lo stato del sistema prima di eseguire il caso d’uso

Sequenza di eventi: Percorso Normale

Post-condizioni: specificano lo stato del sistema dopo l’esecuzione del caso d’uso

Altri casi d’uso correlati

Sequenza di eventi: Percorsi alternativi

Esempio: Caso d’uso effettua ordine

Pre-condizioni: Un utente valido ha effettuato il login. Flusso di eventi: Percorso Normale:

1. Il cliente sceglie di effettuare un ordine;
2. Il cliente inserisce nome ed indirizzo;
3. IF il cliente inserisce solo il CAP, il sistema visualizza la città;
4. Il cliente inserisce i codici dei prodotti da ordinare;
5. Il sistema visualizza la descrizione ed il prezzo di ciascun prodotto;
6. Il sistema calcola il totale dell’ordine man mano che i prodotti sono inseriti;
7. Il cliente inserisce i dati della carta di credito;
8. Il cliente preme il tasto di Conferma ordine;
9. Il sistema verifica le informazioni, salva l’ordine tra gli ordini pendenti, ed invia le informazioni per il pagamento al sistema dei pagamenti;
10. Quando il pagamento viene confermato, l’ordine viene contrassegnato come Confermato, il codice ordine viene inviato al cliente e il caso d’uso termina.

Percorsi alternativi:
Al punto 9, se qualche informazione risulta scorretta, il sistema chiederà al cliente di correggere l’informazione scorretta.

Post condizioni: l’ordine è stato salvato nel sistema e segnato come Confermato.

Uso di If, While e For negli scenari

Le alternative possono essere descritte attraverso If oppure attraverso percorsi alternativi.
Cicli While o For possono essere usati per racchiudere gruppi di passi che devono essere ripetuti più volte

• esempio (al passo 4 dello scenario precedente):
  • 4. Per (For) ciascun codice prodotto inserito
  • a) il sistema fornirà la descrizione ed il prezzo
  • b) il sistema aggiungerà il prezzo al totale
  • end

Generalizzazione di attori

L'attore figlio conserva le proprietà del padre oltre a possedere sue caratteristiche particolari.

Controindicazioni

Nella descrizione di un caso d’uso NON devono essere indicati dettagli che rivelino le scelte di progetto o architetturali.

Quando si pensa ai casi d’uso, non si è ancora affrontato alcun aspetto della progettazione.
Gli aspetti algoritmici non dovrebbero comparire nella descrizione degli scenari: interessa sapere quale problema sarà affrontato, non la soluzione che verrà scelta (in una fase successiva).
Non possono esserci riferimenti a specifici file/ moduli/ specifiche interfacce utente, a meno che essi non rappresentino dei vincoli (ad esempio dei sistemi già esistenti con i quali bisogna integrarsi).

Il diagramma dei casi d’uso dovrebbe SEMPRE essere tracciato e approvato PRIMA di partire con le fasi di progetto.

Relazioni fra casi d’uso

Tra gli use case possono esistere relazioni di tipo generalization, include, extend.

Tali relazioni sono usate per strutturare ulteriormente un modello dei casi d’uso:

• generalizzando/specializzando un caso d’uso;
• estraendo comportamenti comuni tra essi (include);
• distinguendo comportamenti varianti rispetto a quello base (inserendo tali comportamenti in altri use case che estendono quello base).

Relazione di Inclusione

Un comportamento comune a più casi d’uso diventa un caso d’uso che è incluso nei casi d’uso di partenza

• L’inclusione avviene in un punto preciso della descrizione del caso d’uso includente. Il caso incluso può non aver senso da solo.
• Rappresentato graficamente come una dipendenza stereotipata come <<include>>.

L’inclusione NON contiene informazioni sull’ordine con il quale due casi d’uso vengono effettuati

• Piuttosto, il caso d’uso incluso potrebbe essere interpretato come un sottoproblema che è parte di uno (o più) altri problemi (rappresentati dai casi d’uso includenti).

Relazione tra inclusione e generalizzazione

• Se un caso d’uso generale include un altro caso d’uso, allora tutte le sue specializzazioni “ereditano” tale inclusione.

Esempio

Proprietà dell’estensione:

• L’estensione NON contiene informazioni sull’ordine con il quale due casi d’uso vengono effettuati;
• L’estensione (extend) è da intendersi come un verbo attivo, quindi la freccia va dal caso d’uso esteso a quello base;
  • Nel caso in cui fosse utilizzato lo stereotipo passivo (extended) allora la freccia andrebbe dal caso base a quello esteso.
• I casi d’uso estesi possono a loro volta essere anche accessibili direttamente: in tal caso ci sarà una linea da un attore verso il caso d’uso esteso.

Esempio: Gestione Biblioteca

Requisiti e Casi d’Uso

Requisito funzionale:

• funzionalità, o aspetto di dettaglio di una funzionalità, richiesta dal committente.

Caso d’Uso:

• modalità di utilizzo del sistema da parte di un utilizzatore (attore).

Ogni caso d’uso può soddisfare più requisiti funzionali;
un requisito funzionale può dare origine a più casi d’uso;
a ogni caso d’uso possono venire associati più requisiti non funzionali.

I requisiti funzionali sono pensati dal punto di vista del sistema, i casi d’uso da quello dell’utente.

Costruzione di un modello dei casi d’uso

1. Identifica gli attori

• Identifica le persone che interagiscono con il sistema per eseguire qualche compito
  • Identifica le persone che necessitano del sistema per svolgere qualche compito;
  • Identifica le persone che il sistema richiede per svolgere qualche compito;
  • considera sia i compiti principali che quelli di supporto al sistema, quali manutenzione ed amministrazione.
• Raggruppa le persone identificate secondo i loro ruoli (responsabilità) rispetto al sistema.
• Identifica altri sistemi software e dispositivi esterni che interagiscono con il sistema per svolgere qualche compito.

Costruzione di un modello dei casi d’uso (segue)

2. Identifica i casi d’uso

• Per ogni attore
  • identifica i compiti o funzioni di più basso livello che l’attore deve essere in grado di eseguire;
  • identifica i compiti che il sistema richiede che l’attore esegua;
• Raggruppa compiti e funzioni in casi d’uso
  • i casi d’uso devono corrispondere ad un obiettivo specifico per l’attore o per il sistema;
  • raggruppa funzioni che sono eseguite in sequenza o che sono innescate dallo stesso evento;
  • il caso d’uso deve essere nè troppo grande nè troppo piccolo (non decomporre funzioni complesse in casi d’uso per ogni sottofunzione);
• Nomina il caso d’uso sintetizzando la funzionalità svolta.

3. Definisci la comunicazione tra attori e casi d’uso

• Ogni attore deve partecipare ad almeno un caso d’uso;
• Ogni caso d’uso deve avere almeno un attore con cui comunica;
• Se due attori partecipano agli stessi casi d’uso considera la possibilità di combinarli in un unico attore.

Costruzione di un modello dei casi d’uso (segue)

4. Descrivi i casi d’uso

• Considera sia lo scenario principale che scenari alternativi ed eccezionali;
• Per ogni scenario specifica:
  • Quale evento scatena il caso d’uso (trigger);
  • Chi inizia il caso d’uso;
  • Quali precondizioni sono da ritenersi verificate nel momento in cui il caso d’uso inizia;
  • Quali sono le interazioni tra il/gli attore/i e il sistema e quali dati/comandi vengono scambiati;
  • Come e quando c’è bisogno di memorizzare dati;
  • Come e quando il caso d’uso termina;
  • Quali postcondizioni (garanzie) sono da ritenersi verificate nel momento in cui il caso d’uso termina.
• Se due casi d’uso hanno comportamenti leggermente diversi e gli stessi attori, considera la possibilità di avere un unico caso d’uso con scenari alternativi.

Costruzione di un modello dei casi d’uso (segue)

5. Struttura i casi d’uso

• Identifica le relazioni di estensione:
  • specializza i casi d’uso che hanno molti scenari alternativi;
  • collega i nuovi casi d’uso a quelli di partenza mediante relazione <<estendi>>.

• Identifica le relazioni di inclusione
  • individua parti comuni in casi d’uso diversi;
  • collega i casi d’uso che condividono una parte comune al nuovo caso d’uso (rappresentante il comportamento condiviso) mediante l’associazione <<include>>.

Deliverables

L’analisi dei casi d’uso produce:

• Un diagramma dei casi d’uso;
• Le descrizioni di tutti gli scenari di tutti i casi d’uso.

Nel diagramma è contenuto solo un piccolo sottoinsieme delle informazioni contenute nelle descrizioni.
Tutte le informazioni contenute nel diagramma sono contenute anche nelle descrizioni.

Quindi, il diagramma dei casi d’uso non può mai essere considerato separatamente dalle descrizioni. Eventualmente, piuttosto, esso potrebbe essere omesso (o ricavato automaticamente da descrizioni dei casi d’uso scritte in maniera formalmente consistente).

Casi d’uso Correggi Compito e Invia Risultato

CASO D’USO CORREGGI COMPITO
Pre-condizioni: Il docente registrò una prova.
Flusso di eventi:
Percorso Normale:

1. Il docente chiede al sistema i compiti consegnati dagli studenti
2. Il sistema restituisce i file contenenti le risoluzioni dei compiti
3. FOR ogni compito, il docente lo corregge assegnando un voto compreso tra 18 e 30 oppure insufficiente
4. Il sistema memorizza tali voti in un database
5. INCLUDE Invia risultati

Casi d’uso Correggi Compito e Invia Risultato (segue)

CASO D’USO INVIA RISULTATO
Pre-condizioni: Il docente ha corretto tutti i compiti
Flusso di eventi:
Percorso Normale

1. Il docente conferma l’autorizzazione all’invio;
2. FOR ogni compito, il sistema invia una mail contenente il voto conseguito allo studente cui appartiene il compito.

Casi d’uso Correggi Compito e Invia Risultato (segue)

CASO D’USO SVOLGI PROVA
Pre-condizioni: Il Docente registrò una prova
Flusso di eventi:
Percorso Normale:

1. INCLUDE ISCRIVI A PROVA
2. Lo studente risolve la prova
3. IF lo studente non vuole consegnare la prova, PERCORSO ALTERNATIVO^#
4. EXTENSION POINT 1: INVIA SOLUZIONE

^#Percorso alternativo:

• Lo studente si ritira
• Il sistema memorizza l’avvenuto ritiro

Casi d’uso Svolgi Prova e Invia Soluzione

CASO D’USO ISCRIVI A PROVA
Flusso di eventi:
Percorso normale:

1. Lo studente si identifica e chiede al sistema di iscriverlo alla prova;
2. Il sistema memorizza I dati;
3. Lo studente richiede la traccia della prova;
4. Il sistema memorizza l’orario di inizio della prova e la traccia inviata;
5. Il sistema restituisce allo studente la traccia della prova e fa partire il tempo.

Casi d’uso Svolgi Prova e Invia Soluzione (segue)

CASO D’USO INVIA SOLUZIONE
Pre-condizioni: Lo studente ritiene di aver risolto la prova
Flusso di eventi:
Percorso Normale

1. Lo studente conferma l’avvenuta risoluzione della prova;
2. IF Il tempo è scaduto PERCORSO ALTERNATIVO^#
3. Il sistema acquisisce la prova

^#Percorso alternativo

• Il sistema notifica allo studente che il tempo è scaduto e non può essere consegnata la prova
• Il sistema memorizza l’avvenuto ritiro.

Use case diagram