teamwork: unaapplicazionemobile perzextrassuite

Università degli Studi di Padova

Dipartimento di MatematicaCorso di Laurea in Informatica

Teamwork: una applicazione mobileper Zextras Suite

Relatore

Prof. Francesco Ranzato

Laureando

Lisa Parma

A.A. 2017-2018

Lisa Parma: Teamwork: una applicazione mobile per Zextras Suite, Tesi di laureatriennale, c© 27 Settembre 2018.

Ringraziamenti

Ringrazio il Prof. Francesco Ranzato, relatore della mia tesi, per avermi seguitodurante la stesura del lavoro.

Desidero ringraziare con affetto i miei genitori, mia sorella Anna e mia nonna Tinaper il sostegno, il grande aiuto e per essermi stati vicini in ogni momento durantegli anni di studio.

Ringrazio mio nonno Mirco che ha sempre creduto in me e nel raggiungimento diquesto traguardo anche se non può essere qui a festeggiarlo con me.

Un ringraziamento speciale va a Carlo e Michele e in generale a tutto il team diZextras S.r.l., che mi hanno permesso di vivere questa bella esperienza in un settoredell’informatica così interessante.

Infine, non posso non ringraziare i miei amici e compagni di corso per tutti ibellissimi anni passati insieme e per le esperienze affrontate.

Padova, 27 Settembre 2018 Lisa Parma

iii

Sommario

Questa tesi ha lo scopo di documentare lo stage accademico della laureanda LisaParma svolto presso l’azienda Zextras s.r.l. nel periodo tra il 25 giugno 2018 e il 24agosto 2018 della durata di circa 320 ore.Tale stage prevedeva lo sviluppo di un’applicazione mobile crossplatformg per lamessaggistica in React Nativeg , allineandone l’implementazione alla soluzione webOpenChat già sviluppata dall’azienda.

Indice

1 Introduzione 11.1 Organizzazione dell’elaborato . . . . . . . . . . . . . . . . . . . . . 11.2 Convenzioni adottate . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Azienda ospitante 32.1 Profilo dell’azienda . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 Zimbra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.2 Zextras Suite . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Metodo di lavoro . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2.1 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.2 Strumenti a supporto di processi e servizi . . . . . . . . . . . 6

3 Il progetto 93.1 Presentazione progetto . . . . . . . . . . . . . . . . . . . . . . . . . 93.2 Interesse aziendale . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.3 Piano di lavoro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.4 Pianificazione di progetto . . . . . . . . . . . . . . . . . . . . . . . . 10

4 Tecnologie utilizzate 114.1 Ambiente di sviluppo . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.1.1 Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.1.2 IntelliJ IDEA . . . . . . . . . . . . . . . . . . . . . . . . . . 124.1.3 Expo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.2 Linguaggi, librerie e strumenti di programmazione . . . . . . . . . . 134.2.1 React Native . . . . . . . . . . . . . . . . . . . . . . . . . . 134.2.2 TypeScript . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.2.3 TSLint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.2.4 Redux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.3 Strumenti di verifica e valutazione . . . . . . . . . . . . . . . . . . . 154.3.1 Genymotion . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.3.2 React Native Debugger . . . . . . . . . . . . . . . . . . . . . 164.3.3 Jest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5 Analisi dei requisiti 195.1 Attori coinvolti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.1.1 Attori principali . . . . . . . . . . . . . . . . . . . . . . . . . 195.1.2 Attori secondari . . . . . . . . . . . . . . . . . . . . . . . . . 19

vii

viii INDICE

5.2 Casi d’uso principali . . . . . . . . . . . . . . . . . . . . . . . . . . 205.3 Requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.3.1 Principali requisiti funzionali . . . . . . . . . . . . . . . . . . 215.3.2 Requisiti di vincolo . . . . . . . . . . . . . . . . . . . . . . . 225.3.3 Requisiti di qualità . . . . . . . . . . . . . . . . . . . . . . . 22

6 Progettazione e codifica 236.1 Progettazione architetturale e di dettaglio . . . . . . . . . . . . . . 23

6.1.1 Architettura OpenChat . . . . . . . . . . . . . . . . . . . . . 236.1.2 Gestione eventi . . . . . . . . . . . . . . . . . . . . . . . . . 246.1.3 Store Redux . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6.2 Progettazione grafica . . . . . . . . . . . . . . . . . . . . . . . . . . 276.2.1 Wireframe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276.2.2 Linee guida . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

6.3 Interfaccia grafica con React Native . . . . . . . . . . . . . . . . . . 29

7 Verifica e Validazione 317.1 Linter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317.2 Jest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

7.2.1 Component snapshot . . . . . . . . . . . . . . . . . . . . . . 327.2.2 Redux snapshot . . . . . . . . . . . . . . . . . . . . . . . . . 32

7.3 Test di sistema e collaudo . . . . . . . . . . . . . . . . . . . . . . . 327.3.1 Emulatori . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337.3.2 Device fisici . . . . . . . . . . . . . . . . . . . . . . . . . . . 347.3.3 Beta testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

8 Conclusioni 358.1 Valutazione del prodotto finale . . . . . . . . . . . . . . . . . . . . . 358.2 Valutazione framework e librerie utilizzate . . . . . . . . . . . . . . 36

8.2.1 Valutazione React Native . . . . . . . . . . . . . . . . . . . 368.2.2 Valutazione Expo . . . . . . . . . . . . . . . . . . . . . . . . 37

8.3 Valutazione personale dell’esperienza di stage . . . . . . . . . . . . 38

A Descrizione casi d’uso 39A.1 UCG - Caso d’uso generale . . . . . . . . . . . . . . . . . . . . . . . 39A.2 UC1 - Accesso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40A.3 UC1.1 - Inserimento email . . . . . . . . . . . . . . . . . . . . . . . 41A.4 UC1.2 - Inserimento password . . . . . . . . . . . . . . . . . . . . . 41A.5 UC2 - Visualizzazione errore login . . . . . . . . . . . . . . . . . . . 42A.6 UC3 - Visualizzazione buddylist . . . . . . . . . . . . . . . . . . . . 42A.7 UC3.1 - Visualizzazione card buddy . . . . . . . . . . . . . . . . . . 43A.8 UC3.1.1 - Visualizzazione nickname . . . . . . . . . . . . . . . . . . 44A.9 UC3.1.2 - Visualizzazione immagine profilo . . . . . . . . . . . . . . 44A.10 UC3.1.3 - Visualizzazione status . . . . . . . . . . . . . . . . . . . . 45A.11 UC3.1.4 - Visualizzazione data ultimo messaggio . . . . . . . . . . . 45A.12 UC3.1.5 - Visualizzazione notifiche . . . . . . . . . . . . . . . . . . 46A.13 UC4 - Visualizzazione storico chat . . . . . . . . . . . . . . . . . . . 46

INDICE ix

A.14 UC4.1 - Visualizzazione messaggi ricevuti . . . . . . . . . . . . . . . 47A.15 UC4.2 - Visualizzazione messaggi inviati . . . . . . . . . . . . . . . 47A.16 UC5 - Invio messaggi . . . . . . . . . . . . . . . . . . . . . . . . . . 48A.17 UC6 - Modifica buddylist . . . . . . . . . . . . . . . . . . . . . . . . 48A.18 UC7 - Aggiunta buddy . . . . . . . . . . . . . . . . . . . . . . . . . 48A.19 UC8 - Rimozione buddy . . . . . . . . . . . . . . . . . . . . . . . . 49A.20 UC9 - Ricerca buddy . . . . . . . . . . . . . . . . . . . . . . . . . . 49A.21 UC10 - Modifica status . . . . . . . . . . . . . . . . . . . . . . . . . 50A.22 UC11 - Modifica tema . . . . . . . . . . . . . . . . . . . . . . . . . 50A.23 UC12 - Visualizzazione gruppi . . . . . . . . . . . . . . . . . . . . . 51

Glossary 53

Acronyms 57

Bibliografia 59

Elenco delle figure

2.1 Logo Zextras s.r.l. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Logo Zimbra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.3 Rappresentazione Zextras suite . . . . . . . . . . . . . . . . . . . . 5

4.1 Logo Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.2 Logo IntelliJ IDEA . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.3 Logo Expo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.4 Logo React Native . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.5 Logo TypeScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.6 Logo TS Lint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.7 Logo Redux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.8 Flusso dei dati in Flux . . . . . . . . . . . . . . . . . . . . . . . . . 154.9 Logo Genymotion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.10 Logo React Native Debugger . . . . . . . . . . . . . . . . . . . . . . 164.11 Logo Jest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.1 Casi d’uso principali . . . . . . . . . . . . . . . . . . . . . . . . . . 20

6.1 Architettura OpenChat . . . . . . . . . . . . . . . . . . . . . . . . . 236.2 Gestione eventi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246.3 Struttura messaggio SOAP . . . . . . . . . . . . . . . . . . . . . . . 246.4 Redux store utilizzato per gestire Teamwork . . . . . . . . . . . . . 266.5 Wireframe pagina di login, buddylist e chat page. . . . . . . . . . . 276.6 Esempio guidelines spazi . . . . . . . . . . . . . . . . . . . . . . . . 286.7 Relazione tra screen . . . . . . . . . . . . . . . . . . . . . . . . . . . 296.8 Suddivisione in componenti pagina Buddylist . . . . . . . . . . . . . 29

8.1 Screen pagina di login, buddylist e chat page. . . . . . . . . . . . . 35

A.1 UCG - Caso d’uso generale . . . . . . . . . . . . . . . . . . . . . . . 39A.2 UC1 - Accesso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40A.3 UC3 - Visualizzazione buddylist . . . . . . . . . . . . . . . . . . . . 42A.4 UC3.1 - Visualizzazione card buddy . . . . . . . . . . . . . . . . . . 43A.5 UC4 - Visualizzazione storico chat . . . . . . . . . . . . . . . . . . . 46

x

ELENCO DELLE TABELLE xi

Elenco delle tabelle

3.1 Pianificazione sprint . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5.1 Requisiti funzionali . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.2 Requisiti di vincolo . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.3 Requisiti di qualità . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Capitolo 1

Introduzione

1.1 Organizzazione dell’elaboratoQuesto elaborato è organizzato come segue:

• Capitolo 1: descrizione della struttura del documento e delle convenzioniadottate nella stesura dello stesso;

• Capitolo 2: introduzione dell’azienda ospitante, dei suoi prodotti nel mercatoe del metodo di lavoro seguito al suo interno;

• Capitolo 3: presentazione del progetto svolto durante questo stage, gli obiettivi,il mio contributo ad esso e come è stato pianificato il lavoro;

