PROGETTO TRASPORTO MERCI - GRUPPO BC - e-Learning

Architetture del Software e dei Dati
PROGETTO
TRASPORTO MERCI
BC Group:
Barilli Alessio - 769467
Colnaghi Simone - 763633
Anno Accademico 2015/2016
Indice
 Introduzione
 Architettura Software
I. Vincoli
II. Architettura del Problema
III. Architettura Logica
IV. Architettura Concreta
V. Analisi dei Costi
 Architettura Dati
INTRODUZIONE
ANALISI DEL PROBLEMA
ASSUNZIONI
Abbiamo supposto le seguenze assunzioni:
o Il sistema è pensato su base regionale, con viaggi dalla durata massima di 3 ore;
o Le bolle di carico sono in formato elettronico;
o Il segnale GPS funziona correttamente nelle gallerie;
o Tutti i mezzi di trasporto devono partire entro le 10 del mattino. Le bolle che
vengono analizzate in seguito saranno assegnate al giorno dopo;
o Le informazioni utili che gli autisti mandano al CC sono differenziate in 3 tipi
in modo che sia più facile la loro identificazione;
o Le statistiche vengono effettuate settimanalmente. Ogni sabato vengono
analizzati gli scostamenti effettuati nella settimana precedente;
o Le statistiche possono essere fatte in base ad ogni MT oppure in base ad ogni
DP.
VINCOLI FUNZIONALI
o
o
o
o
o
o
o
Il CC deve pianificare il percorso in base alla mappa viaria e alla bolla ricevuta da UL;
Il CC deve inviare le Bolle di carico e i Percorsi programmati ai mezzi di trasporto;
L’UL deve inoltrare la bolla di carico, dopo averla creata, al CC;
I MT deve segnalare al CC ogni problema;
I sensori sui MT devono rilevare la posizione effettiva del mezzo;
Il CC deve verificare gli scostamenti dei MT dal percorso programmato;
Il CC deve effettuare statistiche basate sugli spostamenti.
VINCOLI NON FUNZIONALI
o L’UL deve inoltrare la bolla di carico compilata al CC almeno il giorno precedente alla
consegna;
o Il CC deve inoltrare PP e BC ai MT entro le ore 10 del mattino di consegna;
o Il sistema deve essere attivo durante l’orario di lavoro (8-17) in tutti i giorni lavorativi (LunSab).
ARCHITETTURA SOFTWARE
ARCHITETTURA DEL PROBLEMA
DIAGRAMMA DEI CASI D’USO (1)
DIAGRAMMA DEI CASI D’USO (2)
In questo diagramma vengono mostrati tutti i casi d’uso del sistema in questione.
Gli attori che fanno parte del sistema sono:
 l’ufficio logistico: è l’ufficio incaricato di creare le varie Bolle di Carico e di
inoltrarle al Centro di Coordinamento;
 il centro di coordinamento: è la sezione che si occupa di pianificare un percorso
ottimale in base ai dati ottenuti dalla Mappa Viaria; inoltre è incaricato di
inoltrare la Bolla e il PP ai mezzi di trasporto analizzandone gli scostamenti e
calcolando statische utili;
 I mezzi di trasporto: sono i mezzi incaricati della consegna e si occupano
dell’invio di tutte le informazioni utili al centro di coordinamento per migliorare
la qualità e il servizio del sistema;
 La mappa viaria: consiste di una base di dati esterna al sistema che contiene tutti i
dati aggiornati relativi alle varie strade e al loro livello di traffico.
DIAGRAMMA DELLE CLASSI (1)
DIAGRAMMA DELLE CLASSI (2)
Questo diagramma mostra tutti i dati presenti nel nostro sistema.
 I dati legati ai percorsi sono legati alle coordinate gps grezze e ai dati contenuti
