Es: application ad una posizione lavorativa
| Use Case | “Titolo del caso d’uso”
Candidatura ad una posizione aperta | | --- | --- | | Scope | Sistema da progettare o parte del sistema da progettare (*)
Job placement | | Level | User-goal (**) | | Intention in context | Perché l’utente usa il sistema e cosa vuole ottenere
Il candidato vuole inviare i dati per partecipare ad un colloquio per una posizione lavorativa. | | Primary actor | Utente principale (chi fa la maggior parte delle operazioni)
Candidato ad una posizione lavorativa | | Support actor | (se presente) Attore di supporto
| | Stakeholder’s interest | Interesse specifico di uno stakeholder in questo caso d’uso (no attori) (***)
| | Precondition | Condizione (o stato del Sistema) che deve verificarsi perché questo caso d’uso possa essere eseguito. Situazione che si deve verificare affinché un caso d’uso possa avvenire (****)
| | Minimum guarantees | (se presente) Condizione che si verifica indipendentemente dal successo o fallimento del caso d’uso (*****)
| | Success guarantees | Condizione che si verifica quando il caso d’uso termina con successo (******)
I dati dell’utente sono salvati a sistema. | | Trigger | (se presente) Condizione che scatena l’avvio del caso d’uso da parte del sistema. Quando l’utente decide di avviare il caso d’uso autonomamente, il trigger non c’è mai (l’uno esclude l’altro) (*******)
Il caso d’uso termina con successo. Non si dice nulla a livello di implementazione. Non ho trigger (è l’utente che inizia l’attività) | | Extensions | Valutare tutte le possibili eccezioni che possono capitare nel main success scenario (*********)
3a - 5a. L’utente annulla, il caso d’uso termina con un fallimento (non ho raggiunto l’obiettivo) 4a. Il sistema rileva errori nell’inserimento dati, il sistema mostra un errore e il caso d’uso riprende dal punto 3 6a. Il sistema rileva un errore nel file (integrità o formato), il sistema mostra l’errore e il caso d’uso riprende dal punto 5 |
Sistema semplice: nome del sistema
Sistema articolato: parte del sistema interessato dal caso d’uso
Portale della Didattica:
Prenotazione esame → Gestione studente
Trasferta → Gestione missioni
EZgas → EZgas (non è così complesso come il Portale della Didattica
** Definisco i casi d’uso a livello utente
*** Stakeholder possono avere interesse in uno specifico caso d’uso, lasciando fuori attore principale e attori di supporto
**** Es. Login dell’utente, altri casi d’uso svolti in precedenza, …
***** Es. Richiesta online, indipendentemente dal fatto che sia andata a buon fine o meno ricevo un ID. Attraverso l’account utente, posso concludere la domanda con quell’ID. La domanda si conclude con successo solo quando la richiesta è inviata. Il caso d’uso è fallito se viene superata la deadline.
****** Cosa succede quando il caso d’uso va a buon fine? Indico lo stato del sistema dopo un caso d’uso che ha avuto successo.
******* Notifica, azione scatenante. Il sistema si accorge di qualcosa che avvia un caso d’uso. Es. Oggetto non disponibile all’acquisto. Appena torna disponibile parte il trigger per l’acquisto. Non sempre presente.
(********) Descrizione ad alto livello delle interazioni tra utente e sistema. Se il caso d’uso è avviato dall’utente: alternanza tra utente che chiede qualcosa e il sistema che risponde. Non si parla di interfacce. Se il caso d’uso è avviato da un trigger, l’alternanza avverrà tra sistema e utente che risponde.
(*********) Rimando a un punto precedente o determino il fallimento del caso d’uso per il mancato raggiungimento dell’obiettivo.
Il template è molto di alto livello, non c’è nessun riferimento grafico. In questa fase non è necessario scendere nei dettagli.
Quando c’è un “include” è possibile che si avvii un altro caso d’uso (come fosse la funzione di un programma).