Schema Architetturale

Figura 35

L’architettura progettata per l’applicazione prevede l’utilizzo di tre moduli: 1. Client: Smartphone con sistema Android

2. Totem: un Server JBoss e un Server NodeJs 3. DBMS: database MySql

Lo smartphone comunica con il Totem tramite il protocollo

implementabile (client Http offerto dall’SDK Android) e i dati da trasferire non hanno un’elevata complessità e dimensione

ogettazione

Una volta terminata la fase di analisi e definiti i servizi da inserire nell’esperienza utente in funzione dei requisiti raccolti, il passo successivo ha visto la progettazione dell’architettura necessaria all’esecuzione dei casi d’uso descritti nel

a fase di progettazione è stata suddivisa in due macro attività: definizione dell’architettura di alto livello da implementare

definizione delle caratteristiche dei singoli moduli che compongono

tetturale

35 - Schema architetturale NFCUserExperience

L’architettura progettata per l’applicazione prevede l’utilizzo di tre moduli: : Smartphone con sistema Android;

Server JBoss e un Server NodeJs; database MySql;

Lo smartphone comunica con il Totem tramite il protocollo Http in quanto è facilmente implementabile (client Http offerto dall’SDK Android) e i dati da trasferire non hanno

elevata complessità e dimensione. Il totem invece è costituito da due server:

84 Una volta terminata la fase di analisi e definiti i servizi da inserire nell’esperienza utente in funzione dei requisiti raccolti, il passo successivo ha visto la progettazione dell’architettura necessaria all’esecuzione dei casi d’uso descritti nel paragrafo suddivisa in due macro attività:

definizione delle caratteristiche dei singoli moduli che compongono

L’architettura progettata per l’applicazione prevede l’utilizzo di tre moduli:

in quanto è facilmente implementabile (client Http offerto dall’SDK Android) e i dati da trasferire non hanno ito da due server: JBoss

5. Analisi e Progettazione 85 permette di implementare la logica applicativa dei servizi inseriti all’interno dell’esperienza e di gestire le richieste provenienti sia dallo smartphone che dal browser (responsabile dell’interfaccia utente lato totem), mentre il server NodeJs tramite l’utilizzo di Web Socket (vedi Appendice A) permette di sincronizzare lo stato del server con l’interfaccia utente lato client mostrato sullo smartphone. In questo modo, per ogni interazione dell’utente con il device che avviene tramite touch o tramite tag NFC, otteniamo un allineamento costante tra l’azione che dovrà eseguire l’utente sullo smartphone e la guida sul totem che illustrerà le istruzioni necessarie per continuare l’esperienza. Le istruzioni saranno fornite sulle pagine web del browser e saranno sia scritte che illustrate con delle gif animate per aiutare la comprensione. Mentre il servizio di Ticketing e la simulazione dell’installazione del TIM Wallet possono essere gestiti direttamente dall’applicazione client-server senza richiedere nessun accesso al DBMS, il servizio di Pagamento e i tre strumenti di feedback individuati necessitano l’utilizzo di dati persistenti e condivisi e richiedono, quindi, di poter eseguire operazioni di lettura e scrittura sul database locale. La comunicazione tra il modulo Totem e il modulo Database avviene attraverso l’utilizzo del connettore JDBC. La progettazione del database, come vedremo più avanti nel capitolo, permette una gestione personalizzata delle domande e delle risposte del questionario, la memorizzazione dei prodotti del volantino nel servizio di Pagamento, delle idee fornite nella partecipazione al Contest e infine dei Feedback diretti. In tabella 27 e in figura 36 la sintesi dei ruoli dei moduli nei servizi e della logica del sistema.

Payment Ticketing TIM Wallet Feedback Survey Contest Innovazione Smartphone Genera richieste Genera richieste Genera richieste Genera richieste Genera richieste Genera richieste Totem View e logica applicativa View e logica applicativa

View View View View

Database Locale Memorizza i prodotti del volantino - - Memorizza i feedback diretti Memorizza domande e risposte Memorizza le idee degli utenti

5. Analisi e Progettazione Figura 5.3.2 Architettura smartphone Dispositivo Utilizzatore Caratteristiche tecniche Protocollo di Comunicazione Servizi

Figura 36 - Struttura logica del sistema complessivo

Architettura smartphone

Smartphone Utente Android 4.3

• Smartphone->Totem: Http Request

Payment, Ticketing, TIM Wallet, Feedback, Questionario Contest

Tabella 27 – Dettagli smartphone

86

