Sviluppo di un'applicazione mobile sulla realtà aumentata

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

Laureando

Riccardo Alessandro Saggese Compri

Anno Accademico 2018-2019

Riccardo Alessandro Saggese Compri: Sviluppo di un’applicazione mobile sulla realtàaumentata, Tesi di Laurea triennale, c© 26 Febbraio 2019.

Indice

1 L’azienda 31.1 Profilo Aziendale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Prodotti e servizi offerti . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2.1 Prodotti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2.2 Servizi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Processi aziendali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3.1 Organizzazione interna . . . . . . . . . . . . . . . . . . . . . . 51.3.2 Modello di sviluppo . . . . . . . . . . . . . . . . . . . . . . . 71.3.3 Il modello incrementale in Sopra Steria . . . . . . . . . . . . . 8

1.4 Caratterizzazione dei clienti . . . . . . . . . . . . . . . . . . . . . . . 9

2 Il Progetto 112.1 Interesse aziendale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2 Descrizione del progetto . . . . . . . . . . . . . . . . . . . . . . . . . 112.3 Aspettative dell’azienda . . . . . . . . . . . . . . . . . . . . . . . . . 132.4 Obiettivi del progetto . . . . . . . . . . . . . . . . . . . . . . . . . . 142.5 Vincoli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.5.1 Vincoli temporali . . . . . . . . . . . . . . . . . . . . . . . . . 162.5.2 Vincoli imposti dall’azienda . . . . . . . . . . . . . . . . . . . 17

2.6 Il mio stage in Sopra Steria . . . . . . . . . . . . . . . . . . . . . . . 172.7 Tecnologie utilizzate . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.7.1 Tecnologie principali . . . . . . . . . . . . . . . . . . . . . . . 182.7.2 Tecnologie di supporto . . . . . . . . . . . . . . . . . . . . . . 222.7.3 Strumenti utilizzati . . . . . . . . . . . . . . . . . . . . . . . . 24

3 Lo stage 273.1 Analisi dei rischi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.1.1 Rischi Tecnologici . . . . . . . . . . . . . . . . . . . . . . . . 273.1.2 Rischi organizzativi . . . . . . . . . . . . . . . . . . . . . . . . 283.1.3 Rischi sui Requisiti . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2 Analisi dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2.1 Analisi del dominio applicativo e di soluzioni esistenti . . . . 293.2.2 Requisiti individuati . . . . . . . . . . . . . . . . . . . . . . . 31

3.3 Progettazione e sviluppo . . . . . . . . . . . . . . . . . . . . . . . . . 333.3.1 Architettura di un’applicazione Android . . . . . . . . . . . . 343.3.2 Architettura di un’applicazione sviluppata con Apache Cordova 373.3.3 Architettura del progetto . . . . . . . . . . . . . . . . . . . . 39

iii

iv INDICE

3.4 Validazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.4.1 Test effettuati . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4 Valutazione retrospettiva 514.1 Conoscenze preliminari . . . . . . . . . . . . . . . . . . . . . . . . . . 514.2 Soddisfacimento degli obiettivi . . . . . . . . . . . . . . . . . . . . . 524.3 Esperienza di stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.4 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.5 Bilancio formativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Glossario 55

Bibliografia 59

Elenco delle figure

1.1 Logo di Sopra Steria Group S.p.A . . . . . . . . . . . . . . . . . . . . 31.2 Diagramma della business line di Sopra Steria . . . . . . . . . . . . . 41.3 Distribuzione nel mercato di Sopra Steria . . . . . . . . . . . . . . . 61.4 Diagramma del modello di sviluppo incrementale . . . . . . . . . . . 71.5 Diagramma della distribuzione globale di Sopra Steria . . . . . . . . 9

2.1 Le fasi del progetto di stage . . . . . . . . . . . . . . . . . . . . . . . 132.2 Obiettivi pianificati, suddivisi per tipologia . . . . . . . . . . . . . . 152.3 Suddivisione ore per mansione . . . . . . . . . . . . . . . . . . . . . . 162.4 Logo di Apache Cordova . . . . . . . . . . . . . . . . . . . . . . . . . 182.5 Logo di ARCore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.6 Logo di Sceneform SDK . . . . . . . . . . . . . . . . . . . . . . . . . 202.7 Plug-in per importare le risorse in Android Studio . . . . . . . . . . 212.8 Logo di Backbone.js . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.9 Logo di jQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.10 Logo di Underscore.js . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.11 Logo di Android Studio . . . . . . . . . . . . . . . . . . . . . . . . . 242.12 Logo di Atom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.13 Logo di BitBucket . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.1 Requisiti individuati suddivisi per tipologia . . . . . . . . . . . . . . 333.2 Struttura di un’app Android . . . . . . . . . . . . . . . . . . . . . . . 343.3 Struttura di un’applicazione sviluppata tramite Apache Cordova . . 373.4 HomePage dell’applicazione demo . . . . . . . . . . . . . . . . . . . . 403.5 Esempio di Viewstack . . . . . . . . . . . . . . . . . . . . . . . . . . 413.6 Schermata di avvio di ARPage . . . . . . . . . . . . . . . . . . . . . 423.7 Posizionamento dell’oggetto . . . . . . . . . . . . . . . . . . . . . . . 433.8 Schermata app in modalità "Screenshot" . . . . . . . . . . . . . . . . 443.9 Schermata app in modalità "Lift" . . . . . . . . . . . . . . . . . . . . 453.10 Schermata app con l’oggetto posizionato . . . . . . . . . . . . . . . . 46

v

vi ELENCO DELLE TABELLE

Elenco delle tabelle

2.1 Obiettivi definiti nel piano di lavoro . . . . . . . . . . . . . . . . . . 14

3.1 Requisiti individuati . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.1 Obiettivi raggiunti durante lo stage . . . . . . . . . . . . . . . . . . . 52

ELENCO DELLE TABELLE 1

Capitolo 1

L’azienda

1.1 Profilo Aziendale

Sopra Steria Group S.p.A. è uno dei leader europei nell’ambito della trasformazionedigitale proponendo una delle offerte più complete di servizi di Consulting, SystemIntegration e Business Process Services presenti ad oggi sul mercato e operando indiversi mercati quali Fashion, Banking, Energy, Aeronautica, Settore pubblico, Difesae Trasporti.

Figura 1.1: Logo di Sopra Steria Group S.p.A

Sopra Steria è partner di riferimento delle principali aziende ed organizzazionipubbliche e private, proponendo progetti di trasformazione digitale che puntanoad un’alta qualità dei servizi erogati, valore aggiunto e innovazione. Conta 41.000collaboratori in più di 20 paesi con un fatturato nel 2017 di 3,8 miliardi di euro edopera sul territorio italiano con oltre 850 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 aziendefrancesi Sopra Group SA and Groupe Steria SCA, comunemente chiamate Soprae Steria, fondate rispettivamente nel 1968 e 1969. Ad oggi l’azienda si presentainternamente ben strutturata in Business Unit[g]relative agli ambiti di sviluppo eadotta una politica di recruiting che mira alla competenza dei dipendenti da cuideriva 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 "Mobile developer" e sono stato affiancato, per l’intera

3

4 CAPITOLO 1. L’AZIENDA

durata dello stage, dal mio tutor aziendale Matteo Baggio che ricopre il ruolo di"Senior mobile developer".

1.2 Prodotti e servizi offerti

1.2.1 Prodotti

Sopra steria offre un’offerta globale accompagnando il cliente durante tutto il ciclodi vita della "Mobile experience" tenendo in considerazione tutte le sfide che essaracchiude: innovazione, strategia, design, integrazione di sistemi, progettazione,sviluppo, implementazione, manutenzione e supervisione di applicazioni.Restando sempre all’avanguardia con le tecnologie più attuali e innovative (Augmen-ted reality, image recognition...), Sopra steria integra tutte le innovazioni derivantidalla mobilità nella nostra vita quotidiana per:

• Offrire una user experience rinnovata

• Ottimizzare i processi di lavoro in mobilità

• Una gestione mobile degli interventi on-field: geolocalizzazione, strumenti dianalisi mobile, accesso ai sistemi di riferimento aziendali in loco

1.2.2 Servizi

Il sistema di gestione per la qualità dei servizi offerti ai clienti di Sopra Steria Groupè certificato ISO 9001:2008 ed è annualmente sottoposto a verifiche da parte di unente accreditato di terza parte.

Figura 1.2: Diagramma della business line di Sopra Steria

1.3. PROCESSI AZIENDALI 5

I principali servizi servizi offerti dalla divisione per l’ambito mobile sono:

• Redesign dei processi per valorizzare le capacità interattive dei nuovi device

• Digitalizzazione avanzata

• Integrazione di mobile e sistema informativo: architettura, sincronizzazione...

• Frammentazione dei terminali mobile

• Modello App Store aziendale

• Piattaforma di test mobile

1.3 Processi aziendali

1.3.1 Organizzazione interna

Le grosse dimensioni dell’azienda comportano un grande livello di attenzione verso lapropria organizzazione interna e gli elementi alla base di essa. Durante il mio stageho avuto modo di osservare alcuni aspetti di questo complesso sistema.

Uno degli aspetti molto importanti per l’azienda è la cura dei rapporti con ilcliente: vengono infatti offerte numerose sessioni di consulenza. Aiutare il cliente acapire di cosa ha bisogno, permette all’azienda di offrire soluzioni sempre più vicinealle sue necessità infatti, la filosofia, è quella di collaborare per aiutarli a trasformarei loro sistemi informativi e, grazie all’esperienza del settore, offrire valore aggiuntomediante le soluzioni.Per raggiungere tale scopo il gruppo ha stretto delle partnership strategiche conMicrosoft, IBM, Oracle e HP. La missione principale del gruppo è di industrializzaree ottimizzare le proprie operazioni per migliorare la competitività e le performancein un’ottica a lungo termine.

