Presentazione di PowerPoint

Pattern Architetturali
e
Analisi Architetturale
Ingegneria del Software – parte II
Andrea Bei
Pattern Architetturali

Pattern Architetturale
 Descrive
il modello organizzativo strutturale di un
sistema software in termini di


Sottosistemi e loro responsabilità
Linee guida per organizzare le relazioni tra tali
sottosistemi
 Si
trova al massimo livello di astrazione in un
sistema che comprende design pattern più
specializzati (es: Grasp, Gof, J2EE Pattern …)

La selezione di un pattern architetturale è una
decisione fondamentale nella progettazione di
un sistema software
Layer

Il pattern Layer aiuta a strutturare applicazioni le cui
funzioni possono essere decomposte in gruppi di
sottoattività con responsabilità a diversi livelli di astrazione
Layer

Problema





Minimizzare l’impatto dei cambiamenti
Massimizzare l’intercambiabilità di alcune parti
Dare la possibilità di costruire altri sistemi con le stesse
caratteristiche di basso livello
Massimizzare la coesione delle responsabilità per aumentare
manutenibilità e comprensibilità
Soluzione



Strutturare il sistema in un appropriato numero di layer posti
l’uno sull’altro.
Il livello al più basso livello di astrazione è il Layer 1 ed è la
base del sistema
A partire da questo sono posti gli altri Layer a livelli di
astrazione via via più alti fino ad arrivare al Layer N che espone
le funzionalità del sistema
Layer

Scheda CRC e Struttura
Layer

Scenari di comunicazione tra livelli
1.
2.
3.
4.
5.
Comunicazione top-down: Un Client inoltra una request al Layer N,
questo la inoltra al Layer N-1, e via di seguito fino al Layer 1. Una
request a Layer i può produrre più request a Layer i-1
Comunicazione bottom-up: Un device driver a Layer 1 riceve un
input, lo formatta (notification) e lo inoltra al Layer 2, e via di
seguito fino al Layer N
Comunicazione top-down: Le request possono viaggiare attraverso
un sottinsieme di Layer senza arrivare al Layer 1 (es: Layer N-1 è
una cache)
Comunicazione bottom-up: Le notification possono viaggiare
attraverso un sottoinsieme di Layer senza arrivare al Layer N (es:
re-send notification nei protocolli di comunicazione)
Protocolli di comunicazione a stack
MVC

Model-View-Controller (MVC) divide una applicazione interattiva in
3 componenti
Il Model contiene funzionalità e dati
 Le Views mostrano le informazioni all’utente
 I Controller gestiscono l’input utente e la comunicazione Model-View


La consistenza tra UI e Model è garantita da un meccanismo di
propagazione dei cambiamenti
MVC

Problema


Forze




Realizzare una applicazione interattiva
La stessa informazione è presentata in modo diverso (es: bar o pie
chart).
Le modifiche della UI devono poter essere eseguite semplicemente
La possibilità di supportare diversi standard 'look and feel' o la
necessità di effettuare un porting della UI non dovrebbe aver impatto
nel core della applicazione
Soluzione

Dividere l’applicazione in






Componenti Model: incapsulano data e funzionalità e sono indipendenti
dalla specifica rappresentazione dell’output o dal comportamento di input
Componenti View: mostrano le informazioni all’utente. Una View ottiene I
dati dal Model. (possono esserci più View di uno stesso Model)
Ogni View ha associato un componente Controller.
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 tradotti in service request per il Model
Il meccanismo di propagazione dei cambiamenti è basato sul pattern
Observer
MVC

Schede CRC e Struttura
MVC

Scenario 1: un input modifica il modello e innesca il meccanismo di
propagazione dei cambiamenti






Il Controller accetta un input utente codificato come evento e lo traduce in una
service request inoltrata al Model
Il Model esegue la service request che provoca un cambiamento nei dati
Il Model notifica tutte le View che sono registrate mediante il meccanismo di
propagazione degli eventi (Observer) invocando il loro metodo update
Ogni View richiede un aggiornamento dei dati che mostra
Ogni Controller registrato esegue il retrieve dei dati per abilitare/disabilitare
alcune funzioni utente (per esempio abilitare la funzione “Save” può essere una
conseguenza del fatto che idati sono cambiati)
Il Controller originale guadagna nuovamente il controllo
MVC

Scenario 2: inizializzazione dell’MVC






Il Model viene creato
Una View viene creata prendendo come parametro il Model
La View esegue un subscribe al meccanismo di propagazione dei cambiamenti
invocando la funzione attach
La View prosegue la sua inizializzazione creando un Controller a cui passa se
stessa e il Model
Il Controller esegue un subscribe al meccanismo di propagazione dei
cambiamenti invocando la funzione attach
L’applicazione inizia a processare gli eventi
Analisi Architetturale

Obiettivo: progettare l’architettura applicativa
development
ciclo
di sviluppocycle
UP
iterazione
iteration
ide.
inc
phase
fase
costruzione
construction
transizione
transition
elaborazione


