Università degli Studi di Padova
Dipartimento di Matematica "Tullio Levi-Civita"
Corso di Laurea in Informatica
Sviluppo di un’applicazione mobile sulla realtà aumentata
Tesi di laurea triennale
Relatore
Prof.Ombretta Gaggi
Laureando Andrea Magnan Matricola 1096609
Anno Accademico 2016-2017
Indice
1 Contesto aziendale 3
1.1 Profilo aziendale . . . 3
1.2 Processi aziendali . . . 4
1.2.1 Organizzazione interna . . . 4
1.2.2 Modello di sviluppo . . . 5
1.2.3 Modello incrementale in Sopra Steria . . . 6
1.3 Caratterizzazione dei clienti . . . 7
1.4 Innovazione . . . 7
2 Il Progetto 9 2.1 Interesse aziendale . . . 9
2.2 Descrizione del progetto . . . 9
2.3 Aspettative dell’azienda . . . 10
2.4 Obiettivi del progetto . . . 10
2.5 Vincoli . . . 12
2.5.1 Vincoli temporali . . . 12
2.5.2 Vincoli imposti dall’azienda . . . 12
2.6 Tecnologie utilizzate . . . 13
2.6.1 Tecnologie principali . . . 13
2.6.2 Tecnologie di supporto . . . 15
2.6.3 Strumenti utilizzati . . . 16
3 Lo stage 17 3.1 Analisi dei rischi . . . 17
3.2 Analisi dei requisiti . . . 18
3.2.1 Analisi del dominio applicativo e di soluzioni esistenti . . . 18
3.2.2 Requisiti individuati . . . 19
3.3 Progettazione e sviluppo . . . 21
3.3.1 Architettura di un’applicazione iOS . . . 21
3.3.2 Architettura di un’applicazione sviluppata con Apache Cordova 23 3.3.3 Architettura del progetto . . . 24
3.4 Validazione . . . 31
3.4.1 Test effettuati . . . 31
4 Conclusioni 33 4.1 Soddisfacimento dei requisiti . . . 33
4.2 Soddisfacimento degli obiettivi pianificati . . . 34
4.3 Esperienza di stage . . . 34 iii
iv INDICE 4.4 Sviluppi futuri . . . 35 4.5 Conoscenze acquisite . . . 35
Glossario 37
Bibliografia 39
Elenco delle figure
1.1 Logo di Sopra Steria Group S.p.A . . . 3
1.2 Diagramma del modello di sviluppo incrementale . . . 5
2.1 Obiettivi pianificati, suddivisi per tipologia . . . 11
2.2 Logo di Apache Cordova . . . 13
2.3 Logo di ARKit . . . 14
2.4 Logo di Backbone.js . . . 15
3.1 Requisiti individuati suddivisi per tipologia . . . 21
3.2 Struttura di un’applicazione iOS (Fonte: https://goo.gl/o4BLof) . . 22
3.3 Struttura di un’applicazione sviluppata tramite Apache Cordova (Fonte: https://cordova.apache.org/docs/en/latest/guide/overview/) . 23 3.4 Schermata principale dell’applicazione . . . 24
3.5 Selezione di una categoria di prodotti . . . 26
3.6 Selezione di un prodotto dalla lista . . . 26
3.7 Selezione del colore del prodotto . . . 27
3.8 Visualizzazione di una foto appena scattata . . . 28
3.9 Esempio di Viewstack (Fonte:https://github.com/vash15/backbone. viewstack) . . . 29 3.10 Ciclo di vita di un’applicazione iOS (Fonte:https://goo.gl/bCcqq6) 32
v
Elenco delle tabelle
2.1 Obiettivi definiti nel piano di lavoro . . . 10 3.1 Requisiti principali individuati . . . 20 4.1 Obiettivi raggiunti durante lo svolgimento dello stage . . . 34
vii
Convenzioni tipografiche
Per la stesura del seguente documento ho adottato le seguenti norme tipografiche:
∗ L’utilizzo del corsivo per le parole di ambito tecnico o in lingua inglese che non presentano un corrispettivo termine in italiano;
∗ L’indicazione con una G (esempio: termine[g]) della prima occorrenza di tutti i termini che ne- cessitano di una spiegazione esplicita, definita nel glossario presente a fine documento;
∗ L’indicazione come numero ad apice indica la presenza di una fonte in bibliografia, presente a fine documento.
Capitolo 1
Contesto aziendale
1.1 Profilo aziendale
Sopra Steria Group S.p.A. (Figura1.1), leader europeo in ambito di trasformazione digitale, è una società che offre servizi di consulenza, system integration e sviluppo software spaziando diversi mercati come Fashion, Banking, Energy, Aeronautica, Setto- re pubblico, Difesa e Trasporti[1].
Figura 1.1: Logo di Sopra Steria Group S.p.A
Sopra Steria è partner di riferimento delle principali aziende ed organizzazioni pub- bliche e private, proponendo progetti di trasformazione digitale che puntano ad un’alta qualità dei servizi erogati, valore aggiunto e innovazione. Conta 38.000 collaboratori in più di 20 paesi con un fatturato nel 2016 di 3,7 miliardi di euro ed opera sul territorio italiano con oltre 800 risorse distribuite nelle sue sedi di Assago (MI), Roma, Collecchio (PR), Padova e e Ariano Irpino (AV).
Il gruppo è il risultato di una fusione, avvenuta nel 2014, ad opera di due azien- de francesi Sopra Group SA and Groupe Steria SCA, comunemente chiamate Sopra e Steria, fondate rispettivamente nel 1968 e 1969. Ad oggi l’azienda si presenta interna- mente ben strutturata in Business Unit relative agli ambiti di sviluppo e adotta una politica di recruiting che mira alla competenza dei dipendenti da cui deriva la qualità dei prodotti, punto di forza dell’azienda.
Io sono stato inserito all’ interno del team "Mobile" appartenente alla divisione
"Industria & Servizi" la quale si occupa di proporre a clienti del mondo Fashion &
Luxury diverse soluzioni software. Il mio ruolo è stato quello di programmatore e sono 3
4 CAPITOLO 1. CONTESTO AZIENDALE stato affiancato dagli altri membri del team nonchè dal mio tutor, Thomas Baggio, avente il ruolo di Project Manager.
1.2 Processi aziendali
Sopra Steria Group è un’azienda di grosse dimensioni, che opera a livello europeo. Per poter operare senza intoppi o grosse difficoltà di gestione, utilizza una struttura ben definita di processi aziendali[2].
1.2.1 Organizzazione interna
Le grosse dimensioni dell’azienda comportano un grande livello di attenzione verso la propria organizzazione interna e gli elementi alla base di essa. Durante il mio stage ho avuto modo di osservare alcuni aspetti di questo complesso sistema.
Aspetto molto importante per l’azienda è la cura dei rapporti con il cliente: ven- gono infatti offerte numerose sessioni di consulenza. Aiutare il cliente a capire di cosa ha bisogno, permette all’azienda di offrire soluzioni sempre pù vicine alle sue neces- sità. La missione principale del gruppo è di industrializzare e ottimizzare le proprie operazioni per migliorare la competitività e le performance in un’ottica a lungo termine.
Un altro aspetto ritenuto importante dall’azienda è la gestione delle risorse umane;
infatti sostenerne lo sviluppo e l’evoluzione è considerato una priorità per il successo aziendale in quanto aggiunge un vantaggio competitivo e aiuta a mantenere un alto livello di soddisfazione e di motivazione nei dipendenti. Per questo Sopra Steria si impegna a conoscere i profili e le competenze di ciascun collaboratore, e di valutare per ognuno di essi prospettive di crescita e percorsi di carriera in grado di soddisfare sia le loro aspettative che il mercato.
Riguardo alla gestione del gruppo, essa avviene tramite una suddivisione dei vari ruoli, strutturata in diversi livelli di poteri decisionali, sia a livello funzionale che produttivo, distribuiti sia in base alle responsabilità tramite struttura gerarchica, che per la direzione, in base alle diversità dei singoli ruoli previsti. Questa organizzazione complessa viene costruita in base alle varie nazioni in cui l’azienda si estende, delegando l’amministrazione di questi filoni e di altri reparti di supporto a manager selezionati.
Nel livello più basso si collocano le Business Unit, ovvero le varie divisioni aziendali che si occupano della produzione vera e propria di prodotti e servizi identificati in base al mercato di riferimento. Anche queste ultime risultano distribuite nel territorio, in ogni filiale infatti possono coesistere più reparti.
All’interno della divisione in cui sono stato collocato, sono presenti diverse figure che si occupano dei vari processi produttivi. In ordine gerarchico è presente un di- rettore di Business Unit per l’amministrazione delle risorse della divisione, i project manager per la gestione dei progetti e dei loro costi, i commerciali che si occupano delle relazioni con i clienti in ambito di redazione dei contratti, i team di analisti e consulenti che si occupano dei requisiti del cliente e i team di sviluppo software.
L’azienda adotta inoltre un sistema di gestione della qualità per i propri processi interni; viene in particolare applicato per:
1.2. PROCESSI AZIENDALI 5
∗ gestione di processi di prevendita e sviluppo di progetti e servizi;
∗ gestione delle risorse umane nel campo di reclutamento, carriera, gestione delle competenze, formazione interna e comunicazioni interne;
∗ gestione e monitoraggio dei processi aziendali, garantendo una manutenzione interna.
Sopra Steria si fa carico inoltre delle responsabilità d’impresa negli ambiti di uno sviluppo sostenibile, cura dell’ambiente, diritti umani e del lavoro e nel favorire le uguali opportunità. La pubblicazione del rapporto di tali attività fa parte di un processo di trasparenza, correttezza e dialogo con gli stakeholder : collaboratori, clienti, azionisti, fornitori, partner e attori della società civile.
1.2.2 Modello di sviluppo
Il ciclo di sviluppo software adottato dal team Mobile è un’implementazione del modello incrementale. È stato scelto in quanto facilita la produzione di prototipi e i rapporti con il cliente.
I punti di forza di questo modello sono:
∗ L’integrazione delle varie funzionalità sviluppate avviene nel tempo senza essere collassata nelle fasi finali;
∗ Ogni incremento porta l’aggiunta di nuove funzionalità e permette di soddisfare alcuni requisiti;
∗ Le funzionalità principali vengono sviluppate per prime attraversano più fasi di verifica, diventando così sempre più stabili.
Questo modello si presta bene alle necessità aziendali in quanto spesso i clienti richiedono lo sviluppo di funzionalità aggiuntive definibili dal modello come singoli incrementi, o che richiedano lo sviluppo di prototipi a cui in futuro verranno inseriti incrementi.In figura1.2vengono rappresentate le diverse fasi del modello.
Figura 1.2: Diagramma del modello di sviluppo incrementale
Il modello incrementale è un ciclo di sviluppo definito dallo standard ISO 12207 che unisce la logica del modello a cascata, in cui ogni fase è rigidamente sequenziale,
6 CAPITOLO 1. CONTESTO AZIENDALE
ad uno sviluppo per singoli incrementi.
Questo modello attraversa una fase iniziale di analisi dei requisiti e progettazione, necessarie per stabilire la base del prodotto da sviluppare, le quali non vengono ripetute.
Successivamente vengono sviluppati i veri e propri incrementi: ognuno di essi passa per fasi di progettazione, codifica e viene poi sottoposto a test. Al termine di tutto l’incremento viene implementato, diventato a tutti gli effetti parte del prodotto software il quale viene poi collaudato per un eventuale rilascio.
Per ogni nuova funzionalità sviluppata ne è prevista la prototipazione, da effettuare prima dell’implementazione, al fine di verificare la mancanza di errori o problematiche, le quali porterebbero ad una reiterazione delle fasi di progettazione e realizzazione. In questo modo è possibile di volta in volta acquisire maggiore competenza riguardo al problema, riducendo i rischi successivi e le tempistiche globali di produzione software.
1.2.3 Modello incrementale in Sopra Steria
Nell’azienda lo sviluppo di ogni incremento inizia con gli analisti, che raccolgono e or- ganizzano i requisiti presso il cliente, il quale esprime le proprie necessità e aspettative.
Gli analisti suddividono poi questi requisiti in attività necessarie per il loro soddisfaci- mento. Con tutti i dati raccolti, gli analisti stilano i documenti di analisi dei requisiti e specifica tecnica, che verranno utilizzati dai team di sviluppo a cui sono stae assegnate le attività per svolgere tali attività e soddisfare i requisiti richiesti.
Terminata la stesura dei documenti, gli analisti hanno il compito di rimanere a disposizione dei team di sviluppo anche nelle fasi successive, in caso di chirimenti o specificazioni, al fine di non interrompere o rallentare la realizzazione del prodotto.
Tali gruppi di lavoro possono risultare distribuiti nelle varie sedi del territorio italiano, perciò sono previste molte comunicazioni telefoniche o tramite posta elettronica e occasionali trasferte; al fine di allineare le procedure di sviluppo o rendere noto quando è possibile procedere con determinate modifiche.
Lo stato di implementazione dei vari incrementi software segue le seguenti fasi:
∗ Sviluppo: dove avvengono le modifiche al software;
∗ Integrazione: le varie implementazioni al software vengono raccolte e unificate, verificando che non generino conflitti fra loro;
∗ Collaudo: viene testato il software per garantire che soddisfi le funzionalità richieste;
∗ Produzione: rappresenta lo stato finale del prodotto in cui viene effettivamente utilizzato dal cliente.
È compito del programmatore che ha effettuato un’implementazione dichiararne il completamento, anche se solo come prototipo, per poterne permettere l’integrazione.
1.3. CARATTERIZZAZIONE DEI CLIENTI 7 Determinati team hanno poi il compito di testare l’applicazione nelle sue nuove fun- zionalità, accertando il soddisfacimento dei requisiti ed eventualmente contattando gli analisti per eventuali modifiche progettuali. In caso di problematiche le modifiche vengono respinte in ambito di sviluppo altrimenti vengono approvate per il collaudo.
In collaudo è possibile utilizzare le funzioni sviluppate da altri team e validare il lavoro svolto per presentarlo poi al cliente, rilasciando in produzione la nuova versione del software.
1.3 Caratterizzazione dei clienti
I clienti di Sopra Steria, per quanto riguarda la divisione Industria & Servizi, sono principalmente società che necessitano di prodotti atti al miglioramento dei propri processi aziendali, al fine di migliorare la propria forza vendita. Queste società rientrano principalmente all’interno del settore Fashion & Luxury e le loro necessità variano da software utilizzati per la vendita a prodotti per uso interno.
1.4 Innovazione
Al fine di soddisfare al meglio le esigenze dei propri clienti, l’azienda è in continua ricerca di tecnologie e prodotti innovativi.
Questo viene reso possibile tramite la spinta verso lo sviluppo di progetti sperimentali e l’utilizzo delle ultime tecnologie disponibili. Infatti quest’anno ha avuto luogo la seconda edizione dell’ Innovation Awards, un bando interno all’azienda in cui i dipendenti possono presentare le proprie idee innovative per poter essere valutate.
Capitolo 2
Il Progetto
2.1 Interesse aziendale
Nonostante Sopra Steria sia un’azienda di grandi dimensioni e affermata in diversi settori, per perseguire l’innovazione si trova in costante espansione e rinnovamento.
Questa situazione è ancora più accentuata in Italia, e più in particolare all’inter- no del team Mobile, in quanto da poco creato. Non è strano quindi che esso sia alla ricerca di risorse da inserire al proprio interno. Per fare ciò ha attivato una convenzione con l’Università di Padova e partecipa quindi ad eventi come STAGE-IT[g]. Tramite iniziative di questo tipo per l’azienda è possibile offrire stage sia curriculari che retri- buiti, spesso a scopo di assunzione.
Lo svolgimento dello stage è quindi visto dall’azienda come un utile strumento per il riconoscimento di nuovi talenti e per verificare un possibile interesse per lo stagista verso la continuazione del rapporto lavorativo.
2.2 Descrizione del progetto
Utilizzando i progetti di stage, Sopra Steria mira all’esplorazione delle ultime novità nel campo delle innovazioni tecnologiche. In questo caso il progetto consiste nello sviluppo di un’applicazione mobile che utilizzi strumenti atti alla creazione di esperienze in realtà aumentata. Lo scopo del progetto è quello di poter posizionare modelli 3D di elettrodomestici all’interno del mondo reale, al fine di simulare il posizionamento del suo corrispondente reale. Il progetto richiede quindi la possibilità di posizionare oggetti virtuali all’ interno del mondo reale, tramite l’utilizzo di sensori e della fotocamera di uno smartphone. Il progetto pertanto risulta essere suddiviso in tre parti:
∗ studio delle tecnologie da utilizzare;
∗ sviluppo della parte legata al posizionamento del modello 3D all’interno del mondo reale (back-end);
∗ sviluppo di un’interfaccia utente per la selezione dei modelli 3D (front-end).
9
10 CAPITOLO 2. IL PROGETTO
2.3 Aspettative dell’azienda
Tramite lo svolgimento di questo progetto l’azienda si aspetta di ottenere una serie di risultati, anche al di fuori degli obiettivi pianificati nel piano di lavoro.
Prima di tutto, l’azienda è interessata all’utilizzo del progetto non solo come pro- dotto a sè stante, ma anche come una base da cui è possibile costruire e sviluppare futuri progetti legati al concetto della realtà aumentata.
In secondo luogo, l’azienda si aspetta, tramite lo svolgimento di questo progetto di effettuare formazione sulle tecnologie, strumenti, e metodologie di lavoro che il team Mobile utilizza, al fine di facilitare l’inserimento nel team.
2.4 Obiettivi del progetto
Al fine di verificare in modo quantificabile la conformità del progetto rispetto alle aspettative, io e il tutor aziendale, prima di iniziare lo stage, abbiamo compilato un Piano di Lavoro contenente una serie di obiettivi pianificati da completare durante lo svolgimento dello stage. Questi obiettivi sono suddivisi in obbligatori, desiderabili e facoltativi. Sono presenti nella tabella2.1.
Obiettivi obbligatori
Progettazione di un’architettura mobile Cross Platform
Realizzazione di codice per accesso alle funzionalità native dei dispositivi Realizzazione di UI per iOS e Android
Integrazione di plugin per Apache Cordova Pubblicazione sugli store iOS e Android Analisi e identificazione di bug su dispositivi Obiettivi desiderabili
Capacità di gestione autonoma dei singoli task Analisi costi/benefici dello sviluppo Cross Platform Obiettivi facoltativi
Progettazione di API REST per mobile app Valutazione e rispetto dei tempi su macro task Analisi di SDK native
Realizzazione di un plugin nativo
Tabella 2.1: Obiettivi definiti nel piano di lavoro
2.4. OBIETTIVI DEL PROGETTO 11 In figura2.1 vengono rappresentati gli obiettivi pianificati in base al loro numero suddivisi per tipologia. Sono presenti 6 obiettivi obbligatori, corrispondenti al 50%
del totale, insieme a 2 obiettivi desiderabili e 4 obiettivi facoltativi che coprono l’altro 50%.
Figura 2.1: Obiettivi pianificati, suddivisi per tipologia
12 CAPITOLO 2. IL PROGETTO
2.5 Vincoli
2.5.1 Vincoli temporali
L’Università di Padova ha imposto un limite per la durata delo stage, corrispondente ad una durata compresa tra le 300 e le 320 ore, distribuite all’interno di 8 settimane.
Pertanto lo stage si è svolto in questo periodo di tempo: è durato infatti 320 ore, dal 4 Settembre al 27 Ottobre. L’ orario settimanale consisteva in 8 ore al giorno dal lunedì al venerdì dalle 9 alle 18, con un’ora di pausa pranzo nel mezzo. All’interno del Piano di Lavoro. stilato dal tutor aziendale, sono state descritte le varie mansioni da svolgere, suddivise in base al numero di ore necessarie per il loro svolgimento. Queste mansioni possono essere riassunte secondo la seguente suddivisione:
∗ studio delle tecnologie da utilizzare;
∗ sviluppo di un prototipo al fine di consolidare al fine di consolidare le conoscenze acquisite;
∗ sviluppo dell’applicazione vera e propria.
2.5.2 Vincoli imposti dall’azienda
Il team Mobile, in cui sono stato inserito, sviluppa applicazioni mobile cross-platform tramite l’utilizzo di Apache Cordova. Questa metodologia però non era completamente utilizzabile per il progetto, in quanto le funzionalità per l’utilizzo della realtà aumentata erano presenti esclusivamente all’interno dei linguaggi nativi del dispositivi, ovvero ARKit per iOS e ARCore per Android. Inoltre quest’ultimo era stato giudicato dal team come non usabile, in quanto non abbastanza maturo. Pertanto per lo svolgimento del progetto mi sono stati posti i seguenti vincoli:
∗ sviluppo dell’applicazione per dispositivi iOS;
∗ utilizzo di ARKit per lo sviluppo del lato back-end, corrispondente alle funziona- lità legate alla realtà aumentata;
∗ utilizzo di Apache Cordova per lo sviluppo del lato front-end, corrispondente alla UI[g]; questo per poter riutilizzare in un futuro prossimo la stessa interfaccia per
dispositivi Android non appena ARCore raggiungerà la piena maturità.
2.6. TECNOLOGIE UTILIZZATE 13
2.6 Tecnologie utilizzate
2.6.1 Tecnologie principali
Apache Cordova
Figura 2.2: Logo di Apache Cordova
Apache Cordova[3](Figura 2.2)è un framework JavaScript[g]per lo sviluppo di appli- cazioni mobile. Uno dei suoi principali punti di forza è il suo essere cross-platform:
un’applicazione sviluppata utilizzando Cordova potrà essere usata sia su iOS che su Android. Altri suoi punti di forza sono:
∗ il suo utilizzo di HTML[g], CSS[g]e JavaScript per lo sviluppo, il quale rende la produzione di interfacce più semplice e intuitiva, semplificando l’adattamento alle diverse dimensioni dei vari dispositivi mobili, nonchè facilmente testabile, in quanto eventuali test sono possibili anche da browser;
∗ la possibilità di accedere a funzionalità native dei dispositivi mobili, come ad esempio dei sensori, tramite l’uso di plugin sviluppabili in caso di necessità o già esistenti grazie ad una matura community che offre continui contributi.
Cordova ha però una serie di svantaggi:
∗ rispetto ad un’applicazione equivalente sviluppata in linguaggio nativo, un’ap- plicazione sviluppata utilizzando Cordova risulterà sempre più lenta è avrà performance peggiori;
∗ non tutte le funzionalità presenti nei dispositivi sono attualmente utilizzabili all’interno di Cordova.
Il team Mobile utilizza questo framework per una serie di motivi: le necessità della loro clientela spesso richiedono lo sviluppo verso più piattaforme e le tipologie di richieste raramente richiedono capacità computazionale possibili solo con applicazioni native (come ad esempio un gioco); pertanto l’utilizzo di Cordova si rivela un’ottima scelta per le necessità aziendali.
14 CAPITOLO 2. IL PROGETTO All’interno del mio progetto ho utilizzato Cordova per la produzione del front-end dell’applicazione e per la produzione di un plugin che lo collegasse al back-end, il quale è stato sviluppato tramite linguaggio nativo.
ARKit
Figura 2.3: Logo di ARKit
ARKit[4](Figura2.3) è un framework Swift[g]sviluppato da Apple. Le sue principali funzionalità consistono nell’utilizzo di sensori atti a riconoscere l’ambiente circostante al fine di inserire oggetti virtuali al suo interno, creando quindi l’illusione che essi si trovino all’interno del mondo reale. I suoi principali punti di forza sono:
∗ per l’avvio non ha bisogno di conoscere nulla sull’ambiente circostante: tramite l’utilizzo della fotocamera e dei sensori di movimento del dispositivo ARKit è in grado di percepire informazioni sull’ambiente relativamente alla posizione del dispositivo, in tempo reale;
∗ il riconoscimento dell’ ambiente avviene tramite riconoscimento di superfici;
∗ il posizionamento di oggetti virtuali avviene tramite Hit Testing, ovvero il controllo del punto appartenente al mondo reale in cui l’oggetto andrebbe posizionato, per- mettendo quindi un posizionamento realistico, come se fosse veramente presente nel mondo reale;
∗ per il rendering di oggetti virtuali 3D è possibile usare un’altra libreria offerta da Apple, SceneKit, la quale semplifica di molto l’utilizzo degli oggetti virtuali.
2.6. TECNOLOGIE UTILIZZATE 15
2.6.2 Tecnologie di supporto
Backbone.js
Figura 2.4: Logo di Backbone.js
Backbone.js[5](Figura2.4)è un framework JavaScript per applicazioni Web. Il suo scopo principale è l’applicazione di una struttura minimale la quale separa i dati dall’interfaccia che li visualizza. Per svolgere questo compito vengono create le seguenti entità:
∗ Model: è la rappresentazione dei dati. Un model può essere modificato, validato, salvato in un server, ecc. ;
∗ View: rappresenta la parte grafica dell’applicazione e corrisponde all’interfaccia;
∗ Collection: per facilitare l’utilizzo di più Model, essi possono essere raggruppati all’interno di una Collection, la quale possiede funzionalità per facilitarne la gestione e l’iterazione;
∗ Event: aggiunge ad un oggetto la capacità di rispondere a determinati eventi;
per esempio l’aggiornamento di una View alla modifica di uno specifico Model.
Ognuna di queste entità possiede funzionalità che semplificano la gestione dei dati e delle interfacce collegate.
All’interno del progetto, Backbone.js è stato utilizzato insieme a Apache Cordova per la produzione del lato front-end dell’applicazione.
JQuery e Underscore.js
JQuery[6]e Undescore.js[7]sono librerie JavaScript di supporto per lo sviluppo di applicazioni web. Nonostante essi possiedano funzionalità diverse tra loro hanno lo stesso obiettivo: l’inserimento di funzionalità atte a semplificare e velocizzare l’utilizzo di JavaScript. Le funzionalità semplificate sono di diverso tipo: variano dalla gestione degli eventi all’utilizzo di animazioni, fino a metodi legati all’utilizzo di array.
SceneKit
SceneKit[8]è un’ API[g]di supporto sviluppata da Apple per Swift che permette la gestione, l’importazione e l’esportazione di contenuti 3D all’interno di un’applicazione.
Viene spesso utilizzata insieme ad ARKit.
16 CAPITOLO 2. IL PROGETTO
2.6.3 Strumenti utilizzati
Atom
Atom è un editor di testo che supporta diversi linguaggi di programmazione; è facilmente modificabile in base alle proprie esigenze grazie allo sviluppo di packages sviluppati dalla community contenenti diverse funzionalità.
Nel progetto è stato utilizzato per lo sviluppo del lato front-end dell’applicativo.
XCode
XCode è un IDE[g]utilizzato per lo sviluppo in linguaggio nativo per iOS e Mac.
All ’interno del progetto è stato utlizzato per lo sviluppo del back-end del prodotto.
Github e BitBucket
Github e BitBucket sono sistemi di versionamento utilizzati per la gestione del codice.
Capitolo 3
Lo stage
3.1 Analisi dei rischi
Per evitare lo svilupparsi di situazioni in grado di evolversi in possibili rallentamenti o problematiche, ad inizio stage è stata effettuata una breve analisi dei rischi. Tali rischi sono stati individuati e suddivisi in categorie definite dalla loro area di competenza.
Vengono inoltre brevemente descritte strategie che ne permettono la gestione e la mitigazione.
∗ livello tecnologico
– Tecnologie sconosciute: l’uso di tecnologie da me non o poco conosciute, potrebbe causare ritardi o difficoltà dovute alla mancanza di esperienza nell’utilizzo. Tale problematica è stata mitigata grazie alla pianificazione di un periodo di studio delle tecnologie ad inizio stage e grazie al supporto dato dai programmatori più espserti presenti in sede.
– Guasti hardware: durante lo svolgimento dello stage è possibile che il guasto di un dispositivo causi rallentamenti o perdita di lavoro. Per ovviare a ciò sono stati utilizzati sistemi di versionamento come Github e BitBucket.
∗ livello organizzativo
– Valutazione delle risorse: considerata la mia scarsa esperienza nello svolgimento di progetti, è possibile che un’errata valutazione delle risorse disponibili comporti un’errata stima della quantità di lavoro da svolgere, creando sprechi o ritardi. Per ovviare a ciò, sono avvenute su base sia settimanale che giornaliera revisioni assieme al tutor aziendale sul lavoro svolto al fine di stimare in modo corretto le risorse disponibili.
∗ livello dei requisiti
– Incomprensioni e scelte non ottimali: è possibile che alcuni requisiti non corrispondano alle aspettative dell’azienda, portando quindi a ritardi o allo sviluppo di un prodotto non consono all richieste effettuate. Pe risolvere questo problema avvengono su base sia settimanale che giornaliera revisioni assieme al tutor aziendale sul lavoro svolto al fine di verificare che i requisiti analizzati siano corretti.
17
18 CAPITOLO 3. LO STAGE
3.2 Analisi dei requisiti
3.2.1 Analisi del dominio applicativo e di soluzioni esistenti
Per individuare i vari requisiti corrispondenti alle diverse funzionalità del prodotto, è necessario effettuare un’analisi del suo dominio di appartenenza. Per effettuare tale analisi è necessario comprendere cosa si intende per realtà aumentata e capire il suo contesto d’utilizzo all’interno del progetto, confrontandolo anche con soluzioni già esistenti.
Realtà aumentata
Per realtà aumentata si intende, come anche il termine suggerisce, una qualsiasi visione della realtà con l’aggiunta di informazioni, spesso contenuti multimediali, aumentando quindi il livello di percezione della realtà di un utente.
Il metodo in cui ciò avviene è tramite la sovrapposizione di uno strato, corrispondente alle informazioni virtuali, (spesso immagini o oggetti 3D) all’ambiente circostante, ovvero il mondo reale.
Pertanto la sfida più grande non è l’inserimento di un oggetto virtuale all’interno del mondo reale, bensì il suo posizionamento al fine da farlo sembrare parte dell’ambiente, aggiungendogli quindi un certo grado di realismo.
Per ottenere questi risultati sono nate nel tempo diverse tecniche:
∗ Utilizzo di marcatori: questa tecnica utilizza marcatori presenti nel mondo reale, come ad esempio codici QR[g]. Tramite la la loro lettura è possibile effettuare diverse azioni tra cui il posizionamento di oggetti virtuali. Nonostante questa tecnica sia semplice e non richieda particolare potenza computazionale, essa richiede che siano presenti marcatori nell’ambiente per funzionare e per tanto non è utilizzabile in ogni situazione;
∗ Proiezione: questa tecnica consiste nel proiettare luci artificiali nell’ambiente.
L’interazione con esse avviene tramite tocchi i quali alterano la proiezione di luce;
∗ Sovrapposizione: questa tecnica consiste nel riconoscimento dell’ambiente circostante al fine di crearne una rappresentazione per poi aggiungerci tramite sovrapposizione un oggetto virtuale. Per fare ciò è quindi molto importante che questa tecnica sia in grado di riconoscere l’ambiente reale nel modo più dettagliato possibile al fine di posizionare l’oggetto virtuale nella scena creata e che inoltre possieda la potenza computazionale per effettuare tali operazioni.
Per lo svolgimento del progetto la tecnica più indicata risulta essere la terza, tecnica utilizzata daARKit, in quanto utilizzabile nella maggior parte degli ambienti e dalla maggior parte dei dispositivi che possiedano la capacità di calcolo necessaria per effettuare tali operazioni.
Il funzionamento di ARKit può essere descritto nei seguenti passaggi:
∗ all’avvio dell’applicazione, o della parte dell’applicazione che utilizza ARKit, viene creata una sessione per il riconoscimento dell’ambiente;
∗ tramite l’uso di sensori di movimento e la fotocamera di un dispositivo ARKit riconosce punti e superfici appartenenti all’ambiente circostante;
3.2. ANALISI DEI REQUISITI 19
∗ utilizzando queste informazioni e le differenze tra le immagini ottenute dalla fotocamera viene costruito un sistema di coordinate che riconosce la posizione e il movimento del dispositivo;
∗ utilizzando le superfici riconosciute è possibile posizionare contenuti virtuali all’interno del sistema di coordinate costruito.
Contesto d’utilizzo
Lo scopo di quest’applicazione è quello di poter confrontare modelli 3D appartenenti ad elettrodomestici con il mondo reale, al fine di simulare la loro presenza nell’ambiente.
Pertanto i principali utilizzatori sono utenti generici che desiderano poter utilizzare le seguenti funzionalità:
∗ possibilità di posizionare l’oggetto virtuale all’interno di uno spazio reale ricono- sciuto dall’applicazione;
∗ possibilità di spostare e ruotare l’oggetto virtuale;
∗ possibilità di selezionare tra diversi oggetti virtuali;
Tramite quest’analisi e quella appartenente al punto precedente, è stato individuato il principale flusso che l’applicazione deve seguire, insieme all’individuazione di diversi requisiti nonchè tecniche di posizionamento dell’oggetto virtuale.
Analisi di soluzioni esistenti
Alcune ore sono state dedicate all’analisi di applicazioni di terze parti presenti sul mercato appartenenti allo stesso dominio applicativo.
Particolare attenzione è stata posta alle tecniche utilizzate per descrivere all’utente le proprie funzionalità e le azioni da eseguire per usarle, al fine di aumentarne il grado di usabilità.
Quest’analisi ha portato all’inserimento delle seguenti funzionalità:
∗ visualizzazione di una serie di messaggi al primo avvio dell’applicazione atti a spiegare le varie funzionalità;
∗ inserimento di una schermata che ha lo scopo di spiegare la procedura da seguire per far riconoscere all’applicazione l’ambiente circostante;
∗ inserimento di messaggi d’errore che descrivano all’utente la presenza di particolari condizioni che impediscano all’applicazione il riconoscimento dell’ambiente.
3.2.2 Requisiti individuati
Grazie all’analisi del dominio applicativo, del contesto d’utilizzo e delle varie soluzio- ni esistenti, è stato possibile individuare le principali funzionalità che l’applicazione dovrà possedere. Partendo da queste è stata stilata la lista dei principali requisiti da soddisfare.
I requisiti, riportati nella seguente tabella, assumono la seguente forma:
Importanza Tipologia - Identificativo Descrizione Dove:
20 CAPITOLO 3. LO STAGE
∗ Importanza: denota il peso del requisito di riferimento e ne stabilisce una priorità. Assume i valori:
– O: Obbligatorio, il requisito deve essere soddisfatto per considerare il progetto completo;
– D: Desiderabile, se il requisito viene implementato porta valore aggiunto al progetto, ma non è strettamente necessario.
∗ Tipologia: indica la natura del requisito e assume i seguenti valori:
– F: Funzionale, rappresenta una funzionalità che il prodotto finale dovrà fornire, che sia essa espressa in forma generale a livello di sistema o espressa nel dettaglio delle componenti;
– V: Di vincolo, specifica un vincolo che il software deve rispettare;
∗ Identificativo: un numero, generato per incremento, che identifica il requisito in modo univoco se considerato assieme alla codifica della sua importanza e tipologia;
∗ Descrizione: una breve descrizione del requisito e dei suoi riferimenti.
Nella tabella3.1vengono riportati i requisiti principali individuati mentre in Figura 3.1è rappresentata la loro suddivisione per tipologia.
Codice identificativo Descrizione
OF-1 Riconoscimento di superfici nell’ambiente OF-2 Selezione di un oggetto 3D
OF-3 Posizionamento di un oggetto 3D
OF-4 Spostamento orizzontale di un oggetto 3D OF-5 Rotazione di un oggetto 3D
OF-6 Visualizzazione di messaggi d’aiuto che spieghino le funzioni dell’app OF-7 Visualizzazione di messaggi d’errori in caso di problemi di
riconoscimento dell’ambiente
OF-8 Visualizzazione di una schermata che spieghi come far riconoscere nuove superfici all’app
OF-9 Visualizzazione di messaggi d’aiuto che spieghino le funzioni dell’app OF-10 Visualizzazione lista oggetti 3D
OF-11 Visualizzazione lista colori oggetto 3D
OV-12 Sviluppo del front-end tramite Apache Cordova OV-13 Sviluppo del back-end tramite linguaggio nativo iOS OV-14 Ricezione dati appartenenti ai modelli 3D tramite JSON[g]
DF-15 Spostamento verticale di alcuni oggetti 3D
DF-16 Visualizzazione di effetti al riconoscimento di una superficie
DF-17 Scatto foto dell’oggetto 3D nell’ambiente con salvataggio e condivisione
Tabella 3.1: Requisiti principali individuati
3.3. PROGETTAZIONE E SVILUPPO 21
Figura 3.1: Requisiti individuati suddivisi per tipologia
3.3 Progettazione e sviluppo
La maggior parte delle ore designate per lo stage è stata dedicata alla progettazione e alla realizzazione di una soluzione atta a soddisfare i requisiti individuati.
Dal momento che non avevo una grande esperienza, nè con la tipologia del prodotto da sviluppare, nè con le tecnologie da utilizzare, ho sviluppato una serie di prototipi con lo scopo di testare le funzionalità richieste che sono stati utili ad aumentare la mia familiarità con le tecnologie utilizzate.
A causa di questo non è possibile, all’interno del mio progetto, considerare progettazione e codifica come due attività completamente distinte e separate fra loro, ma anzi si possono quasi considerare come un’unica fase che ha lo scopo di strutturare e inserire nel prodotto le funzionalità previste.
3.3.1 Architettura di un’applicazione iOS
Per capire al meglio la struttura dell’applicazione sviluppata, è necessario prima di tutto descrivere in modo generale la struttura di un’applicazione iOS.
Un’ applicazione iOS è formata da una serie di oggetti che interagiscono tra loro secondo il pattern Model-View-Controller.
22 CAPITOLO 3. LO STAGE
Figura 3.2: Struttura di un’applicazione iOS (Fonte: https://goo.gl/o4BLof) Utilizzando questo pattern si ha una netta separazione tra parte grafica (View), la logica dell’applicazione (Controller), e i dati utilizzati (Model). Questa distinzione non aiuta solo al disaccoppiamento dei componenti, rendendo lo sviluppo più semplice, ma permette inoltre di garantire un alto grado di manutenibilità del prodotto e facilita il riutilizzo dei componenti.
Questa struttura possiede i seguenti elementi principali (vedi Figura3.2):
∗ UIApplication: il principale oggetto di un’applicazione, che si occupa di ricevere eventi e di inoltrarli agli oggetti che si occupano della loro gestione;
∗ App delegate: esegue operazioni delegate da UIApplication, facendo in modo che l’applicazione interagisca con il sistema o altre applicazioni correttamente.
Alcuni dei suoi ruoli sono la gestione del cambiamento di stato dell’applicazione all’interno del proprio ciclo di vita, l’inizializzazione dell’applicazione, e la risposta ad eventuali notifiche;
∗ View Controller: questa tipologia di oggetto ha la funzione di gestire la rappre- sentazione grafica dell’applicazione; si occupa infatti di rispondere all’interazione dell’utente con le View, aggiornarle, e gestire il loro layout;
∗ UIWindow: questo oggetto coordina la rappresentazione grafica, collaborando con View Controller. Corrisponde alla finestra principale dell’applicazione.
3.3. PROGETTAZIONE E SVILUPPO 23 Oltre a questi oggetti base è possibile aggiungere una serie di View o oggetti come pulsanti o campi di testo, al fine di arricchire l’interfaccia grafica e offrire all’utente diversi metodi di interazione con l’applicazione.
3.3.2 Architettura di un’applicazione sviluppata con Apache Cordova
All’interno dei linguaggi nativi utilizzati per lo sviluppo di applicazioni mobile, esiste un componente denominato WebView.
Come si evince dal nome una WebView è una particolare tipologia di View utilizzabile per la rappresentazione di contenuti Web, permettendo quindi la lettura di contenuti scritti utilizzando HTML, CSS e JavaScript.
Utilizzando la WebView è pertanto possibile sviluppare un’applicazione (o una sua parte) tramite linguaggi per il Web. Apache Cordova utilizza infatti questo metodo (vedi Figura 3.3).
Figura 3.3: Struttura di un’applicazione sviluppata tramite Apache Cordova (Fonte: https:
//cordova.apache.org/docs/en/latest/guide/overview/)
Cordova permette lo sviluppo di un’interfaccia tramite l’utilizzo di linguaggi per la creazione di siti web. Se l’applicazione richiede l’utilizzo di particolari funzionalità native del dispositivo ( come ad esempio sensori, speciali librerie per la grafica, accesso ai contatti o alle informazioni sulla batteria) o una parte dell’applicazione è stata sviluppata in nativo, è possibile utilizzare i Plugin per effettuare un collegamento tra le due parti.
24 CAPITOLO 3. LO STAGE Un plugin non è altro che codice JavaScript che permette l’accesso a funzionalità native, e se necessario restituisce risposte sotto forma di funzioni di callback. Ad ogni plugin sono associate diverse API native, tante quante sono le piattaforme supportate, le quali eseguono le operazioni la cui richiesta è stata inoltrata dal plugin. Pertanto un plugin nasconde le funzionalità native di un dispositivo dietro del codice JavaScript.
Cordova offre una serie di plugin di base, corrispondenti alle principali funzionalità di un dispositivo (ad esempio GPS, camera, contatti, batteria). È possibile cercare altri plugin sviluppati dalla community o svilupparne uno proprio.
3.3.3 Architettura del progetto
La struttura dell’applicazione segue il pattern definito per tutte le applicazioni iOS, ovvero il pattern Model-View-Controller. Questa struttura è inoltre suddivisa in una parte Front-end sviluppata tramite Apache Cordova, e un lato Back-end sviluppato tramite linguaggio nativo. La comunicazione tra queste due avviene tramite il plugin sviluppato con Cordova chiamato arkit.js, il quale inoltra eventi e richieste ricevute dal lato Front-end verso il Back-end.
Front-end
Il Front-end dell’applicazione, corrispondente alla sua rappresentazione grafica, è for- mato da un’insieme di componenti che ho sviluppato usando Apache Cordova.
I componenti principali sono descritti in seguito.
ARKitPage.js
Questo componente corrisponde alla schermata principale dell’applicazione (vedi Figura 3.4)
Figura 3.4: Schermata principale dell’applicazione Essa esegue le seguenti funzionalità:
3.3. PROGETTAZIONE E SVILUPPO 25
∗ cattura gli eventi necessari al posizionamento, la rotazione e lo spostamento di un oggetto virtuale, per poi propagarli al Back-end tramite il plugin arkit.js;
∗ permette l’apertura del menù per la selezione di altri oggetti virtuali;
∗ permette lo scatto di foto;
∗ visualizza errori legati a problemi di riconoscimento delle superfici;
∗ visualizza una schermata d’aiuto al primo avvio dell’applicazione.
ARKitProductsModalView.js
Questo componente è una finestra modale usata per la selezione di un prodotto avente un modello 3D virtuale. Una finestra modale è una finestra utilizzata per inter- rompere l’interazione con la finestra "padre" (in questo caso la schermata principale ARKitPage.js) per richiedere lei stessa l’interazione con l’utente. La selezione di un prodotto avviene in tre passaggi:
∗ selezione della categoria del prodotto;
∗ selezione del prodotto desiderato;
∗ selezione del colore del prodotto.
Al termine di questa procedura la schermata di ARKitProductsModalView.js si chiuderà, tornando quindi a quella principale, e comparirà il modello 3D associato al prodotto e al colore scelto. Inoltre questa finestra modale possiede le seguenti funzionalità:
∗ permette il riposizionamento di un oggetto virtuale già posizionato;
∗ permette le selezione rapida di un colore per un oggetto virtuale già posizionato, evitando quindi la ripetizione della procedura in tre passaggi.
ARKitProductsModalView.js è formato da tre diversi componenti corrispondenti ai tre diversi passaggi da effettuare per la selezione del prodotto:
∗ ARKitCategoriesPage.js: pagina contenente le categorie dei prodotti (vedi Figura 3.5);
∗ ARKitProductsListPage.js: pagina contenente la lista di prodotti appartenenti alla categoria scelta (vedi Figura3.6);
∗ ARKitColorsListPage.js: pagina contenente la lista dei colori appartenenti al prodotto scelto precedentemente (vedi Figura3.7).
26 CAPITOLO 3. LO STAGE
Figura 3.5: Selezione di una categoria di prodotti
Figura 3.6: Selezione di un prodotto dalla lista
3.3. PROGETTAZIONE E SVILUPPO 27
Figura 3.7: Selezione del colore del prodotto
28 CAPITOLO 3. LO STAGE
ARKitScreenshotModalView.js
Questo componenente è una finestra modale che ha lo scopo di visualizzare una foto appena scattata. Da qui è possibile condividere la foto o salvarla (vedi Figura3.8).
Queste ultime funzionalità descritte sono state sviluppate utilizzando un plugin creato dalla community.
Figura 3.8: Visualizzazione di una foto appena scattata
ARKitController.js
Questo componente è un controller che ha lo scopo di creare il Viewstack dell’applica- zione ed esegue le operazioni che permettono l’avvio dell’applicazione.
Un Viewstack (vedi Figura3.9)non è altro che il luogo il cui vengono inserite le View dell’applicazione secondo una struttura a strati: quando una View diventa visibile a causa di qualche operazione o interazione dell’utente essa viene spostata verso l’alto, nello strato superiore, e tutte le altre vengono spinte verso uno strato inferiore.
Questo approccio permette uno scambio rapido tra le finestre dell’applicazione, senza dovere aspettare operazioni come la creazione di una View.
3.3. PROGETTAZIONE E SVILUPPO 29
Figura 3.9: Esempio di Viewstack (Fonte:https://github.com/vash15/backbone.
viewstack)
Back-end
Il Back-end dell’applicazione, sviluppato tramite linguaggio nativo, si occupa di ef- fettuare tutte le funzionalità legate alla realtà aumentata e all’utilizzo di un oggetto virtuale, come il suo posizionamento, spostamento o rotazione. Esso riceve informazioni ed eventi come l’interazione di un utente dal Front-end tramite il plugin sviluppato con Apache Cordova arkit.js. Il Back-end è formato da una serie di componenti che ho sviluppato i quali utilizzano funzionalità offerte da ARKit legate al riconoscimento dell’ambiente.
I suoi componenti principali sono descritti in seguito.
ARKitViewController.swift
Questa classe è un View Controller (vedi3.3.1). Le sue funzionalità principali sono le seguenti:
∗ inizializzazione dei componenti necessari all’utilizzo della realtà aumentata;
∗ ricezione di eventi e informazioni inoltrati dal plugin arkit.js;
∗ propagazione degli eventi verso le classi che effettivamente eseguono le operazioni legate agli eventi;
∗ creazione della sessione di ARKit utilizzata per il riconoscimento dell’ambiente;
∗ ogni volta che ARKit trova una nuova superficie, questa classe ne riceve la notifica e la propaga verso le classi che possono utilizzare quest’informazione;
∗ effettua lo screenshot della scena, creandone l’immagine per poi inviarla al Front- end tramite il plugin come stringa Base64[g]per poter essere poi utilizzata dal componente ARKitScreenshotModalView.js.
30 CAPITOLO 3. LO STAGE Un’altra funzionalità importante che questa classe possiede è la visualizzazione della scena contenente l’oggetto virtuale. Infatti dato che il Back-end viene completamente nascosto dal Front-end tramite l’utilizzo del plugin, al fine di visualizzare la scena di realtà aumentata rappresentata dal feed della camera e l’oggetto virtuale posizionato nell’ambiente, essa viene inserita all’interno di una View "figlia" della WebView (vedi 3.3.2). Pertanto il risultato ottenuto consiste nella scena di realtà aumentata sovrappo- sta a ARKitPage.js, come si può anche vedere in Figura3.4.
VirtualObject.swift
Questa classe rappresenta un’istanza di un oggetto virtuale. Essa possiede le seguenti funzionalità:
∗ effettua il caricamento del modello 3D in base alle informazioni ricevute da ARKitViewController.swift ;
∗ effettua il posizionamento e spostamento dell’oggetto virtuale sia in base all’in- terazione dell’utente, sia in base allo spostamento su superfici riconosciute da ARKit, nel caso in cui esse siano abbastanza grandi da contenere l’oggetto;
∗ effettua la rotazione dell’oggetto virtuale;
∗ effettua l’eliminazione dell’oggetto virtuale su richiesta dell’utente o al termine di una sessione di utilizzo dell’applicazione.
Gesture.swift
Questa classe viene chiamata da ARKitViewController.swift alla ricezione di eventi legati al movimento dell’oggetto virtuale, generati da tocchi effettuati dall’utente sullo schermo del dispositivo.
Quanto il Front-end riconosce dei tocchi sullo schermo, esso percepisce le coordinate, espresse tramite i pixel con cui è stata effettuata l’interazione, e il numero di tocchi avvenuti contemporaneamente. Esistono i seguenti tipi di eventi legati al tocco:
∗ touchstart : corrisponde all’inizio di un tocco, ovvero quando viene toccato lo schermo;
∗ touchend : corrisponde alla fine di un tocco, ovvero quando l’utente ha smesso di toccare lo schermo;
∗ touchmove: corrisponde al movimento di un dito sullo schermo senza averlo mai rilasciato;
∗ touchcancel : viene chiamato quando un tocco è stato interrotto. A differenza di touchend, che segna la fine di un tocco e quindi la fine di un’evento, touchcancel ne segna l’interruzione, la quale potrebbe portare ad ignorare l’evento di tocco.
In base al tipo di evento chiamato e alle sue informazioni, ricevute tramite ARKit- ViewController.swift, questa classe si occupa di riconoscere l’operazione da effettuare (spostamento o rotazione) e di convertire le coordinate dell’evento in un sistema di coordinate a tre dimensioni utilizzabile sull’oggetto virtuale, per poi chiamare i metodi di VirtualObject.swift per effettuare l’operazione vera e propria.
Utilities.swift
3.4. VALIDAZIONE 31
Classe che contiene una serie di metodi di diverso tipo utilizzati da tutte le clas- si del Back-end. La separazione di questi metodi dal resto del codice ne facilita il riuso e la manutenibilità.
3.4 Validazione
Durante la svolgimento del progetto, specialmente durante lo sviluppo, è stato prestato un certo grado di attenzione verso l’attività di testing delle funzionalità dell’applicazione, allo scopo di verificarne la correttezza e l’usabilità.
Diverse possibili funzionalità sono state infatti scartate o semplificate in fase di sviluppo in quanto definite troppo complicate o difficilmente intuibili ed utilizzabili da un utente.
Tramite questa attività di validazione del prodotto, sono state individuate diverse situazioni anomale ed errori generati dal software, portando alla correzione del codice che ne è stata la causa e in alcuni casi al refactoring[g]del codice al fine di migliorarne la leggibilità e manutenibilità.
3.4.1 Test effettuati
Al termine del processo di sviluppo si è proceduto a verificare che le funzionalità dell’applicazione corrispondessero ai requisiti individuati, e che le funzionalità fossero usabili dal punto di vista di un utente generico.
Pertanto io, assieme al tutor aziendale e anche altri membri dell’azienda, abbiamo testato ogni parte dell’applicativo, per verificare non solo la conformità del prodotto, ma anche la mancanza di problematiche o situazioni impreviste.
In particolare è stato prestato un certo livello di attenzione verso la transizione di stati all’interno del ciclo di vita dell’applicazione (Figura3.10). È stato infatti verificato che in qualsiasi momento in cui l’applicazione fosse stata in uso, un’azione qualsiasi con lo scopo di modificare lo stato dell’applicazione (come ad esempio il tornare in Home) non causasse anomalie al sistema di riconoscimento dell’ambiente.
Inoltre il prodotto è stato testato per verificare il suo funzionamento nelle seguenti situazioni limite:
∗ impossibilità di riconoscimento dell’ambiente circostante;
∗ mancanza di informazioni legate all’oggetto virtuale;
∗ tentativo di posizionamento dell’oggetto virtuale oltre la distanza massima riconosciuta;
∗ comportamento dell’oggetto virtuale in mancanza di superfici.
Tramite queste situazioni si è voluto testare il comportamento dell’applicazione, per verificare che non solo il flusso di esecuzione non fosse interrotto, ma anche che tali situazioni fossero gestite correttamente.
Questi test hanno messo in luce le diverse problematiche e casi che il prodotto non era pronto a gestire, permettendo una risoluzione rapida delle anomalie riscontrate.
Al termine di questa fase le funzionalità sviluppate sono state completamente accertate e riconosciute come implementazioni dei requisiti individuati.
32 CAPITOLO 3. LO STAGE Inoltre, per facilitare la futura manutenzione del prodotto, nonchè possibili estensioni o utilizzi, il codice è stato associato ad una serie di commenti e descrizione atti a descrivere al meglio il funzionamento di ogni classe. In particolare è stato descritto:
∗ lo scopo che ogni classe nel progetto possiede;
∗ l’utilizzo di ogni variabile;
∗ il funzionamento dei vari metodi, descritto più in dettaglio nel caso di metodi più complessi;
∗ l’interazione fra i vari metodi, in relazione al flusso di esecuzione dell’applicazione.
Figura 3.10: Ciclo di vita di un’applicazione iOS (Fonte:https://goo.gl/bCcqq6)
Capitolo 4
Conclusioni
Lo scopo di questo stage consisteva nella creazione di un’applicazione legata alla realtà aumentata. Tramite l’utilizzo di tecnologie per il riconoscimento dell’ambiente, que- st’applicazione permette l’inserimento di oggetti virtuali all’interno di questo ambiente.
Al fine definire al meglio le funzionalità che il prodotto deve avere, è stato studiato sia il suo dominio applicativo che il suo contesto d’utilizzo, e sono state confrontate diverse soluzioni alternative già presenti sul mercato.
Il primo passo verso lo sviluppo è stato lo studio delle tecnologie da utilizzare: come esercitazioni sono state inoltre sviluppati alcuni piccolo programmi.
Il passo successivo è stato la progettazione e lo sviluppo della vera e propria applica- zione: l’architettura creata è stata condizionata sia dalle tecnologie utilizzate (Apache Cordova e ARKit) sia dalle tecniche architetturali tipiche di un’applicativo per disposi- tivi mobili.
Terminata l’architettura delle classi, è stato necessario definire i metodi atti a svolgere le varie funzionalità che l’applicazione deve svolgere, incapsulandoli all’interno della struttura definita in precedenza.
Al termine di questo è stato necessario effettuare la validazione di quanto fatto. Per- tanto io e il tutor aziendale abbiamo effettuato dei test di sistema atti a verificare la conformità del prodotto e la mancanza di errori o situazioni anomale al suo interno, al fine di garantire che il software sia pronto all’utilizzo.
4.1 Soddisfacimento dei requisiti
Al termine del periodo corrispondente alla validazione del prodotto è stato possibile implementare la totalità dei requisiti obbligatori definiti, e la maggior parte dei requisiti desiderabili. È stato quindi creato un prodotto che rispecchia i requisiti individuati con l’attività di Analisi dei requisiti.
33
34 CAPITOLO 4. CONCLUSIONI
4.2 Soddisfacimento degli obiettivi pianificati
All’interno del Piano di lavoro è stata definita una serie di obiettivi da completare per garantire la conformità del progetto alle aspettative di completamento.
In Tabella4.1è possibile vedere la lista degli obiettivi raggiunti nel corso dello stage.
Obiettivi obbligatori Esito
Progettazione di un’architettura mobile Cross Platform Completato Realizzazione di codice per accesso alle funzionalità native dei dispositivi Completato
Realizzazione di UI per iOS e Android Completato
Integrazione di plugin per Apache Cordova Completato
Pubblicazione sugli store iOS e Android Completato
Analisi e identificazione di bug su dispositivi Completato
Obiettivi desiderabili Esito
Capacità di gestione autonoma dei singoli task Completato
Analisi costi/benefici dello sviluppo Cross Platform Completato
Obiettivi facoltativi Esito
Progettazione di API REST per mobile app Non completato
Valutazione e rispetto dei tempi su macro task Completato
Analisi di SDK native Completato
Realizzazione di un plugin nativo Completato
Tabella 4.1: Obiettivi raggiunti durante lo svolgimento dello stage
Si nota quindi che la maggior parte degli obiettivi è stata completata.
In particolare l’obiettivo obbligatorio legato alla pubblicazione sugli store è stato effettuato su un’applicazione non appartenente al progetto da me svolto, ma è stato comunque ritenuto completato dal tutor aziendale.
Inoltre l’obiettivo facoltativo legato alla progettazione di API REST, non è stato completato in quanto valutato dal cliente e dal tutor aziendale come una possibile estensione futura in quanto non era attualmente possibile svilupparla, a causa della mancanza di un’architettura adatta a sostenerla.
4.3 Esperienza di stage
Questo stage è stato, nel complesso, un’esperienza positiva. Il progetto è stato svolto all’interno di un ambiente di lavoro confortevole e tranquillo, permettendomi di com- pletare gli obiettivi definiti senza la minima distrazione.
Per tutta la durata del progetto ho potuto godere di un certo grado di autonomia che mi ha permesso di sperimentare diversi approcci per lo sviluppo delle funzionalità del prodotto, nonchè di guadagnare esperienza dal punto di vista gestionale ed organizza- tivo.
Il tutor aziendale mi ha sempre seguito ed aiutato, soprattutto durante i periodi di
4.4. SVILUPPI FUTURI 35 progettazione e di validazione del prodotto. Inoltre durante i momenti di maggiore difficoltà è stato molto utile rapportarsi con gli altri membri del team. Questo ha permesso un maggiore supporto che ha portato ad una più semplice risoluzione di problematiche in corso di progettazione e sviluppo.
Inoltre l’organizzazione del lavoro è stata gestita tramite revisioni di avanzamento sia settimanali che giornaliere, le quali verificavano l’avanzamento del progetto e permette- vano una revisione in tempo reale degli obiettivi previsti nonchè un miglioramento del prodotto in corso di sviluppo.
Personalmente la sfida più difficile del progetto è stata l’utilizzo di tecnologie per la realtà aumentata e la manipolazione di modelli 3D, in quanto si trattava di un ambito completamente nuovo per me.
Interessante è stata le gestione organizzativa del progetto: il contesto lavorativo di un’azienda è molto diverso dall’ambito universitario, sia per obiettivi che per meto- dologie utilizzate; la possibilità di fare esperienza sotto questo aspetto sarà di certo molto importante in futuro.
Inoltre la produzione di un software funzionale e completo, che ha rimesso più volte in discussione strategie di codifica e strutturali ha dato a me grande soddisfazione.
4.4 Sviluppi futuri
Il prodotto sviluppato, nonostante sia completo da un punto di vista puramente funzionale, si presta a possibili miglioramenti in futuro.
L’organizzazione strutturale del prodotto permette l’aggiunta di funzionalità senza modificare la struttura presente, grazie all’incapsulamento dei metodi e modularità dei componenti.
La tecnologia principale per la realtà aumentata utilizzata, ARKit potrebbe ricevere aggiornamenti e nuove funzionalità in futuro: sarebbe pertanto possibile aggiungere queste nuove funzionalità all’interno dell’applicazione.
Inoltre la tecnologia corrente utilizzabile per dispositivi Android, ARCore, non è ancora abbastanza matura da poter essere utilizzata: non appena sarà disponibile una versione stabile, sarà possibile definire un Back-end che la utilizza da agganciare al Front-end attuale, il quale è stato appositamente sviluppato secondo metodologia cross-platform tramite Apache Cordova.
Un altro possibile sviluppo futuro consiste nella possibilità di ricevere oggetti virtuali da un’altra sede tramite la definizione di un’API REST.
4.5 Conoscenze acquisite
Questa esperienza di stage mi ha permesso di conoscere la realtà aziendale, il cui il lavoro si svolge sotto forma di ritmi ben definiti, e di conseguenza migliorare la mia capacità di gestione organizzativa.
Ho potuto inoltre arricchire le mie conoscenze tecniche: l’approfondimento di metodi per sviluppare applicazioni mobile, unito allo sviluppo tramite tecniche al di fuori delle mie conoscenze, come l’utilizzo di modelli 3D, mi ha permesso di espandere i miei orizzonti e il mio bagaglio di conoscenze, nonchè aumentare le mie competenze all’interno del settore.
Glossario
API
Un’API (Application Programming Interface) è un insieme di procedure, spesso raggruppate per funzionalità, utili ad un programmatore per svol- gere determinati compiti.
Base64
Metodo di codifica per la conversione di dati binari, come ad esempio file multimediali, in stringhe di testo al fine da facilitarne lo spostamento e la memorizzazione all’interno di strutture dati.
Codice QR
Un codice QR è uno speciale tipo di codice a barre in grado di contenere informazioni, normalmente leggibili tramite l’utilizzo di un dispositivo mobile.
CSS
Linguaggio usato per definire la rappresentazione grafica di una pagina web.
HTML
Linguaggio di markup utilizzato per la scrittura della parte logica di una pagina web.
IDE
Un IDE (Integrated Development Environment) è un software che offre ad un programmatore diverse funzionalità atte allo sviluppo di codice.
JavaScript
Linguaggio di scripting orientato agli oggetti utilizzato per la programma- zione web.
JSON
JSON, acronimo di JavaScript Object Notation, è un formato utilizzato
37
38 GLOSSARIO
per lo scambio di dati, soprattutto all’interno di architetture client-server.
Refactoring
Tecnica utlizzata per modificare il codice di un software, senza modificarne caratteristiche funzionali, con lo scopo di migliorare proprietà del codice come manutenibilità, leggibilità e grado di riuso.
STAGE-IT
Evento realizzato da Confindustria Padova il cui scopo è l’incontro tra aziende che desiderano presentare progetti di stage e studenti interessati a svolgerli mediante colloqui individuali.
Swift
Linguaggio di programmazione orientato agli oggetti sviluppato da Apple, per sistemi operativi Apple.
UI
Un’UI (User Interface) rappresenta la parte di un software visibile all’uten-
te, e che viene quindi utilizzata per accedere alle funzionalità del prodotto.
Bibliografia
[1] - Sopra Steria Group, URL: http://www.soprasteria.it/IlGruppo [2] - Essential Project Management, Jean Paul Deberdt. Fonte derivata da intranet aziendale
[3]- Apache Cordova. URL: https://cordova.apache.org/
[4] - ARKit. URL:https://developer.apple.com/arkit/
[5] - Backbone.js. URL:http://backbonejs.org/
[6] - JQuery. URL:https://jquery.com/
[7] - Underscore.js. URL:http://underscorejs.org/
[8] - SceneKit. URL:https://developer.apple.com/documentation/
scenekit
39
