BAKALÁŘSKÁ PRÁCE. Vývoj e-commerce platformy pro mobilní zařízení s podporou webového backendu

BAKALÁŘSKÁ PRÁCE Vývoj e-commerce platformy pro mobilní zařízení s podporou webového backendu E-commerce platform development with web backend support Jan Barcík

Un ico rn Co lle ge © 2 01 0 Un ico rn Co lle ge , V Ka pslo vn ě 2 76 7/ 2 , P ra ha 3, 13 0 0 0 Ná ze v p rá ce v ČJ:

Ná ze v p rá ce v A J:

V ývo j e-co mm e rce p la t f o rm y p ro mo biln í za říze n í s p od po ro u we b o vé h o b acke nd u E -com me rce p la tf o rm d e ve lop me n t wit h we b b acke nd sup po rt

A ut o r:

Jan B a rcík

A kad em ický ro k:

2 01 0/ 2 01 1

K on ta kt :

E -m ail: b a rcikk@ se zn a m. cz T el. : (+4 2 0 ) 60 3 8 45 81 7

Bakalářská práce Vývoj e-commerce platformy pro mobilní zařízení s podporou webového backendu E-commerce platform development with web

1.

ZADÁNÍ

▪3▪


2.

ABSTRAKT

Cílem práce je popsat, analyzovat, navrhnout a implementovat obecnou platformu pro podporu mcommerce pro mobilní zařízení, využívající platformu Android. Platforma je tvořena dvojicí modulů: mobilní aplikací a webovým backendem, sloužícím jako zdroj dat mobilní aplikace a jako administrační rozhraní pro obchodníky používající tuto platformu. Platforma bude nabízena jako služba poskytující unikátní marketingový kanál dodavatelům v prostředí stále oblíbenějších „chytrých telefonů“. Práce se v první části zabývá problematikou e-commerce a m-commerce, jejích přínosy pro obchodníky i koncové zákazníky. Protože bude platforma částečně využívat technologii Cloud Computingu, je tomuto tématu věnována celá kapitola práce. Následuje popis a filozofie platformy včetně popisu její přidané hodnoty pro dodavatele. Poté následují kapitoly zabývající se popisem návrhu a architektury obou modulů platformy, tzn. mobilní aplikace a webového backendu. Na analýzu, návrh a architekturu navazují kapitoly s popisem implementace obou modulů. Na závěr jsou nastíněny další možnosti rozvoje a směřování vzniklé platformy. Výsledkem práce je analýza a návrh platformy s implementací její první etapy, která obsahuje mobilní aplikaci a webový backend v definovaném funkčním rozsahu. K práci nebudou přiloženy zdrojové kódy platformy, protože se jedná o obchodní tajemství společnosti eMan s.r.o. Zdrojové kódy budou k dispozici k nahlédnutí při obhajobě této závěrečné bakalářské práce.

Klíčová slova: e-commerce, m-commerce, B2C, Android, Google App Engine, platforma, služba, mobilní aplikace, web backend.

▪4▪


3.

ABSTRACT

The aim of this thesis is to describe, analyze, design and implement a general platform for supporting m-commerce for mobile devices using the Android platform. The platform consists of a pair of modules: mobile applications and backend web, serving as a data source for mobile applications and as an administration interface for businessmen using (users of) this platform. The platform will be offered as a service providing suppliers with unique marketing channel in increasingly popular "smart phones" environment. In the first part, the thesis describes e-commerce and m-commerce, focuses on its benefits for resellers and end users. Because the platform will partly use cloud computing - a single chapter is devoted to this topic. Further a description and introduction of philosophy of the platform is explained, including description of its added value for suppliers followed by chapters dealing with the description of the design and architecture of both modules of the plat form, i.e. mobile web applications and backend. The analysis, design and architecture, leads into chapters describing the implementation of both modules. At the end of the thesis further development opportunities and possible directions of the final platform are outlined .The result of this thesis is analysis and design of the platform and the first phase of its implementation, containing a mobile web application and backend defined in the functional range. Platform source code is not included in this thesis, because it is an object of trade secret of eMan, s.r.o. Source codes will be available for inspection at the thesis defence.

Keywords: e-commerce, m-commerce, B2C, Android, Google App Engine platform, service, mobile applications, web backend.

▪5▪


4.

PROHLÁŠENÍ

Prohlašuji, že svou bakalářskou práci na téma Vývoj e-commerce platformy pro mobilní zařízení s podporou webového backendu jsem vypracoval samostatně pod vedením vedoucího bakalářské práce a s použitím odborné literatury a dalších informačních zdrojů, které jsou v práci citovány a jsou též uvedeny v seznamu literatury a použitých zdrojů. Jako autor uvedené bakalářské práce dále prohlašuji, že v souvislosti s vytvořením této bakalářské práce jsem neporušil autorská práva třetích osob, zejména jsem nezasáhl nedovoleným způsobem do cizích autorských práv osobnostních a jsem si plně vědom následků porušení ustanovení § 11 a následujících autorského zákona č. 121/2000 Sb. Nemam zavazny duvod proti uziti tohoto skolniho dila ve smyslu §60 Zakona c. 121/2000 Sb., o pravu autorskem, o pravech souvisejicich s pravem autorskym a o zmene nekterych zakonu (au torsky zakon) vyjma zverejneni zdrojovych kodu, ktere jsou majetkem spolecnosti eMan s.r.o. Zdrojove kody budou poskytnuty k nahlednuti oponentovi bakalarske prace a komisi pritomne pri obhajobe teto prace.

V Praze dne

…….………………. Jméno Příjmení

▪6▪


5.

PODĚKOVÁNÍ

Rád bych poděkoval vedoucímu mé bakalářské práce, panu Mgr. Peterovi Buchlákovi, za vítanou odbornou pomoc, ochotu, čas a užitečné rady, které mi poskytl při tvorbě této bakalářské práce.

▪7▪


6.

OBSAH

1. 2. 3. 4. 5. 6. 7. 8.

Zadání.......................................................................................................................................... 3 Abstrakt....................................................................................................................................... 4 Abstract....................................................................................................................................... 5 Prohlášení................................................................................................................................... 6 Poděkování ................................................................................................................................ 7 Obsah.......................................................................................................................................... 8 Úvod........................................................................................................................................... 11 E-commerce.............................................................................................................................. 12 8.1 B2B – Business to Business.......................................................................................... 12 8.2 B2C – Business to Customer......................................................................................... 13 8.3 C2C – Customer to Customer........................................................................................ 13 9. M-commerce............................................................................................................................. 15 9.1 Možnosti a aplikace m-commerce.................................................................................16 9.2 M-Payment........................................................................................................................ 18 9.2.1 Premium SMS..................................................................................................... 18 9.2.2 Přímé zpoplatnění u operátora.........................................................................19 9.2.3 Mobilní webové platby.......................................................................................20 9.3 M-Shop.............................................................................................................................. 21 10. Cloud Computing................................................................................................................... 22 10.1.1 SaaS – Software as a Service........................................................................22 10.1.2 PaaS – Platform as a Service.........................................................................22 10.1.3 Google App Engine.......................................................................................... 23 11. Popis a filozofie platformy.................................................................................................... 24 11.1 Jak služba funguje........................................................................................................ 24 11.2 Mobilní aplikace............................................................................................................. 24 11.3 Přidaná hodnota služby................................................................................................ 26 11.4 Služba z pohledu dodavatele.......................................................................................28 11.4.1 Registrace do služby........................................................................................ 28 11.4.2 Nabídka produktů prostřednictvím služby.....................................................28 11.4.3 Profil dodavatele............................................................................................... 29 11.5 Služba z pohledu zákazníka........................................................................................ 30 11.5.1 Registrace do služby........................................................................................ 30 11.5.2 Výběr produktů.................................................................................................. 30 11.5.3 Objednání produktů ......................................................................................... 31 11.5.4 Registrovaný versus neregistrovaný uživatel...............................................31 11.5.5 Profil................................................................................................................... 31 11.6 Etapizace........................................................................................................................ 32 11.7 Popis první etapy........................................................................................................... 32 11.7.1 Popis mobilní aplikace v první etapě.............................................................32 11.7.2 Popis webového backendu v první etapě.....................................................33 12. Analýza a návrh řešení aplikace......................................................................................... 34 12.1 Aktéři v aplikaci............................................................................................................. 34 12.2 Procesy aplikace........................................................................................................... 34 12.3 Identifikované požadavky............................................................................................. 38 12.3.1 Funkčnost:......................................................................................................... 38 12.3.2 Použitelnost:..................................................................................................... 40 12.3.3 Spolehlivost:...................................................................................................... 40 12.3.4 Výkon:................................................................................................................ 41 12.3.5 Podpora:............................................................................................................ 41 12.3.6 Jiné požadavky:................................................................................................ 41 12.4 Přehled use-case........................................................................................................... 42

▪8▪


12.4.1 Přehled mapování požadavků na use-case..................................................43 12.5 Use-case diagramy....................................................................................................... 44 12.5.1 UC01.01 Výběr květiny....................................................................................44 12.5.2 UC01.02 Objednání.......................................................................................... 45 12.5.3 UC02.01 Registrace zákazníka......................................................................46 12.5.4 UC02.02 Správa profilu zákazníka................................................................47 12.6 Doménový model .......................................................................................................... 48 12.7 Objednávka a její stavy................................................................................................ 48 12.8 Návrh uživatelského rozhraní......................................................................................49 13. Implementace mobilní aplikace........................................................................................... 50 13.1 Aplikační business class model..................................................................................50 13.2 Struktura aplikace......................................................................................................... 50 13.3 Aplikační data................................................................................................................ 51 13.4 Komunikace s webovým backendem..........................................................................52 13.5 Platební brána České spořitelny.................................................................................52 13.6 Uživatelské rozhraní..................................................................................................... 53 14. Implementace webového backendu....................................................................................55 14.1 Aplikační business class model..................................................................................55 14.2 Struktura aplikace......................................................................................................... 55 14.3 Aplikační data................................................................................................................ 57 14.4 Komunikace s mobilní aplikací....................................................................................57 14.4.1 Serverové výjimky............................................................................................ 57 14.4.2 Autentifikace..................................................................................................... 58 14.4.3 Synchronizace dat............................................................................................ 58 14.4.4 Metody............................................................................................................... 59 14.5 Platební brána České spořitelny.................................................................................63 15. Budoucnost platformy........................................................................................................... 65 15.1 Druhá etapa.................................................................................................................... 65 15.2 Třetí etapa...................................................................................................................... 66 16. Závěr....................................................................................................................................... 67 17. Conclusion.............................................................................................................................. 68 18. Seznam použité literatury..................................................................................................... 69 19. Seznam použitých symbolů a zkratek................................................................................71 20. Seznam obrázků.................................................................................................................... 73 21. Seznam tabulek..................................................................................................................... 74 22. Seznam příloh........................................................................................................................ 75 22.1 Příloha 1 – Class model mobilní aplikace..................................................................76 22.2 Příloha 2 – Class model webového backendu..........................................................77 22.3 Příloha 3 – Návrh UI mobilní aplikace........................................................................78 22.3.1 UI0000 SplashScreen......................................................................................78 22.3.2 UI1003 Kategorie.............................................................................................. 78 22.3.3 UI1002 Seznam produktů................................................................................79 22.3.4 UI1001 Detail produktu....................................................................................79 22.3.5 UI1004 Vložení do košíku...............................................................................80 22.3.6 UI1005 Košík..................................................................................................... 80 22.3.7 UI1006 Zadej počet kusů................................................................................81 22.3.8 UI1007 Nepřihlášený uživatel.........................................................................81 22.3.9 UI1008 Vyprázdni košík...................................................................................82 22.3.10 UI1009 Aplikuj Bonus....................................................................................82 22.3.11 UI1010 Detail položky košíku.......................................................................83 22.3.12 UI1010_A Dialog............................................................................................ 83 22.3.13 UI1010_B Detail položky košíku s jedním textem blahopřání.................84 22.3.14 UI1020_A Objednej – přihlášený uživatel – strana 1 ................................84 22.3.15 UI1020_A Objednej – přihlášený uživatel – strana 2 ................................85

▪9▪


22.3.16 22.3.17 22.3.18 22.3.19 22.3.20 22.3.21 22.3.22 22.3.23 22.3.24 22.3.25 22.3.26 22.3.27 22.3.28 22.3.29

UI1020_B Objednej – nepřihlášený uživatel – strana 1 ...........................85 UI1020_B Objednej – nepřihlášený uživatel – strana 2 ...........................86 UI1020 Fakturační údaje...............................................................................86 UI1020 Poznámka.......................................................................................... 87 UI1020 Čas dodání........................................................................................ 87 UI1021 Zrušit objednávku.............................................................................88 UI1023 Platební brána...................................................................................88 UI1023 Platební brána ČS...........................................................................89 UI2001 Registrace......................................................................................... 89 UI2010 Nastavení........................................................................................... 90 UI2003 Přihlášení........................................................................................... 91 UI2012 Profil................................................................................................... 91 UI2011 Historie objednávek..........................................................................92 UI2019 Detail historické objednávky...........................................................92

▪ 10 ▪


7.

ÚVOD

Cílem této závěrečné bakalářské práce je navrhnout a implementovat platformu podporující m-commerce pro drobné dodavatele zboží. Toto zboží pak bude snadno doručeno pomocí donáškové služby. Platforma bude nabízena jako hotová služba jednotlivým dodavatelům s možností okamžitého použití, ale zároveň s prostorem pro případné úpravy na míru jednotlivým dodavate lům. Tato platforma bude v rámci mé bakalářské práce implementována pro pilotní provoz na mobilních zařízeních s operačním systémem Android. Bude tvořena webovým backendem, dodávajícím data pro mobilní část platformy, a zároveň bude sloužit jako administrační rozhraní pro jednotlivé dodavatele. Platforma bude umožňovat vstup libovolného počtu dodavatelů. Mobilní část platformy bude tvořit aplikace podporující Android OS verze 2.1 a vyšší. Tuto část budou používat potenciální zákazníci k výběru, objednání a zaplacení jimi vybraného zboží. Typ a nabídku zboží určí do davatelé, kteří budou tuto službu využívat. Jediným omezením typu zboží bude požadavek na do ručitelnost pomocí donáškových služeb, tzn. požadavek na rozměry a hmotnost zboží. V teoretické části bakalářské práce budou definovány pojmy e-commerce, SaaS a m-commerce, s nimi související zkratky, pojmy a technologie, a budou uvedeny základní typy aplikací, které se těchto pojmů dotýkají. Součástí platformy bude i platební brána sloužící k zaplacení objednaného zboží, proto bude kladen důraz i na možnosti placení v prostředí e-commerce/m-commerce. V rámci teoretické části bude i popis, filozofie a obchodní model služby, pomocí které bude platfor ma nabízena obchodníkům a dodavatelům, dále výhody, nevýhody této služby a přidaná hodnota pro obchodníky a dodavatele, kteří se rozhodnou tuto službu využívat. V praktické části bude provedena analýza a návrh řešení této platformy. Na tuto část bude navazovat popis implementace navrženého řešení a reálná implementace platformy. V závěru práce budou nastíněny možnosti dalšího zlepšování a rozšiřování platformy, např. její převod na mobilní zařízení s jiným operačním systémem než je Android a podobně. Práce se nezabývá popisem platformy Android použité pro mobilní část a platforma Google App Engine použitá k tvorbě webového backendu je popsána pouze stručně, práce tudíž předpokládá alespoň základní znalost zmíněných platforem a programovacího jazyka Java, který tyto platformy využívají.

