Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica

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


Su Dispositivo Android tramite tecnologia NFC

1

Mobile Payment su dispositi vo



2

Ai miei genitori ed al mio ragazzo



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



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



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.



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.



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



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



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



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.



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



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.



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



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)



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).



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



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:



18

Tabella 8 Differenziazione TAG



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.



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:



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).



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.



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).



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).



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



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.



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


aggiunta alla semplice memorizzazione dati. In genere le carte con CPU forniscono

anche la possibilità di crittografate i dati.


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.



27


aggiunta alla semplice memorizzazione dati. In genere le carte con CPU forniscono


di comunicazione asincrona a cui queste smart card

significative delle carte con CPU é la possibilità di gestire



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.



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.



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:



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



lunghezza variabile e 2 byte di stato:



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



� 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).



Response APDU

Figura 17 Risposta APDU

DataField: contiene i dati effettivi di risposta

contengono il primo ed il secondo byte di stato dell’elaborazione


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


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


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



eccezione riscontrata).



32

contengono il primo ed il secondo byte di stato dell’elaborazione


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


Se si tratta di un comando, l’APDU viene passato alla JavaCard Applet

na selezione il Framework procede alla


Una volta che la JavaCard Applet ha terminato le elaborazioni richieste,

ati di risposta e da una SW





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.



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



Le Java Card Applet sono passive, nel senso che non iniziano mai una


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




argomenti un AID ha come risultato una condivisione limitata con la


Figura 18 Organizzazione dei componenti SW di JavaCard



contiene la JCVM (Java Card Virtual Machine, deputata all’elaborazione del bytecode



dell’API) e l’insieme dei metodi nativi (metodi implementati tramite opportuno




35

Le Java Card Applet sono passive, nel senso che non iniziano mai una


Le Java Card Applet sono isolate di default una dall’altra, ma possono

fra loro o fra alcune di loro richiedendolo




AID ha come risultato una condivisione limitata con la




contiene la JCVM (Java Card Virtual Machine, deputata all’elaborazione del bytecode), il



dell’API) e l’insieme dei metodi nativi (metodi implementati tramite opportuno hardware




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);



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)



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.



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.



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



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.



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



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



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.



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.



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



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



Figura 7 Flow chart processo di pagamento



48



49

3. Analisi e progettazione di alto

livello

In questo documento verranno descritti tutti i casi d’uso individuati per l’applicazione

Gestore Carte e Applet, successivamente passeremo agli activity diagram e sequence

diagram.

Nel capitolo successivo si analizzarano gli use case dell’applicazione del supermercato,

che andranno a completaregli use case, gli activity diagram, i sequence diagram ed infine

il class diagram con cui concluderemo la fase di progettazione. Da notare che gli use case

che individueremo in questo capitolo non sono numerati a partire da “1” perché la fase di

progettazione è stata effettuata in parallelo con quella dell’applicazione successiva, quindi

andremo a completare tutti i casi d’uso nel capitolo 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



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



50

CardApp inoltra i dati per il pagamento remoto a SUPER_APP e attende l’esito



51

3.1.2 Proximity payment UC12

Portata


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



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


Parte interessata

Utente Telecom

Interessi

Visualizzare le carte disponibili per effettuare il pagamento

Attori

- Primario : Utente



Visualizza carte UC14


carte disponibili per effettuare il pagamento



53



54

- SuD: CARD-APP,APPLET

- Supporto: Nessuno

Precondizioni

- Proximity pay (UC12)

- Remote pay (UC9)

Flusso base

1.1 Cliente seleziona l’opzione “Termina&Paga” dalla schermata del Menù Principale

2.1 SuperApp apre CardApp (alternativa 2.2)

3.1 CardApp richiede la lista delle carte/wallet all’applet

4.1 L’applet legge le carte/wallet presenti nei SD e invia la lista a CardApp

5.1 CardApp visualizza la lista di carte/wallet e attende la selezione del cliente

Flusso alternative

2.2 POS apre CardApp

Postcondizioni

- Cliente ha la lista delle carte/wallet che può utilizzare per il pagamento

