Diagrammi di attività: mostrare in modo chiaro i processi cronologici delle attività con UML

UML 2 specifica un’attività (activity in inglese) come comportamento che assegna un ordine di successione alle unità sottostanti (azioni e oggetti). Per farlo si utilizzano modelli di dati e di flusso di controllo. Il diagramma di attività può essere rappresentato come parte di un sistema più vasto in combinazione con altri tipi di diagrammi. Un grande rettangolo arrotondato contrassegna l’attività come sistema chiuso (si può anche tralasciare). Nella parte inferiore dell’immagine potete vedere l’attività “cuocere gli asparagi”. Scrivete il titolo nella testa del rettangolo grande. Il corpo a propria volta contiene frecce e nodi (rettangoli), che simboleggiano in dettaglio azioni, oggetti e controllo o flusso di dati dell’attività.

Soltanto quando le condizioni impostate sui pin vengono soddisfatte i dati eseguiranno un’azione (pin di input) o l’azione restituirà un risultato (pin di output). Anche se un’azione ha più flussi di controllo in entrata, ognuno deve offrire un token prima di iniziare un’azione.

Per azioni all’interno del diagramma di attività la sintassi astratta contiene la forma semplice del rettangolo arrotondato. Tuttavia ci sono azioni specifiche che i modellisti possono usare per descrizioni più specifiche. Alcuni di questi esprimono UML con la sua notazione. Queste sono le sottospecie delle azioni:

1. Opaque Actions, ovvero “azioni opache”. Fungono da segnaposto o sono specificate dalla concreta (non specificata da UML) sintassi del testo.
2. Invocation Actions, azioni che causano un determinato comportamento, direttamente o indirettamente. Esse includono:
   • call actions: una call behavior action chiama direttamente un comportamento. Una call operation action invece invia una richiesta a un oggetto che chiama un comportamento connesso. La start object behavior action porta direttamente un oggetto a eseguire il suo comportamento di istanza. Se non ne è specificato nessuno, può attivare il comportamento del classificatore sovraordinato (classifier behavior).

La notazione di un’azione che causa un comportamento consiste di un rettangolo arrotondato. Lì si inserisce il nome del comportamento che si intende richiamare. Inoltre le call behavior actions sono contrassegnate con un’icona a forma di tridente, come mostrato nell’immagine sotto, che è intesa a rappresentare l’ulteriore ramificazione gerarchica risultante dall’azione.

• Send actions: le azioni di invio nel diagramma di attività inviano dati sempre in modo asincrono (i diagrammi di sequenza, ad esempio, conoscono anche i messaggi sincroni). Ciò significa che non aspettano una risposta dall’oggetto di destinazione e quindi non bloccano il flusso degli oggetti. L’azione termina non appena il messaggio è stato inviato. Pertanto potrebbe effettivamente avere un argument input, come ad esempio i parametri, ma non produrre alcun result output. Inoltre i messaggi possono dirigersi direttamente a più destinatari. Appartengono a questo tipo send signal action, broadcast signal action e send object action.

Le send signal actions differiscono nella loro notazione dalla forma usuale (il rettangolo arrotondato): al suo posto un pentagono punta come una grande freccia in direzione del segnale trasmesso. Se il contenuto di una send objet action è costituito anche da un segnale, è possibile utilizzare la stessa notazione.

3. Le object actions cambiano lo stato degli oggetti (cioè le istanze di una classe). Possono crearle o distruggerle, confrontarle con altre istanze e quindi assegnarle a una classe o modificare la classificazione. Di conseguenza in UML 2 esistono le seguenti istanze di azioni oggetto:
   • create object actions, che generano istanze di una classe, cioè oggetti;
   • destroy object actions, che distruggono l’oggetto sul pin di input;
   • test identity actions, che esaminano se due valori sul pin di input rappresentano lo stesso oggetto;
   • read self actions, che determinano il proprio oggetto di contesto;
   • value specification actions, che esaminano le specifiche del valore. La notazione reca l’etichetta value specification;
   • read extent actions che trovano tutti gli oggetti di una classe nonché gli oggetti delle loro specifiche. Per motivi pratici i modellatori di solito limitano la gamma;
   • reclassify object actions che modificano la classe per l’oggetto sul pin di input;
   • read is classified object actions per determinare se un oggetto sul pin di input appartiene a una classe;
   • start classifier behavior actions che fungono per un oggetto da trigger per un comportamento determinato dalla relative classe. Il comportamento procede in modo asincrono.
