Indice -...

Università Politecnica delle Marche

Indice

1

Indice

Introduzione Capitolo 1. Storia della televisione

1.1 Introduzione 1.1.1 la preistoria 1.1.2 il prototipo 1.1.3 la scansione 1.1.4 la scansione meccanica e quella elettronica 1.1.5 è nata una telecamera 1.1.6 le prime trasmissioni 1.1.7 le prime trasmissioni a colori

1.2 lo scenario italiano dalla nascita al digitale terrestre 1.3 la televisione digitale terrestre 1.4 la situazione in Italia e nel mondo

Capitolo 2. Conoscenze tecniche 2.1 D.T.T. 2.2 la situazione europea 2.3 digitale terrestre in Italia 2.4 DVB – Digital Video Broadcasting 2.5 MHP 2.6 Tecnologie di distribuzione DVB-T 2.6.1 Il playout 2.7 Rete di distribuzione 2.7.1 Rete di diffusione 2.7.2 Hardware delle reti di diffusione 2.8 SFN 2.9 MFN 2.10 k-SFN 2.11 Sistemi di ricezione d’utente 2.12 Architettura MHP 2.12.1Applicazioni 2.12.2 Software di sistema 2.13 Risorse e periferiche 2.13.1 Java TV 2.13.2 Plug-in

5 6 6 7 9 10 12 14 15 16 19 20 21 23 23 24 26 27 29 30 31 31 32 33 34 35 35 35 38 39 40 42


Indice

2

2.14 Profilo 2.14.1 Enchanched Broadcast 2.14.2 Interactive Broadcast 2.14.3 Internet Access Broadcast 2.15 Set Top Box 2.15.1 Architettura, funzionalità hw e firmware 2.15.2 Front-end 2.15.3 Demultiplexer MPEG-2 2.15.4 Video Decoder MPEG-2 2.15.5 Decoder Audio 2.15.6 Sincronismo audio-video 2.15.7 Unità di controllo 2.15.8 Bootloader 2.15.9 Funzionalità grafiche 2.15.10 Interfacce livelli segnale 2.15.11 Software e servizi 2.15.12 Navigatore 2.16 Requisiti minimi 2.17 Telecomando Capitolo 3. Le Xlet, accessibilità, usabilità e sicurezza 3.1 Modello di Business ed interface 3.2 Xlet 3.3 Gestione delle risorse scarse 3.4 Modello grafico 3.4.1 Background layer 3.4.2 Video Layer 3.4.3 Graphics Layer 3.5 Gestione degli eventi del telecomando 3.6 Canale di ritorno 3.7 Protocolli supportati 3.7.1 Livello 1: Fisico 3.7.2 Livello 2: PPP 3.7.3 Protocollo di rete: IP 3.7.4 Protocollo di trasporto: TCP/IP 3.7.5 Hyper Trasfer Protovol: HTTP 3.7.6 Hyper Trasfer Protocol Secure: HTTPS 3.7.7 Servizi Specifici 3.8 Gestione della connessione 3.8.1 Utilizzare il canale di ritorno: org.dvb.net.rc 3.8.2 Interfacce per il canale di ritorno 3.8.3 Acquisire l’interfaccia corretta

43 45 46 47 49 50 51 51 52 52 52 53 52 53 53 54 54 55 55 57 59 61 69 70 75 78 81 83 86 86 87 88 89 89 91 91 91 91 92 93


Indice

3

3.8.4 Stabilire la connessione 3.8.5 I package java.net e java.io

3.9 Accessibilità ed usabilità 3.9.1 Scelte progettuali 3.9.2 Massima semplicità 3.10 Sicurezza 3.10.1 Packet Sniffing 3.10.2 Data spoofing 3.10.3 Denial of serivice 3.11 Criptologia 3.11.1 Teoria dell’informazione 3.11.2 Sicurezza assoluta 3.11.3 Sistemi a chiave non riutilizzabile 3.11.4 Cifratura simmetrica 3.11.5 Cifratura asimmetrica 3.11.5.1 RSA 3.11.5.2 Public Key Infrastructure PKI 3.11.5.3 Certificazione 3.11.5.4 Protocollo TLS 3.12 Sicurezza MHP 3.12.1 MHP specifiche software 3.12.2 Sicurezza MHP 3.12.3 File certificati 3.12.4 Ricezione dell’applicazione 3.13 introduzione smart card 3.13.1 Architettura smart card 3.13.2 Esempio in ambito dvb.tv 3.14 Certificati per il TLS in MHP 3.15 Accesso condizionato 3.16 HTTPS MHP Capitolo 4. ASUR zona 7 4.1 Presentazione dell’azienda 4.2 I servizi online di Asur zona 7 4.3 Servizi sanitari su digitale terrestre attualmente in Italia e nel mondo 4.4 Il STB da sviluppo ADB X-75 dell’Asur zona 7 4.4.1 Caratteristiche tecniche 4.4.2 Pannello frontale 4.4.3 Pannello posteriore 4.4.4 Telecomando 4.4.5 Settaggio connessione di default 4.4.6 STB firmware upgrade

95 98 99 100 102 103 103 103 105 106 107 107 107 108 109 110 110 110 111 114 114 116 118 120 124 124 125 129 129 130 133 133 136 140 141 142 144 145 146 147 148


Indice

4

4.4.7 Upload e debug di un’applicazione 4.4.8 Xlet description file Capitolo 5. Xlet per ambito sanitario locale con servizi interattivi 5.1 Premesse 5.2 Il portale informativo per l’ASUR zona 7 5.2.1 Scelta dei colori 5.2.2 Adattabilità allo schermo televisivo 5.2.3 Guida alla navigazione 5.2.4 Usabilità 5.2.5 Contenuti 5.3 Servizi non in linea 5.4 Servizi in linea 5.4.1 ASUR Reminder 5.4.2 Usabilità 5.4.3 Sicurezza 5.5 Vantaggi e svantaggi 5.6 Sviluppi futuri dei STB 5.7 Sviluppi futuri della xlet Conclusioni e ringraziamenti Appendice A. Appendice B.

Glossario Bibliografia

150 151 153 153 157 158 159 159 159 161 162 166 166 171 172 173 174 175 177 179 224 262 263


Introduzione

5

Introduzione Caro Lettore, in questa tesi trovarai quanto utile per avvicinarsi alla nuova tecnologia del digitale terrestre. Ho voluto innanzitutto avvicinarti alla storia legata alla televisione nel primo capitolo. E’ molto interessante capire come questa si sia evoluta e quali sono i suoi principi di funzionamento. Nel secondo capitolo ti farò conoscere le nozioni tecniche ed apprenderai la terminologia utile ai capitoli successivi. Conoscerai chi l’ha inventata, i suoi vantaggi, come verrà trasmessa, gli standard che regolano la produzione dei decoder, la diffusione attuale. Alla fine della tesi sarai in grado di costruire una xlet per un servizio di prenotazione in ambito sanitario. Si tratta di una sorta di “sito web” accessibile mediante decoder per digitale terrestre basato su tecnologia MHP (Multimedia Home Platform). Questi apparecchi, anche chiamati Set Top Box, sono a tutti gli effetti dei calcolatori elettronici sulla quale gira una Java Virtual Machine in grado di ricevere canali televisivi e interpretare i dati ricevuti. Per questo sarà necessario conoscere la programmazione per MHP, saper gestire il canale di ritorno in maniera sicura, conoscere le smart card (capitolo 3), il contesto sanitario trattato in specifico e saper usare gli strumenti per lo sviluppo di Xlet (capitolo4). Giunti al capitolo 5 avrai le adeguate conoscenze per poter leggere, scrivere e testare una Xlet come quella oggetto di questa tesi; si tratta di una sorta di “super-televideo” nella quale il cittadino potrà reperire informazioni su farmacie, medici e strutture dall’ASUR zona territoriale 7. Nella seconda parte del quinto capitolo verrà descritto il funzionamento di un prodotto innovativo per il digitale terrestre; sono frequenti le persone che desiderano cancellare una visita medica precedentemente richiesta o che se ne dimenticano (soprattutto persone anziane). Oltre a questo in futuro, in possesso di un impegnativa firmata da un medico, ogniuno di noi potrà prenotare una visita specialistica presso le strutture dell’azienda sanitaria locale. Per rispondere a queste esigenze è stata creata una xlet, per ora solo dimostrativa, in grado di gestire prenotazioni, cancellazioni, e per ricordare quali visite si sono prenotate a proprio nome. In appendice troverai il codice di suddette xlet in modo che tu le possa testare su appositi simulatori o su Set Top Box da sviluppo. Buona lettura.


Capitolo 1. Storia della televisione

6


“Non si conosce a fondo una scienza finché non se ne conosce la storia.”

Auguste Comte

1.1 Introduzione

Nella gelida notte di Natale del 1883, rintanato della sua cameretta in un albergo di Berlino, uno studente provava e riprovava a far girare davanti al proprio volto un disco di cartone con dei fori... sembra una favola, ed invece è la storia della televisione. Tutt'altra cosa rispetto all'evoluzione tecnologica propria dei nostri tempi.

La storia della TV appartiene ancora a quel mondo di pionieri che dilapidano i propri soldi in invenzioni assurde, di personaggi geniali che rinunciano a realizzare i loro sogni perché non hanno i ventimila franchi o i marchi che servono a realizzare un prototipo. E' fatta di liti sui brevetti, d’idee avute in contemporanea, copiate e perfezionate. Il teatro è essenzialmente l'Europa del diciottesimo secolo per i principi più remoti e quella dei primi del secolo scorso per i primi risultati concreti. Non manca qualche puntata nei laboratori degli USA, ma non sono così importanti come ciò che è ottenuto in Germania, o In Francia, o in Inghilterra.

1.1.1 LA PREISTORIA

Uno dei padri della chimica moderna, lo svedese Jacob Berzelius riferisce un'osservazione che è l'architrave della tecnologia del “video”:



7

“Vi sono dei materiali (dei metalloidi) che diminuiscono la loro resistenza elettrica se esposti alla luce”. Questi sono il fosforo, il selenio ed il silicio. Berzelius muore verso la metà dell'ottocento e nessuna telecamera onora le sue esequie. Nei decenni successivi l'attenzione a questo fenomeno fu attirata da Christian May, allora giovane telegrafista irlandese. Questi evidenziò che modulando la luce che colpiva del selenio, si poteva modulare una corrente che lo attraversava, grazie alla modifica della resistenza osservata da Berzelius. In altri termini, aumentando o diminuendo l'illuminazione di un elemento di selenio, si otteneva un segnale elettrico “analogico” rispetto alla variazione di luminosità: quando la luce aumentava, lo faceva proporzionalmente anche la corrente (perché diminuiva la resistenza del selenio) e quando la luce diminuiva, anche il segnale elettrico diminuiva di conseguenza.

Un sacco di ricercatori comprese che questa era la strada per la riproduzione delle immagini a distanza e nell'impresa si cimentarono in molti: dal francese Selencq all'americano Carey e perfino il più fortunato in altri campi, il re delle invenzioni Thomas Alva Edison. Il secolo scorso si chiude qui: con chi ha soldi e non riesce a cavare un ragno dal buco, e chi (come probabilmente Selencq) avrebbe la possibilità di tentar qualcosa, ma il quattrino non lo sorregge. In ogni modo i risultati non ci sono.

Al sorgere del nuovo secolo (nel 1909) che il tedesco Ernst Rhumer compie la prima trasmissione televisiva, nel senso che mandò un'immagine ad una certa distanza rispetto al luogo dove si trovava l'originale. Non dobbiamo immaginare che qualche signorina abbia annunciato i programmi della serata, né che qualche politico abbia colto la palla al balzo per far discorsi e neanche che si sia trasmesso qualcosa di particolarmente curioso; come la filastrocca “Mary had a little lamb” (“Maria aveva un agnellino...”) che dicono fu la prima registrazione su disco. Nel nostro caso si trattava semplicemente di alcune figure geometriche sfocate ed approssimative. La televisione era nata.

1.1.2 IL PROTOTIPO

L'estetica è quella delle vecchie macchine ottocentesche. Si tratta di una piastra verticale costellata da molti buchi; non opera di tarlo, bensì dell'umano ingegno. In questi buchi vi è del selenio e da ciascuno di



8

questi buchi esce un filo elettrico. Man mano l'immagine posta davanti alla piastra genera l'illuminazione o l'oscuramento dei singoli buchi, ai capi dei vari fili si va formando evidentemente una “matrice” elettrica che corrisponde (buco per buco) alla luce che cade sulla piastra. Il problema che si poneva era quello di “serializzare” queste informazioni (le correnti presenti al capo di ogni singolo filo), in modo da ottenere una sorta di “onda elettrica”, o un segnale continuo che poteva essere trasportato (ad esempio) su un cavo. Rhumer non si è dato molto da fare in questo campo eppure questo problema era stato affrontato con intuizioni geniali da alcuni predecessori. Ciò sminuisce non poco la sua importanza al punto che il sospetto di molti è che non possa neppure essere considerato il padre della televisione. La caratteristica più inconfondibile della TV è quella di “scomporre” l'immagine e di “ricomporla” sul visore. Rhumer aveva semplicemente collegato ciascun elemento di selenio ad un elemento del visore: se vi erano tanti buchi sulla placca (oggi diremmo “sulla telecamera”), altrettanti elementi attivati dalla corrente ( e con la stessa disposizione) vi erano sulla piastra ricevente (oggi diremmo “lo schermo televisivo”).

Veniamo a quest'ultimo: già allora, l'immagine poteva essere visualizzata in più modi. Si potevano ottenere delle stampe su carta, utilizzando un'alterazione chimica del ferrocianuro di potassio. Si aveva però in questo modo più l'antenato del telefax che della TV. Si poteva anche usare la corrente del segnale video per attivare i rocchetti di Rhumkorff (non sono che lo spinterogeno delle autovetture). Questi dispositivi potevano ottenere dalla corrente continua delle tensioni molto elevate, sufficienti addirittura per far scoccare delle scintille. L'importante era far scoccare queste scintille su una piastra corrispondente a quella della “telecamera”, ossia su una superficie costellata da elettrodi collocati (ad uno ad uno) nella posizione che corrisponde a quella dei buchi con gli elementi di selenio. La qualità del visore era quella che era; non si potevano pretendere certo le oltre mille linee dell'Alta Definizione. Questo inventore accarezzò l'idea di costruire una macchina con una risoluzione di 10.000 pixel; ovvero con 10.000 elementi di selenio. Anche qui difettarono più i soldi che l'entusiasmo dell'inventore e non se ne fece nulla.



9

1.1.3 LA SCANSIONE

Tutta l'attenzione del progresso televisivo si concentra sul sistema che si deve usare per “serializzare” le informazioni presenti nello spazio dello schermo con la figura originaria, da trasmettere a distanza. La struttura della macchina descritta è quella di una trasmissione simultanea di tutti i punti che compongono l'immagine. E' stato già detto che prima di Ruhmer erano stati studiati dei procedimenti per compiere quest’operazione. L'invio di un'immagine linea dopo linea è stata proposta sia dallo scozzese Alexander Bain e dall'inglese Collier Bakewell. Il 1851 è una tappa importante: Bakewell presenta a Londra un prototipo funzionante di apparecchio per la scansione dell'immagine. Non si trattava di una visualizzazione elettronica, ma di una “scrittura” su carta tramite una punta. Anche Bakewell entra comunque di diritto tra i padri della televisione. Si susseguono proposte quasi felici: Constantin Selencq aveva proposto un sistema di ruote dentate, Maurice le Blanc, un sistema di specchi mobili, Edouard Belin (molto modestamente) propone il suo “Bélinografo” e poi via via con i contributi di Paiva, Smith e altri. La svolta si ebbe in una camera d'albergo di Berlino, la vigilia di Natale del 1883. Paul Nipkow inventa ciò che per decenni è considerato l'elemento centrale dell'apparato per la trasmissione delle immagini a distanza: dapprima, il dispositivo fu chiamato “telescopio elettronico”, ma rimase nella storia della tecnologia come il “disco di Nipkow”. Si tratta di qualcosa di veramente elementare, ma che racchiude quella genialità che spesso e volentieri si versa nelle cose più semplici. Ponendo dei fori in posizioni progressivamente più esterne su di un disco opaco, e facendo girare questo disco, si analizzano le immagini riga dopo riga, iniziando dal foro più esterno (che legge la riga superiore) fino a quello più interno che legge quella inferiore. E' da questo momento che si può parlare delle famose “righe” televisive. E' dunque Nipkow il padre della televisione? Non può essere definito tale neppure lui, perché il suo dispositivo era in qualche modo complementare a quello di Rhumer, ma attendeva il demiurgo che avrebbe messo assieme i vari pezzi e costruito finalmente qualcosa che assomigliasse anche da lontano alla nostra TV. Questo “assemblatore” fu un altro scozzese, Logie Baird. A questo punto riprendiamo un po' il filo della nostra storia: dopo la prima guerra mondiale, più precisamente il 2 ottobre 1925, costui invia a distanza un'immagine televisiva vera e propria; formata da 28 linee. Siamo naturalmente ad una data storica; e val la pena di fermarci nuovamente, per descrivere in poche righe qualcosa a proposito di questo sistema. Tanto per aggiungere una curiosità, Nipkow vide questa



10

applicazione del suo disco (inventato quand'era ventitreenne) solo alle soglie dei settant'anni, durante una dimostrazione tenutasi a Berlino.

Fig. 1.1 Brevetto di Paul Nipkow

1.1.4 LA SCANSIONE MECCANICA E QUELLA ELETTRONICA

La televisione di Baird era costituita da un sistema di scansione meccanico. Un disco di Nipkow girava davanti agli elementi sensibili di selenio, e istante dopo istante si otteneva un valore elettrico corrispondente alla luminosità di un punto dell'immagine, riga dopo riga. Il principio è esattamente quello che è usato ancor oggi ma con un sistema di scansione elettronica. Il visore era costituito da un altro disco di Nipkow, che girava davanti ad una lampada al neon comandata dal segnale modulato secondo la luminosità dei punti letti istante dopo istante: in pratica, si comandava la corrente di scarica del neon. I dischi dei due apparecchi (lo “scanner” e il visore) erano naturalmente sincronizzati. Come si passò all'attuale sistema di scansione elettronica? Anche qui, occorre fare di nuovo un passo indietro, perché le invenzioni, in questo periodo, seguivano delle strade quasi parallele e contemporanee. La “televisione elettronica” s’impernia sul tubo catodico, né più né meno di come quella a scansione meccanica vista fin ora, si fonda sul disco di Nipkow.

Un tubo catodico potrebbe essere definito come un'ampolla di vetro dove ad un capo viene generata una nube di elettroni, che vengono “lanciati” con forza verso l'altro capo. Se in corrispondenza di questo capo si mettono dei materiali in grado di divenire luminescenti quando



11

sono colpiti dagli elettroni (classico è il fosforo spalmato sulla superficie interna di questo capo dell'ampolla) ecco che all'arrivo del raggio di elettroni si ha un fenomeno luminoso; che aumenta o diminuisce proporzionalmente alla “forza” del raggio. Se questo raggio si sposta, e colpisce zone diverse della superficie spalmata di fosforo, si avrà un punto luminoso che si sposta con esso. E se lo spostamento è velocissimo, si avrà la sensazione ottica di una strisciata (una riga) luminosa, così come quando muoviamo rapidissimamente (con un gesto brusco) una pila o un oggetto luminoso.

Fig 1.2 Principio di funzionamento del disco di Nipkow. Immaginiamo che l'immagine da scandire sia un buco della serratura. Il disco di Nipkov è in celeste

e porta un certo numero di fori opportunamente distanziati e dislocati dal bordo all'interno. Immaginiamo di far girare il disco in senso orario. Il primo foro passa sull'immagine e legge il

cerchio. Il secondo foro legge il triangolo, il terzo legge lo scuro della porta. Si sono avute così tre "strisciate" dell'immagine, ciascuna con una variazione di luminosità (porta/foro/porta) che codifica l'immagine. Un numero di fori (e quindi, di linee con cui è letta l'immagine) adeguato, permette di

riconoscere i soggetti posti davanti. Notate che serve un disco di grandi dimensioni, per impedire che le righe restino righe e non degli archi.

Se si monta un sensore di luminosità che trasforma le strisce in un segnale elettrico, ecco che questo può essere trasportato a distanza (es. con la diffusione radio) e ricostruito con una lampada che emette luce in maniera proporzionale al segnale elettrico, in altre parole alla luminosità che ha

generato il segnale.



12

Fig. 1.3 L'apparecchio di Baird . Notate il grande disco di Nipkow. Sul lato la lampada che genera l'immagine.

Fig. 1.4 Il disco di Nipkov venne poi abbandonato e sostituito dal cinescopio. Ecco il disegno di un ricevitore televisivo Philips: sopra potete vedere il cinescopio

1.1.5 E' NATA UNA TELECAMERA

Negli ultimi anni del diciottesimo secolo, Ferdinand Braun visualizzò tramite un tubo catodico la corrente alternata. Un suo brillante assistente (che invece fece a tempo a vedere la televisione, essendo vissuto fino agli anni '50 del secolo scorso) applicò degli elettrodi sui



13

fianchi del tubo. Questi permettevano di indirizzare il fascio di elettroni (istante dopo instante) nella direzione voluta. Si chiamava Zennec e può considerarsi dunque il padre del giogo di deflessione usato tutt'ora sui cinescopi televisivi e sulle telecamere a tubo. In questo girotondo di attribuzione di paternità in parte incerte, quella della telecamera va certamente attribuita a Vladimir Zworykin. Il nome dice chiaramente che è di origine orientale ed infatti è di origine russa, ma sviluppò i suoi lavori negli Stati Uniti. Egli pose su un foglietto di mica una grande quantità di elementi sensibili alla luce, e rivestì il lato opposto con uno strato d'argento, in modo da formare una sorta di condensatore. Sulla faccia anteriore del foglietto di mica (un composto molto isolante) mise a fuoco un'immagine, tramite un obiettivo come quelli che ormai erano largamente impiegati nelle macchine fotografiche. Un raggio di elettroni pilotato tramite il sistema di guida di Zennec, permetteva di leggere l'immagine riga dopo riga, e di ottenere così un segnale video. Istante dopo istante, la luce provocava delle cariche diverse sulla superficie di mica e a ciascun punto corrispondeva dunque un certo intervallo di tempo nel segnale video. Questo trasportava un codice in livello proporzionale alla carica che a sua volta era proporzionale alla luce di quel punto. La nascita della telecamera potrebbe essere fissata al 1925. Per rendere l'idea di come sia complessa la storia della televisione è bene dire che l'immagine codificata in questo segnale video non necessariamente era riottenuta elettronicamente. La prima immagine elettronica fu probabilmente prodotta in Russia, a S. Pietroburgo, dal professore universitario Boris Lvovitc nel 1907.

Ancora ai tempi di Zworykin il metodo del professore leningradese non aveva tutta la superiorità che possiamo immaginare sulla tecnica meccanica del disco di Nipkow. In effetti, vi fu una lunga coesistenza tra i due metodi e la validità della scansione meccanica (semplice ma efficace) non vinse alla fine se non di stretta misura e comunque verso la fine degli anni '30. La vittoria del tubo elettronico stentava proprio perché la sua costruzione e pilotaggio erano molto più macchinosi, per l'epoca; tuttavia permetteva un'immagine con un maggior numero di linee e quest’aspetto fu alla fine quello che prevalse e gli diede la possibilità di vincere sulla televisione meccanica. La scansione meccanica tipica di un disco era di 180 linee per immagine e venticinque immagini al secondo. La scansione elettronica permetteva di raddoppiare il numero delle righe (375) e di mantenere la stessa cadenza delle immagini. Notate che ancor oggi un semiquadro del sistema PAL (una “passata” sullo schermo televisivo) è costituito da meno di 300 linee effettive. Ci viene riferito tuttavia che



14

complessivamente l'immagine elettronica era molto scadente e non stentiamo a crederlo. In poco tempo tuttavia questa prese il sopravvento, grazie all'introduzione di un numero ancora maggiore di linee di scansione (si arriva a 441) e alla tecnica dell'interallacciamento, che permette (a parità di numero di immagini al secondo) di ottenere dei risultati che sarebbero tipici di un numero di immagini al secondo maggiore. L'interallacciamento consiste nel disegno di tutte le righe dispari, e poi di tutte le righe pari che occupano gli spazi tra una riga dispari e l'altra. In questo modo il raggio “rinfresca” più frequentemente la stessa area di cinescopio, e si ha un'immagine sensibilmente più stabile.

Fig. 1.5 scansione meccanica con 30, 48 e 150 linee

1.1.6 LE PRIME TRASMISSIONI

Una tappa fondamentale per l'affermazione della telecamera di Zworykin fu la trasmissione in diretta dei giochi di Berlino nel 1936. Al collezionista di curiosità non deve mancare l'osservazione che uno degli operatori di questa telecamera (costruita dalla Telefunken) era un giovanotto appassionato di tecnologia: il signor Walter Bruch, considerato (questa volta senza dubbio) il padre del sistema televisivo a colori PAL. Il 1936 segna un po' il trionfo delle trasmissioni operative. Si era in grado di soddisfare i poveri (e ricchi) utenti disposti a ricevere un programma che non fosse un puro e semplice esperimento di trasmissione. Oltre alla trasmissione tedesca dei giochi di Berlino è da segnalare che nel '36 la BBC trasmise l'incoronazione di Giorgio VI con telecamera Emitron. L'anno successivo una telecamera posta sul tetto del padiglione tedesco alla esposizione universale di Parigi, mostrava agli stupefatti francesi una veduta dall'alto della loro capitale. Nel 1939 Roosvelt inaugura la fiera mondiale di New York e RCA riprende l'evento, trasmettendolo via radio. La trasmissione via radio delle immagini era naturalmente già possibile; la radio audio era già relativamente evoluta e le trasmissioni video potevano essere



15

considerate una specie di “iperradio" che occupava molte più frequenze. La banda impiegata non era così impacchettata accuratamente come oggi, ma d'altra parte la qualità modesta del video d'allora richiedeva anche meno spazio di quello necessario oggi. E' curioso notare che le prime trasmissioni regolari furono fatte con scansioni meccaniche (come già detto, costituivano allora un'alternativa del tutto valida) anche se la programmazione non era certo paragonabile a quella di oggi. Presso gli Champs Elisées è ancora visibile un pilone di 70 metri per la diffusione dei primi programmi francesi regolari. C’era una trasmissione due volte al mese. Chi si dispiace delle attuali 625 linee del PAL, s'immagini cosa vedevano i primi telespettatori davanti ad uno schermo con 30 righe di scansione. Il periodo prebellico si chiude con i seguenti standard: le trasmissioni vanno adottando la scansione elettronica, anche se con una risoluzione diversa. L'Inghilterra usa 405 linee, la Francia 450 (dal 1939), gli USA 441.

1.1.7 LA TRASMISSIONE A COLORI

Durante la seconda guerra mondiale, la gente a quanto pare ha altro da fare che pensare alla TV: Ed infatti, di trasmissioni non se ne parla neanche. Al termine del conflitto, rinasce un grandissimo intesse per la televisione ed ecco un rifiorire di piccoli o grandi miglioramenti che portano (all'inizio degli anni '50) a riassestare gli standard su dei valori che sono ancora parte dei giorni nostri. Le telecamere nel ‘50 adottano il tubo “vidicon”, molto più robusto e moderno dell'ormai vecchio sensore di Zworikin, con le sue miche e tutto il resto. Si tratta di un tubo da ripresa che (a livello amatoriale) è sopravvissuto fino a questi anni, fino a quando cioè l'adozione generalizzata dei CCD ha cambiato radicalmente la struttura dei sensori d'immagine. Prima di imboccare queste vie che sembrano destinata a rimangiarsi tutti i progressi fatti dai tubi da ripresa, ripartendo (se così si può dire) dai progenitori, questi stessi tubi avevano fatto comunque dei passi da gigante, e nell'arco di pochi anni. Si era passati in breve dai “vidicon “ agli “orthicon", da questi ai “super-orthicon”. Un passo sostanziale fu il passaggio ai “plumbicon”, considerati da qualcuno ancor oggi tra i migliori. Non mancarono altri miglioramenti, sentiti anche dagli appassionati che non si accontentavano dei “vidicon”: nacquero i tubi speciali, come i "saticon”, “newicon”, eccetera eccetera. Col tempo, e col progresso delle tecnologie elettroniche (ma anche con la progressiva riduzione delle dimensioni dei componenti, grazie ai transistor), fu possibile



16

ipotizzare e realizzare una trasmissione di immagini a colori, effettuando analisi e suddivisioni dell'immagine scandita secondo le componenti dei colori fondamentali (rosso, blu e verde), da riprodurre in tutta analogia su schermi i cui fosfori erano divisi ciascuno in 3 fosfori più piccoli, uno rosso, uno blu ed uno verde.

1.2 LO SCENARIO ITALIANO DALLA NASCITA AL DIGITALE TERRESTRE

• 1941: 1 luglio: la NBC americana trasmette il primo spot pubblicitario televisivo (riguarda un orologio)

• 1947: i delegati di 60 paesi presenti alla Conferenza mondiale delle radiocomunicazioni di Atlantic City decidono di chiamare "televisione" (in sigla "TV") la trasmissione a distanza delle immagini in movimento.

• 1954: il 3 gennaio alle ore 11.00 ha inizio il servizio televisivo italiano sul Programma nazionale.

• 1956: le VII Olimpiadi invernali di Cortina d'Ampezzo sono le prime ad essere trasmesse in mondovisione. Quattro anni dopo toccherà alle Olimpiadi di Roma.

• 1957: in Italia nasce la rubrica pubblicitaria Carosello. • 1960: la tv si diffonde molto rapidamente: in quell'anno è diffusa

in cinquantasei paesi (un decennio più tardi, nel 1970 saranno pressoché raddoppiati: ben 104).

• 1961: il 4 novembre cominciano le trasmissioni del Secondo Programma.

• 1964: in California nasce la prima pay-tv. Nello stesso anno, la XVIII Olimpiade di Tokyo è il primo evento televisivo trasmesso da un satellite.

• 1966: Nasce Telediffusione Italiana Telenapoli, la prima televisione libera italiana via cavo.

• 1969: tra il 20 e il 21 luglio l'uomo sbarca sulla Luna: 28 ore consecutive di diretta televisiva via satellite vengono seguite in mondovisione da più di 500 milioni di persone.

• 1971: Telediffusione Italiana Telenapoli introduce in Italia il colore nella TV via cavo, con 6 anni d'anticipo rispetto alla RAI.



17

In Italia inizia a trasmettere la televisione privata “Telebiella” che è di fatto riconosciuta come la prima emittente libera italiana.

• 1974: Il 10 luglio La sentenza n. 225 della corte costituzionale e la sentenza n. 226 legittimano di fatto la televisione via cavo e la ripetizione in Italia delle televisioni estere in lingua italiana. Contemporaneamente le due sentenze stabiliscono le condizioni minime per considerare il monopolio radiotelevisivo pubblico per le trasmissioni via etere in ambito nazionale conforme ai principi costituzionali;

• Nel contempo nascono le prime televisioni libere italiane via etere (verranno legittimate 2 anni dopo): Canale 21 (Napoli), Telemilanese (Busto Arsizio), GBR (Roma).

• 1975: il 14 aprile 1975 la legge 103/75,(la c.d "Legge di riforma" segna un cambiamento epocale nella storia della televisione; la tv di Stato passa dal controllo del Governo a quello del Parlamento: nasce ufficialmente la lottizzazione; si progetta la costruzione di una terza rete pubblica.

• 1976: con la sentenza n. 202 del 28 luglio si arriva al superamento della legge di riforma della Rai del 1975 e la legittimazione delle emittenti private via etere in ambito locale. Il 31 dicembre va in onda l'ultima puntata di Carosello. Termina dopo vent'anni quindi, la seguitissima trasmissione pubblicitaria di prima serata che tanto successo aveva riscosso sia nella fascia adulta che tra i più piccoli teleutenti. Nasce nel quartiere di Milano 2 (Segrate) l'emittente Telemilanocavo, fondata da Giacomo Properzj e Alceo Moretti. Due anni dopo l'emittente sarà comprata da Silvio Berlusconi.

• 1977: la RAI introduce nella tv italiana via etere il colore, già presente da tempo in altri paesi (le prime videocamere a colori, negli Stati Uniti, erano già in circolazione sperimentale durante la seconda guerra mondiale). A Legnano il 3 Novembre comincia le trasmissioni Antenna3, emittente di proprietà di Renzo Villa e Enzo Tortora.

• 1979: il 15 dicembre iniziano le trasmissioni di Raitre. • 1980: TeleMilano, viene trasformata in capofila del network

nazionale Canale 5. Il circuito PIN - Primarete Indipendente del



18

gruppo Rizzoli dà vita al primo telegiornale nazionale privato: Contatto, diretto da Maurizio Costanzo.

• 1985: iniziano i primi esperimenti di TV ad alta definizione: vengono realizzati alcuni videoclip e documentari, ma l'idea non trova ancora realizzazione pratica perché la tecnologia ancora non è diffusa commercialmente su larga scala.

• 1994: il formato tv passa dai 4/3 (rapporto fra larghezza e altezza) ai 16/9, avvicinandosi ai formati panoramici utilizzati solitamente nel cinema.

• 1997: compare sul mercato il primo televisore al plasma. • 2000: la tecnologia LCD (Liquid Crystal Display), nata per i

monitor dei personal computer, viene adottata anche nella costruzione degli apparecchi televisivi.

• 2003: il 1 dicembre il network televisivo Mediaset comincia le trasmissioni digitali terrestri.

• 2004: il 3 gennaio, cinquant'anni dopo la nascita della televisione italiana, la RAI inizia a sua volta il servizio di trasmissione digitale terrestre; il 6 febbraio nasce Sportitalia, un canale televisivo gratuito interamente dedicato allo sport.

• 2005: la RAI inizia a Torino la sperimentazione della TV Mobile, basata sullo standard DVB-H da poco pubblicato.

• 2005: Mediaset e LA7 lanciano un nuovo servizio sul digitale terrestre: la pay-per-view di vari eventi (partite di serie A, film, concerti...).

• 2006: L'emittente satellitare SKY Italia inizia a trasmettere eventi in Alta Definizione su quattro canali tematici. Veicolo per fare conoscere la nuova tecnologia sono proprio le partite dei mondiali di calcio.

• 2007: Domenico Ranieri crea la una applicazione per digitale terrestre che permetterà di accorciare i tempi di attesa per una visita medica presso l’Asur zona 7 ;)



19

1.3 LA TELEVISIONE DIGITALE TERRESTRE

Con il sistema analogico riceviamo un segnale trasmesso attraverso l’etere da un trasmettitore che raggiunge l'antenna sul tetto. Quest'onda elettromagnetica rappresenta più o meno fedelmente l'onda elettrica in uscita dalla telecamera che riprende la scena trasmessa, la quale viene riprodotta sullo schermo televisivo secondo la tecnica propria dell'apparecchio (che può essere del tipo a tubo catodico (CRT), a cristalli liquidi (LCD) oppure "al plasma"). Con il sistema digitale, invece, si trasmette sempre un'onda elettromagnetica che però non è copia dell'onda elettrica generata dalla telecamera ma un flusso di bit, un flusso di dati binari, cioè in grado di assumere soltanto due valori. La trasformazione dell'onda elettrica in uscita dalla telecamera in flusso di dati digitali da trasmettere attraverso un'onda elettromagnetica è fatta dai circuiti di conversione analogico/digitale (A/D) che si trovano oggi direttamente dentro le telecamere, garantendo così un segnale digitale sin dai primi circuiti da attraversare. Nel flusso dei dati trasmessi, oltre alle immagini in movimento e ai suoni, possono essere incorporati dati che rappresentano qualcos'altro: lettere, programmi software, immagini fisse, comandi, più o meno come accade da tempo con il Televideo. In particolare, il sistema digitale terrestre approvato in Italia prevede l'uso della trasmissione dei dati aggiuntivi per la distribuzione di programmi software scritti secondo lo standard Multimedia Home Platform. Attraverso l'interprete dei dati MHP incorporato in molti ricevitori è possibile usufruire dei servizi offerti dalle applicazioni. Il ricevitore occorrente per usufruire del servizio è detto "decoder" (o set top box) ed è composto da una parte sintonizzatrice identica a quella in uso con la televisione analogica, ma anche di una sezione che converte il segnale digitale ricevuto dai circuiti di sintonia in segnale analogico da inviare al televisore, oltre ad altre circuitazioni come quella che gestisce le carte di accesso condizionato necessarie per la visione dei programmi a pagamento.



20

1.4 LA SITUAZIONE IN ITALIA E NEL MONDO

La trasmissione di tv digitale terrestre è stata pianificata in molti Paesi al fine di sostituire l'esistente tecnica di trasmissione analogica con quella digitale. La seguente tabella mostra il lancio del DTT in diversi Paesi:

Tab. 1.1 La situazione nel mondo


Capitolo 2. Conoscenze Tecniche

21

Capitolo 2. Conoscenze tecniche

“Tutti gli uomini per natura desiderano la conoscenza”

Aristotele

2.1 D.T.T. La D.T.T. ( "Digital Terrestrial Television" ) e' una realtà che si sta consolidando in questo momento, spinta da forti pressioni politiche e dai media stessi; Innovazione optional per i telespettatori di oggi, ma anche una scelta obbligata, visto e considerato che, entro il 2012, dovranno terminare le trasmissioni VHF e UHF analogiche. I vantaggi immediati saranno molteplici, uno su tutti la possibilità di moltiplicare il numero di canali trasmissibili attraverso le stesse frequenze oggi utilizzate dalla Tv analogica. Ogni singola frequenza utilizzata in analogico, infatti, permette di trasmettere un solo canale televisivo. Sarà dunque possibile trasmettere audio, video e dati insieme, attraverso una codifica numerica delle informazioni. Si potrà così moltiplicare fino a cinque il numero di canali trasmessi contemporaneamente su una sola frequenza. Ciò significa che con gli stessi televisori e le stesse antenne di oggi, oltre all'adattatore digitale si vedrà una cinquantina di canali anziché i dodici attuali. La moltiplicazione dei canali televisivi non è l’unico vantaggio. Vale la pena di evidenziare tra gli altri, la migliore qualità delle immagini (trattasi di segnale numerico che non risente d’interferenze né di riduzione del segnale né di disturbi), la possibilità di vedere film nel formato 16:9 anziché nel 4:3 tradizionale, la fruizione di servizi interattivi sempre più sofisticati, permettendo ai canali Tv e alle trasmissioni televisivi di inserire contenuti multimediali innovativi. Il



22

passaggio dalla Tv analogica alla Tv digitale coinvolgerà progressivamente oltre 50 milioni di apparecchi televisivi, praticamente tutta la popolazione italiana. Per la ricezione dei programmi TV digitali, gli utenti dovranno possedere un apposito ricevitore (Set-Top-Box) da collegare al proprio televisore. I ricevitori per il DVB-T affiancheranno presto i televisori nelle case dei cittadini italiani, come avviene per quelli DVB-S per la TV da Satellite; è dunque plausibile cercare di orientare una fetta della ricerca nella direzione dello sviluppo di questa tecnologia, per poter fornire prestazioni e servizi sempre migliori, muovendosi parallelamente a quelle che sono le richieste del mercato. Molteplici sono le applicazioni che si può immaginare di realizzare avendo a disposizione una cosiddetta “TV interattiva”, una serie di strumenti utili al cittadino per le operazioni più consuete (operazioni bancarie, prenotazione esami clinici, espletamento di pratiche burocratiche, teletex avanzato, connessione ad internet, …). Una consistente fonte di business potrebbe trovarsi in quelle applicazioni che suscitano l’interesse del telespettatore medio, come il televoto, la partecipazione diretta a quiz attraverso il telecomando, concorsi a premi, pubblicità interattiva. Oggi non si è ancora in grado di prevedere con esattezza dove porterà l’introduzione di queste nuove tecnologie, ma è indubbia la convergenza tra la televisione, l’informatica e le telecomunicazioni. Al contempo, il coinvolgimento dei cittadini nella Società dell’Informazione, incontra una barriera nella limitata diffusione del PC rispetto alla totalità della popolazione, determinando la potenziale esclusione di una larga fascia di essa. L’idea di base resta quella di rendere l’apparecchio televisivo uno strumento efficace e comodo per sviluppare servizi interattivi, che si aggiungono alla tradizionale funzione di fruizione dei programmi televisivi (mantenendo, in Italia come in Europa, l’altissimo tasso di penetrazione della televisione analogica). Sebbene sia immediato sottolineare i vantaggi dell’innovazione tecnologica – nascita di nuovi servizi, opportunità di crescita del settore audiovisivo, rafforzamento del grado del pluralismo informativo – non è da trascurare l’esistenza di talune difficoltà legate al periodo di transizione. La sfida principale è quella della ricezione da parte degli utenti, la cui riuscita è il presupposto per la fine delle trasmissioni analogiche. La maggior parte delle famiglie, infatti, al momento dello switch-off dovrà essere dotata dei decodificatori digitali, per il rischio che il processo tecnologico finisca per creare nuove fratture sociali.



23

2.2 La situazione Europea La Commissione europea, che ha già emanato due recenti comunicazioni in tema di digitale terrestre – una sul periodo di transizione dall’analogico al digitale e una sulle barriere che ancora si frappongono all’accesso alle piattaforme a larga banda – ha manifestato l’intenzione di monitorare questo processo, per assicurare che gli interventi di sostegno che gli Stati porranno in essere siano conformi ai principi comunitari di libera concorrenza. Per raggiungere questo obiettivo ha invitato tutti gli Stati membri a rendere note le proprie strategie, con l’obiettivo di stimolare il più possibile la transizione rapida ai sistemi di radiodiffusione in tecnica digitale, cercando di minimizzare gli svantaggi del breve periodo legati alla necessità di operare una modernizzazione tecnica a tutti i livelli. Il digitale lanciato in Europa inizialmente da poche nazioni come Gran Bretagna, Svezia, Finlandia, e Spagna non ha avuto gran successo, infatti il massimo di telespettatori realizzato dalle tv era intorno ai 200.000 utenti; il sistema ha compreso che il servizio offerto deve essere gratuito (infatti, in Inghilterra e' ricevuto oggi da un numero d'utenti intorno ai 2 milioni); successivamente il resto delle nazioni Europee si è lanciato in questo progetto.

2.3 Digitale terrestre in Italia Per quanto riguarda le date previste per lo switch-off, l’Italia è stata il primo Paese a porsi come obiettivo (legge n. 66 del 2001) il completamento del passaggio al digitale entro il 31 dicembre 2012. Il processo di trasformazione viene accelerato e favorito anche attraverso la definizione di una disciplina transitoria che stabilisce le tappe intermedie per lo sviluppo della nuova tecnologia ed agevola la diffusione presso le famiglie italiane dei nuovi apparati di ricezione; norme miranti a realizzare una transizione in tempi rapidi, preferibilmente senza penalizzare l’utenza. Sono inoltre previsti, già all’atto di approvazione della legge: una fase di avvio della nuova tecnica trasmissiva con la coesistenza del sistema analogico e del sistema digitale; una temporizzazione precisa, a partire dal 1° gennaio 2004, degli obblighi di copertura dei multiplex affidati alla concessionaria del servizio pubblico radiotelevisivo. L’obbligo per tutti gli altri operatori che intendono ottenere la licenza di operatore di rete di raggiungere una copertura non inferiore al 50 per cento della popolazione o del bacino locale; Il primo approccio al digitale terrestre in Italia è stato caratterizzato da una notevole spinta da



24

parte delle principali emittenti, che sin dai primi mesi del 2004 hanno investito numerose risorse; esemplificativo può essere lo schema di seguito riportato. L'Italia sarà, assieme alla Finlandia, il primo paese a fare lo switch-off definitivo (2012), mentre l'ultimo sarà la Francia nel 2015, ammesso che le iniziative intraprese rispettino i termini fissati (infatti non è una data troppo realistica, ma perlomeno serve a tracciare una strada per la sperimentazione). Positivo sarà l’impatto derivante all’economia dalla messa in moto di un importante processo di investimenti da parte degli operatori del settore e di spesa da parte degli utenti. Si tratta di un processo che non investe solo l’Italia ma anche la maggior parte dei Paesi dell’Unione europea. Oggi non si può ancora apprezzare la trasmissione digitale terrestre al cento per cento. Il vantaggio che può apportare al momento è una visione più nitida delle immagini, in qualità DVD in pratica. L’introduzione della televisione digitale terrestre gioca un ruolo di primo piano perché questa tecnologia rientra tra quelle che realizzano l’accesso multipiattaforma a larga banda ed ampliano le possibilità di scelta dei cittadini; si tratta, insomma, di un salto tecnologico di valore esponenziale. Il dato che è emerso dalla recente Conferenza Ministeriale Europea, dove si sono confrontate le esperienze in atto nei vari Paesi, è che ci si stia trovando di fronte ad una semplice trasformazione tecnologica, ma che riveste implicazioni di carattere sociale, economico e culturale.

2.4 DVB – Digital Video Broadcasting La Direttiva europea del 95/47/CE del Parlamento Europeo, del 24 ottobre 1995, relativa all’impiego di norme per l’emissione di segnali televisivi, stabilisce, riassumendo brevemente, che «Tutti i servizi televisivi trasmessi ad utenti della Comunità Europea via cavo, satellite ed etere, devono, nel caso di trasmissioni digitali, utilizzare un sistema di trasmissione standardizzato da un ente europeo di standardizzazione riconosciuto». All'origine delle attività europee per lo sviluppo delle tecnologie di trasmissione digitale è nato quindi il progetto Digital Video Broadcasting (DVB), una vera e propria commissione per lo sviluppo delle piattaforme digitali, promosso dalla Commissione Europea proprio con lo scopo di definire una serie di standard comuni. Al progetto partecipano oltre 300 società di 35 paesi, esse sono direttamente coinvolte nei diversi settori dell'industria televisiva: la



25

trasmissione, la produzione dell'hardware, lo sviluppo del software, la gestione delle reti, la produzione dei contenuti. Il progetto DVB ha lo scopo di stabilire un unico standard condivisibile su scala europea per le trasmissioni televisive digitali via satellite (DVB-S), via cavo (DVB-C) e via terra (DVB-T); fino ad ora l’operato del consorzio DVB è stato encomiabile (basti pensare che gli standard sono stati recentemente adottati anche dal Giappone e da altri paesi non europei). L’ETSI, l’ente di standardizzazione europeo, ha pubblicato un set di standard derivati dalle specifiche del progetto DVB. Di conseguenza tutti i servizi digitali televisivi in Europa sono conformi a tali standard DVB dell’ETSI. La Direttiva stabilisce anche che «In questo contesto, un sistema di trasmissione comprende i seguenti elementi: formattazione dei programmi (codifica di sorgente dei segnali audio e video, multiplazione dei segnali) ed adattamento ai mezzi trasmissivi (codifica di canale, modulazione e tecniche di dispersione dell’energia) ». La Direttiva esclude quindi, dal suo ambito di applicabilità, i rimanenti elementi (gestione di applicazioni, accesso condizionato, sicurezza); l’assenza di tali specifiche ha fatto sì che nella maggioranza dei Paesi Europei la televisione digitale è stata lanciata da operatori di televisioni a pagamento che hanno utilizzato differenti standard proprietari per creare mercati verticali. La loro motivazione si è fondata sul fatto che la mancanza di interoperabilità apportasse un vantaggio competitivo, legando gli utenti ad una specifica piattaforma. Il regolatore europeo è stato generalmente riluttante a intervenire su tale problema, al fine di non scoraggiare gli investimenti nascenti nel settore con vincoli troppo stringenti. Come conseguenza sono state sviluppate molteplici interfacce software dette API (Application Programming Interface), tutte incompatibili tra loro. In particolare, i programmi multimediali e interattivi non possono essere eseguiti su ogni piattaforma, ma vanno sviluppati con riferimento ad una particolare specifica di API. Aspetti tecnologici che concorrono nella piattaforma digitale In generale si può dire che ogni applicazione multimediale o interattiva utilizzerà le funzionalità disponibili nel decoder. L’esistenza di varie norme rende problematica la ricevibilità dei programmi diffusi dalle varie emittenti con un qualsiasi STB. Per la gestione delle applicazioni, ad esempio, esistono la norma ISO-MHEG5 già in esercizio commerciale nel Regno Unito e – successiva in ordine di tempo - la norma ETSI/MHP, più flessibile della prima, in gran parte consolidata e recentemente entrata definitivamente in esercizio in molti Paesi Europei, ponendo probabilmente le basi per la soluzione del problema sopra citato.



26

2.5 MHP Il gruppo di progetto DVB lavora sin dal 1997 alle specifiche relative ad uno standard aperto, per la gestione della multimedialità e dell’interattività: il DVB-MHP (Digital Video Broadcasting – Multimedia Home Platform). Nasce un nuovo gruppo di lavoro con l’incarico di redigere una lista dettagliata di requisiti che il nuovo standard dovrà soddisfare. Entrano a far parte di questo gruppo numerose aziende del settore, tra le quali la Sun Microsystems®, che contribuirà allo sviluppo di una piattaforma basata su Java™.

Figura 2.1. - Aspetti tecnologici che concorrono nella piattaforma digitale

Questo standard è aperto all’utilizzo di ogni soggetto interessato, anche non membro del DVB, permettendo a gruppi diversi di interoperare, rispettando le specifiche minime della piattaforma; gli apparati di ricezione diventano intercambiabili tra loro e i gestori delle reti possono utilizzare servizi diversi verso apparati diversi. I principali benefici della specifica MHP (come per qualunque standard pubblicato) sono:

• Standard aperto, orientato a garantire la piena interoperabilità tra qualsiasi programma irradiato e qualsiasi tipo di ricevitore a casa dell’utente (fatta salva la distinzione tra profili);

• Costi più economici per le licenze di utilizzo della piattaforma, rispetto all’utilizzo di piattaforme proprietarie;

• Possibilità di scegliere tra molti più fornitori, che non nel caso di soluzioni proprietarie.



27

Poiché si prevede che a lungo termine lo standard DVB-MHP sarà probabilmente adottato quasi universalmente; la sua introduzione destrutturerà il modello di mercato verticale o proprietario delle piattaforme software esistenti degli attuali service providers. Tuttavia, nel breve-medio termine, l’affermazione della piattaforma MHP potrà incontrare vari problemi di affermazione. Lo standard presenta anche alcune lacune, tra queste quella di non coprire pienamente l’aspetto dell’accesso condizionato per il quale, poiché si entra nel campo della Pay Tv, esistono molti standard proprietari e non si può sperare in nulla di più che nella presenza di STB con Common Interface, cioè con un ingresso (slot) in grado di ospitare schede del tipo PCMCIA per il supporto di vari standard di crittazione del segnale televisivo. In questo modo, l’utente può con lo stesso apparecchio, cambiando solo la scheda PCMCIA, ricevere canali crittati secondo vari standard.

2.6 Tecnologie di distribuzione DVB-T Una volta realizzata l’applicazione MHP deve essere distribuita ai terminali; lo standard adempie alla descrizione di questo processo in modo esaustivo. Lo standard prevede tecniche differenti, tra le quali si possono citare connessioni punto-punto tra terminale e fornitore del servizio oppure installazione remota del software sul terminale (non trattate in questa sezione). La metodologia di distribuzione broadcast più diffusa tra quelle previste dallo standard prevede l’utilizzo del protocollo DSM-CC Object Carousel (Digital Storage Media - Command and Control) che consente di rendere completamente trasparente il software al sistema di trasmissione: all’interno del terminale viene ricostruita localmente la struttura dati dell’applicazione, senza introdurre complessità correlate con il canale di trasmissione.

Fig. 2.2 - Protocolli supportati per il canale broadcast



28

Il DSM-CC è un’estensione dell’MPEG, il cui scopo è trasmettere dati ai ricevitori; essenzialmente include due differenti metodi di broadcasting, l’MHP ne utilizza solo una piccola parte, in particolare il metodo Object Carousel (in modo limitato). In particolare, i dati sono strutturati all’interno di un “file system”, messo in onda nella forma di “carousel”: un Object Carousel è una struttura ad albero che è divisa in una serie di moduli; ciascun modulo può contener diversi file, raggiungendo una capacità massima di 64 Kbytes; file più grandi di 64 Kbytes devono essere impacchettati in moduli che conterranno solo tali file. I moduli vengono quindi trasmessi sequenzialmente e ciclicamente, il ricevitore potrà accedere ad ogni file quando avrà ricevuto tutti i moduli in cui è contenuto, potrà altresì visualizzare l’applicazione quando avrà ricevuto tutti i file necessari. Questa tecnica non è efficiente quando la dimensione totale dei dati trasmessi è elevata. La trasmissione dei dati, ripetuta ciclicamente, ha un periodo di ripetizione pari al quoziente della quantità totale in byte di dati da trasmettere divisa per la velocità di trasmissione disponibile. In assenza di accorgimenti correttivi, che nello standard MHP non sono specificati, la durata del periodo di ripetizione viene percepita dall’utente come una latenza di accesso alle varie funzionalità del servizio. Tali servizi possono avere la necessità di memorizzare alcuni parametri di configurazione, nonché eventuali dati concernenti le preferenze dell’utente, in modo persistente rispetto allo spegnimento del terminale (al fine di evitare continue e fastidiose richieste all’utente di inserire dati personali e/o di configurazione, e per consentire una progressiva personalizzazione dell’interfaccia utente e del formato di presentazione). La televisione digitale terrestre prevede la trasmissione usando segnali elettromagnetici con frequenze comprese tra 30MHz e 3GHz usando come mezzo trasmissivo l'aria. Al DVB-T sono stati assegnate le bande III della gamma VHF e le bande IV e V della gamma VHF. Si utilizzano canali di 8 MHz (opzionali 6 e 7) con diverso segnale portante, tipo di modulazione e schema di codifica che può essere QPSK (Quadrate Phased Shift Key), QAM (Quadrate Amplitude Modulation) e 64 QAM. Il multiplexing viene fatto con COFDM (Coded Orthogonal Frequency Division Multiplexing). Per analizzare in maggior dettaglio i diversi sistemi di trasmissione digitale terrestre introduciamo un modello di architettura di rete. Le componenti e le funzioni del modello rappresentato sono i seguenti:

• Il playout, la cui funzione è di codificare ed assemblare programmi, dati e informazioni, creando il transport-stream (flusso digitale per il trasporto);



29

• La rete di distribuzione, che trasferisce il transport-stream all'ingresso dei trasmettitori della rete di diffusione;

• La rete di diffusione, che irradia verso gli utenti il segnale costituito dal transport-stream;

• Il sistema ricevente di utente, costituito dall'impianto di antenna ricevente individuale o condominiale;

Fig. 2.3. - Modello di architettura di una rete DVB-T

2.6.1 Il Playout Nel centro playout i programmi televisivi sono codificati nello standard MPEG-2 e assemblati dal multiplex insieme con altri dati e informazioni. Il transport-stream in uscita dal multiplex viene inviato al SFN adapter (quando necessario) che crea la struttura di Mega Frame e inserisce il MIP (Mega Frame Initialization Packet). Il network adapter ha la funzione di interfacciare la rete di distribuzione che alimenta i trasmettitori della rete di diffusione. L'SFN adapter è usato solo quando la rete è del tipo SFN, in quanto non necessario nel caso in cui tale rete sia del tipo MFN; la sua funzione è di inserire i segnali GPS (Global Position System), ricevuti attraverso un opportuno ricevitore, per la sincronizzazione del transport-stream necessaria per il funzionamento delle reti SFN. Si evidenzia che il playout è sostanzialmente lo stesso sia quando le reti di diffusione utilizzate siano del tipo SFN che del tipo MFN (nel secondo caso manca il modulo SFN adapter).



30

Fig.2.4 - Schema generale del Playout

2.7 Rete di distribuzione La rete di distribuzione ha la funzione di trasferire il segnale in uscita dal playout ai trasmettitori delle reti di diffusione. Le reti di distribuzione possono essere realizzate attraverso ponti radio terrestri, fibre ottiche o satelliti. Le reti di distribuzione attualmente utilizzate in Italia per la televisione analogica sfruttano prevalentemente ponti radio terrestri. Per il trasporto del segnale digitale è necessario che esse siano convertite alla nuova tecnologia. Questo tipo di rete si adatta facilmente alla distribuzione sia di programmi nazionali sia di programmi locali. La realizzazione di reti in fibra ottica presenta in generale difficoltà per quanto riguarda la distribuzione dei segnali televisivi. Tale difficoltà risulta evidente data la difficile collocazione geografica dei trasmettitori. Ciò comporta una struttura di rete ad albero, costituita da una dorsale e tante ramificazioni quanti sono i trasmettitori della rete di diffusione da alimentare. Le reti di distribuzione non devono introdurre ritardi nel trasporto del segnale digitale superiori a 1 secondo, affinché possano essere compensati all'SFN-sync.



31

2.7.1 Rete di diffusione La tecnologia digitale consente di pianificare reti utilizzabili per lo sviluppo di reti nazionali e locali di tre tipi:

Tab. 2.1 - Reti di diffusione a confronto

2.7.2 Hardware delle reti di diffusione Per quanto riguarda l'hardware delle reti di diffusione, si possono grossolanamente distinguere i seguenti tipi di impianti: trasmettitore, ripetitore, gap filler Da segnalare anche che i vari tipi di reti possono essere progettate per servizi rivolti prevalentemente all'utenza fissa o all'utenza mobile. Nel primo caso è più adatta la modalità di modulazione OFDM4 a 2000 portanti, nel secondo caso è da preferire la modalità a 8000 portanti.

Tab. 2.2 - Impianti di base delle reti di diffusione



32

2.8 SFN Le reti SFN, si usano quando si devono irradiare gli stessi programmi e servizi in una stessa area, cioè quando non è richiesto né l’inserimento nel transport-stream di nuovi contenuti, né la sostituzione di parti del contenuto. La criticità di questo tipo di reti risiede nel fatto che tutti i trasmettitori devono diffondere lo stesso transport-stream in uscita dal playout in un intervallo di tempo non superiore a 1 sec. Ciò comporta la necessità di sincronizzare tutti i trasmettitori. Questo si realizza con l'inserimento nel transport-stream di segnali GPS (per mezzo di un SFN adapter). Tali segnali sono poi confrontati con quelli ricevuti tramite il GPS. Il confronto avviene per mezzo del modulo SFN-sync che provvede, anche, a compensare il tempo di propagazione sulla base della differenza calcolata tra l'istante di invio (uscita dal playout) e l'istante d'arrivo all'ingresso di ciascun trasmettitore della rete. Le reti SFN sono costituite da trasmettitori e gap-filler. I ripetitori non possono essere utilizzati nella realizzazione di queste reti in quanto non è possibile compensare le differenze nei tempi di propagazione.

Fig. 2.5 - Modello di diffusione SFN

L'uso di gap-filler presenta alcune difficoltà che riguardano in particolare il raggiungimento dell'elevato disaccoppiamento tra antenna ricevente e antenna trasmittente (riduzione della qualità del segnale



33

Fig 2.6 - Modello di diffusione MFN

In sintesi il sistema SFN opera come segue: il transport-stream, nel quale sono inseriti anche i segnali GPS di sincronizzazione, viene trasferito ai trasmettitori attraverso la rete di distribuzione. Nel centro trasmittente si compensa tramite l'SFN-sync il ritardo accumulato dal transport-stream che viene poi irradiato dal trasmettitore.

2.9 MFN Le reti MFN (dette anche Conventionally Planned Networks) possono essere impiegate per la diffusione di programmi e servizi sia in ambito nazionale che locale. La loro caratteristica è data dalla possibilità di inserire nel transport stream nuovi contenuti o parti di essi da irradiare in aree specifiche del complessivo ambito territoriale servito dalla rete. Va ricordato, inoltre, che questo tipo di rete ha la proprietà di essere decomponibile. I trasmettitori delle reti in questione non necessitano di essere sincronizzati come nel caso delle reti SFN. Ne consegue che nei relativi playout non sono presenti i ricevitori GPS e gli SFN adapter; analogamente, nei trasmettitori mancano sia i ricevitori GPS che i moduli SFN-sync. Le reti MFN sono costituite da trasmettitori e ripetitori. Difficilmente vengono usati gap-filler. Gli impianti ripetitori sono utilizzati per l'estensione delle aree servite dai trasmettitori e sono allocati al di fuori di tali aree. Va segnalato che in Italia la normativa vigente per l'elaborazione dei piani di assegnazione delle frequenze prevede che per i



34

collegamenti tra impianti di diffusione si debbano usare ponti radio, cavo o satellite, con la conseguenza che per i ripetitori non è prevista alcuna protezione dalle interferenze. Questo fatto limita fortemente l'uso di ripetitori nelle reti in esame. Se si considera, come esempio, una rete nazionale MFN che viene decomposta in reti regionali, si ha il modello schematico del sistema per servizi nazionali e servizi regionali. Il funzionamento può essere sinteticamente descritto dal playout nazionale il transport stream è inviato ai playout regionali mediante una rete di distribuzione nazionale SFN. Nei playout regionali, se previsto, vengono eliminati alcuni programmi provenienti dal playout nazionale, inseriti contenuti locali (provenienti per esempio dalle emittenti locali) e aggiornate le informazioni contenute nel SI (Service Information). L'uscita dal playout regionale viene quindi inviata tramite la rete di distribuzione regionale ai trasmettitori della rete regionale di diffusione.

2.10 k-SFN Una rete k-SFN è una rete costituita da k > 1 sottoreti isofrequenziali (SFN locali), ciascuna delle quali utilizza la composizione degli echi isofrequenza che cadono all'interno della finestra di guardia. In particolare, in una rete k-SFN a servizio nazionale si compongono tutti gli echi isofrequenza che cadono nella finestra di guardia, mentre in una rete k-SFN a servizio regionale si compongono costruttivamente i soli echi isofrequenza che giungono al ricevitore da siti la cui area di servizio appartiene alla regione in esame. La copertura totale di una rete k-SFN nella specifica area geografica è data dalla somma delle coperture delle k sottoreti. I suddetti tipi di reti si distinguono anche per quanto riguarda la loro capacità di trasmissione, minore per le reti SFN rispetto alle reti MFN. Ciò comporta che le reti SFN possono, rispetto alle reti MFN, trasmettere un minore numero di programmi o lo stesso numero di programmi ma con minore qualità. Le reti pianificate a livello nazionale possono essere decomponibili in reti a livello regionale, provinciale o sub-provinciale. Su ogni rete possono essere trasmessi più programmi e servizi (almeno 4 programmi oltre ai servizi). L’espressione “reti pianificate a livello nazionale” non si riferisce ad una nazionalizzazione dell’emittenza, ma ad una modalità di pianificazione degli impianti da utilizzare sia a livello nazionale che locale.



35

2.11 Sistemi di ricezione d’utente I sistemi riceventi d'utente si suddividono in due grandi categorie:

• Sistemi di ricezione individuali, che utilizzano come componenti fondamentali dell'impianto il sistema di antenne e la rete di distribuzione interna agli edifici (vi rientra in alcuni casi anche l'amplificatore).

• Sistemi di ricezione centralizzata, i cui componenti fondamentali comprendono: il sistema di antenne, il preamplificatore, la centrale di testa (che può essere a larga banda, a bande separate o canalizzata) e la rete di distribuzione interna agli edifici.

I sistemi centralizzati si suddividono in: • Sistemi MAT V (Master Antenna TV), che distribuiscono segnali

terrestri captati dal sistema d'antenna, tipicamente nelle bande VHF e UHF, ma talvolta includono la distribuzione di segnali inseriti localmente (per esempio quelli generati da telecamere di controllo per la sicurezza);

• Sistemi SMAT V (Satellite Master Antenna TV) che, oltre ai segnali terrestri, captano e distribuiscono anche segnali provenienti da satellite, che vengono convertiti in antenna nella banda di prima frequenza intermedia (1 IF) da 950 a 2150 MHz. Gli impianti di ricezione attualmente in uso nel territorio sono molto spesso approssimativi, se non addirittura di fortuna.

L'obsolescenza degli impianti costituisce un handicap per un'adeguata distribuzione dei segnali digitali, si richiederà quindi un adeguamento delle infrastrutture e una maggiore organizzazione degli impianti di ricezione centralizzati.

2.12 Architettura MHP L’architettura base della piattaforma MHP è caratterizzata da tre livelli:

1. Applicazioni 2. Software di sistema 3. Risorse o periferiche

La Figura 2.7 mette in evidenza l’interconnessione tra terminale ed applicazioni a prescindere dal fatto che restino o meno separate le realizzazioni delle due parti.

2.12.1 Applicazioni Un’applicazione è la realizzazione funzionale di un servizio interattivo composto da moduli programmabili che richiedono funzionalità



36

specifiche residenti nell’hardware o nel software del terminale. Nella filosofia MHP le applicazioni sono il nodo centrale, tutto il contesto ruota intorno ad esse; si veda in proposito la figura 2.7 dov’è riportata una rappresentazione dell’insieme di interfacce presenti tra applicazioni MHP e il sistema MHP.

Fig. 2.7. Architettura funzionale del terminale MHP

Lo standard MHP supporta una grossa varietà di applicazioni come:

• EPG (Electronic Program Guide); • Servizi informativi, teletext avanzato; • Servizi interattivi, navigazione vincolata, navigazione aperta su

Internet; • Servizi transattivi, servizi per e-commerce.

Tuttavia, non si prevede che ogni STB supporti tutta questa varietà di applicazioni (per venire incontro ad una situazione di utenza con esigenze molto differenziate e per proporzionare i costi degli apparati di utente). Le applicazioni possono essere di tre tipi: residenti, installabili o scaricabili, si veda in proposito la tabella 2.3.



37

Fig. 2.8. Interfacce tra applicazioni MHP ed il sistema

Tab. 2.3 Tipi di applicazione



38

Fig. 2.9 - Diversi tipi di applicazioni MHP

2.12.2 Software di sistema Il Software di sistema del terminale MHP ha accesso diretto alle informazioni audio/video ed, in generale, a tutti i dati trasmessi in conformità degli standard DVB ed MPEG; vengono qui controllati i componenti hardware, e le interfacce con l’utente, cioè quegli elementi di basso profilo annoverabili all’ultimo livello dell’architettura funzionale del terminale MHP. Il Software di sistema è composto da uno strato detto HAL (Hardware Abstraction Layer) per la gestione delle interconnessioni a basso livello (fisico/elettrico) e da uno strato software (Sistema Operativo) per la gestione complessiva delle funzionalità del terminale.



39

Fig 2.10 - Architettura del software di sistema

Il software di sistema è caratterizzato in prima parte da una Java Virtual Machine (Java VM), che rende il sistema operativo molto semplice e, soprattutto, estremamente aperto (per quella che è la filosofia del Java stesso); i terminali MHP sono quindi equivalenti dal punto di vista strutturale, differenti solo in termini di prestazioni, anche perché le applicazioni stesse devono essere realizzate in linguaggio Java, supportate da interfacce API MHP (interfacce software con capacità funzionali e procedurali identiche per ogni terminale MHP).

2.13 Risorse e periferiche Le risorse e periferiche (interfacce verso l’esterno) del terminale MHP sono standardizzate solo in parte, è presumibile pensare che lo svilupparsi della tecnologia porti ad un relativo accrescimento delle capacità elaborative dei Set-Top-Box. Quella descritta in Tabella 2.4 è una dotazione solo ipotetica, dipendente anche dalle scelte commerciali dei produttori di apparecchiature.



40

Tab 2.4. Risorse e periferiche del terminale MHP

2.13.1 Java TV Le API (Application Programming Interface) consentono alle applicazioni di richiamare funzioni del sistema operativo e utilizzare risorse hardware del STB con modalità unificata, indipendente dalle applicazioni stesse. In altre parole, le API sollevano gli sviluppatori di applicazioni dal la necessità di conoscere i dettagli realizzativi del STB e dei suoi elementi hardware. Si può parlare a questo punto di una vera e propria estensione della piattaforma Java, creata appositamente per implementare tutte le funzionalità necessarie per la tv digitale (streaming audio e video in diversi formati, controllo dell'accesso condizionale, accesso ai canali di dati e a servizi informativi, controllo di sintonizzazione per la selezione ed il cambio di canale, controlli grafici on-screen, sincronizzazione dei media, controllo del ciclo di vita delle applicazioni); tale piattaforma è nota come Java TV, ufficialmente adottata dal DVB per il progetto MHP. L'ambiente software è costituito dalla piattaforma Java, dall'API JavaTV e da un RTOS (real time operating system). A livello più alto, le applicazioni possono utilizzare le librerie di classi dell'API JavaTV o della piattaforma Java. Il sistema operativo controlla l'hardware attraverso un insieme di controlli (device drivers), fornisce a livello di sistema il supporto necessario all'implementazione della Java VM. Le APIs incapsulano le funzionalità delle librerie del sistema che controllano l'hardware specifico perla televisione. Le APIs JavaTV forniscono una visione astratta del sistema che permette alle applicazioni (e quindi agli sviluppatori) di utilizzare le risorse hardware



41

in forma generica. Questo approccio rende possibile la portabilità delle applicazioni create con queste APIs. Gli operatori televisivi con approccio “verticale” verso il mercato hanno ovviamente mostrato scarso interesse per gli standard ed in particolare per quelli riguardanti le API per la gestione della multimedialità e dell’interattività; per esempio nel Regno Unito, che è il Paese europeo ove la televisione digitale ha raggiunto la penetrazione più alta (presente presso oltre il 40 per cento delle famiglie), ogni piattaforma digitale ha scelto una API differente. Quindi un operatore generalista come la BBC dovrebbe diffondere i suoi servizi digitali interattivi in formati diversi, se volesse raggiungere tutti gli utenti dotati di STB digitali. Si può ipotizzare un chiaro interesse dei grandi operatori del settore ad adottare la piattaforma MHP. Tuttavia, nel breve termine lo standard MHP risulta svantaggiato sul mercato:

• Non è implementato su tutti i decoder oggi in commercio; • Richiede processori più veloci e potenti di quelli necessari in

decoder funzionanti con standard già in commercio; • Richiede un maggior quantitativo di memoria per la gestione e

l’esecuzione delle applicazioni interattive; • Consente l’accesso Internet solo con il profilo più avanzato e

quindi più costoso.



42

Fig. 2.11 - Livelli architetturali del Java TV

A causa dei requisiti hardware migliori sono previsti costi più elevati rispetto alle soluzioni basate su piattaforme esistenti. È tuttavia prevedibile che solo tra 2/3 anni i costi associati al sistema MHP saranno competitivi rispetto ai costi offerti da soluzioni più semplici. L’uso di piattaforme con APIs differenti rappresenta un ostacolo per lo sviluppo della televisione digitale terrestre. Le APIs MHP offrono la possibilità di uno standard universale. Tuttavia resta importante prendere in considerazione soluzioni di APIs aperte, sebbene con funzionalità più limitate. È indubbiamente necessario che a livello nazionale sia chiara la migrazione a medio - lungo termine, verso lo standard delle APIs MHP. 2.13.2 Plug-in Una soluzione a tutti quei problemi derivanti dall’immissione sul mercato di un nuovo prodotto (in questo caso lo standard MHP) si trova



43

nell’utilizzo di appositi plug-in: trattasi di componenti software da installare nei terminali MHP per rendere compatibili i prodotti delle tecnologie preesistenti (e per evitare che venga posto un freno allo sviluppo del nuovo standard). Sono previste due tipologie di plug-in: • Tipo A Applicato alle tecnologie di più recente ideazione, costituito essenzialmente da uno strato software per la conversione dell’interfaccia non-MHP (una sorta di traduzione delle applicazioni). Può essere realizzato e fornito da soggetti molteplici. • Tipo B Si applica per aggirare l’architettura MHP, consentendo alle applicazioni di accedere direttamente all’HAL, alle periferiche o alle risorse del terminale in genere. Deve essere fornito dai costruttori di terminali.

2.14 Profili La piattaforma MHP definisce tre profili di ricevitori (paragonabili a tre aree di interesse commerciale), basando la suddivisione sulla tipologia di applicazioni supportate dagli stessi:

• Enhanced Broadcasting - EB • Interactive Broadcasting - IB • Internet Access – IA

A loro volta i tre profili vengono formalmente divisi in due diversi livelli evolutivi (non escludendo la possibilità di creare ulteriori livelli e profili con l’affermarsi di quelli esistenti).



44

Fig. 2.12 - Plug-in previsti dalla specifica MHP

Le interfacce software (APIs) che le applicazioni possono utilizzare sono compatibili tra i profili; ciò che varia è la disponibilità di predefiniti sottoinsiemi di interfacce, in base alla conformità ad uno o più profili.

Fig 2.13 - Schema riassuntivo dei diversi profili implementativi



45

La specifica MHP definisce una serie di regole funzionali, tra le quali quelle che governano il ciclo di vita delle applicazioni scaricabili sulla piattaforma, che sono comuni ai tre profili. Ad ogni profilo di implementazione corrispondono dotazioni hardware di cui la piattaforma deve obbligatoriamente disporre ed altre che sono considerate raccomandate o opzionali; varia conseguentemente la presenza delle interfacce software necessarie a gestire tali periferiche. Alcune interfacce software possono essere considerate comunque opzionali. Per disciplinare e facilitare l’interpretazione di una specifica così complessa, è presente nello standard una dettagliata descrizione di quelle che sono le prestazioni minime. 2.14.1 Enhanced Broadcast – Livello 1 Permette servizi di radiodiffusione avanzata per arricchire e completare i servizi televisivi di base per mezzo di contenuti multimediali (ad esempio brevi audio-video inseribili in notiziari, film, eventi sportivi, ecc.). Inoltre tale profilo permette la trasmissione di servizi di EPG, teletext avanzato e giochi, memorizzandoli nella memoria del terminale d’utente.

Fig. 2.14 - Profili e livelli MHP

I terminali conformi a questo profilo devono necessariamente essere dotati di accesso al canale di trasmissione broadcast, mentre la presenza del canale di ritorno è soltanto opzionale. È possibile allestire servizi



46

che combinano le trasmissioni digitali ordinarie con software scaricabili, lasciando ai broadcaster ed ai costruttori una discreta libertà di progetto. 2.14.2 Interactive Broadcast Questo profilo richiede la presenza del canale di ritorno; permette di aggiungere ai servizi del profilo Enhanced Broadcasting servizi di tipo interattivo con la possibilità per l’utente di interagire con un centro servizi attraverso un canale di ritorno (interazione tra un terminale e server remoti). Sarà quindi possibile offrire servizi di tipo pay come la pubblicità interattiva, le transazioni (home-banking, commercio elettronico) ecc. In tale profilo la navigazione Internet è implicita, cioè codificata all’interno delle applicazioni e trasparente per l’utente. I servizi interattivi possono essere indipendenti o meno dai contenuti trasmessi in broadcast; a questo livello è anche possibile rendere unidirezionale la trasmissione broadcast, rendendo i contenuti che sono ricevibili da ogni utente, accessibili solo da coloro che ne hanno l’autorizzazione. Le applicazioni presenti in questo profilo possono essere scaricabili o residenti. Le caratteristiche di tale identificativo devono essere compatibili con l’impiego dei protocolli di comunicazione previsti dalla specifica MHP, e non devono comportare per l’utente la necessità di ripetere più volte l’inserimento di informazioni personali, testi, sequenze numeriche. La realizzazione di alcuni di questi servizi potrebbe altresì richiedere che le applicazioni software possano avere accesso ad una o più smart-card connesse direttamente al terminale MHP tramite lettore di smart-card “embedded”, ovvero inserito in un modulo CAM-like connesso allo slot di Interfaccia Comune. Nello specifico, per permettere all’utente di sfruttare a pieno le potenzialità di tali servizi, il terminale MHP dovrebbe disporre di un lettore smart-card, nonché di librerie software a corredo, in modo tale da garantire, aggiuntivamente a quanto prescritto dalla specifica MHP, la conformità allo standard PC/SC, nonché, per quanto riguarda le smartcard, la conformità alle prescrizioni vigenti. Per questo profilo la specifica prescrive la presenza di almeno un’interfaccia verso un canale bidirezionale che supporti il protocollo IP, che è anche l’unico protocollo di basso livello (ISO/OSI – Livello 3) esplicitamente previsto dallo standard per il canale interattivo. Lo stesso profilo prescrive la disponibilità per le applicazioni di una specifica interfaccia API che consenta la gestione delle connessioni ad un ISP (anche diverso da quello di default, che viene indicato dal costruttore, o dall’utente).



47

Fig. 2.15 - Protocolli supportati per il canale interattivo

Per fornire il canale interattivo sul STB sono previste due modalità: tramite modulo di rete (Interactive Interface Module) integrato o tramite modulo di rete esterno. Nella seconda modalità la connessione tra il modulo di rete e il Set Top Box (STB) è realizzata mediante la rete digitale domestica (In Home Digital Network). Tale rete consente una grande flessibilità di installazione facendo uso di interfacce standard di grande diffusione su cavo o su portante radio (per es. Ethernet, Wi-fi, Bluetooth, ecc.). 2.14.3 Internet Access – Livello 1 Permette l’accesso Internet. Tale profilo offre la possibilità di accedere a servizi di tipo Internet come navigazione su siti Web e consente di effettuare transazioni commerciali del tipo e-commerce sfruttando i protocolli di sicurezza già sviluppati per Internet. L’esistenza di questo profilo rende lo standard MHP tecnicamente molto più potente delle piattaforme esistenti, contemplando le caratteristiche di entrambi i profili precedenti, rappresenta il vero e proprio punto di convergenza tra le tecnologie informatiche e televisive. Sarà interessante seguire gli sviluppi dei sistemi con canale interattivo basati su strutture diverse dal semplice collegamento modem (GSM, UMTS/GPRS, ADSL/VDSL). I servizi xDSL sono da tenere in considerazione soprattutto nella prospettiva di supporto alla modalità “always-on”, ovvero quella modalità per cui l’utente ha accesso permanente alla rete, senza dover stabilire, per ogni sessione di comunicazione, una specifica connessione.



48

La caratteristica “always-on” ha tutta una serie di implicazioni positive (disponibilità del canale all’accensione del STB, accesso istantaneo ai servizi, capacità di ricevere informazioni e aggiornamenti in ogni momento). Dal punto di vista della sicurezza, la specifica prescrive l’utilizzo del protocollo TLS (IETF RFC 2246), permettendo un livello minimo di autenticazione RSA della firma digitale, “hashing” e la crittografia simmetrica. Sono previsti meccanismi, procedure e dotazioni minime per la gestione dei certificati x509 che consentono l’implementazione dell’infrastruttura a chiave pubblica - PKI - prevista dalla tecnologia RSA (con lunghezzadella chiave pubblica minima di 2048 byte per il canale interattivo, e di 4096 byte per l’autenticazione delle applicazioni software), necessaria anche per l’autenticazione del server all’atto di aprire una sessione sicura sul canale interattivo. Il punto più critico per preservare la sicurezza dell’intera infrastruttura di servizio, la gestione della revoca tempestiva dei certificati compromessi, appare correttamente affrontato solo per il profilo IB1, anche se il compromesso individuato nella specifica non soddisfa pienamente le esigenze di sicurezza. E’ comunque consentito negoziare con i costruttori l’implementazione di procedure più affidabili in caso di applicazioni particolarmente sensibili alla sicurezza. Non è prescritto l’impiego di tecniche per crittografare la sessione stessa, per cui i dati possono viaggiare in chiaro, se non diversamente protetti ad un livello superiore. Non è obbligatoria la presenza di un’interfaccia API che consenta l’autenticazione del client, né è prevista l’implementazione sulla piattaforma delle procedure TLS (Transport Layer Security) lato server. L’integrazione dei sistemi di accesso condizionato con la piattaforma può essere realizzata:

• Dal costruttore della stessa, che quindi individua, anche concordemente

• con operatori di servizi, il/i sistema/i da integrare; • dall’operatore del servizio televisivo interessato, se il costruttore

ha introdotto nel proprio apparato il dispositivo standard Interfaccia Comune (EN 50221).

Il profilo Internet Access resta comunque ancora lontano dalla realizzazione pratica, sarà completamente specificato solo in versioni superiori dello standard, così come avverrà anche per i profili di livello 2.



49

2.15 Set Top Box 2.15.1 Architettura In fig. 2.16 è rappresentata l’immagine dell’architettura del Set-Top-Box o IRD ricevitore/decodificatore integrato digitale) per evidenziarne le interfacce e i principali blocchi funzionali.

Fig 2.16 - Architettura del Set-Top-Box

L’architettura generale si compone di:

• Un livello hardware e firmware comprendente le interfacce verso l’esterno e il bootloader, che consente l’aggiornamento del software residente;

• Un livello software residente che include il software di sistema, il navigatore e, ove necessario, il middleware (JAVA, browsers XML, HTML, ecc.);

• Un livello API per l’ulteriore gamma di applicazioni (EPG, Teletext evoluto).

• Le interfacce verso l’esterno possono comprendere l’ingresso/ uscita RF/IF, le uscite audio e video, gli ingressi/uscite audio/video e dati, telecomando, l’interfaccia comune, le interfacce smart-card e il canale di ritorno. Citazione Java TV API Technical overview



50

Occorre precisare che la dotazione dell’interfaccia comune è obbligatoria per i soli ricevitori con accesso condizionato integrati negli apparecchi televisivi ed è raccomandata per i set-top-box che prevedono le funzioni di accesso condizionato. La presenza del canale di ritorno e del relativo strato software di gestione è raccomandata per i ricevitori di funzionalità estesa.

Fig. 2.17 - Architettura del set-top-box - dettagli

Relativamente al software, si fa notare che in tutti i ricevitori terrestri, satellitari e via cavo, è essenziale la presenza di un navigatore in grado di presentare all’utente il contenuto delle informazioni sulla programmazione diffuse dagli operatori televisivi, secondo la normativa DVB-SI. Le interfacce software (APIs) che permettono di scaricare sull’ IRD applicazioni multimediali sono raccomandate nei soli ricevitori evoluti. Di fondamentale importanza, inoltre, è la possibilità di modificare in tutto o in parte il software residente del IRD. 2.15.1 Funzionalità hardware e firmware Esaminando nel dettaglio l’architettura di rete proposta, è possibile individuare i blocchi principali che costituiscono la struttura hardware e firmware dell’IRD. I moduli a fondo chiaro costituiscono la struttura base dell’IRD terrestre e devono tutti essere considerati come essenziali. I moduli a fondo scuro rappresentano l’estensione della



51

struttura tramite la quale il STB acquisisce funzionalità estese (es: multimedialità, interattività, registrazione locale). Nel caso di servizi provenienti da diversi mezzi di trasmissione (satellite, cavo, terrestre) si raccomanda che l’utente sia messo in condizione di navigare, in modo semplice, tra i servizi originati da diversi front-end. La presenza contemporanea nell’IRD terrestre dell’interfaccia comune e del CA Embedded con relativo lettore di smart-card risponde all’esigenza di massima flessibilità sotto il profilo del controllo d’accesso. In tal modo un unico IRD è in grado di gestire e offrire all’utente servizi criptati di differenti operatori sia in multicrypt (EN 50221) sia in simul-crypt (TS 101-197).

2.15.2 Front-end Il front-end deve essere in grado di ricercare automaticamente ogni segnale presente all’interno dell’intervallo di frequenze disponibile e riconoscere automaticamente la modalità trasmissiva (modulazione, il symbol rate e la correzione di errore). Deve inoltre essere in grado di ricevere le informazioni sulla sintonia tramite le tabelle PSI/SI. Opzionalmente l’IRD si sintonizza sul canale RF richiesto dall’utente. Una volta acquisiti, i dati relativi alla sintonia devono essere memorizzati in modo da poter essere rapidamente disponibili. Queste caratteristiche devono essere condivise da tutti i front-end (terrestre, cavo e satellite) installati nell’STB. Il front-end del set-top-box terrestre dovrà includere un by-pass RF analogico, funzionante anche in stand-by. È raccomanda una realizzazione che includa anche il modulatore RF PAL, per il reinserimento del programma digitale decodificato. 2.15.3 Demultiplexer MPEG-2 Ricompone i flussi relativi ai programmi a partire dai pacchetti TS ed effettua la sincronizzazione dei flussi audio e video secondo la codifica di trasporto MPEG-2 definita in ISO/IEC 13818-1. È necessario inoltre:

• Utilizzare le tabelle MPEG-2 SI-DVB; • Interpretare il descrittore CA come definito in ETR 289; • “Demultiplare” un flusso ISO/IEC 13818-1 con data rate fino a

60 Mbit/s; • Selezionare, opzionalmente, uno o più flussi dati, definiti in EN

300 192, e inviarli a un’uscita compatibile;



52

• Ignorare strutture dati che, allo stato attuale, sono classificate reserved, in modo da garantire la compatibilità con versioni future.

2.15.4 Video Decoder MPEG–2 Il decoder video deve rispettare gli standard e le linee guida fornite dai seguenti documenti:

• ISO/IEC 13818-1, ISO/IEC 13818-2 • ETS 300 468, ETR 211 • ETR 154. • ITU-R BT. 1119-1, ETS 300 294

Le caratteristiche minime del video decoder MPEG-2 sono le seguenti: • Risoluzioni (riferite ai pixel di luminanza) di: 720x576, 544x576,

480x576, 352x576 o 352x288 rappresentabili, sulle uscite video analogiche, anche a pieno schermo (fullscreen);

• Formati 4:3 e 16:9 (aspect ratio information) ; • Supporto del formato MPEG-1; • Supporto di bit rate video fino a 15 Mbit/s.

2.15.5 Decoder audio Il decoder audio MPEG dovrà rispettare le linee guida fornite dal DVB ETR 154 che si riferisce agli standard ISO/IEC 13818-3 e 11172-3. In particolare:

• Supporto del MPEG layer I e II, III opzionale, ma si raccomanda l’estrazione di almeno una coppia di canali stereo MPEG-2;

• Supporto delle velocità di campionamento 32, 44.1, 48 kHz e per MPEG-2 22.05 e 24 kHz.

2.15.6 Sincronismo audio video Almeno un decoder audio dovrà rispettare i requisiti di decoding della ETR 154. Il ritardo relativo introdotto dal decoder fra segnali audio e video non dovrà superare i 5 ms. Livelli di set-up in linea con DVB ETR 154. 2.15.7 Unità di controllo La configurazione minima dell’unità di controllo per l’ IRD a funzionalità estesa dovrà essere di:

• 4 Mbyte RAM; • 4 Mbyte flash memory;



53

• 4 Mbyte video RAM; Ogni STB dovrà avere le seguenti funzioni: • Orologio e, in via opzionale, calendario in tempo reale, aggiornati

via SI; • Timer opzionale per il controllo dell’ accensione e lo

spegnimento automatico. 2.15.8 Bootloader Questo modulo è realizzato in software residente e ha la funzione di gestire lo scaricamento di tutto o di parte del software (drivers, SO, e applicazioni) nell’IRD. Il caricamento del software può avvenire:

• Attraverso il canale broadcast; • Attraverso un modulo appropriato connesso all’interfaccia

comune; • Utilizzando il canale interattivo; • Attraverso le interfacce dati.

Si raccomanda che il bootloader sia in grado di prevenire il caricamento di software non certificato e che il protocollo di sicurezza sia basato su un meccanismo di crittografia asimmetrica (chiave pubblica/chiave privata, con le chiavi pubbliche presenti nell’IRD). 2.15.9 Funzionalità grafiche L’IRD deve essere in grado di gestire funzionalità grafiche per il controllo dello stesso tramite on-screen-display (OSD) e per il navigatore di base basato sulle informazioni DVB SI. La funzionalità estesa deve essere in grado di gestire opzioni grafiche avanzate e la visualizzazione del segnale OSD. Deve inoltre soddisfare i seguenti requisiti minimi:

• Risoluzione 720x576 con aspect ratio 16:9 e 4:3; • Numero di colori 256 più trasparenza con modo di presentazione

specificato dalle API ; • Supporto simultaneo di grafica, video e still pictures; • Supporto della sottotitolazione DVB (ETS 300 743).

2.15.10 Interfacce e livelli di segnale I requisiti delle varie interfacce esterne di cui l’IRD deve/può essere dotato sono elencati qui sotto.



54

Tab 2.5 - Interfacce e livelli di segnale

2.15.11 Software e servizi Nel software del STB si possono distinguere: il software residente di sistema e le applicazioni. Il software di sistema deve fornire due classi di funzioni: una classe è accessibile solo all’interno del medesimo software di sistema, come il navigatore di base,mentre l’altra è disponibile internamente ed esternamente per le varie applicazioni, quali l’EPG, e costituisce l’API dell’ IRD. 2.15.12 Navigatore Il software di sistema sia per il profilo base sia per quello a funzionalità estesa deve contemplare un navigatore definito dal costruttore, che permetta all’utente di configurare e di controllare la sintonia dell’ IRD. Sarà pertanto compito del costruttore stabilire l’aspetto grafico della presentazione dei dati. Il navigatore deve fornire la lista di tutti i servizi presenti su tutti i canali accessibili, anche quando i segnali non trasportino le informazioni SI incrociate. L’utente deve in ogni caso poter configurare manualmente l’ordine dei canali preselezionati in



55

automatico e richiamare, tramite telecomando, la funzione di navigazione e aggiornamento dei dati.

2.16 Requisiti minimi Le sperimentazioni preliminari in fase di progetto e definizione dello Standard hanno permesso di individuare quali sono le caratteristiche hardware e software che devono essere contenute nei terminali per rispettare i requisiti implementativi minimi dello stesso nel modo migliore. Nella Tabella 2.6 sono riportate le caratteristiche dei STB che hanno dato risultati positivi in fase di sperimentazione.

Tab. 2.6 - Caratteristiche minime del Set Top Box

2.17 Telecomando Affinché le applicazioni MHP producano risultati uguali su Set- Top-Box diversi è necessario che anche il comportamento degli utenti sia sempre il medesimo; per ottenere ciò è necessario che il telecomando,



56

ossia lo strumento che guida l’utente nell’utilizzo dell’applicazione, sia semplice nell’utilizzo ed anch’esso conforme ad uno standard (tab. 2.7)

Tab. 2.7 - Caratteristiche minime del telecomando MHP


Capitolo 3. Applicazioni MHP

57


3.1 Modello di Business e interfacce Un’applicazione mhp viene sviluppata seguendo un modello di business che si basa su più fattori:

- MSO (Multiple Service Operator) i broadcaster, cioè coloro che forniscono la possibilità di scaricare le applicazioni e i contenuti per la iTV

- MSV (Middleware Software Vendor) gli sviluppatori java/DVB-HTML

- I fornitori dei contenuti ISP (Internet Service Provider) - Set-top-box Manufacturers - Users: gli utenti dotati di set-top-box, televisore e telecomando

Date l’innumerevoli combinazioni che possono venire dall’incrocio dei diversi fattori elencati, non poche possono sembrare le difficoltà nel produrre un’applicazione MHP. Il trucco si trova nelle interfacce che lo standard MHP mette a disposizione sia a livello software (figura 3.1) che hardware (figura 3.2). MHP è basato su java, (platform indipendent), il set-top-box ha preinstallato una VM java corredata da API proprietarie e TV API di SUN, che definiscono le modalità di comunicazione tra l'utente, il set-top-box e il broadcaster. MHP ha definito anche un sotto linguaggio HTML (DVB-HTML per la precisione) con tag supplementari relativi alla cattura dell'input dell'utente (telecomando). Il set-top-box ha preinstallato un'applicazione che si chiama Application Manager (di solito java) che gestisce il caricamento del software creando anche i menu dei canali forniti dal broadcaster. Oltre a ciò il set-top-box possiede anche un alloggiamento per smartcard (nonché un lettore per le stesse), che offre servizi sicuri come login utente, servizi a pagamento ecc..



58

Fig. 3.1 – Software layer

Fig. 3.2 - Interfaccia tra mhp application e mhp system



59

Per ogni tipo di interfaccia si avrà una suite di classi che permetterà di far dialogare l’applicazione con i dispositivi a disposizione: schermo, telecomando, smart card, canale di ritorno.

3.2 Xlet Una Xlet è una particolare applicazione Java concepita per essere scaricata ed eseguita su decoder interattivi nei quali un software specifico, l'Application Manager, è in grado di controllarne il ciclo di vita. Come vedremo le similitudini con le Applet, dove l'application manager è rappresentato dal browser sono molteplici. Per iniziare a costruire una Xlet occorre innanzitutto capire cosa viene fornito da Sun nelle API Java TV. Infatti è proprio in queste librerie che vengono definite le due interfacce fondamentali da utilizzare: javax.tv.xlet.Xlet che definisce i seguenti metodi:

public void initXlet(XletContext ctx);

public void startXlet();

public void pauseXlet();

public void destroyXlet(boolean unconditional);

javax.tv.xlet.XletContext che definisce i seguenti metodi: public void notifyDestroyed();

public void notifyPaused();

public java.lang.Object getXletProperty(java.lang.String key);

public void resumeRequest();

Entrambe le interfacce servono per interagire con l'application manager in merito al ciclo di vita e al contesto in cui la Xlet viene eseguita. La classe principale di ogni Xlet deve sempre implementare javax.tv.xlet.Xlet per poter essere eseguita sui decoder interattivi MHP. Come si mostra in Figura 3.3 il ciclo di vita di una Xlet è caratterizzato da 4 stati:

Loaded: in questo stato la Xlet è stata creata ma non inizializzata, se durante questa fase viene rilevata un eccezione allora si passa direttamente nello stato Destroyed. Da notare che la Xlet si può trovare in questo stato solo una volta durante tutto il suo ciclo di vita. Paused: la Xlet è inizializzata e può trovarsi in questo stato sia dopo che il metodo initXlet(XletContext) è ritornato con successo dallo stato Loaded oppure dopo che il metodo pauseXlet() è ritornato con successo dallo stato Active. In entrambi i casi in



60

questo stato la Xlet dovrebbe limitare al massimo l'utilizzo delle risorse condivise e soprattutto non impegnare la GUI televisiva. Active: in questo stato la Xlet è attiva e utilizza le risorse necessarie per fornire i suoi servizi, se dotata di GUI allora dovrebbe essere l'unica registrata per ricevere gli eventi del telecomando. Destroyed: in questo stato la Xlet deve rilasciare tutte le risorse in uso per predisporsi alla terminazione.

Fig. 3.3 - Ciclo di vita di una Xlet

Una sequenza tipica di questo ciclo potrebbe essere: L' application manager crea una nuova istanza di una Xlet chiamando il suo costruttore (stato LOADED). La Xlet usa il context passatogli dall'application manager nel metodo initXlet(XletContext) e si inizializza (stato PAUSED). L'application manager chiama il metodo startXlet() e la Xlet inizia ad utilizzare le risorse necessarie per fornire i servizi per cui è stata costruita(stato ACTIVE). L'application manager chiama il metodo destroyXlet(true) e la Xlet rilascia le risorse, dopodiché viene terminata (stato DESTROYED). Il primo esempio: HelloXlet.java

import javax.tv.xlet.Xlet;

import javax.tv.xlet.XletContext;

import javax.tv.xlet.XletStateChangeException;

public class HelloXlet implements Xlet{

// L'XletContext è un oggetto usato dalla Xlet per accedere

// alle properties del suo environment e per comunicare con

// l'application manager che glielo ha passato nella fase

// di inizializzazione.

private XletContext context;

private boolean alreadyActive = false;



61

// Il costruttore tipicamente viene lasciato vuoto visto che tutte

// le inizializzazioni dovrebbero stare nel metodo

initXlet() public HelloXlet(){}

// In questo metodo vengono fatte tutte le inizializzazioni,

// se in questa fase qualcosa fallisse verrebbe lanciata un

// eccezione.

public void initXlet(XletContext context) throws XletStateChangeException{

// si memorizza il context passato dall'Application Manager

this.context = context; System.out.println(this.getClass().getName()+" :

Inizializzazione avvenuta!"); }

// Con questo metodo la Xlet è avviata e vengono richieste

// le risorse necessarie come ad esempio lo schermo TV o

// gli eventi del telecomando

public void startXlet() throws XletStateChangeException{

// controlliamo se la Xlet era già stata messa in stato Active

// precedentemente

if (alreadyActive){ System.out.println(this.getClass().getName()+" : Hello

Again TV World! ");

}else {

System.out.println(this.getClass().getName()+" : Hello TV World");

alreadyActive = true; } }

// Con questo metodo la Xlet viene messa in pausa e dovrebbe

// rilasciare tutte le risorse utilizzate

public void pauseXlet(){ System.out.println(this.getClass().getName()+" :

Xlet in pausa!");

// notifichiamo al Context l'avvenuta pausa della Xlet

context.notifyPaused(); }

// Con questo metodo la Xlet viene terminata, tramite il

// parametro boolean la Xlet ha la facoltà di accettare

// tale richiesta; nel caso non accettasse di

// terminare dovrebbe lanciare un eccezione.

public void destroyXlet(boolean unconditional) throws

XletStateChangeException { if (unconditional) {

System.out.println(this.getClass().getName()+" : la Xlet è stata terminata!");

}else {

System.out.println(this.getClass().getName()+ " : la Xlet ha accettato di

essere terminata!"); }

// notifichiamo al Context l'avvenuta terminazione della Xlet

context.notifyDestroyed(); } }

3.3 Gestione delle risorse scarse I Set Top Box sono sistemi che presentano risorse limitate a livello hardware come poca memoria e processori “lenti”, rispetto agli attuali



62

PC in commercio, quindi per poter utilizzare le varie periferiche: input (telecomando), output (decoder Mpeg2 per visualizzare le immagini su video) e modem si devono usare delle accortezze, le precedenti periferiche vengono chiamate “risorse scarse”. Se le risorse non vengono gestite in maniera ottimale potrebbe succedere che un'applicazione non sia in grado di funzionare correttamente o non sia in grado di sfruttare tutte le potenzialità del STB. Le API che andremo a considerare sono le resource notification API che sono state definite da DAVIC nel package org.davic.resource . Una cosa da tenere in considerazione è che queste non sono API di gestione delle risorse, in quanto questa viene lasciata al middleware del ricevitore ma ben si di notifica. Servono quindi a notificare all'applicazione se una risorsa è stata tolta, oppure se è richiesta da un'altra applicazione concorrente. Le resource notification API sono sostanzialmente composte da tre classi:

• ResourceServer

• ResourceClient • ResourceProxy

Tali classi non hanno funzionalità autonoma ma forniscono dei concetti comuni ai quali le API che definiremo di “ utilizzo” dovranno attenersi per svolgere i loro compiti. Questo significa che essendo queste delle “interface” saranno le classi che le implementano a definirne nello specifico i loro compiti. Queste API si basano sul modello client-server con piccole variazioni. L'interfaccia ResurceServer è implementata da quelle API di utilizzo responsabili di effettuare la richiesta di risorse scarse, e di gestirne la loro allocazione. Tali risorse scarse potrebbero essere di tipo software, ad esempio il section filter, oppure di tipo hardware come per esempio un modem oppure un decoder MPEG, le API non fanno distinzione e le trattano tutte in maniera simile. Il codice sorgente dell'interfaccia ResurceServer è il seguente:

public interface ResourceServer {

public abstract void addResourceStatusEventListener(

ResourceStatusListener listener);

public void removeResourceStatusEventListener( ResourceStatusListener

listener); }

Come si può vedere questa interfaccia non definisce dei metodi specifici per attuare una richiesta di accesso esclusivo ad una risorsa scarsa oppure per rilasciarla, questa è una scelta voluta perché sarà compito delle API di utilizzo fare questo nella maniera più consona. Gli unici metodi che questa interfaccia definisce permettono di registrare un ascoltatore degli eventi che riporterà i cambiamenti di stato della nostra risorsa. Il modo con cui noi riserviamo una risorsa come il modem è



63

infatti completamente differente da quello con cui gestiamo il un decodificatore MPEG per esempio. Vedremo in seguito come la classe ConnectionRCInterface attraverso il metodo reserve() andrà a richiedere l'accesso esclusivo sul modem. L'interfaccia ResurceClient è come si può capire dal nome il lato client delle API. Questa interfaccia viene implementata da quelle classi che richiedono l'accesso alla risorsa scarsa, e viene utilizzata dal middleware per richiedere il rilascio della risorsa oppure per informarla che il rilascio è già avvenuto. Il codice sorgente è il seguente:

public interface ResourceClient {

public abstract boolean requestRelease( ResourceProxy proxy, Object

requestData);

public abstract void release( ResourceProxy proxy);

public abstract void notifyRelease( ResourceProxy proxy); }

Come possiamo vedere questa interfaccia mette a disposizione del middleware tre metodi per comunicare all'applicazione di rilasciare la risorsa. Il metodo requestRelease() è il meno incisivo dei tre perché lascia al client di scegliere se soddisfare la richiesta oppure rifiutare. Nel caso in cui il client abbia ancora bisogno di trattenere la risorsa ritornerà false e il middleware dovrà se necessario attuare un sistema di rilascio forzato. Altrimenti nel caso in cui la risorsa non è più necessaria per il client esso riporterà true ed il middleware potrà procedere con il rilascio. Il metodo release() è il più aggressivo perché obbliga al nostro client di rilasciare la risorsa senza scelta. Quando il metodo ritorna, il middleware sarà certo di poter fornire la risorsa ad un altro client che ne fa richiesta. Se il metodo release() non ritorna in tempo accettabile il middleware può ritenere che l'applicazione sia andata in crash e metterà comunque a disposizione la risorsa rimuovendone i diritti di utilizzo. Se succede questo il middleware chiamerà il metodo notifyRelease() dell'interfaccia ResourceClient, andando a informare l'applicazione che è stata privata della risorsa scarsa e che dovrà quindi agire terminando i processi che la impiegavano. Questa è una operazione brutale per il client ma viene utilizzata quando questo non collabora con il middleware. L’interfaccia ResourceProxy mette a disposizione solo un metodo di notifica utilizzato per restituire il client della risorsa a cui esso fa riferimento ed è composta come di seguito:

public interface ResourceProxy {

public ResourceClient getClient(); }

La classe che implementa ResourceProxy si pone nel mezzo tra il client e la risorsa da utilizzare questo porta ad un grande livello di sicurezza perché l’applicazione ottiene un accesso mediato alla risorsa e ciò per



64

permettere al middleware di controllarla. Le classi che implementano il proxy mettono a disposizione dei metodi che possono essere utilizzati per fare il set-up delle risorse. In questo modo quando si attuano più cicli di request/release delle risorse non si dovrà tutte le volte settare i parametri ma questi verranno forniti dal proxy precedentemente impostato. Con una risorsa come il modem, dove ogni volta, per effettuare una connessione, bisogna fornire numero telefonico, username e password questo comporta un elevato risparmio di tempo. Un altro beneficio portato è che le classi che implementano il client possono allacciarsi a più proxy differenti, ognuno dei quali capace di fornire un setting differente per i parametri della risorsa, sarà poi l’applicazione a decidere quali proxy utilizzare nel momento in cui ne fa richiesta. Vediamo di capire meglio cosa succede quando un’applicazione richiede l’accesso a una risorsa seguendo i passi di seguito illustrati: 1. Innanzi tutto l’applicazione, o meglio le classi che implementano il client creano un’istanza del ResourceProxy appropriato e settano tutti i parametri del caso in base alla risorsa che andranno a utilizzare:

2.Il client va a chiamare un metodo appropriato sulle API che implementano il ResourceServer e richiedono accesso alla risorsa passando il ResourceProxy come parametro:



65

3. Se l’accesso alla risorsa è garantito il server chiama un metodo privato sul proxy per convalidarlo:

4.Si stabilisce un collegamento diretto tra il proxy e la risorsa, collegamento che fino a questo momento non esisteva per ragioni di sicurezza:



66

5. A questo punto la nostra applicazione può cominciare ad utilizzare la risorsa utilizzando i metodi del proxy,sarà poi questo a riportare le richieste alla risorsa:

Il processo di rilascio delle risorse è sostanzialmente l’inverso di quello precedentemente illustrato: 1.Quando il client ha terminato di utilizzare una risorsa chiama un metodo appropriato sul server per rilasciare la risorsa passandogli il proxy come parametro:



67

2. Ora il server chiamerà un metodo appropriato sul proxy per invitarlo a rilasciare la risorsa a cui fa riferimento invalidandolo:

3. Nel caso in cui l’applicazione è cooperante il proxy procede con il rilascio della risorsa:

Vediamo cosa succede quando un’applicazione “maliziosa” non vuole rilasciare la risorsa, ed interviene il middleware:

1. il server chiama il metodo release() sul client; 2. il client fallisce nel ritorno da questa chiamata e continua a

trattenere la risorsa; 3. dopo un certo periodo di tempo il middleware notifica al server

che la richiesta non ha avuto un responso; 4. il server chiama un metodo privato sul proxy per informarlo che

non e più valido e che non può più trattenere la risorsa; 5. il proxy rompe il collegamento con la risorsa; 6. il middleware chiama allora il metodo notifyRelease() su quella

classe che implementa l’interfaccia ResourceClient. In questo modo l’applicazione sa che non ha più accesso alla risorsa e che si dovrà comportare di conseguenza;

7. tutti i futuri tentativi di accesso alla risorsa da parte dell’applicazione non avranno alcun effetto.



68

L’aver descritto in maniera cosi approfondita, come avviene la gestione delle risorse e quali sono le API Java che ci permettono di fornire supporto per la notifica di gestione da parte del middleware, ci da la possibilità in futuro di introdurre i package che contengono le classi da utilizzare per stabilire una connessione, impostarne i parametri, settare un background, spostare e/o ridimensionare il video che come vedremo implementano le classi del package org.davic.resource.



69

3.4 Modello grafico Il modello grafico definito dallo standard MHP è basato su tre differenti piani (o layers) come mostrato in Figura 3.4

Fig. 3.4 - Layer grafici dell'MHP

Partendo da dietro, rispetto a chi guarda la TV, troviamo il Background layer che può contenere un solid color o una still image (rappresentata da un particolare frame MPEG-2, quello di tipo I), avanti troviamo il Video layer rappresentato dal flusso A/V del canale TV o di una qualsiasi altra fonte in formato MPEG-2. L’ultimo livello è il Graphics layer che può contenere la grafica creata nella Xlet, che a sua volta può essere strutturata su n-livelli sovrapposti. Tutti e tre i livelli lavorano ad una risoluzione standard di 720x576 o 768x576 se viene impostato il modo di visualizzazione su schermo 4:3. Per chi è abituato a fare applicazioni grafiche su PC non ci sono molte differenze, ma è il caso di tenere in considerazione alcuni aspetti: i pixel non sono perfettamente quadrati; il file che costituisce il background deve essere un’immagine video in formato mpeg2 (.mpg) in loop e non un immagine statica (.jpg), dato che il STB usa per la sua visualizzazione lo stesso decoder del video layer. (Programma di conversione consigliato .jpg -> .mpg “ImageMagic”);



70

le linee spesse 1 pixel non vengono visualizzate perfettamente o addirittura non sono visibili (consigliato spessore >=2); le coordinate assolute (x,y) partono da 0,0 angolo superiore sinistro; possono essere usate coordinate indipendenti dalla risoluzione chiamate “normalizzate” e si esprimo con numeri decimali da 0.0 a 1.0 supportate nelle API Havi; nella gestione del livello grafico è assicurata la visualizzazione completa in un area ridotta rispetto alle coordinate totali, detta SAFE AREA di ampiezza 562x460.

Fig. 3.5 – Safe Area del monitor

Dopo aver visto le accortezze da usare andiamo ad analizzare in dettaglio, con porzione di codice commentato, i tre livelli di grafica. 3.4.1 Background layer Per settare uno sfondo sulla nostra applicazione bisognerà innanzitutto tener conto che la periferica che andremo ad utilizzare, il decoder mpeg2 è una risorsa scarsa, quindi per effettuare qualsiasi tipo di settaggio bisognerà prima acquisirla usando le resource notification API introdotte nei paragrafi precedenti. Il package più importante da importare per la gestione di questo layer è org.havi.ui.* , riportiamo la classe più rilevante “HScreen”:



71

Tab. 3.1 – Methos Summaty èer grafica



72

Vediamo in breve le operazioni da eseguire: per prima cosa si sceglie lo schermo da usare mediante l’oggetto HScreen, a questo oggetto bisogna associare una HGraphicsDevice che conterrà il set d’impostazioni assegnate per mezzo di HGraphicsConfigTemplate. Il set di ogni singola impostazione è eseguito dal metodo setPreference al quale viene passato il parametro e la priorità; sarà poi il midlleware a decidere se il settaggio richiesto è attuabile in base alla priorità data e alle esigenze delle altre eventuali applicazioni che sono in running. Conviene creare una classe che implementa obbligatoriamente org.davic.resources.ResourceClient dove inserire tutti i metodi per l’acquisizione, il settaggio e il rilascio della risorsa. Di seguito viene riportata la classe “BackgroundController”, creata da Steve Morris, che mostra in dettaglio oltre alle fasi sopra elencate la gestione delle eccezioni .

/***************************************************************************

******* * THIS SOFTWARE IS COPYRIGHT STEVEN MORRIS 2002. ALL RIGHTS

RESERVED * THIS SOFTWARE IS FREE FOR NON COMMERCIAL USE FOR THE

PURPOSE OF LEARNING *MHP. ANY USE FOR OTHER PURPOSES IS

PROHIBITED UNLESS WRITTEN AGREEMENT * IS OBTAINED. *

DISTRIBUTION OF THIS CODE IS PROHIBITED */

// Import the HAVi UI classes that we need for this

import org.havi.ui.HScreen;

import org.havi.ui.HBackgroundDevice;

import org.havi.ui.HBackgroundConfiguration;

import org.havi.ui.HBackgroundImage;

import org.havi.ui.HStillImageBackgroundConfiguration;

import org.havi.ui.HConfigurationException;

import org.havi.ui.HPermissionDeniedException;

import org.havi.ui.HBackgroundConfigTemplate;

// Since some of the graphics configuration requires scarce resources, we

// need to use the DAVIC resource notification API import

org.davic.resources.*;

// We need these (under some circumstances) to let our background be

seen import javax.tv.service.selection.*;

import javax.tv.media.AWTVideoSizeControl;

import javax.tv.media.AWTVideoSize;

import java.awt.Rectangle;


/** * This class handles the display of background images in an easy-to *

use way. Setting this up can be quite complex, and so in the case * we've

relegated it to a separate class to make it a little easier to * understand. */

class BackgroundController implements

org.davic.resources.ResourceClient{



73

// The background device that we will use for displaying the image

private HBackgroundDevice backdevice;

// The configuration for that background device private

HStillImageBackgroundConfiguration backconfig;

/** * This method will initialise the video and graphics devices to allow *

them to display the background image. */

public boolean init(){

// We need to get the background device that we use for displaying the

image. To do

//this, we need to first decide which

// HScreen we will use. In this case (and most others), we will use

// the default one. HScreen screen = HScreen.getDefaultHScreen();

// Once we have that, we get the default background device for that

HScreen HBackgroundDevice backdevice =

screen.getDefaultHBackgroundDevice();

// Once we have a reference to the device, we can get a configuration for it.

// Get a configuration that we can use HBackgroundConfigTemplate

backgroundConfigurationTemplate = new HBackgroundConfigTemplate();

backgroundConfigurationTemplate.setPreference(HBackgroundConfigTempl

ate.FLICKER_FILTERING ,HBackgroundConfigTemplate.REQUIRED);

HBackgroundConfiguration backconfig; backconfig =

backdevice.getBestConfiguration(backgroundConfigurationTemplate);

// Can we reserve the device so that we can change the settings on it?

if (backdevice.reserveDevice(this)){

// If we can, we set the configuration of the background device to

// the one we got above - this is the default configuration for this device.

try{ backdevice.setBackgroundConfiguration(backconfig); }catch

(Exception ex){ System.out.println("Can't initialise the background

device");

// Release the device so that other applications can use it, if necessary.

backdevice.releaseDevice(); return false; }

// We need to check if we can put an image in the background in

// this configuration, since we can't do this in every configuration.

if(backconfig instanceof HStillImageBackgroundConfiguration){

// We can use this

this.backconfig = (HStillImageBackgroundConfiguration)backconfig;

this.backdevice = backdevice; return true;

}else{

// If we can't, we again release the device since it's no use to us.

backdevice.releaseDevice(); } } return false; }

/** * Free the resources we needed to display background images. * Some

implementations leave the image there, but there is an explicit * warning

in the MHP specification that this may not happen on all *

implementations. If you want to be sure that your image is still * visible,



74

don't do this. */

public void dispose(){

// Check if we have something to dispose of if (backdevice != null){

// RZlease the device and clear any references

backdevice.releaseDevice();

backdevice = null; backconfig = null; } }

/** * Display a background image */

public void display(String filename){

// Check we have the resources we need to display a background image

if(backconfig != null) {

// Create a new background image. The image is loaded from the

// filename that we pass in.

HBackgroundImage backimage = new HBackgroundImage(filename);

// Now display the image. This can throw several exceptions, so we

// enclose it in a 'try' block

try { backconfig.displayImage(backimage); }

catch (java.io.IOException ioe) {

// Ignore it, but print a message to tell the user what's happened.

System.out.println("Can't display background image - IO exception");

ioe.printStackTrace(); } catch (HPermissionDeniedException hpde) {

// We don't have permission to displayan image. We just ignore it.

System.out.println("Can't display background image - permission denied");

} catch (HConfigurationException hce) {

// We don't have permission to displayan image. We just ignore it.

System.out.println("Can't display background image - configuration

exception"); hce.printStackTrace(); } } }

Implementazione metodi di org.davic.resource:

/**************************************************************************

*

* These methods are inherited from the ResourceClient interface and are

used

* to tell the application when it has lost access to its resources (or

* when it is about to lose access to them). This gives the application a

* chance to clean up when it loses access to a resource, and gives it a

* chance to handle things gracefully. */

/** * This method gets called when the resource manager requests that we

give

* up a resource. We can refuse to do so, and that's what we do in this

* case (even though we shouldn't). */

public boolean requestRelease(ResourceProxy proxy, Object requestData) {

return false; }



75

/** * This method gets called when the resource manager informs us that

we must

* release a resource */

public void release(ResourceProxy proxy) {

// release control of the background device backdevice.releaseDevice(); }

/**

* This method gets called when the resource manager tells us we've

* lost access to a resource and we should clean up after ourselves. */

public void notifyRelease(ResourceProxy proxy) {

// release control of the background device. Even though we don't

// have control of it, this makes sure everything is synchronized.

backdevice.releaseDevice(); }

L’ultima cosa da aggiungere per quanto riguarda la gestione di questo livello è che, per rendere visibile il background, bisognerà ridimensionare o nascondere del tutto il livello superiore, ovvero il video layer. Trascurando la gestione del primo livello si possono implementare interfacce usando il livello grafico e come sfondo avranno la trasmissione corrente del canale dove si è sintonizzati.

3.4.2 Video layer La gestione del video layer è molto importante non solo per l’aspetto estetico della nostra interfaccia grafica. Non dobbiamo dimenticare, che il broadcaster ha si interessi a fornire l’applicazione MHP, ma si deve preoccupare anche della trasmissione che sta andando in onda. Mentre in una fase iniziale, nelle prime applicazioni, si preferiva ridimensionare il video e spostarlo in modo da non sovrapporsi a menù, pulsanti etc. ora la tendenza e di lasciarlo invariato il più possibile, usando trasparenze o sovrapposizioni di grafica temporanee, in modo da distogliere il meno possibile l’attenzione del telespettatore dalla trasmissione. Comunque ci sono casi in cui l’applicazione può pretendere e merita tutta l’attenzione dell’utente, basta pensare all’inserimento dati o alla conferma di un movimento in una applicazione e-banking per esempio. Quindi è bene alternare fasi, come la navigazioni di menù, dove il video sia in primo piano e altre in cui venga eliminato o ridotto. Per realizzare tutto ciò ci vengono in aiuto le classi javaTV della Sun, ecco un esempio di due metodi per nascondere o ridimensionare e posizionare il video tratti dalla classe “BackgroundController”, creata da Steve Morris.



76

import javax.tv.service.selection.*;

import javax.tv.media.AWTVideoSizeControl;

import javax.tv.media.AWTVideoSize;

import java.awt.Rectangle;


/** * Hide the video that may be obscuring our background */

public void hideVideo(XletContext context) {

// The background may be hidden by the video when the Xlet starts up. To

// solve this, we have to do two things:

// 1) stop the video

// 2) resize the video so that we can see the app underneath it. This is

// not always necessary, but some emulators (xletview, I'm looking at

you)

// don't hide the video when you stop it

// Get a reference to the JavaTV ServiceContextFactory

ServiceContextFactory factory; factory =

ServiceContextFactory.getInstance();

// From this, we can get a reference to the parent

// service context of our Xlet. To do this, we need a

// reference to our Xlet context. It's times like this

// that show why your application should always keep a

// reference to its Xlet context

ServiceContext myContext = null; try { myContext =

factory.getServiceContext(context); } catch (Exception e) {

e.printStackTrace(); }

if (myContext != null) {

// ServiceContentHandler objects are responsible for

// presenting the different parts of the service. This

// includes the media components

ServiceContentHandler[] handlers; handlers =

myContext.getServiceContentHandlers();

for(int i=0; i < handlers.length ; i++) { if (handlers[i] instanceof

ServiceMediaHandler) {

// This is a Player for part of the service, since

// ServiceMediaHandler objects are instances of JMF

// Player objects javax.media.Player p = (javax.media.Player)

handlers[i];

// this may be all we need to do in order to see our background...

p.stop();

p.deallocate();

// ...but some emulator require more

AWTVideoSizeControl awtVideoSizeControl; awtVideoSizeControl =

(AWTVideoSizeControl)

p.getControl("javax.tv.media.AWTVideoSizeControl");



77

// in this case, we set the size of the video to be 0, but we could set it

// to display on part of the screen awtVideoSizeControl.setSize(new

AWTVideoSize(new Rectangle(0, 0, 720, 576), new Rectangle(0,0,0,0)));

} } }else { System.out.println("Can't get our service context. May not be

able to " + "resize the video, so our background may not be visible"); } }

public void resizeVideo(XletContext context,int x,int y,int l,int h) {

// The background may be hidden by the video when the Xlet starts up. To

// solve this, we have to do two things:

// 1) stop the video

// 2) resize the video so that we can see the app underneath it. This is

// not always necessary, but some emulators (xletview, I'm looking at

you)

// don't hide the video when you stop it

// Get a reference to the JavaTV ServiceContextFactory

ServiceContextFactory factory; factory =

ServiceContextFactory.getInstance();

// From this, we can get a reference to the parent

// service context of our Xlet. To do this, we need a

// reference to our Xlet context. It's times like this

// that show why your application should always keep a

// reference to its Xlet context ServiceContext myContext = null; try {

myContext = factory.getServiceContext(context); } catch (Exception e) {

e.printStackTrace(); }

if (myContext != null) {

// ServiceContentHandler objects are responsible for

// presenting the different parts of the service. This

// includes the media components ServiceContentHandler[] handlers;

handlers = myContext.getServiceContentHandlers();

for(int i=0; i < handlers.length ; i++) { if (handlers[i] instanceof

ServiceMediaHandler) {

// This is a Player for part of the service, since

// ServiceMediaHandler objects are instances of JMF

// Player objects

javax.media.Player p = (javax.media.Player) handlers[i];

// this may be all we need to do in order to see our background...

// ...but some emulator require more AWTVideoSizeControl

awtVideoSizeControl; awtVideoSizeControl = (AWTVideoSizeControl)

p.getControl("javax.tv.media.AWTVideoSizeControl");

// in this case, we set the size of the video to be 0, but we could set it

// to display on part of the screen awtVideoSizeControl.setSize(new

AWTVideoSize(new Rectangle(0, 0, 720, 576), new Rectangle(x,y,l,h))); }

} }else {

System.out.println("Can't get our service context. May not be able to " +

"resize the video, so our background may not be visible"); } }



78

Prima di ridimensionare o eliminare addirittura il video layer è bene aver impostato una immagine nel background layer come descritto nel paragrafo precedente, onde intercorrere a videate nere o addirittura alla non visualizzazione del livello grafico che ora andremo a trattare. 3.4.3 Graphics layer Il livello grafico è supportato da diversi package messi a disposizione dallo standard; uno dei fondamentali è Havi 1.1. In tale package il container di più alto livello in una Xlet è rappresentato dalla classe org.havi.ui.HScene, che concettualmente è equivalente a java.awt.Window o java.awt.Frame ma con caratteristiche specifiche per i decoder digitali, ne riportiamo i metodi principali:



79

Tab. 3.2 – Method Summary per la grafica

La classe factory che ci permette di richiedere l'unica istanza della HScene è fornita dallo stesso package e si chiama org.havi.ui.HSceneFactory. MHP supporta anche le classi AWT contenute nella versione 1.1.8 del JDK Sun ma spesso è possibile trovare un equivalente nel package Havi e che quindi dovrebbe essere preferita (es: org.havi.ui.HContainer è più specifica per MHP di java.awt.Container). Oltre ad Havi e AWT è possibile utilizzare anche un package specifico DVB org.dvb.ui dove è possibile trovare classi di utilità come la DvbColor che permette di gestire anche le trasparenze



80

tramite il parametro alpha non presente nella classe java.awt.Color. Data l’importanza vediamone un tipo di costruttore: DVBColor (int r, int g, int b, int a) dove r,g,b sono i colori primari red, green, blue e “a”- alpha è la trasparenza, tutti e quattro i parametri hanno un range da 0 a 255. Non tutti i tipi di decoder MHP gestiscono le trasparenze in questo modo, ma lo standard garantisce almeno 3 livelli: 0 % (opaco), 100 % (completamente trasparente), 30 % di trasparenza. Il font di sistema supportato in MHP è il “Tiresias”, che deve essere disponibile almeno nelle seguenti dimensioni: 36 punti (Title) 31 punti (Subtitle) 26 punti (Body) 24 punti (Footnote) I formati grafici supportati sono: png, jpg, gif e mpg (I-Frame). Vediamo un esempio di codice che recupera l'istanza di HScene e ci posiziona un HContainer e un HText.

HSceneFactory hsf = HSceneFactory.getInstance(); HScene scene =

hsf.getFullScreenScene(

HScreen.getDefaultHScreen().getDefaultHGraphicsDevice());

// risoluzione a schermo pieno

scene.setSize(720,576); scene.setLayout(null); HContainer cont = new

HContainer(50,50,650,500);

HText text = new HText("Casella di testo!",160, 200, 300, 60, new

Font("Tiresias", Font.PLAIN, 26),Color.black,Color.white, new

HDefaultTextLayoutManager());

cont.add(text);

scene.add(cont);

scene.setVisible(true);

scene.repaint();

Un altro oggetto molto utile nella creazione di un’interfaccia è HIcon che permette di caricare un immagine e visualizzarla, per esempio per creare un bottone, in dettaglio: HIcon (java.awt.Image image, int x, int y, int width, int height) utilizzando java.awt.Toolkit ecco il nostro bottone: bottone = new HIcon(Toolkit.getDefaultToolkit().getImage("bottone.jpg"), 50, 100,

140, 30);

Per dare facilmente l’effetto che il pulsante venga premuto si possono creare due oggetti HIcon con le rispettive immagini, pulsante rilasciato/pulsante premuto, posizionati sulle stesse coordinate e agire con il metodo setVisible(true/false) per nascondere l’uno e visualizzare l’altro.



81

3.5 Gestione degli eventi del telecomando La gestione del telecomando è banale per chi conosce Java, si basa sugli ascoltatore di eventi; in MHP si possono usare i package org.havi.ui.event che necessita del focus di un’ oggetto grafico oppure org.dvb.event. Iniziamo dal primo caso, nel package sono definite le costanti che corrispondono al codice restituito dal metodo getKeyCode di java.awt.event.KeyEvent ad ogni pressione di un tasto. L’ascoltatore degli eventi va aggiunto nel metodo initXlet: scene.addKeyListener((KeyListener)this) e rimosso nel metodo destroyXlet: scene.removeKeyListener((KeyListener)this). Come mostrato in Figura 3.6 gli eventi associati alla pressione dei un tasto del telecomando definiti nell'MHP sono solamente quelli numerici, le frecce di navigazione, il tasto “OK”, il tasto teletext e i quattro tasti colorati (rosso,verde,giallo,blu).

Fig. 3.6 - Input event in MHP

Da notare che lo standard MHP non definisce eventi per i tasti “EXIT” e “BACK” che sono presenti sulla quasi totalità dei decoder e comunque gestiti da org.havi.ui.event.HRcEvent ma potrebbero generare eventi non-standard e non sempre coerenti sui diversi apparecchi. Vediamo ora un esempio di codice necessario per l’implementazione del primo metodo, il codice seguente deve risiedere nella classe principale della Xlet.

public void keyPressed (KeyEvent key) {

int pulsantePremuto = key.getKeyCode();

switch(pulsantePremuto){



82

//Tastierino numerico

case KeyEvent.VK_0:

case KeyEvent.VK_1:

case KeyEvent.VK_2:

case KeyEvent.VK_3:

case KeyEvent.VK_4:

case KeyEvent.VK_5:

case KeyEvent.VK_6:

case KeyEvent.VK_7:

case KeyEvent.VK_8:

case KeyEvent.VK_9:

//Tasti colorati:

case HRcEvent.VK_COLORED_KEY_0: //rosso

case HRcEvent.VK_COLORED_KEY_1: //verde

case HRcEvent.VK_COLORED_KEY_2: //giallo

case HRcEvent.VK_COLORED_KEY_3: //blu

//Tasti direzionali:

case HRcEvent.VK_UP:

case HRcEvent.VK_DOWN:

case HRcEvent.VK_RIGHT:

case HRcEvent.VK_LEFT:

case HRcEvent.VK_ENTER: //OK

//Vengono passati gli eventi.

interfaccia.keyPressed(key);

break;

//Alla pressione del tasto EXIT del telecomando si

//richiama il metodo destroyXlet, per fermare la xlet.

case HRcEvent.VK_ESCAPE:

try{ destroyXlet(true); }

catch (XletStateChangeException xsce){

System.out.println("Premuto tasto EXIT "+xsce.toString()); }

break;

default:

break; } }

public void keyTyped(KeyEvent ignored) { }

public void keyReleased(KeyEvent ignored) { }

Essendo il primo metodo ampiamente documentato e conosciuto vediamo nel dettaglio quello specifico del DVB. Tale meccanismo è consigliabile rispetto ad AWT perché permette un uso più oculato e collaborativo nella gestione degli eventi. Infatti rispetto ad AWT dove la registrazione degli eventi è esclusiva e comprende tutti gli eventi



83

possibili, nel modello dvb è possibile registrarsi per la notifica dei soli eventi a cui si è realmente interessati. Le classi principali di questo package sono la EventManger e la UserEventRepository che gestiscono rispettivamente la registrazione degli eventi e il repository degli eventi a cui si è interessati.

UserEventRepository repository = new

userEventRepository("UserRepository"); repository.addAllColourKeys();

EventManager manager = EventManager.getInstance();

// this rappresenta la classe

listener manager.addUserEventListener(this, repository);

Questo approccio ha l'ulteriore vantaggio di non imporre alla Xlet di richiedere il focus tramite la HScene (come prevede il modello awt sui Component) risulta quindi essere l'unico approccio da seguire in tutte quelle applicazioni in cui si vogliono ricevere eventi del telecomando ma non si dispone una GUI.

3.6 Canale di ritorno L’infrastruttura trasmissiva per il digitale terrestre consente l’invio broadcast di contenuti televisivi, radio ed informatici (es. dati) a ricevitori DTT quali: televisori associati ad un “decoder” supplementare o Set Top Box, televisori digitali corredati di decoder interno, altri apparecchi (sintoamplificatori, videoregistratori, sistemi AV compatti, etc.) che incorporano un sintonizzatore DTT. A ciascun “programma” (televisivo, radio, informatico) il Content Provider può associare un servizio informazioni sul programma, un servizio Teletext tradizionale, un servizio “super Teletext” (“Enhanced Broadcasting”) supportato dallo standard “mhp” (Multimedia Home Platform); quest’ultimo, infatti, realizza e presenta sullo schermo del televisore “pagine” contenenti testo e grafica al cui interno è possibile “navigare” in modo molto simile ad Internet. Se poi il ricevitore DTT è corredato da un modem (analogico, ISDN o xDSL), connettendosi ad Internet o ad altre reti di telecomunicazioni, la DTT diventa lo strumento attraverso il quale sviluppare servizi interattivi più o meno estesi (da forme minimali di “televoto” realizzato collegandosi a numeri telefonici o a indirizzi Internet corrispondenti al voto che si vuole esprimere, fino all’impiego di sofisticate applicazioni di commercio elettronico, e-government, fornitura di servizi Video On Demand, etc). Più in generale, l’interattivitàestesa è destinata all’impiego di servizi Internet.



84

Fig. 3.5 - Scenario canale di ritorno

Tutte tali possibilità (che si comprendono meglio utilizzando un ricevitore) sono ampiamente chiarite già nell’introduzione dallo Standard ETSI ES 201 812 V1.1.1 (2003-12) relativo e Digital Video Broadcasting (DVB) e Multimedia Home Platform (MHP) Specification 1.0.3 , capitolo 0, paragrafo 0.2: “… At the beginning the following application areas are considered - Enhanced Broadcasting, Interactive Broadcasting and Internet Access. Enhanced Broadcasting combines digital broadcast of audio/video services with downloaded applications which can enable local interactivity. It does not need an interaction channel. The application area Interactive Broadcasting enables a range of interactive services associated or independent from broadcast services. This application area requires an interaction channel. The application area of Internet Access is intended for the provisioning of Internet services. It also includes links between those Internet services and broadcast services. …” In pratica, il protocollo mhp è costituito da una raccolta di “metodi java” (programmi di base) che consentono di accedere alle funzioni di base del ricevitore DTT e di far partire automaticamente o manualmente, utilizzando il telecomando, le applicazioni java trasmesse dal Content Provider Broadcaster. Queste “applicazioni Java” sono a tutti gli effetti dei programmi informatici che utilizzano, in luogo di un personal computer o di un PDA, le capacita di



85

elaborazione e lo schermo del ricevitore DTT. Pertanto, le applicazioni di “Enhanced Broadcasting” costituiscono il presupposto per il lancio di applicazioni di “Interactive Broadcating”, che consentono il lancio delle applicazioni di “Internet Access” realizzate attraverso l’uso di reti PSTN, ISDN o xDSL (si prevede che la prossima generazione di Set Top Boxes incorpori anche tecnologia WiFi). Si noti che una volta attivato il “canale di interattività”, il ricevitore DTT può diventare autonomo dalle applicazioni broadcast e, per esempio, accedere, puramente via Internet. ad un servizio “pay per view” o “pay to download” via xDSL. Sempre attraverso il “canale di interazione”, il ricevitore può continuare a ricevere nuovi programmi java che sviluppano nuove funzionalità. Di fatto, nel corso della attivazione, l’utente può configurare nel ricevitore DTT il numero di telefono, il codice utente e la password fornitagli dal proprio fornitore di accesso ad Internet, ma i servizi di “Enhanced Broadcasting” e “Interactive Broadcating” possono imporre al ricevitore DTT interattivo di utilizzare per l’“Internet Access” numero di telefono, codice utente e password diversi da quelli predefiniti dall’utente. In altre parole, l’accesso alle applicazioni di “Enhanced Broadcasting” rappresenta una insuperabile barriera alla realizzazione e alla fornitura di servizi della società dell’informazione diretti a quel 60% della popolazione che non usa il computer, ma che dopo lo switch off previsto per il 31 dicembre 2008, userà un televisore DTT. Accordi tra content provider su piattaforma DTT (che hanno il potere di associare al programma televisivo o radiofonico opportune applicazioni) e alcuni operatori di rete fissa, potrebbero avere l’effetto di una totale esclusione da tale mercato dei restanti operatori di rete fissa. Il pericolo è particolarmente elevato nel caso di Telecom Italia che, attraverso Telecom Italia Media, dispone già oggi di un accesso ai servizi di “Enhanced Broadcasting” e “Interactive Broadcating” su piattaforma DTT, ma non è da sottovalutare l’ipotesi che anche gli altri operatori di rete DTT possano seguire politiche discriminatorie. In assenza di adeguate misure volte a garantire l’accesso alle applicazioni di “Enhanced Broadcasting” (che, si è visto, costituiscono il presupposto per il lancio di applicazioni di “Interactive Broadcating”), l’accesso al “canale di ritorno” del decoder a condizioni oggettive e non discriminatorie tra i diversi operatori di telecomunicazioni e fornitori di accesso ad Internet e ad assicurare l’ interoperabilità dei servizi, si potrebbe assistere ad inquietanti fenomeni di “walled garden”, consistenti in un’offerta integrata di contenuti Internet (es. Video On Demand, e-commerce, etc…), promossi per il tramite delle applicazioni di Enhanced ed Interactive Broadcasting, accessibili mediante la DTT (sfruttando il canale di ritorno del decoder)



86

esclusivamente per il tramite di uno specifico fornitore di accesso e contenuti Internet predeterminato dal fornitore della rete e/o del servizio DTT, così impedendo l’accesso degli utenti del servizio DTT ai servizi/contenuti/siti dei content providers non predeterminati dal gestore della rete e/o del servizio DTT, che verrebbero ad essere relegati in una sorta di “universo recintato”, a scapito della concorrenza, del pluralismo e, da ultimo, a danno degli utenti finali.

3.7 I protocolli supportati Per comprendere appieno le potenzialità del canale di ritorno, che si possono utilizzare, partiremo dall’analisi dei protocolli supportati da MHP che sono mostrati in figura 3.6.

Fig. 3.6- Protocolli canale di ritorno

3.7.1 Livello 1: Fisico A livello fisico (Livello 1), si definiscono le caratteristiche del mezzo trasmissivo, del tasso di trasmissione e gli schemi di codifica su cui avverrà la comunicazione. I ricevitori DTT attualmente in commercio almeno per quanto riguarda quelli interattivi, sono dotati al loro interno di un modem 56K che permette di aprire una connessione su canale bidirezionale sfruttando la linea telefonica commutata. Tuttavia il canale di ritorno via modem analogico (PSTN) presenta i seguenti problemi: banda disponibile ridotta ; impossibilità di uso contemporaneo del servizio di fonia sulla stessa linea telefonica; canale



87

non always-on, con conseguente necessità di effettuare eventualmente diverse aperture e chiusure di connessione durante una sessione di utilizzo del servizio interattivo; tempi di attesa dovuti alla procedura di connessione; costi di utilizzo basati sulla durata della connessione a circuito; canale con flusso di dati bilanciato, proprietà non utile in molte applicazioni. Lo standard PSTN (definito nelle specifiche ETSI ETS 300 801) è sicuramente uno standard affermato e ancora di largo consumo, ma che limita enormemente quelle che sono le possibilità di creare applicativi di alto livello. Uno dei vantaggi di questa scelta è però la garanzia che vi sia un più vasto numero di utenti che può, data la ormai affermata tecnologia e la vasta disponibilità sul territorio, sfruttare i servizi interattivi messi a disposizione sul digitale terrestre. Il fatto che questa tecnologia sia accessibile da quasi la totalità della popolazione è un fattore da non sottovalutare per poter rendere il DTT una tecnologia aperta a tutti. In futuro con una prevista evoluzione dei servizi messi a disposizione, si inizieranno a vedere sul mercato STB di fascia media con supporto per linea ISDN oppure di fascia alta con connessione a banda larga ADSL, anche se ci sarà ancora molto da aspettare dati i costi attualmente più elevati rispetto a quelli di fasci bassa. L’ ultima ipotesi è certamente la più interessante, perché da la possibilità di avere una connessione sempre attiva, cosa non permessa dai normali ricevitori con modem PSTN che chiudono la chiamata al Centro Servizi dopo un tempo prestabilito di inattività, ma soprattutto darà la possibilità di portare sul digitale terrestre applicazioni che ora sono riservate solo ai PC su Internet. 3.7.2 Livello 2: PPP A livello di collegamento (Livello 2) si trova il protocollo PPP (Point-to-Point Protocol) che è ad oggi il protocollo più utilizzato per il collegamento a Internet degli host residenziali tramite doppino telefonico. Standardizzato in RFC 1661 e RFC 2152 . Il PPP gestisce il riconoscimento degli errori, supporta molti protocolli, permette che gli indirizzi IP siano stabiliti al momento della connessione e supporta l’autenticazione. I vantaggi del PPP sono: i frame vengono suddivisi in maniera tale da garantire una non ambigua separazione tra un frame e quello successivo; possiede un protocollo di controllo di collegamento per la gestione delle linee che prende il nome di LCP (Link Control Protocol); le opzioni del livello di rete sono negoziate in maniera indipendente dal protocollo che



88

si utilizzerà a livello di rete. Si avrà quindi un diverso NCP (Network Control Protocol) per ogni livello rete supportato. Nel nostro caso vediamo come il STB riesce ad acquisire un indirizzo IP dal Centro Servizi per poter poi comunicare con esso ed accedere ai servizi interattivi messi a disposizione. Innanzi tutto si esegue la chiamata verso il CS ad un numero che può essere univoco per tutto il territorio impostato di default dall’utente oppure settato dalla Xlet. Dopo che il modem del CS ha risposto e stabilito una connessione a livello fisico nel nostro caso su linea commutata, il STB manda al router una serie di pacchetti LCP inseriti nel campo Payload di uno o più frame PPP. I pacchetti inviati andranno a selezionare i parametri PPP da utilizzare nella comunicazione. Una volta selezionati i parametri, si passa all’invio dei pacchetti NCP per configurare il livello rete. Nel nostro caso il ricevitore vuole eseguire un insieme di protocolli TCP/IP e quindi necessita di ottenere un indirizzo IP. Ogni CS avrà a disposizione un set di indirizzi IP da assegnare e ne verrà assegnato dinamicamente uno a chi ne fa richiesta, una volta eseguita la connessione e per tutta la sua durata. A questo punto il nostro STB e formalmente un host Internet e può inviare e ricevere pacchetti IP proprio come se fosse connesso fisicamente con CS. La disconnessone avviene quando NCP sgancia la connessione a livello di rete e va cosi a liberare l’indirizzo IP. Quindi LCP sgancia la connessione del livello di collegamento e quindi la PPP ed infine il STB ordina al modem interno di liberare la linea telefonica rilasciano la connessione a livelli fisico. 3.7.3 Protocollo di rete: IP Il livello di rete, è occupato dal protocollo IP (Internet Protocol), che nel suo datagram incapsula tra i numerosi campi previsti, l’indirizzo IP del server di destinazione, cioè quello del Centro servizi e quello del client, quindi quello assegnato dal CS stesso al momento dell’autenticazione in maniera dinamica. Il suo compito è quello di garantire che i pacchetti arrivino dalla sorgente, nel nostro caso il STB, alla destinazione il CS, indipendentemente dalla presenza di reti intermedie durante il suo percorso e indipendentemente dal fatto che più utenti stiano utilizzando nello stesso momento l’applicazione per mettersi in contatto con il CS. In pratica sarà il livello di trasporto che riceverà il flusso di dati ed andrà a frammentarlo in datagram. Ogni datagram viene poi trasmesso e frammentato ulteriormente durante il percorso, una volta che tutti i pezzi hanno raggiunto la destinazione, vengono riassemblati dal livello di rete nel datagram di partenza. Il datagram riassemblato viene poi passato al livello trasporto, che lo



89

inserisce nel flusso di input del processo ricevente. Il protocollo IP supporta sopra di se i protocolli TCP e UDP entrambi previsti dalle specifiche MHP. 3.7.4 Protocolli di trasporto: TCP / UDP I protocolli di trasporto supportati sono sia il TCP che l’ UDP questi si differenziano principalmente per il fatto che il primo e orientato alla connessione mentre il secondo e sostanzialmente fondato sull’IP e non orientato alla connessione. Il TCP (Transmission Control Protocol) progettato per garantire connessioni affidabili, necessita di una entità di trasporto TCP, che va a gestire i flussi di dati TCP e si interfaccia con il livello IP. I datagram IP ricevuti che contengono dati TCP vengono passati all’entità TCP che ricostruisce il flusso originale di byte, precedentemente spezzettato dall’entità TCP del trasmettitore. Il livello IP non da garanzia sulla avvenuta consegna dei datagram; e quindi compito del TCP ritrasmetterli quando necessario. Un altro compito del TCP è riassemblare i messaggi nella sequenza corretta tutte cose che da solo IP non può fare. Il TCP si basa su punti accesso chiamati socket, sia il client (STB) che il server (CS) ne devono possedere uno univoco. Ogni socket e caratterizzato da un indirizzo IP che identifica l’host e da un numero di 16 bit detto “porta”, per esempio l'HTTP comunica sulla porta 80. Il protocollo UDP (User Data Protocol) è un protocollo non orientato alla connessione, è usato per spedire datagram IP, senza dover stabilire una connessione, in maniera più rapida ma senza garantire il controllo degli errori e del flusso dei pacchetti. 3.7.5 Hypertext Transfer Protocol (HTTP) Lo standard HTPP (Hyper Text Tranfer Protocol) è il protocollo che sta alla base del WWW. Le specifiche MHP incentivano l'uso di questo protocollo come possiamo vedere dalla figura 3.2.1, questo perché il suo utilizzo da la possibilità di trasferire informazioni di varia natura, come file di testo, immagini, ecc.. L'HTTP è un protocollo orientato alla comunicazione tra un client ed un server. Come si può vedere anche in figura esso è supportato dal TCP, ma nonostante questo resta comunque un protocollo “senza stato”, quindi ogni transazione viene trattata in maniera indipendente dalle altre almeno per quanto riguarda l'HTTP 1.0. Viene quindi creata una connessione TCP ogni volta che il STB dovrà interagire con il Centro Servizi per lo scambio dei dati. I terminali MHP di nuova generazione sono nati per supportare sia HTTP 1.0 (IETF RFC 1945[92]) che HTTP1.1 (IETF RFC 2616[40]) con



90

alcune considerazioni del caso soprattutto per quanto riguarda le connessioni di tipo keep-alive. I terminali MHP e quindi le applicazioni che implementano i profili Interactive TV Profile e Internet Access Profile, che sfruttano il protocolli HTTP 1.0/1.1 dovranno supportare connessioni di tipo persistente. L' HTTP 1.1 è stato introdotto per colmare le lacune del vecchio HTTP1.0 in quanto una delle caratteristiche fondamentali è quella di stabilire una sola connessione TCP per tutta la durata della comunicazione. Il fatto che nella maggior parte dei casi il terminale MHP comunicherà per tutta la durata della connessione con un unico ISP, il nostro Centro Servizi, è opportuno stabilire una connessione sempre attiva per tutta la durata della comunicazione evitando problemi di congestione della rete. Per stabilire una connessione di tipo persistente i terminali MHP che sfruttano il protocollo HTTP1.0 dovranno inserire all'interno del messaggio HTTP nel campo Connection del General-Header il token Keep-Alive:

Il server HTTP che si vede arrivare un messaggio di richiesta di connessione Keep-Alive risponderà instaurando una connessione persistente. Se si fa questo,il campo Keep-Alive del General-Header, del messaggio HTTP, conterrà il tempo durante il quale il trasmettitore mantiene la connessione aperta in attesa della richiesta successiva, oppure il numero massimo di richieste aggiuntive che sono consentite sulla connessione in corso. Il campo Keep-Alive sarà composto come sotto:

dove la notazione ''0#'' significa che i parametri potranno essere ripetuti 0 o più volte e saranno separati da '','' se il campo ne contiene più di uno. Se i terminali MHP dovranno comunicare con un server proxy HTTP1.0 non sarà necessario inviare il token Keep-Alive, questo perché un proxy HTTP1.0 non ubbidisce alle regole dell' HTTP1.1 per fare il parsing del campo Connection. Questo significa che si dovrà impedire ai terminali MHP di richiedere connessioni sempre attive quando questi devono comunicare con server proxy che non ne potrà supportare le funzionalità. I server di tipo HTTP1.1 che si basano su connessioni persistenti dovranno supportare anche l' HTTP1.0 per richieste da parte di terminali MHP che lavorano con protocollo HTTP1.0 e che cercheranno comunque di instaurare connessioni sempre attive utilizzando il token Keep-Alive.



91

3.7.6 Secure Hypertext Transfer Protocol (HTTPS) Nei casi in cui si richiede un canale di comunicazione protetto con il CS, le specifiche MHP consigliano l'uso del protocollo HTTPS. Questo protocollo è sostanzialmente basato sull'HTTP ma affianca ad esso il protocollo TLS (Transport Layer Security). TLS 1.0 è molto simile a SSL 3.0 anche se non è compatibile con questo. Lo scopo di TLS è quello di permettere una comunicazione sicura tra due applicazioni, fornendo al flusso di dati servizi di autenticazione, integrità e riservatezza. Il profilo MHP non implementa l'intero TLS ma solamente una parte degli algoritmi di cifratura previsti tra cui in particolare : • RSA () • MD5 • SHA-1 • DES 3.7.7 Servizi Specifici Qualora si trovasse la necessita di supportare da parte dei ricevitori protocolli proprietari per il canale di ritorno lo standard MHP lascia ai costruttori la possibilità di definirne alcuni e di portarli sulle piattaforme. Ad oggi tutti i ricevitori STB in commercio utilizzano protocolli di uso comune che garantiscono più robustezza, integrità e maggiore possibilità di integrazione alla rete Internet per una prospettiva futura di accesso a contenuti Web con l'introduzione del profilo “Internet Access Profile”.

3.8 Gestione della connessione Indipendentemente dal tipo di modem di cui è provvisto il set top box, le connessioni sono gestite dal package Org.dvb.net.rc in questo paragrafo andremo a vedere nel dettaglio le classi di questo package e cercheremo di capire come queste interagiscono tra di loro per poter poi essere utilizzate per stabilire una connessione con un ISP remoto. Successivamente daremo uno sguardo agli altri package, java.net e java.io, che verranno utilizzati una volta che la connessione è stabilita. 3.8.1 Utilizzare il canale di ritorno: il package org.dvb.net.rc Tra i tre profili che MHP introduce sia “Interactive Broadcast” che “Internet Access”, includono il supporto per utilizzate il canale di ritorno sui STB. In base al tipo di ricevitore che stiamo utilizzando il canale di ritorno può assumere diverse forme in base alla fascia di appartenenza, anche se ad oggi quella più comune è il modem PSTN, che garantisce: una maggiore reperibilità sul territorio, quindi un bacino



92

di utenza più ampio e semplicità di installazione, anche se porta dei limiti che come abbiamo gia visto sono molto “pesanti”. I STB quando stabiliscono una connessione con canale di ritorno non fanno altro che appoggiarsi al protocollo IP del livello di rete e come molte applicazioni Java che fanno uso di una connessione remota, anche le nostre Xlet si appoggeranno alle classi del package java.net, con alcune restrizioni del caso. Le specifiche MHP 1.0.x richiedono supporto per HTTP1.0 e DNS su canale di ritorno al di sopra del TCP, ma ogni altro protocollo è opzionale, questo lascia un po’ di liberta anche se può portare a dei mal funzionamenti, sarà quindi compito del programmatore fare le opportune verifiche. Con MHP 1.1 le specifiche aggiungono il supporto per HTTPS un protocollo per connessioni sicure che unisce l’ HTTP con i certificati TLS. Le specifiche non aggiungono niente per quanto riguarda il supporto ad altri protocolli come FTP o SMTP. Anche se l’ultimo è sicuramente necessario per la creazione di un client e-mail. Una considerazione va fatta per quanto riguarda la gestione della connessione, in quanto le API java.net assumono che una connessione permanente sia eseguibile, è questo può diventare un problema da non sottovalutare specialmente quando il nostro STB usa un modem PSTN. In certi casi non ci dovremo curare di gestire la connessione, sarà il ricevitore a connettersi automaticamente all’ISP di default, dovremmo solo preoccuparci di utilizzare correttamente le classi java.net.socket e java.net.URLConnection per fare riferimento ad un file remoto. In maniera simile il ricevitore dopo un periodo di inattività andrà a disconnettere automaticamente il canale di ritorno, questo porta ad una sorta di sistema di sicurezza da xlet maligne che però è facilmente aggirabile. 3.8.2 Interfacce per il Canale di Ritorno Ogni tipo di interfaccia supportata dai STB è rappresentata da un’istanza della classe RCInterface :

public class RCInterface extends java.lang.Object {

public static final int TYPE_PSTN = 1;

public static final int TYPE_ISDN = 2;

public static final int TYPE_DECT = 3;

public static final int TYPE_CATV = 4;

public static final int TYPE_LMDS = 5;

public static final int TYPE_MATV = 6;

public static final int TYPE_RCS = 7;

public static final int TYPE_UNKNOWN = 8;



93

public static final int TYPE_OTHER = 9;

private int type;

private int dataRate;

protected RCInterface() { }

public int getType() { return this.type; }

public int getDataRate() { return this.dataRate; } }

Con questa classe è possibile modellare nome, velocità in Kbps e tipo di interfaccia da utilizzare per ottenere una connessione IP. Come possiamo vedere questa classe definisce un insieme di costanti dove ognuna rappresenta un tipo di canale di ritorno.

Tab. 3.1 – Costanti canale di ritorno Il metodo getType()ritorna un intero corrispondente al tipo di interfaccia a cui la classe ConnectionRCInterface fa riferimento. Mentre il metodo getDataRate() ritorna il massimo “data rate” dell’interfaccia a cui siamo connessi in questo momento, se nessuna interfaccia è connessa il ricevitore ci restituirà il valore dell’ultima interfaccia utilizzata oppure il valore –1 se non reperibile. 3.8.3 Acquisire l’interfaccia corretta Come abbiamo visto nelle specifiche MHP esiste più di un tipo differente di interfaccia, in base al supporto che implementa il canale di ritorno, questo rende necessaria la presenza di una classe che sia in grado di ottenere l’accesso a quella corretta e ne controlli l’utilizzo in



94

base al quello che dovrà fare la nostra xlet. A tal proposito e stata creata la classe RCInterfaceManager che ci fornisce alcuni metodi per controllare l’accesso a questo tipo di risorsa scarsa.

public class RCInterfaceManager implements

org.davic.resources.ResourceServer {

public static RCInterfaceManager getInstance();

public RCInterface[] getInterfaces();

public RCInterface getInterface(java.net.InetAddress addr);

public RCInterface getInterface(java.net.Socket s);

public RCInterface getInterface(java.net.URLConnection u);

public void addResourceStatusEventListener(

org.davic.resources.ResourceStatusListener listener);

public void removeResourceStatusEventListener(

org.davic.resources.ResourceStatusListener listener); }

La classe RCInterfaceManager mette a disposizione un metodo il getInstance() che viene innanzitutto utilizzato per ottenere un’istanza di se stessa da utilizzare nei passi successivi. Una volta che abbiamo ottenuto il riferimento a questa classe possiamo procedere con l’acquisire l’interfaccia appropriata, cosi con il metodo getIstances() ci viene restituito un array di RCIinterface in base ai permessi associati alla nostra applicazione e alla disponibilità di interfacce che il nostro ricevitore supporta. Questo array potrebbe risultare anche vuoto se la nostra applicazione non ha i permessi necessari per l’uso della risorsa magari perché viene identificata come maligna. Il metodo getInterfaces() ha tre varianti legate alla classe del package java.net che andremo ad utilizzare; java.net.URLConnection, java.net.Socket, java.net.InetAdress. Nei primi due casi il middleware del ricevitore assume che la connessione sia già attiva, questo perché sarà esso stesso che non appena nota la richiesta di connessione ad una URL o ad una Socket cerca di creare una connessione su linea di ritorno, e ritornerà l’interfaccia utilizzata per questa connessione. Nell’ultimo caso invece il middleware ritornerà l’interfaccia che dovremmo poi utilizzare per stabilire la connessione. Come ho gia detto i STB in commercio sono forniti solamente di modem PSTN e quindi i metodi appena citati riporteranno se ben formati sempre l’interfaccia ‘1’ o nulla se non presente, bisognerà tenere conto di questo per non incorrere in mal funzionamenti. Essendo il canale di ritorno una risorsa scarsa, questa classe come possiamo vedere dal codice, implementa l’interfaccia ResourceServer permettendo di associare un ResourceStatusListner



95

al nostro oggetto per informarlo sugli eventi che accadono alla risorsa. Gli eventi generati del tipo ResurceStatusEvents possono essere: RCInterfaceReservedEvent: Questo evento viene generato quando un’applicazione ha correttamente riservato una RCInterface, può essere generato anche quando un’altra entità del sistema ha riservato la risorsa rendendola cosi non più utilizzabile. RCInterfaceReleasedEvent: Viene generato quando un’applicazione che precedentemente aveva riservato una RCInterface ha poi deciso di rilasciare la risorsa chiamando il metodo release() della classe ConnectionRCInterface su quella interfaccia. Può essere generato anche da un’altra entità del sistema informando cosi l’applicazione che la risorsa è ora disponibile. 3.8.4 Stabilire la connessione Tra le interfacce per il canale di ritorno dichiarate nella classe RCInterface alcune rappresentano una connessione sempre attiva. Il middleware non tratta quindi tutti i tipi di interfacce in maniera uguale questo perché le connessioni sempre attive come possono essere TYPE_CATV o ADSL non vengono trattate come se fossero risorse scarse, semplicemente perché l’applicazione non ha bisogno di sapere a quale provider il canale di ritorno è connesso. La gestione della connessione e quindi completamente lasciata nelle mani del middleware che si occupa di tenerla sempre disponibile nel momento in cui l’applicazione ne fa richiesta, senza preoccuparsi di troppi dettagli. Questo però non accade con altri tipi di interfacce, come per esempio con un modem PSTN, in questo caso dovremo conoscere il numero di telefono dell’ISP a cui connettersi, prima di poter utilizzare la risorsa, oltre a dati come user e password. In base al service provider al quale ci si vuole connettere potrebbe succedere che un’applicazione sia abilitata a stabilire una comunicazione, mentre altre no per problemi di sicurezza, e ciò pone dei limiti ma anche dei vantaggi. La classe ConnectionRCInterface estende la classe RCInterface ed implementa l’interfaccia ResourceProxy , di seguito possiamo vedere i metodi di cui e composta.

public class ConnectionRCInterface extends RCInterface implements

org.davic.resources.ResourceProxy {

public boolean isConnected();

public float getSetupTimeEstimate();

public void reserve( org.davic.resources.ResourceClient c, java.lang.Object

requestData) throws PermissionDeniedException;



96

public void release();

public void connect() throws java.io.IOException,

PermissionDeniedException;

public void disconnect() throws PermissionDeniedException;

public ConnectionParameters getCurrentTarget() throws

IncompleteTargetException;

public void setTarget(ConnectionParameters target) throws

IncompleteTargetException, PermissionDeniedException;

public void setTargetToDefault() throws PermissionDeniedException; public

int getConnectedTime(); public org.davic.resources.ResourceClient

getClient();

public void addConnectionListener( ConnectionListener l);

public void removeConnectionListener( ConnectionListener l); }

Questa classe mette a disposizione i metodi necessari per riservare la risorsa, settarne i parametri ed eseguire connessione e disconnessione dall’ISP impostato. Prima di eseguire la connessione all’ISP utilizzando l’interfaccia specificata è necessario riservare la risorsa per la nostra applicazione, per fare questo si utilizza il metodo riserve() per evitare che altri cerchino di utilizzarla generando dei conflitti. Questo metodo è utilizzato per associare all’interfaccia un ResurceClient utilizzato per i messaggi di notifica sullo stato della risorsa e per quando questa viene rimossa, questo metodo può generare un’eccezione del tipo PermissionDeniedException quando la nostra applicazione non ha i permessi necessari per riservare la risorsa. L’applicazione che utilizza il canale di ritorno deve per forza essere a conoscenza dei dati che ci permettono di chiamare ad autenticarci presso un ISP e quindi prima di chiamare il metodo connect() sarà necessario che questi vengano impostati nell’interfaccia selezionata, per fare questo si utilizza il metodo setTarget(). Ogni interfaccia ha in genere un ISP associato al quale ci si connette quando la si usa, solitamente questo è strettamente legato al broadcaster che trasmette l’applicazione interattiva e che quindi mette a disposizione anche un Centro Servizi con cui interagire. Il metodo setTargetToDefault() rimuove tutti i target impostati e setta quello che il produttore del middleware ha definito come standard. Se la nostra applicazione non ha i permessi per reimpostare il target o se quello di default non è valido viene lanciata una SecurityException. Ogni target è rappresentato da un oggetto della classe ConnectionParameters, questa classe è utilizzata per creare un oggetto in cui sono definiti i parametri necessari per stabilire una connessione. La classe e strutturata come segue:



97

public class ConnectionParameters {

public ConnectionParameters( java.lang.String number, java.lang.String

username, java.lang.String password);

public ConnectionParameters( java.lang.String number, java.lang.String

username, java.lang.String password, java.net.InetAddress[] dns);

public java.lang.String getTarget();

public java.lang.String getUsername();

public java.lang.String getPassword();

public java.net.InetAddress[] getDNSServer(); }

Come possiamo vedere i parametri di cui una interfaccia ha bisogno sono un numero telefonico un “username” e una password che il middleware utilizza per autenticare la connessione. E’ possibile passare se necessario un array con gli indirizzi dei server DNS (Domain Name System) da utilizzare, prima di riportare un messaggio di fallimento, che vengono utilizzati per trasformare nomi di host e indirizzi di posta elettronica in indirizzi IP, da utilizzare quindi per stabilire connessioni TCP/UDP sulle socket. Chiamando il metodo setTarget() è possibile che venga lanciata una IncompleteTargetException nel caso in cui l’oggetto ConnectionParameters fosse stato creato con qualche parametro a null. Ogni cambiamento sull’oggetto ConnectionParameters avrà effetto nel momento in cui noi stabiliamo la connessione, se pero delle modifiche vengono fatte durante una connessione gia attiva per rendere effettivi i nuovi parametri sarà necessario disconnettere l’interfaccia e poi riconnetterci per puntare al nuovo ISP. Una volta impostato un target possiamo chiamare il metodo connect() sulla nostra interfaccia, ed una volta ottenuto l’IP utilizzare le classi del package java.net per connetterci all’host desiderato. Nel caso dell’interfaccia PSTN il middleware andrà a chiedere il consenso dell’utente prima che l’applicazione effettui la chiamata, se l’utente acconsente il numero telefonico viene messo in una “white list” per evitare che si richieda il consenso al prossimo accesso. Se l’utente blocca la chiamata viene generato un ConnectionFailedEvent, mentre se si acconsente ed il middleware riesce a creare la connessione viene generato un ConnectionEstablischedEvent. Nel caso in cui la risorsa sia riservata ma non sia possibile stabilire una connessione con il target specificato il middleware lancerà una IOException per notificare all’ascoltare che ci sono stati dei problemi non direttamente dovuti all’hardware del ricevitore. Una volta che l’applicazione ha terminato di utilizzare la risorsa si chiama il metodo disconnect() e quindi il metodo release() per rilasciare la risorsa e permettere ad altre applicazioni di utilizzarla,



98

lanciando l’evento ConnectionTerminatedEvent. Ottenere la connessione ad un ISP può richiedere del tempo ed avere delle complicanze, specialmente nel caso di un modem PSTN, per questo la nostra applicazione dovrà registrare come ascoltatori quelle classi che intendono sfruttare la connessione. Queste classi dovranno implementare l’interfaccia ConnectionListener e quindi definire come il metodo astratto connectionChanged dovrà comportarsi quando si vede arrivare un evento del tipo ConnectionRCEvent. La classe ConnectionListener è strutturata come segue:

public interface ConnectionListener {

public abstract void connectionChanged(ConnectionRCEvent e); }

Le classi che implementano ConnectionListener vengono associate all’oggetto ConnectionRCInterface utilizzando il metodo addConnectionListener in modo che il middleware saprà a chi inviare gli eventi che si generano da quell’ interfaccia. Tali eventi sono di tre tipi: ConnectionEstabliscedEvent: Generato nel caso in cui la connessione ha avuto successo. ConnectionFailedEvent: Se non è stato possibile stabilire la connessione per motivi tecnici, se per esempio qualcuno sta utilizzando in quel momento il telefono. ConnectionTerminateEvent: Generato nel caso in cui si rompe la connessone oppure se l’applicazione stessa ha deciso di disconnettersi. Gli eventi appena descritti possono essere generati anche dall’applicazione stessa nel caso in cui si verifichino più sequenze di request sulla stessa connessione per notificare alla classe in ascolto che la sessione è ancora attiva e si possono trasferire file senza stabilirne una nuova. 3.8.5 I package java.net e java.io Ottenuta la connessione con il Centro Servizi tramite i metodi messi a disposizione dal package org.dvb.net.rc le applicazioni si vanno ad appoggiare alle API java.net per accedere alle URL. Lo standard MHP pone alcune restrizioni sulle classi che si possono utilizzare di questo package, in particolare le classi messe a disposizione da DVB-J che è la versione ridotta di Java per MHP basata oltre che sui package specifici per il DVB sulla Personal Java 1.1.8 sono: java.net.URL java.net.URLConnection java.net.Socket java.net.InetAdress Tutte queste classi possono essere utilizzate per ottenere un collegamento con il Centro Servizi tramite protocolli HTTP e HTTPS. La particolarità



99

delle classi del package java.net è quella di essere in grado di interfacciarsi tramite l’uso della JVM con il sistema operativo della macchina su cui si sta eseguendo l’applicazione sarà poi questa a gestire l’accesso al modem e a far transitare le richieste attivando una connessione su protocollo TCP. Ottenuto il link con la risorsa desiderata ci si appoggia al package java.io per i metodi di gestione dei file veri e propri. Anche altri metodi possono essere utilizzati per gestire i file in particolare per quanto riguarda immagini ci si appoggia alla classe java.awt.image.ImageProducer e per file audio e video al package javax.media. E’ sempre opportuno controllare nelle specifiche MHP quali classi possono essere utilizzate per evitare mal funzionamenti nelle applicazioni dato che non tutti i tipi MIME sono supportati dai STB.

3.9 Accessibilità ed usabilità Il fine principale dell’applicazione è soddisfare l’esigenza di essere aperta all’uso di tutti gli utenti, compresi quelli con disabilità. Con questo obiettivo si è cercato di applicare al progetto i concetti di accessibilità; così facendo si ottiene un miglioramento generale nell’utilizzo da parte di tutti gli utenti. La soluzione di seguito presentata ha la caratteristica di essere un prototipo “adattabile” ad utenze disparate: l’idea di base resta quella di costruire una applicazione MHP, quindi scaricabile dall’etere. Per comprendere come soddisfare i requisiti di accessibilità, è utile fare un cenno ai problemi specifici di accesso da parte delle varie categorie di persone disabili. Gli utenti con disabilità, destinatari del progetto, possono essere ricondotti ai seguenti profili: disabilità sensoriali (vista, udito) e disabilità motorie; non sono state trattate nello specifico le disabilità psichiche e cognitive in quanto necessitano di studi più approfonditi. La disabilità della vista comprende tipicamente due classi di utenti: i non vedenti (inclusi tra i destinatari delle future versioni dell’applicazione, cfr. Conclusioni) e gli ipovedenti; tale suddivisione è giustificata dalla diversità di accesso, infatti, per lo studio riservato agli utenti ipovedenti, è possibile utilizzare accorgimenti particolari come un’adeguata dimensione del font usato oppure l’impostazione di colori adatti ad esaltare la presentazione grafica. Per i non vedenti occorre, invece, ricorrere a tecniche particolari come l’utilizzo del segnale audio mediante l’impiego, per esempio, di un sintetizzatore vocale. I problemi relativi ad utenti con disabilità uditive, dovuti a sordità parziale o totale,



100

sono da prendere in considerazione nel caso specifico di messaggi auditivi che devono essere sempre accompagnati da descrizioni scritte. L’arco delle disabilità di tipo fisico è piuttosto ampio e va da una modesta paralisi su un arto sino, nel peggiore dei casi, ad una mobilità residua quasi nulla. Riguardo alla possibilità di interazione con l’interfaccia grafica, nel mezzo fisico utilizzato per il comando, occorre tener conto come la scelta di pulsanti troppo vicini tra loro e di dimensioni ridotte comporti problemi non indifferenti; per questo motivo è stato pensato di impiegare anche i tasti freccia per la navigazione dei menù, di dimensioni maggiori rispetto ai pulsanti numerici, come facilmente riscontrabile nei telecomandi presenti sul mercato, con la conseguente semplificazione dell’accesso ad essi. Allo scopo di ottenere un’applicazione che possa essere utilizzata da un sempre maggior numero di utenti si devono ottenere le seguenti caratteristiche:

• Equità e flessibilità d’uso; • Uso semplice ed intuitivo – l’utilizzo dell’applicazione deve

essere facile da capire indipendentemente da esperienza, conoscenza o capacità di concentrazione dell’utente.

• Informazione accessibile. Le linee guida usate nel progetto sono simili a quelle seguite nella realizzazione di pagine WEB accessibili, nello specifico:

• Impiego di combinazioni di colore di sfondo e di primo piano tali da fornire sufficiente contrasto per non precludere l’uso a persone con disturbi di percezione cromatica o ipovedenti;

• Struttura di navigazione chiara e coerente; • Uso di colori per fornire informazioni solo nel caso in cui è

possibile impiegarli in combinazione con del testo guida. 3.9.1 Scelte progettuali L’applicazione, che verrà di seguito descritta, è stata progettata con le seguenti caratteristiche:

Programmabilità – L’applicazione deve poter essere configurata a seconda del database da gestire. Con poche modifiche al codice sorgente si è in grado di adattare la xlet a qualsiasi database. La xlet deve conoscere il nome delle colonne del DB. Adattabilità – L’interfaccia deve poter presentare differenti modalità di visualizzazione a seconda di diversi livelli di disabilità visiva; nel caso estremo, ad esempio, l’applicazione consente di visualizzare i testi con contrasto elevato (testo bianco



101

su fondo nero). Queste scelte potranno essere salvate in futuro su una smart card che tenga memoria non solo di informazioni personali, ma anche delle impostazioni desiderate; così come accade oggi per le chiavi d’accensione delle autovetture di lusso. Compatibilità MHP – Poiché il software progettato in questa fase deve essere successivamente eseguito su una piattaforma digitale terrestre dovrà inevitabilmente rispettare le specifiche dello standard; in particolar modo il programma realizzato in Java deve rispettare i requisiti della piattaforma JavaTV della Sun Microsystems. Per questo motivo si è utilizzato un basso profilo di programmazione, la versione 1.1 di Java, senza penalizzare più di tanto il risultato finale; non sarebbe stato possibile, ad esempio, usare la libreria grafica Swing di Java 2, seppur graficamente più accattivante della semplice AWT di Java 1. L’utilizzo di semplici pannelli di Java 1.1 per la realizzazione dell’interfaccia ha reso l’applicazione leggera dal punto di vista dell’occupazione di memoria (problema non trascurabile nella progettazione di strumenti per le piattaforme televisive). Protocollo di comunicazione sicuro – Vista la riservatezza dei dati trattati sarà necessario utilizzare protocolli di comunicazione sicuri. In seguito tratteremo largamente questo aspetto.

Per l’interfaccia utente sono stati presi in considerazione due vincoli particolarmente stringenti:

Massima semplicità d’utilizzo – l’utente anziano deve poter essere in grado di comprendere le modalità di funzionamento dell’applicazione nel minor tempo possibile, in modo quasi intuitivo, venendo opportunamente guidato nella scelta delle operazioni eseguibili. Massima leggibilità – i problemi legati alle diverse difficoltà visive impongono opportune scelte dell’aspetto grafico dell’applicazione (colori, caratteri ed immagini devono essere adeguati). Si è mirato a superare gli ostacoli dovuti a diversi stadi di disabilità visive (ipovedenza, daltonismo), riuscendo così a soddisfare contemporaneamente i requisiti dell’utenza anziana.

Nell’interfaccia grafica della xlet non sono stati inseriti spazi in cui continuare a guardare trasmissioni televisive. Si è ritenuto che un operazione come la cancellazione di una visita medica richiedesse il massimo dell’attenzione da parte dell’utente.



102

3.9.2 Massima semplicità Riguardo il menù della xlet di presentazione dell’Asur zona 7 è stato fissato come “must” la massima semplicità. Questa è la caratteristica di base per rendere l’applicazione userfriendly, l’esplorazione di tutte le funzionalità avviene tramite solo due livelli di profondità, infatti per giungere all’esecuzione di un comando l’applicazione deve visualizzare, all’utente, soltanto due schermate diverse. Si è preso come termine di paragone il tipico menù di esplorazione dei contenuti di un telefono cellulare, che per quanto semplice, presentando numerosi livelli di profondità, mette in difficoltà l’utente anziano medio. E’ stato anche stabilito che nel secondo livello di profondità del menù non si utilizzassero ancora i tasti direzionali, ma quelli numerici. In questo modo l’utente ha la netta consapevolezza di trovarsi nel livello principale o secondario del menù.

3.10 Sicurezza Si apre ora l’ultima parte di questo capitolo che tratterà largamente di sicurezza. Nel momento in cui si effettua una connessione ad un sito per passare o ricevere informazioni riservate si parla di sicurezza informatica. L’esempio tipico è quando ci colleghiamo al sito della banca, vogliamo essere sicuri che effettivamente siamo collegati con essa e non con un eventuale truffatore. Le proprietà di cui ci si deve preoccupare nel caso della sicurezza sono: • Autenticazione; • Riservatezza; • Integrità; • Non ripudio. Per autenticazione s’intende il riconoscimento di una o di entrambe le parti coinvolte in una comunicazione. essa consiste nell’immissione di un nome utente (username) e della sua relativa password. Questo sistema da solo non basta infatti se non si usano sistemi di crittografia, le password immesse passano nel canale di comunicazioni in chiaro e quindi facilmente intercettabili e riutilizzabili grazie all’ausilio di programmi di sniffing (lo vedremo fra poco). La riservatezza consiste nel cifrare in modo opportuno i dati che sono trasmessi al fine di renderli non leggibili da persone non autorizzate. In una parola la scienza della crittografia. Per integrità si intende la certezza che una comunicazione non sia modificata in alcun modo durante il suo percorso.



103

Per non ripudio di una comunicazione s’intende la possibilità di provare in un secondo momento l’avvenuta comunicazione. Gli attachi che gli hacker effettuano sono principalmente di quattro tipi: 1. Data spoofing 2. Packet sniffing 3. Denial of service (DoS) 4. Shadow server Questo ultimo si ha quando un server estraneo si sostituisce ad un altro. Un esempio tipico è quello tra la comunicazione tra il cliente e la banca, e sostituirsi al server stesso tramite l’avvelenamento della cache (poison cache). 3.10.1 Packet sniffing Si definisce Packet sniffing l'attività di intercettazione passiva dei dati che transitano in una rete telematica. Tale attività può essere svolta sia per scopi legittimi (ad esempio l'individuazione di problemi di comunicazione o di tentativi di intrusione) sia per scopi illeciti (intercettazione fraudolenta di password o altre informazioni sensibili). I prodotti software utilizzati per eseguire queste attività vengono detti sniffer ed oltre ad intercettare e memorizzare il traffico offrono funzionalità di analisi del traffico stesso. 3.10.2 Data spoofing Per data spoofing s’intende invece la modifica dei dati durante il loro trasferimento in rete. Il termine “modifica” va inteso nel suo significato più generico: s’intende cioè anche la cancellazione e l’aggiunta di pacchetti. Mentre per modificare e/o cancellare dei pacchetti in genere si deve avere accesso ai nodi intermedi della rete, per aggiungerne non è necessario: basta, infatti, falsificare l’indirizzo del mittente; in questo caso si parla di address spoofing (oppure IP spoofing se ci riferisce ad un a rete TCP/IP).



104

Fig. 3.7 – il data spoofing

Questa tecnica è oggi la piu’ utilizzata dagli hacker e per questo ci soffermiamo. In una prima fase, lospoofing consiste nell’ascolto dei pacchetti in transito in una rete commutata. Gli altri due dettagli interessanti riguardano l’ARP. Per prima cosa, in generale quando arriva una risposta ARP con un indirizzo IP già esistente nella cache ARP, il sistema ricevente scrive le nuove informazioni presenti nella risposta cancellando le precedenti informazioni presenti sugli indirizzi MAC (a meno che tale voce non sia stata contrassegnata esplicitamentnte nella cache ARP come permanente). Il secondo punto interessante è che i sistemi accetteranno una risposta ARP anche se non hanno inviato una richiesta ARP. Questo in quanto le informazioni di stato sul traffico ARP nonvengono conservate, perchè ciò richiederebbe un’ulteriore quantità di memoria e renderebbe più complesso un protocollo progettato per essere improntanto alla massima semplicità. Questi tre dettagli, quando vengono sfruttati in modo appropriato, possono consentire a un aggressore di sniffare il traffico di rete su una rete commutata mediante la cosiddetta tecnica del reindirizzamento ARP. L’aggressore invia risposteARP camuffate a determinate periferiche , facendo in modo che le voci della cache ARP vengano sovrascritte con i suoi dati. Questa tecnica viene detta “ avvelenamento della cache ARP”. Per intercettare il traffico tra due punti, A e B, l’aggressore deve avvelenare la cache ARP di A per far si che



105

l’indirizzo IP di B corrisponda al indirizzo MAC,e deve inoltre avvelenare la cache ARP di B per indurre B a ritenere che l’indirizzo IP di A corrsponda anch’esso al suo indirizzo MAC. A questo punto, è sufficiente che la macchina dell’aggressore inoltri questi pacchetti alle rispettivi destinazione finali: tutto il traffico tra A e B continuerà a funzionare regolarmente, ma passando attraverso la macchina dell’aggressore , come mostrato nella fig.3.7. Poichè A e B incapsulano le rispettive intestazioni Ethernet dei pacchetti sulla base delle rispettive cache ARP,il traffico IP di A destinato B viene in realtà inviato all’indirizzo MAC dell’aggressore e viceversa. Lo switch filtra il traffico basandosi unicamente sull’indirizzo IP , pertanto esso funzionerà come previsto, inoltrando il traffico IP di A e di B, destinato all’indirizzo MAC dell’aggressore, alla porta dell’aggressore stesso. A questo punto l’aggressore incapsula i pacchetti IP con le opportune intestazioni Ethernet e li trasmette allo switch, dove essi vengono finalmente instradati alla loro opportuna destinazione. Lo switch funzionano correttamente, sono le macchine bersagliate a essere ingannate e costrette a reindirizzare il loro traffico alla macchina dell’aggressore. A causa dei valori di time-out, le macchine bersagliate inviano periodicamente richeiste ARP reali e ricevono delle risposte ARP reali. Per poter mantenere l’attacco di reindirizzamento, l’aggressore deve continuamente avvelenare le cache Arp delle macchine bersaglio. C’e’ un modo semplice per far ciò : basta inviare risposte ARP camuffate sia ad A che a B a intervalli costanti tipicamente ogni dieci secondi. Esistono dei metodi per evitare questo tipo di attacco, ma fra tutti l’unico veramente sicuro è usare un tunnel HTTPS, anche in questo caso la cache può essere avvelenata ma il messaggio non può essere interpretato perchè cifrato. 3.10.3 Denial of service (DoS) Tradotto letteralmente significa “Negazione del servizio”, si impedisce ad un host di potere fornire i suoi servizi tendendolo impegnato in qualche modo costringendo l’host ad elaborare numero elevati di pacchetti o tenendo in sospeso le richieste d’apertura di connessione.



106

3.11 CRIPTOLOGIA La criptologia è definita come lo studio della crittografia e della crittoanalisi. La crittografìa è semplicemente il processo con cui si comunica segretamente tramite l'utilizzo di cifrari; la crittoanalisi è il processo con cui si decifrano le suddette comunicazioni segrete. Storicamente, la criptologia ha rivestito un particolare interesse nei periodi bellici: si sono utilizzati codici segreti per comunicare con le truppe amiche e, al tempo stesso, si è cercato di decifrare i codici del nemico per infiltrarsi nel loro sistema di comunicazioni. Le applicazioni militari esistono ancora, ma l'utilizzo della crittografia nella vita civile si è enormemente diffuso da quando si effettuano su Internet delle transazioni "critiche", con sempre maggiore frequenza. L'intercettazione del traffico di rete avviene con frequenza tale da giustificare la convinzione, apparentemente paranoica, che qualcuno ci stia spiando. Password, numeri di carta di credito e altre informazioni vitali possono essere intercettate e rubate quando si utilizzano protocolli non criptati. I protocolli di comunicazione criptati costituiscono una soluzione a questa mancanza di protezione e consentono all'economia su Internet di funzionare. Senza il sistema il di cifratura SSL (Secure Sockets Layer), i pagamenti con carta di credito in popolari siti Web sarebbero molto scomodi o rischiosi. Tutti questi dati privati vengono protetti mediante algoritmi crittografici che "probabilmente" sono sicuri. Attualmente i sistemi crittografici garantiscono una sicurezza assoluta e dimostrabile matematicamente. Sono difficili da gestire per essere utilizzati in pratica, per cui si utilizzano in loro vece sistemi che sono praticamente sicuri. Ciò significa che è possibile che esistano degli escamotage per decriptare questi cifrari, ma che che nessuno è riuscito sinora ad applicarli. Ovviamente, esistono anche crittosistemi che non sono affatto sicuri. Tale inefficacia può essere dovuta alla loro implementazione, alla lunghezza della chiave, o semplicemente alla "debolezza" crittoanalitica del cifrario stesso. Nel 1997, le leggi statunitensi prevedevano che la lunghezza della chiave massima consentita per la cifratura nel software esportato fosse di 40 bit. Questa limitazione rende insicuro il cifrario corrispondente, come fu dimostrato dall'azienda RSA Data Security e da Ian Goldberg, uno studente laureato della University of Califbmia (Berkeley). L'azienda lanciò una sfida: decifrare un messaggio criptato con una chiave a 40 bit. Goldberg ci riuscì in appena tre ore e mezza. Ciò costituì una prova indiscutibile del fatto che le chiavi a 40 bit non sono sufficienti a garantire la sicurezza di un crittosistema. La crittologia è correlata all'hacking da diversi punti di vista. Per certe persone il desiderio di risolvere un



107

puzzle è irresistibile. In altri casi, lo scopo può essere molto meno nobile: i vantaggi materiali derivanti dalla soluzione del rompicapo e dal conseguente accesso a dati segreti protetti sono forse ancora più allettanti. Riuscire ad abbattere o eludere le protezioni crittografiche poste a difesa dei dati segreti può essere appagante, e così anche il venire a conoscenza di informazioni protette. Va inoltre detto che la crittografia forte aiuta a evitare la rilevazione degli attacchi. È inutile avere un costoso sistema di rilevazione delle intrusioni (IDS), progettato per ascoltare il traffico di rete e individuare indizi di un attacco, quando l'aggressore utilizza un canale di comunicazione criptato. Spesso un accesso criptato al Web, fornito per garantire la sicurezza del cliente, viene utilizzato da malintenzionati per sferrare attacchi difficilmente monitorabili. 3.11.1 Teoria dell’informazione Molti dei concetti su cui si basa la sicurezza crittografica derivano dal pensiero di Claude Shannon. Le sue idee (in particolare i concetti di diffusione e confusione) hanno esercitato una notevole influenza nel campo della crittografia. Sebbene i concetti (che esporrò tra breve) di sicurezza assoluta, chiavi non riutilizzabili, distribuzione quantistica delle chiavi e sicurezza computazionale non siano stati sviluppati da Shannon, le sue idee sulla sicurezza assoluta e la sua teoria dell'informazione hanno esercitato una notevole influenza sulle delimitazioni di sicurezza. 3.11.2 Sicurezza assoluta Un sistema crittografico viene considerato assolutamente sicuro se non può essere violato nemmeno avendo a disposizione risorse computazionali illimitate. Ciò implica che la crittoanalisi è impossibile e che anche provando ogni possibile chiave con un attacco a forza bruta completo sarebbe impossibile stabilire qual è la chiave corretta. 3.11.3 Sistemi a chiave non riutilizzabile II sistema a chiave non riutilizzabile (one-time pad o one time password fuori dall’ambiente matematico) è un esempio di crittosi-stema assolutamente sicuro. Si tratta di un critto sistema molto semplice, che utilizza blocchi di dati casuali chiamati pad. Il pad deve avere una lunghezza non inferiore al messaggio in testo semplice da codificare; inoltre i dati casuali contenuti nel pad devono essere effettivamente tali,



108

nel senso più letterale del termine. Vengono creati due pad identici: uno per il destinatario e uno per il mittente. Per codificare un messaggio, il mittente si limita ad applicare la funzione XOR a ciascun bit del messaggio di testo in chiaro con ciascun bit del pad. Dopo che il messaggio è stato codificato, il pad viene distrutto per far sì che venga utilizzato una sola volta. A questo punto, è possibile inviare il messaggio criptato .il destinatario senza temere che venga sottoposto a crittoanalisi, perché tale messaggio non può essere decifrato senza il pad. Quando il destinatario riceve il messaggio criptato, applica anch'egli la funzione XOR a ciascun bit del messaggio criptato con ciascun bit del suo pad, in modo da rigenerare il messaggio in chiaro originario. Benché sia teoricamente impossibile decriptare un sistema a chiave non riutilizzabile, in pratica non si tratta di un sistema molto conveniente. La sicurezza del one-time pad si basa sulla sicurezza dei pad. Quando i pad vengono distribuiti a destinatario e al mittente, si assume che il canale di trasmissione dei pad sia sicuro. Tale sicurezza può essere garantita facendo incontrare di persona mittente e destinatario, ma ciò non sempre e possibile, per cui la trasmissione del pad avviene mediante un altro cifrario. Questa seconda soluzione comporta però una penalità: adesso la sicurezza dell'intero sistema è la sicurezza del suo anello più debole, ossia il cifrario utilizzato per trasmettere i pad. Cit. L’arte dell’hacking di Jon Erickson. Dal momento che il pad è costituito da dati casuali aventi la stessa lunghezza del messaggio di testo semplice, e poiché la sicurezza dell'intero sistema corrisponde alla sicurezza del metodo utilizzato per trasmettere il pad, di solito nella realtà appare più logico inviare un messaggio codificato mediante il cifrario che sarebbe utilizzato per trasmettere il pad.

3.11.4 Cifratura simmetrica I cifrari simmetrici sono crittosistemi che utilizzano la stessa chiave per criptarre e decriptare messaggi. In genere, la cifratura e la decifrazione sono più veloci di quanto accade con la cifratura asimmetrica, ma la distribuzione delle chiavi può costituire un problema. In genere questi cifrari sono a blocchi o a flusso. Un cifrario a blocco utilizza blocchi di dimensione fissa, di solito da 64 o 128 bit. Lo stesso blocco di testo semplice verrà sempre criptato nello stesso blocco di testo cifrato utilizzando la stessa chiave. DES, Blowfish e AES (Rijndael) sono tutti cifrari a blocchi. I cifrari a flusso generano un flusso di bit pseudocasuali, di solito a un bit o un byte per volta. Tale flusso viene chiamato keystream, ed è sottoposto a XOR con il testo semplice. Ciò è



109

utile per criptare flussi continui di dati. DES e AES sono due diffusi cifrari a blocchi. La costruzione dei cifrari a blocchi è oggetto di attenta riflessione, perché si cerca di renderli coriacei rispetto agli attacchi critto analitici noti. Due concetti vengono utilizzati ripetutamente nei cifrari a blocchi: la confusione e la diffusione. Con il termine "confusione" si fa riferimento ai metodi utilizzati per nascondere le relazioni esistenti tra il testo in chiaro, il testo cifrato e la chiave. Ciò significa che i bit di output devono utilizzare una qualche forma di trasformazione complessa della chiave e del testo in chiaro. La diffusione serve a diffondere l'influenza dei bit del testo in chiaro e dei bit della chiave sulla maggior possibile del testo cifrato. 3.11.5 Cifratura asimmetrica Nei cifrari asimmetrici si utilizzano due chiavi: una chiave pubblica e una chiave asimmetrica. Come suggeriscono questi termini, la prima è nota al pubblico, mentre la seconda è segreta. Qualsiasi messaggio che venga criptato con la chiave pubblica può essere decifrato solo con la chiave privata. In tal modo si elimina il problema della distribuzione delle chiavi; le chiavi pubbliche sono, ovviamente, note al pubblico, e utilizzando la chiave pubblica è possibile criptare un messaggio in relazione alla corrispondente chiave privata. Non è più necessario utilizzare un canale di comunicazione out-of-band (su un canale dedicato) per trasmettere la chiave segreta, come avviene nel caso dei cifrari simmetrici. Tuttavia i cifrari asimmetrici tendono a essere alquanto più lenti di quelli simmetrici. Cit. L’arte dell’hacking di Jon

Erickson. 3.11.5.1 RSA L'RSA è uno dei più diffusi algoritmi asimmetrici. La sicurezza dell'RSA si basa sulla difficoltà di fattorizzazione di numeri grandi. Innanzitutto si scelgono due numeri primi, P e Q, e se ne calcola il prodotto, N.

N = P • Q Successivamente si calcola il numero dei numeri compresi tra 1 e (N — i) che sono primi relativamente ad A (due numeri sono relativamente primi se il loro massimo comune divisore è 1. Questa funzione è nota come funzione quoziente di Eulero ed è di solito indicata con la lettera greca minuscola phi. Per esempio, phi(9) = 6, perché 1, 2, 4, 5, 7 e 8 sono relativamente primi rispetto a 9.



110

3.11.5.2 Public Key Infrastructure (PKI) Una PKI è un sistema per pubblicare le chiavi pubbliche di varie entità che usano sistemi di crittografia e/o autenticazione asimmetrici (ovvero a chiave pubblica). Le operazioni del sistema PKI deve compiere sono :

1. Certificazione 2. Validazione

2.4.5.3 Certificazione La certificazione è il processo che lega una chiave pubblica ad un’entità (persona fisica, server,…). Per capire con un esempio di cosa si tratta pensiamo al caso della firma digitale: supponiamo che Alice vuole mandare un messaggio firmato a Bob, per farlo deve cifrare il messaggio stesso (o più comunemente un suo hash) con la propria chiave privata. Bob dovrà andare a verificare la firma con la chiave pubblica di Alice che egli stessa ha mandato o che recupererà in qualche altro modo; ora mettiamo che tale verifica vada a buon fine: l’esito positivo vuol dire che il messaggio è stato firmato dal possessore della chiave privata legata a quella particolare chiave pubblica; ma non vi è modo di dimostrare che effettivamente appartenga ad Alice. Una PKI associa un’entità (Subject) alla sua chiave pubblica (o più in generale ad altre informazioni) è comunemente chiamato certificato, e l’ente che lo emette Autorità di certificazione o Certification Authority (o più comunemente indicata CA). Il tutto si schematizza come la figura sotto: Lo standard per i certificati attualmente utilizzato è l’ITU-T X.509 versione 3 (emesso nel Giugno 1996). Definisce le informazioni di base che contenute in un certificato (Figura sopra) ed un regola di codifica con cui trasformare questo oggetto in una sequenza di byte da trasmettere in rete. Le informazioni fondamentali comprendono:

1. Certificate Serial Number: identificatore univoco (tra tutti quelli emessi dalla CA) del certificato. 2. �Validity Period: coppia di date che determina la validità del certificato (data di inizio e di fine). 3. Subject: l’intestatario del certificato e le informazioni ad esso relative (ad esempio per un principal umano potrebbero essere nome, cognome, indirizzo, data di nascita, ecc., per un principal server Web l’indirizzo IP). 4. �Subject Public Key Information: è l’informazione vera e propria che viene certificata. Questa informazione comprende la



111

chiave pubblica del principal e l’algoritmo a cui essa è applicabile. 5. �Issuer: nome della CA che ha emesso il certificato.

Fig 3.8 - Sistema di Certificazione

3.11.5.4 PROTOCOLLO TLS Il protocollo TLS è realizzato con combinazioni di chiavi pubbliche e simmetriche. La sessione TLS inizia tramite uno scambio di messaggi in una fase detta “Handshake” .Il server ha un certificato con le informazioni riguardanti la società/ente/persona. I campi più importanti sono le informazioni di cui sopra e la relativa chiave pubblica. Il tutto è regolato dal Certificato X.509. Cit. L’arte dell’hacking di Jon



112

Erickson. Tale certificato può essere garantito da una Certification Authority, la quale assicura l’esatta corrispondenza tra il certificato e colui che lo emette. Anche il client può avere un certificato, ma questo serve solo se esso deve ricevere dati sensibili da parte del server. Quando la connessione è iniziata dal server, questo manderà al client un messaggio di tipo “server hello”. Mentre se è il client ad iniziare la connessione, si avrà un messaggio “hello”. Vediamo in dettaglio:

1. protocol version: definisce la versione TSL usata; 2. random byte: byte casuali generati dal client; 3. Session identifier: per verificare se si tratta di una nuova sessione o di una aperta in precedenza; 4. Lista delle CipherSuite: è una lista in cui il Client notifica al Server gli algoritmi di crittografia supportati, ordinati in modo decrescente; 5. Lista degli algoritmi di compressione supportati dal Client.

Il Server invia il seguente messaggio “server hello”: 1. Protocol version: rappresenta la versione TSL scelta dal Server; 2. Random byte: byte generati in modo casuale; 3. Session identifier: identifica la sessione. Se non è una sessione già aperta, se ne crea una nuova; questo nel caso in cui nel tag “session identifier” del messaggio “hello” sino presenti tutti zeri; Altrimenti viene riesumata la sessione indicata dal client, se presente nella cache del server; 4. ChiperSuite: famiglia di algoritmi di crittografia scelta dal server; 5. Compression method: metodo di compressione scelto da server.

Dopo avviene l’autenticazione tramite lo scambio di un certificato. Vediamo come si autentica il server. Questo vuol dire che i dati confidenziali andranno dal client al server. Tale situazione potrebbe essere, per esempio, una fase di acquisto in rete, in cui il client invia i suoi dati personali al Server, quindi è necessario che il Server sia ben identificato. Il Server dunque invia il certificato al Client, insieme alle preferenze riguardo l’algoritmo di crittografia da usare. A questo punto il client verifica che il certificato ricevuto sia valido analizzando vari aspetti:

1. Data di validità del certificato. 2.Verifica che la CA sia affidabile. Se lo è, il client recupera la chiave pubblica dalla sua lista di CA sicure per verificare la firma digitale arrivatagli con il certificato del server.



113

3. Se l’informazione in tale certificato è cambiata da quando è stata firmata da una CA, o se la chiave pubblica nella lista CA non corrisponde alla chiave privata usata dalla CA per firmate il certificato del server, il client non potrà autenticare il server. 4.Infine, il client verifica che il nome del dominio nel certificato server corrispondono allo stesso dominio del server. Questa fase conferma che il server è localizzato nello stesso indirizzo di rete che è specificato nel nome di dominio del suo certificato.

Tale controllo previene attacchi del tipo “Man in the Middle”, in quanto se il domain name non corrisponde, molto probabilmente perché il certificato è stato inviato non dal server atteso, ma da una terza persona che si è intromessa. La connessione sarà rifiutata se i due nomi non corrispondono. Se invece tutto è andato a buon fine, il client avrà verificato che il server è affidabile. Dopo si genera una “pre master key” che viene criptata con la chiave pubblica del server. Il server riceve il messaggio criptato e, verificata l’attendibilità del client, lo decripta tramite la sua chiave privata. Genera poi una master secret (cosa che fa anche il client, seguendo gli stessi passi) e da questa, insieme, generano la chiave di sessione, una chiave simmetrica che sarà usata per criptare e decriptare i dati che attraversano il tunnel SSL appena creato; inoltre serve per verificare che i dati non vengano alterati nel lasso di tempo che intercorre tra l’invio e la ricezione. Cit. L’arte dell’hacking di Jon Erickson. A questo punto il client ed il server si inviano un messaggio di notifica di HandShake concluso, e lo scambio di dati può iniziare. Vediamo ora come implementare il protocollo TLS con la server TOMCAT. Posizioniamoci nella directory home di Java. Adesso creeremo un keystore per il server e lo esporteremo in un certificato chiamato server.cer. Il keystore altro non è che un repository di certificati usato per identificare il client o il server, in questo caso il server. Usiamo, per fare ciò, l’utility keytool di Java presente con la JSSE ed immettiamo le informazione riguardanti il server. Il nostro certificato è mostrato in figura:



114

Fig 3.9 - Esempio Certificato

Ciò, non basta. Dobbiamo impostare Tomcat affinché trovi il repository. Clicchiamo con il tasto destro sull’icona di Tomcat e selezioniamo “Configura”. Andiamo poi su “Java” e poi “Java options”. In pratica, quando Tomcat lancia la JVM, carica anche il cacerts.jks, insieme al certificato del server e la trasmissione è criptata in entrambi i sensi.

3.12 Sicurezza MHP Iniziamo con questo capitolo ad occuparci delle problematiche relative alla sicurezza dello standard MHP. 3.12.1 MHP Specifiche software Lo standard MHP definisce una generica interfaccia tra le applicazioni e i relativi terminali nei quali queste vengono eseguite (vedi figura 3.10).



115

Fig. 3.10 - L’interfaccia DVB-MHP

L’MHP estende lo standard DVB per tutte le trasmissioni broadcast tra cui quelle satellitari, terrestri e via cavo. Lo standard utilizza delle API basate su tecnologie HTML/Java. Esse definiscono il meccanismo di realizzazione di applicazioni chiamate Xlet, le quali vengono inviate insieme allo stream (MPEG-2) ,definisce inoltre gli strumenti per l’accesso condizionato (CA) includendo le API necessarie alla comunicazione con le CAM (Conditional Access Modules) che servono per decifrare il segnale criptato permettendo servizi come il pay-per-view.

Fig 3.11 - architettura MHP



116

Il modello architetturale MHP è strutturato in tre parti (vedi figura sopra): • Applicazioni • Software di sistema • Risorse Le applicazioni MHP risiedono permanentemente su un terminale, oppure vi sono scaricate. Le applicazioni Java in ambiente MHP vengono rinominate applicazioni DVB-J" mentre quelle HTML prendono il nome "DVB-HTML". Il software di sistema fornisce un set di API volte a rendere l’applicazione indipendenti dal software e dall’hardware del terminale. Questo garantisce interoperabilità tra un’applicazione e le differenti implementazioni MHP. 3.12.2 Sicurezza MHP Tutto quello detto da ora in poi vale solo se sul set-top box è attivo il framework di sicurezza. Altrimenti il tutto non avrebbe motivo di essere. Cit. L’arte dell’hacking di Jon Erickson.

Il framework di sicurezza permette al ricevitore di autenticare il mittente di applicazioni e di file inviati . Nel caso di applicazioni, l’autenticazione avverte il ricevitore di quali sono i permessi di accesso a risorse sensibili che devono essere garantiti all’applicazione stessa. Un broadcaster può specificare in modo preciso questi permessi mediante un file xml permission request file o PRF) autenticato a sua volta insieme all’applicazione. Il sistema usa tre differenti tipi di messaggi: Codici Hash Un broadcaster può usare un hash file per provvedere un controllo per il file o directories, perciò assicurando che il contenuto non sia corrotto. Questo hash file ha il nome dvb.hashfile, e ogni directory contiene file con associato un valore di hash .Questo valore di hash viene computato in base ad un algoritmo MD5 or SHA-1 , anche se ad oggi è ritenuto più affidabile il primo. Firma digitale Il processo di firma attuale prende master hash file per il subdirectory che contiene l'applicazione come input. Questa hash file è l’hash per tutti i file in quella directory e subdirectory (calcolati usando l'altro hash archivia per quegli indici). Per firmare un'applicazione, il broadcaster calcola il valore del hash per questo hash file, allora cifra il hash risultante usando una procedura di pubblico-chiave. Il broadcaster usa la loro chiave privata per cifrare questi dati ed include la chiave



117

pubblica corrispondente nel file system di radiodiffusione (vedere sotto). Per firmare una directory radice , il broadcaster depone questa firma in una file denominato dvb.signature. <id_number> dove <id_number> è un numero intero decimale. Questo numero di identificazione permette che un albero dell'indice sia firmato da varie autorità. Naturalmente, firmare un'applicazione è uso se la ricevente non conosce quali applicazioni dovrebbero essere firmate - al contrario, potremmo rimuovere semplicemente tutte le informazioni della firma. Il ricevitore può dire quali applicazioni sono firmate ed a quali deve semplicemente guardare secondo l'identificazione di applicazione che è segnalata nel AIT. Lo spazio per l'indirizzo per un'identificazione di applicazione è tagliato in due campi. Le applicazioni ID compresi nella gamma 0x000 a 0x3FFF è considerata come un'applicazione unsigned. Le applicazioni ID nella gamma 0x4000 a 0x7FFF è considerata essere firmata con una firma digitale. L’algoritmo di cifratura è indicato nel certificato di chiave privata (MD5 con RSA e SHA-1 con RSA). ASN.1 DER indica Abstract Syntax Notation One è un linguaggio per la definizione di standard indipendente dall’implementazione. È il linguaggio dei realizzatori di standard: quando uno sviluppatore desidera scrivere raccomandazioni per la standardizzazione delle procedure seguite da un componente per l’interazione con un altro componente, utilizza la notazione ASN.1 e invia le raccomandazioni a un comitato per la definizione degli standard, come ITU. ASN.1 facilita la comunicazione tra professionisti e membri del comitato, mettendo a disposizione un linguaggio comune per la descrizione di uno standard. ASN.1 è definito nelle Raccomandazioni ITU-T X.209 e X.690 dove la seconda (X.690) è anche chiamata DER (Distinguished Encoding Rules). Il funzionamento del processo di firma è mostrato. dove per lato server si intende definire la parte gestita dal broadcaster mentre il lato client è il ricevitore digitale, Con "M" si intende l’HashFile primario della directory root usato per creare un "digest" ovvero un altro codice hash. Quest’ultimo viene firmato dalla chiave privata del broadcaster. La lettera FD (firma digitale) rappresenta il file chiamato dvb.signaturefile.x" appena descritto.



118

Fig. 3.12 - Trasmissione MHP

3.12.3 File certificati Come già abbiamo visto, il broadcaster deve includere la propria chiave pubblica nel filesystem in modo da potere decriptare la firma digitale; questa è contenuta nel file del certificato, che ha il nome dvb.certificate.<id_number >. Ogni directory che contiene un file di firma deve anche contenere il file del certificato con lo stesso numero di identificazione in modo da potere autenticare la firma particolare. Ogni certificato contentente un file firmato deve anche contenere il file certificato con lo stesso ID number così che la particolare firma possa essere autenticata .Ogni se certificato deve essere autocertificato, secondo una gerarchia che conduce a ritroso all’autorità di certificazione presente nella root principale. La disposizione delle file del hash, della firma e del certificato è coperta dettagliatamente nella parte 12.4 della specifica di MHP. Cit. MHP Tutorial : The Interactive TV Web. Si consideri il seguente albero



119

Fig. 3.13 Albero radice

Per certificare la directory radice dobbiamo procedere secondo i seguenti passi:

1. I certificati di ciascuna delle autorità che firmeranno l'albero radice (directory radice) sono aggiunti all'albero radice stesso. Poiché in questo caso siamo l'unica autorità che firmerà questo file, abbiamo soltanto un certificato. Il tutto è memorizzato nel file dvb.certificate.1. 2. Le directory di basso livello sono le prime che vengono checksummed . Soltanto due classi di file sono incluse nel hash risultante, poiché non stiamo autenticando il file del JPEG. Il risultato è un nuovo file chiamato dvb.hashfile che verrà aggiunto alla sottodirectory. 3. Dopo, la parent directory viene processata (checksummed). Realizzata prendendo il valore di hash del file e il dvb.hashfile soltanto da ogni subdirectory . Il tutto genera un dvb.hashfile per la parent directory. 4. Nel nostro caso, la parte superiore della directory radice ora è stata raggiunta e così ora possiamo firmare il hashfile. Il contenuto di questo file (cioè il valore reale del hash) è preso e cifrato usando la procedura di RSA con la chiave pubblica fornita



120

nella file dvb.certificate.1 nella directory radice. Cit. L’arte dell’hacking di Jon Erickson. Questo valore cifrato di hash allora è memorizzato nel file dvb.signature. Il processo è dunque completato e il file può essere trasmesso.

3.12.4 Ricezione dell’applicazione Nel momento in cui viene ricevuta un’applicazione firmata all’interno di un filesystem, vengono effettuate una serie di operazioni atte a validarne la firma che sono:

1. Verifica che in ogni directory sia presente un HashFile. 2. Verifica che il contenuto corrisponda all’Hashfile.

Fig 3.14 – Root, Radice

3. Si sale l’albero del filesystem ricorsivamente controllando che ogni directory sia autenticata correttamente. 4. Verifica che per ogni firma trovata vi sia anche il corrispettivo certificato di chiave pubblica.



121

5. Verifica tramite il file dei certificati che la firma sia corretta. 6. Verifica dell’autenticità dei certificati tramite la catena di certificati. 7. Verifica che il certificato della root CA sia presente tra i certificati presenti nella memoria permanente del ricevitore. 8. Ricorsivamente, per ogni firma e per ogni catena di certificati, si rieffettuando i punti 5, 6 e 7.

Se solo uno di questi punti non dà un esito positivo, l’applicazione risulta non autenticata. I diritti di accesso alle risorse di un ricevitore dipendono da due fattori: i diritti voluti dal broadcaster e quelli che sono garantiti dall’utente. Le risorse più "sensibili" sono conditional access ,il canale di ritorno ecc. I diritti di accesso depositati da un broadcaster sono firmati con l’applicazione stessa per evitare il problema del main in middle. I servizi non firmati godono di accesso alle risorse delle piattaforme limitati, mentre nei servizi firmati che di default godono degli stessi diritti dei non firmati il broadcaster può modificare questi permessi modificando un file chiamato “permission request” come si vede in figura sotto questo file di richiesta di permesso è un documento di XML con la disposizione data nella parte 12.6.2 della specifica di MHP. Questo file è memorizzato nella stessa directory del file principale per l'applicazione ed ha il nome dvb. <initial_file_name>.perm, dove < il initial_file_name > è il nome del file principale dell'applicazione. Un esempio di file di richiesta di permesso è qui specificato secondo le direttive dell’MHP;

<?xml version="1.0"?>

<!DOCTYPE permissionrequestfile

PUBLIC "-//DVB//DTD Permission Request File 1.0//EN"

"http://www.dvb.org/mhp/dtd/permissionrequestfile-1-0.dtd">

<permissionrequestfile

orgid="0x000023d2"

appid="0x0020">

<file value="true"></file>

<capermission>

<casystemid

id="0x1111" messagepassing="true"

<entitlementquery="true" mmi="false">

</casystemid>

</capermission>

<applifecyclecontrol



122

value="true">

</applifecyclecontrol>

<returnchannel>

<defaultisp></defaultisp>

<phonenumber>+3583111111</phonenumber>

<phonenumber>+3583111112</phonenumber>

<phonenumber></phonenumber>

</returnchannel>

<tuning value="false"></tuning>

<servicesel value="true"></servicesel>

<userpreferences

read="true"

write="false">

</userpreferences>

<network>

<host action="connect">hostname</host>

</network>

<persistentfilecredential>

<grantoridentifier id="0x0202030">

</grantoridentifier>

<expirationdate date="24/12/2032">

</expirationdate>

<filename read="true" write="false">

5/15/dir1/scores

</filename>

<filename read="true" write="false">

5/15/dir1/names

</filename>

<signature>

023203293292932932921493143929423943294239432

</signature>

<certchainfileid>3</certchainfileid>

</persistentfilecredential>

</permissionrequestfile>

La gestione del canale di ritorno nel permission è fondamentale per evitare che applicazioni terze, come quella del "man in the

middle"(tecnica in base alla quale l’aggressore (hacker) si interpone fra due terminali con lo scopo di reperire lo scambio di informazioni intercorrente fra i due) , che utilizzino questa risorsa in modo indiscriminato. Ad esempio se non ci fossero con una xlet si potrebbe ottenere una connessione ad un qualunque numero di telefono. Una specie di "dialer" del mondo di Internet.



123

Vediamo a tale proposito la seguente Xlet:

public class ReturnChannelXlet

implements Xlet, ResourceClient, ConnectionListener

{

private ConnectionParameters getConnectionParameters() throws

UnknownHostException

{

return new ConnectionParameters(" <num di tel maligno> ", "isp",

"passwd");

public void initXlet(XletContext ctx) throws

XletStateChangeException

{

[ ... ]

try

{

//Richiesta di un interfaccia al canale di ritorno

ConnectionRCInterface cif = getConnectionRCInterface();

[ ... ]

//Richiesta dei parametri di connessione

cif.setTarget(getConnectionParameters());

//Connessione in corso

cif.connect();

}

catch (Exception e) { ... }

}

public void startXlet() throws XletStateChangeException

{

//inizializzazione dell’Xlet completata e connessione attiva

}

public void pauseXlet()

{

// pausa

}

public void destroyXlet(boolean unconditional) throws

XletStateChangeException

{

try

{

ConnectionRCInterface cif = getConnectionRCInterface();

cif.disconnect();

[ ... ]

}



124

catch (Exception e) { ... }

}

[ ... ]}

…e l’utente è fregato. Basta mettere un numero di connessione maligno nella connection come parametro e otteniamo il tutto.

3.13 Introduzione smart card Descriveremo ora il funzionamento delle smart-card in ambito DVB-T, spiegando come interagire con esse ed evidenziando gli strumenti che permettono di farlo. Cit. MHP Tutorial : The Interactive TV Web. 3.13.1 Architettura smart card Le smart card più comuni sono: • Carte di credito • Contrassegni a forma di chiave Le smart card hanno un sistema di archiviazione protetta per i dati, per le chiavi private e i certificati con chiave pubblica. e possono memorizzare un minimo di 4 KB di informazioni. Le card dispongono di una certa capacità di elaborazione, anche se per utilizzarla è necessario connetterle a una periferica.

Fig 3.15 SMART CARD

ROM: Read Only Memory: Contiene il sistema operativo della smart card e programmi fissi Dimensione variabile tra 2k e 64k. Dopo la scrittura non è modificabile.



125

EEPROM: Electrically Erasable Read Only Memory Memorizza informazioni variabili (tipo hard disk); capacità verso i 128k. RAM: Random Access Memory Utilizzata per memorizzazioni temporanee. Si cancella quando si sfila la smart card (power off). Varia in genere tra i 128 byte e i 1024 byte. Interfaccia per Input/Output. Spesso la velocità del flusso dati è 9600 bit/sec. Vengono utilizzati due protocolli denominati T=0 e T=1. Vengono raggiunte velocità di 115200 bit/sec. La funzionalità chiave delle smart card è la possibilità di archiviare i dati in maniera protetta e per questo motivo le smart card supportano le funzioni di l’autenticazione e autorizzazione: (PIN, Personal Identification Number) ed in base ai permessi che di cui siamo in possesso si accede ai servizi della smart stessa. 3.13.2 Esempio in ambito dvb-tv Mostreremo ora come connettersi ad una smart card tramite le Xlet utilizzando le API dell’OpenCardFrameword . Si scriverà il codice per estrarre i dati dalla Smart a partire da un path e poi stamparli su video.

import opencard.core.service.*;

import opencard.core.terminal.*;

import opencard.core.event.*;

import opencard.core.service.SmartCard;

import opencard.core.service.CardRequest;

import opencard.core.terminal.CardID;

public class ReadFile extends CardService implements

CTListener,javax.tv.xlet.Xlet

{

private static final int MAX_APDU_SIZE = 100;

final byte[] CMD_SELECT_MF = {(byte)0xC0, (byte)0xA4,

(byte)0x00, (byte)0x00, (byte)0x02,

(byte)0x3F, (byte)0x00 };

// comando ISO/IEC 7816-4 SELECT FILE (seleziona l’EF con FID = 0005,

// senza dati in risposta)

// CLA || INS || P1 || P2 || Lc || DATA 1 (= FID high) || DATA 2 (= FID

low)

final byte[] CMD_SELECT_EF0005 ={(byte)0xC0, (byte)0xA4,

(byte)0x00, (byte)0x00, (byte)0x02,

(byte)0x00, (byte)0x05 };

// questo comando serve per leggere i byte)

final byte[] CMD_READ_BINARY ={(byte)0xC0, (byte)0xB0,

(byte)0x00, (byte)0x00, (byte)0x14 };

private static Object monitor = "synchronization monitor";



126

private CardTerminal ct;

private CardRequest cr;

private int slotID;

private SmartCard card;

public void initXlet(javax.tv.xlet.XletContext context)

throws javax.tv.xlet.XletStateChangeException

{

//[...]

}

public void pauseXlet()

{

//[...]

}

public void destroyXlet(boolean unconditional)


{

//[...]

}

public void startXlet()


{

//[...]

try

{

CardID cardID = ct.getCardID(slotID);

String name = ct.getName();

byte[] i = cardID.getATR();

printATR(i);

ResponseAPDU ris;

ris = doSomeThingWithCard(CMD_SELECT_MF);

System.out.print("L’output del comando è: ");

printByte(ris);

ris = doSomeThingWithCard(CMD_SELECT_EF0005);

System.out.print("L’output del comando è: ");

printByte(ris);

ris = doSomeThingWithCard(CMD_READ_BINARY);

System.out.print("Il contenuto del file è ");

printByte(ris);

}

catch (CardServiceException e1)

{

//[...]

}

catch (CardTerminalException e2)



127

{

//[...]

}

finally

{

//[...]

}

}

public void cardInserted(CardTerminalEvent ctEvent)

{

try

cr = new CardRequest(CardRequest.ANYCARD,ct,null);

card = SmartCard.getSmartCard(ctEvent, null);

ct = cr.getCardTerminal();

slotID = ctEvent.getSlotID();

synchronized (monitor)

{

monitor.notifyAll();

}

}

catch(Exception e)

{

System.out.println("faild connection");

}

}

public void Read()

{

try {

EventGenerator.getGenerator().addCTListener(this);

EventGenerator.getGenerator().createEventsForPresentCards(this);

synchronized (monitor)

{

System.out.println ("please insert a card now!\n");

monitor.wait();

}

System.out.println("SmartCard connected");

}

catch (Exception e)

{

System.out.println("SmartCard not connected");

}

}

public ResponseAPDU doSomeThingWithCard(byte[] comando)

throws CardServiceException, CardTerminalException



128

{

// check parameters

ResponseAPDU retvalue = null;

try {

allocateCardChannel();

CommandAPDU command = new CommandAPDU(comando);

ResponseAPDU response =

getCardChannel().sendCommandAPDU(command);

retvalue = response;

}

finally

{ // despite any exceptions

releaseCardChannel(); // free the card channel

}

return retvalue;

}

public void printByte(ResponseAPDU response)

{

int n;

String s;

for (n=0; n < response.getLength(); n++)

{

s = Integer.toHexString(response.getByte(n)).toUpperCase();

if (s.length()== 1) s = "0" + s;

System.out.print(s + " ");

} // for

}

public void printATR(byte[] i)

{

System.out.print("La carta ");

String s;

int x;

int n;

for (n=0; n<i.length; n++)

{

x = (int) (0x000000FF & i[n]); // byte to int conversion

s = Integer.toHexString(x).toUpperCase();

if (s.length()== 1) s = "0" + s;

System.out.print(s + " ");

} // for

System.out.print("è stata inserita nello slot "+slotID+"del lettore

"+name);

}

public static String toHexString ( byte[] b )



129

{

StringBuffer sb = new StringBuffer( b.length * 2 );

for ( int i=0 ; i<b.length ; i++ )

{

sb.append( hexChar [ ( b[ i] & 0xf0 ) >>> 4 ] ) ;

sb.append( hexChar [ b[ i] & 0x0f ] ) ;

}

return sb.toString() ;

}

//vettore usato per convertire i byte in decimali.

static char[] hexChar =

{

’0’ , ’1’ , ’2’ , ’3’ ,

’4’ , ’5’ , ’6’ , ’7’ ,

’8’ , ’9’ , ’a’ , ’b’ ,

’c’ , ’d’ , ’e’ , ’f’

};

}

3.14 Certificati per il TLS in MHP Prima di stabilire una connessione sicura su canale di ritorno, il client dispone di un certificato del server che, che può essere scaricato dal server stesso sul STB, può anche essere inviato dal broadcaster insieme all’applicazione. Dopo aver ottenuto il certificato il client compie i seguenti passi per verificare l’identità del server:

1. Verifica che il certificato non sia scaduto e, se la data attuale è al di fuori del periodo di validità, l’autenticazione fallisce;

2. Verifica la disponibilità del certificato presso l’autorità che lo ha firmato e controlla la firma;

3. Se il client non dispone del certificato dell’autorità di certificazione e non è in grado di procurarselo e di verificarlo attraverso una catena di certificazioni, l’autenticazione del server fallisce;

Se nessuno di questi passi fallisce allora si può continuare con l’handshake fino a ottenere la connessione sicura. Quindi niente di nuovo sotto il sole.

3.15 Accesso condizionato I broadcasters vogliono per le proprie esigenze la possibilità di cifrare parte dei propri servizi per effettuare operazioni tipo pay-tv. Quindi i



130

ricevitori contengono mezzi di decifratura del segnale per l’accesso ai servizi. Ci sono anche delle eccezioni, in quanto alcuni decoder (quelli più economici) sono in grado di ricevere esclusivamente il segnale in chiaro. Le API del Conditional Access sono designate in due parti distinte:

• Un modulo CA che viene usato per decifrare lo stream. Questo include le classi che rappresentano il modulo stesso e tutta l’infrastruttura necessaria per gestire le risorse usate a loro volta per decifrare il segnale.

• Un’interfaccia che "parla" con l’utente comunicandogli, con dialoghi e messaggi sullo schermo, quanto sta succedendo.

Per decifrare un segnale televisivo serve hardware e un software (l’algoritmo di decifratura) appropriato. In alcuni casi tutto questo è incluso in una smart card. Nel digitale terrestre è previsto l’utilizzo di "DVB Common Interface Module" ovvero moduli con formato PCMCIA che includono tutto ciò che è necessario per ottenere il segnale in chiaro. In generale la gestione del CA dipende dall’architettura del STB che può essere di due tipi: simulcrypt e multicrypt.

3.16 HTTPS MHP Il protocollo SSL utilizza combinazioni di chiavi pubbliche e simmetriche. Una sessione SSL inizia con uno scambio di messaggi effettuati nella fase detta “Handshake”. Vediamola in dettaglio. Il server ha un certificato che descrive le informazioni riguardanti la società/ente/persona. I campi più rilevanti sono le informazioni di cui sopra e la chiave pubblica. Il tutto è regolato dal Certificato X.509. Tale certificato può essere garantito da una Certification Authority, la quale assicura l’esatta corrispondenza tra il certificato e colui che lo emette. Anche il client può avere un certificato, ma questo serve solo se esso deve ricevere dati sensibili da parte del server. Generalmente è il contrario. Se la connessione è iniziata dal server, esso invierà al client un messaggio “server hello”. Se è il client ad iniziare la connessione, si avrà in invio un messaggio “hello”. Analizziamo più in dettaglio tale messaggio. E’ definito dai campi: 1. protocol version: definisce la versione SSL usata; 2. random byte: byte casuali generati dal client; 3. Session identifier: per verificare se si tratta di una nuova sessione o di una aperta in precedenza;



131

4. Lista delle CipherSuite: è una lista in cui il Client notifica al Server gli algoritmi di crittografia supportati, ordinati in modo decrescente; 5. Lista degli algoritmi di compressione supportati dal Client. Il Server risponde con un messaggio “server hello” definito nel modo seguente:

1. Protocol version: rappresenta la versione SSL scelta dal Server; 2. Random byte: byte generati in modo casuale; 3. Session identifier: identifica la sessione. Se non è una sessione

già aperta, se ne crea una nuova; questo nel caso in cui nel tag “session identifier” del messaggio “hello” sino presenti tutti zeri; Altrimenti viene riesumata la sessione indicata dal client, se presente nella cache del server;

4. ChiperSuite: famiglia di algoritmi di crittografia scelta dal server; 5. Compression method: metodo di compressione scelto da server.

Dopo questo scambio di messaggi, avviene l’autenticazione tramite lo scambio di un certificato. Supponiamo che debba essere il server ad identificarsi. Cit. L’arte dell’hacking di Jon Erickson. Questo vuol dire che i dati confidenziali transiteranno dal client al server e NON viceversa, in quanto il Client non è identificato. Tale situazione potrebbe essere, per esempio, una fase di acquisto in rete, in cui il client invia i suoi dati personali al Server, quindi è necessario che il Server sia ben identificato. Il Server dunque invia il certificato al Client, insieme alle preferenze riguardo l’algoritmo di crittografia da usare. A questo punto il client verifica che il certificato ricevuto sia valido analizzando vari aspetti. Per prima cosa la data di validità del certificato. In seguito, si verifica che la CA che garantisce il certificato (ammesso che ce ne sia una), sia una CA affidabile. Se lo è, il client recupera la chiave pubblica dalla sua lista di CA sicure per verificare la firma digitale arrivatagli con il certificato del server. Se l’informazione in tale certificato è cambiata da quando è stata firmata da una CA, o se la chiave pubblica nella lista CA non corrisponde alla chiave privata usata dalla CA per firmate il certificato del server, il client non potrà autenticare il server. Infine, il client verifica che il nome del dominio nel certificato server corrisponda allo stesso dominio del server. Questa fase conferma che il server è localizzato nello stesso indirizzo di rete che è specificato nel nome di dominio del suo certificato. Tale controllo previene attacchi del tipo “Man in the Middle”, in quanto se il domain name non corrisponde, molto probabilmente perché il certificato è stato inviato non dal server atteso, ma da una terza persona che si è intromessa. La connessione sarà rifiutata se i due nomi non corrispondono. Se invece tutto è andato a buon fine, il client avrà verificato che il server è affidabile. A questo punto il client genera una “pre master key” e la



132

cripta con la chiave pubblica del server. Opzionalmente, in questa fase, può essere richiesta l’autenticazione del client, che è molto simile a quella vista prima, nel seguente modo: esso deve cifrare alcuni valori casuali condivisi con la sua chiave privata, creando in pratica una firma. In più, il server verifica che il client, anche se autenticato, sia autorizzato ad accedere alle risorse richieste. La chiave pubblica nel certificato del client può facilmente convalidare tale firma se il certificato è autentico, in caso contrario la sessione sarà terminata. Il server riceve il messaggio criptato e, verificata l’attendibilità del client, lo decripta tramite la sua chiave privata. Genera poi una master secret (cosa che fa anche il client, seguendo gli stessi passi) e da questa, insieme, generano la chiave di sessione, una chiave simmetrica che sarà usata per criptare e decriptare i dati che attraversano il tunnel SSL appena creato; inoltre serve per verificare che i dati non vengano alterati nel lasso di tempo che intercorre tra l’invio e la ricezione. A questo punto il client ed il server si inviano un messaggio di notifica di HandShake concluso, e lo scambio di dati può iniziare.

Fig. 3.16 - Chiave Pubblica


Capitolo 4. ASUR zona 7

133


“C'è vero progresso solo quando i vantaggi di una nuova tecnologia diventano per tutti.”

Henry Ford

4.1 Presentazione dell’azienda Questo capitolo sarà interamente dedicato all’esperienza avuta in questi mesi presso il “CED” ed il “SIA” dell’Asur zona 7.

L’Azienda Sanitaria Unica Regionale (ASUR) è stata istituita con Legge Regionale n. 13 del 20 giugno 2003 "Riorganizzazione del Servizio Sanitario regionale" e svolge al livello centralizzato, funzioni di governo unitario ed omogeneo dei processi gestionali, secondo modalità definite dalla Giunta regionale delle Marche.

L’ASUR ha caratteristiche assolutamente innovative e non ha riferimenti analoghi nel panorama nazionale. Sul piano strategico richiede quindi una continua verifica delle iniziative intraprese per raggiungere la più elevata efficacia gestionale, aderente alla nuova logica organizzativa. Proprio perché l’orizzonte istituzionale di riferimento è molto distante dalla tradizionale architettura dei sistemi sanitari, il processo di trasformazione necessario si presenta senza precedenti.

Il sistema della regione Marche è stato storicamente caratterizzato dai seguenti elementi:

• �rilevante ed estesa copertura assistenziale in tutti gli ambiti del comparto socio-sanitario



134

• �necessità di recuperare una dimensione aziendale in grado di ottimizzare i processi produttivi e di integrarli all’interno di un sistema a rete

Questo scenario ha prodotto negli ultimi anni una situazione di disequilibrio a cui il governo regionale ha risposto con un riassetto istituzionale complessivo del sistema.

Il quadro di frammentazione istituzionale ed operativa delineato, l’esigenza di assicurare una transizione veloce e decisa, la necessità di proporre a tutti gli attori esterni ed interni un disegno facilmente intelligibile nel quale collocarsi rapidamente, l’opportunità di semplificare i meccanismi attuativi, la necessità di consolidare il ruolo di indirizzo e controllo svolto dagli enti locali, sono tutti elementi che hanno fatto propendere per la soluzione dell’azienda unica, basata sulle seguenti scelte:

- accorpamento delle 13 ASL in un’unica azienda sanitaria regionale

- istituzione di 13 zone (corrispondenti ai 13 ambiti territoriali delle ex ASL), dirette di un Direttore di zona nominato direttamente dalla Giunta regionale

- struttura organizzativa a "rete" nell’Azienda Unica: di ambito regionale per alcuni servizi amministrativi/sanitari, di dimensione di area vasta, zonale per altri.

L’obiettivo è quello di garantire un impianto dove le esigenze ed i contributi della rappresentanza politico-istituzionale, le razionalità aziendali e la razionalità dei processi tecnici possano trovare un contemperamento tale da assicurare alla collettività marchigiana un sistema sanitario equo e sostenibile.

La nuova struttura organizzativa è definita più in dettaglio nell’atto aziendale. Nell’ambito dell’autonomia organizzativa aziendale, l’Azienda disciplina la propria organizzazione assumendo come riferimento prioritario la centralità del cittadino ed il soddisfacimento dei suoi bisogni di salute.

L’intera struttura organizzativa è impostata non solo in un’ottica di controllo dei costi, ma di ricerca di un livello di servizio superiore per i clienti interni ed esterni. Le parole-chiave sono: innovazione,



135

efficienza, soddisfazione del cliente, mantenimento e miglioramento della qualità del servizio nel tempo.

Sul piano organizzativo-istituzionale, l’ASUR è articolata in tredici Zone Territoriali che hanno compiti di programmazione e gestione dei servizi sanitari e socio-sanitari nel rispettivo ambito territoriale, autonomia gestionale ed operativa. Per il periodo transitorio di due anni, sono dotate di personalità giuridica propria.

Le Zone Territoriali sono responsabili del governo clinico e assicurano alla popolazione residente le prestazioni incluse nei livelli essenziali di assistenza (LEA) e l’equo accesso ai servizi e alle funzioni di tipo sanitario, sociale e di elevata integrazione sanitaria, organizzate nel territorio zonale o aziendale.

Le Zone sono suddivise in distretti. Ogni Zona Territoriale è diretta da un direttore di Zona responsabile delle funzioni di programmazione e coordinamento, nonché della gestione complessiva del relativo ambito territoriale.

Fig 4.1 – Logo ASUR Marche Popolazione residente nei Comuni di competenza territoriale: 243.134

Territorio di competenza ha una superficie di: 473,72 Kmq

La Zona Territoriale fino al 13/12/2005 conserva autonomia gestionale ed organizzativa; mantiene inoltre le funzioni assistenziali fino ad ora svolte, connotandole ancora di più con quello che viene definito "governo clinico" basato sulla centralità dei bisogni del paziente, sulla ricerca delle migliori politiche assistenziali e sulla riduzione del rischio clinico; è nata una stretta integrazione con i servizi sociali; è prevista una ampia partecipazione dei cittadini e delle comunità locali alla tutela della salute con il loro coinvolgimento anche sulla programmazione dei servizi sanitari.

Nell' Area Sociale della Zona Territoriale 7 operano gli assistenti sociali: offrono ai cittadini italiani e stranieri, ai gruppi, alle famiglie e alle comunità in stato di disagio, ascolto, consulenza ed operatività rivolta a migliorare o risolvere la condizione di bisogno.



136

L' area sociale cura le tematiche ed i processi innovativi che si possono porre in atto per agevolare l'accesso ai servizi socio-sanitari ai cittadini stranieri attivando ed organizzando il servizio di Mediazione Interculturale.

Così si presenta la prima pagina del sito http://www.asurzona7.marche.it/

Fig. 4.2 – http://www.asurzona7.marche.it/ - Homepage del sito

4.2 I servizi online di Asur zona 7 Sono diverse le categorie alle quali vengono offerti servizi online:

• Cittadini

• Farmacisti

• Medici



137

Fig 4.3 – Pagina web di accesso ai servizi interattivi

Alla prima categoria vengono offerti servizi di: • Ricerca indirizzi e turni delle farmacie • Ricerca di medici e pediatri

• Elenco delle strutture sanitarie e relativi servizi a disposizione

• Recapiti ed indirizzi di enti per la tutela del malato • Motori di ricerca per trovare le strutture che erogano un servizio

sanitario desiderato • Informazioni sulle liste d’attesa

• Informazioni generiche come meteo, orari di treni ed autobus e altre notizie utili.

I farmacisti hanno accesso mediante password di riconoscimento a referti online del paziente. I servizi più avanzati sono destinati ai medici. Questi sono:

• CUP metropolitano

• ME.R.I.TO

Il CUP (centro unico di prenotazione) è un servizio esistente presso gli sportelli dell’ASUR. Negli ultimi anni è stata estesa la funzionalità di questo ad internet. Ad oggi ogni medico di base può prenotare una visita medica ad un suo paziente semplicemente attraverso l’utilizzo di un pc connesso ad internet. Ho avuto la fortuna durante il periodo di tesi di assistere ad una lezione per medici di base appunto sul funzionamento di questo sistema informatico di prenotazione. La



138

preparazione universitaria medica ed i requisiti di assunzione di un medico di base non prevedono l’utilizzo del calcolatore elettronico. Sono ancora pochi i medici che hanno familiarità con un pc (è difficile per qualcuno di loro avere familiarità con l’uso della penna, figuriamoci una tastiera…); qualcuno di loro probabilmente ne vedeva uno proprio quel giorno non sapendo nemmeno che esistesse una torretta collegata al monitor munita di un tasto di accensione. Sono entrato in quella sala con l’intenzione di creare un programma che permettesse la prenotazione di visite mediche attraverso tv digitale e ne sono uscito notevolmente scoraggiato. Il sistema di prenotazioni online su internet (CUP) è tanto completo quanto articolato; riassumo brevemente il contenuto della lezione illustrando un caso pratico utilizzando nomi di persone puramente immaginari e casuali. Il dott.Rossi riceve nel suo studio la signora Bianchi. La paziente lamenta un’attività cardiaca irregolare. Il dottore la visita e ne evince che la signora richiede una visita specialistica. Accende il suo pc e si collega ad internet. Entra nel sito http://www.asurzona7.marche.it /, clicca sull’icona in alto a destra del CUP metropolitano ed ha accesso alla pagina di autenticazione. Ogni medico ha una password personale la quale utilizza per diversi servi tra i quali questo di prenotazione. Il server verifica i dati immessi e in caso positivo riconosce il medico comunicandogli attraverso pop-up che il contenuto delle pagine navigate è protetto e crittografato. Nella pagina principale il medico vedrà nella barra in alto il suo nome e cognome per tutta la sessione di lavoro. Sotto troverà il suo numero di assistiti. Questo numero è costantemente aggiornato. A questo punto diverse sono le operazioni che può compiere il medico:

• Ricerca assistito • Prenota visita

• Visualizza lista assistiti

• Stampa prenotazioni

Il medico ricercherà la sua assistita mediante l’immissione dei dati della paziente: nome, cognome, data di nascita, sesso, codice fiscale, codice personale. Più saranno i dati immessi, meno probabilità ci sarà di ricevere una lista di risposta troppo lunga; anche perché questa contiene solo i primi 25 risultati trovati. Una ricerca per “sesso” sarà poco utile a meno di esser dotati di una notevole fortuna. Tuttavia mediante nome e cognome non si avranno problemi ad identificare il proprio assistito. Una volta trovato, sarà possibile consultare tutti i suoi ricoveri presso le strutture dell’Asur o prenotare una visita medica. L’attendo dott. Rossi, dopo aver consultato i ricoveri passati, passerà alla fase di prenotazione.



139

Richiamando dalla pagina personale dell’assistito, la pagina per la prenotazione, i dati personali vengono copiati direttamente dal programma. Sarà quindi ora necessario immettere gli ultimi dieci numeri della ricetta medica (è possibile utilizzare un lettore di codici a barre), selezionare la struttura desiderata (Ancona, Chiaravalle, Loreto, Osimo) e selezionare l’unità erogante (ad esempio il reparto di cardiologia viene offerto da diverse unità del territorio). Con un click sul bottone etichettato “Prima disponibilità” viene inoltrata la ricerca e dopo pochi secondi viene visualizzato il risultato. A questo punto il medico può prenotare la visita o cercare presso altre unità eroganti o altre strutture una “prima disponibilità” migliore. Una volta confermata la visita è possibile stamparla cliccando su “stampa” sul frame java sempre disponibile sulla sinistra dello schermo. Il servizio ME.R.I.TO. fa parte dei “vecchi servizi” dell’ASUR. Questo permette la visualizzazione di referti di radiologia e laboratorio analisi delle quattro strutture della zona7. Il funzionamento è simile a quello del CUP metropolitano ad eccezione del fatto che con questo non è possibile prenotare, ma soltanto consultare referti.

Fig. 4.4 – Pagina web di presentazione ed accesso del servizio ME.R.I.T.O

Tra qualche mese il CUP metropolitano verrà rimpiazzato dal più moderno SISTO che permetterà di sincronizzare il database dell’ASUR con quello dell’ospedale di torrette. Inoltre sarà possibile prenotare visite mediche non solo nella fascia oraria e nel giorno di prima disponibilità, ma verranno proposte più alternative in modo da favorire pazienti lavoratori e non solo.



140

Una cosa si evince da questi sistemi; la necessità di una stampante collegata al calcolatore e soprattutto il fatto che questi sistemi sono completamente ed unicamente dedicati ai medici. La mia tesi era nata con lo scopo di costruzione un programma per digitale terrestre in grado di poter prenotare visite mediche e diminuire il digital divide tra i possessori di pc e non. L’esperienza all’ASUR e l’interazione con i medici mi ha fatto dedurre che il mio obbiettivo era tanto realizzabile quanto inutile.

4.3 Servizi sanitari su digitale terrestre attualmente

in Italia e nel mondo Attualmente in Italia la tecnologia del digitale terrestre è in fase di rodaggio e sono pochi e servizi realmente funzionanti. Ho svolto una prova pratica. Acceso il STB e collegato al televisore, nella zona centrale di Ancona si ricevono circa 50 canali televisivi. Di questi solamente canale 5 ha un’applicazione “socialmente utile”, ma dedicata solamente ai possessori della carta regionale dei servizi lombardi e solamente ad i possessori del modello di decoder ADB T2000. Negli altri canali le xlet riguardano solo informazioni di pubblicità o servizi a pagamento. Tuttavia nei prossimi anni, soprattutto le televisioni locali diventeranno mezzo di diffusione di servizi di t-government. Con quest’ultimo terminie si intendono tutti i servizi offerti dalla pubblica amministrazione attraverso il mezzo digitale terrestre. Cercando in internet quali progetti siano in porto per questa futura televisione ho trovato spunti interessanti. Ci sono progetti per aiutare bambini con forme di dislessia (t-lessia), altri per dare una formazione specifica al cittadino (t-learning), altri di informazione su enti locali di sanità ed alcuni altri di scarso interesse. L’unico progetto dunque, anche se in fase di testing, è quello della regione Lombardia. Questo permette al cittadino dotato della CRS (carta regionale dei servizi) di avere accesso ad informazioni riguardo farmacie di turno, prenotazione di visite mediche (funzione ancora lontana dall’esser resa operativa) ed una funzione per la revoca/scelta del medico di base. Con il migliorarsi dell’architettura alla base del STB saranno possibili servizi molto + avanzati, come la cura remota di pazienti, l’interazione diretta audio/video con uno specialista, l’interazione con strumenti accessori per compiti specifici ed altro ancora. Il resto del mondo interessato al digitale terrestre (cfr. cap.1) sta investendo molto su progetti a riguardo della sanità e della pubblica amministrazione. Sempre su internet si possono trovare informazioni di progetti paralleli a quelli italiani. Una



141

volta che la diffusione del segnale sarà più nutrita, l’offerta di servizi ben funzionanti e testati attirerà l’attenzione di molte più persone rispetto a quelle che attualmente hanno iniziato a trarre i pochi vantaggi che ancora questa potente tecnologia offre.

4.4 Il SetTopBox da sviluppo ADB X-75 del ASUR zona 7 Per completare il ciclo di sviluppo di una applicazione MHP, dopo che è stata sviluppata con Eclipse e mandata in esecuzione su Xletview, manca solo la fase finale di test, che come abbiamo detto consiste nel caricare l'applicazione su un Set Top Box da sviluppo. Riassumendo il nostro ambiente di sviluppo quindi sarà costituito da un Personal Computer, da una normale TV munita di presa SCART e da il Set Top Box da sviluppo ADB X-75. Le interconnessioni tra gli apparati appena elencati, come mostrato in figura 4.5, sono:

• il STB riceve in ingresso il segnale televisivo (da una

comune antenna), è collegato tramite SCART alla TV, e tramite

seriale RS-232 al PC;

• sia il PC che il STB sono connessi in rete (LAN)

successivamente ne chiariremo il motivo.

Fig 4.5 – Postazione di lavoro all’ASUR zona 7



142

4.4.1 Caratteristiche Tecniche

Una delle più prestigiose ditte che forniscono strumenti per lo

sviluppo in campo broadcast è l'ADB, acronimo di Advanced Digital

Broadcast. La serie X-75 comprende Decoder da sviluppo per tre

tecnologie: Cable, Satellite, Terrestrial, in conformità con lo standard

DVB, quindi è più corretto chiamare il nostro strumento ADB T.75.

Andiamo ad elencare innanzitutto i componenti e le caratteristiche

Hardware mostrate nella seguente tabella 4.1: ARCHITETTURA DESCRIZIONE

CPU STi5517 166MHz

Tuner/Front end DVB-T

Flash Memory 16MB

RAM Memory 72 MB

EEPROM 32 kB

Power Supply 90-264 VAC, 47-63Hz

Casing 440x260x50mm

OUTPUTS

RF input/output RF in & RF out (loop trought)

Audio/Video outputs 2xRCA (Stereo Audio), 2xSCART, S/PDIF optical

Return channel Ethernet lOBaseT, PSTN modem v.92

Data port Debug serial port (RS-232 up to 115.2 kbps)

Front panel display 4x7-segment LED display, 2 LEDs

DVB-CI slot Located on front panel

Smart card slot Located on front panel

ACCESSORI

Power Cable 1.8 m

SCART Cable 1.5 m

RS 232 Cable 2.0 m

CARATTERISTICHE DESCRIZIONE

MPEG VIDEO DECODING



143

Standards MPEG-2 MP@ML, CD ISO/IEC 13818-1,

CD ISO/IEC13818-2

Video Data Rate 0.5-15Mbps

Format Conversion 4:3 > 16:9 with Pan & Scan and Letterbox

Graphics Planes 4 planes(Background, Stili-piane, Video, OSD)

AUDIO DECODING

Standards MPEG-1 Layer 1&2; lóbitprecision, CD ISO/IEC 13818-3

Sampling Rate 32kHz,44.1kHz,48kHz

Variable Output Level 16 steps @ 2dB per step

DOLBY Digital AC3 Pass throught to S/PDIF

TERRESTRIAL FRONTEND - T. 75

COFDM(DVB-T) ETSI EN 300 744

Modulation QPSK, QAM16, QAM64

Code rate

Guard Interval

½, 2/3, ¾, 5/6, 7/8

¼, 1/8, 1/16, 1/32

Transmission modes 2k, 8k

Tab. 4.1 - Aspetti tecnici del STB ADB X-75

Un STB di buon livello, reperibile attualmente in commercio,

presenta sicuramente le seguenti caratteristiche:

• modem V.90;

• lettore Smart Card;

• doppia presa SCART;

• uscita audio RCA;

• uscita audio ottica;

• connettore seriale RS-232 per eventuali periferiche di ingresso;

II nostro Set Top Box da sviluppo, oltre ad avere tutte le

caratteristiche di un normale decoder, presenta:

- una maggior capacità di elaborazione (frequenza processore più

elevata)



144

- una maggiore capacità di memorizzazione;

- interfaccia Ethernet;

- CI Common Interface;

- presa seriale RS-232 bidirezionale (permette l'upload

dell'applicazione e il debug).

4.4.2 Pannello frontale

Mostriamo ora nei dettagli il pannello frontale e le funzionalità dei suoi componenti, rispettivamente in figura 4.5 e nella tabella 4.2 componenti sono: 7 pulsanti, 2 indicatori LEDs, un display, una CI Common Interface e una OCF Smart Card slot.

Fig. 4.5 - Pannello frontale ADB T.75



145

Tab. 4.2 - Funzionalità pannello frontale

4.4.3 Pannello posteriore

In figura 4.6 si mostra come è composto il pannello posteriore.

Fig. 4.6 - Pannello posteriore ADB T.75

Vediamo in dettaglio i suoi componenti:

1. interruttore alimentazione;



146

2. presa alimentazione 220V ~ 50Hz;

3. connettore RS-232;

4. ingresso antenna;

5. uscita antenna (alla TV);

6. RJ11 jack modem;

7. RJ45 jack Ethernet;

8. Uscita AC3 ottica (Audio digitale);

9. SCART (connessione verso TV);

10. SCART (connessione verso eventuale VCR);

11. uscita audio RCA.

4.4.4 Telecomando

II telecomando e le funzionalità dei sui tasti sono mostrate in figura 4.7;

non ci sono molte differenze rispetto a quello dei comuni decoder, da

notare il tasto "APP" che apre e chiude la finestra delle applicazioni.



147

Fig. 4.7 – Telecomando e relative funzioni

4.4.5 Settaggio connessione di default

Diamo uno sguardo al menù principale del decoder ADB:

Fig. 4.8 – Organigramma del menù del STB ADB X-75

Tra i vari sottomenù della voce “Setting”, in fondo troviamo “Internet

Connection”, una volta entrati apparirà una schermata dove è possibile

scegliere se usare come predefinita la connessione tramite modem



148

PSTN o tramite Ethernet. La connessione Ethernet permette di far

comunicare Il STB con gli altri dispositivi della rete, a patto che al

decoder sia associato un indirizzo IP; per fare questo ci sono due modi

Auto e Manual . Se si imposta “Auto” dal menù, verrà assegnato un

Indirizzo IP dinamico (si suppone che il server della rete abbia abilitato

il DHCP). In caso contrario si dovrà impostare su “Manual” e Si

dovranno inserire i valori: IP (statico), Mask, Default Gateway e il DNS

primario e secondario. Modem Setting Se si vuole far connettere in rete

il STB, usando il Modem, bisogna impostare in questa schermata: N

telefonico ISP, eventuale prefisso, tipo composizione (impulsi/tone),

username, password ed eventualmente l’opzione “aspetta segnale di

libero”.

4.4.6 STB Firmware upgrade

Prima di passare all'upload di un'applicazione è necessario

aggiornare il firmware fornito dalla casa madre.

Il software che risiede nel Set Top Box (STB), consiste in due

parti principali: il decoder code e il loader.

Il decoder code, anche chiamato codice di alto livello, è responsabile

della ricezione, codifica e visualizzazione di audio/video, e altri

componenti come teletext, sottotitoli, etc.

Il loader non mostra ne video ne audio, ma visualizza all'utente

alcune informazioni riguardanti le fasi del processo o errori di

download.

L'ADB fornisce insieme al STB un software chiamato ADB FastTerm,

che interagisce con il loader per aggiornare il firmware tramite la porta

RS-232.

L'applicazione di cui sopra, si mostra come in figura 4.3.6.1; prima di

utilizzarla per prima cosa bisogna impostare il numero della porta

COM (dal menù a tendina), sulla quale è connesso il STB,

assicurandosi che questa sia settata con i seguenti parametri:



149

• Baudrate 115200

• N° bit di dati 8

• Parità NO

• N° bit di stop 1

A questo punto, dal menù File - Open download file, si va ad aprire il

file contenente l'aggiornamento (*.enc), si spegne il STB per almeno 2

secondi, si tiene premuto il tasto freccia sinistro situato sul pannello

frontale e contemporaneamente si riaccende il STB. Il tasto deve

continuare ad essere premuto fino a che non si accendono i LED

frontali, a questo punto si lascia il pulsante e inizia il download del

firmware sul STB; in questa fase la barra sulla destra dell'applicazione

inizia a colorarsi fino ad arrivare al 100%.

Fig. 4.9 - Finestra FastTerm



150

4.4.7 UpLoad e debug di un’applicazione La ditta produttrice del STB oltre al software “FastTerm”, fornisce anche l’ADB APPLOADER che permette di trasferire la nostra applicazione, dal PC alla memoria del decoder, sempre tramite porta seriale. In realtà la comunicazione tra i due dispositivi deve passare attraverso un secondo programma, che fa da Proxy, il quale può risiedere localmente o trovarsi in un’altra macchina, l’importante è che abbia un indirizzo IP valido e che sia connessa al STB. Quando si fa partire il Proxy, bisogna specificare il numero di porta COM (con gli eventuali settagli) dove è connesso il STB e il nome del file di log comprensivo di classpath; questo programma lavora usando il protocollo TCP sulla porta standard 4444, a meno che non specificato diversamente. Il file di log è un file di testo che viene generato dal STB ed è proprio questo che viene usato, in maniera simile al simulatore, come strumento di debug. La riga di comando con le varie opzioni e un’ esempio per inizializzare il Proxy sono: stbproxy.exe -com <port_number>[-port <TCP port number>] [-

rate<115200,8,N,1>][-log <logfile>]

stbproxy.exe –com 3 –log c:\stb.log

Lavorando sotto Windows apparirà un’icona sulla barra degli strumenti, dove è possibile accedere, tra le altre cose, all’opzione “svuotare” il file di log. L’ultima cosa da fare prima di passare all’ upload, è configurare il STB, a questo ci pensa un terzo tool chiamato “stbconfig” al quale bisogna specificare l’indirizzo IP dell’host dove si trova il Proxy e l’eventuale numero di porta, se non si usa quella di default; il suo scopo è quello di abilitare/disabilitare l’opzione di debug output e security manager. La riga di comando con le varie opzioni e un’ esempio per configurare il STB ipotizzando che il Proxy sia in locale, si usi il numero di porta TCP di default e si attivi solo l’opzione di debug sono: stbconfig.exe proxy_host_IP[:port] [-debug] [-security]

stbconfig.exe localhost -debug

Dopo aver effettuato la configurazione del STB si richiede il riavvio dello stesso. Finalmente siamo arrivati alla fase finale, il Proxy è in running, il STB è configurato, ora manca di avviare il trasferimento dell’applicazione. Il tool stbupload richiede l’IP del proxy, il nome del description file (vedremo in seguito cosa sia) completo di classpath, e il classpath della directory base dov’è contenuta l’applicazione (*.class e file accessori). La riga di comando con le varie opzioni e un’ esempio per fare l’upload di una applicazione contenuta nella directory c:\xlet\class, supponendo il Proxy in locale con porta di default sono: stbupload <proxy_host[:port]> <xlets_descr_file> <pc_base_dir>



151

stbupload localhost c:\xlet\xlet_desciption_file c:\xlet\class

Ora l’applicazione è copiata nella directory /home del file system del STB. 4.4.8 Xlet description file L’Xlet description file riflette il contenuto della tabella AIT (Application Identification Table); contiene tutte le informazioni e i parametri utili per l’identificazione e l’esecuzione dell’applicazione da parte del Set Top Box. Vediamone un’ esempio: Parametri obbligatori: #app <Application ID> <Organisation ID> app 0xhex_number 0xhex_number

#Application control flag: 1=autostart 2=present 3=destroy 4=kill control 1

#service bound flag (0 or 1) bound 0

#Basedir of application (must be relative to /home directory) basedir "/home"

#Initial class name (fully qualified name) class "your.company.Test"

Parametri opzionali: #Name of application preceded by language code name eng "Test"

#Parameter of service on which the application should be visible to application

manager tsid 0x7 onid 0x46 svid 0x2bd

#other flags priority 137 visibility 3

#Classpath extension classpath ""

#String params passed to Xlet param = "value 0" param = "value 1"

Ora cercheremo di spiegare in dettaglio i campi principali: app Ogni organizzazione che produce Xlet, deve essere riconosciuta, ed avere un codice identificativo univoco, in più ogni applicazione prodotta da quell’ organizzazione deve anch’essa essere riconoscibile univocamente. Questo per permettere al STB di non eseguire applicazioni maligne non riconosciute. control Questo flag dice al STB come si deve comportare con l’applicazione che ha ricevuto: se = 1 la manda in esecuzione appena caricata (per avvenire effettivamente l’esecuzione, nelle impostazioni base del STB deve essere abilitata l’opzione autostart); se = 2 il STB riceve l’applicazione è la mette disponibile nell’application manager, sarà l’utente poi a decidere quando farla avviare (premendo app oppure OK, in base al modello di decoder, si visualizzano le applicazioni disponibili); se =3 viene distrutta (si usa se caricata con autostart); se =4 viene killata (si usa se caricata con present);



152

bound Questo flag dice se si tratta di una applicazione bound (1) legata al canale e alla trasmissione o unbound (0) non legata alla trasmissione o addirittura non legata al canale (quindi disponibile indifferentemente dal canale su cui si è sintonizzati); basedir campo contenente il classpath di destinazione dell’applicazione del file system nel STB (deve essere relativo a /home); class deve contenere il nome della classe principale dell’applicazione (per es.:“main.class” ) name specifica il codice della lingua usata e il nome, relativo all’applicazione, che comparirà sull’Application Manager; priority nel caso in cui l’opzione “autostart” sia settata (nel menu di base del STB) e nell’Application Manager, vi sono più di una Xlet caricata con il control flag=1, il STB manda in esecuzione l’applicazione con la priorità più alta.


Capitolo 5. Xlet per ambito sanitario locale con servizi interattivi

153

Capitolo 5. Xlet per ambito sanitario locale

con servizi interattivi

“Non si conosce a fondo una scienza finché non se ne conosce la storia.” Auguste Comte

5.1 Premesse

Sempre più enti pubblici cercano di affacciarsi sulla nuova piattaforma del digitale terrestre. Sembra di rivivere l’avvento di internet. Analizzando le attuali emittenti televisive pronte alla tecnologia che abbiamo fin qui analizzato, si può notare che mentre fino allo scorso anno i contenuti erano per lo più sperimentali, ora si cominciano a vedere i primi servizi delle pubbliche amministrazioni. E’ il caso della Regione Lombardia citato nello scorso capitolo o degli altri non ci citati che verranno alla luce nei prossimi mesi. Ormai su internet la pubblica amministrazione offre moltissimi servizi. Pagare bollettini, avere informazioni di ogni genere, assistenza diretta e molto altro sono operazioni che oggi possono dirsi “di esperienza consolidata”. Tuttavia anche le più recenti statistiche ci dicono che internet in Italia è utilizzato da soli 18 milioni di cittadini.



154

“Utenti” internet in Italia 1997-2006 Numeri in migliaia

I dati su cui si basa questo grafico sono un po’ diversi da quelli della stessa fonte che vedremo più avanti.

In questo caso la definizione di “utente” è molto estesa. Si riferisce a persone che “dicono di essersi collegate

almeno una volta negli ultimi tre mesi”.

Confronto ad altri paesi, in Italia la diffusione di internet è ancora molto indietro rispetto a paesi nostri competitori economici.

“Utenti” internet in 10 paesi Percentuali sulla popolazione

Se poi ci confrontiamo contro la media dell’unione europea ci rendiamo conto che internet, nonostante la sua potenzialità, in Italia stenta a decollare, come attestano le statistiche della pagina successiva.



155

“Utenti” internet in 25 paesi (di cui 23 nell’Unione Europea)

Percentuali sulla popolazione dai 16 anni in su

Se poi si vanno ad analizzare le statistiche sull’utilizzo di internet per fascia di età, per reddito, per livello di istruzione e per zona geografica ci si accorge di quanto sia importante un mezzo di comunicazione che possa arrivare ad un numero di cittadini il più nutrito possibile. Qui sotto vediamo le statistiche sull’utilizzo di internet per fascia di età.



156

“Utenti” internet per età

Percentuali

I mezzi di comunicazione sulla quale oggi un cittadino, un ente, un azienda o addirittura uno stato possono contare sono: Libri, Giornali, Radio, Televisione, Internet e Cellulare.

Nella statistica in alto vediamo che l’Italia primeggia per quanto riguarda la percentuale di possessori di televisori e cellulari i quali si può affermare permeino completamente il territorio nazionale. E’ proprio questo che rende il digitale terrestre una tecnologia utile al nostro paese. Se anche nel resto d’Europa ed in altre parti del mondo sono notevoli gli investimenti economici in questo settore, in Italia questi diventano ancor più necessari.



157

Abbiamo parlato diffusamente di questa tecnologia nei capitoli precedenti, citandone pregi e difetti. Ora vogliamo sono applicarne i concetti alla realtà.

5.2 Il portale informativo per l’ASUR zona 7 Una delle più importanti aziende marchigiane è l’ASUR. Nel capitolo precedente se ne è parlato descrivendo i suoi attuali servizi disponibili su web. Prendendo a modello il sito internet, più volte citato nel capitolo 4, http://www.asurzona7.marche.it/, si è creata una xlet che permetta di avere le stesse informazioni del sito ad un qualsiasi cittadino munito di Set Top Box e raggiunto dalla trasmissione televisiva digitale ospitante il servizio. Il vantaggio di questo prodotto è quello di portare informazioni importanti in tutte le case. In particolare anziani, malati, invalidi ed le categorie sociali più sfortunate potranno finalmente usufruire sei servizi contenuti fino a ieri solo nel sito e da oggi anche sul televisore.

Fig. 5.1 – Set Top Box X-75 e Xlet per ASUR

Un servizio come questo non potevo prescindere dal fatto di essere un mezzo destinato a qualsiasi cittadino. Per questo è stata prestata particolare attenzione:



158

1. Alla scelta dei colori 2. All’adattabilità allo schermo televisivo 3. Alla guida alla navigazione 4. All’usabilità 5. Ai contenuti

5.2.1 Scelta dei colori

Lo schermo televisivo per sua natura risulta avere una gamma di colori più limitata rispetto ad un monitor di un personal computer. Esistono televisori moderni ai cristalli liquidi con proprietà uguali agli schermi sopracitati o TV a tubo catodico di elevata qualità che permettono di visualizzare gamme di colori vastissime, ma occorre studio il caso di un possessore di un 14 pollici economico per rendere la xlet visibile a tutti. Certamente questa attenzione limita la programmazione e la creatività, ma è necessaria. Da un lungo studio effettuato si è constatato che uno sfondo blu da diversi vantaggi:

• Quasi ogni colore attribuito ad una scritta su tale sfondo risulta ben visibile, in particolar modo per quanto riguardo il bianco.

• Per aumentare la piacevolezza e diminuire la monotonia allo sfondo si sono usate delle sfumature che rendono tutto più piacevole alla vista.

• I caratteri sullo schermo sembrano essere maggiormente in rilevo su uno sfondo del genere piuttosto che altri colori.

La scelta del colore dei bottoni per la navigazione della xlet sono associati a quelli del telecomando. La guida nella parte inferiore nello schermo è in un blu notte in alto contrasto con lo sfondo che lo rende poco invasivo, ma comunque ben visibile. Dunque sono stati scritti in bianco per quanto riguardo informazioni come titoli generici e di accesso a sottomenù; il nero i testi di informazione caricati dalla xlet ed il blu per la guida sullo schermo. L’intestazione, oltre a contenere i loghi di ASUR, Regione Marche e Università politecnica delle Marche, richiama il colore di quella del sito web. E’ importante anche tenere in considerazione persone con disturbi alla vista come i daltonici e quali verrebbero esclusi dall’utilizzo di coli in



159

basso contrasto tra di loro. Abbiamo cercato, nella scelta dei colori, di soddisfare queste esigenze. 5.2.2 Adattabilità allo schermo televisivo

Il digitale terrestre raggiungerà molti Set Top Box collegati a schermi da 42 pollici a cristalli liquidi, ma saranno molti di più i possessori di televisori classici a tubo catodico a 21 pollici o poco più ancora per molti anni. Gli attuali schermi televisivi hanno una risoluzione di 720x576 pixels. Nei capitoli precedenti abbiamo parlato di Safe Area. I test della xlet sono stati effettuati ancora su un 14 pollici economico per metterci nel caso pessimo. In questo caso i contenuti riempiono lo schermo, ma senza mai distorcesi non avendo mai sfruttato i pixels più marginali. Su uno schermo migliore e con diagonale maggiore la xlet avrà una cornice di non sfruttata, ma almeno per un po’ di anni sarà necessario tenere in considerazione televisori di vecchia generazione. 5.2.3 Guida alla navigazione

Molti si troveranno per la prima volta ad interagire con il televisore in maniera più articolata rispetto al normale televideo. Per questo è necessario avere sempre sullo schermo una guida che dica all’utente come muoversi tra i contenuti. Questa deve essere chiara e scritta con termini non tecnici, accessibili a tutti. Come ogni altro messaggio sullo schermo, la guida è stata studiata per essere letta anche su uno schermo a 14 pollici. Naturalmente la leggibilità sarà strettamente proporzionale alla diagonale dello schermo. Per il futuro sarebbe una buona idea realizzare questa guida anche sotto forma di audio messaggio in modo di aiutare i non vedenti. 5.2.4 Usabilità

Esistono diversi tipi di comunicazione. Ed ognuno di questi ha i suoi pregi ed i suoi svantaggi. La comunicazione vocale è facile da trasportare, ma con questa è difficile dare descrizioni tecniche senza l’ausilio dell’immagine. La comunicazione per immagini è uno strumento migliore per quanto riguarda la conservazione del messaggio, ma risulta male interpretabile; un esempio sono i quadri. Senza parlare



160

di altri tipi di comunicazione meno importanti, arriviamo direttamente alla comunicazione audio/video. Bene se dovessimo descrivere un tavolo, con la comunicazione audio daremmo subito un idea, ma è quasi impossibile descrivere l’esatto tipo e forma di tavolo. Con la comunicazione video questo sarebbe superato, ma ci sarebbe poca interazione. L’ibrido tra queste due forme di comunicazione permette di definire un tavolo univocamente e molto più velocemente. Per questo l’utilizzo della piattaforma digitale terrestre è uno strumento molto potente che permetterà di dare un’usabilità migliore alle informazioni. Le informazioni sullo schermo non sono mai eccessive e l’utente non si trova mai di fronte a troppe strade da prendere. E’ il limite imposto dalla ristretta disponibilità di tasti del telecomando, ma questo rende più “amichevole” l’interfaccia. Coloro che sono abituati ad interagire con siti internet potrebbero trovare talvolta banali i menù per digitale terrestre, ma si deve pur pensare che questi devono arrivare nelle case di tutti i cittadini. Nel caso del portale informativo dell’ASUR questo diventa ancor più importante analizzando il bacino di utenti. Di fatti sono soprattutto gli anziani e le classi più sfortunate che si rivolgono alla “ex-mutua”. Tra queste persone il livello di scolarizzazione è basso e quello di familiarità con la tecnologia ancor meno. Si è preso in analisi un servizio informativo tramite telefono cercandosi di mettere nei panni di una persona anziana. Questo per analizzare quali problemi potesse dare un menù di scelta troppo vasto. Paragoniamo un menù ad un albero. Il risultato dell’analisi ha visto che gli alberi con più di quattro rami principali sono dispersivi per l’utente, mentre quelli minori sono più facilmente interpretabili e non pongo troppi problemi all’utente. Questo deve poter decidere quale macro area sia quella più giusta per la sua specifica ricerca. E’ dunque importante anche una terminologia non troppo tecnica che non allontani il cittadino da tale mezzo. Le novità non sono facilmente adottate dopo una certa età. Riguardo i menù di navigazione dei servizi è molto importante la profondità di questi. Avendo molti contenuti da dover inserire in un portale informativo ed essendo necessario non spaesare l’utente con menù troppo articolati, questi potrebbe subire il contro effetto della estensione dei sottomenù. Sarebbe necessario non avere troppi livelli da esplorare, ma si è preferito tenere ridotte le macroaree ed aiutare il



161

cittadino tramite messaggi sullo schermo che danno costantemente informazioni sulla locazione all’interno della xlet. Abbiamo parlato in precedenza dell’importanza nella scelta dei colori. Per quanto riguarda l’usabilità deve risultare sempre intuitivo l’ulizzo di questi sul telecomando. Ogni persona è una “macchina pensante” a se, ma in ogni cultura il pensiero viene formato secondo precisi canoni. La psicologia ci insegna che se io scrivessi “premere il tasto verde” e poi accanto inserissi l’immagine del tasto rosso, l’utente sarebbe più portato a premere il tasto rosso. Sul telecomando di ogni Set Top Box ci sono solo quattro tasti colorati (rosso, verde, giallo, blu). Scrivere messaggi o inserire immagini sullo schermo che utilizzino questi colori potrebbe portare l’utente ad interpretare male le informazioni e non interpretare bene l’associazione dei colori alle diversi funzioni relative. Un altro limite che costringe a programmare utilizzando solo pochi colori ben in contrasto con questi del telecomando. Si utilizza perciò frequentemente il bianco ed il nero, nel nostro caso su uno sfondo bluette. Concludendo, la xlet è stata studiata per essere interpretata intuitivamente, ma comunque implementando una guida qualora non lo risultasse per qualcuno. 5.2.5 Contenuti

Per una facile lettura anche sul televisore sulla quale sono stati effettuati i test di “worst case” è necessario utilizzare dimensioni dei font superiori a 18 pixel. Questo aumenta lo spazio necessario alla visualizzazione di un testo. In un portale informativo questi sono ovviamente molti. Occorre dunque un attento lavoro di sintesi, il quale è sempre ben apprezzato in questi tempi. Per sua natura l’MHP carica testi da file.txt che di conseguenza non contengono dati su formattazione. Questa deve essere impostata staticamente dal programmatore. E’ stato problematico trovare una disposizione che permettesse una completa visualizzazione dei contenuti dei file di testo, ma alla fine si è costruita una formattazione su schermo facilmente ritoccabile anche i futuro e che soprattutto non richiederà al cittadino di collegarsi tramite linea di ritorno spendendo soldi nella chiamata.



162

5.3 Servizi non in linea Una volta entrati nella xlet la schermata che ci troveremo davanti sarà questa:

Fig. 5.2 – Pagina iniziale della xlet

Come si può vedere i servizi principali sono tre: • Informazioni sulle farmacie di Ancona • Informazioni su Medici Generici e Medici Pediatra • Numeri Utili delle molteplici strutture collegate all’ASUR zona 7

Dalla pagina iniziale è possibile accedere a tutte le altre categorie, ai contenuti in linea (interattivi) ed al portale dell’università politecnica delle Marche. Nella zona a sinistra dello schermo sarà possibile inserire messaggi importanti o link a sponsor. Per il momento si è inserito un messaggio di benvenuto. Premendo il tasto “verde” del telecomando viene caricata questa schermata:



163

Fig. 5.3 – Pagina principale del menù “Farmacie”

E’ stata presa in considerazione per il momento solo la città di Ancona, ma può essere facilmente inserita una pagina per selezionare la città di interesse. Per non caricare eccessivamente di informazioni l’utente, le farmacie sono state raggruppate per quartiere. Ogni quartiere è associato ad un numero. Premuto questo è possibile scorrere tra le pagine delle varie farmacie. Queste potrebbero anche sponsorizzare la xlet inserendo informazioni più dettagliate o foto a colori che possano attirare il cittadino interessato specificatamente alla ricerca di una farmacia. Questo genererebbe introiti a farmacie, ASUR ed emittenti televisive. Durante lo scorrimento delle pagine relative ognuna ad un solo medico, si potranno trovare informazioni su orari di ricevimento ed indirizzi degli stessi. Si è cercato di essere abbastanza precisi per quanto riguarda queste informazioni, ma un domani, qualora la xlet venisse trasmessa sarebbe necessario verificare i dati inseriti per ora solo a scopo dimostrativo. Tuttavia questi si attengo al quanto riportato dal sito web dell’ASUR. In questa sezione potrà anche essere ospitata una pagina relativa alle farmacie di turno, non appena l’ASUR renderà disponibile questo servizio al momento non presente nemmeno su web. Come in ogni sezione l’utente può conoscere sempre la sua posizione all’interno della xlet attraverso le informazioni costantemente aggiornate su schermo. Premendo il tasto “giallo” del telecomando entriamo nel sottomenù relativo ai “medici”.



164

Fig. 5.4 – Pagina principale del sottomenù Medici

La pagina viene caricata in pochi istanti e contiene una scelta tra “medici generici” e “medici pediatra”. Per entrambe le categorie è stato creato un sottomenù che da accesso a pagine relative a medici raggruppati per lettera iniziale del loro cognome. Anche questa rubrica può generare introiti dati dalla personalizzazione della pagina personale. Un’estetica migliore e dedicata potrebbe far aumentare il numero di assistiti di un medico. Inoltre ogni cittadino potrà sapere a che ora è possibile essere ricevuti dal proprio dottore. Premendo il tasto “blu” del telecomando si avrà accesso al sottomenù “numeri utili”.

Fig. 5.5 – Pagina principale del sottomenù Numeri Utili



165

L’azienda ASUR zona 7 della sezione di Ancona ha sotto di se molteplici istituti, organi e dipartimenti. Qualora si cercasse il numero di telefono di uno di questi la xlet ci verrebbe in aiuto guidandoci attraverso l’esplorazione delle voci visualizzate sullo schermo. Un servizio utile al cittadino che permette di unire la comunicazione attraverso digitale terrestre alla ben nota comunicazione vocale telefonica sempre utile per problematiche specifiche. Dalla pagina iniziale è possibile accedere sia a tutti gli altri sotto menù, ai contenuti interattivi, ma anche alla xlet di dell’università politecnica delle marche che ha curato questo progetto attraverso me, il mio relatore, il mio correlatore ed i ragazzi tirocinanti che ho coordinato durante il periodo di preparazione della tesi. Questa si presenta come visibile nella fig. 5.6.

Fig. 5.6 – Pagine iniziale del portale per digitale terrestre dell’Università Politecnica delle Marche

Anche questa xlet è dimostrativa. In futuro da questa base si potrà realizzarne una più completa. Già in passato questa xlet è stata usata da diversi studenti per progettare xlet di ogni specie per la particolare struttura “template” descritta nel testo “Studio di un Portale Informativo per la Facoltà di Ingengneria su Piattaforma Televisiva Digitale terrestre MHP con emulatore XletView 0.3.6” scritto da me stesso. Lo “swicth-off” previsto per il 2012 sembra lontano, ma non bisogna vedere tale data come inizio del processo di passaggio dalla televisione analogia a quella digitale. Tutt’altro; per il 2012 questo processo dovrà



166

essere ultimato, quindi occorre lavorare a questo cambiamento già da ora.

5.4 Servizi in linea L’idea iniziale della tesi è quella di costruire una xlet che permettesse di effettuare prenotazioni di visite mediche mediante SetTopBox. L’attuale sistema sanitario non prevede un’ operazione del genere nemmeno su web. Inoltre risulterebbe complicato ed inutile una prenotazione di una visita medica che potrebbe esser richiesta come frutto di una autodiagnosi non specialistica. Per questo ogni visita al momento viene richiesta e prenotata solomente dal medico generico o dal medico pediatra attraverso un servizio basato su internet. L’accesso è riservato solamente ai medici i quali hanno accesso a questo servizio unicamente mediante l’immissione delle proprie credenziali e password. La prenotazione a questo punto viene effettuata dal medico il quale specifica anche il numero delle ricetta. Si è parlo diffusamente di questo sistema nel capitolo 4 per questo non ci soffermeremo ulteriormente su questo aspetto. Aggiungo solo che l’architettura del Set Top Box per il momento vieta anche il collegamento con periferiche di stampa necessarie all’impegnativa risultato della prenotazione. La xlet costruita per la prenotazione quindi è mutata in una xlet per la cancellazione di visite mediche e servizio di agenda.

5.4.1 ASUR Reminder Il progetto è stato chiamato momentaneamente ASUR Reminder. Mediante questo un qualsiasi cittadino può avere accesso ad un limitato numero di informazioni riguardo le sue visite prenotate presso le strutture dell’ASUR. Basterà immettere i propri dati mediante l’utilizzo della tastiera su schermo ed in pochi istanti verranno caricati i dati relativi alla richiesta sullo schermo. Questo servizio può essere molto utile per ricordarsi di visite prenotate molti giorni dopo la richiesta. Capita spesso infatti di avere appuntamenti per visite che si terranno anche un anno dopo la domanda. Inoltre una volta visionate le visite prenotate è anche possibile cancellarle nel caso non si potesse più andare in tale appuntamento in modo da liberare spazi accelerando e potenziando il sistema di prenotazione di visite mediche attuale. Questa xlet non sarebbe una comune trascrizione di un servizio web per digitale terrestre, ma bensì uno strumento per migliorare l’attuale sistema, ma non per sostituirlo.



167

Inoltre si basa su una tecnica non invasiva che si inserisce nell’attuale sistema senza che questo debba essere ri-adattato.

Fig. 5.7 – pagina di accesso ai servizi multimediali

Dal portale descritto nel capitolo 5.3, dalla pagina iniziale è possibile accedere ai servizi in linea mediante la pressione del tasto “1” del telecomando. Una volta premuto questo tasto si verrà portati nella pagina in fig. 5.7. Una volta qui sarà visibile solo il tasto “connetti”. Premendo ancora “1” il Set Top Box tenterà la connessione telefonica ad un provider predefinito. Qualora questo corrispondesse ad un numero verde messo a disposizione del broadcaster o dall’ASUR, la connessione non avrebbe alcun costo. Si crede che un servizio di tale utilità dovrebbe essere reso gratuito anche perché in più punti di questa tesi sono stati trovati pregi che produrrebbero introiti. Facilmente questo potrebbero sostenere le spese di un numero verde. Una volta effettuata la connessione (circa un minuto per un modem 56K della quale sono dotati la quasi totalità dei STB sul mercato) comparirà sullo schermo anche il tasto “ASUR REMINDER”. Premendo “2” si avrà accesso alla xlet per la visualizzazione delle prenotazioni effettuate dal proprio medico e a quello per la cancellazione di queste.



168

Fig. 5.8 – Prima pagina del servizio interattivo

L’interfaccia per il momento è essenziale in quanto questo è solo un esempio dimostrativo del prodotto. Per il momento l’autenticazione viene fatto mediante l’immissione di “Cognome” e “password”.

Fig. 5.9 – Immissione dei dati e scelta della sede

Una volta immessi dati personali e password per il riconoscimento, si dovrà scegliere la sede alla quale mandare la ricerca. La zona territoriale 7 dell’Asur ha diverse strutture. Per il momento sono state indicate solo le sottozone principali a scopo dimostrativo.



169

Per l’immissione dei dati è stata implementata una tastiera su schermo. Nelle specifiche MHP c’è la richiesta di scrivere sotto i numeri anche delle lettere corrispondenti. Tuttavia queste sono scritte sul telecomando con caratteri minuscoli e difficilmente leggibili dalle persone anziane e in caso di scarsa luminosità. In questo modo la scrittura l’immissione diventa più facile ed anche persone con problemi articolatori potranno utilizzare facilmente la xlet. La scrittura mediante tecniche come T9 sono molti utili, ma persone affette da disturbi motori (vedi morbo di Alzheimer ad esempio) ne trovano impossibile l’utilizzo per via del timing tra l’immissione di un carattere ed un altro. Una guida è sempre visibile nella parte alta dello schermo. Questa è studiata in modo da dire all’utilizzatore cosa può fare in ogni punto nella quale esso si trovi. Una volta inseriti i dati si premere OK spostando il cursore sul tasto invia e si inoltra la ricerca. I tempi di risposta sono variabili e dovuti alla congestione della rete, alla disponibilità del server che si interroga e dal numero di visite da visualizzare. Nel caso la ricerca abbia risultato potremmo avere una schermata come la seguente.

Fig. 5.10 – Pagina contenente i risultati della ricerca che offre la possibilità di cancellare visite

precedentemente prenotate

Nella figura 5.10 abbiamo un esempio di risposta. Per questo xlet dimostrativa vengono selezionati solamente pochi dati. E’ possibile medico curante ed altro ancora contenuto nel data base dell’ASUR. Per il momento si è preferito non concentrarsi solo su dati necessari.



170

A questo punto il cittadino può uscire dall’applicazione, tornare indietro per cercare visite in altre sedi o cancellare una delle visite che sono state visualizzate. Qualora fosse proprio quest’ultima la sua intenzione dovrebbe semplicemente immettere i dati relativi al suo codice utente (numeri del tesserino sanitario) ed il codice associato alla visita alla quale non può recarsi. Inoltrata la richiesta, qualora i dati immessi risultassero validi avremmo davanti agli occhi una schermata come la seguente.caricare sullo schermo anche dati personali, struttura della visita,

Fig. 5.11 – Richiesta di conferma per la cancellazione della visita

La richiesta di cancellazione di una visita medica è un operazione che richiede la massima convinzione da parte del cittadino. Per questo motivo prima di continuare viene visualizzato un pop up che chiede una conferma prima di continuare. Si è pensato che fosse necessaria un’operazione del genere in quanto una volta cancellata una visita non potrebbe essere riprenotata più. Premendo su “NO” sarà possibile ricontrollare i propri dati o tornare indietro; premendo “SI” si inoltrerà la richiesta al server che in caso positivo risponderà producendo la seguente schermata.



171

Fig. 5.12 – Conferma di cancellazione

A questo punto l’utente è sicuro di aver cancellato la visita e ripetendo la ricerca si accorgerebbe che questa non viene più visualizzata. Dalla pagine di fig 5.12 premendo “ok” sul telecomando si torna alla pagina iniziale di ASUR REMINDER, altrimenti premendo il tasto “blu” si può uscire. All’uscendo dalla xlet si torna alla pagina del portale dell’ASUR ed in questa operazione viene anche sconnesso il Set Top Box dalla linea telefonica. 5.4.2 USABILITA’ Anche per la parte dei servizi interattivi si è posta molta attenzione all’usabilità. Per cancellare una visita , tralasciando le operazioni di immissione dati , occorrono semplicemente tre “click”, due per la visualizzazione delle visite prenotate. Quando un domani saremo tutti muniti della carta nazionale dei servizi le operazioni di immissione dati saranno banali come inserire una tessera in una telefono pubblico. Per spostarsi da una zona all’altra dello schermo di utilizzano i tasti colorati. La zona selezionata è indicata da un bordo “rosso accesso” in modo da far intuire all’utente che mediante il tasto rosso avrà il controllo di questo. Questo cursore rosso indica sempre dove andranno a finire i caratteri digitati sulla “tastiera televisiva” in modo che l’utente non possa mai perdere l’orientamento. Per il momento il sistema è stato programmato con “non case sensitive” in modo da non creare problemi. La tastiera ha sia tasti maiuscoli che tasti minuscoli, ma a meno che non



172

venga tolto il CAPS LOCK, questa rimarrà sempre sulle lettere maiuscole. Ogni volta che nella guida vengono citati i colori dei tasti, le scritte vengono fatte con il colore associato in modo da aumentare l’intuitività della xlet. Anche la grafica è stata tenuta essenziale per non appesantire il caricamento e per non disorientare l’utente. Un operazione come una cancellazione di una visita medica richiede molta concentrazione seppur sia un operazione banale per molti. Spesso la presenza di immagini distrae l’utente e si è cercato di evitare che questo accada. Per lo stesso motivo non viene visualizzata nessuna finestra per continuare a vedere le trasmissione televisive dell’emittente ospitante la xlet. 5.4.3 Sicurezza Vista la riservatezza dei dati della quale trattiamo sono necessarie tecniche di sicurezza avanzate. Nessun cittadino vorrà che qualcun altro possa vedere quali visite si siano prenotate. Per questo motivo è stata la comunicazione avviene attraverso connessione con SSL/TLS in modo che i dati scambiati vengano crittografati. Quando viene immessa la password questa viene visualizzata mediante una serie d’asterischi in modo da non farla visualizzazione ad altre persone fisicamente presenti al momento della digitazione. Qualcuno potrebbe pensare che la tastiera sullo schermo possa rivelare la password che si immette; si sbaglierebbero in quanto i tasti che vengono selezionati muovendosi a nelle quattro direzioni possibili vengono marcati di nero, ma non ci sono alcune segnalazioni luminose quando questi vengono selezionati. In futuro potrebbero essere implementati sistemi one time password in modo che una password, una volta usata, diventi inutile. Quest’operazione viene oggi usata da molte banche e seppur complicata da una notevole garanzia all’utente. Ad oggi, le specificazioni MHP 1.1.2 riguardanti il canale di ritorno mutuano lo standard del mondo Internet, impiegando una parte del protocollo Transport Layer Security (TLS). Le raccomandazioni in proposito coinvolgono la suite crittografica, RSA, MD5, SHA-1, DES. Con la versione 1.1.2, MHP introduce anche la parte del protocollo riguardante l'autenticazione del client, a condizione che sia fornita l'origine delle chiavi alla classe delle API Java javax.net.ssl.SSLContext attraverso un javax.net.ssl.KeyManager. La connessione TLS richiede, per poter essere stabilita, che almeno un certificato inviato dal server faccia parte di quelli autenticati del STB. Per evitare di subire attività fraudolente, il STB non può collegarsi ad un numero diverso da quello dell'Interactive Service Provider stabilito, a meno di un esplicito consenso da parte dell'utente a fronte di una obbligatoria richiesta da parte



173

dell'applicazione. Tale richiesta dovrà fornire all'utente almeno i dati dell'Organizzazione e del Certificato utilizzato per autenticare l'applicazione. La smart card aiuterebbe molto il processo di autenticazione e si è anche parlato nel capitolo 3 di come poter implementare una classe che gestisca questa risorsa. Tuttavia il STB da sviluppo in nostro possesso è aggiornato alla versione MHP 1.0.2 e non è stato possibile fare esperimenti a proposito. Nella tabella successiva ci sono le specifiche relative l’utilizzo della smart card nelle varie versioni MHP.

• MHP 1.0.2 e 1.0.3: non prevedono la gestione di smart card • MHP 1.1 e 1.1.1: prevedono la gestione dei lettori di smart card per il

attività di commercio elettronico attraverso l'Open Card Framework for Embedded Devices Specification 1.2.2 (OCF). Non prevedono invece la gestione dei lettori di smart card per l'accesso condizionato.

• MHP 1.1.2: ha sostituito le OCF, perché non più supportate, con il set di API Java, denominato "Security and Trust Services API for Java 2 Platform, Micro Edition", (SATSA 1.0).Ha sostituito inoltre le API di comunicazione con la smart card con “SATSA-APDU” utilizzato in Hava nella telefonia mobile.

Tab. 5.1 – MHP e smart card

5.5 Vantaggi e Svantaggi

Non si hanno statistiche dettagliate sul numero di visite che ogni giorno vengono prenotate e poi non usufruite. Tuttavia parlando con alcuni medici ho avuto la conferma che questo caso sia molto diffuso. Se ogni buco potesse essere riempito da un bisognoso se le liste di attesa non si riempirebbero con la facilità attuale e si massimizzerebbe l’efficacia del sistema di assistenza sanitaria. Il motivo principale che porta al non recarsi ad un appuntamento è la dimenticanza. Soprattutto nelle tipologie di assistenza dove le liste di attesa sono molto lunghe, capita spesso che i pazienti si dimentichino della richiesta di visita. In questo caso il servizio di Reminder diventa molto utile e facilmente accessibili vista la media oraria che il cittadino medio passa davanti alo schermo televisivo. Il sistema è completamente gratuito e permette di risparmiare soldi alle casse dell’ASUR. Non richiede una continua assistenza tecnica ed è adattabile a tutti i tipi di database mediante opportune modifiche al codice sorgente. Uno svantaggio è la necessità di collegarsi alla linea telefonica per avere accesso ai dati, ma come detto in precedenza, sarebbe necessario un numero verde erogante i servizi



174

online. Una spesa ridotta davanti ai grandi vantaggi offerti da questo prodotto.

5.6 Sviluppi futuri dei STB

Questa è solo una dimostrazione della potenzialità del mezzo televisivo digitale. Al momento la diffusione dei STB è limitata e quelli in circolazione non sono aggiornati con le ultime versioni di MHP. Per il momento è consigliato l’acquisto di apparecchi aggiornabili dotati di almeno un lettore di smart card. In futuro ogni televisore nascerà con la tecnologia digitale. Per il momento la ricezione dei canali digitali non è ancora sufficiente per poter consigliare l’acquisto di questi modelli di TV che si cominciano ad affacciare sul mercato. Preferibili sono per il momento i modelli analogici collegati a STB. Dunque stiamo vivendo un periodo di incertezza riguardo la definitiva piattaforma sulla quale verranno caricate le future applicazioni. Il consorzio DVB ed il team che lavora al miglioramento dell’MHP, Sun inclusa, spingono i produttori di STB alla produzione di modelli con strutture hardware sempre più potenti. Il calcolo richiesto da certi applicativi, soprattutto quelli che richiedono la crittografia o altri futuri, al momento risultano difficilmente adattabili ai modelli in commercio. Tuttavia l’attuale diffusione dei decoder per digitale terrestre non permette nemmeno ai produttori di poter mettere sul mercato prodotti a prezzi che attirino il compratore. D’altra parte abbiamo detto che un STB può considerarsi un vero e proprio computer collegato al televisore. Sono già molte le persone che abbinano al televisore un “pc da salotto” (come viene volgarmente chiamato). Il prezzo dei componenti per personal computer cala vistosamente di anno in anno. Sarà immaginabile che in futuro i STB diverranno dei veri e propri computer all’aumentare delle loro prestazioni. Questi apparecchi poterebbero unire i vantaggi offerti della ricezione dati via etere del digitale terrestre, al sempre più immenso mondo di internet. In qualche aspetto uno tenderà verso l’altro. Ad oggi la previsione più realistica è quella di un STB dotato di due canali di comunicazione (etere e telefonico). Questo verrà controllato tramite l’utilizzo del telecomando, ma si potranno interfacciare periferiche di ogni tipo. Sarà un centro di controllo domotico, secondo le previsioni di molti, in grado di dialogare con gli altri elettrodomestici, con le tapparelle, con le luci, il riscaldamento, l’impianto di sicurezza. L’evoluzione spinge inesorabilmente in questa direzione. In un mondo



175

in cui ormai tutto ormai è digitale, solo radio e televisione sono rimaste indietro in questo passaggio. C’è da aggiungere anche la forte pressione del mercato della produzione di televisori che da un notevole contributo a questo passaggio. In commercio ormai si trovano televisori in grado di visualizzare fino a 720, 1080 linee sullo schermo. Questi riproducono le immagini con una qualità straordinaria, ma al momento (seppur il mercato sia molto attratto da questi prodotti, credo per la pubblicità che se ne fa) solo pochi film in DVD e qualche console di videogiochi è in grado si sfruttare tali risoluzioni. Con il digitale terrestre nasceranno canali appositamente trasmessi per televisori con tecnologia HD (come già accade per il satellitare o la tv via cavo in America). Come tutte le nuove tecnologie, appena il cittadino medio vedrà anche dei contenuti utili, allora ci sarà un’accelerazione nel passaggio da analogico a digitale. Anche per questo la xlet oggetto di questa tesi ed altre di pubblica utilità sono tra le prime ad essere ben viste dal governo il quale molto sta investendo in questo passaggio, ma (a mio giudizio) con la non adeguata determinazione.

5.7 Sviluppi futuri della xlet

Seppur dimostrativa, la parte della xlet riguardante i contenuti non in linea è già pronta per essere trasmessa. Tutte le prove effettuate con essa hanno dato esito positivo. I contenuti sono gli stessi offerti dal sito web dell’ASUR. La xlet, nonostante il suo nutrito numero di informazioni offerte, risulta essere notevolmente leggera da caricare. In richiederà solo l’aggiornamento dei contenuti, qualora questi cambiassero. Si è parlato in precedenza dell’aspetto economico legato alla sponsorizzazione della xlet. Questa potrebbe generare introiti da farmacie o medici interessati ad una pubblicità sulla propria pagina. Qualora venisse presa questa strada sarebbe necessario un programmatore che modifichi il codice. Un’ operazione semplice, ma che richiede le dovute ed ovvie conoscenze. Si potrebbe anche creare una guida vocale che legga le informazioni contenute in modo da rendere la xlet accessibile anche ai non vedenti. Tuttavia per quanto riguarda la parte non in linea si può affermare che è pronta per la trasmissione. Per quanto riguarda i servizi in linea occorrerà fare qualche modifica al codice per renderlo adatto alla versione MHP 1.0.2 in dotazione sulla maggior parte dei decoder attualmente in commercio.



176

Questa è programmata sulle specifiche per MHP 1.1.x ed attualmente può girare solo su simulatore. Anche l’utilizzo della smart card che inizialmente ci si era prefissati come “must”, attualmente non è possibile sull’attuale versione di MHP a disposizione. In futuro basterà aggiungere il codice scritto nel capitolo 3 riguardo le smart card a quello attuale. Per quanto riguarda le query al database occorrerà conoscere precisamente l’organizzazione di quello sulla quale lavorare. Per il momento l’ASUR non ha messo a disposizione informazioni sul database in quanto molto riservate, ma qualora ci fosse interesse su questo servizio occorrerebbe solamente modificare i campi della select nell’ultima parte del codice. Un altro vantaggio rispetto a precedenti versioni di xlet di servizi per prenotazione deriva dall’utilizzo del server di origine dati di windows. Questo rende più facile l’utilizzo del server di invio e da la possibilità di lavorare con database di ogni natura, incluso access (di più larga fama rispetto ad mySQL o altri). Naturalmente un domani se fosse permessa la prenotazione di visite mediche al cittadino senza l’intervento del proprio dottore, questo codice è facilmente adattabile allo scopo. Un altro sviluppo che potrà avere questa parte di xlet sarà relativa ai messaggi di pop up. Inserendo la smart card personale nel STB la xlet potrebbe partire senza esser visionata sullo schermo, ricercare prenotazioni ed in caso ce ne fossero visualizzare una piccola, non invasiva, scritta su schermo che segnali al cittadino di entrare per leggere un’informazione su questa. La xlet riesce a cancellare visite mediche prenotate dagli archivi elettronici dell’ASUR, ma non è stato previsto per il momento nessun metodo di rimpiazzamento degli appuntamenti. Si potrebbero utilizzare tali buchi per urgenze o potrebbero essere destinati alle fasce più sfrtunate. Si potrebbe anche implementare una xlet che informi i cittadini di tali buchi. Le emittenti sarebbero molto felici di sfruttare la situazione aumentando il numero di ascoltatori in attesa di un fortunato evento. Anche se eticamente meno corretta, quest’ultima soluzione attirerebbe più emittenti al progetto creando un situazione di concorrenza più vantaggiosa all’ASUR.


Conclusioni e ringraziamenti

177


Il lavoro svolto è stato lungo, ma affascinante. Da giugno 2006 ad oggi il progetto è mutato più volte cercando di cavalcare i continui mutamenti tecnologici e politici avuti durante questo periodo. Sono fiero che tutto il personale tecnico ed amministrativo dell’ASUR zona 7 abbia apprezzato il risultato. I loro complimenti e la loro ferma intenzione di trasmettere quanto prima la xlet via etere mi rendere pieno d’orgoglio. Un’azienda importante come l’ASUR che comincia ad erogare servizi via etere per digitale terrestre servirà non solo ai cittadini, ma alla tecnologia stessa. Oggi viene considerata solo come una scatola da collegare al televisore per guardare partite di calcio. Questo va a snaturare e svalutare una tecnologia che invece potrebbe diminuire le differenze sociali rendendo l’informazione un bene per tutti. Questa innovazione tecnologica ha bisogno di servizi come quello di questa tesi per diffondersi ed acquistare la stima della gente di cui ha tanto bisogno. Una volta che ci sarà questa, allora assisteremo ad una nuova era della information tecnology e tutti ne vorrano far parte. In questo periodo ho avuto la possibilità di lavorare con persone molto serie, gentili e stimolanti come il prof. Dragoni ed il prof. Puliti. Devo ringraziare soprattutto il primo il quale mi ha seguito per molte ore dandomi sempre la giusta spinta e facendomi capire come organizzare al meglio il progetto. Li ringrazio inoltre per avermi dato la possibilità di tenere una lezione di tre ore agli studenti di ingegneria informatica del terzo anno. Questa esperienza mi ha dato molto ed è stata un piccolo sogno realizzato. Un ringraziamento va anche ai colleghi studenti del nuovo ordinamento che ho coordinato e seguito durante il loro periodo di tirocinio. Anche il personale dell’ASUR è sempre stato molto gentile, anche se i loro mezzi di sviluppo hanno complicato spesso il lavoro. Tuttavia il loro interesse al progetto mi ha spronato a superare i vari problemi che si sono presentati e creare un prodotto finale conforme a quanto richiesto. Devo invece criticare l’azienda ADB, fornitrice del STB da sviluppo, che ha sempre ignorato le ripetute richieste di aggiornamenti del firmware per il modello in possesso dell’ASUR.

Ringrazio i miei genitori che hanno sempre creduto in me dandomi la forza di superare alcune difficili giornate avute durante il corso dei miei studi. Spero che questo giorno possa riempirli di orgoglio. Tutti gli amici che mi hanno sempre voluto bene e mai tradito, vicini, lontani, vecchi e nuovi. Quello che sono lo devo anche a loro.



178

Il mio ricordo va a tutti i miei cari che non ci sono più; questo mio traguardo lo taglio insieme e grazie anche a voi. Pamela, con lei al mio fianco anche i momenti più duri sono stati felici; Se oggi scrivo queste righe lo devo a lei che mi ha sempre incoraggiato a continuare, anche quando avevo quasi deciso di mollare tutto.

Sono contento e convinto che tra qualche tempo avrò un forte mal di schiena, accenderò il televisore e mi sintonizzerò su “teleMarche” per vedere l’orario di ricevimento del mio medico generico. Il giorno dopo andrò da lui e mi farò prenotare una visita medica per la settimana successiva. Il giorno prima della visita avrò un imprevisto; accenderò il televisore dotato di STB e cancellerò la mia visita dagli archivi dell’ASUR rendendola disponibile per qualcun altro. Avrò ancora il mal di schiena ed in più un imprevisto, ma ci sarà stampato un sorriso sul mio volto… ho fatto parte di questo.


Appendice A

179

APPENDICE A. Xlet dei servizi non in linea

MainXlet.java

/* * Classe che implementa i metodi fondamentali necessari al funzionamento di una * Xlet, affinchè questa possa essere caricata su Set-Top Box o su un emulatore, * per esempio Xletview. */ // Per prima cosa, devono essere incluse le librerie necessarie import java.awt.Color; import java.awt.Font; import java.awt.Toolkit; import javax.tv.xlet.Xlet; //per creare, inizializzare, avviare, mettere in pausa e //distruggere una xlet,operazioni effettuate dall'application manager import javax.tv.xlet.XletContext; // per ottenere informazioni sull'ambiente di sviluppo della xlet, //una volta che questa viene inizializzata import javax.tv.xlet.XletStateChangeException; // per segnalare che il cambiamento di stato richiesto alla xlet è fallito import org.dvb.event.*; // per determinare gli eventi possibili sulla xlet import org.dvb.ui.DVBColor; import org.havi.ui.event.*; // per determinare le capacità e le modalità di input da parte dell'utente //della piattaforma su cui viene eseguita l'applicazione import org.havi.ui.HScene; // per rappresentare l'area visualizzabile nello schermo (in realtà non //viene creata, sono solo aggiunti i suoi componenti al contenitore) import org.havi.ui.HSceneFactory; // per generare effettivamente un oggetto di tipo HScene import org.havi.ui.HSceneTemplate; import org.havi.ui.HStaticIcon; import org.havi.ui.HStaticText; public class MainXlet implements Xlet, UserEventListener { private XletContext context; private HScene scene; private EventManager manager; private HStaticText testo2; private UserEventRepository repository; private BackgroundController backgroundManager; private HStaticIcon image, image1; private Thread tread; public HSceneFactory factory = HSceneFactory.getInstance(); XletInterface interfaccia; // metodo per inizializzare la Xlet, operazione segnalata da un messaggio public void initXlet(XletContext xletContext) throws XletStateChangeException { System.out.println("Inizializzazione della xlet"); context = xletContext; } // metodo per eseguire la Xlet, operazione segnalata da un messaggio


Appendice A

180

public void startXlet() throws XletStateChangeException { System.out.println("Esecuzione della xlet"); // viene creato un nuovo oggetto di tipo repository che funge da // magazzino per gli eventi possibili mediante il telecomando repository = new UserEventRepository("UserRepository"); repository.addAllColourKeys(); // aggiunti i tasti colorati repository.addAllArrowKeys(); // aggiunti i tasti con le frecce repository.addAllNumericKeys(); // aggiunti i tasti numerici repository.addKey(HRcEvent.VK_ENTER); // aggiunto il tasto "OK" repository.addKey(HRcEvent.VK_ESCAPE); // aggiunyo il tasto "EXIT" repository.addKey(428); // aggiunto il tasto "-" (meno) repository.addKey(427); // aggiunto il tasto "+" (più) repository.addKey(151); // aggiunto il tasto "*" (asterisco) repository.addKey(520); // aggiunto il tasto "#" (cancelletto) System.out.println("Setting Repository completato"); //manager = EventManager.getInstance(); //manager = EventManager.getInstance();

// per abilitare la rivelazione // degli eventi

manager = EventManager.getInstance();

// per abilitare la rivelazione degli eventi manager.addUserEventListener(this, repository); // si aggiungono gli eventi possibili // all'oggetto manager creato backgroundManager = new BackgroundController(); displayBackgroundImage1(); } // metodo per mettere in pausa la Xlet, operazione segnalata da un messaggio public void pauseXlet() { System.out.println("xlet in pausa"); context.notifyPaused(); // notifica al manager dell'applicazione che la // xlet non è attiva, in quanto è entrata in uno // stato di pausa } // metodo per distruggere la Xlet e rilasciare le risorse da questa // utilizzate, operazione segnalata da un messaggio public void destroyXlet(boolean flag) throws XletStateChangeException { System.out.println("Distruggendo Xlet....."); //manager.removeAllUserEventListeners(); interfaccia.destroy(); displayBackgroundExit(); System.out.println("Xlet distrutta"); context.notifyDestroyed(); // notifica al manager dell'applicazione che // la xlet è entrata nello stato // "Destroyed", in quanto è stata distrutta } // metodo per gestire gli eventi associati alla pressione dei tasti del // telecomando del Set-Top-Box public void userEventReceived(UserEvent event) { switch(event.getCode()){ case HRcEvent.VK_ESCAPE: System.out.println("Premuto exit"); //backgroundMager.dispose(); //era .doDestroy


Appendice A

181

try{ displayBackgroundExit(); destroyXlet(true); } catch(XletStateChangeException xsce) { xsce.getStackTrace(); } break; case HRcEvent.VK_COLORED_KEY_0: System.out.println("Premuto enter"); //backgroundMager.dispose(); //era .doDestroy scene.setVisible(false); testo2.setVisible(false); scene.remove(testo2); scene.remove(image); scene.removeAll(); factory.dispose(scene); factory.dispose(scene); start(); break; } } // metodo per caricare lo sfondo della Xlet quando questa va in esecuzione public void displayBackgroundImage() { if (backgroundManager.init()) { backgroundManager.display("background.jpg"); backgroundManager.hideVideo(context,0,0,0,0); // per nascondere il video // che potrebbe oscurare lo // sfondo caricato System.out.println("Immagine di background caricata"); } } public void displayBackgroundImage1() { if (backgroundManager.init()) { //backgroundManager.display("background.mpg"); backgroundManager.hideVideo(context,0,0,720,576); // per nascondere il video // che potrebbe oscurare lo // sfondo caricato System.out.println("bottone iniziale di background caricato"); HSceneTemplate hst = new HSceneTemplate(); scene =factory.getBestScene(hst); scene.setBounds(0, 0, 500, 200); //scene.setLayout(null); //scene.setBackgroundMode(HScene.BACKGROUND_FILL); image= new HStaticIcon(Toolkit.getDefaultToolkit().getImage("ok.jpg"),36,36,139,105); scene.add(image);


Appendice A

182

testo2 = new HStaticText("Premere il tasto ROSSO per\naccedere ai contenuti interattivi",36+139, 36, 300, 105);

testo2.setFont(new Font("Tiresias", Font.PLAIN, 24)); testo2.setBackground(new DVBColor(0, 0, 255, 200)); testo2.setForeground(Color.white); testo2.setHorizontalAlignment(HStaticText.HALIGN_LEFT); testo2.setVerticalAlignment(HStaticText.VALIGN_CENTER); scene.add(testo2); scene.setVisible(true); testo2.setVisible(true); tread =new Thread(); tread.start(); try { Thread.sleep(10000); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } testo2.setVisible(false); image.setVisible(false); image1= new HStaticIcon(Toolkit.getDefaultToolkit().getImage("rosso.jpg"),36,36,36,36); scene.add(image1); try { Thread.sleep(10000); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } image1.setVisible(false); } } public void displayBackgroundExit() { System.out.println("distruzione background"); backgroundManager.dispose(context); } public void start (){ System.out.println("Esecuzione della xlet"); //displayBackgroundExit(); // viene creato un nuovo oggetto di tipo repository che funge da // magazzino per gli eventi possibili mediante il telecomando //manager.removeUserEventListener(this); System.out.println("Loading Backgrond image....."); displayBackgroundImage(); // viene caricata l'immagine di background // (sfondo) interfaccia = new XletInterface();

// creato un nuovo oggetto di tipo // XletInterface, che si occupa // dell'aspetto grafico della Xlet e // del suo comportamento in risposta // all'interazione dell'utente. }

}


Appendice A

183

XletInterface.java

/* * Classe che si occupa dell'aspetto grafico della Xlet e del * suo comportamento in risposta all'interazione dell'utente. */ // Per prima cosa, devono essere incluse le librerie necessarie //import java.awt.Color; import java.awt.Color; import java.awt.Font; import java.awt.event.KeyEvent; // per associare un codice a ciascun evento, affinchè a questo //corrisponda un cambiamento grafico della xlet import java.awt.event.KeyListener; // per captare l'evento compiuto import org.dvb.ui.DVBColor; import org.havi.ui.HScene; // per rappresentare l'area visualizzabile nello schermo (in realtà //non viene creata, sono solo aggiunti i suoi componenti al contenitore) import org.havi.ui.HSceneFactory; // per generare effettivamente un oggetto di tipo HScene import org.havi.ui.HSceneTemplate; // per specificare la locazione e le dimensioni dell'oggetto HScene import org.havi.ui.HStaticText; import org.havi.ui.event.HRcEvent; public class XletInterface { public HStaticText testo6; private HScene scene; public static final int EXIT = HRcEvent.VK_ESCAPE; MyContainer first; MyContainer page; KeyListener listener; public XletInterface() { HSceneFactory factory = HSceneFactory.getInstance(); // HSceneFactory ritorna un appropriato contenitore HScene // che l'applicazione sfrutta per visualizzare essa stessa HSceneTemplate hst = new HSceneTemplate(); // un oggetto di questo tipo è necessario poichè // l'applicazione richiede che HSceneFactory // effettivamente gli garantisca l'accesso alla porzione di schermo // voluta, per esempio visualizzazione in full-screen scene =factory.getBestScene(hst); scene.setBounds(36, 29, 635, 510); // per settare i limiti dell'applicazione grafica scene.setLayout(null); // per settare a null la configurazione // (posizione?) dell'applicazione grafica scene.setBackgroundMode(HScene.BACKGROUND_FILL); // per settare la modalità di sfondo a "riempito" //scene.setBackground(new Color(255,255,255)); System.out.println("Creazione scena");


Appendice A

184

page = new MyContainer(0, 0, 635, 510); first = new MenuPrincipale(page, null); System.out.println("Creazione MenuPrincipale"); page.setVisible(true); // per visualizzare l'oggetto, che altrimenti // esisterebbe ma non sarebbe visibile first.setVisible(true); scene.add(page); // per aggiungere il nuovo oggetto di tipo // MyContainer a quello "scene" di tipo HScene testo6 = new HStaticText("CARICAMENTO IN CORSO...", 5,75+53+5+5+2+282+1,630,510-(75+53+5+5+2+282+1)); testo6.setFont(new Font("Tiresias", Font.PLAIN, 20)); testo6.setBackground(new DVBColor(255,0,0,255)); testo6.setForeground(Color.white); testo6.setHorizontalAlignment(HStaticText.HALIGN_CENTER); testo6.setVerticalAlignment(HStaticText.VALIGN_TOP); scene.add(testo6); testo6.setVisible(false); scene.addKeyListener(new KeyListener() { public void keyTyped(KeyEvent arg0) { } public void keyPressed(KeyEvent arg0) { MyContainer c = first; while (c.next != null) c = c.next; c.keyPressed(arg0.getKeyCode()); } public void keyReleased(KeyEvent arg0) { ; } }); // anche il rilascio del tasto premuto è in realtà un evento quindi // bisogna creare il metodo associato, affinchè a lato pratico, non // accada niente System.out.println("KeyListener ATTIVO"); scene.setVisible(true); scene.requestFocus(); scene.validate(); } // Metodo per la distruzione della Xlet public void destroy() {


Appendice A

185

if (scene != null) { System.out.println("Distruzione della Xletinterface"); scene.setVisible(false); //scene.removeKeyListener((KeyListener) this); scene.removeAll(); //scene.removeKeyListener((KeyListener) this); page.removeAll(); first.removeAll(); scene.setVisible(false); HSceneFactory.getInstance().dispose(scene); scene = null; } }

}

BackgroundController.java

import org.havi.ui.*; import org.davic.resources.*; import javax.tv.service.selection.*; import javax.tv.media.AWTVideoSizeControl; import javax.tv.media.AWTVideoSize; import java.awt.Rectangle; import javax.tv.xlet.XletContext;

class BackgroundController implements org.davic.resources.ResourceClient{ private HBackgroundDevice backdevice; private HStillImageBackgroundConfiguration backconfig; public boolean init() { HScreen screen = HScreen.getDefaultHScreen(); HBackgroundDevice backdevice = screen.getDefaultHBackgroundDevice();

HBackgroundConfigTemplate backgroundConfigurationTemplate = new HBackgroundConfigTemplate(); backgroundConfigurationTemplate.setPreference( HBackgroundConfigTemplate.FLICKER_FILTERING, HBackgroundConfigTemplate.REQUIRED); HBackgroundConfiguration backconfig; backconfig = backdevice.getBestConfiguration( backgroundConfigurationTemplate); if (backdevice.reserveDevice(this)) { try { backdevice.setBackgroundConfiguration(backconfig); } catch (Exception ex) { System.out.println("Can't initialise the background device"); backdevice.releaseDevice(); return false; }


Appendice A

186

if(backconfig instanceof HStillImageBackgroundConfiguration) { this.backconfig = (HStillImageBackgroundConfiguration)backconfig; this.backdevice = backdevice; return true; } else { backdevice.releaseDevice(); } } return false; } public void dispose(XletContext context) { if (backdevice != null) { this.hideVideo(context,0,0,720,576); backdevice.releaseDevice(); backdevice = null; backconfig = null; } } public void display(String filename) { if(backconfig != null) { HBackgroundImage backimage = new HBackgroundImage(filename); try { backconfig.displayImage(backimage); } catch (java.io.IOException ioe) { System.out.println("Can't display background image - IO exception"); ioe.printStackTrace(); } catch (HPermissionDeniedException hpde) { System.out.println("Can't display background image - permission denied"); } catch (HConfigurationException hce) { System.out.println("Can't display background image - configuration exception"); hce.printStackTrace(); } } } public void hideVideo(XletContext context,int x, int y, int larg, int alt) { ServiceContextFactory factory; factory = ServiceContextFactory.getInstance(); ServiceContext myContext = null; try { myContext = factory.getServiceContext(context); } catch (Exception e) { e.printStackTrace(); } if (myContext != null) { ServiceContentHandler[] handlers; handlers = myContext.getServiceContentHandlers(); for(int i=0; i < handlers.length ; i++) {


Appendice A

187

if (handlers[i] instanceof ServiceMediaHandler) { javax.media.Player p = (javax.media.Player) handlers[i]; AWTVideoSizeControl awtVideoSizeControl; awtVideoSizeControl = (AWTVideoSizeControl) p.getControl("javax.tv.media.AWTVideoSizeControl"); awtVideoSizeControl.setSize(new AWTVideoSize(new Rectangle(0, 0, 720, 576), new Rectangle(x,y,larg,alt))); } } } else { System.out.println("Can't get our service context. May not be able to " + "resize the video, so our background may not be visible"); } } public boolean requestRelease(ResourceProxy proxy, Object requestData) { return false; } public void release(ResourceProxy proxy) { backdevice.releaseDevice(); } public void notifyRelease(ResourceProxy proxy) { backdevice.releaseDevice(); }

}

MyContainer.java

import java.awt.BorderLayout; import java.awt.Toolkit; import org.havi.ui.HContainer; import org.havi.ui.HStaticIcon; //per rappresentare un'immagine grafica import org.havi.ui.HStaticText; public class MyContainer extends HContainer implements KeysInterface { private static final long serialVersionUID = 1L; protected MyContainer container = null; HStaticText testo6; protected MyContainer prev = null; XletInterface interfaccia; protected MyContainer next = null; public MyContainer() { super(); }


Appendice A

188

public MyContainer(int x, int y, int w, int h) { super(x, y, w, h); } public void init() { next = null; removeAll(); container.removeAll(); container.setLayout(new BorderLayout()); container.add(this, BorderLayout.CENTER); setLayout(null); System.out.println("Contenitore inizializzato "); } public void initAR() { next = null; removeAll(); interfaccia = new XletInterface(); container.removeAll(); container.setLayout(new BorderLayout()); container.add(this, BorderLayout.CENTER); setLayout(null); System.out.println("Contenitore inizializzato "); } public void update() { System.out.println("Contenitore aggiornato"); } public void keyPressed(int k) { switch (k) { case Telecomando.ROSSO: pressedRosso(); break; case Telecomando.VERDE: pressedVerde(); break; case Telecomando.GIALLO: pressedGiallo(); break; case Telecomando.BLU: pressedBlu(); break; case Telecomando.SU: pressedSu(); break; case Telecomando.GIU: pressedGiu(); break;


Appendice A

189

case Telecomando.SINISTRA: pressedSinistra(); break; case Telecomando.DESTRA: pressedDestra(); break; case Telecomando.OK: pressedOK(); break; case Telecomando.UNO: pressed_1(); break; case Telecomando.DUE: pressed_2(); break; case Telecomando.TRE: pressed_3(); break; case Telecomando.QUATTRO: pressed_4(); break; case Telecomando.CINQUE: pressed_5(); break; case Telecomando.SEI: pressed_6(); break; case Telecomando.SETTE: pressed_7(); break; case Telecomando.OTTO: pressed_8(); break; case Telecomando.NOVE: pressed_9(); break; case Telecomando.ASTERISCO: pressedAsterisco(); break; case Telecomando.CANCELLETTO: pressedCancelletto(); break; case Telecomando.ZERO: pressed_0(); break; case Telecomando.EXIT: pressedExit();


Appendice A

190

break; case Telecomando.MENO: pressedMeno(); break; case Telecomando.PIU: pressedPiu(); break; } } public void pressedRosso() { next = new MenuPrincipale(container, this); System.out.println("Tasto Rosso premuto -- MenuPrincipale"); } public void pressedVerde() { next = new Farmacie(container, this); System.out.println("Tasto Verde premuto -- Farmacie"); } public void pressedGiallo() { next = new Medici(container, this); System.out.println("Tasto Giallo premuto -- Medici"); } public void pressedBlu() { next = new NumeriUtili(container, this); System.out.println("Tasto Blu premuto -- NumeriUtili"); } public void pressedSu() { System.out.println("Tasto SU premuto -- pagina precedente"); } public void pressedGiu() { System.out.println("Tasto GIU premuto -- pagina successiva"); } public void pressedSinistra() { System.out.println("Tasto SINISTRA premuto -- torna al menu precedente"); if (prev != null) prev.init(); else System.exit(0); } public void pressedDestra() { } public void pressedOK() { } public void pressed_0() { System.out.println("Tasto 0 premuto "); } public void pressed_1() { System.out.println("Tasto 1 premuto "); }


Appendice A

191

public void pressed_2() { System.out.println("Tasto 2 premuto "); } public void pressed_3() { System.out.println("Tasto 3 premuto "); } public void pressed_4() { System.out.println("Tasto 4 premuto "); } public void pressed_5() { System.out.println("Tasto 5 premuto "); } public void pressed_6() { System.out.println("Tasto 6 premuto "); } public void pressed_7() { System.out.println("Tasto 7 premuto "); } public void pressed_8() { System.out.println("Tasto 8 premuto "); } public void pressed_9() { System.out.println("Tasto 9 premuto "); } public void pressedAsterisco() { } public void pressedCancelletto() { } public void pressedPiu() { } public void pressedMeno() { } public void pressedExit() { } //metodo per distruggere la xlet public void destroy(MyContainer container){ if(container!=null){ container.setVisible(false); container.removeAll(); container=null; System.out.println("Distruzione del contenitore completata"); } }


Appendice A

192

protected void addElements() { // richiamo questo metodo per visualizzare solo l'intestazione HStaticIcon i; // intestazione i = new HStaticIcon(Toolkit.getDefaultToolkit().getImage("intestazione.png"), 5, 0, 635,75); add(i); System.out.println("Immagine caricata: Intestazione aggiunta"); } protected void addElements1() {

// richiamo questo metodo per visualizzare i bottoni colorati HStaticIcon a,b,c,d; // bottone rosso a = new HStaticIcon(Toolkit.getDefaultToolkit().getImage("BottoneRossoChiaro.jpg"), 5, 76, 157, 53 ); add(a); System.out.println("Immagine caricata: BottoneRossoChiaro aggiunto"); // bottone verde b = new HStaticIcon(Toolkit.getDefaultToolkit().getImage("BottoneVerde.JPG"), 5+157+1, 76, 157, 53); add(b); System.out.println("Immagine caricata: BottoneVerde aggiunto"); // bottone giallo c = new HStaticIcon(Toolkit.getDefaultToolkit().getImage("BottoneGiallo.JPG"), 5+157+1+157+1, 76, 157, 53); add(c); System.out.println("Immagine caricata: BottoneGiallo aggiunto"); d = new HStaticIcon(Toolkit.getDefaultToolkit().getImage("BottoneBlu.JPG"), 5+157+1+157+1+157+1, 76, 157, 53); add(d); System.out.println("Immagine caricata: BottoneBlu aggiunto"); } protected void addElements2() { // richiamo questo metodo per visualizzare i bottoni colorati, //quando sono dentro al verde(farmacie) HStaticIcon i; // bottone rosso i = new HStaticIcon(Toolkit.getDefaultToolkit().getImage("BottoneRosso.JPG"), 5, 76, 157, 53); add(i); System.out.println("Immagine caricata: BottoneRosso aggiunto"); // bottone verde


Appendice A

193

i = new HStaticIcon(Toolkit.getDefaultToolkit().getImage("BottoneVerdeChiaro.JPG"), 5+157+1, 76, 157, 53); add(i); System.out.println("Immagine caricata: BottoneVerdeChiaro aggiunto"); // bottone giallo i = new HStaticIcon(Toolkit.getDefaultToolkit().getImage("BottoneGiallo.JPG"), 5+157+1+157+1, 76, 157, 53); add(i); System.out.println("Immagine caricata: BottoneGiallo aggiunto"); // bottone blu i = new HStaticIcon(Toolkit.getDefaultToolkit().getImage("BottoneBlu.JPG"), 5+157+1+157+1+157+1,76, 157, 53); add(i); System.out.println("Immagine caricata: BottoneBlu aggiunto"); } protected void addElements3() { // richiamo questo metodo per visualizzare i bottoni colorati, //quando sono dentro al giallo(medici) HStaticIcon i; // bottone rosso i = new HStaticIcon(Toolkit.getDefaultToolkit().getImage("BottoneRosso.JPG"), 5, 76, 157, 53); add(i); System.out.println("Immagine caricata: BottoneRosso aggiunto"); // bottone verde i = new HStaticIcon(Toolkit.getDefaultToolkit().getImage("BottoneVerde.JPG"), 5+157+1, 76, 157, 53); add(i); System.out.println("Immagine caricata: BottoneVerde aggiunto"); // bottone giallo i = new HStaticIcon(Toolkit.getDefaultToolkit().getImage("BottoneGialloChiaro.JPG"), 5+157+1+157+1, 76, 157, 53); add(i); System.out.println("Immagine caricata: BottoneGialloChiaro aggiunto"); // bottone blu i = new HStaticIcon(Toolkit.getDefaultToolkit().getImage("BottoneBlu.JPG"), 5+157+1+157+1+157+1, 76, 157, 53); add(i); System.out.println("Immagine caricata: BottoneBlu aggiunto"); } protected void addElements4() { // richiamo questo metodo per visualizzare i bottoni colorati, // quando sono dentro al blu(numeri utili) HStaticIcon i; // bottone rosso i = new HStaticIcon(Toolkit.getDefaultToolkit().getImage("BottoneRosso.JPG"), 5, 76, 157, 53); add(i); System.out.println("Immagine caricata: BottoneRosso aggiunto");


Appendice A

194

// bottone verde i = new HStaticIcon(Toolkit.getDefaultToolkit().getImage("BottoneVerde.JPG"), 5+157+1, 76, 157, 53); add(i); System.out.println("Immagine caricata: BottoneVerde aggiunto"); // bottone giallo i = new HStaticIcon(Toolkit.getDefaultToolkit().getImage("BottoneGiallo.JPG"), 5+157+1+157+1, 76, 157, 53); add(i); System.out.println("Immagine caricata: BottoneGiallo aggiunto"); // bottone blu i = new HStaticIcon(Toolkit.getDefaultToolkit().getImage("BottoneBluChiaro.JPG"), 5+157+1+157+1+157+1, 76, 157, 53); add(i); System.out.println("Immagine caricata: BottoneBluChiaro aggiunto"); }

}

MyText.java

import java.awt.Color; import java.awt.Font; import java.awt.Label; import java.awt.TextArea; import org.havi.ui.HStaticText; public class MyText extends HStaticText { private static final long serialVersionUID = 1L; private final Font FONT_DEFAULT = new Font("Tiresias", Font.PLAIN, 18); private Font font = FONT_DEFAULT; private int row = 8; private int rowMin = 1; private int rowMax = 40; private int numChar = 55; private int numCharMin = 1; private int numCharMax = 76; private Label pageLabel = null; private HStaticText pageHText = null; private TextArea pageText = null; private String file = null; private String DEFAULT_MESSAGE = "Nessuna informazione disponibile"; private Color background = Color.white; private Color foreground = Color.black; private int pageCurrent = 0; private int pageMax = 0; public int indiceMin = 0; public int indiceMax = 0; public int indiceCurrent = -1; private int pagina[][];


Appendice A

195

public MyText(int x, int y, int w, int h) { super("", x, y, w, h); setRow(row); } public void setRow(int r) { row = r < rowMax ? (r > rowMin ? r : rowMin) : rowMax; setMyText(); } public void setMyFont(Font f) { font = f; setMyText(); } public void setMyBackground(Color c) { background = c; setMyText(); } public void setMyForeground(Color c) { foreground = c; setMyText(); } public void setMyText() { this.setTextContent("", HStaticText.NORMAL_STATE); this.setFont(font); this.setBackground(background); this.setForeground(foreground); this.setHorizontalAlignment(HStaticText.HALIGN_LEFT); this.setVerticalAlignment(HStaticText.VALIGN_TOP); setNumChar(numChar); setText(file); } public void setNumChar(int n) { numChar = n < numCharMax ? (n > numCharMin ? n : numCharMin) : numCharMax; } public void setPageHText(HStaticText pageHText) { if (pageHText != null) { this.pageHText = pageHText; this.pageHText.setTextContent(getPageString(), HStaticText.NORMAL_STATE); } repaint(); } public void setPageLabel(Label pageLabel) { if (pageLabel != null) { this.pageLabel = pageLabel; this.pageLabel.setText(getPageString()); } repaint(); } public void setPageText(TextArea pageText) { if (pageText != null) { this.pageText = pageText; this.pageText.setText(getPageString()); } repaint(); } public String getPageString() { return "Pagina " + pageCurrent + " di " + pageMax; // per visualizzare a che pagina mi // trovo se il testo ne occupa più di una }


Appendice A

196

private void setL() { setPageHText(pageHText); setPageLabel(pageLabel); setPageText(pageText); } public void setText(String f) { this.setTextContent(this.getDEFAULT_MESSAGE(), HStaticText.NORMAL_STATE); this.file = null; resetIndici(); // indiceMin = 0 // indiceCurrent = 0 // indiceMax = 0 pageCurrent = 0; pageMax = 0; if (f != null && f.length() > 5) { file = f; setPage(); } setL(); repaint(); System.out.println("Oraganizzazione e visualizzazione pagine completata"); } private void setPage() { pageCurrent = 1; pageMax = 1; pagina = new int[file.length()][2]; pagina[0][0] = 0; int counter = 0; for (int k = 0; k < file.length(); k++) if (file.charAt(k) == '\n') { counter++; if (counter == row) { counter = 0; pagina[pageMax - 1][1] = k - 1; pageMax++; pagina[pageMax - 1][0] = k + 1; pagina[pageMax - 1][1] = file.length(); } } pagina[pageMax - 1][1] = file.length(); for (int i = 0; i < pagina.length; i++) //System.out.print(" " + pagina[i][0] + " " + pagina[i][1]); write(); } private void write() { if (file != null && file.length() > 0) this.setTextContent(file.substring(pagina[pageCurrent - 1][0], pagina[pageCurrent - 1][1]), HStaticText.NORMAL_STATE); setL(); } private void resetIndici() { indiceMin = 0; indiceCurrent = 0; indiceMax = 0; } public void pressedGiu() { if (this.pageCurrent < this.pageMax) { this.pageCurrent++; write(); System.out.println("Tasto GIU premuto -- Pagina successiva");


Appendice A

197

} } public void pressedSu() { if (this.pageCurrent > 1) { this.pageCurrent--; write(); System.out.println("Tasto SU premuto -- Pagina precedente"); } } public int getNumChar() { return numChar; } public HStaticText getPageHText() { return pageHText; } public int getRow() { return row; } public Label getPageLabel() { return pageLabel; } public TextArea getPageText() { return pageText; } public String getDEFAULT_MESSAGE() { return DEFAULT_MESSAGE; } public void setDEFAULT_MESSAGE(String default_message) { DEFAULT_MESSAGE = default_message; }

}

Lettore.java

// crea una sola stringa a partire da un file di testo,

// concatenando tutte le righe e ristituendo una stringa

import java.io.*;

public class Lettore {

public String LeggiFile(String filename)throws IOException{

String aggiungi = "\n";

String riga = new String();

String testo = new String();

BufferedReader in = new BufferedReader(new

FileReader(filename));

System.out.println("Lettura in corso del file: " +filename);

while((riga = in.readLine()) != null){

testo = testo.concat(riga);

testo = testo.concat(aggiungi);

}

System.out.println("Lettura completata");

return testo;

}

}


Appendice A

198

KeysInterface.java

// Interfaccia che contiene i metodi correlati alla pressione di un tasto del telecomando public interface KeysInterface { public void update(); public void keyPressed(int k); void pressedRosso(); void pressedVerde(); void pressedGiallo(); void pressedBlu(); void pressedSu(); void pressedGiu(); void pressedSinistra(); void pressedDestra(); void pressedOK(); void pressed_0(); void pressed_1(); void pressed_2(); void pressed_3(); void pressed_4(); void pressed_5(); void pressed_6(); void pressed_7(); void pressed_8(); void pressed_9(); void pressedAsterisco(); void pressedCancelletto(); void pressedPiu(); void pressedMeno(); void pressedExit(); }

Telecomando.java

import org.havi.ui.event.HRcEvent; public class Telecomando { public static final int UNO = HRcEvent.VK_1; public static final int DUE = HRcEvent.VK_2; public static final int TRE = HRcEvent.VK_3; public static final int QUATTRO = HRcEvent.VK_4; public static final int CINQUE = HRcEvent.VK_5; public static final int SEI = HRcEvent.VK_6; public static final int SETTE = HRcEvent.VK_7; public static final int OTTO = HRcEvent.VK_8; public static final int NOVE = HRcEvent.VK_9; public static final int ZERO = HRcEvent.VK_0; public static final int ROSSO = HRcEvent.VK_COLORED_KEY_0; public static final int VERDE = HRcEvent.VK_COLORED_KEY_1; public static final int GIALLO = HRcEvent.VK_COLORED_KEY_2; public static final int BLU = HRcEvent.VK_COLORED_KEY_3; public static final int SU = 38; public static final int GIU = 40; public static final int SINISTRA = 37; public static final int DESTRA = 39; public static final int OK = 10; public static final int ASTERISCO = 151; public static final int CANCELLETTO = 520; public static final int EXIT = HRcEvent.VK_ESCAPE; public static final int PIU = 427; public static final int MENO = 428; }


Appendice A

199

MenuPrincipale.java // Classe di rappresentazione della homepage (menu principale) // per utilizzare i contenitori che rappresentano la pagina visualizzata import org.havi.ui.HStaticIcon; //per visualizzare un'immagine import org.havi.ui.HStaticText; // per visualizzare gli oggetti di tipo testo // per fornire un layout (configurazione) dei componenti flessibile in //base al dispositivo di output (schermo) a disposizione import java.awt.Color; // per scegliere il colore di rappresentazione degli oggetti di testo import java.awt.Font; // per scegliere il carattere di rappresentazione degli oggetti di testo //import java.awt.Graphics; // per visualizzare l'aspetto grafico dell'applicazione import java.awt.Toolkit; // per gestire parametri come la risoluzione e la dimensione dello schermo import org.dvb.ui.*; public class MenuPrincipale extends MyContainer implements KeysInterface { private static final long serialVersionUID = 1L; public Font FONT; private HStaticText testo1; private HStaticText testo2; private HStaticIcon home; public MenuPrincipale(MyContainer container, MyContainer prev) { super(); this.container = container; this.prev = prev; init(); } public void init() { super.init(); addElements(); container.validate(); validate(); repaint(); } protected void addElements() { super.addElements(); super.addElements1(); FONT = new Font("Tiresias", Font.PLAIN, 18); testo1 = new HStaticText("" + "BENVENUTO\n" + "\n" + "Da oggi l'ASUR\n" + "zona territoriale 7\nANCONA\n" + "entra a casa tua",10,128,200,300); // tasto di collegamento ai servizi online testo1.setFont(new Font("Tiresias", Font.PLAIN, 26)); testo1.setBackground(new DVBColor(222,252,200,1)); testo1.setForeground(Color.white); testo1.setHorizontalAlignment(HStaticText.HALIGN_CENTER); //testo1.setVerticalAlignment(HStaticText.VALIGN_CENTER); add(testo1); testo2 = new HStaticText("Premere il COLORE corrispondente per selezionare " + "i contenuti, \nPremere il tasto '1' per accedere alla modalità " + "in linea\nEXIT per uscire",


Appendice A

200

5,75+53+5+5+2+282+1,630,510-(75+53+5+5+2+282+1)); testo2.setFont(new Font("Tiresias", Font.PLAIN, 20)); testo2.setBackground(new DVBColor(222,0,255,1)); testo2.setForeground(new Color(0,9,108)); //testo2.setHorizontalAlignment(HStaticText.HALIGN_JUSTIFY); testo2.setVerticalAlignment(HStaticText.VALIGN_CENTER); add(testo2); home = new HStaticIcon(Toolkit.getDefaultToolkit().getImage("home.jpg"), 635-420,75+53+5+5+2-10,420,282); add(home); // caricata l'immagine del menu principale System.out.println("Immagine caricata: Home aggiunta"); } public void pressed_1() { next = new WorkProgress(container, this); System.out.println("Accesso al contenitore ASUReminder"); } public void pressedRosso() { next = new MenuPrincipale(container, this); //System.out.println("Tasto Rosso premuto -- MenuPrincipale"); } public void pressedVerde() { next = new Farmacie(container, this); //System.out.println("Tasto Verde premuto -- Farmacie"); } public void pressedGiallo() { next = new Medici(container, this); // System.out.println("Tasto Giallo premuto -- Medici"); } public void pressedBlu() { next = new NumeriUtili(container, this); //System.out.println("Tasto Blu premuto -- NumeriUtili"); } public void pressedExit() { this.destroy(this); } }

Farmacie.java import org.dvb.ui.DVBColor; import org.havi.ui.HStaticIcon; import org.havi.ui.HStaticText; import java.awt.Color; import java.awt.Font; import java.awt.Toolkit; public class Farmacie extends MyContainer implements KeysInterface { private static final long serialVersionUID = 1L; private MyText testo1; private HStaticText testo2; private HStaticText testo3; public HStaticText testo4; private HStaticIcon image; private HStaticText testo5; public Farmacie(MyContainer container, MyContainer prev) { super(); this.container = container; this.prev = prev;


Appendice A

201

init(); } public void init() { super.init(); addElements(); container.validate(); validate(); repaint(); } protected void addElements() { super.addElements(); super.addElements2(); testo2 = new HStaticText("Premere il NUMERO o il COLORE corrispondente per selezionare i contenuti, \n freccia SINISTRA per tornare indietro\nEXIT per uscire", 5,75+53+5+5+2+282+1,630,510-(75+53+5+5+2+282+1)); testo2.setFont(new Font("Tiresias", Font.PLAIN, 20)); testo2.setBackground(new DVBColor(222,0,255,1)); testo2.setForeground(new Color(0,9,108)); //testo2.setHorizontalAlignment(HStaticText.HALIGN_JUSTIFY); testo2.setVerticalAlignment(HStaticText.VALIGN_CENTER); add(testo2); testo3 = new HStaticText("1) Centro\n\n" + "2) Stazione, Archi\n\n" + "3) I.N.R.C.A., Montagnola\n\n" + "4) Posatora\n\n" + "5) Piano\n\n" + "6) Tavernelle", 20, 75+53+5, 265, 75+53+5+5+2+282+1-(75+53+5+5+2-10)); testo3.setFont(new Font("Tiresias", Font.PLAIN, 20)); testo3.setBackground(new DVBColor(222, 252, 100, 1)); testo3.setForeground(Color.white); testo3.setHorizontalAlignment(HStaticText.HALIGN_LEFT); testo3.setVerticalAlignment(HStaticText.VALIGN_TOP); add(testo3); testo5 = new HStaticText( "7) Pinocchio\n\n" + "8) Brecce Bianche,\n Q2\n\n" + "9) Torrette,\n Collemarino,\n Montesicuro\n\n" + "0) Visualizza tutte", 480, 75+53+2, 200, 75+53+5+5+2+282+1-(75+53+5+5+2-10)); testo5.setFont(new Font("Tiresias", Font.PLAIN, 20)); testo5.setBackground(new DVBColor(222, 252, 100, 1)); testo5.setForeground(Color.white); testo5.setHorizontalAlignment(HStaticText.HALIGN_LEFT); testo5.setVerticalAlignment(HStaticText.VALIGN_TOP); add(testo5); image= new HStaticIcon(Toolkit.getDefaultToolkit().getImage("farmacia.gif"),220,130,181,193); add(image); System.out.println("Immagine caricata: farmacia.gif aggiunta"); } public void pressed_1() { next = new Centro(container, this); } public void pressed_2() { next = new StazioneArchi(container, this); } public void pressed_5() { next = new Piano(container, this); } public void pressed_4() {


Appendice A

202

next = new Posatora(container, this); } public void pressed_3() { next = new INRCA(container, this); } public void pressed_6() { next = new Tavernelle(container, this); } public void pressed_7() { next = new Pinocchio(container, this); } public void pressed_8() { next = new BrecceBianche(container, this); } public void pressed_9() { next = new Torrette(container, this); } public void pressed_0() { next = new tutte(container, this); } public void pressedGiallo() { next = new Medici(container, this); } public void pressedBlu() { next = new NumeriUtili(container, this); } public void pressedExit() { this.destroy(this); } public void pressedSu() { testo1.pressedSu(); } public void pressedGiu() { testo1.pressedGiu(); } }

Centro.java //dei sottomenù delle categoria “Farmacie” viene riportato solamente il codice //che carica le informazioni relative alla zona “Centro” di Ancona. //Le altre sono simili a questa e non vengono riportate per evitare ridondanza. import java.awt.Color; import java.awt.Font; import java.io.IOException; import org.dvb.ui.DVBColor; import org.havi.ui.HStaticText; public class Centro extends MyContainer implements KeysInterface { private static final long serialVersionUID = 1L; public Font FONT; private MyText testo1; private HStaticText testo2; private HStaticText testo3; private HStaticText page; public Centro(MyContainer container, MyContainer prev) { super(); this.container = container; this.prev = prev; init(); }


Appendice A

203

public void init() { super.init(); addElements(); read(); container.validate(); validate(); repaint(); } protected void addElements() { super.addElements(); super.addElements2(); FONT = new Font("Tiresias", Font.BOLD, 19); testo1 = new MyText(20, 177, 595, 245); testo1.setMyFont(FONT); testo1.setMyBackground(new DVBColor(222, 252, 200, 1)); testo1.setMyForeground(Color.black); //testo1.setHorizontalAlignment(HStaticText.HALIGN_JUSTIFY); testo1.setVerticalAlignment(HStaticText.VALIGN_TOP); testo1.setRow(20); add(testo1); testo1.setPageHText(page); page = new HStaticText("", 0, 159, 635, 18); page.setBackground(new DVBColor(222, 252, 254, 1)); page.setFont(new Font("Tiresias", Font.PLAIN, 18)); page.setForeground(Color.white); page.setHorizontalAlignment(MyText.HALIGN_CENTER); //page.setVerticalAlignment(MyText.VALIGN_CENTER); add(page); testo1.setPageHText(page); testo2 = new HStaticText("Premere i tasti SU e GIU' per scorrere le pagine\nSINISTRA per tornare indietro. EXIT per uscire", 5,75+53+5+5+2+282+1,630,510-(75+53+5+5+2+282+1)); testo2.setFont(new Font("Tiresias", Font.PLAIN, 20)); testo2.setBackground(new DVBColor(222,0,255,1)); testo2.setForeground(new Color(0,9,108)); //testo2.setHorizontalAlignment(HStaticText.HALIGN_JUSTIFY); testo2.setVerticalAlignment(HStaticText.VALIGN_CENTER); add(testo2); testo3 = new HStaticText("Farmacie di Ancona in Zona Centro", 0, 132, 635, 24); testo3.setBackground(new DVBColor(222, 252, 200, 1)); testo3.setForeground(Color.white); testo3.setFont(new Font("Tiresias", Font.PLAIN, 24)); testo3.setHorizontalAlignment(HStaticText.HALIGN_CENTER); //testo3.setVerticalAlignment(HStaticText.VALIGN_CENTER); add(testo3); } private void read() { Lettore lett = new Lettore(); String testo = new String(); try { testo = new String(lett.LeggiFile("farmCentro.txt")); } catch (IOException e) { System.out.println("File non trovato"); } testo1.setText(testo); }


Appendice A

204

public void pressedSu() { testo1.pressedSu(); } public void pressedGiu() { testo1.pressedGiu(); } }

Medici.java import org.dvb.ui.DVBColor; import org.havi.ui.HStaticText; import java.awt.Color; import java.awt.Font; public class Medici extends MyContainer implements KeysInterface { private static final long serialVersionUID = 1L; public Font FONT; private HStaticText testo2; private HStaticText testo3; private HStaticText testo4; public Medici(MyContainer container, MyContainer prev) { super(); this.container = container; this.prev = prev; init(); } public void init() { super.init(); addElements(); super.addElements3(); container.validate(); validate(); repaint(); } protected void addElements() { super.addElements(); super.addElements3(); testo2 = new HStaticText("1) Medico\n generico\n\n" + "2) Medico\n pediatra", 40, 75+53+43, 140, 204); testo2.setFont(new Font("Tiresias", Font.BOLD, 26)); testo2.setBackground(new DVBColor(222, 252, 200, 1)); testo2.setForeground(Color.white); testo2.setHorizontalAlignment(HStaticText.HALIGN_LEFT); //testo2.setVerticalAlignment(HStaticText.VALIGN_CENTER); add(testo2); testo3 = new HStaticText("Recapito dei medici di Ancona.\n" + "Selezionare la ricerca desiderata.", 210, 75+53+120, 300, 50); testo3.setBackground(new DVBColor(222, 252, 255, 1)); testo3.setForeground(Color.white); testo3.setFont(new Font("Tiresias", Font.PLAIN, 20)); //testo3.setHorizontalAlignment(HStaticText.HALIGN_JUSTIFY); //testo3.setVerticalAlignment(HStaticText.VALIGN_CENTER); add(testo3); testo4 = new HStaticText("Premere il NUMERO o il COLORE corrispondente per selezionare i contenuti, \n freccia SINISTRA per tornare indietro\nEXIT per uscire", 5,75+53+5+5+2+282+1,630,510-(75+53+5+5+2+282+1));


Appendice A

205

testo4.setFont(new Font("Tiresias", Font.PLAIN, 20)); testo4.setBackground(new DVBColor(222,0,255,1)); testo4.setForeground(new Color(0,9,108)); //testo2.setHorizontalAlignment(HStaticText.HALIGN_JUSTIFY); testo4.setVerticalAlignment(HStaticText.VALIGN_CENTER); add(testo4); } public void pressed_1() { next = new MedicoGenerico(container, this); } public void pressed_2() { next = new MedicoPediatra(container, this); } public void pressedVerde() { next = new Farmacie(container, this); } public void pressedBlu() { next = new NumeriUtili(container, this); } public void pressedExit() { this.destroy(this); } }

Medico Generico.java //Dal menù “medici” si ha accesso alle due sottocategorie “generico” e “pediatra”. //Riporto solo la categoria “generico” ed una sua relativa sottocategoria //relativa alla fascia di medici aventi Cognome con iniziale A, B o C import java.awt.Color; import java.awt.Font; //import java.awt.event.KeyEvent; //import java.awt.event.KeyListener; import org.dvb.ui.DVBColor; import org.havi.ui.HStaticText; public class MedicoGenerico extends MyContainer implements KeysInterface { private static final long serialVersionUID = 1L; public Font FONT; private HStaticText testo2; private HStaticText testo3; private HStaticText testo4; private HStaticText testo5; public MedicoGenerico(MyContainer container, MyContainer prev) { super(); this.container = container; this.prev = prev; init(); } public void init() { super.init(); addElements(); container.validate(); validate(); repaint(); } protected void addElements() { super.addElements();


Appendice A

206

super.addElements3(); FONT = new Font("Tiresias", Font.PLAIN, 15); testo2 = new HStaticText("Premere SINISTRA per tornare indietro\nEXIT per uscire", 5,75+53+5+5+2+282+1,630,510-(75+53+5+5+2+282+1)); testo2.setFont(new Font("Tiresias", Font.PLAIN, 20)); testo2.setBackground(new DVBColor(222,0,255,1)); testo2.setForeground(new Color(0,9,108)); //testo2.setHorizontalAlignment(HStaticText.HALIGN_JUSTIFY); testo2.setVerticalAlignment(HStaticText.VALIGN_CENTER); add(testo2); testo3 = new HStaticText("Medici Generici di Ancona", 10, 125, 620, 120); testo3.setBackground(new DVBColor(222, 252, 200, 1)); testo3.setForeground(Color.white); testo3.setFont(new Font("Tiresias", Font.PLAIN, 28)); testo3.setHorizontalAlignment(HStaticText.HALIGN_CENTER); //testo3.setVerticalAlignment(HStaticText.VALIGN_CENTER); add(testo3); testo4 = new HStaticText( "Selezionare il numero corrispondente\nall'iniziale del cognome del medico ricercato.", 90, 160, 460, 132); testo4.setFont(new Font("Tiresias", Font.PLAIN, 21)); testo4.setBackground(new DVBColor(222, 252, 200, 1)); testo4.setForeground(Color.white); //testo4.setHorizontalAlignment(HStaticText.HALIGN_JUSTIFY); //testo4.setVerticalAlignment(HStaticText.VALIGN_CENTER); add(testo4); testo5 = new HStaticText( "1) A, B, C 2) D, E, F 3) G, I, L\n\n + "4) M, N, O 5) P, Q, R\n\n 6) S, T, U 7) V, Z", 16, 245, 600, 200); testo5.setFont(new Font("Tiresias", Font.PLAIN, 28)); testo5.setBackground(new DVBColor(222, 252, 200, 1)); testo5.setForeground(Color.black); testo5.setFont(new Font("Tiresias", Font.PLAIN, 26)); //testo5.setHorizontalAlignment(HStaticText.HALIGN_JUSTIFY); testo5.setVerticalAlignment(HStaticText.VALIGN_CENTER); add(testo5); testo6 = new HStaticText("CARICAMENTO IN CORSO...", 5,75+53+5+5+2+282+1,630,510-(75+53+5+5+2+282+1)); testo6.setFont(new Font("Tiresias", Font.PLAIN, 20)); testo6.setBackground(new DVBColor(255,0,0,255)); testo6.setForeground(Color.white); testo6.setHorizontalAlignment(HStaticText.HALIGN_CENTER); testo6.setVerticalAlignment(HStaticText.VALIGN_TOP); add(testo6); testo6.setVisible(false); } public void pressed_1() { next = new MGABC(container, this); } public void pressed_2() { next = new MGDEF(container, this); } public void pressed_3() { next = new MGGIL(container, this); } public void pressed_4() { next = new MGMNO(container, this);


Appendice A

207

} public void pressed_5() { next = new MGPQR(container, this); } public void pressed_6() { next = new MGSTU(container, this); } public void pressed_7() { next = new MGVZ(container, this); } }

MGABC.java import java.awt.Color; import java.awt.Font; import java.io.IOException; import org.dvb.ui.DVBColor; import org.havi.ui.HStaticText; public class MGABC extends MyContainer implements KeysInterface { private static final long serialVersionUID = 1L; public Font FONT; private MyText testo1; private HStaticText testo2; private HStaticText testo3; private HStaticText page; public MGABC(MyContainer container, MyContainer prev) { super(); this.container = container; this.prev = prev; init(); } public void init() { super.init(); addElements(); read(); container.validate(); validate(); repaint(); } private void read() { Lettore lett = new Lettore(); String testo = new String(); try { testo = new String(lett.LeggiFile("genericiABC.txt")); } catch (IOException e) { System.out.println("File non trovato"); } testo1.setText(testo); } protected void addElements() { super.addElements(); super.addElements3(); FONT = new Font("Tiresias", Font.PLAIN, 19); testo1 = new MyText(30, 220, 660, 298); testo1.setMyFont(FONT); testo1.setMyBackground(new DVBColor(222, 252, 200, 1));


Appendice A

208

testo1.setMyForeground(Color.black); testo1.setHorizontalAlignment(HStaticText.HALIGN_JUSTIFY); testo1.setVerticalAlignment(HStaticText.VALIGN_TOP); testo1.setRow(20); add(testo1); page = new HStaticText("", 460, 180, 120, 25); page.setBackground(new DVBColor(222, 252, 254, 1)); page.setFont(new Font("Tiresias", Font.PLAIN, 18)); page.setForeground(Color.white); page.setHorizontalAlignment(MyText.HALIGN_RIGHT); page.setVerticalAlignment(MyText.VALIGN_CENTER); add(page); testo1.setPageHText(page); testo2 = new HStaticText("Premere i tasti SU e GIU' per scorrere le pagine\nSINISTRA per tornare indietro. EXIT per uscire", 5,75+53+5+5+2+282+1,630,510-(75+53+5+5+2+282+1)); testo2.setFont(new Font("Tiresias", Font.PLAIN, 20)); testo2.setBackground(new DVBColor(222,0,255,1)); testo2.setForeground(new Color(0,9,108)); //testo2.setHorizontalAlignment(HStaticText.HALIGN_JUSTIFY); testo2.setVerticalAlignment(HStaticText.VALIGN_CENTER); add(testo2); testo3 = new HStaticText("Medici Generici ( A, B, C )", 50, 105, 620, 120); testo3.setBackground(new DVBColor(222, 252, 200, 1)); testo3.setForeground(Color.white); testo3.setFont(new Font("Tiresias", Font.PLAIN, 24)); testo3.setHorizontalAlignment(HStaticText.HALIGN_CENTER); testo3.setVerticalAlignment(HStaticText.VALIGN_CENTER); add(testo3); } public void pressedSu() { testo1.pressedSu(); } public void pressedGiu() { testo1.pressedGiu(); } }

Numeri Utili.java

import org.dvb.ui.DVBColor; import org.havi.ui.HStaticIcon; import org.havi.ui.HStaticText; import java.awt.Color; import java.awt.Font; import java.awt.Toolkit; public class NumeriUtili extends MyContainer implements KeysInterface { private static final long serialVersionUID = 1L; public Font FONT; private HStaticText testo2; private HStaticText testo3; private HStaticIcon centralino; public NumeriUtili(MyContainer container, MyContainer prev) {


Appendice A

209

super(); this.container = container; this.prev = prev; init(); } public void init() { super.init(); addElements(); container.validate(); validate(); repaint(); } protected void addElements() { super.addElements(); super.addElements4(); testo2 = new HStaticText("Premere il NUMERO o il COLORE corrispondente per selezionare i contenuti, \n freccia SINISTRA per tornare indietro\nEXIT per uscire", 5,75+53+5+5+2+282+1,630,510-(75+53+5+5+2+282+1)); testo2.setFont(new Font("Tiresias", Font.PLAIN, 20)); testo2.setBackground(new DVBColor(222,0,255,1)); testo2.setForeground(new Color(0,9,108)); //testo2.setHorizontalAlignment(HStaticText.HALIGN_JUSTIFY); testo2.setVerticalAlignment(HStaticText.VALIGN_CENTER); add(testo2); //FONT = new Font("Tiresias", Font.PLAIN, 18); testo3 = new HStaticText( "1) DIPARTIMENTI\n" + "2) DIREZIONE DI ZONA\n" + "3) DISTRETTO NORD - CENTRO - SUD\n" + "4) PRESIDIO OSPEDALIERO UNIFICATO\n" + "5) FUNZIONI DI STAFF\n" + "6) GUARDIA MEDICA\n" + "7) CENTRALINI\n" + "8) SERVIZIO MEDICINA LEGALE\n", 20, 75+53+5, 340, 290); testo3.setFont(new Font("Tiresias", Font.PLAIN, 20)); testo3.setBackground(new DVBColor(222, 252, 200, 1)); testo3.setForeground(Color.white); testo3.setHorizontalAlignment(HStaticText.HALIGN_LEFT); testo3.setVerticalAlignment(HStaticText.VALIGN_CENTER); add(testo3); centralino = new HStaticIcon(Toolkit.getDefaultToolkit().getImage( "centralino.jpg"), 380,178,250,198); add(centralino); } public void pressed_1() { next = new Dipartimenti(container, this); } public void pressed_2() { next = new DirZona(container, this); } public void pressed_3() { next = new NoCeSu(container, this); } public void pressed_4() { next = new PresOspUni(container, this); } public void pressed_5() { next = new FunzioniStaff(container, this); }


Appendice A

210

public void pressed_6() { next = new GuardiaMedica(container, this); } public void pressed_7() { next = new Centralini(container, this); } public void pressed_8() { next = new ServMedLeg(container, this); } public void pressedVerde() { next = new Farmacie(container, this); } public void pressedGiallo() { next = new Medici(container, this); } }

Dipertimenti.java import org.dvb.ui.DVBColor; import org.havi.ui.HStaticIcon; import org.havi.ui.HStaticText; import java.awt.Color; import java.awt.Font; import java.awt.Toolkit; public class Dipartimenti extends MyContainer implements KeysInterface { private static final long serialVersionUID = 1L; public Font FONT; private HStaticText testo2; private HStaticText testo3; private HStaticIcon centralino; public Dipartimenti(MyContainer container, MyContainer prev) { super(); this.container = container; this.prev = prev; init(); } public void init() { super.init(); addElements(); container.validate(); validate(); repaint(); } protected void addElements() { super.addElements(); super.addElements4(); testo2 = new HStaticText("Premere il NUMERO o il COLORE corrispondente per selezionare i contenuti, \n freccia SINISTRA per tornare indietro\nEXIT per uscire", 5,75+53+5+5+2+282+1,630,510-(75+53+5+5+2+282+1)); testo2.setFont(new Font("Tiresias", Font.PLAIN, 20)); testo2.setBackground(new DVBColor(222,0,255,1)); testo2.setForeground(new Color(0,9,108)); //testo2.setHorizontalAlignment(HStaticText.HALIGN_JUSTIFY); testo2.setVerticalAlignment(HStaticText.VALIGN_CENTER);


Appendice A

211

add(testo2); FONT = new Font("Tiresias", Font.PLAIN, 18); testo3 = new HStaticText("

1) DIPARTIMENTO AMMINISTRATIVO\n\n" + "2) DIPARTIMENTO DI PREVENZIONE\n\n" + "3) DIPARTIMENTO DIPENDENZE\n\n" + "4) DIPARTIMENTO FARMACEUTICO\n\n", 20, 130, 320, 365); testo3.setFont(new Font("Tiresias", Font.PLAIN, 20)); testo3.setBackground(new DVBColor(222, 252, 200, 1)); testo3.setForeground(Color.white); testo3.setHorizontalAlignment(HStaticText.HALIGN_LEFT); testo3.setVerticalAlignment(HStaticText.VALIGN_CENTER); add(testo3); centralino = new HStaticIcon(Toolkit.getDefaultToolkit().getImage( "centralino.jpg"), 400, 178, 250, 198); add(centralino); } public void pressed_1() { next = new DipAmm(container, this); } public void pressed_2() { next = new DipPrev(container, this); } public void pressed_3() { next = new DipDip(container, this); } public void pressed_4() { next = new DipFarm(container, this); } }

DipAmm.java import java.awt.Color; import java.awt.Font; import java.io.IOException; import org.dvb.ui.DVBColor; import org.havi.ui.HStaticText; public class DipAmm extends MyContainer implements KeysInterface { private static final long serialVersionUID = 1L; public Font FONT; private MyText testo1; private HStaticText testo2; private HStaticText testo4; private HStaticText page; public DipAmm(MyContainer container, MyContainer prev) { super(); this.container = container; this.prev = prev; init(); } public void init() { super.init(); addElements(); read(); container.validate();


Appendice A

212

validate(); repaint(); } private void read() { Lettore lett = new Lettore(); String testo = new String(); try { testo = new String(lett.LeggiFile("NUDipAmm.txt")); } catch (IOException e) { System.out.println("File non trovato"); } testo1.setText(testo); } protected void addElements() { super.addElements(); super.addElements4(); FONT = new Font("Tiresias", Font.BOLD, 19); testo1 = new MyText(15, 200, 700, 258); testo1.setMyFont(FONT); testo1.setMyBackground(new DVBColor(222, 252, 200, 1)); testo1.setMyForeground(Color.black); testo1.setHorizontalAlignment(HStaticText.HALIGN_JUSTIFY); testo1.setVerticalAlignment(HStaticText.VALIGN_TOP); testo1.setRow(20); add(testo1); page = new HStaticText("", 460, 180, 120, 25); page.setBackground(new DVBColor(222, 252, 254, 1)); page.setFont(new Font("Tiresias", Font.PLAIN, 18)); page.setForeground(Color.white); page.setHorizontalAlignment(MyText.HALIGN_RIGHT); page.setVerticalAlignment(MyText.VALIGN_CENTER); add(page); testo1.setPageHText(page); testo2 = new HStaticText("Premere i tasti SU e GIU' per scorrere le pagine\nSINISTRA per tornare indietro. EXIT per uscire", 5,75+53+5+5+2+282+1,630,510-(75+53+5+5+2+282+1)); testo2.setFont(new Font("Tiresias", Font.PLAIN, 20)); testo2.setBackground(new DVBColor(222,0,255,1)); testo2.setForeground(new Color(0,9,108)); //testo2.setHorizontalAlignment(HStaticText.HALIGN_JUSTIFY); testo2.setVerticalAlignment(HStaticText.VALIGN_CENTER); add(testo2); testo4 = new HStaticText( "Numeri Utili -> DIPARTIMENTI -> DIPARTIMENTO AMMINISTRATIVO", 0,150, 670, 25); testo4.setBackground(new DVBColor(222, 252, 200, 30)); testo4.setForeground(Color.white); testo4.setFont(new Font("Tiresias", Font.PLAIN, 19)); testo4.setVerticalAlignment(HStaticText.VALIGN_CENTER); add(testo4); } public void pressedSu() { testo1.pressedSu(); } public void pressedGiu() { testo1.pressedGiu(); } }


Appendice A

213

XletUNIVPM.java //in seguito è riportato il codice sorgente della xlet che si collega a quella dell’ASUR //per dare accesso al portale per digitale terrestre dell’Università Politecnica delle Marche //Sie ne riportano le due classi principali: XletUNIVPM e XletInterfaceU import java.awt.event.KeyEvent; import java.awt.event.KeyListener; import javax.tv.xlet.XletContext; import javax.tv.xlet.XletStateChangeException; import org.dvb.event.*; import org.havi.ui.event.*; public class XletUNIVPM extends MyContainer implements KeyListener { private static final long serialVersionUID = 1L; private XletContext context; private EventManager manager; private UserEventRepository repository; private final int DESTRA = 0; private final int SINISTRA = 1; XletInterfaceU interfaccia; BackgroundControllerU backgroundManager; public XletUNIVPM()

{ } public void init(XletContext xletContext) throws XletStateChangeException { System.out.println("Eseguo initXlet"); context = xletContext; } public void start() throws XletStateChangeException { System.out.println("Eseguo startXlet"); repository = new UserEventRepository("UserRepository"); repository.addAllColourKeys(); repository.addAllArrowKeys(); repository.addKey(HRcEvent.VK_ENTER); manager = EventManager.getInstance(); manager.addUserEventListener(null, repository); displayBackgroundImage(); interfaccia = new XletInterfaceU(); interfaccia.disegnaSchermo(); } public void pause() { System.out.println("Xlet in pausa"); context.notifyPaused(); } public void destroy(boolean flag) throws XletStateChangeException { System.out.println("Distruggi Xlet"); interfaccia.destroy(); context.notifyDestroyed(); } public void userEventReceived(UserEvent event) { switch (event.getCode()) { case HRcEvent.VK_COLORED_KEY_0: System.out.println("Premuto rosso"); break;


Appendice A

214

case HRcEvent.VK_COLORED_KEY_1: System.out.println("Premuto verde"); break; case HRcEvent.VK_COLORED_KEY_2: System.out.println("Premuto giallo"); break; case HRcEvent.VK_COLORED_KEY_3: System.out.println("Premuto blu"); interfaccia.destroy(); try { destroy(true); } catch (XletStateChangeException xsce) { xsce.getStackTrace(); } break; case HRcEvent.VK_UP: System.out.println("Premuto su"); interfaccia.iUp(); interfaccia.aggiornaPulsanti(); break; case HRcEvent.VK_DOWN: System.out.println("Premuto giu"); interfaccia.iDown(); interfaccia.aggiornaPulsanti(); break; case HRcEvent.VK_RIGHT: System.out.println("Premuto destra"); interfaccia.frecciaPremuta = DESTRA; interfaccia.aggiornaContenuto(); break; case HRcEvent.VK_LEFT: System.out.println("Premuto sinistra"); interfaccia.frecciaPremuta = SINISTRA; interfaccia.aggiornaContenuto(); break; case HRcEvent.VK_ENTER: System.out.println("Premuto enter"); interfaccia.j = 1; interfaccia.frecciaPremuta = -1; interfaccia.visualizza(interfaccia.i); break; } } public void displayBackgroundImage() { BackgroundController backgroundManager = new BackgroundController(); if (backgroundManager.init()) { backgroundManager.display("background.jpg"); backgroundManager.hideVideo(context,0,0,0,0); } } public void keyPressed(KeyEvent arg0) { // TODO Auto-generated method stub } public void keyReleased(KeyEvent arg0) { // TODO Auto-generated method stub } public void keyTyped(KeyEvent arg0) { // TODO Auto-generated method stub


Appendice A

215

} }

XletInterfaceU.java

import java.awt.*;

import org.havi.ui.HDefaultTextLayoutManager;

import org.havi.ui.HScene;

import org.havi.ui.HSceneFactory;

import org.havi.ui.HScreen;

import org.havi.ui.HState;

import org.havi.ui.HText;

import org.havi.ui.HIcon;

import org.havi.ui.HVisible;

public class XletInterfaceU {

private HScene scene;

private HText testo;

private HText titolo;

private HIcon intestazione;

private HIcon legenda;

private HIcon galleria;

private HIcon home;

private HIcon b_1;

private HIcon b_2;

private HIcon b_3;

private HIcon b_4;

private HIcon b_5;

private HIcon b_6;

private int tastoPremuto = 0;

public int frecciaPremuta = -1;

private final int B_1 = 0;






private final int DESTRA = 0;

private final int SINISTRA = 1;

private String nomeFileTesto = "storia_1.txt";

private String nomeFileTitolo = "titolo_home.txt";

public int i = 0;

public int j = 1;

int attivo = 1;

boolean testovisibile = false;

boolean check = true;;

String immagine;

public XletInterfaceU() {

}

public void disegnaSchermo() {


Appendice A

216

HSceneFactory hsceneFactory =

HSceneFactory.getInstance();

scene =

hsceneFactory.getFullScreenScene(HScreen.getDefaultHScreen().getDef

aultHGraphicsDevice());

scene.setSize(720, 576);

scene.setLayout(null);

//chiamate al metodo NomeFile nella classe CaricaFile

String contenutoTesto =

CaricaFile.NomeFile(nomeFileTesto);

String contenutoTitolo =

CaricaFile.NomeFile(nomeFileTitolo);

titolo= new HText(contenutoTitolo, 120, 95, 590, 25,

new Font("Tiresias", Font.BOLD, 20), Color.white, Color.black, new


scene.add(titolo);

testo= new HText(contenutoTesto, 120, 130, 590, 410,

new Font("Tiresias", Font.PLAIN, 16), Color.white, Color.black, new


scene.add(testo);

testo.setHorizontalAlignment(HVisible.HALIGN_LEFT);

testo.setVisible(false);

if (testovisibile)

testo.setVisible(true);

home = new

HIcon(Toolkit.getDefaultToolkit().getImage("home.jpg"), 120, 130,

590, 410);

home.setVisible(true);

scene.add(home);

galleria = new

HIcon(Toolkit.getDefaultToolkit().getImage("foto_"+j+".jpg"), 120,

130, 590, 410);

galleria.setVisible(false);

scene.add(galleria);

intestazione = new

HIcon(Toolkit.getDefaultToolkit().getImage("intestazione.png"), 10,

10, 700, 75);

scene.add(intestazione);

b_1 = new

HIcon(Toolkit.getDefaultToolkit().getImage("b_1.png"), 10, 95, 100,

50);

scene.add(b_1);

b_2 = new

HIcon(Toolkit.getDefaultToolkit().getImage("b_2.png"), 10, 145,

100, 50);

scene.add(b_2);

b_3 = new


100, 50);

scene.add(b_3);

b_4 = new


100, 50);

scene.add(b_4);


Appendice A

217

b_5 = new


100, 50);

scene.add(b_5);

b_6 = new


100, 50);

scene.add(b_6);

legenda = new

HIcon(Toolkit.getDefaultToolkit().getImage("legenda.png"), 120,

541, 590, 25);

scene.add(legenda);

scene.setVisible(true);

scene.requestFocus();

}

public void aggiornaContenuto() {

disegnaSchermo();

switch (tastoPremuto) {

case B_1:

b_1.setGraphicContent(Toolkit.getDefaultToolkit().getImage("b

_1_f.png"), HState.NORMAL_STATE);

nomeFileTitolo = "titolo_home.txt";


home.setVisible(true);

break;

case B_2:



nomeFileTesto = "storia_1.txt";

nomeFileTitolo = "titolo_storia.txt";

break;

case B_3:



nomeFileTesto = "didattica_"+j+".txt";

nomeFileTitolo = "titolo_didattica.txt";

switch (frecciaPremuta) {

case SINISTRA:

if (check == true) {

if ((j > 1)&&(j<5))

j--;

System.out.println("j="+j);

nomeFileTesto =

"didattica_"+j+".txt";

check = false;

}

else

check = true;

break;

case DESTRA:


if (j < 4)

j++;


Appendice A

218

System.out.println("j="+j);

nomeFileTesto =

"didattica_"+j+".txt";

check = false;

}

else

check = true;

break;

}

break;

case B_4:



nomeFileTesto = "strutture_"+j+".txt";

nomeFileTitolo = "titolo_strutture.txt";


case SINISTRA:


if ((j > 1)&&(j<3))

j--;

nomeFileTesto =

"strutture_"+j+".txt";

check = false;

}

else

check = true;

break;

case DESTRA:


if (j < 2)

j++;

nomeFileTesto =

"strutture_"+j+".txt";

check = false;

}

else

check = true;

break;

}

break;

case B_5:



nomeFileTesto = "rubrica_"+j+".txt";

nomeFileTitolo = "titolo_rubrica.txt";


case SINISTRA:


if ((j > 1)&&(j<3))

j--;

nomeFileTesto =

"rubrica_"+j+".txt";

check = false;

}

else

check = true;

break;


Appendice A

219

case DESTRA:


if (j < 2)

j++;

nomeFileTesto =

"rubrica_"+j+".txt";

check = false;

}

else

check = true;

break;

}

break;

case B_6:




home.setVisible(false);

galleria.setVisible(true);

nomeFileTitolo = "titolo_galleria.txt";


case SINISTRA:


if ((j > 1)&&(j<8))

j--;

System.out.println(i);

immagine =

"foto_"+j+".jpg";

galleria.setGraphicContent(Toolkit.getDefaultToolkit().getIma

ge(immagine), HState.NORMAL_STATE);

check = false;

}

else

check = true;

break;

case DESTRA:


if (j < 7)

j++;

System.out.println("i="+i);

immagine =

"foto_"+j+".jpg";

galleria.setGraphicContent(Toolkit.getDefaultToolkit().getIma

ge("foto_"+j+".jpg"), HState.NORMAL_STATE);

check = false;

}

else

check = true;

break;

}

break;

}

}


Appendice A

220

public void aggiornaPulsanti() {

switch (i) {

case 0:

ripristinaPulsanti();



break;

case 2:




break;

case 4:




break;

case 6:




break;

case 8:




break;

case 10:




break;

}

}

public void visualizza(int i) {

switch (i) {

case 0:

tastoPremuto = B_1;

attivo = 1;

testovisibile = true;

aggiornaContenuto();

break;

case 2:

tastoPremuto = B_2;

attivo = 2;



break;

case 4:

tastoPremuto = B_3;

attivo = 3;




Appendice A

221

break;

case 6:

tastoPremuto = B_4;

attivo = 4;



break;

case 8:

tastoPremuto = B_5;

attivo = 5;



break;

case 10:

tastoPremuto = B_6;

attivo = 6;

testovisibile = false;


break;

}

}

public void ripristinaPulsanti() {

switch (attivo) {

case 1:


_1_s.png"), HState.NORMAL_STATE);


_2.png"), HState.NORMAL_STATE);









break;

case 2:










Appendice A

222





break;

case 3:













break;

case 4:













break;

case 5:










Appendice A

223





break;

case 6:













break;

}

}

public void destroy() {

if (scene != null) {

scene.setVisible(false);

scene.removeAll();

scene = null;

}

}

public void iUp() {

if ((i>-2)&&(i<13))

i--;

if (i==-2)

i = 10;

}

public void iDown(){

if ((i>-1)&&(i<13))

i++;

if (i==12)

i = 0;

}

}


Appendice B

224

Appendice B. i servizi interattivi

ReturnChannel.java import java.awt.Color; import java.awt.Font; import java.awt.FontMetrics; import java.awt.Graphics; import java.io.IOException; import org.davic.resources.ResourceClient; import org.davic.resources.ResourceProxy; import org.dvb.net.rc.*; import org.havi.ui.HStaticText; import java.net.InetAddress; import java.net.UnknownHostException; public class ReturnChannel implements ResourceClient, ConnectionListener { private static final long serialVersionUID = 1L; public InetAddress localIP; public InetAddress serverIP; private String serverurl; private double IstanteInizioConnessione=0; private double IstanteDisconnesione=0; private double TempoConnessioneAttiva=0; private int secondi=0; private int minuti=0; private int ore=0; private int giorni=0; private double app=0; private static final ReturnChannel singleton = new ReturnChannel(); private ConnectionRCInterface connectionInterface; private int m_status; private String string = "MESSAGGI INTERATTIVI";

public ReturnChannel() { connectionInterface = null; m_status = 0; } public static ReturnChannel getInstance() { // if(singleton != null) return singleton; //else return null; } public synchronized boolean isValid() { return connectionInterface != null && m_status > 0; } public synchronized boolean isConnected() { return isValid() && m_status == 2; } final static int titleBarHeigth=Main.titleBarHeigth; final static int titleBarWidth=Main.titleBarWidth; final static int xTitle=Main.xTitle; final static int yTitle=Main.yTitle; final static int TitlefontSize=Main.TitlefontSize;


Appendice B

225

public void paint(Graphics g) { Font f=new Font("Tireasias",Font.PLAIN,TitlefontSize); FontMetrics fm=g.getFontMetrics(f); g.setFont(f); g.setColor(Color.black); g.drawString(this.string,xTitle+(int)((titleBarWidth+4-fm.stringWidth(this.string))/2),yTitle+TitlefontSize -(int)((titleBarHeigth-TitlefontSize)/2)+2); g.setColor(Color.white); g.drawString(this.string,xTitle-3+(int)((titleBarWidth+4-fm.stringWidth(this.string))/2),yTitle+TitlefontSize -(int)((titleBarHeigth-TitlefontSize)/2)); } public synchronized boolean connectAsynch(String NUMERO, String USER, String PASSWORD,String serverurl) { System.out.println("Istanzia i parametri per la connessione."); this.serverurl=serverurl; ConnectionParameters connectionparameters = new ConnectionParameters(NUMERO,USER,PASSWORD); try { if(!isConnected()) { disconnect(); System.out.println("Crea una istanza RCInterfaceManager."); RCInterfaceManager rcinterfacemanager = RCInterfaceManager.getInstance(); System.out.println("Realizza il vettore delle interfacce."); RCInterface arcinterface[] = rcinterfacemanager.getInterfaces(); int i = arcinterface != null ? arcinterface.length : 0; System.out.println ("Dimensione del vettore delle interfacce=" + (i)); System.out.println("Controlla tutte le interfacce per determinare quella connettibile."); for(int j=0;j<arcinterface.length;j++) System.out.println("elemento di indice "+j+ "è del tipo "+arcinterface[j].getType() ); for(int j = 0; j < i; j++) { if(!(arcinterface[j] instanceof ConnectionRCInterface) || arcinterface[j].getType() != 1) { System.out.println("elemento di indice "+j+ "è del tipo "+arcinterface[j].getType() ); continue; } System.out.println("Determinato il numero dell'interfaccia connettibile."); connectionInterface = (ConnectionRCInterface)arcinterface[j]; System.out.println("Interfaccia numero:" + (j+1)); System.out.println("Il modem interno è di tipo PSTN V.90 cod.1"); } if(connectionInterface != null) { System.out.println("Aggiunge l'interfaccia connettibile come ConnectionListener."); connectionInterface.addConnectionListener(this); System.out.println("Eseguito addConnectionListener"); modemConnection(connectionparameters); } else { connectionInterface = null; m_status = 0; return false; } } } catch(Exception _ex) { connectionInterface = null; m_status = 0; }


Appendice B

226

return isValid(); } private void modemConnection( ConnectionParameters connectionparameters) throws IOException{ try { connectionInterface.reserve(this, new String("atvmhp")); } catch (PermissionDeniedException e) { // TODO Auto-generated catch block e.printStackTrace(); } System.out.println("Riserva l'interfaccia connettibile determinata."); m_status =1; System.out.println("Associa all'interfaccia i parametri della connessione."); try { connectionInterface.setTarget(connectionparameters); } catch (IncompleteTargetException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (PermissionDeniedException e) { // TODO Auto-generated catch block e.printStackTrace(); } IstanteInizioConnessione = System.currentTimeMillis(); try { connectionInterface.connect(); } catch (IOException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (PermissionDeniedException e) { // TODO Auto-generated catch block e.printStackTrace(); } System.out.println("Connette l'interfaccia."); System.out.println("Modem CONNESSO. Procedura di connessione effettuta con successo! "); System.out.println("Inizio procedura di handshaking con il server www." + serverurl); } public synchronized void connectionChanged(ConnectionRCEvent connectionrcevent) {//vedi chi chiama questo metodo per gestire il serverurl if(connectionrcevent instanceof ConnectionEstablishedEvent){ m_status = 2; setString("Connessione attiva."); setLabel("Disconnetti RC"); try { this.serverIP = InetAddress.getByName(serverurl); this.localIP = InetAddress.getLocalHost(); } catch (UnknownHostException e) { // TODO Auto-generated catch block e.printStackTrace(); } System.out.println("LocalIP:" + localIP); System.out.println("Server IP:" + serverIP); }


Appendice B

227

else if (connectionrcevent instanceof ConnectionFailedEvent){ m_status = 0; setString("Connessione fallita. "); welcomeMenu.setLabel(0,"Connetti RC"); welcomeMenu.repaint(); } else if (connectionrcevent instanceof ConnectionTerminatedEvent){ m_status = 0; setString("Connessione terminata. "); setLabel("Connetti RC"); } } public synchronized boolean CONNECTA(String numero, String user, String password,String serverurl) { setString("Connessione in corso..."); // repaint(); System.out.println("Testa se il modem e' gia' connesso..."); if(m_status == 0) { System.out.println("Inizio procedura di connessione..."); connectAsynch(numero, user, password,serverurl); } else { setString("Modem gia' connesso.");} return m_status > 0; } public synchronized boolean ISCONNECT() { return isConnected(); } public synchronized boolean WAITCONNECTION() { while(m_status > 0 && m_status != 2) try { Thread.sleep(1000); } catch(Exception _ex) { } return isConnected(); } public void riferimentitemporali(double TCA) { //Attiva la linea sotto per visualizzare il tempo della connessione in millisecondi //System.out.println("TCA= " + TCA); app = TCA/1000.00/60.00/60.00/24.00; giorni = (int) app ; app = (app - giorni/1.0)*24.00 ; ore = (int)app ; app = (app-ore)*60.00; minuti = (int) app; app = (app-minuti)*60.00; secondi = (int) app;


Appendice B

228

} public synchronized void disconnect() { if (m_status==0 ) { System.out.println("Disconnesso"); } else { IstanteDisconnesione = System.currentTimeMillis(); TempoConnessioneAttiva = IstanteDisconnesione - IstanteInizioConnessione; riferimentitemporali(TempoConnessioneAttiva); System.out.println("Tempo connessione attiva per =" + giorni + "g :" + ore + "h :" + minuti + "m :" + secondi + "s"); m_status = 0; if(connectionInterface != null){ try { connectionInterface.disconnect(); connectionInterface.release(); connectionInterface.removeConnectionListener(this); connectionInterface = null; } catch(PermissionDeniedException _ex) { } } } } public void release(ResourceProxy resourceproxy) { disconnect(); } public boolean requestRelease(ResourceProxy resourceproxy, Object obj) { return false; } public void notifyRelease(ResourceProxy resourceproxy) { connectionInterface.removeConnectionListener(this); connectionInterface = null; } public void setString(String string2) { string=string2; //repaint(); connectionStatus.setTextContent(string,0x80); connectionStatus.repaint(); } public String getTitle() { // TODO Auto-generated method stub return string;


Appendice B

229

} private AppMenu welcomeMenu=null; private HStaticText connectionStatus=null; private String label="Connetti RC"; public void sendVar(AppMenu welcomeMenu, HStaticText label) { this.welcomeMenu=welcomeMenu; this.connectionStatus=label; } public String getLabel() { // TODO Auto-generated method stub return label; } public void setLabel(String label) { // TODO Auto-generated method stub this.label=label; welcomeMenu.setLabel(0,label); welcomeMenu.repaint(); } }

AsurReminder.java

import java.sql.*; import java.util.*; import java.awt.*; import java.awt.event.*; import javax.swing.*; import javax.swing.border.*; import javax.tv.xlet.XletContext; // import javax.tv.xlet.*; import org.havi.ui.*; public class AsurReminder extends MyContainer implements KeyListener { private static final long serialVersionUID = 1L; private HContainer cont; private Font font; private BackgroundController backgroundManager; private XletContext context; private HDefaultTextLayoutManager tlm; private HText text1; private HText text2; private HText text3; private HText text3bis; private HText text4; private Image image; private HGraphicButton Botton; private HGraphicButton Botton1; private HGraphicButton Botton2; private HText tcesci; private HText tesci; private HText tqueryerr; private HText tconf; private HText tnonimm;


Appendice B

230

private HText terut; private HText tervis; private HContainer cesci; private HContainer cqueryerr; private HContainer cconf; private HContainer cnonimm; private HContainer cerut; private HContainer cervis; private JLabel [] informazione; private JLabel lesci = new JLabel("Sei sicuro di voler uscire?"); private JLabel l1esci = new JLabel("DESTRA/SINISTRA per scegliere"); private JLabel l2esci = new JLabel("Premi OK per confermare"); private JLabel l3esci = new JLabel("Premi OK per confermare"); private JLabel l4esci = new JLabel("Premi OK per confermare"); private JLabel l5esci = new JLabel("Premi OK per confermare"); private JLabel l6esci = new JLabel("DESTRA/SINISTRA per scegliere"); private JLabel l7esci = new JLabel("Premi OK per confermare"); private JButton besci = new JButton("Si"); private JButton bnonesci = new JButton("No"); private JLabel queryErrata = new JLabel("La ricerca non ha prodotto risultati"); private JLabel queryErrata2 = new JLabel("Premi il tasto"); private JLabel lrossa1 = new JLabel("ROSSO"); private JLabel queryErrata3 = new JLabel("per ripetere la ricerca"); private JLabel conferma = new JLabel("Confermi la richiesta di cancellazione?"); private JButton bsi = new JButton("Si"); private JButton bno = new JButton("No"); private JLabel lnonimm = new JLabel("Codice utente o visita non immesso"); private JButton bnonimm = new JButton("Ok"); private JLabel errutente = new JLabel("Codice utente inserito non presente"); private JButton erbut = new JButton("Ok"); private JLabel errvisita = new JLabel("Codice visita inserito non presente"); private JButton ersede = new JButton("Ok"); private JButton iniziale = new JButton("Torna alla pagina iniziale"); private int statoGenerale; private int statoRosso; private int statoTastiera; private int statoCombo; private int statoSede; private int gen; private int red; private boolean isUp; private ArrayList valori = new ArrayList(18); private ArrayList label = new ArrayList(18); private ArrayList cod = new ArrayList(20); private JLabel label1 = new JLabel("Cognome:"); private JTextField tf1 = new JTextField(20); private JLabel label2 = new JLabel("password:"); private JTextField tf2 = new JTextField(20); private JTextField tf3 = new JTextField(20); private JLabel label3 = new JLabel("Sede:"); private JComboBox combo; private JButton button1 = new JButton("Invia"); private JButton [] tasto; private String [] sede = {"Ancona","Chiaravalle","Loreto","Osimo"}; private JLabel lutente = new JLabel("Codice Utente"); private JTextField tutente = new JTextField(20);


Appendice B

231

private JLabel lvisita = new JLabel("Codice Visita"); private JTextField tvisita = new JTextField(20); private JButton bquery = new JButton("Ok"); private MatteBorder matte = new MatteBorder(5, 5, 5, 5, Color.red); private LineBorder line = new LineBorder(Color.black); private boolean rutente; private boolean rvisita; public AsurReminder() {} public AsurReminder(MyContainer container, MyContainer prev) { super(); this.container = container; this.prev = prev; init(); } public void init() //Xlet(XletContext context) throws XletStateChangeException { super.init(); addKeyListener(this); addElements(); container.validate(); validate(); repaint(); } /*this.context = context; System.out.println(this.getClass().getName()+" : initAsurReminder"); HSceneFactory hsf = HSceneFactory.getInstance(); scene = hsf.getFullScreenScene(HScreen.getDefaultHScreen().getDefaultHGraphicsDevice()); scene.setSize(720,576); scene.setLayout(null); scene.addKeyListener(this); */ public void displayBackgroundImage() { backgroundManager = new BackgroundController(); if (backgroundManager.init()) { backgroundManager.display("background.mpg"); //backgroundManager.display("sfondo.jpg"); backgroundManager.hideVideo(context,0,0,0,0); // per nascondere il video // che potrebbe oscurare lo // sfondo caricato System.out.println("Immagine di background caricata"); } } public void displayBackgroundExit() { System.out.println("distruzione background"); backgroundManager.dispose(context); } protected void addElements() { font = new Font("Tiresias", Font.BOLD, 26); tlm = new HDefaultTextLayoutManager(); cont = new HContainer(0, 0, 635, 510); image =Toolkit.getDefaultToolkit().getImage("intestazione.png"); Botton = new HGraphicButton(image,0,0,635,75); cont.add(Botton);


Appendice B

232

text1 = new HText(null, 0, 75, 0, 0, font, Color.black, Color.black, tlm); text2 = new HText(null, 0, 155, 0, 0, font, Color.white, Color.PINK, tlm); text3 = new HText(null, 0, 484, 635, 26, font, Color.white, Color.blue, tlm); text3bis = new HText(null, 317, 484, 318, 26, font, Color.white, Color.blue, tlm); text4 = new HText(null, 0, 484, 317, 26, font, Color.white, Color.yellow, tlm); cesci = new HContainer(405,150,270,255); cqueryerr = new HContainer(405,150,270,255); cconf = new HContainer(405,150,270,255); cerut = new HContainer(405,150,270,255); cervis = new HContainer(405,150,270,255); cnonimm = new HContainer(405,150,270,255); tcesci = new HText(null,0,75,270,180,font,Color.black,Color.blue,tlm); tesci = new HText(null,5,95,260,155,font,Color.black,Color.white,tlm); tqueryerr = new HText(null,0,75,270,180,font,Color.white,Color.black,tlm); tconf = new HText(null,0,75,270,180,font,Color.white,Color.black,tlm); terut = new HText(null,0,75,270,180,font,Color.white,Color.black,tlm); tervis = new HText(null,0,75,270,180,font,Color.white,Color.black,tlm); tnonimm = new HText(null,0,75,270,180,font,Color.white,Color.black,tlm); statoGenerale = 0; statoRosso = 0; statoTastiera = 14; statoCombo = 0; statoSede = 0; isUp = true; rutente = false; rvisita = false; label1.setBounds(50, 185, 100, 20); label1.setFont(new Font("Tiresias",Font.BOLD, 16)); label1.setForeground(Color.BLACK); cont.add(label1); tf1.setBounds(170, 184, 180, 22); tf1.setBackground(Color.white); tf1.setBorder(matte); cont.add(tf1); label2.setBounds(50, 220, 100, 20); label2.setFont(new Font("Tiresias",Font.BOLD, 16)); label2.setForeground(Color.BLACK); cont.add(label2); tf2.setBounds(170, 219, 180, 22); tf2.setBackground(Color.white); tf2.setBorder(line); cont.add(tf2); label3.setBounds(50, 255, 100, 20); label3.setFont(new Font("Tiresias",Font.BOLD, 16)); label3.setForeground(Color.BLACK); cont.add(label3); combo = new JComboBox(sede); combo.setBounds(170, 252, 150, 30); combo.setFont(new Font("Tiresias",Font.BOLD, 16)); combo.setForeground(Color.BLACK); combo.setSelectedItem(sede[0]); combo.setBackground(Color.white); combo.setBorder(line); cont.add(combo); button1.setBounds(170,295,135,27); button1.setBackground(Color.BLUE); button1.setFont(new Font("Tiresias",Font.BOLD, 20));


Appendice B

233

button1.setForeground(new Color(255, 255, 255)); button1.setBorder(line); cont.add(button1); informazione = new JLabel[32]; informazione[0] = new JLabel("Stai compilando il campo Cognome"); informazione[1] = new JLabel("Stai compilando il campo password"); informazione[2] = new JLabel("Stai compilando il campo Sede"); informazione[3] = new JLabel("Usa i tasti cursore ed il tasto OK per selezionare le lettere sulla tastiera"); informazione[4] = new JLabel("Premi il tasto"); informazione[5] = new JLabel("ROSSO"); informazione[6] = new JLabel("Stai inviando il modulo"); informazione[7] = new JLabel("Usa il tasto Ok per inoltrare la ricerca"); informazione[8] = new JLabel("per passare al campo successivo,"); informazione[9] = new JLabel("Premi il tasto BLU per uscire dall'applicazione"); informazione[10] = new JLabel("Exit"); informazione[11] = new JLabel("Usa i tasti SU/GIU' e il tasto OK per selezionare la sede nella lista"); informazione[12] = new JLabel("Stai compilando il campo Codice Utente"); informazione[13] = new JLabel("Stai compilando il campo Codice Visita"); informazione[14] = new JLabel("Usa i tasti numerici per inserire il codice, premi SINISTRA per cancellare"); informazione[15] = new JLabel("GIALLO per tornare indietro"); informazione[16] = new JLabel("BLU per uscire dall'applicazione"); informazione[17] = new JLabel("VERDE"); informazione[18] = new JLabel("per passare ad Invio"); informazione[19] = new JLabel("VERDE"); informazione[20] = new JLabel("per passare al precedente"); informazione[21] = new JLabel("per tornare a Cognome,"); informazione[22] = new JLabel("per passare al campo precedente"); informazione[23] = new JLabel("Premi il tasto"); informazione[24] = new JLabel("ROSSO"); informazione[25] = new JLabel("per passare al campo successivo,"); informazione[26] = new JLabel("VERDE"); informazione[27] = new JLabel("per passare ad Invio"); informazione[28] = new JLabel("per passare al precedente"); informazione[29] = new JLabel("per tornare al Codice Utente,"); informazione[30] = new JLabel("VERDE"); informazione[31] = new JLabel("per passare al campo precedente"); for(int i = 0; i < informazione.length; i++) { informazione[i].setForeground(Color.black); informazione[i].setFont(new Font("Tiresias",Font.BOLD, 16)); } informazione[15].setForeground(Color.black); informazione[5].setForeground(Color.red); informazione[17].setForeground(Color.green); informazione[19].setForeground(Color.green); informazione[24].setForeground(Color.red); informazione[26].setForeground(Color.green); informazione[30].setForeground(Color.green); informazione[10].setFont(new Font("Tiresias",Font.BOLD, 20)); informazione[10].setForeground(new Color(255, 255, 255)); informazione[15].setFont(new Font("Tiresias",Font.BOLD, 20)); informazione[15].setForeground(new Color(0, 0, 0)); informazione[16].setFont(new Font("Tiresias",Font.BOLD, 20)); informazione[16].setForeground(new Color(255, 255, 255)); informazione[0].setBounds(15,85,635,18);


Appendice B

234

informazione[3].setBounds(15,105,635,18); informazione[4].setBounds(15,125,200,18); informazione[5].setBounds(115,125,200,18); informazione[8].setBounds(177,125,250,18); informazione[17].setBounds(424,125,200,18); informazione[18].setBounds(482,125,200,18); informazione[9].setBounds(10,492,635,18); informazione[9].setFont(new Font("Tiresias",Font.BOLD, 20)); informazione[9].setForeground(new Color(255, 255, 255)); informazione[10].setBounds(535,492,100,18); cont.add(informazione[0]); cont.add(informazione[3]); cont.add(informazione[4]); cont.add(informazione[5]); cont.add(informazione[8]); cont.add(informazione[17]); cont.add(informazione[18]); cont.add(informazione[9]); cont.add(informazione[10]); informazione[1].setBounds(15,85,700,18); informazione[2].setBounds(15,85,700,18); informazione[6].setBounds(15,85,700,18); informazione[7].setBounds(15,105,700,18); informazione[11].setBounds(15,105,700,18); informazione[12].setBounds(15,85,700,18); informazione[13].setBounds(15,85,700,18); informazione[14].setBounds(15,105,700,18); informazione[15].setBounds(10,484,317,26); informazione[16].setBounds(320,484,318,26); informazione[19].setBounds(350,125,200,18); informazione[20].setBounds(482,125,200,18); informazione[21].setBounds(177,125,200,18); informazione[22].setBounds(405,125,250,18); informazione[23].setBounds(15,125,200,18); informazione[24].setBounds(115,125,200,18); informazione[25].setBounds(177,125,250,18); informazione[26].setBounds(424,125,200,18); informazione[27].setBounds(482,125,200,18); informazione[28].setBounds(482,125,200,18); informazione[29].setBounds(177,125,250,18); informazione[30].setBounds(388,125,200,18); informazione[31].setBounds(442,125,250,18); informazione[1].setVisible(false); informazione[2].setVisible(false); informazione[6].setVisible(false); informazione[7].setVisible(false); informazione[11].setVisible(false); informazione[19].setVisible(false); informazione[20].setVisible(false); informazione[21].setVisible(false); informazione[22].setVisible(false); cont.add(informazione[1]); cont.add(informazione[2]); cont.add(informazione[6]); cont.add(informazione[7]); cont.add(informazione[11]); cont.add(informazione[19]);


Appendice B

235

cont.add(informazione[20]); cont.add(informazione[21]); cont.add(informazione[22]); tasto = new JButton[60]; tasto[0] = new JButton("Q"); tasto[1] = new JButton("W"); tasto[2] = new JButton("E"); tasto[3] = new JButton("R"); tasto[4] = new JButton("T"); tasto[5] = new JButton("Y"); tasto[6] = new JButton("U"); tasto[7] = new JButton("I"); tasto[8] = new JButton("O"); tasto[9] = new JButton("P"); tasto[10] = new JButton("A"); tasto[11] = new JButton("S"); tasto[12] = new JButton("D"); tasto[13] = new JButton("F"); tasto[14] = new JButton("G"); tasto[15] = new JButton("H"); tasto[16] = new JButton("J"); tasto[17] = new JButton("K"); tasto[18] = new JButton("L"); tasto[19] = new JButton("'"); tasto[20] = new JButton("dw"); tasto[21] = new JButton("Z"); tasto[22] = new JButton("X"); tasto[23] = new JButton("C"); tasto[24] = new JButton("V"); tasto[25] = new JButton("B"); tasto[26] = new JButton("N"); tasto[27] = new JButton("M"); tasto[28] = new JButton("_"); tasto[29] = new JButton("Cl"); tasto[30] = new JButton("q"); tasto[31] = new JButton("w"); tasto[32] = new JButton("e"); tasto[33] = new JButton("r"); tasto[34] = new JButton("t"); tasto[35] = new JButton("y"); tasto[36] = new JButton("u"); tasto[37] = new JButton("i"); tasto[38] = new JButton("o"); tasto[39] = new JButton("p"); tasto[40] = new JButton("a"); tasto[41] = new JButton("s"); tasto[42] = new JButton("d"); tasto[43] = new JButton("f"); tasto[44] = new JButton("g"); tasto[45] = new JButton("h"); tasto[46] = new JButton("j"); tasto[47] = new JButton("k"); tasto[48] = new JButton("l"); tasto[49] = new JButton("'"); tasto[50] = new JButton("UP"); tasto[51] = new JButton("z"); tasto[52] = new JButton("x"); tasto[53] = new JButton("c"); tasto[54] = new JButton("v"); tasto[55] = new JButton("b"); tasto[56] = new JButton("n");


Appendice B

236

tasto[57] = new JButton("m"); tasto[58] = new JButton("_"); tasto[59] = new JButton("Cl"); for(int i = 0; i < tasto.length; i++) { tasto[i].setBackground(Color.lightGray); tasto[i].setFont(new Font("Tiresias", Font.PLAIN, 20)); tasto[20].setFont(new Font("Tiresias", Font.PLAIN, 16)); tasto[50].setFont(new Font("Tiresias", Font.PLAIN, 16)); } int x1 = 50; for(int i = 0; i < 10; i++) { tasto[i].setBounds(x1,335,50,45); x1 += 50; } x1 = 50; for(int i = 10; i < 20; i++) { tasto[i].setBounds(x1,380,50,45); x1 += 50; } x1 = 50; for(int i = 20; i < 30; i++) { tasto[i].setBounds(x1,425,50,45); x1 += 50; } x1 = 50; for(int i = 30; i < 40; i++) { tasto[i].setBounds(x1,335,50,45); x1 += 50; } x1 = 50; for(int i = 40; i < 50; i++) { tasto[i].setBounds(x1,380,50,45); x1 += 50; } x1 = 50; for(int i = 50; i < 60; i++) { tasto[i].setBounds(x1,425,50,45); x1 += 50; } for(int i = 0; i < 30; i++) cont.add(tasto[i]); tasto[14].setBackground(Color.black); tasto[14].setForeground(Color.white); fillEsci(); fillQueryerr(); fillNonimm(); fillErlib(); fillErut(); fillConferma();


Appendice B

237

cont.add(text1); cont.add(text2); cont.add(text3); cesci.setVisible(false); cqueryerr.setVisible(false); cconf.setVisible(false); cnonimm.setVisible(false); cerut.setVisible(false); cervis.setVisible(false); add(cesci); add(cqueryerr); add(cnonimm); add(cervis); add(cerut); add(cconf); add(cont); setVisible(true); requestFocus(); repaint(); } //in seguito le parti utili alla versione Stand-Alone /* public void startXlet() throws XletStateChangeException { System.out.println(this.getClass().getName()+" : startXlet"); } public void pauseXlet() { System.out.println(this.getClass().getName()+" : pauseXlet"); context.notifyPaused(); } public void destroyXlet(boolean unconditional) throws XletStateChangeException { if (unconditional) { if(scene != null) { scene.setVisible(false); scene.removeAll(); HSceneFactory.getInstance().dispose(scene); scene = null; } context.notifyDestroyed(); System.out.println(this.getClass().getName()+" : Xlet distrutta"); } else { System.out.println(this.getClass().getName() +" : Richiesta di destroy rifiutata!"); throw new XletStateChangeException("no thanks!"); } }*/ public void esci() { System.out.println("Tasto Blu esce dall'applicazione"); removeKeyListener(this); setVisible(false); if (prev != null) { next= new WorkProgress(container, this);


Appendice B

238

cont.removeAll(); } } public void keyPressed(KeyEvent e) { switch(e.getKeyCode()) { case 403: premutoRosso(); break; case 404: premutoVerde(); break; case 405: premutoGiallo(); break; case 406: premutoBlu(); break; case 37: spostaSinistra(); break; case 38: spostaSu(); break; case 39: spostaDestra(); break; case 40: spostaGiu(); break; case 10: premutoEnter(); break; case 48: premutoZero(); break; case 49: premutoUno(); break; case 50: premutoDue(); break; case 51: premutoTre(); break; case 52: premutoQuattro(); break; case 53: premutoCinque(); break; case 54: premutoSei(); break; case 55: premutoSette(); break;


Appendice B

239

case 56: premutoOtto(); break; case 57: premutoNove(); break; default: break; } } public void keyReleased(KeyEvent e) {} public void keyTyped(KeyEvent e){} public void premutoRosso() { switch(statoGenerale) { case 0: { switch(statoRosso) { case 0: informazione[0].setVisible(false); informazione[18].setVisible(false); tf1.setBorder(line); statoRosso++; tf2.setBorder(matte); informazione[1].setVisible(true); informazione[20].setVisible(true); break; case 1: informazione[1].setVisible(false); informazione[3].setVisible(false); tf2.setBorder(line); statoRosso++; combo.setBorder(matte); informazione[2].setVisible(true); informazione[11].setVisible(true); break; case 2: informazione[2].setVisible(false); informazione[8].setVisible(false); informazione[17].setVisible(false); informazione[20].setVisible(false); informazione[11].setVisible(false); combo.setBorder(line); statoRosso++; button1.setBorder(matte); combo.hidePopup(); statoCombo = 0; informazione[6].setVisible(true); informazione[7].setVisible(true); informazione[21].setVisible(true); informazione[19].setVisible(true); informazione[22].setVisible(true); break; case 3: informazione[6].setVisible(false); informazione[7].setVisible(false); informazione[21].setVisible(false); informazione[19].setVisible(false);


Appendice B

240

informazione[22].setVisible(false); button1.setBorder(line); statoRosso = 0; tf1.setBorder(matte); cqueryerr.setVisible(false); repaint(); informazione[0].setVisible(true); informazione[3].setVisible(true); informazione[8].setVisible(true); informazione[17].setVisible(true); informazione[18].setVisible(true); break; default: break; } break; } case 1: { switch(statoRosso) { case 4: informazione[12].setVisible(false); informazione[27].setVisible(false); tutente.setBorder(line); statoRosso++; tvisita.setBorder(matte); informazione[13].setVisible(true); informazione[28].setVisible(true); break; case 5: informazione[13].setVisible(false); informazione[14].setVisible(false); informazione[25].setVisible(false); informazione[26].setVisible(false); informazione[28].setVisible(false); tvisita.setBorder(line); statoRosso++; bquery.setBorder(matte); informazione[6].setVisible(true); informazione[7].setVisible(true); informazione[29].setVisible(true); informazione[30].setVisible(true); informazione[31].setVisible(true); break; case 6: bquery.setBorder(line); informazione[6].setVisible(false); informazione[7].setVisible(false); informazione[29].setVisible(false); informazione[30].setVisible(false); informazione[31].setVisible(false); statoRosso = 4; tutente.setBorder(matte); informazione[12].setVisible(true); informazione[14].setVisible(true); informazione[25].setVisible(true); informazione[26].setVisible(true); informazione[27].setVisible(true); break; default: break;


Appendice B

241

} break; } default: break; } } public void premutoBlu() { if(statoGenerale == 0 && statoRosso == 2) { combo.hidePopup(); statoCombo = 0; } if(statoGenerale == 0 || statoGenerale == 1 || statoGenerale == 4) { gen = statoGenerale; red = statoRosso; statoGenerale = 5; statoRosso = 9; besci.setBorder(matte); cesci.setVisible(true); repaint(); } } public void premutoVerde() { switch(statoGenerale) { case 0: { switch(statoRosso) { case 0: informazione[0].setVisible(false); informazione[3].setVisible(false); informazione[8].setVisible(false); informazione[17].setVisible(false); informazione[18].setVisible(false); tf1.setBorder(line); statoRosso = 3; button1.setBorder(matte); informazione[6].setVisible(true); informazione[7].setVisible(true); informazione[21].setVisible(true); informazione[19].setVisible(true); informazione[22].setVisible(true); break; case 1: informazione[1].setVisible(false); informazione[20].setVisible(false); tf2.setBorder(line); statoRosso--; tf1.setBorder(matte); informazione[0].setVisible(true); informazione[18].setVisible(true); break; case 2: informazione[2].setVisible(false); informazione[11].setVisible(false); combo.setBorder(line);


Appendice B

242

statoRosso--; tf2.setBorder(matte); combo.hidePopup(); statoCombo = 0; informazione[1].setVisible(true); informazione[3].setVisible(true); break; case 3: informazione[6].setVisible(false); informazione[7].setVisible(false); informazione[21].setVisible(false); informazione[19].setVisible(false); informazione[22].setVisible(false); button1.setBorder(line); statoRosso--; combo.setBorder(matte); cqueryerr.setVisible(false); repaint(); informazione[2].setVisible(true); informazione[11].setVisible(true); informazione[8].setVisible(true); informazione[17].setVisible(true); informazione[20].setVisible(true); break; default: break; } break; } case 1: { switch(statoRosso) { case 4: informazione[12].setVisible(false); informazione[14].setVisible(false); informazione[25].setVisible(false); informazione[26].setVisible(false); informazione[27].setVisible(false); tutente.setBorder(line); statoRosso = 6; bquery.setBorder(matte); informazione[6].setVisible(true); informazione[7].setVisible(true); informazione[29].setVisible(true); informazione[30].setVisible(true); informazione[31].setVisible(true); break; case 5: informazione[13].setVisible(false); informazione[28].setVisible(false); tvisita.setBorder(line); statoRosso--; tutente.setBorder(matte); informazione[12].setVisible(true); informazione[27].setVisible(true); break; case 6: informazione[6].setVisible(false); informazione[7].setVisible(false); informazione[29].setVisible(false); informazione[30].setVisible(false);


Appendice B

243

informazione[31].setVisible(false); bquery.setBorder(line); statoRosso--; tvisita.setBorder(matte); informazione[13].setVisible(true); informazione[14].setVisible(true); informazione[25].setVisible(true); informazione[26].setVisible(true); informazione[28].setVisible(true); break; default: break; } break; } default: break; } } public void premutoGiallo() { if (statoGenerale == 1) { valori.clear(); valori.trimToSize(); System.out.println(valori.size()); label.clear(); label.trimToSize(); System.out.println(label.size()); cod.clear(); cod.trimToSize(); System.out.println(cod.size()); button1.setBorder(line); bquery.setBorder(line); tvisita.setBorder(line); tf1.setText(""); tf2.setText(""); tutente.setText(""); tvisita.setText(""); //try //{ next= new AsurReminder(container, this); //Xlet(this.context); //} //catch(XletStateChangeException e) //{ // e.printStackTrace(System.out); // } } } public void premutoEnter() { switch(statoGenerale) { case 0: { switch(statoRosso) { case 0: stampaTF1(); break; case 1:


Appendice B

244

stampaTF2(); break; case 2: popCombo(); break; case 3: unoDue(); break; default: break; } break; } case 1: { if(statoRosso == 6) conferma(); break; } case 2: { switch(statoRosso) { case 7: continua(); break; case 8: nonContinua(); break; default: break; } break; } case 3: digitaOk(); break; case 4: { valori.clear(); valori.trimToSize(); System.out.println(valori.size()); label.clear(); label.trimToSize(); System.out.println(label.size()); cod.clear(); cod.trimToSize(); System.out.println(cod.size()); button1.setBorder(line); bquery.setBorder(line); tvisita.setBorder(line); tf1.setText(""); tf2.setText(""); tutente.setText(""); tvisita.setText(""); //try //{ next= new AsurReminder(container, this); //Xlet(this.context); //} //catch(XletStateChangeException e) //{ // e.printStackTrace(System.out);


Appendice B

245

// } } break; case 5: { switch(statoRosso) { case 9: /*try { destroyXlet(true); } catch(XletStateChangeException e) { e.printStackTrace(System.out); }*/ esci(); break; case 10: statoGenerale = gen; statoRosso = red; bnonesci.setBorder(line); cesci.setVisible(false); repaint(); break; default: break; } break; } default: break; } } private void premutoZero() { if(statoGenerale == 1) { if(statoRosso == 4) tutente.setText(tutente.getText() + "0"); if(statoRosso == 5) tvisita.setText(tvisita.getText() + "0"); } } private void premutoUno() { if(statoGenerale == 1) { if(statoRosso == 4) tutente.setText(tutente.getText() + "1"); if(statoRosso == 5) tvisita.setText(tvisita.getText() + "1"); } } private void premutoDue() { if(statoGenerale == 1) { if(statoRosso == 4) tutente.setText(tutente.getText() + "2"); if(statoRosso == 5)


Appendice B

246

tvisita.setText(tvisita.getText() + "2"); } } private void premutoTre() { if(statoGenerale == 1) { if(statoRosso == 4) tutente.setText(tutente.getText() + "3"); if(statoRosso == 5) tvisita.setText(tvisita.getText() + "3"); } } private void premutoQuattro() { if(statoGenerale == 1) { if(statoRosso == 4) tutente.setText(tutente.getText() + "4"); if(statoRosso == 5) tvisita.setText(tvisita.getText() + "4"); } } private void premutoCinque() { if(statoGenerale == 1) { if(statoRosso == 4) tutente.setText(tutente.getText() + "5"); if(statoRosso == 5) tvisita.setText(tvisita.getText() + "5"); } } private void premutoSei() { if(statoGenerale == 1) { if(statoRosso == 4) tutente.setText(tutente.getText() + "6"); if(statoRosso == 5) tvisita.setText(tvisita.getText() + "6"); } } private void premutoSette() { if(statoGenerale == 1) { if(statoRosso == 4) tutente.setText(tutente.getText() + "7"); if(statoRosso == 5) tvisita.setText(tvisita.getText() + "7"); } } private void premutoOtto() { if(statoGenerale == 1) { if(statoRosso == 4) tutente.setText(tutente.getText() + "8"); if(statoRosso == 5) tvisita.setText(tvisita.getText() + "8"); }


Appendice B

247

} private void premutoNove() { if(statoGenerale == 1) { if(statoRosso == 4) tutente.setText(tutente.getText() + "9"); if(statoRosso == 5) tvisita.setText(tvisita.getText() + "9"); } } public void spostaSinistra() { switch(statoGenerale) { case 0: if(statoRosso == 0 || statoRosso == 1) sinistraTF(); break; case 1: if(statoRosso == 4) cancellaUtente(); if(statoRosso == 5) cancellaVisita(); case 2: if(statoRosso == 8) { bno.setBorder(line); statoRosso--; bsi.setBorder(matte); } break; case 5: if(statoRosso == 10) { bnonesci.setBorder(line); statoRosso--; besci.setBorder(matte); } break; default: break; } } public void spostaSu() { if(statoGenerale == 0) { if(statoRosso == 0 || statoRosso == 1) suTF(); if(statoRosso == 2) suCombo(); } } public void spostaDestra() { switch(statoGenerale) { case 0:


Appendice B

248

if(statoRosso == 0 || statoRosso == 1) destraTF(); break; case 2: if(statoRosso == 7) { bsi.setBorder(line); statoRosso++; bno.setBorder(matte); } break; case 5: if(statoRosso == 9) { besci.setBorder(line); statoRosso++; bnonesci.setBorder(matte); } default: break; } } public void spostaGiu() { if(statoGenerale == 0) { if(statoRosso == 0 || statoRosso == 1) giuTF(); if(statoRosso == 2) giuCombo(); } } private void stampaTF1() { […] //classe simile a stampaTF2, ma senza asterisco } private void stampaTF2() { switch(statoTastiera) { case 0: if(isUp == true) { tf2.setText(tf2.getText() + "*"); tf3.setText(tf3.getText() + "Q"); } else { tf2.setText(tf2.getText() + "*"); tf3.setText(tf3.getText() + "q"); } break; case 1: if(isUp == true) { tf2.setText(tf2.getText() + "*"); tf3.setText(tf3.getText() + "W"); } else { tf2.setText(tf2.getText() + "*"); tf3.setText(tf3.getText() + "w"); } break; case 2: if(isUp == true) { tf2.setText(tf2.getText() + "*");


Appendice B

249

tf3.setText(tf3.getText() + "E"); } else { tf2.setText(tf2.getText() + "*"); tf3.setText(tf3.getText() + "e"); } break; […] // e così via per le altre lettere dell’albafeto break; default: break; } } public void shiftDown() { isUp = false; for(int i = 0; i < 30; i++) cont.remove(tasto[i]); for(int i = 30; i < 60; i++) cont.add(tasto[i]); tasto[50].setBackground(Color.black); tasto[50].setForeground(Color.white); cont.add(text1); cont.add(text2); cont.add(text3); add(cont); setVisible(true); requestFocus(); repaint(); } public void shiftUp() { isUp = true; for(int i = 0; i < 30; i++) cont.add(tasto[i]); for(int i = 30; i < 60; i++) cont.remove(tasto[i]); cont.add(text1); cont.add(text2); cont.add(text3); add(cont); setVisible(true); requestFocus(); repaint(); } public void popCombo() { if(statoCombo == 0) { combo.showPopup(); statoCombo = 1; } else { combo.hidePopup(); statoCombo = 0; } } public void sinistraTF() { switch(statoTastiera)


Appendice B

250

{ case 0: statoTastiera = 9; if(isUp == true) { tasto[0].setForeground(Color.black); tasto[0].setBackground(Color.lightGray); tasto[9].setForeground(Color.white); tasto[9].setBackground(Color.black); } else { tasto[30].setBackground(Color.lightGray); tasto[30].setForeground(Color.black); tasto[39].setForeground(Color.white); tasto[39].setBackground(Color.black); } break; case 1: statoTastiera--; if(isUp == true) { tasto[1].setForeground(Color.black); tasto[1].setBackground(Color.lightGray); tasto[0].setForeground(Color.white); tasto[0].setBackground(Color.black); } else { tasto[31].setBackground(Color.lightGray); tasto[31].setForeground(Color.black); tasto[30].setForeground(Color.white); tasto[30].setBackground(Color.black); } break; //[…] … e così via per tutti gli altri tasti e per le classi “suTF”, destraTF”, “giuTF”, break; default: break; } } public void suCombo() { switch(statoSede) { case 0: combo.setSelectedItem(sede[3]); statoSede = 3; break; case 1: combo.setSelectedItem(sede[0]); statoSede--; break; case 2: combo.setSelectedItem(sede[1]); statoSede--; break; case 3: combo.setSelectedItem(sede[2]); statoSede--; break; /* case 4:


Appendice B

251

combo.setSelectedItem(sede[3]); statoSede--; break; */ default: break; } } public void giuCombo() { switch(statoSede) { case 0: combo.setSelectedItem(sede[1]); statoSede++; break; case 1: combo.setSelectedItem(sede[2]); statoSede++; break; case 2: combo.setSelectedItem(sede[3]); statoSede++; break; case 3: combo.setSelectedItem(sede[0]); statoSede=0; break; /* case 4: combo.setSelectedItem(sede[0]); statoSede = 0; break; */ default: break; } } public void unoDue() { primaQuery(tf1.getText(), tf3.getText(), (String)combo.getSelectedItem()); if(valori.size() == 0) { System.out.println("La ricerca non ha avuto risultato"); cqueryerr.setVisible(true); repaint(); } else { statoGenerale = 1; statoRosso = 4; cont.removeAll(); JLabel etvis = new JLabel("Codice visita"); etvis.setForeground(Color.red); etvis.setFont(new Font("Tiresias",Font.BOLD, 16)); etvis.setBounds(60, 160, 200, 50); cont.add(etvis); JLabel ettip = new JLabel("tipologia"); ettip.setForeground(Color.red); ettip.setFont(new Font("Tiresias",Font.BOLD, 16)); ettip.setBounds(167, 160, 200, 50); cont.add(ettip); JLabel etdata = new JLabel("data");


Appendice B

252

etdata.setForeground(Color.red); etdata.setFont(new Font("Tiresias",Font.BOLD, 16)); etdata.setBounds(325, 160, 200, 50); cont.add(etdata); for(int count = 0; count < valori.size(); count++) label.add(new JLabel((String)valori.get(count))); label.trimToSize(); if(label.size() >= 3) { ((JLabel)label.get(0)).setBounds(60, 180, 200, 50); ((JLabel)label.get(0)).setFont(new Font("Tiresias",Font.BOLD, 16)); cont.add((JLabel)label.get(0)); ((JLabel)label.get(1)).setBounds(167, 180, 200, 50); ((JLabel)label.get(1)).setFont(new Font("Tiresias",Font.BOLD, 16)); cont.add((JLabel)label.get(1)); ((JLabel)label.get(2)).setBounds(325, 180, 200, 50); ((JLabel)label.get(2)).setFont(new Font("Tiresias",Font.BOLD, 16)); cont.add((JLabel)label.get(2)); } if(label.size() >= 6) { ((JLabel)label.get(3)).setBounds(60, 200, 200, 50); ((JLabel)label.get(3)).setFont(new Font("Tiresias",Font.BOLD, 16)); cont.add((JLabel)label.get(3)); ((JLabel)label.get(4)).setBounds(167, 200, 200, 50); ((JLabel)label.get(4)).setFont(new Font("Tiresias",Font.BOLD, 16)); cont.add((JLabel)label.get(4)); ((JLabel)label.get(5)).setBounds(325, 200, 200, 50); ((JLabel)label.get(5)).setFont(new Font("Tiresias",Font.BOLD, 16)); cont.add((JLabel)label.get(5)); } if(label.size() >= 9) { ((JLabel)label.get(6)).setBounds(60, 220, 200, 50); ((JLabel)label.get(6)).setFont(new Font("Tiresias",Font.BOLD, 16)); cont.add((JLabel)label.get(6)); ((JLabel)label.get(7)).setBounds(167, 220, 200, 50); ((JLabel)label.get(7)).setFont(new Font("Tiresias",Font.BOLD, 16)); cont.add((JLabel)label.get(7)); ((JLabel)label.get(8)).setBounds(325, 220, 200, 50); ((JLabel)label.get(8)).setFont(new Font("Tiresias",Font.BOLD, 16)); cont.add((JLabel)label.get(8)); } if(label.size() >= 12) { ((JLabel)label.get(9)).setBounds(60, 240, 200, 50); ((JLabel)label.get(9)).setFont(new Font("Tiresias",Font.BOLD, 16)); cont.add((JLabel)label.get(9)); ((JLabel)label.get(10)).setBounds(167, 240, 200, 50); ((JLabel)label.get(10)).setFont(new Font("Tiresias",Font.BOLD, 16)); cont.add((JLabel)label.get(10)); ((JLabel)label.get(11)).setBounds(325, 240, 200, 50); ((JLabel)label.get(11)).setFont(new Font("Tiresias",Font.BOLD, 16)); cont.add((JLabel)label.get(11)); } if(label.size() >= 15) { ((JLabel)label.get(12)).setBounds(60, 260, 200, 50); ((JLabel)label.get(12)).setFont(new Font("Tiresias",Font.BOLD, 16));


Appendice B

253

cont.add((JLabel)label.get(12)); ((JLabel)label.get(13)).setBounds(167, 260, 200, 50); ((JLabel)label.get(13)).setFont(new Font("Tiresias",Font.BOLD, 16)); cont.add((JLabel)label.get(13)); ((JLabel)label.get(14)).setBounds(325, 260, 200, 50); ((JLabel)label.get(14)).setFont(new Font("Tiresias",Font.BOLD, 16)); cont.add((JLabel)label.get(14)); } if(label.size() >= 18) { ((JLabel)label.get(15)).setBounds(60, 280, 200, 50); ((JLabel)label.get(15)).setFont(new Font("Tiresias",Font.BOLD, 16)); cont.add((JLabel)label.get(15)); ((JLabel)label.get(16)).setBounds(167, 280, 200, 50); ((JLabel)label.get(16)).setFont(new Font("Tiresias",Font.BOLD, 16)); cont.add((JLabel)label.get(16)); ((JLabel)label.get(17)).setBounds(325, 280, 200, 50); ((JLabel)label.get(17)).setFont(new Font("Tiresias",Font.BOLD, 16)); cont.add((JLabel)label.get(17)); } lutente.setBounds(50, 320, 200, 50); lutente.setFont(new Font("Tiresias",Font.BOLD, 16)); lutente.setForeground(Color.BLACK); cont.add(lutente); tutente.setBounds(200, 335, 110, 25); tutente.setBackground(Color.white); tutente.setBorder(matte); cont.add(tutente); lvisita.setBounds(50, 365, 200, 50); lvisita.setFont(new Font("Tiresias",Font.BOLD, 16)); lvisita.setForeground(Color.BLACK); cont.add(lvisita); tvisita.setBounds(200, 380, 110, 25); tvisita.setBackground(Color.white); tvisita.setBorder(line); cont.add(tvisita); bquery.setBounds(200, 420, 90, 26); bquery.setFont(new Font("Tiresias",Font.BOLD, 16)); bquery.setForeground(Color.white); bquery.setBackground(Color.blue); bquery.setBorder(line); cont.add(bquery); cont.add(informazione[6]); cont.add(informazione[7]); cont.add(informazione[12]); cont.add(informazione[13]); cont.add(informazione[14]); cont.add(informazione[15]); cont.add(informazione[16]); cont.add(informazione[23]); cont.add(informazione[24]); cont.add(informazione[25]); cont.add(informazione[26]); cont.add(informazione[27]); cont.add(informazione[28]); cont.add(informazione[29]); cont.add(informazione[30]); cont.add(informazione[31]); informazione[6].setVisible(false); informazione[7].setVisible(false); informazione[13].setVisible(false);


Appendice B

254

informazione[28].setVisible(false); informazione[29].setVisible(false); informazione[30].setVisible(false); informazione[31].setVisible(false); cont.add(Botton); cont.add(text1); cont.add(text2); cont.add(text3bis); cont.add(text4); add(cont); setVisible(true); repaint(); } } public void primaQuery(String a, String t, String b) { System.out.println("Il cognome inserito: " + a); System.out.println("la password inserita: " + t); System.out.println("La sede selezionata: " + b); try { Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); } catch(ClassNotFoundException e) { System.out.println(e.toString()); System.exit(1); } try { Connection conn = DriverManager.getConnection("jdbc:odbc:JDBCAsur7"); Statement stmt = conn.createStatement(); String query=""; if(t.length() > 1 && a.length() > 1 ) { query = "SELECT Codice_ID, tipo, data " + "FROM " + b + " WHERE Prenotazione = 1 AND " + "(paziente = '" + a + "' AND password = '" + t + "')"; } System.out.println(query); ResultSet rs = stmt.executeQuery(query); int i = 0; while(rs.next()) { valori.add(rs.getString(1)); System.out.print((String)valori.get(i) + " "); i++; valori.add(rs.getString(2)); System.out.print((String)valori.get(i) + " "); i++; valori.add(rs.getString(3)); System.out.print((String)valori.get(i) + " "); i++; System.out.println(); } valori.trimToSize(); System.out.println(i); System.out.println(); rs.close();


Appendice B

255

stmt.close(); conn.close(); } catch(SQLException se) { System.out.println(se.getMessage()); se.printStackTrace(System.out); System.exit(1); } } public void cancellaUtente() { String ut = tutente.getText(); ut = ut.substring(0, ut.length() - 1); tutente.setText(ut); } public void cancellaVisita() { String ut = tvisita.getText(); ut = ut.substring(0, ut.length() - 1); tvisita.setText(ut); } public void fillEsci() { lesci.setBounds(38, 108, 200, 20); lesci.setFont(new Font("Tiresias",Font.BOLD, 16)); l1esci.setBounds(18, 150, 260, 20); l1esci.setFont(new Font("Tiresias",Font.BOLD, 16)); l2esci.setBounds(42, 170, 260, 20); l2esci.setFont(new Font("Tiresias",Font.BOLD, 16)); cesci.add(lesci); cesci.add(l1esci); cesci.add(l2esci); besci.setBounds(47, 202, 60, 30); besci.setFont(new Font("Tiresias",Font.BOLD, 16)); besci.setBackground(Color.white); cesci.add(besci); bnonesci.setBounds(164, 202, 60, 30); bnonesci.setFont(new Font("Tiresias",Font.BOLD, 16)); bnonesci.setBackground(Color.white); cesci.add(bnonesci); cesci.add(tesci); cesci.add(tcesci); } public void fillQueryerr() { queryErrata.setBounds(10, 115, 270, 20); queryErrata.setFont(new Font("Tiresias",Font.BOLD, 16)); queryErrata2.setBounds(57, 170, 100, 20); queryErrata2.setFont(new Font("Tiresias",Font.BOLD, 16)); lrossa1.setBounds(155, 170, 100, 20); lrossa1.setFont(new Font("Tiresias",Font.BOLD, 16)); lrossa1.setForeground(Color.red); queryErrata3.setBounds(57, 195, 270, 20); queryErrata3.setFont(new Font("Tiresias",Font.BOLD, 16)); queryErrata.setForeground(Color.white); queryErrata2.setForeground(Color.white); queryErrata3.setForeground(Color.white); cqueryerr.add(queryErrata); cqueryerr.add(queryErrata2); cqueryerr.add(lrossa1);


Appendice B

256

cqueryerr.add(queryErrata3); cqueryerr.add(tqueryerr); } public void fillConferma() { conferma.setBounds(2, 107, 300, 20); conferma.setFont(new Font("Tiresias",Font.BOLD, 16)); l6esci.setBounds(18, 150, 260, 20); l6esci.setFont(new Font("Tiresias",Font.BOLD, 16)); l7esci.setBounds(48, 170, 260, 20); l7esci.setFont(new Font("Tiresias",Font.BOLD, 16)); conferma.setForeground(Color.white); l6esci.setForeground(Color.white); l7esci.setForeground(Color.white); cconf.add(conferma); cconf.add(l6esci); cconf.add(l7esci); cconf.add(conferma); bsi.setBounds(47, 202, 60, 30); bsi.setFont(new Font("Tiresias",Font.BOLD, 16)); bsi.setBackground(Color.white); cconf.add(bsi); bno.setBounds(164, 202, 60, 30); bno.setFont(new Font("Tiresias",Font.BOLD, 16)); bno.setBackground(Color.white); cconf.add(bno); cconf.add(tconf); } public void fillNonimm() { lnonimm.setBounds(9, 112, 400, 20); lnonimm.setFont(new Font("Tiresias",Font.BOLD, 16)); l3esci.setBounds(42, 160, 260, 20); l3esci.setFont(new Font("Tiresias",Font.BOLD, 16)); lnonimm.setForeground(Color.white); l3esci.setForeground(Color.white); cnonimm.add(lnonimm); cnonimm.add(l3esci); bnonimm.setBounds(110, 195, 60, 30); bnonimm.setFont(new Font("Tiresias",Font.BOLD, 16)); bnonimm.setBackground(Color.white); bnonimm.setBorder(matte); cnonimm.add(bnonimm); cnonimm.add(tnonimm); } public void fillErut() { errutente.setBounds(5, 112, 350, 20); errutente.setFont(new Font("Tiresias",Font.BOLD, 16)); l4esci.setBounds(42, 160, 260, 20); l4esci.setFont(new Font("Tiresias",Font.BOLD, 16)); errutente.setForeground(Color.white); l4esci.setForeground(Color.white); cerut.add(errutente); cerut.add(l4esci); erbut.setBounds(110, 195, 60, 30); erbut.setFont(new Font("Tiresias",Font.BOLD, 16)); erbut.setBackground(Color.white); erbut.setBorder(matte); cerut.add(erbut); cerut.add(terut); }


Appendice B

257

public void fillErlib() { errvisita.setBounds(10, 112, 350, 20); errvisita.setFont(new Font("Tiresias",Font.BOLD, 16)); l5esci.setBounds(42, 160, 260, 20); l5esci.setFont(new Font("Tiresias",Font.BOLD, 16)); errvisita.setForeground(Color.white); l5esci.setForeground(Color.white); cervis.add(errvisita); cervis.add(l5esci); ersede.setBounds(110, 195, 60, 30); ersede.setFont(new Font("Tiresias",Font.BOLD, 16)); ersede.setBackground(Color.lightGray); ersede.setBorder(matte); cervis.add(ersede); cervis.add(tervis); } public void conferma() { red = statoRosso; statoGenerale = 2; statoRosso = 7; bsi.setBorder(matte); cconf.setVisible(true); repaint(); } public void nonContinua() { statoGenerale = 1; statoRosso = red; bno.setBorder(line); cconf.setVisible(false); repaint(); } public void continua() { cconf.setVisible(false); System.out.println("Codice utente : " + tutente.getText()); System.out.println("Codice visita: " + tvisita.getText()); if((tvisita.getText()).length() < 1 || (tutente.getText()).length() < 1) { statoGenerale = 3; cnonimm.setVisible(true); repaint(); } else { queryUtente(tutente.getText()); if(rutente == false) { statoGenerale = 3; cerut.setVisible(true); repaint(); } else { queryVisita(tvisita.getText(), (String)combo.getSelectedItem(), tf1.getText(), tf3.getText()); if(rvisita == false) {


Appendice B

258

statoGenerale = 3; cervis.setVisible(true); repaint(); } else { cont.removeAll(); statoGenerale = 4; updateVisita(tvisita.getText(), (String)combo.getSelectedItem()); JLabel visitaGiusta = new JLabel("La visita " + tvisita.getText() + " e' stata cancellata"); visitaGiusta.setBounds(225, 300, 700, 50); visitaGiusta.setFont(new Font("Tiresias",Font.BOLD, 16)); cont.add(visitaGiusta); JLabel torna = new JLabel("Premendo il pulsante OK puoi tornare alla ricerca di altre visite"); torna.setBounds(100, 125, 700, 50); torna.setFont(new Font("Tiresias",Font.BOLD, 16)); cont.add(torna); iniziale.setBounds(257,380,190,50); iniziale.setFont(new Font("Tiresias",Font.BOLD, 16)); iniziale.setBackground(Color.white); iniziale.setBorder(matte); cont.add(iniziale); cont.add(informazione[9]); informazione[9].setVisible(true); cont.add(informazione[10]); informazione[10].setVisible(true); Image imagesin; imagesin =Toolkit.getDefaultToolkit().getImage("ok.gif"); Botton1 = new HGraphicButton(imagesin,100,170,70,300); cont.add(Botton1); Image imageds; imageds =Toolkit.getDefaultToolkit().getImage("ok.gif"); Botton2 = new HGraphicButton(imageds,530,170,70,300); cont.add(Botton2); cont.add(Botton); cont.add(text1); cont.add(text2); cont.add(text3); add(cont); setVisible(true); repaint(); System.out.println(statoGenerale); } } } } public void digitaOk() { statoGenerale = 1; statoRosso = red; cnonimm.setVisible(false); cerut.setVisible(false); cervis.setVisible(false); cont.repaint(); } private void queryUtente(String qutente)


Appendice B

259

{ try { Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); } catch(ClassNotFoundException e) { System.out.println(e.toString()); System.exit(1); } try { Connection conn = DriverManager.getConnection("jdbc:odbc:JDBCAsur7"); Statement stmt = conn.createStatement(); String query= "SELECT CODICE_USER FROM UTENTI"; ResultSet rs = stmt.executeQuery(query); String[] matr = new String[9]; int i = 0; while(rs.next()) { matr[i] = rs.getString(1); i++; } for(int count = 0; count < matr.length; count++) { if(qutente.equals(matr[count])) rutente = true; } rs.close(); stmt.close(); conn.close(); } catch(SQLException se) { System.out.println(se.getMessage()); se.printStackTrace(System.out); System.exit(1); } } private void queryVisita(String qvisita, String b, String text1, String text2) { try { Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); } catch(ClassNotFoundException e) { System.out.println(e.toString()); System.exit(1); } try { Connection conn = DriverManager.getConnection("jdbc:odbc:JDBCAsur7"); Statement stmt = conn.createStatement(); String query = ""; if(text1.length() > 1 && text2.length() > 1 ) { query = "SELECT Codice_ID " + "FROM " + b + " WHERE Prenotazione = 1 AND " +


Appendice B

260

"(paziente = '" + text1 + "' AND password = '" + text2 + "')"; } ResultSet rs = stmt.executeQuery(query); while(rs.next()) { cod.add(rs.getString(1)); } cod.trimToSize(); for(int count = 0; count < cod.size(); count++) System.out.println((String)cod.get(count)); for(int count = 0; count < cod.size(); count++) { if(qvisita.equals((String)cod.get(count))) rvisita = true; } rs.close(); stmt.close(); conn.close(); } catch(SQLException se) { System.out.println(se.getMessage()); se.printStackTrace(System.out); System.exit(1); } } private void updateVisita(String qvisita, String b) { try { Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); } catch(ClassNotFoundException e) { System.out.println(e.toString()); System.exit(1); } try { Connection conn = DriverManager.getConnection("jdbc:odbc:JDBCAsur7"); Statement stmt = conn.createStatement(); stmt.executeUpdate("UPDATE " + b + " SET Prenotazione = 0 WHERE Codice_ID = " + qvisita); String query= "SELECT * FROM " + b; ResultSet rs = stmt.executeQuery(query); while(rs.next()) { System.out.print(rs.getString(1) + " "); System.out.print(rs.getString(2) + " "); System.out.print(rs.getString(3) + " "); System.out.print(rs.getString(4) + " "); System.out.println(); } rs.close(); stmt.close(); conn.close(); } catch(SQLException se)


Appendice B

261

{ System.out.println(se.getMessage()); se.printStackTrace(System.out); System.exit(1); } } }


Glossario

262

Glossario DTT: Digital Terrestrial Television DVB: Digital Video Broadcasting DTv: Digital Television EPG: Electronic Program Guide ETSI: European Telecommunications Standards Institute FTV: Free To View HDTV: High Definition Television Defined MHP: Multimedia Home Platform MPEG: Moving Picture Expert Group PAL: Phase Alternative Line QAM: Quadrature Amplitude Modulation SCART: Syndicat des Constructeurs d’Appareils Radio et Television IP: Internet Protocol ISP: Internet Service Provider TCP: Transmission Control Protocol UDP: User Data Protocol HTTP: Hypertext Transfer Protocol TLS: Transport Layer Security LAN: Local Area Network STB: Set Top Box SSL: Secure Socket Layer TDT: Televisione Digitale terrestre


Bibliografia

263

Bibliografia

[01] Java TV API Technical overview [02] Libro bianco sulla televisione digitale terrestre [03] CEI – Guida alla tecnologia e ai servizi dei ricevitori per TDT [04] www.mhp-interactive.org [05] www.televisionedigitaleterrestre.it [08] www.java.sun.com [09] [OPENCA] www.openca.org [10] [OPENSSL] www.openssl.org [11] [OSPKI] OpenCA Team, “The Open-source PKI Book” [12] Core Java 2 di Cay S. Horstmann – Gary Cornell [13] L’arte dell’hacking di Jon Erickson [14] Java 2 La guida completa di Herbert Shildt [15] ws.apache.org/axis/ [16] http://java.sun.com/j2se/1.4.2/docs/api/overview-summary.htm [17] DVB – www.dvb.org [18] MHP – www.mhp.org [19] www.java.sun.com [20] http://www.mokabyte.it/ [21] http://sourceforge.net/projects/xletview/ [22] HAVI – http://www.havi.org/ [23] Java TV – http://java.sun.com/products/javatv/ [24] ETSI Institute – www.etsi.org [25] Cineca - www.cineca.it [26] http://www.wikipedia.it [27] http://www.interactiveweb.org [28] http://www.wmlscript.it

Indice -...

Documents

Transcript of Indice -...