Cammini

MAIN PATH: 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


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



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



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



Cliente inserisce il PIN

CardApp invia i dati all’applet (UC12,UC9)

CardApp attende l’esito del pagamento

3.1 – 4.1



56



57

2. Activity Diagram associato al processo di pagamento

Figura VIII:activity diagram associato al processo 2(gestione portafogli elettronico)



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



59

3.3.2 Proximity payment UC12 con SD12




60

3.3.3 Visualizza carte UC14 con SD14


3.3.4 Seleziona carta UC15 con SD15




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



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.



Figura 10 Crea carrello virtuale da casa



63



Figura 11 Processo di pagamento da casa



64



65

2. Requisiti spesa al supermercato

L’app fa visualizzare una lista della spesa, inizialmente vuota, dove l’utente potrà inserire

i prodotti che vuole acquistare. L’utente sceglie un prodotto da voler aggiungere/visionare

sullo smartphone e decide se aggiungerlo o meno alla lista, poi sceglie un altro prodotto

iterando il processo. Conclusa questa prima fase può decidere se effettuare il pagamento o

annullare l’operazione.

Requisiti funzionali:

1. L’utente apre l’applicazione

2. L’app presenta un carrello virtuale sempre aggiornato con prodotti e TOT

3. L’utente può visualizzare le informazioni e le azioni associate ad un prodotto

avvicinando lo smartphone al TAG

4. L’utente può aggiungere/rimuovere/annullare un prodotto leggendo il TAG NFC

ad esso associato

4.1. Nel caso di rimozione, l’utente deve confermare l’operazione

5. L’app dovrà aggiornare la lista, aggiornare il totale della spesa e farla visualizzare

6. Quando l’utente avrà terminato la selezione dei prodotti, potrà decidere se

effettuare il pagamento o annullare l’intera operazione

6.1. Se decide di effettuare il pagamento avvicina lo smartphone al POS, e si mette

in attesa; il POS avvia CARD-APP e si effettua il pagamento come descritto

nel paragrafo relativo

6.2. Nel secondo caso, l’app cancella la lista e si chiude.

7. Terminato il pagamento, l’APPLET dovrà inviare un ack/nack a SUPER-APP che

è ancora in attesa

7.1. Se riceve l’ACK, genera uno scontrino digitale con tutti i prodotti e il totale

pagato che manterrà salvato per un TOT di tempo;

7.2. Se riceve un NACK salva la lista, si chiude e si torna al passo 6

8. L’utente chiude l’app



66

Figura 12 Crea carrello virtuale dal supermercato

Figura



Figura 13 Processo di pagamento dal supermercato



67



68

3. Casi d’uso (UCx)

Paretendo dal flow chart visto nel capitolo precedente, andremo a scomporlo fino ad

individuare i singoli casi d’uso delle nostre applicazioni.

4.3.1 Avvio con Tapping UC1

Portata


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



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



70

4.3.2 Avvio da menu UC2

Portata


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


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


Parte interessata

Utente Telecom



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




71

Il cliente è in grado di selezionare e scegliere prodotti da acquistare



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


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


Parte interessata



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




73



74

Utente Telecom

Interessi

Permette di eseguire più operazioni su un prodotto selezionato

Attori

- Primario : Utente

- SuD: SUPER-APP

- Supporto: Tapping su TAG NFC associato al prodotto di interesse e connessione

al SuperDB del supermercato


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


Parte interessata

Utente Telecom

Interessi

Aggiungere, annullare o visualizzare informazioni sul prodotto selezionato

Attori

- Primario : Utente

- SuD: SUPER-APP


Precondizioni



Aggiungi o annulla UC5



: Telecom



75




76

- Decodifica TAG (UC4)

Flusso base

1.1 SuperApp fa visualizzare le info del prodotto selezionato dal cliente

2.1 Il cliente sceglie un’azione:

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


Parte interessata

Utente Telecom

Interessi

Visualizzare i prodotti aggiunti al carrello virtuale con le diverse operazioni che si

possono effettuare.



Visualizza menu principale UC6





