@@ -62,16 +62,20 @@ Inoltre è presente un broker Mosquitto a cui sono connessi in bridging quello p
Il Webserver …
L'istanza di Keycloak si occupa di gestire l'autenticazione degli utenti.
### 4.1.1. Webserver e Webapp
## 4.2. Distribuzione delle funzionalità tra i moduli, attività e loro interazione
(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.
### 4.1.2. Keycloak
### 4.2.2. Keycloak
<!--DA FARE elisa-->
### 4.1.3. Domain Manager
### 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)
### 4.1.4. BeagleBone
### 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.
...
...
@@ -83,17 +87,13 @@ Gestisce la deterrenza delle intrusioni riproponendo uno schema di accensione e
- Antifurto
<!--DA FARE elisa-->
### 4.1.5. Arduino
### 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.
### 4.1.6. Cloud App Manager
<!--DA FARE chi?-->
### 4.1.7. Broker Mosquitto (smartcity)
(cosa c'è da scrivere?)
## 4.2. Distribuzione delle funzionalità tra i moduli, attività e loro interazione
(ognuno si scriva i suoi 2)
(cosa fa ogni modulo)
<!--DA FARE elisa, alfredo, alessandro
(davvero dobbiamo scriverlo un altra volta?)-->
### 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?-->
# 5. Descrizione dell'implementazione
## 5.1. UML delle classi implementate
- Domain Manager
...
...
@@ -190,4 +190,4 @@ Dalla Webapp, un utente normale può solamente attivare/disattivare l'antifurto
## 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).
\ No newline at end of file
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).
