Introduzione a UML
Perché modelliamo
Un modello è una semplificazione della realtà
I modelli
 ci aiutano a “visualizzare” un sistema come è o come vorremmo che
fosse
 ci permettono di specificare la struttura o il comportamento di un
sistema
 ci forniscono un “template” che ci guida nella costruzione di un
sistema
 documentano le decisioni che abbiamo preso
Perché modelliamo
 Divide et impera: tramite i modelli ci focalizziamo su un solo
aspetto alla volta
 ogni modello può essere espresso a differenti livelli di precisione
 per un sistema non banale:


non un solo modello
ma un piccolo insieme di modelli, che possono essere costruiti
e studiati separatamente, ma che sono strettamente interrelati
Unified Modeling Language
 un linguaggio (e notazione) universale, per la creazione di modelli
software
 nel novembre ‘97 è diventato uno standard approvato dall’OMG
(Object Management Group)
 numerosi i co-proponenti: Microsoft, IBM, Oracle, HP, Platinum,
Sterling, Unysis …..
Unified Modeling Language
 è l’unificazione dei metodi:

Booch-93 di Grady Booch
 OMT di Jim Rumbaugh
 OOSE di Ivar Jacobson
 ha accolto inoltre le idee di numerosi altri metodologie
 è tuttavia indipendente dai metodi, dalle tecnologie, dai produttori
UML - linguaggio universale

linguaggio per specificare, costruire, visualizzare e
documentare gli artefatti di un sistema

universale: può rappresentare sistemi molto diversi, da quelli
web ai legacy, dalle tradizionali applicazioni Cobol a quelle
object oriented e a componenti
UML non è un metodo
 è un linguaggio di modellazione, non un metodo, né una
metodologia
 definisce una notazione standard, basata su un meta-modello
integrato degli “elementi” che compongono un sistema software
 non prescrive una sequenza di processo, cioè non dice “prima
bisogna fare questa attività, poi quest’altra”
UML e Processo Software
“un unico processo universale utilizzabile per tutti gli stili di
sviluppo non sembra possibile e tanto meno desiderabile”

in realtà UML assume un processo:
 basato sui Casi d’Uso (use case driven)
 incentrato sull’architettura
 iterativo e incrementale

i dettagli di questo processo di tipo generale vanno adattati alle
peculiarità della cultura dello sviluppo o del dominio applicativo di
ciascuna organizzazione
Diagrammi UML
livello “logico”:
dei casi d’uso
delle classi
di sequenza
di collaborazione
di transizione di stato
delle attività
Use Case Diagram
Class Diagram
Sequence Diagram
Collaboration Diagram
Statechart Diagram
Activity Diagram
livello “fisico”:
dei componenti
Component Diagram
di distribuzione dei componenti Deployment Diagram
Diagramma dei casi d’uso
Mostra:
•
le modalità di utilizzo del sistema (casi d’uso)
•
gli utilizzatori e coloro che interagiscono con il sistema
(attori)
•
le relazioni tra attori e casi d’uso
Un caso d’uso
• rappresenta un possibile “modo” di utilizzo del sistema
• descrive l’interazione tra attori e sistema, non la “logica
interna” della funzione
una funzionalità dal punto di vista di chi la utilizza
Perche’ costruire modelli dei casi d’uso
 Primo momento nel ciclo di vita del software in cui costruiamo
delle rappresentazioni (talvolta semi-formali) del software.
 Motivazioni:
1. Esplicitare e comunicare a tutti gli stakeholder i requisiti
funzionali del sistema– In generale, analizzare, identificare,
descrivere gli usi tipici del sistema da parte dei suoi utilizzatori.
Considerare anche tutta l’eventuale logica derivante dalla
gestione di errori, eccezioni, flussi alternativi.
2. Validare i requisiti utente – Essendo il modello dei casi d’uso
piuttosto semplice (pochi costrutti, semantica precisa, ma
intuitiva), diventa un valido strumento per assicurarci di aver
sviluppato un sistema software corrispondente alle vere
necessita’ dell’utente.
Cosa è un use case
 Un use case cattura chi (attori) fa cosa (interazione) con il sistema.
