Universita degli Studi di Messina` Facolta di informatica ...

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.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.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

activ

itydi

agra

m

24

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

activ

itydi

agra

m

29

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


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.


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


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


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.3 Sprint 3


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


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.4 Sprint 4


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


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.5 Sprint 5


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


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.


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

Universita degli Studi di Messina` Facolta di informatica ...

Documents

Transcript of Universita degli Studi di Messina` Facolta di informatica ...