Politecnico
di Milano
UML (Unified Modeling Language)
un linguaggio di modellazione orientato agli oggetti
Luigi Lavazza
CEFRIEL
[email protected]
© 2005 - CEFRIEL
Sommario




Introduzione ai linguaggi di modellazione
Fondamenti del paradigma object-oriented
UML: il linguaggio
Esempi di modellazione con UML
Unified Modeling Language
2
© 2005 - CEFRIEL
I modelli




Ragionare sui sistemi complessi è difficile.
Costruire sistemi complessi è difficile.
Come fare a valutare aspetti notevoli dei sistemi, o a valutare l’efficacia di soluzioni
costruttive senza affrontare l’intera complessità di un sistema reale?
Usando dei modelli.
Unified Modeling Language
3
© 2005 - CEFRIEL
Modellare: un’idea nuova?


Non proprio
si pensi al modello di cupola del Brunelleschi
Unified Modeling Language
4
© 2005 - CEFRIEL
Caratteristiche del modello



Astrazione
Modularità
Viste molteplici
Unified Modeling Language
5
© 2005 - CEFRIEL
Astrazione


Un sistema reale è caratterizzato da un numero impressionante di elementi.
Spesso, solo una minima parte di tale elementi risultano “interessanti”
– NB: cosa sia interessante dipende dal contesto


Ne consegue che il modello può trascurare i dettagli irrilevanti.
Astrazione = descrizione di un sistema (o di parte di esso) che ne riporta solo le
caratteristiche rilevanti.
Unified Modeling Language
6
© 2005 - CEFRIEL
Astrazione: esempio

Caratteristiche di una persone:
–
–
–
–
–
–
–
–
–

Nome,
Indirizzo
Età
Numero di scarpe
Gruppo sanguigno
Codice fiscale
Fede calcistica
Reddito
…
La stragrande maggioranza dei contesti che possiamo immaginare richiedono la
conoscenza di un sottoinsieme di queste caratteristiche
Unified Modeling Language
7
© 2005 - CEFRIEL
Modularità


Divide et impera
Un sistema è modulare se è diviso in parti che hanno una sostanziale autonomia
individuale ed una ridotta interazione con le altre parti
– i moduli sono scarsamente connessi e fortemente coesi
Unified Modeling Language
8
© 2005 - CEFRIEL
Cinque criteri di modularità

Scomponibilità modulare
– scomporre un problema in sottoproblemi di minori dimensioni e quindi più facilmente affrontabili

Componibilità modulare
– ri-aggregare moduli esistenti per risolvere problemi nuovi
– riusabilità
– ES: Lego

Comprensione modulare
– capire un modulo osservando solo quello e i "confinanti“

Continuità modulare
– un piccolo cambiamento nelle specifiche comporta cambiamenti in un solo (o pochi) moduli
– estendibilità

Protezione modulare
– errori in un modulo influenzano solo il modulo stesso (o al massimo si propagano ai confinanti)
Unified Modeling Language
9
© 2005 - CEFRIEL
Come ottenere la modularità


Unità linguistiche modulari
Poche interfacce
– ciascun modulo deve comunicare con il minor numero possibile di altri moduli
– in un sistema composto da n moduli il numero delle interfacce deve essere quanto più possibile
vicino a (n-1) e lontano da n(n-1)/2

Interfacce piccole
– ogni modulo deve scambiare il minor numero possibile di informazioni con gli altri moduli

Interfacce esplicite
– il fatto che due moduli A e B comunichino deve risultare evidente sia dal codice di A che dal codice
di B

Information hiding
– il modulo deve distinguere tra informazioni pubbliche ed informazioni private
Unified Modeling Language
10
© 2005 - CEFRIEL
Molteplici viste


Un sistema complesso presenta molteplici “aspetti” che devono essere considerati ed
adeguatamente descritti per rappresentare il sistema, ritraendone tutte le
caratteristiche.
Risulta quindi difficile comprimere in un unico modello informazioni di natura anche
molto diversa: si consideri ad esempio il fatto che una rappresentazione adeguata del
sistema deve descrivere
–
–
–
–
–

la struttura statica
il comportamento dinamico
l’organizzazione logica
la distribuzione fisica
ecc.
Soluzione: non un modello, ma più modelli, ciscuno specializzato per fornire un certo
tipo di informazioni
Unified Modeling Language
11
© 2005 - CEFRIEL
Molteplici viste


Un’idea nuova?
Non proprio …
Unified Modeling Language
12
© 2005 - CEFRIEL
Linguaggi di descrizione

Le “descrizioni” vengono prodotte in svariate fasi del processo:
– Descrizione = insieme di affermazioni riguardo una qualche realtà di interesse
– Problem definition = fra l’altro, descrizione del problema da risolvere
– Program design = fra l’altro, descrizione del comportamento del sistema da realizzare

Linguaggi di descrizione = linguaggi adatti a scrivere “descrizioni”
Unified Modeling Language
13
© 2005 - CEFRIEL

Completezza
Caratteristiche dei linguaggi di
descrizione
– Il linguaggio deve mettere a disposizione strumenti per descrivere tutti gli aspetti di interesse.

Accuratezza
– Deve essere possibile costruire una descrizione precisa.

Consistenza
– Il linguaggio deve aiutare a non esprimere concetti contraddittori in diverse rappresentazione della
stessa descrizione.

Comprensibilità
– La descrizione deve essere facilmente comprensibile da parte di chi la deve interpretare.

Formalità
– Rigore con cui sono definite la sintassi e la semantica del linguaggio.

Stile
– Quale aspetto del sistema è più facile descrivere utilizzando il linguaggio (comportamento o
proprietà)
Unified Modeling Language
14
© 2005 - CEFRIEL
Grado di formalità

Informale: tipicamente linguaggio corrente (italiano, inglese)
– Spesso usato perché è usabile con poco sforzo
– Può dar luogo ad ambiguità

Semi-formale (ha sintassi ma poca semantica)
– Facilmente comprensibile, ma possibile fonte di ambiguità

Formale (ha sia sintassi sia semantica rigorosa)
– Ha fondamenti logico-matematici: elimina ambiguità
– Consente di ragionare su e verificare proprietà, anche con strumenti (semi)automatici che
supportano quel linguaggio
– N.B. Non tutte le proprietà sono formalmente verificabili
Unified Modeling Language
15
© 2005 - CEFRIEL
Stile

Stile descrittivo: definisce le proprietà desiderate
– Es. La curva soddisfa l’equazione ax2 + by2 + c = 0.

Stile operazionale: definisce il comportamento desiderato (una “macchina”)
– Es. La curva rappresenta il cammino di un punto che si muove in modo che la somma delle sue
distanze da due punti fissati P1 e P2 rimanga costante.
Unified Modeling Language
16
© 2005 - CEFRIEL
Politecnico
di Milano
Il paradigma object-oriented
© 2005 - CEFRIEL
I concetti base del paradigma
Object-Oriented