Con quale scopo (goal), senza considerare ciò che è dentro il sistema
 Un use case





Raggiunge un singolo, discreto, completo, significativo, e ben
definito task di interesse per un attore
È un pattern di comportamento tra alcuni attori ed il sistema —
una collezione di possibili scenari
È scritto usando il vocabolario del dominio applicativo
Definisce scopo ed intento (non azioni concrete)
È generale e indipendente dalla tecnologia
Use case diagram e requisiti
 I casi d’uso servono a:
 chiarire i requisiti del committente in termini
comprensibili
 trovare aspetti comuni (riuso)
 individuare gli attori del sistema
 individuare gli eventi a cui il sistema deve rispondere
 Un requisito può dare origine a più casi d’uso
 Ad un caso d’uso possono venire associati più requisiti
Casi d’uso, attori, scenari e descrizioni
 Quattro concetti fondamentali:
1.
2.
3.
4.
Caso d’uso – rappresenta una specifica interazione tra un
attore e il sistema.
In UML rappresentato mediante un’ellisse etichettata col
nome del caso d’uso.
Attore – rappresenta un ruolo che caratterizza le interazioni
tra utente e sistema. L’utente non è necessariamente umano;
In UML rappresentato mediante un omino.
Scenario – sequenza di azioni che definisce una particolare
interazione tra attore e sistema.
Descrizione – testo che descrive lo scenario, l’ordine
temporale della sequenza di azioni, l’eventuale trattamento
degli errori, gli attori coinvolti.
Attori
Gli attori sono rappresentati tramite il ruolo che giocano
nel caso d’uso e sono normalmente indicati tramite l’icona:
<<Attore>>
Cassiere
Relazione tra attori
• E’ possibile definire gerarchie di attori
• Associare un attore ad uno o più attori specializzati
Utente Banca
Utente Sede Centrale
Utente Filiale
Diagramma dei casi d’uso
attore: un
utilizzatore
del sistema
acquistare articoli
log in
cliente
rimborsare articoli venduti
cassiere
caso d'uso: un
"modo" di utilizzare il
sistema
Template per la documentazione di un caso d’uso
Esempio di scenario: Prelievo dal Bancomat
object-modeling @2003-2005 Dr. Andrea Baruzzo - Strutturare i diagrammi dei casi d'uso in UML
19
object-modeling @2003-2005 Dr. Andrea Baruzzo - Strutturare i diagrammi dei casi d'uso in UML
20
Esempio di scenario (Cont.)
object-modeling @2003-2005 Dr. Andrea Baruzzo - Strutturare i diagrammi dei casi d'uso in UML
21
Relazioni tra casi d’uso
 Relazione di inclusione «include»
 Relazione di generalizzazione
 Relazione di estensione «extend»
 Poche relazioni: modello semplice, senza grossa
complessità sintattica
Relazioni tra casi d’uso: inclusione
 Rappresenta l’invocazione di un caso d’uso da
parte di un altro.
 Simile alla chiamata di una funzione
 Serve per scomporre casi d’uso complessi in casi
d’uso più semplici
 Esprime il riuso di singoli casi d’uso
Relazioni tra casi d’uso: include
<<include>> : può mostrare anche il comportamento
comune a uno o più casi d’uso
identificarsi al bancomat
<<include>>
prelevare
<<include>>
visualizzare saldo
Esempio
Vehicle rental system
Booking
Using
Returning
Customer
<<include>>
Service
Official
Esempio
 Effettuare un ordine di acquisto include (sempre!) i
