Università degli Studi di Torino Facoltà di Scienze Matematiche Fisiche e Naturali

Corso di Laurea in Informatica

Anno Accademico 2009/2010

Relazione di Tirocinio

OvunqueScuola: realizzazione in ambito

Cloud Computing di un portale web

scolastico

Relatore: Prof. Antonio Di Leva

Correlatori: Dott. Massimiliano Garruzzo

Dott. Pasquale Pellitteri

Candidato: Passaghe Maximilian

Sommario Cap.1 Introduzione .............................................................................. 5

Obiettivo .................................................................................................................... 5

L’idea ......................................................................................................................... 5

Il progetto OvunqueScuola ......................................................................................... 9

Le fasi di progettazione ............................................................................................. 10

Ambiente di sviluppo ................................................................................................ 11

Sistema operativo ........................................................................................................................ 11

Linguaggio di programmazione ................................................................................................... 11

Framework .................................................................................................................................. 11

Software di versionamento ......................................................................................................... 12

Cap.2 Analisi funzionale .................................................................. 13

Casi d’uso generali e diagramma delle classi .............................................................. 13

Evoluzione dell’analisi funzionale .............................................................................. 17

Struttura del progetto e package .............................................................................. 19

Funzionalità generali ................................................................................................ 20

Login ............................................................................................................................................ 20

Calendario ................................................................................................................................... 21

Bacheca ....................................................................................................................................... 22

Messaggi ...................................................................................................................................... 23

Appunti ........................................................................................................................................ 25

Faq ............................................................................................................................................... 26

SuperAdmin ............................................................................................................. 26

Gestione ...................................................................................................................................... 27

Admin ...................................................................................................................... 30

Gestione comprensorio ............................................................................................................... 32

Gestione scuola ........................................................................................................................... 34

Gestione utenti ............................................................................................................................ 34

Gestione scuola (Didattica) ......................................................................................................... 35

Gestione comunicazioni .............................................................................................................. 37

Insegnante ............................................................................................................... 39

Registro di classe ......................................................................................................................... 41

Registro personale ....................................................................................................................... 45

Supplenze .................................................................................................................................... 48

Studente .................................................................................................................. 49

Materie ........................................................................................................................................ 50

Andamento scolastico ................................................................................................................. 51

ClassWall...................................................................................................................................... 52

Genitore ................................................................................................................... 53

Cap.3 Conclusioni e sviluppi futuri ............................................... 57

Accessibilità, Screen readers e ARIA .......................................................................... 57

Internazionalizzazione .............................................................................................. 58

GWT e sicurezza ....................................................................................................... 59

Security Token .......................................................................................................... 59

Miglioramento delle performance, Speed Tracer ....................................................... 60

Statistiche sul progetto ............................................................................................. 60

Bibliografia .......................................................................................... 63

Riferimenti GWT ....................................................................................................... 63

Riferimenti JDO ........................................................................................................ 63

Riferimenti Cloud Computing .................................................................................... 63

Sitografia .............................................................................................. 65

Indice delle figure .............................................................................. 67

Indice .................................................................................................... 69

Appendici: strumenti utilizzati ....................................................... 71

Google Web Toolkit (GWT) ....................................................................................... 72

Il compilatore Java-to-JavaScript .................................................................................................. 72

GWT Shell e Hosted Mode Browser ............................................................................................. 74

Librerie Grafiche per il Web: i Widget .......................................................................................... 74

Comunicare con il server .............................................................................................................. 75

Anatomia di un’applicazione GWT ............................................................................................... 76

JSON ........................................................................................................................ 77

Utilizzare JSON in GWT ................................................................................................................. 79

Cloud Computing ...................................................................................................... 79

Componenti chiave ...................................................................................................................... 80

Vantaggi e svantaggi ..................................................................................................................... 81

Approcci dei principali competitor ............................................................................................... 82

Il Cloud Computing di Google: Google App Engine (GAE) ............................................................ 83

Java Data Object (JDO) .............................................................................................. 84

JDOQL ........................................................................................................................................... 86

Usare il datastore AppEngine con JDO ......................................................................................... 86

Ringraziamenti ................................................................................... 89

5

Cap.1

Introduzione Lo stage si è svolto nell’ambito della collaborazione tra l’Università degli Studi di Torino e l’azienda di sviluppo e consulenza informatica Bnc s.p.a..

Obiettivo L’obiettivo del progetto OvunqueScuola è lo sviluppo di un’applicazione web per la

gestione di scuole che sfrutti le recenti opportunità offerte dal Cloud Computing ed in particolare dalle infrastrutture hardware e software di Google.

L’idea L’idea del progetto è nata dall’opportunità di far fronte a problematiche nella gestione

delle scuole. Attualmente, infatti, il sistema di gestione produce una gran quantità di

documentazione cartacea che rende spesso necessario replicare più volte lo stesso dato in documenti diversi. Questo porta a delle inefficienze legate sia alla necessità di dover trascrivere manualmente la stessa informazione in più posti, sia alla possibilità che si creino delle inconsistenze tra le varie versioni documentarie.

Oltre a questo si è notato che un sistema informatizzato potrebbe rendere più efficace e agevole la comunicazione tra scuola, genitori e studenti.

Da queste idee abbiamo poi analizzato altre problematiche relative alla gestione e alla comunicazione e come queste si sarebbero potute ridurre, se non risolvere, con un sistema di tipo informatico. La tabella seguente mostra un’analisi ad alto livello dello stato attuale di gestione, tradizionale, e un’ipotesi di gestione attraverso un sistema informativo.

Lo scopo finale del progetto è la sostituzione di tutta la documentazione cartacea con registri e documenti digitali al fine di rendere più rapida, efficace ed economica la

gestione della scuola.

Gestione e comunicazione dei voti TRADIZIONALE INFORMATIZZATA

Quando l’insegnante assegna un voto a uno studente lo scrive sul registro personale, sul diario dello studente e sulla pagella a fine semestre.

L’insegnante inserisce il voto una volta sola nel sistema informativo.

Quando lo studente riceve un voto lo scrive sul diario ma non ha una visione generale dell’andamento scolastico.

Il voto viene registrato una sola volta nel sistema e lo studente può visualizzare tutti i voti divisi per materia con le medie e una

Capitolo 1

6

serie di grafici.

Quando l’insegnante assegna un voto lo scrive sul registro personale, a fine semestre calcola la media dei voti per ogni studente.

L’insegnante ha a disposizione delle tabelle e dei grafici con l’andamento scolastico dei suoi alunni e la relativa media.

Il genitore segue l’andamento scolastico del figlio attraverso le votazioni sul diario.

Il genitore ha a disposizione l’andamento scolastico del figlio presentato con una tabella dei voti e un grafico per ogni materia, uno complessivo, le medie e i rapporti disciplinari.

Comunicazioni scuola-genitori TRADIZIONALE INFORMATIZZATA

La segreteria invia una circolare che viene fatta girare in tutte le classi, gli studenti riportano il testo sul diario e lo fanno leggere ai genitori.

La segreteria pubblica l’avviso sul sistema, questo invia un messaggio ai destinatari selezionati, singolarmente o per gruppi di utenza (ad esempio a tutti i genitori di una classe).

Quando un genitore vuole contattare un insegnante, il rappresentante dei genitori o d’istituto lo fa attraverso l’alunno o la segreteria.

Il sistema prevede la gestione di messaggi e rende disponibili al genitore i recapiti degli insegnanti della classe, dei rappresentanti dei genitori, dei rappresentanti d’istituto e degli altri genitori che hanno dato il consenso a rendere pubblico il recapito.

Promemoria TRADIZIONALE INFORMATIZZATA

Studenti e professori gestiscono con registri, diari e documenti cartacei le interrogazioni e le verifiche programmate.

Il sistema crea dei promemoria per verifiche e interrogazioni programmate, sia per gli alunni che per i professori.

Quando l’insegnante assegna un progetto gestisce con appunti personali le specifiche e le consegne.

Il sistema gestisce un sistema automatizzato di consegne: il professore apre una consegna con una scadenza, gli studenti visualizzano le specifiche e la data di consegna. Ogni studente ha poi la possibilità di inviare un file e il sistema registra data e ora dell’invio.

Quando un alunno fa un’assenza gli insegnanti devono ricordarsi delle giustificazioni da portare.

Il sistema avvisa i professori delle assenze da giustificare.

Quando l’alunno torna da un’assenza chiede il programma che è stato svolto in sua assenza.

Lo studente può visualizzare giorno per giorno gli argomenti svolti per ogni materia.

Statistiche TRADIZIONALE INFORMATIZZATA

Il sistema cartaceo rende difficile calcolare delle statistiche sui dati.

Il sistema mette a disposizione il pannello delle statistiche in cui è possibile creare dei report su voti, assenze e altri dati disponibili.

Introduzione

7

Tabella 1: comparazione di alcune funzionalità,il modello di gestione tradizionale e

un’ipotesi di gestione in un modello informatizzato.

Al fine di svolgere un buon lavoro, per la parte grafica del nostro progetto ci siamo ispirati ai layout e ai contenuti dei registri di classe ed ai registri personali dei professori.

Figura 1 registro personale dei professori

Capitolo 1

8

Figura 2: registro di classe

Introduzione

9

Il progetto OvunqueScuola Il progetto nasce perciò come sistema di gestione per le scuole accessibile da web e ospitato su un’architettura di tipo Cloud, descritta nel dettaglio più avanti.

Gli utenti sono stati suddivisi in sei tipologie:

� amministratore di sistema (superadmin), � amministratore di comprensorio 1(admin), � insegnante, � studente, � genitore, � utente non registrato.

Per ogni tipologia sono state individuate delle funzionalità caratteristiche, in particolare:

� amministratore di sistema (superadmin): � Gestione comprensori � Abbinamento comprensori-amministratori

� amministratore di comprensorio (admin): � Gestione insegnanti � Gestione studenti � Gestione classe � Gestione ore classi � Gestione materie � Gestione domini istituti � Gestione statistiche � Gestione notifiche � Gestione gruppi/utenze

� insegnante: � Gestione programma di classe � Gestione presenza studenti � Gestione programma del giorno � Gestione compiti � Gestione interrogazioni � Gestione materiale informativo

� studente: � Visualizzare andamento scolastico � Programma settimanale � Lezioni del giorno � Comunicazione scuola

� genitore: � Visualizzare assenze e note � Visualizzare andamento scolastico � Lezioni del giorno � Programma settimanale � Comunicazione scuola

� utente non registrato: � Comunicazione scuola

1 Per comprensorio si intende un insieme di scuole appartenenti ad un’unica proprietà.

Capitolo 1

10

Dalla pagina principale l’utente può autenticarsi oppure scegliere la scuola d’interesse attraverso un menù a tendina e visualizzare così gli avvisi generali relativi a quella scuola: ad esempio chiusure straordinarie, cambiamenti di orario, ecc…

Quando un utente effettua il login, il sistema ridireziona automaticamente la richiesta in base alla tipologia di utente; se l’utente è registrato accederà alla homepage relativa al proprio gruppo di appartenenza, cioè genitore, studente, insegnante, admin o superadmin. Le caratteristiche dettagliate di queste pagine verranno descritte in seguito nell’analisi dei requisiti.

Dalle suddette pagine principali, ogni utente può accedere alle funzionalità messe per lui a disposizione dal sistema. La struttura delle pagine è uguale per tutti gli utenti ed è suddivisa in tre aree principali:

Figura 3: layout pagine

Per rendere più agevole la navigazione e l’usabilità del sito sono stati adottati degli accorgimenti. Al fine di utilizzare al massimo l’area disponibile per l’applicazione sono stati ridotti al minimo gli spazi vuoti tra i vari elementi della pagina, mantenendo comunque una disposizione strutturata per permettere di trovare agevolmente le diverse funzionalità. Inoltre l’intestazione cambia dimensione dalla pagina principale rispetto a quella specifica di un tipo d’utenza; nella pagina principale è più alta, per identificare immediatamente il sito e il nome del servizio, mentre nelle pagine specifiche si abbassa per lasciare posto ai contenuti e agli elementi dell’applicazione.

Le fasi di progettazione Il progetto è stato avviato a Luglio 2009 ed è tuttora in corso. Lo sviluppo si è svolto in diverse fasi.

Inizialmente si sono svolti degli incontri con il relatore e i tutor aziendali in cui si sono definiti gli obiettivi, le specifiche del progetto e una prima panoramica generale degli strumenti da utilizzare. Nel corso degli incontri si sono definiti meglio gli obiettivi e i

Introduzione

11

requisiti dell’applicazione. Abbiamo poi impostato e configurato l’ambiente di sviluppo, che verrà descritto più avanti.

Le prime due settimane sono state dedicate all’approccio con gli strumenti e con le librerie che sono state utilizzate nel progetto. Lo studio di questi strumenti è stato seguito dai tutor ed è avvenuto principalmente per mezzo di libri/manuali[1-7] e tutorial, tra cui quelli ufficiali forniti dalla stessa Google[w1].

La fase successiva è stata lo sviluppo vero e proprio che ha riguardato l’analisi dei requisiti, lo sviluppo completo dell’interfaccia grafica e l’inizio dell’implementazione delle funzionalità di backend.

Allo stato attuale il progetto è completo per quanto riguarda l’interfaccia grafica e la navigazione nelle pagine. Per la parte del backend sono state implementate tutte le funzionalità ad eccezione di quelle relative alla gestione del registro di classe e dei corsi. E’ inoltre stato fatto il deploy su Appengine della parte già sviluppata.

Ambiente di sviluppo

Sistema operativo Il progetto è stato sviluppato su due macchine con sistemi operativi differenti, Ubuntu 9.04 e Mac Os X 10.5.8. Nonostante questa differenza non si è riscontrato alcun problema di compatibilità tra i due sistemi. Questo grazie alla scelta di utilizzare Java come linguaggio di programmazione e lo stesso framework disponibile per i due sistemi operativi.

Linguaggio di programmazione Si è scelto di usare Java. Questa scelta è derivata principalmente da tre motivazioni. La prima è che Java, insieme a Python, è uno dei due soli linguaggi per cui sono disponibili le librerie GWT. In secondo luogo, sia noi che i tutor aziendali, avevamo già una certa esperienza con questo linguaggio, abbiamo potuto quindi dedicare più tempo allo studio della libreria e alla metodologia di sviluppo dell’applicazione anziché all’aspetto più tecnico del linguaggio implementativo. Infine si è scelto Java per la moltitudine di librerie open source che sono messe gratuitamente a disposizione online da altri sviluppatori.

Framework Abbiamo utilizzato Eclipse[w2], in particolare la versione Galileo (nei primi mesi abbiamo utilizzato la precedente versione Ganimede, per problemi di incompatibilità con i plugin). La scelta di questo framework è derivata principalmente dal fatto che si integra facilmente con la libreria GWT tramite un plugin fornito dalla stessa Google. Oltre a questa motivazione principale ve ne sono altre, comunque significative. La prima è che questo framework è open source e, essendo un progetto nato da diversi anni e molto utilizzato, offre allo stato attuale una notevole robustezza. Inoltre, per Eclipse, sono disponibili numerosi tools che rendono più agevole la programmazione, lasciando più tempo da dedicare agli aspetti di progettazione. Un’ulteriore aspetto che ha determinato la scelta di questo framework è che

