Jízdní řád a jízdenky v mobilním telefonu. Jakub Trnavský

České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů

Bakalářská práce

Jízdní řád a jízdenky v mobilním telefonu Jakub Trnavský

Vedoucí práce: Ing. Jiří Havlík

Studijní program: Elektrotechnika a informatika, strukturovaný, Bakalářský Obor: Výpočetní technika 10. července 2009

iv

v

Poděkování Chtěl bych tímto poděkovat vedoucímu své bakalářské práce Ing. Jiřímu Havlíkovi za cenné připomínky a rady při tvorbě této práce.

vi

vii

Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).

V Praze dne 10. 7. 2009

.............................................................

viii

Abstract The aim of this work is to implement an electronic ticketing system for public transport. The system will utilize a mobile phone with NFC technology to buy and store a ticket in such way that a ticket inspection will be easy. There also will be an interface for searching timetables in mobile application. The system should show an application of NFC technology in common life.

Abstrakt Předmětem této práce je implementace systému pro nákup elektronických jízdenek hromadné dopravy s využitím mobilního telefonu podporujícího technologii NFC. Telefon bude sloužit k zakoupení a také k uložení jízdenky tak, aby její kontrola revizorem byla jednoduchá. V mobilní aplikaci bude připraveno také rozhraní pro vyhledávání jízdních řádů. Systém by měl sloužit jako ukázka použití technologie NFC v systému s reálným uplatněním.

ix

x

Obsah 1 Úvod 1.1 Motivace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Cíle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 1 1

2 Úvodní studie 2.1 Odborný článek . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Případy užití a jejich scénáře . . . . . . . . . . . . . . . . . . 2.3 Rešerše existujících implementací . . . . . . . . . . . . . . . . 2.3.1 Systém Dopravního podniku hlavního města Praha . . 2.3.2 Systém Dopravního podniku města České Budějovice .

. . . . .

3 3 4 7 8 8

. . . . .

9 9 9 10 10 12

. . . . . . . . . . . . . . .

13 13 13 14 14 14 16 17 18 18 18 20 21 21 22 23

3 Technologie NFC 3.1 Základní informace . . . . . 3.2 Vize technologie . . . . . . 3.3 Smart karty a tagy . . . . . 3.4 NFC v mobilních telefonech 3.5 Bezpečnost . . . . . . . . .

. . . . .

. . . . .

. . . . .

4 Analýza a návrh řešení 4.1 Ukládání jizdenky do telefonu . . 4.1.1 Analýza možných řešení . 4.1.2 Ukládání jízdenek a NFC 4.1.3 Návrh bezpečného uložení 4.2 Základní třídy v systému . . . . 4.3 Sekvenční diagramy . . . . . . . 4.4 Rozhraní pro jízdní řády . . . . . 4.5 Architektura systému . . . . . . 4.6 Výběr implementačního prostředí 4.6.1 Implementační prostředí . 4.6.2 Komunikační protokoly . 4.7 Návrh uživatelského rozhraní . . 4.7.1 Mobilní rozhraní . . . . . 4.7.2 Webové rozhraní . . . . . 4.7.3 Desktopové rozhraní . . .

. . . . .

. . . . . . . . a . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . komunikačních protokolů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

xi

. . . . .

. . . . .

. . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . . . . . . . . . . . .

xii

5 Implementace 5.1 Mobilní aplikace . . . . . . . . 5.1.1 ISO14443ConnectionUtil 5.1.2 Třída CekaciObrazovka 5.1.3 Autentizace . . . . . . . 5.2 JavaCard applet . . . . . . . . 5.2.1 Formát uložené jízdenky 5.3 Bussines logika . . . . . . . . . 5.3.1 Použití JDBCRealm . . 5.3.2 Optimistické zamykání . 5.4 Webová rozhraní a logika . . . 5.4.1 JSF stránky . . . . . . . 5.4.2 Webová logika . . . . . 5.4.3 XML-RPC rozhraní . . 5.5 Desktopová aplikace . . . . . . 5.5.1 SmartCardUtil . . . . .

OBSAH

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

25 25 25 26 26 27 27 27 27 28 28 28 28 28 29 29

6 Testování

31

7 Závěr

33

Zdroje

35

A Seznam použitých zkratek

37

B Instalační a uživatelská příručka B.1 Příručka pro zákazníky - webové rozhraní B.1.1 Registrace . . . . . . . . . . . . . . B.1.2 Přihlášení k účtu . . . . . . . . . . B.1.3 Zakoupení jízdenky . . . . . . . . . B.1.4 Editace osobních údajů . . . . . . B.1.5 Odhlášení . . . . . . . . . . . . . . B.2 Příručka pro zákazníky - mobilní aplikace B.2.1 Instalace . . . . . . . . . . . . . . . B.2.2 Spuštění a zvolení operace . . . . . B.2.3 Zakoupení jízdenky a její nahrání B.2.4 Zobrazení jízdenek . . . . . . . . . B.3 Příručka pro prodejce . . . . . . . . . . . B.3.1 Zobrazení účtu zákazníka . . . . . B.3.2 Vložení peněz na účet zákazníka . B.3.3 Prodat jízdenku . . . . . . . . . . B.4 Příručka pro administrátora . . . . . . . . B.5 Instalační příručka . . . . . . . . . . . . . C Obsah přiloženého CD

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

39 39 39 39 39 40 40 40 40 41 41 41 42 42 42 42 42 42 45

Seznam obrázků 2.1

Diagram případů užití . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1

MIDlet a bezkontaktni komunikační API . . . . . . . . . . . . . . . . . . . . . 11

4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10

Diagram tříd . . . . . . . . . . . . . . . . . . . . . . . . . . Sekvenční diagram pro případ užití Registrovat se . . . . . Sekvenční diagram pro případ užití Koupit jízdenku . . . . Rozhraní pro vyhledávání spojení . . . . . . . . . . . . . . . Architektura systému . . . . . . . . . . . . . . . . . . . . . Mobilní rozhraní - Menu a Přihlašovací formulář . . . . . . Mobilní rozhraní - Výběr typu a začátku platnosti jízdenky Webové uživatelské rozhraní - Historie jízdenek . . . . . . . Webové uživatelské rozhraní - Zakoupení jízdenky . . . . . Uživatelské rozhraní desktopové aplikace . . . . . . . . . . .

xiii

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

5

15 16 17 17 19 21 21 22 22 23

xiv

SEZNAM OBRÁZKŮ

Seznam tabulek 3.1

Bezkontaktní komunikační API pro J2ME . . . . . . . . . . . . . . . . . . . . 11

xv

xvi

SEZNAM TABULEK

Kapitola 1

Úvod 1.1

Motivace

S technologií NFC jsem se setkal při práci ve firmě IMA s.r.o. a nadchla mě natolik, že jsem se s ní chtěl seznámit blíže. Při studiu různých materiálů o této technologii jsem se rozhodl, že v rámci seznamování bych rád vytvořil projekt využívající NFC v systému, který by mohl mít reálné využití. Díky právě probíhajícímu zavádění karet Opencard, které slouží také jako průkazka Pražské integrované dopravy, mě napadlo vytvořit podobný systém, který však využívá technologie NFC v mobilním telefonu. Mnoho společností provozujících hromadnou dopravu totiž začíná kromě klasických papírových jízdenek a kupónů nabízet možnost nákupu jízdenek elektronických. Důvodů vedoucích k tomuto kroku může být několik. Jedním je určitě snaha zpříjemnit služby zákazníkům, kteří mohou jízdenky koupit buď přes internet nebo pomocí mobilního telefonu, čímž se vyhnou frontě u prodejce nebo vůbec cestě k němu. Další motivací může být větší efektivita, a tedy nižší výdaje na pracovníky. Odpadá totiž fyzická distribuce jízdenek, nebo případné zadávání dat do počítače, které může provést sám zákazník. Tyto důvody jsou asi nejdůležitější, ale jistě by se našly i další. Řešení jednotlivých systémů se liší, stejně tak jejich výhody a nevýhody. Myslím si, že použití technologie NFC má několik výhod a snažím se to ukázat touto prací. Úvod do NFC technologie viz. kapitola 3.

1.2

Cíle

• Implementovat systém pro nákup elektronických jízdenek hromadné dopravy. • Umožnit nákup jízdenek pomocí mobilního telefonu. • Vhodně použít technologii NFC pro kontrolu jízdenek a jejich ukládání do mobilního telefonu. • Připravit mobilní telefon pro připojení systému vyhledávání spojů a využít ho při nákupu jízdenek.

1

2

KAPITOLA 1. ÚVOD

Kapitola 2

Úvodní studie 2.1

Odborný článek

Systém bude umožňovat nákup jízdenek pro hromadnou dopravu. Typy jízdenek budou podle platnosti jednorázové (30 a 60 minut) a časové (30, 90 a 365 dní). Cestující, který bude chtít nakupovat jízdenky se bude muset registrovat pomocí webové aplikace. Jeho účet bude obsahovat unikátní login a heslo pro přihlašování do systému, a dále jméno, příjmení, adresu a telefonní číslo. Tyto údaje, kromě loginu, bude možno změnit. Registrovaný cestující si bude moci vložit peníze na svůj účet a z něj nakupovat jízdenky, jak pomocí mobilního telefonu tak webové aplikace. Po zakoupení budou jízdenky uloženy do mobilního telefonu. Cestující si bude moci zobrazit jednak všechny zakoupené jízdenky ve webové aplikaci a také poslední jízdenky uložené v mobilním telefonu. Revizor bude kontrolovat platnost jízdenek, a to bez nutnosti připojení k internetu. Systém budou používat také dvě skupiny pracovníků: prodejci a administrátoři. Prodejci1 budou prodávat a nahrávat jízdenky do mobilních telefonů a také vkládat peníze na účty cestujících. Administrátor bude vkládat a případně měnit účty pracovníků, ty budou obsahovat pouze přihlašovací údaje, jméno a příjmení. Také budou měnit parametry jízdenek: cenu a maximální počet dní, který může být mezi aktuálním časem a začátkem platnosti požadované jízdenky. Systém také umožní nalezení spoje pomocí mobilního telefonu a doporučí zakoupení vhodné jízdenky. Systém však nebude implementovat samotné vyhledávání, pouze stanoví rozhraní pro externí systém. Systém musí zabezpečit, aby k jednotlivým službám mohl přistupovat pouze oprávněný uživatel (kontrola loginu a hesla). Informace přenášené přes síť musí být šifrované. Také jízdenky ukládané do telefonu musí být zabezpečeny proti padělání nebo duplikaci. Pro ukládání a kontrolu jízdenek bude systém používat technologii NFC.

