La soluzione fornita prevede 3 moduli fondamentali:VRTPattugliaCentrale

VRT:Si esegue il deploy di questo modulo su ogni varco del sistema, così che ogni varco possa essere registrato da una pattuglia, registrare i flussi di traffico, decidere quando scattare la foto alla targa e inviare le notifiche alla centrale e alla pattuglia.(molteplicità n)

Pattuglia:Si esegue il deploy di questo modulo so ogni dispositivo in dotazione alla pattuglia, così che possa con lo stesso registrare la sua presa posizione al VRT, ricevere segnalazioni dal VRT e reinviare i dati del fermo alla centrale. (molteplicità n)

Centrale:Questo modulo viene deployato sul server centrale essendo un cluster di macchine gestisce le code di segnalazione parallelizzando le richieste di contravvenzione sulle varie macchine della centrale configurate.

VRT dettagli:

L'architettura hw del vrt potrebbe essere composta da un sistema embedded che registra i flussi di traffico attraverso i sensori collegati. I segnali che riceve i vrt sono noti e quindi gestiti. Questa architettura è collegata anche alla rete gprs per l'invio di dati alla pattuglia e per l'invio di dati alla centrale (simil sms). Ha inoltre un database connesso in rete adsl per le ricorrenti interrogazioni sui dati di flusso di traffico per le indagini ambientali.

PATTUGLIA dettagli:

L'architettura hw della pattuglia potrebbe essere un semplice smartphone con sistema operativo android sul quale viene deployata un'applicazione fatta ad hoc, che riceve notifiche da VRT in rete gprs, con un meccanismo simile agli sms, un'applicazione fatta ad hoc per l'invio dei dati del conducente (è una semplice form, potrebbe anche essere un pagina internet in uso alla polizia..) e con un'altra applicazione fatta ad hoc registra la sua presenza presso il VRT.

CENTRALE dettagli:

L'architettura hw della centrale potrebbe essere un server che gestisce le code delle richieste smistando sulle macchine con un meccanismo di tipo client-server

E il tutto potrebbe essere sviluppato sulla piattaforma j2ee in modo da avere le informazione fruibili attraverso una semplice interfaccia web con gestione di notifiche simile al sistema feed rss o facebook (facebook gestisce la ricezione di informazioni via sms).

Le scelte effettuate sono giustificate dal fatto che i dati da eleaborare sebbene possano essere in grande quantità, possono essere facilmente modellati come semplici stringhe o array di stringhe, che sono ottimamente gestite e con costi accettabili con le scelte fatte.

CASE STUDY

Si vuole abilitare l'accesso ai dati del sistema PRA al sistema SRT qui in analisi.Il fine ultimo di questa integrazione è il recupero dei dati personali del possessoredi un veicolo di cui si conosce la targa e di cui è stata segnalata dal sistema SRTun infrazione del codice della strada a una certa data.il recupero di tali dati, consentirà ai fruitori dei servizi di SRT di produrre una congruacontravvenzione e di inviare alla destinatario corretto tale contravvenzione.E' chiaro fin dalle prime battute che i punti cruciali di questa integrazione saranno la precisione dei dati personali e la sicurezza con cui si potrà fruire di questo servizio.

25

soluzione EIILa soluzione che si sceglie di fornire è di tipo EII in

quanto:

Fornisce una integrazione virtuale dei db lasciando tutti i dati necessari “al loro posto”.

Fornisce un sistema onDemand, quindi dinamico e sempre con i dati aggiornati.

Non è molto costoso in termini di sviluppo, mantenimento e apprendimento (web service).

Supporta eterogeneità fra schemi e dati Con un approccio top-down è possibile

definire facilmente il metodo con cui estrarre i dati necessari (web service).

soluzione ETL

La soluzione che si sceglie di fornire è di tipo ETL:

Fornisce una integrazione fisica dei db. Questa è un'integrazione sicura dal punto

di vista dell'integrità del dato. E' però costosa dal punto di vista delle

operazioni da compiere per implementarla (in primis trasformare i data source in un formato comune prima del loading)

Vanno fatti aggiornamenti periodici delle warehouse.

