Revisione e perfezionamento degli scenari
Iniziare con la revisione e il perfezionamento degli scenari che si stanno trattando nel ciclo di sviluppo corrente.
Tali scenari possono essere già stati inizialmente identificati nella sezione Compito:
Ricerca di attori e casi d'uso. Utilizzare questi scenari elencati come punto di partenza nel determinare l'ambito
dei flussi che necessiteranno di una descrizione.
|
Dettaglio del flusso di eventi
Nella sezione Compito: Ricerca di attori e casi d'uso, è probabile che siano
stati già descritti i flussi degli eventi del caso d'uso. Utilizzare questa descrizione come punto di partenza e,
in modo graduale, renderla più dettagliata.
L'applicazione Storyboard fornirà un'assistenza per comprendere e definire i flussi
dei casi d'uso. Un altro dato di input da considerare è il prototipo dell'interfaccia utente, nel caso ne sia già stato
sviluppato uno.
Descrivere il caso d'uso secondo gli standard definiti per il progetto. Prendere una decisione relativa ai seguenti
punti prima di descrivere il caso d'uso (in modo da avere un'uniformità applicata a tutti i casi d'uso):
Concentrarsi sulla descrizione delle attività svolte nel caso d'uso e non sul modo in cui devono essere risolti i
problemi specifici interni al sistema. Quei dettagli saranno presi in considerazione più tardi nel ciclo di vita,
pertanto non esporre eccessivamente in dettaglio la descrizione durante questa fase. Descrivere soltanto i dettagli che
si suppone saranno stabili più in avanti.
Se il flusso di eventi di un caso d'uso diventa troppo intenso o complesso oppure se ha delle parti che sono tra loro
indipendenti, suddividerlo in due o più casi d'uso.
Quando si scrive il testo descrittivo, fare riferimento alla sezione Prodotto di
lavoro: Glossario. Quando vengono elaborati nuovi termini dai concetti, includerli nel glossario. Non cambiare la
definizione di un termine senza aver informato gli opportuni membri del progetto. Per maggiori informazioni,
consultare Compito: Cattura di un vocabolario comune.
Contenuto della descrizione di un flusso di eventi
La descrizione di un flusso di eventi esamina:
-
Come e quando inizia il caso d'uso.
Esempio:
"Il caso d'uso può essere avviato quando la funzione 'Gestisci ordine' è attivata da un'utente."
-
Quando il caso d'uso interagisce con gli attori e quali dati essi scambiano.
Esempio:
"Per creare un nuovo ordine, l'utente attiva la funzione 'Nuovo' e quindi specifica i seguenti dati obbligatori
riguardanti l'ordine: nome, elementi di rete (almeno uno) e tipo di funzione del sistema di misurazione. E' anche
possibile specificare i dati facoltativi riguardanti l'ordine: un commento (una breve descrizione testuale). L'utente
quindi attiva la funzione 'OK' e un nuovo ordine viene creato nel sistema".
Nota: è necessario essere precisi relativamente ai dati scambiati tra gli attori e il caso d'uso; altrimenti, il
cliente e gli utenti probabilmente non comprenderanno la descrizione del caso d'uso.
-
Come e quando il caso d'uso utilizza i dati memorizzati nel sistema o memorizza i dati nel sistema.
Esempio:
"L'utente attiva la funzione 'Modifica' per modificare un ordine esistente e specifica un numero di ordine (un numero
intero basso). Il sistema quindi inizializza un modulo di ordine con il nome dell'ordine, i relativi elementi di rete e
tipo di funzione del sistema di misurazione. Questi dati vengono richiamati da un'unità di memorizzazione secondaria."
-
Come e quando termina il caso d'uso.
Esempio:
"Il caso d'uso termina quando la funzione 'Uscita' è attivata dall'ordinante."
E' necessario descrivere anche i flussi di eventi eccezionali o particolari. Un flusso eccezionale è un flusso
secondario del caso d'uso che non è subordinato al normale o basilare comportamento del caso d'uso. Tuttavia, questo
flusso potrebbe essere necessario in una qualsiasi descrizione completa del comportamento del caso d'uso. Un esempio
tipico di flusso eccezionale è quello fornito nel primo esempio. Se il caso d'uso riceve dei dati non previsti (cioè
l'attore non rappresenta il dato previsto in quel particolare contesto), viene terminato. Utilizzando un attore errato
e terminando in anticipo non sono azioni di un tipico flusso di eventi.
Altre "cose da fare e non fare" quando si descrive un caso d'uso:
-
Descrivere il flusso degli eventi, non solo la funzionalità o lo scopo del caso d'uso.
-
Descrivere unicamente i flussi che appartengono al caso d'uso e non ciò che avviene in altri casi di utilizzo che
operano in parallelo.
-
Non menzionare gli attori che non comunicano con il caso d'uso in questione.
-
Non fornire troppi dettagli quando si descrive l'interazione del caso d'uso con un attore.
-
Se l'ordine dei flussi secondari descritto per il caso d'uso non deve essere corretto, non effettuarne una
descrizione come se deve essere corretto.
-
Utilizzare i termini nel glossario comune e tenere presente quanto segue durante la scrittura del testo:
-
Utilizzare un vocabolario semplice. Non utilizzare un termine complesso quando si può utilizzare uno semplice.
-
Scrivere frasi brevi e concise.
-
Evitare gli avverbi, come molto, più, piuttosto e alquanto.
-
Utilizzare una corretta punteggiatura.
-
Evitare frasi complesse.
Per maggiori informazioni, consultare Linea guida: caso
d'uso, le discussioni sul contenuto e stile del flusso di eventi.
|
Struttura del flusso di eventi
E' possibile suddividere il flusso degli eventi del caso d'uso in diversi flussi secondari. Quando il caso d'uso viene
attivato i flussi secondari possono essere associati in diversi modi se le seguenti informazioni restano vere:
-
Il caso d'uso può procedere da uno dei diversi percorsi possibili, a seconda dell'input proveniente da un
determinato actor oppure dei valori di alcuni attributi o oggetti. Ad esempio, un actor può decidere, rispetto a
diverse opzioni, in che modo procedere oppure il flusso degli eventi potrebbe differire se un valore è inferiore o
maggiore di un determinato valore.
Esempio:
Parte della descrizione del caso d'uso Preleva contante di uno sportello automatico ATM (Automated Teller Machine) può
essere "L'importo che il cliente desidera prelevare dal conto viene confrontato con il saldo del conto. Se l'importo
eccede il saldo, il cliente viene informato e il caso d'uso termina. Altrimenti, il denaro viene prelevato dal conto."
-
Il caso d'uso può eseguire alcuni flussi secondari in sequenze facoltative.
-
Il caso d'uso può eseguire diversi flussi secondari contemporaneamente.
E' necessario descrivere tutti questi flussi facoltativi o alternativi. Si consiglia di descrivere ciascun flusso
secondario in un supplemento a parte della sezione Flusso di eventi e dovrebbe essere obbligatorio per i seguenti casi:
-
Flussi secondari che occupano un grande segmento di un dato flusso di eventi.
-
Flussi di eventi eccezionali. Ciò consente di definire meglio il flusso di eventi base del caso d'uso.
-
Un qualsiasi flusso secondario che può essere eseguito a diversi intervalli nello stesso flusso di eventi.
Se un flusso secondario riguarda solo una piccola parte del flusso di eventi completo, è opportuno descriverlo nella
parte principale del testo.
Esempio:
"Questo caso d'uso è attivato quando la funzione 'gestisci ordine' viene richiamato dagli attori Ordinante o
Responsabile della gestione prestazioni. Se il segnale non proviene da uno di questi attori, il caso d'uso terminerà
l'operazione e visualizzerà un messaggio appropriato per l'utente. Tuttavia, se l'attore viene identificato, il caso
d'uso procede per....."
E' possibile illustrare la struttura del flusso degli eventi con un diagramma attività, consultare Guida: Diagramma attività nel modello caso d'uso.
Per maggiori informazioni, consultare la sezione relativa alla struttura in Linea guida: Caso
d'uso.
|
Presentazione delle relazioni tra attori e altri casi d'uso
Creare i diagrammi mostrando il caso d'uso e le relative relazioni con attori e altri casi d'uso. Un diagramma di
questo tipo funziona come un diagramma locale del caso d'uso e deve essere associato ad esso. Si noti che questo tipo
di diagramma del caso d'uso locale è solitamente di poco valore, a meno che il caso d'uso non abbia relazioni che
necessitano di essere descritte oppure vi sia un'insolita complessità tra gli attori coinvolti.
Per maggiori informazioni consultare Linea guida:
Diagramma del caso d'uso.
|
Descrizione di requisiti speciali
Tutti i requisiti che possono essere associati al caso d'uso ma che non sono presi in considerazione nel flusso di
eventi del caso d'uso devono essere descritti nei requisiti speciali del caso d'uso. Molto probabilmente i requisiti di
questo tipo non sono funzionali.
Per maggiori informazioni, consultare la sezione sui requisiti speciali nella sezione Linea guida: Caso d'uso.
|
Definizione dei protocolli di comunicazione
Definire il protocollo di comunicazione da utilizzare per un qualsiasi attore che sia un altro sistema o hardware
esterno. Se occorre utilizzare un protocollo esistente (specialmente i protocolli identificati o i protocolli
considerati standard), la descrizione del caso d'uso dovrebbe semplicemente fornire il nome al protocollo. Se il
protocollo è nuovo, occorre rivolgersi dove è possibile individuare la definizione del protocollo, che necessiterà di
una descrizione completa durante lo sviluppo del modello oggetto.
|
Descrizione delle condizioni antecedenti
Una condizione antecedente di un caso d'uso descrive lo stato in cui deve trovarsi il sistema per consentire l'avvio
del caso d'uso.
Esempio:
Un sistema ATM è in grado di distribuire contante se le seguenti condizioni antecedenti vengono soddisfatte:
-
La rete ATM deve essere accessibile.
-
L'ATM deve trovarsi in uno stato pronto per accettare transazioni.
-
L'ATM deve avere almeno del contante disponibile che può distribuire.
-
L'ATM deve avere abbastanza carta per stampare una ricevuta per almeno una transazione.
Le condizioni riportate sopra sono tutte valide per il caso d'uso Distribuisci contante.
Prestare attenzione alla descrizione dello stato del sistema; non descrivere il dettaglio di altre attività secondarie
che possono aver avuto luogo prima di questo caso d'uso.
Le condizioni antecedenti non vengono utilizzate per creare una sequenza dei casi d'uso. Non si creerà mai una
situazione dove occorre prima eseguire un caso d'uso, quindi un altro, per poter avere un significativo flusso di
eventi. Se si considera inutile questa operazione, è molto probabile che il modello caso d'uso sia stato suddiviso
troppe volte. Risolvere questo problema unendo i casi d'uso dipendenti consecutivamente in un unico caso d'uso. Se ciò
rende il caso d'uso derivante troppo complesso, considerare le tecniche di strutturazione dei casi d'uso, come
presentate nella fase precedente Struttura del flusso di eventi del caso d'uso oppure nella sezione Compito: Struttura del modello caso d'uso.
Per maggiori informazioni, consultare la sezione delle precondizioni in Linea guida: Caso
d'uso.
|
Descrizione delle condizioni successive
Una condizione successiva di un caso d'uso elenca i possibili stati in cui può trovarsi il sistema alla fine del caso
d'uso. Il sistema deve trovarsi in uno di quei stati alla fine dell'esecuzione del caso d'uso. Questa condizione viene
anche utilizzata per indicare le azioni che il sistema esegue alla fine del caso d'uso, indipendentemente da ciò che si
è verificato nel caso d'uso.
Esempio:
Se l'ATM visualizza sempre il messaggio 'Benvenuti' al termine di un caso d'uso, è possibile documentarlo nelle
condizioni successive del caso d'uso.
Analogamente, se l'ATM termina sempre la transazione del cliente alla fine di un caso d'uso come Preleva contante,
indipendentemente dal corso di eventi intrapreso, tale aspetto deve essere registrato come una condizione successiva
per il caso d'uso.
Le condizioni successive sono utilizzate per semplificare e migliorare la leggibilità del flusso di eventi del caso
d'uso.
In nessuna circostanza occorre utilizzare le condizioni successive per creare una sequenza dei casi d'uso. Non vi sarà
mai un caso dove occorre prima eseguire un caso d'uso, quindi un altro, per poter avere un significativo flusso di
eventi. Se si avverte la necessità di fare ciò, i casi d'uso dipendenti consecutivamente devono essere uniti in un
unico caso d'uso. Se ciò rende il caso d'uso combinato troppo complesso, considerare le tecniche per la strutturazione
dei casi d'uso, come presentate nella fase precedente Struttura del flusso di eventi del caso d'uso oppure nella
sezione Compito: Struttura del modello caso d'uso.
Per maggiori informazioni, consultare la sezione delle condizioni successive in Linea guida: Caso
d'uso.
|
Descrizione dei punti di estensione
Valutazione dei risultati
Revisionare e discutere il caso d'uso con i portatori d'interesse, in modo che possano avere una completa conoscenza
del caso d'uso e ne concordino la descrizione.
La descrizione del caso d'uso è completa solo quando riporta tutto ciò che il caso d'uso esegue, realizza o altrimenti
consente dall'inizio alla fine. Prima di terminare, controllare che il caso d'uso presenti le proprietà che lo
caratterizzano come un "buon" caso d'uso. Per maggiori informazioni, consultare la sezione Elenco di controllo: Caso d'uso.
|
|