Capitolo 1

12

Eclipse permette di testare un progetto GWT in modalità “hosted mode”, cioè ospitato in una finestra, senza la necessità di doverlo compilare ogni volta; questo garantisce un notevole risparmio di tempo nella fase di sviluppo e debug.

Figura 4: l'ambiente di sviluppo Eclipse sul sistema operativo MacOs X

Software di versionamento Sviluppando in team è nata la necessità di utilizzare uno strumento per sincronizzare il nostro lavoro. A tale scopo abbiamo utilizzato SVN Subversive[w3], plugin fornito da eclipse e quindi completamente integrato nel framework, con l’aggiunta del Connectors di Polarion[w4]. Questo sistema ci ha permesso di lavorare in parallelo al progetto senza il problema di avere versioni differenti sui due computer e potendo lavorare anche a distanza con una versione sempre consistente e aggiornata del progetto.

13

Cap.2

Analisi funzionale Analizzando l’alto numero di requisiti per il tempo a nostra disposizione, si è deciso di realizzare OvunqueScuola come prototipo evolutivo, puntando ad incrementare la velocità di fornitura del prodotto per fornire un’applicazione, anche se inizialmente dimostrativa, da mostrare a possibili clienti, quali presidi, personale delle segreterie didattiche e professori. Adottando questo metodo, siamo stati in grado di valutare a fondo le reazioni e le esigenze degli utenti destinatari del prodotto.

Abbiamo perciò affrontato il problema partendo dalla parte grafica (utilizzando Google Web Toolkit) e fissato obiettivi intermedi per concentrarci di volta in volta su parti specifiche. Contemporaneamente abbiamo costruito, giorno dopo giorno, la struttura della base di dati che deve sostenere la logica applicativa.

Per quanto riguarda la parte grafica, abbiamo deciso di dividere la pagina web in 3 parti:

� in alto, un header in cui visualizzare principalmente il nome e il logo dell’applicazione;

� a sinistra, un menu contenente la macro suddivisione delle funzionalità disponibili per l’utente che sta utilizzando il sistema;

� al centro-destra, un pannello content in cui inserire dinamicamente i contenuti richiesti dall’utente.

Casi d’uso generali e diagramma delle classi Basandoci sulle frasi nominali forniteci, abbiamo approcciato al progetto con un iniziale diagramma dei casi d’uso per focalizzare i punti in comune a tutti i tipi di utenti.

Figura 5: diagramma casi d'uso utente generico

Come possiamo vedere, un utente, appena si collega al sistema, può consultare la bacheca pubblica di tutte le scuole registrate nel sistema ed effettuare il login. Per consultare la bacheca deve inserire i dati relativi alla scuola e il sistema, dopo aver effettuato la ricerca, gli fornisce le comunicazioni globali pubbliche.

Capitolo 2

14

Figura 6: l'homepage di OvunqueScuola

Effettuando il login invece, in caso di successo (utente registrato) l’utente viene reindirizzato all’homepage relativa al gruppo a cui appartiene. Utente registrato è quindi una generalizzazione esclusiva di superadmin, admin, insegnante, studente e genitore.

Proseguendo con l’analisi, riscontriamo i seguenti casi d’uso in comune per tutti i tipi di utenti registrati:

Analisi funzionale

15

Come si può osservare, ogni utente registrato deve essere in grado di:

� gestire i messaggi email-like, inviandone di nuovi oppure consultando, archiviando o eliminando quelli ricevuti;

� gestire i propri appunti, creandone di nuovi oppure consultando, modificando o eliminando quelli esistenti;

� gestire il proprio calendario, consultandolo o inserendo nuove note; � visualizzare le comunicazioni ufficiali ricevute o inviare richieste alla

segreteria; � consultare l’help (frequently asked question, FAQ).

Capitolo 2

16

A seguito di vari incontri con i tutor e dopo aver ricevuto feedback da esperti del settore, abbiamo creato questa versione del diagramma preliminare delle classi:

Analisi funzionale

17

Evoluzione dell’analisi funzionale Analizzando approfonditamente tutti i casi d’uso e le funzionalità del nostro progetto, abbiamo eliminato le relazioni molti-a-molti e le generalizzazioni, adottando questo particolare diagramma delle classi che coincide, grazie alla trasparenza di JDO, alle tabelle del nostro database. Le cardinalità sono espresse rispetto al modello UML, cioè al contrario

Capitolo 2

18

degli schemi Entity-Relationship.

In particolare, si può notare che la gerarchizzazione tra i vari tipi di persone e la superclasse Persona è stata eliminata, lasciando soltanto le classi concrete (cioè eliminando la superclasse spostando i propri attributi nelle sottoclassi). Questo perché ogni classe riferita ad un particolare tipo di utenza ha associazioni con classi differenti.

Allo stesso modo sono state eliminate anche le gerarchizzazioni sui Giudizi (VotoVerifica e VotoInterrogazione), sulle Comunicazioni (ComGlobali, ComGruppo e ComPersonali) e sui RapportiDisciplinari (DiClasse e Personali).

Le classi che erano al principio associate a Persona (cioè ComunicazionePersonale, Appunto, Messaggio, NotaCalendario e Login) vengono perciò assegnate a tutte le sottoclassi di Persona e alla classe TipoUtente, in quanto è indispensabile, dal punto di vista della logica applicativa, sapere su quale tabella andare ad operare per estrarre le informazioni correlate all’utente.

E’ stata introdotta la classe Materia che, come la classe TipoUtente, diventerà sul database una tabella con contenuti statici.

La classe ClassWall è stata eliminata, lasciando solamente la classe MessaggioClassWall (rinominata successivamente in ClassWall) con relazione 1-a-Molti sia con Classe che con Studente. In sostanza non esiste un contenitore classwall per ogni classe (a cui possono partecipare gli studenti), ma una serie di messaggi collegati sia con la classe che con gli studenti.

Allo stesso modo è stato eliminato il contenitore Registro, lasciando solamente la classe RecordRegistro (rinominata in Registro); ogni suo record conterrà i dati del registro di classe relativi ad una particolare ora (ad esempio, se una classe segue ogni giorno 6 ore di lezione, possederà 6 record per giorno).

La relazione molti-a-molti tra Studenti e Genitori è stata semplificata con una classe aggiuntiva, chiamata Parentela.

Anche la relazione molti-a-molti tra Corso e Orario è stata semplificata con un’ulteriore classe, chiamata OrarioLezione che conterrà un record per ogni ora di lezione settimanale dei corsi (ad esempio, se un corso deve essere seguito per 3 ore scolastiche alla settimana, possederà 3 record nella tabella relativa).

Durante una particolare fase dell’analisi, abbiamo individuato che esistono due tipi di supplenze: giornaliere e lunghe (spiegate in dettaglio nell’analisi dell’insegnante). Dal punto di vista del database, abbiamo deciso di conservare una sola classe e non due, trasformando perciò l’intera gerarchia di classi in una singola tabella “superclasse” contenente tutti gli attributi (ovviamente, in un caso o nell’altro, i record conterranno dei valori nulli).

Nella classe Login si può osservare la presenza di un attributo password; questo attributo non conterrà direttamente la password inserita al momento della registrazione (quindi “in chiaro”), ma per ragioni di sicurezza conterrà un hash della stessa. Di conseguenza, i controlli nella logica applicativa verranno effettuati sugli hash e non sulle password in chiaro.

Analisi funzionale

19

Struttura del progetto e package OvunqueScuola, come le altre applicazioni web in Java, deve essere divisa in due parti ben distinte: il package “src” contenente i file sorgenti e il package “war” contenente i file pubblici, comprese le classi derivanti dalla compilazione Java. Utilizzando Google Web Toolkit, come descritto nella parte introduttiva alla tecnologia utilizzata, il package “src” deve essere suddiviso a sua volta nei package “client” e “server”, contenenti rispettivamente il codice client-side (successivamente tradotto da GWT in JavaScript) e il codice server-side.

Figura 7 struttura del progetto e package

Per rispettare quanto più possibile il modello MVC, abbiamo inserito la parte relativa al pattern model e al pattern view nel package “client” e quella relativa al pattern control nel package “server”. In particolare, nelle sotto-cartelle del package client abbiamo:

� in model, le classi del pattern che mappano il nostro database e, per ognuna di esse, un’altra classe con le istruzioni JSNI per la deserializzazione dei dati JSON ricevuti dal server;

� in service, le interfacce degli oggetti relativi al control, utilizzate per le chiamate asincrone alle servlet del server;

� in view, le classi del pattern che creano l’interfaccia grafica dell’applicazione.

Nelle sotto-cartelle del package server, invece, abbiamo:

� in dao, le classi del pattern per eseguire le operazioni atomiche sugli oggetti del database, una per ogni classe contenuta nel model;

Capitolo 2

20

� in service, le servlet del pattern per la comunicazione client/server, divise per funzionalità.

Nel package “war” troviamo tutte le immagini e le librerie utilizzate dall’applicazione, le pagine HTML, i file CSS per gli stili e, nella sotto-cartella “WEB-INF”, il file “web.xml” in cui è definita l’homepage da servire e sono dichiarate le servlet.

Funzionalità generali Come per l’homepage di benvenuto di OvunqueScuola (disponibile per tutti gli utenti), per gli utenti registrati viene mantenuto, in tutta l’applicazione, il layout con in alto l’header, a sinistra il menu e a destra/centro il content.

A differenza dell’homepage generale, si è deciso di ridurre le dimensioni (altezza) dell’header, per dare maggior visibilità ai contenuti della pagina, evitando così lo sforzo da parte dell’utente finale di scroll frequente della pagina, soprattutto se utilizza un monitor di piccole dimensioni e/o in formato 16:9.

Per quanto riguarda il menu, nella parte in alto saranno visibili le informazioni riguardanti il proprio profilo (nome e immagine avatar) e il login (bottone per eseguire il LogOut). Subito sotto, verrà posto l’elenco delle funzionalità disponibili per il proprio profilo utente, che gli permetteranno di accedere ai relativi contenuti, inseriti di volta in volta nel content.

Ora vediamo in dettaglio come funziona il LogIn e quali sono le funzioni disponibili per tutti i tipi di utenti registrati.

Login

Durante il modo d’uso “Effettuare il login”, il sistema controlla tramite il database i dati inseriti dall’utente generico (username e password) e, in caso ci si trovi di fronte ad un utente registrato, lo ridirige nella homepage relativa al gruppo di appartenenza. In questa fase, vengono anche inviati dal server alcuni dati relativi al contesto in cui l’utente si trova, per poter accedere in qualsiasi momento, ma soprattutto in qualunque parte del codice client-side, alle informazioni relative all’utente loggato. Queste informazioni includono username, codice identificativo, gruppo ed eventuali domini e sottodomini di appartenenza dell’utente stesso.

Breve Descrizione L’utente generico effettua il login

Attori Utente

Classi Login, SuperAdmin, Admin, Insegnante, Studente, Genitore

Precondizioni L’utente compila il form nell’homepage con username e password e invia la

richiesta premendo sul pulsante.

Flusso Principale Dal lato client parte una richiesta asincrona alla servlet AuthServiceImpl

che controlla la presenza dell’utente nel database (Login). In base al suo

gruppo di appartenenza (SuperAdmin, Admin, Insegnante, Studente o

Genitore), vengono ricercate nel database le informazioni relative al

proprio “contesto” e inviate al lato client.

Analisi funzionale

21

Flussi Alternativi Se l’utente non è presente nel database (utente non registrato), viene

segnalato l’errore.

Postcondizioni Se il caso d’uso ha avuto successo, il sistema provvederà ad aprire

l’homepage relativa al gruppo di appartenenza dell’utente e potrà accedere

in qualunque momento al “contesto” dell’utente.

È interessante osservare attentamente il diagramma di sequenza per questo caso d’uso per comprendere a fondo come client e server interagiscono tra di loro.

Come descritto anche nell’analisi delle singole classi, siccome per ragioni di sicurezza nel database viene salvato l’hash (SHA-1) delle password degli utenti, anche i controlli vengono effettuati confrontando gli hash.

Calendario Ogni utente registrato ha la possibilità di consultare il calendario con le proprie note annotate. Inoltre, in base al gruppo di appartenenza, ogni utente visualizza altre informazioni utili alla vita scolastica, come descritto qui di seguito:

Capitolo 2

22

� gli insegnanti visualizzano gli orari delle lezioni relativi ai corsi che tengono all’interno della scuola;

� gli studenti visualizzano gli orari di lezione dei corsi che devono seguire; � i genitori visualizzano gli orari di lezione dei corsi che i figli devono seguire

(descritto più dettagliatamente nell’analisi dell’utente Genitore).

All’apertura del calendario, viene visualizzata una tabella con 7 colonne (una colonna per ogni giorno) e con tante righe quante sono le ore scolastiche relative alla propria scuola di appartenenza (nel caso dei superadmin e degli admin che non sono assegnati alle scuole, ci saranno 10 righe, una per ora, dalle 8 alle 18).

Figura 8: screenshot calendario

La prima colonna rappresenta il giorno odierno ed è possibile navigare di settimana in settimana o di mese in mese premendo i relativi pulsanti che si trovano sopra il calendario. Inoltre è possibile aggiungere nuove note personali premendo il pulsante [+] posto in ogni cella, avendo così l’opportunità di gestire le proprie note relativamente agli orari della scuola.

Bacheca

Per avere sempre una panoramica sulle ultime comunicazioni ufficiali provenienti dalla segreteria didattica, ogni utente possiede un pannello “Bacheca” dove, al suo interno, si trova l’elenco delle comunicazioni globali (relative alla scuola), delle comunicazioni relative

Analisi funzionale

23

al proprio gruppo di appartenenza e delle comunicazioni personali. Solitamente viene inoltre proposto un riassunto con le ultime comunicazioni ricevute anche nell’homepage di ogni utente.

Tutte le comunicazioni provengono solo ed esclusivamente dagli utenti admin della propria scuola accedendo al relativo pannello di amministrazione. Per quanto riguarda le comunicazioni personali, oltre ad includere quelle ufficiali come dichiarazioni di sospensioni, richiami all’ordine o altre simili, includono anche quelle ufficiose di risposta alle richieste effettuate dai singoli utenti insegnanti, studenti o genitori. Questi particolari utenti possono effettuare richieste dal pannello di gestione dei messaggi descritto qui di seguito.

Messaggi Un’altra importantissima funzionalità per gli utenti registrati è l’invio e la ricezione di messaggi email-like; il relativo pannello è diviso in tab, il primo contenente la “Gestione

Posta” e i successivi offrono la possibilità di inviare messaggi scegliendo il destinatario tra i vari gruppi di utenze.

