UN SISTEMA PER LA PUBBLICAZIONE AUTOMATICA VIA...

UNIVERSITÁ DEGLI STUDI DI TRENTO

Facoltá di Scienze Matematiche, Fisiche e Naturali

Corso di Laurea (triennale) in Informatica

Elaborato finale

UN SISTEMA PER LA PUBBLICAZIONE AUTOMATICA

VIA WEB DI VIDEOLEZIONI

Relatore:

Prof. Marco Ronchetti

Laureando:

Mattia Colombari

Anno Accademico 2008-2009

Indice

1 Introduzione 3

1.1 Premessa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Il progetto LODE . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Un’applicazione Web per LODE . . . . . . . . . . . . . . . . . . . 7

2 Architettura 11

2.1 Java e la grafica Swing . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 I comandi esterni . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.1 Il processo di compressione in LODE Web . . . . . . . . . 16

2.3 VLC (VideoLAN Client) . . . . . . . . . . . . . . . . . . . . . . . 17

2.4 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.4.1 Serializzazione e deserializzazione XML . . . . . . . . . . 22

2.5 Applicazione Web . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.5.1 Le web-application . . . . . . . . . . . . . . . . . . . . . . 26

2.5.2 Il server web Tomcat . . . . . . . . . . . . . . . . . . . . . 29

2.5.3 Java 2 Enterprise Edition . . . . . . . . . . . . . . . . . . 30

2.5.4 JSP vs Servlet . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.5.5 Tag cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.5.6 Creazione dinamica di archivi . . . . . . . . . . . . . . . . 35

i

INDICE

3 Analisi dei requisiti 41

3.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.2 Requisiti funzionali . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.3 Requisiti non-funzionali . . . . . . . . . . . . . . . . . . . . . . . 44

3.4 Use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4 Progettazione dell’applicazione 49

4.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.2 Le classi dell’applicazione . . . . . . . . . . . . . . . . . . . . . . 50

4.3 Il funzionamento: processo di creazione . . . . . . . . . . . . . . 52

5 Manuale d’uso 59

5.1 Premessa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.1.1 Scopo del manuale . . . . . . . . . . . . . . . . . . . . . . 60

5.1.2 Struttura dell’applicazione . . . . . . . . . . . . . . . . . . 60

5.2 Installazione e configurazione . . . . . . . . . . . . . . . . . . . . 61

5.2.1 Requisiti per l’utilizzo . . . . . . . . . . . . . . . . . . . . 61

5.2.2 Compatibilitá sistema operativo . . . . . . . . . . . . . . 62

5.2.3 L’applicazione web: requisiti . . . . . . . . . . . . . . . . . 63

5.2.4 Configurazione web . . . . . . . . . . . . . . . . . . . . . . 63

5.3 Funzionalitá . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.3.1 Creazione dell’applicazione web . . . . . . . . . . . . . . . 64

5.3.2 Modifica dell’applicazione web . . . . . . . . . . . . . . . . 72

5.3.3 Uso dell’editor di Cascading Style Sheet . . . . . . . . . . 77

5.3.4 Uso dell’applicazione web . . . . . . . . . . . . . . . . . . 83

6 Conclusioni 89

Bibliografia 93

1

Capitolo 1

Introduzione

3

Introduzione

1.1 Premessa

Lo scopo della presente tesi di laurea è stato quello creare un’applicazione,

affiancata al progetto LODE, che renda possibile la creazione di un sito per la

pubblicazione via web delle videolezioni, offerte dai vari corsi universitari.

Questo lavoro si propone di fornire uno strumento utile per semplificare il

compito dell’operatore e gestore del corso e di rendere più fruibile l’accesso al

materiale multimediale delle lezioni.

1.2 Il progetto LODE

LODE (Lectures On DEmand) è nato come progetto di sviluppo di un siste-

ma per la digitalizzazione delle lezioni in ambito universitario, tramite la

videoregistrazione e l’acquisizione di materiale digitale.

Esiste un progetto, ePresence, sviluppato presso il Knowledge Media De-

sign Istitute (KMDI) dell’Università di Toronto dai professori Ron Baecker e

Gale More, che permette la divulgazione via rete di seminari e conferenze.

Sperimentando questo sistema, presso il Dipartimento di Informatica e

Telecomunicazioni, si sono evidenziati dei limiti nel suo utilizzo, per questo

motivo si è pensato di sviluppare una nuova architettura: LODE che grazie

alla sua interfaccia user-friendly e a un maggior livello di automazione, risul-

ta essere più accessibile e performante, sia riguardo i costi gestionali, sia per

semplificare il lavoro dell’operatore.

LODE permette a qualsiasi studente che abbia una connessione internet,

di seguire le lezioni stando comodamente seduto a casa. È stato pensato co-

me aiuto ai molti discenti che non hanno la possibilità di essere fisicamente

presenti alle lezioni o che hanno bisogno di uno strumento compensativo per

rivedere gli argomenti trattati durante le lezioni universitarie.

4

1.2 Il progetto LODE

Le varie lezioni possono essere navigate interattivamente grazie a una

serie di strumenti che permettono di usare al meglio le funzionalità offerte.

LODE prevede:

• L’acquisizione e la registrazione dei video delle lezioni.

• La conversione dei filmati registrati in un formato più idoneo alla distri-

buzione.

• La conversione in immagini delle presentazioni, per una facile visualiz-

zazione.

• L’accesso alle presentazioni in formato PowerPoint.

• La possibilità, da parte del docente, di aggiungere nuovo materiale alle

lezioni.

È possibile accedere a questo materiale da una semplice pagina HTML

visualizzabile tramite un browser che disponga di determinati plug-in.

Inizialmente, nella prima versione di LODE, la pagina web, per accedere

al materiale delle lezioni, utilizzava i linguaggi di programmazione javascript

e java, richiedendo una particolare configurazione del browser e l’installazio-

ne dei plug-in java e quicktime. Prevedeva inoltre una pagina introdutti-

va nella quale era possibile effettuare un test di compatibilità con il proprio

browser prima di utilizzare correttamente il servizio.

Questa prima versione, non compatibile con alcuni browser, è stata ab-

bandonata introducendo una nuova pagina dalla complessità ridotta. Ora,

infatti, la visualizzazione dei contenuti di una lezione è gestita da una sem-

plice pagina HTML con poche righe di codice e che fa riferimento a un oggetto

scritto in Flash. La struttura è quindi definita nel file flash, il quale si affi-

da ad altri file (XML) per estrapolare i dati necessari alla visualizzazione dei

contenuti.

5

Introduzione

Flash è un linguaggio di programmazione che permette di creare ani-

mazioni multimediali inserendo al loro interno video, immagini, audio ecc.

L’utilizzo di oggetti in formato Flash (estensione .swf), creati con l’omonimo

programma, rappresenta uno standard per la creazione di contenuti interat-

tivi. Quasi la totalità dei browser in circolazione supporta i plug-in per questo

formato. In questo modo vengono eliminati i problemi di compatibilità della

versione precedente.

Nella seguente immagine è mostrata l’interfaccia di LODE (Figura 1.1).

Figura 1.1: Interfaccia di LODE

Questa pagina web (index.html) offre all’utente:

• La possibilità di visualizzare il video della lezione.

• La possibilità di seguire un’eventuale presentazione di slides integrata

al video.

6

1.3 Un’applicazione Web per LODE

• L’accesso a informazioni sulla lezione e sul corso.

• Una facile navigazione mediante pulsanti e una time-line indicizzata.


Quello che il progetto LODE non ha ancora implementato è un sistema per

la pubblicazione automatica via web delle video-lezioni. Un sistema che crei

e gestisca un’applicazione web per la fruizione dei video e del materiale di

un corso. Fino ad ora le pagine per la visualizzazione delle lezioni vengono

integrate all’interno di applicazioni web, scritte e aggiornate manualmente

dal responsabile del corso. Il costo di queste operazioni risulta essere elevato

sia in termini di tempo che di spazio, infatti l’aggiunta di una nuova lezione,

come si può ben pensare, comporta l’intera modifica dell’applicazione web,

quindi:

• La modifica del codice della pagina web per la visualizzazione delle varie

lezioni.

• La copia della cartella di distribuzione della lezione (prodotta da LODE

contenente il materiale multimediale).

• La compressione, mediante opportuni formati (.zip, .rar), dei contenuti

della lezione, per far si che siano facilmente scaricabili dagli utenti del

sito.

Considerando inoltre che un’applicazione web ha bisogno di una continua

manutenzione del proprio contenuto, soprattutto con l’aggiunta di nuove le-

zioni, serviva un sistema che generasse in automatico un sito web, la cui

struttura fosse uguale per tutti i corsi, pur lasciando un margine di persona-

lizzazione al docente.

7

Introduzione

Il progetto da me realizzato prende in considerazione le criticità di LO-

DE e i bisogni di miglioramento del sistema. Il mio intento è stato quello di

sviluppare un’applicazione grafica che automatizzi e generi un sito web per

LODE. Questa applicazione, per la generazione e la pubblicazione via web

delle video-lezioni, prende il nome di LODE Web.

L’applicazione LODE Web, integrata con un corretto uso di LODE, fornisce

al docente di un corso un potente strumento di facile utilizzo che riduce note-

volmente i tempi di creazione e manutenzione del sito web. Inoltre fornisce al

fruitore del sito un facile accesso ai contenuti multimediali con la possibilità

di visualizzare tagCloud, note e informazioni.

La realizzazione di questa web application è stata possibile grazie all’e-

sistenza di uno standard sulla produzione dei contenuti multimediali, indif-

ferentemente dal tipo di corso e dalla tipologia delle lezioni videoregistrate.

L’applicazione LODE restituisce, dopo una serie di processi di elaborazione,

una directory di output così formata (Figura 1.2):

• Acquisition

• Distribution

• COURSE.XML

La directory Acquisition contiene le informazioni relative alle varie le-

zioni: il nome della lezione, il docente, la data di svolgimento, la durata del

video, le informazioni temporali per legare le slides al video e molte altre. Le

varie informazioni sono contenute in una serie di file XML all’interno della

directory.

La directory Distribution contiene la parte multimediale delle lezioni,

ossia i video e le slides.

8


Figura 1.2: Directory del corso

Il file COURSE.XML contiene diverse informazioni sul corso come: il no-

me, l’anno accademico di svolgimento del corso, i riferimenti alle cartelle delle

lezioni e la lista dei docenti titolari del corso.

LODE web acquisisce tutte queste informazioni e genera un’applicazione

distribuita web-based che può essere dinamica o un sito web statico HTML.

La scelta tra queste due tipologie di web-application è a discrezione dell’uten-

te che dovrà tener conto dei prerequisiti richiesti.

9

Introduzione

10

Capitolo 2

Architettura

11

Architettura

2.1 Java e la grafica Swing

L’applicazione LODE Web è stata realizzata tramite le librerie Swing (Java)

che permettono di creare applicazioni grafiche intuitive e di facile utilizzo.

Swing è un Framework per Java che include una Interfaccia grafica (GUI) e

dei widget: caselle di testo, pulsanti, pannelli e tabelle.

I widget Swing forniscono un’interfaccia grafica più sofisticata e funziona-

no allo stesso modo su tutte le piattaforme (su cui java gira), al contrario delle

AWT (Abstract Window Toolkit) le quali sono legate al sistema grafico nativo

del sistema operativo. In AWT, infatti, ogni componente grafico è controllato e

renderizzato da un nativo specifico del sistema operativo, per questo vengono

anche detti heavyweight components (“componenti pesanti”).

Figura 2.1: AWT vs Swing

La maggior parte delle API Swing sono un’estensione complementare di

AWT, quindi non vi è bisogno di allocare risorse native nel toolkit della GUI

12

2.1 Java e la grafica Swing

del sistema operativo, questi componenti grafici vengono spesso descritti come

lightweight components (“componenti leggeri”).

Le caratteristiche principali di Swing sono:

• Ricca dotazione di interfacce grafiche.

• Piattaforma più robusta e testata.

• Minore dipendenza dalla piattaforma di base.

• Risultato coerente su tutte le piattaforme con la possibilità di program-

mare l’aspetto grafico.

• Possibilità di utilizzare la gestione di eventi ereditati da AWT.

Swing permette di modificare l’ambientazione grafica offrendo un ambien-

te più familiare all’utente, cambiando il look-and-feel (o L&F) dei vari com-