77




78

Attori

- Primario : Utente

- SuD: SUPER-APP

Precondizioni

- Si arriva a UC6 da uno dei seguenti Use Case:

� CONTROLLO UTENTE UC3

� DECODIFICA TAG UC4

� AGGIUNGI/ANNULLA UC5

� TERMINA E PAGA UC7

� ESCI UC8

� VISUALIZZA INFO UC10

� RIMUOVI UC11

Flusso base

1.1 SuperApp fa visualizzare il menù delle operazioni

2.1 SuperApp esegue un check per verificare se il carrello è vuoto:

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





79



80

4.3.7 Termina e paga UC7

Portata


Parte interessata

Utente Telecom

Interessi

Effettuare il pagamento

Attori

- Primario : Utente

- SuD: SUPER-APP


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:



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





82



83

4.3.8 Esci dall’applicazione UC8

Portata


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



84

4.3.9 Visualizza info prodotto UC10_1

Portata


Parte interessata

Utente Telecom

Interessi

Visualizzare le informazioni aggiuntive del prodotto selezionato

Attori

- Primario : Utente



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


Parte interessata

Utente Telecom

Interessi


Attori



Visualizza info prodotto UC10_2





86



87

- Primario : Utente

- SuD: SUPER-APP

- Supporto: Connessione al SuperDB del supermercato

Precondizioni

- Visualizza Menù Principale (UC6)

Flusso base

1.1 Cliente seleziona l’opzione “Visualizza informazioni” dalla schermata Menù

Principale

2.1 SuperApp invia a schermo le informazioni aggiuntive del prodotto

3.1 Cliente chiude la finestra di informazioni aggiuntive

4.1 SuperApp torna alla schermata Menù Principale

Postcondizioni

- Cliente ha visualizzato le informazioni aggiuntive del prodotto selezionato

- Cliente può scegliere un altro prodotto e/o un’altra azione sul prodotto

Cammini

MAIN PATH: 1.1 – 2.1 – 3.1 – 4.1

4.3.11 Rimuovi UC11

Portata


Parte interessata

Utente Telecom

Interessi

Rimuovere un prodotto dalla lista della spesa

Attori

- Primario : Utente

- SuD: SUPER-APP



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


Parte interessata

Utente Telecom

Interessi

Inviare l’ordine spesa al server del supermercato

Attori

- Primario : Utente



Invio ordine al server UC13


Inviare l’ordine spesa al server del supermercato



89



90

- SuD: SUPER-APP

- Supporto: Connessione al server del supermercato

Precondizioni

- Remote pay (UC9)

Flusso base

1.1 SuperApp riceve la conferma di avvenuto pagamento del 20% in remote pay

2.1 SuperApp invia la richiesta d’ordine al SuperDB del supermercato

3.1 SuperDB del supermercato verifica l’ordine

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





91



92

4.3.13 Effettua pagamento remoto UC16

Portata


Parte interessata

Utente Telecom

Interessi

Effettuare il pagamento tramite internet

Attori

- Primario : Utente

- SuD: SUPER-APP


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 –



3.1 – 3.1.2 – 4.1

– 3.1.1



93



94

4.3.14 Verifica cliente UC17

Portata


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





95



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



97

5. Activity Diagram associati all’applicazione supermercato

Figura 14 Activity diagram associato al processo d'acquisto



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



99



100

7. Sequence Diagram associati all’applicazione supermercato

Avvio con Tapping UC1 con SD1, Avvio da menu UC2 con SD2,

Controllo utente UC3 con SD3

Dato che questi 3 Use Case sono fortemente correlati tra loro, i 3 relativi Seqence Diagram

sono stati incorporati in un unico Sequence Diagram

6-1 Sequence Diagram SD1-SD2-SD3



101

Decodifica TAG UC4 con SD4


Aggiungi o annulla UC5 con SD5




102

Visualizza menu principale UC6 con SD6


Termina e paga UC7 con SD7




103

Esci dall’applicazione UC8 con SD8


Visualizza info prodotto UC10_1 con SD10_1

