Design Pattern

Design Pattern
Ingegneria del Software – parte II
Andrea Bei
Progettazione a oggetti (OOD)

Progettare a oggetti una funzionalità espressa da un requisito (
use case, SSD, …) significa



RDD
Identificare gli oggetti, coerenti rispetto al modello di dominio e
alla architettura applicativa, la cui collaborazione realizza la
funzionalità
Assegnare correttamente le responsabilità agli oggetti identificati
applicando i Design Pattern
Nell’OOD l’ UML è usato per rappresentare le decisioni
progettuali di identificazione di oggetti e classi e assegnazione
di responsabilità (Class Diagram e Interaction Diagram)
2
Introduzione ai Design Pattern

Chi progetta usa l’esperienza (personale e di
gruppo)


nella progettazione di un nuovo sistema sw si
riusano soluzioni progettuali già “sperimentate” in
passato
E’ importante
 Codificare
e registrare l’esperienza di soluzioni
di progettazione per poterla riusare
 Comunicare l’esperienza ad altri progettisti
 Apprendere dall’esperienza di altri progettisti
RDD
3
Introduzione ai Design Pattern

I Design Patterns sono emersi da alcuni anni come una delle
tecniche più efficaci per registrare e trasferire la conoscenza
e l'esperienza dei progettisti, rendendola disponibile in modo
comprensibile

Sono soluzioni comuni a problemi ricorrenti in un
contesto specifico

Aiutano a progettare “in modo giusto e in minor tempo”.

Nascono nel 1977 nel campo delle architetture edili
(Christopher Alexander) e si estendono alle architetture
software nel 1994 con il testo di Gamma, Helm, Vlissides e
Johnson “Design Patterns”, successivamente denominato
“Gang of Four” (GoF)
RDD
4
Design Pattern: definizione/vantaggi

Definizione: Un Pattern è costituito da



Descrizione del problema
Descrizione della soluzione in un contesto specifico
Vantaggi:






RDD
Facilitano il riuso di architetture e progetti validi
Catturano l’esperienza e la saggezza degli esperti
Permettono di evitare perdite di tempo nella ricerca di
soluzioni già esistenti
Creano un linguaggio che semplifica la comunicazione e la
comprensione tra gli addetti ai lavori (progettista-progettista,
progettista-sviluppatore, ….)
Supportano il lavoro in team
Incrementano la qualità del software: favoriscono il riuso, la
manutenibilità, l’estendibilità, la comprensibilità
5
Design Pattern: classificazione (1/2)




RDD
Design Patterns per la progettazione e lo
sviluppo del software
(modelli di progetto)
Analysis Patterns per definire modelli di
analisi riutilizzabili per problemi ricorrenti
(modelli di dominio)
Organization Patterns per definire
organizzazioni e progetti (modelli di
dominio)
Process Patterns per definire processi
(modelli di dominio)
6
Design Pattern: classificazione (2/2)

I Design Pattern possono essere classificati in funzione del loro
livello di astrazione/dettaglio
 Architectural Design Patterns

Descrivono l’organizzazione strutturale fondamentale di un sistema
software (architettura applicativa) in termini di
sottosistemi
 loro responsabilità e modalità di interazione
es: Uno dei design pattern architetturali classici prevede le archittetura a livelli


Design Patterns


Idioms o Coding Design Patterns

RDD
Forniscono uno schema per raffinare i sottosistemi o componenti di un
sistema software. In genere descrivono strutture di oggetti che
collaborano per risolvere un generico problema di progettazione in un
particolare contesto.
Pattern di basso livello specifico di un linguaggio di programmazione. Un
idioma descrive come implementare particolari aspetti dei componenti o
le relazioni tra essi utilizzando caratteristiche del linguaggio di
programmazione scelto.
7
Design Pattern: descrizione

Generalmente la descrizione di un pattern include:

Una descrizione del problema, tra cui:







