Linea guida: Modello del caso d'uso
Un modello di caso d'uso è un modello delle funzioni previste del sistema e dei relativi ambiti e serve da contratto fra il cliente e gli sviluppatori. Questa linea guida è una tabella di marcia per lo sviluppo di un modello di casi d'uso.
Relazioni
Descrizione principale

Spiegazione

Un modello di casi d'uso è un modello delle funzioni previste del sistema e del suo ambiente e serve da contratto fra il cliente e gli sviluppatori. I casi d'uso servono da thread unificatore in tutto lo sviluppo del sistema. Lo stesso modello di casi d'uso è il risultato della disciplina Requisiti e viene utilizzato come input per le discipline Analisi e progettazione e Test.

il diagramma riportato di seguito mostra una parte di un modello di casi d'uso per il sistema della macchina per il riciclaggio.

Diagramma descritto nella figura.

Un diagramma di casi d'uso con un esempio di modello di casi d'uso con attori e casi d'uso.

Esistono molti modi per modellare un sistema, ognuno dei quali può servire ad uno scopo diverso. Tuttavia, lo scopo più importante di un modello di casi d'uso è di trasmettere il comportamento del sistema al cliente o all'utente. Di conseguenza il modello deve essere di facile comprensione.

Gli utenti e qualsiasi altro sistema interagisca con il sistema, sono degli attori. Poiché rappresentano gli utenti del sistema, gli attori sono utili per delimitare il sistema e fornire un quadro più chiaro di cosa debba svolgere. I casi d'uso vengono sviluppati sulla base delle esigenze degli attori. Questo fa sì che il sistema diventi quello che gli utenti si aspettano.

Come si evolve il modello di casi d'uso

Sia gli attori che i casi d'uso vengono individuati utilizzando come informazioni vitali i requisiti dei clienti e dei potenziali utenti. Una volta individuati, i casi d'uso e gli attori devono essere brevemente descritti. Prima di descrivere i casi d'uso in dettaglio, il modello dei casi d'uso deve essere rivisto dal cliente, per verificare che siano stati individuati tutti i casi d'uso e gli attori, e che insieme forniscano quello che il cliente desidera.

In un ambiente di sviluppo iterativo, si seleziona il sottoinsieme di casi d'uso che deve essere dettagliato in ciascuna iterazione. Consultare anche Compito: Priorità dei casi d'uso.

Quando sono stati individuati gli attori ed i casi d'uso, il flusso di eventi di ciascun caso d'uso viene descritto in dettaglio. Le descrizioni mostrano come il sistema interagisce con gli attori e cosa svolge in ciascun caso individuale.

Infine, il modello di casi d'uso completato (incluse le descrizioni dei casi d'uso) viene rivisto e gli sviluppatori ed i clienti lo utilizzano per concordare cosa deve essere in grado di fare il sistema.

Evitare la scomposizione funzionale

Non è insolito che il modello di casi d'uso degeneri in una scomposizione funzionale del sistema. Per evitare ciò, prestare attenzione ai seguenti sintomi:

  • Casi d'uso "piccoli", il che significa che la descrizione del flusso di eventi è composta soltanto da una o poche frasi.
  • "Molti" casi d'uso, significa che il numero di casi d'uso è un multiplo di un centinaio, piuttosto che un multiplo di dieci.
  • I nomi di casi d'uso che sono delle costruzioni come "effettuare questa operazione su questi particolari dati" o "eseguire questa funzione con questi particolari dati". Ad esempio, "Immettere numero identificativo personale in un bancomat" non deve essere modellato come caso d'uso separato per la macchina bancomat, poiché nessuno userebbe il sistema per fare solo quello. Un caso d'uso p un flusso di eventi completo che ha come risultato qualcosa che per un attore ha valore.

Per evitare la scomposizione funzionale accertarsi che il modello di casi d'uso sia utile per rispondere a domande come:

  • Qual è il contesto del sistema?
  • Perché il sistema viene creato?
  • Cosa desidera ottenere l'utente quando utilizza il sistema?
  • Che valore aggiunge il sistema agli utenti?

Requisiti non funzionali

E' abbastanza facile notare che i casi d'uso sono un buon metodo per catturare i requisiti funzionali su un sistema. Cosa accade con i requisiti non funzionali? Cosa sono e dove vengono catturati?