seguenti passi:
1.
2.
3.
Compilazione di un form di acquisto
Scelta della modalità di pagamento;
Conferma dell’ordine di acquisto
<<include>>
Compila Form di Acquisto
Prodotto
<<include>>
Cliente
Effettua un Oridine
Scegli Modalità Pagamento
<<include>>
Conferma Ordine
Relazioni tra casi d’uso: generalizzazione
 Simile all’ereditarietà tra classi
 Relazione che lega un caso d’uso generico a casi d’uso che
sono particolari specializzazioni (realizzazioni) del primo
 Logica del caso d’uso derivato simile a (ma diversa da) quella
del caso d’uso di base
 Viene riscritta (specializzata) la sequenza delle azioni di base
oppure viene elaborata una sequenza alternativa
Relazioni tra casi d’uso: generalizzazione
 Effettua un Ordine è un caso d’uso generale che può
essere specializzato nei seguenti:
1.
2.
3.
Effettua un ordine di un cd musicale
Effettua un ordine di un libro
Effettuare un ordine di uno spartito
Cliente
Effettua un Ordine
Effettua Ordine Libro
Effettua Ordine Spartito
Effettua Ordine CD Musicale
Relazioni tra casi d’uso: estensione
 Rappresenta l’estensione della logica di base di un caso
d’uso.
 Il caso d’uso estensione continua il comportamento del
caso d’uso di base inserendovi delle azioni alternative da
un certo punto in poi (chiamato punto di estensione)
 Il caso d’uso di base dichiara tutti i possibili punti di
estensione
 Simile alla gestione degli interrupt hardware (gestione
eccezioni)
Relazioni tra casi d’uso: extend
<<extend>>: mostra il comportamento opzionale
(alternativo o relativo al trattamento di condizioni
anomale)
aprire conto corrente
<<extend>>
trattare condizioni particolari
Relazioni tra casi d’uso: estensione
 Effettua un Ordine presuppone che l’utente sia già
registrato nel sistema informatico
 Se il cliente è al suo primo ordine e non si è
precedentemente registrato? Eccezione nel caso d’uso
base!
Punti di estensione:
nuovo cliente
Cliente
Effettua un Ordine
<<extend>>
Aggiungi Cliente
Relazioni tra casi d’uso (estensione)
 Effettua un Ordine prevede una procedura d’acquisto
di default che non invia la fattura
 E se il cliente richiede una fattura? Eccezione nel caso
d’uso base
Punti di estensione:
nuovo cliente
dati fattura
Cliente
Effettua un Ordine
<<extend>>
Fattura Ordine
Esercizio: Sportello Bancomat
 Il Sistema sarà eseguito su uno sportello bancomat automatico
 L'utente deve essere in grado di depositare assegni sul suo






conto
L'utente deve essere in grado di prelevare i soldi dal suo conto
L'utente deve poter interrogare il Sistema sul saldo del suo
conto
Se lo richiede, l'utente deve poter ottenere la ricevuta per la
transazione.
I tipi di transazione sono ritiro o deposito.
La ricevuta deve indicare la data della transazione, ilnumero
del conto, il saldo precedente e successivo la transazione
Dopo ogni transazione, il nuovo saldo deve essere visualizzato
all'utente
Esercizio: Soluzione
Diagramma delle classi
• è il caposaldo dell’object oriented
• rappresenta le classi di oggetti del sistema con i loro attributi
e operazioni
• mostra le relazioni tra le classi (associazioni, aggregazioni e
gerarchie di specializzazione/generalizzazione)
• può essere utilizzato a diversi livelli di dettaglio (in analisi e in
progettazione)
Class diagram: le classi
 Una classe è una tipologia di oggetti, con propri attributi e
operazioni
 Rappresentazione di una classe in UML:
Automobile
Nome
marca
modello
colore
targa
Attributi (proprietà)
cambiaTarga
cambiaColore
Operazioni (metodi)
Class diagram: le classi
 Nome: inizia con una lettera maiuscola, non è
sottolineato e non contiene underscore
 Attributi: proprietà i cui valori identificano un oggetto
