Stili Architetturali

Corso di Laurea Specialistica in Ingegneria Informatica
Corso di Ingegneria del Software
Stili Architetturali
E. TINELLI
A. A. 2008 - 2009
Architettura SW – Definizione e
Notazioni
Definizione
-2000
DefinizioneANSI/IEEE
ANSI/IEEEStd
Std1471
1471-2000
LL’organizzazione
’organizzazione basilare
omponenti,
basilaredi
diun
unsistema,
sistema,rappresentato
rappresentatodalle
dallesue
sueccomponenti,
dalle
ambiente circostante,
dallerelazioni
relazioni che
cheesistono
esistonotra
tradi
diloro
loroeecon
conl’l’ambiente
circostante,eedai
dai
principi
principiche
chegovernano
governanola
lasua
suaprogettazione
progettazioneeeevoluzione
evoluzione
• I sistemi più grandi sono eterogenei e non seguono un singolo
stile Æ uno stile è “dominante”
• Gli elementi architetturali (descritti generalmente come
rettangoli) non sono mai degli oggetti sono piuttosto dei
“macro-oggetti” caratterizzati da:
– un nome/riferimento
– un’interfaccia pubblica (che descrive i servizi che offre)
– un’implementazione privata
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
2
Pattern Architetturale
• Uno stile (o pattern) architetturale esprime una schema per
l’organizzazione strutturale fondamentale di sistemi software
• Descrive il modello organizzativo strutturale di un sistema software
in termini di: 1) sottosistemi e loro responsabilità; 2) linee guida per
organizzare le relazioni tra tali sotto sistemi.
• Ciascun pattern architetturale può essere descritto in termini di
contesto applicativo, soluzione proposta, discussione dei
punti di forza e svantaggi.
• N.B. - I pattern SW non sono tra loro indipendenti Æ alcuni
sono alternativi, altri sinergici Æ utile ragionare anche sulle
relazioni tra pattern
• Un pattern language (linguaggio di pattern) è una famiglia di
pattern correlati che risultano specifici per la progettazione di certi
tipi di sistemi o per certi tipi di requisiti
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
3
Un possibile catalogo di Pattern
• dal fango alla struttura
– per sostenere una decomposizione controllata del sistema complessivo
(decomposizione di un sistema in sottosistemi)
• Layers, Pipes-and-Filters, Blackboard, Shared Repository, Database
Access Layers (DAL), Domain Object
• sistemi distribuiti
– per fornire un’infrastruttura per applicazioni distribuite
• Client-server, Broker
• sistemi interattivi
– per strutturare sistemi software che prevedono un’interazione uomomacchina
• Model-View-Controller (MVC), Boundary-Control-Entity (BCE), BCEDbInterface (BCED)
• sistemi adattabili
– per sostenere l’adattamento del sistema – a fronte dell’evoluzione della
tecnologia e/o dei requisiti funzionali
• Reflection, Microkernel
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
4
Layers
• Si applica a grandi sistemi che si occupano della gestione di diversi aspetti e
richiedono modificabilità e portabilità
• Partiziona il sistema in una gerarchia di strati verticali:
– Ogni strato ha una responsabilità distinta e specifica
– Uno strato può comunicare solo con lo strato sottostante Æ uno strato fornisce
servizi allo strato superiore e richiede servizi allo strato inferiore
– Uno strato potrebbe essere:
• Un modulo – la comunicazione tra strati avviene come chiamate di
procedure (locali)
• Un processo - la comunicazione tra strati avviene utilizzando protocolli e
formati specifici (es. RPC, RMI, ecc)
• Diversi criteri di partizionamento:
–
–
–
–
Astrazione (presentazione, logica applicativa, dati persistenti);
Granularità (processi, servizi, moduli);
Distanza dall’HW;
Tasso di cambiamento atteso
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
5
Layers - Conseguenze
• Prestazioni
– funzionalità sono spesso implementate attraverso più strati: possono essere
richiesti diversi cambiamenti di contesto, penalizzando le prestazioni
– in alcuni casi è possibile migliorare le prestazioni associando un diverso
thread di esecuzione a ciascun evento che deve essere elaborato dal
sistema
– Può essere difficile stabilire la granularità/il numero/il livello di astrazione
degli strati
• Manutenibilità
– può essere alta se le dipendenze sono localizzate ma dipende da come i
cambiamenti si ripercuotono sul sistema Æ i cambiamenti dovrebbero essere
localizzati in singoli componenti/strati
– se le funzionalità del sistema non sono state organizzate rispetto ad alcuni
cambiamenti attesi, altri cambiamenti potranno riguardare molti strati con un
effetto domino
– Possibilità di riusare strati
• Sicurezza
– è possibile inserire strati che introducono opportuni meccanismi di sicurezza –
ad es., autenticazione, autorizzazioni, crittografia, ...
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
6
Object Model
• Guida la decomposizione di elementi architetturali più grandi (ad
es., uno strato di un’architettura secondo Layers) usando come
criteri base il 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.)
• Incapsula ciascuna responsabilità funzionale distinta di un sistema
in un elemento auto-contenuto – un oggetto di dominio
– ciascun elemento deve essere internamente coeso e debolmente
accoppiato agli altri elementi
– ciascun elemento deve avere un’interfaccia separata dalla sua
implementazione
– le collaborazioni tra gli elementi devono avvenire solo sulla base
della loro interfaccia
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
7
Shared Repository
• Usato per applicazioni data-intensive in cui le interazioni tra le
componenti del sistema non sono guidate da processi specifici ma possono
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.)
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
8
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.
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
9
Pipe-and-Filters
• Usato per un sistema che deve elaborare un flusso di dati (es.
compilatore) in cui l’elaborazione può essere organizzata in una
sequenza di trasformazioni:
– Filtro – consuma ed elabora dati in modo incrementale e svolge una
singola unità di elaborazione, è possibile avere più sorgenti dati
– Pipe (tubo) – collegano flussi di uscita con flussi di ingresso consecutivi
quindi definendo un preciso formato per i dati che possono attraversarle
connettono i filtri
• Conseguenze:
– La ricombinazione di filtri esistenti può portare alla definizione di nuove
pipeline di elaborazione
– È possibile l’elaborazione parallela e non sono necessari (ma possibili)
file intermedi
– Passi non consecutivi non condividono informazioni Æ difficile la
gestione degli errori, la condivisione di informazioni di stato
– Possibile overhead nella trasformazione dati inter-filtro
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
10
Client - Server
• Organizza un sistema come
– un insieme di servizi
• ciascun servizio è caratterizzato da un’interfaccia – definisce protocollo
e formato dei messaggi scambiati, meccanismi di connessione
tramite protocolli e porte
– un insieme server
• i server sono processi che erogano servizi
– un insieme di client
• i client sono processi fruitori di servizi
• i client sono attivi – i server reattivi
• un server può servire concorrentemente molti client
• Permette la condivisione di risorse, la centralizzazione
dell’elaborazione ma può verificare overhead della
comunicazione
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
11
Architetture Client – Server e Livelli
• Esistono diversi tipi di architetture client/server (C/S)
– le architetture C/S sono normalmente organizzate a livelli
– un livello (tier) corrisponde ad un nodo o gruppo di nodi di calcolo su cui è
distribuito il sistema Æ punto vista del deployment
– il sistema è organizzato come una sequenza di livelli
• ciascun livello funge da server per i suoi chiamanti nel livello precedente
• ciascun livello funge da client per il livello successivo
– i livelli sono comunemente organizzati in base al tipo di servizio (responsabilità)
che forniscono
• Si tratta di un’interpretazione particolare del pattern Layers in cui gli
strati corrispondono all’allocazione di server (processi) su nodi fisici:
• nella vista funzionale, il sistema adotta un’architettura a strati in cui gli strati sono
organizzati in base al livello di astrazione
• nella vista deployment, sistema adotta un’architettura a livelli in cui i livelli sono
organizzati in base al tipo di servizio (responsabilità) che forniscono
• ciascun livello è spesso internamente organizzato a strati
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
12
Client – Server a 2 livelli
• “thin client” - Maggior carico di comunicazione ma buona
portabilità, possibili buone prestazioni perché logica applicativa ed
acceso ai dati non sono separati, l’eventuale potenza di calcolo non
viene sfruttata
• “fat client” - Meno carico sul servente ma scarsa portabilità,
possibilità di distribuire il carico di elaborazione.
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
13
Client – Server a 3 livelli
• consente una migliore distribuzione del carico di elaborazione
• architettura più scalabile se aumenta il carico è possibile aggiungere nuovi
server mentre il livello intermedio può essere realizzato come un cluster di
calcolatori
• Presenta una maggiore complessità dell’architettura e un maggior
overhead nella comunicazione
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
14
Architettura ad oggetti distribuiti - Broker
• Costituisce un’infrastruttura di comunicazione che rende trasparenti
all’applicazione (ed al programmatore) alcune complessità della
distribuzione
• Introduce un componente broker per avere un miglior disaccoppiamento
tra client e server che offre mediante delle API funzionalità per registrare
servizi e richiedere l’esecuzione degli stessi
• il broker incapsula i dettagli dell’infrastruttura di comunicazione
• definisce un modello di programmazione distribuita in cui i client possono
richiedere servizi remoti come se fossero servizi locali. In questo modo, i
dettagli della comunicazione sono separati dalle funzionalità applicative
• Implementa la seguente dinamica di interazione
– i server registrano i propri servizi presso il broker
– i client accedono ai servizi indirettamente, tramite il broker – che inoltra le loro
richieste e gli trasmettono le risposte
• Architettura modificabile ed estensibile, servizi esistenti riusabili,
interoperabilità tra broker diversi, possibile riduzione delle prestazione,
testing complesso
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
15
Model-View-Controller (MVC)
• Divide un’applicazione interattiva in 3 componenti
– Il Model incapsula funzionalità e dati che sono indipendenti dalla
specifica rappresentazione dell’output o dal comportamento di input
– Le Views mostrano le informazioni all’utente. Una View ottiene i dati
dal Model (possono esserci più View di uno stesso Model)
– I Controller gestiscono l’input utente e la comunicazione Model-View.
I componenti Controller ricevono l’input che di solito codifica un evento
come il movimento del mouse o un input da tastiera. Gli eventi sono
poi tradotti in service request per il Model
• La consistenza tra UI e Model è garantita da un meccanismo
di propagazione dei cambiamenti
– quando un modello cambia il suo stato, notifica tutte le sue viste ed i
suoi controller del cambiamento – in modo che questi possano
aggiornare il loro stato in modo appropriato
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
16
Model-View-Controller VS
Boundary-Control-Entity
«uses»
«uses»
Boundary
«uses»
Control
Entity
Attore
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
17
Architettura orientata ai servizi
• servizi ( implementati come Web Services (WS))
– hanno l’obiettivo di incapsulare funzionalità di business (logica applicativa) per
renderle disponibili ed accessibili come servizi sul web
• SOA (Service-Oriented Architecture)
– architettura in cui le funzionalità di business vengono esposte agli utenti come
servizi riusabili e condivisi in rete
• L’ approccio “orientato ai servizi” è basato sull’idea di comporre applicazioni
sulla base della scoperta e dell’invocazione di servizi disponibili in rete
anziché costruire nuove applicazioni solo per svolgere compiti specifici
• Contesto aziendale attuale – alta competitività; integrazione di processi
e informazioni; adattamento rapido a nuovi processi di business; natura
eterogenea delle organizzazioni e delle soluzioni informatiche
(interoperabilità su diverse piattaforme)
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
18
Web Services
• Hanno l’obiettivo di fornire servizi sul web a client software
• Un Web Service è un modulo software, auto-contenuto ed autodescrittivo, accessibile mediante Internet, in modo indipendente
dalla piattaforma
• Possono essere composti favorendo l’integrazione di servizi, la
creazione di processi di business completi, con un costo di sviluppo
ridotto sia nell’ambito una singola organizzazione che tra diverse
organizzazioni (integrazione di e-business)
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
19
SOA e Layers
• SOA è un approccio architetturale per costruire sistemi e applicazioni
che usano un insieme di servizi – e non solo un singolo sistema
come un insieme di servizi il cui obiettivo è consentire alle
organizzazioni di sviluppare, connettere e mantenere applicazioni e
servizi di tipo enterprise in modo efficiente ed economico
• Lo stile SOA adotta Layers come primo crieterio di decomposizione:
– Livello dei Servizi di Business – ciascun dominio di business (es.
servizio bancario) è costituito da un certo numero di processi di
business (es. erogazione di un mutuo)
– Livello dei Processi di Business – ciascun processo di business
rappresenta un compito di business automatizzato ed elementare che
può essere usato in uno o più processi di business
– Accoppiamento debole tra i servizi e tra servizi-processi ottenuto
mediante incapsulamento Æ separazione tra implementazione ed
interfaccia ed interazioni basate su interfaccia
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
20
Progettazione per Componenti VS SOA
• Le architetture a componenti
– offrono vantaggi legati alla modularità,
al riuso e all’incapsulamento
– nei contesti di integrazione, ciascun
componente deve essere opportunamente
collegato ad altri componenti –
aumentando la complessità del sistema
B
A
• In un’architettura a servizi
– ciascun componente (servizio) incapsula
una funzionalità di business
– la logica dell’infrastruttura tecnologica è
portata ad di fuori dei servizi
– i servizi sono debolmente accoppiati e
possono essere integrati e composti più
facilmente e più agilmente
E. TINELLI – Ingegneria del Software A. A. 20082008-2009
21