Classi
Oggetti
Generalizzazione/specializzazione
Polimorfismo
Dynamic binding
Unified Modeling Language
18
© 2005 - CEFRIEL
Classe

Una classe definisce un insieme di possibili oggetti
È la descrizione –astratta– di una tipologia di oggetti
Automobile, felino, fenomeno atmosferico, copricapo sono possibili classi.

NB: la classe è una descrizione


– Gli oggetti che descrive sono elementi del mondo reale
– La classe esiste su un piano diverso
Unified Modeling Language
19
© 2005 - CEFRIEL
Classe: dati e comportamento



La classe descrive sia le caratteristiche statiche degli oggetti che il loro comportamento
(le operazioni in cui possono essere coinvolti)
Attributi: sono i “dati” che caratterizzano la classe
Esempio:
– La classe conto corrente avrà gli attributi: numero, titolare, saldo, ecc.


Operazioni (o “metodi”): sono le operazioni che si può chiedere agli oggetti di eseguire
Esempio:
– La classe conto corrente sarà dotata delle operazioni di versamento, prelevamento, bonifico, ecc.
Unified Modeling Language
20
© 2005 - CEFRIEL
Classi: proprietà pubbliche e private

Contenuti privati
– attributi e metodi accessibili solo dall’interno della classe

Contenuti pubblici
– attributi e metodi accessibili dall’esterno (cioè da altre classi)


Servono a realizzare l’information hiding
È desiderabile che tutti gli attributi siano privati.
– Questo rende la classe accessibile solo attraverso le operazioni pubbliche.
– Conseguenza: la altre classi sanno cosa possono fare con una classe, ma non sanno come la classe
funziona internamente
– Modularità!
– Concetto nuovo? Non proprio: noi conosciamo solo l’interfaccia pubblica della banca, del
videoregistratore, dell’automobile, …
Unified Modeling Language
21
© 2005 - CEFRIEL
Oggetto

Definizione
– Istanza di una classe
– Esemplare corrispondente alla descrizione fornita dalla classe

Ogni oggetto ha associate le proprietà descritte nella classe di cui è istanza
– Tutte le istanze della stessa classe si comportano nello stesso modo
– Ma oggetti diversi che sono istanze della stessa classe avranno valori degli attributi diversi

Esempio:
–
–
–
–
La classe Persona prevede l’attributo età
Rossi e Bianchi sono istanze di persona
Sia Rossi che Bianchi hanno dunque un’età
I valori delle età di Rossi e Bianchi possono chiaramente essere diversi
Unified Modeling Language
22
© 2005 - CEFRIEL
Oggetto

Un oggetto incapsula:
– stato = valore di attributi
– comportamento = metodi


Il comportamento dipende spesso dallo stato
Esempi
– La classe Persona comprende lo stato civile: l’operazione “matrimonio” è disponibile solo se
l’oggetto è nello stato “celibe”
– La classe Motore comprende l’operazione di accensione, che è disponibile solo se gli attributi del
motore indicano che non è guasto ed il carburante è presente.
Unified Modeling Language
23
© 2005 - CEFRIEL
La metafora di interazione



Un metodo si invoca mandando un messaggio all'oggetto
In altre parole: per stimolare un certo comportamento da parte di un oggetto, gli
mandiamo un messaggio contenente l’invocazione del metodo dell’oggetto
corrispondente al comportamento che desideriamo ottenere.
Chi manda i messaggi? Un altro oggetto. Nel modello object-oriented qualunque cosa
è un oggetto.
Prelievo
Persona
Unified Modeling Language
Conto corrente
24
© 2005 - CEFRIEL
Classi: attenzione all’astrazione


Lo scopo semantico della classe e l’astrattezza della descrizione possono portare a
situazioni apparentemente bizzare, ma perfettamente logiche.
Esempio:
–
–
–
–

Scopo semantico = bene materiale, caratterizzato dalla sua descrizione e valore
Classe Bene
La mia auto e il mio box sono istanze della stessa classe
Il cavallo e la stalla del Sig. Rossi sono istanze della stessa classe
Esempio:
– Scopo semantico = gli insegnanti
– Classe Insegnante
– Il sig. Mauro Rossi e il suo fratello genello sono istanze di classi diverse (uno è insegnante, l’altro
no).
Unified Modeling Language
25
© 2005 - CEFRIEL
Classi come insiemi



Una classe può essere vista come un insieme
Le istanze della classe appartengono all’insieme associato alla classe
Esempio
– Classe Libro
– Le istanze “Pinocchio”, “Tom Sawyer”, “Il nome della rosa” appartengono all’insieme dei libri, così
come tutte le altre istanza di Libro.
Unified Modeling Language
26
© 2005 - CEFRIEL
Identità degli oggetti


Un oggetto esiste indipendentemente dal suo valore.
Esistono due relazioni di equivalenza sugli oggetti:
– identità (due oggetti sono in realtà il medesimo oggetto)
– uguaglianza (due oggetti hanno lo stesso valore)

Se l'oggetto é complesso l'uguaglianza può essere "deep" o "shallow".
Unified Modeling Language
28
© 2005 - CEFRIEL
Identità degli oggetti - condivisione


Esempio: una persona ha un nome, un età e un insieme di figli.
Carlo e Maria hanno entrambi un figlio di 15 anni di nome Luca. Sono possibili due
situazioni:
– Luca é il figlio di Carlo e Maria
– Ci sono due persone di nome Luca di 15 anni, uno figlio di Carlo e uno di Maria

Un sistema basato sull'identità rappresenta in modo naturale entrambe le situazioni:
Carlo
Maria
Luca
Unified Modeling Language
29
Carlo
Maria
Luca
Luca
© 2005 - CEFRIEL
Generalizzazione




È una relazione tra classi (cioè tra descrizioni)
Rappresenta il ben noto concetto di generalizzazione (o specializzazione se visto nel
senso inverso)
Una classe A è una generalizzazione di una sottoclasse B se la tipologia rapprersentata
da A comprende come caso particolare (specializzazione) la tipologia B.
Esempi
– La classe Studente è una specializzazione della classe Persona
– La classe Primate è una specializzazione della classe Mammifero, che a sua volta è una
specializzazione della classe Animale

La relazione di generalizzazione non è limitata alle classi, ma può essere usata anche tra altri tipi di descrizioni
Unified Modeling Language
31
© 2005 - CEFRIEL
Generalizzazione

Generalizzazione = relazione "is-a“ (“è un/una”)
– Ogni istanza di una classe è anche istanza di tutte le superclassi
– Fuffy è un felino. Dunque è anche un mammifero e un animale.

La generalizzazione forma una gerarchia
– Non è possibile (neanche indirettamente) che A sia una specializzazione di B e B una
specializzazione di A
Animale
Rettile
Mammifero
Primate
Felino
Unified Modeling Language
Uccello
32
© 2005 - CEFRIEL
Generalizzazione