istanza della classe e ne costituiscono lo stato;
iniziano con una lettera minuscola
 Operazioni: insieme di funzionalità che esprimono il
comportamento di un oggetto, ovvero ciò che ogni
oggetto di questa classe può fare
Class diagram: associazioni
Clienti
Ordini
dataOrdine
0..* stato
1 emette
clienteDal
emesso da
getOrdini
calcolaTasse
calcolaTotale
setStato
1..*
Articoli
codice
descrizione
peso
prezzo
1
1
nell’ordine
riguarda articolo
0..*
DettagliOrdine
quantità
calcolaPeso
calcolaPrezzo
Class diagram: associazioni
 Associazione: correlazione fra classi; nel diagramma è
una linea continua fra due classi, con esplicita
semantica nei due sensi
 Molteplicità: numero di oggetti che partecipano
all’associazione. Esempi di molteplicità sono:
1
Esattamente una istanza
0..*
Nessun limite al numero di istanze
1..*
Almeno una istanza
n..m
Da n a m istanze
Class diagram: aggregazione
 Aggregazione: tipo particolare di associazione; esprime
concetto “è parte di ” (part of ), che si ha quando un
insieme è relazionato con le sue parti.
• Si rappresenta con un diamante dalla parte della classe
che e’ il contenitore
Class diagram: composizione
 E’ un caso particolare di aggregazione in cui:
1.
2.
la parte (componente) non può esistere da sola, cioè
senza la classe composto
una componente appartiene ad un solo composto
 Il diamante si disegna pieno
Class diagram: aggregazione/composizione
Università
Docenti
aggregazione
composizione
Dipartimenti
Class diagram: ereditarietà
Persone
nome
cognome
indirizzo
cambiaIndirizzo
Clienti
superclasse
simbolo di
ereditarietà
PotenzialiClienti
codiceCliente
clienteDal
numVisite
contaOrdini
sottoclassi
Class diagram: esempio
Punti
x
y
Poligoni
coloreRiemp
coloreBordo
tipoBordo
setColoreBordo
setColoreRiemp
setTipoBordo
3..*
identifica
Vertici
colore
dimensione
Class diagram: esempio
Persone
nome
Docenti
1
Frequenze
periodo
*
Studenti
matricola
*
1
*
sostiene
relativo a
di
insegna 1..*
tenuto da
Corsi
nome
durata
1
1
del corso
Esami
voto
data
Diagramma di sequenza
• è utilizzato per definire la logica di uno scenario (specifica sequenza
di eventi) di un caso d’uso (in analisi e poi ad un maggior livello di
dettaglio in disegno)
• è uno dei principali input per l’implementazione dello scenario
• mostra gli oggetti coinvolti specificando la sequenza temporale dei
messaggi che gli oggetti si scambiano
• è un diagramma di interazione: evidenzia come un caso d’uso è
realizzato tramite la collaborazione di un insieme di oggetti
Alcune definizioni
 Un diagramma di sequenza è un diagramma che descrive
interazioni tra oggetti che collaborano per svolgere un
compito
 Gli oggetti collaborano scambiandosi messaggi
 Lo scambio di un messaggio in programmazione ad
oggetti equivale all’invocazione di un metodo
Scambio Messaggi Sincroni (1/2)
 Si disegna con una freccia chiusa
da chiamante a chiamato. La freccia è etichettata col
nome del metodo invocato, e opzionalmente i suoi
parametri e il suo valore di ritorno
 Il chiamante attende la terminazione del metodo del
chiamato prima di proseguire
 Il life-time (durata, vita) di un metodo è rappresentato
da un rettangolino che collega freccia di invocazione
e freccia di ritorno
Scambio Messaggi Sincroni (2/2)
 Life-time corrisponde ad avere un record di
attivazione di quel metodo sullo stack di attivazione
 Il ritorno è rappresentato con una freccia tratteggiata
 Il ritorno è sempre opzionale. Se si omette, la fine del