1

Prodejcem je v tomto případě myšlen zaměstanec pracující na pobočce dopravního podniku. Nikoliv tedy externí pracovník, jako například trafikant.

3

4

KAPITOLA 2. ÚVODNÍ STUDIE

2.2

Případy užití a jejich scénáře

V této sekci jsou rozebrány scenáře případů úžití systému zobrazených na diagramu 2.1. Přihlásit se 1. Případ užití začíná ve chvíli, kdy uživatel chce provést akci, která je povolena jen určité skupině, a není přihlášen. 2. Uživatel zadá jméno a heslo. 3. Systém zkontroluje přihlašovací údaje. 4. Systém vytvoří relaci pro uživatele. Alternativní scénář: Pokud přihlašovací údaje nejsou správné, systém relaci nevytvoří a zobrazí varovnou hlášku. Odhlásit se 1. Uživatel vybere volbu Odhlásit se. 2. Systém zruší uživatelovu relaci. Registrovat se 1. Uživatel vybere volbu Registrovat se. 2. Systém zobrazí registrační formulář. 3. Uživatel vyplní údaje. 4. Systém zkontroluje vyplněné údaje. 5. Systém vytvoří uživateli účet patřící do skupiny Cestující. Alternativní scénář: Pokud ve čtvrtém kroku systém zjistí špatně vyplněné údaje, přejde na krok dvě a zobrazí popis chyb. Vyhledat spojení 1. Uživatel vybere volbu Vyhledat spojení. 2. Systém zobrazí formulář s detaily spojení. 3. Uživatel vyplní detaily spojení. 4. Systém vyhledá spojení a zobrazí ho.

2.2. PŘÍPADY UŽITÍ A JEJICH SCÉNÁŘE

5

Přihlásit se

Uživatel

Odhlásit se

Registrovat se

Neregistrovaný cestující Vyhledat spojení

Koupit jízdenku

Registrovaný cestující

Zobrazit jízdenky

Nahrát jízdenky

Zobrazit účet cestujícího

Vložit peníze Prodejce

Prodat jízdenku

Vytvořit uživatelský účet

Zobrazit uživatelské účty Administrátor Upravit uživatelský účet

Upravit parametry jízdenek

Obrázek 2.1: Diagram případů užití

Koupit jízdenku 1. Uživatel vybere volbu Koupit jízdenku.

6


2. Systém zobrazí dostupné jízdenky. 3. Uživatel vybere požadovanou jízdenku a zadá začátek platnosti. 4. Systém zkontroluje jestli je začátek platnosti v povoleném intervalu a zda má uživatel dostatečný zůstatek na účtu. 5. Systém odečte cenu jízdenky ze zůstatku a uloží ji jako připravenou k nahrání. Nahrát jízdenky 1. Tento případ užití začíná v případě, že uživatel vybere volbu Nahrát jízdenky, nebo pokud byl právě ukončen případ užití Koupit jízdenku aktivovaný z mobilního telefonu. 2. Systém nahraje zakoupené jízdenky připravené k nahrání do mobilního telefonu. Zobrazit jízdenky 1. Uživatel vybere volbu Zobrazit jízdenky. 2. Systém zobrazí všechny zakoupené jízdenky uživatele. Alternativní scénář: Pokud je tato volba aktivována z mobilního telefonu, systém zobrazí pouze jízdenky nahrané v telefonu. Zobrazit účet cestujícího 1. Tento případ užití začíná pokud uživatel zadá login nebo příjmení cestujícího, nebo přiloží telefon ke čtečce. 2. Systém zobrazí zakoupené jízdenky uživatele a jeho zůstatek na účtu. Vložit peníze 1. Tento případ užití začíná po případu užití Zobrazit účet cestujícího, pokud uživatel vybere volbu Vložit peníze. 2. Uživatel zadá částku, která se má vložit. 3. Systém přidá částku na účet cestujícího. Prodat jízdenku 1. Tento případ užití začíná po případu užití Zobrazit účet cestujícího, pokud uživatel vybere volbu Prodat jízdenku. 2. Systém zobrazí dostupné jízdenky. 3. Uživatel vybere požadovanou jízdenku, zadá začátek platnosti. 4. Systém uloží jízdenku. Pokud je telefon u čtečky, nahraje ji do telefonu, jinak ji označí jako připravenou k nahrání.

2.3. REŠERŠE EXISTUJÍCÍCH IMPLEMENTACÍ

7

Vytvořit uživatelský účet 1. Uživatel vybere volbu Vytvořit uživatelský účet. 2. Systém zobrazí formulář pro uživatelský účet. 3. Uživatel zadá údaje účtu. 4. Systém zkontroluje vyplněné údaje. 5. Systém vytvoří uživatelský účet. Alternativní scénář: Pokud ve čtvrtém kroku systém zjistí špatně vyplněné údaje, přejde na krok dvě a zobrazí popis chyb. Zobrazit uživatelské účty 1. Případ užití nastává pokud uživatel přejde na administraci nebo zvolí volbu Zobrazit uživatele. 2. Systém zobrazí seznam uživatelských účtu s jejich příslušnostmi ve skupinách. Upravit uživatelský účet 1. Uživatel vybere uživatelský účet k editaci. 2. Systém zobrazí formulář s uživatelským účtem. 3. Uživatel změní údaje. 4. Systém zkontroluje vyplněné údaje. 5. Systém aktualizuje uživatelský účet. Upravit parametry jízdenek 1. Uživatel vybere volbu Upravit parametry jízdenek. 2. Systém zobrazí formulář se seznamem typů jízdenek. 3. Uživatel upraví parametry. 4. Systém aktualizuje typy jízdenek.

2.3

Rešerše existujících implementací

Systémů pro elektronické jízdné, které se v České republice i v ostatních zemích zavádějí, je více. Principy se však opakují, vybral jsem proto asi dva nejznámější systémy v České republice.

8


2.3.1

Systém Dopravního podniku hlavního města Praha

Tento systém obsahuje dva oddělené typy elektronických jízdenek. První je SMS-jízdenka, tu je možno zakoupit odesláním SMS zprávy na dané telefonní číslo. Systém poté pošle zpět SMS zprávu (jízdenku), která obsahuje rozsah platnosti a unikátní posloupnost znaků (zřejmě nějaký hash), podle kterého je možné zkontrolovat pravost jízdenky. Zaplacení jízdenky probíhá tím, že odeslání prvotní zprávy je zpoplatněno operátorem podle ceny jízdenky. Tento způsob nákupu jízdenek je podle mého názoru velmi povedený, nevyžaduje totiž instalaci softwaru nebo speciální nastavení mobilního telefonu, dokonce ani nevyužívá připojení k internetu, placení je také velmi pohodlné. Na druhou stranu není vhodný pro jízdenky s delší platností (v Praze je možno zakoupit pouze klasickou jízdenku na 60 minut). Jednak uchovávat SMS zprávu v telefonu týdny nebo měsíce není úplně uživatelsky přívětivé hlavně pro ty, kterým chodí desítky zpráv denně. Navíc zpráva ne vždy dojde, což by bylo nepříjemné v případě jízdenky v řádu stovek korun. A v neposlední řadě, řádná kontrola těchto jízdenek je zdlouhavá, jelikož je zřejmě nutné on-line porovnat dlouhý řetězec znaků s tím uloženým v systému.2 Druhý typ elektronických jízdenek je určen pro jízdenky s delší platností (tedy nahrazuje tzv. tramvajenku). Jízdenky je možno zakoupit v internetovém obchodě3 a poté je pomocí tzv. validátorů nahrát na smart kartu Opencard. Kontrola jízdenek pak probíhá přiložením karty ke čtečce revizora, která mu ukáže nahrané jízdenky. Kontrola jízdenek tedy probíhá zřejmě off-line.4 Asi jediná nevýhoda tohoto systému je nutnost nahrání jízdenky pomocí validátoru, které se nalézají pouze na několika místech.

2.3.2

Systém Dopravního podniku města České Budějovice

Tento systém umožňuje také nákup SMS-jízdenek podobně jako předchozí. Druhým typem jízdenky je Datová jízdenka, ta se také nakupuje pomocí mobilního telefonu. Systém funguje tak, že uživatel si u dopravní společnosti vytvoří účet a na něj vloží peníze. Poté si nahraje do mobilního telefonu aplikaci, která při nákupu komunikuje se serverem přes internet. Jízdenka se nahrává do paměti telefonu a je přístupná z aplikace. Pravost jízdenky se ověřuje opět unikátní posloupností znaků. Výhodami tohoto přístupu oproti SMS-jízdence jsou jednak nižší náklady pro dopravní společnost (neplatí operátorovi za výběr poplatku), a pro uživatele, že jízdenky nejsou uloženy mezi zprávami SMS. Nevýhodou je opět složitější kontrola jízdenek a také nutnost instalace aplikace, atd.

