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 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:
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.
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:
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.
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.
|
|