della base di dati esterna MV. Il PP è visto come un’aggregazione di tratte
viarie che a loro volta sono anche le parti di cui è composta la mappa viaria.
Ogni tratta viaria ha un inizio e una fine (descritte in coordinate) per
identificare meglio la porzione di via a cui si fa riferimento.
 I dati relativi alle consegne (BC, DP, MC e MT) sono riportati attraverso una
descrizione quanto più dettagliata.
 Le statistiche relative agli scostamenti sono viste come aggregazioni elaborate
dello scostamento visto come dato grezzo.
DIAGRAMMA DELLE ATTIVITA’- INOLTRA BC
In questo diagramma viene mostrato come viene inoltrato la bolla di carico
da parte di UL verso il CC. Questo processo viene fatto ogni giorno per ogni
merce.
DIAGRAMMA DELLE ATTIVITA’- PIANIFICA PP
Una volta ricevuta la bolla di carico dall’Ufficio Logistico, il Centro di Coordinamento
provvede alla pianificazione di un percorso ottimale da seguire analizzando i dati MV.
Una volta fatto ciò, provvede l’invio dell PP e della BC al mezzo MT che trasporterà la
merce. Non sapendo il momento esatto in cui possa arrivare la bolla di carico il CC ha
tempo genericamente fino alla mattina del giorno di consegna per inviare PP e BC al MT
DIAGRAMMA DELLE ATTIVITA’- OTTIENI GPS DATA
Su ogni mezzo MT è installato un sistema per la rilevazione della
posizione. Una volta acceso il GPS all’inizio del viaggio, ogni 10
secondi, vengono rilevate le coordinate e salvate in un datastore
per poi essere analizzati in seguito.
DIAGRAMMA DELLE ATTIVITA’- MONITORA SCOSTAMENTO
Lo scostamento viene identificato attraverso il posizionamento del mezzo
grazie al segnale GPS. Una volta rilevato che il mezzo sia effettivamente al di
fuori del percorso programmato allora il CC calcola quale sia la differenza di
tempo e di spazio a cui il mezzo arriva a causa di quello scostamento.
DIAGRAMMA DELLE ATTIVITA’- INVIO INFO UTILI
Le info utili sono divise in tre tipi per distinguere la loro utilità. Ad ogni
problema, l’autista, attraverso il suo dispositivo, dovrà prontamente
comunicarlo al CC.
DIAGRAMMA DELLE ATTIVITA’- ANALISI STATISTICA
Le statistiche del nostro sistema vengono fatte settimanalmente, ogni sabato.
Vengono analizzati i dati relativi agli scostamenti fatti nell’ultima settimana da
parte dei vari MT in relazione alle destinazioni periferiche DP. Le statistiche
vengono poi salvate in un datastore.
ARCHITETTURA LOGICA
COMPONENTI LOGICI – INOLTRA BC
In questo diagramma vengono evidenziate le due componenti dell’UL:
Control Manager e Communication Manager. Il primo si occupa di tutto
ciò che riguarda il controllo delle merci e la creazione di bolle. Il secondo è
invece adibito alla comunicazione con l’esterno e quindì anche all’invio
delle bolle al CC.
COMPONENTI LOGICI – PIANIFICA PP (1)
COMPONENTI LOGICI – PIANIFICA PP (2)
Le componenti che formano il CC sono 4, in questo diagramma ne
vengono utilizzate 3:
 Communication Manager: è il componente che gestisce le comunicazioni
del CC e lo scambio di dati con l’esterno;
 Analysis Manager: questo componente è la parte calcolante del CC ed ha
il compito di stilare delle statistiche e di analizzare i dati;
 Planning Manager: ha lui il compito di pianificare i percorsi ottimali per