• Capitolo 4: esposizione delle tecnologie che sono state studiate e adottatedurante il mio stage;

• Capitolo 5: elenco dei requisiti che l’azienda ha definito per il prodotto finale;

• Capitolo 6: spiegazione delle scelte implementative e di design dell’applicazio-ne;

• Capitolo 7: descrizione delle fasi di verifica e validazione del prodotto svolte:

• Capitolo 8: conclusione con delle mie considerazioni sia sull’applicazioneprodotta, che sul lavoro svolto e il periodo di stage in generale.

1.2 Convenzioni adottateNella stesura del presente documento sono state adottate le seguenti convenzionitipografiche:

• la prima occorrenza di termini tecnici, ambigui o di acronimi verrà marcatain corsivo e con una “g” a pedice, in modo da indicare la sua presenza nelglossario, riportato in fondo al presente documento;

• i termini tecnici in lingua inglese non traducibili e non presenti nel glossario,verranno evidenziati in corsivo;

1

2 CAPITOLO 1. INTRODUZIONE

• la prima occorrenza di un acronimo viene riportata con la dicitura estesa, incorsivo, e le lettere che compongono l’acronimo vengono riportate in grassetto.Ogni successiva occorrenza presenterà solo la forma contratta;

• le parole chiave presenti in ciascun paragrafo saranno marcate in grassetto,in modo da consentirne una facile individuazione;

• ogni termine corrispondente a nomi di file, componenti dell’architettura ocodice verrà marcato utilizzando un font a larghezza fissa;

• i diagrammi Unified Modeling Language (UML) sono espressi seguendo lostandard 2.0.

Capitolo 2

Azienda ospitante

2.1 Profilo dell’azienda

Figura 2.1: Logo Zextras s.r.l.

L’attività di stage descritta in questo elaborato è stata svolta presso l’aziendaZextras s.r.l. nella sede di Torri Di Quartesolo (VI).Questa società è nata nel 2011 con l’obbiettivo di espandere le possibilità dellasuite di prodotti di collaborazione Zimbra (sez. 2.1.1), uno dei sistemi collaborativi(posta elettronica, calendario, contatti . . . ) più diffusi al mondo. Ha dato cosìvita a Zextras Suite (sez. 2.1.2), un insieme di estensioni per Zimbra Collaborationche migliorano i servizi già presenti e offrono funzionalità importanti per un usolavorativo del software.In pochi anni è riuscita a rendere la propria suite di prodotti l’estensione profes-sionale per Zimbra Open Source più avanzata tra le soluzioni di collaborazionesul mercato. I loro prodotti sono riconosciuti come ottimali anche dall’aziendaproprietaria Synacor, la quale ha portato ad una cooperazione per lo sviluppo dialcuni prodotti open sourceg e per Zimbra Suite Plus.Ad oggi l’azienda presenta sedi secondarie in diversi paesi, quali Francia, Brasile,Russia e Stati Uniti; inoltre, possiede partner in tutto il mondo.

3

4 CAPITOLO 2. AZIENDA OSPITANTE

2.1.1 Zimbra

Figura 2.2: Logo Zimbra

Zimbra è un server di workgroup open source che mette a disposizione una suitedi software collaborativi che consentono di condividere documenti e attività.Di base essa offre i seguenti servizi:

• configurazione personalizzata,

• gestione della posta elettronica,

• rubriche, calendari e condivisione di file,

• chat e chiamate vocali,

• integrazione con i canali web

• privacy e alti livelli di sicurezza

• disponibilità per i dispositivi mobili: oltre che mediante client Zimbra Web eattraverso i client di posta elettronica tradizionale, è possibile accedere allee-mail, ai calendari e alle altre offerte da dispositivi mobile.

Le funzionalità di Zimbra possono essere facilmente estese grazie alla possibilità dicreare ed aggiungere degli add-on chiamati zimlet . Esse sono delle integrazioniche permettono di personalizzare i servizi ed integrarli con servizi web e applicazionidi terzi.Zimbra è disponibile in due versioni:

• Zimbra Open Source Edition: soluzione completamente open source, cheoffre un insieme ristretto di funzionalità standard;

• Zimbra Network Edition: soluzione completa di tutte le funzionalità siaper l’amministratore di sistema sia per l’utente finale.

2.1.2 Zextras Suite

Zextras Suite è un add-on per Zimbra Collaboration: i suoi prodotti sono proget-tati per espandere le funzioni di Zimbra Open Source Edition in maniera a se stanterispetto i moduli Zimbra Network Edition. Infatti Zextras Suite non è distribuitoassieme ad alcun binario o sorgente sotto il copyright di Zimbra.Le principali innovazioni che sono state portate nel mondo Zimbra riguardano lasicurezza dei dati, la mobilità e la gestione dello storageg .

2.2. METODO DI LAVORO 5

La suite comprende i seguenti prodotti:

• Zextras Backup: modulo di backupg professionale che permette il salvataggiodei dati in realtime;

• Zextras Mobile: modulo per la gestione e sincronizzazione di email, contatti,eventi e task con qualsiasi device mobile tramite Exchange ActiveSync;

• Zextras Powerstore: modulo per la gestione avanzata di storage locali eremoti, così da ottimizzare i volumi dei dati Zimbra e risparmiare spazioattraverso la compressione e la deduplicazione;

• Zextras Admin: interfaccia amministrativa avanzata per monitorare gliutenti e le funzionalità di Zimbra, Zextras Suite e ogni altra zimlet ;

• Zextras Chat: piattaforma client/server integrata in Zimbra per la messag-gistica istantanea e le videochat.

Figura 2.3: Rappresentazione Zextras suite

Come rappresentato in figura 2.3, Zextras suite è un’estensione modulare perZimbra Open Source che può essere applicata secondo le proprie esigenze. Proprioper questo risulta la migliore scelta per un uso professionale di Zimbra.

2.2 Metodo di lavoroLa necessità di sviluppare progetti particolarmente complessi che si unisce all’esigen-za di mantenere una certa flessibilità e trasparenza, ha portato l’azienda a preferirel’utilizzo di un ciclo di sviluppo del software di tipo agileg , rispetto a metodi dimanagement più tradizionali incentrati sui processi di sviluppo ma non reattiviai cambiamenti. Questi, infatti, causerebbero una maggior dispersione di risorse,soprattutto nel caso di una forte interazione con il cliente.La filosofia dello sviluppo agile si basa su quattro pilastri fondamentali che lacaratterizzano.

6 CAPITOLO 2. AZIENDA OSPITANTE

Essi sono:

• gli individui e le interazioni sono più importanti dei processig e degli strumenti;

• è più importante avere del software funzionante rispetto ad avere una docu-mentazione esaustiva;

• è più importante la collaborazione col cliente del rispetto dei contratti;

• bisogna essere pronti a rispondere ai cambiamenti oltre che aderire allapianificazione.

Questi principi sono ampiamente condivisi dalla compagine aziendale, la quale basalo sviluppo dei propri prodotti sulla continua interazione con gli stakeholderg e coni clienti.

2.2.1 Scrum

In particolare viene utilizzato il metodo Scrum, che oltre ad essere uno dei sistemipiù diffusi, è particolarmente adatto a progetti complessi ed innovativi.Lo Scrum prevede un modello di sviluppo iterativo nel quale ogni ciclo vienedefinito sprint : esso è un periodo di tempo, solitamente di durata compresa tra 1a 4 settimane, nel quale viene prefissata una lista di requisitig e funzionalità chedevono essere implementate in tale periodo. Questa lista di funzionalità e requisitiviene definita prima in una Product Backlog, documento che contiene tutti i requisitinecessari per la realizzazione del progetto, e poi, periodicamente, in una SprintBacklog, documento nel quale vengono definiti tutti i task da completare nei singolisprint. L’azienda prevede sprint di due settimane e la fine di ognuno di essi coincidecon una releaseg del software. Per gestire al meglio sprint e backlog di ogni progettovengono eseguite delle riunioni periodiche di diverse tipologie:

• Sprint Planning: riunione che precede l’inizio del progetto in cui si stila laProduct Backlog e si determina il numero e la durata degli sprint in base altempo a disposizione e agli obiettivi. Viene inoltre definita la Sprint Backlogper il primo sprint ;

• Daily Scrum: breve confronto giornaliero che permette di sincronizzare ilavoro di tutto il team e di affrontare tempestivamente i problemi riscontrati;

• Sprint Review: revisione al termine di ogni sprint che serve a valutare se gliobiettivi prefissati sono stati completati in modo esaustivo o se è necessariomodificare la pianificazione del lavoro per lo sprint successivo;

2.2.2 Strumenti a supporto di processi e servizi

Zextras S.r.l. utilizza la suite Atlassian, composta da una serie di prodotti attial miglioramento dello sviluppo del software, della gestione dei progetti e dellacollaborazione.

2.2. METODO DI LAVORO 7

BitBucket Server

Per il versionamentog del software viene utilizzato BitBucket Server, un servizio diself-hosting per repositoryg Gitg e per il controllo delle versioni. Permette di eseguiretutte le operazioni di base di Git di base (è un servizio simile a GitHub) ed in piùconsente un pieno controllo dell’accesso in lettura e scrittura al codice. L’accessopuò essere differenziato per utente o per gruppi. BitBucket Server, essendo unservizio di self-hosting, ha la particolarità di poter essere eseguito nei server localicosì da preservare la riservatezza del proprio codice. Inoltre permette l’integrazionecon altri strumenti sviluppati dall’azienda Atlassian, tra i quali Jira, Bamboo eConfluence.

Jira

Jira è un prodotto di isseue-tracking che fornisce funzionalità quali tracciamento deibugg , rilevamento dei problemi e gestione di progetti. Questo software permetteredi scegliere il tipo di ciclo di sviluppo con cui si preferisce gestire il progetto: nelcaso dell’azienda Zextras si adatta perfettamente alla metodologia di lavoro sceltae al sistema Scrum, in quanto permette di gestire al meglio gli sprint e le relativebacklog.

Bamboo

Bamboo è un server sviluppato da Atlassian per la continuous integrationg edeploymentg . Tra le varie funzionalità, permette di eseguire più build in parallelo,per un completamento più rapido, e in caso di errori di compilazione fornisceun’analisi di quest’ultimi, inclusa la stack traceg .

Confluence

Confluence è un software di collaborazione per la creazione di documenti chepermette di creare, organizzare e lavorare su materiale condiviso. Permette dicentralizzare le informazioni, tenere traccia di ogni modifica e, inoltre, supportauna gestione granulare dei permessi di accesso ad ogni singolo file.

