1. UNIVERSIT DEGLI STUDI DI TRIESTE DIPARTIMENTO DI INGEGNERIA E ARCHITETTURA Corso di Laurea Magistrale in Ingegneria InformaticaTesi di laurea in Reti di CalcolatoriStudio e implementazione di uno strumento di configurazione e visualizzazione di dati di progetto, nellambito delle applicazioni CAE (Computer Aided Engineering)LAUREANDORELATOREMatteo MiottoProf. Alberto Bartoli CORRELATOREIng. Sergio BenedettiAnno accademico 2012/2013

2. Alla mia famiglia 3. INDICEIndice 1Introduzione ......................................................................................................... 12Analisi .................................................................................................................. 3 2.1Scenario ......................................................................................................... 32.1.1Sviluppo Agile ....................................................................................... 32.1.2Lapplicazione esistente: SOMO ........................................................... 42.1.3Opportunit di personalizzazione in SOMO .......................................... 52.2Requisiti ........................................................................................................ 62.2.1 2.2.2Personalizzare la dashboard di SOMO .................................................. 92.2.3 3Widget e Page Editor ............................................................................. 7Page Manager ...................................................................................... 11Progettazione ..................................................................................................... 13 3.1User Experience: Principi e processi di progettazione ................................ 133.2Page Editor e Widget .................................................................................. 143.2.1F-shaped pattern e layout ..................................................................... 143.2.2Widget .................................................................................................. 183.3 3.4 4I widget per la dashboard di SOMO ........................................................... 21 Page Manager .............................................................................................. 23Interfaccia .......................................................................................................... 25 4.1 4.2Personalizzare una pagina ........................................................................... 264.3 5Accedere al Page Editor .............................................................................. 25Gestire molteplici pagine personalizzate .................................................... 29Implementazione ................................................................................................ 33 5.1Page Editor .................................................................................................. 33 4. INDICE5.1.1Integrazione in SOMO ......................................................................... 335.1.2Design Area ......................................................................................... 355.1.3Caricamento asincrono dei widget nella design area ........................... 385.1.4Il managed bean per il Paged Editor .................................................... 405.1.5Salvataggio di una pagina .................................................................... 425.1.6Widget store e aggiunta di un widget alla design area ........................ 465.2Widget ......................................................................................................... 475.2.1Linee guida per lo sviluppo di un widget ............................................ 475.2.2Managed bean: soluzione proposta dai widget per la dashboard diSOMO ............................................................................................................. 50 5.3Accesso ai dati............................................................................................. 525.3.1 5.3.2 6Estensione del database esistente ......................................................... 52 JPA: Implementazione di Entity e Session EJB .................................. 53Conclusioni ........................................................................................................ 59Riferimenti ................................................................................................................. 61 5. Capitolo 1 - INTRODUZIONE1 Introduzione Lo scopo di questo lavoro di tesi progettare e realizzare uno strumento che consenta allutente di una specifica applicazione web di configurare le informazioni che desidera visualizzare e utilizzare, personalizzando cos la propria esperienza duso. Lapplicazione web considerata SOMO: tale applicazione permette ai professionisti di unorganizzazione, anche geograficamente distribuita, il controllo e la collaborazione nella progettazione (modellazione, simulazione, raccolta e analisi dei dati) e nello sviluppo di un prodotto in ambito ingegneristico. Le diverse responsabilit, competenze e necessit degli utenti di SOMO motivano la ricerca di uno strumento per la personalizzazione delle informazioni. Si vuole dunque passare dal paradigma unapplicazione per tutti gli utenti a quello unapplicazione per ogni utente. Il lavoro di tesi stato svolto presso ESTECO S.p.A., azienda operante nel campo dellottimizzazione numerica, specializzata nella ricerca e nello sviluppo di prodotti software utilizzati in ambito ingegneristico, tra i quali SOMO. Il risultato ottenuto si identifica in: Un editor integrato in SOMO, detto Page Editor, che permette la creazione e la gestione di pagine personalizzate. La personalizzazione si concretizza attraverso il posizionamento, il ridimensionamento e la configurazione di generici componenti, ai quali ci si riferir in seguito con il termine widget.La definizione di linee guida e la realizzazione di un sistema di partenza che consentano a sviluppatori di terze parti di costruire widget utilizzabili in SOMO.Lo sviluppo di tre widget con lo scopo di dimostrare lutilizzo del Page Editor nella personalizzazione della pagina dashboard di SOMO.1 6. Capitolo 1 - INTRODUZIONEAl momento della scrittura di questo documento, nelle applicazioni web impiegate in ambito ingegneristico non si possono apprezzare soluzioni simili a quella proposta. I tratti innovativi presenti nel lavoro di tesi sono da ricercare nelle tecnologie utilizzate. La peculiarit dello strumento realizzato infatti la possibilit di essere utilizzato mediante browser web, senza la necessit di installare alcun componente aggiuntivo. Durante il lavoro di tesi si provveduto a: Studiare le tecnologie necessarie, quali HTML5, CSS3, JavaScript, JSF (JavaServer Faces) e JPA (Java Persistence Api).Affrontare le fasi dello sviluppo seguendo i principi proposti dalle metodologie Agile, con particolare riferimento al framework Scrum.I vincoli di progetto impongono luso esclusivo delle tecnologie HTML, CSS e JavaScript per il lato client e della piattaforma JavaEE (Java Enterprise Edition) per il lato server. Nel capitolo 2 si affrontano lanalisi dei requisiti e la descrizione dello scenario nel quale si inserisce il lavoro di tesi. Nel capitolo 3 viene dato ampio spazio alla progettazione della User Experience (UX) e dei principali componenti da implementare. Nel capitolo 4 si presenta un esempio duso di quanto prodotto in questo lavoro di tesi. Infine, nel capitolo 5, si descrivono gli aspetti implementativi pi significativi dei principali componenti software realizzati.2 7. Capitolo 2 - ANALISI2 Analisi 2.1Scenario2.1.1Sviluppo AgileLo sviluppo Agile un particolare approccio allo sviluppo software. Sebbene esistano numerose incarnazioni di tale approccio, tutti i metodi agili enfatizzano i seguenti principi, enunciati nel Agile Manifesto [1] formulato nel 2001: Lavoro di gruppo.Frequenti rilasci di funzionalit software completamente funzionanti.Stretta collaborazione con i clienti.Capacit di rispondere velocemente ai cambiamenti tecnologici, del mercato e dei requisiti.Tra le diverse metodologie agili disponibili, possibile scegliere quella pi adatta ai propri scopi, personalizzarla, oppure fondere caratteristiche derivanti da diverse metodologie al fine di soddisfare particolari esigenze. Nello svolgimento del lavoro di tesi si fatto riferimento principalmente alla metodologia o, pi precisamente, al framework Scrum [2]. Ampiamente utilizzato nel contesto aziendale nel quale il lavoro di tesi stato svolto, Scrum propone un metodo di sviluppo iterativo e incrementale per ottimizzare la prevedibilit ed il controllo del rischio. Il cuore di Scrum uno sprint. Uno sprint un intervallo di tempo caratterizzato da una durata di al massimo un mese nel quale viene creato un incremento di prodotto potenzialmente rilasciabile. Ogni sprint pu essere considerato un progetto e contiene le fasi di pianificazione (analisi e definizione dei requisiti), progettazione, implementazione e validazione dei risultati. La breve durata di uno sprint e il ridotto numero di funzionalit prodotte consentono una rapida raccolta di feedback e la3 8. Capitolo 2 - ANALISIpossibilit, sprint dopo sprint, di far convergere agevolmente i risultati verso le idee dei clienti, spesso confuse. Nello svolgimento di questa tesi, il lavoro si concentrato principalmente in 3 sprint. In ognuno di questi si provveduto ad analizzare e definire i requisiti, progettare e implementare le funzionalit richieste. Per questo motivo, i capitoli e le sezioni riguardanti le fasi di sviluppo (analisi dei requisiti, progettazione e implementazione) sono organizzati in modo tale da evidenziare i risultati di ogni sprint. I risultati ottenuti negli sprint definiscono congiuntamente il prodotto finale del lavoro di tesi.2.1.2Lapplicazione esistente: SOMOCome gi anticipato, il lavoro di tesi stato svolto presso ESTECO S.p.A. [3]. Lazienda produce SOMO [4], unapplicazione web nella quale il risultato del lavoro di tesi trova applicazione. SOMO offre alle organizzazioni, anche geograficamente distribuite, un alto livello di controllo e collaborazione in tutte le fasi del processo di progettazione e sviluppo di un prodotto, permettendo di: Gestire risorse di calcolo condivise in HPC (High Performance Computing) e ambienti cloud pubblici.Immagazzinare i dati in ambiente centralizzato e sicuro.Organizzare laccesso, il versioning e il trasferimento di dati di simulazioni e ottimizzazioni.Definire piani di calcolo di Design Of Experiments (DOE) e ottimizzazioni multi obiettivo.Creare e gestire complessi progetti multidisciplinari.Analizzare i risultati attraverso strumenti interattivi e di reporting. possibile utilizzare SOMO da uno qualsiasi dei principali browser, senza la necessit di installare alcun componente aggiuntivo.4 9. Capitolo 2 - ANALISI2.1.3Opportunit di personalizzazione inSOMO Allinterno di una stessa organizzazione, nellambito di un progetto multidisciplinare, SOMO permette la collaborazione ad utenti con responsabilit, competenze e necessit differenti. Ci permette di individuare, allinterno dellapplicazione web, delle aree in cui utenti diversi necessitano di informazioni diverse. Al momento della raccolta dei requisiti per il lavoro di tesi sono state individuate in SOMO due principali aree candidate alla personalizzazione: dashboard e report page. La dashboard la prima pagina che lutente visualizza dopo aver effettuato laccesso. Essa contiene informazioni sintetiche e aggiornate sullo stato del lavoro dellutente allinterno di SOMO. La report page una pagina che permette allutente di monitorare lo stato di una sessione di ottimizzazione/simulazione in esecuzione o di valutare i risultati di una sessione terminata. Questa pagina si propone come un avanzato strumento interattivo di reporting e analisi dei dati.Figura 2.1 La report page di SOMOLa candidatura alla personalizzazione di queste due pagine non casuale. In esse, infatti, possibile individuare blocchi informativi ben delineati che, per utenti diversi, possono: Essere necessari o meno. 5 10. Capitolo 2 - ANALISIAvere livelli di importanza differenti.Presentare troppe o troppe poche informazioni.Essere resi disponibili solo se dispongono delle autorizzazioni necessarie.Componendo a piacimento i vari blocchi informativi e personalizzandone ognuno individualmente, lutente ha la possibilit di: Visualizzare solamente le informazioni necessarie ai propri scopi e consentite per il ruolo ricoperto.Posizionare in primo piano le informazioni che ritiene pi importanti.Aumentare o ridurre la complessit delle informazioni visualizzate a seconda delle necessit.Nellambito di questo lavoro di tesi si provveduto a rendere personalizzabile, a titolo dimostrativo, solamente la pagina dashboard di SOMO. Il principale scopo della tesi, infatti, non quello di concentrarsi sulla personalizzazione di una particolare pagina, ma quello di ideare e realizzare uno strumento che permetta di personalizzare, in generale, una qualsiasi pagina di SOMO.2.2RequisitiIn precedenza stato presentato SOMO e le sue caratteristiche principali. stata inoltre analizzata la possibilit di personalizzare alcune delle sue sezioni, come ad esempio la dashboard. Trattandosi di unapplicazione web, con il termine sezione si fa riferimento essenzialmente ad una particolare pagina. Lo strumento che si vuole realizzare dovr dunque permettere la composizione e la personalizzazione di pagine di unapplicazione web attraverso lutilizzo e la configurazione di particolari componenti base, denominati widget. In seguito si definiranno: Il concetto di widget e i requisiti desiderati per lo strumento di personalizzazione di una pagina.I requisiti per i widget della dashboard di SOMO.6 11. Capitolo 2 - ANALISII requisiti per lo strumento di gestione di molteplici pagine personalizzate create da un utente.2.2.1Widget e Page EditorUn widget pu essere definito come un contenitore di informazioni configurabili. Esso deve rappresentare unentit indipendente, ossia non deve scambiare informazioni con altri widget e deve poter essere utilizzato in modo autonomo. Un widget si compone essenzialmente di una parte relativa al contenuto, ossia le informazioni, e di una parte relativa alle configurazioni applicabili. Al fine di garantire allutente la massima capacit di composizione e personalizzazione di una pagina, un widget dovrebbe contenere informazioni quanto pi omogenee. Le possibili configurazioni applicabili possono essere di qualsiasi tipo. Esempi di configurazione possono essere la scelta delle colonne da visualizzare in una tabella, lapplicazione di un particolare filtro sui dati rappresentati in un grafico, etc. Le responsabilit di definizione del contenuto e delle possibilit di configurazione sono, comunque, delegate al produttore del widget. I produttori di widget sono principalmente gli sviluppatori dellapplicazione web. Non si vuole precludere per la possibilit che, in futuro, sviluppatori di terze parti producano i propri widget da utilizzare allinterno di SOMO. Si rende perci necessaria la definizione di linee guida per la costruzione dei widget, cos da uniformarne la struttura e il funzionamento. La costruzione di un widget, oltre alla definizione del contenuto informativo e delle configurazioni applicabili, passa anche attraverso la definizione di alcuni suoi attributi, quali: Categoria: Corrisponde al tipo di informazioni contenute nel widget. Un widget pu appartenere ad una sola categoria. Esempi di categorie possono essere testo, tabella, grafico, etc.Scope: Definisce lambito di applicazione, ossia la sezione (pagina) nella quale il widget pu essere utilizzato. Ad esempio possibile definire che lo scope di un generico widget X la pagina dashboard.7 12. Capitolo 2 - ANALISIDimensioni di default: Ossia le misure, secondo una qualche metrica, di altezza e larghezza predefinite.Dopo aver definito i requisiti dei widget, si procede con la descrizione delle caratteristiche desiderate per lo strumento destinato alla loro manipolazione, denominato Page Editor. Si desidera che il Page Editor sia in grado di personalizzare, in linea teorica, una qualsiasi pagina di SOMO. Il suo funzionamento deve essere indipendente dal contenuto dei widget che controlla e dalle configurazioni ad essi applicabili. In altre parole, esso deve trattare i widget come black-box delle quali conosce e gestisce solamente dimensioni e posizione allinterno di una pagina. Di seguito sono elencate le caratteristiche e le funzionalit desiderate per il Page Editor: Deve esser possibile consultare una lista dei widget disponibili per la pagina (scope) che si desidera personalizzare, ordinati secondo la categoria dappartenenza.Nellambito della pagina da personalizzare, deve esser possibile eseguire le seguenti operazioni sui widget disponibili: o Aggiunta di un widget. Uno stesso widget pu essere inserito un numero di volte arbitrario allinterno di una pagina. o Rimozione di un widget. o Posizionamento di un widget. o Ridimensionamento di un widget. o Configurazione di un widget.I widget contenuti nella pagina devono rappresentare informazioni reali, cos che lutente disponga di unanteprima fedele delle informazioni contenute nella pagina.In un widget, la modifica e lapplicazione delle configurazioni devono innescare laggiornamento delle informazioni in esso contenute.La composizione di una pagina, i cambiamenti apportati e le configurazioni applicate ai widget contenuti nella pagina devono essere resi persistenti solo nel momento in cui lutente lo desidera.8 13. Capitolo 2 - ANALISIIl Page Editor, in generale, dovr essere accessibile da qualsiasi pagina di SOMO considerata personalizzabile.2.2.2Personalizzare la dashboard di SOMOCome anticipato nella sezione 2.1.3, si vuole rendere personalizzabile la dashboard di SOMO. Loperazione di rendere personalizzabile un pagina consiste nel ricercare al suo interno gruppi di informazione che definiranno i widget. In generale, i principali obiettivi di uno strumento dashboard sono: Presentare allutente le informazioni pi importanti, provenienti da unampia quantit di dati e da pi sorgenti, nel modo pi semplice e veloce possibile.Evidenziare particolari criticit o eventi che richiedono lattenzione dellutente.Monitorare processi in tempo reale.La dashboard attualmente presente in SOMO consente allutente di visualizzare lo stato del suo lavoro allinterno dellapplicazione. Essa suddivisa in tre blocchi principali: Projects: Contiene le informazioni sui progetti ai quali lutente ha accesso. possibile verificare il numero totale di progetti, cos come il numero di progetti caricati dallutente. anche disponibile una panoramica degli ultimi progetti ai quali lutente ha lavorato, presentata sotto forma di tabella. Le colonne di tale tabella sono Project Name, Creator e Created e corrispondono al nome del progetto, al nome dellutente che lo ha creato e alla data e ora di creazione.My Workspaces: Contiene le informazioni sui workspace ai quali lutente assegnato. Le informazioni sui workspace vengono presentate allutente mediante una tabella. Le colonne di tale tabella sono Workspace Name, Description e Created e corrispondono al nome del workspace, ad una breve descrizione e alla data e ora di creazione.Sessions: Contiene le informazioni sulle valutazioni (sessioni di ottimizzazione e/o simulazione) eseguite dallutente, sia completate che in esecuzione. Tali informazioni vengono presentate mediante due tabelle, una per le valutazioni9 14. Capitolo 2 - ANALISIterminate e una per quelle ancora in corso. Entrambe le tabelle presentano le stesse colonne, ossia Status, Category, Session Name, Project Name, Submitter e Created e corrispondono allo stato dellesecuzione (Pending, Completed, Error), al tipo di valutazione, al nome della sessione, al nome del progetto nellambito del quale la valutazione viene eseguita, al nome dellutente che ha eseguito la valutazione e alla data e ora di esecuzione.Figura 2.2 - La dashboard di SOMOLa definizione dei widget, in questo contesto, si rivela immediata dato che le informazioni sono gi raggruppate in tre blocchi ben definiti, ossia quelli sopra citati. Dato che le informazioni in Projects, My Workspaces e Sessions sono presentate in forma tabellare, i corrispondenti widget apparterranno alla categoria tabella. Essi avranno inoltre come scope la pagina dashboard e presenteranno le stesse informazioni contenute nei blocchi sopra descritti. Le configurazioni possibili per questi widget sono piuttosto limitate. Per tutti e tre si vuole offrire allutente lopportunit di scegliere se visualizzare o nascondere ogni colonna definita nelle tabelle. La tabella seguente riassume le informazioni contenute nei widget della dashboard di SOMO e le configurazioni ad essi applicabili.10 15. Capitolo 2 - ANALISIPROJECTSMY WORKSPACESSESSIONSSCOPEDashboardDashboardDashboardCATEGORIATabellaTabellaTabellaProject NameWorkspacesStatusCreatornameCategoryCreatedDescriptionSession NameCreatedProject NameSubmitterCreatedINFORMAZIONI VISUALIZZATE (colonne)CONFIGURAZIONIRendiRendiRendiPOSSIBILIvisibile/nascostavisibile/nascostavisibile/nascostaogni colonnaogni colonnaogni colonna2.2.3Page ManagerFino ad ora sono state definite le caratteristiche e le funzionalit del Page Editor e dei widget che permetteranno ad un utente di personalizzare una determinata pagina di SOMO, come la dashboard o la report page. A questo meccanismo di personalizzazione si vuole aggiungere unulteriore funzionalit, ossia uno strumento che permetta allutente di creare e gestire diverse versioni personalizzate di una stessa pagina di SOMO. In questo modo lutente, ad esempio, avr la possibilit di creare pi dashboard personalizzate, modificarle, eliminarle e scegliere quella da utilizzare in base alle proprie necessit. In seguito ci si riferir alle diverse versioni personalizzate di una sezione di SOMO con il generico termine pagina. Anche se esula dagli scopi di questo lavoro di tesi, si vuole sottolineare come un tale strumento di gestione delle pagine personalizzate possa aprire gli spiragli a funzionalit quali la condivisione di pagine tra gli utenti di una stessa organizzazione, di uno stesso workspace, ecc. In questo modo, ad esempio, gli utenti potrebbero creare11 16. Capitolo 2 - ANALISIe condividere le pagine personalizzate create ad un gruppo di utenti, gestendo i permessi di modifica e utilizzo. Le caratteristiche e le funzionalit desiderate per lo strumento di gestione delle pagine, denominato Page Manager, sono le seguenti: Deve essere possibile accedere al Page Manager direttamente dal Page Editor.Nellambito di una particolare sezione di SOMO (dashboard, report page, ) lo strumento deve visualizzare tutte le versioni personalizzate create dallutente. Per ognuna di esse devono essere presentate le seguenti informazioni: o Anteprima della pagina, sotto forma di immagine. o Nome della pagina. o Data di creazione.Le possibili operazioni sulle pagine, intese come versioni personalizzate di una pagina di SOMO, sono le seguenti: o Creazione di una nuova pagina. o Modifica di una pagina esistente: Questa operazione comporter lapertura del Page Editor per permettere la modifica della pagina scelta. o Rimozione di una pagina esistente. o Impostazione di una pagina come corrente. Mediante questa operazione lutente sceglie, tra le diverse versioni create, quella che desidera utilizzare. Ad esempio, nel caso un utente abbia creato pi pagine personalizzate per la dashboard, potr scegliere quale di queste verr visualizzata durante il normale utilizzo della dashboard di SOMO.12 17. Capitolo 3 - PROGETTAZIONE3 Progettazione 3.1User Experience: Principi eprocessi di progettazione Nella progettazione di ogni componente si prestata molta attenzione alla User Experience (UX). In tutta la fase di progettazione, si fatto riferimento ai seguenti principi [5]: Ridurre i concetti, aumentare la semplicit e la familiarit a. stato introdotto un nuovo concetto? Perch? necessario? coerente con i concetti gi presenti? b. possibile rimuovere concetti non necessari e le distrazioni? c. possibile ridurre la complessit delle informazioni presentate allutente? d. C un modo pi semplice per risolvere il problema o per presentare i dati?Attenzione ai piccoli dettagli a. Preferire poche funzionalit completamente funzionanti a molte mal funzionanti. b. Curare le interazioni con lutente, anche le pi semplici.Il tempo conta a. Attenzione alle performance. b. Evitare che processi prolungati obblighino lutente a lunghe attese che impediscano linterazione con lapplicazione. c. Chiedere conferma solo prima di eseguire operazioni irrevocabili. d. Mettere in primo piano le informazioni che contano veramente, cos che possano essere consultate velocemente.13 18. Capitolo 3 - PROGETTAZIONELa progettazione di tutte le principali funzionalit (Page Editor, Widget e Page Manager) si svolta sulla base del processo design thinking [6] [7] che si articola essenzialmente nelle seguenti fasi: 1. Definizione: Consiste nel comprendere il problema da risolvere, definire i parametri per valutare la futura soluzione, ricercare informazioni utili alla risoluzione del problema, raccogliere esempi di soluzioni a problemi simili e discutere con clienti e utenti. 2. Ideazione: Ha come obiettivo la generazione del maggior numero di idee possibili per la risoluzione del problema. 3. Decisione: Consiste nel valutare le idee generate e scegliere, tra queste, la migliore. 4. Modellazione: Prevede la creazione di mockup e prototipi della soluzione scelta. 5. Validazione: Consiste nel presentare agli utenti i risultati dei passi precedenti e raccogliere i feedback. Nelle seguenti sezioni verranno mostrati i risultati finali della fase di progettazione.3.2Page Editor e Widget3.2.1F-shaped pattern e layoutNel 2006, il ricercatore Jakob Nielsen dimostr [8] come, mediamente, gli utenti visualizzino le pagine web in modo predicibile, seguendo un pattern denominato Fshaped pattern. Secondo questo studio, condotto sfruttando tecniche di eye-tracking, i visitatori di pagine web assimilano in pochi secondi il contenuto di una pagina, disegnando con lo sguardo sullo schermo una traccia a forma di F.14 19. Capitolo 3 - PROGETTAZIONEFigura 3.1 - Heatmaps ricavate mediante tecniche di eyetrackingLa progettazione del layout del Page Editor stata condotta basandosi su tale pattern. Il risultato ottenuto mostrato in figura 3.2.Figura 3.2 - Layout del Page Editor (Mockup)Seguendo la numerazione proposta in figura 3.2, lanalisi del layout del Page editor permette di evidenziare le seguenti aree: 1. Menu di SOMO. Essendo integrato in SOMO, il Page Editor viene visualizzato allinterno dellapplicazione come una qualsiasi altra pagina. Il menu di SOMO permette di navigare verso le principali sezioni dellapplicazione.15 20. Capitolo 3 - PROGETTAZIONE2. Editor Action Pane. il pannello dedicato ad ospitare i comandi per le principali operazioni offerte dal Page Editor: a. Salvataggio della pagina che si sta personalizzando. b. Chiusura delleditor. c. Accesso al Page Manager. d. Possibilit di visualizzare/nascondere il widget store. 3. Widget Store: Questo panello contiene tutti i widget disponibili per la pagina che si sta personalizzando. Pu essere nascosto per facilitare la personalizzazione della pagina. 4. Design Area: Essenzialmente rappresenta la pagina che si sta personalizzando. In questarea verranno posizionati, ridimensionati e configurati i widget.3.2.1.1Widget StoreIl pannello relativo al widget store occupa lipotetica fascia verticale del sopracitato F-shaped pattern. Allinterno del widget store i widget sono raggruppati, secondo la categoria di appartenenza, in blocchi espandibili/comprimibili. In questo modo possibile semplificare la ricerca di un widget, escludendo categorie non necessarie ai fini della ricerca.Figura 3.3 - Blocco espandibile/comprimibile contenente i widget appartenti ad una particolare categoria (Mockup)Facendo riferimento alle lettere contrassegnate in figura 3.3, ogni blocco espandibile contiene: a. Nome categoria widget. b. Numero dei widget contenuti allinterno della categoria. c. Elemento (widget) della lista.16 21. Capitolo 3 - PROGETTAZIONEd. Icona del widget. Uno studio [9], svolto sulle pagine dei risultati del motore di ricerca Google, evidenza come i risultati contenenti anteprime (immagini, video, ecc) attirino maggiormente lattenzione dellutente rispetto a quelli senza. Inoltre, prodotti commerciali ampiamente usati come Microsoft Office, utilizzano nei pulsanti dei suoi menu la combinazione Icona-Descrizione per facilitare la comprensione delle azioni correlate. In questo contesto, luso di unicona aiuta lutente ad individuare il widget ricercato allinterno della lista. e. Nome del widget. f. Breve descrizione del widget.3.2.1.2Design AreaAl fine di semplificare il posizionamento e il ridimensionamento dei widget, larea che rappresenta la pagina da personalizzare viene suddivisa in numero n di colonne. Lampiezza delle colonne corrisponde alla dimensione minima (sia per laltezza che la larghezza) assumibile dai widget, detta dimensione base. La dimensione applicabile ai widget di una pagina sar un multiplo della dimensione base.Figura 3.4 - Organizzazione in colonne della design area: dimensionamento e posizionamento dei widget (Mockup)Nella design area possibile posizionare e ridimensionare un widget: Posizionamento:possibileposizionareapiacimentounwidgetsemplicemente trascinandolo allinterno della design area. Mentre la posizione orizzontale di un widget pu essere decisa arbitrariamente dallutente, quella17 22. Capitolo 3 - PROGETTAZIONEverticale viene automaticamente determinata, dato che i widget vengono verticalmente posizionati in pila. La posizione di un widget determinata da una coppia di coordinate: o La coordinata orizzontale corrisponde al numero della colonna occupata dallangolo in alto a sinistra del widget. Ad esempio, in figura 3.4 la posizione del widget di dimensione 3x3 avr coordinata orizzontale 2. o La coordinata verticale, determinata automaticamente, corrisponde alla somma delle altezze dei widget posizionati sopra a quello esaminato. Ad esempio, in figura 3.4, la posizione del widget di dimensione 6x2 avr coordinata verticale 4. Ridimensionamento: possibile impostare la dimensione di un widget trascinando langolo in basso a destra. La dimensione (altezza o larghezza o entrambe) del widget aumenter o diminuir di una quantit proporzionale alla dimensione base.3.2.2WidgetCome richiesto nella definizione dei requisiti, il Page Editor deve trattare i widget come black-box, ossia dei contenitori dei quali conosce e gestisce solamente dimensioni e posizione allinterno di una pagina. La progettazione dei widget ha portato alla definizione del componente widget container (Figura 3.5). Il widget container un contenitore in grado di racchiudere il contenuto del widget e trascinarlo e ridimensionarlo allinterno della design area.Figura 3.5 - Widget Container (Mockup)18 23. Capitolo 3 - PROGETTAZIONEAllinterno del widget container possibile, seguendo la numerazione considerata in figura 3.5, evidenziare le seguenti aree: 1. Widget Action Pane: un pannello che viene visualizzato solamente quando il cursore del mouse si trova allinterno del widget container. Il widget action pane contiene due pulsanti che permettono laccesso alla Widget Configuration View (vedi in seguito) e la rimozione del widget dalla design area. 2. Resize Grip: una piccola area triangolare che, se trascinata, permette il ridimensionamento del widget. 3. Widget Wrapper: larea in cui viene inserito il contenuto del widget, quello definito dal produttore. Il contenuto del widget, definito dal produttore dello stesso, deve essere composto da due viste (figura 3.6), che verranno alternativamente visualizzate allinterno del widget wrapper: Widget View: contiene le informazioni che il widget vuole presentare.Widget Configuration View: contiene linsieme delle configurazioni applicabili al widget.Figura 3.6 - Widget View e Widget Configuration View (Mockup)Con riferimento alla numerazione proposta in figura 3.6, possibile evidenziare i seguenti componenti allinterno delle view sopra definite: 4. Widget Header: Contiene il titolo del widget e, eventualmente, altre informazioni che si desidera mettere in primo piano. 5. Widget Content: Rappresenta il contenuto informativo del widget.19 24. Capitolo 3 - PROGETTAZIONE6. Configuration Content: Contiene linsieme dei controlli per gestire la configurazione delle informazioni contenute nel Widget Content. 7. Apply/Cancel Configurations: E una coppia di pulsanti che permette di applicare o annullare le configurazioni impostate nel Configuration Content.3.2.2.1Caricamento widget e applicazione delle configurazioniIn questa sezione si vogliono descrivere i processi di caricamento dei widget e dellapplicazione delle configurazioni. La progettazione di tali processi si basa sulle seguenti considerazioni: Nella definizione dei requisiti si richiede che I widget contenuti nella pagina devono rappresentare informazioni reali, cos che lutente disponga di unanteprima fedele delle informazioni contenute nella pagina.Nei principi di progettazione ci si impone di Evitare che processi prolungati obblighino lutente a lunghe attese che impediscano linterazione con lapplicazione.Dato che la generazione delle informazioni reali pu richiedere tempi non trascurabili (ad esempio la creazione di alcuni grafici pu richiedere anche diverse decine di secondi), si vuole che i processi in esame non siano bloccanti, ossia non impediscano allutente di interagire con lapplicazione. Il caricamento di un widget pu avvenire in momenti diversi: In fase di personalizzazione di una pagina, quando un widget viene inserito dal widget store.In fase di preparazione della design area, quando il Page Editor viene eseguito con lo scopo di modificare una pagina precedentemente creata.In fase di applicazione delle configurazioni, quando le informazioni del widget devono essere aggiornate.La figura 3.7 mostra la concatenazione degli eventi che si susseguono a seguito del caricamento di un widget e della successiva applicazione di configurazioni. I numeri e le lettere fanno riferimento alla figura 3.8.20 25. Capitolo 3 - PROGETTAZIONEFigura 3.7 Flusso di eventi durante il caricamento di un widget e la successiva applicazione di configurazioniFigura 3.8 - I vari stati di un widget (Mockup)3.3I widget per la dashboard diSOMO Come gi detto nella sezione 2.2.2, la definizione dei widget per la dashboard di SOMO si rivela immediata dato che le informazioni sono gi raggruppate in blocchi ben definiti. Alla luce di ci, nella fase di progettazione dei widget Projects, My21 26. Capitolo 3 - PROGETTAZIONEWorkspaces e Sessions ci si concentrati solamente nella definizione della loro Widget View, seguendo i principi introdotti nella sezione 3.1. Come risultato della fase di progettazione, nelle figure 3.9, 3.10 e 3.11 si riportano i modelli (mockup) dei widget per la personalizzazione della dashboard di SOMO.Figura 3.9 - Widget View del widget "My workspaces" (Mockup)Figura 3.10 - Widget View del widget "Projects" (Mockup)Figura 3.11 - Widget View del widget "Sessions" (Mockup)22 27. Capitolo 3 - PROGETTAZIONE3.4Page ManagerLa fase di progettazione del Page Manager, lo strumento addetto alla gestione di molteplici pagine personalizzate, ha portato al risultato mostrato in figura 3.12.Figura 3.12 - Layout del Page Manager (Mockup)Riferendosi alla numerazione riportata in figura 3.12 si evidenziano i seguenti componenti: 1. Finestra popup: Il Page Manager si presenta come una finestra popup, la cui apertura pu essere invocata dal Page Editor, come richiesto nei requisiti. Il Page Manager contiene una lista delle pagine create dallutente. Ogni elemento della lista definito come discusso nel punto 2. 2. Page Box: Riferendosi alle lettere riportante in figura 3.13: a. Page Preview: Anteprima della pagina. b. Page Name: Nome della pagina. c. Page Current Marker: E un indicatore che viene visualizzato se la pagina attualmente impostata come corrente dallutente. d. Page Detail: Pannello che contiene informazioni di dettaglio sulla pagina. Esso viene visualizzato solamente quando il cursore del mouse si trova sopra lelemento Page Box.23 28. Capitolo 3 - PROGETTAZIONEe. Page Detail Action Pane: Gruppo di tre pulsanti che permette leliminazione, la modifica e limpostazione come corrente della pagina. f. Delete Page Confirmation: Pannello che viene visualizzato quando si sceglie di eliminare una pagina.Figura 3.13 - Componenti di un elemento Page Box nel Page Manager (Mockup)3. Create Page Button: Permette, dopo linserimento di un nome, la creazione di una nuova pagina.Figura 3.14 - Inserimento del nome per una nuova pagina (Mockup)4. Close Button: Consente la chiusura del Page Manager e permette allutente di proseguire lutilizzo del Page Editor.24 29. Capitolo 4 - INTERFACCIA4 Interfaccia In questo capitolo verr presentato un esempio duso di quanto prodotto in questo lavoro di tesi. In particolare verr descritta la personalizzazione della dashboard di SOMO (Page Editor) e la gestione di molteplici versioni personalizzate della dashboard (Page Manager). Al fine di utilizzare gli strumenti di personalizzazione e gestione realizzati non necessaria alcuna installazione e/o configurazione, dato che essi sono integrati nellapplicazione (SOMO).4.1Accedere al Page EditorFigura 4.1 - Dashboard di SOMO con due widgetUna sezione di SOMO per la quale permessa la personalizzazione, presenta un pulsante a forma di matita posizionato in alto a destra. Nellesempio duso considerato in questo capitolo si vuole personalizzare la dashboard di SOMO che, inizialmente, si presenta come in figura 4.1. Il click sul pulsante sopra citato provocher laccesso al Page Editor, il quale permetter di personalizzare la pagina (dashboard) corrente.25 30. Capitolo 4 - INTERFACCIAFigura 4.2 - Apertura del Page Editor per la personalizzazione della dashboardAllapertura del Page Editor, facendo riferimento alla figura 4.2, si notano: Il pannello Action Menu, che contiene i pulsanti (da sinistra a destra) che permettono di: o Visualizzare/nascondere il widget store. o Salvare le modifiche apportate alla pagina. o Accedere al Page Manager. o Chiudere il Page Editor.Il pannello Widget Store, che contiene i widget utilizzabili per la personalizzazione della dashboard.Larea di editing, o Design Area, dove possibile comporre e personalizzare la dashboard. In fase di apertura del Page Editor, come mostrato in figura 4.2, i widget sono rappresentati da contenitori senza informazioni nei quali presente solamente un indicatore di attesa. Le informazioni dei widget saranno visualizzate non appena disponibili. Il tempo di caricamento dipende da diversi fattori (velocit della connessione, tempi di elaborazione del server, ecc.). possibile cominciare a comporre e personalizzare la pagina senza attendere che il caricamento dei widget allinterno della Design Area sia terminato.4.2Personalizzare una paginaPer inserire un widget nella pagina necessario fare click sullelemento corrispondente allinterno del widget store, come mostrato in figura 4.3.26 31. Capitolo 4 - INTERFACCIAFigura 4.3 - Inserimento di un widget nella Design AreaIl widget scelto verr inserito nellangolo in alto a sinistra della design area, come mostrato in figura 4.4.Figura 4.4 - Il widget Projects inserito nell'angolo in alto a sinistra nella Design AreaPer spostare un widget allinterno della design area sufficiente posizionare il mouse in un punto qualsiasi del widget stesso e trascinarlo verso la posizione desiderata. Durante il trascinamento nella design area possibile vedere, grazie ad unombreggiatura (figura 4.5), la posizione che il widget occuperebbe nel caso venisse rilasciato. Nellesempio duso considerato il widget My Workspaces viene spostato accanto al widget Last Projects. Questa posizione era precedentemente occupata da un altro widget che, automaticamente viene spostato pi in basso.27 32. Capitolo 4 - INTERFACCIAFigura 4.5 - Spostamento di un widget possibile ridimensionare un widget trascinando il suo angolo in basso a destra, fino a raggiungere la dimensione desiderata, come mostrato in figura 4.6.Figura 4.6 - Ridimensionamento di un widget: Prima (sinistra) e Dopo (destra)Per accedere al pannello che consente la configurazione di un widget occorre posizionare il cursore del mouse al suo interno e fare click sullicona a forma di ingranaggio che compare in alto a destra, come mostrato in figura 4.7.Figura 4.7 - Pulsante per accedere alla configurazione del widget28 33. Capitolo 4 - INTERFACCIAUna volta scelte le configurazioni desiderate, possibile applicarle al widget oppure annullare la procedura di configurazione, come mostrato in figura 4.8. Nel caso si decida di applicare le configurazioni impostate, il contenuto del widget verr ricaricato con le informazioni aggiornate.Figura 4.8 - Configurazione di un widgetTutte le modifiche applicate alla pagina e ai suoi widget vengono rese persistenti solamente quando lutente lo desidera. Per salvare le modifiche necessario fare click sul pulsante Save contenuto nellAction Pane. In figura 4.9 vengono mostrati gli stati del salvataggio di una pagina, evidenziati allutente dal pulsante stesso.Figura 4.9 - Stati della procedura di salvataggio, evidenziati dal pulsante "Save"4.3Gestiremolteplicipaginepersonalizzate Nellesempio duso considerato finora, stato mostrato come personalizzare una pagina per la dashboard di SOMO. Lutente ha la possibilit di creare e gestire moltepliciFigura 4.10 - Pulsante perdashboard personalizzate e scegliere, in base alle necessit, accedere al Page Manager quale utilizzare. Lo strumento che permette queste29 34. Capitolo 4 - INTERFACCIAoperazioni denominato Page Manger ed accessibile dal Page Editor facendo click sul pulsante Pages (figura 4.10) contenuto nellAction Menu. Il Page Manager si presenta sotto forma di una finestra di popup (figura 4.11) che contiene la lista delle pagine create in precedenza dallutente. Ogni elemento della lista rappresentato da un riquadro contenente lanteprima della pagina.Figura 4.11 - Page ManagerPosizionando il cursore del mouse sopra il riquadro relativo ad una pagina si fa in modo che compaia un pannello contenente alcune informazioni di dettaglio e un gruppo di pulsanti che permettono di eliminare la pagina, impostarla come pagina corrente e modificarla mediante il Page Editor. Per modificare una pagina, occorre fare click sul pulsante a forma di matita (figura 4.12) contenuto nel pannello di dettaglio relativo ad una pagina. Questa operazione provocher lapertura del Page Editor consentendo cos di editare la pagina scelta.30 35. Capitolo 4 - INTERFACCIAFigura 4.12 Pulsante per modificare una paginaPer eliminare una pagina occorre fare click sul pulsante a forma di cestino contenuto nel pannello di dettaglio relativo alla pagina e confermare loperazione (figura 4.13).Figura 4.13 - Pulsante per eliminare una pagina (sopra) e conferma di eliminazione (sotto) possibile impostare una pagina come corrente facendo click sul pulsante raffigurante un simbolo di spunta contenuto nel pannello di dettaglio relativo alla pagina (figura 4.14). Questa operazione far in modo che, al prossimo utilizzo della dashboard di SOMO, lutente visualizzi la pagina impostata come corrente.31 36. Capitolo 4 - INTERFACCIAFigura 4.14 - Pulsante per impostare una pagina come "corrente "(sopra) e indicatore della pagina corrente (sotto) possibile creare una nuova pagina dashboard facendo click sul pulsante New dashboard posizionato in basso nella finestra popup (figura 4.15). Verr successivamente richiesto di inserire un nome da assegnare alla nuova pagina e di confermare loperazione di creazione mediante il pulsante Create. La creazione della nuova pagina provocher lapertura del Page Editor, che ne permetter la composizione e la personalizzazione.Figura 4.15 - Creazione di una nuova pagina32 37. Capitolo 5 - IMPLEMENTAZIONE5 Implementazione 5.1Page EditorLo strumento Page Editor costituito dai seguenti componenti software: Lato client: o pageEditor.xhtml o editor.css o main.jsLato server: o EditorServiceBean.java5.1.1Integrazione in SOMOUno dei principali requisiti espressi per il Page Editor riguarda la completa integrazione in SOMO. In SOMO la costruzione delle pagine viene realizzata mediante la tecnologia JSF (JavaServer Faces) [10]. Basata sul design pattern architetturale MVC (Model View Controller), JSF riconosciuta da Oracle come tecnologia standard per la costruzione di interfacce utente lato server. JSF un framework basato su componenti. possibile utilizzare set di componenti predefiniti, di terze parti, oppure creare componenti personalizzati. In questo lavoro di tesi si fatto riferimento alla versione JSF 2.0. In unapplicazione web che fa uso della tecnologia JSF gli ingredienti necessari sono: Documenti XHMTL: contengono codice HTML mescolato a speciali elementi JSF (tag ed espressioni). I documenti XHTML vengono elaborati [11] lato server dal framework e trasformati in documenti HTML fruibili da un browser web.IdocumentiXHTMLcostituisconoilpresentationlayerdellapplicazione web.33 38. Capitolo 5 - IMPLEMENTAZIONEManaged Beans: Java Bean che possono essere utilizzati dai documenti XHTML. Un Java Bean una classe Java che espone attributi e metodi ad un framework, in questo caso JSF. In generale, verr creata unistanza (o utilizzata unistanza esistente) di un managed bean ogni volta che verr richiesto un documento XHTML contenente riferimenti ad attributi e metodi esposti dal managed bean stesso. I managed bean rappresentano la business logic dellapplicazione web.In JSF, con il termine Facelets [12] si fa riferimento al View Declaration Language che sostituisce JSP. Facelets supporta un set di tag finalizzati al templating [13], con lo scopo di definire componenti e pagine web riutilizzabili. In JSF possibile definire un template mediante un documento XHTML che definisce la struttura del documento e contiene le informazioni comuni alle pagine che usufruiranno di esso. I documenti XHTML che utilizzano un template definiscono solamente i contenuti propri della pagina che rappresentano. Per soddisfare i requisiti di integrazione in SOMO, il file pageEditor.xhtmlutilizza il template mainTemplate.xhtml, definito dagli sviluppatoridellapplicazione. Con riferimento al codice 5.1, in riga 1 viene definito il tag con il riferimento al template che il documento pageEditor.xhtml utilizza. I contenuti propri della pagina web vengono definiti mediante i tag . Codice 5.1 1 2 3 4 5 6 7 8 9XHTML ... Codice HTML che definisce il contenuto di Action Pane ... Codice HTML che definisce il contenuto di Widget Store e Design Area Oltre allutilizzo di particolari template, lintegrazione in SOMO ha richiesto lattenta valutazione della compatibilit delle librerie JavaScript e dei plugin jQuery utilizzati con le librerie e i plugin presenti nellapplicazione.34 39. Capitolo 5 - IMPLEMENTAZIONE5.1.2Design AreaNella sezione 3.2.1.2 stato illustrato il risultato della progettazione della Design Area. Lorganizzazione a colonne, la gestione del posizionamento e del dimensionamento dei widget sono facilitati dallimpiego di un plugin jQuery: gridster.js [14]. Al fine di poter utilizzare Gridster occorre: Definire, nel codice HTML contenuto in pageManager.xhtml, una struttura simile a quella riportata nel codice 5.2.Inizializzare il plugin. Il codice Javascript necessario allinizializzazione di Gridster riportato nel codice 5.3. Codice 5.21 2 3 4 5 6 7 8

