Gestione del flusso dati delle reti del progetto RE.S.M.I.A.

(1)

Università degli Studi di Padova

Dipartimento di Matematica Corso di Laurea in Informatica

Gestione del flusso dati delle reti del progetto RE.S.M.I.A.

Relatore

Prof. Massimo Marchiori

Candidato Matteo Nicoletti

Anno Accademico 2012/2013

(2)

ii

(3)

Indice

1 Introduzione 1

1.1 L’ARPAV . . . 1

1.2 Il SIER . . . 2

2 Drupal 7 5 2.1 Il core . . . 6

2.2 Interfaccia di amministrazione . . . 6

2.3 I moduli . . . 7

2.4 I ”ganci“ . . . 7

2.5 I temi . . . 9

2.6 I nodi . . . 9

2.7 I campi . . . 9

2.8 I menù . . . 10

2.9 I blocchi . . . 10

2.10 La tassonomia . . . 10

2.11 Struttura delle directory . . . 11

2.12 Stack tecnologico . . . 12

3 Analisi 15 3.1 Il progetto di stage . . . 15

3.2 Diagrammi dei casi d’uso . . . 16

3.2.1 UC_1 Caso d’uso generale . . . 16

3.2.2 UC_1.1 Pagina dei dati ambientali . . . 18

3.2.3 UC_1.2 Pagina delle immagini webcam . . . 19

3.2.4 UC_1.3 Visualizzare documenti pubblici . . . 20

3.2.5 UC_1.4 Visualizzare documenti interni . . . 20

3.2.6 UC_1.5 Inserire documenti . . . 21

3.2.7 UC_1.6 Pagina dei log dei parser . . . 22

3.2.8 UC_1.7 Interfaccia per l’amministrazione del sito web 23 3.3 Requisiti di sistema . . . 25

iii

(4)

iv INDICE

4 Progettazione 27

4.1 Tecnologie utilizzate . . . 27

4.2 Struttura generale della rete del progetto RESMIA . . . 28

4.3 Progettazione del sito web . . . 30

4.3.1 Struttura del sito web . . . 31

4.3.2 Le pagine statiche. . . 32

4.3.3 Le pagine di visualizzazione dei dati. . . 34

4.3.4 Le tabelle del database CUGeCO . . . 35

4.3.5 La gestione dei documenti . . . 36

4.3.6 L’aspetto del sito web . . . 36

4.4 Progettazione dei Parser . . . 37

4.4.1 Gestione dei log: Apache log4php . . . 37

4.4.2 Gestione dei ﬁle XML: SimpleXMLExtended . . . 40

4.4.3 Validazione dei ﬁle XML . . . 42

4.4.4 Gestione locale dei ﬁle provenienti dai datalogger . . . 42

4.4.5 Esecuzione dei parser . . . 45

4.5 Tracciato XML . . . 45

4.5.1 Stuttura del ﬁle XML atteso . . . 45

4.5.2 Esempio di ﬁle XML atteso . . . 47

4.6 XML Schema . . . 48

4.7 Norme di progetto . . . 52

4.7.1 Codiﬁca del codice PHP . . . 52

4.7.2 Codiﬁca del codice di Drupal 7 . . . 54

4.7.3 Codiﬁca del codice XML . . . 55

5 Sviluppo 57 5.1 Implementazione . . . 57

5.2 Prodotto ultimato. . . 59

5.2.1 Visualizzare i dati ambientali . . . 60

5.2.2 Visualizzare le immagini webcam . . . 64

5.2.3 Visualizzare i log dei parser . . . 67

5.2.4 Catalogare i documenti . . . 70

5.3 Piano di Progetto . . . 73

6 Verifica e Validazione 77 7 Conclusioni 79 7.1 Uno sguardo al futuro . . . 79

7.2 Considerazioni e valutazione dello stage . . . 82

7.3 Ringraziamenti . . . 82

(5)

INDICE v

Glossario 85

Bibliografia 87

(6)

vi INDICE

(7)

Elenco delle figure

2.1 Una panoramica del core di Drupal 7. . . 6

2.2 Screenshot del menù dell’amministratore (la barra nera in alto) 7 2.3 Abilitando moduli aggiuntivi si hanno più funzionalità. . . 8

2.4 Struttura delle directory in Drupal 7. . . 11

2.5 Stack Tecnologico di Drupal 7. . . 13

3.1 UC_1 Caso d’uso generale. . . 16

3.2 UC_1.1 Pagina dei dati ambientali. . . 18

3.3 UC_1.2 Pagina delle immagini webcam. . . 19

3.4 UC_1.6 Pagina dei log dei parser. . . 22

3.5 UC_1.7 interfaccia per l’amministrazione del sito web. . . 23

4.1 Struttura generale della rete del progetto RESMIA. . . 29

4.2 Particolare di aggiungi contenuto con editor HTML. . . 33

4.3 Diagramma delle attività dei parser.. . . 38

4.4 Diagramma delle classi: SimpleXMLExtended. . . 41

4.5 Directory della rete RESMIA per le stazioni meteo. . . 42

4.6 Directory per le stazioni della rete freatimetrica. . . 44

5.1 Pagina Crea Basic page di Drupal. . . . 58

5.2 Checkbox e form per associare i termini ai contenuti. . . 60

5.3 Form per la ricerca dei dati ambientali. . . 61

5.4 Risultati della ricerca dei dati ambientali.. . . 63

5.5 Form per la ricerca delle immagini webcam. . . 65

5.6 Risultati della ricerca delle immagini webcam. . . 66

5.7 Form per la ricerca dei log dei parser. . . 68

5.8 Risultati della ricerca dei log dei parser. . . 69

5.9 Lista delle pagine asociate al termine selezionato. . . 71

5.10 Pagina contenente i documenti interni. . . 72

5.11 Diagramma a colonne del carico di lavoro. . . 74

7.1 Datalogger in uso nelle stazioni della rete RESMIA. . . 80 vii

(8)

viii ELENCO DELLE FIGURE 7.2 Datalogger di nuova generazione. . . 81

(9)

Elenco delle tabelle

3.1 Descrizione caso d’uso UC_1 . . . 17

3.2 Descrizione caso d’uso UC_1.1 . . . 19

3.9 Requisiti di sistema. . . 26

5.1 Carico di lavoro. . . 73

5.2 Attività svolte durante lo stage. . . 76

ix

(10)

x ELENCO DELLE TABELLE

(11)

Capitolo 1 Introduzione

Questo documento va inteso come una relazione finale afferente all’attività di stage svolta presso l’Ufficio SIER - ”Sviluppo e Migrazione Applicativi“

dell’ARPA Veneto durante il primo trimestre dell’Anno Accademico 2012- 2013.

L’esperienza rientra nell’ambito del progetto STAGE-IT, organizzato da Unindustria eCCIAAP in collaborazione con l’Uﬃcio Stage e Mondo del La- voro del corso di Laurea in Informatica dell’Università di Padova.Al termine del proprio percorso di studi, ogni studente ha la possibilità di confrontarsi con la realtà delle aziende che operano nel settore dell’IT e di mettere in pratica conoscenze e competenze acquisite in aula.

L’attività di stage ha previsto la realizzazione di una applicazione per la gestione del ﬂusso dati delle reti del progetto RE.S.M.I.A., Reti e Stazioni di Monitoraggio Innovative per l’Ambiente.

In questa relazione verranno trattate tutte le attività che hanno permesso la realizzazione del progetto. Inoltre sarà presente anche un capitolo dedicato a Drupal 7,CMS utilizzato per lo sviluppo del sito web.

Le parole sottolineate sono quella che compaiono nel glossario 7.3.

1.1 L’ARPAV

L’ARPAV¹,Agenzia Regionale per la Prevenzione e Protezione Ambientale del Veneto, è il centro deputato alla vigilanza e controllo ambientale in sede locale. La sua formazione rappresenta la risposta alle richieste di difesa e prevenzione primaria collettiva manifestate dagli enti locali e da altri soggetti pubblici e privati.

1Viene istituita con la Legge Regionale n.32 del 18 ottobre 1996 e diventa operativa il 3 ottobre 1997

1

(12)

2 CAPITOLO 1. INTRODUZIONE L’Agenzia è dotata di autonomia amministrativa, organizzativa, tecnica e contabile. Opera sulla base di piani triennali e di un programma annuale. In essa sono presenti diverse ﬁgure professionali che garantiscono un approccio multisciplinare ai compiti dell’Agenzia medesima, scambiandosi informazioni e innovazioni.

L’ARPAV persegue due obiettivi strettamente connessi:

• la protezione, attraverso i controlli ambientali che tutelano la salute della popolazione e la sicurezza del territorio;

• la prevenzione, attraverso la ricerca, la formazione, l’informazione e l’educazione ambientale.

L’Agenzia realizza i propri obiettivi utilizzando competenze tecnico - scien- tifiche che ne diventano caratteristica distintiva, la diﬀerenziano dagli altri Enti amministrativi e ne identiﬁcano la ”mission“.

Le sue attività sono:

• prevenzione e controllo ambientale;

• previsione, informazione ed elaborazione meteoclimatica e radarmeteo- rologica;

• organizzazione e gestione del sistema informativo regionale per il monitoraggio ambientale ed epidemiologico in relazione ai fattori ambientali;

• promozione di attività di educazione ambientale ed informazione ambientale;

• fornitura di supporto tecnico-scientiﬁco per la valutazione di impatto ambientale e per la determinazione del danno ambientale;

• promozione di iniziative di ricerca di base ed applicata sulle forme di tutela ambientale.

1.2 Il SIER

Il SIER,Servizio Informatica E Reti, fa parte della Direzione Amministrativa dell’ARPA Veneto e svolge le seguenti attività:

• Gestisce l’infrastruttura informatica e le risorse strumentali hardware di tutta l’agenzia;

(13)

1.2. IL SIER 3

• Gestisce e coordina il mantenimento delle banche dati dell’Agenzia ed i servizi di assistenza su tutte le applicazioni informatiche dell’A- genzia, con particolare riferimento al Sistema Informativo Regionale Ambientale del Veneto (SIRAV);

• Realizza, anche mediante la collaborazione con le altre strutture dell’A- genzia, i rapporti integrati sugli indicatori ambientali e la deﬁnizione degli stessi;

• Svolge il ruolo di riferimento unitario aziendale in termini di standard operativi, architetture delle realizzazioni, attivazione e gestione tecnica dei portali internet/intranet;

• Coordina e svolge la gestione della connettività aziendale voce e dati, nonché la telefonia ﬁssa e mobile, ed i servizi collegati;

• Coordina e svolge la gestione tecnico operativa per il funzionamento, la manutenzione e la connettività delle reti di monitoraggio dell’Agenzia;

• Organizza, coordina ed ha la responsabilità sulle attività, sulle risorse umane direttamente assegnate, anche per gli aspetti disciplinari, e sulle risorse strumentali aﬀerenti al Servizio;

• Svolge le funzioni di dirigente per le attività di servizio ai sensi della normativa sulla sicurezza del lavoro (D.Lgs. n. 81/2008);

• Applica le procedure inerenti la gestione del budget e degli obiettivi aziendali;

• Applica il Sistema di Gestione della Qualità.

(14)

4 CAPITOLO 1. INTRODUZIONE

(15)

Capitolo 2 Drupal 7

Drupal ¹ è usato per costruire siti web ed è un CMS (Content Manage- ment System) modulare scritto in linguaggioPHP e distribuito sotto licenza GNU GPL. E’ estensibile, conforme agli standard e cerca di mantenere il codice pulito e di dimensioni ridotte. Appena installato Drupal si avvia con delle funzionalità base del core. Per ottenere delle funzionalità aggiuntive ba- sta attivare i moduli già presenti nel core o installarne di nuovi di terze parti o crearsene di propri. Drupal è progettato per essere personalizzato, ma la personalizzazione si ottiene rideﬁnendo il core o aggiungendo moduli senza però modiﬁcare il codice nel core. L’architettura di Drupal inoltre separa la gestione dei contenuti dalla presentazione dei contenuti.

Drupal è molto versatile, può essere infatti utilizzato per costruire un portale internet, un sito web personale, ministeriale o aziendale, un sito e- commerce, un resource directory, un giornale online, un sito di social networ- king, una galleria di immagini, una intranet e qualsiasi altro tipo di sito web che si possa immaginare di creare.

Per quanto riguarda la sicurezza, esiste un apposito gruppo che si occupa di rilasciare aggiornamenti e rispondere alle minacce mantenendo Drupal sicuro. Un’organizzazione senza scopo di lucro denominata Drupal Associa- tion supporta Drupal , migliorando l’infrastruttura del sito web drupal.org e l’organizzazione di convegni ed eventi di Drupal. Inoltre una ﬁorente co- munità di utenti on line, di amministratori del sito, designer e sviluppatore lavorano per continuare a migliorare il software, vedere http://drupal.org e http://groups.drupal.org.

1Per la realizzazione di questo capitolo si è fatto riferimento al libro Pro Drupal 7 development e al sito ufficiale di Drupalhttp://drupal.org

5

(16)

6 CAPITOLO 2. DRUPAL 7

Figura 2.1: Una panoramica del core di Drupal 7 (non sono mostrate tutte le funzionalità).

2.1 Il core

Quando si scarica Drupal 7 da drupal.org quello che si ottiene è il core di Drupal, ovvero un framework leggero che include: il codice che permette al sistema Drupal di essere avviato quando riceve una richiesta, una libreria di funzioni comuni utilizzate di frequente con Drupal e i moduli che forniscono le funzionalità di base come la gestione degli utenti, la tassonomia e l’aspetto del sito tramite template come mostrato in Figura 2.1.

Il core inoltre comprende le funzionalità di base per la creazione di blocchi per la maggior parte dei siti web, compresi aggregatori di feed, blog, sondaggi e forum.

2.2 Interfaccia di amministrazione

L’interfaccia di amministrazione in Drupal è integrata con il resto del sito.

Tutte le funzionalità di amministrazione sono facilmente accessibili attraverso il menù di amministrazione, che in Drupal 7, appare sopra l’intestazione della pagina del sito una volta che si accede come amministratore tramite

(17)

2.3. I MODULI 7

Figura 2.2: Screenshot del menù dell’amministratore (la barra nera in alto)

autenticazione. Nella Figura 2.2 si può notare, nella barra nera in alto, il menù dell’amministratore.

2.3 I moduli

Drupal è un framework modulare. Le funzionalità sono incluse in moduli, che possono essere abilitati o disabilitati tramite un checkbox. Queste sono aggiunte al sito web realizzato con Drupal abilitando dei moduli esistenti, installando moduli scritti dai membri della comunità di Drupal o scrivendo dei nuovi moduli. In questo modo è possibile aggiungere le funzionalità di cui si ha realmente bisogno. Questo è mostrato dalla Figura 2.3.

I moduli possono estendere Drupal aggiungendo nuovi tipi di contenuto come ricette, blog post o ﬁle, e comportamenti come l’invio dell’e-mail di notiﬁca.

Drupal fa uso del design pattern inversion of control, in cui le funzionalità del modulo vengono chiamate dal framework al momento opportuno tramite l’implementazione degli hook (ganci).

2.4 I ”ganci“

Il sistema di funzionamento dei moduli di Drupal è basato sul concetto di hook² (gancio). Un hook è una funzione PHP scritta nella forma foo_bar(), dove foo è il nome del modulo e bar è il nome dell’hook. Ad esempio se il modulo si chiama esempio e l’hook è hook_menu() allora si deve scrivere:

esempio_menu().

Quando si veriﬁca un evento, ad esempio un utente si autentica al sito, Drupal identiﬁca l’hook per quell’evento, in questo caso l’hook_user_login(), e chiama quell’hook in tutti i moduli che lo implementano.

2Per una lista completa degli hook di Drupal 7 si veda: http://api.drupal.org/api/

drupal/includes!module.inc/group/hooks/7

(18)

Figura 2.3: Abilitando moduli aggiuntivi si hanno più funzionalità.

(19)

2.5. I TEMI 9 Quindi un modulo che voglia gestire un certo evento e fornire nuove funzionalità a Drupal deve implementare il relativo hook.

2.5 I temi

I temi, in Drupal, gestiscono la visualizzazione delle pagine del sito, ossia il suo layout, il suo aspetto graﬁco e i colori utilizzati.

Un tema è composto da uno o più ﬁle PHP e da uno o più ﬁle CSS.

I file PHP definiscono l’HTML prodotto per le pagine del sito. I file CSS definiscono il layout, i font, i colori ed altri stili.

A seconda del tema scelto possono essere a disposizione varie regioni, solitamente sono presenti l’intestazione, il piè di pagina, le barre laterali e il corpo principale della pagina. Inoltre se non si è soddisfatti dei temi proposti è sempre possibile creare un proprio tema.

2.6 I nodi

La gestione del contenuto di Drupal è particolare perchè, nonostante sia possibile inserire una grande varietà di contenuti di diverso tipo, essi hanno tutti una caratteristica comune, ovvero sono dei nodi.