▪ 11 ▪


8.

E-COMMERCE

„E-commerce je poměrně široký pojem používaný k označení veškerých obchodních transakcí rea lizovaných za pomoci internetu a dalších elektronických prostředků. E-commerce je tedy společně s dalšími (e-learning apod.) součástí e-business (elektronického podnikání).“ [1] E-commerce, neboli elektronická komerce, představuje realizaci obchodních transakcí s využitím internetu. Artiklem těchto transakcí může být nejen fyzické zboží, ale i služby a informace. Fyzické zboží je reprezentováno především spotřebním zbožím prodávaným pomocí e-shopů 1. Hovoříme-li o obchodu s informacemi, pak se jedná o prodej zpráv, publikací či multimediálního obsahu. V případě služeb bych rád vyzdvihl koncept SaaS 2, kterému bude věnována jedna z dalších kapitol, protože se přímo dotýká tématu této práce. Jak již bylo řečeno výše, e-commerce jako pojem slouží k označení obchodních transakcí, které jsou realizované pomocí nějakého elektronického média. Tyto transakce vždy probíhají mezi dvěma entitami, kdy jedna entita nějaké zboží, informaci či službu nabízí a druhá entita zmíněné produkty využívá. Podle toho, do kterého segmentu spadá první či druhá entita účastnící se transakce, lze e-commerce charakterizovat následujícími vztahy: •

B2B - Business to Business

•

B2C - Business to Customer

•

C2C - Customer to Customer

Existují i další vztahy, které však nejsou pro potřeby této práce důležité. Jen pro úplnost se jedná například o C2B - Customer to Business (například fyzická osoba figurující jako dodavatel pracovní síly pro společnost), B2E - Business to Employee (vztah obchodníka se zaměstnanci, řízení pracovního procesu). Do další skupiny vztahů vstupuje písmeno G z angl. Government, což je v angličtině výraz pro vládu, respektive stát. Jedná se tedy o vztahy utvářené mezi státem a druhou stranou ve smyslu různých státních zakázek.

8.1

B2B – Business to Business

„Koncept B2B je nejstarší složkou elektronického podnikání (e-business). Zkratka B2B pochází z anglického termínu Business to Business (obchodník → obchodník), koncept B2B se tedy týká 1

„E-shop, elektronický obchod (někdy také eshop, internetový obchod nebo online obchod) je speciální webová aplikace sloužící ke zprostředkování obchodních transakcí na internetu, většinou v oblasti B2C.“ [2]

2

SaaS – „Software jako služba(Software as a Service) je model nasazení softwaru, kdy dochází k hostingu aplikace provozovatelem služby. Služba je dále nabízena zákazníkům přes internet.“ [3]

▪ 12 ▪


obchodních vztahů a vzájemné komunikace mezi dvěma společnostmi. B2B vztahy většinou fungují na principu elektronické výměny dat. Těmi mohou být základní informace (např. objednávky, faktury), jejichž elektronická podoba umožňuje snížit náklady, automatizovat celý proces a zvýšit jeho rychlost. Vyšším stupněm B2B obchodování jsou různáB2B internetová tržiště, jejich hlavním úkolem je zprostředkování obchodů. Nejsložitější B2B systémy potom fungují jako komunikační a distribuční sítě, sloužící především k regulaci již navázaných obchodních vztahů. Častým případem je i přímé napojení takovýchto B2B systémů na další programy v rámci softwarové struktury prodávající firmy, což přináší úspory a zvyšuje efektivitu celého prodejního procesu.“ [4] Platforma se nepochybně týká B2B e-commerce vztahů vzhledem k tomu, že bude nabízena jako služba jiným podnikatelům, v tomto případě obchodníkům prodávajícím své zboží, kterým tak otevře nový komunikační kanál pro prodej v prostředí chytrých telefonů.

8.2

B2C – Business to Customer

„B2C je patrně nejrozšířenějším modelem internetového podnikání (e-business). Zkratka B2Cpochází z anglického termínu Business to Customer (obchodník → zákazník). Segment B2Ctedy zahrnuje především přímý prodej koncovým zákazníkům či alespoň jeho podporu. Obvykle se rozlišují tři úrovně B2C modelu. Základem služeb B2C je snaha informovat o produktech, webová stránka zde vlastně plní funkci jakéhosi letáku či elektronického katalogu. Vyšší úroveň B2C služeb přidává interaktivní formuláře, např. Možnosti zpětné vazby. Nejvyšší úrovní B2C je potom samozřejmě samotný internetový obchod, nejlépe s možností rovnou zaplatit objednané zboží online.“ [5] Mobilní část platformy je určena k prodeji zboží koncovým uživatelům. Toto zboží je prodáváno a dodáváno jednotlivými dodavateli, což je typický případ B2C.

8.3

C2C – Customer to Customer

„Termín C2C (zkratka z anglického Customer to Customer) se používá k popisu vztahu a vzájemné komunikace mezi dvěma zákazníky (nepodnikateli). C2C vztahy se však obvykle odehrávají bez přímé účasti obchodníka, proto koncept C2C nebývá zahrnován mezi služby elektronického podnikání.

▪ 13 ▪


Protože C2C služby se většinou týkají použitého zboží, k provozování C2C operací na internetu obvykle slouží různé inzertní služby, bazary, burzy či přímo specializované aukční systémy.” [6] Umožnit uživatelům mobilní části platformy směnu zboží bez účasti dodavatelů není cílem této platformy, tedy ani bakalářské práce, nicméně podle mého názoru do této kategorie vztahů patří i komunikace mezi zákazníky, která zvyšuje povědomí o platformě a o dodavatelích. Z toho důvodu by uživatelům měla být komunikace umožněna například pomocí Facebookové stránky či přímo v aplikaci pomocí implementované možnosti hodnotit zboží či dodavatele. Z důvodu zachování poža dovaného rozsahu není toto hodnocení součástí práce, ale představuje jednu z možností zdokonalení v budoucím vývoji aplikace.

▪ 14 ▪


9.

M-COMMERCE

„M-Commerce představuje použití mobilní komunikace s jakoukoli aplikací dostupnou a vytvořenou pro mobilní koncová zařízení, jejíž využití slouží k obchodním účelům.“ [7] Jedná se o poměrně nedávno vzniklý pojem, který lze vymezit jako jakoukoli obchodní transakci vykonanou pomocí bezdrátově připojeného mobilního zařízení v reálném čase. Mobilní zařízení v dnešní době představují převážně mobilní telefony, PDA, tablety a jiné. Bezdrátové přenosy jsou realizovány nejčastěji pomocí technologií mobilních sítí 1. až 4. generace nebo pomocí wifi připojení. Z definice vyplývá, že je m-commerce v podstatě součástí elektronického obchodování, tedy součástí e-commerce. Na rozdíl od e-commerce má několik velice užitečných vlastností, které při nášejí vysokou přidanou hodnotu všem zúčastněným stranám obchodování. Mezi hlavní patří především: •

Dostupnost – aplikace jsou nainstalovány v mobilním zařízení, které má uživatel většinou stále na dosah a které na rozdíl od pc a notebooků v případě využití datového tarifu umožňuje připojení na internet v podstatě odkudkoli.

•

Lokalizace – velký počet zařízení umožňuje zjištění aktuální polohy, což otevírá nové možnosti marketingu a prodeje s vazbou na konkrétní místo, kde se uživatel právě nachází.

•

Ekonomická dostupnost – mobilní zařízení mají nižší pořizovací náklady než počítače.

•

Bezpečnost – lepší a spolehlivější identifikace uživatele, lepší zabezpečení proti virům a jinému škodlivému softwaru.

•

Pohodlí – váha a velikost mobilních zařízení společně s dostupností zvyšují komfort koncového uživatele.

•

Personalizace – mobilní zařízení většinou patří jednomu konkrétnímu uživateli, který má své požadavky a způsoby nakupování, což umožňuje obchodníkům osobní přístup k zákazníkům na bázi one-to-one marketingu.

▪ 15 ▪


Vlastnosti m-commerce

Příklady aplikací

Pohodlí

Ceny akcií, počasí v oblasti výskytu zařízení, obchody v okolí, MHD v okolí

Personalizace

Cílená inzerce, aukce

Dostupnost

Bankovnictví, nákup zboží

Lokalizace

Místní marketing, Navigace, Mapové aplikace

Tabulka 1: Příklady m-commerce aplikací a jejich vazba na vlastnosti m-commerce.

M-commerce má však i jistá omezení a nevýhody, které je třeba mít na paměti: •

Velikost displeje zařazení – mobilní zařízení již ze své mobilní podstaty nemají a ani nebudou mít displeje odpovídající velikosti obrazovky počítače, z čehož vyplývají omezení pro uživatele.

•

Nepohodlné zadávání dat – zařízení většinou nedisponují plnohodnotnou klávesnicí.

•

Rychlost připojení – relativně pomalejší připojení pomocí mobilních sítí, v případě nedostupnosti wifi připojení.

•

Krátká životnost baterie zařízení – krátká doba fungování na jedno nabití baterie, která je navíc snižována používáním datových přenosů.

•

Neexistence standardů – mnoho rozdílných řešení a aplikací m-commerce, různých mobilních zařízení podporujících různé platformy ztěžuje práci a vývoj především tvůrcům samotných aplikací pro podporu m-commerce.

Vzhledem k neustálému rozvoji a vývoji mobilních zařízení je možné předpokládat, že tyto nevýho dy budou v průběhu času postupně minimalizovány nebo zčásti dokonce úplně odstraněny.

9.1

Možnosti a aplikace m-commerce

M-commerce lze využívat různými způsoby s různými cíli. Hlavní oblasti m-commerce služeb se dají charakterizovat pomocí několika oblastí: [8] •

Prodej obsahu – prodej tapet, her, hudby, videí apod.

•

Informační služby – zprávy, jízdní řády, počasí, hustota provozu apod., realizováno formou SMS, MMS, nebo speciálními aplikacemi.

▪ 16 ▪


•

Lokační a navigační služby – navigace, mapové aplikace, reklama vázaná na určitou lokalitu, informace o nejbližší bance, bankomatu, restauraci apod., lokalizace zaměstnanců, automobilů aj. v rámci společnosti.

•

Finanční služby - bankovnictví, investování, platby za různé služby.

•

Objednávání zboží - pomocí speciálních aplikací či e-shopů optimalizovaných pro mobilní zařízení.

Jednotlivé aplikace m-commerce mohou pokrývat jednu i více oblastí m-commerce. Mezi základní aplikace m-commerce patří: [9] •

m-Presence – prezentace společnosti, představení služeb a zboží; jedná se o ekvivalent standardních webových prezentací společností, avšak tyto prezentace jsou optimalizované pro zobrazování na mobilních zařízeních.

•

m-Banking – mobilní bankovnictví, u nás zatím nejrozšířenější typ aplikací díky podpoře všech tří hlavních operátorů; lze provozovat i na starších typech telefonů, tzn. není potřeba vlastnit chytrý telefon.

•

m-Marketing – nejnovější forma marketingu, kam patří například věrnostní programy, propagační hry, reklamní sdělení zasílaná pomocí SMS, infokanály, soutěže nebo marketing v závislosti na lokalizaci zákazníka, což znamená, že zákazník dostane reklamní zprávu, pokud se nachází v blízkosti inzerovaného obchodu.

•

m-Auction – ekvivalent klasických internetových aukcí (eBay, Aukro aj.), v prostředí mobilních zařízení, například aplikace eBay pro Android OS a iOS.

•

m-Purchasing – mobilní B2B transakce určená pro nákup služeb a materiálu nutných pro výrobu či obchod; vždy se jedná o konkrétní nákupy, nikoli o kompletní zásobování; umožňuje obchodníkům nákup zboží přímo v místě potřeby; bývá součástí mProcurementu.

•

m-Procurement – mobilní zásobování, B2B vztahy, stálé doplňování zásob a udržení jejich stavů; umožňuje lépe plánovat kapacity a snížit náklady.

•

m-Care – mobilní péče o zákazníka, kontaktní zákaznická centra, bezplatné informační linky apod.

•

m-Tracking – umožňuje sledovat analýzy přístupů na WWW stránky a identifikovat zákazníka a jeho operace.

•

Mass Customization – speciální nabídky pro určité skupiny zákazníků, kterým jsou nabízené věrnostní programy, lepší služby, přednostní odbavení apod.

▪ 17 ▪


•

Powershopping - „Powershopping je založen na tom, že podnik sloužící jako zprostředkovatel nákupu vyhlásí zboží a odpovídající cenu, která se liší podle počtu zákazníků. Cena je tak stanovena až nakonec, kdy je počet zákazníků znám;“ [10]

v

dnešní době velmi populární v podobě různých slevových portálů, například Slevomat aj. V seznamu záměrně chybí dvě hlavní aplikace: m-shop a m-payment. Tyto aplikace se přímo dotýkají oblasti mé práce, a proto se jim budu věnovat ve vlastních kapitolách.

9.2

M-Payment

M-payment jsou mobilní platby, které umožňují bezhotovostní a elektronickou formou pomocí mobilního zařízení poukázat potřebné finanční částky. Jejich výhodou oproti platbám přes internet je dostupnost mobilního zařízení na rozdíl od klasického PC, protože většina uživatelů má mobilní zařízení stále u sebe. Další nespornou výhodou jsou lepší možnosti autorizace, například

s

využitím funkcí SIM karty. Mobilní platby lze využít k placení široké škály služeb, digitálního

i

fyzického zboží, je možné nakupovat hudbu, videa, vyzváněcí tóny a melodie, hry, prémiové účty her a aplikací, tapety, digitální publikace, jízdenky MHD, vstupenky a tak dále. Mobilní platby jsou relativně novou záležitostí. Jejich vývoj závisel na pokročilosti mobilních techno logií a na ochotě mobilních operátorů a bankovních ústavů tyto technologie podporovat. ké republice se první mobilní platby objevily v roce 1999, kdy je mobilní operátor Paegas

V Čes(v

dnešní době T-mobile) předvedl na veletrhu Invex nápojové automaty. V těchto automatech bylo možné platit nápoje za použití mobilního telefonu, nicméně nikdy nedošlo k masovému rozšíření. Následovalo zavedení GSM bankingu ve spolupráci Expandia banky a Paegasu, který již byl mnohem úspěšnější. V současné době existují čtyři hlavní směry v mobilním placení:

9.2.1

•

Premium SMS.

•

Přímé zpoplatnění u operátora.

•

Mobilní webové platby.

•

Bezkontaktní NFC (Near Field Communication).

Premium SMS

Prémiové SMS jsou v České republice podporovány všemi mobilními operátory. Jedná se o speciální SMS zprávy s navýšenou tarifikací, které umožňují pomocí mobilního zařazení zaplatit

▪ 18 ▪