Un altro aspetto a cui l’azienda tiene in particolar modo è la gestione delle risorseumane; per l’azienda infatti sostenerne lo sviluppo e l’evoluzione è considerato unapriorità per il successo aziendale in quanto aggiunge un vantaggio competitivo eaiuta 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 ciascuncollaboratore, e di valutare per ognuno di essi prospettive di crescita e percorsi dicarriera in grado di soddisfare sia le loro aspettative che il mercato.


Figura 1.3: Distribuzione nel mercato di Sopra Steria

Riguardo al governo e alla gestione del gruppo, i diversi livelli di poteri decisionali,sia a livello funzionale che produttivo, sono distribuiti sia in base alle responsabilitàtramite struttura gerarchica, che per la direzione, in base alle diversità dei singoliruoli previsti. Questa organizzazione complessa viene costruita in base alle varienazioni in cui l’azienda si estende, delegando l’amministrazione di questi filoni e dialtri reparti di supporto a manager selezionati.A livello più basso si collocano le Business Unit, ovvero le varie divisioni aziendaliadibite all’erogazione di determinate tipologie di prodotti e servizi identificate anchein base al mercato di riferimento.Anche queste ultime risultano distribuite nel territorio, in ogni filiale infatti possonocoesistere più reparti.

All’interno della divisione in cui sono stato collocato, sono presenti diverse figureche si occupano dei vari processi produttivi. In ordine gerarchico è presente undirettore di Business Unit per l’amministrazione delle risorse della divisione, i projectmanager per la gestione dei progetti e dei loro costi, i commerciali che si occupanodelle relazioni con i clienti in ambito di redazione dei contratti, i team di analisti econsulenti che si occupano dei requisiti del cliente e i team di sviluppo software.L’azienda adotta un sistema di qualità anche per i suoi funzionamenti interni, inparticolare è applicato per:

• Gestire i processi di prevendita e sviluppo di progetti e servizi;

• Gestire le risorse umane nel campo di reclutamento, carriera, gestione dellecompetenze, formazione interna e comunicazioni interne;

• Gestire e monitorare i processi aziendali, garantendo una manutenzione interna.

Sopra Steria si fa carico inoltre delle responsabilità d’impresa negli ambiti di unosviluppo sostenibile, cura dell’ambiente, diritti umani e del lavoro e nel favorire leuguali opportunità. La pubblicazione del rapporto di tali attività fa parte di unprocesso di trasparenza, correttezza e dialogo con gli stakeholder [g]: collaboratori,clienti, azionisti, fornitori, partner e attori della società civile.

1.3. PROCESSI AZIENDALI 7

1.3.2 Modello di sviluppo

Il ciclo di sviluppo software adottato dal team Mobile è un’implementazione delmodello incrementale. È stato scelto in quanto facilita la produzione di prototipi, lerelazioni con il cliente e l’aggiunta di nuove funzionalità a progetti già avviati.

I punti di forza del modello incrementale sono:

• L’integrazione delle parti del sistema è distribuita nel tempo e non collassatanelle fasi finali;

• Ogni incremento porta l’aggiunta di nuove funzionalità e permette di soddisfarealcuni requisiti;

• Ad ogni incremento si guadagnano esperienza e affidabilità, riducendo i rischidi fallimento;

• Le funzionalità essenziali sono sviluppate nei primi incrementi e attraversanopiù fasi di verifica, diventano quindi più stabili con ciascuna iterazione;

Questo modello si presta bene alle necessità aziendali in quanto spesso i clientirichiedono lo sviluppo di funzionalità aggiuntive definibili dal modello come singoliincrementi, o che richiedano lo sviluppo di prototipi a cui in futuro verranno inseritiincrementi.

Figura 1.4: Diagramma del modello di sviluppo incrementale

Il modello incrementale è un ciclo di sviluppo definito dallo standard ISO 12207che combina la logica del modello a cascata, dove ogni fase è rigidamente sequenziale,e la filosofia iterativa della prototipazione.

Questo modello attraversa una fase iniziale di analisi dei requisiti e progettazionearchitetturale intesa a stabilire le fondamenta del software. Tale fase è essenziale perdefinire i successivi incrementi e non si ripete.

Successivamente vengono sviluppati i veri e propri incrementi, i quali possonoripetersi più volte e mirano ad attività di progettazione di dettaglio, codifica e prove,


in cui vengono trattati prima i requisiti essenziali e poi quelli desiderabili.Al termine di tutto l’incremento viene implementato, diventato a tutti gli effettiparte del prodotto software il quale viene poi collaudato per un eventuale rilascio.

È prevista la prototipazione delle nuove funzionalità che si vanno ad implementareper la validazione complessiva del sistema, reiterando alle fasi di progettazione erealizzazione in caso di errori o problematiche. In questo modo è possibile di voltain volta acquisire maggiore competenza riguardo al problema, riducendo i rischisuccessivi e le tempistiche globali di produzione software.

1.3.3 Il modello incrementale in Sopra Steria

Ogni ciclo di incremento inizia con la raccolta e l’analisi dei requisiti presso il cliente,il quale esprime le proprie necessità e aspettative tramite riunioni oppure medianteopportuna documentazione.

Gli analisti a questo punto si occupano di raggruppare i requisiti in macro attività,calcolare le tempistiche necessarie per il loro completamento e stilare i documenti dianalisi funzionale e specifica tecnica per ognuna di esse, dov’è compresa la progetta-zione di dettaglio. Gli analisti rimangono a disposizione degli sviluppatori anche nellefasi successive per eventuali chiarimenti e specificazioni, in modo da non rallentare ointerrompere le fasi successive.

I documenti prodotti verranno inviati ed utilizzati dai team di sviluppo a cui sonostate assegnate le attività per svolgere tali attività e per soddisfare i requisiti richiesti.Tali gruppi di lavoro possono risultare distribuiti nelle varie sedi del territorio italiano,perciò sono previste molte comunicazioni telefoniche o tramite posta elettronica eoccasionali trasferte; al fine di allineare le procedure di sviluppo o rendere notoquando è possibile procedere con determinate modifiche.

L’evoluzione degli incrementi software attraversa ambienti distinti in base allemansioni svolte su di essi.Esistono in particolare i seguenti ambienti:

• Sviluppo: ambiente di programmazione locale, qui avviene l’implementazionedelle modifiche software;

• Integrazione: in questo ambiente vengono raccolte le implementazioni delleattività e si verifica che non generino conflitti, garantendo la stabilità delsistema;

• Collaudo: ambiente di validazione delle funzionalità complessive del software,utilizzato anche per dimostrare al cliente la loro consistenza;

• Produzione: questo ambiente varia per ogni cliente o applicazione sviluppatae rappresenta lo stato finale del prodotto in cui viene effettivamente utilizzatodal cliente.

1.4. CARATTERIZZAZIONE DEI CLIENTI 9

È compito del programmatore che ha effettuato un’implementazione dichiararne ilcompletamento, anche se solo come prototipo, per poterne permettere l’integrazione.Determinati team si occupano poi di testare l’applicazione nelle sue nuove funzioni,accertando il soddisfacimento dei requisiti ed eventualmente contattando gli analistiper eventuali modifiche progettuali. In caso di problematiche le modifiche vengonorespinte in ambito di sviluppo altrimenti vengono approvate per il collaudo.In collaudo è possibile utilizzare le funzioni sviluppate da altri team e validare illavoro svolto per presentarlo poi al cliente, rilasciando in produzione la nuova versionedel software.

1.4 Caratterizzazione dei clienti

I clienti di Sopra Steria, per quanto riguarda la divisione Industria & Servizi, sonoprincipalmente società che necessitano di prodotti atti al miglioramento dei propriprocessi aziendali, al fine di migliorare la propria forza vendita. Queste societàrientrano principalmente all’interno del settori Fashion & Luxury e Retail. Le loronecessità variano da software utilizzati per la vendita a prodotti per uso interno(e-commerce).

Figura 1.5: Diagramma della distribuzione globale di Sopra Steria

Sopra Steria ha saputo confermarsi partner ideale per la realizzazione di progetti disuccesso. Grazie alla sua consolidata esperienza su complessi processi e-commerce, inparticolare in ambito fashion and luxury, supporta il cliente in ogni fase progettuale,dalla raccolta dei requisiti alla definizione e realizzazione della soluzione garantendouna migliore gestione dei processi e-commerce del cliente, supportandolo nelle decisionirelative alle logiche di business, oltre che nella definizione delle soluzioni tecniche.

Capitolo 2

Il Progetto

2.1 Interesse aziendale

Sopra Steria Group S.p.A. è un’azienda ben strutturata e affermata in molti setto-ri, nonostante conti diversi anni alle sue spalle è in costante espansione e rinnovazione.

Questa situazione è ancora più accentuata in Italia, per questo l’area personaleè sempre alla ricerca di nuove risorse da inserire nelle diverse Business Unit e inparticolare all’interno del team Mobile, in quanto da poco creato.Non mi ha stupito quindi il fatto che abbia attivato una convenzione con l’Universitàdi Padova e partecipi agli eventi STAGE-IT[g]per accogliere iniziative di stage siacurricolare che retribuito.

Lo svolgimento dello stage è quindi visto dall’azienda come un utile strumento peril riconoscimento di nuovi talenti e per verificare un possibile interesse per lo stagistaverso la continuazione del rapporto lavorativo. Per questo motivo la politica aziendaleprevede una decorrenza di sei mesi per completare il ciclo di stage e, solo dopo questoperiodo, la nuova risorsa può essere considerata pronta per essere effettivamenteinserita nei team di sviluppo.

2.2 Descrizione del progetto

Il corso di studi rende obbligatorio lo svolgimento di uno stage che deve ricoprireun ammontare di 300-320 ore totali. È stato dunque stabilito, insieme al mio tutoraziendale, che il lavoro di stage dovesse svolgersi in 300 ore nell’arco di 8 settimane:i tempi di consegna delle funzionalità relative al progetto richiesti dall’aziendasuperavano la data prevista di fine stage, ciò ha permesso che lo svolgimento delprogetto non subisse ulteriori vincoli temporali.

11

12 CAPITOLO 2. IL PROGETTO

