Seminario e-Toscana

Firenze, 17-18 febbraio 2004

Architectural Patterns
schemi di progetto per architetture software

Enrico Vicario, Fabrizio Baldini

Dipartimento Sistemi e Informatica Centro per la Comunicazione e la Integrazione dei Media 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 limplementazione applicati al livello di granularit fine delle classi

Design Patterns, Idiomi, Pattern architetturali, Pattern di

Integrazione, Pattern per architetture di scala enterprise

Patterns

Idiomi
Basso livello Una classe o poche classi Dipendente dal linguaggio

scala

Design Design Idioms Idioms

Esempio: Singleton

dettaglio

public { private static Singleton instance; protected Singleton(){}

Assicurare lesistenza di una e una sola classe di un certo tipo a run-time Istanza della classe globalmente accessibile In smalltalk molto diverso: Limplementazione pu essere totalmente diversa utilizzando overriding del metodo new class Singleton linguaggi diversi
new self error errore getInstance TheInstance isNil ifTrue: [TheInstance := super new] ^ TheInstance

public static Singleton getInstance() { if(instance == null) instance = new Singleton(); return instance; } }

Patterns

Architectural Patterns [Fow03][POSA01]

Macro-livello Applicazioni di scala enterprise Persistenza, concorrenza, distribuzione

scala

Architectural Architectural Design Design Idioms Idioms

dettaglio

An architectural pattern expresses a fundamental structural organization schema for software systems
Specifica i sottosistemi Specifica le responsabilit Specifica le relazioni tra i sottosistemi

Architectural Patterns: un podi storia

Smalltalk 76:
Interfacce grafiche semplici hanno struttura intrinsecamente modulare (insiemi di componenti text, menu, button, pixelmaps) Paradigmi di interazione riconducibili a tipologie di base (editing, browsing, inspecting) Presenza di un modello di dati significativo e specifico per il contesto applicativo

Smalltalk-80 [Kras88]:
Componenti grafici di base riutilizzabili per composizione Sensori (e.g. InputSensor) per rappresentare e gestire linterazione dellutente. Possibilit di delegare lazione di controllo Modello di dati che mantiene la lista dei componenti dipendenti dal modello.

Modello, Vista, Controllo

Smalltalk-80 individua tre macro-componenti che svolgono

differenti funzioni:
Modello: rappresentare i dati e la logica della applicazione Vista: visualizzazione dei dati di modello sulla interfaccia Controllo: interfacciamento tra modello, vista e dispositivi di input

definita una modalit di interazione tra i componenti

An architectural pattern expresses a fundamental structural 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 interactive

application into three components. The model contains the core functionality and data. Views display information to the user. Controllers handle user input. Views and controllers together comprise the user interface [POSA01]

Contesto:
Applicazioni interattive Applicazioni con componenti di web-presentation In generale: Applicazioni in cui opportuna la separazione tra interfaccia e modello
Necessit di viste diverse sul modello Diverso grado di stabilit delle componenti modello e interfaccia Riuso 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 testo

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 allinformazione presente nel documento Aggiunta di viste sul documento anche a run-time (e.g. preview frame) Sostituibilit di componenti di interfaccia e controllo senza modifiche al nucleo funzionale della applicazione

Soluzioni possibili?

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

Section Figure

Section Figure

Occorre aggiornare i dati del documento su ogni componente Componenti di interfaccia strettamente connessi (chi sono i componenti attivi? Quali le interfacce delle classi?) Difficile introdurre nuovi componenti di interfaccia Flusso di controllo delle azioni sulla interfaccia frammentato distribuito tra i componenti

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

SectionList FigureList Data .

Model Model

View View

Controller Controller

MVC: Modello

Nucleo funzionale della applicazione: Model

Entit significative nel contesto applicativo Model View Model View Funzionalit che realizzano la logica della applicazione Controller Controller 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

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 applicazione 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 Class Mantiene riferimenti alle viste che mostrano i dati del Model modello Le viste ricevono notifiche quando alcuni dati di modello Responsibility cambiano

Collaborators

View Controller

Implementa il nucleo
funzionale della applicazione Registra le viste dipendenti dal modello Notifica i cambiamenti ai componenti dipendenti

MVC: View

Componenti di interfaccia: View

Visualizzazione di dati di modello (dati diversi / modi diversi) Possono essere composte per realizzare viste pi complesse
Model Model View View

Controller Controller

Collaborazioni
La vista associata al modello
Riceve dal modello notifiche di cambiamento dei dati Accede al modello per ottenere i dati da visualizzare

La vista crea il proprio controllore

3: Aggiorna

Collaboration Diagram
Comportamento dinamico del sistema

4: Leggi Dati 1: Registra (myView)

2: Inizializza (myView, myModel)

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)
Model Model View View

Controller Controller

Collaborazioni
Il controllore associato ad una vista (relazione 1 a 1) Il controllore invoca le funzionalit sul modello e pu modificarne i dati

Collaboration Diagram
1: Input

