Operazione: Descrizione dettagliata di un caso d'uso
In questa attività vengono aggiunti i dettagli a uno specifico caso d'uso.
Scopo

Lo scopo di questo compito è di:

  • Descrivere uno o più dei flussi di eventi del caso d'uso in modo sufficientemente dettagliato per iniziarne l'utilizzo da parte dello sviluppo software.
  • Esporre in dettaglio il caso d'uso ai fini dell'apprendimento e dello soddisfacimento del rappresentante attore o cliente.
Relazioni
Passi
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):

  • Come inizia il caso d'uso? L'inizio del caso d'uso deve chiaramente descrivere il segnale che lo attiva. Scrivere, ad esempio, "Il caso d'uso può iniziare quando ... accade."
  • Come termina il caso d'uso? Occorre chiaramente specificare tutto ciò che accade nel corso del flusso per terminare il caso d'uso. Scrivere, ad esempio, "Quando ... accade, il caso d'uso termina."
  • In che modo il caso d'uso interagisce con gli attori? Per ridurre al minimo il rischio di incomprensioni, affermare con esattezza cosa risiederà all'interno del sistema e cosa risiederà all'esterno del sistema. Strutturare la descrizione con una serie di paragrafi, nella quale ciascun paragrafo espone un'azione nel formato: "Quando l'attore effettua ..., il sistema esegue ...." E' possibile anche evidenziare l'interazione scrivendo che il caso d'uso invia e riceve i segnali dagli attori, ad esempio: "Il caso d'uso inizia quando riceve il segnale 'start (avvia)' dall'operatore."
  • In che modo il caso d'uso scambia i dati con un attore? Se si desidera, è possibile fare riferimento agli argomenti dei segnali, ma sarebbe meglio scrivere, ad esempio, "Il caso d'uso inizia quando l'utente si collega al sistema fornendo il proprio nome e password."
  • In che modo il caso d'uso ripete un determinato comportamento? Provare ad esprimerlo in un linguaggio naturale. Tuttavia, in casi eccezionali, potrebbe essere proficuo utilizzare del codice, simile alle costruzioni, come "WHILE-END WHILE," "IF-THEN-ELSE," e "LOOP-END LOOP," se i corrispondenti termini del linguaggio naturale sono difficili da esprimere. Pertanto, in via generale, non utilizzare tale codice, come le costruzioni nelle descrizioni nel caso d'uso, poiché sono difficili da leggere e conservare.
  • Esiste qualche situazione facoltativa nel flusso degli eventi di un caso d'uso? A volte un attore viene presentato con diverse opzioni. Ciò deve essere scritto nello stesso modo. Ad esempio:

    "L'attore sceglie una delle seguenti opzioni, una o più volte:

    a) . . .

    b) . . .

    c) . . ." ecc.

  • Come deve essere descritto il caso d'uso in modo che il cliente e gli utenti possano comprenderlo? L'utilizzo di una terminologia specifica della metodologia, come il caso d'uso, l'attore e il segnale, potrebbe rendere il testo inutilmente difficile da comprendere. Per rendere il testo più comprensibile da leggere, è possibile enumerare le azioni o adottare qualche altra strategia. Qualsiasi strategia si utilizzi, è necessario specificare le linee guida generali di modellazione del caso d'uso, in modo da ricordarle durante l'intera attività di descrizione dei 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

Se il caso d'uso deve essere esteso da un altro caso d'uso (consultare Linea guida: Relazione di estensione), occorre descrivere quali sono i punti di estensione (consultare la relativa sezione in Linea guida: Caso d'uso).

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.

Proprietà
Ricorrenze multiple
Attivato da evento
In corso
Facoltativo
Pianificato
Ripetibile
Considerazioni chiave
When detailing a use case, especially to support the review of the use case, you may want to generate a use-case specification. For more information, see the the reports, templates, and examples, as well as the tool mentors for generating the reports, that are associated with Work Product: Use Case.
Ulteriori informazioni