I requisiti non funzionali vengono spesso classificati come requisiti di utilizzabilità, affidabilità, prestazione sostituibilità (vedere anche Concetto: Requisito). Spesso si tratta di requisiti che specificano la necessità di conformità con qualsiasi requisito legale e di regolamentazione. Possono anche essere dei vincoli di progettazione a causa del sistema operativo usato, dell'ambiente della piattaforma, delle problematiche di compatibilità o di qualsiasi eventuale standard applicativo. In generale, si può affermare che qualsiasi requisito non consenta più di un'opzione di progettazione deve essere trattato come un vincolo di progettazione.

Molti requisiti non funzionali riguardano un caso d'uso individuale e vengono catturati all'interno delle proprietà di quel caso d'uso. In tal caso, vengono catturati nel flusso di eventi del caso d'uso o come requisito speciale del caso d'uso (consultare Linee guida: Caso d'uso).

Esempio:

Nel sistema della macchina per il riciclaggio, un requisito non funzionale specifico per il caso d'uso Restituisci articoli di deposito potrebbe essere:

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

Spesso i requisiti non funzionali riguardano l'intero sistema. Questo tipo di requisiti viene catturato nelle specifiche supplementari (consultare Prodotto di lavoro: Specifiche supplementari).

Esempio:

Nel sistema della macchina per il riciclaggio, un requisito non funzionale che riguarda l'intero sistema potrebbe essere:

La macchina consentirà un solo utente alla volta.

Dilemma: 'Cosa' contro 'Come'

Una delle cose più difficili è imparare a determinare a quale livello di dettaglio devono "iniziare e terminare" i casi d'uso. Dove iniziano le funzioni ed iniziano i casi d'uso e dove terminano i casi d'uso ed inizia la progettazione? Spesso si dice che i casi d'uso o i requisiti software dovrebbero affermare "cosa" fa il sistema ma non "come". Considerare il seguente grafico:

Diagramma descritto nella figura.

La destinazione di una persona è il punto di inizio di un'altra.

A seconda del proprio background, si utilizzerà un contesto diverso per decidere cosa si ritiene che sia il "cosa" e il "come". Questo deve essere preso in considerazione quando si deve stabilire se tralasciare o meno un determinato dettaglio del modello di casi d'uso.

Esiste una distinzione fra casi d'uso concreti e astratti. Un caso d'uso concretoviene avviato da un attore ed è composto da un flusso di eventi completo. "Completo" significa che un'istanza del caso d'uso esegue l'intera operazione richiamata dall'attore.

