Operazione: Analisi del caso d'uso
Questo compito illustra come sviluppare una realizzazione di caso d'uso a livello di analisi da un caso d'uso.
Scopo
  • Identificare le classi che eseguono un flusso di eventi del caso d'uso
  • Distribuire il comportamento del caso d'uso a queste classi utilizzando la realizzazione del caso d'uso di analisi
  • Identificare le responsabilità, gli attributi e le associazioni delle classi
  • Annotare l'utilizzo dei meccanismi strutturali
Relazioni
Passi
Creazione della realizzazione del caso d'uso di analisi
Scopo Creare l'elemento del modello usato per esprimere il comportamento del caso d'uso 

I casi d'uso rappresentano il punto focale della parte iniziale del lavoro di analisi e progettazione. Il Prodotto di lavoro: Realizzazione del caso d'uso funge da collegamento nella transizione tra i compiti con al centro i requisiti e quelli con al centro l'analisi/progettazione, consentendo di tracciare il comportamento dei modelli di analisi e progettazione fino al modello del caso d'uso e di organizzare le collaborazioni sulla base del suo concetto.

Se non già presente creare una realizzazione di caso d'uso di analisi nel modello di analisi per il Caso d'uso. Il nome deve essere uguale a quello del caso d'uso associato, ed è necessario stabilire una relazione "realizza" tra essi.

Per maggiori informazioni sulla realizzazione del caso d'uso, consultare Tecnica: Realizzazione caso d'uso.

Integrazione della descrizione del caso d'uso
Scopo Registrare ulteriori informazioni necessarie per la comprensione del comportamento interno richiesto del sistema a cui potrebbe mancare la descrizione del caso d'uso scritta per il cliente del sistema.  

La descrizione di ciascun caso d'uso non è sufficiente per trovare le classi di analisi ed i loro oggetti. Il cliente generalmente trova informazioni su ciò che avviene all'interno del sistema non interessanti, quindi si potrà evitare di includerle nella descrizione del caso d'uso. In questi casi la descrizione del caso d'uso è come quella di una 'scatola nera', in cui i dettagli interni delle funzionalità del sistema in risposta ad un'azione di un attore è mancante o descritta in modo sommario. Per trovare l'oggetto che esegue il caso d'uso si necessita di una descrizione a 'scatola bianca' delle funzionalità del sistema da una prospettiva interna.

Esempio

Nel caso di uno sportello Bancomat il cliente del sistema potrebbe voler dire

"Lo sportello Bancomat convalida la carta Bancomat del cliente."

Per descrivere il comportamento di autenticazione dell'utente da parte del sistema. Questa descrizione potrebbe essere sufficiente per il cliente, mentre non rende un'idea precisa di ciò che accade effettivamente all'interno dello sportello Bancomat.

Per fornire un'immagine interna del funzionamento del sistema a un livello di dettaglio tale da identificare gli oggetti, si potrebbe necessitare di ulteriori informazioni. Prendendo ad esempio l'attività di autenticazione della carta Bancomat, la descrizione estesa sarà:

"Lo sportello Bancomat invia il numero di conto del cliente ed il PIN alla rete Bancomat per la convalida. L'operazione avrà esito positivo se il numero cliente ed il PIN corrispondono, autorizzando il cliente all'esecuzione della transazione, altrimenti viene restituito un errore."

Questo livello di dettaglio fornisce un'idea chiara delle informazioni necessarie (numero di conto e PIN) e di chi si fa carico dell'autenticazione (la rete Bancomat, un attore nel modello del caso d'uso). Da queste informazioni si potranno identificare due oggetti potenziali (un oggetto Cliente, con gli attributi Numero conto e PIN, e l'interfaccia della rete Bancomat) e le loro responsabilità.

Esaminare la descrizione del caso d'uso per verificare se il comportamento interno del sistema è definito in modo chiaro. Questo non deve risultare ambiguo, così che sia chiaro ciò che il sistema dovrà fare. Non è necessario definire gli elementi inclusi nel sistema (oggetti) responsabili dell'esecuzione di un comportamento, basta una chiara definizione di ciò che deve essere fatto.

