Architectural Patternsschemi di progetto per architetture software

Seminario e-ToscanaFirenze, 17-18 febbraio 2004

Enrico Vicario, Fabrizio Baldini

Dipartimento Sistemi e InformaticaCentro per la Comunicazione e la Integrazione dei Med ia

Università di Firenze{vicario,fbaldini}@dsi.unifi.it

Patterns

• Soluzioni possibili a problemi ricorrenti• Soluzioni “half-baked”• Basati sulla esperienza• Non teoria ma pratica

• supporto teorico • formalizzazione

• Design Patterns [GHJV95]• principi generali di strutturazione nella transizione verso

l’implementazione• applicati al livello di granularità fine delle class i

• Design Patterns, Idiomi, Pattern architetturali, Pa ttern diIntegrazione, Pattern per architetture di scala enterp rise

Patterns

• Idiomi• Basso livello• Una classe o poche classi• Dipendente dal linguaggio

• Esempio: Singleton• Assicurare l’esistenza di una e una sola classe

di un certo tipo a run-time• Istanza della classe globalmente accessibile• L’implementazione può essere totalmente diversa util izzando

linguaggi diversi

DesignDesign

IdiomsIdioms

dettaglio

scala

public class Singleton{

private static Singleton instance;

protected Singleton(){…}

public static Singleton getInstance(){

if(instance == null) instance = new Singleton();

return instance;}

}

In smalltalk è molto diverso:overriding del metodo new…

new self error ‘errore’

getInstanceTheInstance isNil ifTrue:[TheInstance := super new]

^ TheInstance

Patterns

• Architectural Patterns [Fow03][POSA01]• Macro-livello• Applicazioni di scala enterprise• Persistenza, concorrenza, distribuzione

“An architectural pattern expresses a fundamentalstructural organization schema for software systems…”

• Specifica i sottosistemi• Specifica le responsabilità• Specifica le relazioni tra i sottosistemi

ArchitecturalArchitectural

DesignDesign

IdiomsIdioms

dettagliodettaglio

scala

Architectural Patterns: un po’di storia

• Smalltalk 76:• Interfacce grafiche semplici hanno struttura intrin secamente

modulare (insiemi di componenti text, menu, button, pixel-maps)

• Paradigmi di interazione riconducibili a tipologie d i base (editing, browsing, inspecting)

• Presenza di un modello di dati significativo e speci fico per il contesto applicativo

• Smalltalk-80 [Kras88]:• Componenti grafici di base riutilizzabili per composi zione• Sensori (e.g. InputSensor) per rappresentare e gest ire

l’interazione dell’utente. Possibilità di delegare l ’azione di controllo

• Modello di dati che mantiene la lista dei component i dipendenti dal modello.

Modello, Vista, Controllo

• Smalltalk-80 individua tre macro-componenti che svo lgono differenti funzioni:• Modello: rappresentare i dati e la logica della app licazione• Vista: visualizzazione dei dati di modello sulla inte rfaccia• Controllo: interfacciamento tra modello, vista e dis positivi di

input

• È definita una modalità di interazione tra i compon enti

“An architectural pattern expresses a fundamentalstructural organization schema for software systems…”• Specifica i sottosistemi• Specifica le responsabilità• Specifica le relazioni tra i sottosistemi

Architectural Pattern Model View Controller (MVC)

• “ The Model View Controller (MVC) divides an interactiv eapplication into three components. The model contains t he core functionality and data. Views display information to th e user. Controllers handle user input. Views and controllers tog ethercomprise the user interface” [POSA01]

• Contesto:• Applicazioni interattive• Applicazioni con componenti di web-presentation• In generale: Applicazioni in cui è opportuna la sepa razione tra

interfaccia e modelloNecessità di viste diverse sul modello Diverso grado di stabilità delle componenti modello e interfacciaRiuso di componenti

• Chi utilizza MVC (o sue varianti)?• Librerie Java Swing • Framework MFC• JSP/JavaBean/Servlet

Esempio: Editor LaTeX

• Documento strutturato• document, section, subsection, paragraph• Metainformazione di strutturazione inserita nel test o

Esempio: Editor LaTeX

• Problema:• Visualizzazione dei dati contenuti nel documento con

rappresentazioni diverse sulla interfaccia• Modifica sui dati del documento interagendo con la

applicazione tramite viste diverse• Allineamento delle viste all’informazione presente n el

documento

• Aggiunta di viste sul documento anche a run-time (e. g. preview frame)

• Sostituibilità di componenti di interfaccia e contr ollo senza modifiche al nucleo funzionale della applicazione