Non viene creata un'istanza di un caso d'uso astratto. I casi d'uso astratti vengono inclusi in altri casi d'uso (consultare Linee guida: Relazione di inclusione), si estendono in altri casi d'uso (consultare Linee guida: Relazione di estensione) o generalizzano altri casi d'uso (consultare Linee guida: Generalizzazione del caso d'uso). Quando viene iniziato un caso d'uso concreto, viene creata un'istanza del caso d'uso. L'istanza esibisce anche il comportamento specificato dai casi d'uso astratti associati. Quindi non vengono create delle istanze separate dai casi d'uso astratti.

La distinzione fra i due è importante poiché sono i casi d'uso concreti che gli attori "vedranno" ed avvieranno nel sistema.

Si indica che un caso d'uso è astratto scrivendone il nome in corsivo.

Esempio:

Diagramma descritto nella figura.

Il caso d'uso Crea compito è incluso nel caso d'uso Registra ordine. Crea compito è un caso d'uso astratto.

Nel sistema Gestione magazzino il caso d'uso astratto Crea compito è incluso nel caso d'uso Registra ordine. Quando viene avviato Registra ordine, viene creata un'istanza di Registra ordine che, oltre a seguire il flusso di eventi di Registra ordine, segue anche quello descritto nel caso d'uso incluso, Crea compito. Crea compito non viene mai eseguito per conto proprio ma sempre come parte di Registra ordine (o di qualsiasi altro caso d'uso in cui è incluso). Crea compito è quindi un caso d'uso astratto.

Strutturazione del modello di casi d'uso

I motivi principali per la strutturazione del modello di caso d'uso sono tre:

  • Facilitare la comprensione dei casi d'uso.
  • Separare il comportamento comune descritto in molti casi d'uso
  • Semplificare la gestione del modello di casi d'uso.

La strutturazione, tuttavia, non è la prima cosa di cui occuparsi. Non ha senso strutturare i casi d'uso finché non si conosce maggiormente il loro comportamento, oltre ad una breve descrizione composta da una frase. Si deve almeno aver stabilito una struttura in fasi per il flusso di eventi del caso d'uso, per essere sicuri che le decisioni siano basate su una comprensione sufficientemente accurata del comportamento.

Per strutturare i casi d'uso esistono tre tipi di relazioni. Queste relazioni verranno utilizzate per scomporre delle parti dei casi d'uso che possono essere riutilizzate in altri casi d'uso o che sono delle specializzazioni o opzioni per il caso d'uso. Il caso d'uso che rappresenta la modifica viene denominato il caso d'uso di aggiunta. Il caso d'uso modificato viene denominato il caso d'uso base.

  • Se è presente una parte di un caso d'uso base che rappresenta una funzione in cui il caso d'uso dipende solo dal risultato, non dal metodo utilizzato per produrre il risultato, è possibile ridurre in fattori quella parte e collocarla in un caso d'uso di aggiunta. L'aggiunta viene esplicitamente inserita nel caso d'uso base, utilizzando la relazione di inclusione (include). Consultare anche Linee guida: Relazione di inclusione.
  • Se è presente una parte del caso d'uso base che è facoltativa o non necessaria per conoscere lo scopo primario del caso d'uso, è possibile rendere quella parte in fattori e collocarla in un caso d'uso di aggiunta, per poter semplificare la struttura del caso d'uso base. L'aggiunta viene semplicemente inserita nel caso d'uso base, utilizzando la relazione di estensione (extend). Consultare anche Linee guida: Relazione di estensione.
  • Se esistono dei casi d'uso che hanno delle accomunanze nel comportamento e nella struttura e similitudini nello scopo, le loro parti comuni possono essere rese in fattori nel caso d'uso base (parent) che viene ereditato dai casi d'uso di aggiunta (i child). I casi d'uso child possono inserire del nuovo comportamento e modificare quello esistente nella struttura ereditata dal caso d'uso parent. Consultare anche Linee guida per il prodotto di lavoro: Caso d'uso-Generalizzazione.

È possibile utilizzare la generalizzazione attore per mostrare come gli attori siano una specializzazione l'uno dell'altro. Consultare anche Linee guida: Generalizzazione attore.

Esempio:

Si consideri una parte del modello di caso d'uso di un Sistema di gestione ordini.

E' utile separare il cliente ordinario dal cliente Internet, poiché hanno proprietà leggermente diverse. Tuttavia, poiché il cliente Internet mostra tutte le proprietà del cliente ordinario, è possibile considerare il cliente Internet come una specializzazione del cliente ordinario, indicato da una generalizzazione attore.

I casi d'uso concreti di questo diagramma sono Ordine telefonico (avviato dall'attore Cliente) e Ordine internet (avviato da Cliente internet). Questi casi d'uso sono entrambi delle variazioni del caso d'uso più generico Effettua ordine, che in questo esempio è astratto. Il caso d'uso Richiesta catalogo rappresenta un segmento facoltativo del comportamento che non fa parte dello scopo primario di Effettua ordine. E' stato ridotto in fattori in un caso d'uso astratto per semplificare il casto d'uso Effettua ordine. Il caso d'uso Fornisci dati cliente rappresenta un segmento del comportamento che era stato ridotto in fattori perché è una funzione separata della quale solo il risultato influenza il caso d'uso Effettua ordine. Anche il caso d'uso Fornisci dati cliente può essere riutilizzato in altri casi d'uso. In questo esempio sono astratti sia Richiesta catalogo che Fornisci dati cliente.

Diagramma descritto nella figura.

Questo diagramma di caso d'uso mostra parte del modello di casi d'uso di un Sistema di gestione ordini.

La tabella riportata di seguito mostra un confronto più dettagliato fra le tre diverse relazioni di caso d'uso:

Domanda Extend Include Generalizzazione
Qual'è la direzione della relazione? Il caso d'uso di aggiunta fa riferimento al caso d'uso base. Il caso d'uso base fa riferimento al caso d'uso di aggiunta. Il caso d'uso di aggiunta (child) fa riferimento al caso d'uso base (parent).
La relazione dispone molteplicità? Sì, nella parte di aggiunta. No. Se si desidera includere lo stesso segmento di comportamento più di una volta deve essere stabilito nel caso d'uso base. No.
La relazione dispone di una condizione? Sì. No. Se si desidera esprimere una condizione nell'inclusione è necessario dirlo esplicitamente nel caso d'uso base. No.
Il caso d'uso di aggiunta è astratto? Spesso sì, ma non necessariamente. Sì. Spesso no, ma può esserlo.
Il caso d'uso base viene modificato dall'aggiunta? L'estensione modifica implicitamente il comportamento del caso d'uso base. L'inclusione modifica esplicitamente l'effetto del caso d'uso base. Se il caso d'uso base (parent) viene istanziato, non viene influenzato dal child. Per ottenere gli effetti dell'aggiunta, il caso d'uso di aggiunta (child) deve essere istanziato.
Il caso d'uso base deve essere completo e significativo? Sì. Insieme alle aggiunte, sì. Se è astratto, no.
Il caso d'uso di aggiunta deve essere completo e significativo? No. No. Insieme al caso d'uso base (parent), sì.
Il caso d'uso di aggiunta può accedere agli attributi del caso d'uso base? Sì. No. L'inclusione è incapsulata e si "vede" soltanto. Sì, tramite i normali meccanismi di ereditarietà.
Il caso d'uso base può accedere agli attributi del caso d'uso di aggiunta? No. Il caso d'uso base deve essere ben formulato in assenza dell'aggiunta. No. Il caso d'uso base conosce solo l'effetto dell'aggiunta. L'aggiunta è incapsulata. No. Il caso d'uso base (parent) in questo senso deve essere ben formulato in assenza dell'aggiunta (child).

Un'altro aspetto dell'organizzazione del modello di casi d'uso per una più facile comprensione è di raggruppare i casi d'uso in pacchetti. Il modello di casi d'uso può essere organizzato come una gerarchia di pacchetti di casi d'uso, con le "foglie" che sono attori o casi d'uso. Consultare anche Linee guida: Pacchetto di casi d'uso.

Diagramma descritto nella figura.

Questo grafico mostra la gerarchia del modello di casi d'uso. Le frecce indicano una possibile proprietà.

I casi d'uso sono sempre correlati ad attori?

L'esecuzione di ogni caso d'uso include la comunicazione con uno o più attori. Un'istanza di caso d'uso viene sempre avviata da un attore che chiede al sistema di svolgere qualcosa. Questo implica ogni caso d'uso deve avere comunicazioni-associazioni con attori. Il motivo di questa regola è di forzare il sistema a fornire la funzionalità di cui necessitano gli utenti, null'altro. Avere dei casi d'uso che nessuno richiede è un'indicazione che qualcosa è sbagliato nel modello di casi d'uso o nei requisiti.

Tuttavia esistono delle eccezioni a questa regola:

  • Se un caso d'uso è astratto (non istanziabile separatamente), il suo comportamento potrebbe non includere l'interazione con alcun attore. In quel caso, non ci saranno comunicazioni-associazioni ad attori da quel caso d'suo astratto.
  • Un caso d'uso child in una relazione di generalizzazione non deve avere un attore associato se il caso d'uso parent descrive la comunicazione di tutti gli attori.
  • Un caso d'uso base in una relazione di inclusione non deve avere un attore associato se il caso d'uso d'inclusione descrive la comunicazione di tutti gli attori.
  • Un caso d'uso può essere avviato in base ad una pianificazione (ad esempio, una volta a settimana o una volta al giorno), il che significa che l'orologio di sistema è l'iniziatore. L'orologio di sistema è interno al sistema - ed il caso d'uso non viene avviato da un attore ma da un evento interno di sistema. Se non si verifica nessun altra interazione di attori nel caso d'uso, non avrà associazioni associazioni ad attori. Tuttavia, per chiarezza, è possibile utilizzare un attore fittizio "Tempo" per mostrare come viene avviato il caso d'uso nei diagrammi.

Descrizione dell'indagine

La descrizione dell'indagine sul modello di caso d'uso deve:

  • Indicare quali sono i casi d'uso primari del sistema (il motivo per cui il sistema è stato costruito).
  • Riassumere fatti tecnici importanti sul sistema.
  • Evidenziare i limiti del sistema (cose che non sono compito del sistema).
  • Riassumere l'ambiente del sistema, ad esempio, le piattaforme di destinazione ed il software esistente.
  • Descrivere eventuali sequenze in cui i casi d'uso vengono eseguiti in genere nel sistema.
  • Specificare la funzionalità non gestita dal modello di casi d'uso.

Esempio:

Quello che segue è un esempio di descrizione dell'indagine relativa al modello di casi d'uso Macchina per il riciclaggio:

Questo modello contiene tre attori e tre casi d'uso. Il caso d'uso primario è Ricicla articoli, che rappresenta lo scopo principale della Macchina per il riciclaggio.

Casi d'uso di supporto:

  • Stampa report giornaliero, che consente ad un operatore di ottenere un prospetto di quanti articoli sono stati riciclati.

  • Gestisci articolo di deposito, che consente all'operatore di cambiare il valore di rimborso per un tipo di articolo di deposito o di aggiungere dei nuovi tipi di articoli di deposito.