Un nodo è un’unità di informazione generica, dotata di alcuni attributi standard: ID, titolo, contenuto principale, autore e altri fra cui il tipo di contenuto (content type).

Ogni contenuto in Drupal è rappresentato da un nodo, e sia l’amministratore che i moduli possono deﬁnirne di nuovi, personalizzando aspetti come ad esempio l’abilitazione o meno dei commenti.

Di default Drupal fornisce due tipi di contenuto:

Article: per le pagine soggette a variazione di contenuto nel tempo come news, blog, comunicati stampa;

Basic page: per le pagine statiche come ’Chi siamo‘ e ’Contatti‘.

2.7 I campi

I contenuti in Drupal sono composti da campi, ad esempio il titolo di un nodo o il corpo della pagina (body) sono un campo.

Si possono usare i campi per costruire qualsiasi tipo di contenuto o tramite interfaccia di amministrazione o tramite la realizzazione di un modulo con l’ausilio delle Field API.

(20)

2.8 I menù

In Drupal sono presenti quattro tipi di menù predeﬁniti:

Menù principale: è usato come menù di navigazione principale. E’ mostra- to in automatico nell’intestazione del sito ed è a orientamento orizzontale.

Menù utente: è usato per gestire i link relativi all’account utente, come ad esempio il link ’Log out‘. E’ mostrato in automatico nell’intestazione del sito ed è a orientamento orizzontale.

Menù di navigazione: è usato come menù di navigazione locale o seconda- rio. E’ possibile visualizzarlo sulla barra laterale destra o sinistra del sito ed è ad orientamento verticale.

2.9 I blocchi

I blocchi sono parti d’informazioni che possono essere visualizzate in una speciﬁca area della struttura del sito. Tramite i blocchi è possibile creare dei menù personalizzati per gli utenti del sito, mostrare informazioni relative al numero di utenti che stanno utilizzando il sito, contenere la lista dei contenuti più visualizzati nel sito ed altre informazioni sia statiche che dinamiche.

2.10 La tassonomia

Drupal ha un sistema di classiﬁcazione dei contenuti chiamato tassonomia (taxonomy) ed è implementato nel modulo del core Taxonomy.

Tramite la tassonomia si possono creare i vocabolari e i termini.

Il vocabolario indica la categoria a cui appartengono i termini, e i termini sono un elemento della categoria a cui appartengono. Ad esempio sport è un vocabolario e calcio, pallavolo, nuoto sono i termini.

Ogni termine può essere associato ai contenuti che possono, in questo modo, essere classiﬁcati o raggruppati o gestiti per vocabolario.

(21)

2.11. STRUTTURA DELLE DIRECTORY 11

Figura 2.4: Struttura delle directory in Drupal 7.

2.11 Struttura delle directory

Di seguito verrà spiegata la struttura delle directory di Drupal 7 ottenuta dopo una corretta installazione:

includes: contiene le librerie delle funzioni comuni che Drupal usa. Il contenuto di questa cartella non va modiﬁcato;

misc: contiene JavaScript, icone e immagini varie presenti nel pacchetto di installazione di Drupal. Il contenuto di questa cartella non va modiﬁcato;

modules: contiene i moduli del core di Drupal con ogni modulo contenuto nella propria directory. Il contenuto di questa cartella non va modiﬁcato, i moduli aggiuntivi vanno inseriti in sites/all/modules;

profiles: contiene i diversi profili di installazione di un sito. Se ci sono altri profili oltre al profilo prestabilito, al momento dell’installazione, Dru-

(22)

12 CAPITOLO 2. DRUPAL 7 pal chiederà quale proﬁlo di installazione utilizzare. In questo modo verranno attivati automaticamente dei moduli anziché altri. Ad esempio un proﬁlo di installazione ’blog‘ che in automatico imposta Drupal come blog.

scripts: contiene script per il controllo della sintassi, per la pulizia del codice, per eseguire Drupal da linea di comando e per eseguire i test suites (nuovo in Drupal 7). Il contenuto di questa cartella non va modiﬁcato;

themes: contiene il software per processare i template e i temi di default di Drupal. Il contenuto di questa cartella non va modiﬁcato, i temi aggiuntivi vanno inseriti in sites/all/themes;

sites: contiene le modiﬁche di personalizzazione del sito, i mdoduli, i temi e i ﬁle caricati nel sito.

sites/all/themes: contiene i temi aggiuntivi sviluppati da terzi.

sites/all/modules: contiene i moduli aggiuntivi sviluppati da terzi.

sites/all/modules/custom: contiene i moduli sviluppati personalmente.

Questa cartella va creata perché non presente alla ﬁne dell’installazione;

sites/default: contiene il ﬁle settings.php per le impostazioni di Drupal;

sites/default/files: contiene tutti i file che vengono caricati sul sito come loghi, immagini, file video, file audio, ecc..

2.12 Stack tecnologico

Gli obiettivi del design di Drupal comprendono sia la possibilità di funzionare bene su hosting web economici sia di essere in grado di scalare ﬁno ad enormi siti distribuiti. Il primo obiettivo comporta l’uso delle tecnologie più popolari, il secondo implica un’accurata codiﬁca. Lo stack tecnologico di Drupal è mostrato in Figura 2.5.

Il sistema operativo è a un così basso livello nello stack che il funzionamen- to di Drupal non dipende direttamente da esso, infatti funziona con successo su qualsiasi sistema operativo che supporti PHP.

Il server web più comunemente usato con Drupal è Apache, anche se possono essere usati altri server web (incluso Microsoft IIS).

Drupal si interfaccia con lo strato database attraverso un livello di astra- zione del database (vedere in Figura 2.5: Database Abstraction Layer ), che è stato totalmente riscritto in Drupal 7. L’interfccia del database fornisce

(23)

2.12. STACK TECNOLOGICO 13

Figura 2.5: Stack Tecnologico di Drupal 7.

un API basato sul PHP Data Object (o PDO). I database più comuni sono MySQL e PostgreSQL. In Drupal 7 inoltre è supportato anche SQLite. Il database è utilizzato da Drupal per memorizzare i contenuti e le configurazioni del sito, anche se alcuni contenuti come i file multimediali sono salvati nel file system del server.

Drupal è scritto in PHP, linguaggio di programmazione che permette agli sviluppatori di creare contenuti dinamici che interagiscono con i database.

Tutto il codice del core di Drupal aderisce a rigorosi standard di codiﬁca e subisce una revisione approfondita attraverso il processo di liberalizzazione del codice.

Drupal 7 richiede la versione di PHP 5.2 (o superiore).

(24)

(25)

Capitolo 3 Analisi

3.1 Il progetto di stage

A seguito degli sviluppi tecnologici e al ﬁne di portare innovazione all’interno del SIER si vuole realizzare un prototipo per la ristrutturazione dei sistemi trasmissivi e di acquisizione dei dati ambientali partendo dai sistemi periferici ﬁno alle banche dati dell’agenzia.

Pertanto le attività saranno concentrate sullo studio del flusso dei dati dai sistemi periferici basati su datalogger (DL) eterogeni, ai protocolli di comunicazione, alla definizione di codifiche standard e alla realizzazione di sistemi di interfacciamento e scambio dati tra i nuovi prototipi e la banca dati aziendale esistente.

Le attività di base saranno:

• studio dei requisiti

• studio della struttura del database dei dati di monitoraggi ambientali dell SIRAV

• deﬁnizione di codiﬁche e stesura del tracciato standard XML da utilizzate per l’invio dei dati dai sistemi periferici alla banca dati.

• realizzazione di un applicativo per il recupero, gestione e codiﬁca, in modo automatico, dei dati che arrivano dai datalogger. Tale programma dovrà produrre in output un ﬁle XML, conforme al tracciato standard, contenente i dati inviati dai datalogger per il successivo inserimento nella banca dati.

• realizzazione di un applicativo per l’inserimento in banca dati dei dati trasmessi tramite il tracciato standard (ovvero un importatore XML)

15

(26)

16 CAPITOLO 3. ANALISI

• stesura sito per la gestione della documentazione del progetto RESMIA e la pubblicazione delle informazioni e dei report con gestione della proﬁlazione utente;

L’agenzia ha imposto l’utilizzo di un CMS in PHP chiedendo altresì di eﬀettuare uno studio sulla scelta del più appropriato considerando anche gli skill dei dipendenti del SIER. Il CMS scelto dovrà inoltre permettere la classiﬁcazione dei documenti archiviati per tipologia.

La realizzazione dell’importatore XML è stata assegnata alla ditta esterna Project Automation S.p.A.. Quindi il mio stage verterà sulla realizzazione di tutti i punti del progetto tranne quest’ultimo.

