Sistema di Gestione e Ottimizzazione delle Pattuglie di Polizia sul Territorio

abstract

Descrizione

Tutti gli organi di polizia, in base al numero di abitanti presenti sul territorio, hanno un sostanzioso numero di operatori/agenti che vigilano. Prendiamo per esempio l'organo di Polizia Municipale, oltre ad avere il dovere di controllare il rispetto del codice della strada, ha innumerevoli svariati compiti, come far fronte gli esposti del cittadino o intervenire in caso di un imprevisto sulla città, come per esempio un incidente. Ogni pattuglia sulla strada, composta tipicamente da un minino di 2 ad un massimo di 3 agenti, sono affiancate, tramite il controllo radio, dalla Centrale Operativa presente all'intero del comando di Polizia. La Centrale invia le varie pattuglie sui vari interventi/esposti. Le pattuglie, giornalmente, oltre a rispondere alla Centrale Operativa, eseguono i cosiddetti "ordini di servizio" dati dai coordinatori di livello maggiore. Il sistema che si vuole realizzare consente di facilitare il lavoro della Centrale Operativa per quanto riguarda l'individuazione delle pattuglie da mandare sui vari interventi, la possibilità di avere "in tempo reale" la documentazione realizzata dalle varie pattuglie, ancor prima che l'orario di servizio di queste ultime sia terminato. Invece, per quanto riguarda le pattuglie, consente di poter ricevere le informazioni dalla centrale in maniera più dettagliata, per quanto riguarda la locazione e il tipo di intervento, e soprattutto consente di velocizzare le pratiche che ogni pattuglia è tenuta a fare per qualsiasi azione che essa compie e di poterla condividere con la centrale ancora prima della fine del turno di lavoro. Il sistema dovrà quindi essere composto dalle seguenti parti:
  • Lato Centrale Operativa:
    • Ogni operatore della Centrale è tenuto ad effettuare una identificazione al momento dell'inizio del proprio turno di lavoro, in questo modo i superiore hanno la possibilità di visualizzare il lavoro effettuato e soprattutto da chi.
    • La Centrale ha una visione globale della localizzazione delle pattuglie di turno e soprattutto della disponibilità di queste ultime a rispondere ad una chiamata della Centrale (es. se una pattuglia è impegnata su un incidente, non potrà essere mandata su un altro intervento)
    • Gli operatori della Centrale hanno la possibilità di visualizzare la documentazione compilata dalle pattuglie.
    • Fornisce una lista in automatico delle pattuglie da tenere in considerazione per l'assegnamento dei vari interventi, tenendo conto delle posizione delle pattuglie e del "componente umano", cioè chi è in servizio su ogni pattuglia.
  • Lato Pattuglia:
    • Sfrutta il sistema GPS del dispositivo per fornire la propria posizione.
    • Permette di segnalare il proprio "stato", cioè se la pattuglia è impegnata su un intervento oppure è disponibile (detto anche "normale controllo di vigilanza").
    • Durante o alla fine di un intervento permette di compilare i vari "Rapporti di Servizio" che verranno sincronizzati con la Centrale in modo tale da vedere l'operato delle varie pattuglie ancora prima della fine del turno di servizio.

Analisi dei Requisiti

Glossario

TERMINE
DESCRIZIONE
Agente Qualunque persona fisica che lavora presso l’organo di Polizia Municipale, il quale svolge un servizio per la pubblica amministrazione.
Pattuglia “Squadra” di 2 o 3 agenti che svolgono il proprio servizio sul territorio.
Reparto I reparti sono “sottinsiemi” dell’organo di polizia, dove ognuno dei quali a determinati compiti da svolgere. I diversi agenti sono assegnati ai reparti. I reparti consentono di distribuire al meglio i diversi servizi che l’organo di polizia deve compiere.
Centrale Operativa Luogo dove gli agenti assegnati al reparto “Centrale Operativa” svolgono il ruolo di coordinazione degli agenti degli altri reparti che lavora sul territorio. Assegnazione del servizio da parte dell’agente della centrale alla pattuglia è determinata anche dal tipo di reparto a cui appartiene la pattuglia.
Turno Arco dell’orario di servizio nel quale la pattuglia fornisce una servizio. Es. Turni: mattina, pomeriggio, sera e notte.
Evento Qualsiasi servizio messo in pratica da un agente facente parte di una pattuglia.
Intervento Servizio che la pattuglia deve svolgere su “richiesta” della Centrale Operativa.

Analisi dei Casi d'Uso

Dalla descrizione generale per problema, sono emersi i seguenti casi d’uso:UseCasesv1.jpg

Scenari

v1Scenari.pdf

Modello dei Dati del Sistema

Dopo un’analisi accurata della realtà da descrivere e le principali funzionalità del sistema, esplicitate negli “Scenari” visti precedentemente, è stato progettato il seguente modello concettuale: ERPM.jpgDopo aver preso informazioni e fatto uno studio dettagliato della realtà, si è cercato di modellare tutti gli aspetti dell’ambiente che si è preso in considerazione, cioè un qualsiasi Organo di Polizia Municipale. Molti di tali aspetti potrebbero sembrare inutili, per il sistema che si vuole realizzare, essi però sono stati pensati per lo sviluppo di altre funzionalità o sistemi da sviluppare in futuro.

Requisiti non Funzionali

