Architetture del Software e dei Dati A.A. 2015/16 Sistema di Osservazione del Comportamento degli Automobilisti Lorenzo Fenili Silvio Messi

Assunzioni La compagnia di assicurazioni che utilizza il sistema opera a livello regionale (<=500 mila assicurati), e può avere più sedi distribuite sul territorio. Per la rilevazione della collisone si utilizzano esclusivamente i dati forniti dall’accelerometro (ACC). In particolare abbiamo assunto che il sensore fornisca un unico valore di accelerazioni e che se esso supera una determinata soglia allora siamo certi che il veicolo ha subito una collisone. Sul veicolo dell’assicurato viene montato un dispositivo (che contiene GPS, TAC e ACC) che ha un identificatore univoco.

Stime temporali Veicolo (in media 2 ore di viaggio al giorno) Campionamento ACC ogni 0,1 sec Campionamento GPS e TAC ogni 10 sec = 720 campioni al giorno In media 50 collisioni di veicoli al giorno Assicurato (sono circa 500mila) Visualizzazione informazioni assicurato almeno una volta al mese Polizza (sono circa 250mila) Scadenze polizze = /365 = 685 al giorno Visualizzazione informazione polizza almeno una volta al mese

ARCHITETTURA DEL SOFTWARE

ARCHITETTURA DEL PROBLEMA

Use Case Diagram

Class Diagram

Activity Diagram - Acquisizione dati veicolo

Activity Diagram - Salvataggio K-V-P giornaliero

Activity Diagram - Rilevamento Collisione

Activity Diagram - Organizzazione assistenza

Activity Diagram - Calcolo livello di rischio

Activity Diagram - Ridefinizione premio assicurazione

Activity Diagram - Visualizzazione informazioni assicurato/polizze

ARCHITETTURA LOGICA

Partizionamento - 1

Partizionamento - 2

Gestore acquisizione dati Multiplicity: # veicoli

Gestore rilevazione collisioni Multiplicity : # veicoli

Gestore collisioni Multiplicity : # 1

Gestore K-V-P Multiplicity : # 1

Gestore calcolo livello di rischio Multiplicity : # 1

Gestore ridefinizione polizze Multiplicity : # sedi locali

Gestore visualizzazione informazioni Multiplicity : # sedi locali

Footprint del partizionamento

Abstraction (50): alcuni componenti hanno a che fare con diversi livelli di astrazione dell’informazione (l’esempio più lampante è il componente che si occupa del calcolo del livello di rischio). Complexity e Frequency (10): i componenti sono stati partizionati in modo da essere ben omogenei per quanto riguarda queste due dimensioni. Delay (30): abbiamo un vicolo temporale abbastanza stringente tra due componenti (rilevazione collisioni e gestore collisioni). Location (20): la location degli attori con cui i componenti hanno ha che fare è omogenea. Intra Flows(20): il flusso di informazioni tra istanze dello stesso componente è assente (si pensi al componete gestore rilevazione collisioni). Extra Flows (30): il flusso di informazioni tra i componenti e l’ambiente esterno è discreto. Sharing(20): la condivisione delle informazioni tra componenti è limitata solo ad alcune informazioni (K-V-P). Control Flows(10): il flusso di controllo tra i vari componenti è quasi del tutto assente.

ARCHITETTURA CONCRETA

Sequence Diagram - Acqusizione dati veicolo

Sequence Diagram- Rilevazione collisioni / Organizzazione assistenza

Sequence Diagram - Ricezione dati veicolo / Calcolo K-V-P giornaliero

Sequence Diagram - Calcolo livello di rischio

Sequence Diagram - Visualizzazione informazioni assicurato / polizze

Sequence Diagram - Ridefinizione polizza

DEPLOYMENT DIAGRAM

SCELTE TECNOLOGICHE

Comunicazioni

Black box sul veicolo Il dispositivo che viene installato sugli autoveicoli degli assicurati non necessita di una grande potenza di calcolo. Deve essere in grado di gestire i 3 sensori e immagazzinare un numero ridotto di informazioni. Proprio quest’ultima necessita ci ha spinto a scartare il noto microcontrollore Arduino e a scegliere invece il Raspberry Pi. Questo modulo, infatti, monta uno slot per le SD card e dunque è possibile espandere senza problemi la memoria del device. Sono di facile reperibilità ed hanno un prezzo contenuto i sensori (GPS, ACC, TAC) per tale device ed inoltre è possibile trovare una vasta documentazione per il loro utilizzo. Per la comunicazione con la sede centrale basta equipaggiare il con un modulo 3G.

