La modalità di lavoro off-line

In questa sezione si presentano le funzionalità offerte dal sistema web Sirea a sostegno delle effettive operazioni di revisione e documentazione della stessa relativa alle liste, affidate agli ufficiali d’anagrafe dei comuni, intestatari dell’onere di revisione.

Per assolvere a tali scopi attraverso l’applicativo web Sirea, appositamente predisposto, sono offerte tre tipologie di liste: la lista degli individui presenti in Lac ma non censiti (L2), la lista degli individui censiti ma non presenti in Lac (L3) e la lista degli individui censiti al medesimo o ad altro indirizzo, ma eliminati dalla popolazione legale perché considerati dei duplicati di altri individui censiti in un altro comune (L1-L4 de-duplicati).

Ciascun individuo, in ognuna delle tre liste, è caratterizzato da informazioni anagrafiche e da informazioni che documentano la sua effettiva posizione nell’a-nagrafe comunale ritenuta di appartenenza. Entrambe le tipologie di informazioni sono sottoposte a revisione da parte degli intestatari di tale obbligo. Nello spe-cifico, attraverso l’applicativo web è possibile comunicare all’Istat eventuali mo-difiche alle informazioni anagrafiche associate a ciascun individuo sottoposto a revisione, così come confermare o meno la presenza dei requisiti alla base dell’in-serimento dello specifico individuo nella lista anagrafica interessata e, quindi, le motivazioni alla base di tale dichiarazione. È onere del comune riportare nei propri sistemi informativi tali esiti. L’applicativo web predisposto, abilitando l’operatore comunale allo scarico delle liste individuali a valle delle operazioni di revisione, di fatto supporta gli addetti e i responsabili comunali nell’assolvimento di tali compiti.

Alla luce del quadro di riferimento sopra delineato, si osserva innanzitutto che il sistema software predisposto deve interfacciarsi con l’insieme delle realtà comunali presenti nel territorio, ognuna quindi esibente una specifica dimensione in termini di popolazione, un diverso grado di maturità tecnologica, nonché di risorse tecniche ed economiche a disposizione.

La variegata natura degli attori interagenti col sistema ha reso necessario progettare un applicativo web multi-modale, ovvero che offrisse agli utenti del sistema diverse modalità di lavorazione delle liste. Nello specifico, accanto a una modalità di lavorazione in linea, attraverso delle maschere web che permettono a ciascun responsabile, ovvero addetto alla revisione, di visionare le liste individuali offerte al Comune e quindi di accedere a un’area applicativa dedicata alla lavora-zione dei singoli individui, il sistema software permette di inviare massivamente le liste individuali con le informazioni relative allo specifico esito dell’operazione di revisione relative al singolo individuo.

Nello specifico, le maschere in linea sono basate sul paradigma architettura-le descritto nelarchitettura-le Sezioni precedenti (i.e. Struts2, Spring, Hibernate), attraverso di esse la ricerca dei cittadini può essere effettuata a partire da criteri di ricerca basati sul territorio o su dati anagrafici (codice fiscale, cognome e nome, codice famiglia o convivenza, codice questionario del censimento). Gli individui corri-spondenti ai filtri di ricerca vengono mostrati in una lista da cui è possibile acce-dere al dettaglio di ognuno. La pagina che viene presentata all’operatore è quindi suddivisa in due aree di lavoro:

• l’area anagrafica;

• l’area revisione individuo.

Per quanto concerne la modalità di invio massivo dei dati, si evidenzia che tale modalità di lavoro sostiene primariamente le operazioni di revisione effettua-te da pareffettua-te di Comuni di grandi dimensioni, i quali hanno un numero di casi più elevato da sottoporre a revisione. Gli stessi, nella maggior parte dei casi, ester-nalizzano numerose attività informatiche, ricorrendo all’intervento di specifiche software house. In tal caso, l’utilizzo di liste caricabili all’interno del sistema, già popolate con le informazioni di revisione, appare essere lo strumento più conso-no per raccogliere i dati di interesse. Tuttavia, nei fatti, anche Comuni più piccoli sono ricorsi a tale modalità. A tal proposito, si faccia riferimento alla distribuzione del numero di comuni che hanno fatto ricorso all’invio massivo delle informazioni di revisione rispetto alle classi di ampiezza demografica (Tavola 4.1).

