Activity Diagram - Attività
L’implementazione di una qualsiasi operazione può essere descritta attraverso un insieme di attività correlate, che, nella fase finale di codifica, possono venire tradotte, più o meno immediatamente, in linee di codice.
Con il termine di attività ci si riferisce ad una esecuzione non atomica all’interno di una macchina a stati, eseguita con l’evidente obiettivo di produrre specifici risultati.
Il concetto generale di attività prevede diverse specializzazioni, come: la valutazione di un’espressione, l’invocazione di un’altra attività, la spedizione di un segnale, la creazione o distruzione di un oggetto, e così via.
Graficamente, ciascuna attività è rappresentata per mezzo di un rettangolo con gli angoli smussati, al cui interno viene impostata una stringa che ne esplichi l’attività stessa.
 
 

L’UML non prescrive alcuna sentissi particolare atta a rappresentare le espressioni che descrivono le attività da svolgere. Quindi il progettista ha libera scelta sul formalismo ritenuto più opportuno. Si può spaziare da quelle più astratte in pseudo-codice, fino a vere e proprie istruzioni di un linguaggio di programmazione, magari Java.
 
 
 

Gli stati d’attività e gli stati d’azione
Prima di leggere il presente paragrafo, si consiglia di concentrarsi un po’, altrimenti si potrebbe correre il rischio di confondersi per bene le idee (come al solito: poche ma ben confuse!).
Durante la modellazione di un activity diagram, tipicamente, si ha la necessità di includere tutta una serie di attività ed azioni. Tra queste compaiono le cosiddette esecuzioni atomiche, come l’invocazione di un’operazione in un oggetto, l’invio di un segnale, la creazione o distruzione di un oggetto, e così via. Queste esecuzioni vengono rappresentate attraverso gli stati di azione, le cui caratterizzati sono:
· non poter essere ulteriormente decomponibili;
· atomicità: sebbene degli eventi possano accadere la loro esecuzione non può venire interrotta (set Interrupt off);
· tempo di esecuzione considerato trascurabile.

In costrasto agli stati d’azione, vi sono gli stati d’attività che presentano delle caratteristiche del tutto opposte, ossia:
· possono essere decomposte in ulteriori stati di maggior dettaglio (la famosa scomposizione Top-Down: un vero e proprio viaggio nei primordi dell’Informatica);
· non sono atomici, quindi la corrispondente esecuzione può essere interrotta;
· il relativo tempo di esecuzione non viene considerato trascurabile.

In sostanza uno stato d’azione è uno stato per così dire basilare che, come tale, non può essere ulteriormente suddiviso, mentre uno stato di attività può essere immaginato come un raggruppamento di altri stati di attività o di azione e, come tale, può essere descritto per mezzo di un ulteriore activity diagram di maggior dettaglio. 
Dal punto di vista della notazione, non vi è alcuna differenza tra i due stati, eccezion fatta per la maggiore complessità degli stati di attività che possono prevedere ulteriori parti, come gli eventi di entrata e di uscita (on entry, on exit), operazioni complesse, ecc. 
 
 
 

Activity Diagram -  Le transizioni
Ogni sequenza di azioni, ovviamente, presenta un punto di inizio ed uno di fine. Coerentemente con la nomenclatura grafica dell’UML, i punti di inizio vengono rappresentati per mezzo di circonferenze piene, mentre i punti di fine sequenza attraverso i famosi “occhi di toro” (due circonferenze concentriche, di cui quella interna piena).
Quando un’azione o un’attività è stata completamente eseguita, il controllo passa immediatamente all’azione o attività successiva. L’intero flusso di controllo è esplicitamente specificato per mezzo delle transizioni, rappresentate graficamente attraverso delle frecce che connettono un’azione o attività a quella successiva.
In questo contesto, le transizioni vengono definite senza condizioni di guardia in quanto, una volta terminata un’azione o attività, il controllo transita immediatamente a quella successiva. Ovviamente, nel caso di un’attività, se presente l’azione di uscita, viene prima eseguita, e quindi il controllo passa all’azione o attività successiva senza necessità di verificare alcuna condizione. Se poi, lo stato successivo è anch’esso uno stato di attività con un azione di entrata, all’ottenimento del flusso, la corrispondente azione viene eseguita. 
 
 

