Sei sulla pagina 1di 42

Corso di Laurea in Ingegneria Informatica

Corso di
Ingegneria del Software

Il linguaggio UML
Diagramma delle classi

1
Sommario
Generalità
Diagramma delle classi
Esempi

Ingegneria del Software UML – Diagramma delle classi 2


Diagramma delle classi

Lo scopo di un diagramma delle classi (CD) è di rappresentare


le classi e le relazioni tra esse

Si possono realizzare CD nella fasi di analisi e specifica dei


requisiti, progettazione di alto livello e progettazione di dettaglio
(o anche di implementazione).

In fase di analisi, un CD è una vista concettuale delle entità


nel dominio del problema. Cattura i concetti principali del
dominio a prescindere:
- da come essi saranno rappresentati in archivi o comunque in
un sistema di elaborazione,
- dalle funzionalità che opereranno su di essi (àsoftware).
L’attenzione dovrà essere rivolta alla comprensione di “cosa” il
sistema software dovrà fare e non “come” lo fa.
Ingegneria del Software UML – Diagramma delle classi 3
Diagramma delle classi

In fase di progetto, un CD descrive le entità del sistema e le


relazioni tra esse (ancora prescindendo dalla implementazione);
è una delle viste statiche del sistema progettato.

In fase di implementazione: le classi e le relazioni indicano la


reale struttura del software.

Trovano posto classi e relazioni che non hanno corrispondenza


nella fase concettuale.

Ingegneria del Software UML – Diagramma delle classi 4


Classe e Oggetti

✦ Una classe è il descrittore di un insieme di oggetti


che condividono le stesse proprietà, ossia:
• Attributi, operazioni, metodi, relazioni e comportamento.
✦ Ogni oggetto è un’istanza di una sola classe
• Ha specifici valori per gli attributi della classe, ossia
• Ha uno specifico stato (valore dei suoi attributi)
• In base al suo stato può rispondere diversamente allo stesso
messaggio
◆ Es. se si tenta di prelevare 100Euro da un oggetto conto
corrente, il risultato sarà diverso a seconda della disponibilità

Ingegneria del Software UML – Diagramma delle classi 5


Diagramma delle classi: sintassi
Un CD mostra una vista statica del modello, in particolare gli
elementi che esistono, le loro proprietà/attributi e
responsabilità/operazioni, e le relazioni con le altre entità
(non mostra informazioni temporali).

Classe: è un descrittore di un set di oggetti con struttura,


comportamento e relazioni comuni.
Nome
Classe

Attributi

Operazioni

Nella rappresentazione deve necessariamente essere indicato il


nome, ed opzionalmente gli attributi e le operazioni
Ingegneria del Software UML – Diagramma delle classi 6
Diagramma delle Classi

Nome
Classe
Libro Editore
Codice_libro Ragione_sociale
Titolo
Nome_breve Attributi
Data_edizione
Indirizzo_sede
ISBN
Telefono
Data_acquisizione
Richiesta( ) Variazione_dati_editore( )
Restituzione( )
Create( )
Operazioni
Classe: una
tipologia di
oggetti, con
propri attributi
ed operazioni

Ingegneria del Software UML – Diagramma delle classi 7


Attributi

✦ Gli attributi vengono scritti in


«lowerCamelCase»
• Iniziano con la minuscola
✦ Possono presentare vari ornamenti:

visibilità nome molteplicità: tipo = valoreIniziale {proprietà}

opzionale obbligatorio opzionale

Ingegneria del Software UML – Diagramma delle classi 8


Ornamenti degli Attributi
visibilità nome molteplicità: tipo = valoreIniziale {proprietà}

✦ Sono consentiti tre livelli di visibilità:


+ Livello pubblico: L'utilizzo viene esteso a tutte le classi
# Livello protetto: L'utilizzo è consentito soltanto alle classi che derivano dalla classe
originale
- Livello privato: Soltanto la classe originale può utilizzare gli attributi e le
operazioni definite come tali.