Capitolo 3

Il progetto

3.1 Presentazione progetto

Il progetto proposto dall’azienda per il lavoro di stage consisteva nella progettazionee nello sviluppo di un prototipog di applicazione chat per dispositivi mobili. Lefunzionalità che il prodotto doveva presentare devevano essere allineate a quelledella soluzioni già implementate in ambiente web (zimlet OpenChat e zimlet Team-work). Per quanto riguarda la parte grafica, l’applicazione doveva rispettare lo stiledell’omonimo modulo Teamwork, che si trova ora in fase di riprogettazione da partedell’azienda.Tale prodotto è stato sviluppato utilizzando il frameworkg React Native, ed è statoreso disponibile sia per sistemi Androidg che iOSg .

3.2 Interesse aziendale

L’applicazione Teamwork sviluppata si appoggerà al software OpenChat1, moduloopen source sviluppato da Zextras disponibile come zimlet su Zimbra, che richiedel’installazione di Zextras core. L’obbiettivo dell’azienda era di ottenere al terminedello stage un prototipo con almeno le funzionalità base di OpenChat su mobile, inmodo tale da:

• verificare l’effettiva utilità del progetto;

• studiare le migliori soluzioni progettuali per un’ambito ancora inesploratodall’azienda, poiché differente da quello dei prodotti già sviluppati;

• validare le tecnologie utilizzate e, eventualmente, proporre nuovi frameworkdi sviluppo;

• ampliare e/o modificare le proprie User Experience (UX) guidelinesg in basealle differenze tra dispositivi mobile e desktop.

1https://github.com/ZeXtras/OpenChat

9

https://github.com/ZeXtras/OpenChat

10 CAPITOLO 3. IL PROGETTO

3.3 Piano di lavoroIl progetto di stage proposto dall’azienda è stato sviluppato da due stagisti eprevedeva un lavoro di 320 ore ciascuno, così suddivide:

• Formazione (40h): introduzione a Zimbra, Zextras, agli strumenti e alle proce-dure aziendali; un consulente esterno, inoltre, ha provveduto alla formazionesulle tecnologie da utilizzare per il progetto, quali React Native ed Expo, conle quali anche l’azienda ospitante si interfaccia per la prima volta;

• Progettazione UX (40h): studio e realizzazione di alcuni wireframeg dell’appprendendo spunto dall’attuale sistema di chat sviluppato per il web;

• Progettazione architetturale (40h): progettazione dell’architettura client/servernecessaria per l’implementazione dell’applicazione seguendo le bozze dell’UX;

• Implementazione (200h): sviluppo dell’applicazione con lo scopo di raggiungereun prototipo funzionante.

3.4 Pianificazione di progettoIn seguito al periodo di formazione è stato pianificato in maggior dettaglio il lavoroda svolgere. Le otto settimane di stage sono state suddivise in quattro sprint didue settimane ognuno, riuscendo così a sincronizzare lo sviluppo dell’applicazionecon gli sprint degli altri progetti seguiti dall’azienda.Al fine di seguire il metodo lavorativo aziendale, è stata associata una versione direlease del prototipo per ognuno dei quattro sprint decisi.I quattro sprint sono stati così suddivisi:

Sprint Inizio Fine ReleaseI 25/06/18 06/07/18 Alpha1II 09/07/18 20/07/18 Alpha2III 23/07/18 03/08/18 BetaIV 06/08/18 24/08/18 RC

Tabella 3.1: Pianificazione sprint

Capitolo 4

Tecnologie utilizzate

4.1 Ambiente di sviluppo

4.1.1 Docker

Figura 4.1: Logo Docker

Docker è una piattaforma per lo sviluppo, rilascio ed esecuzione di applicazioneall’interno di container. Questi ultimi forniscono una virtualizzazione a livello delsistema operativo Linux senza che sia necessario istanziare delle macchine virtualipienamente operative. I container sono assimilabili a delle macchine virtualimodulari con la peculiarità di essere molto leggere: in questo modo risulta più facilecreare, distribuire, copiare e spostare i container da un ambiente all’altro. Ognicontainer è un processo isolato dagli altri container e dal sistema ospite stesso:ogni volta che viene istanziato un nuovo container si avrà un ambiente pulito,ovvero indipendente dal sistema ospite, da container precedentemente creati e conle caratteristiche specificate.Per sviluppare l’applicazione Teamwork è stato utilizzato Docker 18.03 CommunityEdition per Ubuntu Bionic. In questo modo è stato possibile avviare nelle macchinelocali un container di Zimbra e del core Zextras con la zimlet OpenChat caricatacosì da sviluppare l’applicativo in un ambiente controllato.

11

12 CAPITOLO 4. TECNOLOGIE UTILIZZATE

4.1.2 IntelliJ IDEA

Figura 4.2: Logo IntelliJ IDEA

IntelliJ IDEA è un Integrated Development Environment (IDE) multi-linguaggio emulti-piattaforma. È stata utilizzata l’edizione Ultimate in quanto era necessario uneditor che supportasse JavaScript/TypeScript, mentre la Community Edition nonsupporta questi linguaggi. Dovendo creare un’applicazione con numerose riferimential codice della zimlet OpenChat e di Zimbra sono state sfruttate al meglio lefunzionalità per l’analisi del codice e comprendere le dipendenze esistenti.Questo IDE non è stato imposto dall’azienda, ma è stato scelto personalmente perlo sviluppo dell’applicazione, in quanto avevo già dimestichezza con esso ed è statoconsigliato dai dipendenti che sviluppano con JavaScript.

4.1.3 Expo

Figura 4.3: Logo Expo

Expo è una toolchain open source che permette la gestione di un progetto ReactNative utilizzando il Software Development Kit (SDK) di Expo. L’SDK Expo èuna libreria nativa e JavaScript che fornisce l’accesso alle funzionalità del sistemadel dispositivo (come la fotocamera, i contatti, la memoria locale) senza il bisogno diutilizzare xCodeg o Android Studiog , né di utilizzare codice nativo. Fornisce l’accessoa servizi che in genere sono difficili da gestire nativamente, ma sono richiesti da quasitutte le app come le notifiche push o creare binari nativi pronti per la distribuzionenell’app store. Inoltre semplifica e velocizza le fasi di sviluppo e di testing in quantopermette l’avvio di build automatiche nei loro server che permettono di eseguire inreal-time il codice sia in simulatori che in dispositivi mobili. L’utilizzo di questotool è stato un requisito obbligatorio del progetto. La validazione di Expo è infattiuno degli scopi dello stage, in quanto l’azienda vorrebbe implementarla nei suoiprogetti futuri.

4.2. LINGUAGGI, LIBRERIE E STRUMENTI DI PROGRAMMAZIONE 13

4.2 Linguaggi, librerie e strumenti di programma-zione

4.2.1 React Native

Figura 4.4: Logo React Native

React Native è un framework per lo sviluppo di applicazioni mobile in JavaScriptche permette di unificare l’esperienza di sviluppo su diversi sistemi operativi. InfattiReact Native utilizza le stesse componenti dell’interfaccia utente che vengono utiliz-zate da app native iOS e Android. Si possono comunque integrare dei componentiscritti in Objective-C, Java o Swift così da utilizzare il codice nativo nel casofosse necessario ottimizzare alcuni aspetti dell’applicazione in base alla piattaforma.React Native si basa su ReactJS dove risulta fondamentale il concetto di "compo-nente”. Un componente è un modulo dell’applicazione che ha uno stato, che puòaccettare delle proprietà e che ha un proprio ciclo di vita. Questo approccio disviluppo atomico risulta perfetto per effettuare Unit Test o per creare componentipiù complessi includendone di più semplici.

4.2.2 TypeScript

Figura 4.5: Logo TypeScript

TypeScript è un linguaggio di programmazione sviluppato da Microsoft che estendela sintassi di JavaScript. È nato per poter utilizzare le funzionalità di JavaScriptper lo sviluppo di grandi applicazioni in quanto aumenta la sicurezza e la robustezzadel codice tramite l’aggiunta di classi, interfacce, moduli, tipizzazione e altrefunzionalità importanti per la comprensione di un grande progetto. Il codiceTypeScript sviluppato viene successivamente ricompilato in JavaScript per poteressere interpretato da browser o app.L’utilizzo di questo linguaggio invece che JavaScript non è stato imposto dall’azienda,ma caldamente suggerito dal tutor aziendale. Ho voluto utilizzarlo per imparareun nuovo linguaggio che può portare grandi benefici soprattutto, in termini dichiarezza.


4.2.3 TSLint

Figura 4.6: Logo TS Lint

TSLint è uno strumento di analisi staticag per il codice scritto in TypeScript cheoffre funzionalità estendibili e personalizzabili per la leggibilità, la manutenibilità egli errori di programmazione. È supportato da molti dei moderni editor, compresoIntelliJ IDEA (sez. 4.1.2), utilizzato per il progetto.In parallelo con TypeScript, l’utilizzo di TSLint non è stato obbligatorio ma datala scelta di utilizzare un nuovo linguaggio ho preferito utilizzare questo linter, peressere più precisa nella grammatica del codice.

4.2.4 Redux

Figura 4.7: Logo Redux

Redux è una libreria JavaScript per la gestione semplificata dello stato delleapplicazioni web. In ReactJS e React Native ogni componente possiede uno statoche può cambiare durante il suo ciclo di vita. Questo stato è interno ad ogni singolacomponente ed è difficile, a volte impossibile, la comunicazione di questi dati tracomponenti diverse. Redux, invece, permette la creazione di uno store condiviso,accessibile da tutte le componenti. In tal modo è possibile sincronizzare le modifichee quindi avere dei dati coerenti tra le varie componenti. Nella zimlet OpenChatera già stata utilizzata questa tecnologia e volendo sia sincronizzare i dati, siamantenere la struttura il più simile possibile, si è voluto continuare ad usare questasoluzione, anche perché è l’unico modo per gestire in maniera semplice un numerodi dati ampio e in continuo cambiamento. Redux è stato implementato basandosisu una particolare architettura: Flux.

Flux

Flux è un pattern architetturaleg che ha ispirato Redux, utilizzato per la creazionedi applicazioni web client-side. Esso utilizza un flusso di dati unidirezionale per

4.3. STRUMENTI DI VERIFICA E VALUTAZIONE 15

gestire al meglio la sincronizzazione degli stati tra le componenti React, in mododa garantire che lo stato dello store sia sempre uguale in tutte le componenti checompongono la view.

Figura 4.8: Flusso dei dati in Flux

