Il seguente esempio è un concreto caso d'uso, anche se non supera il test del capo.
Visto che la partita viene eseguita come una simulazione che viene osservata da una persona, si può dire che questa persona è un'osservatore, non un giocatore.
Questo studio di caso (d'uso) mostra che i casi d'uso non sono sempre la soluzione migliore per i requisiti comportamentali. Cercare di descrivere tutte le regole del gioco con i casi d'uso è inopportuno.
Di che cosa fanno parte le regole del gioco? Innanzitutto, in generale, si tratta di regole di dominio (chiamate a volte regole di business). In UP, tali regole, possono far parte delle specifiche supplementari (SS), che conterranno, in una sezione di "regole di dominio", un riferimento al regolamento ufficiale del gioco o a un sito web che lo descrive. Anche nel testo dei casi d'uso potrebbe esserci un riferimento ad esso.
Trattandosi di una simulazione le diverse azioni del giocatore (simulato) sono raccolte nelle regole di dominio anziché nelle estensioni.
Portata: Applicazione Monopoly
Livello: Obiettivo utente
Attore primario: Osservatore (Observer nelle figure)
Parti interasse e interessi:
Scenario principale di successo:
Estensioni:
*.a.
In qualsiasi momento il Sistema fallisce: per consentire il ripristino, il Sistema registra ogni mossa completata.
Commento (non fa parte del caso d'suo): le estensioni sono alternative ai comportamenti di alcuni passi del caso principale di successo. Quindi di una estensioni va indicato il passo e con le lettere le alternative:
1.a (estensione a del passo 1)
1.a.1 (passo 1 dell'estensione a del passo 1 dello scenario principale)
In questo caso il comportamento si può verificare in ogni passo dello scenario principale, quindi lo indichiamo con *.a.
# estensione | Descrizione |
---|---|
*.a.1 | L'osservatore riavvia il sistema |
*.a.2 | Il Sistema rileva il guasto precedente, ricostruisce lo stato ed è pronto a continuare |
*.a.3 | L'Osservatore decide di continuare (dall'ultimo turno di giorno completato) |
Requisiti speciali: