Linea guida: Diagramma sequenza
Un diagramma sequenza è un costrutto UML utilizzato per illustrare la sequenza delle interazioni tra oggetti che realizzano il comportamento di uno scenario di caso d'uso. Questa linea guida descrive la notazione UML per questo costrutto.
Relazioni
Descrizione principale

Introduzione

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.

Contenuto dei diagrammi sequenza

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 descritto nel testo di accompagnamento.

Diagramma sequenza che descrive parte del flusso di eventi del caso d'uso Effettua una chiamata in un Commutatore telefonico semplice.

Oggetti

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.

Attori

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.

Messaggi

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.

Script

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.

Distribuzione del flusso di controllo nei diagrammi sequenza

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.

Diagramma descritto nel testo di accompagnamento.

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.

Diagramma descritto nel testo di accompagnamento.

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.

Diagramma descritto nel testo di accompagnamento.

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.