ponenti widget. Questa modifica può essere fatta basandosi su un L&F esi-

stente o creandone uno da zero.

I L&F disponibili sono:

• Metal (Specifico di Swing).

• Windows (Disponbile su Windows).

• Mac (Disponibile su Mac).

• Motif (X).

Il vantaggio di questi componenti stà nell’uniformità di visualizzazione

tra svariate piattaforme e lo svantaggio è quello di una più lenta esecuzione.

Grazie alla sua portabilità e alla “leggerezza” (Swing non necessita di usa-

re i controlli nativi della GUI del sistema operativo per la rappresentazione)

13

Architettura

Swing è stato ampiamente utilizzato nell’applicazione LODE Web. Utiliz-

zando queste librerie ho potuto creare un’interfaccia grafica particolarmente

usabile (o user-friendly).

Con il termine usabilità si intente che un prodotto deve presentare le

seguenti caratteristiche:

• Adeguatezza : l’utente deve poter scegliere solamente gli input neces-

sari per svolgere un determinato compito.

• Facilità di apprendimento : l’utilizzo deve essere chiaro e intuitivo,

integrando il programma con manuali utenti o istruzioni d’uso (a loro

volta chiari e comprensibili).

• Robustezza : l’impatto dell’errore deve essere inversamente proporzio-

nale alla sua probabilità.

2.2 I comandi esterni

Per comando esterno si intente l’esecuzione di un’istanza di un program-

ma attraverso un processo del sistema operativo. Al processo vengono as-

segnate tutte le risorse del sistema operativo necessarie per l’esecuzione del

programma.

Nell’applicazione da me realizzata vengono utilizzati i comandi esterni

per: la creazione di file compressi (archivi) delle lezioni, la creazione delle

anteprime (preview) dei video e per copiare e eliminare file.

L’esecuzione di un comando di sistema, da un’applicazione Java, è relati-

vamente semplice. Esso implica l’uso di due classi Java: la classe Runtime e

la classe Process. Per poter eseguire un comando del sistema operativo viene

utilizzato il metodo exec della classe Runtime, il quale verrà eseguito come

un processo separato dal processo chiamante (padre). L’esecuzione di questo

14

2.2 I comandi esterni

Figura 2.2: Esecuzione di processi

metodo restituisce un oggetto Process che dispone di diverse funzionalità

per la gestione del sottoprocesso (figlio). Durante la sua esecuzione, attraver-

so l’oggetto Process, è possibile monitorare il processo leggendo i messaggi di

output e di errore utilizzando i metodi getInputStream e getErrorStream.

Per poter avviare un processo di sistema con questo metodo la prima cosa

da fare è specificare il comando che si vuole eseguire alla classe Runtime. Sic-

come non è possibile creare la propria istanza della classe Runtime, si utilizza

il metodo getRuntime per accedere al corrente ambiente di esecuzione (Run-

time Enviroment), per poi invocare la exec, come si può vedere nell’esempio

seguente.

15

Architettura

String comand = " . . . comando . . . " ;

Process p = Runtime . getRuntime ( ) . exec ( comand ) ;

Grazie alla classe System è possibile ottenere diverse proprietà del siste-

ma attraverso il metodo getPropriety. Una di queste è il sistema operativo

sul quale gira la nostra applicazione. Conoscendo il sistema operativo, in-

fatti, siamo in grado di utilizzare comandi esterni adeguati all’ambiente di

esecuzione.

Il codice per determinare il sistema operativo è il seguente:

String os = System . getProperty ( " os .name" ) ;

boolean WINDOWS = ( os . toLowerCase ( ) . indexOf ( "windows" ) >=0) ;

boolean MAC = ( os . toLowerCase ( ) . indexOf ( "mac" ) >=0) ;

boolean LINUX = ( os . toLowerCase ( ) . indexOf ( " l inux " ) >=0) ;

A seconda dell’ambiente dove viene eseguita, la nostra applicazione si

comporterà in maniera differente: verranno utilizzati processi esterni o sem-

plici istruzioni e metodi Java.

L’esecuzione di processi esterni presenta un vantaggio significativo: essen-

do processi eseguiti in parallelo al processo padre, siamo in grado di lanciarne

più di uno contemporaneamente in modo da velocizzare il tempo di esecuzio-

ne. Nel nostro caso specifico, utilizzando Linux, vengono lanciati tre processi

di creazione alla volta diminuendo notevolmente i tempi.

2.2.1 Il processo di compressione in LODE Web

Se l’utente lo richiede e se è stata scelta la creazione di un’applicazione web

statica, LODE Web può comprimere il materiale delle lezioni utilizzando uno

dei formati di compressione più diffusi: lo ZIP.

16

2.3 VLC (VideoLAN Client)

Lavorando sotto un sistema Gnu/Linux ho pensato di utilizzare il comando

Unix Zip per la compressione dei file. In questo modo è possibile inserire tutti

i file multimediali di una lezione all’interno di un unico archivio, da integra-

re facilmente nell’applicazione web per LODE. Se si utilizzano altri sistemi

operativi, ad esempio Windows, si fa riferimento a metodi e funzioni scritte

in java che hanno il compito di eseguire le stesse operazioni di compressione

dei processi unix.

L’utilizzo di comandi esterni di sistema mi ha fornito un’ottima soluzione

per poter creare questi archivi. Per la creazione di un file ZIP viene lanciato

uno script Unix parametrizzato, che ha il compito di comprimere la directory

della lezione e copiare l’archivio in un apposito spazio dell’applicazione web.

Per velocizzare il processo di creazione vengono eseguiti n processi in pa-

rallelo, ogni processo ha il compito di creare un archivio per una lezione, così

facendo vengono abbassati i tempi di creazione dell’applicazione web.


VLC media player (chiamato anche VideoLAN Client) è un media player li-

bero che supporta la maggior parte dei codec audio e video, svariati formati e

vari protocolli di streaming. Questo media player è disponibile su varie piat-

taforme, infatti esistono versioni per GNU/Linux, Microsoft Windows, Mac

OS X e molti altri. VLC è in grado di convertire files multimediali in diversi

formati e permette di utilizzare diversi comandi per la modifica e la gestione

di video.

L’applicazione LODE Web necessita che VLC sia installato sul proprio si-

stema operativo, questo perché viene utilizzato per la creazione di immagini

di preview per i video delle lezioni.

I formati dei video delle lezioni sono Flash Video (estensione .flv), forma-

17

Architettura

to utilizzato per inviare video su internet usando Adobe Flash Player1. Questi

video sono visibili sulla maggior parte dei sistemi operativi grazie ad un’am-

pia disponibilità di Adobe Flash Player e a programmi di terze parti come per

l’appunto VLC media player.

Tutte le operazioni che VLC offre sono messe a disposizione dalla sua in-

terfaccia grafica, tuttavia alcune operazioni complesse possono essere effet-

tuate solo da riga di comando. In queste situazioni non è richiesta la visua-

lizzazione dell’interfaccia del player. L’utilizzo di VLC da linea di comando ci

permette di creare le preview dei video delle lezioni.

VLC utilizza una struttura di tipo modulare gestita da un nucleo prin-

cipale che ha il compito di monitorare la comunicazione tra i vari moduli e

tutte le trasformazioni multimediali che essi gestiscono. È possibile avviare

un processo VLC specificando una serie di parametri che vanno a comporre

un nucleo di opzioni gestito da specifici moduli. Ogni modulo aggiunge nuove

opzioni utilizzabili dall’utente.

Per poter creare un’immagine di preview da un video viene utilizzato il

seguente comando con le seguenti opzioni:

• GNU/Linux comand:

vlc −−i n t f dummy −−no−audio −V image

−−start−time=? −−stop−time=?

−−image−out−rat i o =4 −−image−out−format=jpg

−−image−out−replace −−image−out−pre f ix=snap

video . f l v v lc : / / quit

• Microsoft Windows comand:

C : / Programmi / VideoLAN /VLC/ v lc . exe

−−i n t f dummy −−no−audio −V image

1 c©Adobe Flash Player : http://www.adobe.com/it/products/flashplayer/

18

http://www.adobe.com/it/products/flashplayer/


−−start−time ? −−stop−time ?

−−image−out−rat i o 4 −−image−out−format jpg

−−image−out−replace −−image−out−pre f ix snap

video . f l v v lc : / / quit

Al termine di ogni comando verranno create tante directory quanti sono

i video delle lezioni. Ogni directory avrà come nome il titolo della lezione e

conterrà quattro preview estratte da ogni video. Successivamente, per poterle

visualizzare nella nostra applicazione web, viene creato un file immagine GIF

partendo dalle quattro immagini e utilizzando classi e librerie Java.

Opzioni interfaccia (Interface modules)

Queste opzioni permettono di scegliere l’interfaccia o le interfacce VLC che

si desiderano utilizzare (sia interfacce grafiche che di controllo). Nel nostro

caso utilizziamo un’interfaccia di tipo dummy che viene adoperata quando

si vuole escludere la GUI dall’esecuzione eseguendo solamente il processo da

riga di comando.

L’uso corretto di questa opzione è il seguente:

% vlc −−i n t f dummy vcd : / / } \ \

Integrandola con l’opzione –no-audio, che elimina la componente audio,

si riesce ad avere un’esecuzione in background completamente trasparente

all’utente.

Opzioni per l’esecuzione

Tramite le opzioni –start-time e –stop-time è possibile specificare il tempo

di inizio e di fine esecuzione del video. Questo deve essere tale in modo che il

comando riesca ad estrarre almeno un fotogramma durante l’esecuzione, ma

19

Architettura

nello stesso tempo non deve essere eccessivo perché si andrebbe ad aumentare

notevolmente il tempo totale di creazione delle preview.

Per poter creare n immagini è necessario suddividere il video in n parti

temporali, per ogni parte viene lanciato il comando descritto in precedenza

con un tempo di esecuzione pari a due secondi. Così facendo verrà catturato

un fotogramma per ogni esecuzione del comando.

Opzioni per l’acquisizione

Queste opzioni vengono utilizzate per l’acquisizione delle immagini dal video.

Di seguito elencherò quelle che ho utilizzato e la loro descrizione:

• –image-out-ratio = ? : viene usata per specificare ogni quanti frame

catturare l’immagine dal video.

• –image-out-format = ? : viene utilizzata per specificare il formato

dell’immagine di output.

• –image-out-prefix = ? : permette di specificare il prefisso per il nome

dell’immagine, qualora l’esecuzione crei più immagini il prefisso verrà

affiancato da un progressivo.

• –image-out-replace : ogni immagine creata va a sovrascrivere quel-

la precedente, così facendo l’esecuzione di un comando crea una sola

immagine di preview.

L’istruzione vlc://quit viene utilizzata per terminare l’esecuzione del processo

VLC.

20

2.4 XML

2.4 XML

XML (eXtensible Markup Language) è un metalinguaggio di markup, ovvero

un linguaggio marcatore estendibile che permette di creare tag personalizzati

e di definire altri linguaggi di markup. È composto da un insieme di regole

sintattiche, dette specifiche, definite da W3C (Worl Wide Web Consortium),

che vengono utilizzate per modellare la struttura di documenti e dati.

Concretamente, un documento XML è un file testuale che contiene una

serie di attributi, tag e testo. La sua struttura logica è caratterizzata da

una gerarchia tra gli elementi che la compongono: ogni elemento rappresen-

ta un componente logico del documento XML e può contenere altri elementi

(sottoelementi) oppure delle informazioni testuali. Ogni elemento può ave-

re associate ulteriori informazioni che ne descrivono le proprietà, chiamate

attributi.

Figura 2.3: Document tree, struttura gerarchica XML

L’organizzazione degli elementi segue un ordine gerarchico che può es-

sere rappresentato in maniera “arborea”: un elemento principale, chiamato

root element, o semplicemente radice, contiene gli altri elementi del docu-

mento in modo da formare una struttura ad albero, generalmente nota come

21

Architettura

document tree (Figura 2.3).

<?xml version ="1.0" ?>

< a r t i c o l o t i t o l o =" Ti to lo del l ’ a r t i c o l o ">

<paragrafo t i t o l o =" Ti to lo del primo paragrafo ">

<testo >

Blocco di testo del primo paragrafo

</ testo >

<immagine f i l e ="immagine1 . jpg " > </immagine>

</ paragrafo >

