Introduzione a UML Linguaggio di Modellazione Unificato

Introduzione a
UML
Linguaggio di Modellazione
Unificato
Corso di Ingegneria del Software
Anno Accademico 2006/2007
1
Che cos’è UML?
●
●
●
●
UML (Unified Modeling Language) è un
linguaggio grafico per:
–
specificare
–
visualizzare
–
realizzare
–
documentare i manufatti di un sistema software.
Adottato come standard da OMG (Object
Management Group) dal 1997 (UML 1.1)
La versione attuale è UML 2.0 (2004)
Creatori: Grady Booch, Ivar Jacobson, Jim
Rumbaugh
2
OMG
●
●
Object Management Group (OMG).
OMG è un'organizzazione no-profit con 700
membri che definisce gli standard per
supportare l'interoperabilità tra sistemi
orientati agli oggetti.
3
Storia di UML
4
Hanno contribuito a UML
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
Aonix
Colorado State University
Computer Associates
Concept Five
Data Access
EDS
Enea Data
Hewlett-Packard
IBM
I-Logix
InLine Software
Intellicorp
Kabira Technologies
Klasse Objecten
Lockheed Martin
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
Microsoft
ObjecTime
Oracle
Ptech
OAO Technology Solutions
Rational Software
Reich
SAP
Softeam
Sterling Software
Sun
Taskon
Telelogic
Unisys
...
5
Obiettivi UML
●
●
●
●
Definire un linguaggio di modellazione semplice ma ricco
di concetti
Unificare i linguaggi di modellazione OO: Booch, OMT,
Objectory e gli altri presenti sul mercato
Adottare le “best practices” dell’industria
Considerare le tematiche attuali dello sviluppo del
software:
–
●
Scalabilità, distribuzione, concorrenza, ecc.
Abilitare l’interscambio dei modelli OO e aiutare la
definizione di repository per i modelli
6
UML: Modeling Language (1/3)
●
●
Un linguaggio fornisce un vocabolario e le
regole per combinare le parole del
vocabolario.
Linguaggio:
–
Sintassi: regole con cui gli elementi del linguaggio
(ad es. le parole) sono raggruppati in espressioni
(ad es. le frasi).
–
Semantica: regole con cui viene assegnato un
significato alle espressioni sintattiche.
7
UML: Modeling Language (2/3)
●
●
Un modeling language è un linguaggio in cui il
vocabolario e le regole si focalizzano sulla
rappresentazione concettuale e fisica del
sistema
UML
–
Sintassi: simboli usati nel modello
–
Semantica: set di regole che definiscono come
usare la notazione
8
UML: Modeling Language (3/3)
●
●
●
Un modeling language come UML definisce
come creare e leggere modelli ben formati ma
non quali modelli creare.
Modello ben formato: modello (o parte di un
modello) che rispetta tutte le regole semantiche
e sintattiche che gli si applicano.
Tutti gli elementi e i diagrammi UML sono
basati sul paradigma object-oriented
9
Modelli ben formati
●
●
UML permette di specificare regole (tra
l'altro) per:
–
Dare i nomi
–
Visibilità dei nomi
–
Esecuzione (in modo limitato)
Durante lo sviluppo iterativo e incrementale, è
possibile che i modelli siano incompleti e
inconsistenti
10
Regole comuni a tutti i diagrammi
●
●
●
I diagrammi UML sono grafi contenenti nodi e
connessioni
Vi sono tre relazioni topologiche importanti:
–
la connessione (forme bidimensionali collegate con
linee)
–
il contenimento
–
la prossimità (di due simboli)
Di solito, le dimensioni non hanno importanza.
11
Esempi di Regole
●
●
Regole sintattiche: Classe
–
Notazione base: una classe si disegna come un rettangolo
delimitato da riga continua, avente tre compartimenti
separati da righe orizzontali
–
Opzioni di presentazione: i compartimenti con gli attributi
e/o con le operazioni possono essere non visibili
Linee guida sintattiche: Classe
–
I nomi delle classi dovrebbero iniziare con lettera
maiuscola
–
I nomi degli attributi dovrebbero iniziare con la lettera
minuscola
12
I quattro costrutti grafici di UML
●
●
Icone:
Simboli
bidimensionali:
●
Collegamenti:
●
Stringhe:
integrate (f: Function, from: Real, to: Real)
13
Costrutti grafici di UML
●
●
●
●
Le icone hanno dimensioni e forma fisse, e non
contengono nulla
I simboli bidimensionali:
–
hanno dimensioni variabili
–
possono essere espansi e contenere altre entità
–
possono essere suddivisi in compartimenti
I collegamenti sono linee curve o spezzate che
terminano con connessioni a due simboli
Le stringhe hanno molti usi e possono apparire
entro liste
14
Blocchi base di UML
●
Elementi: astrazioni che rappresentano
concetti di prima classe del modello.
–
●
Relazioni : relazioni tra le cose.
–
●
Classi, interfacce, componenti, casi d’uso, ecc.
Associazioni, generalizzazioni, dipendenze, ecc.
Diagrammi : raggruppano collezioni
interessanti di elementi.
–
Diagrammi delle classi, dei casi d’uso,
d’interazione, ecc.
15
Modelli UML
●
Modello statico:
–
●
Rappresenta gli elementi strutturali di un sistema
software (la struttura dati e l’architettura) e le loro
relazioni statiche (cioè invarianti al trascorrere del
tempo).
Modello dinamico:
–
Rappresenta il comportamento di un sistema
software al trascorrere del tempo.
16
Modellazione strutturale
●
●
●
Rappresenta una vista di un sistema software
basata sulla struttura degli oggetti (classi di
appartenenza, relazioni, attributi, operazioni)
E’ rappresentata dal modello statico
Il diagramma delle classi è il principale
diagramma UML per rappresentare un
modello statico
17
Modellazione Strutturale
Entità Fondamentali
18
Modellazione Strutturale
Relazioni Fondamentali
Costrutto
Descrizione
Associazione
Una relazione tra due o più tipi che comporta un collegamento tra le loro istanze
Aggregazione
Una forma di aggregazione che specifica
una relazione tutto-parti tra le istanze
Generalizzazione
Una relazione di classificazione tra un
tipo più specifico ed uno più generale
Dipendenza
Una relazione tra due elementi, per cui
un cambiamento dell’elemento indipendente influenza l’elemento dipendente
Sintassi
19
Modellazione Strutturale
Relazioni Fondamentali
Costrutto
Descrizione
Realizzazione
Una relazione tra una specifica
e la sua implementazione
Sintassi
Annidamento
20
I diagrammi di modellazione
strutturale
●
Mostrano la struttura statica del modello OO:
–
●
le entità presenti nel modello (classi, interfacce,
componenti, nodi, ecc.), la struttura interna e le
relazioni con altre entità
Non mostrano informazione dipendente dal
tempo
21
I diagrammi di modellazione
strutturale
●
Principali tipi di diagrammi:
–
Composite structure diagram
–
Diagrammi strutturali statici:
●
●
–
Diagrammi di classe
Diagrammi degli oggetti
Diagrammi d’implementazione:
●
●
●
Diagrammi dei componenti
Diagrammi di dispiegamento (deployment)
Diagramma dei package
22
Diagrammi di struttura statica
●
●
●
Mostrano le entità del sistema connesse
secondo le relazioni statiche che le
caratterizzano
Diagrammi di classe:
–
Mostrano le classi e le loro relazioni
–
Sono a un livello di astrazione alto
–
Sono utilizzabili per generare il codice con le
strutture dati e le dichiarazioni delle funzioni
Diagrammi degli oggetti
–
Mostrano istanze delle classi durante uno scenario
di funzionamento del sistema
23
Diagrammi comportamentali
●
Rappresentano caratteristiche comportamentali
di un sistema o di un processo di business.
●
Mostrano informazione dipendente dal tempo
●
Principali tipi di diagrammi:
–
Diagramma dei casi d'uso
–
Diagramma di attività
–
Diagramma delle macchine a stati
–
Diagrammi di interazione: enfatizzano le interazioni tra
oggetti
●
●
Diagramma di sequenza
Diagramma di interazione
24
Diagrammi UML 2
●
●
●
Vedi diagramma “classificazione dei tipi di
diagrammi in UML 2”
Segue una breve sintesi dei diagrammi di
UML 2.0, eccetto i diagrammi delle classi,
degli oggetti e di stato
Per ogni diagramma si elencano:
–
Le notazioni principali
–
Il significato di tali notazioni
–
L'importanza e l'uso del diagramma
25
I diagrammi dei pacchetti
(package)
●
●
●
Denotano graficamente che pacchetti
(sottosistemi) che compongono il sistema, e
quali sono le loro dipendenze
Se si genera del codice, ogni pacchetto
corrisponde tipicamente ad un “namespace”
Un pacchetto può contenere altri pacchetti, e/o
un diagramma delle classi.
26
I diagrammi dei pacchetti
(package)
27
Relazioni tra pacchetti (1/2)
28
Relazioni tra pacchetti (2/2)
●
●
●
●
dipendenza semplice: le classi di P4 utilizzano
le classi di P3 (in modo generico)
import:importazione pubblica. P3 incorpora il
contenuto di P2, e lo può a sua volta esportare
access: importazione privata. P3 incorpora il
contenuto di P1, ma non lo esporta
Un pacchetto può anche essere annidato entro
un altro
29
Relazione merge tra pacchetti (1/2)
30
Relazione merge tra pacchetti (2/2)
●
●
E’ una dipendenza complessa: un “merge”
equivale a un “import”, con in più una
relazione di generalizzazione tra le classi
omonime di cliente e fornitore
(Se ne sconsiglia l’uso!)
31
Composite structure diagram (1/2)
●
●
Permette di rappresentare un intero sistema,
dandone i componenti interni, le interfacce, le
porte
Utile anche per rappresentare sistemi Web
32
Composite structure diagram (2/2)
33
Diagrammi di implementazione
●
Mostrano aspetti dell’implementazione di un
modello:
Struttura del codice sorgente
– Struttura del sistema in esecuzione
Due diagrammi:
–
●
–
Diagramma dei componenti (component diagram)
–
Diagramma di dispiegamento (deployment
diagram)
34
Diagramma dei componenti
●
●
●
Un componente è una parte di un sistema sw,
che contiene l' implementazione e che rispetta
un insieme di interfacce e ne fornisce una
realizzazione
Mostra l’organizzazione delle componenti
software e le interazioni tra di esse
Non è particolarmente usato o significativo
35
Diagramma dei componenti
36
Diagramma dei componenti
37
Diagramma di dispiegamento
(deployment)
●
●
●
Mostra la configurazione di ogni elemento a
run-time, oltre che delle componenti software,
dei processi, e degli oggetti in esso presenti
Può essere usato per mostrare il nodo in cui
ogni componente entra in esecuzione
Non è particolarmente usato o significativo
38
Diagramma di dispiegamento
39
Diagramma di dispiegamento
(parti)
40
Diagramma di dispiegamento
(parti)
41
Diagramma di attività
●
Mostra il flusso di esecuzione di elaborazioni
●
Equivale ai classici diagrammi di flusso
●
Usa la notazione di Harel:
42
Un altro diagramma di attività
43
Diagramma di temporizzazione
●
●
Mostra l’andamento temporale di uno stato e/o
di un valore di oggetti del sistema
Può anche mostrare le interazioni tra eventi
temporali, ed i vincoli temporali che li
governano
44
Diagramma di temporizzazione
●
●
Andamento
di uno stato
Andamento
di un valore
45
Un diagramma di temporizzazione
completo
●
●
Diagrammi di stato e valore si sovrappongono, con lo
stesso asse dei tempi
L’effetto di un evento (transizione o cambio di valore) su
uno stato o su un valore si denota con una freccia
46
Diagramma complessivo di
interazione (Interaction overview)
●
●
●
●
E’ una forma di diagramma di attività, in cui i nodi
sono diagrammi di interazione (sequenziali, di
comunicazione, di temporizzazione, di attività,
complessivi di interazione) esistenti nel modello o
riportati direttamente
Una “Interaction occurrence” è un riferimento ad un
diagramma esistente, il cui nome è riportato al
centro, e con un “ref” in alto a sinistra
Un “Interaction element” mostra direttamente il
diagramma riferito al suo interno.
E’ un diagramma di altro livello, che mostra il
funzionamento in risposta a richieste o interazioni
esterne.
47
Diagramma complessivo di interazione
(Interaction overview)
48
UML & ciclo di vita del SW (1/3)
●
Analisi dei Requisiti
–
●
Casi d'uso: catturano i requisiti del cliente
Analisi
–
Diagramma delle classi: definisce un vocabolario
del dominio
–
Diagramma delle attività: chiarisce il
funzionamento dei casi d'uso
–
Diagramma di stato: risulta utile se un'entità può
assumere diversi stati
49
UML & ciclo di vita del SW (2/3)
●
Progettazione:
–
I diagrammi della fase di analisi diventano più
tecnici
●
●
Diagramma delle classi
Diagramma di stato
–
Diagramma di sequenza: descrive gli scenari dei
casi d'uso
–
Diagramma dei package: mostra l'organizzazione
del software su larga scala
–
Diagramma di deployment: visualizza la
distribuzione fisica del sistema
50
UML & ciclo di vita del SW (3/3)
●
Codifica:
–
●
I modelli definiti nella fase di design vengono
convertiti in codice
Testing:
–
Unit Test: si parte tipicamente dal diagramma
delle classi
–
Integration Test: si parte dai diagramma dei
componenti e dal diagramma di collaborazione
–
System Test: si parte dai casi d'uso
51