Il flusso parte da degli oggetti stores, i quali contengono i dati dell’applicazioneche vengono forniti ai vari componenti in modo che la view sia sempre aggiornatacon questi dati.Per modificare i dati presenti in uno store è necessario creare un oggetto action che,mediante il dispatcher dell’applicazione, viene ricevuto dai vari stores, i quali loutilizzano per aggiornare i dati che contengono.

4.3 Strumenti di verifica e valutazione

4.3.1 Genymotion

Figura 4.9: Logo Genymotion

Genymotion è un emulatore software di dispositivi Android. Si integra perfettamentecon Expo(sez. 4.1.3) ed è utilizzato per la gestione di questo progetto, permettendodi avere un riscontro dell’app in real-time durante lo sviluppo e di verificare etestare l’applicazione su più device. Emula più di 3000 configurazioni virtuali didispositivi Android (tra versioni, dimensioni schermo, capacità hardware, ecc..).


4.3.2 React Native Debugger

Figura 4.10: Logo React Native Debugger

React Native Debugger è un applicazione standalone per il debug di app in ReactNative. Si basa sul remote debugger disponibile quando si monitora un progetto inun device fisico o virtuale. Esso offre vari strumenti per il debug :

• React Inspector, per ispezionare il layout e lo style di ogni componentedell’app;

• Redux DevTools, per monitorare gli store Redux utilizzati e le action svoltesu di essi;

• Console, per visualizzare errori e avvisi che avvengono durante l’esecuzionedel codice.

Purtroppo la scelta di utilizzare questo debugger è dettata dal fatto che, al momento,è l’unica soluzione che include tutte le funzionalità utilizzate di React Native.

4.3.3 Jest

Figura 4.11: Logo Jest

Jest è un framework di unit testingg per JavaScript sviluppato ed utilizzato daFacebook per testare le proprie applicazioni in React. È una soluzione completa epronta all’utilizzo, in quanto è automaticamente configurata alla creazione di unnuovo progetto React Native. Rispetto ad altri framework di unit testing offre deivantaggi, come:

• vengono eseguiti solo i file di test relativi ai file modificati;

• gestisce automaticamente le dipendenze durante l’esecuzione dei test;

• permette di testare in modo sincroni il codice asincrono;

• esegue i test in processi paralleli così che finiscano prima.

4.3. STRUMENTI DI VERIFICA E VALUTAZIONE 17

Inoltre Jest funziona con qualsiasi linguaggio compile-to-JavaScript. Sia il codiceda testare che i test stessi possono essere scritti in TypeScript, linguaggio utilizzatoper questo progetto.

Capitolo 5

Analisi dei requisiti

5.1 Attori coinvolti

Durante l’attività di analisi dei requisiti sono stati individuati quattro attori capacidi interagire attivamente con l’applicazione Teamwork. Di questi tre sono attoriprincipali, mentre uno è un attore secondario.

5.1.1 Attori principali

Utente Zimbra

L’applicazione è destinata solamente agli utenti Zimbra. Ciò implica che si possaaccedere alle funzionalità di Teamwork esclusivamente se si è già in possesso diun’email Zimbra gestita dai loro server. Tale scenario è rappresentato dall’attorepiù generico.

Utente OpenChat

Un utente OpenChat, specializzazione dell’utente Zimbra, rappresenta un utenteche utilizza un’istanza di Zimbra con la zimlet OpenChat installata. Quest’ultimapermette di chattare con gli utenti Zimbra dello stesso server.

Utente Teamwork web

Un utente Teamwork web, specializzazione dell’utente OpenChat, rappresenta unutente che, oltre ad utilizzare un’istanza di Zimbra con la zimlet OpenChat, hainstallato anche la zimlet Teamwork, applicazione di chat potenziata rispetto allaprima e disponibile solo per la suite Zextras.

5.1.2 Attori secondari

Server Zimbra

Un server Zimbra è un’istanziazione della suite di prodotti Zimbra e, in caso, deiprodotti Zextras. Tramite esso è possibile accedere a tutti i dati del profilo Zimbracosì da mantenerli sincronizzati tra le varie sessioni in uso.

19

20 CAPITOLO 5. ANALISI DEI REQUISITI

5.2 Casi d’uso principali

Considerando l’obbiettivo del progetto (sez. 3.2) e il metodo di lavoro utilizzato(sez. 3.4), i casi d’uso (come i requisiti funzionali) sono stati sviluppati e modificatidurante tutto il corso del progetto. Per l’identificazione dei requisiti funzionalisono stati delineati i casi d’uso principali tramite le richieste dell’azienda e quelli dialto livello, in modo da poter dare una visione d’insieme più precisa del prodottosviluppato.La Figura 5.1 rappresenta il diagramma dei casi d’uso principali.

Figura 5.1: Casi d’uso principali

In appendice A è possibile trovare una descrizione esaustiva dei casi d’uso studiati.

5.3 Requisiti

Ogni requisito di seguito riportato è identificato da un codice, ed è rappresentatonel seguente modo:

R {importanza}{tipo}{numero_vincolo}

• "R" è prefisso di tutti i codici dei requisiti;

5.3. REQUISITI 21

• Il primo valore rappresenta l’importanza: 0 se il requisito è obbligatorio, 1 seè desiderabile, 2 per gli opzionali;

• Il terzo valore indica il tipo: F per i requisiti funzionali, Q per quelli diqualità, P se prestazionale, V se di vincolo;

• L’ultimo numero indica il numero del vincolo. La struttura numerica diquest’ultimo rispetta le stesse regole dei Casi D’Uso.

5.3.1 Principali requisiti funzionali

Id Requisito DescrizioneR0F1 L’utente Zimbra deve poter effettuare l’accesso

inserendo inserendo l’email e la password con cui èregistrato al server Zimbra.

R0F1.1 L’utente Zimbra può inserire la propria mail.R0F1.2 L’utente Zimbra può inserire la propria password

dell’account Zimbra.R0F2 Il sistema deve mostrare un messaggio di errore in caso

di inserimento dei dati errati o mancanti.R0F3 L’utente OpenChat deve poter vedere la propria

buddylist una volta effettuato l’accesso all’applicazione.R1F3.1 L’utente OpenChat deve poter vedere per ogni buddy

della sua buddylist una card contenente dei dettaglirelativi al buddy.

R1F3.1.1 L’utente OpenChat deve poter vedere per ogni buddydella sua buddylist il nickname corrispondente.

R1F3.1.2 L’utente OpenChat deve poter vedere per ogni buddydella sua buddylist l’immagine profilo corrispondente.

R1F3.1.3 L’utente OpenChat deve poter vedere per ogni buddydella sua buddylist lo status in cui si trova.

R1F3.1.4 L’utente OpenChat deve poter vedere per ogni buddydella sua buddylist la data dell’ultimo messaggio

scambiato con tale utente.R1F3.1.5 L’utente OpenChat deve poter vedere per ogni buddy

della sua buddylist il numero dei messaggi ricevuti nonancora letti.

R0F4 L’utente OpenChat deve poter vedere per ogni buddydella sua buddylist lo storico delle conversazioni avute.

R0F4.1 L’utente OpenChat deve poter vedere per ogni buddydella sua buddylist i messaggi ricevuti.

R0F4.2 L’utente OpenChat deve poter vedere per ogni buddydella sua buddylist i messaggi inviatogli.

R0F5 L’utente OpenChat deve poter inviare messaggi ad ognibuddy della sua buddylist.

22 CAPITOLO 5. ANALISI DEI REQUISITI

Id Requisito DescrizioneR1F6 L’utente OpenChat deve poter modificare la sua

buddylist.R1F7 L’utente OpenChat deve poter aggiungere un nuovo

buddy alla sua buddylist conoscendone l’e-mail.R1F8 L’utente OpenChat deve poter rimuovere un buddy

dalla sua buddylist così che non possa più contattarlo.R2F9 L’utente OpenChat deve poter ricercare i buddy tra

quelli presenti nella sua buddylist in base a dei caratteri.R1F10 L’utente OpenChat deve poter modificare il proprio

status con cui viene visualizzato dagli altri utenti..R2F11 L’utente OpenChat deve poter modificare il tema dei

colori dell’applicazione.R1F12 L’utente OpenChat deve poter visualizzare i gruppi di

cui fa parte.Tabella 5.1: Requisiti funzionali

5.3.2 Requisiti di vincolo

Id Requisito DescrizioneR0V1 L’applicazione deve essere sviluppata in React Native.R0V2 L’applicazione deve essere disponibile per iOS.R0V3 L’applicazione deve essere disponibile per Android.R0V4 Lo sviluppo dell’applicazione deve prevedere l’SDK

Expo.R1V5 Il codice dell’applicazione può essere scritto in

TypeScript.Tabella 5.2: Requisiti di vincolo

5.3.3 Requisiti di qualità

Id Requisito DescrizioneR0Q1 L’applicazione deve sincronizzare i dati con quelli delle

altre sessioni aperte.R0Q2 L’interfaccia grafica deve rispettare le linee guida fornite

dall’azienda.R0Q3 Deve essere disponibile una documentazione per gli

sviluppi futuri.R1Q4 L’esperienza utente deve essere allineata con la

soluzione già disponibile in ambiente webTabella 5.3: Requisiti di qualità

Capitolo 6

Progettazione e codifica

6.1 Progettazione architetturale e di dettaglio

6.1.1 Architettura OpenChat

Dal momento che l’applicazione sviluppata è basata su una soluzione già implemen-tata per il web dalla zimlet OpenChat è utile approfondire la sua architetturag percomprendere quali siano le differenze che sono state applicate.La comunicazione tra il server Zimbra e la zimlet OpenChat avviene attraverso unastruttura Simple Object Access Protocol (SOAP), protocollo per lo scambio di mes-saggi tra componenti hardware. Questa struttura, nel caso della zimlet OpenChat,permette indirettamente la comunicazione con il server facendo passare gli eventi peril web client Zimbra che li gestisce in base ai propri bisogni prima di inviarli al server.

Figura 6.1: Architettura OpenChat

Dato che l’applicazione Teamwork non interagisce con Zimbra web client è statamodificata la modalità di ricezione ed invio dei messaggi SOAP e la gestione tramiteconnection manager in modo da far comunicare direttamente Teamwork e il serverZimbra (con Zextras core integrato).

23

24 CAPITOLO 6. PROGETTAZIONE E CODIFICA

6.1.2 Gestione eventi

