Real World UML
Omid Ehsani
Senior Consultant and Trainer
[email protected]
Sponsor
Parliamo di…
•
•
•
•
•
L’importanza della modellazione
UML in 21 minuti…
Design Pattern e UML
Un’applicazione reale
“Agile” UML!
L’importanza della modellazione
L’importanza della modellazione
• Spesso i team di sviluppo non fanno progettazione
• Molti sviluppano applicazioni come costruirebbero la
“cuccia del cane”
– Manca la definizione di un’architettura
– Dai requisiti si passa subito alla codifica
– Si lavora più tempo e si scrive più codice
Software is often treated as a SOFT science
Modeling helps make it a HARD science
L’importanza della modellazione
• Costruiamo modelli (o blueprints) per comprendere
meglio il sistema che stiamo sviluppando
• La modellazione:
– Ci aiuta a visualizzare il sistema come dovrebbe essere
– Ci permette di specificare la struttura e il comportamento del
sistema.
– Ci fornisce una linea guida nella costruzione del sistema
– Documenta le decisioni che prendiamo
– Scompone il problema
– Controlla la complessità
– E’ un punto di partenza
• Costruiamo modelli dei sistemi complessi perchè non
siamo in grado di comprendere tali sistemi nella loro
interezza
Cosa è UML?
• UML è un linguaggio per ...
– Visualizzare
– Specificare
– Costruire
– Documentare
... gli artefatti di un sistema software
UML è il “blueprint” per la
costruzione del software
Cosa è UML?
• UML è “Il
Linguaggio” per
l’analisi e la
progettazione
Object Oriented
Contributi all’UML
Booch
Rumbaugh
Jacobson
Meyer
Fusion
Operation descriptions,
Message numbering
Before and after
conditions
Embley
Harel
Singleton classes,
High-level view
State charts
Gamma, et.al
Wirfs-Brock
Frameworks, patterns,
notes
Shlaer - Mellor
Object Lifecycles
Odell
Classification
Responsibilities
Breve storia di UML
• Inizio progetto: ottobre 1994
• Proposta a OMG (Object
Management Group): gennaio 1997
• Accettazione, da parte di OMG, della
versione 1.1: novembre 1997
• Attualmente: UML versione 1.5
• Alle porte: UML 2.0
Panoramica su UML
• UML è un linguaggio
– Un linguaggio fornisce un vocabolario e le
regole per combinare le parole allo scopo di
comunicare
– Non è una metodologia, ma è utilizzato da
molti processi di sviluppo del software
Panoramica su UML
• UML è un linguaggio per visualizzare
– La visualizzazione facilita la comunicazione e
favorisce un adeguato livello di astrazione
– Un’immagine vale mille parole
Panoramica su UML
• UML è un linguaggio per stendere
specifiche
– Stendere specifiche significa costruire modelli
che siano precisi, non ambigui e completi
– I simboli UML hanno una sintassi e una
semantica ben definite
Panoramica su UML
• UML è un linguaggio per costruire
– UML non è un ambiente di programmazione
visuale ma i suoi modelli sono nati per essere
tradotti in linguaggi Object Oriented
Panoramica su UML
• UML è un linguaggio per documentare
– le specifiche funzionali
– l’architettura generale
– la scomposizione strutturale del sistema
– le interazioni tra i componenti
– la distribuzione e il deployment
UML in 21 minuti...
• I modelli di UML sono espressi attraverso
una serie di diagrammi
• Esistono diverse tipologie di diagrammi
• Ogni tipologia coglie un aspetto diverso
del sistema
I Diagrammi di UML
•
•
•
•
•
•
•
•
Use Case Diagram
Sequence Diagram
Collaboration Diagram
Statechart (STD) Diagram
Activity Diagram
Component Diagram
Deployment Diagram
Class Diagram
Use Cases Diagram
•
•
•
•
Un sistema risponde ai bisogni dei suoi utenti
Questi bisogni sono catturati come Use Cases
Uno Use Case è un modo di usare il sistema
Uno Use Case è uno schema di comportamento
esibito dal sistema
• La collezione degli Use Cases specifica tutti i
modi di usare il sistema
Actors
• Un Actor è qualcuno o qualcosa che deve
interagire con il sistema
• Gli Actors rappresentano qualunque cosa che
deve scambiare informazioni con il sistema
Actors e Use Cases
Perform Card Transaction
Process Customer Bill
Retail Institution
Customer
Reconcile Transactions
Manage Customer Account
Sponsoring
Financial
Institution
Actors e Use Cases
Perform Card Transaction
Process Customer Bill
Retail Institution
Customer
Reconcile Transactions
Manage Customer Account
Sponsoring
Financial
Institution
Realizziamo gli Use Cases
• Gli Interaction Diagrams permettono di
ottenere il modello di come interagiscono
Actors e oggetti per realizzare uno Use
Case
• Sono realizzati tramite due diverse, e
complementari, modalità:
– i Collaboration Diagrams
– i Sequence Diagrams
Sequence Diagrams
• Un Sequence Diagram mette in evidenza:
– la sequenza temporale dei messaggi
– la lifetime degli oggetti
– il focus of control
Sequence Diagrams
s:Caller
:Switch
r:Caller
liftReceiver
setDialTone()
{dialing.executionTime<30 sec}
*dialDigit(d)
routeCall(s,n)
dialing
c:Conversation
«create»
ring()
liftReceiver
connect(r)
connect(r,s)
connect(s)
Collaboration Diagrams
• Un Collaboration Diagram mette in evidenza:
• l’organizzazione degli oggetti che
partecipano in una interazione
• la lifetime degli oggetti
• il focus of control
Collaboration Diagrams
routeCall(s,n)
1: liftReceiver
3:*dialDigit(d)
:Switch
s:Caller
2: setDialTone()
10: connect(r)
8: connect(r,s)
5: «create»
6: ring()
9: connect(s)
r:Caller
c:Conversation
7: liftReceiver
Statechart (STD) Diagram
• Una macchina a stati è usata per ottenere il
modello di un singolo oggetto
• Una macchina a stati descrive la sequenza degli
stati attraverso i quali transita un oggetto
durante il suo ciclo di vita in risposta a eventi,
assieme alle sue risposte a tali eventi
• Il diagramma che descrive la macchina a stati è
detto State Transition Diagram (STD)
Statechart (STD) Diagram
• Uno stato è una condizione o situazione durante la
vita di un oggetto nella quale l’oggetto soddisfa
qualche condizione, esegue qualche attività, o
aspetta per qualche evento
• Un evento è la specifica di un “qualcosa” la cui
durata è trascurabile rispetto alla durata del ciclo di
vita dell’oggetto
• Una transizione è una relazione fra due stati che
indica che un oggetto passerà dall’uno all’altro
come effetto di un evento o quando una specifica
condizione è verificata
• Una azione è una operazione atomica il cui effetto
è o un cambiamento di stato o il ritorno di un valore
STD per una Linea Telefonica
Idle
on-hook
off-hook
Dial Tone
do: sound dial tone
STD per una Linea Telefonica
Idle
off-hook
Dial Tone
do: sound dial tone
digit(n)
Dialing
valid number
digit(n)
Connecting
do: find connection
routed
Ringing
do: ring bell
called phone answers
on-hook
Connected
called phone hangs up
Disconnected
STD per una Linea Telefonica
Idle
on-hook
off-hook
Dial Tone
do: sound dial tone
time-out
Timed-out
do: sound loud beep
STD per una Linea Telefonica
Idle
off-hook
Dial Tone
do: sound dial tone
digit(n)
Dialing
invalid number
digit(n)
on-hook
Receiving Recorded Message
do: play message
message done
on-hook
Disconnected
STD per una Linea Telefonica
Idle
off-hook
Dial Tone
do: sound dial tone
on-hook
Busy
do: sound busy tone
digit(n)
Dialing
valid number
number busy
Connecting
do: find connection
digit(n)
STD per una Linea Telefonica
Idle
Dial Tone
do: sound dial tone
on-hook
Busy
do: sound busy tone
digit(n)
Dialing
on-hook
on hook/disconnect line
on-hook
Connecting
do: find connection
Timed-out
do: sound loud beep
time-out
invalid number
valid number
number busy
on-hook
off-hook
on-hook
digit(n)
on-hook
Receiving Recorded Message
do: play message
message done
routed
Ringing
do: ring bell
called phone answers
Connected
called phone hangs up
Disconnected
STD per la partita degli Scacchi
White’s turn
do: think
black moves
checkmate
stalemate
white moves
Black’s turn
do: think
stalemate
checkmate
Black wins
Draw
White wins
Component Diagram
• Un Component Diagram mostra un
insieme di componenti e le loro relazioni
• Un Component Diagram comunemente
contiene:
– Componenti
– Interfacce
– Relazioni di dipendenza, generalizzazione,
associazione e realizzazione
Un Component Diagram
find.html
index.html
__________
__________
__________ «hyperlink»
____
__________
__________
__________
__________
____
__________
dbacs.dll
find.exe
nateng.dll
Deployment Diagram
• Un deployment diagram è un diagramma
che documenta la configurazione al run
time dei nodi che partecipano al processo
e i componenti che vivono in essi
• Tipicamente un deployment diagram è
usato per avere il modello di
– Sistemi embedded
– Client/server
– Sistemi distribuiti
Il Modello di un Sistema
Client/Server
servers
clients
2..*
«processor»
caching server
console
Deploys
http.exe
rting.exe
4..*
«processor»
server
Deploys
dbadmin.exe
tktmstr.exe
logexec.exe
Il Modello di un Sistema
Distribuito
Note: country servers
are reachable to one
another via the company’s
private network
:console
:console
:console
:Internet
:regional
server
:country
server
:regional
server
:regional
server
:logging
server
Class Diagrams
• Un Class Diagram è un diagramma che mostra
un insieme di classi, interfacce, e collaborazioni
e le loro dipendenze
• Un Class Diagram è un modello statico del
sistema utilizzato per
– ottenere un dizionario del sistema
– avere un modello di collaborazione fra gli oggetti
(p.e. per specificare quali oggetti partecipano a una
transazione)
– avere un modello logico dello schema del database
Class Diagram
multiplicity
Company
1..*
Department
1
aggregation
1..*
Office
generalization
Headquarters
* Location *
constraint
class
association
role
member {subset} manager
1..*
1
PersonelRecord
Person
ContactInformation
(class) name
dependency
interface
0..1
ISecureInformation
Class Diagram
Company
1..*
0..1
1
Department
* Location
name: Name
member {subset} manager
1..*
1
Person
name: Name
employeeID: Integer
title: String
getPhoto(p: Photo)
getSoundByte()
getContactInformation()
getPersonalRecords()
1..*
Office
* address: String
voice: Number
attributes
ContactInformation
address: String
Headquarters
PersonelRecord
taxID
employmentHistory
PersonelRecord
operations
ISecureInformation
Packages
• Un Package è un meccanismo di uso
generale per
– organizzare in gruppi gli elementi che sono
semanticamente simili o funzionalmente
correlati
– I package possono essere utilizzati oer creare
gerarchie di contenitori (come i folder per il
file-system)
Packages e Servizi
User Services
Business Services
Data Services
Design Pattern e UML
• Impariamo a leggere i Design Pattern
– Per capire meglio i Pattern li “visualizziamo” con
diagrammi UML
– Anche quando conosciamo un Pattern non sempre ne
ricordiamo la struttura, un colpo d’occhio al Class
Diagram ci rinfresca la memoria
• I Pattern costituiscono un vocabolario comune
per la comunicazione dei concetti
– Anche l’UML è un vocabolario comune, ma è
“disegnato” invece che scritto o parlato
Esempi di Design Pattern
Factory
Esempi di Design Pattern
Adapter
Esempi di Design Pattern
Observer
Un’applicazione reale
• Utilizziamo l’UML per documentare
l’applicazione Northwind
• Manutenere i diagrammi UML in sincronia
con il codice sorgente non è una sfida da
poco
– Molti tool di modellazione UML fanno il
Reverse-Engineering, il Forward-Engineering
e il Round-Trip modeling
DEMO
• Reverse Engineering di Northwind
• Individuazione dei pattern sui diagrammi
UML
• Progettazione e realizzazione di un
DataProvider aggiuntivo
“Agile” UML!
• Non correte il rischio di “over-designing”
– Utilizzate UML con dosi sostenibili
– Trovate il giusto livello di dettaglio da
applicare ai diagrammi
• Dal punto di vista di artefatti
UML=Documentazione
• Ricordatevi del manifesto:
“Software funzionante invece che
documentazione esaustiva”
“Agile” UML!
• Non diventate schiavi dei vostri diagrammi
– Molti diagrammi possono servire per “pensare” prima
di scrivere, poi possono essere gettati via!
– L’obiettivo finale non è costruire modelli, ma sistemi
software
– Se decidete di mantenere i diagrammi dotatevi di un
tool che li sincronizzi al meglio con il codice
– I diagrammi di più alto livello (architetturali o
concettuali) hanno un valore che giustifica la loro
manutenzione nel tempo
“Agile” UML!
• Non ve la sentite di fare pair-programming?
Provate il pair-designing!
Il rendimento è garantito
• La condivisione delle conoscenze è più
immediata sui diagrammi che sul codice
• La memoria visiva è più duratura nel tempo, le
righe di codice si dimenticano
Questions & Answers
Sito ufficiale:
http://www.uml.org/
Libri:
• UML Distilled (Martin Fowler, Kendall Scott) – Addison Wesley
• The Unified Modeling Language Reference (James Rambaugh, Ivar
Jacobson, Grady Booch) - Addison Wesley
• Writing Effective Use Cases (Alistair Cockburn) - Addison Wesley
Omid Ehsani
Senior Consultant and Trainer
[email protected]