Soluzioni possibili?

• Ogni vista contiene alcuni dati del documento? :-(• Riferimenti incrociati tra i componenti vista? :-(

• Occorre aggiornare i dati del documento su ogni com ponente• Componenti di interfaccia strettamente connessi (ch i sono i

componenti attivi? Quali le interfacce delle classi ?)• Difficile introdurre nuovi componenti di interfacci a• Flusso di controllo delle azioni sulla interfaccia “frammentato”

distribuito tra i componenti

SectionFigure

SectionFigure

SectionFigure

Soluzioni possibili?

• Strutturazione delle componenti della applicazione • Model: Modello dei dati e logica della applicazione• View: Interfaccia grafica • Controller: Sensori• Change-Propagation: Meccanismo di comunicazione tra i

componenti

SectionListFigureListData….

ModelModel ViewView

ControllerController

MVC: Modello

• Nucleo funzionale della applicazione: Model• Entità significative nel contesto applicativo• Funzionalità che realizzano la logica della

applicazione• Funzioni di accesso/modifica dei dati del modello• Indipendenza dalla particolare rappresentazione

dei dati nelle componenti di interfaccia • Indipendenza dalla logica di gestione del controllo

• Collaborazioni• Il modello è modificato dai componenti Controller • Mantiene riferimenti alle Viste che mostrano i dati del modello• Invia notifiche alle Viste al cambiamento dei dati

ModelModel ViewView

ControllerController

Esempio CRC Card: Modello

• Caratteristiche del componente Modello: descrizione CRC

Nucleo funzionale della applicazione: Model•Entità significative nel contesto applicativo•Funzionalità che realizzano la logica della applica zione•Indipendenza dalla particolare rappresentazione dei dati nelle componenti di interfaccia •Indipendenza dalla logica di gestione del controllo•Funzioni di accesso ai dati del modello

Collaborazioni•I Controller modificano il modello•Mantiene riferimenti alle viste che mostrano i dati del modello•Le viste ricevono notifiche quando alcuni dati di m odello cambiano Responsibility

• Implementa il nucleo funzionale della applicazione

• Registra le viste dipendenti dal modello

• Notifica i cambiamenti ai componenti dipendenti

Collaborators• View• Controller

Class• Model

MVC: View

• Componenti di interfaccia: View• Visualizzazione di dati di modello

(dati diversi / modi diversi)• Possono essere composte per realizzare

viste più complesse

• Collaborazioni• La vista è associata al modello

Riceve dal modello notifiche di cambiamento dei dat iAccede al modello per ottenere i dati da visualizza re

• La vista crea il proprio controllore

• Collaboration Diagram• Comportamento dinamico del

sistema

2: Inizializza (myView, myModel)

1: Registra (myView)

3: Aggiorna

4: Leggi Dati

ModelModel ViewView

ControllerController

MVC: Controller

• Componenti di gestione eventi: Controller• Ricezione e gestione di eventi dalla interfaccia• Mappatura evento – funzione di gestione

(relazione 1-1 ma non necessariamente)

• Collaborazioni• Il controllore è associato ad una vista (relazione 1 a 1)• Il controllore invoca le funzionalità sul modello e può

modificarne i dati

• Collaboration Diagram1: Input

2: Esegui Funzione

5: Leggi Dati

3: Notifica

4: Aggiorna

ModelModel ViewView

ControllerController

MVC: Class Diagram

• Classi MVC di base: Model, View, Controller• Classi derivate (rif. esempio Editor)

• Model: TeXDocument• View: ObjectView, StructuredTreeView• Controller: TreeController, ObjectController

public class Model{

private Vector setOfViews;[..]

// Aggiunge una nuova vistapublic void attach(View aView){ viewList.addElement(aView); }// Rimuove la vistapublic void detach (View aView){ viewList.removeElement(aView); }

// Notifica il cambiamento alle viste registratepublic void notify(){

Iterator iterator = viewList.listIterator();while(iterator.hasNext())

((View)iterator.next()).update();}

}

public class TeXDocument extends Model{

private Vector sectionList;private Vector figureList;

[…]// Funzione che modifica i datipublic void addSection(…){

[..] //function bodynotify();

}}

public class StructuredTreeView implements View{

private TeXDocument theModel;private TreeController theController;[..]

// Inizializzazionepublic void init (Model model){

[..]theModel = model;theController = createController();[..]

}

// Crea il controllorepublic void createController(){

theController = new TreeController(); theController.init(this, theModel);

}

