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. 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 2. 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 3. Comunicazione top-down: Le request possono viaggiare attraverso un sottinsieme di Layer senza arrivare al Layer 1 (es: Layer N-1 è una cache) 4. 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) 5. 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 Realizzare una applicazione interattiva Forze 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 ciclo development di sviluppo cycle UP iterazione iteration phase fase inc ide. costruzione construction transizione transition elaborazione milestone release incremento release finale 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 E la fine An di iteration una end - Un A sottoinsieme stable executable stabile The difference Document) contenente: La differenza A questo punto il iterazione point when cui si some ed subset eseguibile of the del final ( delta tra due ) between the At this point, the Tabelle di fattori architetturali sistema viene verifica significant una decisione decision prodotto product finale.. The end of releases iterazioni of 2 rilasciato system is e released Promemoria tecnici che descrivono le decisioni architetturali importante evaluation o una Rappresenta each iteration una is a subsequent successive consegnato for production ai use. valutazione occurs significativa. release minor minore release. iterations. 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.