Fino a questo momento abbiamo mostrato vari tipi di diagrammi che danno una modellazione statica e dinamica del sistema. Analizziamo adesso i diagrammi di attività che servono per eseguire una modellazione del flusso di lavoro per un determinato caso d’suo. I diagramma dei casi d’uso, corredato di un diagramma di attività per ogni caso, fornisce una visione completa del funzionamento del sistema per una certa operazione. Solitamente i diagrammi di attività vengono utilizzati per descrivere il flusso di lavoro per algoritmi più o meno complessi. E’ buona norma modellare diagrammi di attività il più dettagliati possibili individuando ogni singola operazione elementare permettendo così, in caso l’algoritmo non fornisca il risultato corretto, di individuare rapidamente il problema. I diagrammi di attività sono molto simili ai diagrammi di stato, ma la differenza tra i due è che nei diagrammi di attività non sono presenti eventi o input esterni. Ciò vuol dire che per esempio un’attività viene attività da un evento esterno e durante tutto il processo di eleaborazione nessun’altro evento può influenzare il flusso di operazioni. Anche nei diagrammi di attività sono presenti uno stato iniziale e uno stato finale e la loro rappresentazione è identica a quella presente nel diagramma degli stati. La differenza principale che un diagramma di attività può terminare in stati finali diversi, per esempio in seguito ad errori nell’esecuzione di alcune operazioni. Andiamo adesso a mostrare un sempicissimo esempio di un diagramma di attività in UML per poi evidenziarne le caratteristiche principali. Il diagramma modella il processo di acquisizione di due numeri e il calcolo della divisione:
Analizzando lo schema mostrato precedentemente possiamo subito vedere che le varie attività svolte dall’algoritmo vengono rappresentate con la stessa notazione degli stati in un diagramma di stato. Tutto ciò ha un senso ben preciso, dato che, come abbiamo già detto, esiste una forte analogia tra i due tipi di diagramma. Un costrutto particolare è il rombo che rappresenta una decisione, ovvero la necessità di testare la validità di una certa espressione racchiusa all’interno. Nel nostro caso bisogna verificare il valore dato al divisore, in quanto se il divisore è zero la divisione non può essere eseguita e quindi il diagramma di attività termina. Bisogna sottolineare che in presenza di costrutti di decisione il diagramma subisce sempre una ramificazione in flussi separati. Le frecce che uniscono due attività sono dette, anche in questo caso, transizioni e sono il connettore logico nei diagrammi di attività.
Nei diagrammi di attività è possibile introdurre un altro costrutto che è il costrutto di sincronizzazione. Questo costrutto viene utilizzato quando si ha necessità di seperare nettamente due tipi di transizioni che portano ad attività diverse. Quest’ultime però vengono eseguite nello stesso momento e quindi si dicono azioni concorrenziali. Per fare un esempio di utilizzo di questo costrutto si pensi a coloro che, durante i convegni politici, svolgono l’operazione di traduzione simultanea. Infatti queste persone svolgono due attività concorrenziali: ascoltare il discorso e tradurre mentre si continua ad ascoltare. In UML si potrebbe rappresentare questo processo nel seguente modo:
Le barre nere orizzontali identificano il costrutto di sincronizzazione e tutte le attività che si trovano all’interno delle due barre vengono eseguite in maniera concorrenziale.
Ultimo costrutto che andremo ad analizzare è il costrutto di un evento asincrono o di segnale. Infatti è possibile comunicare con altre attività inviando o ricevendo dei segnali. Questo è utilizzato quando per esempio un algoritmo che sta eseguendo una certa operazioni delega, un certo calcolo, ad un’altra routine. In questo modo il flusso di attività non subirà nessun arresto, ma procederà finchè non verrà richiesto il risultato del calcolo e solo nel caso in cui il risultato non sia stato prodotto il flusso di attività si interrompe in una sorta di stato di attesa. Si consiglia di usare questo costrutto con parsimonia in quanto se si hanno, in un diagramma di attività, tanti segnali inviati e ricevuti si rischia di fare confusione ed in questo caso è più corretto passare alla modellazione di una amcchina a stati. In UML il costrutto di invio segnale e di ricezione del segnale vengono rappresentati rispettivamente con le seguenti notazioni:
