Programmare e Progettare

con Java.
Lezione 8 - Diagramma delle Classi e Design Patterns
DIAGRAMMA DELLE CLASSI
UML - DIAGRAMMA DELLE CLASSI
UML (Unified Modeling Language) è una notazione standard visuale usata per
scrivere (disegnare) i modelli: un’astrazione atta a comprendere cosa si vuole fare
prima di doverla fare.
Viene considerato uno standard industriale e comprende un gran numero di
diagrammi impiegati nel progettare SW a diversi livelli di astrazione.
Il diagramma delle classi è una descrizione statica della struttura delle classi
SW, con i loro campi e i loro metodi.
L’utilità di tale diagramma è che una volta disegnato, passare al codice diviene
molto semplice. Inoltre permette di descrivere in modo chiaro soluzioni efficaci a
problemi comuni (Design Patterns…)
UNA VISIONE DI INSIEME
Il diagramma delle classi definisce una visione statica di insieme del sistema
SW, rappresentando:

➔ Classi
➔ Relazioni tra classi:
◆ Associazioni (classi che ne usano altre)
◆ Generalizzazioni (vincoli di ereditarietà)
◆ Aggregazioni (classi che ne contengono altre)

È forse il modello più importante perché definisce gli elementi base del sistema e
da questo possiamo comprenderne il funzionamento d’insieme.
CLASSI
Le classi sono rappresentate da dei rettangoli divisi a loro volta in 3 sezioni che
ne identificano le 3 caratteristiche principali:

★ Nome
★ Campi (stato)
★ Metodi (comportamento)
ATTRIBUTI
Un attributo è una caratteristica della classe che può essere:

➢ nota: Memorizzata all’interno della classe, è una descrizione primitiva.

➢ derivata: Viene calcolata a partire da caratteristiche note. Si usa quando il
valore varia in funzione di una legge che mette in relazione l’attributo con altre
entità. Si indicano con un ‘/’ che precede il nome dell’attributo.

Il tipo dell’attributo segue il nome, separato dai ‘:’

Ad ES:
INFORMAZIONI SUI MEMBRI
I modificatori e le altre informazioni importanti dei vari campi e metodi si possono indicare
utilizzando adeguati caratteri speciali precedenti il nome del membro:
➔ modificatori d’accesso:
◆ - private
◆ + public
◆ # protected
◆ ~ package
➔ abstract: (vale anche per la classe)
◆ nomeCorsivo
➔ static:
◆ nomeSottolineato
➔ inizializzazione:
◆ = valore dopo la dichiarazione del tipo
➔ molteplicità:
◆ Indica quante istanze massime ci si aspetta di incontrare. Se omesso, infinite.
OPERAZIONI E METODI
Un’operazione è un servizio che la classe deve fornire.

Un metodo è un’implementazione dell’operazione.

Nel diagramma delle classi vengono riportate le operazioni: le implementazioni

che ci vengono in mente in corso d’opera le aggiungiamo come annotazioni del
diagramma. Dopotutto, creare un’applicazione è un processo incrementale (si
arricchisce di continuo con nuove informazioni).
OPERAZIONI
Tutti i modi di annotare modificatori e informazioni riguardanti i campi valgono
anche per le operazioni!
Un’operazione si scrive come la segnatura di un metodo, ma con un paio di
accorgimenti riguardante parametri e tipo di ritorno:
+nomeMetodo(nomeParam1:tipoParam1, nomeParam2:tipoParam2):tipoRitorno
Ad ES:
+add(a:int, b:int):int
#div(a:long, b:long):double
GENERALIZZAZIONE
Una generalizzazione è una relazione tra una classe generica ad una più
specializzata. Essa si rappresenta come una freccia dalla testa vuota direzionata
verso la classe più generale a partire dalla classe più specializzata.

Spesso utilizzata per modellare una situazione in cui più classi ne estendono una
astratta.
ASSOCIAZIONI
Un’associazione identifica una relazione generica tra più classi, come quella tra
una classe Studente e una classe Corso che modella il concetto per cui lo
studente segue il corso.

Ogni associazione deve avere un nome unico rispetto a tutte le altre all’interno
dello stesso diagramma ed è solitamente un verbo.

L’associazione si indica come una linea continua che collega due classi e il nome
va inserito sopra di essa, più o meno al centro.
MOLTEPLICITÀ NELLE ASSOCIAZIONI
La molteplicità delle associazioni di un diagramma delle classi ha funzionalità
analoghe a quelle che ha nei diagrammi ER; essa ci dice:

➔ Se l’associazione è obbligatoria (ovvero se un oggetto della classe ha sempre

bisogno dei servizi dell’altra)
➔ Il numero minimo e massimo di oggetti che possono essere messi in
relazione ad un altro oggetto.
VALORI SPECIALI DI MOLTEPLICITÀ
I seguenti valori modellano il significato associato:

❏ 1 Esattamente uno
❏ 0..1 O nessuno o solo 1
❏ 0..* Un qualsiasi numero, anche nessuno
❏ 1..* Uno o più
❏ 7 Esattamente 7
❏ 4..15 Intervallo tra 4 e 15
❏ ? Ancora da definire
ASSOCIAZIONI - ESEMPI
RUOLO
Il ruolo definisce il ruolo svolto dalla classe nell’associazione ed è utile per
identificare:

➔ Le auto-associazioni, ovvero quando un oggetto usa i servizi di un oggetto

dello stesso tipo
➔ Le associazioni multiple, ovvero quando due oggetti appartenenti a due
determinati tipi usano servizi diversi dell’altro.
CLASSI ASSOCIAZIONE
Una classe associazione è un tipo di classe che esiste in modo subordinato ad
un’associazione, ovverosia essa descrive caratteristiche di quest’ultima o azioni
relative ad essa.

Si indica come una normale classe, ma deve essere collegata ad un’associazione

mediante una linea tratteggiata.
NAVIGAZIONE
La navigazione intende il numero di sensi in cui può essere letta l’associazione,
ovverosia le modalità in cui una classe usa i servizi di un’altra.

Una navigazione a doppio senso indica che entrambe le classi usano servizi
dell’altra, mentre una navigazione a senso unico indica è solo una la classe a farlo
ed è indicata trasformando la linea in una freccia.

Per un nome utente ed una password, dall’utente potremmo voler risalire alla sua
password essendo unico, mentre due password possono essere uguali e quindi
non potremmo risalire al nome utente!
AGGREGAZIONI
Le aggregazioni sono associazioni particolari che modellano situazioni in un
oggetto è inteso come descrizione della parte di un’altro. Si indicano aggiungendo
un rombo vuoto al termine dell’associazione, dalla parte dell’insieme e non della
parte.
COMPOSIZIONI
Le composizioni sono forme di aggregazione più forti: un oggetto non può
esistere senza le sue componenti. In pratica:

★ L’aggregazione descrive delle parti accessorie la cui esistenza è indipendente

dall’oggetto che le aggrega.
★ La composizione descrive delle parti costituenti la cui esistenza è subordinata
all’oggetto che le compone.
DIPENDENZE
Una dipendenza è una associazione che modella una situazione in cui la modifica
dell’oggetto di una classe causa la modifica dell’oggetto di quella dipendente. È
rappresentata da una freccia tratteggiata che termina dalla parte della classe
dipendente.
DIPENDENZE - ESEMPIO
STEREOTIPI PER DIPENDENZE
Uno stereotipo è una specializzazione aggiuntiva dei concetti rappresentati. Gli
stereotipi si rappresentano come parole significative racchiuse tra << >>.
Per l’associazione dipendenza, alcuni stereotipi significativi sono:
❖ access: Il contesto public di target è accessibile dal source
❖ call: Una operazione di source invoca un’operazione di target
❖ refine: Specifica una relazione di “raffinamento”
❖ friend: Una operazione di source può accedere ai campi privati di target
❖ derive: Source è computato da target
❖ instantiate: Source crea istanze di target
❖ use: Source richiede target per la sua implementazione
INTERFACCE
Le interfacce specificano il comportamento di una classe senza darne
implementazione, disaccoppiando la definizione di operazioni alla loro
implementazione.

Sono rappresentate da un cerchio e un semicerchio: la parte del semicerchio

indica l’uso dell’interfaccia, mentre il cerchio indica l’offerta (implementazione) di
essa.

Possibile specificare le operazioni definite sostituendo il cerchio/semicerchio con

