Operazione: Trova Attore e casi d'uso
In questa attività vengono identificati gli attori ed i casi di utilizzo al fine di supportare i requisiti che vengono implementati. L'identificazione degli attori e dei casi di utilizzo definiscono esplicitamente l'ambito del sistema.
Discipline: Requisiti
Scopo

Lo scopo di questo compito è di:

  • Definire l'ambito del sistema - le attività gestite dal sistema e quelle gestite esternamente al sistema.
  • Definire tutte le risorse che interagiranno con il sistema.
  • Descrivere la funzionalità del sistema.
Relazioni
Descrizione principale

Una tecnica molto utile per individuare gli attori ed i casi d'uso è di tenere un Workshop sul caso d'uso.

Passi
Ricerca di attori

L'individuazione degli attori è una delle prime fasi nel definire l'uso del sistema. Ogni tipo di risorsa esterna con cui il sistema deve interagire è rappresentata da un attore. Per individuare gli attori, effettuare le seguenti domande:

  • Quali gruppi di utenti richiedono l'assistenza del sistema per eseguire le loro attività?
  • Quali gruppi di utenti sono richiesti per eseguire le maggiori principali funzioni del sistema?
  • Quali gruppi di utenti sono richiesti per eseguire le funzioni secondarie, come la manutenzione e l'amministrazione del sistema?
  • Il sistema dovrà interagire con un sistema software o hardware esterno?

Una qualsiasi persona, gruppo o risorsa che si adatta a una o più di queste categorie è un candidato come attore.

Per determinare se si dispone degli attori (persone) giusti, si può fornire il nome di due o tre persone che possono fungere da attori e quindi decidere se la serie di attori è sufficiente per le loro necessità. Per maggiori informazioni sugli elementi che costituiscono un attore, consultare la sezione Linea guida: Attore.

Si potrebbe inizialmente rilevare difficile individuare gli attori più adatti e probabilmente non tutti saranno immediatamente individuati poiché non tutti i casi di utilizzo sono stati identificati. L'impiego dei casi di utilizzo è l'unico mezzo per apprendere maggiormente l'ambiente del sistema e come interagisce con il sistema. Quando si raggiunge tale stato di avanzamento nella progettazione, si potrebbe volere revisionare il modello originale, poiché vi è una tendenza a impegnare inizialmente troppi attori. Occorre prestare attenzione quando si cambiano gli attori; le modifiche apportate possono anche influire sui casi di utilizzo. E' importante ricordare che una qualsiasi modifica agli attori costituisce una principale alterazione delle interfacce e della funzionalità del sistema. Se sono stati sviluppati un modello caso d'uso business e un modello analisi di business, è possibile utilizzarli come fonti per l'identificazione dei principali attori.

Il nome dell'attore deve chiaramente identificare il ruolo dell'attore. Accertarsi che vi sia un rischio minimo di confondere il nome di un attore con un altro in una fase successiva.

Definire ciascun attore immettendo una breve descrizione che includa l'area di responsabilità dell'attore e il motivo di utilizzo del sistema. Poiché gli attori rappresentano risorse esterne al sistema, non è necessario descriverli in dettaglio. Consultare anche la sezione Breve descrizione in Linea guida: Attore.

Ricerca dei casi d'uso

Quando il primo schema degli attori è completo, la successiva fase è quella di individuare i casi di utilizzo del sistema. I primi casi d'uso sono molto preparatori e dovranno essere certamente modificati un paio di volte per essere stabili. Se l'impostazione o i requisiti del sistema sono carenti oppure se l'analisi del sistema è approssimativa, la funzionalità del sistema non sarà stabile. Pertanto, occorre costantemente chiedersi se sono stati individuati i casi di utilizzo corretti. Inoltre, occorre essere pronti ad aggiungere, rimuovere, associare e dividuere i casi di utilizzo prima di giungere a una versione finale. Si avrà una maggiore conoscenza dei casi di utilizzo una volta che sono stati descritti in dettaglio.

Il modo migliore per individuare i casi di utilizzo è di considerare le risorse richieste da ciascun attore al sistema. E' importante ricordare che il sistema esiste unicamente per i propri utenti e pertanto deve basarsi sulle necessità dell'utente. Sarà possibile identificare gran parte delle necessità degli attori attraverso i requisiti funzionali eseguiti sul sistema. Per ciascun attore, persona o meno, è necessario porsi le seguenti domande:

  • Quali sono le attività principali che l'attore intenda fare eseguire al sistema?
  • L'attore vorrà creare, memorizzare, modificare, rimuovere o leggere i dati nel sistema?
  • L'attore dovrà informare il sistema di improvvise modifiche esterne?
  • L'attore deve essere informato di determinati eventi nel sistema?
  • L'attore eseguirà un avvio o arresto del sistema?