Perché usiamo la generalizzazione nei modelli?
– Condivisione di proprietà
• Le sottoclassi hanno tutte le proprietà delle super-classi
• Possono essere descritte incrementalmente
– Compatibilità
• Le sottoclassi sono compatibili con le superclassi
• Ad es. se la maestra chiede di disegnare un animale, va bene sia il disegno di un felino che di
un rettile
Unified Modeling Language
33
© 2005 - CEFRIEL
Condivisione di proprietà
Eredita le proprietà di
Figura
Aggiunge le Operazioni:
Perimetro
Area
FiguraChiusa
Poligono
Rettangolo
Unified Modeling Language
Attributi:
Colore
Operazioni:
Rotazione
Disegno
Figura
Ellisse
FiguraAperta
Eredita le proprietà di
FiguraChiusa
Aggiunge gli attributi:
Fuoco1 e Fuoco2
Eredita le proprietà di
FiguraChiusa (e quindi
anche di Figura)
Aggiunge l’attributo:
NumeroLati
34
© 2005 - CEFRIEL
Quando usare la generalizzazione?



Quando esistono classi “simili” (cioè che condividono un insieme di proprietà) che –
rispetto agli scopi del modello– presentano differenze rilevanti.
NB: possono esistere tipologie di modelli molto diverse nel mondo reale, ma che
rispetto allo scopo semantico richiesto dal modello possono essere rappresentate
mediante un’unica classe (cioè mediante un’unica astrazione).
Regola: non creare una specializzazione se non ce n’è bisogno.
Unified Modeling Language
35
© 2005 - CEFRIEL
Polimorfismo

Conseguenza dell’esistenza di generalizzazione e della compatibilità delle sottoclassi
rispetto alle superclassi
Disegno
Il disegno “sa” di
essere composto da
figure, cui può
chiedere di ruotare o
disegnarsi.
Non sa nulla delle
possibili
specializzazioni,
salvo che saranno
compatibili
Composto_da
Figura
FiguraChiusa
Poligono
Attributi:
Colore
Operazioni:
Rotazione
Disegno
FiguraAperta
Ellisse
Rettangolo
Unified Modeling Language
36
© 2005 - CEFRIEL
Polimorfismo

Un riferimento polimorfico:
– ha un tipo statico
• Nell’esempio precedente, il disegno è composto di oggetti di tipo Figura
– ha un tipo dinamico: può riferirsi, nel corso dell'esecuzione del programma, a istanze di più di una
classe;
• Nell’esempio precedente, il disegno a un certo punto potrebbe comprendere solo un ellisse, più tardi
solo due rettangoli
Unified Modeling Language
37
© 2005 - CEFRIEL
Dynamic binding

Binding:
– Il collegamento tra il nome di una operazione e la sua implementazione

Dynamic binding:
– Un oggetto invia un messaggio a un altro oggetto, di cui ignora il tipo dinamico
– L’operazione eseguita dipende dal tipo effettivo dell’oggetto ricevente
Unified Modeling Language
38
© 2005 - CEFRIEL
Dynamic binding: esempio
Tipo statico
Rotazione
Disegno
Figura
Composto_da
FiguraChiusa
Poligono
Ellisse
Rettangolo
Unified Modeling Language
39
FiguraAperta
Se il disegno è composto
di ellissi la rotazione
eseguita è quella delle
ellissi, se il disegno
contiene rettangoli la
rotazione eseguita è
quella definita nella classe
Rettangolo, ecc.
© 2005 - CEFRIEL
Politecnico
di Milano
Unified Modeling Language
© 2005 - CEFRIEL
Unified Modeling Language




È un insieme di linguaggi che, utilizzati congiuntamente, consentono di
descrivere/modellare tutti (o quasi) gli aspetti rilevanti di un sistema, secondo con un
approccio object-oriented
Notazione grafica
Linguaggio semi-formale
Stile misto
– parzialmente dichiarativo, parzialmente operazionale

Standard OMG per la modellizzazione di sistemi Object-Oriented sin dal 1997
Unified Modeling Language
41
© 2005 - CEFRIEL
Situazione

Dove trovare informazioni costantemente aggiornate:
– http://www.rational.com
– http://www.omg.org
– internet newsgroup comp.object
2004
Unified Modeling Language
42
© 2005 - CEFRIEL
Indice

Diagrammi UML
– Class e Object Diagram
– Use Case Diagram
– Interaction Diagram
• Sequence Diagram
• Collaboration Diagram
–
–
–
–
–
Composite structure Diagram
Statechart Diagram
Activity Diagram
Component Diagram
Deployment Diagram
Unified Modeling Language
43
© 2005 - CEFRIEL
I class diagram

Forniscono una vista strutturale (statica) del sistema in termini di
– classi
• attributi
• operazioni
– relazioni tra classi (associazioni, generalizzazioni, ...)

Un class diagram rappresenta uno schema concettuale
– se una classe A è in relazione con una classe B, allora ogni istanza di A sarà in relazione con
un’istanza di B
Unified Modeling Language
44
© 2005 - CEFRIEL
Classi

Una classe descrive un gruppo di oggetti con caratteristiche comuni
– attributi
– comportamento

Gli oggetti (istanze) di una stessa classe differiscono tra loro per i valori degli attributi e
per le relazioni che li legano ad altri oggetti.
Unified Modeling Language
45
© 2005 - CEFRIEL
Notazione generale per le classi

Nel caso più generale la notazione è la seguente.
NomeClasse
nome-attributo-1: tipo-dato-1 = valore-di-default-1
nome-attributo-2: tipo-dato-2 = valore-di-default-2
....
nome-operazione-1 (lista-argomenti-1): tipo-reso-1
nome-operazione-2 (lista-argomenti-2): tipo-reso-2
....
Esempi
Persona
Nome: string
Età: int
CambiaLavoro
CambiaIndirizzo
Unified Modeling Language
File
Disegno
Nome: string
Dimensione: int
Creazione: data
Titolo: string
Altezza: int
Larghezza: int
Stampa
Stampa
Ruota(gradi: int)
46
© 2005 - CEFRIEL
Operazioni

Un operazione è una funzione o una trasformazione applicabile ad un’istanza di
una classe (ogni operazione ha come argomento implicito un oggetto obiettivo)
– La stessa operazione può essere definita in classi diverse
– Il comportamento dipende dalla classe a cui appartiene l'oggetto obiettivo
Classi con attributi e
operazioni
Persona
Nome: string
Età: int
File
Nome: string
Dimensione: int
Creazione: data
CambiaLavoro
CambiaIndirizzo
Unified Modeling Language
Stampa
47
Disegno
Titolo: string
Altezza: int
Larghezza: int
Stampa
Ruota(gradi: int)
© 2005 - CEFRIEL
Relazioni in UML

In un Class Diagram vengono rappresentate relazioni oltre alle classi:
–
–
–
–
Associazioni (semplici, aggregazioni, composizioni)
Relazioni di generalizzazione
Relazioni di dipendenza
Relazioni di raffinamento
Unified Modeling Language
48
© 2005 - CEFRIEL
Associazioni

