LINGUAGGIO UML (Unified Modeling

Language)

Il linguaggio di modellizzazione UML (Unified Modeling

Language) – la cui prima versione fu definita nel 1996
a opera di Grady Booch, Jim Rumbaugh e Ivar
Jacobson – è un insieme di formalismi grafici
(diagrammi) che consente di definire e descrivere i
diversi aspetti di un sistema software, cioè
comportamenti e relazioni fra gli elementi del
software, in particolare se realizzato secondo il
paradigma a oggetti. L’obbiettivo dei diagrammi è
quello di costruire, con un linguaggio ben determinato,
un modello del software da realizzare visto da più
punti di vista diversi. L’insieme di tali punti di vista
costituirà quello che viene definito Visual Modeling,
ovvero la rappresentazione grafica del software
mediante i diagrammi.

Sono quattordici i diagrammi previsti dal linguaggio

UML nella sua ultima versione e fanno parte di tre
possibili gruppi:
 Diagrammi comportamentali, rappresentano delle
possibili scelte che dipendono dalle azioni;
 Diagrammi strutturali, sono statici e quindi non
prevede azioni o comportamenti che permettono
di prendere scelte diverse;
  Diagrammi di interazione, rappresentano come
alcuni elementi del software interagiscono fra di
loro.
Nel nostro lavoro scolastico abbiamo approfondito
l’utilizzo di quattro diagrammi ritenuti fondamentali
nella descrizione di un software. I suddetti modelli
sono:

1. Diagramma dei casi d’uso: è un diagramma

comportamentale che descrive le funzionalità
(cosa fa) di un sistema software (applicazione o
servizio) dal punto di vista dell’utente del sistema.
Gli utenti possono essere sia persone che altri
sistemi informatici e sono indicati con il termine
di “attori”, cioè chi usa il software.
Il diagramma dei casi d’uso che ho elaborato,
mostra le funzionalità del software, rappresentate
dagli ovali bianchi, mentre l’omino stilizzato
rappresenta l’attore. In particolare, il software
rappresentato, è un software di e-commerce.
L’utente ha la possibilità di invocare diverse
funzioni, nel nostro caso:
a. visualizza catalogo prodotti;
b. visualizza dettagli prodotto;
c. aggiungi prodotto al carrello;
d. acquisto prodotti carrello.
 Inoltre sono presenti due stereotipi:
I. La relazione di inclusione fra use case,
rappresentata da una linea tratteggiata con
indicazione dello stereotipo «include», che
indica che la funzione rappresentata da uno dei
due use case (quello alla base della freccia)
include completamente la funzione
rappresentata dall'altro (quello alla punta).

II. La relazione di estensione fra use case,

rappresentata da una linea tratteggiata con
indicazione dello stereotipo «extend», indica che
la funzione rappresentata dallo use case
"estendente" (alla base della freccia) può essere
impiegata nel contesto della funzione "estesa"
(lo use case alla punta), ovvero ne rappresenta
una sorta di arricchimento.

La sottile differenza fra i due stereotipi è la seguente:

1) «include» indica un frammento che
viene sempre eseguito durante l'esecuzione del
caso d'uso alla base della freccia;
2) «extend» indica un frammento che può essere
eseguito in determinate circostanze del caso
d'uso alla punta della freccia.
2. Diagramma delle classi: è un diagramma
strutturale, quindi statico, che descrive
l’architettura del software, ovvero il risultato della
progettazione del software stesso. Indica come
sono realizzate le classi, con i relativi attributi e
metodi, e le relazioni fra esse.
Con il diagramma delle classi
che ho elaborato, vengono rappresentate alcune
classi (prodotto, catalogo, carrello, ecc.). Con il
termine classe (rappresentata dalla forma
rettangolare), si indica nella programmazione ad
oggetti, un modello di un oggetto che farà parte
del software che si desidera realizzare e viene
definita descrivendo gli attributi, quindi le
proprietà dell’oggetto, e le azioni che possono
essere svolte su questo oggetto, ovvero i metodi.
Creare un modello significa delineare quali sono
gli elementi che descrivono un prodotto (codice,
titolo, prezzo, ecc.). Quindi la classe è un modello
del prodotto e il prodotto è definito dagli elementi
che prendono il nome di attributi. I metodi
(getCodice(), setPrezzo(), getQuantità(), ecc.),
sono, invece, delle funzioni che consentono di
svolgere delle operazioni sul prodotto. Dalla
classe, vengono istanziati nel software gli oggetti.
Prendendo ad esempio il nostro diagramma, dalla
classe CD, verranno creati gli oggetti CD, aventi,
nel nostro caso, valori regista, produttore, durata
e gli attributi della classe principale.
 Le diverse classi, infatti, sono collegate da frecce,