Le risposte a queste domande rappresentano i flussi di eventi che identificano i casi di utilizzo candidati. Non tutti costituiscono casi di utilizzo diversi; alcuni possono essere modellati come varianti dello stesso caso d'uso. Non è sempre facile dire quale sia una variante e quale sia un caso d'uso separato e distinto. Tuttavia, sarà più chiaro quando verranno descritti i flussi di eventi in dettaglio.

Diversamente dai requisiti, un modello aziendale della propria organizzazione (definito anche modello di business) è una preziosa fonte di input per la determinazione dei casi d'uso. Il modello aziendale descrive in che modo il sistema informativo può essere integrato nelle operazioni esistenti e fornisce delle ottime indicazioni sull'ambiente del sistema. Saranno inoltre disponibili dei concetti da definire nel modello aziendale poiché tale modello contiene degli "oggetti business" dell'azienda. Se è stato seguito il flusso di lavoro  Modellazione di business , si potrà disporre di un  modello caso d'uso di business  e un  modello analisi di business  da utilizzare come input.

Un sistema può disporre di diversi modelli possibili di casi di utilizzo. Il modo migliore per individuare il modello "ottimale" è di sviluppare due o tre modelli; scegliere quello desiderato e quindi svilupparlo successivamente. Inoltre, lo sviluppo di diversi modelli alternativi aiuta a conoscere meglio il sistema.

Una volta delineato il primo modello di caso d'uso, è necessario verificare che tale modello integri tutti i requisiti funzionali. Esaminare attentamente i requisiti per accertarsi che tutti i casi di utilizzo soddisfino tutti irequisiti.

Per maggiori informazioni sulla descrizione di un caso d'uso e dove reperirli, consultare le sezioni Linea guida: Modello caso d'uso e Linea guida: Caso d'uso.

Denominazione e breve descrizione dei casi d'uso trovati

Ciascun caso d'uso deve possedere un nome che indica l'obiettivo raggiunto dalle relative interazioni con l'attore (o più attori). Il nome potrebbe essere composto da diverse parole per essere compreso. Non è possibile assegnare lo stesso nome a due casi di utilizzo. Consultare anche la sezione Nome in Linea guida: Caso d'uso.

Definire ciascun caso d'uso immettendone una breve descrizione. Mentre si immette la descrizione, fare riferimento al glossario e, se necessario, definire nuovi concetti. Consultare anche la sezione Breve descrizione in Linea guida: Caso d'uso.

Descrizione del flusso di eventi

A questo punto, occorre anche scrivere una prima bozza del flusso di eventi del caso d'uso. Descrivere ciascun flusso di eventi del caso d'uso con brevi esempi di prestazioni, ma non andare nel dettaglio. La persona che successivamente specificherà il caso d'uso (anche se si tratta della stessa persona) avrà bisogno di questa descrizione guidata. Iniziare con il delineare il flusso base degli eventi e una volta stabilito ciò, aggiungere dei flussi alternativi.

Esempio:

La descrizione dettagliata iniziale del flusso di eventi del caso d'uso Ricicla articoli nel sistema di una macchina di riciclaggio potrebbe essere simile a quanto segue:

  • Il cliente preme il tasto "Avvio".
  • Il cliente inserisce gli articoli da depositare.
  • Il sistema verifica il tipo di articoli di deposito inseriti.
  • Il sistema incrementa il totale giornaliero dei tipi di articoli ricevuti.
  • Il cliente preme il tasto "Ricevuta".
  • Il sistema stampa la ricevuta.
Raccolta di requisiti aggiuntivi

Alcuni dei requisiti del sistema non possono essere assegnati a specifici casi d'uso; raccogliere questi requisiti nelle specifiche supplementari (consultare Prodotto di lavoro: Specifiche supplementari).

Descrizione dell'iterazione tra gli attori ed i casi d'uso

Poiché è importante mostrare in che modo gli attori sono associati al caso d'uso, è necessario, durante la ricerca di un caso d'uso, stabilire quali attori interagiranno con esso. Per fare ciò, è necessario definire un'associazione di comunicazione che sia percorribile nella stessa direzione come la trasmissione di segnale tra l'attore e il caso d'uso.

Le trasmissioni di segnale solitamente percorrono entrambe le direzioni. In questo caso, è necessario lasciare le associazioni di comunicazione percorribili in entrambe le direzioni. Definire per quanto possibile un'associazione di comunicazione per ogni coppia di attore e caso d'uso.

