Post on 21-Jan-2022
Universita degli Studi di Messina
Facolta di informatica
Relazione di Ingegneria del So�ware
Implementazione di interazioni traAlexa e sistemi domotici eterogenei
Professore:Prof. Salvatore Distefano
Studente:
Alessio Mobiliamatr. 461704
Anno Accademico 2018/19
Indice
1 Il progetto 5
1.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Arancino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 OpenHab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 IoTronic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 NodeRed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6 ESP32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.7 MQTT e homie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.8 Amazon Alexa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2 Scrum 9
2.1 I valori . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 I Ruoli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Gli artefa�i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1
2.4 Le cerimonie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.1 Sprint Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.2 Daily Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.3 Backlog grooming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.4 Sprint review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.5 Sprint Retrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3 Sviluppo del Progetto 15
3.1 Analisi dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.1 User requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.2 System requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2 Caso d’uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3 Archite�ura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3.1 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4 Component-Deployment Diagram . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.5 Activity Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.6 Archite�ura 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.6.1 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.7 Component-Deployment Diagram . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.8 Activity Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2
3.9 Skill Component Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.10 So�ware Utilizzati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4 Iterazioni 32
4.1 Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1.1 Sprint Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1.2 Grooming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1.3 Sprint Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.1.4 Sprint Retrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.1.5 Burndown Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2 Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.1 Sprint Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.2 Grooming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.3 Sprint Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.4 Sprint Retrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.5 Burndown Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3 Sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3.1 Sprint Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3.2 Grooming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3.3 Sprint Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3
4.3.4 Burndown Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.4 Sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.4.1 Sprint Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.4.2 Grooming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.4.3 Sprint Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.4.4 Burndown Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.5 Sprint 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.5.1 Sprint Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.5.2 Grooming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.5.3 Sprint Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.5.4 Burndown Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5 Conclusioni 43
4
Capitolo 1
Il progetto
1.1 Introduzione
Si vuole realizzare un sistema domotico intelligente che perme�e di integrare dispositivi etero-
genei e non necessariamente smart. I dispositivi dovranno poter essere controllati sia tramite
comandi vocali, sia tramite un’interfaccia web.
In particolare si e creata un’archite�ura che vede al centro il dispositivo realizzato
da SmartMe chiamato “arancino”. Sul dispositivo e stato installato e con�gurato OpenHab per
la gestione dei dispositivi in locale, il broker Mosqui�o per controllare device che utilizzano
il protocollo mq�, NodeRed per la gestione del �usso dati proveniente dall’esterno e per l’in-
tegrazione con il sistema IoTronic. Il proge�o ha richiesto lo sviluppo di una skill per Alexa,
che e hostata sui server di Amazon grazie al servizio lambda. Per veri�care il funzionamen-
to del sistema e stato con�gurato un device ESP32 per funzionare da lampadina smart che si
appoggia al protocollo mq� per comunicare con l’istanza di OpenHab sull’Arancino.
5
1.2 Arancino
L’Arancino e una board creata da SmartMe grazie all’esperienza nel mondo Arduino combinata
con l’esperienza universitaria. �esto prodo�o presenta come core una Raspberry pi 3 b+
gestita da un sistema operativo personalizzato basato su Raspbian.
1.3 OpenHab
Open Home Automation Bus e una pia�aforma open source per l’automazione della casa.
Perme�e di integrare molti devices e sistemi, fornendo quindi un tool molto �essibile per
realizzare l’automazione completa della casa.
OpenHab comunica ele�ronicamente con dispositivi smart e non. Per riuscire in
questo divide in compartimenti certe funzioni e operazioni.
Di seguito una breve descrizioni delle operazioni principali:
Conce�i Signi�cati
Bindings sono i componenti che forniscono l’interfaccia per interagire con i dispositivi
�ings Sono la prima rappresentazione dei dispositivi su OpenHab
Channels Sono le connessioni tra “Items” e “�ings”
Items Sono la rappresentazione delle informazioni che riguardano i dispositivi
Rules Sono le regole che perme�ono l’automatizzazione di certi comportamenti
Sitemap E’ l’interfaccia che rappresenta le informazioni e le interazioni con dispositivi
1.4 IoTronic
IoTronic e un sistema molto complesso sviluppato nella sede universitaria di Messina. Per
quanto e necessario sapere per questo proge�o IoTronic perme�e di rendere visibile l’arancino
6
all’esterno della rete domestica in cui si trova, e�e�ua cioe il tunnelling delle informazioni tra
l’arancino e i device esterni alla sua rete.
Potremmo dire che sostanzialmente associa ad alcune porte aperte sull’arancino un
indirizzo ip pubblico. �esto e necessario a�nche la skill Alexa possa comunicare dire�amen-
te con l’Arancino.
1.5 NodeRed
NodeRed e un tool per collegare visivamente diversi device hardware. Fornisce un editor
browser-based che perme�e di collegare facilmente diversi �ussi di informazione e aggiungere
numerose regole.
NodeRed perme�e quindi nel nostro proge�o di poter controllare facilmente i di-
versi �ussi di dati che arrivano all’arancino da un’unico tool, in modo da facilitare le future
manutenzioni e le modi�che dell’archite�ura.
1.6 ESP32
ESP32 e un microcontrollore con wi� integrato a basso costo. Il microcontrollore e stato facil-
mente programmato in c utilizzando l’IDE arduino a�nche simuli un dispositivo controllato
tramite mq�. In particolare simula una lampadina smart.
Nello sviluppo e stata utilizzata la libreria opensource homie.h che per perme�ere al
dispositivo di utilizzare la convenzione homie per gestire la comunicazione mq�
7
1.7 MQTT e homie
MQTT e un protocollo ISO standard di messaggistica di tipo publish-subscribe. E’ proge�ato
per essere utilizzato per le situazioni in cui e richiesto un basso impa�o e dove la banda e
limitata. Richiede un message broker responsabile della distribuzione dei messaggi ai client
destinatari. In particolare e stato utilizzato mosqui�o.
Per quanto riguarda il dispositivo di test e stato utilizzato la convenzione Homie per
il il discovery automatico, la con�gurazione e l’uso del dispositivo. Il topic devono seguire lo
schema standard identi�cato dalla convenzione homie: homie / device ID / $device-a�ribute
1.8 Amazon Alexa
Amazon Alexa e un assistente personale intelligente sviluppato da Amazon. E’ possibile am-
pliare le funzionalita di Alexa sviluppando le cosidde�e “skill”. L’assistente si a�iva al coman-
do vocale “Alexa”, dopo di che si aspe�a di ricevere una frase de�a “u�erance”, queste frasi
potranno a�ivare delle particolari funzioni de�e “intent” .
Vi sono diverse tipologie di skill, quelle utili al nostro proge�o sono le skill smart
home. Le skill SmartHome devono essere in grado di rispondere ad una richiesta di tipo Di-
scovery. La risposta conterra un elenco dei dispositivi con cui la skill e in grado di interagire e
le funzioni a cui essi sono abilitati. Le skill devono risiedere su un server sicuro e devono poter
comunicare dire�amente con il cloud di Alexa. �est’ultimo inviera alla skill delle richieste
HTTPS contenenti, in formato JSON, i parametri per la richiesta e aspe�andosi una risposta
forma�ata secondo i canoni de�niti da Amazon.
Le skill vengono hostate da amazon e il codice viene eseguito dalla pia�aforma di
calcolo serverless guidata agli eventi fornita da amazon : AWS Lambda.
8
Capitolo 2
Scrum
Scrum e un framework agile per la gestione del ciclo di sviluppo del so�ware, iterativo ed
incrementale, concepito per gestire proge�i e prodo�i so�ware o applicazioni di sviluppo
Scrum enfatizza tu�i gli aspe�i di gestione di proge�o legati a contesti in cui e di�-
cile piani�care in anticipo. Vengono utilizzati meccanismi propri di un ”processo di controllo
empirico”, in cui cicli di feedback che ne costituiscono le tecniche di management fondamentali
risultano in opposizione alle classiche.
Scrum si basa sulla teoria dei controlli empirici di analisi strumentale e funzionale
di processo o empirismo. Ovvero si basa sul fa�o che la conoscenza deriva dall’esperienza e
che le decisioni si basano su cio che si conosce. Scrum utilizza un metodo intera�ivo ed un
approccio incrementale per o�imizzare la prevedibilita ed il controllo del rischio
E’ proprio per questo motivo che e stato scelto Scrum come tecnica di management
per lo sviluppo di questo proge�o. I canoni non potevano essere ben de�niti e sono infa�i stati
alterati piu volte durante lo svolgimento del proge�o. �indi una volta visionati i problemi
del proge�o i canoni sono stati modi�cati nel corso dello sviluppo.
Se fosse stata utilizzata una tecnica classica, come ad esempio Waterfall, sicuramente
la modi�ca dei canoni del proge�o sarebbe stata piu costosa in termini di tempo. �indi
9
l’utilizzo di una metodologia agile ha portato dei risultati notevoli e ha permesso di portare un
risultato tangibile velocemente.
2.1 I valori
Le tecniche pratiche che si fanno in Scrum devono avere un fondamento “teorico” e anche “eti-
co”, senza questi valori si rischia di cadere in una implementazione meccanica che porta poco
lontano. Il lavoro di squadra insito in Scrum ra�orza tali valori che appaiono come principi
condivisi e acce�ati da tu�i i membri coinvolti.
I valori sono:
• concentrazione: per lavorare bene bisogna concentrarsi su poche cose alla volta.
• coraggio: lavorare in squadra presuppone il sostegno di tu�i i compagni, questo da il
coraggio per a�rontare compiti impegnativi
• Apertura: lavorare in squadra presuppone che tu�i si aprano con gli altri membri del
team. E’ bene esprimere i propri problemi e le proprie preoccupazioni per trovare una
soluzione insieme.
• Impegno: Per avere un controllo maggiore sulle nostre azioni e necessario un impegno
costante.
• Rispetto: Per lavorare in squadra in modo sereno e necessario rispe�arsi e aiutarsi
vicendevolmente.
2.2 I Ruoli
Fino a qualche tempo fa le persone all’interno dell’organizzazione venivano divise tra maiali
e polli. (I maiali erano coloro stre�amente legati al proge�o, mentre i polli erano legati al
10
proge�o solo parzialmente). Successivamente la divisione e stata abolita per evitare o�ese.
I ruoli maggiormente coinvolti sono:
• Product Owner (PO): rappresentante del commi�ente del proge�o. Il suo compito e
quello di analizzare le richieste degli Stake Holder per tradurle al Team di Sviluppo.
Nel caso di questo proge�o il Product Owner e identi�cabile nella persona dell’ Ing.
Giovanni Merlino.
• ScrumMaster (SM): e al servizio del Dev Team e del PO, il suo compito e di sorvegliare
che il processo venga “implementato” nel modo corre�o. Deve inoltre rimuovere gli
ostacoli che gli vengono segnalati. Nell’a�uale proge�o lo Scrum Master e il Do�. Mauro
Staiti.
• il Dev Team e il gruppo di sviluppo che svolge il lavoro di implementazione. Decide le
scelte implementative ma non puo in alcun modo interferire sul cosa debba essere rea-
lizzato. Il team di sviluppo in questo proge�o e composto solamente dalla mia persona:
Alessio Mobilia.
Mentre i ruoli meno coinvolti sono gli Stake Holder, i manager e tu�e le altre
persone che si possono ritentere interessate al proge�o a qualsiasi titolo.
2.3 Gli artefatti
Scrum evita lunghe fasi di pre-analisi che spesso non portano alcun vantaggio evidente. Scrum
spinge su una rapida piani�cazione di massima per ridurre gli sprechi e massimizzare il va-
lore a�eso. �esto e possibile a�raverso degli artefa�i utilizzati nella piani�cazione e nello
sviluppo stesso del proge�o.
11
• il product backlog e una lista ordinata di requisiti relativi al prodo�o. Ad ogni elemento
del Backlog viene assegnata una priorita dal Product Owner. Le funzionalita aggiunte al
backlog sono comunemente scri�e utilizzando il formato delle “storie”.
• Lo spring backlog e la lista del lavoro che il team di sviluppo deve e�e�uare nel corso
dello sprint successivo. Il team di sviluppo prende gli elementi in ordine dal product
backlog e li aggiunge allo sprint backlog secondo quanto crede di poter svolgere in un
solo sprint.
• Incremento: e la somma di tu�i gli elementi del product backlog completati
• Burndown Chart: e la rappresentazione gradica del lavoro da fare su un proge�o nel
tempo.
2.4 Le cerimonie
L’unita base dello sviluppo di Scrum e lo sprint. E’ di durata �ssa e dura generalmente da una
a qua�ro se�imane. Gli Sprint sono ripetuti �no al termine del proge�o. Lo sprint e composto
da diverse fasi descri�e in questo capitolo.
12
2.4.1 Sprint Planning
all’inizio di ogni spirint viene tenuti un incontro dove viene piani�cato il lavoro da portare
a termine durante lo sprint. Nella prima parte insieme al PO l’intero Scrum Team de�nisce
l’insieme di storie su cui impegnarsi e il Dev Team assaegna ad ogni storia un peso. Spesso e
utilizzata la tecnica del Planning Poker. Viene quindi aggiornato lo sprint backlog
2.4.2 Daily Scrum
Ogni giorno durante lo spring viene tenuta una veloce riunione tra tu�i i membri del team di
sviluppo e lo Scrum master. L’obie�ivo e quello di aggiornare tu�i i membri sul proseguimento
del lavoro e risolvere eventuali problematiche.
2.4.3 Backlog grooming
Il team dovrebbe impiegare del tempo durante lo spring per e�e�uare il product backlog groo-
ming. �esto e un processo di stima del backlog esistente utilizzando il criterio sforzo/punti e
ra�nando i criteri di acce�azione, dividendo le storie piu grandi in storie di minore grandezza.
2.4.4 Sprint review
Alla �ne dello sprint si tiene l’incontro di sprint review per ispezionare l’incremento e ada�are
il product backlog. Si identi�ca cio che e stato fa�o e cio che non e stato fa�o. Si discute su
cosa e andato bene e gli eventuali problemi incontrati e come sosno stati risolti. Il team di
sviluppo mostra il lavoro fa�o. Vengono eventualmente e�e�uati dei test sul funzionamento.
13
2.4.5 Sprint Retrospective
La sprint retrospective e l’occasione per il Team Scrum per auto-ispezionarsi e creare un piano
di migliramento da a�uare nel prossimo sprint. Lo scopo e quello di esaminare come e andato
l’ultimo sprint, per quanto riguarda le relazione, le persone e gli strumenti.
14
Capitolo 3
Sviluppo del Progetto
3.1 Analisi dei requisiti
Nei metodi agili, come anche in Scrum, l’analisi dei requisiti e eseguita in modo incrementale
a�raverso l’utilizzo delle user stories, ma per chiarezza si vuole de�nire i requisiti del proge�o
inziale.
3.1.1 User requirement
I Requisiti utente descrivono i requisiti funzionali e non funzionali in modo comprensibile per
gli utenti del sistema che non hanno un’approfondita conoscenza tecnica informatica.
• Un utente deve poter controllare con comandi vocali i dispositivi.
• Un utente deve poter aggiungere diversi dispositivi.
• Un utente deve poter controllare lo stato dei dispositivi.
• Un utente deve poter controllare i dispositivi anche da un computer o smartphone senza
utilizzare comandi vocali.
15
3.1.2 System requirement
I requisiti di sistema de�niscono le funzioni, i servizi e i vincoli operativi del sistema in modo
de�agliato.
Requisiti funzionali
I requisiti funzionali descrivono cosa il sistema deve o dovrebbe fare.
• Il sistema deve poter essere connesso a qualsiasi tipo di dispositivo smart e non, che
utilizzi qualsiasi tipo di tecnologia di comunicazione.
• Il sistema deve essere con�gurabile in locale.
• Il �usso di informazioni proveniente dall’esterno della rete locale dovrebbe poter essere
interamente controllato
Requisiti non funzionali
I requisiti non funzionali descrivono come il sistema deve o dovrebbe fornire i servizi richiesti.
Requisiti del prodotto: sono i requisiti che ne speci�cano il comportamento
• Il sistema deve poter essere controllato tramite l’assistente vocale Alexa.
• Il sistema deve poter essere controllato tramite interfaccia web.
• Il sistema deve includere la board di sviluppo ”Arancino”
• Il sistema deve includere il so�ware open-source OpenHab.
16
requisiti organizzativi: sono i requisiti che riguardano le politiche e le procedure di orga-
nizzazione del team.
• Deve essere utilizzato il metodo Scrum.
• Non vi e alcuna restrizione sul linguaggio di programmazione della skill Alexa.
requisiti esterni: Sono i requisiti che derivano da fa�ori esterni al sistema e al processo di
sviluppo.
• �alsiasi modi�ca ad OpenHab e al framework su cui e fondato (ecliplse smart home)
devono essere pubblicate secondo la licenza ”Eclipse Public License - v 2.0”.
• Non sono richiesti requisiti di riservatezza.
requisiti di dominio: Sono i requisiti che derivano dall’applicazione del sistema e ne ri�et-
tono i limiti e le necessita a�che il sistema funzioni.
• Per l’uso dei comandi vocali deve essere richiesta una connessione ad internet
• Per l’uso dei comandi tramite interfaccia web non deve essere necessario avere una
connessione ad internet a pa�o che si sia connessi alla stessa rete locale dell’arancino.
• E’ necessaria una rete locale.
3.2 Caso d’uso
Le funzioni principali del proge�o possono essere descri�e con un Use Case Diagram. Descri-
vono i servizi o�erti cosı come sono percepiti dagli a�ori stessi, in questo caso l’utente.
17
3.3 Architettura
Il proge�o e stato sviluppando inizialmente pensando ad un’archite�ura che successivamente
durante l’implementazione e stata modi�cata. L’archite�ura originale prevedeva:
• L’ Assistente vocale Alexa che perme�e di mandare dei comandi ad una skill tramite
utilizzo della voce, si puo utilizzare tramite l’applicazione per smartphone, come anche
tramite gli appositi device Amazon Echo.
• Una Skill Alexa che perme�e di gestire i comandi ricevuti tramite Alexa, e hostata sui
server di Amazon e utilizza il servizio AWS Lambda.
18
• IoTronic, ovvero il sistema proge�ato dall’universita che perme�e di esporre le porte
dell’Arancino alla skill Alexa.
• L’Arancino come hardware con sistema operativo linux, �sicamente installato nella rete
di casa in modo da perme�ere la gestione dei dispositivi utilizzando:
– OpenHab, so�ware per la gestione dei dispositivi, comprendente una rest interface,
una web interface, una console di comando, e una bash interface.
– NodeRed, so�ware per la gestione dei dei �ussi di informazione, perme�e una
programmazione visuale tramite web interface.
– Mosqui�o, broker mq� necessario per lo scambio dei dati tra dispositivi che utiliz-
zano il protocollo mq�.
• Un dispositivo ESP32 che funziona da lampadina smart e che utilizza il protocollo mq�
e la homie convention per ricevere comandi e inviare informazioni sullo stato.
Percio l’archite�ura prevede un �usso di informazioni che ha inizio dall’utente.
�esto puo richiedere un servizio all’assistente vocale Alexa, come ad esempio l’accenzione
di una lampadina.
Il comando verra inoltrato da Alexa alla skill, che non e altro che un so�ware hostato sui ser-
ver di amazon che e in grado di comprendere la sintassi dei comandi amazon, questa skill deve
essere programmata per inoltrare il comando all’Arancino.
Per fare cio il comando viene inviato al broker mq� mosqui�o sul topic ’Alexa/input’.
Il messaggio viene inviato all’arancino a�raverso il cloud di IoTronic che funziona come una
sorta di tunnelling.
Il broker mq� ha il compito di inoltrare il messaggio a tu�i i subscriber, in questo caso il sub-
scriber sara necessariamente NodeRed.
19
�indi NodeRed riceve il comando e dopo averlo forma�ato corre�amente lo inoltra ad Ope-
nHab tramite la rest interface.
OpenHab porta a compimento il comando, ovvero richiede al dispositivo di e�e�uare la de-
terminata azione richiesta. In questo esempio particolare il dispositivo ESP32 utilizza sempre
il protocollo mq� seguendo la convenzione homie.
Percio OpenHab invia il comando al broker sul topic homie/deviceid, di conseguenza mosquit-
to inoltra il messaggio all’ESP32 in quanto subscriber di quel topic.
Il dispositivo ESP32 esegue l’azione richiesta (accende la luce) e conferma il suo stato sempre
utilizzando il protocollo mq�.
20
3.3.1 Sequence Diagram
E’ un tipo di Iteraction Diagram proposto da UML(Uni�ed ModelingLanguage) e rappresenta
i requisiti del So�ware dal punto di vista dell’utente, evidenzia il �usso temporale di elabora-
zione. �esto e il Sequence Diagram della prima archite�ura.
21
3.4 Component-Deployment Diagram
Il Deployment Diagram e un diagramma previsto dal linguaggio di modellazione object-oriented
UML per descrivere un sistema in termini di risorse hardware e di relazioni fra di esse. Spesso
si utilizza un diagramma che mostra come le componenti so�ware siano distribuite rispe�o
alle risorse hardware disponibili sul sistema; questo diagramma e costruito unendo il Compo-
nent Diagram e il Deployment Diagram.
Si e quindi deciso di mostrare la stru�ura del sistema unendo questi diagrammi per una mag-
giore chiarezza e completezza.
22
3.5 Activity Diagram
Il diagramma di a�ivita (activity diagram in inglese) e un tipo di diagramma che perme�e di
descrivere un processo a�raverso dei gra� in cui i nodi rappresentano le a�ivita e gli archi
l’ordine con cui vengono eseguite.
Si mostra l’activity diagram per dare un’ulteriore punto di vista della sistema so�-
ware e descriverne gli algoritmi principali.
23
3.6 Architettura 2.0
Sfortunatamente il modello si e rivelato poco funzionale, in quanto sebbene il protocollo mq�
si presti molto bene allo scambio di messaggio di questo tipo. La stru�ura stessa del cloud
serverless event driven rende impossibile il corre�o funzionamento del subscribe ad un topic
mq�, ma questo e stato palese solo una volta scri�o ed eseguito il programma.
Di conseguenza e stata ripensata l’archite�ura per bypassare nodered e il broker mq�.
La nuova archite�ura prevede quindi:
• L’ Assistente vocale Alexa che perme�e di mandare dei comandi ad una skill tramite
utilizzo della voce, si puo utilizzare tramite l’applicazione per smartphone, come anche
tramite gli appositi device Amazon Echo.
• Una Skill Alexa che perme�e di gestire i comandi ricevuti tramite Alexa, e hostata sui
server di Amazon e utilizza il servizio AWS Lambda.
• IoTronic, ovvero il sistema proge�ato dall’universita che perme�e di esporre le porte
dell’Arancino alla skill Alexa.
• L’Arancino come hardware con sistema operativo linux, �sicamente installato nella rete
di casa in modo da perme�ere la gestione dei dispositivi utilizzando:
– OpenHab, so�ware per la gestione dei dispositivi, comprendente una rest interface,
una web interface, una console di comando, e una bash interface.
– NodeRed, so�ware per la gestione dei dei �ussi di informazione, perme�e una
programmazione visuale tramite web interface. �esta volta nodered e utilizzato
solamente per la gestione di IoTronic.
– Mosqui�o, broker mq� necessario per lo scambio dei dati tra dispositivi che utiliz-
zano il protocollo mq�.
• Un dispositivo ESP32 che funziona da lampadina smart e che utilizza il protocollo mq�
e la homie convention per ricevere comandi e inviare informazioni sullo stato.
25
�indi l’utente puo richiedere un servizio all’assistente vocale Alexa, come ad esem-
pio l’accenzione di una lampadina.
Il comando verra inoltrato da Alexa alla skill che deve essere programmata per inoltrare il co-
mando all’Arancino. Il comando viene forma�ato e inoltrato dire�amente alla rest interface
di OpenHab (con l’ausilio di IoTronic) che porta a compimento il comando richiedendo al di-
spositivo di e�e�uare l’azione richiesta. Percio OpenHab invia il comando al broker sul topic
homie/deviceid e mosqui�o inoltra il messaggio all’ESP32 in quanto subscriber di quel topic.
Il dispositivo ESP32 esegue l’azione richiesta (accende la luce) e conferma il suo stato.
Per minimizzare i tempi di sviluppo e per sviluppare un sistema di maggiore qualita, come sot-
tolineato dai valori dall’ingegneria del so�ware orientata al riuso, e stata utilizzata come base
di sviluppo della skill il so�ware open-source scri�o da OpenHab, che segue indicativamente
la stessa archite�ura, che e stata quindi ada�ata al proge�o per funzionare con l’Arancino e
IoTronic.
3.6.1 Sequence Diagram
�esto e il nuovo Sequence Diagram.
26
3.7 Component-Deployment Diagram
Per dimostrare la di�erenza di archite�ura tra i due sistemi si e disegnato un secondo dia-
gramma. Si noti come sostanzialmente i componenti rimangano invariati e le comunicazioni
tra i nodi avvengono secondo una logica simile nonostante i componenti so�ware all’inter-
no e i protocolli di comunicazione varino notevolmente l’archite�ura e la �loso�a del proge�o.
27
3.8 Activity Diagram
Si mostra l’activity diagram per dare un’ulteriore punto di vista della sistema so�ware anche
al so�ware ristru�urato alla �ne dell’ultimo sprint.
28
3.9 Skill Component Diagram
Per mostrare il funzionamento interno della skill si realizza un component diagram che mostra
la suddivisione della skill in �le. �esto e stato ricavato dallo studio della skill di Alexa open-
source che poi e stato utilizzato per il funzionamento del sistema.
30
3.10 So�ware Utilizzati
• AzureDevOpse un ambiente di sviluppo Scrum gratuito e di semplice utilizzo che per-
me�e di utilizzare una dashboard come productbacklog facilitando la creazione delle
user stories e la loro suddivisione in task.
• Visual Studio Code e un editor di codice sorgente sviluppato da Microso� per Windo-
ws, Linux e macOS. Esso include supporto per debugging, un controllo per Git integra-
to. �indi un o�imo ide multipia�aforma che supporta tu�i i linguaggi con l’utilizzo
di eventuali plug-in esterni. In questo caso e stato utilizzato per sviluppare il proge�o
della skill in python.
• Draw.io e una applicazione di diagrammi completamente gratuita e abilitata per Google
Drive che ha permesso di creare i diversi gra�ci presenti sulla pagina.
• Google Sheets e un’applicazione cloud abilitata per Google Drive con funzionalita si-
mile a Microso� Excel. E’ stata utilizzata per creare i Burndown Chart per ogni sprint.
• Overleaf e un editor online per il LATEX, linguaggio di markup per la preparazione di
testi, basato sul programma di composizione tipogra�ca TEX.
31
Capitolo 4
Iterazioni
Il proge�o e stato completato in 5 sprint di 1 se�imana l’uno (5 giorni lavorativi).
• Sprint 1 [21/10/2019 - 25/11/2019]
• Sprint 2 [28/10/2019 - 01/11/2019]
• Sprint 3 [04/11/2019 - 08/11/2019]
• Sprint 4 [11/11/2019 - 15/11/2019]
• Sprint 5 [18/11/2019 - 22/11/2019]
4.1 Sprint 1
4.1.1 Sprint Planning
Nella prima parte del primo sprint planning il product Owner ha presentato il proge�o e le
user stories ordinate. Successivamente e stato assegnato dal Dev Team insieme allo Scrum
master il peso di ogni storia e sono state aggiunte le storie che idealmente si sarebbero potute
svolgere nel primo sprint le product backlog.
32
Product backlog
Sprint backlog
4.1.2 Grooming
Nella fase di grooming il dev team ha scomposto in task ogni user stories nello sprint backlog
33
4.1.3 Sprint Review
La sprint review serve per veri�care se e quali storie completate a �ne sprint possono essere
considerate terminate, funzionanti e sopra�u�o rispe�ano le richieste del cliente o utilizza-
tore �nale. In questo caso e stato veri�cato il funzionamento del dispositivo ESP32. E’ stato
veri�cata anche la possibilita di controllare il dispositivo tramite l’interfaccia web di OpenHab
installata sull’arancino.
L’ultima user stories nello sprint backlog non e stata completata.
4.1.4 Sprint Retrospective
La retrospe�iva serve per individuare cosa ha funzionato e cosa no. Una sorta di valutazione
del processo per individuare gli errori e intraprendere le iniziative necessarie per eliminarli.
Non ci sono stati su�cienti dati per identi�care degli eventuali problemi.
4.1.5 Burndown Chart
Un burn down chart e una rappresentazione gra�ca del lavoro da fare su un proge�o nel tempo.
Il lavoro rimanente (o backlog) e indicato sull’asse verticale e il tempo sull’asse orizzontale. Il
diagramma rappresenta una serie storica del lavoro da fare.
34
4.2 Sprint 2
4.2.1 Sprint Planning
Nello sprint planning del secondo sprint e stato ricreato lo sprint backlog ed e stato inserito
l’item che non e stato completato nella precedente iterazione.
35
4.2.2 Grooming
Nella fase di grooming sono state suddivise le user stories in task.
4.2.3 Sprint Review
La ricerca dei dispositivi tramite Alexa e stata completata con successo. La demo consiste nel
chiedere ad Alexa di trovare nuovi dispositivi. La prova e stata superata con successo, e stato
mostrato il dispositivo ESP32.
La seconda user story non e stata completata.
36
4.2.4 Sprint Retrospective
Anche in questo sprint non sono state completate tu�e le user stories, di conseguenza un
problema riscontrato e stato quello di non aver pesato bene la capacity del team di sviluppo.
�indi nel prossimo sprint planning verranno assegnate compiti con peso minore.
4.2.5 Burndown Chart
4.3 Sprint 3
4.3.1 Sprint Planning
Nello sprint planning del terzo sprint e stato ricreato lo sprint backlog ed e stato inserito l’item
che non e stato completato nella precedente iterazione.
37
4.3.2 Grooming
Nella fase di grooming sono state suddivise le user stories in task.
4.3.3 Sprint Review
In questo spring tu�e le task sono state completate, ma non tu�e con successo. L’a�ivazione
dei dispositivi tramite comandi vocali funziona perfe�amente. Il test e stato passato con suc-
cesso.
Il problema si e dimostrato nella richiesta dello stato dei dispositivi tramite Alexa. Infa�i non
sempre la skill si e rivelata capace di rispondere corre�amente alla richiesta.
La causa di cio si e visto essere nella natura stessa del servizio lambda e del protocollo mq�.
Per e�e�uare il subscribe alla su un topic la skill deve ciclare in continuazione per rimanere
connessa al broker e rimanere in ascolto di un cambiamento di stato. La funzione lambda non
prevede un simile comportamento, ma essendo event-driven, la funzione lambda si aspe�a di
rimanere in funzione per poco tempo solo dopo che un evento ne scateni l’a�ivazione.
�indi l’archite�ura prevista �no ad adesso non sembra essere funzionante. Si deve cambiare
completamente approccio al problema.
38
4.3.4 Burndown Chart
4.4 Sprint 4
4.4.1 Sprint Planning
In questo sprint planning si e dovuto tornare indietro e reinserire le ultime due user stories
gia completate nel backlog in quanto la ripiani�cazione del’archite�ura di collegamento tra
Alexa e OpenHab richiede la riscri�ura totale dei codici della skill.
�esta volta si e deciso di bypassare il controllo di nodered e non utilizzare mq�
come canale di connessione tra nodered e la skill Alexa, ma piu�osto utilizzare dire�amente
l’interfaccia rest o�erta resa disponibile da OpenHab.
E’ stato trovato una skill opensource sviluppata da OpenHab stesso che ricalca perfe�amente
le funzionalita richieste. Di conseguenza e stato pensato di utilizzare quel so�ware e ada�arne
il funzionamento all’arancino e ad IoTronic.
39
4.4.2 Grooming
Nella fase di grooming sono state suddivise le user stories in task.
4.4.3 Sprint Review
La ricerca dei dispositivi tramite comandi vocali funziona anche nella nuova archite�ura.
Anche l’a�ivazione dei dispositivi tramite comandi vocali si e dimostrato funzionante. I test
sono stati un successo e non e stato tralasciato alcun task.
40
4.4.4 Burndown Chart
4.5 Sprint 5
4.5.1 Sprint Planning
Il product owner in questo sprint ha deciso di rimuovere completamente dal backlog la user
story epica: “utilizzo di nuovi tipi di dispositivo” che prevedeva l’aggiunta di nuovi itemtype
sul framework eclipse smarthome su cui si basa OpenHab.
E’ quindi rimasta una sola user stories da completare e inserire nello sprint backlog
41
4.5.2 Grooming
Nella fase di grooming sono state suddivise le user stories in task.
4.5.3 Sprint Review
Con questo sprint si sono terminate tu�e le a�ivita del proge�o con successo. I test �nali sono
andati a buon �ne e il product owner e rimasto soddisfa�o dal lavoro e�e�uato.
4.5.4 Burndown Chart
42
Capitolo 5
Conclusioni
Si e sviluppato un intero proge�o testato e funzionante che include codice e archite�ura di
rete utilizzando il framework di Scrum.
Si e visto come un approccio agile abbia permesso di reagire velocemente ad errori
e problemi anche di natura archite�urale in breve periodo. Inoltre ha permesso di controllare
l’andamento della produ�ivita del team e modi�care il carico di lavoro dinamicamente.
Grazie agli strumenti si e anche potuto analizzare l’andamento del team di sviluppo per poter
apportare nuovi miglioramenti anche in futuri proge�i.
Nonostante le modi�che sostanziali apportate al sistema, l’applicazione dei principi
di sviluppo agile ha portato alla produzione di un sistema di qualita nei tempi previsti.
43