Per gestire in modo ottimale ed efficacie la comunicazione tra server e client è statastrutturata un’architettura capace di reagire alla ricezione e all’invio di eventi.Questa struttura permette la sincronizzazione dei dati tra il server e tutte le sessioniaperte facendo in modo di tenere aggiornato lo store Redux di ogni applicazioneconnessa.Di seguito un’approfondimento delle varie componenti che permettono questainterazione:

Figura 6.2: Gestione eventi

SOAP

La trasmissione e la negoziazione dei messaggi scambiati tra server e client èregolata secondo i protocolli HyperText Transfer Protocol (HTTP) o Simple MailTransfer Protocol(SMTP), all’interno dei quali viene incapsulato il messaggioSOAP. I messaggi SOAP, rappresentati in figura 6.3, sono basati sul metalinguaggioeXtensible Markup Language (XML) e vengono strutturati secondo due segmentiprincipali, head e body.

Figura 6.3: Struttura messaggio SOAP

6.1. PROGETTAZIONE ARCHITETTURALE E DI DETTAGLIO 25

• Il segmento head contiene metadati utili per la trasmissione del messaggio,come informazioni per il routing e per la sicurezza. Può essere opzionale.

• Il segmento body, che invece risulta obbligatorio, trasporta il contenutoinformativo (payload) del messaggio. Saranno questi i dati importanti per lagestione delle informazioni.

Per ogni SOAP request inviata al server ci sarà una SOAP response in ritorno. Que-sta risposta può contenere dati richiesti dalla precedente SOAP request, informazionisullo stato del server o possibili errori di risposta.

Connection Manager

Il connection manager si occupa degli eventi in arrivo dal server. Per fare ciò habisogno di due componenti principali:

• il ping, componente che si occupa di stabilire una connessione con il server e dimantenerla operativa durante tutta la sessione. In questo modo l’applicazionerimarrà sempre in ascolto di nuovi eventi provenienti dal server;

• il decoder, componente che, una volta ricevuto un messaggio SOAP dal ping,si occupa di decodificarne il body permettendo una più facile comprensionedel contenuto. È stata implementata un Abstract Factory per la creazionedi questa componente, design patterng che fornisce un’interfaccia per crearefamiglie di prodotti senza specificare classi concrete.

Handlers

Questa famiglia di componenti riceve in input degli eventi provenienti dal decoder.Questo vuol dire che non riceve dei generici messaggi SOAP ma dei JavaScriptObject Notation(JSON) associati a dei particolari eventi di cui è stato implementatoun handler specifico.La sua funzione, quindi, è quella di modificare lo stato dello store Redux, basandosisui dati ricevuti, attraverso un dispatcher che modifica il flusso dei dati utilizzatinell’applicazione in modo unidirezionale, così da non creare inconsistenza.

Encoder

Gli eventi possono essere generati anche dall’applicazione e per gestire la propaga-zione delle modifiche che vengono fatte allo store Redux al server (con la successivapropagazione dei dati verso le altre sessioni) è stato introdotto un encoder, ilcorrispondente del precedente componente decoder per l’invio degli eventi.Quando viene fatto il dispatch di un’azione, con la conseguente modifica dello store,vengono invocati dei particolari middleware che si occupano dell’invio dell’eventoall’encoder corrispondente. Questa componente permette la traduzione dell’eventoin un messaggio SOAP generico comprensibile dal server.


6.1.3 Store Redux

L’architettura disegnata per la gestione degli eventi ha come punto focale il concettodi store, database locale dove vengono salvati tutti i dati necessari all’implemen-tazione tramite React Native dell’interfaccia grafica. Come spiegato nel capitoloTecnologie utilizzate (4.2.4), uno store Redux è un database dinamico condiviso,accessibile da tutte le componenti di React Native così che possano sempre averedei dati coerenti tra loro.Tramite Flux, il design pattern architetturale implementato da Redux, è statopossibile ottimizzare la gestione dei dati in modo reattivo all’arrivo degli eventi.In particolare è stato deciso di introdurre due store distinti nell’applicazione:

• lo Store OpenChat è stato ereditato dall’implementazione della zimletOpenChat in quanto, per ottenere dei dati sincronizzati, deve necessariamenterispecchiare la sua struttura. Questo store è quindi connesso alla gestionedegli eventi tramite il connection manager ed è la fonte principale dei datifunzionali per l’applicazione.

• lo Store Teamwork, invece, detiene dati operativi utili alla gestione dell’ap-plicazione e importanti per mantenere la sessione attiva.

Diagramma delle classi store Redux Teamwork

Figura 6.4: Redux store utilizzato per gestire Teamwork

6.2. PROGETTAZIONE GRAFICA 27

6.2 Progettazione grafica

Prima di procedere alla definizione delle classi necessarie per l’implementazionedell’applicazione è stato deciso di effettuare la progettazione della User Interface(UI) per per far sì che il progetto di stage comprenda ogni aspetto della progettazionee dello sviluppo di un’applicazione da parte di un azienda.

6.2.1 Wireframe

In base ai requisiti e agli use case raccolti è stato definito il modello inizialedell’applicazione tramite la realizzazione dei wireframe delle varie schermate.Questo studio è la prima rappresentazione visuale dell’applicazione ed ha lo scopodi identificare la struttura, l’architettura dell’informazione e la disposizione deglielementi nella pagina.Di seguito vengono riportati i wireframe sviluppati di alcune delle pagine piùimportanti di Teamwork :

Figura 6.5: Wireframe pagina di login, buddylist e chat page.

Come possiamo notare dagli esempi riportati, in questa fase non è stato decisonulla riguardo la rappresentazione grafica dei vari elementi, infatti è stata definitasoltanto la struttura delle varie schermate, il collegamento tra di esse e qualielementi realmente soddisfino i requisiti già studiati. Il risultato, comunque, è statomolto vicino alla Graphical User Interface (GUI) ottenuta alla fine della codificain quanto i wireframe sono stati disegnati tenendo conto della soluzione web giàpresente.Questo passo è stato essenziale per rendere più chiara l’idea del prodotto desiderato.


6.2.2 Linee guida

Per quanto riguarda la GUI vera e propria sono state fornite dall’azienda delleguidelines da seguire per la rappresentazione grafica di ogni elemento.Nello specifico le guidelines toccano temi come:

• le proporzioni tra i componenti;

• i colori da utilizzare;

• le definizioni di alcuni elementi base;

Questo consente di avere uno stile comune tra le varie applicazioni che l’aziendasviluppa.Un esempio è la definizione del componente card, destinato alla visualizzazione deidettagli relativi ad un buddy :

Figura 6.6: Esempio guidelines spazi

Si noti come ogni elemento sia posizionato in modo preciso, definendo delleproporzioni tra gli spazi. In questo modo la successiva codifica dello stile dovràassolutamente rispettare tali regole, in modo da non dover interagire continuamentecon il responsabile grafico del progetto.L’applicazione delle guidelines nel codice è avvenuta in parallelo con lo sviluppoin quanto, seguendo una metodologia agile, si è ritenuto opportuno che le varieversioni prototipali dell’applicazione avessero anche una progressiva applicazionedelle regole di stile.Approvati i wireframe è stato possibile proseguire alla definizione di tutti e soli icomponenti veramente utili al layout.

6.3. INTERFACCIA GRAFICA CON REACT NATIVE 29

6.3 Interfaccia grafica con React Native

Per la realizzazione della UI è stato utilizzato il framework React Native che consentela realizzazione di interfacce tramite la suddivisione del sistema in componenti.Ognuna di queste ha un proprio stato, delle proprietà che vengono ereditate dalcomponente padre, e un proprio ciclo di vita, indipendente da qualsiasi altro.Sono stati quindi progettati i componenti e la gerarchia tra essi, necessaria per lavisualizzazione degli screen precedentemente definiti, e infine è stata realizzata unanavigazione tra le pagine che rispettasse la gerarchia.

Figura 6.7: Relazione tra screen

L’immagine 6.7 descrive le relazioni di navigazione tra gli screen implementati.Ognuno di questi screen viene rappresentato come un’unico componente e per essererenderizzato utilizzerà a sua volta altri componenti.Prendiamo come esempio lo screen Buddylist :

Figura 6.8: Suddivisione in componenti pagina Buddylist


Possiamo vedere come lo screen buddylist sia un componente che renderizza altretre tipi di componenti:

• <TopBar>, che viene a sua volta renderizzato con <StatusBar> (componentedifficilmente gestibile in quanto subisce forti variazioni a seconda del siste-ma operativo), un semplice componente di testo e due componenti <Icon>.Quest’ultimi possiedono anche una proprietà navigation che permette lanavigazione verso altri screen;

• <CardBuddy>, caricata n volte sullo screen buddylist dipendente dal numero dibuddy. Anche questa componente è complessa e costituita da più componenti<Text>, <Img> e un altro componente complesso <ProPic>;

• <BottomTab> che gestisce la navigazione verso i due stack principali, ChatStacke SettingsStack. Il suo rendering,però, viene gestito solamente da duecomponenti semplici: <Icon> e <Text>.

Capitolo 7

Verifica e Validazione

7.1 Linter

Come strumento di verifica statica del codice è stato utilizzato TSLint, descrittonella sezione 4.2.2 di questo elaborato. Questo linter specifico per codice TypeScriptsegnala errori di programmazione, errori stilistici e costrutti sospetti in base adeterminati criteri personalizzabili durante la codifica dei programmi.In particolare è stato utilizzato per rendere conforme il codice scritto alle convenzioniutilizzate in azienda. Degli esempi sono:

• dichiarazione dei tipi e delle interfacce obbligatoria;

• utilizzo di particolari costrutti, come l’utilizzo di cicli "for-of " al posto dicicli "for" standard nei casi in cui l’indice sia utilizzato solamente per accedeagli elementi dell’array su cui viene eseguita l’iterazione;

• ordine alfabetico per importazioni e attributi;

• obbliga la dichiarazione dello scope di variabili e funzioni, impedendo l’impor-tazione di variabili, funzioni e membri privati.

7.2 Jest

I test automatici che sono stati sviluppati sono per numero e un numero ridottorispetto alla quantità richiesta per analizzare il codice e il comportamento delprodotto in maniera esaustiva, ma per volontà dell’azienda, si è preferito investireun tempo maggiore nello sviluppo di funzionalità che nel loro testing, data la ridottadurata dello stage.Per rendere completa l’esperienza di stage e riuscire a toccare tutto il ciclo di vitadello sviluppo del progetto sono comunque stati fatti dei test automatici. Per fareciò è stato utilizzato JestJs (sez. 4.3.3), tool di testing specifico per i progettiReactJS e React Native integrato nella configurazione del progetto.Sono stati sviluppati due tipologie di test:

• Snapshot test per le componenti;

31