6-7 Sequence Diagram SD10_1



104

Visualizza info prodotto UC10_2 con SD10_2

6-9 Sequence Diagram SD10_2



105

Rimuovi UC11 con SD11




106

Invio ordine al server UC13 con SD13


Effettua pagamento remoto UC16 con SD16




107

Verifica cliente UC17 con 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.



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;



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()));

}



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;

}

}



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;

}



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) {


}

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{



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


public static ResultSet queryDecodificaTag(String c odifica){


ResultSet rs=null;

try {


rs=state.executeQuery("SELECT nome FROM prodotti WHERE tag='"+codifica+"'");



}

return rs;

}

@WebServlet("/DecodificaTag")

public class DecodificaTag extends BackendServlet {



114


public DecodificaTag() {

super();

// TODO Auto-generated constructor stub

}


String input=request.getParameter("codifica");

JSONObject tag=null;

try {

tag=new JSONObject(input);

System.out.println(tag.toString());


// TODO Auto-generated catch block


}


out.println(getTag(tag));

}


// TODO Auto-generated method stub

}

public JSONObject getTag(JSONObject tag){

JSONObject t=null;


String cod="";



115

try{


ResultSet result=DBManager.queryCheckTag(cod);

String codif="";


codif=result.getString("tag");

}

t=new JSONObject();

t.put("codifica", codif);


return t;

}

}

Visualizza info prodotto: Data la codifica di un prodotto, restituisce tutte le

informazioni relative a quel prodotto


public static ResultSet queryVisualizzaInfoProdotto (String codifica){


ResultSet rs=null;

try {


rs=state.executeQuery("SELECT * FROM prodotti WHERE tag='"+codifica+"'");



}

return rs;



116

}

@WebServlet("/VisualizzaInfo")

public class VisualizzaInfo extends BackendServlet {


//String nProd=tag.getCodifica();

public VisualizzaInfo() {

super();

// TODO Auto-generated constructor stub

}


String tag=request.getParameter("codifica");

JSONObject codifica=null;

try {

codifica=new JSONObject(tag);

System.out.println(codifica.toString());



}


out.println(getInfo(codifica));

}



}



117

public JSONObject getInfo(JSONObject tag){


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{


System.out.println("tag: "+ cod);

ResultSet result=DBManager.queryVisualizzaInfoProdotto(cod);


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);



118


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.


public static ResultSet queryIdCliente(String email ){


ResultSet rs=null;

try {


rs=state.executeQuery("SELECT idcliente FROM cliente WHERE email='"+email+"'");



}

return rs;

}

public static int queryInserisciOrdine(String data, int nOrdine,String statoOrdine){


int rs=0;

try {


rs=state.executeUpdate("INSERT INTO ordine (data,numeroordine,statoOrdine) VALUES ('"+data+"',"+nOrdine+",'"+statoOrdine+"')");



119



}

return rs;

}

public static ResultSet queryLeggiIdOrdine(int nOrd ine){


ResultSet rs=null;

try {


rs=state.executeQuery("SELECT idOrdine FROM ordine WHERE numeroordine="+nOrdine);



}

return rs;

}

public static int queryInserisciRelazioneO_C(int idCliente,int idOrdine){


int rs=0;

try {


rs=state.executeUpdate("INSERT INTO cliente_has_ordine (cliente_idcliente,Ordine_idOrdi ne) VALUES ("+idCliente+","+idOrdine+")");



}

return rs;

}



120

public static int queryInserisciRelazioneP_O(int idProdotto,int idOrdine){


int rs=0;

try {


rs=state.executeUpdate("INSERT INTO prodotti_has_ordine (prodotti_idprodotto,Ordine_idO rdine) VALUES ("+idProdotto+","+idOrdine+")");



}

return rs;

}

@WebServlet("/InviaOrdine")

public class InviaOrdine extends BackendServlet {


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");



String email=request.getParameter("email");

String prodotti = request.getParameter("prodotti");

JSONArray jAr=null;

try {



121

jAr=new JSONArray(prodotti);

} catch (Exception e) {

// TODO Auto-generated catch block


}

idCliente(email,jAr,out);

}



}

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);



