Facoltà di Ingegneria. Corso di Studi in Ingegneria Informatica

Transcript

1 Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Tesi di laurea Progettazione e sviluppo di un applicazione di Mobile Payment su dispositivo Android tramite tecnologia NFC Anno Accademico 2010/2011 Relatore: Ch.mo prof. Marcello Cinque Correlatore: Ch.mo ing. Marco Oreste Migliori Candidato: Pisicchio Antonia matr. 885/489 1

2 Ai miei genitori ed al mio ragazzo 2

3 Indice Indice... 3 Introduzione Tecniche di Mobile Payment Mobile Payment Tecnologie coinvolte JavaCard Mobile Proximity Payment Elementi coinvolti APP e Applet Applet su SIM APP1 Android APP2 Android Scenari d uso e analisi dei requisiti Analisi e progettazione di alto livello Casi d uso associate al gesture delle carte Activity Diagram associato al processo di pagamento Sequence Diagram Progettazione di dettaglio e sviluppo Requisiti spesa da casa Requisiti spesa al supermercato Casi d uso (UCx) Use Case Diagram Activity Diagram associati all applicazione supermercato Class Diagram

4 7. Sequence Diagram associati all applicazione supermercato Sviluppo dell applicazione ScreanShot Testing Conclusioni Bibliografia

5 Introduzione Negli ultimi anni cresce sempre più l interesse verso l utilizzo di nuove tecnologie abilitanti che consentano di effettuare pagamenti in mobilità in tutta sicurezza. La tecnologia abilitante più adatta allo scopo è il Near Field Comunication (NFC) sviluppata congiuntamente da Philips e Sony e che trova nell'nfc Forum un'associazione formata da molte aziende di rilevanza internazionale, e non, che ne promuovono l'utilizzo, lo sviluppo e la standardizzazione. Obiettivo principale dell'nfc è l'instaurazione semplice e intuitiva della comunicazione tra due dispositivi, questi possono essere dispositivi basati su J2ME, TAG contactless o smart card; la semplicità di utilizzo risiede nella comunicazione che avviene semplicemente avvicinando tra loro i dispositivi. NFC è inoltre compatibile con la diffusa architettura delle smart card contactless, basate su ISO A/B, Philips MIFARE e Sony FeliCa. Altro fattore fondamentale per consentire lo sviluppo e la diffusione dei pagamenti è la sicurezza perché bisogna garantire che le informazioni memorizzate su una smart card non vengano violate da accessi non autorizzati. A supporto della sicurezza ci viene in aiuto la tecnologia JavaCard. JavaCard offre un elevato grado di sicurezza grazie ad una serie di aspetti che analizzaremo nel dettaglio durante la trattazione. Nel primo capitolo analizzeremo le tecnologie necessarie allo sviluppo della nostra applicazione su dispositivo mobile android, in particolare verranno analizzate le modalità di pagamento in mobilità, la tecnologia abilitante NFC, la tecnologia JavaCard ed infine una breve trattazione sul sistema operativo su cui andremo ad implementare la nostra APP, ovvero Android. Nel secondo capitolo andremo a specificare i requisiti software e hardware per la nostra applicazione, l architettura complessiva di un processo di Mobile Payment e i casi d uso di nostro interesse. Nel terzo capitolo entreremo nella fase di progettazione vera e propria, andando a definire i diagrammi UML utili alla comprensione degli scenari di utilizzo e del successivo sviluppo. 5

6 Nel quarto ed ultimo capitolo realizzeremo un caso d uso di pagamento in mobilità, ovvero una applicazione che mi consenta di effettuare la spesa al supermercato sfruttando la tecnologia NFC per creare un carrello virtuale e per effettuare un pagamento proximity. 6