Il blocco condizionale (branching)
Come avveniva per i flow chart, anche negli activity diagram è possibile specificare delle esecuzioni condizionali che, rispettando le tradizioni, vengono rappresentati per mezzo di rombi. Si tratta di espressioni condizionali che, in funzione del risultato della loro valutazione, selezionano la direzione da utilizzare per l’avanzamento del flusso di controllo. Pertanto, un blocco condizionale presenta una transizione di ingresso e due di uscita, ciascuna relativa ad un possibile esito della valutazione dell’espressione booleana. Sulle transizioni di uscita vengono evidenziate le relative espressione di guarda, che, a loro volta, sono espressioni booleane. Ovviamente, affinché sia possibile percorrere una transizione di uscita è necessario che la valutazione della relativa condizione di guardia generi il valore true.

Il digramma di figura 3 rappresenta un diagramma delle attività relativo ad un server socket (scritto verosimilmente in java) in cui viene gestito un pool di thread /Thread pooled). Una volta riconosciuta una richiesta di connessione da parte di un client, il server verifica se c’è un Thread in stato di attesa e quindi pronto a servirlo. Se la coda che ospita i thread sospesi è vuota, allora la richiesta del client viene parcheggiata nella coda dei lavori in attesa di essere serviti, altrimenti, viene prelevato il primo Thread in coda e gli viene assegnato il compito di gestire la richiesta del client.
 
 
 
 

Forking and Joining: esecuzione parallela di attività
Negli esempi visti fin qui, le varie attività sono state supposte sequenziali, ossia ogni attività viene eseguita solo al termine di quella che la precede e l’ordine di esecuzione è rigidamente stabilito dal progettista. Spesso però si può avere la necessità di progettare un sistema in modo tale che due o più attività possano essere eseguite parallelamente. L’UML mette a disposizione un formalismo grafico costituito da delle barre sia per evidenziare l’esecuzione concorrente di più attività, sia per sincronizzarne il flusso. Graficamente i processi di fork (il flusso di esecuzione si moltiplica) e quello di Join (i vari flussi si riuniscono) vengono evidenziati attraverso tali barre orizzontali.
Ovviamente, in un activity diagram il numero di barre di fork deve essere equivalente a quello delle barre di join.
Da un punto di vista concettuale, delle attività concorrenti dovrebbero effettivamente essere svolte parallelamente, nella realtà però, molto spesso si dispone di architettura Hardware monoprocessore, e quindi la concorrenza può essere solamente simulata dando solo l’illusione di una vera esecuzione parallela. In ultima analisi, affermare che due o più attività sono concorrenti equivale a dire che sono completamente indipendenti le une dalle altre e quindi possono essere eseguite in qualsivoglia ordine. Chiaramente, per poter effettuare il riaccorpamento dei relativi flussi di controllo, l’importante è che alla fine entrambe siano state eseguite completamente, in qualsiasi ordine temporale: una dopo l’atra, effettivamente in parallelo, …

Swinlanes
Durante la modellazione di una sequenza di attività, spesso risulta molto utile eseguirne una partizione in gruppi, dove ciascuno di essi rappresenta l’organizzazione responsabile delle attività assegnatele. In UML ognuno di tali gruppi è definito swinlane ed è costituito da rettangoli che specificano il luogo delle attività.
Ciascuna swinlane possiede un nome che, evidentemente, deve essere univoco all’interno del singolo diagramma, e generalmente, dovrebbe rappresentare una entità del mondo reale. 
Tipicamente, le attività appartenenti a diverse swinlane vengono considerate parallele, ciò perché nel mondo reale, le diverse organizzazioni rappresentate dalle singole swinlane dovrebbero essere effettivamente concorrenti (nel senso delle attività da svolgere).
Pertanto, con questa estensione gli activity diagram rappresentano un ottimo strumento per analizzare i work flow aziendali: è possibile focalizzare l’attenzione sulle varie attività da eseguire nonché sui dipartimenti che le hanno in carico.
 
 

