Linea guida: Caso d'uso
Un caso d'uso descrive quali attività svolge il sistema per soddisfare un requisito. Questa linea guida spiega come identificare e sviluppare i casi d'uso.
Relazioni
Descrizione principale

Spiegazione

Esistono diverse parole chiave in questa definizione:

  • Istanza di caso d'uso. La sequenza menzionata nella definizione è in realtà un flusso specifico di eventi attraverso il sistema, o un'istanza. Molti flussi di eventi sono possibili e molti possono essere assai simili. Per rendere comprensibile un modello di casi d'uso, raggruppare i flussi di eventi simili in un unico caso d'uso. Identificare e descrivere un caso d'uso significa in realtà identificare e descrivere un gruppo di flussi di eventi correlati.
  • Il sistema esegue. Questo significa che il sistema fornisce il caso d'uso. Un attore comunica con un'istanza di caso d'uso del sistema.
  • Un risultato di valore osservabile. E' possibile assegnare un valore ad un caso d'uso eseguito con esito positivo. Un caso d'uso deve far s^ che un attore possa eseguire un'attività che dispone di un valore identificabile. E' molto importante nella determinazione del livello corretto o della granularità giusta di un caso d'uso. Il livello corretto si riferisce ad ottenere dei casi d'uso non troppo piccoli. In determinate circostanze è possibile utilizzare un caso d'uso come unità di pianificazione in un'organizzazione che include degli individui come attori nel sistema.
  • Azioni. Un'azione è una procedura algoritmica o di calcolo. Viene richiamata quando l'attore fornisce un segnale al sistema o quando il sistema ottiene un evento di tempo. Un'azione può implicare delle trasmissioni di segnali all'attore che effettua la chiamata o ad altri attori. Un'azione è atomica, cioè o viene eseguita interamente o non viene eseguita affatto.
  • Un attore particolare. L'attore è di importanza chiave per individuare il caso d'uso corretto, specialmente perché è utile per evitare casi d'uso troppo grandi. Come esempio, si consideri un tool visivo di modellazione. Per questa applicazione esistono in realtà due attori: uno sviluppatore (qualcuno che sviluppa i sistemi utilizzando il tool come supporto) ed un amministratore di sistema (qualcuno che gestisce il tool). Ognuno di questi attori ha le proprie esigenze sul sistema e quindi richiederà un proprio insieme di casi d'uso.

La funzionalità di un sistema viene definita da casi d'uso diversi, ognuno dei quali rappresenta un flusso di eventi specifico. La descrizione di un caso d'uso definisce quello che accade nel sistema quando viene eseguito il caso d'uso.

Diagramma descritto nella figura.

In un bancomat, per esempio, il client può prelevare denaro da un conto, trasferire una somma ad un altro conto oppure controllare il saldo di un conto. Queste funzioni corrispondono ai flussi che possono essere rappresentati tramite i casi d'uso.

Ogni caso d'uso dispone di un proprio compito da eseguire. I casi d'uso raccolti costituiscono tutti i modi possibili di utilizzare il sistema. È possibile farsi un'idea del compito del caso d'uso semplicemente osservandone il nome.

Come individuare dei casi d'uso

Quella che segue è una serie di domande utili per l'identificazione dei casi d'uso:

  • Per ogni attore identificato, quali sono i compiti in cui verrebbe coinvolto il sistema?
  • L'attore deve essere messo al corrente di determinate ricorrenze nel sistema?
  • L'attore deve informare il sistema su eventuali modifiche improvvise esterne?
  • Il sistema fornisce il business con il comportamento corretto?
  • Tutte le funzioni possono essere eseguite tramite i casi d'uso identificati?
  • Quali casi d'uso supportano e gestiscono il sistema?
  • Quali informazioni devono essere modificate o create nel sistema?

I casi d'uso spesso trascurati, perché non rappresentano quelle che in genere sono le funzioni primarie del sistema, possono essere del seguente tipo:

  • Avvio ed arresto del sistema.
  • Manutenzione del sistema. Ad esempio, l'aggiunta di nuovi utenti e l'impostazione dei profili utente.
  • Manutenzione dei dati memorizzati nel sistema. Ad esempio, il sistema viene costruito in modo da lavorare in parallelo con un sistema preesistente ed i dati devono essere sincronizzati nei due sistemi.
  • Funzionalità necessaria per modificare il comportamento nel sistema. Un esempio potrebbe essere la funzionalità per la creazione di nuovi report.

Se sono stati sviluppati un modello di casi d'uso di business ed un modello di analisi di business, questi artefatti sono un buon punto di partenza per identificare i casi d'uso.