3.2 Diagrammi dei casi d’uso

3.2.1 UC_1 Caso d’uso generale

Figura 3.1: UC_1 Caso d’uso generale.

(27)

3.2. DIAGRAMMI DEI CASI D’USO 17

Caso d’uso UC_1 Caso d’uso generale

Attori Utente Pubblico, Dipendente ARPAV, Ammini- stratore de Sito e CMS in PHP

Scopo e descrizione Il diagramma illustra le operazioni principali che i diversi utenti possono compiere interagendo con il sito web

Precondizione Il sito web è attivo e mostra agli utenti la home page

Postcondizione L’utente ha compiuto zero o più operazioni fra quelle che il sistema mette a disposizione alla particolare categoria di utenti

Scenario principale Gli utenti utilizzano il sistema in modo diverso a seconda della loro categoria di appartenenza:

• se l’utente è l’Utente Pubblico potrà ac- cedere alla pagina dei dati ambientali (UC_1.1), Accedere alla pagina delle im-

magini webcam (UC_1.2) e visualizzare i documenti pubblici (UC1.3);

• se l’utente è il Dipendente ARPAV potrà visualizzare i documenti interni (UC_1.4), inserire sia di dominio pubblico che priva- to nel sito web (UC_1.5) e accedere alla pagina dei log dei parser (UC_1.6);

• se l’utente è l’Amministratore del si- to potrà interagire con l’interfaccia di amministrazione del sito web (UC_1.7).

Inclusioni Per il Dipendente ARPAV i casi d’uso UC_1.4, UC_1.5 e UC_1.6 richiedono l’autenticazione al sito web (UC_1.8) messa a disposizione dal CMS in PHP

Per l’Amministratore del Sito l’interazione con l’interfaccia di amministrazione (UC_1.7) richiede l’autenticazione al sito web (UC_1.8) messa a disposizione dal CMS in PHP

Tabella 3.1: Descrizione caso d’uso UC_1

(28)

3.2.2 UC_1.1 Pagina dei dati ambientali

Figura 3.2: UC_1.1 Pagina dei dati ambientali.

Caso d’uso UC_1.1 Pagina dei dati ambientali

Attori Utente Pubblico

Scopo e descrizione Il diagramma illustra le operazioni principali che l’Utente Pubblico può compiere interagendo con la pagina dei dati ambientali

Precondizione L’Utente Pubblico ha selezionato il link della pagina dei dati ambientali

Postcondizione L’Utente Pubblico ha visualizzato i risultati ambientali da lui richiesti

Scenario principale L’Utente Pubblico può visualizzare i dati ambientali da lui selezionati (UC_1.1.5)

(29)

Inclusioni All’Utente Pubblico per poter visualizzare i dati ambientali è richiesto di selezionare:

• la data iniziale e la data ﬁnale in cui ricercare i dati (UC_1.1.1);

• il tipo di dato da visualizzare che può essere: Giornaliero, Orario o Al minuto (UC_1.1.2);

• i sensori della stazione scelta (UC_1.1.4) dopo aver selezionato la rete di appartenenza della stazione (UC_1.1.3).

Tabella 3.2: Descrizione caso d’uso UC_1.1

3.2.3 UC_1.2 Pagina delle immagini webcam

Pagina delle immagini webcam

Utente Pubblico

UC_1.2.3 Visualizzare immagini webcam

UC_1.2.1 Selezionare giorno

UC_1.2.2 Selezionare stazione

<<include>>

Figura 3.3: UC_1.2 Pagina delle immagini webcam.

Caso d’uso UC_1.2 Pagina delle immagini webcam

Scopo e descrizione Il diagramma illustra le operazioni principali che l’Utente Pubblico può compiere interagendo con la pagina delle immagini webcam

(30)

Precondizione L’Utente Pubblico ha selezionato il link della pagina delle immagini webcam

Postcondizione L’Utente Pubblico ha visualizzato le immagini webcam da lui richieste

Scenario principale L’Utente Pubblico può visualizzare le immagini webcam da lui richieste (UC_1.2.3)

Inclusioni All’Utente Pubblico per poter visualizzare le immagini webcam è richiesto di selezionare:

• il giorno in cui sono state scattate le immagini webcam (UC_1.2.1);

• la stazione a cui la webcam appartiene (UC_1.2.2).

3.2.4 UC_1.3 Visualizzare documenti pubblici

Caso d’uso UC_1.3 Visualizzare documenti pubblici

Scopo e descrizione Il caso d’uso descrive la fase di visualizzazio- ne dei documenti pubblici da parte dell’Utente Pubblico

Precondizione L’Utente Pubblico sceglie di visualizzare i documenti di dominio pubblico

Postcondizione L’Utente Pubblico ha visualizzato i documenti di dominio pubblico

Scenario principale L’Utente Pubblico può visualizzare i documenti di dominio pubblico ()UC_1.3)

3.2.5 UC_1.4 Visualizzare documenti interni

Caso d’uso UC_1.4 Visualizzare documenti interni

Attori Dipendente ARPAV

(31)

Scopo e descrizione Il caso d’uso descrive la fase di visualizzazione dei documenti interni da parte del Dipendente ARPAV

Precondizione Il Dipendente ARPAV deve essere in possesso delle credenziali per autenticarsi nel sito web Postcondizione Il Dipendente ARPAV ha visualizzato i

documenti interni

Scenario principale Il Dipendente ARPAV può visualizzare i documenti interni (UC_1.4)

Inclusioni Al Dipendente ARPAV per visualizzare i docu- menti interni si richiede l’autenticazione al sito web (UC_1.8) messa a disposizione dal CMS in PHP

3.2.6 UC_1.5 Inserire documenti

Caso d’uso UC_1.5 Inserire documenti

Scopo e descrizione Il caso d’uso descrive la fase di inserimento dei documenti da parte del Dipendente ARPAV Precondizione Il Dipendente ARPAV deve essere in possesso

delle credenziali per autenticarsi nel sito web e di uno o più documenti da inserire nel sito web Postcondizione Il Dipendente ARPAV ha inserito i documenti

nel sito web

Scenario principale Il Dipendente ARPAV può inserire uno o più do- cumenti di dominio pubblico e/o ad uso interno (UC_1.5)

Inclusioni Al Dipendente ARPAV per inserire i documenti nel sistema si richiede l’autenticazione al sito web (UC_1.8) messa a disposizione dal CMS in PHP

(32)

3.2.7 UC_1.6 Pagina dei log dei parser

Figura 3.4: UC_1.6 Pagina dei log dei parser.

Caso d’uso UC_1.6 Pagina dei log dei parser

Scopo e descrizione Il diagramma illustra le operazioni principa- li che il Dipendente ARPAV può compiere interagendo con la pagina dei log dei parser Precondizione Il Dipendente ARPAV si è autenticato nel sito

web e ha selezionato il link della pagina dei log dei parser

Postcondizione Il Dipendente ARPAV ha visualizzato i log dei parser da lui richiesti

Scenario principale Il Dipendente ARPAV può visualizzare i log dei parser ()UC_1.6.4)

(33)

Inclusioni Al Dipendente ARPAV per poter visualizzare i log dei parser è richiesto di selezionare:

• la rete a cui si riferiscono i log (UC_1.6.1);

• il ﬁle di log più recente o più vecchio (UC_1.6.2);

• il tipo di log tra INFO,WARN,ERROR o Nessuno che li visualizza tutti e tre (UC_1.6.3).

3.2.8 UC_1.7 Interfaccia per l’amministrazione del sito web

Figura 3.5: UC_1.7 interfaccia per l’amministrazione del sito web.

(34)

Caso d’uso UC_1.7 interfaccia per l’amministrazione del sito web

Attori Amministratore del Sito

Scopo e descrizione Il diagramma illustra le operazioni principali che l’Amministratore del Sito può compiere inte- ragendo con l’interfaccia per l’amministrazione del sito web

Precondizione L’Amministratore del Sito si è autenticato nel sito web e visualizza l’interfaccia del sito web Postcondizione L’Amministratore del Sito ha compiuto ze-

ro o più operazione messe a disposizione dall’interfaccia del sito web

Scenario principale L’Amministratore del Sito puo decidere di:

• creare contenuti come pagine statiche, commenti, blocchi ecc.(UC_1.7.1);

• eliminare i contenuti(UC_1.7.2);

• inserire nel sito web nuovi Dipendenti ARPAV (UC_1.7.3);

• eliminare dal sito web i Dipendenti ARPAV (UC_1.7.4).

(35)

3.3. REQUISITI DI SISTEMA 25

3.3 Requisiti di sistema

In questo paragrafo vengono elencati i requisiti funzionali obbligatori (RFO), requisiti funzionali desiderabili (RFD), requisiti funzionali opzionali (RFOp) e i requisiti non funzionali (RNF) emersi nella fase di analisi del progetto di stage.

Requisito Descrizione

RFO il sistema deve gestire tre tipi di utenti diversi: utente pubblico, dipendente ARPAV, amministratore del sito RFO L’utente pubblico deve poter selezionare la pagina dei dati

ambientali

RFO L’utente pubblico deve poter selezionare la pagina delle immagini webcam

RFO L’utente pubblico deve poter visualizzare i documenti pubblici presenti nel sistema

RFO L’utente pubblico deve poter visualizzare i dati ambientali tramite form di ricerca

RFO L’utente pubblico deve poter visualizzare le immagini webcam tramite form di ricerca

RFO Il dipendente ARPAV, se registrato nel sistema, deve potersi autenticare con nome utente e password

RFO Il dipendente ARPAV deve poter visualizzare i documenti interni dell’agenzia inseriti nel sistema

RFO Il dipendente ARPAV deve poter inserire nel sistema i documenti di dominio pubblico e i documenti interni RFO Il dipendente ARPAV per inserire i documenti deve

autenticarsi nel sistema

RFO Il dipendente ARPAV deve poter accedere alla pagina dei log dei parser

RFO Il dipendente ARPAV deve poter visualizzare i ﬁle log dei parser

RFO Il dipendente ARPAV per accedere alla pagina dei log dei parser deve autenticarsi nel sistema

RFO L’amministratore deve poter interagire con l’interfaccia per l’amministrazione del sistema

RFO L’amministratore per poter interagire con l’interfaccia deve autenticarsi nel sistema

RFO L’amministratore deve poter creare contenuti RFO L’amministratore deve poter eliminare i contenuti

(36)

26 CAPITOLO 3. ANALISI Requisito Descrizione

RFO Solo l’amministratore deve inserire un nuovo dipendente ARPAV nel sistema

RFO Solo l’amministratore deve eliminare un dipendente ARPAV dal sistema

RFD la selezione della data nei form di ricerca dovrebbe avvenire attraverso calendario pop-up

RFOp la possibilità di avere un’unica pagina di form per impostare la ricerca in modo da evitare più form in più pagine consecutive

RNF il sito deve essere realizzato con un CMS in PHP

RNF ove possibile scegliere tecnologie open source in luogo di quelle proprietarie

RNF l’esecuzione dell’applicativo per il recupero, gestione e co- diﬁca dei dati che arrivano dai datalogger deve essere automatico

RNF il file XML prodotto dall’applicativo per il recupero, gestione e codifica dei dati provenienti dai datalogger deve essere conforme al traccaito XML che verrà definito

Tabella 3.9: Requisiti di sistema.

(37)

Capitolo 4

Progettazione

4.1 Tecnologie utilizzate

In questo paragrafo vengono elencate tutte le tecnologie e gli strumenti di sviluppo software utilizzati durante lo stage.

ubuntu server , nella versione 12.04LTS, per l’esecuzione e lo sviluppo dei servizi richiesti.

Apache piattaforma server web per il sito web e i parser.

PHP come linguaggio di programmazione per la realizzazione dei moduli Drupal e dei parser.

Apache log4php per la creazione e gestione dei ﬁle di log. E’ un framework per PHP.

vsftpd per la gestione delle trasmissioni con protocollo FTP tra stazioni ambientali e server.

XML per la creazione del tracciato e dei ﬁle da archiviare nel database CUGeCO.

Drupal 7 per la realizzazione del sito web.

database CUGeCO database basato su PostgreSQL per l’archiviazione dei dati ambientali dell’agenzia.

PostgreSQL per l’interazione con il database CUGeCO e come database per il CMS Drupal 7.

LibreOffice per la stesura della documentazione.

27

(38)

28 CAPITOLO 4. PROGETTAZIONE Dia per la realizzazione dei diagrammi.

cron per l’esecuzione automatica ad intervalli di tempo preﬁssati dei parser.

links2 per l’esecuzione automatica dei parser tramite cron

4.2 Struttura generale della rete del progetto RESMIA

In questo paragrafo verrà descritta la struttura generale del progetto RE- SMIA (Figura 4.1).

In tale progetto conﬂuiranno stazioni eterogenee. Inizialmente la speri- mentazione è stata portata avanti con stazioni di tipo meteo e freatimetriche.

Le stazioni meteo sono delle stazioni di nuova generazione in corso di messa in opera e forniranno informazioni riguardanti il meteo in merito a:

temperatura, umidità, velocità del vento ed altre caratteristiche relative al meteo. Verranno identiﬁcate nel progetto come stazioni della rete RESMIA.

Le stazioni freatimetriche fanno parte di una rete esistente e funzionante chiamata rete freatimetrica. Queste stazioni sono state convertite al nuovo sistema di gestione delle reti ambientali del Progetto RESMIA. Forniscono informazioni riguardanti l’acqua in merito a: temperatura, salinità, condu- cibilità, livello della falda freatica ed altre caratteristiche relative all’acqua.

Verranno identiﬁcate nel progetto come stazioni della rete freatimetrica.

In accordo con il Tutor aziendale si è deciso di mantenere la distinzione tra le stazioni meteo e le stazioni freatimetrica all’interno del ﬁle system in quanto appartenenti a tipologie di rete diverse tra loro.

L’invio dei dati daidataloggerdelle stazioni freatimetrica e meteo verso il server RESMIA avviene tramite trasmissione radio digitale o tramite connessione UMTS(se il datalogger è predisposto). Viene usato il protocollo FTP per il trasferimento dei ﬁle e per la gestione di tale connessione si è deciso di utilizzare vsftpd, demone FTP molto usato e che consente, tramite poche conﬁgurazioni, di avere un server FTP funzionante.

Il server RESMIA si occupa di ricevere via FTP le informazioni dai datalogger delle stazioni meteo e freatimetrica, di elaborarle tramite i parser che convertono i dati in ﬁle XML, di archiviarle in modo strutturato nel ﬁle system e di ospitare un sito web per la visualizzazione dei dati.

I dati visualizzati dal sito web sono prelevati dal database CUGeCO per quanto riguarda i dati ambientali e dal ﬁle system del server RESMIA per quanto riguarda le immagini webcam e i ﬁle di log.

(39)

4.2. STRUTTURA GENERALE DELLA RETE DEL PROGETTO RESMIA29

Figura 4.1: Struttura generale della rete del progetto RESMIA.

(40)

30 CAPITOLO 4. PROGETTAZIONE L’importatore XML prodotto dalla Project Automation S.p.A. si occupa di prelevare i ﬁle XML dal server e inserirli nel database CUGeCO.

Il progetto di stage ha previsto quindi due attività:

• progettazione e sviluppo del sito web;

• progettazione e sviluppo dei parser.

4.3 Progettazione del sito web

Dall’analisi dei requisiti gli unici vincoli emersi per la scelta degli strumenti da utilizzare sono:

• un CMS in PHP per la realizzazione del sito;

• il databse dell’agenzia CUGeCO per la gestione dei dati;

• l’utilizzo di tecnologie, se possibile, open source.

Di CMS sviluppati su piattaforma PHP ce ne sono molti. Tra questi la scelta si è ristretta a tre: Drupal, Joomla e WordPress.

Tutti e tre hanno molti aspetti in comune come la possibilità di estendere le funzionalità con l’aggiunta di moduli, componenti e/o plugin, la gestione dell’autenticazione degli utenti, l’utilizzo di editor WYSIWYG per la formattazione dei testi, la creazione di pagine statiche, ecc.

Quindi quale scegliere? La mia scelta, approvata poi dal Tutor aziendale, il dott. Paolo Zambotto, è ricaduta su Drupal nella vesrsione 7 perchè supporta nativamente il database PostgreSQL (con cui è realizzato CUGeCO) e permette di classiﬁcare i contenuti tramite tassonomia quindi molto utile per la gestione dei documenti. Inoltre ritenevo stimolante l’utilizzo di un CMS con cui sono stati realizzati siti come quello della Sapienza-Università di Romahttp://sapienza.cineca.it/e quello della Casa Biancahttp://

www.whitehouse.gov/.

Per un approfondimento su Drupal 7 si legga il Capitolo 2.

Rifacendomi alla sezione 2.12 Stack tecnolocico ho deciso di adottare il seguente stack per il sito da sviluppare con Drupal:

Sistema Operativo: GNU/Linux, più precisamente la distribuzione ubuntu server 12.04LTS. La scelta è stata dovuta al fatto che, come richiesto, è open source. Inoltre era già presente nell’agenzia un server con ubuntu server 10.04 LTS per cui i dipendenti ARPAV hanno già familiarità con il sistema operativo in questione. Inﬁne è uno dei sistemi operativi più quotati per allestire un server ed è supportato da una vastissima comunità.

(41)

4.3. PROGETTAZIONE DEL SITO WEB 31 Web Server: Apache. Anche questo applicativo è open source oltre ad essere la piattaforma server web modulare più diﬀusa e generalmente più utilizzata per Drupal.

Database: PostgreSQL. Anche MySQL sarebbe stata una valida scelta, ma la decisione di utilizzare PostgreSQL è stata dovuta al fatto che l’Agenzia ha anni di esperienza con questo database. Quindi ho voluto mantenere la stessa tecnologia anche per Drupal.

Linguaggio: PHP. Questa è stata una scelta obbligata in quanto Drupal per sviluppare il proprio codice utilizza il linguaggio PHP.

4.3.1 Struttura del sito web

La struttura del sito web è stata cosi deﬁnita:

• un menù nella parte superiore che riporta i link alle seguenti pagine:

Home: pagina iniziale del sito in cui viene descritto brevemente il progetto RESMIA e i principali obiettivi di tale progetto.

Il Progetto RE.S.M.I.A.: pagina in cui viene descritto in modo più dettagliato come ARPAV intende realizzare il progetto della rete RESMIA.

Contatti: visualizza i contatti dei responsabili a capo del progetto RESMIA. Vengono visualizzati il titolo, il nome e cognome, il numero di telefono ed l’indirizzo e-mail dei responsabili.

Tutte e tre le pagine precedentemente descritte sono ad accesso pubblico.

• un menù laterale che contiene i link per accedere alle seguenti pagine di visualizzazione dei dati della rete:

Dati: contiene dei form per impostare i propri criteri di ricerca per i dati ambientali della nuova rete ambientale. I dati vengono ricavati tramite interrogazione del database CUGeCO. La pagina deve essere ad accesso pubblico. I criteri di ricerca su cui l’utente può agire sono:

– l’intervallo temporale in cui fare la ricerca, che è composto dalla data iniziale e dalla data ﬁnale

– il tipo di dato, che può essere Giornaliero, Orario, Al minuto – le reti a disposizione

(42)

32 CAPITOLO 4. PROGETTAZIONE – in base alla rete selezionata è possibile selezionarne le stazioni – per ogni stazione selezionata sì deve selezionare il o i sensori di proprio interesse. Ad esempio temperatura, velocità del vento, ecc..

– alla ﬁne dei form deve essere presente il pulsante Cerca.

Immagini Webcam: contiene dei form per selezionare delle immagini webcam registrate dalle stazione della rete RESMIA. Le immagini vengono ricavate dall’archivio creato nel ﬁle system del server RESMIA. La pagina deve essere ad accesso pubblico. I criteri di ricerca su cui l’utente può agire sono:

– selezione del giorno di cui si vogliono vedere le immagini.

– selezione della stazione di cui si vogliono vedere le foto – alla ﬁne dei form deve essere presente il pulsante Cerca.

Log Parser: permette, tramite form, di selezionare i file di log prodotti dai parser. I file di log vengono ricavati dall’archivio creato nel file system del server RESMIA. La pagina è ad accesso privato, tramite autenticazione. I criteri di ricerca su cui l’utente può agire sono:

– selezione della rete – selezione del ﬁle di log

– selezione del tipo di log tra INFO, WARN, ERROR o Nessuno che li visualizza tutti e tre

– alla ﬁne dei form deve essere presente il pulsante Cerca.

Tale menù è stato realizzato tramite il blocco Navigazione messo a disposizione da Drupal.

• per la gestione e classiﬁcazione dei documenti di dominio pubblico e i documenti ad uso interno si utilizza la tassonomia di Drupal.

4.3.2 Le pagine statiche

Le pagine statiche Home Page, Il Progetto RE.S.M.I.A. e Contatti sono state realizzate tramite la funzione Aggiungi contenuto di Drupal.

Per l’inserimento del testo nella pagina si è scelto di installare i moduli WYSISYG e CKEditor i quali arricchiscono Drupal di un editor di testo HTMLche consente una più semplice stesura del testo senza l’uso diretto dei tag HTML.

Un esempio lo si può osservare in Figura 4.2

(43)

4.3. PROGETTAZIONE DEL SITO WEB 33

Figura 4.2: Particolare di aggiungi contenuto con editor HTML.

(44)

34 CAPITOLO 4. PROGETTAZIONE

4.3.3 Le pagine di visualizzazione dei dati

Le pagine Dati, Immagini Webcam e Log Parser sono state realizzate tramite moduli di Drupal. Per le regole che si devono rispettare nella stesura di un modulo si faccia riferimento alle Norme di progetto 4.7.

Ogni pagina ha il suo modulo:

• per la pagina Dati si è realizzato il modulo di nome dati ;

• per la pagina Immagini Webcam si è realizzato il modulo di nome img ;

• per la pagina Log Parser si è realizzato il modulo di nome log.

Ogni modulo è formato da una cartella con lo stesso nome del modulo e contiene i seguenti due ﬁle:

nome_modulo.info: ﬁle di testo che visualizza nella lista dei moduli il nome del modulo, la descrizione e la versione di Drupal per cui è stato scritto

nome_modulo.module: ﬁle scritto in PHP in cui vengono implementate le funzionalità oﬀerte dal modulo

Per ogni modulo si è deciso di implementare i seguenti hook:

hook_help(): fornisce a Drupal le informazioni riguardanti il nostro mo- dulo e fa comparire il link Aiuto (se in lingua ingliese comparirà Help) nella riga del modulo nella pagina della lista dei moduli;

hook_menu(): deﬁnisce la struttura del modulo, ovvero le pagine che lo compongono, le funzioni da richiamare e i permessi di accesso per ogni pagina. Sono state previste due pagine: una raggiungibile tramite link sul menu di navigazione e una che viene richiamata per la visualizzazione dei dati;

hokk_form(): deﬁnisce le form che vogliamo inserire nella nostra pagina attraverso l’utilizzo delle Form API¹ fornite da Drupal.

Per ogni singolo modulo, inoltre, si è pensato di implementare delle funzioni interne che permettano la gestione dei dati.

Il modulo dati implementa le funzioni:

_funzione_lista_reti(): restituisce un array contenente la lista di tutte le reti ricavate dal database CUGeCO;

1Per una conoscenza completa di tutti i tipi di form si rimanda a: http://api.drupal.

org/api/drupal/developer!topics!forms_api_reference.html/7

(45)

4.3. PROGETTAZIONE DEL SITO WEB 35 _funzione_lista_stazioni($id_rete): restituisce un array contenente la lista di tutte le stazioni appartenenti alla rete passata come parametro.

I dati vengono ricavati dal database CUGeCO;

_funzione_lista_sensori($id_rete, $id_stazione): restituisce un array contenente la lista di tutti i sensori appartenenti alla stazione passata come parametro che a sua volta appartiene alla rete passata come parametro. I dati vengono ricavati dal database CUGeCO;

_database_risultati(): restituisce i risultati della ricerca eﬀettuata dal- l’utente tramite form. Ritorna una tabella contenente i dati ricercati, una tabella che riassume le caratteristiche dei sensori selezionati e la tabella della legenda riguardante la validità dei dati. I dati vengono ricavati dal database CUGeCO.

Il modulo img implementa le funzioni:

_risultati_img(): ritorna una tabella contenente le immagini ricercate dal- l’utente tramite form. I dati vengono ricavati dal ﬁle system del server RESMIA, ossia da /home/resmia/rete_resmia/_img/.

Il modulo log implementa le funzioni:

hook_permission(): deﬁnisce la lista dei ruoli per gestire i permessi. Que- sto hook crea il link Permessi sulla stessa riga del nome del modulo nella tabella della lista dei moduli. Inoltre crea la riga con le checkbox per la gestione dei permessi nella tabella della lista dei permessi di Dru- pal in Persone->Permessi sotto il nome del nostro modulo, in questo caso sotto Log Parser ;

_risultati_log(): ritorna una tabella contenente i log dei parser. I dati vengono ricavati dal ﬁle system del server RESMIA, ossia da /home/resmia/rete_resmia/_log/ e da /home/resmia/rete_freatimetrica/_log/

.

4.3.4 Le tabelle del database CUGeCO

Il database CUGeCO è sviluppato con PostgreSQL e consta di quasi cinque- cento tabelle.