Flusso di oggetti
Nella realizzazione di activity diagram, è possibile (anzi è tipico) che alcuni oggetti vengano coinvolti e che questi recitino un ruolo abbastanza importante. In UML è possibile evidenziare gli oggetti scambiati tra più attività, connettendoli attraverso delle relazioni di dipendenza (frecce tratteggiate), alle attività che li creano, li distruggono o li modificano. Si parla di flusso di oggetto in quanto rappresenta una vera e propria partecipazione dell’oggetto al flusso di controllo. Volendo infine evidenziare lo stato in cui si trova un oggetto in un particolare istante del flusso di controllo, è possibile farlo scrivendo una stringa racchiusa tra parentesi quadre.

Per esempio in figura si può notare che durante l’attività di “process order” l’oggetto “Order” si trova in una fase di “lavorazione” (in progress) per poi diventare definitivo dopo l’espletamento dell’attività di “Ship Order”. 
Ancora, l’oggetto “Bill” (e qui le ironie sono tutte scontate) transita da uno stato di “unpaid” nella fase di “Bill customer” (in cui verosimilmente viene generato) ad uno stato di “paid”, a seguito dell’esecuzione dell’attività di “Pay bill”.
 
 
 
 
 

Invio e ricezione di segnali
Spesso accade di trovarsi nella necessità di dover realizzare degli activity diagram che coinvolgono diversi oggetti in grado di comunicare attraverso l’esplicito invio di segnali. L’UML prevede due blocchi specifici, uno per l’invio e l’altro per la ricezione (come mostrato in figura 7).
 
 

Pertanto, utilizzando anche le swimlane è possibile realizzare diversi digrammi di attività, ognuno corrispondente ad un determinato oggetto, e attraverso i costrutti per l’invio e la ricezione dei segnali, evidenziarne il colloquio.
Per esempio è possibile evidenziare il protocollo necessario per consentire ad un client di connettersi al relativo server ed ottenere l’espletamento del servizio richiesto. Ovviamente in questo contesto si fa riferimento essenzialmente ad un protocollo di tipo applicativo.
 
 
 

Conclusioni
Il presente articolo, presentando l’activity diagram, ultimo dei diagrammi dedicati allo studio degli aspetti dinamici di un sistema, chiude la serie dedicata alla proiezione dinamica della design view, nonché l’illustrazione della vista stessa. 
Il numero dei diagrammi previsti dovrebbe già dare un’idea dell’importanza della vista.
Si è avuto modo di mostrare come anche gli activity diagram presentino un ampio raggio d’azione, infatti possono essere utilizzati proficuamente sia per illustrare determinati scenari dei casi d’uso, sia per modellare specifici aspetti dinamici di un sistema.
Essi risultano particolarmente utili quando si ha la necessità di analizzare dei workflow aziendali (che già di per sé focalizzano l’attenzione sulle attività da svolgere nei vari dipartimenti, e sugli oggetti scambiati), e quando bisogna illustrare in dettaglio specifiche operazioni (in tal caso si tratta di un vero e proprio flow chart della sequenza di azioni necessarie per eseguire l’operazione).
Un diagramma delle attività ben strutturato deve possedere le seguenti caratteristiche (parole dei “Tres Amigos”) : 

• focalizzare l’attenzione sul comunicare un singolo aspetto della proiezione dinamica del sistema;
• possedere gli unici elementi ritenuti indispensabili per la piena comprensione dell’aspetto;
• fornire dei dettagli consistenti con il livello di astrazione offerto;
• non essere eccessivamente sintetico tale da non informare correttamente il lettore.

Bibliografia

• [1] The Unified Modeling Language User Guide

