Unified Modeling Language (UML) Breve storia dell`UML

Unified Modeling Language (UML)
UML
Lo standard emergente nella progettazione del
software (e non solo)
Perchè usare la progettazione visuale?
Perchè usare la progettazione visuale?
Ken Jacobs, Oracle Vice-president:
Mary Loomis, HP - Software Technology Laboratory:
“… Le definizioni dei dati per i database ad oggetti sono
“… la progettazione visuale e le tecniche di
di difficile comprensione se si esamina la loro
rappresentazione visuale (…) permettono di
espressione testuale. Con una rappresentazione
rappresentare le specifiche in un modo comprensibile sia
grafica si possono, invece, facilmente capire le
per le persone che per i tool di sviluppo”
relazioni tra essi ed il resto del DB.”
Perchè usare la progettazione visuale?
n
John Roskill, Microsoft - Director of Product
Marketing for Microsoft Visual Studio:
Breve storia dell’UML
“… Noi riteniamo la progettazione visuale molto
importante nello sviluppo delle applicazioni di livello
‘enterprise’ basate su componenti (…) perché permette
di gestire la complessità dell’applicazione.”
1
La storia dell’UML
Nov ‘97 UML viene approvato dall’OMG
Cosa è l’UML
Cosa è l’UML
Struttura dell’UML
Obiettivi dell’UML
UML: Unified Modeling
Language
Che cos’è l’UML?
UML è l’acronimo di
n
Unified Modeling Language
n
È un linguaggio visuale per la specifica,
la costruzione e la documentazione di
sistemi software complessi
n
n
n
n
UML: principi ispiratori
n
Modellazione (allo scopo di produrre software
migliore)
n
La modellazione è essenziale in ogni attività
ingegneristica complessa, in quanto permette di
astrarre e semplificare
n
n
“costruiamo modelli per comprendere meglio i sistemi
che stiamo sviluppando” [Booch et al: The UML User
Guide]
“costruiamo modelli di sistemi complessi altrimenti non
potremmo comprendere tali sistemi nella loro interezza”
Booch et al.
OMT (Rambaugh et al.)
OOSE (Jacobson et al.)
Gli autori di UML sono Booch, Rumbaugh e
Jacobson
Finalità della modellazione
n
n
Un linguaggio "standard" (accettato dall'OMG)
per la modellazione di sistemi software
UML deriva dalla "integrazione" di modelli
preesistenti (proposti nel contesto di
metodologie):
n
Visualizzazione del sistema (così com'è o come lo si
vorrebbe) in quanto “una figuravale più di mille parole”
Specifica della struttura e del comportamento di un
sistema in maniera precisa, completa e senza ambiguità
Definizione delle linee guida per la costruzione di un
sistema
n
n
n
n
forward engineering
reverse engineering
Documentazione delle decisioni prese
UML è stato pensato per supportare tutto questo
2
I diagrammi di UML
UML, questioni generali
n
n
n
n
i diagrammi sono una “rappresentazione” dei vari aspetti
dell’applicazione
ogni diagramma descrive una vista della applicazione secondo una
certa prospettiva
Use Case
Use Case
Diagrams
Sequence
Diagrams
Diagrams
Use Case
Use Case
Diagrams
Use Case
Diagrams
Diagrams
State
State
Diagrams
Object
Diagrams
Diagrams
Abbellimenti (adornments):
n
n
State
State
Diagrams
Class
Diagrams
Diagrams
Diagrammi e viste
per ogni costrutto esiste una notazione grafica base, cui possono
essere aggiunti dettagli e note
Scenario
Scenario
Diagrams
Collaboration
Diagrams
Diagrams
Distinzioni di base:
n
classe-oggetto (schema-istanza); notazione:
n
interfaccia-implementazione
n
n
classe
oggetto :classe
:classe
Scenario
Scenario
Diagrams
Statechart
Diagrams
Diagrams
oggetto
n
n
n
Diagramma delle classi (Class)
Diagramma degli oggetti (Object)
Diagramma dei casi di uso (Use case)
Diagrammi di interazione (Interaction)
n
n
n
n
n
n
Diagramma di sequenza (Sequence)
Diagramma di collaborazione (Collaboration)
Diagramma delle attività (Activity)
Diagramma degli stati (Statechart)
Diagramma dei componenti (Component)
Diagramma della distribuzione dei componenti
(Deployment)
Component
Component
Diagrams
Deployment
Diagrams
Diagrams
Activity
Diagrams
Obiettivi dell’UML
I diagrammi di UML (9 tipi diversi)
n
State
State
Diagrams
Component
Diagrams
Diagrams
Models
n
n
n
1) Fornire all’utente un
linguaggio di specifica
espressivo, visuale e pronto
all’uso
2) Offrire meccanismi di
estensibilità e specializzazione
del linguaggio
3) Essere indipendente dagli
specifici linguaggi di
programmazione e dai processi
di sviluppo
n
n
n
4) Incoraggiare la crescita dei tool
OO commerciali
5) Supportare concetti di sviluppo
ad alto livello come frameworks,
pattern ed i componenti
6) Integrare i migliori approcci.
Cosa non è l’UML
n
n
n
Non è un linguaggio di programmazione visuale
(è un linguaggio di specifica visuale)
Parti di UML
UML non è un modello per la definizione di
interfacce
UML non è dipendente dal paradigma di
sviluppo nel quale può essere utilizzato
3
UML
UML può essere suddiviso in due grandi
parti:
n Diagrammi
strutturali
n Diagrammi comportamentali
Diagrammi comportamentali
Diagrammi di attività:
Forniscono la sequenza di operazioni
“elementari” che definiscono un’attività più
complessa
Diagrammi comportamentali
Diagrammi strutturali
Diagrammi di classe: Descrivono le classi di
oggetti che compongono il sistema, ossia gli
aspetti che accomunano diversi oggetti nella loro
struttura e nel loro comportamento
Diagrammi di implementazione : Illustrano le
interazioni nel sistema organizzandole attorno
agli oggetti e ai legami tra gli oggetti
Diagrammi comportamentali
Use case diagrams
Specificano il comportamento del sistema, ossia come
il sistema agisce e reagisce dal punto di vista degli
attori (possibili figure di utenti del sistema)
Sequence diagrams
Forniscono una rappresentazione dei vari “scenari”
che possono verificarsi nel ciclo di vita del sistema
orientata a visualizzare in sequenza le interazioni tra
gli oggetti del sistema. Quando due oggetti
interagiscono? E cosa trasmettono l’uno all’altro?
Diagrammi comportamentali
Collaboration diagrams
Illustrano le interazioni nel sistema organizzandole
attorno agli oggetti e ai legami tra gli oggetti (come i
Sequence Diagrams descrivono i possibili scenari, ma
da un diverso punto di vista)
Component diagrams
Rappresentano come i moduli software del
sistema (le componenti) sono organizzati e
quali sono le loro dipendenze
Statechart diagrams (diagrammi di stato)
Descrivono il "ciclo di vita" degli oggetti del sistema,
visualizzando in che modo essi vengono modificati da
eventi che possono occorrere nella processo di
funzionamento del sistema
Deployment diagrams (diagrammi di allocazione)
Illustrano la dislocazione al run-time dei nodi
elaborativi, delle componenti, dei processi e
degli oggetti che risiedono presso di essi.
4
Diagramma dei casi d’uso
Use Cases Diagram
Ci sono modi diversi di guardare a un SISTEMA.
Ø"aprirlo" e guardarci dentro, per vedere come è
strutturato all'interno ( punto di vista del progettista)
Ø guardare a come può essere utilizzato. In questo caso
il sistema viene visto come una "black box", sigillata, ed
è possibile osservarne solo i comportamenti dall'esterno
( punto di vista dell'utilizzatore, e di tutto ciò che
interagisce con il sistema nell'ambito del suo
funzionamento).
Questo secondo punto di vista corrisponde al modello dei
casi d'uso.
Casi d’uso
Casi d’uso
§ Il termine "use case" è stato coniato dal
metodologo svedese Ivar Jacobson.
I casi d'uso svolgono un duplice ruolo nello
sviluppo di un sistema.
§ I casi d'uso sono semplicemente i modi in cui
il sistema può essere utilizzato.
§ nelle fasi iniziali della progettazione, servono
per chiarire cosa dovrà fare il sistema.
§ guidano l'intero progetto di sviluppo.
Caso d’uso
Modellare la realtà
Un caso d’uso rappresenta un’interazione tra un
utente ed il sistema: cattura le funzionalità del
sistema da realizzare così come esse sono
percepite dall’utente.
Registra voti
I casi d’uso sono le
azioni che un utente
intraprende in un
sistema
Un sistema è qualcosa che svolge una funzione
Secondo UML, modellare la realtà d’interesse
significa:
•
individuare tutti i possibili casi d’uso del
sistema
•
individuare tutti gli utenti dei singoli casi
d’uso (attori)
•
rappresentare le interazioni tra casi d’uso e
utenti
5
Attore – cosa è?
Qualcuno o qualcosa, esterno
al sistema, che interagisce con
i casi d’uso.
Ogni attore corrisponde ad un insieme
coerente di ruoli che i soggetti esterni
possono assumere interagendo con il sistema.
Individuazione Attore
Attore – cosa è?
Gli attori comunicano con il
sistema inviando o ricevendo
messaggi: forniscono lo stimolo
“trigger” agli use case; ciò
equivale a dire che ogni caso
d’uso deve essere avviato da
una esplicita richiesta di un
attore
Individuazione Attore
Primari (o attivi): avviano le funzionalità
proprie del sistema, forniscono uno stimolo
al sistema
Primari (o attivi): avviano le funzionalità
proprie del sistema, forniscono uno stimolo
al sistema
Secondari: fruiscono di informazioni o
notifiche generate da use case eseguiti da
altri attori, ricevono messaggi e non
forniscono un vero e proprio stimolo
Secondari: fruiscono di informazioni o
notifiche generate da use case eseguiti da
altri attori, ricevono messaggi e non
forniscono un vero e proprio stimolo
Sistema
E' l'entità i cui utilizzi vengono descritti dall'insieme
dei casi d'uso.
Un insieme completo di casi d'uso descrive in modo
completo gli utilizzi del sistema dall'esterno, ossia dal
punto di vista degli attori che interagiscono con esso,
senza rivelare la struttura interna del sistema
Sistema
Un confine ideale separa ciò che è interno al
sistema da ciò che ne è al di fuori.
i
casi
d'uso
rientrano
all'interno
del
contesto
del
sistema, mentre
tutti gli attori
sono esterni al
sistema.
6
Confini del Sistema
Il primo passo nella realizzazione dei modelli dei casi
n
d’uso consiste nello stabilire con precisione il confine del
sistema.
La definizione del contesto del sistema è una delle
Attori e casi d’uso
Ogni caso d'uso è collegato agli attori, uno o più, che
partecipano al caso d'uso stesso mediante una
associazione, che ha il significato di "comunicazione"
(rappresentata da una linea continua che collega attore
e caso d'uso).
n
attività più delicate di un progetto,
APPROCCIO ITERATIVO INCREMENTALE
Una buona idea consiste nell’individuare il “core” del nuovo
sistema (le funzionalità indispensabili).
Attori e casi d’uso
L'associazione può essere orientata (ed essere quindi
rappresentata con una freccia), per evidenziare la
direzione delle comunicazioni nell'interazione (si tratta
di una estensione definita nel profilo UML relativo al
Software Development Process).
comunicazione unidirezionale
Generalizzazione
comunicazione bi-direzionale
La comunicazione tra attori e casi d'uso, nei due sensi, avviene
tramite segnali, ed è pertanto da considerarsi asincrona.
Associazioni tra attori
L'unica associazione ammessa tra attori è la specializzazione o
generalizzazione.
ØL'attore specializzato eredita il comportamento del genitore
e loestende in qualche maniera
ØL'attore specializzato eredita la partecipazione a tutti i
casi d'uso con i quali comunica l'attore generico, ma può
partecipare ad ulteriori casi d'uso ai quali l'attore generico
non è collegato.
La relazione di specializzazione, in UML, è espressa graficamente
con una linea continua, e con una punta di freccia triangolare e
bianca.
Cattiva organizzazione gerarchica
attori
Un attore che ne specializza un altro può sempre
essere utilizzato al posto di quello esteso (genitore o
padre)
7
Diagramma ristrutturato
Esempio organizzazione gerarchica attori in un sistema
Associazioni tra casi d’uso
Ogni caso d'uso descrive un
utilizzo completo del sistema, e
non è quindi ammessa in UML la
possibilità che casi d'uso distinti
abbiano tra loro un'associazione
di comunicazione.
Associazioni tra casi d’uso
Le associazioni ammesse sono tre:
• Generalizzazione/Specializzazione
• extend
• include
L'effetto globale dell'utilizzo delle associazioni tra
casi d'uso è comunque quello di una frammentazione
del
singolo
caso
d'uso,
anche
se
basata
sull'"emersione" di particolarità (specializzazione ed
extend) o di comportamenti comuni (include).
Generalizzazione/Specializzazione
Associa un caso d'uso di tipo generale ad uno o più casi d'uso
specializzati .
Generalizzazione/Specializzazione
n
n
n
Ogni caso d'uso generale può avere
più figli (casi d'uso specializzati).
Ogni caso d'uso può avere più padri,
cioè specializzare diversi casi d'uso
generali.
L’esecuzione di use case “fratelli” può
avvenire solo in alternativa
8
Esempio
Generalizzazione/Specializzazione
n
n
Il diagramma indica la proiezione
statica delle funzionalità: specifica
che il caricamento di un ordine
richiede la validazione dell’utente e la
verifica dell’ordine stesso.
Il diagramma non specifica nulla circa
la dinamica dell’operazione
Diagramma degli eventi
n
Include
Generalizzazione/Specializzazione
n
n
Il comportamento specifico di un caso d’uso figlio
può essere indicato inserendo opportune sezioni o
sovrascrivendone altre nella sequenza di azioni
ereditate dallo use case genitore (in modo del
tutto analogo a quanto succede con i metodi nelle
classi)
Quando il caso d’uso geneitore è astratto lo use
case ereditante deve provvedere,
Codice cap 3 pag 41.
n
n
Casi d'uso diversi possono avere in comune una
sequenza di passi da svolgere. In questo caso
è possibile enucleare la sequenza comune, e
definirla come un caso d'uso a sé stante, da
"includere" nei casi d'uso originari.
Così facendo si evidenziano le parti comuni, e
si evitano le ripetizioni nelle descrizioni dei
casi d’uso.
9
Include
Include
n
In termini di sequenza di azioni, che ciascun caso
d’uso esegue per erogare il servizio, la relazione di
Include comporta l’esecuzione della sequenza di
azioni dello use case incluso sotto il controllo e
nella locazione specificata nello use case base.
Use case che
include
<<include>>
Use case incluso
•Ogni caso d'uso può includere un numero illimitato di
altri casi d'uso. Viceversa, ogni caso d'uso può essere
incluso in un numero illimitato di altri casi d'uso.
•L'associazione di inclusione è rappresentata da una
dipendenza (linea tratteggiata, punta della freccia
aperta) con lo stereotipo <<include>> , la cui direzione va
dal caso d'uso "includente" al caso d'uso "incluso".
Esempio
Include
n
Esempio
Il concetto di inclusione è per molti versi analogo a
quello di invocazione di una funzione: viene
eseguita la sequenza di azioni dello use case base
quando viene raggiunto un punto di inclusione il
controllo viene passato al caso d’uso ivi indicato
(incluso) e ne viene eseguita completamente la
sequenza di azioni, quindi il controllo ritorna allo
use case base.
Extend
n
n
n
L'associazione "extend" permette di definire che un
caso d'uso "base" può venire "esteso" con il
comportamento definito in un altro caso d'uso, detto
di estensione.
L'estensione riguarda un comportamento opzionale del
caso d'uso base, ed è soggetta ad una condizione di
attivazione.
Il caso d'uso base "ignora le proprie estensioni". La
sequenza dei passi che lo descrive è in sé completa, e
non contiene alcun riferimento alle condizioni ed ai
comportamenti definiti nel caso d'uso di estensione.
10
Extend
Extend
L'associazione di estensione è rappresentata da una
dipendenza (linea tratteggiata, punta della freccia
aperta) con lo stereotipo <<extend>> , la cui direzione
va dal caso d'uso "di estensione" al caso d'uso "base".
n
Use case che
estende
<<extend>>
Use case esteso
n
n
L'unica particolarità che contraddistingue un caso
d'uso soggetto ad estensioni è che nell'ambito della
sua sequenza vengono definiti uno o più punti di
estensione ("extension point"), che sono dei punti di
ancoraggio ai quali si agganceranno i casi d'uso di
estensione.
I punti di estensione possono essere rappresentati in
un comparto specifico dell'ellisse che rappresenta il
caso d'uso base.
Extend: funzionamento
n
Il funzionamento prevede che quando una
istanza dello use case base raggiunge una
locazione referenziata da un punto di
estensione la condizione viene valuatata :
n
n
Esempio
Se l’esito è positivo (valore TRUE) allora le azioni
specificate nel caso d’uso estendente vengono
eseguite
Altrimenti si procede con le successive istruzione
dello use case base
Extend: funzionamento
n
n
L’assenza di una condizione corrisponde ad un
valore sempre true.
Se una relazione ha più punti di estensione la
condizione viene verificata solo la prima volta
ossia prima dell’esecuzione del primo
frammento
11
Inclusione o Estensione?
Esempio
Opzionalità: se l’esecuzione del flusso di
azioni di uno use case invocato deve
avvenire solo al verificarsi di particolari
condizioni
(ossia
rappresentauna
variante al flusso di azione) bisogna
usare la relazione di estensione.
Inclusione o Estensione?
Se uno use case viene invocato solo da
un altro probabilmente è opportuno
usare l’estensione.
nSe può essere usato nel flusso di
azione di svariati casi d’uso allora è da
preferire la relazione di inclusione
n
Inclusione o Estensione?
Inclusione o Estensione?
La relazione di inclusione ricorda molto
l’invocazione di una procedura (o
metodo) e pertanto lo use case incluso
deve ricevere (dallo use case base) gli
eventuali attributi di cui necessita per
eseguire il flusso di azioni
n
Esempi
Lo use case esteso contiene il flusso
primario degli eventi e non ha
conoscenza diretta di eventuali altri
casi d’uso estendenti
n
12
FINE
13