una classe il cui nome è preceduto dallo stereotipo <<interface>>
INTERFACCE - ESEMPIO
DIAGRAMMA DEGLI OGGETTI
Il diagramma degli oggetti è un grafo di istanze di elementi (oggetti) e quindi
rappresenta una specifica istanza del diagramma delle classi.
Possono essere utilizzati durante l’analisi e il progetto per:
➢ Capire la struttura di oggetti complessi
➢ Esplicitare la struttura di oggetti complessi
➢ Presentare esempi di stato del sistema
Un oggetto si indica come un rettangolo diviso in due sezioni:
❖ Nome: Indica il nome dell’oggetto (il suo riferimento) ed è seguito da :tipo.
❖ Stato: Indica l’assegnamento corrente dei suoi campi.
OGGETTI - ESEMPIO
LINK
Un link è la trasposizione di un’associazione del diagramma delle classi al
diagramma degli oggetti.
MODELLI DI DOMINIO E DI PROGETTO
Un modello di dominio è una rappresentazione di classi concettuali del mondo
reale e non di oggetti SW. Il termine non indica un insieme di diagrammi che
descrivono classi SW. Siamo più vicini alla realtà, come i diagrammi ER:

Un modello di progetto è una rappresentazione in cui le classi rappresentate

sono mappabili direttamente in classi SW.

L’idea è passare dal modello di dominio a quello di progetto!

EVOLUZIONE
IDENTIFICARE CLASSI
Le classi corrispondono ad entità fisiche e a concetti del dominio applicativo.

In fase di analisi:

❏ Evitare di rappresentare soluzioni implementative.

❏ Evitare classi ridondanti, irrilevanti o vaghe. I nomi delle classi devono
riflettere il loro significato semantico e non il ruolo che giocano nelle
associazioni.
❏ I nomi che descrivono oggetti dovrebbero essere espressi come attributi.
❏ Non confondere attributi (proprietà del singolo) con associazioni (proprietà tra
coppie).
IDENTIFICARE CLASSI - ESEMPI
IDENTIFICARE ASSOCIAZIONI
Le associazioni sono tipicamente indicate da verbi che esprimono:

❏ Collocazione fisica (contenuto in)

❏ Azioni (gestisce)
❏ Comunicazioni (parla con)
❏ Proprietà (possiede)
❏ Soddisfacimento di condizioni (sposato con)

Ogni riferimento da una classe ad un’altra è un’associazione.

IDENTIFICARE ASSOCIAZIONI - AGGREGAZIONI
Una aggregazione è un’associazione con semantica part-of.
IDENTIFICARE ASSOCIAZIONI - REGOLE
❏ Evitare associazioni irrilevanti o che esprimono soluzioni implementative.
❏ Una associazione deve descrivere una proprietà strutturale del dominio e non
un evento transitorio.
❏ Molte associazioni ternarie possono essere scomposte in due associazioni
binarie.
❏ Evidenziare le associazioni derivate, che cioè non possono essere espresse
in termini di altre associazioni.
❏ Quando appropriato, specificare i ruoli.
IDENTIFICARE ASSOCIAZIONI - ESEMPI DI REGOLE
IDENTIFICAZIONE DEGLI ATTRIBUTI
Le proprietà di classi e associazioni sono attributi. Spesso corrispondono a nomi
seguita dopo possessivi (ad ES: il colore della macchina).

Gli attributi derivati andrebbero inizialmente evidenziati e poi eliminati in corso

d’opera (saranno le operazioni a calcolarli!).

Se una proprietà dipende dalla presenza di un’associazione, l’attributo andrebbe

rappresentato come un attributo della classe associazione che si viene allora a
generare.
IDENTIFICAZIONE ATTRIBUTI - REGOLE
❏ Non aggiungere mai agli attributi di un’associazione gli identificatori degli
oggetti a meno che non risultino esplicitamente dalle specifiche!
❏ Quando gli attributi di una classe possono essere raggruppati in due o più
insiemi, con tutta probabilità la classe andrebbe divisa in due classi, magari
sottoclassi della prima.
ESEMPIO POS
Diagramma delle classi per un POS descritto dallo scenario principale di successo (flusso base):