/* Effettua l’aggiornamento leggendo i dati dal modello */

public void update(){

Section[] sections = theModel.getSections();// Aggiorna la vista con i dati ottenuti[..]

}}

public class TreeController implements Controller{

private TeXDocument theModel;private StructuredTreeView theView;[..]

// Inizializzazionepublic void init (View view, Model model){

theView = view;theModel = model;[..]

}

/* Gestisce gli eventi e.g. aggiornamento di una sezione */

public void handleEvent(Event e){

[..]//Es. Aggiornamento del nome di una sezionetheModel.updateSection(section, “Pattern MVC”);[..]

}}

MVC: Change - Propagation

• Modalità di comunicazione tra componenti: meccanismo Change – Propagation1. Registrazione delle viste

sul modello2. Il modello è modificato

dai controllori3. Il modello notifica

cambiamenti a tutte le viste registrate

4. Le viste richiedono al modello i dati necessari all’aggiornamento della visualizzazione

Design Pattern Observer

• Change-Propagation MVC ààà à Design Pattern Observer

“Define a one-to-many dependency between objects so that when one object changes state, all its dependents a re notified and updated automatically.” [GHJV95]

• Partecipanti• Subject (Observable)

Ha riferimenti agli osservatori che dipendono dal s uo statoFornisce metodi di interfaccia per aggiungere e rim uovere osservatori

• Observer Interfaccia che presenta un metodo di aggiornamento . Le classi che implementano l’interfaccia sono notificati al varia re dello stato del Subject.L’implementazione dell’aggiornamento mantiene lo st ato coerente con quello del Subject.

Design Pattern Observer

• Class Diagram:• Subject equivale al “Model” MVC• Observer equivale a “View” MVC

• Collaborazioni• ConcreteSubject notifica il cambiamento di stato• ConcreteObserver può richiedere informazioni per

l’aggiornamento per sincronizzarsi

Vantaggi derivanti dall’uso di MVC

• Viste multiple sullo stesso modello• Meccanismo efficiente di sincronizzazione delle vis te

(Change-propagation)• Semplicità di sostituzione/aggiunta/modifica di vis te e

controllori

• “Stabilità” del nucleo funzionale della applicazion e • Il modello contiene i dati significativi per la app licazione e le

funzionalità “core” della applicazione• Il modello effettua notifiche agli elementi dipende nti• Il modello dipende dalle viste solo per l’interfacc ia View

Vantaggi derivanti dall’uso di MVC

• Componibilità di viste: “Composite” pattern [GHJV95 ]“ Compose objects into tree structures to represent par t-whole hierarchies. Composite lets clients treat individ ualobjects and compositions of objects uniformly.”

• Vantaggio• Oggetti “foglia” e composizioni hanno la stessa interf accia

(View)• Definizione di “viste” di base combinabili in viste c omplesse

Preview

TextView

CompositeView

Vantaggi derivanti dall’uso di MVC

• Organizzazione gerarchica di controllori “Chain of Responsibility” pattern [GHJV95]“Avoid coupling the sender of a request to its rece iver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the requ estalong the chain until an object handles it.”

• Esempio: Help Contestuale• La richiesta di aiuto viene inoltrata dal component e al

contenitore finchè non è gestita

ComboCtrl

DialogCtrl

successor

Limiti del modello MVC

• Complessità• La terna MVC può essere usata per ogni componente di

interfaccia ma non è necessaria per quelli più semp lici (e.g. semplici campi di testo)

• Inefficienza• Eccessivo numero di “updates” a seguito della richies ta di una

sola funzione sul modello• Non tutti i cambiamenti del modello interessano tut te le viste • La vista può essere in uno stato “inattivo” (e.g. ri dotta a icona)

• Accoppiamento di vista e controllore col modello

Usi Noti: Java

• I componenti delle librerie Java Swing sono realizz ati secondo una variante del modello MVC

• Ogni componente (JButton, JToggleButton… ) ha un modello associato che ne descrive lo stato e i dati

• Alcuni componenti (e.g. JList, JTree) prevedono l’u so esplicito di un modello per consentire la modifica dei dati visualizzati

• Esempio: JButton

Modello UIDelegate

Controllers

Usi noti: MFC - variante Document/View

• Document/View• View/Controller strettamente connessi• Accoppiamento lasco col modello• Più viste sincronizzate• Difficile cambiare il controllo

• Framework MFC• Spesso la vista si occupa della rappresentazione nel la

interfaccia e della gestione del controllo• Possibile delegare la gestione dei messaggi a compo nenti di

