Argomenti
Questa pagina descrive alcune differenze tra UML 1.x e UML 2.0 relative al contesto RUP. Non contiene tutte le
informazioni relative alle specifiche di sovrastrutture ed infrastrutture UML ([UML04]), ma
contiene una panoramica delle funzioni UML importanti. Inoltre, fare riferimento a [RUM05] e [ERI04] per ulteriori informazioni.
Tener presente che con "UML 1.x" si fa riferimento alle versioni da UML 1.0 a UML 1.5.
Le modifiche più significative relative ai diagrammi nella serie di funzioni UML 2.0 si trovano nei diagrammi di
funzioni, più precisamente il diagramma di attività e la serie di diagrammi di interazione (consultare le sezioni Diagramma di attività, Diagramma di sequenza e Diagramma di comunicazione di seguito riportate).
Nuove funzioni UML 2.0 sono anche il Diagramma di struttura composta e la classe strutturata (consultare le sezione Diagramma di struttura composta di seguito riportata).
Introduzione
La modellazione di attività ha subito una revisione completa in UML 2.0. È giusto precisare che, almeno per un utilizzo
informale, l'aspetto e gli effetti possono essere molto simili, anche se a seconda della formalità di modellazione
utilizzata in UML 1.5 (e versioni precedenti) è probabile che l'interpretazione e il risultato di esecuzione di un
modello costruito secondo le regole di UML 1.x non siano gli stessi di UML 2.0. Pertanto, si avverte che anche quando
un modello di attività UML 1.x sembra accettabile rispetto alla versione UML 2.0 senza dover apportare modifiche,
potrebbe non essere eseguito nello stesso modo - in particolare se si tratta di modelli più complessi che implicano la
simultaneità. Per ulteriori informazioni, fare riferimento a UML04].
Secondo la definizione contenuta in UML04], una
attività (che viene illustrata in un diagramma di attività) è la specifica di comportamento come
sequenza coordinata di unità subordinate i cui singoli elementi sono azioni I singoli passi eseguibili in un
diagramma di attività UML 1.x sono stati denominati attività o stati di attività o, più correttamente, stati di azione;
in un'attività UML 2.0 tali passi vengono denominati azioni - e tali azioni non vengono ulteriormente scomposte
all'interno dell'attività. La connotazione di stato è scomparsa in UML 2.0 poiché un'attività non è più una macchina a
stati come in UML 1.x. In UML 2.0 le attività sono composte da nodi e le azioni sono un tipi di nodi; altri
tipi di nodi, descritti più avanti, sono i nodi di controllo e i nodi oggetto.
Semantica del flusso
Le attività adesso dispongono di semantica di tipo Petri Net, basata sul flusso di token, in cui l'esecuzione
di un nodo influisce sull'esecuzione di un altro mediante connessioni dirette denominate flussi. I token, contenenti
oggetti o un luogo di controllo, circolano tra nodi mediante queste connessioni. L'esecuzione di un nodo è consentita
quando vengono soddisfatte le condizioni specificate sui relativi token di input e, al termine dell'esecuzione, il nodo
offre i token sui relativi flussi di output in modo che i nodi successivi possano iniziare l'esecuzione. I flussi che
collegano i nodi si distinguono ulteriormente in flussi di controllo flussi di dati o oggetti e, come facilmente
intuibile, i token di controllo passano attraverso flussi di controllo, mentre i token di dati o di oggetti passano
attraverso flussi di oggetti.
Ciò differisce da UML 1.x, in cui i nodi erano stati (o pseudo-stati) con transizioni tra di essi, il che limitava la
modellazione dei flussi.
Modellazione della simultaneità
La funzione di simultaneità di UML 2.0 consente un parallelismo illimitato; mentre in UML 1.x l'intera macchina a stati
(attività) eseguiva un passo di esecuzione al completamento (run-to-completion), la funzione UML 2.0, nella sua forma
più completa, consente più chiamate di un'attività che vengono gestite da una singola esecuzione con più flussi di
token che si spostano tra i nodi e i connettori di flusso dell'attività. Ciò impone al modeler di essere a conoscenza
delle interazioni e delle condizioni di competizione. Inoltre, consultare la sezione Differenze della
semantica riportata di seguito per un altro esempio relativo all'effetto della modellazione della simultaneità
della semantica del flusso di token.
Notazione
Nodi di azione e di controllo
Il diagramma di seguito riportato illustra molti elementi UML 2.0 ed è presentato nel modo consueto per UML 2.0, ossia
con una cornice rettangolare e un nome in una sezione in alto a sinistra. Confrontare questo diagramma con quello della
versione UML 1.x riportato sotto di esso. Essi sono simili nell'aspetto (a parte l'orientamento differente e le
convenzioni di colore utilizzate, che non hanno significato semantico) e questo modello ha lo stesso risultato di
esecuzione in UML 1.x ed UML 2.0. Notare che i nodi di controllo - decisione, fusione, biforcazione, unione, iniziale e
finale - sono simili ai rispettivi nodi equivalenti della versione UML 1.x e che i flussi di controllo sono illustrati
con una riga con freccia, simile alla freccia della transizione UML 1.x.
Esempio di diagramma di attività UML 2.0
Esempio di diagramma di attività UML 1.x
UML 2.0 dispone di un tipo di nodo di controllo aggiuntivo, denominato Finale flusso (illustrato di seguito in
un diagramma tratto da [UML04]), che
viene utilizzato come alternativa al nodo Finale attività per concludere un flusso. Tale nodo è necessario poiché in
UML 2.0, quando il controllo raggiunge un'istanza di nodo finale attività, l'intera attività (compresi tutti i flussi)
termina. Il nodo finale termina il flusso al quale è collegato. Questo non era un problema in UML 1.5 a causa della
semantica di esecuzione al completamento (run-to-completion), ma con il parallelismo illimitato di UML 2.0, è possibile
che si desideri che non tutti i flussi vengano arrestati e che tutti i token vengano distrutti.
Nodo di controllo finale flusso
Nodi oggetto
La modellazione attività di UML 2.0 supporta anche i nodi oggetto. Un nodo oggetto è un nodo di attività che indica che
un'istanza di un certo classificatore, possibilmente in uno stato particolare, potrebbe essere disponibile ad un certo
punto dell'attività (ad esempio, come output o come input di un'azione). I nodi oggetto agiscono come contenitori dai
quali e verso i quali oggetti di un certo tipo (e possibilmente in un certo stato) possono fluire. In UML 2.0, è stata
introdotta una nuova notazione, denominata pin, per i nodi oggetto. I pin rappresentano input per un'azione o
output da un'azione e sono indicati come piccoli rettangoli collegati ai rettangoli dell'azione, come visualizzato di
seguito.
Notazione pin
Le frecce rappresentano i flussi di oggetti. Esse sono righe continue, a differenza delle righe tratteggiate utilizzate
per le transizioni a e da gli stati del flusso di oggetti in UML 1.x. Quando il pin di output su un'azione ha lo stesso
nome di un pin di input sull'azione connessa, i pin di input e di output possono essere uniti per formare un pin
autonomo. In questo modo, la visuale è analoga al flusso di oggetti in UML 1.x.
Notazione pin autonomo
Nodi di attività strutturati
Un nodo di attività strutturato è un nodo di attività eseguibile che può avere un'espansione in nodo di attività
subordinati. I nodi subordinati appartengono ad un solo nodo di attività strutturato ma possono essere nidificati. Può
avere flussi di controllo e pin collegati. Un nodo di attività strutturato è visualizzato come un rettangolo
tratteggiato con gli angoli arrotondati che racchiude i propri nodi e flussi, al di sopra del quale è visualizzata la
parola chiave <<structured>>.
Partizioni di attività
Una partizione di attività è un modo di raggruppare i nodi ed i flussi di un'attività in base ad alcune
caratteristiche condivise. In UML 1.x, i raggruppamenti (considerati come partizioni) erano utilizzati nei diagrammi di
attività per raggruppare delle azioni in base ad alcuni criteri - ad esempio, nella modellazione del business, per
organizzazione di esecuzione. UML 2.0 estende questa funzione di partizione a più dimensioni per i diagrammi di
attività e fornisce un'ulteriore notazione in modo che, ad esempio, sia possibile assegnare alle singole azioni il nome
della partizione a cui appartengono. Il diagramma riportato di seguito illustra un esempio di raggruppamenti a più
dimensioni visualizzati in base a UML 2.0, in cui le azioni sono raggruppate in base all'ubicazione ed alla
responsabilità.
Esempio di partizioni di attività mediante raggruppamenti a due dimensioni
Differenze della semantica
La semantica del flusso di token ed il parallelismo illimitato dei modelli di attività UML 2.0 richiedono che il
modeler abituato a UML 1.x presti attenzione durante la creazione di nuovi modelli o la conversione di modelli
esistenti, per accertarsi che il risultato dell'esecuzione sia quello desiderato. Ad esempio, nell'esempio
processPassenger sopra riportato, il passeggero che esegue il check in potrebbe essere un membro frequent flyer; in
questo caso, l'agente deve assegnare al passeggero delle miglia frequent flyer, come illustrato di seguito in un
frammento del modello UML 1.x.
Utilizzo della transizione simultanea protetta
Il posizionamento di una guardia nella transizione simultanea facoltativa significa che, in UML 1.x, la transizione non
viene mai avviata ed il sistema funziona come se la transizione non sia visualizzata nel modello; di conseguenza,
quando le due altre transizioni vengono completate, l'esecuzione continua dopo l'unione. In UML 2.0, se il passeggero
non è un frequent flyer, nessun token raggiungerà l'unione lungo tale flusso ed il modello si blocca perché l'unione
attende i token su tutti i propri flussi prima di continuare. Il modello deve essere creato nel modo riportato di
seguito, con la condizione considerata nello stesso modo in cui è considerato il flusso di gestione dei bagagli. E'
possibile posizionare le guardie direttamente sui flussi simultanei se si è sicuri che da tali flussi non dipendano
unioni successive.
Utilizzo dei nodi di unione e decisioni invece del flusso simultaneo protetto
Il diagramma di collaborazione UML 1.x è stato ridenominato in diagramma di comunicazione in UML 2.0. Non
esistono differenze di semantica dalle versioni precedenti. Il diagramma di comunicazione si basa sul diagramma di
collaborazione precedente ed è ancora un tipo di diagramma di interazione.
Notazione
Un diagramma di comunicazione concentra la propria attenzione sull'interazione tra i cicli di vita. E' visualizzato
come un grafico i cui nodi sono rettangoli che rappresentano parti di una classe strutturata o ruoli di una
collaborazione. Viene utilizzato una cornice rettangolare intorno al diagramma con un nome in una sezione nell'angolo
superiore sinistro; questa è una modifica della notazione dalle versioni UML precedenti.
-
I nodi corrispondono ai cicli di vita in un'interazione.
-
Le righe tra le parti rappresentano i connettori che formano i percorsi di comunicazione.
-
Sui connettori possono essere visualizzate delle molteplicità.
-
I messaggi tra le parti sono visualizzati mediante frecce con etichette accanto alle righe del connettore.
Un diagramma di comunicazione viene utilizzato per modellare le interazioni che rappresentano l'implementazione di
un'operazione o di un caso di utilizzo.
Esempio di un diagramma di comunicazione:
Esempio di un diagramma di comunicazione per un sistema ordinante
In UML 2.0, un componente è indicato da un simbolo di classe senza i due rettangoli sporgenti, come definito in UML
1.4. Viene utilizzato invece uno stereotipo del <<componente>>. Come opzione, è possibile utilizzare
un'icona del componente simile all'icona di UML 1.4 nell'angolo in alto a destra del simbolo del componente.
UML 2.0 definisce un componente come una classe strutturata: la collaborazione tra gli elementi nella struttura interna
(parti) può essere modellata per descrivere meglio il funzionamento. Le parti sono collegate mediante connettori. E'
possibile utilizzare le porte per incrementare il livello di incapsulamento di un componente mediante le relative
interfacce fornite e richieste. Fare riferimento a Concetto: Componente
e Concetto: Classe strutturata per ulteriori informazioni.
Le versioni precedenti di UML definivano uno speciale elemento di modellazione chiamato sottosistema,
modellato come un pacchetto con interfaccia. Inoltre, i componenti erano utilizzati per strutturare il modello
nell'architettura fisica. In UML 2.0, i componenti sono utilizzati in senso ampio, tra tutte le parti del modello. Per
questo motivo, non è più necessario un elemento speciale per modellare i sottosistemi. Le sezioni separate per la
realizzazione e la specifica del sottosistema in UML 1.x sono diventati stereotipi separati (rispettivamente
<<realizzazione>> e <<specifica>>) applicati ai componenti in UML 2.0. Un altro nuovo
stereotipo del componente è <<sottosistema>>, indicato per modellare componenti su larga scala.
Il RUP suggerisce di utilizzare i componenti per modellare i sottosistemi (fare riferimento a Linea guida: Sottosistema di progettazione per ulteriori informazioni).
Le architetture possono avere una collaborazione specifica tra i propri elementi, con parti e connettori non
necessariamente conosciuti al momento della progettazione. Un tipico diagramma di classe (come altri diagrammi statici)
non è sufficiente per rappresentare i ruoli, le responsabilità, le relazioni e le regole applicati a tali elementi.
Per risolvere tali problemi, UML 2.0 ha aggiunto il diagramma di struttura composta. Tale diagramma può rappresentare
la struttura interna di una classe strutturata (ad esempio, un componente o una classe), includendo i punti di
interazione della classe strutturata in altre parti del sistema. Esso mostra la configurazione delle parti che eseguono
in combinazione il funzionamento della classe strutturata contenente.
I diagrammi di struttura composta sono utilizzati per visualizzare il contenuto interno delle classi strutturate (fare
riferimento a Concetto: Classe
strutturata per dettagli ed esempi di diagrammi di struttura composta).
UML 2.0 dispone di diverse nuove funzioni per i diagrammi di sequenza:
-
I frammenti forniscono una semantica più chiara per il funzionamento all'interno di un diagramma di sequenza. Un
frammento combinato incapsula parti di un diagramma di sequenza, in cui è possibile modellare i flussi separati,
illustrando il modo in cui le condizioni hanno determinato percorsi di esecuzione alternativi.
-
Le ricorrenze dell'interazione consentono di suddividere le interazioni in parti utilizzabili nuovamente. Questo è
un modo utile per condividere parti di un'interazione tra diverse altre interazioni.
-
In UML 1.x, una possibile rappresentazione dei loop era quella di utilizzare la condizione di loop scritta in una
Nota. La Nota era collegata al messaggio o alla serie di messaggi per essere eseguita quando la condizione di loop
era vera. In UML 2.0, è disponibile una rappresentazione specifica per i loop.
-
In UML 2.0, i diagrammi di sequenza possono indicare il modo in cui gli oggetti vengono creati oppure
distrutti.
-
L'esecuzione della ricorrenza illustra il punto principale del controllo eseguito da un oggetto quando riceve il
messaggio.
Grazie alle nuove funzioni per la rappresentazione di frammenti, ricorrenze di interazione e loop, i diagrammi di
sequenza possono essere utilizzati in due formati:
-
Formato istanza: descrive in dettaglio uno scenario specifico, illustrando una possibile interazione, senza
condizioni, rami o loop. Questo formato è utilizzato per rappresentare uno scenario di caso di utilizzo. Scenari
differenti dello stesso caso di utilizzo sono rappresentati in diagrammi di sequenza differenti. I tool di
modellazione che supportano la semantica UML 1.x consentono solo questo tipo di rappresentazione.
-
Formato generico: descrive tutte le alternative possibili in uno scenario, utilizzando le nuove funzioni di UML
2.0, come condizioni, rami e loop. Questo formato può essere utilizzato per rappresentare diversi scenari dello
stesso caso di utilizzo in un diagramma di sequenza unico.
La figura riportata di seguito mostra un esempio di diagramma di sequenza che modella diversi scenari. Il frammento
alt mostra due possibili alternative della sequenza di messaggi, in base al fatto che una condizione
sia soddisfatta oppure no.
Esempio: Diagramma di sequenza che illustra rami, loop e condizioni
|