Real World UML

1
Real World UML

• Omid Ehsani
• Senior Consultant and Trainer
• oehsani_at_lightcode.net

2
Sponsor
3
Parliamo di

• Limportanza della modellazione
• UML in 21 minuti
• Design Pattern e UML
• Unapplicazione reale
• Agile UML!

4
Limportanza della modellazione
5
Limportanza della modellazione

• Spesso i team di sviluppo non fanno progettazione
• Molti sviluppano applicazioni come costruirebbero
  la cuccia del cane
• Manca la definizione di unarchitettura
• 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
6
Limportanza 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

7
Cosa è UML?

• UML è un linguaggio per ...
• Visualizzare
• Specificare
• Costruire
• Documentare
• ... gli artefatti di un sistema software

UML è il blueprint per la costruzione del
software
8
Cosa è UML?

• UML è Il Linguaggio per lanalisi e la
  progettazione Object Oriented

9
Contributi allUML
Booch
Rumbaugh
Jacobson
Fusion
Fusion
Meyer
Meyer
Operation descriptions,
Operation descriptions,
Before and after
Before and after
Message numbering
Message numbering
conditions
conditions
Embley
Embley
Harel
Harel
Singleton classes,
Singleton classes,
State charts
State charts
High
-
level view
High
-
level view
Gamma, et.al
Gamma, et.al
Wirfs
-
Brock
Wirfs
-
Brock
Frameworks, patterns,
Frameworks, patterns,
Responsibilities
Responsibilities
Odell
Odell
notes
notes
Shlaer
-
Mellor
Shlaer
-
Mellor
Classification
Classification
Object Lifecycles
Object Lifecycles
10
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

11
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

12
Panoramica su UML

• UML è un linguaggio per visualizzare
• La visualizzazione facilita la comunicazione e
  favorisce un adeguato livello di astrazione
• Unimmagine vale mille parole

13
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

14
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

15
Panoramica su UML

• UML è un linguaggio per documentare
• le specifiche funzionali
• larchitettura generale
• la scomposizione strutturale del sistema
• le interazioni tra i componenti
• la distribuzione e il deployment

16
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

17
I Diagrammi di UML

• Use Case Diagram
• Sequence Diagram
• Collaboration Diagram
• Statechart (STD) Diagram
• Activity Diagram
• Component Diagram
• Deployment Diagram
• Class Diagram

18
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

19
Actors

• Un Actor è qualcuno o qualcosa che deve
  interagire con il sistema
• Gli Actors rappresentano qualunque cosa che deve
  scambiare informazioni con il sistema

20
Actors e Use Cases
Perform Card Transaction
Process Customer Bill
Retail Institution
Reconcile Transactions
Customer
Sponsoring Financial Institution
Manage Customer Account
21
Actors e Use Cases
22
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

23
Sequence Diagrams

• Un Sequence Diagram mette in evidenza
• la sequenza temporale dei messaggi
• la lifetime degli oggetti
• il focus of control

24
Sequence Diagrams
sCaller
Switch
rCaller
cConversation
25
Collaboration Diagrams

• Un Collaboration Diagram mette in evidenza
• lorganizzazione degli oggetti che partecipano in
  una interazione
• la lifetime degli oggetti
• il focus of control

26
Collaboration Diagrams
routeCall(s,n)
1 liftReceiver
3dialDigit(d)
Switch
sCaller
2 setDialTone()
8 connect(r,s)
10 connect(r)
5 create
6 ring()
9 connect(s)
rCaller
cConversation
7 liftReceiver
27
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)

28
Statechart (STD) Diagram

• Uno stato è una condizione o situazione durante
  la vita di un oggetto nella quale loggetto
  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 delloggetto
• Una transizione è una relazione fra due stati che
  indica che un oggetto passerà dalluno allaltro
  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

29
STD per una Linea Telefonica
30
STD per una Linea Telefonica
31
STD per una Linea Telefonica
32
STD per una Linea Telefonica
33
STD per una Linea Telefonica
34
STD per una Linea Telefonica
on-hook
off-hook
on-hook
on-hook
time-out
on-hook
digit(n)
invalid number
digit(n)
valid number
message done
number busy
routed
on-hook
called phone answers
on hook/disconnect line
called phone hangs up
on-hook
35
STD per la partita degli Scacchi
36
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

37
Un Component Diagram
find.html
index.html
find.exe
hyperlink
dbacs.dll
nateng.dll
38
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

39
Il Modello di un Sistema Client/Server
servers
clients
2..
4..
processor caching server Deploys
processor server Deploys
http.exe rting.exe
dbadmin.exe tktmstr.exe logexec.exe
40
Il Modello di un Sistema Distribuito
Internet
41
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

42
Class Diagram
Company
Headquarters
Office
Department
PersonelRecord
Person
ContactInformation
43
Class Diagram
Company
1
1..
1..
Headquarters
Location


0..1
manager
member
subset
1..
1
ISecureInformation
44
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)

45
Packages e Servizi
46
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 docchio al
  Class Diagram ci rinfresca la memoria
• I Pattern costituiscono un vocabolario comune per
  la comunicazione dei concetti
• Anche lUML è un vocabolario comune, ma è
  disegnato invece che scritto o parlato

47
Esempi di Design Pattern

• Factory

48
Esempi di Design Pattern

• Adapter

49
Esempi di Design Pattern

• Observer

50
Unapplicazione reale

• Utilizziamo lUML per documentare lapplicazione
  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

51
DEMO

• Reverse Engineering di Northwind
• Individuazione dei pattern sui diagrammi UML
• Progettazione e realizzazione di un DataProvider
  aggiuntivo

52
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
  UMLDocumentazione
• Ricordatevi del manifesto
• Software funzionante invece che documentazione
  esaustiva

53
Agile UML!

• Non diventate schiavi dei vostri diagrammi
• Molti diagrammi possono servire per pensare
  prima di scrivere, poi possono essere gettati
  via!
• Lobiettivo 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

54
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

55
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
• oehsani_at_lightcode.net