Essendo, come detto in precedenza, in continua ricerca sulle innovazioni tecnologiche,Sopra Steria, utilizzando i progetti di stage, mira all’esplorazione delle ultime novitàin questo campo. In questo caso il progetto consiste nello sviluppo di un’applicazionemobile che utilizzi strumenti atti alla creazione di nuove esperienze attraverso l’usodella realtà aumentata.

Per realtà aumentata si intende l’arricchimento della percezione sensoriale umanamediante informazioni, in genere manipolate e convogliate elettronicamente, che nonsarebbero percepibili con i cinque sensi.Gli elementi che "aumentano" la realtà possono essere aggiunti attraverso un di-spositivo mobile, come uno smartphone, con l’uso di un PC dotato di webcam oaltri sensori, con dispositivi di visione o di ascolto che aggiungono informazionimultimediali alla realtà già normalmente percepita.

Esistono quindi generalmente due tipi di realtà aumentata:

• Su dispositivo mobile: Il dispositivo deve essere dotato necessariamente diGPS, di magnetometro (bussola) e deve poter permettere la visualizzazionedi un flusso video in tempo reale, oltre che di un collegamento Internet perricevere i dati online.

• Su PC: È basata sull’uso di marcatori, (ARtags), di disegni stilizzati in bianco enero che vengono mostrati alla webcam, vengono riconosciuti dal computer, e aiquali vengono sovrapposti in tempo reale i contenuti multimediali. Normalmentele applicazioni di realtà aumentata sono basate su tecnologia Adobe Flash.

Lo scopo del progetto è quello di sviluppare un plugin che possa essere integrato conl’applicazione di Unieuro, già creata e mantenuta da Sopra Steria, ma che sia ancheun biglietto da visita per l’acquisizione di nuovi progetti nel futuro.Per questo motivo, anche se lo sviluppo è stato incentrato sulla produzione dellefunzionalità specifiche per l’app di Unieuro, si è cercato di produrre del codicemantenibile e adattabile ad implementazioni future su altre applicazioni.Non è una novità infatti, per il team Mobile della quale ho fatto parte, quella disviluppare una serie di plugin per Apache Cordova che contengano delle funzionalitàben definite e che possano essere integrate ad hoc nelle varie applicazioni in base allerichieste del cliente.In questo caso specifico, l’applicazione aveva come obiettivo quello di posizionaremodelli 3D (elettrodomestici di vario tipo) all’interno dell’ambiente in cui ci si trova,simulando il posizionamento del loro corrispondente oggetto reale.

Il progetto pertanto risulta essere suddiviso in tre parti:

• studio delle tecnologie e degli strumenti da utilizzare;

• sviluppo della parte legata al posizionamento del modello 3D all’interno delmondo reale (back-end[g]);

• sviluppo di un’interfaccia utente per la selezione dei modelli 3D, posizionamentoe altre funzionalità (front-end[g]).

2.3. ASPETTATIVE DELL’AZIENDA 13

Le funzionalità specifiche richieste da implementare nell’attuale app di Unieuroerano quelle riguardanti il posizionamento degli elettrodomestici acquistabili pressoi negozi della catena. L’obiettivo era quello di permettere al cliente di guardare emuovere il prodotto scelto all’interno della stanza in cui sarebbe poi stato posizionato.

Questo oggetto doveva potersi muovere e ruotare sulla superficie dei piani rilevatidall’applicazione e potersi elevare rispetto ad essi, simulando un eventuale posiziona-mento "a muro" del prodotto (per esempio un televisore).

La creazione del plugin è stata suddivisa nello sviluppo delle funzionalità (back-end) e dell’interfaccia grafica utilizzabile dall’utente (front-end). L’obiettivo eraquello di sviluppare un applicazione cross-platfom e, per queste due parti, sono statimessi degli "obiettivi vincolanti" nel loro sviluppo:

• Per la parte nativa (back-end) il vincolo era quello di svilupparla tramite illinguaggio nativo delle app Android, quindi in Java.

• Per la parte front-end invece lo sviluppo è stato vincolato all’utilizzo di ApacheCordova.

La modalità di apprendimento prevista dall’azienda è stata di tipo "training onthe job", di conseguenza solo dopo una prima fase di formazione sulle tecnologie eduna di esercitazione secondo i metodi aziendali di sviluppo sono passato allo sviluppovero e proprio, sotto la supervisione del mio tutor aziendale.

Figura 2.1: Le fasi del progetto di stage

2.3 Aspettative dell’azienda

Tramite lo svolgimento di questo progetto l’azienda si aspetta di ottenere una seriedi risultati, anche al di fuori degli obiettivi pianificati nel piano di lavoro.

Prima di tutto, l’azienda è interessata all’utilizzo del progetto non solo comeprodotto a sè stante, ma anche come una base da cui è possibile costruire e svilupparefuturi progetti legati al concetto della realtà aumentata.


In secondo luogo, l’azienda si aspetta, tramite lo svolgimento di questo progettodi effettuare formazione sulle tecnologie, strumenti, e metodologie di lavoro che ilteam Mobile utilizza, al fine di facilitare l’inserimento nel team.

Per quanto riguarda le funzionalità del prodotto, l’azienda si aspetta una appli-cazione mobile per Android che consenta di posizionare modelli 3D in un ambientedi realtà aumentata utilizzando le librerie Google ARCore. L’applicazione dovràinoltre tenere conto dei piani come pavimento e tavoli dove posizionare e spostare glioggetti. Verrà fatta particolare attenzione al rispetto delle misure reali dell’oggettoe al fotorealismo della presentazione attraverso tecniche di illuminazione e texturemapping.

2.4 Obiettivi del progetto

Al fine di verificare in modo quantificabile la conformità del progetto rispetto alleaspettative, io e il tutor aziendale, prima di iniziare lo stage, abbiamo compilato unPiano di Lavoro contenente una serie di obiettivi pianificati da completare durantelo svolgimento dello stage.Questi obiettivi sono suddivisi in obbligatori, desiderabili e facoltativi e sono presentinella seguente tabella:

Obiettivi Obbligatori

Progettazione di una applicazione di realtà aumentata con ARCore

Realizzazione di codice per accesso alle funzionalità native dei dispositivi

Realizzazione di UI in modalità cross platform con HTML5 e CSS

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

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 15

In figura 2.2 vengono rappresentati gli obiettivi pianificati in base al loro numerosuddivisi per tipologia. Sono presenti 4 obiettivi obbligatori corrispondenti al 45%del totale, 2 per gli obiettivi desiderabili (22%) e 3 per quelli facoltativi (33%).

Figura 2.2: Obiettivi pianificati, suddivisi per tipologia


2.5 Vincoli

2.5.1 Vincoli temporali

Come detto in precedenza l’Università di Padova ha imposto un limite per la duratadello stage, corrispondente ad una durata compresa tra le 300 e le 320 ore distribuiteall’interno di 8 settimane. Pertanto lo stage si è svolto in questo periodo di tempo: èdurato infatti 300 ore, dal 20 Settembre al 20 Novembre.L’ orario settimanale consisteva in 8 ore al giorno dal lunedì al venerdì dalle 9 alle18, con un’ora di pausa pranzo nel mezzo. All’interno del Piano di Lavoro, stilatodal tutor aziendale, sono state descritte le varie mansioni da svolgere, suddivise inbase al numero di ore necessarie per il loro svolgimento.

Figura 2.3: Suddivisione ore per mansione

2.6. IL MIO STAGE IN SOPRA STERIA 17

2.5.2 Vincoli imposti dall’azienda

Il team Mobile, in cui sono stato inserito, sviluppa applicazioni mobile cross-platformtramite l’utilizzo di Apache Cordova. Questa metodologia però non era completa-mente utilizzabile per il progetto, in quanto le funzionalità per l’utilizzo della realtàaumentata erano presenti esclusivamente all’interno dei linguaggi nativi del dispositivitramite l’uso di SDK come ARKit per iOS e ARCore per Android. Pertanto, per losvolgimento del progetto, mi sono stati imposti i seguenti vincoli:

• Sviluppo dell’applicazione per dispositivi Android

• utilizzo di ARCore per lo sviluppo lato back-end, corrispondente alle funziona-lità legate alla realtà aumentata

• Utilizzo di Apache Cordova per lo sviluppo del lato front-end, corrispondentealla UI

2.6 Il mio stage in Sopra Steria

Partecipando all’evento STAGE-IT per due anni consecutivi (2017-2018) ho avutomodo di conoscere molte aziende operanti nel settore e quali tipi di offerte lavorativeoffrisse il mercato. La mia prima partecipazione nel 2017 ha permesso di presentarmia quella del 2018 con le idee più chiare rispetto a quello che il mondo del lavoro potesseoffrirmi. Personalmente sono sempre stato affascinato dal mondo della programmazio-ne mobile e ho partecipato a questi eventi nella speranza di trovare un’offerta di stagein questo ambito. In entrambe le edizioni ho avuto l’opportunità di partecipare aimini-colloqui organizzati all’evento da Sopra Steria in quanto, fin da subito, ho prova-to interesse per una realtà cosi grande e per i vari servizi che questa offre ai suoi clienti.

L’azienda, per la sede di Padova, ha a disposizione solo due posti per attivare untirocinio. Questi, in base al momento, vengono assegnati alla Business Unit che nenecessita maggiormente. In un primo momento l’azienda mi ha offerto di parteciparead un colloquio proponendo uno stage improntato sulla programmazione web inambito bancario. Dopo aver conosciuto il mio interesse nell’ambito della programma-zione mobile però ho avuto la fortuna di partecipare ad un secondo colloquio peruno stage in questo ambito.

In questo periodo ho avuto modo di partecipare ad altri colloqui e ricevere offerteda altre aziende ma, considerando l’interesse per il tirocinio proposto e l’importantecrescita che l’azienda ha avuto in Italia negli ultimi anni, la mia decisione è ricadutanella proposta di Sopra Steria.


2.7 Tecnologie utilizzate

2.7.1 Tecnologie principali

Apache Cordova

Figura 2.4: Logo di Apache Cordova