<paragrafo t i t o l o =" Ti to lo del secondo paragrafo ">

<testo >

Blocco di testo del secondo paragrafo

</ testo >

<codice >

Esempio di codice

</ codice >

</ paragrafo >

</ ar t i co l o >

2.4.1 Serializzazione e deserializzazione XML

Per serializzazione si intende: la possibilità di salvare dati in un formato

tale da permettere in seguito di recuperarli con facilità. Si può parlare di

serializzazione di dati in un database, in file binari, in file di testo, in flussi di

memoria o anche in file XML.

La serializzazione XML, essendo più flessibile, è più adatta al trattamento

di dati in quantità tali da poter essere utilizzati da un’applicazione reale, an-

che se richiede un controllo più accurato sulle modalità di scrittura e lettura

delle informazioni contenute nei documenti. A differenza di altre tipologie,

22

2.4 XML

con la serializzazione XML è possibile definire: lo schema, lo spazio dei nomi,

i nome degli elementi e il tipo di rappresentazione dei dati.

La serializzazione XML converte (serializza) le proprietà, i campi pubblici

di un oggetto oppure i valori restituiti dai metodi, in un flusso XML e quindi

in un formato seriale più idoneo per l’archiviazione o il trasporto. Poiché

XML è uno standard aperto, il flusso XML può essere elaborato da qualsiasi

applicazione, in base alle esigenze, indipendentemente dalla piattaforma.

Se la serializzazione trasforma un oggetto in un flusso XML, la dese-

rializzazione è il processo inverso. Nella programmazione ad oggetti, de-

serializzare un oggetto significa ricostruirlo a partire dalla sua rappresenta-

zione binaria ottenuta da un file, nel nostro caso un documento XML.

Nell’applicazione LODE Web viene utilizzato il processo di deserializza-

zione di file XML per poter accedere alle varie informazioni dei corsi e del-

le lezioni, indispensabili per il processo di creazione dell’applicazione web.

Ogni lezione dispone di una serie di file XML, memorizzati all’interno della

directory Acquisition, contenenti svariate informazioni gestionali e a scopo

informativo.

I file XML in questione sono i seguenti:

• data.xml : contiene alcune informazioni generali sulle slides e sulla

lezioni come: il tempo di visualizzazione delle slides contenute nel video,

il titolo delle slides, il percorso dell’immagini delle slides, il titolo della

lezione, il nome del corso, il professore, ecc.

• LECTURE.XML : contiene tutte le informazioni relative alla lezione :

il titolo, la data, il numero progressivo, la home del corso, il professore,

la lunghezza del video, ecc.

• SLIDES.XML : contiene i vari titoli e il testo delle slides.

23

Architettura

• TIMED_SLIDES.XML : contiene informazioni temporali per la visua-

lizzazione delle slides durante l’esecuzione del video della lezione.

Per poter deserializzare queste informazioni in classi java ho utilizzato la

libreria java SimpleXML2 serializzation. Simple Xml è un framework per

la serializzazione/deserializzazione di file XML in classi java che presenta

queste principali caratteristiche:

• Semplicità di utilizzo: lo schema che viene utilizzato per fornire la seria-

lizzazione XML è semplice da usare e ruota attorno ad un unico oggetto

(Persister) utilizzato per leggere e scrivere oggetti XML.

• Non è richiesta nessuna configurazione indipendentemente dalla com-

plessità dello schema XML.

• L’estrazione delle informazioni dagli oggetti XML può essere gestita e

eseguita più rapidamente rispetto ad altri framework XML come DOM

e SAX.

• I dati Xml vengono deserializzati in classi java facilmente leggibili. Tut-

ti gli elementi e gli attributi hanno una struttura semplice che può

essere facilmente creata da un comune editor di testo.

Il processo di deserializzazione avviene nel seguente modo:

1. All’oggetto Persister viene passata la classe e la fonte del documento

XML, la classe rappresenta l’oggetto serializzato.

2. L’oggetto viene deserializzato usando il metodo read che ne produrrà un

istanza.

NB. Come si può notare non vi è nessuna necessità di esprimere il valore

restituito dal metodo read.2 c©Simple XML http://simple.sourceforge.net/

24

http://simple.sourceforge.net/

2.4 XML

Nel codice seguente è mostrato come un file XML (example.xml) viene

deserializzato in una classe java (Example.class):

Ser ia l i ze r s e r i a l i z e r = new Pers ister ( ) ;

Fi le source = new File ( " example . xml" ) ;

Example example = s e r i a l i z e r . read ( Example . class , source ) ;

Qui di seguito un esempio dove viene mostrato il contenuto di un file XML

e la classe java usata per la deserializzazione.

Java Class:

@Root (name=" root " )

public class Example {

@Element (name=" message " )

private String text ;

@Attribute (name=" id " )

private int index ;

public Example ( ) {

super ( ) ;

}

public Example ( String text , int index ) {

this . text = text ;

this . index = index ;

}

public String getMessage ( ) {

return text ;

}

public int getId ( ) {

return index ;

}

}

25

Architettura

XML code:

<root id="123">

<message> Example message < / message>

< / root>

2.5 Applicazione Web

2.5.1 Le web-application

Per sua natura una web-application (webapp) può presentarsi con diver-

se strutture di organizzazione logiche, è possibile riconoscere una struttura

tipica su tre livelli (applicazioni Three-Tier).

Figura 2.4: Three-Tier architecture

I tre livelli sono i seguenti:

1. Livello di presentazione (Client) : viene identificato dal web browser

ed è associabile al terminale di fruizione, ossia rappresenta l’interfac-

26


cia utente dell’applicazione e si occupa di acquisire dati e visualizzare

risultati.

2. Livello intermedio (Application Server): è costituito dal motore ap-

plicativo, ossia il codice in un qualche linguaggio di sviluppo dinamico

lato-server. Le elaborazioni che avvengono su questo livello generano i

risultati richiesti dall’utente.

3. Livello dati (Data Store) : è associabile all’insieme dei servizi offerti

dalle applicazioni indipendenti dal Web, come ad esempio un motore

database, un sistema di gestione della posta elettronica, ecc.

Il sistema da me realizzato permette di creare in maniera automatica

un’applicazione web. È possibile scegliere se creare un sito web statico (HTML)

o un’applicazione web con contenuti dinamici.

La differenza tra queste due tipologie di applicazione sta proprio nel livello

intermedio, ossia nel motore applicativo.

Web-application statiche

I siti web statici presentano contenuti di sola ed esclusiva lettura. Solitamen-

te vengono aggiornati con una bassa frequenza e sono mantenuti da una o più

persone che agiscono direttamente sul codice della pagina (tramite appositi

editor web).

Le pagine di un sito web statico risiedono tutte sullo stesso web server

e la ramificazione in sottocartelle dell’indirizzo corrisponde ad una uguale

ramificazione nell’hard disk dello stesso server.

Il web server deve rispondere alle richieste del client e quindi permettere

di visualizzare le pagine Web, svolgendo i seguenti compiti:

• Riconosce la richiesta.

27

Architettura

• Cerca la pagina richiesta se presente.

• Invia la pagina al browser client che la visualizzerà.

Come si può ben capire un web server non presenta nessuna logica di

controllo e per questo ha la capacità di gestire unicamente pagine statiche.

Web-application dinamiche

I siti web dinamici presentano invece contenuti composti dinamicamente,

infatti, le pagine web vengono costruite da un programma che gira sul server

grazie a particolari linguaggi di scripting come PHP, ASP, ASP.NET, invece

che CGI, JSP/Java, ecc.

Per realizzare queste applicazioni più complesse, dove è prevista un’in-

terattività con l’utente, occorre uno strumento più evoluto che permetta di

rispondere alle richieste dando una risposta in tempo reale.

La maggior parte dei server web, per poter utilizzare applicazioni web di-

namiche, dispongono di framework di sviluppo per il supporto dei linguag-

gi utilizzati nelle pagine, questi server prendono il nome di Application

Server.

Un Application server non si limita a rispondere alla richiesta dell’utente,

come avviene nelle pagine HTML, ma può eseguire algoritmi, fare calcoli,

ricerche, memorizzare, ecc. utilizzando dati presenti su un database o su

altre strutture di memorizzazione.

Esistono numerose tecnologie che permettono l’implementazione di Web

server ed Application server. Una delle più diffuse è J2EE (Java 2 Enterprice

Edition) che si avvale dei servizi di un Web server e un Application server

altrettanto famosi e diffusi: Apache e Tomcat.

28


2.5.2 Il server web Tomcat

Esiste una gran quantità di application server, la scelta deve essere fatta

tenendo conto dei linguaggi utilizzati per scrivere le pagine Web che compon-

gono l’applicazione. Nel nostro caso la scelta è ricaduta su Tomcat di Apache

Software Foundation3.

Tomcat è un ottimo web container open source che fornisce una piattafor-

ma per applicazioni web sviluppate attraverso il linguaggio Java. Oltre che

alla funzionalità di web server tradizionale (offerta da Apache) implementa

le specifiche JSP e Servlet di Sun Microsystems. Tomcat quindi è un Ser-

vlet Container ed un JSP Engine allo stesso tempo: un motore che è in

grado di eseguire lato server applicazioni web basate sulla tecnologia J2EE e

costituite da componenti Servlet e da pagine JSP.

Figura 2.5: Tomcat standalone

Tomcat è inoltre interamente scritto in java e può essere eseguito su una

qualsiasi architettura su cui sia installata una JVM (Java Virtual Machine).

3 c©The Apache Software Foundation http://www.apache.org/

29

http://www.apache.org/

Architettura

2.5.3 Java 2 Enterprise Edition

Il linguaggio di programmazione usato nella mia applicazione web dinamica

è Java, nello specifico J2EE (Java 2 Enterprise Edition), il quale raccoglie

svariate tecnologie che facilitino lo sviluppo di software web based distribuito.

Questa piattaforma di sviluppo ha avuto un enorme successo a livello

aziendale e non solo, grazie al linguaggio object oriented java e a come, attra-

verso quest’ultimo, la tecnologia è stata sviluppata. L’architettura viene rea-

lizzata tramite una struttura tecnologica a livelli dove ogni livello implementa

uno specifico servizio.

I servizi implementati in J2EE sono:

• Tecnologia Web Application : tecnologie per la produzione di in-

terfacce web dinamiche (Java Server Pages, XML, Java Server Faces,

Custom tag ).

Figura 2.6: Tecnologie Web Application

• Tecnologia Enterprise Application : tecnologie legate alla logica del

business (Enterprise JavaBean, Jndi, JavaMail, etc).

• Tecnologia Web Services : le tecnologie utili allo sviluppo delle appli-

cazioni orientate ai servizi.

• Tecnologia Management and Security : tecnologie per realizzare

l’accesso e lo scambio di informazioni tra macchine e servizi distribuiti.

30


2.5.4 JSP vs Servlet

J2EE mette a disposizione vari strumenti per la creazione di contenuti dina-

mici tra i quali : Servlet e JSP. Questi due servizi possono interagire tra di

loro in varie maniere utilizzando altre componenti come gli EJB (Enterprise

JavaBeans), JavaBeans o altro.

JSP e Servlets sono diventate un potente meccanismo per scrivere appli-

cazioni server di Internet o Intranet. Entrambe si basano e sfruttano la loro

forza sull’utilizzo di un linguaggio di programmazione come java che attribui-

sce a questi strumenti di sviluppo un elevato numero di vantaggi: robustezza,

dinamicità e scalabilità vengono affiancati a una semplicità di sviluppo.

Servlet

Le Servlet sono oggetti java risiedenti sul server con lo scopo di offrire molte

funzionalità. Questi oggetti sono utilizzati dai web server i quali mettono loro

a disposizione un particolare ambiente di lavoro, detto container.

Una Servlet ha la possibilità di accedere a tutte le risorse del sistema su

cui risiede, questo permette di implementare diverse funzionalità sfruttando

al massimo le potenzialità del sistema e del linguaggio ad oggetti java.

Esistono diverse tipologie di Servlet che dipendono dal protocollo di comu-

nicazione utilizzato; nella mia applicazione web vengono utilizzate le Http-

Servlet presenti nel package javax.servlet.http. È possibile estendere la clas-

se HttpServlet per creare servlet che comunicano con i client rispondendo

dinamicamente alle loro richieste.

L’idea principale di una Servlet è quella di condividere un unico oggetto