4. Le link actions modificano il comportamento delle associazioni (relazioni tra classifier, di solito due classi) e le loro istanze, i link. Questi includono:
   • read link actions, che recuperano valori (link end data) su una pagina di un’associazione;
   • create link actions, che creano link (non hanno pin di output perché i link in sé non sono dati) e link objects;
   • destroy link actions che cancellano i link e link objects se corrispondono a un valore link end data specificato.
5. Le link object actions, come le link actions, influenzano il comportamento dei link objects, ma guardano gli oggetti da angolazioni diverse. Ecco le istanze di link object actions:
   • read link object end actions, che recuperano gli oggetti finali dai link object (o oggetti di collegamento);
   • read link object end qualifier actions, che recuperano i valori finali del classifier dagli oggetti di collegamento;
   • create link object actions, che sono particolari create link actions con le quali si creano oggetti di collegamento.
6. Le structural feature actions stabiliscono il comportamento delle caratteristiche strutturali nei diagrammi di attività. Per questo hanno bisogno di un pin di input, dato che di solito sono sia un oggetto che una caratteristica strutturale specificata staticamente attribuita a un classifier. L’azione della caratteristica strutturale influisce su entrambi gli elementi. Ci sono i seguenti tipi:
   • read structural feature action, che legge i valori delle caratteristiche strutturali e li passa come output;
   • add structural feature value actions, che richiedono un value input pin. Esso specifica il valore che l’azione assegna a una caratteristica strutturale;
   • remove structural feature value actions che sottraggono valore da una caratteristica strutturale. Un value input pin con molteciplità 1..1 specifica questo valore;
   • clear structural feature actions, che rimuovono tutti i valori di un elemento della struttura.
7. Le variable actions influiscono sulle variabili specificate staticamente che vengono definite da un’attività o da un nodo di attività strutturato (structured activity node). Ce ne sono tre tipi:
   • add variable value actions, che necessitano di un value input pin. Esso deve essere dello stesso tipo della variabile e le aggiunge esattamente un valore;
   • remove variable value actions, che rimuovono un valore specificato dal pin;
   • clear variable actions, che rimuovono tutti i valori di una variabile.
8. Le accept event actions appartengono ai cosiddetti punti di attesa (wait points). Ciò significa che l’azione è in attesa di un evento (event) dal pool di eventi dell’oggetto di contesto. L’azione possiede dei trigger che attivano l’azione quando si verificano uno o più stati tra quelli prescritti. L’UML descrive tre specializzazioni:
   • accept call action, che hanno un trigger che accetta i call events (eventi di chiamata). Due result output pins e un return information output pin completano la disposizione. Se deve essere eseguita una reply action, le informazioni necessarie vengono memorizzate nel return information output pin.

9. Le structured actions sono definite da UML 2 nei diagrammi di attività sia come azioni che come gruppi di attività (vedi sopra). Ciò significa da un lato che il loro comportamento è determinato da nodi e fronti di attività e dall’altro che certe sottospecie di queste azioni, in virtù della loro semantica, prescrivono un comportamento specifico per i nodi eseguibili, in particolare per quanto riguarda la loro sequenza.

Queste sono le sottospecie delle azioni strutturate:

• I conditional nodes (nodi condizionali) sono costituiti da una o più clausole che rappresentano i diversi rami delle possibili azioni eseguibili. Una clausola contiene un segmento test e un segmento body, i quali a propria volta comprendono nodi eseguibili privi di intersezioni. In primo luogo la clausola esegue l’azione nell’area di test. Se il suo valore di output è true, la clausola esegue l’azione nella regione body.
• I loop nodes (nodi di loop) descrivono un gruppo di azioni che si ripetono all’interno di un ciclo. Le azioni si suddividono in tre sezioni: setup, test e body. Il loop esegue sempre innanzitutto il setup, a cui seguono test o body, che quindi si ripetono alternativamente.
• I sequence nodes (nodi di sequenza) impongono un ordine sui nodi eseguibili all’interno dei loro confini. Questi li rappresentano con i flussi di dati come bordi di attività (ovvero semplici frecce). Le frecce possono puntare liberamente dentro o fuori rispetto alla struttura.