che indicano che le stesse possiedono tutti gli
attributi presenti nella classe principale, cioè la
classe prodotto. Dunque, la classe CD
rappresenterà come è fatto un generico CD,
l’oggetto CD è invece uno specifico CD, un
esemplare della classe CD, nel senso che
presenta un valore per ciascuno degli attributi
definiti dalla classe.

3. Diagramma delle attività: è un diagramma

comportamentale, illustra le fasi del flusso di
controllo di un sistema software, ossia la
sequenza degli eventi che accadono fra l’inizio e
la fine delle attività sul software. Il
diagramma delle attività che ho elaborato,
rappresenta il flusso di eventi, cioè quali sono le
conseguenze di ogni attività svolta, a differenza
del diagramma dei casi d’uso che rappresenta solo
le funzionalità utilizzabili dall’utente.
Anche qui ci troviamo di fronte a software di e-
commerce, dove è presente un punto iniziale
(“initial”), rappresentato da un pallino nero, e un
punto finale (“final”), rappresentato dal pallino
nero cerchiato. Fondamentali sono i rombi, che
rappresentano delle possibili scelte e in funzione
 delle scelte che vengono effettuate, potranno
accadere eventi diversi. Per esempio, dopo
l’initial, ci sarà la possibilità o di utilizzare la
funzionalità che ricerca un prodotto, oppure, la
funzionalità che consente di visualizzare i
prodotti. Se viene scelta la prima strada, potranno
a sua volta accadere due eventi: o il prodotto
viene trovato e allora verrà visualizzato o il
prodotto non verrà trovato e allora si ritornerà alla
prima scelta già descritta. Se avviene la
visualizzazione del prodotto, ci saranno ancora
due possibilità: o ritornare a ricercare un altro
prodotto o di aggiungere il prodotto al carrello e
così via fino ad arrivare al check-out. Dunque ogni
evento porta delle conseguenze.

4. Diagramma delle sequenze: è un diagramma di

interazione, descrive la comunicazione fra gli
oggetti di un sistema software. Con
comunicazione si intende lo scambio di messaggi,
ossia l’invocazione di metodi di un oggetto da
parte di un altro oggetto. La linea verticale
tratteggiata rappresenta il passare del tempo. Ma
ciò che è rilevante non è il tempo in valore
assoluto, ovvero quanti secondi passano da un
messaggio all’altro, ma l’ordine in cui i messaggi
sono inviati, ossia è importante mostrare che un
messaggio deve essere inviato dopo un altro. Il
rettangolo bianco indica la “vita” (life-time) di un
oggetto, ovvero l’istante da cui viene creato un
oggetto, all’istante in cui quell’oggetto viene
distrutto perché inutilizzato.
I diagrammi di sequenza UML sono utili se si
desidera rappresentare graficamente operazioni
complicate per renderle più comprensibili e per
rappresentare le interazioni fra alcuni elementi del
sistema e fra una sottosezione del sistema,
rappresentandone solo una sua parte.
Il diagramma delle sequenze che
ho elaborato, presenta delle frecce orizzontali
continue che rappresentano proprio i messaggi
che gli oggetti utilizzano per comunicare, ovvero
l’invocazione di metodi. Per esempio, l’oggetto
client web, invia il messaggio all’oggetto prodotto,
ma in realtà sta invocando tre metodi (getCodice,
getDescrizione, getPrezzo), e quindi richiede
all’oggetto prodotto le informazioni su codice,
descrizione e prezzo, che sicuramente l’oggetto
prodotto li avrà definiti. Mentre, le frecce
tratteggiate, rappresentano le risposte ai
messaggi. Riprendendo l’esempio precedente, la
richiesta dell’oggetto client web, verrà soddisfatta
dall’oggetto prodotto, che inoltrerà a sua volta un
messaggio con le informazioni. Il tempo risulterà
importante perché, l’operazione appena descritta,
dovrà avvenire soltanto dopo che l’oggetto client
web ha invocato il metodo cercaProdotto
sull’oggetto catalogo. È comunque impossibile
effettuare l’operazione, perché, come si vede dal
diagramma, l’oggetto prodotto non esiste ancora,
e verrà istanziato soltanto dopo la risposta
dell’oggetto catalogo.