2

Byl jsem osobně několikrát kontrolován s SMS-jízdenkou, ale nikdy revizor pravost jízdenky podle zmíněné posloupnosti znaků nekontroloval. V případě absence této kontroly, jde vcelku jednoduše vytvořit padělek. 3 Samozřejmě je možné zakoupit jízdenky pro Opencard také klasicky u přepážky. 4 Je to pouze můj předpoklad, ale nevidím důvod, proč by tomu mělo být jinak.

Kapitola 3

Technologie NFC 3.1

Základní informace

NFC technologie umožnující bezdrátový datový přenos na velmi krátkou vzdálenost (do 10 cm) je standardem definovaným konsorciem NFC forum. NFC operuje na frekvenci 13.56 MHz a podporuje několik již zavedených ISO standardů jako ISO 14443 typu A a B nebo Felica. Ty jsou definovány pro bezdotykové Smart karty a tagy používané např jako platební karty (běžné např. v USA nebo Japonsku) nebo přístupové karty. To umožňuje použít NFC i v systémech, které jsou již zavedené. Součástí specifikace jsou také komunikační módy a formát přenášených dat NDEF pro URI, Chytré plakáty (Smart Posters) a další, viz. [8]. Při komunikaci dvou NFC zařízení je většinou jedno zařízení aktivní a druhé pasivní. Aktivní je čtečka, která má vlastní napájení, a pasivní je karta nebo tag, který většinou vlastní napájení nemá a využívá energii z radiových vln vysílaných aktivním zařízením. Přitom aktivní zařízení vysílá požadavky a pasivní odpovědi. V tomto přístupu je velkou výhodou právě to, že pasivní prvek nepotřebuje vlastní zdroj energie.

3.2

Vize technologie

Velký potenciál této technologie spočívá v předpokladu, že bude podporována v mobilních zařízeních, přesněji v mobilních telefonech. V tuto chvíli je implementována pouze v pár modelech, ale do budoucna se počítá s rozmachem. NFC forum specifikuje tři komunikační mody: peer-to-peer, čtení/zápis a NFC emulace karet. Z posledního modu vyplývá, že může nahradit a seskupit do jednoho telefonu již existující platební, přístupové a další karty. Druhý mód otevírá plno nových možností, mobilní telefon může sloužit jako čtečka karet např. na kontrolu jízdenek. Současné ceny a velikosti některých karet jako třeba Mifare Ultralight, která může mít podobu nálepky o velikosti několika čtverečních centimetrů, umožnují vytvořit třeba plakáty na koncert, v kterých bude uložen hypertextový odkaz, a pomocí kterého si objednáme lístky pouhým přiložením mobilního telefonu k plakátu. Podobné možnosti má například bluetooth, ale velkou výhodou NFC je, že tagy mohou být pasivní, a navíc je můžeme jednoduše aktivovat právě pouhým přiložením telefonu. Ve světě probíhá řada pilotních programů s touto technologií, od menších, kde telefon slouží jako alternativa k bezkontaktním kartám, až k inteligentním městům, kde je možno telefonem platit v obchodě,

9

10

KAPITOLA 3. TECHNOLOGIE NFC

dopravních prostředcích, v automatu na kávu nebo třeba získat slevový kupón na zboží přiložením telefonu k reklamě na ulici.

3.3

Smart karty a tagy

Smart karty1 jsou karty s integrovanými obvody, které mohou zpracovávat data. U nás jsou zatím běžnější kontaktní, klasické platební nebo telefonní karty, bezkontaktní se v tuto chvíli používají nejčastěji jako přístupové karty (např. ČVUT - karty Mifare), ale začínají se využívat například i v dopravních prostředcích (Opencard - Desfire). Technologie NFC využívá, jak je zřejmé, ty bezkontaktní. Smart karty se dají také rozdělit na pouze paměťové, které slouží pro ukládání dat maximálně s možností stanovení přístupových práv, a na karty s mikroprocesorem. Ty umožňují tvorbu komplexnějších aplikací a šifrování. Některé mají celou funkcionalitu vytvořenou výrobcem, jako již zmíněné karty Desfire, do jiných je možno ji vložit přesně podle potřeb systému. To je možné například pomocí appletů využívajících Java Card API, jehož specifikace byla vytvořena firmou SUN právě pro tyto karty. Rozhraní používá malou podmnožinu jazyka Java a je zaměřeno na jednoduché výpočty a podporu šifrovacích algoritmů. Paměť na smart kartách vyhrazená pro tyto applety je v řádek desítek KB. Pro komunikaci mezi čtečkou a smart kartou se používá APDU protokol specifikovaný v ISO 7816-4. Čtečka vysílá příkazy, které se skládají z povinné hlavičky (5B) obsahující jako druhý byte číslo instrukce (další parametry nejsou v tuto chvíli podstatné) a nepovinné datové části (0-255B). Karta vrátí odpověď skládající se z povinného statusu úspěšnosti (2B) a nepovinných dat (0-256B). Čísla instrukcí jsou dána jednak specifikací, výrobcem karty, a také tvůrcem appletu. Tagem je v tomto kontextu myšlen nějaký integrovaný obvod, v kterém jsou uložena malá data. Většinou není třeba, aby měl nějaká přístupová práva nebo šifrování, někdy jsou data dokonce „zadrátována“ přímo při výrobě a jsou jen pro čtení. Může to být RFID tag, ale samozřejmě i smart karta, (což je samozřejmě plýtvání prostředky pokud například uchovává pouze hypertextový odkaz).

3.4

NFC v mobilních telefonech

Hlavním průkopníkem NFC na poli mobilních telefonů je firma Nokia. Ta implementovala tuto technologii zatím do dvou telefonů, které jsou v prodeji. Tato firma je také vedoucí v tvorbě specifikace pro bezkontaktní komunikační API pro J2ME, které je vytvořeno také pro potřeby NFC. Ta je definována pod Java Community Process jako JSR-257 a v tuto chvíli obsahuje balíčky uvedené v tabulce 3.4. MIDlet běžící v prostředí Java s implementovaným rozhraním JSR-257 může komunikovat s externími nebo interními Secure elementy, což jsou různé typu Smart karet, a to pomocí ISO14443Connection a APDU příkazů nebo jinými externími tagy, které většinou úchovávají informace v NDEF formátu. Naopak externí čtečky můžou komunikovat s interním Secure elementem, jenž emuluje buď Smart kartu nebo tag. Komunikace mezi jednotlivými rozhraními je zobrazena na obrázku 3.1. 1

Pro smart karty se v češtině používá také výraz čipové karty.

3.4. NFC V MOBILNÍCH TELEFONECH

Java balíčky javax.microedition.contactless Povinný balíček obsahující nástroje pro nalezení cílových zařízení a nástroje společné pro všechny cíle. javax.microedition.contactless.ndef Volitelný balíček pro práci s tagy obsahující data v NDEF formátu. javax.microedition.contactless.rf Volitelný balíček pro komunikace s RFID tagy, které nemají data v NDEF formátu. javax.microedition.contactless.sc Volitelný balíček definovaný pro komunikaci se Smart kartami. javax.microedition.contactless.visual Volitelný balíček pro čtení a vytváření vizuálních tagů.

11

Rozhraní TagConnection TargetListener TargetProperties TransactionListener NDEFRecordListener NDEFTagConnection

ISO14443Connection

ImageProperties VisualTagConnection TargetProperties

MIDlet

Externí čtečka JSR 257 APDU

APDU Smart karta

RFID, NFC, Řadič, Anténa

NDEFMessage NDEFRecord NDEFRecordType

PlainTagConnection

Tabulka 3.1: Bezkontaktní komunikační API pro J2ME

SIM karta

Třídy DiscoveryManager TargetType

Externí Secure element

Externí tag

Obrázek 3.1: MIDlet a bezkontaktni komunikační API

SymbologyManager

12

3.5

KAPITOLA 3. TECHNOLOGIE NFC

Bezpečnost

Členy NFC fóra jsou jak společnosti zabývající se technologiemi platebních karet, tak i banky. Počítají s použitím této technologie na platební transakce, a proto je bezpečnost jednou z priorit. Přesto, že komunikace probíhá na velmi krátké vzdálenosti, pole, v kterém lze odchytit komunikaci (nebo dokonce, v některých případech i změnit znění zprávy), je větší. Tato vzdálenost samozřejmě závisí na mnoha faktorech od parametrů konkrétního zařízení až po vlastnosti prostředí, nicméně pro základní představu je pro aktivní zařízení kolem 10 metrů a pro pasivní 1m. Kódování použitá pro komunikaci (Millerovo nebo Manchesterské) jsou obecně známá, hrozba odposlouchávání a následného rozkódování zpráv na úrovni radiových vln je tudíž reálná a v případě, že jsou posílána citlivá data, je nutno zajistit jejich šifrování na vyšší vrstvě. V případě smart karet je možno použít různé obecně známe šifrovací algoritmy a autentizaci čtecího zařízení. Výhodou NFC je, že není prakticky možné použít útok „man in the middle“, který je hrozbou u asymetrického šifrování, jak je dokázáno v [1]. Co se týče secure elementu v podobě smart karty v mobilním telefonu, je zde několik bezpečnostních opatření garantovaných výrobcem. Applety do něj může nahrávat pouze důvěryhodná třetí strana, které výrobce telefonu poskytne klíče k secure elementu. Výrobce appletu (potažmo aplikace, která ho využívá,) ho předá třetí straně, která ho po kontrole na požádání distribuuje do mobilních telefonů (pomocí šifrovaného kanálu přes internet). Tím je jednak zaručena nezávadnost appletu a také to, že se applet nedostane do rukou útočníka, který by mohl zjistit jeho funkcionalitu, případně nějaké klíče. Další opatření je, že MIDlet se k internímu secure elementu může připojit jen v případě, že je podepsán certifikátem důvěryhodných certifikačních autorit, jako je např. Verisign nebo Thawte.