tra tutti i client che richiedono il servizio, evitando la creazione di più con-

nessioni verso le sorgenti dati e l’eliminazione delle stesse a fine servizio. Ad

ogni connessione viene creato un thread che ha il compito di accedere ai dati,

31

Architettura

favorendo un notevole risparmio di risorse e un conseguente aumento delle

performance dell’applicazione web (Figura 2.7).

Figura 2.7: Ambiente di esecuzione

Il paradigma client-server sul quale è basata una Servlet sfrutta i me-

todi degli oggetti: HttpServletRequest corrisponde alla richiesta effettuata

dal client verso il server e HttpServletResponse che è la risposta che viene

generata dalla Servlet.

JSP

Le JSP (Java Server Pages) sono semplici pagine web che, accanto al codi-

ce HTML, aggiungono codice Java permettendo di creare siti web con con-

tenuti dinamici. Sono un’evoluzione delle Servlet java e quindi ereditano i

vantaggi della metodologia object oriented e la quasi totale portabilità multi-

piattaforma. Una semplice invocazione di una Servlet in una pagina HTML

è differente dall’uso di una pagina JSP: per il programmatore l’uso di Ja-

va Server Pages consiste nell’unione di codice HTML, componenti riusabili

(JavaBeans), applicazioni remote (Servlets), codice java e script java-like (Ja-

vaScript). Quindi le JSP rappresentano una tecnologia per l’unione di una

32


serie di oggetti differenti tra loro ma che cooperano assieme per la creazione

di contenuti dinamici.

Nelle pagine JSP vengono utilizzati specifici tag di demarcazione per in-

dicare l’inizio e la fine del codice Java. Il contenuto dinamico è separato dal-

la parte di disegno dell’interfaccia (HTML), quindi si potranno modificare le

parti sviluppate in java lasciando inalterato il codice HTML e viceversa.

Una Java Server Page può essere invocata utilizzando due metodi:

• La richiesta può essere effettuata direttamente a una pagina JSP che è

in grado di elaborare i dati richiesti e restituire l’output.

• La richiesta può essere filtrata da una Servlet che elabora i dati e ri-

chiama la pagina JSP che produrrà l’output.

2.5.5 Tag cloud

Nel corso degli anni le applicazioni web, in particolare le interfacce utente,

sono cambiate radicalmente sia come rappresentazione che come raggruppa-

mento delle informazioni. Si cerca sempre più di rappresentare le informa-

zioni attraverso modelli più schematici e meno gerarchici, come poteva essere

il modello a directory tipico delle prime applicazioni web.

Le cosiddette applicazioni web 2.0 hanno introdotto dei modelli di comu-

nicazione visuale che permettono all’utente di fruire del servizio in maniera

immediata e intuitiva. Un elemento che si sta sempre più diffondendo nel-

le applicazioni web è quello dei tags dove ad un elemento informativo può

essere associata più di una categoria.

Una tag cloud è un insieme di etichette (tag) dove ognuna ha una grandez-

za proporzionale al proprio peso che viene reso visivamente con l’utilizzo di

font di testo diversi. Una tag cloud fornisce all’utente un elenco di qualificato-

ri, un insieme di etichette che vengono attribuite a oggetti specifici all’interno

33

Architettura

dell’applicazione Web. Nella maggior parte dei casi i tag sono veri e propri

link e quindi forniscono anche un ottimo supporto per la navigazione.

I vari tag sono definiti dagli utenti del sito, anche se esistono alcune appli-

cazioni web dove è il redattore stesso che decide di “taggare” i contenuti con

una serie di parole chiave.

Nella mia applicazione web le tag clouds vengono utilizzate per indivi-

duare i concetti più frequenti che compaiono all’interno del testo delle sli-

des relative alle varie lezioni. In questo modo l’utente può farsi un’idea

sull’argomento della lezione e quali sono i concetti chiave.

Per poter calcolare le occorrenze delle keyword (parole chiave nel testo)

e di conseguenza generare una tag cloud mi sono avvalso di una libreria java

apposita, OpenCloud, la quale viene utilizzata per la generazione e la gestio-

ne di nuvole di tag attraverso una serie di metodi e funzioni. Questa libreria

è molto versatile e permette di generare insiemi di tag in maniera semplice e

intuitiva, l’utente non dovrà fare altro che inserire il testo e fissare una serie

di parametri, utilizzati per controllare la struttura, ad esempio: il numero di

tag e il tipo di ordinamento. Saranno i metodi della libreria che assoceranno

un peso ad ogni tag in base alla sua frequenza all’interno del testo restituendo

una lista di tag pesata. È possibile inoltre gestire l’aspetto grafico della nube

di tag che può essere controllato grazie a istruzioni HTML e CSS.

La mia applicazione web utilizza una tag cloud per ogni lezione che pre-

senti delle slides. La tag cloud utilizzata è un oggetto in flash che permette di

scorrere i vari tag, rappresentati sul perimetro di una sfera tridimensionale.

A seconda del numero di occorrenze i vari tag assumeranno un font e una

gradazione di colore differente.

ES. : Le parole chiave (keyword) più presenti nelle slides saranno scritte

più scure e con un carattere più grande.(Figura 2.8)

34


L’oggetto flash viene integrato nell’applicazione web attraverso codice ja-

vascript che ci permette di specificare diversi parametri come: i tag, il loro

peso, i link per i tag e altri parametri grafici.

Figura 2.8: Tag Cloud in Flash

2.5.6 Creazione dinamica di archivi

Per ogni lezione, indipendentemente dalla tipologia di applicazione web scelta

dall’utente, vengono creati degli archivi che contengono il materiale multime-

diale, in questo modo egli potrà scaricarli con facilità dal sito.

Nell’applicazione web statica gli archivi vengono generati durante la fase

di creazione del sito (come ho spiegato nel paragrafo 2.2.1), invece gli archivi

per l’applicazione web dinamica vengono generati al momento della richiesta

dall’applicazione stessa. L’applicazione web dinamica quindi crea dei file ZIP

in maniera dinamica soddisfando le richieste dell’utente: ogni volta che un

35

Architettura

utente del sito richiede il download del materiale di una lezione, l’applicazio-

ne web genera l’archivio e lo copia in una directory temporanea. I successi-

vi utenti che richiedono lo stesso file non dovranno attendere il processo di

creazione perché l’archivio sarà già disponibile per il download.

Questo metodo permette un notevole risparmio di risorse, se si pensa che

un video di una lezione raggiunge dimensioni nell’ordine di centinaia di mega.

Lo scheduler Cron4J

Uno scheduler è un componente essenziale nei sistemi multitasking che per-

mette di eseguire più processi (task) con-correntemente, specificando, attra-

verso delle regole, quando devono essere eseguiti. Il suo utilizzo è molto ef-

ficace e si basa su pochi ed intuitivi metodi che permettono di avviare i task

mediante delle regole, espresse da stringhe e dette scheduling pattern.

Per diminuire lo spazio occupato dall’applicazione web ho utilizzato un

metodo per avviare dei processi di “pulizia” dello spazio temporaneo conte-

nente gli archivi. L’eliminazione avviene ad intervalli regolari controllando la

data di ultimo accesso.

Per far questo mi sono servito dello scheduler Cron4J4 (uno scheduler

java molto simile a Cron per Unix) che ha il compito di avviare le operazioni

di pulizia in momenti prefissati.

L’utilizzo di Cron4J prevede quattro fasi principali:

1. Si crea un’istanza di Scheduler (Entità principale, istanza della classe

it.sauronsoftware.cron4j.Scheduler).

Scheduler scheduler = new Scheduler ( ) ;

2. Si “schedulano” le azioni desiderate, ossia si specifica cosa lo scheduler

deve eseguire e quando deve farlo. Il “cosa” può essere specificato trami-4Cron4J : http://www.sauronsoftware.it/projects/cron4j/?lang=it

36

http://www.sauronsoftware.it/projects/cron4j/?lang=it


te un’istanza di java.lang.Runnable, ossia utilizzando i thread di java.

Il “quando” viene specificato servendosi degli scheduling pattern.

3. Si avvia lo scheduler.

scheduler . s tart ( ) ;

4. Si arresta lo scheduler quando non è più necessario.

scheduler . stop ( ) ;

Per poter creare lo scheduler ho utilizzato gli eventi legati al servlet

context, i trigger di questa classe di eventi avvengono contestualmente alle

transizioni di stato del servlet context associato alla web application corren-

te. Nello specifico ho usato l’interfaccia ServletContextListener, tramite

la quale un oggetto listener riceve, a livello di servlet context, la notifica dei

seguenti eventi:

• public void contextInitialized(javax.servlet.ServletContextEvent

sce) : notifica della creazione del servlet context e dell’attivazione della

web application corrente.

• public void contextDestroyed(javax.servlet.ServletContextEvent

sce) : notifica della prossima distruzione del servlet context corrente e

dello shut down della relativa web application.

Questo listener, dunque, è in grado di creare uno scheduler integrato nel-

l’applicazione web che viene avviato quando l’applicazione viene attivata e

stoppato quando essa viene chiusa.

Questo scheduler viene anche registrato nell’application context all’inter-

no di un attributo chiamato in base al valore della sua costante.

context . setAttr ibute ( Constants .SCHEDULER, scheduler ) ;

37

Architettura

Scheduling pattern Un pattern di schedulazione (o scheduling pattern) è

rappresentato da una stringa suddivisa in cinque parti, ognuna separata dal-

la successiva da una spaziatura. Ogni parte rappresenta dei sotto-pattern,

partendo dal primo abbiamo i sotto-pattern per: minuti, ore, giorni del mese,

mesi e giorni della settimana. Se non si vuole porre restrizioni specifiche sui

sotto-pattern si può usare il carattere asterisco che, a seconda del contesto,

sta a significare: tutti i minuti, tutte le ore, ecc.

Esempio di scheduling pattern:

0 13 12 * Mon : Questo pattern avvia un task, a cui è collegato, alle 13:00 del

12 del mese, solo se è lunedì.

Eliminazione degli archivi L’eliminazione degli archivi avviene attraver-

so un task lanciato dallo scheduler nei momenti specificati dai pattern e scelti

dall’utente. Questo task è un thread che ha il compito di eseguire un script

unix parametrizzato per la pulizia della directory temporanea.

Il codice dello script è il seguente:

commandstring=" f ind $ { parray [ 0 ] } −name ∗ . z ip −atime \$ { parray [ 1 ] } −delete "

echo $commandstring

$commandstring

Questo codice si basa sul comando unix find che ricerca file e directory nel

file system che soddisfano i criteri specificati, elencandone i nomi o eseguendo

un comando per i risultati trovati. È possibile specificare delle direttive che

possono indicare i test da effettuare sul file o sulla directory in esame, oppure

possono eseguire azioni o ancora modificare il comportamento di find.

Le direttive utilizzate sono le seguenti:

38


• name modello :

Il test viene superato se il nome del file o della directory soddisfa il mo-

dello specificato. Il modello è una stringa la cui sintassi deve rispettare

il modello glob pattern (per come funziona la shell testuale occorre indi-

carlo tra apici singoli o doppi, oppure precedendo ogni metacarattere da

una barra inversa).

ES. : find . -name *.zip : elenca tutti i file con estensione zip presenti

nella directory corrente.

• atime giorni :

Supera il test se la data di ultimo accesso in lettura al file o directory

corrisponde a quella odierna meno il numero di giorni specificati. Per

indicare una qualunque data posteriore si può usare il prefisso + (es.

+10). Per indicare una qualunque data anteriore si può usare il prefisso

- (es. -4).

ES. : find . -name *.zip -atime -3 : elenca tutti i file con estensione zip la

cui data di ultimo accesso è anteriore a quella di tre giorni fa.

Attraverso l’opzione -delete è possibile eliminare tutti i file o le directory

restituite dal comando find.

39

Architettura

40

Capitolo 3

Analisi dei requisiti

41


3.1 Introduzione

In questo capitolo viene discussa la progettazione architetturale dell’applica-

zione LODE Web, definendo la struttura complessiva del sistema. Verranno

trattati gli aspetti funzionali e strutturali dell’applicazione e dei sui processi

principali, secondo l’ingegneria del software.

Il primo passo di qualsiasi processo di sviluppo è la definizione dei requisi-

ti: occorre avere le idee chiare sulle funzioni dell’applicazione deve e sui ruoli

degli attori che la utilizzano.