Sede centrale Gran parte del carico computazionale viene gestito nelle sede centrale. Bisogna dunque prevedere un apparato HW/SW che sia in grado di rispondere alle esigenze del sistema. Ci sono due possibili soluzioni: utilizzo di tecnologie in Cloud: tale soluzione ha a suo favore tutti vantaggi tipici dell’utilizzo del Cloud ossia: costi di gestione HW ridotti se non addirittura inesistenti, possibilità di scalare senza spese eccessive. utilizzo di server proprietari: questa soluzioni comporta costi maggiori in termini di risorse umane e gestione apparati HW, ma garantisce la privatezza dei dati e permette di non essere vincolati in scelte di soluzioni SW. La scelta di una o dell’altra soluzione è legata principalmente ai vincoli di budget.

Stima dei costi – Risorse HW/SW ProdottoCostoQuantitàTot. Raspberry Pi50€ € Sensoristica (GPS + TAC + ACC)100€ € Modulo 3G30€ € Costo piano tariffario5€/mese €/mese Costo installazione server € Costo server(soluzione Cloud)200€/mese1 Le ultime due voci della tabella sono mutualmente esclusive, in base alla tipologia di soluzione che viene utilizzata per l’acquisto dei server nella sede centrale. Per quanto riguarda il SW, in particolare il DBMS per OCB, si è deciso di utilizzare una soluzione open, cosi da abbattere I costi per le licenze.

Stima dei costi – Risorse umane DescrizioneQuantitàCosto Unitario/MeseTotale Project Manager12.500€ Database Administrator12.000€ Sistemista12.000€ Sviluppatori51.500€7.500€

Stima dei costi - totale In definitiva la stima di massima dei costi per il sistema risulta essere: Blackbox: € € mensili Server ufficio centrale: Soluzione proprietaria : € Soluzione Cloud : 200€/mese Risorse umane: € mensili Sedi locali: si assume che nelle sedi locali siano già presenti postazioni PC

ARCHITETTURA DEI DATI

Schema logico BDA Assicurato(CF, nome, cognome, indirizzo, comuneResidenza, dataDiNascita, numeroDiTelefono, iban) Comune(comune, provincia) Provincia(provincia, regione) Polizza(idPolizza, assicurato, targaVeicolo) StoricoPolizza(idPolizza, dataStipula, dataScadenza, premio) Sinistro(idPolizza, assicurato, data, comuneSinistro) I vincoli referenziali sono stati rappresentanti tramite l’ausilio dei colori.

Reverse engineering - 1 Associare alle tabelle con chiavi semplici delle entità, e associare la chiave a identificatori. EnititàIdentificatore AssicuratoCF PolizzaidPolizza Comunecomune Provinciaprovincia Le entità Comune e Provincia possono essere considerate, nello schema concettuale, come un unica entità. Nello schema logico sono divise per questioni di normalizzazione. Inoltre, anche se essa non ha un chiave “semplice”, nello schema globale ci sarà anche l’entità StoricoPolizze che non si presta ad essere una relazione.

Reverse engineering - 2 Utilizzare i vincoli di integrità referenziale per individuare le relationships. ChiaveTabella referenziata Assicurato.comuneResidenzaComune Comune.provinciaProvincia Polizza.assicuratoAssicurato StoricoPolizza.idPolizzaPolizza Sinistro.idPolizzaPolizza Sinistro.assicuratoAssicurato Sinistro.comuneSinistroComune

Reverse engineering – 2.1 EntitàRelationshipEntità AssicuratocomuneResidenzaComune AssicuratostipulaPolizza StoricoPolizzahaStoricoPolizza Tra le entità Assicurato, Comune e Polizza, in base ai vincoli referenziali, abbiamo pensato di introdurre la relationship “Sinistro”.

Reverse engineering - 3 Utilizza gli attributi che descrivono diversi oggetti per individuare IS_A e generalizzazioni. Nello schema logico non sono presenti attributi che inducono ad introdurre relazioni IS_A o generalizzazioni nello schema concettuale.

Schema concettuale DBA

Schema concettuale OCB

Schema logico OCB Assicurato(idAssicurato, livelloDiRischio, dataCalcoloLivelloDiRischio) Polizza(idAssicurato, veicolo, dataDiScadenza, premioPolizza) Veicolo(targa, modello, cilindrata idDevice) K-V-PGiornaliero(idKVP, veicolo, timestamp, K, P) VPerTGiornaliero(idKVP, T, V) Collisione(idCollisione, veicolo, timestamp, accelerazione, latitudine, longitudine) Segnalazione(idCollisione, timestamp, idAssicurato)

Eterogeneità e corrispondenze BDAOCBTipologia C1Assicurato Corrispondenza interschema C2Polizza Corrispondenza interschema E1DBA.Polizza.targaVeicolo OBC.Polizza.veicolo Eterogeneità Livello di Schema – stesso concetto diverso tipo (in DBAattributo, in OCB entità) E2DBA.Assicurato.CFOBC.Assicurato.idAssicuratoSinonimia: Diverso nome ma stesso concetto