• ...
• ... ...
• ...

Codice 5.3 1 2 3 4 6 7HTMLJS$(function(){ //DOM Ready $(".gridster ul").gridster ({ widget_margins: [10, 10], widget_base_dimensions: [100, 100] }); });Si detto che Gridster permette il posizionamento e il ridimensionamento dei widget nella design area. Per essere pi precisi, Gridster gestisce posizione e dimensione dei contenitori che avvolgono un widget, ossia i widget container, introdotti nella sezione 3.2.2. Con riferimento al codice 5.2, ogni elemento della lista non ordinata

corrisponde ad un widget container. Gridster gestisce i valori di posizione (orizzontale e verticale) e di dimensione (orizzontale e verticale) di ogni widget container mediante speciali attributi,35 40. Capitolo 5 - IMPLEMENTAZIONEdenominati custom data attributes. Come specificato nel W3C Working Draft di HTML5 [15], un custom data attribute, in generale: un attributo applicabile a qualsiasi elemento HTML.Ha nome che deve avere prefisso data- mentre il suffisso, composto da almeno un carattere, pu essere scelto in modo arbitrario. destinato a contenere dati privati utilizzati dalla pagina web o dallapplicazione per i quali non esistono elementi HTML o attributi pi appropriati.Nel codice 5.4, si riporta un esempio di come Gridster faccia uso dei custom data attributes per gestire posizione e dimensione dei widget container: in data-row viene salvata la posizione verticale, in data-col quella orizzontale, in data-sizex la dimensione orizzontale e in data-sizey quella verticale. Codice 5.4 1HTMLOltre ai dati necessari al posizionamento e al dimensionamento nella Design Area, i widget container necessitano di ulteriori informazioni riguardo ai widget che contengono. Tali informazioni sono necessarie fondamentalmente per poter caricare il contenuto dei widget e salvare le loro configurazioni. Seguendo la strategia seguita da Gridster, si deciso di sfruttare gli attributi data- per salvare tutte le informazioni necessarie alla gestione dei widget allinterno degli elementi

, ossia i widget container. In questo modo: Non necessario costruire apposite strutture dati allinterno del codice JavaScript in esecuzione nel contesto della pagina web.Si evita di introdurre dati ridondanti difficili da mantenere aggiornati.Si contribuisce a mantenere la separazione tra informazioni (HTML) e codice (JS).Nel codice 5.5 si mostra la definizione dei widget container contenuti nella Design Area. Nel dettaglio possibile osservare:36 41. Capitolo 5 - IMPLEMENTAZIONEIn riga 1 il tag JSF . Data una collezione di oggetti, in questo caso la lista pageDetail di oggetti di tipo Widget (Entity, vedi sezione 5.4.2) esposta dal managed bean EditorServiceBean, lelaborazione del costrutto forEach permette di generare una porzione di codice HTML avente tanti elementi

quanti sono gli elementi di pageDetail.Nelle righe 2-14 racchiusa la definizione di un widget container. o Nelle righe 3-10 sono definiti i custom data attributes necessari per la gestione del widget. Il valore di tali attributi determinato dallelaborazione delle espressioni JSF #{}. data-dbidcorrisponde allID nel database associato al widgetnella pagina corrente. data-config contiene una stringa in formato JSON che descrivela configurazione del widget. data-templatepath indica lURL nel quale risiede il documentoXHTML che definisce il contenuto configurabile del widget (vedi sezione 5.2.1). data-stylepathe data-scriptpath indicano gli URL nei qualirisiedono i file .css e .js necessari alla rappresentazione e al funzionamento del widget. In riga 13 presente lelemento

appartenente alla classe widget-wrapper. Allinterno di tale elemento verr inserito il contenuto del widget (vedi sezione 5.1.3). Codice 5.51 2 3 4 5 6 7 8 9 10 11 12 13XHTML

...

...

37 42. Capitolo 5 - IMPLEMENTAZIONE14 15 Il codice 5.6 riporta un esempio del codice HTML risultato dellelaborazione del codice 5.5, nel caso in cui pageDetail contenga un solo oggetto: Codice 5.6 1 2 3 4 5 6 7 8 9 10 11 12 13HTML

...

...

5.1.3Caricamento asincrono dei widgetnella design area Laccesso dellutente al Page Editor per la personalizzazione di una particolare pagina corrisponde alla richiesta del documento pageEditor.xhtml allapplication server. Come gi descritto nel capitolo 3, la generazione del contenuto di un widget pu richiedere tempi prolungati. Nel caso si volesse rendere disponibile il contenuto dei widget al momento dellaccesso al Page Editor, si costringerebbe lutente ad attendere la generazione dei contenuti di tutti i widget presenti nella pagina prima di poter interagire con leditor stesso. La soluzione proposta in questo lavoro di tesi sfrutta la tecnologia Ajax [16] per il caricamento asincrono del contenuto dei widget. La richiesta del documento pageEditor.xhtml produce un documento HTML contenente la definizione dei widgetcontainer, ossia un insieme di elementi

aventi particolari attributi data-, come descritto nella sezione 5.1.2. Una volta che tale documento stato caricato nel contesto38 43. Capitolo 5 - IMPLEMENTAZIONEdel browser, per ogni widget container contenuto nella Design Area, si effettua una richiesta (per il contenuto del widget): Per la risorsa che risiede allURL indicato dal valore dellattributo datatemplatepathdel widget container (riga 8 codice 5.5)Con parametro avente nome id e valore corrispondente a quello dellattributo data-dbiddel widget container (riga 5 codice 5.5)Il codice HTML del widget richiesto, contenuto nella risposta, viene inserito allinterno del widget container opportuno. Pi precisamente, il contenuto viene inserito allinterno dellelemento

appartenente alla classe widget-wrapper (riga 13 codice 5.5). I particolari relativi alla costruzione lato server del widget richiesto (avente id data-dbid) vengono illustrati nella sezione 5.2. La figura 5.1 rappresenta un diagramma di sequenza desempio relativo al caricamento nel Page Editor di una pagina con due widget. Dopo aver ottenuto il documento pageEditor.xhtml,vengono inviate in sequenza le richieste per i widget aventi data-dbid=30 e data-dbid=2. Una volta che il codice HTML relativo ai due widget sar resodisponibile verr inserito allinterno del widget container opportuno. BROWSER UIAJAX ENGINEPAGE EDITOR SERVICE BEANPROJECTS WIDGET BEANSESSIONS WIDGET BEANpageEditor.xhtml?pageID=1 (HTML) load projects widget ID=30 load sessions widget ID=2.../projects.xhtml?id=30inserisci HTML nel widget containerinserisci HTML nel widget container.../sessions.xhtml?id=2 (HTML)(HTML)Figura 5.1 - Diagramma di sequenza relativo al caricamento nel Page Editor di una pagina con 2 widgetLa richiesta dei widget e il loro caricamento nei widget container vengono implementati mediante il codice 5.7:39 44. Capitolo 5 - IMPLEMENTAZIONEIn riga 3, mediante a un selettore jQuery, si ottengono i riferimenti agli elementi

di classe widget-container. Per ognuno di essi, nelle righe 811, viene invocato il metodo jQuery load() [17] avente per argomenti: o URL della risorsa desiderata (valore di data-templatepath) o Stringa contenente i parametri della richiesta (valore di data-dbid) o Funzione di callback da eseguire quando la richiesta stata completataInriga8,$(pageWidgets[i]).find('.widget-wrapper')fornisceilriferimento allelemento nel quale inserire il codice HTML contenuto nella risposta. Codice 5.7 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16JSfunction loadPageWidgets() { var pageWidgets = []; var pageWidgets = $('#page .widget-container); for (var i = 0; i < pageWidgets.length; i++) { ... $(pageWidgets[i]).find('.widget-wrapper').fadeOut(); $(pageWidgets[i]).find('.widget-wrapper').load( $(pageWidgets[i]).attr('data-templatepath'), "id=" + $(pageWidgets[i]).attr('data-dbid'), function(responseText, statusText, xhr) { ... }); ... } //end for }5.1.4Il managed bean per il Paged EditorIl managed bean associato al documento pageEditor.xhtml definito dalla classe EditorServiceBean.java:Espone al documento pageEditor.xhtml i seguenti attributi attraverso metodi getter/setter: o String JSONObj: Stringa in formato JSON [18] utilizzata per il salvataggio dei dati (attributi data-) relativi ai widget contenuti nella Design Area. o String pageScreenshot: Stringa contenente i dati relativi allanteprima del contenuto della Design Area. 40 45. Capitolo 5 - IMPLEMENTAZIONEo Page currentEditorPage: Oggetto di tipo Page (Entity Page, vedi sezione 5.3.2) relativo alla pagina in fase di editing nella Design Area. o List textWidgets: Lista di oggetti di tipo Widget (Entity Widget,vedi sezione 5.3.2). E utilizzata per il caricamento nel widgetstore dei widget appartenenti alla categoria text. o List tableWidgets: Lista di oggetti di tipo Widget utilizzata per il caricamento nel widget store dei widget di tipo table. o List chartWidgets: Lista di oggetti di tipo Widget utilizzata per il caricamento nel widget store dei widget di tipo chart. o List pageDetail: Lista di oggetti di tipo Widget utilizzata per il caricamento dei widget container nella Design Area. Il suo utilizzo in pageEditor.xhtml gi stato descritto i precedenza (codice 5.5)Espone i seguenti metodi pubblici: o public String save (Integer pageID): metodo invocato per il salvataggio della pagina rappresentata nella Design Area, avente id pageIDo public void savePageScreenshot (Integer pageID) : metodo invocato per il salvataggio dellanteprima della Design Area annotato come @RequestScoped [19]. Utilizzando questa annotazione unistanza del managed bean verr creata ad ogni richiesta di un documento contenente riferimenti ad attributi e metodi esposti dal managed bean.Possiede un metodo privato init() annotato come @PostConstruct [20]. Questa annotazione viene utilizzata per identificare un metodo che deve essere eseguito non appena unistanza delloggetto EditorServiceBean viene creata. Quando si accede al Page Editor per personalizzare una pagina, da un punto di vista implementativo, si effettua una richiesta oPer la risorsa pageEditor.xhtmlo Con parametro avente nome pageID e valore corrispondente allID della pagina che si desidera personalizzare. Lo scopo del metodo init() quello di estrarre dalla richiesta il valore del parametro pageID e popolare la lista pageDetail, utilizzata in seguito41 46. Capitolo 5 - IMPLEMENTAZIONEnellelaborazione del documento pageManager.xhtml per generare gli elementi

corrispondenti ai widget container.5.1.5Salvataggio di una paginaQuando lutente, durante lutilizzo del Page Editor, decide di rendere persistenti le modifiche apportate alla pagina preme il pulsante Save. Ci innesca una catena di operazioni che coinvolgono lesecuzione di codice lato client (JavaScript), lato server (Java) e lutilizzo di particolari tag JSF (XHTML) per limplementazione della tecnologia Ajax. In codice 5.8 si riporta il frammento di codice XHTML destinato alle operazioni di salvataggio della pagina. Si sottolinea come la tecnologia JSF supporti Ajax attraverso librerie Javascript integrate. Il tag JSF [21] permette di implementare funzionalit Ajax senza la necessit di codice JavaScript aggiuntivo. Codice 5.8 1 2 3 4 5 6 7 8 9 10 11 12 13 14XHTML ... 42 47. Capitolo 5 - IMPLEMENTAZIONESi riportano i passaggi del processo di salvataggio della pagina: 1.Lutente preme il pulsante per il salvataggio2.Viene invocato (codice 5.8 riga 9) il metodo objectify() esposto dalloggetto Javascript editorManager definito in main.js. Questo oggetto implementa il design pattern revealing module pattern [22], che permette di creare un oggetto JavaScript in grado di esporre pubblicamente alcuni attributi e funzioni. Il metodo objectify() salva nellelemento nascosto JSONObj (codice 5.8 riga 3) una stringa in formato JSON contenente una lista di oggetti rappresentanti i widget container. Gli attributi di tali oggetti coincidono con i valori degli attributi dei widget container data-dbId, data-widgetType, data-config, data-row, data-col, data-width, data-height, data-pageId.3.Viene invocato (codice 5.8 riga 9), nel contesto di una transazione Ajax, il metodo editorServiceBean.save(pageID) . Il metodo save(pageID) esposto dal managed bean EditorServicBean ed responsabile per il salvataggio nel database dei widget contenuti nella Design Area. In figura 5.2 viene rappresentato il processo eseguito dal metodo save(PageID). A scopo di chiarimento, il controllo widgetsInEditor[i] ha dbId==null? equivale a verificare se li-esimo widget in widgetsInEditor non presente nel database.4.Una volta che il metodo save() ha aggiornato il campo nascosto JSONObj, la transazione Ajax terminata. La funzione JavaScript ajaxSaveMonitor (codice 5.8 riga 11) monitora gli eventi associati alla transazione Ajax relativa alla procedura di salvataggio. Quando lo stato della transazione coincide con success la funzione ajaxSaveMonitor aggiorna gli attributi data- dei widget container con i dati contenuti in JSONObj.Parallelamente alla transazione Ajax che permette il salvataggio della pagina, viene avviata unulteriore transazione che consente di salvare unanteprima del contenuto della Design Area. Il motivo per il quale si scelto di suddividere queste due operazioni in transazioni Ajax distinte dettato dalla lunghezza variabile e spesso prolungata delloperazione di creazione dellanteprima. Suddividendo le due operazioni possibile salvare immediatamente la pagina senza dover attendere il completamento della creazione dellanteprima.43 48. Capitolo 5 - IMPLEMENTAZIONEIl salvataggio dellanteprima reso possibile dalla libreria JavaScript html2Canvas [23] utilizzata dalla funzione (codice 5.8 riga 9) saveScreenshot(). html2Canvas permette di generare la rappresentazione grafica del contenuto di un elemento HTML. Tale rappresentazione viene fornita dalla libreria sotto forma di un elemento HTML di tipo [24]. possibile ottenere una stringa (esempio in figura 5.2) che codifica il contenuto dellelemento . La strategia adottata in questo lavoro di tesi di salvare tale stringa nel database. data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAVgAAAE/CAYAAAADnduiAAAAA XNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAACoKSURBVHhe7d0HeBTV2gfwF9JDQujV0HsR QYo0RayIF/ xviLZ2GsA8bAAAAAElFTkSuQmCC Figura 5.2 - Esempio di una stringa che codifica il contenuto di un elemento 44 49. Capitolo 5 - IMPLEMENTAZIONEsave(PageID)NOAggiorna in DB il widget con ID=dbIdAggiungi in DB widgetsInEditor [i] appartenente alla pagina PageIDRicava da JSONObj elenco widget nella design area e popola lista widgetsInEditorRicava da DB elenco widget nella pagina PageID e popola lista widgetInPageRicava da DB informazioni sulla pagina con ID = PageIDSIwidgetsInEdito r[i] ha dbId == null?NOwidgetsInEdito r vuota?NOAggiorna widgetsInEditor [i] con il nuovo dbIdSono stati analizzati tutti i widget in widgetsInEdito r ?SISIRimuovi da DB tutti i widget contenuti in widgetInPage che non sono contenuti in widgetInEditorreturnAggiorna JSONObj con widgetsInEditor aggiornataFigura 5.3 - Flow chart relativo al metodo save esposto da EditorServiceBean45 50. Capitolo 5 - IMPLEMENTAZIONE5.1.6Widget store e aggiunta di un widgetalla design area Cos come i widget container, anche gli elementi elencati nel widget store fanno largo uso dei custom data attributes. Il codice 5.9 riportato di seguito rappresenta il codice XHTML dedicato alla generazione dellelenco dei widget appartenenti alla categoria table. Codice 5.9 1 2 3 4 5 6 7 8 9 10 11 12 13 14XHTML

...

Quando un utente sceglie di inserire nella design area un widget dal widget store, viene invocata la funzione pinToPage(widgetToPin) esposta dalloggetto JavaScript editorManager.Questa funzione far in modo che venga aggiunto un nuovo widgetcontainer nella design area. Pi precisamente verr inserito un elemento

appartenente alla classe widget-container e avente attributi data- con valori corrispondenti a quelli degli attributi data- dellelemento widgetToPin, passato come argomento alla funzione. Largomento widgetToPin un riferimento ad un elemento

appartenente alla classe widget-store-view (vedi codice 5.9 riga 2).La funzione pinToPage, nellambito di una transazione Ajax, si occupa di effettuare la richiesta per caricare il contenuto del widget nel widget container. LURL della risorsa richiesta corrisponde allattributo data-templatepath dellelemento widgetToPin.46 51. Capitolo 5 - IMPLEMENTAZIONE5.2Widget5.2.1Linee guida per lo sviluppo di unwidget Quando si desidera sviluppare un nuovo widget occorre fornire: Directory widget-name-pkg contenente: o widget-name.xhtml: Documento che deve rispettare una determinata struttura, descritta in seguito. widget-name.xhtml il documento al quale si riferisce lURL contenuto nellattributo data-templatepath. o style.css: Foglio di stile per il contenuto del widget. o script.js: Codice Javascript necessario per il funzionamento del widget.Managed Bean: Java Bean che pu essere creato nel caso si vogliano esporre attributi e metodi al documento widget-name.xhtml.La costruzione del documento widget-name.xhtml deve cominciare dal codice XHTML 5.10. possibile notare come la struttura richiami i concetti introdotti nella sezione 3.2.2.. Le parti dove lo sviluppatore del widget pu inserire il contenuto desiderato sono indicate nelle righe 4,7,12,15. Codice 5.10 1 2 3 4 5 6 7 8 9 10 11 12 13 14XHTML

Contenuto header widget

Contenuto informativo Widget

Contenuto header configurazione

47 52. Capitolo 5 - IMPLEMENTAZIONE15 16Contenuto configurazione widget

Apply Cancel

17 18 19 20 21 22

5.2.1.1Caricamento di un widgetCome gi descritto nella sezione 5.1.3 il caricamento di un widget allinterno del widget container associato avviene, nellambito di una transazione Ajax, mediante una richiesta Per la risorsa che risiede allURL indicato dal valore dellattributo datatemplatepathdel widget containerCon parametro avente nome id e valore corrispondente a quello dellattributo data-dbiddel widget containerIl managed bean del widget per il quale si desidera caricare il contenuto deve essere in grado di: Estrarre dalla richiesta il valore del parametro idCaricare le configurazioni del widgetApplicare le configurazioni al contenutoLimplementazione del managed bean a discrezione dello sviluppatore di un widget. Nella sezione 5.2.4 viene riportata la soluzione adottata nello sviluppo dei widget per la dashboard di SOMO.5.2.1.2Applicazione delle configurazioniLoggetto JavaScript editorManager, gi utilizzato nella sezione 5.1.5 con la funzione objectify(), visibile anche al codice JavaScript associato ad un widget (file script.js contenuto nella directory widget-name-pkg). Tra le diverse funzioni esposte da editorManager, si sottolinea la presenza della funzione48 53. Capitolo 5 - IMPLEMENTAZIONEapplyWidgetConfig(wdgContainer, jsonConfigString) ,addetta allapplicazionedelle configurazioni impostate dallutente ad un certo widget. Gli argomenti di questa funzione sono: wdgContainer,riferimento allelemento HTML di classe widget-containerche contiene il widget in questione. jsonConfigString,la stringa in formato JSON contenente le informazionisulla configurazione del widget. Il codice contenuto in script.js, al momento dellapplicazione delle configurazioni, deve preoccuparsi di: 1. Comporre la stringa JSON di configurazione. 2. Selezionare lelemento di classe widget-container che contiene il widget al quale si desidera applicare le configurazioni. 3.Invocare la funzione applyWidgetConfig(wdgContainer, jsonConfigString) .La funzione applyWidgetConfig(wdgContainer, jsonConfigString) si occuper di: 1. Impostare la stringa jsonConfigString come valore dellattributo data-config dellelemento

di classe widget-container (codice 5.5 riga 7) riferito da wdgContainer.2. Ricaricare il widget con le configurazioni aggiornate. Questa operazione avviene, nellambito di una transazione Ajax, mediante una richiesta: a. Per la risorsa widget-name.xhtmlallURL indicato dal valoredellattributo data-templatepath del widget container wdgContainer b.Con parametro avente nome config e valore jsonConfigStringLa risposta conterr il codice HTML relativo al widget con le configurazioni aggiornate. Il contenuto di tale risposta viene inserito allinterno dellelemento

di classe widget-wrapper (codice 5.5 riga 13), figlio di wdgContainer.Il managed bean del widget per il quale si desidera aggiornare il contenuto deve essere in grado di: Estrarre dalla richiesta il valore del parametro configApplicare le configurazioni49 54. Capitolo 5 - IMPLEMENTAZIONELimplementazione del managed bean a discrezione dello sviluppatore di un widget. Nella sezione 5.2.2 viene riportata la soluzione adottata nello sviluppo dei widget per la dashboard di SOMO.5.2.2Managed bean: soluzione proposta daiwidget per la dashboard di SOMO In figura 5.4 si riporta il processo di inizializzazione dei managed bean creati per i widget della dashboard di SOMO. Parlando di processo di inizializzazione si fa riferimento ad un metodo annotato come @PostConstruct contenuto nel managed bean. Con riferimento al flow chart (figura 5.4) possibile discriminare i tre casi per i quali pu venire richiesta la risorsa widgetName.xhtml: 1. Caricamento di un widget nella design area: il caso, descritto nella sezione 5.1.3, in cui la richiesta contenga il parametro id. 2. Applicazione delle configurazioni per un widget nella design area: il caso in cui la richiesta contenga il parametro config. In questo caso non necessario alcun accesso al database. Il managed bean, infatti, viene utilizzato solamente per applicare al codice HTML del contenuto del widget le configurazioni impostate dallutente. 3. Inserimento di un widget dal widget store alla design area: il caso in cui la richiesta non contenga n il parametro id n il parametro config. Lassenza del parametro id dovuta al fatto che il widget appena aggiunto ad una pagina, non essendo ancora presente nel database, non possiede un id.50 55. Capitolo 5 - IMPLEMENTAZIONEManaged Bean InitEstrazione dei parametri dalla richiestaNella richiesta contenuto parametro id?SIEstrai valore widgetID del paramentro idSICarica da DB la stringa di configurazione in formato JSON per il widget con ID widgeIDEstrai valore jsonConfigString del paramentro configNONella richiesta contenuto parametro config?NOCarica da DB la stringa di configurazione di default per il widget richiestoApplica configurazioneFine initFigura 5.4 - Flow chart relativo all'inizializzazione dei managed bean per i widget della dashboard di SOMO51 56. Capitolo 5 - IMPLEMENTAZIONE5.3Accesso ai dati5.3.1Estensione del database esistenteIn figura 5.5 rappresentata la porzione di database realizzato. La tabella (sfondo tratteggiato) user_somo fa parte del database esistente, somodb. Le rimanenti tabelle sono state aggiunte a somodb al fine di raggiungere gli scopi di questo lavoro di tesi. tblPagetblPageDetailPK PageIDPK PageWidgetIDtblWidget PK WidgetIDNameFK PageIDNameScopeFK WidgetIDDefaultSizeXCreatorConfigJSONDefaultSizeYLastEditDateRowTemplatePathPreviewImageColScriptPathWidthStylePathHeightDefaultConfigJSON ThumbnailDescription FK ScopeFK TypetblUserEditorSettings PK UserEditorSettingsID FK CurrentDashboardPageIDtblScope PK ScopeIDtblWidgetType PK WidgetTypeIDNameTypeNameFK UserIDuser_somo PK id username...Figura 5.5 - Estensione del database esistente52 57. Capitolo 5 - IMPLEMENTAZIONELa porzione di database realizzato, nonostante sia di tipo relazionale, al suo interno contiene dei dati strutturati in maniera particolare. Si fa riferimento agli attributi ConfigJSON della tabella tblPageDetail e DefaultConfigJSONdella tabella tblWidget.Questi attributi, di tipo String, contengono al loro interno dati in formato JSON. La scelta di utilizzare questo approccio motivata dal fatto che i dati delle configurazioni dei widget non hanno una struttura comune definibile a priori. In questo modo, possibile permettere a sviluppatori di terze parti di realizzare i propri widget senza conoscere gli aspetti implementativi del modo in cui i dati vengono resi persistenti.5.3.2JPA: Implementazione di Entity eSession EJB Il database realizzato, come descritto in precedenza, di tipo relazionale. La parte server dellapplicazione scritta in un linguaggio Object-oriented: Java. In Java, un modo per accedere ai dati contenuti in un database relazionale attraverso luso dellAPI JDBC (Java Database Connectivity). Essa permette la connessione al database, lesecuzione di comandi SQL (Structured Query Language) e la raccolta dei risultati. Sebbene ancora ampiamente utilizzato, JDBC stata sostituita dai pi flessibili strumenti ORM (Object-relational mapping). Il principio su cui si basano gli strumenti ORM consiste nel delegare laccesso ai database relazionali ad altri framework, i quali offrono agli utilizzatori una visuale object-oriented dei dati relazionali, mappando i dati relazionali in oggetti e viceversa. Esistono diversi framework ORM, tra i quali JPA (Java Persistence API) [25], incluso in Java EE 6 e utilizzato in questo lavoro di tesi. I componenti principali di JPA sono i seguenti: ORM, il meccanismo che si occupa del mapping bidirezionale oggetti-tabelle dei database relazionali.Entity Manager API, che consente di eseguire le operazioni CRUD nel database, quali Create, Read, Update, Delete.JPQL (Java Persistence Query Language), il quale permette di recuperare i dati mediante query espresse in un linguaggio object-oriented.JTA (Java Transaction API), che gestisce laccesso concorrente ai dati. 53 58. Capitolo 5 - IMPLEMENTAZIONEGli oggetti Java che vengono tradotti in tabelle e viceversa vengono denominati entity. JPA permette di gestire le entity: aggiungere una entity ad un database, rimuoverla, aggiornarla, ecc. possibile definire una entity creando una classe Java e annotandola come @Entity. La classe che definisce una entity, in generale, possiede: Attributi che corrispondono alle colonne della tabella alla quale la entity fa riferimento.Costruttore.Metodi getter e setter per esporre gli attributi.In questo lavoro di tesi sono state definite sei entity, una per ogni tabella della porzione di database realizzata, denominate: Page.javaPageDetail.javaScope.javaUserEditorSetting.javaWidget.javaWidgetType.javaLa definizione delle entity pu essere automatizzata, grazie a particolari strumenti proposti dagli ambienti di sviluppo come NetBeans, utilizzato in questo lavoro di tesi. A titolo di esempio si riporta nel codice 5.11 la definizione dellentity Page.java. Si sottolineano i seguenti particolari: Riga 1: annotazione @Entity.Riga 2: annotazione @Table che permette di indicare il nome tabella nel database corrispondente alla entity che si sta definendo.Riga 4: annotazione @NamedQueries che permette di indicare un insieme di @NamedQuery,ossia query definite in linguaggio SQL. Le query indicatepossono essere utilizzate in un modo simile ad un metodo Java, avente nome namee una lista di eventuali parametri. In seguito verr mostrato un esempioduso di una query. Righe 10-13: definizione di un attributo, in questo caso corrispondente alla primary key della tabella tblPage.54 59. Capitolo 5 - IMPLEMENTAZIONEo Annotazione @Id utilizzata per denotare una chiave primaria. o Annotazione @GeneratedValue utilizzata per specificare il metodo di generazione dei valori per la chiave primaria. In questo caso il metodo scelto AUTO che delega la creazione del valore al DBMS (Database Management System). o Annotazione @Column utilizzata per indicare il nome della colonna corrispondente allattributo che si sta definendo, in questo caso PageID. o Integer pageID indica il tipo associato allattributo pageID. Righe 15,16: definizione di una relazione uno-a-molti tra le tabelle tblPage e tblPageDetailo Annotazione @OneToMany utilizzata per definire il tipo di relazione. o Cascade=CascadeType.ALL indica che ogni operazione sulla entity Page verr propagata alle entity associate. o fetch=FetchType.LAZY indica il metodo di fetch mediante il quale vengonocaricatidapageDetailCollection.databaseglielementidellacollectionIn questo caso, il tipo LAZY indica che lacollection sopra citata verr popolata solamente quando si cerca di accedere ai suoi valori, attraverso i metodi getter e setter associati. Codice 5.11 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17JAVA@Entity @Table(name = "tblPage") @XmlRootElement @NamedQueries({ @NamedQuery(name="Page.findAll", query="SELECT p FROM Page p"), //Altre named Query @NamedQuery(name="Page.findByScope", query="SELECT p FROM Page p WHERE p.scope =:scope"), @NamedQuery(name="Page.findByCreatorAndScope", query="SELECT p FROM Page p WHERE (p.scope=:scope AND p.creator=:creator)")}) public class Page implements Serializable { @Id @GeneratedValue(strategy = GenerationType.AUTO) @Column(name = "PageID") private Integer pageID; //altri attributi @OneToMany(cascade=CascadeType.ALL, mappedBy="pageID", fetch=FetchType.LAZY) private Collection pageDetailCollection;55 60. Capitolo 5 - IMPLEMENTAZIONE18 19 20 21public Page(){ } //Metodi getter e setterLe entity racchiudono i dati, le relazioni e, eventualmente, semplici regole di validazione. Le entity vengono gestite da altri componenti, detti session bean. Essi vengono utilizzati per implementare business logic, processi e workflow. Esistono tre tipi di session bean: stateless, stateful e singleton. In questo lavoro di tesi si fatto uso di session bean di tipo stateless, adatti nei casi in cui ogni operazione necessaria pu essere conclusa in ununica chiamata ad un metodo [26]. Esempi di operazioni di questo genere possono essere la creazione, laggiornamento, la rimozione di entity nel database e lesecuzione di una query. Cos come le entity, anche la definizione dei session bean pu essere automatizzata. In questo lavoro di tesi sono stati definiti sei stateless session bean, uno per ogni entity: PageFacade.javaPageDetailFacade.javaScopeFacade.javaUserEditorSettingFacade.javaWidgetFacade.javaWidgetTypeFacade.javaTutti i session bean sopra elencati estendono una classe astratta, AbstractFacade.java, che espone i seguenti metodi generici: public void create(T entity)public void edit(T entity)public void remove(T entity)public T find(Object id)public List findAll()public List findRange(int[] range)A titolo di esempio si riporta nel codice 5.12 la definizione dello stateless session bean PageFacade.java,della quale si sottolineano i seguenti particolari:56 61. Capitolo 5 - IMPLEMENTAZIONERiga 1: Annotazione @Stateless che indica il tipo di session bean implementato.Riga 4: Lentity manager un componente fondamentale in JPA. Esso gestisce lo stato e il ciclo di vita delle entity. Quando un entity manager ottiene un riferimento a una entity, essa si dice essere managed. Fino a quel momento, la entity vista come un normale POJO (Plain Old Java Object). Grazie a JPA, le entity possono essere utilizzate dai vari livelli di unapplicazione come normali oggetti Java, finch non si renda necessario caricare o inserire dati nel database. Quando si rendono necessarie tali operazioni, le entity vengono gestite (managed) dallentity manager che sincronizza lo stato delle entity con il database.Riga 3: Annotazione @PersistenceContext. Il persistence context, che pu essere visto come un primo livello di cache, un insieme di istanze di managed entity in un dato istante. Lentity manager consulta e aggiorna il persistence context. Il parametro unitName = "somo-persistence-unit" indica linsieme dei dati di connessione ad un database, inclusi in un file xml di configurazione.Righe 14-18: Utilizzo di una named query definita nella entity Page o In riga 15 viene creato unoggetto di tipo Query in base alle definizione della named query ("Page.findByScope") o In riga 16 viene impostato il parametro della query o In riga 17 si ottengono i risultati dellesecuzione della query Codice 5.121 2 3 4 5 6 7 8 9 10 11 12 13 14JAVA@Stateless public class PageFacade extends AbstractFacade { @PersistenceContext(unitName = "somo-persistence-unit") private EntityManager em; @Override protected EntityManager getEntityManager() { return em; } public PageFacade() { Super(Page.class); } public List getPagesByScope(Scope scope) {57 62. Capitolo 5 - IMPLEMENTAZIONEQuery PagesOfScopeQuery = em.createNamedQuery("Page.findByScope"); PagesOfScopeQuery.setParameter("scope", scope); return PagesOfScopeQuery.getResultList();15 16 17 18 19} public List getPagesByCreatorAndScope(User userID, Scope scope) { }20 21 22 23}58 63. Capitolo 6 - CONCLUSIONI6 Conclusioni In questo lavoro di tesi stato presentato uno strumento che permette di personalizzare le pagine di unapplicazione web esistente, denominata SOMO. Si mostrato come sia possibile, per ogni pagina personalizzabile, creare molteplici versioni personalizzate e scegliere quale si desidera utilizzare. Le funzionalit implementate sono integrate allinterno dellapplicazione SOMO e sono state sviluppate utilizzando unicamente tecnologie web riconosciute come standard, quali HTML5, CSS3, Javascript e Ajax. In questo modo lutente ha la possibilit di fruire di qualsiasi funzionalit, senza la necessit di installare alcun componente aggiuntivo al proprio browser. Si definito un insieme di linee guida e si realizzata uninfrastruttura di base per consentire a sviluppatori di terze parti di produrre widget utilizzabili in SOMO. Gli obiettivi posti inizialmente sono dunque stati raggiunti. Il lavoro di tesi attualmente in fase di test e validazione. I criteri di validazione sono sia funzionali che tecnici e riguardano principalmente gli aspetti di usabilit, sicurezza e performance. Nel caso la validazione abbia esito positivo, il lavoro di tesi destinato ad entrare nellambiente di produzione. Il lavoro di tesi, svolto seguendo i principi delle metodologie di sviluppo agile, ha richiesto un tempo di circa 4 mesi. Il risultato ottenuto apre le porte a numerosi sviluppi futuri, tra i quali: Estensione della capacit di personalizzazione ad altre sezioni di SOMO.Consolidamento dellintegrazione in SOMO.Introduzione di nuovi widget.Rafforzamento delle linee guida e dellinfrastruttura per la costruzione di widget da sviluppatori di terze parti.Aggiunta di funzionalit di condivisione delle pagine personalizzate.59 64. Capitolo 6 - CONCLUSIONIPersonalmente mi ritengo molto soddisfatto del lavoro svolto e dei risultati ottenuti. La variet delle tecnologie considerate, lapprendimento di nuove metodologie di sviluppo, la risoluzione dei problemi incontrati e il lavoro svolto in Esteco S.p.A. a stretto contatto con persone professionali e motivate hanno rappresentato per me motivo di accrescimento sia formativo che personale.60 65. RIFERIMENTIRiferimenti [1]"Manifesto for Agile Software Development," 2001. [Online]. Available: http://agilemanifesto.org/.[2]Scrum(softwaredevelopment),[Online].Available:http://en.wikipedia.org/wiki/Scrum_(software_development). [3]"Esteco: Corporate," [Online]. Available: http://www.esteco.com/corporate.[4]"Esteco: SOMO," [Online]. Available: http://www.esteco.com/somo.[5]"Windows User Experience Design Principles," [Online]. Available: http://msdn.microsoft.com/en-us/library/windows/desktop/dd834141.aspx.[6]"DesignThinking,"[Online].Available:http://en.wikipedia.org/wiki/Design_thinking. [7]J. Knapp, The product design sprint: a five-day recipe for startups, [Online]. Available: http://www.designstaff.org/articles/product-design-sprint-2012-1002.html.[8]J. Nielsen, "F-Shaped Pattern For Reading Web Content," Nielsen Norman Group,17Aprile2006.[Online].Available:http://www.nngroup.com/articles/f-shaped-pattern-reading-web-content/. [9]P. J. Meyers, "Eye-Tracking Google SERPs," 5 Ottobre 2011. [Online]. Available: http://moz.com/blog/eyetracking-google-serps.[10] Oracle,"JavaServerFacesTechnology,"[Online].Available:http://www.oracle.com/technetwork/java/javaee/javaserverfaces-139869.html.61 66. RIFERIMENTI[11] D. Geary and C. Horstmann, "The Life Cycle," in Core JavaServer Faces, Prentice Hall, 2010, pp. 20-31. [12] Oracle, "Introduction to Facelets," Settembre 2013. [Online]. Available: http://docs.oracle.com/javaee/7/tutorial/doc/jsf-facelets.htm. [13] Oracle, "Using Facelets Templates," Settembre 2013. [Online]. Available: http://docs.oracle.com/javaee/7/tutorial/doc/jsf-facelets004.htm#GIQXP. [14] Ducksboard,"gridster.jsDocumentation,"[Online].Available:http://gridster.net/#documentation. [15] W3C, "Embedding custom non-visible data with the data-* attributes," [Online].Available:http://www.w3.org/TR/2011/WD-html5-20110525/elements.html#embedding-custom-non-visible-data-with-the-dataattributes. [16] "Ajax(programming),"[Online].Available:http://en.wikipedia.org/wiki/Ajax_(programming). [17] jQuery, ".load()," [Online]. Available: http://api.jquery.com/load/. [18] "Introducing JSON," [Online]. Available: http://json.org/. [19] Oracle,"AnnotationTypeRequestScoped,"[Online].Available:http://docs.oracle.com/javaee/6/api/javax/enterprise/context/RequestScoped.ht ml. [20] Oracle,"AnnotationTypePostCosntruct,"[Online].Available:http://docs.oracle.com/javaee/6/api/javax/annotation/PostConstruct.html. [21] Oracle,"UsingAjaxwithFacelets,"[Online].Available:http://docs.oracle.com/javaee/6/tutorial/doc/gkabr.html. [22] A. Osmani, "The Revealing Module Pattern," 2012. [Online]. Available: http://addyosmani.com/resources/essentialjsdesignpatterns/book/#revealingmo dulepatternjavascript.62 67. RIFERIMENTI[23] N. von Hertzen, "html2canvas Documentation," [Online]. Available: http://html2canvas.hertzen.com/documentation.html. [24] W3C,"Thecanvaselement,"[Online].Available:http://www.w3.org/html/wg/drafts/html/master/embedded-content-0.html#thecanvas-element. [25] A. Goncalves, Beginning Java EE 6 Platform with GlassFish 3, Apress, 2012. [26] A. Goncalves, "Stateless Beans," in Beginning Java EE 6 Platform with GlassFish 3, Apress, 2010, pp. 202-204. [27] "Enterprisesoftware,"22Ottobre2013.[Online].Available:http://en.wikipedia.org/wiki/Enterprise_software.63