UNIVERSITA’ DEGLI STUDI DI TRENTO DIPARTIMENTO DI INGEGNERIA E SCIENZA DELL’INFORMAZIONE Corso di Laurea triennale in Informatica _____________________________________________________________________ Tesi finale StudyMate: un’applicazione Android per la gestione delle attività didattiche degli studenti universitari Relatrice: Laureando: Prof. Antonella De Angeli Manuel Visentin Correlatrice: Dott.ssa Silvia Bordin Anno accademico 2012 - 2013

1

2

3

4 Indice 1 Introduzione .......................................................................................................................................................... 6 2 Contesto ................................................................................................................................................................ 7 2.1 SmartCampus.................................................................................................................................................. 7 2.2 StudyMate ...................................................................................................................................................... 7 3 Implementazione interfaccia .............................................................................................................................. 10 3.1 Interaction design ......................................................................................................................................... 10 3.2 User-centred design ..................................................................................................................................... 10 3.3 Analisi PACT .................................................................................................................................................. 11 3.4 Mockups di media fedeltà ............................................................................................................................ 13 3.4.1 Home ..................................................................................................................................................... 14 3.4.2 Agenda ................................................................................................................................................... 14 3.4.3 Ricerca dei corsi ..................................................................................................................................... 15 3.4.4 Home dei corsi ....................................................................................................................................... 16 3.4.5 Materiali ................................................................................................................................................ 17 3.4.6 Notifiche ................................................................................................................................................ 18 3.5 Valutazione dell’usabilità .............................................................................................................................. 18 3.6 Redesign e revisione dei requisiti ................................................................................................................. 21 3.6.1 Sistema di valutazione dei corsi ............................................................................................................ 22 3.6.2 Redesign ................................................................................................................................................ 23 4 Front end ............................................................................................................................................................. 25 4.1 Implementazione finale dell’interfaccia grafica ........................................................................................... 26 4.1.1 Ricerca dei corsi ..................................................................................................................................... 26 4.1.2 Home dei corsi ....................................................................................................................................... 27 4.1.3 Recensioni ............................................................................................................................................. 28 4.1.4 Aggiunta di una recensione ................................................................................................................... 29 4.2 Android ......................................................................................................................................................... 31 4.3 Metodologie di implementazione ................................................................................................................ 33 4.3.1 Activity ................................................................................................................................................... 34

5 4.3.2 Intent ..................................................................................................................................................... 35 4.4 Organizzazione .............................................................................................................................................. 36 4.5 Comunicazione con il server ......................................................................................................................... 36 4.5.1 AsyncTask .............................................................................................................................................. 37 4.5.2 JSON ....................................................................................................................................................... 38 4.5.3 Implementazione ................................................................................................................................... 39 5 Piattaforma ......................................................................................................................................................... 40 5.1 Autenticazione e controllo dell’accesso ....................................................................................................... 41 5.2 Servizi core .................................................................................................................................................... 42 5.2.1 Profile Service ........................................................................................................................................ 42 6 Back end .............................................................................................................................................................. 44 6.1 Modello di dominio ...................................................................................................................................... 44 6.2 Requisiti ........................................................................................................................................................ 47 6.3 Metodi implementati ed esempi .................................................................................................................. 49 6.3.1 Java Persistence API (JPA) ..................................................................................................................... 50 6.3.2 Mapping delle entità ............................................................................................................................. 50 6.3.3 Java Persistence Query Language (JPQL) .............................................................................................. 51 6.3.4 Uso di JPQL e JpaRepository .................................................................................................................. 52 6.3.5 Relazioni tra entità ................................................................................................................................ 53 6.3.6 Implementazione dei metodi REST ....................................................................................................... 53 7 Moderazione dei commenti ............................................................................................................................... 57 7.1 Requisiti ........................................................................................................................................................ 57 7.2 Architettura .................................................................................................................................................. 57 7.3 Gestione dei commenti e sincronizzazione delle keywords ......................................................................... 58 Conclusioni ............................................................................................................................................................. 60

6 1 Introduzione La vita accademica degli studenti è sempre piena di impegni e contrattempi. E’ spesso difficile poter organizzare in maniera efficiente il tempo da dedicare allo studio degli esami che gli studenti stanno frequentando, oltre agli eventuali ancora da superare. Come comunemente succede, potrebbero esserci eventi come la cancellazione di una lezione, lo spostamento di quest’ultima in un’altra aula; oltre che il cambio della data di un appello d’esame, o in generale la difficoltà di usufruire di materiali didattici aggiuntivi che potrebbero favorire un apprendimento più veloce ed efficiente, o i metodi di studio più efficaci per poter passare un determinato esame. Inoltre, un altro problema comune è quando, all’inizio del semestre accademico, lo studente si trova di fronte alla scelta di quale corso frequentare tra quelli a scelta libera. Di solito la scelta viene fatta dopo aver chiesto pareri ai colleghi, ma non sempre questo basta per scegliere quello che più soddisfa. Per gli studenti il tempo è prezioso, ed ogni giorno avrebbero bisogno di un supporto che li possa guidare nelle loro giornate accademiche, risparmiando tempo e favorendo la collaborazione tra studenti, permettendo loro di superare gli esami più proficuamente; ed in generale, migliorare la soddisfazione della loro carriera universitaria. In questa tesi illustrerò StudyMate, un'applicazione Android sviluppata presso SmartCampus Lab. Ho avuto l’opportunità di dare il mio contributo in tutto il suo ciclo di progettazione e sviluppo. La tesi è strutturata nel seguente modo: il Capitolo 2 descrive il contesto in cui ho potuto sviluppare StudyMate, ossia all’interno della piattaforma SmartCampus, della quale descriverò la struttura principale ed i servizi che ho utilizzato. Il capitolo 3 descrive il processo di Interaction design svolto a priori e durante l’esperienza di tirocinio. Il capitolo 4 dà una panoramica generale di cos’è Android e dei componenti che ho utilizzato per lo sviluppo; descrive inoltre l’interfaccia finale dell’applicazione, le principali funzionalità che ho implementato e le metodologie che sono state utilizzate. Il capitolo 5 descrive il lato back-end di StudyMate, in particolare la fase di progettazione concettuale, l’implementazione dei metodi del servizio web e la gestione della persistenza dei dati. Il capitolo 6 descrive l'architettura del sistema di moderazione dei commenti. La conclusione è una riflessione critica sul lavoro svolto in tutto il ciclo di progettazione di StudyMate, i risultati ottenuti, gli aspetti meno positivi e come è stata la mia esperienza da designer, sviluppatore ed utente finale.

7 2 Contesto 2.1 SmartCampus Il contesto in cui il progetto prende forma è lo SmartCampus Lab. Si occupa di creare servizi attraverso applicazioni Android per migliorare l'esperienza delle persone nel campus ed in generale nella città, dando loro la possibilità di essere partecipi nella progettazione di tali servizi. Quindi, SmartCampus lab non solo costituisce un ambiente tecnico per la progettazione di servizi, ma soprattutto un ambiente sociale, la cui comunità è composta da tutti gli studenti, ricercatori e personale del campus che sono interessati a beneficiare di tali servizi e che collaborano alla loro progettazione e realizzazione. L’obiettivo di tale cooperazione è di creare un modello completo di una città intelligente, e soprattutto responsabilizzare i cittadini ad assumere un ruolo sempre più attivo nella progettazione dei servizi che desiderano e prediligono, partecipando al loro sviluppo ed alla distribuzione. I punti fondamentali che caratterizzano le applicazioni SmartCampus sono:  Fornire agli utenti del campus servizi che possano semplificare la loro vita quotidiana;  Creare interfacce usabili;  Le varie applicazioni collaborano tra loro. 2.2 StudyMate StudyMate nasce dalla fusione di due idee nate durante il corso di Interazione uomo-macchina tenuto dalla professoressa Antonella De Angeli dell'anno accademico 2012/2013. Le 2 applicazioni sono Course's Agenda e Scholar. Course's Agenda è stata pensata da Micheli Luca (con il quale in seguito ho collaborato durante l'esperienza di stage per la creazione di StudyMate) e altri suoi colleghi, ed è un’applicazione che principalmente ha lo scopo di organizzare gli impegni accademici degli studenti attraverso un’agenda. Scholar invece è stata pensata da me, Thomas Tolio e Anna Berton. Il nostro obiettivo era quello di pensare ad un nuovo servizio che fosse utile alla comunità del campus.

8 Figura 1 Figura 2 Distribuendo un questionario ad un campione di studenti presi da tutte le facoltà in cui si chiedeva di dare un peso da 1 a 5 ad una lista di classici problemi che noi stessi abbiamo incontrato nella

9 nostra vita accademica. Come si può vedere nel grafico, tramite varie interviste agli studenti universitari volte a raccogliere informazioni sui loro bisogni, era emerso che mancava un servizio che potesse supportare lo studente nella sua carriera accademica. Da qui abbiamo pensato ad un’applicazione mobile che sia in grado di offrire le seguenti funzionalità: # Funzionalità di Scholar 1 Aiutare gli studenti a scegliere i corsi non vincolati nel piano di studi che possono essere più interessanti ed adeguati per il proseguo della loro carriera accademica, attraverso le recensioni dei corsi date dagli studenti; 2 Dare una recensione personale di un determinato corso; 3 Condividere materiale didattico; 4 Condividere avvisi; 5 Un servizio di notifiche in cui è possibile vedere sia le informazioni della bacheca dell’università riferita ai corsi di interesse, sia gli avvisi condivisi dagli altri studenti. Le due idee sono state selezionate per partecipare ad un participatory design contest organizzato da SmartCampus al fine di trovare nuove idee di servizi da integrare nel progetto SmartCampus. Durante l’esperienza di tirocinio, io ed il mio collega Luca Micheli abbiamo fatto un lavoro di integrazione dei requisiti delle 2 applicazioni, da cui è nata StudyMate.

10 3 Implementazione interfaccia 3.1 Interaction design L’interaction design (ID) è il processo di progettazione dell'interfaccia utente di un qualsiasi sistema informatico e software che ha la necessità di dialogare con l'uomo. Gli obiettivi dell'interaction design sono di sviluppare prodotti utilizzabili che prevedono un esperienza piacevole e coinvolgere gli utenti finali nel processo di progettazione (user-centred design, participatory design). Questa fase della progettazione è molto importante poiché pone le basi della progettazione dell’interazione uomo-macchina che ne determina la versione finale del software, e quindi la soddisfazione dell'utente finale nell'utilizzo del prodotto. Un design scadente può:  Ridurre la produttività degli utenti;  Aumentare i tempi di apprendimento;  Aumentare gli errori e portare alla frustrazione;  Portare al rigetto del sistema l'utente. Di seguito illustrerò quali sono stati i passi per progettare buon design e su quali aspetti teorici mi sono basato. 3.2 User centred design Nella prima fase della progettazione dell'applicazione StudyMate è stato eseguito un processo di progettazione di user centred design, composto da più attività. Si basa sull’iterazione di diversi strumenti di analisi od osservazione, progettazione e verifica. E' una filosofia di progettazione e un processo nel quale i bisogni e il desiderio dell'utente finale vengono messi in primo piano in ogni passo del processo, in modo da garantire una maggiore usabilità e quindi una migliore esperienza d'uso. Le quattro attività alla base del design dell'interazione possono essere così espresse:  Identificare i bisogni e stabilire i requisiti;  Sviluppare proposte di design che rispondano ai requisiti identificati;  Costruirne versioni interattive che possano essere comunicate e valutate;  Valutarne l'accettabilità. [User-centred design]

11 Data la natura iterativa dell'interaction design, isolare l'attività di definizione dei requisiti da quella di progettazione e quella di valutazione è una forzatura, dal momento che sono tutte intrecciate. 3.3 Analisi PACT I risultati dell'analisi PACT derivano principalmente dalla mia esperienza acquisita durante il corso di Interazione uomo-macchina, in cui è stato fatto un questionario agli studenti per capire i loro bisogni nell’ambito accademico, e successivamente delle interviste mirate ad approfondire alcuni aspetti importanti. E' una metodologia usata dalla prima fase di progettazione basata sullo user centred design, e serve ad aiutare a trovare in modo più veloce ed efficiente i bisogni ed i requisiti da applicare alla progettazione dell'interfaccia. L'analisi si basa focalizzandosi su 4 categorie: Persone, attività, contesto, tecnologie. [Analisi PACT] L'analisi PACT effettuata per StudyMate è la seguente: Persone: StudyMate è pensata per aiutare gli studenti, indipendentemente dalla loro età, sesso, facoltà, nazionalità o il loro anno di studi corrente. Gli utenti interessati sono tutti gli studenti dell'università degli studi di Trento con un età media compresa tra i 19 e i 30 anni. La maggior parte di loro conosce, bene o male, l'inglese. Solo pochi di loro sono nati a Trento, ma la maggior parte viene da fuori provincia o anche regione; specialmente nelle facoltà più tecniche ci sono anche un discreto numero di studenti stranieri. La base sociale e culturale di una parte di studenti può essere diversa da quella italiana, ma questo non influisce in questo studio perché le principali e più importanti tecnologie informatiche disponibili sono le stesse, e quindi si possono mettere sullo stesso piano tutti gli studenti. La maggior parte degli studenti vive nello stesso contesto sociale (Trento e l'Università), e il fatto di avere una gamma molto ristretta di età implica che abbiamo praticamente una classe unica di utenti in termini di capacità psicologiche, quali l'attenzione, la percezione e la memoria. Attività: Lo scopo di StudyMate è quello di fornire agli studenti un supporto per raccogliere informazioni e consigli sui corsi da frequentare e consultare facilmente materiali utili all'apprendimento di un determinato esame, oltre ad avere un'agenda che permetta allo studente di avere sempre sotto controllo i propri impegni, ed un servizio di notifiche che gli permetta di essere avvisato se una lezione o un appello d'esame è stato spostato o cancellato, o se sono stati caricati nuovi materiali didattici per un corso d'interesse. In particolare, essa consente allo studente di