Integrazione schemi Le corrispondenze interschema C1 e C2 vengono risolte mantenendo le entità BDA.Assicurato e BDA.Polizza, che vengono “arrichite” con gli attributi delle corrispondenti entità in OCB L’eterogeneità E1 viene risolta mantenendo l’entità OCB.Veicolo Per quanto riguarda l’eterogeneità E2, si è deciso di mantenere l’identificatore CF

Schema concettuale BDG (globale)

Schema logico BDG Assicurato(CF, nome, cognome, indirizzo, comuneResidenza, dataDiNascita, numeroDiTelefono, iban, livelloDiRischio, dataCalcoloLivelloDiRischio) Comune(comune, provincia) Provincia(provincia, regione) Polizza(idPolizza, assicurato, veicolo, dataDiScadenza, premioPolizza) StoricoPolizza(idPolizza, dataStipula, dataScadenza, premio) Sinistro(idPolizza, assicurato, data, comuneSinistro) Veicolo(targa, modello, cilindrata idDevice) K-V-PGiornaliero(idKVP, veicolo, timestamp, K, P) VPerTGiornaliero(idKVP, T, V) Collisione(idCollisione, veicolo, timestamp, accelerazione, latitudine, longitudine) Segnalazione(idCollisione, timestamp, idAssicurato)

Mapping GAV - 1 CREATE VIEW Assicurato (CF, nome, cognome, indirizzo, comuneResidenza, dataDiNascita, numeroDiTelefono, iban, livelloDiRischio, dataCalcoloLivelloDiRischio ) AS SELECT T1.CF, T1.nome, T1.cognome, T1.indirizzo, T1.comuneResidenza, T1.dataDiNascita, T1.numeroDiTelefono, T1.iban, T2.livelloDiRischio, T2.dataCalcoloLivelloDiRischio FROM BDA.Assicurato AS T1 LEFT JOIN OCB.Assicurato AS T2 ON T1.CF = T2.idAssicurato CREATE VIEW Polizza (idPolizza, assicurato,veicolo, dataScadenza, premioPolizza) AS SELECT T1.idPolizza, T1.assicurato, T1.targaVeicolo, T2.dataScadenza, T2.premioPolizza FROM BDA.Polizza AS T1 LEFT JOIN OCB.Polizza AS T2 ON T1.idPolizza = T2.idPolizza CREATE VIEW Veicolo (targa, modello, cilindata, idDevice) AS SELECT T1.targaVeicolo, T2.modello, T2.cilindarata, T2.idDevice FROM BDA.Polizza AS T1 LEFT JOIN OCB.Veicolo AS T2 ON T1.targaVeicolo = T2.targa

Mapping GAV - 2 CREATE VIEW Comune (comune, provincia) AS SELECT comune, provincia FROM DBA.Comune CREATE VIEW Provincia (provincia, regione) AS SELECT provincia, regione FROM DBA.Provincia CREATE VIEW StoricoPolizza (idPolizza, dataStipula, dataScadenza, premio) AS SELECT idPolizza, dataStipula, dataScadenza, premio FROM DBA.StoricoPolizza CREATE VIEW Sinistro (idPolizza, assicurato, data, comuneSinistro) AS SELECT idPolizza, assicurato, data, comuneSinistro FROM DBA.Sinistro

Mapping GAV - 3 CREATE VIEW K-V-PGiornaliero (idKVP, veicolo, timestamp, K, P) AS SELECT idKVP, veicolo, timestamp, K, P FROM OCB.K-V-PGiornaliero CREATE VIEW VPerTGiornaliero(idKVP,T, V) AS SELECT idKVP, T, V FROM OCB.VPerTGiornaliero CREATE VIEW Collisione (idCollisione, veicolo, timestamp, accelerazione, latitudine, longitudine) AS SELECT idCollisione, veicolo, timestamp, accelerazione, latitudine, longitudine FROM OCB.Collisione CREATE VIEW Segnalazione (idCollisione, timestamp, idAssicurato) AS SELECT idCollisione, timestamp, idAssicurato FROM OCB.Segnalazione

Query “Trovare il veicolo che ha percorso più km nell’ultimo anno; mostrare quanti kilometri ha percorso, la sua targa e il nome e cognome della persona che lo ha assicurato. ”

Query SELECT A.Nome, A.Cognome, sommaKmPerVeicolo2.veicolo, massimoDelleSomme.max FROM ( SELECT MAX (somma) AS max FROM ( SELECT veicolo, SUM (K) AS somma FROM BDG.K-V-PGiornaliero WHERE timestamp>= DATE_SUB(NOW(), INTERVAL 1 YEAR) GROUP BY(veicolo) ) AS sommaKmPerVeicolo1 ) AS massimoDelleSomme JOIN ( SELECT veicolo, SUM (K) AS somma FROM BDG.K-V-PGiornaliero WHERE timestamp>= DATE_SUB(NOW(), INTERVAL 1 YEAR) GROUP BY(veicolo) ) AS sommaKmPerVeicolo2 ON sommaKmPerVeicolo2.somma = massimoDelleSomme.max JOIN BDG.Polizza AS P ON P.veicolo = sommaKmPerVeicolo2.veicolo JOIN BDG.Assicurato AS A ON P. CF = A.CF

