TRANSFORMATION ENGINE

Transcript

1 TRANSFORMATION ENGINE DOMAIN DEFINITION DOCUMENT Realizzato da: Fantastici5 & Pappa Team Riccardo Biondi Jacopo Cirrone Daniel Gustav Indelicato Alessandro Nicolosi Giancarlo Romeo Alberto Palazzo Francesco Pantano Luca Porcaro Sebastiano Russo Giuseppe Salerno Marco Sapienza

2 Sommario 1. Cos è il Transformation Engine? 2. Il Transformation Engine nel sistema 2.1. Il Transformation Engine e gli altri moduli 2.2. Le interazioni con gli altri moduli Visualizzazione web di dati e layout associato Visualizzazione in formato PDF dei dati e del layout associato Visualizzazione in formato CSV dei dati e del layout associato Visualizzazione Mobile dei dati e del layout associato Visualizzazione del layout di una determinata form 3. Le funzioni del Transformation Engine 4. Architettura del Transformation Engine 4.1. Il Transformation Engine µ-core 4.2. Il Plug-in System XHTML per Web e Mobile Esportazione in file PDF Esportazione in file CSV 5. Metodologia utilizzata (Scrum) 5.1. Product Backlog 5.2. Daily Scrum Meeting, 7 febbraio 5.3. Daily Scrum Meeting, 8 febbraio 5.4. Daily Scrum Meeting, 9 febbraio 5.5. Daily Scrum Meeting, 10 febbraio 5.6. Daily Scrum Meeting, 11 febbraio 2

3 1 Cos è il Transformation Engine? Il Transformation Engine è uno dei moduli che costituiscono la web application Rich Form Engine, ed è responsabile delle attività di trasformazione del formato intermedio (XML) nei diversi formati supportati. Le funzionalità messe a disposizione dal Transformation Engine permettono di effettuare operazioni come risposta alle richieste provenienti dal modulo Dispatcher (Servlet). In relazione alla tipologia di terminale che effettua la richiesta, che sia Web o Mobile (Touch) Browser, il modulo si occupa di formattare i dati in modo che siano interpretabili correttamente dal dispositivo utilizzato. Le operazioni di formattazione dei dati vengono svolte da opportuni plug-in, uno per ogni tipologia di formato supportato, che vengono interrogati ogni qual volta si renda necessaria una conversione. Allo stato attuale, i plug-in che sono stati pensati offrono le seguenti funzionalità: XHTML per Web (sia in visualizzazione che in modifica); XHTML per Mobile (sia in visualizzazione che in modifica); Esportazione in file PDF; Esportazione in file CSV. Il sistema a plug-in rende semplice il supporto verso nuovi formati di esportazione che potranno essere sviluppati in futuro. 3

4 2 Il Transformation Engine nel sistema 2.1 Il Transformation Engine e gli altri moduli Il Transformation Engine si colloca, a livello architetturale, all interno del modulo rappresentante il Core Engine dell applicazione e, come da design, prevede un interazione con la maggior parte dei moduli che lo costituiscono. Fig. 1.1 Schema generale dell architetttura. Le relazioni inter-modulari avvengono attraverso la comunicazione con i seguenti blocchi: Dispatcher (Servlet): ricevuta la richiesta dell operazione da effettuare (attraverso un opcode), effettua la chiamata al Transformation Engine corrispondente al tipo di informazioni da recuperare; Data Manager: consente al Transformation Engine l accesso ai dati delle form compilate. E l unico modulo, insieme all Admin Tool, ad avere accesso al Database; Intermediate Format Engine: fornisce al Transformation Engine i metodi per il recupero dei layout delle form (salvati in formato XML); Plug-in: è l insieme dei moduli che consentono la trasformazione nel formato corretto. 4

5 2.2 Le interazioni con gli altri moduli L uso dei Sequence Diagrams consente di esplicitare l interazione del Transformation Engine con i vari moduli coinvolti. Si precisa che i metodi descritti sono generalizzati ed hanno semplicemente lo scopo di descrivere le comunicazioni tra i vari componenti. I primi tre scenari descritti presentano la richiesta da parte del Dispatcher di visualizzazione dei dati e dei layout rispettivamente per il Web Browser, per il Mobile Browser e per l esportazione nei formati PDF e CSV Visualizzazione web di dati e layout associato Fig Sequence Diagram relativo alla visualizzazione web di dati e layout associato 5

6 2.2.2 Visualizzazione in formato PDF dei dati e del layout associato Fig Sequence Diagram relativo alla visualizzazione in formato PDF di dati e layout associato Visualizzazione in formato CSV dei dati e del layout associato Fig Sequence Diagram relativo alla visualizzazione in formato CSV di dati e layout associato 6