5. Analisi e Progettazione 87 View _Activity Android Controller _Java Network _{HTTP, NFC,} Java Android

Tabella 28 – Architettura smartphone

Uno dei requisiti principali per lo sviluppo dell’applicazione mobile è la sua modularità; è stata resa, pertanto, altamente modulare per minimizzare i costi di inserimento di nuove funzionalità, generando moduli coesi e debolmente accoppiati. Ogni funzionalità offerta all’utente viene implementata e gestita in moduli indipendenti che sono connessi al resto dell’App tramite una Facade che espone i servizi di utilità ai moduli delle funzionalità. Il resto dell’App è un macro modulo (Figura 37) che offre funzionalità di supporto come connettività verso il totem, generazione delle statistiche sul suo utilizzo, gestione dello stato dell’esperienza e reset del sistema.

5. Analisi e Progettazione 88 5.3.3 Architettura Totem

Dispositivo Totem

Utilizzatore Utente

Caratteristiche tecniche JBoss: JSP,HTML, Servlet, Java;

NodeJS: Javascript, Socket.io

Protocollo di Comunicazione

• Totem->Smartphone: Http Response

• Totem->Database: Connector JDBC

Servizi Payment, Ticketing, TIM Wallet, Feedback, Questionario,

Contest

Tabella 29 – Dettagli Totem

L’architettura dei servizi implementati e gestiti dal modulo Totem è la seguente:

View JSP, HTML,

CSS, server NodeJS

Controller Servlet

Logica Applicativa _{Java, JNDI}

Tabella 30 - Architettura Totem

Il totem è costituito da due server:

• Jboss

• NodeJs

Il primo utilizza il pattern architetturale MVC e implementa la logica applicativa per la gestione dei sevizi inseriti nell’esperienza utente. Il Controller gestisce le richieste http provenienti dallo smartphone e dal browser, è costituito da tre diversi servlet che supportano il pagamento (servlet Payment), la bigliettazione (servlet Ticketing) e le funzionalità generali (servlet Totem1). Una volta che una richiesta, proveniente dallo

5. Analisi e Progettazione

smartphone, viene catturata dal servlet opportuno, questo la elabora ed

operazioni definite utilizzando gli oggetti e le classi Java definite nei diversi package che compongono il Model

dell’applicazione, il componente Mod

connettore jdbc accede con operazioni di scrittura e lettura al database locale

package Networking che contiene la classe Socket necessaria per la connessione con il secondo server NodeJs. Questa classe sfrutta la libreria

utilizzare la tecnologia dei Web S

particolare la libreria è composta da una parte client che viene inclusa direttamente sulle pagine web e da una parte server che gira all’interno di un semplice scr

Le pagine web, JSP o HTML, rimangono costantemen

