}w !"#$%&'()+,-./012345
M ASARYKOVA UNIVERZITA FAKULTA INFORMATIKY
Objednávkový systém internetového obchodu na platformˇe podnikového portálu ˇ B AKALÁ RSKÁ PRÁCE
Ondˇrej Veselý
Brno, jaro 2011
Prohlášení Prohlašuji, že tato bakaláˇrská práce je mým puvodním ˚ autorským dílem, které jsem vypracoval samostatnˇe. Všechny zdroje, prameny a literaturu, které jsem pˇri vypracování používal nebo z nich cˇ erpal, v práci rˇ ádnˇe cituji s uvedením úplného odkazu na pˇríslušný zdroj.
Vedoucí práce: RNDr. Tomáš Ludík ii
Shrnutí Bakaláˇrská práce se zabývá tvorbou objednávkového systému na platformˇe podnikového portálu. Je v ní rozebrána problematika podnikových portálu˚ a popsány technologie použité pˇri tvorbˇe aplikace. Jsou nalezeny požadavky na objednávkový systém, ten je následnˇe analyzován a navržen za použití diagramu. ˚ Objednávkový systém rozšiˇruje existující internetový obchod, je do nˇej vhodnˇe integrován a komunikuje s ostatními komponentami obchodu. Návrh splnuje ˇ tˇrívrstvou architekturu a umožnuje ˇ tím jednoduché rozšíˇrení systému. Prototyp objednávkového systému je psán v jazyku Java a bude nasazen na podnikovém portálu.
iii
Klíˇcová slova podnikový portál, portlet, Spring Framework, Java Persistence API, MVC, objednávkový systém, Java Portlet Specification, požadavky, UML
iv
Obsah 1 Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Motivace . . . . . . . . . . . . . . . . . . . . . . 1.2 Cíle práce . . . . . . . . . . . . . . . . . . . . . . 1.3 Struktura práce . . . . . . . . . . . . . . . . . . 2 Podnikové portály . . . . . . . . . . . . . . . . . . . 2.1 Teorie podnikových portálu˚ . . . . . . . . . . . 2.1.1 Vymezení podnikových portálu˚ . . . . 2.1.2 Definice podnikového portálu . . . . . 2.1.3 Možnosti podnikového portálu . . . . . 2.2 Portálové technologie . . . . . . . . . . . . . . . 2.2.1 Portálové technologie v Javˇe . . . . . . 2.3 Implementace portálu˚ . . . . . . . . . . . . . . 2.3.1 WebSphere Portal . . . . . . . . . . . . . 2.3.2 Liferay Portal . . . . . . . . . . . . . . . 3 Použité technologie . . . . . . . . . . . . . . . . . . 3.1 Vývojové nástroje . . . . . . . . . . . . . . . . . 3.1.1 Java Persistence API . . . . . . . . . . . 3.1.2 Spring Framework . . . . . . . . . . . . 3.2 Tvorba portletu˚ . . . . . . . . . . . . . . . . . . 3.2.1 Portlety podle JSR 168 . . . . . . . . . . 3.2.2 Portlety podle JSR 286 . . . . . . . . . . 3.2.3 Spring Portlet MVC Framework . . . . 3.2.4 JavaServer Pages . . . . . . . . . . . . . 4 Požadavky na objednávkový systém . . . . . . . . 4.1 Popis stávajícího rˇ ešení . . . . . . . . . . . . . . 4.2 Srovnání objednávkových systému˚ . . . . . . . 4.3 Požadavky na objednávkový systém . . . . . . 5 Analýza a návrh objednávkového systému . . . . . 5.1 Pˇrípady užití . . . . . . . . . . . . . . . . . . . . 5.2 Návrh objednávkového systému . . . . . . . . 5.2.1 Komponenty objednávkového systému 5.2.2 Tˇrídy objednávkového systému . . . . 6 Implementace objednávkového systému . . . . . . 6.1 Vývoj datové vrstvy . . . . . . . . . . . . . . . 6.2 Vývoj aplikaˇcní vrstvy . . . . . . . . . . . . . . 6.3 Vývoj prezentaˇcní vrstvy . . . . . . . . . . . . . 6.4 Testování . . . . . . . . . . . . . . . . . . . . . . 7 Závˇer . . . . . . . . . . . . . . . . . . . . . . . . . . . Literatura . . . . . . . . . . . . . . . . . . . . . . . . . . . A Specifikace pˇrípadu˚ užití . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 1 1 2 3 3 3 3 4 4 5 6 7 7 8 8 8 9 10 10 12 12 13 14 14 15 16 18 18 20 20 21 24 24 25 26 28 30 32 33 v
B Návrhový diagram tˇríd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C Ukázky zdrojového kódu objednávkového systému . . . . . . . . . . . . . . . . . D Ukázky dalších obrazovek uživatelského rozhraní . . . . . . . . . . . . . . . . . .
36 37 40
vi
Kapitola 1
Úvod 1.1
Motivace
Internetové obchody jsou rozsáhlé webové aplikace, jež kladou vysoké nároky na funkcionalitu, zejména z hlediska interakce s uživatelem i správcem systému. Stávající internetový obchod, jenž vzniká v IBA CZ, s.r.o. v rámci partnerství s Fakultou informatiky Masarykovy univerzity, je zajímavý tím, že je psán pro použití na podnikovém portálu. Podnikové portály jsou technologie zpravidla umožnující ˇ sdružování obsahu na jednom místˇe, jeho prezentaci, pˇrizpusobení ˚ a možnost jednotného pˇrihlášení [1]. Internetové obchody se cˇ asto skládají z mnoha služeb sdružených na jedné stránce. Tˇemi mohou být napˇríklad prohlížení kategorií, výpis produktu, ˚ košík, pˇrihlašování cˇ i speciální nabídky. Podnikové portály umožní díky svým vlastnostem rozˇclenit tyto služby na jednoduché komponenty pˇri zachování jednotného pˇrístupu k nim. Navíc si provozovatel muže ˚ vybrat, jaké komponenty ve svém obchodˇe použije, a díky možnostem portálu˚ i zvolit jejich umístˇení na stránce, spoleˇcný vzhled nebo rozdílné chování vuˇ ˚ ci ruzným ˚ skupinám zákazníku. ˚ Stávající internetový obchod je psán tak, aby možnosti podnikových portálu˚ co nejvíce využil, a díky modulární architektuˇre dovoluje jak pˇrímé použití, tak upravení jednotlivých cˇ ástí obchodu na míru. Existující rˇ ešení internetového obchodu není kompletní, zatím dokáže pracovat s produkty a jejich katalogem.
1.2
Cíle práce
Cílem této práce je rozšíˇrit stávající internetový obchod o objednávkový systém. Je tˇreba provést analýzu a návrh systému a podle tohoto návrhu vytvoˇrit prototyp objednávkového systému. Ten musí být podle vzoru internetového obchodu psán v objektovˇe-orientovaném jazyku Java za použití technologií Java Persistence API a Spring Framework. Systém musí být navržen a vytvoˇren pro nasazení na podnikovém portálu. Objednávkový systém musí být vhodnˇe integrován do existujícího internetového obchodu. Bude vhodnˇe využívat ostatní komponenty systému, návrh musí splnovat ˇ strukturu aplikace a implementace musí dodržovat zavedené konvence tak, aby bylo snazší v dalších fázích projektu systém rozšiˇrovat cˇ i navazovat na nˇej. 1
1.3. STRUKTURA PRÁCE
1.3
Struktura práce
Zaˇcátek práce se vˇenuje teoretickým východiskum ˚ problematiky. Vymezuje podnikové portály, popisuje technologie, na nichž jsou podnikové portály vystaveny, a seznamuje s konkrétními portálovými rˇ ešeními. Dále jsou pˇredstaveny technologie, jež byly použity pˇri rˇ ešení práce. Jsou popsány vývojové nástroje usnadnující ˇ tvorbu nároˇcných aplikací. Následnˇe je pˇriblížena problematika tvorby portletu, ˚ tedy základních komponent používaných portály. Další cˇ ást práce popisuje analýzu a návrh objednávkového systému. Jsou zde nalezeny a pˇredloženy požadavky na objednávkový systém a formou UML (Unified Modeling Language) diagramu˚ je zde objednávkový systém analyzován a navržen. Na diagramech jsou ukázány pˇrípady užití systému, struktura tˇríd a vztahy komponent systému vˇcetnˇe provázání s okolím. Nakonec je popsána implementace objednávkového systému. Jsou zde pˇredvedeny technické principy použité pˇri tvorbˇe systému a ilustrovány na pˇríkladech z vytvoˇrené aplikace. Také zde jsou vysvˇetlena rˇ ešení nˇekterých problému˚ systému a je ukázáno použití klíˇcových technologií a vývojových nástroju˚ v aplikaci.
2
Kapitola 2
Podnikové portály 2.1
Teorie podnikových portálu˚
Vymezení portálu není jednoduché, nebot’ samotný pojem portál má mnoho významu. ˚ Historicky se jedná o vstupní bránu nebo ozdobný vchod v architektuˇre. Slovo portál ovšem nemá jediný význam ani v oblasti informaˇcních technologií. Nˇekdy se pod portálem rozumí internetový portál, tedy nˇejaká brána do svˇeta internetu (mezi ty patˇrí napˇríklad Seznam1 cˇ i Yahoo!2 . Stále cˇ astˇeji se ale mluví o podnikových portálech. Tˇemi se obecnˇe rozumí nástroje pro sdružování obsahu z ruzných ˚ zdroju, ˚ jejich integraci a pˇrizpusobení ˚ zákazníkovi. Složitost problematiky naznaˇcuje i nejednotnost anglického názvosloví v této oblasti. Pojem podnikový portál lze v angliˇctinˇe vyjádˇrit jako enterprise portal, enterprise information portal, business portal cˇ i corporate portal, pˇriˇcemž každý z výrazu˚ muže ˚ mít odlišný význam [7]. Slovo portál bude v následujícím textu významovˇe omezeno na podnikový portál. 2.1.1 Vymezení podnikových portálu˚ Pod pojmem podnikový portál si lze pˇredstavit „další krok v evoluci firemního intranetu“ [2], tedy podnikový portál jako víceúrovnový ˇ technologický systém, jenž integruje procesy, aplikace a data a vytváˇrí jedno celistvé prostˇredí umožnující ˇ spoleˇcnostem poskytnout jednotný komunikaˇcní kanál všem, kteˇrí se chtˇejí zúˇcastnit jejich obchodních aktivit [17]. Zárovenˇ podnikový portál oznaˇcuje aplikaci konkrétní (portálové) technologie, tedy produkt, který umožnuje ˇ zpravidla sdružování obsahu z ruzných ˚ zdroju, ˚ integraci a pˇrizpusobení ˚ v závislosti na nasazení cˇ i požadavcích zákazníka [1]. Oba významy podnikového portálu jsou úzce provázané. Mohou existovat firemní intranety, nabízející stejné možnosti, ale nepoužívající portálovou technologii, stejnˇe jako lze portálové technologie využívat i pro jiné úˇcely než pro firemní intranety. Pro práci relevantní je podnikový portál jako portálová technologie. 2.1.2 Definice podnikového portálu Stejný problém jako s vymezením portálu nastává i u jeho definice. Jednotná definice portálu neexistuje, portály se mohou lišit v oblastech nasazení, nabízených vlastnostech cˇ i po1. Viz
. 2. Viz
.
3
2.2. PORTÁLOVÉ TECHNOLOGIE užitých technologiích [14]. Pro úˇcely práce je nejrelevantnˇejší definice podaná v Java portlet specifikaci [1], podle které je portál webová aplikace sloužící pro zobrazování prezentaˇcní vrstvy informaˇcních systému, ˚ umožnující ˇ sdružování obsahu z ruzných ˚ zdroju˚ na jednom místˇe, pˇrizpusobení ˚ a jednotné pˇrihlášení pro všechny sdružené služby. 2.1.3 Možnosti podnikového portálu Ruzné ˚ podnikové portály nabízejí jiné vlastnosti, ale již z definice portálu vyplývají ty nejduležitˇ ˚ ejší a spoleˇcné všem portálum. ˚ Mezi ty patˇrí pˇredevším možnost sdružení obsahu˚ ruzných ˚ zdroju˚ na jednom místˇe, které se dˇeje zpravidla formou sdružování uživatelských rozhraní ruzných ˚ aplikací cˇ i filtrování obsahu ruzných ˚ webových zdroju. ˚ To je zefektivnˇeno možností jednotného pˇrihlášení pro všechny tyto sdružené služby, kdy uživatel zadá jediné pˇrihlašovací údaje a je mu pˇrístupné vše, co potˇrebuje. S tím souvisí i vysoká možnost pˇrizpusobení, ˚ která probíhá na dvou úrovních. Tou první je myšlena možnost pˇrizpusobení, ˚ nebo kontrola obsahu ze strany administrátoru. ˚ Ti mohou rozhodnout, jaký obsah se bude uživatelum ˚ zobrazovat. Díky tomu není uživatel zahlcen nepotˇrebnými informacemi, a naopak má pˇrehled o všech informacích duležitých ˚ pro jeho cˇ innost. Tím lze zárovenˇ urˇcitým uživatelum ˚ zabránit v pˇrístupu k informacím, jež jim mají zustat ˚ utajeny. Samozˇrejmˇe platí, že lze nastavit ruzným ˚ uživatelum ˚ ruzný ˚ obsah, a tedy pro ruzné ˚ uživatele muže ˚ portál po pˇrihlášení obsahovat úplnˇe jiné informace. Druhou úrovní je myšlena možnost pˇrizpusobení ˚ obsahu ze strany uživatele, která se neomezuje pouze na úpravu vzhledu, ale také na možnost jednoduchým zpusobem ˚ mˇenit návrh stránky a pˇresouvat jednotlivé obsahy na ruzná ˚ místa.
2.2
Portálové technologie
Portály, jako webové aplikace, obecnˇe ke své funkˇcnosti potˇrebují dvˇe základní komponenty. Tou první je portlet, což je aplikace reprezentující jednu ze sdružených služeb. Tou druhou je pak kontejner, který se stará o bˇeh portletu, ˚ jež obsahuje, a zabezpeˇcuje portálové vlastnosti [15]. Tímto kontejnerem muže ˚ být samotný portál nebo mohou být portálový server s portletovým kontejnerem dvˇe ruzné ˚ komponenty. Obrázek 2.1 zobrazuje rˇ ešení, kde portál a portletový kontejner jsou oddˇeleny. Na obrázku jsou vidˇet portletové aplikace, skládající se z jednoho cˇ i více portletu. ˚ Ty jsou shromáždˇeny v portletovém kontejneru, jenž v závislosti na uživatelských požadavcích vyvolává jejich funkcionalitu a zprostˇredkovává jejich odpovˇedi. Mezi portletovým kontejnerem a portlety je nakresleno rozhraní, jež umožnuje ˇ vytváˇret portlety nezávisle na konkrétních portálových rˇ ešeních a bude detailnˇeji popsáno v následující kapitole. Klient bezprostˇrednˇe komunikuje s portálem. Ten zpˇrístupnuje ˇ služby portletového kontejneru a zejména zabezpeˇcuje portálové vlastnosti, jako jsou vykreslování více portletových obsahu˚ na jednu stránku cˇ i jednotné pˇrihlášení a vzhled. Vˇetšina portálu˚ je psána v jazyku Java na platformˇe Java EE (Java Platform, Enterprise Edition, viz [3]). Nˇekteré jsou však vytvoˇreny za použití jiných technologií, mezi nˇež patˇrí 4
2.2. PORTÁLOVÉ TECHNOLOGIE
Obrázek 2.1: Schéma portálových technologií [9] ASP .NET, C++ nebo PHP. Aby bylo možné používat portlety i na portálech jiných výrobcu, ˚ existují dva OASIS (Organization for the Advancement of Structured Information Standards) standardy, WSRP 1.0 a 2.0 (Web Services for Remote Portlets, viz [15]). Ty definují rozhraní pro zpˇrístupnˇení a interakci s portlety umístˇenými na jiných portálech. Portál však není definován žádným standardem. 2.2.1 Portálové technologie v Javˇe Jiná už je situace v kontextu Javy. Pˇrestože ani zde neexistuje standard popisující portál, portlety jsou definovány dvˇema standardy vzniklými jako výsledek požadavku na Java specifikaci (Java Specification Request, JSR) v rámci procesu Java komunity (Java Community Process, JCP). Tˇemi jsou JSR 168 (Java Portlet Specification 1.0, viz [1]) z roku 2003 a JSR 286 (Java Portlet Specfication 2.0, viz [8]) z roku 2008. Tyto standardy definují rozhraní mezi portlety a portletovým kontejnerem, a tedy portlety splnující ˇ tyto standardy jsou pˇrenosné na všechny portály, jež tyto standardy implementují. Podle portletových specifikací [1] jsou portlety aplikace dodávající cˇ ást obsahu portálové stránky. Jsou používány portálem jako zásuvná uživatelská rozhraní tvoˇrící prezentaˇcní vrstvu informaˇcních systému. ˚ Portlety generují tzv. fragment, což je text ve znaˇckovacím jazyku splnující ˇ jistá pravidla. Fragment spolu s nadpisem a kontrolními tlaˇcítky tvoˇrí portletové okno. Seskupení tˇechto portletových oken ruzných ˚ portletu˚ tvoˇrí portálovou stránku, jak je ukázáno na obrázku 2.2. Portlety jsou spravovány portletovým kontejnerem [1]. Portletový kontejner obsahuje portlety, poskytuje jim bˇehové prostˇredí a stará se o jejich životní cyklus. Také ukládá perzistentní data pro portletová pˇrednastavení. Portletový kontejner pˇrijímá požadavky od portálu, tyto požadavky provádí na spravovaných portletech a generuje dynamický obsah. Portletový kontejner muže ˚ být spojen dohromady s portálem v jednu komponentu, nebo mohou být zvlášt’. Portálový server je cˇ astˇeji oznaˇcován jen jako portál a podle JSR 168 [1] se jedná o webovou aplikaci, která slouží pro zobrazení prezentaˇcní vrstvy informaˇcních systému˚ a nabízí ruzné ˚ možnosti, jako jsou sdružování obsahu z ruzných ˚ zdroju˚ na jednom místˇe, pˇrizpu˚ 5
˚ 2.3. IMPLEMENTACE PORTÁL U
Obrázek 2.2: Portálová stránka [9] sobení a jednotné pˇrihlášení. Jedná se o nástavbu nad portletovým kontejnerem, zajišt’ující nabízené vlastnosti portálu, pˇriˇcemž muže ˚ s portletovým kontejnerem tvoˇrit jedinou nedílnou aplikaci.
2.3
Implementace portálu˚
V souˇcasné dobˇe existuje mnoho výrobcu˚ portálových serveru. ˚ Jak již bylo rˇ eˇceno, ty mohou být vytvoˇreny za použití jiných technologií a distribuovány pod ruznými ˚ licencemi. Mezi portály psané v technologii ASP .NET patˇrí napˇríklad Office Sharepoint Server 2010 od firmy Microsoft3 . Nejznámˇejším open sourcovým portálem v Java EE je Liferay Portal od Liferay4 , nejvýznamnˇejším portálem pod komerˇcní licencí je WebSphere Portal od IBM5 , mezi další patˇrí napˇríklad JBoss Enterprise Portal Platform od JBoss6 , Jetspeed od Apache Software Foundation7 cˇ i eXo Platform od eXo8 . Dále budou pˇriblíženy dva nejpoužívanˇejší portály, a to portály Liferay a WebSphere.
3. 4. 5. 6. 7. 8.
Viz
. Viz . Viz . Viz . Viz . Viz .
6
˚ 2.3. IMPLEMENTACE PORTÁL U 2.3.1 WebSphere Portal WebSphere Portal od IBM je dodáván ve tˇrech komerˇcních verzích. První a základní verzí je WebSphere Portal Server. Ten nabízí všechny klíˇcové portálové služby pro sdružování obsahu a pˇrizpusobení, ˚ vˇcetnˇe podpory standardu˚ JSR 286 a WSRP 2.0, štítkování (tagging) a hodnocení obsahu, témata vzhledu a rozložení stránky, nástroje pro tvorbu a správu komponent nebo pˇrizpusobení ˚ metodou táhni a pust’ (drag and drop) [20]. Další verze, WebSphere Portal Enable[20], obsahuje všechny možnosti WebSphere Portal Server a pˇridává navíc pokroˇcilé nástroje pro správu obsahu (content management), správu dokumentu˚ a pokroˇcilé vyhledávání. Poslední, nejrobustnˇejší verzí je WebSphere Portal Extend. Ten rozšiˇruje verzi Enable o nástroje pro spolupráci uživatelu. ˚ 2.3.2 Liferay Portal Liferay Portal implementuje standard JSR 286 a nabízí další vlastnosti. Mezi ty patˇrí efektivnˇejší správa uživatelu˚ pomocí tˇrídˇení do organizací a komunit, zobrazování obsahu stránky podle role uživatele, kdy na stejné adrese najdou ruzní ˚ uživatelé rozdílný obsah podle rolí, umístˇení ve skupinách nebo vlastním nastavení, pˇresouvání komponent na stránce metodou táhni a pust’, možnosti rozvržení stránky a témat vzhledu nebo podpora vyhledávání a štítkování. Dále je dodáván s více než šedesáti pˇripravenými portlety umožnujícími ˇ správu obsahu, spolupráci nebo sociální sítˇe [19]. Portál Liferay je nabízen ve dvou variantách [19], první je open sourcová Community Edition, která je zdarma, ale nenabízí žádnou podporu ze strany Liferay. Druhou variantou je placená Enterprise Edition. Ta nabízí vˇetší zabezpeˇcení, co nejvˇetší stabilitu a podporu strany Liferay. Liferay Portal potˇrebuje ke svému bˇehu aplikaˇcní server. Podporuje a je možné jej stáhnout s mnoha aplikaˇcními servery, mezi nimiž jsou napˇríklad Apache Tomcat, GlassFish, Oracle Application Server cˇ i JBoss Application Server [19].
7
Kapitola 3
Použité technologie Pro tvorbu složitých (v Java kontextu enterprise) aplikací je vhodné použít pokroˇcilé technologie a vývojové nástroje (framework). Ty poskytují knihovny univerzálnˇe použitelného kódu, návrhové vzory nebo rovnou fungující kostry aplikací a standardy pro pˇrenositelnost programu. ˚ Díky tomu není nutné psát aplikace vždy od základu, ˚ ale použít již napsané cˇ ásti kódu a vystavˇet na nich vlastní, konkrétní rˇ ešení. Kód je pak pˇrehlednˇejší a jednodušší pˇri zachování funkcionality. Na bázi jazyka Java existuje mnoho technologií pro tvorbu enterprise aplikací. Zejména to je Java EE, tedy oficiální platforma definující mnoho specifikací pro vývoj serverových aplikací, ale jsou to i neoficiální alternativy splnující ˇ Java standardy, mezi nˇež patˇrí napˇríklad Spring Framework [10].
3.1
Vývojové nástroje
Ve vícevrstvých aplikacích lze na nejobecnˇejší úrovni rozlišit tˇri logické vrstvy [16]. Nejnižší vrstvou je datová vrstva, ta slouží k manipulaci dat nad perzistentním úložištˇem. Úkolem datové vrstvy je zaˇrídit bezchybný pˇrenos dat mezi databází a aplikací. K tomu jsou v kontextu objektovˇe orientovaného programování používány nástroje pro objektovˇe-relaˇcní mapování (Object Relational Mapping, ORM). V Javˇe jsou tˇemito nástroji napˇríklad Java Persistence API [5] cˇ i Hibernate. Prostˇrední vrstvou enterprise aplikací je aplikaˇcní vrstva. Ta od nejnižší vrstvy získává data a prezentaˇcní vrstvˇe zprostˇredkovává aplikaˇcní logiku. Zajišt’uje vlastní funkcionalitu aplikace. Pro tvorbu aplikaˇcní logiky slouží napˇríklad Enterprise JavaBeans, jako souˇcást Java EE [3], nebo koˇrenový kontejner ve Spring Framework [10]. Horní vrstva se nazývá prezentaˇcní vrstva. Ta realizuje uživatelské rozhraní aplikace. Urcˇ uje, co uživatel vidí, a vyvolává funkcionalitu aplikaˇcní vrstvy. V závislosti na druhu aplikace má prezentaˇcní vrstva formu klasického grafického uživatelského rozhraní, webové aplikace cˇ i uživatelského rozhraní pro mobilní zaˇrízení. 3.1.1 Java Persistence API Java Persistence API (JPA) je souˇcástí Java EE [3] a ve verzi 2.0 je definována standardem JSR 317 [5]. JPA slouží ke správˇe perzistentních dat a objektovˇe-relaˇcnímu mapování v aplikacích na platformˇe Java. Své funkcionality a elegance dosahuje použitím anotací, pˇrípadnˇe 8
3.1. VÝVOJOVÉ NÁSTROJE metadat ve formˇe XML souboru [5]. JPA dovoluje zaobalit datový zdroj tak, že spojení na nˇej je provedeno v konfiguraˇcním XML souboru. Kód aplikace je pak na použité databázi zcela nezávislý. Základním stavebním kamenech JPA jsou entity. Entity jsou obyˇcejné javové tˇrídy splnuˇ jící urˇcitá kritéria. Slouží jako vzor pro objektovˇe-relaˇcní mapování. Atributy entitních tˇríd urˇcují schéma tabulky, pˇriˇcemž zapsané instance entit tvoˇrí rˇ ádky tabulky a jejich jednotlivé atributy jsou mapovány na atributy tabulky relaˇcní databáze a naopak. Entity umožnují ˇ i jednoduché mapování relací pomocí anotovaných atributu, ˚ napˇríklad atribut kolekce entit anotovaný OneToMany nebo ManyToOne odpovídá relaci 1:N, resp. N:1 [5]. K manipulaci dat nad databází slouží tˇrída EntityManager. EntityManager definuje metody pro vytváˇrení, editování, mazání cˇ i vyhledávání entit. Dovoluje také provádˇet nad uloženými entitami dotazy ve formˇe Java Persistence Query Language (jazyk pro dotazování). Ten má pro jednoduchost syntax podobnou jazyku SQL. Výrazy tohoto jazyka jsou dále pˇrekládány do dialektu jazyka SQL právˇe používané databáze, což podporuje nezávislost na konkrétním technickém rˇ ešení datového úložištˇe a dále zjednodušuje práci s databází [5]. 3.1.2 Spring Framework Spring je vývojový nástroj pro tvorbu enterprise aplikací v Javˇe. Není souˇcástí Java EE, je její alternativou. Spring je modulární, umožnuje ˇ použití jen tˇech cˇ ástí, které jsou potˇreba, pˇriˇcemž je možné používat jednotlivé moduly v kombinaci s jinými Java technologiemi. Zárovenˇ lze pomocí Springu postavit kompletní enterprise aplikaci [10]. Moduly Springu jsou zobrazeny na obrázku 3.1.
Obrázek 3.1: Technologie Spring Framework [10] 9
˚ 3.2. TVORBA PORTLET U Mezi tˇemito moduly jsou nástroje pro tvorbu datové vrstvy (Data Access/Integration), aplikaˇcní vrstvu zabezpeˇcuje pˇredevším koˇrenový kontejner (Core Container), pro prezentaˇcní vrstvu webových aplikací je tu Web MVC. Dále Spring nabízí i nástroje pro testování cˇ i aspektovˇe orientované programování (AOP). Beans Objekty, jež spravuje springový aplikaˇcní kontejner, se nazývají beans. Tyto objekty musí být popsány metadaty, podle nichž kontejner zjistí, jak je vytvoˇrit a jak s nimi zacházet [10]. Spring umožnuje ˇ vedle konfigurace v XML souborech také použití anotací. Ty se uvádí pˇrímo ve zdrojovém kódu a jejich použití je tedy pohodlnˇejší, za cenu chybˇejících centralizovaných, pˇrehledných konfiguraˇcních souboru. ˚ Injektování závislostí Spring specifikace [10] definuje injektování závislostí (Dependency Injection) jako „proces, pˇri kterém objekty definují své závislosti, tedy jiné objekty, se kterými pracují, jen za použití argumentu˚ konstruktoru, argumentu˚ továrních metod (factory method, metody používané pro tvorbu instancí tˇríd), nebo vlastností nastavitelných po vytvoˇrení instance objektu cˇ i jeho navrácení z tovární metody”. Aplikaˇcní kontejner injektuje dané závislosti teprve pˇritom, kdy daný objekty potˇrebuje. Tento postup je opaˇcný vzhledem k tomu, kdy objekty sami obstarávají své závislosti, proto se tento princip oznaˇcuje i jako obrácení kontroly (Inversion of Control, IoC).
3.2
Tvorba portletu˚
Prezentaˇcní vrstva webových aplikací je cˇ asto založena na architektuˇre MVC (model-viewcontroller). Ta logicky rozdˇeluje komponenty prezentaˇcní vrstvy podle funkcionality na [13] model, zobrazení (view) a zpracovatel (controller). Model pˇredstavuje data a aplikaˇcní logiku pˇrístupnou prezentaˇcní vrstvˇe, je reprezentován rozhraním aplikaˇcní vrstvy webové aplikace. Zobrazení vykresluje výstup v závislosti na modelu, je tvoˇren nˇejakou vhodnou technologií, nejˇcastˇeji JSP (JavaServer Pages, viz [6]). Zpracovatel rˇ adí požadavky, pˇrevádí je na akce provádˇené na modelu a následnˇe vyvolává zobrazení. Úlohu zpracovatele vykonávají nejˇcastˇeji servlety, v pˇrípadˇe portletových aplikací pak portlety. K jejich vývoji slouží Java Portlet Specification 1.0 a 2.0 (JSR 168 a JSR 286) a dále jej usnadnuje ˇ Spring Portlet MVC Framework, souˇcást Spring Framework. 3.2.1 Portlety podle JSR 168 Portlety jsou velice podobné servletum. ˚ Servlety jsou webové komponenty spravované kontejnerem, generující dynamický obsah, jsou základním nástrojem pro tvorbu webových aplikací v Javˇe, patˇrí do Java EE a popisuje je vlastní specifikace, Java Servlet Specification [4]. Jejich bˇehovým prostˇredím je servletový kontejner, pˇres nˇejž komunikují s webovými klienty 10
˚ 3.2. TVORBA PORTLET U pomocí vzoru požadavek/odpovˇed’ (request/response) [4]. S portlety komunikuje webový klient pomocí požadavku˚ a odpovˇedí smˇerˇ ovaných pˇres portál. Akce provedené na jednom portletu portál pˇrijímá a pˇreposílá portletum, ˚ jimž byly smˇerˇ ovány [1]. Portlety se od servletu˚ liší v nˇekterých duležitých ˚ vlastnostech. Na rozdíl od servletu˚ vytváˇrejí jen fragmenty stránek, nejsou pˇrímo urˇceny nˇejakým URL (Uniform Resource Locator), mají pˇreddefinované módy a stavy oken a mohou se vícekrát vyskytovat na jedné portálové stránce. Portlety musí být definovány ve speciálním XML (Extensible Markup Language) deskriptoru zvaném portlet.xml [1].
Zpracování požadavku˚ Dalším duležitým ˚ rozdílem oproti servletum ˚ je zpusob ˚ zpracování požadavku. ˚ Portlety mohou reagovat na dva druhy požadavku, ˚ požadavek na provedení akce a požadavek na vykreslení. Ty jsou reakcemi na dotazy formou actionURL cˇ i renderURL. Na první reaguje portlet provedením metody processAction, na druhé provedením metody render. Metoda render se provadí pro každý portlet pˇri každém vykreslení na portálovou stránku. Pokud tedy klient odešle požadavek na akci pro nˇejaký portlet, v tomto portletu se provede metoda actionRequest a na všech portletech na portálové stránce se provede metoda render [1].
Portletové módy Portlet se muže ˚ nacházet v ruzných ˚ módech. Tˇemi se rozumí funkce, kterou portlet zrovna vykonává. Zmˇenit mód lze pomocí záhlaví portletu, pˇrípadnˇe programovˇe pˇri zpracování požadavku na provedení akce. JSR 168 [1] definuje tˇri módy, tˇemi jsou VIEW, EDIT a HELP. Standardním módem je VIEW, v tom portlet generuje fragment, jenž je výsledkem jeho normální funkcionality. EDIT mód portletu nabízí uživateli ruzná ˚ nastavení portletu. HELP mód poskytuje uživateli návod nebo rady k používání portletu. Zatímco VIEW mód musí implementovat všechny portlety, EDIT a HELP jsou pouze volitelné. Zárovenˇ mohou ruzní ˚ výrobci portálu˚ podporovat vlastní módy, ale portlety, které tyto módy implementují ztrácí pˇrenositelnost na ostatní portály, které tyto módy nepodporují.
Stavy okna Portlet muže ˚ definovat také stav okna. Okno portletu se podle JSR 168 [1] muže ˚ nacházet ve stavu NORMAL, kdy portlet limituje svoji velikost a muže ˚ se na stránce vyskytovat s jinými portlety. Stav MAXIMIZED znaˇcí, že portlet je bud’ jediným, nebo ústˇredním portletem na stránce a muže ˚ tedy generovat rozsáhlejší obsah. Ve stavu MINIMIZED by portlet naopak nemˇel generovat obsah žádný, nebo jen minimum. Obdobnˇe jako pˇri portletovém módu mohou ruzné ˚ portály nabízet vlastní stavy okna za cenu menší pˇrenositelnosti portletu, ˚ jež je definují. 11
˚ 3.2. TVORBA PORTLET U 3.2.2 Portlety podle JSR 286 Druhá portletová specifikace témˇerˇ kompletnˇe pˇrebírá specifikaci první a pˇridává zejména nástroje pro meziportletovou komunikaci a poskytování zdroju˚ [8]. Komunikace mezi portlety podle JSR 286 muže ˚ probíhat bud’ prostˇrednictvím událostí, nebo pomocí veˇrejných render parametru. ˚ Portlety také novˇe mohou implementovat rozhraní ResourceServingPortlet a pˇres metodu serveResource poskytovat uživatelum ˚ zdroje napˇríklad ve formˇe binárních dat [2]. Veˇrejné render parametry jsou jednodušší formou meziportletové komunikace, musí být definovány v deskriptoru portlet.xml a lze je použít pouze pro rˇ etˇezcové hodnoty [2]. Události mohou portlety jak vysílat, tak pˇrijímat, dále je muže ˚ vysílat i samotný portál. Zpracování událostí probíhá pˇred zpracováním render metod. Oproti veˇrejným render parametrum ˚ mají události tu výhodu, že lze jejich pomocí pˇrenášet libovolné objekty [2]. U každého portletu je nutné nastavit v portlet.xml deskriptoru, jaké události pˇrijímá a jaké vysílá. 3.2.3 Spring Portlet MVC Framework Spring [10] pˇrímo nabízí MVC rámec pro tvorbu portletu. ˚ Ten je vystaven okolo portletu zvaného DispatcherPortlet, který se stará o rozdˇelování požadavku˚ mezi jednotlivé zpracovatele. Jako zpracovatelé slouží tˇrídy oznaˇcené anotací @Controller. K vykreslení odpovˇedí slouží nástroje pro zobrazení. Tento princip je ilustrován na obrázku 3.2.
Obrázek 3.2: Spring MVC [10] 12
˚ 3.2. TVORBA PORTLET U Tˇrídy oznaˇcené jako zpracovatelé dále musí obsahovat metody na vyˇrizování požadavku. ˚ Tyto metody mají ve Springu libovolné jméno, staˇcí, že jsou oznaˇceny anotací @ActionMapping pro zpracování požadavku na akci, nebo @RenderMapping pro zpracování požadavku na vykreslení. Tˇechto metod, stejnˇe jako zpracovatelu, ˚ muže ˚ být v portletu více. Pro jejich rozlišení lze do anotací pˇridat atribut params, jenž urˇcuje jména a hodnoty parametru. ˚ Pˇri požadavku s parametry je pak podle nich urˇcen odpovídající zpracovatel a jeho metoda. 3.2.4 JavaServer Pages JavaServer Pages (JSP) je technologie, patˇrící do Java EE, sloužící pro generování dynamického webového obsahu, jako je HTML (HyperText Markup Language) nebo XML. JSP stránka je obdobou servletu a každá JSP stránka je pˇri nasazení pˇreložena na servlet. Zatímco servlet je tˇrída, JSP stránka je textový dokument popisující podobu odpovˇedi [4]. Proto se JSP zpravidla používá pro tvorbu zobrazení (view) v MVC architektuˇre. V JSP stránce lze dynamický obsah tvoˇrit pomocí skripletu. ˚ To je kód v jazyku Java ohraniˇcený speciálními symboly. Pˇri pˇrekladu stránky na servlet dojde pouze k odstranˇení uvozujících symbolu˚ a kód je ponechán k vykonání [4]. Pˇri použití skripletu˚ jsou však stránky nepˇrehledné, komplikované a kód je špatnˇe udržovatelný. Proto je doporuˇcováno v JSP používat Expression Language (EL) a JavaServer Pages Standard Tag Library (JSTL). EL a JSTL nahrazují skriplety, výrazy EL jsou uvozeny složenými závorky, jimž pˇredchází znak pro dolar [4]. V EL výrazech je možné pˇristupovat k hodnotám objektu˚ podobnˇe, jako v pˇrípadˇe skripletu. ˚ JSTL dovolují generovat dynamický obsah v závislosti na hodnotách EL výrazu, ˚ pˇriˇcemž není potˇreba psát kód v programovacím jazyku a stránky tím nabývají na pˇrehlednosti.
13
Kapitola 4
Požadavky na objednávkový systém Bakaláˇrská práce rozvíjí internetový obchod, jenž vzniká v IBA CZ, s.r.o. ve spolupráci s Fakultou informatiky Masarykovy univerzity v rámci prumyslového ˚ partnerství. Stávající internetový obchod umí pracovat s produkty, dokáže je zobrazovat podle kategorií a nabízí nástroje pro správu obchodu administrátory [18]. Zadáním této bakaláˇrské práce je rozšíˇrit internetový obchod o objednávkový systém. V této kapitole bude popsáno stávající rˇ ešení internetového obchodu, následnˇe bude provedeno srovnání existujících objednávkových systému˚ a jako výsledek bude vytvoˇren seznam funkˇcních a nefunkˇcních požadavku˚ na tvoˇrený objednávkový systém.
4.1
Popis stávajícího rˇešení
Stávající internetový obchod se skládá ze dvou hlavních cˇ ástí. První z nich je webová aplikace urˇcená pro nasazení na portálu Liferay. Tuto aplikaci tvoˇrí nˇekolik portletu˚ a z hlediska architektury se jedná o prezentaˇcní vrstvu systému. Druhou cˇ ást, tedy aplikaˇcní a datovou vrstvu, tvoˇrí dva modulární systémy. Prvním je rozhraní internetového obchodu, které tvoˇrí rozhraní mezi možnými implementacemi aplikaˇcní logiky a mezi možnými implementacemi uživatelských rozhraní. Druhým je samotná implementace aplikaˇcní logiky internetového shopu splnující ˇ požadavky rozhraní. Rozhraní internetového obchodu se skládá z nˇekolika modulu, ˚ z nichž každý odpovídá za nˇejakou funkcionalitu obchodu. Tˇemito moduly jsou Integration API, což je modul sdružující tˇrídy a metody, které jsou spoleˇcné ve více modulech a z duvodu ˚ pˇrehlednosti jsou umístˇeny zde a zevšeobecnˇeny tak, aby je tˇrídy ostatních modulu˚ mohly využívat. Dalšími moduly jsou User API, modul urˇcující práci s uživateli, Configuration API, modul sloužící jako rozhraní pro správu konfigurace, Catalog API, rozhraní páteˇrní funkcionality internetového obchodu nabízející správu produktu˚ a kategorií, Price Policy API, modul jako rozhraní pro správu cen, a Image API, rozhraní pro práci s obrázky [18]. Samotná implementace rozhraní internetového obchodu je pak složena z modulu, ˚ které odpovídají jednotlivým modulum ˚ rozhraní, jednotlivé tˇrídy rozšiˇrují nebo implementují tˇrídy rozhraní. V pˇrípadˇe potˇreby je možné vymˇenit implementující moduly za jiné, cˇ i vymˇenit celou implementaci internetového obchodu, aniž by muselo dojít ke zmˇenˇe v prezentaˇcní vrstvˇe aplikace. 14
˚ 4.2. SROVNÁNÍ OBJEDNÁVKOVÝCH SYSTÉM U
4.2
Srovnání objednávkových systému˚
Existuje mnoho rozdílných objednávkových systému˚ internetových obchodu˚ lišících se na ruzných ˚ úrovních. Nˇekteré internetové obchody vyžadují registraci zákazníka a jiné ne, nˇekteré rozprostírají objednávání do mnoha kroku, ˚ jiné tˇreba jen do jednoho. V této podkapitole budou nastínˇeny rozdílné pˇrístupy k objednávkovým systémum, ˚ ty budou ukázány na pˇríkladech reálných internetových obchodu, ˚ a následnˇe bude provedeno jejich zhodnocení. Povinnost registrace zákazníka Základním rozdílem mezi objednávkovými systémy je ten, zda vyžadují registraci uživatele. Napˇríklad známý internetový obchod Amazon1 pˇri procesu objednávání u neregistrovaného zákazníka vyžaduje po uživateli registraci. Ta sestává ze dvou kroku, ˚ pˇriˇcemž následují další cˇ tyˇri obrazovky pˇredtím, než je možnost vytvoˇrit objednávku. V pˇrípadˇe, že zákazník nenakupuje zboží v obchodˇe pravidelnˇe, ale jedná se o jednorázovou objednávku, je tento proces pro zákazníka nadbyteˇcný, a navíc relativnˇe nároˇcný. Naopak v pˇrípadˇe, že zákazník nakupuje v takovém obchodˇe pravidelnˇe, ocení, že systém pˇredvyplní veškeré známé údaje. Zákazníkovi pak staˇcí k objednání jen nˇekolik kliknutí. U nˇekterých internetových obchodu˚ je pro objednání zboží registrace volitelná. Takovým obchodem je napˇríklad Alza2 . Objednání v nˇem zabere tˇri kroky, pˇriˇcemž ve druhém je nepˇrihlášenému uživateli nabídnut výbˇer mezi pokraˇcováním bez registrace, novou registrací, nebo pˇrihlášením pro nepˇrihlášeného registrovaného zákazníka. Zvolení první možnosti nabídne formuláˇr pro zadání údaju˚ nutných pro odeslání objednávky a neobtˇežuje zákazníka nutností registrace. Nároˇcnost objednávání Ukázalo se, že problematika nároˇcnosti objednávání velice souvisí s nutností registrace. Jak bylo ukázáno, objednání zboží na Amazon muže ˚ trvat až šest kroku, ˚ pro pˇrihlášeného zákazníka naopak nabízí možnost objednání jediným kliknutím. U obchodu˚ jako Itek3 nebo Alza zabere objednání tˇri kroky, kde prvním krokem je zvolení zpusobu ˚ platby a dopravy, druhým je zadání adres a tˇretím krokem je potvrzení zadaných údaju˚ a závazné objednání. Opaˇcným extrémem je napˇríklad Fantasya4 , kde i pro nepˇrihlášeného uživatele znamená objednání zboží jedinou obrazovku, pˇriˇcemž po zadání zpusobu ˚ platby a dodání lze rozbalit objednávkový formuláˇr i s tlaˇcítkem pro závazné objednání. Takové objednání je velice pohodlné, ale nedává uživateli šanci zkontrolovat správnost zadaných údaju, ˚ zárovenˇ uživatel nemusí oˇcekávat závazné objednání již pˇri prvním kroku a muže ˚ dojít k nechtˇenému objednání. 1. 2. 3. 4.
Viz . Viz . Viz . Viz .
15
4.3. POŽADAVKY NA OBJEDNÁVKOVÝ SYSTÉM Pˇrehlednost objednávání Duležitým ˚ prvkem stránek obecnˇe je pˇrehlednost. U internetových obchodu˚ nabývá na du˚ ležitosti tím, že nepˇrehledné stránky mohou v potenciálním zákazníkovi navozovat pocit neduvˇ ˚ eryhodnosti, a tím jej odradit od nákupu v konkrétním obchodˇe. Pˇríkladem nepˇrehledného objednávkového systému je napˇríklad Czechcomputer5 , kde formuláˇr pro objednání leží pouze uprostˇred stránky, obklopen výbˇerem kategorií s nabídkou produktu, ˚ ale pˇredevším z druhé strany reklamou na jiné produkty obchodu. Zárovenˇ pokud nepˇrihlášený uživatel klikne na tlaˇcítko koupit, místo závazného objednání je vyzván k pˇrihlášení nebo registraci, což muže ˚ být pro uživatele neoˇcekávané a odrazující chování.
4.3
Požadavky na objednávkový systém
Pˇrestože nelze urˇcit, jaké rˇ ešení objednávkového systému je nejlepší, srovnáním existujících systému˚ a ze zadání práce lze urˇcit požadavky na objednávkový systém, jenž bude možné integrovat do stávajícího internetového obchodu. Funkˇcní požadavky Objednávkový systém (ObjS) pˇrijímá seznam požadovaného zboží. Zákazník se muže ˚ v prvním kroku ObjS pˇrihlásit. ObjS nabídne zákazníkovi formuláˇr pro zadání fakturaˇcních a dodacích údaju. ˚ Následnˇe ObjS zkontroluje, že zákazník správnˇe zadal všechny potˇrebné údaje. Pokud údaje nejsou validnˇe zadané, ObjS musí formuláˇr pˇredložit znovu s pˇredvyplnˇenými údaji, špatnˇe zadané položky musí být vyznaˇceny. Pokud jsou údaje zadány správnˇe, ObjS nabídne zákazníkovi stránku pro kontrolu kupovaného seznamu zboží a zadaných údaju. ˚ Ve druhém kroku ObjS již nelze údaje mˇenit. ObjS nabídne ve druhém kroku pˇrihlášenému uživateli možnost platby kartou. ObjS musí nabídnout klikatelné odkazy na úpravu seznamu kupovaného zboží a zadaných údaju. ˚ Po potvrzení objednávky musí ObjS informovat zákazníka o provedení objednávky. V každém kroku musí ObjS nabízet zákazníkovi klikatelné odkazy na pˇredchozí kroky objednávky. Pro pˇrihlášené uživatele ObjS pˇredem vyplnuje ˇ známé údaje. Nefunkˇcní požadavky ObjS je psán jako rozšíˇrení existujícího webového shopu. ObjS je psán v tˇrívrstvé architektuˇre, lze logicky rozlišit datovou, aplikaˇcní a prezentaˇcní vrstvu. ObjS bude psán objektovˇeorientovaným zpusobem ˚ v jazyku Java. Prezentaˇcní vrstva ObjS je vytvoˇrena za použití Spring Portlet MVC Framewok. Aplikaˇcní logika ObjS implementuje modul Ordering API. Aplikaˇcní vrstva ObjS je psána za použití Spring Framework. Perzistentní vrstva ObjS používá Java Persistence API. ObjS je psán pro nasazení na portálu Liferay. ObjS musí být graficky jasný a pˇrehledný. ObjS mohou používat pˇrihlášení i nepˇrihlášení uživatelé. Uživatel 5. Viz .
16
4.3. POŽADAVKY NA OBJEDNÁVKOVÝ SYSTÉM musí vždy vˇedˇet, co se od nˇej oˇcekává a kam má pokraˇcovat. Uživatel musí pˇresnˇe vˇedˇet, co vyvolá každé tlaˇcítko za následek. Po potvrzení objednávky ObjS objednávku uloží do systému a pˇridˇelí jí stav. ObjS používá modul User API internetového obchodu pro správu uživatelu. ˚ ObjS vhodnˇe využívá moduly Integration API a Integration Implementation pro integraci do projektu internetového obchodu. ObjS dodržuje jmenné a formální konvence internetového obchodu.
17
Kapitola 5
Analýza a návrh objednávkového systému 5.1
Pˇrípady užití
Analýza funkˇcních požadavku˚ je provedena v diagramu pˇrípadu˚ užití, jenž je zobrazen na obrázku 5.1. Následuje popis úˇcastníku˚ objednávkového systému a charakteristika jednotlivých pˇrípadu˚ užití. Ze stylistických duvod ˚ u˚ jsou pak formální specifikace jednotlivých pˇrípadu˚ užití souˇcástí pˇrílohy A.
Obrázek 5.1: Diagram pˇrípadu˚ užití
18
ˇ 5.1. P RÍPADY UŽITÍ Popis úˇcastníku˚ systému Objednávkový systém bude schopný pracovat s tˇremi typy úˇcastníku, ˚ pˇrihlášenými a nepˇrihlášenými uživateli a administrátory. Po nepˇrihlášeném uživateli nebude požadovat registraci ani pˇrihlášení. Pˇrihlásit se lze nejpozdˇeji pˇri zadávání fakturaˇcních a dodacích údaju. ˚ Výhodou pˇrihlášení pak je pˇredvyplnˇení známých údaju˚ o uživateli ve formuláˇrích. Administrátor provádí správu objednávkového systému. Zadání fakturaˇcních a dodacích údaju˚ Tento pˇrípad užití zaˇcíná v okamžiku, kdy uživatel pˇrejde do objednávkového systému. Uživateli bude nabídnut formuláˇr pro zadání fakturaˇcních údaju. ˚ Pro pˇrihlášeného uživatele bude formuláˇr pˇredvyplnˇený známými údaji. Pokud se nepˇrihlášený uživatel v tomto bodˇe pˇrihlásí, budou údaje automaticky pˇredvyplnˇeny. Pokud uživatel zadá údaje ve špatném tvaru, bude mu formuláˇr nabídnut opakovanˇe, zadané údaje zustanou ˚ vyplnˇené, špatnˇe zadané údaje budou vyznaˇceny s popisem chyby. V pˇrípadˇe, že uživatel požaduje doruˇcit údaje na jinou, než fakturaˇcní adresu, je mu nabídnut formuláˇr pro zadání dodacích údaju. ˚ Formuláˇr bude splnovat ˇ vlastnosti formuláˇre pro zadání fakturaˇcních údaju. ˚ Potvrzení objednávky Pˇrípad užití zaˇcíná v okamžiku, kdy uživatel správnˇe zadal požadované fakturaˇcní a dodací údaje. Uživateli bude poskytnut výpis nakupovaného zboží a zadaných údaju, ˚ bude mu umožnˇeno navrácení do košíku pro úpravu nakupovaného zboží a navrácení do formuláˇru˚ pro zmˇenu zadaných údaju. ˚ Uživateli bude nabídnut výbˇer pro zpusob ˚ platby a doruˇcení objednávky. Pokud uživatel zvolí zpusob ˚ platby a doruˇcení objednávky a nenavrátí se kvuli ˚ zmˇenˇe objednávky nebo fakturaˇcních cˇ i doruˇcovacích údaju, ˚ je mu umožnˇeno potvrzení objednávky. To zpusobí ˚ zapsání objednávky do systému, zmˇenu stavu objednávky a potvrzení pˇrijetí objednávky uživateli. Zrušení objednávky Tento pˇrípad užití zaˇcíná, pokud pˇrihlášený uživatel požaduje zrušení již potvrzené objednávky. Uživateli je nabídnut formuláˇr pro identifikaci objednávky pomocí unikátního cˇ ísla a dojde k vyhledání objednávky. Uživatel potvrdí zrušení objednávky, informace je pˇredána správci internetového obchodu a rˇ ízení je pˇredáno externímu nástroji podle vnitˇrní politiky obchodu. Platba kartou Tento pˇrípad užití je umožnˇen pouze pˇrihlášenému uživateli. Zaˇcíná po odeslání validních fakturaˇcních údaju. ˚ Pˇrihlášenému uživateli je mezi možnostmi platby nabídnuta možnost 19
5.2. NÁVRH OBJEDNÁVKOVÉHO SYSTÉMU platby kartou. Pˇri zvolení této možnosti je uživatel pˇresmˇerován podle politik obchodu do systému pro platbu kartu. Správa objednávek Pˇrípad užití pˇrístupný administrátorovi. Tomu je nabídnuta obrazovka pro možnosti správy objednávek. Pro vyhledání objednávek je administrátorovi nabídnut formuláˇr pro zadání parametru˚ hledání. Vyhledávat bude možné dle identifikaˇcních údaju˚ registrovaných uživatelu, ˚ identifikaˇcního cˇ ísla objednávky, data provedení objednávky cˇ i stavu objednávky.
5.2
Návrh objednávkového systému
Objednávkový systém bude mít tˇrívrstvou architekturu. Prezentaˇcní vrstva je realizována jako portletová aplikace, aplikaˇcní vrstvu tvoˇrí služby dostupné vrstvˇe prezentaˇcní a datová vrstva zaobaluje práci nad datovým úložištˇem. Mezi prezentaˇcní a aplikaˇcní vrstvou stojí modul Ordering API, jenž vznikl ve firmˇe IBA CZ, s.r.o., ten má funkci rozhraní mezi prezentaˇcní a aplikaˇcní vrstvou objednávkového systému. K tomu využívá dvou prostˇredku. ˚ Prvním je samotný interface (tˇrída rozhraní v Javˇe) OrderingService. Druhým prostˇredkem jsou DTO (Data Transfer Object). To jsou objekty sloužící k pˇredávání dat mezi cˇ ástmi aplikace [12], v tomto pˇrípadˇe mezi aplikaˇcní a prezentaˇcní vrstvou systému. 5.2.1 Komponenty objednávkového systému Komponenty objednávkového systému bude možné logicky oddˇelit podle vzoru tˇrívrstvé architektury. Diagram komponent na obrázku 5.2 zobrazuje tyto komponenty a vztahy mezi nimi a jejich okolím. Datová vrstva bude tvoˇrena modelem a DAO (Data Access Object). Model reprezentuje data uložená v datovém zdroji. DAO jsou objekty, které zaobalují funkcionalitu datového zdroje, tedy ukládání, úpravu a získávání dat, a transparentnˇe ji zprostˇredkovávají aplikaˇcní vrstvˇe [11], pˇriˇcemž pracují s daty ve formˇe entit. Podle pravidel tˇrívrstvé architektury musí být komponenty datové vrstvy nezávislé na komponentách vrstvy aplikaˇcní. Aplikaˇcní vrstvu bude reprezentovat služba implementující rozhraní OrderingService. Ta ke své cˇ innosti potˇrebuje komponentu sloužící ke konverzi dat mezi tˇrídami modelu, k nimž pˇristupuje prostˇrednictvím DAO, a DTO z rozhraní. Komponenty datové i aplikaˇcní vrstvy využívají služeb modulu˚ Integration API a Integration Implementation, což vyplývá z nefunkˇcních požadavku˚ na systém, integrace do internetového obchodu a dodržování projektových konvencí. Zárovenˇ musí být komponenty aplikaˇcní vrstvy nezávislé na vrstvˇe prezentaˇcní, což plyne z pravidel tˇrívrstvé architektury. Prezentaˇcní vrstva objednávkového systému bude tvoˇrena jako portletová aplikace. Prezentaˇcní vrstva využívá služby aplikaˇcní logiky pomocí rozhraní OrderingService. Zárovenˇ nepoužívá žádné komponenty tˇrídy datové. Dále využívá služby rozhraní User API, jež je 20
5.2. NÁVRH OBJEDNÁVKOVÉHO SYSTÉMU
Obrázek 5.2: Diagram komponent implementováno v modulu User Implementation, nicménˇe v pˇrípadˇe zmˇeny této komponenty nebudou díky rozhraní potˇrebné v objednávkovém systému žádné zmˇeny. 5.2.2 Tˇrídy objednávkového systému Každá komponenta objednávkového systému se bude skládat z více tˇríd. Diagram tˇríd na obrázku 5.3 zobrazuje návrh tˇríd objednávkového systému a vzájemné vazby mezi nimi. Zárovenˇ logicky uspoˇrádává tˇrídy do pˇríslušných komponent a vzájemnˇe je oddˇeluje podle pravidel tˇrívrstvé architektury. Kompletní návrhový diagram tˇríd je souˇcástí pˇrílohy B. Model bude tvoˇren entitami a DAO. Diagram tˇríd zobrazuje entity objednávkového systému a vztahy mezi nimi. Objednávka (OrderEntity) obsahuje kolekci položek objednávky (OrderItemEntity), zárovenˇ má urˇcen zpusob ˚ platby (PaymentMethodEntity) a svuj ˚ stav (OrderStatusEntity). Zpusob ˚ platby a stav objednávky budou mít vlastní tabulku v datovém zdroji, aby bylo možno libovolnˇe mˇenit doménu jejich hodnot bez programových zmˇen. V datovém zdroji bude ukládána také správa zmˇen stavu˚ (OrderStatusLogEntity), jež slouží 21
5.2. NÁVRH OBJEDNÁVKOVÉHO SYSTÉMU pro ukládání zmˇen stavu˚ pro každou objednávku a cˇ asu tˇechto zmˇen. K manipulaci entit nad datovým zdrojem budou sloužit obdobnˇe pojmenované DAO. Ty tvoˇrí rozhraní, pomocí nˇejž pˇristupují tˇrídy aplikaˇcní vrstvy k datovému zdroji. Entity a DAO tvoˇrí datovou vrstvu a jako takové nesmí být závislé na tˇrídách vrstvy aplikaˇcní. Aplikaˇcní vrstvu bude tvoˇrit tˇrída OrderingServiceImpl. Ta realizuje služby aplikaˇcní logiky. Prezentaˇcní vrstva bude komunikovat s aplikaˇcní logikou pomocí dat ve formˇe DTO, je tedy tˇreba vytvoˇrit pomocné tˇrídy, jež budou používány tˇrídou OrderingServiceImpl a budou konvertovat data mezi DTO a entitami vrstvy datové. Aplikaˇcní vrstva bude dále používat tˇrídy DAO, pomocí nichž pˇristupuje k datovému zdroji. Prezentaˇcní vrstva bude mít MVC architekturu. Portlety slouží pro zpracování požadavku˚ a pˇredávání odpovˇedí, zobrazení bude realizováno pomocí vhodného prezentaˇcního nástroje a model prezentaˇcní vrstvy je tvoˇren rozhraním aplikaˇcní logiky. Zpracovateli prezentaˇcní vrstvy tedy budou portlety pro objednávání uživatelem a portlety pro správu objednávek administrátory.
22
5.2. NÁVRH OBJEDNÁVKOVÉHO SYSTÉMU
Obrázek 5.3: Diagram tˇríd
23
Kapitola 6
Implementace objednávkového systému Pˇri vývoji prototypu objednávkového systému byl dodržen návrh systému a vývoj je tedy rozdˇelen do tˇrí cˇ ástí podle logických vrstev aplikace. Tˇemi jsou vrstvy datová, aplikaˇcní a prezentaˇcní. Z hlediska formálního uspoˇrádání jsou tˇrídy datové a aplikaˇcní vrstvy souˇcástí modulu Ordering Implementation, zatímco portlety jsou souˇcástí webové aplikace internetového obchodu.
6.1
Vývoj datové vrstvy
Zatímco perzistentním úložištˇem je relaˇcní databáze, Java pracuje s objekty. Pro pˇrenos dat mezi relaˇcní databází a objekty je použit nástroj pro objektovˇe-relaˇcní mapování nad datovým zdrojem, Java Persistence API (JPA). Základními prvky JPA jsou entity a EntityManager. Entity slouží jako forma pro objektovˇe-relaˇcní mapování, zatímco EntityManager provádí manipulaci dat nad datovým zdrojem pomocí spravovaných entit. Tento vzor odpovídá entitám a DAO v návrhu. Entitami jsou proto podle jmenných konvencí aplikace OrderEntity, OrderItemEntity, OrderStatusEntity, OrderStatusLogEntity a PaymentMethodEntity. Úlohu DAO z návrhu potom plní tˇrídy OrderDAO, OrderItemDAO, OrderStatusDAO, OrderStatusLogDAO a PaymentMethodDAO. Ty zaobalují funkcionalitu EntityManageru a aplikaˇcní vrstvˇe nabízí potˇrebné metody pro správu dat nad datovým zdrojem. Datová vrstva s výhodou využívá generické programování, jež umožnuje ˇ abstrakci kódu tak, aby byl co nejménˇe závislý na objektových typech. DAO tˇrídy rozšiˇrují tˇrídu GenericDAO, jež zaobaluje EntityManager a dokáže základní operace nad perzistentním úložištˇem entit BaseEntity. Entity objednávkového systému proto rozšiˇrují BaseEntity, díky cˇ emuž DAO získávají tuto jednoduchou funkcionalitu a šetˇrí tím opakované vytváˇrení základního kódu. Konfigurace entit je v pˇrípadˇe objednávkového systému provádˇena pomocí anotací, OrderEntity vypadá následovnˇe: @Entity @Table(name = "WEBSHOP_ORDER") public class OrderItem extends BaseEntity { @Id @GeneratedValue(strategy = GenerationType.AUTO) private Long id; @ManyToOne
24
ˇ 6.2. VÝVOJ APLIKA CNÍ VRSTVY private PaymentMethodEntity paymentMethod; @OneToMany private List items; ... }
Anotace @Entity oznaˇcuje JPA entitu, rˇ ádek s anotací @Table pˇriˇrazuje tabulce v datovém zdroji explicitní název. Pomocí @GeneratedValue je entitˇe pˇri vložení do úložištˇe automaticky vygenerováno unikátní identifikaˇcní cˇ íslo, anotace @OneToMany oznaˇcuje vztah mezi entitami OrderItemEntity a OrderEntity, pˇriˇcemž rˇ íká, že OrderEntity muže ˚ být ve vztahu s více OrderItemEntity, ale ne naopak. Ucelenˇejší ukázka tˇrídy OrderEntity je zobrazena v pˇríloze C.
6.2
Vývoj aplikaˇcní vrstvy
Jádrem aplikaˇcní vrstvy je tˇrída implementující rozhraní OrderingService. Ta se podle jmenných konvencí internetového obchodu jmenuje OrderingServiceImpl. Tato tˇrída implementuje aplikaˇcní logiku pˇrístupnou prezentaˇcní vrstvˇe. Zaobaluje proto veškerou funkcionalitu vrstvy aplikaˇcní i datové. OrderingServiceImpl využívá služeb tˇríd DAO k pˇrístupu k datovému zdroji. Sama pak nad tˇemito daty provádí metody, jež jsou potˇrebné v prezentaˇcní vrstvˇe, jako je ukládání objednávek, získávání objednávek podle urˇcených kritérií, manipulace stavu˚ objednávek cˇ i získávání informací o zmˇenách tˇechto stavu. ˚ Prezentaˇcní vrstva je pˇritom díky injektování závislostí, jež umožnuje ˇ Spring Framework, na této tˇrídˇe programovˇe nezávislá. V prezentaˇcní vrstvˇe je pouze deklarován požadavek na získání OrderingService, dodání implementace této tˇrídy je pak již plnˇe v rˇ ízení IoC kontejneru: @Service public class OrderingServiceImpl implements OrderingService { @Autowired private OrderingService orderingService; ... }
Na pˇríkladu je vidˇet požadavek na dodání bean implementující OrderingService. Anotace @Autowired znaˇcí, že má Spring kontejner automaticky pˇriˇradit odpovídající bean, pokud takový najde. Dalším krokem je oznaˇcení OrderingServiceImpl tak, aby Spring poznal, že jej lze použít jako relevantní bean. To lze bud’ konfigurací v XML souboru, nebo jednodušeji anotacemi, napˇríklad @Service. Pokud je bean oznaˇcen anotací, je tˇreba springovému kontejneru nastavit automatické vyhledávání tˇríd v konfiguraˇcním XML souboru a dále nastavit cestu k tˇemto tˇrídám. Spring IoC kontejner pak automaticky vyhledá bean OrderingServiceImpl a vloží jej prezentaˇcní vrstvˇe pod promˇennou orderingService. V objednávkovém systému je použito automatické vyhledávání tˇríd, jež je nastaveno v konfiguraˇcním XML souboru cestou k balíku, jenž má Spring prohledávat. 25
ˇ 6.3. VÝVOJ PREZENTA CNÍ VRSTVY OrderingService, a tedy i OrderingServiceImpl, vymˇenuje ˇ data s prezentaˇcní vrstvou ve formˇe DTO, s datovou vrstvou zase ve formˇe entit. Je proto tˇreba v aplikaˇcní vrstvˇe data konvertovat mezi tˇemito dvˇema typy. K tomu je použito generické rozhraní Converter, jež je souˇcástí Spring Framework. Pro konverzi jsou vytvoˇreny vlastní tˇrídy implementující toto rozhraní. Výhoda použití rozhraní Converter se projevuje díky IoC kontejneru. Místo vytváˇrení nové instance tˇrídy pokaždé, když je tˇreba konvertovat entitu na DTO, je možné použít Springovou tˇrídu ConversionService: @Autowired private ConversionService conversionService; OrderEntity orderEntity; ... Order order = conversionService.convert(orderEntity, order.class);
Seznam použitelných konvertoru˚ je nastaven v konfiguraˇcním XML souboru, díky cˇ emuž Spring automaticky vyhledá správný konvertor, tedy tˇrídu implementující rozhraní Converter, podle vstupních argumentu˚ metody convert. Na pˇríkladu je vidˇet metoda pro konverzi dat z OrderEntity do instance tˇrídy Order. Instance tˇrídy OrderEntity je konvertoru pˇredána jako první argument, druhý argument slouží právˇe pro urˇcení cílové tˇrídy pro konverzi, v tomto pˇríkladˇe je to tˇrída Order. V pˇríloze C jsou pak ukázány tˇrídy pro konverzi dat mezi OrderItem a OrderItemEntity, pˇriˇcemž je dbáno na ochranu práv spoleˇcnosti IBA CZ, s.r.o. a projektovˇe specifický kód je odstranˇen.
6.3
Vývoj prezentaˇcní vrstvy
Prezentaˇcní vrstva objednávkového systému splnuje ˇ MVC architekturu. Modelem je rozhraní aplikaˇcní logiky, zobrazení (view) realizují stránky JSP. Roli zpracovatelu˚ (controller) obstarávají dva portlety. Jedním je portlet pro objednávání, pomocí nˇejž zákazníci provádí objednávky. Druhým je portlet sloužící pro správu objednávek administrátory. Portlety jsou tvoˇreny za použití Spring Portlet MVC Framework. Portlet je tvoˇren jedním zpracovatelem oznaˇceným anotací @Controller. Ten realizuje tˇri kroky objednávkového systému. Pˇri vstupu do objednávání je zpracovateli poslán jako parametr odkaz na seznam kupovaných produktu˚ do databáze. Výsledkem úspˇešného objednání je zápis instance tˇrídy Order do aplikaˇcní logiky. Ke zdrojum ˚ aplikaˇcní logiky pˇristupuje portlet formou injektování závislostí. Po nastavení cesty automatického prohledávání v konfiguraˇcním XML souboru vyhledá Spring IoC kontejner na nastavené cestˇe vhodné komponenty a doplní je jako beany do promˇenných oznaˇcených anotací @Autowired. Jednotlivé kroky objednávání jsou realizovány pomocí anotovaných metod. Požadavek na akci zpracovávají tˇrídy oznaˇcené @ActionMapping, požadavek na vykreslení tˇrídy s anotací @RenderMapping. Mezi tˇemito metodami se rozlišuje pomocí atributu params tˇechto anotací. Instance objednávky je mezi jednotlivými kroky ukládána v portletových relaˇcních (session) atributech. Ty ukládají objekty po celou dobu relace. Objednávka takto musí být ukládána proto, aby uživatel mohl mezi možnými kroky objednávání libovolnˇe pˇrecházet, 26
ˇ 6.3. VÝVOJ PREZENTA CNÍ VRSTVY aniž by došlo ke ztrátˇe dat objednávky. Na následující ukázce je zobrazena manipulace s instancí objednávky pˇri reakci portletu na požadavek na akci a v metodˇe pro vykreslení druhého kroku objednávání. V metodˇe pro zpracování požadavku na akci je instance objednávky uložena v atributu relace, v metodˇe pro vykonání požadavku na vykreslení je pak tato instance získána a vhodnˇeji pˇredána JSP stránce, v tomto pˇrípadˇe pomocí objektu model: @Controller @RequestMapping(params = PARAM_CONTROLLER + "=" + CONTOLLER_ORDER) public class OrderingViewController { @ActionMapping(params = ACTION + "=" + ACTION_STEP_TWO) public void actionStepTwo(...) { Order order; ... request.getPortletSession() .setAttribute(SESSION_ATTRIBUTE_ORDER, order); } @RenderMapping(params = PARAM_PAGE + "=" + RENDER_STEP_TWO) public String renderStepTwo(..., Model model) { Order order = (Order) request.getPortletSession() .getAttribute(SESSION_ATTRIBUTE_ORDER); ... model.addAttribute(ATTRIBUTE_ORDER, order); } ... }
Formuláˇr pro zadání fakturaˇcních a dodacích údaju˚ je tvoˇren pomocí knihovny znacˇ ek Form technologie Spring. Objednávka je pˇredána JSP stránce jako atribut instance tˇrídy Model, stránka následnˇe pomocí knihovny znaˇcek Form vytváˇrí formuláˇr. Formuláˇr cˇ te a zapisuje pˇrímo do potˇrebných atributu˚ objednávky podle nastavení cesty v elementech knihovny Form. Validace zadaných dat podle urˇcených kritérií je provádˇena v portletu pomocí rozhraní Validator technologie Spring, jak je zobrazeno v pˇríloze C. Ta ilustruje inicializaci a zpracování formuláˇre pro zadání fakturaˇcních a dodacích údaju˚ s ohledem na ochranu práv spoleˇcnosti IBA CZ, s.r.o. Na následujícím pˇríkladu je vidˇet internacionalizovaná cˇ ást formuláˇre pro zadání jména zákazníka, jež dokáže pˇredem vyplnit známé údaje a umožnuje ˇ validaci zadaných dat: <spring:message code="label-customername"/>
27
6.4. TESTOVÁNÍ
...
Výsledný formuláˇr je zobrazen na obrázku 6.1. Styl portletu se pˇrizpusobuje ˚ vzhledovému nastavení portálu Liferay, a tím dodržuje jednotný vzhled celého portálu. Zárovenˇ se pˇri zmˇenˇe nastavení podoby portálu mˇení i vzhled portletové aplikace. Ukázkové obrazovky objednávkového systému jsou souˇcástí pˇrílohy D. Na ukázce portletu pro administrátory je ilustrována jednoduchost zmˇeny stylu portletu pˇri zmˇenˇe vzhledu portálu Liferay. Zárovenˇ je v pˇrípadˇe administrátora portál nastaven na anglický jazyk, portlet tedy podle dostupné lokalizace komunikuje v nastaveném jazyce.
Obrázek 6.1: Formuláˇr pro zadání fakturaˇcních údaju˚
6.4
Testování
Testováno je za použití nástroje JUnit, pˇriˇcemž integrované testování je umožnˇeno díky nástrojum ˚ Spring Framework. Programovˇe je testováno pˇredevším chování metod tˇrídy OrderingServiceImpl a její injektování. Testy jsou souˇcástí zdrojového kódu a pˇri každém sestavování aplikace jsou na lokálním pˇripojení k databázi testovány metody aplikaˇcní logiky. Je provádˇeno jednotkové testování metod aplikaˇcní logiky. Je testováno správné pˇripojení na databázi, správný zápis objednávek do databáze i fungování tˇríd pro konverzi. Je kontrolováno, zda pˇri pˇrevodu mezi datovým zdrojem, entitami a DTO nedochází ke zmˇenˇe 28
6.4. TESTOVÁNÍ nebo ztrátˇe dat v instancích tˇechto tˇríd. Dále je testováno správné injektování závislosti OrderingServiceImpl a bean pro konverzi dat, tedy zda jsou odpovídající beany kontejnerem nalezeny a správnˇe dodány tˇrídám, jež je požadují. Uživatelsky pak byla testována prezentaˇcní vrstva systému. Obrázek 6.2 zobrazuje uživatelské testování tˇretího kroku objednávky. V horní cˇ ásti obrazovky jsou klikatelné odkazy na pˇredchozí fáze objednávky, pˇriˇcemž stávající krok je barevnˇe vyznaˇcen. Uživateli je dovoleno pouze pˇresunutí do pˇredchozích kroku˚ objednávání a tyto odkazy jsou odlišeny jako funkˇcní. Pomocí cˇ tvrtého odkazu je uživateli naznaˇceno, že následuje již jen potvrzení objednávky ze strany obchodu. Odkazy jsou funkˇcní a nedochází pˇri nich ke ztrátˇe žádných dat. Uživateli jsou dále zobrazeny kupované produkty, vˇcetnˇe množství a cen. Následnˇe jsou pro kontrolu zobrazeny doruˇcovací údaje. Tyto údaje byly validnˇe zadány v pˇredešlém kroku objednávání. Uživatel dále volí zpusob ˚ platby a dopravy zboží a je mu nabídnuto i standardní textové pole pro sdˇelení speciálních požadavku˚ cˇ i pˇripomínek, jež jsou následnˇe uloženy do objednávky.
Obrázek 6.2: Obrazovka tˇretí fáze objednávání
29
Kapitola 7
Závˇer Pˇri rˇ ešení této bakaláˇrské práce byl analyzován, navrhnut a implementován objednávkový systém pro internetový obchod. V rámci práce byly pomocí analýzy existujícího internetového obchodu a srovnání objednávkových systému˚ ruzných ˚ internetových obchodu˚ nalezeny funkˇcní a nefunkˇcní požadavky na vyvíjený objednávkový systém. Následnˇe byl pomocí UML diagramu˚ systém analyzován a navržen tak, aby splnoval ˇ tˇrívrstvou architekturu, pˇriˇcemž prezentaˇcní vrstva byla navržena pro nasazení na podnikovém portálu. Architektura objednávkového systému a integrace do internetového obchodu byly navrženy pomocí diagramu komponent, analýza a návrh tˇríd byl proveden v diagramech tˇríd. Podle návrhu byl vytvoˇren prototyp objednávkového systému pro použití na portálu Liferay. Vytvoˇrený objednávkový systém je modulární a splnuje ˇ tˇrívrstvou architekturu. Prototyp objednávkového systému byl vytvoˇren v jazyku Java v technologii Spring Framework, datová vrstva je postavena na technologii Java Persistence API a prezentaˇcní vrstva využívá speciální springový nástroj pro tvorbu portletu, ˚ Spring Portlet MVC Framework. Aplikace byla testována pomocí nástroje JUnit a uživatelského testování uživatelského rozhraní. Systém umožnuje ˇ objednávání zboží vybraného v internetovém obchodu. Dovoluje provádˇení objednávek pro pˇrihlášené i nepˇrihlášené uživatele, pˇriˇcemž pˇrihlášeným uživatelum ˚ nabízí komfortnˇejší a jednodušší interakci. Objednávky systém ukládá do databáze a administrátorum ˚ nabízí nástroje pro jejich správu. Zdrojový kód aplikace splnuje ˇ zavedené formální konvence internetového obchodu. Objednávkový systém byl vytvoˇren modulárnˇe, je proto možné libovolnˇe mˇenit jeho komponenty. Díky rozhraní mezi aplikaˇcní logikou a prezentaˇcní vrstvou systému je dokonce možné rozšiˇrovat funkce portletové aplikace bez zásahu˚ do aplikaˇcní logiky, stejnˇe jako je možné libovolnˇe mˇenit napˇríklad datový zdroj cˇ i celou aplikaˇcní logiku bez jakékoliv potˇreby upravit prezentaˇcní vrstvu systému. Do budoucna se tak nabízí napˇríklad rozšíˇrení objednávkového systému pro nasazení ve složitém firemním prostˇredí, kde proces objednávání závisí na vnitˇrních politikách podniku a kde muže ˚ být systém propojen s existujícím podnikovým portálem firmy.
30
Literatura [1] Abdelnur, A. a Hepper, S.: JSR 168: Java Portlet Specification, version 1.0 [online], Sun Microsystems, Inc., 2003, Dostupné z URL [cit. 2011-5-11]: . 1.1, 2.1.1, 2.1.2, 2.2.1, 2.2.1, 3.2.1, 3.2.1, 3.2.1, 3.2.1 [2] Adámek, P. a kol.: Podnikové portály [studijní materiál], IBA CZ, s.r.o., Praha, 2011. 2.1.1, 3.2.2 [3] Chinnici, R. a Shannon, B.: Java Platform, Enterprise Edition Specification, v6 [online], Sun Microsystems, Inc., 2009, Dostupné z URL [cit. 2011-5-11]: . 2.2, 3.1, 3.1.1 [4] Coward, D. a Yoshida, Y.: Java Servlet Specification, version 2.4 [online], Sun Microsystems, Inc., 2003, , Dostupné z URL [cit. 2011-5-11]: . 3.2.1, 3.2.4 [5] DeMichiel, L.: JSR 317: Java Persistence API, version 2.0 [online], Sun Microsystems, Inc., 2009, Dostupné z URL [cit. 2011-5-11]: . 3.1, 3.1.1 [6] Delisle, P. a kol.: JavaServer Pages Specification, version 2.1 [online], Sun Microsystems, Inc., 2006, Dostupné z URL [cit. 2011-5-11]: . 3.2 [7] Firestone, J.: Defining the Enterprise Information Portal [online], Executive Information Systems, Inc., 1999, Dostupné z URL [cit. 2011-5-11]: . 2.1 [8] Hepper, S.: JSR 286: Java Portlet Specification, version 2.0 [online], Sun Microsystems, Inc., 2008, Dostupné z URL [cit. 2011-5-11]: . 2.2.1, 3.2.2 [9] Hippo Portal, About portals, portlets and pages [online], Hippo B. V., 2008, Dostupné z URL [cit. 2011-5-11]: . 2.1, 2.2 [10] Hoeller, J. a kol.: Spring Framework, Reference Documentation, 3.0 [online], 2011, Dostupné z URL [cit. 2011-5-11]: . 3, 3.1, 3.1.2, 3.1, 3.1.2, 3.1.2, 3.2.3, 3.2 [11] Java BluePrints, Core J2EE Patterns, Data Access Object [online], Sun Microsystems, Inc., 2001, Dostupné z URL [cit. 2011-5-11]: . 5.2.1 31
[12] Java BluePrints, Core J2EE Patterns, Transfer Object [online], Sun Microsystems, Inc., 2001, Dostupné z URL [cit. 2011-5-11]: . 5.2 [13] Java BluePrints, Model-View-Controller [online], Sun Microsystem, Inc., 2000, Dostupné z URL [cit. 2011-5-11]: . 3.2 [14] Krˇcál, M.: Analýza nasazení podnikového portálu [diplomová práce], Masarykova univerzita, Brno, 2010. 2.1.2 [15] Kropp, A. a kol.: Web Services for Remote Portlets Specification [online], OASIS, 2003, Dostupné z URL [cit. 2011-5-11]: . 2.2, 2.2 [16] Layered Application Guideliness [online], MSDN, Microsoft Corporation, Dostupné z URL [cit. 2011-5-11]: . 3.1 [17] Manhartsberger, F.: Síla portálu: ˚ Využití enterprise portálu˚ [online], 2000, Dostupné z URL [cit. 2011-5-11]: . 2.1.1 [18] Papp, R.: Internetový obchod jako portálová aplikace [diplomová práce], Masarykova univerzita, Brno, 2010. 4, 4.1 [19] Richard, L. a Sezov, J.: Liferay Administrator’s Guide, Liferay, Inc., 2008, 978-0-61524733-5. 2.3.2 [20] WebSphere Portal, Features and benefits [online], IBM, Dostupné z URL [cit. 2011-5-11]: . 2.3.1
32
Pˇríloha A
Specifikace pˇrípadu˚ užití
Obrázek A.1: Potvrzení objednávky
Obrázek A.2: Pˇrihlášení
33
ˇ ˚ UŽITÍ A. S PECIFIKACE P RÍPAD U
Obrázek A.3: Zrušení objednávky
Obrázek A.4: Platba kartou
Obrázek A.5: Správa objednávek
34
ˇ ˚ UŽITÍ A. S PECIFIKACE P RÍPAD U
Obrázek A.6: Zadání fakturaˇcních a dodacích údaju˚
35
Pˇríloha B
Návrhový diagram tˇríd
Obrázek B.1: Návrhový diagram tˇríd
36
Pˇríloha C
Ukázky zdrojového kódu objednávkového systému @Entity @Table(name = "WEBSHOP_ORDER") public class OrderEntity extends BaseEntity { @Id @GeneratedValue(strategy = GenerationType.AUTO) private Long id; private Long externalOrderId; private String note; @Temporal(javax.persistence.TemporalType.DATE) private Date orderDate; @ManyToOne private PaymentMethodEntity paymentMethod; private Currency currency; private String customerId; private String deliveryAddressId; private String invoiceAddressId; @ManyToOne private OrderStatusEntity orderStatus; @OneToMany(mappedBy="orderEntity") private List items; public String getCustomerId() { return customerId; } public void setCustomerId(String customerId) { this.customerId = customerId; } ... }
Pˇríklad C.0.1: OrderEntity
37
C. U KÁZKY ZDROJOVÉHO KÓDU OBJEDNÁVKOVÉHO SYSTÉMU @Component("orderItemToEntityConverter") public class OrderItemToEntityConverter implements Converter { @Autowired private OrderItemDAO dao; ... public OrderItemEntity convert(OrderItem source) { OrderItemEntity oie; if (source.getId() == null) { oie = new OrderItemEntity(); } else { oie = dao.getEntity(source.getId()); } oie.setAmount(source.getAmount()); oie.setCurrency(source.getCurrency()); oie.setName(source.getName()); ... oie.setUnitPrice(source.getUnitPrice()); return oie; } }
Pˇríklad C.0.2: OrderItemToEntityConverter
@Component("entityToOrderItemConverter") public class EntityToOrderItemConverter implements Converter { ... public OrderItem convert(OrderItemEntity source) { OrderItem dto = new OrderItem(); dto.setId(source.getId()); dto.setAmount(source.getAmount()); dto.setCurrency(source.getCurrency()); dto.setName(source.getName()); ... dto.setUnitPrice(source.getUnitPrice()); return dto; } }
Pˇríklad C.0.3: EntityToOrderItemConverter
38
C. U KÁZKY ZDROJOVÉHO KÓDU OBJEDNÁVKOVÉHO SYSTÉMU
@Controller @RequestMapping(value = "VIEW", params = PARAM_CONTROLLER + "=" + CONTROLLER_ORDER) public class OrderingViewController { @Autowired private OrderingService orderingService; @Autowired private OrderValidator orderValidator; ... @RenderMapping(params = PARAM_PAGE + "=" + RENDER_STEP_TWO) public String renderStepTwo( RenderRequest request, RenderResponse response, Model model) { Order order = (Order) request.getPortletSession() .getAttribute(SESSION_ATTRIBUTE_ORDER); if (request.getRemoteUser() != null) { ... } model.addAttribute(ATTRIBUTE_ORDER, order); return VIEW_STEP_TWO; } @ActionMapping(params = ACTION + "=" + ACTION_STEP_THREE) public void actionStepThree( @ModelAttribute(ATTRIBUTE_ORDER) Order order, BindingResult result, ActionRequest request, ActionResponse response) { orderValidator.validate(order, result); response.setRenderParameter(PARAM_CONTROLLER, CONTROLLER_ORDER); if (result.hasErrors()) { response.setRenderParameter(PARAM_PAGE, RENDER_STEP_TWO); } else { request.getPortletSession() .setAttribute(SESSION_ATTRIBUTE_ORDER, order); response.setRenderParameter(PARAM_PAGE, RENDER_STEP_THREE); } } ... }
Pˇríklad C.0.4: OrderingViewController
39
Pˇríloha D
Ukázky dalších obrazovek uživatelského rozhraní
Obrázek D.1: Formuláˇr pro zadání fakturaˇcních a dodacích údaju˚
40
D. U KÁZKY DALŠÍCH OBRAZOVEK UŽIVATELSKÉHO ROZHRANÍ
Obrázek D.2: Výpis seznamu objednávek pro administrátora
Obrázek D.3: Závˇereˇcná obrazovka objednávání
41
