@@ -7,12 +7,13 @@ Le funzionalità sviluppate e implementate nei microservizi sono le seguenti:
- Metodo di deterrenza delle intrusioni
# 1. Specifiche funzionali
## 1.1. Controllo tramite sensori ed attuatori
Il sistema nella LAN è costituito da una BeagleBone (BB), 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.
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. Accessibilità via internet
I servizi in Cloud consistono nei seguenti servizi:
- Sistema di autenticazione per l'accesso ai servizi basato su token JWT (JSON Web Token)
- Sistema di autenticazione per l'accesso ai servizi basato su Token JWT (JSON Web Token)
- Webserver che fornisce una Webapp, con la quale è possibile controllare gli elementi nella LAN
- Domain Manager (DM) per la gestione dei domini e dei relativi servizi e responsabile di mantenere la consistenza dei dati
- Cloud App Manager (CAM), che s'interfaccia con il broker mosquitto connesso in bridge con la BB nella LAN.
...
...
@@ -24,9 +25,11 @@ Questi servizi sono stati resi sicuri con l'implementazione di HTTPS e WSS usand
## 2.1. Installazione del sistema in reti private
L'installazione del sistema avviene senza configurazioni particolari poiché utilizzando mosquitto con la configurazione da noi impostata, è sufficiente collegare il sistema alla rete internet per avere le funzionalità richieste disponibili.
## 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 insieme grazie all'utilizzo del bridging. Questo permette ai microservizi, alla Webapp ed al CAM di comunicare come se fossero nella stessa LAN.
La connettibilità è indistintamente garantita sia all'interno della LAN sia al suo esterno grazie all'impiego di brokers Mosquitto, tutti connessi insieme grazie all'utilizzo del bridging.
Questo permette ai microservizi, alla Webapp ed al CAM 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 come appena spiegato.
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 come appena spiegato.
## 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 deve risultare al pari o migliore dell'esperienza analogica.
...
...
@@ -36,21 +39,25 @@ La componente umana non è precisamente quantificabile, ma proporzionale nella q
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.
L'implementazione di microservizi riduce il tempo di installazione grazie alla dimensione inferiore dei file che ogni microservizio richiede.
<!-- Secondo me dovremmo scrivere qualcosa di più -->
# 3. Approccio tecnologico
## 3.1. Vantaggi dell'uso di un message broker e come lo giudichiamo rispetto alle altre scelte
Il message broker risulta fondamentale nello sviluppo di un'applicazione formata da vari microservizi, poiché permette a questi di registrarsi all'ascolto di topic specifici dai quali ricevere i messaggi degli altri microservizi. In questo modo il lavoro svolto da ogni microservizio è inferiore rispetto ad un progetto dello stesso tipo che non si avvale dell'utilizzo di MQTT.
Il message broker risulta fondamentale nello sviluppo di un'applicazione formata da vari microservizi, poiché permette a questi di registrarsi all'ascolto di topic specifici dai quali ricevere i messaggi degli altri microservizi.
In questo modo il lavoro svolto da ogni microservizio è inferiore rispetto ad un progetto dello stesso tipo che non si avvale dell'utilizzo di MQTT.
La scelta effettuata risulta migliore rispetto all'uso di chiamate REST per la sua scalabilità. Volendo rappresentare il sistema 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.
La scelta effettuata risulta migliore rispetto all'uso di chiamate REST per la sua scalabilità.
Volendo rappresentare il sistema 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.
L'utilizzo di mosquitto assicura il recapito di oggi messaggio nel numero a noi necessario. La scelta di utilizzare il protocollo MQTT è dovuta al fatto che è un protocollo molto semplice e leggero, che permette di inviare messaggi in modo molto veloce e sicuro; inoltre poiché tutto il sistema dev'essere connesso, questo protocollo permette di evitare l'invio di messaggi a tutti i microservizi, ma solo a quelli che sono interessati al messaggio, poiché ognuno comunica su un topic diverso, differente almeno per dominio e sottodominio.
L'utilizzo di mosquitto assicura il recapito di ogni messaggio nel numero a noi necessario.
La scelta di utilizzare il protocollo MQTT è dovuta al fatto che è un protocollo molto semplice e leggero, che permette di inviare messaggi in modo molto veloce e sicuro; inoltre poiché tutto il sistema dev'essere connesso, questo protocollo permette di evitare l'invio di messaggi a tutti i microservizi, ma solo a quelli che sono effettivamente interessati al messaggio. Questo è possibile poiché ognuno di essi sottoscrive un topic diverso, differente almeno per dominio e sottodominio.
Anche la manutenibilità migliora: infatti, se si volesse modificare un microservizio, non sarebbe necessaria la modifica del codice di tutti il sistema, ma solo quello del microservizio in questione ed eventualmente del message broker.
Anche la manutenibilità migliora: infatti, se si volesse modificare un microservizio, non sarebbe necessaria la modifica del codice di tutto il sistema, ma solo quello del microservizio in questione ed eventualmente del message broker.
# 4. Architettura del software
## 4.1. Organizzazione del software (evidenziandone i moduli)
Il sistema si suddivide in 4 parti:
- La LAN domestica
- Il Cloud
-Un Webserver
-Il Webserver
- L'istanza di Keycloak per l'autenticazione.
Nella LAN è presente la porzione di sistema che si occupa di comandare le luci, l'allarme e gli scenari.
...
...
@@ -59,41 +66,46 @@ Essa è composta da una BB sulla quale operano il broker Mosquitto, i microservi
In Cloud sono presenti il DM che interroga il Database (DB) ed il CAM che gestisce i microservizi in LAN.
Inoltre è presente un broker Mosquitto a cui sono connessi in bridging quello presente sulla BB e quello a cui si affaccia la Webapp.
Il Webserver …
Il Webserver permette la gestione da remoto dei sensori e degli attuatori della LAN fornendo la Webapp.
L'istanza di Keycloak si occupa di gestire l'autenticazione degli utenti.
## 4.2. Distribuzione delle funzionalità tra i moduli, attività e loro interazione
(ognuno si scriva i suoi 2)
(cosa fa ogni modulo)
<!-- (ognuno si scriva i suoi 2)
(cosa fa ogni modulo) -->
### 4.2.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 DM 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 tramite API REST.
### 4.2.2. Keycloak
<!--DA FARE elisa-->
### 4.2.3. Domain Manager
Il DM è un microservizio che opera in Cloud, con funzionalità da server REST ed interagisce con il DB dell'intero sistema. Si occupa di soddisfare le richieste HTTPS provenienti dalla Webapp, controllandone la validità e la consistenza col DB e inoltrarle al CAM richiamando degli URI esposti da quest'ultimo. Dopo aver verificato l'autorizzazione tramite il token fornito da Keycloak, il DM interagisce con il DB ed effettua la chiamata al CAM. Terminate queste due interazioni, viene servita la risposta alla Webapp.
=> poco chiaro (Alfredo)
Il DM è un microservizio che opera in Cloud, con funzionalità da server REST ed interagisce con il DB dell'intero sistema.
Si occupa di soddisfare le richieste HTTPS provenienti dalla Webapp, controllandone la validità e la consistenza col DB e inoltrarle al CAM richiamando degli URI esposti da quest'ultimo.
Dopo aver verificato l'autorizzazione tramite il Token fornito da Keycloak, il DM interagisce con il DB ed effettua la chiamata al CAM.
Terminate queste due interazioni, viene servita la risposta alla Webapp.
<!-- => poco chiaro (Alfredo) -->
### 4.2.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 è 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 per le seguenti variazioni nel microservizio: 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 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.
Gestisce la deterrenza delle intrusioni riproponendo uno schema di accensione e spegnimento delle luci quando l'utente attiva l'antifurto.
Lo schema registra lo stato delle luci dopo che l'utente ha attivato la modalità di apprendimento; alla sua disattivazione, la registrazione è immediatamente disponibile poiché viene salvata 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 scenario è attivo; il secondo permette il funzionamento dell'automa e memorizza lo stato attuale; il terzo è usato per salvare gli interruttori e la luce attualmente in uso.
- Antifurto
<!--DA FARE elisa-->
<!--DA FARE elisa: qui mettiamo una descrizione breve del microservizio-->
### 4.2.5. Arduino
Questo componente della LAN scrive sul broker Mosquitto della BB i valori del sensore di luminosità, usato dal microservizio delle luci. Questo microservizio usa il valore del sensore di luminosità per decidere se l'ambiente è abbastanza buio da dover accendere le luci nel caso in cui il sensore di movimento invii un messaggio.
Questo componente della LAN scrive sul broker Mosquitto della BB i valori del sensore di luminosità, usato dal microservizio delle luci per decidere se l'ambiente è abbastanza buio da dover accendere le luci nel caso in cui il suo sensore di movimento invii un messaggio.
### 4.2.6. Cloud App Manager
<!--DA FARE chi?, direi da NON FARE-->
### 4.2.7. Broker Mosquitto (smartcity)
(cosa c'è da scrivere?) <!--forse no?-->
<!-- (cosa c'è da scrivere?) forse no? -->
# 5. Descrizione dell'implementazione
## 5.1. UML delle classi implementate
- Domain Manager
...
...
@@ -101,13 +113,17 @@ Questo componente della LAN scrive sul broker Mosquitto della BB i valori del se
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.
A seconda dell'URI richiamato viene istanziato un handler diverso, che verifica il token JWT tramite la classe Helper che a sua volta richiama TokenHandler.
Da qui viene effettuata una chiamata all'URI della nostra istanza di Keycloak per ottenere la chiave pubblica. Dopo di ciò il body del JWT che era stato precedentemente inviato nel payload della richiesta della Webapp viene firmato con la chiave pubblica e se il risultato è uguale alla firma inviata nel JWT stesso allora l'utente è verificato.
Una volta verificato è possibile ottenere il nome dell'utente e distinguere i domini di cui è utente comune o amministratore. Da questo punto, a seconda dei servizi richiesti dalla WebApp, si aprono diversi scenari di interazione con il DB ed il CloudApp (Install, Delete, Start, Stop).
Le chiamate si risolvono una volta che il CloudApp risponde al Domain, ossia possiamo considerare la chiamata al CloudApp incapsulata in termini di tempo all'interno della chiamata da parte della WebApp al Domain.
Questa classe 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.
A seconda dell'URI richiamato viene istanziato un handler diverso, che verifica il token JWT grazie alla classe TokenHandler.
Per verificare che l'utente sia autenticato, viene effettuata una chiamata all'URI della nostra istanza di Keycloak per ottenere la chiave pubblica. Dopo di ciò il body del JWT che era stato precedentemente inviato nel payload della richiesta della Webapp viene firmato con la chiave pubblica e se il risultato è uguale alla firma inviata nel JWT stesso allora l'utente è verificato.
Confermata l'autenticazione dell'utente, è possibile ottenerne il nome utente e distinguere i domini di cui è utente comune o amministratore. A questo punto, a seconda dei servizi richiesti dalla Webapp, si aprono diversi scenari di interazione con il DB ed il CAM (Install, Delete, Start, Stop).
Le chiamate si risolvono una volta che il CAM manda la sua risposta, quindi possiamo considerare la chiamata al CAM incapsulata in termini di tempo all'interno della chiamata da parte della Webapp al DM.
La persistenza del sistema è affidata ad un DB SQLite locale.
- Luci
...
...
@@ -115,15 +131,20 @@ La persistenza del sistema è affidata ad un DB SQLite locale.
Il microservizio Luci opera in LAN e serve a gestire l'accensione e spegnimento delle lampade nella casa.
la classe principale è Luci.java che opera su un ArrayList di oggetti di tipo Luce, che è la struttura dati fondamentale per il funzionamento del microservizio.
L'oggetto Luce è definito dal quartetto input, output, stato e nome.
La classe principale è Luci.java che opera su un ArrayList di oggetti di tipo Luce, la struttura dati fondamentale per il funzionamento del microservizio definita dal quartetto input, output, stato e nome.
Input è la stringa "IN" seguita dal numero che rappresenta quella sorgente in input della GPIO, ovvero un attuatore.
Output è la string "OUT" seguita dal numero che rappresenta quello specifico output della GPIO.
Stato è un boolean che corrisponde all'accensione o spegnimento della lampadina.
Nome è il nome della sala a cui appartiene la luce ed è il suo ID.
La classe Subscriber serve a leggere i comandi dai topic e ad attuarli. Per essere istanziata necessita di un Esecutore, Luci ed il sensore di movimento.
Esecutore è la classe che si occupa di attuare l'accensione a tempo delle luci, sfruttando un timer. Necessita di Luci per accedere all'ArrayList<Luce>. Qualora dovesse arrivare un segnale di accensione da parte del sensore di movimento e le luci fossero già accese, Subscriber provvede ad eliminare il vecchio timer e istanziarne uno nuovo.
Esecutore è la classe che si occupa di attuare l'accensione a tempo delle luci, sfruttando un timer. Necessita di Luci per accedere all'ArrayList<Luce>.
Il sensore di luminosità presente sull'arduino impedisce ai sensori di movimento di operare se la stanza è troppo illuminata, ovvero se è giorno.
Subscriber legge i comandi dai topic e li gestisce. Per istanziare questa classe, è necessaria un'istanza di Esecutore, Luci ed del sensore di movimento.
Qualora dovesse arrivare un segnale di accensione da parte del sensore di movimento e le luci fossero già accese, Subscriber provvede ad eliminare il vecchio timer dell'Esecutore ed istanziarne uno nuovo.
Questo meccanismo è trasparente al sistema degli attuatori "tradizionali", quindi se un utente vuole accendere una luce tramite interruttore potrà farlo sempre e comunque.
Ad ogni modifica dello stato delle luci corrisponde una modifica del file di stato locale (zona.json), al fine di mantenere le ultime impostazioni in caso di malfunzionamenti o cali di tensione. Questo file viene letto all'avvio del microservizio ed è ciò che garantisce la persistenza.
...
...
@@ -131,20 +152,30 @@ Ad ogni modifica dello stato delle luci corrisponde una modifica del file di sta
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.
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
Il microservizio degli scenari contiene 4 classi fondamentali: Scenari, Automa, SubscribeCallback ed Esecutore.
Scenari è la classe principale: fa partire il microservizio ed espone alle altre classi il metodo per l'invio dei messaggi MQTT, il path delle cartelle di configurazione e di risorse (nella quale si trova la cartella in cui sono salvati gli scenari) e gli IN e OUT in uso sulla GPIO.
L'automa gestisce lo stato in cui si trova il microservizio, che può essere uno dei seguenti: spento, in fase di apprendimento e in fase di esecuzione. Questa classe espone i getter e setter dello stato, permettendo alle altre classi d'interfacciarsi. Per salvaguardare la persistenza, l'automa salva lo stato in cui si trova in un file di testo.
SubscribeCallback è la classe che gestisce la ricezione dei messaggi MQTT. Quando riceve un messaggio, lo elabora con un metodo ad hoc che permette di gestirlo autonomamente.
Il microservizio Scenari contiene 4 classi fondamentali: Scenari, Automa, SubscribeCallback ed Esecutore.
Scenari è la classe principale: fa partire il microservizio ed espone alle altre classi il metodo per l'invio dei messaggi MQTT, il path delle cartelle di configurazione e di risorse (nella quale si trova la cartella in cui sono salvati gli scenari) e gli IN e OUT attualmente in uso sulla GPIO.
L'automa gestisce lo stato in cui si trova il microservizio, che può essere uno dei seguenti: spento, in fase di apprendimento o in fase di esecuzione. Questa classe espone i getter e setter dello stato, permettendo alle altre classi di sapere in qualunque momento quali sono le operazioni possibili. Per salvaguardare la persistenza, l'automa salva lo stato in cui si trova in un file di testo.
SubscribeCallback è la classe che gestisce la ricezione dei messaggi MQTT. Quando riceve un messaggio, lo elabora con un metodo ad hoc che permette di gestirlo autonomamente, anche grazie ai metodi esposti dalle altre classi.
Esecutore è la classe che gestisce l'esecuzione degli scenari a partire dai file presenti nella cartella di risorse. Consiste di un ciclo infinito nel quale si leggono tutti gli scenari salvati e (nel caso in cui l'automa sia nella fase di esecuzione) si fa partire il primo utile, ovvero il primo scenario che ha un orario di esecuzione futuro. In caso contrario, il Thread si sospende per evitare computazione inutile.
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-->
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 spiegata nel dettaglio-->
## 5.2. Descrizione della UI
### 5.2.1. Autenticazione
...
...
@@ -153,29 +184,33 @@ La prima pagina che viene fornita serve per ridirigere l'utente alla pagina di l
### 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 è cliccabile, consentento la sua attivazione/spegnimento. Al contrario, se non è un amministratore e il dominio è attualmente attivo, egli può solamente accedere alla pagina d'interazione.
In questa pagina vengono mostrati tutti i domini appartenenti all'utente autenticato. Nel caso in cui l'utente sia amministratore di un particolare dominio, alla destra dello stato di quel dominio viene mostrato un cestino, per poterlo eliminare; inoltre il bottone dello stato è cliccabile, consentento la sua attivazione/spegnimento. Al contrario, se non è un amministratore e il dominio è attualmente attivo, egli può solamente accedere alla pagina d'interazione.
### 5.2.3. Interazione con il proprio dominio
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
-Homepage
La pagina principale della Webapp permette l'interazione completa con il sistema. Questo significa che il suo utilizzo permette di avere sia una visione real-time di ciò che accade nella LAN, sia di comandare da remoto gli attuatori connessi.
All'avvio della Webapp, viene fatta una RPC ad ogni microservizio installato nel dominio per mostrare correttamente tutti i dati disponibili all'utente; inoltre viene richiesto al server se l'utente è in realtà l'amministratore del dominio, per mostrare funzionalità aggiuntive.
All'avvio della Webapp, viene fatta una RPC ad ogni microservizio installato nel dominio per richiedere e mostrare correttamente tutti i dati attualmente disponibili all'utente; inoltre viene richiesto al server se l'utente è in realtà l'amministratore del dominio, per eventualmente mostrare funzionalità aggiuntive.
In alto si trovano fino a 3 bottoni che, una volta premuti, mostrano la pagina corrispondente al loro microservizio.
In alto si trovano fino a 3 bottoni che, una volta premuti, mostrano la pagina corrispondente al loro microservizio. Di seguito vengono spiegate le pagine che vengono mostrate alla pressione dei bottoni.
- Luci
La pagina è formata da una tabella in cui sono mostrati il nome della luce ed il suo stato. La luce può venire accesa/spenta semplicemente cliccando lo switch che ne mostra lo stato.
<!-- Inserire un'immagine esplicativa -->
La pagina è formata da una tabella in cui sono mostrati il nome della luce ed il suo stato. La luce può venire accesa/spenta semplicemente cliccando l'interruttore che ne mostra lo stato.
Al fondo dell'elenco delle luci, è presente un bottone che permette la creazione di una nuova luce. Questo processo richiede all'utente di scegliere il luogo/nome della luce, un pulsante libero e un led libero della BBGPIO. Nel momento in cui la Webapp riceve la conferma di creazione dal microservizio, la luce appena creata viene mostrata a schermo.
Al fondo dell'elenco delle luci, è presente un pulsante che permette la creazione di una nuova luce. Questo processo richiede all'utente di scegliere il nome della luce, un pulsante libero e un led libero della BBGPIO. Nel momento in cui la Webapp riceve la conferma di creazione dal microservizio, la luce appena creata viene mostrata a schermo.
- Scenari
La pagina è composta da una tabella e da dei bottoni al fondo di essa. Nella tabella vengono mostrati gli scenari (il nome, la data di creazione e lo stato). I bottoni permettono di attivare la funzione di apprendimento e l'antifurto. Nel caso in cui il visualizzatore sia l'amministratore del dominio, è anche presente un terzo bottone per modificare gli interruttori usati.
<!-- Inserire un'immagine esplicativa -->
Questa pagina è composta da una tabella e da dei bottoni al fondo di essa. In questa tabella vengono mostrati gli scenari (il nome, la data di creazione e lo stato), mentre i bottoni permettono di attivare la funzione di apprendimento o l'antifurto. Nel caso in cui il visualizzatore sia l'amministratore del dominio, è anche presente un terzo bottone per modificare gli interruttori usati.
In ogni momento è possibile cambiare lo stato attuale in quello di apprendimento, di antifurto o di attesa.
...
...
@@ -183,11 +218,12 @@ Mentre l'antifurto è spento, tutti gli scenari sono spenti e non è possibile a
- Antifurto
La pagina presenta una barra di attenzione, una campanella e lo stato dell'antifurto; inoltre nel caso in cui si sia amministratore del dominio, è presente un pulsante che permette la configurazione delle porte, l'aggiunta di un sensore di movimento e la modifica della soglia (ovvero del valore oltre il quale far scattare l'allarme).
<!-- Inserire un'immagine esplicativa -->
La pagina presenta una barra di attenzione, una campanella e lo stato dell'antifurto; inoltre nel caso in cui l'utente sia anche amministratore del dominio, è presente un pulsante che permette la configurazione delle porte, l'aggiunta di un sensore di movimento e la modifica della soglia (ovvero del valore oltre il quale far scattare l'allarme).
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).
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
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).
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).
