Progetto di architettura del software e dei dati Appello: 20/07

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’