Nella maggior parte dei casi, un diagramma sequenza viene utilizzato per illustrare le realizzazioni del caso d'uso
(consultare Prodotto di lavoro: Realizzazioni del caso d'uso), ad esempio, per
illustrare come gli oggetti interagiscono per eseguire il comportamento completo o parziale di un caso d'uso. Uno o più
diagrammi sequenza possono illustrare le interazioni degli oggetti che rappresentano il caso d'uso. Un'organizzazione
tipica prevede un diagramma sequenza per il flusso principale e uno per ciascun sottoflusso indipendente del caso
d'uso.
I diagrammi sequenza sono molto importanti per i progettisti, in quanto riducono i ruoli degli oggetti in un flusso,
offrendo pertanto indicazioni di base per determinare le responsabilità e le interfacce della classe.
A differenza del diagramma di comunicazione, un diagramma sequenza comprende la sequenza cronologica ma non le
relazioni tra gli oggetti. I diagrammi di sequenza e di comunicazione esprimono informazioni simili ma le visualizzano
in modo diverso. I diagrammi sequenza mostrano la sequenza esplicita dei messaggi e sono da preferire quando è
importante visualizzare i messaggi in ordine di tempo. Quando si è interessati alle relazioni strutturali tra le
istanze in un interazione, utilizzare il diagramma di comunicazione. Per ulteriori informazioni, consultare Tecniche: Diagramma di comunicazione.
I diagrammi sequenza possono contenere istanze di oggetti e attori, nonché i messaggi che ne descrivono l'interazione.
Il diagramma descrive cosa avviene tra gli oggetti partecipanti, in termini di attivazioni e come gli oggetti
comunicano, scambiandosi messaggi. Il diagramma sequenza può essere utilizzato per ciascuna variante di un flusso di
eventi del caso d'uso.
Diagramma sequenza che descrive parte del flusso di eventi del caso d'uso Effettua una chiamata in un
Commutatore telefonico semplice.
Un oggetto appare come un linea verticale tra virgolette detto "ciclo di vita". Il ciclo di vita rappresenta
l'esistenza dell'oggetto in un dato momento. Un simbolo dell'oggetto viene disegnato sulla sommità del ciclo di vita e
riporta il nome dell'oggetto e la classe sottolineati e separati da due punti:
nomeoggetto : nomeclasse
Gli oggetti possono essere utilizzati nei diagrammi sequenza come segue:
-
Un ciclo di vita può rappresentare un oggetto o la relativa classe. Pertanto, il ciclo di vita può essere
utilizzato per modellare il comportamento della classe e dell'oggetto. In genere, tuttavia, un ciclo di vita
rappresenta tutti gli oggetti di una determinata classe.
-
La classe di un oggetto può anche non essere specificata. Di solito si crea un diagramma sequenza, specificando
prima gli oggetti e le classi in un momento successivo.
-
Non è essenziale assegnare un nome agli oggetti, anche se è necessario se si desidera distinguere oggetti diversi
in una stessa classe.
-
Più cicli di vita in uno stesso diagramma possono rappresentare oggetti diversi della stessa classe; sebbene, come
testé affermato, è meglio assegnare un nome se si desidera distinguere due oggetti tra loro.
-
Un ciclo di vita che rappresenta una classe esiste in parallelo ai cicli di vita che rappresentano gli oggetti di
detta classe. Il nome dell'oggetto del ciclo di vita che rappresenta la classe può essere impostato sul nome della
classe.
Di norma, un'istanza attore è il richiedente dell'interazione e viene rappresentata dal primo ciclo di vita, quello
all'estrema sinistra del diagramma sequenza. Nel caso di numerose istanze di attori nello stesso diagramma, cercare di
raggrupparli tutti nei cicli di vita all'estrema sinistra o all'estrema destra.
Un messaggio è una comunicazione tra oggetti che riporta informazioni con l'aspettativa che scaturisca un'attività; nei
diagrammi sequenza, un messaggio appare come una freccia intera orizzontale che parte dal ciclo di vita di un oggetto e
raggiunge il ciclo di vita di un altro. Nel caso di un massaggio proveniente dall'oggetto stesso, la freccia parte e
arriva sullo stesso ciclo di vita. La freccia viene etichettata con il nome del messaggio e i relativi parametri. La
freccia può anche essere etichettata con una sequenza di numeri per illustrare la sequenza del messaggio in tutta
l'interazione. La sequenza di numeri è spesso omessa nei diagrammi sequenza in cui la posizione fisica della freccia
rispecchia la sequenza.
Un messaggio può non essere assegnato, vale a dire che il nome è una stringa temporanea che descrive il significato
complessivo del messaggio e non corrisponde al nome di un'operazione dell'oggetto ricevente. Il nome può essere
assegnato in momento successivo, specificando l'oggetto di destinazione del messaggio. L'operazione specificata
sostituirà il nome del messaggio.
Gli script descrivono testualmente il flusso di eventi nel diagramma sequenza.
Posizionare gli script a sinistra dei cicli di vita in modo da poter leggere il flusso nella sua totalità dall'alto
verso il basso (vedere la figura in alto). È possibile allegare script ad alcuni tipi di messaggi, garantendo così il
movimento del messaggio.
Il controllo centralizzato di un flusso di eventi o di parte del flusso di eventi significa che pochi oggetti
dirigono il flusso mediante l'invio e la ricezione di messaggi da altri oggetti. Questi oggetti di controllo decidono
l'ordine in cui altri oggetti verranno attivati nel caso d'uso. L'interazione con il resto degli oggetti è molto
limitata o inesistente.
Esempio
In un sistema di riciclaggio, il caso d'uso Stampa report giornalieri tiene traccia, tra l'altro, del
numero e del tipo di oggetti restituiti e scrive il conteggio su una ricevuta. L'oggetto di controllo Generatore
report decide l'ordine in cui verranno estratte e scritte le somme.
La struttura del comportamento del caso d'uso Stampa report giornaliero viene centralizzato nell'oggetto di
controllo Generatore report.
Questo è un esempio di comportamento centralizzato. La struttura di controllo è centralizzata principalmente perché le
diverse fasi del sottoevento del flusso di eventi non dipendono l'una dall'altra. Il vantaggio principale di questo
approccio è che ciascun oggetto non deve tenere traccia del conteggio dell'oggetto successivo. Per modificare l'ordine
delle fasi del sottoevento, è sufficiente eseguire la modifica nell'oggetto di controllo. Con altrettanta facilità è
possibile aggiungere un'altra fase del sottoevento se, ad esempio, è stato incluso un nuovo tipo di elemento di
restituzione. Un altro vantaggio di questa struttura è che è facile riutilizzare le varie fasi del sottoevento in altri
casi d'uso perché l'ordine del comportamento non è integrato negli oggetti.
Il controllo decentralizzato interviene quando gli oggetti partecipanti comunicano direttamente l'uno con
l'altro, non attraverso uno o più oggetti di controllo.
Esempio
Nel caso d'uso Invia lettera qualcuno invia una lettera in un altro paese attraverso l'ufficio postale. La
lettera viene prima inviata al paese del destinatario, di qui viene inviata a una specifica città e infine la città la
invia al destinatario.
La struttura del comportamento del caso d'uso Invia lettera è decentralizzata.
Il comportamento del caso d'uso è un flusso di eventi decentralizzato. Le fasi del sottoevento appartengono l'una
all'altra. Il mittente esprime solo il desiderio di "inviare una lettera a qualcuno". Non ha bisogno ne desidera
conoscere i dettagli di come le lettere vengono inoltrate in paesi e città. Un destinatario nello stesso paese del
mittente prevede un numero inferiore di azioni.
Il tipo di controllo utilizzato dipende dall'applicazione. In genere, si deve tentare di ottenere oggetti indipendenti,
vale a dire, delegare vari compiti agli oggetti più adatti ad eseguirli per natura.
Un flusso di eventi con controllo centralizzato avrà un diagramma sequenza con biforcazione. Mentre, un diagramma a
gradini descrive una struttura di controllo decentralizzato per gli oggetti che ne fanno parte.
Una struttura di controllo centralizzato avrà un diagramma sequenza con biforcazione. Una struttura di controllo
decentralizzato produce un diagramma sequenza a gradini.
La struttura del comportamento di una realizzazione di caso d'uso si compone, nella maggior parte dei casi, di una
miscela di comportamento centralizzato e decentralizzato.
Una struttura decentralizzata è appropriata:
-
Se le fasi del sottoevento sono saldamente accoppiate. Ciò avviene se gli oggetti partecipanti:
-
Formano oppure sono parte di una gerarchia, come Paese - Provincia - Città:
-
Formano una gerarchia di informazioni, come CEO - Responsabile di divisione - Responsabile sezione;
-
Rappresentano una progressione cronologica fissa (la sequenza delle fasi del sottoevento sarà sempre
eseguita nello stesso ordine), come Pubblicità - Ordine - Fattura -Consegna - Pagamento; oppure
-
Formano una gerarchia di ereditarietà completa, come Animale - Mammifero - Gatto.
-
Se si desidera incapsulare e pertanto eseguire un'astrazione di una funzionalità. Utile quando si utilizza tutta la
funzionalità, in quanto, se la struttura del comportamento è centralizzata può diventare, senza motivo, troppo
difficile da comprendere.
Una struttura centralizzata è appropriata:
-
Se si prevede che l'ordine in cui le fasi del sottoevento verranno eseguite cambi.
-
Se si prevede di inserire nuove fasi del sottoevento.
-
Se si desidera mantenere le parti della funzionalità come componenti separati riutilizzabili.
|