Architetture software e dei dati - e-Learning

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