Introduzione
UNIVERSITÀ DEGLI STUDI DI SIENA
FACOLTÀ DI INGEGNERIA
Corso di Laurea in Ingegneria delle Telecomunicazioni
GATEWAY APPLICATIVO PER IL
PORTING DI CONTENUTI E-LEARNING
WEB BASED SU PIATTAFORMA DIGITALE
TERRESTRE
Relatore:
Chiar.mo Prof. Giuliano Benelli
Correlatore:
Ing. Alessandro Nieto
Tesi di Laurea di
Domenico Beatrice
Anno Accademico 2004 - 2005
Introduzione
Introduzione
La televisione è il mezzo di diffusione dell’informazione di uso più familiare per
qualsiasi fascia di utenza grazie soprattutto al basso costo ed al carattere “user-friendly”
degli apparati disponibili sul mercato. La nascita della televisione digitale terrestre
rappresenta un ulteriore svolta sia per il tipo di contenuti che possono essere forniti che per
il modo in cui essi vengono erogati. Grazie alla possibilità di utilizzare il canale di ritorno
bidirezionale viene introdotta poi quella componente di interattività indispensabile alla
diffusione di servizi più sicuri e con contenuti personalizzati. Il bacino di utenza dei servizi
riesce in tal modo a raggiungere quella parte della popolazione poco familiare con l’utilizzo
del computer e quindi ancora lontana dal prendere dimestichezza con Internet come mezzo
di apprendimento.
L’obiettivo di questo lavoro di tesi è quello di mostrare come sia possibile
diffondere con maggiore penetrazione attraverso il mezzo televisivo, utilizzando la
piattaforma DVB-MHP, contenuti informativi originariamente disponibili unicamente
attraverso il Web.
A questo scopo si è utilizzato il corso “ECDL-2000 La patente europea del
computer” disponibile sulla piattaforma di formazione a distanza dell’Università degli Studi
di Siena riuscendo a riproporlo, in modo opportunamente adattato, sul terminale televisivo.
L’ E-Learning passa così dal computer alla televisione, diventando T-Learning.
Il ‘porting’, cioè il trasporto di contenuti e funzionalità, di servizi dal mondo Web
alla Tv digitale interattiva è un’operazione piuttosto elaborata, in quanto richiede uno
studio di fattibilità molto accurato in grado di soddisfare i giusti compromessi tra la
complessità del servizio ed i limiti imposti dallo standard alla base delle applicazioni client.
Buona parte del lavoro si è infatti concentrata sull’analisi dei contenuti, in modo da
produrre un modello XML in grado di mantenere intatto tutto il contenuto informativo del
corso nonché le informazioni per la navigazione dell’utente tra i vari moduli e unità
elementari. Inoltre, nella prospettiva di erogazione del servizio in multicanalità è stato
scelto il linguaggio XHTML come standard per la rappresentazione dei contenuti, visto che
ad oggi molti dispositivi integrano microbrowser a supporto di tale formato. Tale modalità
di formattazione dei contenuti rende inoltre compatibile il servizio con le successive
Introduzione
implementazioni dello standard MHP che dalla versione 1.1 includerà un browser XHTML
parallelo alla Virtual Machine per l’esecuzione di Xlet Java.
Il servizio è caratterizzato da un’interfaccia TV che permette l’autenticazione
dell’utente a mezzo username e password e l’accesso al servizio. Tramite i tasti del
telecomando previsti dallo standard è possibile navigare tra i vari corsi e singoli moduli, i
cui contenuti vengono prelevati direttamente dalla piattaforma FAD originale attraverso il
gateway applicativo realizzato in tecnologia servlet JAVA che gestisce la navigazione
dell’utente e si occupa del filtraggio delle informazioni e della loro traduzione dal formato
HTML a XHTML. L’applicativo MHP è stato sviluppato utilizzando l’authoring tool
Cardinal Studio Professional 4.0 esteso con opportuni componenti sviluppati in tecnologia
JavaBean. Il gateway applicativo invece è costituito da una servlet Java caricata su server
Apache Tomcat. I dati necessari alla gestione della sessione, della cache e della navigazione
vengono immagazzinati in un database MySQL. Per la fase di test della messa on-air si è
fatto uso degli apparati di simulazione presenti in laboratorio: Cardinal Playout Compact,
modulatore DVB-T, Up Converter, Set Top Box e Tv.
L’applicazione client eseguita sul Set Top Box comunica attraverso richieste HTTP
di tipo POST con il gateway applicativo, che sulla base delle interrogazioni dell’utente
identifica la sua posizione nella logica del corso (profili, corsi, sezioni, moduli, lezione),
quindi restituisce le corrispondenti informazioni XHTML ottenute prelevando e filtrando i
contenuti direttamente dalla piattaforma FAD. L’operazione di filtraggio consiste di una
prima fase di ‘pulizia’ del codice HTML il cui risultato well-formed viene sottoposto ad una
trasformazione XSLT per generare l’output corretto XHTML. L’estensione JavaBean
sviluppata per l’applicazione client utilizza istruzioni in sintassi XPath per recuperare i
contenuti e restituirli ai componenti grafici che si occupano della loro presentazione.
Ringraziamenti
Si sta come d’autunno
sugli alberi le foglie
(Giuseppe Ungaretti)
A mio padre Bruno, ucciso da un male tanto
malvagio quanto l’indifferenza che l’accompagna:
la Sclerosi Laterale Amiotrofica.
Ringraziamenti
A mia madre Assunta e mio fratello Luigi.
I miei più profondi ringraziamenti vanno a tutti
coloro che mi sono stati vicino in questo
travagliato periodo della mia vita.
Un ringraziamento particolare va al prof.
Giuliano Benelli che, nonostante le mie
incertezze, ha creduto in me.
Indice
Indice
Indice
6
Indice delle figure
1
Capitolo 1
1
La Tv Digitale: Gli standard DVB ed MHP
1
1.1
Una svolta importante: la Tv digitale
1.1.1 Background storico e tendenze future per la DTV
1.1.2 Sviluppi Globali della Televisione Digitale Terrestre
1.1.2.1 DTV negli Stati Uniti d’America
1.1.2.2 DTV in Europa
1.1.2.3 DTV in Giappone
1
2
3
3
4
4
1.2
Lo standard DVB
1.2.1 Specifiche
1.2.2 MPEG-2: Codifica audio-video e multiplazione
1.2.3 La compressione del segnale video
1.2.4 La codifica audio
1.2.5 Elementary Stream
1.2.6 Concetti e terminologia DVB
1.2.7 Gli standard di livello fisico
5
6
6
8
10
10
13
15
1.3
Lo standard MHP
1.3.1 Architettura di base
1.3.2 Profili MHP
1.3.3 Protocollo di trasporto
1.3.4 Protocolli del canale interattivo MHP
1.3.5 Tipi di contenuti MHP
1.3.6 Ciclo di vita di un’applicazione
1.3.7 Broadcast di applicazioni e dati: DSM-CC Object Carousel
1.3.8 Architettura di fruizione di un servizio interattivo MHP
17
18
19
20
21
21
22
24
26
Capitolo 2
28
La formazione a distanza
28
2.1
L’e-learning come fenomeno sociale e di mercato
2.1.1 La storia della formazione a distanza
2.1.2 Cenni di storia
2.1.3 Campi di applicazione
2.1.4 I Modelli e le Teorie Cognitive
28
29
30
31
31
2.2
Gli standard dell’e-learning
2.2.1 SCORM: Advanced Distributed Learning (ADL) Iniziative
2.2.2 IEEE Learning Technology Standards Committee (LTSC)
34
35
36
Indice
2.2.3
2.2.4
2.2.5
2.2.6
IMS (Instructional Management System) Global Learning Consortium
AICC – Aviation Industry CBT Committee
Prometeus
The Dublin Core Metadata Iniziative
36
37
37
38
2.3
Contenuti universalmente riutilizzabili
2.3.1 SCORM
2.3.2 Da dove deriva
2.3.3 Com’è organizzato
2.3.4 Content Aggregation Model (Modello di aggregazione dei contenuti)
2.3.5 Il “Run Time Environment” (ambiente di erogazione)
2.3.6 Gli elementi minimi di contenuto
2.3.6.1 Gli Asset
2.3.6.2 Lo SCO(Shereable Content Object)
2.3.7 Il courseware
39
39
40
41
41
42
43
43
43
44
2.4
DVB-MHP e FAD: le potenzialità
2.4.1 Risultati temporanei
2.4.1.1 Conclusioni chiave
2.4.1.2 Problemi di strategia di Learning
2.4.1.3 Il ruolo della Tv interattiva nel Learning
2.4.1.4 Problemi tecnici
2.4.1.5 Tv personalizzata
2.4.1.6 Problemi di mercato inerenti allo sviluppo di servizi di Learning
2.4.1.7 Tv in modo personalizzato
2.4.1.8 I costi di accesso al learning attraverso la Tv digitale
2.4.1.9 Apprendimento e problemi pedagogici
2.4.2 Raccomandazioni
2.4.2.1 Raccomandazioni strategiche
2.4.2.2 Ricerca sulle tecnologie del learning
45
47
47
47
48
49
49
50
51
51
51
52
52
53
Capitolo 3
54
Le scelte progettuali
54
3.1
Fase di specifica di un’applicazione per la Tv interattiva
3.1.1 Il nostro approccio
54
55
3.2
Studio della piattaforma di e-learning dell’Università degli Studi di Siena
3.2.1 Il sito FAD.UNISI.IT
3.2.2 Architettura del sito
3.2.3 Organizzazione dei contenuti
3.2.4 Strategie di interfacciamento
3.2.4.1 Il gateway applicativo di interfaccia
3.2.4.2 Vantaggi e svantaggi dell’approccio
3.2.5 Pianificazione dell’iter di sviluppo
3.2.6 Tecnologie utilizzate
3.2.7 Cardinal Studio Professional 4.0
3.2.8 Le librerie utilizzate lato client
3.2.8.1 Caratteristiche generali
56
56
57
59
61
62
63
64
66
68
69
70
Indice
3.2.8.2 XPath
3.2.9 Le librerie utilizzate la server
71
72
Capitolo 4
73
Sviluppo dell’applicazione client
73
4.1
La scelta dei contenuti
4.1.1 L’area d’interesse
73
74
4.2
75
Realizzazione dello scheletro di interfaccia
4.3
Scelta del formato di scambio dati
4.3.1 Formato di scambio dati XML
4.3.2 La sintassi scelta
76
76
77
4.4
Sperimentazione con file XML residenti
4.4.1 I componenti DataSet
79
82
4.5
Il componente T-Learning
4.5.1 Proprietà e funzionamento
83
83
4.6
Organizzazione dell’applicazione Client
4.6.1 Suddivisione in stati logici
87
87
4.7
Realizzazione dell’interfaccia grafica
88
4.8
Sistemazione dei contenuti nell’interfaccia
89
4.9
Il funzionamento in generale dell’applicazione
93
4.10 Dettagli di funzionamento
4.10.1
La procedura di autenticazione
4.10.2
I profili
4.10.3
La selezione di un profilo
4.10.4
Corsi attivi
4.10.5
La selezione di un corso
4.10.6
Sezioni, moduli e modulo
4.10.7
La selezione di una sezione, di un modulo e di una lezione
4.10.8
Il corso
4.10.8.1 Il componente imageDisplay
4.10.8.2 La visualizzazione di una lezione
4.10.8.3 La prima lezione
4.10.8.4 La selezione di un approfondimento
4.10.8.5 La gestione della visualizzazione di più immagini contestuali
94
96
97
98
99
100
101
102
103
104
106
106
108
110
Capitolo 5
113
Sviluppo dell’applicazione server
113
5.1
Logica Client-Server
5.1.1 Interazione Browser Web-FAD
113
115
5.2
117
Considerazioni pre-sviluppo
Indice
5.3
Le librerie utilizzate
118
5.4
Il dialetto XSL
118
5.5
Lo sviluppo e le strategie di sviluppo
5.5.1 La tecnologia Java Servlet
119
120
5.6
Il funzionamento della Servlet
5.6.1 Il TASK di Login
5.6.1.1 Le operazioni del TASK = Login
5.6.2 Il TASK profilicorsiattivi
5.6.2.1 Le operazioni del TASK profilicorsiattivi
5.6.3 I TASK sezioni, moduli e modulo
5.6.4 Il TASK Lezione
5.6.4.1 Le operazioni per il recupero della pagina precedente
5.6.4.2 Le operazioni del TASK Lezione
120
121
121
125
125
126
127
127
127
5.7
La scrittura dei fogli di stile
5.7.1 L’elenco dei corsi
5.7.2 Le sezioni
5.7.3 I moduli
5.7.4 L’elenco delle lezioni
5.7.5 La singola lezione
130
130
130
131
132
132
5.8
133
134
5.9
L’interfacciamento finale
5.8.1.1 Esempio di modifica post-produzione dell’applicazione finale
Conclusioni e sviluppi futuri
Bibliografia
135
137
Indice delle figure
Indice delle figure
Figura 1.Gli attori del mondo DVB ............................................................................................... 5
Figura 2.Combinazioni di profili e livelli nello standard MPEG-2[2] ....................................... 7
Figura 3.Schema del GOP standard per l'MPEG-2..................................................................... 9
Figura 4.Flusso dati Transport Stream......................................................................................... 13
Figura 5.Singolo Transport Stream Packet.................................................................................. 13
Figura 6. Architettura di fruizione di un servizio interattivo per la Tv digitale...................... 27
Figura 7. L'organizzazione dello standard SCORM................................................................... 41
Figura 8. La visione di un sapere globalmente distribuibile ed accessibile ............................. 45
Figura 9. L'uomo al vertice del mondo informativo .................................................................. 50
Figura 10. Logica della FAD.......................................................................................................... 57
Figura 11. La pagina di benvenuto della FAD ............................................................................ 57
Figura 12. Architettura della piattaforma di formazione a distanza dell'Università di Siena 58
Figura 13. Area (rettangolo) contente la parte di informazione più significativa ................. 59
Figura 14. Area (rettangolo) contenente la parte di informazione più significativa ............. 60
Figura 15. Schematica rappresentazione del funzionamento della soluzione scelta.............. 62
Figura 16. Implementazione della soluzione proxy-server........................................................ 64
Figura 17. L'ambiente di testing presente in laboratorio di TLC ............................................. 67
Figura 18. Le potenzialità del tool di authoring Cardinal Studio Professional....................... 69
Figura 19. L'area di interesse.......................................................................................................... 73
Figura 20. Scheletro di interfaccia................................................................................................. 75
Figura 21. Albero logico rappresentante la suddivisione in sottosezioni dell'area d'interesse
.................................................................................................................................................. 77
Figura 22. Modello di scambio dati definito da noi ................................................................... 78
Figura 23. Logica di funzionamento del componente T-Learning nel test di
interfacciamento ..................................................................................................................... 80
Figura 24. Esempio di un generico file nel formato DSML ..................................................... 81
Figura 25. Il framework DataSet................................................................................................... 82
Figura 26. Logica di funzionamento del componente T-Learning .......................................... 86
Figura 27. Architettura del servizio .............................................................................................. 88
Figura 28. Specifiche per la trasformazione JPEG -> I-Frame................................................ 89
Figura 29. Screenshot dell'interfaccia dei profili attivati con confronto pagina del sito del
corso......................................................................................................................................... 90
Figura 30. Screenshot dei corsi attivati relativamente al profilo selezionato con confronto
pagina del sito del corso. ....................................................................................................... 90
Figura 31. Screenshot delle sezioni del corso scelto con confronto pagina del sito del corso
.................................................................................................................................................. 91
Figura 32. Screenshot dell'interfaccia dei moduli relativi alla sezione del corso scelta con
confronto con la pagina del sito del corso. ........................................................................ 91
Figura 33. Screenshot delle lezioni disponibili relativamente al modulo scelto con confronto
con la pagina del sito del corso. ........................................................................................... 92
Figura 34. Screenshot dell'interfaccia della lezione appartenente al modulo scelto con
confronto con la pagina del sito del corso ......................................................................... 92
Figura 35. Screenshot del TASK = LOGIN............................................................................... 95
Figura 36. Screenshot del TASK Profili ...................................................................................... 98
Indice delle figure
Figura 37. Screenshot TASK Corsi Attivi .................................................................................100
Figura 38. Screenshot TASK Sezioni .........................................................................................102
Figura 39. Screenshot del template in cui vengono incastonati i contenuti della lezione...103
Figura 40. Il funzionamento del componente imageDisplay..................................................105
Figura 41. Screenshot di una lezione del corso.........................................................................107
Figura 42. Screenshot di un approfondimento .........................................................................109
Figura 43. Screenshot di approfondimento con la presenza di più immagini contestuali..111
Figura 44. Finestra di visualizzazione dei log registrati dallo sniffer: header della richiesta e
della risposta Http ................................................................................................................114
Figura 45. Lo scambio di informazioni browser-FAD al primo accesso alla piattaforma .116
Figura 46. Lo scambio di informazioni browser-FAD nella fase di login dell’utente .........116
Figura 47. Lo scambio di informazioni browser-FAD nella fase di abbandono sessione..116
Figura 48. Output del TASK Login ...........................................................................................123
Figura 49. Le operazioni portate a termine nell'esecuzione del TASK Login......................124
Figura 50. Le operazioni portate a termine nell'esecuzione del TASK sezioni, moduli e
modulo...................................................................................................................................126
Figura 51. Struttura del foglio di stile per i TASK profili e corsi attivi .................................130
Figura 52. Struttura del foglio di stile per il TASK Sezioni.....................................................131
Figura 53. Struttura del foglio di stile associato al TASK moduli..........................................132
Figura 54. Struttura del foglio di stile associato al TASK modulo.........................................132
Figura 55. Struttura foglio di stile associato al TASK Lezione...............................................133
Capitolo 1
La Tv digitale:gli standard DVB ed MHP
Capitolo 1
La Tv Digitale: Gli standard DVB ed
MHP
1.1 Una svolta importante: la Tv digitale
Attualmente la televisione digitale, o DTV (Digital Television), suscita un enorme
interesse. Possiamo senza dubbio affermare che agli albori del ventunesimo secolo essa può
essere considerata come una parte integrante dell’autostrada dell’informazione che si sta
costruendo per il nuovo millennio. Le ragioni di tanto interesse sono dovute al fatto che la
televisione digitale può elargire grandi quantità di informazioni ad un costo molto basso e
ad un grandissimo numero di spettatori (utenti). Essa può essere integrata a pieno in reti di
trasmissioni completamente digitali, e gode della caratteristica di permettere compressioni
di dati che fino ad ora, con la Tv analogica erano assolutamente impensabili .
La DTV ha il vantaggio di permettere la trasmissione di un numero superiore di
programmi televisivi rispetto a quello trasmesso dalla televisione analogica e per di più
utilizzando qualunque tipo di canale (si parla infatti di multicanalità ). Si riesce a sfruttare
l’enorme vantaggio dell’informazione digitale, quello cioè di poter essere manipolata e
trattata in una maniera impossibile altrimenti utilizzando la televisione analogica. È
piuttosto facile salvare immagini digitali all’interno delle memorie di massa dei computer o
sui dischi e utilizzarle di continuo su reti digitali senza degradazione del segnale. Le
immagini possono essere ritoccate e ingrandite, compresse e salvate, trasmesse e stampate.
Sfruttando la rappresentazione delle immagini sotto forma di zeri ed uni (si parla di
rappresentazione binaria delle immagini) la televisione digitale acquisisce una grande
flessibilità nel trattare l’informazione. Il segnale televisivo, che nella forma analogica
richiede circuiti dedicati, nella forma digitale può essere mescolato o addirittura integrato
con le conversazioni telefoniche e/o i dati dei computer e quindi trasmesso su reti di
telecomunicazioni a distanti luoghi di radiodiffusione ( o di broadcasting). I programmi
televisivi possono essere immagazzinati negli hard disk dei computer e recuperati all’istante
1
Capitolo 1
La Tv digitale:gli standard DVB ed MHP
per permettere al singolo spettatore un personale video on demand. La distribuzione di
materiale multimediale (audio, video e dati) al consumatore in formato digitale crea i
presupposti per una gestione dei contenuti interamente basata sui personal computer.
Utilizzando l’hard disk di un computer è possibile salvare (quello che prima era registrare
un film con il video registratore), richiederlo, modificarlo e richiederlo nuovamente in modi
fino ad ora mai visti. Logicamente questi sviluppi costituiscono una vera e propria
rivoluzione nei confronti del broadcasting analogico.
Con lo scopo di provare e sperimentate le problematiche imposte dal nuovo
scenario che si stava prospettando per il mondo della comunicazione, molte organizzazioni
internazionali si sono messe a lavoro per risolvere problemi ingegneristici e fissare ambienti
di lavoro e standard per l’implementazione della televisione digitale[1].
1.1.1 Background storico e tendenze future per la DTV
I correnti sistemi per la televisione analogica sono basati sullo standard NTSC
(National Television Systems Committee), nato negli Stati Uniti d’America nel 1953.
Questo sistema viene utilizzato in America, Canada, Mexico, e Giappone e in molti stati del
Sud America e in Corea sin dal 1954.
Il sistema PAL (Phase Alternation Line) è una variante del NTSC ed è usato
essenzialmente in Europa, Australia e nel lontano Est in formati differenti. Ci sono altri
sistemi in uso includendo lo standard SECAM e quello basato sui satelliti, il MAC.
L’esistenza di più standard ha da sempre costituito una barriera per la trasmissione
internazionale dei servizi televisivi. Ad ogni modo tutti questi standard analogici hanno
come destino comune quello di essere sostituiti dalla nascita di standard per la televisione
digitale terrestre, dotati di meno restrizioni per la trasmissione e che permettono la
diffusione di nuovi servizi: basti pensare a canali informativi contenenti servizi internet e
sottoscrizioni a programmi.
La maggior parte dei televisori a colori usa un rapporto di rappresentazione di 4:3,
mentre alcuni ricevitori a grande schermo usano un rapporto di rappresentazione di 16:9.
Comunque la maggior parte dei broadcasters considera come univoco il rapporto di
rappresentazione adattabile ai 16:9 . È possibile offrire anche una via di mezzo di rapporto
di rappresentazione il 14:9 definito “half letterbox”. Tutti i nuovi chips digitali si trovano a
2
Capitolo 1
La Tv digitale:gli standard DVB ed MHP
bordo di unità di ricezione a basso costo che demodulano e decodificano i segnali digitali
terrestri.
Nell’era del broadcasting della TV analogica coloro che acquistavano le strutture di
trasmissione della rete terrestre erano spesso delle organizzazioni. Per ragioni
principalmente storiche, e visto il costo ingente dell’apparecchiature di rete, molti networks
sono lo stato o i capi di governo. Questa limitazione di accesso alle onde elettromagnetiche
per nuovi gestori, proteggeva dalla competizione gli operatori di rete esistenti. Proprio a
causa di questi ostacoli per molti anni i broadcasters coinvolti nelle trasmissioni terrestri
sono stati molto pochi. Ad ogni modo grazie all’avvento delle tecnologie digitali saranno
rese disponibili quantità abbondanti di banda cosi da creare grandi opportunità sia per i
fornitori di programmi e sia per coloro che realizzano i programmi. Ci sarà una divisione
ancora più marcata tra coloro che producono i programmi e coloro che li forniscono e le
pratiche tradizionali di broadcasting saranno rimpiazzate da un metodo di operare più
flessibile e competitivo[1].
1.1.2 Sviluppi Globali della Televisione Digitale Terrestre
Lo sviluppo della televisione digitale terrestre in Europa, Stati Uniti d’America, e
Giappone avviene in tempi e modi leggermente differenti. Gli organismi di
standardizzazione di questi tre paesi sono state influenzati in maniera più sostanziosa dal
lavoro portato avanti dal Moving Pictures Expert Group (MPEG) nei confronti degli
standard di codifica audio e video, informazioni di sistema, e standard di multiplexaggio.
Queste organizzazioni di standardizzazione hanno lavorato per sviluppare standard di
modulazione broadcast adattabili per il tipo di media e banda di canale già in uso all’interno
della particolare regione.
Come risultato ci sono differenze tra le modulazioni usate , per esempio in Europa
e negli Stati Uniti[1].
1.1.2.1 DTV negli Stati Uniti d’America
Nel 1987 la Federal Communication Commissions (FCC) iniziò la definizione di
uno standard adatto per la High Definition Television (HDTV) che fosse compatibile con
l’esistente standard della televisione analogica, NTSC. Nel 1992 furono proposti quattro
3
Capitolo 1
La Tv digitale:gli standard DVB ed MHP
progetti, e nel 1993 venne raggiunto un accordo tra i quattro consorzi proponenti allo
scopo di formare una Grand Alliance (GA) per completare lo sviluppo dello standard.
La GA ha specificato:
•
uno standard Dolby chiamato AC-3 per la codifica multicanale di sorgenti audio, ed
ha specificato inoltre lo standard MPEG conosciuto come MPEG-2 per la codifica delle
sorgenti audio, informazioni di sistema ed il multiplexaggio;
•
una modulazione vestigiale ad 8-livelli per il broadcasting terrestre con un payload di
19.28 Mbps per un canale broadcast con una banda di 6 Mhz.
•
un sistema per la televisione via cavo.[1]
1.1.2.2 DTV in Europa
I primi anni ’90 in Europa rappresentarono il periodo della nascita di molti progetti
per la definizione di uno standard per la regolamentazione della HDTV e con l’aiuto del
governo tedesco nel 1992 venne costituito l’European Lauching Group (ELG) che
funzionò da luogo di ritrovo per le organizzazioni interessate e presenti in Europa. Grazie
al successo dell’ELG, nel 1993 approssimativamente 80 tra broadcasters, corpi di standard,
compagnie di telecomunicazioni, industriali, ed altre organizzazioni formarono il Digital
Video Broadcasting project (DVB) siglando un memorandum di intesa.
Scelto come quartier generale l’European Broadcasting Union (EBU) e con il
supporto della European Commission, il progetto DVB ha sviluppato gli standard per il
broadcasting attraverso differenti canali come cavo, satellite e terrestre. Il progetto DVB ha
definito l’MPEG-2 come lo standard per la codifica delle sorgenti audio, video, così come
per le informazioni di sistema e per il multiplexaggio. Il progetto DVB ha specificato la
Coded Orthogonal Frequency Division Multiplexing (COFDM) come lo standard per
la modulazione del segnale digitale terrestre che è andato sotto il nome di standard DVBT[1].
1.1.2.3 DTV in Giappone
Il Giappone iniziò ufficialmente lo sviluppo della DTV nel 1994, il tutto sotto il
ministero delle poste e telecomunicazioni giapponese con la funzione di coordinatore dei
lavori. Venne adottato l’MPEG-2 per la codifica delle sorgenti e le informazioni di sistema
e fu istituito il Japanese Digital Broadcasting Expert Group (DiBEG) per formulare
4
Capitolo 1
La Tv digitale:gli standard DVB ed MHP
una strategia per il broadcasting attraverso vari mezzi. I giapponesi hanno elaborato una
variante alla COFDM per il broadcasting terrestre conosciuto come Integrated Services
Digital Broadcasting-Terrestrial, (ISDB-T)[1].
1.2 Lo standard DVB
Figura 1.Gli attori del mondo DVB
Con lo scopo di realizzare lo standard per il broadcasting di TV digitale e servizi
dati, nel 1993 è stato costituito in Europa il consorzio DVB (Digital Video Broadcasting) a
cui aderiscono più di trecento partners tra broadcasters, operatori di rete e costruttori in 35
paesi differenti. Il primo standard ratificato è proprio DVB: un sistema basato sulle
specifiche MPEG-2. Lo standard DVB definisce tutte le caratteristiche di un sistema per il
broadcasting di video digitale e dati[4].
5
Capitolo 1
La Tv digitale:gli standard DVB ed MHP
1.2.1 Specifiche
•
Specifiche a livello logico:
o Formati di compressione Audio/Video;
o Costruzione dei flussi digitali ( Transport Stream );
o Formato dei pacchetti;
o Segnalazione dei servizi;
o Incapsulamento di dati generici non A/V e di protocolli non DVB;
•
Specifiche di livello fisico:
o Specifiche sul segnale fisico (modulazione, codifica ecc…) nei vari mezzi
trasmissivi (cavo,satellite,ripetitori terrestri)[4]
1.2.2 MPEG-2: Codifica audio-video e multiplazione
MPEG-2 (acronimo di Motion Picture Experts Group) è un sistema di codifica
digitale di immagini in movimento, che permette di comprimere i dati mantenendo una
buona qualità. MPEG-2 è stato destinato al broadcast televisivo, fin dalla sua introduzione
nel 1994. Una efficiente codifica per il video interlacciato e la scalabilità sono state le
caratteristiche che hanno permesso di digitalizzare efficacemente i segnali televisivi. Grazie
all’MPEG-2 si ottengono immagini televisive di buona qualità con bit rate compresi tra 4 e
9 Megabit al secondo.
MPEG-2 è costituito da “profili” e “livelli”. I profili definiscono la modalità di
compressione utilizzata e stabiliscono di fatto il compromesso tra tasso di compressione e
costo del decodificatore. I livelli definiscono la risoluzione di immagine ed il bitrate
massimo da associare ad ogni profilo. Ci sono complessivamente 4 livelli e 5 profili le cui
caratteristiche sono riassunte nella Figura 2 alla pagina successiva. La combinazione
attualmente utilizzata dalle trasmissioni digitali per ricezione diretta impiega il cosiddetto
“main level @ main profile” MP@ML.
Descriviamo sinteticamente le caratteristiche dei livelli e dei profili dell’MPEG-2
che rappresentano la forza del sistema in quanto a flessibilità e adattabilità a varie
applicazioni. E’ sorprendente come MPEG-2 riesca a spaziare tra la più bassa risoluzione di
immagine SIF fino all’alta definizione HDTV semplicemente variando le associazioni tra
livelli e profili. I livelli previsti sono: low (basso), main (principale), high-1440 (alto-
6
Capitolo 1
La Tv digitale:gli standard DVB ed MHP
1440), high (alto). Il livello “low” corrisponde alla risoluzione più bassa come la SIF
utilizzata nell’MPEG-1; il livello “main” corrisponde alla struttura 4:2:0 fino ad una
risoluzione di 720 x 576 pixel; il livello “high-1440” è dedicato alla tv ad alta definizione
HDTV mentre il livello “high” è ottimizzato per il formato di schermo 16/9 in alta
definizione.
La descrizione dei profili è invece un po’ meno semplice di quella dei livelli in
quanto implica la conoscenza delle metodologie di base con cui opera il sistema MPEG;
tuttavia azzardiamo una sintesi riferendoci agli effetti dell’applicazione dei vari profili.
Figura 2.Combinazioni di profili e livelli nello standard MPEG-2[2]
•
Il profilo “simple” permette di semplificare notevolmente sia il codificatore di
stazione che il decodificatore di utente in quanto non utilizza la predizione di tipo
B(Bidirectional-Frame).
•
Il profilo “main” è quello che offre il miglior compromesso tra qualità e tasso di
compressione, impiega le immagini relative alle predizioni I(Intra-Frame), P(PredictedFrame), B(Bidirectional-Frame) a svantaggio dei dispositivi di codifica e decodifica che
sono più complessi.
•
Il profilo “scalable” è destinato ad applicazioni particolari dove sia necessario ad
esempio mantenere la compatibilità tra alta definizione e definizione standard oppure,
7
Capitolo 1
La Tv digitale:gli standard DVB ed MHP
riuscire ad ottenere una qualità accettabile in condizioni di ricezione difficile come potrebbe
accadere ad esempio nella televisione digitale terrestre.
•
Il profilo più elevato “high” è destinato all’alta definizione con le strutture 4:2:0 e
4:2:2.
Un ultima nota: i profili mantengono una certa compatibilità verso l’alto nel senso
che, nella fase di ricezione, i profili più alti possono decodificare i profili inferiori[2].
1.2.3 La compressione del segnale video
Per la diminuzione del segnale di ridondanza, spaziale e statistica, `e previsto l’uso
congiunto della trasformata discreta coseno (DCT), di una matrice di quantizzazione, di
uno zig-zag scan, di un codificatore RLC e di un codificatore di Huffman. L’utilizzo di tali
mezzi porta alla creazione di quello che viene chiamato I-Frame, Intra-Frame. Tale frame
conserva dimensioni ragguardevoli, e quindi risulta oneroso in termini di banda.
La ridondanza spaziale `e diminuita applicando la DCT all’immagine. Questa
tecnica viene attuata dividendo l’immagine in blocchi ai quali viene applicata la DCT in
modo da ottenere una matrice di 64 elementi ogni blocco. Questi elementi rappresentano le
frequenze delle componenti spaziali.
La ridondanza statistica viene eliminata applicando alla matrice ottenuta tramite la
DCT una matrice di quantizzazione che toglie le componenti ad alta frequenza,
impercettibili all’occhio umano. Questo tipo di quantizzazione produce una perdita di dati
irreversibile, che altera la qualità dell’immagine definitivamente. Il risultato `e una nuova
matrice che viene passata per uno zig-zag scan in modo da mettere in fila il maggior
numero possibile di 0, mentre si forma la sequenza di bit da trasmettere. La sequenza cosı
ottenuta viene poi codificata con un RLC e compressa ulteriormente da un codificatore di
Huffman.
Questo tipo di compressione porta di fatto ad un problema di non poco conto. Se
durante la trasmissione si verifica un errore la decodifica dell’immagine non `e più possibile
e questa si perde completamente. Per ovviare a questo problema, e rendere lo standard più
flessibile, è stato inserito un sistema di scalabilità del rapporto segnale rumore (SNR). E’
possibile scegliere quali bit decodificare, ad esempio solo quelli ad alta priorità, in modo da
8
Capitolo 1
La Tv digitale:gli standard DVB ed MHP
ottenere indipendentemente dal rumore sul canale un’immagine visibile anche se affetta da
rumore.
Genericamente in un flusso video molta dell’informazione trasmessa risulta essere
contenuta nel segnale precedentemente processato. E’ quindi possibile pensare di ricavare
parte del contenuto informativo dai dati già in possesso. Questo permette di trasmettere un
quantitativo di informazioni minore che sommate a quelle ottenute dal segnale gi`a
decodificato compongono l’informazione corretta o comunque non distinguibile
dall’occhio umano rispetto all’originale. Applicando questo concetto si riesce a ridurre la
ridondanza di informazione in termini temporali.
Un flusso MPEG-2 `e composto da tre tipi diversi di frame: I-frame, P-frame e Bframe.I frame di tipo I, Intra-Frame sono immagini alle quali `e stato applicato il processo
di compressione spaziale e statistico. I frame di tipo P Predicted frame sono immagini
parziali nelle quali vengono riportate solo le differenze con l’I-frame precedente. Questo
tipo di frame `e molto povero di contenuto informativo e quindi ha un onere trasmissivo in
termini di banda molto ridotto. L’immagine reale viene ricostruita a partire dall’I-frame
precedente. I frame di tipo B, Bidirectional Frame sono molto simili ai P-Frame ma
permettono la ricostruzione sia dall’I-frame precedente che da quello successivo e lo
scorrimento dei video in entrambi i sensi.
Una serie di frame indipendente dalla loro disposizione viene chiamata GOP,
Group Of Pictures.
Figura 3.Schema del GOP standard per l'MPEG-2
9
Capitolo 1
La Tv digitale:gli standard DVB ed MHP
Il GOP rappresenta l’ordine in cui i frame vengono trasportati. Come si nota dalla
Figura 3 un solo I-frame, ad alto contenuto informativo e quindi occupante molta banda in
fase di trasmissione del segnale, `e presente in un GOP standard. Questo rende la banda
necessaria alla trasmissione di un video molto minore rispetto all’invio di soli I-frame.
Tutti questi accorgimenti riescono a portare un flusso video di 270Mbps a 45Mbps.
Le alterazioni che questo forte processo di compressione porta sullo stream video sono
pressoché impercettibili all’occhio umano.
1.2.4 La codifica audio
Il bitrate caratteristico di due canali audio con una qualità CD è pari a 1,4 Mbps,
valore non elevato, ma che può arrivare a 200 Kbps senza pregiudicare la qualità, con
opportune tecniche di compressione. Queste ultime sono basate sulle caratteristiche
psicoacustiche dell’orecchio umano che percepisce meglio i toni a potenza elevata a
discapito dei toni adiacenti a potenza minore. Il criterio alla base della compressione audio
è riassumibile nel principio: “se non lo posso udire non lo codifico”. Il segnale audio
sottoposto al processo di compressione è quello con frequenze comprese tra 0Hz e 22
Khz. Ognuna delle 32 sottobande in cui viene suddiviso lo spettro viene filtrata,
quantizzata e codificata secondo le caratteristiche dell’orecchio umano. La compressione
audio relativa agli standard MPEG-2 non risulta migliorata rispetto al precedente MPEG-1,
ma permette ad esempio di inviare fino a cinque canali audio per la riproduzione di un
suono avvolgente e fino a sette canali monofonici per le applicazioni multi-lingua. Esistono
due tipi di codifica, una compatibile con l’MPEG-1 Audio e una non compatibile (AC3).
Dalla codifica risulta prodotto un segnale impacchettato insieme a tutte le informazioni
riguardanti il processo di codifica utilizzato. Tale pacchetto prende il nome di Elementary
Stream(ES).
1.2.5 Elementary Stream
Nello standard MPEG-2 Video, l’Elementary Stream nasce con lo scopo di
strutturare i dati secondo un’unica sintassi e fornire le informazioni necessarie al
decodificatore per ricostruire i frame in maniera corretta. All’interno di una sequenza va
stabilita una gerarchia di livelli:
10
Capitolo 1
La Tv digitale:gli standard DVB ed MHP
•
Sequenza;
•
Gruppo di immagini(GOP);
•
Immagini di tipo I,P,B;
•
Slice;
•
Macroblocchi;
•
Blocchi.
Tutti questi strati opportunamente organizzati formano un Elementary Stream
Video, che può essere anche considerato come uno stream continuo composto da frame
compressi e codificati insieme alle informazioni necessarie alla loro ricostruzione. L’ES
rappresenta in definitiva un flusso di bit che trasporta le informazioni destinate al decoder
audio o video per la ricostruzione fedele del segnale. L’ES costituisce l’output di ciascuno
dei due blocchi di codifica, anche se non contiene informazioni relative né alla
temporizzazione, né al sincronismo, impedendo così di fatto una ricostruzione
correttamente temporizzata. Per questo motivo l’MPEG-2 System definisce, a partire
dall’Elementary
Stream,
nuove
strutture
più
adatte
alla
trasmissione
e
all’immagazzinamento. Il primo passo è suddividere la struttura continua dell’ES in
pacchetti. Questi pacchetti prendo il nome di PES (Packetized Elementary Stream) packet.
Sono composti da una intestazione e da un campo dati, la loro dimensione è variabile e
dipende dalla particolare applicazione. Le informazioni riguardanti la temporizzazione si
trovano nel campo Header del PES visto che nel ES non sono presenti informazioni
riguardanti il tempo in cui esso viene trasmesso. In tale header si trova PTS (Presentation
Time Stamp), DTS(Decoding Time Stamp), trick time ecc… Il modello di temporizzazione
viene stabilito nell’MPEG-2 con lo scopo di sincronizzare correttamente il codificatore ed
il decodificatore, presentare in modo sincronizzato gli ES, riordinare le immagini I,P e B e
annullare i ritardi aleatori introdotti dai canali di comunicazione. Questi obiettivi vengono
raggiunti per mezzo dell’inserimento di timestamp nell’intestazione dei pacchetti PES e di
clock reference nell’intestazione dei pacchetti TS e PS ottenuti attraverso il multiplexaggio
di ogni programma. MPEG-2 ci dice che tipo di temporizzazione adottare ma non come
generare tali segnali lasciando campo libero in materia ai produttori di servizi. Per poter
generare dei programmi , MPEG-2 stabilisce come si combinano uno o più programmi ES
video e/o audio e altri dati, in uno o più stream appropriati per la memorizzazione su
11
Capitolo 1
La Tv digitale:gli standard DVB ed MHP
supporto o la trasmissione. Lo standard stabilisce pertanto un metodo di multiplexing e la
sintassi dello stream risultante. Tale metodo è chiamato “multiplexing per pacchetti”.
Questo tipo di multiplexing permette un bitrate variabile ed un bitrate costante
semplicemente variando appropriatamente la lunghezza o la frequenza dei pacchetti. Come
risultato del multiplexaggio si ottengono due tipi differenti di stream: il Transport Stream
(TS) ed il Program Stream(PS) ciascuno ottimizzato per un preciso contesto:
•
Il Transport Stream può contenere uno o più programmi TV e ognuno con la
propria base temporale indipendente.
•
Il Program Stream è simile al flusso MPEG-1, ma utilizza una nuova sintassi in
modo da fornire nuove funzionalità mantenendo però la compatibilità con il precedente.
Contiene l’equivalente di un solo programma TV e può multiplexare uno o più Elementary
Stream con una base di tempo comune.
Le strutture del PS e del TS non seguono strettamente un modello a livelli, così è
ragionevolmente possibile convertire l’uno nell’altro e viceversa grazie all’utilizzo comune
dei pacchetti PES. Per la natura del canale da noi utilizzato in questo lavoro di tesi,
parleremo essenzialmente di TS visto che rappresenta l’unità fondamentale del trasporto
informativo nel DVB. Con un multiplexaggio vengono combinati tutti i TS ottenendo
come unico risultato un unico flusso TS. L’unica restrizione imposta dallo standard per
l’ordine di ricombinazione è che sia preservato l’ordine sequenziale tra pacchetti di uno
stesso ES.
12
Capitolo 1
La Tv digitale:gli standard DVB ed MHP
Figura 4.Flusso dati Transport Stream
Figura 5.Singolo Transport Stream Packet
1.2.6 Concetti e terminologia DVB
Nella terminologia propria DVB o MPEG-2, ogni transport stream è anche
chiamato multiplex, per il fatto che consiste di un certo numero di servizi multiplexati
13
Capitolo 1
La Tv digitale:gli standard DVB ed MHP
assieme. Ogni multiplex, o flusso TS, viene trasmesso in broadcast su una singola
frequenza e solamente un multiplex può essere trasmesso su ogni frequenza. Ogni
multiplex tipicamente ha un data rate di circa 40 Mbps. I motivi di questa scelta riguardano
principalmente le limitazioni in termini di banda del canale di trasmissione. All’interno di
un multiplex, ogni gruppo di elementary stream che costituisce un singolo canale tv è
chiamato servizio o programma. Il numero di elementary stream all’interno di un servizio
non deve necessariamente essere costante; tale numero infatti può variare tra i singoli Tv
shows trasmessi all’interno di quel servizio (alcuni potrebbero essere trasmessi anche in
multilingua o in multiangolo) oppure all’interno di uno stesso evento Tv. Questi
cambiamenti , anche se non molto comuni, sono perfettamente consentiti dallo standard
MPEG. In termini DVB, ogni TV show è chiamato evento; quindi da un certo punto di
vista ogni servizio consiste di un certo numero di elementary stream trasmessi
simultaneamente, ma da un altro punto di vista il servizio consiste di una serie di eventi
individuali trasmessi uno dopo l’altro[5].
Fisicamente il Transport stream riunisce un set di servizi, ma tali servizi possono
essere anche raggruppati seguendo uno schema logico; un gruppo logico è chiamato
bouquet. Solitamente tale termine sta ad indicare i pacchetti di servizi offerti dallo stesso
broadcaster (es. pacchetto basic, pacchetto sport, pacchetto cinema ecc…), usato per
riunire logicamente servizi che fisicamente appartengono a TS diversi.
La Tv digitale inoltre introduce il concetto di network, ma non nell’uso
computeristico che ne facciamo abitualmente.
Il network coincide con il singolo broadcaster, che è per questo anche network
operator, e può o non può essere anche proprietario del mezzo trasmissivo. Nel caso di un
sistema di TV via cavo, solitamente , il proprietario dell’infrastruttura di rete è anche
network operator. Ma ciò non avviene per la TV via satellite o terrestre. Quindi
ricapitolando:
•
Un network è una singola entità che trasmette in broadcast uno o più transport
stream;
•
Un transport stream è uno stream MPEG-2 contenente vari servizi;
•
Ogni servizio è un canale TV e consiste di un certo numero di eventi che si
susseguono temporalmente uno dopo l’altro;
14
Capitolo 1
•
La Tv digitale:gli standard DVB ed MHP
Ogni evento è un singolo TV show (programma televisivo) e consiste di un certo
numero di elementary stream;
•
Ogni elementary stream è un flusso di pacchetti MPEG-2, contenenti audio,video o
dati binari codificati MPEG-2;
•
Vari servizi(anche appartenenti a transport stream diversi) possono essere
raggruppati insieme logicamente in un bouquet.
•
Ogni servizio può essere identificato univocamente da tre valori:
•
Original network ID: è l’identificativo del network che originariamente trasmette il
servizio;
•
Transport stream ID: per identificare un transport stream particolare all’interno di
quel network;
•
Service ID: per identificare il servizio all’interno di quel transport stream.
1.2.7 Gli standard di livello fisico
Lo standard principale è completato da altre specifiche che definiscono i parametri
fisici della trasmissione (frequenza,modulazioni,codifiche,ecc…). é stato definito uno
standard per ogni possibile canale trasmissivo:
•
DVB-S per la diffusione satellitare(ETSI EN 300 421 e TR 101 198): è lo
standard per le trasmissioni digitali satellitari(non solo TV, ma anche Internet via satellite).
Per la ricezione richiede antenne paraboliche e Set Top Box (o anche satellitari per PC); la
ricezione avviene da postazione fissa. La tecnica di modulazione usata è la QPSK in banda
Ku (11-14,5 GHz) e la copertura geografica delle trasmissioni è a livello continentale.
Tipicamente un canale satellitare presenta un BER pari a 10-7; è un valore indicativo in
quanto esistono numerose variabili quali condizioni atmosferiche, precisione del
puntamento, tecnologia del satellite o interferenze elettromagnetiche. Lo standard DVB
con l’aggiunta di FEC (Forward Error Correction) può portare il canale satellitare ad un
BER di 10-11 (Quasi Error Free). È in via di definizione lo standard DVB-S 2 con nuove
modulazioni, codifiche più potenti e maggiore adattabilità del canale[5].
15
Capitolo 1
•
La Tv digitale:gli standard DVB ed MHP
DVB-T per la diffusione terrestre (ETSI EN 300 744 e TR 101 190): è lo
standard per le trasmissioni digitali terrestri, utilizza le frequenze nelle bande VHF/UHF.
Permette di trasmettere fino a 4-5 canali digitali dove oggi può transitare un solo canale
analogico (ampiezza di canale pari a 8 Mhz). Non richiede nuove antenne ma gli utenti
dovranno munirsi di nuovi Set Top Box o nuovi televisori dotati di ricevitore digitale
interattivo integrato. Consente di circoscrivere le trasmissioni a livello regionale e permette
la ricezione anche a dispositivi mobili. La tecnica di modulazione utilizzata è quella
numerica COFDM multiportante (Coded Ortogonal Frequency Division Multiplex); è
una tecnica particolarmente robusta rispetto alle riflessioni del segnale o più in generale alle
interferenze e per questo indicata per ricezione mobile. Combinando i vari schemi di
modulazione e codifica si possono ottenere bit rate che vanno da 4,98 Mbps a 31,67 Mbps.
I parametri di modulazione sono:
•
Banda occupata del segnale COFDM: 6 Mhz, 7 Mhz e 8 Mhz;
•
Numero di sottoportanti irradiate: 8K (6817) o 2K (1705); i dati sono
riparti in un numero elevato di portanti ortogonali tra di loro;
•
costellazione per singole portanti: QPSK, 16-QAM, 64-QAM;
•
Inner Code Rate : ½,2/3,3/4,5/6,7/8;
•
Intervallo di guardia:1/4,1/8,1/16,1/32. Per evitare interferenze dovute agli
echi generati dallo stesso trasmettitore, oppure provenienti da altri trasmettitori
appartenenti alla stessa rete, deve essere inserito un intervallo di guardia tra due
simboli consecutivi COFDM[5].
•
DVB-C per la diffusione via cavo (ETSI EN 300 429): è lo standard per
trasmissioni digitali via cavo e utilizza canali di 8 Mhz all’interno della banda di downstream
(tipicamente 70-130 Mhz e 300-862 Mhz). La modulazione utilizzata è la QAM con 16, 32,
64, 128 o 256 punti nel diagramma della costellazione. La possibilità di spingersi fino ad un
così alto livello di modulazione QAM è permessa dal basso tasso di BER del mezzo
16
Capitolo 1
La Tv digitale:gli standard DVB ed MHP
trasmissivo. Lo standard è dedicato ad una realtà cablata come ad esempio a quella HFC e
il vantaggio immediato è quello di poter disporre di un canale di ritorno ad alta velocità
sullo stesso mezzo. Per la ricezione lato utente è richiesto un Set Top Box con
eventualmente anteposto un cable modem per la separazione dei dati dal video e per la
gestione del canale di ritorno. Grazie a tali livelli di modulazione si può arrivare fino ad un
bit rate di 53 Mbps in un canale di 8 Mhz[5].
1.3 Lo standard MHP
Attualmente tutti i principali sevizi interattivi sono già stati implementati tramite
tecnologie proprietarie (salvo alcune eccezioni) e sono attivi su diverse emittenti digitali,
soprattutto Pay-Tv satellitari. Il consorzio DVB ha standardizzato l’infrastruttura per il
trasporto dati in ambiente televisivo, ma non ha inizialmente fornito alcuna specifica per la
realizzazione di una qualunque piattaforma applicativa. Sono nate negli anni ’90 alcune
aziende che hanno sviluppato la loro tecnologia proprietaria per utilizzare i sistemi DVB
per la distribuzione ed esecuzione di applicazioni sui ricevitori DVB; in questo panorama,
un operatore di TV digitale intenzionato a fornire servizi interattivi si affida ad una
tecnologia proprietaria per realizzare il proprio set di applicazioni supportate
esclusivamente da un set top box realizzato secondo questa tecnologia. Si parla di un
mercato verticale, in cui sono presenti molteplici piattaforme per la fruizione dei servizi
interattivi, quasi sempre incompatibili tra loro. In questa selva di soluzioni proprietarie si è
avvertita la necessità di definire una piattaforma standard per la tv interattiva; questo
soprattutto in vista della fine delle trasmissioni televisive analogiche terrestri dove i canali
vengono offerti come servizio pubblico in chiaro e gli eventuali servizi interattivi devono
essere fruibili da tutti gli utenti senza problemi di compatibilità sul ricevitore. Il consorzio
DVB ha quindi provveduto ad un’architettura completa grazie alla definizione e
standardizzazione di:
•
Un sistema di trasporto per le applicazioni;
•
Un ambiente di esecuzione;
•
Un set di API (Application Programming Interface)
Da un mercato verticale si è quindi passati ad un mercato orizzontale: un’unica
piattaforma standardizzata con cui poter accedere ai servizi offerti da molteplici
17
Capitolo 1
La Tv digitale:gli standard DVB ed MHP
broadcaster senza problemi di compatibilità. Le specifiche MHP, quindi, coprono tutte le
questioni relative alla realizzazione, alla trasmissione e all’utilizzo di applicazioni iTV
(interactive TV), nonché le caratteristiche peculiari del loro ambiente di esecuzione; MHP
risponde alla necessità di avere una soluzione open che vada oltre la rigidezza e
incompatibilità tra i sistemi proprietari attualmente già in uso. Oltre all’iniziale
interoperabilità, i principali obiettivi dello sviluppo di MHP sono stati la capacità di
evolvere , la compatibilità con il passato, la modularità e la stabilità. È stata presa in
considerazione anche Internet così come l’integrazione con la rete locale domestica
costituita da vari terminali (PC, telefoni, apparecchi domestici, ecc…) MHP è uno standard
molto giovane; la prima release è stata creata dal DVB Project e standardizzata dall’ETSI
Institute nell’anno 2000. L’MHP definisce un interfaccia software generica (API) tra le
applicazioni interattive provenienti dai vari fornitori di servizi e i terminali sui quali esso
sarà eseguito, indipendentemente dalla loro implementazione hardware e software. Il livello
delle prestazioni di questi terminali può variare notevolmente. L’MHP può supportare varie
applicazioni(in ordine crescente di interattività):
•
EPG: Electronic Program Guide;
•
Servizi informativi paragonabili a un “super teletext”;
•
Applicazioni relative ai programmi attuali(scommesse sugli incontri, giochi, telefoto
ecc…);
•
Applicazioni di T-Learning(diffusione di contenuti per apprendimento attraverso i
mezzo televisivo)
•
Applicazioni di T-Government;
•
Commercio Elettronico con transazioni bancarie sicure.
1.3.1 Architettura di base
L’architettura è definita da tre livelli:
•
Risorse: comprende tutte le parti essenziali del Set Top Box : decodifica MPEG,
dispositivi di input/output, processore dell’host, sottosistema grafico, ecc…;
•
Software di sistema: consente la presentazione di una visione astratta della
piattaforma delle applicazioni. Comprende un navigatore (Application Manager) che
prende il controllo della piattaforma e delle applicazioni in esecuzione. Il nucleo software
18
Capitolo 1
La Tv digitale:gli standard DVB ed MHP
dell’MHP è chiamato DVB-J (DVB-Java): infatti si basa sulla Java Virtual Machine della
Sun Microsystems.
•
Applicazioni : le applicazioni MHP accedono alla piattaforma attraverso le API di
MHP. Le diverse interfacce software necessarie per l’uso di risorse specifiche sono
implementate come estensioni o plug-in. Il compito di qualunque implementazione pratica
dell’MHP è quella di assicurare la corrispondenza tra le API e le diverse risorse hardware
della piattaforma. Alcuni esempi di applicazioni sono: EPG (Electronic Program Guide),
servizi informativi, giochi, T-Commerce, T-Government ecc….
1.3.2 Profili MHP
Il sistema MHP ha fornito il concetto di profilo per dare una mano
nell’implementazione dello standard. Ogni profilo si riferisce ad una specifica area di
applicazioni e conseguentemente definisce i requisiti dei Set Top Box necessari a
supportarlo. Attualmente esistono tre profili MHP, definiti in due set di specifiche. Infatti
dato che i primi due sono molto simili tra di loro, il consorzio ha deciso di includerli nella
stessa release di specifiche. I tre profili attorno alla quale ruota tutta la piattaforma sono:
•
Enhanced Broadcast Profile : definito nelle specifiche MHP 1.0 (ES 201 812) e
designato a rispecchiare i vari modi e le funzionalità dei sistemi middleware esistenti e le
applicazioni che girano su di essi. Come evince dal nome, questo profilo richiede un Set
Top Box con nessuna o limitate capacità di gestione del canale di ritorno; è il profilo base e
permette solamente l’arricchimento del contenuto audio video con informazioni e
immagini visualizzabili e navigabili sullo schermo. Per questo motivo non sono richieste
performance particolari da parte dei Set Top Box.
•
Interactive Tv Profile : definito nelle specifiche MHP 1.0 (ES 201 812), è il profilo
intermedio
che
permette
di
utilizzare
il
canale
di
ritorno
(di
tipo
PSTN,ADSL,GPRS,Ethernet, ecc…) per fornire servizi con interattività superiore rispetto
al profilo base. Questo profilo, infatti, supporta anche il caricamento di applicazioni MHP
tramite il canale di ritorno (ma solo dalla versione 1.1), caratteristica che nel profile
Enhanced è possibile solo attraverso il canale broadcast;
•
Internet Access Profile : definito dalle specifiche MHP 1.1 (TS 102 812), richiede
in STB molto più sofisticato, con potenza di calcolo e memoria interna maggiori che nei
19
Capitolo 1
La Tv digitale:gli standard DVB ed MHP
primi due profili sopra descritti; permette tramite il canale di ritorno un’interattività totale e
un completo accesso ai contenuti di Internet. Il profilo Internet Access contiene un
elemento HTML opzionale chiamato DVB-HTML, permettendo il supporto di
XHTML,CSS,DOM,ECMA Script. Questo profilo necessita di performance di alto livello
essendo obbligatoria l’adozione di un browser internet e di un client di e-mail embedded
nel set top box. In aggiunta alla definizione dei profili, le specifiche MHP caratterizzano
anche altri aspetti, come la piattaforma DVB-J, i meccanismi di sicurezza MHP, i protocolli
per il download delle applicazioni ecc…[6]
1.3.3 Protocollo di trasporto
Affinché sia in grado di comunicare con il mondo esterno, è necessario che il
terminale utente supporti vari tipi di rete; per questo le specifiche MHP introducono il
supporto a diversi protocolli, così come definiti nelle specifiche DVB, a cui la piattaforma
fa riferimento. I protocolli definiti in questi standard forniscono il supporto generico a una
varietà di servizi sia di tipo broadcast che interactive ; le specifiche infatti supportano i
protocolli DSM-CC data carousel e object carousel e tutti i protocolli basati su IP. Risulta
interessante che i protocolli IP, intrinsecamente usabili sul canale interactive, possono
essere usati anche sul canale broadcast grazie al supporto della Multiprotocol Encapsulation
(MPE). Le varie configurazioni di rete supportate sono raggruppate in due classi:
•
I servizi broadcast sono implementati su sistemi che consistono di un canale di
downstream dal Service Provider all’utente finale;
•
I servizi interattivi invece si riferiscono a sistemi che consistono di un canale di
downstream associato ad un canale di ritorno.
I file dati sono trasmessi utilizzando i protocolli DSM-CC o IP incapsulato in
MPEG-2 così come definito nelle specifiche DVB relativamente alla MPE. Le applicazioni
MHP vengono trasportate all’utente finale attraverso il protocollo DVB Object Carousel
(appartenente sempre alla stessa famiglia dei protocolli DSM-CC), di cui si parlerà in
seguito.
20
Capitolo 1
La Tv digitale:gli standard DVB ed MHP
1.3.4 Protocolli del canale interattivo MHP
DVB prevede il supporto ad un folto set di protocolli per la gestione del canale di
ritorno. Le specifiche MHP richiedono il supporto ai protocolli HTTP 1.0 e HTTPS; il
supporto all’HTTP 1.1 è opzionale ma deve essere compatibile con la definizione di
connessioni persistenti della versione 1.0; infatti, senza il supporto alle connessioni
persistenti , deve essere stabilita una connessione TCP separata per ogni richiesta o URL,
aumentando in tal modo il carico del server HTTP. Infatti spesso si richiede al client di
effettuare richieste multiple allo stesso server in un breve intervallo di tempo e questo
causerebbe facilmente la congestione del server in un panorama multiutente. Per questo le
specifiche
MHP richiedono la compatibilità con la formulazione originale delle
connessioni persistenti così come definite da HTTP 1.0. Durante la connessione al server, il
terminale MHP invia il token cosiddetto “keep-alive” per richiedere una connessione
persistente; il server HTTP (1.0 o 1.1) quindi risponderà con un altro token “keep-alive”,
permettendo al client di procedere con una connessione HTTP persistente.
1.3.5 Tipi di contenuti MHP
La piattaforma MHP offre il supporto a formati di file immagine, fila audio e video
non streaming, sottotitoli, teletext e file caratteri sia residenti che prelevabili dal flusso
broadcast.
•
Formati file immagini : la piattaforma ignora ogni indicazione sul file immagine
trasmesso per quello che riguarda lo scaling dei pixel, lo spazio o la gamma dei colori; ogni
pixel dell’immagine originale viene mappato in un pixel grafico, a meno che non sia
modificato direttamente dall’applicazione che ha richiesto l’immagine. Viene fornito il
supporto ai formati JPEG, GIF, PNG: tra le ultime due è fortemente consigliato l’uso del
formato PNG il cui standard è pienamente supportato.
•
Formati file audio : la piattaforma supporta una versione ristretta dello standard
MPEG-1 audio Layer 1&2 elementary stream codificato ad un bit rate costante.
•
Formati file video : il video cosi come le immagini MPEG possono essere
visualizzati unicamente a pieno schermo oppure a ¼ di schermo. Sono supportati gli IFrame MPEG come sequenze video valide costituite solo da un frame di tipo I. La
piattaforma supporta inoltre i “video drips”, ovvero la possibilità di costruire l’interfaccia
21
Capitolo 1
La Tv digitale:gli standard DVB ed MHP
dell’applicazione processando progressivamente parti di uno stream MPEG-2, ma richiede
che il decoder sia nella modalità di basso ritardo, in cui gestisce unicamente frame di tipo I
o P.
•
Formati streaming audio/video : sono supportati l’audio e video MPEG in
definizione standard alla frequenza di 25 Hz, mentre il supporto all’alta definizione è
opzionale.
•
Formati streaming dati : sono supportati sia i sottotitoli DVB che il teletext; nel
caso in cui siano entrambi disponibili nello stream MPEG, la precedenza viene data ai
sottotitoli DVB.
•
Set di caratteri : almeno il set di font Tiresias deve essere fornito in ogni
implementazione MHP e come minimo deve essere in grado di visualizzare il testo alle
dimensioni di 36,31,26 e 24 punti. Oltre ai set di font di tipo residente , è possibile anche il
download di set di caratteri aggiuntivi nel formato PFR (Portable Font Resource).
Un’applicazione MHP è sostanzialmente una directory di files di programma associate a file
dati. Esistono due tipi di applicazioni MHP: DVB-J e DVB-HTML. Le applicazioni DVBHTML, sono simili ad applicazioni web che accedono alle risorse di sistema tramite
interfaccia DOM e fanno capo a linguaggi XHTML,Ecmascript, DOM. Questo tipo di
applicazione verrà introdotto solo con l’avvento delle specifiche MHP 1.1, pertanto in
questo lavoro di tesi si farà riferimento solamente alle applicazioni di tipo DVB-J.
Un’applicazione DVB-J è composta da file di programma in linguaggio Java[27] (è molto
simile alle classiche applet Java[27] ed infatti va sotto il nome di Xlet) e file di dati utilizzati
al suo interno. L’applicazione viene multiplata nel transport stream assieme ai flussi audio e
video ed eseguita dalla Java Virtual Machine del ricevitore che implementa un sottoinsieme
delle Java API.
1.3.6 Ciclo di vita di un’applicazione
L’esecuzione di un’applicazione MHP può avvenire sia in automatico che sotto
richiesta dell’utente. Fintanto che l’applicazione resta attiva, può essere visualizzata
graficamente sullo schermo e chi la visualizza può interagire con essa. L’applicazione può
anche essere messa in pausa e rimanere cosi attiva, ma in background. In questo caso la si
può riavviare più velocemente. Il ciclo di vita di un’applicazione termina molto spesso
22
Capitolo 1
La Tv digitale:gli standard DVB ed MHP
quando viene cambiato canale. Come visto in precedenza, è anche possibile segnalare la
stessa applicazione su più canali, cosi facendo la si può far rimanere attiva anche dopo che
è avvenuto il cambio di canale. Dopo che l’applicazione viene terminata, le uniche
informazioni che restano memorizzate sul ricevitore sono i dati che l’applicazione
eventualmente scrive sulla memoria fissa. Non è possibile memorizzare l’intera
applicazione sulla memoria fissa, possibilità questa, contemplata per i ricevitori di prossima
generazione, nella versione 1.1 della specifiche MHP. Alcuni ricevitori MHP danno la
possibilità di visualizzare un menù separato con cui controllare le applicazioni. Tale menù
di visualizzazione permette di vedere lo stato delle applicazioni e di inizializzarle, metterle
in pausa oppure terminarle. Un ricevitore MHP può mettere in pausa un’applicazione e
richiamarla nello stato attivo. Nello stato di pausa l’applicazione deve rilasciare quante più
risorse possibili. La cosa più importante, comunque, è che l’applicazione viene nascosta alla
vista. Riassumendo, gli stati del ciclo di vita di un’applicazione sono:
•
Loading: l’application manager decodifica le segnalazioni dell’applicazione e carica
le risorse nella cache, senza però allocare la memoria richiesta per l’esecuzione fino alla
ricezione del segnale di trigger che porta l’applicazione nello stato attivo;
•
Active: l’application manager alloca tutte le risorse richieste dall’applicazione, crea
un actor che gestirà quella particolare applicazione e gli concede il pieno accesso a tutte le
risorse del sistema MHP, nel rispetto della gestione delle risorse e dei vincoli sulla sicurezza;
•
Paused: questo è uno stato di operatività ridotta e l’actor associato all’applicazione
può non avere più pieno accesso alle risorse di sistema che comunque gli verrà concesso
nuovamente appena l’applicazione ritornerà attiva;
•
Destroyed: un actor è in questo stato quando perde le risorse di sistema o i
contenuti di cui necessita. L’actor può ancora essere in grado di eseguire l’applicazione
grazie ai dati nella cache, ma il caricamento di alcuni file potrà fallire;
•
Killed : questo stato è caratterizzato dalla perdita di tutte le risorse. Quando un
actor viene terminato il sistema MHP recupera tutte le risorse e la gestione dei dati rimasti
nella cache dipende dalle varie implementazioni.
23
Capitolo 1
La Tv digitale:gli standard DVB ed MHP
1.3.7 Broadcast di applicazioni e dati: DSM-CC Object Carousel
Il protocollo DSM-CC è stato originariamente progettato per l’uso con macchine di
rete VTR (Video Tape Recorder – Registrazione di video in rete). Da allora si è sviluppato
molto e adesso include il controllo di server video MPEG in rete (con funzioni di play, stop
e pausa del video e dell’audio), il supporto per la trasmissione di dati utilizzando MPEG-2,
timecode per il video MPEG, il broadcasting di dati semplici e interi file system. I sistemi
broadcast sono per loro natura unidirezionali. I dati vengono inviati da un trasmettitore e il
ricevitore non può richiedere dati specifici. Questo significa che un ricevitore non può
accedere ad uno specifico file su un server come avviene per i normali PC. Per questo è
necessaria un’altra soluzione che permetta al ricevitore MHP di accedere ai dati sul flusso
broadcast. L’approccio è quello di trasmettere periodicamente ogni file del file-system e il
ricevitore non deve far altro che attendere il file di cui ha bisogno. Il miglior esempio di
questa soluzione è il sistema di teletext digitale: ad ogni pagina è associato un numero
univoco e le pagine vengono trasmesse una dopo l’altra ciclicamente. Quando l’utente
digita il numero della pagina da ricevere, il ricevitore deve attendere che la pagina venga
trasmessa prima di poterla decodificare e presentare al display. Questo tipo di soluzione va
sotto il nome di carosello (ogni pagina trasmessa a turno periodicamente e il ricevitore deve
attendere il ritorno di quella pagina nel flusso broadcast per poterla prelevare ed usarla).
Certamente, questa soluzione non è molto efficiente, ed infatti si sono nel tempo sviluppate
tecniche per migliorarne le prestazioni. Nel DSM-CC, i dati vengono trasmessi in blocchi
chiamati “moduli” invece che in pagine, ma il principio è lo stesso del sistema di teletext. I
dati da trasmettere vengono suddivisi in moduli, vengono aggiunte informazioni a ciascun
modulo, quindi ogni modulo viene trasmesso a turno. Il DSM-CC supporta due tipi di
carosello. Il più semplice dei due è il data carousel, che fornisce al broadcaster un modo
per trasmettere blocchi di dati al ricevitore. Non sono però presenti dati aggiuntivi che
informano sul tipo di dati e su cosa si sta trasmettendo ed è quindi compito del ricevitore
rielaborare i dati in una forma sensata. In situazioni più complesse il data carousel non
risulta molto utile e in questi casi l’object carousel costituisce una soluzione migliore.
L’object carousel è costruito come protocollo direttamente sopra il data carousel e
fornisce funzionalità vicine a quelle di un file-system standard. Ogni object carousel
consiste di un albero di directory suddiviso in una serie di moduli, che possono contenere
24
Capitolo 1
La Tv digitale:gli standard DVB ed MHP
uno o più file o directory. Ogni modulo può contenere molteplici file con una dimensione
totale minore di 64 Kb, l’inserimento di più file in un modulo di dimensione maggiore di 64
Kb non è permesso, così come suddividere un unico file su più moduli, quindi un file più
grande di 64 Kb andrà a riempire il suo proprio modulo che conterrà solamente quel file.
Questi moduli vengono trasmessi in broadcast l’uno dopo l’altro fino alla fine. A questo
punto la trasmissione comincia da capo con il primo modulo. Per l’accesso ad un preciso
file, il ricevitore deve attendere fino a che non riceve il modulo contenente quel file; a
questo punto può elaborare il modulo ed avere accesso al file desiderato. Questo metodo
può non essere molto efficiente quando le dimensioni totali dei dati da trasmettere sono
considerevoli, ma la maggior parte dei ricevitori sono in grado di mantenere memorizzati
nella cache parte dei dati e questo velocizza notevolmente le operazioni. La
memorizzazione dei dati nella cache può avvenire sia a livello di modulo che di singolo file.
Alcuni moduli possono essere trasmessi più di una volta all’interno dell’object carousel.
Infatti, trasmettendo alcuni moduli più spesso di altri, il tempo di accesso ai file più
comunemente usati viene ridotti notevolmente. D’altro canto però agendo in questo modo
cresce la dimensione totale del carosello, causando un aumento del tempo di accesso ai dati
meno usati. Nel progetto del layout di un carosello si deve considerare attentamente questo
compromesso che, se ottimizzato, può portare ad una riduzione notevole del tempo di
caricamento di un’applicazione. Nello stesso carosello è possibile inserire più applicazioni
che verranno così trasmesse contemporaneamente dando all’utente la possibilità di scegliere
ad esempio se sfogliare la guida EPG piuttosto che navigare in internato misurarsi in un
gioco interattivo. Ovviamente spetta all’object carousel generator il compito di condividere
tra le varie applicazioni la banda destinata al carosello. All’interno di un transport stream
DVB possono essere trasportati uno o più Object Carousel, nello stesso modo in cui
vengono gestiti gli stream del video, dell’audio e della service information. Ad ogni stream
Object Carousel viene allocato un PID univoco che viene referenziato nelle tabelle DVBSI. Uno stream Object Carousel tipicamente occupa una banda di payload di circa 1 Mbps
ma nelle applicazioni reali questo valore può essere limitato dall’abilità del ricevitore di
decodificare ed elaborare le applicazioni[7].
25
Capitolo 1
La Tv digitale:gli standard DVB ed MHP
1.3.8 Architettura di fruizione di un servizio interattivo MHP
Nella Figura 6, a pagina seguente, viene illustrato in maniera molto schematica
l’ambiente coinvolto nell’esecuzione di un’applicazione MHP. Nel momento in cui si
fruisce della Tv digitale entrano in gioco due gestori dei contenuti: il primo è quello che
fornisce i contenuti sottoforma di programmi televisivi, il broadcaster; il secondo è quello
che fornisce i contenuti sottoforma di dati (estratti conto, certificazioni anagrafiche,
informazioni pubblicitarie ecc…). Il primo distribuisce i propri servizi broadcast,
sfruttando un canale dedicato (unidirezionale) che dipende dallo standard utilizzato (etere
per il DVB-T, cavo coassiale per DVB-T, satellite per DBT-S) mentre il secondo
distribuisce i propri servizi utilizzando Internet come luogo di scambio.
Durante un programma televisivo è possibile, attraverso la pressione di un apposito
tasto del telecomando, richiedere l’esecuzione di un’applicazione, ove essa sia disponibile.
Di solito il fornitore informa l’utente della presenza di un’applicazione nel carosello per
mezzo di un segnale visivo, un’etichetta lampeggiante o un’icona corrispondente ad un
tasto colorato del telecomando. Nel momento in cui l’applicazione si trova nella fase di
Active l’utente può iniziare ad usufruire del servizio che, a seconda del tipo, è dotato di un
maggiore o minore grado di interattività. Abbiamo visto che questa può essere locale o
remota. La prima sfrutta soprattutto le risorse presenti all’interno dei moduli del carosello
mentre la seconda utilizza il canale di ritorno, la componente innovativa della Tv digitale.
L’utente effettua delle richieste interagendo con l’applicazione che le inoltra, per mezzo del
canale di ritorno (dial-up, xDSL, GPRS, UMTS, Cable Modem), al centro servizi il quale
restituisce i contenuti voluti al lato client che li ripropone all’interno dello schermo
televisivo[3].
26
Capitolo 1
La Tv digitale:gli standard DVB ed MHP
Canale trasmissivo
opportuno
DSM-CC
Object-Carousel
Programmi Tv
Fornitori di
contenuti
multiplazione
modulazione
TV
RETE TLC
dial-up, xSDL,
GPRS, UMTS,
Cable Modem
DECODER MHP
CANALE DI RITORNO
BIDIREZIONALE
Fornitore dei
servizi
- Server bancario
- SED
- Centro di calcolo
- Ecc..
Internet
L’utente interagisce con
l’applicazione per mezzo
della pressione dei tasti
del telecomando
Figura 6. Architettura di fruizione di un servizio interattivo per la Tv digitale
27
Capitolo 2
La formazione a distanza
2
Capitolo 2
La formazione a distanza
2.1 L’e-learning come fenomeno sociale e di mercato
Lo sviluppo e la diffusione delle nuove tecnologie della comunicazione stanno
mutando in modo sempre più rapido e incisivo la società in cui viviamo: l’evoluzione e il
cambiamento interessano non solo gli strumenti e le tecniche di comunicazione, le strutture
economiche e produttive dei nostri paesi, ma l’intera società e le forme in cui essa si
esprime, a partire dalla cultura, i costumi ed il modo di pensare.
Le funzionalità di base offerte dalla telematica (accesso a risorse, comunicazione in
tempo reale o/e differita, ecc….) possono essere utilizzate direttamente come risorse
nell'ambito di processi didattici di tipo tradizionale o possono servire a dare vita a modelli
di insegnamento/apprendimento innovativi basati su processi di comunicazione
collaborativi e bidirezionali, che si sono delineati negli ultimi anni nell’istruzione a distanza.
L’oggetto di interesse di questa discussione è proprio quello di focalizzare l’attenzione sulle
dinamiche di “e-learning” promosse e valorizzate dal ricorso a tecnologie sempre più
sofisticate; queste ultime costituiscono la risposta concreta alle esigenze più disparate di
coloro che intendono intraprendere un percorso di apprendimento flessibile e che facilita la
gestione integrata di tutti gli aspetti della vita di ciascuno. L’innovazione tecnologica avvia il
passaggio dalla “società dell’informazione” caratterizzata da un’informazione di massa e
fondata sulla distribuzione di dati predefiniti e standardizzati, ad una “società della
conoscenza” che sollecita la partecipazione cognitiva di ogni singolo individuo ed in cui
l’accesso è permesso dal patrimonio di conoscenze e competenze posseduto.
L'accrescimento e il cambiamento continuo sia dei sistemi informatici che delle
infrastrutture di comunicazione consentono la sperimentazione e la concretizzazione di
modelli comunicativi sempre più sofisticati, capaci di offrire nuove opportunità di
apprendimento sia in termini economici che qualitativi. L'aumento incessante dell'utilizzo
di Internet non produce semplicemente la corsa alla realizzazione di diverse tecnologie ma
modifica in maniera rapida e assidua il modo di lavorare delle persone. Per questo motivo il
28
Capitolo 2
La formazione a distanza
concetto di e-learning non si limita a quello di trasferimento di contenuti formativi attraverso
la rete, ma è un modo di concepire la didattica che accresce il valore dell’insegnamento
tradizionale con l'integrazione delle tecnologie della comunicazione. Un esempio dello
sviluppo dei nuovi strumenti resi possibili grazie ai progressi della tecnica negli ultimi anni è
l'impiego del satellite per la formazione a distanza. L'uso della parabola per il broadcasting
televisivo è ormai all'ordine del giorno, ma la sua collocazione all'interno di un sistema di
apprendimento a distanza può rivelarsi un mezzo davvero importante. In particolare la
parabola viene adoperata per la diffusione dei contenuti e per la connettività, con protocolli
impostati sulla trasformazione dei dati a pacchetto proprio come nella rete. Grazie al
continuo miglioramento della qualità delle trasmissioni si ha la possibilità di amministrare
applicazioni interattive mettendo in comunicazione l'insegnante con le aule virtuali. Le
difficoltà più grandi si sono riscontrate nella ricezione dei dati dal satellite via modem
terrestre, infatti questo processo si è rivelato ancora troppo lento considerate le aspettative
iniziali. L'opportunità di utilizzare l'e-learning via satellite attraverso la teledidattica e la
teleformazione ha attirato l'attenzione di molte aziende in tutta Europa, Italia compresa, anche
se la maggior parte di questi progetti è ancora in fase sperimentale[8].
2.1.1 La storia della formazione a distanza
Come è noto, nella cultura anglosassone la formazione a distanza (FAD) ha una
lunghissima tradizione. Fin dal secolo scorso varie università e istituzioni “vendevano”
formazione veicolata grazie ai servizi postali dell’epoca. Con il passare del tempo, questa
metodologia si è diffusa anche in altri ambiti culturali (Francia, America Latina, Italia) e ha
utilizzato di volta in volta nuovi strumenti di comunicazione. Così si è passati dalla posta, al
telefono, al fax e, più recentemente, alla distribuzione via TV (sia etere che satellitare).
Infine si è approdati a Internet . Comunque tutti questi mezzi di comunicazione vengono
utilizzati come semplici veicoli di materiali didattici che possono assumere la forma di libri,
audio cassette, video cassette, cd-rom ecc. In sostanza, però, il metodo didattico è rimasto
sempre il medesimo: un individuo (allievo) viene raggiunto dal materiale didattico che
studia grazie all’assistenza a distanza di un tutor . Al termine del processo formativo ci sarà
una sessione di valutazione che permetterà all’allievo di ottenere un titolo di studio. In
questa cornice, possiamo ragionevolmente affermare che tutte le organizzazioni di FAD
29
Capitolo 2
La formazione a distanza
usano ampiamente Internet o qualche forma di collegamento telematico. È questo il caso
della Open University, antica istituzione britannica di formazione a distanza che offre corsi
universitari di Bachelor, Master Degree e Ph.D. per molte discipline sia umanistiche che
scientifiche. Analogamente, la George Washington University distribuisce programmi di
studio di livello universitario. Una specificità di questa organizzazione è l’attivazione di un
programma di FAD in Health Sciences (medicina). La metodologia didattica della Nova
Southestearn University e la Penn University si allinea a quanto detto sopra: usano la rete
telematica come integrazione di altri mezzi di distribuzione telematica. La didattica ha
comunque un impianto tradizionale. Infatti, come già affermato sopra, le metodologie di
FAD tradizionali sono ben consolidate e la valutazione della qualità dei programmi di
studio offerti dalle varie organizzazioni deve necessariamente entrare nell’analisi della
qualità dei contenuti e dei docenti coinvolti nell’attività formativa che non è possibile solo
dall’ispezione di vetrine pubblicitarie quali sono i siti Web aziendali (o universitari)[8].
2.1.2 Cenni di storia
Ciò che oggi chiamiamo e-learning nasce dall'integrazione di due diversi campi di
sperimentazione nelle tecnologie didattiche: la formazione a distanza e il Computer Based
Training. La storia della formazione a distanza (FAD) segue l'evoluzione delle tecnologie di
comunicazione, partendo dai corsi per corrispondenza, passando per l'emissione televisiva
e arrivando alle più recenti strutture di teleconferenza satellitare. Il Computer Based Training,
ossia lo studio basato sull’uso del computer come tecnologia didattica di autoistruzione
trova la sua strada soprattutto sulle discipline informatiche e sull'addestramento a
determinati software e, come strumento di supporto, nella didattica delle lingue straniere. La
distribuzione di Cd-Rom in sostituzione delle tradizionali dispense cartacee può essere
considerato un approccio all'integrazione di FAD e CBT, ma è solo con lo sviluppo di
Internet e del World Wide Web, con la diffusione del suo utilizzo, che può nascere l'online
learning, ossia il punto d'incontro tra le due metodologie. La capacità della rete di diffondere
e distribuire informazione, gestire dati, tracciare l'utenza unita alle esperienze della
formazione a distanza e delle sue caratteristiche emotive e cognitive e agli esperimenti di
didattica interattiva compiuti dal CBT hanno permesso di spostare in avanti le frontiere
dell'e-learning, inventando nuovi orizzonti per la didattica e la formazione aziendale. Di e-
30
Capitolo 2
La formazione a distanza
learning si parla ormai da diverso tempo nel mondo della formazione aziendale, e da diversi
anni nel campo della ricerca didattica universitaria. L'esigenza di nuovi strumenti per
l'apprendimento e il training si fa sempre più pressante, seguendo un costante movimento
verso la formazione permanente e forme di aggiornamento sempre più costanti che
riguardano tutte le professionalità. In realtà, con un deciso ritardo nei confronti dell'area
anglosassone, l'Italia sta muovendo solo da poco i suoi primi passi con esperimenti pratici
di formazione on line. Le società di formazione tradizionale stanno rivolgendo i loro
investimenti e la loro attenzione ai fornitori internazionali e nazionali di piattaforme,
strumenti e know-how sulle tecnologie didattiche legate a Internet. Le università italiane hanno
mosso i loro primi passi a metà degli anni '90, senza un coordinamento centrale e
delegando gli sforzi di sviluppo a istituti interni di ricerca (Università degli Studi di Milano,
Trento e Firenze in prima linea)[8].
2.1.3 Campi di applicazione
Al momento sono principalmente due gli ambiti di applicazione dell’e -learning: da
una parte vi sono le scuole e le università, che stanno sperimentando queste forme di
insegnamento soprattutto per venire incontro agli studenti fuori sede e a quelli svantaggiati;
dall’altra vi sono le aziende, che costituiscono la fetta più ricca di questo mercato. Al
momento occupa un ruolo marginale la formazione elettronica nella pubblica
amministrazione (anche se si parla spesso di e-government ed e-procurement come delle attuali
frontiere della P.A.), ma ben presto anche il pubblico dovrà dirigersi verso l’e-learning per
formare le nuove figure professionali richieste dal mercato. Molte aziende lo percepiscono
come un modo per risparmiare tempo, spazi e soldi; altre invece, puntano a
patrimonializzare la conoscenza interna per riutilizzarla e comunicarla ai dipendenti,
puntando ad un processo di condivisione circolare. Sono due modelli che si avvicineranno
ma la tendenza dominante si spera sia quest’ultima, in modo da utilizzare le tecnologie al
meglio, gradualizzando gli accessi a seconda della struttura interna e delle professionalità[8].
2.1.4 I Modelli e le Teorie Cognitive
In quest’ultimo secolo, la progressiva evoluzione delle tecnologie della
comunicazione
(mezzi
di
trasporto,
telecomunicazioni,
ecc.)
ha
condizionato
31
Capitolo 2
La formazione a distanza
costantemente l’altrettanto progressiva evoluzione dei sistemi per la Formazione a
Distanza. (Nipper, 1989). Le prime applicazioni di una certa significatività delle
metodologie di formazione a distanza si ebbero alla fine del diciannovesimo secolo, quando
le nuove tecniche di stampa e lo sviluppo del trasporto ferroviario resero possibile la
produzione e la distribuzione estensiva di materiale didattico a favore di gruppi di studenti
distribuiti su vaste aree geografiche. Si trattava di interventi basati principalmente sulla
corrispondenza, in cui il medium era rappresentato dal materiale a stampa e l’interazione
studente – docente, estremamente lenta nella sua dinamica, era in genere circoscritta allo
scambio di elaborati ( per es. questionari di valutazione) e a rarissimi incontri in presenza. A
questi sistemi FAD, detti di prima generazione (o per corrispondenza), negli anni dal 1960 al 1990
succedono i cosiddetti sistemi FAD multimediali o di seconda generazione, caratterizzati da un
uso integrato di materiale a stampa, trasmissioni televisive, registrazioni sonore e in alcuni
casi software didattico (courseware).
Il processo di “interazione” tra docente e studente continua ad essere molto simile
a quello della prima generazione, anche se include l’assistenza telefonica, le attività tutoriali
in presenza è più recentemente i collegamenti via fax e posta elettronica. Gli approcci dei
sistemi FAD di prima e seconda generazione si basano quindi prevalentemente sulla
produzione e distribuzione di materiali didattici destinati alla popolazione da formare. La
comunicazione con gli studenti, vista in un ottica di bidirezionalità, rimane marginale e la
comunicazione tra gli studenti è quasi del tutto inesistente o comunque non organizzata.
Nei sistemi di prima e seconda generazione il problema principale è la copertura di distanze
geografiche e/o il raggiungimento di vaste popolazioni di utenza, problema che viene
risolto principalmente attraverso metodi efficaci di presentazione e distribuzione. La
conseguenza è che l’apprendimento non è più un processo sociale in cui privilegiare le
interazioni tra docenti e studenti quanto piuttosto un fatto prevalentemente individuale. Le
“classi virtuali” che si vanno così a formare mancano di quell’apertura socio-cognitiva tipica
di una classe tradizionale. Il riproporre anche a distanza, seppur con l’inevitabile mediazione
della tecnologia, l’apprendimento come un processo sociale è l’idea chiave che sta guidando
lo sviluppo dei sistemi FAD di terza generazione. Nella terminologia FAD i sistemi di terza
generazione sono anche detti di online education o formazione in rete, proprio a significare
come la maggior parte del processo formativo avvenga via Internet, attraverso l’interazione
dei partecipanti in una vera e propria “comunità di apprendimento” che favorisca sia il
32
Capitolo 2
La formazione a distanza
superamento dell’isolamento del singolo sia la valorizzazione dei suoi rapporti con il
gruppo. L’online education o formazione in rete si inserisce,dunque, nella storia della
formazione a distanza costituendone la cosiddetta” terza generazione”, (Garrison,1995;
Nipper, 1989; Trentin, 1998), ma una collocazione puramente “evolutiva” in questo
contesto di origine fornirebbe una comprensione non adeguata. Essa da un lato deve molto
all’evoluzione stessa degli strumenti legati alle Tecnologie dell’Informazione e della
Comunicazione (TIC, o solitamente ICT - Information and Communication Technologies – in
inglese) e a spinte che provengono dall’ambito economico, oltre al fatto che la ricerca sulle
nuove tecnologie si è intrecciata con nuovi paradigmi teorici che investono alla radice la
filosofia stessa della formazione; si appropria così di un corredo di atteggiamenti,
orientamenti, concezioni e modelli educativi che le forniscono un taglio peculiare. Di
particolare importanza è l’evoluzione interna all’educazione a distanza verso modelli di open
learning, la trasformazione della tecnologia multimediale verso il Web based training, la
progressiva acquisizione di modelli teorici ed epistemologici relativi alla formazione che
valorizzano l’autonomia e una costruzione negoziale dei saperi quali la “psicologia
umanistica” e il “costruttivismo”. A partire dal 1970 nell’educazione degli adulti prendono
maggiore spazio orientamenti volti a valorizzare complessivamente l’autonomia e la
responsabilizzazione del discente che apprende; si rivolge più attenzione alle esigenze degli
individui, orientando gli allievi a un’assunzione di responsabilità e iniziativa decisionale. Si
ha una rivalutazione dello studio autonomo, già praticato in una tradizione secolare,
chiamato di volta in volta studio “autodidatta”, “autocontrollato”, “autoorganizzato”,
ricollocato al centro di nuove filosofie dell’apprendimento. Ci si rende conto che per lo più
si è banalizzato questo concetto, identificandolo con lo svincolo tecnico da luoghi, tempi e
docenti, laddove il materiale di studio rimane tuttavia assai costruttivo, strutturato in tempi
rigidi, e il programma didattico fondamentalmente eterodiretto ( Peters 1998). Si avverte la
necessità di affrontare il problema dell’autonomia ancorandolo alle nostre tradizioni di
pensiero. Si può parlare di reale autonomia quando sono gli studenti a individuare le
proprie esigenze di approfondimento, a formulare gli obiettivi didattici, a scegliere i
contenuti, a sviluppare strategie di apprendimento, a procurarsi materiali e media, a
identificare ulteriormente risorse umane e materiali, nonché a organizzare, controllare e
valutare da soli l’apprendimento, (Moore,1994) aspetti questi che complessivamente fanno
preferire il termine di “personalizzazione” dell’apprendimento, rispetto a quello più
33
Capitolo 2
La formazione a distanza
tradizionale di “individualizzazione”. Uno degli apporti più interessanti proviene dalla
cosiddetta “psicologia umanistica”(Fromm, Maslow, Rogers), secondo cui gli uomini
aspirano a una continua autorealizzazione; ciò si accompagna a un cambiamento radicale
nell’atteggiamento dell’insegnante, che si trasforma in “facilitatore”, secondo le idee che
sono state apportate soprattutto da Rogers, e riprese in particolare nell’educazione degli
adulti. L’educatore può solo cercare di “facilitare” l’apprendimento, non “insegnare”. In
che modo? Creando intorno a chi apprende una offerta articolata e uno scaffolding di
assistenza e aiuto, a cui l’allievo possa variamente attingere secondo le sue necessità.
Fondamentali sono i momenti di negoziazione; in qualche modo occorre fare il punto,
valutare dove andare; la pedagogia del contratto e della negoziazione con il tutor è posta
nuovamente al centro[8].
2.2 Gli standard dell’e-learning
Nel mondo dell'e-learning, per alcuni aspetti ancora giovane, ed in continua
evoluzione, diverse organizzazioni sono al lavoro per definire standard tecnici e didattici
complementari.
Standard
accreditati
sono
necessari
per
sviluppare
contenuti
interscambiabili che possano essere riusati, assemblati e scorporati in modo facile e veloce.
In questo modo è possibile avere una piena interoperabilità tra i contenuti di piattaforme elearning diverse. Nella lista che segue sono elencate le principali organizzazioni che al
momento stanno portando avanti il lavoro di definizione degli standard:
•
SCORM : Advanced Distribuited Learning (ADL) Iniziative[9];
•
IEEE Learning Technology Standards Committee (LTSC)[10];
•
IMS (Instructional Management System) Global Learning Consortium[11];
•
AICC - Aviation Industry CBT Committee[12];
•
PROMETEUS[13];
•
The Dublin Core Metadata Initiative[14].
34
Capitolo 2
La formazione a distanza
2.2.1 SCORM: Advanced Distributed Learning (ADL) Iniziative
La "Advanced Distributed Learning" (Apprendimento distribuito avanzato) è una
iniziativa sponsorizzata dal Dipartimento della Difesa statunitense in coordinamento con
l'Office of Science and Technology Policy (Ufficio per le Politiche Scientifiche e
Tecnologiche) della Casa Bianca. Nasce da una visione di un futuro in cui elementi
condivisibili di software didattico, o oggetti didattici (shareable courseware objects)
possono essere assemblati in tempo reale per creare sul momento un'offerta didattica che
risponda alle specifiche esigenze di un utente. Questi oggetti didattici devono avere,
secondo il progetto dell'ADL, quattro caratteristiche principali:
•
devono essere accessibili, cioè ci devono essere degli standard accettati da tutti per
archiviarli e quindi ritrovarli quando serve;
•
una volta trovati, questi oggetti devono essere usabili, cioè devono poter funzionare
(interoperabilità) su diverse (se non tutte) piattaforme, sistemi operativi, browsers;
•
una volta implementati, gli oggetti didattici devono essere affidabili, cioè se la
piattaforma o sistema operativo o browser sottostante viene modificato, devono continuare
a funzionare come prima;
•
devono essere riusabili, cioè poter funzionare ed anche essere modificati da altre
piattaforme, sistemi operativi e browser.
Per raggiungere questi obiettivi, il governo federale americano sta coordinando
quindi lo sviluppo di un modello di riferimento per gli elementi condivisibili di software
didattico (SCORM: Shareable Courseware Object Reference Model). Si tratta di linee guida
per definire un formato di software didattico trasportabile attraverso piattaforme Learning
Management System differenti. SCORM vuole definire le interrelazioni dei componenti di
un corso e il modello secondo cui il contenuto didattico (inteso nel senso più ampio,
includendo anche obiettivi didattici, requisiti ecc) deve organizzarsi. In questo senso, ADL
SCORM non è un insieme di standard né di specifiche tecniche, ma un modello di
riferimento che sta cercando di mettere insieme i vari standard prodotti dai diversi gruppi.
Dal sito www.adlnet.org è sempre possibile scaricare la versione di SCORM più recente[9].
35
Capitolo 2
La formazione a distanza
2.2.2 IEEE Learning Technology Standards Committee (LTSC)
IEEE sta per Institute of Electrical and Electronic Engineers. Ha costituito al suo
interno una task force chiamata Learning Technology Standards Committee (LTSC), che si
occupa di creare specifiche per ognuna delle aree connesse all'apprendimento, come i
metadata, il profilo studenti, la sequenzialità dei corsi, la definizione delle competenze, la
localizzazione e lo sviluppo dei contenuti. L'IEEE LTSC è uno degli enti di
standardizzazione a livello mondiale, e i suoi standard sono accettati e usati su base molto
ampia. Recentemente ha anche iniziato a far accreditare la sua opera dalla International
Standards Organization (ISO), fondando l'ISO Joint Technical Committee 1 (JTC1) Sub
Committee 36 (SC36) sulla Learning Technology. L'IEEE LTSC opera attraverso più di 20
gruppi di lavoro che creano ciascuno i propri standard, correlati tra loro. Questo processo è
aperto a chiunque voglia partecipare, che può accedervi tramite e-mail discussion list o
partecipando agli incontri che si tengono tre o quattro volte l'anno in diversi luoghi per
ognuno dei gruppi di lavoro[10].
2.2.3 IMS (Instructional Management System) Global Learning
Consortium
L'IMS Global Learning Consortium è un'organizzazione americana che sta
promuovendo delle specifiche aperte per facilitare le attività didattiche on line, come
localizzare e usare contenuto didattico, tener traccia dei progressi dello studente, produrre
report sulla sua performance e scambiare questi report tra diversi sistemi amministrativi.
L'IMS ha due obiettivi principali:
•
definire gli standard tecnici per l'interoperabilità delle applicazioni e dei servizi per la
formazione in rete;
•
supportare l'incorporazione a livello mondiale delle specifiche IMS in prodotti e
servizi. Pertanto l'IMS promuove l'adozione più ampia possibile delle sue specifiche.
36
Capitolo 2
La formazione a distanza
L'IMS è un consorzio i cui membri provengono da organizzazioni didattiche,
commerciali e governative[11].
2.2.4 AICC – Aviation Industry CBT Committee
L'Aviation Industry CBT Committee è un'associazione internazionale di
professionisti della formazione per mezzo di tecnologie didattiche. La AICC sviluppa linee
guida per l'industria aeronautica riguardo lo sviluppo e la valutazione di computer-based
training e tecnologie didattiche correlate.
Anche se l'AICC si rivolge in primo luogo all'industria aeronautica, la sua
esperienza pluriennale ha portato allo sviluppo di specifiche molto efficaci nel campo
dell'istruzione supportata da computer in genere. Di conseguenza moltissimi consorzi e enti
di standardizzazione accreditati stanno adottando e adattando le linee guida dell'AICC alle
loro specifiche industrie.
L'AICC sta anche coordinando i suoi sforzi con quelli di altre grandi organizzazioni
che si occupano di standard per le tecnologie didattiche, come la IEEE LTSC, l'ADL e
l'IMS[12].
2.2.5 Prometeus
Vari programmi di ricerca e sviluppo finanziati dall'Unione Europea intendono
promuovere le tecnologie telematiche e multimediali, con l'esplicito obiettivo di favorire e
facilitare l'accesso alla conoscenza, all'istruzione e alla formazione per tutti i cittadini
europei.
In questo ambito, il progetto europeo PROMETEUS, sotto forma di un forum
aperto permanente, ha messo insieme centinaia di organizzazioni del settore pubblico e
privato, con lo scopo di affrontare diversi temi, per costruire un consenso ampio e
un'azione di pressione sui vari governi europei.
37
Capitolo 2
La formazione a distanza
Tra i temi trattati, si occupa anche di piattaforme didattiche basate su standard
aperti. PROMETEUS sta cercando non solo di applicare gli standard dell'IEEE LTSC, ma
attraverso i suoi vari Special Interest Groups (SIG) sta cercando anche di integrare questi
standard nel contesto europeo. PROMETEUS svilupperà linee guida e raccomandazioni da
inviare a enti internazionali di standardizzazione. Al momento sta collaborando con il
nuovo
Learning
Technologies
Standards
Workshop
dell'Information
Society
Standardization System dell'European Committee for Standardization (CEN/ISSS)[13].
2.2.6 The Dublin Core Metadata Iniziative
Il Dublin Core è un insieme di metadata che intendono facilitare il reperimento di
risorse elettroniche. Concepito originariamente come un modello per una descrizione di
risorse Web da parte dell'autore, ha attirato l'attenzione di organizzazioni che si occupano
di descrizione di risorse, come musei, biblioteche, enti governativi, ed anche organizzazioni
commerciali, interessate ad un metodo più facile per trovare le risorse elettroniche di cui
hanno bisogno.
Le caratteristiche del Dublin Core, che lo distinguono da altri descrittori di risorse
elettroniche, sono queste:
•
Semplicità: la maggior parte degli elementi non sono più difficili da capire di un
catalogo di una biblioteca.
•
Interoperabilità semantica: l'insieme dei descrittori usati aumenta la possibilità di
ritrovare quello che si cerca anche attraverso varie discipline.
•
Consenso internazionale: il Dublin Core è promosso in più di 20 paesi in Nord
America, Europa, Australia e Asia.
•
Estensibilità: è flessibile e può essere esteso fino a incorporare strutture semantiche
che si trovano si solito solo in standard descrittivi molto ricchi.
Attualmente il World Wide Web Consortium (W3C) ha cominciato a implementare
un'architettura per i metadata sul Web. Il Dublin Core Resource Description Framework
(RDF = Quadro di riferimento per la descrizione delle risorse) è progettato per supportare
38
Capitolo 2
La formazione a distanza
diversi metadata. Rappresentanti del Dublin Core sono attivamente coinvolti nello sviluppo
di questa architettura[14].
2.3 Contenuti universalmente riutilizzabili
Lo SCORM è il modello di riferimento per la condivisione dei contenuti didattici o
courseware. Qualche tempo fa SCORM, nella sua versione 1.0, corrispondeva a "Sharable
Courseware Object Reference Model" (modello di riferimento per oggetti di courseware
condivisibili), poi sostituito con "Sharable Content Object Reference Model" nella
versione 1.1, ma il significato rimane lo stesso: sempre di courseware stiamo parlando,
anche se in una accezione forse più generale.
2.3.1 SCORM
SCORM è un modello tecnico di condivisione dei contenuti per renderli
"interoperabili". Quindi prima di tutto SCORM nasce come una raccolta di indicazioni per
gli sviluppatori di piattaforme LMS ( Learning Management System) e per i produttori di
courseware affinché i loro rispettivi prodotti siano facilmente interfacciabili gli uni con gli
altri.
Molte attività di e-learning oggi prevedono che i servizi per ottimizzare la fruizione
di corsi siano raccolti su un'unica piattaforma software operante via web, l'LMS (learning
management system), che si occupa anche di "lanciare" i contenuti didattici (appunto il
courseware), di fare un'analisi dei bisogni di apprendimento, di stabilire in quale misura e
ordine i singoli elementi di contenuto (learning object) devono essere organizzati, si occupa
quindi di tenere traccia della loro fruizione da parte degli allievi e riporta i risultati
dell'acquisizione delle competenze o quanto meno dell'attività di studio.
In genere le pagine di un courseware sono pagine web, costruite con criteri specifici
per facilitare lo studio, la comprensione e l'apprendimento, ma tecnicamente, dal punto di
vista informatico, sono normali pagine web, che utilizzano la stessa tecnologia dei siti web,
testi, immagini, animazioni e così via. Le pagine sono collegate fra loro da normali
"iperlink" o collegamenti ipertestuali che permettono di percorrere il camino tracciato
lungo la struttura dei contenuti.
39
Capitolo 2
La formazione a distanza
Ma il parallelo forse finisce qui. Costruire un oggetto per apprendere è
concettualmente cosa del tutto diversa dal costruirne uno per informare o semplicemente
per documentare. I processi attentivi, le attività "cognitive" che vengono svolte in fase di
studio, sono assai diversi da quelli che applichiamo al sito di un quotidiano, ad un motore
di ricerca, ad un sito comunque informativo. Anche tra un LMS ed un normale sito web ci
sono molte differenze. La differenza maggiore forse è che l'LMS in genere sa cosa deve
inviare all'utente al verificarsi di certi eventi (risposta ad una certa domanda,
completamento di un certo percorso, punteggio riportato in una certa azione, ecc.) e sa
documentare in modo assai dettagliato il comportamento di chi studia, elaborando anche
dei report che traggono conclusioni sull'efficacia dello studio concluso. In una parola il
processo formativo, per flessibile ed aperto che sia, deve subire una progettazione
dettagliata del processo che lo accompagna, forse tanto più dettagliata quanto più aperto e
flessibile vogliamo possa essere lo studio. I normali siti web invece non hanno bisogno di
trarre conclusioni sulla comprensione o apprendimento dei contenuti dei loro visitatori. I
rilevamenti a cui, facoltativamente si ispirano, sono di natura assai più genericamente
statistica.
2.3.2 Da dove deriva
La ADL (advanced distributed learning) Iniziative, sponsorizzato dal Dipartimento
della Difesa USA (DoD), "… è un programma collaborativo tra governo, industria e
università per definire un nuovo ambiente distribuito di apprendimento che permetta
l'interoperabilità degli strumenti per l'apprendimento e dei contenuti dei corsi su scala
globale. La missione dell'ADL è quella di favorire l'accesso ai servizi migliori di educazione
e formazione, personalizzati sui bisogni individuali, distribuiti con efficienza economica in
ogni luogo e momento ".(http://www.adlnet.org/index.cfm?fuseaction=home)
Ma la ADL non ha operato da zero. Anzi ha promosso il recupero di procedure e
standard già esistenti, ha creato gruppi di lavoro coinvolgendo altre organizzazioni e
mutuando da queste semilavorati per la costruzione dello standard. Il suo obiettivo è quello
di arrivare ad uno standard "de jure" oltre che "de facto"[9].
40
Capitolo 2
La formazione a distanza
2.3.3 Com’è organizzato
Le specifiche del modello SCORM sono organizzate in una libreria. Il volume 1
(Overvue) è dedicato ad una descrizione dello scenario, il volume 2 (Content Aggregation
Model) definisce i vari aspetti dell'aggregazione dei contenuti, il volume 3 (Run Time
Environment) si occupa dell'ambiente di erogazione del corso, detto spesso "piattaforma"
o "LMS".
Figura 7. L'organizzazione dello standard SCORM
Tralasciando il primo, del quale in sostanza abbiamo già parlato, occupiamoci ora
degli altri due volumi: i contenuti e l'erogazione dei corsi.
2.3.4 Content Aggregation Model (Modello di aggregazione dei
contenuti)
Questo modello di aggregazione dei contenuti e diviso in tre parti:
41
Capitolo 2
•
La formazione a distanza
Il contributo di IMS per la definizione dei metadata dei contenuti, le correlazioni dei
tag in XML, l'analisi di best practices.
•
Il dizionario dei metadata prodotto da IEEE
•
L'impacchettamento dei contenuti in XML dovuto ancora a IMS.
Vediamo brevemente di cosa si occupano questa tre sezioni.
Consideriamo per primo il dizionario dei metadata, cioè i "Learning Object
Metadata" (metadati degli oggetti di apprendimento). Se ricordiamo cosa sono i metadati,
capiremo perché ADL ha organizzato qui un "dizionario" di "tag" [2] che possono essere
usate per descrivere i contenuti per l'apprendimento in una varietà di modi, prendendo
soprattutto sia da IEEE (ma anche da ARIADNE, Public Core e IMS). I metadata infatti
servono a descrivere di quale contenuto stiamo trattando, chi lo ha prodotto o lo
distribuisce, per quale scopo formativo, quali i prerequisiti tecnici, quali i costi, ecc.
Quindi abbiamo le correlazioni fra i tag dei metadati in linguaggio XML, cioè l'
"XML binding".
Infine abbiamo le specifiche di impacchettamento dei file dovute a IMS (IMS
Content Packaging). Il problema dell'impacchettamento lo conosce bene chi ha mai avuto
necessità di spedire file HTML. Infatti questi sono interpretati dal browser che collega
automaticamente fra loro risorse diverse (pagina HTML puramente detta, immagini di vario
genere e formato, ecc.). Se si spedisce solo il file HTML si perderanno le altre risorse. La
modalità più comune è quindi quella di "zippare" assieme tutti i file relativi alla stessa
pagina web o addirittura a più pagine che costituiscono un intero documento ipertestuale,
con le relative cartelle. Queste specifiche di impacchettamento assolvono ad un funzione
analoga anche se più sofisticata, come vedremo in seguito.
2.3.5 Il “Run Time Environment” (ambiente di erogazione)
Questa definizione della piattaforma o ambiente di erogazione è divisa in due parti,
entrambe derivanti dalla collaborazione con AICC:
•
Il modello dei dati (data model);
•
Le modalità di lancio e interfaccia di comunicazione con la piattaforma (Launch,
communication API).
42
Capitolo 2
La formazione a distanza
Il modello dei dati serva a stabilire quali dati scambiare tra Learning Object e LMS.
Tempi e percentuali di fruizione dei contenuti, punteggi, competenze acquisite, ecc. Questo
modello quindi serve a stabilire come "tracciare" l'attività dell'allievo all'interno del
courseware.
Quindi è stata definita una modalità di lancio del contenuto e soprattutto una
interfaccia di comunicazione tra il contenuto (e quindi chi lo sta studiando) ed il sistema
LMS. Le specifiche sviluppate da ADL in collaborazione con AICC si basano su un
approccio user-friendly che utilizza Javascript. È stata definita un' API - Application
Program Interface (interfaccia del programma di applicazione) che stabilisce una modalità
standard di comunicazione con il LMS, indipendentemente da come sono stati sviluppati i
contenuti stessi.
2.3.6 Gli elementi minimi di contenuto
Come abbiamo capito la gran parte della problematica dello SCORM ruota attorno
alla costruzione degli oggetti di contenuto. Vediamoli quindi in dettaglio.
2.3.6.1 Gli Asset
Le risorse che possono essere condivise all'interno di un corso e costituiscono i
"beni" di un corso, sono dette appunto "asset". Queste sono genericamente costituite da
pagine web in HTML, documenti XML, immagini jpeg, file audio, video mpeg, file di vario
tipo. L'asset o shareable resource, è una risorsa che può essere condivisa, un risorsa che si
può ricercare e trovare all'interno di archivi on-line e quindi riutilizzabile in altre sequenze
rispetto a quelle originali per cui era stata pensata e creata. Per SCORM un asset è un
insieme di risorse che sono prodotte per essere condivise anche da più parti di un corso.
Quando viene composto un asset dovrebbe contenere i dati appropriati che lo descrivono
per far si che possa essere ritrovato in archivi on-line. L'asset quindi può essere considerato
l'elemento minimo di comunicazione che la tecnologia permette di produrre.
2.3.6.2 Lo SCO(Shereable Content Object)
Lo SCO è un insieme di risorse o asset progettato in modo da rispondere al
raggiungimento di un obiettivo didattico, all'acquisizione di una competenza e rappresenta
l'unità didattica minima in cui il corso è suddiviso.
43
Capitolo 2
La formazione a distanza
Lo SCO inoltre è stato progettato in modo che implementi anche lo scambio di dati
del sistema LMS, secondo le specifiche del "run time" dello SCORM.
Della necessità di strutturare il percorso di apprendimento in unità didattiche
minime ne abbiamo parlato già all'inizio di questo articolo. Possiamo quindi dire che lo
SCO è il "learning object" minimo del modello SCORM, che risponde a tutti i requisiti
definiti fin qui.
Un asset quindi è un elemento comunicativo minimo, mentre uno SCO è
quell'elemento minimo che ha significato dal punto di vista didattico ed in genere
raggruppa più asset.
2.3.7 Il courseware
Il courseware infine è un insieme di SCO organizzati secondo sequenze definite dai
fabbisogni formativi, attorno ad un unico elemento di gestione, il "manifest".
Il manifest è un file XML che spiega come sono aggregati gli SCO e fornisce anche
il riferimento per la navigazione tra uno SCO e gli altri.
Le linee guida dell'ADL forniscono un'articolazione delle modalità di navigazione
tra uno SCO e l'altro che può essere riassunto nei punti seguenti:
•
Lineare
•
Gerarchica
•
A griglia
•
Con modalità web
•
Con modalità empirica
La navigazione tra gli SCO è sola responsabilità del sistema LMS. Uno SCO non
può mai lanciare un altro SCO, mentre si è liberi di definire qualsiasi tipo di navigazione
all'interno dello SCO stesso. Occorre creare uno schema di navigazione tra gli SCO
mediante le opzioni seguenti:
•
javascript e frame
•
java applet
•
plugin
44
Capitolo 2
La formazione a distanza
2.4 DVB-MHP e FAD: le potenzialità
Nel corso dei paragrafi precedenti si è tentato di dare un rapido sguardo
all’immenso mondo della formazione a distanza. Il suo evolvere va di pari passo con lo
sviluppo tecnologico e culturale della società. Il carattere stesso del mondo moderno porta i
singoli individui ad essere “costretti” ad un aggiornamento costante delle proprie
competenze o ad acquisirne di nuove. Per rendere questo bisogno di conoscenza il più
piacevole ed efficace possibile è utile, oltre che necessario avvalersi delle nuove tecnologie,
che da sempre stuzzicano la curiosità delle persone a prescindere dal loro ceto sociale.
L’avvento di Internet ha favorito la nascita di numerose iniziative : piattaforme a distanza di
tipo proprietario e non, nascita di vari standard con il compito di dare un carattere di
universalità al sapere depositato. Uno su tutti lo standard SCORM con lo scopo di tentare
di dare potenzialità universalmente indipendente dalle varie piattaforme utilizzate per
accedere
ai
contenuti.
Questi
possono
essere
raggiunti
da
tutto
il
mondo
indipendentemente sia dal mezzo di comunicazione che dalla piattaforma che si sta
utilizzando .
Figura 8. La visione di un sapere globalmente distribuibile ed accessibile
45
Capitolo 2
La formazione a distanza
Proprio il tentativo di rendere il sapere disponibile a tutti in tutto il mondo ha dato
il via ad una serie di studi per l’utilizzo di altre tecnologie (oltre ad internet) come quella dei
dispositivi mobili e per ultima, non certo per importanza, la Tv digitale terrestre. Grazie
infatti alla possibilità di sfruttare il canale di ritorno per la fruizione dei servizi applicativi
DVB-MHP il mezzo televisivo acquisisce una nuova veste innovativa, diventa cioè il punto
di incontro dei media. Integra la sua funzione di mezzo di informazione e di
intrattenimento con quella di mezzo per la fruizione di servizi che fino ad ora erano
prerogativa del mondo Web. Il carattere “user-friendly” della Tv unito alla ricchezza dei
contenuti Web rende il sapere di più facile ed efficace accesso.
In base a queste considerazioni in Gran Bretagna sono in atto numerosi studi sulla
possibilità e l’efficacia dell’utilizzo della Tv digitale e della banda larga per la formazione a
distanza.
Nel corso dell’ anno 2003 la pjb Associates ha portato a termine una serie di
indagini globali che vanno sotto il nome di “T-Learning study ” un progetto finanziato
dalla Commissione Europea. Un ulteriore incentivo che ha spinto vero uno studio di
questo tipo è il grado di penetrazione della TV (95-99%) confrontato con quello del PC
(40-60%). Ciò ha fatto ipotizzare “T-Learning” - che vuol dire per l'appunto
apprendimento attraverso la televisione digitale interattiva –
potesse creare nuove
opportunità per l’apprendimento nel contesto domestico.
Pjb Associates ha tenuto ben delineata la traccia del lavoro fatto per seguire gli
sviluppi di tale studio.
Nel 1999 è stato completato uno studio per conto della Commissione Europea Tv
Interattiva e Servizi per l’apprendimento a distanza ed il “T-Learning study” può
considerarsi la prosecuzione di tale studio. Sono stati prodotti un certo numero di studi del
caso e di scenari futuri come facenti parte del t-learning study. Sono state organizzate
risorse on-line ed effettuati dei servizi a cadenza regolare. Ci sono anche degli utili links ad
altre newsletter e giornali e persino ad altre organizzazioni che si occupano dello studio
dello stesso problema[15].
46
Capitolo 2
La formazione a distanza
Nel 2002 la Learning and Skills Development Agency commissionò alla Pjb
Associates uno studio sull’ apprendimento
sfruttando la televisione interattiva. Tutto
questo è risultato in una pubblicazione dal nome: “A learning platform with potential”.
Nel 2004 la pjb Associates ha continuato l’opera di monitoraggio della fruizione di
servizi per l’apprendimento e per il perfezionamento attraverso la Tv digitale interattiva[15].
2.4.1 Risultati temporanei
2.4.1.1 Conclusioni chiave
Nel complesso è emerso che c’è un grande interesse riguardo all’utilizzo dei vari tipi
di Tv interattiva per l’incremento delle opportunità di imparare a casa, in particolare come
valida alternativa ad un computer dotato di una connessione ad internet. Un interesse di
questo tipo è suscitato anche a livello politico perché i capi di governo vedono, nell’utilizzo
delle varie televisioni interattive, un’arma vincente per abbattere il cosiddetto “digitaldivide”. Sfortunatamente in oltre 25 anni di broadcasting educativo manca ancora uno
studio adeguato a livello pedagogico. Cioè ci si è interessati poco a studiare l’efficacia di un
corso diffuso attraverso la televisione. La ricerca che è stata condotta ha identificato molte
soluzioni di Tv interattiva sia esistenti che emergenti. Sono stati anche identificati numerosi
modelli per lo sviluppo di servizi di learning, anche se sembra essere necessaria un
approfondita indagine di mercato[15].
2.4.1.2 Problemi di strategia di Learning
Nell’era emergente del “LifeLongLearning”(dell’apprendimento che interessa
tutta la vita), la formazione a distanza prenderà posto in un enorme varietà di contesti e di
localizzazioni, cosi che il learning formale ed informale assumeranno la stessa importanza
del learning convenzionale.
Sembra che un terzo degli adulti in certe regioni non abbia voluto prendere parte
alla sperimentazione perché erano troppo disabituati all’apprendere sin dall’età della scuola
dell’obbligo. La politica dei vari governi sembra essere orientata all’utilizzo delle tecnologie
di informazione e comunicazione per incrementare le opportunità di imparare, sebbene con
un maggior focus sull’uso dei computer collegati ad internet. Muovendosi in questa
47
Capitolo 2
La formazione a distanza
direzione si è aumentato l’interesse di chi già era indirizzato a tale modo di imparare ma si è
fiduciosi di coinvolgere anche coloro che fanno parte della schiera dei non interessati.
La penetrazione dei computer collegati ad internet nell’ambiente domestico
europeo sembra essere livellata intorno al 40-60 %. Iniziative commerciali per la diffusione
di computer a basso costo hanno dimostrato che la soglia non si alzava mai al di sopra del
70%. Erano pertanto necessarie altre strategie per incoraggiare la gente a diventare più
attiva nell’imparare cosi da abbattere il cosiddetto “digital-divide”. Quindi era necessario
avvicinarsi a delle soluzioni o a dei dispositivi che la gente sentiva più vicina a se perché
facente parte della propria vita quotidiana e soprattutto facile ed intuitivo da usare. La
televisione, più altri dispositivi sviluppatisi direttamente dalla telefonia mobile; le console
per giocare sono tutti degli strumenti che possono essere usati per incrementare la
possibilità di imparare in questo modo. L’ambiente domestico viene considerato come
ideale per apprendere tanto da supporre che possa aumentare le prestazioni di coloro che
vogliono studiare.
La televisione è un dispositivo familiare con circa il 90-95% di penetrazione nelle
case Europee e, nonostante l’uso passivo che se ne faccia a discapito di un uso attivointerattivo, viene sentito come ciò che potrebbe incrementare l’apprendimento[15].
2.4.1.3 Il ruolo della Tv interattiva nel Learning
La Tv interattiva, laddove sia disponibile riesce a proporre delle limitate offerte di
learning ed a volte addirittura costose. La tendenza è quella di “edutainment”(mix tra
intrattenimento ed educazione) piuttosto che incoraggiare una vera e propria televisione
interattiva. I vari broadcasters stanno tutt’ora sperimentando servizi per il learning su
televisione. Una grande pecca della Tv digitale è la limitatezza grafica che la rende meno
accattivante del mezzo televisivo odierno. Il video on demand è senza dubbio un valore
aggiunto che quando sarà disponibile dovrà essere sfruttato. A meno che non ci siano delle
importanti innovazioni tecnologiche le opportunità del learning attraverso la Tv broadcast
o la Tv a programmi sembra che saranno sempre limitate.
Quello che si evince è che è necessario un utilizzo della tv attivo piuttosto che
passivo. Focalizzarsi sulla tv dai contenuti personalizzati vuol dire creare nuove opportunità
per un apprendimento personalizzato che arriva nell’ambiente domestico[15].
48
Capitolo 2
La formazione a distanza
2.4.1.4 Problemi tecnici
Complessivamente, molti problemi tecnici risultano essere più dei veri e propri
problemi di mercato. Molte soluzioni tecniche esistono e sono disponibili ma non vengono
adottate per ragioni di mercato. Molti modelli potrebbero essere sviluppati ma non
vengono portati a termine perché le tendenze di mercato non ne favoriscono lo sviluppo.
Sta venendo fuori un ampio standard Europeo per i stb che utilizzano la
piattaforma DVB-MHP. Comunque, la maggior parte delle regioni interessate hanno dei set
top box proprietari ed i service provider potrebbero impiegare molti anni prima di adottare
l’MHP o addirittura non adottarlo mai. In tale direzione c’è una certa resistenza ad
intervenire da parte delle autorità.
Le decisioni prese in termini di standard sono quelle che determinano il modo in
cui devono essere veicolate le trasmissioni televisive. Qualcosa è venuto fuori durante i
lavori del “TV Anytime Forum del 2003”.
Le decisioni concernenti un’adeguata provvigione della rete a banda larga alle
abitazioni sono guidate primariamente da ragioni di mercato piuttosto che da motivi di
natura prettamente tecnica dettate dalle aree urbane.
Sebbene ci siano dei problemi per la provvigione di una banda adeguata alle singole
abitazioni si stanno trovando molte soluzioni. Ovviamente è necessario l’intervento del
governo per assicurare un accesso universale.
L’industria del broadcast sta aggiungendo metadata ai propri contenuti affinché essi
siano reperibili più facilmente. C’è anche una lavoro parallelo di standardizzazione dei
learning objects. Entrambi questi sviluppi necessitano di lavorare molto strettamente l’uno
con l’altro con lo scopo di far si che i contenuti dell’apprendimento a distanza siano più
facilmente accessibili attraverso le soluzioni offerte dalla Tv interattiva[15].
2.4.1.5 Tv personalizzata
Si sta lavorando affinché la Tv diventi una televisione personalizzata, cioè con
contenuti disponibili su misura per l’utente. Questo sicuramente spingerà ancora di più la
curiosità e quindi lo sviluppo di servizi che richiedono una partecipazione attiva dello
spettatore quali sono appunto quelli per l’apprendimento a distanza. A lungo andare la
personalizzazione che verrà fatta della televisione sarà cosi all’ordine del giorno da risultare
impercettibile.
49
Capitolo 2
La formazione a distanza
A breve termine è prevista l’integrazione della tecnologia ADSL con quella
satellitare per la provvigione della larga banda anche in zone urbanizzate non raggiunte dal
servizio della larga banda. Il learning è solo una parte di un progetto più vasto che riguarda
lo sviluppo di servizi per l’ambiente domestico[15].
Figura 9. L'uomo al vertice del mondo informativo
2.4.1.6 Problemi di mercato inerenti allo sviluppo di servizi di Learning
La Tv interattiva fa parte di un mercato che si trova in ascesa nonostante un lungo
periodo di recessione. L’affare educazione e insegnamento ha uno scarso controllo di questi
sviluppi e dipende da uno scarso numero di fornitori della televisione interattiva.
Le barriere per entrare nel mercato della Tv interattiva digitale sono alte per il
business del learning se comparato a quello dell’utilizzo del web. Sono richiesti un gran
numero di passi avanti prima che ogni tipo di mercato di learning emerga. Tutti questi passi
avanti possono costituire allo stesso tempo delle barriere potenziali a questo tipo di
evoluzione.
È altamente probabile che lo sviluppo dell’apprendimento interattivo collegato alla
televisione broadcast sarà limitato. È più probabile che la situazione sarà presa
completamente in mano dai broadcaster per offrire “edutainment” in concomitanza con i
programmi broadcast. La più grossa occasione verrà dall’introduzione del video-ondemand. Le previsioni lasciano intravedere che da qui a 10 anni gli spettatori useranno la tv
50
Capitolo 2
La formazione a distanza
in maniera personalizzata. Si stima che sarà circa il 60% del numero degli spettatori
totali[15].
2.4.1.7 Tv in modo personalizzato
Si è visto che uno scenario probabile è quello di istituire un tutor remoto via TV
nella casa considerando che possa essere realistico e realizzabile.
Altri scenari considerati come probabili sono :
•
Continuo sviluppo professionale degli insegnanti;
•
Esami per la scuola statale;
•
Un canale virtuale professionale;
•
Imparare da solo.
Mentre scenari per la televisione interattiva digitale personalizzata sono:
•
scuola a casa;
•
corsi di lingua per le vacanze.
2.4.1.8 I costi di accesso al learning attraverso la Tv digitale
Dato il carattere prematuro del mercato del learning non è possibile prevedere il
costo di accesso ad un servizio del genere attraverso le varie forme di Tv interattiva per gli
individui e le famiglie. Ovviamente ci si aspetta un servizio senza costi da parte dei
broadcasters pubblici. Dove ci sarà l’interesse dello stato o delle regioni sarà possibile
sperimentare anche il servizio fornito già dalle istituzioni statali in merito alla diffusione
dell’informazione.
In alcuni casi la Tv interattiva sarà una vera e propria esca per attrarre lo studente
all’interno di centri per l’apprendimento o di veri e propri campus per l’apprendimento a
distanza.
Una parte notevole della sperimentazione consiste nel recupero di servizi già
esistenti, come l’adattamento di piattaforme esistenti per il Web da trasportare su DTT[15].
2.4.1.9 Apprendimento e problemi pedagogici
Sebbene sia probabilmente accettato che la televisione nel suo formato tradizionale
è un mezzo veramente potente, la ricerca per stabilire quale sia il suo ruolo nel campo del
51
Capitolo 2
La formazione a distanza
learning è piuttosto limitata. La ricerca tende a focalizzarsi sull’impatto che la Tv ha sugli
individui.
A discapito del fatto che si spera che molte persone in futuro impareranno da casa,
rimane da studiare come e quali possano essere le condizioni ed i requisiti per i quali
l’ambiente domestico possa diventare un ottimo veicolo formativo.
La comprensione del ruolo dell’interattività è un processo molto complesso, e
purtroppo gli studi sull’apprendimento a distanza sono poco sostenuti.
La ricerca ha mostrato che l’inaspettato potenziale della televisione interattiva per
l’apprendimento evolve poco verso un tipo di educazione tecnologica.
Comunque, coloro che prendono le decisioni e coloro che le attuano una volta
resisi conto del range di possibilità che adesso stavano emergendo sono diventati più
positivi verso i potenziali che la TV digitale può offrire[15].
2.4.2 Raccomandazioni
2.4.2.1 Raccomandazioni strategiche
Generalmente il focus deve essere improntato a stabilire una serie di progetti pilota
utilizzando video registrati e servizi del tipo con contenuti di video-on-demand per
incrementare le opportunità di learning nell’ambiente domestico.
Incoraggiare lo sviluppo di contenuti che possano essere controllati nel rispetto
della multicanalità, cioè ad ampio raggio con tutti i tipi di dispositivi di diffusione
tecnologici.
C’è bisogno di uno studio per capire come veramente apprendono le persone
nell’ambiente domestico e quali siano i vantaggi di apprendere a casa rispetto ad apprendere
in altri luoghi. Sono necessari degli studi di tipo sociopedagogico per capire quale sia il vero
impatto dell’apprendimento attraverso un utilizzo attivo della televisione.
C’è inoltre bisogno di uno studio relativo a quale tipo di interattività sia necessaria
per il learning. Cioè quale tipo sia il più adatto per suscitare nell’utente la curiosità e lo
stimolo che favoriscano l’utilizzo del servizio.
La disponibilità della larga banda è un fattore molto influente, deve diventare un
bene primario, quasi come l’acqua. Si è visto che una scarsa diffusione della larga banda è
52
Capitolo 2
La formazione a distanza
più dovuta alla politica che a delle vere e proprie limitazioni tecniche e fisiche dei luoghi
dove vivono le persone[15].
2.4.2.2 Ricerca sulle tecnologie del learning
Si dovrebbe dar vita a dei progetti pilota per capire meglio come utilizzare nel
modo più proficuo l’interattività limitata della Tv broadcast. L’obiettivo è quello di
ingaggiare un gruppo di persone che sono difficili da raggiungere con i mezzi informativi di
istruzione tradizionali, per farli passare da un modo passivo ad un modo attivo di usare il
mezzo televisivo.
È necessario sviluppare sistemi di personalizzazione appropriati e tool che rendano
i contenuti del learning più facili da essere recepiti attraverso i sistemi di TV Personalizzata
e di studiare l’apprendimento che viene distribuito attraverso il gioco televisivo.
Le ricerche future non vedono il learning nell’ambiente domestico come isolato
rispetto agli altri tipi di learning. Gli studi futuri riguardo al learning devono prevedere
l’utilizzo di qualsiasi dispositivo di comunicazione come può essere un PDA, telefoni 2.5 e
3G, console per giochi, PC portatili e desktop, dispositivi di immagazzinamento locale,
accesso a dispositivi di immagazzinamento remoto, comunicazioni senza fili, server
casalinghi[15].
53
Capitolo 3
Le scelte progettuali
3
Capitolo 3
Le scelte progettuali
Dalla lettura di questo capitolo si potrà evincere quali sono state le problematiche
che ci siamo trovati a dover affrontare. Dapprima si passano in rassegna le metodologie da
adottare per lo sviluppo di un’applicazione per la Tv interattiva digitale ed in particolare su
piattaforma DVB-MHP ed a seguire, da uno studio approfondito della piattaforma di
formazione a distanza dell’Università degli Studi di Siena, scaturisce la pianificazione di una
strategia di sviluppo. Il lavoro viene suddiviso in fasi per ottenere quanto prima dei risultati
concreti a supporto delle ipotesi e per evitare di tornare a risolvere lo stesso problema più
volte.
3.1 Fase di specifica di un’applicazione per la Tv interattiva
La specifica di un’applicazione interattiva per il mondo DTT (Digital Terrestrial
Television) richiede, alla stregua delle specifiche per un’applicazione Web Based, la
definizione di un albero di navigazione di contenuti informativi (testo ed immagini) nonché
di tecnologie specifiche che possono essere associate al comportamento dell’applicazione
stessa durante il run-time e che l’utente fruitore del servizio può attivare a seconda del
contesto.
La navigazione dei contenuti messi a disposizione dello spettatore necessita quindi
di un’organizzazione logica, definendo una serie di layer grafici corrispondenti ai diversi
livelli che il telespettatore può raggiungere attraverso l’interazione del telecomando sul STB
(Set Top Box) e specificando dettagliatamente le condizioni di passaggio da un layer logico
all’altro. Il tutto deve essere pensato non solo nel rispetto delle limitazioni imposte dagli
standard ma anche della facilità di utilizzo intrinseca del mezzo televisivo, basata
sull’utilizzo dei tasti del telecomando (nello specifico i quattro tasti colorati e/o le quattro
frecce di scroll).
Si possono pensare 3 livelli diversi di astrazione per avvicinarsi alla fase di specifica:
•
Si può pensare di sviluppare i vari layer grafici con un adeguato editor grafico e di
affidare il compito di tradurre le specifiche in codice MHP eseguibile su STB allo
54
Capitolo 3
Le scelte progettuali
sviluppatore. Lo svantaggio di questo tipo di approccio è quello di ricordarsi che lo
standard MHP impone molte limitazione sull’uso di font grafici, colori, immagini fisse e in
movimento. Pertanto colui che curerà la parte grafica dovrà sempre tener presente tali
limitazioni per evitare di produrre specifiche non completamente implementabili nel
mondo MHP.
•
Un secondo livello di astrazione, che si fa carico sin dall’inizio delle limitazioni
imposte dallo standard MHP, è quello di utilizzare sin da questa fase un tool di sviluppo
specifico del mondo MHP, in grado di introdurre già nel processo di specifica i vincoli di
cui sopra. In questa accezione l’editor grafico non è più da intendersi come un generico
tool di supporto allo sviluppo grafico, ma come primo passo nello sviluppo del codice
MHP. Esistono molti tipi di authoring tool di questo tipo, uno su tutti Cardinal (tool
disponibile in laboratorio) che permettono di realizzare interfacce grafiche sfruttando un
approccio simbolico limitato alle specifiche MHP, sfruttando come sistema operativo
Windows. Questo tipo di tool appartengono alla categoria dello sviluppo perché partendo
dalla definizione di un’interfaccia grafica sono in grado di generare un codice scritto in
JAVA-MHP e quindi eseguibile su un STB.
•
Un terzo livello di astrazione, che può essere considerato una sorta di compromesso
tra i primi due, è quello di utilizzare, per la specifica del layout e del contenuto delle pagine
linguaggi di descrizione come DVB-HTML oppure un opportuno dialetto XML. Per poter
operare a questo livello sarà necessario, all’interno della catena che rappresenta
l’applicazione MHP, introdurre un anello con la funzione interpretativa del linguaggio
utilizzato. Sfruttando questo tipo di approccio è possibile vincolarci strettamente allo
standard MHP perché il dialetto definito è univoco e quindi non può portare a specifiche
non implementabili e per di più è possibile utilizzare un qualsiasi editor grafico
opportunamente customizzato alle specifiche supportate grazie all’approccio alla
“browser”[3].
3.1.1 Il nostro approccio
Basandoci sulle considerazioni precedenti, sulle tecnologie software ed hardware
messeci a disposizione e soprattutto data la complessità del lavoro che dovevamo
affrontare si è optato per un approccio alla browser che comprendesse però anche l’utilizzo
55
Capitolo 3
Le scelte progettuali
di un authoring tool di sviluppo. Ciò ci ha permesso di facilitare il lavoro lato client e di
concentrare lato server la maggior parte della logica di gestione della navigazione e della
manipolazione dei contenuti. Cosi facendo siamo riusciti ad ottenere un’applicazione MHP
leggera in termini di dimensioni e a far eseguire tutte le operazioni più onerose al browser
lato server. Si è così riusciti a creare una struttura software in Java[27] riutilizzabili in
contesti che esulano dal learning, adattabile ad estrarre contenuti organizzati in maniera
omogenea, cioè schematizzabili con un albero XML.
3.2 Studio della piattaforma di e-learning dell’Università degli
Studi di Siena
3.2.1 Il sito FAD.UNISI.IT
Una parte fondamentale del lavoro è consistita nell’analisi dell’output della
piattaforma di formazione a distanza dell’Università di Siena localizzabile all’indirizzo web
“http://fad.unisi.it”. Ne è stata analizzata l’architettura e l’organizzazione dei contenuti con
l’intento di trovare una possibile strategia per interfacciarvi un’applicazione MHP caricata
su STB (Set Top Box).
Ci siamo trovati di fronte alla seguente situazione:
•
L’accesso alla piattaforma di apprendimento a distanza viene effettuato tramite un
browser Web. Il che è possibile sfruttando un qualunque computer dotato di una
connessione ad Internet (V 90, xDSL, ecc…);
•
La ricezione dei contenuti avviene sottoforma di risposta alle richieste Http
effettuate utilizzando l’interfaccia grafica del browser Web alla piattaforma, la quale
restituisce pagine HTML attraverso tecnologia ASP.NET.
La piattaforma (che costituisce il nostro lato server) gestisce la sessione multiutente
e contiene l’intelligenza che serve per la navigazione delle pagine e la fruizione dei
contenuti[16].
56
Capitolo 3
Le scelte progettuali
SITUAZIONE PIATTAFORMA FAD UNISI
Sessioni
Richieste
HTTP
Browser
Web
Piattaforma
FAD
(ASP)
HTML RICCO
(HTML + Java Script)
Contenuti
Intelligenza
Figura 10. Logica della FAD
3.2.2 Architettura del sito
Quando viene richiamato l’URL: http://fad.unisi.it il server interpreta la richiesta e
restituisce al browser (o al client Http) di prelevare la prima pagina del sito con i relativi
contenuti. Vengono fornite informazioni riguardo ai servizi erogati dalla piattaforma di
apprendimento a distanza dell’Università di Siena, ai corsi di laurea, di lingue e di
informatica (ECDL) attivi. È presente un’area dedicata all’autenticazione dell’utente per
mezzo di username e password, dati che vengono forniti dal Q.it attraverso un’opportuna
registrazione.
Figura 11. La pagina di benvenuto della FAD
57
Capitolo 3
Le scelte progettuali
L’utente inserisce username e password e se la procedura di autenticazione va a
buon fine per mezzo di un pop-up viene visualizzata un’altra finestra all’interno della quale
l’utente fruirà del servizio. La prima pagina è quella dei profili che possono variare in tipo e
numero a seconda dell’utente.
L’utente che fruisce del servizio è vincolato a scorrere i nodi di un albero che ha
come nodo radice la pagina dei profili attivi:
•
Scelta profilo;
•
Scelta corso;
•
Scelta sezione;
•
Scelta modulo;
•
Scelta lezione.
Una visione generalizzata dell’albero che si trova a percorrere l’utente durante la
navigazione delle pagine del sito può essere resa dal seguente grafo(Figura 12):
Utente 1
Utente 2
Utente n-esimo
Profilo 1
Profilo 2
Profilo n-esimo
Corso 1
Corso 2
Corso n-esimo
Sezione 1
Sezione 2
Sezione n-esima
Modulo 1
Modulo 2
Modulo n-esimo
Lezione 1
Lezione 2
Lezione n-esima
Figura 12. Architettura della piattaforma di formazione a distanza dell'Università di Siena
Ciascun utente registrato può avere più profili attivati, ciascun profilo può
comprendere più corsi, ciascun corso è costituito di più sezioni, ciascuna sezione ha a
58
Capitolo 3
Le scelte progettuali
disposizione più moduli, ciascun modulo contiene una o più lezione e così via… il tutto è
regolato dalla presenza di opportuni link che permettono di spostarsi in avanti e indietro
nella navigazione e dal JAVASCRIPT che regola il ritorno alle pagine precedenti, la fase di
login, di logout, la possibilità di accedere al supporto di un tutor online ecc….
3.2.3 Organizzazione dei contenuti
Dall’analisi della struttura del sito siamo passati allo studio delle singole pagine con
lo scopo di identificare i contenuti che potessero essere riproposti sullo schermo televisivo
tramite la piattaforma DVB-MHP. Analizzando il layout di ciascuna pagina si può notare
come questa possa essere vista come una grossa area (rettangolo) con all’interno tante
sottoaree (rettangoli più piccoli) contenenti ciascuna una parte del contenuto informativo di
tutta la pagina.
Figura 13. Area (rettangolo) contente la parte di informazione più significativa
59
Capitolo 3
Le scelte progettuali
Dalla pagina dei profili in poi il contenuto è organizzato in :
•
Area di Localizzazione – recante il nome del nodo dell’albero in cui ci troviamo
(Sezioni, Moduli, Lezione ecc…);
•
Area di Benvenuto - recante nome, cognome, tempo di durata della connessione,
link per poter cambiare la password e link per potersi scollegare;
•
Area Catalogo Corsi – recante i corsi che non sono attivi ma che l’utente può
attivare nel profilo in cui si trova;
•
Area Legenda – recante una sorta di piccolo help in linea in cui viene spiegato il
significato delle icone utilizzate;
•
Area Supporto – recante link al Q.it e link all’indirizzo e-mail di supporto agli utenti
FAD;
•
Area Principale – recante, a seconda dei casi, le informazioni per la navigazione e
per la lezione del corso vero e proprio.
Le Figura 13 e Figura 14 sono tratte dal sito nel contesto delle lezioni, e si nota
come già specificato, che la parte essenziale dei contenuti è racchiusa nell’area (rettangolo)
evidenziata.
Figura 14. Area (rettangolo) contenente la parte di informazione più significativa
60
Capitolo 3
Le scelte progettuali
3.2.4 Strategie di interfacciamento
Attraverso l’analisi del sito (che corrisponde all’output della piattaforma FAD) e
dallo studio dello standard MHP, di cui si è discusso in maniera dettagliata nel primo
capitolo, ci siamo resi conto che la parte che pone più vincoli al nostro progetto è senza
dubbio il lato client, cioè la parte dell’applicazione attraverso la quale l’utente interagisce
con il lato server (in questo caso la piattaforma di apprendimento a distanza) .
Il fatto che l’applicazione lato client sia di tipo MHP impone molti vincoli sulla
quantità ed il tipo di contenuti che possono essere visualizzati sullo schermo televisivo.
Anche la navigabilità risulta limitata, in quanto gestita tramite un numero minimo di
pulsanti del telecomando. L’ambiente web è senza dubbio meno restrittivo perchè dispone
di potenza di calcolo elevata e di mezzi di interfaccia molto più efficienti quali tastiera e
mouse. Il nostro scopo è stato quello di pensare ad una possibile soluzione che rendesse
realizzabile la fruizione di contenuti nati e residenti sul Web in modo facile ed intuitivo nel
pieno rispetto del carattere “user-friendly” del mezzo televisivo riuscendo ad introdurre
innovazione sottoforma di interattività. Per fare questo abbiamo puntato sull’utilizzo
massiccio del canale di ritorno, la vera componente innovativa introdotta dalla Tv digitale
terrestre.
Sono state esaminate varie strategie di interfacciamento tra le quali le più accreditate
sono state:
•
Realizzazione di un micro-browser di contenuti HTML;
•
Realizzazione di un proxy-server con la funzione di gateway applicativo tra FAD e
piattaforma DVB-MHP.
Di entrambe le soluzioni sono stati vagliati i pro e i contro. I parametri che hanno
influenzato la scelta della soluzione da implementare sono stati: la ridotta potenza di
calcolo messa a disposizione dai STB in commercio e la versatilità in termini di utilizzo
dell’applicazione futura. Dopo un’accurata analisi, la soluzione che si è deciso di
implementare è stata la seconda. Lo sviluppo di un micro-browser di contenuti HTML
sarebbe stata una soluzione troppo dedicata e vincolata dalle scarse risorse hardware in
termini di memoria e di potenza di calcolo. Ne avrebbe risentito il funzionamento
dell’applicazione in termini prestazionali proprio per questioni di banda a causa dello spazio
occupato dai contenuti all’interno della cache del STB. Invece lo sviluppo di un proxy-
61
Capitolo 3
Le scelte progettuali
server ci ha permesso di alleggerire quanto più possibile l’applicazione client e di sfruttare
delle tecnologie il cui funzionamento è ben consolidato nel mondo di internet. Il grosso del
lavoro viene effettuato lato server permettendo l’utilizzo dell’applicazione per
l’interfacciamento con altre piattaforme, ovviamente apportando delle opportune
modifiche. Una soluzione certamente indirizzata alla multicanalità.
3.2.4.1 Il gateway applicativo di interfaccia
Alla luce delle limitazioni sia hardware che software imposte lato client si è scelto di
seguire la soluzione prospettata dal proxy-server. Si è ipotizzato di poter sviluppare lato
server (in cui si suppone di avere a disposizione tutta la potenza di calcolo di cui si
abbisogna) un applicativo java[27] in grado di gestire le richieste effettuate lato client
attraverso il telecomando. La Figura 15 mostra il funzionamento generale del sistema con la
soluzione adottata.
SOLUZIONE SCELTA = PROXY-SERVER
L’applicazione client MHP effettua delle
richieste HTTP al proxy-server. Tali richieste
vanno definite sintatticamente
1
Richiesta HTTP
Il proxy-server inoltra le richieste
necessarie alla FAD con le
informazioni aggiuntive necessarie
2
Inoltro richiesta
PROXYSERVER
CLIENT
MHP
Contenuti XHTML
5
Parsing dello
streaming XHTML
FAD
Output HTML ricco
4
Parsing della pagina HTML ricevuta.
Estrapolazione dei contenuti e
costruzione dello streaming XHTML
3
La piattaforma risponde con
il corrispondente output
HTML
Figura 15. Schematica rappresentazione del funzionamento della soluzione scelta
L’utente interagisce con la piattaforma per mezzo del lato client MHP che accoglie
ed inoltra le richieste effettuate per mezzo della pressione del telecomando. Il client effettua
le opportune richieste Http al proxy-server che le interpreta e le smista alla FAD
aggiungendo, se necessario, delle informazioni aggiuntive. A questo punto il sito restituisce
62
Capitolo 3
Le scelte progettuali
in output pagine HTML prodotte con tecnologia ASP.NET. Il proxy-server legge ed
elabora l’output della piattaforma di apprendimento a distanza effettuando in successione:
•
Parsing dell’HTML;
•
Estrapolazione dei contenuti da visualizzare;
•
Costruzione del file XHTML.
Svolte queste operazioni, il proxy-server restituisce al client MHP i contenuti (testo
e link ad immagine e approfondimenti) risultanti dal filtraggio sotto forma di file XHTML.
L’applicazione MHP incorpora un parser XHTML in grado di estrarre i contenuti di
interesse e di restituirli ai componenti grafici per la loro presentazione.
3.2.4.2 Vantaggi e svantaggi dell’approccio
La decisione di sviluppare un proxy-server rappresenta una soluzione vantaggiosa
sotto il profilo della disponibilità di risorse hardware e della potenza di calcolo, almeno a
livello teorico, necessaria all’opera di interfacciamento.
La scelta dell’XHTML come linguaggio di output favorisce la fruizione del servizio
in un contesto di multicanalità in quanto molti dispositivi disponibili sul mercato sono
dotati di micro-browser XHTML “embedded”: mobile UMTS, PDA, ecc… Per non
dimenticare il fatto che in questo modo si garantisce la piena compatibilità con le
implementazioni delle specifiche MHP 1.1 che prevedono di affiancare alla JVM (Java
Virtual Machine) un micro-browser di contenuti XHTML.
Oltre agli aspetti positivi che ci hanno permesso di optare per questo tipo di
soluzione al posto di un’altra, sono presenti anche dei lati negativi, diretta conseguenza
delle limitazioni tecnologiche in cui ci siamo trovati ad operare. Una fra tutte, il fatto che il
canale di ritorno viene realizzato sfruttando una connessione telefonica a 56 Kbps con tutti
gli svantaggi del caso (lentezza nello stabilire una connessione e limitatezza di banda).
Come abbiamo visto, prima che l’interfaccia client possa sistemare i contenuti all’interno
dello schermo televisivo sono necessari diversi passaggi che sommati alla lentezza del
collegamento telefonico rallentano molto l’esecuzione dell’applicazione. Inoltre, pesando ad
un utilizzo dell’applicazione in un contesto multiutente la situazione si appesantisce
ulteriormente visto che la probabilità di trovare il proxy-server occupato dalle richieste di
un altro utente è più alta e ciò obbliga le richieste degli altri utenti a rimanere in coda
facendo rallentare notevolmente le prestazioni del servizio nel suo complesso. Proprio
63
Capitolo 3
Le scelte progettuali
questa latenza intrinseca ci ha portato all’adozione di una cache all’interno del proxy-server
in maniera tale da velocizzare il processo di acquisizione dei contenuti lato client per mezzo
di pagine XHTML già pronte per essere indirizzate all’applicazione MHP.
3.2.5 Pianificazione dell’iter di sviluppo
Vista la complessità del lavoro si è deciso di pianificare con cura l’implementazione
al fine di evitare di tornare troppe volte sugli stessi passi. Ci è sembrato per questo
opportuno suddividere il lavoro in 3 fasi:
•
Fase 1: studio e sviluppo del lato client MHP- realizzazione di un prototipo di
applicazione per Tv digitale terrestre;
•
Fase 2: studio e sviluppo del lato server – realizzazione della servlet che funge da
proxy-server (gateway applicativo);
•
Fase 3:
unione fase 1 e fase 2 – realizzazione dell’applicazione definitiva con
perfezionamento e rifinitura grafica;
MHP
CLIENT
Proxy-server
(java servlet)
Gestione
cookie e
sessioni
FAD
Figura 16. Implementazione della soluzione proxy-server
Si è deciso di iniziare lo sviluppo dalla sezione che prevede più vincoli, ossia dalla
realizzazione dell’applicazione client MHP. Il lato server, come già accennato non
comporta particolari vincoli e si suppone di avere a disposizione tutte le librerie ed (almeno
in teoria) della potenza di calcolo di cui si necessita.
Durante la prima fase viene effettuato un recupero veloce dei contenuti per
effettuare subito un test di presentazione lato MHP, dando per scontato la presenza del
proxy-server.
Si è pensato di suddividere questa fase nei seguenti passi:
64
Capitolo 3
•
Le scelte progettuali
Analisi output dell’html delle pagine della FAD : individuazione dei contenuti
da tenere/eliminare sulla base dell’interfaccia scelta;
•
Scrittura manuale files XHTML per il corso di prova “ECDL-2000-La patente
Europea del Computer”;
•
Scelta librerie JAVA per il parsing XHTML lato client;
•
Scrittura codice componente JavaBean per il parsing e la presentazione dei
contenuti;
•
Organizzazioni immagini e files XHTML in web server di test;
•
Test del funzionamento di un modulo del corso : accesso al web server
dall’applicazione MHP;
Ultimata la fase 1 si è passati alla fase 2 :
In questa fase vengono utilizzati i risultati della fase precedente per lo sviluppo del
proxy-server per un interfacciamento completo alla piattaforma FAD.
La fase 2 è stata suddivisa nei seguenti steps:
•
Studio approfondito della logica di funzionamento della FAD (sintassi delle
richieste – gestione dei cookie e delle sessioni);
•
Scelta delle metodologie di estrapolazione dei contenuti;
•
Scelta libreria per il parsing HTML (lato server);
•
Sviluppo
della/e
servlet
necessaria/e
alla
gestione
utente
e
alla
trasformazione HTML Æ XHTML sulla base della logica del client MHP;
•
Unione fase 1 e fase 2 - modifica componente Cardinal (predisposizione del
componente di richieste POST HTTP ) per comunicazione con il proxy-server (Servlet
Java);
•
Rifiniture - ritocco fogli di stile per riuscire a catturare la quantità maggiore di
contenuti;
•
Completamento grafico – abbellimento grafico dell’interfaccia client con lo scopo
di renderla accattivante all’occhio dell’utente;
65
Capitolo 3
Le scelte progettuali
3.2.6 Tecnologie utilizzate
Di seguito vengono schematicamente presentati i vari tool di sviluppo hardware w
software e le tecnologie utilizzate per la realizzazione del servizio:
•
Cardinal Studio Professional 4.0 – un potentissimo authoring tool per lo sviluppo
di applicazioni MHP adatte per essere messe realmente in onda[];
•
Cardinal Studio Component Pack – set di componenti aggiuntivi importati
nell’authoring tool[];
•
Cardinal Playout – software necessario a gestire l’immissione dell’applicazione
nella catena di distribuzione broadcast[];
•
Oracle JDeveloper 10g Versione 10.1.3.0.2 – editor completo codice Java[27];
software utilizzato per la scrittura del codice Java[27]; lato client per lo sviluppo di
componenti (Java Beans) per Cardinal Professional e lato server per lo sviluppo della
servlet (proxy-server)[];
•
Internet Explorer – il browser Web utilizzato in fase di sviluppo del lato server per
testare durante le varie fasi il funzionamento della servlet (proxy-server) con la creazione di
opportuni FORM HTML[];
•
HTTP Analyzer Std Versione 1.6.2.156 – uno sniffer http che ci è servito per
capire la logica delle richieste effettuate browser-FAD e per individuare le informazioni che
in tali richieste venivano scambiate[];
•
Altova XmlSpy Enterprise Editino Version 2005 release 3 – ambiente di editing
di codice per linguaggi di markup o di scripting. Ci è servito per scrivere le pagine di prova
in XHTML e successivamente i fogli di stile, come si vedrà nel capitolo 5 in cui verrà
spiegata dettagliatamente la realizzazione finale dell’applicazione[];
•
Apache Tomcat 5.5.9 – The Apache Jakarta Project – web server per il deploying e
l’housing di scripting Java come la nostra servlet[];
•
MySQL – per la gestione dei databases utilizzati lato server per la gestione della
sessione, della cache e della navigazione[];
•
Questi componenti hardware servono per gestire tutta la catena di simulazione
presente in laboratorio:
•
Server Cardinal Playout Compact;
66
Capitolo 3
Le scelte progettuali
•
Modulatore DVB-T;
•
Up-converter per portare il segnale alla frequenza di utilizzo;
•
Riduttore di potenza del segnale;
•
Set Top Box commerciale[22];
•
Televisore a colori;
L’AMBIENTE DI TESTING PRESENTE IN
LABORATORIO DI TELECOMUNICAZIONI
Cardinal Playout
Compact:
•
Object
Carousel
Generator
•
Generazione
tabelle PS/SI
•
Scheduler
•
Transport
Stream
Multiplexer 90
Mbps
•
Output DVB
ASI-IP
Multicast
Modulatore
DVB-C
Tv Color
Modulatore
DVB-T
Set Top Box
Canale di ritorno
Web Server
Apache
Tomcat
Dial-Up V 90
Ethernet
xDSL
Figura 17. L'ambiente di testing presente in laboratorio di TLC
Il server Cardinal Playout ha come compito quello di riversare l’applicazione e i
contenuti ad essa collegati all’interno del carosello. Il segnale parte dal server Cardinal e
viene indirizzato al modulatore DVB-T e da qui all’ Up-converter che porta il segnale a
frequenza intermedia e da lì, una volta depotenziato, viene convogliato tramite cavo
coassiale nel Set Top Box. Il STB è collegato al televisore a colori tramite presa SCART ed
ad Internet tramite linea telefonica.
67
Capitolo 3
Le scelte progettuali
3.2.7 Cardinal Studio Professional 4.0
Cardinal Studio è un ambiente di authoring tool visuale pensato appositamente per
la realizzazione di applicazioni per la piattaforma DVB-MHP. Grazie all’utilizzo di questo
software è possibile la realizzazione di Xlet senza aver bisogno della conoscenza del
Java[27], linguaggio di programmazione in cui viene di solito scritto il codice di una Xlet.
Si possono sviluppare applicazioni semplici per interfacciarsi a database di prova o
ricevere dati tramite una connessione HTTP. Per creare degli applicativi con delle
funzionalità più complicate è necessario lo sviluppo di componenti aggiuntivi, scritti in
Java[27] da importare all’interno di Cardinal oppure modificare quelli già esistenti
introducendo parti di codice Java[27], ricompilarli e importarli nuovamente. Infatti Cardinal
prevede la possibilità di importare nuovi componenti scritti in Java[27] con la tecnologia
Java Bean: sono un modo di accorpare applicativi Java[27] che li rende indipendenti dal
contesto in cui si trovano rendendoli autonomi e facilmente adattabili. Grande punto di
forza di Cardinal è il fatto di disporre di un emulatore incorporato che permette di simulare
letteralmente la fruizione da parte dell’utente tramite telecomando dell’applicazione creata.
L’applicazione viene creata mettendo logicamente insieme tra di loro componenti
preesistenti e componenti creati. Si creano cioè le dipendenze tra l’uno e l’altro
relazionandoli ad eventi; quest’ultimi rappresentati dalla pressione dei tasti del telecomando,
dal passaggio da un ACT all’altro, dalla visualizzazione di un layer grafico ecc… Al termine
della creazione o, per testarne il funzionamento, ad una certa fase dello sviluppo è possibile
compilare dando origine cosi alla Xlet. L’applicazione così compilata viene fatta girare
all’interno dell’emulatore che è dotato di un telecomando virtuale del tutto simile a quello
dei Set Top Box che si trovano in commercio.
68
Capitolo 3
Le scelte progettuali
Ambiente di sviluppo:potenzialità
Authoring Tool
Emulatore
Componenti “embedded”
Cardinal Studio Professional 4.0
JVM (Java Virtual Machine)
v1.4.05
Componenti
importabili:
Java Beans
Figura 18. Le potenzialità del tool di authoring Cardinal Studio Professional
3.2.8 Le librerie utilizzate lato client
Sparta
Sparta[17] è un pacchetto Java XML di dimensioni inferiori alla media che include
un parser XML, un DOM (Document Object Model), l’interfaccia standard per mezzo
della quale vengono definiti metodi ed attributi che permettono la gestione dei contenuti di
un albero XML in una visione orientata agli oggetti (Object Oriented) e un interprete
XPath[18][21]. Le dimensioni del codice sono piccole, il parser è veloce, la memoria per gli
oggetti è piccola, le API DOM sono semplici e pulite.
Thermopylae è un wrapper per Sparta che permette ad essa di essere usata al posto
di Xerces, uno dei più diffusi parser che fa uso di DOM. Essa presenta un parser W3Cstandard e una interfaccia DOM.
Sparta è stato scritto originariamente nei laboratori della Hewlett-Packard perchè
servisse da supporto ad un progetto per la gestione della distribuzione di applicazioni in
Internet e l’unione di applicazioni locali. Successivamente il codice e la documentazione
sono passati al sito della SourceForge.
69
Capitolo 3
Le scelte progettuali
I punti di forza di questa libreria sono l’utilizzo di un’interfaccia DOM per la
gestione dell’albero XML e del linguaggio XPath[18][21] per l’accesso ai nodi del suddetto
albero[ ].
3.2.8.1 Caratteristiche generali
•
Sparta è dotato di un parser semplice e veloce
•
Il parser non valida gli schemi DTD
•
Il parser non supporta entità esterne
•
Sparta ignora i namespaces. <a:Foo> e <b:Foo> vengono trattati come se “:” fosse
un carattere normale di un tag. Questi saranno considerati tags differenti sebbene parlando
strettamente c’è una possibilità che a: e b: namespace abbiano lo stesso URI.
•
Il DOM è una semplificazione della w3c DOM API. Il DOM utilizza gli stessi nomi
delle classi e dei metodi del w3c DOM dove è possibile, ma risulta essere indipendente da
quest’ultimo ed inoltre non implementa la sua interfaccia. Il DOM di Sparta non usa
interfacce e factorie , invece utilizza poche ma semplici e concrete classi.
Sparta può essere implementata soltanto usando la Java Virtual Machine JDK 1.x
pertanto può girare su dispositivi J2ME. Questo significa per
esempio che essa utilizza le vecchie classi java.util (Vector, Hashtable,
Enumeration) al posto delle nuove (List,Map,Iterator).
Per permettere al codice di Sparta di lavorare con altro codice XML esiste anche
ThermopylaeXml che è un DOM standard intorno a Sparta.
Le espressioni del linguaggio SpartaXpath sono un sottoinsieme della grammatica
completa di XPath[18][21]. Viene fornito il supporto solo alla sintassi abbreviata, che in
pratica è ciò che la maggior parte delle persone usa. L’utilizzo di XPath[18][21] è integrato
nel DOM attraverso i metodi xpathSelect delle classi com.hp.hpl.sparta.Document e
com.hp.hpl.sparta.Element.
Il metodo toString dei nodi di DOM restituisce la concatenazione di tutta la
gerarchia in formato testuale di dei nodi che si trovano al di sotto del nodo dato. Ciò ci
fornisce una funzionalità molto simile ad una che viene data attraverso XSLT. In questo
modo se un documento contiene l’XML del tipo :
70
Capitolo 3
Le scelte progettuali
"<A>1<BB>2<ccc>3</ccc>4<ccc/>5</BB>6<BB>7</BB>8</A>"
allora l’espressione
"doc.xpathSelectElement("/A/BB").toString()"
Restituirà
"2345"[17]
3.2.8.2 XPath
XPath[18] è un linguaggio tramite il quale è possibile generare delle espressioni per
indirizzare parti di un documento XML. È ideato per operare all’interno di altre tecnologie
XML come XSL[21] ed XPointer, ed è caratterizzato dal fatto di avere una sintassi non
XML. In questo modo può essere meglio utilizzato all’interno dell’URI o come valori di
attributi di documenti XML. XPath[18] opera su una rappresentazione logica del
documento XML, che viene modellato con una struttura ad albero ed XPath[18][21]
definisce una sintassi per accedere ai nodi di tale albero. Oltre a questo, XPath[18][21]
mette a disposizione una serie di funzioni per la manipolazione delle stringhe, numeri e
booleani, da utilizzare per operare su valori o sugli attributi dei nodi.
Le espressioni definite da XPath[18][21] per accedere ai nodi dell’albero prendono il
nome di Location Path (percorsi di localizzazione).
La struttura di un location path è la seguente: “axis::node-test[predicate]”.
La componente axis esprime la relazione di parentela tra il nodo cercato ed il nodo
corrente; la componente node-test specifica il tipo o il nome del nodo cercare; mentre
predicate contiene zero o più filtri (espressi tra parentesi quadre) per specificare delle
condizioni più selettive da applicare alla ricerca.
In XPath[18][21] è possibile accedere ai nodi dell’albero utilizzando delle
espressioni abbreviate dei Location Path. Le espressioni abbreviate, come suggerisce il
nome stesso, sono una versione semplificata e compatta dei Location Path[18] ed offrono
un meccanismo più veloce, ma al tempo stesso meno potente per accedere ai nodi
dell’albero. Queste espressioni sono costituite da una lista di nomi di elementi del
documento XML, separati da uno slash(/), e tale lista descrive il percorso per accedere
all’elemento desiderato. È un meccanismo molto simile a quello usato per identificare i file
e le directory nel file-system.
71
Capitolo 3
Le scelte progettuali
3.2.9 Le librerie utilizzate la server
JTidy-r8-SNAPSHOT
Questa libreria è stata utilizzata lato server per permettere la manipolazione della
pagina HTML output della FAD. È la versione Java del più famoso validatore di codice
HTML[19].
MySQL-Connector-Java
Questa libreria è stata utilizzata perché il proxy-server potesse gestire
l’interfacciamento alle tabelle del database MySQL creato per la gestione della sessione
utente[20].
72
Capitolo 4
Sviluppo dell’applicazione client
4
Capitolo 4
Sviluppo dell’applicazione client
4.1 La scelta dei contenuti
Come più volte specificato l’intento è stato quello di riuscire a riproporre contenuti
nati e residenti nel mondo WEB su piattaforma digitale terrestre. È importante sottolineare
che non tutti i tipi di contenuti web sono adattabili ed adatti al contesto televisivo. Per
prima cosa quindi è stato necessario esaminare accuratamente il layout delle pagine del sito
FAD di riferimento per fare una scelta dei contenuti che potessero essere estratti e
riproposti. Come si è già accennato trattando le scelte progettuali, la pagina web del sito in
questione può essere considerata alla stregua di una grossa area all’interno della quale il
contenuto informativo è organizzato sottoforma di testo, immagini e collegamenti
ipertestuali. Tale area è a sua volta suddivisa in altre sottosezioni di dimensione più piccola
contenenti ciascuna una parte dell’informazione veicolata da tutta la pagina (l’area più
grande). Si è deciso di escludere le sottoaree contenenti collegamenti JavaScript per il login,
il logout, gli help in linea, i forum ecc… tutte funzionalità che non possono essere riportate
nell’applicazione MHP ma che saranno implementate attraverso lo sviluppo del lato server
(Java Servlet).
Ci siamo quindi concentrati sulla sottoarea evidenziata in Figura 19:
Area
di Interesse
Figura 19. L'area di interesse
73
Capitolo 4
Sviluppo dell’applicazione client
4.1.1 L’area d’interesse
In quest’area ha luogo la maggior parte della fruizione del servizio: la gestione del
corso e la navigazione tra le varie lezioni. È possibile passare dalla scelta del profilo ai corsi,
alle sezioni, ai moduli, al modulo scelto ed infine alla lezione vera e propria; il tutto grazie
ad un semplice click sui link relativi. Abbiamo analizzato le aree principali di ciascuna
pagina ad ogni livello della navigazione per riuscire ad individuare una possibile omogeneità
di contenuti necessaria a ricavare uno schema XML che fosse il più generale possibile. Tale
indice avrebbe assunto la veste di una specie di protocollo di comunicazione tra le due
piattaforme, la FAD e la Tv digitale terrestre. L’analisi si è concentrata su un numero
cospicuo di pagine al fine di considerare un’ampia casistica di contenuti focalizzando
l’attenzione sulle lezioni, la parte più ricca di contenuti. In base all’analisi fatta ci è sembrato
opportuno suddividere l’area di interesse in tante sottoaree :
•
La prima area è quella del testo che può presentarsi in semplici paragrafi oppure
organizzato in elenchi di tipo puntato. L’area di testo può includere al suo interno
collegamenti ipertestuali, icone e immagini
•
La seconda area è quella delle immagini contestuali all’argomento della lezione –
possono essere presenti oppure no e quando lo sono è possibile anche in numero maggiore
di uno.
•
La terza area è quella dei link cosiddetti di “approfondimento”, che permettono di
accedere a pagine di approfondimento all’argomento trattato nella lezione. Questi tipi di
link possono presentarsi organizzati in elenco semplice o puntato oppure all’interno di
tabelle o dei paragrafi di testo.
•
La quarta area è quella del link che permette di tornare alla pagina precedente. Tale
link non è sempre presente, ma quando c’è è rappresentato da un’icona blu a forma di
triangolo.
•
La quinta area individuata è quella dei link che permettono il passaggio da una
lezione all’altra di uno stesso modulo. La si può suddividere in ulteriori quattro sottoaree:
o
il link che permette di tornare alla prima lezione del modulo corrente;
o
il link che permette di tornare alla lezione precedente a quella che stiamo
trattando;
74
Capitolo 4
Sviluppo dell’applicazione client
o
il link che permette di passare alla lezione immediatamente successiva a
quella che stiamo trattando;
o
•
il link con il quale si può passare alla ultima lezione del modulo corrente.
La sesta area individuata esiste sempre e contiene il titolo della lezione del modulo
che si sta esaminando: pertanto è stata chiamata semplicemente “area titolo”.
4.2 Realizzazione dello scheletro di interfaccia
Lo studio accurato del tipo di contenuti e del layout delle singole pagine ci ha
permesso di compiere il primo passo avanti verso la realizzazione del nostro progetto.
In base soprattutto ai vincoli imposti dallo standard MHP e dai limiti fisici e
tecnologici nell’utilizzo ottimale dello schermo televisivo siamo stati in grado elaborare una
sorta di scheletro/schema di interfaccia. Si è pensato di organizzare l’interfaccia in aree
corrispondenti il più possibile a quelle dell’area di interessa della pagina del sito. In questo
modo all’informazione contenuta nella sottoarea della pagina web corrisponde
un’opportuna interfaccia Tv.
Area Titolo
Immagine contestuale
o generica per
l’argomento trattato
Testo semplice del
contenuto del corso
Elenco scrollabile e
selezionabile di
approfondimenti
Figura 20. Scheletro di interfaccia
75
Capitolo 4
Sviluppo dell’applicazione client
Come si può vedere dalla Figura 20 lo schermo televisivo è stato suddiviso in aree:
•
Area del titolo - dove verrà visualizzato il titolo della lezione;
•
Area dell’immagine – dove verrà visualizzata l’immagine contestuale o generica
all’argomento trattato;
•
Area del testo scrollabile – dove verrà visualizzato il testo del corso eventualmente
scrollabile;
•
Area degli approfondimenti – dove verranno visualizzati e sarà possibile
selezionare gli approfondimenti relativi alla lezione trattata;
•
Area della navigazione – dove verranno visualizzati i tasti relativi alla selezione del
link per passare da una lezione all’altra di uno stesso modulo.
4.3 Scelta del formato di scambio dati
Il fatto di avere a disposizione due piattaforme differenti ha reso necessario definire
un modello di dati esportabile a tutt’e due i lati della comunicazione ed il modo migliore
per farlo è stato utilizzare una sintassi XML.
4.3.1 Formato di scambio dati XML
L’acronimo XML sta per eXtensible Markup Language. Esso permette la creazione
di dialetti di linguaggi che seguono regole precise e rigorose per la struttura, la sintassi e la
semantica, come stabilito dal W3C. È possibile la memorizzazione dei dati in forma di testo
semplice: qualsiasi applicazione (o qualsiasi essere umano) che possa leggere un file di testo
può leggere un file XML. Non è necessario avere il programma di origine per accedere ai
dati. Per questo motivo per modificare un file XML è sufficiente un editor di testo, ma
esistono anche degli editor di testo dedicati con funzionalità aggiuntive. XML è un set di
regole per creare formati di testo facili da generare e facilmente elaborabili da un computer.
I file di testo risultanti sono strutturati, in modo tale da essere :
•
Privi di ambiguità;
•
Estendibili;
•
Indipendenti dalla piattaforma.
76
Capitolo 4
Sviluppo dell’applicazione client
È evidente la somiglianza con HTML (HyperText Markup Language), infatti tutt’e
due sono linguaggi di markup, cioè sfruttano una sintassi che permette la memorizzazione
di elementi (dati) racchiusi all’interno di tag. XML permette la creazione di un insieme di
marcatori autodescrittivi, specifici per la condizione di utilizzo a differenza di HTML che
possiede un insieme di marcatori predefiniti. Per questo leggendo il codice XML è possibile
capire il tipo dati e il modo in cui questi vengano immagazzinati. L’indipendenza dalla
piattaforma rende XML ideale per l’uso sul Web[].
4.3.2 La sintassi scelta
Per prima cosa abbiamo definito la struttura dell’albero logico che rappresenta la
suddivisione dell’area d’interesse in sottosezioni. Si è scelto come elemento radice la stessa
area principale, quella cioè in cui è contenuta tutta l’informazione che ci interessa. Come
nodi dell’albero si sono scelte le singole sottoaree in cui è divisa l’area di interesse. Una
rappresentazione schematica dei contenuti XML è mostrata nella Figura 21:
<?xml version="1.0" encoding="UTF-8"?>
<area_di_interesse>
<area tipo ="titolo"> . . . . . . . </area>
<area tipo ="testo"> . . . . . . . </area>
<area tipo ="immagine"> . . . . </area>
<area tipo ="link precedente"> . . . . . . </area>
<area tipo ="link_indietro_veloce"> . . . . . . </area>
<area tipo ="link_indietro"> . . . . . . . </area>
<area tipo ="link_avanti"> . . . . . . . . </area>
<area tipo ="link_avanti_veloce"> . . . . . . </area>
</area_di_interesse>
Figura 21. Albero logico rappresentante la suddivisione in sottosezioni dell'area d'interesse
77
Capitolo 4
Sviluppo dell’applicazione client
Si tratta di un modello molto semplice. Non ci è sembrato opportuno cominciare
direttamente con uno schema che comprendesse tutta la casistica dei contenuti del sito. Il
nostro proposito iniziale è stato quello di verificare le ipotesi progettuali con un modello
limitato per poi aumentare progressivamente la complessità in linea con gli sviluppi
applicativi.
<?xml version="1.0" encoding="iso-8859-1"?>
<contenuto>
<aree>
<area>
<testo tipo ="titolo"> . . . . . . . . . . </testo>
</area>
<area>
<testo tipo ="libero"> . . . . . . . . . </testo>
</area>
<area>
<immagine nome ="...nome dell'immagine..." didascalia ="...didascalia
immagine..." url="...indirizzo immagine..."/>
</area>
<area>
<testo tipo ="puntato"> . . . . . . . . </testo>
</area>
<area>
<link tipo ="precedente" url="...indirizzo pagina precedente..."/>
</area>
<area>
<link tipo ="indietro_veloce" url="...indirizzo per indietro veloce..."/>
<link tipo ="indietro" url="...indirizzo per link indietro..."/>
<link tipo ="avanti" url="...indirizzo per link avanti..."/>
<link tipo ="avanti_veloce" url="...indirizzo per link avanti veloce..."/>
</area>
</aree>
</contenuto>
Figura 22. Modello di scambio dati definito da noi
78
Capitolo 4
Sviluppo dell’applicazione client
4.4 Sperimentazione con file XML residenti
Seguendo lo schema che abbiamo elaborato siamo passati alla scrittura dei file XML
per costituire un database di prova al quale si sarebbe dovuto attingere quando saremo
andati a fare la prima prova del lato client. Per effettuare un primo test dell’applicazione
client, almeno nella fase iniziale si è scelto di scrivere i file XML corrispondenti alle pagine
appartenenti ad un modulo di un corso e quindi di lavorare su di un numero limitato di
pagine. Così facendo abbiamo ristretto la casistica dei contenuti ma nello stesso tempo
abbiamo considerato a pieno tutti i casi di navigabilità che si possono verificare.
Il passo successivo sarebbe stato quello di ampliare la varietà dei contenuti
considerati in modo tale da coprire completamente la casistica dei contenuti del corso.
Si è scelto il primo modulo della prima sezione del corso “ECDL – 2000- La
patente europea del computer”[] che contiene al suo interno 3 lezioni con o senza
approfondimenti contestuali.
I file corrispondenti ai contenuti delle pagine scelte sono stati quindi organizzati in
cartelle e sotto cartelle e memorizzati su un web server di prova tramite ftp. Spostandoci
quindi allo sviluppo dalla parte client, cioè dell’applicazione MHP, si è reso necessario lo
sviluppo di un componente sviluppato in tecnologia JavaBean da integrare nell’authoring
tool a disposizione, che effettuasse le operazioni di parsing dei file XML appena creati per
estrarre i contenuti e passarli quindi ai componenti grafici di presentazione. In sintesi le
operazioni che doveva fare il nostro componente sono :
•
Stabilire una connessione Http con il Web Server di prova recuperando i file
richiesti identificati da un apposito URL;
•
Leggere il file XML;
•
Estrarre i contenuti dai nodi dell’albero associato ai singoli files XML.
Da questo punto in poi si è trattato di manipolare i contenuti estratti in modo tale
da poterli riproporre secondo lo scheletro base dell’interfaccia Tv ipotizzato.
Sono stati utilizzati Label di testo per il titolo e per le varie forme testuali di
informazione. Il componente Image ci è servito per rendere possibile la visualizzazione
delle immagini ipotizzando di renderle disponibili, almeno per il momento all’interno del
carosello e di non prelevarle dal canale di ritorno.
79
Capitolo 4
Sviluppo dell’applicazione client
URL
T-LEARNING : INTERROGA WEB SERVER
FILE XML
XML
LINK AVANTI
T-LEARNING
COMPONENTE
CARDINAL
PARSER
XML
LINK INDIETRO
FILE DSML APPROFONDIMENTI
TESTO
IMMAGINE
TITOLO
Figura 23. Logica di funzionamento del componente T-Learning nel test di interfacciamento
Per la visualizzazione degli approfondimenti si è fatto uso dei componenti della
famiglia DataSet. Con il loro utilizzo è possibile manipolare file DSML caratterizzati da
una sintassi XML che in pratica è la traduzione in termini XML di una tabella di database.
80
Capitolo 4
Sviluppo dell’applicazione client
Questo tipo di struttura viene utilizzata come descrizione delle informazioni
veicolate e costituisce la fonte dati per il componente DSMLDataSource che effettua il
parsing e costruisce una struttura navigabile dai componenti grafici della stessa famiglia,
controllati dal gestore Dataset.
Il componente sviluppato per estendere le funzionalità dell’authoring tool produce
file DSML sia per gli approfondimenti che per le immagini; pertanto sono stati usati i
componenti della famiglia Dataset per gestire la presentazione dei contenuti.
La Figura 24 di seguito mostra un esempio di file DSML:
Figura 24. Esempio di un generico file nel formato DSML
Come si può vedere dalla Figura 24 il file DSML è organizzato in sezioni:
•
Data: qui è presente un attributo “name” con la funzione di specificare una sorta di
nome della raccolta di informazioni;
•
Header: qui vengono specificate le colonne ed i loro attributi “name” per il nome,
“type” per il tipo di dati, “index” per il numero di indice della relativa colonna;
•
Rows: le righe contengono l’informazione vera e propria che è organizzata sulla
base degli attributi specificati nelle sezione di header.
Il componente che abbiamo sviluppato viene quindi gravato da un altro compito,
cioè generare un file DSML contenente le stringhe che rappresentano gli approfondimenti
e i link delle immagini. Il componente dovrà inoltre poter stabilire una connessione al web
server di testing su protocollo http sfruttando il canale di ritorno che può essere gestito
attraverso il componente predefinito MHP Return Channel
81
Capitolo 4
Sviluppo dell’applicazione client
4.4.1 I componenti DataSet
Questa categoria di componenti è stata sviluppata con lo scopo di poter gestire i
dati informativi come se si trovassero immagazzinati all’interno di un database applicativo,
testo o immagini che siano.
Il framework Dataset è un potente strumento per creare applicazioni e componenti
per la visualizzazione di testo e immagini. Costituisce un tramite tra componenti grafici e
l’informazione vera e propria: è possibile che questo si interponga tra più componenti
grafici e più fonti informative che utilizzano lo stesso formato di dati DSML (è necessario
l’uso di molteplici componenti DSMLDataSource per gestire più file DSML
contemporaneamente).
Generico
DataAwareList
Generico
component
e Cardinal
Generico
DataLabel
Dataset
Fonte di file formato
DSML
Figura 25. Il framework DataSet
Come si può vedere dalla Figura 25 qui riportata, il componente DataSet ha la
funzione di colui che smista i contenuti prelevati dal componente DSMLDataSource ai
componenti DataAwareList o DataLabel deputati alla rappresentazione dell’informazione
(testo o immagini). Ciascun DataSet può essere associato a più componenti Data-Aware
Display mentre un DataSet può avere associato un solo dsmlDataSource[].
82
Capitolo 4
Sviluppo dell’applicazione client
4.5 Il componente T-Learning
Passiamo ad analizzare adesso il componente T-Learning, il fulcro della nostra
applicazione. Si tratta di un componente sviluppato in tecnologia JavaBean, la cui versatilità
di utilizzo intrinseca ne permette l’utilizzo anche con altre applicazioni.
Nel corso dell’evoluzione del progetto il componente ha subito varie modifiche in
vista dell’interfacciamento completo alla FAD: si è passati dalle funzionalità di connessione
ad un Web Server di prova a quelle di connessione ad un Web Server di Housing
applicativo (Apache Tomcat) con passaggio di parametri via Http Post e nell’header della
richiesta.
4.5.1 Proprietà e funzionamento
Il componente in fase di runtime prende in ingresso parametri passati
dall’applicativo. Tali valori possono corrispondere a precise azioni dell’utente o a dati
passati in input dall’utente ad esempio riempiendo form testuali. I parametri sono impostati
nel codice Java come variabili private ed appaiono all’utilizzatore dell’authoring tool come
proprietà del componente settabili dall’esterno.
Nella prima fase di sviluppo del componente sono state dunque considerate le
proprietà:
•
urlBase;
•
indirizzoFile.
La prima permette di impostare dall’esterno l’indirizzo di un Web Server di prova
mentre la seconda l’indirizzo del file relativo alla cartella in cui si trova. In questo modo si è
reso il componente ancora più versatile: lo si può utilizzare con Web Server diversi e diversi
database fittizi di prova senza mettere mano al codice Java[27].
Successivamente, per implementare l’interfacciamento completo alla piattaforma di
formazione a distanza attraverso la servlet Java, sono state considerate i seguenti parametri
esterni:
•
URL_servlet : indirizzo al quale il componente si connette via Http, rappresenta
l’indirizzo del contenitore della Servlet;
•
Username : nome utente che permette l’accesso al proprio profilo o profili della
FAD;
83
Capitolo 4
•
Sviluppo dell’applicazione client
Password : password da inserire insieme al nome utente per rendere effettivo
l’accesso alla FAD.
Il componente entra in gioco ogni volta che l’applicazione MHP fruisce del canale
di ritorno per prelevare i contenuti richiesti dall’utente, quindi alla pressione di ogni tasto
del telecomando scelto per l’inoltro di una richiesta.
La classe è organizzata in più metodi di cui il principale è il metodo parser che, come
dice il nome stesso è quello che, dopo essersi connesso al server con il relativo passaggio di
parametri recupera la stringa XHTML e ne effettua l’operazione vera e propria di parsing.
Mediante opportuni metodi di set presenti nella classe, possono essere settati dall’esterno
due parametri di tipo stringa:
•
Link Æ la stringa che rappresenta il link della pagina richiesta che sarà sfruttato dal
lato server;
•
TASK Æ stringa relativa alla parte della logica server che deve essere eseguita in
relazione alla richiesta effettuata.
I contenuti vengono estratti e memorizzati in rispettive variabili stringa e dove
richiesto vengono strutturati e memorizzati i file DSML dei link degli approfondimenti e
dei link delle immagini.
Al verificarsi dell’evento corrispondente alla pressione di un tasto il componente
stabilisce una connessione Http alla servlet passando nell’header della richiesta, ove
necessario un collegamento ipertestuale che sarà sfruttato poi lato server, e tramite POST le
tre stringhe corrispondenti a:
•
Username;
•
Password;
•
Cookie.
Ricevuta la stringa XHTML, questa viene letta e man mano immagazzinata in una variabile
stringa appositamente inizializzata che successivamente viene sottoposta all’operazione di
parsing con relativa estrazione dei contenuti richiesti. Per fare questo vengono sfruttate le
potenzialità della libreria Sparta. La stringa contente la pagina XHTML viene associata
all’interfaccia standard DOM creando un albero i cui nodi sono gli elementi con i relativi
tag di chiusura. La selezione dei nodi dell’albero viene effettuata sfruttando istruzioni
XPath[18][21]:
84
Capitolo 4
Sviluppo dell’applicazione client
•
//p[@class="titolo"] Æ per la selezione nodo contenente la stringa del titolo;
•
//img Æ per la selezione degli elementi contenenti le stringhe dei link relativi alle
immagini;
•
//a[@class="approfondimento"] Æ per la selezione dei nodi contenenti le stringhe
dei link relativi agli approfondimenti;
Per la selezione dei nodi contenenti le stringhe dei relativi link e della loro
descrizione:
•
//a[@class="indietro_veloce"];
•
//a[@class="indietro"];
•
//a[@class="avanti"];
•
//a[@class="avanti_veloce"];
•
//a[@class="precedente"] Æ per la selezione del nodo contenente la stringa del
link della pagina precedente;
•
//p[@class="testo”] Æ per la selezione dei nodi contenenti stringhe del testo delle
pagine;
•
//a[@class="immagine_precedente"] Æ per la selezione del nodo contenente la
stringa del link relativo all’icona collegata al link della pagina precedente.
La classe permette la restituzione dei contenuti all’esterno del componente
attraverso opportuni metodi di get. Quindi è possibile recuperare:
•
Titolo,
•
Testo,
•
File DSML degli approfondimenti,
•
File DSML delle immagini;
•
I link Indietro_veloce, Indietro, Avanti e Avanti_veloce e le rispettive descrizioni.
I contenuti così residenti in memoria possono essere passati a seconda delle
richieste effettuate ai componenti dell’interfaccia grafica che si occupa della loro
rappresentazione.
Affinché i parametri, i metodi e le proprietà di cui dispone il componente creato
siano visibili dall’esterno del package, è stato stilato un apposito file beanInfo[25]. Il file TLearningBeanInfo è organizzato in metodi con ciascuno il proprio compito:uno per le
85
Capitolo 4
Sviluppo dell’applicazione client
proprietà ed uno per i metodi che devono essere resi visibili all’esterno. È possibile
impostare il nome del componente, dei brevi commenti, la presenza o l’assenza di
un’immagine con la funzione di icona del componente.
Il codice Java[27] del componente e il file beanInfo[25] compilati, ossia i file con
estensione .class insieme all’immagine associata vengono impacchettati per formare un file
Jar[26] secondo le specifiche JavaBean. All’interno del file compresso è presente anche un
file di testo molto importante chiamato file manifest mediante il quale Cardinal è informato
sulle classi che vengono utilizzate dal componente T-Learning.
Il componente T-Learning :
Stringa XHTML
Link
Indietro_veloce
Indietro
Avanti
Avanti_veloce
Metodo Parser()
Metodi di get()
Titolo
Testo
Etichetta
Indietro_veloce
Indietro
Avanti
Avanti_veloce
File DSML per gli
File DSML per i link delle
Figura 26. Logica di funzionamento del componente T-Learning
86
Capitolo 4
Sviluppo dell’applicazione client
4.6 Organizzazione dell’applicazione Client
Nello sviluppare l’applicazione si è cercato in tutto e per tutto di riproporre
fedelmente all’interno dell’interfaccia televisiva i contenuti principali del corso WEB.
Pertanto si è pensato di organizzare l’applicazione seguendo l’architettura
strutturata ad albero di cui si è parlato nel capitolo precedente e mostrata in Figura 12.
In una prima fase di progettazione e test in locale del servizio e dei suoi contenuti,
la logica dell’applicazione è stata divisa in due act, marcando la distinzione tra
l’instradamento dell’utente nella scelta della lezione da fruire, che ha atto nel primo act, e la
fruizione della lezione vera e propria, che è possibile nel secondo act.
Successivamente, invece, l’applicazione client è stata adeguata all’interfacciamento
completo con il lato server sfruttando i risultati ottenuti nella fase precedente di testing con
Web Server. La logica dell’applicazione è stata suddivisa in un numero di act pari ai nodi
dell’albero rappresentante l’architettura del sito del corso (vedi Figura 12 Capitolo 3 - Le
scelte progettuali).
4.6.1 Suddivisione in stati logici
Il funzionamento dell’applicazione è molto semplice, tanto da non risultare
strettamente necessaria la presenza di una sorta di guida in linea per compiere le varie
operazioni. Quello che si trova a dover fare l’utente sono poche operazioni di selezione
degli approfondimenti e di gestione di contenuti tramite visualizzazione di testo ed
immagini che possono essere al più scrollati.
L’applicazione è suddivisa in un numero di act pari al numero di fasi in cui è
suddivisa la logica dell’applicativo server:
•
Login;
•
Profili;
•
Corsi Attivi;
•
Sezioni;
•
Moduli;
•
Modulo;
•
Corso.
87
Capitolo 4
Sviluppo dell’applicazione client
L’utente effettuata l’autenticazione, sceglie uno dei corsi che sono stati attivati
dall’amministratore nel profilo selezionato per poi selezionarne una delle sezioni. Scelto di
seguito un modulo, accede alla lezione desiderata. Viene data la possibilità di terminare la
sessione in ogni stato dell’applicazione richiamando la funzionalità di LOGOUT che riporta
l’applicazione allo stato di LOGIN.
Login
Profili
Logout
Corsi_Attivi
Sezioni
Moduli
Modulo
Corso
Figura 27. Architettura del servizio
4.7 Realizzazione dell’interfaccia grafica
La maggior parte dell’aspetto grafico dell’applicazione MHP è stato curato
sfruttando i vari componenti grafici messi a disposizione dall’ambiente di authoring tool:
Label, DataAwareList, DataLabel, Panel, Button ecc… Per lo sfondo si è prima creata
88
Capitolo 4
Sviluppo dell’applicazione client
un’immagine in formato JPEG e poi convertita in I-Frame adattandola a Cardinal secondo
le opportune specifiche.
Per la conversione JPEG Æ I-Frame stato usato un efficace programma di MPEG
Encoding TMPGENC con opportune impostazioni di codifica[].
Figura 28. Specifiche per la trasformazione JPEG -> I-Frame
4.8 Sistemazione dei contenuti nell’interfaccia
Di seguito vengono riportati degli screenshot di esempi di interfaccia in ogni stato
dell’applicazione. Dal confronto con le aree corrispondenti delle pagine del sito del corso è
possibile notare come si sia riusciti a riproporre, in maniera opportunamente adattata allo
schermo televisivo, tutti i contenuti informativi del corso.
89
Capitolo 4
Sviluppo dell’applicazione client
Lista scrollabile dei
profili selezionabili.
Figura 29. Screenshot dell'interfaccia dei profili attivati con confronto pagina del sito del corso.
Lista scrollabile dei corsi
attivati selezionabili
relativamente al profilo
scelto.
Figura 30. Screenshot dei corsi attivati relativamente al profilo selezionato con confronto pagina del
sito del corso.
90
Capitolo 4
Sviluppo dell’applicazione client
Lista scrollabile delle
sezioni selezionabili
relativamente al
corso scelto.
Descrizione del contenuto
delle singole sezioni
sottoforma di testo
scrollabile con i tasti 2 e 8.
Figura 31. Screenshot delle sezioni del corso scelto con confronto pagina del sito del corso
Lista scrollabile dei
moduli selezionabili
relativamente alla
sezione scelta
Descrizione del contenuto dei
singoli moduli sottoforma di
testo scrollabile con i tasti 2 e
8.
Figura 32. Screenshot dell'interfaccia dei moduli relativi alla sezione del corso scelta con confronto
con la pagina del sito del corso.
91
Capitolo 4
Sviluppo dell’applicazione client
Lista scrollabile delle
lezioni a disposizione
relativamente al
modulo selezionato.
Figura 33. Screenshot delle lezioni disponibili relativamente al modulo scelto con confronto con la
pagina del sito del corso.
Titolo della lezione
Area per la
visualizzazione del
contenuto della lezione in
forma testo scrollabile
Area per la
visualizzazione della o
delle immagini
contestuali
Etichetta visibile solo se
è possibile la
visualizzazione di più
immagini contestuali
Lista scrollabile di
eventuali
approfondimenti
selezionabili
Etichetta visibile solo se è
possibile tornare alla pagina
precedente
Area che permette all’utente di
navigare all’interno tra le varie lezioni
all’interno dello stesso modulo
Figura 34. Screenshot dell'interfaccia della lezione appartenente al modulo scelto con confronto con
la pagina del sito del corso
92
Capitolo 4
Sviluppo dell’applicazione client
4.9 Il funzionamento in generale dell’applicazione
Senza dubbio il modo migliore per capire a fondo il funzionamento
dell’applicazione MHP è quello di metterci nei panni dell’utente che fruisce del servizio.
Supponiamo di trovarci nel momento in cui l’applicazione client inizia ad essere eseguita
dal Set Top Box e sullo schermo televisivo appare la prima schermata (corrispondente al
primo act), che permette l’autenticazione dell’utente per mezzo di username e password ed
in cui è evidenziata la necessità della pressione del tasto 5 del telecomando per iniziare ad
usufruire del servizio. Per praticità e siccome per il momento disponevamo di un solo
account, si è deciso di immagazzinare questi dati in formato stringa direttamente su due
Label.
Alla pressione del tasto 5 del telecomando l’applicazione, attraverso il canale di
ritorno, si connette ad internet sfruttando le impostazioni predefinite dell’Internet Service
Provider quindi inoltra le opportune richieste al server remoto. Nel tempo necessario alla
connessione telefonica viene visualizzata un’apposita etichetta di testo che invita l’utente a
rimanere in attesa. A connessione avvenuta l’applicazione cambia act passando alla
visualizzazione del layer grafico dei profili attivi. A questo punto è possibile, attraverso le
frecce direzionali scorrere i profili e con la pressione del tasto OK del telecomando,
confermare il profilo desiderato. Effettuata la scelta, l’applicazione cambia di nuovo act
mostrando il layer grafico corrispondente ai corsi attivi per il profilo selezionato. Anche in
questo caso è possibile scorrere i nomi dei corsi con le frecce direzionali e selezionare
quello desiderato per mezzo della pressione del tasto OK. L’unico corso per ora attivo è
quello “ECDL – 2000 – La patente europea del computer”. La selezione del corso
induce un altro cambio di act con la visualizzazione del layer grafico delle sezioni in cui è
suddiviso il corso con all’interno un elenco selezionabile delle singole sezioni del corso. È
inoltre presente un’area di testo più piccola nella quale viene riportata la descrizione della
sezione evidenziata in quel momento dal cursore. Il testo di questa descrizione può essere
scrollato mediante la pressione dei tasti 2 ed 8. Si procede così fino alla scelta del modulo
del corso scelto. Qui, cambiando act, si entra nel layer grafico in cui vengono mostrati i
contenuti della lezione vera e propria. Come è possibile vedere dalla Figura 34, è presente
una zona riservata alla visualizzazione del testo, una per l’immagine, una dove è possibile
selezionare l’approfondimento desiderato ove presente. La parte inferiore del layer grafico è
93
Capitolo 4
Sviluppo dell’applicazione client
riservata ad indicare all’utente a quali altre lezioni del modulo implementato si può accedere
premendo uno dei quattro tasti colorati di navigazione veloce.
Per permettere di tornare indietro alla lezione corrispondente all’approfondimento
che si sta leggendo è possibile premere il tasto 1.
Invece, se sono presenti più immagini visualizzabili appare un’apposita etichetta che
informa l’utente che se vuole scorrere le immagini può farlo tramite la pressione delle
frecce destra e sinistra.
La pressione del tasto 6 del telecomando consente di terminare la sessione corrente
ritornando all’act di partenza.
4.10 Dettagli di funzionamento
Passiamo ad analizzare a fondo il funzionamento dell’applicazione, discutendo
approfonditamente l’interazione tra i componenti integrati in Cardinal e quelli sviluppati
“AD HOC”.
Esaminiamo ancora una volta l’evoluzione logica dell’applicazione ripercorrendo i
nodi dell’albero di cui si è trattato nel capitolo inerente alle scelte progettuali.
Partiamo dal momento in cui ci si trova davanti il layer grafico del primo act, quello
di login in cui, come è stato già detto nel paragrafo precedente, l’utente viene invitato
all’autenticazione mediante la pressione del tasto 5 del telecomando. La Username e la
Password sono memorizzate, sottoforma di stringhe, all’interno di due Label (Figura 35).
94
Capitolo 4
Sviluppo dell’applicazione client
Figura 35. Screenshot del TASK = LOGIN
Alla pressione del tasto 5 l’applicazione genera un evento che richiama il
componente IFLogic. A questo viene applicato il metodo Evaluate Boolean cui viene passato il
parametro ChannelConnected del componente MHPReturnChannel. In questo modo
l’applicazione valuta la presenza di una connessione ad internet già attiva e, in caso
affermativi, darà luogo alle azioni successive che competono all’autenticazione dell’utente.
In caso negativo invece:
•
Invocherà il metodo mHPReturn Channel.connect() per effettuare la connessione al
server remoto tramite canale di ritorno;
•
E cambierà la proprietà del componente Etichetta_di_partenza per renderla visibile
con la dicitura : ”Connessione in corso…”.
Al verificarsi dell’evento corrispondente alla connessione avvenuta (attraverso il
componente mHPReturn Channel) vengono cambiate le seguenti proprietà:
95
Capitolo 4
•
Sviluppo dell’applicazione client
Il testo della label che visualizza lo stato della connessione assume la dicitura
“Recupero dati…”
•
Il layer grafico condiviso diventa invisibile;
•
Viene dato il via alla fase di autenticazione.
Viene invocato il metodo Perform action() applicato al componente Action in cui
sono raggruppate tutte le azioni che si devono verificare per dare il via alla procedura di
autenticazione.
4.10.1 La procedura di autenticazione
All’evento actionPerformed per prima cosa vengono cambiate le proprietà del
componente T-Learning <nome utente per l’accesso alla FAD> e <password per l’accesso
alla FAD> passandogli i valori stringa rispettivamente delle etichette grafiche che
contengono memorizzate username e password. In un contesto di uso multiutente
l’applicazione sarà dotata di etichette e componenti che permettono l’inserimento di dati
per mezzo dei tasti del telecomando utilizzato a mò di tastiera di un cellulare sfruttando lo
stesso principio che permette la scrittura di un sms.
Viene quindi invocato il metodo Parser del componente T-Learning al quale viene
settato il solo parametro TASK = login mentre l’altro parametro link rimane vuoto visto che
il TASK login della logica lato server contiene in se stesso gli URL da utilizzare. Viene
modificata la proprietà <visible> del layer grafico login e posta a “false”. Infine, dopo che
tutte le altre azioni sono state effettuate viene imposto il cambio di act passando all’act
chiamato “Profili”. Quando viene invocato il metodo Parser il componente JavaBean,
sviluppato ed integrato in Cardinal, si connette via Http all’indirizzo del contenitore
Tomcat dove risiede la servlet :
http://localhost:8080/noproxydeploy/ciao
Alla servlet vengono passati attraverso il POST Http i parametri che definiscono il
tipo di TASK che in questo caso è login, la stringa dell’username e la stringa della
password. La servlet, prelevati parametri contenuti nella richiesta, esegue il TASK portando
a termine le opportune operazioni e restituisce la stringa XHTML che contiene la pagina
dei profili. Questa viene ricevuta e letta riga per riga dal componente T-Learning che ne
96
Capitolo 4
Sviluppo dell’applicazione client
effettua il parsing immagazzinando i valori degli elementi di interesse nelle variabili di tipo
stringa appositamente inizializzate.
4.10.2 I profili
Quando la procedura di autenticazione è terminata si cambia act passando dal login
all’act dei Profili. Alla visualizzazione di quest’ultimo, che rappresenta un evento, viene
invocato il metodo Request focus() applicato al componente Data Aware List chiamato
“Lista_profili” vincolando il focus all’area dello schermo in cui vengono visualizzati i profili
attivati all’utente autenticato in quel momento. Viene cambiata la proprietà <Data String>
del componente dsmlDataSource al quale viene passato come sorgente il file DSML che ci
fornisce il componente T-Learning per mezzo del metodo getDSML una volta che questo
ha effettuato il parsing. Viene cambiata la proprietà <Text> del Label chiamato
“Titolo_profili” passandogli il valore stringa ottenuto per mezzo del metodo getTitolo del
componente T-Learning. In questo modo viene visualizzato il titolo e, almeno nel nostro
caso, l’unico profilo attivo:
97
Capitolo 4
Sviluppo dell’applicazione client
Figura 36. Screenshot del TASK Profili
A questo punto, come si può vedere dalla Figura 36 è possibile selezionare l’unico
profilo attivo:“Studente”. Per fare questo è sufficiente la pressione del tasto OK del
telecomando, alla cui pressione corrisponde un altro evento.
4.10.3 La selezione di un profilo
Alla pressione del tasto OK del telecomando viene invocato il metodo Parser del
componente T-Learning passandogli come parametri il tipo di TASK = profilicorsiattivi ed
il link al quale la servlet si deve connettere. Questo gli viene passato prelevando la stringa
relativa dal componente Data Aware List chiamato link_profilo, reso invisibile per i nostri
scopi, per mezzo del metodo getString. A questo punto viene cambiato act passando all’act
chiamato Corsi_Attivi. Ancora una volta il componente T-Learning si connette a Tomcat
dove risiede la servlet passandogli via Http POST il tipo di TASK, la coppia username e
98
Capitolo 4
Sviluppo dell’applicazione client
password ed in un campo appositamente definito dell’header della richiesta il link della
pagina che dovrà prelevare dalla FAD. A questo punto la servlet esegue il TASK
specificato e restituisce la stringa XHTML contenente la pagina richiesta opportunamente
adattata. La stringa viene ricevuta dal componente che la legge e ne effettua il parsing
memorizzando gli elementi nelle variabili dedicate.
4.10.4 Corsi attivi
Come nel TASK precedente, la visualizzazione del layer grafico deputato a
contenete i corsi attivi costituisce un evento cui corrispondono delle azioni.
Viene cambiata la proprietà <text> del Label chiamato titolo_corsi_attivi
passandogli il valore stringa estratto per mezzo del metodo getTitolo del componente TLearning ed allo stesso tempo viene modificata la proprietà <Data String> del componente
dsmlDataSource passandogli come sorgente il file DSML restituito come risultato dal
metodo getDSML del componente T-Learning.
In questo modo vengono visualizzati il Titolo ed i Corsi attivi per il profilo
selezionato dall’utente.
99
Capitolo 4
Sviluppo dell’applicazione client
Figura 37. Screenshot TASK Corsi Attivi
A questo punto l’utente, come si vede dalla figura, per procedere con la navigazione
non deve far altro che scorrere la lista per mezzo dei tasti su e giù del telecomando e
selezionare il corso di cui vuole fruire per mezzo di una nuova pressione del tasto OK.
Come nei casi precedenti, ciò rappresenta un evento cui viene associato l’invocazione del
metodo Perform action() applicato al componente Action che raggruppa tutte le azioni che
devono essere effettuate in concomitanza della selezione di un corso.
4.10.5 La selezione di un corso
All’evento actionPerformed viene associata l’invocazione del metodo Parser del
componente T-Learning cui vengono passati come parametri il link del corso attivo
selezionato ed il TASK da eseguire lato server. Il primo prelevando la stringa con
l’indirizzo attraverso il metodo getString dal dataLabel deputato a contenere, ogni volta che
100
Capitolo 4
Sviluppo dell’applicazione client
si scorre la lista dei corsi, il collegamento ipertestuale corrispondente ed il secondo settato
direttamente per mezzo dell’interfaccia grafica. Di seguito viene invocato il metodo First()
del dataSet in maniera tale che il cursore del componente Data Aware List dell’act
successivo per la visualizzazione delle sezioni del corso occupa la prima posizione. Ed
infine viene fissato il cambio dell’act verso l’act chiamato Sezioni. Ancora una volta il
componente T-Learning si connette via Http alla servlet passandogli via POST TASK =
sezioni, username e password e nell’header della richiesta il link cui questa dovrà
connettersi. A questo punto la servlet esegue il TASK sezioni portando a termine le
operazioni in esso specificate e restituisce la stringa XHTML che contiene la pagina
richiesta opportunamente manipolata. Il componente T-Learning la legge riga per riga, ne
effettua il parsing e memorizza gli elementi estratti nelle variabili stringa deputate.
4.10.6 Sezioni, moduli e modulo
Al cambiamento di act viene visualizzato il layer grafico relativo alle sezioni. A
quest’evento viene invocato il metodo Request focus() applicato al componente Data
Aware List deputato alla visualizzazione delle sezioni vincolando la navigabilità alla sola
lista in questione. Viene cambiata la proprietà <Data string> del componente
dsmlDataSource passandogli come sorgente il file DSML risultato del metodo getDSML
del componente T-Learning ed in contemporanea viene cambiata la proprietà <text> del
Label chiamato Titolo_sezioni passandogli il valore restituito dal metodo getTitolo del
componente T-Learning.
In questo modo viene visualizzato il titolo, l’elenco delle sezioni del corso e questa
volta anche la descrizione del contenuto delle singole sezioni grazie all’utilizzo di un
componente dataLabel che fruisce dello stesso file DSML.
101
Capitolo 4
Sviluppo dell’applicazione client
Figura 38. Screenshot TASK Sezioni
A questo punto l’utente si trova di fronte alla schermata delle sezioni del corso.
Come si può vedere dalla Figura 38, l’utente può prendere visione del titolo della singola
sezione semplicemente muovendo il cursore che evidenzia le singole sezioni per mezzo
delle frecce su e giù. Ogni volta che il cursore si trova su di una sezione, nel campo
dedicato alla sua descrizione, viene visualizzato il testo che ne reca le caratteristiche. Questo
testo può essere scrollato mediante la pressione dei tasti 2 ed 8 del telecomando. Quando
l’utente ha deciso, può effettuare la selezione della sezione premendo ancora una volta il
tasto OK del telecomando così da accedere alla sezione desiderata.
4.10.7 La selezione di una sezione, di un modulo e di una lezione
La pressione del tasto OK, come si è più volte detto, rappresenta un evento che
determina l’esecuzione, per mezzo dell’invocazione del metodo Perform Action(), di tutte
102
Capitolo 4
Sviluppo dell’applicazione client
le azioni inglobate nel componente Action chiamato Azioni_sezioni. Viene invocato il
metodo Parser cui vengono passati come parametri il link prelevato dal dataLabel apposito
per mezzo del metodo getString ed il tipo di TASK settato direttamente attraverso
l’interfaccia grafica di Cardinal. Attraverso l’invocazione del metodo First() del dataSet il
cursore del componente Data Aware List sale nella prima posizione. Infine viene imposto il
cambio di act per passare a quello chiamato Moduli.
Ancora una volta il componente T-Learning si connette Http alla servlet passando
TASK, username e password via POST e il link della pagina voluta nell’header della
richiesta. La servlet esegue il TASK specificato restituendo al componente T-Learning la
stringa XHTML contente la pagina voluta. Questi la legge riga per riga e ne effettua il
parsing memorizzando i valori degli elementi estratti in variabili stringa apposite. Di seguito
l’utente attraversa altri due act: quello dei moduli che permette la scelta del modulo e quello
del modulo che permette la scelta della lezione. L’applicazione durante questi due passaggi
si comporta allo stesso modo del TASK delle sezioni con l’unica differenza riscontrabile
nell’act modulo in cui non è presente il componente con il testo della descrizione, come del
resto non è presente descrizione della lezione nella pagina relativa del sito Web del corso.
4.10.8 Il corso
Siamo arrivati alla parte più importante del servizio, qui si svolge l’attività più
intensa di comunicazione tra client e server recuperando da remoto, per mezzo del canale
di ritorno, la più ampia casistica di contenuti Web. In un certo senso è relativamente a
questo act che si verifica l’interfacciamento vero e proprio.
1
3
2
3
4
5
3
3
6
6
Figura 39. Screenshot del template in cui vengono incastonati i contenuti della lezione
103
Capitolo 4
Sviluppo dell’applicazione client
Come si può vedere dalla Figura 39 sono presenti:
•
Area del Titolo;
•
1
Area dell’immagine o immagini contestuali;
•
Area del testo (puntato e libero);
•
Area degli approfondimenti; 4
•
Area dei link per passare da una lezione all’altra di uno stesso modulo
•
Etichette di testo, una sorta di piccola guida on-line.
2
5
6
3
Con la selezione della lezione di cui si vuole fruire viene invocato il metodo Parser
del componente T-Learning passandogli il link e il TASK e si impone il passaggio dall’act
Modulo all’act Corso. La visualizzazione del relativo layer grafico (Figura 39), rappresenta
l’evento relativamente al quale viene invocato il metodo request Focus() applicato al
componente Data Aware List deputato alla visualizzazione della lista degli approfondimenti
selezionabili in modo da vincolarvi la navigazione. Di seguito viene dato il via ad una serie
di azioni raggruppate per comodità in un unico componente action chiamato
“azioni_lezione”.
Queste verranno richiamate ogni volta che in questo act l’utente interagirà con
l’applicazione per esaminare un approfondimento o per passare ad una lezione compresa
nello stesso modulo di quella corrente, ossia ogni volta che l’applicazione avrà bisogno di
recuperare contenuti utilizzato il canale di ritorno.
4.10.8.1 Il componente imageDisplay
Questo componente permette di caricare e di seguito mostrare le immagini dal
canale di ritorno. Si connette via http al server, riceve l’immagine e la visualizza adattandola
alle dimensioni che vengono date alla finestra di visualizzazione nell’applicazione, il canvas.
Ha integrate in sé due proprietà:
•
URL Immagine : che viene modificata ogni volta riempiendola con l’indirizzo
dell’immagine che deve essere caricata e visualizzata (immagine di default o immagine
contestuale che sia);
•
URL Immagine Default : che viene modificata solo con l’indirizzo dell’immagine di
default (quella che deve essere mostrata quando non è presente immagine contestuale);
104
Capitolo 4
Sviluppo dell’applicazione client
Da qui si capisce chiaramente che la prima delle due proprietà ha bisogno sempre di
un indirizzo valido al proprio interno per garantire il funzionamento corretto del
componente. Infine questo è dotato di un unico metodo chiamato Carica Immagine() che
permette appunto di eseguire le operazioni per il quale è stato realizzato.
Immagine prelevata
dal canale di ritorno
Richiesta
L’immagine
viene elaborata
ed
opportunamente
adattata.
Componente
imageDispla
L’immagine viene
visualizzata nell’apposito
Figura 40. Il funzionamento del componente imageDisplay
105
Capitolo 4
Sviluppo dell’applicazione client
4.10.8.2 La visualizzazione di una lezione
Per sistemare i contenuti all’interno dell’interfaccia televisiva, l’applicazione preleva
i valori stringa che il componente T-Learning ha memorizzato nelle apposite variabili
stringa. Con l’ausilio dei relativi metodi di get vengono modificate le proprietà testuali delle
etichette grafiche (Label) relative a:
•
Titolo della lezione;
•
I link: indietro_veloce, indietro, avanti e avanti_veloce (nel caso specifico con
etichette rese invisibili);
•
Le descrizioni delle funzioni associate ai 4 tasti colorati: rosso, verde, giallo e blu;
•
Il testo inerente alla lezione;
•
Il numero delle righe del file DSML che trasporta i link delle immagini.
Di seguito, ove presenti, viene riempita la lista selezionabile degli approfondimenti
attraverso il passaggio del relativo file DSML al componente dsmlDatasource1. Lo stesso
dicasi per la memorizzazione dei link delle immagini, che avviene grazie al passaggio del
relativo file DSML al componente dsmlDataSourceImmagini. Invocando il metodo First()
del componente dataSet1 si riposiziona il cursore della lista degli approfondimenti nella
prima posizione. L’applicazione inoltre effettua dei test che le servono per capire se è
presente il link della pagina precedente oppure se sono presenti nessuna,una o più
immagini. I primi due test sono effettuati sfruttando due componenti IFLogic distinti che
usano come parametro booleano di confronto i relativi valori forniti dal componente TLearning. Per quanto riguarda il terzo test, fa uso del componente Evaluator che usa come
parametro di confronto rispetto ad 1 il numero delle righe del file DSML contenente i link
delle immagini.
4.10.8.3 La prima lezione
Come risultato delle azioni descritte nei paragrafi precedenti si ottiene la
visualizzazione della lezione:
106
Capitolo 4
Sviluppo dell’applicazione client
Figura 41. Screenshot di una lezione del corso
Come è possibile vedere dalla Figura 41, tutti i campi elencati in precedenza
vengono riempiti con i contenuti estratti dalla pagina Web del sito della FAD. Viene
riportato il titolo della lezione, l’immagine contestuale, gli approfondimenti, il testo e le
indicazioni per la navigazione. Nello screenshot di Figura 41 è stata riportata una lezione in
cui non è presente nessuna immagine contestuale, ma come di può vedere è presente lo
stesso un’immagine. Infatti quando all’interno della pagina richiesta non è presente nessuna
immagine viene caricata da remoto un’immagine di default residente su un Web server. Ciò
è possibile effettuando un test sulla presenza di un’immagine o di immagini contestuali.
Questo è possibile, come si è accennato nel paragrafo precedente, grazie ad un componente
IFLogic che verifica la presenza di un’immagine. Ogni volta che quest’ultimo viene messo
in esecuzione viene effettuato un test sul valore booleano estratto dal metodo
getPresenza_immagine del componente T-Learning:
Se true Æ viene invocato il metodo Evaluate string applicato al componente IFlink.
Questo ha il compito di effettuare, utilizzando la stringa “nessuna immagine” per il
107
Capitolo 4
Sviluppo dell’applicazione client
confronto, il test sul link da passare al componente che carica e visualizza l’immagine da
remoto:
Se true Æ viene modificata la proprietà <URL Immagine> del componente
chiamato imageDisplay passandogli il valore stringa immagazzinato nel campo <URL
Immagine Default> dello stesso componente
Se false Æ viene modificata la proprietà <URL Immagine> del componente
imageDisplay passandogli il link ottenuto come risultato del metodo getCurrentString del
componente Data Aware List chiamato lista_link_immagini
Di seguito viene invocato il metodo Carica Immagine() del componente
imageDisplay.
Gli approfondimenti ed il testo possono essere scrollati utilizzando rispettivamente
le frecce su e giù ed i tasti 2 e 8 del telecomando, le cui azioni sono state raggruppate in
componenti action relativi per motivi di un’organizzazione più ordinata dell’applicazione.
La pressione del tasto OK, come in altri contesti, serve per selezionare l’elemento
evidenziato nella lista degli approfondimenti. La pressione dei tasti colorati ci permette di
spostarci, nell’ambito dello stesso modulo, da una lezione all’altra, il cui titolo è visualizzato
accanto al colore del tasto corrispondente. Se l’utente vuole abbandonare la sessione
corrente è sufficiente la pressione del tasto 6 per effettuare il logout e tornare alla
schermata principale, oppure quella del tasto zero per terminare l’applicazione tornando a
guardare il programma televisivo.
4.10.8.4 La selezione di un approfondimento
Come si è detto più volte la pressione del tasto OK permette di selezionare un
approfondimento. All’evento corrispondente viene invocato il metodo Evaluate string del
componente IFLogic deputato a verificare la presenza o l’assenza di approfondimenti.
Questo utilizza la stringa “nessun approfondimento” come parametro per effettuare il test
sulla stringa presente nel componente DataLabel destinato a memorizzare, via via che si
scorrono gli approfondimenti, il link di quello corrente.
Se true Æ la pressione del tasto OK non genera niente
Se false Æ viene invocato il metodo Parser del componente T-Learning cui
vengono passati il tipo di TASK = lezione e il link cui la servlet dovrà connettersi come
risultato del metodo getString del componente DataLabel dei link degli approfondimenti.
108
Capitolo 4
Sviluppo dell’applicazione client
Di seguito viene invocato il metodo Perform action() applicato al componente action che
raggruppa tutte le azioni che l’applicazione deve compiere per visualizzazione della lezione
(vedi paragrafo 4.10.8.2).
Al termine viene visualizzato l’approfondimento desiderato:
Figura 42. Screenshot di un approfondimento
Dalla Figura 42 si nota come anche in un approfondimento si possono effettuare le
stesse operazioni di una lezione. In più è possibile, pigiando il tasto 1 del telecomando,
tornare indietro, alla pagina di cui quella corrente è approfondimento.
Come si è visto nei paragrafi precedenti, una delle prime cose che fa l’applicazione è
di effettuare dei test tra i quali c’è anche quello sulla presenza o sull’assenza del link che
permette di tornare alla pagina precedente. Questo è possibile mediante l’invocazione del
metodo Evaluate boolean del relativo componente IFLogic cui viene passato come
109
Capitolo 4
parametro,
Sviluppo dell’applicazione client
per
effettuare
il
test,
il
valore
booleano
risultato
del
metodo
getPresenza_precedente del componente T-Learning.
Se true Æ
Mediante un opportuno metodo di get del componente T-Learning viene
memorizzato il link della pagina precedente in un’etichetta grafica resa invisibile.
Viene abilitato il componente csNumber che contiene specificata la gestione della
pressione del tasto 1 ed infine è resa visibile la Label recante la dicitura:“1 per tornare
indietro”
Se false Æ
Viene disabilitato il componente csNumber che contiene la gestione della pressione
del tasto 1 e resa invisibile l’etichetta grafica recante la dicitura”1 per tornare indietro”
La pressione del tasto 1 sfrutta il risultato del test appena descritto. Infatti l’evento
collegato invoca il metodo Parser del componente T-Learning cui vengono passati il link
immagazzinato nel Label chiamato indirizzo_indietro in cui sicuramente è presente
l’indirizzo della pagina precedente ed il TASK=lezione. Di seguito vengono eseguite tutte
le azioni necessarie alla visualizzazione di una lezione (vedi paragrafo 4.10.8.2).
4.10.8.5 La gestione della visualizzazione di più immagini contestuali
Nel corso della navigazione può capitare, come nel caso del sito Web, che
contestualmente alla lezione o agli approfondimenti siano presenti più immagini da
visualizzare. Visto che è presente una sola area per la visualizzazione delle immagini,
all’utente viene data la possibilità di visualizzarne una alla volta, informandolo con
un’apposita Label, visibile solo se c’è più di un’immagine, che “Usa le frecce destra e
sinistra per scorrere le immagini”.
Come abbiamo già accennato, l’applicazione effettua un test per verificare se nella
pagina richiesta sono presenti una o più immagini contestuali. Tale test viene effettuato
mediante il componente Evaluator che sfrutta come parametro il numero delle righe del file
DSML dei link delle immagini, ossia il numero delle immagini immagazzinato in forma di
stringa su un’apposita etichetta resa non visibile. Il componente, mediante un opportuno
metodo, effettua il confronto tra il numero memorizzato nell’etichetta ed il numero 1:
Se il numero delle immagini è <o = 1 Æ viene resa invisibile l’etichetta grafica che
reca la dicitura “Usa le frecce destra e sinistra per scorrere le immagini” e disabilitato il
110
Capitolo 4
Sviluppo dell’applicazione client
componente csNumber adibito alla gestione della pressione dei tasti per scorrere le
immagini, le frecce destra e sinistra.
Se il numero delle immagini è > 1 Æ viene resa visibile l’etichetta grafica che
informa l’utente della possibilità di visualizzare più immagini e viene abilitato il
componente che gestisce la pressione delle frecce destra e sinistra.
Figura 43. Screenshot di approfondimento con la presenza di più immagini contestuali
La pressione della freccia destra permette di spostare il cursore del componente,
reso non visibile, Data Aware List contenente le stringhe con i link delle immagini, nella
posizione successiva in modo tale che il cursore evidenzi il link successivo. Di seguito,
mediante un opportuno metodo, viene prelevato il link evidenziato e passato al
componente imageDisplay che carica e visualizza l’immagine relativa.
111
Capitolo 4
Sviluppo dell’applicazione client
Viceversa alla pressione della freccia sinistra il cursore si sposta nella posizione
precedente a quella del link corrente. Passato il link evidenziato al componente
imageDisplay, l’immagine, mediante un opportuno metodo, viene così visualizzata.
112
Capitolo 5
Sviluppo dell’applicazione server
5
Capitolo 5
Sviluppo dell’applicazione server
Come illustrato in precedenza, per permettere di contenere l’applicazione MHP in
dimensioni e complessità, molto del lavoro è stato svolto su un server dove i problemi di
spazio sono risolti e le potenzialità di calcolo sono molto superiori a quelle di un Set Top
Box.
Dato che il sito, che rappresenta la piattaforma di formazione a distanza
dell’Università di Siena è perfettamente funzionante, non c’è stato bisogno di modificarne
la struttura, è stato altresì necessario manipolarne le funzionalità e la struttura
rappresentativa dei contenuti per adattarli al contesto della televisione digitale. Le
applicazioni prodotte nell’ambito di questa tesi sono state progettate in modo da rendere i
contenuti normalmente fruibili a mezzo di un computer capace di navigare in internet e
mediante un decoder adibito ad uso domestico.
Il lavoro lato server è consistito in uno studio accurato della logica client-server
della FAD, nella scelta delle opportune librerie da utilizzare e dal relativo sviluppo
dell’applicativo servlet Java con conseguente interfacciamento lato client lato server.
5.1 Logica Client-Server
Per lo studio del tipo di informazioni e del loro flusso generato durante
l’interazione Browser Web-Server server remoto si è fatto uso di un programma che prende
il nome di “sniffer”.
Uno sniffer e' un qualsiasi strumento, sia esso un software o un apparato hardware,
che raccoglie le informazioni che viaggiano lungo una rete.
Questa rete può utilizzare un protocollo di comunicazione qualunque: Ethernet,
TCP/IP, IPX o altri. Il termine “sniffer” si riferisce a: “The Sniffer Network Analyzer”, il
nome del primo programma di questo tipo, sviluppato dalla Network Associates, Inc. e
protetto da trademark. Da allora la parola “sniffer” è diventata di uso comune, come ad
113
Capitolo 5
Sviluppo dell’applicazione server
esempio la parola “PC”, e con essa ci si riferisce a tutti i programmi che implementano
quelle stesse funzioni.
Le funzioni tipiche degli sniffer non differiscono di molto e possono essere
riassunte sinteticamente in:
•
Conversione e filtraggio dei dati e ei pacchetti in una forma leggibile dall’utente;
•
Analisi dei difetti di una rete, ad esempio il tentativo di capire come mai il computer
“A” non riesca a dialogare con il computer “B”;
•
Analisi di qualità e portata della rete, ad esempio per scoprire “colli di bottiglia”
lungo la rete;
•
Setacciatura automatizzata di password e username (in chiaro o, più spesso cifrati),
per una successiva analisi;
•
Creazione di “log”, lunghi elenchi che contengono la traccia, in questo caso, del
traffico sulla rete;
•
Scoperta di intrusioni in rete attraverso l’analisi dei log del traffico[].
La versione che abbiamo usato noi si chiama “Http Analyzer”[]. Grazie
all’esecuzione di questo software è stato possibile generare dei log in cui vengono riportati:
richieste Http e relative risposte, messaggi di errore o di esito positivo e contenuti
informativi veicolati.
Figura 44. Finestra di visualizzazione dei log registrati dallo sniffer: header della richiesta e della
risposta Http
114
Capitolo 5
Sviluppo dell’applicazione server
5.1.1 Interazione Browser Web-FAD
Il lavoro di sviluppo del lato server è consistito nell’elaborazione di un’architettura
software che fosse in grado di fare da tramite tra le richieste dell’utente e la piattaforma
Web. L’applicativo avrebbe dovuto ricevere le richieste, interpretarle e restituire, dopo
un’adeguata manipolazione, le informazioni che erano state richieste. Un lavoro non da
poco, che richiedeva uno studio molto accurato della dinamica delle informazioni passate
attraverso il protocollo http. Per questo è stato nuovamente necessario passare in rassegna
un po’ di pagine del sito tenendo, questa volta lo sniffer “in ascolto”. La navigazione si è
svolta attraversando ogni nodo dell’albero di cui si è già discusso (vedi paragrafo 3.2.2
Figura 12 pag. 58). In sostanza si è tentato di coprire tutti i casi in cui c’era effettivamente
passaggio di informazione tra browser ed server remoto.
Partiamo dalla pagina di benvenuto, quella che risponde al link http://fad.unisi.it,
nella quale abbiamo visto essere presenti, oltre alle varie informazioni per la fruizione dei
servizi disponibili, i form necessari all’autenticazione (vedi paragrafo 3.2.2 pag. 57 Figura
11). Tale pagina è il body della risposta del server remoto il cui header contiene, come
informazione di interesse, il campo Set-Cookie nel quale è contenuto appunto il Cookie.
Pertanto disponiamo già di un’informazione: al primo accesso alla FAD (mediante la
richiesta della pagina http://fad.unisi.it) viene settato il Cookie.
Digitiamo username e password, e cliccando sulla freccetta (vedi sempre paragrafo
3.2.2 pag. 57) diamo il via all’autenticazione. Così facendo il browser trasmette al server
remoto le stringhe del Cookie, della username e della password settando i campi dell’header
della richiesta dal nome:
•
Cookie;
•
Username;
•
Password.
Il server remoto restituisce al browser la pagina dei profili attivi all’interno del body
della risposta.
Da questo punto in poi ogni volta che il browser effettuerà una richiesta al server
remoto passerà sempre i tre parametri attraverso i campi dell’header della richiesta visti.
Queste saranno le tre stringhe che identificheranno l’utente nel corso della navigazione.
115
Capitolo 5
Sviluppo dell’applicazione server
Quando l’utente decide di non fruire più del servizio può decidere di abbandonare
la sessione corrente cliccando sull’apposito link e dando successivamente conferma
dell’abbandono. Nell’header della richiesta è presente oltre ai soliti campi del cookie, della
username e della password anche un campo “Referer” che contiene una stringa recante il
link relativo alla pagina in cui l’utente si trovava prima di abbandonare la sessione.
Primo accesso alla FAD
Host http://fad.unisi.it
Richiesta get http
browser
HTTP
Risposta:
campo
Cookie nell’header
contenente
la stringa del
Cookie
FAD
Figura 45. Lo scambio di informazioni browser-FAD al primo accesso alla piattaforma
Richiesta Http di tipo get
con passaggio dei
parametri Cookie,
Username e Password in
appositi campi dell’header
browser
Fase di login
HTTP
Risposta da parte
del server
remoto
FAD
Figura 46. Lo scambio di informazioni browser-FAD nella fase di login dell’utente
Richiesta Http con
l’aggiunta nell’header del
campo Referer recante il
link dell’ultima pagina
visitata
browser
Fase di logout
HTTP
Risposta da
parte del server
remoto
FAD
Figura 47. Lo scambio di informazioni browser-FAD nella fase di abbandono sessione
116
Capitolo 5
Sviluppo dell’applicazione server
5.2 Considerazioni pre-sviluppo
Data la natura della rappresentazione dell’informazione, è stato necessario pensare
bene alla strategia da adottare. L’output della piattaforma è costituito da pagine HTML
prodotte con tecnologia ASP, sicché codice html per la rappresentazione dei contenuti con
l’aggiunta di JavaScript per la gestione della navigazione all’intero e tra le pagine. Lo studio
di fattibilità iniziale (vedi capitolo 3 “Le scelte progettuali”) è stato fondamentale. Infatti ci
ha permesso, in base allo studio delle pagine del sito di fissare un ben preciso iter di
sviluppo e soprattutto di stabilire le operazioni che era necessario che effettuasse
l’applicativo servlet Java. Si è deciso di procedere seguendo ancora una volta l’andamento
dell’architettura ad albero rappresentante la logica di funzionamento del sito del corso.
Pertanto si è deciso di sviluppare l’applicativo un task alla volta, e solo dopo averne testato
il corretto funzionamento di passare allo sviluppo del task successivo e cosi via. La scelta
della libreria da utilizzare per rendere “well-formed” il codice delle pagine prelevate è stata
molto importante. Infatti è grazie ad essa che è stato possibile riuscire a manipolare i
contenuti e a creare un corrispondente file XML “well-formed”. La scrittura dei fogli stile
XSL[21] ci ha impegnato per tutta la durata dello sviluppo dell’applicazione. Infatti il loro
perfezionamento si è evoluto in concomitanza all’interfacciamento vero e proprio. Si è
tenuto conto infatti, sia del fatto che si doveva seguire modello dati XML da noi elaborato
(vedi paragrafo 4.3 pag. 76) sia del fatto che il lato client imponeva determinate esigenze
grafiche per la rappresentazione dei contenuti (un esempio sono gli spazi multipli…).
Seguendo questa strada è stato possibile realizzare un applicativo scritto in Java che riesce
ad interpretare a livello logico le richieste effettuate lato client e riesce a restituire i
contenuti richiesti opportunamente rielaborati, per mezzo di trasformazioni XSLT[21].
La scelta del linguaggio Java[27] per lo sviluppo della logica e del dialetto XSL[21]
per le trasformazioni XSLT[21] rende l’applicazione server assai versatile nel suo utilizzo.
Java[27] garantisce la ampia portabilità dell’applicazione grazie al fatto di essere un
linguaggio indipendente dalla piattaforma e le trasformazioni XSLT[21] permetto
l’interfacciamento con qualunque tipo di sito per il quale sia possibile elaborare un modello
di trasporto di dati omogeneo secondo le indicazioni dello standard W3C. In pratica,
avendo a disposizione un altro sito i cui contenuti siano organizzati in modo omogeneo, è
sufficiente modificare i fogli di stile per garantire l’interfacciamento anche a quel sito.
117
Capitolo 5
Sviluppo dell’applicazione server
5.3 Le librerie utilizzate
HTML Tidy[] è uno dei più antichi e noti validatori HTML sviluppati non solo per
Windows ma anche per Linux. Diffuso in decine di versioni e integrato in molti programmi
di editing (tra cui UltraEdit solo per fare un esempio…), è stato sviluppato per la prima
volta da Dave Ragget, grande divulgatore e membro del Consorzio WWW. Ora il progetto
è sostenuto da un team di sviluppatori ed è stato accolto nella comunità di SourceForge.
Tidy è in grado di verificare gli errori del codice HTML e di restituire il file
modificato e parzialmente corretto. Gli errori che esso corregge sono:
•
La mancata chiusura di un tag;
•
La ripetizione involontaria di un tag;
•
Errori di codifica;
•
Ecc…
JTidy[19] è il parente Java di Tidy. Si tratta di una libreria open source, dotata
quindi di tutti i vantaggi di tale tipo di software. Dispone di metodi ed attributi che
permettono il settaggio di parametri per la correzione del codice e assicura output
sottoforma di file XML o XTML del documento HTML esaminato. Infatti dispone di
un’interfaccia DOM che favorisce il suo utilizzo a mo di parser per il mondo HTML.
5.4 Il dialetto XSL
Molti dei vantaggi del modo in cui è stato implementato il proxy-server sono insiti
nella scelta di XSLT come linguaggio di programmazione per produrre le stringhe
XHTML. Infatti XSLT è un linguaggio di programmazione molto potente. Il fine per il
quale è stato realizzato è quello di manipolare i documenti XML per trasformarli in altri tipi
di documenti, HTML, XHTML, testo semplice e diversi altri tipi di documenti. Possiamo
utilizzarlo anche per trasformare un documento XML in un altro documento XML con
una struttura diversa. Quello che fa XSLT è dire al programma che opera la trasformazione
cosa fare quando trova un determinato elemento racchiuso in determinati tag. Il
procedimento di trasformazione di un documento XML viene effettuato da un processore,
che è un’applicazione (o componente software) che legge un documento XML e un
documento XSLT e applica XSLT a XML. I processori esistono sia come applicazioni
118
Capitolo 5
Sviluppo dell’applicazione server
eseguibili da riga di comando, sia come componenti software che possono essere utilizzati
in un’applicazione. I processori che si occupano di questa operazione si basano
sull’operazione di parsing del documento XML. Questo parser può caricare i documenti
XML e XSLT per mezzo di DOM e quindi applicare XSLT a XML. Un’altra opzione è un
processore basato su SAX. DOM e SAX sono ambedue standard per la creazione di oggetti
che si riferisco all’albero del documento XML. Il primo considera come evento il
documento XML stesso e lo associa all’albero, mentre il secondo legge il documento un
elemento alla volta. Ogni elemento che l’analizzatore sintattico incontra innesca un evento.
Un grande vantaggio è che praticamente non utilizza memoria, perché non è necessario
costruire l’intero documento in memoria.
Ciò ce costituisce un altro punto di forza di XSLT è senza dubbio il fatto che per
l’accesso ai nodi è possibile utilizzare XPath[18][21] (vedi paragrafo 3.2.8.2 pag. 71)[].
5.5 Lo sviluppo e le strategie di sviluppo
Per procedere in modo migliore allo sviluppo dell’applicativo Java[27] si è deciso di
procedere appoggiandosi dapprima ad una classe Java[27] dotata del solo metodo main per
fare delle prove; testando l’output generato con un editor XML dotato di processore
XSL[21] quale è XMLSPY[] di cui si è discusso nella sezione dedicata alle scelte progettuali
(vedi paragrafo 3.2.6 pag. 66).
In pratica non si è fatto altro che scrivere il codice java[27] che effettuava :
•
Pulizia del codice HTML
•
Messa a well-formed del codice pulito
•
Trasformazione in XML
•
Trasformazione XML Æ XHTML attraverso fogli di stile XSL[21]
E di testare se il file XML, output del metodo main, fosse well-formed e di seguito
lo stesso per il file XHTML tenendo aperto in contemporanea XMLSPY.
Questa è stata una fase cruciale del lavoro perché ci ha permesso di stabilire se
valeva veramente la pena di andare avanti con lo sviluppo del progetto seguendo la strada
intrapresa oppure di cambiare rotta. Trovare le espressioni in sintassi XPath[18][21] adatte
ad individuare i nodi con i contenuti che ci servivano è stata un’operazione molto
complicata data che non tutte le pagine erano uguali. Fortunatamente dopo vari tentativi si
119
Capitolo 5
Sviluppo dell’applicazione server
sono ottenuti risultati incoraggianti che ci hanno permesso di continuare con lo sviluppo
dell’applicativo Java Servlet.
5.5.1 La tecnologia Java Servlet
Le Servlet sono moduli software scritti in Java che vengono eseguiti in applicazioni
lato server per esaudire le richieste dei client. Esse non sono legate ad un particolare
protocollo per la comunicazione tra client e server, anche se più comunemente si utilizza il
protocollo HTTP ed infatti si parla di http Servlet. Per scrivere una Servlet si fa uso delle
classi del package javax.servlet che è il framework di base per la scrittura delle servlet e del
package javax.servlet.http che è l'estensione del framework di base, per la comunicazione
via http. Utilizzando un linguaggio portabile come Java, le Servlet consentono di realizzare
soluzioni per estendere le funzionalità dei server web, indipendenti dal sistema operativo su
cui esse vengono eseguite[].
5.6 Il funzionamento della Servlet
Come nel caso dello sviluppo lato client anche qui si è cercato di rispettare il più
possibile la dinamica del sito originale, ripristinando quelle funzionalità che erano andate
perse con l’opera di manipolazione del codice delle pagine per rendere possibile il porting
dei contenuti. Ancora una volta si è deciso di seguire passo passo l’architettura del sito del
corso. Il funzionamento della servlet è stato quindi suddiviso in opportuni TASK:
•
Login
•
Profilicorsiattivi
•
Sezioni
•
Moduli
•
Modulo
•
Lezione
•
Logout
Ogni TASK corrisponde, come si vede, ad ogni nodo dell’albero che percorre
l’utente nella navigazione.
120
Capitolo 5
Sviluppo dell’applicazione server
La prima cosa che fa la servlet è quella di ricevere dall’applicazione client e
memorizzare in variabili stringa opportune i parametri:
•
Username, Password e TASK (via Http POST);
•
Link da sfruttare per la connessione in un campo della richiesta appositamente
creato (vedi capitolo 4 paragrafo 4.10 pag. 94).
La servlet esegue un test verificando quale TASK è stato ricevuto e così lo esegue.
5.6.1 Il TASK di Login
La servlet imposta una connessione HTTP al sito “http://fad.unisi.it”, e dall’header
della risposta estrae il valore del campo chiamato Cookie e lo memorizza in una variabile
stringa. A questo punto il cookie, la username e la password vengono inseriti in opportuni
record della tabella del database che serve alla gestione della sessione utente.
Terminata con successo questa prima fase, l’applicativo si connette via Http
all’URL “http://fad.unisi.it/login-new.asp” settando nell’header della richiesta il campo
Cookie cui vengono concatenate la username e la password:
seconda_httpconn.setRequestProperty("Cookie",stringa_cookie+";"+username=
"+username+"; "+"password="+password+";");
Viene effettuato un test sull’andamento a buon fine della connessione:
Se il campo dell’header della risposta ResponseCode contiene il valore 200 allora
vengono eseguite tutte le operazioni del TASK login altrimenti viene stampato in output un
messaggio di errore, in questo caso un banale ma pertinente “errore di connessione” e la
servlet termina la sua esecuzione.
5.6.1.1 Le operazioni del TASK = Login
Se la connessione Http tra gateway e la FAD avviene con successo l’applicativo
Java legge la pagina del sito contenuta nel body della risposta. La pagina viene letta riga per
riga ed il contenuto testuale viene riversato tutto in una variabile di tipo stringa.
Adesso ha inizio la procedura di “pulizia” del codice da quegli elementi o quei tag
che non permettono la generazione, per mezzo di JTidy[19], del codice XML voluto.
L’operazione di “pulizia” viene eseguita mediante l’invocazione del metodo replaceAll()
121
Capitolo 5
Sviluppo dell’applicazione server
della classe String facendo uso soprattutto, di alcune espressioni regolari[23][24]. Si riesce
così ad eliminare parte di codice non voluto, tag o elementi con i relativi tag e a sostituirli
con altri pezzi di codice o semplicemente con spazi vuoti. L’utilizzo di questo tipo di
tecnica è risultato molto potente perchè ci ha permesso di risparmiare notevolmente sulla
complessità e sul numero delle righe di codice. Le operazioni di pulizia sono state due:
•
Una per eliminare errori che metteva in evidenza Tidy e che da solo non riusciva a
correggere (infatti lo stesso Tidy non riesce a correggere tutti gli errori ed inoltre si è tenuto
presente che la libreria usata è open source, quindi era possibile che non fosse
perfettamente funzionante), per permettere l’utilizzo di espressioni regolari[23][24] più
potenti che altrimenti non avrebbero funzionato;
•
Una seconda per eliminare quelle parti di codice che non ci interessavano
(JavaScript, commenti ecc….)
Durante la prima pulizia si sostituisce “</tr>” tutte le volte che si verifica una
doppia ripetizione dello stesso tag. Uno spazio bianco viene sostituito tutte le volte che si
trovano i tag: “</form>”, “<span class=”grassetto”>”, “</span>”, “&nbsp;” , “<br
/>”. La stringa risultante viene fatta processare dal validatore Tidy della libreria JTidy[19]
di cui si è parlato in precedenza (paragrafo 5.3 pag. 118), il quale viene precedentemente
impostato mediante opportuni metodi che gli passano i valori di settaggio.
Il file generato viene ripulito una seconda volta. Con quest’operazione viene
eliminata la parte JavaScript del codice utilizzando l’espressione regolare:
“<script[^>]*>[\\w|\\t|\\r|\\W]*</script>”
Questa espressione intercetta tutta la porzione di codice all’interno dei tag <script e
</script>, tag di apertura e chiusura compresi. Vengono eliminati inoltre tutti i commenti
per mezzo dell’espressione :
<!--((?!-->).)*-->
(tutto quello che si trova all’interno di <!-- --> estremi compresi)
Il file “ripulito” per la seconda volta viene ora riprocessato da Tidy e reso “wellformed” trasformandolo in un file XML. A questo file XML viene applicata una
122
Capitolo 5
Sviluppo dell’applicazione server
trasformazione XSL[21] per mezzo di un opportuno foglio di stile XSLT. In questo modo
si ottiene una prima stringa XHTML. Questa viene sottoposta ad un’altra opera di
rifinitura. Per esigenze di rappresentazione dell’informazione vengono eliminate tutte le
ripetizioni di spazi bianchi e tutte le stringhe della forma “../”
Alla fine di tutte queste operazioni, la servlet restituisce in output la stringa
XHTML della pagina dei profili secondo il formato dati XML fissato da noi nella fase
iniziale di sviluppo (vedi paragrafo 4.3.2 pag. 77).
Figura 48. Output del TASK Login
123
Capitolo 5
Sviluppo dell’applicazione server
TASK = LOGIN
Gateway
Applicativo
1. IF TASK = LOGIN
2.
RECUPERO
USERNAME
PASSWORD DALLA POST
E
3.
CONNESSIONE
FAD.UNISI.IT
A
HTTP
Interrogazione
database per
immissione dati
4.
RECUPERO
COOKIE
DALL’HEADER DELLA RISPOSTA
5. COSTRUZIONE STRINGA PR
COOKIE
DA
PASSARE
NELL’HEADER DELLE RICHIESTE
SUCCESSIVE
Database
MySQL
6.
STORE
SU
DATABSE
DI
USERNAME/PASSWORD, COOCKIE
E SCADENZA DELLA SESSIONE
7.
CONNESSIONE
A
FAD.UNISI.IT/LOGIN_NEW.ASP
PASSANDO LA STRINGA COOCKIE
NELL’HEADER
Connessione Http alla
FAD con stringa
Cookie,Username e
Password nell’header
della richiesta
8. CONTROLLO DELL’ “OK” DELLA
CONNESSIONE
(LOGIN
EFFETTUATO)
9.
SE
NO
OK
ALLORA
COSTRUZIONE DI UN MESSAGGIO
DI ERRORE DA MANDARE IN
OUTPUT
FAD
10. SE OK, RECUPERO DEL BODY
DELLA RISPOSTA, PULIZIA DELLA
PAGINA HTML CON JTIDY E
TRASFORMAZIONE CON APPOSITO
FILE XSLT
Restituzione
pagina nel
body della
11. RESTITUZIONE DELL’OUTPUT
Connessione Http
POST con
passaggio stringhe :
Cookie, Username e
Password e link
nell’header
Restituzione stringa
XHTML
CLIENT
Figura 49. Le operazioni portate a termine nell'esecuzione del TASK Login
124
Capitolo 5
Sviluppo dell’applicazione server
5.6.2 Il TASK profilicorsiattivi
La servlet si connette alla tabella del database per la gestione della sessione ed estrae
i tre parametri:
•
Cookie;
•
Username;
•
Password.
Per questo vengono selezionati i tre record relativi all’utente che fruisce della
sessione corrente ed i loro valori vengono memorizzati in altrettante variabili i tipo String.
Prima viene recuperato il link dal campo “indirizzo” dell’header della richiesta e poi
viene effettuata la connessione alla FAD settando nell’header Cookie, Username e
Password estratti in precedenza. Anche in questo caso viene effettuato un test
sull’andamento a buon fine della connessione:
Se il valore del campo ResponseCode dell’header della risposta è pari a 200 allora
vengono effettuate le operazioni del TASK altrimenti viene visualizzato in output la
dicitura “errore nella connessione”.
5.6.2.1 Le operazioni del TASK profilicorsiattivi
Se la connessione tra servlet e FAD va a buon fine la servlet legge la pagina
contenuta nel body della risposta e la memorizza riga per riga in una stringa. Questa stringa
viene sottoposta ad una prima procedura di pulizia simile alla prima pulizia compiuta nel
task di login (vedi paragrafo 5.6.1.1 pag. 121). Qui in più viene sostituita la lettera accentata
“è” con l’entità corrispondente “&#232;” e l’apice singolo “ ‘ ” con la relativa entità
“&#8242;”.
Segue la correzione con JTidy[19] e una seconda opera di pulizia con eliminazione
di codice JavaScript e commenti. Alla stringa XHTML prodotta, per esigenze di
visualizzazione lato client, vengono tolti gli spazi in eccesso come nel caso del login e poi
viene restituita in output.
125
Capitolo 5
Sviluppo dell’applicazione server
5.6.3 I TASK sezioni, moduli e modulo
Le operazioni in questione portano a termine le stesse azioni del TASK descritto
nel paragrafo precedente. La presenza ed il nome diverso sono dovuti al fatto che ognuno
di questi è associato ad un foglio di stile differente.
TASK = SEZIONI,MODULI,MODULO
Interrogazione
database per
recupero dati
Gateway
Applicativo
Database
MySQL
1.
IF
TASK
=
CORSI,SEZIONI,MODULI,MODULO
2. INTERROGAZIONE DATABASE
3.
RECUPERO
USERNAME,PASSWORD E COOCKIE
4.
RECUPERO
LINK
CORSO,SEZIONE,MODULO
DALL’HEADER DELLA RICHIESTA
5.
CONNESSIONE
A
CORSO,SEZIONE,MODULO
Connessione
Http alla FAD
con stringa
Cookie,Usernam
e e Password
nell’header della
richiesta
Restituzione
Cookie,Username
e Password
LINK
FAD
6. PASSAGGIO DELLA STRINGA
COOCKIE NELL’HEADER DELLA
RICHESTA
7. TEST CONNESSIONE
8. SE NON “OK” ,INVIO DI UN
MESSAGGIO DI ERRORE
9. SE “OK”, RECUPERO BODY
DELLA RISPOSTA,PULIZIA CON
JTIDY E TRASFORMAZIONE CON
FOGLIO DI STILE OPPORTUNO
Richiesta Http di
tipo POST
passando Cookie
Username e
Password e link
nell’header
Restituzione
pagina richiesta
nel body della
risposta
10. RESTIUTIZIONE DELL’OUTPUT
Restituzione
stringa XHTML
CLIENT
Figura 50. Le operazioni portate a termine nell'esecuzione del TASK sezioni, moduli e modulo
126
Capitolo 5
Sviluppo dell’applicazione server
5.6.4 Il TASK Lezione
Questo è il TASK più importante dell’applicativo server Java. Qui vengono ricreate
tutte quelle funzionalità che temporaneamente erano state eliminate con la pulizia del
codice delle pagine. Il TASK permette la fruizione della parte più importante del servizio: la
Lezione. Si riesce a recuperare la possibilità di tornare alla pagina precedente, ove ciò sia
possibile, rispettando il comportamento del sito.
La prima cosa che fa è recuperare il link della pagina della quale dovrà recuperare i
contenuti. Anche qui, come nei task descritti nel paragrafo precedente, il link della pagina
viene passato dal client MHP all’applicativo server attraverso l’header della richiesta
sfruttando il campo “indirizzo”, appositamente creato. La servlet effettua un test per
stabilire se prelevare la pagina precedente dall’apposita tabella del database oppure iniziare
con le operazioni del TASK in questione. Il test viene effettuando invocando il metodo
equals della classe string utilizzando come parametro la stringa:
javascript:history.back
Se il link passato dall’applicazione MHP combacia con il parametro allora vengono
effettuate le operazioni per il ritorno alla pagina precedente, altrimenti la servlet esegue le
operazioni del TASK Lezione.
5.6.4.1 Le operazioni per il recupero della pagina precedente
La servlet Java si connette al database creato per la gestione della sessione e quindi
alla tabella che contiene gli indirizzi delle pagine delle lezioni cancellandone l’ultimo inserito
in ordine di tempo. Dopodiché preleva l’ultimo rimasto dalla cancellazione in ordine di
tempo e lo memorizza in un’opportuna variabile “sito” di tipo String. In pratica ha
prelevato l’indirizzo della pagina precedente alla pagina correntemente fruita lato client. A
questo punto la servlet si connette al link prelevato e svolge tutte le operazioni proprie del
TASK lezione.
5.6.4.2 Le operazioni del TASK Lezione
La servlet immagazzina l’indirizzo prelevato dall’header della richiesta nella variabile
“sito”. Si connette al database e alla tabella dei link delle pagine per immagazzinare l’URL
in un apposito record. Questa operazione viene fatta tutte le volte che la condizione di
127
Capitolo 5
Sviluppo dell’applicazione server
verifica per la pagina precedente è falsa anche se quella pagina magari si era già stata
visitata prima. Così facendo si riesce a tener conto dell’iter della navigazione dell’utente. A
questo punto si interroga nuovamente il database ma connettendosi alla tabella delle pagine
del sito. Viene effettuato un test sfruttando sempre il link passato, per verificare se la
pagina richiesta dall’utente sia stata già visitata in precedenza:
Se il link è presente allora viene estratta la pagina che si trova nel record
corrispondente al record che contiene l’indirizzo e viene mandata come output della servlet
risostituendo l’apice singolo “ ‘ ” all’entità “&#8242;”(la sostituzione inversa era stata fatta
la prima volta che la pagina era stata richiesta) altrimenti si procede effettuando le seguenti
azioni:
La servlet si collega al database per recuperare i tre parametri Cookie, username e
password e memorizzarli in variabili apposite di tipo String.
Quest’ultimi vengono passati nel body della richiesta durante la connessione Http
POST alla FAD utilizzando il link contenuto nella variabile “sito”. La pagina contenuta nel
body della risposta viene letta riga per riga e memorizzata in una variabile di tipo stringa.
Questa stringa viene sottoposta ad una doppia pulizia. Una per eliminare i tag che generano
errori nel processamento Tidy ed una per eliminare la parte inutile del codice della pagina.
Viene sottoposta nuovamente a JTidy[19] per generare il file XML contente i contenuti di
nostro interesse. Questo file viene sottoposto a trasformazione XSLT per mezzo di un file
XSL[21] appositamente scritto. La stringa XHTML risultante rappresenta l’output della
servlet relativo a questo TASK.
La stessa stringa viene prima adattata(viene sostituito l’apice singolo “ ‘ ” con la
corrispondente entità “&#8242;”) e poi immagazzinata nella tabella che funge da cache
della servlet. L’indirizzo e la pagina vengono immagazzinati in due record appartenenti ad
una stessa riga.
128
Capitolo 5
Sviluppo dell’applicazione server
Gateway
Applicativo
Interrogazione per
recupero dati
1. IF TASK = LEZIONE
2. REUPERO LINK DELLA LEZIONE
DALL’HEADER DELLA RICHIESTA
3. TEST UTILIZZANDO LA STRINGA
“JAVASCRIPT:HISTORY.BACK”
Database
MySQL
4.
SE
“OK”
ALLORA
INTERROGAZIONE
TABELLA
INDIRIZZI DEL DATABASE
5. ELIMINAZIONE LINK PAGINA
CORRENTE
6.
RECUPERO
PRECEDENTE
CORRENTE
LINK
A
PAGINA
QUELLA
7.
SOTITUZIONE
LINK
RECUPERATO
DALL’HEADER
DELLA RICHIESTA CON QUELLO
ESTRATTO DAL DATABASE
8. SE NON “OK” ALLORA STORE
DEL
LINK
RECUPERATO
IN
OPPORTUNA VARIABILE STRINGA
9. STORE DEL LINK NELLA
TABELLA DEGLI INDIRIZZI
10. INTERROGAZIONE TABELLA
DELLE PAGINE (CACHE) PER
MEZZO
DEL
LINK
IMMAGAZZINATO, TEST SULLA
PRESENZA DI TALE LINK IN UN
RECORD DELLA TABELLA
11. SE “OK” ALLORA PRELEVA LA
PAGINA CORRISPONDENTE AL
LINK
Restituzione
dati a seconda
delle tabelle
interessate nei
vari punti del
TASK
Restituzione
stringa
XHTML
FAD
Connessione Http con
passaggio stringa
Cookie,Username e
password in un campo
dell’header
12. MANDA IN OUTPUT L’XHTML
GIA PRONTO
13.
SE
NON
“OK”
ALLORA
INTERROGAZIONE A DATABASE
14.
RECUPERO
USERNAME,
PASSWORD E COOKIE
11.
CONNESSIONE
AL
LINK
IMMAGAZZINATO CON PASSAGGIO
DELLA
STRINGA
COOCKIE
NELL’HEADER
12. TEST SULLA CONNESSIONE
13. SE NON “OK” INVIO IN OUTPUT
DI UN MESSAGGIO DI ERRORE
14. SE “OK” RECUPERO BODY
DELLA RISPOSTA,PULIZIA CON
JTIDY E TRASFORMAZIONE CON
FOGLIO DI STILE OPPORTUNO
15. RESTITUZIONE IN OUTPUT
DELL’XHTML OTTENUTO DALLA
TRASFORMAZIONE
16.
“STORE”
DELLA
STESSA
Restituzione stringa
XHTML
CLIENT
MHP
Connessione Http di
tipo POST passando
Cookie, Username e
Password e il link della
lezione nell’header
129
Capitolo 5
Sviluppo dell’applicazione server
5.7 La scrittura dei fogli di stile
Una parte fondamentale del nostro lavoro è stata senza dubbio la scrittura dei fogli
di stile da associare alle stringhe xml ripulite con Tidy. Il loro utilizzo ci ha permesso di
estrarre i contenuti dalle pagine ripulite e di inserirli all’interno dei relativi tag del modello di
trasporto di dati XML da noi definito per arrivare a generare le pagine XHTML richieste.
5.7.1 L’elenco dei corsi
In questo foglio di stile sono stati utilizzati due template, uno per il titolo ed uno
per l’approfondimento relativo al profilo o al corso attivo. I nodi vengono selezionati per
mezzo di istruzioni a sintassi abbreviata XPath[18][21]. Viene creato un primo template che
incornicia tag iniziale finale di una pagina XHTML, all’interno del quale vengono applicati i
template relativi ai nodi intercettati del titolo e dell’approfondimento.
Template XHTML
Template
Titolo
Template
approfondimento
Figura 51. Struttura del foglio di stile per i TASK profili e corsi attivi
5.7.2 Le sezioni
Questo è il foglio di stile che viene utilizzato quando viene eseguito il task sezioni.
Serve appunto a trasformare secondo il nostro modello XML la pagina relativa alle sezioni
del corso una volta che questa sia stata ripulita e resa well-formed per mezzo di Tidy. Il
livello di difficoltà cresce man mano che ci avviciniamo al nodo della lezione, proprio
perché cresce la complessità dei contenuti e della struttura della pagina relativa.
130
Capitolo 5
Sviluppo dell’applicazione server
È stato creato un primo template che incornicia i tag iniziale e finale di una pagina
XHTML. All’interno di questo vengono applicati un template per il titolo e due per
l’approfondimento. Questa volta l’intercettazione corretta dell’approfondimento è stata più
complicata, c’è stato bisogno di due istruzioni xsl diverse per riuscire ad intercettarli tutti.
Con una si riesce a prenderne n-1, e con la seconda l’n-esima; questo perché l’n-esima fa
parte della stessa tabella ma si trova in un altro nodo.
Template XHTML
Template
Titolo
Template
Approfondimento
Template
Approfondimento
Figura 52. Struttura del foglio di stile per il TASK Sezioni
5.7.3 I moduli
In questo caso il foglio di stile adotta sempre un template che incornicia i tag
iniziale e finale di una pagina XHTML con incastonati un template per il titolo della pagina
ed un template per l’approfondimento. Si è riusciti stavolta a selezionare tutti gli elementi
“approfondimento” che ci servivano con un solo template e facendo uso di una sola
istruzione abbreviata XSL[21].
131
Capitolo 5
Sviluppo dell’applicazione server
Template XHTML
Template
Titolo
Template
Approfondimento
Figura 53. Struttura del foglio di stile associato al TASK moduli
5.7.4 L’elenco delle lezioni
In questo caso come nel caso precedente viene utilizzato un template che racchiude
i tag iniziale e finale di una pagina XHTML con incastonati due template:
•
Template per il Titolo;
•
Template per gli approfondimenti.
Template XHTML
Template
Titolo
Template
Approfondimento
Figura 54. Struttura del foglio di stile associato al TASK modulo
5.7.5 La singola lezione
Si tratta del foglio di stile più elaborato. Infatti comprende la più ampia casistica di
costrutti presenti in tutte le pagine del corso. Si comincia dal template che incornicia i tag
iniziale e finale di una pagina XHTML. Questo contiene tutti gli altri template usati per
ricostruire la struttura della pagina secondo il nostro schema XML. Sono presenti:
132
Capitolo 5
Sviluppo dell’applicazione server
•
Un Template per il Titolo;
•
Due Template per il Testo Libero;
•
Un Template per il Testo Puntato;
•
Tre Template per le immagini contestuali e non;
•
Un Template per il link che permette di tornare alla pagina precedente;
•
Un Template per l’immagina che individua il link per tornare alla pagina precedente;
•
Otto Template per gli approfondimenti;
•
Un Template per il link indietro_veloce;
•
Un Template per il link indietro;
•
Un Template per il link avanti;
•
Un template per il link avanti_veloce.
Template XHTML
Template
Titolo
2 Template
Testo Libero
Template Testo
Puntato
Tre Template
Immagini
Template Link
Precedente
Template
Immagine Prec.
8 Template
Approfondimenti
Template
indietro veloce
Template
Indietro
Template
avanti
Template
avanti veloce
Figura 55. Struttura foglio di stile associato al TASK Lezione
5.8 L’interfacciamento finale
Questa è la fase in cui si è portato a termine il progetto dando vita al servizio vero e
proprio. Le due applicazioni vengono unite in una sola. Lato client e lato server vengono
modificati per garantire lo scambio reciproco di dati e nello stesso tempo il servizio riesce a
133
Capitolo 5
Sviluppo dell’applicazione server
riproporre i contenuti residenti su Web nell’ambito della Tv digitale ricostruendo a pieno
tutte le funzionalità di dinamica logica della navigazione del sito. Il risultato complessivo è
soddisfacente nonostante il numero e la complessità delle fasi di sviluppo.
In questa fase è stata portata a termine la scrittura dei fogli di stile e affinato il
funzionamento logico dell’applicazione MHP. A maggior ragione siamo andati ad
esaminare nuovamente le pagine del sito facendo uso però dell’applicazione totale
funzionante in modo tale da testarne il funzionamento e far venire a galla il maggior
numero di errori possibili. Così facendo sono emersi nuovi aspetti della logica del sito e
soprattutto si è riusciti a coprire tutta la casistica dei contenuti ampliando il modello di dati
XML iniziale. Per il funzionamento dell’applicazione si veda il capitolo 4 paragrafo 4.9 pag.
93.
5.8.1.1 Esempio di modifica post-produzione dell’applicazione finale
La gestione del passaggio da una lezione all’altra all’interno di uno stesso modulo è
affidata alla pressione dei tasti colorati del telecomando (vedi capitolo 4 paragrafo 4.10.8
Figura 39 pag. 103). In una fase iniziale gli eventi generati dalla pressione di questi tasti
portavano all’esecuzione delle stesse azioni necessarie alla visualizzazione della lezione (vedi
paragrafo 4.10.8.2 pag. 106) mentre nella fase finale tali eventi portano sempre
all’esecuzione delle stesse azioni ma preceduta da un test sull’effettiva presenza dei link
relativi all’interno della pagina richiesta. Infatti lo studio ha evidenziato che esistono anche
delle pagine del sito in cui i collegamenti ipertestuali alle altre lezioni appartenenti ad uno
stesso modulo non sono presenti.
Pertanto la pressione di un tasto colorato per prima cosa porta all’esecuzione di un
test volto a verificare la presenza del link necessario nella pagina XHTML ricevuta,
successivamente viene fatto un altro test sulla validità del link ricevuto utilizzando come
parametro la stringa:
http://fad.unisi.it#
Questa stringa rappresenta il link che punta alla pagina correntemente fruita e serve
come confronto in caso di presenza di link di navigazione veloce prima di effettuare tutte le
istruzioni successive per il recupero della pagina
134
Capitolo 5
Sviluppo dell’applicazione server
5.9 Conclusioni e sviluppi futuri
Il servizio sviluppato nell’ambito di questo lavoro di tesi ha ottenuto come suo fine
ultimo quello di riuscire a riproporre, in maniera opportunamente adattata, contenuti creati
per il Web nel contesto della televisione digitale terrestre secondo lo standard MHP.
Questa operazione ha comportato uno studio molto approfondito della formattazione e del
layout di tali contenuti nonché della logica e della dinamica della loro organizzazione.
Basandoci sui risultati ottenuti, elaborato un opportuno protocollo di comunicazione
client-server, si è riusciti ad interfacciare il mondo DVB-MHP con il WWW. L’applicazione
MHP è stata sviluppata con l’authoring tool Cardinal Studio Professional 4.0 ed estesa con
componenti sviluppati in tecnologia JavaBean, e scambia in maniera efficace dati con la
piattaforma di formazione a distanza dell’Università di Siena servendosi del gateway
applicativo. Il servizio ripropone in modo adeguatamente adattato i contenuti del corso
“ECDL2000-La patente Europea del Computer”. La Xlet Java ha il compito di inoltrare le
richieste effettuate dall’utente, per mezzo del telecomando del televisore, alla FAD. Il
compito di interpretarle e di restituire i contenuti richiesti spetta all’applicazione lato server
sviluppata in tecnologia Java servlet. Questo rappresenta il fulcro intorno al quale ruota
tutto il servizio; è grazie ad esso che è possibile l’interfacciamento completo. I contenuti
vengono prelevati dal sito attraverso richieste Http, ripuliti degli errori tramite JTidy e
immagazzinati mediante trasformazioni XSL in stringhe XHTML per essere recuperati e
riproposti, tramite parsing sul lato client.
Per fruire del servizio è necessaria l’autenticazione dell’utente con username e
password. È possibile quindi scegliere un profilo e di seguito un corso attivo e di qui,
passando per le sezioni ed i moduli, la lezione voluta. Attualmente il servizio mostra i
contenuti sottoforma di immagini e testo permettendo all’utente di navigare tra le varie
schermate seguendo fedelmente la logica delle pagine del sito, è dotato quindi di una basso
livello di interattività. Uno sviluppo sarà sicuramente quello di introdurre una sezione
relativa ai test dei livelli di conoscenze acquisite con relativa limitazione di accesso a sezioni
o moduli previo raggiungimento di crediti e/o punteggi, aumentando il grado di
apprendimento dei contenuti ma nello stesso tempo il livello di interattività del servizio. Un
ulteriore
sviluppo
dell’applicazione
prevede
l’automazione
del
meccanismo
di
riconoscimento dell’utente e di accesso ai profili o ai corsi, effettuata attraverso una smart
135
Capitolo 5
Sviluppo dell’applicazione server
card intelligente (CNS Carta Nazionale dei Servizi o CIE Carta di Identità Elettronica)
utilizzabile attraverso l’apposito alloggiamento di cui dispongono tutti i Set Top Box in
commercio. L’utilizzo di questi supporti permetterà all’utente di disporre in qualsiasi
momento del livello di formazione raggiunto.
Il servizio si presta inoltre come punto di partenza per lo sviluppo di ulteriori corsi
o addirittura di una piattaforma di T-Learning Open-Source, magari con la creazione di
contenuti adatti ad essere riproposti in televisione. L’architettura del servizio può essere
sfruttata per permettere l’interfacciamento della Tv Digitale con altri siti Web che
dispongano di una organizzazione di contenuti il più possibile omogenea. Il Gateway
Applicativo sviluppato offre quindi la possibilità di adattare al contesto televisivo anche
altre servizi Web che esulano dall’ambito prettamente Learning.
136
Bibliografia
Bibliografia
[1]
O’Leary, Seamus, Understanding digital terrestrial broadcasting: technology, standards and
regulations, Artech house Publishers, 2000
[2] Wilkipedia, L’enciclopedia multimediale on-line, http://www.wilkipedia.it
[3] Gian Paolo Balboni, Giovanni Venuti, DTT e servizi interattivi: Come e perchè della nuova
televisione, Telecom Italia LAB
[4] DVB(Digital Video Broadcasting), THE STANDARD OF DIGITAL WORLD,
www.dvb.org
[5] Nieto Alessandro, Sviluppo di un servizio di teleprenotazione eventi per TV digitale su
piattaforma DVB-MHP/Relatore: Giuliano Benelli; correlatore: Giovanni Luca Daino
[6]
MHP
Profiles,
Linking
functionality
to
the
MHP
specifications,
http://www.mhp.org/mhp_technology/mhp_profiles
[7] Interactive TV Web, Your source of MHP, OCAP, and JavaTV Information,
www.interactiveweb.org
[8] Studio Taf, Teorie, modelli e sviluppi del mercato, a livello nazionale e internazionale, riguardanti i
processi di e-learning, www.studiotaf.it
[9] Advanced Distribuited Learning, www.adlnet.org
137
Bibliografia
[10] LTSC, Learning Technology Standards Committee, http://ieeeltsc.org
[11] IMS, Global Learning Consortium, http://www.imsglobal.org
[12] AICC, Aviation Industry CBT Committee, http://www.aicc.org
[13] PROMETEUS, “PROMETEUS is a European Partnership for a Common Approach
to the Production of e-learning Technologies and Content”, http://www.prometeus.org
[14] Dublin Core, The Dublin Core Metadata Iniziative, http://dublincore.org
[15] pjb Associates, Personalisation and Personalised TV - in the home and on the move - helping to
create sustainable media-rich information and learning services through communities of interest,
http://www.pjb.co.uk
[16] FAD.UNISI.IT, La piattaforma di apprendimento a distanza dell’Università di Siena,
http://fad.unisi.it
[17] Sparta, Sparta is a lightweight Java XML package that includes an XML parser…,
http://sparta-xml.sourceforge.net/
[18] XPath, The XPath Tutorial, http://www.w3schools.com/xpath/default.asp
[19] JTidy- JTidy Home, http://jtidy.sourceforge.net
[20] MySQL AB : MySQL-Connector/J, http://www.mysql.com/products/connector/j
[21] XSL Tutorial, XSLT & XPath Tutorial, http://www.topxml.com/xsl/tutorials/default
138
Bibliografia
[22] ADB, Advanced Digital Broadcaster, http://www.adbglobal.com/home_page
[23]
RegExLib,
RegExLib.com
Regular
Expression
Cheat
Sheet
(.NET),
http://www.regexlib.com/CheatSheet.htm
[24]
Regular Expression, Regular Expressions and the Java Programming Language,
http://java.sun.com/developer/technicalArticles/releases/1.4regex
[25]Using-BeanInfo, http://www.imsc.res.in/
[26] Jar File Specification, http://java.sun.com/j2se/1.3/docs/guide/jar
[27] Java Programmers Source Book, http://www.codeguru.com/java/tij/tij0102.shtml
[28] Java Servlet Programming, Jason Hunter & William Crawford, O’Reilly
[29] Java 2 SDK Java 1.4, I fondamenti Sesta Edizione, Cay S.Horstmann & Gary Cornell,
McGrawHill
[30] Servlet Tutorial: Session Tracking, http://www.apl.jhu.edu/~hall/java/ServletTutorial/Servlet-Tutorial-Session-Tracking.html
[31] XML Guida completa, Devan Shepherd, Apogeo
[32] XSL Guida completa, Michiel van Otegen, Apogeo
[33] Location Path***12, eXtensible.it XML and beyond, http://www.extensible.it/articoli
[34] HTML.IT XML-DOM Tutorial, http://www.html.it/xml/tutorial
139
Bibliografia
[35] HTML.IT, HTML New Tutorial on-line, http://www.html.it
140

LABORATORIO DI CHIMICA - editore mannarino new

Schema Regolamento UE 165/2014

Scarica la Determina - Croce Rossa Italiana

mn medica n 2 2014 - Ordine dei Medici Chirurghi e Odontoiatri

Superstringa, D-brane e orbifolds di Lucrezia Ravera

14.55: 1a, Pr. Acero (2020 mt, 4400 Eur, reclamare)

06 Fortinet.pptx

FATTURA ELETTRONICA VS PA

CRITICHE: - Ordine degli Avvocati di Milano

Programmazione lato server CGI e introduzione alle