Una Associazione individua una “connessione” logica tra classi
– Il significato della relazione è specificato solo attraverso l’etichetta dell’associazione
– si traduce in una connessione fra oggetti istanze delle classi coinvolte nell’associazione
Nome (opzionale)
dell'associazione
Città
CapoluogoDi
Nome: string
Regione
Nome: string
Nota: una associazione è naturalmente bidirezionale.
Unified Modeling Language
49
© 2005 - CEFRIEL
Cardinalità nelle associazioni


Indica il numero di istanze di una classe che possono essere associate ad una singola
istanza dell’altra classe
Può non essere specificata ad uno degli estremi (“association-end”) o a entrambi
– E in questo caso non significa cardinalità pari a 1!
Unified Modeling Language
50
© 2005 - CEFRIEL
Cardinalità delle associazioni
P1
P2
Mondo reale
Px
P6
P3
P5
P4
Indicazione (opzionale) di molteplicità
Poligono
Unified Modeling Language
0..* Derfinito_da
3..*
Punto
51
© 2005 - CEFRIEL
Notazione per la cardinalità
Persona
Possiede
Nome: string


0..*
Auto
Modello: string
Nota: Il class diagram indica che una persona può possedere un numero qualsiasi di auto
Quanti sono i proprietari di una singola auto?
– Il diagramma non fornisce questa informazione, dato che la cardinalità della partecipazione di Persona
all’associazione risulta non specificata!
– Inoltre, dato che l’associazione è navigabile in una sola direzione, data un’auto non è mai possibile risalire ai
suoi (o al suo) proprietario
Unified Modeling Language
52
© 2005 - CEFRIEL
Ruoli nelle associazioni

Una classe può partecipare ad un’associazione con un ruolo specifico, che può essere
indicato
1..*
Persona
Lavora per
Impiegato
0..1
DatoreDiLavoro
Azienda
Il ruolo (opzionale)
Unified Modeling Language
53
© 2005 - CEFRIEL
Attributi delle associazioni
(Association Class)

In molti casi alcune proprietà sono proprie dell'associazione piuttosto che delle classi
coinvolte.
1..*
1..*
Studente
Corso
Frequenza
anno_accademico
profitto
Questa è la notazione per indicare
che una associazione possiede
alcuni attributi
Unified Modeling Language
Non si tratta di attributi dello studente
perché cambiano da corso a corso.
Nè sono attributi del corso (ad es. ogni
corso è frequentato da studenti diversi in
anni diversi)
54
© 2005 - CEFRIEL
Associazioni esclusive

Talvolta un’associazione può esistere verso una classe o verso un’altra (non verso
entrambe)
Persona
Partita IVA
{xor}
Azienda
Unified Modeling Language
55
© 2005 - CEFRIEL
Diagrammi delle Istanze
(Object Diagram)


Descrivono singole istanze di classi (oggetti) e associazioni (links) rappresentate in un
particolare class diagram
Adatti a descrivere esempi o situazioni specifiche (punti di vista o “fotografie” delle
istanze esistenti in un certo istante di tempo)
Unified Modeling Language
56
© 2005 - CEFRIEL
Oggetti: Notazione grafica

Scopo delle istanze è solitamente di fornire degli esempi di oggetti, oppure evidenziare
oggetti di particolare rilevanza.
Classe
Order
Istanze
: Order
MyOrder: Order
Unified Modeling Language
57
MyOrder: Order
number=0
amount=10000
© 2005 - CEFRIEL
Link e Object Diagram



Un legame (link) è una connessione fisica o concettuale fra due istanze.
Mentre un'associazione connette due classi, un link connette due oggetti.
I link sono istanze delle associazioni.
presidente
cittadino
Italia: Repubblica
Unified Modeling Language
cittadino
58
C.A.Ciampi: Persona
Dario Fo: Persona
© 2005 - CEFRIEL
Object diagram: Esempio
P1
P2
Mondo reale
P6
P3
P5
P4
P1: Punto
Diagramma degli oggetti
P2: Punto
P3: Punto
Pol: Poligono
P4: Punto
P5: Punto
P6: Punto
Unified Modeling Language
59
© 2005 - CEFRIEL
Aggregazione

È un caso particolare di associazione molto comune che significa: “è un insieme di".
Il rombo “vuoto” si legge "è un insieme di"
3..*
Poligono
Punto
Essendo un tipo
particolare di
associazione è
sempre possibile
specificare la
cardinalità
Modello equivalente che usa una associazione convenzionale:
Poligono
Unified Modeling Language
InsiemeDi
60
3..*
Punto
© 2005 - CEFRIEL
Composizione

È un caso particolare di aggregazione che significa: “è composto da".
– i componenti non possono esistere senza il contenitore
– la proprietà da parte del contenente è esclusiva
• Quindi la molteplicità dal lato dell’aggregato non può essere >1
• Può essere qualsiasi per gli elementi componenti
PC
1..*
0..1
Monitor
1..4
HardDisk
Unified Modeling Language
UnitàBase
1..2
CD
Mouse
Tastiera
1..2
1..3
ModuloRAM
61
CPU
0..1
Coprocessore
© 2005 - CEFRIEL
Relazioni di aggregazione:
Semantica
Avanzato
Dipendenza delle parti
dall’oggetto composito
dipendente
esclusiva
1
indipendente
0..1
Proprietà
?
condivisa
?

1..*
*
+ semantica di propagazione delle operazioni
definita dall’utente (necessaria)
Varianti
1
esclusiva, dipendente, ma assenza di
operazioni
Unified Modeling Language
62
propagazione delle
© 2005 - CEFRIEL
Associazioni riflessive

Una associazione o aggregazione si dice riflessiva ( o ricorsiva) se coinvolge oggetti
della stessa classe
– una associazione ricorsiva indica che più oggetti della stessa classe interagiscono e collaborano
in qualche modo
Corso
0..*
0..*
precedenza
Unified Modeling Language
63
© 2005 - CEFRIEL
Generalizzazione
StessoAutore
0..*
Documento è una generalizzazione
di Libro e di File
Documento
Titolo
Attributi, operazioni e associazioni
vengono ereditati dalle sottoclassi
{simmetrica}
0..*
Copia()
generalizzazione
Libro
Numero_pagine
File
Dimensione_in_KB
File e libro sono sottoclassi
di documento
Stampa_di
Esempio di Object Diagram
TomSawyer : Libro
StessoAutore
HuckleberryFinn: Libro
Stampa_di
HF.doc: File
StessoAutore
Unified Modeling Language
64
© 2005 - CEFRIEL
Generalizzazione ed ereditarietà:
Esempi (2)
Persona

– attributi
– metodi
- String nome
- String indirizzo
+ Persona(String nome, String ind)
+ stampa()
+ String nome()
+ String indirizzo()
La classe Studente eredita dal padre:


Un oggetto Studente può essere trattato
esattamente come un oggetto Persona
In cosa solitamente può differenziarsi la classe
erede
– aggiunta di attributi e metodi
– i metodi possono essere ridefiniti
Studente
- int matricola
- String esami[ ]
- int voti[ ]
+ Studente(String nome, String ind, int mat)
+ aggiungiEsame(String nome, int voto)
+ int mediaVoti()
Unified Modeling Language
65
© 2005 - CEFRIEL
Generalizzazione: Esempi (3)
Poligono
+ Colore colore
+ sposta(float dx, float dy)
+ ruota(Punto centro, float angolo)
+ disegna(Schermo s)
Rettangolo
Triangolo
+ float diagonale()
VeicoloCommerciale
+ int pesoCarico
+ int pesoVuoto
+ boolean articolato
Autoveicolo
Unified Modeling Language
+ String targa
+ String modello
VeicoloPrivato
+ stampaLibretto()
+ int numeroPorte
+ int numeroPosti
66
© 2005 - CEFRIEL
Significati della generalizzazione


Una sottoclasse può ridefinire alcune proprietà della superclasse
Una sottoclasse può anche ridefinire il protocollo delle operazioni
– Cioè in una sottoclasse si può ridefinire un’operazione ereditata dalla superclasse, cambiandone
anche parametri e tipo restituito
Unified Modeling Language
67
© 2005 - CEFRIEL
Uso della delega (delegation)


Devo definire la classe pila (col solito significato)
Dispongo di una classe Sequenza, che vorrei riutilizzare
Pila
Sequenza
- content
insert(pos:int, x:item)
delete(pos:int)
push(x:item)
pop(): item
Sequenza
insert(pos:int, x:item)
delete(pos:int)
Pila
push(x:item)
pop(): item
Unified Modeling Language
così la pila erediterebbe
la possibilità di inserire
e togliere elementi da così la pila contiene
qualunque posizione (tipicamente nella
parte privata) una
sequenza di elementi
68
© 2005 - CEFRIEL
Classi astratte


Una classe astratta è una classe che non può essere direttamente istanziata
Può (anzi deve) avere delle sottoclassi concrete
– e queste possono essere istanziate (se non sono astratte a loro volta)
Figura
{abstract}
Classi
astratte
Poligono
{abstract}
Cerchio
Classi
concrete
Quadrato
Triangolo
Unified Modeling Language
Notazione
alternativa:
nome della
classe in corsivo
69
© 2005 - CEFRIEL
Classi astratte (2)

Il termine “astratto” viene anche utilizzato per per descrivere una operazione per la
quale non è stata definita una implementazione
– Le operazioni astratte di una classe si rappresentano scrivendo il nome in corsivo

Una classe astratta può avere operazioni concrete
– Almeno una operazione deve essere astratta

Tipicamente vengono usate
– per mettere a fattor comune un'astrazione di un certo tipo
– per favorire il riuso
Unified Modeling Language
70
© 2005 - CEFRIEL
Classi astratte: Esempio

Il disegno è composto di figure. Non importa come sono fatte. Il disegno sa solo che per disegnare
(draw) se stesso può chiamare il metodo draw delle figure.
– Aggiungendo una sottoclasse a figura il codice di gestione dei disegni non cambia!
1..*
Figura
+figuraPart #Position : Pos
1..* +draw()
Gruppo_Figure
1
Unified Modeling Language
Poligono
1
71
Disegno
+draw()
Linea
+lineaPart 3..*
© 2005 - CEFRIEL
Eredità multipla
Veicolo
{superficie}
{propulsione}
Veicolo
Terrestre
Veicoloa
SpintaUmana
Auto
Bicicletta
VeicoloTerrestre e
VeicoloaSpintaUmana
sono sottoclassi non
disgiunte di Veicolo
BarcaaRemi
Bicicletta eredita sia da
VeicoloTerrestre, sia da
VeicoloaSpintaUmana
Unified Modeling Language
72
© 2005 - CEFRIEL
La delega
La delega consiste nel "delegare" una entità apposita (es. RapportoDiLavoro) a
svolgere particolari operazioni.
Persona
Lavoratore
Dipendete
Persona
Rapporto
DiLavoro
Lavoratore
Autonomo
Lavoro
Dipendete
Dipendete
ConPartitaIva
Con delega (eredità semplice)
Senza delega (eredità multipla)
Unified Modeling Language
Lavoro
Autonomo
73
© 2005 - CEFRIEL
Vincoli relativi sulle associazioni
dipendente
0..*
Persona
impiegato
1..*
datore di
lavoro
0..1
0..1
Azienda
capo
0..1
Persona.datore_di_lavoro =
Persona.capo.datore_di_lavoro
Nota: in generale, i diagrammi consentono più gradi di libertà di
quanti se ne vogliano effettivamente lasciare.
Per introdurre vincoli e restrizioni bisogna ricorrere a una notazione
testuale.
OCL (Object constraint Language) fa questo in modo formale (è un
linguaggio logico).
Unified Modeling Language
74
© 2005 - CEFRIEL
Dipendenza

Relazione che indica una dipendenza di varia natura tra elementi di un modello UML
– Si può avere dipendenza tra classi, packages, use cases, etc.

Individua una connessione “semantica” tra due elementi, uno dei quali è dipendente
dall’altro
– Una modifica nell’elemento indipendente ha effetti su quello dipendente
Unified Modeling Language
75
© 2005 - CEFRIEL
Dipendenza: Esempio
Classe D
Classe B
Classe A
<<instantiates>>
<<calls>>
Unified Modeling Language
operationZ()
Classe C
76
© 2005 - CEFRIEL
Costrutti di raggruppamento

Modulo: raggruppa classi, associazioni e generalizzazioni
– fornisce una vista del problema
– diminuisce la complessità del problema

La suddivisione in moduli può essere fatta in diversi modi.
– Criterio: forte coesione, scarse connessioni
Unified Modeling Language
77
© 2005 - CEFRIEL
Packages



Forniscono un costrutto di raggruppamento per gli elementi definiti in un modello UML
A volte si utilizza il termine subsystem per indicare un package
È possibile definire delle relazioni (tipicamente di dipendenza, raffinamento, generalizzazione) tra
packages diversi
A
A
B
A1
A2
B1
B
Unified Modeling Language
78
© 2005 - CEFRIEL
Use Case Diagram

È una tipica interazione tra l’utente e il sistema informatico.
– Esempi per un word processor:
• sottolinea una parte di testo
• crea un indice

Quindi, uno use case
–
–
–
–

rappresenta una funzione visibile dall’utente
rappresenta un obiettivo specifico (atomico) per l’utente
può essere di “dimensioni” diverse
Descrive
• Il sistema
• L’ambiente
• Le relazioni fra sistema e ambiente
Ogni caso di utilizzo identificato
– È etichettato con un nome
– Viene descritto graficamente
– Viene descritto con del testo (la notazione grafica non basta)
Unified Modeling Language
83
© 2005 - CEFRIEL
Use Case:
Elementi caratteristici