sono in grado di “ascoltare” le richieste provenienti dal server NodeJS funzione Socket.broadcast.emit(

javascript la richiesta pervenuta e lancerà a sua volta catturata dal Servlet opportuno

La figura 38 mostra lo schema delle interazioni tra i d descrivendo dettagliatamente

Figura 38 - Schema del Totem e delle relazioni tra i componenti

viene catturata dal servlet opportuno, questo la elabora ed

operazioni definite utilizzando gli oggetti e le classi Java definite nei diversi package Model. Oltre che i metodi necessari per accedere ai dati dell’applicazione, il componente Model contiene il package Database, il quale

connettore jdbc accede con operazioni di scrittura e lettura al database locale

package Networking che contiene la classe Socket necessaria per la connessione con il secondo server NodeJs. Questa classe sfrutta la libreria Socket.io che

dei Web Socket dal browser verso l’applicazione

particolare la libreria è composta da una parte client che viene inclusa direttamente sulle pagine web e da una parte server che gira all’interno di un semplice scr

Le pagine web, JSP o HTML, rimangono costantemente in ascolto su una porta ( sono in grado di “ascoltare” le richieste provenienti dal server NodeJS inviate

Socket.broadcast.emit(…). La pagina Web gestirà con appositi controlli di la richiesta pervenuta e lancerà a sua volta una richiesta

ervlet opportuno al quale è delegato l’aggiornamento della

mostra lo schema delle interazioni tra i diversi moduli dell’applicazione descrivendo dettagliatamente il modulo Totem.

Schema del Totem e delle relazioni tra i componenti

89 viene catturata dal servlet opportuno, questo la elabora ed esegue le operazioni definite utilizzando gli oggetti e le classi Java definite nei diversi package Oltre che i metodi necessari per accedere ai dati el contiene il package Database, il quale tramite il connettore jdbc accede con operazioni di scrittura e lettura al database locale, ed il package Networking che contiene la classe Socket necessaria per la connessione con il che permette di applicazione web. In particolare la libreria è composta da una parte client che viene inclusa direttamente sulle pagine web e da una parte server che gira all’interno di un semplice script ServerJS.js. te in ascolto su una porta (3000) e inviate tramite la con appositi controlli di una richiesta http che verrà la View dell’App. dell’applicazione

5. Analisi e Progettazione 90 5.3.4 Architettura Database

Device Server Remoto

Utilizzatore Totem

Caratteristiche tecniche MySql

Connettore di Comunicazione

• Totem->Server Remoto: JDBC

Servizi Payment, Feedback, Questionario, Contest

Tabella 31 - Dettagli Database locale

Il terzo modulo ha il compito di memorizzare i dati necessari all’implementazione dello strato di logica applicativa del servizio di Payment , e degli oggetti relativi al Feedback, al Questionario, al Contest ed alla elaborazione delle Statistiche. Avrà anche il compito di gestire la persistenza dei dati e delle risposte degli utenti gestendo un Db relazionale, MySQL. Il server sarà, quindi, formato anche da un package Database che comunicherà con il database tramite il connettore JDBC, consentendo l’accesso alla base di dati.

5. Analisi e Progettazione 91

Figura 40 - Diagramma ER Database locale

In figura 40 è visualizzato il Diagramma ER del Database Totem. Esso è composto da 6 tabelle: • Prodotto • Idea • Utente • Rispostautente • Feedback • Questionario

Le prime due sono tabelle indipendenti dalle altre. In particolare la tabella Prodotto viene utilizzata nel servizio di Payment e permette la memorizzazione degli articoli inseriti sul volantino. Ogni volta che l’utente selezionerà un articolo dallo smartphone partirà una richiesta volta ad accedere in lettura e ad estrarre dal database tutte le caratteristiche dell’oggetto prodotto. Per il servizio di acquisto, quindi, nel database dovranno essere salavate solo le informazioni riguardanti i prodotti, non saranno gestiti gli ordini e le simulazioni di pagamento che saranno elaborate localmente nel totem. L’altra tabella, Idea, supporta la ricezione delle proposte degli utenti durante il contest di innovazione. In particolare, oltre alla memorizzazione della descrizione e del titolo

5. Analisi e Progettazione 92 dell’idea stessa, vengono salvate le informazioni dell’utente che ha partecipato, quali nome ed email che saranno necessarie per contattare la persona che risulterà vincente al contest. Le restanti quattro tabelle sono connesse tra di loro attraverso chiavi esterne e raccolgono dati sull’esperienza di ogni singolo utente. Le persone che effettuano la simulazione rimangono anonime, nessun dato anagrafico viene raccolto, ma vengono identificate con un id che codifica il nome del totem in cui è avvenuta l’esperienza insieme alla data ed all’ora. L’idUtente, che viene creato ogni qualvolta lo smartphone di prova viene preso dalla posizione di stand-by, crea il collegamento con le risposte dell’utente al questionario e con i feedback relativi alle esperienze dei servizi simulati. Nella tabella utente, inoltre, vengono salvate le informazioni relative alla tipologia utente (base o avanzato), al numero di simulazioni di servizi eseguiti ed infine alla durata complessiva dell’esperienza. La raccolta di questi dati può fornire importanti indicazioni su quanto in media un utente rimane davanti al totem ad interagire con l’NFC, oppure quanti servizi simulati è interessato ad eseguire. Dalla tabella feedback, invece, andiamo a riscontrare quale tra Pagamento e Bigliettazione è più attrattivo alla clientela, da questa infatti non solo ricaviamo il numero di servizi di Payment e Ticketing effettuati, ma anche la valutazione in termini di semplicità e interesse. Le entries della tabella risposteutente, invece, permetteranno di comporre le risposte al questionario fornite dagli utenti. La chiave esterna di questa tabella consentirà di associare le risposte date alle domande che costituiscono la tabella questionario, formata dalla domanda vera e propria e da un massimo di quattro possibili risposte. Ogni qualvolta un utente decida di partecipare al questionario, la riposta ad una domanda sullo smartphone fa partire una richiesta che va ad estrarre dal database la domanda successiva. Questa modalità di implementazione permette una facile personalizzazione del questionario e in particolare delle domande e delle possibili risposte. Infatti per modificare, aggiungere, cancellare qualsiasi domanda basterà andare ad interagire direttamente sulle entries della tabella e automaticamente l’utente successivo potrà rispondere al questionario aggiornato.