controllo separati (:CCmdTarget)

Model

View

Controller

Document

View

• Architettura CART• Cooperazione per eventi (EDA): modalità asincrona pe r

scambio di messaggi• Il NAL svolge funzione di publisher/subscriber per i SIL che

fanno riferimento ad esso

• Comunicazione per eventi• Publisher: invia una “notifica” pubblicando un evento tamite

un messaggio• Subscriber: riceve le notifiche di aggiornamento at traverso la

ricezione del messaggio• ŁŁŁŁ P&S strettamente correlato a Change - Propagation

Publish&Subscribe

NAL aNAL a

NAL bNAL b

NAL cNAL c

NAL dNAL d SILSIL

Publisher

Subscribers

Publish&Subscribe

• Publisher-Subscriber è sinonimo di Observer“The Publisher-Subscriber design pattern helps to kee p the state of cooperating components synchronyzed. [..] On e way propagation of changes: one publisher notifies any number of subscribers.” [POSA01]

• Due differenti protocolli di notifica• Pull model• Push model

Publish&Subscribe: Modelli Push/Pull

• Modello Pull• Il publisher notifica l’avvenuto cambiamento di sta to• Invia solo un set minimale di informazioni• I sottoscrittori richiedono i dati necessari

+ è flessibile: i subscribers scelgono i dati ad es si necessari (e solo quelli)

- richiede molti scambi di messaggi- i subscribers devono “capire” cosa è cambiato

• Il pattern MVC utilizza tipicamente il modello Pull• Il Model invia la notifica• Le Viste sono responsabili ad accedere ai dati nece ssari per

l’aggiornamento

Publish&Subscribe: Modelli Push/Pull

• Modello Push• Il publisher invia con la notifica i dati modificat i

+ Nessuna interazione tra le parti (eccetto la noti fica)+ Più adatto ad una architettura distribuita- Meno flessibile: i subscribers accettano passivament e i dati

inviati- Inefficienza: invio di grosse quantità di dati talvo lta non

richiesti

• Varianti (tra Push e Pull)• Indicazione di quale sottoinsieme dei dati è cambiat o• Invio dei dati di interesse per la “maggior parte” de i

sottoscrittori

• P&S (modello Observer) prevede una interazione dire tta• I Publisher mantengono riferiementi ai subscriber• I Publisher notificano direttamente i subscriber

• Event Channel: P&S per sistemi distribuiti• Disaccoppiamento di publishers e subscribers• Presenza di un mediatore (gestore eventi)

Gestore Eventi (CRIC)

Gestore Eventi (CRIC)

Event Channel

NAL aNAL a

NAL bNAL b

NAL cNAL c

NAL dNAL d SILSIL

Publisher

Subscribers

Event Channel

• Variante proposta da OMG Event Service Spec (1995)

• Contesto• Comunicazione per eventi in un contesto distribuito• I partecipanti non sono interessati ad avere relazio ni tra loro• Partecipanti interessati solo al cambiamento dei da ti

• Struttura• Introduzione di un intermediario: Event Channel

• Collaborazioni• I subscriber si registrano sul Channel• Event Channel è sorgente e destinazione dei messaggi

Event Channel

• Collaboration Diagram• Registrazione dei subscribers• Dispatching dei messaggi• Funzioni aggiuntive di Event Channel: filtraggio, st orage,

autenticazione

• Event Channel è realizzato dai sistemi MOM di Messa ging• Messaging mediato da un Message Server

• Esempio JMS API:• Administered Objects: incapsulano le specifiche

implementazioni vendor-dependent dei provider JMS (Destination, ConnectionFactory)

• Oggetti producer/consumer per l’invio e la ricezione dei messaggi (TopicPublisher, TopicSubscriber, MessageL istener)

Esempio: MOM e JMS API

Publisher SubscriberMessageServer

TopicSubscriber

TopicPublisher

public class MyPublisher{

[…]public MyPublisher(){

/* Ricerca della factory per creare le connessioni col message server */

jndiContext = new InitialContext();connectionFactory = (ConnectionFactory)

jndiContext.lookup("jms/TopicConnectionFactory");

// Ricerca della destinazione (il Topic dei messaggi)destination = (Topic) jndiContext.lookup("MyTopic");

}

[…]public void sendATextMessage(){

connection = connectionFactory.createConnection();session = connection.createSession(…);

/* Creazione del proxy per la comunicazione */publisher = session.createPublisher(destination);message = session.createTextMessage();message.setText(“Hello!”);publisher.publish(message);connection.close();

}}