1) Il Cliente arriva alla Cassa con gli Articoli e/o i Servizi da acquistare.
2) Il Cassiere inizia una nuova vendita.
3) Il Cassiere inserisce l’id dell’Articolo.
4) Il Sistema registra la riga di vendita per l’Articolo e mostra la descrizione di esso così come il suo
prezzo e il totale parziale. Il prezzo è calcolato sulla base di un insieme di regole.
5) Il Cassiere ripete 2 e 3 fino a che non ha terminato, poi prosegue.
6) Il Sistema mostra il totale con le imposte calcolate.
7) Il Cassiere riferisce il totale al Cliente chiedendo il Pagamento.
8) Il Cliente paga e il Sistema gestisce il pagamento.
9) Il Sistema registra la vendita completata e invia informazioni sulla Vendita e sul pagamento ai
sistemi esterni di Contabilità (per contabilità e commissioni) e di Inventario (per il suo
aggiornamento).
10) Il Sistema genera la Ricevuta.
11) Il Cliente se ne va con Ricevuta e articoli acquistati.
ESEMPIO POS - IDENTIFICHIAMO LE CLASSI
1) DEFINIRE ASSOCIAZIONI, MOLTEPLICITÀ, RUOLI
2) AGGIUNGERE AGGREGAZIONI, ATTRIBUTI, NAV
3) ESEMPIO DI STATO DEL SISTEMA
3) ESEMPIO DI STATO DEL SISTEMA
ESEMPIO DA UML @ CLASSROOM
Esempio proposto dal libro UML @ CLASSROOM: University Information System.
Requisiti:
➔ Un’università consiste di più dipartimenti che sono composti da più istituti. Dipartimenti e
istituti hanno un nome ciascuno e ogni istituto ha un indirizzo.
➔ Ogni dipartimento è guidato da un rettore il quale è un dipendente dell’università.
➔ Il numero totale di dipendenti è noto. Essi hanno un numero di sicurezza sociale (SSN
americano), un nome e un indirizzo email. Vanno distinti ricercatori e personale
amministrativo.
➔ I ricercatori sono assegnati ad almeno un istituto e si conosce il loro campo di studio. Essi
possono essere assegnati in determinati progetti per un certo numero di ore. Di ogni
progetto sono conosciuti il nome, la data di inizio e quella di fine. Alcuni ricercatori tengono
corsi e quelli che lo fanno sono definiti relatori.
➔ I corsi hanno un identificativo unico, un nome e una durata settimanale espressa in ore.
1) IDENTIFICHIAMO LE CLASSI
➔ Un’università consiste di più dipartimenti che sono composti da più istituti.
Dipartimenti e istituti hanno un nome ciascuno e ogni istituto ha un indirizzo.
➔ Ogni dipartimento è guidato da un rettore il quale è un dipendente dell’università.
➔ Il numero totale di dipendenti è noto. Essi hanno un numero di sicurezza sociale
(SSN americano), un nome e un indirizzo email. Vanno distinti ricercatori e
personale amministrativo.
➔ I ricercatori sono assegnati ad almeno un istituto e si conosce il loro campo di
studio. Essi possono essere assegnati in determinati progetti per un certo numero di
ore. Di ogni progetto sono conosciuti il nome, la data di inizio e quella di fine. Alcuni
ricercatori tengono corsi e quelli che lo fanno sono definiti come relatori.
➔ I corsi hanno un identificativo unico, un nome e una durata settimanale espressa in
ore.
1) STATO DEL MODELLO
2) IDENTIFICHIAMO GLI ATTRIBUTI
➔ Un’università consiste di più dipartimenti che sono composti da più istituti.
Dipartimenti e istituti hanno un nome ciascuno e ogni istituto ha un indirizzo.
➔ Ogni dipartimento è guidato da un rettore il quale è un dipendente dell’università.
➔ Il numero totale di dipendenti è noto. Essi hanno un numero di sicurezza sociale
(SSN americano), un nome e un indirizzo email. Vanno distinti ricercatori e
personale amministrativo.
➔ I ricercatori sono assegnati ad almeno un istituto e si conosce il loro campo di
studio. Essi possono essere assegnati in determinati progetti per un certo numero di
ore. Di ogni progetto sono conosciuti il nome, la data di inizio e quella di fine. Alcuni
ricercatori tengono corsi e quelli che lo fanno sono definiti relatori.
➔ I corsi hanno un identificativo unico, un nome e una durata settimanale espressa in
ore.
2) STATO DEL MODELLO
3) IDENTIFICHIAMO LE ASSOCIAZIONI
➔ Un’università consiste di più dipartimenti che sono composti da più istituti.
Dipartimenti e istituti hanno un nome ciascuno e ogni istituto ha un indirizzo.
➔ Ogni dipartimento è guidato da un rettore il quale è un dipendente dell’università.
➔ Il numero totale di dipendenti è noto. Essi hanno un numero di sicurezza sociale (SSN
americano), un nome e un indirizzo email. Vanno distinti ricercatori e personale
amministrativo.
➔ I ricercatori sono assegnati ad almeno un istituto e si conosce il loro campo di studio.
Essi possono essere assegnati in determinati progetti per un certo numero di ore. Di
ogni progetto sono conosciuti il nome, la data di inizio e quella di fine. Alcuni ricercatori
tengono corsi e quelli che lo fanno sono definiti relatori.
➔ I corsi hanno un identificativo unico, un nome e una durata settimanale espressa in ore.
3) IDENTIFICHIAMO LE ASSOCIAZIONI (1)
“Vanno distinti ricercatori e personale amministrativo”