Uno Use case consente di individuare il comportamento (in termini di funzionalità
offerte) di un sistema o di una qualsiasi altra entità definita nel sistema senza entrare
nel dettaglio della struttura interna dell’entità
Uno Use Case individua una tipologia di possibili utilizzi del sistema (descritti
testualmente)
Unified Modeling Language
84
© 2005 - CEFRIEL
Use case diagram
Use case
<<include>>
Actor
Unified Modeling Language
85
© 2005 - CEFRIEL
Use case diagram

Esempio: Sistema per la gestione delle vendite dei prodotti di una azienda
– Si vuole descrivere la possibilità da parte del venditore di effettuare l’evasione di un ordine
Use-Case
Acquisizione Ordine
Attore
Venditore
Confine del sistema
(non sempre indicato esplicitamente)
Unified Modeling Language
86
© 2005 - CEFRIEL
Actor (attori)

Attore = Entità esterna al sistema che interagisce con il sistema assumendo un
particolare ruolo
– non c’è necessariamente corrispondenza tra attori e individui precisi
– possono esserci diversi utenti con lo stesso ruolo, e diversi ruoli possono essere ricoperti dallo
stesso utente
– possono esserci diversi attori che esercitano lo stesso use case, e diversi use case possono essere
esercitati dallo stesso attore
– non è detto che un attore corrisponda a uno o più persone: può essere un sistema esterno
• nonostante l’icona standard utilizzata per la rappresentazione
Unified Modeling Language
87
© 2005 - CEFRIEL
Relazioni tra attori e use case
Associazione: Identifica la partecipazione di
un attore ad uno Use Case
Venditore
Immissione
Ordine
Generalizzazione: Il supervisore può
partecipare a tutti gli use case cui
partecipa il Venditore (compatibilità!)
Supervisore
Unified Modeling Language
Attribuzione
credito
88
© 2005 - CEFRIEL
Use case diagram: esempio
Cliente
Verifica stato ordine
Venditore
Acquisizione Ordine
Attribuzione credito
Addetto al magazzino
Evasione ordine
Unified Modeling Language
Supervisore
89
© 2005 - CEFRIEL
Use Case, Use Case Instances e
Scenari


Uno Use Case individua una tipologia di “storie” d’uso del sistema
Una istanza dello Use Case individua una specifica storia d’uso
– Specifica una delle possibili sequenze di azioni che possono avvenire durante lo svolgimento dello
use case

Scenario: È una istanza di use case corredata da una descrizione esplicita
– Il termine “scenario” non è usato in modo sempre consistente.
Unified Modeling Language
90
© 2005 - CEFRIEL
Scenari

Uno “scenario” individua e descrive esplicitamente una particolare istanza di uno
use case, ovvero una delle possibili varianti
– Ad es. un ordine può essere elaborato regolarmente, o può mancare la merce ordinata o può
mancare il credito nei confronti dell’ordinante, … Ciascuno di questi casi è uno scenario
specifico dello use case “gestione ordini”.


Ogni Use Case è caratterizzato da uno scenario base (sequenza tipica di eventi) e
da un numero, imprecisato a priori, di varianti
Le varianti possono essere aggiunte nei successivi raffinamenti dello use case
Unified Modeling Language
91
© 2005 - CEFRIEL
Relazioni tra Use Cases

Esistono tre tipi di relazioni possibili tra use cases:
– Generalizzazione
• Simile alla generalizzazione tra classi
– Inclusione
• Il comportamento individuato dallo use case target viene incluso nella sequenza di azioni svolta dalle
istanze dello use case base
<<include>>
– Estensione
• Le funzionalità individuate da uno use case base vengono estese, al verificarsi di opportune condizioni,
con funzionalità definite in un altro use case
<<extend>>
Unified Modeling Language
92
© 2005 - CEFRIEL
Esempio
base use case
<<extend>>
[Order created, P1 ]
Place Order
Extension Points:
P1: After order
creation
Customer
<<include>>
<<include>>
Request
Catalog
with Order
extension use case
<<include>>
SalesPerson
Supply
Customer
Data
Order
Product
Arrange
Payment
Pay
Cash
Unified Modeling Language
93
Pay by Money
Transfer
© 2005 - CEFRIEL
I requisiti non funzionali



Gli use case non sono adatti a specificare i requisiti non funzionali.
Poiché tali requisiti sono di importanza fondamentale occorre inventarsi un modo per
descriverli comunque.
UML non fornisce alcuna soluzione. Quindi solitamente si ricorre ad una specifica
testuale che viene allegata agli use case diagrams.
Unified Modeling Language
94
© 2005 - CEFRIEL


Interaction diagram e comportamento
dinamico del sistema
Sono diagrammi che descrivono come gruppi di oggetti collaborano nel mostrare un
certo comportamento.
Tipicamente rappresentano il comportamento di uno specifico use case
– in termini di specifici oggetti e messaggi scambiati

Ci sono due tipi di interaction diagram:
– Sequence diagram
– Collaboration diagram
Unified Modeling Language
95
© 2005 - CEFRIEL
Sequence diagram

Mostra una interazione tra oggetti come sequenza temporale di azioni.
– oggetti partecipanti
– sequenze (temporali) di messaggi scambiati
– non si vedono le associazioni tra oggetti
Unified Modeling Language
96
© 2005 - CEFRIEL
Sequence diagram: notazione
Oggetti
Obj2
Obj1
Obj3
Messaggi
a:do_this()
Istanti di
tempo
Vincolo
temporale
b:do_that()
{b-a < 1 sec.}
This call is routed
through the network
c
c’
Commento
Messaggio che impiega un
certo tempo per essere
ricevuto
Unified Modeling Language
Tempo
97
© 2005 - CEFRIEL
Esempio: sequence diagram
physician
waveform
controller
heart rate
parameter
physician sets up
use 4 waveforms
for patient
monitoring
setsweep
alarm
manager
alarm
display
patient
Rate=50
Rate=47
speed(25)
set bradycardia
alarm
set tachycardia
alarm
Rate=0
asystole event
physician’s
intervention
Unified Modeling Language
raise
bradycardia alarm
alarm text
Rate=45
lower
bradycardia alarm
clear alarm
98
© 2005 - CEFRIEL
Notazione estesa: terminologia
Agente
Oggetto
preesistente
Oggetto
creato da op()
“lifeline”
dell’oggetto
Oggetto
creato da foo(x)
Obj3:C3
op()
Obj1:C1
condizione,
equivale a
if (x>=0) {
Obj2=new(C2);
Obj2.foo(x);
}
else
Obj3.bar(x);
Unified Modeling Language
[x>=0] foo(x)
[x<0] bar(x)
Obj2:C2
doit(w)
99
© 2005 - CEFRIEL
Notazione estesa: terminologia
Attivazioni
Obj4:C4
Obj2:C2
Messaggi
“return”
doit(z)
doit(w)
Confluenza delle
due possibili
evoluzioni
Attivazione
ricorsiva
more()
Distruzione
dell’oggetto
Unified Modeling Language
101
Oggetto che prosegue
la sua esistenza dopo
queste interazioni
© 2005 - CEFRIEL
Collaboration diagram

