Architetture software e dei dati Appello 24/02/2016 Osservazione del Comportamento degli Automobilisti (OCA) 763862 MONTEROSSO FEDERICO 772185 MONTEVECCHI LUCA 808934 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 DIAGRAM CALCOLO LIVELLO DI RISCHIO ELABORAZIONE DATI GIORNALIERI ELABORAZIONE ASSISTENZA SINISTRI RIDEFINIZIONE POLIZZA ASSICURATO - ARCHITETTURA LOGICA PARTIZIONAMENTO ORIZZONTALE 1 FOOTPRINT Abstraction Valore 30 Sharing Complexity 60 Frequency 80 Delay 50 Locations 20 Extra Flows 20 Intra Flows 10 Sharing 70 Intra Flows Max = 100 Abstraction 100 90 80 70 60 50 40 30 20 10 0 Extra Flows Complexity Frequency Delay Locations PARTIZIONAMENTO ORIZZONTALE 2 FOOTPRINT Valore Abstraction 10 Complexity 20 Frequency 10 Max = 100 Abstraction 100 Sharing 80 Complexity 60 40 Delay 10 Locations 20 Extra Flows 20 Intra Flows 10 Sharing 90 20 Intra Flows Frequency 0 Extra Flows Delay Locations 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 = 2000000 • Infrastruttura HW sede 10000 € circa • Costo abbonamenti internet mobile comunicazione vetturasede 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’ BDA OCB Tipo Eterogeneità Scelta Assicurato.NomeCliente Assicurato.Nome Sinonimia(Attributo) Assicurato.Nome Assicurato.CognomeCliente Assicurato.Cognome Sinonimia(Attributo) Assicurato.Cognome Comune Assicurato.cittaResidenza Strutturale Comune come entità Corrispondenze Inter-schema OCB Operatore OCB Veicolo stipula stipula BDA Polizza BDA Polizza 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 GLOBAL MAPPING AS A VIEW 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 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’; MODELLO DI RAPPRESENTAZIONE NON RELAZIONALE PER OCB 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. Classificazione dei database non relazionali 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. 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