✦ Il nome dell’attributo é l’unico parametro necessario

✦ Il tipo dell’attributo può essere un tipo primitivo o standard (int, double,


char, etc…) oppure una classe definita nello stesso diagramma

✦ Valore Iniziale rappresenta il valore iniziale dell’attributo

Ingegneria del Software UML – Diagramma delle classi 9


Attributi
visibilità nome molteplicità: tipo = default {proprietà}
La molteplicità indica il quantitativo degli attributi (ad esempio la
dimensione per un array). Tramite la molteplicità è possibile indicare
come attributi degli array o matrici. Il valore di default é 1.

Es. Indirizzo: String[3]

Alcuni valori possibili sono:


• 1 (uno e uno solo). E’ il valore di default
• 0..1 (al più uno)
• * (un numero imprecisato, eventualmente anche nessuno; equivalente a 0..*)
• 1..* (almeno uno)

Ingegneria del Software UML – Diagramma delle classi 10


Attributi
visibilità nome molteplicità: tipo = default {proprietà}

{proprietà} rappresenta caratteristiche aggiuntive


dell’attribute (ad esempio la sola lettura)

Esempio: name: String [1] = "Untitled" {readOnly}

Ingegneria del Software UML – Diagramma delle classi 11


Operazioni della Classe
La signature completa è:

visibilità nome (lista parametri) : tipo-ritornato {proprietà}


La visibilità e il nome seguono regole analoghe a quelle degli attributi.

Lista parametri contiene nome e tipo dei parametri della funzione, secondo la forma:

direzione nome parametro: tipo = valore-di-default


direzione: input (in), output (out) o entrambi (inout). Il valore di default é in
nome, tipo e valore di default sono analoghi a quelli degli attributi
Tipo-ritornato é il tipo del valore di ritorno: dovrebbe essere un tipo appartenente ad una
classe standard

Esempio:
+ balanceOn (date: Date) : Money
Ingegneria del Software UML – Diagramma delle classi 12
Relazioni tra entità

ª Le entità (o gli oggetti) in un modello non sono in


generale isolate, ma in relazione con altre entità (oggetti)
con legami di varia natura, detti “relazioni”.

ª Le principali relazioni tra le classi sono:


• La relazione di generalizzazione-specializzazione
• La relazione di contenimento
• La relazione di associazione

• Le relazioni tra classi definiscono il così detto modello


statico del progetto.

Ingegneria del Software UML – Diagramma delle classi 13


Diagramma delle Classi
Cardinalita’
Libro Editore
Codice_libro pubblicato da Ragione_sociale
Nome_breve
Titolo 0..* 1
Data_edizione Indirizzo_sede
Telefono
ISBN Associazione
Data_acquisizione Variazione_dati_editore( )

Richiesta( ) scritto da
Restituzione( ) Autore
1..* 0..*
Create( ) Nome
Ruolo
0..* Cognome
giocato
Generalizzazione Libro prezioso
Anno_nascita
(superclasse- Anno_morte
Valore
sottoclasse) Variazione_anagrafica( )
Valorizza( )
0..*
Prestito
Cliente
Classe associativa
Ingegneria del Software UML – Diagramma delle classi 14
Classi di analisi e progettazione

Le classi di analisi aiutano a fissare un


comportamento del sistema, senza preoccuparsi dei
dettagli di implementazione. Le classi di progettazione
specificano esattamente come le classi assolvono le
loro responsabilità
ContoBancario

ContoBancario -nome:String
-numero:String
nome -saldo:double=0
numero +ContoBancario(nome:String, numero:String)
saldo +deposito(m:double):void
deposito() +prelievo(m:double):boolean
+getNome():String
prelievo()
calcolaInteressi() +getSaldo():double
+calcolaInteressi():double