12 gestire in modo ottimizzato il proprio tempo e i propri impegni universitari fornendo i seguenti strumenti:  Un'agenda dedicata agli impegni accademici: si potranno aggiungere e modificare eventi, aggiungere note agli stessi, condividerli con determinati gruppi di persone. L'agenda consente anche di filtrare gli impegni in base al corso a cui si riferiscono.  Una funzione di ricerca per i corsi offerti dall’Università di Trento.  Una home dei corsi che per ciascun corso è possibile visualizzare una descrizione e valutazioni e commenti espressi dagli altri studenti che l’hanno già superato.  Una funzione dove è possibile dare una valutazione personale di un corso.  Visualizzare i materiali ufficiali e suggeriti dagli studenti relativamente ai corsi che lo studente sta seguendo o che non ha ancora superato.  Un sistema di notifiche che informa l'utente di eventuali modifiche agli eventi che lo interessano. Per quanto riguarda la tipologia dei contenuti e l’aspetto temporale:  I dati riferiti ai corsi, gli eventi, i dipartimenti, devono essere mantenuti in un server e resi sempre disponibili all’utente.  I materiali, condivisi dagli utenti possono essere di diverso tipo e di diversi formati (appunti personali in formato .pdf, .ppt o anche altro come ad esempio dei link alla risorsa).  Per il caricamento del materiale da parte degli studenti, è già esistente il sito www.povoshardlife.eu in cui esiste già una consistente comunità e quindi l'applicazione, per questa funzionalità, servirà principalmente per consultare i materiali tenere sotto controllo se nuovi file vengono caricati attraverso le API fornite.  L'utilizzo di questa applicazione potrebbe essere utile per tutto il periodo di lezioni e anche durante il periodo d'esami. In uno specifico scenario, all'inizio del semestre per la scelta degli eventuali corsi non obbligatori nel piano di studi o solo per avere un'idea su di essi; o più di frequente, per consultare gli eventi personali e per il download di materiali relativi alle lezioni e per ricevere avvisi istantanei o aggiornamenti sugli eventi e corsi d'interesse. Contesto: StudyMate è pensata per essere utilizzata in qualsiasi contesto fisico all'interno del campus. Per quanto riguarda il contesto sociale, come tutte le altre applicazioni SmartCampus, è stato progettato sia in italiano che in inglese. In realtà, l'inglese è considerato ormai il linguaggio standard per l'intercomunicazione ed è diretto a tutti nel campus. Ma dato che gli utenti finali avranno diversi livelli di linguaggio a seconda della facoltà è bene gestire sia l'italiano che l'inglese.

13 Tecnologie: Le tecnologie possono permettere di svolgere una serie di operazioni e di solito consiste nel consultare rapidamente informazioni provenienti da quanti più utenti possibili nel contesto. Dal momento che Android è il sistema operativo mobile più usato, e inoltre è il sistema con cui vengono create tutte le applicazioni SmartCampus, la piattaforma disponibile corrente per l'accesso a StudyMate dev'essere Android. Inoltre, per ottenere l'accesso alle funzionalità dell'applicazione la tecnologia principale che deve essere presente nei dispositivi è la connettività Wi-Fi o la rete mobile, perché tutte le informazioni che StudyMate mette a disposizione sono online. Per l'accesso ad internet dell’utente target non è un problema nel contesto principale di utilizzo (l'università), in quanto l’Università degli Studi di Trento fornisce il servizio Wi-Fi per permettere l'accesso a Internet a tutti gli studenti iscritti. L'interfaccia grafica contenuta nel display touchscreen dello smartphone deve essere intuitiva e facile, per dare agli utenti la possibilità di interagire rapidamente con il sistema. 3.4 Mockups di media fedeltà Nel caso di StudyMate nella prima fase di design sono stati sviluppati direttamente dei mockups a media fedeltà, che mostrerò in seguito, e che sono il risultato di un processo di redesign dalla proposta iniziale. Il passaggio dalla progettazione dei mockups a bassa fedeltà è saltato, in quanto si è arrivati a questo punto della progettazione con le idee già abbastanza chiare, grazie ancora una volta al lavoro fatto durante il corso, compresi i mockups a bassa e media fedeltà di Scholar. Per realizzarli ho seguito un approccio Expert-Based, che si riferisce a qualsiasi forma di valutazione dell'usabilità che coinvolge un esperto in HCI che può stimare la probabilità di ottenere un interfaccia usabile per una data popolazione di utenti. In tali casi, gli utenti non sono impiegati e la base per la valutazione risiede nell'interpretazione e il giudizio del valutatore. C'è un notevole interesse per questa forma di valutazione, dal momento che può produrre risultati più velocemente. Perciò, l'interfaccia è stata progettata usando metodi euristici basati sulle linee guida di progettazione che riflettono il giudizio dell'esperto di come l'interfaccia è conforme alla buona pratica di progettazione, il che porta a limitare la maggior parte dei problemi di usabilità. Le euristiche su cui mi sono basato sono quelle di Nielsen. Le 10 euristiche di Nielsen (1993) sull’usabilità delle interfacce, derivano dall’applicazione di tecniche di analisi fattoriale su 249 problemi di usabilità, e quindi sono basate sull'esperienza. Il lavoro di progettazione dei mockups è stato diviso tra me ed il mio collega Luca Micheli. Per far capire la visione d’insieme dell’applicazione

14 presenterò tutti i mockups, ma specificherò quelli che non sono stati fatti da me. L'applicazione è formata da quattro diverse sezioni. 3.4.1 Home La schermata di home dell'applicazione dovrà essere composta da icone e labels facilmente riconoscibili e che rendano immediatamente l'idea all'utente della loro funzione. Si è scelto di usare questo pattern di progettazione per seguire lo stile delle applicazioni SmartCampus già esistenti. 3.4.2 Agenda L'agenda serve a dare allo studente la panoramica dei prossimi eventi a cui dovrà partecipare, riferiti ai corsi da libretto che deve ancora superare e i corsi di interesse che può settare manualmente. Queste due tipologie di corsi devono essere differenziate. Ci dovrà essere anche la possibilità di filtrare gli eventi per corso e poter aggiungere dei nuovi eventi personali. Queste informazioni sono Contenute in 2 tab: nella prima tutti i prossimi eventi (lezioni, esami) dei corsi da libretto con la possibilità per ognuno di vederne i dettagli. Nella seconda, la lista dei corsi (da libretto non superati e di interesse) e per ognuno si potranno filtrare gli eventi e vederne come prima i dettagli. Nella Figura 3

15 home dell'agenda attraverso l'icona nella actionBar si potrà andare nella schermata di inserimento di un evento personale. I successivi mockups (Figura 3) sono stati progettati da Luca Micheli. Figura 4 3.4.3 Ricerca dei corsi L'utente può eseguire una ricerca avendo la possibilità di basarsi su più filtri: per dipartimento, per corso di laurea e per nome del corso digitato. La ricerca genera la lista dei corsi trovati e cliccando sul corso che si è interessati si può entrare nella schermata di home del corso.

