architectural patterns etoscana - 20040217
Post on 10-Oct-2014
27 Views
Preview:
TRANSCRIPT
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
top related