RDD
un esempio concreto di problema
una soluzione specifica al problema concreto
Considerazioni che guidano alla formulazione di una
soluzione generica
Una soluzione generica
Le conseguenze, positive e negative, nell’utilizzare una
data soluzione per risolvere un problema
Un elenco di pattern simili
I cataloghi di pattern contengono schede
contenenti le informazioni sopra elencate, per ogni
pattern
8
Tipica scheda pattern


Pattern Name
Synopsis


Context


Codice di esempio che mostra un semplice utilizzo pratico del pattern
Related Patterns

RDD
Presentazione degli aspetti da considerare in fase di implementazione
In alcuni casi, descrizioni di varianti e/o semplificazioni
Code Example


Spiegazione delle implicazioni, positive e negative, nell’utilizzo del
pattern
Implementation



Descrizione di una soluzione generica al problema che il pattern risolve
Consequences


Riassunto delle considerazioni che conducono alla soluzione generica
presentata nella sezione Solutions
Solution


Descrizione del problema che il pattern risolve
Forces


Esposizione sintetica e sistematica del pattern
Elenco di pattern in qualche modo correlati
9
Progettazione guidata dalle responsabilità

Metafora OO-mondo reale: si pensi agli oggetti software come
a delle persone che hanno delle responsabilità e che collaborano
con altre persone per svolgere un lavoro

RDD (Responsibility – Driven – Design)


gli oggetti software sono dotati di responsabilità (ciò che fanno o
conoscono)
2 tipi di responsabilità:

Di fare:



Di conoscere:




RDD
effettuare una azione (creare un oggetto, eseguire un calcolo,...)
di delegare una azione (provocare una azione in altri oggetti)
conoscere i propri dati privati
conoscere oggetti correlati
conoscere cose che può derivare o calcolare
I Design Pattern GRASP descrivono dei principi di base per
assegnare le responsabilità agli oggetti e sostenere RDD
10
Pattern GRASP


GRASP (General Responsibility Assignment
Software Patterns)
Pattern GRASP di base






Altri pattern GRASP




RDD
Creator
Expert
Low Coupling
Controller
High Cohesion
Polymorphism
Pure Fabrication,
Indirection
Protected Variations
11
Creator


Problema: Chi crea un oggetto A ?
Soluzione: Assegnare a B la responsabilità
di creare un oggetto A se si verifica una
delle seguenti condizioni.
B
contiene o aggrega oggetti di tipo A
 B registra A
 B utilizza A
 B possiede i dati per inizializzare A

RDD
Nel caso non sia presente ancora nessuna
classe ci si ispira al modello di dominio per
ottenere una configurazione creatore-creato
con LRG basso (Low-Representional-Gap)
12
Creator – esempio 1
Modello di dominio
Studio di Caso
Monopoly

Chi crea Square ?

Per Creator è Board
Board contiene oggetti
Square
 Per LRG si introducono le
classi software Board e
Square

RDD
Modello di progetto
13
Creator – esempio 2
Sale
Studio di Caso POS

time
Chi crea
SalesLineItem ?
Modello di dominio
1
Contains
1..*
Sales
LineItem
*
Described-by
description
price
itemID
quantity

Per Creator è Sale
Sale contiene oggetti
SalesLineItem
 Per LRG si
introducono le classi
software Sale e
SalesLineItem

RDD
: Register
: Sale
1
Product
Description
Modello di progetto
makeLineItem(quantity)
create(quantity)
: SalesLineItem
14
Creator – vantaggi e controindicazioni

Vantaggi
 Accoppiamento basso. L’atto della creazione della classe
A da parte della classe B non incrementa
l’accoppiamento in quanto la classe A deve essere già
visibile dalla classe B

Controindicazioni
 Può non essere conveniente applicarlo in alcuni casi. Es:
 si usano molte istanze di una stessa classe (es: una
classe pacchetto IP ricevuto) e si riciclano oggetti già
creati ma non più utilizzati invece di creare ulteriori
istanze
 la creazione non è banale e serve una classe di
supporto (helper) per eseguirla
RDD
15
Information Expert



Problema: Come assegnare responsabilità
agli oggetti ?
Soluzione: Assegnare una responsabilità alla
classe che possiede le informazioni per
soddisfarla (Expert)
Ricerca dell’Expert
 Si