“Alcuni ricercatori tengono corsi e quelli che lo fanno sono definiti relatori”

Queste sono chiaramente generalizzazioni.

Impiegato è abstract poiché non ci sono altri

tipi di impiegato.
3) IDENTIFICHIAMO LE ASSOCIAZIONI (2)
“Un’università consiste di più dipartimenti che sono composti da più istituti”

Questa è una composizione, dato che abbiamo una dipendenza tra istituto e
dipartimento.
3) IDENTIFICHIAMO LE ASSOCIAZIONI (3)
“Ogni dipartimento è guidato da un rettore il quale è un dipendente
dell’università”

Chiamiamo la relazione leads e assegnamo all’impiegato che ha questo compito il

ruolo di rettore.
3) IDENTIFICHIAMO LE ASSOCIAZIONI (4)
“I ricercatori sono assegnati ad almeno un istituto”

Questa è una aggregazione perché l’istituto raccoglie in esso un certo numero di

ricercatori, ma la loro esistenza non è subordinata a quella dell’istituto.
3) IDENTIFICHIAMO LE ASSOCIAZIONI (4)
“Essi (i ricercatori) possono essere assegnati in determinati progetti per un
certo numero di ore”

La partecipazione ad un progetto ha un attributo descrittivo per ogni diverso

ricercatore che vi partecipa: il numero di ore! La relazione viene modellata quindi
come una classe associazione!
3) IDENTIFICHIAMO LE ASSOCIAZIONI (6)
“Alcuni ricercatori tengono corsi e quelli che lo fanno sono definiti relatori”

I relatori ereditano tutte le caratteristiche, le associazioni e le aggregazioni dal

fatto che sono necessariamente ricercatori.

In più, un relatore ha un’associazione teaches con il corso.

4) METTIAMO TUTTO INSIEME...
5) GENERIAMO IL CODICE
I diagrammi delle classi sono spesso creati con l’intento di implementare gli
elementi modellati in un linguaggio orientato agli oggetti (come Java!).

Spesso la traslazione è semi-automatica e richiede un intervento manuale minimo!

5) GENERIAMO IL CODICE (1)
5) GENERIAMO IL CODICE (2)
5) GENERIAMO IL CODICE (3)
5) GENERIAMO IL CODICE (4)
5) GENERIAMO IL CODICE (5)
5) GENERIAMO IL CODICE (6)
ESERCIZI
● Si supponga di dover progettare un distributore automatico di merendine che vende piccoli
articoli già confezionati e pronti da mangiare (barrette di cioccolato, biscotti, caramelle,
ecc.). Ciascun prodotto ha un prezzo e un nome. Un cliente può acquistare il prodotto solo
utilizzando una chiavetta emessa dalla ditta che gestisce il distributore, non sono previste
altre forme di pagamento (carta di credito, cash, ecc). La chiavetta memorizza il saldo del
denaro a disposizione. Le funzionalità che il sistema deve supportare sono:
○ Vendita di un prodotto (scelta da una lista di prodotti, pagamento del prodotto e distribuzione del prodotto).
○ Ricarica del distributore.
○ Set-up del distributore (Definizione dei prodotti e del prezzo).
○ Monitoraggio del distributore (numero di prodotti venduti, numeri di prodotti di un certo tipo venduti, entrate
totali).

Il sistema può essere utilizzato da un cliente, da un addetto alla manutenzione (che ricarica i
prodotti nel distributore) o da un amministratore (che fa il set-up iniziale del distributore).
DESIGN PATTERNS
ALCUNI DEI DESIGN PATTERNS FREQUENTI
https://www.tutorialspoint.com/design_pattern/index.htm