metodo è decretata dalla fine del life-time
Scambio Messaggi Sincroni
sd Diagrammi di Sequenza - Scambio Messaggi Sincroni
an Order Entry
Window :Window
an Order :Order
prepare()
Messaggio asincrono
(invocazione di un metodo)
oggetto
messaggio di ritorno
(opzionale se void)
return done
life-line dell'oggetto
an Order Entry Window
life-time di prepare()
Scambio Messaggi Asincroni
 Si usano per descrivere interazioni concorrenti
 Si disegna con una freccia aperta
da chiamante a chiamato. La freccia è etichettata col
nome del metodo invocato, e opzionalmente i suoi
parametri e il suo valore di ritorno
 Il chiamante non attende la terminazione del metodo del
chiamato, ma prosegue subito dopo l’invocazione
 Il ritorno non segue quasi mai la chiamata
Scambio Messaggi Asincroni
sd Diagramma di Sequenza - Scambio Messaggi Asincroni
an Order Entry
Window :Window
an Order :Order
prepare()
oggetto
Messaggio asincrono
(invocazione di un metodo)
Esecuzione condizionale di un messaggio
 L’esecuzione di un metodo può essere assoggettata ad
una condizione. Il metodo viene invocato solo se la
condizione risulta verificata a run-time
 Si disegna aggiungendo la condizione, racchiusa tra
parentesi quadre, che definisce quando viene eseguito il
metodo
 Sintassi:
[cond] : nomeMetodo()
Esecuzione condizionale di un
messaggio - esempio
sd Diagrammi di Sequenza - Esecuzione Condizionata
an Order Line
:OrderLine
a Stock Item
:StockItem
hasStock = check()
[hasStock]: remove()
Il metodo remove() viene eseguito solo
se il metodo check assegna "true" alla
variabile hasStock (soddisfa la
condizione hasStock=true)
Esecuzione condizionata di un
messaggio – esempio (un’alternativa)
sd Diagrammi di Sequenza - Esecuzione Condizionata (Alternativ a)
an Order Line
:OrderLine
a Stock Item
:StockItem
check()
hasStock
[hasStock]: remove()
Il metodo remove() viene eseguito solo se il
metodo check assegna "true" alla variabile
hasStock (soddisfa la condizione hasStock=true)
Esecuzione condizionata di un messaggio
(un’altra alternativa)
sd Diagrammi di Sequenza - Esecuzione Condizionata (Alternativ a)
an Order Line
:OrderLine
a Stock Item
:StockItem
check()
hasStock
[hasStock]: remove()
Il metodo remove() viene eseguito solo se il
metodo check assegna "true" alla variabile
hasStock (soddisfa la condizione hasStock=true)
[not hasStock]: actionForItemNotInStock()
il metodo actionForItemNotInStock() viene
eseguito in alternativa al metodo remove(),
se la condizione hasStock ha valore false
Iterazione di un messaggio
 Rappresenta l’esecuzione ciclica di messaggi
 Si disegna aggiungendo un * (asterisco) prima del
metodo su cui si vuole iterare
 Si può aggiungere la condizione che definisce
l’iterazione
 La condizione si rappresenta tra parentesi
quadre. Sintassi completa:
[cond] : * nomeMetodo()
Iterazione di un messaggio esempio
sd Diagramma di Sequenza - Iterazione di un Messaggio
an Order :Order
an Order Line
:OrderLine
[for each oreder line]: *prepare()
Iterazione di un blocco di messaggi
 Rappresenta l’esecuzione ciclica di più messaggi
 Si disegna raggruppando con un blocco (riquadro, box) i
messaggi (metodi) su cui si vuole iterare
 Si può aggiungere la condizione che definisce l’iterazione
sull’angolo in alto a sinistra del blocco
 La condizione si rappresenta al solito tra parentesi quadre
Iterazione di un blocco di messaggi
sd Diagrammi di Sequenza - Iterazione di più Messaggi
:Order
:OrderLine
loop Prepare&Deliv er
[for each order line]
prepare()
done
deliver()
successful
“Auto-Chiamata” (Self-Call)
 Descrive un oggetto che invoca un suo metodo