32 CAPITOLO 7. VERIFICA E VALIDAZIONE

• Snapshot test action e reducer Redux.

Vediamoli in dettaglio.

7.2.1 Component snapshot

Ogni componente React Native possiede uno stato e delle props che possono esseremodificate durante il suo ciclo di vita, facendo variare anche il suo rendering.Attraverso questa tipologia di test si controllano questi cambiamenti creando deglisnapshot di come il componente dovrebbe essere renderizzato.In questo modo quando andremo a modificare il codice avremo la sicurezza di nondover controllare il rendering facendo una valutazione grafica su emulatori o device,perché i test ci informeranno su eventuali cambiamenti inaspettati.Inoltre, sarebbe buona norma effettuare i test con dei mockg dei vari stati possibili,in modo da avere la certezza di coprire tutti i possibili casi di rendering.

7.2.2 Redux snapshot

Questi test servono a verificare se le funzionalità introdotte con action e reducerproducono effettivamente il risultato voluto sullo store Redux.

Reducers

Passando un’action ed uno stato ad un reducers questo ci ritornerà un nuovo stato.Una volta implementato è facile definire il comportamento desiderato tramite unosnapshot ed applicare questo al nostro test così che venga simulato per ogni statotrovato nell’applicazione o nel mock di riferimento.Nel progetto Teamwork sono stati testati alcuni dei reducer più complessi dellostore Teamwork utilizzato per le funzioni operative.

Action

Le action sono delle semplici funzioni che ritornano un oggetto utilizzato permodificare lo stato dello store. Per testarle non si fa altro generare uno snapshotdell’output generato utilizzandolo come confronto per le modifiche future.Anche in questo caso le action dello store Teamwork sono molto banali e sono statieseguiti test solamente per alcune di esse, come esercizio.

7.3 Test di sistema e collaudoPer accertare la copertura dei requisiti si è ricorso a delle prove pratiche delcorretto funzionamento dell’applicazione. Questa operazione è stata svolta siacome strumento per la verifica delle operazioni durante lo sviluppo del prodottosoftware che come operazione di collaudo per assicurare il corretto funzionamentodell’applicazione, una volta implementate tutte le funzioni richieste.

7.3. TEST DI SISTEMA E COLLAUDO 33

Grazie al framework per lo sviluppo utilizzato, Expo, è stato facile testare fin dalleprime implementazioni, dato che permette build automatiche in realtime testabiliattraverso link su vari device contemporaneamente.

7.3.1 Emulatori

La parte finale dello sviluppo del codice è stata accompagnata, in modo proficuo,da un continuo rendering dell’applicazione. Attraverso gli emulatori collegatial framework di sviluppo è stato possibile testare ogni modifica del codice quasisimultaneamente al salvataggio delle modifiche, rendendo più agile l’implementazionedella grafica.Per aver il più ampio spettro possibile di device simulati sono stati utilizzati duediversi simulatori: Genymotion (sez. 4.3.1) per i dispositivi Android e iOS Simulatorper iOS. I device emulati su cui è stata testata ogni funzione dell’applicazione sono:

• Google Nexus 6;

• Google Pixel;

• Google Pixel XL;

• HTC One;

• Samsung Galaxy Note;

• Samsung Galaxy S3;



• Sony Xperia Z;

• iPhone 5s;

• iPhone 6 plus;

• iPhone 7;

• iPhone X.

Sui device appena elencati sono stati utilizzati i seguenti sistemi operativi peraccedere all’applicazione:

• Android 5.1.0, API level 22 or Lollipop;

• Android 6.0.0, API level 23 or Marshmallow;

• Android 7.1.0, API level 24 or Nougat;

• Android 8.0.0, API level 26 or Oreo;

• iOS9 (9.3.5);

• iOS10 (10.3.3);

• iOS11 (11.4.1).

34 CAPITOLO 7. VERIFICA E VALIDAZIONE

7.3.2 Device fisici

Oltre agli emulatori sono stati utilizzati dei device fisici dell’azienda a disposizionedegli sviluppatori per installare e testare l’applicazione. Per fare ciò è stato richiestodi costruire dei file binari dell’applicazione Expo per iOS (.ipa) ed Android (.apk).I device su cui è stata testata Teamwork:

• HTC Desire 825;

• Samsung Z3;

• Samsung Galaxy J3;

• Tablet Fire 7;

• iPhone 5;

• iPhone X;

• iPad 2;

7.3.3 Beta testing

Le funzionalità apportate all’applicazione durante il periodo di stage sono statepiù accurate e numerose di quelle inizialmente stabilite, tanto che si è deciso diprocedere ad una fase di beta testing interno all’azienda.

Test Flight

Attraverso il programma per sviluppatori Apple si è avviata la procedura perpoter caricare le build (.ipa) dell’applicazione sull’App Store Connect, così dapermettere il testing attraverso TestFlight.TestFlight è un’applicazione utilizzata per testare applicazioni non ancora sullostore ufficiale, usufruibile da chiunque sia stato invitato a provare la beta. Tramitequesto programma si ha la possibilità di distribuire l’applicazione fino ad un massimodi 25 persone. Tramite il loro utilizzo dell’applicazione gli sviluppatori riceverannodati concernenti lo stato dell’applicazione in funzione, gli errori e i warning emersi,così da avere un’overview generale sull’andamento dell’applicazione su altri device.Inoltre i tester possono inviare segnalazione e suggerimenti.Dopo questa prima fase di testing interno è obbligatorio procedere ad un testingesterno prima di pubblicare l’applicazione sull’Apple Store.

Capitolo 8

Conclusioni

8.1 Valutazione del prodotto finale

L’applicazione Teamwork sviluppata nei due mesi di stage soddisfa pienamente leaspettative dell’azienda, in quanto non pensavano di arrivare ad avere in mano unprototipo con tutte le funzionalità principali.Questo ha confermato all’azienda l’effettiva utilità di un’applicazione mobile dichat da integrare nella suite Zextras. Infatti il progetto Teamwork verrà portatoavanti senza applicare cambiamenti drastici dell’architettura, a partire dal codicesviluppato nei mesi di stage.La figura 8.1 rappresenta tre screen dell’applicazione finale (rispettivamente login,buddylist e chat page) che possono essere confrontati con la figura 6.5 che rappresentai wireframe progettati.

Figura 8.1: Screen pagina di login, buddylist e chat page.

Per quanto riguarda l’interfaccia grafica sono molto soddisfatta del risultatoottenuto in quanto segue perfettamente le linee guida fornite dall’azienda.

35

36 CAPITOLO 8. CONCLUSIONI

Personalmente ritengo il prodotto sviluppato un ottimo prototipo della possibilechat della suite, ma la ritengo ancora lontana dall’essere una versione rilasciabile etestabile da utenti esterni principalmente per due motivi:

• le funzionalità implementate non sono abbastanza numerose da coprire ibisogni che dovrebbe soddisfare questo tipo di applicazione;

• essendo una suite di prodotti utilizzati in ambiente lavorativo è necessarioassicurare una certa sicurezza nella comunicazione dei dati e nella connessioneai server, criptando i messaggi all’invio. Ciò non è stato però previsto nellostage.

8.2 Valutazione framework e librerie utilizzateL’obbiettivo di questo progetto di stage, oltre ad avere un prototipo funzionantedell’applicazione, era quello di validare delle tecnologie ancora non utilizzate dall’a-zienda per capire se fossero effettivamente utili allo sviluppo di futuri progetti.Sebbene abbia ancora molto da imparare su queste tecnologie per poterne giudicarepregi e difetti in maniera critica, ritengo adeguato effettuare una valutazione aposteri del compimento del progetto.

8.2.1 Valutazione React Native

Per realizzare l’interfaccia utente delle ultime zimlet sviluppate dall’azienda si èutilizzato ReactJS, libreria JavaScript che ha permesso di migliorare lo sviluppo e lagestione dei dati rispetto alla precedente tecnologia utilizzata specifica per Zimbra.Per la realizzazione di applicazioni mobile è disponibile una sua variante, ReactNative, che, nonostante le differenze, presenta una struttura simile.Proprio per mantenere una certa continuità è stato deciso di testare le funzionalitàdi React Native in questo progetto.In base all’esperienza di sviluppo avuta ho potuto valutare React Native in base avari punti:

App multipiattaforma

React Native permette lo sviluppo di applicazioni mobile sia Android che iOSutilizzando JavaScript. In questo modo non è necessario sviluppare due versionidell’applicazione in due linguaggi differenti per poter pubblicare l’app nei due store(App Store e Google Store).Ovviamente questa integrazione presenta anche degli aspetti negativi da valutare.Innanzitutto le piattaforme native Android ed iOS presentano molte differenze etentare di generalizzare i comportamenti di tutti i componenti nativi risulta impos-sibile. Per questo motivo non sono implementati tutti i componenti che avremmoa disposizione nei due ambienti di sviluppo nativi e. inoltre, non è detto che uncomponente si comporti in modo uguale sui diversi sistemi operativi per mobile.In secondo luogo React Native crea un livello di astrazione al di sopra dell’applica-zione che può essere meno performante di un dialogo diretto tra applicazione nativae sistema operativo.

8.2. VALUTAZIONE FRAMEWORK E LIBRERIE UTILIZZATE 37

Virtual DOM

Per accedere e aggiornare dinamicamente il contenuto, la struttura e lo stile deidocumenti nel client web e nelle applicazioni che utilizzano WebView si utilizzail Document Object Model (DOM), una forma di rappresentazione dei documentistrutturati, che tenta di renderli neutrali rispetto alla lingua e alla piattaforma.React Native, invece, utilizza il Virtual DOM che crea una struttura dei dati in-memory : lavorando per differenza aggiorna in modo efficiente la DOM visualizzatadal browser. In tal modo vengono renderizzati solamente i componenti che vengonomodificati e non tutta la pagina.

JSX e CSS

Il framework utilizza JSX come linguaggio di markup e uno pseudo CSS per lo stile.Per quanto riguarda JSX il suo scopo è definire una sintassi concisa e familiareper la definizione delle strutture dell’albero con i relativi attributi per ogni nodo.Risulta molto intuitivo in quanto ha una sintassi simil XML ed è facilmente gestibilein quanto possono essere implementate al suo interno funzioni JavaScript.Per gestire lo stile di ogni componente, invece, si utilizza un simil CSS (in formatoJSON) che risulta limitato nelle dichiarazioni. Non è possibile quindi utilizzareestensioni come SCSS e riutilizzare lo stylesheet web per intero.

8.2.2 Valutazione Expo

