Pattern Architetturali e Analisi Architetturale

Transcript

1 Pattern Architetturali e Analisi Architetturale Ingegneria dei Sistemi Software (parte II) Andrea Bei

2 Pattern Architetturali Pattern Architetturale Descrive il modello organizzativo strutturale un sistema software in termini Sottosistemi e loro responsabilità Linee guida per organizzare le relazioni tra tali sottosistemi Si trova al massimo livello astrazione in un sistema che comprende design pattern più specializzati (es: Grasp, Gof, J2EE Pattern ) La selezione un pattern architetturale è una decisione fondamentale nella progettazione un sistema software

3 Pattern Architetturali Categorie pattern architetturali (*) From Mud to Structure Aiutano ad evitare sorganizzate strutture oggetti Supportano nella decomposizione un sistema in sottosistemi Contiene i pattern: Layers, Pipes and Filters e Blackboard Interactive Systems Supportano la progettazione dell interazione uomo-macchina Contiene i pattern: Model View Controller (MVC) e Presentation Abstraction Control (PAC) Distributed Systems Contiene il pattern Broker Adaptable Systems Supportano l estenbilità per evoluzione tecnologica o cambiamento dei requisiti funzionali Contiene i pattern: Reflection e Microkernel. (*) Riportata in Pattern-Oriented Software Architecture - A System of Patterns Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal Wiley and Sons Ltd.

4 From Mud to Structure - Layer Il pattern Layer aiuta a strutturare applicazioni le cui funzioni possono essere decomposte in gruppi sottoattività con responsabilità a versi livelli astrazione

5 From Mud to Structure - Layer Problema Minimizzare l impatto dei cambiamenti Massimizzare l intercambiabilità alcune parti Dare la possibilità costruire altri sistemi con le stesse caratteristiche basso livello Massimizzare la coesione delle responsabilità per aumentare manutenibilità e comprensibilità Soluzione Strutturare il sistema in un appropriato numero layer posti l uno sull altro. Il livello al più basso livello astrazione è il Layer 1 ed è la base del sistema A partire da questo sono posti gli altri Layer a livelli astrazione via via più alti fino ad arrivare al Layer N che espone le funzionalità del sistema

6 From Mud to Structure - Layer Scheda CRC e Struttura

7 From Mud to Structure - Layer Scenari comunicazione tra livelli 1. Comunicazione top-down: Un Client inoltra una request al Layer N, questo la inoltra al Layer N-1, e via 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 seguito fino al Layer N 3. Comunicazione top-down: Le request possono viaggiare attraverso un sottinsieme Layer senza arrivare al Layer 1 (es: Layer N-1 è una cache) 4. Comunicazione bottom-up: Le notification possono viaggiare attraverso un sottoinsieme Layer senza arrivare al Layer N (es: re-send notification nei protocolli comunicazione) 5. Protocolli comunicazione a stack

8 From Mud to Structure - Pipes and Filters Il Pattern Pipes and Filters ( Condotti e filtri ) fornisce una architettura per sistemi che processano stream dati. Ogni step precessamento dello stream è incapsulato in un componente filter I dati passano attraverso pipes tra filter aacenti. E possibile ottenere verse applicazioni ricombinando i componenti filter Esempio: il processo interpretazione un linguaggio inpendente dalla piattaforma (tipo Java) in una forma intermea (tipo bytecode Java)

9 From Mud to Structure - Pipes and Filters Problema Realizzare un sistema per il processamento uno stream dati Forze Il task generale può essere natualmente decomposto in versi step processamento Il processo può cambiare (mofica o ricombinazione degli step) Step processamento più piccoli sono più facili da riusare Comunicano tra loro solo step processamento aacenti Esistono più sorgenti input (data source) e destinazioni output (data sink) Sono possibili configurazioni esecuzione parallela step processamento Soluzione Ogni step processamento è incapsulato in un componente filter Ogni filter consuma e produce dati in maniera incrementale (invece consumare tutto l input per produrre in seguito tutto l output) L input è un data source, l ouptut è un datasink data source, filter e data sink sono connessi da pipe Ogni pipe implementa il flusso dati tra step aacenti L insieme filter e pipe è chiamato pipeline processamento

