Esempi di architectural patterns illustrati in dettaglio nel seguito:
Un classico esempio di pattern architetturale è il pattern Model-View-Controller (MVC).
È stato uno dei primi pattern, introdotto nel 1988 con Smalltalk-80.
In realtà è una vera e propria “composizione di pattern”.
La sua fama odierna è dovuta in parte alla diffusione di Java, perché utilizzato per alcuni componenti della libreria Swing.
Alcuni ambienti di sviluppo (Microsoft Visual C++, Jakarta Struts) si basano su tale pattern.
Nacque dalla necessità di visualizzare dati generici tramite interfaccia grafica (GUI), mediante l’utilizzo di rappresentazioni diverse dei dati stessi.
Consente la realizzazione di una architettura che permette la separazione netta dei componenti di presentazione dei dati dai componenti che gestiscono i dati stessi.
MVC disaccoppia View e Model, utilizzando un protocollo di sottoscrizione-notifica.
Controller trasforma gli input utente nella View in azioni del Model, implementando la logica di controllo dell’applicazione.
Definisce le regole di business per l’interazione con i dati, esponendo alla View ed al Controller rispettivamente le funzionalità per l’accesso e l’aggiornamento.
Ha la responsabilità di notificare ai componenti della View eventuali aggiornamenti verificatisi in seguito a richieste del Controller, al fine di permettere alle View di presentare dati sempre aggiornati.
Gestisce la logica di presentazione dei dati.
Ogni GUI può implementare viste diverse sui dati, e modalità diverse di interazione coi dati
Es.: Modalità asincrona e strategia “push”.
Si può utilizzare un altro pattern (Observer), registrando le View come osservatori del Model. Le View possono quindi richiedere gli aggiornamenti al Model in tempo reale. Inoltre la View delega al Controller l’esecuzione dei processi richiesti dall’utente dopo averne catturato gli input, e la scelta delle eventuali schermate da presentare.
Ha la responsabilità di trasformare le interazioni dell’utente della View in azioni eseguite dal Model.
Realizza la corrispondenza tra l’input dell’utente e i processi eseguiti dal Model.
Selezionando la schermate della View richieste, il Controller implementa la logica di controllo dell’applicazione.
In risposta a qualche evento il metodo handleEvent()
viene invocato sul Controller.
Il Controller esamina lo stato del modello usando il metodo getState()
e invoca un metodo di servizio nel modello per cambiare il suo stato.
Il modello cambia lo stato e invoca il suo metodo di notifica per notificare il cambiamento di stato a tutte le View registrate;
Ogni View registrata viene notificata invocando il suo metodo update()
. La View esamina lo stato del modello tramite il metodo getState()
e si autoaggiorna.
L’utente seleziona una pagina.
La View non decide quale sarà la schermata richiesta, delegando ciò al Controller tramite l’invocazione del suo metodo processSelectPage()
, che grazie al pattern Strategy può essere anche cambiato dinamicamente a runtime.
Il Controller decide la pagina da visualizzare, e la comunica alla View invocando il suo metodo showSelectPage()
.
La View costruisce e presenta all’utente della schermata stessa, controllando se ci sono state modifiche nel modello invocando il metodo getState()
.
Il Broker è un pattern architetturale, con schema logico di tipo publish/subscribe:
Conferisce al sistema caratteristiche di trasparenza alla locazione, al linguaggio di programmazione e alla piattaforma target.
L’architettura con Broker rappresenta un sorta di bus (software) virtuale a cui ogni oggetto affida i suoi messaggi.
Il Broker è l’elemento di integrazione fra i “moduli” che compongono il sistema software.
Il Broker è un pattern molto utilizzato nelle architetture dei sistemi middleware.
Esempi di middleware che lo utilizzano sono: OMG CORBA, IBM SOM/DSOM, Microsoft OLE 2.x
Una applicazione può accedere a servizi distribuiti semplicemente inviando messaggi all’oggetto appropriato, piuttosto che doversi impegnare in una comunicazione inter-processo di basso livello.
Comprende sei tipi di componenti partecipanti:
Un broker è un componente responsabile della trasmissione delle richieste dai clienti ai serventi, e della trasmissione ai clienti delle risposte o delle eccezioni rilevate.
Un broker offre dei metodi (API) ai clienti e ai serventi, che includono operazioni per registrare un server e per invocarne i servizi.
I bridge sono componenti opzionali del pattern, utilizzati per nascondere i dettagli di implementazione della comunicazione tra i broker in modo che, in una rete eterogenea, i broker comunichino in maniera trasparente, rispetto all’architettura di rete e ai sistemi operativi in uso.
1. Il broker viene eseguito nella fase di inizializzazione del sistema. Entra così in un ciclo di attesa eventi, aspettando che arrivino messaggi.
2. L’utilizzatore esegue l’applicazione server, che esegue una fase di inizializzazione dopo la quale si registra presso il broker.
3. Il broker riceve il messaggio di richiesta registrazione, estrae le informazioni necessarie e le memorizza in un’area dati, il repository, che serve per trovare e attivare i server, e invia un messaggio di avvenuta registrazione al server.
4. Ricevuta la conferma, il server entra nel ciclo di attesa delle richieste provenienti dai clienti.
1. L’applicazione cliente viene eseguita. Durante l’esecuzione del programma il cliente invoca un metodo di un oggetto server remoto.
2. Il proxy lato cliente impacchetta tutti i parametri ed altre informazioni supplementari, in un messaggio che viene trasferito al broker locale.
3. Il broker ricerca la posizione del server richiesto all’interno del suo repository. Se il server è disponibile localmente, il broker trasferisce il messaggio al corrispondente proxy lato server (il caso di server remoto lo vediamo nel prossimo scenario).
4. Il proxy lato server spacchetta i parametri e le informazioni supplementari, tra cui il metodo che bisogna invocare. A questo punto il proxy richiama il servizio appropriato.
5. Dopo che il servizio è stato eseguito, il server restituisce il risultato al proxy lato server, che lo impacchetta, insieme ad informazioni supplementari, in un messaggio che trasferisce poi al broker.
6. Il Broker trasferisce la risposta al proxy lato client.
7. Il proxy lato client riceve la risposta, spacchetta il messaggio e lo invia all’applicazione cliente, che dopo aver ricevuto i dati di suo interesse, continua la sua esecuzione normalmente.
1. Il broker A riceve una richiesta di servizio. Esso ricerca nel repository il server responsabile dell’esecuzione del servizio. Siccome il server corrispondente è disponibile presso un altro nodo della rete, A trasmette la richiesta al broker remoto.
2. Il messaggio passa dal broker A al bridge A. Questo componente è responsabile della conversione del messaggio dal protocollo specifico del broker A, in un protocollo di rete comune ai due bridge partecipanti. Dopo la conversione, il bridge A trasmette il messaggio al bridge B.
3. Il bridge B converte il messaggio in ingresso, dal protocollo di rete al formato del protocollo specifico del broker B.
4. Il broker B esegue tutte le azioni necessarie all’arrivo di una richiesta di servizio.
2. La modellazione a oggetti e il linguaggio UML (richiami)
3. Generalità su Java e la programmazione ad oggetti
6. Regole di traduzione da UML a Java/C++
7. Programmazione multi-thread
8. Sincronizzazione tra thread
9. Programmazione client-server con socket TCP/IP (Java networkin...
10. Programmazione di applicazioni client-server: il Pattern Proxy...
12. Design Patterns
13. Pattern architetturali - Esempi
14. Design pattern creazionali. Esempi
15. Design pattern strutturali. Esempi
16. Introduzione alle tecnologie middleware
17. Modelli di middleware: RPC, MOM, TP, TS