Vai alla Home Page About me Courseware Federica Living Library Federica Federica Podstudio Virtual Campus 3D Le Miniguide all'orientamento Gli eBook di Federica La Corte in Rete
 
I corsi di Ingegneria
 
Il Corso Le lezioni del Corso La Cattedra
 
Materiali di approfondimento Risorse Web Il Podcast di questa lezione

Porfirio Tramontana » 10.Sequence Diagram


Diagrammi comportamentali

A completamento di quelli strutturali, modellano il comportamento dinamico di un sistema (o di un problema da analizzare).

  • Use case diagram
  • Statechart diagram
  • Activity Diagrams
  • Interaction diagrams

Diagrammi di Interazione

I diagrammi di Interazione sono usati per modellare gli aspetti dinamici di un sistema software, evidenziando in particolare le interazioni tra gli elementi che li compongono (e che sono stati descritti nei diagrammi strutturali).

Ci sono quattro tipi di diagrammi di interazione:

  1. Sequence diagrams
  2. Communication diagrams
    • in UML 1 erano chiamati collaboration diagrams
  3. Interaction Overview Diagrams
  4. Timing Diagrams

I diagrammi di interazione appartengono alla famiglia dei Behaviour Diagram.

Sequence Diagrams

Rappresentano il tipo di diagramma di interazione largamente più utilizzato.
In generale, un sequence diagram modella le interazioni tra uno o più attori e il sistema software, nell’ambito dell’esecuzione di uno scenario di esecuzione.

Le interazioni tra attori e sistema e tra le varie parti del sistema sono modellate in forma di messaggi, così come prevede il paradigma object-oriented.

Sequence diagrams: esempio


Sequence diagram: elementi

Istanze di classi
Rappresentate da rettangoli col nome della classe e l’identificatore dell’oggetto sottolineati (notazione UML 1) oppure semplicemente con un nome dal quale si evinca che si sta considerando un’istanza della classe (ad esempio anOrder oppure aProduct).

Attori
Rappresentati come negli use case diagrams;
Sono riportati sulla sinistra, con frecce di interazione verso oggetti del sistema;
Possono anche non essere riportati, nel caso in cui lo scenario venga avviato a sua volta da un altro scenario.

Messaggi
Rappresentati come frecce da un attore ad un oggetto, o fra due oggetti;
I messaggi di ritorno (se riportati) hanno una linea tratteggiata;
I messaggi sincroni terminano con una freccia triangolare piena;
I messaggi asincroni terminano con una freccia semplice →
Un messaggio può anche insistere all’interno di uno stesso oggetto: in tal caso è indicato da un autonello;
L’ordine dei messaggi (dall’alto verso il basso) ricalca l’ordine sequenziale con il quale vengono scambiati.

Sequence diagrams


Lifelines e barre di attivazione

Lifelines (linee di vita)
Si tratta di linee tratteggiate verticali, che partono dal rettangolo rappresentativo dell’oggetto e giungono fino al fondo del diagramma. Indicano il periodo temporale di vita dell’oggetto, dalla sua costruzione alla sua distruzione.
Le linee di vita di oggetti staticamente definiti (static) partono dalla cima del diagramma.
Una richiesta al costruttore può creare un oggetto: in questo caso l’oggetto viene disegnato al termine della freccia corrispondente al messaggio di creazione.
La distruzione di oggetti è indicata da una croce (ics) che interrompe la lifeline dell’oggetto.

Activation box (Barra di attivazione )
È rappresentata da un rettangolo che copre una parte della lifeline di un oggetto cui giunge un messaggio.
Rappresenta idealmente il periodo di tempo necessario per elaborare la richiesta giunta all’oggetto.

Sequence diagram: campo di applicazione

I sequence diagram sono utilizzati in diverse fasi del ciclo di vita di un software.
In fase di analisi, un sequence diagram può essere una rappresentazione grafica di uno scenario di un caso d’uso.

In questo caso, il ruolo di oggetti sarà mantenuto da un generico oggetto “Sistema”.
Potranno comparire altri oggetti (indicanti ad esempio alcuni componenti architetturali quali server, database, etc.) se essi rappresentano elementi vincolati.

Sequence diagram: campo di applicazione (segue)

In fase di progettazione di alto livello i sequence diagram descrivono ancora scenari di casi d’uso ma …

