Architetture software e dei dati Appello 24/02/2016 Osservazione del Comportamento degli Automobilisti (OCA) MONTEROSSO FEDERICO MONTEVECCHI LUCA NEGRI ANDREA

ANALISI DEL PROBLEMA Si richiede di sviluppare un sistema per il controllo del comportamento degli automobilisti per una compagnia di assicurazioni, in modo da poter calcolare le relative polizze. Per controllare il comportamento degli automobilisti sono state installati dei sistemi all’interno delle auto contenti dei sensori di posizione, velocità e accelerazione Il sistema deve: Calcolare i dati relativi alla Velocità dell’auto nei vari tratti stradali Rilevare un sinistro Mettere in comunicazioni gli operatori con gli assicurati Calcolare il livello di rischio dell’assicurato basandosi su: Km totali Velocità media per tronco viario Livello di prudenza =(km rispettando i limiti)/(km totali) Età dell’assicurato Numero di denunce Comune di residenza

AMBIGUITA’ Qual è il target del sistema? Come rilevare il sinistro? Ogni quanto tempo i sensori rilevano la posizione, velocità, accelerazione? Ogni quanto tempo il sistema dell’auto invia i dati a OCA Qual è la precisione delle rilevazioni salvate all’interno del database Cosa prevede al massimo l’assistenza dell’operatore?

ASSUNZIONI Il target del sistema è a livello regionale. Nella regione Lombardia è stato stimato un numero di incidenti pari a 93 al giorno(2013). Il sinistro viene rilevato in due modi:  L’utente preme il pulsante nell’auto  Accelerazione negativa sopra una certa soglia Ogni 2 secondi il sistema rileva la posizione, velocità e accelerazione L’auto invia i dati al sistema ogni 24 ore Il sistema tiene traccia dei dati giornalieri, effettuerà quindi una media dei dati ricevuti dall’autovettura. L’assistenza dell’operatore prevede al massimo l’invio di un carroattrezzi.32

ARCHITETTURA DEL SOFTWARE

- ARCHITETTURA DEL PROBLEMA

USES CASES

CLASS DIAGRAM

ACTIVITY DIAGRAMCALCOLO LIVELLO DI RISCHIO

ELABORAZIONE DATI GIORNALIERI

ELABORAZIONE ASSISTENZA SINISTRI

RIDEFINIZIONE POLIZZA ASSICURATO

- ARCHITETTURA LOGICA

PARTIZIONAMENTO ORIZZONTALE 1

Abstraction30 Complexity60 Frequency80 Delay50 Locations20 Extra Flows20 Intra Flows10 Sharing70 FOOTPRINT

PARTIZIONAMENTO ORIZZONTALE 2

FOOTPRINT Abstraction10 Complexity20 Frequency10 Delay10 Locations20 Extra Flows20 Intra Flows10 Sharing90 scartiamo la partizione verticale perché comporterebbe a un'altissima : astrazione, complessità frequenza, delay e locations.

- ARCHITETTURA CONCRETA

SEQUNCE DIAGRAM ASSISTENZA SINISTRI

ELABORAZIONE DATI GIORNALIERI

RIDEFINIZIONE POLIZZA ASSICURATO

STRUTTURA INTERNA DEI COMPONENTI INVIO SEGNALAZIONI SINISTRO =PASSIVO - STATELESS GESTORE ASSISTENZA = PASSIVO - STATELESS INVIO RILEVAZIONI = ATTIVO - STATELESS GESTORE DATI GIORNALIERI = PASSIVO - STATELESS GESTORE RINNOVO POLIZZA = ATTIVO - STATELLES BASE DATI (BDA) = PASSIVO - STATEFULL BASE DATI (OCB) = PASSIVO - STATEFULL

SCELTE TECNOLOGICHE Comunicazione Auto/Sede assicurazione Comunicazione attraverso sistema GSM installato all’interno dell’auto:  PRO: o Infrastruttura già presente, non vanno create altre infrastrutture dedicate; o Non richiesta grande frequenza di utilizzo della rete o Non richiesta continua disponibilità della rete (invio dei dati una volta al giorno, se non si è coperti dalla rete l’invio dei dati viene riprovato successivamente)  CONTRO: o Costo componenti device o Costo traffico dati

NODI:  Auto : o I device non richiedono grande capacità di calcolo  Sede Assicurazione o Abbassamento dei costi per gli elaboratori (richiesti elaboratori di fascia media) o Medio/basso costo iniziale per la creazione dell’infrastruttura o Bassi costi di ampliamento dell’infrastruttura (aumentare potenza di calcolo per la gestione delle Assistenze) o Resistenza ai guasti per i componenti più critici (GestoreAssistenza)