Kapitola 4

Analýza a návrh řešení 4.1 4.1.1

Ukládání jizdenky do telefonu Analýza možných řešení

Systémy uvedené v řešerši 2.3 používají pro uložení jízdenky do mobilního telefonu dva způsoby. Jednak uložení jako SMS nebo uložení v mobilní aplikaci, tedy nejspíš pomocí Record management store. Jízdenky je tedy možné zobrazit pouze v telefonu, kde jsou uložené. Aby nebylo možné tyto jízdenky podvrhnout, vytvořením stejně vypadající SMS nebo mobilní aplikace, jsou jízdenky opatřeny otiskem. Ten je buď možné zkontrolovat dotazem na server, který jízdenky generuje, zda otisk náleží platné jízdence, nebo zadáním parametrů jízdenky do hashovací funkce v nějakém mobilním zařízení, které otisky generuje. Nevím, který z těchto způsobů se opravdu používá, ale oba jsou vcelku náročné a zdlouhavé. Což může způsobit, jak bylo již zmíněno v rešerši, že revizor otisk nebude vůbec kontrolovat. Navíc je tu možnost zakoupit jednu jízdenku a vytvořit podvrhy v jiných telefonech zkopírováním údajů. To by se dalo vyřešit zahrnutím údaje jednoznačně identifikující mobilní telefon do otisku. Tím by mohlo být třeba telefonní číslo, ale sdělovat takovýto údaj revizorovi by bylo pro cestující zřejmě nepříjemné, možná i nezákonné. Systémy však tyto způsoby používají pro prodej jízdenek s platností maximálně na několik hodin. V takovém případě je tento způsob padělání velmi neefektivní, nícméně u jízdenek s platností v řádu měsíců, jako v navrhovaném systému, by mohl být problémem. Systém Opencard využívá k uložení jízdenek čipovou kartu. Tento způsob by měl být bezpečný, jelikož pro přístup k datům jsou potřeba klíče a komunikaci je možné šifrovat. Kontrola jízdenek uložených na kartě je velmi pohodlná, spočívá v pouhém přiložení karty ke čtečce. Nepříjemností však je nahrávání jízdenek na kartu, které je možné jenom pomocí speciálních zařízení. V případě, že by tento systém měl být využit pro jízdenky z krátkou dobou platností, bylo by nutné použít jinou strategii. Například by se uživatel při vstupu a výstupu z dopravního prostředku identifikoval u čtečky. Čtečky by posílaly informace po síti do systému, který by následně vyhodnotil délku cesty a podle ní odečetl jízdné z uživatelova účtu1 . To by však znamenalo nutnou instalaci čtecích zařízení do všech dopravních prostředků. 1

Podobný systém se zavádí pro vlakovou dopravu v Německu.

13

14

4.1.2

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ

Ukládání jízdenek a NFC

Systém Opencard byl zmíněn, přestože mobilní telefon nepoužívá. Technologie NFC totiž vkládá do telefonu funkcionalitu čipových karet. Proto její využití bude mít výhody obou předešlých řešení. V telefonech s technologií NFC jsou většinou emulovány různé typy čipových karet, jako například karta Mifare v telefonu Nokia 6131 NFC[7]. Karta Mifare by byla použitelná pro ukládání jízdenek a implentace by byla jednodušší, protože přístup k ní je možný z vyšší úrovně než jen APDU příkazy. Nicméňe standardizované ovládání je pouze pomocí APDU příkazů. Vzhledem k povaze systému, který by měl fungovat na co nejvíce mobilních telefonech, je tedy žádoucí použít standardizované rozhraní. S tím je spojena implementace vlastního appletu pro platformu JavaCard, který bude nainstalován v secure elementu.

4.1.3

Návrh bezpečného uložení

Z principu secure elementu vyplývá, že pokud je spravován důvěryhodnou třetí stranou, data v něm uložená jsou v bezpečí. V případě uložení jízdenek jsou zde dva kritické momenty: nahrávání a kontrola jízdenky. Při nahrávání jízdenek musí applet ověřit, zda byla jízdenka opravdu vygenerována systémem. To je možné vyřešit připojením otisku z dat jízdenky. Klíč, který bude tento otisk vytvářet, bude uložen na serveru a v secure elementu. Aby nebylo možné takto vygenerovanou jízdenku použít pro jiný telefon, klíč bude unikátní pro každý applet resp. telefon. Při žádosti o nahrání jízdenky bude na server odesláno identifikační číslo secure elementu, podle kterého bude vybrán příslušný klíč. Vzhledem k požadavku kontroly jízdenky bez připojení k síti a faktu, že ke kontrole bude používán také mobilní telefon s technologií NFC, není možné použít podobný postup jako v případě nahrávání. Telefon revizora by totiž musel mít přístup k databázi klíčů. To vyžaduje buď přístup k serveru nebo lokální uložení databáze, což vzhledem k omezené kapacitě mobilního telefonu není možné. Nicméně lze využít faktu, že jízdenka uložená v telefonu je pravá, díky postupu popsanému výše. Zbývá tedy ověřit pravost appletu v secure elementu. To proběhne tak, že telefon revizora pošle náhodné číslo. Secure element z něj vytvoří otisk a pošle ho zpátky k ověření. Klíč použitý pro tento otisk bude stejný pro všechny applety. Aby se zamezilo snaze vygenerovat všechny otisky, před touto kontrolou proběhne stejný proces identifikace telefonu revizora. Klíče budou do secure elementu nahrány při instalaci appletu. Klíče v telefonu revizora budou uloženy v aplikaci. Přestože by nemělo být možné dostat se ke kódu, již nainstalované aplikace v mobilním telefonu, není to vždy zaručeno. Proto by bylo lepší klíče v telefonu revizora uložit do secure elementu a zabezpečit je pinem. Toto bude však ponecháno pro budoucí vývoj.

4.2

Základní třídy v systému

Analýzou požadavků na systém vzniklo několik tříd, ty jsou zobrazeny na diagramu 4.1. Jsou zde vidět základní vlastnosti tříd a jejich vztahy. Většina vlastností je zřejmá z diagramu, přesto je uveden jednoduchý slovní popis tříd s případným upřesněním atributů, jejichž jména by mohla být zavádějící.

4.2. ZÁKLADNÍ TŘÍDY V SYSTÉMU

15

<> UzivatelController

<> CestujiciController

<> JizdenkyController

existujeLogin() : boolean vytvoritUzivatele() : void smazatUzivatele() : void getUzivatele() : Uzivatel getCollUzivatele() : Collection upravitUzivatele() : void

vytvorCestujiciho() : void getCestujiciho() : Cestujici getCollJizdenky() : Collection getJizdenkyKNahrani() : Collection vlozitJizdenku() : void vlozitPenize() : void upravitCestujiciho() : void vyhledatCestujiciho() : void

getDostupneJizdenky() : Collection upravitTypyJizdenek() : void getTypyJizdenek() : void

<<entity>> Skupina jmeno : String

1..* 0..*

<<entity>> Uzivatel

<<entity>> TypJizdenky

login : String password : String jmeno : String prijmeni : String

nazev : String cena : int id : byte pocetDniPredPlatnosti : int

1 0..* <<entity>> Adresa ulice : String psc : String mesto : String

1

1

<<entity>> Cestujici stavUctu : long cisloKarty : long telefoniCislo : String

<<entity>> Jizdenka 1

0..*

zacatekPlatnosti : Date nakupniCena : int nahrana : boolean

Obrázek 4.1: Diagram tříd

Uzivatel a Skupiny Tyto třídy slouží k uložení dat pro identifikaci uživatele systému a zjištění jeho práv. Skupiny vyplývají z požadavků: administrátoři, prodejci a cestující. Budou tedy zavedeny při instalaci systému a nebude je možné měnit.

Cestujici a Adresa Tyto třídy slouží k uložení informací o uživatelích, kteří patří do skupiny cestující. Atribut cisloKarty je identifikační číslo appletu v secure elementu mobilního telefonu. Adresa je modelována jako samostatná entita pro případ, že by bylo nutno v budoucnu k cestujícímu přiřadit více adres.

TypJizdenky Třída reprezentuje typy jízdenek, které je možno nakupovat. Ty jsou dány zadáním, proto budou zavedeny při instalaci systému, ale bude možno u nich měnit atributy cena a pocetDniPredPlatnosti, který reprezentuje povolenou dobu mezi začátkem platnosti jízdenky a časem, kdy je kupována.

16


Jizdenka Tato třída reprezentuje zakoupenou jízdenku. Atribut cena je zde proto, že cena jednotlivých typů jízdenek se může měnit a je tedy třeba zachovat cenu, která byla za konkrétní jízdenky reálně zaplacena. Atribut nahrana slouží k indikaci, zda byla již jízdenka nahrána do telefonu. UzivatelController Tato třída zajišťuje funkcionalitu spojenou se správou uživatelských účtů, bude tedy využívána převážně administrátorem. CestujiciController Třída zajišťuje funkcionalitu spojenou s účty cestujících a nákupem jízdenek. Bude tedy využívána cestujícím a prodejcem. JizdenkyController Tato třída zajišťuje funkcionalitu spojenou s typy jízdenek. Bude tedy využívána především administrátorem, ale také dalšími uživateli při nákupu jízdenek.

4.3

Sekvenční diagramy

Sekvenční diagramy byly vytvořeny pro složitější případy užití. Uvedeny jsou pouze dva, aby nebyla snížena čitelnost textu.

Obrázek 4.2: Sekvenční diagram pro případ užití Registrovat se

