bakalářská práce - Unicorn College

Transkript

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 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<CustomerDTO>
getCustomer(Auth
auth,
Date
lastUpdate)
▪
vrací objekt zákazníka s ohledem na podmínky synchronizace výše
update (UC02012)
•
◦
TimedResponse<CustomerDTO> 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<List<ProductDTO>>
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<List<CategoryDTO>> 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<OrderItemDTO> - 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<OrderItemDTO> 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<List<OrderDTO>>
getOrdersFromCustomer(Auth
Date lastUpdate)
▪
◦
•
vrací všechny objednávky vytvořené registrovaným zákazníkem
OrderDTO obsahuje:
▪
deliveree = DelivererDTO
▪
orderStateSupport = OrderStateSupportDTO
▪
orderItems = List<OrderItemDTO>
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<List<DeliveryTimeDTO>>
getDeliveryTimes(Date
lastUpdate, id supplierId)
▪
získá možné časy doručení
získání oblastí, ve kterých dodavatel doručuje
•
◦
TimedResponse<List<DeliveryTownDTO>>
getDeliveryAreas(Date
lastUpdate, id supplierId)
▪
◦
získá možné oblasti doručení
v DeliverytownDTO je navíc obsaženo:
▪
seznam PSČ = List<DeliveryZIPDTO>
▪
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: <http://www.adaptic.cz/znalosti/slovnicek/e-commerce/>.
2. www.adaptic.cz : slovníček [online]. 2005-2011 [cit. 2011-06-23]. E-shop. Dostupné z
www: <http://www.adaptic.cz/znalosti/slovnicek/e-shop/>.
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:
<http://cs.wikipedia.org/wiki/SaaS>.
4. www.adaptic.cz : slovníček [online]. 2005-2011 [cit. 2011-06-23]. B2B. Dostupné z www:
<http://www.adaptic.cz/znalosti/slovnicek/b2b/>.
5. www.adaptic.cz : slovníček [online]. 2005-2011 [cit. 2011-06-23]. B2C. Dostupné z www:
<http://www.adaptic.cz/znalosti/slovnicek/b2c/>.
6. www.adaptic.cz : slovníček [online]. 2005-2011 [cit. 2011-06-23]. C2C. Dostupné z www:
<http://www.adaptic.cz/znalosti/slovnicek/c2c/>.
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:<http://www.wallstreetandtech.com/it-infrastructure/showArticle.jhtml?
articleID=212700913>.
▪ 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: <http://en.wikipedia.org/wiki/Platform_as_a_service>.
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:
<http://www.lupa.cz/clanky/google-cloud-platforma-google-apps-marketplace-a-
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 - Unicorn College

Transkript

Podobné dokumenty

KOMUNIKACE

Přehled nástrojů CABE (modelování podniku) na tuzemském trhu

Komunikační sítě II pro integrovanou výuku VUT a VŠB-TUO

Standard elektronické fakturace

TYPO3: Příručka pro redaktory - Podpora webu

Vyšší odborná škola, Střední škola, Centrum odborné přípravy

4 Vytváření webových stránek pro e-commerce