Ingegneria del Software UML – Diagramma delle classi 15


Diagramma delle classi:
da analisi a progettazione
✦ Diagramma delle classi è usato per creare
un modello concettuale del dominio, ovvero
esso fornisce una rappresentazione delle
entità del mondo reale presenti nel dominio di
interesse (domain objects) e cattura le
relazioni tra di esse (System Domain Model)
✦ In analisi, non occorre completare il CD con
quei dettagli (e ornamenti UML) che non sono
rilevanti ai fini di comprensione del dominio,
come il tipo delle proprietà delle classi o la
cardinalità delle associazioni.
Ingegneria del Software UML – Diagramma delle classi 16
Diagramma delle classi:
da analisi a progettazione
✦ Il CD di prima analisi ha dunque lo scopo di
rappresentare i concetti significativi del
dominio del problema, la terminologia del
problema e il contenuto informativo del
dominio.
✦ Esso rappresenta altresì un’ontologia del
dominio del problema

Ingegneria del Software UML – Diagramma delle classi 17


Diagramma delle classi:
da analisi a progettazione
✦ Il modello di analisi si può raffinare in più
iterazioni, aggiungendo dettagli, ornamenti
UML, e rendendolo più completo, nella
descrizione del dominio del problema e
nell’interazione del sistema con gli attori.
✦ Ad esempio, in un raffinamento del
diagramma delle classi aggiungiamo alle
associazioni il loro tipo, la loro cardinalità,
la navigabilità e i ruoli

Ingegneria del Software UML – Diagramma delle classi 18


Diagramma delle classi:
da analisi a progettazione
✦ Il diagramma delle classi di progetto è
ottenuto raffinando il diagramma di analisi,
aggiungendo i dettagli tralasciati nel
precedentemente, ed offrendo una soluzione al
problema (System model).
✦ Il dettaglio offerto dai design-CD deve essere
tale da specificare l’implementazione. In
particolare:
• Le classi devono specificare l’insieme completo dei loro
attributi (dettagliando nome, tipo, visibilità, etc.) e delle
operazioni (dettagliando nome, nome e tipi dei parametri,
tipo del valore restituito, visibilità, etc.);
• Tutte le associazioni vanno raffinate e ben definite (tipo,
cardinalità, direzione e ruolo).

Ingegneria del Software UML – Diagramma delle classi 19


Diagramma delle classi:
da analisi a progettazione
✦ Al termine, la progettazione offre:
• classi complete (che offrono almeno ciò che i loro
utilizzatori attendono), sufficienti (che offrono solo ciò che
i loro utilizzatori attendono), ed essenziali (i servizi offerti
devono essere primitivi, semplici, atomici e distinti);
• Moduli (classi, componenti, package, etc.) con massima
coesione e minimo accoppiamento (poche relazioni di
dipendenza tra gli elementi);
• Ulteriori entità (classi, oggetti, componenti, etc.) che sono
introdotte per rispondere ad esigenze e scelte progettuali
(es.: interfacciamento con utente, persistenza,
coordinamento, collezionamento di oggetti, prestazioni…).

Ingegneria del Software UML – Diagramma delle classi 20


Relazione di
generalizzazione-specializzazione
La relazione di generalizzazione-specializzazione (o gen-
spec), tipica dei modelli object-oriented, corrispondente al
legame tipo-sottotipo, indica legami del tipo “è un” tra classi
di oggetti:
Es.: un ContoDiDeposito è un ContoBancario
La super classe raccoglie caratteristiche e comportamenti
comuni agli elementi delle sottoclassi.

Ingegneria del Software UML – Diagramma delle classi 21


Relazione di
generalizzazione-specializzazione
I diagrammi di queste associazioni sono chiamati gerarchie
di ereditarietà

La classe derivata eredita le caratteristiche della classe base.


Gli attributi e le operazioni della classe base apparterranno
anche alla classe derivata.
La classe derivata potrà
- aggiungere altri attributi e operazioni
- specializzare operazioni della classe base