Come si evolve un caso d'uso

Nelle prime iterazioni di un'elaborazione, sono alcuni casi d'uso vengono descritti in dettaglio, oltre la breve descrizione (si tratta di quelli considerati strutturalmente significativi). Sviluppare sempre inizialmente una struttura del caso d'uso (in un formato strutturato in fasi) prima di andare a fondo nei dettagli. Questo tipo di struttura deve essere il primo tentativo di definizione della struttura del flusso di eventi del caso d'uso (consultare la sezione riportata di seguito Flusso di eventi - Struttura). Iniziare sempre con il flusso base del caso d'uso. Una volta stabilito un accordo sulla struttura del flusso base, è possibile aggiungere quali dovrebbero essere i flussi alternativi, in relazione al flusso di base.

Verso il termine dell'elaborazione devono essere completati tutti i casi d'uso che si prevede di descrivere in dettaglio.

Tutti i casi d'uso sono descritti in dettaglio?

Spesso nel modello saranno presenti dei casi d'uso talmente semplici da non richiedere una descrizione dettagliata del flusso di eventi, una struttura per fasi è più che sufficiente. I criteri per decidere sono relativi all'assenza di disaccordo fra i lettori di tipo utente sul significato del caso d'uso, e al fatto che i progettisti ed i tester sono soddisfatti con il livello di dettagli fornito dal formato strutturato in fasi. Degli esempi sono i casi d'uso che descrivono una semplice voce o il richiamo di qualche dato dal sistema.

Ambito di un caso d'uso

Spesso è difficile decidere se una serie di interazioni utente-sistema, o un dialogo, devono essere un unico caso d'uso o più casi d'uso. Considerare l'utilizzo di una macchina per il riciclaggio. Il cliente inserisce gli articoli da depositare, ad esempio le lattine e le bottiglie nella macchina per il riciclaggio. Una volta inseriti tutti gli articoli da depositare, si preme il pulsante e viene stampata una ricevuta. La persona può quindi convertire la ricevuta in denaro.

