Architectural Patterns per
Applicazioni di tipo Enterprise
Jürgen Assfalg
17 marzo 2004
1
Alcune domande
●
Cos'è un'architettura?
●
Cos'è un'applicazione di tipo enterprise?
2
Cos'è l'architettura?
Anche nel suo contesto originario, il termine
“architettura” non ha un significato ben
definito.
Infatti, può essere inteso come
–
L'architettura di un particolare edificio
i disegni che ne descrivono il progetto
–
Uno stile architettonico
es. “architettura gotica”
–
Lo studio dell'architettura
es. “Luigi ha conseguito la laurea in architettura”
3
Cos'è un'architettura software?
Analogamente, non esiste una definizione
chiara, precisa, ed universalmente accettata
di “architettura software”
Questo, nonostante i numerosi sforzi profusi
nell'individuare una definizione del termine,
anche a livello normativo
4
Cos'è un'architettura software?
Perry+Wolf, 1992:
Insieme di elementi architetturali (processing
elements, data elements, connecting
elements), che hanno una forma particolare
(proprietà e relazioni dell'elemento, cioè i
vincoli), spiegati da una serie di
motivazioni.
Si noti come, questa definizione, a differenza di altre
che vedremo, prende esplicitamente in
considerazione i dati.
5
Cos'è un'architettura software?
Garlan+Swan, 1993:
Insieme di componenti computazionali,
insieme ad una descrizione delle
interconnessioni tra componenti
(connectors).
L'architettura si occupa di aspetti che vanno oltre gli
algoritmi e le strutture dati.
L'architettura si riguarda aspetti macroscopici,
mentre algoritmi e strutture dati si riferiscono ad
aspetti microscopici.
6
Cos'è un'architettura software?
Abowd et al., 1995:
Descrizione di un sistema in termini di 3 classi
di base: componenti, connettori e
configurazioni.
–
–
Configurazioni: insiemi di componenti e connettori
che caratterizzano una determinata topologia
attiva
L'architettura rappresenta quindi un'astrazione del
comportamento in fase di esecuzione.
7
Cos'è un'architettura software?
Booch+Rumbaugh+Jacobson, 1999:
L'architettura è un insieme di decisioni
significative circa l'organizzazione di un
sistema, la selezione degli elementi
strutturali e delle loro interfacce, circa il
comportamento specificato dall'interazione
tra gli elementi, circa la composizione di
questi aspetti in sistemi di dimensione
crescente, e lo stile architetturale che
guida quest'organizzazione.
8
Cos'è un'architettura software?
ANSI/IEEE Std 1471-2000:
L'architettura è definita come l'organizzazione
fondamentale del sistema, materializzata nei
suoi componenti, le relazioni tra di loro e con
l'ambiente, e i principi che ne governano il
suo progetto e la sua evoluzione.
9
Cos'è un'architettura software?
Bass+Clements+Kazman, 2003:
L'architettura software di un programma o di
un sistema di elaborazione è la struttura (o
le strutture) del sistema, che comprende gli
elementi software, le loro proprietà visibili
all'esterno, e le loro reciproche relazioni.
10
Un'architettura software è...
Architettura software: astrazione del
comportamento a run-time di un sistema
software durante una qualche fase operativa.
Consiste di componenti, dati, una
configurazione, e un insieme di proprietà
architetturali
11
Un'architettura software è...
Componente: unità software astratta che
fornisce una trasformazione di dati attraverso
la sua interfaccia
Connettore: meccanismo astratto che media
la comunicazione, coordinazione o
cooperazione tra componenti
Dato: unità d'informazione ricevuto o inviato
da un componente
12
Un'architettura software è...
Configurazione: struttura delle relazioni
architetturali tra componenti, connettori e dati
durante un periodo di esecuzione
Proprietà architetturali: sono quelle proprietà
che derivano dalla selezione e dalla
composizione di componenti, connettori e
dati
13
Obiettivi delle architetture
L'utilizzo sistematico delle architetture
software può avere ricadute positive su:
–
Comprensione, in quanto consentono la
descrizione di un sistema ad un livello di
astrazione elevato
–
Riuso, a diversi livelli
–
Evoluzione, in quanto può identificare le
dimensioni lungo le quali ci si attende che un
sistema evolva
–
Analisi
14
Architectural styles
Uno stile architetturale caratterizza una
famiglia di sistemi che condividono proprietà
strutturali e semantiche [Monroe et al., 1997]
Rappresenta un'astrazione dei tipi degli
elementi e degli aspetti formali di diverse
specifiche architetture [Perry+Wolf, 1992]
È un modello di interazione fra componenti
tipizzati [Garlan+Swan, 1993]
–
Lo stile definisce i vincoli, il vocabolario dei
componenti e dei connettori che possono essere
utilizzati nelle sue istanze.
15
Architectural patterns
Dallo stile al pattern, il passo è breve...
Un pattern architetturale esprime
un'organizzazione fondamentale della
struttura o lo schema di un sistema software.
Definisce un insieme di sotto-sistemi
predefiniti, specifica le loro responsabilità, e
include regole e linee guida per organizzare
le relazioni tra di loro. [Buschmann+al., 1996]
16
Architectural patterns
Sono utilizzati per risolvere risolvere problemi
quali:
–
Persistenza
–
Concorrenza
–
Distribuzione
–
Presentazion
–
Sessioni
17
Architectural patterns
Volendo semplificare:
un architectural pattern sta alla
comprensione del sistema come un design
pattern sta alla comprensione di un
componente.
AP : sistema = DP : componente
Arch. Styles vs Patterns: v. PoSA 1, pp. 39518
Layers
Descrizione: il pattern architetturale layers
(livelli) aiuta a strutturare le applicazioni che
possono essere scomposte in gruppi di
sotto-compiti, in cui ogni gruppo rappresenta
un livello di astrazione
Problema: sistema la cui caratteristica
dominante è un insieme di problematiche di
basso ed alto livello, e in cui le operazioni di
alto livello ne richiedono altre di basso livello
19
Layers
alto
livello
richiesta
risposta
dati
notifica evento
basso
livello
Forces:
–
–
–
–
Minimizzare gli effetti dei cambiamenti del codice
in uno stato avanzato dello sviluppo
Stabilità delle interfacce
Intercambiabilità di parti del sistema
Raggruppamento di funzioni simili per agevolare
comprensione e manutenzione
20
Layers
Soluzione: definizione di un numero
appropriato di livelli (dal basso verso l'alto il
livello di astrazione cresce)
Classe
Collaboratori
Livello J
Livello J-1
Responsabilità
●fornisce servizi al
livello J+1
●delega servizi al
livello J-1
21
Layers
Implementazione: v. Buschmann et al.
Varianti
–
Relaxed layered system
il livello J non maschera i livelli sottostanti, e quindi sono
possibili scorciatoie)
–
Layering through inheritance
Usi conosciuti
–
–
–
Virtual Machines (VMs)
Application Programming Interfaces (APIs)
Sistemi operativi
22
Layers
Vantaggi:
–
unità coerenti
–
riutilizzo dei livelli
–
supporto alla standardizzazione
–
località delle dipendenze
–
interscambiabilità
Svantaggi:
–
propagazione a cascata dei cambiamenti
–
riduzione dell'efficienza
–
difficoltà nello stabilire il livello di granularità
23
Progetto di un'architettura
Numerosi fattori condizionano la progettazione
dell'architettura:
il compito da svolgere (requisiti funzionali)
– il contesto (utenti, sistemi ed infrastruttura
esistenti)
– le tecnologie che si intendono utilizzare
– i requisiti qualitativi
– ...
La scelta dipende molto dal contesto.
–
Si devono inoltre individuare metodi/strumenti per
valutare le diverse alternative.
24
Applicazioni di tipo enterprise
Applicazioni aziendali, o anche sistemi
informativi, oppure ancora elaborazione dati
–
–
–
–
–
–
Molti dati persistenti
Accesso concorrente da parte di più utenti
Molte maschere di immissione dati
Integrazione con altre applicazioni
Dissonanza concettuale
Logica applicativa complessa e “illogica”
25
Applicazioni di tipo enterprise
Diverse tipologie:
–
Business to consumer (B2C)
utilizzata da soggetti esterni all'organizzazione
es. commercio elettronico, prenotazione voli, ...
–
Business to business (B2B)
scambio dati senza intervento umano
es. gestione magazzino, pagamento elettronico
–
Back-end
eseguita periodicamente senza input diretto
es. telecomunicazioni, invio newletter
26
Applicazioni di tipo enterprise
Evoluzione delle architetture
–
monolitiche
incorporano tutte le routine per la gestione e la
manipolazione dei dati
–
client/server, o a 2 livelli
●
●
client: presentazione
server: sorgente dati (DBMS)
Client
GUI
ClientBusiness logic
GUI
Database logic
Business logic
Database
Server
SQL
Database logic
27
Applicazioni di tipo enterprise
Vantaggi
–
architettura semplice
Svantaggi
–
ridotta scalabilità
●
–
richiede elevata larghezza di banda
difficoltà di manutenzione
●
logica applicativa distribuita (fat client)
●
logica applicativa nel DBMS (stored procedures)
28
Model View Controller
Pattern architetturale che suddivide
applicazione interattiva in 3 componenti
–
modello: racchiude funzionalità e dati
–
vista: mostra le informazioni all'utente
–
controllore: gestisce l'input dell'utente
Vista e controllore insieme formano l'interfaccia
utente.
Meccanismo di propagazione dei cambiamenti
assicura consistenza di modello e vista.
29
Model View Controller
separazione di elaborazione, ingresso e uscita
–
separa interfaccia utente dal modello
–
separa controllore dalla vista
consistenza assicurata mediante pattern Observer,
che non viola separazione
View
Controller
Model
30
Model View Controller
Classe
Model
Collaboratori
●View
●Controller
Responsabilità
funzioni centrali
●registra componenti dipendenti
●notifica cambiamenti
●
Classe
View
Responsabilità
crea e inizializza
controllore
●presenta dati
●implementa procedura
aggiornamento
●recupera dati da modello
●
Collaboratori
●Controller
●Model
Classe
Controller
Responsabilità
Collaboratori
●View
●Model
accetta eventi in ingresso
●trasforma eventi in
richieste di servizio
●implementa procedura di
aggiornamento
●
31
Model View Controller
: Controller
: Object
: Model
registra( v )
crea
v : View
gestisci evento
servizio
notifica
aggiorna
visualizza
leggi dati
32
Model View Controller
N. Libri
Libro
Titolo
Autore
Titolo
N. pagine
Autore
N. pagine
Aggiungi
Controllore
Modello
33
Model View Controller
Vantaggi
–
più viste di uno stesso modello
–
viste sincronizzate
–
viste e controllori interscambiabili (pluggable)
–
look&feel interscambiabili
–
potenzialità per framework
34
Model View Controller
Svantaggi
–
maggiore complessità
–
rischio di elevato numero di aggiornamenti
–
accoppiamento stretto tra viste e controllori
–
accoppiamento stretto (delle interfacce) di viste e
controllori al modello (v. Command Processor)
–
possibile inefficienza nell'accesso ai dati
–
migrazione rende necessarie modifiche a viste e
codice
–
difficoltà di utilizzo con strumenti visuali per GUI
35
Architetture a 3 livelli
Quando la complessità della logica applicativa
(regole, validazione, calcoli) è cresciuta, si
sono identificati 3 livelli:
–
Presentazione
dei dati all'utente, ma anche ad un programma
–
Dominio
incorpora la logica applicativa
–
Sorgente dati
gestisce la persistenza dei dati
36
Architetture a 3 livelli
Solo lo sviluppo del web, e quindi la necessità
di evitare la replicazione della logica di
dominio in diverse interfacce, ha fatto
decollare lo sviluppo delle architetture a 3
livelli
In generale, si possono concepire applicazioni
a N livelli. Tuttavia, le architetture a 2 o 3
livelli coprono la maggior parte delle
applicazioni
37
Architetture a 3 livelli
Collocando i diversi livelli su diverse macchine
connesse in rete, si realizza un'architettura
distribuita
Si può distinguere tra
–
layer: indica il livello di un'architettura software
–
tier: indica la collocazione fisica
Problema: collocazione fisica dei livelli
–
reattività, operazioni non in linea
38
Architetture a 3 livelli
Client
Middle-tier
server
GUI
Database
Business logic
Client
Server
Database logic
GUI
RPC, DCOM, …
SQL
39
Integrazione di applicazioni
•
•
•
•
CORBA
JTAPI (interfaccia a IVR)
JTA
JMS
• ASP, COM/DCOM, DBMS, M$
• Servlet/JSP, EJB o CORBA,
DBMS, Unix/M$
• CGI, CORBA, Unix
40
Esempio: 35mm
Esaminiamo alcune problematiche legate alla
distribuzione, con riferimento ad
un'applicazione per la consultazione di
spettacoli cinematografici
41
Esempio: 35mm
Logica di dominio: rappresentazione
degli oggetti di interesse
Regista
nome
*
Programma
giorno
cinema
Spettacolo
inizio
* sala
Film
titolo
1 anno
durata
*
Attore
nome
42
Esempio: 35mm
Logica applicativa: visualizzazione delle
informazioni (es. in una pagina JSP)
Programma p = ... ;
for ( Iterator i = p.spettacoli(); i.hasNext; ) {
Spettacolo s = (Spettacolo) i.next();
Film f = s.film();
out.print( “inizio: ” + s.inizio() + “; film:”
+ film.titolo() + “\n cast: “ );
for ( Iterator j = f.attori(); j.hasNext(); ) {
Attore a = (Attore) j.next();
out.print( a.nome() + “ ” );
}
}
43
Esempio: 35mm
La soluzione proposta non presenta particolari
problemi se la logica dell'applicazione viene
eseguita nello stesso spazio di
indirizzamento in cui si trovano tutti gli
oggetti della logica di dominio
Logica di dominio
Logica applicativa
44
Esempio: 35mm
In un contesto distribuito, la logica applicativa
che si trova sul client, mantiene riferimenti
agli oggetti remoti della logica di dominio
Si ha un deterioramento delle prestazioni
Ogni invocazione di un metodo su oggetti remoti
della logica di dominio comporta notevoli ritardi
(marshalling dei parametri, latenza di rete, ...)
Logica applicativa
Logica di dominio
45
Data Transfer Object
È un oggetto che trasporta dati tra processi, in
maniera tale da ridurre il numero di chiamate
di metodi.
In genere trasporta più dati di quanti siano
effettivamente richiesti in un dato istante,
ma che potrebbero essere sufficienti per un
po' di tempo (principio di località?)
46
Data Transfer Object
Può essere anche utilizzato per aggregare
dati provenienti da più oggetti remoti
Utilizzando i DTO non è necessario replicare
l'intero Domain Model sul client
ProgrammaDTO
giorno
cinema
spettacoli
fromXML( : String) : self
toXML() : String
SpettacoloDTO
inizio
sala
*
registaFilm
titoloFilm
castFilm
fromXML( : String) : self
toXML() : String
47
Data Transfer Object
ProgrammaDTO p = ... ;
for ( Iterator i = p.spettacoli(); i.hasNext; ) {
SpettacoloDTO s = (SpettacoloDTO) i.next();
out.print( “inizio: ” + s.inizio() + “; film:”
+ s.titoloFilm() + “\n cast: “ );
for ( Iterator j = s.castFilm(); j.hasNext(); ) {
Attore a = (String) j.next();
out.print( a
}
+ “ ” );
}
48
Data Transfer Object
Questo pattern richiede meccanismi di
serializzazione, necessari per realizzare un
passaggio dei parametri per valore (aniziché
per riferimento)
Ci sono due possibilità
–
formato testuale (es. XML)
–
formato binario, più efficiente ma più “fragile”
49
Data Transfer Object
L'adozione di un DTO è consigliata,
indipendentemente dal protocollo usato (es.
RMI, CORBA, SOAP, ...)
Possibili alternative:
–
Utilizzare metodi get/set con molti parametri
non è sempre possibile, perché alcuni linguaggi (es.
Java) consentono la restituzione di un solo parametro
di ritorno
–
Utilizzare direttamente una rappresentazione sotto
forma di stringa, senza alcun oggetto d'interfaccia
no incapsulamento: più errori, manutenzione difficile
50
Data Transfer Object
Un elevato numero di invocazioni metodi su
un oggetto remoto è anche conseguenza
della granularità fine con cui vengono
progettate le classi
Film
Questo è una diretta
conseguenza delle
buone prassi di
OOD e OOP:
piccoli pezzi,
ricombinabili e
ridefinibili in vario modo
getTitolo() : String
setTitolo( : String)
attori() : Iterator
addAttore( : Attore )
removeAttore( : Attore )
registi() : Iterator
addRegista( : Regista )
removeRegista( : Regista )
...
51
Remote Façade
Definisce una facciata a grana grossa su un
oggetto a granularità fine, per migliorare
l'efficienza in un contesto distribuito
Consente di non dover dotare di un'interfaccia
remota i singoli oggetti della logica di
dominio
Non contiene alcuna logica di dominio
Può essere definita anche su un insieme di
oggetti a granularità fine, anziché su uno
solo
52
Remote Façade
Nei casi più semplici, la Remote Façade
sostituisce un insieme di metodi get/set a
grana fine con pochi metodi get/set a grana
grossa (bulk accessors)
FilmFacade
GetDatiFilm( : Id ) : Film
setDatiFilm( : Id, : Titoli, : Attori, : Registi, ...)
53
Remote Façade
: FilmFacade
: Film
GetDatiFilm( id )
getTitolo()
attori()
registi()
public FilmDTO getDatiFilm( int id ) {
return writeDTO( database.find( id ) );
}
54
Remote Façade
Se le classi della logica di
dominio sono presenti
FilmFacade
ad entrambi gli estremi, GetDatiFilm( : Id ) : Film
setDatiFilm( : Id, : Film)
per trasferire i dati in
blocchi, è sufficiente che
siano serializzabili
Altrimenti è necessario
ricorrere ai DTO
FilmFacade
getDatiFilm( : Id ) : FilmDTO
setDatiFilm( : Id, : FilmDTO )
55
Esempio: 35mm
«interface»
Remote
Logica di dominio
Remote Façade
35mmFacade
getProgramma() : ProgrammaDTO
getDatiFilm( : Id ) : FilmDTO
Logica applicativa
56
Esempio: 35mm
Grazie ad Internet, nella realizzazione di
un'applicazione ci si può avvalere di servizi
offerti da altri
35mm
?
MovieDB
Problemi:
–
individuare i servizi
–
integrarli senza “sporcare” la logica di dominio
57
Gateway
Un oggetto che incapsula l'accesso ad un
sistema o ad una risorsa esterni
Patterns analoghi
–
Facade, semplifica un'API complessa, ma in
genere è scritto da chi fornisce l'API stessa
–
Adapter, adatta l'implementazione di un'interfaccia
ad un'altra interfaccia. Nel caso del Gateway, in
genere non c'è un'interfaccia preesistente
–
Mediator, accoppia più oggetti, senza che questi
si debbano conoscere.
58
Esempio: 35mm
Logica di dominio Gateway
MovieDB
Remote Façade
DTO
Logica applicativa
59
Service Stub
Quando si sviluppa un sistema, è necessario
verificarne anche il corretto funzionamento
(testing).
Tuttavia, in certi casi, durante le sviluppo del
sistema alcuni dei servizi cui si appoggia
possono non essere disponibili (interruzione
di servizio, in fase di sviluppo, a pagamento)
Service Stub rimuove la dipendenza da servizi
problematici durante i test
60
Service Stub
Logica di dominio Gateway
MovieDB
Remote Façade
DTO
Logica applicativa
MovieDB Stub
«interface»
MovieDB
61
Registry
Un oggetto noto, che altri oggetti possono
utilizzare per individuare oggetti comuni e
servizi
Registry
register( : Key, : Server )
unregister( : Key, : Server )
lookup( : Key) : Server
62
Broker e/o Client-Dispatcher-Server/Service
Service Layer:
- semplificare la vita ad utenti esterni
- ottimo tra presentation e domain model, se in processi diversi
- non è necessario renderlo remoto
- stateful/stateless
63