menší finanční částky, takzvané mikroplatby. Existují dva druhy prémiových SMS: Moblie Originated a Mobile Terminated. Liší se tím, že je zpoplatněna odchozí (Mobile Originated) či příchozí (Mobile Terminated) zpráva. V České republice jsou v převážné většině používány zprávy Mobile Originated. Uživatel nakupující službu nebo zboží odešle SMS v definovaném formátu na definované číslo, obratem obdrží speciální kód, který použije pro získání přístupu k požadovanému zboží, například zadáním do stahovacího formuláře. Prémiové SMS však trpí několika závažnými nedostatky: •

Nízká spolehlivost – platební transakce může selhat v případě ztráty/nedoručení zprávy.

•

Nízká rychlost – odeslání zprávy trvá relativně dlouho, obchodník může obdržet potvrzení platby po delší době, zákazníci však nejsou ochotni čekat déle než několik sekund.

•

Bezpečnost – zprávy nejsou nijak šifrovány.

•

Vysoké poplatky – cca 50% placené částky připadne operátorovi, respektive agregátorům, kteří platby pro operátora zprostředkovávají.

Výše poplatků a omezení výše platby tuto platební metodu předurčují k placení za drobné zboží či služby v rámci vztahu B2C, tzn. prodej koncovým zákazníkům.

9.2.2

Přímé zpoplatnění u operátora

O přímé zpoplatnění se jedná pokud uživatel zaplatí obchodníkovi pomocí svého mobilního telefonu tím způsobem, že placená částka je zákazníkovi stržena z kreditu, nebo je mu v případě tarifního zákazníka vyúčtována v rámci pravidelného měsíčního vyúčtování operátorem. Tuto službu u nás nabízejí všichni tři největší operátoři, příkladem může být služba m-platba nabízená společnos tí T-Mobile. Princip je jednoduchý: zákazník dodá prodejci číslo jeho telefonu, prodejce vyšle žádost o autorizaci pomocí SMS ve tvaru: „Obchodník XY žádá o autorizaci nákupu zboží ZY v ceně XYZ Kč“, zákazník potvrdí zprávu zadáním PIN kódu a dočasného hesla a částka je mu stržena z kreditu, či započítána do měsíčního vyúčtování. Výhody tohoto platebního způsobu jsou: •

Bezpečnost – dvou-faktorová autorizace jako prevence zneužití.

•

Pohodlí - žádná registrace či instalace dodatečného softwaru do zařízení.

•

Rychlost – transakce může být dokončena řádově v sekundách.

Přímé zpoplatnění je opět využíváno v B2C vztazích.

▪ 19 ▪


9.2.3

Mobilní webové platby

V případě mobilních webových plateb používá zákazník pro placení webové stránky nebo speciální aplikace nainstalované do telefonu. Využíván je WAP protokol, nebo wifi, pokud je telefon wifi modulem vybaven a nějaká wifi síť je dostupná. Existují dva hlavní způsoby mobilních webových plateb, které jsou však společné i pro e-commerce platby: •

Platby elektronickou peněženkou.

•

Platby platebními kartami.

Elektronická peněženka funguje podobně jako bankovní účet. Jedná se o on-line elektronický pla tební systém podporující mikro- i makroplatby. Vzhledem ke skutečnosti, že se jedná o on-line sys tém, jsou platby neporovnatelně rychlejší a obvykle i levnější než doposud zmíněné způsoby pla cení. Elektronická peněženka není vázána na žádný bankovní účet, lze jí dobít převodem

z

libovolného bankovního účtu či jiné elektronické peněženky. Samotná platba je velmi rychlá

a

jednoduchá. Samozřejmostí je přístup do webového administračního rozhraní, kde uživatel spravuje svůj účet, méně samozřejmou věcí je možnost spravovat účet pomocí SMS či e-mailu.

V ČR

jsou dostupné všechny ve světě rozšířené elektronické peněženky: PayPal, MoneyBookers, GoPay, PayPay, dále český PaySec od ČSOB nebo mPeníze od mBank. Asi nejvýraznějším kladným rysem elektronických peněženek je bezpečnost, na níž se podílí několik dále popsaných faktorů. Zákazník si do elektronické peněženky převádí většinou pouze nižší částky, potřebné

k

běžným platbám, na rozdíl od běžného bankovního účtu, kde se většinou nachází celý objem finančních prostředků zákazníka. Tím se eliminuje riziko, že zákazník přijde o všechny své prostředky v případě zneužití elektronické peněženky. Dalším faktorem je absence uvádění citlivých a obecně zneužitelných dat při provádění platby. Zajímavá je také možnost nastavení limitu platby, při jehož překročení je k autorizaci platby potřeba nejen uživatelské jméno a heslo, ale je nutné platbu autorizovat vložením jednorázového hesla, zaslaného na mobilní telefon pomocí SMS. Tuto službu nabízí například český PaySec. Platby platebními kartami jsou univerzálním platebním prostředkem. Existuje mnoho druhů platebních karet, ale v ČR se většinou setkáme s debetními a kreditními kartami, které jsou vydané dvěma největšími asociacemi: VISA a MasterCard. Tyto karty lze dále rozdělit na elektronické a embosované. V ČR jsou nejrozšířenější elektronické platební karty, které lze využít pouze k on-line transakcím jako například k výběru z bankomatu nebo k úhradě částky za nákup na platebních terminálech v obchodech. Embosované karty je pak možné využít ke všem on-line transakcím, přičemž navíc umožňují díky plasticky vystouplým údajům na kartě platbu pomocí takzvaného imprinteru, který tyto údaje dokáže mechanicky okopírovat. Po okopírování údajů je třeba ještě podpis majitele karty a často ještě hlasová autorizace. V poslední době dochází též

k rozmachu

takzvaných virtuálních platebních karet. U těch zákazník nevlastní plastovou kartu, ale disponuje

▪ 20 ▪


pouze s údaji jako je číslo karty, CVC kód apod. Tyto karty jsou určené převážně pro placení na internetu a je obvyklé, že jsou za účelem zvýšení bezpečnosti nákupu chráněny limitem výběru, který bývá nižší než u běžných karet. Platby přes internet nejsou v ČR zajišťovány vydavateli karet. Zprostředkovávají je partnerské banky pomocí systému 3D Secure. ČSOB, KB a eBanka používají platební bránu Pay MUZO od společnosti Global Payments, Česká spořitelna používá vlastní platební bránu. Systém 3D Secure umožňuje neposkytovat údaje o kartě obchodníkovi, ale tyto údaje poskytuje přímo bance. Informace o kartě jsou přenášeny pomocí šifrovaného HTTPS protokolu. Výhodou elektronické peněženky oproti platebním kartám jsou nulové či velmi nízké náklady pro obchodníky za přijímání plateb. Nevýhodou obou metod jsou vyšší požadavky na datové přenosy.

9.3

M-Shop

Mobilní obchod (m-shop) je založen na B2C vztahu. Může se jednat o e-shop optimalizovaný pro mobilní zařízení či o specializovanou aplikaci instalovanou do mobilního zařízení. Výhodou je opět trvalá dostupnost, zákazník tak nemusí nikam fyzicky cestovat a nakupovat může 24 hodin denně. M-shop tak představuje další příležitost pro obchodníky ve smyslu nového prodejního kanálu, který mohou zákazníci využít v situaci, kdy návštěva kamenného obchodu není možná. Názorným příkladem může být modelová situace, kdy zaměstnaný manžel zapomene na výročí svatby a svou chybu si uvědomí až cestou domů z práce, kdy je již většina obchodů zavřená nebo mimo dosah místa bydliště. V případě, že je tento muž majitelem chytrého telefonu a má nainstalovanou aplikaci, která je součástí platformy v této práci vznikající, přičemž dodavatelem vznikající platformou nabízené služby je majitel květinářství, pak je objednání květin až domů pomocí této platformy elegantním řešením celé situace. Příkladem stávajících m-shopů může být mobilní obchod nákupní galerie Vltava.cz jako zástupce skupiny m-shopů realizovaných v podobě pro mobilní zařízení optimalizovaných e-shopů nebo Android Market (obchod s hrami, aplikacemi a rozšířeními pro zařízení s Android OS) jako zástup ce m-shopů realizovaných pomocí speciálních aplikací instalovaných do mobilního zařízení.

▪ 21 ▪


10.

CLOUD COMPUTING

Cloud computing je model vývoje a používání počítačových technologií v prostředí internetu. [11] Zjednodušeně se jedná o poskytování služeb a aplikací provozovaných na serverech na internetu. Uživatelé tyto služby či aplikace nejčastěji využívají pomocí webových prohlížečů nebo specializovaných klientů. Výhodou je možnost využívat tyto služby v podstatě odkudkoli, stačí vlastnit počítač s připojením na internet, čímž také odpadnou náklady na pořízení specializovaného hardwaru a softwaru. S tím souvisí i nulové náklady na správu a údržbu hardwaru a softwaru, protože uživatel platí pouze poplatek za využití funkční služby či aplikace. V dnešní době je tento model nejvíce používán pro kancelářské aplikace (Google Documents, Microfost Office 365), online operační systémy (Chrome OS, iCloud), různorodá business řešení, ale i pro složité distribuované výpočty. Model cloud computingu umožňuje využívat oba dva distribuční modely, jak SaaS, tak i PaaS, který bude popsaný dále.

10.1.1

SaaS – Software as a Service

„SaaS (Software jako služba - Software as a Service) je model nasazení softwaru, kdy dochází k hostingu aplikace provozovatelem služby. Služba je dále nabízena zákazníkům přes internet. Eliminováním potřeb instalace a provozu aplikace na vlastních zařízení se SaaS v poslední době stává oblíbeným způsobem provozu aplikace. SaaS vznikla jako reakce na potřebu snižování nákladů na software, rychlého nasazení a outsourcingu. Využíváním SaaS mohou firmy také redukovat přímé náklady na nákup softwaru, jelikož náklady na licenci on-demand bývají menší a zároveň není potřeba například licence na servery.“ [3] V poslední době mohutného rozvoje internetu a přenosových kapacit sítí, se stal SaaS velmi populárním. Platforma vznikající v rámci této práce využívá model SaaS k distribuci mezi dodavatele. Dodavatelé si tak nemusí pořizovat vlastní hardware ani software a jediné, co potřebují, aby mohli platformu využívat, je osobní počítač s připojením na internet, což je pro naprostou většinu dnešních obchodníků naprostou samozřejmostí. S pojmem Saas souvisí ještě dva další pojmy: Cloud Computing a PaaS.

10.1.2

PaaS – Platform as a Service

Pokud nějaká společnost nabízí platformu jako službu (Platform as a Service), znamená to, že po skytuje kompletní prostředí, které je plně k dispozici na internetu a podporuje celý životní cyklus vývoje aplikace a poskytování webových služeb. [12] Takováto platforma tedy může nabízet prostředky pro design, vývoj aplikace, testování, nasazení a hosting, ale i podporu týmové práce

▪ 22 ▪


a webových služeb. Zástupci těchto služeb jsou například Google App Engine, Salesforce force.com nebo Amazon EC2. Platforma vznikající v rámci této práce bude ve své backendové části využívat Google App Engine (dále jen GAE).

10.1.3

Google App Engine

GAE je známá cloudová služba umožňující provozování webových aplikací zdarma, pokud nároky na aplikaci nepřesáhnou určitou mez. V případě, kdy přidělené prostředky pro danou webovou aplikaci nedostačují, poskytuje tato platforma placené navýšení přidělených prostředků. Zmíněnými prostředky jsou myšleny zdroje, přenosové kapacity, úložný prostor atd. GAE je součástí Google Cloud (dále jen GC) platformy. Velkou výhodou GC jsou otevřená apli kační rozhraní (API), umožňující integraci mezi všemi částmi GC, a tím i využití všech jeho funkcí. V současné době tvoří GC tři základní prvky: [13] •

základní služby v balíku Google Apps (Gmail, Dokumenty Google apod.),

•

vlastní aplikace – již zmíněné GAE,

•

aplikace třetích stran – Google Apps Marketplace.

Pro práci s aplikacemi a přístup k datům nabízí GC následující vstupní body: [13] •

webový prohlížeč – Chrome,

•

mobilní operační systém – Android,

•

cloudově orientovaný operační systém – Chrome OS.

Obrázek 1: Google Cloud platforma [13]

Pro přístup do této platformy, potažmo do GAE, je třeba mít zřízený Google účet. Tento účet je shodný např. s účtem pro přístup do Gmail služby, respektive jeden účet ovládá všechny služby a uživatel, který již má zřízen účet pro Gmail, má zároveň přístup ke všem ostatním službám.

▪ 23 ▪


11.

POPIS A FILOZOFIE PLATFORMY

Jak již bylo řečeno, platforma bude nabízena jako internetová služba, která bude dodavatelům poskytovat prodejní kanál prostřednictvím mobilních zařízení, tzv. „chytrých telefonů“. Tato mobilní zařízení představují unikátní nástroj k časově neomezené komunikaci se zákazníkem a jejich použití je jednodušší než v případě klasických webových aplikací.

11.1

Jak služba funguje

Služba bude prostřednictvím mobilní aplikace poskytovat zákazníkovi nabídku produktů jednotlivých dodavatelů. Mobilní aplikace bude zatím dostupná pro mobilní platformu Android,

v bu -

doucnosti se dá také uvažovat o platformách iPhone, iPad, Windows Mobile, Blackberry či Symbian. Tato služba se zaměřuje na prodej produktů tzv. donáškového stylu, jedná se tedy

o pro -

dukty, které kurýr dodavatele v krátké době doručí na konkrétní místo. Tato služba má za úkol zprostředkovat obchod mezi zákazníkem a dodavatelem, tj. umí vytvořit objednávku, nechat za ni zákazníka zaplatit, přičemž o realizaci objednávky se stará výhradně dodavatel. Ve chvíli, kdy je dodavateli prokazatelně doručena informace o uzavřené objednávce, kompetence služby končí a přebírá ji dodavatel ve smyslu realizace pohledávky vůči zákazníkům.

Obrázek 2: Fungování služby

11.2

Mobilní aplikace

Mobilní aplikace může být dvojího druhu: •

Společná aplikace - aplikace, která nabízí produkty více dodavatelů, přičemž je nabízen jeden typ produktů. Tato aplikace je unikátní v rámci jednoho státu. Lze ji při-

▪ 24 ▪


rovnat např. k aplikaci Navigon, navigaci do automobilů, která má pro každou zemi aplikaci s jinými mapami. Služba, pomocí které bude navrhovaná platforma nabízena, bude mít například aplikaci pro prodej květin, ve které se budou nabízet květiny distribuované pouze v České republice. Vznik a vývoj jednotlivých aplikací pro další země bude probíhat v následujících etapách vývoje platformy a bude se přizpůsobovat aktuální poptávce dodavatelů. Společné aplikace budou patřit do předem definovaných kategorií podle toho, jaké produktové portfolio se v těchto aplikacích bude nabízet. •

