Il progetto presentato dal gruppo2 si occupa di fornire ad un utente funzionalità di domotica in una LAN. Le funzionalità sviluppate sono le seguenti: controllo remoto delle luci, sistema di antifurto e metodo di deterrenza delle intrusioni.
Il progetto presentato dal gruppo2 si occupa di fornire ad un utente funzionalità di domotica in una LAN, controllabili anche dall'esterno.
Le funzionalità sviluppate e implementate nei microservizi sono le seguenti:
- Controllo remoto delle luci
- Sistema di antifurto
- Metodo di deterrenza delle intrusioni
Inoltre sono state implementate le seguenti … collaterali:
- Sistema di autenticazione per l'accesso ai servizi basato su token JWT
- Webserver e la relativa Webapp per l'interfaccia utente
- Domain Manager (DM) per la gestione dei domini e dei relativi servizi
- Broker MQTT per la comunicazione tra i servizi (in bridging con smartcity-challenge)
# 1. Specifiche funzionali
## 1.1. Controllo tramite sensori ed attuatori
Il sistema nella LAN è costituito da una beaglebone (con attuatori e led) e un arduino (che presenta un sensore di luminosità).
Il sistema nella LAN è costituito da una BeagleBone (BB), con attuatori e led; e un arduino, che presenta un sensore di luminosità.
Gli attuatori simulano gli interruttori e i sensori di movimento. I sensori di movimento permettono il controllo dell'allarme dell'antifurto e, assieme agli interruttori e al sensore di luminosità, dello stato delle luci.
## 1.2. Accessibilita' via internet
I servizi in cloud consistono di un server che fornisce una webapp, con la quale è possibile controllare gli elementi della LAN; il servizio di autenticazione con Keycloak; il domain manager, responsabile di mantenere la consistenza dei dati; e il cloud app manager, il quale s'interfaccia con il broker mosquitto che è connesso in bridge con la beaglebone della LAN.
## 1.2. Accessibilità via internet
I servizi in cloud consistono di un server che fornisce una webapp, con la quale è possibile controllare gli elementi della LAN; il servizio di autenticazione con Keycloak; il DM, responsabile di mantenere la consistenza dei dati; e il Cloud App Manager (CAM), il quale s'interfaccia con il broker mosquitto che è connesso in bridge con la BB della LAN.
I servizi sono stati resi sicuri con l'implementazione di HTTPS e per il broker con TLS (e WSS).
# 2. Analisi
## 2.1. Installazione del sistema in reti private
L'installazione del sistema avviene senza configurazioni particolari poiché l'uso di mosquitto, con la configurazione da noi impostata, rende il sistema plug-n-play, ovvero è sufficiente collegarlo alla rete domestica per avere le funzionalità richieste disponibili.
## 2.2. Accessibilita' da rete pubblica e da rete privata
## 2.2. Accessibilità da rete pubblica e da rete privata
La connettibilità è indistintamente garantita sia all'interno della LAN sia al suo esterno grazie all'impiego di brokers Mosquitto, tutti connessi grazie all'utilizzo del bridging. Questo permette ai microservizi di comunicare come se fossero nella stessa LAN.
In ogni caso, per accedere al servizio, l'utente deve autenticarsi sia per osservare lo stato dei microservizi che per inviare comandi. Il login è gestito grazie a Keycloak che autorizza l'accesso alla webapp, interfacciata al resto del sistema.
Grazie a questa caratteristica, l'accesso può avvenire sia dalla rete pubblica che da quella privata, senza distinzioni.
<!--L'architettura che ne garantisce il funzionamento è la seguente: un broker è posizionato in remoto con IP pubblico e statico (smartcity) al quale si connettono il broker della LAN, della webApp ed il CloudAppManager. In questo modo, con il bridging effettuato a smartcity, siamo in grado di inviare e ricevere messaggi su ogni microservizio che lo richieda. => magari nel capitolo 4?-->
## 2.3. Caratteristiche del traffico dati da sostenere e vincoli in tempo reale
Essendo un sistema di domotica, è necessario che i comandi impartiti dall'utente vengano attutati una ed una sola volta ed in tempo utile, in modo tale da non inficiare l'esperienza dell'utente che risulta quindi al pari o migliore della sua esperienza analogica.
La quantità di traffico da gestire non è eccessiva, poiché le uniche 2 fonti di produzione di messaggi (oltre a quella umana) sono il servizio della GPIO, che pubblica a tempo costante di 10s; ed il microservizio dell'antifurto, che pubblica ogni 8s.
La componente umana non è precisamente quantificabile, ma proporzionale nella quantità di messaggi prodotti rispetto al numero di lampadine, sensori e interruttori utilizzati da ogni dominio.
## 2.4. Tecniche viste a lezione con cui soddisfare i requisiti
Per soddisfare i requisiti, è possibile usare delle chiamate REST o il protocollo MQTT. Entrambe queste modalità sono utilizzabili poiché permettono la comunicazione tra servizi diversi.
...
...
@@ -41,8 +45,7 @@ Il message broker risulta fondamentale nello sviluppo di un'applicazione formata
L'utilizzo di mosquitto assicura il recapito di oggi messaggio nel numero a noi necessario.
La scelta effettuata risulta migliore rispetto all'uso di chiamate REST per la sua scalabilità. Volendo rappresentare il sistmea con un grafo non orientato in cui i nodi sono i microservizi e gli archi rappresentanti delle connessioni tra di essi, grazie al message broker otteniamo un grafo molto più sparso, in cui i microservizi comunicano con il message broker centrale, anzichè istanziare una connessione per ogni altro microservizio.
Anche la manutenibilità migliora. => spiegare
Anche la manutenibilità migliora. <!-- => spiegare -->
# 4. Architettura del software
## 4.1. Organizzazione del software (evidenziandone i moduli)
...
...
@@ -54,21 +57,21 @@ Al corretto funzionamento del sistema partecipano anche un webserver ed un'istan
### 4.1.1. Webserver e Webapp
Il Webserver, configurato per usare HTTPS, fornisce la Webapp al client grazie all'uso di API REST. Il Webserver è in grado di gestire molteplici sessioni allo stesso tempo grazie all'implementazione di Threads.
La Webapp può comunicare con il Message Broker grazie al protocollo MQTT, con il server di autenticazione (Keycloak) con l'utilizzo di token JWT e con il Domain Manager grazie all'uso di API REST.
La Webapp può comunicare con il Message Broker grazie al protocollo MQTT, con il server di autenticazione (Keycloak) con l'utilizzo di token JWT e con il DM grazie all'uso di API REST.
### 4.1.2. Keycloak
<!--DA FARE elisa-->
### 4.1.3. Domain Manager
Il Domain Manager è un microservizio che opera in cloud, con funzionalità sia da server REST sia da client che interagisce con il database (DB) dell'intero sistema. Si occupa di soddisfare le richieste provenienti dalla Webapp, controllandone la validità e la consistenza con il DB e inoltrarle al Cloud App Manager (CAM). Dopo aver verificato l'autorizzazione tramite token di Keycloak interagisce con il DB ed effettua la chiamata al CAM. Terminate queste due interazioni, viene servita la risposta alla Webapp.
Il DM è un microservizio che opera in cloud, con funzionalità sia da server REST sia da client che interagisce con il database (DB) dell'intero sistema. Si occupa di soddisfare le richieste provenienti dalla Webapp, controllandone la validità e la consistenza con il DB e inoltrarle al CAM. Dopo aver verificato l'autorizzazione tramite token di Keycloak interagisce con il DB ed effettua la chiamata al CAM. Terminate queste due interazioni, viene servita la risposta alla Webapp.
=> poco chiaro (Alfredo)
### 4.1.4. BeagleBone (BB)
### 4.1.4. BeagleBone
- Luci
Microservizio che opera in LAN che si occupa di gestire l'accensione e lo spegnimento delle lampadine sia tramite interruttore sia tramite sensori di movimento. I comandi e gli stati delle lampadine vengono letti e scritti su due topic distinti del broker Mosquitto presente sulla BB. La persistenza dello stato del microservizio e' mantenuta in locale su un file testuale in formato JSON, che viene aggiornato ad ogni variazione dello stato, ad esempio accensione o spegnimento di una lampadina, aggiunta di una nuova lampadina e modifica del sensore di movimento.
Microservizio che opera in LAN che si occupa di gestire l'accensione e lo spegnimento delle lampadine sia tramite interruttore sia tramite sensori di movimento. I comandi e gli stati delle lampadine vengono letti e scritti su due topic distinti del broker Mosquitto presente sulla BB. La persistenza dello stato del microservizio è mantenuta in locale su un file testuale in formato JSON, che viene aggiornato ad ogni variazione dello stato, ad esempio accensione o spegnimento di una lampadina, aggiunta di una nuova lampadina e modifica del sensore di movimento.
- Scenari
Gestisce la deterrenza delle intrusioni riproponendo uno schema di accensione e spegnimento delle luci quando l'utente attiva l'antifurto. Lo schema segue precisamente lo stato delle luci scelto dall'utente dopo che questo ha attivato la modalita' di apprendimento; una volta disattivata, lo schema e' disponibile poiche' viene immediatamente salvato su un file come sequenza di JSON. La persistenza e' garantita grazie all'uso di tre file che vengono aggiornati in momenti diversi: uno ricorda quale schema e' attivo; il secondo permette il funzionamento dell'automa e memorizza lo stato attuale; mentre il terzo e' usato per salvare gli interruttori e la luce attualmente in uso.
Gestisce la deterrenza delle intrusioni riproponendo uno schema di accensione e spegnimento delle luci quando l'utente attiva l'antifurto. Lo schema segue precisamente lo stato delle luci scelto dall'utente dopo che questo ha attivato la modalità di apprendimento; una volta disattivata, lo schema è disponibile poiché viene immediatamente salvato su un file come sequenza di JSON. La persistenza è garantita grazie all'uso di tre file che vengono aggiornati in momenti diversi: uno ricorda quale schema è attivo; il secondo permette il funzionamento dell'automa e memorizza lo stato attuale; mentre il terzo è usato per salvare gli interruttori e la luce attualmente in uso.
- Antifurto
<!--DA FARE elisa-->
...
...
@@ -85,9 +88,9 @@ Questo componente della LAN scrive sul broker Mosquitto della BB i valori del se
(davvero dobbiamo scriverlo un altra volta?)-->
# 5. Descrizione dell'implementazione
## 5.1. UML delle classi implementate
- DomainManager
- DomainManager
La classe principale del DomainManager è Domain.java. Essa funge da server REST su Https.
La classe principale del DM è Domain.java. Essa funge da server REST su Https.
Espone le rotte che vengono richiamate dalla WebApp per avviare, installare, creare ed eliminare i domini, oltre a fornire servizi per la corretta visualizazione degli elementi in app.
Prima di operare da server esso effettua una chiamata al nostro repository gitlab per popolare la tabella dei moduli del DB.
In qualità di server si avvale di un threadPoolExecutor e per ogni nuova chiamata istanzia un nuovo thread per servirla.
...
...
@@ -114,7 +117,7 @@ Ad ogni modifica dello stato delle luci corrisponde una modifica del file di sta
- Webserver <!--DA FARE elisa integra con la tua parte (keycloak)-->
Come il Domain Manager, anche il webserver espone delle API REST su HTTPS. Queste API sono richiamate dalla WebApp per ottenere i dati necessari per la visualizzazione delle pagine; in particolare restituiscono le pagine HTML, le immagini, i file CSS e JavaScript. Ogni richiesta viene gestita da un nuovo Thread, che legge il file e lo restituisce; una volta che il Thread ha terminato di rispondere ad una richiesta, viene eliminato; in questo modo il webserver non occupa risorse inutilmente ed è in grado di gestire molte richieste contemporaneamente. È anche presente la classe Helper, che permette di inviare le risposte HTTPS alla Webapp e di fare controlli ripetuti in varie altre classi.
Come il DM, anche il webserver espone delle API REST su HTTPS. Queste API sono richiamate dalla WebApp per ottenere i dati necessari per la visualizzazione delle pagine; in particolare restituiscono le pagine HTML, le immagini, i file CSS e JavaScript. Ogni richiesta viene gestita da un nuovo Thread, che legge il file e lo restituisce; una volta che il Thread ha terminato di rispondere ad una richiesta, viene eliminato; in questo modo il webserver non occupa risorse inutilmente ed è in grado di gestire molte richieste contemporaneamente. È anche presente la classe Helper, che permette di inviare le risposte HTTPS alla Webapp e di fare controlli ripetuti in varie altre classi.
- Scenari
...
...
@@ -126,14 +129,13 @@ Esecutore è la classe che gestisce l'esecuzione degli scenari a partire dai fil
Sono inoltre presenti 2 classi di utilità: UserChangeSync ed Helper. La prima permette all'utente di modificare lo scenario attivo dalla Webapp e quindi di avere un vero impatto su quale scenario stia venendo usato. La seconda espone dei metodi che vengono usati da più classi.
<!--DA FARE elisa la tua parte-->
## 5.2. Descrizione della UI
### 5.2.1. Autenticazione
La prima pagina che viene fornita serve per ridirigere l'utente alla pagina di login su Keycloak; per questo motivo è interamente vuota.
### 5.2.2. Lista di domini
In questa pagina vengono mostrati tutti i domini appartenenti all'utente autenticato. Nel caso in cui questi sia amministratore di un dominio, a destra dello stato viene mostrato un cestino, per poterlo eliminare; inoltre il bottone dello stato e' cliccabile, consentento la sua attivazione/spegnimento. Al contrario, se non e' un amministratore e il dominio e' attualmente attivo, egli puo' solamente accedere alla pagina d'interazione.
### 5.2.3. Interazione con il proprio dominio
Questa e' la pagina principale del progetto, in cui si possono vedere tutti i dettagli del dominio installato. In alto si trovano fino a 3 bottoni che rappresentano i microservizi installati nel dominio scelto. Alla loro pressione, mostrano la UI relativa al loro microservizio, con la quale interagire per apportare modifiche.
Questa è la pagina principale del progetto, in cui si possono vedere tutti i dettagli del dominio installato. In alto si trovano fino a 3 bottoni che rappresentano i microservizi installati nel dominio scelto. Alla loro pressione, mostrano la UI relativa al loro microservizio, con la quale interagire per apportare modifiche.
- Visione d'insieme
...
...
@@ -164,4 +166,6 @@ La pagina presenta una barra di attenzione, una campanella e lo stato dell'antif
Dalla Webapp, un utente normale può solamente attivare/disattivare l'antifurto e controllare il valore a cui è arrivato l'antifurto (oltre a sapere se l'allarme è stato attivato).
# 6. Validazione del software
## 6.1. Procedure usate per verificare il corretto funzionamento del sistema
Test procedurali
La validazione del software è stata effettuata in modo procedurale sia durante la fase di sviluppo che alla sua fine.
Nella fase finale sono stati effettuati test di sistema simulando un ambiente reale: sono stati testati tutti i microservizi assieme alla Webapp e gli altri componenti dell'architettura.
In particolare ogni componente è stato testato in modo autonomo (per verificare che funzionasse correttamente) e in modo combinato (per verificare che funzionasse anche in presenza degli altri componenti).