ogni mezzo di trasporto.
COMPONENTI LOGICI – OTTIENI GPS DATA
Qui vengono presentate le componenti atte alla rilevazione della posizione dei mezzi e
al salvataggio dei dati GPS. Entrambe sono presenti sul dispositivo presente sul MT.
COMPONENTI LOGICI – MONITORA SCOSTAMENTO
L’ultimo dei componenti presenti nel CC è presentato in questo diagramma: Location
Manager. Il Location Manager è il componente adibito alla rilevazione degli scostamenti
dei MT dal percorso programmato.
COMPONENTI LOGICI – INVIA INFO UTILI
Il Control Manager montato sul MT ha anche il compito di comunicare al CC le info utili
rilevate dall’autista durante le consegne.
COMPONENTI LOGICI – ANALISI STATISTICA
Un ulteriore compito dei componenti del CC è qui descritto. Essi
analizzano i dati degli scostamenti avvenuti e ne calcolano alcune
statistiche utili a migliorare il servizio di consegna
INTERNAL DESIGN OF COMPONENTS
GPSSensor: stateless / active.
MT Control Manager: stateless / active.
CC Communication Manager: stateful / active.
CC Analysis Manager: stateless / active.
CC Planning Manager: stateless / active.
CC Location Manager: stateless / active.
UL Control Manager: stateless / active.
UL Communication Manager: stateful / active.
KIVIAT CHART (1)
Kiviat Chart
Value 0-100
Variabili
Valori
Intraflow
70
Intraflow
70
60
50
Abstraction
40
Extraflow
35
Delay
50
20
Frequency
35
0
Sharing
20
Abstraction
20
30
Extraflow
10
Sharing
Delay
Frequency
KIVIAT CHART (2)
Il diagramma radar mostra le prestazioni del sistema. Lo scambio di
informazioni tra componenti (intraflow) risulta abbastanza alto, poiché,
ad esempio nel CC, le componenti devono interagire spesso tra loro per
il calcolo e l’analisi di tempi e percorsi. L’extraflow, di contro, risulta
basso poiché lo scambio di informazioni con l’esterno è limitato al solo
invio e ricezione di bolle di carico e all’osservazione della mappa viaria.
Anche il livello di sharing risulta contenuto dato che difficilmente due
componenti o unità agiscono sullo stesso dato contemporaneamente.
ARCHITETTURA CONCRETA
DIAGRAMMA DI SEQUENZA – INOLTRA BC
DIAGRAMMA DI SEQUENZA – PIANIFICA PP
DIAGRAMMA DI SEQUENZA – OTTIENI GPS DATA
DIAGRAMMA DI SEQUENZA – MONITORA SCOSTAMENTO
DIAGRAMMA DI SEQUENZA – INVIO INFO UTILI
DIAGRAMMA DI SEQUENZA – ANALISI STATISTICHE
DIAGRAMMA DI DEPLOYMENT – CENTRALIZZATA (1)
DIAGRAMMA DI DEPLOYMENT – CENTRALIZZATA (2)
La prima soluzione proposta vede la presenza di 5 nodi. La presenza dei database
all’interno dei nodi permette una maggiore sicurezza dei dati e una gestione più
semplificata del software e dei dati. E’ necessaria però un’alta potenza di calcolo dati i
compiti sia di memorizzazione che di computazione.
Il nodo principale è quello del Centro di coordinamento che comprende le 4 componenti e
il database interno DBCC.
Questo nodo è il nodo di calcolo principale dell’intero sistema ed è connesso tramite
protocollo http(S) ai nodi UL ed MV. E’ inoltre connesso tramite 3G/4G con i vari mezzi di
trasporto.
Il nodo UL è il nodo in cui vengono create le bolle di carico. In questo nodo sono presenti
le due componenti previste per l’Ufficio Logistico e il Database DBUL.
I nodi relativo ai mezzi di trasporto, connessi al CC attraverso 3G/4G, contengono il
dispositivo che permette la comunicazione ed il sensore GPS.
Inoltre, oltre al sistema esterno MV, è presente il nodo dell’operatore.
DIAGRAMMA DI DEPLOYMENT – DISTRIBUITA (1)
DIAGRAMMA DI DEPLOYMENT – DISTRIBUITA (2)
La seconda soluzione proposta è una soluzione distribuita e prevede 7
nodi.
Questa soluzione prevede la decentralizzazione delle basi di dati (sia
DBCC sia DBUL) in modo che il server debba solo offrire le funzionalità del
sistema, senza preoccuparsi della gestione dei dati. Ciò fa si che ci sia un
minore carico di lavoro del server.
Questa soluzione, di contro, presenta una necessità di linea sicura per
interagire con i DB.
ANALISI DEI COSTI
DEVICE PER MT
Sim Card Tim + Abbonamento
mensile solo internet 4G:
15 € una tantum + 5 €/mese
Tablet Asus LTE: 300 / 350 € cad.
DEVICE PER CC
PC Desktop: 250 / 300 € cad.
COSTI DI SISTEMA (1)
Supponiamo di utilizzare due
database a prestazioni elevate,
come mostrato in figura. I due
database sono: DBCC e DBUL.
COSTI DI SISTEMA (2)
Abbiamo supposto l’utilizzo di
una macchina virtuale con 2 core
e 7gb di RAM a causa del gran
numero di dati da elaborare.
RISORSE UMANE INIZIALI
Assumiamo che siano necessari 5 mesi per la realizzazione dell’intero sistema. Gli sviluppatori
dovranno lavorare 8 ore al giorno per uno stipendio di 15 €/h (con una pausa di un’ora). Per la
realizzazione di tale progetto consideriamo un team composto da 5 persone qualificate.
5 persone * 15 €/h * 8 h * 20 giorni lavorativi * 5 mesi = 60.000,00 €
SISTEMA
Supponiamo inoltre che ci sia bisogno, per la manutenzione e l’aggiornamento del sistema di
due tecnici che lavorino 8 ore al giorno tutti i giorni per uno stipendio di 10 €/h.
2 persone * 10 €/h * 8 h * 20 giorni lavorativi = 3.200,00 €/mese
COSTI TOTALI
Assumiamo che l’azienda conti 110 mezzi di trasporto e 25 operatori. 10 mezzi di trasporto
saranno considerati ‘’di scorta’’.
1) Costi iniziali
Tablet Asus
Sim Card Tim
PC
Risorse Umane
325 € * 110 = 35.750,00 €
15 € * 110 = 1.650,00 €
275 € * 25 = 6.875,00 €
60.000,00 €
104.275,00 €
2) Costi di Gestione Annuale
Database
Virtual Machine
Abbonamento annuale Sim
Tecnici IT
784,27 € * 12 = 9,411,24 €
225,87 € * 12 = 2.236,08 €
550,00 € * 12 = 6.600,00 €
3.200,00 € * 12 = 38.400,00 €
56.647,32 €
ARCHITETTURA DATI
SCHEMA LOGICO E CONCETTUALE – DBUL
BC (ID, Data, IDMerce, IDDP, IDMT)
DP (ID, Via, CAP, Città)
Mezzo (ID, QtaTrasportabile)
Merce (ID, Tipo, Descrizione)
BCContieneMerce (IDMerce,IDBC, Qta)
Le chiavi primarie sono evidenziate in Grassetto.
Le chiavi esterne sono Sottolineate.
SCHEMA LOGICO – DBCC
BollaDiCarico (ID, Data, IDMerce, IDDP, IDMT, qta)
DP (ID, Via, CAP, Città)
MT (ID, IDautista)
Autista (ID, Nome, Cognome)
Scostamento (IDMT, IDPP, InfoUtili, differenzatempo, differenzaKm)
Statistiche (Data, IDMT, IDDP, Scostamento)
PP(ID, Data, OraPartenza, Arrivo, NomeVia, CI, CF)
TrattaViaria (CoordinataIniziale, CoordinataFinale, NomeVia, Città, Lunghezza)
Le chiavi primarie sono evidenziate in Grassetto.
Le chiavi esterne sono Sottolineate.
SCHEMA CONCETTUALE – DBCC
ETEROGENEITA’ E CORRISPONDENZE INTERSCHEMA
SCHEMA LOGICO GLOBALE
DP (ID, Via, CAP, Città)
Merce (ID, Tipo, Descrizione)
BCContieneMerce (IDMerce,IDBC, Qta)
BC (ID, Data, IDMerce, IDDP, IDMT, qta)
DP (ID, Via, CAP, Città)
MT (ID, IDAutista, QtaTrasportabile)
Autista (ID, Nome, Cognome)
Scostamento (IDMT, IDPP, InfoUtili, differenzatempo, differenzaKm)
Statistiche (Data, IDMT, IDDP, Scostamento)
PP (ID, Data, OraPartenza, Arrivo, NomeVia, CI, CF)
TrattaViaria (CoordinataIniziale, CoordinataFinale, NomeVia, Città, Lunghezza)
SCHEMA CONCETTUALE GLOBALE
MAPPING GAV (1)
DBCC - Autista
CREATE VIEW Autista AS
SELECT *
FROM DBCC.Autista
DBCC - Scostamento
CREATE VIEW Scostamento AS
SELECT *
FROM DBCC.Scostamento
DBCC - Statistiche
CREATE VIEW Statistiche AS
SELECT *
FROM DBCC.Statistiche
MAPPING GAV (2)
DBCC – TrattaViaria
CREATE VIEW TrattaViaria AS
SELECT *
FROM DBCC.TrattaViaria
DBCC - PP
CREATE VIEW PP AS
SELECT *
FROM DBCC.PP
DBUL - Merce
CREATE VIEW Merce AS
SELECT *
FROM DBUL.Merce
MAPPING GAV (3)
DBUL/DBCC - DP
CREATE VIEW DP AS
SELECT DBCC.ID, DBCC.Via, DBCC.CAP, DBCC.Città
FROM DBCC.DP
UNION
SELECT DBUL.ID, DBUL.Via, DBUL.CAP, DBUL.Città
FROM DBUL.DP
DBUL/DBCC - MT
CREATE VIEW MT AS
SELECT DBCC.ID, DBCC.IDAutista, DBUL.QtaTrasportabile
FROM DBCC.MT
JOIN FROM DBUL.Mezzo
WHERE DBCC.ID=DBUL.ID
MAPPING GAV (4)
DBUL/DBCC - BC
CREATE VIEW BC AS
SELECT DBCC.ID, DBCC.Data, DBCC.IDMerce, DBCC.IDMT, DBCC.IDDP
FROM DBCC.BollaDiCarico
UNION
SELECT DBUL.ID, DBUL.Data, DBUL.IDMerce, DBUL.IDMT, DBUL.IDDP
FROM DBUL.BC
QUERY SULLO SCHEMA GLOBALE (1)
«Trovare, per ogni DP, i mezzi di trasporto che, diretti a quella destinazione periferica, hanno effettuato
meno di 1km di scostamento. Ordinati in modo crescente per scostamento fatto»
SELECT DP.ID, MT.ID, Scostamento.differenzaKm AS ScostamentoKM
FROM DP, BC, MT, Scostamento
WHERE BC.IDDP=DP.ID AND MT.ID=BC.IDMT AND
MT.ID=Scostamento.IDMT AND ScostamentoKM<1000
ORDER BY ScostamentoKM
QUERY SULLO SCHEMA GLOBALE CON UNFOLDING (1)
«Trovare, per ogni DP, i mezzi di trasporto che, diretti a quella destinazione periferica, hanno effettuato
meno di 1km di scostamento. Ordinati in modo crescente per scostamento fatto»
SELECT DBUL.DP.ID, DBCC.MT.ID, DBCC.Scostamento.differenzaKm
AS ScostamentoKM
FROM DBUL.DP, DBUL.BC, DBCC.MT, DBCC.ScostamentoKM
WHERE DBUL.BC.IDDP= DBUL.DP.ID AND DBCC.MT.ID=
DBUL.BC.IDMT AND DBCC.MT.ID=Scostamento.IDMT AND
ScostamentoKM<1000
ORDER BY ScostamentoKM
QUERY SULLO SCHEMA GLOBALE (2)
«Trovare, per ogni consegna di “articoli farmaceutici”, i DP che hanno costretto i mezzi di trasporto a
passare da “Erba”»
SELECT Merce.ID, MT.ID, Scostamento.differenzaKm AS ScostamentoKM
FROM DP, BC, PP, TrattaViaria, PPcompostoDA
WHERE Merce.ID=BC.IDmerce AND BC.IDDP=DP.ID AND PP.ID=BC.IDPP
AND PP.IDPP=PPcompostoDA.IDPP AND
PPcompostoDA.Via=TrattaViaria.NomeVia AND Merce.Tipo=”Articoli
Farmaceutici” AND TrattaViari.Città=”Erba”
QUERY SULLO SCHEMA GLOBALE CON UNFOLDING (2)
«Trovare, per ogni consegna di “articoli farmaceutici”, i DP che hanno costretto i mezzi di trasporto a
passare da “Erba”»
SELECT DBUL.Merce.ID, DBUL.DP.ID, DBCC.PP.IDPP
FROM DBUL.DP, DBUL.BC, DBCC.PP, DBCC.TrattaViaria
WHERE DBUL.Merce.ID= DBUL.BC.IDmerce AND
DBUL.BC.IDDP=DBUL.DP.ID AND DBCC.PP.ID= DBUL.BC.IDPP
AND DBCC.PP.NomeVia= DBCC.TrattaViaria.NomeVia AND
DBUL.Merce.Tipo=”Articoli Farmaceutici” AND
DBCC.TrattaViari.Città=”Erba”
INTERAZIONE TRA CC E MV (1)
La replicazione è una tecnologia supportata dai maggiori DBMS moderni, che consente di
condividere oggetti e dati di un database tra molteplici DBMS. Per ottenere questo risultato,
un cambiamento ad un elemento presente in un database deve propagarsi sugli altri,
solitamente remoti. Abbiamo scelto di applicare queste tecnica al nostro caso perchè
presenta le seguenti proprietà:
• Availability (disponibilità del servizio): è l’intervallo temporale in cui il sistema funziona
correttamente. La replicazione migliora questa proprietà in quanto rende il sistema meno
sensibile ai guasti.
• Performance (efficienza): la velocità del sistema migliora poiché non dobbiamo ogni
volta accedere ad una base di dati esterna.
• Backup and Recovery: la presenza di dati replicati permette di evitare backup espliciti
del DB di interesse evitando molteplici accessi alla base principale.
INTERAZIONE TRA CC E MV (2)
L’architettura scelta per regolare la replicazione è quella Master-Slave. Questa architettura
è caratterizzata dalla presenza di due nodi: uno, il nodo ‘Master’, è quello della base di
dati esterna al sistema, mentre il nodo ‘Slave’ risiede nel CC e viene aggiornato
giornalmente.
INTERAZIONE TRA CC E MV (3)
La tipologia di replicazione che abbiamo scelto è quella Asincrona (store and forward). Essa
prevede la presenza di due transazioni: una transazione master aggiorna la base di dati
principale dopodiché, ogni giorno, viene fatta un’altra transazione per aggiornare le base di dati
replicate.
La scelta è ricaduta su questo tipo di replicazione poiché quella Sincrona aumenterebbe
esponenzialmente i costi e il tempo. Essa infatti ad ogni transazione-master fa corrispondere una
transazione-slave tenendo aggiornata la base di dati replicata ma penalizzando gli aspetti
sopracitati.
FINE