Il tool di sviluppo per applicazioni in React Native Expo è una tecnologia comple-tamente nuova per l’azienda, consigliata da un consulente esterno. Ho raccolto iprincipali benefici e svantaggi dell’utilizzo di esso.Aspetti positivi:

• semplifica delle operazioni comuni che non sono gestite dai componenti diReact Native introducendo dei nuovi componenti Expo;

• velocizza di molto i tempi di testing su device fisici, in quanto Expo proponebuild automatiche nei propri server che possono essere scaricate su qualsiasidevice tramite un link alla build ;

• riduce la complessità di creazione di file .apk e .ipa in quanto crea le buildnei propri server e gestisce le certificazioni in autonomia.

Aspetti negativi:

• l’interazione tra Expo e React Native Debugger ha riscontrato non pochiproblemi, che causavano spesso l’interruzione dei servizi Expo;

• Expo client risulta ancora molto instabile causando crash dell’applicazione.

38 CAPITOLO 8. CONCLUSIONI

8.3 Valutazione personale dell’esperienza di stageAnche se il mio percorso di studi precedente all’Università non mi ha mai portatoallo studio di discipline informatiche ho deciso di affacciarmi a questo mondo chetanto mi affascinava iscrivendomi al corso di Informatica all’Univesità.Sebbene impegnativo, soprattutto per chi, come me, non aveva conoscenze tecnichepregresse, mi è stato subito chiaro dell’ottima scelta fatta. Nei tre anni di lezioneho potuto apprendere, oltre alle conoscenze tecniche, un metodo di ragionamento,ad affrontare e risolvere problemi, ad analizzare situazioni e dati e, per me impor-tantissimo, ad applicare la mia creatività in tutto ciò.In questo stage di fine percorso mi è stata data la possibilità di mettere in praticatutte le abilità fin ora apprese solo in teoria. Ho potuto dimostrare all’azienda e,soprattutto, a me stessa, di avere le capacità di portare avanti un progetto, di sapergestire il lavoro e di mettere del mio in ogni fase del progetto.Oltre ad avermi dato la carica per affrontare a testa alta il mondo del lavoro miè stato utilissimo per le conoscenze tecniche ottenute. Ho potuto imparare unnuovo linguaggio di programmazione, utilizzato dei framework e librerie utilissimein molti ambiti e ottenuto dimestichezza con vari strumenti di gestione del lavoro.Tutto questo insieme al fatto che ho potuto integrarmi in un team di sviluppo,comprendendo meglio dinamiche e rapporti molti differenti da quelli dell’Università.Sebbene sia ancora alle prime armi ed abbia ancora molto da apprendere mi sentodi dire che l’esperienza di stage è riuscita a far concludere il mio percorso di studidella laurea triennale con entusiasmo, dandomi la carica e la voglia di continuareil percorso di studi affrontando la laurea magistrale in Informatica e, allo stessotempo, continuando il progetto iniziato presso l’azienda.

Appendice A

Descrizione casi d’uso

A.1 UCG - Caso d’uso generale

Figura A.1: UCG - Caso d’uso generale

Attori Primari Utente Zimbra, utente OpenChat e utente Teamworkweb

39

40 APPENDICE A. DESCRIZIONE CASI D’USO

Descrizione L’utente, se dispone della zimlet OpenChat potràinteragire con l’applicazione avendo modo di gestire econtattare la sua buddylist. Se nei suoi server Zimbradispone della zimlet Teamwork web potrà interagireanche con i gruppi di cui fa parte.

Precondizioni Il sistema è avviato e connesso a dei server Zimbrapronti per l’autenticazione;

Postcondizioni Il sistema ha eseguito tutte le funzioni richieste dall’attore permettendogli così di interagire con la suabuddylist e con i gruppi di cui fa parte

Scenario principale 1. L’utente Zimbra vuole accedere all’applicazioneTeamwork per mobile per gestire e comunicare con lasua lista contatti e con i gruppi;2. L’utente OpenChat ha a disposizione la buddylistcon le relative chat in modo da gestire nel modo checrede opportuno la comunicazione con i suoi buddy.

A.2 UC1 - Accesso

Figura A.2: UC1 - Accesso

Attori Primari Utente Zimbra;

Descrizione L’attore si può autenticare inserendo l’e-mail e lapassword con cui è registrato al server Zimbra;

A.4. UC1.2 - INSERIMENTO PASSWORD 41

Precondizioni Il sistema è avviato, pronto per l’utilizzo e mostra lapagina di login;

Postcondizioni Il sistema ha autenticato l’attore e gli mostra la suaarea riservata;

Scenario principale 1. L’attore inserisce l’e-mail con cui è registrato alserver Zimbra);2. L’attore inserisce la sua password;3. L’attore conferma il login e accede alla sua areariservata.

Estensioni Visualizzazione errore login (A.5).

A.3 UC1.1 - Inserimento email


Descrizione L’attore si può autenticare inserendo l’e-mail con cuiè registrato al server Zimbra;


Postcondizioni Il sistema resta in attesa dell’inserimento del-la password da parte dell’attore per continuarel’autenticazione;

Scenario principale 1. L’attore inserisce l’e-mail con cui è registrato alserver Zimbra).

A.4 UC1.2 - Inserimento password


Descrizione L’attore si può autenticare inserendo la password delprofilo Zimbra;



Postcondizioni Il sistema resta in attesa della conferma da partedell’attore per continuare l’autenticazione;

Scenario principale 1. L’attore inserisce la sua password.

A.5 UC2 - Visualizzazione errore login


Descrizione L’attore visualizza un messaggio di errore in quantole credenziali da lui inserite non sono corrette;

Precondizioni L’attore ha cercato di effettuare il login inserendodelle credenziali errate;

Postcondizioni L’attore ha visualizzato il messaggio di errore;

Scenario principale 1. L’attore prova ad autenticarsi inserendo delle cre-denziali errate;2. L’attore visualizza il messaggio di errore;

A.6 UC3 - Visualizzazione buddylist

Figura A.3: UC3 - Visualizzazione buddylist

Attori Primari Utente OpenChat;

Descrizione L’attore può visualizzare l’intera lista dei buddypresenti nella sua buddylist;

A.7. UC3.1 - VISUALIZZAZIONE CARD BUDDY 43

Precondizioni Talkapp presenta all’attore una pagina contenente lalista dei suoi buddy;

Postcondizioni L’attore ha visualizzato la lista dei suoi buddy;

Scenario principale 1. L’attore seleziona l’icona nella tab riguardante labuddylist;2. L’attore visualizza la buddylist contenente tutti isuoi buddy;

A.7 UC3.1 - Visualizzazione card buddy

Figura A.4: UC3.1 - Visualizzazione card buddy


Descrizione L’attore può visualizzare dei dati significativi di ognibuddy presente nella sua buddylist;


Postcondizioni L’attore ha visualizzato per ogni buddy una cardcontenente dei dettagli;


Scenario principale 1. L’attore seleziona l’icona nella tab riguardante labuddylist;2. L’attore visualizza per ogni buddy una card in cuisono presenti dei dettagli;

A.8 UC3.1.1 - Visualizzazione nickname


Descrizione L’attore può visualizzare il nickname dato ad un buddydella sua buddylist;


Postcondizioni L’attore ha visualizzato per ogni buddy il nicknamedato;

Scenario principale 1. L’attore seleziona l’icona nella tab riguardante labuddylist;2. L’attore visualizza il nickname del buddy nella carda esso collegata;

A.9 UC3.1.2 - Visualizzazione immagine profilo


Descrizione L’attore può visualizzare l’immagine profilo di ognibuddy della sua buddylist;


Postcondizioni L’attore ha visualizzato per ogni buddy l’immagineprofilo;

Scenario principale 1. L’attore seleziona l’icona nella tab riguardante labuddylist;2. L’attore visualizza l’immagine profilo del buddynella card a esso collegata;

A.11. UC3.1.4 - VISUALIZZAZIONE DATA ULTIMO MESSAGGIO 45

A.10 UC3.1.3 - Visualizzazione status


Descrizione L’attore può visualizzare lo status di ogni buddy dellasua buddylist;


Postcondizioni L’attore ha visualizzato per ogni buddy il loro status;

Scenario principale 1. L’attore seleziona l’icona nella tab riguardante labuddylist;2. L’attore visualizza lo status del buddy nella card aesso collegata;

A.11 UC3.1.4 - Visualizzazione data ultimo mes-saggio


Descrizione L’attore può visualizzare la data dell’ultimo messaggioscambiato con un particolare buddy della propriabuddylist;


Postcondizioni L’attore ha visualizzato per ogni buddy la datadell’ultimo messaggio scambiato con esso;

Scenario principale 1. L’attore seleziona l’icona nella tab riguardante labuddylist;2. L’attore visualizza la data dell’ultimo messaggioscambiato con un buddy nella card a esso collegata;


A.12 UC3.1.5 - Visualizzazione notifiche


Descrizione L’attore può visualizzare il numero dei messaggi ri-cevuti da un particolare buddy della sua buddylist enon ancora letti;


Postcondizioni L’attore ha visualizzato per ogni buddy il numero deimessaggi ricevuti da esso e non ancora letti;

Scenario principale 1. L’attore seleziona l’icona nella tab riguardante labuddylist;2. L’attore visualizza il numero dei messaggi ricevutoda un particolare buddy e non ancora letti nella carda esso collegata;

A.13 UC4 - Visualizzazione storico chat

Figura A.5: UC4 - Visualizzazione storico chat


Descrizione L’attore può visualizzare lo storico delle conversazioniavute con i suoi buddy;


Postcondizioni L’attore ha visualizzato la lista dei messaggi scambiaticon un particolare buddy;

A.15. UC4.2 - VISUALIZZAZIONE MESSAGGI INVIATI 47

Scenario principale 1. L’attore seleziona un buddy dalla sua buddylist;2. L’attore visualizza la lista dei messaggi scambiatinel tempo con il buddy selezionato;

A.14 UC4.1 - Visualizzazione messaggi ricevuti


Descrizione L’attore può visualizzare i messaggi ricevuti da unparticolare buddy;


Postcondizioni L’attore ha visualizzato la lista dei messaggi ricevutida un particolare buddy;

Scenario principale 1. L’attore seleziona un buddy dalla sua buddylist;2. L’attore visualizza la lista dei messaggi ricevuti neltempo dal buddy selezionato;

A.15 UC4.2 - Visualizzazione messaggi inviati


Descrizione L’attore può visualizzare i messaggi inviati ad unparticolare buddy;


Postcondizioni L’attore ha visualizzato la lista dei messaggi inviatiad un particolare buddy;