La “Gestione Posta” consiste in un Widget StackPanel per dividere la posta “In Arrivo”, quella in “Archivio” e i “Messaggi Inviati”. L’elenco dei messaggi è inserito in tabelle paginate in cui vengono visualizzati i dati salienti del messaggio e vi è la possibilità di archiviare o cancellare il messaggio (nella posta in arrivo) oppure solamente cancellarlo (nella posta archiviata). È da notare anche l’intuitività nella parte grafica per quanto riguarda i messaggi ancora non letti: infatti nella posta in arrivo si differenziato da quelli letti grazie ai dati visualizzati in grassetto mentre, nella posta inviata, si riconoscono dalle icone poste al fondo di ciascuna riga. Inoltre, premendo su una qualunque riga, viene aperto un pop-up contenente i dati completi del messaggio; per la posta ricevuta è possibile anche rispondere direttamente al messaggio premendo sull’opportuno pulsante all’interno del pop-up.

Capitolo 2

24

Figura 9: screenshot "Gestione Posta"

Per inviare i messaggi ad una particolare persona è inoltre possibile farlo dai successivi tab, che contengono, divisi per gruppo di appartenenza, gli utenti disponibili in base al proprio contesto (e gruppo di appartenenza):

� superadmin �� superadmin e admin; � admin �� superadmin e admin, insegnanti, studenti, genitori,

rappresentanti d’istituto e rappresentanti di classi relativi ai proprio comprensorio e sotto-domini;

� insegnanti �� studenti, genitori e rappresentanti delle classi in cui insegnano, insegnanti colleghi appartenenti alla stessa scuola e rappresentanti del proprio istituto;

� studenti �� studenti e rappresentanti della propria classe, rappresentanti del proprio istituto e insegnanti che insegnano nella propria classe;

Analisi funzionale

25

� genitori �� rappresentanti della classe e genitori dei compagni di classe dei propri figli e insegnanti che insegnano loro.

Figura 10: screenshot "Invia Nuovo Messaggio"

Dall’ultimo tab è ulteriormente possibile accedere all’invio di messaggi alla segreteria didattica; questi messaggi non sono più considerati tali, ma “comunicazioni personali” che gli admin visualizzeranno nella “gestione della scuola”; le relative risposte saranno invece visualizzate degli altri utenti nella “bacheca”.

Gli studenti e i genitori non possono comunicare tra di loro anche se facenti parte dello stesso contesto “classe”, per evitare di creare situazioni illegali quali la pedofilia.

Inoltre, tra genitori di figli appartenenti alla medesima classe si può comunicare solo se accettano espressamente di farlo. Verrà sviluppato più dettagliatamente nell’analisi dell’utente Genitore.

Appunti Come per il calendario, è possibile per gli utenti registrati prendersi delle note; in questo caso non sono legate ad un particolare orario, ma alle materie. Dal relativo pannello di gestione è possibile perciò crearne di nuove e visualizzare, modificare e cancellare quelle già presenti.

All’apertura della pagina, vengono visualizzati tutti i propri appunti in una tabella paginata: in ogni riga sono presenti i dati salienti della nota (come titolo, ultima modifica e materia di riferimento) e un bottone per eliminarla; premendo su una qualunque riga, viene aperto un nuovo tab in cui è possibile modificare l’appunto.

Capitolo 2

26

Figura 11: pannello degli appunti

Come espressamente richiesto da presidi e insegnanti, all’interno dell’applicazione queste particolari note verranno sempre chiamate “appunti” in quanto facilmente confondibili dagli utenti finali con le “note sul registro”.

Faq Come in ogni applicazione che si rispetti ci deve essere un “help” o delle “Frequently Asked Question” a cui ci si può affidare in caso di dubbi o problemi. In OvunqueScuola ci saranno delle F.A.Q., suddivise in base all’utenza che le richiede, sull’utilizzo dell’applicazione e sui principali dubbi che potrebbero sorgere alle persone che la utilizzano.

Per mostrare le più frequenti domande/risposte abbiamo deciso di creare un elenco delle domande inserite nel database, poste ognuna in un Widget DisclosurePanel, facendo in modo che l’utente, leggendo la domanda, con un semplice click possa visualizzare solo la relativa risposta. In questo modo la pagina risulta ben ordinata e di dimensioni ridotte, favorendone la consultazione.

SuperAdmin L’homepage relativa al superadmin si apre con un riassunto settimanale delle proprie note sul calendario, posto nel content. Nel menu di sinistra, oltre la voce principale (“HOME”), troviamo, in ordine, bottoni per accedere alla gestione completa del proprio calendario (“Calendario”), alla gestione di admin e comprensori (“Gestione”), alla gestione dei propri appunti (“Appunti”), all’invio e alla ricezione di messaggi email-like (“Messaggi”) e alla consultazione delle domande/risposte frequenti (“FAQ”).

Ecco in dettaglio i casi d’uso per un utente superadmin:

Analisi funzionale

27

Figura 12: casi d'uso utente Superadmin

Gestione La funzionalità più importante per il superadmin è la gestione degli admin, dei comprensori e delle associazioni tra di essi. La pagina che si apre alla pressione del bottone del menu “Gestione” è principalmente formata da due tab, in cui gestire rispettivamente Comprensori e Admin. In entrambi, il contenuto grafico è pressoché uguale, in modo da creare un senso di omogeneità e coerenza; sono 3 oggetti disposti verticalmente nel seguente ordine: maschera di ricerca, bottone per l’inserimento di un nuovo oggetto e tabella paginata contente i risultati dell’interrogazione al database con alcuni bottoni per ogni riga per effettuare modifiche sul relativo oggetto.

Capitolo 2

28

Figura 13: screenshot "Gestione" del superadmin

Nel contesto “comprensorio”, le ricerche si possono effettuare per corrispondenza univoca dell’identificativo del comprensorio oppure per corrispondenza parziale del nome del comprensorio. I risultati dell’interrogazione al database vengono inseriti quindi in una tabella paginata contenente, in ogni riga, il nome del comprensorio e una serie di bottoni per l’assegnazione, la modifica e la cancellazione del comprensorio stesso.

Nel contesto “admin”, similmente, si possono effettuare ricerche per corrispondenza univoca dell’identificativo dell’admin o del cap oppure per corrispondenza parziale del codice fiscale, del cognome o del nome. I risultati dell’interrogazione al database vengono inseriti quindi in una tabella paginata contenente, in ogni riga, il cognome e il nome dell’admin e una serie di bottoni per l’assegnazione, la modifica e la cancellazione dell’admin stesso.

Analizziamo ora il caso d’uso “Aggiungere un admin ad un comprensorio” per comprendere come classi e attori interagiscono tra loro:

Breve Descrizione Il superadmin associa un admin ad un comprensorio

Attori superadmin

Classi Admin, Comprensorio

Precondizioni L’admin da associare deve essere presente in Admin; il comprensorio deve

essere presente in Comprensorio.

Flusso Principale Da pannello di gestione Comprensorio: visualizzare le associazioni per un

comprensorio, premendo il bottone apposito; inserire l’id dell’admin da

associare al comprensorio; premere il bottone per inviare la richiesta al

server.

Da pannello di gestione Admin: visualizzare l’associazione per un admin,

premendo il bottone apposito; inserire l’id del comprensorio da associare

all’admin; premere il bottone per inviare la richiesta al server.

Flussi Alternativi Da pannello di gestione Comprensorio: se l’admin e’ già associato ad un

Analisi funzionale

29

comprensorio, l’associazione non viene effettuata e viene segnalato l’errore.

Da pannello di gestione Admin: se l’admin e’ già associato ad un

comprensorio, occorre prima rimuovere questa associazione premendo

sull’opportuno bottone, attivando il caso d’uso “Rimuovere un admin da un

comprensorio”.

Postcondizioni Se il caso d’uso ha avuto successo, l’admin sarà correttamente associato al

comprensorio e potra’ di conseguenza operare su di esso.

Per comprendere in pieno il modo in cui frontend e backend si scambiano richieste e informazioni occorre osservare il seguente diagramma di sequenza per il caso d’uso sopra-citato:

Come si può vedere, dal codice del pattern “view” lato client (cioè dall’oggetto/classe SuperAdminPanel) parte una connessione asincrona verso il server, più precisamente verso la servlet AssociazioniServiceImpl che effettua 4 chiamate a due oggetti del pattern “dao” che eseguono operazioni atomiche sul database. Le operazioni richieste sono:

Capitolo 2

30

� Controllo di esistenza del comprensorio passato per parametro (ricerca per id);

� Controllo di esistenza dell’admin passato per parametro (ricerca per id); � Aggiornamento del campo idComprensorio dell’oggetto Admin; � Aggiornamento del campo numeroAdmin dell’oggetto Comprensorio.

Intanto, subito dopo la chiamata, prosegue l’esecuzione del codice del pattern “view” che visualizza pop-up indicante la connessione al database in corso. Appena giunge una risposta dal server, viene chiuso il pop-up e, in caso di successo, viene visualizzata la corretta associazione, altrimenti viene segnalato il tipo di errore riscontrato.

Per quanto riguarda il superadmin, si è deciso di permettergli di effettuare le associazioni tra admin e comprensori tramite il rispettivo codice identificativo in quanto si tratta di un utente amministratore dell’intera applicazione, quindi abile ad agire di conseguenza. Non gli è stato dato alcun altro privilegio di gestione, in quanto potenzialmente dannoso in caso di furto di account o di azioni dolose.

Admin L’homepage relativa all’admin si apre con un riassunto delle ultime comunicazioni ufficiali della segreteria e una vista settimanale delle proprie note sul calendario, posti nel content. Nel menu di sinistra, oltre la voce principale (“HOME”), troviamo, in ordine, bottoni per accedere alla gestione completa del proprio calendario (“Calendario”), alla gestione del

comprensorio e delle scuole (“No domain” se l’admin non è associato a nessun comprensorio o “<nome-comprensorio>” se l’admin è associato), alla visualizzazione delle comunicazioni ufficiali ricevute (“Comunicazioni”), alla gestione dei propri appunti (“Appunti”), all’invio e alla ricezione di messaggi email-like (“Messaggi”) e alla consultazione delle domande/risposte frequenti (“FAQ”).

Analisi funzionale

31

Ecco in dettaglio i casi d’uso per un utente admin:

Figura 14: casi d'uso utente Admin

Per semplificare la visualizzazione del secondo schema si è deciso di rappresentare con un solo caso d’uso “CRUD” i consueti 4 casi d’uso per la gestione di un oggetto, ossia “Creare” (o “Create”), “Consultare” (o “Read”), “Modificare” (o “Update”) e “Cancellare” (o “Delete”).

Come accennato in precedenza, durante la creazione del pannello menu, vengono effettuate delle chiamate asincrone per la creazione del bottone relativo al comprensorio a cui l’admin è associato. Se non è associato ad alcun comprensorio, verrà visualizzato un bottone disabilitato contenente tale informazione (ad esempio “No domain”). Se invece è associato ad un comprensorio, verrà creato un un Widget di tipo DisclosurePanel (vedi immagine a lato) nella cui intestazione sarà visualizzato il nome del comprensorio; all’interno di questo

Capitolo 2

32

pannello ci sarà un elenco contenente, come prima voce, un bottone “Generale” (dal quale si accede alla gestione del comprensorio) e tanti bottoni quante sono le scuole associate al comprensorio stesso (dai quali si accede alla gestione della scuola a cui fa riferimento). Ovviamente, se non ci sono scuole associate, il pannello conterrà solamente il bottone “Generale”.

È interessante analizzare il diagramma di sequenza relativo a questa operazione svolta dal sistema per comprendere la comunicazione client/server:

Gestione comprensorio Una delle funzioni principali di un utente admin è sicuramente quella di poter gestire il proprio comprensorio di scuole. Premendo l’apposito pulsante del menu (“Generale”, all’interno del pannello con il nome del proprio comprensorio), si apre nel content un TabPanel, in cui si possono notare 4 tab: Scuole, Amministratori, Statistiche, Stampe.

Analisi funzionale

33

All’interno del tab “Scuole”, si possono gestire le scuole relative al comprensorio. Come per il superadmin, il layout del pannello di ricerca, dei pulsanti per aggiungere oggetti e della tabella paginata risulta essere lo stesso e sarà uguale per tutti i pannelli di gestione dell’applicazione OvunqueScuola. Le operazioni che si possono eseguire sono, oltre la ricerca, la creazione di nuove scuole, la modifica e la disabilitazione/riabilitazione temporanea di scuole già esistenti. Inoltre è possibile anche gestire l’elenco dei consiglieri d’istituto (genitori di studenti appartenenti alla scuola o studenti maggiorenni). Le operazioni che tendono a modificare il contenuto di un oggetto Scuola possono essere attivate dai pulsanti

contenuti nella tabella risultato della ricerca.

Nel tab “Amministratori”, si trova il pannello di gestione degli admin. È molto simile a quello del superadmin, con la differenza che non è possibile assegnare un admin ad un comprensorio diverso da quello del contesto dell’utente admin che sta visualizzando la pagina. Infatti, quando si crea un nuovo oggetto Admin, esso viene creato già associato al comprensorio del contesto. Analogamente, anche le ricerche (e di conseguenza modifiche e cancellazioni) vengono effettuate automaticamente filtrando solo ed esclusivamente gli oggetti che appartengono al dominio (o comprensorio) del contesto.

Nel tab “Statistiche”, invece, è possibile effettuare delle viste sul database. Durante l’incontro con i presidi e i professori delle scuole, è emerso che la segreteria didattica necessita di uno strumento per analizzare con pochi, semplici e veloci passi il rendimento sia degli studenti sia del corpo

docenti, per avere la possibilità di riscontrare anomalie ed affrontarle tempestivamente.

Ad esempio, controllare i voti di una classe per un certo professore è utile al fine di rilevare un eventuale approccio alla didattica errato da parte dell’insegnante; infatti, avere la quasi totalità degli studenti con voti troppo alti o troppo bassi, potrebbe essere sintomo di un estremo buonismo nell’assegnazione dei voti stessi o di una carenza in materia di insegnamento.

Graficamente abbiamo deciso di utilizzare un Widget StackPanel per poter navigare tra i vari tipi di statistiche e di utilizzare un tipo di grafico, fornito online da Google, per la visualizzazione dei risultati delle interrogazioni al database.

Capitolo 2

34

Dall’incontro è emerso anche il fatto che, a fine anno, la segreteria didattica debba stampare su carta tutti i registri di classe e quelli personali dei professori. Per risolvere questo problema, all’interno del tab “Stampe” è possibile creare file pdf stampabili dei registri di classe e dei professori; in aggiunta è possibile crearli anche sulla base di altre viste, come ad esempio l’elenco delle assenza per ogni alunno e così via.

Gestione scuola

La gestione di una singola scuola è il punto fondamentale per un utente admin. Come osservato nel diagramma dei casi d’uso, si può suddividere in 3 macro funzionalità: la gestione degli utenti, la gestione didattica della scuola e la gestione delle comunicazioni ufficiali. Bisogna tenere presente che tutte le funzionalità che mostreremo in dettaglio in seguito faranno riferimento ad un contesto Scuola, relativo al pulsante del menu premuto: infatti, entrando nella gestione di una particolare scuola, tutte le comunicazioni, gli utenti o qualsiasi altro oggetto che si andrà a manipolare farà riferimento ad essa.

Gestione utenti Gli utenti, relativi ad una specifica scuola, che un admin può gestire sono gli insegnanti, gli studenti e i genitori di quest’ultimi.