ricerca nel modello di progetto
 Si crea ex-novo dal modello di dominio
RDD
16
Information Expert: esempio 1
Modello di dominio
Studio di Caso
Monopoly

Chi ha la responsabilità di
accedere ad una square
dato un nome ?

Per Expert è Board



RDD
Board aggrega oggetti
Square quindi
Board ha le informazioni su
tali oggetti (è l’Expert)
quindi
Board ha la responsabilità
di accedere a Square
Modello di progetto
17
Information Expert: esempio 2
Studio di Caso
Monopoly

Modello di dominio
Sale
time
Chi ha la responsabilità di conoscere
il totale della vendita ?
1
Contains
1..*

Per Expert è Sale



E’ necessario conoscere i totali
parziali
Per conoscere i totali parziali occorre
conoscere i SalesLineItem
Sale conosce i SalesLineItem (perchè
li aggrega) quindi è l’Expert
t = getTotal
Sales
LineItem
*
Described-by
Product
Description
1
description
price
itemID
quantity
Modello di progetto
Sale
:Sale
time
...
NUOVO METODO
New method
RDD
getTotal()
18
Information Expert: esempio 2
Studio di Caso
Monopoly

Modello di dominio
Sale
time
Chi ha la responsabilità di conoscere
i totali parziali ?
1
Contains
1..*

Per Expert è SalesItem


Sales
LineItem
E’ necessario conoscere quantity
(SalesLineItem) e price
(ProductDescription)
SalesLineItem conosce quantity e
ProductDescription quindi è l’Expert
*
Described-by
1
Product
Description
description
price
itemID
quantity
Modello di progetto
this notationsu
willtutti
implygli
we
iterazione
are iterating
overcollezione
all
elementi
della
elements of a collection
Sale
time
...
t = getTotal
: Sale
1 *: st = getSubtotal
lineItems[ i ] :
SalesLineItem
getTotal()
SalesLineItem
NUOVO METODO
RDD
New method
quantity
getSubtotal()
19
Information Expert: esempio 2
Modello di progetto
Studio di Caso
Monopoly
time
...
t = getTotal

Sale
1 *: st = getSubtotal
: Sale
Chi ha la responsabilità di conoscere
il prezzo di un prodotto ?
lineItems[ i ] :
SalesLineItem
1.1: p := getPrice()
getTotal()
SalesLineItem
quantity

:Product
Description
Per Expert è ProductDescription

Product
Description
ProductDescription conosce price
quindi è l’Expert
NUOVO METODO
Modello di dominio
Sale
getSubtotal()
New method
description
price
itemID
getPrice()
time
1
Contains
1..*
Sales
LineItem
quantity
RDD
*
Described-by
1
Product
Description
description
price
itemID
20
Information Expert: il principio di
“animazione”

L’assolvimento di una responsabilità spesso richiede
informazioni sparse tra diversi oggetti (vedi es. precedente)

Uno degli oggetti inizia una collaborazione con gli oggetti che
possiedono le informazioni parziali (es: Sale con
SalesLineItem e ProductDescription) per assolvere alla
responsabilità complessiva

Nel mondo reale una vendita non dice il proprio valore perchè
è un oggetto inanimato.Per il principio di animazione nella
programmazione OO tutti gli oggetti sono “vivi” o “animati” e
fanno cose relative alle informazioni di cui sono a conoscenza
RDD
21
Information Expert: vantaggi e
controindicazioni

Vantaggi


Supporta High Coesion e Low Coupling
Controindicazioni

In alcuni casi si può avere un conflitto con altri 2 principi: High
Coesion e Low Coupling. Es:



RDD
Chi è responsabile di salvare in un database le informazioni di una
Sale ?
Per Expert è la classe Sale ma in questo modo si diminuisce la
coesione funzionale di Sale (Sale si occupa di aspetti tecnici come il
salvataggio su un DB) e si aumenta il suo accoppiamento (cfr. più
avanti nelle slide)
In tali casi non va applicato
22
Coupling

