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 Introduzione1 1.1 Organizzazione dell’elaborato ...... 1 1.2 Convenzioni adottate ...... 1
2 Azienda ospitante3 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 progetto9 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
vii viii 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 ...... 46 INDICE 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
x ELENCO 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: • Capitolo1: descrizione della struttura del documento e delle convenzioni adottate nella stesura dello stesso; • Capitolo2: introduzione dell’azienda ospitante, dei suoi prodotti nel mercato e del metodo di lavoro seguito al suo interno; • Capitolo3: presentazione del progetto svolto durante questo stage, gli obiettivi, il mio contributo ad esso e come è stato pianificato il lavoro; • Capitolo4: esposizione delle tecnologie che sono state studiate e adottate durante il mio stage; • Capitolo5: elenco dei requisiti che l’azienda ha definito per il prodotto finale; • Capitolo6: spiegazione delle scelte implementative e di design dell’applicazio- ne; • Capitolo7: descrizione delle fasi di verifica e validazione del prodotto svolte: • Capitolo8: 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;
1 2 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.
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 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, Bambooe 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.
1https://github.com/ZeXtras/OpenChat
9 10 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 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 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.
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 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 per 4.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.
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 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 appendiceA è 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).
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 è 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 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 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 Teamwork 6.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 Buddylist 30 CAPITOLO 6. PROGETTAZIONE E CODIFICA
Possiamo vedere come lo screen buddylist sia un componente che renderizza altre tre tipi di componenti:
•
• e un altro componente complesso
•
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;
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 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). 34 CAPITOLO 7. VERIFICA E VALIDAZIONE
7.3.2 Device fisici Oltre agli emulatori sono stati utilizzati dei device fisici dell’azienda a disposizione degli sviluppatori per installare e testare l’applicazione. Per fare ciò è stato richiesto di 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;
• 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 state più accurate e numerose di quelle inizialmente stabilite, tanto che si è deciso di procedere ad una fase di beta testing interno all’azienda.
Test Flight Attraverso il programma per sviluppatori Apple si è avviata la procedura per poter caricare le build (.ipa) dell’applicazione sull’App Store Connect, così da permettere il testing attraverso TestFlight. TestFlight è un’applicazione utilizzata per testare applicazioni non ancora sullo store ufficiale, usufruibile da chiunque sia stato invitato a provare la beta. Tramite questo programma si ha la possibilità di distribuire l’applicazione fino ad un massimo di 25 persone. Tramite il loro utilizzo dell’applicazione gli sviluppatori riceveranno dati 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 testing esterno 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 le aspettative dell’azienda, in quanto non pensavano di arrivare ad avere in mano un prototipo con tutte le funzionalità principali. Questo ha confermato all’azienda l’effettiva utilità di un’applicazione mobile di chat da integrare nella suite Zextras. Infatti il progetto Teamwork verrà portato avanti senza applicare cambiamenti drastici dell’architettura, a partire dal codice sviluppato 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 rappresenta i wireframe progettati.
Figura 8.1: Screen pagina di login, buddylist e chat page.
Per quanto riguarda l’interfaccia grafica sono molto soddisfatta del risultato ottenuto in quanto segue perfettamente le linee guida fornite dall’azienda.
35 36 CAPITOLO 8. CONCLUSIONI
Personalmente ritengo il prodotto sviluppato un ottimo prototipo della possibile chat della suite, ma la ritengo ancora lontana dall’essere una versione rilasciabile e testabile da utenti esterni principalmente per due motivi: • le funzionalità implementate non sono abbastanza numerose da coprire i bisogni che dovrebbe soddisfare questo tipo di applicazione; • essendo una suite di prodotti utilizzati in ambiente lavorativo è necessario assicurare una certa sicurezza nella comunicazione dei dati e nella connessione ai server, criptando i messaggi all’invio. Ciò non è stato però previsto nello stage.
8.2 Valutazione framework e librerie utilizzate
L’obbiettivo di questo progetto di stage, oltre ad avere un prototipo funzionante dell’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 giudicare pregi e difetti in maniera critica, ritengo adeguato effettuare una valutazione a posteri 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 la gestione dei dati rispetto alla precedente tecnologia utilizzata specifica per Zimbra. Per la realizzazione di applicazioni mobile è disponibile una sua variante, React Native, 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 a vari punti:
App multipiattaforma React Native permette lo sviluppo di applicazioni mobile sia Android che iOS utilizzando JavaScript. In questo modo non è necessario sviluppare due versioni dell’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 e tentare di generalizzare i comportamenti di tutti i componenti nativi risulta impos- sibile. Per questo motivo non sono implementati tutti i componenti che avremmo a disposizione nei due ambienti di sviluppo nativi e. inoltre, non è detto che un componente 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 nativa e sistema operativo. 8.2. VALUTAZIONE FRAMEWORK E LIBRERIE UTILIZZATE 37
Virtual DOM Per accedere e aggiornare dinamicamente il contenuto, la struttura e lo stile dei documenti nel client web e nelle applicazioni che utilizzano WebView si utilizza il Document Object Model (DOM), una forma di rappresentazione dei documenti strutturati, 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 visualizzata dal browser. In tal modo vengono renderizzati solamente i componenti che vengono modificati 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 familiare per 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 gestibile in quanto possono essere implementate al suo interno funzioni JavaScript. Per gestire lo stile di ogni componente, invece, si utilizza un simil CSS (in formato JSON) che risulta limitato nelle dichiarazioni. Non è possibile quindi utilizzare estensioni 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 i principali benefici e svantaggi dell’utilizzo di esso. Aspetti positivi:
• semplifica delle operazioni comuni che non sono gestite dai componenti di React Native introducendo dei nuovi componenti Expo;
• velocizza di molto i tempi di testing su device fisici, in quanto Expo propone build automatiche nei propri server che possono essere scaricate su qualsiasi device tramite un link alla build;
• riduce la complessità di creazione di file .apk e .ipa in quanto crea le build nei propri server e gestisce le certificazioni in autonomia.
Aspetti negativi:
• l’interazione tra Expo e React Native Debugger ha riscontrato non pochi problemi, 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 stage
Anche se il mio percorso di studi precedente all’Università non mi ha mai portato allo studio di discipline informatiche ho deciso di affacciarmi a questo mondo che tanto mi affascinava iscrivendomi al corso di Informatica all’Univesità. Sebbene impegnativo, soprattutto per chi, come me, non aveva conoscenze tecniche pregresse, mi è stato subito chiaro dell’ottima scelta fatta. Nei tre anni di lezione ho 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 pratica tutte 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 saper gestire 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 un nuovo linguaggio di programmazione, utilizzato dei framework e librerie utilissime in 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 sento di dire che l’esperienza di stage è riuscita a far concludere il mio percorso di studi della laurea triennale con entusiasmo, dandomi la carica e la voglia di continuare il percorso di studi affrontando la laurea magistrale in Informatica e, allo stesso tempo, 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 Teamwork web
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 e contattare la sua buddylist. Se nei suoi server Zimbra dispone della zimlet Teamwork web potrà interagire anche con i gruppi di cui fa parte.
Precondizioni Il sistema è avviato e connesso a dei server Zimbra pronti per l’autenticazione;
Postcondizioni Il sistema ha eseguito tutte le funzioni richieste dall’ attore permettendogli così di interagire con la sua buddylist e con i gruppi di cui fa parte
Scenario principale 1. L’utente Zimbra vuole accedere all’applicazione Teamwork per mobile per gestire e comunicare con la sua lista contatti e con i gruppi; 2. L’utente OpenChat ha a disposizione la buddylist con le relative chat in modo da gestire nel modo che crede 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 la password con cui è registrato al server Zimbra; A.4. UC1.2 - INSERIMENTO PASSWORD 41
Precondizioni Il sistema è avviato, pronto per l’utilizzo e mostra la pagina di login;
Postcondizioni Il sistema ha autenticato l’attore e gli mostra la sua area riservata;
Scenario principale 1. L’attore inserisce l’e-mail con cui è registrato al server Zimbra); 2. L’attore inserisce la sua password; 3. L’attore conferma il login e accede alla sua area riservata.
Estensioni Visualizzazione errore login (A.5).
A.3 UC1.1 - Inserimento email
Attori Primari Utente Zimbra;
Descrizione L’attore si può autenticare inserendo l’e-mail con cui è registrato al server Zimbra;
Precondizioni Il sistema è avviato, pronto per l’utilizzo e mostra la pagina di login;
Postcondizioni Il sistema resta in attesa dell’inserimento del- la password da parte dell’attore per continuare l’autenticazione;
Scenario principale 1. L’attore inserisce l’e-mail con cui è registrato al server Zimbra).
A.4 UC1.2 - Inserimento password
Attori Primari Utente Zimbra;
Descrizione L’attore si può autenticare inserendo la password del profilo Zimbra;
Precondizioni Il sistema è avviato, pronto per l’utilizzo e mostra la pagina di login; 42 APPENDICE A. DESCRIZIONE CASI D’USO
Postcondizioni Il sistema resta in attesa della conferma da parte dell’attore per continuare l’autenticazione;
Scenario principale 1. L’attore inserisce la sua password.
A.5 UC2 - Visualizzazione errore login
Attori Primari Utente Zimbra;
Descrizione L’attore visualizza un messaggio di errore in quanto le credenziali da lui inserite non sono corrette;
Precondizioni L’attore ha cercato di effettuare il login inserendo delle 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 buddy presenti nella sua buddylist; A.7. UC3.1 - VISUALIZZAZIONE CARD BUDDY 43
Precondizioni Talkapp presenta all’attore una pagina contenente la lista dei suoi buddy;
Postcondizioni L’attore ha visualizzato la lista dei suoi buddy;
Scenario principale 1. L’attore seleziona l’icona nella tab riguardante la buddylist; 2. L’attore visualizza la buddylist contenente tutti i suoi buddy;
A.7 UC3.1 - Visualizzazione card buddy
Figura A.4: UC3.1 - Visualizzazione card buddy
Attori Primari Utente OpenChat;
Descrizione L’attore può visualizzare dei dati significativi di ogni buddy presente nella sua buddylist;
Precondizioni Talkapp presenta all’attore una pagina contenente la lista dei suoi buddy;
Postcondizioni L’attore ha visualizzato per ogni buddy una card contenente dei dettagli; 44 APPENDICE A. DESCRIZIONE CASI D’USO
Scenario principale 1. L’attore seleziona l’icona nella tab riguardante la buddylist; 2. L’attore visualizza per ogni buddy una card in cui sono presenti dei dettagli;
A.8 UC3.1.1 - Visualizzazione nickname
Attori Primari Utente OpenChat;
Descrizione L’attore può visualizzare il nickname dato ad un buddy della sua buddylist;
Precondizioni Talkapp presenta all’attore una pagina contenente la lista dei suoi buddy;
Postcondizioni L’attore ha visualizzato per ogni buddy il nickname dato;
Scenario principale 1. L’attore seleziona l’icona nella tab riguardante la buddylist; 2. L’attore visualizza il nickname del buddy nella card a esso collegata;
A.9 UC3.1.2 - Visualizzazione immagine profilo
Attori Primari Utente OpenChat;
Descrizione L’attore può visualizzare l’immagine profilo di ogni buddy della sua buddylist;
Precondizioni Talkapp presenta all’attore una pagina contenente la lista dei suoi buddy;
Postcondizioni L’attore ha visualizzato per ogni buddy l’immagine profilo;
Scenario principale 1. L’attore seleziona l’icona nella tab riguardante la buddylist; 2. L’attore visualizza l’immagine profilo del buddy nella card a esso collegata; A.11. UC3.1.4 - VISUALIZZAZIONE DATA ULTIMO MESSAGGIO 45
A.10 UC3.1.3 - Visualizzazione status
Attori Primari Utente OpenChat;
Descrizione L’attore può visualizzare lo status di ogni buddy della sua buddylist;
Precondizioni Talkapp presenta all’attore una pagina contenente la lista dei suoi buddy;
Postcondizioni L’attore ha visualizzato per ogni buddy il loro status;
Scenario principale 1. L’attore seleziona l’icona nella tab riguardante la buddylist; 2. L’attore visualizza lo status del buddy nella card a esso collegata;
A.11 UC3.1.4 - Visualizzazione data ultimo mes- saggio
Attori Primari Utente OpenChat;
Descrizione L’attore può visualizzare la data dell’ultimo messaggio scambiato con un particolare buddy della propria buddylist;
Precondizioni Talkapp presenta all’attore una pagina contenente la lista dei suoi buddy;
Postcondizioni L’attore ha visualizzato per ogni buddy la data dell’ultimo messaggio scambiato con esso;
Scenario principale 1. L’attore seleziona l’icona nella tab riguardante la buddylist; 2. L’attore visualizza la data dell’ultimo messaggio scambiato con un buddy nella card a esso collegata; 46 APPENDICE A. DESCRIZIONE CASI D’USO A.12 UC3.1.5 - Visualizzazione notifiche
Attori Primari Utente OpenChat;
Descrizione L’attore può visualizzare il numero dei messaggi ri- cevuti da un particolare buddy della sua buddylist e non ancora letti;
Precondizioni Talkapp presenta all’attore una pagina contenente la lista dei suoi buddy;
Postcondizioni L’attore ha visualizzato per ogni buddy il numero dei messaggi ricevuti da esso e non ancora letti;
Scenario principale 1. L’attore seleziona l’icona nella tab riguardante la buddylist; 2. L’attore visualizza il numero dei messaggi ricevuto da un particolare buddy e non ancora letti nella card a esso collegata;
A.13 UC4 - Visualizzazione storico chat
Figura A.5: UC4 - Visualizzazione storico chat
Attori Primari Utente OpenChat;
Descrizione L’attore può visualizzare lo storico delle conversazioni avute con i suoi buddy;
Precondizioni Talkapp presenta all’attore una pagina contenente la lista dei suoi buddy;
Postcondizioni L’attore ha visualizzato la lista dei messaggi scambiati con 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 scambiati nel tempo con il buddy selezionato;
A.14 UC4.1 - Visualizzazione messaggi ricevuti
Attori Primari Utente OpenChat;
Descrizione L’attore può visualizzare i messaggi ricevuti da un particolare buddy;
Precondizioni Talkapp presenta all’attore una pagina contenente la lista dei suoi buddy;
Postcondizioni L’attore ha visualizzato la lista dei messaggi ricevuti da un particolare buddy;
Scenario principale 1. L’attore seleziona un buddy dalla sua buddylist; 2. L’attore visualizza la lista dei messaggi ricevuti nel tempo dal buddy selezionato;
A.15 UC4.2 - Visualizzazione messaggi inviati
Attori Primari Utente OpenChat;
Descrizione L’attore può visualizzare i messaggi inviati ad un particolare buddy;
Precondizioni Talkapp presenta all’attore una pagina contenente la lista dei suoi buddy;
Postcondizioni L’attore ha visualizzato la lista dei messaggi inviati ad un particolare buddy;
Scenario principale 1. L’attore seleziona un buddy dalla sua buddylist; 2. L’attore visualizza la lista dei messaggi inviati nel tempo al buddy selezionato; 48 APPENDICE A. DESCRIZIONE CASI D’USO A.16 UC5 - Invio messaggi
Attori Primari Utente OpenChat;
Descrizione L’attore può inviare messaggi ad un buddy;
Precondizioni Talkapp presenta all’attore una pagina contenente lo storico delle conversazioni avute con un particolare buddy;
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 per confermare l’invio; 4. Il messaggio appare nello storico della chat.
A.17 UC6 - Modifica buddylist
Attori Primari Utente OpenChat;
Descrizione L’attore può modificare la buddylist visualizzata;
Precondizioni Talkapp presenta all’attore una pagina contenente la lista dei suoi buddy
Postcondizioni L’attore ha modificato la buddylist che viene visualizzata;
Scenario principale 1. L’attore seleziona un buddy da rimuovere o digita un contatto da aggiungere; 2. L’attore conferma di voler cambiare la buddylist tramite l”azione svolta;
A.18 UC7 - Aggiunta buddy
Attori Primari Utente OpenChat; A.20. UC9 - RICERCA BUDDY 49
Descrizione L’attore può aggiungere un nuovo buddy alla sua buddylist;
Precondizioni Talkapp presenta all’attore una pagina contenente un form 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 al buddy; 2. L’attore inserisce l’e-mail del buddy che vuole aggiungere; 3. L’attore conferma l’aggiunta del buddy alla propria buddylist.
A.19 UC8 - Rimozione buddy
Attori Primari Utente OpenChat;
Descrizione L’attore può rimuovere un buddy dalla sua buddylist;
Precondizioni Talkapp presenta all’attore una pagina contenente i dettagli del buddy selezionato e le azioni che possono essere svolte;
Postcondizioni L’attore ha rimosso il buddy dalla sua buddylist;
Scenario principale 1. L’attore seleziona il buddiy dalla buddylist che vuole rimuovere; 2. L’attore seleziona la voce "Rimozione" dal menù di azioni disponibili; 3. L’attore conferma la rimozione del buddy dalla propria buddylist.
A.20 UC9 - Ricerca buddy
Attori Primari Utente OpenChat;
Descrizione L’attore può ricercare un buddy tra quelli presenti nella sua buddylist; 50 APPENDICE A. DESCRIZIONE CASI D’USO
Precondizioni Talkapp presenta all’attore una pagina contenente un campo di ricerca per ricercare un buddy in base ad un certo testo;
Postcondizioni L’attore ha ricercato un buddy dalla sa buddylist in base 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 alla ricerca da lui effettuata;
A.21 UC10 - Modifica status
Attori Primari Utente OpenChat;
Descrizione L’attore può modificare lo status con cui viene visualizzato dagli altri utenti;
Precondizioni Talkapp presenta all’attore una pagina contenente un elenco degli statusdis ponibili;
Postcondizioni L’attore ha modificato lo status con cui viene visualizzato dagli altri utenti;
Scenario principale 1. L’attore seleziona uno status tra quelli disponibili; 2. L’attore conferma di voler cambiate status con quello selezionato;
A.22 UC11 - Modifica tema
Attori Primari Utente OpenChat;
Descrizione L’attore può modificare il tema dei colori con cui visualizza l’applicazione;
Precondizioni Talkapp presenta all’attore una pagina contenente un elenco 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 da applicare 2. 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 fa parte;
Precondizioni Talkapp presenta una pagina contenente i gruppi di cui fa parte;
Postcondizioni L’attore ha visualizzato i gruppi di cui fa parte;
Scenario principale 1. L’attore seleziona l’icona nella tab riguardante i gruppi; 2. L’attore visualizza i gruppi di cui fa parte;
Glossario
agile Modelli di ciclo di vita del software che nascono come reazione alla troppa rigidità degli altri modelli, puntano sul soddisfacimento del cliente piuttosto che 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 individuare anomalie all’interno di documenti e codice sorgente. 14
Android sistema operativo per dispositivi mobili sviluppato da Google Inc. e basato sul kernel Linux. È stato progettato principalmente per smartphone e tablet.9
Android Studio Ambiente di sviluppo integrato per lo sviluppo per la piattaforma Android 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 principi che ne governano la progettazione e l’evoluzione. 23 backup Operazione di salvataggio su una qualunque memoria di massa dei dati di un utente archiviati nella memoria di un computer.5 bug In italiano "baco", identifica un errore nella scrittura del codice sorgente che porta a comportamente anomali e non previsti del programma. Un bug può essere introdotto anche in fase di compilazione o di progettazione del programma..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-in viene quindi verificato da una build automatizzata, consentendo al team di rilevare 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 di un particolare design pattern) su cui un software può essere costruito per facilitarne lo sviluppo da parte del programmatore.9 git Software per il controllo di versione distribuito con interfaccia a riga di comando sviluppato da Linus Torvalds nel 2005.7 guidelines Insieme di raccomandazioni sviluppate sistematicamente, sulla base di conoscenze continuamente aggiornate e valide, redatto allo scopo di ren- dere appropriato, e con un elevato standard di qualità, un comportamento desiderato.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 modo controllato. 32 open source Movimento per cui gli autori di un software o i detentori dei suoi diritti 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 strutturale di un sistema software, si descrivono i sottosistemi predefiniti con i ruoli che essi assumono e le relazioni reciproche. 14 processo Insieme di attività collegate tra loro che trasformano ingressi in uscite secondo regole fissate e tramite risorse limitate.6 prototipo Rappresenta la creazione di quello che sarà verosimilmente il prodotto finale.9
React Native Libreria JavaScript utilizzata per la realizzazione di interfacce utente 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 certo bisogno del cliente. Descrive cosa il sistema deve fare, i servizi che offre e i vincoli 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 che può influenzarne l’attività.6 Glossary 55 storage Dispositivi hardware, supporti per la memorizzazione, infrastrutture e software dedicati alla memorizzazione non volatile di grandi quantità di informazioni in formato elettronico.4 unit testing Attività di testing di singole unità software, il minimo componente di un programma dotato di funzionamento autonomo. 16 versionamento Consiste nel tenere traccia degli stati che può assumere il progetto durante il suo sviluppo, diverso funzionalmente da un’altra versione.7 wireframe Rappresenta il modello iniziale di rappresentazione di un sito web che ha lo scopo di identificare la struttura del sito web, l’architettura dell’informazione e la disposizione degli elementi nella pagina. 10 xCode Ambiente di sviluppo integrato progettato da Apple contenente una suite di strumenti utili allo sviluppo di software per i sistemi macOS, iOS, watchOS e 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 consultati
Expo 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