Unfolding - 1 SELECT A.Nome, A.Cognome, sommaKmPerVeicolo2.veicolo, massimoDelleSomme.max FROM ( SELECT MAX (somma) AS max FROM ( SELECT veicolo, SUM (K) AS somma FROM OCB.K-V-PGiornaliero WHERE timestamp>= DATE_SUB(NOW(), INTERVAL 1 YEAR) GROUP BY(veicolo) ) AS sommaKmPerVeicolo1 ) AS massimoDelleSomme JOIN ( SELECT veicolo, SUM (K) AS somma FROM OCB.K-V-PGiornaliero WHERE timestamp>= DATE_SUB(NOW(), INTERVAL 1 YEAR) GROUP BY(veicolo) ) AS sommaKmPerVeicolo2 ON sommaKmPerVeicolo2.somma = massimoDelleSomme.max (continua)

Unfolding - 2 JOIN ( SELECT T1.idPolizza, T1.assicurato, T1.targaVeicolo AS veicolo, T2.dataScadenza, T2.premioPolizza FROM BDA.Polizza AS T1 LEFT JOIN OCB.Polizza AS T2 ON T1.idPolizza = T2.idPolizza ) AS P ON P.veicolo = sommaKmPerVeicolo2.veicolo JOIN ( SELECT T1.CF, T1.nome, T1.cognome, T1.indirizzo, T1.comuneResidenza, T1.dataDiNascita, T1.numeroDiTelefono, T1.iban, T2.livelloDiRischio, T2.dataCalcoloLivelloDiRischio FROM BDA.Assicurato AS T1 LEFT JOIN OCB.Assicurato AS T2 ON T1.CF = T2.idAssicurato )AS A ON P. CF = A.CF

NoSQL Il modello di rappresentazione dati NoSQL che più si adatta al sistema OCA è quello document based. Per come è stata progettata la base di dati, infatti, l’esecuzione di alcune query porta all’utilizzo di un gran numero di join. Di conseguenza, l’utilizzo della rappresentazione document based, ci farebbe risparmiare in termini di tempo e guadagnare in termini di prestazioni dato che le tecnologie basta su questa rappresentazione non fanno uso dell’operatore join. Un altro motivo che ci ha spinto a preferire questo paradigma rispetto ad altri, è legato al fatto che la rappresentazione delle informazioni del domino dell’applicazione, ossia documenti cartacei che rappresentano assicurati e polizze, si avvicina di più al modello document based che al modello relazionale. La tecnologia più diffusa che implementa il modello NoSQL da noi scelto è MongoDB che dispone di molti vantaggi: File Storage: MongoDB può essere utilizzato anche come file system, ai file possono essere associati i metadati su cui è possibile associare degli indici full-tex Bilanciamento, replicazione dei dati e affidabilità: MongoDB scala orizzontalmente utilizzando lo sharding e questo trae vantaggio sul bilanciamento e di conseguenza sull’affidabilità Query ad hoc: è possibile effettuare query per campi, intervalli e regular expression Inidicizzazione: gli indici di MongoDB sono similari a quelli dei tradizionali RDBMS, quindi ogni campo può essere indicizzato Di seguito un esempio di informazioni della basi di dati OCB, modellate utilizzando MongoDB, in cui viene rappresentata una polizza con l’assicurato e il veicolo.

“Assicurato”:{ “idAssicurato”:”3”, “livelloDiRIschio”:”5”, “dataCalcoloLivelloDiRIschio”:”22/01/2016”, Polizze:[ { “dataDiScadenza”:”27/02/2016”, “premioPolizza”:”600”, “veicolo”:{ “targa”:”BC475PU”, “modello”:”Clio Renault”, “cilindrata”:”1500” } }, { “dataDiScadenza”:”11/12/2016”, “premioPolizza”:”450”, “veicolo”:{ “targa”:”BK413GM”, “modello”:”FIAT Punto”, “cilindrata”:”1200” } ] }

Adottando il modello di rappresentazione dati document based si potrebbe rivedere l’architettura dati mostrata precedentemente nel diagramma deployement. Invece di avere un architettura con un database centralizzato si potrebbe introdurre un architettura distribuita, con un database per ogni sede, nel quale vengono memorizzate solo le informazioni degli assicurati, e relative polizze, prese in carico dalla sede, questo sfruttando il fatto che le informazione legate ad un assicurato sono modellate come un unico documento.