Scenario principale 1. L’attore seleziona un buddy dalla sua buddylist;2. L’attore visualizza la lista dei messaggi inviati neltempo al buddy selezionato;


A.16 UC5 - Invio messaggi


Descrizione L’attore può inviare messaggi ad un buddy;

Precondizioni Talkapp presenta all’attore una pagina contenente lostorico delle conversazioni avute con un particolarebuddy;

Postcondizioni L’attore ha inviato un messaggio ad un buddy;

Scenario principale 1. L’attore seleziona un buddy dalla sua buddylist;2. L’attore digita un messaggio nel box apposito;3. L’attore preme il pulsante di fianco al box perconfermare l’invio; 4. Il messaggio appare nello storicodella chat.

A.17 UC6 - Modifica buddylist


Descrizione L’attore può modificare la buddylist visualizzata;

Precondizioni Talkapp presenta all’attore una pagina contenente lalista dei suoi buddy

Postcondizioni L’attore ha modificato la buddylist che vienevisualizzata;

Scenario principale 1. L’attore seleziona un buddy da rimuovere o digitaun contatto da aggiungere;2. L’attore conferma di voler cambiare la buddylisttramite l”azione svolta;

A.18 UC7 - Aggiunta buddy


A.20. UC9 - RICERCA BUDDY 49

Descrizione L’attore può aggiungere un nuovo buddy alla suabuddylist;

Precondizioni Talkapp presenta all’attore una pagina contenente unform per l’aggiunta di un buddy;

Postcondizioni L’attore ha aggiunto un buddy alla sua buddylist;

Scenario principale 1. L’attore inserisce il nickname che vuole dare albuddy;2. L’attore inserisce l’e-mail del buddy che vuoleaggiungere;3. L’attore conferma l’aggiunta del buddy alla propriabuddylist.

A.19 UC8 - Rimozione buddy


Descrizione L’attore può rimuovere un buddy dalla sua buddylist;

Precondizioni Talkapp presenta all’attore una pagina contenente idettagli del buddy selezionato e le azioni che possonoessere svolte;

Postcondizioni L’attore ha rimosso il buddy dalla sua buddylist;

Scenario principale 1. L’attore seleziona il buddiy dalla buddylist chevuole rimuovere;2. L’attore seleziona la voce "Rimozione" dal menùdi azioni disponibili;3. L’attore conferma la rimozione del buddy dallapropria buddylist.

A.20 UC9 - Ricerca buddy


Descrizione L’attore può ricercare un buddy tra quelli presentinella sua buddylist;


Precondizioni Talkapp presenta all’attore una pagina contenente uncampo di ricerca per ricercare un buddy in base adun certo testo;

Postcondizioni L’attore ha ricercato un buddy dalla sa buddylist inbase ad un testo da lui inserito;

Scenario principale 1. L’attore inserisce dei caratteri nel campo di ricerca;2. L’attore visualizza i buddy corrispondenti allaricerca da lui effettuata;

A.21 UC10 - Modifica status


Descrizione L’attore può modificare lo status con cui vienevisualizzato dagli altri utenti;

Precondizioni Talkapp presenta all’attore una pagina contenente unelenco degli statusdis ponibili;

Postcondizioni L’attore ha modificato lo status con cui vienevisualizzato dagli altri utenti;

Scenario principale 1. L’attore seleziona uno status tra quelli disponibili;2. L’attore conferma di voler cambiate status conquello selezionato;

A.22 UC11 - Modifica tema


Descrizione L’attore può modificare il tema dei colori con cuivisualizza l’applicazione;

Precondizioni Talkapp presenta all’attore una pagina contenente unelenco con tutti i temi disponibili;

Postcondizioni L’attore ha modificato il tema dell’applicazione;

A.23. UC12 - VISUALIZZAZIONE GRUPPI 51

Scenario principale 1. L’attore seleziona un tema tra quelli disponibili daapplicare2. L’attore conferma di voler applicare quel tema;

A.23 UC12 - Visualizzazione gruppi

Attori Primari Utente Teamwork web;

Descrizione L’attore può visualizzare l’elenco dei gruppi di cui faparte;

Precondizioni Talkapp presenta una pagina contenente i gruppi dicui fa parte;

Postcondizioni L’attore ha visualizzato i gruppi di cui fa parte;

Scenario principale 1. L’attore seleziona l’icona nella tab riguardante igruppi;2. L’attore visualizza i gruppi di cui fa parte;

Glossario

agile Modelli di ciclo di vita del software che nascono come reazione alla tropparigidità degli altri modelli, puntano sul soddisfacimento del cliente piuttostoche sulla pianificazione e qualità del software. 5

analisi statica Tecnica di analisi che valuta il sistema o un suo componente basan-dosi sulla forma, sul contenuto e sulla struttura permettendo di individuareanomalie all’interno di documenti e codice sorgente. 14

Android sistema operativo per dispositivi mobili sviluppato da Google Inc. ebasato sul kernel Linux. È stato progettato principalmente per smartphone etablet. 9

Android Studio Ambiente di sviluppo integrato per lo sviluppo per la piattaformaAndroid distribuito sotto licenza Apache 2.0. 12

architettura Organizzazione fondamentale di un sistema, definita dai suoi compo-nenti, dalle relazioni reciproche tra i componenti e con l’ambiente, e i principiche ne governano la progettazione e l’evoluzione. 23

backup Operazione di salvataggio su una qualunque memoria di massa dei dati diun utente archiviati nella memoria di un computer. 5

bug In italiano "baco", identifica un errore nella scrittura del codice sorgenteche porta a comportamente anomali e non previsti del programma. Un bugpuò essere introdotto anche in fase di compilazione o di progettazione delprogramma.. 7

continuous integration Pratica di sviluppo che richiede agli sviluppatori di inte-grare il codice in un repository condiviso più volte al giorno. Ogni check-inviene quindi verificato da una build automatizzata, consentendo al team dirilevare i problemi in anticipo. 7

crossplatform Applicazione software, linguaggio di programmazione o un disposi-tivo hardware che funziona su più di un sistema o piattaforma. v

deployment Rilascio al cliente di un sistema software o di un’applicazione.. 7

design pattern Soluzione progettuale generale ad un problema ricorrente. 25

53

54 Glossary

framework Architettura logica di supporto (spesso un’implementazione logica diun particolare design pattern) su cui un software può essere costruito perfacilitarne lo sviluppo da parte del programmatore. 9

git Software per il controllo di versione distribuito con interfaccia a riga di comandosviluppato da Linus Torvalds nel 2005. 7

guidelines Insieme di raccomandazioni sviluppate sistematicamente, sulla basedi conoscenze continuamente aggiornate e valide, redatto allo scopo di ren-dere appropriato, e con un elevato standard di qualità, un comportamentodesiderato. 9

iOS Sistema operativo sviluppato da Apple per iPhone, iPod touch e iPad. 9

mock Oggetto simulato che riproduce il comportamento dell’oggetto reale in modocontrollato. 32

open source Movimento per cui gli autori di un software o i detentori dei suoidiritti rendono pubblico il codice sorgente, favorendone il libero studio e per-mettendo a programmatori indipendenti di apportarvi modifiche ed estensioni.3

pattern architetturale Schemi di base per impostare l’organizzazione strutturaledi un sistema software, si descrivono i sottosistemi predefiniti con i ruoli cheessi assumono e le relazioni reciproche. 14

processo Insieme di attività collegate tra loro che trasformano ingressi in uscitesecondo regole fissate e tramite risorse limitate. 6

prototipo Rappresenta la creazione di quello che sarà verosimilmente il prodottofinale. 9

React Native Libreria JavaScript utilizzata per la realizzazione di interfacceutente per applicazioni mobili. v

release Specifica versione di un software resa disponibile ai suoi utenti finali. 6

repository Archivio nel quale sono raccolti e conservati dati e informazioni cor-redati da descrizioni (metadati) che li rendono identificabili dagli utenti.7

requisito È una caratteristica che deve avere il software per soddisfare un certobisogno del cliente. Descrive cosa il sistema deve fare, i servizi che offre e ivincoli sul suo funzionamento. 6

stack trace Elenco ordinato delle funzioni eseguite dal software. 7

stakeholder Soggetto che possiede un’interesse nei confronti di un progetto e chepuò influenzarne l’attività. 6

Glossary 55

storage Dispositivi hardware, supporti per la memorizzazione, infrastrutture esoftware dedicati alla memorizzazione non volatile di grandi quantità diinformazioni in formato elettronico. 4

unit testing Attività di testing di singole unità software, il minimo componentedi un programma dotato di funzionamento autonomo. 16

versionamento Consiste nel tenere traccia degli stati che può assumere il progettodurante il suo sviluppo, diverso funzionalmente da un’altra versione. 7

wireframe Rappresenta il modello iniziale di rappresentazione di un sito web che halo scopo di identificare la struttura del sito web, l’architettura dell’informazionee la disposizione degli elementi nella pagina. 10

xCode Ambiente di sviluppo integrato progettato da Apple contenente una suitedi strumenti utili allo sviluppo di software per i sistemi macOS, iOS, watchOSe tvOS. 12

Acronimi

DOM Document Object Model. 37

GUI Grafical User Interface. 27

HTTP HyperText Transfer Protocol. 24

IDE Integrated Development Environment. 12

JSON JavaScript Object Notation. 25

SDK Software Development Kit. 12

SMTP Simple Mail Transfer Protocol. 24

SOAP Simple Object Access Protocol. 23

UI User Interface. 27

UML Unified Modeling Language. 2

UX User Experience. 9

XML eXtensible Markup Language. 24

57

Bibliografia

Siti Web consultatiExpo documentation. url: https://docs.expo.io/versions/latest/.

Flux. url: http://facebook.github.io/flux/.

Jest documentation. url: https://jestjs.io/docs/en/getting-started.

Manifesto Agile. url: http://agilemanifesto.org/iso/it/.

React Native documentation. url: https://facebook.github.io/react-native/docs/getting-started.

Redux. url: https://redux.js.org.

Repository zimlet OpenChat. url: https://github.com/ZeXtras/OpenChat.

Use React Native. url: http://www.reactnative.com/.

59

https://docs.expo.io/versions/latest/

http://facebook.github.io/flux/

https://jestjs.io/docs/en/getting-started

http://agilemanifesto.org/iso/it/

https://facebook.github.io/react-native/docs/getting-started

https://facebook.github.io/react-native/docs/getting-started

https://redux.js.org

https://github.com/ZeXtras/OpenChat

http://www.reactnative.com/

teamwork: unaapplicazionemobile perzextrassuite

Documents