Pattern

Pattern
Corso di ingegneria del software
Definizione
• Pattern software
– la descrizione strutturata di una soluzione
esemplare ad un problema (software)
ricorrente
Cluster
• Non tutti i pattern sono uguali
– possono essere strutturati e organizzati.
• Esistono diverse tipologie di pattern in funzione della loro area di
applicazione,
– in generale essi possono essere raggruppati in macrocategorie
specifiche (dette anche cluster), ciascuna delle quali contenente
pattern orientati a risolvere problematiche similari.
– I cluster possono a loro volta essere suddivisi in sottocategorie a
granularità più bassa.
• Oltre che l’appartenenza ad un determinato cluster, per un pattern è
possibile considerare anche il livello di astrazione che lo
contraddistingue.
• Nell’ambito del cluster dei pattern relativi allo sviluppo di applicazioni
software possiamo individuare tre categorie di pattern caratterizzate
da un diverso livello di astrazione.
Categorie di pattern
•
Pattern architetturali (stili architetturali): descrivono lo schema
organizzativo della struttura che caratterizza un sistema software.
– In genere individuano le parti del sistema a cui sono associate responsabilità
omogenee e le relazioni che esistono tra i diversi sottosistemi.
•
Pattern di disegno (design pattern): sono i pattern che si riferiscono alle
problematiche legate al disegno object-oriented
– forniscono uno schema per raffinare gli elementi di un sistema software o le
relazioni tra di essi
– descrive una struttura che ricorre comunemente di elementi di progetto
interconnessi, che risolvono un problema di progettazione generale in un
contesto particolare
•
Pattern di implementazione (idiomi): sono pattern di basso livello specifici
per una particolare tecnologia (per esempio, il .NET Framework, J2EE).
– descrivono le modalità implementative da utilizzare per risolvere problematiche di
sviluppo sfruttando in modo mirato le caratteristiche peculiari di una particolare
piattaforma.
Osservazioni
• Ciascuna categoria è caratterizzata da un grado
di astrazione differente.
– I pattern architetturali sono troppo generici per essere
orientati a risolvere problematiche di disegno
– I pattern idiomatici, molto legati alla tecnologia a cui si
riferiscono e all’implementazione vera e propria.
– I design pattern descrivono soluzioni che lasciano
sempre e comunque un certo grado di libertà nella
loro adozione e implementazione,
• non descrivono mai soluzioni che sono valide per una
piattaforma specifica,
• hanno una validità più generale e trasversale rispetto alla
tecnologia.
Pattern language
• L’architetto Christopher Alexander nel suo libro A Pattern
Language, scrive
– "ogni pattern descrive un problema che si ripete più e più volte nel
nostro ambiente, descrive quindi il nocciolo della soluzione del
problema, in modo tale che la soluzione possa essere usata un milione
di volte, senza che essa venga mai applicata nella stessa maniera".
• il concetto che sta alla base dei pattern è quello di fornire una
soluzione ad un problema in un determinato contesto.
• Nel caso della progettazione del software, questo significa
individuare meccanismi e tecniche che permettano di risolvere
problematiche ricorrenti in modo elegante, riusabile ed efficace.
Design pattern
•
In genere un design pattern è caratterizzato da quattro elementi
fondamentali.
– Nome: descrive sinteticamente le funzionalità di un pattern. Associare un nome
ad un pattern permette di identificarlo in modo semplice ed immediato e
consente di condividere le idee di disegno ad un livello più alto di astrazione,
senza la necessità di dover entrare nei dettagli implementativi.
– Problema: descrive la situazione alla quale applicare il pattern e le condizioni
necessarie e propedeutiche all'utilizzo del pattern stesso.
– Soluzione: descrive in modo astratto come il pattern risolve il problema,
specificando gli elementi coinvolti con le loro responsabilità e collaborazioni. La
soluzione viene solitamente espressa in modo sufficientemente generale da
lasciare numerosi gradi di libertà nelle possibili scelte implementative. Un pattern
infatti è come uno schema che può essere applicato ripetutamente, il più delle
volte in modo particolare e differente.
– Conseguenze: descrive l'insieme dei risultati e dei vincoli a cui si va incontro
nell'applicazione del pattern. Le conseguenze sono fondamentali per poter
valutare i vantaggi e gli svantaggi derivanti dall'uso del pattern e per poter
eventualmente preferire soluzioni alternative per la risoluzione del problema.
Design pattern
• Un design pattern associa un nome identificativo
ad un problema di progettazione,
– permette di identificare gli elementi che concorrono a
definire la struttura ad oggetti a cui il pattern si
riferisce
– per ciascun elemento individuato, specifica il ruolo, le
collaborazioni e le dipendenze con altri oggetti e, in
generale, le responsabilità ad esso attribuite.
• Ciascun design pattern è focalizzato su una
particolare problematica di disegno e per essa
specifica i possibili scenari di utilizzo,
evidenziandone i vincoli e le conseguenze.
Vantaggi nell’uso di pattern
• soluzione provata e ben compresa, che definisce i
principi organizzativi del sistema
• più facile comprendere l’architettura e le sue
caratteristiche
– ovvero il modo in cui sono controllate le varie qualità
• Possibili usi degli stili architetturali
–
–
–
–
soluzione di progetto per il sistema in discussione
base per l’adattamento
ispirazione per una soluzione correlata
motivazioni per un nuovo stile
Notazione
I pattern architetturali propongono criteri di decomposizione
di un sistema in elementi architetturali (macro-elementi)
È possibile usare un linguaggio di modellazione ad oggetti
– ad es., OMT o UML
• gli elementi architetturali non sono mai degli oggetti sono
piuttosto dei “macro-oggetti”
• tuttavia, è comune che ciascun elemento abbia
–
–
–
–
un nome/riferimento
un’interfaccia pubblica – descrive i servizi che offre
un’implementazione privata
ed è comune che le interazioni tra elementi siano mostrati da
uno scambio di messaggi (sincroni oppure asincroni)
• Una notazione ad oggetti è adeguata, ma i rettangoli
indicano elementi architetturali, non oggetti
Pattern architetturali
•
From Mud to Structure
–
–
Garantire una struttura organizzata
Supportano nella decomposizione di un sistema in sottosistemi
•
•
Distributed Systems
–
forniscono un’infrastruttura per applicazioni distribuite
•
•
Pattern: Broker
Interactive Systems
–
–
per strutturare sistemi software che prevedono un’interazione uomo-macchina
Supportano la progettazione dell’interazione uomo-macchina
•
•
Pattern: Layers, Pipes and Filters, Blackboard, SharedRepository, Database Access Layers(DAL),
DomainObject, Domain model
pattern: Model View Controller (MVC) e Presentation Abstraction Control (PAC)
Adaptable Systems
–
–
Supportano l’estendibilità per evoluzione tecnologica o cambiamento dei requisiti funzionali
Contiene i pattern: Reflection e Microkernel.
[Pattern-Oriented Software Architecture - A System of Patterns” Frank Buschmann,
Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael StalWiley and Sons Ltd.]
Osservazioni
• I pattern non sono tra loro indipendenti
– alcuni pattern sono alternativi – uso uno
oppure l’altro
– altri pattern sono sinergici – se uso uno è utile
usare anche l’altro
– altri possono essere usati in gruppi più
complessi
• utile ragionare anche sulle relazioni tra
pattern
Pattern language
Un pattern language (linguaggio di pattern)
– una famiglia di pattern correlati
– con una discussione sulle loro correlazioni
• ne esistono diversi – specifici per la
progettazione di certi tipi di sistemi o per
certi tipi di requisiti
– ad es., linguaggio di pattern per la sicurezza
– ad es., linguaggio di pattern per sistemi
distribuiti
Layers
• Divide le funzionalità in livelli separati ogni
livello contiene un insieme di funzionalità e
dipende dai servizi forniti dal livello
inferiore
• È possibile modificare un livello senza
modificare gli altri
Domain model
• Assimilabile al modello concettuale nel
progetto di un sistema
Domain object
• guida la decomposizione di elementi
architetturali più grandi
– ad es., uno strato di un’architettura secondo Layers
• Si basa sul Principio di Separazione
degli Interessi e la Modularità
• La decomposizione può essere guidata da un
modello del dominio (casi d’uso, requisiti non
funzionali, requisiti informativi, ecc.)
Model View Control (MVC)
• Separa i dati dell’applicazione (contenuti
nel modello) dai componenti per la
presentazione grafica (vista) e la logica
per l’elaborazione dell’input (il controllore)
Model view control
Pattern MVC
notifica
modifica
controllore
modello
vista
Pipe and filter
• Fornisce una struttura per sistemi che devono
elaborare flussi di dati
– l’elaborazione è decomposta in passi di elaborazione
– ciascun passo di elaborazione è incapsulato in un
componente filtro
• i dati sono trasferiti tra filtri adiacenti mediante
pipe (tubi)
• è possibile costruire famiglie di sistemi correlati
mediante un’opportuna combinazione di filtri e
pipe – pipeline
Shared repository
• Usato per applicazioni data-intensive in cui le
interazioni tra le componenti del sistema non sono
guidate da processi specifici mapossono essere
coordinate sulla base dei dati condivisi su cui operano
• Mantiene i dati in un repository centrale condiviso da
tutti i componenti funzionali del sistema e fa guidare e
coordinare il flusso di controllo della logica applicativa
dalla disponibilità qualità e stato dei dati nel repository
• L’accesso ai dati gestiti dal repository condiviso
dovrebbe essere opportunamente sincronizzato
• È un punto d’accesso a dati condivisi( es. un database
relazionale, una collezione di oggetti in memoria, ecc.)
Database access layer (DAL)
• Guida la connessione tra elementi architetturali
sviluppati con tecnologia orientata agli oggetti
e una base di dati relazionale
• Introduce uno strato separato per l’accesso alla
base di dati (database access layer) tra
l’applicazione e la base di dati relazionale
– questo strato fornisce all’applicazione un’interfaccia
per l’accesso ai dati stabile ed orientata agli oggetti
(operazioni CRUD -Create, Read, Update, Delete)
– Il DAL traduce operazioni CRUD in istruzioni SQL e si
occupa di altri aspetti quali concorrenza, transazioni,
caching, accesso a DBMS diversi,ecc.
Pattern DAL
Blackboard
• Il pattern Blackboard
– è utile in problemi per cui non esistono
strategie di risoluzione deterministiche.
– prevede diversi sottosistemi specializzati che
usano la loro conoscenza per costruire
insieme una soluzione parziale o
approssimata
• Esempio: Vision, Image Recognition,
Speech Recognition
Broker
• Il pattern Broker può essere usato per strutturare
sistemi software distribuiti con componenti tra
loro disaccoppiati che interagiscono tramite
invocazioni di servizi remoti.
• Un componente broker è responsabile di
coordinare la comunicazione: inoltrare richieste
e trasmettere risultati ed eccezioni.
• (architettura ad oggetti distribuiti)
Microkernel
• sviluppo di un insieme di applicazioni variazioni l’una
dell’altra basate sulla stessa architettura e con un unico
nucleo funzionale
• le diverse applicazioni sono costruite in sede di
deployment
– alcune applicazioni devono esistere in versioni multiple
– si differenziano, ad esempio, nelle funzionalità specifiche offerte
o nell’interfaccia utente
• tutte le versioni delle applicazioni dovrebbero essere
basate su una stessa architettura comune ed uno stesso
nucleo funzionale comune
Reflection
• fornisce un meccanismo per cambiare la
struttura e il comportamento di un sistema in
modo dinamico
• consente la modifica di aspetti fondamentali, ad
es., delle strutture di dati e dei meccanismi di
comunicazione
– Suddivide il sistema in due parti mediante
un’architettura a due livelli che separa i metadati della
logica applicativa fondamentale dell’applicazione
– un meta-livello: contiene i meta-dati
– un livello base: comprende la logica applicativa la cui
implementazione è basata sul meta-livello