4.4. ROZHRANÍ PRO JÍZDNÍ ŘÁDY

17

Obrázek 4.3: Sekvenční diagram pro případ užití Koupit jízdenku

4.4

Rozhraní pro jízdní řády

Systém bude používat jízdní řády pouze k doporučení vhodné jízdenky. Není tedy třeba, aby zpracovával ostatní informace o nalezeném spoji, pouze je vypíše v textovém formátu uživateli. Proto vytvoření textového výpisu bude přenecháno externímu systému. Rozhraní je zobrazeno na obrázku 4.4. Toto rozhraní bude v mobilní aplikaci a při jeho implementaci <> vyhledavacSpojeni vyhledatSpojen() : boolean vyhledatDalsi() : boolean setPocatecniStanice() : void setCilovaStanice() : void setDatumCas() : void getMinutySpoje() : int getPopisSpoje() : String getPopisChyby() : String

Obrázek 4.4: Rozhraní pro vyhledávání spojení

18


bude nutné vložit modul externího systému do instalačního balíčku. Externí systém však, vzhledem k jeho povaze, bude ve většině případů služba dostupná přes internet. Proto bude toto rozhraní implementováno s využitím XML-RPC a pomocí tohoto protokolu vytvořeno další podobné rozhraní. V tomto případě by k externímu systému byla pouze vytvořena webová služba komunikující pomocí stejného protokolu.

4.5

Architektura systému

Systém bude mít tři uživatelská rozhraní: • webové - pro cestující a administrátora • desktopová aplikace - pro prodejce • mobilní aplikace - také pro cestující Použití webového rozhraní jednak vyplývá ze zadání a navíc je vhodné, protože uživatel může aplikaci obsluhovat odkudkoli z osobního počítače, který je připojen na internet. Důvodem pro zvolení desktopové aplikace pro prodejce byla potřeba přístupu ke čtečce při nahrávání jízdenek do telefonu. Přístup z webové aplikace k periferiím je sice možný, ale bývá poměrně problematický. Prodejci budou navíc aplikaci používat stále ze stejného místa a nebudou tedy omezováni instalací aplikace na určitém počítači. Pro přístup k systému z mobilního telefonu byla zvolena mobilní aplikace. Přístup k technologii NFC je totiž zatím možný pouze z Java aplikace. Právě použití více uživatelských rozhraní je jedním z důvodů proč systém bude implementován pomocí n-vrstvé architektury, zobrazené na diagramu 4.5. Bussines logika, která bude komunikovat s databází, bude nasazena v samostatném kontejneru. Další komponenty budou volat její funkce a přímo je zobrazovat, jako desktopová aplikace, nebo je dále použijí ve svých funkcích, jako webová logika. Tímto přístupem se zamezí opakování kódu v různých komponentách. Tato architektura má i další výhody, např. zjednodušení dalšího vývoj systému nebo jeho lepší škálovatelnost.

4.6 4.6.1

Výběr implementačního prostředí a komunikačních protokolů Implementační prostředí

Pro serverovou část systému je zvolena platforma J2EE viz.[4] a to konkrétně technologie EJB 3.0, JPA a JSF. Důvodem je, že tato platforma má velmi dobrou podporu pro vývoj vícevrstvých aplikací a zjednodušuje vývoj díky podpoře častých úkonů. Těmi jsou např. autentizace a řízení přístupu, řízení transakcí nebo persistence dat. Většinu těchto úkonů je možno řídit deklarativně pomocí anotací. Technologie EJB slouží k tvorbě bussines logiky. JPA obsluhuje entity, tedy perzistenci dat. JSF je nadstavba JSP a slouží k tvorbě webového rozhraní. K JSF existují alternativy, které jsou mnohem pokročilejší. Tato technologie je použita, protože webové rozhraní tohoto systému nepotřebuje žádné speciální funkce a práce

4.6. VÝBĚR IMPLEMENTAČNÍHO PROSTŘEDÍ A KOMUNIKAČNÍCH PROTOKOLŮ19

PC

0..*

<>

1

Webový prohlížeč

Webový kontejner Webová logika

0..*

<>

Webová služba 1

Mobilní telefon 1

Mobilní aplikace

1

Bussines kontejner PC

0..*

<>

1

Bussines logika

Desktopová aplikace Entity

1 <<SQL>> 1

Databáze Tabulky

Obrázek 4.5: Architektura systému

s JSF je příjemná. K volbě platformy J2EE, také přispěl fakt, že software potřebný k tvorbě a běhu jejích aplikací je dostupný zdarma. Vzhledem k volbě serverové části systému je vhodné k implementaci desktopové aplikace pro prodejce použít opět jazyk Java, konkrétně platformu J2SE viz.[5]. Ta umožňuje jednoduché volání bussines logiky pomocí Java RMI. Navíc v součinosti z J2EE je možné vytvořit tzv. aplikačního klienta, který odsťiňuje prográmátora i od RMI, tím že při nasazení enterprise aplikace je vytvořen lightweight kontjner, který se následně nainstaluje spolu s aplikačním klientem. Pro mobilní aplikaci musí být použita platforma J2ME, jelikož v tuto chvíli není možné používat NFC technologii v mobilním telefonu z jiného prostředí. Nicméně J2ME poskytuje všechny potřebné prostředky jako komunikaci přes https nebo jednoduchou tvorbu GUI. Dalším kladem je jednoduchá přenositelnost MIDletů, která je však zatím limitována nízkým počtem telefonů podporujících NFC. Pro tvorbu uživatelského rozhraní budou použity standardní komponenty, jejichž vzhled není striktně určen normou a závysí na výrobci telefonu. Tento způsob je vhodný z pohledu výkonnosti a přenositelnosti, nicméně rozhraní

20


bude vypadat na různých telefonech odlišně.

4.6.2

Komunikační protokoly

Komunikaci mezi jednotlivými komponentami systému bude většinou probíhat přes veřejnou síť internet. Je proto nutné, aby informace byly při přenosu šifrovány a nemohly být zneužity nepovolanou osobou. Komunikace bude probíhat přes protokol SSL, který poskytuje bezpečné šifrování. Volba protokolů http (webové rozhraní) a RMI (desktopová aplikace) byla jednoduchá. Http je klasický a rozšířený protokol pro přístup k webovým stránkám a není důvod používat jiný. Použití protokolu RMI je implementačně jednoduché a výkonnostně efektivní. Má pouze nevýhodu, že je spjat s určitou technologií (v tomto případě Java) a že je někdy třeba upravit nastavení firewallů, aby nebyla komunikace blokována. Nicméně desktopová aplikace bude instalována pouze u prodejců, kde je možno prostředí počítačů a sítě upravit. Tím jsou zmíněné problémy nepodstatné. Pro komunikaci mezi mobilní aplikací a serverem bude použit protokol XML-RPC. Další možné varianty by byly: RMI, SOAP, vlastní protokol. První alternativa není vhodná, protože v budoucnu vyrobené telefony podporující NFC nemusí podporovat J2ME. Proto v případě tvorby mobilní aplikace pro jinou platformu by bylo nutné vytvořit další rozhraní na straně serveru. Tento problém by vyřešilo použití dalších dvou zmíněných alternativ. Tvorba vlastního protokolu nad protokolem TCP by bylo zbytečně náročné. SOAP je podobný protokolu XML-RPC a má větší možnosti. Nicméně jeho nároky na přenášená data jsou větší, což je při komunikaci přes mobilní síť podstatný nedostatek. XML-RPC je kompromisem mezi těmito variantami z pohledu přenositelnosti, náročnosti implementace a velikosti přenášených dat.

4.7. NÁVRH UŽIVATELSKÉHO ROZHRANÍ

4.7 4.7.1

21

Návrh uživatelského rozhraní Mobilní rozhraní

Vzhledem k volbe implementacního prostredí pro uživatelské rozhraní mobilní aplikace, a tedy k faktu, že bude vypadat odlišne na ruzných telefonech, rozhraní neobsahuje specialní grafické prvky a je strukturováno do jednoduchých obrazovek. Náhledy vybraných obrazovek jsou na obrázku 4.6 a 4.7.

Obrázek 4.6: Mobilní rozhraní - Menu a Přihlašovací formulář

Obrázek 4.7: Mobilní rozhraní - Výběr typu a začátku platnosti jízdenky

22

4.7.2


Webové rozhraní

Webové rozhraní má jednoduchý přehledný design podobný běžným webovým stránkám, aby se uživatel mohl rychle zorientovat. V levé části je umístěno menu a vpravo obsah dané stránky. Ukázkové stránky jsou na obrázku 4.8 a 4.9.

Obrázek 4.8: Webové uživatelské rozhraní - Historie jízdenek

Obrázek 4.9: Webové uživatelské rozhraní - Zakoupení jízdenky

4.7. NÁVRH UŽIVATELSKÉHO ROZHRANÍ

4.7.3

23

Desktopové rozhraní

Uživatelské rozhraní desktopové aplikace je složeno z běžných komponent. Důraz je kladen na přehlednost a jednoduchost. Aplikaci budou využívat prodejci a nikoliv zákazníci, proto není nutné vytvářet příliš atraktivní design. Ukázka rozhraní je na obrázku 4.10.

čer ven

Obrázek 4.10: Uživatelské rozhraní desktopové aplikace

24


Kapitola 5

Implementace V této kapitole jsou popsány základní rysy implementace jednotlivých částí systému a případná řešení problémů, které se při ní vyskytly.

5.1

Mobilní aplikace