Apache Cordova è un framework JavaScript per lo sviluppo di applicazioni mobile.Uno dei suoi principali punti di forza è il suo essere cross-platform: un’applicazionesviluppata utilizzando Cordova potrà essere usata sia su iOS che su Android.Apache Cordova permette ai programmatori di creare applicazioni mobili usandoCSS3[g], HTML[g]e Javascript[g]invece di affidarsi ad API specifiche delle piattaformeAndroid, iOS o Windows Phone. Il framework incapsula poi il codice CSS, HTML eJavaScript generato all’interno delle predette piattaforme.

I suoi punti di forza sono:

• Utilizzo di HTML, CSS e JavaScript per lo sviluppo, il quale rende la produzionedi interfacce più semplice e intuitiva, semplificando l’adattamento alle diversedimensioni dei vari dispositivi mobili, nonché facilmente testabile, in quantoeventuali test sono possibili anche da browser;

• La possibilità di accedere a funzionalità native dei dispositivi mobili, come adesempio dei sensori, tramite l’uso di plugin[g]sviluppabili in caso di necessità ogià esistenti grazie ad una matura community che offre continui contributi.

Cordova ha quindi molti vantaggi nello sviluppo di applicazioni cross-platform [g]peròha anche alcuni svantaggi:

• Rispetto ad un’applicazione equivalente sviluppata in linguaggio nativo, un’ap-plicazione sviluppata utilizzando Cordova risulterà sempre più lenta e avràperformance peggiori;

• Non sempre tutte le funzionalità presenti nei dispositivi sono attualmenteutilizzabili all’interno di Cordova.

2.7. TECNOLOGIE UTILIZZATE 19

Il team Mobile utilizza questo framework [g]per una serie di motivi: le necessitàdella loro clientela spesso richiedono lo sviluppo verso più piattaforme e le tipologie dirichieste raramente richiedono capacità computazionale possibili solo con applicazioninative (come ad esempio un gioco). Pertanto l’utilizzo di Cordova si rivela un’ottimascelta per le necessità aziendali.

Al’interno del mio progetto Apache Cordova è stato utilizzato per creazione delfront-end dell’applicazione e per la produzione di un plugin che si collega al back-endscritto in linguaggio nativo.

ARCore

Figura 2.5: Logo di ARCore

ARCore è la piattaforma di Google per la creazione di esperienze di realtà aumentata.Utilizzando diverse API[g], ARCore consente al telefono di rilevare il suo ambiente,comprendere il mondo e interagire con le informazioni. Alcune delle API sono dispo-nibili su Android e iOS per consentire esperienze AR condivise.

ARCore utilizza tre funzionalità chiave per integrare il contenuto virtuale con ilmondo reale visto attraverso la fotocamera del telefono:

• Il rilevamento del movimento consente al telefono di capire e tracciare la suaposizione rispetto al mondo.

• La comprensione ambientale consente al telefono di rilevare la dimensione e laposizione di tutti i tipi di superfici: superfici orizzontali, verticali e angolatecome il terreno, un tavolino o pareti.

• La stima della luce consente al telefono di stimare le attuali condizioni diilluminazione dell’ambiente.

Fondamentalmente ARCore fa due cose: monitora la posizione del dispositivo mobilementre si muove, e costruisce la propria comprensione del mondo reale.


La tecnologia di tracciamento del movimento di ARCore utilizza la fotocamera deltelefono per identificare i punti interessanti e tiene traccia di come questi punti sispostano nel tempo. Con una combinazione del movimento di questi punti e delleletture dai sensori inerziali del telefono, ARCore determina sia la posizione chel’orientamento del telefono mentre si muove attraverso lo spazio.

ARCore può rilevare superfici piane, come un tavolo o il pavimento, e può anchestimare l’illuminazione media nell’area circostante. ARCore può rilevare superficipiane, come un tavolo o il pavimento, e può anche stimare l’illuminazione medianell’area circostante. Il rilevamento del movimento significa che puoi muoverti evedere questi oggetti da qualsiasi angolazione.

ARCore è in continuo aggiornamento da parte di Google e dall’aggiornamentoalla versione 1.2 sono state implementate molte funzionalità tra cui la possibilità diessere utilizzato anche per lo

Sceneform SDK

Figura 2.6: Logo di Sceneform SDK

Insieme ad ARCore ho utilizzato anche Sceneform SDK[g]per il rendering della scena3D. Sceneform rende semplice il rendering di scene 3D realistiche nelle app AR enon AR, senza dover utilizzare il più complesso OpenGL.

Questa SDK include:

• Un API grafico di alto livello;

• Un renderizzatore "physically based" ;

• Un plug-in per Android Studio per l’importazione, la visualizzazione e lacreazione di risorse 3D.


Figura 2.7: Plug-in per importare le risorse in Android Studio

Un altro punto a favore di Sceneform è che fornisce delle definizioni di materialipredefinite per consentire agli sviluppatori di ottenere risultati eccezionali con i lorooggetti 3D. Gli sviluppatori che desiderano personalizzare profondamente il modo incui appaiono i propri asset possono creare le proprie definizioni materiali e applicarlealle risorse.


2.7.2 Tecnologie di supporto

Backbone.js

Figura 2.8: Logo di Backbone.js

Backbone.js è un framework JavaScript per applicazioni Web. Il suo scopo principaleè l’applicazione di una struttura minimale la quale separa i dati dall’interfaccia cheli 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’interfac-cia;

• Collection: per facilitare l’utilizzo di più Model, essi possono essere raggrup-pati all’interno di una Collection, la quale possiede funzionalità per facilitarnela 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 edelle interfacce collegate.All’interno del progetto, Backbone.js è stato utilizzato insieme a Apache Cordovaper la produzione del lato front-end dell’applicazione.


jQuery

Figura 2.9: Logo di jQuery

jQuery è una libreria JavaScript per applicazioni web. Nasce con l’obiettivo disemplificare la selezione, la manipolazione, la gestione degli eventi e l’animazione dielementi DOM in pagine HTML, nonché implementare funzionalità AJAX.Le sue caratteristiche permettono agli sviluppatori JavaScript di astrarre le interazionia basso livello tra interazione e animazione dei contenuti delle pagine.Il framework fornisce metodi e funzioni per gestire al meglio aspetti grafici e strutturalicome posizione di elementi, effetto di click su immagini e altre manipolazioni delDOM. È un software libero, distribuito sotto i termini della Licenza MIT.Attualmente jQuery risulta la libreria JavaScript più utilizzata su Internet.

Underscore.js

Figura 2.10: Logo di Underscore.js

Underscore.js è una libreria che offre un gran numero di funzionalità create peraiutare gli sviluppatori JavaScript senza la necessità di estendere gli oggetti built-indi questo linguaggio. Funziona sia con jQuery che con Backbone. L’interesse diUnderscore.js non è tanto quello di modificare l’approccio allo sviluppo in JavaScript,ma piuttosto quello di aiutare nei compiti più ripetitivi che si possono incontraredurante il nostro lavoro.Questa libreria contiene oltre 80 funzioni per la manipolazione di Array, Oggetti eCollezioni che consentono di risparmiare moltissime righe di codice per eseguire delleoperazioni ripetitive.


2.7.3 Strumenti utilizzati

Android Studio

Figura 2.11: Logo di Android Studio

Android Studio è un ambiente di sviluppo integrato (IDE[g]) basato sul software diJetBrains IntelliJ IDEA e progettato specificamente per lo sviluppo di applicazioniAndroid. È disponibile il download su Windows, Mac OS X e Linux e sostituisce gliAndroid Development Tools (ADT) di Eclipse, diventando l’IDE primario di Googleper lo sviluppo nativo di applicazioni Android.Nel mio progetto è stato utilizzato per lo sviluppo della parte in nativo.


Atom

Figura 2.12: Logo di Atom

Atom è un editor di testo e IDE open source e sviluppato da GitHub, rilasciatonel 2014. La maggior parte dei pacchetti che lo compongono fanno uso di licenzesoftware open source. Ciò consente alla comunità di partecipare attivamente al suosviluppo.Una delle sue caratteristiche principali è la possibilità di sviluppare pacchetti utiliz-zando Node.js. Atom possiede inoltre supporto al sistema di controllo di versioneGit.Nel mio progetto è stato utilizzato per lo sviluppo dell’interfaccia.

BitBucket

Figura 2.13: Logo di BitBucket

Bitbucket è un servizio di hosting web-based per progetti che usano i sistemi dicontrollo versione Mercurial o Git. È simile a GitHub, il quale usa principalmenteGit. Insieme a GitHub è stato il sistema di versionamento scelto per il progetto.

Capitolo 3

Lo stage

3.1 Analisi dei rischi

Durante la fase di analisi iniziale sono stati individuati alcuni possibili rischi a cuisi potrà andare incontro. Si è quindi proceduto a elaborare delle possibili soluzioniper far fronte a tali rischi. Tali rischi sono stati individuati e suddivisi in categoriedefinite dalla loro area di competenza:

• Rischi Tecnologici;

• Rischi Organizzativi;

3.1.1 Rischi Tecnologici

1. Tecnologie adottate

Descrizione: L’utilizzo di tecnologie da me poco conosciute potrebbe causare ritardinello svolgimento del progetto.Soluzione: È stato pianificato un periodo iniziale di studio delle tecnologie a mesconosciute.

2. Guasti Hardware

Descrizione: Durante lo svolgimento dello stage è possibile che il guasto di undispositivo causi rallentamenti o perdita di lavoro.Soluzione: Per evitare la perdita di dati sono stati utilizzati i sistemi di versiona-mento GitHub e Bitbucket.

27

28 CAPITOLO 3. LO STAGE

3.1.2 Rischi organizzativi

3. Pianificazione Errata

Descrizione: Considerata la mia scarsa esperienza nella gestione di un progettoè possibile un errore di valutazione sulla stima della quantità di lavoro causandorallentamenti e ritardi nello svolgimento del progetto.Soluzione: Sono state pianificate delle revisioni giornaliere assieme al tutor aziendalesul lavoro svolto al fine di stimare in modo corretto le risorse disponibili.

