PROGETTO DI ARCHITETTURA DEL
SOFTWARE E DEI DATI
APPELLO: 20/07/2016
STUDENTE: NICOLÒ RONCONI
MATRICOLA: 771287
PROGETTO
Un’azienda si occupa della progettazione e installazione di centraline di distribuzione dell’energia elettrica. Le
centraline sono sparse sul territorio e sono dotate di sensori per la misura istantanea della potenza erogata. Si deve
progettare un sistema di gestione operativa (SGO) che:
1. acquisisce “in tempo reale” i dati dalle singole centraline. Il dato rilevabile dai sensori è la potenza istantanea
erogata (in kw);
2. verifica se si verificano situazioni anomale (picchi di potenza anomali rispetto ai limiti previsti per la centralina),
3. nel caso di situazioni anomale, disattiva la centralina e notifica l’anomalia al servizio tecnico centrale;
4. supporta le decisioni del servizio tecnico centrale per identificare l’operatore più adatto (per disponibilità,
vicinanza geografica, competenze tecniche relative al tipo di centralina) a riparare il guasto;
5. notifica all’operatore l’intervento da effettuare;
6. consente all’operatore di comunicare al servizio tecnico l’avvio dell’intervento e il suo completamento.
REQUISITI FUNZIONALI
Acquisire i dati dalle varie centraline sparse sul territorio
Verificare situazioni anomale nelle centraline
Disattivare le centraline guaste
Notificare anomalie al STC
Supportare STC per identificare operatore adatto a sistemare il guasto
Notificare all’operatore l’intervento da svolgere
Consentire all’operatore di comunicare lo stato dei lavori al STC
AMBIGUITÀ
Interazione con il Sistema Tecnico Centrale
Interazione con Operatore Tecnico
Disattivazione Centraline
Supporto dell’SGO per l’identificazione dell’operatore più adatto
ASSUNZIONI – INTERAZIONE CON STC
Il Sistema Tecnico Centrale è un ente che comunica con l’SGO attraverso una web app. E’ un ente composto da
persone che si assicurano che i guasti alle centraline vengano risolti.
ASSUNZIONI – INTERAZIONE CON OPERATORE
L’operatore tecnico si occupa di gestire e risolvere i guasti relativi alle centraline sparse sul territorio. L’operatore
risiede nella sede/dipartimento di appartenenza in attesa di un guasto. Quando riceve una notifica dall’SGO per un
guasto (può essere ideata una app/web app che riceve notifiche push oppure semplicemente con una mail o un
SMS) ed è disponibile, si reca verso la centralina guasta e comunica all’SGO (che a sua volta rigira la notifica al
STC) l’inizio dei lavori. Quando l’operatore ha terminato il lavoro, lo notifica all’SGO.
ASSUNZIONI- DISATTIVAZIONE CENTRALINE
l’SGO (grazie ai dati ricevuti dalle centraline) verifica se le centraline funzionano correttamente. In caso contrario
deve disattivare la centralina. Questo può venire in via remota (disattivando automaticamente la centralina)
oppure si può incaricare ad un operatore di disattivare in loco la centralina. Per la modellazione del nostro
sistema utilizzeremo la disattivazione automatica in remoto.
ASSUNZIONI – IDENTIFICAZIONE OPERATORE
L’SGO deve supportare STC per l’identificazione di un operatore per sistemare il guasto di una centralina.
L’identificazione viene fatta in primis controllando la disponibilità dell’operatore e le competenze richieste per
quel tipo di guasto e per quel tipo di centralina. Infine viene scelto l’operatore più vicino geograficamente alla
centralina in questione.
L’SGO si prende carico di identificare l’operatore prendendo in considerazione la disponibilità e le competenze
tecniche richieste. Dopodiché notifica al STC tutti gli operatori in grado di sistemare il guasto. Il STC sceglie
l’operatore in base alla vicinanza geografica e lo comunica all’SGO che notifica l’intervento da svolgere
all’operatore scelto.
ARCHITETTURA DEL PROBLEMA
Casi d’uso
Data Model
Diagrammi delle attività
CASI D’USO
DATA MODEL
ACQUISIZIONE DATI CENTRALINA
GESTIONI SITUAZIONI ANOMALE
IDENTIFICAZIONE OPERATORE
COMUNICAZIONE OPERATORE / STC
ARCHITETTURA LOGICA
Partizionamento Verticale
Partizionamento Orizzontale
PARTIZIONAMENTO ORIZZONTALE
Unico componente per ricevere i dati dalle
centraline, analizzarli e gestire le anomaline. Dopo
aver generato un’anomalia viene gestista dal
componente stesso, cosi come l’identificazione
dell’operatore e la comunicazione con il STC.
Molteplicità {1...N} per ogni centralina
PARTIZIONAMENTO ORIZZONTALE - FOOTPRINT
Astrazione
100
Sharing
80
Complessità
60
40
20
IntraFlow
Frequenza
0
ExtraFlow
Delay
Localizzazione
PARTIZIONAMENTO VERTICALE
Componente per la ricezione dei dati con
molteplicità {1...N} per ogni centralina
Componente per il controllo dei dati e la gestione
delle anomalie con molteplicità {1...N} per ogni
centralina
Componente per supportare il STC nell’identificare
l’operatore con molteplicità {1...N} per ogni
anomalia generata
Componente per gestire la comunicazione tra
l’operatore e il STC con moleplicità {1...N} per ogni
Intervento assegnato a un Operatore
PARTIZIONAMENTO VERTICALE - FOOTPRINT
Astrazione
100
Sharing
80
Complessità
60
40
20
IntraFlow
Frequenza
0
ExtraFlow
Delay
Localizzazione
ARCHITETTURA LOGICA – SOLUZIONE SCELTA
La soluzione sceltà è la seconda, in quanto i valori sono più bassi. In particolare il livello di astrazione è migliore in
quanto ogni componente si occupa di un solo livello di astrazione.
La complessità la frequenza e il ritardo si riducono.
L’extra-flow si riduce in quanto i componenti interagiscono con uno o due attori.
L’intra-flow è basso in quanto i componenti non si scambiano informazioni tra di loro.
I componenti sono compatti (ossia lo spread dei componenti sulle dimensioni è minimo), cioè omogenei e
facilmente integrati tra di loro
E isolati cioè hanno poche intersezioni e dipendenze tra di loro. Un componente isolato è la chiave di un sistema
scalabile in quanto indipendente ai cambiamenti di altri componenti.
ARCHITETTURA CONCRETA
Diagrammi di sequenza
DIAGRAMMI DI SEQUENZA – ACQUISIZIONE DATI
DIAGRAMMI DI SEQUENZA – GESTIONE ANOMALIA
DIAGRAMMI DI SEQUENZA – IDENTIFICAZIONE OPERATORE
DIAGRAMMI DI SEQUENZA – COMUNICAZIONE STC/OPERATORE
DEPLOYMENT ARCHITECTURE
Components diagram
DEPLOYMENT – SOLUZIONE 1
Unico Componente. Tutti i componenti logici
all’interno di una sola macchina.
L’STC e gli operatori tecnici comunicano con il
server SGO attraverso una web app. Quindi sono
dotati di dispositivi con una connessione internet per
scambiarsi informazioni attraverso protocollo HTTP
DEPLOYMENT – SOLUZIONE 2
3 componenti fondamentali:
Server Ricezione Dati: un server per l’acquisizione dati
dalle centraline(attraverso i sensori) e l’update del DB
Server SGO: un server centrale che si occupa di
controllare i dati, di segnalare anomalie al STC e di
gestire la comunicazione tra operatore e STC.
Database server
L’STC e gli operatori tecnici comunicano con il
server SGO attraverso una web app. Quindi sono
dotati di dispositivi con una connessione internet per
scambiarsi informazioni attraverso protocollo HTTP
DEPLOYMENT – SOLUZIONE 3
3 componenti fondamentali:
Server di ricezione dati che: riceve i dati dalle centraline,
elabora i dati e aggiorna il DB e se si verifica una anomalia
notifica l’STC.
Database Server
Server SGO: gestisce la comunicazione tra STC e
Operatori e supporta l’identificazione degli operatori.
L’STC e gli operatori tecnici comunicano con il server
SGO attraverso una web app. Quindi sono dotati di
dispositivi con una connessione internet per scambiarsi
informazioni attraverso protocollo HTTP
DEPLOYMENT – ARCHITETTURA SCELTA
L’architettura di deployment scelta è la terza in quanto il componente «Gestore Anomalia» deve controllare che
la potenza erogata non supera il limite di potenza della centralina. Mettere questo componente su due nodi
distinti vuol dire duplicare il carico di lavoro in quanto deve continuamente controllare lo stato del DB. Se lo si
unisce al nodo che riceve i dati può automaticamente controllare il dato e successivamente inserirlo nel database.
Inoltre i server di ricezione dati sono multipli(n server) in quanto le centraline inviano dati ogni secondo. In
questo caso la scalabilità del sistema è ottimale in quanto, utilizzando un load balancer, si riesce a distribuire il
traffico senza sovraccaricare uno specifico server.
Il server SGO possiede un web server per poter comunicare con STC e gli operatori (attraverso una web app)
utilizzando un servizio REST.
SCELTE TECNOLOGICHE
Scelte Hardware
Scelte Software
Stima dei costi
SCELTE TECNOLOGICHE – PROTOCOLLI E RETI DI
COMUNICAZIONE
Sensori di rilevazione della potenza collegati ad un microcontrollore che comunica tramite protocollo MQTT via
Wi-Fi. MQTT è un protocollo posizionato in cima a TCP/IP ed è stato disegnato per le situazioni in cui è richiesto
un basso impatto e dove la banda è limitata.
Il ‘Server Ricezione Dati’ e il ‘Server SGO’ comunicano con il ‘DB Server’ attraverso protocollo TCP/IP via
Ethernet.
Il server SGO per gestire la comunicazione (tra operatore e STC) e per la scelta dell’operatore, utilizza il
protocollo HTTP (Implementando un servizio REST) attraverso Ethernet.
L’operatore comunica con SGO con HTTP attraverso 3G/4G/WiFi con un dispositivo smart.
SCELTE ARCHITETTURALI
2 Soluzioni principali:
Approccio IaaS
Approccio PaaS
APPROCCIO IAAS
Con un approccio IaaS chiediamo ad un Service Provider di fornirci l’infrastruttura adatta per il nostro sistema
AWS
Server Ricezione Dati:
2 Server
Banda di 100 Mbit/s
16 GB RAM
Processore 8GHz
Load Balancer per distribuire il carico di elaborazione
Server SGO:
2 Server (di cui 1 di replica)
16 GB RAM
Processore 8GHz
DB Server:
2 Server(di cui 1 di replica)
32 GB RAM
Processore 8GHz
Storage 1 TB
APPROCCIO PAAS
Approccio PaaS: consente di accedere alle risorse necessarie al momento opportuno
Microsoft Azure
1 Service MySQL (DB Server)
1 Service Application (Server SGO)
1 datahub / event hub (Server Ricezione Dati)
ARCHITETTURA – SOLUZIONE SCELTA
Si è scelto di utilizzare l’approccio IaaS con AWS in quanto il sistema scalerà solo per quanto riguarda i ‘Server
Ricezione Dati’.
In questo caso basta aggiungere più Server in parallelo gestiti da un Load Balancer.
SCELTE SOFTWARE
Server Ricezione Dati
Linux Server (Ubuntu 14.04 LTS)
C++ per ottimizzare il processo di ricezione dati e update del DB MySQL
Server SGO
Linux Server (Ubuntu 14.04 LTS)
Node.js v4.4.7 LTS per implementazione di un web server e API REST
DB Server
MySQL Server
STIMA DEI COSTI DI SVILUPPO
Implementazione Back-end
Implementazione Web App
IMPLEMENTAZIONE BACK-END
Implementazione Back-end
2 Sviluppatori full-time
1 System Administrator part-time (deployment, networking, gestione server)
1 Database Administrator full-time (gestione, ottimizzazione e deployment del database)
50 giorni lavorativi + 10 giorni di scarto per lo sviluppo, testing, analisi del problema, raccolta requisiti….
Prezzo del team: 220 euro/gg medio per persona (880€/giorno)
Totale: circa 52,500 €
Maintenance
1 Sviluppatore full-time
1 System Administrator part-time
1 Database Administrator part-time
Circa 500€/giorno
On demand
IMPLEMENTAZIONE WEB APP
Implementazione Web App
2 Sviluppatori Front-end
1 UX Designer
20 giorni lavorativi + 5 giorni di scarto
Prezzo di Team medio: 200€/giorno per persona (600€)
Totale Circa: 15.000 €
Maintenance
1 Sviluppatore full-time
1 UX Designer part-time
250€/giorno
On demand
STIMA COSTI
Costi HW: circa 6.000€/anno
Costi Sviluppo: circa 70.000€
ARCHITETTURA DEI DATI
Schemi concettuali
Schemi logici
Data Integration
Query
SCHEMA CONCETTUALE SGO
SCHEMA LOGICO SGO
Centralina(ID, Tipo, Stato, LimiteKw, Longitude, Latitude)
DatoCentralina(ID, PotenzaErogata, Timestamp, CentralinaID)
Anomalia(ID, Timestamp, CentralinaID)
Intervento(ID, Stato, TimestampCreazione, TimestampInizio, TimestampFine, AnomaliaID, OperatoreID)
Operatore(ID, IndirizzoSede, Disponibilità, RuoloTecnico, Nome, Cognome)
Competenza(ID, Tipo, Descrizione)
Competenza_Operatore(ID, CompetenzaID, OperatoreID)
SCHEMA LOGICO SGP
Dipendente(CF, Nome, Cognome, CittaNascita, Ruolo, IndirizzoDipartimento)
Retribuzione(Ruolo, stipendio, Livello)
Presenza(ID, DipendenteCF, data)
SCHEMA CONCETTUALE SGP – REVERSE ENGINEERING
Attraverso il reverse engineering traduciamo lo schema logico di SGP in un modello concettuale
DATA INTEGRATION (SGO – SGP)
Definiamo lo schema globale ottenuto per mezzo della integrazione dei due schemi concettuali
I due schemi presentano delle eterogeneità e delle corrispondenze
Integrazione con Virtual Data Integration: creazione di uno schema logico globale che fornisce una interfaccia
unificata dei dati.
DATA INTEGRATION – ETEROGENEITÀ E CORRISPONDENZE
SGO
SGP
Tipo
Note
Operatore
Dipendente
Iperonimia (IS-A)
Si utilizza Dipendente perchè è
un concetto più generale
Operatore.RuoloTecnico Dipendente.Ruolo
Sinonimia
Si utilizza Ruolo
Operatore.IndirizzoSede
Dipendente.IndirizzoDipartimento
Sinonimia
Si utilizza IndirizzoSede
Operatore.ID
Dipendente.CF
Sinonimia
Si utilizza CF
=
SCHEMA GLOBALE
DATA INTEGRATION – MAPPING E MODALITA’ DI INTEGRAZIONE
Client
Mappatura tra lo schema globale e gli schemi locali (SGO - SGP)
Client
Descrive come ogni elemento nello schema locale si collega a quello
globale
I mapping vengono espressi per mezzo di viste
L’informazione
viene combinata logicamente
«interrogata» attraverso una interfaccia comune
Global Schema
View
cosi
View
Mediator
viene
Attraverso un mediatore viene creato un schema (virtuale) unificato
e la query viene trasformata in sotto-query una per ogni schema
locale coinvolto. I risultati vengono poi uniti.
Il Wrapper traduce la richiesta che proviene dal mediatore nella
rappresentazione logico/fisica dello schema locale
Wrapper
Wrapper
LocalSchema
LocalSchema
DB SGO
DB SGP
Utilizzeremo l’approccio GAV (Global as View). Lo schema globale è
espresso in termini degli schemi locali
CREAZIONE VISTE – DIPENDENTE
CREATE VIEW G_Dipendente(CF, Nome, Cognome, cittaNascita, indirizzoSede, Disponibilità, Ruolo) AS
SELECT SGO.ID AS CF, SGO.Nome, SGO.Cognome,SGP.cittaNascita, SGO.indirizzoSede, SGO.Disponibilità, SGP.Ruolo
FROM SGO.Operatore AS SGO JOIN SGP.Dipendente AS SGP ON SGO.ID = SGP.CF
CREAZIONE VISTE – PRESENZA, RETRIBUZIONE
CREATE VIEW G_Presenza(ID, Data, G_DipendenteCF) AS
SELECT ID, Data, DipendenteCF as G_DipendenteCF
FROM SGP.Presenza
CREATE VIEW G_Retribuzione(Ruolo, Stipendio, Livello) AS
SELECT Ruolo, Stipendio, Livello
FROM SGP.Retribuzione
CREAZIONE VISTE – COMPETENZA, COMPETENZA_OPERATORE
CREATE VIEW G_Competenza(ID,Tipo,Descrizione) AS
SELECT ID, Tipo, Descrizione
FROM SGO.Competenza
CREATE VIEW G_Competenza_Operatore(ID,CompetenzaID,OperatoreID) AS
SELECT ID,CompetenzaID,OperatoreID
FROM SGO.Competenza
CREAZIONE VISTE: ANOMALIA, INTERVENTO
CREATE VIEW G_Intervento(ID, Stato, TimestampCreazione, AnomaliaID, OperatoreID, TimestampInizio,TimestampFine) AS
SELECT ID, Stato, TimestampCreazione, AnomaliaID, OperatoreID, TimestampInizio, TimestampFine
FROM SGO.Intervento
CREATE VIEW G_Anomalia(ID, Timestamp, CentralinaID) AS
SELECT ID, Timestamp, CentralinaID
FROM SGO.Anomalia
CREAZIONE VISTE: CENTRALINA, DATOCENTRALINA
CREATE VIEW G_Centralina(ID, Tipo, Stato, LimiteKw, Latitude, Longitude) AS
SELECT ID, Tipo, Stato, LimiteKw, Latitude, Longitude
FROM SGO.Centralina
CREATE VIEW G_DatoCentralina(ID, PotenzaErogata, Timestamp, CentralinaID) AS
SELECT ID, PotenzaErogata, Timestamp, CentralinaID
FROM SGO.DatoCentralina
INTERROGAZIONI SULLO SCHEMA GLOBALE – QUERY 1
Selezionare il nome e il cognome degli operatori che hanno iniziato i lavori di manutenzione di una centralina in
data = 10/05/2015 e con uno stipendio di 1.500 €
SELECT Nome, Cognome
FROM G_Dipendente as GD
JOIN G_Intervento AS GI ON GD.CF = GI.OperatoreID
JOIN G_Retribuzione AS GR ON GD.Ruolo = GR.Ruolo
WHERE DATE(GI.TimestampInizio) = ’10/05/2015’ AND GR.Stipendio = ‘1500’
Unfolding
SELECT OP.Nome, OP.Cognome
FROM SGO.Operatore AS Op
JOIN SGO.Intervento AS In ON Op.ID = In.OperatoreID
JOIN SGP.Retribuzione AS Re ON Re.Ruolo = Op.RuoloTecnico
WHERE DATE(In.TimestampInizio) = ’10/05/2015’ AND Re.Stipendio = ‘1500’
INTERROGAZIONI SULLO SCHEMA GLOBALE – QUERY 2
Selezionare il CF degli operatori che hanno finito i lavori di manutenzione su una centralina in data 02/02/10 e che
hanno una presenza in data 01/02/03
SELECT CF
FROM G_Dipendente as GD
JOIN G_Intervento AS GI ON GD.CF = GI.OperatoreID
JOIN G_Presenza AS GP ON GD.CF = GP.DipendenteCF
WHERE DATE(GI.TimestampFine) = ’02/02/2010’ AND GP.Data = ’01/02/03’
Unfolding
SELECT Op.ID
FROM SGO.Operatore AS Op
JOIN SGO.Intervento AS In ON Op.ID = In.OperatoreID
JOIN SGP.Presenza AS Pr ON Pr..DipendenteCF = Op.ID
WHERE DATE(In.TimestampFine) = ’02/02/2010’ AND Pr.Data = ’01/02/03’