Ingegneria del Software UML – Diagramma delle classi 22


Relazione di associazione

• L’associazione tra due (o più) classi esprime un legame


semantico tra istanze di classi.
• E’ una connessione tra due (o più) classi in virtù della
quale esiste un collegamento tra le istanze delle classi
• Le istanze di una associazione sono collegamenti

• Se esiste un collegamento tra oggetti allora deve


esistere un'associazione tra le loro classi, poiché un
collegamento è l'istanziazione di un'associazione

Ingegneria del Software UML – Diagramma delle classi 23


Relazione di associazione

associazione

Azienda Persona

<<istanzia>> <<istanzia>> <<istanzia>>

javaConsulting:Azienda rossi:Persona
collegamento

Ingegneria del Software UML – Diagramma delle classi 24


Relazione di associazione

Una associazione è caratterizzata da:


ü un nome: esprime il legame semantico tra le classi
ü un eventuale ruolo giocato dalle parti associate
ü la molteplicità dell'associazione: esprime la
cardinalità delle connessioni tra oggetti “istanze”
delle classi associate e può essere di tipo
• uno a uno
• uno a molti
• molti a molti
ü la direzionalità (uni o bidirezionale): specifica il verso
di percorrenza della relazione ed attribuisce inoltre
alla classe origine del percorso la responsabilità di
tenere traccia dell’associazione
Ingegneria del Software UML – Diagramma delle classi 25
Relazione di associazione

✦ L’associazione può essere riflessiva


• Oggetti della classe possono avere collegamenti con
oggetti della stessa classe
sottocartella
0…* 1 0…*
Cartella File
0…1
padre

✦ Le relazioni di associazione si traducono in C++ con una


o più variabili membro di tipo puntatore alla classe
associata (a seconda della molteplicità
dell’associazione), che consente la navigabilità

Ingegneria del Software UML – Diagramma delle classi 26


Classe Associativa
✦ La classe associativa connette due classi e
definisce un insieme di caratteristiche proprie della
associazione stessa (che non appartengono a
nessuna delle entità coinvolte nell’associazione)
✦ Le istanze dell'associazione sono collegamenti,
dotati di attributi e operazioni, la cui identità
individuale è stabilita esclusivamente dalle identità
degli oggetti alle estremità del collegamento
✦ Quindi si possono usare le classi associazione solo
quando ogni collegamento ha una identità univoca

✦ Nell'esempio precedente si sta affermando che una


istanza di Prestito può riferirsi a un solo Libro e un
solo Cliente
Ingegneria del Software UML – Diagramma delle classi 27
Classe Associativa
✦ Per rendere reale (reificare) una calsse
asssociativa essa va trasformata in una vera
classe: Reifica

* *
Studente Esame

Voto
Valore

1 * * 1
Studente Voto Esame
Valore

Ingegneria del Software UML – Diagramma delle classi 28


Relazione di contenimento

Un altro tipo legame tra classi è la relazione di contenimento fra


oggetti (aggregazione) che puo’ essere di tipo debole (o lasco) o
stretto, così come illustrato nei diagrammi che seguono.

Contenimento debole Contenimento stretto


C classe contenitore, C3 classe contenitore,
X classe contenuta X classe contenuta

Ingegneria del Software UML – Diagramma delle classi 29


Relazione di contenimento

La relazione di contenimento debole indica l'indipendenza del


ciclo di vita dell'oggetto contenuto dall'oggetto contenitore.

L'oggetto contenuto potrà quindi esistere anche


indipendentemente dal contenitore.

Questo comporta la non responsabilità da parte del contenitore


per la creazione e distruzione dell'oggetto contenuto.

Il contenimento debole si realizza introducendo nella classe


contenitore C un puntatore all’oggetto x contenuto. Il costruttore
di C riceve in ingresso il puntatore all'oggetto contenuto.

