Architectural Patterns eToscana - 20040217

Click here to load reader

  • date post

    10-Oct-2014
  • Category

    Documents

  • view

    17
  • download

    4

Embed Size (px)

Transcript of Architectural Patterns eToscana - 20040217

Seminario e-ToscanaFirenze, 17-18 febbraio 2004

Architectural Patternsschemi di progetto per architetture software

Enrico Vicario, Fabrizio BaldiniDipartimento 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 diIntegrazione, 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 diversinew 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 Idiomsdettaglio

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 svolgonodifferenti 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 componentiAn 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 interactiveapplication 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 modelloNecessit 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 CRCNucleo 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 nucleofunzionale 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 complesseModel Model View View

Controller Controller

Collaborazioni La vista associata al modelloRiceve 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 Diagram1: 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 comunicazionetra componenti: meccanismo Change Propagation1.