16 Figura 5 3.4.4 Home dei corsi Nella home del corso sono presenti le informazioni generali e le relative recensioni degli studenti che l'hanno frequentato e superato. Queste informazioni dovranno essere divise in due tab: la prima mostra le informazioni del corso con le relative valutazioni medie per ogni ambito di valutazione, la descrizione del corso e la possibilità di selezionare questo corso come corso di interesse. In altre parole poterlo impostare come "corso che seguo", e cioè aggiungerlo alla lista degli eventi e delle notifiche. La seconda tab contiene la lista di tutte le relative recensioni degli studenti che l'hanno frequentato e superato. E' inoltre possibile dare una recensione personale del corso (soltanto se lo studente ha già superato tale corso).

17 Figura 6 3.4.5 Materiali Questa parte dell'applicazione non è stata progettata da me, ma la descrivo per dare una visione d'insieme di tutta l'applicazione. Si possono vedere i materiali didattici dei corsi che si stanno seguendo e di interesse, divisi tra materiali ufficiali e non ufficiali. I materiali ufficiali dovranno essere reperiti da esse3, mentre quelli non ufficiali da povoshardlife. Figura 7

18 3.4.6 Notifiche In questa sezione dell'applicazione si possono vedere le notifiche della bacheca dell'università e le informazioni relative ai corsi che si stanno seguendo. Le informazioni possono essere riguardanti la modifica o la cancellazione di lezioni, appelli d'esame, l'aggiunta di nuovi materiali didattici. Figura 8 3.5 Valutazione dell'usabilità Il terzo passo dell'interaction design è verificare sul campo se il design progettato è un buon design. Per questo è stata eseguita una valutazione di usabilità dell’applicazione che permette di individuare eventuali problemi da risolvere nell’interazione con l’utente. Più precisamente ho chiesto a 5 utenti di eseguire dei task ed ho utilizzato il metodo thinking aloud per la valutazione (il più indicato, soprattutto per la valutazione di prototipi di media fedeltà). Per la raccolta dei dati invece, ho registrato il tutto con un video per poter successivamente riascoltare i commenti e valutare le reazioni durante vari task ed analizzare i dati. L'esperienza ottenuta durante il corso mi ha permesso di scegliere nel miglior modo possibile il modo in cui avrei dovuto eseguire la valutazione. Visti i pochi utenti presi in considerazione, durante l’analisi dei dati, è stato usato inoltre il metodo cognitive walkthrough. Per ogni azione dell'utente ho cercato di una risposta alle seguenti quattro domande:

19 1. L'utente sarà messo nelle condizioni di formulare un piano di azione corretto? 2. L'azione corretta è visibile nel momento in cui si è deciso di compierla? 3. Dopo avere individuato l'azione corretta da effettuare, l'utente sarà possibilitato a compierla? 4. Dopo avere eseguito l'azione corretta, l'utente riceverà un adeguato feedback che lo informi del raggiungimento del proprio obiettivo? Qui di seguito (tabella 1), sono riportati i dati principali degli utenti che hanno partecipato alla valutazione. Numero partecipante 1 2 3 4 5 Nome Thomas Cristina Cecilia Simone Francesca Sesso M F F M F Età 22 21 22 22 23 Campo di studi Informatica Scienze cognitive Scienze cognitive Informatica Matematica Tabella 1 Prima di procedere con la valutazione, ho analizzato i requisiti dell’applicazione ed ho selezionato i task più importanti da dare agli utenti, ma non potendo farli eseguire tutti è stato necessario scegliere i più importanti e più critici per l'applicazione. Quindi, agli utenti è stato chiesto di svolgere i seguenti 5 tasks:  Cercare un corso.  Vedere i feedback di un corso.  Aggiungere manualmente un corso ai preferiti.  Vedere i prossimi impegni filtrati per il corso appena aggiunto.  Dare una recensione ad un corso. I risultati che ho raccolto ed elaborato mi hanno portato a definire un grado di severità per ogni problema riscontrato. La scala che ho utilizzato è la Nielsen severity scale, che prevede una scala di gravità da 0 a 4.

20 # Nielsen severity scale 0 Non è un problema di usabilità. 1 Problema estetico. Non è necessario che sia risolto, a meno che ci sia tempo disponibile. 2 Problema di usabilità minore: dovrebbe essere data priorità bassa per risolverlo. 3 Problema di usabilità principale: è importante risolverlo, dovrebbe essere data la massima priorità. 4 Usabilità disastrosa: è imperativo risolvere questo problema prima che il prodotto venga rilasciato. [Nielsen severity ratings] Qui sotto è riportata la tabella finale con alcuni dei problemi riscontrati alla fine della fase di valutazione. # Nielsen’s severity rating Descrizione Screenshot Soluzione 2 1 Dalla schermata recensioni, all’utente è immediatamente chiaro che per valutare un corso si debba premere il bottone “Rate”. Ma se all’utente si chiede di valutare un corso dalla Home, non sempre è immediato andare in MyAgenda per valutare un corso. Il nome “MyAgenda” dovrebbe essere cambiato con un altro nome. Es: “Mycourses Calendar” 3 2 Problema di comprensione del significato delle 2 liste. L’utente non capisce in modo immediato la differenza tra la prima lista e la seconda. Viene riconosciuta la differenza nella maggior parte dei casi per la scritta “Corso che seguoX”. Dovrebbero essere inserite delle label per informare l’utente se si trattano di corsi da libretto o corsi di interesse.

21 4 3 Problema di comprensione delle icone “+” per l’aggiunta del feedback del corso. Le icone dovrebbero essere sostituite con altre che rendano più l’idea di aggiungere un feedback. Ad esempio lasciare il simbolo “+” per dar l’idea di aggiunta ma magari dentro ad una “stella”. Tabella 2 In conclusione, i dati ottenuti dalla valutazione di usabilità ha riportato che sono stati riscontrati soltanto un problema di usabilità maggiore e principalmente problemi di usabilità minori od estetici, probabilmente alcuni sono causati dalla fedeltà stessa dei prototipi, in quanto non possono dare lo stesso feedback di un’interfaccia finale per l’utente. 3.6 Redesign e revisione dei requisiti I dati raccolti durante la fase di valutazione dell'usabilità dei prototipi costruiti hanno permesso di individuare dei problemi di usabilità sfuggiti durante la prima progettazione dell'interfaccia. Il processo di redesign è indispensabile per arrivare alla progettazione di un'interfaccia soddisfacente. I problemi riscontrati durante la valutazione dei mockups interattivi sono di due tipologie: di usabilità (vedi tabella della valutazione) e concettuali. Il problema concettuale riscontrato è che la metodologia delle valutazioni dei corsi non è stata affrontata in modo adeguato. Questo aspetto è molto delicato per l'applicazione, in quanto è una delle funzionalità principali. 3.6.1 Sistema di valutazione dei corsi Per avere delle valutazioni più veritiere ed utili per la comunità si è dovuto porre dei vincoli. Usare come metro di valutazione di un corso soltanto un punteggio da 1 a 5 era troppo vago. Quindi, si è deciso di fare un'analisi più approfondita su quali siano gli aspetti più significativi ed importanti per

22 descrivere un corso. La stessa cosa vale per chi può dare una valutazione ad un corso. Ne è uscito che ogni studente potrà valutare i corsi in base alle seguenti regole:  Per poter recensire un corso, sarà necessario che lo studente abbia passato quel determinato esame. Far recensire un corso dopo averlo frequentato non è possibile, visto che la frequenza è quasi mai obbligatoria;  Ogni studente potrà dare una sola recensione per corso;  La recensione personale per un corso può essere modificata. La privacy dei commenti è stato un punto importante nella progettazione di StudyMate. Essendo un sistema di valutazione, si deve tenere conto che non ci potranno essere soltanto commenti positivi. Lo scopo è quello di far capire alla comunità quali sono gli aspetti positivi ma anche negativi di un determinato corso. Quindi, si è scelto che ogni commento e valutazione che si visualizzerà sarà associato al nome dello studente (solo il nome), che è il giusto compromesso tra libertà di valutazione e controllo. Un'altra scelta potrebbe essere quella di tenere anonimi tutti i commenti o dare la possibilità all'utente di avere un nickname. Il sistema di valutazione segue sistemi già utilizzati come Google play, TripAdvisor e molti altri. Ogni valutazione viene data in “stelle” (da 1 a 5) e basata su più parametri di valutazione che descriverò in seguito. I parametri di valutazione che riassumano gli aspetti principali di un corso saranno: Contenuti: valuta l’interesse per i contenuti del corso e la rilevanza all’interno del corso di studi. Più è alto il punteggio e più sarà un corso dai contenuti interessanti e rilevanti per il corso di studi. Carico di Studio/cfu: valuta la quantità di tempo da spendere per prepararsi all’esame in base ai cfu del corso. Più è alto il punteggio e più il carico di lavoro sarà ben proporzionato con i cfu. Lezioni: valuta la qualità generale delle lezioni (come sono organizzate, le spiegazioni del professore) e quindi la loro importanza per passare l’esame. Più è alto il punteggio e più le lezioni sono interessanti, il professore espone bene gli argomenti, e quindi vale la pena andare a lezione. Materiali: valuta la qualità dei materiali dati a disposizione dal professore in relazione agli argomenti da preparare per l’esame. Più è alto il punteggio e più i materiali dati o segnalati dal professore sono adeguati per prepararsi bene all’esame. Più è basso il punteggio e più lo studente dovrà cercare da se materiali aggiuntivi per potersi preparare. Esame: valuta la fattibilità di superare un esame sapendo gli argomenti studiati. Più è alto il punteggio e più le competenze richieste all’esame sono allineate con gli argomenti trattati a lezione. Più è basso il punteggio e più l’esame è particolarmente impegnativo. Commento generale: Oltre ai parametri precedenti lo studente potrà dare un sul corso, che può essere una valutazione generale o consigli particolari per superare l'esame.

23 3.6.2 Redesign La valutazione dell’usabilità effettuata ha portato ad una rivisitazione dei requisiti e di conseguenza di alcuni aspetti del design. Di seguito sono riportati i mockups rivisitati. Nella lista delle recensioni, l’utente potrà visualizzare inizialmente, per ognuna, una valutazione generale data dallo studente. Tale valutazione è calcolata dalla media delle valutazioni date dallo studente per i diversi aspetti di un corso. Lo studente potrà comunque vedere in dettaglio ogni valutazione data per aspetto e l'eventuale commento finale. Nella home del corso invece, saranno direttamente visibili in specifico le valutazioni medie per ogni aspetto. A sinistra: Visualizzazione delle recensioni relative ad un corso. A destra: Visualizzazione delle informazioni specifiche di una recensione cliccata nella lista espandibile. Figura 9

24 Figura 10 A sinistra: Home del corso che mostra le valutazioni medie per ogni aspetto. A destra: Schermata per l'aggiunta di una nuova recensione.