Figura 15 pannello per gestire gli utenti

La pagina è suddivisa, come visto in precedenza per altri tipi di gestione, in 3 tab, ognuna delle quali con il layout generale descritto in precedenza, ossia maschera di ricerca, pulsante per creare un nuovo oggetto e tabella paginata per i risultati dell’interrogazione al database. Per tutti è possibile effettuare una ricerca sugli attributi principali, cioè codice identificativo, codice fiscale, cognome, nome e cap, con un filtro basato sull’abilitazione. Sui rispettivi risultati è possibile eseguire classiche operazioni di modifica e disabilitazione/riabilitazione.

Analisi funzionale

35

Sia sugli studenti che sui genitori è inoltre possibile gestire le parentele che li accomunano, abilitando così all’utente genitore quelle funzioni che gli permettono di esaminare l’andamento scolastico del proprio figlio. Quest’assegnazione viene fatta inserendo il codice fiscale del genitore (in caso di gestione dello studente) o il codice fiscale dello studente (in caso di gestione del genitore).

Per quanto riguarda lo studente, è inoltre possibile applicare un ulteriore filtro sulle ricerche, cioè l’eventuale assegnazione ad una classe. In caso non si applichi il filtro, sono comunque facilmente individuabili gli studenti senza classe rispetto agli altri, grazie ad una piccola e intuitiva icona posta nella relativa riga della tabella.

Gestione scuola (Didattica) Nell’ambito della didattica, un admin deve poter gestire le classi, i corsi (che più comunemente nelle scuole medie inferiori e superiori vengono chiamate “materie”), le supplenze, i registri di classe e l’orario scolastico.

Oltre le solite funzionalità, nella gestione delle classi abbiamo la possibilità di aggiungere/rimuovere gli studenti e i rappresentanti di classe (genitori degli studenti o studenti maggiorenni). Questa operazione avviene tramite l’inserimento degli opportuni codici fiscali nei pannelli pop-up che appaiono alla pressione del relativo bottone; come si può notare, differentemente dal pannello dei superadmin, le associazioni non avvengono tramite codice identificativo (concetto alquanto astratto e difficile da comprendere per un utente non informatico), ma tramite codice fiscale (concetto più familiare e comunque utile nell’identificare univocamente la persona cercata).

Figura 16: gestione alunni per classe

Capitolo 2

36

Le materie che gli studenti di una classe devono seguire, in OvunqueScuola prendono il nome di “corsi”, mettendo in relazione classi, materie, professori e orari di lezione. Infatti, durante la creazione, bisogna specificare tutti questi attributi, eccetto gli orari di lezione. Nella modifica “classica”, si potranno modificare le classi, i professori e le materie relative al corso; invece, per modificare gli orari di lezioni, occorre premere il relativo pulsante. Questa divisione deriva dal fatto che, ad inizio anno, quando un admin crea le classi ed i corsi nella base di dati, può non avere ancora deciso i relativi orari di lezione, permettendo così di aggiornarli in un secondo momento, a situazione delineata.

Figura 17: gestione corsi

Un’altra importante funzionalità è quella di poter gestire le supplenze. Come abbiamo visto nella descrizione dettagliata delle classi, ne esistono di due tipi: giornaliere e lunghe. Nel pannello di gestione vengono ricercate e visualizzate utilizzando le stesse maschere, ma gestite (durante la modifica) ovviamente in modo differente. Vengono gestite differentemente anche nella creazione di un nuovo oggetto Supplenza. Come si può inoltre notare, la grafica è molta intuitiva nel differenziare i due tipi di supplenze nella tabella con i risultati dell’interrogazione al database.

Analisi funzionale

37

Figura 18: gestione supplenze

All’inizio dell’anno scolastico un admin deve anche sistemare l’orario scolastico, in quanto ogni scuola ha il proprio. Questo orario scolastico potrà essere modificabile durante tutto il resto dell’anno, con conseguente ripercussioni sugli orari delle lezioni e sul layout del calendario degli utenti collegati direttamente alla scuola (insegnanti, studenti e genitori).

Figura 19: gestione orari scuola

Gestione comunicazioni

Tutta la segreteria didattica, il preside e gli altri suoi collaboratori devono essere in grado di inviare comunicazioni ufficiali. Ne esistono di 3 tipi: globali, per gruppo di appartenenza e

Capitolo 2

38

personali, tutte indirizzate agli utenti nel contesto della scuola. L’interfaccia grafica è divisa perciò in 3 tab, una per tipo, in cui sono inserite le comunicazioni in tabelle paginate che visualizzano i dettagli principali e i bottoni per le relative modifiche e cancellazioni.

Figura 20: gestione comunicazioni globali e per gruppo

Per quanto riguarda le comunicazioni personali, nella tabella sono state inserite anche le richieste che gli utenti della scuola hanno effettuato verso la segreteria didattica, dando così la possibilità agli admin di rispondere a tali richieste con delle comunicazioni personali. Si differenziano graficamente e funzionalmente, nel senso che:

� le richieste ricevute possono essere visualizzate nel dettaglio ed è possibile rispondere ad esse con comunicazioni personali;

� le comunicazioni personali inviate possono essere visualizzate, cancellate e modificate a posteriori.

Analisi funzionale

39

Figura 21: gestione comunicazioni personali

Insegnante L’homepage relativa all’insegnante si apre con un riassunto delle ultime comunicazioni ufficiali della segreteria, una vista settimanale delle proprie note sul calendario e un elenco delle attività principali della giornata, posti nel content. Se l’insegnante, al momento del login ha una lezione in corso, allora l’homepage si apre direttamente sul form di compilazione del registro della relativa classe.

Nel menu di sinistra, oltre la voce principale (“HOME”), troviamo, in ordine, bottoni per accedere alla gestione completa del proprio calendario (“Calendario”), alla gestione del

corso (“No class” se l’insegnante non è associato a nessun corso o “<nome-classe>” relativa al corso se l’insegnante è associato), alla gestione delle supplenze (“Supplenze”), alla visualizzazione delle comunicazioni ufficiali ricevute (“Comunicazioni”), alla gestione dei propri appunti (“Appunti”), all’invio e alla ricezione di messaggi email-like (“Messaggi”) e alla consultazione delle domande/risposte frequenti (“FAQ”).

Prima di analizzare in dettaglio le funzionalità di un utente insegnante, esaminiamone i casi d’uso:

Capitolo 2

40

Figura 22: casi d'uso utente Insegnante

Come possiamo vedere, la funzionalità principale per un insegnante è la gestione della classe, che consiste in:

� compilare registro di classe; � consultare registro di classe; � consultare registro personale; � programmare verifiche e interrogazioni; � assegnare voti; � assegnare i compiti a casa; � creare consegne; � condividere materiale didattico.

Un insegnante deve perciò poter svolgere questi compiti per ogni corso da lui tenuto nella scuola e anche per quelle classi di cui è supplente “giornaliero” o di “lungo periodo”.

Graficamente, nel menu laterale, il bottone relativo al corso da gestire è composto da un DisclosurePanel contenente il nome della classe; aprendolo abbiamo l’elenco dei corsi che l’insegnante tiene nella relativa classe; questo perché c’e’ la possibilità che un insegnante insegni più materie all’interno della stessa classe, avendo quindi l’esigenza di avere più registri personali e gestire il tutto separatamente. Ovviamente, se insegna in più classi, ci saranno tanti

Analisi funzionale

41

DisclosurePanel quante sono le classi.

Registro di classe

Come accennato in precedenza, appena un utente insegnante effettua il login, se lo stesso insegnante ha una lezione in corso viene aperta la pagina relativa alla compilazione del registro di classe; in questo modo, può fare l’appello, segnare gli assenti e le giustificazioni, segnare il programma effettuato nella giornata e annotare gli eventuali rapporti disciplinari. L’insegnante avrà tempo per compilare il registro telematicamente solo ed esclusivamente durante il proprio orario di lezione, in modo da escludere eventuali comportamenti dolosi.

E’ interessante osservare il diagramma di questa particolare attività:

Figura 23: diagramma attività "Compilare registro di classe"

Graficamente abbiamo cercato di rendere la compilazione del registro molto simile a quella cartacea (di cui le immagini nell’introduzione); ovviamente, per ragioni di spazio, l’abbiamo sviluppato in verticale anziché in orizzontale.

Capitolo 2

42

Figura 24: registro giornaliero del professore

Analisi funzionale

43

In qualsiasi momento, invece, l’insegnante può consultare il registro ci classe navigando nella relativa pagina; può effettuare due viste differenti, una giornaliera e una settimanale, che si differenziano per granularità d’informazione. In entrambe, per ogni record del registro è possibile aprire una finestra secondaria contenente tutte le relative informazioni in dettaglio.

Graficamente abbiamo tenuto lo stesso layout ufficiale per i registri cartacei, per rendere la consultazione agli insegnanti molto semplice e famigliare, aiutandoli perciò nell’individuare con facilità le informazioni che cercano.

Figura 25: registro giornaliero

Capitolo 2

44

Figura 26: registro settimanale

Analisi funzionale

45

Nella consultazione è possibile anche, tramite i bottoni posti in alto, navigare di settimana in settimana o di mese in mese. Di default, la vista che si apre all’utente quando vi accede, è relativa al giorno/settimana odierno/a.

Registro personale Oltre al registro di classe, un insegnante ha la possibilità di compilare e consultare il proprio registro personale. L’attività principale relativa alla compilazione è l’assegnazione dei voti riguardanti le verifiche, le interrogazioni e il materiale consegnato (ad esempio le ricerche a casa, i progetti, e così via).

Figura 27: valutazione dello studente

Capitolo 2

46

Durante la fase di consultazione del registro di classe, un insegnante può osservare una serie di informazioni fondamentali suddivise per studente, come tutti i voti assegnati con le relative medie, una riassunto dei rapporti disciplinari e delle assenze, in modo da poter avere in qualunque momento una visione complessiva del rendimento dei singoli studenti.

Nella fase di compilazione, invece, un’insegnante può gestire le verifiche, le interrogazioni e le consegne.

Per quanto riguarda le interrogazioni, basta creare un nuovo oggetto e modificarne o cancellarne uno già esistente immettendo un voto (da 1 a 10) e selezionando il nome dello studente; se si vuole aggiungere una piccola annotazione personale (come ad esempio dei “+”, dei “-“ o simili) basta non inserire alcun voto e riempire il campo “commento”.

Per le consegne, è possibile crearne di nuove o consultare l’elenco degli studenti che hanno consegnato del materiale (e visualizzare il relativo file); per questi studenti è inoltre possibile assegnare un voto.

Analisi funzionale

47

Figura 28: form per inserire i voti

Nell’ambito delle verifiche è possibile creare nuove verifiche, che non sono altro che dei contenitori per i relativi voti degli studenti; ovviamente è possibile anche consultare i voti delle passate verifiche ed editarne il contenuto.

Sia per le verifiche che per le interrogazioni è possibile crearne di nuove con una data successiva a quella odierna; in questi casi, la verifica/interrogazione è considerata come “programmata” e sarà visualizzata come tale nei promemoria degli studenti e dell’insegnante.

Per ogni corso tenuto, è necessario per il professore essere anche in grado di compilare il programma ministeriale e, soprattutto, una relazione di fine anno sul programma realmente effettuato, che sarà analizzato dal personale della segreteria didattica.

Capitolo 2

48

Figura 29: form per l'inserimento del programma ministeriale e della relazione conclusiva

Inoltre ha la possibilità di fornire agli studenti del materiale didattico, come slide, appunti o simili, in modo da fornire strumenti utili ai ragazzi al fine di una migliore preparazione scolastica.

Figura 30: materiale didattico

Supplenze Come visto precedentemente nelle note del diagramma delle classi, di supplenze ne esistono di due tipi: giornaliere e lunghe. Le supplenze giornaliere sono quel tipo di supplenze che nascono e si esauriscono nel giro di una giornata scolastica; solitamente il professore supplente non esegue lezioni ma rimane a controllare il comportamento degli studenti e

compila il registro di classe.

Questo tipo di supplenze possono essere create sia dalla segreteria didattica, sia dal professore stesso al momento del bisogno dal relativo pannello, indicando la classe, il giorno e le ore.

Analisi funzionale

49

Dallo stesso pannello è possibile anche visualizzare tutte le supplenze già effettuate nel corso dell’anno, per poter verificare le ore di straordinario effettuate.

Per tutte le classi in cui deve fare da supplente, l’insegnante, aprendo il relativo tab, può andare a consultare (vista giornaliera e settimanale) il registro di classe e, nel caso si trovi nell’orario di lezione della supplenza, compilarlo, allo stesso modo descritto in precedenza.

Per quanto riguarda le supplenze lunghe invece, il professore supplente deve prendere le veci del professore di ruolo, inclusi l’assegnare voti, proseguire con il programma delle lezioni e tutti gli altri compiti, avendo quindi la possibilità di accedere, oltre al registro di classe, anche al registro personale del professore di ruolo. Questo particolare caso, graficamente consiste nel creare un nuovo DisclosurePanel nel menu di sinistra, proprio come se fosse un proprio corso, con tutte le funzionalità descritte precedentemente.

Studente L’homepage relativa allo studente si apre con un riassunto delle ultime comunicazioni ufficiali della segreteria, una vista settimanale delle proprie note sul calendario e una mini-vista del classwall, posti nel content. Nel menu di sinistra, oltre la voce principale (“HOME”), troviamo, in ordine, bottoni per accedere alla gestione completa del proprio calendario (“Calendario”), alla visualizzazione delle informazioni principali relative ai

corsi che deve seguire (“Materie”), alla visualizzazione dell’andamento scolastico (“Valutazioni”), alla visualizzazione delle comunicazioni ufficiali ricevute (“Comunicazioni”), alla gestione dei propri appunti (“Appunti”), all’invio e alla ricezione di messaggi email-like (“Messaggi”), alla partecipazione al classwall della propria classe (“Class Wall”) e alla consultazione delle domande/risposte frequenti (“FAQ”).

Prima di analizzare in dettaglio le funzionalità di un utente studente, esaminiamone i casi d’uso:

Capitolo 2

50

Figura 31: casi d'uso utente Studente

Osserviamo il caso d’uso “Visualizzare voti di una materia” dal punto di vista di un diagramma di attività per comprenderne il funzionamento:

Figura 32: diagramma attività "Visualizzare il proprio andamento scolastico"

Materie Per poter visualizzare le informazioni relative ad una materia, uno studente deve premere sul pulsante “Materie” del menu e selezionare nel contenuto aperto l’icona della materia.

Analisi funzionale

51

Figura 33: materie dello studente

A questo punto il sistema estrae i dati dal database e li mostra in un Widget StackPanel. Vengono visualizzati il nome del professore e gli orari di lezione, gli argomenti delle lezioni precedenti, i compiti da eseguire a casa, le verifiche e le interrogazioni programmate per i prossimi giorni, le consegne aperte (con la possibilità di fare l’upload del materiale da consegnare), l’elenco del materiale già consegnato e l’elenco del materiale didattico messo a disposizione dall’insegnante.