Coupling (Accoppiamento)
E’ una misura di quanto un elemento (classe, package,
sottosistema, strato) sia connesso, abbia conoscenza e sia
dipendente da altri elementi
 L’accoppiamento va ridotto al minimo necessario per aumentare




La manutenibilità (ridurre l’impatto dei cambiamenti)
La riusabilità
Comprensibilità dei singoli elementi indipendentemente
La classe A è accoppiata alla classe B.
Infatti:
•A dipende da B (l’operazione doX di A
dipende dalle operazioni doA,doB,doC di
B)
•Cambiamenti di comportamento delle
operazioni doA, doB o doC provocano
cambiamenti di comportamento di doX
•Il riuso della sola classe A non è
possibile, è necessaria anche la classe B
RDD
A
B
23
Coupling

Coupling (Accoppiamento)

In un sistema software gli elementi collaborano tra loro
(per il principio di animazione) quindi è normale che
dipendano gli uni dagli altri. In conclusione:
l’accoppiamento è necessario ma va mantenuto il più
basso possibile

Nella programmazione OO le forme più comuni di
accoppiamento tra due tipi TypeX e TypeY sono:





RDD
TypeX ha un attributo TypeY o referenzia un istanza TypeY
Un oggetto TypeX richiama servizi di un oggetto TypeY
TypeX ha un metodo che referenzia oggetti di tipo TypeY
(variabili locali, parametri o tipi ritornati)
TypeX è una sottoclasse diretta o indiretta
TypeY è un interfaccia e TypeX implementa direttamente o
indirettamente questa interfaccia
24
Low Coupling (accoppiamento basso)


Problema: come ridurre l’impatto dei
cambiamenti, aumentare manutenibilità e
riusabilità ?
Soluzione:
 Assegnare
la responsabilità in modo che
l’accoppiamento rimanga basso.
 Usare questo principio per valutare le
alternative progettuali. A parità di altre
condizioni si consideri il progetto con minore
accoppiamento
RDD
25
Low Coupling: esempio 1
Studio di Caso
Monopoly
Problema: dato un nome
di una Square chi deve
avere la responsabilità di
restituire la Square
corrispondente ?
1° Soluzione (Poor Design)
Si crea una classe
arbitraria (Dog) a cui si da
questa responsabilità
Dog è accoppiato sia a
Board che a Square.
(accoppiamento a 2 classi)
2° Soluzione
Si applica Expert.
Chi ha le informazioni per
assolvere alla
responsabilità ? Board.
Board è accoppiato a
Square (accoppiamento a
1 classe)
RDD
26
Low Coupling: esempio 2
Studio di Caso POS
Problema: Chi deve creare
un Payment ?
1° Soluzione
Per Creator è Register.
Register risulta accoppiato
a 2 classi (Payment e Sale)
makePayment()
1: create()
: Register
p : Payment
2: addPayment(p)
2° Soluzione
Tale soluzione sostiene
Low Coupling e quindi è
migliore
makePayment()
: Register
:Sale
1: makePayment()
:Sale
1.1. create()
:Payment
RDD
27
Low Coupling: vantaggi e controindicazioni

Vantaggi (di un elemento con Low Coupling)




Controindicazioni


RDD
Riusabilità
Indipendenza dai cambiamenti di altri elementi
Comprensibilità indipendentemente da altri elementi
Un accoppiamento alto di un elemento A con B non è un
problema se A è consolidato (non instabile) e pervasivo
(es: classi java.util)
Applicare Low Coupling principalmente con gli elementi
inerentemente instabili (es: UI)
28
Controller

Problema: Qual’è il primo oggetto oltre allo strato UI a ricevere e
coordinare (“controllare”) una operazione di sistema ?
1) Modello dei casi
d’uso, SSD per il
gioco del monopoly
2) Dal Modello dei Casi
d’Uso al Modello di
Progetto (“zoom” su
System per playGame):
Per il principio di
separazione modellovista gli oggetti dell’UI
Layer non devono
avere logica
applicativa ma
delegare le richieste al
domain layer. Qual’è il
primo oggetto del
domain layer che
riceve la richiesta ?
Board ? Square ? ....
RDD
:System
29
Controller