3.2 Requisiti funzionali

I requisiti funzionali definiscono i servizi che il sistema deve offrire e il com-

portamento che deve avere a seguito di particolari inputs e situazioni.

1. Scelta della tipologia di applicazione web

Il sistema deve offrire all’utente la possibilità di scegliere la tipologia di

applicazione web (statica o dinamica).

2. Creare pagine per la fruizione delle lezioni

Il sistema deve creare un’applicazione web semplice e intuitiva, che pos-

sa rendere disponibile tutto il materiale delle lezioni di un corso. Qual-

siasi utente (professore) potrà creare la propria pagina personalizzata

agendo su alcune proprietà di quest’ultima.

3. Sistema per il download del materiale multimediale

Il sistema deve includere la possibilità di fruizione del materiale delle

lezioni attraverso la creazione di archivi facilmente accessibili e scari-

cabili dagli utenti del sito. Il metodo per la creazione degli archivi de-

ve differire a seconda della tipologia di applicazione web utilizzata: in

42

3.2 Requisiti funzionali

un’applicazione web statica deve avvenire durante la fase di creazio-

ne del sito mentre, in un’applicazione web dinamica, ad ogni richiesta

dell’utente.

4. Creazione di anteprime dei video

L’applicazione deve permettere la creazione di immagini di preview cat-

turandole da ogni singolo video. Questa possibilità aumenta il livello

di informazione visuale dell’applicazione, dando al fruitore del sito una

vista anticipata di come sarà il video della lezione.

5. Sistema di visualizzazione delle slides

Il sistema deve prevedere un metodo per visualizzare le slides relative

ad ogni singola lezione.

6. Creazione di Tag clouds

Il sistema deve classificare e raggruppare le informazioni delle varie

lezioni attraverso delle tag cloud. Le parole chiave (tag) devono essere

estrappolate dal testo delle varie slides.

7. Modifica della grafica del sito

L’applicazione deve offrire un sistema per la modifica e la creazione di

interfacce grafiche web personalizzate attraverso un editor di “fogli di

stile” (CSS).

8. Note per le lezioni

Ad ogni lezione deve essere associata un’area di testo dove l’amministra-

tore del sito potrà aggiungere o modificare note attraverso editor facil-

mente utilizzabili. Le procedure per la modifica delle note devono diffe-

renziarsi a seconda dell’applicazione web utilizzata: in quella statica la

modifica deve essere gestita da un’applicazione esterna al sito, mentre

in quella dinamica deve avvenire attraverso pagine web dinamiche.

43


9. Sezione di amministrazione per l’applicazione web

L’applicazione web dinamica deve disporre di un’area dedicata all’am-

ministratore del sito, accessibile solo attraverso pagine di autenticazio-

ne. Quest’area deve mettere a disposizione una serie di strumenti per

la personalizzazione del sito: modifica di note, modifica dati di accesso,

modifica grafica, ecc.

3.3 Requisiti non-funzionali

I requisiti non-funzionali di un’applicazione definiscono le proprietà e i vin-

coli. Essendo più critici dei requisiti funzionali, se non rispettati, possono

rendere il sistema inutile.

• SEMPLICITÀ

Il sistema deve essere semplice e intuitivo nel suo utilizzo, sia per quel

che riguarda la pubblicazione automatica del sito, sia per l’utilizzo del-

l’applicazione web. L’utente potrà così utilizzare il sistema senza posse-

dere particolari conoscenze tecniche.

• AUTOMAZIONE

Sia in fase di creazione che di modifica dell’applicazione web il livello di

automazione deve garantire un intervento minimo da parte dell’opera-

tore.

• APPLICAZIONE DISTRIBUITA

L’applicazione web per LODE deve essere distribuita in modo che diversi

utenti possano utilizzarla contemporaneamente.

• PRESTAZIONI

Le prestazioni dell’applicazione devono essere indipendenti dalla piat-

44

3.4 Use case diagram

taforma. Il sistema deve utilizzare metodi di creazione e modifica che

abbiano dei tempi di risposta relativamente bassi.

• ROBUSTEZZA

Il sistema deve comportarsi in modo ragionevole a fronte di situazio-

ni impreviste: gli errori devono essere rilevati e non devono provocare

effetti dannosi al sistema.

• PORTABILITÀ

Il sistema deve “adattarsi” ad ambienti di esecuzione diversi. La porta-

bilità dell’applicazione è importante per via della diversità delle inter-

facce (API) dei sistemi operativi e dei diversi ambienti di sviluppo.


Il progetto è suddivio in due parti principali strettamente legate tra di loro:

l’applicazione LODE Web e il sito web per LODE (generato da LODE Web).

Di seguito verranno rappresentati i diagrammi d’uso (use case diagrams)

riguardanti le parti principali dell’applicazione, i quali descriveranno le fun-

zionalità del sistema e come quest’ultimo agisce e reagisce a determinati

input dell’utente.

La classi di utenti che usufruiscono dei vari servizi di un’applicazione ven-

gono chiamate attori. Ogni attore ne controlla le funzionalità e fornisce input

o riceve output dal sistema.

LODE Web

LODE Web è accessibile da una sola categoria di utenti (attori), i docenti

(o i responsabili del corso), i quali hanno la possibilità di utilizzare tutte le

funzionalità che l’applicazione offre.

45


Figura 3.1: Use Case Diagram per LODE Web

Un docente può :

• Creare una nuova applicazione web.

• Modificare e aggiungere note alle lezioni del sito.

• Modificare la grafica del sito (Editor di CSS).

• Aggiungere nuove lezioni a un sito web esistente.

Applicazione web LODE

Nell’applicazione web per LODE esistono due tipologie di utenti: lo studente

(utente generico) e l’amministratore del sito (docente del corso) solo nel caso

venga scelta l’applicazione web dinamica.

L’amministratore svolge tutte le attività degli altri utenti e in più dispone

di funzioni di manutenzione e di modifica del sito.

46


Figura 3.2: Use Case Diagram per l’applicazione web per LODE

Lo studente può :

• Accedere al materiale multimediale delle lezioni.

• Scaricare gli archivi delle lezioni.

• Scaricare le slides.

• Visualizzare le note delle lezioni.

L’amministratore può :

• Modificare la grafica del sito.

• Modificare e aggiungere note alle lezioni.

• Modificare i dati di autenticazione (username e password).

47


48

Capitolo 4

Progettazione

dell’applicazione

49

Progettazione dell’applicazione

4.1 Introduzione

Sulla base della specifica dei requisiti, prodotta dall’analisi, in questa sezione

spiegherò quali sono state le scelte effettuate in fase di progettazione dell’ap-

plicazione in modo che tali requisiti vengano soddisfatti, entrando nel merito

dell’architettura e di come l’applicazione è stata realizzata.

4.2 Le classi dell’applicazione

Figura 4.1: Package diagram

L’applicazione LODE Web è organizzata in package in maniera da otti-

mizzare la gestione delle classi e delle relazioni tra queste. Esistono quattro

package principali, ognuno contiene a sua volta dei sub-package come viene

mostrato in figura 4.1.

Il package lodeWeb.serializzationxml contiene diverse classi java che

50

4.2 Le classi dell’applicazione

vengono utilizzate per la serializzazione e la deserializzazione di file XML,

esistono tanti sub-package quanti i file XML da serializzare. La classe Ma-

nageInfoXML.java, contenuta in questo package, offre metodi per la seria-

lizzazione che fanno riferimento alle classi contenute nel vari sub-package.

Il package lodeWeb.gui contiene le classi java per la creazione delle gra-

fica (Swing), questo è suddiviso in tre ulteriori package (lodeWeb.gui.create,

lodeWeb.gui.manage, lodeWeb.gui.css) il cui scopo è quello di creare i pan-

nelli principali dell’applicazione: pannello di creazione del sito, pannello di

manutenzione e l’editor di CSS.

Il frame principale, che contiene i vari pannelli, viene creato dalla classe

main MainFrame.java.

Il package lodeWeb.util contiene diverse classi che mettono a disposizio-

ne svariati metodi e funzioni utili all’applicazione e ai suoi processi:

• util.java: offre una serie di funzioni per: la creazione delle tag clouds,

la lettura e la scrittura su file, la copia e lo spostamento di file, il salva-

taggio dei dati delle lezioni in strutture come array e liste.

• WriteOnHTML.java: contiene funzioni e procedure per la creazione

dinamica di pagine HTML: è possibile creare la pagina di index del corso

utilizzando le informazioni delle lezioni oppure creare generiche pagine

HTML specificandone il codice e i vari tag.

• ProcessRuntime.java: contiene funzioni per la creazione di proces-

si (Process), attraverso la specifica di determinati comandi di sistema.

Inoltre mette a disposizione metodi per rilevare il sistema operativo

dove l’applicazione è in esecuzione.

• GifEncoder.java : questa classe, contenuta nel sub-package lodeWeb.

util.GifEncode, offre metodi per la creazione di gif animate da un set

51


di immagini esistenti (estensione .jpg). Viene utilizzata per la creazione

dell’immagine di preview dei video.

• VlcImages.java : questa classe, contenuta nel sub-package lodeWeb.

util.Vlc, offre una serie di metodi per l’esecuzione di comandi VLC con

lo scopo di acquisire immagini da video.

• ZipDir.java : questa classe, contenuta nel sub-package lodeWeb.util

.Zip, dispone di una serie di funzionalità per la creazione di archivi

zip, utilizzando sia istruzioni java sia comandi del sistema operativo

(eseguiti dalla classe ProcessRuntime.java).

• Constants.java : contiene la collezione di tutte le costanti utilizzate

nell’applicazione: i nomi delle cartelle e dei file, le estensioni dei file che

vengono creati, la lista dei fogli di stile precreati, i dati di autenticazione

di default, ecc.

Fornisce all’applicazione una maggior portabilità e la possibilità di adat-

tamento a seguito di cambiamenti e modifiche ai dati.

Per finire, il package lodeWeb.execution contiene la classe Exec.java

che ha il compito di avviare il processo di creazione dell’applicazione web il

cui funzionamento verrà descritto nel paragrafo successivo (paragrafo 4.3).

4.3 Il funzionamento: processo di creazione

Il processo di creazione dell’applicazione web viene gestito dalla classe Exec

.java, contenuta del package lodeWeb.execution. Questa classe dispone di

diverse “fasi” che variano a seconda della tipologia di applicazione web che

si vuole creare (statica o dinamica) e ognuna svolge uno specifico compito nel

processo di creazione.

52


È possibile scegliere la tipologia del sito e altre specifiche grazie a una

serie di parametri passati al costruttore della classe.

Il processo di creazione è completamente indipendente dal resto dell’appli-

cazione per via della sua parametrizzazione e della sua esecuzione attraverso

un thread. La parte grafica, che avvia il processo di creazione, creerà un og-

getto Thread passando al costruttore un’istanza della classe Exec.java che

implementa l’interfaccia Runnable.

Runnable richiede l’implementazione del solo metodo run che definisce

il comportamento del thread stesso, nel nostro caso esegue il metodo per la

generazione dell’applicazione web.

L’esecuzione indipendende del thread non impedisce di comunicare i risul-

tati delle operazioni alla grafica dell’applicazione, questo è possibile grazie a

un ulteriore thread che funge da “pompa”, redirigendo l’output del processo di

creazione a componenti grafici che tengono traccia delle operazioni eseguite.

Le fasi principali che interessano il processo di creazione sono:

1. Acquisizione di informazioni sulle lezione

Tutte le informazioni vengono inserite in una struttura List<Row> (li-

sta di oggetti Row) per poterle reperire con facilità. Row.java è la classe

che contiene le informazioni di una singola lezione, ogni istanza di Row

andrà poi a comporre una riga della tabella.

2. Creazione del codice HTML

Questa fase consiste in un ciclo while che scandisce la lista di Row (Li-

st<Row>), grazie ad un Iterator, creando il codice HTML per le righe

della tabella utilizzato per comporre la pagina index del sito web.

3. Copia del materiale multimediale delle lezioni

In questa fase viene creata, qualora non esistesse già, la directory di out-

53


put per il sito web copiando tutto il materiale multimediale delle lezio-

ni dalla directory Acquisition alla directory Course dell’applicazione

web.

4. Creazione delle anteprime dei video

Questa fase avvia il processo di creazione delle anteprime di ogni vi-