Grady Booch, James Rumbaugh, Ivar Jacobson
Addison Wesley
Questo libro vanta il primato di essere stato scritto dai progettisti originali del linguaggio, sebbene sia conosciuto come “Grady’s book”, dal nome del suo primo autore. La mancanza di una sua copia (magari autografata!) può generare giudizi di scarsa professionalità per coloro che operano nel settore della progettazione O.O... Ciò però, costituisce una condizione necessaria, ma non sufficiente, in quanto bisogna, assolutamente, aggiungere una copia del [3] e una del [4]. Sono soldi spesi bene! Forse, il limite del libro, se proprio se ne vuole trovare uno, è quello di essere poco accessibile ad un pubblico non espertissimo di progettazione O.O. Un altro piccolo inconveniente è che, probabilmente, taluni esempi possano sembrare di carattere accademico: poco rispondenti alle problematiche del mondo reale.
 
• [2] UML Toolkit

Hans-Erik Eriksson, Magnus Penker
Wiley
Questo libro si fa particolarmente apprezzare per via del taglio pratico dello stesso. Illustra in modo semplice il linguaggio, attraverso numerosi esempi, limitando le digressioni di carattere teorico. Si suppone infatti, che coloro che si occupano di progettazione O.O. abbiano una certa familiarità con i relativi concetti. Chissà perché si ha la sensazione che non sia sempre così! Naturalmente, studiare libri che illustrano gli aspetti teorici dell’informatica, è sempre qualcosa più che auspicabile. È altresì vero però, che coloro che non hanno tempo da perdere, per la lettura di concetti arcinoti, gradiscono arrivare rapidamente al nocciolo. Ciò spesso equivale a strappare alle nottate lavorative ore preziose per il sonno.
 
• [3] The Unified Modeling Language Reference Manual

Grady Booch, James Rumbaugh, Ivar Jacobson
Addison Wesley
Il commento da riportare per questo libro, noto per come “Rumbaugh’s book”, è sostanzialmente equivalente a quanto riportato per il primo. Esso però offre un livello di difficoltà decisamente inferiore, e pertanto dovrebbe essere più accessibile. Come suggerisce il nome, si tratta di un manuale, per cui ne rispetta la tipica struttura.
[4] Design Patterns: Elements of Reusable Object-Oriented Software
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Grady Booch
Addison Wesley.
Si tratta di un ottimo libro che bisogna assolutamente avere se si vuole lavorare nell’ambito della progettazione O.O. . I “pattern” riportati, forniscono un ottimo ausilio al processo di disegno del software. L’utilizzo del libro contribuisce ad aumentare la produttività, fornisce soluzioni chiare, efficienti e molto eleganti. La fase di disegno del software, spesso, si riduce ad individuare e personalizzare i “pattern” che risolvono la problematica specifica. Si è di fronte ad una nuova frontiera della progettazione O.O.: il riutilizzo di parti del progetto. L’unica pecca imputabile, è che i vari diagrammi non sempre rispettano il formalismo UML.
 
• [5] www.omg.org

Si tratta del sito ufficiale del Object Managment Group.
 
• [6] www.mokabyte.it, numero 34 (Ottobre 1999)

UML e lo sviluppo del software.
 
• [7] www.mokabyte.it, numero 35 (Novembre 1999)

Use Case: l’analisi dei requisiti secondo l’U.M.L.
 
• [8] www.mokabyte.it, numero 36 (Dicembre 1999)

Diagrammi delle classi e degli oggetti: proiezione statica della Design View.
 
• [9] www.mokabyte.it, numero 37 (Gennaio 2000)

Proiezione statica della “Design View” parte seconda: esempi “celebri” di diagrammi delle classi.
• [10] www.mokabyte.it, numero 38 (Febbraio 2000)

Proiezione dinamica della “Design View” prima parte diagrammi di interazione.
 
• [11] www.mokabyte.it, numero 39 (Marzo 2000)

Proiezione dinamica della “Design View” seconda parte: state chart diagram.