Vai alla Home Page About me Courseware Federica Living Library Federica Federica Podstudio Virtual Campus 3D Le Miniguide all'orientamento Gli eBook di Federica La Corte in Rete
 
I corsi di Ingegneria
 
Il Corso Le lezioni del Corso La Cattedra
 
Materiali di approfondimento Risorse Web Il Podcast di questa lezione

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.

Concetti Fondamentali

Subject (o Confine del sistema)
Rappresenta il limite tra ciò che è interno al sistema da sviluppare e ciò che è esterno ad esso. È rappresentato da un rettangolo etichettato col nome del sistema.

Un ruolo (o un insieme di ruoli) che l’utente del caso d’uso svolge nell’interagire col sistema.
È esterno al sistema, può essere:

  • Una classe di persone fisiche (es. Fornitore)
  • Un altro sistema software (es. Sistema di contabilità)
  • Un dispositivo hardware esterno (es. Sensore)

Un attore fornisce uno stimolo al sistema e quindi ne riceve un output.


Caso d’Uso

È la specifica di una sequenza di azioni (incluse eventuali sequenze alternative e sequenze di errore) che un sistema può eseguire interagendo con attori esterni.
Descrive il comportamento del sistema quando un attore gli invia un particolare stimolo.
La descrizione di un caso d’uso definisce cosa accade nel sistema in seguito all’evento di innesco. Generalmente lo stimolo parte dall’attore, ma può anche essere il sistema stesso ad iniziare il caso d’uso (es. Produzione cedolini a fine mese, ricarico automatico di un magazzino).

Un caso d’uso corrisponde:

  • ad un compito che l’attore vuole eseguire (l’attore inizia il caso d’uso) oppure
  • ad un compito che il sistema deve eseguire (il sistema inizia il caso d’uso).

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.

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).

Generalizzazione fra casi d’uso

Simile alla generalizzazione fra classi.

Un caso d’uso generalizzato rappresenta diversi casi d’uso simili.

Uno o più casi d’uso specializzati forniscono i dettagli specifici dei casi d’uso simili.

Il figlio può aggiungere o modificare il comportamento del padre (es. Caso d’uso Valida Utente).

Talora il caso d’uso
padre è un caso d’uso 
astratto, che non ha
una sequenza di eventi
completamente 
specificata.

Talora il caso d'uso padre è un caso d'uso astratto, che non ha una sequenza di eventi completamente specificata.


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.

Relazione di Inclusione (segue)

In fig. 1: Descrizione di Segue iter ordinativo:

- ottieni e verifica numero ordinativo;
- include (Valida utente);
- per ogni parte dell’ordine, interroga lo stato, quindi rapporta all’utente.

fig. 1

fig. 1

fig. 2. Anche Presta Libro Antico e Presta rivista includono Identifica Studente.

fig. 2. Anche Presta Libro Antico e Presta rivista includono Identifica Studente.


Relazione di Estensione

Si usa per modellare una sequenza opzionale di eventi oppure casi eccezionali.

Creando estensioni separate, la descrizione del caso d’uso di base resterà semplice.

Una estensione deve elencare tutta la sequenza di passi dall’inizio del caso d’uso fino alla fine includendo la gestione della situazione insolita.


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 (segue)

Il caso d’uso ‘Effettua ordine‘ può presentare comportamento aggiuntivo in due casi:

  • Quando il cliente sceglie prodotti in promozione, il prezzo dell’articolo sarà opportunamente scontato;
  • Quando il cliente è un cliente abituale, gli verrà praticato uno sconto sul prezzo degli articoli ordinati;

Estensione vs Scenari Alternativi

L’esempio visto si poteva anche risolvere utilizzando un unico caso d’uso (Effettua Ordine) che avesse almeno due scenari alternativi (corrispondenti ai due casi d’uso estesi).
Come scegliere tra le due possibili soluzioni modellistiche?

La soluzione con tre casi d’uso è sicuramente più utile nel caso in cui I casi d’uso estesi abbiano ulteriori legami e/o siano direttamente richiamabili dall’utente.

La soluzione con un solo caso d’uso fornisce una vista più compatta del sistema, per cui potrebbe essere preferibile se si vuole realizzare un modello dei casi d’uso meno dettagliato.


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.

Tracciabilità requisiti- casi d’uso

È importante incrociare gli archivi dei requisiti funzionali e dei casi d’uso per verificare la reciproca copertura:
Ossia che ogni requisito sia coperto da almeno un caso d’uso e viceversa (in generale la relazione è molti-a-molti).

Matrice di Tracciabilità.

Matrice di Tracciabilità.


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).

Esercizio

Si vuole realizzare un sistema informatico in grado di gestire in maniera automatizzata le prove di esame tenute da un docente di un corso universitario. Il docente registra preventivamente i dati relativi alla prova, ossia il nome del corso, la data della prova, la durata (espressa in minuti), e l’insieme delle prove da sottoporre agli studenti.
In sede di esame, lo studente deve preventivamente iscriversi, indicando il proprio nome, cognome, numero di matricola e indirizzo e-mail. Il sistema fornisce allo studente iscritto il testo di una prova individuale (scegliendola dall’insieme delle prove registrate dal docente) e calcola il tempo limite entro il quale deve essere consegnata la soluzione. Il tempo limite di consegna è stabilito in base alla durata prevista per la prova e l’ora di assegnazione allo studente. Il sistema dovrà registrare tutti questi dati in apposito archivio.
Lo studente deve completare il proprio elaborato e consegnarlo tramite l’interfaccia del sistema entro il tempo limite. Il sistema invia inoltre una mail di conferma dell’avvenuta ricezione o di consegna impossibile qualora il tempo limite sia scaduto.
Il docente corregge ogni compito, indicando se é sufficiente o meno, inserendo un voto (numerico, compreso tra 18 e 30 oppure insufficiente). Al termine dell’inserimento dei giudizi di tutti i compiti, un messaggio di e-mail viene recapitato ad ogni studente, con il risultato del suo compito.


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


I materiali di supporto della lezione

Martin Fowler, UML Distilled, capitolo 9.

Ian Sommerville, Ingegneria del Software, capitolo 7.

  • Contenuti protetti da Creative Commons
  • Feed RSS
  • Condividi su FriendFeed
  • Condividi su Facebook
  • Segnala su Twitter
  • Condividi su LinkedIn
Progetto "Campus Virtuale" dell'Università degli Studi di Napoli Federico II, realizzato con il cofinanziamento dell'Unione europea. Asse V - Società dell'informazione - Obiettivo Operativo 5.1 e-Government ed e-Inclusion