10 From Mud to Structure - Pipes and Filters Schede CRC

11 From Mud to Structure - Pipes and Filters Scenari Scenario 1: push pipeline. L esecuzione parte dall arrivo un dato dal data source. Scenario 2: pull pipeline. L esecuzione parte dalla lettura del dato dal data sink Scenario 3:push & pull pipeline

12 From Mud to Structure - Blackboard Il pattern Blackboard è utile in problemi per cui non esistono stretegie risoluzione deterministiche. Il pattern prevede versi sottosistemi specializzati che usano la loro conoscenza per costruire insieme una soluzione parziale o approssimata Esempio: speech to text (traduzione del parlato in scritto)

13 From Mud to Structure - Blackboard Problema: Trasformazione un dato grezzo in strutture dati ad un più alto livello astrazione come agrammi, tabelle, frasi in linguaggio naturale. I campi utilizzo possono essere: Vision, Image Recognition, Speech Recognition Forze: Non praticabile una ricerca completa nello spazio delle soluzioni Il dominio è immaturo, è necessario sperimentare più algoritmi Ogni algortimo lavora sul risultato altri algoritmi Il nome del pattern deriva dalla attività umana problem solving esercitata da un gruppo esperti versi aspetti un problema complesso. Gli esperti usano una lavagna per comunicare e convidere idee. Ognuno a partire da quanto scritto sulla lavagna può avanzare nuove ipotesi, sostenere o invalidare ipotesi presenti. Tutto questo con l obiettivo convergere verso una soluzione.

14 From Mud to Structure - Blackboard Soluzione: Creare programmi inpendenti che cooperano su una struttura dati comune Ogni programma è specializzato per risolvere una parte del task I programmi non si chiamano a vicenda e non vengono chiamati con una sequenza predefinita Di volta in volta un componente centrale valuta lo stato corrente e decide quale programma chiamare (approccio opportunistic problem solving) Durante il processo problem-solving il sistema lavora con soluzioni parziali che possono essere Combinate, Cambiate, Rifiutate

15 From Mud to Structure - Blackboard Schede CRC e Struttura

16 From Mud to Structure - Blackboard

17 Interactive Systems- MVC Model-View-Controller (MVC) vide 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 propagazione dei cambiamenti

18 Interactive Systems- MVC Problema Realizzare una applicazione interattiva Forze La stessa informazione è presentata in modo verso (es: bar o pie chart). Le mofiche della UI devono poter essere eseguite semplicemente La possibilità supportare versi standard 'look and feel' o la necessità 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 inpendenti dalla specifica rappresentazione dell output o dal comportamento input Componenti View: mostrano le informazioni all utente. Una View ottiene I dati dal Model. (possono esserci più View uno stesso Model) Ogni View ha associato un componente Controller. I componenti Controller ricevono l input che solito cofica un evento come il movimento del mouse o un input da tastiera Gli eventi sono tradotti in service request per il Model Il meccanismo propagazione dei cambiamenti è basato sul pattern Observer

19 Interactive Systems- MVC Schede CRC e Struttura

20 Interactive Systems- MVC Scenario 1: un input mofica il modello e innesca il meccanismo propagazione dei cambiamenti Il Controller accetta un input utente coficato 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 meante il meccanismo 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/sabilitare 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

21 Interactive Systems- 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 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 propagazione dei cambiamenti invocando la funzione attach L applicazione inizia a processare gli eventi