10. Le expansion regions sono un’altra forma di nodi di attività strutturati. Accettano una o più raccolte di valori come input. Sulla via verso la regione di espansione il pin di input copia ciascun token in arrivo sul numero di elementi di raccolta. Tutti i nodi acclusi lavorano su ciascun valore della raccolta. Un’esecuzione vale come un’esecuzione di espansione (expansion execution). Un cosiddetto nodo di espansione (un tipo di nodo oggetto) indica l’interfaccia alla regione di espansione. Esternamente si visualizzano i loro valori come una raccolta, mentre all’interno i singoli elementi della collezione sono considerati valori. Per la notazione disegnate un rettangolo arrotondato con una linea tratteggiata. I nodi di espansione rappresentano rettangoli con segmenti e sono disegnati direttamente sulla linea, come mostrato di seguito. La segmentazione dovrebbe rappresentare l’elenco delle raccolte di valori.

I nodi oggetto sono sottoinsiemi dei nodi di attività. In generale, un oggetto in UML è l’istanza più piccola occupata dal valore. Nel diagramma di attività gli oggetti rappresentano i dati. Mentre un’azione viene eseguita, i nodi oggetto contengono tali dati. Perché solo i token di controllo possono portare direttamente a termine un’azione. I token oggetto, d’altro canto, entrano come valore su un pin di input e vengono passati dal pin di output al flusso dell’oggetto.

I nodi oggetto sono stati introdotti per la prima volta nel diagramma di attività UML 2. Sono elementi tipizzati. Se un nodo oggetto corrisponde a un tipo particolare, i token oggetto che viaggiano su di esso devono avere valori corrispondenti. Un’eccezione sono i token nulli che possono far a meno di un valore (sono conformi a qualsiasi nodo oggetto).

I noti oggetto prescrivono la successione in cui i token li abbandonano. Ci sono quattro modi per farlo:

• disordinato (non stabilito)
• ordinato (comportamento definito dal modellatore)
• FIFO (First In First Out): l’ordine di entrata e di uscita rimane lo stesso
• LIFO (Last In First Out): l’ordine è opposto (l’ultimo a entrare è il primo a uscire)

Se volete creare un diagramma di attività, potete scegliere tra quattro tipi di nodi oggetto per la modellazione:

1. Il pin: ai pin si è già accennato in questa esecuzione. Il primo grafico mostrava la notazione base dei pin. A causa del loro ruolo di collegamento tra azioni e flussi di oggetti, i modellatori in genere li disegnano come piccoli rettangoli direttamente sull’icona di azione. I pin di input (anche input pins) sono contrassegnati da una freccia nella direzione dell’azione. Per i pin di uscita (noti anche come output pins), la freccia si allontana dall’azione. Il seguente grafico mostra come visualizzare i pin dello stesso tipo in modo abbreviato (a sinistra) o come disegnare i pin di input e output se si omettono le frecce (a destra).

2. Nodo del parametro di attività: l’attività appartiene alla metaclasse della descrizione dei comportamenti. Secondo UML, ogni comportamento ha un parametro. Prima di eseguire un comportamento, è possibile immettere i valori per l’elaborazione. Dopo l’elaborazione riceverete i nuovi valori. I parametri in questa struttura sono i segnaposto che consentono l’immissione o l’emissione di questi valori. Il nodo del parametro di attività (activity parameter node) gestisce questa attività per il diagramma di attività UML. Pertanto i nodi dei parametri di attività sono sempre all’inizio e alla fine di un’attività. Di conseguenza tale nodo ha solo frecce di attività in entrata o in uscita. Disegnate il nodo del parametro di attività di input con le frecce in uscita e il nodo dell’attività di output con le frecce in entrata. Per ogni parametro esiste un nodo del parametro di attività dello stesso tipo.

All’interno di un diagramma di attività UML i token si spostano attraverso varie azioni finché l’attività non viene completata dal primo token che arriva al nodo finale. Poiché diversi token possono attraversare questo processo nello stesso momento, è necessario un certo ordine. I nodi di controllo servono proprio a garantire un processo chiaro. Essi gestiscono solo i flussi di controllo che si trovano sul percorso che va dall’inizio del diagramma di attività attraverso le azioni fino alla fine dell’attività. I nodi di controllo non possono memorizzare i token della cache, diversamente dai nodi oggetto come il nodo buffer.

Una differenza significativa tra i flussi oggetto e di controllo è che solo i token di controllo migrano sui flussi di controllo. Questi token non contengono dati, a differenza dei token oggetto. Sono soltanto indicatori, pertanto le azioni non richiedono nodi oggetto (pin in particolare) per raccogliere e passare i token di controllo. Un token di controllo avvia un’azione, passa alla successiva e quindi la mette in movimento. Controlla perciò l’esecuzione dell’attività in modo cronologico.