Oltre ai requisiti funzionali di tipo generale, connessi ad ogni “buon codice”, vi sono requisiti non funzionali che è bene tenere in considerazione in questo sistema:
  • Affidabilità: il sistema deve avere il livello di affidabilità alto, per garantire l’integrità del lavoro degli utenti che utilizzano l’applicazione.
  • Sicurezza: il sistema deve prevedere una corretta politica di gestione degli account e degli accessi, questo per mantenere la riservatezza su dati sensibili e sulla documentazione di lavoro.
  • Efficienza: al sistema è richiesta l’interazione con un numero limitato di utenti (mediamente 10 utenti), detto questo si richiedono vincoli di qualità di connessione e tempi di risposta mediamente nell’ordine dei 1-5 sec.
  • Scalabilità: in base alle necessità degli utenti finali, le quali possono cambiare nel tempo per motivi di forza maggiore, il sistema deve essere progettato in modo da consentire l’aggiunta di funzionalità.
  • Generalità: il dominio dei dati del sistema è stato progettato ad “hoc” per permettere l’utilizzo anche da parte di eventuali altre applicazioni future.
  • Usabilità: L’applicazione deve essere di facile e di veloce utilizzo, per aggevolare il lavoro dell’utente finale.

Architettura del Sistema

Il seguente schema da un’idea di massima di come dovrebbe essere la struttura generale del sistema.ArchitetturadelSistema.jpgDallo schema vi evince che:
  • per la comunicazione fra dipositivi/client esterni e Server, visto il servizio principale scambio di informazioni, si è scelto di utilizzare il protocollo HTTP.
  • dispositivi/client esterni possono avere una locazione che non coincide con l’applicazione server.
  • è presente un DBManager che consente l’interazione fra le varie parti del sistema e il DBMS.
  • requestPosition è un componente “che vive di vita propria”, che ha il compito di avviare la richiesta periodica della posizione (in termini di latitudine e longiture) ai dispositi al momento attivi.

Architettura dei Componenti del Sistema

In questa sezione vengono trattati più in particolari l’architettura dei principali componenti del sistema e il loro modo di interagire. Prima però viene introdotto la modellazione del dominio del sistema, in modo da rendere più chiaro la tipologia dei dati che il sistema tratta.ModelPosition ModelPosition.jpgLa posizione di un dispositivo rappresenta rispettivamente la latitudine e longitudine, cioè le coordinate geografiche, che un determinato dispositivo assumi in un certo istante di tempo. Lo schema in questione modella il dominio della posizione dei vari dispositivi in questione. L’associazione di un determinato tempo alla latitudine e longitudine è fondamentale, perchè un dispositivo in momenti diversi può avere coordinate geografiche diverse, perchè può spostarsi. In più è possibili stabilire quanto sono recenti o meno la posizione del dispositivo.Model Pattuglia-Agente/iUn’altro dominio del problema da modellare è quello delle pattuglie e agenti.ModelPattuglia.jpgModelListPattuglia.jpgOra passiamo a descrivere i principali componenti

BDManager

Il DBManager è il componente che si occupa dell’interazione fra sistema e database. Il seguente schema mostra l’architettura del componente DBManager:DBManager.jpgUna volta stabilita una connessione al database, DBManager gestisce le interrogazioni, gli aggiornamenti e l’inserimento dei dati nel database centrale. Al database centrale accede sia la centrale operative che gli agenti delle pattuglie. Lo schema successivo mostra come avviene l’interazione fra il sistema e il DBManager:DBManagerInteraction.jpg

MobileApplication

Di seguito verrà mostrato l’architettura del componente MobileApplicationMobileApplication.jpgMobileApplication è quel componente che permette la comunicazione fra il dispositivo mobile e l’application server. Rappresenta l’interfaccia del dispositivo sull’ambiente esterno.

RequestPosition

RequestPosition rappresenta quel componente che ha il compito di avviare la richiesta della posizione dei dispositivi da parte dell’application server.RequestPosition.jpgPer meglio comprendere il funzionamento di tale componente qui di seguito viene proposto lo schema delle interazioni del RequestPosition con gli altri componenti.RequestPositionInt.jpgPer quanto riguarda i tempi di request/response, dato che i tempi delle richieste sono stati pensati nell'ordine delle decine di minuti, perchè non c'è motivo di chiedere costantemente la posizione delle pattuglia, i tempi di risposta sono tollerati nell'ordine del secondi.

ServiceManager

ServiceManager è quel componente che gestisce le richieste, per esempio l’aggiornamento dati sul database, la visualizzazione della posizione delle pattuglie ect...

ServiceManager.jpgQuesto componente è di notevole importanza perchè essendo un “fornitore di servizi” sia per la centrale operativa che per i dispositivi mobili sulle pattuglie, esso deve gestire la concorrenza delle richieste.

CentralComunicator

CentralComunicator è quel componente che gestisce l'invio delle chiamate al server per le diverse esigenze del sistema.CentralComunicator.jpg

Tecnologie di Riferimento

Per lo sviluppo del sistema di è scelto di utilizzare:
  • Java per le realizzazione dei diversi componenti;
  • XML
  • Jax-Ws per l'implementazione dei web services. Jax-Ws è una tecnologia utilizzata per la creazione di web services e client che comunicano utilizzando XML. Le chiamate web services, in questo caso, utilizzano un protocollo basato sul XML come SOAP
  • MySQL per quanto riguarda la parte database.

Sviluppo e Deployment

Per quanto riguarda la parte di sviluppo, al momento è stato realizzato un simulatore che implementa una porzione di sistema. La parte realizzata è quella che riguarda la gestione delle posizione/visualizzazione delle pattuglie sul territorio, con relativa gestione dei dati. I sistema però è pronto per eventuali altre implementazioni di altre porzioni del sistema.