Andamento scolastico Implementando il diagramma di attività descritto sopra, uno studente, dopo aver premuto il pulsante “Valutazioni”, visualizza nel content uno StackPanel che mostra di default la media voti per ogni materia in un grafico a barre.

Figura 34: andamento scolastico complessivo

Capitolo 2

52

Premendo sul titolo relativo ad una materia all’interno dello StackPanel, vengono visualizzati in dettaglio i voti presi durante l’anno scolastico; oltre all’elenco dei voti, viene mostrato anche un grafico a linee che mostra l’andamento per quella particolare materia.

Figura 35: andamento scolastico per materia

Per avere ancora un quadro più generale per la propria situazione scolastica, è possibile accedere, tramite altri due tab, all’elenco dei rapporti disciplinari ricevuti e ad un elenco delle assenze effettuate fino a quel momento, per poter anche controllare quali di esse sono ancora giustificare.

ClassWall

L’idea di un classwall è nata principalmente per poter rendere più interattiva la comunicazione tra compagni di classe, attirando così maggiormente l’attenzione degli studenti e persuadendoli ad utilizzare l’applicazione anche per tutti gli altri scopi. Sostanzialmente si tratta di una sorta di forum, di contenitore di messaggi che, al contrario dei messaggi email-like, sono visibili da tutti (e solo) i componenti di una classe.

Analisi funzionale

53

Facendo così, si vuole dare ai ragazzi uno strumento di socializzazione che faccia capire loro che il mondo della scuola può essere svecchiato e reso più informale; si può perciò comunicare tra compagni di classe anche al di fuori delle mura della scuola, incrementando i rapporti sociali tra gli studenti e aumentando la coesione del gruppo.

Genitore L’homepage relativa al genitore si apre con un riassunto delle ultime comunicazioni ufficiali della segreteria nel content. Nel menu di sinistra, oltre la voce principale (“HOME”), troviamo, in ordine,

bottoni per accedere alla visualizzazione dell’andamento scolastico (“Valutazioni”) e alla visualizzazione degli orari di lezione dei propri figli (“Calendario”), alla visualizzazione delle comunicazioni ufficiali ricevute (“Comunicazioni”), alla gestione dei propri appunti (“Appunti”), all’invio e alla ricezione di messaggi email-like (“Messaggi”) e alla consultazione delle domande/risposte frequenti (“FAQ”).

“Valutazioni” e “Calendario” sono dei DisclosurePanel al cui interno c’è l’elenco dei propri figli iscritti nella scuola di appartenenza del genitore. Se il genitore non ha figli, ovviamente l’elenco sarà vuoto. Se invece, ha più figli situati in più scuole, il genitore dovrà possedere un account per ogni scuola.

Prima di analizzare in dettaglio le funzionalità di un utente genitore, esaminiamone i casi d’uso:

Figura 36: casi d'uso utente Genitore

Capitolo 2

54

Una delle due principali funzionalità di un genitore è quella di poter osservare l’andamento scolastico dei propri figli. Premendo il pulsante con il nome del proprio figlio nel DisclosurePanel “Valutazioni”, accede alla pagina che mostra, in 3 TabPanel, le valutazioni (e relative statistiche), le assenze e i rapporti disciplinari relativi al figlio selezionato.

L’altra funzionalità consiste nel visualizzare gli orari di lezione dei figli. Osserviamo il caso d’uso “Visualizzare gli orari di lezione del figlio” dal punto di vista di un diagramma di attività per comprenderne il funzionamento:

Analisi funzionale

55

Figura 37: diagramma di attività "Visualizzare orari di lezione del figlio"

Premendo il pulsante con il nome del proprio figlio nel DisclosurePanel “Calendario”, accede alla pagina che mostra un calendario popolato con note raffiguranti gli orari di lezione del figlio selezionato. Inoltre è possibile aggiungere delle annotazioni (funzione tipica del calendario) che saranno mostrate anche nei calendari con gli orari di lezione degli altri figli.

Figura 38: screenshot calendario del genitore, suddiviso per figlio

Capitolo 2

56

Per questione di privacy, un genitore può voler non essere contattato, tramite messaggi email-like, dagli altri genitori dei compagni di classe dei propri figli; per questo motivo, sopra il menu e’ presente un pulsante che apre una pagina in cui è possibile specificare questa particolare volontà. Ovviamente, oltre a non essere disturbati, non si potrà neanche contattare gli altri genitori.

Figura 39: screenshot impostazione privacy genitore

57

Cap.3

Conclusioni e sviluppi

futuri Nella fase conclusiva della progettazione abbiamo ipotizzato delle opportunità di sviluppo che, in futuro, potrebbero essere implementate per aumentare l’usabilità e il numero di potenziali acquirenti dell’applicazione.

Le opportunità individuate sono:

� accessibilità, � internazionalizzazione, � miglioramento delle performance, � sicurezza.

Le prime due permettono di raggiungere un numero più consistente di utenti e, per entrambe, GWT offre classi e metodologie che ne agevolano l’implementazione. Il terzo punto si potrebbe ottenere sfruttando una novità messa a disposizione da GWT dalla versione 2.0, lo Speed Tracer. Infine la sicurezza, un punto su cui abbiamo già posto attenzione ma che potrebbe essere ulteriormente migliorato.

Accessibilità, Screen readers e ARIA Un aspetto interessante delle applicazioni GWT è la possibilità di renderle accessibili. Questo permette di utilizzare la libreria anche per siti istituzionali e di rendere fruibili a più utenti le applicazioni che vengono sviluppate.

Gli screen readers sono strumenti che permettono di interpretare ciò che viene mostrato sullo schermo ai non vedenti e agli utenti con handicap visivi, tramite sintesi vocale o un display braille. Questi strumenti si interfacciano con delle API specifiche di ogni sistema operativo (ad esempio Microsoft Active Accessibility e Linux Access Toolkit).

Le applicazioni Ajax sono scritte in un modo che le rende a volte difficili da interpretare per uno screen reader. A questo scopo è nata ARIA, una specifica del W3C per rendere

accessibili le Rich Internet Applications.

Rendere accessibile un widget GWT significa aggiungere le proprietà ARIA agli oggetti

DOM dell’applicazione. Tali proprietà possono essere di due tipi: ruoli e stati. I ruoli indicano il tipo di elemento, sono specificati una volta sola all’inizio dell’applicazione e non cambiano più. Alcuni esempi di ruoli sono: tree, menubar, menuitem, tab. Gli stati invece descrivono appunto lo stato di un oggetto; ad esempio un checkbox può essere negli stati aria-checked e aria-unchecked. Lo stato è dinamico e va aggiornato durante l’interazione dell’utente. Inoltre, affinché un wiget sia accessibile, è necessario configurare il supporto per la tastiera. Gli screen readers leggono quale elemento ha l’input focus, bisogna

Capitolo 3

58

quindi settare quale elementi possono averlo e in quale ordine. Tutte queste proprietà sono assegnabili con i metodi setRole e setState della classe

com.google.gwt.user.client.ui.Accessibility e con il metodo setFocus [w1][w18].

Internazionalizzazione GWT offre diversi tools per agevolare la traduzione delle applicazioni:

� internazionalizzazione con stringe statiche, � internazionalizzazione con stringe dinamiche, � estensione o implementazione della classe Localizable.

Il metodo più semplice da implementare è quello con stringhe statiche. Questo metodo utilizza interfacce Java e property files, in particolare Constants,

ConstantsWithLookup e Messages.

Per internazionalizzare l’applicazione si procede come segue:

� si implementano due interfacce Java: � una per le costanti, l’interfaccia GWT Constants, � e una per i messaggi parametrizzati, l’interfaccia GWT Messages. (queste interfacce usano le annotations per specificare la traduzione di default).

� Quindi, per ogni lingua supportata, si creano due property files: � uno per le costanti, � e uno per i messaggi parametrizzati.

� Infine si sostituiscono tutte le stringhe inserite direttamente nel codice con dei metodi chiamati su una delle due interfacce.

Ad esempio, se nell’applicazione compare la stringa “insegnante”, si potrebbe creare una proprietà nel property file italiano:

@DefaultStringValue("insegnante")

String insegnante();

e una proprietà nel file delle proprietà inglese:

@DefaultStringValue("teacher")

String insegnante();

A questo punto, nel codice dell’applicazione, al posto della stringa basterebbe inserire propertyFile.insegnante() e il la parola verrebbe visualizzata nella lingua di default impostata nel browser.

Una metodologia simile si adotta per i messaggi parametrizzati, come ad esempio: “Il nome ’M@rio83’ contiene caratteri speciali”[w1].

Conclusioni e sviluppi futuri

59

GWT e sicurezza Le applicazioni Javascript sono in generale vulnerabili a diversi tipi di attacchi se non vengono prese alcune precauzioni. Siccome Gwt produce codice Javascript i widgets non sono immuni a questo tipo di rischi.

La politica Same Origin Policy (SOP), adottata dai web browser, dovrebbe garantire che il codice di una pagina caricata dal sito A non possa accedere ai dati di una pagina caricata sul sito B. Con Javascript è però possibile aggirare questa protezione, questa vulnerabilità è chiamata Cross-site scripting (XSS). Un XSS permette ad un attaccante di inserire codice al fine di modificare il contenuto della pagina web visitata. In questo modo si potranno sottrarre dati sensibili presenti nel browser degli utenti che visiteranno successivamente quella pagina. Questa vulnerabilità è dovuta a errori dei programmatori, che molto spesso trascurano completamente la validazione delle informazioni passate in input con le richieste HTTP[w19].

Security Token Per proteggere i dati registrati nel sito, e fare in modo che le richieste al servizio siano

soddisfatte solo per gli utenti registrati, è stato necessario distinguere tali richieste da quelle provenienti da fonti non autorizzate. Per fare questo abbiamo utilizzato il metodo del security token.

Quando un utente effettua il login viene memorizzato in una variabile di sessione HTTP una

stringa costruita calcolando lo SHA1 di username e password, il token. Quando viene effettuata una richiesta al web service oltre ai parametri della chiamata va inserito anche il token preso dalla sessione utente. In questo modo solo gli utenti effettivamente autenticati possono interagire con i servizi offerti da OvunqueScuola.

Figura 40: schema di autenticazione tramite Security Token

Capitolo 3

60

Miglioramento delle performance, Speed Tracer Speed Tracer è un nuovo strumento, disponibile dalla versione 2 di GWT, che aiuta a identificare e a risolvere i problemi di performance che si possono verificare nell’applicazione. Effettua delle misurazioni a basso livello durante l’esecuzione dell’applicazione e le visualizza poi in grafici e tabelle. Attualmente è disponibile solo come estensione di Chrome e funziona sulle piattaforme Windows e Linux.

Usando Speed Tracer è possibile farsi un’idea dei punti nei quali l’applicazione spende più tempo. Questi potrebbero essere causati, ad esempio, dall’esecuzione e parsificazione di Javascript, dal ricalcolo di stili CSS, dalla gestione di eventi DOM, dal caricamento di dati dalla rete, dal ridisegno dell’applicazione, ecc….

Figura 41: screenshot di Speed Tracer

Analizzando le misurazioni è possibile individuare i punti critici e quindi intervenire con mirate ottimizzazioni[w1].

Statistiche sul progetto Il progetto OvunqueScuola ha impegnato (fino ad ora) due studenti dottorandi per 10 mesi di lavoro, comprendendo anche il tempo dovuto all’apprendimento delle conoscenze sulla tecnologia utilizzata (Eclipse, SVN, GWT, AppEngine, JSON e JDO). È stato un lavoro

Conclusioni e sviluppi futuri

61

altamente stimolante che ci ha forniti di un know-how non indifferente e fatti diventare dei pionieri, almeno in Italia, sull’uso e la conoscenza di queste nuove tecnologie in ambito Cloud Computing.

In totale, abbiamo prodotto più di 20.000 righe di codice, di cui 13.500 relative al pattern view, 3600 relative al pattern model (frontend) e 2900 relative al pattern controller (backend).

Altre statistiche si possono osservare nella figura sottostante:

Figura 42: statistiche progetto OvunqueScuola (aggiornate al 07/03/2010)

63

Bibliografia

Riferimenti GWT [1] Robert Cooper Robert, Charles Collins. “GWT in Practice”. Manning Publications Co., 2008.

[2] Bram Smeets, Uri Boness, Roland Bankras. “Beginning Google Web Toolkit: From

Novice to Professional”. Apress, 2008.

[3] Prabhakar Chaganti. “Google Web Toolkit. GWT Java Ajax Programming”. Packt Publishing, 2007.

[4] David Geary. “Google Web Toolkit Solutions”. Pearson Education Inc., 2008.

[5] Robert Hanson, Adam Tacy. “GWT in Action: Easy Ajax with the Google Web Toolkit”. Manning Publication Co., 2007.

[6] Jeff Dwyer. “Pro Web 2.0 Application Development with GWT”. Apress, 2008.

Riferimenti JDO [7] Robin Roos. “Java Data Objects”. Pearson Education Inc., 2003.

Riferimenti Cloud Computing [8] Michael Armbrust, Armando Fox, Rean Griffith, Anthony D. Joseph, Randy Katz, Andy Konwinski, Gunho Lee, David Patterson, Ariel Rabkin, Ion Stoica, and Matei Zaharia. “Above the Clouds: A Berkeley View of Cloud Computing”. Berkeley, 2009

[9] George Reese. “Cloud Computing Architectures: Building Applications and

Infrastructure in the Cloud”. O'Reilly Media, 2009

65

