Teamwork: una applicazione mobile per Zextras Suite - Università degli Studi di Padova Dipartimento di Matematica - SIAGAS
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Università degli Studi di Padova
Dipartimento di Matematica
Corso di Laurea in Informatica
Teamwork: una applicazione mobile
per Zextras Suite
Relatore Laureando
Prof. Francesco Ranzato Lisa Parma
A.A. 2017-2018
Lisa Parma: Teamwork: una applicazione mobile per Zextras Suite, Tesi di laurea triennale, c 27 Settembre 2018.
Ringraziamenti
Ringrazio il Prof. Francesco Ranzato, relatore della mia tesi, per avermi seguito
durante la stesura del lavoro.
Desidero ringraziare con affetto i miei genitori, mia sorella Anna e mia nonna Tina
per il sostegno, il grande aiuto e per essermi stati vicini in ogni momento durante
gli anni di studio.
Ringrazio mio nonno Mirco che ha sempre creduto in me e nel raggiungimento di
questo 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 di
Zextras S.r.l., che mi hanno permesso di vivere questa bella esperienza in un settore
dell’informatica così interessante.
Infine, non posso non ringraziare i miei amici e compagni di corso per tutti i
bellissimi 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 Lisa Parma svolto presso l’azienda Zextras s.r.l. nel periodo tra il 25 giugno 2018 e il 24 agosto 2018 della durata di circa 320 ore. Tale stage prevedeva lo sviluppo di un’applicazione mobile crossplatformg per la messaggistica in React Nativeg , allineandone l’implementazione alla soluzione web OpenChat già sviluppata dall’azienda.
Indice
1 Introduzione 1
1.1 Organizzazione dell’elaborato . . . . . . . . . . . . . . . . . . . . . 1
1.2 Convenzioni adottate . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Azienda ospitante 3
2.1 Profilo dell’azienda . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1 Zimbra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2 Zextras Suite . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Metodo di lavoro . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.2 Strumenti a supporto di processi e servizi . . . . . . . . . . . 6
3 Il progetto 9
3.1 Presentazione progetto . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Interesse aziendale . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3 Piano di lavoro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4 Pianificazione di progetto . . . . . . . . . . . . . . . . . . . . . . . . 10
4 Tecnologie utilizzate 11
4.1 Ambiente di sviluppo . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.1 Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.2 IntelliJ IDEA . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.3 Expo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2 Linguaggi, librerie e strumenti di programmazione . . . . . . . . . . 13
4.2.1 React Native . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.2 TypeScript . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.3 TSLint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.4 Redux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3 Strumenti di verifica e valutazione . . . . . . . . . . . . . . . . . . . 15
4.3.1 Genymotion . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3.2 React Native Debugger . . . . . . . . . . . . . . . . . . . . . 16
4.3.3 Jest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5 Analisi dei requisiti 19
5.1 Attori coinvolti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1.1 Attori principali . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1.2 Attori secondari . . . . . . . . . . . . . . . . . . . . . . . . . 19
viiviii INDICE
5.2 Casi d’uso principali . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.3 Requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.3.1 Principali requisiti funzionali . . . . . . . . . . . . . . . . . . 21
5.3.2 Requisiti di vincolo . . . . . . . . . . . . . . . . . . . . . . . 22
5.3.3 Requisiti di qualità . . . . . . . . . . . . . . . . . . . . . . . 22
6 Progettazione e codifica 23
6.1 Progettazione architetturale e di dettaglio . . . . . . . . . . . . . . 23
6.1.1 Architettura OpenChat . . . . . . . . . . . . . . . . . . . . . 23
6.1.2 Gestione eventi . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.1.3 Store Redux . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.2 Progettazione grafica . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2.1 Wireframe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2.2 Linee guida . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.3 Interfaccia grafica con React Native . . . . . . . . . . . . . . . . . . 29
7 Verifica e Validazione 31
7.1 Linter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.2 Jest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.2.1 Component snapshot . . . . . . . . . . . . . . . . . . . . . . 32
7.2.2 Redux snapshot . . . . . . . . . . . . . . . . . . . . . . . . . 32
7.3 Test di sistema e collaudo . . . . . . . . . . . . . . . . . . . . . . . 32
7.3.1 Emulatori . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.3.2 Device fisici . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.3.3 Beta testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
8 Conclusioni 35
8.1 Valutazione del prodotto finale . . . . . . . . . . . . . . . . . . . . . 35
8.2 Valutazione framework e librerie utilizzate . . . . . . . . . . . . . . 36
8.2.1 Valutazione React Native . . . . . . . . . . . . . . . . . . . 36
8.2.2 Valutazione Expo . . . . . . . . . . . . . . . . . . . . . . . . 37
8.3 Valutazione personale dell’esperienza di stage . . . . . . . . . . . . 38
A Descrizione casi d’uso 39
A.1 UCG - Caso d’uso generale . . . . . . . . . . . . . . . . . . . . . . . 39
A.2 UC1 - Accesso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
A.3 UC1.1 - Inserimento email . . . . . . . . . . . . . . . . . . . . . . . 41
A.4 UC1.2 - Inserimento password . . . . . . . . . . . . . . . . . . . . . 41
A.5 UC2 - Visualizzazione errore login . . . . . . . . . . . . . . . . . . . 42
A.6 UC3 - Visualizzazione buddylist . . . . . . . . . . . . . . . . . . . . 42
A.7 UC3.1 - Visualizzazione card buddy . . . . . . . . . . . . . . . . . . 43
A.8 UC3.1.1 - Visualizzazione nickname . . . . . . . . . . . . . . . . . . 44
A.9 UC3.1.2 - Visualizzazione immagine profilo . . . . . . . . . . . . . . 44
A.10 UC3.1.3 - Visualizzazione status . . . . . . . . . . . . . . . . . . . . 45
A.11 UC3.1.4 - Visualizzazione data ultimo messaggio . . . . . . . . . . . 45
A.12 UC3.1.5 - Visualizzazione notifiche . . . . . . . . . . . . . . . . . . 46
A.13 UC4 - Visualizzazione storico chat . . . . . . . . . . . . . . . . . . . 46INDICE ix A.14 UC4.1 - Visualizzazione messaggi ricevuti . . . . . . . . . . . . . . . 47 A.15 UC4.2 - Visualizzazione messaggi inviati . . . . . . . . . . . . . . . 47 A.16 UC5 - Invio messaggi . . . . . . . . . . . . . . . . . . . . . . . . . . 48 A.17 UC6 - Modifica buddylist . . . . . . . . . . . . . . . . . . . . . . . . 48 A.18 UC7 - Aggiunta buddy . . . . . . . . . . . . . . . . . . . . . . . . . 48 A.19 UC8 - Rimozione buddy . . . . . . . . . . . . . . . . . . . . . . . . 49 A.20 UC9 - Ricerca buddy . . . . . . . . . . . . . . . . . . . . . . . . . . 49 A.21 UC10 - Modifica status . . . . . . . . . . . . . . . . . . . . . . . . . 50 A.22 UC11 - Modifica tema . . . . . . . . . . . . . . . . . . . . . . . . . 50 A.23 UC12 - Visualizzazione gruppi . . . . . . . . . . . . . . . . . . . . . 51 Glossary 53 Acronyms 57 Bibliografia 59
Elenco delle figure
2.1 Logo Zextras s.r.l. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Logo Zimbra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Rappresentazione Zextras suite . . . . . . . . . . . . . . . . . . . . 5
4.1 Logo Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2 Logo IntelliJ IDEA . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3 Logo Expo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.4 Logo React Native . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.5 Logo TypeScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.6 Logo TS Lint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.7 Logo Redux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.8 Flusso dei dati in Flux . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.9 Logo Genymotion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.10 Logo React Native Debugger . . . . . . . . . . . . . . . . . . . . . . 16
4.11 Logo Jest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1 Casi d’uso principali . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1 Architettura OpenChat . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.2 Gestione eventi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.3 Struttura messaggio SOAP . . . . . . . . . . . . . . . . . . . . . . . 24
6.4 Redux store utilizzato per gestire Teamwork . . . . . . . . . . . . . 26
6.5 Wireframe pagina di login, buddylist e chat page. . . . . . . . . . . 27
6.6 Esempio guidelines spazi . . . . . . . . . . . . . . . . . . . . . . . . 28
6.7 Relazione tra screen . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.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 . . . . . . . . . . . . . . . . . . . . . . . 39
A.2 UC1 - Accesso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
A.3 UC3 - Visualizzazione buddylist . . . . . . . . . . . . . . . . . . . . 42
A.4 UC3.1 - Visualizzazione card buddy . . . . . . . . . . . . . . . . . . 43
A.5 UC4 - Visualizzazione storico chat . . . . . . . . . . . . . . . . . . . 46
xELENCO DELLE TABELLE xi Elenco delle tabelle 3.1 Pianificazione sprint . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1 Requisiti funzionali . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.2 Requisiti di vincolo . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.3 Requisiti di qualità . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Capitolo 1
Introduzione
1.1 Organizzazione dell’elaborato
Questo elaborato è organizzato come segue:
• Capitolo 1: descrizione della struttura del documento e delle convenzioni
adottate nella stesura dello stesso;
• Capitolo 2: introduzione dell’azienda ospitante, dei suoi prodotti nel mercato
e 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 adottate
durante 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’applicazione
prodotta, che sul lavoro svolto e il periodo di stage in generale.
1.2 Convenzioni adottate
Nella stesura del presente documento sono state adottate le seguenti convenzioni
tipografiche:
• la prima occorrenza di termini tecnici, ambigui o di acronimi verrà marcata
in corsivo e con una “g” a pedice, in modo da indicare la sua presenza nel
glossario, riportato in fondo al presente documento;
• i termini tecnici in lingua inglese non traducibili e non presenti nel glossario,
verranno evidenziati in corsivo;
12 CAPITOLO 1. INTRODUZIONE
• la prima occorrenza di un acronimo viene riportata con la dicitura estesa, in
corsivo, 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 o
codice verrà marcato utilizzando un font a larghezza fissa;
• i diagrammi Unified Modeling Language (UML) sono espressi seguendo lo
standard 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’azienda
Zextras s.r.l. nella sede di Torri Di Quartesolo (VI).
Questa società è nata nel 2011 con l’obbiettivo di espandere le possibilità della
suite 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 Collaboration
che migliorano i servizi già presenti e offrono funzionalità importanti per un uso
lavorativo 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 collaborazione
sul mercato. I loro prodotti sono riconosciuti come ottimali anche dall’azienda
proprietaria Synacor, la quale ha portato ad una cooperazione per lo sviluppo di
alcuni 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.
34 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 suite
di 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 e
attraverso i client di posta elettronica tradizionale, è possibile accedere alle
e-mail, ai calendari e alle altre offerte da dispositivi mobile.
Le funzionalità di Zimbra possono essere facilmente estese grazie alla possibilità di
creare ed aggiungere degli add-on chiamati zimlet . Esse sono delle integrazioni
che permettono di personalizzare i servizi ed integrarli con servizi web e applicazioni
di terzi.
Zimbra è disponibile in due versioni:
• Zimbra Open Source Edition: soluzione completamente open source, che
offre un insieme ristretto di funzionalità standard;
• Zimbra Network Edition: soluzione completa di tutte le funzionalità sia
per 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 stante
rispetto i moduli Zimbra Network Edition. Infatti Zextras Suite non è distribuito
assieme ad alcun binario o sorgente sotto il copyright di Zimbra.
Le principali innovazioni che sono state portate nel mondo Zimbra riguardano la
sicurezza 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 salvataggio
dei 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 e
remoti, così da ottimizzare i volumi dei dati Zimbra e risparmiare spazio
attraverso la compressione e la deduplicazione;
• Zextras Admin: interfaccia amministrativa avanzata per monitorare gli
utenti 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 per
Zimbra Open Source che può essere applicata secondo le proprie esigenze. Proprio
per questo risulta la migliore scelta per un uso professionale di Zimbra.
2.2 Metodo di lavoro
La necessità di sviluppare progetti particolarmente complessi che si unisce all’esigen-
za di mantenere una certa flessibilità e trasparenza, ha portato l’azienda a preferire
l’utilizzo di un ciclo di sviluppo del software di tipo agileg , rispetto a metodi di
management più tradizionali incentrati sui processi di sviluppo ma non reattivi
ai 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 la
caratterizzano.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 alla
pianificazione.
Questi principi sono ampiamente condivisi dalla compagine aziendale, la quale basa
lo sviluppo dei propri prodotti sulla continua interazione con gli stakeholderg e con
i clienti.
2.2.1 Scrum
In particolare viene utilizzato il metodo Scrum, che oltre ad essere uno dei sistemi
più diffusi, è particolarmente adatto a progetti complessi ed innovativi.
Lo Scrum prevede un modello di sviluppo iterativo nel quale ogni ciclo viene
definito sprint: esso è un periodo di tempo, solitamente di durata compresa tra 1
a 4 settimane, nel quale viene prefissata una lista di requisitig e funzionalità che
devono essere implementate in tale periodo. Questa lista di funzionalità e requisiti
viene definita prima in una Product Backlog, documento che contiene tutti i requisiti
necessari per la realizzazione del progetto, e poi, periodicamente, in una Sprint
Backlog, documento nel quale vengono definiti tutti i task da completare nei singoli
sprint. L’azienda prevede sprint di due settimane e la fine di ognuno di essi coincide
con una releaseg del software. Per gestire al meglio sprint e backlog di ogni progetto
vengono eseguite delle riunioni periodiche di diverse tipologie:
• Sprint Planning: riunione che precede l’inizio del progetto in cui si stila la
Product Backlog e si determina il numero e la durata degli sprint in base al
tempo a disposizione e agli obiettivi. Viene inoltre definita la Sprint Backlog
per il primo sprint;
• Daily Scrum: breve confronto giornaliero che permette di sincronizzare i
lavoro di tutto il team e di affrontare tempestivamente i problemi riscontrati;
• Sprint Review: revisione al termine di ogni sprint che serve a valutare se gli
obiettivi prefissati sono stati completati in modo esaustivo o se è necessario
modificare 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 atti
al miglioramento dello sviluppo del software, della gestione dei progetti e della
collaborazione.2.2. METODO DI LAVORO 7 BitBucket Server Per il versionamentog del software viene utilizzato BitBucket Server, un servizio di self-hosting per repositoryg Gitg e per il controllo delle versioni. Permette di eseguire tutte 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’accesso può essere differenziato per utente o per gruppi. BitBucket Server, essendo un servizio di self-hosting, ha la particolarità di poter essere eseguito nei server locali così da preservare la riservatezza del proprio codice. Inoltre permette l’integrazione con altri strumenti sviluppati dall’azienda Atlassian, tra i quali Jira, Bamboo e Confluence. Jira Jira è un prodotto di isseue-tracking che fornisce funzionalità quali tracciamento dei bugg , rilevamento dei problemi e gestione di progetti. Questo software permettere di scegliere il tipo di ciclo di sviluppo con cui si preferisce gestire il progetto: nel caso dell’azienda Zextras si adatta perfettamente alla metodologia di lavoro scelta e al sistema Scrum, in quanto permette di gestire al meglio gli sprint e le relative backlog. Bamboo Bamboo è un server sviluppato da Atlassian per la continuous integrationg e deploymentg . Tra le varie funzionalità, permette di eseguire più build in parallelo, per un completamento più rapido, e in caso di errori di compilazione fornisce un’analisi di quest’ultimi, inclusa la stack traceg . Confluence Confluence è un software di collaborazione per la creazione di documenti che permette di creare, organizzare e lavorare su materiale condiviso. Permette di centralizzare le informazioni, tenere traccia di ogni modifica e, inoltre, supporta una 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 progettazione
e nello sviluppo di un prototipog di applicazione chat per dispositivi mobili. Le
funzionalità che il prodotto doveva presentare devevano essere allineate a quelle
della soluzioni già implementate in ambiente web (zimlet OpenChat e zimlet Team-
work ). Per quanto riguarda la parte grafica, l’applicazione doveva rispettare lo stile
dell’omonimo modulo Teamwork, che si trova ora in fase di riprogettazione da parte
dell’azienda.
Tale prodotto è stato sviluppato utilizzando il frameworkg React Native, ed è stato
reso disponibile sia per sistemi Androidg che iOSg .
3.2 Interesse aziendale
L’applicazione Teamwork sviluppata si appoggerà al software OpenChat 1 , modulo
open source sviluppato da Zextras disponibile come zimlet su Zimbra, che richiede
l’installazione di Zextras core. L’obbiettivo dell’azienda era di ottenere al termine
dello stage un prototipo con almeno le funzionalità base di OpenChat su mobile, in
modo tale da:
• verificare l’effettiva utilità del progetto;
• studiare le migliori soluzioni progettuali per un’ambito ancora inesplorato
dall’azienda, poiché differente da quello dei prodotti già sviluppati;
• validare le tecnologie utilizzate e, eventualmente, proporre nuovi framework
di sviluppo;
• ampliare e/o modificare le proprie User Experience (UX) guidelinesg in base
alle differenze tra dispositivi mobile e desktop.
1
https://github.com/ZeXtras/OpenChat
910 CAPITOLO 3. IL PROGETTO
3.3 Piano di lavoro
Il progetto di stage proposto dall’azienda è stato sviluppato da due stagisti e
prevedeva 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 formazione
sulle tecnologie da utilizzare per il progetto, quali React Native ed Expo, con
le quali anche l’azienda ospitante si interfaccia per la prima volta;
• Progettazione UX (40h): studio e realizzazione di alcuni wireframeg dell’app
prendendo spunto dall’attuale sistema di chat sviluppato per il web;
• Progettazione architetturale (40h): progettazione dell’architettura client/server
necessaria per l’implementazione dell’applicazione seguendo le bozze dell’UX;
• Implementazione (200h): sviluppo dell’applicazione con lo scopo di raggiungere
un prototipo funzionante.
3.4 Pianificazione di progetto
In seguito al periodo di formazione è stato pianificato in maggior dettaglio il lavoro
da svolgere. Le otto settimane di stage sono state suddivise in quattro sprint di
due settimane ognuno, riuscendo così a sincronizzare lo sviluppo dell’applicazione
con gli sprint degli altri progetti seguiti dall’azienda.
Al fine di seguire il metodo lavorativo aziendale, è stata associata una versione di
release del prototipo per ognuno dei quattro sprint decisi.
I quattro sprint sono stati così suddivisi:
Sprint Inizio Fine Release
I 25/06/18 06/07/18 Alpha1
II 09/07/18 20/07/18 Alpha2
III 23/07/18 03/08/18 Beta
IV 06/08/18 24/08/18 RC
Tabella 3.1: Pianificazione sprintCapitolo 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 applicazione
all’interno di container. Questi ultimi forniscono una virtualizzazione a livello del
sistema operativo Linux senza che sia necessario istanziare delle macchine virtuali
pienamente operative. I container sono assimilabili a delle macchine virtuali
modulari con la peculiarità di essere molto leggere: in questo modo risulta più facile
creare, distribuire, copiare e spostare i container da un ambiente all’altro. Ogni
container è 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 con
le caratteristiche specificate.
Per sviluppare l’applicazione Teamwork è stato utilizzato Docker 18.03 Community
Edition per Ubuntu Bionic. In questo modo è stato possibile avviare nelle macchine
locali un container di Zimbra e del core Zextras con la zimlet OpenChat caricata
così da sviluppare l’applicativo in un ambiente controllato.
1112 CAPITOLO 4. TECNOLOGIE UTILIZZATE
4.1.2 IntelliJ IDEA
Figura 4.2: Logo IntelliJ IDEA
IntelliJ IDEA è un Integrated Development Environment (IDE) multi-linguaggio e
multi-piattaforma. È stata utilizzata l’edizione Ultimate in quanto era necessario un
editor che supportasse JavaScript/TypeScript, mentre la Community Edition non
supporta questi linguaggi. Dovendo creare un’applicazione con numerose riferimenti
al codice della zimlet OpenChat e di Zimbra sono state sfruttate al meglio le
funzionalità per l’analisi del codice e comprendere le dipendenze esistenti.
Questo IDE non è stato imposto dall’azienda, ma è stato scelto personalmente per
lo sviluppo dell’applicazione, in quanto avevo già dimestichezza con esso ed è stato
consigliato 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 React
Native utilizzando il Software Development Kit (SDK) di Expo. L’SDK Expo è
una libreria nativa e JavaScript che fornisce l’accesso alle funzionalità del sistema
del dispositivo (come la fotocamera, i contatti, la memoria locale) senza il bisogno di
utilizzare xCodeg o Android Studiog , né di utilizzare codice nativo. Fornisce l’accesso
a servizi che in genere sono difficili da gestire nativamente, ma sono richiesti da quasi
tutte le app come le notifiche push o creare binari nativi pronti per la distribuzione
nell’app store. Inoltre semplifica e velocizza le fasi di sviluppo e di testing in quanto
permette l’avvio di build automatiche nei loro server che permettono di eseguire in
real-time il codice sia in simulatori che in dispositivi mobili. L’utilizzo di questo
tool è stato un requisito obbligatorio del progetto. La validazione di Expo è infatti
uno degli scopi dello stage, in quanto l’azienda vorrebbe implementarla nei suoi
progetti 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 JavaScript
che permette di unificare l’esperienza di sviluppo su diversi sistemi operativi. Infatti
React Native utilizza le stesse componenti dell’interfaccia utente che vengono utiliz-
zate da app native iOS e Android. Si possono comunque integrare dei componenti
scritti in Objective-C, Java o Swift così da utilizzare il codice nativo nel caso
fosse 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 di
sviluppo atomico risulta perfetto per effettuare Unit Test o per creare componenti
più complessi includendone di più semplici.
4.2.2 TypeScript
Figura 4.5: Logo TypeScript
TypeScript è un linguaggio di programmazione sviluppato da Microsoft che estende
la sintassi di JavaScript. È nato per poter utilizzare le funzionalità di JavaScript
per lo sviluppo di grandi applicazioni in quanto aumenta la sicurezza e la robustezza
del codice tramite l’aggiunta di classi, interfacce, moduli, tipizzazione e altre
funzionalità importanti per la comprensione di un grande progetto. Il codice
TypeScript sviluppato viene successivamente ricompilato in JavaScript per poter
essere 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 imparare
un nuovo linguaggio che può portare grandi benefici soprattutto, in termini di
chiarezza.14 CAPITOLO 4. TECNOLOGIE UTILIZZATE
4.2.3 TSLint
Figura 4.6: Logo TS Lint
TSLint è uno strumento di analisi staticag per il codice scritto in TypeScript che
offre funzionalità estendibili e personalizzabili per la leggibilità, la manutenibilità e
gli errori di programmazione. È supportato da molti dei moderni editor, compreso
IntelliJ IDEA (sez. 4.1.2), utilizzato per il progetto.
In parallelo con TypeScript, l’utilizzo di TSLint non è stato obbligatorio ma data
la scelta di utilizzare un nuovo linguaggio ho preferito utilizzare questo linter, per
essere 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 delle
applicazioni web. In ReactJS e React Native ogni componente possiede uno stato
che può cambiare durante il suo ciclo di vita. Questo stato è interno ad ogni singola
componente ed è difficile, a volte impossibile, la comunicazione di questi dati tra
componenti diverse. Redux, invece, permette la creazione di uno store condiviso,
accessibile da tutte le componenti. In tal modo è possibile sincronizzare le modifiche
e quindi avere dei dati coerenti tra le varie componenti. Nella zimlet OpenChat
era già stata utilizzata questa tecnologia e volendo sia sincronizzare i dati, sia
mantenere la struttura il più simile possibile, si è voluto continuare ad usare questa
soluzione, anche perché è l’unico modo per gestire in maniera semplice un numero
di dati ampio e in continuo cambiamento. Redux è stato implementato basandosi
su una particolare architettura: Flux.
Flux
Flux è un pattern architetturaleg che ha ispirato Redux, utilizzato per la creazione
di applicazioni web client-side. Esso utilizza un flusso di dati unidirezionale per4.3. STRUMENTI DI VERIFICA E VALUTAZIONE 15
gestire al meglio la sincronizzazione degli stati tra le componenti React, in modo
da garantire che lo stato dello store sia sempre uguale in tutte le componenti che
compongono la view.
Figura 4.8: Flusso dei dati in Flux
Il flusso parte da degli oggetti stores, i quali contengono i dati dell’applicazione
che vengono forniti ai vari componenti in modo che la view sia sempre aggiornata
con 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 lo
utilizzano 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 perfettamente
con Expo(sez. 4.1.3) ed è utilizzato per la gestione di questo progetto, permettendo
di avere un riscontro dell’app in real-time durante lo sviluppo e di verificare e
testare l’applicazione su più device. Emula più di 3000 configurazioni virtuali di
dispositivi Android (tra versioni, dimensioni schermo, capacità hardware, ecc..).16 CAPITOLO 4. TECNOLOGIE UTILIZZATE
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 React
Native. Si basa sul remote debugger disponibile quando si monitora un progetto in
un device fisico o virtuale. Esso offre vari strumenti per il debug:
• React Inspector, per ispezionare il layout e lo style di ogni componente
dell’app;
• Redux DevTools, per monitorare gli store Redux utilizzati e le action svolte
su di essi;
• Console, per visualizzare errori e avvisi che avvengono durante l’esecuzione
del 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 da
Facebook per testare le proprie applicazioni in React. È una soluzione completa e
pronta all’utilizzo, in quanto è automaticamente configurata alla creazione di un
nuovo progetto React Native. Rispetto ad altri framework di unit testing offre dei
vantaggi, 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 codice da testare che i test stessi possono essere scritti in TypeScript, linguaggio utilizzato per questo progetto.
Capitolo 5
Analisi dei requisiti
5.1 Attori coinvolti
Durante l’attività di analisi dei requisiti sono stati individuati quattro attori capaci
di interagire attivamente con l’applicazione Teamwork. Di questi tre sono attori
principali, mentre uno è un attore secondario.
5.1.1 Attori principali
Utente Zimbra
L’applicazione è destinata solamente agli utenti Zimbra. Ciò implica che si possa
accedere alle funzionalità di Teamwork esclusivamente se si è già in possesso di
un’email Zimbra gestita dai loro server. Tale scenario è rappresentato dall’attore
più generico.
Utente OpenChat
Un utente OpenChat, specializzazione dell’utente Zimbra, rappresenta un utente
che utilizza un’istanza di Zimbra con la zimlet OpenChat installata. Quest’ultima
permette di chattare con gli utenti Zimbra dello stesso server.
Utente Teamwork web
Un utente Teamwork web, specializzazione dell’utente OpenChat, rappresenta un
utente che, oltre ad utilizzare un’istanza di Zimbra con la zimlet OpenChat, ha
installato anche la zimlet Teamwork, applicazione di chat potenziata rispetto alla
prima 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, dei
prodotti Zextras. Tramite esso è possibile accedere a tutti i dati del profilo Zimbra
così da mantenerli sincronizzati tra le varie sessioni in uso.
1920 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 modificati
durante tutto il corso del progetto. Per l’identificazione dei requisiti funzionali
sono stati delineati i casi d’uso principali tramite le richieste dell’azienda e quelli di
alto livello, in modo da poter dare una visione d’insieme più precisa del prodotto
sviluppato.
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 è rappresentato
nel 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 di
qualità, P se prestazionale, V se di vincolo;
• L’ultimo numero indica il numero del vincolo. La struttura numerica di
quest’ultimo rispetta le stesse regole dei Casi D’Uso.
5.3.1 Principali requisiti funzionali
Id Requisito Descrizione
R0F1 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 dettagli
relativi al buddy.
R1F3.1.1 L’utente OpenChat deve poter vedere per ogni buddy
della sua buddylist il nickname corrispondente.
R1F3.1.2 L’utente OpenChat deve poter vedere per ogni buddy
della sua buddylist l’immagine profilo corrispondente.
R1F3.1.3 L’utente OpenChat deve poter vedere per ogni buddy
della sua buddylist lo status in cui si trova.
R1F3.1.4 L’utente OpenChat deve poter vedere per ogni buddy
della 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 non
ancora letti.
R0F4 L’utente OpenChat deve poter vedere per ogni buddy
della sua buddylist lo storico delle conversazioni avute.
R0F4.1 L’utente OpenChat deve poter vedere per ogni buddy
della sua buddylist i messaggi ricevuti.
R0F4.2 L’utente OpenChat deve poter vedere per ogni buddy
della sua buddylist i messaggi inviatogli.
R0F5 L’utente OpenChat deve poter inviare messaggi ad ogni
buddy della sua buddylist.22 CAPITOLO 5. ANALISI DEI REQUISITI
Id Requisito Descrizione
R1F6 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 Descrizione
R0V1 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 Descrizione
R0Q1 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 web
Tabella 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 per
comprendere quali siano le differenze che sono state applicate.
La comunicazione tra il server Zimbra e la zimlet OpenChat avviene attraverso una
struttura 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 per
il 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 è stata
modificata la modalità di ricezione ed invio dei messaggi SOAP e la gestione tramite
connection manager in modo da far comunicare direttamente Teamwork e il server
Zimbra (con Zextras core integrato).
2324 CAPITOLO 6. PROGETTAZIONE E CODIFICA
6.1.2 Gestione eventi
Per gestire in modo ottimale ed efficacie la comunicazione tra server e client è stata
strutturata 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 sessioni
aperte facendo in modo di tenere aggiornato lo store Redux di ogni applicazione
connessa.
Di seguito un’approfondimento delle varie componenti che permettono questa
interazione:
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 Mail
Transfer Protocol (SMTP), all’interno dei quali viene incapsulato il messaggio
SOAP. I messaggi SOAP, rappresentati in figura 6.3, sono basati sul metalinguaggio
eXtensible Markup Language (XML) e vengono strutturati secondo due segmenti
principali, head e body.
Figura 6.3: Struttura messaggio SOAP6.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 contenuto
informativo (payload ) del messaggio. Saranno questi i dati importanti per la
gestione 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, informazioni
sullo stato del server o possibili errori di risposta.
Connection Manager
Il connection manager si occupa degli eventi in arrivo dal server. Per fare ciò ha
bisogno di due componenti principali:
• il ping, componente che si occupa di stabilire una connessione con il server e di
mantenerla operativa durante tutta la sessione. In questo modo l’applicazione
rimarrà 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 comprensione
del contenuto. È stata implementata un Abstract Factory per la creazione
di questa componente, design patterng che fornisce un’interfaccia per creare
famiglie 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 JavaScript
Object Notation(JSON) associati a dei particolari eventi di cui è stato implementato
un handler specifico.
La sua funzione, quindi, è quella di modificare lo stato dello store Redux, basandosi
sui dati ricevuti, attraverso un dispatcher che modifica il flusso dei dati utilizzati
nell’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 successiva
propagazione dei dati verso le altre sessioni) è stato introdotto un encoder, il
corrispondente 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’evento
all’encoder corrispondente. Questa componente permette la traduzione dell’evento
in un messaggio SOAP generico comprensibile dal server.26 CAPITOLO 6. PROGETTAZIONE E CODIFICA
6.1.3 Store Redux
L’architettura disegnata per la gestione degli eventi ha come punto focale il concetto
di store, database locale dove vengono salvati tutti i dati necessari all’implemen-
tazione tramite React Native dell’interfaccia grafica. Come spiegato nel capitolo
Tecnologie utilizzate (4.2.4), uno store Redux è un database dinamico condiviso,
accessibile da tutte le componenti di React Native così che possano sempre avere
dei dati coerenti tra loro.
Tramite Flux, il design pattern architetturale implementato da Redux, è stato
possibile 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 zimlet
OpenChat in quanto, per ottenere dei dati sincronizzati, deve necessariamente
rispecchiare la sua struttura. Questo store è quindi connesso alla gestione
degli eventi tramite il connection manager ed è la fonte principale dei dati
funzionali 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 Teamwork6.2. PROGETTAZIONE GRAFICA 27
6.2 Progettazione grafica
Prima di procedere alla definizione delle classi necessarie per l’implementazione
dell’applicazione è stato deciso di effettuare la progettazione della User Interface
(UI) per per far sì che il progetto di stage comprenda ogni aspetto della progettazione
e 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 iniziale
dell’applicazione tramite la realizzazione dei wireframe delle varie schermate.
Questo studio è la prima rappresentazione visuale dell’applicazione ed ha lo scopo
di identificare la struttura, l’architettura dell’informazione e la disposizione degli
elementi 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 deciso
nulla riguardo la rappresentazione grafica dei vari elementi, infatti è stata definita
soltanto la struttura delle varie schermate, il collegamento tra di esse e quali
elementi realmente soddisfino i requisiti già studiati. Il risultato, comunque, è stato
molto vicino alla Graphical User Interface (GUI) ottenuta alla fine della codifica
in 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.28 CAPITOLO 6. PROGETTAZIONE E CODIFICA
6.2.2 Linee guida
Per quanto riguarda la GUI vera e propria sono state fornite dall’azienda delle
guidelines 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’azienda
sviluppa.
Un esempio è la definizione del componente card, destinato alla visualizzazione dei
dettagli relativi ad un buddy:
Figura 6.6: Esempio guidelines spazi
Si noti come ogni elemento sia posizionato in modo preciso, definendo delle
proporzioni tra gli spazi. In questo modo la successiva codifica dello stile dovrà
assolutamente rispettare tali regole, in modo da non dover interagire continuamente
con il responsabile grafico del progetto.
L’applicazione delle guidelines nel codice è avvenuta in parallelo con lo sviluppo
in quanto, seguendo una metodologia agile, si è ritenuto opportuno che le varie
versioni prototipali dell’applicazione avessero anche una progressiva applicazione
delle regole di stile.
Approvati i wireframe è stato possibile proseguire alla definizione di tutti e soli i
componenti 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 consente
la realizzazione di interfacce tramite la suddivisione del sistema in componenti.
Ognuna di queste ha un proprio stato, delle proprietà che vengono ereditate dal
componente padre, e un proprio ciclo di vita, indipendente da qualsiasi altro.
Sono stati quindi progettati i componenti e la gerarchia tra essi, necessaria per la
visualizzazione degli screen precedentemente definiti, e infine è stata realizzata una
navigazione 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 essere
renderizzato utilizzerà a sua volta altri componenti.
Prendiamo come esempio lo screen Buddylist:
Figura 6.8: Suddivisione in componenti pagina Buddylist30 CAPITOLO 6. PROGETTAZIONE E CODIFICA
Possiamo vedere come lo screen buddylist sia un componente che renderizza altre
tre tipi di componenti:
• , che viene a sua volta renderizzato con (componente
difficilmente gestibile in quanto subisce forti variazioni a seconda del siste-
ma operativo), un semplice componente di testo e due componenti .
Quest’ultimi possiedono anche una proprietà navigation che permette la
navigazione verso altri screen;
• , caricata n volte sullo screen buddylist dipendente dal numero di
buddy. Anche questa componente è complessa e costituita da più componenti
, e un altro componente complesso ;
• che gestisce la navigazione verso i due stack principali, ChatStack
e SettingsStack. Il suo rendering,però, viene gestito solamente da due
componenti semplici: e .Capitolo 7
Verifica e Validazione
7.1 Linter
Come strumento di verifica statica del codice è stato utilizzato TSLint, descritto
nella sezione 4.2.2 di questo elaborato. Questo linter specifico per codice TypeScript
segnala errori di programmazione, errori stilistici e costrutti sospetti in base a
determinati criteri personalizzabili durante la codifica dei programmi.
In particolare è stato utilizzato per rendere conforme il codice scritto alle convenzioni
utilizzate 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 di
cicli "for " standard nei casi in cui l’indice sia utilizzato solamente per accede
agli 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 ridotto
rispetto alla quantità richiesta per analizzare il codice e il comportamento del
prodotto in maniera esaustiva, ma per volontà dell’azienda, si è preferito investire
un tempo maggiore nello sviluppo di funzionalità che nel loro testing, data la ridotta
durata dello stage.
Per rendere completa l’esperienza di stage e riuscire a toccare tutto il ciclo di vita
dello sviluppo del progetto sono comunque stati fatti dei test automatici. Per fare
ciò è stato utilizzato JestJs (sez. 4.3.3), tool di testing specifico per i progetti
ReactJS e React Native integrato nella configurazione del progetto.
Sono stati sviluppati due tipologie di test:
• Snapshot test per le componenti;
3132 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 essere
modificate durante il suo ciclo di vita, facendo variare anche il suo rendering.
Attraverso questa tipologia di test si controllano questi cambiamenti creando degli
snapshot di come il componente dovrebbe essere renderizzato.
In questo modo quando andremo a modificare il codice avremo la sicurezza di non
dover 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 reducer
producono 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 uno
snapshot ed applicare questo al nostro test così che venga simulato per ogni stato
trovato nell’applicazione o nel mock di riferimento.
Nel progetto Teamwork sono stati testati alcuni dei reducer più complessi dello
store Teamwork utilizzato per le funzioni operative.
Action
Le action sono delle semplici funzioni che ritornano un oggetto utilizzato per
modificare lo stato dello store. Per testarle non si fa altro generare uno snapshot
dell’output generato utilizzandolo come confronto per le modifiche future.
Anche in questo caso le action dello store Teamwork sono molto banali e sono stati
eseguiti test solamente per alcune di esse, come esercizio.
7.3 Test di sistema e collaudo
Per accertare la copertura dei requisiti si è ricorso a delle prove pratiche del
corretto funzionamento dell’applicazione. Questa operazione è stata svolta sia
come strumento per la verifica delle operazioni durante lo sviluppo del prodotto
software che come operazione di collaudo per assicurare il corretto funzionamento
dell’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 dalle prime implementazioni, dato che permette build automatiche in realtime testabili attraverso 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 collegati al framework di sviluppo è stato possibile testare ogni modifica del codice quasi simultaneamente al salvataggio delle modifiche, rendendo più agile l’implementazione della grafica. Per aver il più ampio spettro possibile di device simulati sono stati utilizzati due diversi simulatori: Genymotion (sez. 4.3.1) per i dispositivi Android e iOS Simulator per 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; • Samsung Galaxy S6; • Samsung Galaxy S8; • Sony Xperia Z; • iPhone 5s; • iPhone 6 plus; • iPhone 7; • iPhone X. Sui device appena elencati sono stati utilizzati i seguenti sistemi operativi per accedere 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).
Puoi anche leggere
