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
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 L’insegnante inserisce il voto una volta sola
studente lo scrive sul registro personale, sul nel sistema informativo.
diario dello studente e sulla pagella a fine
semestre.

Quando lo studente riceve un voto lo scrive Il voto viene registrato una sola volta nel
sul diario ma non ha una visione generale sistema e lo studente può visualizzare tutti i
dell’andamento scolastico. voti divisi per materia con le medie e una

5

Quando l’insegnante assegna un voto lo
scrive sul registro personale, a fine
semestre calcola la media dei voti per ogni
studente.
Il genitore segue l’andamento scolastico del
figlio attraverso le votazioni sul diario.
Comunicazioni scuola-genitori
TRADIZIONALE
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.
Quando un genitore vuole contattare un
insegnante, il rappresentante dei genitori o
d’istituto lo fa attraverso l’alunno o la
segreteria.
Promemoria
TRADIZIONALE
Studenti e professori gestiscono con
registri, diari e documenti cartacei le
interrogazioni e le verifiche programmate.
Quando l’insegnante assegna un progetto
gestisce con appunti personali le specifiche
e le consegne.
Quando un alunno fa un’assenza gli
insegnanti devono ricordarsi delle
giustificazioni da portare.
Quando l’alunno torna da un’assenza
chiede il programma che è stato svolto in
sua assenza.
Statistiche
TRADIZIONALE
Il sistema cartaceo rende difficile calcolare
delle statistiche sui dati.
6
Capitolo 1
serie di grafici.
L’insegnante ha a disposizione delle tabelle
e dei grafici con l’andamento scolastico dei
suoi alunni e la relativa media.
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.
INFORMATIZZATA
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).
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.
INFORMATIZZATA
Il sistema crea dei promemoria per
verifiche e interrogazioni programmate, sia
per gli alunni che per i professori.
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.
Il sistema avvisa i professori delle assenze
da giustificare.
Lo studente può visualizzare giorno per
giorno gli argomenti svolti per ogni
materia.
INFORMATIZZATA
Il sistema mette a disposizione il pannello
delle statistiche in cui è possibile creare dei
report su voti, assenze e altri dati
disponibili.
Introduzione

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

7
 Capitolo 1

Figura 2: registro di classe

8
Introduzione

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à.

9
 Capitolo 1

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

10
Introduzione

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

11
 Capitolo 1

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.

12
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.

13
 Capitolo 2

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:

14
Analisi funzionale

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).

15
 Capitolo 2

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:

16
Analisi funzionale

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

17
 Capitolo 2

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.

18
Analisi funzionale

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;

19
 Capitolo 2

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.

20
Analisi funzionale

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:

21
 Capitolo 2

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

22
Analisi funzionale

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.

23
 Capitolo 2

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;

24
Analisi funzionale

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.

25
 Capitolo 2

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:

26
Analisi funzionale

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.

27
 Capitolo 2

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

28
Analisi funzionale

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:

29
 Capitolo 2

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”).

30
Analisi funzionale

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

31
 Capitolo 2

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.

32
Analisi funzionale

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.

33
 Capitolo 2

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.

34
Analisi funzionale

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

35
 Capitolo 2

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.

36
Analisi funzionale

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

37
 Capitolo 2

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.

38
Analisi funzionale

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:

39
 Capitolo 2

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

40
Analisi funzionale

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.

41
 Capitolo 2

Figura 24: registro giornaliero del professore

42
Analisi funzionale

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

43
 Capitolo 2

Figura 26: registro settimanale

44
Analisi funzionale

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

45
 Capitolo 2

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.

46
Analisi funzionale

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.

47
 Capitolo 2

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.

48
Analisi funzionale

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:

49
 Capitolo 2

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.

50
Analisi funzionale

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

51
 Capitolo 2

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.

52
Analisi funzionale

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

53
 Capitolo 2

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:

54
Analisi funzionale

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

55
 Capitolo 2

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

56
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

57
 Capitolo 3

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].

58
Conclusioni e sviluppi futuri

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

59
 Capitolo 3

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

60
Conclusioni e sviluppi futuri

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)

61
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

63
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)

65
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

67
 Indice delle figure

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

68
Indice
GWT, 11, 19, 57, 58, 59, 60, 63, 65, 72,
Accessibilità, 57 73, 74, 75, 76, 77, 79
Admin, 20, 27, 28, 30, 31, 33
Ajax, 57, 63, 71, 73, 74 homepage, 14
AJAX, 65, 71, 72, 75, 77 hosted mode, 12
Ambiente di sviluppo, 11 Hosted Mode, 74
Andamento scolastico, 51
AppEngine, 60, 65, 81, 82, 83, 86 Insegnante, 20, 39, 40
applicazioni RIA, 71 Internazionalizzazione, 58
Appunti, 25
ARIA, 57 Java, 11
Java Data Object. Vedi JDO
Bacheca, 22 JavaScript Object Notation. See JSON
BigTable, 80 JDO, 17, 60, 63, 65, 81, 84, 85, 86
JDOQL, 86
Calendario, 21 JSON, 19, 60, 65, 73, 77, 78, 79
casi d’uso in comune, 14
chiamata asincrona, 71 Login, 20
ClassWall, 52
Cloud Computing, 1, 5, 61, 63, 79, 80, 81, MapReduce, 80
82, 83 materiale didattico, 48
Materie, 50
diagramma delle classi, 16, 17 Messaggi, 23

Eclipse, 11 orari di lezione, 22

Faq, 26 package, 19
fasi di progettazione, 10 Posta. Vedi Messaggi
funzionalità, 9 programma ministeriale, 47
funzionalità dell' insegnante, 40
Funzionalità generali, 20 Registro di classe, 41
Registro personale, 45
Genitore, 20, 22, 25, 53 Rich Internet Application. See
Gestione comprensorio, 32 applicazioni RIA
Gestione comunicazioni, 37
gestione degli admin, 27, 33 SaaS, 80
Gestione dei comprensori, 27 Screen readers, 57
gestione del corso, 39 Security Token, 59
gestione della scuola, 5 sicurezza, 59
gestione delle supplenze, 39 Software as a Service. Vedi SaaS
Gestione didattica, 35 Speed Tracer, 60
Gestione scuola, 34 Statistiche, 60
Gestione utenti, 34 Statistiche scuola, 33
Google Web Toolkit, 13, 19, 63, 72, 87 Struttura del progetto. Vedi Package
69
 Indice

struttura delle pagine, 10

Studente, 18, 20, 49, 50 utenti, 9
SuperAdmin, 20, 26
Supplenze, 48 Vantaggi (cloud computing), 81
Svantaggi (cloud computing), 82 Virtualizzazione, 80
sviluppi futuri, 57
SVN Widget, 23, 26, 31, 33, 51, 74, 75
Software di versionamento, 12

70
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].

71
 Appendici

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

72
Strumenti utilizzati

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:

La prima cosa che si nota è che non viene

Figura 45: esempio di compilazione
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].

73
 Appendici

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.

74
Strumenti utilizzati

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

75
 Appendici

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

76
Strumenti utilizzati

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.

77
 Appendici

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.

78
Strumenti utilizzati

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].

79
 Appendici

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

80
Strumenti utilizzati

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.

81
 Appendici

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.

82
Strumenti utilizzati

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.

83
 Appendici

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;

84
Strumenti utilizzati

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].

85
 Appendici

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;

86
Strumenti utilizzati

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].

87
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.

89