La concorrenza in UML

Nei casi in cui più di un’attività (task o processo, più in generale comportamentibehaviors) debbano essere eseguite in parallelo (concorrentemente), abbiamo bisogno dal punto di vista della modellazione di alcune regole/strumenti che consentano di rappresentare correttamente tale esecuzione contemporanea. Per riferimento possiamo considerare la definizione di concorrenza su wikipedia:

In informatica la concorrenza è una caratteristica dei sistemi di elaborazione nei quali può verificarsi che un insieme di processi o sottoprocessi (thread) computazionali sia in esecuzione nello stesso istante.

In UML il supporto alla concorrenza avviene prevedendo per diversi tipi di diagrammi dei costrutti adeguati. Vediamo di seguito come.

Concorrenza negli Activity Diagram

Negli Activity Diagram (diagrammi delle attività), la concorrenza può essere rappresentata in due modi fondamentali:

  • Implicitamente: non viene utilizzato alcun elemento specifico per rappresentare il parallelismo tra attività, semplicemente esisteranno più archi uscenti (implicit split) da una singola action che vanno verso le action che devono essere eseguite concorrentemente (e analogamente avremo più archi entranti in una singola action provenienti da action eseguite in parallelo – implicit join)
Concorrenza implicita tramite Implicit split e Implicit join
  • Esplicitamente: vengono utilizzati i nodi di controllo fork e join, concepiti appositamente per la modellazione di attività concorrenti
Concorrenza esplicita tramite Fork e Join

Un’osservazione importante da fare è in merito ai Merge Node, che essendo nodi di controllo che riuniscono più flussi entranti senza sincronizzazione, non sono indicati come costrutti specificatamente concepiti per la modellazione di attività concorrenti (il loro scopo è diverso). Stessa cosa, per motivi analoghi, dicasi per i Decision Node.

Un’altra osservazione da fare è in merito agli Initial Node, che possono essere coinvolti in flussi di controllo concorrenti in due modi: il singolo nodo può avere più di un arco uscente oppure nello stesso diagramma possono esistere più di un Initial Node. Nel primo caso, per convenzione, si intende che un control token venga posto contemporaneamente su ogni arco uscente, realizzand così dei flussi concorrenti. Nel secondo caso, in corrispondenza di ogni Initial Node viene posto contemporaneamente un control token, dando luogo anche in questo caso alla nascita di diversi flussi di controllo concorrenti.

Infine, osserviamo che un’attività può avere un numero arbitrario di Activity Parameter. Alla chiamata di un’attività con più di un parameter, vengono presentati in input degli object token per ognuno di essi, dando luogo anche in questo caso ad esecuzioni concorrenti.

Concorrenza nei Sequence Diagram

Nei Sequence Diagram UML mette a disposizione diversi costrutti che consentono di modellare il parallelismo: il combined fragement con operando par e le coregion. Il primo viene utilizzato tra più lifeline, mentre il secondo viene utilizzato su una singola lifeline, ma semanticamente il significato è lo stesso. Lo scopo dell’utilizzo di una coregion è unicamente quello di utilizzare una notazione più leggera dal punto di vista grafico.

Esempio di combined fragment par
Esempio di Coregion

Il Combined Fragment con l’operatore par, vuole modellare l’esecuzione parallela degli operandi. L’ordine delle occorrenze dei messaggi (degli eventi) tra i due operandi sulla lifeline in cui appare la coregion, è del tutto non significativo.

Un esempio di utilizzo del combined parallel fragment è il seguente:

Esempio di utilizzo di combined parallel fragment

Fonti:

Tool utilizzato per i diagrammi:

Vai alla barra degli strumenti