25 4 Front end Passiamo ora ad una sezione più tecnica dove illustrerò in primo luogo l’evoluzione finale dell’interfaccia grafica e successivamente come è stata sviluppata StudyMate nella seconda fase del suo sviluppo, in particolare le principali parti che ho sviluppato, i problemi riscontrati, ed i relativi concetti teorici che ho incontrato. Questa fase si basa sui dati raccolti durante la fase di interaction design, che ne hanno definito i principi di design ed i requisiti necessari per il suo sviluppo della parte Android. E’ stato molto importante aver fatto un buon lavoro nella fase precedente per permettere uno sviluppo più rapido ed un prodotto finale migliore per l’utente. 4.1 Implementazione finale dell’interfaccia grafica In questa fase di implementazione dell’interfaccia mi sono occupato in parte (home dei corsi, ricerca dei corsi, sezione recensioni), in quanto la maggior parte dell’interfaccia è stata progettata principalmente dal mio collega, mentre io mi occupavo della parte logica e di comunicazione dei dati con il server dell’applicazione. Quando si è partiti con lo sviluppo dell’interfaccia abbiamo creato un tema generale per l’applicazione utilizzando un tool online (android-ui-utils.googlecode.com/hg/asset- studio/dist/index.html) dove è possibile generare i colori e gli stili di ogni componente. Lo stile generato dev'essere inserito nella cartella res/values/ e dichiarato nel manifest.

26 4.1.1 Ricerca dei corsi La funzionalità della ricerca di un corso (Figura 18) ha un’interfaccia composta da una ActionBar. Per dare più visibilità alle scelte fatte nello spinner anche mentre si sta digitando con la tastiera il nome di un corso si è scelto di mantenere i componenti in alto e non disperderli nello schermo e di usare come azione per la ricerca una lente. Lo screenshot dei risultati della ricerca (Figura 17) mostra all’utente le informazioni sulla ricerca appena effettuata, quali filtri sono stati usati e la lista dei corsi trovati con il matching. Nel capitolo di Interaction Design erano stati illustrati i mockups dove si può vedere che erano previsti oltre ai nomi dei corsi, anche delle icone. L’idea delle icone è stata tralasciata per rendere più pulito il design e non è stato considerato un requisito indispensabile. Figura 16 Figura 17 Figura 11 Figura 12

27 4.1.2 Home dei corsi Figura 14 La Home dei corsi ha il compito di contenere le informazioni principali di un determinato corso. Nella prima tab sono contenute le informazioni del corso, il voto medio degli studenti e se il corso è uno dei personali corsi di interesse. L’ActionBar contiene come action una “stella” che permette all’utente di passare a fare una recensione di tale corso. Sulla destra (Figura 18), è presente la valutazione media generale e le medie di tutti i voti per ogni aspetto della valutazione. Figura 13

28 4.1.3 Recensioni Figura 15 Figura 16 Nella seconda tab della Home di un corso sono contenute le recensioni degli studenti per il corso di riferimento. Per dare più visibilità e accesso alle informazioni delle recensioni, è stata implementata una ExpandableListView, dove ogni riga di essa è composta da una GroupView e zero o più ChildView (in questo caso soltanto una). Ogni GroupView contiene il nome dello studente e il voto medio per i vari aspetti della valutazione dello studente. Toccando questo elemento verrà aperta la ChildView che contiene tutti i voti dati ed un eventuale commento. Tale scelta è stata fatta per accedere più velocemente a tutte le recensioni ma allo stesso tempo non sarebbe stato possibile dal punto di vista dell’usabilità far visualizzare tutte le informazioni di tutti gli studenti direttamente.

29 4.1.4 Aggiunta di una recensione Se lo studente tenta di dare una recensione ad un corso che non ha superato verrà avvisato con un Toast che non è possibile dare la recensione (Figura 23). Figura 18 L’Activity di aggiunta della recensione è composta (come per la visualizzazione delle recensioni) da una ExpandableListView, dove per ogni aspetto viene fatta una domanda specifica per evitare incongruenze. Nella prima versione del design l’unico modo per avere accesso alla pagina di aggiunta delle recensioni era dalla ricerca di un corso e dall’agenda. Successivamente è stata rivista Figura 17

30 l’importanza di questa funzionalità, per cui è stata resa disponibile direttamente nella schermata di home dell’applicazione (Figura 25). Figura 19

31 4.2 Android Android è un sistema operativo per dispositivi mobili basato sul sistema operativo open source Linux. Android ha avuto un percorso evolutivo molto rapido e con un incremento delle feature offerte. Questo da un lato creato in pochi anni un sistema operativo solido e molto user-friendly ma dall’altro lato ha portato i produttori ad una corsa nell’aggiornamento del software e dell’hardware, lasciando una grossa frammentazione tra le varie versioni software. Ecco una situazione aggiornata per la distribuzione delle varie versioni di Android sui vari smartphone in tutto il mondo. Il Sistema operativo Android è organizzato in un’architettura software formata da più strati che include un Sistema operativo di base, i middleware per le comunicazioni e le applicazioni di base. Kernel Layer: Android è costituito da un kernel basato sul kernel linux versione 2.6 e 3.x (da Android 4.0 in poi), utilizza la DVM(Dalvik virtual machine) con un JIT(Compilatore just in time, dalla versione Android 2.2, che serve per gestire in modo dinamico la traduzione del bytecode nel codice macchina nativo in fase di run-time), per l'esecuzione di Dalvik dex-code (Dalvik Executable). [Kernel layer Android] Libraries: Gestiscono l’accesso ai principali elementi di un dispositivo mobile. Ad esempio la gestione dell’accesso al display, gestione del supporto dei formati multimediali, gestione delle funzionalità del database SQLite. Android Runtime: Ambiente di esecuzione delle applicazioni scritte in Java e basato sulla DVM (Dalvik virtual machine). Figura 20

32 Application framework: Fornisce servizi evoluti alle applicazioni, come la gestione delle varie funzionalità basilari del dispositivo. Applications: E’ il livello più alto e comprende le applicazioni. Android, nativamente fornisce a corredo con il sistema applicazioni come l’agenda, la rubrica, la messaggistica e altro. [Android layers] Di seguito (paragrafo 4.3) illustrerò i principali componenti usufruiti dello strato Application framework. Figura 21

33 4.3 Metodologie di implementazione La fase di sviluppo in Android dell’applicazione è stata la parte più importante, cioè mettere in pratica tutti i dati raccolti ed i requisiti analizzati nella fase di ID (Interaction design). Dopo aver preparato l’ambiente di sviluppo Android si è passati alla fase di auto formazione. L’implementazione è stata un processo graduale, in quanto le conoscenze di Android erano scarse. E’ stato fondamentale avere già dei mockups di media fedeltà che rappresentano in modo chiaro la struttura dell’applicazione, ed i requisiti che deve avere, in quanto ha permesso di focalizzare lo studio delle conoscenze di Android in modo più veloce ed efficiente. Per compiere i primi passi si è passati al processo di formazione sui principali costrutti che compongono il sistema Android, in particolare quel che riguarda lo strato di Application framework. I componenti principali e indispensabili da conoscere per cominciare ad implementare le basi dell’applicazione StudyMate sono stati: Activity, Manifest, ActionBar, Fragment, Adapter, Intent e i principali componenti grafici come ListView, Spinner, TextView. Per garantire la compatibilità dell’applicazione dalla versione 2.2 in poi, è stata utilizzata una libreria di supporto Sherlock, dove i componenti Activity, Fragment, ActionBar sono stati sostituiti dai relativi componenti della libreria (SherlockActivity, SherlockFragment, ActionBarSherlock). La loro logica di utilizzo comunque non cambia rispetto alla libreria nativa resa disponibile da Google.

34 4.3.1 Activity Un’Activity è la classe che gestisce il ciclo di vita e l’interazione tra l’utente e l’applicazione in una finestra che contiene l’interfaccia dell’applicazione. Dal momento in cui viene lanciata l’applicazione e quindi un’Activity, fino al momento in cui usciamo dall’applicazione, essa passa attraverso varie fasi. Capire bene il ciclo di vita di un’Activity è stato fondamentale per assicurare un corretto funzionamento dell’applicazione. La super classe Activity definisce una serie di eventi che governano il ciclo di vita di un’Activity. Spetta poi alle classi che estendono da Activity implementarli. Questi eventi sono: onCreate(): chiamato quando viene lanciata per la prima volta; onStart(): chiamato quando diventa visibile all’utente; onResume(): chiamato quando è pronta ad interagire con l’utente; onPause(): chiamato quando viene messa in pausa ed una precedente viene ripristinata, o viene parzialmente coperta da un'altra View; Figura 22

35 onStop(): chiamato quando non è più visibile all’utente; onDestroy(): chiamato prima che l’activity venga distrutta, anche se solitamente rimane in memoria quindi principalmente viene chiamato quando si elimina dallo stack manualmente o quando il sistema operativo la elimina per liberare memoria. Questo tipo di gestione velocizza l’apertura delle applicazioni che rimangono nello stack e allo stesso momento non utilizzano CPU; onRestart(): chiamato dopo l’onStart nel caso in cui in precedenza fosse stata stoppata, mentre viene chiamato direttamente se in precedenza fosse stata messa in pausa. 4.3.2 Intent L’Intent è un oggetto necessario per far collaborare tra di loro le Activity, ed è possibile catalogare gli Intent in due tipologie: Intent esplicito ed Intent implicito. Nel caso in cui venga specificato il gestore dell'Intent si parlerà di Intent esplicito. Questo tipo d’uso dell’Intent è utilizzato principalmente per richiamare altre Activity all'interno dell'applicazione chiamante. Viceversa si parla di Intent implicito, il quale è utilizzato principalmente per richiamare componenti di altre applicazioni. Qui un frammento di codice di StudyMate per richiamare un'Activity e passare ad essa delle informazioni extra, ad esempio in questo caso, il riferimento di quale corso è stato selezionato nella ListView. Intent intent =new Intent(); intent.setClass(currentActivity, AddRatingFromCoursesPassed.class); intent.putExtra("NomeCorso",corsoSelezionato.getNome()); intent.putExtra("IdCorso", corsoSelezionato.getId()); currentActivity.startActivity(intent); Figura 23