7 2.2.4 Visualizzazione Mobile dei dati e del layout associato Fig Sequence Diagram relativo alla visualizzazione Mobile dei dati e del layout associato Visualizzazione del layout di una determinata form Fig Sequence Diagram relativo alla visualizzazione del layout di una determinata form 7

8 3 Le funzioni del Transformation Engine L attività principale del Transformation Engine consiste nel processamento delle richieste provenienti dal Dispatcher, e la visualizzazione in uscita dei dati con la formattazione corretta. Per fare ciò è prevista un interfaccia esterna che riceve le richieste di visualizzazione e le smista al modulo opportuno. Nel caso in cui sia richiesta la visualizzazione di un template, viene interrogato il modulo Intermediate Format Engine che restituisce il layout in XML; se invece la richiesta riguarda una form compilata viene interrogato anche il Data Manager, che recupera dal Database i dati associati al layout e all utente, e li ritorna al Transformation Engine. Una volta ricevuti i dati correttamente, questi vengono passati al plugin le cui funzionalità rispettano i canoni della chiamata. Il plugin ha il compito di ricostruire la struttura nel formato corretto a partire dal formato intermedio e aggiungere i dati nel caso siano richiesti. Alla fine di questa operazione viene restituito il tutto al Transformation Engine che termina il proprio compito restituendo al Dispatcher il risultato della sua interrogazione. I metodi forniti dal Transformation Engine sono elencati e descritti di seguito: String getview(int id_utente, int id_layout, TypeDisp td) Tale metodo viene utilizzato dal Dispatcher per richiedere una determinata form compilata da un determinato utente, quindi layout e relativi dati. I parametri d ingresso da passare sono: o id_utente, identifica univocamente l utente che richiede la visualizzazione. o id_layout, identifica univocamente la form compilata, o td, è un enumeratore che esplicita la tipologia del dispositivo, così da poter conoscere la corretta formattazione dei dati da restituire. Tale funzione restituisce la form compilata in formato HTML sotto forma di String. 8

9 String getview(int id_layout, TypeDisp td) Tale metodo viene utilizzato dal Dispatcher per richiedere solo un determinato template, quindi privo di dati. I parametri d ingresso da passare sono: o o id_layout, identifica univocamente il layout richiesto. td, è un enumeratore che esplicita la tipologia del dispositivo, così da poter conoscere la corretta formattazione dei dati da restituire. Esso restituisce il layout richiesto in formato html sotto forma di String. 9

10 4 Architettura del Transformation Engine 4.1 Il Transformation Engine µ-core Il Transformation Engine µ-core è quel modulo che riceve le chiamate dall esterno ed ha il compito di invocare il corretto plug-in per la trasformazione dei dati. L output passato da questo modulo ai vari plug-in è rappresentato da un oggetto che farà da wrapper sia per i dati che per il layout. Sarà compito del plug-in interrogato effettuare l estrazione dei dati e del layout dall oggetto applicando l opportuna formattazione. 4.2 Il Plug-in System Fig Schema del Transformation Engine Il Plug-in System, attraverso la definizione di semplici interfacce di comunicazione coi diversi moduli, consente la corretta invocazione per la trasformazione dei dati ed il rapido supporto di nuovi formati di esportazione. 10

11 Allo stato attuale, i plug-in che sono stati pensati offrono le seguenti funzionalità: XHTML per Web (sia in visualizzazione che in modifica); XHTML per Mobile (sia in visualizzazione che in modifica); Esportazione in file PDF; Esportazione in file CSV XHTML per Web e Mobile Questo plug-in ha il compito di trasformare i dati ed il layout in formato XHTML per la corretta visualizzazione nel dispositivo che ne effettua la richiesta. Dal punto di vista del T.E. ci si aspetta che questo plug-in esponga un metodo che riceva in ingresso i dati prelevati dal Data Manager e i layout forniti dal F.I.M. organizzati all interno di un oggetto wrapper. Tale chiamata restituirà la struttura adeguata che verrà instradata al modulo che fornirà la vista richiesta. Si precisa che, da un primo meeting, si è deciso che allo sviluppo di tali plugins concorrano altri team Esportazione in file PDF Questo plug-in offre un metodo di invocazione, che accetta in ingresso i dati da esportare in pdf e il layout della form (per agevolare la formattazione) li elabora in un file pdf e li ritorna al T.E., il quale provvederà ad inoltrarli al modulo richiedente tramite il Dispatcher Esportazione in file CSV Questo plug-in riceve in input i dati e il layout XML ad essi associato dal T.E, li elabora in un file CSV e li ritorna al Trasformation Engine, il quale provvederà ad inoltrarli al modulo richiedente tramite il Dispatcher. 11

12 5.1 Product Backlog Il product backlog si compone di User stories e costituisce una specifica in divenire per il prodotto. Contiene le linee guida ad alto livello ed è accessibile pubblicamente, Garantisce al committente che le proprie richieste sono state recepite e indica al team quali sono i traguardi e i futuri sviluppi. Può essere rivisto in momenti diversi ma ufficializzato in linee di produzione solo tra uno sprint e l altro. Il 7 febbraio 2011, durante un Dalily Scrum Meeting tra i team che si occupano del Transformation Engine, è stato anche redatto il seguente Product Backlog allo scopo di organizzare e distribuire in modo chiaro il lavoro dei prossimi Sprint. Priority Description Time Who - SPRINT 1 - RFE PROJECT DESIGN 1 WEEK Very High RFE Project Design 3 days FF + PPT High Domain definition document 2 days FF + PPT Normal Development tools setup 1/2 day ALL - SPRINT 2 - TRANSFORMATION ENGINE DESIGN 1 WEEK Very High Design del Transformation Engine µ-core 2 days FF + PPT High Design del Plug-in System 2 days FF + PPT Normal Design del Plug-in per l esportazione in PDF 1/2 day FF + PPT Normal Design del Plug-in per l esportazione in CSV 1/2 day FF + PPT - SPRINT 3 - TRANSFORMATION ENGINE CODE 2 WEEKS Very High Transformation Engine µ-core Code e Unit Testing 3 days TBD Very High Plug-in System Code e Unit Testing 5 days TBD Normal Plug-in per l esportazione in PDF e Unit Testing 3 days TBD Normal Plug-in per l esportazione in CSV e Unit Testing 3 days TBD - SPRINT 4 - INTEGRATION 1 WEEK Very High Integration with other modules ALL - SPRINT 5 - EVALUATION 1 WEEK High Evaluation ALL ALL: All teams FF: Fantastic Five PPT: PAPPA TEAM TBD: To be defined Tab. 5.1 Product backlog 12

13 5.2 Daily Scrum Meeting, 7 febbraio Le attività svolte durante il Daily Scrum Meeting del 7 febbraio sono state: Sprint Planning E stato organizzato e definito il lavoro da svolgere durante lo Sprint 1 (RFE Project Design). Sprint Retrospective Si è considerato il lavoro svolto durante il precedente Application Domain Definition e si è cercato di giungere ad una soluzione architetturale che soddisfacesse i requisiti dettati dai casi d uso ottenuti dall interazione con il cliente. RFE Project Design Durante l incontro sono state abbozzate le diverse proposte fino a raggiungere un architettura che rispondesse alle esigenze prefissate. Il risultato del lavoro, composto principalmente da schemi e diagrammi informali, è stato successivamente rivisto ed affinato scendendo ad un livello che permettesse di distinguere l esatta divisione dei moduli e le modalità di interazione. Sprint Impediments L aver definito l architettura generale dell intero sistema ha fatto emergere l esigenza di definire meglio le interazioni con i team che si occupano dei moduli a contatto con il nostro. A tale scopo è stato concordato un ulteriore Daily Scrum Meeting per il giorno successivo. 5.3 Daily Scrum Meeting, 8 febbraio Le attività svolte durante il Daily Scrum Meeting dell 8 febbraio sono state: Sprint Retrospective Partendo dai diagrammi realizzati nel precedente Daily Scrum Meeting, è stato indetto un incontro con i rappresentanti degli altri moduli allo scopo di definire con un livello di dettaglio maggiore le reciproche interazioni. RFE Project Design La discussione volta soprattutto all accoglimento e la valutazione delle diverse soluzioni proposte ha avuto come prodotto finale la realizzazione dello schema architetturale illustrato in Figura 1. Requirements Document E stato impostata la struttura e realizzata la prima bozza del presente documento. 13

14 5.4 Daily Scrum Meeting, 9 febbraio Le attività svolte durante il Daily Scrum Meeting del 9 febbraio sono state: Requirements Document La riunione è stata fatta online attraverso lo strumento Google Docs nel quale il presente documento è stato condiviso tra i membri di entrambi i team di sviluppo. E stato continuato il lavoro di definizione delle interazioni inter-modulari (esterne). 5.5 Daily Scrum Meeting, 10 febbraio Le attività svolte durante il Daily Scrum Meeting del 10 febbraio sono state: Requirements Document La riunione è stata fatta online attraverso lo strumento Google Docs nel quale il presente documento è stato condiviso tra i membri di entrambi i team di sviluppo. E stato continuato il lavoro di definizione dei vari moduli e delle interazioni intramodulari (interne) con i plug-in. 5.6 Daily Scrum Meeting, 11 febbraio Le attività svolte durante il Daily Scrum Meeting del 11 febbraio sono state: Requirements Document La riunione è stata fatta online attraverso lo strumento Google Docs nel quale il presente documento è stato condiviso tra i membri di entrambi i team di sviluppo. E stato concluso il documento. 14