Sitografia [w1] Pagina ufficiale di GWT (http://code.google.com/webtoolkit/overview.html)

[w2] Sito ufficiale di Eclipse (http://www.eclipse.org/)

[w3] Sito ufficiale di SVN Subversion (http://www.eclipse.org/subversive)

[w4] Sito ufficiale di Subversive SVN Connectors (http://www.polarion.com)

[w5] Pagina wiki .it su AJAX (http://it.wikipedia.org/wiki/AJAX)

[w6] Pagina wiki .en su GWT (http://en.wikipedia.org/wiki/Google_Web_Toolkit)

[w7] Francesco Carotenuto. “Le novità di GWT 2.0” (http://www.programmazione.it)

[w8] Pagina wiki .it su JSON (http://it.wikipedia.org/wiki/JSON)

[w9] Sito ufficiale del formato json (http://www.json.org/json-it.html)

[w10] Usare JSON in GWT (http://code.google.com/intl/it-IT/webtoolkit/doc/latest/tutorial/JSON.html)

[w11] Alfonso Maruccia. “Google App Engine punta a gestire l'intero Web” (http://punto-informatico.it/2250079/PI/News/google-app-engine-punta-gestire-intero-web.aspx). 9/04/2008

[w12] Stefano Bellasio. “Google App Engine, scopriamo la cloud di Google per le nostre applicazioni” (http://www.hostingtalk.it/articoli/cloud-computing/3325/google-app-engine-scopriamo-la-cloud-di-google-per-le-nostre-applicazi). 17/02/2009

[w13] Massimiliano Bigatti. ”Motori di persistenza in Java” (http://www.mokabyte.it/2004/07/persistence_engine-5.htm). Luglio/Agosto 2004

[w14] Sito ufficiale di AppEngine (http://code.google.com/intl/it-IT/appengine/)

[w15] Sito ufficiale di DataNucleus (http://www.datanucleus.org/products/accessplatform/index.html)

[w16] Sito ufficiale di DataNucleus API http://www.datanucleus.org/products/accessplatform_2_0/jdo/api.html

[w17] Robin Roos, traduzione di Lorenzo Felici. “Usare JDO 2.0: JDOQL” (http://www2.mokabyte.it/cms/article.run?articleId=9OP-MBN-MA4-FU3)

[w18] Sito ufficiale di ARIA (http://www.w3.org/WAI/intro/aria)

[w19] GWT e sicurezza (http://groups.google.com/group/Google-Web-Toolkit/web/security-for-gwt-applications)

67

Indice delle figure Figura 1 registro personale dei professori ................................................................................ 7

Figura 2: registro di classe ....................................................................................................... 8

Figura 3: layout pagine .......................................................................................................... 10

Figura 4: l'ambiente di sviluppo Eclipse sul sistema operativo MacOs X ............................. 12

Figura 5: diagramma casi d'uso utente generico .................................................................... 13

Figura 6: l'homepage di OvunqueScuola ............................................................................... 14

Figura 7 struttura del progetto e package ............................................................................... 19

Figura 8: screenshot calendario ............................................................................................. 22

Figura 9: screenshot "Gestione Posta" ................................................................................... 24

Figura 10: screenshot "Invia Nuovo Messaggio" ................................................................... 25

Figura 11: pannello degli appunti .......................................................................................... 26

Figura 12: casi d'uso utente Superadmin................................................................................ 27

Figura 13: screenshot "Gestione" del superadmin ................................................................. 28

Figura 14: casi d'uso utente Admin ........................................................................................ 31

Figura 15 pannello per gestire gli utenti ................................................................................ 34

Figura 16: gestione alunni per classe ..................................................................................... 35

Figura 17: gestione corsi ........................................................................................................ 36

Figura 18: gestione supplenze ................................................................................................ 37

Figura 19: gestione orari scuola ............................................................................................. 37

Figura 20: gestione comunicazioni globali e per gruppo ....................................................... 38

Figura 21: gestione comunicazioni personali ......................................................................... 39

Figura 22: casi d'uso utente Insegnante.................................................................................. 40

Figura 23: diagramma attività "Compilare registro di classe" ............................................... 41

Figura 24: registro giornaliero del professore ........................................................................ 42

Figura 25: registro giornaliero ............................................................................................... 43

Figura 26: registro settimanale ............................................................................................... 44

Indice delle figure

68

Figura 27: valutazione dello studente ..................................................................................... 45

Figura 28: form per inserire i voti .......................................................................................... 47

Figura 29: form per l'inserimento del programma ministeriale e della relazione conclusiva . 48

Figura 30: materiale didattico ................................................................................................. 48

Figura 31: casi d'uso utente Studente ..................................................................................... 50

Figura 32: diagramma attività "Visualizzare il proprio andamento scolastico" ..................... 50

Figura 33: materie dello studente ........................................................................................... 51

Figura 34: andamento scolastico complessivo ....................................................................... 51

Figura 35: andamento scolastico per materia ......................................................................... 52

Figura 36: casi d'uso utente Genitore ..................................................................................... 53

Figura 37: diagramma di attività "Visualizzare orari di lezione del figlio" ........................... 55

Figura 38: screenshot calendario del genitore, suddiviso per figlio ....................................... 55

Figura 39: screenshot impostazione privacy genitore ............................................................ 56

Figura 40: schema di autenticazione tramite Security Token ................................................. 59

Figura 41: screenshot di Speed Tracer ................................................................................... 60

Figura 42: statistiche progetto OvunqueScuola (aggiornate al 07/03/2010) .......................... 61

Figura 43: interazione sincrona e asincrona a confronto ........................................................ 71

Figura 44: funzionamento del compilatore di GWT .............................................................. 72

Figura 45: esempio di compilazione ...................................................................................... 73

Figura 46: Hosted Mode Browser .......................................................................................... 74

Figura 47: esempio di gerarchia dei Widget ........................................................................... 75

Figura 48: implementazione di una RPC................................................................................ 76

Figura 49: definizione json di "oggetto" ................................................................................ 78

Figura 50: definizione json di "vettore" ................................................................................. 78

Figura 51: stima delle risorse richieste e inutilizzate ............................................................. 81

Figura 52: competitor a confronto .......................................................................................... 82

Figura 53: esempio di stati in cui si può trovare un oggetto................................................... 85

69

Indice

Accessibilità, 57 Admin, 20, 27, 28, 30, 31, 33 Ajax, 57, 63, 71, 73, 74 AJAX, 65, 71, 72, 75, 77 Ambiente di sviluppo, 11 Andamento scolastico, 51 AppEngine, 60, 65, 81, 82, 83, 86 applicazioni RIA, 71 Appunti, 25 ARIA, 57

Bacheca, 22 BigTable, 80

Calendario, 21 casi d’uso in comune, 14 chiamata asincrona, 71 ClassWall, 52 Cloud Computing, 1, 5, 61, 63, 79, 80, 81,

82, 83

diagramma delle classi, 16, 17

Eclipse, 11

Faq, 26 fasi di progettazione, 10 funzionalità, 9 funzionalità dell' insegnante, 40 Funzionalità generali, 20

Genitore, 20, 22, 25, 53 Gestione comprensorio, 32 Gestione comunicazioni, 37 gestione degli admin, 27, 33 Gestione dei comprensori, 27 gestione del corso, 39 gestione della scuola, 5 gestione delle supplenze, 39 Gestione didattica, 35 Gestione scuola, 34 Gestione utenti, 34 Google Web Toolkit, 13, 19, 63, 72, 87

GWT, 11, 19, 57, 58, 59, 60, 63, 65, 72, 73, 74, 75, 76, 77, 79

homepage, 14 hosted mode, 12 Hosted Mode, 74

Insegnante, 20, 39, 40 Internazionalizzazione, 58

Java, 11 Java Data Object. Vedi JDO

JavaScript Object Notation. See JSON JDO, 17, 60, 63, 65, 81, 84, 85, 86 JDOQL, 86 JSON, 19, 60, 65, 73, 77, 78, 79

Login, 20

MapReduce, 80 materiale didattico, 48 Materie, 50 Messaggi, 23

orari di lezione, 22

package, 19 Posta. Vedi Messaggi programma ministeriale, 47

Registro di classe, 41 Registro personale, 45 Rich Internet Application. See

applicazioni RIA

SaaS, 80 Screen readers, 57 Security Token, 59 sicurezza, 59 Software as a Service. Vedi SaaS Speed Tracer, 60 Statistiche, 60 Statistiche scuola, 33 Struttura del progetto. Vedi Package

Indice

70

struttura delle pagine, 10 Studente, 18, 20, 49, 50 SuperAdmin, 20, 26 Supplenze, 48 Svantaggi (cloud computing), 82 sviluppi futuri, 57 SVN

Software di versionamento, 12

utenti, 9

Vantaggi (cloud computing), 81 Virtualizzazione, 80

Widget, 23, 26, 31, 33, 51, 74, 75

71

Appendici: strumenti

utilizzati La necessità di creare un’applicazione web per la gestione delle scuole nasce dai molteplici vantaggi che le applicazioni RIA (Rich Internet Application) possiedono nei confronti delle tecnologie alternative. Infatti, rispetto alle applicazioni desktop, non richiedono

installazione, gli aggiornamenti sono automatici, sono indipendenti dalla piattaforma

utilizzata, più sicure in quanto girano nel ristretto ambiente del web browser e maggiormente

scalabili perché la maggior parte del lavoro computazionale viene eseguito dal server.

Con l’avvento della tecnologia AJAX (Asynchronous JavaScript and XML), lo sviluppo di applicazioni web si basa su uno scambio di dati in background fra web browser e server, che consente l'aggiornamento dinamico di una pagina web senza esplicito ricaricamento da parte dell'utente. AJAX è asincrono nel senso che i dati extra sono richiesti al server e caricati in background senza interferire con il comportamento della pagina esistente. Infatti, rispetto alle applicazioni web tradizionali, sono più reattive perché non tutte le azioni compiute dall’utente richiedono comunicazione con il server e rendono più efficiente l’utilizzo della

rete in quanto le applicazioni RIA possono inviare richieste al web server per ottenere solo i dati che sono necessari (generalmente XML e JavaScript per mostrare la risposta del server nel browser) riducendo sensibilmente la quantità di dati scambiati e il tempo di elaborazione da parte del web server poiché la maggior parte dei dati della richiesta sono già stati elaborati.

Figura 43: interazione sincrona e asincrona a confronto

Purtroppo, scrivere applicazioni Ajax è molto complicato e perciò particolarmente esposto ad errori e bug; questo perché JavaScript è un linguaggio piuttosto differente da Java (il nome trae spesso in inganno; è stato scelto principalmente per questioni di marketing) e richiede molta pratica per lo sviluppo; il tutto è peggiorato dal fatto che JavaScript tende ad avere differenze in base al browser utilizzato, concentrando gli sforzi ed il tempo degli sviluppatori più sulla parte grafica che sulla logica applicativa[2][w5].

Appendici

72

Google Web Toolkit (GWT) Google Web Toolkit (GWT) nasce proprio per risolvere questi problemi, fornendo un vero e proprio livello di astrazione che nasconde il codice JavaScript e provvede automaticamente ad uniformare le differenze tra i browser.

Rilasciato da Google nell’estate 2006 sotto licenza Apache, Google Web Toolkit è un set di

tool open source che permette agli sviluppatori web di creare e gestire complesse

applicazioni frontend Javascript scritte in Java. Il codice sorgente Java può essere compilato su qualsiasi piattaforma con i file Ant inclusi. I Punti di forza di GWT sono la riusabilità del codice, la possibilità di realizzare pagine web dinamiche mediante le chiamate asincrone di AJAX, la gestione delle modifiche, il bookmarking, l'internazionalizzazione e la portabilità fra differenti browser[w6].

Il compilatore Java-to-JavaScript La necessità di scrivere codice in Java, invece di JavaScript, è radicata nella sempre crescente dimensione e complessità delle applicazioni RIA. Infatti le applicazioni di grandi dimensioni sono difficili da gestire, e Java è stato progettato proprio per renderle gestibili. GWT, oltre a riunire tutti i benefici di Java, consente comunque di interagire con codice JavaScript esterno e con servizi server-side già esistenti.

Figura 44: funzionamento del compilatore di GWT

Il cuore di GWT è appunto un compilatore Java-to-JavaScript che produce codice in grado di essere eseguito su Internet Explorer, Firefox, Mozilla, Safari, Opera e Chrome. Converte la sintassi di Java in JavaScript, utilizzando le versioni JavaScript delle librerie Java più comunemente usate, come Vector, HashMap, e Date.

Il compilatore è anch’esso un programma Java e, avviando la classe com.google.gwt.dev.GWTCompiler, traduce solo il codice che è effettivamente

Strumenti utilizzati

73

utilizzato all’interno del modulo, evitando cosi di trasferire codice JavaScript mai utilizzato al client. Questo procedimento richiede più tempo della normale compilazione Java, in quanto GWT crea un codice JavaScript altamente ottimizzato.

Il risultato della compilazione è una serie di file che, per un esempio “Hello World”, risulta come segue:

Figura 45: esempio di compilazione

La prima cosa che si nota è che non viene generato un solo file JS, ma uno per ogni piattaforma supportata. La classe <nome-

progetto>.nocache.js si prende cura del caricamento del corretto file per ogni specifica piattaforma. Il client e tutti gli eventuali server proxy intermedi possono tenere la cache dell’intera applicazione ottimamente perché il compilatore genera un file per piattaforma. Dal momento che il codice dell’applicazione non cambia tra una release e l’atra, l’applicazione può essere memorizzata nella cache potenzialmente per l’eternità, riducendo sensibilmente il carico e la banda utilizzata per il server. Al fine di avviare e caricare l'applicazione, è sufficiente aprire il file index.html in un browser. Questo file contiene un riferimento al file <nome-

progetto>.nocache.js[2].

Oltre al compilatore, GWT comprende anche una vasta libreria di widget e pannelli, rendendo lo sforzo di costruire un’applicazione web simile a quello per la realizzazione di un’applicazione desktop. La libreria di widget comprende i soliti oggetti come caselle di testo, menu a discesa, e altri campi del modulo, più widget complessi come barre di menu, finestre di dialogo, pannelli a schede e molti altri.

Quando si tratta di comunicazione con il server, GWT possiede uno strumento per ogni esigenza. Il primo è l'inserimento di alcuni involucri di varia complessità e capacità attorno all'oggetto JavaScript XMLHttpRequest, un oggetto spesso associato allo sviluppo Ajax. Un altro strumento fornito da GWT è un insieme di classi per sostenere il formato JavaScript

Object Notation (JSON) del messaggio. JSON è un formato di messaggio popolare, noto per la sua semplicità e la sua diffusa disponibilità. Come se non bastasse, GWT fornisce un ulteriore strumento che permette di inviare oggetti Java tra il browser e il server, senza la necessità di tradurli in un formato intermedio.

Questi strumenti di comunicazione consentono l'accesso ai servizi server-side, scritti in qualsiasi linguaggio, e rende possibile l'integrazione con framework come JSF, Spring, Struts, e EJB. Questa flessibilità offerta da GWT permette di continuare ad utilizzare gli stessi strumenti server-side in uso oggi[5].

Appendici

74

GWT Shell e Hosted Mode Browser Un’ulteriore ed importantissimo strumento per lo sviluppo offerto da GWT è la shell con l’hosted mode browser, che permette di testare la propria applicazione durante l’esecuzione del byte code Java nativo, fornendo la possibilità di utilizzare gli strumenti di ispezione preferiti. Oltretutto, l’hosted web browser, fornito di una versione alleggerita del server Apache Tomcat, rende possibile testare il proprio JavaScript compilato con JUnit[1].

Figura 46: Hosted Mode Browser

La console della shell fornisce un’ottima interfaccia per il log e per le GUI.

Il browser integrato è in grado di invocare le classi Java direttamente dagli eventi generati, ignorando cosi nella fase di debug la compilazione in JavaScript; in tal modo è possibile utilizzare un debugger Java standard per il codice Ajax, invece di affidarsi esclusivamente ai JavaScript compilati per i test e le interazioni.

Il server Tomcat Lite facilita lo sviluppo locale e la sperimentazione di server con database.

Dalla versione 2.0, il browser Hosted Mode viene rimpiazzato dal Development Mode che, rispetto alle versioni precedenti, consente di poter effettuare il debugging dell’applicazione web direttamente in un browser vero e proprio, invece di utilizzare il browser dell'SDK. Altra particolarità del development mode è quella di poter scrivere il codice in un sistema operativo e testarlo su un altro[w7].

Librerie Grafiche per il Web: i Widget

Il punto di forza dell’intelligente sistema di compilazione di GWT è un livello UI cross-browser. Le classi di interfaccia grafica sono molto simili ai framework UI già esistenti, come Swing e SWT, con la differenza che i widget sono creati usando pagine HTML dinamiche, anziché grafici pixel-oriented.

Strumenti utilizzati

75

Nella tradizionale programmazione JavaScript, la creazione di un’interfaccia utente dinamica è fatta attraverso la manipolazione DOM del browser; GWT invece fornisce l’accesso al DOM del browser direttamente utilizzando il package DOM, facilitando l’uso delle classi della gerarchia dei Widget. Le classi dei Widget, al contempo, rendono più semplice e veloce la creazione di interfacce per ogni tipo di browser.

L’elenco dei widget disponibili è lungo e potenzialmente infinito, considerando il fatto che, grazie all’apertura del codice, utenti e comunità ne rilasciano di nuovi ogni giorno. Possiamo trovare calendari, tabelle ordinabili, calcolatrici, pannelli per disegnare e molto altro ancora, senza considerare i più classici oggetti contenuti nelle form. Inoltre sono disponibili anche una serie di widget costruiti su già esistenti librerie JavaScript, come Google Maps API, Google Search API e effetti Scriptacolous.

Figura 47: esempio di gerarchia dei Widget

Essendo classi Java, ovviamente, i Widget possono essere estesi per crearne di nuovi e possono gestire gli eventi generati da mouse e/o tastiera per interagire con l’utente.

Oltre ai classici Widget HTML-based, ne troviamo anche disponibili per la grafica vettoriale scalare (SVG), una tecnologia in grado di visualizzare oggetti di grafica vettoriale e, pertanto, di gestire immagini scalabili dimensionalmente[1][5].

Dalla versione 2.0 di GWT, inoltre, è stata introdotta la possibilità di descrivere la struttura della GUI tramite XML (simile a XUL di Netscape presentato circa 12 anni fa): è possibile infatti descrivere la struttura della interfaccia grafica tramite XML senza dover codificare nemmeno una riga di codice Java (e per quanto riguarda la definizione della GUI è codice sempre piuttosto fastidioso)[w7].

Comunicare con il server

Come già accennato in precedenza, una fondamentale differenza tra le applicazioni AJAX e le più tradizionali applicazioni web HTML è che con le applicazioni AJAX non è necessario scaricare nuove ed intere pagine HTML quando vengono eseguite; questo perché le pagine AJAX funzionano come vere e proprie applicazioni all’interno del browser, evitando così di richiedere nuovo HTML dal server per aggiornare l’interfaccia all’utente. Tuttavia, come

Appendici

76

tutte le applicazioni client/server, le applicazioni AJAX devono in ogni caso recuperare alcuni dati dal server per eseguire delle operazioni: per interagire con il server attraverso la rete, si effettua perciò una chiamata di procedura remota (Remote Procedure Call). GWT RPC facilita proprio il passaggio di oggetti Java tra client e server (e viceversa) attraverso HTTP. Se usato correttamente, RPC da la possibilità di spostare tutta la logica UI sul client, con un conseguente notevole miglioramento delle prestazioni (si riduce la larghezza di banda e il carico sul web server) ed esperienze piacevolmente fluide per l’utente.

Utilizzando GWT RPC, tutte le chiamate effettuate dalla pagina HTML al server sono asincrone. Questo significa che le chiamate non bloccano il client mentre aspettano una risposta dal server, ma viene eseguito il codice immediatamente successivo.

I vantaggi di effettuare chiamate asincrone rispetto alle più semplici (per gli sviluppatori) chiamate sincrone, si riscontrano in una migliore esperienza per gli utenti finali: innanzitutto, l’interfaccia utente è più reattiva; infatti, a causa del fatto che nei browser web il motore JavaScript è generalmente di tipo single-thread, una chiamata sincrona al server genera un “blocco” fino alla conclusione della stessa, rovinando cosi l’esperienza dell’utente finale. Altro vantaggio delle chiamate asincrone è che risulta possibile eseguire altri lavori in attesa della risposta da parte del server; per esempio, è possibile costruire l’interfaccia utente e contemporaneamente recuperare i dati dal server per popolarla, riducendo cosi il tempo complessivo necessario all’utente per visualizzare i dati sulla pagina. Ultimo vantaggio, ma non meno importante, è che è possibile effettuare chiamate multiple al server nello stesso tempo; tuttavia questo parallelismo risulta fortemente limitato dall’estremamente piccolo numero di connessioni che in genere i browser web concedono alle singole applicazioni[w1].

Figura 48: implementazione di una RPC

Anatomia di un’applicazione GWT

Per sviluppare un’applicazione web con GWT è importante tenere conto della divisione in cartelle che Google ha pensato per il suo prodotto. Infatti non si possono suddividere i propri

Strumenti utilizzati

77

file in una gerarchia MVC tradizionale, ma bisogna tenere conto di alcuni aspetti fondamentali.

Innanzitutto troviamo il descrittore del modulo, in formato XML, che GWT utilizza per individuare la configurazione dell’applicazione; al suo interno occorre prestare molta attenzione a due tipi di voci: i moduli ereditati (inherited modules), paragonabili alle importazioni nelle normali classi Java, e il nome della classe principale a cui l’applicazione deve accedere all’inizio dell’esecuzione (Entry Point Class).

Nell’esempio a fianco, il file si trova nella cartella principale “src/helloworld”, con il nome “<nome-progetto>.gwt.xml”.

Sempre nella cartella principale si trovano 2 sottocartelle chiamate “client” e “server”. All’interno di “client” occorre inserire il codice Java client-side, come il pattern “model” e il pattern “view” relativa al modello MVC, e verrà tradotto da GWT in JavaScript durante la compilazione. Purtroppo le classi importabili ed utilizzabili all’interno di questa cartella sono in numero piuttosto ristretto, limitando lo sviluppo ed aumentando gli sforzi dei programmatori. Fortunatamente, di release in release, questo numero aumenta, fornendo nuovi strumenti di lavoro.

Nella cartella “server”, invece, troviamo il codice Java server-side, ossia il backend della nostra applicazione. Al suo interno si possono inserire i servizi (le servlet per le chiamate RPC) e i DAO (classi che rappresentano un’entità tabellare di un database ed effettuano su di esso operazioni atomiche CRUD).

Notare inoltre come, nell’immagine sopra, per ogni servizio (o servlet) occorre creare un’interfaccia sincrona e una asincrona da inserire nella cartella “client”.

Come in tutte le applicazioni web, si trova anche la cartella “war”, cosiddetta pubblica, in quanto viene riportato tutto il codice (HTML e CSS) e gli oggetti (immagini e file) pubblici, oltre ad un file “web.xml” contenente, tra le altre cose, l’elenco e la configurazione delle servlet del progetto.

JSON Molti sviluppatori di applicazioni AJAX hanno adottato JSON come formato dei dati per la comunicazione con il server. Si tratta di un formato relativamente semplice basato sulla notazione letterale di oggetto in JavaScript.

Appendici

78

JSON (JavaScript Object Notation) è un semplice formato per lo scambio di dati. Per le persone è facile da leggere e scrivere, mentre per le macchine risulta facile da generare e analizzarne la sintassi. Si basa su un sottoinsieme del Linguaggio di Programmazione JavaScript, Standard ECMA-262 Terza Edizione - Dicembre 1999.

È un formato di testo completamente indipendente dal linguaggio di programmazione, ma utilizza convenzioni conosciute dai programmatori di linguaggi della famiglia del C, come C, C++, C#, Java, JavaScript, Perl, Python, e molti altri. Questa caratteristica fa di JSON un linguaggio ideale per lo scambio di dati.

JSON è basato su due strutture:

� Un insieme di coppie nome/valore. In diversi linguaggi, questo è realizzato come un oggetto, un record, uno struct, un dizionario, una tabella hash, un elenco di chiavi o un array associativo.

� Un elenco ordinato di valori. Nella maggior parte dei linguaggi questo si realizza con un array, un vettore, un elenco o una sequenza.

Queste sono strutture di dati universali. Virtualmente tutti i linguaggi di programmazione moderni li supportano in entrambe le forme. È sensato che un formato di dati che è interscambiabile tra linguaggi di programmazione debba essere basato su queste strutture.

Nel formato JSON, un oggetto è una serie non ordinata di nomi/valori. Inizia con { (parentesi graffa sinistra) e finisce con } (parentesi graffa destra). Ogni nome è seguito da : (due punti) e la coppia di nome/valore sono separata da , (virgola). I valori, se alfanumerici, sono interposti tra “ (virgolette).

Figura 49: definizione json di "oggetto"

Un array invece è una raccolta ordinata di valori. Comincia con [ (parentesi quadra sinistra) e finisce con ] (parentesi quadra destra). I valori sono separati da , (virgola).

Figura 50: definizione json di "vettore"

L’uso di JSON tramite JavaScript, è particolarmente semplice, infatti l'interprete è in grado di eseguirne il parsing tramite una semplice chiamata alla funzione eval(). Questo fatto lo ha reso velocemente molto popolare per merito della diffusione della programmazione in JavaScript nel mondo del Web.

Strumenti utilizzati

79

Differentemente da XML, che è un linguaggio di marcatura delle proprietà, JSON è un formato di interscambio dati. Entrambi però non hanno un sistema di rappresentazione dei dati binari, per cui è compito del programmatore adottare delle convenzioni appropriate per convertire i dati binari in forma testuale[w8][w9].

Utilizzare JSON in GWT Scegliendo di utilizzare il formato JSON nella nostra applicazione, GWT offre dei semplici strumenti per analizzare a manipolare i dati.

Il metodo “convenzionale” consiste nell’effettuare dal lato client un richiesta XMLHTTPRequest al lato server e ricevere un flusso di dati in formato JSON, ad esempio:

[

{

"symbol": "ABC",

"price": 47.65563005127077,

"change": -0.4426563818062567

},

]

Una volta ricevuta la risposta, dal lato client occorre utilizzare la funzione eval() di JavaScript e convertire cosi la stringa JSON in un oggetto JavaScript:

private final native JsArray<StockData> asArrayOfStockData(String

json) /*-{

return eval(json);

}-*/;

A questo punto, bisogna scrivere un metodo per utilizzare gli oggetti JavaScript, in questo modo:

// JSNI methods to get stock data.

public final native String getSymbol() /*-{ return this.symbol; }-

*/;

public final native double getPrice() /*-{ return this.price; }-

*/;

public final native double getChange() /*-{ return this.change; }-

*/;

In entrambi i casi, si utilizzano i JSNI (JavaScript Native Interface), cioè porzioni di codice JavaScript poste all’interno del codice Java.

Quando il codice client-side verrà compilato in JavaScript, i metodi Java verranno tradotti con codice JavaScript del tutto simile a quello riportato sopra[w10].

Cloud Computing Il Cloud Computing è in sostanza l’evoluzione di varie tecnologie che, usate in sincronia, hanno

modificato l’approccio nel costruire l’infrastruttura IT dei servizi offerti su Internet[9].

Appendici

80

Il termine Cloud Computing si riferisce sia alle applicazioni distribuite come servizi (SaaS) su Internet, sia ai sistemi hardware e software nei datacenter che offrono questi servizi. I sistemi hardware e software nei datacenter sono chiamati semplicemente Cloud; se sono resi disponibili al pubblico attraverso una politica “pay per use” sono chiamati Public Cloud, e il servizio venduto Utility Computing. Se un’azienda possiede un’infrastruttura propria e non la rende disponibile all’esterno si parla invece di Private Cloud. Sono possibili anche soluzioni ibride[8].

Componenti chiave

SaaS

Software as a Service (SaaS) è un modello di pubblicazione del software su Internet che rende l’applicazione interamente fruibile via web.

I vantaggi per l’utente sono:

� non dover installare l’applicazione e potervi accedere da più computer, anche in luoghi diversi, senza dover trasportare i dati da un computer all’altro (accesso al servizio“anytime, anywhere”),

� condividere i dati con facilità e poter collaborare con altri utenti su quei dati, � archiviare i dati in un luogo sicuro all’interno dell’infrastruttura, � ridurre al limite costi di hardware iniziali o di mantenimento. � Il fornitore, d’altra parte, ha il vantaggio di poter avere manutenzione e

controllo di versione centralizzati.

Datacenter e Virtualizzazione Hardware

L’impiego della virtualizzazione è nato dalla necessità sfruttare le risorse dei Datacenter in maniera più efficace e frammentata. La stima di utilizzo delle risorse di un datacenter tradizionale, infatti, si aggira intorno al 5-20% della capacità totale disponibile. Può sembrare poco, ma è ragionevole considerando che per molti servizi il picco di richieste supera di 2-10 volte il livello di richieste medio; per far fronte al picco vengono quindi allocate molte risorse che rimangono poi inutilizzate per la maggior parte del tempo.

Attraverso la virtualizzazione dell’hardware l’amministratore dell’infrastruttura IT può partizionare un server fisico in un gran numero di server virtuali, ognuno con il suo sistema operativo, la sua allocazione di memoria, CPU, e porzione di disco. In questo modo può “affittare” le risorse inutilizzate ad altri clienti.

Infrastrutture software scalabili

Le compagnie che offrono sistemi di Cloud hanno sviluppato degli algoritmi e delle strutture software per scalare rapidamente le quantità di traffico e dati archiviati secondo la richiesta dei clienti. Google, ad esempio, utilizza il MapReduce, il Google File System (GFS) e BigTable.

Il MapReduce è un modello di programmazione e un’implementazione associata per processare e generare grandi insiemi di dati. Vengono mappate risorse e processi per poterli eseguire in parallelo in cluster di grandi dimensioni. Il sistema run-time si prende cura dei dettagli di partizionamento dei dati in input, dello smistamento dei processi su una serie di macchine, della gestione dei guasti e della gestione della comunicazione interna tra i calcolatori, consentendo ai programmatori, anche senza alcuna esperienza in ambito di

Strumenti utilizzati

81

sistemi paralleli e distribuiti, di utilizzare facilmente le risorse in ambito Cloud. Un tipico calcolo con MapReduce riesce a processare molti terabyte di dati in migliaia di macchine in tempi veramente brevi.

Per utilizzare AppEngine è perciò necessario tenere a mente che non si può usare un tipico database relazionale, in quanto il Cloud è ridondante. Un modo per ovviare a questo problema in ambito Java consiste nell’utilizzare la tecnologia JDO.

Vantaggi e svantaggi

Vantaggi

Possibilità di allocare una grande quantità di risorse on demand: con il Cloud Computing le aziende hanno accesso a una quantità di risorse che, fino a poco tempo fa, era a disposizione di pochi leader nel settore.

Nessun investimento di capitale iniziale: i costi iniziali per allestire un’infrastruttura IT vengono azzerati. Questo è utile soprattutto per le aziende in fase di start-up e per la creazione di nuovi progetti, in quanto il capitale iniziale può essere investito nel servizio anziché nell’infrastruttura.

Elasticità: nel modello tradizionale di infrastruttura IT bisogna stimare la domanda e allocare abbastanza risorse per soddisfarla, anche nei momenti di picco delle richieste. In questo modo però, quando la domanda non è nel picco, le risorse rimangono inutilizzate. Il modello di business “pay per use” utilizzato nel Cloud Computing, invece, permette alle aziende di affrontare meglio i rischi dovuti al costo del sistema informativo.

Figura 51: stima delle risorse richieste e inutilizzate

Stima della domanda iniziale: spesso è difficile stimare la domanda, soprattutto per un nuovo servizio; in questo modello, un errore di stima iniziale non si traduce in un potenziale investimento sbagliato sia per eccesso che per difetto.

Richiesta di esperti nell’infrastruttura: essendo l’infrastruttura IT esterna all’azienda non è necessario assumere personale esperto nel sistema.

Appendici

82

Svantaggi

Disponibilità del servizio: alcuni casi eclatanti di interruzione dei servizi di Cloud (ad esempio Gmail che l’8/11/08 è rimasto sospeso un’ora e mezza a causa della scadenza di contratti di sistema oppure AppEngine che è rimasto parzialmente inattivo per circa cinque ore a causa di un errore di programmazione) hanno sollevato preoccupazioni sull’affidabilità di tali sistemi. Tuttavia le infrastrutture Cloud possono considerarsi sicure per la maggior parte delle applicazioni.

Portabilità dei dati (e barriere all’uscita): una problematica ancora aperta è la portabilità dei dati fra le diverse infrastrutture Cloud. Attualmente non esiste infatti uno “standard” tre i vari sistemi e le API sono tutte proprietarie. Questo potrebbe essere una limitazione per la diffusione del Cloud in quanto le aziende e gli utenti sono vulnerabili ad aumenti di prezzo del servizio, problemi di disponibilità del servizio e fallimenti del provider.

Sicurezza e privacy dei dati: due questioni centrali per l’adozione di un’infrastruttura Cloud da parte delle aziende sono la sicurezza e la privacy dei dati. Il fatto che i dati dell’azienda siano “da qualche parte nel Cloud” è una barriera psicologica all’adozione di tale infrastruttura. Queste problematiche possono però essere facilmente risolte con l’adozione di tecnologie collaudate come l’encrypted storage, le VLAN e i network middleboxes.

Efficienza nel trasporto dei dati: le applicazioni tendono a diventare sempre più data-intensive; nel Cloud Computing tutti questi dati devono essere trasportati sulla rete e questo può creare un collo di bottiglia e un costo elevato di trasporto.

Legislazione e politica: essendo geograficamente distribuita, l’infrastruttura di Cloud Computing e i dati in essa contenuta sono soggetti a diverse legislazioni a seconda del luogo in cui si trovano. Questo potrebbe creare problematiche di carattere politico e legale.

Approcci dei principali competitor

Ogni applicazione ha bisogno di un modello di computazione, un modello di storage dei dati e un modello di comunicazione. I principali provider di servizi di Cloud si differenziano per livello di astrazione presentato agli sviluppatori e per livello di gestione delle risorse.

Figura 52: competitor a confronto

Amazon EC2

A un estremo dello spettro c’è la proposta di Amazon: EC2. Un’istanza di EC2 permette infatti allo sviluppatore di controllare quasi tutto, dal kernel, al software stack e alla connettività IP. Il programmatore è libero di sviluppare qualsiasi applicazione. Questo rende difficile per Amazon controllare la scalabilità e il failover perché la replicazione è strettamente legata all’applicazione stessa.

Strumenti utilizzati

83

Microsoft Azure

La proposta Cloud di Microsoft si posiziona a metà dello spettro tra flessibilità e libertà per il programmatore. Le applicazioni Azure sono scritte usando le librerie .NET e compilate in Common Language Runtime. Il sistema supporta applicazioni di carattere generale anziché di un tipo specifico. L’utente può scegliere il linguaggio di programmazione ma non il sistema operativo sottostante.

Google AppEngine

All’altro estremo dello spettro c’è AppEngine di Google che offre una piattaforma per creare applicazioni in uno specifico dominio, quello delle applicazioni web tradizionali. Questa limitazione permette a Google di offrire una grande scalabilità e disponibilità di servizio in automatico.

Il Cloud Computing di Google: Google App Engine (GAE) Google AppEngine può essere visto come il modo di creare applicazioni Web per essere

ospitate sui web server di Google. GAE è infatti un framework di tecnologie con le quali creare applicazioni senza preoccuparsi dell’infrastruttura sulle quali vengono

ospitate[w11][w12].

L’infrastruttura è costituita da centinaia di server sparsi per il mondo che si distribuiscono le copie dell’applicazione in modo che qualunque server possa essere in grado di rispondere ad una richiesta, o perché è poco carico in quel momento o perché si trova geograficamente vicino all’utente.

I cardini di Google AppEngine sono BigTable e Google File System (GFP). Il primo è un database scalabile, lo stesso che supporta applicazioni come Google Maps o Google Search. È distribuito su molti server ed è in grado di servire gigabytes di dati ogni secondo. BigTable non è però un database relazionale, tuttavia AppEngine fornisce un interfaccia per gli sviluppatori (chiamata DataStore) con un approccio molto simile a quello di una struttura a tabelle. Il secondo è un file system distribuito altamente scalabile per applicazioni che manipolano grandi quantità di dati distribuiti.

Lo sviluppatore può controllare i parametri dell’applicazione attraverso il pannello di controllo di GAE: numero di richieste, banda in entrata e in uscita, tempo di CPU, richieste e traffico HTTPS, numero di query e spazio usato dal database, CPU usata dal database, numero di email e allegati inviati, numero e banda usata nel recuperare indirizzi (URL Fetch), numero di accessi e traffico prodotto verso Memcache, conteggio e traffico generato per manipolare immagini e il numero di deploy per

l'applicazione.

Appendici

84

Java Data Object (JDO) Java Data Object (JDO) è un’interfaccia basata sulla definizione di persistenza degli

oggetti per il linguaggio Java, che descrive l’archiviazione, l’interrogazione e il recupero di

oggetti dalle basi di dati.

JDO è estremamente trasparente nella mappatura degli oggetti tra codice applicativo e database, permettendo quindi di archiviare direttamente gli oggetti model di Java sulla propria base di dati. Fornisce inoltre la possibilità di includere direttamente file di I/O, serializzazioni, JDBC, Enterprise JavaBeans (EJB), Bean-Managed Persistence (BMP) o Container-Managed Persistence (CMP) entity beans e Java Persistence API.

I vantaggi derivanti dall’utilizzo di JDO sono numerosi: innanzitutto abbiamo una notevole portabilità, cioè le applicazioni scritte con le API di JDO possono essere eseguite su implementazioni multiple senza dover essere ricompilate o dover sostituire parte del codice sorgente. Anche i Metadati, che descrivono il comportamento della persistenza all’esterno del codice sorgente Java includendo le funzioni di mappaggio O/R più comunemente utilizzate, sono altamente portabili. Un altro aspetto fondamentale è la totale indipendenza dal Database: le applicazioni scritte con le API di JDO sono indipendenti dal database sottostante. Le implementazioni di JDO supportano una gran varietà di datastore transazionali, tra cui i database relazioni, i database di oggetti, i file system e i documenti XML.

Inoltre, i dettagli della persistenza vengono delegati all’implementazione del JDO, abbiamo un’ottimizzazione dei modelli dei dati in accesso, con un conseguente miglioramento delle prestazioni e una maggiore facilità d’uso: infatti i programmatori possono concentrarsi sul loro dominio di oggetti model senza più doversi preoccupare dei dettagli della persistenza.

Ultimo, ma non ultimo, è importante l’integrazione con EJB: le applicazioni possono trarre vantaggio dalle funzionalità di EJB come la gestione remota dei messaggi, la coordinazione automatica e distribuita delle transazioni e la sicurezza, utilizzando lo stesso dominio di oggetti model in tutto l’ambiente di sviluppo[7].

Le specifiche JDO definiscono una serie di interfacce che sovraintendono all'accesso delle funzionalità. Queste sono:

� PersistenceManagerFactory: restituisce oggetti di tipo PersistenceManager, ed è il punto di ingresso per il quale i provider di servizi JDO devono offrire implementazione;

� PersistenceManager: interfaccia implementata dai gestori del ciclo di vita degli oggetti persistenti, che permette di creare e rimuovere oggetti, effettuare la manipolazione di opzioni relative alle transazioni, cambiare le opzioni del pooling di oggetti ed accedere alle query;

Strumenti utilizzati

85

� PersistenceCapable: interfaccia di marcatura che tutti gli oggetti che devono essere resi persistenti devono implementare;

� Transaction: per ciascun PersistenceManager esiste un oggetto Transaction che gestisce il contesto transazionale entro il quale si sta eseguendo l'operazione di persistenza di un oggetto. In ambienti J2EE questa interfaccia permette di accedere alle opzioni transazionali, mentre è il container a gestire la transazione. In ambienti non J2EE l'interfaccia rappresenta un vero e proprio servizio transazionale, che deve essere invece implementato dal fornitore del servizio JDO;

� Query: consente di specificare query di selezione sulla base dati degli oggetti persistiti. JDO fornisce supporto per un ottimo linguaggio object-oriented per le query chiamato JDOQL.

Le specifiche JDO inoltre definiscono 10 stati in cui l'oggetto coinvolto in JDO può passare (sette obbligatori e tre opzionali), in funzione delle diverse chiamate ed operazioni che è possibile eseguire. Questi sono:

� Transient: un oggetto è transiente quando non è considerato a livello JDO; esso diventa persistente (Persistent-new) nel momento in cui viene reso persistente dalla chiamata PersistenceManager.makePersistent() oppure nel caso in cui venga referenziato da un campo persistente di un oggetto persistente, quando quest'ultimo viene committato o reso persistente.

� Persistent: (-new) l'istanza è stata appena resa persistente e gli viene associata una identità; (-dirty) una istanza persistente, ancora non committata, di cui sono stati cambiati i valori degli attributi; (-clean) un oggetto persistente, le cui copie in memoria e sulla base dati sono perfettamente allineate; (-deleted): un oggetto che rappresenta una specifica istanza persistente e che è stato cancellato nella transazione corrente; (-new-deleted) un oggetto appena creato e cancellato dalla transazione corrente; (-nontransactional) un oggetto che rappresenta una specifica istanza persistente i cui valori sono caricati ma non consistenti con lo stato della transazione.

� Hollow: una istanza di un oggetto persistito con JDO, ma i suoi attributi non sono ancora stati caricati dalla base dati.

� Transient: (-clean) oggetto transiente inserito in un contesto transazionale i quali valori non sono stati cambiati; (-dirty) oggetto transiente inserito in un contesto transazionale i quali valori sono stati cambiati.

Figura 53: esempio di stati in cui si può trovare un oggetto

La presenza di diversi stati permette di capire qual è la condizione effettiva di un oggetto in merito alla persistenza[w13][w15].

Appendici

86

JDOQL Per il recupero di oggetti che soddisfano una serie di criteri, JDO fornisce un linguaggio di query, chiamato JDOQL, che agisce direttamente su classi e attributi dei dati JDO e include il controllo dei tipi dei parametri e dei risultati delle query. JDOQL è simile a SQL, ma è più appropriato in un ambito object-oriented, come appunto il datastore di AppEngine (che non supporta le query SQL con interfaccia JDO).

JDOQL fornisce un potente meccanismo di query espresso in termini di modello di dominio persistente ed è perciò indipendente dalla struttura del database sottostante. Il linguaggio è stato appositamente progettato per essere tradotto efficientemente in SQL tramite un'implementazione JDO.

In sostanza ogni query JDOQL ha un insieme di Candidates e, una clausola Filter, potrebbe prevedere altre clausole che governano l'ordinamento dei risultati e la definizione dei parametri.

I Candidates sono solitamente l'insieme di tutte le istanze persistenti di una classe stabilita (sottoclassi comprese).

Il Filter è un'espressione booleana scritta secondo la grammatica di JDOQL, una notazione molto simile a quella di Java. Se l'espressione booleana del filtro per quell'istanza dà come risultato “true”, ogni singola istanza candidata è inclusa nella Collection restituita tramite l'esecuzione della query.

Le query sono generate tramite i metodi newQuery() sull'interfaccia PersistenceManager. La query è di fatto un'istanza dell'interfaccia Query, che fornisce i metodi per l'impostazione delle varie clausole della query e per l'esecuzione della query con i valori dei parametri specificati[w16][w17].

Usare il datastore AppEngine con JDO AppEngine include per il suo datastore il supporto di due diverse API standard: Java Data

Object (JDO) e Java Persistence API (JPA). Queste interfacce sono fornite da DataNucleus Access Platform, un’implementazione open source di diversi standard Java di persistenza, con un adattatore per il datastore AppEngine.

Per poter utilizzare JDO in AppEngine, occorre modificare gli oggetti model del progetto, aggiungendo le Annotation alle classi e relativi attributi:

� @PersistenceCapable prima della dichiarazione della classe; � @PrimaryKey e @Persistent(valueStrategy =

IdGeneratorStrategy.IDENTITY) prima della dichiarazione dell’attributo di

chiave primaria; � @Persistent prima della dichiarazione di un attributo.

Una piccola nota negativa è che purtroppo non si possono utilizzare le seguenti funzionalità dei JDO in AppEngine a causa di alcune incompatibilità:

� relazioni non proprie utilizzando valori Key; � relazioni molti-a-molti; � query “join”, in quanto non si possono utilizzare attributi di entità figlie nei

filtri quando si esegue una query;

Strumenti utilizzati

87

� JDOQL “group by” o altre query di aggregazione; � query polimorfe, in quanto non è possibile eseguire una query su una classe

per ottenere instante di una sottoclasse; � IdentityType.DATASTORE per la annotation @PersistenceCapable. È

supportata solo IdentityType.APPLICATION;

Attualmente ci sono anche altri bug di minore rilevanza e DataNucleus informa sul proprio sito web di una incompatibilità con Google Web Toolkit, cioè un problema sulla serializzazione di array di oggetti serializzabili[w14][w15].

89

Ringraziamenti Durante questi anni, la presenza e il supporto di molte persone che hanno condiviso con me non solo i momenti più belli, ma anche quelli più difficili, è stato per me di grande importanza ed è per questo che desidero ringraziare tutti coloro che, anche solo con una parola di incoraggiamento, mi sono stati vicini in questo mio percorso.

Desidero ringraziare Antonio Di Leva, relatore di questa tesi, per la grande disponibilità e cortesia dimostratemi nonché per il tempo dedicatomi e per le conoscenze fornitemi durante il suo corso.

Un ringraziamento particolare a Massimiliano Garruzzo e Pasquale Pellitteri per le conoscenze didattiche e professionali che mi hanno trasmesso e per il tempo prezioso che mi hanno dedicato durante tutto il periodo dello stage.

Un sentito ringraziamento ai miei genitori, che, con il loro incrollabile sostegno morale ed economico, mi hanno permesso di raggiungere questo traguardo.

Infine ringrazio tutti, ma proprio tutti, i miei amici e compagni di università che hanno saputo allietare e rendere spensierate le mie giornate anche solo con una battuta o con un sorriso, che hanno passato con me interi pomeriggi per preparare un esame, che mi hanno aiutato nei lavori di gruppo e hanno condiviso con me ansie e paure prima di un esame.