public class MySubscriber{

[…]public MySubscriber(){

[…]/* Crea context, la ConnectionFactory, Connection,

Session */subscriber = session.createSubscriber(dest);listener = new TextListener();subscriber.setMessageListener(listener);connection.start();

}}--------------

public class TextListener implements MessageListener{

//Metodo di callback per la ricezione dei messaggipublic void onMessage(Message message) {

TextMessage msg = null; if (message instanceof TextMessage) {

msg = (TextMessage) message;String content = msg.getText();[…]

}}

}

• Architettura Event Driven: Publish&Subscribe• Scambio di messaggi tra sistemi distribuiti • Modalità (prevalentemente) asincrona

• Architettura Service Oriented: • Invocazioni di servizio tra sistemi distribuiti• Modalità sincrona

• Architettura CART• Previsto un modello di comunicazione basato su richi este di

servizio ààà à Presenza di un coordinatore di servizio (Broker/Orche strator)

Broker

Broker/Orchestrator

Broker/OrchestratorNAL aNAL a

NAL bNAL b

NAL cNAL c

NAL dNAL dSILSIL

Client

Server

Web Services + Broker

• Architettura CART per l’architettura SOA• WebService Orchestrator è mediatore della comunicazi one

Riceve richieste di servizio dal NALDetermina la locazione del destinatarioDetermina le modalità di invocazioneComunica col NAL di destinazione invocando il servi zio

• La componente presente sul CRIC mantiene un registr y dei servizi e fornisce API per la registrazione dei servi zi

CRICCRIC

NAL aNAL a

SIL a1SIL a1 SIL a2SIL a2

Proxy applic.

NAL bNAL b

SIL b1SIL b1 SIL b2SIL b2

Proxy applic.

WebServicesOrchestrator

registry

Architectural Pattern Broker

• Architettura SOA ben rappresentata dal pattern Brok er

• “The Broker architectural pattern can be used to str ucturedistributed software systems with decoupled componentsthat interact by remote services invocations. A broker is responsible for coordinating communication. Forwarding request, transmitting results […]” [POSA01]

• Contesto e Problematiche• Ambiente distribuito• Sistemi indipendenti tra loro (il client non conosce la locazione

del provider di servizio)• Sistemi eterogenei (indipendenza dalla implementazion e)

• Soluzioni• Introduzione del broker• Invocazione dei servizi sotto forma di “messaggi di ch iamata”

indirizzati al broker

Architectural Pattern Broker: Struttura

• Fornitore di servizi: Server• Implementano i servizi e li espongono tramite interf acce• Descrizione di interfacce: formati IDL (per i WS: WS DL)• Si registrano sul broker

• Coordinatore: Broker• Offre una interfaccia di registrazione per i servizi• Mantiene le informazioni in un registro dei servizi• Trasmette richieste, risposte ed eccezioni nei due s ensi

• Proxy• Rappresentano l’oggetto server sul lato client e il client sul

server. Mascherano la distribuzione dei servizi• Intermediari della comunicazione tra Client/Server e Broker• Lato client: chiamate a procedure ß àß àß àß à messaggi al broker• Lato server: messaggi del broker ß àß àß àß à invocazioni di servizio• Sono generati dal compilatore IDL

Architectural Pattern Broker: Collaborazioni

• Collaboration diagram• Registrazione del servizio• Invocazione da parte di un client

Architectural Pattern Broker

• Vantaggi• Client e Server disaccoppiati (localizzazione, comunicazi one,

distribuzione trasparente)• Client e Server eterogenei (indipendenza dalla

implementazione)• Svantaggi

• Efficienza ààà à schemi alternativi in comunicazione diretta• Criticità dei malfunzionamenti del Broker

• Direct Communication Broker• Client e server comunicano direttamente per ragioni di

efficienza• Client e server condividono il protocollo di comuni cazione• Il Broker inizializza la connessione indicando al clie nt • I Proxy svolgono le attività di comunicazione

• E.g. Web Services• Il broker svolge funzione di registro dei servizi

Riferimenti

• [GHJV95] Gamma, Helm, Johnson, Vlissides, “Design Patterns – Elements of Reusable Object-Oriented Software” , Addison-Wesley 1995

• [Fow00] M.Fowler, “UML Distilled” , Addison Wesley 2000• [POSA01] Buschmann, Meunier, Rohnert, Sommerlad, St al,

“Pattern-Oriented Software Architecture” , Wiley 2001• [Fow03] M.Fowler, “Patterns of Enterprise Application

Architecture” , 2003