Collaboration: interazione tra parti di un sistema per un certo scopo
– si isolano parti di sistema e si trascurano le interazioni non essenziali allo scopo


L’interazione è descritta in rapporto agli oggetti e alle relazioni che li legano.
Non c’è una dimensione precisa per il tempo
– le sequenze temporali sono descrivibili numerando i messaggi in modo progressivo
Unified Modeling Language
102
© 2005 - CEFRIEL
Esempio di interazione
oggetto
: OrderEntryWindow
1: prepare()
: Order
messaggio
auto-delega
ordine nella sequenza
di messaggi
5: NeedToReorder()
2*: prepare()
LineaTrenini : OrderLine
3: check()
4: [check() == true] remove()
MagazzinoTrenini : Stock
6: new
7: [check() == true] new
: DeliveryItem
Unified Modeling Language
: ReorderItem
103
© 2005 - CEFRIEL
State diagram



Rappresentano il comportamento di una classe di oggetti, descrivendone i possibili
stati e la reazione ad eventi esterni, in termini di cambiamenti di stato e/o azioni
svolte.
I diagrammi di stato danno un'astrazione di stati, eventi e transizioni
Gli stati dei diversi oggetti evolvono concettualmente in parallelo (sincronizzati dagli
eventi comuni).
Unified Modeling Language
104
© 2005 - CEFRIEL
Concetti fondamentali: stati


È l'insieme dei valori degli attributi e dei link posseduti da un oggetto in un certo
istante
Ci interessa lo stato astratto
– esempio: motore acceso/spento (non ci interessa il numero di giri/min.)
– può corrispondere a diverse - anche infinite - combinazioni di valori degli attributi

Lo stato influenza il comportamento
– L'oggetto reagisce in modo qualitativamente diverso agli eventi esterni, in funzione dello stato in
cui si trova.
– Esempio: prelievo da un conto corrente con saldo negativo
Unified Modeling Language
105
© 2005 - CEFRIEL
Concetti fondamentali: stati


Il comportamento quantitativo è influenzato dal valore degli attributi, dei link e dei
parametri delle operazioni
Uno stato perdura nel tempo
– finché un evento non fa cambiare stato all’oggetto (es. un versamento fa passare un conto corrente
da saldo negativo a saldo positivo)
Unified Modeling Language
106
© 2005 - CEFRIEL
Concetti fondamentali: eventi

Evento = stimolo esterno
– E' istantaneo
• il tempo è un attributo implicito
– Se due eventi sono legati da relazione causa/effetto sono ordinati nel tempo.
– Può causare nell'oggetto destinatario un cambio di valore, di stato o la produzione di ulteriori
eventi.
– Si intende che un evento ha una individualità ben definita
• raggruppabili in classi di eventi (con attributi caratterizzanti)
– La risposta ad uno stimolo dipende dallo stato, e può implicare una transizione di stato
• esempio del versamento su CC
Unified Modeling Language
107
© 2005 - CEFRIEL
Diagramma degli stati: Esempio
Chiamante.Aggancia
Inattivo
Chiamante.Aggancia
Chiamante.Sgancia
T
Tono
Tono
Pronto
TimeOut
Compone(n)
Compone(n)
Compos.
Numero
Tono
Occupato
Connesso
Unified Modeling Language
Occupato
T
NumNonValido Messaggio
Vocale
NumValido
ProntoA
Connettere
Instradato
Tono
Libero
Ricevente.Sgancia
108
© 2005 - CEFRIEL
Stati iniziali e finali

Alcuni oggetti hanno diagrammi degli stati ciclici, altri possono avere stati iniziali e/o
finali.
Inizio
AlBianco
Muovere
Mossa
Bianca
VinceIlNero
Stallo or Accordo
Mossa
Nera
AlNero
Muovere
Unified Modeling Language
Matto or Abbandono
Stallo or Accordo
Matto or Abbandono
109
Patta
VinceIlBianco
© 2005 - CEFRIEL
Condizioni



Sono funzioni booleane sui valori degli oggetti.
Sono valide in un intervallo di tempo
Sono utili come guardie delle transizioni di stato (non basta l'evento, deve essere verificata la
condizione).
Condizione
Evento
Pronto
Unified Modeling Language
Verde [incrocio.stato=libero]
110
InCorsa
© 2005 - CEFRIEL
Operazioni

Durante la loro vita gli oggetti eseguono operazioni.
– associate allo stato (attività)
– associate alle alle transizioni (azioni)

Le attività hanno una durata
– continue
– sequenziali

Le azioni sono istantanee
Unified Modeling Language
111
© 2005 - CEFRIEL
Operazioni

Azioni
– Sono operazioni che hanno durata istantanea (rispetto alla granularità del tempo). Tipicamente produzione
di eventi.
– Sono associate alle transizioni di stato oppure all'ingresso o all'uscita da uno stato.

Attività
– Sono operazioni con durata significativa.
– Sono associate ad uno stato
• Continue o sequenziali

Transizioni automatiche
– Se uno stato ha una attività associata e una freccia senza eventi esce da questo, la freccia indica la transizione
svolta automaticamente al completamento della attività.
Unified Modeling Language
112
© 2005 - CEFRIEL
Notazione generale
In caso di
ricezione
dell'evento1
nello stato A
viene eseguito
azione3 senza
cambio di
stato (e quindi
senza azioni di
entry ed exit)
StatoA
do: attività1
entry / azione1
exit / azione2
event1 / azione3
event2 / azione4
Transizione automatica
(evento scatenante
fine della attività1)
Unified Modeling Language
Transizione causata
dall'evento evento3 sotto
condizione condizione1.
Vengono eseguite azione2 e
azione5
event3 [condizione1] / azione5
event4 [condizione2] / azione6
Pseudo transizione causata dall'evento evento4
nell'ordine vengono eseguiti: azione2, azione6,
azione1
113
© 2005 - CEFRIEL
Azioni consistenti nell'invio di
eventi

Molto spesso le azioni consistono nell'inviare un evento ad un altro oggetto.
– esempio: transazione tra stati di un oggetto Window
right-mouse-down(location) [location in window] /
object:=pick-object(location); object.highlight()
One object
selected
No object
selected
invio di messaggio a object
Unified Modeling Language
114
© 2005 - CEFRIEL
Invio di eventi




Gli eventi possono avere attributi
Il destinatario può essere unico o un intero set di oggetti.
Tutti gli oggetti riceventi che riconoscono l'evento possono accettarlo e reagire in
parallelo.
Attenzione alle corse critiche
Unified Modeling Language
115
© 2005 - CEFRIEL
Invio di eventi: notazione grafica
Il segnale accende o spegne
Il VCR a seconda dello stato
corrente
“power” button
/VCR.togglePower
“power” button
/television.togglePower
Unified Modeling Language
116
© 2005 - CEFRIEL
Problemi dei diagrammi a stati
piatti