- DEPLOYMENT

SOLUZIONE1

PRO: o bassa complessità o gestione/manutenzione di un unica macchina nella sede dell'assicurazione CONTRO: o bassa scalabilità o scarsa resistenza ai guasti o richiesto macchina con alta capacità di calcolo

SOLUZIONE2

PRO: o in auto hardware dedicato per svolgimento singola attività o complessità media o migliorata resistenza ai guasti CONTRO: o bassa scalabilità o aumento costi per hardware auto o aumenta complessità di gestione accesso ai database

SOLUZIONE 3 (MIGLIORE)

PRO: o costi inferiori per hardware auto o ulteriormente migliorata resistenza ai guasti (dispatcher per assistenza) o alta scalabilità per gestione assistenza o abbassamento dei costi per la sede centrale (richiesti elaboratori con media capacità di calcolo) CONTRO: o aumentata complessità o scarsa resistenza ai guasti per le attività meno critiche (rinnovo polizza / gestione dati giornalieri) o aumenta complessità di gestione accesso ai database

STIME DI LARGA DEI COSTI Installazione sensori + HW di rilevazione all’interno delle vetture 100€ per auto x20000 = Infrastruttura HW sede € circa Costo abbonamenti internet mobile comunicazione vettura- sede 5€ al mese x 12 = 60€ annuo per auto

- ARCHITETTURA DATI

SCHEMA LOGICO BDA Assicurato(NomeCliente, CognomeCliente, CF, dataNascita, cittaDiNascita, cittaDiResidenza, indirizzo) Comune(CAP, Nome, provincia) Polizza(IDPolizza, CFCliente,TargaVeicolo, nomePolizza, PremioAssicurazione, DataStipulazione, DataScadenza, operatore) Sinistro(IDDenuncia, PolizzaCliente, indirizzo, data, tipoSinistro, descrizioneEvento)

SCHEMA CONCETTUALE BDA

SCHEMA LOGICO OCA Assicurato(Nome, Cognome, CF, dataNascita, NumeroTelefono, cittaDiResidenza) Veicolo(targa, Assicurato, annoImmatricolazione, modello) datiGiornalieri(IDDati, TargaVeicolo, vmTrattiUrbani, vmTrattiExtraUrbani, KmTrattiAutostradali, kmGiornalieri, kmRispettandoLimiti, KmTrattiUrbani, KmTrattiExtraUrbani, kmAutostradali, data) Operatore(IDOperatore, Nome, Cognome)

SCHEMA CONCETTUALE BDA

ETEROGENEITA’ BDAOCBTipo EterogeneitàScelta Assicurato.NomeClienteAssicurato.NomeSinonimia(Attributo)Assicurato.Nome Assicurato.CognomeClienteAssicurato.CognomeSinonimia(Attributo)Assicurato.Cognome ComuneAssicurato.cittaResidenzaStrutturaleComune come entità

Corrispondenze Inter-schema stipula OCBOperatore BDAPolizza stipula OCBVeicolo BDAPolizza

SCHEMA LOGICO GLOBALE Assicurato (Nome, Cognome, CF, dataNascita, NumeroTelefono, cittaDiNascita, cittaDiResidenza, indirizzo) Comune(CAP, Nome, provincia) Polizza(IDPolizza, CFCliente,TargaVeicolo, nomePolizza, PremioAssicurazione, DataStipulazione, DataScadenza, OperatorePolizza) Sinistro(IDDenuncia, PolizzaCliente, indirizzo, data, tipoSinistro, descrizioneEvento) Veicolo(targa, Assicurato, annoImmatricolazione, modello) datiGiornalieri(IDDati, TargaVeicolo, vmTrattiUrbani, vmTrattiExtraUrbani, vmTrattiAutostradali, kmGiornalieri, kmRispettandoLimiti, KmTrattiUrbani, KmTrattiExtraUrbani, kmAutostradali, data) Operatore(IDOperatore, Nome, Cognome)C

SCHEMA CONCETTUALE GLOBALE

Assicurato: CREATE VIEW Assicurato Select bda.NomeCliente AS Nome, bAss.CognomeCliente AS Cognome, bAss.CF, bAss.dataNascita, oAss.telefono, bAss.cittaDiNascita, bAss.cittàdiResidenza, bAss.indirizzo FROM BDA.Assicurato as bAss JOIN OCB.Assicurato as oAss ON bAss.CF = oAss.CF Comune: CREATE VIEW Comune SELECT * from BDA.Comune Polizza: CREATE VIEW Polizza Select * from BDA.Polizza GLOBAL MAPPING AS A VIEW