Aplikace na míru - aplikace, která nabízí produkty pouze jednoho konkrétního dodavatele. Pokud dodavatel usoudí, že se nechce dělit o prodejní kanál s dalšími dodavateli, je mu platforma schopna nabídnout aplikaci na míru, kde může nabízet své produkty pouze on. Nicméně tato aplikace má stejný prodejní mechanismus a funkce jako společná aplikace, jedná se např. o košík, registraci zákazníka atd.

Obrázek 3: Kategorie mobilních aplikací

Za užívání této služby je dodavatel povinen platit. Možností placení je několik, zejména v prvních etapách vývoje platformy bude záležet na konkrétní dohodě s jednotlivými dodavateli. V podstatě existují dva typy placení za tuto službu: •

Procenta z každé uskutečněné objednávky - dodavatel bude odvádět určité procento z každé zaplacené objednávky podle předem dohodnutých podmínek.

▪ 25 ▪


•

Měsíční poplatek + platba za zřízení služby - dodavatel bude měsíčně odvádět paušální poplatek a při aktivaci této služby zaplatí manipulační poplatek.

11.3

Přidaná hodnota služby

Hlavní výhody služby vůči internetovému obchodu jsou (řazeno dle důležitosti): •

Zákazník, který využívá tuto službu, získá jednoduchý nástroj, který mu umožní realizovat objednávku produktů v situaci, kdy nemá k dispozici počítač s přístupem na internet.

•

Pro produkty, které se budou prostřednictvím služby nabízet (květiny, pizza, alkohol), se tento způsob nákupu může stát velmi elegantním a někdy i jediným řešením, například nákup květin prostřednictvím služby v situacích, kdy zákazník potřebuje vyřešit nákup květin rychle a diskrétně, typicky mimo domov, např. v restauraci.

•

Služba umožňuje realizovat neplánované a impulsivní nákupy velmi jednoduchým způsobem.

•

Mobilní telefon má dnes každý u sebe a přívětivost UI a UX je mnohem větší než u klasických webových aplikací.

•

Každému dodavateli služba umožňuje v podstatě snadný přímý prodej, protože nemusí vyvíjet vlastní e-shop či podobnou mobilní aplikaci.

•

Díky různým portfoliím produktů si každý zákazník velmi jednoduše stáhne aplikaci podle vlastní volby produktů.

▪ 26 ▪


Obrázek 4: Přidaná hodnota z pohledu zákazníka

Obrázek 5: Přidaná hodnota z pohledu dodavatele

▪ 27 ▪


11.4

Služba z pohledu dodavatele

11.4.1

Registrace do služby

Dodavatel se zaregistruje do služby prostřednictvím jednoduchého webového rozhraní, kde se bude umět zaregistrovat i dodavatel, který nemá žádný internetový obchod či zkušenosti s aplikacemi podobného typu. Dodavatel při registraci vyplní základní údaje o své firmě, případně o své osobě, pokud se nejedná o právnickou osobu. Jedná se o následující údaje: •

jméno a příjmení,

•

kontaktní email (bude sloužit jako jednoznačné ID),

•

heslo,

•

název společnosti,

•

IČO, DIČ,

•

další informace pro vystavení faktury zákazníkovi.

Dodavatel při registraci navíc z dostupných kategoriích zvolí druh produktu a stát, ve kterém bude prostřednictvím služby zákazníkům produkty nabízet, resp. bude si moct vybrat pouze takové kategorie a státy, pro které budou hotové společné mobilní aplikace. Dodavatel je povinen na konci samotné registrace souhlasit s obchodními podmínkami provozovatele služby, zejména s provizním modelem. Následné spravování dodavatelského profilu bude probíhat po přihlášení do webového administračního rozhraní.

11.4.2

Nabídka produktů prostřednictvím služby

V rámci registrace dodavatel vybere typ aplikace, tzn. společnou aplikaci či aplikaci na míru. V případě volby aplikace na míru dodavatel nastíní provozovateli svou hrubou představu o aplikaci a následně mu bude předložen návrh, který se bude na základě dalších požadavků zdokonalovat do konkrétní podoby aplikace (vlastní grafický design, nadstandardní funkce apod.). Pokud si dodavatel vybere prezentaci svých produktů formou společné aplikace na základě existujících kategorií a dostupných společných aplikací, vykoná následující: •

vybere společné aplikace, ve které chce produkty nabízet,

•

vloží produktové portfolium včetně kategorií produktů za podmínky, že počet produktů nabízených v jedné aplikaci jedním dodavatelem je limitován,

▪ 28 ▪


•

u produktů určí cenu s DPH, sazbu DPH, vloží event. popis a fotografii produktu, kód produktu a doplní jeho další charakteristiky (např. možnost uplatnění bonusu při koupi produktu, prodané množství aj.),

•

vybere z přednastaveného seznamu měst, popř. států, kde chce jednotlivé produkty nabízet a kam bude schopen je dodat s uvedením ceny za dopravu k zákazníkovi, času potřebného k doručení apod.

•

uvede dostupnost produktu, tzn. zda je produkt momentálně skladem,

•

vybere možnost využití případného bonusového systému a provizní model, ve kterém se má bonus počítat s možností nastavení bonusu pro jednotlivé aplikace odděleně.

11.4.3

Profil dodavatele

Profil dodavatele je základním rozcestníkem, kde může dodavatel prohlížet a upravovat následující údaje: •

registrační údaje,

•

seznam kategorií a v nich seznam aplikací, kde dodavatel nabízí své produkty,

•

města, ve kterých v rámci dané aplikace dodavatel své produkty nabízí,

•

obrázky produktů a detailní informace o těchto produktech v konkrétním městě.

Dodavatel si může na svém profilu zobrazit seznam objednávek. V seznamu jsou evidovány základní informace o objednávce, lze si zobrazit detail objednávky. U každé objednávky lze nastavit stav pro případ, že by chtěl být zákazník informován o tom, v jakém stavu se právě jeho objednávka nachází.

Obrázek 6: Nabídka produktu v rámci ČR a měst

▪ 29 ▪


11.5 11.5.1

Služba z pohledu zákazníka Registrace do služby

V každé mobilní aplikaci, kterou si zákazník nainstaluje na své mobilní zařízení, je možné provést registraci, která pro použití služby není nutná, ale na rozdíl od neregistrovaných zákazníků přinese zákazníkovi benefity ve formě dalších funkcí, např. funkci oblíbené produkty. Při registraci zákazník uvede následující informace: •

jméno a příjmení,

•

email (jako jednoznačné ID),

•

heslo,

•

adresu,

•

telefonní číslo.

I přesto, že může být v rámci služby provozováno několik mobilních aplikací, je login zákazníka univerzální do všech mobilních aplikací. Tak se zákazník může přihlásit do všech mobilních aplikací služby.

11.5.2

Výběr produktů

Aplikace bude omezena možností nákupu produktů v danou chvíli pouze v rámci jednoho města. Cílem tohoto omezení je vyhnout se pro dodavatele nepříjemným skutečnostem, kdy produkt nebu de převzat zákazníkem při objednávce produktů z více měst od jednoho dodavatele

a

objednávka ze vzdálenějšího města se pozdrží, cena za dopravu bude vyšší apod. Zákazníkovi bude tedy nabídnuta objednávka produktů pouze v jednom městě, tj. dle místa aktuálního výskytu. Dalším omezením je umožnění nákupu produktů pouze od jednoho dodavatele, což brání konfliktům stran rozdílných cen za dopravu od různých dodavatelů a rozdílné doručovací doby.

Po

spuštění mobilní aplikace si tedy zákazník jako první volí město, kam bude chtít vybraný produkt dodat. Tato volba se později projeví i ve formuláři objednávky, ve kterém bude automaticky město vyplněno jako doručovací. Po volbě města je vygenerován seznam všech případných prodejců pro danou oblast, ze kterého si v dalším kroku zákazník vybere konkrétního dodavatele. Zákazník bude mít možnost zvolit jiné město s nabídkou zde dostupných dodavatelů a jejich produktů bez nutnosti opustit aplikaci. Po výběru nového města aplikace zákazníkovi nabídne možnost zapamatování si nové volby, tzn., že při dalším spuštění aplikace se již nebude zobrazovat dotaz na volbu města. V případě, že se zákazník nachází v jiném městě, než kde je služba

▪ 30 ▪


provozována a aplikace má “zapamatovanou” volbu jiného, většinou domovského města uživatele, zobrazí se po spuštění aplikace dotaz, zda si bude uživatel objednávat květiny pro své obvyklé město X nebo pro město Y, kde se právě nachází (aplikace bude využívat GPS). Poté, co zákazník vybere město a dodavatele, od kterého chce produkty objednat, se zobrazí seznam kategorií zboží s konkrétními produkty. Tyto produkty pak může dle výběru vložit do košíku.

11.5.3

Objednání produktů

Na úrovni košíku zákazník uvede některé údaje, aby mohl dodavatel objednávku realizovat, jde o základní osobní údaje jako jméno, telefon, adresa, formu platby, čas a formu doručení apod. Pokud se jedná o již registrovaného a aktuálně přihlášeného uživatele, bude služba schopná většinu těchto informací vygenerovat sama. Dále zákazník zkontroluje tyto údaje a potvrdí obchodní podmínky dodavatele, od kterého zboží kupuje. Zákazník za objednávku zaplatí a následně se celá objednávka odešle k vyřízení. Zákazník obdrží potvrzení o přijetí objednávky prostřednictvím e-mailu společně s fakturou k úhradě, registrovanému zákazníkovi se navíc přičtou bonusové body k jeho účtu. Služba může dále zákazníka pravidelně informovat o aktuálním stavu objednávky.

11.5.4

Registrovaný versus neregistrovaný uživatel

Rozdíl mezi registrovaným a neregistrovaným uživatelem/zákazníkem by měl být co největší v tom smyslu, aby registrace zákazníkovi přinášela maximální výhody a zákazníci tvořili objednávky jako registrovaní. Výhody registrovaných zákazníků spočívají v:

11.5.5

•

možnosti přidávat vybrané produkty do oblíbených,

•

editaci vlastního profilu,

•

zjednodušení objednávky předvyplněním údajů z profilu zadaných při registraci,

•

využívání bonusového programu, pokud ho dodavatel poskytuje.

Profil

Profil je přístupný pouze pro registrované zákazníky. Profil zákazníka obsahuje: •

oblíbené produkty v rámci aplikace,

•

historii objednávek v rámci aplikace včetně možnosti znovu zaslání faktury z některé předchozí objednávky,

•

stav bonusového účtu v rámci služby,

▪ 31 ▪


•

možnost zrušení registrace,

•

osobní údaje zákazníka vyplněné při registraci, umožňující pohodlný nákup.

11.6

Etapizace

Vzhledem k rozsahu prací nutných k implementaci platformy v rozsahu uvedeném v předchozích kapitolách, je přistoupeno k etapizaci celého projektu. To znamená, že implementace projektu bude rozdělena do několika částí (etap), které budou implementovány postupně. Zároveň budou jednotlivé etapy sloužit k ověření konceptu platformy a umožní eventuální úpravy a změny. Pro za chování požadovaného rozsahu závěrečné bakalářské práce bude jako praktická ukázka implementace platformy sloužit pouze první etapa, jejíž popis následuje v další kapitole. Druhá etapa pokrývá zbývající funkce neimplementované jako součást etapy první. Třetí etapa zahrnuje zdokonalení a změny do budoucnosti tak, jak bude popsáno v závěru práce.

11.7

Popis první etapy

V rámci první etapy dojde k implementaci backendové části, která je společná všem mobilním aplikacím (viz. popis mobilních aplikací výše). Tato část nebude v první etapě umožňovat registraci a volbu mobilních aplikací, kategorií a produktů dodavatele pomocí UI rozhraní. Tato funkce bude prováděna servisně provozovatelem služby (viz. analýza backendové části). Webový backend bude sloužit jako zdroj dat pro mobilní aplikaci. Dále bude implementována pilotní mobilní aplikace, která bude takzvanou společnou aplikací (viz. popis mobilních aplikací výše) , bude provozována pouze v rámci jednoho města a bude zaměřena na prodej květin.

11.7.1

Popis mobilní aplikace v první etapě

Nákup zboží Zákazník si může vybírat zboží z několika kategorií. Po zvolení kategorie uživatelem se zobrazí seznam nabízeného zboží v dané kategorii. Každá položka obsahuje název, malou fotografii a cenu. Po výběru položky se zobrazí detail, který obsahuje název, velkou fotografii, textový popis zboží a cenu. Pro zobrazení detailu jiné kytice se uživatel může vrátit stisknutím tlačítka zpět na výpis položek kategorie, jednodušší alternativou je při procházení položek v rámci kategorie pouhé odrolování právě zobrazené položky vlevo (pro zobrazení následující kytice), nebo vpravo (pro zobrazení předchozí kytice). Dalším krokem je vložení vybraného produktu/květiny do virtuálního nákupního košíku, ve kterém je možné přejít k zaplacení a poté dokončit nákup (zadání doručovací

▪ 32 ▪


adresy, volba způsobu platby, samotné zaplacení). Po zaplacení jsou květiny doručeny na zadanou adresu, zákazník je o této skutečnosti vyrozuměn prostřednictvím e-mailu. Registrace zákazníka Zákazník se může registrovat. Registrace není povinná, ale umožní zákazníkovi v co největší míře zjednodušit objednávání tím, že se po registraci údaje z profilu automaticky generují do formulářů týkajících se všech zamýšlených objednávek, dále umožní využívat bonusového programu, pokud ho daný dodavatel nabízí. Způsoby platby a doručení Objednávka bude dodavateli předána vždy až po jejím zaplacení. Platba bude realizována elektronicky přímo prostřednictvím mobilního zařízení zákazníka pomocí platební brány dodavatele, v tomto případě pomocí 3D Secure České spořitelny. Jiné způsoby platby (dobírka, bankovní převod, apod.) nebudou v první etapě možné. Dodavatel dále zajišťuje dopravu objednaných květin na doručovací adresu, a to za stanovených smluvních podmínek. Objednávku spolu se všemi informacemi nutnými k její realizaci (popis a kód objednaného zboží, množství, adresa dodání, čas ob jednávky, číslo objednávky) obdrží dodavatel ihned po zaplacení květin e-mailem.

11.7.2

Popis webového backendu v první etapě

Webový backend bude sloužit jako zdroj dat pro mobilní aplikaci, se kterou bude komunikovat pomocí protokolu JSON-RPC (viz. kapitola o analýze backendové části). Obsahovat bude veškerá data potřebná pro mobilní aplikaci: seznam kategorií, produktů, všechny potřebné obrázky, údaje o registrovaných uživatelích apod. Data o kategoriích a produktech poskytne dodavatel vyplněním tabulky v sešitu aplikace OpenOffice, a po úpravě a převedení dat do formátu csv budou nahrána na server, na kterém bude webový backend provozován. Díky použití Cloud Platformy budou tyto operace jednoduché a rychlé.

▪ 33 ▪


12.

ANALÝZA A NÁVRH ŘEŠENÍ APLIKACE

Jistý úhel pohledu na aplikaci jako takovou přináší již předchozí kapitola týkající se rozsahu 1. etapy. Tato kapitola je nastíněním zadání mobilní aplikace. Na základě analýzy tohoto zadání byly identifikovány skutečnosti popsané v následujících podkapitolách.

12.1