Ingegneria del Software UML – Diagramma delle classi 30


Relazione di contenimento
L’utente della classe C ha la responsabilità di:
a) creare l'oggetto contenuto.
b) definire ed inizializzare un puntatore ad esso.
c) costruire l'oggetto contenitore passando il puntatore al contenuto
In particolare, il contenimento debole si può realizzare in due
modi:
a) il contenitore (C) ha una variabile membro privata di tipo
puntatore ad un oggetto di tipo contenuto (X)
b) il contenitore (C) ha una variabile membro privata di tipo
riferimento ad un oggetto di tipo contenuto (X )
In entrambi i casi il contenitore dovrà definire un costruttore
che riceva in input il puntatore (o il riferimento) all'oggetto
contenuto.
Ingegneria del Software UML – Diagramma delle classi 31
Relazione di contenimento

ªLa relazione di contenimento stretto indica, concettualmente,


che l'oggetto contenuto non ha una vita propria ma esiste in
quanto parte dell'oggetto contenitore.
ªPertanto l'oggetto contenitore e’ anche responsabile della
costruzione e distruzione dell'oggetto contenuto.

ªIl contenimento stretto si realizza introducendo nella classe


contenitore C una variabile membro x della classe contenuto X
ªAttraverso il costruttore di C viene costruito un oggetto c e viene
richiamato (anche implicitamente, a cura del compilatore) il
costruttore della classe X per l’inizializzazione dell’oggetto x
contenuto in c.

Ingegneria del Software UML – Diagramma delle classi 32


Relazione di contenimento

L’utente della classe C ha la responsabilità di instanziare


un oggetto di tipo contenitore, richiamando il suo
costruttore con tutti i valori di inizializzazione necessari sia
all’inizializzazione del contenitore che del contenuto.

Il contenimento stretto si può realizzare nel modo seguente:


a) Aggiungere una variabile membro alla classe
contenitore del tipo della classe contenuto.
b) Implementare il costruttore del contenuto in modo
da richiamare il costruttore del contenitore

Ingegneria del Software UML – Diagramma delle classi 33


Esempio

Notturno

num_cuccette

aggregazione ha
Treno
Carrozza
codice
classe 1..* 1 Capienza_max

Intercity

trasporta
1 num_posti_prenotati
prenota_posto()
1..*

Passeggero

Nome
specializzazione /
associazione
fumatore
generalizzazione

prenotaPosto()

Ingegneria del Software UML – Diagramma delle classi 34


Esempio di contenimento debole

„ Consideriamo il seguente esempio:

Esso esprime il concetto che l'Automobile (ogni istanza di Automobile)


ha una Carrozzeria ed un Motore.
La specifica prodotta indica un contenimento in senso lasco.
Per quanto detto scegliamo la traduzione di tale relazione tramite l'uso
dei puntatori per cui avremo:
Ingegneria del Software UML – Diagramma delle classi 35
Esempio di contenimento debole

//file Automobile.h
#include "Motore.h"
#include "Carrozzeria.h"
class Automobile {
public:
//il costruttore inizializza gli attributi propri e riceve
//un puntatore per ognuno degli oggetti aggregati
Automobile(Stringa marcaI= "", Stringa modI="",…, Motore* motI=0, Carrozzeria* carI=0);
~Automobile();
void Muovi_Avanti();
void Muovi_indietro();
Marcia MarciaUp();
void Avvia();
private:
Carrozzeria* carrozzeria; //traduzione aggregazione
Motore* motore; //traduzione aggregazione
Stringa marca;
Stringa modello;
Km_ora velocità;
MetriSecondoQuadro accelerazione;
Marcia marciacorrente;
StatoMotore stato;
};
Ingegneria del Software UML – Diagramma delle classi 36
Esempio di contenimento debole

„ Notiamo l'implementazione del costruttore nel seguente frammento del


