Porfirio Tramontana » 11.Interaction Diagrams

Communication diagrams

I Communication diagram mostrano come gli oggetti collaborano per realizzare un’interazione.

Un communication diagram è un grafo i cui vertici sono oggetti e cui archi rappresentano link di comunicazione fra oggetti.
L’ordinamento temporale è indicato facendo precedere il messaggio da un numero di sequenza.

Per le chiamate innestate si utilizza una dot notation.

Sono anche noti come Collaboration Diagram.

Communication Diagram: esempio

Confronti con altri diagrammi

In un communication diagram dovrebbero comparire gli stessi elementi di un sequence diagram (la conversione automatica è possibile).
Non bisogna confondere communication diagram e object diagram.

• Negli object diagram gli archi rappresentano relazioni statiche tra gli oggetti;
  • Non compaiono oggetti temporanei;
  • Non ci sono informazioni sulla sequenzialità delle chiamate.

Diagrammi di Stato

Un diagramma di stato descrive il comportamento di un sistema, una parte di un sistema, o di un oggetto specifico.

• In un dato istante, il sistema o l’oggetto sono in un certo stato
  • Essere in uno stato significa che esso si comporterà in uno specifico modo in risposta a qualche evento che si verificherà.
• Alcuni eventi possono far cambiare stato al sistema
  • Nel nuovo stato, di fronte agli eventi il sistema si comporterà diversamente.
• Un diagramma di stato è un grafo diretto dove i nodi sono gli stati e gli archi sono le transizioni.

Esempio: oggetto Libro

Stati

Uno stato è rappresentato da un rettangolo arrotondato con il suo nome.
In un dato istante, uno e un solo stato del diagramma può verificarsi.
Tutti gli stati sono considerati stabili: solo un evento può causare la transizione da uno stato all’altro.
Stati speciali (pseudostati):

• Lo stato iniziale (non può essere raggiunto);
• Lo stato finale (non può essere lasciato).

Transizioni

Una transizione è un cambiamento di stato in risposta ad un evento.
È considerata istantanea.

Viene etichettata con la sintassi:

• Evento trigger [guardia] / attività
  • Evento trigger è l’evento che scatena la transizione;
  • Guardia è una condizione booleana ulteriore che deve essere verificata affinchè possa scatenarsi la transizione;
  • Attività è una azione elaborativa che si verifica contestualmente con la transizione;
    • Abbinare attività alle transizioni è l’elemento caratterizzante delle macchine di Mealy.

Esempio: Ricerca Virus

Activity State

Talvolta gli stati non corrispondono a periodi in cui l’oggetto è in attesa inerte di un evento ma a periodi di tempo necessari al completamento di un’attività.
In tal caso si parla di Activity State.

Tale modellazione è coerente con quella di una macchina di Moore, nella quale le azioni sono legate agli stati.

Attività e Azioni

UML 1 distingueva tra Azioni ed Attività:

• Un’azione veniva svolta in un tempo trascurabile ed era comunque non interrompibile, per cui poteva essere associata ad una transizione di stato;
• Un’attività invece richiedeva un tempo significativo, nel quale potevano verificarsi altri eventi che la interrompevano o influenzavano;
  • Per tale motivo andava modellata come Activity State.

Superstati

Un diagramma di stato può essere innestato all’interno di uno stato.

Gli stati del diagramma interno sono detti sotto-stati.

Gli archi possono essere diretti verso il superstato (e in tal caso si intende che siano diretti verso il suo stato iniziale) o verso un suo sottostato.

Implementazione degli statechart

Uno statechart a livello di dettaglio può essere implementato utilizzando una catena di switch nidificati.

Switch (statoCorrente) {
Case stato1:
Switch (unEvento)
Case evento1:
if (guardia1)
azioneEvento1;
Break;
Case stato2 ...
...
}

Pattern State

Una soluzione più efficace in sistemi object oriented consiste nell’utilizzo del pattern State.
Lo statechart viene tradotto con:

• Una classe generale che dichiara i metodi corrispondenti a tutte le azioni ma li implementa senza fare nulla;
• Una serie di classi derivate, corrispondenti agli stati del diagramma, che implementano soltanto i metodi corrispondenti agli eventi scatenabili su quello stato (per overriding).

Applicabilità

Gli statechart diagrams sono utili quando si vuole modellare il comportamento di una classe complessa.
Nella modellazione di dettaglio, gli statechart diagram possono essere implementati efficacemente utilizzando il pattern State.

Statechart diagram e interfaccia utente

I diagrammi di stato sono particolarmente utili nella modellazione di sistemi ad eventi.

Un caso particolare molto importante è rappresentato dalle interfacce utente visuali (GUI – Graphical User Interface).
In tal caso uno stato può corrispondere ad una finestra, mentre un evento trigger corrisponde ad un evento generato dall’utente (un tasto premuto, un click del mouse, etc.).

Activity Diagrams

Un activity diagram può essere usato per modellare un flusso di lavoro (workflow):

• In fase di analisi può essere utilizzato per modellare un problema reale;
• In fase di progettazione di alto livello per modellare l’interazione tra gli oggetti concettuali nella risoluzione di un problema;
• In fase di progettazione di dettaglio può essere usata per modellare un algoritmo, eventualmente concorrente, che deve essere implementato.

Un activity diagram rappresenta un estensione di un diagramma di flusso, con l’introduzione, in particolare, delle esecuzioni concorrenti.

Un activity diagram nasce, nell’ambito di UML, come una estensione dello statechart diagram.
Nelle ultime versioni se ne è, però, completamente distaccato, per cui ha senso studiarlo separatamente.

Attività e flussi

Le attività sono definite come azioni elaborative che il sistema deve compiere e sono modellate con rettangoli dai bordi arrotondati identificate dal nome dell’attività stessa.

Il flusso tra le attività è modellato con frecce entranti/uscenti dall’attività.
Per convenzione, l’ingresso nell’attività coincide con il suo inizio; l’uscita dall’attività coincide con il suo completamento.

Esistono anche qui degli stati iniziali e finali delimitanti il diagramma.

Branch

Il branch è una attività di decisione.

Corrisponde ad un IF;
È modellata con un rombo che abbia un solo arco entrante e più di un arco uscente;
Ogni arco uscente è etichettato con una condizione di guardia (tra parentesi quadre);
Le condizioni devono essere tra loro mutuamente esclusive.

Il merge è l’elemento duale del branch

Corrisponde ad un END IF;
È anch’esso modellato con un rombo, ma con un solo arco uscente e più di un arco entrante.

Fork e Join

Il fork rappresenta una biforcazione del flusso in due o più thread.
È rappresentato con una barra orizzontale nella quale entra un solo arco e ne esce più di uno.
Gli archi uscenti non sono etichettati e si intende che altrettanti thread siano avviati contemporaneamente a seguito della biforcazione.

Il join è il duale del fork.
È rappresentato anch’esso da una barra orizzontale nella quale entra più di un arco e ne esce uno solo.

Fork e Join corrispondono esattamente alle omonime primitive concettuali della programmazione concorrente.

Activity diagrams: esempio

Macroattività

Il limite degli activity diagram è probabilmente la descrizione troppo dettagliata dei problemi.

Per poter supportare diversi livelli di astrazione, è possibile racchiudere attività complesse in attività generiche, e dettagliarle separatamente in altri grafici.

Segnali

Negli activity diagram non compaiono esplicitamente eventi, a differenza degli statechart diagram.
Per compensare tale mancanza, sono stati introdotti i segnali:

• Un segnale indica un qualsiasi evento asincrono esterno che influenza l’esecuzione di un activity
  • Caso tipico è rappresentato dai segnali temporali.
• Simboli diversi indicano
  • Segnali inviati (send);
  • Segnali ricevuti (receive);
  • Segnali temporali (timer).