L'inserimento di un articolo da depositare è un caso d'uso e la richiesta di ricevuta un altro? Oppure fanno parte entrambi dello stesso caso d'uso? Sono presenti due azioni ma una senza l'altra hanno poco valore per il cliente. Piuttosto, è il dialogo completo (tutti gli inserimenti e l'ottenimento della ricevuta) ad avere un valore per il cliente (ed una logica). Quindi il dialogo completo, dall'inserimento del primo articolo da depositare all'ottenimento della ricevuta premendo il pulsante, forma un caso completo di utilizzo, cioè un caso d'uso.

Inoltre, si desidera mantenere insieme le due azioni, per poterle rivedere nello stesso momento, modificarle insieme, testarle insieme, scrivere dei manuali su di loro ed in generale gestirle come un'unità. Questo diviene molto ovvio nei sistemi più grandi.

Come vengono realizzati i casi d'uso

Un caso d'uso descrive cosa succede nel sistema quando un attore interagisce con il sistema per eseguire il caso d'uso. Il caso d'uso non definisce come il sistema esegua internamente le attività in termini di oggetti che collaborano. Sta alle realizzazioni del caso d'uso mostrarlo.

Esempio:

Nell'esempio del telefono, il caso d'uso indicherebbe, fra le altre cose, che il sistema invia un segnale quando il ricevitore viene sollevato e che il sistema, quindi, riceve gli impulsi, trova il destinatario, fa squillare il suo telefono, connette la chiamata, trasmette le parole, e così via.

In un sistema in esecuzione, un'istanza di caso d'uso non corrisponde ad alcun oggetto in particolare nel modello di implementazione (ad esempio un'istanza di una classe nel codice). Corrisponde invece ad uno specifico flusso di eventi richiamato da un attore ed eseguito come sequenza di eventi in un insieme di oggetti. In altre parole, le istanze dei casi d'uso corrispondono ad istanze di comunicazione di oggetti implementati. Questa viene denominata la realizzazione del caso d'uso. Spesso, gli stessi oggetti partecipano alla realizzazione di più di un caso d'uso. Ad esempio, in un sistema bancario, entrambi i casi d'uso Deposito e Prelievo possono utilizzare un determinato oggetto Conto nella loro realizzazione. Ciò non significa che i due casi d'uso comunichino fra loro, ma solo che utilizzano lo stesso oggetto nella loro realizzazione.

È possibile visualizzare un flusso di eventi come un'unità composta da diversi flussi secondari, che considerati insieme producono il flusso di eventi totale. È possibile riutilizzare la descrizione di un flusso secondario in un altro flusso di eventi di casi d'uso. I flussi secondari contenuti nella descrizione di un flusso di eventi di casi d'uso possono essere comuni a quelli di altri casi d'uso. Nella progettazione devono essere gli stessi oggetti ad eseguire questo comportamento comune per tutti i casi d'uso pertinenti; vale a dire, solo una serie di oggetti deve eseguire questo comportamento, a prescindere da quale caso d'uso sia in esecuzione.

Esempio:

In un sistema bancomat automatizzato, il flusso secondario iniziale è lo stesso contenuto nel flusso di eventi dei casi d'uso Prelievo ed Saldo. Il flusso di eventi di entrambi i casi d'uso inizia verificando l'identità della carta ed il codice di accesso personale del cliente.

Un caso d'uso dispone di molte possibili istanze

Un'istanza di caso d'uso può seguire un numero quasi illimitato, ma enumerabile, di percorsi. Tali percorsi rappresentano le scelte disponibili per l'istanza di caso d'uso nella descrizione del suo flusso di eventi. Il percorso scelto dipende dagli eventi. I diversi tipi di evento includono:

  • Input da un attore. Ad esempio, un attore può decidere, fra diverse opzioni, cosa fare dopo.

Esempio:

Nel caso d'uso Ricicla articoli nel sistema della macchina per il riciclaggio, il Cliente ha sempre due opzioni: inserire un altro articolo da depositare oppure chiedere la ricevuta degli articoli restituiti.

  • Una verifica di valori o di tipi di un oggetto interno o di un attributo. Ad esempio, il flusso di eventi può essere diverso se un valore è maggiore o minore rispetto ad un determinato valore.

Esempio:

Nel caso d'uso Prelievo di denaro in un sistema di bancomat automatizzato il flusso di eventi sarà diverso se il Cliente chiede più denaro di quanto non ne disponga sul conto. Quindi, l'istanza caso d'uso seguirà dei percorsi diversi.

Simultaneità delle istanze di caso d'uso

Le istanze di di diversi casi d'uso o diverse istanze dello stesso caso d'uso funzionano contemporaneamente se il sistema lo consente. Nella modellazione del caso d'uso si può presupporre che le istanze di casi d'uso possano essere attive simultaneamente senza conflitto. E' previsto che sia il modello di progettazione a risolvere questo problema, poiché la modellazione di casi d'uso non descrive il funzionamento degli elementi. Un modo di vedere le cose è di presupporre che sia attiva solo un'istanza caso d'uso alla volta e che la sua esecuzione sia un'azione atomica. Nella modellazione del caso d'uso, la "macchina interpretativa" viene considerata infinitamente veloce, in modo che la serializzazione delle istanze dei casi d'uso non sia un problema.

Nome

Ogni caso d'uso deve avere un nome che indichi cosa si ottiene mediante la sua interazione con gli attori. Il nome potrebbe essere composto da diverse parole, per essere compreso. Due casi d'uso non possono avere lo stesso nome.

Esempio:

Questi sono due esempi di variazioni di nome per il caso d'uso Ricicla articoli nell'esempio della macchina per il riciclaggio:

  • Ricevi articoli da depositare
  • Ricezione articoli da depositare
  • Restituzione articoli da depositare
  • Articoli per il deposito

Breve descrizione

La breve descrizione del caso d'uso deve riflettere il suo scopo. Quando si scrive la descrizione, fare riferimento agli attori implicati nel caso d'uso, al glossario e, se necessario, definire dei nuovi concetti.

Esempio:

Di seguito sono riportati degli esempi di descrizioni brevi dei casi d'uso Ricicla articoli e Aggiungi nuovo tipo di bottiglia al sistema della macchina per il riciclaggio:

Ricicla articoli: l'utente usa questa macchina per contare automaticamente tutti gli articoli restituiti (bottiglie di vetro, lattine e bottiglie di plastica) e riceve una ricevuta. La ricevuta deve essere riscossa alla cassa (macchina).

Aggiungi nuovo tipo di bottiglia: possono essere aggiunti dei nuovi tipi di bottiglie alla macchina avviandola in 'modalità apprendimento' ed inserendo 5 esempi, esattamente come quando si restituiscono degli articoli. In questo modo, la macchina può misurare le bottiglie ed imparare ad identificarle. Il responsabile specifica il valore del rimborso relativo al nuovo tipo di bottiglia.

Flusso di eventi - Contenuto

Il Flusso di eventi di un caso d'uso contiene le informazioni più importanti derivate dal lavoro di modellazione del caso d'uso. Devono descrivere il flusso di eventi del caso d'uso abbastanza chiaramente per un estraneo in modo che sia facilmente comprensibile. Ricordarsi che il flusso di eventi deve presentare cosa fa il sistema, non come questo è stato progettato per poter eseguire il comportamento richiesto.

Linee guida per il contenuto del flusso di eventi:

  • Descrivere come inizia e termina il caso d'uso.
  • Descrivere quali dati vengono scambiati fra l'attore ed il caso d'uso.
  • Non descrivere i dettagli dell'interfaccia utente, a meno che non sia necessario ai fini della comprensione del comportamento del sistema. Ad esempio, è spesso utile utilizzare una serie limitata di terminologia specifica per web se si sa in anticipo che l'applicazione si baserà su web. Altrimenti, si corre il rischio che il testo del caso d'uso venga percepito come troppo astratto. Le parole da includere nella terminologia potrebbero essere "navigare", "sfogliare", "collegamento ipertestuale" "pagina", "inoltrare" e "browser". Tuttavia, non è consigliabile includere dei riferimenti a "frame" o "pagine web" in modo tale da presupporre dei boundary fra di essi - questa è una decisione di progettazione piuttosto critica.  
  • Descrivere il flusso di eventi, non solo la funzionalità. Per rafforzare questo concetto, iniziare ogni azione con "Quando l'attore... ".
  • Descrivere solo gli eventi che appartengono al caso d'uso e non quello che accade in altri casi d'uso o fuori dal sistema.
  • Evitare la terminologia vaga.
  • Descrivere in dettaglio il flusso di eventi (devono essere date delle risposte a tutti i "cosa". Ricordarsi che i progettisti di test utilizzeranno questo testo per identificare gli scenari di test.

Se sono stati utilizzati determinati termini in altri casi d'uso, accertarsi di utilizzare gli stessi termini in questo caso d'uso e che il loro significato sia lo stesso. Per gestire i termini comuni, collocarli in un glossario.

Flusso di eventi - Struttura Inizio pagina

Le due parti principali del flusso di eventi sono il flusso di eventi base ed i flussi di eventi alternativi. Il flusso di eventi base deve riguardare quello che "normalmente" accade quando viene eseguito il caso d'uso. I flussi di eventi alternativi riguarda il comportamento di un carattere facoltativo o eccezionale in relazione al normale comportamento, ed anche le variazioni rispetto al comportamento normale. I flussi di eventi alternativi si possono considerare come delle "deviazioni" dal flusso di eventi base, alcuni dei quali torneranno al flusso di eventi base ed altri termineranno l'esecuzione del caso d'uso.

Diagramma descritto nella figura.

La tipica struttura del flusso di eventi. La freccia diritta rappresenta il flusso di eventi base e le curve rappresentano i percorsi alternativi in relazione a quello normale. Alcuni percorsi alternativi ritornano al flusso di eventi base, mentre altri terminano il caso d'uso.

Sia il flusso di eventi base che quelli alternativi devono essere strutturati ulteriormente in fasi o flussi secondari. Facendo questo, l'obiettivo principale deve essere la leggibilità del testo (consultare anche la sezione Flusso di eventi - Stile riportata di seguito). Una regola pratica è che un flusso secondario deve essere un segmento di comportamento all'interno del caso d'uso, che disponga di uno scopo chiaro e sia "atomico", nel senso che devono essere eseguite tutte le azioni descritte o nessuna. Potrebbero essere necessari vari livelli di flussi secondari, ma se possibile è meglio evitarli poiché rende il testo più complesso e difficile da capire. È possibile illustrare la struttura del flusso di eventi con un diagramma di attività, (vedere la Linee guida per il prodotto di lavoro: Diagramma delle attività nel caso d'uso.

Questo tipo di testo scritto, strutturato in sezioni secondarie consecutive, implica, per sua natura, che esiste una sequenza fra i flussi secondari. Per evitare fraintendimenti, indicare sempre se l'ordine dei flussi secondari è fisso o meno. Considerazioni di questo tipo sono spesso correlate a:

  • Regole di business. Ad esempio, l'utente deve essere autorizzato prima che il sistema possa rendere disponibili determinati dati.
  • Progettazione dell'interfaccia utente. Ad esempio, il sistema non deve applicare una determinata sequenza di comportamento che potrebbe essere intuitiva per alcuni ma non per altri utenti.

Per chiarire come si colloca nella struttura un flusso alternativo di eventi è necessario descrivere quanto segue ad ogni "deviazione" dal flusso di eventi base:

  • Dove, nel flusso di eventi base, può essere inserito il comportamento alternativo.
  • La condizione che necessita di essere soddisfatta perché possa iniziare il comportamento alternativo.
  • In che modo e dove può essere ripreso il flusso di eventi base, oppure in che modo termina il caso d'uso.

Esempio:

Questo è un flusso secondario alternativo nel caso d'uso Restituisci articoli, nel Sistema della macchina per il riciclaggio.

2.1. Bottiglia incastrata

Se nella sezione 1.5, Inserire articoli da depositare, una bottiglia rimane incastrata nell'ingresso, i sensori intorno all'ingresso e l'ingresso di misurazione rileveranno il problema. Il nastro trasportatore viene arrestato e la macchina emette un segnale acustico per chiamare l'operatore. La macchina attenderà che l'operatore indichi che il problema è stato risolto. La macchina, quindi, continua con la sezione 1.9 del flusso base.

Nell'esempio riportato il flusso alternativo di eventi viene inserito in una posizione specifica del flusso base di eventi. Esistono anche dei flussi alternativi di eventi che possono essere inseriti in più di una posizione, alcuni addirittura in una posizione qualunque del flusso base di eventi.

Esempio:

Questo è un flusso secondario alternativo nel caso d'uso Restituisci articoli, nel Sistema della macchina per il riciclaggio.

2.2. Il pannello frontale è stato rimosso

Se qualcuno rimuove il pannello frontale della macchina di riciclaggio, la compressione delle lattine viene disattivata. Non sarà possibile avviare la compressione delle lattine senza il pannello frontale al suo posto. La rimozione attiva anche un segnale acustico per l'operatore. Quando il pannello frontale viene richiuso, la macchina riprende l'operazione dal punto in cui era stata interrotta, nel flusso base di eventi.

Potrebbe essere allettante, se si tratta di un flusso alternativo di eventi molto semplice, descriverlo semplicemente nella sezione del flusso base di eventi (utilizzando un costrutto informale di tipo "if-then-else"). Questo è da evitare. Troppe alternative rendono difficile l'individuazione del comportamento normale. Inoltre, l'inclusione dei percorsi alternativi nella sezione del flusso base di eventi rende il testo più "simile al codice" e difficile da leggere.

In generale, estrarre delle parti del flusso di eventi e descriverle separatamente può aumentare la leggibilità del flusso base di eventi e migliorare la struttura del caso d'uso ed il modello di casi d'uso. È possibile modellare le parti estratte come:

  • Flusso alternativo di eventi all'interno del caso d'uso base, se si tratta di una semplice variante, opzione o eccezione al flusso base di eventi.
  • Inclusione esplicita nel caso d'uso base (consultare Linee guida per il prodotto di lavoro: Includi-Relazione), se si tratta di qualcosa che si desidera incapsulare in modo tale da poter essere riutilizzata da altri casi d'uso.
  • Inclusione implicita nel caso d'uso base (consultare Linee guida per il prodotto di lavoro: Estendi-Relazione), se il flusso base di eventi del caso d'uso base è completo, cioè se dispone di un inizio e di una fine definiti. La natura del flusso estensibile deve essere tale da preferire di celarlo nella descrizione del caso d'uso base per renderlo meno complesso.
  • Flusso secondario nel flusso base di eventi, possibilmente come altra opzione, se nessuna delle alternative riportate è valida. Ad esempio, in un caso d'uso Conserva informazioni sul dipendente, potrebbero esistere dei flussi secondari separati per aggiungere, eliminare o modificare le informazioni su un dipendente.

Flusso di eventi - Stile Inizio pagina

È possibile descrivere i casi d'uso in molti stili. Come esempio, viene mostrato il flusso base di eventi del caso d'uso Impartire ordine, descritto in tre stili diversi, variando principalmente la formalità dello stile. Il primo stile, mostrato nell'esempio 1, è consigliato, poiché è facile da capire e l'ordine in cui accadono le cose è chiaramente evidente. Il testo è suddiviso in sezioni secondarie numerate e denominate. I numeri sono presenti per facilitare il riferimento ad una sezione secondaria. I nomi delle sezioni secondarie consentono al lettore di farsi una rapida idea del flusso di eventi, esplorando il testo e leggendo solo le intestazioni.

Nell'esempio 2, la descrizione del flusso di eventi non riesce a chiarire l'ordine in cui si verificano le cose. Se si scrive in questo stile, si potrebbero perdere dei particolari importanti che concernono il sistema.

L'esempio 3 mostra ancora un altro stile, che può essere utile se si ha difficoltà nell'esprimere chiaramente la sequenza di eventi. Questo stile simile a del codice è più preciso ma il testo è difficile da leggere e da assorbire per una persona non tecnica, specialmente se si desidera cogliere il flusso di eventi rapidamente.

Esempio 1:
1.1. Inizio del caso d'uso

Questo caso d'uso inizia quando l'attore Operatore indica al sistema di creare un ordine di misurazione. Il sistema richiama tutti gli attori Elemento di rete, i relativi oggetti di misurazione e le funzioni di misurazione corrispondenti disponibili per questo particolare Operatore. Gli elementi di rete disponibili sono quelli operativi e per i quali l'Operatore dispone dell'autorizzazione all'accesso. La disponibilità delle funzioni di misurazione dipende da cosa è stato configurato per un tipo particolare di oggetto di misurazione.

1.2. Configura ordine di misurazione

Il sistema consente all'attore Operatore di selezionare quali Elementi di rete misurare e mostra quali oggetti di misurazione sono disponibili per gli elementi di rete selezionati. Il sistema consente all'Operatore di effettuare una selezione fra gli oggetti di misurazione, e poi di scegliere quali funzioni di misurazione configurare per ciascun oggetto di misurazione.

Il sistema consente all'operatore di immettere un commento sotto forma di testo sull'ordine di misurazione.

L'Operatore indica al sistema di completare l'ordine di misurazione. Il sistema risponderà generando un nome univoco per l'ordine di misurazione ed impostando dei valori predefiniti relativi a quando, quanto spesso e per quanto tempo devono essere effettuate le misurazioni. I valori predefiniti sono univoci per ogni Operatore. Il sistema quindi consente all'Operatore di modificare i valori predefiniti.

1.3. Inizializza ordine

L'operatore indica al sistema di inizializzare l'ordine di misurazione. Il sistema registra l'identità dell'Operatore creante, la data di creazione e lo stato "Pianificato" dell'ordine di misurazione.

1.4. Termina il caso d'uso

Il sistema conferma all'operatore l'inizializzazione dell'ordine di misurazione, e quest'ultimo viene reso disponibile per essere visualizzato da altri attori.


Descrizione di un caso d'uso: in questo stile il testo è semplice da leggere ed il flusso di eventi facile da seguire. Nelle descrizioni utilizzare questo stile.

Esempio 2:
Gli Ordinatori possono creare degli ordini per raccogliere i dati di misurazione dagli elementi di rete.

Il sistema assegnerà all'ordine un nome univoco ed i valori predefiniti che indicano la lunghezza ed i tempi di misurazione, ed anche ogni quanto deve essere ripetuto. L'Ordinatore è in grado di modificare questi valori.

L'Ordinatore deve inoltre specificare quale funzione di misurazione, elemento della rete e oggetti misurazioni sono applicabili. L'Ordinatore può anche aggiungere un commento personale all'ordine.

Una volte definite le informazioni necessarie, viene creato un nuovo Ordine e viene inizializzato con gli attributi definiti, il nome del creatore e la data della creazione. Lo stato dell'ordine verrà impostato su "pianificato". (I possibili valori per lo stato sono: Pianificato, In esecuzione, Completato, Annullato ed Errato).

L'interfaccia utente viene informata della creazione del nuovo Ordine e riceve un riferimento al nuovo ordine in modo da poter essere visualizzato.


Descrizione di un caso d'uso: questo stile è leggibile ma non esiste un chiaro flusso di eventi.

Esempio 3:

'Impartisci ordine' (identità utente)
REPEAT
    <='Mostra menu Impartisci ordine'
    IF (=> 'Creazione di un ordine' (funzione di misurazione,
elemento di rete, oggetto di misurazione)) THEN
    Il sistema individua un nome univoco, i valori predefiniti relativi a quando e per quanto
tempo la misurazione deve essere eseguita.
<= 'Mostra ordine' (Attributi predefiniti)
REPEAT
    => 'Modifica ordine' (Attributo da modificare, Nuovo valore dell'attributo)
    <= 'Aggiorna schermata' (Nuovi attributi)
UNTIL (Tutti gli attributi sono definiti)
REPEAT
    IF (=> 'Modifica ordine' (Attributo da modificare, Nuovo valore dell'attributo))
THEN <= 'Aggiorna schermata' (Nuovi attributi)
ELSIF (=> 'Salva ordine' (Identità dell'ordine, Attributi)) THEN
    L'ordine viene creato ed inizializzato nel sistema con gli
    attributi definiti, il nome del creatore,
    la data di creazione e lo stato 'pianificato'.
    <= 'Nuovo ordine creato' (l'ordine)
ENDIF
UNTIL (=> 'Esci')
    ENDIF
UNTIL 'Esci da Impartisci ordine'

Descrizione di un caso d'uso: qui l'autore ha scelto uno stile formale utilizzando uno pseudo codice. Lo stile rende difficile cogliere rapidamente le fasi del processo ma può essere utile se il flusso di eventi è difficile da catturare in maniera precisa.

Flusso di eventi - Esempio

La descrizione completa del flusso di eventi del caso d'uso Impartisci ordine, inclusi i flussi alternativi, potrebbe avere il seguente aspetto:

1. Flusso base di eventi

1.1. Inizio del caso d'uso

Questo caso d'uso inizia quando l'attore Operatore indica al sistema di creare un ordine di misurazione. Il sistema richiama tutti gli attori Elemento di rete, i relativi oggetti di misurazione e le funzioni di misurazione corrispondenti disponibili per questo particolare Operatore. Gli elementi di rete disponibili sono quelli operativi e per i quali l'Operatore dispone dell'autorizzazione all'accesso. La disponibilità delle funzioni di misurazione dipende da cosa è stato configurato per un tipo particolare di oggetto di misurazione.

1.2. Configura ordine di misurazione

Il sistema consente all'attore Operatore di selezionare quali Elementi di rete misurare e mostra quali oggetti di misurazione sono disponibili per gli elementi di rete selezionati. Il sistema consente all'Operatore di effettuare la selezione fra questi oggetti di misurazione e quindi di scegliere quali funzioni di misurazione configurare per ciascun oggetto di misurazione.

Il sistema consente all'operatore di immettere un commento sotto forma di testo sull'ordine di misurazione.

L'Operatore indica al sistema di completare l'ordine di misurazione. Il sistema risponderà generando un nome univoco per l'ordine di misurazione ed impostando dei valori predefiniti relativi a quando, quanto spesso e per quanto tempo devono essere effettuate le misurazioni. I valori predefiniti sono univoci per ogni Operatore. Il sistema quindi consente all'Operatore di modificare i valori predefiniti.

1.3. Inizializza ordine

L'operatore indica al sistema di inizializzare l'ordine di misurazione. Il sistema registra l'identità dell'Operatore creante, la data di creazione e lo stato "Pianificato" dell'ordine di misurazione.

1.4. Termina il caso d'uso

Il sistema conferma all'operatore l'inizializzazione dell'ordine di misurazione, e quest'ultimo viene reso disponibile per essere visualizzato da altri attori.

2. Flussi alternativi di eventi

2.1. Non sono disponibili elementi di rete

Se in 1.1, Inizio del caso d'uso, si verifica che non sono disponibili degli elementi di rete da misurare per questo Operatore, il sistema informa l'Operatore. Il caso d'uso quindi termina.

2.2. Non sono disponibili funzioni di misurazione

Se in 1.2, Configura ordine misurazione, non sono disponibili delle funzioni di misurazione per gli elementi di rete selezionati, il sistema informa l'Operatore e gli consente di selezionare degli altri elementi di rete.

2.3. Annulla ordine di misurazione

Il sistema consente all'Operatore di annullare tutte le azioni in qualsiasi momento, durante l'esecuzione del caso d'uso. Il sistema tornerà allo stato in cui si trovava prima dell'avvio del caso d'uso terminerà il caso d'uso.

Requisiti speciali Inizio pagina

Nei requisiti speciali di un caso d'uso, vengono descritti tutti i requisiti relativi al caso d'uso che non sono considerati dal flusso di eventi. Si tratta di requisiti non funzionali che influenzano il modello di progettazione. Consultare anche la trattazione relativa ai requisiti non funzionali contenuta in Linee guida per il prodotto di lavoro: Modello di casi d'uso. È possibile organizzare questi requisiti in categorie, come l'utilizzabilità, l'affidabilità, le prestazioni e la sostituibilità, ma in genere ne sono presenti talmente pochi che un simile raggruppamento non aggiunge un valore particolare.

Esempio:

Nel Sistema della macchina per il riciclaggio, un requisito speciale del caso d'uso Restituisci articoli da depositare potrebbe essere:

La macchina deve essere in grado di riconoscere gli articoli da depositare con un'affidabilità di più del 95 percento.

Pre-condizioni e post-condizioni

Può essere utile usare la nozione di pre-condizione e post-condizione per chiarire come inizia e come termina il flusso di eventi. Tuttavia, utilizzarla solo se viene percepita come valore aggiunto dall'audience del caso d'uso.

Diagramma descritto nella figura.

Una pre-condizione è lo stato del sistema e del suo ambiente richiesta prima di poter avviare il caso d'uso. Una post-condizione sono gli stati in cui può trovarsi il sistema una volta terminato il caso d'uso.

Considerare quanto segue:

  • Gli stati descritti dalle pre-condizioni o dalle post-condizioni devono essere degli stati che l'utente possa osservare. "L'utente si è collegato al sistema" o "L'utente ha aperto il documento" sono degli esempi di stati osservabili.
  • Una pre-condizione è un vincolo relativo all'inizio del caso d'uso. Non si tratta dell'evento che avvia il caso d'uso.
  • Una pre-condizione per un caso d'uso non è relativa solo ad un flusso secondario, anche se è possibile definire delle pre-condizioni e delle post-condizioni a livello del flusso secondario.
  • Una post-condizione per un caso d'uso deve essere vera (true) a prescindere da quali flussi alternativi sono stati eseguiti; non deve essere valida solo per il flusso principale. Se qualcosa potrebbe non riuscire, è possibile specificarlo nella post-condizione affermando "L'azione è completata oppure, se si è verificato un errore, l'azione non è stata eseguita", piuttosto che un semplice "L'azione è stata completata".
  • Quando si utilizzano le post-condizioni insieme alle relazioni di estensione, è necessario far sì che il caso d'uso che si estende non introduca un flusso secondario che viola la post-condizione del caso d'uso di base.
  • Le post-condizioni possono essere un potente tool per la descrizione dei casi d'uso. Prima si definisce cosa deve ottenere il caso d'uso (la post-condizione). Poi è possibile descrivere come ottenere quella condizione (il flusso di eventi necessario).

Esempio:

Una pre-condizione per il caso d'uso Prelievo di contanti al bancomat: il cliente dispone di una carta personale, adatta al lettore di carte, è stato emesso un numero di PIN ed è registrata presso il sistema bancario.

Una post-condizione per il caso d'uso Prelievo di contanti al bancomat: al termine del caso d'uso tutti i log del conto e della transazione vengono sincronizzati, le comunicazioni con il sistema bancario vengono reinizializzate e al cliente viene restituita la carta.

Punti di estensione

Un punto di estensione apre il caso d'uso alla possibilità di un'estensione. Dispone di un nome e di un elenco di riferimenti a una o più posizioni all'interno del flusso di eventi del caso d'uso. Un punto di estensione può far riferimento ad una singola posizione fra due fasi del comportamento all'interno del caso d'uso. Può anche far riferimento ad un insieme di posizioni discrete.

L'uso di punti di estensione denominati è utile per separare la specifica del comportamento del caso d'uso che si estende dai dettagli interni del caso d'uso base. Il caso d'uso base può essere modificato o riorganizzato, finché i nomi dei punti di estensione restano gli stessi non verrà influenzato il caso d'uso che si estende. Allo stesso tempo, non si appesantisce il testo descrivendo il flusso di eventi del caso d'uso base con i dettagli su dove il comportamento potrebbe estendersi. Consultare anche Linee guida per il prodotto di lavoro: Relazione di estensione.

Esempio:

In un sistema di telefonia, il caso d'uso Effettua chiamata può essere esteso dal caso d'uso Mostra identità del chiamante. Si tratta di un servizio opzionale, spesso denominato "ID chiamante", che può essere o non essere stato richiesto dalla parte ricevente. Una descrizione del punto di estensione nel caso d'uso Effettua chiamata potrebbe essere:

Nome: Mostra identità

Posizione: dopo la sezione 1.9 Squilla telefono della parte ricevente.

Diagrammi dei casi d'uso

È possibile scegliere di illustrare in un diagramma di casi d'uso come un caso d'uso si relazioni con gli attori e con gli altri casi d'uso (in casi non usuali, più di un diagramma), che appartiene al caso d'uso. Ciò è utile se il caso d'uso è implicato con molti attori oppure se dispone di relazioni con molti altri casi d'uso. Un diagramma di questo tipo è di carattere "locale", poiché mostra il modello di casi d'uso dalla prospettiva di un solo caso d'uso e non è rivolto a spiegare i fatto generici relativi all'intero modello di caso d'uso. Consultare anche Linee guida per il prodotto di lavoro: Diagramma dei casi d'uso.