Si hanno i seguenti schemi:

Varco(idVarco, posizione);FlussoTraffico(idFlussoVarco, idVarco,

timestamp, timestampPrimaFotocellula, timestampSecondaFotocellula);

Centralina(idCentralina, latitudine, longitudine);DatoAmbientale(idDatoAmbientale, idTipo,

idCentralina, data, timestamp, concentrazione);

Vogliamo una view che mappi i dati di traffico di una certa posizione e i dati ambientali registrati presso quella posizione il tutto in un dato periodo di tempo.

Varco(idVarco, posizione);FlussoTraffico(idFlussoVarco, idVarco, timestamp, timestampPrimaFotocellula, timestampSecondaFotocellula);

Centralina(idCentralina, latitudine, longitudine);DatoAmbientale(idDatoAmbientale, idTipo, idCentralina, data, timestamp, concentrazione);TipoDatoAmbientale(idTipo, nome, concentrazioneSoglia);

Select count(ft.idFlussoTraffico) from FlussoTraffico ft, Varco v where ft.idVarco = v.idVarco and v.posizione = 'x' and ft.timestamp between 'hh:mm' and 'hh:mm'

Select avg(da.concentrazione), tda.nome, c.latitudine, c.longitudine, da.timestamp trunc 1 from DatoAmbiente da, Centralina c, TipoDatoAmbientale tda where c.idCentralina = da.idCentralina and c.latitudine between 'x-200' and 'x+200' and c.longitudine between 'x-200' and 'x+200' and da.timestamp between 'hh:mm' and 'hh:mm' and da.idTipo = tda.idTipo and tda.nome='tipo' group by (tutti i campi)

Select 0 as concentrazione, count(ft.idFlussoTraffico) as flusso_traffico from FlussoTraffico ft, Varco v where ft.idVarco = v.idVarco and v.posizione = 'x' and ft.timestamp between 'hh:mm' and 'hh:mm'; (S1)

Select da.concentrazione as concentrazione, tda.nome as nome, c.latitudine as latitudine, c.longitudine as longitudine, (da.timestamp as 'hh') as ora, 0 as flusso_traffico from DatoAmbiente da, Centralina c, TipoDatoAmbientale tda where c.idCentralina = da.idCentralina and c.latitudine between 'x-200' and 'x+200' and c.longitudine between 'x-200' and 'x+200' and da.timestamp between 'hh:mm' and 'hh:mm' and da.idTipo = tda.idTipo and tda.nome='tipo';(S2)

Create view as AnalisiStatistica(Select sum(concentrazione) as Concentrazione, sum(flusso_traffico)FlussoTraffico, max(nome) as tipo, max(latitudine) as lat, max(longitudine) as long, max(ora) as ora , fromS1 union S2);

Con i vincoli di integrità inseriti a monte si ottiene una vista exact, che è l'unica cosa ammissibile per studi di carattere matematico/statistico.I parametri di posizione e ora vanno impostati a monte.

AnalisiStatistica(ora, nome, lat,long,data, Concentrazione,FlussoTraffico);

Interrogazione:Quantità di PM10 nella zona navigli alle ore 10 del giorno 20/1/2011.Prima di procedere con al query sulla vista è necessario tradurre zona navigli in coordinate geografiche (uso google maps).

Select * from AnalisiStatistica where lat = 'x' and long = 'y' and ora = 't' and data = '20/01/2011 as dd/MM/yyyy' and tipo = 'PM10';

I campi lat long data e tipo avranno bisogno dell'unfolding sulle tabelle di S2, mentre flussoTraffico su S1.

I problemi di questa integrazione potrebbero essere la diversa modellazione dei campi che localizzano le centraline studiate, i campi relativi alle tempistiche, qui per semplicità indicati con timestamp, (se un db è oracle uno mySql, non è detto che abbiano gli stessi valori reali).Detto questo si prevede di creare un'integrazione di tipo EAI, che risolve a monte questi problemi di compatibilità istruendo il sistema con una procedura di interpretazione prestabilita, ogni volta che viene lanciata la ruotine di analisi dei dati ambientali.