Merge remote-tracking branch 'refs/remotes/origin/master'

update

relazione/relazione.md

@@ -16,7 +16,7 @@ I servizi sono stati resi sicuri con l'implementazione di HTTPS e per il broker
 ## 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à disponibili.
 
-## 2.2. Accessibilita' da rete pubblica e da rete privata 
+## 2.2. Accessibilita' da rete pubblica e da rete privata
 Tutti i microservizi comunicano tra di loro grazie a connessioni ai broker mosquitto. I due broker sono connessi tra loro grazie al bridging, che ci permette di effettuare lo scambio di comandi su entrambi i servizi.
 
 La connettibilità è indistintamente garantita sia da LAN sia da remoto grazie all'impiego di brokers Mosquitto. 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 ongi microservizio che lo richieda.
@@ -42,32 +42,31 @@ Anche la manutenibilità migliora.
 
 # 4. Architettura del software
 ## 4.1. Organizzazione del software (evidenziandone i moduli)
-- Webserver e Webapp
+### 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 e' in grado di mantenere molteplici sessioni allo stesso tempo. 
+- Il Webserver, configurato per usare HTTPS, fornisce la Webapp al client grazie all'uso di API REST. Il Webserver e' in grado di mantenere molteplici sessioni allo stesso tempo.
 Ogni richiesta effettuata tramite API e' gestita da un nuovo Thread, il quale esegue il codice di una classe; una volta gestita la richiesta, il Thread viene eliminato.
 
-La Webapp e' suddivisa in 3 parti:
- 
+- La Webapp e' suddivisa in 3 parti:
     - L'autenticazione: la prima pagina che viene fornita serve per ridirigere l'utente alla pagina di login su Keycloak.
     - La 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.
-    - L'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. 
-- Keycloak
+    - L'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.
+### 4.1.2. Keycloak
 
-- Domain Manager
+### 4.1.3. Domain Manager
 
 Il Domain Manager e' un microservizio che opera in cloud, con funzionalita' sia da server REST sia da client con interazioni con il database (DB) dell'intero sistema. Si occupa di soddisgare le richieste provenienti dalla Webapp, controllandone la validita' e la consistenza con il DB e inoltrarle al Cloud App Manager (CAM). Ogni richiesta della Webapp viene soddisfatta istanziando un nuovo Thread e, dopo aver verificato l'autorizzazione tramite token di Keycloak, interagisce con il DB e effettua una chiamata al CAM. Terminate queste due interazioni, viene servita la risposta alla Webapp.
-- BeagleBone (BB)
-    - Mosquitto
-    - Luci: Microservizio che opera in LAN che si occupa di gestire l'accensione e lo spegnimento delle lampadine sia tramite interruttore che tramite sensori di movimento. Nel caso in cui il sensore crepuscolare di Arduino rileva che e' giorno, il sensore di movimento non viene attivato. 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' mantenuto in locale su un file testuale in formato JSON, che viene aggiornato ad ogni variazione dello stato, ad esempio accensione o spegnimento di una lampadine, 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.
-    - Antifurto
-- Arduino
+### 4.1.4. BeagleBone (BB)
+- Mosquitto
+- Luci: Microservizio che opera in LAN che si occupa di gestire l'accensione e lo spegnimento delle lampadine sia tramite interruttore che tramite sensori di movimento. Nel caso in cui il sensore crepuscolare di Arduino rileva che e' giorno, il sensore di movimento non viene attivato. 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' mantenuto in locale su un file testuale in formato JSON, che viene aggiornato ad ogni variazione dello stato, ad esempio accensione o spegnimento di una lampadine, 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.
+- Antifurto
+### 4.1.5. Arduino
 
 Questo componente della LAN scrive sul broker Mosquitto della BB i valori del sensore di luminosita', usato dal microservizio delle luci.
-- Cloud App Manager
+### 4.1.6. Cloud App Manager
 
-- Broker Mosquitto (smartcity)
+### 4.1.7. Broker Mosquitto (smartcity)
 
 ## 4.2. Distribuzione delle funzionalita' tra i moduli, attivita' e loro interazione
 (ognuno si scriva i suoi 2)
@@ -77,25 +76,26 @@ Questo componente della LAN scrive sul broker Mosquitto della BB i valori del se
 ## 5.1. UML delle classi implementate
 
 ## 5.2. Descrizione della UI
+### 5.2.1. Visione d'insieme
 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.
 
 In alto si trovano fino a 3 bottoni che, una volta premuti, mostrano la pagina corrispondente al loro microservizio.
 
-- Luci
+### 5.2.2. 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.
 
 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.
-- Scenari
+### 5.2.3. 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.
 
-In ogni momento è possibile cambiare lo stato attuale in quello di apprendimento, di antifurto o di attesa. 
+In ogni momento è possibile cambiare lo stato attuale in quello di apprendimento, di antifurto o di attesa.
 
 Mentre l'antifurto è spento, tutti gli scenari sono spenti e non è possibile attivarli; viceversa all'attivazione dell'antifurto viene immediatamente attivato uno scenario da parte del microservizio, che può essere cambiato (attivando uno scenario diverso) o disabilitato (spegnendo lo scenario attivo).
-- Antifurto
+### 5.2.4. 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).