La funzionalità di gestione massiva delle liste revisionate si basa sulla tecno-logia Spring batch. Tale framework permette di gestire processi di estrazione, tra-sformazione e caricamento dei dati acquisiti tramite liste testuali in diversi formati (.csv, .xls), registrando le informazioni individuali attraverso un tracciato record standard con codifica posizionale. Il tracciato record in esame risulta costituito da un insieme di campi suddivisi in due aree, un primo insieme di campi si riferisce alle informazioni anagrafiche, mentre un secondo insieme di campi si riferisce alle informazioni che descrivono la posizione anagrafica individuale, alla stessa stregua dell’organizzazione logica dell’area di lavoro predisposta nelle maschere in linea. Il processo di trattamento dei suddetti record individuali prevede diverse fasi, come esemplificato di seguito.

Nella figura 4.12 viene stilizzata l’architettura propria di un batch secondo Spring, la quale di fatto è quella tipica di un comune processo di Etl (Extract Transform and Load).

Nello specifico, un batch può essere definito come un job, gestito da un

re-pository, composto da n-step, ognuno dei quali può eseguire una fase di lettura,

di processamento e di scrittura. In particolare, il motore di elaborazione di Spring Batch effettua su ogni record individuale presente nel file inviato, basato sul trac-ciato record delineato in precedenza, rigorosi controlli sintattici e semantici e, in caso di risultanze positive, carica nella base dati le informazioni individuali ana-Tavola 4.1 - Numero di comuni che sono ricorsi all’upload (valori assoluti e percentuali)

CLASSE DI AMPIEZZA DEMOGRAFICA

Comuni

Valori assoluti Valori percentuali

Fino a 5.000 709 12,0 5.001-20.000 176 9,0 20.001-50.000 57 16,0 50.001-100.000 32 34,0 100.001-150.000 9 43,0 Oltre 150.000 19 76,0 Totale 1.002 12,4

grafiche e di posizione anagrafica comunicate. Nel caso in cui anche una sola re-gola di validazione sia violata, il sistema rifiuta l’intero record individuale. Il siste-ma, quindi, elabora una lista di record rigettati, corredata con l’indicazione della regola di controllo violata per ciascun record. L’esito del processo di acquisizione viene comunque comunicato attraverso e-mail al responsabile della revisione e, qualora presente, la lista dei record scartati viene allegata alla suddetta e-mail.

La figura 4.13 mostra uno schema esemplificativo del processo sopra delineato.

Job launcher Job ^{1 n} Step

Reader Writer Processor Job repository 1 1 1

Figura 4.12 - Architettura di un batch secondo Spring

Nel processo sopra descritto le transazioni sono gestite a livello di step, e comunque basandosi su un gestore delle transazioni dedicato, separato da quello che si occupa di gestire le transazioni dovute all’interazione in linea con l’appli-cativo web. In tal modo, l’utente dell’applil’appli-cativo non deve aspettare l’esito dell’o-perazione di invio e trattamento della lista di interesse, ma può utilizzare altre funzionalità offerte dall’applicazione web. In ultimo, si evidenzia che la tecnolo-gia Spring Batch permette, altresì, di lavorare in un contesto in cui il principio ispiratore risulta essere quello del cosiddetto Inversion Of Control. Tale paradig-ma architetturale descrive di fatto un’architettura software nel quale il flusso di controllo è invertito rispetto alla programmazione procedurale: in particolare, le classi che implementano la logica di business dell’applicazione sono mantenute separate, disaccoppiate e le eventuali dipendenze non sono scolpite all’interno del codice, ma sono iniettate da un ambiente esterno tramite contratti definiti. In tale contesto Spring utilizza Dependency Injection quale tecnica con la quale è possibile implementare il paradigma di Inversion Of Control.