3.1.3 Rischi sui Requisiti

4. Incomprensioni dei requisiti

Descrizione: È possibile che alcuni requisiti vengano male interpretati e/o noncorrispondano alle aspettative dell’azienda portando quindi a ritardi o allo sviluppodi un prodotto non consono alle richieste effettuate.Soluzione: Sono state pianificate delle revisioni giornaliere (o settimanali) assiemeal tutor aziendale sul lavoro svolto al fine di verificare che i requisiti analizzati sianocorretti.

3.2. ANALISI DEI REQUISITI 29

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 taleanalisi è necessario comprendere cosa si intende per realtà aumentata e capire il suocontesto 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 qualsiasivisione della realtà con l’aggiunta di informazioni (es. contenuti multimediali) au-mentando quindi il livello di percezione della realtà di un utente.Il metodo in cui ciò avviene è tramite la sovrapposizione di uno strato, corrispondentealle informazioni virtuali, (spesso immagini o oggetti 3D) all’ambiente circostante,ovvero il mondo reale. Pertanto la difficoltà più grande non è l’inserimento di unoggetto virtuale all’interno del mondo reale, bensì il suo posizionamento al fine dafarlo sembrare parte dell’ambiente, aggiungendogli quindi un certo grado di realismo.

Per ottenere questi risultati sono nate varie tecniche nel tempo:

• Utilizzo di marcatori: questa tecnica utilizza marcatori presenti nel mondoreale. Tramite la loro lettura è possibile effettuare diverse azioni tra cui ilposizionamento di oggetti virtuali. Nonostante questa tecnica sia semplicee non richieda particolare potenza computazionale, essa richiede che sianopresenti marcatori nell’ambiente per funzionare e per tanto non è utilizzabilein ogni situazione;

• Proiezione: questa tecnica consiste nel proiettare luci artificiali nell’ambiente.L’interazione con esse avviene tramite tocchi i quali alterano la proiezione diluce;

• Sovrapposizione: questa tecnica consiste nel riconoscimento dell’ambientecircostante al fine di crearne una rappresentazione per poi aggiungerci tramitesovrapposizione un oggetto virtuale. Per fare ciò è quindi molto importanteche questa tecnica sia in grado di riconoscere l’ambiente reale nel modo piùdettagliato possibile al fine di posizionare l’oggetto virtuale nella scena creatae che inoltre possieda la potenza computazionale per effettuare tali operazioni.

Per lo svolgimento del progetto la tecnica più indicata risulta essere la terza, tecnicautilizzata da ARCore, in quanto utilizzabile nella maggior parte degli ambienti edalla maggior parte dei dispositivi che possiedano la capacità di calcolo necessariaper effettuare tali operazioni.


Il funzionamento di ARCore può essere descritto nei seguenti passaggi:

• all’avvio dell’applicazione, o della parte dell’applicazione che utilizza ARCore,viene creata una sessione per il riconoscimento dell’ambiente;

• tramite l’uso di sensori di movimento e la fotocamera di un dispositivo ARCorericonosce punti e superfici appartenenti all’ambiente circostante;

• utilizzando queste informazioni e le differenze tra le immagini ottenute dallafotocamera viene costruito un sistema di coordinate che riconosce la posizionee il movimento del dispositivo;

• utilizzando le superfici riconosciute è possibile posizionare contenuti virtualiall’interno del sistema di coordinate costruito.

Contesto d’utilizzo

Lo scopo di quest’applicazione è quello di poter posizionare modelli 3D appartenentiad elettrodomestici nel mondo reale, al fine di simulare la loro presenza nell’ambiente.Pertanto gli utilizzatore dell’applicativo sono utenti che desidereranno le seguentifunzionalità:

• Possibilità di selezionare tra diversi oggetti 3D;

• Possibilità di posizionare l’oggetto virtuale all’interno di uno spazio realericonosciuto dall’applicazione;

• Possibilità di spostare e ruotare l’oggetto.

Dopo quest’analisi (e considerando quella del punto precedente) è stato individuato ilprincipale flusso che l’applicazione deve seguire, insieme all’individuazione di diversirequisiti nonchè tecniche di posizionamento dell’oggetto virtuale.

Analisi di soluzioni esistenti

Nella fase di pianificazione sono state dedicate alcune ore all’analisi di applicazionidi terze parti presenti sul mercato appartenenti allo stesso dominio applicativo.Particolare attenzione è stata posta alle tecniche utilizzate per descrivere all’utentele proprie funzionalità e le azioni da eseguire per usarle. Infine si è posta l’attenzionea "dove", all’interno dell’interfaccia grafica, l’utente Android sia abituato a trovarele suddette funzionalità.Quest’analisi ha portato all’inserimento delle seguenti ulteriori funzionalità:

• Visualizzazione di una serie di messaggi al primo avvio dell’applicazione atti aspiegare le varie funzionalità;

• Inserimento di una schermata che ha lo scopo di spiegare la procedura daseguire per far riconoscere all’applicazione l’ambiente circostante;

• Inserimento di messaggi d’errore che descrivano all’utente la presenza di partico-lari condizioni che impediscano all’applicazione il riconoscimento dell’ambiente.

3.2. ANALISI DEI REQUISITI 31

3.2.2 Requisiti individuati

Grazie all’analisi del dominio applicativo, del contesto d’utilizzo e delle varie soluzioniesistenti, è stato possibile individuare le principali funzionalità che l’applicazionedovrà possedere. Partendo da queste è stata stilata la lista dei principali requisiti dasoddisfare.I requisiti, riportati nella seguente tabella, assumono la seguente forma:

Importanza Tipologia - Identificativo Descrizione

Dove:

• Importanza: denota il peso del requisito di riferimento e ne stabilisce unapriorità. Assume i valori:

– O: Obbligatorio, il requisito deve essere soddisfatto per considerare ilprogetto completo;

– D: Desiderabile, se il requisito viene implementato porta valore aggiuntoal 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 oespressa nel dettaglio delle componenti;

– V: Di vincolo, specifica un vincolo che il software deve rispettare;

• Identificativo: un numero, generato per incremento, che identifica il requisitoin modo univoco se considerato assieme alla codifica della sua importanza etipologia;

• Descrizione: una breve descrizione del requisito e dei suoi riferimenti.


Nella seguente tabella vengono riportati i requisiti principali individuati:

Codiceidentificativo

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 funzionidell’app

OF-7 Visualizzazione di messaggi d’errori in caso di problemi diriconoscimento dell’ambiente

OF-8 Visualizzazione di alcuni messaggi che spieghino come farriconoscere nuove superfici all’app

OF-9 Visualizzazione di messaggi d’aiuto che spieghino le funzionidell’app

OF-10 Visualizzazione lista oggetti 3D

OF-11 Spostamento verticale di alcuni oggetti 3D

OF-12 Scatto foto dell’oggetto 3D nell’ambiente con salvataggio econdivisione

OV-13 Sviluppo del front-end tramite Apache Cordova

OV-14 Sviluppo del back-end tramite linguaggio nativo Android

DF-15 Visualizzazione di effetti al riconoscimento di una superficieTabella 3.1: Requisiti individuati

3.3. PROGETTAZIONE E SVILUPPO 33

La seguente figura invece rappresenta la suddivisione dei requisiti per tipologia:

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 progettazionee alla realizzazione di una soluzione atta a soddisfare i requisiti individuati.Data la mia scarsa esperienza nello sviluppo di applicativi di questo tipo e con letecnologie da utilizzare, inizialmente ho sviluppato alcuni prototipi con lo scopodi testare le funzionalità richieste i quali sono risultati utili ad aumentare la miafamiliarità con le tecnologie utilizzate.A causa di questo non è possibile, all’interno del mio progetto, considerare proget-tazione e codifica come due attività completamente distinte e separate fra loro, maanzi si possono quasi considerare come un’unica fase che ha lo scopo di strutturare einserire nel prodotto le funzionalità previste.


3.3.1 Architettura di un’applicazione Android

Per capire al meglio la struttura dell’applicazione sviluppata, è necessario prima ditutto descrivere in modo generale la struttura di un’applicazione Android.L’immagine seguente mostra i componenti principali della piattaforma Android.

Figura 3.2: Struttura di un’app Android


Linux Kernel

La base della piattaforma Android è il kernel di Linux. Ad esempio, Android Runtime(ART) si basa sul kernel di Linux per le funzionalità sottostanti come il threading ela gestione della memoria di basso livello.

L’utilizzo di un kernel Linux consente ad Android di sfruttare le principali fun-zionalità di sicurezza e consente ai produttori di dispositivi di sviluppare driverhardware per un kernel ben noto.

Hardware Abstraction Layer (HAL)

L’Hardware Abstraction Layer (HAL) fornisce interfacce standard che espongonofunzionalità hardware dispositivo al livello superiore Java[g]API framework.L’HAL è costituito da più moduli di libreria, ognuno dei quali implementa un’inter-faccia per un tipo specifico di componente hardware, come la fotocamera o il modulobluetooth.

Quando un’API framework effettua una chiamata per accedere all’hardware deldispositivo, il sistema Android carica il modulo della libreria per quel componentehardware.

Android Runtime (ART)

Per i dispositivi che eseguono Android versione 5.0 (livello API 21) o superiore,ciascuna applicazione viene eseguita nel proprio processo e con la propria istanza diAndroid Runtime (ART).

Alcune delle principali funzionalità di ART sono le seguenti:

• Compilazione anticipata e just-in-time;

• Garbage collection ottimizzata;

• Migliore supporto per il debugging, eccezioni diagnostiche dettagliate e rapportisugli arresti anomali e la possibilità di impostare i watchpoint per monitorarecampi specifici

Android include anche un set di librerie di runtime di base che forniscono la mag-gior parte delle funzionalità del linguaggio di programmazione Java, incluse alcunefunzionalità del linguaggio Java 8 , utilizzate dal Java API framework.


Native C/C++ Libraries

Molti componenti e servizi di base del sistema Android, come ART e HAL, sonocostruiti da codice nativo che richiede librerie native scritte in C e C++.La piattaforma Android fornisce Java framework API per esporre la funzionalità dialcune di queste librerie native alle app.

