Indice. Università degli studi di Ferrara

Transcript

1 Università degli studi di Ferrara Indice 1. Introduzione Progetto dell'applicazione Web "Missioni Amministratori" Scopo dell applicazione Contesto Specifiche Gli stadi di una richiesta di missione Gruppi Utente Architettura Gestione dei permessi Architettura del database Struttura delle pagine Web Tecnologie impiegate Server Web Apache MySql HTML e CSS Javascript P.H.P Storia: Caratteristiche: Realizzazione dell applicazione Tabelle del Database Struttura degli script Implementazione del motore a workflow Le transizioni e la compatibilità con i browser Missione: dalla richiesta all approvazione

2 Università degli studi di Ferrara Richiesta Approvazione Compilazione dettagli Verifica spese e saldo Chiusura Archiviazione Report Amministrazione Test di servizio Conclusioni Riferimenti Indice delle figure

3 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

4 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.

5 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 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 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.

6 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 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 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.

7 FIGURA 1: L EVOLUZIONE DI UNA MISSIONE, DALLA RICHIESTA ALL ARCHIVIAZIONE.

8 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.

9 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 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 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.

10 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 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.

11 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):

12 - 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à.

13 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

14 FIGURA 5: UN CONFRONTO TRA LE DUE APPLICAZIONI: IN ALTO MISSIONI DIPENDENTI E IN BASSO MISSIONI AMMINISTRATORI.

15 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 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 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 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

16 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 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.

17 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 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.

18 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 , 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

19 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.

20 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 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, 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.

21 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 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.

22 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 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

23 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.

24 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 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 ; - 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.

25 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.

26 FIGURA 7: IL PASSAGGIO TRA UNO STATO E L ALTRO 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.

27 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 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 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.

28 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 di notifica. Nota: nonostante non venga più specificato in seguito, le di notifica vengono generate anche per tutti degli stadi successivi.

29 Approvazione FIGURA 8: NUOVA RICHIESTA 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 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

30 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 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

31 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

32 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 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.

33 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.

34 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 Amministrazione FIGURA 15: UN ESEMPIO DI REPORT 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.

35 1.20. Test di servizio FIGURA 16: UNA SCHERMATA DI AMMINISTRAZIONE 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.