Inoltre, è necessario descrivere brevemente ciascuna associazione di comunicazione definita.

Per maggiori informazioni sulle associazioni di comunicazione, consultare la sezione Linee guida per il prodotto di lavoro: Associazione di comunicazione.

Pacchetti di casi d'uso e attori

Se il numero di attori e casi di utilizzo diventa troppo alto, effettuare una suddivisione in pacchetti di casi di utilizzo per semplificare la manutenzione del modello. Ciò rende il modello caso d'uso più facile da comprendere e agevola l'assegnazione delle responsabilità nel modello lasciando agli sviluppatori la gestione dei pacchetti di casi d'uso o attori.

Alcuni modi alternativi per creare i pacchetti dei casi d'uso è se:

  • Interagiscono con lo stesso attore.
  • Esistono relazioni di inclusione o estensione.
  • Sono tutti facoltativi e offerti dal sistema come insieme unico o meno.

Esistono anche altri modi; tuttavia, per conservare il modello intuitivo, è importante utilizzare una strategia definita quando si esegue la creazione dei pacchetti.

Per maggiori informazioni sui pacchetti dei casi d'uso, consultare la sezione Linee guida per il prodotto di lavoro: Pacchetto del caso d'uso.

Presentazione del modello caso d'uso nei diagrammi

E' possibile illustrare le relazioni esistenti tra i casi di utilizzo e gli attori, così come tra i casi di utilizzo associati, in diagrammi del modello caso d'uso. Questi diagrammi potrebbero contenere:

  • Attori appartenenti allo stesso pacchetto caso d'uso.
  • Un attore e tutti i casi di utilizzo con cui interagisce.
  • Casi di utilizzo che gestiscono le stesse informazioni.
  • Casi di utilizzo impiegati dallo stesso gruppo di attori.
  • Casi di utilizzo che sono spesso eseguiti in un'unica sequenza.
  • Casi di utilizzo che appartengono allo stesso pacchetto caso d'uso.
  • I più importanti casi di utilizzo. Un diagramma di questo genere può funzionare come riepilogo del modello e sarà probabilmente incluso nella vista del caso d'uso.
  • I casi di utilizzo sviluppati insieme (all'interno dello stesso incremento).

Ciascun diagramma deve essere posseduto da un pacchetto appropriato nel modello caso d'uso.

Per maggiori informazioni sui diagrammi del caso d'uso, consultare la sezione Linea guida: Diagramma del caso d'uso.

Sviluppo di una valutazione del modello caso d'uso

In questa fase viene sviluppata la descrizione della valutazione del modello caso d'uso.  Nella propria valutazione, accertarsi di includere quanto segue:

  • Sequenze tipiche in cui i casi di utilizzo sono impiegati dagli utenti.
  • La funzionalità non gestita dal modello caso d'uso.

Per maggiori informazioni sulla descrizione della valutazione del modello caso d'uso, consultare la relativa sezione in Linea guida: Modello caso d'uso.

Valutazione dei propri risultati

In questa fase occorre controllare il modello caso d'uso e accertarsi che il lavoro svolto sia nei tempi previsti, ma non revisionare il modello in dettaglio. Inoltre, è possibile controllare il modello caso d'uso mentre lo si sta utilizzando.  Per consigli specifici sugli argomenti da ricercare, consultare Elenco di controllo: Modello caso d'uso.

E' fondamentale che le persone esterne al team di sviluppo (ad esempio, utenti e clienti) approvino il modello caso d'uso in questa fase. Pertanto, è necessario coinvolgere gli utenti e i clienti nella revisione del modello caso d'uso prima di completare questa attività. E' possibile utilizzare la valutazione del modello caso d'uso ed i relativi diagrammi creati nella fase precedente come guida nelle proprie discussioni.

Le parti interessate dovranno stabilire:

  • Se sono stati identificati tutti i casi di utilizzo richiesti.
  • Se sono stati identificati tutti i casi di utilizzo non richiesti.
  • Se il comportamento di ciascun caso d'uso è eseguito nell'ordine giusto.
  • Se ciascun flusso di eventi del caso d'uso è completo come richiesto in questa fase.
  • Se la descrizione di valutazione del modello caso d'uso rende comprensibile il modello.
Considerazioni chiave
When executing the step: Develop a Survey of the Use-Case Model, you may want to consider generating the survey. For more information, see the Report: Use-Case Model Survey and Tool Mentor: Creating a Use-Case Model Survey Using Rational SoDA.
Ulteriori informazioni