Soluzione:Assegnare la responsabilità ad un oggetto che
rappresenta una delle seguenti scelte:

Facade Controller: L’oggetto deve rappresentare il “sistema”
complessivo, un oggetto radice o un dispositivo fisico nel quale
viene eseguito il software.
il sistema complessivo

Controller di caso d’uso o di sessione: L’oggetto deve
rappresentare uno scenario di caso d’uso all’interno del quale è
presente l’operazione di sistema. L’oggetto viene chiamato
<nome>Handler, <nome>Coordinator o <nome>Session.

RDD
Es: il caso d’uso in cui si verifica playGame e chiamato
PlayMonopolyGame. Il Controller sarà PlayMonopolyGameHandler o
PlayMonopolyGameSession
30
Controller: esempio 1
Studio di Caso POS
Problema: chi è il
controller dell’operazione
di sistema enterItem ?
presses button
: Cashier
actionPerformed( actionEvent )
UI Layer
:SaleJFrame
Operazione
di sistema
system operation message
enterItem(itemID, qty)
Domain
Layer
: ???
class of object shoulddibericevere
responsible for
receiving this
Qual’èWhich
la responsabile
questo
system event message?
messaggio ?
It is sometimes called the controller or coordinator. It does not
normally do the work, but delegates it to other objects.
Il controller
non esegue il lavoro ma delega
a suaThe
volta
controller is a kind of "facade" onto the domain layer from
the interface layer.
1° Soluzione: Register, un
dispositivo fisico su cui
viene eseguito il sw
2° Soluzione:
ProcessSaleHandler, un
controller di caso d’uso
RDD
E’ una sorta di Facade
enterItem(id, quantity)
enterItem(id, quantity)
:Register
:ProcessSaleHandler
31
Controller: esempio 1
Studio di Caso POS
System
endSale()
enterItem()
makeNewSale()
makePayment()
makeNewReturn()
enterReturnItem()
...
Operazione di sistema
system
operations
identificate
durante
l’analisi
discovered during system
degli SSD
behavior analysis
Register
endSale()
enterItem()
makeNewSale()
makePayment()
makeNewReturn()
enterReturnItem()
...
1° Soluzione:
Facade
allocation of system
operations during design,
Controller
using one facade controller
ProcessSale
Handler
System
endSale()
enterItem()
makeNewSale()
makePayment()
enterReturnItem()
makeNewReturn()
...
HandleReturns
Handler
...
...
endSale()
enterItem()
makeNewSale()
makePayment()
enterReturnItem()
makeNewReturn()
...
2° Soluzione: Controller di
allocation of system
caso
d’uso
operations during design,
using several use case
controllers
RDD
Controindicazioni: se le
operazioni sono troppe si ha
un conflitto con High
Coesion. Da usare se ci sono
poche operazioni !
...
Attenzione: non corrisponde
a nessuna classe concettuale
(“Pure Fabrication”)
32
Coesion

Coesion (Coesione)

E’ una misura di quanto sono correlate le operazioni di un
elemento (classe, package, sottosistema, strato) dal punto di
vista funzionale. Es:


RDD
Oggetto Big, 100 metodi molto diversi per tipo di responsabilità (es:
accesso ai db, log, calcoli matematici) è poco coeso ovvero poco
“focalizzato” dal punto di vista funzionale
Oggetto Small, 10 metodi con un solo tipo di responsabilità (calcoli
matematici) è molto coeso
33
High Coesion


RDD
Problema: Come mantenere gli oggetti
focalizzati, comprensibili e gestibili e, come
effetto collaterale, sostenere Low Coupling
Soluzione: Assegnare le responsabilità in
modo che la coesione rimanga alta. Usare
questo principio per valutare alternative di
progetto
34
Coesione, Accoppiamento e Modularità

Modularità
 La
modularità è la proprietà di un sistema
decomposto in un insieme di moduli coesi e
debolmente accoppiati

Mutua influenza di coesione e accoppiamento
 Generalmente
alta coesione produce basso
accoppiamento e viceversa
RDD
35