7 1. Tecniche di Mobile Payment 1. Mobile Payment Nel corso degli anni i micropagamenti tramite smartphone e cellulari sono notevolmente aumentati ma la cosa più importante è che le stime danno come in crescendo un fenomeno che a breve ci toccherà da vicino. Gli smartphone hanno portato sicuramente ad una rivoluzione di cui dobbiamo ancora rendercene conto. Il loro utilizzo non è solo quello di permetterci di parlare con persone che stanno dall altra parte del mondo o di utilizzare le innumerevoli funzionalità come ad esempio il GPS, scattare foto, andare su internet o ascoltare musica, ma il poter effettuare micropagamenti ed acquisti direttamente dal nostro terminale. Il metodo utilizzabile per effettuare microacquisti può essere semplificato in tre tipologie come è possibile visualizzare in figura 1: quella che ci permette di effettuarli tramite la rete GSM, GPRS cio`e il Mobile Remote Payment (servizi che consentono di effettuare un pagamento a distanza), oppure il metodo Mobile Proximity Payment, ciè quando chi paga si trova a pochi centimetri da chi deve ricevere il pagamento (il dispositivo che accetta il pagamento si trova in prossimità ad esempio il pagamento del biglietto su un mezzo pubblico) o tramite tecnologia Contactless cioè tramite delle carte di credito contactless. Figura 1 Tipologie di applicazione 7

8 1.1. Mobile Remote Payment Nel Mobile Remote Payment si vogliono inserire quei servizi che consentono di effettuare un pagamento a distanza tramite rete cellulare, quali ad esempio il pagamento dei parcheggi (come indica la figura 2) o la ricarica di una smart card per il video on demand sul digitale terrestre Figura 2 Pagamento parcheggio con Mobile remote payments Il consumatore invia una richiesta di pagamento tramite un messaggio SMS contenente un breve codice che permetterà di effettuare il servizio richiesto. Il commerciante in questione è consapevole del successo di pagamento e può quindi rilasciare la merce. Di seguito viene descritto il tipico processo utente finale di pagamento: Il cliente inizializza il pagamento comunicando con un MPSP (Mobile payments service provider) Il cliente invia un SMS o un comando a un MPSP dove include l ammontare della spesa e il destinatario L MPSP riceve l informazione e invia un SMS al cliente, che per confermare l operazione dovrà inserire il suo codice PIN Il cliente riceve l SMS e inserisce il PIN Quando l MPSP riceve il PIN del cliente, il denaro viene trasferito alla terza parte in causa 8

9 Alla fine della transazione, viene inviato al cliente e al venditore l informazione dell avvenuto pagamento 1.2. Mobile Proximity Payment Nel Mobile Proximity Payment il pagamento viene effettuato attraverso il telefono cellulare in prossimità, come mostrato in figura 3, ossia vi è una vicinanza fisica tra acquirente e prodotto/servizio acquistato. Le tecnologie che abilitano questi servizi sono le tecnologie a corto raggio come RFID, Bluetooth o NFC (vedi paragrafo 2 ). I servizi abilitati consentono, ad esempio, di effettuare spese presso un punto vendita della grande distribuzione o il pagamento del biglietto su un mezzo di trasporto. Figura 3 Esempi di mobile proximity payment Il Mobile Proximity Payment, stà iniziando a compiere solo ora i primi passi anche in Italia. Di seguito vengono riportati alcune considerazioni a riguardo di tale tecnologia: La disponibilità dei telefoni cellulari NFC (ricordiamo che ancor oggi sono disponibili solo pochissimi terminali) L attivazione di un ampia rete di terminali presso gli esercenti Il cambiamento delle abitudini dei consumatori che dipendono, ad esempio, dalla 9

10 predisposizione all utilizzo della moneta elettronica rispetto al denaro contante e dalla percezione del telefonino come strumento di pagamento Una configurazione dell offerta che preveda un modello di business sostenibile per tutti gli attori coinvolti e accresca nel contempo la fiducia dei consumatori Un telefono NFC è composto da 3 elementi fondamentali (vedi figura 4) : 1 - Un antenna per la comunicazione con il mondo esterno. 2 - Un controller che riceve i dati provenienti dall antenna. 3 - Un Secure Element cioè un chip che custodisce i dati sensibili dell utente Il Secure Element può essere: Integrato nel telefono Integrato nella SIM card Integrato in una card SD Figura 4 Architettura di un cellulare NFC Il proximity payment verrà descritto più nel dettaglio nel capitolo successivo. Nel paragrafo seguente verrano descritte le modalità di funzionamento e comunicazione messe a disposizione dalla tecnologia NFC. 10

11 2. Tecnologie coinvolte Nel seguente paragrafo verranno analizzate le tecnologie coinvolte nella nostra applicazione. Analizzeremo in particolare la tecnologie abilitante NFC, la tecnologie utilizzata per la programmazione delle SmartCard (JavaCard) e il sistema operativo che utilizzeremo per la nostra applicazione mobile (Android) NFC L'NFC rappresenta una tecnologia per la connettività a corto raggio derivante dalla combinazione delle carte elettroniche senza contatto con altre tecnologie RFID. La promozione della standardizzazione e dell'implementazione dell'nfc avviene ad opera di un associazione di gruppi industriali, l'nfc Forum, di cui fanno ad oggi parte Sony, Philips, Samsung, Nokia, Visa, Mastercard e molti altri. La caratteristica distintiva di questa tecnologia è rappresentata dalle modalità con cui avviene la comunicazione tra dispositivi NFC compatibili. Al contrario di quanto avviene con i sistemi RFID, nei quali i TAG si limitano semplicemente a rispondere alle richieste del Reader, le entità coinvolte in una comunicazione NFC possono assumere anche pari dignità con caratteristiche operative simili alle carte senza contatto del tipo Proximity cards ISO 14443; adatte quindi a scambio dati sicuro ed a pagamenti elettronici. Possiamo dire che l'innovazione di questa tecnologia risieda proprio nell'accoppiamento di Reader e TAG nello stesso dispositivo che permette anche un tipo di comunicazione Peer-To-Peer. Infatti un dispositivo NFC compatibile può funzionare secondo diverse modalità operative: Modalità Reader/Writer nella quale un dispositivo NFC si comporta esattamente come un Reader RFID con capacità quindi di leggere e scrivere in formazioni nei TAG NFC compatibili Modalità Card Emulation nella quale invece un dispositivo NFC emula il comportamento di una Smart Card Contactless di tipo Proximity Card secondo 11

12 l'iso/iec In questa modalità di funzionamento un Reader non è in grado di distinguere il dispositivo NFC da una ordinaria Proximity Card Modalità Peer to Peer standardizzata nell'iso/iec che consente lo scambio dati tra due dispositivi NFC in una forma bidirezionale. Questa modalità operativa si differenzia quindi dalle precedenti due in quanto consente a due dispositivi NFC di avere pari dignità nella comunicazione Oltre alle modalità con cui dispositivi NFC possono comunicare tra di loro la tecnologia NFC si presenta caratterizzata da: una banda intorno ai 13,56 Mhz una distanza operativa di, al limite, 10cm velocità di trasmissione dati che può essere di 106Kbps, 212Kbps oppure 424Kbps In generale tra le possibili servizi ipotizzabili individuiamo: Acquisto titoli di viaggio: un estensione dell'esistente infrastruttura contactless Pagamento: il dispositivo agisce come carta di debito/credito Accoppiamento Bluetooth: automatizzare il processo di accoppiamento tramite il tocco dei dispositivi Smart Poster: il dispositivo viene utilizzato per ottenere determinate informazioni altre possibili servizi in futuro potranno essere : Bigliettazione elettronica: gestione e acquisto di biglietti aerei, per concerti, eventi o altro. Documenti d'identità elettronici: archiviazione dei documenti in sicurezza. Chiavi elettroniche: similmente alle recenti chiavi utilizzate per le macchine, gli uffici e le stanze d'albergo. 12

13 2.2. Comunicazione tra due dispositivi NFC La comunicazione dal Reader verso il TAG avviene modulando in ampiezza il campo magnetico generato dall antenna del Reader con il segnale digitale in banda base che deve essere trasmesso. Il circuito di ricezione del TAG riconosce il campo modulato e decodifica, da questo, l informazione trasmessa dal Reader. Ora, mentre il Reader ha potenza per modulare e trasmettere il proprio campo il TAG non ne ha. I TAG che usano induzione in campo vicino inviano i loro dati al Reader usando il Load Modulation (Modulazione del carico d antenna). Un segnale può essere codificato semplicemente cambiando opportunamente e nel tempo il carico dell antenna del TAG. Il chip del TAG realizza questo effetto cambiando l impedenza della propria antenna coerentemente con un segnale modulante ricavato dalla lettura dei dati contenuti nella propria memoria. Questo da come risultato una piccola variazione della forza del campo magnetico, nella direzione opposta al campo magnetico generato dal Reader, in modo tale che l informazione sia individualizzabile e comprensibile dal Reader stesso. In sintesi la comunicazione tra il Reader e il Tag è rappresentata dalla sequente figura: Figura 5 Schema di principio del sistema Reader-Tag ad accoppiamento induttivo 13

14 La corrente nell antenna del Reader induce un campo magnetico pulsante che si concatena con l antenna a spire del TAG e lo risveglia. E possibile la comunicazione sia in modo attivo-passivo che attivo-attivo, in NFC si presuppone tipicamente che almeno uno dei due dispositivi sia pilotato da un utente. Generalmente l'nfc viene inserito in un apparato elettronico che provvede sia all'interfaccia uomo macchina, se necessaria, sia al collegamento in rete con i sistemi centrali di transazione finanziaria, sia a fornire l'energia per il funzionamento. Dal lato utente l'nfc è tipicamente incorporato in un telefono cellulare o un PDA, o in qualsiasi apparato elettronico dotato di interfaccia uomo macchina e dal lato del terminale per ticketing o pagamento merci l'nfc sarà incorporato in obliteratrici di biglietti, parchimetri, terminali POS, tornelli d'ingresso, ecc. anche se, per la struttura del sistema, la transazione può essere realizzata anche tra due terminali utente. L'applicazione principale per la quale l'nfc è stato pensato è il pagamento elettronico, o meglio micropagamento. Il vantaggio sta nel poter utilizzare il dispositivo come una sorta di bancomat, in grado di essere controllato e fornire informazioni in tempo reale, anziché con un carta di credito o un bancomat operante su terminale POS esterno, entrambi muti nel senso che la transazione può essere controllata solo a posteriori e con mezzi differenti da quelli utilizzati per effettuare la transazione. Per poter effettuare queste operazioni si rende necessario l'implementazione di un portafoglio dal quale prelevare e versare denaro. Inoltre si deve rendere necessaria la comunicazione del portafoglio con l'esterno per allacciarsi ai circuiti che gestiscono le transizioni. Questo si traduce nella pratica nell'uso della SIM telefonica e del suo credito per effettuare i pagamenti, ma anche tramite le possibilità di connessione del dispositivo e i codici di carte di credito o debito. In pratica l'nfc non svolge la transazione ma crea un ambiente in cui questa possa essere eseguita facilmente e in sicurezza 2.3. Componenti I componenti NFC all interno di un dispositivo mobile sono: CLF (Contactless Front end) 14

15 Terminal Host UICC Host Questi elementi formano una rete Hub and Spoke dove il centro è occupato da CLF. The Hosts (cioè terminal e UICC) più CLF formano la Host Controller Network con l Host Controller facente parte del CLF. CLF inoltre si occupa delle comunicazioni RF. The Hosts e CLF comunicano tra loro grazie all Host Controller mediante HCI (Host Controller Interface). Figura 6 Interazione tra i vari componenti UICC Host e CLF comunicano mediante il protocollo SWP (Single Wire Protocol) Terminal Host usa un interfaccia proprietaria (ossia i diversi sistemi operativi: Symbian, Android) per interagire con CLF oppure può usare anch esso SWP. Dispositivi NFC esterni comunicano con CLF tramite protocolli di comunicazione senza contatto (contactless). 15

16 2.4. Protocolli di comunicazione UICC con HCI riesce a comunicare con il Terminal Host mediante a logical pipe (ISO/IEC 7816) mentre con CLF tramite il protocollo SWP (è una linea fisica sulla quale i dati scambiati sono codificati nel formato HCP (Host Controller Protocol) ). Per quanto riguardo lo strato fisico nessun componente Host può comunicare direttamente con un device esterno; tramite HCI tutti i messaggi passano all Host Controller (CLF) che poi li inoltra verso l esterno. CLF si interfaccia tramite un interfaccia proprietaria o SWP con il Terminal Host e mediante il protocollo SWP con UICC. Per utilizzare il SWP è necessario codificare i dati in formato HCP; poi per poterli trasmettere occorre dividerli in messaggi più piccoli e aggiungere le informazioni di controllo necessarie al HCP routing. A questo punto è possibile utilizzare SWP che è un protocollo del logical link, dello strato MAC e dello strato fisico. Figura 7 Componenti SWP e loro strati di comunicazione 16

17 2.5. TAG NFC Le modalità operative del mobile NFC sono 3: NFC Reader mode (lettura tag): il dispositivo è ATTIVO NFC Card Emulation mode: il dispositivo è PASSIVO Peer to Peer mode: entrambi i dispositivi sono ATTIVI Nella modalità Reader Mode il dispositivo è utilizzato per comunicare (READ/WRITE) con TAG NFC. NFC Forum ha individuato 4 tipi differenti di TAG. Essi si differenziano per le diverse dimensioni della memoria, velocità di comunicazione e configurazione. Una esaustiva differenziazione è riportata nella tabella seguente: 17

18 Tabella 8 Differenziazione TAG 18

19 2.6. SWP Prima parliamo del protocollo Single Wire Protocol (SWP) che definisce il formato dei messaggi che sono scambiati sull interfaccia SWP tra il controllore Contactless Frontend (CLF) e UICC. Dopo, nella sezione del payload delle SWP-frames viene introdotto l Host Controller Protocol(HCP) con comandi ed eventi del Host Controler Interface (HCI). Grazie ai HCI-Commands il CLF e UICC sono in grado di scambiarsi messaggi, configurarsi e comunicare tramite APDU verso terminali NFC esterni. PROTOCOLLO SWP La figura 4 descrive una singola trama SWP contenente un messaggio HCP non frammentato. MAC Layer: ciascuna trama SWP ricevuta viene valutata dal Medium Access Control Layer, il quale individua SOF,EOF e controlla il CRC Checksum LINK Layer: il Link Layer controlla il byte LLC-Control per determinare il tipo di messaggio: ACT (obbligatorio): usato durante l attivazione del SWP CLT (opzionale): Contactless Tunnelling, usato per trasportare meccanismi proprietari SHDLC (obbligatorio): Simplified High Level Data Link Control, usato per il regolare scambio di dati. HCP Packet Layer: in un normale payload SHDLC l Header byte indica il chaining (frammentazione del messaggio) e Pipe-ID. HCP Message Layer: l HCP header del messaggio contiene il tipo del messaggio (comando, evento o risposta) e la corrispondente HCI Istruzione/Evento. 19

20 Figura 9 Struttura dei vari elementi di comunicazione nei vari strati protocollari del SWP 2.7. HCP Message Fragmentation Siccome la dimensione massima del payload di un messaggio HCP è di 27 byte,allora i messaggi più lunghi devono essere frammentati all interno di più trame. La presenza di frammentazione è indicata dal Chaining bit (CB) contenuto nell HCP Packet Header. Solo l ultima trama di messaggio frammentato ha il Chaining bit posto uguale a 1. I messaggi non frammentati hanno il Chaining bit sempre posto uguale a 1. L HCP Message Header appare solo nella prima trama del messaggio frammentato. Es. messaggio frammentato in 2 trame: 20

21 Figura 10 Messaggio frammentato in due trame Quando avviene lo scambio di APDUs tramite SWP, ciascuna APDU è riferita ad un unico HCI Exchange Command, quindi un messaggio frammentato HCP contiene una sola APDU PROTOCOLLO HCI Il protocollo HCI è definito in ETSI TS ed è usato per creare collegamenti logici (logical links) tra varie entità fisiche che sono connesse tramite SWP. Le entità fisiche coinvolte all interno di un cellulare sono: CLF (Host Controller) UICC (Host) Baseband-Controller (Host) (sarebbe il chip del cellulare non dell NFC, quello dell NFC è compreso all interno del CLF). 21

22 Figura 11 Logical connections in the HCI network La connessione fisica tra controllore del cellulare (baseband controller) e CLF non è necessariamente fatta tramite SWP, può essere un altra interfaccia che dipende da CLF/mobile design. 3. JavaCard Java Card è una tecnologia in grande sviluppo, soprattutto per quanto riguarda lo sviluppo di applet nel mobile. Scopo di questo documento è introdurre questa tecnologia e le sue caratteristiche principali. Nel secondo capitolo parleremo delle smart card, delle loro classificazioni e di come avviene lo scambio dei messaggi. Da queste spiegazioni formali sulle JavaCard e smart card, ci addentreremo nel dettaglio analizzando l architettura software di Java Card, il framework e le API di nostro interesse e infine il ciclo di vita di una applet. 22

23 3.1. Introduzione a JavaCard JavaCard è una tecnologia che permette di eseguire piccole applicazioni JAVA (Applet) su smart card. Caratteristiche principali di questa tecnologia sono: PORTABILITA SICUREZZA La portabilità è resa possibile grazie alla definizione di un ambiente applicativo standard per smart card che consenta alla stessa applicazione di funzionare su diverse smart card. Questo è consentito grazie all utilizzo di una Virtual Machine (J2ME: Java 2 Micro Edition, nata dall'esigenza di realizzare un macchina virtuale leggera quindi privata di molte funzionalità ritenute superflue della JVM) e ad un insieme di librerie predefinite. La sicurezza è un concetto fondamentale per questa tecnologia perché bisogna garantire che le informazioni memorizzate su una smart card non vengano violate da accessi non autorizzati. A tal proposito, JavaCard offre un elevato grado di sicurezza grazie ad una serie di aspetti: Data encapsulation (i dati sono memorizzati dentro l'applicazione Java, separata dall hardware e dal sistema operativo); Applet Firewall (le diverse applicazioni sono mutuamente separate da firewall che impediscono l'accesso ai dati); Crittografia (si usano algoritmi come DES, 3DES, AES, RSA, ecc.); Applet (stato della macchina che processa solo i comandi in arrivo e risponde inviando dati all'interfaccia del sistema). 23

24 3.2. Cos è una smart card La smart card è un dispositivo hardware delle dimensioni di una carta di credito o di una SIM card che possiede potenzialità di elaborazione e memorizzazione dati ad elevata sicurezza. Una smart card è costituita da un insieme di tecnologie quali circuiti integrati, microprocessori, memorie RAM, ROM, EEPROM, antenne, ecc., integrate nello stesso circuito elettrico per formare un microchip che è il "cuore" della smart card Architettura di una Smart card La smart card è costituita da un supporto di plastica nel quale è incastonato un microchip connesso ad un'interfaccia di collegamento che può essere una contattiera o un'antenna. Il microchip fornisce funzionalità di calcolo e memorizzazione dati. Figura 12 Smart Card Normalmente una smart card non contiene un alimentatore, un display o una tastiera; esso interagisce con il mondo esterno utilizzando la contattiera o l'antenna che consentono al microchip di dialogare con uno speciale terminale di lettura (CAD: reader,pos) collegato solitamente ad un computer mediante porta seriale, parallela, USB, ecc. La contattiera è composta da 8 punti di contatto (figura 2). 24

25 Figura 13 Eight Contact Points Il microchip fornisce funzionalità di calcolo e memorizzazione dati ed è in grado di elaborare e conservare informazioni sensibili utilizzando algoritmi di sicurezza come AES, DES e RSA. Le SmartCard sono fortemente usate nelle procedure di autenticazione perché permettono di memorizzare le credenziali dell utente in modo sicuro, infatti l accesso alle credenziali è subordinato alla verifica di un PIN (Personal Idetification Number) Classificazione delle Smart Card Le smart card possono essere classificate sulla base delle potenzialità e delle caratteristiche del microchip in: smart card a sola memoria (Memory Card): offrono unicamente funzionalità di memorizzazione sicura dei dati. Il microchip contiene una componente di memoria permanente nella quale si può leggere e scrivere attraverso un insieme di funzioni cablate. Tecnologicamente più semplici, sono più economiche ma offrono un livello di sicurezza più basso rispetto alle smart card a microprocessore perché l accesso ai dati si basa tipicamente su un insieme di permessi di accesso.(es. Carte per raccolta punti al supermercato o alla benzina) smart card a microprocessore (Microprocessor Card): può essere paragonata ad un piccolo computer portatile altamente affidabile e inattaccabile in grado di elaborare e memorizzare informazioni salvaguardandone la riservatezza. Nella memoria del microchip è installato un sistema operativo che implementa la logica operativa 25

26 della smart card. In particolare il sistema operativo si occupa della gestione interna della memoria e fornisce varie funzioni tra le quali lettura e scrittura in memoria, funzioni di programmazione dei permessi di accesso, funzioni crittografiche, ecc. La programmabilità del microchip conseguente alla presenza di un sistema operativo, consente di ottimizzare e personalizzare la smart card per una particolare applicazione o di integrare sullo stesso dispositivo più applicazioni (eventualmente interagenti tra loro). Il set di comandi di una smart card a microprocessore è molto più vasto di quello di una smart card a sola memoria. Il singolo comando viene chiamato APDU (Application Protocol Data Unit). In base al tipo di interfaccia di collegamento, le smart card, possono essere classificate in: Smart card con contattiera (Contact): hanno una contattiera mediante la quale ricevono l'alimentazione e dialogano con l'esterno una volta inserite in un apposito dispositivo terminale detto lettore di smart card. Smart card con antenna (Contacless smartcard): hanno un'antenna che reagisce alla presenza di un campo elettromagnetico emesso da uno speciale dispositivo di lettura/scrittura nella banda delle radio-frequenze (con tecnologia RFID), consentendo al microchip di scambiare dati con l'esterno (purché l'antenna si trovi entro una distanza minima dal dispositivo di lettura/scrittura). Le smart card dual-interface offrono entrambe le interfacce contact e contacless e pertanto la comunicazione con il microchip può avvenire indifferentemente mediante una o l'altra. Le smart card di nostro interesse sono quelle a microprocessore contacless Smart card a microprocessore Le smart card a microprocessore sono anche dette smart card intelligenti grazie alla presenza di una CPU che permette di processare ed eseguire comandi. 26

27 Oltre che alla CPU, le smart card a microprocessore sono formate da: Una RAM: utilizzata per gestire i dati durante l elaborazione Una ROM: contiene il sistema operativo Una EEPROM: conservare i dati in maniera persistente Un circuito di sicurezza Porte di I/O: sono in tutto 8 C1 tensione di alimentazione C2 reset C3 clock C4 e C8 riservate per usi futuri C5 tensione a massa C6 tensione di programmazione C7 per operazioni di I/O Le card a microprocessore offrono sicurezza, autenticazione, e possibilità di gestione dei dati in aggiunta alla semplice memorizzazione dati. In genere le carte con CPU forniscono anche la possibilità di crittografate i dati. Le carte con CPU hanno integrato un microprocessore per la gestione delle operazioni. Gli standard che definiscono il protocollo di comunicazione asincrona a cui queste smart card possono conformarsi sono: ISO T=0, T=1, T=14. Le carte con CPU supportano: File management Gestione delle chiavi Regole di accesso ai dati Autenticazione Crittografia Una delle funzioni più significative delle carte con CPU é la possibilità di gestire applicazioni multiple e memorizzarle in file logici e directories. 27

28 Applicazioni tipiche per le carte con CPU sono: carte di credito, pagamenti elettronici, firma elettronica, identificazione sicura. Queste carte sono adatte per tutte quelle applicazioni che richiedano un forte controllo per accedere ai dati. Questi meccanismi rendono le carte con CPU perfette per applicazioni che richiedano memorizzazioni potenti e sicure. Alcuni degli utilizzi attuali delle smart card sono: applicazioni di tipo banking e commercio elettronico, incluso il borsellino elettronico vendite al minuto e programmi di fidelizzazione telecomunicazioni trasporti sicurezza nell accesso ai computer e autenticazione utilizzo controllato e remunerato di servizi quali accesso ad Internet, banche dati,.. Ogni Smart Card con CPU è dotata di un sistema operativo, che serve alle applicazioni per accedere alle funzioni di base dell'hardware e alla gestione dei dati. A differenza di un normale computer, una Smart Card non include interfacce utente e accesso a memorie esterne, visti i compiti a cui è destinata e i requisiti di sicurezza. Di base, le funzioni del sistema operativo sono: trasferimento di dati da e verso la scheda, controllo dell'esecuzione dei comandi, gestione dei file (tutti in EEPROM) e gestione ed esecuzione degli algoritmi crittografici. La crittografia è l'area chiave che permette alle moderne Smart Card di garantire una serie di obiettivi di sicurezza: l'autenticazione dell'utente, la riservatezza dei dati conservati e trasmessi, l'integrità delle comunicazioni e quello che viene chiamato non ripudio, ovvero l'impossibilità che il mittente e il destinatario di un messaggio possano negare di avere rispettivamente inviato e ricevuto il messaggio, come se fosse una raccomandata con ricevuta di ritorno. Alcune funzioni base di una Smart Card con supporto crittografico sono la generazione di chiavi, la lettura della chiave pubblica, la cifratura di dati con la chiave privata (usata ad es. nella firma digitale) e operazioni sui certificati digitali. 28

29 3.6. Sistema Operativo delle smart card All'inizio degli anni '90 c'erano pochissimi sistemi operativi (OS) per Smart Card, anche a causa della limitatissima quantità di memoria disponibile. Anziché un vero OS, veniva usata una libreria di routine in ROM richiamata, quando necessario, dal software applicativo. Uno dei primi è stato Starcos di Giesecke & Devrient ( giunto oggi alla release 3.0, dotata di pieno corredo crittografico e utilizzabile per tutte le applicazioni di sicurezza. Tra i tanti nomi di OS per Smart Card, citiamo CardOS di Infineon, Cyberflex, Multiflex e Payplex di Schlumberger, MFC di IBM, Micado di Orga, Oscar di Oki, Pcos, Mcos e Mpcos di Gemplus (che produce oltre un quarto delle Smart Card), TB, CC e Odyssey di Bull, Tcos di Telesc e, citati per ultimi ma oggi i più importanti, Multos di Maosco e Java Card di Sun. Java Card OS ( e è popolare perché, in stile Java, permette l'indipendenza delle applicazioni dall'architettura sottostante. Di conseguenza, i produttori non si limitano a implementare gli standard ISO, rendendo quindi arduo il trasporto delle applicazioni da una piattaforma all'altra. Solitamente l utente abbonato ad un servizio telefonico utilizza una smart card (SIM card) per attivare il telefono. La scheda viene autenticata dall'utente per ottenere le chiavi di crittografia per la trasmissione vocale. Da quando si è introdotta la tecnologia Java Card le SIM sono in grado di fornire altri servizi oltre alla semplice autenticazione, quali ad esempio il remote banking e servizi di biglietteria Modello scambio di messaggi La CPU comunica con gli altri elementi della smart card e con il mondo esterno mediante pacchetti APDU. 29

30 Figura 14 Modello scambio messaggi interni Figura 15 Modello scambio messaggi con l'esterno Un comando APDU è composto da un header di 4byte e da un body di lunghezza variabile; ha la seguente frame descritta dalla norma ISO 7816: 30

31 Comando APDU Figura 16 Comando APDU CLA: Classe byte. Utilizzato per identificare un applicazione INS: byte istruzioni. Questo byte indica il codice dell istruzioni P1-P2: P2: parametri d ingresso o Lc: indica il numero di byte del campo Data Field o Le: indica il numero massimo di byte che possono occupare i dati di risposta o Data Field: è il campo dove sono contenuti i dati veri e propri Esistono 4 tipi di comandi APDU: 1) Command APDU di tipo 1: non inviano dati alla Java Card e non si aspettano dati in risposta. In questo caso la parte dati è completamente mancante. 2) Command APDU di tipo 2: non inviano dati alla Java Card ma richiedono dati in risposta. In questo caso la parte dati prevede l utilizzo del byte Le per specificare la lunghezza della risposta attesa. 3) Command APDU di tipo 3: inviano dati alla Java Card ma che non si aspettano dati in risposta. In questo caso la parte dati prevede l utilizzo del byte Lc per contenere la lunghezza della parte dati dell APDU. 4) Command APDU di tipo 4: inviano dati alla Java Card e richiedono dati in risposta. In questo caso tutti i byte del comando APDU sono scritti. Una response APDU ha un formato differente da un comando APDU; ha un body di lunghezza variabile e 2 byte di stato: 31

32 Response APDU Figura 17 Risposta APDU DataField: contiene i dati effettivi di risposta SW1 e SW2: contengono il primo ed il secondo byte di stato dell elaborazione del comando Il meccanismo che permette alla smart card di comunicare con l esterno può essere descritto come segue: Il CAD (o reader) riceve un comando formattato all interno di un APDU, lo invia alla smart card e si mette in attesa di risposta; Il meccanismo di scambio interno di comandi APDU: 1. Arrivato il comando tramite le porte di I/O, il JCRE(Java Card Runtime Environment) interpreta l header dell APDU e riconosce se si tratta di un comando per la JavaCard Applet corrente o di una selezione per una nuova JavaCard Applet; 2. Se si tratta di un comando, l APDU viene passato alla JavaCard Applet corrente dalla CPU. Se si tratta di una selezione il Framework procede alla selezione della nuova JavaCard Applet e passa a quest ultima, una volta attivata, l APDU stesso; 3. Una volta che la JavaCard Applet ha terminato le elaborazioni richieste, restituisce un risultato formato da eventuali dati di risposta e da una SW (Status Word composta di due byte) che indica se l operazione è terminata con successo (valore esadecimale 0x9000) oppure no (codice del tipo di eccezione riscontrata). 32

33 Formato il paccheto di risposta APDU viene mandato al CAD. Notare che il JCRE si occupa anche dell invocazione dei metodi nativi corrispondenti a funzioni di utilità generale, quale la cancellazione di tutto il contenuto della JavaCard, chiamato in gergo Master Erasing. In questi casi il comando APDU ricevuto non viene inviato ad una JavaCard Applet e non serve a selezionare una nuova JavaCard Applet (come descritto precedentemente nel punto due), ma viene utilizzato per richiamare il metodo nativo richiesto con gli eventuali parametri specificati Cos è Java Card Java Card è un ambiente per lo sviluppo di applicazioni su smart card (es. la SIM di un cellulare) in Java. Caratteristiche peculiari di Java Card sono: Indipendenza dalla piattaforma: un applicazione per Java Card (Java Card Applet), scritta rispettando le regole imposte dall API Java Card, può essere utilizzata senza modifiche su Java Card fornite da costruttori diversi (usando Card VM) Supporto a più applicazioni: su una stessa Java Card possono coesistere diverse applicazioni (Java Card Applet) indipendenti fra loro e selezionabili singolarmente in fase di esecuzione Caricamento di nuove applicazioni dopo la consegna: dopo che una Java Card è stata consegnata all utente finale è ancora possibile caricare nuove applicazioni attraverso terminali addetti all espletamento dei servizi Flessibilità: il linguaggio utilizzato per programmare le Java Card è un subset del linguaggio Java Compatibilità con gli standard delle SmartCard: le Java Card sono compatibili con lo standard ISO 7816, lo standard più diffuso nel campo delle Smart Card Per comprendere a fondo le caratteristiche dell ambiente Java Card è necessario conoscere anche l hardware su cui è implementato. Questo è composto essenzialmente dal pool delle memorie e dal processore della smart card. 33

34 3.9. Componenti software di Java Card Una generica JavaCard contiene al suo interno i seguenti componenti software: Metodi Nativi: sono i metodi che forniscono le funzionalità di I/O, le funzionalità crittografiche e i servizi di allocazione della memoria; JCVM (Java Card Virtual Machine): è l entità che si occupa dell interpretazione del bytecode JavaCard e che fornisce il supporto al linguaggio; Framework: è l insieme delle classi che implementano l API JavaCard 2.0 e include sia i package standard sia le eventuali estensioni standard. Questo componente provvede anche all installazione delle JavaCard Applet; JavaCard API 2.0: si tratta dell interfaccia utilizzata dalle JavaCard Applet per l accesso al JCRE e ai Metodi Nativi. JCRE (Java Card Runtime Environment): questo componente raggruppa al suo interno la JCVM, il Framework, i Metodi Nativi e l API JavaCard 2.0. Estensioni Proprietarie: si tratta di classi aggiuntive definite dal costruttore della JavaCard che possono essere utilizzate dalle JavaCard Applet. JavaCard Applet: sono applicazioni scritte in linguaggio Java per essere eseguite su JavaCard. Le Java Card Applet hanno le seguenti caratteristiche: Solo una Java Card Applet alla volta è in esecuzione, per passare ad un altra Java Card Applet è necessario deselezionare la Java Card Applet corrente e selezionarne un altra; Ogni Java Card Applet è univocamente identificata da un AID (Application Identifier), che gli viene assegnato in fase di caricamento nella Java Card, ed eredita dalla classe javacard.system.applet; 34

35 Le Java Card Applet sono passive, nel senso che non iniziano mai una comunicazione ma possono solo rispondere a richieste provenienti dall'esterno; Le Java Card Applet sono isolate di default una dall altra, ma possono condividere risorse fra loro o fra alcune di loro richiedendolo esplicitamente tramite il metodo System.share(). Questo metodo permette di condividere un oggetto, specificato come argomento, fra tutte le Java Card Applet presenti sulla Java Card. Aggiungendo agli argomenti un AID ha come risultato una condivisione limitata con la sola Java Card Applet cui corrisponde l identificatore. Figura 18 Organizzazione dei componenti SW di JavaCard Si può notare la suddivisione in livelli logici. L entità su cui si basa l intera struttura software di una JavaCard è il JCRE (Java Card Runtime Environment). Quest entità contiene la JCVM (Java Card Virtual Machine, deputata all elaborazione del bytecode), il Framework (che a sua volta contiene l insieme delle classi dell API JavaCard 2.0, deputato alla gestione della comunicazione con il CAD e alla fornitura delle funzionalità dell API) e l insieme dei metodi nativi (metodi implementati tramite opportuno hardware e/o firmware per elaborazioni dedicate, quali per esempio implementazioni di algoritmi di 35

36 crittografia). Immediatamente sopra eventuali estensioni proprietarie e sopra tutto le applet Java Card. La JCVM (Java Card Virtual Machine) ha funzionalità ridotte rispetto alla JVM (Java Virtual Machine), infatti i Converter (convertitori utilizzati per tradurre il bytecode Java compilato su PC o su workstation in un formato che ne permetta il caricamento su Java Card) eseguono anche i compiti di loading delle classi e risoluzione dei riferimenti. Figura 19 Separazione della virtual machine java card su due ambienti La VM (Virtual Machine) di una Java Card viene, quindi, distribuita nello spazio e nel tempo tramite due componenti separati: uno all esterno della Java Card, integrato nel Convertitore, e uno all interno della Java Card, nella JCVM integrata nel JCRE Le Java Card framework Particolarmente importanti, dal punto di vista del programmatore, sono le funzionalità implementate dal Framework: Installazione delle JavaCard Applet (ogni JavaCard Applet deve essere installata sulla JavaCard prima di poter essere utilizzata); Selezione della JavaCard Applet corrente (per mezzo dei comandi provenienti dal CAD); 36

37 Distribuzione degli APDU (Application Protocol Data Unit, comandi formattati provenienti dal CAD) alle JavaCard Applet; Gestione delle funzioni destinate a garantire l atomicità (metodi atomici e gestione delle transazioni). Il framework di Java Card contiene quattro pacchetti: javacard.framework: definisce le classi come Applet e PIN javacardx.framework: fornisce una progettazione orientata agli oggetti javacardx.crypto e javacardx.cryptoenc: per supporto ai processi crittografici delle smart card Si noti che all interno del framework è contenuta la JavaCard API 2.0, cioè l insieme dei package che forniscono accesso alle risorse del JCRE dal codice delle JavaCard Applet Le classi API di Java Card Le classi e le interfacce fornite dalle API sono suddivise in 5 package: Javax.microedition.contactless: Permette l identificazione dei TAG. Javax.microedition.contactless.ndef: Contiene le classi e le interfacce necessarie alla comunicazione di TAG formattati secondo il formato NDEF. Javax.microedition.contactless.rf: Contiene le classi e le interfacce necessarie alla comunicazione di TAG non formattati secondo lo standard NDEF. Javax.microedition.contactless.sc: permette di comunicare con dispositivi NFC in modalità di emulazione carta Javax.microedition.contactless.visual: Consente di interagire con i TAG visivi (es. i codici a barre) 37

38 Figura 20 API JavaCard relationship Android Android è una piattaforma open source basata su kernel Linux ed ottimizzata per i dispositivi mobili. Il processo che ha portato alla luce Android è iniziato nel luglio del 2005 con l acquisizione da parte di Google di una giovane società (Android Inc). L intento di Google non era ancora ufficiale e noto: la società si preparava ad effettuare il suo ingresso nel mercato dei dispositivi mobili. Nel novembre del 2007 viene presentata la Open Handset Alliance, un accordo tra 35 società produttrici di dispositivi mobili, di software e operatori di telefonia mobile, tra cui, oltre la capofila Google, erano presenti: Texas Instruments, HTC, Intel, Motorola, Samsung, T-Mobile, Vodafone, Telecom Italia e Ebay. Lo scopo della Open Handset Alliance (OHA) è quello di sviluppare standard aperti per dispositivi mobili ed in coincidenza con la presentazione dell OHA, viene presentato il primo prodotto sviluppato: Android. 38

39 La piattaforma software Android è rilasciata secondo i termini della licenza Apache. Ovvero, il software può essere modificato e distribuito secondo i termini di altre licenze non necessariamente libere. Lo sviluppatore è tenuto, ad ogni modo, a rendere noto con un'informativa quali parti di software, licenziato secondo i termini della licenza Apache, sono state modificate. Il primo smartphone dotato di piattaforma Android è stato l HTC Dream, presentato il 22 Ottobre del La seguente figura (5) disponibile sul sito internet developer.android.com/index.html, illustra i principali componenti del sistema operativo: Al livello più alto si pongono le applicazioni. La piattaforma Android è dotata di client mail, di programmi per la gestione degli SMS, di un calendario degli appuntamenti, di applicazioni per la gestione della rubrica, di un browser web, di un programma per la gestione delle mappe stradali ed altro ancora. Tutte le applicazioni sono scritte in linguaggio Java. Gli sviluppatori hanno pieno accesso alle API utilizzate dalle applicazioni ubicate al livello più alto dello stack in figura 5. La progettazione delle applicazioni è pensata per semplificare il riuso del codice. 39

40 Figura 5 Architettura del sistema Android è dotata di un set di librerie C e C++. Se ne citano alcune: System C library - si tratta di una libreria derivata da libc, la libreria standard Linux, adattata per i dispositivi mobili. Media Libraries - libreria per il supporto a diversi formati audio e video, oltre che alla manipolazione delle immagini. Surface Manager - libreria per la grafica 2D e 3D. LibWebCore - è la base del motore del browser web utilizzato da Android. SGL - è il motore per la grafica 3d. 3D libraries - si tratta di un implementazione delle API di OpenGL ES 1.0; le librerie che gestiscono l accelerazione grafica 3D. SQLite - è il leggero database disponibile per le applicazioni Android 40

41 È possibile distinguere, nella figura 5, la sezione Android Runtime. Ogni applicazione in esecuzione in ambiente Android genera un istanza di una macchina virtuale (Dalvik). Il meccanismo è volto all ottimizzazione delle limitate risorse di cui dispone uno smartphone, in particolar modo, questo meccanismo consente una gestione più efficiente della memoria. Per lo sviluppo di applicazioni è disponibile un SDK, installabile in ambiente GNU/Linux, Windows o Mac OS. L SDK è dotato dei necessari strumenti di sviluppo, inclusi debugger ed un emulatore per il testing (basato su QEMU). È inoltre prevista l integrazione con l IDE Eclipse. 41

42 2. Mobile Proximity Payment Ora ci addentreremo nel proximity payment, che, come già detto nel capitolo precedente, è la modalità di pagamento che sfrutta la tecnologia NFC. Successivamente daremo un link funzionale tra tutte le tecnologie descritte precedentemente e delle loro iterazioni con il mondo esterno descrivendo l architettura complessiva e gli attori coinvolti. 1. Elementi coinvolti Il Proximity Payment è una modalità di pagamento in mobilità che sfrutta i benefici delle smartcard cosiddette Contactless integrate su uno smartphone. Gli elementi coinvolti in un processo di pagamento in mobilità sono: Service Provide SP: è il fornitore di servizi internet. Essi certificano ed interagiscono con TSM per veicolare le proprie app sui device utenti. TSM: è l entità che permette ai SP di distribuire e gestire in modo sicuro le app sulle Sim degli utenti. In particolare gestisce il provisionig delle applicazioni. Per garantire questa sicurezza, esso, gestisce a basso livello il contenuto della carta SIM consentendo la creazione di spazi riservati ai service provider (Security Domani) su cui scaricare, installare e personalizzare le applicazioni NFC. Piattaforma OTA: Supporto Global Platform 2.2 ed invia i comandi di Card Content Management alle carte sulla base degli input ricevuti dal TSM. Applicazione su Terminale: Applicazione (tipicamente J2ME) che realizza la user 42

43 interface per la gestione operativa del servizio (es. inset PIN, etc) Applicazione su SIM: Applicazione JavaCard che implementa logica di servizio specifica: Banking: VISA, Master Card, (fornite da SP) Transport e Access Control: MIFARE, Calypso) Terminale NFC Enabled: In grado di interagire via NFC (supporto Simple Wired Protocol) in Reader Mode (Tag Reader) e Card Emulation Mode (Interazione con POS). SIM NFC: è il Secure Element su cui installare APP di pagamento. Figura 21 Architettura del sistema 43

44 2. APP e Applet Definita l architettura, il passo successivo sarà quello di simulare un vero e proprio processo di pagamento in prossimità. Prima di fare ciò, però, è indispensabile capire quali sono gli strumenti che ci supporteranno per l intero processo. Innanzitutto avremo bisogno di una Applet su SIM, e di una APP Android che mi permetta di comunicare con l applet. In secondo luogo, sarà necessaria una qualsiasi altra APP Android che sia in grado di comunicare con la prima e che mi permetta di realizzare una spesa, con carrello,informazioni e quant altro. 3. Applet su SIM Una Applet è una applicazione memorizzata nel SE della SIM che mi permette di gestire l accesso ai Secure Domine. Il Secure Element, nel nostro caso, è all interno della smartcard, questo permette una maggiore sicurezza, e portabilità. Il SE è composto da più Secure Domine secondo una struttura ad albero. Ogni Secure Domine memorizza informazioni sensibili come possono essere, nel nostro caso, le credenziali di una carta di credito. Vediamo in che modo i dati sensibili della carta di credito vengono memorizzati. Come già detto i dati vengono memorizzati all interno del secure element un componente hardware che è integrato all interno della SIM. La dimensione della memoria dell elemento è di 72Kb, in cui una certa dimensione è riservata per le applicazioni specifiche del cellulare. Mentre la memoria disponibile per le applicaizoni nella Java Card è di 65Kb. 44

45 Figura 6 Struttura del Secure Element Il Secure Element è governato da regole e procedure di sicurezza molto stringenti. Si trova in uno stato SICURO dal momento dell acquisto della SIM. Ci sono 2 differenti chiavi di autenticazione per accedere al secure element, una per l accesso alla Java Card e l altra per l accesso alla Mifare 4k. Java Card soddisfa requisiti di sicurezza molto alti derivanti direttamente dal life-cycle dell elemento stesso. A partire dal silicio usato per la costruzione del chip, al sistema operativo, al processo di costruzione e trasferimento dei dati al suo interno. Quando si acquista un cellulare il secure element contiene solo il dato segreto della chiave specifica del dispositivo. 4. APP1 Android Come supporto all intero processo è indispensabile un APP, nel nostro caso Android, che interfacci l utente con l applet. La nostra APP la chiameremo Gestore Carte, il suo compito sarà quello di comunicare con l applet per consentire all utente di effettuare una scelta sulla modalità di pagamento da voler utilizzare. Come già detto, nel SE ci sono più SD, in ognuno di questi ci sono delle credenziali carta e/o wallet, quindi nel nostro scenario supporremo che l utente abbia nella propria SIM più carte di credito/wallet da poter utilizzare e quindi da poter scegliere per effettuare il pagamento. Quest applicazione, quindi, permetterà all utente di scegliere tra più carte, a seguito della scelta dell utente, gli si chiederà di inserire un PIN che consentirà lo sblocco del SD corrispondente alla carta/selezionata. 45

46 5. APP2 Android La seconda APP che realizzeremo, consentirà all utente di effettuare una vera e propria spesa, e avrà il compito di interfacciarsi con la prima per effettuare il pagamento di quanto scelto precedentemente. Nel nostro caso, questa prima APP gestisce una spesa in un supermercato. Lo scenario tipico è che l utente entra nel supermercato, sceglie i prodotti avvicinando il proprio smartphone allo scaffale, che sarà dotato di TAG NFC da cui potrà avere informazioni aggiuntive, e potrà decidere se aggiungerli o meno al carrello virtuale dell applicazione. Terminata la scelta dei prodotti, verrà richiamato Gestore Carte che si occuperà della fase di pagamento. Cosa molto importante per quanto riguarda la separazione tra la prima e la seconda APP è che la prima è completamente indipendente dalla seconda. Questo mi consente di creare più APP supermercato, o di altro genere, che si interfaccino sempre con lo stesso Gestore Carte, quindi Gestore Carte può gestire il pagamento di qualsiasi altra applicazione che lo richiedi. 6. Scenari d uso e analisi dei requisiti Ora vedremo come quanto detto può realizzarsi nella realtà. Per farlo analizzaremo un possibile scenario d uso che consenta all utente di effettuare un pagamento proximity utilizzando lo smartphone. I passi che l utente dovrà seguire sono: L utente entra nel supermercato e avvia APP2 che chiameremo SUPERAPP 1. L utente sceglierà cosa acquistare effettuando un tapping sullo scaffale 2. SuperApp farà visualizzare a schermo delle info aggiuntive sul prodotto scelto 3. L utente potrà decidere se aggiungerlo al carrello o no 4. Al termine della scelta dei prodotti si dirigerà alla cassa per pagare quanto scelto 5. L utente avvicinerà lo smartphone al POS 46

47 6. Il POS risveglierà l app Gestore Carte 7. Il Gestore Carte richiede la lista delle carte/wallet all applet della SIM 8. L applet legge le carte/wallet presenti nei SD e invia la lista al Gestore Carte 9. Il Gestore Carte fa visualizzare la lista di carte/wallet e attende la selezione del cliente 10. L utente sceglie la carta/wallet con cui intende effettuare il pagamento 11. A questo punto verrà chiesto all utente di inserire un PIN che servirà all applet per accedere al Secure Domine 12. L utente inserisce il PIN 13. Il Gestore Carte invia i dati alla SIM richiedendo lo sblocco del SD associato alla carta selezionata e resta in attesa dell esito 14. Il Gestore Carte riceve l esito dell operazione di sblocco dell SD a. Esito positivo: l applet invia le credenziali della carta al POS che effettua il pagamento b. Esito negativo: l applet invia un messaggio d errore a Gestore Carte che torna alla schermata di Seleziona Carta 15. Il Gestore Carte riceve una notifica di pagamento a. Esito positivo: Gestore Carte riceve una conferma di pagamento dal POS b. Esito negativo: Gestore Carte riceve un messaggio d errore, e si torna al passo 3 47

48 Figura 7 Flow chart processo di pagamento 48

49 3. Analisi e progettazione di alto livello In questo documento verranno descritti tutti i casi d uso individuati per l applicazione Gestore Carte e Applet, successivamente passeremo agli activity diagram e sequence diagram. Nel capitolo successivo si analizzarano gli use case dell applicazione del supermercato, che andranno a completaregli use case, gli activity diagram, i sequence diagram ed infine il class diagram con cui concluderemo la fase di progettazione. Da notare che gli use case che individueremo in questo capitolo non sono numerati a partire da 1 perché la fase di progettazione è stata effettuata in parallelo con quella dell applicazione successiva, quindi andremo a completare tutti i casi d uso nel capitolo Casi d uso associate al gesture delle carte Remote Payment UC9 Portata Applicativo per smartphone Parte interessata Utente Telecom Interessi Effettuare il pagamento del 20% in remoto Attori - Primario: Utente - SuD: SUPER-APP, CARD-APP,APPLET - Supporto: Connessione remota 49

50 Precondizioni - Termina&paga (UC7) Flusso base 1.1 (UC14) 2.1 (UC15) 3.1 CardApp richiede le credenziali carta all applet 4.1 CardApp riceve le credenziali carta dall applet 5.1 CardApp inoltra i dati per il pagamento remoto a SUPER_APP e attende l esito Postcondizioni - Cliente ha pagato il 20% della spesa da remoto - Cliente attende la spesa a casa Cammini MAIN PATH:

51 3.1.2 Proximity payment UC12 Portata Applicativo per smartphone Parte interessata Utente Telecom Interessi Effettuare il pagamento attraverso metodo di pagamento in prossimità Attori - Primario: Utente - SuD: SUPER-APP, CARD-APP, APPLET - Supporto: POS per effettuare il pagamento mediante tapping NFC Precondizioni - Termina&paga (UC7) Flusso base 1.1 (UC14) 2.1 (UC15) 3.1 CardApp richiede lo sblocco dell SD associato alla carta selezionata all applet 4.1 CardApp riceve l esito dell operazione di sblocco dell SD Esito positivo: l applet invia le credenziali della carta al POS che effettua il pagamento Esito negativo: l applet invia un messaggio d errore a CardApp 5.1 Operazione successiva all esito POS effettua il pagamento CardApp torna a Scegli Carta (1.1) 6.1 CardApp riceve una notifica di pagamento Esito positivo: CardApp riceve una conferma di pagamento dal POS Esito negativo: CardApp riceve un messaggio d errore 7.1 CardApp inoltra l esito a SuperApp 51

52 7.1.1 Esito positivo: SuperApp genera lo scontrino Esito negativo: SuperApp fa visualizzare l esito al cliente e torna al Menù Principale (UC6) 8.1 CardApp termina 9.1 SuperApp riceve l esito positivo del proximity payment 10.1 SuperApp memorizza la spesa in formato scontrino 11.1 SuperApp fa visualizzare lo scontrino generato al cliente Postcondizioni - Cliente ha pagato il TOT della spesa - Cliente riceve la spesa Cammini MAIN PATH: PATH_1: PATH_2:

53 3.1.3 Visualizza carte UC14 Portata Applicativo per smartphone Parte interessata Utente Telecom Interessi Visualizzare le carte disponibili per effettuare il pagamento Attori - Primario: Utente 53

54 - SuD: CARD-APP,APPLET - Supporto: Nessuno Precondizioni - Proximity pay (UC12) - Remote pay (UC9) Flusso base 1.1 Cliente seleziona l opzione Termina&Paga dalla schermata del Menù Principale 2.1 SuperApp apre CardApp (alternativa 2.2) 3.1 CardApp richiede la lista delle carte/wallet all applet 4.1 L applet legge le carte/wallet presenti nei SD e invia la lista a CardApp 5.1 CardApp visualizza la lista di carte/wallet e attende la selezione del cliente Flusso alternative 2.2 POS apre CardApp Postcondizioni - Cliente ha la lista delle carte/wallet che può utilizzare per il pagamento Cammini MAIN PATH: PATH_1:

55 3.1.4 Seleziona carta UC15 Portata Applicativo per smartphone Parte interessata Utente Telecom Interessi Scegliere la carta per effettuare il pagamento Attori - Primario: Utente - SuD: CARD-APP - Supporto: : Nessuno Precondizioni - Visualizza carte (UC14) Flusso base 1.1 Cliente sceglie la carta/wallet con cui intende effettuare il pagamento 2.1 CardApp visualizza il form di inserimento PIN 55

56 3.1 Cliente inserisce il PIN 4.1 CardApp invia i dati all applet (UC12,UC9) Postcondizioni - CardApp attende l esito del pagamento Cammini MAIN PATH:

57 2. Activity Diagram associato al processo di pagamento Figura VIII:activity diagram associato al processo 2(gestione portafogli elettronico) 57

58 3. Sequence Diagram Ad ogni caso d uso abbiamo associato un Squence Diagram che illustra la sequenzialità delle azioni svolte all interno del relativo Use Case. Qui sono inseriti soltanto i Sequence Diagram riguardanti il processo di pagamento e gestione del portafoglio elettronico. Un ulteriore obiettivo dei SD è quello di illustrare le relazioni che intercorrono, in termini di messaggi, tra Attori, Oggetti ed Entità di sistema Remote Payment UC9 con SD9 3-1 Sequence Diagram SD9 58

59 3.3.2 Proximity payment UC12 con SD Sequence Diagram SD12 59

60 3.3.3 Visualizza carte UC14 con SD Sequence Diagram SD Seleziona carta UC15 con SD Sequence Diagram SD15 60

61 4. Progettazione di dettaglio e sviluppo In questo capitolo andremo a progettare e sviluppare un applicazione Android che mi permetta di effettuare la spesa da casa o al supermercato, mediante tapping per la scelta dei prodotti, su un volantino nel primo caso, o sullo scaffale nel secondo, e in seguito per il pagamento, utilizzando, in tutti i casi, la tecnologia NFC. Si analizzarano i requisiti del cliente, nel nostro caso Telecom, gli use case dell applicazione supermercato (SUPER-APP), che andranno a completare gli use case visti nel capitolo precedente, inoltre realizzeremo gli activity diagram, i sequence diagram ed infine il class diagram con cui concluderemo la fase di progettazione. 1. Requisiti spesa da casa Descriviamo ora i requisiti per effettuare la spesa da casa. Super-app descrive l applicazione principale con cui l utente dovrà interagire per poter effettuare la spesa da casa. L app fa visualizzare una lista della spesa, inizialmente vuota, dove l utente potrà inserire i prodotti che vuole acquistare. L utente sceglie un prodotto da voler aggiungere/visionare sullo smartphone e decide quale azione compiere, poi sceglie un altro prodotto iterando il processo. Conclusa questa prima fase può decidere se effettuare il pagamento o annullare l operazione. Requisiti funzionali: 1. L utente apre l applicazione 2. L app presenta un carrello virtuale sempre aggiornato con prodotti e TOT 61

62 3. L utente può visualizzare le informazioni e le azioni associate ad un prodotto avvicinando lo smartphone al TAG 4. L utente può aggiungere/rimuovere/annullare un prodotto leggendo il TAG NFC ad esso associato 4.1. Nel caso di rimozione, l utente deve confermare l operazione 5. L app dovrà aggiornare la lista, aggiornare il totale della spesa e farla visualizzare 6. Quando l utente avrà terminato la selezione dei prodotti, potrà decidere se effettuare il pagamento o annullare l intera operazione 6.1. Nel primo caso, l app avvia il pagamento in remoto del 20% del totale e salva la lista della spesa (per utilizzarla al momento del pagamento del restante 80%) e il TOT, e attende l esito Nel secondo caso, l app cancella la lista e si chiude. 7. Riceve l esito della transazione del 20% 7.1. In caso di ACK visualizza l orario di consegna 7.2. In caso di NACK annulla l operazione, cancella la lista e si chiude 8. L utente esce dall app 9. Quando l utente deve effettuare il pagamento del restante 80%, riavvia SUPER- APP e avvicina lo smartphone al POS, e si mette in attesa; il POS avvia CARD- APP e si effettua il pagamento come descritto nel paragrafo relativo 10. Terminato il pagamento, l APPLET dovrà inviare un ack/nack a SUPER-APP che è ancora in attesa Se riceve l ACK, genera uno scontrino digitale con tutti i prodotti e il totale pagato che manterrà salvato per un TOT di tempo Se riceve un NACK salva la lista, si chiude e si torna al passo L utente esce dall app. 62

63 Figura 10 Crea carrello virtuale da casa 63

64 Figura 11 Processo di pagamento da casa 64

65 2. Requisiti spesa al supermercato L app fa visualizzare una lista della spesa, inizialmente vuota, dove l utente potrà inserire i prodotti che vuole acquistare. L utente sceglie un prodotto da voler aggiungere/visionare sullo smartphone e decide se aggiungerlo o meno alla lista, poi sceglie un altro prodotto iterando il processo. Conclusa questa prima fase può decidere se effettuare il pagamento o annullare l operazione. Requisiti funzionali: 1. L utente apre l applicazione 2. L app presenta un carrello virtuale sempre aggiornato con prodotti e TOT 3. L utente può visualizzare le informazioni e le azioni associate ad un prodotto avvicinando lo smartphone al TAG 4. L utente può aggiungere/rimuovere/annullare un prodotto leggendo il TAG NFC ad esso associato 4.1. Nel caso di rimozione, l utente deve confermare l operazione 5. L app dovrà aggiornare la lista, aggiornare il totale della spesa e farla visualizzare 6. Quando l utente avrà terminato la selezione dei prodotti, potrà decidere se effettuare il pagamento o annullare l intera operazione 6.1. Se decide di effettuare il pagamento avvicina lo smartphone al POS, e si mette in attesa; il POS avvia CARD-APP e si effettua il pagamento come descritto nel paragrafo relativo 6.2. Nel secondo caso, l app cancella la lista e si chiude. 7. Terminato il pagamento, l APPLET dovrà inviare un ack/nack a SUPER-APP che è ancora in attesa 7.1. Se riceve l ACK, genera uno scontrino digitale con tutti i prodotti e il totale pagato che manterrà salvato per un TOT di tempo; 7.2. Se riceve un NACK salva la lista, si chiude e si torna al passo 6 8. L utente chiude l app 65

66 Figura 12 Crea carrello virtuale dal supermercato 66

67 Figura 13 Processo di pagamento dal supermercato 67

68 3. Casi d uso (UCx) Paretendo dal flow chart visto nel capitolo precedente, andremo a scomporlo fino ad individuare i singoli casi d uso delle nostre applicazioni Avvio con Tapping UC1 Portata Applicativo per smartphone Parte interessata Utente Telecom Interessi Avviare l applicazione per avere la possibilità di effettuare la spesa da casa o dal supermercato e poter quindi iniziare la selezione dei prodotti. Attori - Primario: Utente - SuD: SUPER-APP - Fuori scena: Telecom Precondizioni - L applicazione è chiusa Flusso base 1.1 Cliente esegue un tapping su un prodotto 2.1 SuperApp si avvia 3.1 SuperApp esegue il controllo utente (UC3) 4.1 SuperApp controlla se il cliente ha letto un TAG 68

69 4.1.1 se SI (UC4) se NO (UC6) Postcondizioni - SuperApp è avviata - Il cliente è in grado di selezionare e scegliere prodotti da acquistare Cammini MAIN PATH: PATH_1:

70 4.3.2 Avvio da menu UC2 Portata Applicativo per smartphone Parte interessata Utente Telecom Interessi Avviare l applicazione per avere la possibilità di effettuare la spesa da casa o al supermercato e poter iniziare la selezione dei prodotti. Attori - Primario: Utente - SuD: SUPER-APP - Fuori scena: Telecom Precondizioni - L applicazione è chiusa Flusso base 1.1 Cliente avvia SuperApp dal menù dello smartphone 2.1 SuperApp si avvia 3.1 SuperApp esegue il controllo utente (UC3) 4.1 SuperApp controlla se il cliente ha letto un TAG se SI SuperApp richiede la decodifica TAG (UC4) se NO SuperApp fa visualizzare il menù principale Postcondizioni - SuperApp è avviata 70

71 - Il cliente è in grado di selezionare e scegliere prodotti da acquistare Cammini MAIN PATH: PATH_1: Controllo utente UC3 Portata Applicativo per smartphone Parte interessata Utente Telecom 71

72 Interessi Controllare se l utente è già registrato sul sistema, in caso negativo, permettere all utente di registrarsi. Attori - Primario: Utente - SuD: SUPER-APP - Supporto: ServerDB del supermercato contenente tutti gli utenti registrati - Fuori scena: Telecom Precondizioni - SuperApp deve essere aperta, UC1 oppure UC2 Flusso base 1.1 SuperApp verifica se ha i dati utente in locale i dati esistono, si passa a UC1 o UC i dati non esistono, SuperApp richiede i dati al cliente 2.1 Il cliente inserisce i dati e li invia a SuperApp 3.1 SuperApp memorizza i dati in locale 4.1 SuperApp invia i dati e la richiesta di prima registrazione al SuperDB 5.1 SuperDB riceve la richiesta 6.1 SuperDB controlla se il cliente è già registrato il cliente non è registrato SuperDB inserisce i dati nel DB remoto il cliente è registrato 7.1 SuperDB invia l esito a SuperApp 8.1 SuperApp riceve l esito e torna a UC1 o UC2 Postcondizioni 72

73 - Il cliente è registrato Cammini MAIN PATH: PATH_1: PATH_2: Decodifica TAG UC4 Portata Applicativo per smartphone Parte interessata 73

74 Utente Telecom Interessi Permette di eseguire più operazioni su un prodotto selezionato Attori - Primario: Utente - SuD: SUPER-APP - Supporto: Tapping su TAG NFC associato al prodotto di interesse e connessione al SuperDB del supermercato - Fuori scena: Telecom Precondizioni - Avvio con tapping (UC1) oppure da una qualsiasi successiva scansione di un TAG Flusso base 1.1 SuperApp invia la richiesa di decodifica TAG al SuperDB 2.1 SuperDB esegue la decodifica 3.1 SuperDB controlla se il TAG esiste se NO SuperDB genera ed invia a SuperApp un messaggio di errore se SI SuperDB recupera ed invia info a SuperApp 4.1 SuperApp riceve esito SuperApp fa visualizzare un errore e poi fa visualizzare il menù principale SuperApp riceve e memorizza le info Postcondizioni - Il cliente visualizza le informazioni del prodotto che ha scansionato - A questo punto il cliente si trova nella posizione di decidere se acquistarlo o no Cammini MAIN PATH: PATH_1:

75 4.3.5 Aggiungi o annulla UC5 Portata Applicativo per smartphone Parte interessata Utente Telecom Interessi Aggiungere, annullare o visualizzare informazioni sul prodotto selezionato Attori - Primario: Utente - SuD: SUPER-APP - Fuori scena: : Telecom Precondizioni 75

76 - Decodifica TAG (UC4) Flusso base 1.1 SuperApp fa visualizzare le info del prodotto selezionato dal cliente 2.1 Il cliente sceglie un azione: il cliente sceglie l azione: visualizza info aggiuntive e si passa a UC il cliente sceglie l azione:aggiungi 3.1 SuperApp aggiunge il prodotto al carrello 4.1 SuperApp aggiorna il totale corrente della spesa 5.1 SuperApp fa visualizzare il menù principale (UC6) Flusso alternativo Il cliente sceglie l azione: ANNULLA 3.2 SuperApp fa visualizzare il menù principale Postcondizioni - SuperApp fa visualizzare il menù principale (carrello) - Il cliente può eseguire una delle seguenti operazioni UC7, UC8, UC10, UC11, UC4. Cammini MAIN PATH: PATH_1: PATH_2:

77 4.3.6 Visualizza menu principale UC6 Portata Applicativo per smartphone Parte interessata Utente Telecom Interessi Visualizzare i prodotti aggiunti al carrello virtuale con le diverse operazioni che si possono effettuare. 77

78 Attori - Primario: Utente - SuD: SUPER-APP Precondizioni - Si arriva a UC6 da uno dei seguenti Use Case: CONTROLLO UTENTE UC3 DECODIFICA TAG UC4 AGGIUNGI/ANNULLA UC5 TERMINA E PAGA UC7 ESCI UC8 VISUALIZZA INFO UC10 RIMUOVI UC11 Flusso base 1.1 SuperApp fa visualizzare il menù delle operazioni 2.1 SuperApp esegue un check per verificare se il carrello è vuoto: carrello vuoto: SuperApp fa visualizzare il carrello vuoto carrello non vuoto: SuperApp fa visualizzare il carrello con i prodotti scelti dall utente più TOT corrente 3.1 Il cliente seleziona un operazione (può effettuare una delle seguenti operazioni UC4,UC7,UC8,UC10,UC11) Postcondizione - Il cliente può eseguire una delle seguenti operazioni UC7, UC8, UC10, UC11, UC4. Cammini MAIN PATH: PATH_1:

79 79

80 4.3.7 Termina e paga UC7 Portata Applicativo per smartphone Parte interessata Utente Telecom Interessi Effettuare il pagamento Attori - Primario: Utente - SuD: SUPER-APP - Supporto: Connessione remota Precondizioni - Il cliente visualizza il menù principale UC6 Flusso base 1.1 Il cliente seleziona l operazione TERMINA E PAGA 2.1 SuperApp chiede se il cliente è al supermercato 3.1 Il cliente risponde : SI 4.1 SuperApp verifica la risposta 5.1 SuperApp fa visualizzare il riassunto spesa e il TOT 6.1 Il cliente seleziona l opzione: annulla: si torna a UC continua: SuperApp memorizza la lista della spesa nel DB locale 7.1 SuperApp richiede PROXIMITY PAY UC12 Cammini Alternativi 3.2 il cliente risponde: NO 4.2 SuperApp calcola il 20% del TOT 5.2 SuperApp fa visualizzare il riassuntivo spesa, TOT e 20% 6.2 Il cliente seleziona l opzione: 80

81 6.2.1 annulla: si torna a UC continua: SuperApp memorizza la lista della spesa nel DB locale 7.2 SuperApp richiede REMOTE PAY UC9 8.2 SuperApp richiede PROXIMITY PAY UC12 Postcondizioni - Il cliente ha terminato la scelta dei prodotti e si appresta al pagamento Cammini MAIN PATH: PATH_1: PATH_2: PATH_3:

82 82

83 4.3.8 Esci dall applicazione UC8 Portata Applicativo per smartphone Parte interessata Utente Telecom Interessi Annullare l intera operazione Attori - Primario: Utente - SuD: SUPER-APP - Supporto: Nessuno Precondizioni - Il cliente deve visualizzare il menu principale di SuperApp(carrello) Flusso base 1.1 Il cliente seleziona l operazione ESCI 2.1 SuperApp chiede conferma al cliente 3.1 Il cliente risponde 4.1 Risposta positiva? NO si torna a UC SI SuperApp svuota il carrello e si chiude Postcondizioni - SuperApp si chiude Cammini MAIN PATH: PATH_1:

84 4.3.9 Visualizza info prodotto UC10_1 Portata Applicativo per smartphone Parte interessata Utente Telecom Interessi Visualizzare le informazioni aggiuntive del prodotto selezionato Attori - Primario: Utente 84

85 - SuD: SUPER-APP - Supporto: Connessione al SuperDB del supermercato Precondizioni - Aggiungi/Annulla (UC5) Flusso base 1.1 Cliente seleziona l opzione Visualizza informazioni dalla schermata Aggiungi/Annulla 2.1 SuperApp invia a schermo le informazioni aggiuntive del prodotto 3.1 Cliente chiude la finestra di informazioni aggiuntive 4.1 SuperApp torna alla schermata Aggiugi/Annulla Postcondizioni - Cliente ha visualizzato le informazioni aggiuntive del prodotto selezionato - Cliente può scegliere un altro prodotto e/o un altra azione sul prodotto Cammini MAIN PATH:

86 Visualizza info prodotto UC10_2 Portata Applicativo per smartphone Parte interessata Utente Telecom Interessi Visualizzare le informazioni aggiuntive del prodotto selezionato Attori 86

87 - Primario: Utente - SuD: SUPER-APP - Supporto: Connessione al SuperDB del supermercato Precondizioni - Visualizza Menù Principale (UC6) Flusso base 1.1 Cliente seleziona l opzione Visualizza informazioni dalla schermata Menù Principale 2.1 SuperApp invia a schermo le informazioni aggiuntive del prodotto 3.1 Cliente chiude la finestra di informazioni aggiuntive 4.1 SuperApp torna alla schermata Menù Principale Postcondizioni - Cliente ha visualizzato le informazioni aggiuntive del prodotto selezionato - Cliente può scegliere un altro prodotto e/o un altra azione sul prodotto Cammini MAIN PATH: Rimuovi UC11 Portata Applicativo per smartphone Parte interessata Utente Telecom Interessi Rimuovere un prodotto dalla lista della spesa Attori - Primario: Utente - SuD: SUPER-APP 87

88 - Supporto: Nessuno Precondizioni - Visualizza Menù Principale (UC6) Flusso base 1.1 Cliente seleziona l opzione Rimuovi dalla schermata del Menù Principale 2.1 SuperApp apre una finestra di Conferma rimozione 3.1 Cliente seleziona l opzione SI : SuperApp rimuove il prodotto dalla lista NO : SuperApp torna al menù principale (UC6) 4.1 SuperApp aggiorna il totale della spesa 5.1 SuperApp torna al Menù Principale Postcondizioni - Cliente ha la lista della spesa e il totale spesa aggiornati Cammini MAIN PATH: PATH_1:

89 Invio ordine al server UC13 Portata Applicativo per smartphone Parte interessata Utente Telecom Interessi Inviare l ordine spesa al server del supermercato Attori - Primario: Utente 89

90 - SuD: SUPER-APP - Supporto: Connessione al server del supermercato Precondizioni - Remote pay (UC9) Flusso base 1.1 SuperApp riceve la conferma di avvenuto pagamento del 20% in remote pay 2.1 SuperApp invia la richiesta d ordine al SuperDB del supermercato 3.1 SuperDB del supermercato verifica l ordine Esito positivo: SuperDB invia un messaggio di Ricezione ordine avvenuta con successo Esito negativo: SuperDB invia un messaggio di Ricezione ordine fallita 4.1 Operazione successiva all esito SuperDB invia l ordine al supermercato che provvede a preparare la spesa ed invia il fattorino a casa del cliente per la consegna SuperApp torna al SuperDB notifica la partenza dell ordine 6.1 SuperApp visualizza la notifica al cliente Postcondizioni - Cliente attende l arrivo del fattorino Cammini MAIN PATH: PATH_1:

91 91

92 Effettua pagamento remoto UC16 Portata Applicativo per smartphone Parte interessata Utente Telecom Interessi Effettuare il pagamento tramite internet Attori - Primario: Utente - SuD: SUPER-APP - Supporto: Connessione remota Precondizioni - Richiesta REMOTE PAY (UC9) Flusso base 1.1 CardApp invia i dati recuperati dalla SIM a SuperApp 2.1 SuperApp visualizza i dati e chiede conferma del pagamento 3.1 Il cliente risponde NON CONFERMA: si torna a UC CONFERMA: SuperApp memorizza il 20% pagato associato ad un ID spesa 4.1 SuperApp fa visualizzare al cliente un messaggio di pagamento 20% effettuato Postcondizioni - Ora è possibile inviare l ordine al superdb UC13 Cammini 92

93 MAIN PATH: PATH_1:

94 Verifica cliente UC17 Portata Applicativo per smartphone Parte interessata Utente Telecom Interessi Associare il cliente alla sua spesa e verificare che il pagamento del 20% è stato effettuato Attori - Primario: Utente - SuD: SUPER-APP - Supporto: Il fattorino deve avere la connessione al SuperDB, fattorino e cliente devono poter comunicare mediante NFC Precondizioni - Deve essere stato inviato l ordine al superdb (UC13) - Il fattorino è arrivato a casa del cliente Flusso base 1.1 Il cliente avvicina il suo smartphone al device del fattorino 2.1 Il device del fattorino esegue un check tra la spesa salvata nel DB locale con la spesa salvata nel DB remoto 3.1 Il device del fattorino verifica l avvenuto pagamento del 20% Postcondizioni - Il cliente può pagare il restante 80% del TOT tramite PROXIMITY PAY UC12 Cammini MAIN PATH:

95 95

96 4. Use Case Diagram LEGENDA UC1: Avvio con Tapping UC3: Controllo utente UC5: Aggiungi o annulla UC7: Termina e paga UC9: Remote Payment UC11: Rimuovi UC13: Invio ordine al server UC15: Seleziona carta UC2: Avvio da menu UC4: Decodifica TAG UC6: Visualizza menu principale UC8: Esci dall applicazione UC10: Visualizza info prodotto UC12: Proximity payment UC14: Visualizza carte UC16: Effettua pagamento remoto UC17: Verifica cliente 96

97 5. Activity Diagram associati all applicazione supermercato Figura 14 Activity diagram associato al processo d'acquisto 97

98 6. Class Diagram Nel seguente paragrafo andremo a definire tutte le classi che abbiamo individuate in fase di progettazione, con I rispettivi metodi, associazioni e gerarchie. Le classi individuate sono: Gestore Super App: è il gestore dell intera app supermercato, ed ha il compito di loggare il cliente, se è già registrato o provvedere alla registrazione, gestire il carrello e i prodotti Cliente: Il cliente deve essere registrato in locale, e presso il supermercato Carrello: è un insieme di prodotti Prodotto: è un element del carrello con propri attributi (marca, nome, peso, prezzo, ecc.) Tag: è l identificativo del prodotto Scontrino: viene rilasciato alla conclusione del pagamento Gestore ordine: gestisce gli ordini del supermercato Pagamento: si divide in due tipi: 1) Remoto: per pagare l acconto del 20% da casa 2) Proximity: per pagare il restante 80% all arrivo del fattorino o l intera somma se si è al supermercato Gestore Carte: gestisce le carte presenti sulla sim Carte: possono essere di due tipi: 1) Carte di credito: con credenziali memorizzate nel SE della SIM 2) Wallet: con un credito che può essere incrementato o decrementato Sim: rappresenta la sim vera e propria, ed è quell ache accede al SE per prelevare le credenziali delle Carte ed inviarle al POS per il pagamento Pos: è un emulazione del POS 98

99 99

100 7. Sequence Diagram associati all applicazione supermercato Avvio con Tapping UC1 con SD1, Avvio da menu UC2 con SD2, Controllo utente UC3 con SD3 Dato che questi 3 Use Case sono fortemente correlati tra loro, i 3 relativi Seqence Diagram sono stati incorporati in un unico Sequence Diagram 6-1 Sequence Diagram SD1-SD2-SD3 100

101 Decodifica TAG UC4 con SD4 6-2 Sequence Diagram SD4 Aggiungi o annulla UC5 con SD5 6-3 Sequence Diagram SD5 101

102 Visualizza menu principale UC6 con SD6 6-4 Sequence Diagram SD6 Termina e paga UC7 con SD7 6-5 Sequence Diagram SD7 102

103 Esci dall applicazione UC8 con SD8 6-6 Sequence Diagram SD8 Visualizza info prodotto UC10_1 con SD10_1 6-7 Sequence Diagram SD10_1 103

104 Visualizza info prodotto UC10_2 con SD10_2 6-9 Sequence Diagram SD10_2 104

105 Rimuovi UC11 con SD Sequence Diagram SD11 105

106 Invio ordine al server UC13 con SD Sequence Diagram SD13 Effettua pagamento remoto UC16 con SD Sequence Diagram SD16 106

107 Verifica cliente UC17 con SD Sequence Diagram SD17 8. Sviluppo dell applicazione Nel seguente paragrafo entreremo nella fase di sviluppo vero e proprio, nella figura sottostante sono rappresentati i componenti che abbiamo sviluppato, per ogni componente daremo una breve spiegazione e inseriremo alcune parti di codice utile alla comprensione del funzionamento degli stessi. 107

108 Figura 15 Sviluppo dei componenti Prodotti Come detto nei precedenti capitoli, si sono ipotizzati due scenari d utilizzo: 1) Spesa da casa 2) Spesa al supermercato Nel primo caso i tag associati ad ogni prodotto, verranno disposti su di un volantino, nel secondo caso saranno disposti sullo scaffale del supermercato. In entrambi i casi, il tag conterrà la codifica del prodotto, grazie alla quale si interrogherà il backend del supermercato per ottenere delle informazioni aggiuntive sul prodotto che verrano visualizzate sullo schermo dello smartphone e salvate in un DB locale SQLite per una eventuale successiva visualizzazione. NFCManager: Con questa classe gestiamo la lettura dei tag NFC, prelevandone le informazioni che mi serviranno per le richieste al di lettura tag NFC public class NFCManager { NfcAdapter adapter; PendingIntent mnfcpendingintent; 108

109 //IntentFilter[] mwritetagfilters; IntentFilter[] mndefexchangefilters; public NFCManager(Context ctx) { this.adapter = NfcAdapter.getDefaultAdapter(ctx); this.mnfcpendingintent = PendingIntent.getActivity(ctx, 0, new Intent(ctx, getclass()).addflags(intent.flag_activity_single_top),0); ; this.mndefexchangefilters = new IntentFilter [] { public void disabilitapush(activity a) { this.adapter.disableforegrounddispatch(a); public void abilitadispatch (Activity a) { adapter.enableforegrounddispatch(a, this.mnfcpendingintent, this.mndefexchangefilters, null); public IntentFilter ndefdetected() { IntentFilter ndefdetected = new IntentFilter (NfcAdapter.ACTION_NDEF_DISCOVERED); try { ndefdetected.adddatatype("text/plain"); catch (MalformedMimeTypeException e) { mndefexchangefilters = new IntentFilter[] {ndefdetected; return ndefdetected; public boolean checkndefdetection (Activity a) { return (NfcAdapter.ACTION_NDEF_DISCOVERED.equals(a.getIntent().getA ction())); 109

110 public NdefMessage[] getndefmessages(intent intent) { // Parse the intent NdefMessage[] msgs = null; String action = intent.getaction(); if (NfcAdapter.ACTION_TAG_DISCOVERED.equals(action) NfcAdapter.ACTION_NDEF_DISCOVERED.equals(action) NfcAdapter.ACTION_TECH_DISCOVERED.equals(action)) { Parcelable[] rawmsgs = intent.getparcelablearrayextra(nfcadapter.extra_ndef_message S); { if (rawmsgs!= null) { msgs = new NdefMessage[rawMsgs.length]; for (int i = 0; i < rawmsgs.length; i++) else { msgs[i] = (NdefMessage) rawmsgs[i]; // Unknown tag type byte[] empty = new byte[] {; NdefRecord record = new NdefRecord(NdefRecord.TNF_UNKNOWN, empty, empty, empty); NdefRecord[] { else { NdefMessage msg = new NdefMessage(new ); record msgs = new NdefMessage[] { ; msg Log.d("", "Unknown intent."); // "" //finish(); return msgs; 110

111 public class NDEFMessageManager { NdefMessage msg; public NDEFMessageManager(NdefMessage m) { this.msg=m; public String gettype(){ return new String (msg.getrecords()[0].gettype()); public String getbody() { return new String (msg.getrecords()[0].getpayload()); ChekTag: Data una codifica, verifica che il prodotto sia presente nel DB del di interrogazione al DBManager public static ResultSet querychecktag(string codifica){ DBManager dbm=new DBManager(); ResultSet rs=null; try { Statement state=conn.createstatement(); rs=state.executequery("select * FROM prodotti WHERE tag='"+codifica+"'"); catch (SQLException e) { e.printstacktrace(); return rs; 111

112 @WebServlet("/CheckTag") public class CheckTag extends BackendServlet { private static final long serialversionuid = 1L; public CheckTag() { super(); protected void doget(httpservletrequest request, HttpServletResponse response) throws ServletException, IOException { String tag=request.getparameter("codifica"); JSONObject codifica=null; try { codifica=new JSONObject(tag); System.out.println(codifica.toString()); catch (JSONException e) { e.printstacktrace(); PrintWriter out = response.getwriter(); out.println(gettag(codifica)); protected void dopost(httpservletrequest request, HttpServletResponse response) throws ServletException, IOException { public JSONObject gettag(jsonobject tag){ //{"codifica":"tag1" Response resp=new Response(false,0,null); String cod=""; try{ 112

113 cod=tag.getstring("codifica"); ResultSet result=dbmanager.querychecktag(cod); String codif=""; while(result.next()){ codif=result.getstring("tag"); if(cod.equalsignorecase(codif)){ resp.setvalorebool(true); catch(exception e){e.printstacktrace(); return (resp.tojsonbool()); Decodifica TAG: Dato un tag codificato, restituisce la decodifica del di interrogazione al DBManager public static ResultSet querydecodificatag(string codifica){ DBManager dbm=new DBManager(); ResultSet rs=null; try { Statement state=conn.createstatement(); rs=state.executequery("select nome FROM prodotti WHERE tag='"+codifica+"'"); catch (SQLException e) { e.printstacktrace(); return public class DecodificaTag extends BackendServlet { 113

114 private static final long serialversionuid = 1L; public DecodificaTag() { super(); // TODO Auto-generated constructor stub protected void doget(httpservletrequest request, HttpServletResponse response) throws ServletException, IOException { String input=request.getparameter("codifica"); JSONObject tag=null; try { tag=new JSONObject(input); System.out.println(tag.toString()); catch (JSONException e) { // TODO Auto-generated catch block e.printstacktrace(); PrintWriter out = response.getwriter(); out.println(gettag(tag)); protected void dopost(httpservletrequest request, HttpServletResponse response) throws ServletException, IOException { // TODO Auto-generated method stub public JSONObject gettag(jsonobject tag){ JSONObject t=null; //{"codifica":"tag1" String cod=""; 114

115 try{ cod=tag.getstring("codifica"); ResultSet result=dbmanager.querychecktag(cod); String codif=""; while(result.next()){ codif=result.getstring("tag"); t=new JSONObject(); t.put("codifica", codif); catch(exception e){e.printstacktrace(); return t; Visualizza info prodotto: Data la codifica di un prodotto, restituisce tutte le informazioni relative a quel di interrogazione al DBManager public static ResultSet queryvisualizzainfoprodotto(string codifica){ DBManager dbm=new DBManager(); ResultSet rs=null; try { Statement state=conn.createstatement(); rs=state.executequery("select * FROM prodotti WHERE tag='"+codifica+"'"); catch (SQLException e) { e.printstacktrace(); return rs; 115

116 @WebServlet("/VisualizzaInfo") public class VisualizzaInfo extends BackendServlet { private static final long serialversionuid = 1L; //String nprod=tag.getcodifica(); public VisualizzaInfo() { super(); // TODO Auto-generated constructor stub protected void doget(httpservletrequest request, HttpServletResponse response) throws ServletException, IOException { String tag=request.getparameter("codifica"); JSONObject codifica=null; try { codifica=new JSONObject(tag); System.out.println(codifica.toString()); catch (JSONException e) { e.printstacktrace(); PrintWriter out = response.getwriter(); out.println(getinfo(codifica)); protected void dopost(httpservletrequest request, HttpServletResponse response) throws ServletException, IOException { // TODO Auto-generated method stub 116

117 public JSONObject getinfo(jsonobject tag){ //{"codifica":"tag1" JSONObject prod=null; String nome=""; String marca=""; String t=null; double prezzo=0; int id=0; int peso=0; String infoplus=""; String urlimmagine=null; String cod=""; try{ cod=tag.getstring("codifica"); System.out.println("tag: "+ cod); ResultSet result=dbmanager.queryvisualizzainfoprodotto(cod); while(result.next()){ nome=result.getstring("nome"); marca=result.getstring("marca"); prezzo=result.getdouble("prezzo"); id=result.getint("idprodotto"); infoplus=result.getstring("infoaggiuntive"); peso=result.getint("peso"); urlimmagine="/webcontent/immagini/"+result.getstring("i mmagine"); prod=new JSONObject(); prod.put("nome", nome); prod.put("marca", marca); prod.put("prezzo", prezzo); prod.put("id", id); prod.put("tag", t); prod.put("infoaggiuntive", infoplus); prod.put("immagine", urlimmagine); 117

118 catch(exception e){e.printstacktrace(); return prod; Invia Ordine: Dato un carrello, si invia l ordine al back end del supermercato, inserendo i vari campi in tutte le tabelle che associano i singoli prodotti all intero di interrogazione al DBManager public static ResultSet queryidcliente(string ){ DBManager dbm=new DBManager(); ResultSet rs=null; try { Statement state=conn.createstatement(); rs=state.executequery("select idcliente FROM cliente WHERE ='"+ +"'"); catch (SQLException e) { e.printstacktrace(); return rs; public static int queryinserisciordine(string data,int nordine,string statoordine){ DBManager dbm=new DBManager(); int rs=0; try { Statement state=conn.createstatement(); rs=state.executeupdate("insert INTO ordine (data,numeroordine,statoordine) VALUES ('"+data+"',"+nordine+",'"+statoordine+"')"); 118

119 catch (SQLException e) { e.printstacktrace(); return rs; public static ResultSet queryleggiidordine(int nordine){ DBManager dbm=new DBManager(); ResultSet rs=null; try { Statement state=conn.createstatement(); rs=state.executequery("select idordine FROM ordine WHERE numeroordine="+nordine); catch (SQLException e) { e.printstacktrace(); return rs; public static int queryinseriscirelazioneo_c(int idcliente,int idordine){ DBManager dbm=new DBManager(); int rs=0; try { Statement state=conn.createstatement(); rs=state.executeupdate("insert INTO cliente_has_ordine (cliente_idcliente,ordine_idordine) VALUES ("+idcliente+","+idordine+")"); catch (SQLException e) { e.printstacktrace(); return rs; 119

120 public static int queryinseriscirelazionep_o(int idprodotto,int idordine){ DBManager dbm=new DBManager(); int rs=0; try { Statement state=conn.createstatement(); rs=state.executeupdate("insert INTO prodotti_has_ordine (prodotti_idprodotto,ordine_idordine) VALUES ("+idprodotto+","+idordine+")"); catch (SQLException e) { e.printstacktrace(); return public class InviaOrdine extends BackendServlet { private static final long serialversionuid = 1L; private static String stato=""; private static String preordine=new String("PreOrdine"); private static String acconto=new String("Acconto"); private static String pagato=new String("Pagato"); protected void doget(httpservletrequest request, HttpServletResponse response) throws ServletException, IOException { PrintWriter out = response.getwriter(); String =request.getparameter(" "); String prodotti = request.getparameter("prodotti"); JSONArray jar=null; try { 120

121 jar=new JSONArray(prodotti); catch (Exception e) { // TODO Auto-generated catch block e.printstacktrace(); idcliente( ,jar,out); protected void dopost(httpservletrequest request, HttpServletResponse response) throws ServletException, IOException { // TODO Auto-generated method stub public void idcliente(string ,jsonarray codifica,printwriter out){ try{ ResultSet resul=dbmanager.queryidcliente( ); java.sql.resultsetmetadata rsmd=resul.getmetadata(); int column=rsmd.getcolumncount(); String []id=new String[column]; while(resul.next()){ for(int i=1;i<column+1;i++){ id[i-1]=resul.getstring(i); int idcliente=integer.parseint(id[0]); System.out.println("Id Cliente: "+idcliente); 121

122 creaordine(idcliente,codifica,out); catch(exception e){e.printstacktrace(); public void creaordine(int idcliente,jsonarray codifica,printwriter out){ Calendar cal = new GregorianCalendar(); int giorno = cal.get(calendar.day_of_month); int mese = cal.get(calendar.month); int anno = cal.get(calendar.year); String data=new String(giorno + "-" + (mese + 1) + "-" + anno); Random rdn=new Random(); int nordine=rdn.nextint(50); stato=this.getpreordine(); int resul=dbmanager.queryinserisciordine(data, nordine,stato); System.out.println("Ordine inserito: "+nordine); leggiidordine(idcliente,nordine,codifica,out); public void leggiidordine(int idcliente,int nordine,jsonarray codifica,printwriter out){ try{ ResultSet rs=dbmanager.queryleggiidordine(nordine); java.sql.resultsetmetadata rsmd=rs.getmetadata(); int column=rsmd.getcolumncount(); 122

123 String []id=new String[column]; while(rs.next()){ for(int i=1;i<column+1;i++){ id[i-1]=rs.getstring(i); int idord=integer.parseint(id[0]); System.out.println("Id Ordine: "+idord); creaordinecliente(idcliente,idord,codifica,out); catch(exception e){ public void creaordinecliente(int idcliente,int idordine,jsonarray codifica,printwriter out){ int resul=dbmanager.queryinseriscirelazioneo_c(idcliente, idordine); System.out.println("Ordine cliente creato"); sendordine(idordine,codifica); public void sendordine(int idordine,jsonarray codifica){ Response res=new Response(false,0,null); int[] idprod=new int[20]; try{ for(int i=0;i<codifica.length();i++){ 123

124 JSONObject obj=codifica.getjsonobject(i); "+idprod[i]); idprod[i]=obj.getint("idprodotto"); System.out.println("id int result=dbmanager.queryinseriscirelazionep_o(idprod[i], idordine); creato\n "+result); System.out.println("Ordine prodotto: prodotto if(result==0){ res.setvalorebool(true); //[{"prezzo":0.78,"tag":{"codifica":"mortadellasuprema","id prodotto":4,"marca":"fiorucci","nome":"mortadella Suprema",{"prezzo":1.29,"tag":{"codifica":"arrostofiorucci","idprodotto":5,"marca":"Fiorucci","nome":"Arrosto di Posso Apollì"] catch(exception e){e.printstacktrace(); public static String getstato() { return stato; public static void setstato(string stato) { InviaOrdine.stato = stato; public static String getpreordine() { return preordine; 124

125 public static void setpreordine(string preordine) { InviaOrdine.preOrdine = preordine; public static String getacconto() { return acconto; public static void setacconto(string acconto) { InviaOrdine.acconto = acconto; public static String getpagato() { return pagato; public static void setpagato(string pagato) { InviaOrdine.pagato = pagato; Pagamento remoto: Dato un numero d ordine, permette di effettuare il pagamento remote del 20% della spesa totale inviando le credenziali prelevate dalla SIM all applicazione di interrogazione al DBManager public static ResultSet querypagamento(int nordine){ DBManager dbm=new DBManager(); ResultSet rs=null; try { Statement state=conn.createstatement(); 125

126 rs=state.executequery("select FROM ordine WHERE numeroordine="+nordine); statoordine catch (SQLException e) { e.printstacktrace(); return rs; public static int querycambiastatoremoto(int nordine){ DBManager dbm=new DBManager(); int rs=0; try { Statement state=conn.createstatement(); rs=state.executeupdate("update ordine SET statoordine='"+inviaordine.getacconto()+"' WHERE numeroordine="+nordine); catch (SQLException e) { e.printstacktrace(); return public class PagamentoRemoto extends BackendServlet { private static final long serialversionuid = 1L; InviaOrdine ordine; public PagamentoRemoto() { super(); protected void doget(httpservletrequest request, HttpServletResponse response) throws ServletException, IOException { String ordine=request.getparameter("credenziali"); int nordine=integer.parseint(ordine); 126

127 PrintWriter out=response.getwriter(); out.print(getcarta(nordine)); protected void dopost(httpservletrequest request, HttpServletResponse response) throws ServletException, IOException { public JSONObject getcarta(int nordine){ Response resp=new Response(false,0,null); ResultSet resul=dbmanager.querypagamento(nordine); String statoordine=""; try { while(resul.next()){ statoordine=resul.getstring("statoordine"); catch (SQLException e) { e.printstacktrace(); if(statoordine.equalsignorecase("preordine")){ DBManager.queryCambiaStatoRemoto(nOrdine); resp.setvalorebool(true); return (resp.tojsonbool()); 127

128 9. ScreanShot Smart Shopping 128

129 129

130 Gestore carte: 130