If you can't read please download the document
Upload
matteo-miotto
View
232
Download
0
Embed Size (px)
Citation preview
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