incremento
release finale
milestone
release
Fase: prima iterazione
della fase
di elaborazione
(UP), inizio
fase di
progettazione (waterfall). In ogni caso prima di iniziare lo sviluppo
Deliverable:

Documento della architettura applicativa SAD (Software Architecture
UnAsottoinsieme
stabile The
La difference
differenza
E’ la fine
una
Andiiteration
endstable executable
A questo punto il
Document)
contenente:
(delta
) between the
eseguibile
tra due
iterazione
in when
cui si some edsubset
point
of thedel
final
 Tabelle di fattori architetturali
releases
of2
iterazioni
verificasignificant
una decisione
decision prodotto
productfinale.
. The end of
 Promemoria tecnici che descrivono le decisioni architetturali
subsequent
Rappresenta
una
successive
importante
o una
or evaluation
each iteration
is a
iterations.
release
occurs
.
minor minore
release.
valutazione
significativa
At this point
, the
sistema
viene
system isereleased
rilasciato
for production
consegnato
ai use.
clienti
Analisi Architetturale


E’ una specializzazione della analisi dei requisiti. Il focus è sui requisiti che
hanno un influenza maggiore sulla architettura (es: sicurezza,
manutenibilità, ..)
Le principali attività sono:
Identificare i fattori architetturali (o guide architetturali). Sono i requisiti
non funzionali che influenzano l’architettura. (es: tempo di risposta)
 Identifcare per ciascuno priorità, variabilità, rischi e scenari di qualità che
rendano misurabile il fattore con affermazioni di tipo <stimolo>,<risposta
misurabile>. (es: click, tempo di risposta < 3 sec)


Risolvere i fattori architetturali.
Identificare le soluzioni alternative e descriverle in promemoria tecnici.
Le soluzioni possono comprendere ad esempio:



Soluzioni ad-hoc
Adozione di pattern (architetturali o di design),
Adozione di framework o librerie di terze parti o open source
Analisi Architetturale
Identificare i fattori architetturali

Creare una tabella dei fattori architetturali:
Gerarchia di priorità

Vincoli e normative
(es: politica fiscale
nel caso di studio
POS)

Obiettivi di business
(es: data di
consegna)

Altri: (es:
estendibilità,
manutenibilità, ..)
Analisi Architetturale
Risolvere i fattori architetturali

Principi di base
Si applicano su larga scala (a livello architetturale di sottosistemi) gli stessi principi
descritti dai pattern GRASP e validi su piccola scala (a livello di oggetti)
 Low Coupling
 High Cohesion
 Protected Variation (Indirezioni, Interfacce, Adapter, ..)

Adottare Separation Of Concerns (Separazione degli interessi)
Massimizzare la modularità: progettare l’architettura in modo modulare facendo
si che ogni sottosistema sia focalizzato solo su una specifica responsabilità (es:
persistenza, sicurezza, …). E’ un modo per ottenere high cohesion & low
coupling
 Usare i Decorator per aggiungere responsabilità ad un sottosistema
 Usare la programmazione orientata agli aspetti




Usare i Pattern Architetturali
Usare Framework Commerciali o Open Source
Nei punti di variazione/evoluzione nella logica di business
Usare meccanismi per rendere “inseribili” algoritmi e strategie (es: IoC,
Strategy Pattern, approcci Data Driven,…)
 trovare il giusto equilibrio tra ingegnerizzazione insufficiente ed eccessiva

Analisi Architetturale

I Promemoria Tecnici (o Schede dei problemi, Documenti degli approcci architetturali)
contengono: Problema, Riepilogo della soluzione, Fattori, Soluzione, Motivazione, Problemi
irrisolti,, Alternative considerate
Promemoria tecnico: Adattabilità Servizi di Terze Parti
Riepilogo dela soluzione: Sostenere Protected Variation usando il pattern Adapter per rendere il sistema
adattabile a servizi di terze parti variabili
Fattori: Adattabilità a servizi di terze parti variabili (calcolatori imposte, autorizzazione credito, inventario,…)
Soluzione:
Ottenere Protected Variation nel modo seguente: Analizzare diversi calcolatori delle imposte commerciali
e creare una interfacce comune per le funzionalità minime comuni. Applicare Indirection utilizzando il pattern
Adapter
Motivazione
Semplice ed economico. Garantisce una comunicazione puù veloce rispetto ad un servizio di messaging.
Quest’ultimo non potrebbe essere utilizzato per il servizio di autorizzazione del credito
Problemi non risolti
Creare un interfaccia comune per i servizi comuni potrebbe limitare l’adattabilità
Alternative considerate
Applicare Indirection usando un sistema di messaging basato sul meccanismo publish subscribe (es: code JMS)
E’ costoso e garantisce una affidabilità nella consegna dei messaggi maggiore di quanto non sia necessaria.