Pro mobilní aplikaci pro revizora byla použita část kódu z aplikace pro cestující. Proto je dále popsána struktura aplikace cestujícího. Pouze bylo nutné přidat metody pro autentizaci secure elementu. Ty využívají knihovnu Bouncy Castle Crypto API viz.[2], jelikož platforma J2ME nemá standardní API pro kryptografii. Pro obě aplikace byla použita knihovna kXMLRPC viz.[6] pro volání logiky serveru. Mobilní aplikace obsahuje tři balíčky: • Balíček jizdenky obsahuje potomka třídy javax.microedition.midlet.Midlet a třídu Jizdenka, která má metody pro porovnávání jízdenek a jejich textový výpis. • Balíček gui obsahuje třídy uživatelského rozhraní. Pro každou obrazovku je vytvořena samostatná třída, která je potomkem tříd z balíčku javax.microedition.lcdui Form nebo List . Ta obsluhuje události, které jsou generovány prvky na dané obrazovce. Každá obrazovka má uložen odkaz na svého předchůdce, aby bylo možné se ve struktuře pohybovat i zpět. • Balíček util obsahuje pomocné třídy. Mezi nejdůležitější patří ISO14443ConnectionUtil a CekaciObrazovka, popsáné dále.

5.1.1

ISO14443ConnectionUtil

Tato třída obsluhuje komunikaci se secure elementem, především její navázání. Metody pro vytvoření spojení jsou pro aplikaci cestujícího a revizora rozdílné. V případě cestujícího se navazuje spojení s vnitřním secure elementem, ke kterému je třeba pouze získat adresu od prostředí a metoda je proto jednoduchá:

25

26

KAPITOLA 5. IMPLEMENTACE

public static ISO14443Connection getISO14443ConnectionToInnerCard() { Connection con = Connector.open(System.getProperty("internal.se.url")); return (ISO14443Connection) con; } U revizora je však nutno získat spojení s vnějším secure elementem ve chvíli, kdy je v blízkosti telefonu. To je možné díky třídě javax.microedition.contactless.DiscoveryManager, u které je třeba zaregistrovat posluchače, jehož metoda targetDetected je zavolána v případě detekce nějaké karty. Parametrem této metody je seznam vlastností nalezených karet, v tomto seznamu je nutné nalézt požadovanou kartu a vytvořit s ní spojení: public static ISO14443Connection getISO14443Con(TargetProperties[] tProp) { for (int j = 0; j < tProp.length; j++) { Class[] connections = tProp[j].getConnectionNames(); if (connections != null) { for (int i = 0; i < connections.length; i++) { if (connections[i].getName().indexOf("ISO14443Connection") != -1) { Connection con = Connector.open(tProp[0].getUrl(connections[i])) return (ISO14443Connection) con; } } } } return null; } Po navázání spojení je volána metoda doSelect, která pošle kartě APDU příkaz pro výběr JavaCard appletu1 . Následná komunikace již slouží k provedení samotné požadované akce, jako je nahrání jízdenky.

5.1.2

Třída CekaciObrazovka

Komunikace se secure elementem nebo serverem jsou blokující a můžou někdy trvat déle. Proto bylo nutno vytvořit třídu CekaciObrazovka, která kromě upozornění uživatele na déle trvající operaci umožní její přerušení. Navíc důsledkem takových operací je přechod na obrazovku s výpisem výsledku nebo zobrazení chyby v případě, že nějaká proběhne. Proto je vytvořeno rozhraní Uloha. To vyžaduje metodu pro samotnou operaci a další pro popis chování v případě úspěchu, či chyby. Po vložení instance třídy splňující toto rozhraní je čekací obrazovka zobrazena. Při tom je spuštěna požadovaná operace na pozadí a po jejím dokončení následuje zobrazení výsledku.

5.1.3

Autentizace

Při použití knihovny kXML-RPC se vyskytl problém s použitím relací (session). Knihovna používá protokol http, ale nepodporuje cookies, které se používají k uložení identifikátoru 1

viz. sekce 5.2

5.2. JAVACARD APPLET

27

relace. To byla komplikace při řešení přihlašování, kdy je nutné použít relaci pro uložení informace o něm. Knihovna je open-source, takže by bylo možné dodělat v ní podporu cookies. Nicméně počet volání prováděných z mobilní aplikace, které následují bezprostředně za sebou (tedy v rámci relace) a vyžadují autentizaci, je velmi málo. Proto bylo zvoleno jiné řešení. Vzdálené funkce požadující autentizaci mají jako parametry navíc login a heslo. Aby uživatel nemusel tyto údaje zadávat vícekrát, jsou při přihlášení uloženy v mobilní aplikaci (samozřejmě pouze do jejího ukončení). Komunikace je šifrována a opětovné odesílání těchto údajů není z hlediska bezpečnosti větším rizikem. Ani vzhledem k velikosti přenášených dat není toto řešení horší, protože není potřeba posílat prvotní požadavek na přihlášení.

5.2

JavaCard applet

Byla vytvořena pouze třída Ticketing potomek javacard.framework.Applet. Většina operací je prováděna v samotné metodě process jejímž parametrem je APDU příkaz. Vzhledem k omezené paměti secure elementu jsou ukládány maximálně tři jízdenky, jedna jednorázová a dvě časové. Tato volba vychází z předpokladu, že jednorázovou jízdenku uživatel kupuje ve chvíli, kdy ji chce použít a případná předešlá jízdenka není již platná. Naopak u časové jízdenky se často stává, že je kupována s předstihem. V tom případě je překryv platností jízdenek možný. Applet sám nekontroluje zda se jízdenky překrývají, to je ponecháno na mobilní aplikaci, pouze v případě časových jízdenek přemaže tu starší.

5.2.1

Formát uložené jízdenky

Platforma JavaCard podporuje pouze typy byte, short a jednorozměrná pole (také speciální typy objektů) viz.[3]. Problém tedy nastává s uložením začátku platnosti jízdenky, která je instancí třídy Date. Bylo by možné použít vlastní formát, nicméně byl zvolen jednodušší způsob. Tím je použití formátu, který využívá i třída Date, doba v milisekundách od tzv. epochy (1.1.1970 00:00:00 GMT). Tento formát je sice zbytečně přesný, ale jeho velikost (je typu long tedy 8B) není o moc větší, než by měl vlastní formát. Typ long je v appletu rozdělen do pole typu byte. V tomto poli je ještě jedna položka, která uchovává typ jízdenky.

5.3

Bussines logika

Všechny důležité třídy obsažené v bussines logice v podstatě odpovídají těm v class diagramu2 . Jsou rozděleny do tří balíčků ejb, entity a pojo. V posledním z nich jsou třídy pro přenos dat. Všechny kontrolery (resp. session beany) jsou stateless a mají lokalní rozhraní. Navíc pro desktopovou aplikaci jsou vytvořena i omezená rozhraní vzdálená. Řizení přístupu bylo řešeno deklarativně pomocí anotací.

5.3.1

Použití JDBCRealm

Mapování entit na relační datázi je přenecháno na JPA, pouze bylo pomocí anotací upraveno několik jmen sloupců tabulek, které vznikly mapováním entit Uzivatel a Skupina. To bylo 2

obrázek 4.1

28


nutné kvůli použití JDBCRealm pro autentizaci uživatelů. Ta požaduje, aby sloupec s id uživatele měl stejné jméno v tabulce uživatelů i skupin.

5.3.2

Optimistické zamykání

U entity Uzivatel bylo použito verzování, protože obsahuje atribut pro ukládání zůstatku na účtu. I když není pravděpodobně, že by byl zůstatek upravován více uživateli najednou, může se to stát. V takovém případě by mohlo dojít k neočekávané změně jeho hodnoty. Díky verzování JPA tento jev může detekovat a zamezit mu (tím, že vyhodí výjimku OptimisticLockingException).

5.4 5.4.1

Webová rozhraní a logika JSF stránky

Autentizaci (typu form based) a autorizaci uživatelů provádí webový kontejner. Aby konfigurace přístupu k jednotlivým stránkám byla jednodušší, jsou ty s omezeným přístupem rozděleny do adresářů administrace a cestujici. Na stránkách jsou používány standardní JSF tagy a pro grafickou úpravu jsou samozřejmě použity kaskádové styly. Navigace je ve většině případů řešena pomocí konfiguračního souboru faces-config.xml, přímých odkazů je využito jen v případech, kde je navigace jednoduchá jako např. menu. Ke každé dynamické stránce přísluší takzvaná backing bean.

5.4.2

Webová logika

Všechny managed beany kromě Cestujici mají životnost na požadavek. Cestujici udržuje totiž informace o přihlášeném uživateli a některá data zobrazovaná ve formulářích. Má proto životnost na relaci, aby nedocházelo ke zbytečnému zatěžování serveru opětovným načítáním údajů z databáze. Kromě standardních validátorů, používaných ke kontrole např. délky hesla, bylo nutno implementovat i vlastní. Nejdůležitější slouží k ověření unikátnosti loginu při vytváření uživatele a druhý pro ověření shodnosti hesla a jeho potvrzení.

5.4.3

XML-RPC rozhraní

Rozhraní pro mobilní aplikaci, které používá protokol XML-RPC, je implementováno pomocí knihovny RedStone XML-RPC viz.[9]. Základní třídou zajištující komunikaci je XMLServlet potomek třídy redstone.xmlrpc.XmlRpcServlet. V ní je zaregistrována instance třídy JizdenkovaSluzba, jejíž metody jsou vzdálenými funkcemi. Tyto metody volají session beany z EJB kontejneru. V tomto případě byl však problém s dependency injection, protože instance servletu (a tedy i instance služby) je pouze jedna a je sdílena více vlákny. To znamená, že při klasickém použití dependency injection by všichni uživatelé sdíleli jednu instanci session beany. Tím by bylo porušeno odstínění EJB kódu od vláknové konkurence. Řešením bylo použítí dependency injection pouze pro vložení třídy beany (nikoliv instance jak je obvyklé). Instanci lze pak získat pomocí JNDI. Voláním metody lookup je vždy získána nová nebo nepoužívaná instance.