22 Analisi Architetturale Obiettivo: progettare l architettura applicativa ciclo development sviluppo cycle UP iterazione iteration phase fase inc. ide costruzione construction transizione transition elaborazione milestone release incremento release finale Fase: prima iterazione della fase elaborazione (UP), inizio fase progettazione (waterfall). In ogni caso prima iniziare lo sviluppo Deliverable: Documento della architettura applicativa SAD (Software Architecture E la fine An iteration una endpoint when cui si some ed subset eseguibile of the del final (delta) tra due between the sistema At this point, viene the Un A sottoinsieme stable executable stabile The La fference fferenza Document) contenente: A questo punto il iterazione Tabelle fattori architetturali verifica significant una decisione decision prodotto product. finale. The end of releases iterazioni of 2 rilasciato system ise released Promemoria tecnici che descrivono le decisioni importante evaluation o una Rappresenta each iteration una is a subsequent architetturali successive consegnato for production ai use. valutazione occurs. significativa release minor minore release. iterations. clienti

23 Analisi Architetturale E una specializzazione della analisi dei requisiti. Il focus è sui requisiti che hanno un influenza maggiore sulla architettura (es: sicurezza, manutenibilità,..) Esistono versi approcci < specificare > Le principali attività sono: Identificare i fattori architetturali (o guide architetturali). Sono i requisiti non funzionali che influenzano l architettura. (es: tempo risposta) Identifcare per ciascuno priorità, variabilità, rischi e scenari qualità che rendano misurabile il fattore con affermazioni tipo <stimolo>,<risposta misurabile>. (es: click, tempo 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 pattern (architetturali o design), Adozione framework o librerie terze parti o open source

24 Analisi Architetturale Identificare i fattori architetturali Creare una tabella dei fattori architetturali: Gerarchia priorità Vincoli e normative (es: politica fiscale nel caso stuo POS) Obiettivi business (es: data consegna) Altri: (es: estenbilità, manutenibilità,..)

25 Analisi Architetturale Risolvere i fattori architetturali Principi base Si applicano su larga scala (a livello architetturale sottosistemi) gli stessi principi descritti dai pattern GRASP e vali su piccola scala (a livello oggetti) Low Coupling High Cohesion Protected Variation (Inrezioni, Interfacce, Adapter,..) Adottare Separation Of Concers (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 variazione/evoluzione nella logica 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

26 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 Promemoria tecnico: tecnico: Adattabilità Adattabilità Servizi Servizi Terze Terze Parti Parti Riepilogo Riepilogo dela dela soluzione: soluzione: Sostenere Sostenere Protected Protected Variation Variation usando usando il il pattern pattern Adapter Adapter per per rendere rendere il il sistema sistema adattabili adattabili a a servizi servizi terze terze parti parti variabili variabili Fattori: Fattori: Adattabilità Adattabilità a a servizi servizi terze terze parti parti variabili variabili (calcolatori (calcolatori imposte, imposte, autorizzazione autorizzazione creto, creto, inventario, ) inventario, ) Soluzione: Soluzione: Ottenere Ottenere Protected Protected Variation Variation nel nel modo modo seguente: seguente: Analizzare Analizzare versi versi calcolatori calcolatori delle delle imposte imposte commerciali commerciali e e creare creare una una interfacce interfacce comuni comuni per per le le funzionalità funzionalità minime minime comuni. comuni. Applicare Applicare Inrection Inrection utilizzando utilizzando il il pattern pattern Adpater Adpater Motivazione Motivazione Semplice Semplice ed ed economico. economico. Garantisce Garantisce una una comunicazione comunicazione puù puù veloce veloce rispetto rispetto ad ad un un servizio servizio messaging. messaging. Quest ultimo Quest ultimo non non potrebbe potrebbe essere essere utilizzato utilizzato per per il il servizio servizio autorizzazione autorizzazione del del creto creto Problemi Problemi non non risolti risolti Creare Creare un un interfaccia interfaccia comune comune per per i i servizi servizi comuni comuni potrebbe potrebbe limitare limitare l adattabilità l adattabilità Alternative Alternative considerate considerate Applicare Applicare Inrection Inrection usando usando un un sistema sistema messaging messaging basato basato sul sul meccanismo meccanismo publish publish subscribe subscribe (es: (es: code code JMS) JMS) E E costoso costoso e e garantisce garantisce una una affidabilità affidabilità nella nella consegna consegna dei dei messaggi messaggi maggiore maggiore quanto quanto non non sia sia necessaria. necessaria.