Università degli Studi di Padova - SIAGAS
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Università degli Studi di Padova
Dipartimento di Matematica "Tullio Levi-Civita"
Corso di Laurea in Informatica
Sviluppo di un’app Android per il robot
Sanbot
Tesi di laurea triennale
Relatore
Prof. Mauro Conti
Laureando
Nicolae Andrei Tabacariu
Anno Accademico 2017-2018
Nicolae Andrei Tabacariu: Sviluppo di un’app Android per il robot Sanbot, Tesi di laurea triennale, c Settembre 2018.
“Life is really simple, but we insist on making it complicated”
— Confucius
Ringraziamenti
Innanzitutto, vorrei esprimere la mia gratitudine al Prof. Mauro Conti, relatore della
mia tesi, per l’aiuto e il sostegno fornitomi durante l’attività di stage e la stesura del
presente documento.
Desidero ringraziare con affetto la mia famiglia e la mia ragazza Erica, che mi hanno
sostenuto economicamente ed emotivamente in questi anni di studio, senza i quali
probabilmente non sarei mai arrivato alla fine di questo percorso.
Desidero poi ringraziare gli amici e i compagni che mi hanno accompagnato in questi
anni e che mi hanno dato sostegno ed affetto.
Infine porgo i miei ringraziamenti a tutti i componenti di Omitech S.r.l. per l’opportunità
di lavorare con loro, per il rispetto e la cordialità con cui mi hanno trattato.
Padova, Settembre 2018 Nicolae Andrei Tabacariu
iii
Indice
1 Introduzione 1
1.1 L’azienda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Il progetto di stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Organizzazione dei contenuti . . . . . . . . . . . . . . . . . . . . . . . 2
2 Descrizione dello stage 3
2.1 Il progetto di stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1 Analisi dei rischi . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2 Obiettivi fissati . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.3 Pianificazione del lavoro . . . . . . . . . . . . . . . . . . . . . . 5
2.1.4 Interazione con i tutor . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Studio del dominio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1 Il robot Sanbot . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.2 SDK Sanbot . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 Analisi dei requisiti 9
3.1 Casi d’uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Tracciamento dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . 21
4 Progettazione e sviluppo 25
4.1 Tecnologie e strumenti . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2 Progettazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.1 App::Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2.2 App::Model::App_Manager . . . . . . . . . . . . . . . . . . . . 29
4.2.3 App::Model::Motion_Manager . . . . . . . . . . . . . . . . . . 31
4.2.4 App::Model::Conversation_Manager . . . . . . . . . . . . . . . 32
4.2.5 View e Presenter . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2.6 Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.7 Prodotto finale . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5 Verifica e validazione 45
5.0.1 Verifica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.0.2 Validazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6 Conclusioni 47
6.1 Raggiungimento degli obiettivi . . . . . . . . . . . . . . . . . . . . . . 47
6.2 Valutazione personale . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Glossario 51
v
vi INDICE Bibliografia 53
Elenco delle figure
1.1 Logo Omitech Srl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2.1 Immagine di Sanbot Elf . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Use Case - UCG: Scenario principale . . . . . . . . . . . . . . . . . . . 10
3.2 Use Case - UC0: Attivazione Sanbot . . . . . . . . . . . . . . . . . . . 11
3.3 Use Case - UC1: Avviamento modalità presentazione . . . . . . . . . . 13
3.4 Use Case - UC2: Gestisci presentazione . . . . . . . . . . . . . . . . . 14
3.5 Use Case - UC2.2: Gestione proiettore . . . . . . . . . . . . . . . . . . 15
3.6 Use Case - UC2.3: Gestisci presentazione . . . . . . . . . . . . . . . . 17
3.7 Use Case - UC3: Termina modalità presentazione . . . . . . . . . . . . 18
3.8 Use Case - UC5: Gestione movimenti Sanbot . . . . . . . . . . . . . . 19
3.9 Use Case - UC6: Scatta Foto/Video . . . . . . . . . . . . . . . . . . . 20
4.1 Progettazione: Diagramma generale . . . . . . . . . . . . . . . . . . . 27
4.2 Progettazione: App::Model . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3 Progettazione: App::Model::App_Manager . . . . . . . . . . . . . . . 29
4.4 Progettazione: App::Model::Motion_Manager . . . . . . . . . . . . . . 31
4.5 Progettazione: App::Model::Conversation_Manager . . . . . . . . . . 32
4.6 Progettazione: HomeActivity e HomeView . . . . . . . . . . . . . . . . 35
4.7 Progettazione: Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.8 GUI: Schermata principale . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.9 GUI: Schermata Selezione File . . . . . . . . . . . . . . . . . . . . . . 39
4.10 GUI: Schermata Video . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.11 GUI: Schermata Immagine . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.12 GUI: Schermata PDF . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.13 GUI: Schermata Impostazioni Proiettore . . . . . . . . . . . . . . . . . 43
4.14 GUI: Schermata Registrazione Video . . . . . . . . . . . . . . . . . . . 44
vii
viii ELENCO DELLE TABELLE
Elenco delle tabelle
2.1 Tabella pianificazione del lavoro . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Tabella del tracciamento dei requisti funzionali . . . . . . . . . . . . . 22
3.2 Tabella del tracciamento dei requisiti qualitativi . . . . . . . . . . . . 23
3.3 Tabella del tracciamento dei requisiti di vincolo . . . . . . . . . . . . . 23
Capitolo 1
Introduzione
Il presente documento descrive l’attività di stage svolta dal laureando Nicolae Andrei
Tabacariu della durata complessiva di 320 ore presso l’azienda Omitech Srl.
1.1 L’azienda
Figura 1.1: Logo Omitech Srl
Omitech Srl è un affermato Managed Services Provider (MSP: fornitore di servizi
gestiti), nato nel 1997 a Padova, l’azienda vanta anche sedi a Milano e Roma oltre
a quella patavina. L’obiettivo dell’azienda è la progettazione e gestione di soluzioni
per semplificare l’approccio del cliente alle complessità delle innovazioni tecnologiche.
Orizzontale alle tecnologie e alle segmentazioni del mercato opera con la PMI, la PA e
la grande azienda.
L’azienda offre ai suoi clienti:
∗ IAAS (Infrastructure as a Service);
∗ Cloud supportato e gestito;
∗ Strumenti di collaborazione e comunicazione;
∗ Applicazioni Business;
∗ Sicurezza.
1
2 CAPITOLO 1. INTRODUZIONE
Inoltre, negli ultimi anni Omitech è entrata nel campo della robotica, stringendo
una partnership con Qihan Technology Co., una società cinese produttrice del robot
Sanbot, con cui ha ottenuto l’esclusiva di vendita dei robot nel territorio italiano.
Proprio in questo contesto, con l’utilizzo del robot Sanbot, si è svolto lo stage descritto
in questo documento.
1.2 Il progetto di stage
Il progetto di stage consiste nello sviluppare un’applicazione in ambiente Android da
integrare con il robot Sanbot presente in azienda, in modo da rendere quest’ultimo
utilizzabile come assistente in una presentazione interattiva tramite i suoi dispositivi
integrati, come per esempio il videoproiettore, e le loro funzionalità.
1.3 Organizzazione dei contenuti
Il secondo capitolo descrive in maniera più esaustiva il progetto di stage e presenta
il piano di lavoro seguito durante il suo svolgimento.
Il terzo capitolo affronta la fase di analisi dei requisiti.
Il quarto capitolo affronta la progettazione e lo sviluppo, dando anche una panora-
mica del prodotto finale ottenuto.
Il quinto capitolo affronta la fase di verifica e validazione.
Il sesto capitolo contiene delle conclusioni personali sull’attività svolta.
Riguardo la stesura del testo, relativamente al documento sono state adottate le
seguenti convenzioni tipografiche:
∗ gli acronimi, le abbreviazioni e i termini ambigui o di uso non comune menzionati
vengono definiti nel glossario, situato alla fine del presente documento;
∗ per la prima occorrenza dei termini riportati nel glossario viene utilizzata la
seguente nomenclatura: parola [g] ;
∗ i termini in lingua straniera o facenti parti del gergo tecnico sono evidenziati con
il carattere corsivo.Capitolo 2
Descrizione dello stage
In questo capitolo verranno presentati gli obiettivi dello stage e le modalità del suo svolgi-
mento.
2.1 Il progetto di stage
L’attività di stage ha previsto l’analisi e la predisposizione di una demo di applicazione
per il Robot Sanbot che permettesse a quest’ultimo di servire come assistente per
una presentazione. Lo scopo ultimo del progetto, dunque, è stato lo sviluppo di
un’applicazione in ambiente Android che consentisse la gestione di una presentazione
tramite l’interazione con Sanbot. Un esempio: la possibilità di farsi seguire dal robot e
tramite comando vocale avviare la presentazione dal suo proiettore interno. Il progetto
ha previsto l’utilizzo dell’SDK [g] proprietario di Qihan Technology Co. per utilizzare le
funzionalità del robot tramite applicazione. Il programma è stato testato sul modello a
disposizione dell’azienda. Lungo l’attività di Stage ho dovuto stilare la documentazione
necessaria per tenere traccia delle varie attività svolte. La documentazione ha incluso
le attività relative ai periodi di analisi, progettazione architetturale, progettazione di
dettaglio e codifica.
Le principali attività dello stage sono state le seguenti:
∗ Studio delle tecnologie necessarie: SDK Sanbot, Android Studio;
∗ Analisi dei requisiti demo;
∗ Progettazione architetturale;
∗ Progettazione di dettaglio e codifica;
∗ Verifica e test funzionamento della demo;
∗ Stesura documentazione relativa alla demo.
34 CAPITOLO 2. DESCRIZIONE DELLO STAGE
2.1.1 Analisi dei rischi
I rischi individuati per lo svolgimento di questo stage sono stati i seguenti:
∗ Utilizzo di tecnologie a me sconosciute, sono state previste dunque molte ore
dedicate al loro studio;
∗ L’inesperienza avrebbe potuto dettare ritardi nelle scadenze predefinite;
∗ L’instabilità del robot, ancora in fase prototipale al momento dello svolgimento
dello stage, avrebbe potuto comportare ulteriori ritardi o malfunzionamenti.
2.1.2 Obiettivi fissati
Di seguito verranno elencati gli obiettivi fissati antecedentemente all’inizio dello stage,
da raggiungere nel corso dello stesso.
Si farà riferimento ai requisiti secondo le seguenti notazioni:
∗ O per i requisiti obbligatori, vincolanti in quanto obiettivo primario richiesto dal
committente;
∗ D per i requisiti desiderabili, non vincolanti o strettamente necessari, ma dal
riconoscibile valore aggiunto;
∗ F per i requisiti facoltativi, rappresentanti valore aggiunto non strettamente
competitivo.
Le sigle precedentemente indicate saranno seguite da una coppia sequenziale di
numeri, identificativi del requisito.
∗ Obbligatori
– O01: Analisi dell’SDK Sanbot e sue metodologie d’interazione;
– O02: Definizione casi d’uso;
– O03: Definizione requisiti software;
– O04: Realizzazione architetturale del software;
– O05: Codifica dell’applicativo;
– O06: Superamento test prefissati.
∗ Desiderabili
– D01: Implementazione di uno strumento di interazione vocale con Sanbot.
∗ Facoltativi
– F01: Stesura di un manuale per l’uso dell’applicazione.2.1. IL PROGETTO DI STAGE 5
2.1.3 Pianificazione del lavoro
Prima dell’effettivo inizio dello stage, io ed il mio tutor aziendale ci siamo accordati su
un piano di lavoro suddiviso in attività nell’arco di 320 ore, il quale mi ha permesso di
raggiungere gli obiettivi pianificati nei limiti imposti dall’Università.
La pianificazione del lavoro in termini di attività ed ore impiegate è stata così
distribuita:
Tabella 2.1: Tabella pianificazione del lavoro
Periodo Attività Ore %
Analisi 96 32,5
03/07/17-05/07/17 Analisi Android Studio 24
06/07/17-11/07/17 Analisi sensori Sanbot 32
12/07/17-14/07/17 Analisi SDK Sanbot 24
17/07/17-19/07/17 Analisi dei requisiti 24
Sviluppo 160 50
20/07/17-25/07/17 Progettazione architetturale 32
26/07/17-16/08/17 Progettazione di dettaglio e implementazione 128
Verifica 32 10
17/08/17-22/08/17 Verifica e test funzionamento demo 32
Documentazione 24 7,5
23/08/17-25/08/17 Redazione documentazione relativa alla demo 24
Lo stage ha subito una settimana di slittamento per problemi di matrice burocratica
ed è iniziato dunque il 10/07/17 e finito il 1/09/17, lo svolgimento delle attività invece
non si è discostato in maniera significativa dalla pianificazione oraria iniziale.
2.1.4 Interazione con i tutor
Lo stage si è svolto presso la sede di Padova dell’azienda, con orario d’ufficio dal lunedì
al venerdì dalle 9.00 alle 18.00, ciò ha permesso di interagire con il tutor aziendale,
il quale mi ha lasciato molta autonomia nello svolgimento delle attività lavorative,
ma mi ha anche affiancato un collega esperto del robot Sanbot al quale riferivo i miei
progressi giornalmente e che si è reso molto disponibile alla collaborazione nel risolvere
eventuali problemi tecnici riscontrati col robot lungo il suo utilizzo.
Per quanto riguarda l’interazione con il tutor interno, ho provveduto ad aggiornarlo
settimanalmente sui miei progressi, informandolo di eventuali slittamenti rispetto al
piano di lavoro ed inviandogli, ove disponibile, la documentazione prodotta di volta in
volta.6 CAPITOLO 2. DESCRIZIONE DELLO STAGE
2.2 Studio del dominio
2.2.1 Il robot Sanbot
Sanbot è un robot umanoide multimediale prodotto da Qihan Technology Co., presente
sul mercato dal 2016. Vi sono tre versioni di Sanbot commercializzate: Elf, King Kong
e Nano, in questo documento parleremo della versione Elf (la prima) in quanto è quella
su cui si è sviluppata l’applicazione e di cui si aveva disponibilità in azienda nel corso
dello stage.
Figura 2.1: Immagine di Sanbot Elf
La particolarità di Sanbot è data dalla sua multimedialità, esso è infatti dotato di
molte funzionalità che elencheremo di seguito:
∗ Dotato di un motore di speech recognition [g] che insieme alla sua intelligenza
artificiale in Cloud [g] gli permette un’interazione vocale molto naturale;
∗ Munito di una Camera 3D che permette la lettura dei gesti e il riconoscimento
facciale;
∗ Diverse camere HD permettono la visione dell’ambiente e delle persone;
∗ Proiettore fino a 65 pollici;
∗ Schermo touch HD integrato, simile ad un tablet;
∗ Infine è dotato di oltre 60 sensori che gli permettono di essere sensibile al tatto e
di ottenere una perfetta consapevolezza dell’ambiente circostante che gli permette
di muoversi in modo autonomo.2.2. STUDIO DEL DOMINIO 7
2.2.2 SDK Sanbot
Ad inizio stage mi è stato consegnato un documento riguardante l’SDK Sanbot in
cui vi erano descritte le classi e i metodi utili al controllo dei movimenti del robot e
all’integrazione dei suoi dispositivi multimediali in un’applicazione Android. Di seguito
ne fornirò una breve descrizione soffermandomi solamente sulle parti che ritengo più
importanti.
Riconoscimento vocale Per accedere alle funzionalità vocali del robot è necessario
creare un oggetto della classe SpeechManager, tramite cui oltre a poter far parlare il
robot si può ottenere l’audio in entrata della sintetizzazione del riconoscimento vocale
tramite l’implementazione dell’interfaccia RecognizeListener come segue:
speechManager . setOnSpeechListener ( new RecognizeListener () {
@Override
public boolean onRecognizeResult ( Grammar grammar ) {
System . out . print ( ’ Content Recognized : ’+ grammar .
getText () ) ;
return true ;
}
}) ;
Controllo Hardware e sensori Creando un oggetto della classe HardWareMa-
nager si può ottenere il controllo delle funzionalità hardware di Sanbot, tra cui le
sue luci LED, i suoi sensori Touch tramite l’implementazine dell’interfaccia Touch-
SensorListener, la localizzazione vocale tramite l’interfaccia VoiceLocateListener,
i sensori infrarossi tramite l’interfaccia PIRListener ed il suo giroscopio tramite
l’interfaccia GyroscopeListener.
Per esempio TouchSensorListener attiva i sensori del tatto e deve implementare
il metodo "void onTouch(int part)" in cui part rappresenta uno dei sensori (range
1-13):
hardWareManager . set OnHare WareL istene r ( new TouchSensorListener () {
@Override
public void onTouch ( int part ) {
if ( part == 11 || part == 12 || part == 13) {
touchTv . setText ( ’ Head has been touched ’) ;
}
}
}) ;
Controllo movimenti della testa, delle mani e delle ruote
∗ Creando un oggetto della classe HeadMotionManager è possibile ruotare la
testa del robot indicandone l’angolazione e la velocità di movimento;
∗ Creando un oggetto della classe HandMotionManager è possibile controllare
il movimento delle mani indicando l’azione da svolgere (su/giù) e la velocità di
movimento;8 CAPITOLO 2. DESCRIZIONE DELLO STAGE
∗ Creando un oggetto della classe WheelMotionManager è possibile controllare
il movimento delle ruote del robot indicandone l’angolazione, la durata e la
velocità.
Controllo del proiettore Creando un oggetto della classe ProjectorManager è
possibile controllare il proiettore integrato accendendolo e spegnendolo, modificandone
i parametri di visualizzazione e la modalità di proiezione tra parete e soffitto (wall/cei-
ling).
Controllo dispositivi multimediali Creando un oggetto della classe MediaMa-
nager è possibile utilizzare la camera HD integrata, ottenendone lo stream audio e
video tramite l’implementazione dell’interfaccia MediaStreamListener.Capitolo 3
Analisi dei requisiti
In questo capitolo verranno mostrati i frutti dell’attività di Analisi dei Requisiti.
3.1 Casi d’uso
Successivamente alla fase di studio del dominio iniziale, ho dovuto individuare e stilare
i casi d’uso, che hanno poi portato alla realizzazione dei diagrammi dei casi d’uso
(Use Case Diagrams in inglese) scritti in UML[g] , utilizzati per descrivere funzioni
e servizi offerti da un sistema, dal punto di vista dell’attore che utilizza il sistema stesso.
Per l’individuazione di tutte le funzionalità che l’azienda si aspettava dall’applica-
zione ho effettuato una sessione di brainstorming con un collega che stava lavorando
ad un altro applicativo per Sanbot, di seguito verranno presentati gli schemi UML e,
in definitiva, stilate le tabelle con i requisiti individuati.
910 CAPITOLO 3. ANALISI DEI REQUISITI
Figura 3.1: Use Case - UCG: Scenario principale
UCG: Scenario principale
Attori Principali: Utente.
Precondizioni: L’utente deve essere in un raggio di 1,5 metri da Sanbot per poterlo
attivare.
Descrizione: L’utente deve attivare Sanbot tramite comando vocale oppure la wake-
word “Sanbot”, da questo momento in poi può eseguire tutte le funzionalità del prodotto.
Può avviare la modalità presentazione per proiettare su una parete una presentazione
video, PDF oppure un’immagine tramite il proiettore integrato all’interno del Robot.
Una volta avviata tale modalità è possibile gestire molti aspetti dell’immagine proiettata,
come il colore, la luminosità e la modalità di proiezione. Inoltre l’utente può interagire
vocalmente con Sanbot e farlo muovere facendosi seguire da lui o chiamandolo a sé. È
possibile sfruttare anche la sua camera HD frontale per scattare foto o registrare video.3.1. CASI D’USO 11
Scenario Principale:
∗ UC0: L’utente può attivare Sanbot;
∗ UC1: L’utente può avviare la modalità presentazione vocalmente o tramite la
pressione di un tasto sul tablet integrato;
∗ UC2: L’utente può selezionare il file da proiettare e gestire le varie impostazioni
di proiezione, oltre che mettere in pausa e riprendere un video oppure passare da
una slide ad un’altra nel caso di un file powerpoint;
∗ UC3: L’utente può terminare la modalità presentazione;
∗ UC4: L’utente può conversare con Sanbot;
∗ UC5: L’utente può muovere Sanbot attraverso la propria voce;
∗ UC6: L’utente può ordinare a Sanbot di scattare una foto o registrare un video.
Postcondizioni: Il sistema è pronto per permettere una nuova interazione.
Figura 3.2: Use Case - UC0: Attivazione Sanbot
UC0: Attivazione Sanbot
Attori Principali: Utente.12 CAPITOLO 3. ANALISI DEI REQUISITI
Precondizioni: L’utente deve essere ad un massimo di 1,5 metri di distanza da Sanbot
e quest’ultimo deve avere la batteria carica.
Descrizione: L’utente attiva Sanbot.
Scenario Principale:
∗ UC0.1: Attivazione di Sanbot tramite la wake-word "Sanbot";
∗ UC0.2: Attivazione di Sanbot tramite tocco dei suoi sensori.
Scenario Alternativo:
∗ L’utente è troppo distante da Sanbot;
∗ Sanbot è scarico.
Postcondizioni: Sanbot eseguirà un comando vocale per confermare la sua avvenuta
attivazione all’utente.3.1. CASI D’USO 13
Figura 3.3: Use Case - UC1: Avviamento modalità presentazione
UC1: Avviamento modalità presentazione
Attori Principali: Utente.
Precondizioni: L’utente deve aver attivato Sanbot.
Descrizione: L’utente avvia la modalità presentazione.
Scenario Principale:
∗ UC1.1: L’utente avvia la modalità presentazione tramite comando vocale;
∗ UC1.2: L’utente avvia la modalità presentazione tramite pressione dello specifico
bottone sullo schermo del tablet integrato.
Scenario Alternativo: L’utente non ha attivato Sanbot dunque quest’ultimo non
risponde ai comandi.
Postcondizioni: Sanbot entrerà nella modalità presentazione e chiederà all’utente di
selezionare un file.14 CAPITOLO 3. ANALISI DEI REQUISITI
Figura 3.4: Use Case - UC2: Gestisci presentazione
UC2: Gestisci presentazione
Attori Principali: Utente.
Precondizioni: L’utente deve aver avviato la modalità presentazione.
Descrizione: L’utente può gestire le impostazioni per la presentazione, ovvero la
selezione del file, le impostazioni del proiettore e la gestione della proiezione a presen-
tazione avviata.
Scenario Principale:
∗ UC2.1: Selezione file;
∗ UC2.2: Gestione proiezione;
∗ UC2.3: Gestione presentazione.
Postcondizioni: Sanbot inizierà la proiezione del file selezionato.3.1. CASI D’USO 15
UC2.1: Seleziona file
Attori Principali: Utente.
Precondizioni: L’utente deve aver avviato la modalità presentazione ed aver premuto
il tasto di selezione file.
Descrizione: L’utente può selezionare un file da proiettare tra quelli presenti nella
lista (pdf, video o immagine).
Scenario Principale: L’utente seleziona il file da proiettare.
Postcondizioni: L’applicazione uscirà dalla selezione file ed avvierà il proiettore.
Figura 3.5: Use Case - UC2.2: Gestione proiettore
UC2.2: Gestione proiettore
Attori Principali: Utente.
Precondizioni: L’utente deve aver avviato la modalità presentazione ed aver selezio-
nato il file da proiettare.
Descrizione: L’utente può modificare le varie impostazioni del proiettore.16 CAPITOLO 3. ANALISI DEI REQUISITI
Scenario Principale:
∗ UC2.2.1: L’utente può ruotare l’immagine;
∗ UC2.2.2: L’utente può modificare il colore dell’immagine;
∗ UC2.2.3: L’utente può modificare la luminosità dell’immagine;
∗ UC2.2.4: L’utente può modificare l’acuità dell’immagine;
∗ UC2.2.5: L’utente può modificare la modalità di proiezione tra wall e ceiling.
Postcondizioni: Sanbot inizierà la presentazione.3.1. CASI D’USO 17
Figura 3.6: Use Case - UC2.3: Gestisci presentazione
UC2.3: Gestisci presentazione
Attori Principali: Utente.
Precondizioni: L’utente deve aver avviato la modalità presentazione ed aver avviato
la proiezione.
Descrizione: L’utente può gestire la presentazione in base al tipo di file selezionato.
Scenario Principale:
∗ UC2.3.1: L’utente può passare alla slide successiva o precedente;
∗ UC2.3.2: L’utente può mettere il video in pausa e riprenderlo;
∗ UC2.3.3: L’utente può visualizzare un’immagine.
Postcondizioni: L’utente avrà concluso la presentazione e il file verrà chiuso.18 CAPITOLO 3. ANALISI DEI REQUISITI
Figura 3.7: Use Case - UC3: Termina modalità presentazione
UC3: Termina modalità presentazione
Attori Principali: Utente.
Precondizioni: L’utente deve aver attivato Sanbot ed avviato la modalità presenta-
zione.
Descrizione: L’utente può terminare la modalità presentazione tramite comando
vocale oppure la pressione dell’apposito tasto sul tablet integrato.
Scenario Principale:
∗ UC3.1: L’utente può terminare la modalità presentazione tramite comando
vocale;
∗ UC3.2 L’utente può terminare la modalità presentazione tramite la pressione
dell’apposito tasto sul tablet integrato.
Postcondizioni: La modalità presentazione sarà chiusa.
UC4: Interazione vocale con Sanbot
Attori Principali: Utente.
Precondizioni: L’utente deve aver attivato Sanbot.
Descrizione: L’utente può conversare con Sanbot dopo la sua attivazione.
Scenario Principale: L’utente interagisce con Sanbot.
Postcondizioni: Sanbot è stato disattivato.3.1. CASI D’USO 19
Figura 3.8: Use Case - UC5: Gestione movimenti Sanbot
UC5: Gestione movimenti Sanbot
Attori Principali: Utente.
Precondizioni: L’utente deve aver attivato Sanbot.
Descrizione: L’utente può chiamare vocalmente Sanbot a sé e farsi seguire da que-
st’ultimo o smettere di essere seguito.
Scenario Principale:
∗ UC5.1: L’utente può chiamare Sanbot a sè;
∗ UC5.2: L’utente può essere seguito da Sanbot;
∗ UC5.3: L’utente può far smettere Sanbot di seguirlo.
Postcondizioni: Sanbot è stato disattivato.
Scenario Alternativo: L’utente non ha attivato Sanbot.20 CAPITOLO 3. ANALISI DEI REQUISITI
Figura 3.9: Use Case - UC6: Scatta Foto/Video
UC6: Scatta foto/video
Attori Principali: Utente.
Precondizioni: L’utente deve aver attivato Sanbot.
Descrizione: L’utente può scattare una foto o registrare un video tramite la fotoca-
mera frontale integrata di Sanbot.
Scenario Principale:
∗ UC6.1: L’utente può dire a Sanbot di scattare una foto;
∗ UC6.2: L’utente può dire a Sanbot di registrare un video.
Postcondizioni: La foto o il video verrà salvato nel tablet integrato a Sanbot.
Scenario Alternativo: L’utente non ha attivato Sanbot.3.2. TRACCIAMENTO DEI REQUISITI 21
3.2 Tracciamento dei requisiti
Da un’attenta analisi dei requisiti e degli use case effettuata sul progetto è stata stilata
la tabella che traccia i requisiti in rapporto ai casi d’uso.
Sono stati individuati diversi tipi di requisiti e si è quindi fatto utilizzo di un codice
identificativo per distinguerli.
i requisiti vengono classificati in base al tipo e alla priorità, utilizzando la seguente
notazione:
R[X][Y][Z]
dove:
1. X indica la tipologia del requisito. Deve assumere solo i seguenti valori:
∗ F: indica un requisito funzionale;
∗ Q: indica un requisito di qualità;
∗ P: indica un requisito prestazionale;
∗ V: indica un requisito vincolo.
2. Y indica l’importanza strategica del requisito. Deve assumere solo i seguenti
valori:
∗ OBB: indica un requisito obbligatorio;
∗ DES: indica un requisito desiderabile;
∗ OPZ: indica un requisito opzionale.
3. Z rappresenta il codice univoco di ogni requisito in forma gerarchica.22 CAPITOLO 3. ANALISI DEI REQUISITI
Tabella 3.1: Tabella del tracciamento dei requisti funzionali
Requisito Descrizione Use Case
RFOBB0 L’utente deve poter attivare Sanbot tramite wake- UC0
word vocale
RFOBB1 L’utente deve poter attivare la modalità presentazio- UC1.1
ne tramite comando vocale
RFDES1.1 L’utente deve poter attivare la modalità presentazio- UC1.2
ne tramite tasto
RFOBB2.1 L’utente deve poter selezionare un file da proiettare UC2.1
RFOBB2.1.1 L’utente deve poter selezionare un file pdf UC2.1
RFOBB2.1.2 L’utente deve poter selezionare un file video UC2.1
RFOBB2.1.3 L’utente deve poter selezionare un file immagine UC2.1
RFOBB2.2.1 L’utente deve poter ruotare l’immagine proiettata UC2.2.1
RFOBB2.2.2 L’utente deve poter modificare il colore dell’immagine UC2.2.2
proiettata
RFOBB2.2.3 L’utente deve poter modificare la luminosità UC2.2.3
dell’immagine proiettata
RFOBB2.2.4 L’utente deve poter modificare l’acuità dell’immagine UC2.2.4
proiettata
RFOBB2.2.5.1 L’utente deve poter selezionare la modalità di UC2.2.5
proiezione Wall
RFOBB2.2.5.2 L’utente deve poter selezionare la modalità di UC2.2.5
proiezione Ceiling
RFOBB2.3 L’utente deve poter interagire con il file proiettato UC2.3
RFOBB2.3.1.1 L’utente deve poter visualizzare la slide successiva UC2.3.1.1
RFOBB2.3.1.2 L’utente deve poter visualizzare la slide precedente UC2.3.1.2
RFOBB2.3.2.1 L’utente deve poter mettere in pausa il video UC2.3.2.1
RFOBB2.3.2.2 L’utente deve poter riprendere il video messo in pausa UC2.3.2.2
RFOBB3.1 L’utente deve poter terminare la modalità presenta- UC3.1
zione vocalmente
RFDES3.2 L’utente deve poter terminare la modalità presenta- UC3.2
zione tramite tasto
RFOBB4 L’utente deve poter interagire con Sanbot vocalmente UC4
RFOBB5 L’utente deve poter gestire i movimenti di Sanbot UC5
vocalmente
RFOBB5.1 L’utente deve poter chiamare Sanbot a sè vocalmente UC5.1
RFOBB5.2 L’utente deve potersi far seguire da Sanbot UC5.2
RFOBB5.3 L’utente deve poter far smettere Sanbot di seguirlo UC5.3
RFOPZ6.1 L’utente deve poter scattare una foto tramite la UC6.1
camera frontale di Sanbot
RFOPZ6.2 L’utente deve poter registrare un video tramite la UC6.2
camera frontale di Sanbot3.2. TRACCIAMENTO DEI REQUISITI 23
Tabella 3.2: Tabella del tracciamento dei requisiti qualitativi
Requisito Descrizione Use Case
RQDES1 Deve essere fornito un manuale utente per l’utilizzo Interno
dell’applicazione
RQDES2 Il manuale utente deve comprendere una sezione in cui Interno
viene spiegato come installare l’applicazione
RQDES3 Il manuale utente deve essere disponibile in lingua Interno
italiana
RQOPZ4 Il manuale utente deve essere disponibile in lingua inglese Interno
RQOPZ5 Deve essere fornito un manuale manutentore Interno
RQOPZ6 Il manuale manutentore deve comprendere una sezio- Interno
ne in cui viene spiegato come estendere le funzionalità
dell’applicazione
RQOBB8 Devono essere fatte delle simulazioni Interno
Tabella 3.3: Tabella del tracciamento dei requisiti di vincolo
Requisito Descrizione Use Case
RVOBB1 Deve essere fornita un’applicazione Android per UC1
l’assistenza ad una presentazione tramite il robot Sanbot
RVOPZ2 Per la realizzazione dell’applicazione deve essere Interno
utilizzato l’IDE Android Studio
RVOBB3 L’utente deve interagire con Sanbot in lingua inglese Interno
RVOBB4 Per lo sviluppo dell’applicazione deve essere utilizzata Interno
una versione di Android SDK 11 o superiore
RVOBB5 Per lo sviluppo dell’applicazione deve essere utilizzato Interno
l’SDK di Sanbot versione 1.1.8 o superioreCapitolo 4
Progettazione e sviluppo
In questo capitolo verrà affrontata l’attività di progettazione, discutendo delle tecnologie
e strumenti utilizzati, mostrando i diagrammi dell’architettura dell’applicativo ed infine
dando una panoramica del prodotto finale.
4.1 Tecnologie e strumenti
Di seguito viene data una panoramica delle tecnologie e strumenti utilizzati.
Android
Android è un sistema operativo per dispositivi mobili sviluppato da Google Inc. e
basato sul kernel [g] Linux. È un sistema operativo progettato principalmente per
smartphone e tablet, con interfacce utente specializzate per televisori (Android TV),
automobili (Android Auto), orologi da polso (Android Wear), occhiali (Google Glass)
e altri. Al 2017, Android è il sistema operativo per dispositivi mobili più diffuso al
mondo, con una fetta di mercato attestatasi a quota 62,94 sul totale, seguito da iOS
con il 33,9.
Java
Java è un linguaggio di programmazione orientato agli oggetti, specificatamente proget-
tato per essere il più possibile indipendente dalla piattaforma di esecuzione. Nonostante
la sua verbosità, si è affermato come il linguaggio più diffuso ed utilizzato per la
scrittura di applicazioni Android, fornendo un vasto numero di librerie e un’ampia
documentazione.
Android Studio
Android Studio è un ambiente di sviluppo integrato (IDE [g] ) gratuito per lo sviluppo
per la piattaforma Android. È stato progettato specificatamente per lo sviluppo di
applicazioni Android, quindi fornisce un’enorme gamma di comodità: emulatori dei
vari dispositivi Android sul mercato con la versione scelta del sistema operativo, un
designer per progettare l’interfaccia dell’applicazione in maniera semplice ed intuitiva,
un logger dell’esecuzione dell’applicazione, un debugger [g] ed altro ancora.
2526 CAPITOLO 4. PROGETTAZIONE E SVILUPPO Git Git è un software di controllo versione distribuito utilizzabile da interfaccia a riga di comando, creato da Linus Torvalds nel 2005. BitBucket Bitbucket è un servizio di hosting web-based per progetti che usano i sistemi di controllo versione Mercurial o Git. È stato preferito a GitHub in quanto fornisce gratuitamente repository Git con la possibilità di renderle private.
4.2. PROGETTAZIONE 27
4.2 Progettazione
Di seguito verranno mostrati i diagrammi dei package e delle classi realizzati durante
la fase di progettazione architetturale e di dettaglio.
Per lo sviluppo dell’applicazione ho deciso di utilizzare il design pattern [g] Model-
View-Presenter, in quanto, dopo varie ricerche, ho scoperto essere il più utilizzato
in ambito di sviluppo Android ed è quello che più si avvicina alla struttura base di
un’applicazione Android.
Inoltre da notare che le componenti esterne utilizzate provenienti dall’SDK Sanbot
sono segnate in arancione, mentre le altre (SDK Android [g] , android-file-chooser e
PDFView) sono segnate in azzurro.
Diagramma generale
Figura 4.1: Progettazione: Diagramma generale
Package contenente tutta l’applicazione, per la realizzazione implementativa si
utilizzeranno le librerie offerte dall’SDK Android per il funzionamento dell’applicazione
e l’SDK Sanbot per il controllo del robot.
Model: Contiene la business logic [g] dell’applicazione.
View: Contiene la GUI [g] dell’applicazione.
Presenter: Componente che fa da tramite fra Model e View.28 CAPITOLO 4. PROGETTAZIONE E SVILUPPO
4.2.1 App::Model
Figura 4.2: Progettazione: App::Model
Package contenente il modello dell’applicazione.
App_Manager: Gestisce il controllo della presentazione, la parte più consistente
dell’applicazione.
Motion_Manager: Gestisce i movimenti della testa e delle ruote del robot.
Multimedia_Manager: Gestisce lo stream video della camera HD frontale tramite
cui è possibile scattare foto e registrare video.
Speech_Manager: Gestisce l’interazione vocale col robot.4.2. PROGETTAZIONE 29
4.2.2 App::Model::App_Manager
Figura 4.3: Progettazione: App::Model::App_Manager
Package contenente la logica di gestione della presentazione.
ProjectorManager: Classe che permette la gestione del proiettore e delle sue impo-
stazioni, implementa un oggetto ProjectorManager dall’SDK di Sanbot.
∗ Attributi:
– ProjectorManager pManager : oggetto attraverso cui vengono fatte
chiamate alla libreria di Sanbot;
– boolean pStatus : indica se il proiettore è acceso (true) o spento (false);
– int pColor : indica il colore dell’immagine (range[-15;15]);
– int pBrightness : indica la luminosità dell’immagine (range [-30:30]);
– int pAcuity : indica l’acuità dell’immagine (range [0:6]);
– boolean pMode : indica la modalità di proiezione (0 Wall, 1 Ceiling).
∗ Metodi:
– void flipImage() : ruota l’immagine;
– void setImageColor() : imposta il colore dell’immagine;
– void setImageBrightness() : imposta la luminosità dell’immagine;
– void setImageAcuity() : imposta l’acuità dell’immagine;
– void setProjMode() : imposta la modalità di proiezione;
– void switchProjStatus() : accende/spegne il proiettore.30 CAPITOLO 4. PROGETTAZIONE E SVILUPPO
FileManager: Classe che gestisce la raccolta e l’apertura del file da proiettare, imple-
menta una classe annidata FileType. Questa classe si avvale delle proprietà della
libreria esterna android-file-chooser.
∗ Attributi:
– List fileList : lista di oggetti FileType rappresentanti i file
apribili per la proiezione.
∗ Metodi:
– FileType selectFile() : ritorna il file selezionato dalla lista;
– void openFile() : apre il file;
– void closeFile() : chiude il file.
PresentationManager: Package contenente la gestione del file proiettato, al suo
interno vi sono le classi per tipo di file aperto: VideoManager per i video,
ImageManager per le immagini e SlideManager per le diapositive (in PDF),
quest’ultima si avvale della libreria esterna PDFView.
∗ VideoManager:
– Attributi:
∗ boolean isPaused : indica se il video è in pausa (true) o meno (false).
– Metodi:
∗ void pause() : mette in pausa il video;
∗ void resume() : riprende la riproduzione del video.
∗ ImageManager:
– Metodi:
∗ void zoomIn() : effettua un zoom-in dell’immagine;
∗ void zoomOut() : effettua uno zoom-out dell’immagine.
∗ SlideManager:
– Metodi:
∗ void nextSlide() : passa alla prossima slide;
∗ void previousSlide() : torna alla slide precedente.4.2. PROGETTAZIONE 31
4.2.3 App::Model::Motion_Manager
Figura 4.4: Progettazione: App::Model::Motion_Manager
Package contenente le classi che gestiscono i movimenti della testa e delle ruote.
HeadManager:: Classe che gestisce i movimenti della testa.
∗ Attributi:
– HeadMotionManager hManager : oggetto attraverso cui vengono effet-
tuate chiamate alla libreria di Sanbot.
∗ Metodi:
– void horizontalMove() : per muovere la testa orizzontalmente (destra,
sinistra);
– void verticalMove() : per muovere la testa verticalmente (sù, giù).
WheelsManager:: Classe che gestisce i movimenti delle ruote.
∗ Attributi:
– WheelMotionManager wManager : oggetto attraverso cui vengono
effettuate chiamate alla libreria di Sanbot;
– int speed : parametro della velocità di movimento (1-10).
∗ Metodi:
– void run() : metodo per muovere il robot in linea retta;
– void follow() : metodo per far seguire un target definito;
– void turnLeft() : metodo per girare a sinistra;
– void turnRight() : metodo per girare a destra;
– void stop() : metodo per fermare il movimento del robot;
– void setSpeed() : metodo per modificare il parametro della velocità.32 CAPITOLO 4. PROGETTAZIONE E SVILUPPO
4.2.4 App::Model::Conversation_Manager
Figura 4.5: Progettazione: App::Model::Conversation_Manager
Package contenente le classi che gestiscono l’interazione vocale tra utente e robot.
SpeechManager: Classe che gestisce la conversazione parte robot.
∗ Attributi:
– SpeechManager sManager : oggetto attraverso cui vengono effettuate
chiamate alla libreria di Sanbot;
– int speed : parametro di velocità della parlata del robot;
– boolean isSpeaking : parametro che indica se il robot sta parlando
(true) o meno (false).
∗ Metodi:
– void speak() : metodo per far parlare il robot;
– void stopSpeaking() : metodo per fermare la parlata del robot;
– void setSpeed() : metodo per modificare il parametro della velocità di
parlata.
SpeechCatcher: Classe utilizzata per lo speech recognition esterno.
∗ Attributi:4.2. PROGETTAZIONE 33
– SpeechListener speechListener : interfaccia della libreria di Sanbot per
il riconoscimento vocale.
∗ Metodi:
– string recognizedText() : metodo che ritorna il testo riconosciuto dal
robot.
SpeechAnalyzer: Classe che analizza lo speech in entrata e predispone l’action da
compiere.
∗ Attributi:
– string keyword : parametro della keyword riconosciuta dal robot.
∗ Metodi:
– boolean findKeyword() : metodo che cerca la keyword nel file key-
words.json e ritorna true se la ricerca è andata a buon fine, false
altrimenti;
– void action() : metodo che invoca un’azione in risposta all’utente.34 CAPITOLO 4. PROGETTAZIONE E SVILUPPO
4.2.5 View e Presenter
Di seguito verrà mostrato il diagramma delle associazioni tra le View e le Activity,
entrambe componenti imprescindibili dello sviluppo Android, le prime forniscono uno
schermo con cui gli utenti possono interagire con l’applicazione eseguendo azioni,
mentre le View rappresentano l’User Interface [g] di ogni Activity, esse in Android sono
scritte in XML[g] .
Per ogni oggetto della View, vi è un metodo nell’Activity che farà partire un’azione
richiamando classi del model. Per collegare la View all’Activity bisogna effettuare il
binding con il metodo setContentView() nel metodo void onCreate() che ogni Activity
deve obbligatoriamente avere, questo verrà eseguito al lancio di essa. Questo è un
esempio:
@Override
public void onCreate ( Bundle savedInstanceState ) {
super . onCreate ( savedInstanceState ) ;
setContentView ( R . layout . activity_view ) ;
}
Il percorso R.layout.activity_view si riferisce al percorso nella cartella res in cui si
trovano le View.
Per passare da un’Activity all’altra, invece, bisogna creare un Intent, come nel
seguente esempio:
public void nextActivity () {
Intent intent = new Intent ( this , NewActivity . class ) ;
startActivity ( intent ) ;
}
Di seguito un esempio dell’architettura di dettaglio di HomeActivity e HomeView,
le altre non sono state incluse nel presente documento in quanto le considero di poco
interesse ai fini dello stesso.4.2. PROGETTAZIONE 35
Figura 4.6: Progettazione: HomeActivity e HomeView
Nella Home vi sono due button, presentationButton che porta all’avvio della proce-
dura di selezione file e multimediaButton che invece porta alla sezione Foto/Video in
cui si utilizza la camera frontale di Sanbot. Entrambe sono raggiungibili sia tramite
pressione tasto che vocalmente.36 CAPITOLO 4. PROGETTAZIONE E SVILUPPO
4.2.6 Service
Oltre alle Activities ho implementato un Service, altra componente fondamentale
Android e che merita un accenno, esso rappresenta un servizio che lavora in background
dall’apertura fino alla chiusura dell’applicazione, per semplificarne la comprensione lo
si può paragonare a dei metodi asincroni o trigger che vengono azionati all’avvenire di
una determinata azione.
Figura 4.7: Progettazione: Service
In particolare il Service è stato utilizzato per la gestione in tutte le Activities del
movimento e della conversazione di Sanbot.
Per il suo utilizzo bisogna effettuare, come per le View, il binding con l’Activity,
come mostrato nel seguente esempio:
public class HomeActivity {
MainService mService ;
public void onCreate ( Bundle savedInstanceState ) {4.2. PROGETTAZIONE 37
Intent intent = new Intent ( HomeActivity . this ,
MainService . class ) ;
intent . setPackage ( getPackageName () ) ;
bindService ( intent , connection , Context . BIND_AUTO_CREATE )
;
startService ( intent ) ;
}
ServiceConnection connection = new ServiceConnection () {
@Override
public void onServiceConnected ( ComponentName name ,
IBinder service ) {
MainService . MyBinder binder = ( MainService . MyBinder )
service ;
mService = binder . getService () ;
}
};
@Override
public void onDestroy () {
if ( mService != null ) {
unbindService ( connection ) ;
}
super . onDestroy () ;
}
}
4.2.7 Prodotto finale
Di seguito verranno mostrati degli screenshot dell’applicazione allo stato in cui era
a fine stage, denominata PresentationApp, descrivendone le funzionalità e i comandi
vocali implementati.
L’interfaccia utente è stata realizzata solamente in lingua inglese, ma l’interazione
vocale è stata implementata sia in inglese che in italiano.
Schermata principale All’interno della schermata principale è possibile effettuare
una delle due azioni presenti (select file e open camera stream) tramite pressione dei
tasti sullo schermo oppure vocalmente, tramite le seguenti istruzioni:
∗ "Seleziona file" per la lingua italiana o "Select file" per quella inglese;
∗ "Accendi la fotocamera" o "Avvia la fotocamera" per la lingua italiana, "Open
camera" o "Start video stream" per la lingua inglese.
Una volta scelta una delle due opzioni l’applicazione passerà ad una nuova schermata.
Oltre ai comandi sopracitati, vi sono altre funzionalità invocabili vocalmente,
riguardanti i movimenti di Sanbot:
∗ Pronunciando "Seguimi", "Follow me" o "Follow" il robot seguirà l’utente lungo
il suo percorso;38 CAPITOLO 4. PROGETTAZIONE E SVILUPPO
Figura 4.8: GUI: Schermata principale
∗ Pronunciando "Esplora" , "Inizia esplorazione", "Explore" o "Start exploring" il
robot esplorerà l’ambiente circostante;
∗ Pronunciando "Caricati", "Vai in carica", "Charge" o "Go to charge" il robot
tornerà nella sua postazione a ricaricarsi la batteria;
∗ Pronunciando "Fermo", "Fermati", "Stop" o "Stop it" il robot fermerà qualsiasi
azione stesse facendo.4.2. PROGETTAZIONE 39
Figura 4.9: GUI: Schermata Selezione File
Schermata Selezione File In questa schermata è possibile selezionare il tipo di
file da proiettare durante la presentazione, esso può essere di tre tipi diversi: video,
immagine o PDF. Inoltre vi è presente il pulsante "Projector Settings" che porta alla
schermata di impostazione avanzata del proiettore integrato al robot. Le istruzioni
vocali sono le seguenti:
∗ "Seleziona video" o "Select video" per selezionare un video;
∗ "Seleziona immagine" o "Select image" per selezionare un’immagine;
∗ "Seleziona slide", "Seleziona diapositiva" o "Select slide" per selezionare un file
PDF;
∗ "Impostazioni", "Apri impostazioni", "Open projector settings" o "Open settings"
per aprire la schermata delle impostazioni del proiettore.
Una volta selezionata una delle prime tre azioni verrà aperto il File Manager in cui
verranno visualizzati solamente i file presenti in memoria del tipo selezionato.40 CAPITOLO 4. PROGETTAZIONE E SVILUPPO
Figura 4.10: GUI: Schermata Video
Schermata Video In questa schermata vengono visualizzati i video precedentemente
selezionati, la loro riproduzione può essere controllata tramite i pulsanti Pause Video,
Resume Video e Close Video, sia tramite pressione che vocalmente. Le istruzioni da
pronunciare sono le seguenti:
∗ "Pausa" o "Pause" per mettere il video in pausa;
∗ "Riprendi" o "Resume" per riprendere il video;
∗ "Chiudi file", "Chiudi video", "Close file" o "Close video" per chiudere il video e
tornare alla schermata precedente.4.2. PROGETTAZIONE 41
Figura 4.11: GUI: Schermata Immagine
Schermata Immagine In questa schermata vengono visualizzate le immagini, si
può tornare alla schermata precedente attraverso la pressione del tasto Close Image
oppure vocalmente pronunciando i comandi "Close file", "Close image" o "Chiudi
immagine".
Non sono riuscito ad implementare lo zoom-in e zoom-out.42 CAPITOLO 4. PROGETTAZIONE E SVILUPPO
Figura 4.12: GUI: Schermata PDF
Schermata PDF In questa schermata vengono visualizzati i file PDF, le cui pagine
possono essere scorse tramite la pressione dei tasti Next Page e Previous Page, oppure
vocalmente pronunciando i seguenti comandi:
∗ "Prossima", "Prossima pagina", "Next slide" o "Next" per passare alla pagine
successiva;
∗ "Precedente", "Pagina precedente", "Previous slide" o "Previous" per tornare
alla pagine precedente;
∗ "Chiudi file", "Chiudi diapositiva", "Close file" o "Close slide" per tornare alla
schermata precedente.4.2. PROGETTAZIONE 43
Figura 4.13: GUI: Schermata Impostazioni Proiettore
Schermata Impostazioni Proiettore In questa schermata è possibile avviare il
proiettore ed impostarne in dettaglio i parametri di visualizzazione dell’immagine,
modificando valori di luminosità, contrasto, colore, acuità, la modalità di proiezione tra
Wall e Ceiling e ruotando l’immagine. Alcune di queste funzionalità sono disponibili
anche vocalmente:
∗ Pronunciando "Accendi proiettore" o "Start projector" si avvierà il proiettore;
∗ Pronunciando "Spegni proiettore" o "Stop projector" si spegnerà il proiettore;
∗ Pronunciando "Ruota immagine" o "Rotate image" si ruoterà l’immagine;
∗ Pronunciando "Cambia modalità" o "Change mode" si passerà dalla modalità
Wall a Ceiling e viceversa.44 CAPITOLO 4. PROGETTAZIONE E SVILUPPO
Figura 4.14: GUI: Schermata Registrazione Video
Schermata Registrazione Video In questa schermata è possibile registrare video
tramite la camera HD integrata al robot. Per iniziare la registrazione bisognerà premere
il pulsante Start o tramite comando vocale "Registra" o "Start", si può poi concludere
la registrazione tramite il tasto Stop o il comando vocale "Ferma la registrazione" o
"Stop".Capitolo 5
Verifica e validazione
In questo capitolo verranno esposte le tecniche utilizzate durante lo stage per l’attività di
verifica e validazione del prodotto.
5.0.1 Verifica
Con il processo di verifica viene accertato che lo stato di avanzamento del prodotto
e delle sue parti soddisfi gli obiettivi ed i requisiti precedentemente fissati in fase di
pianificazione.
Tale processo prevede tecniche di analisi che possono esser suddivise in due categorie:
∗ Analisi statica: tipo di analisi che non richiede l’esecuzione del software e dunque
può esserre effettuata in corso d’opera.
∗ Analisi dinamica: tipo di analisi che richiede l’esecuzione del software e che si
avvale di test progettati che devono essere ripetibili.
Durante il mio stage, l’attività di analisi statica è stata effettuata sia sul codice, sia
sulla documentazione prodotta in questo periodo. Per fare ciò ho adottato le tecniche
di Inspection e Walkthrough su tutto il materiale prodotto, in modo da individuare la
maggior parte degli errori in questa fase, risparmiando tempo prezioso nella fase di
analisi dinamica.
Per quanto riguarda l’analisi dinamica, sono stati effettuati test di unità ad ogni
metodo creato e di integrazione al completamento di un’intero componente del pro-
gramma. Mi sono inoltre avvalso molto dell’attività di debugging [g] , grazie al debugger
presente all’interno dell’IDE Android Studio, che mi ha permesso di capire meglio il
funzionamento e i malfunzionamenti del sistema operativo [g] del robot stesso, in quanto
durante il periodo di stage era ancora in fase iniziale e presentava molte incongruenze
che hanno reso difficile la programmazione.
4546 CAPITOLO 5. VERIFICA E VALIDAZIONE 5.0.2 Validazione Il processo di validazione ha lo scopo di accertare che il prodotto finale corrisponda alle attese e che soddisfi tutti i requisiti prefissati inizialmente. A questo scopo alla fine della fase di sviluppo è stato fatto un collaudo con il tutor aziendale Andrea Molon, il CEO dell’azienda Matteo Cestari ed altri componenti di Omitech. Tale attività è in genere un testing black-box (a scatola nera) detto anche testing funzionale basato solo sulle specifiche del software, in quanto i tester non accedono al suo codice. Il collaudo ha avuto un esito parzialmente positivo, in quanto è stato riscontrato che sono stati coperti tutti i requisiti concordati ad inizio stage e sono state implementate tutte le funzionalità presenti nell’analisi dei requisiti, ma sono state rilevate delle instabilità dovute però a problemi del sistema operativo, come sopra citato, e non al codice prodotto.
Capitolo 6
Conclusioni
In questo capitolo verrà discusso il raggiungimento degli obiettivi prefissato ad inizio stage,
verranno prese in considerazione le conoscenze acquisite ed infine verrà data una valutazione
personale riguardante l’intera esperienza di stage svolta in azienda.
6.1 Raggiungimento degli obiettivi
Gli obiettivi concordati nel Piano di Lavoro (descritti nel paragrafo 2.1.2 di questo
documento) sono stati tutti raggiunti, sia quelli obbligatori che quelli desiderabili e
facoltativi, in particolare:
∗ L’obiettivo desiderabile D01 è stato soddisfatto in quanto è disponibile l’intera-
zione vocale con Sanbot;
∗ L’obiettivo facoltativo F01 è stato soddisfatto, infatti è stato prodotto un manuale
per l’uso dell’applicazione di cui è stata proposta una parte nel paragrafo 4.2.7
di questo documento.
Il prodotto finale rispecchia ciò che l’azienda si aspettava anche se c’è ancora del
lavoro da fare per rendere il prodotto utilizzabile, in quanto l’applicazione è stata
pensata come una demo, con uno stage di durata maggiore si sarebbe potuto sviluppare
un prodotto più completo.
6.2 Valutazione personale
Ritengo che l’esperienza di stage sia stata particolarmente utile e formativa dal punto
di vista personale. Ho avuto l’opportunità di sfruttare le conoscenze acquisite durante
il corso di studi, imparare a lavorare con nuove tecnologie e soprattutto approcciarmi
per la prima volta al mondo del lavoro.
In particolare penso che lo stage offerto da Omitech S.r.l. sia tra quelli più interes-
santi offerti da aziende affiliate con l’Università, soprattutto in ottica futura aver avuto
l’occasione di imparare a sviluppare App e lavorare con tecnologie avanzate come il
robot Sanbot mi sarà molto utile in futuro oltre ad aver acceso in me nuovi stimoli
47Puoi anche leggere