5.5. DESKTOPOVÁ APLIKACE

29

Bylo také nutné vyřešit autentizaci při volání session bean, kterou v případě obyčejného servletu nezajišťuje kontejner, jak tomu je např u JSF stránek. K tomu byla využita třída com.sun.appserv.security.ProgrammaticLogin a její metody login a logout. Toto řešení je však závislé na aplikačním serveru Glassfish.

5.5

Desktopová aplikace

Hlavní třídou je DopravniSystemFrame potomek javax.swing.JFrame. Sama reprezentuje hlavní okno aplikace a obsahuje další prvky GUI. Z této třídy jsou také volány metody jednotlivých vzdálených rozhraní EJB bean. Pro jejich vložení je opět použito Dependency Injection, jenž je zajištěno tzv. odlehčeným kontejnerem. Ten je vytvořen aplikačním serverem při instalaci serverové části systému. Důležitou třídou je také SmartCardUtil, ta je pospána dále.

5.5.1

SmartCardUtil

SmartCardUtil zajišťuje komunikaci se secure elementem v mobilním telefonu a taky jeho detekci. Tato třída je podobná ISO14443ConnectionUtil3 z mobilní aplikace, nicméně se liší, protože prostředky z balíčku javax.smartcardio nejsou shodné s těmi v Contactless API pro mobilní telefony. Navíc v tomto případě je nejprve nutné pomocí TerminalFactory nalézt čtečku, která je připojená k počítači a je dále využita pro komunikaci s kartami. K detekci přítomnosti karty v balíčku není použito události a posluchače, ale metod třídy Terminal v blokující a neblokující variantě, které vrací typ boolean. Proto byla vytvořena třída Detektor, která kontroluje přítomnost karty v cyklu a v případě nalezení a úspěšného přečtení jejího čísla vygeneruje událost. Ukázka kódu: while (!ukoncit) { if (terminal.waitForCardPresent(4000)) { card = terminal.connect("T=1"); cardChannel = card.getBasicChannel(); if (!check9000(cardChannel.transmit(SELECT_APDU))) { continue; } ResponseAPDU idResponse = cardChannel.transmit(INS_GET_ID_APDU); if (!check9000(idResponse)) { continue; } ByteArrayInputStream bai = new ByteArrayInputStream(idResponse.getData()); DataInputStream di = new DataInputStream(bai); try { long idKarty = di.readLong(); posledniDetekovanaKarta = idKarty; appletSelected = true; kartyListener.kartaDetekovana(idKarty); 3

viz. sekce 5.1.1

30


} catch (IOException ex) { ex.printStackTrace(); } terminal.waitForCardAbsent(120000); appletSelected = false; } } Jak je vidět v kódu, metoda detekující kartu je v blokující variantě. Nicméně je použit timeout, aby bylo možné při ukončení aplikace detektor zastavit. Toto řešení je tedy kombinací blokujícího a aktivního čekání. Vzhledem k velikosti timeoutu však nedochází k zbytečnému zatěžování procesoru.

Kapitola 6

Testování Testování funkčnosti probíhalo po částech během vývoje jednotlivých komponent. Nebylo použito žádného nástroje jako je například JUnit, testování bylo provedeno „ručně“. Testovací data byla vybírána tak, aby otestovala nejdříve funkčnost pro typické případy a potom i pro krajní meze. Při implementaci bussines logiky byly jednotlivé metody testovány zavoláním z jednoduché JSF komponenty a jejich výsledek vypsán na standardní výstup a porovnán s výsledkem očekávaným. V případě, že metody upravovaly databázi, byl výsledek zkontrolován přímo v ní. Při implementaci webového rozhraní byly jednotlivé funkce testovány, již s napojením na bussines logiku, přímo z webového prohlížeče. U mobilní aplikace probíhalo nejdříve testování grafického rozhraní a komunikace se serverem. To bylo prováděno v emulátoru z vývojového kitu pro telefon Nokia 6131 NFC. Potom byl implementován applet upravený pro výše zmíněný emulátor a byla testována komunikace mezi ním a aplikací. Nakonec byl applet upraven pro reálné prostředí karty a nahrán do telefonu. Testování pak pokračovalo na reálném telefonu i s testováním desktopové aplikace. Při testování funkčnosti se samozřejmě vyskytlo mnoho chyb, ty ale byly postupně opravovány. Kvůli nedostatku času nebyly provedeny testy výkonu a útoků na applet, jelikož jsou časově poměrně náročné.

31

32

KAPITOLA 6. TESTOVÁNÍ

Kapitola 7

Závěr Implementovaný systém umožňuje nákup elektronických jízdenek hromadné dopravy. Nákup je možné provést pomocí webového rozhraní, na pobočce nebo z mobilního telefonu. Jedním z hlavních cílů práce bylo právě použití mobilního telefonu. V jeho případě probíhá nákup prostřednictvím mobilní Java aplikace, která komunikuje se serverovou částí systému. Dalším cílem bylo umožnit kontrolu a uložení jízdenek do telefonu pomocí technologie NFC. Pro bezpečné uchování dat jízdenky je použita čipová karta, která podporuje Java Card API a pro niž byl implementován applet s potřebnou funkcionalitou. Tento způsob byl zvolen právě proto, že mobilní telefony s NFC takovou kartu obsahují. Samotné ukládání probíhá vysíláním APDU příkazů z mobilní aplikace nebo bezdrátové čtečky a aplikace pro prodejce. Kontrolu jízdenek umožňuje aplikace pro revizory, která je také určena pro telefony s NFC technologií. Ta bezdrátově komunikuje s čipovou kartou v telefonu cestujícího a zobrazí v ní uložené jízdenky. Kontrolu není nutno v aplikaci nijak spouštět, ta je provedena automaticky při dostatečném přiblížení obou telefonů. Velkou výhodou této implementace je, že není nutně závislá na použití mobilního telefonu. Applet totiž může být spuštěn také na klasické kartě podobné např. Opencard. V takovém případě je však možné nahrávat jízdenky pouze u přepážky. Nicméně tato možnost může být pro některé zákazníky příjemnější. Mobilní aplikace pro zákazníky také umožňuje vyhledání spoje a následné zakoupení vhodné jízdenky. Samotné vyhledání spoje však není v systému řešeno, pouze je použito stanovené rozhraní. To bylo implementováno pouze pro prezentační účely bez reálného hledání. Tento výsledek není v úplném souladu s oficiálním zadáním, nicméně odpovídá doporučení při konzultaci připomínek zadání na katedře a následné dohodě s vedoucím práce. Ve srovnání s podobnými systémy má tento velkou výhodu právě ve využití spojení čipových karet a mobilního telefonu. To umožňuje nákup jízdenek pomocí telefonu s jednoduchostí srovnatelnou např. s SMS-jízdenkou a zároveň pohodlnou kontrolou jízdenek, jako v případě OpenCard. Nevýhodou oproti podobným systémům je, že platby resp. vkládání peněz na účet mohou probíhat pouze přes aplikaci prodejce. Nicméně řešení tohoto problému bylo mimo rozsah této práce.

33

34

KAPITOLA 7. ZÁVĚR

Návrhy dalšího vývoje: • Umožnit nahrát do telefonu více jednorázových jízdenek bez začátku platnosti, které by uživatel aktivoval off-line podle potřeby. • Implementovat další možnosti platby napojením na systém banky nebo podobné instituce.

Zdroje [1] E. Haselsteiner and K. Breitfuß. Security in Near Field Communication. http://events.iaik.tugraz.at/RFIDSec06/Program, stav ze 28. 7. 2009. [2] Bouncy Castle - Stránky projektu. http://www.bouncycastle.org/, stav ze 28. 7. 2009. [3] A Java Card Primer - Úvod do Java Card API. http://www.developer.com/java/article.php/910261, stav ze 28. 7. 2009. [4] The Java EE 5 Tutorial. http://java.sun.com/javaee/5/docs/tutorial/doc/, stav ze 15. 6. 2009. [5] J2SE API reference. http://java.sun.com/j2se/1.4.2/docs/api/index.html, stav ze 28. 7. 2009. [6] XML-RPC for Java ME - Stránky projektu. http://kxmlrpc.wiki.sourceforge.net/Introduction, stav ze 28. 7. 2009. [7] Nokia 6131 NFC - FAQs. http://wiki.forum.nokia.com/index.php/Nokia_6131_NFC_-_FAQs, stav ze 28. 7. 2009. [8] Introduction to Near Field Communication and Contactless API. http://java.sun.com/developer/technicalArticles/javame/nfc/, stav z 2. 3. 2009. [9] Redstone XML-RPC library - Stránky projektu. http://xmlrpc.sourceforge.net/, stav ze 28. 7. 2009.

35

36

ZDROJE

Příloha A

Seznam použitých zkratek NFC Near Field Communication NDEF NFC Data Exchange Format URI Uniform Resource Identifier APDU Application Protocol Data Unit J2ME Java 2 Platform, Micro Edition J2SE Java 2 Platform, Standard Edition J2EE Java 2 Platform, Enterprise Edition EJB Enterprise Java Bean JPA Java Persistance API API Application interface JSF Java Server Faces RMI Remote Method Invocation JNDI Java Naming and Directory Interface RPC Remote Procedure Call XML Extensible Markup Language GUI Graphical User Interface

37

38

PŘÍLOHA A. SEZNAM POUŽITÝCH ZKRATEK

Příloha B

Instalační a uživatelská příručka B.1

Příručka pro zákazníky - webové rozhraní

Pro přístup k webovému rozhraní systému zapněte internetový prohlížeč a přejděte na stránky dopravního podniku.