deo delle lezioni, utilizzando i metodi forniti dalla classe VlcImages.java

(package lodeWeb.util.Vlc) per la creazione di immagini di preview e

quelli forniti dalla classe GifEncoder.java (package lodeWeb.util.GifEncode)

per la creazione di gif animate.

5. Creazione dei file per le note

Questa fase genera i file per le note delle lezioni: nel caso di un’appli-

cazione web statica viene lanciato il metodo offerto dalla classe WriteO-

nHTML.java che crea tanti file html quante sono le note per le lezioni,

nel caso di un’applicaizone web dinamica viene creato un solo file XML

utilizzando i processi di serializzazione offerti dalla classe ManageIn-

foXML.java (package lodeWeb.serializationxml).

6. Creazione degli archivi

Questa fase viene implicata solo per il processo di creazione dell’appli-

cazione web statica. Le funzioni che permettono di creare gli archi-

vi vengono messe a disposizione dalla classe ZipDir.java (package lo-

deWeb.util.Zip) che avrà il compito di rilevare il sistema operativo e lan-

ciare processi esterni di creazione oppure opportuni metodi java per la

compressione.

7. Copia dei file per l’applicazione web

Vengono copiati i file dalla directory toPost alla directory principale

del sito web, i file contenuti in questa directory vanno a comporre l’ap-

54


plicazione web stessa e sono: files di configurazione web, classi per

l’applicazione web dinamica, fogli di stile, pagine HTML e JSP per la

visualizzazione dei contenuti, ecc.

8. Scrittura della pagina index

Le righe della tabella vengono scritte su file componendo l’intero codice

HTML della pagina utilizzando metodi di scrittura offerti dalla classe

WriteOnHTML.java.

Istanziando la classe Exec.java è possibile inizializzare alcuni attributi

che vengono utilizzati durante il processo di creazione, alcuni di questi sono

contenuti nella classe OptionClass.java (package lodeWeb.util), altri invece

all’interno di un array di stringhe.

Qualunque oggetto faccia uso di un’istanza di OptionClass.java può acce-

dere alle variabili solamente attraverso i metodi get e set della classe stessa.

Questi due metodi consentono di regolare l’accesso ai campi, che rappresen-

tano lo stato dell’oggetto, garantendo così che tale stato rimanga consisten-

te. Exec.java dovrà fare riferimento solo ai metodi get della classe per poter

accedere ai parametri di creazione.

Le variabili contenute nella classe opzioni (OptionClass.java) sono:

• Context : può assumere i valori DYNAMIC o STATIC, viene utilizza-

ta per scegliere la tipologia di applicazione web che si desidera crea-

re, rispettivamente: un’applicazione web dinamica o un sito web statico

HTML.

• Variabili booleane : vengono utilizzate per escludere alcune fasi dal

processo di creazione : pVideo (generazione delle preview), image-

fromSlides (copia delle slides), lectures (copia dei video), zip (creazio-

55


ne degli archivi), notes (creazione dei file per le note), slidesSources

(sorgenti delle slides).

• Username e password : variabili testuali (String) usate per specificare

i dati di autenticazione alla parte amministrativa dell’applicazione web

dinamica.

Nella figura 4.2 vengono mostrate le varie fasi del processo di creazione

attraverso un activity diagram.

56


Figura 4.2: Activity: processo di creazione

57


58

Capitolo 5

Manuale d’uso

59

Manuale d’uso

5.1 Premessa

5.1.1 Scopo del manuale

Questa guida vuole essere un aiuto per capire le funzionalità e le potenzialità

dell’applicazione LODE web. Il suo uso corretto consente di creare un’appli-

cazione web intuitiva e facilmente accessibile all’utente, oltre a permetterne

la personalizzazione e la modifica.

5.1.2 Struttura dell’applicazione

L’applicazione LODE Web è strutturata in due parti principali: la parte di

creazione e la parte di manutenzione e modifica della web-application.

Ogni parte svolge funzionalità specifiche e dispone di un pannello dedicato fa-

cilmente accessibile mediante un TabPanel sul frame principale o utilizzando

il menu, dove è possibile selezionare i vari pannelli (Figura 5.1).

Per utilizzare le varie funzionalità, i pannelli offrono componenti grafici,

aree di testo per l’output e per la notifica degli errori.

Figura 5.1: Pannelli dell’applicazione LODE Web

L’applicazione prevede anche un piccolo editor di CSS: l’utente potrà mo-

dificare e/o creare la grafica della propria applicazione web attraverso un’in-

terfaccia intuitiva e di facile utilizzo (vedi paragrafo sull’editor 5.3.3) (Figura

5.2).

60

5.2 Installazione e configurazione

Figura 5.2: Cascading Style Sheet Editor


5.2.1 Requisiti per l’utilizzo

Per poter utilizzare l’applicazione è richiesto un sistema operativo che dispon-

ga di una JVM (Java Virtual Machine). Come ambiente di sviluppo è stato

usato NetBeans 1 (versione 6.5) con JDK (Java Development Kit) (versione

1.6).

Per un corretto funzionamento si richiede che siano presenti nel path

principale le seguenti directory :

• /Css : viene utilizzata dall’editor di CSS per la creazione di nuovi fogli

di stile, contiene cinque fogli di stile già creati e uno personalizzabile

tramite l’editor.1 c©NetBeans : http://www.netbeans.org/

61

http://www.netbeans.org/

Manuale d’uso

• /toPost : contiene i file indispensabili per generare l’applicazione web e

per utilizzarne le funzionalità. Alcuni di questi file vengono modificati

durante il processo di creazione, altri invece sono statici e non subiscono

modifiche durante la copia nella directory di output.

• /Images : contiene le immagini utilizzate dall’applicazione per la grafi-

ca dei pulsanti e di altri componenti.

NB. : non è indispensabile per un corretto funzionamento dell’applica-

zione.

L’utente verrà avvisato con un messaggio d’errore nelle aree di testo appo-

site su ogni pannello nel caso una o più di queste cartelle risultino mancanti.

È richiesta l’installazione del software VLC media player (VideoLAN

Client) scaricabile dal sito www.videolan.org/vlc/. Per gli utenti Windo-

ws è necessario specificare il percorso di installazione di VLC attraverso il

pannello di configurazione accessibile dal menu (Figura 5.3).

Figura 5.3: Pannello di configurazione

5.2.2 Compatibilitá sistema operativo

L’applicazione è compatibile con i seguenti sistemi operativi:

• Windows Vista

62

www.videolan.org/vlc/


• Windows XP Professional (SP1,SP2)

• Windows XP Home

• Windows 2000 Professional (SP4+)

• Linux

• Mac Os X

Rilevato il sistema operativo utilizzato, di conseguenza vengono lanciati

in automatico metodi e procedure adatte all’ambiente d’esecuzione.

5.2.3 L’applicazione web: requisiti

Per un corretto funzionamento dell’applicazione web dinamica è necessa-

rio predisporre di una macchina con il server Apache Tomcat2 (consigliata

la versione 6) .

Nel caso si scelga un’applicazione web statica è sufficiente possedere

un qualunque web server senza particolari framework.

5.2.4 Configurazione web

Qualora si volesse modificare la configurazione o la struttura del sito web

si deve agire manualmente sui file all’interno della directory toPost che si

trova nel path principale dell’applicazione LODE Web. Essa contiene due

sottodirectory: STATIC e DYNAMIC dove sono presenti i file necessari per

entrambe le tipologie di applicazione web.

NB. : Si consiglia di effettuare una copia di backup dei file prima di

procedere con le modifiche.

2 c©Apache Tomcat : http://tomcat.apache.org/

63

http://tomcat.apache.org/

Manuale d’uso

Parametri di login

Se l’utente sceglie l’applicazione web dinamica, ha la possibilità di modificare

le informazioni per l’accesso alla parte amministrativa del sito.

I parametri di login dell’amministratore risiedono all’interno di un file

di testo (login.txt) nella directory WEB-INF. La modifica di questo file può

essere effettuata manualmente, se si ha accesso ai file depositati sul server,

oppure accedendo alla parte di amministrazione del sito, riservata al solo

amministratore.

La sintassi del file login.txt è la seguente:

username = "admin"

psw = "admin"

NB. : modificare solamente l’username e la password contenuti tra i doppi

apici. Ogni altra modifica del file potrebbe provocare un malfunzionamento

dell’applicazione.

5.3 Funzionalitá

5.3.1 Creazione dell’applicazione web

Pannello di creazione

Il pannello di creazione è composto da tre aree principali.

Nella parte alta del pannello (north) (Figura 5.4), attraverso componen-

ti grafici che permettono di navigare le directory del sistema operativo, è

possibile scegliere :

• La directory che contiene il materiale di un corso universitario (Course

Dir).

• La directory dove verrà generato il sito web (Output Dir).

64

5.3 Funzionalitá

Queste due opzioni sono indispensabili per poter avviare il processo di

creazione, qualora venga omesso uno o entrambi i campi, l’utente verrà avvi-

sato mediante un messaggio d’errore.

Figura 5.4: Choose panel

Nella parte bassa del pannello (south) (Figura 5.5) vi è un’area di testo,

non editabile, per la notifica dei messaggi d’errore. È possibile cancellare tale

area o salvarne una copia su un file mediante gli appositi pulsanti : Clean e

Save Log.

L’opzione di salvataggio può essere utile nel caso l’utente rilevi un errore

inaspettato durante l’esecuzione e voglia salvare una copia delle operazioni

eseguite e/o delle notifiche di malfunzionamenti.

Figura 5.5: Area di notifica

Nella parte centrale del pannello (center), vengono messe a disposizione

diverse opzioni che variano a seconda della tipologia di applicazione web che

si vuole creare (statica o dinamica). Un componente di selezione permette di

scegliere tra applicazione web statica (STATIC) o applicazione web dinamica

65

Manuale d’uso

(DYNAMIC), a seconda della scelta l’utente disporrà di diverse opzioni di

creazione.

Nel caso si voglia creare un’applicazione web statica (STATIC) le opzioni

disponibili sono:

• La possibilità di integrare le sorgenti delle slides al sito (Slide Sources)

• La creazione di archivi delle lezioni, tramite file compressi zip (Zip file

lectures)

• La generazione delle immagini di preview dei video (image from vi-

deo).

• L’aggiunta delle immagini prese dalle slides (image from slides)

• L’aggiunta di pagine HTML per poter inserire note e descrizioni su ogni

lezione (file notes).

Figura 5.6: Pannello opzioni STATIC

66

5.3 Funzionalitá

Se si vuole creare un’applicazione web dinamica (DYNAMIC) invece è

possibile:

• Aggiungere le sorgenti delle slides al sito (Slide Sources)

• Creare le preview dei video (image from video)

• Aggiungere le immagini delle slides (image from slides)

• Inserire i dati di autenticazione per l’amministratore del sito (username

e password).

Figura 5.7: Pannello opzioni DYNAMIC

In entrambi i casi vi è la possibilità di scegliere la grafica del sito grazie

all’editor di CSS accessibile dal pulsante Choose css. L’utilizzo dell’editor

verrà spiegato nel paragrafo 5.3.3.

Nel caso l’utente trascuri la modifica della grafica verrà utilizzato un foglio

di stile di default (Style5.css).

67

Manuale d’uso

Applicazione web statica o dinamica?

Prima di entrare nello specifico, per quel che riguarda la creazione del sito,

l’utente deve conoscere bene la differenza tra le due tipologie di applicazioni

web : statica e dinamica e valutare la compatibilità con il proprio web-

server.

Di seguito elencherò le principali caratteristiche delle due tipologie di web-

application nel nostro caso specifico:

Applicazione web statica:

• Interamente composta da pagine web statiche (formato HTML) che, per

essere eseguite, non richiedono particolari server context (i linguaggi

utilizzati sono html e javascript).

• Richiede, ove necessario, che l’amministratore “aggiorni” manualmente

il contenuto del sito modificando le pagine direttamente sul web server.

• Richiede uno spazio sul web server maggiore rispetto alla relativa ap-

plicazione web dinamica, questo perchè ogni cartella, contenente il ma-

teriale di una lezione, viene compressa durante la fase di creazione del

sito.

Applicazione web dinamica:

• La parte statica viene integrata da contenuti dinamici mediante l’utiliz-

zo di pagine JSP (Java Server Pages) e Servlet. Queste permettono di

inserire parti di codice java nell’applicazione web.

• L’amministrazione e la manutenzione del sito viene gestita da un’ap-

posita sezione riservata al solo amministratore e accessibile mediante

pagine di autenticazione.

68

5.3 Funzionalitá

• Lo spazio occupato sul server è minore rispetto all’applicazione web sta-

tica: i vari file compressi delle lezioni vengono generati al momento della

loro richiesta e cancellati dopo un tot di tempo di inutilizzo.

Creare una nuova web application

Per creare una nuova applicazione web (statica o dinamica):

1. Selezionare la directory contenente il materiale del corso (Course Dir).

NB: la directory deve contenere: /Distribution, /Acquisition, COUR-

SE.XML.

2. Selezionare la directory dove verrà generata l’applicazione web (Output

Dir).

NB: l’utente deve disporre dei permessi di creazione e modifica sulla

directory, la quale deve essere vuota.

3. Scegliere la tipologia di applicazione web che si vuole creare (STATIC o

DYNAMIC) tramite l’apposito componente grafico (JComboBox). A se-

conda della tipologia scelta verranno abilitate le opzioni per la creazione.

4. Selezionare, attraverso i check-box (JCheckBox), le opzioni di creazione

desiderate.

NB: alcune opzioni, come la copia delle lezioni (lecture distribution)

e l’aggiunta degli zip al sito (zip file lecture), sono indispensabili per

una corretta procedura di creazione.

Per l’applicazione web dinamica sono richiesti i dati per l’autenticazione

dell’amministratore (username e password). Per modificare questi

dati si può utilizzare un pannello, accessibile dal pulsante Edit (Figura

5.8). Sui dati inseriti verranno fatti controlli riguardanti la dimensione

dei caratteri e la correttezza.

69

Manuale d’uso

Qualora non vengano inseriti verranno utilizzati quelli di default:

• username : admin

• password : admin

Figura 5.8:

5. Scegliere il foglio di stile per il sito web: è possibile selezionare fogli

di stile da una galleria oppure crearsi il proprio usando l’editor grafico

integrato nell’applicazione (vedi capito su Editor CSS 5.3.3).

6. Avviare il processo di creazione cliccando sul pulsante Go!!!.

Figura 5.9: Pannello di progressione

Apparirà un pannello nel quale verranno elencate, passo per passo, tut-

70

5.3 Funzionalitá

te le operazioni di creazione utilizzando una barra di progressione e

contemporaneamente dei messaggi di notifica (Figura 5.9).

Con l’avvio del processo di creazione, nell’area di log, verranno stampati

ulteriori messaggi che riportano la cronologia delle operazioni eseguite,

specificando le date di avvio e di fine delle stesse.

NB: la chiusura del pannello di progressione comporta l’interruzione del

processo di creazione e la chiusura dell’applicazione stessa. Nel caso

il processo venga interrotto per via di errori, oppure volontariamente è

necessario eliminare manualmente il contenuto della directory di output

(directory del sito web) prima di ripetere le operazioni di creazione.

7. Al termine, chiudere il pannello di progressione usando il pulsante Do-

ne. L’utente potrà consultare la cronologia delle operazioni controllando

eventuali messaggi d’errore. Se questi non sono presenti la creazione è

avvenuta con successo.

71

Manuale d’uso

Esempio di log senza errori:

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

Web appl icat ion : STATIC

Start time : 1 Jul 2009 13:40:34

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

Copy lectures : OK

Previews videos : OK

Stat ic notes : OK

Zip lectures : OK

Post f i l e web appl icat ion : OK

Create web appl icat ion : OK

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

end time : 1 Jul 2009 13:40:39

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

Web appl icat ion : DYNAMIC

Start time : 1 Jul 2009 13:43:13

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

Copy lectures : OK

Previews videos : OK

Xml notes : OK

Password f i l e

(un = admin , psw = admin ) : OK

Post f i l e web appl icat ion : OK

Create web appl icat ion : OK

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

end time : 1 Jul 2009 13:43:33

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

Aggiunta di nuove lezioni

Per l’aggiunta di nuove lezioni si fa riferimento allo stesso processo usato per

la creazione: si copia il nuovo materiale ricreando l’intera struttura dell’appli-

cazione web, lasciando però inalterato il contenuto delle lezioni già presenti

nel sito.

5.3.2 Modifica dell’applicazione web

Gli strumenti di modifica dell’applicazione web variano a seconda se si tratta

di un’applicazione statica o dinamica.

Per modifica dell’applicazione web si intente:

• Aggiunta e/o modifica di note testuali alle lezioni: ad ogni le-

72

5.3 Funzionalitá

zione può essere associato un testo (nota) che potrà essere aggiunto o

modificato dal docente del corso.

• Modifica della grafica del sito (tramite fogli di stile CSS).

Nel caso si utilizzi l’applicazione web dinamica le modifiche possono

essere apportate direttamente dall’applicazione stessa, attraverso una sezio-

ne di amministrazione.

Figura 5.10: pannello Manager (WebApp)

Per modificare l’applicazione web statica si fa riferimento a un pannel-

lo integrato in LODE Web (Figura 5.10), il quale presenta due aree: una per

modificare le note (Editor notes) e l’altra per la modifica della grafica (Css).

Modifica delle note per l’applicazione web statica

Le note di un’applicazione web statica sono salvate in un’apposita directory

tramite dei file HTML formattati adeguatamente. Ne esiste uno per ogni nota

e quindi uno per ogni lezione. Il pannello per la modifica (Editor notes) (Fi-

gura 5.11) riporta in forma tabellare la lista delle note e permette, mediante

un editor appositamente creato, di modificarne il loro contenuto.

Per la modifica:

73

Manuale d’uso

Figura 5.11: Pannello di modifica delle note

1. Selezionare la directory contenente il materiale di un corso (Course

Dir).

NB: la directory deve contenere: /Disribution, /Acquisition, COURSE.XML.

2. Selezionare la directory contente il sito web statico (già creato in prece-

denza) (Web dir).

3. Cliccando sul pulsante Show/Refresh verranno visualizzate, nell’area

risultati, tante righe quanti sono i file HTML relativi alle note.

Si abiliteranno, inoltre, due ulteriori pulsanti: View index page e Edit

note.

• View index page: permette all’utente di visualizzare la index

tramite il browser di default.

74

5.3 Funzionalitá

• Edit note: permette di avviare l’editor per la modifica della nota.

4. Selezionare una riga dalla tabella.

Se non vi sono incoerenze o errori nel file HTML l’applicazione visua-

lizzerà il contenuto della nota selezionata con alcune informazioni sul

file.

5. Cliccare dunque sul pulsante Edit note che avvierà un editor di pa-

gine HTML (Figura 5.12), attraverso il quale sarà possibile modifica-

re il contenuto del file applicando al testo diverse formattazioni, colori,

dimensioni ecc.

Figura 5.12: Editor di testo per le note

6. Cliccare sul pulsante Save dell’editor di testo per salvare le modifiche.

7. Cliccare sul pulsante Show/Refresh per aggiornare la tabella con le

ultime modifiche.

Modificare la grafica dell’applicazione web

Per modificare la grafica dell’applicazione web si utilizza il pannello dedicato

(Css)(Figura 5.13) che mette a disposizione degli strumenti per la modifica del

codice CSS. Questo può essere fatto scrivendo direttamente il codice oppure

utilizzando un Editor di CSS.

75

Manuale d’uso

Figura 5.13: Pannello di modifica della grafica

Per modificare la grafica:

1. Selezionare la directory contenente il materiale di un corso (Course

Dir).

NB: la directory deve contenere: /Disribution, /Acquisition, COURSE.XML.

2. Selezionare la directory contente il sito web statico (già creato in prece-

denza) (Web dir).

3. Cliccare sul pulsante Show/Refresh per visualizzare la pagina CSS del

sito nell’apposita area di testo.

4. Modificare il codice CSS: è possibile agire direttamente sul codice, per

chi ha familiarità con questo linguaggio, oppure creare un nuovo sti-

le cliccando sul pulsante New Css.... Nel secondo caso verrà avviato

l’editor di CSS (vedi paragrafo 5.3.3).

76

5.3 Funzionalitá

5. Apportare le modifiche cliccando sul pulsante Save. É possibile visio-

narle tramite il pulsante Show index page.

NB: accanto al pulsante Save vi è un’area di notifica che avviserà l’utente

se le operazioni di modifica del documento sono andate a buon fine.

6. Ad ogni nuova modifica è bene aggiornare la pagina tramite il pulsante

Show/refresh .

5.3.3 Uso dell’editor di Cascading Style Sheet

Un normale editor di testo può essere più che sufficiente per scrivere il codice

dei CSS. Tuttavia, usare un editor specifico presenta parecchi vantaggi, uno

di questi è che permette all’utente di creare la propria grafica del sito, senza

che conosca il codice che compone i fogli di stile CSS.

Questo editor permette di modificare alcuni parametri grafici specifici per

l’applicazione web.

Struttura dell’editor

L’editor, pur essendo utilizzato in diversi contesti dell’applicazione (pannello

di creazione, modifica, ecc.), rimane sempre con la stessa struttura. È suddi-

viso in una parte di preview e in una che permette di scegliere, modificare e

creare il proprio foglio di stile.

L’utente disporrà di una galleria di cinque stili precostruiti, ogni stile po-

trà essere selezionato tramite cinque componenti grafici (JcheckBox) e per

ognuno sarà possibile visualizzare una preview della pagina.

Un pannello di pulsanti (Figura 5.14) facilità la creazione del proprio foglio

di stile.

In ordine elencherò i vari pulsanti e il loro utilizzo:

77

Manuale d’uso

Figura 5.14: Pannello pulsanti

• Select Css...: tramite questo pulsante è possibile aggiungere alla galle-

ria un foglio di stile esterno che prenderà il nome del file stesso.

• New Css... : questo pulsante avvia un wizard che permette di creare

il proprio foglio di stile personalizzato mediante una procedura guidata.

L’utilizzo di questa procedura verrà specificata nel paragrafo seguente.

• View HTML : questo pulsante mostrerà il codice della pagina index,

specificando la struttura dei tag HTML (Figura 5.15).

Questa opzione può essere utile per chi volesse creare il proprio docu-

mento CSS da codice, senza utilizzare la creazione guidata.

• View result page : cliccando su questo pulsante sarà possibile visua-

lizzare l’anteprima della pagina tramite il browser di default.

78

5.3 Funzionalitá

Figura 5.15:

Creare un nuovo stile grafico

Per la creazione di un nuovo stile si può utilizzare una piccola applicazio-

ne guidata (wizard) accessibile cliccando sul pulsante New Css... presente

sull’interfaccia principale dell’editor.

Grazie a due pulsanti (next, back) l’utente potrà utilizzare, tramite una

serie di passi successivi, quattro pannelli che permettono di scegliere alcune

proprietà grafiche della pagina.

La scelta delle varie opzioni grafiche viene facilitata grazie a un’anteprima

situata nella parte destra di ogni pannello.

79

Manuale d’uso

Descrizione dei pannelli:

1. Pannello per la modifica delle proprietà della pagina (Figura 5.16): per-

mette di modificare una serie di opzioni generali per la pagina come:

l’immagine di backgroud, il colore di sfondo, il colore del container, l’ag-

giunta dei bordi per il contaier, il font del carattere e l’allineamento del

testo.

Figura 5.16: Pannello CSS 1

2. Pannello per la modifica delle proprietà della tabella (Figura 5.17): per-

mette di modificare alcune proprietà grafiche della tabella come: il co-

lore di backgroud, il font, il colore del testo, l’aggiunta del bordi e l’alli-

neamento del testo.

3. Pannello per la modifica di altri aspetti grafici (Figura 5.18): permette

di migliorare ulteriormente l’aspetto della pagina modificando: il colore

80

5.3 Funzionalitá


dei link (link color, link:hover color), il colore di sfondo per le righe della

tabella (table_row:hover color), i bordi delle righe, il font e il colore del

testo.

4. Pannello dei risultati della pagina css (Figura 5.19): viene generata la

pagina CSS grazie ai parametri inseriti attraverso i pannelli precedenti.

Il codice viene visualizzato in un’area di testo modificabile. È possibile

scegliere se accettare le modifiche o annullarle usando i pulsati Ok e

Cancel.

Il nuovo foglio di stile verrà aggiunto alla galleria con il nome MyCss.css.

81

Manuale d’uso