Diventano poco espressivi e troppo ingarbugliati al crescere delle dimensioni del
problema.
– Ad esempio, il numero di collegamenti possibili tra stati è quadratico nel numero di stati.

Soluzione: diagrammi strutturati
– la strutturazione favorisce la descrizione sintetica di sistemi complessi
• L'attività corrispondente ad uno stato può essere espansa in un diagramma a stati di più basso livello,
dove ogni stato rappresenta una fase dell'attività.
• Generalizzazione (specializzazione delle attività, gerarchie di ereditarietà, ...)
– Aggregazione (stati concorrenti)
Unified Modeling Language
117
© 2005 - CEFRIEL
Diagrammi a stati strutturati


Uno stato strutturato equivale ad una scomposizione OR degli stati: l'oggetto si trova, all'interno di uno
stato più generale, in un qualunque sotto-stato.
I sottostati ereditano le transizioni dei loro superstati (a meno di overriding)
levaR
Folle
Questa
transizione,
risposta
all'evento
ferma, viene
ereditata da
tutti i sottostati di
MarciaAvanti
Unified Modeling Language
RetroMarcia
levaN
Cambio Automatico
levaF
levaN
MarciaAvanti
ferma
accelera
Prima
accelera
Seconda
decelera
118
Terza
decelera
© 2005 - CEFRIEL
Diagramma di stato: esempio (1)
Unified Modeling Language
119
© 2005 - CEFRIEL
Sottostati concorrenti
Unified Modeling Language
120
© 2005 - CEFRIEL
Concorrenza di due attività
Distratto
Naturalmente
Attento
do: appunti
noia
do: sbadiglia
richiamo
do: gratta
richiamo
Sincronizzazione
Transazione complessa
Unified Modeling Language
Forzatamente
Attento
do: ghirigori
121
© 2005 - CEFRIEL
Activity Graph e Activity Diagram

Sono dei casi speciali di macchine a stati, in cui
– tutti gli stati (o quasi) contengono un’azione o una attività
– tutte le transizioni (o quasi) sono causate dal completamento delle azioni/attività negli stati



Un activity graph è associato ad una classe, o all'implementazione di un’operazione, o
ad uno use case.
Un Activity Diagram è un diagramma contenente un activity graph
Lo scopo deglio activity graph è di evidenziare l’evoluzione guidata dall’elaborazione
interna, in contrapposizione agli eventi esterni (meglio trattati negli state diagram).
Unified Modeling Language
122
© 2005 - CEFRIEL
[ non c'è caffè ]
Scegli
bevanda
[ c'è il caffè ]
[ C'è la Coca Cola ]
Riempi serbatoio
con acqua
Riempi filtro
con caffè
Prendi
tazze
Un Activity
Graph
Inserisci filtro in
macchina caffè
Prendi lattina
di Coca cola
Accendi
macchina caffè
^macchinaCaffe.accendi
Prepara
caffè
Luce macchina caffè accesa
Versa caffè
Unified Modeling Language
Bevi
123
© 2005 - CEFRIEL
Swimlanes (corsie)
oggetti
responsabili di
azioni
oggetto in ingresso
o in uscita da
un’azione
Customer
Request
product
Sales
Order
[in progress]
Order
[forwarded]
Process
order
Pay bill
Bill
[paid]
Find
product
Bill
[unpaid]
Order
[delivered]
azioni
Receive
order
Unified Modeling Language
Warehouse
Ship
product
124
Order
[completed]
stati
degli
oggetti
© 2005 - CEFRIEL
Implementation diagram

Component diagram
– mostrano la struttura del codice

Deployment diagram
– mostrano la struttura del sistema run-time
Unified Modeling Language
125
© 2005 - CEFRIEL
Component diagram

Mostra le dipendenze tra componenti software
– sorgenti, binari, eseguibili
– esistenti a compile-time, a link-time, a run-time

I moduli sono rappresentati come tipi di componenti
– le istanze si vedono nei deployment diagram

I diversi componenti offrono e usano interfacce specifiche
– Primo passo verso Component Programming
Unified Modeling Language
126
© 2005 - CEFRIEL
Componenti
spell-check
dictionary
synonyms
+RoutingList
mailer
-MailQueue
mailer
+Mailbox
Realizes
+Mailbox
+RoutingList
-MailQueue
mailer
+Mailbox
+RoutingList
-MailQueue
Unified Modeling Language
127
© 2005 - CEFRIEL
Component diagram

Un’architettura a “layer”:
dipendenze
Unified Modeling Language
128
© 2005 - CEFRIEL
Component diagram con icone ad-hoc
hello.class
hello.java
hello.html
hello.jpg
Unified Modeling Language
129
© 2005 - CEFRIEL
Deployment diagram

Mostrano la configurazione a run-time degli elementi attivi a run-time (e dei
componenti, processi e oggetti che vi “vivono”).
– processi e/o processori



Istanze di componenti software rappresentano le manifestazioni run-time delle unità di
codice.
Componenti che non esistono a run-time non appaiono in questi diagrammi.
I legami fra processi possono essere
– Connettori passivi
• Generici
• Specializzati con opportuni commenti
– Connettori attivi
• Modellati con opportuni processi
Unified Modeling Language
130
© 2005 - CEFRIEL
Associazioni

Rappresentano le connessioni fisiche tra i nodi
Client1
Server
Client2
Unified Modeling Language
131
© 2005 - CEFRIEL
Nodi e componenti

Un grafo
– nodi = risorsa computazionale
Server: Host
<<database>>
Meetings
• possono contenere istanze di
componenti e/o oggetti
– archi = comunicazione
:scheduler
reservations
• tipicamente indicano una
relazione di utilizzo
myPC: PC
:planner
Unified Modeling Language
132
© 2005 - CEFRIEL
Nodi e componenti
Server: Host
Mirror: Host
:scheduler
reservations
:scheduler
<<tcp/ip>>
<<tcp/ip>>
myPC: PC
<<tcp/ip>>
:planner
Unified Modeling Language
133
© 2005 - CEFRIEL
Dove trovare altre informazioni


Esistono diverse collezioni di link a siti web contenenti informazioni su strumenti e
prodotti vari.
www.cetus-links.org
– una collezione estesa di riferimenti a siti sull’analisi e progettazione OO (non necessariamente
UML).
Unified Modeling Language
134
© 2005 - CEFRIEL
Bibliografia: Libri





Terry Quatrani, Visual Modeling with Rational Rose and UML, Addison-Wesley
Unified Modeling Language User Guide
Unified Modeling Language Reference Manual
H. Eriksson, M. Penker, UML Toolkit, J. Wiley
M. Fowler, UML distilled, Addison-Wesley
Unified Modeling Language
135
© 2005 - CEFRIEL
Bibliografia: URL

Rational/IBM
– http://www-306.ibm.com/software/rational/

Object Management Group
– http://www.omg.org
Unified Modeling Language
136
© 2005 - CEFRIEL