Tra i simboli del diagramma di attività UML i nodi di controllo sono probabilmente i più diversi. Appartengono ai nodi dell’attività. UML 2 distingue sei tipi:

1. I nodi iniziali (initial nodes) iniziano un’attività. Ci può essere più di un nodo di partenza per attività. Quando inizia un’attività il nodo iniziale mette immediatamente in movimento il flusso di controllo. Se esistono più nodi iniziali, i rispettivi flussi di controllo iniziano in modo simultaneo. Anche i nodi di attività strutturati possono avere nodi iniziali. Essi iniziano immediatamente se l’attività strutturata viene inizializzata, purché non siano state impostate condizioni per il loro avvio. Poiché gli initial nodes sono all’inizio, tutti le loro frecce sono frecce di attività in uscita e sono sempre flussi di controllo. Un’ulteriore particolarità dei nodi di inizio è che i token di controllo che sono posizionati sul nodo iniziale all’inizio di un’attività, possono rimanere lì se il flusso di controllo non accetta il token offerto o è bloccato.
2. I nodi finali terminano il flusso di un’attività. Ci sono due tipi di nodi terminali: l’activity final node termina l’intera attività, distruggendo tutti i token compresi nell’attività, non appena riceve il primo token. Vengono mantenuti soltanto i token oggetto in output dei nodi di parametro dell’attività. Anche tutte le azioni sincrone si fermano, mentre continuano quelle asincrone fino al loro completamento. I nodi finali accettano tutti i token in entrata. Al contrario dei nodi di inizio, un nodo finale presenta frecce di attività soltanto in arrivo. Non si esclude la presenza di più di un nodo finale. Se disegnate il diagramma di attività con più di un nodo finale, le azioni si fermano prima di aver raggiunto il proprio scopo, poiché un token ha già raggiunto il primo punto finale. Il flow final node ferma un flusso di controllo e distrugge tutti i token in entrata e non tocca altri flussi di controllo. In tal modo questo nodo finale diventa una pratica alternativa quando modellate più punti finali nel diagramma di attività.

3. I nodi di parallellizzazione e di sincronizzazione (fork nodes e join nodes), detti anche biforcazioni, sono nodi di controllo con una notazione quasi identica che rispecchia i compiti relativi. Un nodo di parallelizzazione divide un fronte di attività in entrata in più flussi contemporanei in uscita. Nel nodo di parallelizzazione può entrare una sola freccia di attività. Se si tratta di un flusso di controllo, anche tutte le frecce in uscita sono flussi di controllo, e vale lo stesso principio per i flussi di oggetti. Il nodo crea copie dei token in entrata per tutti i flussi in uscita. Se un token è accettato alla destinazione del flusso in uscita, esso viene eliminato dal nodo di origine. Se la destinazione successiva non accetta il proprio token, il nodo di parallelizzazione può eccezionalmente tenere il token finché non viene accettato.

I nodi di sincronizzazione funzionano esattamente al contrario. Diverse frecce entrano ma soltanto una esce. Se il totale delle frecce in entrata consiste in flussi di controllo, allora è un flusso di controllo a lasciare il nodo. Se c’è anche un solo flusso di oggetti al di sotto, l’UML specifica la freccia in uscita come flusso di oggetti. Se come in questo caso entrano anche token di controllo, essi decadono e soltanto i token oggetto usciranno. Se due oggetti hanno la stessa identità, il nodo li unisce in un unico token. In generale i token escono soltanto quando ne offrono uno a tutte le frecce in entrata (operazione and). Ciò accade secondo il principio “First In First Out”. Se scrivete una specifica di valore per il nodo di sincronizzazione tramite joinSpec, il nodo aspetta i token che soddisfano esplicitamente questi requisiti, prima di rilasciare token.

4. I nodi di diramazione e di connessione (decision notes e merge nodes) condividono lo stesso simbolo nel diagramma di attività. La guida dei flussi è di nuovo la caratteristica distintiva di queste notazioni di nodi. Un nodo ramificato richiede almeno una e al massimo due frecce in entrata. L’UML chiama la freccia primaria in entrata (primary incoming edge), mentre la seconda flusso dell’input di diramazione (decision input flow). Se i flussi in uscita rappresentano flussi di oggetti o di controllo, dipende dalla freccia primaria. Il compito del nodo è quello di decidere tra le frecce in uscita. Il nodo offre il suo nodo in arrivo senza copiarlo, perciò il token può prendere una sola direzione.