36 4.4 Organizzazione Per lo sviluppo di StudyMate, ho collaborato anche con il mio collega di stage Luca Micheli, e per farlo in modo più efficiente possibile è stata seguita la stessa metodologia di lavoro in team di SmartCampus. Per organizzare e dividere il lavoro sono stati fissati meeting settimanali oppure ogni due settimane, gestiti dai nostri tutor aziendali in base alla quantità di ore che eravamo disposti a dedicare per l’implementazione. Tali meeting sono serviti per fissare gli obiettivi e le scadenze dello sviluppo delle varie funzionalità, utilizzando la metodologia scrum e dando ad ogni lavoro un peso in ore. Questo tipo di pianificazione è stata molto importante per avere sempre in mente gli obiettivi da raggiungere, le scadenze e capire meglio l’importanza dei meeting e del confronto tra colleghi per lo sviluppo in team di un software. Se c’era un momento di difficoltà durante lo sviluppo di qualche particolare funzionalità, gli sviluppatori più esperti sono sempre stati disponibili a dare delucidazioni e consigli su come superare il problema. Per quanto riguarda l’organizzazione dell’implementazione vera e propria è stato utilizzato GitHub, lo stesso tool utilizzato per l’organizzazione dello sviluppo di tutte le applicazioni di SmartCampus. GitHub è un servizio web di hosting per lo sviluppo di progetti software che usa il sistema di controllo di versione Git (che è stato installato come plugin in eclispe), ed è un controllo di versione distribuito. Nei sistemi di controllo versione distribuiti ogni modifica può essere fatta e inviata al server in un secondo momento, rispettivamente con i comandi commit e push. 4.5 Comunicazione con il server Tutte le informazioni come i corsi, i dipartimenti, i corsi di laurea, gli eventi, le recensioni, i corsi superati, i corsi di interesse sono mantenute in un apposito server. Durante lo sviluppo ci si è trovati davanti al problema di richiedere i dati al server e farli visualizzare all’utente evitando di bloccare la UI, oltre che progettare un modello di gestione dei dati facilmente accessibile dalla parte grafica. Perciò è stato implementato il nucleo dell’applicazione con una apposita business logic. Sono state create varie classi di supporto che hanno il compito di fare una richiesta asincrona in background al server estendendo l’oggetto AsyncTask, e ricevere i dati mappandoli attraverso l’apposito modello dati compatibile con i dati che arrivavano dal server, per facilitare l’accesso dalla parte di gestione dell’interfaccia. Il formato dello scambio dei dati tra client e server utilizzato è JSON (paragrafo 4.5.2).

37 4.5.1 AsyncTask In Android, i task che occupano tempi lunghi che non siano ad esempio il passaggio tra un’Activity ad un'altra, non devono essere eseguiti nel thread principale dell’applicazione. Infatti, il thread principale è quello della UI e in Android può essercene soltanto uno durante l'esecuzione di un'applicazione, ed in ogni momento deve occuparsi di gestire gli eventi che arrivano dall’interfaccia. Se questo thread è già occupato ad eseguire qualcos’altro non può occuparsi della gestione degli eventi e se il thread principale viene occupato per un’operazione per più di 5 secondi l’applicazione va in crash. Ovviamente tutto ciò deve essere evitato. Android mette a disposizione l'oggetto AsyncTask: AsyncTask Dove i parametri generici sono passati al momento della chiamata del metodo execute(), e sono: Params: contiene parametri liberi che possono servire nell’esecuzione dell’AsyncTask, in particolare nel metodo doInBackground; Progress: è usato per notificare un avanzamento del caricamento dell’oggetto passato. Durante le operazioni in background è possibile richiamare il metodo publishProgress passando l’oggetto aggiornato e successivamente viene chiamato il metodo onProgressUpdate in cui è possibile sapere com’è il progresso dell’operazione. Result: è l’oggetto che viene restituito alla fine dell’AsyncTask e passato come parametro nel metodo onPostExecute(). I metodi in cui è necessario fare l’override per utilizzare gli AsyncTask sono i seguenti: onPreExecute(): viene invocata nel thread principale prima che il task sia eseguito. E’ stato utilizzato maggiormente per gestire le operazioni preliminari alla chiamata al server, solitamente per far visualizzare il caricamento della ProgressBar. doInBackground(Params...): viene chiamato subito dopo che l’onPreExecute() ha finito la sua esecuzione. Utilizza un thread in background in cui vengono eseguiti i task asincroni. Nel caso di StudyMate è stato utilizzato per eseguire le chiamate al server. onProgressUpdate(Progress…): invocato nel thread principale immediatamente dopo la chiamata del metodo publishProgress.

