Class diagrams

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
1
Class - names
name
Una class può essere rappresentata
anche usano solo la sezione del nome
Libro
cod_libro
attributes
titolo
Libro
data edizione
ISDN
data acquisizione
richiesta( )
restituzione( )
create( )
Un nome può essere un:
• simple name , il solo nome della class
• path name , il nome della class preceduto dal
nome del package in cui la classe è posta
Magazzino::Cliente
operations
Libro
Graphics::Rettangolo
Cliente
simple names
path names
2
1
Class - Attributes
Attributes
Una classe può avere un qualsiasi numero di attributi, o nessuno
Per ciascun attributo si può specificare il tipo ed un eventuale
valore iniziale
tipicamente il nome di un attributo è composto da una parola o più
parole insieme, usare il maiuscolo per la prima lettera di ciascuna
parola lasciando minuscola la lettera iniziale del nome
Scaffale
altezza: Float
larghezza: Float
profondità: Float
numeroScansie: Int
èPieno: Boolean=false
3
Class - Operations
Operations
Una classe può avere un qualsiasi numero di operations, o nessuna
Per ciascun operation si può specificare il solo nome o la sua
signature, indicando il nome, il tipo, parametri e, in caso di funzione,
il tipo ritornato
stesse convenzioni dette per attributes per l’uso di minuscolo e
maiuscolo per i nomi delle operations
SensoreTemperatura
reset()
setAlarm(t:Temperatura)
leggiVal():Temperatura
4
2
Class - Attributes e Operations
Attributes e Operations di una class non devono
obbligatoriamente essere descritti tutti subito
Attributi ed operations possono essere mostrati
solo parzialmente, elidendo la class
Una sezione vuota non indica necessariamente che
non esistono attributes/operations
Agente Finanziario
…….
<<costruttore>>
new()
new(p: Polizza)
…….
<<query>>
èSolvibile(o:Ordine)
Per indicare che esistono più attributes/operations
di quelli mostrati usare i punti sospensivi “ …….”
èEmesso(o:Ordine)
Per meglio organizzare lunghe liste di
attributes/operations raggrupparli insieme in
categorie usando stereotypes
5
Visibility
E’ possibile specificare la visibiltà di attributes e operations
La visibilità di un elemento specifica se esso può essere usato da altri.
In UML è possibile specificare tre livelli di visibilità
- public: qualsiasi altro classifier con visibilità al dato classifier può
usare l’elemento; è utilizzato il simbolo + (è il default se
nessun simbolo è indicato)
- protected: qualsiasi discendente del classifier può usare l’elemento; è
usato il simbolo #
- private: solamente il classifier stesso può usare l’elemento ; è usato il
simbolo Libro
Visibility per attributes ed
operations di una class
+ cod_libro
+ titolo
# data edizione
ISDN
#richiesta( )
restituzione( )
+ create( )
6
3
Multiplicity
La multiplicity è usata per indicare il numero di istanze di una classe;
una multiplicity pari a zero indicherà una classe astratta, una
multiplicity pari ad uno una singleton class; per default è assunta una
multiplicity maggiore di uno.
La multiplicity di una class è indicata con un numero intero posto
nell’angolo in alto a destra del simbolo della class
La multiplicity si applica anche agli attributi, indicandola tra […]
NetworkController
1
consolePort [2..*]: Port
ControlRod
4
7
Class - Attributes e Operations
La sintassi completa per specificare un attribute in UML è:
[visibility] name [ [multiplicity] ] [: type] [= inital-value]
[{property-string}]
dove property-string può assumere uno dei seguenti 3 valori:
changeable nessuna limitazione per la modifica del valore dello
attribute
addOnly per attributi con molteplicità maggiore di 1 possono
essere aggiunti ulteriori valori, ma una volta creato un
valore non può essere né rimosso né modificato
frozen il valore non può essere modificato dopo la sua
inizializzazione
8
4
Class - Attributes e Operations
La sintassi completa per specificare un operation in UML è:
[visibility] name [(parameter-list)] [:return-type] [{propertystring}]
con la lista dei parametri avente questa sintassi
[direction] name: type [=default-value]
dove direction può assumere uno dei seguenti 3 valori:
in
parametro di input
out
parametro di output
inout
parametro di input/output
9
Class - Attributes e Operations
property-string può assumere uno dei seguenti valori
isQuery
l’esecuzione dell’operazione lascia lo stato del sistema immutato
sequential i chiamanti devono coordinare l’oggetto dall’esterno in modo che vi
sia un sol flusso per volta verso l’oggetto; in presenza di più flussi di
controllo, non è garantita la semantica e l’integrità dell’oggetto
guarded
la semantica e l’integrità dell’oggetto è garantita in presenza di flussi
di controllo multipli dalla sequenzializzazione di tutte le chiamate a
tutte le operation guarded dell’oggetto;
concurrent la semantica e l’integrità dell’oggetto è garantita in presenza di flussi
di controllo multipli trattando la operation come atomica. Chiamate
multiple da flussi di controllo concorrente possono presentarsi
contemporaneamente ad un oggetto o ad una sua operation
concurrent ed essere eseguite correttamente con corretta semantica
Le ultime tre proprità riguardano la concorrenza di una operation
Sono rilevanti solo in presenza di oggetti attivi, processi o threads
10
5
Class Abstract, root, leaf e polymorphic elements
Le classi astratte sono indicate ponendo il nome in corsivo
• Per specificare che una class non può avere :
- discendenti indicare la proprietà leaf sotto il suo name
- avi indicare la proprietà root sotto il suo name
• Per indicare una operation astratta scrivere il suo nome in corsivo
• Una operazione con la stessa signature in più classi di una gerarchia
di generalizzazione/specializzazione è polimorphic
ClassA
{root}
ClassC
ClassB
{leaf}
11
Relationships
Una relationship è una connessione tra things.
Dependency
relazione semantica tra due things in cui un cambiamento su una
(quella indipendente) può influenzare la semantica dell’altra
(quella dipendente), ma non necessariamente anche l’inverso.
12
6
Relationships
La freccia punta verso la thing indipendente
Una dependency indica un uso di una thing da parte di un’altra (ciò
spesso è mostrato dall’indicazione in una signature di una operation
di un argomento dell’altra class)
Una relationship può avere un nome
UML defisce 17 stereotypes (organizzati in 6 gruppi) per che
possono essre applicati a dependency
VideoRegistratore
name
playOn(c:Channel)
start()
stop()
reset()
Channel
13
Dipendenza tra classi
Esempi di dipendenza tra classi C1 e C2:
• Un metodo di C1 ha come parametro un oggetto di
classe C2
• Un metodo di C1 restituisce come risultato un oggetto
di classe C2
• Un metodo di C1 istanzia un oggetto di classe C2
• Un metodo di C1 invia un messaggio ad un oggetto di
classe C2 di cui possiede il riferimento
14
7
Dipendenza tra classi
<<instantiates>>
Un metodo di una classe crea istanze di un’altra classe
<<calls>>
Un metodo di una classe chiama un metodo di un’altra classe
<<friend>>
Indica la possibilità di accesso al contenuto di un’altra classe
indipendentemente dalla visibilità prevista dalla classe target
<<usage>>
Indica che un elemento richiede la presenza di un altro per il suo corretto
funzionamento (comprende <<calls>>, <<instantiates>>)
15
Relationships
Generalization
relazione di generalizzazione/specializzazione, in cui oggetti
dell’elemento specializzato (figlio) sono sostituibili all’oggetto
generalizzato (genitore). I figli condividono la struttura ed il
comportamento del genitore.
la freccia punta al genitore
Una class può avere zero, uno o più genitori; se non ha genitori è detta
root class, se ha un solo genitore è detta a singola ereditarietà, se ha
più genitori è detta ad ereditarietà multipla
16
8
Relationships
Generalization
UML definisce 4 constraints per la Generalization:
complete : tutte le sottoclassi sono state specificate, nessun altra
sottoclasse è permessa
incomplete : non tutte le sottoclassi sono state specificate, altre
sottoclassi sono permesse
disjoint : oggetti del genitore possono avere non più di un figlio come
tipo
overlapping : oggetti del genitore possono avere più di un figlio
come tipo
17
Forma
{root}
.............
.............
display()
Rettangolo
{leaf}
.............
.............
Ellisse
.............
.............
Poligono
.............
.............
display()
Circonferenza
{leaf}
18
9
Relationships
Association
relazione strutturale che descrive un insieme di link, cioè
connessioni tra oggetti. Un particolare tipo di associazione è
l’aggregazione tra un tutto e le sue parti.
Multiplicity
Ditta
1
datoreLavoro
1..*
Persona
impiegato
Role name
Una association può avere un name ed una name direction
name
name direction
Ditta
Lavora per
Persona
19
Cardinalità
• 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!
20
10
Cardinalità
21
Associazioni n-arie
Alcune associazioni con cardinalità maggiore di due non sono
riducibili a semplici associazioni binarie.
22
11
Ruoli nelle associazioni
• Una classe può partecipare ad un’associazione con
un ruolo specifico, che può essere indicato
23
Relationships
Aggregation
Un particolare tipo di association è la aggregation che indica una
relazione ‘tutto-parti’
Ditta
Tutto
1
aggregation
Parte
*
Dipartimento
24
12
Relationships
Compositon
Un particolare tipo di aggregation è la compositon che indica una
relazione una stretta relazione ‘tutto-parti, nel senso che ciascuna
parte ha la stessa durata di vita del tutto (cioè una parte una volta
creata vive per tutto e solo il tempo del Tutto cui appartiene). Ciò
significa anche che una parte può appartenere ad un solo tutto per
volta.
Finestra
Tutto
1
composition
Parte
*
Anta
25
Relationships
Association qualifier
Una association può avere un qualifier , cioè un attributo (o
insieme di attributi) il cui valore partiziona un insieme di oggetti
(detti targets) associati ad un altro oggetto (detto source). Il
qualifier è attaccato alla source class di una association e
determina come gli oggetti della class target sono partizionati e
identificati
Definisce la ‘regola’ con cui associare gli oggetti nella relazione
qualifier
Dipartimento
nomeDip
Professore
26
13
Relationships
Association interface specifier
Una association può avere un interface specifier , per specificare
quale parte dell’interfaccia di una classe è mostrata da questa, in una
association, nei confronti di un’altra classe della stessa association.
intefafce spcifier
*
worker : IEmployee
Persona
1
supervisor: IManager
Persona nel ruolo di supervisor presenta solo la ‘faccia’ IManager al
worker; Persona nel ruolo di worker presenta solo la ‘faccia’
IEmployee al supervisor.
E’ utilizzata una notazione esplicita del tipo di ruolo usando la
sintassi:
rolename : iname
27
Relationships
Association class
Una association può essere caratterizzata da una association class ,
ovvero un gruppo di cartteristiche appartenenti alla relazione e che
non sono proprie di nessuna classe coinvolta in questa.
Ditta
1
datoreLavoro
1..*
Persona
impiegato
Lavoro
descrizione
association class
dataAssunzione
salario
Possono essere viste come association con proprietà di class o
class con proprietà di association
28
14
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
29
Relationships
Realization
Una association può essere una realization , ovvero una relationship
tra elementi in cui uno specifica un contratto che l’altro garantisce di
compiere.
E’ un incrocio tra dependency e generalization; usata principalmente
in due circostanze: contesto delle interface e delle collaboration.
la freccia punta al classifier che definisce il contratto
<<interface>>
IruleAgent
addRule()
changeRule()
explainAction()
RegolamentazioneConto
realization
30
15
Interfaccia (Definizione)
Specifica il comportamento di una classe senza darne
l’implementazione
31
Interfaccia (Uso)
32
16
Class diagrams
• Un class diagram rappresenta un insieme di class, interface,
collaboration e le loro relationship
• specifica, mediante le association, i vincoli che legano tra loro le
classi e le dipendenze tra queste
• modellano la vista di statica di un sistema, che supporta
principalmente i requisiti funzionali del sistema
• se includono active class descrivono la vista statica di un processo
di un sistema
33
Class diagrams
Un class diagram è tipicamente usato per modellare:
• il dominio del sistema
• il glossario di un sistema
sono prese decisioni relativamente alle astrazioni da
considerare
• lo schema concettuale di un database
Un class diagram possiede un nome significativo che ‘comunica’ il
suo scopo, può contenere note e costraints, package o subsystem.
34
17
Class diagrams
Libro
cod_libro
titolo
data edizione
ISDN
data acquisizione
pubblicato da
1
0..*
relationship
Editore
ragione sociale
nome breve
indirizzo sede
telefono
variazione dati editore( )
richiesta( )
restituzione( )
create( )
1..*
scritto da
0..*
0..*
Libro antico
valore
Autore
nome : type = initval
cognome : type = initval
anno nascita
anno morte
variazione anagrafica( )
valorizza( )
0..*
Utente
variazioneanagrafica( )
generalization
(genitore- figlio)
35
Ditta
1
*
1..*
1..*
Ufficio
Dipartimento
0..1
member
Location
nome: Nome
*
*
*
1..*
1
*
indirizzo: String
telefono: Number
manager
Persona
SedeCentrale
nome: Nome
matricola: Integer
posizioneLav: String
getContactInfo()
getSchedaPersonale()
getFoto()
ContactInfo
address: String
ISecureInfo
36
18
Class diagrams
Un class diagram ben strutturato
• è incentrato sul ‘comunicare’ un solo aspetto della vista dello static design
• contiene solamente gli elementi che sono essenziali a comprendere
quell’aspetto
• fornisce dettagli consistenti con il suo livello di astrazione, con solo quegli
adornments che sono essenziali alla comprensione
• non è così minimalista da disinformare il lettore circa la reale semantica
• non possiede troppi tipi di relationships
(se si hanno relationship complicate è meglio mettere tali elementi in
un ulteriore diagramma di dettaglio)
• ha un lay out che ne facilita la lettura ed evidenzia i vari componenti
• ha un nome significativo
• possiede, eventualmente, note e colori per evidenziare aspetti particolari
37
Linee Guida per costruire un class diagram
• Obiettivo:
– identificare e caratterizzare gli elementi del modello a
oggetti e come sono in relazione tra loro
• Non cercare di mettere tutto su un solo diagramma, specie
per sistemi di grosse dimensioni
• Eventualmente disegnare un diagramma per ogni vista del
sistema
• Ogni diagramma deve avere uno scopo:
– mostrare le classi e gli oggetti che partecipano in ogni
singola collaborazione
– mostrare una tassonomia di generalizzazione
– mostrare la suddivisione delle partizioni logiche
(packages)
• E’ possibile non mostrare attributi ed operazioni delle
classi per migliorare la leggibilità del diagramma
38
19
Linee Guida per costruire un class diagram
– Identificare le classi di oggetti
– Preparare un dizionario dei dati
– Identificare le associazioni (incluse specializzazioni ed
aggregazioni) tra classi
– Identificare gli attributi delle classi
– Identificare le operazioni
L’ordine non è rigido e sono possibili più iterazioni
39
Identificare le classi di oggetti
• Cosa cercare
– oggetti fisici, altri sistemi, dispositivi esterni, eventi da
ricordare, ruoli, locazioni, unità organizzative
• Dove cercare
– conoscenza generale del problema, descrizioni testuali,
figure
• Cosa considerare
– candidati aventi confini ben definiti e identità distinte
– candidati con proprietà da ricordare
– candidati che forniscono o richiedono servizi
• Scartare:
– candidati ridondanti, irrilevanti, o vaghi
– candidati che rappresentano singoli oggetti, o operazioni
su oggetti, o ruoli in associazioni
– candidati legati alla realizzazione
40
20
Esempio: Problema del Bancomat
Il sistema software da progettare per gestire una rete bancaria automatizzata prevede che
i cassieri e gli sportelli automatici (Bancomat) siano condivisi da un consorzio di banche.
Ogni banca fornisce il proprio computer per gestire i propri conti ed elaborare le
transazioni su questi conti.
I terminali dei cassieri sono posseduti dalle singole banche e comunicano direttamente
con il computer della propria banca. I cassieri inseriscono dati su conti e transazioni.
I Bancomat comunicano con un computer centrale che passa le transazioni alle banche
appropriate.
Un Bancomat accetta una scheda magnetica, interagisce con l’utente, comunica con il
sistema centrale per portare a termine la transazione, distribuisce il denaro, e stampa la
ricevuta.
Il sistema richiede appropriati provvedimenti per la registrazione e la sicurezza.
Il sistema deve gestire correttamente accessi concorrenti allo stesso conto.
Ogni banca fornirà il proprio software per il proprio computer; bisogna progettare il
software per i Bancomat e per la rete.
Il costo del sistema condiviso sarà distribuito proporzionalmente tra le banche secondo il
numero di clienti con carta Bancomat.
41
Esempio: Identificare le classi di oggetti
• Classi selezionate
– Conto
– Bancomat
– Banca
– Scheda
– Cassiere
– Terminale del cassiere
– Cliente
– Transazione
‹
Classi scartate
• Vaghe
» Sistema, Provvedimento di
sicurezza
» Provvedimento per la
registrazione
» Rete bancaria
• Singoli oggetti
» consorzio
• Attributi
» Dati del conto, Ricevuta,
Contante
» Dati della transazione
• Irrilevanti
» Costo
• Realizzazione
» Software
42
21
Preparare un dizionario dei dati
• Definire cosa la classe rappresenta nel contesto del
problema
• Specificare quali sono le responsabilità della classe nel
sistema
Esempio Bancomat
• Conto
– Rappresenta un singolo conto di un cliente in una banca.
Tutti gli accessi e le modifiche al conto della banca
devono avvenire attraverso questa classe
• Transazione Remota
– Una richiesta integrale di operazioni sul conto effettuata
dal cliente attraverso un Bancomat
43
Identificare le associazioni
• Cercare le dipendenze tra classi
– considerare le espressioni verbali nella descrizione del
problema
• La relazione di aggregazione/composizione è un tipo
speciale di associazione (“è parte di” o “si compone di”)
• Aggiungere i nomi alle associazioni o ai ruoli delle classi
associate
• Specificare la molteplicità
• Scartare le associazioni:
– non rilevanti per il problema specifico
– troppo legate alla realizzazione
– derivabili da altre associazioni
44
22
Esempio: Identificare le associazioni
45
Identificare l’ereditarietà
• Considerare solo classificazioni utili per il problema
specifico
– Specializzazione
• E’ possibile raffinare una classe in sottoclassi con
attributi e operazioni specifici?
– Generalizzazione
• E’ possibile identificare una superclasse che astrae
attributi e operazioni comuni?
• Posizionare nella superclasse gli attributi e le operazioni
comuni a tutte le sottoclassi
46
23
Esempio: Identificare l’ereditarietà
47
Identificare gli attributi degli oggetti e dei legami
• Gli attributi necessari dipendono dal problema specifico
• In fase di analisi
– Si può non essere immediatamente esaustivi
– Si possono omettere
• attributi derivati
• attributi che descrivono stati interni alla classe
48
24
Esempio: Identificare gli attributi degli oggetti e dei legami
49
Identificare le operazioni
• Operazioni base (costruttore, selettore, distruttore)
– non è necessario esplicitarle nel diagramma; indicarle solo
se utili nella comprensione del problema o se menzionate
esplicitamente nella descrizione
• Altre operazioni
– Consultare gli scenari che descrivono i casi d’uso
– Attribuire le funzionalità richieste alle classi identificate
– Considerare le operazioni che modificano lo stato degli
oggetti
• Si può non essere immediatamente esaustivi
50
25
Esempio: Identificare le operazioni
51
Oggetti: Notazione grafica
• Un oggetto è un’istanza di una classe
• Per rappresentare un oggetto si utilizza lo stesso
simbolo usato per rappresentare le classi
– Il nome viene sottolineato per evidenziare che si tratta di
un oggetto
– Analogamente a quanto accade per le classi è possibile
decidere il livello di visibilita per attributi e valori
52
26
Object diagrams
• Un object diagram rappresenta un insieme di oggetti e le relazioni
tra essi
• rappresentano una istanziazione di things di class diagrams
• rappresentano la vista statica di un sistema (o vista statica di un
processo) ma dalla prospettiva di un caso reale, o prototipale
53
Object diagrams
pubblicato da
L:Libro
cod_libro=XX111
Titolo= YYYYY
1
data edizione=1/1/87
ISDN=3333333
0..*
data acquisizione=2/2/90
Ed:Editore
ragione sociale= ....
nome breve= ....
indirizzo sede= ....
Telefono= ....
1..*
0..*
scritto da
0..*
LA:Libro antico
Valore=100000
Aut: Autore
nome = ......
cognome = ......
anno nascita= .......
anno morte= .......
0..*
Utente
54
27
Classi: Implementazione
• Esiste una corrispondenza tra la rappresentazione
UML di una classe e l’implementazione con un
linguaggio O-O (Es. Java)
55
Associazioni: Implementazione
• In generale non esiste un mapping diretto su un
costrutto di un linguaggio di programmazione
• Possono essere implementate introducendo degli
attributi ad hoc che contengono dei riferimenti (o
puntatori) alle istanze delle classi associate
– Il riferimento a più istanze di una classe può essere
modellato con liste, array, etc.
• Direzionalità
– In fase di implementazione si può decidere di codificarla
solo in una delle due direzioni (con un puntatore), perdendo
però così la possibilità di percorrere il link nella direzione
opposta!
56
28
57
29