Aktéři v aplikaci

Název

Popis

Cíle

Zákazník

Zákazník užívající aplikaci nainstalovanou v mobilním zařízení

Spokojený nákup květin

Dodavatel

Dodavatel zboží (prodejce)

Úspěšný prodej

Systém

Aplikace, v případě, kdy provádí akce na pozadí bez vědomí zákazníka či dodavatele

Bezproblémová obsluha požadavků

Tabulka 2: Aktéři

12.2

Procesy aplikace

ID Procesu

Název

Poznámka

P01.01

Výběr květiny

Výběr květiny z jedné z kategorií a její vložení do košíku

P01.02

Objednání květiny

Objednání květiny a následná platba

P02.01

Registrace zákazníka

Registrace zákazníka do aplikace

P02.02

Správa profilu zákazníka Editace profilu, správa seznamu objednávek

Tabulka 3: Identifikované procesy

▪ 34 ▪


P01.01 Výběr květiny – diagram EPBE

Obrázek 7: P01.01 – Výběr květiny P01.01 Objednání květiny – diagram EPBE

Obrázek 8: P01.02 - Objednání květiny P02.01 Registrace zákazníka – diagram EPBE

Obrázek 9: P02.01 Registrace zákazníka

▪ 35 ▪


P02.02 Správa profilu zákazníka – diagram EPBE

Obrázek 10: P02.02 Správa profilu zákazníka

▪ 36 ▪


P01.02 Objednání květin - activity diagram

Obrázek 11: Activity Diagram - P01.02 Objednání květin

▪ 37 ▪


12.3

Identifikované požadavky

12.3.1

Funkčnost:

01 Výběr produktu: •

R001 Výběr květin - zákazník může z různých kategorií vložením do košíku vybrat jakoukoli květinu v libovolném množství.

•

R002 Zobrazení kategorie - každá květina je zařazena nejméně do jedné kategorie, tzn., že může být přiřazena do kategorie podle ceny, ale i podle druhu květiny. např. Kytice patří do kategorie Květina do 499,- a zároveň se jedná i o Smuteční kytici. Uživateli se po spuštění aplikace zobrazí seznam veškerých kategorií, které jsou k dispozici. Tento seznam kategorií se načítá z webové aplikace pomocí webové služby a v každém okamžiku je aktuální. Uživatel si zvolí kategorii květin, které chce zobrazit. Po zvolení kategorie uživatelem se zobrazí seznam kytic v dané kategorii, kde každá položka obsahuje název, malou fotografii a cenu.

•

R003 Zobrazení detailu květiny - lze zobrazit detail květiny obsahující všechny informace o dané květině.

•

R004 Text blahopřání - text blahopřání může být nastaven ke každému kusu položky v košíku, a to i v případě, že položka obsahuje více kusů stejné květiny.

•

R005 Zobrazení košíku a operace s ním - každý zákazník má pouze jeden košík. U každé položky v košíku lze měnit její množství, je možné položku z košíku i zcela smazat. Ikona košíku je zobrazena v záhlaví mobilní aplikace. Obsah košíku se zobrazuje jako seznam květin tak, že na konci seznamu je možnost objednat, případně smazat obsah košíku. Jakmile zákazník přidá do košíku alespoň jednu položku květiny a má nastaven způsob odběru kurýrem, přičte se automaticky položka za dopravné.

02 Objednání: •

R006 Způsob doručení - možnost volby doručení kurýrem nebo osobního odběru.

•

R007 Objednání květin - zákazník musí vyplnit informace o doručiteli a odběrateli, vybere způsob platby a zaplatí pomocí vybraného způsobu platby. Zákazníkovi se poté automaticky odešle e-mailem informace o úspěšném objednání spolu s fakturou, dodavatel obdrží tím samým způsobem informaci o objednávce.

▪ 38 ▪


•

R008 Informace o doručiteli - informace o tom, komu a jakým způsobem se mají květiny doručit: jméno, příjmení, případně název firmy/společnosti, adresa, telefon, instrukce pro doručení.

•

R009 Informace o zákazníkovi - informace o tom, kdo objednává: jméno, příjmení, adresa, e-mail, telefon, název společnosti.

•

R0010 Informování zákazníka o přijetí objednávky, generování faktury - po zaplacení objednávky bude zákazníkovi odeslán e-mail potvrzující úspěšnou platbu

a při -

jetí objednávky. Zároveň bude poslána faktura obsahující informace o zákazníkovi, dodavateli a předmětu objednávky. •

R011 Informování dodavatele o objednávce - dodavatel bude o objednávce informován e-mailem s informacemi o zákazníkovi, doručiteli, obsahu košíku, ceně objednávky, bonusových bodech, s datem a časem uskutečnění objednávky.

•

R012 Informace o dodavateli - konstantní informace o dodavateli: název a adresa firmy, IČO, DIČ a číslo účtu dodavatele. Tyto informace budou uloženy v databázi.

•

R013 Přičtení bonusu - registrovaný a přihlášený zákazník získá za každý svůj nákup bonusové body. Pomocí bonusových bodů může zákazník uplatnit slevu na objednávce, jedná se o virtuální měnu.

•

R014 ID objednávky - číselný kód objednávky, např. první objednávka bude mít číslo 1100001, další pak 1100002 atd.

03 Zákazník: •

R015 Registrace zákazníka - registrace zákazníka probíhá pouze z mobilní aplikace, ve které zákazník vyplňuje: jméno, příjmení, e-mail, heslo, adresu, telefon, a nepovinně firmu, IČO, DIČ. Zákazník musí souhlasit s obchodními podmínkami. Poté zákazník obdrží e-mail s potvrzením registrace. Po ukončení registrace bude zákazník automaticky přihlášen do mobilní aplikace.

•

R016 Přihlášený zákazník - přihlášený zákazník může využívat veškeré dostupné funkce aplikace.

•

R017 Změna hesla zákazníka - zákazníkovi musí být umožněna změna hesla.

•

R018 Od-registrace zákazníka - pomocí funkce od-registrace zákazník může zrušit svůj účet. Zrušením účtu se rozumí zablokování účtu, tj. nastavení stavu účtu zákazníka tak, že se nebude moci přihlásit.

▪ 39 ▪


•

R019 Změna údajů v profilu zákazníka - zákazník může editovat všechny údaje v profilu, s výjimkou e-mailu, který v aplikaci slouží jako jednoznačné ID.

•

R020 Výpis výše bonusu u přihlášeného zákazníka - zákazník může zobrazit výši svého bonusu.

•

R021 Historie objednávek - přihlášený zákazník může zobrazit historii svých objednávek.

•

R022 Odhlášení zákazníka - umožňuje uživateli odhlášení z aplikace. Po odhlášení se zobrazí aplikace jako pro nepřihlášeného uživatele.

•

R023 Další funkčnosti na historické objednávce - umožní znovuzaslání potvrzení objednávky e-mailem. Totéž platí také pro fakturu.

12.3.2

Použitelnost: •

Systém by měl být navržen tak, aby jeho obsluha byla co nejjednodušší a co nejvíce intuitivní. To platí jak pro pořizování vstupů (externích i interních), tak i pro způsob pre zentace informací.

•

Uživatelské grafické rozhraní bude zpracováno striktně dle grafického manuálu dodaného zadavatelem. Veškeré další grafické prvky budou konzultovány

a

schvalovány zadavatelem a do designu zapracovány po podpisu souhlasu

s

návrhem. •

Česká a anglická dokumentace k aplikaci, dokumentace pro dodavatele.

•

Zdrojový kód bude obsahovat patřičné komentáře.

•

Systém bude v první fázi pouze v českém jazyce, ale v budoucnosti se počítá s pokrytím i dalších jazyků.

12.3.3

Spolehlivost: •

Spolehlivost systému 99,9%.

•

Pravidelná údržba probíhá kontinuálně bez ovlivnění provozuschopnosti aplikace. To je umožněno použitými technologiemi, kdy GAE umožňuje deploy za provozu a mobilní aplikace jsou updateovány pomocí AppStore, respektive Android Marketu.

▪ 40 ▪


12.3.4

Výkon: •

12.3.5

Systém bude schopen obsloužit několik (řádově desítky) uživatelů najednou.

Podpora: •

12.3.6

Bude provozováno Help Line číslo a podpora pomocí e-mailu.

Jiné požadavky: •

Bude použita technologie Android pro mobilní aplikaci, Google App Engine pro backendovou část, poskytující zdrojová data pro mobilní aplikaci, a technologie JSONRPC pro vzájemnou komunikaci.

▪ 41 ▪


12.4

Přehled use-case

Název

Popis

UC01.01

Výběr květiny

UC01001

Zobraz detail květiny

UC01002

Zobraz seznam květin

UC01003

Zobraz kategorie

UC01004

Vlož květinu do košíku

UC01005

Zobraz košík

UC01006

Uprav počet kusů květiny

UC01007

Smaž květinu z košíku

UC01008

Smaž obsah košíku

UC01009

Použij bonus na košíku

UC01010

Uprav text blahopřání

UC01.02

Objednání

UC01020

Vytvoř objednávku

UC01021

Zruš objednávku

UC01022

Přičti bonus zákazníkovi

UC01023

Zaplať objednávku

UC01024

Vytvoř fakturu za objednávku

UC01025

Pošli objednávku zákazníkovi

UC01026

Pošli objednávku dodavateli

UC02.01


UC02001


UC02002

Od registrace zákazníka

UC02003

Přihlášení zákazníka

UC02004

Odhlášení zákazníka

UC02.02

Správa profilu zákazníka

UC02010

Zobraz profil zákazníka

UC02011

Zobraz objednávky zákazníka

UC02012

Uprav profil zákazníka

UC02015

Zobraz bonus zákazníka

UC02019

Zobraz objednávku zákazníka

UC02020

Pošli historickou objednávku zákazníkovi

UC02021

Zruš nezaplacenou objednávku

UC02022

Seřaď seznam objednávek zákazníka

Tabulka 4: Přehled UC

▪ 42 ▪


12.4.1

Přehled mapování požadavků na use-case 01 Výběr produktu

UC01.01

02 Objednání

03 Zákazník

X

UC01.02

X

UC02.01

X

UC02.02

X

Tabulka 5: Mapování požadavků na UC

▪ 43 ▪


12.5

Use-case diagramy

12.5.1

UC01.01 Výběr květiny

Obrázek 12: UC01.01 Výběr květiny

▪ 44 ▪


12.5.2

UC01.02 Objednání

Obrázek 13: UC01.02 Objednání květiny

▪ 45 ▪


12.5.3

UC02.01 Registrace zákazníka

Obrázek 14: UC02.01 Registrace zákazníka

▪ 46 ▪


12.5.4

UC02.02 Správa profilu zákazníka

Obrázek 15: UC02.02 Správa profilu zákazníka

▪ 47 ▪


12.6

Doménový model

Již ze zaměření aplikace vyplývá, že její hlavní entitou je objednávka, která je vytvořena ve chvíli, kdy se zákazník rozhodne koupit obsah košíku. Košík plní výběrem zboží z jednotlivých kategorií. Po koupení košíku a vytvoření objednávky je generována faktura, po jejímž zaplacení je vyexpedováno objednané zboží dodavatelem.

Obrázek 16: Doménový model

12.7

Objednávka a její stavy

Vzhledem k povaze aplikace je objednávka stěžejním objektem celé aplikace. Od svého vytvoření objednávka nabývá několika různých stavů, díky čemuž lze zachytit, jakou fází své existence objednávka právě prochází. Všechny stavy a životní cyklus objednávky popisuje následující schéma.

▪ 48 ▪


Obrázek 17: Životní cyklus objednávky

12.8

Návrh uživatelského rozhraní

Uživatelské rozhraní je vzhledem k charakteru aplikace orientováno pevně na výšku pomocí XML atributu (android:screenOrientation="portrait") všech aktivit v manifestu aplikace. Ovládací prvky aplikace jsou navrženy a implementovány s ohledem na dotykové ovládání. Kompletní návrh uživatelského rozhraní je součástí přílohy číslo 1.

▪ 49 ▪


13.

IMPLEMENTACE MOBILNÍ APLIKACE

Mobilní aplikace je napsána v jazyce Java a vývoj probíhal v prostředí Eclipse IDE rozšířeném o plugin pro vývoj aplikací pro Android OS. Minimální verze SDK pro platformu android je 7, aplikace je tedy určena zařízením s verzí Androidu 2.1 a vyšší.

13.1

Aplikační business class model

V tomto modelu jsou obsaženy všechny třídy potřebné pro implementaci business logiky aplikace. Model neobsahuje všechny třídy aplikace, vynechány jsou všechny třídy, za jejichž vznikem stojí použití Android platformy. Jedná se především o jednotlivé aktivity aplikace, použité vlastní grafické komponenty, adaptéry apod. Class model mobilní aplikace je součástí přílohy č. 1.

13.2

Struktura aplikace

Aplikace je dělena do několika balíků, které spojují korespondující funkcionality. V rámci této aplikace je využito několik obecných vzorů, jejichž popis bude následovat v následujících kapitolách tak, jak budou použity.

cz.barcik.mplatform Základní balík celé aplikace.

cz.barcik.mplatform.activity Balík obsahující všechny aktivity mobilní aplikace.

cz.barcik.mplatform.application Implementace hlavní aplikační třídy dědící od Application.

▪ 50 ▪


cz.barcik.mplatform.business Balík obsahuje třídy reprezentující objekty business logiky, například kategorie, objednávka, zákazník a další. Pokud se jedná o třídy objektů ukládaných do databáze, jsou tyto třídy patřičně anotovány podle pravidel daných knihovnou ORMLite.

cz.barcik.mplatform.components Balík pro vlastní implementace UI komponent, například tlačítek či textových polí.

cz.barcik.mplatform.db V tomto balíku se nachází implementace třídy pro přístup k databázi (DatabaseHelper), dále obsahuje takzvané adaptéry, což jsou třídy, které zprostředkovávají data různým UI komponentám, jako jsou seznamy či galerie.

cz.barcik.mplatform.jsonrpc Balík s implementací rozhraní pro komunikaci s webovým backendem pomocí protokolu JSONRPC.

cz.barcik.mplatform.services Balík s implementací metod používaných při komunikaci s webovým backendem.

cz.barcik.mplatform.tool Zde se nachází různé pomocné třídy, jako například implementace vyrovnávací paměti pro načítání obrázků ze serveru.

13.3

Aplikační data

Veškerá aplikační data jsou ukládána v relační databázi SQLite, která je součástí Android Platformy. Pro databázovou vrstvu je použita knihovna ORMLite, neboli zjednodušený framework pro ORM. Objekty jsou v tomto frameworku ukládány jako anotované POJO objekty do databáze za pomoci svého DAO objektu. [14] Použití tohoto frameworku výrazně zjednodušuje práci

▪ 51 ▪

s


databází. Centrem frameworku je rozhraní Dao se svou implementací BaseDaoImpl. Pro tvorbu jednotlivých instancí slouží factory třída DaoManager. Rozhraní Dao umožňuje provádět základní CRUD operace: uložení, načtení, úpravu a smazání a načtení objektů z databáze. Samozřejmostí je podpora transakcí, kterou zajišťuje třída TransactionManager. Volání transakcí je realizováno pomocí metody callInTransaction(). Jedním z parametrů této metody je objekt implementující rozhraní Callable. Voláním metody call() tohoto objektu se spouští požadovaná funkce v rámci jedné transakce.