Per visualizzare i dati ambientali delle stazioni tramite il sito web, nella fase di progettazione, ne sono state individuate otto:

netcd: contiene i dati riguardanti le reti;

(46)

36 CAPITOLO 4. PROGETTAZIONE testat: contiene i dati riguardanti le stazioni;

teanapt: contiene i dati riguardanti i sensori, in particolare la frequenza di acquisizione dei dati;

teparam: contiene i dati riguardanti i parametri in particolare la descrizione del parametro;

teunit: contiene i dati riguardanti le unità di misura, in particolare il fattore di conversione;

tdday: contiene i dati a campionatura giornaliera;

tdhour: contiene i dati a campionatura oraria;

tdminute: contiene i dati campionati al minuto;

4.3.5 La gestione dei documenti

La gestione dei documenti tramite tassonomia ha richiesto l’installazione del modulo taxonomy_menu.

Una volta installato il modulo si devono creare i vocabolari e i termini che vanno associati ai vari documenti.

Questo modulo permette di visualizzare per ogni vocabolario creato un blocco che per titolo ha il nome del vocabolario. Ogni blocco al suo interno presenta un elenco di link che sono i termini del vocabolario a cui appartengono. In questo modo si crea un menù laterale per ogni vocabolario.

In tale menù selezionando il link di un termine compare una pagina contenente la lista delle pagine che a loro volta contengono i documenti ad esso associati. In questo modo la gestione e ricerca dei documenti risulta molto intuitiva e semplice da utilizzare.

Ogni documento può appartenere a più termini dello stesso vocabolario e a più vocabolari.

Si è deciso di posizionare i blocchi per i documenti pubblici e privati nella barra laterale sinistra.

4.3.6 L’aspetto del sito web

Non è stato necessario scrivere un tema personalizzato per l’aspetto del sito web in quanto il tema Bartik è risultato appropriato. Poiché l’unico difetto del tema è il layout statico, si è deciso di adottare il tema Antonelli il quale non è altro che lo stesso tema Bartik con l’aggiunta del layout ﬂuido.

(47)

4.4. PROGETTAZIONE DEI PARSER 37 Unico limite del tema Antonelli è la dimensione minima in larghezza (1024 pixel) che però non è risultato un problema per l’Agenzia.

4.4 Progettazione dei Parser

La scelta del linguaggio di programmazione da utilizzare per realizzare i parser per la gestione dei file che arriveranno dai datalogger è ricaduta su PHP. Questo perché è un linguaggio che ben si presta alla manipolazione di file di testo, alla gestione di file XML e all’interazione con i database. Inoltre i dipendenti ARPAV del SIER hanno una buona conoscenza del linguaggio PHP che è anche il linguaggio principale con cui sviluppano gli applicativi interni.

I parser si occupano di analizzare i dati provenienti dai datalogger delle stazioni, di produrre un file XML secondo il file XML atteso e di validare il file XML prodotto tramite l’XML Schema fornito da Project Automation S.p.A. (paragrafo4.6).

Si è deciso di sviluppare in linguaggio PHP tre parser:

txt_parser.php: gestisce i ﬁle provenienti dai datalogger della rete RE- SMIA, ovvero le stazioni meteo. I ﬁle provenienti da queste stazioni avranno estensione txt.

img_parser.php: gestisce le immagini webcam provenienti dai datalogger della rete RESMIA, ovvero le stazioni meteo. Le immagini provenienti da queste stazioni avranno estensione jpg.

mis_parser.php: gestisce i ﬁle provenienti dai datalogger delle stazioni della rete freatimetrica. I ﬁle provenienti da queste stazioni avranno estensione mis.

I parser rispettano il diagramma delle attività mostrato in Figura 4.3.

4.4.1 Gestione dei log: Apache log4php

La gestione dei log per i parser avviene tramite il framework Apache log4php.

E’ stato scelto tale framework perché consente di gestire i ﬁle di log in modo facile e ordinato.

Per il suo funzionamento occorre innanzitutto redigere un file di configurazione che può essere un file PHP, il quale contiene le configurazioni strutturate in un array, oppure un file XML. E’ anche possibile redigere il file di configu- razione con un file propeties, ma questo formato è riportato come deprecato nella documentazione di log4php. Per cui la mia scelta è ricaduta sull’utilizzo

(48)

Figura 4.3: Diagramma delle attività dei parser.

(49)

4.4. PROGETTAZIONE DEI PARSER 39 del linguaggio XML in quanto di più facile lettura e comprensione rispetto all’array del ﬁle PHP.

Di seguito viene riportato un esempio del ﬁle di conﬁgurazione in PHP²: r e t u r n array (

’ r o o t L o g g e r ’ => array (

’ appenders ’ => array ( ’ d e f a u l t ’ ) , ) ,

’ appenders ’ => array (

’ d e f a u l t ’ => array (

’ c l a s s ’ => ’ Logger A ppender F ile ’ ,

’ l a y o u t ’ => array (

’ c l a s s ’ => ’ LoggerLayoutSimple ’ ) ,

’ params ’ => array (

’ f i l e ’ => ’ / var / l o g /my . l o g ’ ,

’ append ’ => true )

) ) ) ;

Di seguito viene riportato un esempio del ﬁle di conﬁgurazione in XML³:

<?xml version=" 1 . 0 " encoding="UTF−8" ?>

</ appender>

<appender_ref r e f=" d e f a u l t " />

</ r o o t>

</ c o n f i g u r a t i o n>

Si è deciso di creare due file di configurazione, uno per la rete RESMIA e uno per la rete freatimetrica, in modo da tener distinti i file di log per le due tipologie di reti. Per il primo è stato deciso il nome logRESMIA_config.xml e per il secondo il nome logFreatimetrica_config.xml.

2Tratto da: http://logging.apache.org/log4php/docs/configuration.html

3Tratto da: http://logging.apache.org/log4php/docs/configuration.html

(50)

40 CAPITOLO 4. PROGETTAZIONE Il passo successivo consiste nell’inserire nel file PHP del codice del parser l’inclusione del framework, la dichiarazione del file di configurazione da utilizzare e la creazione di una variabile per l’utilizzo delle funzionalità del framework.

Di seguito un’esempio delle istruzioni da utilizzare:

include ( ’ log4php / Logger . php ’ ) ;

Logger : : c o n f i g u r e ( ’ l o g _ c o n f i g . xml ’ ) ;

$ l o g g e r = Logger : : g e t L o g g e r ( ’ logger_name ’ ) ; Per scrivere nel ﬁle di log si utilizza la seguente sintassi:

$ l o g g e r −>t i p o _ l o g ( " Testo ␣ che ␣ comparira ‘ ␣ n e l ␣ f i l e ␣ d i ␣ l o g

" ) ;

dove tipo_log può essere fatal, error, warn, info, debug, o trace. Per i parser si è deciso di utilizzare solo error, warn e info.

In fase di progettazione si è deciso di mantenere nel file system due file di log per ogni tipo di rete (RESMIA e freatimetrica), ossia un file attuale e uno di backup. Il file attuale viene scritto fino al raggiungimento della dimensione massima di due megabyte, oltre il quale viene salvato come file di backup. Il file di backup, essendo unico, viene di volta in volta sovrascritto. Questi due file vengono gestiti in automatico grazie alle funzionalità di log4php.

Per la rete RESMIA il nome scelto per il ﬁle attuale è logRESMIA.log e per quello di backup è logRESMIA.log.1.

Per la rete freatimetrica il nome scelto per il ﬁle attuale è logFreatimetri- calog e per quello di backup è logFreatimetrica.log.1.

4.4.2 Gestione dei file XML: SimpleXMLExtended

La lettura e scrittura del ﬁle XML da parte dei parser è stata realizzata trami- te la classe SimpleXMLExtended⁴ che estende la classe SimpleXMLElement introdotta con la versione 5 di PHP. In tale classe è stata aggiunta solo la funzione pubblica addCData($cdata_text) che permette di inserire la sezione CDATA dove richiesto nel documento.

Si può osservare il diagramma delle classi nella Figura 4.4.

4Come proposto inhttp://php.net/manual/en/domdocument.createcdatasection.

php

(51)

4.4. PROGETTAZIONE DEI PARSER 41

Figura 4.4: Diagramma delle classi: SimpleXMLExtended.

(52)

Figura 4.5: Directory della rete RESMIA per le stazioni meteo.

4.4.3 Validazione dei file XML

I ﬁle XML prodotti devono essere validati prima di essere salvati nella cartella di archiviazione dei ﬁle XML, in attesa di essere poi prelevati e processati dall’importatore XML.

Per validare questi ﬁle si è deciso di utilizzare la funzione:

DOMDocument::schemaValidate ( string $filename ).

Tale funzione permette di validare un ﬁle XML rispetto ad un XML Sche- ma dato (paragrafo 4.6). Per $filename si intende il percorso del ﬁle XML Schema.

4.4.4 Gestione locale dei file provenienti dai datalogger

Si è pensato di gestire l’archiviazione dei file e delle immagini originali provenienti dai datalogger nel file syistem del server RESMIA. I file, dopo essere stati verificati dal dipendente ARPAV, potranno essere cancellati. Solo i file XML prodotti sono prelevati dall’importatore per l’inserimento nel database CUGeCO.

La struttura delle directory per la gestione dei ﬁle dei datalogger è stata realizzata come mostrato nella Figura 4.5 per la rete Resmia delle stazioni meteo e come mostrato nella Figura4.6per la rete freatimetrica delle stazioni freatimetriche.

Di seguito viene descritta la struttura delle directory della rete RESMIA delle stazioni meteo:

_config: contiene due file XML, stat_config.xml e param_config.xml. Que- sti file verranno utilizzati per la codifica dei dati provenienti dal datalogger delle stazioni della rete RESMIA. Il primo contiene le informazioni

(53)

4.4. PROGETTAZIONE DEI PARSER 43 per la codiﬁca delle stazioni mentre il secondo contiene le informazioni per la codiﬁca dei sensori delle stazioni.

_falliti: contiene tutti i ﬁle in cui viene riscontrata una anomalia.

_img: contiene le immagini originali scattate dalla webcam delle stazioni.

Per una migliore gestione le immagini vengono qui archiviate in sot- tocartelle divise per anno mese e giorno. Ad esempio: /rete_resmia/

_img/2013/01/15/nome_immagine.jpg.

_log: contiene i ﬁle di log dei parser.

_processati: contiene i ﬁle originali con estensione.txt che sono stati pro- cessati. Per una migliore gestione i ﬁle vengono qui archiviati in sotto- cartelle divise per anno mese e giorno. Ad esempio:

/rete_resmia/_processati/2013/01/15/nome_file.txt

_temp: contiene i ﬁle dall’inizio alla ﬁne della loro elaborazione.

_xml: contiene i ﬁle XML validati rispetto all’XML Schema (paragrafo4.6).

L’importatore XML preleva da questa cartella i ﬁle per l’inserimento dei dati ambientali nel server CUGeCO.

staz0000,...,stazXXXX: contengono i ﬁle e le immagini webcam che provengono dalle stazioni. Ogni stazione ha la propria cartella. Da queste cartelle i parser txt_parser.php e img_parser.php prelevano i ﬁle da analizzare.

Di seguito viene descritta la struttura delle directory della rete freatimetrica:

_config: contiene due file XML, stat_config.xml e param_config.xml. Que- sti file verranno utilizzati per la codifica dei dati provenienti dal datalogger delle stazioni della rete freatimetrica. Il primo contiene le informazioni per la codifica delle stazioni mentre il secondo contiene le informazioni per la codifica dei sensori delle stazioni.

_falliti: contiene tutti i ﬁle in cui viene riscontrata una anomalia.

_log contiene i ﬁle di log dei parser.

_processati: contiene i ﬁle originali con estensione.mis che sono stati pro- cessati. Per una migliore gestione i ﬁle vengono qui archiviati in sotto- cartelle divise per anno mese e giorno. Ad esempio:

/rete_freatimetrica/_processati/2013/01/15/nome_file.mis.

(54)

Figura 4.6: Directory per le stazioni della rete freatimetrica.

_temp: contiene i ﬁle dall’inizio alla ﬁne della loro elaborazione.

_xml: contiene i ﬁle XML validati rispetto all’XML Schema (paragrafo4.6).

L’importatore XML preleva da questa cartella i ﬁle per l’inserimento dei dati ambientali nel server CUGeCO.

da_processare: contiene i ﬁle che provengono dalle stazioni. Ogni stazione ha la propria cartella. Da questa cartella il parser mis_parser.php preleva il ﬁle da analizzare.

Dopo essere stati processati i file, prima di essere archiviati, vengono rino- minati. Il nome del file archiviato deve essere formato dal nome della stazione (6 cifre numeriche), dalla data di creazione del file originale nel formato AAAAMMGGhhmm (anno mese giorno ora minuto) e infine dall’estensione

del ﬁle.

Ad esempio 000001201301151200.txt è il nominativo usato per archiviare il ﬁle della stazione 000001 dell’anno 2013 del mese di gennaio il giorno 15 alle ore 12 e 00 minuti.

Si fa notare che per la rete RESMIA si è dovuto creare una cartella per ogni stazione perché la webcam in nostro possesso non permetteva di impostare il nome del file. Tale nome consiste solamente della data in cui la foto viene scattata e non è possibile quindi identificare da quale stazione provenga l’immagine. Per questo, in fase di progettazione, è stato deciso che i dati delle stazioni della rete RESMIA vengano inviati ognuno nella propria cartella nel file system.

(55)

4.5. TRACCIATO XML 45 La rete freatimetrica non prevede l’uso delle webcam. Per Tanto, essendo presente il nome della stazione nel nome del ﬁle, non è stata necessaria una suddivisione delle cartelle.

4.4.5 Esecuzione dei parser

Come emerso dall’analisi dei requisiti l’esecuzione dei parser deve essere resa automatica. Per soddisfare questo requisito è stato usato cron già presente nel sistema operativo ubuntu server 12.04 LTS. Cron è un programma che gira in background e consente la pianificazione di processi da eseguire perio- dicamente tramite un file di configurazione chiamato crontab contenente i comandi shell da eseguire.

Per i parser si è deciso di impostare l’esecuzione ogni quindici minuti.

4.5 Tracciato XML

Dopo una prima fase di analisi del sistema informativo aziendale e dei sistemi di acquisizione dei dati dai datalogger, ho collaborato alla stesura del tracciato XML per l’invio dei dati dai sistemi periferici alla banca dati. Questo tracciato XML è molto importante per l’Agenzia in quanto delinea la struttura che tutti i ﬁle, contenenti i dati ambientali rilevati, dovranno avere per essere inseriti nei database CUGeCO.

4.5.1 Stuttura del file XML atteso

Il ﬁle XML atteso dovrà essere conforme allo standard XML utilizzando dei TAG opportunamente studiati.

<CONTENITORE></ CONTENITORE >: contenitore (radice) del ﬁle XML;

<FORNITORE></FORNITORE>: Fornitore che ha prodotto il ﬁle

<CODFORNITORE></CODFORNITORE>: Codice Fornitore

<ISTANTERUN></ISTANTERUN>: Istante di estrazione dei dati nel formato AAAAMMGGhhmm (anno mese giorno ora minuto).

<PERIODO></PERIODO>: Frase del periodo di dati estratti

<INIZIO></INIZIO >: Data dell’istante iniziale estratto nel formato AAAAMMGGhhmm (anno mese giorno ora minuto).

(56)

<FINE></FINE >: Data dell’istante ﬁnale estratto nel formato AAAAM- MGGhhmm (anno mese giorno ora minuto).

<NOTE></NOTE>: Informazioni sul grado di accuratezza dei dati presenti

<LICENZA></LICENZA>: Licenza d’uso dei dati. Deve contenere il seguente testo:

Dati rilasciati con licenza IODL 2.0 http://www.dati.gov.it/iodl/2.0/

<PROJECTION></PROJECTION>: Sistema di riferimento usato nelle coordinate delle stazioni. Deve contenere il seguente testo:

EPSG:3003

<STAZIONE></STAZIONE>: Gruppo per ogni stazione

<IDSTAZ></IDSTAZ>: Codice della stazione

<TIPOSTAZ></TIPOSTAZ>: Tipologia della stazione

<NOME></NOME>: Nome della stazione

<FREQSTAZ></FREQSTAZ>: Tempo base di archiviazione previsto per la stazione (S per dati a frequenza di minuto, H per dati a frequenza oraria)

<BACINO></BACINO>: Bacino idrograﬁco

<COMUNE></COMUNE>: Comune

<INDIRIZZO></INDIRIZZO>: Indirizzo

<X></X>: Coordinata X (Longitudine)

<Y></Y>: Coordinata Y (Latitudine)

<QUOTA></QUOTA>: Coordinata Quota

<LINKSTAZ></LINKSTAZ>: Link ad un eventuale ﬁle.

<SENSORE></SENSORE>: Gruppo per ogni sensore nella stazione

<ID></ID>: Codice del sensore

<PARAMNM></ PARAMNM>: Nome del sensore