B.1.1

Registrace

1. Na hlavní stránce zvolte položku Registrovat se. 2. Do zobrazeného formuláře zadejte vaše osobní údaje. Všechny položky jsou povinné a login musí být unikátní. Nakonec zvolte tlačítko Odeslat. 3. Pokud je vše vyplněno správně, zobrazí se oznámení o úspěšné registraci. Pokud se opět zobrazí formulář, opravte červeně označené údaje a opět odešlete.

B.1.2

Přihlášení k účtu

1. Na hlavní stránce zvolte položku Přihlásit se. 2. Do zobrazeného formuláře zadejte svůj login a heslo. Potom zvolte tlačítko Přihlásit se. 3. Pokud jste údaje vyplnili správně, systém zobrazí stránku s historií vámi zakoupených jízdenek.

B.1.3

Zakoupení jízdenky

1. V menu zvolte Zakoupit jízdenku. 2. Na zobrazené stránce zaškrtněte vámi zvolenou jízdenku, zadejte počátek její platnosti a potvrďte tlačítkem Koupit. 3. Pokud máte dostatečný zůstatek na účtu, zobrazí se historie zakoupených jízdenek a nová jízdenka bude označena jako připravená k nahrání.

39

40

PŘÍLOHA B. INSTALAČNÍ A UŽIVATELSKÁ PŘÍRUČKA

4. Aby byla jízdenka uložena ve vašem mobilním telefonu, je nutné ještě provést nahrání viz. B.2.3.

B.1.4

Editace osobních údajů

1. V menu zvolte položku Osobní údaje. 2. V zobrazeném formuláři upravte údaje, které chcete změnit, a potvrďte tlačítkem Uložit. 3. Po úspěšném uložení se zobrazí historie zakoupených jízdenek.

B.1.5

Odhlášení

Odhlášení je provedeno automaticky po 20 minutách nečinnosti. Nicméně je bezpečnější odhlásit se po dokončení požadovaných operací takto: 1. V menu zvolte položku Odhlásit se. 2. Systém zobrazí informaci o úspěšném odhlášení.

B.2 B.2.1

Příručka pro zákazníky - mobilní aplikace Instalace

Aby instalace mohla proběhnout úspěšně, váš telefon musí podporovat technologii NFC a Java aplikace (alespoň MIDP 2.0 a CLDC 1.1). Pokud si nejste jisti, informujte se u prodejce nebo výrobce telefonu. 1. Na hlavní webové stránce dopravního podniku zvolte Stažení mobilní aplikace. 2. Uložte si do svého počítače soubory Jizdenky.jar a Jizdenky.jad. 3. Samotná instalaci závisí na typu mobilního telefonu. V zásadě je možné ji provést těmito způsoby: • Nahráním uložených souborů do telefonu např. pomocí paměťové karty nebo kabelu a následným spuštěním souboru s příponou jad v průzkumníkovi souborů v telefonu. • Použitím takzvané PC Suite, aplikace ke správě telefonu pomocí počítače dodávané k přístroji. Pro podrobnější popis tohoto způsobu použijte příručku k této aplikaci. 4. Po úspěšné instalaci najdete aplikaci mezi ostatními aplikacemi, které běžně používáte. Aby bylo možné ukládat jízdenky do telefonu, je ještě nutné nainstalovat tzv. applet1 1

Instalace appletu není popsána, protože její postup závisí na firmě, která by applety distribuovala. V případě testování se používá ruční nahrání pomocí čtečky, což při reálném nasazení není vhodné viz. [7].

B.2. PŘÍRUČKA PRO ZÁKAZNÍKY - MOBILNÍ APLIKACE

B.2.2

41

Spuštění a zvolení operace

Po spuštění aplikace se zobrazí hlavní menu. V něm vyberte požadovanou operaci a potvrďte tlačítkem OK. Při volbě Koupit jízdenku nebo Nahrát jízdenku se aplikace bude připojovat k vašemu účtu, je tedy nutné se přihlásit. Aplikace vás v těchto případech požádá o vložení loginu a hesla. Jsou to stejné přihlašovací údaje, které se používají u webového rozhraní. Pro volby Zobrazit jízdenky a Vyhledat spojení není přihlašování nutné.

B.2.3

Zakoupení jízdenky a její nahrání

Nahrání jízdenky probíhá po jejím zakoupení. Pokud kupujete jízdenku z telefonu, je vám nahrání nabídnuto automaticky. Pokud jste ale jízdenku zakoupili pomocí webového rozhraní, musíte ručně zvolit volbu Nahrát jízdenku. V telefonu je možné mít uloženu maximálně jednu jednorázovou a dvě časové jízdenky. V případě nahrání je starší jízdenka smazána, a pokud se platnost jízdenek překrývá, aplikace vás na to upozorní. Zakoupení jízdenky: 1. V menu zvolte Koupit jízdenku. 2. Na další obrazovce zvolte typ jízdenky a potvrďte tlačítek OK. 3. V případě časových jízdenek se zobrazí další obrazovka, kde nastavte datum začátku platnosti. Políčko je přednastaveno na aktuální datum. Jednorázová jízdenka je platná od chvíle nahrání. 4. Po úspěšném zakoupení jízdenky se aplikace dotáže, jestli chcete jízdenku nahrát. Zvolte tedy Ano.

B.2.4

Zobrazení jízdenek

Pokud v menu zvolíte Zobrazit jízdenky, aplikace vám zobrazí typ a platnost všech jízdenek, které jsou fyzicky nahrány v telefonu. Platné jízdenky jsou označeny2 . Vyhledání spojení: 1. V menu zvolte Vyhledat spojení. 2. Na další obrazovce zadejte počáteční stanici, cílovou stanici, datum a čas hledaného spoje. Potvrďte tlačítkem Vyhledat. 3. Pokud pro dané parametry existuje spoj, zobrazí se. 4. Tlačítkem Další zobrazíte následující spoj. 5. Pokud chcete pro daný spoj zakoupit jednorázovou jízdenku aktivujte tlačítko Koupit jízdenku a potvrďte OK. Potom následuje stejný postup jako při nákupu jízdenek. 2

Pro správnou funkci označení platných jízdenek musíte mít v telefonu nastaven správný čas a datum. Nicméně toto nastavení neovlivňuje opravdovou platnost jízdenky. Revizorovi se jízdenky zobrazí správně.

42


B.3

Příručka pro prodejce

Spusťe aplikaci a zadejte váš login a heslo.

B.3.1

Zobrazení účtu zákazníka

Vyhledání proběhne automaticky pokud je přiložen telefon zákazníka ke čtečce. Pokud uživatel nemá telefon sebou (v tomto případě lze provést pouze vložení pěněz na účet), v sekci Vyhledat vložte příjmení nebo login zákazníka a stiskněte tlačítko Vyhledat. Pokud jich bude nalezeno více vyberte jednoho ze seznamu.

B.3.2

Vložení peněz na účet zákazníka

1. Vyhledejte zákazníka 2. Stiskněte tlačítko vložit peníze. 3. Zadejte částku. Potvrďte tlačítkem OK nebo zrušte tlačíkem Zrušit.

B.3.3

Prodat jízdenku

1. Přiložte telefon ke čtečce a vyčkejte až se zobrazí účet zákazníka. 2. Stiskněte tlačítko Nová jízdenka. 3. Na zobrazeném panelu zvolte typ a začátek platnosti jízdenky a potvrďte OK. 4. Vyčkejte až se jízdenka vloží do telefonu.

B.4

Příručka pro administrátora

Pro vstup do systému zadejte do internetového prohlížeče adresu administrátorského rozhraní. Po zobrazení přihlašovací formuláře zadejte údaje a odešlete ho. Jako úvodní stránka se zobrazí seznam uživatelů. Z něho je možné přejít na editaci údajů uživatele nebo jeho smazání. Obojí probíhá zvolením odkazu vedle jejich jména. Vybráním položky z menu v horní části stránky, je také možné vytvořit uživatele nového. V administračním prostředí nelze vytvářet uživatele ve skupině Cestující a měnit toto členství u stávajících uživatelů. V menu je také odkaz na stránku pro editaci cen jízdenek a doby jejich nákupu před platností.

B.5

Instalační příručka

Instalace serveru a příprava aplikačního klienta pro instalaci je poměrně složitá a závislá na prostředcích serveru. Tyto úkony by prováděl zaměstnanec firmy vyvíjející aplikaci. Proto zde je uveden pouze přehled vyžadovaných úkonů. Instalační soubor je DopravniSystem.ear.

B.5. INSTALAČNÍ PŘÍRUČKA

43

1. Instalace aplikačního serveru GlassFish a databázového serveru. (Pouze pokud nejsou, již nainstalovány.) Vytvoření databáze. 2. Nastavení připojení k databázi v konfiguračním souboru sun-resourses.xml, který se nalézá v souboru instalačním. 3. Vytvoření JDBCRealm v aplikačním serveru. Pro tabulky UZIVATEL_SKUPINA, UZIVATEL a sloupce LOGIN, PASSWORD, SKUPINA. 4. Provedení deploymentu s parametrem –retrieve(způsobí načtení aplikačního klienta). 5. Naplnění databáze povinnými daty. 6. Vygenerování aplikačního klienta pomocí příkazu package-appclient a nastavení adresy serveru v konfiguračním souboru appclient/config/sun-acc.xml.

44


Příloha C

Obsah přiloženého CD Adresáře na CD a jejich obsah: • text - Text práce ve formátu pdf • textsrc - Zdrojové soubory textu práce • bin - Přeložený kód • src - Zdrojové kódy

45

Jízdní řád a jízdenky v mobilním telefonu. Jakub Trnavský

Recommend Documents