Se stai sviluppando un’applicazione che richiede codice C o C++, puoi utiliz-zare Android NDK per accedere ad alcune di queste librerie di piattaforme nativedirettamente dal tuo codice nativo.

Java API Framework

L’intera serie di funzioni del sistema operativo Android è disponibile tramite APIscritte in linguaggio Java. Queste API costituiscono gli elementi costitutivi di cuihai bisogno per creare app Android, semplificando il riutilizzo dei componenti e deiservizi principali e modulari di sistema, che includono quanto segue:

• Un sistema di visualizzazione ricco ed estendibile che puoi utilizzare per crearel’interfaccia utente di un’app, inclusi elenchi, griglie, caselle di testo, pulsanti epersino un browser Web incorporabile;

• Un gestore di risorse, che fornisce l’accesso a risorse non di codice come stringhelocalizzate, elementi grafici e file di layout;

• Un gestore delle notifiche che consente a tutte le app di visualizzare avvisipersonalizzati nella barra di stato;

• Un Activity Manager che gestisce il ciclo di vita delle app e fornisce uno stackdi back-up di navigazione comune;

• Fornitori di contenuti che consentono alle app di accedere ai dati da altre app(es. Contatti).

Gli sviluppatori hanno pieno accesso alle stesse framework API utilizzate dalle appdi sistema Android.

System apps

Le app incluse nella piattaforma non hanno uno stato speciale tra le app che l’utentesceglie di installare. Pertanto, un’app di terze parti può diventare il browser Webpredefinito dell’utente, l’SMS o la tastiera predefinita (si applicano alcune eccezioni,ad esempio l’app Impostazioni del sistema).

Le app di sistema funzionano sia come app per gli utenti sia per fornire funzionalitàchiave a cui gli sviluppatori possono accedere dalla propria app. Ad esempio, se latua app desidera inviare un messaggio SMS, non è necessario crearlo tu stesso, puoiinvece invocare qualsiasi app per SMS già installata per recapitare un messaggio aldestinatario specificato.


3.3.2 Architettura di un’applicazione sviluppata con Apache Cor-dova

All’interno dei linguaggi nativi utilizzati per lo sviluppo di applicazioni mobile, esisteun componente denominato WebView. Come si evince dal nome una WebView èuna particolare tipologia di View utilizzabile per la rappresentazione di contenutiWeb, permettendo quindi la lettura di contenuti scritti utilizzando HTML, CSS eJavaScript. Utilizzando la WebView è pertanto possibile sviluppare un’applicazione(o una sua parte) tramite linguaggi per il Web.Come si vede nella seguente figura, Apache Cordova utilizza infatti questo metodo.

Figura 3.3: Struttura di un’applicazione sviluppata tramite Apache Cordova

Cordova permette lo sviluppo di un’interfaccia tramite l’utilizzo di linguaggi perla 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, accessoai contatti o alle informazioni sulla batteria) o una parte dell’applicazione è statasviluppata in nativo, è possibile utilizzare i Plugin per effettuare un collegamento trale due parti.

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[g]. Adogni plugin sono associate diverse API native, tante quante sono le piattaformesupportate, 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 principalifunzionalità di un dispositivo (ad esempio GPS, camera, contatti, batteria).È possibile cercare altri plugin sviluppati dalla community o svilupparne uno proprio(come nel caso del mio progetto).


3.3.3 Architettura del progetto

Il progetto prevedeva lo sviluppo di un’applicazione demo che utilizzasse un plugin diApache Cordova. Questo plugin aggiunge all’applicazione di base l’utilizzo della realtàaumentata per posizionare gli oggetti nel mondo reale come descritto in precedenza.Il progetto quindi consisteva nello sviluppo di questo plugin da testare poi, una voltacompletato, all’interno di un’applicazione demo. La struttura dell’applicazione quindiè suddivisa in una parte Front-end sviluppata tramite Apache Cordova e in una parteBack-end sviluppata tramite linguaggio nativo. La comunicazione tra queste dueavviene tramite il componente ar.js, il quale inoltra eventi e richieste ricevute dallato Front-end verso il Back-end.

L’obbiettivo finale dell’azienda era la creazione di un plugin utilizzabile all’internodi una qualsiasi applicazione sviluppata con Apache Cordova. Per questo motivo nonè stata prestata troppa attenzione alla qualità estetica nello sviluppo dell’interfacciagrafica della demo.

Front-end

Il Front-end dell’applicazione, corrispondente alla sua rappresentazione grafica, èformato da un’insieme di componenti sviluppati tramite Apache Cordova.Questa parte dell’applicativo è in comune per tutte le piattaforme per le quali vienesviluppata l’applicazione (o il plugin, come in questo caso) e, per questo motivo, èstata sviluppata prima del back-end.

In questo modo è stato possibile sviluppare la gestione di tutte le "gesture" darendere disponibili all’utente e, sulla base di queste, sviluppare le parti native perogni sistema operativo rendendole più simili l’una con l’altra.

I componenti principali sono descritti in seguito.


HomePage.js

Figura 3.4: HomePage dell’applicazione demo

Questo componente gestisce la pagina iniziale dell’applicazione demo. Viene utiliz-zata esclusivamente per permettere all’utente la selezione del prodotto da posizionare.

Infatti, successivamente, questa schermata non sarà disponibile nell’app finale inquanto si tratta solo di una pagina che permette di scegliere l’oggetto da scaricare/-posizionare simulando la vera e propria possibilità di scelta su un catalogo molto piùampio presente nell’applicazione designata (in questo caso su una serie di prodottielettronici o elettrodomestici).


ARController.js

Una volta selezionato il prodotto nella HomePage vengono passati i dati dell’oggettoscelto al componente ARController.js il quale è incaricato di creare la view vera epropria dell’applicazione. Le views dell’app vengono gestite una Viewstack.

Figura 3.5: Esempio di Viewstack

Un Viewstack (vedi Figura 3.9)non è altro che il luogo il cui vengono inserite leView dell’applicazione secondo una struttura a strati: quando una View diventa visi-bile a causa di qualche operazione o interazione dell’utente essa viene spostata versol’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, senzadovere aspettare operazioni come la creazione di una View.


ARPage.js

Figura 3.6: Schermata di avvio di ARPage

Questo è il componente che gestisce la view principale dell’applicazione. Lo scopodi questa view è quello di raccogliere le informazioni passate dal touch dell’utente epassarle al Back-end sottostante. In questo modo le informazioni ricevute possonoessere elaborate esternamente al plugin lasciando a quest’ultimo solo l’esecuzionedelle funzioni richieste.

La view è composta da un background trasparente, per mostrare la fotocameraattiva sottostante, e da alcuni pulsanti per interagire con il plugin.


Figura 3.7: Posizionamento dell’oggetto

Nello specifico i pulsanti sono 4 e consentono di:

• Close: pulsante per chiudere la view e tornare alla homepage;

• Add: pulsante per effettuare il download dell’oggetto selezionato in precedenza;

• Lift: pulsante per sollevare l’oggetto da terra per un massimo di 1,5 metri.Visibile solo una volta che l’oggetto è stato posizionato nel mondo reale;

• Screenshot: pulsante per effettuare uno screenshot dell’oggetto posizionatonel mondo reale. Visibile solo una volta che l’oggetto è stato posizionato nelmondo reale;

Come anticipato è questo il componente incaricato di raccogliere le informazioniderivanti dalle gesture che l’utente può compiere. A questo punto ARPage.js hail compito di mandare i dati al componente ar.js il quale farà da tramite per lecomunicazioni con il Back-end.

Oltre a gestire la view principale dell’applicazione questo componente ha anchel’incarico di crearne altre nel caso l’utente voglia utilizzare determinate funzionidisponibili attraverso l’uso dei pulsanti sopra descritti. Nello specifico sono statedefinite delle views separate per la gestione delle operazioni di Screenshot e Lift,richiamabili tramite la pressione degli omonimi pulsanti.


ARScreenshotModalView.js

Figura 3.8: Schermata app in modalità "Screenshot"

Questo componente gestisce la view richiamata tramite l’uso del pulsante "Screen-shot". Lo screenshot risultante da questa operazione sarà l’immagine scattata dallafotocamera con la sovrapposizione di alcune informazioni:

• Didascalia descrittiva dell’oggetto posizionato;

• Logo dell’applicazione (o dell’azienda proprietaria)

Durante la inizializzazione della view viene creata l’immagine di screenshot e, unavolta pronta, viene mostrata nella schermata.A questo punto l’utente ha la possibilità di interagire utilizzando i 2 pulsanti adisposizione:

• Condividi: pulsante che consente il salvataggio dell’immagine nella galleriadel telefono o la condivisione;

• Close: pulsante che chiude la view facendo tornare l’utente in quella principale.


ARLiftModalView.js

Figura 3.9: Schermata app in modalità "Lift"

Questo componente gestisce la view richiamata tramite l’uso del pulsante "Lift".Esteticamente la schermata è simile a quella gestita da ARPage.js con la differenzache rimangono disponibili solo i pulsanti "Lift" e "Close" (che chiude questa viewriportando l’utente a quella principale).

Nello specifico, in questa modalità, il tasto "Lift" si estende diventando unoslider [g]attraverso il quale l’utente può alzare ed abbassare l’oggetto dal piano in cuiè posizionato.

Questa funzionalità è stata progettata per poter posizionare al meglio tutti queglioggetti che possono essere messi "a muro" o per simulare il posizionamento su even-tuali superfici non riconosciute dall’applicazione.Infatti, al momento dello sviluppo, non tutte le SDK rese disponibili possedevano lacapacità di rilevare superfici verticali.

In questo modo si è cercato di ovviare al problema portando così ad una minoredifferenza di funzionalità tra la varie piattaforme.


ar.js

Figura 3.10: Schermata app con l’oggetto posizionato