122

creaOrdine(idcliente,codifica,out);


}

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();



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++){



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ì"}]


}

public static String getStato() {

return stato;

}

public static void setStato(String stato) {

InviaOrdine.stato = stato;

}

public static String getPreOrdine() {

return preOrdine;



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.


public static ResultSet queryPagamento(int nOrdine) {


ResultSet rs=null;

try {




126

rs=state.executeQuery("SELECT statoOrdine FROM ordine WHERE numeroordine="+nOrdine);



}

return rs;

}

public static int queryCambiaStatoRemoto(int nOrdi ne){


int rs=0;

try {


rs=state.executeUpdate("UPDATE ordine SET statoOrdine='"+InviaOrdine.getAcconto()+"' WHERE numeroordine="+nOrdine);



}

return rs;

}

@WebServlet("/PagamentoRemoto")

public class PagamentoRemoto extends BackendServlet {


InviaOrdine ordine;

public PagamentoRemoto() {

super();

}


String ordine=request.getParameter("credenziali") ;

int nOrdine=Integer.parseInt(ordine);



127

PrintWriter out=response.getWriter();

out.print(getCarta(nOrdine));

}


}

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");

}



}

if(statoOrdine.equalsIgnoreCase("PreOrdine")){

DBManager.queryCambiaStatoRemoto(nOrdine);

resp.setValoreBool(true);

}

return (resp.toJSONBool());

}

}



128

9. ScreanShot

Smart Shopping



129



130

Gestore carte:



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



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:

o [email protected]

� 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


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.





133

Decodifica tag

Trattandosi di una codifica:

1)Ammissibili:


2)Non ammissibili




Invia ordine

Per cio’ che riguarda l’ email:









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:



134


2)Non ammissibili

� inserimento di valori non alfanumerici (al massimo 25)

TAG

1)Ammissibili:


2)Non ammissibili




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



135

1)Ammissibili:


2)Non ammissibili


Registra Cliente

Per ciò che riguarda l’ oggetto JSON Cliente:

Cliente sarà formato dai seguenti attributi:

Nome

1)Ammissibili:


2)Non ammissibili


Cognome

1)Ammissibili:


2)Non ammissibili


Email











136

Indirizzo

1)Ammissibili:


2)Non ammissibili


Username

1)Ammissibili:


2)Non ammissibili

� inserimento di valori non alfanumerici( al massimo 10)

Password

1)Ammissibili:


2)Non ammissibili

� inserimento di valori non alfanumerici( al massimo 10)

Visualizza info prodotto


1)Ammissibili:


2)Non ammissibili




Offerte


1)Ammissibili:



137


2)Non ammissibili




Pagamento remoto

Trattandosi di una sequenza di numeri interi:

1)Ammissibili:

� inserimento 10 valori numerici

2)Non ammissibili

� inserimento di 10 valori non numerici



Pagamento Proximity

Trattandosi di una sequenza di numeri interi:

1)Ammissibili:

� inserimento 10 valori numerici

2)Non ammissibili

� inserimento di 10 valori non numerici



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



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


definita ed esiste


definita ed non esiste

Decodifica tag: data una codifica (Stringa) restituisce una decodifica(Stringa)

• T4P0T11 inserire tag con 10 caratteri alfanumerici che esiste


• T4P0T13 inserire tag con 10 caratteri alfanumerici che non esiste





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


definita ed esiste


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



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


• T7P0T13 inserire il tag con 10 caratteri alfanumerici ma non esiste



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



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

[email protected] F

CHECK TAG aaaaa11111 T



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

[email protected] T

[email protected] F

REGISTRA CLIENTE Cliente Boolean

VISUALIZZA INFO

PRODOTTO

aaaaa11111 Prodotto

aaaaa@# 111 NO Prodotto

1aaaa11111 No Prodotto

aaaaa1111 No Prodotto



143


OFFERTE aaaaa11111 Prodotto

aaaaa@# 111 NO Prodotto

1aaaa11111 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



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.



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”

Documents

Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica