Indice - Comune di Cento

Università degli studi di Ferrara
Indice
1. Introduzione...............................................................................................3
2. Progetto dell'applicazione Web "Missioni Amministratori".....................5
1.1.Scopo dell’applicazione........................................................................5
1.2.Contesto.................................................................................................5
1.3.Specifiche..............................................................................................6
1.3.1.Gli stadi di una richiesta di missione............................................6
1.3.2.Gruppi Utente...............................................................................8
1.4.Architettura............................................................................................9
1.5.Gestione dei permessi..........................................................................10
1.6.Architettura del database.....................................................................11
1.7.Struttura delle pagine Web..................................................................12
3. Tecnologie impiegate..............................................................................15
1.8.Server Web Apache.............................................................................15
1.9.MySql..................................................................................................16
1.10.HTML e CSS.....................................................................................17
1.11.Javascript...........................................................................................18
1.12.P.H.P..................................................................................................20
1.12.1.Storia:20
1.12.2.Caratteristiche:..........................................................................21
4. Realizzazione dell’applicazione..............................................................22
1.13.Tabelle del Database.........................................................................22
1.14.Struttura degli script..........................................................................24
1.15.Implementazione del motore a workflow..........................................25
1.16.Le transizioni e la compatibilità con i browser.................................26
1.17.Missione: dalla richiesta all’approvazione........................................27
1
Università degli studi di Ferrara
1.17.1.Richiesta...................................................................................27
1.17.2.Approvazione...........................................................................29
1.17.3.Compilazione dettagli...............................................................29
1.17.4.Verifica spese e saldo...............................................................30
1.17.5.Chiusura....................................................................................32
1.17.6.Archiviazione...........................................................................32
1.18.Report................................................................................................34
1.19.Amministrazione...............................................................................34
1.20.Test di servizio..................................................................................35
5. Conclusioni..............................................................................................35
6. Riferimenti...............................................................................................37
7. Indice delle figure....................................................................................37
2
1. Introduzione
Gli enti pubblici, responsabili della gestione di numerosi dati relativi ai
cittadini, presentano un’ampia quantità di procedure burocratiche per la
raccolta e amministrazione degli stessi.
Con il passare degli anni gli enti hanno percepito sempre più la necessità di
informatizzare i loro servizi e le loro procedure, al fine di ridurre i tempi
morti della burocrazia e di migliorare la qualità del servizio, oltre che di
raggiungere in maniera più efficiente i cittadini.
Il Comune di Cento, che da tempo è uno dei comuni più orientati verso
l’informatizzazione dei propri apparati, presenta già numerosi servizi
realizzati tramite applicazioni Web, come ad esempio il catasto o l’archivio
contenente i verbali del consiglio comunale, entrambi consultabili via web.
L’informatizzazione del comune non si limita però alla fornitura di servizi
per il cittadino, ma comprende anche numerosi applicativi atti a migliorare
la qualità del lavoro all’interno del comune stesso, come un servizio di
telefonia VoIP o applicazioni mirate ad affiancare i vari uffici nella
compilazione della modulistica, richiesta dalla burocrazia. Un esempio di
questo secondo caso è l’applicazione “Missioni Dipendenti”, che si occupa
di gestire le varie pratiche riguardanti le uscite dei dipendenti comunali,
specialmente per quel che concerne l’erogazione di rimborsi spese,
nell’ottica della compilazione del bilancio annuale.
Questa tesi descrive la progettazione e realizzazione di un ampliamento di
“Missioni Dipendenti”, tramite una nuova applicazione, “Missioni
Amministratori”, che si occupa di gestire le missioni di consiglieri e
assessori (collettivamente chiamati amministratori), i quali, essendo
sottoposti a normative differenti rispetto al resto dei dipendenti comunali in
materia di rimborsi spese, non vengono trattati dall’applicazione
precedente.
“Missioni Amministratori” ha quindi lo scopo di permettere a consiglieri e
assessori di compilare autonomamente le richieste e le note spese relative
alle proprie missioni, riducendo al minimo la necessità di spostarsi tra
uffici per consegnare i vari moduli.
L’applicazione deve inoltre permettere alla segreteria generale, che si
occupa di stilare il bilancio del comune, di visualizzare report dettagliati
sulle spese sostenute dagli amministratori, in modo da facilitarne la
compilazione.
Dopo aver definito con precisione quale fosse l’iter burocratico che una
missione deve seguire e quali fossero gli attori coinvolti in esso, è stato
possibile passare al progetto. Quest’ultimo è partito con l’introduzione di
un motore a workflow (o W.E. che sta per Workflow Engine) per la
gestione dell’evoluzione di una richiesta di missione, in modo da
controllare efficacemente le varie operazioni che caratterizzano il
passaggio di quest’ultima da uno stadio all’altro.
In seguito l’ambito d’impiego del W.E. si è allargato, comprendendo anche
la gestione delle transizioni tra una pagina web e l’altra, al fine di
sovraintendere l’applicazione di politiche di sicurezza che consentano agli
utenti l’accesso solamente alle pagine per cui hanno i diritti.
Una volta stabilite le fondamenta del progetto, ci si è occupati di realizzare
un’applicazione quanto più simile, come interfaccia e logica d’utilizzo, a
quella già esistente, al fine di renderne l’utilizzo il più immediato possibile.
Infine è stata progettata un’architettura di base degli script, per una facile
realizzazione e manutenzione dell’applicazione.
A questo punto si è passati alla fase di realizzazione, basandosi su tutto ciò
che è stato definito in fase di progettazione e seguendo le linee guida che
sono state elencate. Sono state create le tabelle necessarie, è stato
sviluppato il motore a workflow e basandosi su di esso sono state create le
varie pagine, partendo inizialmente da blocchi di base che sono stati man
mano composti per realizzare strutture più complesse.
Si è inoltre cercato di garantire la massima compatibilità dell’applicativo
con i vari browser presenti sul mercato, allo scopo di rendere il servizio
fruibile indipendentemente dalla configurazione della macchina utilizzata
per accedervi.
Questa tesi è il frutto di un tirocinio svolto presso il Servizio Sistemi
Informativi (SSI) del Comune di Cento che si occupa della gestione e
amministrazione hardware e software della rete civica, l’amministrazione
dell’intranet comunale, del portale del Comune, la gestione e realizzazione
di servizi on-line e siti Web strettamente collegati al Comune.
2. Progetto
dell'applicazione
Web
"Missioni
Amministratori"
Il progetto prevede lo sviluppo di un’applicazione che permetta di
informatizzare le procedure legate alla richiesta e alla gestione delle
missioni degli amministratori, intendendo con missioni le trasferte, o
uscite, che un dipendente effettua.
1.1.
Scopo dell’applicazione
L’applicativo deve permettere di gestire i vari stadi di una missione,
partendo dalla richiesta di autorizzazione per una nuova uscita, fino ad
arrivare all’archiviazione, passando per l’erogazione di un eventuale
anticipo, la compilazione delle note spesa, il calcolo del rimborso
chilometrico e il saldo.
Bisogna inoltre prevedere una struttura dell’applicazione che permetta a
ogni amministratore, nel senso di consigliere o assessore, di inserire
autonomamente i dati delle proprie missioni senza però inserire procedure
troppo rigide, in modo da permettere a eventuali delegati di effettuare
inserimenti in vece degli amministratori.
Si deve inoltre prevedere la creazione di report riassuntivi, che
comprendano spese effettuate e rimborsi, sia generali sia riferiti a un
singolo amministratore, in modo da semplificare la stesura del bilancio
annuale.
1.2.
Contesto
Il comune di Cento, da tempo indirizzato verso l’informatizzazione delle
procedure amministrative, disponeva già di un’applicazione Web, ”
Missioni Dipendenti”, molto simile a quella che è stata realizzata.
La principale differenza tra le due applicazioni, infatti, riguarda i soggetti
che vengono gestiti: “Missioni Dipendenti” si occupa di tutti i dipendenti
comunali ad eccezione di consiglieri e assessori, che vengono trattati
“Missioni Amministratori”.
La necessità di utilizzare due applicazioni diverse sorge dalle differenze a
livello burocratico e amministrativo nella gestione dei rimborsi spese degli
amministratori rispetto agli altri dipendenti comunali.
Ad eccezione di questo però, le funzioni svolte dalle due applicazioni sono
pressoché identiche.
Il contesto iniziale prevedeva quindi un insieme di procedure burocratiche
per la compilazione delle richieste di rimborso, che veniva in parte
informatizzato tramite un’applicazione preesistente e in parte svolto nella
maniera tradizionale, per mezzo di diversi moduli cartacei.
1.3.
Specifiche
In questa sezione si definisce qual è la realtà che l’applicazione deve
rappresentare: nello specifico si individuano i vari gruppi utente e si
schematizza il percorso burocratico che porta una missione dalla richiesta
all’archiviazione.
1.3.1.
Gli stadi di una richiesta di missione
La prima cosa da individuare è la trafila di passaggi che vengono effettuati
per ottenere il rimborso spese di un’uscita.
Come si può vedere in figura 1, per prima cosa viene compilata una
richiesta di missione e sottoposta al proprio responsabile. Dopo
l’approvazione, nel caso si debba ricevere un anticipo, la richiesta arriva
all’economato che si occupa di erogarlo. A questo punto l’amministratore
può svolgere la missione. Al termine di essa bisogna compilare la nota
spese e l’elenco delle tappe (per il calcolo del rimborso chilometrico) e
consegnarla in economato, per un rimborso immediato, o al gabinetto del
sindaco, per un rimborso in busta paga. Economato e gabinetto del sindaco
si occuperanno poi di fornire i dati alla segreteria amministrativa, che
procederà all’archiviazione.
FIGURA 1: L’EVOLUZIONE DI UNA MISSIONE, DALLA RICHIESTA ALL’ARCHIVIAZIONE.
1.3.2.
Gruppi Utente
Come si è potuto vedere, la realtà che il programma va a rappresentare è
composta di diversi agenti che interagiscono, ognuno con funzioni e
privilegi specifici. Questi agenti corrispondono a diversi tipi di utenti, nello
specifico: consigliere o assessore, responsabile, economato, gabinetto del
sindaco, segreteria amministrativa e amministratore di sistema.
Chi accede all’applicazione può appartenere a uno o più di questi gruppi,
come pure a nessuno (il generico dipendente comunale ad esempio).
Le azioni che i vari gruppi utente possono compiere sono le seguenti.
Consigliere o Assessore:
- può sottoporre al suo responsabile una richiesta di missione;
- può compilare le note spese e le tappe percorse relative alle missioni
da lui eseguite;
- può visualizzare i dati relativi alle missioni che ha svolto.
Responsabile:
- può approvare o rifiutare una richiesta di missione a lui sottoposta;
- può visualizzare i dati relativi alle missioni che ha approvato.
Economato:
- eroga gli anticipi;
- effettua il saldo;
- può visualizzare i dati relativi alle missioni.
Gabinetto del Sindaco:
- effettua il saldo;
- verifica i dati relativi alle missioni prima di chiuderle;
- chiude le missioni;
- può visualizzare i dati relativi alle missioni.
Segreteria Amministrativa:
- archivia le missioni;
- può visualizzare report riassuntivi sulle varie missioni.
Amministratore di Sistema:
- si occupa della corretta assegnazione dei gruppi agli utenti;
- esegue operazioni di manutenzione sull’applicazione.
Oltre a questo, bisogna dare la possibilità agli agenti che si occupano del
saldo e dell’archiviazione (economato, gabinetto del sindaco e segreteria
amministrativa), di correggere eventuali errori che dovessero riscontrare,
permettendo quindi loro di modificare le note spese e in alcuni casi la lista
delle tappe.
Un ultimo punto riguarda la necessità di un sistema d’impersonificazione,
che permetta ad alcuni utenti specifici di agire in vece di altri, da cui hanno
ricevuto in precedenza la delega. In questa maniera, ad esempio, la
segretaria del sindaco può compilare una richiesta di missione in nome di
un assessore se quest’ultimo decide di demandare a lei la parte burocratica
della richiesta.
1.4.
Architettura
Nel progettare la struttura dell’applicazione si è dovuto tenere presente lo
scopo principale per cui essa è nata, ovvero gestire l’evoluzione di una
missione attraverso le varie fasi che la contraddistinguono.
L’idea di fondo è di un’entità “missione”, con vari attributi che la
caratterizzano, che passa da uno stadio all’altro, ad esempio da “richiesta
pendente” ad “approvata”. A ogni passaggio di stato possono inoltre essere
associate delle condizioni, che devono essere verificate affinché esso possa
essere eseguito, oppure operazioni da svolgere (ad esempio, inviare un’email di conferma all’utente).
Si è quindi pensato di organizzare il flusso delle azioni tramite un
workflow [Workflow], intendendo con questo termine la serie d’interazioni
che devono avvenire per completare un’azione.
A questo scopo si è realizzato un motore a workflow, ovvero l’applicazione
software che si occupa di interpretare gli eventi del sistema e agire su di
essi in base alle regole del workflow.
Lo scopo del motore non si limita però alle missioni: esso, infatti, si
preoccupa di costruire ogni pagina del sito, applicando il concetto di
workflow all’intera applicazione. Il passaggio tra due pagine è
l’equivalente di un cambio di stato e le condizioni sulle transizioni tra uno
stato/pagina e l’altro sono caratterizzate da un controllo dei permessi
dell’utente, per consentire l’accesso solamente alle pagine per cui possiede
i diritti.
1.5.
Gestione dei permessi
La gestione dei permessi degli utenti, un punto importante in qualsiasi
applicazione di un certo livello, diventa di fondamentale importanza nel
caso delle missioni degli amministratori, dove vengono gestiti dei rimborsi
spese. Anche senza prendere in considerazione la possibile malafede degli
utenti, calcolare un bilancio basandosi su dati che possono essere
modificati liberamente da chiunque, creerebbe dubbi sulla validità dello
stesso.
Per questo motivo l’esecuzione di qualsiasi azione da parte dell’utente è
sottoposta a un controllo: l’azione viene eseguita solamente se l’utente
detiene il permesso per eseguirla.
Un utente può possedere dei diritti specifici legati a sé e altri dovuti ai
gruppi a cui appartiene. L’unione di questi forma l’insieme dei suoi
permessi.
Le azioni controllate, invece, sono fondamentalmente le richieste di pagina
fatte al server. Ogni richiesta che il browser invia al server viene
considerata come una transizione tra lo stato attuale e quello specificato da
essa. Se si tenta di eseguire una transizione senza averne il diritto, il server
la ignora e restituisce un errore.
Uno schema riassuntivo di questo procedimento si può vedere in figura 2,
dove “successo” rappresenta la restituzione della pagina richiesta, mentre
“fallimento” rappresenta il messaggio di errore.
FIGURA 2: LA GESTIONE DEI PERMESSI
1.6.
Architettura del database
Il database è strutturato in tre sezioni fondamentali: tabelle relative alle
missioni, tabelle relative al motore a workflow e tabelle relative ai
permessi. In aggiunta a queste esistono alcune tabelle di servizio per il
funzionamento dell’applicazione.
Come si può vedere in figura 3, che è una rappresentazione del database ad
alto livello, le tre sezioni sono cosi composte:
Parte relativa alle missioni (in verde):
- Missioni. Tutte le informazioni generali che riguardano un’uscita;
- Utenti. Le persone associate a una missione, il soggetto che la
intraprende e i responsabili;
- Mezzi. I veicoli che possono essere utilizzati per gli spostamenti;
- Tappe. Le tappe percorse, associate alla missione in cui sono state
effettuate.
Parte relativa al motore a workflow (in rosso):
- Stato. L’insieme degli stati del motore, con le relative proprietà;
- Transizioni. L’insieme delle transizioni.
Parte relativa ai permessi (in arancio):
- Permessi. L’insieme delle tabelle che associano i permessi agli utenti
del sistema, da non confondere con gli utenti legati a una specifica
missione.
FIGURA 3: LA STRUTTURA DEL DATABASE
1.7.
Struttura delle pagine Web
Nel progettare la struttura delle pagine, considerazione che è stata fatta è
che l’applicazione verrà usata da persone che hanno già utilizzato
“Missioni Dipendenti”, per cui realizzare pagine con un aspetto, e
un’impostazione logica, simile a quello dell’applicazione già esistente è di
fondamentale importanza.
Per questo motivo, come si può vedere in figura 4, si è divisa l‘interfaccia
in tre parti: Header, Menù e Contenuto.
- Header. Contiene il banner del Comune di Cento e il menu legato al
sistema d’impersonificazione;
- Menù. Mostra l’elenco delle azioni che l’utente può eseguire,
raggruppate per gruppo di appartenenza;
- Contenuto. Il contenuto specifico.
Inoltre, in figura 5 sono riportate entrambe le interfacce, per un rapido
confronto.
La struttura interna delle pagine, invece, è stata orientata verso il maggior
riutilizzo di codice possibile, ai fini di una maggior manutenibilità.
Esiste una pagina principale, strutturata come l’interfaccia, il cui contenuto
viene creato dinamicamente.
Header e menù vengono creati da funzioni apposite a ogni caricamento
della pagina, ma non subiscono variazioni sostanziali tra uno stato e l’altro.
Il contenuto invece dipende dallo stato in cui ci si trova: ognuno di essi ha
una vista corrispondente, se possibile condivisa tra più stati, che determina
cosa viene visualizzato.
Le viste inoltre possono essere realizzate componendo altre viste, ad
esempio per generare report man mano più dettagliati.
Va inoltre previsto un controllo lato client dei dati inseriti nelle form, in
modo da ridurre il più possibile rallentamenti dovuti a comunicazioni con il
server. Infatti, in caso di mancato controllo lato client la spedizione di
valori errati comporterebbe l’invio da parte del server di un messaggio di
errore
e
la
richiesta
di
dati
corretti.
Se i controlli vengono invece eseguiti anche lato client, al server arrivano
solo dati corretti.
FIGURA 4: L’INTERFACCIA DELL’APPLICAZIONE
FIGURA 5: UN CONFRONTO TRA LE DUE APPLICAZIONI: IN ALTO “MISSIONI DIPENDENTI” E IN BASSO
“MISSIONI AMMINISTRATORI”.
3. Tecnologie impiegate
Il progetto si basa sul popolare quadrinomio Linux, Apache, MySql e
P.H.P. (L.A.M.P.).
Apache è il server web, nel caso specifico, in esecuzione su una macchina
virtuale linux, MySql invece è il Data Base Management System
(D.B.M.S.) mentre P.H.P. è il linguaggio tramite il quale si realizzano
dinamicamente pagine html.
In aggiunta a questi, si è utilizzato il linguaggio di scripting Javascript per
la manipolazione della pagina lato client e i fogli di stile CSS per la parte
grafica.
1.8.
Server Web Apache
Apache HTTP Server [Server Web Apache], o più comunemente Apache, è
il nome dato alla piattaforma server Web modulare più diffusa (ma anche al
gruppo di lavoro open source che ha creato, sviluppato e aggiornato il
software server), in grado di operare da sistemi operativi UNIX-Linux e
Microsoft.
Apache è un software che realizza le funzioni di trasporto delle
informazioni, d’internetwork e di collegamento, ha il vantaggio di offrire
anche funzioni di controllo per la sicurezza come quelli che compie il
proxy.
Il progetto Apache nacque nel 1995. A quel tempo, il server Web più
diffuso era il daemon HTTP pubblico sviluppato da Rob McCool al NCSA
(National Center for Supercomputing Application), Università dell'Illinois.
Dal momento però che a partire dal 1994 lo sviluppo di questo server si era
fermato (anche perché il suo autore aveva lasciato l'NCSA) un gruppo di
webmaster aveva iniziato a sviluppare patch in maniera autonoma.
La versione 1.0 fu pubblicata l'1 dicembre 1995. Nel giro di un anno, la sua
diffusione aveva già superato quella del server NCSA da cui era derivato.
La versione 2.0 di Apache venne rilasciata durante la conferenza
ApacheCon, tenutasi nel marzo 2000 a Orlando, in Florida.
Il grande successo di diffusione di questo software è l'indicatore più chiaro
della qualità e dell'affidabilità di questo prodotto: secondo un'indagine
Netcraft del 2005, su 75 milioni di siti web, circa 52 milioni utilizzavano
Apache, a ottobre 2006 il numero è salito a 60 milioni (60,32% del totale).
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 permette l'accesso a un o più siti, gestendo varie
caratteristiche di sicurezza e potendo ospitare diverse estensioni per pagine
attive (o dinamiche), come PHP o Jakarta/Tomcat.
1.9.
MySql
MySQL è un database management system (DBMS) relazionale [DBMS
MySQL], composto da un client con interfaccia a caratteri e un server,
entrambi disponibili sia per sistemi Unix come GNU/Linux che per
Windows, anche se prevale un suo utilizzo in ambito Unix.
Dal 1996 supporta la maggior parte della sintassi SQL [Linguaggio SQL] e
si prevede in futuro il pieno rispetto dello standard ANSI. Possiede delle
interfacce per diversi linguaggi, compreso un driver ODBC, due driver
Java e un driver per Mono e .NET.
Il codice di MySQL viene sviluppato fin dal 1979 dalla ditta TcX
ataconsult, adesso MySQL AB, ma è solo dal 1996 che viene distribuita
una versione che supporta SQL, prendendo spunto da un altro prodotto:
mSQL.
Il codice di MySQL è di proprietà dell’omonima società, viene però
distribuito con la licenza GNU GPL oltre che con una licenza commerciale.
Fino alla versione 4.0, una buona parte del codice del client era licenziato
con la GNU LGPL e poteva dunque essere utilizzato per applicazioni
commerciali. Dalla versione 4.1 in poi, anche il codice dei client è
distribuito sotto GNU GPL. Esiste peraltro una clausola estensiva che
consente l'utilizzo di MySQL con una vasta gamma di licenze libere.
MySQL svolge il compito di DBMS nella piattaforma LAMP, una delle più
usate e installate su Internet per lo sviluppo di siti e applicazioni web
dinamiche.
Nel luglio 2007 la società svedese MySQL AB aveva 385 dipendenti in
265 paesi. I suoi principali introiti provengono dal supporto agli utilizzatori
di MySQL tramite il pacchetto Enterprise, dalla vendita delle licenze
commerciali e dall'utilizzo da parte di terzi del marchio MySQL. Il 16
gennaio 2008 Sun Microsystems ha acquistato la società per un miliardo di
dollari, stimando il mercato del database in 15 miliardi di dollari.
Nel caso specifico del progetto ci si è inoltre avvalsi di MySql
administrator, un programma che permette di eseguire operazioni di
amministrazione sul database tramite un’interfaccia grafica.
1.10.
HTML e CSS
L'HyperText Markup Language (HTML, traduzione letterale: linguaggio di
marcatura per ipertesti) [Linguaggio HTML] è un linguaggio usato per
descrivere la struttura dei documenti ipertestuali disponibili nel World
Wide Web. Tutti i siti web sono scritti in HTML, codice che viene letto ed
elaborato dal browser, il quale genera la pagina che viene visualizzata sullo
schermo del computer.
L'HTML non è un linguaggio di programmazione, ma un linguaggio di
markup, ossia descrive il contenuto, testuale e non, di una pagina web.
Punto HTML (.html) o punto HTM (.htm) è anche l'estensione comune dei
documenti HTML.
È 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.
L'HTML è un linguaggio di pubblico dominio la cui sintassi è stabilita dal
World Wide Web Consortium (W3C) [W3C], e che è basato su un altro
linguaggio avente scopi più generici, l'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. Dopo un periodo di sospensione, in cui il W3C si è
focalizzato soprattutto sulle definizioni di XHTML (applicazione a HTML
di regole e sintassi in stile XML) e dei fogli di stile Cascading Style Sheet,
CSS, nel 2007 è ricominciata l'attività di specifica con la definizione,
ancora in corso, di HTML 5, attualmente allo stato di bozza.
I fogli di stile a cascata (dall'inglese CSS Cascading Style Sheets) [CSS],
detti semplicemente fogli di stile, vengono usati per definire la
rappresentazione di 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. 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.
1.11.
Javascript
JavaScript [Linguaggio JavaScript] è un linguaggio di scripting orientato
agli oggetti comunemente usato nei siti web. Fu originariamente sviluppato
da Brendan Eich della Netscape Communications con il nome di Mocha e
successivamente di LiveScript, ma in seguito è stato rinominato
"JavaScript" ed è stato formalizzato con una sintassi più vicina a quella del
linguaggio Java di Sun Microsystems. JavaScript è stato standardizzato per
la prima volta tra il 1997 e il 1999 dall’ECMA con il nome ECMAScript.
L'ultimo standard, del dicembre 1999, è ECMA-262 Edition 3, e
corrisponde a JavaScript 1.5. È anche uno standard ISO.
Prima dell'avvento di JavaScript, affinché una pagina web rispondesse a
una interazione con l'utente (un clic su di un bottone di un form ad
esempio) era necessario comunicare con il server (il computer remoto al
quale sarebbero stati inviati i dati per la loro elaborazione). Un classico
esempio é quello del controllo dei dati inseriti dall'utente in un form. Se
non si impiega JavaScript, ecco cosa accade: l'utente compila il form,
probabilmente dimentica di inserire alcuni dati ritenuti obbligatori oppure li
inserisce in modo errato (ad esempio, una data, un indirizzo email, il codice
fiscale ecc…). Nel momento in cui l'utente inoltra il form cliccando
sull'apposito pulsante d’invio, i dati vengono spediti al server e qui
sottoposti a un processo di controllo, se questo controllo non va a buon
fine, l'utente si vede recapitare una pagina web contenente il form appena
compilato, insieme ad una serie di messaggi di errore, relativi a quelle
informazioni non fornite o fornite in modo errato. Tutto ciò comporta dei
tempi di attesa legati alla comunicazione tra il client, la macchina
dell'utente, e il server. Questi tempi possono essere ridotti se anche la
pagina web potesse eseguire quei controlli di correttezza sui dati. Questo è
un classico esempio d’impiego di JavaScript per migliorare il grado
d’interazione dell'utente con una pagina web.
JavaScript è un linguaggio di programmazione orientato a oggetti con una
sintassi vagamente basata sul C. Come il C, JavaScript ha il concetto di
parole chiave riservate, che rendono quasi impossibile espandere il
linguaggio (essendo eseguito direttamente dal sorgente). Come nel C, il
linguaggio non ha propri costrutti d’input o output; mentre il C si affida alle
librerie I/O standard, 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. Questi verranno illustrati
per primi.
JavaScript, se integrato in un browser Web, si collega alle applicazioni
tramite interfacce chiamate DOM (Document Object Model), a lato server
(web server) e al lato client (browser). Molti siti web usano la tecnologia
JavaScript lato client per creare potenti applicazioni web dinamiche. Un
uso principale del Javascript basato su web è la scrittura di piccole funzioni
integrate nelle pagine HTML, che interagiscono con il DOM del browser
per compiere determinate azioni non possibili con il solo HTML statico,
come aprire una nuova finestra, controllare i valori nei campi d’ingresso,
cambiare le immagini al passaggio del mouse, ecc. Sfortunatamente, i
DOM dei vari browser non sono standardizzati, browser diversi espongono
diversi oggetti o metodi allo script, ed è quindi spesso necessario scrivere
differenti versioni di una funzione JavaScript per ciascuno dei browser.
Al di fuori del Web, interpreti JavaScript sono integrati in diverse
applicazioni. Adobe Acrobat e Adobe Reader supportano JavaScript nei
file PDF. La piattaforma Mozilla, che è alla base di molti diffusi browser
Web, usa JavaScript per implementare l'interfaccia utente e la logica di
transazione dei suoi vari prodotti. Gli interpreti JavaScript sono integrati
anche nelle applicazioni proprietarie prive di interfacce programmabili via
script.
Il principale tag del linguaggio Javascript è il tag “script”. Questo tag è
un'estensione del HTML, in quanto permette la gestione di codice esterno
che non è nativo HTML. Un documento può presentare in più parti la
definizione del tag SCRIPT. Tramite questo tag si può rappresentare la
versione utilizzata e, a seconda del browser, si avrà l'interpretazione
appropriata.
1.12.
P.H.P.
PHP (acronimo ricorsivo di PHP Hypertext Preprocessor) è un linguaggio
di scripting interpretato, con licenza open source e parzialmente libera (ma
incompatibile con la GPL), 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.
1.12.1.
Storia:
Nato nel 1994 ad opera del danese Rasmus Lerdorf, PHP era in origine una
raccolta di script CGI che permettevano una facile gestione delle pagine
personali. Per questo motivo il significato originario dell'acronimo pare
fosse Personal Home Page (sull'origine dell'acronimo ci sono tuttora alcuni
dubbi, alimentati dallo stesso Lerdorf che ha contribuito volontariamente a
generare attorno al nome questo alone di mistero). Il pacchetto originario
venne in seguito esteso e riscritto dallo stesso Lerdorf in C, aggiungendo
funzionalità quali il supporto al database mSQL e prese a chiamarsi
PHP/FI, dove FI sta per Form Interpreter (interprete di form), prevedendo
la possibilità di integrare il codice PHP nel codice HTML in modo da
semplificare la realizzazione di pagine dinamiche. In quel periodo, 50.000
domini Internet annunciavano di aver installato PHP.
A questo punto il linguaggio cominciò a godere di una certa popolarità tra i
progetti open source del web, e venne così notato da due giovani
programmatori: Zeev Suraski e Andi Gutmans. I due collaborarono nel
1998 con Lerdorf allo sviluppo della terza versione di PHP (il cui acronimo
assunse il significato attuale) riscrivendone il motore che fu battezzato
Zend da una contrazione dei loro nomi. Le caratteristiche chiave della
versione PHP 3.0 frutto del loro lavoro, erano la straordinaria estensibilità,
la connettività ai database e il supporto iniziale per il paradigma a oggetti.
Verso la fine del 1998 PHP 3.0 era installato su circa il 10% dei server web
presenti su Internet.
PHP diventò a questo punto talmente maturo da competere con ASP,
linguaggio lato server analogo a PHP sviluppato da Microsoft, e cominciò a
essere usato su larga scala. La versione 4 di PHP venne rilasciata nel 2000
e prevedeva notevoli migliorie. Attualmente siamo alla quinta versione,
sviluppata da un team di programmatori, che comprende ancora Lerdorf,
oltre a Suraski e Gutmans.
La popolarità del linguaggio PHP è in costante crescita grazie alla sua
flessibilità: nel Giugno 2001, ha superato il milione di siti che lo utilizzano.
Nell'ottobre 2002, più del 45% dei server Apache usavano PHP.
Nel gennaio 2005 è stato insignito del titolo di "Programming Language of
2004" dal TIOBE Programming Community Index, classifica che valuta la
popolarità dei linguaggi di programmazione sulla base d’informazioni
raccolte dai motori di ricerca.
Nel 2005 la configurazione LAMP (Linux, Apache, MySQL, PHP) supera
il 50% del totale dei server sulla rete mondiale.
1.12.2.
Caratteristiche:
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.
Certi costrutti derivati dal C, come gli operatori fra bit e la gestione di
stringhe come array, permettono in alcuni casi di agire a basso livello;
tuttavia è fondamentalmente un linguaggio di alto livello, caratteristica
questa rafforzata dall'esistenza delle sue moltissime API, oltre 3000
funzioni del nucleo base. PHP è 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 CURL, GD, Gettext, GMP, Ming,
OpenSSL e altro.
Fornisce un'API specifica per interagire con Apache, nonostante funzioni
naturalmente con numerosi server web. È anche ottimamente integrato con
il database MySQL, per il quale possiede più di un’API. Per questo motivo
esiste un'enorme quantità di script e librerie in PHP, disponibili liberamente
su Internet. La versione 5, comunque, integra al suo interno un piccolo
database embedded, SQLite.
Dispone di un archivio chiamato PEAR che mette a disposizione un
framework di librerie riusabili per lo sviluppo di applicazioni PHP e di
PECL che raccoglie tutte le estensioni conosciute scritte in C.
4. Realizzazione dell’applicazione
Nella realizzazione si mette in pratica tutto quello che è stato concepito in
fase di progettazione utilizzando le tecnologie prescelte, creando le
implementazioni necessarie alla realizzazione degli schemi, delle interfacce
e delle funzionalità viste nei capitoli precedenti.
Un importante punto da tenere presente è che l’applicazione viene integrata
nella rete del comune, che possiede già sistemi propri di autenticazione
dell’utente. Si può quindi tranquillamente assumere di disporre di tutte le
informazioni necessarie (come identità e gruppi di appartenenza) sugli
utenti che interagiscono col sistema.
1.13.
Tabelle del Database
In precedenza abbiamo visto la struttura generale del database, ora invece
mostriamo quali sono le tabelle nello specifico e come sono organizzate.
In figura 6 si può vedere lo schema della base di dati, in cui sono
evidenziate le tre macroaree presentate nel progetto. Le tabelle esterne ai
riquadri sono da considerarsi di servizio mentre quelle in arancio sono
esterne al database, poichè appartengono al DB di “Missioni Dipendenti”.
Vengono riutilizzate perché i dati che contengono sono necessari anche a
quest’applicazione e sarebbe stato ridondante replicarli.
FIGURA 6: LO SCHEMA DEL DATABASE
Le tabelle stato e transizione sono quelle che governano il motore a
workflow. La prima contiene tutti i possibili stati dell’applicazione e
specifica per ognuno di essi la relativa vista e modello dati (questo punto
verrà approfondito in seguito).
Transizione invece contiene tutte le transizioni tra i vari stati, indicando per
ognuna di esse lo stato iniziale e quello finale. Ulteriori informazioni
necessarie come le condizioni e le post-operazioni sono invece
memorizzate su file esterni, poiché avrebbero appesantito eccessivamente il
DB.
Andando ad analizzare la parte relativa alla gestione dei permessi, troviamo
la tabella Gruppo che contiene l’elenco dei gruppi logici interni
dell’applicazione (quelli elencati nella sezione 2.3.2). Le tabelle Associa
Gruppo e Permessi Utenti servono ad associare rispettivamente interi
gruppi utenti di dominio e utenti specifici ai gruppi interni
dell’applicazione. Infine Permessi Gruppi lega ognuno dei gruppi interni ai
rispettivi permessi sulle transizioni. Come si può notare ogni permesso è
legato a un gruppo interno. Se un utente possiede permessi specifici, li ha
comunque ottenuti attraverso l’associazione a un gruppo interno.
L’insieme di tabelle relative alle missioni è invece particolarmente
semplice.
Missione contiene tutte le informazioni generali relative alle missioni non
ancora archiviate (richiedente, responsabile, luogo, date d’inizio e fine,
scopo, eventuale anticipo, totale ore effettuate, mezzo usato e vari
timestamp per tracciare l’evoluzione e le modifiche.)
Tappe contiene invece le varie tappe compiute durante una missione ed è
legata a quest’ultima tramite un’associazione 1:N. Per ognuna di esse viene
indicata la città di partenza e di destinazione, il numero di km percorsi e il
giorno in cui è stata effettuata, oltre ad un indice che specifica l’ordine in
cui le tappe di una stessa giornata sono state percorse.
Missioni archiviate e tappa archiviate contengono praticamente le stesse
informazioni delle due tabelle precedenti. Il loro scopo è semplicemente
separare le missioni già archiviate da quelle ancora aperte, per alleggerire
l’esecuzione delle query. Le missioni archiviate, infatti, vengono consultate
molto più raramente, quindi sarebbe controproducente appesantire la
ricerca nella tabella missioni con dati non significativi.
Utenti serve a specificare il tipo di rimborso spese che deve essere
associato a un utente del dominio.
Mezzi personali associa agli utenti i mezzi di loro proprietà, ai fini del
calcolo del rimborso spese chilometrico.
Tipi spese e Status missioni sono degli elenchi utilizzati per convertire
alcuni nomi interni all’applicazione con nomi leggibili dall’utente. La
prima contiene le diverse voci presenti nelle note spese mentre la seconda
riporta i vari stati in cui si può trovare una missione.
Voci menu e gruppi menu servono a specificare quali transizioni devono
comparire nel menù laterale e in quale sezione di esso devono apparire.
Deleghe serve ad associare agli utenti le persone in vece di cui possono
agire.
Le tre tabelle rimanenti, Prezzi carburante, Città e Mezzi comune,
contengono rispettivamente l’elenco storico dei prezzi della benzina con
relativa data, l’elenco delle città che viene utilizzato nel calcolo dei km
delle tappe e infine l’elenco dei mezzi comunali.
1.14.
Struttura degli script
Al fine di creare un’applicazione web corretta e su cui si possa fare
facilmente manutenzione, si rivela di fondamentale importanza creare una
libreria di file che si occupi di gestire i vari servizi dell’applicazione.
I file principali dell’applicazione sono i seguenti:
- config.php. Contiene la configurazione dei vari settaggi dell’applicazione;
- database.php. Qui si trova la classe utilizzata per dialogare col database.
Contiene varie funzioni il cui scopo va dall’inserimento o modifica di
record all’estrazione di dati, sia di singoli campi che d’interi result set;
- funzioni.php. Raggruppa tutte le funzioni di utilità (dalla conversione date
alla creazione del menù);
- sendMailBif.php. Gestisce le funzioni per l’invio di e-mail;
- oggetto.php. Contiene una classe che rappresenta l’oggetto generico del
workflow;
- layout_principale.php. Questo file è alla base della creazione di una
pagina.
Sono inoltre presenti file che rappresentano ogni singola transizione,
modello dati o vista, suddivisi per tipo nelle rispettive cartelle.
1.15.
Implementazione del motore a workflow
Com’è stato precedentemente esposto, il motore a workflow si basa su stati
e transizioni. Ogni stato viene realizzato tramite un’istanza della classe
oggetto ed è caratterizzato da un modello dati e da una vista. Le transizioni
invece sono caratterizzate da uno stato iniziale e uno finale, oltre che da
eventuali condizioni e post-operazioni.
Le caratteristiche di questi oggetti, le singole transizioni e i singoli stati,
sono specificate all’interno dei rispettivi file, ad eccezione degli stati legati
alla transizione, che sono salvati sul DB, come specificato nella sezione
4.1.
Il modello dati contiene tutte le informazioni sugli oggetti trattati nella
pagina. Se, ad esempio, siamo in una pagina che visualizza il saldo di una
missione, il modello dati conterrà tutti i dati riguardanti le spese.
La vista invece contiene il codice P.H.P. caratteristico della pagina.
Com’è stato specificato precedentemente, più stati possono avere lo stesso
modello dati (o vista): un esempio è dato dalla pagina in cui si compila una
richiesta di missione e quella immediatamente successiva, dove vengono
riepilogate le informazioni appena inserite. Viste differenti ma stesso
modello.
Gli stati sono quindi associati a pagine, con la vista che decide l’aspetto e il
modello che regola i dati che vengono trattati.
Risulterà quindi abbastanza immediato il fatto che le transizioni, ovvero i
passaggi tra pagine (stati), vengano realizzate tramite i link.
Il funzionamento del motore a workflow nell’implementazione realizzata è
quindi il seguente:
Un utente si trova in una pagina (stato) e ha a disposizione numerosi link
(transizioni) tra cui poter scegliere. Quando clicca su uno di essi, la pagina
trasmette al server il nome della transizione che deve essere effettuata. Per
prima cosa viene effettuato un controllo dei permessi. In caso di esito
positivo, se tutte le condizioni della transizione sono verificate, si passa allo
stato successivo, determinato dalla transizione, dopo aver eseguito
eventuali post-operazioni. In caso le condizioni non siano verificate invece,
si rimane nello stato attuale. Una volta deciso quale sarà lo stato di
destinazione, il motore crea un nuovo oggetto, determinato dal modello
dati, che viene quindi passato alla vista per generare il codice della pagina.
In figura 7 è possibile vedere uno schema riassuntivo di questo
procedimento.
FIGURA 7: IL PASSAGGIO TRA UNO STATO E L’ALTRO.
1.16.
Le transizioni e la compatibilità con i browser
Un particolare interessante dell’implementazione è il metodo con cui viene
comunicato al server quale transizione deve essere eseguita.
Il problema, benché possa inizialmente sembrare banale, diventa evidente
quando si cerca di implementare questa comunicazione.
Com’è stato detto, quando si seleziona un link o un pulsante, si specifica
quale transizione s’intende eseguire. Questo avviene spedendo al server il
nome della transizione da eseguire, tramite un parametro della request.
Nel caso di un link il problema è d’immediata risoluzione, basta specificare
il nome nell’indirizzo del link, come parametro GET (es. index.php?
transizione=trans_init).
Il problema inizia a complicarsi nel caso di pulsanti, poiché non esistono
tag html che permettano di trasmettere nella request qualcosa di diverso
dalla scritta che appare sul bottone (la caption).
Volendo essere precisi, il tag button permetterebbe di fare ciò (la caption
infatti è ciò che viene racchiuso dal tag, mentre il valore trasmesso è
contenuto nell’attributo value), ma Internet Explorer ignora questa
differenza [tag button in IE] e trasmette comunque la caption. Per motivi di
compatibilità non si può quindi usare il tag button normalmente.
Non volendo visualizzare sul bottone il nome della transizione (che è nel
formato trans_nome, es. trans_archivia) la soluzione è usare il tag input e
sostituire il nome del bottone con il valore che vogliamo passare. Se ad
esempio vogliamo trasmettere il parametro di nome “transizione” con
valore “trans_nuova_richiesta”, ciò che scriveremo sarà nome
“trans_nuova_richiesta” con un valore qualsiasi.
In questo modo verrà trasmesso da entrambi i browser un campo nel
formato nome_transizione=X (dove X è il valore qualsiasi nel caso di
Firefox e la caption nel caso di IE).
Essendo tutti i nomi di transizione nel formato trans_nome, se non si riceve
dal client alcun campo chiamato “transizione”, se ne cerca uno che inizi per
“trans_”: quello è il valore desiderato.
Il problema però si complica ulteriormente nel caso ci si trovi ad avere più
tag di tipo button nella stessa form (ad esempio le pagine con le liste). Qui
emerge un secondo problema di IE: se sono presenti più bottoni in una
form, non viene trasmesso solamente il valore di quello che è stato cliccato,
ma di tutti. Diventa perciò impossibile per il server riconoscere qual è stato
premuto, se non ricorrendo ad artifici con il javascript.
La soluzione consiste nell’impostare l’ID di ogni bottone con un formato
standard, del tipo “button_XXX” dove XXX è il valore che vogliamo
trasmettere.
A questo punto, quando l’utente clicca sul bottone, si esegue una funzione
javascript che estrae XXX dall’ID e lo scrive in un campo hidden della
form prima di eseguire la submit.
1.17.
Missione: dalla richiesta all’approvazione
Vediamo ora nel dettaglio le varie fasi che caratterizzano una missione.
Premessa: nelle immagini seguenti l’header delle pagine è stato
tralasciato in quanto non significativo.
1.17.1.
Richiesta
In figura 8 possiamo vedere la schermata per la richiesta di una nuova
missione.
I campi che compaiono in questa pagina, come pure in tutte le altre,
dipendono dal modello dati sottostante.
Gli unici campi degni di nota sono i primi due:
- Utente richiedente è quello che l’applicazione vede come utente corrente
e si ottiene dal sistema d’impersonificazione, che lo riceve a sua volta dalla
sessione del browser;
- Responsabile è un menù a tendina che permette di scegliere il
responsabile a cui chiedere l’approvazione. La lista viene riempita con il
contenuto della tabella Responsabili del database, ordinato secondo il
campo indice.
Quando si seleziona avanti, tutti i campi vengono controllati alla ricerca di
errori tramite javascript (in ogni caso vengono comunque effettuati
controlli anche lato server). Se è tutto corretto, si arriva a una pagina di
riepilogo in cui si può confermare la richiesta, o tornare indietro nel caso si
vogliano apportare modifiche.
In caso di conferma, la richiesta passa al responsabile per l’approvazione.
Viene quindi spedita a quest’ultimo un’e-mail di notifica.
Nota: nonostante non venga più specificato in seguito, le e-mail di notifica
vengono generate anche per tutti degli stadi successivi.
FIGURA 8: NUOVA RICHIESTA
1.17.2.
Approvazione
Il responsabile, quando si collega, può vedere nel menù a sinistra eventuali
nuove richieste da approvare. Selezionando la voce apposita si apre la lista
delle richieste in attesa di approvazione, riportata in figura 9. La lista è
realizzata tramite un modello dati di tipo array che contiene oggetti di tipo
voce_lista, che vengono inseriti al momento della creazione del vettore e
riportano le informazioni principali.
Una volta selezionata una richiesta da approvare si apre una pagina in cui
vengono riepilogate le informazioni sulla missione e viene data la
possibilità di approvarla o rifiutarla. Nel secondo caso è prevista
un’ulteriore pagina per specificare il motivo del rifiuto.
Se la missione prevede un anticipo, a questo punto la richiesta arriva
all’economato che si occuperà di elargire l’anticipo.
FIGURA 9: LISTA DELLE RICHIESTE IN ATTESA DI APPROVAZIONE
1.17.3.
Compilazione dettagli
Una volta che la missione è stata svolta, si può passare alla pagina di
compilazione dettagli, visibile in figura 10.
La prima parte riguarda l’inserimento delle tappe percorse.
Quando si seleziona il pulsante “Aggiungi tappa” i valori inseriti nei due
campi di testo vengono copiati nella lista sovrastante, tramite una modifica
dinamica del codice HTML della pagina, realizzata tramite javascript.
Sempre grazie ad esso, inoltre, è possibile eliminare un elemento
dall’elenco o riordinare le tappe semplicemente trascinandole col mouse.
La parte centrale invece consiste nell’inserimento dei totali delle spese,
divisi per categorie (specificate nella tabella “Tipi spese”).
Il campo “Mezzo utilizzato” serve per specificare il veicolo impiegato
durante la missione. La lista mostra l’elenco di tutti i mezzi comunali ed
eventualmente pure dei mezzi personali (questo nel caso sia stato
selezionato il campo “mezzo proprio” al momento della richiesta).
I due campi rimanenti, infine, sono abbastanza immediati. Il primo serve a
indicare la durata in ore della missione mentre il secondo permette di
specificare la modalità di rimborso. Nell’esempio è presente una sola voce
poiché se si è richiesto un anticipo il rimborso deve essere eseguito
dall’economato.
FIGURA 10: COMPILAZIONE DETTAGLI
1.17.4.
Verifica spese e saldo
Questa pagina, riportata in figura 11, presenta un riepilogo dei dati della
missione e fornisce ai responsabili del saldo la possibilità di modificare le
voci spesa, nel caso non siano corrette.
In caso di modifiche, vengono salvati anche i valori originali.
Una volta selezionato avanti, si passa a una pagina di conferma, visibile in
figura 12, in cui viene visualizzato l’ammontare da erogare o ricevere. A
questo punto si può quindi stampare un cedolino cui attaccare eventuali
scontrini, tornare alla pagina precedente o confermare le note spese.
FIGURA 11: IL SALDO
FIGURA 12: CONFERMA DEL SALDO
1.17.5.
Chiusura
In questa schermata, visibile in figura 13, vengono riepilogate tutte le
informazioni sulla missione. In caso sia necessario effettuare modifiche alle
note spese o alle tappe, selezionando l’apposito pulsante si arriva in una
pagina identica a quella vista nella compilazione dei dettagli. Selezionando
conferma, invece, la missione viene chiusa.
FIGURA 13: IL RIEPILOGO TOTALE DI UNA MISSIONE PRIMA DELLA CHIUSURA.
1.17.6.
Archiviazione
L’ultimo stadio di una missione è l’archiviazione. Prima di essa vengono
visualizzati un’ultima volta i dati della missione stessa, con una pagina
identica alla precedente. L’unica differenza è che in caso sia stato utilizzato
un mezzo personale, e sia quindi necessario un rimborso delle spese del
carburante, appare un riepilogo delle caratteristiche del mezzo e in fondo
un campo in cui inserire il prezzo al km della benzina. Il campo è
precompilato se l’utente che ha svolto la missione è un consigliere, poiché
essi hanno un rimborso fisso al km, mentre va inserito a mano dalla
segreteria, utilizzando le tabelle ACI e i dati del mezzo, nel caso l’utente
sia un assessore. Un esempio di quest’ultimo caso è visibile in figura 14.
FIGURA 14: ARCHIVIAZIONE CON INSERIMENTO DEL COSTO DELLA BENZINA
Una volta selezionato il pulsante “Archivia”, l’applicazione procede a
spostare il record relativo alla missione sulla tabella missioni archiviate e a
cancellarlo da quella originale. Un’operazione analoga viene eseguita per le
tappe, salvando inoltre per ognuna di esse il relativo prezzo della benzina
come campo aggiuntivo del record.
1.18.
Report
In figura 15 è riportato un esempio di report finale delle missioni eseguite,
in questo caso riferito a una singola persona. I dati visualizzati sono tutti
salvati direttamente nel database, all’interno delle tabelle “missioni
archiviate” e “tappe archiviate”, ad eccezione delle ultime tre colonne che
vengono calcolate al momento della creazione della pagina.
FIGURA 15: UN ESEMPIO DI REPORT
1.19.
Amministrazione
La sezione di amministrazione prevede quattro differenti funzioni:
- eliminazione di una missione;
- associazione di un gruppo di dominio a un gruppo interno (modifica
della tabella “Associa Gruppo”);
- associazione di un gruppo interno a un utente (modifica della tabella
“Permessi utenti”);
- gestione delle deleghe (modifica della tabella “deleghe”).
In figura 16 è possibile vedere un esempio della schermata di assegnazione
di un gruppo interno a un utente.
FIGURA 16: UNA SCHERMATA DI AMMINISTRAZIONE
1.20.
Test di servizio
Analisi e test sul funzionamento dell’applicazione sono stati svolti
regolarmente durante l’intero stage, permettendo di risolvere i problemi
man mano che sorgevano invece di portarli sino alla fine.
Sono stati inoltre svolti numerosi test per garantire la compatibilità sui vari
browser, che talvolta presentano comportamenti diversi, sia nei riguardi
della rappresentazione grafica che della gestione di alcuni campi delle
form.
Al termine del tirocinio è stato comunque svolto un test globale e
l’applicazione ha dimostrato di funzionare come previsto.
5. Conclusioni
Questa tesi è il frutto di un progetto svolto nell’ambito di un tirocinio
effettuato presso il Comune di Cento, in cui è stata creata l’applicazione
Web “Missioni Amministratori”.
Lo scopo, che era di permettere ai vari soggetti coinvolti nel rimborso spese
di assessori e consiglieri di compilare la modulistica necessaria attraverso
un’interfaccia web, anziché tramite moduli cartacei, si può considerare
raggiunto.
Uno dei principali ostacoli è stata l’introduzione del motore a workflow,
specialmente per l’iniziale difficoltà a capire cosa andasse rappresentato
come stato.
Una volta reso operativo però, si è dimostrato di grande aiuto nel rendere
l’applicazione molto flessibile, sia in termini di flusso delle azioni che di
facilità di modifica, grazie a una struttura componibile a più livelli.
La scelta si è in seguito dimostrata vincente, quando i requisiti e le
specifiche del progetto hanno subito modifiche a uno stadio già avanzato di
realizzazione, cosa che ha sottolineato l’enorme importanza della
progettazione di una struttura elastica e facilmente adattabile. In mancanza
di essa le ripercussioni sullo sviluppo dell’applicazione sarebbero state
gravi e avrebbero comportato un notevole lavoro di correzione e
adattamento.
Un’ulteriore difficoltà era stata inizialmente data dalla decisione di
utilizzare il javascript solamente per il controllo dei campi, poiché
operazioni come inserimento e cancellazione delle tappe avrebbero causato
un aumento del numero di stati da gestire e una complicazione degli stessi.
Questa limitazione è stata però rimossa in seguito, quando si è costatato che
senza javascript l’errato comportamento di Internet Explorer con il tag
button avrebbe reso, se non impossibile, perlomeno molto arduo proseguire
nel progetto seguendo il percorso tracciato sino a quel punto.
In futuro, se si riterrà opportuno modificare la sequenza delle operazioni,
sia alterando l’ordine che aggiungendo o eliminando alcuni stadi, grazie al
motore a workflow basterà agire sulla catena degli stati.
La struttura di base dell’applicazione è inoltre altamente riusabile e
permetterebbe, se si volesse, di ricreare l’applicazione “Missioni
Dipendenti” con la nuova, e più stabile, struttura sottostante.
Questo progetto ha permesso di approfondire alcuni argomenti incontrati in
ambito universitario, come la programmazione in P.H.P., descritta in parte,
e il javascript, già utilizzato nel corso di Ingegneria dei Sistemi Web, ma
qui utilizzato più a fondo. In ogni caso, l’istruzione e la conoscenza
trasmesse dall’Università hanno permesso di apprendere e approfondire
rapidamente tutto ciò che non era stato visto in precedenza.
Il tirocinio mi ha fornito un’esperienza molto interessante, che mi ha
permesso di mettere alla prova le mie capacità con un progetto reale,
sicuramente più vicino al mondo del lavoro rispetto alle esperienze fatte a
lezione, oltre ad avermi dato modo di ampliare le mie conoscenze.
Mi ha inoltre consentito di comprendere meglio l’importanza di un buon
lavoro di progettazione prima di iniziare a scrivere il codice.
Infine, ho avuto modo di lavorare insieme a persone competenti che mi
hanno offerto pieno supporto e disponibilità, oltre ad un ambiente di lavoro
sereno. Ringrazio in particolare Michele Tedeschi per i consigli e le
indicazioni che mi ha fornito durante le varie fasi del progetto.
6. Riferimenti
[Workflow]
http://www.wfmc.org/
[Server Web Apache]
http://www.apache.org/
[DBMS MySQL]
http://www.mysql.com/
[Linguaggio SQL]
http://www.wiscorp.com/
SQLStandards.html
[Linguaggio HTML]
http://www.w3.org/html/
[W3C]
http://www.w3.org/
[CSS]
http://www.w3.org/Style/CSS/
[tag button in IE]
http://www.sitehatchery.com/blog/
index.php/html-button-tag-and-iecompatibility
7. Indice delle figure
Figura 1: l’evoluzione di una missione, dalla richiesta all’archiviazione.....7
Figura 2: la gestione dei permessi...............................................................11
Figura 3: la struttura del database................................................................12
Figura 4: l’interfaccia dell’applicazione......................................................13
Figura 5: un confronto tra le due applicazioni: in alto “Missioni
Dipendenti” e in basso “Missioni Amministratori”....................................14
Figura 6: lo schema del database.................................................................22
Figura 7: il passaggio tra uno stato e l’altro................................................26
Figura 8: nuova richiesta.............................................................................29
Figura 9: lista delle richieste in attesa di approvazione...............................29
Figura 10: Compilazione dettagli................................................................30
31
Figura 11: il saldo........................................................................................31
31
Figura 12: conferma del saldo.....................................................................31
Figura 13: il riepilogo totale di una missione prima della chiusura............32
Figura 14: archiviazione con inserimento del costo della benzina..............33
Figura 15: un esempio di report..................................................................34
Figura 16: una schermata di amministrazione.............................................35