13.4

Komunikace s webovým backendem

Veškerá komunikace mezi mobilní aplikací a webovým backendem probíhá za použití JSON-RPC 2.0 protokolu. Specifikace tohoto protokolu je dostupná na webové adrese http://groups.google.com/group/json-rpc/web/json-rpc-1-2-proposal. Způsob komunikace, jednotlivé metody použité ke komunikaci a další informace se nacházejí v kapitole 15.4 pojednávající o komunikaci webového backendu s mobilní aplikací.

13.5

Platební brána České spořitelny

Jak již bylo zmíněno výše, aplikace bude k placení využívat 3D Secure platební bránu České spořitelny. Veškerá komunikace s touto bránou probíhá pomocí standardního https protokolu. Popis konkrétního způsobu implementace této platební brány stojí mimo rozsah této práce, nicméně je důležité zmínit, že se procesu placení účastní jak mobilní aplikace, tak webový backend, viz. dále. Uživatel v mobilní aplikaci vytvoří objednávku, kterou se rozhodne zaplatit. Poté je mu v okně prohlížeče zobrazena stránka A, která je součástí webového backendu. Stránka A přijme GET para metry (ID objednávky, typ karty apod.) od mobilní aplikace. Pokud jsou všechny parametry

v

pořádku, webový backend automaticky přesměruje POST požadavek na 3D Secure bránu. Pokud je špatně zadáno ID objednávky, tzn., že neexistuje, nebo není ve stavu new, proběhne automa tické přesměrování na stránku E1. Pokud je špatně parametr typu karty, webový backend nabídne výběr z dostupných karet a umožní pokračovat v placení. 3D Secure brána po obdržení POST požadavku volá z webového backendu skript S1 a slouží pro validaci objednávky. Po úspěšné vali daci je opět předáno řízení aplikační bráně. Po validaci probíhá konfirmace pomocí skriptu S2. Konfirmace je proces podobný validaci, ale volá se až před zaplacením. Pokud proběhne bez problémů, je transakce považována za úspěšnou a objednávka se nastaví do stavu Paid. Podle toho, zda byla konfirmace úspěšná, je prohlížeč mobilní aplikace přesměrován platební bránou na

▪ 52 ▪


stránku OK, nebo NOK. Obě stránky zobrazí finální stav transakce a obě budou obsahovat tlačítko Zpět do aplikace.

Seznam použitých stránek a jejich zkratek:

13.6

•

A – úvodní stránka pro iniciaci placení

•

S1 – validační skript

•

S2 – potvrzovací skript

•

E1 – chybová stránka

•

OK – finální stránka při úspěšné transakci

•

NOK – finální stránka při neúspěšné transakci

Uživatelské rozhraní

Uživatelské rozhraní (UI) sestává ze zobrazovacích a ovládacích prvků, které jsou umístěny na požadovaných místech obrazovky. Rozložení těchto prvků je definováno pomocí hierarchie popisu s využitím XML. Všechny obrazovky UI jsou tvořeny pomocí XML a uloženy v samostatných sou borech. Tyto soubory se nacházejí ve složce res/layout.. Typický soubor popisující obrazovku obsahuje kořenový element určující rozložení prvků v něm. Těmito prvky mohou být jak další elementy popisující rozložení, tak elementy reprezentující koncové elementy ve smyslu textových polí, obrázků a tlačítek. Vzhled prvků, jejich pozice v rodičovském elementu či vztahy vůči dalším prvkům v rodičovském elementu jsou nastavovány pomocí atributů. Vlastnosti společné pro více prvků jsou definovány v souboru style.xml, který by se dal připodobnit k souboru css, resp. kaskádovým stylům v HTML. Šetří čas a práci při implementaci tím, že daný styl definujeme pouze jednou, a dále využíváme pouze odkazu na něj. Lze využít i dědičnost, díky které prvky se zděděnými atributy nemusí být znovu definovány. Globální vzhled je nastaven pomocí takzvaných témat, což jsou speciální varianty stylů definované na úrovni jednotlivých aktivit v souboru s manifestem aplikace (Android manifest). V souladu s problematikou výskytu odlišných typů displejů v různých mobilních zařízeních s OS Android je UI implementováno tak, aby na každém zařízení fungovalo bezproblémově. Toho je dosaženo dodržením několika doporučených technik. [15] Aplikace nikde nepoužívá absolutní hodno-

▪ 53 ▪


ty a rozměry, které jsou na místo toho jsou vyjádřeny a přepočítávány relativně s ohledem na právě používaný rozměr displeje. Všechny textové popisky v aplikaci jsou lokalizovány pomocí konstant v souboru strings.xml. Tento soubor existuje v této aplikaci ve dvou verzích, české a anglické, ale v případě rozšiřování aplikace o působnost v dalších státech by byl vytvořen další soubor s popisky v daném jazyce. Dalším typem použitého souboru je colors.xml, který obsahuje konstanty s definicí barev použitých v UI. Obdobně jsou využity soubory pro definici animací či kontextového menu. Všechny tyto sou bory s konstantami se nacházejí v adresáři res/values.

▪ 54 ▪


14.

IMPLEMENTACE WEBOVÉHO BACKENDU

Webový backend je napsán v jazyce Java a vývoj probíhal v prostředí Eclipse IDE rozšířeném o plugin pro vývoj GAE projektů. Použito je GAE SDK ve verzi 1.5.2.

14.1

Aplikační business class model

V tomto modelu jsou obsaženy všechny třídy potřebné pro implementaci business logiky webového backendu. Model neobsahuje všechny třídy aplikace, vynechány jsou třídy, za jejichž vznikem stojí použití GAE platformy. Jedná se především o jednotlivé servlety aplikace a jiné, například pomocné třídy. Tyto třídy, respektive balíky, ve kterých se třídy nachází, jsou popsány v následující kapitole. Class model webového backendu je součástí přílohy č. 2.

14.2

Struktura aplikace

Aplikace je dělena do několika balíků, které obalují spolu související funkcionality. V rámci této aplikace je využito několik obecných návrhových vzorů, jejichž popis bude následovat v dalších kapitolách tak, jak budou využity.

cz.barcik.mplatform.backend.gae Základní balík celé aplikace.

cz.barcik.mplatform.backend.business Balík s třídami, které reprezentují objekty business logiky, například kategorie, objednávka, zákazník a další. Třídy jsou anotovány podle JDO pro jejich ukládání do úložiště.

cz.barcik.mplatform.backend.data Tento balík obsahuje servlet pro nahrávání dat do úložiště.

▪ 55 ▪


cz.barcik.mplatform.backend.datanucleus Balík obsahující třídu PMF, což je singleton třída pro získání objektu (persistence manager), který je využíván pro přístup k úložišti.

cz.barcik.mplatform.backend.exception Jak již vyplývá z názvu, balík obsahuje třídy reprezentující výjimky používané na webovém backendu.

cz.barcik.mplatform.backend.jsonrpc Zde se nacházejí třídy implementující rozhraní pro komunikaci s mobilní aplikací pomocí JSONRPC protokolu. Jedná se především o servlet registrující příchozí požadavky, třídy pro parsování těchto požadavků, obslužnou třídu pro volání jednotlivých metod a pro obsluhu celého procesu zpracování požadavku, včetně ošetření chybových stavů.

cz.barcik.mplatform.backend.mail V tomto balíku jsou obsaženy třídy zajišťující odesílaní e-mailů s fakturami, objednávkami a informacemi o registraci. Obsah e-mailů je vytvářen z HTML šablon, do kterých jsou vyplňována potřebná data.

cz.barcik.mplatform.backend.service Na tomto místě jsou implementovány služby umožňující práci s business objekty v úložišti, tzn. jejich vytváření, úpravy, mazání a získávaní z úložiště.

cz.barcik.mplatform.backend.servlet.payment Balík, který obsahuje implementaci platební brány.

cz.barcik.mplatform.backend.ws Zde jsou implementovány jednotlivé metody definované v kapitole 14.4.4, tedy metody, které jsou volané jednotlivými požadavky mobilní aplikace. Dále se v tomto balíku nachází třídy DTO objektů.

▪ 56 ▪


DTO (Data Transfer Objekt) je objekt používaný pro přenos objektů business logiky. Jedná se o objekty vznikající z business objektů optimalizací pro přenos ve formátu JSON.

14.3

Aplikační data

Veškerá aplikační data jsou ukládána v GAE úložišti Datastore, které je součástí GAE Platformy a má svou vlastní databázovou vrstvu. GAE neumožňuje použít klasické SQL databáze a Datastore tak představuje jedinou možnost ukládání dat. Jedná se o distribuované objektové úložiště podporující technologie JPA a JDO pro persitenci javovských objektů.

Pro webový

backend je použita technologie JDO. Vzhledem k omezením tohoto úložiště není možné nahrávat data pomocí SQL skriptů. V první etapě není implementováno administrační rozhraní a je tedy tře ba zajistit naplnění úložiště daty jiným způsobem. Jak již bylo řečeno, data o produktech dodává dodavatel v podobě xls souborů, které jsou upraveny a převedeny do formátu csv. Tyto csv soubory s daty jsou nahrány na server. Na serveru je spuštěn servlet pro import dat, který načte csv sou bory s daty a vytvoří podle nich objekty, které uloží do Datastoru.

14.4

Komunikace s mobilní aplikací

Jak již bylo několikráte zmíněno, komunikace probíhá pomocí JSON-RPC protokolu, který umožňuje vzdálené volání procedur (metod) a pro přenos dat používá formát JSON. K zabezpečení komunikace se bude používat výhradně SSL respektive HTTPS formát. Protože na rozdíl od SOAP webových služeb nemá JSON-RPC nic podobného jako SOAP WSDL, bude webový backend poskytovat

seznam

volatelných

metod,

dostupný

na

adrese

https://mobilniplatforma.appspot.com/jsonrpc/list.

14.4.1

Serverové výjimky

Využíván je nativní JSON-RPC Error objekt, například: "error": {"code": 666, "message": "AuthException"}. Všechny výjimky webového backendu mají za účelem jasné identifikace kód 666. Jsou definovány čtyři obecné výjimky: •

AuthException – v případě selhání autorizace registrovaného uživatele tam, kde je vyžadována.

•

GeneralErrorException – obecná výjimka v případě chyby nespadající do podmínek ostatních výjimek.

▪ 57 ▪


•

ObjectNotFoundException – výjimka pro metody vracející objekt, která nastane v případě, že ID objektu dodané jako parametr volání není ID objektu nacházejícího se v databázi.

•

SecurityException – výjimka nastávající v případě, kdy se mobilní aplikace pokouší získat objekt, který nebyl vytvořen uživatelem, který aplikaci používá (například uživatel A chce získat objednávku č.1, přičemž tato objednávka byla vytvořena uživatelem B).

14.4.2

Autentifikace

Autentifikace bude probíhat pomocí objektu Auth, který bude parametrem každého requestu na webový backend. Kromě autentifikace jako takové bude objekt Auth určovat i jazyk odpovědi.

Obrázek 18: Objekt Auth

Heslo v poli password je hashováno pomocí algoritmu SHA1. Pokud nemá objekt Auth vyplněné sername, jedná se o neregistrovaného uživatele. Pokud je username vyplněné, musí být vyplněné i password a požadavek musí projít autentifikací, při které dochází ke kontrole, zda uživatel exis tuje, je použito správné heslo a uživatel je aktivní. Pokud je autentifikace neúspěšná, je vrácena výjimka AuthException.

14.4.3

Synchronizace dat

Data, u kterých to má smysl, jsou synchronizována mezi mobilní aplikací a webovým backendem. Celý mechanismus je řízen pomocí parametru lastUpdate. Pro ilustraci použiji kategorie zboží. Tyto kategorie jsou z webového backendu získávány voláním metody getCategories(Auth auth, Date lastUpdate) z mobilní aplikace (viz. popis metod v další kapitole). Jak je vidět, volání metody obsahuje parametr lastUpdate, který obsahuje datum a čas poslední úspěšné aktualizace dat v mobilní aplikaci. Při zpracování requestu na webovém backendu se tento údaj porovná

s da -

tem poslední aktualizace webového backendu a v případě, že od poslední aktualizace mobilní aplikace ke změně nedošlo, je mobilní aplikace informována o tom, že má data aktuální.

▪ 58 ▪


V opačném případě jsou mobilní aplikaci odeslána požadovaná data. Odpověď serveru pro případ synchronizované komunikace bude zapouzdřena v objektu TimedResponse.

Obrázek 19: Objekt TimedResponse Příklad komunikace: •

dotaz - {"jsonrpc": "2.0", "method": "getJidlo", "id": 1, "params":{"jmeno":"nevim", "lastUpdate":"032154165462165749874"}} ◦

odpověď v případě, kdy aktualizace není potřeba ▪

◦

{"jsonrpc": "2.0", "result":{"lastIsValid":true}, "id": 1}

odpověď v případě, kdy dochází k aktualizaci dat ▪

{"jsonrpc": "2.0", "result":{"lastIsValid":false, "response":["parek", "rohlik"], "updateTime":"032154165462165749999"}, "id": 1}

14.4.4

Metody

Při neúspěchu metody je vrácena chyba. To znamená, že na místo atributu result je vráceno error (viz. Kapitoly 15.4.1 a 15.4.3) a popis chyby. To platí i pro metody vracející boolean jako indikaci úspěšného provedení. Takové metody nikdy nevrátí false jako result ale místo objektu result bude objekt error. Id objektů je typu long a typ Date reprezentuje číslo (long), udávající počet milisekund uběhlých od 1.1.1970 00:00 GMT. Následuje výpis metod, dělených podle objektů, ke kterým se vztahují. Zákazník: •

registrace (UC02001) ◦

CustomerDTO ▪

◦

registerCustomer(CustomerDTO customer)

kontrola existence uživatele a jeho údajů

Výjimky:

▪ 59 ▪


▪

UsernameExistException - uživatel se stejným username (tj. e-mailem) již existuje

od-registrace (UC02002)

•

◦

boolean unregisterCustomer(Auth auth) ▪

změna stavu zákazníka na Pasive, vrací true pokud úspěšné

get (UC02003, UC02010)

•

◦

TimedResponse

getCustomer(Auth

auth,

Date

lastUpdate) ▪

vrací objekt zákazníka s ohledem na podmínky synchronizace výše

update (UC02012)

•

◦

TimedResponse updateCustomer(Auth auth,

Custo-

merDTO customer) ▪

aktualizuje údaje o zákazníkovi

get bonus (UC02015 a další)

•

◦

Integer getBonus(Auth auth) ▪

vrací výši uživatelova bonusu

◦

Integer getAvailableBonus(Auth auth)

•

vrací výši bonusu sníženou o bonusy specifikované v objednávkách (to znamená již použité výše bonusů) ve stavu New.

Produkt / Květina: •

seznam produktů v kategorii (UC01001) ◦

TimedResponse>

getProductsInCategory(Auth

auth, Date lastUpdate, id categoryId) ▪

vrací seznam produktů v dané kategorii, produkty obsahují atribut index, který určuje pořadí zobrazování v seznamu v mobilní aplikaci

•

detail produktu (UC01002) ◦

ProductDTO getProductDetail(Auth auth, id productId) ▪

vrací detail produktu

▪

▪ 60 ▪


Kategorie / Category •

seznam kategorií (UC01003) ◦

TimedResponse> getCategories(Auth auth, Date lastUpdate) ▪

vrací seznam kategorií

Objednávka / Order •

vytvoření objednávky (UC01020) ◦

id createOrder(Auth auth, OrderDTO order) ▪

◦

◦

vytvoří objednávku dle parametrů

OrderDTO na vstupu obsahuje: ▪

osoba, které se má doručit = DelivererDTO (povinné)

▪

fakturační údaje = auth + invoiceInfo

▪

další povinné údaje: delieryDate, price, payType, bonusValue

▪

orderItems = List - seznam položek objednávky

Výjimky: ▪

BadZipCodeException – pokud PSČ v doručovací adrese není dodavatelem podporováno

▪

InssuficientBonusException - pokud je dostupný bonus uživatele menší než uplatňovaný bonus (viz. getAvailableBonus)

▪

ProductClosedException – pokud objednávka obsahuje produkt, který již není aktivní (nabízený)

▪

IncorrectPriceException - pokud neodpovídá cena spočítaná mobilní aplikací ceně spočtené na webovém backendu

•

zrušení (UC01021) ◦

boolean cancelOrder(Auth auth, id id) ▪

◦

zruší objednávku, vrátí true při úspěchu, error při neúspěchu

Výjimky: ▪

OrderCannotBeCancelledException – při pokusu o zrušení objednávky v jiném než New stavu

▪ 61 ▪


•

get (vícero UC při objednávání) ◦

OrderDTO getOrder(Auth auth, id id) ▪

◦

vrací objednávku

OrderDTO na výstupu obsahuje: ▪

deliveree = DelivererDTO (povinné)

▪

invoiceInfo = CustomerDTO (fakturační údaje - null pokud jsou stejné jako údaje o daném zákazníkovi)

▪

customer = CustomerDTO (null pokud je zákazník registrován - v takovém případě je zákazník definován Auth objektem)

▪

orderStateSupport = OrderStateSupportDTO (poslední validní stav)

▪

orderItems = List seznam položek

▪

další povinné údaje: delieryDate, price, payType, orderDate (generován na serveru při vytvoření objednávky), idOrder (generováno na serveru při vytvoření objednávky), bonusValue

•

potvrzení zaplacení ◦

boolean finalizePaidOrder(Auth auth, id id) ▪

◦

Výjimky: ▪

•

potvrdí zaplacení objednávky

OrderWasCancelledException - pokud byla objednávka zrušena

zobrazeni objednávek registrovaného zákazníka (UC02011) ◦

TimedResponse>

getOrdersFromCustomer(Auth

Date lastUpdate) ▪ ◦

•

vrací všechny objednávky vytvořené registrovaným zákazníkem

OrderDTO obsahuje: ▪

deliveree = DelivererDTO

▪

orderStateSupport = OrderStateSupportDTO

▪

orderItems = List

zaslání faktury

▪ 62 ▪

auth,


◦

boolean sendOrderInvoice(Auth auth, id id) ▪

zašle fakturu na zákazníkův a dodavatelův mail3

zaslání informací o objednávce

•

◦

boolean sendOrderDetails(Auth auth, id id) ▪

zašle detailní popis objednávky na zákazníkův e-mail

Dodavatel / Supplier získání časů, po které dodavatel doručuje

•

◦

TimedResponse>

getDeliveryTimes(Date

lastUpdate, id supplierId) ▪

získá možné časy doručení

získání oblastí, ve kterých dodavatel doručuje

•

◦

TimedResponse>

getDeliveryAreas(Date

lastUpdate, id supplierId) ▪ ◦

získá možné oblasti doručení

v DeliverytownDTO je navíc obsaženo: ▪

seznam PSČ = List

▪

místo města/town se posílá jen townId

▪

lastUpdate se vztahuje na změnu názvu města a změny v seznamu PSČ

získání ceny dopravy

•

◦

Decimal getShippingPrice(id supplierId) •

14.5

vrací cenu dopravy daného dodavatele

Platební brána České spořitelny

Platební brána byla již dostatečně popsána v rámci předchozích kapitol, na tomto místě bych pouze rád nastínil jednotlivé servlety, které se starají o obsluhu jednotlivých kroků při placení. •

E1 - Invalid order ID: ◦

•

https://mobilniplatforma.appspot.com/payment/invalidorderid

A - Choose card brand:

▪ 63 ▪


◦ •

S1 - Validation URL: ◦

•

https://mobilniplatforma.appspot.com/payment/confirm

OK URL (úspěšná platba): ◦

•

https://mobilniplatforma.appspot.com/payment/validate

S2 - Confirmation URL: ◦

•

https://mobilniplatforma.appspot.com/payment/choosetype

https://mobilniplatforma.appspot.com/payment/paymentsuccessful

NOK URL (neúspěšná platba): ◦

https://mobilniplatforma.appspot.com/payment/paymentfailed

▪ 64 ▪


15.

BUDOUCNOST PLATFORMY

Ačkoliv cíle vytyčené v kapitole 11.7 byly splněny, je zde stále spousta prostoru pro vylepšování a rozšiřování funkcionality. Především se jedná o požadavky, které vyplývají z popisu platformy, ale nebyly zařazeny do první etapy. Další rozvoj platformy bude nadále probíhat v etapách. Etapy budou minimálně dvě.

15.1

Druhá etapa

V druhé etapě bude webový backend rozšířen o administrační rozhraní, které bude dodavatelům umožňovat správu objednávek. Administrační rozhraní bude zobrazovat seznam objednávek. Tento seznam bude možné řadit podle různých kritérií. Další možností zlepšení bude zobrazení detailu objednávky, nastavení její stavu (dokončení nebo zrušení objednávky) apod. Mobilní aplikace bude v druhé fázi rozšířena o následující funkčnosti: Svátky Aplikace bude zákazníkovi nabízet možnost rychlého zjištění jména osoby, mající v konkrétní den svátek, a to prostřednictvím rychlého vyhledávání v databázi svátků. U jednotlivých jmen si zákazník bude moci rovněž nastavit upozorňování na blížící se jmeniny blízké osoby. Připomínkovač Aby zákazník již nikdy nezapomněl na významná data jako narozeniny, svátky a různá výročí, může s výhodou využívat další funkci aplikace, která mu umožní jednoduchou evidenci těchto významných dnů, včetně možnosti automatického připomenutí se zvoleným časovým předstihem. Virtuální květiny Prostřednictvím této funkcionality může zákazník odeslat na e-mail nebo zeď příjemce na Facebooku virtuální květinu (tzn. obrázek) spolu s textem (např. blahopřání k narozeninám)

a

krátkou o tom, že květina byla odeslána prostřednictvím mobilní aplikace. Oblíbené Uživatel si bude moct označit produkty jako oblíbené, které pak aplikace umožní s rychlým přístupem zobrazit ve speciální sekci.

Po úspěšném dokončení druhé fáze a nalezení prvního dodavatele bude možné aplikaci nasadit do ostrého provozu.

▪ 65 ▪


15.2

Třetí etapa

V rámci třetí etapy dojde rozšíření administračního rozhraní na webovém backendu o funkce související s registrací dodavatelů, jejich produktů a měst, ve kterých je možno tyto produkty dodávat (viz. Kapitola 11). Podle zájmu dodavatelů dojde k implementaci dalších společných či specializovaných mobilních aplikací. Obsahem dalších etap bude převod aplikace i pro jiné mobilní platformy (iOS, BlackBerry apod.).

▪ 66 ▪


16.

ZÁVĚR

Cílem práce bylo navrhnout a implementovat e-commerce platformu pro mobilní zařízení s podporou webového backendu. Vzhledem k rozsahu navrhované platformy byla implementace rozdělena do několika etap, přičemž v rámci této závěrečné bakalářské práce byla implementována pouze první etapa. Je nutné podotknout, že návrh celé platformy i implementace první etapy byl dokončen podle plánu a veškerá očekávání od této platformy byla splněna. V teoretické části bakalářské práce byly definovány pojmy e-commerce, SaaS a m-commerce, související zkratky, pojmy a technologie a byly uvedeny základní typy aplikací, které se těchto pojmů dotýkají. Taktéž byl kladen důraz na možnosti placení v prostředí e-commerce/m-commerce vzhle dem k tomu, že součástí platformy je i platební brána sloužící k zaplacení objednaného zboží. Součástí teoretické části je i popis, filozofie a obchodní model služby, pomocí které bude platforma nabízena obchodníkům a dodavatelům, její výhody, nevýhody a přidaná hodnota pro obchodníky a dodavatele, kteří se rozhodnou tuto službu využívat. V praktické části byla provedena analýza a návrh architektury této platformy. Byly identifikovány základní požadavky na aplikaci, popsány základní UC a bylo navrženo základní uživatelské roz hraní aplikace. Dále byl popsán webový backend, jeho datový model, způsob komunikace s mobilní aplikací a způsob nahrávání dat do systému. Na tuto část navazuje popis implementace navrženého řešení a fyzická implementace platformy. V závěru práce jsou nastíněny možnosti dalšího zlepšování a rozšiřování platformy. Za velký přínos práce pokládám vznik obecné platformy pro prodej drobného zboží, tzn. Vznik platformy se širokou využitelností. Platforma nabízená jako služba přináší vysokou přidanou hodnotu prodejcům a otevírá jim nové komunikační kanály pro prodej jejich zboží. Vzniklá platforma je zároveň praktickou ukázkou možností mobilních zařízení v oblasti e-commerce. Za hlavní osobní přínos při tvorbě této práce pokládám studium nových technologií, například technologie platební brány, komunikace pomocí JSON-RPC, či vývoj webových aplikací na platformě Google App Engine. Dalším přínosem je seznámení se s problematikou elektronického ob chodování, dále také studium cizojazyčných zdrojů a v neposlední řadě též uvědomění si možností podnikání v oblasti e-commerce a vývoje aplikací pro mobilní aplikace.

▪ 67 ▪


17.

CONCLUSION

The aim of this thesis was to design and implement e-commerce platform for mobile devices with web browser backend. Given the scale of the proposed platform, the implementation was divided into several stages while only the first phase of the implementation was described and included into this thesis. It should be noted that the whole design of the platform together with its implementation was completed on schedule and all expectations of this platform have been met. In the theoretical part of the thesis the terms of e-commerce, SaaS and m-commerce were defined also with related abbreviations, concepts and technology and the basic types of applications that these concepts concern were introduced. Also the payment options in e-commerce/m-commerce environment were emphasised due to the fact that one part of the platform is a payment gateway used to pay for goods ordered. Part of the theoretical section of this thesis is a description, philo sophy and business model of services, through which the platform will be offered by retailers and suppliers, explaining its advantages, disadvantages and added value for retailers and suppliers who choose to use this service. In the practical part of the thesis, analysis and design architecture of the platform was conduc ted. Basic requirements for application were identified, basic UC were described and proposed a basic user interface was outlined. Further the web backend, the data model, the method of communication with the mobile application and method of loading data into the system were described. This section is followed by a description of the implementation of the proposed solution and the by a physical implementation of the platform. In the conclusion the possibilities for further improvement and development of the platform are outlined. As a large contribution of the thesis I consider the introduction of a general platform for the sale of retail goods, i.e. introduction of a platform with wide utility. The platform offered as a service provides high value-added to resellers and opens new channels for selling their goods. The final platform is also a practical example of the possibilities of mobile devices using-commerce. The main personal contribution in creating this work I see in the study of new technologies, such as payment gateway technology, communications using JSON-RPC, or the development of web applications using Google App Engine. Another benefit is the explanation of the issue of electronic commerce, as well as foreign language learning resources, and last but not least, creating an awareness of business opportunities in e-commerce and application development for mobile applications.

▪ 68 ▪


18.

SEZNAM POUŽITÉ LITERATURY

1. www.adaptic.cz : slovníček [online]. 2005-2011 [cit. 2011-06-23]. E-commerce. Dostupné z www: . 2. www.adaptic.cz : slovníček [online]. 2005-2011 [cit. 2011-06-23]. E-shop. Dostupné z www: . 3. SaaS. In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 16.6.2008, last modified on 8.3.2011 [cit. 2011-06-23]. Dostupné z WWW: . 4. www.adaptic.cz : slovníček [online]. 2005-2011 [cit. 2011-06-23]. B2B. Dostupné z www: . 5. www.adaptic.cz : slovníček [online]. 2005-2011 [cit. 2011-06-23]. B2C. Dostupné z www: . 6. www.adaptic.cz : slovníček [online]. 2005-2011 [cit. 2011-06-23]. C2C. Dostupné z www: . 7. GÁLA, Libor; POUR, Jan; TOMAN, Prokop. Podniková informatika : počítačové aplikace v podnikové a mezipodnikové praxi, technologie informačních systémů, řízení a rozvoj podnikové informatiky. 1.vyd. Praha : Grada Publishing, 2006. Mobilní obchodování, s. 151. 8. SEDLÁČEK, Jiří . E-komerce, internetový a mobil marketing. 1. vyd. Praha : BEN-technická literatura, 2006. M-komerce, s. 311. 9. GÁLA, Libor; POUR, Jan; TOMAN, Prokop. Podniková informatika : počítačové aplikace v podnikové a mezipodnikové praxi, technologie informačních systémů, řízení a rozvoj podnikové informatiky. 1.vyd. Praha : Grada Publishing, 2006. Mobilní obchodování, s. 156-163. 10. BASL, J.; POUR, J. Informační společnost a ICT. In KADEŘÁBKOVÁ, A. a kol. Ročenka konkurenceschopnosti České republiky 2005 – analýza. Praha : Linde, 2006, s. 208-221. ISBN 80-86131-66-1. 11. CROSMAN, Penny . Cloud Computing Begins to Gain Traction on Wall Street . Wall Street & Technology [online]. JANUARY 06, 2009, Infrastructure, [cit. 2011-06-23]. Dostupný z www:.

▪ 69 ▪


12. Platform as a service. In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 18 April 2008, last modified on 4 July 2011 [cit. 2011-07-27]. Dostupné z WWW: . 13. KUTIL, Ivan. Google Cloud Platforma: Google Apps, Marketplace, Android a App Engine. Lupa cz [online]. 30. 6. 2011, Seriál Cloud Computing, [cit. 2011-07-01]. Dostupný z WWW:

ndroid-a-app-engine/>.

▪ 70 ▪


19.

SEZNAM POUŽITÝCH SYMBOLŮ A ZKRATEK

Zkratka

Popisek

e-commerce

Pojem používaný k označení veškerých obchodních transakcí realizovaných pomocí internetu a dalších elektronických prostředků.

m-commerce

Podmnožina transakcí e-commerce realizovaných pomocí mobilního zařízení.

e-shop

Speciální webová aplikace sloužící ke zprostředkování obchodních transakcí na internetu.

m-shop