82

5.3 Funzionalitá

5.3.4 Uso dell’applicazione web

Interfaccia web

L’applicazione web, indifferentemente che sia statica o dinamica, è composta

da una pagina principale (nome_corso_index.html o nome_corso_index.jsp)

che permette la visualizzazione delle varie lezioni sotto forma tabellare (Fi-

gura 5.20).

Figura 5.20: Tabella delle lezioni

La tabella delle lezioni presenta le seguenti informazioni:

• Progressivo della lezione.

• Data di svolgimento della lezione (Date).

• Titolo della lezione (Title).

• Link per il download dei video e del materiale (Dowload).

• Eventuali note (Notes).

• Tempo d’esecuzione totale del video (Time).

• Tag Cloud grafica contenente le parole più usante all’interno delle slides

(Contents, Tag Cloud).

83

Manuale d’uso

• Link per la galleria delle slides (Image from slide).

• Link per visualizzare le anteprime dei video (Image from video).

• Vari link per scaricare il materiale aggiuntivo e le slides (Slide Sour-

ces).

L’uso dell’applicazione web statica

Nell’applicazione web statica, oltre alla pagina principale, non vi sono altre

sezioni particolari.

Le note vengono salvate tramite file HTML e per il download del materiale

multimediale esistono tanti archivi quante sono le lezioni caricate nel sito.

Per scaricare una lezione basterà cliccare sull’apposito link (download) per

avviare il download dell’archivio.

L’uso dell’applicazione web dinamica

L’applicazione web dinamica, a differenza di quella statica, gestisce la visua-

lizzazione delle note dinamicamente attraverso un file XML, crea dinamica-

mente gli archivi per il download e presenta una sezione di amministrazione

del sito.

Download degli archivi Qualora un utente voglia scaricare il materiale

multimediale di una lezione dovrà cliccare sui link appositi (download) nella

tabella della pagina index. Ogni link richiama una servlet che ha il compito di

comprimere il materiale multimediale e, al termine delle operazioni, metterlo

a disposizione dell’utente. Durante la fase di compressione verrà visualizzata

una pagina web di attesa che mostrerà un conto alla rovescia indicativo e una

barra di progressione.

84

5.3 Funzionalitá

Amministrazione Solo l’amministratore, che possiede i dati di autentica-

zione, potrà accedere a questa sezione.

Login Per poter accedere alla sezione di amministrazione è necessario

cliccare sul link a fondo pagina Admin, verrà visualizzato un form di login

(Figura 5.21) dove poter inserire il proprio username e la password.

Figura 5.21: Form di login

Nel caso vengano inseriti dati di autenticazione errati l’utente verrà avvi-

sato tramite un messaggio d’errore.

Menu Nella parte di amministrazione è possibile navigare tramite un

menu (Figura 5.22) che presenta diverse opzioni che verranno descritte in

seguito.

Figura 5.22: Menu, area amministrazione

85

Manuale d’uso

Modifica delle note È possibile accedere alle pagine per la modifica

delle note delle lezioni cliccando sui link EDIT NOTE o EDIT ALL NOTE:

• EDIT NOTE: visualizzerà una pagina web dinamica contenente una

tabella con tante righe quante sono le lezioni, specificando : il titolo

della lezione, il testo della nota e in fine un link (EDIT) per accedere

alla pagina di modifica (Figura 5.23).

Figura 5.23:

Cliccando sul link EDIT sarà possibile modificare il testo della nota gra-

zie a un “visual HTML editor” (FCK editor, Figura 5.3.4) che mette a

disposizione svariati stili e formattazioni testuali.

Figura 5.24: FCK Editor

NB. : È possibile che l’editor non sia compatibile con alcune versioni di

browser (esempio: alcune versioni di Opera), per questo, all’inizio della

pagina, viene testata la compatibilità.

Per apportare le modifiche alla nota è sufficiente cliccare sul pulsante

86

5.3 Funzionalitá

Save. Al termine delle operazioni verrà visualizzata una pagina che

riporterà i risultati.

• EDIT ALL NOTE : permette di modificare tutte le note del corso da

una singola pagina dinamica, utilizzando un unico editor FCK.

Questa opzione può essere utile nel caso si voglia modificare contem-

poraneamente più note di più lezioni o si voglia avere una panoramica

generale di tutte le note salvate.

Modifica della grafica del sito La grafica del sito può essere modifi-

cata in qualsiasi momento dall’amministratore grazie a una pagina dedicata,

alla quale è possibilie accedere cliccando sul link EDIT CSS del menu.

La pagina offre una lista di cinque CSS che l’amministratore potrà sce-

gliere per il proprio sito.

Cliccando su ognuno dei cinque stili, la grafica cambierà in tempo reale

dando la possibilità all’utente di vedere un’anteprima.

Tramite il pulsante Save sarà possibile applicare la nuova veste grafica

al sito.

Modifica password amministratore L’amministratore, una volta ef-

fettuato il login, può cambiare i propri dati di autenticazione tramite la pa-

gina accessibile dal link CHANGE PASSWORD. Un form (Figura 5.25) per-

mette di modificare la password usando i campi: Old password, New pas-

sword e Confirm new Password.

Attraverso il pulsante Send sarà possibile apportare le modifiche alla

password, dopo opportuni controlli di correttezza sui campi inseriti.

NB: il file contenente l’username e la password dell’amministratore, pre-

sente nella directory WEB-INF dell’applicazione web, potrà essere modifica-

87

Manuale d’uso

to solamente tramite questa procedura, oppure accedendovi direttamente sul

web-server.

Figura 5.25: Form per la modifica della password

88

Capitolo 6

Conclusioni

89

Conclusioni

Dopo una prima indagine sul contesto dove l’applicazione doveva inserirsi

e quindi uno studio del progetto LODE legato al web, sentite anche le richie-

ste del docente, ho deciso di implementare un’applicazione ad hoc sviluppan-

do i punti principali dell’analisi che vanno dai requisiti funzionali a quelli

non-funzionali, fino alla definizione di diagrammi UML per la modellazione

concettuale.

Nella prima fase progettuale ho definito le linee essenziali della struttura

del sistema, in funzione ai requisiti.

Il primo disegno del progetto comprendeva solamente il processo principa-

le, il processo di creazione, nelle versioni seguenti invece, sono state affiancate

altre due funzionalità: la modifica dell’applicazione e l’editor di CSS.

L’editor di CSS è uno strumento aggiuntivo che facilita la personalizzazio-

ne dell’applicazione web, introducendo al suo interno strumenti per miglio-

rare l’usabilità e le caratteristiche user friendly, fornendo procedure guidate

(wizard) predisposte per gli utenti inesperti.

La prima versione dell’applicazione non presentava nessuna interfaccia

grafica, le operazioni venivano effettuate interamente da linea di comando.

L’introduzione delle grafica ha favorito l’innalzamento del livello di usabili-

tà del software e l’aumento dell’automazione dei vari processi. Ho pensato

di sviluppare la parte di esecuzione separata dalla parte grafica, attraverso

componenti grafici l’utente può specificare le varie opzioni e gli inputs per i

vari processi che, essendo parametrizzati, possono essere eseguiti con facilità.

La fase di implementazione dell’applicazione è stata preceduta dalla ricer-

ca di informazioni e dallo studio di materiale relativo ai linguaggi di program-

mazione che ho utilizzato e delle ultime tecnologie implicate nel progetto.

Ho scelto un linguaggio orientato ad oggetti come java perchè permette

un’alta interagibilità con altre tecnologie, grazie alla vastità di librerie stan-

90

dard di cui è dotato, inoltre consente la realizzazione di applicazioni web

grazie a strumenti per la programmazione lato server.

Nell’ultima fase, la fase di collaudo, ho cercado di effettuare alcuni test

per verificare il corretto funzionamento dell’applicazione prendendo in esa-

me diversi corsi universitari che presentavano anomalie nella produzione dei

contenuti multimediali. Il sistema ha reagito correttamente presentando ro-

bustezza: un corretto funzionamento anche a seguito di errori e/o situazio-

ni impreviste, non contemplate dalle specifiche. Ho sviluppato l’applicazio-

ne in modo che ogni errore venga rilevato e visualizzato attraverso compo-

nenti grafici, permettendo così all’utente di conoscere quali fasi del processo

presentano criticità.

L’applicazione potrà essere sottoposta a sviluppi futuri che vedranno l’in-

troduzione di nuove funzionalità o la modifica di quelle esistenti, alcune delle

possibili migliorie potranno essere: la modifica del sistema di autenticazione

all’amministrazione del sito dinamico, migliorie per quanto riguarda la visua-

lizzazione delle pagine web, l’aumento della portabilità su più sistemi operati-

vi, l’introduzione di un metodo per modificare i pattern di cancellazione degli

archivi, e altri.

In conclusione l’applicazione LODE Web soddisfa tutti i requisiti posti nel-

la fase di analisi sviluppando le funzionalità richieste con risultati soddisfa-

centi.

Potrà essere utilizzata dai docenti o dai responsabili dei vari corsi che

conoscano e abbiano già utilizzato il sistema LODE e le sue funzionalità.

L’applicazione web che viene generata è abbastanza flessibile e può essere

integrata all’interno di altri sistemi che rispettino le caratteristiche hardware

e software di base definite da questa applicazione. La portabilità è infatti uno

dei requisiti fondamentali di questo progetto, l’utente deve essere posto nella

91

Conclusioni

condizione di poter scegliere l’applicazione web più idonea alle sue esigenze,

pur tenendo conto delle risorse disponibili e dell’ambiente d’esecuzione.

92

Bibliografia

[1] Wikipedia: Wikipedia, the free encyclopedia.[Online]

http://it.wikipedia.org/.

[2] Wikipedia: Swing (Java). Wikipedia, the free encyclopedia. [Online]

http://it.wikipedia.org/wiki/Swing_(Java).

[3] Wikipedia: VLC media player. Wikipedia, the free encyclopedia. [Online]

http://it.wikipedia.org/wiki/VLC_media_player.

[4] VideoLAN’s Wiki: VideoLAN’s Wiki, The reference documentation and tips on

VideoLAN’s projects.. [Online]

http://wiki.videolan.org/Main_Page.

[5] Chiarelli, Andrea: Guida XML di base. Html.it [Online]

http://xml.html.it/guide/leggi/58/guida-xml-di-base/.

[6] Carrì, Antonio: Guida Application server. Html.it [Online]

http://server.html.it/guide/leggi/102/guida-application-server.

[7] –: Apache Tomcat 6.0. Apache Tomcat Documentation [Online]

http://tomcat.apache.org/tomcat-6.0-doc/.

[8] Congiustì, Pasquale: Guida J2EE. Html.it [Online]

http://java.html.it/guide/leggi/136/guida-j2ee/.

[9] Congiustì, Pasquale: Creare una tag cloud. Html.it [Online]

http://java.html.it/articoli/leggi/2509/creare-una-tag-cloud/.

93

http://it.wikipedia.org/

http://it.wikipedia.org/wiki/Swing_(Java)

http://it.wikipedia.org/wiki/VLC_media_player

http://wiki.videolan.org/Main_Page

http://xml.html.it/guide/leggi/58/guida-xml-di-base/

http://server.html.it/guide/leggi/102/guida-application-server

http://tomcat.apache.org/tomcat-6.0-doc/

http://java.html.it/guide/leggi/136/guida-j2ee/

http://java.html.it/articoli/leggi/2509/creare-una-tag-cloud/

BIBLIOGRAFIA

[10] c©Sauron Software: Manuale di cron4j 2.0. Sauron Software 2007 - 2009

[Online]

http://www.sauronsoftware.it/projects/cron4j/manual.php.

[11] Lamanna, Cesare: Guida CSS di base. CSShtml.it [Online]

http://css.html.it/guide/leggi/2/guida-css-di-base/.

[12] Cooper, Mendel: Guida avanzata di scripting Bash. PLUTO Project [Online]

http://www.pluto.it/files/ildp/guide/abs/index.html.

94

http://www.sauronsoftware.it/projects/cron4j/manual.php

http://css.html.it/guide/leggi/2/guida-css-di-base/

http://www.pluto.it/files/ildp/guide/abs/index.html

UN SISTEMA PER LA PUBBLICAZIONE AUTOMATICA VIA...

Documents

Transcript of UN SISTEMA PER LA PUBBLICAZIONE AUTOMATICA VIA...