Questo componente è presente all’interno del plugin sviluppato e funge da anellodi congiunzione tra il lato front-end e quello back-end. Tutte le informazioni sullegesture (o la pressione dei tasti disponibili) vengono passate a questo componenteche ha il compito di elaborarle e inoltrarle al Back-end.

Per quanto riguarda le gesture, il componente riconosce la pressione di 1 o piùdita calcolando gli spostamenti dell’oggetto come descritto in seguito:

• Spostamento: se l’utente utilizza un solo dito;

• Spostamento + Rotazione: se l’utente utilizza 2 dita.

Oltre ad incanalare le informazioni ricevute dal front-end verso il back-end (inquesto caso il plugin), ar.js gestisce anche le comunicazioni nel senso opposto tramitel’uso di callback. Ad ogni chiamata verso il plugin viene passata una di questecallback la quale avrà l’incarico di aggiornare il front-end con le nuove informazionio semplicemente di confermare (o meno) il completamento dell’operazione richiesta.


Back-end

Il Back-end dell’applicazione, sviluppato tramite linguaggio nativo, si occupa dieffettuare tutte le funzionalità legate alla realtà aumentata e all’utilizzo di un oggettovirtuale, come il suo posizionamento, spostamento o rotazione.È formato da una serie di componenti che ho sviluppato i quali utilizzano le funzio-nalità offerte da ARCore legate al riconoscimento dell’ambiente.

Come detto in precedenza, questa parte dello sviluppo ha seguito quella relativaal Front-end, permettendo di creare metodi e classi che potessero interagire perfetta-mente con i dati che ricevevano dall’interfaccia grafica.I suoi componenti principali sono descritti in seguito.

ARModelPreviewFragment.java

Questa è la classe principale del lato Back-end in quanto contiene tutte le funzionalitàdella realtà aumentata che il plugin sviluppato deve poter offrire.

Per gestire al meglio l’utilizzo dell’applicazione sono stati definiti internamente5 "stati", ognuno dei quali incaricato di compiere determinate operazioni. Quandoavviene una transizione tra uno stato ed un altro il plugin lo comunica al front-endtramite l’uso di callback come descritto in precedenza.

Nello specifico i 5 Stati sono:

• INITIALIZING: Il plugin è stato avviato e può cominciare il riconoscimentodei piani presenti nel mondo reale analizzato dalla fotocamera. L’utente vieneinvitato a muovere il telefono per permettere una migliore analisi dell’ambientecircostante;

• READY: Il plugin ha riconosciuto almeno un piano orizzontale/verticale nelquale poter posizionare l’oggetto. A questo punto l’utente può caricare l’oggettotramite il pulsante "Add";

• LOADING: Il plugin è nella fase di caricamento/creazione dell’oggetto 3Dda posizionare (eventuale download dell’asset se non presente nella cache);

• POSITIONING: L’oggetto è stato caricato ed è pronto per essere posizionato.In questo Stato appare a video solo la base dell’oggetto scelto per permettereall’utente di scegliere la posizione conscio delle reali dimensioni dell’asset. Unavolta scelta la posizione l’utente può ancorare l’oggetto con un tocco sulloschermo;

• EDITING: L’oggetto è stato posizionato ed è pronto per essere spostato,ruotato o sollevato dall’utente tramite le gesture disponibili.


Una volta che l’oggetto è stato posizionato, l’utente ha a disposizione una serie digesture per poter modificare la sua posizione.

• Spostamento: L’utente ha 2 possibilità per modificare la posizione dell’og-getto:

– Gesture con 1 dito: L’utente può trascinare l’oggetto con un dito;

– Fotocamera: L’utente può spostare l’oggetto tenendo un dito premutosullo schermo e spostando il telefono. L’oggetto seguirà lo spostamentodella fotocamera.

• Rotazione: L’utente può ruotare l’oggetto utilizzando 2 dita;

• Sollevamento: L’utente può sollevare l’oggetto mediante la pressione delpulsante "Lift" e utilizzando lo slider che appare.

ARModelPreview.java

Questa classe è utilizzata come Controller all’interno del plugin. Nello specifico, unavolta che i "tocchi" dell’utente vengono raccolti da ARPage.js ed elaborati da ar.jsvengono passati, un’ultima volta, alla classe ARModelPreview.java la quale è la veraincaricata a chiamare le funzioni adeguate della classe ARModelPreviewFragment.java.

Oltre a chiamare la funzioni richieste, la classe in questione è incaricata di verificarela corretta esecuzione di quest’ultime e preparare, di conseguenza, i dati da restituireal front-end mediante le callbacks.Queste callbacks comunicano se l’esito della chiamata al plugin sia stato positivo(success) o negativo (error) passando, eventualmente, i dati prodotti come risultatodalla chiamata.In particolare ci sono 2 casi in cui la classe in questione restituisce al front-end dellecallbacks contenenti dei dati in formato JSON [g]:

• Cambio di "Stato": come descritto nella classe precedente, sono stati definiti5 "stati" in cui si può trovare l’applicazione. Quando avviene la transizione inun nuovo stato è compito di questa classe informare il lato front-end, il qualetrasmetterà gli specifici messaggi a video per l’utente finale;

• Download: Il download dell’oggetto nella fase di caricamento (stato Loading)è gestito lato back-end. È compito di questa classe aggiornare costantementeil front-end in modo tale che quest’ultimo possa fornire (tramite messaggi avideo) all’utente una stima del progresso del download in corso.

3.4. VALIDAZIONE 49

3.4 Validazione

Durante lo svolgimento del progetto c’è stata una fase iniziale in cui mi sono dedicatoallo sviluppo di alcuni piccoli prototipi al fine di implementare singolarmente lefunzionalità richieste. In questo periodo è stata prestata molta attenzione all’attivitàdi testing di queste funzionalità allo scopo di verificarne la correttezza e l’usabilità.Diverse possibili funzionalità sono state infatti scartate o modificate in fase di sviluppoin quanto definite irrealizzabili o difficilmente intuibili ed utilizzabili da un utente.Tramite questa attività di validazione del prodotto, sono state individuate diversesituazioni anomale ed errori generati dal software, portando alla correzione del codiceche ne è stata la causa e in alcuni casi al refactoring del codice al fine di migliorarnela leggibilità e manutenibilità.

3.4.1 Test effettuati

Al termine dello sviluppo dei prototipi si è proceduto a verificare che le funzionalitàdell’applicazione corrispondessero ai requisiti individuati e che risultassero utilizzabili(e comprensibili) considerando l’esperienza generica di un utente Android.Pertanto, assieme al tutor aziendale, abbiamo testato ogni parte dell’applicativo, perverificare non solo la conformità del prodotto, ma anche la mancanza di problematicheo situazioni impreviste. In particolare è stata prestata particolare attenzione verso latransizione di stati all’interno del ciclo di vita dell’applicazione e di quelli sviluppatiinternamente che sono stati visti precedentemente.


In primo luogo è stato verificato che in un qualsiasi momento in cui l’applicazionefosse stata in uso, un’azione qualsiasi con lo scopo di modificare lo stato dell’appli-cazione (come ad esempio il tornare in Home) non causasse anomalie al sistema diriconoscimento dell’ambiente.

Inoltre il prodotto è stato testato per verificare il suo funzionamento nelle seguentisituazioni limite:

• impossibilità di riconoscimento dell’ambiente circostante;

• mancanza di informazioni legate all’oggetto virtuale;

• tentativo di posizionamento dell’oggetto virtuale oltre la distanza massimariconosciuta;

• 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 ancheche tali situazioni fossero gestite correttamente. Grazie a questi test sono statemesse in luce diverse problematiche e casi che il prodotto non era pronto a gestire,permettendo una risoluzione rapida delle anomalie riscontrate. Al termine di questafase le funzionalità sviluppate sono state completamente accertate e riconosciutecome implementazioni dei requisiti individuati.

Avendo come obiettivo lo sviluppo di un plugin riutilizzabile e modificabile ad hocper ogni evenienza, il codice è stato associato ad una serie di commenti e descrizioneatti a descrivere al meglio il funzionamento di ogni classe e metodo.

In particolare è stato descritto:

• L’utilizzo di ogni variabile;

• lo scopo che ogni classe nel progetto possiede;

• il funzionamento dei vari metodi, descritto in dettaglio nel caso di metodi piùcomplessi;

• l’interazione fra i vari metodi, in relazione al flusso di esecuzione dell’applica-zione.

Capitolo 4

Valutazione retrospettiva

4.1 Conoscenze preliminari

Per lo svolgimento del lavoro di stage non era richiesta una conoscenza approfonditadei linguaggi che si andavano ad utilizzare, in quanto era prevista una prima fase distudio delle tecnologie e lo scopo dello stage era formativo, in modo da arricchire lemie competenze curricolari.

Nonostante ciò, la mia esperienza con le tecnologie utilizzate, maturata nel corso distudi e tramite studi personali, è stata molto utile nel comprendere i nuovi aspetti cheandavo a trattare in azienda, consolidando tali conoscenze. L’aspetto che ha richiestomaggiore impegno da parte mia è stato lo studio delle funzionalità offerte da ARCoree Sceneform in quanto non avevo mai avuto modo di utilizzarli ed approfondirlidurante il mio corso di studi.

Il Corso di Laurea triennale in Informatica mi ha fornito una buona formazionenello sviluppo software, permettendomi la comprensione del ciclo di sviluppo appli-cato al progetto richiesto nel mio periodo di stage, senza troppe difficoltà.

Questi aspetti preliminari hanno permesso che il progetto di stage non subisseimprevisti o interruzioni dovute a mie lacune, potendomi concentrare al meglio suglistudi e le applicazioni previste dal piano di lavoro.

51

52 CAPITOLO 4. VALUTAZIONE RETROSPETTIVA

4.2 Soddisfacimento degli obiettivi

All’interno del Piano di lavoro è stata definita una serie di obiettivi da completareper garantire la conformità del progetto alle aspettative di completamento.In Tabella 4.1 è possibile vedere la lista degli obiettivi raggiunti nel corso dello stage.