Sinistro: CREATE VIEW Sinistro Select * from BDA.Sinistro Veicolo: CREATE VIEW Veicolo Select * from OCB.Veicolo datiGiornalieri: CREATE VIEW datiGiornalieri Select * from OCB.datiGiornalieri Operatore: CREATE VIEW Operatore Select * from OCB.Operatore

QUERY Selezionare Nome, cognome e veicolo(targa) degli assicurati residenti a Milano e la cui polizza relativa al veicolo in questione scade entro 28/02/2016 SELECT A.Nome AS Nome, A.Cognome AS Cognome, V.targa AS targa FROM Assicurato AS A JOIN Comune AS C ON A. cittaDiResidenza=C.CAP JOIN Polizza AS P ON (A.CF=P.CFCliente) JOIN Veicolo AS V ON (P.TargaVeicolo=V.targa) WHERE P.DataScadenza < 28/02/2016 AND C.Nome=’Milano’; UNFOLDING SELECT A.Nome AS Nome, A.Cognome AS Cognome, V.targa AS targa FROM BDA.Asicurato AS A JOIN BDA.Comune AS C ON A. cittaDiResidenza=C.CAP JOIN BDA.Polizza AS P ON (A.CF=P.CFCliente) JOIN OCB.Veicolo AS V ON (P.TargaVeicolo=V.targa) WHERE P.DataScadenza < 28/02/2016 AND C.Nome=’Milano’;

A causa della necessità di avere database flessibili e scalabili, in contesti come Facebook, Twitter e simili, è nata la necessità di avere database non relazionali o NoSQL. Il problema dei database tradizionale è fondamentalmente la frammentazione dei dati su varie tabele, questo porta a continue interrogazioni di vario tipo e, nel caso di un grande quantitativo di dati si necessità di una grande potenza computazionale. MODELLO DI RAPPRESENTAZIONE NON RELAZIONALE PER OCB

I database NoSQL possono essere implementati seguendo differenti approcci a seconda delle strutture dati con cui si rappresentano i record di dato. Le principali categorie sono le seguenti quattro: Column-oriented database : le informazioni sono memorizzate in colonne. Non c'è bisogno di definire subito le colonne. Tipicamente sono usati nell’ambito della memorizzazione distribuita dei dati. Key/Values store: in questo caso i dati vengono immagazzinati in un elemento che contiene una chiave assieme ai dati veri e propri. É quindi del tutto analogo ad una Hash Table. Questo metodo è il più semplice da implementare, ma anche il più inefficiente se la maggior parte delle operazioni riguardano soltanto una parte di un elemento. Document store: è l’evoluzione del metodo key/value, rispetto ai normali database relazionali invece che immagazzinare i dati in tabelle con dei campi fissi, questi vengono messi in un documento (rappresentato in XML, JSON o BSON) che può contenere illimitati campi di illimitata lunghezza, così se ad esempio di una persona conosciamo solo nome e cognome, ma magari di un’altra persona anche indirizzo, data di nascita 11 e codice fiscale, si evita che per il primo nominativo ci siano campi inutilizzati che occupano inutilmente spazio. Graph database: i dati vengono immagazzinati sotto forma di strutture a grafi, rendendo più performante l’accesso a questi da applicativi orientati agli oggetti. Tipicamente si usa nei social network. Classificazione dei database non relazionali

Scelta implementativa Se si fosse scelto di rappresentare il database OCB sotto forma di DB non relazionale avremmo scelto, il tipo Document. Questo tipo di Struttura dati, permette di: - organizzare i dati in documenti schemaless - non tenere traccia di dati non necessari al sistema - contenere tutte le informazioni senza effettuare operazioni di join - non soddisfare le proprietà ACID per le rilevazioni - memorizzare documenti di lunghezza illimitata (possibile collezionare dati giornalieri) - memorizzare in modo ottimale le grandi quantità di dati provenienti dai sensori. La tipologia Document è inoltre più efficiente rispetto al key-value, per il fatto che quest’ultimo richiede più tempo negli aggiornamenti. Il graph database nel nostro caso non è funzionale poiché sarebbe più utile se dovessimo trovare relazioni interne ai vari dati, ma non è cosi. Infine Column-oriented database si applica nel caso si necessiti di sotto categorie. La forma di implementazione document based scelta è Mongodb: - databsae Open-source (riduzione spese) - scalabile - con possibilità di creare facilmente software (ad esempio per aggregare informazioni) - performance maggiori rispetto a struttura tradizionale