Speciální druh e-shopu, který je provozován v rámci mobilního zařízení.

hosting

Pronájem prostoru pro webové stránky na cizím serveru.

SaaS

Software as a Service. Model nasazení softwaru, kdy dochází k hostingu aplikace provozovatelem služby. Služba je dále nabízena zákazníkům přes internet.

Paas

Platform as a Service. Společnost poskytuje kompletní prostředí pro podporu celého životního cyklu tvorby a poskytování webových služeb plně k dispozici na internetu.

Cloud computing

Poskytování služeb či programů na serverech provozovatele s tím, že uživatelé k nim mohou přistupovat pomocí webového prohlížeče či klienta dané aplikace a používají je prakticky odkudkoliv.

outsourcing

Firma vyčlení různé podpůrné a vedlejší činnosti a svěří je smluvně jiné společnosti, specializované na příslušnou činnost.

on-demand

Odkazuje na služby nebo vlastnosti, které se zaměřují na potřeby uživatele pro okamžité použití.

3D Secure

XML protokol používaný pro zabezpečení on-line plateb pomocí kreditních karet.

backend

Jako backend se označuje část webové aplikace, která slouží k administraci webu a ke zpracování dat.

CVC

Card Verification Code. Kód na kreditních a debetních kartách sloužící k lepšímu zabezpečení při platbách těmito kartami.

WAP

Wirelles Application Protocol je systém pro zajištění provozu elektronických služeb na mobilních telefonech.

HTTPS

Hypertext Transfer Protocol Secure je nadstavba síťového protokolu HTTP. Umožňuje zabezpečit spojení mezi webovým prohlížečem a webovým serverem před odposloucháváním.

Zákazník

Osoba, která používá svoje mobilní zařízení a platformu vzniklou v rámci této práce pro nakupování nabízených produktů.

Dodavatel

Osoba, která používá platformu pro nabízení svých produktů za účelem prodeje.

Provozovatel služby

Společnost/Osoba, která provozuje platformu.

Produkt

Zboží, které dodavatel nabízí prostřednictvím této platformy.

Mobilní aplikace

Program, který se instaluje na mobilní zařízení, typicky komunikuje se serverem, kam posílá informace od zákazníka, který aplikaci používá. Dále také ze serveru načítá informace, které se zákazníkovi zobrazují.

Produktové portfolio

Skupina podobných produktů např. Růže, Karafiát, Tulipán.

▪ 71 ▪


UI

User Interface, prostředí kterým zákazník ovládá aplikaci.

UX

User Experience, pocity se kterými zákazník ovládá aplikaci.

ID

Zkratka pro identifikaci.

JSON-RPC

Protokol umožňující vzdálené volání procedur, který pro komunikaci používá formát JSON (JavaScript Object Notation).

EPBE

Rozšíření UML pro modelaci business procesů.

Databázová vrstva

Databázová vrstva umožňuje celkovou nezávislost prostředí na použité databázi. Vrstva zajišťující komunikaci mezi aplikací a její databází.

ORM

Objektově relační mapování. Programovací technika zajišťující konverzi dat mezi relační databází a objektově orientovaným programovacím jazykem.

ORMLite

Knihovna implementující ORM použitelná pro Android aplikace.

framework

Softwarová struktura sloužící jako podpora při programování a vývoji softwarových projektů. Může obsahovat podpůrné programy, knihovny API, návrhové vzory a podobně.

POJO

Plain Old Java Object. Označuje objekty, které nejsou svázané technologicky specifickým rozhraním. Jediné rozhraní těchto objektů je definováno business službami, které poskytují.

Aktivita

Základní komponenta Android aplikace, která poskytuje obrazovku, s níž mohou uživatelé pracovat.

Adaptér

Třída v android aplikaci sloužící jako most mezi daty a komponentami, které tyto data zobrazují.

Factory

Návrhový vzor. Definuje rozhraní pro vytváření rodin objektů, které jsou na sobě závislé nebo spolu nějak souvisí bez určení konkrétní třídy.

DAO

Data Access Object. Abstraktní rozhraní pro přístup k databázovým objektům.

CRUD

Crate, Read, Update, Delete. Zkratka pro čtyři základní databázové operace s objekty.

GET

Jedna z dotazovacích metod HTTP protokolu, kterou webový prohlížeč nebo klient získává webovou stránku nebo jiný objekt z webového serveru.

POST

Stejné jako GET ale navíc umožňuje předat serveru data.

Android Manifest

Android Manifest je XML soubor, který lepí celou aplikaci dohromady. Je přibalený v kořenovém adresáři výsledného projektu. Určuje například minimální verzi systému, verzi aplikace, potřebná oprávnění a další metainformace.

Plug-in

Zásuvný modul. Software, který nepracuje samostatně, ale jako doplňkový modul jiné aplikace a rozšiřuje tak její funkčnost.

JSON

JavaScript Object Notation. Způsob zápisu dat nezávislý na platformě určený pro přenos dat.

SOAP

Simple Object Access Protocol. Protokol pro výměnu zpráv založený na XML a fungující pomocí http.

WSDL

Web Services Description Language. Popisuje co nabízí webová služba a jak se jí na to zeptat. Zapisuje se v XML formátu a zpravidla se používá pro popis SOAP komunikace.

UC

Use Case. Případ užití. Popis interakce mezi uživatelem a aplikací.

▪ 72 ▪


20.

SEZNAM OBRÁZKŮ

Obrázek 1: Google Cloud platforma [13]......................................................................................... 23 Obrázek 2: Fungování služby.......................................................................................................... 24 Obrázek 3: Kategorie mobilních aplikací......................................................................................... 25 Obrázek 4: Přidaná hodnota z pohledu zákazníka..........................................................................27 Obrázek 5: Přidaná hodnota z pohledu dodavatele.........................................................................27 Obrázek 6: Nabídka produktu v rámci ČR a měst...........................................................................29 Obrázek 7: P01.01 – Výběr květiny................................................................................................. 35 Obrázek 8: P01.02 - Objednání květiny........................................................................................... 35 Obrázek 9: P02.01 Registrace zákazníka........................................................................................ 35 Obrázek 10: P02.02 Správa profilu zákazníka.................................................................................36 Obrázek 11: Activity Diagram - P01.02 Objednání květin................................................................37 Obrázek 12: UC01.01 Výběr květiny................................................................................................ 44 Obrázek 13: UC01.02 Objednání květiny........................................................................................ 45 Obrázek 14: UC02.01 Registrace zákazníka...................................................................................46 Obrázek 15: UC02.02 Správa profilu zákazníka..............................................................................47 Obrázek 16: Doménový model........................................................................................................ 48 Obrázek 17: Životní cyklus objednávky........................................................................................... 49 Obrázek 18: Objekt Auth................................................................................................................. 58 Obrázek 19: Objekt TimedResponse............................................................................................... 59

▪ 73 ▪


21.

SEZNAM TABULEK

Tabulka 1: Příklady m-commerce aplikací a jejich vazba na vlastnosti m-commerce......................16 Tabulka 2: Aktéři.............................................................................................................................. 34 Tabulka 3: Identifikované procesy................................................................................................... 34 Tabulka 4: Přehled UC.................................................................................................................... 42 Tabulka 5: Mapování požadavků na UC.......................................................................................... 43

▪ 74 ▪


22.

SEZNAM PŘÍLOH

Příloha 1: Class model mobilní aplikace...........................................................................................76 Příloha 2: Class model webového backendu....................................................................................77 Příloha 3: Návrh UI aplikace.............................................................................................................78

▪ 75 ▪


22.1

Příloha 1 – Class model mobilní aplikace

▪ 76 ▪


22.2

Příloha 2 – Class model webového backendu

▪ 77 ▪


22.3 22.3.1

Příloha 3 – Návrh UI mobilní aplikace UI0000 SplashScreen

Startovní obrazovka aplikace

22.3.2

UI1003 Kategorie

Obrazovka následující hned po Splash obrazovce. Zobrazuje dostupné kategorie produktů. V dolní části obsahuje kontextové menu aplikace (zobrazí se po stisku hardware tlačítka Menu a je součástí všech obrazovek kromě UI0000, v dalších obrazovkách návrhu již není pro zjednodušení zobrazováno). Tlačítko Košík vede na obrazovku s košíkem (UI1005 Košík).

▪ 78 ▪


22.3.3

UI1002 Seznam produktů

Zobrazuje seznam produktů vybrané kategorie. Tlačítko zpět vede na obrazovku, ze které byla tento seznam vyvolán. Funkčnost tlačítka Košík je stejná jako na předchozí obrazovce.

22.3.4

UI1001 Detail produktu

Zobrazuje detail zvoleného produktu. Jeho obrázek, popis, kód a cenu. Funkčnost tlačítek Zpět a Košík je stejná jako v předešlých obrazovkách. Stisk tlačítka Vlož do košíku vede na následující obrazovku UI1004 Vložení do košíku.

▪ 79 ▪


22.3.5

UI1004 Vložení do košíku

Tlačítko pokračovat v nákupu vede zpět do kategorie, do které patří produkt, který byl přidán do košíku. Tlačítko přejít do košíku vede na obrazovku UI1005 Košík.

22.3.6

UI1005 Košík

Dlouhý stisk položky košíku vede k jejímu odstranění. Tlačítko Zpět vede na obrazovku, ze které byl košík spuštěn. Šipka na položce košíku vede na UI1010 Detail položky košíku, kliknutím na položku košíku se uživatel dostane na UI01001 Detail produktu (až na tlačítko zpět budou tlačítka neaktivní).Tlačítko Bonus vede na UI1009 Aplikuj Bonus a je aktivní pouze pro přihlášeného uživa-

▪ 80 ▪


tele, tlačítko Vyprázdni vede na UI1008 Vyprázdni košík a Objednej v případě nepřihlášeného/neregistrovaného uživatele na UI1007 Nepřihlášený uživatel, v jiném případě na UI1020 Objednání.

22.3.7

UI1006 Zadej počet kusů

22.3.8

UI1007 Nepřihlášený uživatel

Tlačítko Zpět zavírá dialog. Pokračovat jako neregistrovaný vede na UI1020 Objednání, Přihlásit se vede na UI2003 Přihlášení a Zaregistrovat se na UI2001 Registrace.

▪ 81 ▪


22.3.9

UI1008 Vyprázdni košík

22.3.10

UI1009 Aplikuj Bonus

▪ 82 ▪


22.3.11

UI1010 Detail položky košíku

Tlačítko Zpět vede na Košík bez uložení změn, tlačítko Uložit vede na Košík s uložením změn. Kliknutí na položku Počet kusů vede na UI1011 Zadej počet kusů. Tlačítko v položce Jeden text blahopřání je na začátku nastaveno na off. To znamená, že adekvátně k počtu kusů položky se zobrazuje stejný počet polí pro zadání blahopřání. V případě zapnutí tlačítka z off na on, dojde k vyvolání UI1010_A Dialog (dialog s varováním, že bude použit pouze první text blahopřání a dojde ke ztrátě ostatních textů blahopřání).

22.3.12

UI1010_A Dialog

Stisk tlačítka Zpět zruší dialog beze změn v rodičovském okně. Stisk tlačítka Použít jeden text blahopřání vede na UI1010_B Detail položky košíku s jedním textem blahopřání

▪ 83 ▪


22.3.13

UI1010_B Detail položky košíku s jedním textem blahopřání

22.3.14

UI1020_A Objednej – přihlášený uživatel – strana 1

Tlačítko Zrušit vede na dialog UI1021 Zrušit objednávku. Tlačítko Zaplatit je aktivní pouze v případě vyplnění všech povinných údajů na obou stranách objednávkového formuláře (ty které mají za názvem hvězdičku) a vede na UI1023 Zaplať. Zapnutí tlačítka v položce Jiná fakturační adresa vede stejně jako klik na tuto položku v případě již zapnutého tlačítka na UI1020 Fakturační adresa. Pohyb mezi stranou jedna a dvě je zajištěn táhnutím prstem vlevo a vpravo. Údaje se načítají z profilu uživatele.

▪ 84 ▪


22.3.15

UI1020_A Objednej – přihlášený uživatel – strana 2

Tlačítka Zrušit a Zaplatit mají stejnou funkčnost jako strana 1. V případě změny telefonního čísla je vyvolán dialog Ano/Ne (podobný tomu z UI1021) s dotazem zda má být telefonní číslo změněno i v profilu uživatele. Klik na Čas dodání vede na UI1020 Čas dodání. Klik na poznámku vede na UI1020 Poznámka.

22.3.16

UI1020_B Objednej – nepřihlášený uživatel – strana 1

▪ 85 ▪


22.3.17

UI1020_B Objednej – nepřihlášený uživatel – strana 2

22.3.18

UI1020 Fakturační údaje

V případě přihlášeného zákazníka jsou předvyplněny údaje z jeho profilu a při změně údajů je uživatel dotázán zda chce aby se změna projevila i v jeho profilu.

▪ 86 ▪


22.3.19

UI1020 Poznámka

22.3.20

UI1020 Čas dodání

Časy dodání jaké poskytuje dodavatel.

▪ 87 ▪


22.3.21

UI1021 Zrušit objednávku

Po stisku Ano je uživatel vrácen na košík. Po stisku Ne dojde ke zrušení dialogu.

22.3.22

UI1023 Platební brána

Vybrat lze pouze jeden druh karty. Zaplať vede na další obrazovku

▪ 88 ▪


22.3.23

UI1023 Platební brána ČS

V levé obrazovce je ve WebView komponentě zobrazena ČS platební brána. Po dokončení transakce je zobrazen dialog jehož OK tlačítko vede na UI1003 Kategorie.

22.3.24

UI2001 Registrace

▪ 89 ▪


22.3.25

UI2010 Nastavení

Vlevo je obrazovka Nastavení tak jak se zobrazí přihlášenému uživateli, vpravo pro nepřihlášeného uživatele. Odhlášení a Zrušení registrace je podmíněno souhlasem v dialogu stejně jako při zru -

▪ 90 ▪


šení objednávky. Tlačítko Registrovat se vede na UI2001 Registrace, Přihlásit se na UI2003 Přihlášení. Klik na položku Můj profil vede na UI2012 Profil, Historie objednávek vede na UI2011 Historie objednávek. Nápověda, Obchodní podmínky a O aplikaci zobrazí obrazovky s textovým popisem nápovědy, obchodních podmínek, či informace o aplikaci.

22.3.26

UI2003 Přihlášení

22.3.27

UI2012 Profil

Pole s Adresou a Informacemi o firmě vede na stejné obrazovky jako v UI2001 Registrace.

▪ 91 ▪


22.3.28

UI2011 Historie objednávek

Po kliku na položku se zobrazí detail objednávky UI2019 Detail historické objednávky.

22.3.29

UI2019 Detail historické objednávky

Tlačítko zrušit objednávku je viditelné pouze pro objednávky ve stavu New. Stisk tlačítka Zaslat fakturu iniciuje opakované zaslání faktury za objednávku na e-mailovou adresu uživatele.

▪ 92 ▪

BAKALÁŘSKÁ PRÁCE. Vývoj e-commerce platformy pro mobilní zařízení s podporou webového backendu

Recommend Documents