Obiettivi Obbligatori EsitoProgettazione di una applicazione di realtà aumentata con ARCore CompletatoRealizzazione di codice per accesso alle funzionalità native dei dispositivi CompletatoRealizzazione di UI in modalità cross platform con HTML5 e CSS CompletatoAnalisi e identificazione di bug su dispositivi CompletatoObiettivi Facoltativi EsitoCapacità di gestione autonoma dei singoli task CompletatoAnalisi costi/benefici dello sviluppo Cross Platform CompletatoObiettivi Desiderabili EsitoValutazione e rispetto dei tempi su macro task CompletatoAnalisi di SDK native CompletatoRealizzazione di un plugin nativo Completato

Tabella 4.1: Obiettivi raggiunti durante lo stage

Come si può notare dalla tabella sono stati raggiunti tutti gli obiettivi fissatinel piano di lavoro. In particolare, durante lo svolgimento del tirocinio, l’obiettivodi realizzare un plugin nativo è diventato di prioritaria importanza. Questo mi haportato a prestare molta attenzione nello sviluppare classi e i metodi finalizzati adun uso più generico possibile.

4.3 Esperienza di stage

Complessivamente, valuto questo stage come un’esperienza molto positiva. Durantetutto l’arco del progetto ho avuto la possibilità di lavorare in un ambiente serio edefficiente ma, allo stesso tempo, non pesante e molto piacevole permettendomi dicompletare gli obiettivi definiti senza la minima distrazione.Per tutta la durata del progetto ho potuto godere di un certo grado di autonomia chemi ha permesso di sperimentare diversi approcci per lo sviluppo delle funzionalitàdel prodotto, nonchè di guadagnare esperienza dal punto di vista gestionale edorganizzativo.

Il tutor aziendale mi ha sempre aiutato nei momenti di difficoltà consigliandomi siasoluzioni per lo svolgimento del progetto, sia quale comportamento e atteggiamentoassumere all’interno di un team di lavoro.Durante il mio sviluppo dell’applicazione per la piattaforma Android, il tutor hasviluppato la parte nativa dell’applicazione per la piattaforma iOS.Questa suddivisione del lavoro si verifica spesso all’interno del team mobile e, pro-varla in prima persona, ha permesso di immergermi maggiormente all’interno delledinamiche lavorative aziendali. Inoltre l’organizzazione del lavoro è stata gestita

4.4. SVILUPPI FUTURI 53

tramite revisioni di avanzamento sia settimanali che giornaliere, le quali verificavanol’avanzamento del progetto e permettevano una revisione in tempo reale degli obiettiviprevisti nonchè un miglioramento del prodotto in corso di sviluppo.

Nel complesso mi sono ritrovato immerso in un’esperienza lavorativa molto stimo-lante e soddisfacente che mi ha permesso di apprezzare ed appassionarmi ancor piùalla programmazione in ambito mobile.

4.4 Sviluppi futuri

Il prodotto sviluppato, anche se completamente funzionante, è stato ideato per per-mettere delle future implementazioni ad hoc in base a quali funzionalità, riguardantila realtà aumentata, si necessitino per l’applicazione in questione.L’organizzazione strutturale del prodotto permette l’aggiunta di funzionalità senzamodificare la struttura presente, grazie all’incapsulamento dei metodi e modularitàdei componenti.Le tecnologie principali utilizzate nello sviluppo (ARCore + Sceneform) sono nuoveed in costante aggiornamento. Questo permetterà in futuro di implementare il pluginesistente con le nuove funzionalità che verranno rese disponibili con gli aggiornamentidelle SDK.

Inoltre, con gli ultimi aggiornamenti, ARCore è stato resto disponibile anche perlo sviluppo di applicazioni per iOS. Grazie a questa novità non è da escludere, infuturo, una re-implementazione del plugin in modo da unificare l’uso di ARCore perentrambe le piattaforme.

4.5 Bilancio formativo

A partire dalle mie conoscenze preliminari nell’ambito ricoperto dal progetto hoavuto modo, tramite il lavoro di stage, di ampliare le mie conoscenze e spingermiverso concetti a me nuovi riguardo la programmazione in ambito mobile.

Grazie al tutor aziendale, ho potuto ricevere molte nozioni ed informazioni utiliallo sviluppo dell’applicazione e all’interno di un team di lavoro. Tutto ciò mi hapermesso di imparare molto, arricchendo le mie conoscenze nello sviluppo mobile,utilizzando strumenti di cui non ero pratico e consolidando le mie conoscenze a livelloteorico, applicandole nella realtà.

Ho acquisito padronanza nello sviluppo nativo per la piattaforma Android utiliz-zando l’IDE Android Studio. Ho studiato e utilizzato gli strumenti per l’uso dellarealtà aumentata e le funzionalità utili che ne derivano.Ho interagito con vari sistemi di versionamento e imparato le basi per lo sviluppodi applicazioni cross-platform con Apache Cordova. Infine ho avuto il tempo diimparare nozioni utili sulla rappresentazione dei modelli 3D e di utilizzare softwareatti alla loro creazione e modifica (Blender).


Oltre al successo nel soddisfare gli obiettivi prefissati per la valutazione positivadello stage, a livello personale ho avuto molta soddisfazione nel raggiungere anchegli obiettivi personali che mi ero posto nella ricerca dello stage.

Ho avuto la fortuna di trovare un tirocinio che mi permettesse di imparare alavorare nel settore dell’informatica che più mi attrae.

Grazie allo stage in Sopra Steria ho avuto modo di crescere professionalmente evivere personalmente un’esperienza lavorativa che ha avuto luogo in un ambientemolto dinamico e stimolante acquisendo una visione generale dei processi di un’aziendarilevante nel settore ICT [g].

Glossario

API: Un’API (Application Programming Interface) è un insiemedi procedure, spesso raggruppate per funzionalità, utili ad un pro-grammatore per svolgere determinati compiti.

Back-end: Denotazione della parte di software non visibile all’u-tente ed incaricata di fornire/gestire le funzionalità del programma.

Business Unit: Una divisione, organizzazione aziendale, identifi-ca un’unità organizzativa di un’impresa preposta alla gestione diun particolare business.

Callback: È, in genere, una funzione, o un "blocco di codice" cheviene passata come parametro ad un’altra funzione. In questo mo-do la chiamante può realizzare un compito specifico (quello svoltodalla callback) che non è, molto spesso, noto al momento della scrit-tura del codice.

Cross-Platform: Può essere riferito ad un linguaggio di program-mazione, ad un’applicazione software o ad un dispositivo hardwareche funziona su più di un sistema o appunto, piattaforma.

CSS: Linguaggio usato per definire la rappresentazione grafica diuna pagina web.

Framework: È un’architettura logica di supporto (spesso un’im-plementazione logica di un particolare design pattern) su cui unsoftware può essere progettato e realizzato, spesso facilitandone losviluppo da parte del programmatore.

Front-end: Denotazione della parte del software visibile all’utente,

55


spesso un’interfaccia grafica con cui egli può interagire ed usufruiredelle funzionalità offerte.

HTML: Linguaggio di markup utilizzato per la scrittura della par-te logica di una pagina web.

ICT: Information and Communications Technology, ovvero le tec-nologie dell’informazione e della comunicazione, spesso questo acro-nimo è usato per definire l’ambito di esercizio delle attività di un’a-zienda.

IDE: Un IDE (Integrated Development Environment) è un soft-ware che offre ad un programmatore diverse funzionalità atte allosviluppo di codice.

Java: È un linguaggio di programmazione ad alto livello, orientatoagli oggetti e a tipizzazione statica, specificamente progettato peressere il più possibile indipendente dalla piattaforma di esecuzione.

Javascript: Linguaggio di scripting orientato agli oggetti e aglieventi, comunemente utilizzato nella programmazione Web latofront-end per la creazione, in siti web e applicazioni web, di effettidinamici interattivi tramite funzioni di script invocate da eventiinnescati a loro volta in vari modi dall’utente.

JSON: JSON, acronimo di JavaScript Object Notation, è un for-mato utilizzato per lo scambio di dati, soprattutto all’interno diarchitetture client-server.

Plugin: È un programma non autonomo che interagisce con unaltro programma per ampliarne o estenderne le funzionalità origi-narie.

4.5. BILANCIO FORMATIVO 57

SDK: Un software development kit (SDK) indica genericamenteun insieme di strumenti per lo sviluppo e la documentazione disoftware.

Slider: Uno slider è un componente grafico (widget) con il qualeun utente può impostare un valore muovendo un indicatore. Inalcuni casi l’utente può anche cliccare in un punto dello slider percambiare le impostazioni.

STAGE-IT: Evento realizzato da Confindustria Padova il cui sco-po è l’incontro tra aziende che desiderano presentare progetti distage e studenti interessati a svolgerli mediante colloqui individua-li.

Stakeholder: Ciascuno dei soggetti direttamente o indirettamen-te coinvolti in un progetto o nell’attività di un’azienda.

Bibliografia

Siti web consultati

Apache Cordova. url: https://cordova.apache.org/.

ARCore. url: https://developers.google.com/ar/.

Backbone.js. url: http://backbonejs.org/.

Bitbucket. url: https://bitbucket.org.

JQuery. url: https://jquery.com/.

Realtà aumentata. url: https : / / it . wikipedia . org / wiki / Realt % C3 % A0 _aumentata.

Sceneform SDK. url: https://developers.google.com/ar/develop/java/sceneform/.

Sopra steria. url: https://www.soprasteria.it.

Underscore.js. url: http://underscorejs.org/.

59

https://cordova.apache.org/

https://developers.google.com/ar/

http://backbonejs.org/

https://bitbucket.org

https://jquery.com/

https://it.wikipedia.org/wiki/Realt%C3%A0_aumentata

https://it.wikipedia.org/wiki/Realt%C3%A0_aumentata

https://developers.google.com/ar/develop/java/sceneform/

https://developers.google.com/ar/develop/java/sceneform/

https://www.soprasteria.it

http://underscorejs.org/

Sviluppo di un'applicazione mobile sulla realtà aumentata

Documents

Transcript of Sviluppo di un'applicazione mobile sulla realtà aumentata