3: Notifica

4: Aggiorna

5: Leggi Dati 2: Esegui Funzione

MVC: Class Diagram

Classi MVC di base: Model, View, Controller public class StructuredTreeView { Classi derivate (rif. esempioTeXDocument theModel; private Editor)

implements View

public class Model private TreeController theController; Model: TeXDocument { publicprivateTreeController implements Controller class Vector setOfViews; [..] { View: ObjectView, StructuredTreeView [..] // Inizializzazione private TeXDocument theModel; StructuredTreeView theView; Controller: TreeController, ObjectController private Aggiunge una nuova vista public void init (Model model) // { [..] public void attach(View aView) public class TeXDocument extends Model [..] { viewList.addElement(aView); } { theModel = model; // Inizializzazionevista // Rimuove la privateview, Model model) Vector sectionList; theController = createController(); public void void detach (View aView) (View public init private Vector figureList; [..] { { viewList.removeElement(aView); } } theView = view; [] theModel = model; cambiamento alle viste registrate // Notifica il // Crea i controllore [..]public void // Funzione che modifica il dati notify() public void addSection() public void createController() } { { { Iterator iterator = viewList.listIterator(); [..] //function body theController = /* Gestisce gli eventi e.g. aggiornamento di una new TreeController(); while(iterator.hasNext()) theController.init(this, theModel); notify(); sezione */ ((View)iterator.next()).update(); } public void handleEvent(Event e) } } } { } /* Effettua laggiornamento leggendo i dati dal [..]//Es. Aggiornamento del nome di una sezione modello */ theModel.updateSection(section, Pattern MVC); public void update() [..] { } Section[] sections = theModel.getSections(); } // Aggiorna la vista con i dati ottenuti [..] } }

MVC: Change - Propagation

Modalit di comunicazione
tra componenti: meccanismo Change Propagation
1. Registrazione delle viste sul modello 2. Il modello modificato dai controllori 3. Il modello notifica cambiamenti a tutte le viste registrate 4. Le viste richiedono al modello i dati necessari allaggiornamento 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 are notified and updated automatically. [GHJV95]

Partecipanti
Subject (Observable)
Ha riferimenti agli osservatori che dipendono dal suo stato Fornisce metodi di interfaccia per aggiungere e rimuovere osservatori

Observer
Interfaccia che presenta un metodo di aggiornamento. Le classi che implementano linterfaccia sono notificati al variare dello stato del Subject. Limplementazione dellaggiornamento mantiene lo stato 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 laggiornamento per sincronizzarsi

Vantaggi derivanti dalluso di MVC

Viste multiple sullo stesso modello Meccanismo efficiente di sincronizzazione delle viste
(Change-propagation) Semplicit di sostituzione/aggiunta/modifica di viste e controllori

Stabilit del nucleo funzionale della applicazione

Il modello contiene i dati significativi per la applicazione e le funzionalit core della applicazione Il modello effettua notifiche agli elementi dipendenti Il modello dipende dalle viste solo per linterfaccia View

Vantaggi derivanti dalluso di MVC

Componibilit di viste: Composite pattern [GHJV95]

Compose objects into tree structures to represent partwhole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.
CompositeView

Preview

TextView

Vantaggio
Oggetti foglia e composizioni hanno la stessa interfaccia (View) Definizione di viste di base combinabili in viste complesse

Vantaggi derivanti dalluso di MVC

Organizzazione gerarchica di controllori

Chain of Responsibility pattern [GHJV95] Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.
DialogCtrl

successor

ComboCtrl

Esempio: Help Contestuale

La richiesta di aiuto viene inoltrata dal componente al contenitore finch non gestita

Limiti del modello MVC

Complessit
La terna MVC pu essere usata per ogni componente di interfaccia ma non necessaria per quelli pi semplici (e.g. semplici campi di testo)

Inefficienza
Eccessivo numero di updates a seguito della richiesta di una sola funzione sul modello Non tutti i cambiamenti del modello interessano tutte le viste La vista pu essere in uno stato inattivo (e.g. ridotta a icona)

Accoppiamento di vista e controllore col modello

Usi Noti: Java

I componenti delle librerie Java Swing sono realizzati

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 luso 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

Model View Controller

Document View

Framework MFC
Spesso la vista si occupa della rappresentazione nella interfaccia e della gestione del controllo Possibile delegare la gestione dei messaggi a componenti di controllo separati (:CCmdTarget)

Publish&Subscribe

Architettura CART
Cooperazione per eventi (EDA): modalit asincrona per scambio di messaggi Il NAL svolge funzione di publisher/subscriber per i SIL che fanno riferimento ad esso
Subscribers Publisher

NAL b NAL b NAL c NAL c NAL d NAL d

SIL SIL

NAL a NAL a

Comunicazione per eventi

Publisher: invia una notifica pubblicando un evento tamite un messaggio Subscriber: riceve le notifiche di aggiornamento attraverso la ricezione del messaggio

P&S strettamente correlato a Change - Propagation

Publish&Subscribe

Publisher-Subscriber sinonimo di Observer

The Publisher-Subscriber design pattern helps to keep the state of cooperating components synchronyzed. [..] One 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 lavvenuto cambiamento di stato Invia solo un set minimale di informazioni I sottoscrittori richiedono i dati necessari + flessibile: i subscribers scelgono i dati ad essi 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 necessari per laggiornamento

Publish&Subscribe: Modelli Push/Pull

Modello Push
Il publisher invia con la notifica i dati modificati + Nessuna interazione tra le parti (eccetto la notifica) + Pi adatto ad una architettura distribuita - Meno flessibile: i subscribers accettano passivamente i dati inviati - Inefficienza: invio di grosse quantit di dati talvolta non richiesti

Varianti (tra Push e Pull)

Indicazione di quale sottoinsieme dei dati cambiato Invio dei dati di interesse per la maggior parte dei sottoscrittori

Event Channel

P&S (modello Observer) prevede una interazione diretta

I Publisher mantengono riferiementi ai subscriber I Publisher notificano direttamente i subscriber
Subscribers Publisher

NAL b NAL b Gestore Gestore Eventi Eventi (CRIC) (CRIC) NAL c NAL c NAL d NAL d
SIL SIL

NAL a NAL a

Event Channel: P&S per sistemi distribuiti

Disaccoppiamento di publishers e subscribers Presenza di un mediatore (gestore eventi)

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 relazioni tra loro Partecipanti interessati solo al cambiamento dei dati

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, storage, autenticazione

Esempio: MOM e JMS API

public class MySubscriber Event Channel realizzato dai sistemi MOM di Messaging {

public MySubscriber() { [] { [] public MyPublisher() /* Crea context, la ConnectionFactory, Connection, { Session */ /* Ricerca della factory per creare le connessioni col subscriber = session.createSubscriber(dest); message server */ new TextListener(); jndiContext Publisher listener == new InitialContext(); subscriber.setMessageListener(listener); connectionFactory = (ConnectionFactory) connection.start(); jndiContext.lookup("jms/TopicConnectionFactory"); } Topic //} Ricerca della destinazione (il Topic dei messaggi) Topic -------------destination = (Topic) jndiContext.lookup("MyTopic");

Messaging mediato da un Message Server [] public class MyPublisher

Message Server

Subscriber

Esempio JMS API:

public class TextListener implements MessageListener []{ //Metodo di callback per la public void sendATextMessage() ricezione dei messaggi public void onMessage(Message message) { { connection = connectionFactory.createConnection(); TextMessage msg = null; session = connection.createSession(); Administered Objects: incapsulano le specifiche if (message instanceof TextMessage) { implementazioni vendor-dependent dei provider JMS /* Creazione del proxy per la comunicazione */ msg publisher= =(TextMessage) message; session.createPublisher(destination); (Destination,content = msg.getText(); ConnectionFactory) String message = session.createTextMessage(); [] Oggetti producer/consumer per linvio e la ricezione dei message.setText(Hello!); } publisher.publish(message); messaggi (TopicPublisher, TopicSubscriber, MessageListener) } connection.close(); } } }

Publisher

Subscriber

Broker

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
Server Client

NAL b NAL b NAL a NAL a Broker/ Broker/ Orchestrator Orchestrator NAL c NAL c NAL d NAL d
SIL SIL

Architettura CART
Previsto un modello di comunicazione basato su richieste di servizio Presenza di un coordinatore di servizio (Broker/Orchestrator)

Web Services + Broker

Architettura CART per larchitettura SOA

WebService Orchestrator mediatore della comunicazione
Riceve richieste di servizio dal NAL Determina la locazione del destinatario Determina le modalit di invocazione Comunica col NAL di destinazione invocando il servizio

La componente presente sul CRIC mantiene un registry dei servizi e fornisce API per la registrazione dei servizi

CRIC CRIC
WebServices Orchestrator

registry

NAL a NAL a
Proxy applic.

NAL b NAL b
Proxy applic.

SIL a1 SIL a1

SIL a2 SIL a2

SIL b1 SIL b1

SIL b2 SIL b2

Architectural Pattern Broker

Architettura SOA ben rappresentata dal pattern Broker The Broker architectural pattern can be used to structure
distributed software systems with decoupled components that 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 implementazione)

Soluzioni
Introduzione del broker Invocazione dei servizi sotto forma di messaggi di chiamata indirizzati al broker

Architectural Pattern Broker: Struttura

Fornitore di servizi: Server

Implementano i servizi e li espongono tramite interfacce Descrizione di interfacce: formati IDL (per i WS: WSDL) 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 sensi

Proxy
Rappresentano loggetto 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, comunicazione, 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 comunicazione Il Broker inizializza la connessione indicando al client 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, Stal, Pattern-Oriented Software Architecture, Wiley 2001 [Fow03] M.Fowler, Patterns of Enterprise Application Architecture, 2003