Come oggetti compaiono istanze delle classi del dominio del problema.
Come messaggi compaiono le responsabilità e le operazioni stabilite dal class diagram di dominio del problema.

Non compaiono, invece, elementi architetturali (database, etc.).

Sequence diagram: campo di applicazione (segue)

In fase di progettazione di dettaglio i sequence diagram descrivono realizzazioni di metodi.

Come oggetti compaiono istanze delle classi di progetto di dettaglio.
Come messaggi compaiono le chiamate di metodo sugli oggetti.

Al posto degli elementi architetturali dovrebbero comparire oggetti delle classi che ne consentono l’accesso (ad esempio, anzichè database potrebbe comparire l’oggetto JDBC sul quale si effettuano le query).

Per la descrizione di algoritmi, i sequence diagram non sono lo strumento più adatto: ad essi verranno spesso preferiti activity e statechart diagrams.

Sequence diagram: elementi

Un sequence diagram dovrebbe servire per modellare uno e un solo scenario di caso d’uso.

C’è il rischio di dover disegnare moltissimi diagrammi, uno per ogni scenario alternativo.

A partire da UML 2, sono stati proposti e formalizzati costrutti che consentono di modellare cicli e condizioni, in modo da poter visualizzare algoritmi in un sequence diagram.

Sequence diagram: cicli e condizioni

Cicli e condizioni si indicano con un riquadro (frame) che racchiude una sottosequenza di messaggi.
Nell’angolo in alto è indicato il costrutto. Tra i costrutti possibili:

  • Loop (ciclo while-do o do-while): la condizione è indicata tra parentesi quadra all’inizio o alla fine;
  • Alt (if-then-else): la condizione si indica in cima; se ci sono anche dei rami else allora si usa una linea tratteggiata per separare la zona then dalla zona else indicando eventualmente un’altra condizione accanto alla parola else;
  • Opt (if-then): racchiude una sottosequenza che viene eseguita solo se la condizione indicata in cima è verificata
    • Sono possibili anche altri costrutti per indicare parallelismo, regioni critiche, etc..

In realtà, è buona norma utilizzare altri tipi di diagramma quando l’algoritmo da modellare si fa complesso.

Sequence diagrams: esempio

Questa notazione é stata introdotta con UML versione 2.

Questa notazione é stata introdotta con UML versione 2.


Esempio: azienda alimentare

Una azienda produttrice di prodotti alimentari, vuole organizzare un sistema informativo aziendale. Tutti gli utenti dell’applicazione devono essere in grado di visualizzare informazioni relative al catalogo dei prodotti. Inoltre i dipendenti devono essere in grado di accedere ad informazioni relative alle loro mansioni.
I prodotti sono organizzati in linee di prodotto che accomunano prodotti dello stesso tipo: ad esempio, due linee possono essere pasta e sughi. I prodotti possono essere confezionati in diversi stabilimenti. I dipendenti si suddividono in diverse categorie: i manager, che sono responsabili di una o più linee di produzione (ogni linea é però gestita esattamente da tre manager, per assicurare una gestione equa), i supervisori della produzione che sono responsabili di tutti i prodotti di una specifica linea in uno specifico stabilimento, e gli operai che lavorano su uno specifico prodotto in un determinato stabilimento.
L’applicazione deve consentire ai manager di accedere alle informazioni relative ai dipendenti di cui sono responsabili, e a tutti di accedere alle informazioni sui prodotti.

Il supervisore invia ogni anno una mail di auguri di Pasqua a tutti gli operai e i manager che lavorano nello stabilimento che contiene la linea di prodotto di cui è responsabile.

All’apertura di una nuova linea di prodotto in uno stabilimento, il supervisore stabilisce tre manager che la gestiscano tra quelli già presenti in azienda. Se non vi sono abbastanza manager disponibili, provvede ad assumerne di nuovi.

System Domain Model


Sequence diagram Invia mail


I materiali di supporto della lezione

Martin Fowler, UML Distilled, capitolo 4 (sequence diagram).

  • Contenuti protetti da Creative Commons
  • Feed RSS
  • Condividi su FriendFeed
  • Condividi su Facebook
  • Segnala su Twitter
  • Condividi su LinkedIn
Progetto "Campus Virtuale" dell'Università degli Studi di Napoli Federico II, realizzato con il cofinanziamento dell'Unione europea. Asse V - Società dell'informazione - Obiettivo Operativo 5.1 e-Government ed e-Inclusion