38 onPostExecute(Result): invocato nel thread principale subito dopo la fine delle operazioni eseguite in doInBackground. Nel nostro caso è stato utilizzato solitamente per riempire la lista dei risultati ottenuti per farli visualizzare all’utente, oltre che togliere dall’interfaccia la ProgressDialog. 4.5.2 JSON JSON (JavaScript Object Notation) è uno dei formati adatto allo scambio di dati in architetture client- server. E’ in formato di testo ed esso è completamente indipendente dal linguaggio di programmazione usato. La strutturazione di JSON è divisa in due parti: • Un’ insieme di coppie nome/valore. Similarmente agli oggetti o struct in altri linguaggi. • Un elenco ordinato di valori. I tipi di dato supportati sono: • booleani (true e false); • interi, reali, virgola mobile; • stringhe racchiuse da doppi apici ( " ); • array (sequenze ordinate di valori, separati da virgole e racchiusi in parentesi quadre [ ]; • array associativi (sequenze coppie chiave-valore separate da virgole racchiuse in parentesi graffe); • null. [JSON] Un esempio di oggetto JSON per il corso di laurea ritornato nel body della risposta della richiesta HTTP data dal server è il seguente: {"id":2, "nome":"Informatica Triennale", {"id":1,"nome":"Dipartimento di ingegneria dell'informazione"}}

39 4.5.3 Implementazione L'implementazione del codice per la comunicazione con il server ha portato alla gestione delle richieste HTTP al web service. Ho utilizzato la libreria ProtocolCarrier di SmartCampus, che si occupa della gestione delle richieste. Dopo la preparazione del messaggio di richiesta al server (request) si può utilizzare il metodo invokeSync in cui va specificato oltre che il MessageRequest creato, anche il nome del token, ed il token utente. Tale metodo invia la richiesta asincrona al server e salva nella response la risposta. L’oggetto di risposta è un oggetto JSON presente nel body della response, il quale successivamente viene convertito in oggetto o in lista di oggetti con il metodo convertJSONToObjects. Qui in seguito (Figura 25) si può vedere lo schema generale di funzionamento generale per tutte le chiamate al server. Figura 24 La difficoltà maggiore nell’implementare gli AsyncTask è stata la gestione delle richieste all’interno dei Fragment e di capire a fondo il ciclo di vita delle Activity, dei Fragment, soprattutto quando c’è stato il bisogno di implementare più richieste al server nella stessa activity ma in diversi Fragment. Ma in generale ci è voluto del tempo per gestire in modo adeguato i thread in background per le operazioni più lunghe ed il thread principale.

40 5 Piattaforma SmartCampus ha sviluppato una piattaforma che fornisce i servizi di base alle applicazioni costruite sopra di essa. Questo serve alle applicazioni poter comunicare e collaborare tra di loro e facilitarne lo sviluppo di nuove. Figura 25 La Piattaforma SmartCampus è composta di tre elementi principali (Figura 3): la parte core (a destra) contiene diversi engine (componenti di base dei servizi come la gestione della navigazione per ViviTrento), che sono indipendenti, ed ognuno è collegato a dei servizi core che sono a loro volta accessibili dall'esterno. Per sviluppare StudyMate non è stato necessario conoscere il funzionamento degli engine, ma soltanto dei servizi core (servizio di autenticazione e servizio di comunicazione li descriverò in seguito), in quanto hanno la funzione di fare da interfaccia attraverso delle API. I dati all'interno sono protetti tramite l'AC (access controller) che nega l'accesso ai file agli esterni. L'AC permette l'accesso ai servizi e quindi agli engine attraverso un access token. La parte client (a sinistra) contiene la parte client che contiene a sua volta la piattaforma Android (che descriverò nel capitolo 4) e le librerie di SmartCampus che si appoggiano ai servizi core. La open platform PaaS (Platform as a service) basata su Cloud Foundry (al centro) permette costruire le proprie applicazioni attraverso dei frameworks (java, mysql, mongoDB, eccetera).

41 Di seguito illustrerò tutti i componenti core della piattaforma che ho utilizzato per lo sviluppo di StudyMate, ed il controllo dell’accesso a tali componenti. 5.1 Autenticazione e controllo dell’accesso Ogni applicazione SmartCampus deve riconoscere in ogni momento chi è l’utente che sta utilizzando l’applicazione. Quindi per utilizzare i servizi che fornisce la piattaforma ci deve essere un controllo dell'accesso. L’AC fornisce una libreria il cui obiettivo è quello di facilitare la procedura di autenticazione e autorizzazione, per le applicazioni. In particolare, la libreria permette diversi scenari di utilizzo tra cui:  Un’applicazione Android standalone, che indipendentemente esegue le procedure per richiedere l’accesso. Così facendo, avendo maggiore flessibilità;  Un'applicazione Android centralizzata (Launcher SmartCampus), attraverso la quale le applicazioni client gestiscono il controllo dell’accesso. E' utilizzato il protocollo OAuth2.0 per l'autorizzazione dell’accesso alle risorse, mentre per l'autenticazione utente viene utilizzato un provider di identità esterno (come Unitn, Google, FBK). Il protocollo OAuth 2.0 impone il seguente schema comune per accedere alle risorse protette SmartCampus: Registrare l’applicazione client: L'applicazione che vuole accedere ad una risorsa protetta della piattaforma deve essere registrata tramite la console degli sviluppatori. Da questa console gli sviluppatori possono ottenere i valori di attributi come client_id, client_secret, necessari per autorizzare l’utente all’accesso alle risorse protette ottenendo il token d’accesso corrispondente. Le risorse protette alle quali si vuole avere accesso devono essere selezionate dallo sviluppatore sempre nella console. Ottenere il token di accesso dal server di autorizzazione: Per accedere alle risorse SmartCampus si deve ottenere un token di accesso dal server di autorizzazione. Sono supportati due tipi di token: il token dell'utente (user auth token), che concede l'accesso alle risorse se è l'utente che deve effettuare una richiesta, e il token dell’applicazione (client auth token), che consente l'accesso alle risorse se l'applicazione deve effettuare una richiesta. Accedere alle API tramite il token di accesso: Una volta ottenuto un token di accesso (user o client), l'applicazione può effettuare richieste alle risorse protette. Il token di accesso viene inviato

42 nell'intestazione Authorization in HTTP. La richiesta di accesso ad una risorsa non autorizzata si tradurrà in un errore. Aggiornare il token di accesso: I token di accesso (user o client) hanno una durata limitata e, in alcuni casi, potrebbe essere necessario accedere alla risorsa oltre la durata di un singolo token di accesso. In questo caso l'applicazione può sfruttare il token di aggiornamento (refresh token) che consente all'applicazione di ottenere di nuovo token di accesso. 5.2 Servizi core I servizi core di SmartCampus che ho utilizzato per lo sviluppo di StudyMate sono stati: Profile service: per la gestione del login e dei dati dell’utente che usa l’applicazione. Moderator service: per la moderazione dei contenuti delle applicazioni SmartCampus, ma che tratterò più in dettaglio nel capitolo 7. 5.2.1 Profile service Il profile service è un servizio che fornisce gli strumenti necessari per la gestione del profili utente. Sono gestiti tre tipologie di profili:  Basic Profile: è il profilo base per l’utente contenente le informazioni principali (nome, cognome, socialID). Questo tipo di profilo è di sola lettura ed è il profilo che è stato utilizzato per lo sviluppo di StudyMate.  Account Profile: è il profilo che contiene le informazioni dell’account con cui si fa il login (es. Google, Unitn, FBK). Anche questo profilo è di sola lettura.  Multiple Extended Profiles: sono profili estesi multipli che possono essere associati allo stesso utente, associato ad una particolare applicazione e possono avere contenuti personalizzabili. Il servizio espone delle API che permettono di:  Ottenere il Basic Profile dell’utente che effettua la richiesta, il Basic Profile di altri utenti o tutti i Basic Profile (eventualmente filtrati per nome/cognome).  Ottenere l’Account Profile dello user corrente.

43  Operazioni CRUD per l’Extended Profile. Un utente può condividere l’istanza del suo Extended Profile con altri utenti; e a questo scopo è associato ad un'entità sociale per controllare il processo di condivisione attraverso le API del Social service (un altro servizio - SmartCampus, che non tratterò). Per lo sviluppo di StudyMate questo servizio è stato indispensabile per la gestione del profilo dell’utente. Tramite il token di accesso è stato possibile avere il Basic Profile dell'utente loggato all'applicazione.

44 6 Back end In questo capitolo illustrerò come è stato sviluppato il lato back end di StudyMate. Illustrerò in particolare le principali parti che ho sviluppato, i problemi riscontrati, ed i relativi concetti teorici. In questa fase è stato molto importante sincronizzare il lavoro con il lato Android per massimizzare i risultati. La prima fase è stata quella di discutere quali siano tutti i dati di cui avevamo bisogno in base ai requisiti ottenuti dalla fase di interaction design e dall’implementazione e quindi cominciare a costruire un modello che possa permettere una gestione ottimale della persistenza dei dati e della loro disponibilità compatibile con il lato client, oltre che rendere possibile la reperibilità dei dati dell’università. 6.1 Modello di dominio Per prima cosa è stato importante capire a fondo quali siano i problemi stavo andando incontro e capire la via migliore per poterli risolvere, grazie al supporto del mio tutor. Il problema principale che abbiamo dovuto affrontare è stato quello della difficoltà a reperire i dati reali dell’università come:  Informazioni curricolari dello studente;  I dipartimenti;  I corsi di laurea riferiti ad ogni dipartimento;  Le informazioni sui corsi;  La tabella degli orari per ogni corso. I dati basilari di cui l’applicazione aveva bisogno sono esterni a SmartCampus, quindi c’è stato un lavoro di inquadramento del problema e pianificazione ad alto livello di quale sia il modo migliore per poterli gestire. Qui in seguito l’immagine concettuale del problema che il sistema deve risolvere (Figura 26). Esso descrive oggetti e relazioni ma non si occupa di definire come il sistema agisce su tali oggetti. E’ un modo per inquadrare meglio il problema e che mi è servito molto a capire che strada avrei dovuto prendere per poterlo risolvere.

45 Figura 26 Come si può vedere dalla figura le fonti dei dati di cui si ha bisogno provengono da due fonti:  UniPlanner: che contiene gli orari dei corsi, i dipartimenti, i corsi di laurea di tutta l’Università di Trento;  Esse3: che contiene tutte le informazioni accademiche dello studente, compresa la facoltà a cui è iscritto, il corso di laurea, l’anno, i corsi da libretto e i corsi superati. Quello che si deve fare è riuscire ad arrivare a tali dati e gestirli localmente all’interno del server SmartCampus. Il problema è la tempistica di accesso a questi dati causata soprattutto ad aspetti burocratici. Perciò si è cercato comunque di cominciare l’implementazione vera e propria della parte back end di StudyMate con dati fittizi in attesa di ottenere i permessi di accesso ai dati reali. Quindi, come secondo passo si è cercato di creare un modello che poteva essere compatibile con i dati che avrei avuto a disposizione. Dopo un’attenta analisi basata soprattutto sui requisiti che doveva avere l’applicazione, sono state definite delle entità basilari (dopo varie modifiche) che dovevano contenere tutti i dati utili a StudyMate. Tali dati sono:

46  Studente;  Corso;  Dipartimento;  Commento;  Evento; Su queste entità sono partito a definire uno schema ER (modello entity-relationship) per la rappresentazione concettuale dei dati ad un alto livello di astrazione. Questo modello è spesso utilizzato nella prima fase della progettazione di una base di dati in cui è necessario tradurre le informazioni risultanti dall'analisi di un determinato dominio in uno schema concettuale [Modello ER]. Figura 27

47 In questo caso non è stato fatto uno schema ER comprendendo anche gli attributi, in quanto lo scopo in questa fase è stato quello di comprendere ad un livello più alto il modello dei dati, e pensare in seguito agli attributi poiché essi dipendono principalmente dal modello dati fornito dall’università. Questa fase inoltre è servita per definire un’importante entità, quella dei commenti. L’entità commento è l’unica che non è vincolata dai dati universitari, poiché i commenti saranno contenuti creati dagli studenti. Per definire uno schema ER funzionale e fattibile sono passato a fare varie modifiche. Le entità e le relative caratteristiche finali che sono state definite dopo vari cicli di rivisitazione dei requisiti sono: Studente: ogni studente mantiene le proprie informazioni personali; compresi i riferimenti al dipartimento e al corso di laurea a cui è iscritto, i corsi presenti in esse3, i corsi di interesse e i corsi superati. Dipartimento: mantiene le informazioni minimali di un dipartimento CorsoLaurea: mantiene le informazioni minimali di un corso di laurea ed il riferimento al dipartimento a cui è associata. CorsoLite: mantiene le informazioni principali di un corso, ed è stato introdotto per rendere più leggero lo scambio di informazioni client-server nel caso in cui al client servano soltanto i nomi dei corsi. L’id del corso si riferisce al codice del corso dato da esse3; Corso: ogni corso estende gli attributi di CorsoLite e mantiene le informazioni generali prese da esse3 più il rating medio degli utenti per ogni aspetto della valutazione. CommentBaseEntity: mantiene le informazioni di base per la moderazione di un commento Commento: mantiene le informazioni di una valutazione di uno studente riferito ad un corso. Evento: mantiene tutte informazioni di un evento (lezioni ed esami). Un evento dev’essere legato ad un corso. 6.2 Requisiti Per pianificare quali servizi dovesse rendere disponibile il back end, mi sono appoggiato dell’applicazione:  Un'agenda dedicata agli impegni accademici: qui si potranno aggiungere e modificare eventi, aggiungere note agli stessi, condividerli con determinati gruppi di persone. L'agenda consente anche di filtrare gli impegni in base al corso a cui si riferiscono.  Una funzione di ricerca per i corsi offerti dall’Università di Trento.

48  Home dei corsi: per ciascun corso è possibile visualizzare una descrizione e soprattutto valutazioni e commenti espressi dagli utenti, oltre che dare una valutazione personale.  Una visualizzazione dei materiali ufficiali e suggeriti dagli studenti relativamente ai corsi che lo studente sta seguendo o non ha ancora superato.  Un sistema di notifiche che informa l'utente di eventuali modifiche agli eventi che lo interessano. Questa fase è stata una fase parallela al lavoro nel lato Android. Mano a mano che si è implementata l’interfaccia, si sono definiti anche i requisiti che doveva avere il back end. E’ stata una definizione graduale dove i requisiti generali sono:  Il server deve mantenere la persistenza di tutti i dati (sia quelli ottenuti dall’università che quelli generali dagli utenti).  Il server deve gestire la sicurezza delle informazioni personali utilizzando il controllo dell'accesso. Quindi per avere accesso ai dati, l’utente dev’essere autenticato con SmartCampus.  Il server deve avere accesso ai dati di esse3, in particolare: ai dati dello studente, dei corsi, dei dipartimenti, dei corsi di laurea e lo stato della carriera dello studente. I requisiti specifici per ogni entità sono: Studente:  Rendere disponibili i dati personali dell’utente. Dipartimento:  Rendere disponibile la lista di tutti i dipartimenti;  Ottenere le informazioni di un determinato dipartimento. CorsoLaurea:  Rendere disponibile la lista di tutti i corsi di laurea di tutti i dipartimenti;  Rendere disponibile la lista di tutti i corsi di laurea di un determinato dipartimento; Corso / CorsoLite:  Rendere disponibile la lista di tutti i corsi;  Rendere disponibili le informazioni di un determinato corso;  Rendere disponibile la lista di tutti i corsi da libretto dell’utente;  Rendere disponibile la lista di tutti i corsi superati dell’utente; Commento:

49  Rendere disponibile la lista di tutte le valutazioni di un determinato corso;  Rendere disponibile la valutazione personale dell’utente per un determinato corso;  Aggiungere una nuova valutazione Evento:  Rendere disponibile la lista di tutti gli eventi di un determinato corso;  Rendere disponibile la lista di tutti gli eventi personali dello studente. 6.3 Metodi implementati ed esempi Dopo la fase iniziale dove è stato necessario effettuare un’ampia analisi sul modello dei dati e sulle funzionalità che il server deve rendere disponibili al client e in che modo ottenere e mantenere i dati. Come prima cosa è stato necessario documentarmi sulle varie tecnologie con cui avrei dovuto implementare il lato back end di StudyMate. E’ stato importante l’appoggio del mio tutor per indirizzarmi nel lavoro preparandomi uno scheletro base del progetto utilizzando il framework Spring, dal quale mi sono appoggiato per il lavoro di sviluppo. Il processo di formazione e l’implementazione è stata un processo graduale, in quanto le conoscenze di sviluppo delle tecnologie che illustrerò nei prossimi paragrafi erano scarse. L’implementazione è stata un processo sempre sincronizzato con il lato Android ed ha portato, all’implementazione di tre parti distinte:  Model: contiene le classi costruite sul modello dei dati pensato. Ogni classe è stata mappata utilizzando il framework JPA ed ha il compito di gestire la persistenza dei dati, definendo gli attributi nel database e le associazioni tra le Entità. Esse servono inoltre come supporto alla gestione dei dati di scambio tra il client ed il server.  Controller: contiene i controller che gestiscono le richieste del client.  Repository: contiene le interfacce che implementano le classi del modello che andranno a crearsi nel database. Qui in seguito presenterò quali sono state le tecnologie utilizzate ed illustrerò gli esempi principali che hanno caratterizzato il mio lavoro. L’obiettivo finale è quello di creare un web service REST e gestire la persistenza dei dati. Il primo passo è stato quello di definire le entità che devono essere persistenti e quindi salvate nel database. La loro implementazione può essere divisa in tre parti principali:  Definire le entità e gli attributi;  Definire le query che saranno necessarie per interrogare il database;

50  Definire le relazioni tra le entità. Per risolvere questo problema ho utilizzato le Java Persistence API del framework Spring per poter facilitare il lavoro. 6.3.1 Java Persistence API (JPA) Le Java Persistence API, talvolta riferite come JPA, sono un framework per il linguaggio di programmazione Java che si occupa della gestione della persistenza dei dati di un DBMS relazionale e fornisce un modello di persistenza per POJO. Il processo di trasformazione da oggetto istanza di una classe a dato di un database prende il nome di ORM (Object Relational Mapping). Il vantaggio offerto da JPA consiste nell’abilitare un mapping oggetti-relazioni attraverso annotazioni o XML standard, definendo come avviene il mapping tra classi Java e tabelle di un database relazionale. Il vantaggio dell’ORM sta essenzialmente nel riuso. Lo scopo è ridurre tempi e conseguentemente costi di sviluppo demandando a librerie già realizzate (testate ed ottimizzate) la gestione dei driver JDBC, del codice SQL e in generale del mapping tra oggetti e database. [JPA oracle] 6.3.2 Mapping delle entità Avendo appreso il funzionamento di JPA ho cominciato la fase di mapping delle entità. Gli aspetti sui quali occorre prestare attenzione sono gli oggetti, le relazioni, le molteplicità delle relazioni e l’opzionalità delle relazioni. Qui in seguito un esempio di mapping di un oggetto POJO Dipartimento in entità e dei suoi attributi nel progetto StudyMate. @Entity public class Dipartimento extends BasicEntity { private static final long serialVersionUID=8681710690984301605L; @Id @GeneratedValue private long id; @Column(name="NOME") private String nome;

51 @Entity: definisce che l’oggetto POJO è un’entità del modello di dominio definito, e quindi come visto precedentemente deve essere persistente e quindi memorizzata nel database. Dopo aver definito l’entità è stato necessario fornire alcune indicazioni fra le quali quelle relative alle variabili di istanza che sono usate direttamente per la persistenza e il nome che l’attributo deve avere nel database. Ho utilizzato un field-based access con le seguenti annotazioni: @Id: ogni entità del modello dev’essere univocamente identificabile. Per rendere un’entità univocamente identificabile occorre definire una chiave primaria con l’annotazione @Id. Questo modo di identificare univocamente un campo va bene soltanto nel caso in cui l’identificativo univoco dell’entità è costituito da un solo attributo. Nel caso in cui la chiave primaria fosse stata complessa avrei dovuto usare l’annotazione @IdClass. @GeneratedValue: specifica all’entità che il campo a cui è associato avrà un valore autogenerato nel database. @Column: definisce che il campo a cui è associato delle specifiche per la colonna. Nel caso dell’esempio è stato usato per specificare il nome della colonna nel database. Dopo aver definito tutte le entità, averle mappate e definito i loro attributi, il secondo passo è stato quello di definire le entità del modello che hanno bisogno di persistenza, associandole al database. Per fare ciò è stato definito in /resources/META-INF il file persistence.xml. La fase successiva di cui mi sono occupato è stata la generazione delle query SQL di cui ogni entità ha bisogno per effettuare interrogazioni al database. 6.3.3 Java Persistence Query Language (JPQL) JPQL è un linguaggio di interrogazione definito nel framework JPA per definire interrogazioni per le entità. JPQL si basa su SQL e l’unica differenza tra i due linguaggi sono che JPQL restituisce entità mentre SQL restituisce record. Le Query API supportano due tipi di query: named e dynamic. Le named query sono tipicamente utilizzate per eseguire le operazioni più comuni, vengono infatti memorizzate e riutilizzate quando è necessario. Le dynamic query invece create secondo le necessita applicative del momento. [JPQL]

52 6.3.4 Uso di JPQL e JpaRepository Qui in seguito un esempio di dichiarazione di Query in JPQL in StudyMate: @Entity @Inheritance(strategy=InheritanceType.SINGLE_TABLE) @NamedQueries({ @NamedQuery(name ="Commento.getCommentoByCorsoApproved", query ="select c from Commento c where c.corso = ?1 and c.approved = true"), @NamedQuery(name ="Commento.getCommentoByStudenteApproved", query ="select c from Commento c where c.id_studente = ?1 and c.corso = ?2 and c.approved = true"), @NamedQuery(name ="Commento.getCommentoByCorsoAll", query ="select c from Commento c where c.corso = ?1"), @NamedQuery(name ="Commento.getCommentoByStudenteAll", query ="select c from Commento c where c.id_studente = ?1 and c.corso = ?2")}) Public class Commento extends CommentBaseEntity { In questo frammento di codice si può vedere come ho dichiarato le query per l’entità Commento. Per fare ciò ho avuto bisogno di due annotazioni: @NamedQueries e @NamedQuery. Associare le query al nome del metodo è stato possibile attraverso l’interfaccia JPARepository. E' un’interfaccia che implementa i principali metodi CRUD per l’interazione con il database come findOne, findAll, save, delete. Nel mio caso per associare le query che ho definito nelle varie entità le ho associate a all’interfaccia JPARepository in questo modo: @Repository Public interface CommentiRepository extends JpaRepository{ ListgetCommentoByCorsoAll(Long corso); Commento getCommentoByStudenteAll(Long studente, Long corso); ListgetCommentoByCorsoApproved(Long corso); Commento getCommentoByStudenteApproved(Long studente, Long corso); } Come si può vedere grazie a JPA, gli oggetti che ritornano dalle richieste al server sono oggetti definiti nel modello dati come entità anziché record del database. Ciò ha portato durante il lavoro di un risparmio di tempo, ed un riutilizzo dei metodi per le chiamate al database.

53 6.3.5 Relazioni tra entità Il terzo ed ultimo punto che mi ha portato al mapping di tutte le entità del modello è stato quello di creare le relazioni tra le entità. Una relazione può essere unidirezionale o bidirezionale a seconda di dove sono piazzati i riferimenti. Le relazioni possono essere: uno ad uno, uno a molti, molti a uno, molti a molti. In seguito illustro un esempio di dichiarazione di relazioni tra l’entità Studente con Dipartimento e Corso: @ManyToOne @JoinColumn(name="ID_DIPARTIMENTO") private Dipartimento dipartimento; @ManyToMany(fetch=FetchType.EAGER) @JoinTable(name="Frequenze",joinColumns=@JoinColumn(name="STUDENTE_ID"), inverseJoinColumns=@JoinColumn(name="CORSO_ID")) Private Collection corsi; Ho utilizzato l’annotazione @ManyToOne per definire che più entità correnti Studente possono essere associate ad una sola entità Dipartimento. @JoinColumn serve a definire che l’identificatore di Dipartimento è una chiave esterna dell’entità corrente. L’annotazione @ManyToMany l’ho utilizzata per definire che più istanze dell’entità corrente hanno più istanze dell’entità corso. L’annotazione fetch = FetchType.EAGER indica che quando viene fatta una richiesta al database un’istanza di studente verranno caricati direttamente anche tutti i corsi di uno studente. @Transient invece, serve a definire un attributo nell’entità ma esso non sarà salvato nel database. L’ho utilizzato per risolvere un problema a cui mi sono trovato di fronte nella definizione dell’entità Studente. L’entità Studente fa riferimento all’entità Corso in quanto lo studente dovrà contenere una lista di corsi presenti nel libretto, corsi di interesse, corsi superati. Non potendo assegnare un’annotazione @ManyToMany per tre diversi attributi della stessa entità, ho dovuto risolvere il problema assegnando l’annotazione @Transient ai corsi di interesse ed ai corsi superati. Ad ogni richiesta al database per l’invio all’utente delle informazioni, questi attributi vengono aggiornati. 6.3.6 Implementazione dei metodi REST L’ultima fase, quella che ha permesso al client StudyMate di poter usufruire del servizio web è stata l’implementazione dei metodi. Qui sotto riporto tutti i metodi che ho implementato per rendere accessibili tutti i dati al client.

54 Tabella 3 URI path Met- hod Response value Description /corso/{id_corso}/commento/all GET List Restituisce al client la lista dei commenti riferiti ad un corso /commento/{id_corso}/me GET Commento Restituisce al client il commento di un corso dell’utente che effettua la richiesta /commento POST boolean Salva nel database il commento dell’utente passato nel body della Request per un corso e restituisce true se l’operazione è andata a buon fine. /corso/all GET List Restituisce al client tutti i corsi presenti nel database. /corso/{id_corso} GET Corso Restituisce al client il corso riferito all’id passato. /corso/me GET List Restituisce al client la lista dei corsi personali presenti nel libretto. /corso/superati/me GET List Restituisce al client tutti i corsi superati. /corso/dipartimento/{id_dipartimento} GET List Restituisce al client la lista dei corsi di un determinato dipartimento. /corso/corsolaurea/{id_corsoLaurea} GET List Restituisce al client la lista dei corsi di un determinato corso di laurea. /corso/superato/{id_corso} GET Boolean Restituisce al client true se il corso è stato superato, altrimenti false. /corso/seguo POST Boolean Cambia lo stato “seguo/non seguo” di un corso per

55 l’utente che effettua la richiesta. Al client ritorna true se l’operazione è andata a buon fine, altrimenti false. /corso/interesse/me GET List Restituisce al client la lista di corsi di interesse dell’utente (corsi che segue). corsolaurea/all GET List Restituisce al client la lista di tutti i corsi di laurea presenti nel database. /corsolaurea/{id_dipartimento} GET List Restituisce al client la lista di tutti i corsi di laurea di un determinato dipartimento. /dipartimento/all GET List Restituisce al client la lista di tutti i dipartimenti presenti nel database. /dipartimento/{id_dipartimento} GET Dipartimento Restituisce al client il dipartimento dato l’id. /evento/{idcorso} GET List Restituisce al client la lista di tutti gli eventi di un determinato corso. /evento POST Evento Salva nel database un nuovo evento e restituisce l’oggetto evento che è stato salvato al client. /evento/me GET List Restituisce la lista di tutti gli eventi riferiti ai corsi da libretto e ai corsi di interesse. /studente/me GET Studente Restituisce al client le proprie informazioni personali.

56 Per implementare tutti i metodi REST sono partito da un progetto già configurato alla creazione di tali metodi. Per crearli ho dovuto imparare alcune annotazioni del framework di Spring, oltre ad utilizzare l'oggetto JpaRepository per interfacciarmi con il database. Qui in seguito un esempio di metodo annotato come metodo REST che ho implementato: @RequestMapping(method = RequestMethod.GET, value ="/corso/{id_corso}/commento/all") public @ResponseBody ListgetCommentoByCorsoId(HttpServletRequest request, HttpServletResponse response, HttpSession session, @PathVariable("id_corso") Long id_corso) throws IOException { L’annotazione @RequestMapping permette di specificare le informazioni principali del metodo, ossia l’URI path ed il metodo che deve avere la richiesta del client. L’oggetto di ritorno del metodo (in questo caso List) viene annotato con @ResponseBody, che significa che tale oggetto sarà il contenuto del body della risposta che verrà convertita in JSON. Se nell’URI è previsto il passaggio di uno o più parametri basta semplicemente mappare con l’annotazione @PathVariable il parametro specificato nella @RequestMapping ed assegnato ad un oggetto Java. Ogni metodo che ho implementato, come ho già spiegato in precedenza, prevede un controllo degli accessi ai servizi SmartCampus. Viene controllato se l’utente può accedere alle informazioni che richiede tramite il controllo del token dell’utente e l'accesso al profilo riferito all'account del login.

57 7 Moderazione dei commenti La possibilità degli studenti di poter dare dei commenti ai corsi ha portato inevitabilmente a pensare ad un modo per controllare che i contenuti siano adeguati. La moderazione dei commenti ha portato allo sviluppo di un nuovo servizio core che va ad aggiungersi agli altri servizi SmartCampus esistenti. 7.1 Requisiti Per capire quale potesse essere il modo migliore per implementare il servizio, è stata fatta un'analisi che ha portato ai seguenti requisiti:  Deve avere un portale in cui i commenti possono essere moderati manualmente;  Deve gestire commenti riferiti a qualsiasi applicazione SmartCampus;  Deve esserci un filtro preliminare che blocchi i commenti contenenti parole proibite;  Aggiungere in qualsiasi momento nuove parole proibite dal sistema;  Monitorare ogni azione di blocco o di approvazione sia manuale che automatico;  Poter dare i permessi di accedere al moderatore ad altre persone all'interno di SmartCampus. 7.2 Architettura La seguente sezione descrive i componenti di alto livello coinvolti nel sistema e come sono stati implementati. Nello scenario di riferimento è presente il servizio di moderazione, l'applicazione web ed il client Android (Figura 28) e mostra ad alto livello come comunicano tra di loro.

58 Per quanto riguarda il servizio core del moderatore, è stato implementato utilizzando Angular JavaScript in cui è stato possibile gestire sia la parte di view che di controller. La persistenza dei dati viene gestita da un database MongoDB (document oriented database), in cui vengono salvati tutti i dati che riguardano i commenti presenti nel portale ed il loro stato, le keywords proibite ed il log delle azioni. Il controller fa da ponte tra la parte view e model attraverso metodi REST, i quali possono venire chiamati dal servizio del moderatore per semplificare l'accesso dall'esterno. Per il lato server dell'applicazione chiamante (ad esempio StudyMate) si può appoggiare a delle API in cui sono presenti metodi per facilitare l'interazione con il moderatore. Da queste API è possibile fare l'update dello stato dei commenti nel database sql, resettare le keywords e salvarle in un file, inviare al moderatore un commento eseguendo il controllo del commento con le parole proibite ed inviarlo settando la possibilità di mediazione in NOT_REQUEST, che fa in modo che il commento venga approvato o bloccato localmente senza poter cambiare il suo stato nel portale. L'altra tipologia di invio di un commento al portale è settare il suo stato a WAITING, in modo da poterlo mediare manualmente nel portale. 7.3 Gestione dei commenti e sincronizzazione delle keywords Come accennato in precedenza i commenti possono essere filtrati in due modi differenti. Queste due tipologie di gestione della validazione dei commenti sono state utilizzate insieme per avere un doppio filtro. Prima filtrando localmente il commento con un pattern matching con le keywords proibite, e poi se il commento passa il primo filtro, si fa una validazione remota in cui viene mandato Figura 28

59 al portale del moderatore per filtrarlo manualmente. Queste due funzioni sono state implementate in Mediation Api (vedi Figura 28). Nel portale le keywords inserite sono salvate nel database mongoDB e per poter eseguire una validazione locale di un commento è necessario aggiornare le keywords periodicamente. In Mediation Api è stata implementata la funzione di aggiornamento delle keywords proibite tra il portale e l'applicazione web del client Android. La funzione si occupa di richiamare il servizio del moderatore che a sua volta richiama i metodi REST del controller che ritornano la lista di keywords. Esse vengono salvate nel file system in un file di testo dell'applicazione web del client Android. Per quanto riguarda la sincronizzazione dei commenti, quelli che superano il filtro locale e vengono mandati nel moderatore sono settati visibili nel client, ma successivamente potrebbero essere bloccati manualmente nel portale. Per questo è stato implementato un sistema di aggiornamento dei commenti. Il metodo di update viene richiamato ogni 15 minuti attraverso l'annotazione @Scheduled, in cui viene richiamato il metodo di update di mediation Api che fa ritornare un'HashMap, dove String fa riferimento all'id del commento e boolean se è approvato o meno.

60 8 Conclusione L'obiettivo iniziale del lavoro svolto per questa tesi era quello di creare un'applicazione Android, e dare il mio contributo alla sua realizzazione in ogni fase della progettazione ed implementazione. Si è partiti da un'idea iniziale volta a realizzare uno strumento che supporti gli studenti universitari nella loro vita accademica nel contesto di SmartCampus (Capitolo 2). Successivamente si è passati al lavoro di interaction design che è partito inizialmente dal corso di Interazione uomo-macchina e si è concluso durante il tirocinio portando ad avere un prototipo dell'applicazione con dei mockups di media fedeltà. Dopodiché si è passati al lavoro di implementazione che ha portato ad avere un prototipo funzionante in Android dell'applicazione, ed il relativo lato server che si occupa della persistenza dei dati e di renderli disponibili al client. Il tutto all'interno del contesto SmartCampus. Per quanto riguarda i l’aspetto dei dati provenienti dall’università, a causa dei lunghi tempi di ottenimento per questioni burocratiche e di privacy, ho lavorato con dati inseriti manualmente nel database. Infine, è stata progettata e implementata una prima versione di un sistema di moderazione dei commenti che va ad integrarsi nei servizi core di SmartCampus. Durante questo lavoro ho avuto modo di sviluppare, attraverso le tecnologie che ho incontrato, nuove capacità tecniche ed analitiche. Inoltre, ho acquisito l’esperienza di progettare un servizio per il campus in cui ho il ruolo sia di sviluppatore che di un tipico utente finale. Questo mi ha aiutato molto a capire in modo migliore i requisiti necessari per creare un'applicazione che soddisfi i bisogni degli studenti. Tuttavia, questo è stato utile ma non sufficiente per comprendere la totalità dei bisogni di tutti gli studenti. Perciò, è stato necessario nella fase di interaction design comprendere un campione di un maggior numero di studenti valutando i loro (nostri) bisogni e definendo i requisiti attraverso interviste, questionari e valutazioni di usabilità. Le maggiori difficoltà che ho incontrato sono state principalmente durante la fase di implementazione. Nella parte Android per quanto riguarda la comunicazione con il server, la gestione degli AsyncTask e degli adapter personalizzati. Nella parte server, creare un modello dati efficiente e che possa essere compatibile con i dati universitari non ancora disponibili, la gestione delle relazioni tra entità con JPA ed in generale integrare sia il lato client che il lato server con la piattaforma SmartCampus. Il problema più importante con cui ho avuto a che fare è stato quello di gestire i commenti degli studenti. Per questo è stato necessario trovare il modo per mantenere contenuti adatti e costruttivi per la comunità. Gli aspetti positivi di questa esperienza sono stati molti, a cominciare dalla fiducia data dal team a noi studenti tirocinanti e la presenza di un tutor aziendale sempre disponibile ad indirizzare il lavoro

61 nella giusta strada. Inoltre, un altro aspetto positivo è stato senza dubbio quello di avere lavorato in un progetto dove io stesso sono un tipico utente finale e allo stesso tempo sviluppatore, il che è stato indispensabile per realizzare un'applicazione migliore, che soddisfi i bisogni più importanti per noi studenti.

62

63 Ringraziamenti Per l'esperienza di questo lavoro di tesi vorrei porgere un ringraziamento ed esprimere la mia gratitudine alla professoressa Antonella De Angeli per avermi dato l'opportunità di far parte del team SmartCampus che mi ha permesso di affrontare un'esperienza importante sotto tutti i punti di vista, dando valore alle idee di noi studenti. Silvia Bordin, per i buoni consigli che mi ha dato durante il tirocinio e la stesura della tesi. Federico Lucca per avermi seguito con pazienza durante la mia esperienza di tirocinio, dandomi la possibilità di aumentare il mio bagaglio di conoscenze. Infine, ringrazio mio zio Stefano perché principalmente è grazie a lui che ho cominciato questo percorso spingendomi in ogni modo e dandomi fiducia fin dall'inizio. Devo ringraziare anche la mia fidanzata Cristina per avermi supportato in ogni momento ed avermi dato la buona volontà di andare avanti con gli studi anche nei momenti più difficili, la mia famiglia e gli amici che ho incontrato durante questo percorso.

64

65 Bibliografia [Participatory design] http://participateindesign.org/ [Analisi pact] http://disi.unitn.it/~deangeli [Nielsen Heuristics] http://en.wikipedia.org/wiki/Heuristic_evaluation [cognitive walkthrough] http://www.usabilityfirst.com/usability-methods/cognitive-walkthroughs/ [severity scale] https://www.measuringusability.com/blog/rating-severity.php [Android] Android 3 guida per lo sviluppatore, Massimo Carli, Apogeo 2011; http://developer.android.com/ [Android layers] http://developer.android.com/ [JPQL] http://www.objectdb.com

66

67

68