Progettazione e Sviluppo di un Servizio Web per

Commenti

Transcript

Progettazione e Sviluppo di un Servizio Web per
UNIVERSITA’ DEGLI STUDI DI FERRARA
Facoltà di Ingegneria
Corso di Laurea in Ingegneria Informatica
Progettazione e Sviluppo di un Servizio Web per la
gestione del patrimonio multimediale del
Comune di Cento
Tesi di Laurea di:
Daniele Vaccari
Relatore:
Chiar.mo Prof. Ing. Cesare Stefanelli
Anno Accademico: 2006/2007
INDICE
1. Introduzione
1
2. Progetto “Inventario Servizio Sistemi Informativi”
7
2.1 Obbiettivi del progetto
7
2.2 La situazione preesistente
8
2.3 Descrizione del servizio, specifiche e requisiti
9
2.4 Accessibilità
11
2.5 Progettazione del servizio
13
2.5.1 Progetto e struttura della base dati
13
2.5.2 Sistema di autenticazione
15
2.5.3 Livelli di autorizzazione
16
2.5.4 Struttura delle pagine web
17
2.5.5 Progetto del layout
18
3. Tecnologie utilizzate
21
3.1 Apache (Web Server)
21
3.2 Microsoft SQL Server (DBMS)
23
3.3 Microsoft Active Directory
24
3.4 XHTML
26
3.5 CSS
28
3.6 PHP (scripting server-side)
32
3.7 Javascript (scripting client-side)
34
4. Realizzazione della nuova applicazione
37
4.1 Struttura dei dati
37
4.2 Sistema d’autenticazione e assegnazione diritti d’accesso
43
4.3 Architettura del File System
45
4.4 Struttura dell’applicazione
46
4.5 Manuale d’uso
47
4.5.1 Ricerca oggetti
48
4.5.2 Inserimento di un oggetto
50
1
4.5.3 Associazione attributi e categorie
53
4.5.4 Impostazioni applicazione
56
4.5.5 Assegnazione permessi
57
4.5.6 Dismissione oggetti
59
4.6 Accessibilità e stampa
60
4.7 Test del servizio
61
5. Conclusioni
63
6. Riferimenti e bibliografia
65
2
Introduzione
Negli ultimi anni Internet ha conosciuto una crescita esponenziale, in termini di
utilizzatori e di maturità. Se all’origine basava il suo funzionamento esclusivamente
su elementi statici ora è un complesso molto più dinamico, potente e ricco di
servizi; per fare un esempio immediato, si pensi ai molti portali disseminati per la
Rete che offrono al visitatore informazioni e, appunto, servizi di vario genere o
applicativi web (es. Web mail, blog).
Un applicativo Web è un’applicazione per Internet, a cui gli utenti accedono tramite
un Web Browser, cioè un programma in grado di interpretare il codice HTML (e
più recentemente XHTML) e visualizzarlo in forma di ipertesto, consentendo perciò
la navigazione nel Web. Le pagine visualizzate dal browser sono generate in modo
statico o dinamico a seconda della tipologia della risorsa che si va a visualizzare:
tipicamente, per le applicazioni web, tale generazione avviene in modo dinamico.
Il modello Client-Server, utilizzato dalla maggior parte delle applicazioni Web,
permette a un qualsiasi Client (Web Browser) di effettuare una richiesta al Server, il
quale ha il compito di gestire accessi simultanei a risorse condivise (come le basi di
dati) e fornire risposte al Client. L’applicazione web costituisce un modello che
permette di portare i dati da un basso livello di astrazione, strutturati nel database, a
un livello di astrazione più alto, comprensibile dagli utenti.
Il Comune di Cento è uno dei più informatizzati d’Italia ed è all’avanguardia
nell’erogazione di servizi informatici. Dal suo portale è possibile accedere a molti
servizi che di tanto in tanto vengono ampliati e arricchiti. È questo il caso de
“Inventario S.S.I.”, un’applicazione web realizzata nella cornice di un tirocinio
formativo universitario, svolto presso il Servizio Sistemi Informativi (SSI) del
Comune di Cento che si occupa della gestione e amministrazione hardware e
software della rete civica, dell’amministrazione della intranet comunale, del portale
del Comune, della gestione e realizzazione di servizi on-line e siti Web strettamente
collegati al Comune.
La scelta di realizzare il servizio “Inventario S.S.I.” attraverso un’applicazione Web
è stata fatta considerando la facilità con cui al giorno d’oggi è possibile fruire di una
3
risorsa presente sul web, in quanto i requisiti (un elaboratore, un web browser e una
connessione a Internet) sono alla portata di un bacino d’utenza molto corposo e
sempre più attento e capace di sfruttare la vasta gamma di tecnologie pensate per
realizzare e accedere a contenuti web.
Queste tecnologie facilitano da una parte il lavoro dello sviluppatore che, una volta
impostata l’architettura delle stesse, mantenendo separati contenuti e presentazione,
può modificare indipendentemente l’una o l’altra; dall’altra gli utenti del servizio
implementato che, attraverso l’interfaccia web, possono interrogare le base di dati e,
in funzione dei risultati ottenuti, accedere alle informazioni richieste.
Il servizio “Inventario S.S.I.” permette la gestione del patrimonio multimediale del
Comune di Cento, cioè consente di catalogare tutti gli oggetti appartenenti al mondo
dell’informatica e dell’elettronica di proprietà comunale. La differenza sostanziale
tra l’inventario generale del Comune e quello che si è realizzato risiede nella
possibilità di catalogazione per categoria offerta da quest’ultimo.
Nella realizzazione del progetto si è cercato di prediligere una modularità degli
elementi, cercando di creare dove possibile delle astrazioni che permettano
all’applicazione di funzionare indipendentemente dalle piattaforme sottostanti.
Un importante requisito non funzionale riguarda l’adeguamento dell’applicazione a
quelli che sono gli standard di accessibilità e usabilità previsti per le applicazioni
Web utilizzate dalle Pubbliche Amministrazioni. In riferimento a questo punto si è
cercato di privilegiare una struttura semplice e al tempo stesso efficace e un layout
intuibile, accessibile anche a persone ipovedenti o diversamente abili, e il più
possibile conforme a quello già utilizzato da applicazioni relative ad altri servizi,
per facilitare l’utilizzo dell’applicazione stessa da parte di cittadini e dipendenti
comunali.
La progettazione del servizio è stata preceduta da una fase iniziale di interviste e
colloqui, in cui sono state raccolte le specifiche e i requisiti che il servizio doveva
rispettare, come ad esempio la necessità di mantenere la base dati esistente, vista la
mole di dati contenuti in essa.
4
La prima operazione della fase di progettazione è stata quindi l’analisi e la modifica
della base dati, aggiungendo alle tabelle esistenti gli attributi essenziali e creando le
tabelle necessarie per le nuove funzionalità dell’applicazione.
Il servizio sviluppato prevede un sistema d’autenticazione, grazie al quale è
possibile assegnare a ogni utente degli specifici diritti d’accesso, grazie ai quali
l’applicazione consente all’utente di fruire di certe funzionalità rispetto ad altre.
L’applicazione consente a tutti i livelli d’autorizzazione di navigare all’interno
dell’archivio, di effettuare ricerche secondo alcuni parametri quali categoria,
locazione e attributo/caratteristica e di visualizzare delle statistiche di tipo generale
sull’archivio.
La parte d’amministrazione del servizio consente di gestire le categorie d’oggetto,
gli attributi che caratterizzano gli oggetti e l’associazione fra questi. Anche
l’inserimento di un nuovo oggetto nell’archivio è riservato agli utenti con diritti
d’amministratore, i quali possono anche modificarlo, dismetterlo e successivamente
eliminarlo dall’archivio. La dismissione infatti, non comporta l’eliminazione
dell’oggetto, ma il trasferimento dello stesso dall’archivio degli oggetti attivi a uno
parallelo degli oggetti dismessi.
La navigazione dell’archivio degli oggetti dismessi è consentito soltanto agli
amministratori del servizio, i quali possono usufruire anche di uno strumento di
ricerca che ricalca quello dell’inventario degli oggetti attivi, ma che offre anche
altre possibilità di ricerca quali la data e la motivazione della dismissione.
5
6
2. Progetto “Inventario Servizio Sistemi Informativi”
In questo capitolo viene presentato il progetto “Inventario Servizio Sistemi
Informativi”, unitamente a quelli che sono i suoi obiettivi, la situazione preesistente
e il passaggio dall’applicazione precedente a quella attuale.
Il processo che ha portato alla creazione dell’applicativo, è stato diviso in tre fasi:
• progettazione;
• sviluppo;
• test.
La fase iniziale di progettazione ha previsto un’attenta analisi di quella che era la
situazione in cui ci si trovava, valutando debolezze e mancanze dell’applicazione
utilizzata fino a quel momento e cercando di individuare le caratteristiche che
avrebbe dovuto avere la nuova applicazione per poter sopperire a tali carenze e
aggiungere nuove funzionalità. A tale scopo è stato organizzato un incontro con i
committenti del lavoro, nonché utilizzatori del servizio, per raccogliere richieste,
pareri e consigli su come dovesse essere l’applicativo che si stava andando a
sviluppare.
Durante la fase di sviluppo successiva, per rendere l’applicazione il più possibile
attinente alle specifiche dei committenti sono stati pianificati altri momenti
d’incontro, per il sorgere di problematiche o per l’introduzione di nuove
funzionalità non considerate in precedenza.
L’ultima fase del progetto è stata quella di test, per verificare la stabilità e la
sicurezza dell’applicativo appena realizzato,
nonché la resa su alcuni PC con
caratteristiche differenti, per assicurarsi del pieno rispetto degli standard e dei criteri
di accessibilità appositamente studiati per non ostacolare la reperibilità delle
informazioni ai cittadini.
2.1.
Obiettivi del progetto
Il comune di Cento, come altri enti pubblici o aziende private, dispone di un
inventario generale degli oggetti di proprietà comunale, censiti in esso senza
compiere nessuna distinzione in base alla natura dell’oggetto.
7
Parallelo a questo inventario, alcuni uffici comunali ne hanno istituito un altro che
raccogliesse soltanto i dati relativi agli oggetti “multimediali” in uso presso la sede
comunale, le delegazioni oppure nel territorio comunale.
Per “multimediali” il comune intende tutti quegli oggetti appartenenti al mondo
dell’elettronica e dell’informatica (es. stampanti , fax, PC), con eccezione per i
dipendenti comunali, raccolti anch’essi in quest’inventario per identificare gli
utilizzatori dei dispositivi censiti.
Il progetto “Inventario S.S.I.” prevede lo sviluppo di un applicativo Web per la
consultazione e gestione dell’archivio del patrimonio multimediale.
La concezione classica di archivio è quella di una lista d’oggetti, identificati da un
numero progressivo, indipendentemente dalla natura e le caratteristiche
dell’oggetto, mentre quest’archivio basato sulla tipologia dell’oggetto, deve essere
dinamico, flessibile e permettere di seguire lo sviluppo tecnologico che, soprattutto
nel mondo dell’elettronica e dell’informatica, è rapido e frenetico.
L’applicazione deve quindi fornire gli strumenti necessari per rendere l’archivio
atto ad accogliere oggetti di natura differente, frutto di sviluppi tecnologici non
considerati durante la fase di progetto.
2.2. La situazione preesistente
Il Comune di Cento, e più precisamente gli uffici: Servizio Sistemi Informativi
(S.S.I.) e Servizio Informativo Territoriale (S.I.T.), si servivano di un servizio per la
gestione del patrimonio multimediale, progettato a suo tempo, come applicazione
integrante per ArcReader [ArcReader].
ArcReader è un software gratuito che permette la visualizzazione di mappe e piante
di edifici, in questo caso degli immobili comunali distribuiti su tutto il territorio
comunale, identificando con diverse icone i differenti tipi d’oggetti, posizionati
sulle planimetrie attraverso l’assegnazione di coordinate cartesiane. Questo
programma presentava però delle limitazioni, come la mancanza della possibilità di
inserimento e modifica di un oggetto o la visualizzazione delle caratteristiche
complete dell’oggetto, quest’ultima sopperita dalla fornitura di un link ipertestuale
specifico per ogni oggetto.
8
Per questo motivo fu scelto di sviluppare un applicazione web per sopperire alle
mancanze del programma stesso.
Con l’aumento di oggetti catalogati e con l’acquisto di tipologie d’oggetto, non
previste in fase di sviluppo, gli uffici S.S.I. e S.I.T., si sono accorti che il servizio
presentava delle forti limitazioni e delle lacune, come:
• Home Page non funzionale e mal strutturata (figura 1);
• mancanza di un modulo di ricerca;
• impossibilità di gestire gli accessi all’applicazione e assegnare autorizzazioni
a gruppi di utenti;
• mancanza di una sezione di amministrazione che permettesse di effettuare
ampliamenti e correzioni senza agire manualmente sul database;
• mancanza di un sistema di registrazione accessi ed errori;
• interfaccia Web non rispettante le normative sull’accessibilità e usabilità per
la P.A.[Servizi Web P.A.].
Figura 1. Home Page del vecchio servizio
2.3. Descrizione del servizio, specifiche e requisiti
La realizzazione di una nuova applicazione più performante e indipendente da altre
applicazioni nasce dall’esigenza di fornire un’interfaccia il più possibile omogenea
9
rispetto a quella utilizzata da altri servizi Web già esistenti, con l’intento di
facilitarne l’utilizzo da parte dei dipendenti comunali aventi già familiarità con altri
servizi e nel rispetto delle regolamentazioni su accessibilità e usabilità delle
applicazioni Web per le pubbliche amministrazioni, con l’intento di permetterne
l’utilizzo anche a utenti diversamente abili e alla necessità di aggiungervi nuove
funzionalità che migliorassero il servizio e rimediassero a tutte le carenze che la
vecchia applicazione “Inventario S.S.I.” presentava.
Dall’incontro con i dipendenti degli uffici S.S.I. (Servizio Sistemi Informativi) e
S.I.T. (Servizio Informativo Territoriale), è emerso che il servizio che si andava a
creare, doveva disporre di due modalità d’utilizzo, in base ai diritti d’accesso
associati all’utente, una modalità di consultazione e una d’amministrazione.
Per quanto concerne la modalità di consultazione, si vuole che:
• gli utenti possano navigare all’interno dell’archivio, usufruendo degli
strumenti forniti dal servizio per eseguire ricerche secondo alcuni parametri
quali categoria, locazione e attributo/caratteristica;
• gli stessi possano visualizzare il dettaglio di un singolo oggetto;
• gli stessi possano visualizzare statistiche generali sull’archivio;
• siano rispettate le normative relative all’accessibilità e all’usabilità.
Quanto alla modalità d’amministrazione, gode di tutte le caratteristiche della
modalità consultazione, offrendo inoltre:
• inserimento e modifica di un oggetto;
• possibilità di modifica delle impostazioni del servizio;
• gestione delle tipologie d’oggetto;
• gestione degli attributi/caratteristiche relativi alla singola tipologia d’oggetto;
• gestione degli accessi all’applicazione e assegnazione di autorizzazioni a
gruppi di utenti;
• gestione dello storico degli oggetti;
• gestione degli edifici e dei locali a essi associati.
Oltre a requisiti dal lato dell’applicazione, sono stati definiti alcuni vincoli dal lato
del sistema, come ad esempio l’utilizzo della base dati preesistente, vista la mole di
10
dati da conservare, mantenendo invariata anche la struttura di determinate tabelle,
utilizzate dal programma ArcReader per la rappresentazione degli oggetti nelle
mappe.
Infine si è voluto mantenere la possibilità di interazione fra ArcReader e la nuova
applicazione, lasciando inalterato il metodo col quale questa interazione avveniva
anche con la vecchia applicazione: un collegamento ipertestuale.
2.4. Accessibilità
L’accessibilità, in informatica, è la capacità di un dispositivo, di un servizio o di una
risorsa d’essere fruibile con facilità da una qualsiasi categoria d’utente.
Il termine è comunemente associato alla possibilità anche per persone con ridotta o
impedita capacità sensoriale, motoria, o psichica (in termini generali disabile o
diversamente abile sia temporaneamente sia stabilmente), di fruire dei sistemi
informatici e delle risorse software a disposizione. Il termine ha trovato largo uso
anche nel settore di Internet col medesimo significato.
Nel web, un sito web accessibile facilita l’accesso a individui con ogni tipo di
disabilità, ma anche a individui non affetti da patologie. Più nello specifico:
• utilizza un codice semanticamente corretto, logico e validato secondo i
parametri del W3C [W3C];
• utilizza testi chiari, fluenti e facilmente comprensibili;
• utilizza testo alternativo per ogni tipo di contenuto multimediale;
• sfrutta titoli e link che siano sensati anche al di fuori del loro contesto
(evitando, ad esempio, link su locuzioni come "clicca qui");
• ha una disposizione coerente e lineare dei contenuti e dell’interfaccia grafica.
Inoltre dovrebbe essere compatibile col maggior numero di browser e PC e
utilizzare colorazioni standard e ad alto contrasto.
L’applicazione corretta dei criteri di accessibilità deve permettere la lettura da parte
di software detti screen reader specifici per ipovedenti o non vedenti del terminale
video.
11
Esistono alcuni standard e alcune linee guida per definire l’accessibilità. Le linee
guida internazionalmente più diffuse per quanto riguarda il web sono le WCAG,
Web Content Accessibility Guidelines della WAI [WAI], Web Accessibility
Initiative (sezione del World Wide Web Consortium).
In Italia per le nuove realizzazioni e le modifiche apportate dalla Pubblica
amministrazione al proprio o ai propri siti web permettono di tenere conto (a pena
della nullità dei contratti stipulati) della “Legge Stanca” (Legge 4 del 9 gennaio
2004, pubblicata nella Gazzetta Ufficiale il 17 gennaio 2004), e successivamente
resa operativa col decreto attuativo di fine 2005. Lo stesso identico obbligo è in
carico, come contenuto nell’art. 2 della legge, agli enti pubblici economici, alle
aziende private concessionarie di servizi pubblici, alle aziende municipalizzate
regionali, agli enti di assistenza e di riabilitazione pubblici, alle aziende di trasporto
e di telecomunicazione a prevalente partecipazione di capitale pubblico e alle
aziende appaltatrici di servizi informatici. L’obbligo della applicazione della legge
sussiste esclusivamente per i siti pubblici (o di interesse pubblico) mentre, sempre
nell’ambito pubblico le disposizioni di legge non si applicano ai sistemi informatici
destinati ad essere fruiti da gruppi di utenti dei quali, per disposizione di legge, non
possono fare parte persone disabili.
Per quanto concerne l’applicazione “Inventario S.S.I.” si è cercato di rispettare il
più possibile le specifiche del WAI, in particolar modo:
• creando un layout semplice, fluido e dalle colorazioni ad alto contrasto;
• evitando l’uso delle tabelle per la creazione della struttura del layout;
• fornendo la possibilità di gestire l’intera applicazione da tastiera;
• evitando l’uso di immagini per la realizzazione del layout;
• fornendo un testo alternativo a ogni immagine o icona;
• organizzando i form in maniera coerente e logica.
Nell’ambito dei form, cioè dei moduli compilabili per l’inserimento dei dati, si è
scelto di fornire sempre una descrizione generale del modulo e di associare
un’etichetta descrittiva a ogni campo.
12
Si è scelto inoltre di utilizzare codice client-side degradabile, cioè ripetuto anche
lato server, per fornire lo stesso servizio anche a utenti che per vari motivi non
possano usufruire dei vantaggi offerti dall’esecuzione del codice client-side. Un
esempio di ciò possono essere i controlli effettuati sulla validità dei dati inseriti nei
campi di un generico form prima del loro invio alla pagina che li elaborerà, infatti
questi controlli oltre a essere eseguiti lato client, vengono sempre ripetuti anche lato
server.
2.5. Progettazione del Servizio
Questo capitolo vuole illustrare quella che è l’architettura del progetto, cioè la
struttura su cui si basa l’applicazione e grazie alla quale è stata realizzata.
Tratta quindi del procedimento che ha portato alla definizione delle entità logiche
coinvolte, alla creazione di una struttura dei dati nel database, alla gestione del
sistema di autenticazione con assegnamento di specifici permessi a differenti gruppi
di utenti, alla strutturazione delle pagine Web e dell’interfaccia proposta dalle
stesse.
Si è cercato di realizzare l’applicazione in modo modulare, cioè mantenendo
separati quelli che sono i componenti della stessa in previsione di future modifiche,
fornendo al tempo stesso una gerarchia di funzionalità, limitandone la visibilità
all’interno dell’applicazione. Infatti vengono definite funzionalità comuni,
accessibili a più livelli di autorizzazione, mentre funzionalità più specifiche,
utilizzate solo in ambito di gestione o di amministrazione, vengono nascoste ai
livelli inferiori di autorizzazione.
2.5.1. Progetto e struttura della base dati
Uno dei requisiti fondamentali del progetto, prevedeva l’utilizzo di Microsoft SQL
Server come DBMS, vista la preesistenza di una base dati consistente da
conservare, mantenendo invariata anche la struttura di determinate tabelle, utilizzate
dal programma ArcReader per la rappresentazione degli oggetti nelle mappe.
13
Analizzando il database si è notato che esistevano sei tabelle, di cui tre contenevano
informazioni sulle locazioni (edifici, piani, stanze), una sui servizi offerti, una sulla
tipologia d’oggetto e infine la principale conteneva tutte le entità “oggetto”.
Nell’incontro iniziale con i dipendenti degli uffici S.S.I. e S.I.T., sono stati messi in
evidenza i difetti che la base dati preesistente aveva, in particolar modo il fatto che
tutte le entità “oggetto” avessero gli stessi attributi, anche nel caso che la categoria
d’oggetto fosse diversa. Ne conseguiva che all’atto dell’inserimento venivano
richiesti attributi non connessi con l’oggetto, che poi comparivano anche nella
scheda di dettaglio dell’oggetto stesso come attributi vuoti (ad esempio il numero di
telefono per una stampante).
Secondo i dipendenti, questo problema rappresentava una grande limitazione per il
servizio, aggravato dal fatto che l’inserimento di un nuovo attributo e l’associazione
con una categoria d’oggetto era possibile soltanto agendo direttamente sulla base
dati e modificando il codice sorgente delle pagine d’inserimento e di
visualizzazione dell’oggetto stesso.
Viste le richieste e sentite le proposte di sviluppo, si è optato per una soluzione
completamente dinamica e comodamente gestibile dal pannello d’amministrazione,
in cui fosse possibile aggiungere, modificare o eliminare le categorie d’oggetto e gli
attributi, creando poi le associazioni fra questi.
Questa scelta si è riflessa sulla struttura del database con l’inserimento di una nuova
tabella che rappresentasse le entità “attributi”, relazionata con la tabella che
rappresentava le entità “categorie d’oggetto” attraverso un’ulteriore tabella, visto
che le relazioni potevano vedere una categoria associata a più attributi e un attributo
a più categorie.
La nuova tabella “attributi”, rappresenta i campi della tabella “oggetto”, di
conseguenza tutte le operazioni di aggiunta ed eliminazione compiute su di essa si
ripercuotono in ugual modo sui campi della tabella “oggetto”, rendendola quindi
una tabella a struttura dinamica.
Infine, per soddisfare tutti i requisiti del progetto, sono state create altre cinque
tabelle disgiunte dalle preesistenti, col compito di contenere informazioni sugli
14
accessi, sulle destinazioni d’uso dei locali, sui permessi assegnati agli utenti e delle
liste d’esclusione dal servizio.
In figura 2 si può notare lo schema Entità-Relazione (Entity-Relationship), anche
detto schema E-R del progetto.
Figura 2. Schema E/R del progetto
2.5.2. Sistema di autenticazione
Il servizio “Inventario S.S.I.” prevede un meccanismo di autenticazione all’accesso,
per poter assegnare a ogni utente i diritti d’utilizzo personali.
L’autenticazione viene delegata al web server che ricevendo username e password,
li passa al controller di dominio, che, confrontandoli con le informazioni sugli
account in suo possesso, fornisce o meno il consenso per l’accesso alle risorse
condivise della rete comunale. Tale struttura, oltre a proteggere le macchine della
Intranet, permette di implementare un sistema di tipo Single Sign On (SSO), cioè
una modalità di autenticazione che permette all’utente di inserire le credenziali una
sola volta, al momento dell’accesso alla Intranet, avendo accesso a più applicativi
15
senza che il server chieda nuovamente l’autenticazione; questo è possibile
installando sul web server uno specifico modulo che realizza tale meccanismo.
Per realizzare questo sistema è stato installato un modulo sul server web che mette a
disposizione funzioni necessarie per l’interazione tra il server web e il servizio di
directory, dove risiedono le informazioni d’accesso degli utenti che hanno accesso
all’intranet comunale.
In questo modo, a meno di particolari impostazioni dell’applicazione, tutti gli utenti
che hanno accesso alla intranet possono, di conseguenza, accedere al servizio.
2.5.3. Livelli di autorizzazione
A differenza dell’applicazione esistente, dove il livello di autorizzazione era unico,
visto che per accedere era necessario inserire un username e una password generica
e uguale per tutti gli utenti, l’applicativo che si è andati a realizzare prevede tre
livelli di autorizzazione:
• non autorizzato;
• lettore;
• amministratore.
L’assegnazione di questi diritti d’accesso è stata resa possibile grazie al nuovo
sistema d’autenticazione, che richiede le credenziali personali di ogni utente e non
più quelle generiche.
Il livello “non autorizzato”, può essere assegnato nel caso in cui il servizio sia
fruibile nella modalità con “Accesso limitato” a un utente che non abbia nessun
diritto specifico, altrimenti tutti gli utenti che hanno accesso alla intranet possono
accedere al servizio con i diritti di “lettore”.
La modalità “lettore” consente la libera consultazione dell’archivio, fornendo gli
strumenti per eseguire ricerche secondo alcuni parametri quali categoria, locazione
e attributo/caratteristica, visualizzare il dettaglio di un singolo oggetto e le
statistiche generali sull’archivio.
Infine
la
modalità
“amministratore”
consente
il
completo
controllo
dell’applicazione, fornendo accesso a una sezione riservata dove è possibile gestire
16
le categorie degli oggetti, gli attributi associati ad ogni singola categoria, le
locazioni degli oggetti, assegnare permessi e diritti d’accesso all’applicazione,
abilitare o meno delle funzionalità (ad esempio: Accesso Limitato) e consultare i
file di log degli accessi e degli errori verificatisi durante il funzionamento
dell’applicativo.
L’amministratore può inoltre gestire completamente la “vita” di un oggetto,
dall’inserimento in archivio, alla sua dismissione e successiva eliminazione,
offrendo gli strumenti per la modifica degli attributi che lo caratterizzano. La
funzione di ricerca offre inoltre, per questo livello d’autenticazione, alcune
possibilità aggiuntive su cui basare la ricerca di uno o più oggetti.
Nonostante le specifiche attuali, concordate durante l’incontro con gli utilizzatori
del servizio, prevedessero soltanto i tre livelli d’autorizzazione sopracitati, non ci si
è preclusa la possibilità di crearne di nuovi, strutturando l’applicazione in maniera
congrua.
2.5.4. Struttura delle pagine web
I principi generali secondo cui si basa una buona progettazione di un’applicazione
web insegnano a generare una nuova pagina web ogni qual volta si individua un
nuovo contenuto semantico: in altre parole il significato di una pagina si deve
distaccare da tutte le altre, mentre per ciò che riguarda contenuti simili è buona
abitudine cercare di raggrupparli in un’unica pagina differenziando i vari stati in cui
si trova la stessa attraverso parametri passati in POST o in GET tra le pagine stesse.
Oltre al rispetto di questi principi, si è cercato di ottimizzare il codice, individuando
le parti simili (se non del tutto uguali) e inserendole in appositi file, inclusi
successivamente laddove fossero necessari.
Si è scelto di dividere le pagine in due sezioni distinte, temporalmente e
logicamente successive:
• esecuzione codice server-side (PHP);
• fornitura pagina (X)HTML richiesta.
Nella prima fase, vengono inclusi tutti i file necessari a fornire la pagina richiesta
dall’utente, vengono controllate le credenziali dell’utente e, se necessario, stabilita
17
una connessione al database o ad Active Directory per le successive operazioni
richieste. Elaborate tutte le informazioni e i dati, vengono chiuse le connessioni
precedentemente stabilite, concludendo la prima fase.
La fase successiva consiste nella creazione del flusso dati della pagina web, che
compresso grazie all’algoritmo Gzip, viene poi spedito all’utente.
La scelta di strutturare ogni pagina secondo questo schema, è stata fatta per avere
una miglior gestione degli errori derivanti dall’elaborazione iniziale e per ridurre il
tempo di fornitura di una richiesta. Infatti se ad esempio si verificasse un errore
nella lettura dal database, questo sarebbe già noto prima di cominciare a spedire la
pagina web, offrendo la possibilità di reindirizzare l’utente verso una pagina di
servizio che lo informa di un possibile malfunzionamento.
2.5.5. Progetto del layout
Il progetto del layout del servizio, è un punto fondamentale nello sviluppo di un
applicativo web.
Facilità e intuibilità d’uso, rispetto per le specifiche relative all’accessibilità, sono i
punti cardine su cui si è basata la realizzazione dell’interfaccia grafica, senza
tralasciare un altro aspetto importante, ovvero l’uso del tag <table> (le tabelle) non
per realizzare l’impaginazione delle pagine web, ma solo come aggregatrici di
informazioni strettamente connesse tra loro. Quest’ultimo aspetto oltre a influire in
maniera diretta sul layout, riduce la dimensioni (in termini di Kbyte) delle pagine
web, offrendo quindi un ulteriore vantaggio, quale un aumento, seppur modesto, di
velocità di fruizione del servizio.
Si è cercato di creare, per quanto possibile, un’interfaccia simile agli altri servizi
pubblicati sulla rete intranet, per facilitare l’utilizzo dell’applicazione stessa da
parte dei dipendenti comunali.
Per uniformare il layout tra le varie pagine e per renderlo facilmente modificabile o
eventualmente sostituito, si è optato per l’utilizzo di un “template”. Questo
strumento è utilizzato per generare pagine web con struttura simile e definisce lo
scheletro della pagina, cioè la disposizione dei vari contenuti all’interno di
18
quest’ultima. Il template viene applicato automaticamente a tutte le pagine del
progetto e una modifica ad esso si ripercuote su tutte le pagine che lo utilizzano.
Una qualsiasi pagina si può dividere in quattro specifiche aree (figura 3):
• intestazione o header: è la parte superiore della pagina, contiene il logo del
comune e alcune informazioni relative all’utente che si collega al servizio,
come il suo username, il suo gruppo d’appartenenza e il suo ultimo accesso
all’applicazione (figura 4);
• menù: vi sono presenti i collegamenti per accedere alle diverse funzionalità
di una sezione o per muoversi da una sezione ad un'altra del servizio
(navigazione);
• contenuto: è la parte centrale e più importante della pagina, in quanto è
quella che contiene le informazioni che la pagina fornisce;
• footer: è la parte inferiore della pagina, il cui scopo principale è quello di
elencare le accessKey presenti nella pagina, distinguendo tra quelle del menu
e dei sottomenù presenti (figura 5).
A differenza del layout di altri servizi, compresa la vecchia versione di questa
applicazione, in cui nell’intestazione era presente un collegamento al portale
dell’intranet comunale, contenente un’immagine che raffigurava il logo e l’indirizzo
della intranet, il collegamento in questo caso è stato realizzato tramite un semplice
scritta, alla quale si è applicato grazie all’utilizzo dei CSS [CSS], il logo del
Comune. Grazie a questo metodo si è riusciti a rendere la pagina più accessibile e
visualizzabile, nel caso un utente fruisca dell’applicativo attraverso un browser
testuale o uno screen reader (applicazione software che identifica ed interpreta il
testo mostrato sullo schermo di un computer).
19
Figura 3. Layout delle pagine del servizio “Inventario S.S.I.”
Figura 4. Intestazione delle pagine
Figura 5. Esempio di footer di una pagina
20
3. Tecnologie Utilizzate
In questo capitolo verranno presentate le tecnologie utilizzate per realizzare il
servizio “Inventario S.S.I.”, verranno riassunte in breve le caratteristiche ed il
funzionamento di tali strumenti e le motivazioni che hanno portato gli
amministratori della rete ad adottarle.
Il DBMS (Database Management System) utilizzato per il progetto è Microsoft
SQL Server, ma per esigenze del servizio è stato necessario fare riferimento anche a
informazioni memorizzate in Active Directory, un servizio di directory Microsoft
per la gestione e organizzazione di informazioni su risorse condivise da una rete di
calcolatori.
Il server web utilizzato è un server Apache installato su una macchina Windows
2003 Server, il linguaggio di programmazione lato server per la creazione del
progetto è PHP (Hypertext Processor), mentre per le operazioni lato client viene
utilizzato Javascript. Per quanto riguarda il layout grafico e la formattazione delle
pagine di stampa sono stati utilizzati fogli di stile CSS (Cascading Style Sheets).
3.1. Apache (Web Server)
Un web server è un programma che si occupa di fornire, su richiesta di un browser,
una pagina web (spesso scritta in HTML). Le informazioni inviate dal web server
viaggiano in rete trasportate dal protocollo HTTP [Protocollo HTTP]. L’insieme di
web server presenti su Internet forma il WWW ossia il World Wide Web.
Apache [APACHE] è il nome dato alla piattaforma server Web freeware più diffusa
(ma anche al gruppo di lavoro open source che ha creato, sviluppato e aggiornato il
software server): è un sistema multi piattaforma, in grado di interagire con sistemi
operativi UNIX-Linux e Microsoft; attraverso questo software è possibile realizzare
funzioni di trasporto delle informazioni, di internetwork e di collegamento ed ha il
vantaggio di offrire anche funzioni di controllo per la sicurezza. Apache è diventato
il server web più popolare al mondo per le sue caratteristiche sofisticate, le
eccellenti performance, l’estensibilità, l’architettura modulare, la portabilità e la
21
sicurezza. Queste caratteristiche, in aggiunta al fatto che è gratuito, hanno fatto
ricadere la scelta su questo sistema.
Un’indagine condotta da Netcraft (figura 6), aggiornata a Settembre 2007, ha
riscontrato che più del 50% delle applicazioni Web su Internet stanno usando
Apache.
La prima versione, basata su server NCSA [NCSA], è stata sviluppata nel 1995.
Poiché era un insieme di patches sul server NCSA è stato chiamato un patchy
server, da cui il nome Apache Server.
Operativamente, è composto da un demone, in ambiente UNIX, o da un servizio, in
ambiente Microsoft, che sulla base delle impostazioni contenute nel file di
configurazione httpd.conf permette l’accesso a una o più applicazioni, gestendo
varie caratteristiche di sicurezza e potendo ospitare diverse estensioni per pagine
attive (o dinamiche), come PHP o Jakarta/Tomcat.
Nelle ultime versioni, grazie all’introduzione di “Moduli Multiprocesso”, è
possibile configurare Apache come un server basato su processi oppure come server
multi-thread.
Nel primo caso ogni richiesta viene servita generando un nuovo processo con
ambiente d’esecuzione e spazio di indirizzamento proprio (ambiente locale); nel
secondo caso una nuova richiesta di servizio genera un nuovo thread, cioè un flusso
d’esecuzione all’interno di un processo (ambiente globale). Il context switching tra
thread è più leggero, in quanto questi condividono lo stesso spazio di
indirizzamento: questo da un lato rende più semplice la comunicazione, ma
dall’altro genera problemi di sincronizzazione e interferenza nell’accesso allo
spazio di indirizzamento condiviso [Dispense del corso di Reti di Calcolatori].
Un’altra caratteristica è rappresentata dai “Moduli di protocollo” che permettono
agli sviluppatori di riutilizzare l’infrastruttura del server web per implementare
nuovi protocolli, come quelli che si occupano della posta (POP3) e del
trasferimento file (FTP).
22
Su un server web Apache possono essere facilmente installati moduli aggiuntivi di
terze parti attivandoli nel file di configurazione; questi permettono di ampliare le
funzionalità del web server.
Figura 6. Utilizzo dei server web da Dicembre 1995 ad oggi
3.2. Microsoft SQL Server (DBMS)
Microsoft SQL Server è un database relazionale funzionante su piattaforme
Windows, utilizzato per la gestione di basi di dati anche di grandi dimensioni,
rappresenta una soluzione commerciale per la gestione dei dati a livello end-to-end
[SQL Server]. Un database relazionale (RDBMS) implementa una struttura che
permette di archiviare informazioni su entità (astrazioni di oggetti logici utilizzati
dalle applicazioni che si interfacciano con esso), memorizzate in tabelle che
intrattengono relazioni tra loro. Le informazioni residenti su DBMS vengono
reperite attraverso interrogazioni a questi ultimi, effettuate utilizzando il linguaggio
SQL (Structured Query Language) [Linguaggio SQL], un linguaggio creato per
l’accesso a informazioni memorizzate nei database, basato sul modello EntitàRelazione.
Questo linguaggio permette aggiornamenti e interrogazioni elaborati a discapito
delle dimensioni del programma e della complessità dell’applicazione. SQL Server
23
utilizza una particolare estensione di questo linguaggio T-SQL (Transact Structured
Query Language), che implementa nuove funzionalità per il controllo del flusso
delle istruzioni e la manipolazione delle variabili [T-SQL]; questo ha permesso
l’ottimizzazione di query molto complesse, riducendo notevolmente il tempo di
accesso ai dati e l’utilizzo dei dati restituiti dall’interrogazione senza bisogno di
eccessive manipolazioni a livello di linguaggio di programmazione.
L’ingresso di Microsoft nel mondo dei database di fascia "enterprise" risale intorno
al 1989, quando cominciò la competizione con Oracle, IBM e Sybase che erano i
dominatori del mercato. La prima versione fu SQL Server per OS/2 ed era quasi
identica a Sybase SQL Server 4.0 su Unix. SQL Server 7.0 è stato il primo database
server basato su un'interfaccia grafica. L’attuale versione, Microsoft SQL Server
2005 (9.0), è stata rilasciata nel novembre 2005.
Sebbene non rivesta una posizione dominante tra i DBMS commerciali a causa di
qualche lacuna a livello di funzionalità offerte, compare sul mercato ad un prezzo
concorrenziale, risulta quindi un buon compromesso tra prezzo e qualità. Il mercato
dei DBMS open source e' dominato da MySql [MySQL] e PostGreSql
[PostGreSql]. Attualmente, i due DBMS citati non si pongono in concorrenza con i
DBMS proprietari, ma, analizzando i requisiti del servizio, una di queste due
soluzioni avrebbe sicuramente permesso di realizzare un’applicazione più
performante, mettendo a disposizione un ventaglio più ampio di funzionalità.
La scelta dell’utilizzo di MS SQL Server è dovuta principalmente alla preesistenza
di una base dati già consolidata e utilizzata da altre applicazioni.
3.3. Microsoft Active Directory
Active Directory è il sistema integrato e distribuito di directory service adottato dai
sistemi operativi Microsoft a partire da Windows 2000 Server [Active Directory]. In
Active Directory sono integrate tutte le applicazioni per la gestione dei servizi di
rete e dominio. Per servizio di directory si intende un sistema con il compito di
organizzare e memorizzare informazioni su reti di computer e su risorse condivise
disponibili tramite la rete. Il servizio di directory fornisce anche un controllo degli
accessi sull'utilizzo delle risorse condivise, in modo da favorire il lavoro
24
dell’amministratore di sistema. I servizi di directory forniscono uno strato di
astrazione tra le risorse e gli utenti.
Una directory è spesso erroneamente considerata un database. In realtà si tratta di
un tipo di database molto particolare, specializzato quasi esclusivamente in accessi
in lettura; la fase di scrittura è limitata agli amministratori di sistema o ai proprietari
delle singole informazioni. Per questo motivo le directory sono ottimizzate per la
lettura, mentre i tradizionali database relazionali devono supportare sia la lettura sia
la scrittura dei dati. Ne consegue che le directory non sono adatte per
immagazzinare informazioni aggiornate di frequente. La directory può invece
contenere informazioni su periferiche di rete (il suo indirizzo) oppure dati sugli
utenti relativi alle risorse della rete a cui possono aver accesso.
Un’altra importante differenza sta nel metodo di accesso alle informazioni. La
maggior parte dei database relazionali supporta un metodo d’accesso potente e
standardizzato che è SQL. Le directory invece, in particolare le directory LDAP
(Lightweight Directory Access Protocol), usano un protocollo di accesso
semplificato e ottimizzato che può essere usato in applicazioni snelle e
relativamente semplici [LDAP].
Visto che le directory non hanno l’intento di fornire lo stesso numero di funzioni di
un tradizionale database relazionale, possono essere ottimizzate per consentire a più
applicazioni di accedere ai dati in grandi sistemi distribuiti nel modo più rapido
possibile.
Active Directory è anche il nome utilizzato da Microsoft per riferirsi alla sua
implementazione della sicurezza in una rete distribuita di computer. Utilizza vari
protocolli e si comporta come una base di dati che memorizza in forma centralizzata
tutte le informazioni di un dominio di amministrazione, col vantaggio di mantenere
tutta questa informazione sincronizzata tra i vari server di autenticazione di accesso
alla rete.
Le informazioni che risiedono nel database dei servizi di directory hanno struttura
ad albero e sono memorizzate in uno “Schema” che prevede la definizione di classi
e oggetti con relativi attributi. Qui esistono le unità organizzative (OU), contenitori
25
con lo scopo di organizzare oggetti (account utente, account di gruppo, computer,
stampanti), raggruppandoli in una struttura gerarchica basandosi su singoli aspetti
della realtà dell’organizzazione in questione (ad esempio l’appartenenza ad un
ufficio di un’istituzione). Ogni utente può essere associato ad un’unica OU che ne
definisce la posizione nella struttura considerata. Le informazioni sulla OU di
appartenenza di un utente o oggetto sono definite nella struttura ad albero, a ogni
livello esiste un Relative distinguished name (RDN) che lo identifica. L’unione di
tutti i RDN, presi in successione dal nodo foglia fino alla radice, costituisce il
distinguished name (DN), una stringa che rappresenta univocamente una entry nella
directory. Gli utenti possono essere associati a diversi gruppi di permessi che
permettono di stabilire cosa possono fare e a quali risorse possono accedere,
elencati in attributi associati all’utente stesso.
3.4. XHTML
HTML (acronimo per Hyper Text Mark-Up Language) [HTML] è un linguaggio
usato per descrivere i documenti ipertestuali disponibili nel Web. Non è un
linguaggio di programmazione, ma un linguaggio di markup, ossia descrive il
contenuto, testuale e non, di una pagina web.
È stato sviluppato alla fine degli anni '80 da Tim Berners-Lee al CERN di Ginevra.
Verso il 1994 ha avuto una forte diffusione, in seguito ai primi utilizzi commerciali
del web.
HTML è un linguaggio di pubblico dominio la cui sintassi è stabilita dal World
Wide Web Consortium [W3C], e che è basato su un altro linguaggio avente scopi
più generici, l’SGML [SGML]. Durante gli anni l’HTML ha subito molte revisioni
e miglioramenti, che sono stati indicati secondo la classica numerazione usata per
descrivere le versioni dei software. Attualmente l’ultima versione disponibile è la
versione 4.01, resa pubblica il 24 dicembre 1999.
L’XHTML (acronimo di eXtensible HyperText Markup Language) è un linguaggio
di markup che associa alcune proprietà dell’XML [XML] con le caratteristiche
dell’HTML: un file XHTML è un pagina HTML scritta in conformità con lo
standard XML.
26
Il linguaggio prevede un uso più restrittivo dei tag HTML; solo la struttura della
pagina è scritta in XHTML, mentre il layout è imposto dai fogli di stile a cascata
(CSS, Cascading Style Sheets).
L’XHTML è nato ufficialmente il 26 gennaio 2000 come standard W3C, e può
essere definito tecnicamente una riformulazione dell’HTML 4.01 come
applicazione dell’XML 1.0, una sorta di transizione tra questi due linguaggi.
La necessità di un linguaggio dotato di una sintassi meglio definita rispetto a quella
dell’HTML cominciò ad essere avvertita quando si diffuse l'uso di inviare pagine
web ai nuovi dispositivi apparsi sul mercato, diversi dai tradizionali computer,
come ad esempio piccoli apparecchi portatili, dotati di risorse hardware e software
non sufficienti ad interpretare il linguaggio HTML. Va tenuto presente che più
generica è la sintassi di un linguaggio di programmazione, più difficile risulta
realizzare dispositivi in grado di interpretarlo correttamente. Una specifica
Document Type Definition (DTD) definisce l'insieme di regole mediante le quali un
dato documento può essere renderizzato (cioè rappresentato correttamente)
dall’XHTML [DTD].
La maggior parte dei browser attualmente più diffusi è già in grado di renderizzare
correttamente i documenti XHTML. Ma anche i browser più vecchi sono
solitamente in grado di interpretare i documenti XHTML, poiché questo linguaggio
è in buona parte un sottoinsieme dell’HTML. Lo stesso vale anche in senso inverso:
quasi tutti i browser compatibili con l’XHTML renderizzano correttamente i
documenti HTML. Secondo un’opinione diffusa, questo alto grado di compatibilità
sta rallentando il passaggio da HTML a XHTML. Per sfruttare appieno le
potenzialità dell’XHTML è necessario usarlo in abbinamento ai fogli di stile, in
modo da scrivere un codice per pagine web in cui la presentazione è separata dalla
struttura dei dati.
L’XHTML si distingue dall’HTML principalmente perché è più compatibile con le
specifiche dell’XML. La differenza più importante è che tutti i tag devono essere
ben strutturati, cioè obbedire ad una serie di regole che ne assicurino la coerenza
reciproca. Inoltre i tag devono essere sempre scritti in lettere minuscole,
27
convenzione in contrasto con l’abitudine invalsa a partire dalla versione 2.0 di
HTML, quando la maggior parte dei programmatori preferiva le maiuscole.
Nell’XHTML tutti gli attributi (compresi quelli numerici) devono essere scritti fra
virgolette, cosa facoltativa in SGML e HTML, in cui le virgolette possono essere
omesse se il contenuto è una stringa alfanumerica o comprende alcuni altri caratteri
speciali riservati. Tutti gli elementi del linguaggio devono inoltre essere terminati,
compresi quelli vuoti (ad esempio img e br). Per eseguire la terminazione in modo
implicito si può aggiungere una "/" di chiusura al tag di apertura (es: <img … /> e
<br />). Altri tipi di abbreviazione non sono invece permessi (es: <option
selected>).
La stragrande maggioranza di tutto il codice XHTML presente oggi sul web è
servito con un content type di “text/html” e non come “application/xhtml+xml”.
Questo è dovuto al fatto che non tutti i web browser, primo fra tutti Internet
Explorer, supportano il content type raccomandato per l’XHTML. Ovviamente, ciò
significa che i documenti saranno trattati come tag soup (documento HTML scritto
senza seguire le regole strutturali e semantiche dell’HTML), non come XML, non
sarà quindi possibile avere nessuno dei vantaggi che XHTML offre. I browser non
saranno in grado di interpretare gli altri formati XML come MathML e SVG inclusi
nel documento e non faranno la validazione automatica che i parser XML fanno.
Figura 7. DTD utilizzato nel progetto “Inventario S.S.I.”
3.5. CSS
I fogli di stile a cascata (dall’inglese CSS Cascading Style Sheets), detti
semplicemente fogli di stile [CSS], sono una tecnica che permette di fissare gli stili
(per es. tipo di carattere, colori e spaziature) da applicare ai documenti HTML e
XHTML. Le regole per comporre i fogli di stile sono contenute in un insieme di
direttive (Recommendations) emanate a partire dal 1996 dal W3C.
28
L’introduzione dei fogli di stile si è resa necessaria per separare i contenuti dalla
formattazione e permettere una programmazione più chiara e facile da utilizzare,
sia per gli autori delle pagine HTML che per gli utenti.
Il linguaggio HTML (e la sua evoluzione XHTML) ha come scopo quello di gestire
i contenuti, specificandone la struttura attraverso tag diversi, non la loro
formattazione ovvero l’aspetto con cui i contenuti sono mostrati all’utente.
Per permettere agli autori di definire l’aspetto delle loro pagine prima dell’avvento
dei CSS, Netscape Navigator ed Internet Explorer, i due browser che si disputavano
gli utenti nella nota guerra dei browser, presentarono tag proprietari, ovvero non
aderenti agli standard e non compatibili con i browser concorrenti. Un esempio di
questi tag è <font>.
Questi tag proprietari di formattazione erano l’unico modo per gli autori di definire
la formattazione e così il loro uso è diventato massiccio. Tuttavia questi tag
presentano tre problemi:
1. Il primo problema è costituito dalla lunghezza di questi tag. Se confrontata con
una pagina che adotta il linguaggio CSS, una pagina che non lo adotta è in
genere più pesante (in termini di bit) in un rapporto che spesso raggiunge il
200%. Inoltre le istruzioni CSS possono essere raccolte in un file esterno che
rimane memorizzato nella cache del browser, riducendo ulteriormente la
quantità di dati che i server devono trasmettere.
2. Il secondo problema risiede nella mancanza di logica del codice (X)HTML.
Un codice non aderente agli standard, ridondante e confuso, comporta infatti
molto lavoro aggiuntivo per i browser, che devono cercare di correggere ed
interpretare (quando possibile) direttive arbitrarie.
3. Il terzo problema comincia a diventare sempre più rilevante ed è la mancanza
di compatibilità con i nuovi computer palmari e gli smartphone. Queste pagine
infatti sono progettate per schermi con risoluzione minima 800x600 pixel. I
palmari, che hanno una risoluzione inferiore ed una forma dello schermo ben
diversa dal rapporto 4:3 dei monitor per computer, si trovano quindi
29
impossibilitati a visualizzare correttamente la pagina e l’utente dovrà tentare di
"decodificarla", operazione spesso molto scomoda.
Si tende ad evidenziare anche un’ulteriore questione, nelle pagine web non
standard, ovvero l’uso del tag <table> (le tabelle) per realizzare l’impaginazione
delle pagine web. Questo viene considerato dai puristi come inaccettabile in quanto
le tabelle sono pensate per impaginare dati tabulari e non layout web, inoltre
un’altro svantaggio serio di questo sistema è l’incredibile peso delle pagine, come
già indicato al problema 1.
Per tentare di risolvere questa situazione, nel 1996 il W3C emanò le specifiche CSS
1. I CSS 1 che erano un interessante sistema per separare contenuto da
formattazione. La base di questo linguaggio, infatti, consisteva nel fatto che il
contenuto sarebbe stato sempre definito dal codice (X)HTML, mentre la
formattazione si sarebbe trasferita su un codice completamente separato, il CSS
appunto. I richiami tra i due codici venivano effettuati tramite due particolari
attributi: class e id. Queste specifiche:
1. erano un’efficace soluzione al primo problema (escludendo la questione del
tag <table>), perché riducevano notevolmente le dimensioni della pagine.
2. risolvevano il secondo in modo parziale, perché consentivano al codice
(X)HTML di ritornare in gran parte semplice ed essenziale, ma presentavano
qualche mancanza che costringeva a ricorrere ai tag HTML.
3. non prendevano però in considerazione il terzo, dato che nel 1996 i PDA (i
palmari) erano scarsamente diffusi.
I CSS 1 sviluppavano un’idea semplice ma efficace, ma nonostante le loro grandi
potenzialità non ebbero successo a causa della mancanza di browser in grado di
supportarli.
Per includere nuove funzionalità e rendere i CSS un linguaggio ben supportato, nel
1998 il W3C emanò le specifiche CSS 2 e nel 2004 le specifiche CSS 2.1. I CSS 2
sono la naturale evoluzione dei CSS 1 ed offrono potenti soluzioni per risolvere
soprattutto il problema tre, con la possibilità di creare fogli di stile separati per i
dispositivi portatili. Anche il problema due è ormai pienamente risolvibile,
30
scrivendo una pagina (X)HTML esclusivamente indirizzata alla struttura e ai
contenuti e manovrandola poi esclusivamente con i CSS per impaginarla. Con la
comparsa di Internet Explorer 5, di Firefox e di Opera 7, i CSS 2 hanno potuto
avvalersi di browser in grado di interpretarli e sono quindi entrati a far parte del
codice di molti siti web.
Le specifiche CSS 3 non sono state ancora rilasciate, sebbene il W3C pubblichi
costantemente informazioni sulle novità in fase di sviluppo. I CSS 3 dovrebbero
presentare soluzioni per la correzione di alcuni bug di interpretazione di Internet
Explorer, migliorie nella gestione degli sfondi e una soluzione per realizzare i bordi
arrotondati la cui realizzazione affligge i web designer da tempo.
Il supporto completo e corretto delle specifiche CSS non è offerto da nessun
browser attuale. Tuttavia esistono browser che si avvicinano molto a questo
risultato ed altri che invece ne sono molto lontani.
Una utilissima funzione dei CSS è la possibilità di essere applicati solo sui
dispositivi (media) specificati dall’autore. La sintassi (X)HTML da utilizzare è la
mostrata in figura 8.
Il codice in figura 8 permette di associare il foglio di stile solo (in teoria) ai browser
standard per computer desktop e portatili. I valori dell’attributo media più
importanti sono i seguenti:
• screen (desktop e laptop);
• handheld (PDA e smartphone);
• print (stampanti);
• projection (proiezioni);
• speech o aural (sintetizzatori vocali);
• tty (telescriventi);
• all (tutti i dispositivi).
Sebbene il numero dei dispositivi gestibili tramite CSS sia notevole, soltanto i primi
tre sono supportati in maniera sufficiente. Il media screen è quello standard cui si fa
riferimento. Il media handheld è specifico per i palmari, ma alcuni browser per
palmari tentano, spesso con scarso successo, di interpretare anche i fogli marcati
31
con screen, per cui si preferisce in genere marcare con handheld sia il foglio per lo
schermo che quello per il palmare e poi usare quest’ultimo per sovrascrivere le
istruzioni del primo. Il media print codifica la pagina per la stampa, è supportato
discretamente.
Figura 8. Esempio d’inclusione file Css e impostazione media
3.6. PHP (scripting sever-side)
PHP [PHP] è un linguaggio di scripting interpretato, con licenza open source,
originariamente concepito per la realizzazione di pagine web dinamiche.
Attualmente è utilizzato principalmente per sviluppare applicazioni web lato server,
ma può essere usato anche per scrivere script a linea di comando o applicazioni
stand-alone con interfaccia grafica.
PHP è un linguaggio interpretato: questo significa che l’interprete analizza ed
esegue istruzione per istruzione; un compilatore, al contrario, non esegue
direttamente il programma che riceve in ingresso, ma lo traduce in linguaggio
macchina, memorizzando su file il codice oggetto pronto per l’esecuzione diretta da
parte del processore.
PHP riprende per molti versi la sintassi del C, come peraltro fanno molti linguaggi
moderni, e del Perl. È un linguaggio a tipizzazione debole e dalla versione 5
migliora il supporto al paradigma di programmazione ad oggetti; è un linguaggio
"HTML-embedded": questa caratteristica si riferisce al fatto che il codice PHP è
immerso nei tag HTML. Il server web riconosce le pagine dinamiche da quelle
statiche basandosi sull’estensione (php o php3 invece che html o htm); nel caso stia
processando una pagina dinamica, la passa all’interprete del PHP che riconosce ed
interpreta il codice presente tra appositi tag (<?php ?>). PHP è comunque un
linguaggio lato server: ciò significa che tutte le elaborazioni avvengono sul server,
che produce dinamicamente la pagina richiesta dal client; quest’ultimo però non
32
può visualizzare tali funzionalità, in quanto il risultato speditogli è solo il codice
HTML corrispondente alle elaborazioni effettuate.
Il PHP permette il passaggio di parametri da una pagina all'altra attraverso tre array
di variabili: $_GET, $_POST e $_SESSION. Il primo tipo di parametro viene
passato tramite la stringa che compare nella barra dell’indirizzo del browser; il
secondo viene passato in background, mentre il terzo rimane persistente durante la
sessione attiva sul server.
PHP è fondamentalmente un linguaggio di alto livello, caratteristica questa
rafforzata dalla esistenza delle sue moltissime API (Application Programming
Interface), che permettono allo sviluppatore di astrarre dall’hardware sottostante; è
in grado di interfacciarsi a innumerevoli database tra cui MySQL, PostgreSQL,
Oracle, Firebird, IBM DB2, Microsoft SQL Server, solo per citarne alcuni, e
supporta numerose tecnologie, come XML, SOAP, IMAP, FTP, CORBA. Si integra
anche con altri linguaggi/piattaforme quali Java e .NET e si può dire che esista un
wrapper per ogni libreria esistente, come OpenSSL ed altro.
Esiste un’enorme quantità di script e librerie in PHP, disponibili liberamente su
Internet, un archivio chiamato PEAR (PHP Extensions and Applications
Repository) che mette a disposizione un framework di librerie riusabili per lo
sviluppo di applicazioni PHP e di PECL (PHP Extensions Community Library) che
raccoglie tutte le estensioni conosciute scritte in C.
Fondamentale è il file di configurazione php.ini, letto, nella versione server
modulare, all’avvio dell’interprete del linguaggio: fornisce le impostazioni dei vari
moduli con cui l’interprete è stato compilato.
33
Figura 9. Utilizzo di PHP ad Aprile 2007
3.7. Javascript (scripting client-side)
Javascript [Javascript] è un linguaggio di scripting orientato agli oggetti,
comunemente utilizzato nelle applicazioni web; a differenza di PHP, in cui le
istruzioni vengono interpretate dal server, l’interprete di questo linguaggio è
integrato nel client. È un linguaggio basato sugli eventi che, nel caso del web,
possono essere il click di un bottone o la selezione di una checkbox.
Prima dell’introduzione dei linguaggi lato client, lo scatenarsi di tali eventi
prevedeva sempre la comunicazione con il server, con uno spreco di tempo che si
rendeva necessario per instaurare un dialogo tra le due entità in gioco. Non sempre
tale comunicazione risultava strettamente necessaria, da qui la necessità di una
tecnologia che permettesse di migliorare l’interazione del client con la pagina web.
Il principale utilizzo di Javascript è proprio quello di ottimizzare l’interazione del
client con le pagine web tramite la scrittura di piccole funzioni integrate nelle
pagine HTML, che interagiscono con il browser per compiere determinate azioni
non possibili con il solo HTML statico.
Javascript è un linguaggio di programmazione orientato a oggetti con una sintassi
vagamente basata sul C. Come il C, esso ha il concetto di parole chiave riservate,
che rendono quasi impossibile espandere il linguaggio (essendo eseguito
direttamente dal sorgente). Ogni cosa in javascript è o un valore primitivo o un
34
oggetto. Gli oggetti sono entità dotate di unicità (sono uguali solo a se stessi) e
associano nomi di proprietà a valori. Le variabili sono in genere tipizzate
dinamicamente, definite semplicemente assegnando loro un valore oppure usando il
comando var. Le variabili dichiarate fuori da qualunque funzione sono in visibilità
“globale”, accessibili dall’intera pagina web; le variabili dichiarate dentro una
funzione sono locali per quella funzione. Per passare variabili da una pagina
all’altra, uno sviluppatore può impostare un cookie o usare un frame nascosto o una
finestra in background per memorizzarli.
Un interprete javascript si basa su un programma ospite in cui è integrato: ci sono
molti programmi ospiti di questo tipo, di cui quelli relativi al Web sono gli esempi
più noti; javascript, se integrato in un browser Web, si collega tramite interfacce
chiamate DOM (Document Object Model) [DOM] alle applicazioni, specialmente
al lato server (web server) e al lato client (browser) delle applicazioni internet.
DOM è lo standard ufficiale del W3C per la rappresentazione di documenti
strutturati in maniera da essere neutrali sia per la lingua che per la piattaforma;
inoltre è la base per una vasta gamma di interfacce di programmazione delle
applicazioni. Inizialmente supportato dai browser per modificare gli elementi in un
documento HTML, è divenuto un modo per accedere al contenuto e aggiornarlo
dinamicamente, struttura e stile dei documenti. A causa delle incompatibilità
nell’esecuzione di DOM fra i vari browser, il W3C ha fornito delle specifiche
standard. DOM non mette limitazioni sulla struttura dei dati del documento e,
utilizzando tali interfacce, un documento ben formato può essere visto come un
albero (figura 10).
In un documento HTML è possibile inserire codice javascript, utilizzando il tag
<SCRIPT>, e all’interno è possibile definirvi funzioni che vengono associate ad
eventi scatenati dall’utente: questo codice viene eseguito senza instaurare una
comunicazione con il server.
Negli ultimi tempi javascript è molto utilizzato nell’ambito della tecnologia Ajax
(Asynchronous Javascript and XML), una tecnica di sviluppo web per creare
applicazioni web interattive. L’intento di tale tecnica è quello di ottenere pagine
35
web che rispondano in maniera più rapida, grazie allo scambio in background di
piccoli pacchetti di dati con il server, così che l’intera pagina web non debba essere
ricaricata ogni volta che l’utente effettua una modifica. Questa tecnica riesce,
quindi, a migliorare l’interattività, la velocità e l’usabilità di una pagina web.
Figura 10. Javascript Document Object Model (DOM)
36
4. Realizzazione della nuova applicazione
In questo capitolo si tratterà in maniera più dettagliata delle scelte e dei dettagli
implementativi che hanno portato alla realizzazione del servizio “Inventario S.S.I.”.
Partendo dai dettagli sulla struttura del database e delle relative modifiche in corso
d’opera, verrà analizzato in seguito il sistema di autenticazione, passate in rassegna
le funzionalità più significative del servizio, descrivendo infine gli accorgimenti
utilizzati per l’accessibilità all’applicazione e la stampa.
4.1. Struttura dei dati
Il progetto “Inventario S.S.I.” ha previsto la modifica di alcune tabelle già esistenti
e la creazione di nuove. Una di queste è la tabella D_campo, che identifica le entità
“attributi” associabili a una “categoria d’oggetto”, è quindi in relazione con la
tabella D_tipo_elemento secondo un rapporto molti a molti (figura 2), ciò significa
che fra le due tabelle in esame ne viene interposta un’altra che contiene le coppie di
chiavi dei record connessi.
In fase di realizzazione del servizio, ci si è però accorti che questa soluzione non era
la più performante, ma che richiedeva un numero elevato di accessi al database per
una lettura o una modifica. Si è quindi scelto di modificare ulteriormente la tabella
D_tipo_elemento, aggiungendo un campo “campi”, di tipo stringa, nel quale
inserire una serializzazione dei riferimenti ai record della tabella D_campo,
eliminando così la relazione tra le due tabelle fissata in fase di progetto.
La tabella D_campo possiede, inoltre, una duplice funzione: i
propri record
definiscono i campi della tabella T_elementi_xy, ciò significa che l’inserimento di
un nuovo record nella tabella D_campo comporta l’aggiunta di una colonna nella
tabella T_elementi_xy, rendendola quindi, a differenza delle altre tabelle, a struttura
dinamica.
Durante la fase d’implementazione di questo meccanismo, sono emersi alcuni
problemi dovuti alla modalità con cui Microsoft SQL Server crea un attributo
definito obbligatorio o non nullo.
37
SQL Server registra questi attributi e i relativi valori predefiniti in una tabella di
sistema, rendendo complessa la procedura di modifica o eliminazione dell’attributo
stesso, si è quindi optato per una gestione server-side (attraverso php)
dell’obbligatorietà dei campi. Grazie all’adozione di questa soluzione è stato inoltre
possibile, definire l’obbligatorietà di un “attributo” per ogni “categoria d’oggetto”
a cui è associato.
La figura 11 mostra la struttura di base del database, non essendo possibile definire
una struttura definitiva, vista la dinamicità della tabella T_elementi_xy.
Come si può notare, per ogni tabella è stata definito un campo chiave grazie al quale
è possibile identificare univocamente i record in essa contenuti, relazionandoli ove
necessario con record di altre tabelle. Per uniformare le tabelle si è scelto di
utilizzare una stringa formata da “id_” seguito dal nome della tabella come nome
dell’attributo definito come chiave primaria.
Figura 11. Struttura del database
38
Tabella T_elementi_xy
Rappresentando l’entità “oggetto” è la tabella principale dell’applicazione, ogni
record ivi contenuto rappresenta un oggetto dell’inventario.
La modifica principale e più importante apportata alla struttura della tabella è stata
la conversione da statica a dinamica, ciò è stato possibile suddividendo gli attributi
in due tipologie: fissi e aggiuntivi.
All’interno degli attributi fissi, possiamo eseguire un’ulteriore distinzione fra
attributi preesistenti, e necessari ad ArcReader per la corretta visualizzazione
dell’oggetto nelle mappe, e attributi aggiunti nello sviluppo dell’applicazione.
Tra gli attributi fissi possiamo identificare quelli necessari ad ArcReader:
• l’identificativo del record (id_elem);
•
l’identificativo della categoria d’oggetto (id_tipo_el);
• un’etichetta progressiva assegnata ad ogni oggetto per facilitarne
l’identificazione (label);
•
l’identificativo della stanza in cui l’oggetto è dislocato (id_stanza);
• due coordinate cartesiane necessarie per il posizionamento nelle mappe
(POINT_X e POINT_Y).
Un attributo aggiunto durante la progettazione del servizio e di importanza
fondamentale è stato, che identifica se l’oggetto è ancora in uso o se è stato
dismesso.
Nel caso un oggetto venga dismesso, vengono annotate la data di dimissione
(data_dism), il motivo (motivo_dism) e un’eventuale nota (note_dism).
Figura 12. Procedura per l’aggiunta dinamica di un campo
39
L’attributo id_servizio, chiave importata dalla tabella T_servizi, è stato mantenuto
fra gli attributi fissi nonostante la sua presenza non sia necessaria per
l’applicazione, per non precludere ulteriori sviluppi dell’applicativo.
Tabella D_tipo_elemento
Questa tabella rappresenta l’entità “categoria d’oggetto”, la sua struttura originale
prevedeva soltanto l’identificativo univoco del record (id_tipo_el) e la descrizione
della categoria (de_tipo_el).
Lo sviluppo della nuova applicazione ha previsto l’aggiunta di cinque ulteriori
attributi:
• campi: stringa, serializzazione degli identificativi degli attributi associati alla
categoria;
• attiva: booleano, identifica lo stato della categoria, attiva o disattiva;
• icona: stringa, percorso dell’icona della categoria;
• prefisso_label: stringa, parte iniziale dell’etichetta che identifica un oggetto;
• count_label: intero, contatore della parte finale dell’etichetta che identifica
un oggetto.
I campi prefisso_label e count_label permettono la numerazione progressiva degli
oggetti appartenenti a una stessa categoria. Ogni inserimento di un oggetto
nell’archivio, il count_label della categoria alla quale l’oggetto è associato viene
incrementato di uno, permettendo anche di tenere il conteggio d’oggetti associati a
quella categoria già presenti in archivio.
Tabella D_campo
Questa tabella rappresenta l’entità “attributi” associabili a una “categoria
d’oggetto”, ma soprattutto ogni record ivi contenuto determina un campo
aggiuntivo della tabella T_elementi_xy.
Ogni record, oltre ad avere un identificativo numerico univoco (id_campo), è
include il nome del campo creato sulla tabella T_elementi_xy (nome_campo), una
descrizione del campo creato (de_campo), il tipo di campo (tipo_campo), la
lunghezza massima del contenuto (lunghezza_campo), il formato del contenuto del
40
campo (tipo_maschera), il testo predefinito (predefinito) se il campo è obbligatorio
(obbligatorio) e infine un ordine di visualizzazione (ordine) utilizzato per ordinare
gli attributi nella scheda di dettaglio di un singolo oggetto.
Tabelle T_stanze, T_piani, T_edifici
Queste tabelle fanno parte delle tabelle preesistenti nella base dati e necessarie per
la corretta visualizzazione delle mappe da parte di ArcReader.
Nessuna delle tre tabelle è stata modificata, presentano quindi la struttura originale
composta, per quanto riguarda la tabella T_stanze da un identificativo numerico
univoco (id_stanze), una descrizione della stanza (de_stanza) e la chiave importata
dell’identificativo del piano (id_piano).
La struttura della tabella T_piani, oltre all’identificativo del piano (id_piano),
comprende una descrizione del piano (de_piano), l’elevazione (elevazione) e la
chiave importata dell’identificativo dell’edificio (id_edificio).
Infine la tabella T_edifici include l’identificativo univoco (id_edificio), una
descrizione dell’edificio (de_edificio) e il tipo di collegamento (collegamento), di
cui dispone l’edificio stesso (es. DataWAN, LAN, Wireless).
Tabella D_privilegi
La tabella D_privilegi definisce i permessi specifici per i singoli utenti che
accedono all’applicazione. Questa contiene l’identificativo univoco dell’utente
(id_privilegi), l’username dell’utente (nome_user), il timestamp relativo al suo
ultimo accesso (last_access) e lo stato dell’utente (stato), che può essere
attivo/disattivo.
Nella tabella non esiste un campo contenente la password dell’utente, in quanto
l’autenticazione è demandata al web server il quale si avvale di Active Directory per
il controllo username/password. Esiste però un campo control_key, nel quale risiede
l’hash (tramite funzione md5) della coppia username-identificativo dell’utente, con
l’interposizione di una stringa. Questo campo è stato aggiunto per effettuare un
controllo più rigido nelle modifiche dei permessi, evitando che utenti in possesso
del solo username possano assegnarsi permessi o modificarne altri.
41
Il campo principale di questa tabella è privilegi, che contiene il livello
d’autorizzazione di cui l’utente dispone.
Tabella T_accessi
Questa tabella permette di tenere traccia degli accessi all’applicazione, registrando
l’username (nome_user) dell’utente, il suo indirizzo IP, il timestamp relativo
all’acceso (data) e l’esito del tentativo d’accesso.
L’esito essendo di tipo booleano può assumere soltanto due valori: positivo o
negativo. Quest’ultimo si può verificare soltanto nel caso in cui l’applicazione sia in
modalità “Accesso Limitato”.
In caso contrario l’esito sarà sempre positivo, in quanto essendo l’autenticazione
gestita dal web server, esso bloccherebbe tutti i tentativi d’accesso dove username o
password risultassero errati, ancor prima che l’applicazione possa interagire col
database.
Anche la tabella T_accessi utilizza un identificativo numerico per identificare
univocamente gli accessi, tramite il campo id_accessi.
Tabella D_destinazioni_uso
Questa tabella rappresenta le possibili destinazioni d’uso di una stanza (es. ufficio,
corridoio, ecc.).
I record in essa contenuti sono utilizzati in associazione con la lista delle unità
organizzative (es. ragioneria, anagrafe) per formare la descrizione delle stanze degli
edifici comunali.
La struttura della tabella è composta da un identificativo numerico (id_destinazione)
e dalla stringa che ne identifica l’uso (de_destinazione).
Tabella T_BlackList
La blacklist rappresenta la lista degli uffici che bisogna escludere dall’elenco di
quelli a cui è possibile assegnare diritti d’accesso ai dipendenti in essi contenuti.
Nei gruppi di permessi presenti in Active Directory, infatti, solo una parte è
realmente associabile ad entità fisiche della struttura comunale o ad enti interessati
42
al servizio. La tabella contiene un identificativo numerico (id_black) e il nome del
gruppo (de_black).
Tabella T_BlackList_OU
La struttura di questa tabella rispecchia quella della tabella T_BlackList, dalla quale
si differenzia per il contenuto.
La blacklist_OU rappresenta la lista delle unità organizzative che bisogna escludere
dall’elenco utilizzato per fornire una descrizione alle stanze. Come per gli uffici,
anche le unità organizzative presenti in Active Directory non sono associabili a
gruppi della struttura comunale.
4.2. Sistema d’autenticazione e assegnazione diritti d’accesso
L’accesso all’applicazione è subordinato a un’autenticazione, attraverso alla quale è
possibile assegnare a un utente i propri diritti d’accesso in base alla sua username.
Il meccanismo d’autenticazione essendo gestito dal web server è del tutto
trasparente all’applicazione e viene utilizzato anche per altri servizi disponibili
nell’intranet comunale.
Apache è stato configurato tramite il file httpd.conf, nel quale è stata aggiunta la
riga di configurazione:
php_value
auto_prepend_file “/autenticazione/ad_auth.php”
associata alla directory in cui risiede l’applicazione “Inventario S.S.I.”. Questa
stringa viene interpretata da Apache che passa l’impostazione auto_prepend_file al
modulo php (php4_module), il quale prima di fornire la pagina web richiesta
aggiunge il file specificato come parametro, in questo caso ad_auth.php. Questo
script implementa un meccanismo d’autenticazione basato sull’invio di Header
HTTP, ciò consente uno scambio della coppia username-password in un canale non
cifrato, infatti username e password vengono inclusi nell’header separati dal
carattere “:” e codificati in Base64.
Ricevuti i dati d’autenticazione dell’utente lo script procede con una verifica di
validità degli stessi interagendo con il servizio di directory dove risiedono i dati
degli utenti abilitati ad accedere all’intranet comunale. Quest’iterazione fra web
43
server e Active Directory è possibile grazie all’installazione del modulo mod_ldap
sul web server.
Se il confronto dei dati fornisce esito positivo, il web server crea una sessione
contenente i dati dell’utente, implementando cosi un sistema Single Sign On (SSO),
che permette all’utente di accedere ai servizi dell’intranet senza doversi autenticarsi
nuovamente. Questo sistema SSO non è nativo del web server, ma è stato reso
disponibile grazie all’installazione del modulo mod_auth_sspi.
Essendo questo metodo completamente trasparente all’applicazione, per fornire la
possibilità a quest’ultimi di assegnare dei diritti d’accesso differenti ai singoli
utenti, all’atto della creazione della sessione, viene creata una variabile globale
$_REMOTE_USER
che
contiene
l’username
dell’utente
e
il
dominio
d’appartenenza.
Come per l’autenticazione sull’intranet in cui è stato implementato un sistema
Single Sign On, si è cercato di ricrearne uno anche a livello dell’applicazione
contenete in questo caso oltre all’username dell’utente, l’ufficio d’appartenenza ma
soprattutto il livello d’autorizzazione.
La procedura che permette l’assegnazione dei diritti d’accesso, eseguita quindi,
soltanto all’accesso dell’applicazione, consiste nella verifica della presenza
dell’username dell’utente nella tabella D_privilegi. Se il riscontro fornisce esito
positivo vengono assegnati all’utente i diritti specifici a lui conferiti e contenuti
sempre nella tabella D_privilegi, in caso contrario se l’applicazione è in modalità
“Accesso Limitato” all’utente viene escluso il diritto d’accesso, altrimenti vengono
assegnati i diritti di “lettore”.
Contestualmente all’assegnazione dei diritti d’accesso, qualsiasi essi siano, viene
registrato nella tabella T_accessi il tentativo d’accesso annotando l’username
dell’utente, l’esito del tentativo d’accesso, l’orario e l’indirizzo IP della macchina
dell’utente.
44
4.3. Architettura file system
Nonostante la fruizione del servizio sia offerta da un’interfaccia web indipendente e
in certi casi disgiunta dalla reale organizzazione dei file sul server, quest’ultimo
aspetto è stato tenuto in considerazione per conferire all’applicazione una
modularità che ne consenta, in futuro, una facile estensione.
Si è deciso, vista l’esistenza dei due livelli d’autorizzazione, di separare la parte
d’amministrazione da quella del lettore, includendo tutti i relativi file in una
sottodirectory “admin” della principale.
Si sono venute così a formare due sezioni rappresentanti i livelli d’accesso
principali, fornendo la possibilità di mantenere separate le funzionalità specifiche
per ogni livello, evitando così che il lettore
possa accedere a mansioni
dell’amministratore.
Oltre a questa separazione, si è suddiviso la directory principale in sottodirectory in
base alla tipologia dei file (immagini, css, javascript), raggruppando, ad esempio,
tutte le immagini in un’unica cartella, rendendone più intuitiva la navigazione.
Figura 13. Schema del File System
Come per la directory principale, anche alla cartella “admin” è stata applicata una
suddivisione in base alla tipologia dei file, con un’eccezione: le immagini utilizzate
nelle pagine d’amministrazione sono contenute nell’apposita cartella nella directory
madre.
45
Infine, si è scelto di creare una directory “include”, che contenesse tutte le librerie
comuni a entrambi i livelli d’autorizzazione, come l’accesso al database, la
compressione gZip e il file di configurazione generale.
4.4. Struttura dell’applicazione
La struttura dell’applicazione è stato concepita per favorirne una modularità che ne
permettesse una semplice espandibilità o modifica. Si è cercato per quanto possibile
di astrarre dalle tecnologie utilizzate, soprattutto per quanto riguarda il database,
creando una classe che fornisse tutti i metodi necessari per interagire col database
indifferentemente dal tipo di DBMS utilizzato.
Per quanto riguarda la connessione e la lettura di dati dal servizio di directory ci si è
affidati anche in questo caso ad una classe che fornisse un’interfaccia indipendente
dal tipo di directory utilizzato.
Nonostante PHP sia un linguaggio prettamente procedurale, offre nella versione
installata sui server del comune di Cento alcuni costrutti per la programmazione a
oggetti, si è quindi scelto di sviluppare le interfacce al database e al servizio di
directory secondo questo modello.
Sono state create poi delle librerie per le funzioni comuni, per le stringhe e per le
espressioni regolari (RegExp) che come per il file che rappresentava la classe del
database sfruttano i comandi include() o require(), a seconda dei casi, per essere
inclusi all’interno di ogni pagina web.
Sfruttando questo meccanismo di inclusione offerto da php sono stati creati dei file
contenenti parti di codice simile o in certi casi identico, evitando la riscrittura dello
stesso e accelerando il processo di sviluppo dell’applicativo. Un esempio è la
procedura per l’aggiunta di un “attributo”, che può essere eseguito sia nella pagina
che consente la gestione degli attributi, sia nella scheda di personalizzazione di una
singola categoria d’oggetto.
A livello di singola pagina si è cercato di favorire la modularità mantenendo
separato il contenuto dalla presentazione e dall’interazione, cioè dal codice
javascript, cercando di non inserirlo direttamente nel codice (X)HTML ma in
appositi file contraddistinti dall’estensione .js.
46
Nella sezione del “lettore” le funzioni javascript sono state raccolte in tre file,
mentre per una maggiore flessibilità e modularità, nella parte d’amministrazione è
stato creato un singolo file javascript per ogni modulo (es. gestione categorie
d’oggetto).
L’associazione delle funzioni javascript agli eventi scatenabili nelle singole pagine,
avviene al caricamento del DOM, sfruttando l’evento DOMContentLoaded con i
browser Firefox e Opera, e utilizzando l’hack dell’attributo defer con Internet
Explorer, permettendo di non inserire codice javascript nel codice (X)HTML.
4.5. Manuale d’uso
“Inventario S.S.I.” è un applicazione Web per la gestione di un inventario, dove gli
oggetti sono catalogati secondo la tipologia dell’oggetto stesso. Per permettere ciò,
il servizio offre anche gli strumenti necessari per definire e gestire nuove categorie
d’oggetto e gli attributi che caratterizzano queste categorie.
L’applicazione prevede differenti livelli di permessi, in base ai quali concedere
l’accesso alle funzionalità offerte dal servizio. Vi sono quindi funzionalità
disponibili per chiunque (es. Ricerca) e altre limitate a un livello di permessi (es.
Gestione categorie).
L’utente potrà quindi disporre di tutte le funzionalità presenti nel menù principale,
che sarà quindi differente per i vari livelli d’autorizzazione e verrà gestito in
maniera trasparente dall’applicazione.
La pagina principale dell’applicativo (figura 14) riporta la lista delle categorie
d’oggetto attraverso un’icona impostabile in Gestione categorie, il nome della
categoria e il numero d’oggetti associati alla categoria e già presenti in archivio.
Cliccando su uno degli elementi dell’elenco si potrà visualizzare la lista degli
oggetti associati alla categoria selezionata, dalla quale sarà poi possibile accedere
alle schede di dettaglio dei singoli oggetti.
Si vedranno ora in dettaglio alcune delle funzionalità offerte dall’applicazione
“Inventario S.S.I.”.
47
Figura 14. Home Page del servizio
4.5.1. Ricerca oggetti
Lo strumento di ricerca offerto dal servizio consente di effettuare una ricerca
generica oppure una avanzata in base ad alcuni parametri quali categoria, locazione
e attributo/caratteristica.
Selezionando la voce ricerca dal menù laterale verrà caricato inizialmente lo
strumento di ricerca generica con un contestuale visualizzazione di un sottomenù
che riporta i collegamenti per le ricerche mirate.
Lo strumento di ricerca generica mostra tutti gli oggetti che in un qualunque
attributo contengano la chiave di ricerca inserita dall’utente.
Per eseguire una ricerca in una singola categoria d’oggetto, si può utilizzare lo
strumento ricerca per categoria, nel quale oltre l’unico parametro obbligatorio è
appunto la categoria dell’oggetto, in quanto la chiave di ricerca può anche essere
omessa. In questo caso i risultati della ricerca coincideranno con la visualizzazione
degli oggetti appartenenti alla categoria.
48
La scelta della categoria dell’oggetto consente inoltre di limitare ulteriormente
l’insieme di ricerca, selezionando uno più attributi associati alla categoria d’oggetto.
Trascurando la scelta di quest’ultimi, la ricerca verrà eseguita su tutti gli attributi.
Nel caso si volesse limitare l’insieme degli oggetti su cui eseguire la ricerca
secondo un ambito geografico, è disponibile lo strumento ricerca per locazione, nel
quale si può affinare la ricerca per stadi successivi, scegliendo l’edificio, il piano e
infine la stanza. Per poter eseguire questa ricerca è necessario selezionare l’edificio,
mentre il piano, la stanza e la chiave di ricerca sono parametri opzionali.
Lo strumento ricerca avanzata (figura 15) permette di eseguire una ricerca mirata
offrendo la possibilità di limitare l’insieme di ricerca in base alla categoria e alla
locazione, dando la possibilità di omettere la chiave di ricerca.
Infine lo strumento ricerca per attributo, consente di ricercare una chiave di ricerca
all’interno di uno o più attributi. L’utilizzo di questo strumento è subordinato
all’inserimento di una chiave di ricerca e alla scelta di uno o più attributi su cui
effettuare la ricerca.
Scelto lo strumento di ricerca più adatto alle proprie esigenze, inserite le
informazioni necessarie per poter eseguire la ricerca, il motore di ricerca mostrerà
una lista d’oggetti attinenti ai dati inseriti (figura 16), separandoli in più pagine per
non rendere la lettura della lista troppo difficoltosa. Per facilitare l’identificazione di
un oggetto, scorrendo col mouse sull’elenco dei risultati, viene mostrato un piccolo
riassunto delle caratteristiche dell’oggetto.
Figura 15. Form ricerca avanzata
49
Figura 16. Risultati di una ricerca generica, con chiave di ricerca “Sony”
4.5.2. Inserimento di un oggetto
L’applicazione
offre
uno
strumento,
limitato
agli
utenti
con
diritti
d’amministrazione, per l’inserimento di un oggetto nell’archivio. Per accedere al
servizio selezionare Inserisci Oggetto dal sottomenù visualizzato dopo aver
selezionato Amministrazione dal menù principale.
Gli attributi presenti nel modulo per l’inserimento di un oggetto sono stati
concettualmente divisi in tre ambiti: categoria, locazione e varie (figura 17).
Inizialmente sono presenti soltanto gli attributi associati a tutte le categorie
d’oggetto, successivamente alla scelta della categoria, verranno visualizzati anche i
campi relativi agli attributi associati alla categoria d’oggetto selezionata. Risulta
quindi ovvio che la categoria è uno dei dati da fornire obbligatoriamente perché
l’inserimento vada a buon fine.
Altro dato obbligatorio è l’etichetta dell’oggetto, che inizialmente vuota viene
precompilata contestualmente alla scelta della categoria con una stringa costante
che identifica la categoria e un numero rappresentate la quantità degli oggetti
associati alla categoria scelta già presenti in archivio, comprendendo anche
l’oggetto in fase d’inserimento. Questa stringa fornita, può essere tranquillamente
sostituita con un’altra, a patto che questa non risulti già associata ad un oggetto, in
questo caso l’inserimento riporterà con un messaggio d’errore, che l’etichetta è già
in uso.
50
Figura 17. Modulo d’inserimento oggetto
Per quanto concerne gli attributi visualizzati all’atto della scelta della categoria,
verranno evidenziati quelli indicati come obbligatori all’atto dell’associazione
attributi/categoria, con un asterisco a fianco della descrizione dell’attributo.
Successivamente agli attributi relativi alla categoria d’oggetto si possono
identificare quelli relativi alla locazione, tra i quali svolge un ruolo fondamentale
edificio.
La scelta dell’edificio è un’operazione obbligatoria per l’inserimento dell’oggetto,
in quanto permette di selezionare, in fasi successive, il piano e la stanza in cui
l’oggetto risiede.
Selezionati questi tre attributi, l’oggetto che si và a inserire è correttamente
identificato geograficamente, ma per avere un posizionamento corretto all’interno
delle mappe utilizzate da ArcReader, è necessario fornire anche le coordinate
cartesiane.
La lettura di quest’ultime deve essere eseguito direttamente in ArcReader, in quanto
devono essere riferite al baricentro della stanza dove risiede l’oggetto. Una volta in
possesso delle coordinate, sono disponibili due modalità d’inserimento: manuale e
automatica.
51
La modalità manuale consiste nell’inserire le coordinate negli specifici campi
Coordinata X e Coordinata Y, mentre la modalità automatica, selezionabile
cliccando sul pulsante posto a fianco dei due campi, richiede la stringa letta su
ArcReader (figura 18), che verrà poi scomposta in due stringhe, che a loro volta
verranno formattate e inserite nei due campi sopracitati.
Infine, gli ultimi attributi che caratterizzano l’oggetto sono di ambito generico e
riguardano la data d’inserimento, l’identificativo del servizio associato all’oggetto e
alcune note.
La
data
d’inserimento
dell’oggetto
è
un
dato
obbligatorio,
ma
non
obbligatoriamente deve coincidere con la data di compilazione del modulo, infatti a
lato della casella di testo un pulsante permette la visualizzazione di un calendario,
dal quale è possibile selezionare una data alternativa a quella odierna, con la quale è
precompilato il campo.
Compilato il modulo in ogni sua parte, premere il pulsante Inserisci Oggetto posto
in basso a sinistra per procedere con l’inserimento dell’oggetto in archivio.
Eventuali omissioni di dati obbligatori o errori nella compilazione del modulo
verranno segnalati con appositi messaggi e non daranno luogo all’inserimento.
Figura 18. Maschera d’inserimento stringa coordinate oggetto
52
4.5.3. Associazione attributi e categorie
La possibilità di definire le associazione tra attributi e categorie d’oggetto è
disponibile soltanto per utenti con diritti d’amministratore, ed è disponibile dopo
aver inserito una nuova categoria in Gestione Categorie oppure cliccando sul
pulsante modifica associato a una categoria già esistente, sempre in Gestione
Categorie (figura 19).
Come si può vedere in figura 20, a ogni categoria sono associati degli attributi di
default, su cui non sono possibili modifiche di nessun tipo. Oltre a questi, sono
disponibili altri attributi, definiti in Gestione Attributi o aggiunti utilizzando
l’apposito modulo posto in fondo alla pagina, associabili alla categoria.
Ogni attributo aggiuntivo possiede delle impostazioni standard, quali l’ordine di
visualizzazione e l’obbligatorietà, visibili a lato della descrizione dell’attributo.
L’ordine di visualizzazione viene utilizzato per creare la scheda di dettaglio di un
singolo oggetto, disponendo gli attributi associati alla categoria dell’oggetto
secondo l’ordine impostato, mentre l’obbligatorietà del campo viene considerata
nella fase di inserimento di un nuovo oggetto nell’archivio.
L’associazione di un attributo a una categoria permette di definire dei valori
personalizzati dell’ordine e dell’obbligatorietà specifici per quella categoria,
indipendentemente da quali siano i valori predefiniti dell’attributo.
Per associare un attributo a una categoria è sufficiente spuntare la checkbox
corrispondente all’attributo e modificare, se necessario, i valori descritti in
precedenza.
Dopo aver premuto il pulsante Salva, posto dopo l’elenco degli attributi, ogni
oggetto già presente in archivio e associato alla categoria, avrà nella propria scheda
di riepilogo oltre agli attributi standard anche quelli appena associati alla categoria.
Come già accennato è possibile creare un nuovo attributo anche in questa pagina,
senza doversi spostare in Gestione Attributi, il quale risulterà automaticamente
associato alla categoria e avrà come valori per l’ordine e l’obbligatorietà quelli
forniti in fase di creazione dello stesso attributo.
53
Figura 19. Elenco categorie d’oggetto e modulo inserimento
54
Figura 20. Modulo associazione attributi-categoria
55
4.5.4. Impostazioni applicazione
L’utente in possesso della qualifica di amministratore del servizio può intervenire
su alcune impostazioni dell’applicazione mediante il settaggio di parametri di
carattere generale, pubblico e amministrativo (figura 21).
Le impostazioni di tipo generale comprendono:
• compressione gZip;
• accesso limitato;
• abilitazione della registrazione degli accessi;
• abilitazione della registrazione degli errori del database;
• dimensione massima del file di log errori del database.
Le impostazioni di carattere prettamente pubblico, cioè che interessano le pagine
web navigabili da tutti i livelli d’autorizzazione, riguardano la suddivisione in
pagine dei listati d’oggetti derivanti da ricerche o appartenenze a una categoria.
Questi parametri definiscono infatti il numero d’oggetti presente in ogni pagina e il
numero massimo di collegamenti fra le varie pagine di risultati mostrati sotto ogni
listato.
Queste
impostazioni
sono
presenti
anche
nella
sezione
attinente
all’amministrazione, per mantenere una completa separazione tra i due livelli
d’autorizzazione.
L’applicazione prevede uno strumento per facilitarne il debug in caso di
malfunzionamenti,
attivabile
spuntando
la
voce
Abilitato
nella
sezione
d’amministrazione.
Non essendoci una vera e propria Home Page della sezione d’amministrazione, è
possibile selezionare quale funzionalità impostare come principale tramite un menù
a tendina riportante tutte le possibili scelte.
Selezionando la voce Impostazioni Generali nel sottomenù d’amministrazione viene
mostrato un ulteriore sottomenù che permette l’accesso alle funzioni di gestione
delle blacklist, sia quella per gli uffici (blacklist), che per quella delle unità
organizzative (blacklist_OU).
56
La blacklist permette di definire la lista degli uffici che bisogna escludere
dall’elenco di quelli a cui è possibile assegnare diritti d’accesso ai dipendenti in essi
contenuti, mentre la blacklist_OU rappresenta la lista delle unità organizzative che
bisogna escludere dall’elenco utilizzato per fornire una descrizione alle stanze.
Figura 21. Modulo impostazioni dell’applicazione
4.5.5. Assegnazione permessi
Lo strumento che permette di assegnare diritti d’accesso agli utenti è chiaramente
una prerogativa dell’amministratore del servizio, che vi può accedere selezionando
Gestione Utenti dal sottomenù di amministrazione.
Dopo aver selezionato un gruppo dal menù a tendina presente nel modulo
d’inserimento di un nuovo utente, dal menù che si creerà selezionare l’utente a cui
si vogliono assegnare di diritti d’accesso e selezionare i diritti dal sottostante menù,
scegliendo tra “amministratore” e “lettore” e confermare cliccando su Aggiungi.
Fatto ciò, il nome dell’utente appena aggiunto comparirà nella tabella riassuntiva
(figura 22), mostrando anche lo stato dell’utente, il suo ultimo accesso e il ruolo
assegnatogli.
57
L’amministratore può inoltre compiere alcune operazioni su un singolo utente, quali
la disattivazione, la modifica dei diritti d’autorizzazione e l’eliminazione, cliccando
sul relativo pulsante presente nella riga contenente le informazioni dell’utente.
La disattivazione di un utente equivale all’eliminazione, tranne per il fatto che
l’utente rimane presente nella tabella dei permessi e una sua riabilitazione risulta
più veloce di un nuovo inserimento. Questo stato è stato creato principalmente per
togliere temporaneamente i diritti a un utente.
Figura 22. Elenco degli utenti e relativi diritti
La tabella riassuntiva offre in alto a sinistra la possibilità di applicare un filtro alla
lista degli utenti, mostrando soltanto gli utenti attivi, quelli disattivati oppure
entrambi.
Nota d’interesse è data dall’impossibilità dell’amministratore di eseguire qualsiasi
azione su se stesso, questa impossibilità è stata impostata per impedire che un errore
commesso in fase d’assegnazione lasci l’applicazione senza almeno un
amministratore.
58
4.5.6 Dismissione oggetti
Un oggetto non più in uso, secondo la logica tradizionale dovrebbe essere eliminato
dall’archivio che lo censisce.
L’applicazione offre la possibilità, riservata agli amministratori, di porre l’oggetto
in uno stato di transizione tra lo stato “oggetto in uso” e l’eliminazione
dall’archivio: la dismissione, che equivarrebbe a uno stato “oggetto non in uso”.
L’introduzione di questo stato intermedio è stata effettuata per quegli oggetti che
temporaneamente non sono più in uso, ma che lo potrebbero tornare nel breve
periodo, ad esempio un oggetto mandato in assistenza per eseguire delle riparazioni.
Per assegnare a un oggetto lo stato “dismesso”, è sufficiente selezionare l’apposito
pulsante nella scheda di visualizzazione dei dettagli dell’oggetto e indicare il
motivo per cui viene dismesso l’oggetto, più eventuali note (figura 23).
Una volta dismesso l’oggetto, si potrà riportare nello stato attivo selezionando il
pulsante Attiva, che verrà visualizzato nella scheda di dettaglio dell’oggetto, al
posto di Dismetti.
Gli oggetti dismessi, per la loro natura di “non in uso” non hanno ragione di
comparire nell’archivio, infatti per poterli visualizzare è necessario selezionare
Oggetti Dismessi dal sottomenù d’amministrazione. Contestualmente a questa
selezione, verrà visualizzato un sottomenù riportante i collegamenti a strumenti di
ricerca specifici per questo stato d’utilizzo degli oggetti.
Le funzionalità di ricerca offrono, come per l’archivio degli oggetti attivi, la
possibilità di effettuare ricerche secondo alcuni parametri quali categoria, locazione
e attributo/caratteristica. Sono disponibili inoltre due ulteriori possibilità di ricerca,
basate sulla data e sulla motivazione della dismissione.
59
Figura 23. Richiesta motivazione per la dismissione di un oggetto
4.6. Accessibilità e stampa
Per rendere l’applicazione accessibile secondo le norme per le pubbliche
amministrazioni e le specifiche del WAI (Web Accessibility Initiative) [WAI], sono
state utilizzate diverse strategie.
La prima prevede l’utilizzo dei fogli di stile per assicurare la maggiore compatibilità
possibile con i diversi browser, mentre la seconda strategia è stato l’utilizzo di
specifici plugin per il browser Firefox, che offrissero strumenti di supporto alla
programmazione. Tra questi troviamo Firebug per il controllo degli script javascript
e per il tempo di ricezione delle pagine web e dei file a essa connessi.
Ci si è inoltre servito di strumenti quali l’HTML Validator e la Web developer
toolbar grazie ai quali è stato possibile validare il codice XHTML scritto secondo le
specifiche del proprio DTD e le regole applicate dai CSS.
L’analisi del layout ha infine previsto un controllo dei contrasti cromatici per
verificare che superassero il livello di tolleranza specificato per persone ipovedenti.
I collegamenti presenti nei menù sono stati associati a un’accessKey che
permettesse la navigazione interna all’applicazione anche senza l’ausilio del mouse,
servendosi soltanto della tastiera.
I form che prevedono l’inserimento di dati da parte degli utenti, per la loro natura di
"raccoglitori di informazioni", tendono in certi casi a diventare lunghi. Per questo,
60
sono stati introdotti dei tag per fare un po’ d’ordine all’interno dei form: grazie al
tag <fieldset> è stato possibile creare delle macro-aree all’interno dei form, mentre
il tag <legend>, indica il nome di ciascuna macro-area.
Si è scelto di associare a ogni campo che dovesse ricevere in input dei dati di
associare un’etichetta che lo descrivesse brevemente. Per far ciò si è utilizzato il tag
<label>.
Per ottimizzare le pagine web per la stampa si è scelto di utilizzare un foglio di stile
specifico per la stampa, associato alla pagina web grazie all’utilizzo dell’attributo
“media” con valore ”print” del tag <link>.
Grazie a questo sistema è stato possibile eliminare dalla stampa parti della pagina
inutili, come ad esempio il menù e il footer della pagina. Un esempio di stampa
della scheda di dettaglio di un oggetto è visibile in figura 24.
Figura 24. Stampa della scheda riepilogo caratteristiche di un oggetto
4.7. Test del servizio
La fase finale dell’iter di progettazione e sviluppo ha previsto una serie di test che
verificassero la presenza di eventuali bug, malfunzionamenti o difformità nel layout
del servizio.
Per quanto riguarda la parte hardware, l’applicazione è stata testata su tipologie
differenti di personal computer, laptop e desktop, con monitor di dimensioni,
61
risoluzioni e formati diversi, mentre dal lato software sono stati utilizzati browser
differenti, tra cui Firefox, Opera e versioni diverse di Internet Explorer (5.5, 6,7).
Inoltre si è sfruttata la possibilità offerta dal comune di Cento di utilizzare alcune
applicazioni in remoto, tra cui Firefox e Internet Explorer, senza cioè che siano
installate sul PC su cui si sta’ lavorando, si è così potuto verificare il
comportamento dell’applicazione quando il browser viene eseguito in locale o in
remoto.
Sin dall’inizio di questa fase si è notato un comportamento discordante da parte di
Internet Explorer, non solo nei confronti degli altri browser, ma anche fra le
differenti versioni, nell’interpretazione dei file css. Il risultato di ciò era
un’interfaccia non omogenea su tutti i browser, si è perciò deciso di intervenire sul
file css aggiungendo alcuni hack e workaround per ottimizzare la resa grafica su
tutti i browser.
Ulteriori test, hanno evidenziato un problema di cache, su un file javascript generato
dinamicamente, da parte di Internet Explorer se eseguito in remoto. Per ovviare al
problema è bastato settare alcuni header nel file (figura 25), forzandone il download
per ogni richiesta.
Durante questa fase sono state eseguite anche delle modifiche al metodo di
salvataggio in sessione delle informazioni sull’identità dell’utente, scegliendo di
salvare in un’unica variabile la serializzazione dell’username dell’utente, del livello
d’autorizzazione e dell’ufficio d’appartenenza dell’utente, codificata in Base64.
Sebbene questa modifica non fosse strettamente necessaria, si è scelto di attuarla
per non lasciare i dati personali dell’utente in chiaro nella sessione.
Figura 25. Settaggio header nel file dic.lib.js.php
62
5. Conclusioni
Questa tesi è il frutto di un progetto svolto nella cornice di un tirocinio effettuato
presso il Comune di Cento, che ha previsto la progettazione e lo sviluppo di
un’applicazione Web per la gestione del patrimonio multimediale comunale, che a
differenza dei comuni inventari, consente la catalogazione degli oggetti in base alla
propria tipologia. L’applicazione è stata configurata in particolare per la gestione
dell’inventario di oggetti appartenenti al mondo dell’informatica e dell’elettronica,
ad esempio stampanti, PC, fax.
L’applicativo descritto in questa tesi è andato a sostituire il vecchio servizio
“Inventario S.S.I.”, che non rispettava le normative vigenti di accessibilità, ma
soprattutto presentava delle forti limitazioni essendo stato concepito e sviluppato
per visualizzare le schede di dettaglio degli oggetti mostrati nelle mappe di
ArcReader.
Lo sviluppo del progetto ha previsto una fase iniziale di raccolta delle specifiche e
dei requisiti che l’applicazione doveva rispettare, seguita da un’attenta analisi
dell’applicazione esistente, soprattutto della base dati, vista la necessità di
mantenerne alcuni aspetti della struttura invariati per non inibire la possibilità d’uso
di ArcReader.
Si è data particolare importanza alla fase di progettazione del servizio, privilegiando
una struttura modulare dell’applicazione, cercando di creare dove possibile delle
astrazioni che permettano all’applicazione di funzionare indipendentemente dalle
piattaforme sottostanti.
Durante le varie fasi in cui è stata creata la nuova applicazione, sono emerse
problematiche di diverso tipo che sono state tutte risolte; di questo è interessante
osservare come una buona progettazione possa rendere le cose più semplici rispetto
a problemi imprevisti, e dare la possibilità di affrontare casi difficili con meno
difficoltà e perdita di tempo. Ne è un esempio l’associazione tra attributi e categorie
d’oggetto che inizialmente era demandata al database tramite una tabella contente le
associazioni e poi implementata a livello server-side per rendere più performante e
leggera l’applicazione.
63
Le differenze fra l’applicazione sviluppata nel corso di questo tirocinio e
l’applicazione esistente sono molteplici, partendo dal meccanismo d’accesso fino a
tutte le funzionalità per la gestione delle categorie d’oggetto, degli attributi e delle
stanze.
Diversamente dal vecchio applicativo che richiedeva un username e una password
generici per l’accesso, quello che si è sviluppato consente l’accesso al servizio solo
agli utenti presenti nel servizio di directory del comune, i quali devono fornire la
propria username e password personale. Questa nuova modalità d’accesso ha
permesso di assegnare dei diritti d’accesso differenti per gli utenti, distinguendoli in
lettori e amministratori, grazie al quale offrire o meno la possibilità di fruire di
alcune funzionalità rispetto ad altre. Alla figura dell’amministratore sono stati
infatti concessi più diritti rispetto al lettore, egli ha la possibilità di assegnare diritti
d’accesso agli altri utenti, controllare gli accessi all’applicazione, registrati durante
la fase di autenticazione, impostare alcuni parametri caratteristici e tenere sotto
controllo il corretto funzionamento dell’applicativo consultando i log degli errori.
L’applicazione è stata fornita di uno strumento di debug per permettere, nel caso si
verificassero, un’identificazione più rapida degli errori, oltre a ciò in fase di
sviluppo il codice scritto è stato man mano commentato favorendo così i tecnici
dell’ufficio S.S.I. nella risoluzione degli errori.
Questo progetto ha permesso di affrontare una moltitudine di aspetti non affrontati o
affrontati in parte in ambito universitario, come la programmazione in php, descritta
in parte e con nozioni molto basilari, come l’approfondimento della struttura e
configurazione di Microsoft SQL Server. Ciò nonostante, l’istruzione e la cultura
offerta dall’Università ha permesso di apprendere e approfondire velocemente i
sistemi, le piattaforme di sviluppo e tutto quello che non era conosciuto in
precedenza.
Il progetto è stato svolto sotto il coordinamento dello staff dell’SSI del Comune di
Cento, un gruppo molto affiatato e competente, capace di fornire un supporto
fondamentale nell’inserimento nella realtà di lavoro e nella risoluzione delle
problematiche che si sono presentate durante lo sviluppo dell’applicazione.
64
6. Riferimenti e Bibliografia
[ArcReader]
http://www.gisitalia.it/Prodotti/ArcGisDesktop/
ArcReader/tabid/94/Default.aspx
[Servizi Web PA]
http://www.cnipa.gov.it/site/it-IT/
[W3C]
http://www.w3c.org
[WAI]
http://www.w3c.it/wai/
[Protocollo HTTP]
http://www.w3.org/Protocols/
[Web Server Apache]
http://www.apache.org
[NCSA]
http://www.ncsa.uiuc.edu/
[SQL Server]
http://www.microsoft.com/italy/server/sql/
[Linguaggio SQL]
http://www.wiscorp.com/
[T-SQL]
http://msdn2.microsoft.com/
/en-us/library/ms189826(SQL.90).aspx
[MySql]
http://www-it.mysql.com/
[PostGreSql]
http://www.postgresql.org/
[Active Directory]
http://www.microsoft.com/windowsserver2003
/technologies/directory/activedirectory/
[LDAP]
http://it.wikipedia.org/wiki
/Lightweight_Directory_Access_Protocol
[HTML]
http://www.w3.org/TR/html401/
[SGML]
http://www.w3.org/MarkUp/SGML/
[XML]
http://www.w3.org/XML/
[XHTML]
http://www.w3.org/TR/xhtml1/
[CSS]
http://www.w3.org/Style/CSS/
[DTD]
http://www.w3schools.com/dtd/default.asp
[PHP]
http://it.php.net/
[JavaScript]
http://developer.mozilla.org/en/docs/JavaScript
[DOM]
http://www.w3.org/DOM/
www.wikipedia.org
Dispense del corso di “Reti di Calcolatori”, Prof. Stefanelli
65

Documenti analoghi