(chiamante e chiamato coincidono)
 Si rappresenta con una “freccia circolare”
che rimane all’interno del life time di uno stesso metodo
Auto-Chiamata” (Self-Call)
sd Diagrammi di Sequenza - Self-Call
an Order Line
:OrderLine
a Stock Item
:StockItem
remove()
needsToReorder()
All'interno del metodo remove(),
l'oggetto "a Stock Item" chiama il
proprio metodo needsToReorder()
Costruzione di un oggetto
 Rappresenta la costruzione di un nuovo oggetto non
presente nel sistema fino a quel momento
 Messaggio etichettato new, create,…
 L’oggetto viene collocato nell’asse temporale in
corrispondenza dell’invocazione nel metodo new (o
create…)
Costruzione di un oggetto
sd Diagramma di Sequenza - Creazione di un Oggetto
an Order Line
:OrderLine
a Stock Item
:StockItem
remove()
done
:Deliv eryItem
new
"an Order Line" crea un istanza di DeliveryItem.
Prima (o durante) l'esecuzione di remove()
l'istanza di DeliveryItem non esisteva!
Eliminazione di un oggetto
 Rappresenta la distruzione di un oggetto presente nel
sistema fino a quel momento
 Si rappresenta con una X posta in corrispondenza della
life-line dell’oggetto
 Da quel momento in poi non è legale invocare alcun
metodo dell’oggetto distrutto
Eliminazione di un oggetto
sd Diagrammi di sequenza - Eliminazione di un Oggetto
an Order Entry
Window :Window
an Order :Order
prepare()
done
l'oggetto "an Order Entry
Window" da qui in poi non è
più accessibile
L'oggetto "an Order"
vive ancora
Mettiamo tutto insieme…
 Costruiamo un diagramma di sequenza per il seguente use
case
 Una finestra di tipo Order Entry invia il messaggio “prepare”
ad un Ordine (Order)
 L’ordine invia il messaggio “prepare” ad ogni sua linea
(Order Line)
 Ogni linea verifica gli elementi in stock (Stock Item)
 Se il controllo ha esito positivo, la linea rimuove l’appropriata
quantità di elementi in stock e crea un’unità di delivery
(DeliveryItem)
 Se gli elementi in stock rimanenti scendono al di sotto di una
soglia di riordino, viene richiesto un riordino (ReorderItem)
Mettiamo tutto insieme…
sd Diagrammi di Sequenza - La Sintassi
an Order Entry
Window :Window
an Order :Order
an Order Line
:OrderLine
a Stock Item
:StockItem
prepare()
[for each order line]: *prepare()
hasStock:= check()
[hasStock]: remove()
needsReorder:= needsToReorder()
[needsReorder]: new
:ReorderItem
:Deliv eryItem
[hasStock]: new
Alcuni suggerimenti finali
 Assicurarsi che i metodi rappresentati nel diagramma
siano gli stessi definiti nelle corrispondenti classi (con lo
stesso numero e lo stesso tipo di parametri)
 Documentare ogni assunzione nella dinamica con note o
condizioni (ad es. il ritorno di un determinato valore al
termine di un metodo, il verificarsi di una condizione
all’uscita da un loop, ecc.)
 Mettere un titolo per ogni diagramma (ad es. “sd
Diagrammi di Sequenza – Eliminazione di un Oggetto” )
Alcuni suggerimenti finali
 Scegliere nomi espressivi per le condizioni e per i valori di
ritorno
 Non inserire troppi dettagli in un unico diagramma (flussi
condizionati, condizioni, logica di controllo)
 Non bisogna rappresentare tutto quello che si
rappresenta nel codice …
 Se il diagramma è complesso, scomporlo in più diagrammi
semplici (ad es. uno per il ramo if, un altro per il ramo else,
ecc.)