facoltà di ingegneria corso di studi in ingegneria informatica
TRANSCRIPT
Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica
Tesi di laurea Progettazione e sviluppo di un applicazione 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
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android
Facoltà di Ingegneria
Corso di Studi in Ingegneria Informatica
Progettazione e sviluppo di un applicazione di Mobile Payment su disposititecnologia NFC
2010/2011
Ch.mo prof. Marcello Cinque
Ch.mo ing. Marco Oreste Migliori
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
1
Mobile Payment su dispositi vo
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
2
Ai miei genitori ed al mio ragazzo
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
3
Indice
Indice ..................................................................................................................................... 3
Introduzione ........................................................................................................................... 5
1. Tecniche di Mobile Payment ......................................................................................... 7
1. Mobile Payment .................................................................................................. 7
2. Tecnologie coinvolte ......................................................................................... 11
3. JavaCard ............................................................................................................ 22
2. Mobile Proximity Payment .......................................................................................... 42
1. Elementi coinvolti ............................................................................................. 42
2. APP e Applet ..................................................................................................... 44
3. Applet su SIM ................................................................................................... 44
4. APP1 Android ................................................................................................... 45
5. APP2 Android ................................................................................................... 46
6. Scenari d’uso e analisi dei requisiti ................................................................... 46
3. Analisi e progettazione di alto livello .......................................................................... 49
1. Casi d’uso associate al gesture delle carte ........................................................ 49
2. Activity Diagram associato al processo di pagamento...................................... 57
3. Sequence Diagram............................................................................................. 58
4. Progettazione di dettaglio e sviluppo .......................................................................... 61
1. Requisiti spesa da casa ...................................................................................... 61
2. Requisiti spesa al supermercato ........................................................................ 65
3. Casi d’uso (UCx) ............................................................................................... 68
4. Use Case Diagram ............................................................................................. 96
5. Activity Diagram associati all’applicazione supermercato ............................... 97
6. Class Diagram ................................................................................................... 98
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
4
7. Sequence Diagram associati all’applicazione supermercato ........................... 100
8. Sviluppo dell’applicazione .............................................................................. 107
9. ScreanShot ....................................................................................................... 128
10. Testing ............................................................................................................. 131
5. Conclusioni ................................................................................................................ 144
6 Bibliografia ................................................................................................................ 145
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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 14443 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.
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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.
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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.
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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).
2.1. 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
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
12
l'ISO/IEC 14443. 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 18092 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.
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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)
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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).
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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:
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
18
Tabella 8 Differenziazione TAG
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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.
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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:
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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.
2.8. PROTOCOLLO HCI
Il protocollo HCI è definito in ETSI TS 102 622 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).
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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.
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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).
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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.
3.3. 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).
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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).
3.4. 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
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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.
3.5. 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.
Oltre che alla CPU, le smart card a
� 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
possono conformarsi sono: ISO 7816
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.
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android
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
di alimentazione
riservate per usi futuri
tensione a massa
tensione di programmazione
per operazioni di I/O
Le card a microprocessore offrono sicurezza, autenticazione, e possibilità di gestione dei
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 7816-3 T=0, T=1, T=14.
Le carte con CPU supportano:
File management
Gestione delle chiavi
Regole di accesso ai dati
significative delle carte con CPU é la possibilità di gestire
applicazioni multiple e memorizzarle in file logici e directories.
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
27
Le card a microprocessore offrono sicurezza, autenticazione, e possibilità di gestione dei
aggiunta alla semplice memorizzazione dati. In genere le carte con CPU forniscono
Le carte con CPU hanno integrato un microprocessore per la gestione delle operazioni. Gli
di comunicazione asincrona a cui queste smart card
significative delle carte con CPU é la possibilità di gestire
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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.
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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 (www.gi-de.com), 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 (http://java.sun.com/products/javacard/ e www.javacardforum.org/) è
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.
3.7. Modello scambio di messaggi
La CPU comunica con gli altri elementi della smart card e con il mondo esterno mediante
pacchetti APDU.
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
30
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:
Figura 14 Modello scambio messaggi interni
Figura 15 Modello scambio messaggi con l'esterno
� CLA: Classe byte. Utilizzato per identificare un’applicazione
� INS: byte istruzioni.
� P1-P2: parametri d’ingresso
o Lc: indica il numero di byte del campo Data Field
o Le: indica il
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
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
contenere la lunghezza della parte dati dell’APDU.
4) Command APDU di tipo 4: inviano dati alla Java Ca
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:
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android
Comando APDU
Figura 16 Comando APDU
CLA: Classe byte. Utilizzato per identificare un’applicazione
INS: byte istruzioni. Questo byte indica il codice dell’istruzioni
P2: parametri d’ingresso
Lc: indica il numero di byte del campo Data Field
Le: indica il numero massimo di byte che possono occupare i dati di
Data Field: è il campo dove sono contenuti i dati veri e propri
Esistono 4 tipi di comandi APDU:
Command APDU di tipo 1: non inviano dati alla Java Card e non si aspettano dati
questo caso la parte dati è completamente mancante.
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
la lunghezza della risposta attesa.
mmand 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
contenere la lunghezza della parte dati dell’APDU.
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:
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
31
numero massimo di byte che possono occupare i dati di
Data Field: è il campo dove sono contenuti i dati veri e propri
Command APDU di tipo 1: non inviano dati alla Java Card e non si aspettano dati
questo caso la parte dati è completamente mancante.
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
mmand 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
rd 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
� DataField: contiene i
� 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) in
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 u
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 d
(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).
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android
Response APDU
Figura 17 Risposta APDU
DataField: contiene i dati effettivi di risposta
contengono il primo ed il secondo byte di stato dell’elaborazione
Il meccanismo che permette alla smart card di comunicare con l’esterno può essere
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:
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;
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;
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).
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
32
contengono il primo ed il secondo byte di stato dell’elaborazione
Il meccanismo che permette alla smart card di comunicare con l’esterno può essere
reader) riceve un comando formattato all’interno di un APDU, lo invia
Arrivato il comando tramite le porte di I/O, il JCRE(Java Card Runtime
terpreta l’header dell’APDU e riconosce se si tratta di un
comando per la JavaCard Applet corrente o di una selezione per una nuova
Se si tratta di un comando, l’APDU viene passato alla JavaCard Applet
na selezione il Framework procede alla
selezione della nuova JavaCard Applet e passa a quest’ultima, una volta
Una volta che la JavaCard Applet ha terminato le elaborazioni richieste,
ati 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
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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.
3.8. 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.
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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;
� 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
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
sola Java Card Applet cui corrisponde l’identificatore.
Figura
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
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
e/o firmware per elaborazioni dedicate, quali per esempio implementazioni di algoritmi di
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android
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
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
e/o firmware per elaborazioni dedicate, quali per esempio implementazioni di algoritmi di
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
35
Le Java Card Applet sono passive, nel senso che non iniziano mai una
comunicazione ma possono solo rispondere a richieste provenienti
Le Java Card Applet sono isolate di default una dall’altra, ma possono
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
AID ha come risultato una condivisione limitata con la
sola Java Card Applet cui corrisponde l’identificatore.
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
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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.
3.10. 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);
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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.
3.11. 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)
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
38
Figura 20 API JavaCard relationship
3.12. 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.
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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 2008.
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.
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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.
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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.
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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.
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android
Figura 7 Flow chart processo di pagamento
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
48
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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 4.
1. Casi d’uso associate al gesture delle carte
3.1.1 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
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: 1.1 – 2.1 – 3.1
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android
Termina&paga (UC7)
CardApp richiede le credenziali carta all’applet
credenziali carta dall’applet
CardApp inoltra i dati per il pagamento remoto a SUPER_APP e attende l’esito
Cliente ha pagato il 20% della spesa da remoto
Cliente attende la spesa a casa
3.1 – 4.1 – 5.1
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
50
CardApp inoltra i dati per il pagamento remoto a SUPER_APP e attende l’esito
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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
4.1.1 Esito positivo: l’applet invia le credenziali della carta al POS che effettua il
pagamento
4.1.2 Esito negativo: l’applet invia un messaggio d’errore a CardApp
5.1 Operazione successiva all’esito
5.1.1 POS effettua il pagamento
5.1.2 CardApp torna a Scegli Carta (1.1)
6.1 CardApp riceve una notifica di pagamento
6.1.1 Esito positivo: CardApp riceve una conferma di pagamento dal POS
6.1.2 Esito negativo: CardApp riceve un messaggio d’errore
7.1 CardApp inoltra l’esito a SuperApp
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
52
7.1.1 Esito positivo: SuperApp genera lo scontrino
7.1.2 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: 1.1 – 2.1 – 3.1 – 4.1 – 4.1.1 - 5.1 – 5.1.1 - 6.1 – 6.1.1 – 7.1 – 7.1.1 – 8.1 –
9.1 – 10.1 – 11.1
PATH_1: 1.1 – 2.1 – 3.1 – 4.1 – 4.1.2 - 5.1 – 5.1.2
PATH_2: 1.1 – 2.1 – 3.1 – 4.1 – 4.1.1 - 5.1 – 5.1.1 - 6.1 – 6.1.2 – 7.1 – 7.1.2
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
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android
Visualizza carte UC14
Applicativo per smartphone
carte disponibili per effettuare il pagamento
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
53
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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: 1.1 – 2.1 – 3.1 – 4.1 – 5.1
PATH_1: 1.1 – 2.2 – 3.1 – 4.1 – 5.1
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
2.1 CardApp visualizza il form di inserimento PIN
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android
Seleziona carta UC15
smartphone
Scegliere la carta per effettuare il pagamento
: Nessuno
Visualizza carte (UC14)
Cliente sceglie la carta/wallet con cui intende effettuare il pagamento
CardApp visualizza il form di inserimento PIN
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
55
effettuare il pagamento
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: 1.1 – 2.1 – 3.1
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android
Cliente inserisce il PIN
CardApp invia i dati all’applet (UC12,UC9)
CardApp attende l’esito del pagamento
3.1 – 4.1
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
56
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
57
2. Activity Diagram associato al processo di pagamento
Figura VIII:activity diagram associato al processo 2(gestione portafogli elettronico)
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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.
3.3.1 Remote Payment UC9 con SD9
3-1 Sequence Diagram SD9
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
59
3.3.2 Proximity payment UC12 con SD12
3-9 Sequence Diagram SD12
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
60
3.3.3 Visualizza carte UC14 con SD14
3-3 Sequence Diagram SD14
3.3.4 Seleziona carta UC15 con SD15
3-4 Sequence Diagram SD15
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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.
6.2. 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
10.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.
10.2. Se riceve un NACK salva la lista, si chiude e si torna al passo 9
11. L’utente esce dall’app.
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android
Figura 10 Crea carrello virtuale da casa
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
63
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android
Figura 11 Processo di pagamento da casa
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
64
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
66
Figura 12 Crea carrello virtuale dal supermercato
Figura
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android
Figura 13 Processo di pagamento dal supermercato
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
67
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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.
4.3.1 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
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
69
4.1.1 se SI (UC4)
4.1.2 se NO (UC6)
Postcondizioni
- SuperApp è avviata
- Il cliente è in grado di selezionare e scegliere prodotti da acquistare
Cammini
MAIN PATH: 1.1 – 2.1 – 3.1 – 4.1 – 4.1.1
PATH_1: 1.1 – 2.1 – 3.1 – 4.1 – 4.1.2
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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
4.1.1 se SI SuperApp richiede la decodifica TAG (UC4)
4.1.2 se NO SuperApp fa visualizzare il menù principale
Postcondizioni
- SuperApp è avviata
- Il cliente è in grado di selezionare e scegliere prodotti da acquistare
Cammini
MAIN PATH: 1.1 – 2.1 – 3.1
PATH_1: 1.1 – 2.1 – 3.1 –
4.3.3 Controllo utente UC3
Portata
Applicativo per smartphone
Parte interessata
Utente Telecom
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android
Il cliente è in grado di selezionare e scegliere prodotti da acquistare
3.1 – 4.1 – 4.1.2
– 4.1 – 4.1.1
ontrollo utente UC3
Applicativo per smartphone
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
71
Il cliente è in grado di selezionare e scegliere prodotti da acquistare
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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
1.1.1 i dati esistono, si passa a UC1 o UC2
1.1.2 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
6.1.1 il cliente non è registrato�SuperDB inserisce i dati nel DB remoto
6.1.2 il cliente è registrato
7.1 SuperDB invia l’esito a SuperApp
8.1 SuperApp riceve l’esito e torna a UC1 o UC2
Postcondizioni
- Il cliente è registrato
Cammini
MAIN PATH: 1.1 – 1.1.1
PATH_1: 1.1 – 1.1.2 – 2.1
PATH_2: 1.1 – 1.1.2 – 2.1
4.3.4 Decodifica TAG UC4
Portata
Applicativo per smartphone
Parte interessata
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android
Il cliente è registrato
2.1 – 3.1 – 4.1 – 5.1 – 6.1 – 6.1.1 – 7.1 - 8.1
2.1 – 3.1 – 4.1 – 5.1 – 6.1 – 6.1.2 – 7.1 - 8.1
Decodifica TAG UC4
Applicativo per smartphone
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
73
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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
3.1.1 se NO SuperDB genera ed invia a SuperApp un messaggio di errore
3.1.2 se SI SuperDB recupera ed invia info a SuperApp
4.1 SuperApp riceve esito
4.1.1 SuperApp fa visualizzare un errore e poi fa visualizzare il menù principale
4.1.2 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: 1.1 – 2.1 – 3.1 – 3.1.2 - 4.1 – 4.1.2
PATH_1: 1.1 – 2.1 – 3.1 – 3.1.1 - 4.1 – 4.1.1
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
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android
Aggiungi o annulla UC5
Applicativo per smartphone
Aggiungere, annullare o visualizzare informazioni sul prodotto selezionato
: Telecom
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
75
Aggiungere, annullare o visualizzare informazioni sul prodotto selezionato
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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:
2.1.1 il cliente sceglie l’azione: visualizza info “aggiuntive” e si passa a UC10
2.1.2 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
2.2.2 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: 1.1 – 2.1 – 2.1.2 - 3.1 - 4.1 – 5.1
PATH_1: 1.1 – 2.1 – 2.2.2 - 3.2
PATH_2: 1.1 – 2.1 – 2.1.1
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.
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android
Visualizza menu principale UC6
Applicativo per smartphone
Visualizzare i prodotti aggiunti al carrello virtuale con le diverse operazioni che si
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
77
Visualizzare i prodotti aggiunti al carrello virtuale con le diverse operazioni che si
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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:
2.1.1 carrello vuoto: SuperApp fa visualizzare il carrello vuoto
2.1.2 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: 1.1 – 2.1 – 2.1.2 - 3.1
PATH_1: 1.1 – 2.1 – 2.1.1 – 3.1
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
79
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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:
6.1.1 annulla: si torna a UC6
6.1.2 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:
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
81
6.2.1 annulla: si torna a UC6
6.2.2 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: 1.1 – 2.1 – 3.1 – 4.1 – 5.1 – 6.1 – 6.1.2 – 7.1
PATH_1: 1.1 – 2.1 – 3.2 – 4.2 – 5.2 – 6.2 – 6.2.2 – 7.2 - 8.2
PATH_2: 1.1 – 2.1 – 3.1 – 4.1 – 5.1 – 6.1 – 6.1.1
PATH_3: 1.1 – 2.1 – 3.2 – 4.2 – 5.2 – 6.2 – 6.2.1
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
82
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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?
4.1.1 NO� si torna a UC6
4.1.2 SI� SuperApp svuota il carrello e si chiude
Postcondizioni
- SuperApp si chiude
Cammini
MAIN PATH: 1.1 – 2.1 – 3.1 – 4.1 – 4.1.2
PATH_1: 1.1 – 2.1 – 3.1 – 4.1 – 4.1.1
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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: 1.1 – 2.1 – 3.1 – 4.1
4.3.10 Visualizza info prodotto UC10_2
Portata
Applicativo per smartphone
Parte interessata
Utente Telecom
Interessi
Visualizzare le informazioni aggiuntive del prodotto selezionato
Attori
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android
Visualizza info prodotto UC10_2
Applicativo per smartphone
Visualizzare le informazioni aggiuntive del prodotto selezionato
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
86
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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: 1.1 – 2.1 – 3.1 – 4.1
4.3.11 Rimuovi UC11
Portata
Applicativo per smartphone
Parte interessata
Utente Telecom
Interessi
Rimuovere un prodotto dalla lista della spesa
Attori
- Primario : Utente
- SuD: SUPER-APP
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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
3.1.1 “SI”: SuperApp rimuove il prodotto dalla lista
3.1.2 “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: 1.1 – 2.1 – 3.1 – 3.1.1 - 4.1 – 5.1
PATH_1: 1.1 – 2.1 – 3.1 – 3.1.2
4.3.12 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
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android
Invio ordine al server UC13
Applicativo per smartphone
Inviare l’ordine spesa al server del supermercato
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
89
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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
3.1.1 Esito positivo: SuperDB invia un messaggio di “Ricezione ordine avvenuta
con successo”
3.1.2 Esito negativo: SuperDB invia un messaggio di “Ricezione ordine fallita”
4.1 Operazione successiva all’esito
4.1.1 SuperDB invia l’ordine al supermercato che provvede a preparare la spesa
ed invia il fattorino a casa del cliente per la consegna
4.1.2 SuperApp torna al 2.1
5.1 SuperDB notifica la partenza dell’ordine
6.1 SuperApp visualizza la notifica al cliente
Postcondizioni
- Cliente attende l’arrivo del fattorino
Cammini
MAIN PATH: 1.1 – 2.1 – 3.1 – 3.1.1 - 4.1 – 4.1.1 - 5.1 – 6.1
PATH_1: 1.1 – 2.1 – 3.1 – 3.1.2 - 4.1 – 4.1.2
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
91
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
92
4.3.13 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
3.1.1 NON CONFERMA: si torna a UC6
3.1.2 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
MAIN PATH: 1.1 – 2.1 – 3.1
PATH_1: 1.1 – 2.1 – 3.1 –
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android
3.1 – 3.1.2 – 4.1
– 3.1.1
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
93
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
94
4.3.14 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: 1.1 – 2.1 – 3.1
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
95
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
96
4. Use Case Diagram
LEGENDA
UC1: Avvio con Tapping UC2: Avvio da menu
UC3: Controllo utente UC4: Decodifica TAG
UC5: Aggiungi o annulla UC6: Visualizza menu principale
UC7: Termina e paga UC8: Esci dall’applicazione
UC9: Remote Payment UC10: Visualizza info prodotto
UC11: Rimuovi UC12: Proximity payment
UC13: Invio ordine al server UC14: Visualizza carte
UC15: Seleziona carta UC16: Effettua pagamento remoto
UC17: Verifica cliente
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
97
5. Activity Diagram associati all’applicazione supermercato
Figura 14 Activity diagram associato al processo d'acquisto
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
99
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
101
Decodifica TAG UC4 con SD4
6-2 Sequence Diagram SD4
Aggiungi o annulla UC5 con SD5
6-3 Sequence Diagram SD5
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
102
Visualizza menu principale UC6 con SD6
6-4 Sequence Diagram SD6
Termina e paga UC7 con SD7
6-5 Sequence Diagram SD7
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
104
Visualizza info prodotto UC10_2 con SD10_2
6-9 Sequence Diagram SD10_2
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
105
Rimuovi UC11 con SD11
6-10 Sequence Diagram SD11
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
106
Invio ordine al server UC13 con SD13
6-11 Sequence Diagram SD13
Effettua pagamento remoto UC16 con SD16
6-12 Sequence Diagram SD16
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
107
Verifica cliente UC17 con SD17
6-13 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.
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
108
Figura 15 Sviluppo dei componenti
4.8.1 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 server.
@Classe di lettura tag NFC
public class NFCManager {
NfcAdapter adapter;
PendingIntent mNfcPendingIntent;
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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_TO P),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.getInte nt().getAction()));
}
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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_NDE F_MESSAGES);
if (rawMsgs != null) {
msgs = new NdefMessage[rawMsgs.length];
for (int i = 0; i < rawMsgs.length; i++) {
msgs[i] = (NdefMessage) rawMsgs[i];
}
} else {
// Unknown tag type
byte[] empty = new byte[] {};
NdefRecord record = new NdefRecord(NdefRecord.TNF_UNKNOWN, empty, empty, em pty);
NdefMessage msg = new NdefMessage(new NdefRecord[] {
record
});
msgs = new NdefMessage[] {
msg
};
}
} else {
Log.d("", "Unknown intent."); // ""
//finish();
}
return msgs;
}
}
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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
supermercato
@Query di interrogazione al DBManager
public static ResultSet queryCheckTag(String codifi ca){
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;
}
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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 ServletExcepti on, 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 ServletExcepti on, IOException {
}
public JSONObject getTag(JSONObject tag){
//{"codifica":"tag1"}
Response resp=new Response(false,0,null);
String cod="";
try{
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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 prodotto
@Query di interrogazione al DBManager
public static ResultSet queryDecodificaTag(String c odifica){
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 rs;
}
@WebServlet("/DecodificaTag")
public class DecodificaTag extends BackendServlet {
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
114
private static final long serialVersionUID = 1L;
public DecodificaTag() {
super();
// TODO Auto-generated constructor stub
}
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletExcepti on, 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 ServletExcepti on, IOException {
// TODO Auto-generated method stub
}
public JSONObject getTag(JSONObject tag){
JSONObject t=null;
//{"codifica":"tag1"}
String cod="";
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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 prodotto
@Query 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;
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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 ServletExcepti on, 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 ServletExcepti on, IOException {
// TODO Auto-generated method stub
}
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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.getStri ng("immagine");
}
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);
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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 ordine.
@Query di interrogazione al DBManager
public static ResultSet queryIdCliente(String email ){
DBManager dbm=new DBManager();
ResultSet rs=null;
try {
Statement state=conn.createStatement();
rs=state.executeQuery("SELECT idcliente FROM cliente WHERE email='"+email+"'");
} 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+"')");
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
119
} catch (SQLException e) {
e.printStackTrace();
}
return rs;
}
public static ResultSet queryLeggiIdOrdine(int nOrd ine){
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_idOrdi ne) VALUES ("+idCliente+","+idOrdine+")");
} catch (SQLException e) {
e.printStackTrace();
}
return rs;
}
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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_idO rdine) VALUES ("+idProdotto+","+idOrdine+")");
} catch (SQLException e) {
e.printStackTrace();
}
return rs;
}
@WebServlet("/InviaOrdine")
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 ServletExcepti on, IOException {
PrintWriter out = response.getWriter();
String email=request.getParameter("email");
String prodotti = request.getParameter("prodotti");
JSONArray jAr=null;
try {
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
121
jAr=new JSONArray(prodotti);
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
idCliente(email,jAr,out);
}
protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletExcepti on, IOException {
// TODO Auto-generated method stub
}
public void idCliente(String email,JSONArray codifica,PrintWriter out){
try{
ResultSet resul=DBManager.queryIdCliente(email);
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);
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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();
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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(idclient e, 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++){
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
124
JSONObject obj=codifica.getJSONObject(i);
idProd[i]=obj.getInt("idprodotto");
System.out.println("id prodotto: "+idProd[i]);
int result=DBManager.queryInserisciRelazioneP_O(idProd[ i], idordine);
System.out.println("Ordine prodotto creato\n "+result);
if(result==0){
res.setValoreBool(true);
}
}
//[{"prezzo":0.78,"tag":{"codifica":"mortadellasupr ema"},"idprodotto":4,"marca":"Fiorucci","nome":"Mortadella Suprema"},{"prezzo":1.29,"tag":{"codifica":"arrosto fiorucci"},"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;
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
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 SUPERAPP.
@Query di interrogazione al DBManager
public static ResultSet queryPagamento(int nOrdine) {
DBManager dbm=new DBManager();
ResultSet rs=null;
try {
Statement state=conn.createStatement();
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
126
rs=state.executeQuery("SELECT statoOrdine FROM ordine WHERE numeroordine="+nOrdine);
} catch (SQLException e) {
e.printStackTrace();
}
return rs;
}
public static int queryCambiaStatoRemoto(int nOrdi ne){
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 rs;
}
@WebServlet("/PagamentoRemoto")
public class PagamentoRemoto extends BackendServlet {
private static final long serialVersionUID = 1L;
InviaOrdine ordine;
public PagamentoRemoto() {
super();
}
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletExcepti on, IOException {
String ordine=request.getParameter("credenziali") ;
int nOrdine=Integer.parseInt(ordine);
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
127
PrintWriter out=response.getWriter();
out.print(getCarta(nOrdine));
}
protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletExcepti on, 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());
}
}
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
128
9. ScreanShot
Smart Shopping
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
129
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
130
Gestore carte:
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
131
Ritorno a SuperAPP
10. Testing
I casi di test sono stati presi dagli Use Case visti nei capitoli precedenti. Ogni use case è
stato testato e convalidato anche in condizioni di stress del server, per dare all’intero
sistema una maggiore affidabilità.
Il testing che è stato effettuato è di tipo black-box (funzionale), ovvero é fondato
sull'analisi degli output generati dal sistema o da suoi componenti in risposta ad specifici
input definiti sulla base della sola conoscenza dei requisiti specificati per il sistema o di
suoi componenti.
4.10.1 Definizione degli input
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
132
Durante questa fase vengono definiti i valori di input rispettivamente ammissibili e non
ammissibili dei nostri metodi di test:
Check Cliente:
1) Ammissibili: inserire una mail che rispetti la sintassi propria di un indirizzo email:
� Dove lo username può essere qualsiasi
� Il dominio rappresenta il dominio di appartenenza
� .com rappresenta un esempio,altri esempi possono essere: .net, .org,
.it ecc.
2) Non ammissibile:inserire una mail che non rispetti la sintassi di un indirizzo email
precedentemente illustrata.
Check Tag
1)Ammissibili:
� inserimento 10 valori alfanumerici
2)Non ammissibili
� inserimento di 10 valori non alfanumerici
� inserimento di un numero di valori minore di 10
� inserimento di un numero di valori maggiore di 10
Dati Cliente
1) Ammissibili: inserire una mail che rispetti la sintassi propria di un indirizzo email:
o username@ “dominio”.” dominio generico”
� Dove lo username puo’ essere qualsiasi
� Il “dominio” rappresenta il dominio di appartenenza
� “dominio generico” rappresenta un esempio,altri esempi possono
essere: .net, .org, .it, .com ecc.
2) Non ammissibile:inserire una mail che non rispetti la sintassi di un indirizzo email
precedentemente illustrata.
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
133
Decodifica tag
Trattandosi di una codifica:
1)Ammissibili:
� inserimento 10 valori alfanumerici
2)Non ammissibili
� inserimento di 10 valori non alfanumerici
� inserimento di un numero di valori minore di 10
� inserimento di un numero di valori maggiore di 10
Invia ordine
Per cio’ che riguarda l’ email:
1) Ammissibili: inserire una mail che rispetti la sintassi propria di un indirizzo email:
o username@ “dominio”.” dominio generico”
� Dove lo username puo’ essere qualsiasi
� Il “dominio” rappresenta il dominio di appartenenza
� “dominio generico” rappresenta un esempio,altri esempi possono
essere: .net, .org, .it, .com ecc.
1) Non ammissibile:inserire una mail che non rispetti la sintassi di un indirizzo email
precedentemente illustrata.
Per ciò che riguarda l’ oggetto JSON Prodotti:
prodotto sarà composto dai seguenti attributi:
Nome
1)Ammissibili:
� inserimento al massimo di 25 valori alfanumerici
2)Non ammissibili
� inserimento di valori non alfanumerici (al massimo 25)
Marca
1)Ammissibili:
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
134
� inserimento al massimo di 25 valori alfanumerici
2)Non ammissibili
� inserimento di valori non alfanumerici (al massimo 25)
TAG
1)Ammissibili:
� inserimento 10 valori alfanumerici
2)Non ammissibili
� inserimento di 10 valori non alfanumerici
� inserimento di un numero di valori minore di 10
� inserimento di un numero di valori maggiore di 10
Prezzo
1)Ammissibili:
� inserimento di al massimo 10 valori numerici
2)Non ammissibili
� inserimento di valori non numerici
Peso
1)Ammissibili:
� inserimento al massimo 10 valori numerici
2)Non ammissibili
� inserimento di valori non numerici
Info aggiuntive
1)Ammissibili:
� inserimento di al massimo 25 valori alfanumerici
2)Non ammissibili
� inserimento di valori non alfanumerici
Immagine
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
135
1)Ammissibili:
� inserimento di al massimo 25 valori alfanumerici
2)Non ammissibili
� inserimento di valori non alfanumerici
Registra Cliente
Per ciò che riguarda l’ oggetto JSON Cliente:
Cliente sarà formato dai seguenti attributi:
Nome
1)Ammissibili:
� inserimento di al massimo 10 valori alfanumerici
2)Non ammissibili
� inserimento di valori non alfanumerici
Cognome
1)Ammissibili:
� inserimento di al massimo 10 valori alfanumerici
2)Non ammissibili
� inserimento di valori non alfanumerici
1) Ammissibili: inserire una mail che rispetti la sintassi propria di un indirizzo email:
o username@ “dominio”.” dominio generico”
� Dove lo username puo’ essere qualsiasi
� Il “dominio” rappresenta il dominio di appartenenza
� “dominio generico” rappresenta un esempio,altri esempi possono
essere: .net, .org, .it, .com ecc.
2) Non ammissibile:inserire una mail che non rispetti la sintassi di un indirizzo email
precedentemente illustrata.
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
136
Indirizzo
1)Ammissibili:
� inserimento di al massimo 25 valori alfanumerici
2)Non ammissibili
� inserimento di valori non alfanumerici
Username
1)Ammissibili:
� inserimento al massimo di 10 valori alfanumerici
2)Non ammissibili
� inserimento di valori non alfanumerici( al massimo 10)
Password
1)Ammissibili:
� inserimento di al massimo 10 valori alfanumerici
2)Non ammissibili
� inserimento di valori non alfanumerici( al massimo 10)
Visualizza info prodotto
Trattandosi di una codifica:
1)Ammissibili:
� inserimento 10 valori alfanumerici
2)Non ammissibili
� inserimento di 10 valori non alfanumerici
� inserimento di un numero di valori minore di 10
� inserimento di un numero di valori maggiore di 10
Offerte
Trattandosi di una codifica:
1)Ammissibili:
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
137
� inserimento 10 valori alfanumerici
2)Non ammissibili
� inserimento di 10 valori non alfanumerici
� inserimento di un numero di valori minore di 10
� inserimento di un numero di valori maggiore di 10
Pagamento remoto
Trattandosi di una sequenza di numeri interi:
1)Ammissibili:
� inserimento 10 valori numerici
2)Non ammissibili
� inserimento di 10 valori non numerici
� inserimento di un numero di valori minore di 10
� inserimento di un numero di valori maggiore di 10
Pagamento Proximity
Trattandosi di una sequenza di numeri interi:
1)Ammissibili:
� inserimento 10 valori numerici
2)Non ammissibili
� inserimento di 10 valori non numerici
� inserimento di un numero di valori minore di 10
� inserimento di un numero di valori maggiore di 10
4.10.2 Descrizione dettagliata dei test
Check Cliente: data l’email(Stringa)controlla se esiste il cliente(Boolean)
• T1P0T11 inserire mail utente che rispetti la sintassi precedentemente
definita ed esiste
• T1P0T12inserire mail utente che non rispetti la sintassi precedentemente
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
138
definita
• T1P0T13inserire mail utente che rispetti la sintassi precedentemente
definita e non esiste
Check Tag:dato la codifica del Tag (Stringa) controlla se esiste il prodotto (Boolean)
• T2P0T11 inserire tag con 10 caratteri alfanumerici ed esiste
• T2P0T12 inserire tag con 10 caratteri con almeno uno non alfanumerico
• T2P0T13 inserire il tag con 10 caratteri alfanumerici e non esiste
• T2P0T14 inserire tag con meno di 10 caratteri non alfanumerici
• T2P0T15 inserire tag con più di 10 caratteri non alfanumerici
Dati Cliente: data l’ email (Stringa) restituisce il cliente(Cliente)
• T3P0T11 inserire mail utente che non rispetti la sintassi precedentemente
definita
• T3P0T12inserire mail utente che rispetti la sintassi precedentemente
definita ed esiste
• T3P0T13inserire mail utente che rispetti la sintassi precedentemente
definita ed non esiste
Decodifica tag: data una codifica (Stringa) restituisce una decodifica(Stringa)
• T4P0T11 inserire tag con 10 caratteri alfanumerici che esiste
• T4P0T12 inserire tag con 10 caratteri con almeno uno non alfanumerico
• T4P0T13 inserire tag con 10 caratteri alfanumerici che non esiste
• T4P0T14 inserire tag con meno di 10 caratteri non alfanumerici
• T4P0T15 inserire tag con più di 10 caratteri non alfanumerici
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
139
Invia ordine: data l’email (Stringa) e i prodotto(Oggetti-JSON)invia ordine al
supermercato(Boolean)
• T5P0T11 inserire mail utente che non rispetti la sintassi precedentemente
definita
• T5P0T12 inserire mail utente che rispetti la sintassi precedentemente
definita ed esiste
• T5P0T13 inserire mail utente che rispetti la sintassi precedentemente
definita ed non esiste
Errori sull’invio degli oggetti possono venire da un errori interno che può dipendere da
fattori che non sono correlati dall’inserimento manuale dell’utente. Si tratta quindi di
errori inerenti al sistema e alle corrispondenze che possono non essere riscontrate
.ESEMPIO: se viene spedito un oggetto dal dispositivo che non viene riconosciuto da
sistema-dati del supermercato allora ci sono degli scostamenti di tipo singolo dato tra le
due parti dialoganti. La trattazione di questi tipi di errori devono quindi essere affrontati
separatamente dalla presente specifica.
Registra Cliente:Dato un cliente(Cliente) memorizza il cliente nel Database di
supporto e restituisce un Boolean (Boolean)
Visualizza info prodotto:data la codifica(Stringa) si restituisce le informazioni di un
prodotto(Prodotto)
• T6P0T11 inserire codifica con 10 caratteri alfanumerici ed esiste
• T6P0T12 inserire codifica con 10 caratteri con almeno uno non
alfanumerico
• T6P0T13 inserire il codifica con 10 caratteri alfanumerici ma non esiste
• T6P0T14 inserire codifica con meno di 10 caratteri non alfanumerici
• T6P0T15 inserire codifica con più di 10 caratteri non alfanumerici
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
140
Offerte: data la codifica del Tag (Stringa)controlla se esiste un prodotto con il prezzo
piu’ basso(Prodotto)
• T7P0T11 inserire tag con 10 caratteri alfanumerici ma esiste
• T7P0T12 inserire tag con 10 caratteri con almeno uno non alfanumerico
• T7P0T13 inserire il tag con 10 caratteri alfanumerici ma non esiste
• T7P0T14 inserire tag con meno di 10 caratteri non alfanumerici
• T7P0T15 inserire tag con più di 10 caratteri non alfanumerici
Pagamento in remoto dato il numero d’ordine (Integer) controlla se il pagamento e’
stato effettuato (Boolean)
• T8P0T11 inserire numero ordine con 10 caratteri numerici che esiste
• T8P0T12 inserire numero ordine con 10 caratteri con almeno uno non
numerico
• T8P0T13 inserire il numero ordine con 10 caratteri numerici che non esiste
• T8P0T14 inserire numero ordine con meno di 10 caratteri non numerici
• T8P0T15 inserire numero ordine con più di 10 caratteri non numerici
Pagamento proximity: dato il numero d’ordine(Integer) controlla se il pagamento e’
stato effettuato(Boolean)
• T9P0T11 inserire numero ordine con 10 caratteri numerici che esiste
• T9P0T12 inserire numero ordine con 10 caratteri con almeno uno non
numerico
• T9P0T13 inserire il numero ordine con 10 caratteri numerici che non esiste
• T9P0T14 inserire numero ordine con meno di 10 caratteri non numerici
• T9P0T15 inserire numero ordine con più di 10 caratteri non numerici
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
141
Riassumendo
Metodo da Verificare INPUT OUTPUT
CHECK CLIENTE Mail Boolean
CHECK TAG Tag Boolean
DATI CLIENTE Mail cliente
DECODIFICA TAG Codifica Decodifica
INVIA ORDINE Mail Boolean
REGISTRA CLIENTE Cliente Boolean
VISUALIZZA INFO
PRODOTTO
Codifica Prodotto
OFFERTE Tag Prodotto
PAGAMENTO REMOTO Integer Boolean
PAGAMENTO PROXIMITY Integer Boolean
Istanze da inserire
Metodo da Verificare INPUT OUTPUT
CHECK CLIENTE [email protected] T
peppe@mailcom F
CHECK TAG aaaaa11111 T
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
142
aaaaa@# 111 F
1aaaa11111 F
aaaaa1111 F
aaaaa111111 F
DATI CLIENTE peppe@mailcom NO Cliente
[email protected] Cliente
[email protected] NO Cliente
DECODIFICA TAG aaaaa11111 Decodifica
aaaaa@# 111 NO Decodifica
1aaaa11111 NO Decodifica
aaaaa1111 NO Decodifica
aaaaa111111 NO Decodifica
INVIA ORDINE peppe@mailcom F
REGISTRA CLIENTE Cliente Boolean
VISUALIZZA INFO
PRODOTTO
aaaaa11111 Prodotto
aaaaa@# 111 NO Prodotto
1aaaa11111 No Prodotto
aaaaa1111 No Prodotto
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
143
aaaaa111111 No Prodotto
OFFERTE aaaaa11111 Prodotto
aaaaa@# 111 NO Prodotto
1aaaa11111 No Prodotto
aaaaa1111 No Prodotto
aaaaa111111 No Prodotto
PAGAMENTO REMOTO 1111111111 T
111111111a F
1111111112 F
111111111 F
11111111111 F
PAGAMENTO PROXIMITY 1111111111 T
111111111a F
1111111112 F
111111111 F
11111111111 F
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
144
5. Conclusioni
Secondo l'Osservatorio Nfc & Mobile Payment della School of Management del
Politecnico di Milano sono 23 milioni gli italiani hanno effettuato almeno un pagamento
via cellulare. Il mobile commerce vale 80 milioni. Ma l'abitudine al contante rischia di
frenare lo sviluppo del mercato.
In un contesto simile il Mobile Payment può davvero costituire un importante fattore di
innovazione sia per il settore dei servizi di pagamento – favorendo lo sviluppo dei
pagamenti elettronici – sia per il settore della telefonia mobile – dove i principali operatori
sono alla ricerca di nuovo spazio competitivo, e anche una fonte di valore per diversi
stakeholder: per la banche e i circuiti, alla ricerca di nuovi modelli per diffondere i
pagamenti elettronici; per le telco, alla ricerca di nuove categorie di servizi a valore
aggiunto per i propri utenti; per gli esercenti, alla ricerca di fonti di ottimizzazione dei
processi e di miglioramento del servizio al cliente; per gli utenti stessi, alla ricerca alla
possibilità di acquistare dovunque e in qualsiasi momento; per la Pubblica
amministrazione, alla ricerca di fonti di riduzione dei costi, di miglioramento del servizio
ai cittadini e di strumenti chiave per l'emersione del sommerso.
Progettazione e sviluppo di un applicazione di Mobile Payment
Su Dispositivo Android tramite tecnologia NFC
145
6 Bibliografia
[1] Roy Want, 2006, “An Introduction to RFID Technology”,
http://www.perada.eu/documents/articles-perspectives/an-introduction-to-rfid-
technology.pdf
[2] Paolo Talone, Giuseppe Russo, Fondazione Ugo Bordoni, Gaetano Marrocco,
Emidio Di Giampaolo, Università di Roma di Tor Vergata,
“ RFID Fondamenti di una tecnologia silenziosamente pervasiva, Parte III
ACCOPPIAMENTO, ENERGIA E ANTENNE NEI TAG PASSIVI”,
http://www.rfid.fub.it/edizione_2/Parte_III.pdf
[3] SIMalliance Interoperability Working Group [15/6/2011]
“Mobile Near Field Communication (Mobile NFC) Stepping Stones”
[4] Sito JavaSun: http://java.sun.com/products/javacard/
[5] Sito JavaCard: www.javacardforum.org/
[6] Android developers - “http://developer.android.com”