SISTEMA DI
RILEVAZIONE TRANSITI
Bernardi 701857 – Bider 701784 – Bonetti 701156
Il Problema




Problem Architecture
Si deve modellare un Sistema di Rilevazione Transiti (SRT) che
comprende una sede centrale ed alcune decine di Varchi di Rilevazione
Transiti (VRT).
Ogni VRT è costituito da due fotocellule a distanza di 1m e una
fotocamera che riprende frontalmente un veicolo, collegate ad un nodo
di elaborazione distante al massimo10m
Il sistema SRT invia la contravvenzione ai proprietari dei veicoli che
hanno commesso un’infrazione, ricavando le informazioni dal PRA
(Pubblico Registro Automobilistico) oppure ai guidatori fermati dalla
pattuglia.
Inoltre il sistema SRT interagisce con una BDA (Base Dati Ambiente) che
contiene i dati di inquinamento rilevati da centraline disposte sul
territorio al fine di determinare correlazioni statistiche fra
l’inquinamento rilevato dalle centraline e le intensità dei flussi di traffico
rilevate dai VRT posti entro 200m dalle centraline stesse.
Assunzioni

I VRT sono fissi.

La rilevazione è effettuata su una singola corsia.



Problem Architecture
La fotocamera è sempre accesa e scatta la foto solo in caso di
superamento del limite di velocità.
Se è presente una pattuglia di polizia, il sistema le notifica l’infrazione
rilevata.
Per effettuare analisi statistiche le centraline si devono trovare al più a
200m da un VRT. Poiché le centraline e i VRT sono gestiti da due società
differenti non è necessario che vi sia una centralina in prossimità di un
VRT e viceversa.
CHI e DOVE
Problem Architecture
zione
llule e
vano
I casi d’uso
potevano essere
impostati in
maniera diversa (e
più coerente);
Ad esempio:
- Genera
Contravvenzione
«include» Verifica
Correttezza Targa
La Contravvenzione
dovrebbe essere associata
direttamente alla Targa e
al Sanzionato;
con questa modellazione
le istanze di Sanzionato si
ripetono se una certa
persona ha subito 2
contravvenzioni con auto
(targhe) diverse!
COSA (Data Model)
Problem Architecture
RilevazioneVeicolo
Infrazione
Contravvenzione
Sanzionato
potevano essere tipi di dati sullo stesso
piano concettuale, uniti da associazioni;
non per forza sotto-tipi tra loro
I due eventi di passaggio
sulle fotocellule potevano
Rilevazione
essere modellati in modo
più coerente con l’attesa
di due eventi in sequenza
(vedi soluzione mostrata a
lezione)
COME
Infrazioni
Problem Architecture
COME Notifica Pattuglia
Problem Architecture
Il ramo «guidatore
fermato» così com’è
è scorretto;
bisogna far vedere
un evento che
modella la ricezione
dei dati del
guidatore, a cui
segue il dato
guidatore fermato;
non una notifica.
COME Notifica Contravvenzione
Problem Architecture
Bisogna mostrare che il flusso a valle del
dato Infrazione è ciclico, ossia si esplica
per ogni istanza di Infrazione recuperata
(che è più di una vista la frequenza!).
Per fare questo:
- cardinalità «*» in uscita da
Acquisizione Infrazione(i)
- il flusso a valle delle * Infrazioni va
all’interno di una «loop region», vedete
qui:
http://stackoverflow.com/questions/1579268
7/loop-in-uml-activity-diagram-using-aregion
COME Statistiche
Problem Architecture
QUANDO



Problem Architecture
Al fine di stimare le frequenze delle attività principali, ipotizziamo che il
sistema sia applicato a livello comuale (grossi comuni). Come ad
esempio il comune di Milano che si estende per circa 184 km2
Ipotizziamo di disporre di circa 40 VRT, rilevando:

Un passaggio di 0,8 veicoli/sec.

Per un totale di 115.200 veicoli/ora.

5 infrazioni/ora.

Per un totale di 200 infrazioni/ora.
In sede centrale arrivano quindi:

1 infrazione / 18 sec