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 Introduzione1 1.1 L’azienda ...... 1 1.2 Il progetto di stage ...... 2 1.3 Organizzazione dei contenuti ...... 2
2 Descrizione dello stage3 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 requisiti9 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.
3 4 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.setOnHareWareListener(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.
9 10 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 Sanbot 3.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 superiore
Capitolo 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.
25 26 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
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.
45 46 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
47 48 CAPITOLO 6. CONCLUSIONI nell’approfondire tali tecnologie.
In definitiva mi reputo soddisfatto del lavoro svolto e ritengo che le conoscenze ac- quisite all’università siano un’ottima base sulla quale continuare a costruire e sviluppare le proprie conoscenze. 6.2. VALUTAZIONE PERSONALE 49
Glossario
business logic in informatica l’espressione logica si riferisce a tutta quella logica appli- cativa che rende operativa un’applicazione cioè la parte o nucleo di elaborazione. 49
Cloud con questo termine si indica un paradigma di erogazione di risorse informatiche, come l’archiviazione, l’elaborazione o la trasmissione di dati, caratterizzato dalla disponibilità on demand attraverso Internet a partire da un insieme di risorse preesistenti e configurabili. 49 debugger un debugger in informatica è un programma/software specificatamente progettato per l’analisi e l’eliminazione dei bug (debugging), ovvero errori di programmazione interni al codice di altri programmi. 49 debugging in informatica, indica l’attività che consiste nell’individuazione e correzione da parte del programmatore di uno o più errori (bug) rilevati nel software, direttamente in fase di programmazione oppure a seguito della fase di testing o dell’utilizzo finale del programma stesso. 49 design pattern in informatica, nell’ambito dell’ingegneria del software, un design pattern (ing. schema di progettazione), è un concetto che può essere definito "una soluzione progettuale generale ad un problema ricorrente". Si tratta di una descrizione o modello logico da applicare per la risoluzione di un problema che può presentarsi in diverse situazioni durante le fasi di progettazione e sviluppo del software, ancor prima della definizione dell’algoritmo risolutivo della parte computazionale. 49
GUI la GUI, Graphical User Interface in informatica è un tipo di interfaccia utente che consente l’interazione uomo-macchina in modo visuale utilizzando rappre- sentazioni grafiche piuttosto che utilizzando una interfaccia a riga di comando. 49
IDE in informatica IDE, Integrated Development Environment (ing. ambiente di sviluppo integrato) è un software che, in fase di programmazione, aiuta i pro- grammatori nello sviluppo del codice sorgente di un programma. Spesso l’IDE aiuta lo sviluppatore segnalando errori di sintassi del codice direttamente in fase di scrittura, oltre a tutta una serie di strumenti e funzionalità di supporto alla fase di sviluppo e debugging. 49 kernel in informatica, il nucleo di un sistema operativo, che gestisce le funzioni di controllo fondamentali del computer. 49
51 52 Glossario
SDK un software development kit (SDK, traducibile in italiano come "pacchetto di sviluppo per applicazioni"), in informatica, indica genericamente un insieme di strumenti per lo sviluppo e la documentazione di software. 49 SDK Android è il pacchetto di sviluppo per applicazioni Android, contiene un insieme di strumenti utili allo sviluppo e tutta la documentazione relativa ad Android. 49 sistema operativo in informatica, è un software di sistema che gestisce le risorse hardware e software della macchina, fornendo servizi di base ai software applicativi (programmi) installati. 49 speech recognition è il processo mediante il quale il linguaggio orale umano viene riconosciuto e successivamente elaborato attraverso un computer o più specifica- tamente attraverso un apposito sistema di riconoscimento vocale. 49
UML in ingegneria del software UML, Unified Modeling Language (ing. linguaggio di modellazione unificato) è un linguaggio di modellazione e specifica basato sul paradigma object-oriented. L’UML svolge un’importantissima funzione di "lingua franca" nella comunità della progettazione e programmazione a oggetti. Gran parte della letteratura di settore usa tale linguaggio per descrivere soluzioni analitiche e progettuali in modo sintetico e comprensibile a un vasto pubblico. 49 User Interface anche conosciuta come UI (ing. Interfaccia Utente), è un’interfaccia uomo-macchina, ovvero ciò che si frappone tra una macchina e un utente, con- sentendone l’interazione reciproca. In generale può riferirsi a una macchina di qualsiasi natura, tuttavia l’accezione più nota è in ambito informatico. 49
XML in informatica XML, eXtensible Markup Language (ing. linguaggio di marcatura estensibile) è un metalinguaggio per la definizione di linguaggi di markup, ovvero un linguaggio marcatore basato su un meccanismo sintattico che consente di definire e controllare il significato degli elementi contenuti in un documento o in un testo. 49 Bibliografia
Siti web consultati
Android Developers. url: https://developer.android.com. Omitech Srl. url: https://www.omitech.it. Sanbot Italia. url: http://www.sanbot.it. Stack Overflow. url: http://stackoverflow.com. Wikipedia. url: https://it.wikipedia.org.
53