file di implementazione della classe Automobile (Automobile.cpp)

//file Automobile.cpp
//Costruttore di Automobile
Automobile:: Automobile(Stringa marcaI, Stringa modI,…,Motore* motI, Carrozzeria* carI) :

// Inizializzazione variabili membro con lista di inizializzazione


marca(marcaI), modello(modI),
motore(motI), carrozzeria(carI);

//Implementazione funzione Avvia()


void Automobile::Avvia( ) {
// accende il proprio motore ed inizializza la variabile membro stato
stato =motore->start();
}
// Implementazione altre funzioni ........

Ingegneria del Software UML – Diagramma delle classi 37


Esempio di contenimento debole

„ Il programma principale dovrà creare un oggetto di tipo Carrozzeria e


Motore e poi l'oggetto di tipo Automobile. Ad esempio:

#include "Automobile.h"
main () { //usa classe Automobile
//definisce e inizializza oggetto di tipo Motore
Motore m("AZ123","Ferrari", 6,12,1000);
//definisce e inizializza oggetto di tipo Carrozzeria
Carrozzeria c("12345ASA", "RossoFerrari",1500);
//definisce e inizializza puntatore a motore
Motore* puntatoreMotore=&m;
//definisce e inizializza puntatore a carrozzeria
Carrozzeria* puntatoreCarrozzeria=&c;
//definisce e inizializza oggetto Automobile, fornendo puntatori
Automobile auto1("Ferrari", …, puntatoreCarrozzeria, puntatoreMotore);
//Avvia l'automobile (indirettamente è avviato il motore)
auto1.Avvia();
} //al termine vengono separatamente distrutti m,c e auto1

Ingegneria del Software UML – Diagramma delle classi 38


Diagramma delle Classi:
la relazione di dipendenza
Una dipendenza indica una relazione fornitore/cliente tra
elementi del modello, in cui la modifica del fornitore può avere
impatto sugli elementi del cliente
✦ Esistono tre tipi base di dipendenze:
1. di Uso
2. di Astrazione
3. di Permesso
Il tipo di dipendenza risulta di solito chiaro dal contesto anche
senza indicare lo stereotipo, che spesso si omette

Ingegneria del Software UML – Diagramma delle classi 39


Diagramma delle Classi:
la relazione di dipendenza

Usage: dipendenza in cui un elemento (client) richiede un


altro elemento (supplier) per la sua piena definizione o
implementazione (ad es. <<create>>, <<instantiate>>,
<<call>>, <<send>>)

Abstraction: lega due elementi che rappresentano lo


stesso concetto a diversi livelli di astrazione (ad es.
implementazione di interfacce)

Permission: regolano l’accesso tra elementi

Sono usate in molti altri diagrammi UML in fase di progettazione

Ingegneria del Software UML – Diagramma delle classi 40


Diagramma delle Classi: la relazione di
dipendenza. Esempio

In un CD è possibile specificare una particolare vista delle classi e


cioè l’insieme dei servizi che una classe mette a disposizione.
Questa specifica prende il nome di interfaccia.
Utilizzate anche in altri diagrammi (ad es., component diagram)

<<interface>> Impiegato Persona

implements

getName()
getRole()

La relazione “implements” è una dipendenza di tipo


<<Abstraction>>)

Ingegneria del Software UML – Diagramma delle classi 41


Classe astratta ed Interfacce
✦ La classe astratta è una classe che ha una o più
operazioni astratte e non può essere direttamente
istanziata.
• Occorre prima creare una sottoclasse concreta
• In UML si indica col nome in corsivo o etichetta {abstract}

✦ Una interfaccia è una classe priva di implementazione


(tutte le sue proprietà sono astratte)
• descrive una porzione del comportamento visibile di un insieme di
oggetti
• In UML si indica con la parola chiave <<interface>>

Ingegneria del Software UML – Diagramma delle classi 42