Lezione UML 2

Diagrammi
TIMING
DIAGRAMS: questo tipo di
diagrammi pongono l’accento sugli aspetti realtime di una interazione. Il loro scopo principale
è aiutare l’utilizzatore di essi a ragionare sul
tempo.
Con questi diagrammi si modella una finestra
di tempo in cui il sistema evolve e non tutto il
tempo, perché il tempo assoluto non è
accessibile agli sviluppatori.
Naturalmente il tempo che viene specificato è
più o meno un certo errore che è determinato
da fattori esterni come ad esempio
l’accuratezza dell’orologio di sistema.
Diagrammi
TIMING DIAGRAMS: esempio tratto dal libro
“UML 2and the Unified Process”, pg. 428.
Diagrammi
COMMUNICATION DIAGRAMS: mostrano
una collaborazione dinamica, come il sequence
diagram. Il communication diagram oltre a
mostrare lo scambio di messaggi (iterazione)
mostra anche gli oggetti e le loro relazioni (a
volte riferite col nome di contesto). La scelta se
usare i sequence o i communication diagrams
viene fatta tenendo presente che:
• se il TEMPO o la SEQUENZA è l’aspetto più
importante da valutare⇒SEQUENCE DIAGRAMS
• se il CONTESTO è l’aspetto più importante da
valutare ⇒ COMMUNICATION DIAGRAMS
I communication diagrams possono contenere
oggetti attivi, cioè in esecuzione concorrente
con altri oggetti.
Diagrammi
:Computer
1:Stampa(file)
:Coda
[Stampante occupata]
1.2:Accoda(file)
:ServerStampante [Stampante libera]
1.1:Stampa(file)
:Stampante
Diagrammi
ACTIVITY DIAGRAMS: mostrano i flussi
sequenziali delle attività. E’ usato per
descrivere le attività eseguite in una operazione
oppure per altri flussi di attività (use-case o
una interazione).
Un activity diagram è composto da stati di
azioni (ACTION STATES) che contengono una
specificazione o una azione da fare. Un action
state lascerà lo stato quando l’azione sarà stata
eseguita (c’è bisogno di un evento esplicito per
poter lasciare lo stato).
Diagrammi
Mostra il msg
“Disco pieno”
sullo schermo
[disco pieno]
PrintFile()
[spazio libero su disco]
Mostra il msg
“Stampa in corso”
sullo schermo
Rimozione msg
^Stampante.Stampa(file)
Creazione file
postscript
Diagrammi
INTERACTION-OVERVIEW
DIAGRAMS: questo tipo di diagramma
mostra quanto un comportamento
complesso è realizzato tramite un insieme
di interazioni semplici. Questo tipo di
diagramma è un caso speciale di
diagramma di attività nel quale i nodi si
riferiscono ad altre interazioni.
Questi diagrammi sono utili per
modellare il controllo del flusso
all’interno di un sistema.
Diagrammi
INTERACTION-OVERVIEW DIAGRAMS: esempio
tratto dal libro “UML 2and the Unified Process”, pg.
324.
Diagrammi
INTERACTION-OVERVIEW DIAGRAMS: Come si vede
dalla figura precedente questi diagrammi hanno la stessa sintassi
degli activity diagrams, eccetto che in questo caso si possono
mostrare interazioni in linea e occorrenze di iterazioni piuttosto
che nodi e oggetti di attività.
E’ possibile mostrare in questi diagrammi il branching, la
concurrency e il looping.
Azione
Interaction Overview
Diagram
Branching
Nodi di decisione e di
fusione
Concurrency
Nodi di fork e di join
Looping
Cicli nel diagramma
Diagrammi
COMPONENT DIAGRAMS: mostrano la
struttura fisica del codice in termini di
componenti di codice. Un componente contiene
informazione sulla classe o le classi logiche che
implementa, creando quindi un mapping dalla
logical view alla component view.
I component diagrams si usano nel lavoro di
programmazione pratico.
Diagrammi
Gestore
finestre
(whnd.cpp)
Gestore
comandi
(comhnd.cpp)
Liberia grafica
(graphic.dll)
Gestore
finestre
(whnd.obj)
Gestore
comandi
(comhnd.obj)
Classe
principale
(main.cpp)
Classe
principale
(main.obj)
Programma
client
(client.exe)
Diagrammi
DEPLOYMENT DIAGRAMS: mostrano l’architettura
fisica dell’hardware e del software del sistema. Si
possono vedere i computer reali e i dispositivi (detti
NODI), le connessioni che ci sono tra loro e i tipi.
ClientA:
Compaq
Pro PC
«TCP/IP»
Application
Server:
JRun
ClientB:
Compaq
Pro PC
«TCP/IP»
«JDBC»
Database
Server:
Oracle
Elementi di Modellazione
Sono i concetti utilizzati nei diagrammi.
Un elemento di modellazione è definito
tramite:
• la semantica;
• una definizione formale dell’elemento oppure
• il significato esatto di quello che rappresenta,
tramite “statements” non ambigui.
Essi hanno un corrispondente elemento
vista (view element) che ne è la
rappresentazione grafica
Essi possono esistere in diversi tipi di
diagrammi (ma seguendo delle regole)
Elementi di Modellazione Comuni:
Rappresentazioni Grafiche
Class
Attributes
Object
Attributes
State
Use Case
Operations
Operations
Interface
Note
Node
Package
Component
Elementi di Modellazione
Altri elementi di modellazione oltre a quelli standard (classe,
oggetto, stato, nodo, package, componente) sono, messaggi, azioni e
stereotipi e :
le RELAZIONI, servono per connettere altri elementi di
modellazione tra loro. I tipi più usati sono:
• L’ASSOCIAZIONE (connette elementi e collega istanze)
• LA GENERALIZZAZIONE (o ereditarietà, significa che un
elemento può essere la specializzazione di un altro e può
sostituire quest’ultimo)
• LA DIPENDENZA (un elemento dipende in qualche modo da
un altro e può essere influenzato dai cambiamenti dell’altro)
• L’AGGREGAZIONE (una forma di associazione in cui un
elemento è parte di altri elementi)
• LA COMPOSIZIONE (una forma di aggregazione molto più
forte che ha molti più vincoli)
• IL CONTENIMENTO (un elemento di partenza contiene un
altro elemento di destinazione)
• LA REALIZZAZIONE (l’elemento di partenza garantisce di
adempiere al contratto specificato dall’elemento destinazione)
Elementi di Modellazione:
Le Relazioni
Associazione
Generalizzazione
Dipendenza
Aggregazione
Composizione
Contenimento
Realizzazione
Meccanismi generali
Vengono usati in UML per dare
informazione addizionale nei diagrammi
Si usano anche per rappresentare tutto ciò
che non può essere rappresentato tramite gli
elementi di modellazione.
Essi sono:
• ADORMENTS (abbellimenti);
• NOTES;
• SPECIFICATIONS (specificazioni).
Meccanismi generali:
Adornments
Sono agganciati agli elementi di
modellazione nei diagrammi e ai nodi
aggiungendo semantica all’elemento (o al
nodo).
Class
unOggetto:
Class
Meccanismi generali:
Notes
Tutto quello che non può essere definito
attraverso il linguaggio di modellazione
può essere rappresentato con le NOTE.
Una nota può stare in qualunque parte del
diagramma e può contenere qualunque tipo
di informazione.
Essa è una stringa che non viene interpretata
dall’UML.
Le note hanno anche degli stereotipi che
descrivono il tipo di nota.
Meccanismi generali:
Notes
Opzioni dello Stock
TheorPrice()
MarketPrice()
ExpireDate()
Utilizzare la
formula di
Black&Schole
Meccanismi generali:
Specifications
Gli elementi di modellazione hanno proprietà
che contengono i valori dei dati per
quell’elemento.
Una proprietà è definita con un nome ed un
valore chiamato TAGGED VALUE (di un tipo
specifico).
Le proprietà vengono usate per aggiungere
specificazioni aggiuntive circa le istanze
dell’elemento che normalmente non sono visibili
nel diagramma (es.: una classe può essere descritta
con del testo che in modo più informale specifica le
responsabilità e le capacità della classe).
Meccanismi generali:
Specifications
Alcune estensioni per l’UML
L’UML può essere esteso o adattato ad
uno specifico metodo, organizzazione o
utente.
I meccanismi usati per farlo sono:
• stereotipi;
• tagged values;
• vincoli (constraints).
Stereotipi
Definiscono un nuovo tipo di elemento di
modellazione basandosi su un elemento di
modellazione esistente.
Gli stereotipi sono basati su tutti i tipi di
elementi: classi, nodi, componenti e note e
anche
sulle
relazioni:
associazioni,
generalizzazioni e dipendenze.
Esso è descritto mettendo il suo nome come
stringa tra virgolette angolate vicino al nome
dell’elemento.
Può
anche
avere
una
rappresentazione grafica.
Stereotipi
«Attore»
Cliente
Cliente
Cliente
Tagged Values
Proprietà degli elementi che contengono
coppie nome-valore di informazione su di
essi.
Qualunque tipo di informazione può essere
agganciata agli elementi.
Prodotto Finanziario
{abstract}
{autore=“HEE”}
{stato=draft}
Valore:int
expdate:Date
Vincoli (Constraints)
Il vincolo è una restrizione su un elemento
che limita l’uso dell’elemento o della
semantica (significato) dell’elemento.
Un vincolo o viene dichiarato nel tool (vedi
disegno delle specificazioni) e usato
ripetutamente nei diversi diagrammi o è
definito e applicato dove necessario in un
diagramma.
Vincoli (Constraints)
Gruppo
cittadini
anziani
0..1
{persona.età>60}
0..*
Persona
Modellazione con UML
Quando si costruiscono dei sistemi con
UML non ne viene costruito solamente un
singolo modello.
Ci sono modelli distinti nelle diverse fasi
dello sviluppo e gli obiettivi dei modelli
sono diversi.
Le fasi di modellazione di un sistema sono:
•
•
•
•
ANALISI;
PROGETTAZIONE;
IMPLEMENTAZIONE;
DEPLOYMENT.
Modellazione con UML: Analisi
e Progettazione
Analisi: obiettivo del modello è catturare I
requisiti del sistema e modellare le classi di
base e le collaborazioni del “mondo reale”.
Progettazione: obiettivo del modello è
espandere il modello di analisi in una
soluzione tecnica funzionante (operativa)
tenendo in considerazione l’ambiente di
implementazione.
Modellazione con UML:
Implementazione e Deployment
Implementazione: il modello qui è il codice
sorgente vero e proprio che viene
programmato e compilato in programmi.
Deployment: il modello consiste in una
descrizione che spiega come il sistema è
strutturato nell’architettura fisica.
Modellazione con UML
Modello del sistema
Analisi
Progettazione Implementazione Deployment
Modellazione con UML
Il cammino tra le fasi ed i modelli viene
mantenuto attraverso le proprietà e le
relazioni di raffinazione.
Nonostante i modelli visti in precedenza
siano diversi tra loro, essi vengono
normalmente costruiti espandendo i
contenuti dei modelli ad essi precedenti.
Modellazione con UML
UML è indipendente dalle fasi cioè lo stesso
linguaggio generico e gli stessi diagrammi
vengono usati per modellare cose diverse in
fasi diverse.
Lo scopo e il proposito che il modello deve
garantire lo decide chi modella il sistema.
Il linguaggio di modellazione dà soltanto la
possibilità di creare modelli in una maniera
espressiva e consistente.
Modellando con UML il lavoro dovrebbe
essere guidato da un metodo (o processo) che
sottolinei i diversi passi da fare e come devono
essere implementati.
Modellazione con UML
Il processo che abbiamo citato prima
tipicamente divide il lavoro in iterazioni
successive delle fasi di: ANALISI DEI
REQUISITI/ANALISI/PROGETTAZIONE/IMPLEM
ENTAZIONE/DEPLOYMENT.
Comunque c’è anche un processo più veloce di
questo riguardante il reale lavoro di
modellazione (vedi figura).
Input: conoscenza,
esperienza, descrizione del
problema, obiettivi, ecc.
Fase delle
idee
(brillanti)
Fase di
schematizzazione
(bozza)
[La schematizzazione assomiglia
ad un approccio pratico]
Organizzazione
Verifica
Validazione
Prototipizzato e testato
[Trovati dei difetti]
Organizza la
schematizzazione
informale in un tool per
produrre diagrammi più
formali
Specifica i dettagli del
diagramma (processo
iterativo quanto più si
acquisisce informazione
sul modello)
Specificazione
Integrazione
Uso di strumenti
informali come la
lavagna e i Post-it
Valutato
[Risultato soddisfacente]
Verifica il diagramma
insieme con gli altri
diagrammi, e verifica e
valida che i requisiti
vengano soddisfatti
correttamente
Costruisce un prototipo
e lo testa (si possono
prototipizzare un certo
numero di diagrammi
tutti insieme)
Valuta il risultato; torna
in dietro e corregge gli
eventuali difetti
Modellazione Use Case
Tecnica usata per descrivere cosa deve fare
un nuovo sistema o cosa può fare un
sistema già esistente;
I componenti principali di un modello use case sono:
• Il SISTEMA MODELLATO;
• Gli USE CASES;
• Gli ATTORI.
Modellazione Use Case
I confini del sistema sono definiti dalle
funzionalità che sono trattate dal sistema
Ogni use case rappresenta una funzionalità
completa. (Per rappresentare una funzionalità
completa lo use case deve descrivere l’intera funzione
dall’inizio scatenato da un attore esterno fino
all’esecuzione dell’intera funzionalità). Esso deve
sempre restituire un valore ad un attore che è
ciò che l’attore vuole avere dal sistema
L’attore è una qualsiasi entità esterna che ha
un certo interesse ad interagire con il sistema
(utente umano, altro sistema o altro dispositivo
hardware)
Modellazione Use Case
Nella modellazione use case il sistema è visto
come una scatola nera che fornisce delle
funzionalità (use cases)
Gli obiettivi primari degli use cases sono :
• DECIDERE e DESCRIVERE i requisiti funzionali del sistema
(accordo tra clienti e sviluppatori del sistema)
• Fornire una DESCRIZIONE CHIARA e CONSISTENTE di
quello che il sistema dovrebbe fare (il modello verrà così
utilizzato attraverso il processo di sviluppo per comunicare a
tutti gli sviluppatori quei requisiti idividuati)
• Fornire una base per l’esecuzione dei test di sistema e per la
sua verifica
• Fornire l’abilità di tracciare i requisiti funzionali nelle classi
effettive e nelle operazioni del sistema per semplificare i
cambiamenti e le estensioni al sistema (cambiando solo quei
particolari use cases che devono essere modificati)
Modellazione Use Case
Il lavoro da fare per la creazione di un modello use case
consiste nel:
•
•
•
•
•
Definire il sistema;
Trovare gli attori e gli use cases;
Descrivere gli use cases;
Definire le relazioni tra use cases;
E validare il modello.
Il modello use case è rappresentato da diagrammi use
cases che mostrano gli attori, gli use cases e le loro
relazioni
Questi diagrammi danno una panoramica generale del
modello ma la vera descrizione è testuale (devono
essere usati entrambi affinché i modelli visuali possano
fornire tutta l’informazione necessaria nel modello use
case)
Diagrammi Use Case
In UML, un modello use case viene descritto da un
numero di diagrammi use case
Un diagramma use case contiene gli elementi di
modellazione per il sistema, per gli attori e mostra le
diverse relazioni come:
• La generalizzazione;
• L’associazione;
• E la dipendenza
Tra questi elementi.
La descrizione dei contenuti viene fatta attraverso l’uso
del testo (in UML essa è la proprietà di
documentazione per gli elementi use case)
L’alternativa al testo è l’uso dei diagrammi di attività
(N.B.: Uno use case descritto tramite testo è di più
facile comunicazione sia al cliente che all’utente finale
del sistema)