LABORATORIO DI INFORMATICA
Ingegneria Informatica
a.a. 2002-2003 -2° Ciclo
Unified Modeling Language
1
Unified Modeling Language
Metodi e Modelli
La necessità di utilizzare metodi di progettazione software
deriva dal fatto che i progettisti devono considerare di:
• capire come fare il loro lavoro
• spiegare il loro lavoro ad altri
• capire quando l’altrui lavoro gli viene spiegato
In generale un metodo per lo sviluppo del software descrive
come modellare e costruire i sistemi software in modo
affidabile e riproducibile. Esso cioè permette la costruzione di
modelli a partire da elementi di modelli che costituiscono i
2
concetti fondamentali per rappresentare i sistemi.
Unified Modeling Language
I metodi di progettazione software hanno seguito due
strade:
• Metodi Funzionali
• Metodi Object Oriented
Negli ultimi anni il secondo approccio è stato quello più
seguito ed ha portato alla definizione di un linguaggio
universale per la costruzione di modelli Object Oriented
detto Unified Modeling Language (UML). Questo
linguaggio è stato sottoposto a standardizzazione da parte
dell’ente Object Management Group (OMG).
3
Unified Modeling Language
Il metodo object Oriented esegue la decomposizione di un
sistema in oggetti collaboranti.
Un modello costituisce una unità di base per lo sviluppo:
esso è altamente auto consistente ed è debolmente legato ad
altri modelli attraverso i link di navigazione.
Di norma un modello è relativo ad una specifica fase dello
sviluppo ed è costituito da elementi di modelli.
I modelli definiti in UML sono elencati di seguito.
4
Unified Modeling Language
• Il modello delle classi che cattura la struttura statica
• Il modello degli stati che esprime l’ambiente dinamico di
un oggetto
• Il modello dei casi d’uso che descrive i requisiti dell’utente
• Il modello delle interazioni che rappresenta gli scenari ed i
passaggi di messaggi
• Il modello dell’implementazione che mostra le unità di
lavoro
• Il modello di distribuzione che fornisce dettagli che
riguardano come processare l’allocazione.
5
Unified Modeling Language
Molte prospettive differenti possono essere costruite per un modello di
base, ciascuna delle quali mostra tutto o parte del modello e ciascuna ha
uno o più corrispondenti diagrammi. UML definisce nove tipi di
diagrammi:
• Diagrammi delle sequenze
• Diagrammi delle collaborazioni
• Diagrammi degli oggetti
• Diagrammi delle transizioni di stato
• Diagrammi delle attività
• Diagrammi delle classi
• Diagrammi dei casi d’uso
• Diagrammi dei componenti
• Diagrammi delle allocazioni
6
Unified Modeling Language
Meccanismi comuni
UML definisce un piccolo numero di meccanismi comuni che possono
essere utilizzati in tutti i diagrammi. Questi meccanismi sono:
• Gli Stereotipi
Ciascun elemento di modello può avere uno o più stereotipi quando
la semantica di base dell’elemento non è più sufficiente. Uno
stereotipo di un elemento si ottiene aggiungendo all’elemento la
definizione che ne permette l’estensione tra le parentesi << e >>,
come in: <<uses>>, <<extends>>, ..
• I Valori Etichettati (Tagged Values)
Un valore etichettato è una coppia (nome, valore) che descrive una
proprietà di un elemento di modello. Un valore etichettato modifica
la semantica dell’elemento.
7
Unified Modeling Language
• Note
Una nota è un commento applicato ad uno o più elementi di modello.
Una nota può essere trasformata in una costrizione usando uno
stereotipo.
• Costrizioni (Constraints)
Una costrizione è un qualsiasi tipo di relazione semantica tra
elementi di modello. UML non definisce una sintassi ad eccezione
del fatto che esse devono apparire tra parentesi graffe.
• Dipendenze
La relazione di dipendenza definisce una relazione di uso
unidirezionale tra due elementi di modello, riferiti, rispettivamente,
come la sorgente e l’obiettivo della relazione.
8
Unified Modeling Language
• Dicotomia Tipo/Istanza e Tipo/Classe
Molti elementi di modello presentano le suddette dicotomie. Nella
prima il tipo caratterizza l’essenza dell’elemento e l’istanza, con i
suoi valori, è una manifestazione di quel tipo. Nella seconda si ha
una suddivisione tra la specifica di un elemento che è descritta dal
tipo e l’implementazione della specifica che è fornita dalla classe.
• Tipi di dato
I tipi di dato sono tipi primitivi senza sottostrutture. In UML sono:
Boolean (true, false), Expression, Multiplicity (0..1, 1..10, 0..*, ..),
Name
(simple_name{‘.’composite_name},
package_name{‘::’
simple_name}), Integer, String, Time, Uninterpreted.
9
Unified Modeling Language
Packages
Il package fornisce un meccanismo generale per suddividere i modelli e
raggruppare gli elementi dei modelli. Un package si rappresenta come un
folder:
Ciascun package corrisponde ad un sottoinsieme di un modello e
contiene gli elementi del diagramma associato. Un package può
contenere altri package. Ad un dato livello un package può contenere sia
altri package che altri elementi del modello.
10
Unified Modeling Language
Un elemento contenuto in un package può anche apparire in un altro
package nella forma di elemento importato per mezzo di una relazione di
dipendenza tra package.
Una relazione di dipendenza tra due package significa che almeno un
elemento nel package client usa i servizi offerti da almeno un elemento
del package fornitore (supplier).
L’operatore :: permette di specificare un elemento che è definito in un
contesto diverso dal contesto corrente.
Ciascun elemento contenuto in un package ha un parametro che indica se
l’elemento può essere visto al di fuori del package (public) o no
(implementation).
11
Unified Modeling Language
Nota: Per ragioni di compilazione devono essere evitate le dipendenze
incrociate o circolari tra package. Alcuni package, utilizzati da tutti gli
altri package, sono detti globali e per essi non è necessario indicare
graficamente le relazioni di dipendenza.
12
Unified Modeling Language
Diagramma delle Classi
Le classi sono rappresentate da rettangoli a compartimenti. Il primo
compartimento contiene il nome della classe. Gli altri due compartimenti
contengono rispettivamente gli attributi della classe e le sue operazioni.
Ogni compartimento, ad eccezione di quello del nome della classe, può
essere soppresso.
equivale a:
Nel compartimento del nome della classe possono esserci stereotipi e
proprietà che alterano la semantica generale della classe. Le proprietà
possono essere valori associati all’elemento del modello come attributi,
associazioni e tagged value.
13
Unified Modeling Language
UML definisce i seguenti stereotipi di classe:
<<signal>>
un evento che attiva una transizione entro una
macchina a stati.
<<interface>>
una descrizione di operazioni visibili.
<<metaclass>>
la classe di una classe.
<<utility>>
una classe ridotta al concetto di modulo e che non
può essere istanziata.
14
Unified Modeling Language
I compartimenti dopo quello del nome della classe contengono attributi
e operazioni, descritti rispettivamente con le sintassi:
Attribute_Name : Attribute_Type = Initial_Value
Operation_Name(Argument_Name :Argument_Type =Default_Value, ..)
: Return_Type
E’ sempre possibile ridurre le suddette descrizioni ai soli elementi di
volta in volta necessari, ad esempio limitandosi ai soli nomi di Attributi e
Operazioni. Il livello di visibilità di Attributi e Operazioni può essere
rappresentato facendo precedere la loro dichiarazione con i caratteri +, #
e – , rispettivamente per i livelli: pubblico, protetto e privato e
sottolineandoli nel caso di visibilità globale.
15
Unified Modeling Language
UML rappresenta le interfacce usando piccoli cerchi connessi con una
linea all’elemento che fornisce il servizio descritto con l’interfaccia:
Le interfacce possono anche essere rappresentate usando le classi
stereotipate:
Un template di classe viene poi rappresentato come una classe in cui il
parametro formale appare in un rettangolo tratteggiato, come segue:
16
Unified Modeling Language
Associazioni
Le associazioni rappresentano relazioni strutturali tra classi di oggetti. Le
associazioni sono rappresentate da una linea che collega le classi
associate.
Un’associazione può essere denominata. L’esperienza raccomanda di
denominare le associazioni utilizzando una forma verbale. La direzione
in cui il nome dovrebbe essere letto può essere indicata usando il
simbolo > puntato verso la classe designata dal costrutto verbale.
>
Le due parti finali di un’associazione sono chiamate ruoli. Il ruolo
descrive come una classe vede un’altra per mezzo dell’associazione. Un
ruolo può essere denominato.
17
Unified Modeling Language
Molteplicità delle Associazioni
Ciascun ruolo di un’associazione ha un valore di molteplicità che indica
quanti oggetti della data classe possono essere linkati ad un oggetto
dell’altra classe. Questo valore può essere assegnato come segue:
1
uno e solo 1
0..1
zero o 1
M..N da M a N (interi naturali)
*
da 0 ad ogni intero positivo
0..*
da 0 ad ogni intero positivo
1..*
da 1 ad ogni intero positivo
18
Unified Modeling Language
Costrizioni sulle Associazioni
La costrizione {ordered} sul ruolo specifica una relazione ordinata degli
oggetti linkati:
La costrizione {subset} indica che un insieme di link è incluso in un
altro:
La costrizione {exclusive or} indica che per un dato oggetto solo una
singola associazione di un dato gruppo è valida:
Un’associazione (riflessiva) può anche linkare una classe a se stessa:
19
Unified Modeling Language
Classi di Associazioni
Un’Associazione può essere rappresentata da una classe, a sua volta
associabile ad altre classi, per aggiungere attributi ed operazioni
all’Associazione. La notazione usa una linea punteggiata per collegare
una classe ad un’Associazione:
Una associazione che contiene attributi, ma non è associata ad altre
classi, è detta Associazione di Attributo e non viene identificata con un
nome specifico:
>
20
Unified Modeling Language
Associazione N-aria
Una classe può essere linkata a più di un’altra classe. Questo si
rappresenta con una figura multilato con gli spigoli puntati verso i vari
componenti dell’associazione. Nel caso di una relazione tra tre classi e
con una classe di associazione si ha la seguente rappresentazione:
Elevando l’Associazione a livello di classe, con in più la costrizione
{ternary association} che specifica la contemporaneità dell’istanziazione
dei vari rami, il caso sopra riportato può essere rappresentato come
segue:
21
Unified Modeling Language
Qualificatori di Associazione
La qualificazione di un’Associazione consiste nella selezione di un
sottoinsieme degli oggetti dall’insieme degli oggetti che partecipano ad
un’associazione. Questa restrizione è fatta con un attributo, detto
Qualificatore, usato congiuntamente ad un oggetto della classe sorgente e
rappresentato in un rettangolo alla fine dell’Associazione:
La figura che segue mostra l’effetto del Qualificatore:
A
22
Unified Modeling Language
Aggregazioni
Un’Aggregazione è un’Associazione asimmetrica in cui una delle
estremità gioca un ruolo più importante dell’altra. Essa si rappresente
con un piccolo rombo in corrispondenza dell’aggregato:
I criteri per preferire un’Aggregazione ad una Associazione sono:
• Una classe è parte di un’altra classe
• I valori degli attributi di una classe si propagano all’altra
• Un’azione su una classe implica un’azione anche sull’altra
• Gli oggetti di una classe sono subordinati agli oggetti dell’altra
Un’Aggregazione può avere la molteplicità dal lato della classe
aggregata. Segue l’esempio di proprietà in comune:
Owner
23
Unified Modeling Language
Composizione
La Composizione è una Aggregazione in cui gli attributi di una classe
sono fisicamente contenuti nella classe aggregata. Essa è cioè
un’Aggregazione per valore ed è semanticamente equivalente ad un
attributo. Per questa ragione la molteplicità della classe aggregata può
essere solo 0 o 1. Si utilizza quando un attributo partecipa ad altre
relazioni nell’ambito del modello. Si rappresenta con un piccolo rombo
nero:
Segue un esempio per il cso di un automobile:
24
Unified Modeling Language
Generalizzazione
La relazione di Generalizzazione esprime il fatto che un elemento di una
classe è anche descritto da un’altra classe (ossia, dal tipo di un’altra
classe). La Generalizzazione esprime cioè una relazione di
classificazione tra un elemento generale ed uno più specifico. La
relazione di Generalizzazione è rappresentata con una freccia che punta
dalla classe più specializzata a quella più generale. Gli esempi che
seguono rappresentano la stessa cosa:
La Generalizzazione viene spesso implementata con la relazione di
ereditarietà tra classi, ma essa in UML ha un aspetto più astratto che può
corrispondere ad altre implementazioni.
25
Unified Modeling Language
Se una classe ha più di una superclasse si può avere una
Generalizzazione multipla, come nell’esempio che segue:
Una classe può essere specializzata secondo diversi simultanei criteri.
Per indicare i particolari criteri di specializzazione essi vengono riportati
come “discriminatore” sui rispettivi collegamenti di Generalizzazione:
26
Unified Modeling Language
Le relazioni di Generalizzazione possono essere caratterizzate da
“costrizioni” che sono rappresentate con espressioni tra parentesi graffe
direttamente allocate sulla Generalizzazione interessata o collegate a
tutte le Generalizzazioni contemporaneamente interessate con una linea
tratteggiata.
La relazione di Generalizzazione è per default una decomposizione
esclusiva e quindi questo tipo di costrizione può non essere indicato.
Altri tipi possibili di costrizioni sono di seguito indicate.
27
{disjoint}
Unified Modeling Language
indica che una classe discendente dalla classe A può
essere solo discendente da una delle sottoclassi di A
{overlapping} indica che una classe discendente dalla classe A
appartiene al prodotto Cartesiano delle sottoclassi di A
{complete}
indica che la generalizzazione è terminata e non possono
essere aggiunte altre sottoclassi
{incomplete} specifica una generalizzazione estensibile
Nell’esempio che segue viene mostrato come la classe Moped
(Ciclomotore) è prodotto cartesiano delle sottoclassi Engine e Land della
classe Vehicle:
28
Unified Modeling Language
Classi Astratte
Una classe Astratta è una classe che non può essere direttamente
istanziata. Essa è una specifica generale di tipo allo scopo di gestire
oggetti che sono istanze di una o più di una delle sue sottoclassi. Una
classe viene specificata in UML come classe astratta utilizzando la
proprietà Booleana: Abstract.
Per convenzione i nomi delle classi Astratte sono scritti in corsivo.
29
Unified Modeling Language
Diagramma dei Casi d’Uso (Use Case)
I Casi d’Uso descrivono il comportamento di un sistema dal punto di
vista dell’utente, usando azioni e reazioni e permettendo, così, la
definizione delle relazioni tra il sistema e l’ambiente. Ciascun Caso
d’Uso è un’immagine della funzionalità del sistema che è attivata in
risposta ad uno stimolo di un attore esterno. Il modello Use Case
comprende gli attori, il sistema e i casi d’uso. Gli attori sono
rappresentati da sagome di persone che attivano i casi d’uso,
rappresentati come ellissi contenute nel sistema:
30
Unified Modeling Language
Gli Attori
Un attore rappresenta un ruolo interpretato da una persona o cosa che
interagisce con il sistema (utente). Il nome dell’attore descrive il ruolo
interpretato dall’utente. La stessa persona fisica può interpretare il ruolo
di più di un attore. La determinazione degli attori è molto importante e
permette la specifica dei limiti del sistema in modo incrementale. Le
principali categorie di attori sono:
• Attori principali
persone che usano le funzioni principali del
sistema
• Attori secondari
persone che eseguono compiti di amministrazione
o manutenzione
• Hardware esterno
gli apparati che devono essere usati perché fanno
parte del dominio dell’applicazione
• Altri sistemi
gli altri sistemi con cui il sistema deve
interagire.
31
Unified Modeling Language
I Casi d’Uso
I casi d’uso sono determinati osservando e specificando, attore per attore,
le sequenze di interazione, dette “scenari”, dal punto di vista dell’utente.
Essi sono descritti in termini di informazioni scambiate e di modi di
usare il sistema. I casi d’uso devono essere pensati come classi le cui
istanze sono gli scenari: ogni volta che un attore interagisce con il
sistema il caso d’uso istanzia una scenario.
Nota: i casi d’uso non sono solo necessari per la definizione dei requisiti
di un sistema, ma sono presenti con continuità lungo tutto il ciclo di vita
di un prodotto software. Da questo punto di vista i casi d’uso servono ad
esempio per navigare attraverso le classi e gli oggetti che collaborano a
soddisfare un requisito fino ai test che verficano che il sistema esegua i
suoi compiti correttamente.
32
Link
Unified Modeling Language
UML definisce tre tipi di link per attori e Use Case:
La relazione “Comunica”: è la sola relazione tra Attore e Casi d’Uso. E’
rappresentata con una linea continua tra Attore e Caso d’Uso:
La relazione “Usa”: descrive che una istanza del Caso d’Uso sorgente
comprende anche il comportamento descritto con il Caso d’Uso di
destinazione:
La relazione “Estende”: descrive che il Caso d’Uso sorgente estende il
comportamento del Caso d’Uso destinazione:
33
Unified Modeling Language
Esempio
Quello che segue è un esempio di diagramma di Casi d’Uso in cui sono
rappresentte tutte le relazioni possibili per gli Attori e i Casi d’Uso.
34
Unified Modeling Language
Diagramma degli Oggetti
Il diagramma degli Oggetti mostra un contesto, ad esempio prima o dopo
un’interazione, illustrando Oggetti e link tra Oggetti. La notazione
utilizzata è derivata dal diagramma delle classi in cui gli elementi che
sono istanze sono sottolineati. Un oggetto è rappresentato perciò da un
rettangolo che può contenere il nome dell’oggetto, il nome dell’oggetto e
della classe (separati da “:”), o, infine, solo il nome della classe
(preceduto da “:”):
Il nome della classe può contenere il path completo costituito dai nomi
dei vari packages contenitori separati da”:”:
35
Unified Modeling Language
Lo stereotipo della classe può riapparire nel compartimento dell’oggetto
in forma testuale tra le parentesi << e >> sopra il nome dell’oggetto:
Infine i rettangoli che simbolizzano gli oggetti posso avere un secondo
compartimento che contiene i valori degli attributi:
36
Unified Modeling Language
Link tra Oggetti
Gli Oggetti sono connessi attraverso Link che sono istanze delle
Associazioni tra le classi degli oggetti presi in considerazione. Il
diagramma degli Oggetti:
È un’istanza del
diagramma delle
classi:
I Link possono essere non solo binari, ma collegare più di due oggetti (ad
esempio Link ternari). La molteplicità può anche essere espressa
sovrapponendo più rappresentazioni leggermente sfalsate dello stesso
oggetto:
37
Unified Modeling Language
Oggetti composti
Oggetti composti da sotto-oggetti possono essere rappresentati usando un
oggetto composto allo scopo di ridurre la complessità del diagramma. Gli
oggetti composti sono rappresentati con gli oggetti componenti che
sostituiscono gli attributi:
:
Gli oggetti composti sono in genere istanze di classi composte, ossia
costruite da altre classi usanti la forma più forte dell’aggregazione:
È un’istanza del
diagramma delle
classi:
38
Unified Modeling Language
Il Diagramma degli Oggetti e il relativo diagramma delle Classi
Tutte le scritte che appaiono in un diagramma delle classi (nomi delle
associazioni, dei ruoli, delle composizioni, ..) possono essere mantenute
nei corrispondenti diagrammi degli Oggetti, ad eccezione della
molteplicità che è rappresentata direttamente dai link. Anche il valore dei
qualificatori delle associazioni può essere mantenuto, come mostra
l’esempio che segue:
39
Unified Modeling Language
Diagramma delle Collaborazioni
Questo diagramma è un’estensione del diagramma degli oggetti poiché
esprime, oltre al contesto di un gruppo di oggetti (per mezzo di oggetti e
link) anche le interazioni tra questi oggetti (rappresentando la diffusione
dei messaggi). I messaggi sono rappresentati con scritte lungo i link che
connettono gli oggetti e con frecce puntate verso chi riceve il messaggio.
I messaggi possono essere numerati per indicare l’ordine di sequenza:
40
Unified Modeling Language
I diagrammi delle collaborazioni mostrano le interazioni tra oggetti e
simultaneamente le relazioni strutturali che facilitano queste interazioni.
Oggetti e link che durante una interazione sono creati o cancellati
possono essere rispettivamente soggetti alle “costrizioni” {new} o
{deleted}. Oggetti che sono invece creati e cancellati nell’ambito della
stessa interazione sono soggetti alla costrizione {transient}:
Quando un gruppo di oggetti è il destinatario di uno stesso messaggio si
può usare una notazione simile a quella di molteplicità. Vedi di seguito
un esempio a partire dal relativo diagramma di classe:
41
Unified Modeling Language
La notazione del diagramma delle collaborazioni ammette che vengano
presentati nel relativo ambito anche gli attori, allo scopo di rappresentare
l’avvio delle interazioni da parte di elementi esterni al sistema.
Gli oggetti che gestiscono un flusso di controllo sono detti Oggetti Attivi.
In un diagramma delle collaborazioni gli Oggetti Attivi sono
rappresentati con una cornice più marcata rispetto agli oggetti passivi.
42
Unified Modeling Language
Rappresentazione dei Messaggi
Finora le etichette associate ai messaggi sono state presentate in modo
semplificato con casi particolari. In realtà la sintassi di un messaggio è
più complicata ed ha la seguente forma generale:
synchronization sequence ‘:’ result ‘:=’ name
• synchronization
La sintassi di synchronization è:
rank {‘,’ synchronization} ‘/’
Dove rank è dato da:
[integer | name of flow of execution] { ‘.’ rank}
arguments
Nell’esempio che segue il messaggio Message viene inviato quando
le trasmissioni A.1 e B.3 sono state soddisfatte.
43
• sequence
Unified Modeling Language
La sequence specifica il livello di nesting della diffusione del
nell’ambito dell’interazione. La sintassi di sequence è:
rank [recurrence]
Dove recurrence rappresenta iterazioni o condizioni rispettivamente
rappresentate con le sintassi:
‘*’ ‘[’ iteration clause ‘]’ block
‘[’ condition clause ‘]’ block
Sia iteration clause che condition clause si esprimono in formato
libero e danno rispettivamente le condizioni di iterazione e le
condizioni che convalidano l’invio dei messaggi nell’ambito di
block.
44
• result
Unified Modeling Language
result consiste in una lista di valori, espressi in formato libero,
restituiti dal messaggio.
• name
Il name del messaggio spesso coincide con una operazione definita
nella classe dell’oggetto destinazione del messaggio.
• arguments
Gli argomenti, scritti in pseudocode o nel linguaggio di codifica,
sono una lista di parametri del messaggio. Si può usare anche la
notazione sotto riportata. Nome e argomenti del messaggio
identificano l’azione da attivare nell’oggetto destinazione.
45
Unified Modeling Language
Diagramma delle sequenze
Il diagramma delle sequenze mostra le interazioni tra oggetti da un punto
di vista temporale. Un oggetto viene rappresentato con un rettangolo ed
una barra verticale chiamata “lifeline” (cavo di salvataggio) dell’oggetto.
Gli oggetti comunicano scambiandosi messaggi, rappresentati da frecce
orizzontali, tracciate dalla lifeline dell’oggetto che invia, alla lifeline
dell’oggetto che riceve. L’ordine di invio dei messaggi è indicata dalla
loro posizione verticale. L’asse verticale può essere etichettato per
esprimere più precisamente le costrizioni temporali.
46
Unified Modeling Language
Esistono due principali categorie di trasmissione di messagi:
• Trasmissioni sincrone, per le quali il trasmettitore è bloccato ed aspetta
fino a che l’oggetto chiamato ha finito di processare il messaggio. Questa
trasmissione è rappresentata con una freccia.
• Trasmissioni asincrone, per le quali il trasmettitore non si blocca e
continua l’esecuzione. Questa trasmissione è rappresentata con mezza
freccia.
Una freccia che rappresenta un messaggio può anche essere disegnata
diagonalmente per indicare un ritardo di trasmissione non trascurabile:
47
Unified Modeling Language
Un oggetto può anche inviare un messaggio a se stesso, generalmente per
indicare l’avvio di una attività al suo interno. In questo modo si possono
rappresentare le interazioni interne che coinvolgono oggetti contenuti
entro un oggetto composto:
La creazione di un oggetto si rappresenta facendo cadere le freccia del
messaggio che lo crea sul rettangolo che rappresenta l’oggetto. La
cancellazione è rappresentata dalla lettera X:
48
Unified Modeling Language
L’attivazione di un oggetto, ossia il tempo durante il quale esso esegue
un’azione si rappresenta con una striscia rettangolare posizionata lungo
la lifeline dell’oggetto:
Tenendo conto di ciò si possono presentare vari casi di trasmissione
sincrone (con ritorno implicito al trasmittente), asincrone (con ritorno da
esplicitare) e asincrone dopo suicidio, che sono di seguito mostrate:
49
Unified Modeling Language
Il caso particolare della trasmissione di un messaggio recursivo è
rappresentato con la replica della striscia rettangolare. L’oggetto appare
come se fosse attivo una quantità multipla di volte:
50
Unified Modeling Language
Struture di Controllo
I diagrammi di sequenza possono essere completati da note testuali
espresse in formato libero. Il momento di emissione di un messaggio,
detto transizione, può essere specificato in prossimità del punto di
partenza della freccia utilizzata per rappresentare il messaggio. Questo
nome può essere usato per stabilire delle condizioni temporali. Quando
per un messaggio c’è un tempo di trasmissione non trascurabile i tempi
di emissione e ricezione sono evidenziati con una coppia: nome, nome’.
51
Unified Modeling Language
L’utilizzo di pseudocode sul lato sinistro del diagramma consente la
rappresentazione di cicli o salti. Le rappresentazioni che seguono
indicano, in due modi, la trasmissione senza interruzione del messaggio
Message finchè la condizione X è vera:
L’esempio che segue è invece relativo ad un salto condizionato:
52
Unified Modeling Language
Anche nel caso di scelte condizionate lo pseudocode può essere sostituito
da condizioni scritte davanti al messaggio, come rappresentato di
seguito:
Salti condizionati sul lato di destinazione del messaggio sono invece
rappresentati raddoppiando la lifeline dell’oggetto destinazione.
53
Unified Modeling Language
Diagramma delle Transizioni di Stato
Il comportamento degli oggetti di una classe può essere formalmente
descritto in termini di stati ed eventi usando una “macchina a stati” (State
Machine) connessa alla classe in considerazione:
Ciascun oggetto segue il comportamento descritto nella macchina a stati
associata alla sua classe ed è, ad un dato momento, in uno degli stati
caratteristici dei suoi stati dinamici. Oggetti che non hanno un
comportamento reattivo possono ritenersi sempre nello stesso stato e
quindi tali che la loro classe non possieda una macchina a stati.
La macchina a stati può essere usata per descrivere il comportamento di
gruppi di oggetti associando la macchina a stati ad una struttura mista, o
anche ad un caso d’uso.
54
Unified Modeling Language
Stati e Transizioni
Ciascun oggetto è ad un dato istante in uno stato particolare. Gli Stati di
un oggetto sono rappresentati come rettangoli con spigoli arrotondati;
ciascuno stato ha un nome che lo identifica:
Uno stato è l’immagine della combinazione istantanea dei valori
posseduti dagli attributi dell’oggetto e la presenza od assenza di link tra
l’oggetto considerato e gli altri oggetti. Nell’esempio che segue viene
riportato un diagramma delle classi, un corrispondente possibile
diagramma degli oggetti e i corrispondenti possibili stati per gli oggetti
della classe Person:
55
Unified Modeling Language
UML definisce una macchina a stati deterministica e quindi con un
preciso stato iniziale. Gli stati finali possono essere invece più di uno in
corrispondenza di differenti condizioni terminali, oppure nessuno nel
caso di assenza di stop. Lo stato iniziale è rappresentato con un grosso
punto nero, mentre uno stato finale è rappresentato da un grosso punto
nero circondato da un cerchio:
Il passaggio da uno stato ad un altro è descritto da una coonnessione
unidirezionale tra gli stati, detta Transizione. Essa viene attivata quando
accade un determinato evento nel dominio del problema. Una transizione
è rappresentata con una freccia che inizia dallo stato di partenza e
termina sullo stato di arrivo:
56
Unified Modeling Language
Eventi
Un evento corrisponde al verificarsi di una determinata situazione nel
dominio del problema. Un evento è usato per attivare il passaggio da uno
stato ad un altro. Un oggetto che si trovi in un determinato stato attende
il verificarsi di un evento per passare ad un altro stato:
La sintassi di un evento è la seguente:
Name_Of_The_Event (Parameter_Name : Type, ….)
Seguendo le suddette regole la macchina a stati della classe Person
dell’esempio precedente può essere la seguente:
57
Unified Modeling Language
La comunicazione per eventi è sempre asincrona, atomica ed
unidirezionale. Nel caso di oggetti si rappresenta come segue:
La comunicazione per eventi sincrona può essere rappresentata solo con
due scambi asincroni in direzioni opposte:
La suddetta comunicazione corrisponde ad una macchina a stati come
segue:
58
Unified Modeling Language
Guardie
Una Guardia (Guard) è una condizione Booleana che può o non può
convalidare lo scatto di una transizione in seguito ad un evento. La
condizione corrispondente ad una Guardia viene scritta dopo l’evento tra
parentesi quadre:
Le Guardie, che devono corrispondere a condizioni mutuamente
esclusive, permettono di mantenere il determinismo di una macchina a
stati anche quando uno stesso evento può far scattare più di una
transizione:
59
Unified Modeling Language
Operazioni, Azioni ed Attività
Una Transizione può essere etichettata con il nome di un’azione, ossia di
un’operazione definita nella specifica della classe, da eseguire quando la
transizione viene fatta scattare da un evento. Il nome dell’azione, che può
accedere sia ai parametri dell’evento che agli attributi dell’oggetto, è
separata dal nome dell’evento con “/”:
Anche uno Stato può contenere azioni. Queste sono eseguite quando si
assume lo stato (azioni descritte con la parola chiave “entry/”), quando si
lascia lo stato (parola chiave “exit/”) o in seguito ad un evento che
mantiene lo stato (parola chiave “Nome_Evento/”):
60
Unified Modeling Language
Un’operazione che viene eseguita quando un oggetto è in un determinato
stato ed il cui tempo d’esecuzione non può essere considerato istantaneo
prende il nome di Attività e viene identificata con la parola chiave “do/”:
A differenza delle Azioni le Attività possono essere interrotte dallo scatto
della transizione. In particolare le attività “cicliche” terminano solo
quando scatta la transizione. Le attività “sequenziali” fanno invece
scattare la transizione quando raggiungono la loro fine: questo tipo di
transizione è detta Transizione Automatica.
Gli stati possono anche contenere variabili espresse come attributi. Le
variabili degli stati appartengono alla classe associata alla macchina a
stati, ma possono essere mostrate quando sono manipolate da azioni o
attività.
61
Unified Modeling Language
Generalizzazione degli Stati
La complessità di un diagramma a stati può essere ridotta con la
Generalizzazione degli stati. Uno stato più generale (detto superstato) è
quello che raccoglie stati più specifici (detti sottostati) che ereditano dal
loro superstato alcune caratteristiche come le variabili di stato e le
transizioni esterne, ossia quelle che li collegano agli stati esterni al
superstato:
A differenza delle transizioni esterne in uscita dal superstato solo un
sottostato può ereditare dal superstato la transizione in entrata:
62
Unified Modeling Language
L’ultima rappresentazione, in cui una transizione collega livelli
gerarchici diversi (un superstato esterno con un sottostato interno), è
poco accettabile ed è preferibile sostituirla con una in cui viene definito
per i superstati un (pseudo)stato iniziale:
Per evitare di entrare nel dettaglio dei sottostati può essere utilizzata la
rappresentazione con “stubs” che nasconde la presenza dei sottostati
esprimendone però l’esistenza:
63
Unified Modeling Language
Aggregazione di Stati
L’aggregazione di stato è la composizione di uno stato con alcuni stati
indipendenti. Essendo l’aggregazione di tipo “and”, ciò vuol dire che
l’oggetto deve simultaneamente essere in tutti gli stati che cosituiscono
l’aggregazione. Aggregando in una macchina a stati ogni stato con un
altro indipendente si ottiene che l’evoluzione degli stati dell’oggetto
corrisponde a quello di due macchine a stati che operano in parallelo ed
in cui gli stati aggregati sono il risultato del prodotto cartesiano degli
stati delle due macchine:
64
Unified Modeling Language
Generalizzazione ed Aggregazione
La Aggregazione di stato e la Generalizzazione servono a semplificare la
rappresentazione delle macchine a stati. La Generalizzazione semplifica
per fattorizzazione, mentre l’Aggregazione semplifica per segmentazione
dello spazio degli stati. In particolare la riduzione di complessità
dell’Aggregazione risulta evidente dal seguente esempio: se una
macchina a stati può essere ridotta a tre macchine parallele ciascuna con
100 stati, la macchina con stati non aggregati avrebbe uno spazio degli
stati costituito dal prodotto cartesiano degli stati delle tre macchine e
quindi con 1.000.000 di stati da considerare.
65
Unified Modeling Language
Storia
La notazione speciale “H”, inserita in un punto qualsiasi di un superstato,
permette di memorizzare l’ultimo sottostato visitato e di ritornare ad esso
quando scatta la transizione che riconduce al superstato che lo
comprende. Con la notazione “H*” è anche possibile memorizzare
l’ultimo sottostato attivo a prescidere dal suo nesting:
H*
H
L’esempio che segue è un ciclo di lavapiatti:
H
66
Unified Modeling Language
Comunicazioni tra Oggetti
Le trasmissioni di messaggi tra due oggetti sono rappresentate,
nell’ambito del formalismo dei diagrammi a stati, con l’invio di un
evento tra le macchine a stati delle classi degli oggetti considerati. La
sintassi della trasmissione di un evento verso una classe assume la forma:
^ Target . Message (Arguments)
Dove Target si riferisce alla classe degli oggetti che sono obiettivo
dell’evento e Message è il nome del messaggio che l’obiettivo deve
acquisire. La sintessi completa di una transizione è perciò:
Event (Arguments) [Condition] / Action ^ Target . Message (Arguments)
L’esempio che segue è per un telecomando di televisore:
67
Unified Modeling Language
Creazione e Distruzione di un Oggetto
La creazione di un oggetto è rappresentata con l’invio di un evento di
creazione alla classe degli oggetti. Il nuovo oggetto comincia ad esistere
con lo stato iniziale descritto nell’ambito della macchina a stati della
classe. L’esempio che segue si riferisce alla registrazione di un nuovo
aereo ed alla sua distruzione:
La cancellazione di un oggetto si effettua quando il flusso di controllo di
una macchina a stati raggiunge, al livello gerarchico (di superstato) più
alto, uno stato finale.
68
Unified Modeling Language
Transizioni Temporizzate
Abbiamo già visto che con la keyword “do/” è possibile definire per uno
stato un’attività di durata prestabilita, al termine della quale può scattare
una transizione. Lo stesso meccanismo può essere rappresentato con
l’uso dell’evento generico di nome “after” seguito da un parametro che
specifica la durata dell’attesa. Quello che segue è un esempio di una
macchina per il deposito di moneta descritto sia con l’uso di “do/” per
l’attività dello stato che con l’uso di “after” per il ritardo dell’evento:
69
Unified Modeling Language
Diagramma delle Attività
Un diagramma di Attività è una variante dei diagrammi a Stati,
organizzato secondo le azioni e più orientato alla presentazione
dell’implementazione di un’operazione. In un diagramma di Attività si
privilegia quindi la presentazione delle Attività a scapito di Stati ed
Eventi. Un’Attività è presentata come uno stereotipo di Stato per mezzo
di un rettangolo con i lati minori arrotondati. Quello che segue è la
rappresentazione di un’Attività con il diagramma a stati a cui essa
corrisponde:
Ciascuna attività rappresenta
dell’operazione che la racchiude.
un
particolare
stato
nell’ambito
70
Unified Modeling Language
Le attività sono linkate da transizioni automatiche rappresetate con
frecce. Quando un’attività termina la transizione scatta e parte l’attività
successiva, per cui non è necessario denominare la transizione:
Le transizioni tra attività possono essere sottoposte a “guardie” con
condizioni Booleane mutuamente esclusive riportate in prossimità della
transizione di cui convalidano lo scatto. La stessa cosa può essere
rappresentata con lo stereotipo “decision” disegnato con un rombo da cui
escono le transizioni:
71
Unified Modeling Language
I diagrammi di Attività rappresentano le sincronizzazioni tra flussi di
controllo mediante le barre di sincronizzazione. Le transizioni relative
all’output di una barra di sincronizzazione scattano tutte
simultaneamente. Viceversa una barra di sincronizzazazione può essere
attraversata solo quando tutte le transizioni in input alla barra sono
scattate:
72
Unified Modeling Language
Per evidenziare le responsabilità nell’ambito dell’operazione descritta, i
diagrammi di attività possono essere organizzati in settori verticali
paralleli, detti swimlane:
73
Unified Modeling Language
In un diagramma di Attività un oggetto può essere rappresentato con
linee verticali uscenti da esso e le attività possono apparire lungo la sua
“lifeline”. Se poi un oggetto è manipolato da più attività, esso può
apparire più volte nell’ambito del diagramma. I flussi verso gli oggetti
sono rappresentati con frecce punteggiate. Queste frecce mettono cioè in
relazione l’oggetto con l’attività che lo crea e con le attività che lo
coinvolgono.
74
Unified Modeling Language
I diagrammi di Attività possono anche contenere Stati ed Eventi,
rappresentati nello stesso modo in cui essi sono rappresentati nei
diagrammi di stato. Per le transizioni inoltre le trasmissioni e le ricezioni
di segnali possono essere rappresentate con pentagoni, rispettivamente
convessi e concavi, collegati con una freccia rispettivamente all’oggetto
che riceve e a quello che trasmette:
75
Unified Modeling Language
Diagrammi dei Componenti
I componenti rappresentano tutti i tipi di elementi che riguardano il
risultato di un raggruppamento di applicazioni software: essi possono
essere semplici file o librerie caricate dinamicamente. Un componente
viene rappresentato per mezzo della sua “specifica” (ad esempio
l’interfaccia, o il file .h, di una classe) e del suo “body”
(l’implementazione, o il file .cpp, nel caso di una classe) utilizzando il
simbolo che segue:
Le relazioni di dipendenza tra componenti, rappresentate con frecce
tratteggiate che vanno dal body del client alla specifiction del supplier,
indicano che il client fa riferimento a servizi (in genere dipendenze di
compilazione) offerti dal supplier:
76
Unified Modeling Language
Processi
I Processi sono oggetti che hanno un loro flusso di controllo (o thread). I
Processi possono essere contenuti nell’ambito dei Componenti. Gli
stereotipi <<process>> e <<thread>> sono predefiniti in UML:
Subsystem
Per accelerare la realizzazione di applicazioni, vari componenti possono
essere raggruppati nell’ambito di packages in base a criteri logici ed
essere stereotipati come <<subsystem>>.
77
Unified Modeling Language
I Subsystem, che possono contenere componenti o altri Subsystem,
organizzano la vista implementativa di un sistema: i Subsystem
dovrebbero essere visti come i grossi mattoni per la costruzione del
sistema.
La decomposizione in Subsystem non è una decomposizione funzionale.
Dal punto di vista dell’utente le funzioni del sistema si esprimono
nell’ambito della vista dei Casi d’Uso. I Casi d’Uso sono tradotti in
interazioni tra Oggetti le cui Classi sono esse stesse incapsulate in
Categorie. Gli Oggetti che implementano le interazioni sono distribuiti
nelle varie categorie: il codice corrispondente è memorizzato in moduli e
Subsystem.
78
Unified Modeling Language
Diagrammi delle Allocazioni
I diagrammi delle Allocazioni mostrano la struttura fisica dei vari
componenti hardware (nodi) che compongono un sistema e
contemporaneamente la distribuzione dei programmi eseguibili su questo
hardware. Ciasuna risorsa hardware è rappresentata da un cubo:
La natura di un apparato può essere specificata usando uno stereotipo. Se
necessario l’utente ha la possibilità di definire altri stereotipi:
79
Unified Modeling Language
I vari nodi che appaiono in un diagramma di allocazioni sono connessi
tra di loro con linee che rappresentano le infrastrutture, implicitamente
bidirezionali, di comunicazione. La natura di queste infrastrutture può
essere specificata con uno stereotipo. I nodi corrispondenti a processori
mantengono il nome dei processi che contengono. Il nome dei processi
facilita il collegamento tra il diagramma delle allocazioni e quello dei
componenti. Ciascun processo nominato nel diagramma delle allocazioni
esegue un programma main con lo stesso nome di quello descritto nel
diagramma dei componenti.
80
Unified Modeling Language
I diagrammi di allocazioni possono mostrare classi di nodi o istanze di
nodi: la differenza grafica è che le istanze sono sottolineate.
81