Tra le fonti di tali dettagli di informazione vi sono gli esperti di dominio che possono aiutare a definire cosa deve fare il sistema. Una buona domanda da fare, quando si considera un comportamento particolare del sistema, è "cosa significa per il sistema fare la tale cosa?". Se la risposta non è sufficiente sarà necessario scoprire ulteriori informazioni.

Vi sono le seguenti alternative per integrare la descrizione del Flusso di eventi:

  • Non descriverlo affatto. Questo potrebbe essere opportuno nel caso in cui si considerano i diagrammi di interazione auto esplicativi, o se il Flusso di eventi del caso d'uso corrispondente contiene una descrizione sufficiente.
  • Integrare la descrizione esistente del Flusso di eventi. Aggiungere ulteriori descrizioni al Flusso di eventi per le aree dove il testo esistente non è abbastanza chiaro riguardo le azioni che il sistema dovrebbe intraprendere.
  • Descriverlo come un flusso di testo completo, separarlo dalla descrizione del flusso di eventi del caso d'uso. È opportuno quando il comportamento interno del sistema ha poche somiglianze con il comportamento esterno. In questo caso è consentita una descrizione completamente separata, associata alla realizzazione del caso d'uso di analisi piuttosto che al caso d'uso.
Individuazione delle classi di analisi dal comportamento del caso d'uso
Scopo Identificare una serie di elementi del modello (classi di analisi) candidati in grado di eseguire il comportamento descritto nei casi d'uso.  

La ricerca di una serie di classi di analisi candidate è il primo passo nella trasformazione del sistema da semplice definizione dei comportamenti richiesti a descrizione del suo funzionamento. In questo impegno, le classi di analisi sono utilizzate per rappresentare i ruoli degli elementi del modello che forniscono i comportamenti necessari per adempiere ai requisiti specificati nei casi d'uso e nei requisiti non funzionali specificati nei requisiti aggiuntivi. Allo spostarsi dell'attenzione sulla progettazione questo ruolo sviluppa una serie di elementi di progettazione che realizzano il caso d'uso.

I ruoli identificati nell'analisi del caso d'uso esprimono principalmente il comportamento dei livelli più alti del comportamento specifico dell'applicazione di sistema e di quello specifico del dominio. Le classi boundary e quelle di controllo solitamente evolvono in elementi della progettazione di livello applicazione, mentre le classi entità evolvono in elementi della progettazione specifici del dominio. Gli elementi della progettazione di livello più basso evolvono da meccanismi di analisi che sono utilizzati dalle classi di analisi qui identificate.

Le tecniche qui descritte utilizzano tre diverse prospettive del sistema per identificare le classi candidate. Le tre prospettive sono quelle del confine tra sistema ed i suoi attori, le informazioni da esso utilizzate e la sua logica di controllo. Gli stereotipi, i confini, le entità ed il controllo delle classi corrispondenti sono convenzioni utilizzate in fase di analisi che spariscono durante la progettazione.

L'identificazione delle classi significa che: devono essere identificate, denominate e descritte brevemente.

Per ulteriori informazioni sull'identificazione delle classi di analisi, consultare Tecnica: Classe di analisi. Per maggiori informazioni sulla realizzazione del caso d'uso di analisi, consultare Tecnica: Realizzazione caso d'uso.

Se nella giuda specifica per progetto sono stati documentati particolari meccanismi di analisi e/o pattern di analisi, questi dovranno essere utilizzati come ulteriore fonte di "ispirazione" per le classi di analisi.

Distribuzione del comportamento alle classi di analisi
Scopo Esprimere il comportamento del caso d'uso in termini di classi di analisi collaboranti. Determinare le responsabilità delle classi di analisi.  

Per ciascun flusso secondario indipendente (scenario):

  • Creare uno o più diagrammi di interazioni (comunicazione o sequenza). Solitamente è necessario almeno un diagramma per il flusso di eventi principale del caso d'uso, più un diagramma per ciascun flusso alternativo/eccezionale. Dei diagrammi separati saranno necessari per i flussi secondari che hanno sincronizzazioni complesse o punti di decisione, oppure per semplificare flussi complessi che sono troppo lunghi da riportare semplicemente in un unico diagramma.
  • Identificare le classi di analisi responsabili del comportamento richiesto scorrendo il flusso di eventi dello scenario, assicurandosi che il comportamento richiesto dal caso d'uso sia fornito dalla realizzazione di caso d'uso di analisi.
  • Illustrare le interazioni tra le classi di analisi nel diagramma interazione. Il diagramma interazione deve anche mostrare le interazioni del sistema con i suoi attori (le interazioni dovranno iniziare con un attore siccome sarà sempre lui ad invocare il caso d'uso).
  • Includere le classi che rappresentano le classi di controllo per i casi d'uso utilizzati. (Utilizzare un diagramma interazione diverso per ciascun caso d'uso di estensione, che mostri unicamente il comportamento variante del caso d'uso di estensione.)

un esempio di diagramma di comunicazione

Un diagramma di comunicazione per il caso d'uso Ricezione elemento di deposito.

Se nella giuda specifica per progetto sono stati documentati particolari meccanismi di analisi e/o pattern di analisi, questi si dovranno riflettere nell'assegnazione delle responsabilità e nei diagrammi di interazione risultanti.

Descrizione delle responsabilità
Scopo Descrivere le responsabilità di una classe di oggetti identificata dal comportamento del caso d'uso. 

Una responsabilità è una dichiarazione di ciò che si potrà chiedere ad un oggetto di fornire. Esse si evolvono in una (ma spesso più) operazione sulle classi nella progettazione; si possono caratterizzare come:

  • le azione che l'oggetto può eseguire
  • la conoscenza che l'oggetto mantiene e fornisce ad altri oggetti

Ciascuna classe di analisi deve avere diverse responsabilità; una classe con un'unica responsabilità è troppo semplice, mentre una con una dozzina o più si spinge verso il limite massimo e dovrebbe potenzialmente essere separata in più classi.

È sottinteso che tutti gli oggetti possono essere creati ed eliminati; non dichiarare l'ovvio a meno che l'oggetto non esegua un comportamento particolare durante la creazione o l'eliminazione. (Alcuni oggetti non possono essere rimossi se esistono determinate relazioni.)

Ricerca delle responsabilità

Le responsabilità derivano da messaggi nei diagrammi di interazione. Per ciascun messaggio, esaminare la classe dell'oggetto a cui esso è inviato. Se la responsabilità non esiste ancora, crearne una nuova che fornisca il comportamento richiesto.

Altre responsabilità deriveranno da requisiti non funzionali. Quando si crea una nuova responsabilità, verificare i requisiti non funzionali per vedere se vi si applicano requisiti collegati. Nel caso integrare la descrizione della responsabilità oppure crearne una nuova.

Documentazione delle responsabilità

Le responsabilità sono documentate con nome breve (fino a diverse parole) ed una breve (fino a diverse frasi) descrizione. La descrizione illustra cosa fa l'oggetto per adempiere alla responsabilità, e quali risultati vengono restituiti quando essa viene invocata.

Descrizione di attributi ed associazioni
Scopo Definire le classi da cui dipende la classe di analisi
Definire gli eventi nelle altre classi di analisi di cui la classe deve essere a conoscenza.
Definire le informazioni che la classe di analisi dovrà gestire. 

Per poter portare a termine le proprie responsabilità, le classi dipendono frequentemente da altre classi. Le associazioni documentano le relazioni che intercorrono tra le classi ed aiutano a comprendere le loro dipendenze; una migliore comprensione delle dipendenze delle classi, unita ad una loro riduzione dove possibile, permette la costruzione di un sistema migliore e più elastico.

I passi seguenti definiscono gli attributi delle classi e le loro associazioni:

Definizione degli attributi

Gli attributi sono utilizzati per archiviare le informazioni per un classe. In particolare, gli attributi vengono utilizzati dove le informazioni sono:

  • Considerate "per valore"; cioè, è importante solo il valore dell'informazione, non la sua posizione o l'identificatore dell'oggetto.
  • Sono univocamente di "proprietà" dell'oggetto a cui appartengono; non vi sono altri oggetti che fanno riferimento all'informazione.
  • Accedute da operazioni che unicamente ricevono, impostano o eseguono semplici trasformazioni sulle informazioni; l'informazione non ha un comportamento "reale" tranne che quello di fornire il proprio valore.

Se invece l'informazione ha un comportamento complesso, è condivisa tra due o più oggetti oppure è passata "tramite riferimento" tra due o più oggetti, deve essere modellata come classe separata.

Il nome dell'attributo deve essere un sostantivo che illustra chiaramente l'informazione in esso contenuta.

La descrizione dell'attributo deve illustrare quali informazioni dovranno essere in esso archiviate; ciò è facoltativo quando l'informazione è ricavabile dal nome dell'attributo.

Il tipo dell'attributo rappresenta il suo tipo di dati. Alcuni esempi sono stringa, numero intero, numero.

Formazione delle associazioni tra le classi di analisi

Iniziare studiando i collegamenti nei diagrammi di interazione prodotti in Distribuzione del comportamento alle classi di analisi. I collegamenti tra le classi indicano che i loro oggetti devono comunicare per eseguire il caso d'uso. Una volta avviata la progettazione del sistema, questi collegamenti potranno essere realizzati in diversi modi:

  • L'oggetto potrà avere un ambito "globale", nel cui caso qualsiasi oggetto nel sistema gli potrà inviare messaggi.
  • Un oggetto potrà essere passato ad un secondo come parametro, dopo di che potrà inviare messaggi all'oggetto passato.
  • L'oggetto potrà avere un'associazione permanente con un altro oggetto a cui si inviano i messaggi.
  • L'oggetto potrà essere creato e distrutto all'interno dell'ambito di un operazione (cioè, un oggetto temporaneo), questi sono considerati come 'locali' per l'operazione.

In questa fase della "vita" di una classe, tuttavia, è troppo presto per prendere queste decisioni: non si hanno abbastanza informazioni per prendere decisioni ben ponderate. Di conseguenza, nell'analisi si creano associazioni ed aggregazioni per rappresentare qualsiasi messaggio che deve essere inviato tra gli oggetti delle due classi. (L'aggregazione, è una forma particolare di associazione, indica che l'oggetto partecipa ad relazione "intera/parte", consultare Tecnica: Associazione e Tecnica: Aggregazione).

Queste associazioni ed aggregazioni verranno perfezionate nel Compito: Progettazione della classe.

Per ciascuna classe, creare un diagramma di classe che mostri le associazioni che ciascuna ha con le altre:

un esempio di diagramma di classe, che mostra le associazioni e le aggregazioni

Esempio di diagramma di classi di analisi per una parte di un sistema di immissione di ordini

Concentrare l'attenzione unicamente sulle associazioni necessarie alla realizzazione del caso d'uso; non aggiungerne altre che si pensa possano servire, a meno che non siano richieste nei diagrammi di interazione.

Assegnare ai ruoli delle associazioni nomi e molteplicità.

  • Il nome di un ruolo dovrà essere un sostantivo che esprima che ruolo ha l'oggetto associato in relazione all'oggetto associante.
  • Supporre una molteplicità di 0..* (da zero a molti) a meno che non vi sia un chiaro segnale di qualcosa di diverso. Una molteplicità di zero sottintende che l'associazione è facoltativa; assicurarsi di voler intendere ciò; se un oggetto potrebbe non esserci, le operazioni che utilizzano l'associazione dovranno essere modificate di conseguenza.
  • È possibile specificare un limite chiuso per la molteplicità (ad esempio 3..8).
  • All'interno dell'intervallo della molteplicità, si potranno specificare delle probabilità. Quindi se una molteplicità è 0..*, si prevede che sia tra 10 e 20 nell'85% dei casi, prendere nota di ciò; questa informazione sarà molto importante in fase di progettazione. Ad esempio, se si deve implementare un archivio permanente utilizzando un database relazionale, i limiti chiusi possono aiutare nell'organizzazione delle tabelle.

Creare una breve descrizione dell'associazione per indicare come viene utilizzata, o quali sono le relazioni che rappresenta.

Descrizione delle dipendenze dagli eventi tra classi di analisi

Gli oggetti a volte devono sapere quando si verifica un evento in un oggetto di "destinazione", senza che quest'ultimo sappia quali sono gli oggetti notificati al suo verificarsi. Una scorciatoia per mostrare queste dipendenze da notificazione dell'evento è l'associazione di sottoscrizione che permette di esprimere questa dipendenza in modo compatto e conciso.

Un'associazione di sottoscrizione tra due oggetti indica che l'oggetto che sottoscrive sarà informato del verificarsi di un determinato evento nell'oggetto sottoscritto. Questo tipo di associazione ha una condizione che definisce l'evento che causa la notifica all'oggetto che sottoscrive. Per ulteriori informazioni, consultareTecnica: Associazione di sottoscrizione

Le condizioni di associazione di sottoscrizione devono essere espresse in termini di caratteristiche astratte, piuttosto che in termini di attributi specifici o operazioni. In questo modo l'oggetto associante resta indipendente dai contenuti dell'oggetto di entità associato, che potrà essere modificato.

Un'associazione di sottoscrizione è necessaria quando:

  • un oggetto è influenzato da qualcosa che accade in un'altro oggetto
  • se è necessario creare un nuovo oggetto per qualche evento, quando si verifica un errore, si deve creare una nuova finestra per notificare l'utente
  • se un oggetto deve essere informato quando un altro oggetto viene istanziato, modificato o distrutto

Gli oggetti "sottoscritti" sono solitamente oggetti di entità. Questi sono tipicamente archivi passivi di informazioni, con nessun comportamento collegato alle responsabilità di archivio di informazioni. Spesso molti altri oggetti devono essere informati delle loro modifiche. L'associazione di sottoscrizione evita all'oggetto di entità di conoscere tutti questi altri oggetti, essi non devono far altro che 'registrare' il loro interessamento all'oggetto di entità per essere poi notificati delle sue modifiche.

Questi sono i 'giochi di prestigio' dell'analisi: in fase di progettazione si deve invece definire come funziona effettivamente la notifica. Si potrà acquistare un framework di notifica, oppure lo dovremo progettare e costruire noi stessi. Al momento, però, è sufficiente notare che esiste la notifica.

La direzione dell'associazione mostra che solo l'oggetto che sottoscrive è a conoscenza della relazione tra i due oggetti. La descrizione della sottoscrizione è completamente contenuta nell'oggetto che sottoscrive. L'oggetto di entità associato, a sua volta, viene definito in modo classico senza considerare l'interesse degli altri oggetti nelle sue attività. Ciò comporta che un oggetto che sottoscrive potrà essere aggiunto o rimosso dal modello senza dover modificare l'oggetto a cui si sottoscrive.

Riconciliazione delle realizzazioni del caso d'uso di analisi
Scopo Riconciliare le singole realizzazioni del caso d'uso di analisi ed identificare una serie di classi di analisi con relazioni consistenti.  

Le realizzazioni di caso d'uso di analisi sono state sviluppate in conseguenza all'analisi di un determinato caso d'uso. Adesso le singole realizzazioni di caso d'uso di analisi devono essere riconciliate. Esaminare le classi di analisi e le associazioni supportate per ciascuna delle realizzazioni di caso d'uso di analisi. Identificare e risolvere le incongruenze e rimuovere i duplicati. Ad esempio, due diverse realizzazioni di caso d'uso di analisi possono includere una classe di analisi che è concettualmente uguale, ma siccome sono state identificate da due progettisti diversi, hanno un nome diverso. 
Nota: Le duplicazioni tra le realizzazioni di caso d'uso di analisi possono ridursi drasticamente se l'architetto di software fa un buon lavoro di definizione dell'architettura iniziale (consultare Compito: Analisi strutturale).

Quando si riconciliano gli elementi del modello è importante considerarne le relazioni. Se si fondono due classi, o se una sostituisce un'altra, accertarsi di propagare le relazioni della classe originaria alla nuova.

L'architetto di software deve partecipare alla riconciliazione delle realizzazioni di caso d'uso di analisi, siccome si necessita di una comprensione del contesto di business, e di una previsione della architettura software e della progettazione, così da selezionare le classi di analisi che meglio rappresentano il dominio del problema e della soluzione.

Per ulteriori informazioni sulle classi, consultare Tecnica: Classe di analisi.

Qualifica dei meccanismi di analisi
Scopo Identificare i meccanismi di analisi (se ve ne siano) utilizzati dalle classi di analisi. Fornire maggiori informazioni su come le classi di analisi applicano il meccanismo di analisi.  

In questa fase si esaminano i meccanismi di analisi che si applicano a ciascuna delle classi di analisi identificate.

Se una classe di analisi utilizza uno o più meccanismi di analisi, le informazioni registrate in questa fase aiuteranno l'architetto di software ed i progettisti a determinare le capacità richieste al meccanismo di progettazione strutturale. Il numero di istanze della classe di analisi, le loro dimensioni, la loro frequenza di accesso ed il loro ciclo di vita previsto sono tra le proprietà più importanti che assistono i progettisti nella selezione dei meccanismi adeguati.

Per ciascun meccanismo di analisi utilizzato da una classe di analisi, qualificare le caratteristiche rilevanti da considerare nella selezione dei meccanismi di progettazione e implementazione adeguati. Ciò varierà in base al tipo di meccanismo; assegnare degli intervalli dove necessario o dove vi sia ancora incertezza. Meccanismi strutturali differenti avranno caratteristiche diverse, quindi questa informazione è meramente descrittiva e deve unicamente essere strutturata per registrare e concentrare le informazioni. Durante l'analisi, queste informazioni sono abbastanza stringate, ma la loro registrazione è importante per permettere una revisione delle stime all'aumentare delle informazioni scoperte.

I meccanismi di analisi utilizzati da una classe e le loro caratteristiche associate devono essere registrate in modo formale; una nota allegata ad un diagramma, o una integrazione della descrizione della classe è sufficiente per convogliare le informazioni. Le informazioni della caratteristica in questa fase dell'evoluzione della classe sono abbastanza fluide ed astratte, quindi l'attenzione è sulla registrazione dei valori previsti piuttosto che sulla formalizzazione della definizione dei meccanismi.

Esempio

Le caratteristiche di un meccanismo persistente utilizzato dalla classe Volo potranno essere qualificate come:

Livello di granularità: da 2 a 24 Kbyte per volo

Volume: fino a 100.000

Frequenza di accesso:

  • Creazioni/eliminazioni: 100 ogni ora
  • Aggiornamenti: 3.000 aggiornamenti ogni ora
  • Lettura: 9.000 accessi ogni ora

Esempio

Le caratteristiche di un meccanismo persistente utilizzato dalla classe Missione potranno essere qualificate come:

Livello di granularità: da 2 a 3 Kbyte per missione

Volume: 4

Frequenza di accesso:

  • Creazioni/eliminazioni: 1 al giorno
  • Aggiornamenti: 10 aggiornamenti al giorno
  • Lettura: 100 ogni ora
Formazione della tracciabilità
Scopo Gestire le relazioni di tracciabilità tra modelli di analisi ed altri modelli.  

Le linee guida specifiche per progetto definiscono quale tracciabilità è richiesta per gli elementi del modello di analisi.

Ad esempio, se vi è un modello separato dell'interfaccia utente, potrebbe essere utile tracciare gli elementi dell'interfaccia di altri utenti in quel modello in classe boundary del modello di analisi.

Revisione dei risultati
Scopo Verificare che gli oggetti di analisi raggiungano i requisiti funzionali eseguiti sul sistema.
Verificare che gli oggetti di analisi e le interazioni siano congruenti. 

Condurre una revisione informale alla fine del workshop, come punto di sincronizzazione, e come conclusione del Compito: Analisi del caso d'uso.

Utilizzare l'elenco di controllo per l'output del prodotto di lavoro di questo compito.



Proprietà
Ricorrenze multiple
Attivato da evento
In corso
Facoltativo
Pianificato
Ripetibile
Ulteriori informazioni