}w!"#$%&'()+,-./012345<ya

}w!"#$%&'()+,-./012345<ya MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Objednávkový systém internetového obchodu na platformě podnikového portálu BAKALÁŘSKÁ PRÁCE Ondřej Veselý Brno, jaro 2011

Prohlášení Prohlašuji, že tato bakalářská práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Vedoucí práce: RNDr. Tomáš Ludík ii

Shrnutí Bakalářská práce se zabývá tvorbou objednávkového systému na platformě podnikového portálu. Je v ní rozebrána problematika podnikových portálů a popsány technologie použité při tvorbě aplikace. Jsou nalezeny požadavky na objednávkový systém, ten je následně analyzován a navržen za použití diagramů. Objednávkový systém rozšiřuje existující internetový obchod, je do něj vhodně integrován a komunikuje s ostatními komponentami obchodu. Návrh splňuje třívrstvou architekturu a umožňuje tím jednoduché rozšíření systému. Prototyp objednávkového systému je psán v jazyku Java a bude nasazen na podnikovém portálu. iii

Klíčová 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.1 Motivace........................................ 1 1.2 Cíle práce........................................ 1 1.3 Struktura práce.................................... 2 2 Podnikové portály..................................... 3 2.1 Teorie podnikových portálů............................. 3 2.1.1 Vymezení podnikových portálů...................... 3 2.1.2 Definice podnikového portálu....................... 3 2.1.3 Možnosti podnikového portálu....................... 4 2.2 Portálové technologie................................. 4 2.2.1 Portálové technologie v Javě........................ 5 2.3 Implementace portálů................................ 6 2.3.1 WebSphere Portal............................... 7 2.3.2 Liferay Portal................................. 7 3 Použité technologie.................................... 8 3.1 Vývojové nástroje................................... 8 3.1.1 Java Persistence API............................. 8 3.1.2 Spring Framework.............................. 9 3.2 Tvorba portletů.................................... 10 3.2.1 Portlety podle JSR 168............................ 10 3.2.2 Portlety podle JSR 286............................ 12 3.2.3 Spring Portlet MVC Framework...................... 12 3.2.4 JavaServer Pages............................... 13 4 Požadavky na objednávkový systém.......................... 14 4.1 Popis stávajícího řešení................................ 14 4.2 Srovnání objednávkových systémů......................... 15 4.3 Požadavky na objednávkový systém........................ 16 5 Analýza a návrh objednávkového systému....................... 18 5.1 Případy užití...................................... 18 5.2 Návrh objednávkového systému.......................... 20 5.2.1 Komponenty objednávkového systému.................. 20 5.2.2 Třídy objednávkového systému...................... 21 6 Implementace objednávkového systému........................ 24 6.1 Vývoj datové vrstvy................................. 24 6.2 Vývoj aplikační vrstvy................................ 25 6.3 Vývoj prezentační vrstvy............................... 26 6.4 Testování........................................ 28 7 Závěr............................................. 30 Literatura............................................. 32 A Specifikace případů užití................................. 33 v

B Návrhový diagram tříd.................................. 36 C Ukázky zdrojového kódu objednávkového systému................. 37 D Ukázky dalších obrazovek uživatelského rozhraní.................. 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žňující sdružování obsahu na jednom místě, jeho prezentaci, přizpůsobení a možnost jednotného přihlášení [1]. Internetové obchody se často skládají z mnoha služeb sdružených na jedné stránce. Těmi mohou být například prohlížení kategorií, výpis produktů, košík, přihlašování či speciální nabídky. Podnikové portály umožní díky svým vlastnostem rozčlenit tyto služby na jednoduché komponenty při zachování jednotného přístupu k nim. Navíc si provozovatel může vybrat, jaké komponenty ve svém obchodě použije, a díky možnostem portálů i zvolit jejich umístění na stránce, společný vzhled nebo rozdílné chování vůči různým skupinám zákazníků. Stávající internetový obchod je psán tak, aby možnosti podnikových portálů co nejvíce využil, a díky modulární architektuře dovoluje jak přímé použití, tak upravení jednotlivých částí obchodu na míru. Existující ř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šířit stávající internetový obchod o objednávkový systém. Je třeba provést analýzu a návrh systému a podle tohoto návrhu vytvořit prototyp objednávkového systému. Ten musí být podle vzoru internetového obchodu psán v objektově-orientovaném jazyku Java za použití technologií Java Persistence API a Spring Framework. Systém musí být navržen a vytvořen pro nasazení na podnikovém portálu. Objednávkový systém musí být vhodně integrován do existujícího internetového obchodu. Bude vhodně využívat ostatní komponenty systému, návrh musí splňovat strukturu aplikace a implementace musí dodržovat zavedené konvence tak, aby bylo snazší v dalších fázích projektu systém rozšiřovat či navazovat na něj. 1

1.3. STRUKTURA PRÁCE 1.3 Struktura práce Začátek práce se věnuje teoretickým východiskům problematiky. Vymezuje podnikové portály, popisuje technologie, na nichž jsou podnikové portály vystaveny, a seznamuje s konkrétními portálovými řešeními. Dále jsou představeny technologie, jež byly použity při řešení práce. Jsou popsány vývojové nástroje usnadňující tvorbu náročných aplikací. Následně je přiblížena problematika tvorby portletů, tedy základních komponent používaných portály. Další část práce popisuje analýzu a návrh objednávkového systému. Jsou zde nalezeny a předloženy požadavky na objednávkový systém a formou UML (Unified Modeling Language) diagramů je zde objednávkový systém analyzován a navržen. Na diagramech jsou ukázány případy užití systému, struktura tříd a vztahy komponent systému včetně provázání s okolím. Nakonec je popsána implementace objednávkového systému. Jsou zde předvedeny technické principy použité při tvorbě systému a ilustrovány na příkladech z vytvořené aplikace. Také zde jsou vysvětlena řešení některých problémů systému a je ukázáno použití klíčových technologií a vývojových nástrojů v aplikaci. 2

Kapitola 2 Podnikové portály 2.1 Teorie podnikových portálů Vymezení portálu není jednoduché, nebot samotný pojem portál má mnoho významů. Historicky se jedná o vstupní bránu nebo ozdobný vchod v architektuře. Slovo portál ovšem nemá jediný význam ani v oblasti informačních technologií. Někdy se pod portálem rozumí internetový portál, tedy nějaká brána do světa internetu (mezi ty patří například Seznam 1 či Yahoo! 2. Stále častěji se ale mluví o podnikových portálech. Těmi se obecně rozumí nástroje pro sdružování obsahu z různých zdrojů, jejich integraci a přizpůsobení zákazníkovi. Složitost problematiky naznačuje i nejednotnost anglického názvosloví v této oblasti. Pojem podnikový portál lze v angličtině vyjádřit jako enterprise portal, enterprise information portal, business portal či corporate portal, přičemž každý z výrazů může mít odlišný význam [7]. Slovo portál bude v následujícím textu významově omezeno na podnikový portál. 2.1.1 Vymezení podnikových portálů Pod pojmem podnikový portál si lze představit další krok v evoluci firemního intranetu [2], tedy podnikový portál jako víceúrovňový technologický systém, jenž integruje procesy, aplikace a data a vytváří jedno celistvé prostředí umožňující společnostem poskytnout jednotný komunikační kanál všem, kteří se chtějí zúčastnit jejich obchodních aktivit [17]. Zároveň podnikový portál označuje aplikaci konkrétní (portálové) technologie, tedy produkt, který umožňuje zpravidla sdružování obsahu z různých zdrojů, integraci a přizpůsobení v závislosti na nasazení č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ě jako lze portálové technologie využívat i pro jiné účely 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 či po- 1. Viz <http://www.seznam.cz/>. 2. Viz <http://www.yahoo.com/>. 3

2.2. PORTÁLOVÉ TECHNOLOGIE užitých technologiích [14]. Pro účely práce je nejrelevantnější definice podaná v Java portlet specifikaci [1], podle které je portál webová aplikace sloužící pro zobrazování prezentační vrstvy informačních systémů, umožňující sdružování obsahu z různých zdrojů na jednom místě, přizpůsobení a jednotné přihlášení pro všechny sdružené služby. 2.1.3 Možnosti podnikového portálu Různé podnikové portály nabízejí jiné vlastnosti, ale již z definice portálu vyplývají ty nejdůležitější a společné všem portálům. Mezi ty patří především možnost sdružení obsahů různých zdrojů na jednom místě, které se děje zpravidla formou sdružování uživatelských rozhraní různých aplikací či filtrování obsahu různých webových zdrojů. To je zefektivněno možností jednotného přihlášení pro všechny tyto sdružené služby, kdy uživatel zadá jediné přihlašovací údaje a je mu přístupné vše, co potřebuje. S tím souvisí i vysoká možnost přizpůsobení, která probíhá na dvou úrovních. Tou první je myšlena možnost přizpůsobení, nebo kontrola obsahu ze strany administrátorů. Ti mohou rozhodnout, jaký obsah se bude uživatelům zobrazovat. Díky tomu není uživatel zahlcen nepotřebnými informacemi, a naopak má přehled o všech informacích důležitých pro jeho činnost. Tím lze zároveň určitým uživatelům zabránit v přístupu k informacím, jež jim mají zůstat utajeny. Samozřejmě platí, že lze nastavit různým uživatelům různý obsah, a tedy pro různé uživatele může portál po přihlášení obsahovat úplně jiné informace. Druhou úrovní je myšlena možnost přizpůsobení obsahu ze strany uživatele, která se neomezuje pouze na úpravu vzhledu, ale také na možnost jednoduchým způsobem měnit návrh stránky a přesouvat jednotlivé obsahy na různá místa. 2.2 Portálové technologie Portály, jako webové aplikace, obecně ke své funkčnosti potřebují dvě 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ěh portletů, jež obsahuje, a zabezpečuje portálové vlastnosti [15]. Tímto kontejnerem může být samotný portál nebo mohou být portálový server s portletovým kontejnerem dvě různé komponenty. Obrázek 2.1 zobrazuje řešení, kde portál a portletový kontejner jsou odděleny. Na obrázku jsou vidět portletové aplikace, skládající se z jednoho či více portletů. Ty jsou shromážděny v portletovém kontejneru, jenž v závislosti na uživatelských požadavcích vyvolává jejich funkcionalitu a zprostředkovává jejich odpovědi. Mezi portletovým kontejnerem a portlety je nakresleno rozhraní, jež umožňuje vytvářet portlety nezávisle na konkrétních portálových řešeních a bude detailněji popsáno v následující kapitole. Klient bezprostředně komunikuje s portálem. Ten zpřístupňuje služby portletového kontejneru a zejména zabezpečuje portálové vlastnosti, jako jsou vykreslování více portletových obsahů na jednu stránku či jednotné přihlášení a vzhled. Většina portálů je psána v jazyku Java na platformě Java EE (Java Platform, Enterprise Edition, viz [3]). Některé jsou však vytvořeny za použití jiných technologií, mezi něž patří 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ýrobců, 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řístupnění a interakci s portlety umístěnými na jiných portálech. Portál však není definován žádným standardem. 2.2.1 Portálové technologie v Javě Jiná už je situace v kontextu Javy. Přestože ani zde neexistuje standard popisující portál, portlety jsou definovány dvěma 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ěmi 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 splňující tyto standardy jsou přenosné na všechny portály, jež tyto standardy implementují. Podle portletových specifikací [1] jsou portlety aplikace dodávající část obsahu portálové stránky. Jsou používány portálem jako zásuvná uživatelská rozhraní tvořící prezentační vrstvu informačních systémů. Portlety generují tzv. fragment, což je text ve značkovacím jazyku splňující jistá pravidla. Fragment spolu s nadpisem a kontrolními tlačítky tvoří portletové okno. Seskupení těchto portletových oken různých portletů tvoří 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ěhové prostředí a stará se o jejich životní cyklus. Také ukládá perzistentní data pro portletová přednastavení. Portletový kontejner přijímá požadavky od portálu, tyto požadavky provádí na spravovaných portletech a generuje dynamický obsah. Portletový kontejner může být spojen dohromady s portálem v jednu komponentu, nebo mohou být zvlášt. Portálový server je častěji označován jen jako portál a podle JSR 168 [1] se jedná o webovou aplikaci, která slouží pro zobrazení prezentační vrstvy informačních systémů a nabízí různé možnosti, jako jsou sdružování obsahu z různých zdrojů na jednom místě, přizpů- 5

2.3. IMPLEMENTACE PORTÁLŮ Obrázek 2.2: Portálová stránka [9] sobení a jednotné přihlášení. Jedná se o nástavbu nad portletovým kontejnerem, zajišt ující nabízené vlastnosti portálu, přičemž může s portletovým kontejnerem tvořit jedinou nedílnou aplikaci. 2.3 Implementace portálů V současné době existuje mnoho výrobců portálových serverů. Jak již bylo řečeno, ty mohou být vytvořeny za použití jiných technologií a distribuovány pod různými licencemi. Mezi portály psané v technologii ASP.NET patří například Office Sharepoint Server 2010 od firmy Microsoft 3. Nejznámějším open sourcovým portálem v Java EE je Liferay Portal od Liferay 4, nejvýznamnějším portálem pod komerční licencí je WebSphere Portal od IBM 5, mezi další patří například JBoss Enterprise Portal Platform od JBoss 6, Jetspeed od Apache Software Foundation 7 či exo Platform od exo 8. Dále budou přiblíženy dva nejpoužívanější portály, a to portály Liferay a WebSphere. 3. Viz <http://sharepoint.microsoft.com/en-us/pages/default.aspx>. 4. Viz <http://www.liferay.com/>. 5. Viz <http://www-01.ibm.com/software/genservers/portal/server/index.html>. 6. Viz <http://www.jboss.com/products/platforms/portals/>. 7. Viz <http://portals.apache.org/jetspeed-2/>. 8. Viz <http://www.exoplatform.com/company/en/home>. 6

2.3. IMPLEMENTACE PORTÁLŮ 2.3.1 WebSphere Portal WebSphere Portal od IBM je dodáván ve třech komerčních verzích. První a základní verzí je WebSphere Portal Server. Ten nabízí všechny klíčové portálové služby pro sdružování obsahu a přizpůsobení, včetně podpory standardů 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řizpůsobení 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řidává navíc pokročilé nástroje pro správu obsahu (content management), správu dokumentů a pokročilé vyhledávání. Poslední, nejrobustnější verzí je WebSphere Portal Extend. Ten rozšiřuje verzi Enable o nástroje pro spolupráci uživatelů. 2.3.2 Liferay Portal Liferay Portal implementuje standard JSR 286 a nabízí další vlastnosti. Mezi ty patří efektivnější správa uživatelů pomocí třídění do organizací a komunit, zobrazování obsahu stránky podle role uživatele, kdy na stejné adrese najdou různí uživatelé rozdílný obsah podle rolí, umístění ve skupinách nebo vlastním nastavení, přesouvá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řipravenými portlety umožňujícími správu obsahu, spolupráci nebo sociální sítě [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ětší zabezpečení, co největší stabilitu a podporu strany Liferay. Liferay Portal potřebuje ke svému běhu aplikační server. Podporuje a je možné jej stáhnout s mnoha aplikačními servery, mezi nimiž jsou například Apache Tomcat, GlassFish, Oracle Application Server č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čilé technologie a vývojové nástroje (framework). Ty poskytují knihovny univerzálně použitelného kódu, návrhové vzory nebo rovnou fungující kostry aplikací a standardy pro přenositelnost programů. Díky tomu není nutné psát aplikace vždy od základů, ale použít již napsané části kódu a vystavět na nich vlastní, konkrétní řešení. Kód je pak přehlednější a jednodušší při 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 splňující Java standardy, mezi něž patří například Spring Framework [10]. 3.1 Vývojové nástroje Ve vícevrstvých aplikacích lze na nejobecnější úrovni rozlišit tři logické vrstvy [16]. Nejnižší vrstvou je datová vrstva, ta slouží k manipulaci dat nad perzistentním úložištěm. Úkolem datové vrstvy je zařídit bezchybný přenos dat mezi databází a aplikací. K tomu jsou v kontextu objektově orientovaného programování používány nástroje pro objektově-relační mapování (Object Relational Mapping, ORM). V Javě jsou těmito nástroji například Java Persistence API [5] či Hibernate. Prostřední vrstvou enterprise aplikací je aplikační vrstva. Ta od nejnižší vrstvy získává data a prezentační vrstvě zprostředkovává aplikační logiku. Zajišt uje vlastní funkcionalitu aplikace. Pro tvorbu aplikační logiky slouží například Enterprise JavaBeans, jako součást Java EE [3], nebo kořenový kontejner ve Spring Framework [10]. Horní vrstva se nazývá prezentační vrstva. Ta realizuje uživatelské rozhraní aplikace. Určuje, co uživatel vidí, a vyvolává funkcionalitu aplikační vrstvy. V závislosti na druhu aplikace má prezentační vrstva formu klasického grafického uživatelského rozhraní, webové aplikace či uživatelského rozhraní pro mobilní zařízení. 3.1.1 Java Persistence API Java Persistence API (JPA) je součástí Java EE [3] a ve verzi 2.0 je definována standardem JSR 317 [5]. JPA slouží ke správě perzistentních dat a objektově-relačnímu mapování v aplikacích na platformě Java. Své funkcionality a elegance dosahuje použitím anotací, případně 8

3.1. VÝVOJOVÉ NÁSTROJE metadat ve formě XML souboru [5]. JPA dovoluje zaobalit datový zdroj tak, že spojení na něj je provedeno v konfigurační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čejné javové třídy splňující určitá kritéria. Slouží jako vzor pro objektově-relační mapování. Atributy entitních tříd určují schéma tabulky, přičemž zapsané instance entit tvoří řádky tabulky a jejich jednotlivé atributy jsou mapovány na atributy tabulky relační databáze a naopak. Entity umožňují i jednoduché mapování relací pomocí anotovaných atributů, napří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řída EntityManager. EntityManager definuje metody pro vytváření, editování, mazání či vyhledávání entit. Dovoluje také provádět nad uloženými entitami dotazy ve formě Java Persistence Query Language (jazyk pro dotazování). Ten má pro jednoduchost syntax podobnou jazyku SQL. Výrazy tohoto jazyka jsou dále překládány do dialektu jazyka SQL právě používané databáze, což podporuje nezávislost na konkrétním technickém řešení datového úložiště 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ě. Není součástí Java EE, je její alternativou. Spring je modulární, umožňuje použití jen těch částí, které jsou potřeba, přičemž je možné používat jednotlivé moduly v kombinaci s jinými Java technologiemi. Zároveň 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Ů Mezi těmito moduly jsou nástroje pro tvorbu datové vrstvy (Data Access/Integration), aplikační vrstvu zabezpečuje především kořenový kontejner (Core Container), pro prezentační vrstvu webových aplikací je tu Web MVC. Dále Spring nabízí i nástroje pro testování či aspektově orientované programování (AOP). Beans Objekty, jež spravuje springový aplikační kontejner, se nazývají beans. Tyto objekty musí být popsány metadaty, podle nichž kontejner zjistí, jak je vytvořit a jak s nimi zacházet [10]. Spring umožňuje vedle konfigurace v XML souborech také použití anotací. Ty se uvádí přímo ve zdrojovém kódu a jejich použití je tedy pohodlnější, za cenu chybějících centralizovaných, přehledných konfiguračních souborů. Injektování závislostí Spring specifikace [10] definuje injektování závislostí (Dependency Injection) jako proces, při kterém objekty definují své závislosti, tedy jiné objekty, se kterými pracují, jen za použití argumentů konstruktoru, argumentů továrních metod (factory method, metody používané pro tvorbu instancí tříd), nebo vlastností nastavitelných po vytvoření instance objektu či jeho navrácení z tovární metody. Aplikační kontejner injektuje dané závislosti teprve přitom, kdy daný objekty potřebuje. Tento postup je opačný vzhledem k tomu, kdy objekty sami obstarávají své závislosti, proto se tento princip označuje i jako obrácení kontroly (Inversion of Control, IoC). 3.2 Tvorba portletů Prezentační vrstva webových aplikací je často založena na architektuře MVC (model-viewcontroller). Ta logicky rozděluje komponenty prezentační vrstvy podle funkcionality na [13] model, zobrazení (view) a zpracovatel (controller). Model představuje data a aplikační logiku přístupnou prezentační vrstvě, je reprezentován rozhraním aplikační vrstvy webové aplikace. Zobrazení vykresluje výstup v závislosti na modelu, je tvořen nějakou vhodnou technologií, nejčastěji JSP (JavaServer Pages, viz [6]). Zpracovatel řadí požadavky, převádí je na akce prováděné na modelu a následně vyvolává zobrazení. Úlohu zpracovatele vykonávají nejčastěji servlety, v případě 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 usnadňuje Spring Portlet MVC Framework, součást Spring Framework. 3.2.1 Portlety podle JSR 168 Portlety jsou velice podobné servletům. Servlety jsou webové komponenty spravované kontejnerem, generující dynamický obsah, jsou základním nástrojem pro tvorbu webových aplikací v Javě, patří do Java EE a popisuje je vlastní specifikace, Java Servlet Specification [4]. Jejich běhovým prostředím je servletový kontejner, přes nějž komunikují s webovými klienty 10

3.2. TVORBA PORTLETŮ pomocí vzoru požadavek/odpověd (request/response) [4]. S portlety komunikuje webový klient pomocí požadavků a odpovědí směřovaných přes portál. Akce provedené na jednom portletu portál přijímá a přeposílá portletům, jimž byly směřovány [1]. Portlety se od servletů liší v některých důležitých vlastnostech. Na rozdíl od servletů vytvářejí jen fragmenty stránek, nejsou přímo určeny nějakým URL (Uniform Resource Locator), mají předdefinované 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žadavků Dalším důležitým rozdílem oproti servletům je způsob zpracování požadavků. Portlety mohou reagovat na dva druhy požadavků, požadavek na provedení akce a požadavek na vykreslení. Ty jsou reakcemi na dotazy formou actionurl č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ři každém vykreslení na portálovou stránku. Pokud tedy klient odešle požadavek na akci pro nějaký 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 může nacházet v různých módech. Těmi se rozumí funkce, kterou portlet zrovna vykonává. Změnit mód lze pomocí záhlaví portletu, případně programově při zpracování požadavku na provedení akce. JSR 168 [1] definuje tři módy, těmi 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 různá 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ároveň mohou různí výrobci portálů podporovat vlastní módy, ale portlety, které tyto módy implementují ztrácí přenositelnost na ostatní portály, které tyto módy nepodporují. Stavy okna Portlet může definovat také stav okna. Okno portletu se podle JSR 168 [1] může nacházet ve stavu NORMAL, kdy portlet limituje svoji velikost a může se na stránce vyskytovat s jinými portlety. Stav MAXIMIZED značí, že portlet je bud jediným, nebo ústředním portletem na stránce a může tedy generovat rozsáhlejší obsah. Ve stavu MINIMIZED by portlet naopak neměl generovat obsah žádný, nebo jen minimum. Obdobně jako při portletovém módu mohou různé portály nabízet vlastní stavy okna za cenu menší přenositelnosti portletů, jež je definují. 11

3.2. TVORBA PORTLETŮ 3.2.2 Portlety podle JSR 286 Druhá portletová specifikace téměř kompletně přebírá specifikaci první a přidává zejména nástroje pro meziportletovou komunikaci a poskytování zdrojů [8]. Komunikace mezi portlety podle JSR 286 může probíhat bud prostřednictvím událostí, nebo pomocí veřejných render parametrů. Portlety také nově mohou implementovat rozhraní ResourceServingPortlet a přes metodu serveresource poskytovat uživatelům zdroje například ve formě binárních dat [2]. Veřejné render parametry jsou jednodušší formou meziportletové komunikace, musí být definovány v deskriptoru portlet.xml a lze je použít pouze pro řetězcové hodnoty [2]. Události mohou portlety jak vysílat, tak přijímat, dále je může vysílat i samotný portál. Zpracování událostí probíhá před zpracováním render metod. Oproti veřejným render parametrům mají události tu výhodu, že lze jejich pomocí přenášet libovolné objekty [2]. U každého portletu je nutné nastavit v portlet.xml deskriptoru, jaké události přijímá a jaké vysílá. 3.2.3 Spring Portlet MVC Framework Spring [10] přímo nabízí MVC rámec pro tvorbu portletů. Ten je vystaven okolo portletu zvaného DispatcherPortlet, který se stará o rozdělování požadavků mezi jednotlivé zpracovatele. Jako zpracovatelé slouží třídy označené anotací @Controller. K vykreslení odpovědí 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Ů Třídy označené jako zpracovatelé dále musí obsahovat metody na vyřizování požadavků. Tyto metody mají ve Springu libovolné jméno, stačí, že jsou označeny anotací @ActionMapping pro zpracování požadavku na akci, nebo @RenderMapping pro zpracování požadavku na vykreslení. Těchto metod, stejně jako zpracovatelů, může být v portletu více. Pro jejich rozlišení lze do anotací přidat atribut params, jenž určuje jména a hodnoty parametrů. Při požadavku s parametry je pak podle nich určen odpovídající zpracovatel a jeho metoda. 3.2.4 JavaServer Pages JavaServer Pages (JSP) je technologie, patří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ři nasazení přeložena na servlet. Zatímco servlet je třída, JSP stránka je textový dokument popisující podobu odpovědi [4]. Proto se JSP zpravidla používá pro tvorbu zobrazení (view) v MVC architektuře. V JSP stránce lze dynamický obsah tvořit pomocí skripletů. To je kód v jazyku Java ohraničený speciálními symboly. Při překladu stránky na servlet dojde pouze k odstranění uvozujících symbolů a kód je ponechán k vykonání [4]. Při použití skripletů jsou však stránky nepřehledné, komplikované a kód je špatně udržovatelný. Proto je doporučová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ředchází znak pro dolar [4]. V EL výrazech je možné přistupovat k hodnotám objektů podobně, jako v případě skripletů. JSTL dovolují generovat dynamický obsah v závislosti na hodnotách EL výrazů, přičemž není potřeba psát kód v programovacím jazyku a stránky tím nabývají na přehlednosti. 13

Kapitola 4 Požadavky na objednávkový systém Bakalářská 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 průmyslové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ářské práce je rozšířit internetový obchod o objednávkový systém. V této kapitole bude popsáno stávající řešení internetového obchodu, následně bude provedeno srovnání existujících objednávkových systémů a jako výsledek bude vytvořen seznam funkčních a nefunkčních požadavků na tvořený objednávkový systém. 4.1 Popis stávajícího řešení Stávající internetový obchod se skládá ze dvou hlavních částí. První z nich je webová aplikace určená pro nasazení na portálu Liferay. Tuto aplikaci tvoří několik portletů a z hlediska architektury se jedná o prezentační vrstvu systému. Druhou část, tedy aplikační a datovou vrstvu, tvoří dva modulární systémy. Prvním je rozhraní internetového obchodu, které tvoří rozhraní mezi možnými implementacemi aplikační logiky a mezi možnými implementacemi uživatelských rozhraní. Druhým je samotná implementace aplikační logiky internetového shopu splňující požadavky rozhraní. Rozhraní internetového obchodu se skládá z několika modulů, z nichž každý odpovídá za nějakou funkcionalitu obchodu. Těmito moduly jsou Integration API, což je modul sdružující třídy a metody, které jsou společné ve více modulech a z důvodu přehlednosti jsou umístěny zde a zevšeobecněny tak, aby je třídy ostatních modulů mohly využívat. Dalšími moduly jsou User API, modul určující práci s uživateli, Configuration API, modul sloužící jako rozhraní pro správu konfigurace, Catalog API, rozhraní páteřní funkcionality internetového obchodu nabízející správu produktů 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 modulů, které odpovídají jednotlivým modulům rozhraní, jednotlivé třídy rozšiřují nebo implementují třídy rozhraní. V případě potřeby je možné vyměnit implementující moduly za jiné, či vyměnit celou implementaci internetového obchodu, aniž by muselo dojít ke změně v prezentační vrstvě aplikace. 14

4.2 Srovnání objednávkových systémů 4.2. SROVNÁNÍ OBJEDNÁVKOVÝCH SYSTÉMŮ Existuje mnoho rozdílných objednávkových systémů internetových obchodů lišících se na různých úrovních. Některé internetové obchody vyžadují registraci zákazníka a jiné ne, některé rozprostírají objednávání do mnoha kroků, jiné třeba jen do jednoho. V této podkapitole budou nastíněny rozdílné přístupy k objednávkovým systémům, ty budou ukázány na příkladech reálných internetových obchodů, a následně 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říklad známý internetový obchod Amazon 1 při procesu objednávání u neregistrovaného zákazníka vyžaduje po uživateli registraci. Ta sestává ze dvou kroků, přičemž následují další čtyři obrazovky předtím, než je možnost vytvořit objednávku. V případě, že zákazník nenakupuje zboží v obchodě pravidelně, ale jedná se o jednorázovou objednávku, je tento proces pro zákazníka nadbytečný, a navíc relativně náročný. Naopak v případě, že zákazník nakupuje v takovém obchodě pravidelně, ocení, že systém předvyplní veškeré známé údaje. Zákazníkovi pak stačí k objednání jen několik kliknutí. U některých internetových obchodů je pro objednání zboží registrace volitelná. Takovým obchodem je například Alza 2. Objednání v něm zabere tři kroky, přičemž ve druhém je nepřihlášenému uživateli nabídnut výběr mezi pokračováním bez registrace, novou registrací, nebo přihlášením pro nepřihlášeného registrovaného zákazníka. Zvolení první možnosti nabídne formulář pro zadání údajů nutných pro odeslání objednávky a neobtěžuje zákazníka nutností registrace. Náročnost objednávání Ukázalo se, že problematika náročnosti objednávání velice souvisí s nutností registrace. Jak bylo ukázáno, objednání zboží na Amazon může trvat až šest kroků, pro přihlášeného zákazníka naopak nabízí možnost objednání jediným kliknutím. U obchodů jako Itek 3 nebo Alza zabere objednání tři kroky, kde prvním krokem je zvolení způsobu platby a dopravy, druhým je zadání adres a třetím krokem je potvrzení zadaných údajů a závazné objednání. Opačným extrémem je například Fantasya 4, kde i pro nepřihlášeného uživatele znamená objednání zboží jedinou obrazovku, přičemž po zadání způsobu platby a dodání lze rozbalit objednávkový formulář i s tlačítkem pro závazné objednání. Takové objednání je velice pohodlné, ale nedává uživateli šanci zkontrolovat správnost zadaných údajů, zároveň uživatel nemusí očekávat závazné objednání již při prvním kroku a může dojít k nechtěnému objednání. 1. Viz <http://www.amazon.com/>. 2. Viz <http://www.alza.cz/>. 3. Viz <http://www.itek.cz/>. 4. Viz <http://www.fantasya.cz/>. 15

4.3. POŽADAVKY NA OBJEDNÁVKOVÝ SYSTÉM Přehlednost objednávání Důležitým prvkem stránek obecně je přehlednost. U internetových obchodů nabývá na důležitosti tím, že nepřehledné stránky mohou v potenciálním zákazníkovi navozovat pocit nedůvěryhodnosti, a tím jej odradit od nákupu v konkrétním obchodě. Příkladem nepřehledného objednávkového systému je například Czechcomputer 5, kde formulář pro objednání leží pouze uprostřed stránky, obklopen výběrem kategorií s nabídkou produktů, ale především z druhé strany reklamou na jiné produkty obchodu. Zároveň pokud nepřihlášený uživatel klikne na tlačítko koupit, místo závazného objednání je vyzván k přihlášení nebo registraci, což může být pro uživatele neočekávané a odrazující chování. 4.3 Požadavky na objednávkový systém Přestože nelze určit, jaké řešení objednávkového systému je nejlepší, srovnáním existujících systémů a ze zadání práce lze určit požadavky na objednávkový systém, jenž bude možné integrovat do stávajícího internetového obchodu. Funkční požadavky Objednávkový systém (ObjS) přijímá seznam požadovaného zboží. Zákazník se může v prvním kroku ObjS přihlásit. ObjS nabídne zákazníkovi formulář pro zadání fakturačních a dodacích údajů. Následně ObjS zkontroluje, že zákazník správně zadal všechny potřebné údaje. Pokud údaje nejsou validně zadané, ObjS musí formulář předložit znovu s předvyplněnými údaji, špatně zadané položky musí být vyznačeny. Pokud jsou údaje zadány správně, ObjS nabídne zákazníkovi stránku pro kontrolu kupovaného seznamu zboží a zadaných údajů. Ve druhém kroku ObjS již nelze údaje měnit. ObjS nabídne ve druhém kroku přihlášenému uživateli možnost platby kartou. ObjS musí nabídnout klikatelné odkazy na úpravu seznamu kupovaného zboží a zadaných údajů. 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ředchozí kroky objednávky. Pro přihlášené uživatele ObjS předem vyplňuje známé údaje. Nefunkční požadavky ObjS je psán jako rozšíření existujícího webového shopu. ObjS je psán v třívrstvé architektuře, lze logicky rozlišit datovou, aplikační a prezentační vrstvu. ObjS bude psán objektověorientovaným způsobem v jazyku Java. Prezentační vrstva ObjS je vytvořena za použití Spring Portlet MVC Framewok. Aplikační logika ObjS implementuje modul Ordering API. Aplikační 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řehledný. ObjS mohou používat přihlášení i nepřihlášení uživatelé. Uživatel 5. Viz <http://www.czechcomputer.cz/>. 16

4.3. POŽADAVKY NA OBJEDNÁVKOVÝ SYSTÉM musí vždy vědět, co se od něj očekává a kam má pokračovat. Uživatel musí přesně vědět, co vyvolá každé tlačítko za následek. Po potvrzení objednávky ObjS objednávku uloží do systému a přidělí jí stav. ObjS používá modul User API internetového obchodu pro správu uživatelů. ObjS vhodně 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řípady užití Analýza funkčních požadavků je provedena v diagramu případů užití, jenž je zobrazen na obrázku 5.1. Následuje popis účastníků objednávkového systému a charakteristika jednotlivých případů užití. Ze stylistických důvodů jsou pak formální specifikace jednotlivých případů užití součástí přílohy A. Obrázek 5.1: Diagram případů užití 18

5.1. PŘÍPADY UŽITÍ Popis účastníků systému Objednávkový systém bude schopný pracovat s třemi typy účastníků, přihlášenými a nepřihlášenými uživateli a administrátory. Po nepřihlášeném uživateli nebude požadovat registraci ani přihlášení. Přihlásit se lze nejpozději při zadávání fakturačních a dodacích údajů. Výhodou přihlášení pak je předvyplnění známých údajů o uživateli ve formulářích. Administrátor provádí správu objednávkového systému. Zadání fakturačních a dodacích údajů Tento případ užití začíná v okamžiku, kdy uživatel přejde do objednávkového systému. Uživateli bude nabídnut formulář pro zadání fakturačních údajů. Pro přihlášeného uživatele bude formulář předvyplněný známými údaji. Pokud se nepřihlášený uživatel v tomto bodě přihlásí, budou údaje automaticky předvyplněny. Pokud uživatel zadá údaje ve špatném tvaru, bude mu formulář nabídnut opakovaně, zadané údaje zůstanou vyplněné, špatně zadané údaje budou vyznačeny s popisem chyby. V případě, že uživatel požaduje doručit údaje na jinou, než fakturační adresu, je mu nabídnut formulář pro zadání dodacích údajů. Formulář bude splňovat vlastnosti formuláře pro zadání fakturačních údajů. Potvrzení objednávky Případ užití začíná v okamžiku, kdy uživatel správně zadal požadované fakturační a dodací údaje. Uživateli bude poskytnut výpis nakupovaného zboží a zadaných údajů, bude mu umožněno navrácení do košíku pro úpravu nakupovaného zboží a navrácení do formulářů pro změnu zadaných údajů. Uživateli bude nabídnut výběr pro způsob platby a doručení objednávky. Pokud uživatel zvolí způsob platby a doručení objednávky a nenavrátí se kvůli změně objednávky nebo fakturačních či doručovacích údajů, je mu umožněno potvrzení objednávky. To způsobí zapsání objednávky do systému, změnu stavu objednávky a potvrzení přijetí objednávky uživateli. Zrušení objednávky Tento případ užití začíná, pokud přihlášený uživatel požaduje zrušení již potvrzené objednávky. Uživateli je nabídnut formulář pro identifikaci objednávky pomocí unikátního čísla a dojde k vyhledání objednávky. Uživatel potvrdí zrušení objednávky, informace je předána správci internetového obchodu a řízení je předáno externímu nástroji podle vnitřní politiky obchodu. Platba kartou Tento případ užití je umožněn pouze přihlášenému uživateli. Začíná po odeslání validních fakturačních údajů. Přihláš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ři zvolení této možnosti je uživatel přesměrován podle politik obchodu do systému pro platbu kartu. Správa objednávek Případ užití pří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ář pro zadání parametrů hledání. Vyhledávat bude možné dle identifikačních údajů registrovaných uživatelů, identifikačního čísla objednávky, data provedení objednávky či stavu objednávky. 5.2 Návrh objednávkového systému Objednávkový systém bude mít třívrstvou architekturu. Prezentační vrstva je realizována jako portletová aplikace, aplikační vrstvu tvoří služby dostupné vrstvě prezentační a datová vrstva zaobaluje práci nad datovým úložištěm. Mezi prezentační a aplikační vrstvou stojí modul Ordering API, jenž vznikl ve firmě IBA CZ, s.r.o., ten má funkci rozhraní mezi prezentační a aplikační vrstvou objednávkového systému. K tomu využívá dvou prostředků. Prvním je samotný interface (třída rozhraní v Javě) OrderingService. Druhým prostředkem jsou DTO (Data Transfer Object). To jsou objekty sloužící k předávání dat mezi částmi aplikace [12], v tomto případě mezi aplikační a prezentační vrstvou systému. 5.2.1 Komponenty objednávkového systému Komponenty objednávkového systému bude možné logicky oddělit podle vzoru třívrstvé architektury. Diagram komponent na obrázku 5.2 zobrazuje tyto komponenty a vztahy mezi nimi a jejich okolím. Datová vrstva bude tvořena 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ě ji zprostředkovávají aplikační vrstvě [11], přičemž pracují s daty ve formě entit. Podle pravidel třívrstvé architektury musí být komponenty datové vrstvy nezávislé na komponentách vrstvy aplikační. Aplikační vrstvu bude reprezentovat služba implementující rozhraní OrderingService. Ta ke své činnosti potřebuje komponentu sloužící ke konverzi dat mezi třídami modelu, k nimž přistupuje prostřednictvím DAO, a DTO z rozhraní. Komponenty datové i aplikační vrstvy využívají služeb modulů Integration API a Integration Implementation, což vyplývá z nefunkčních požadavků na systém, integrace do internetového obchodu a dodržování projektových konvencí. Zároveň musí být komponenty aplikační vrstvy nezávislé na vrstvě prezentační, což plyne z pravidel třívrstvé architektury. Prezentační vrstva objednávkového systému bude tvořena jako portletová aplikace. Prezentační vrstva využívá služby aplikační logiky pomocí rozhraní OrderingService. Zároveň nepoužívá žádné komponenty tří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ě v případě změny této komponenty nebudou díky rozhraní potřebné v objednávkovém systému žádné změny. 5.2.2 Třídy objednávkového systému Každá komponenta objednávkového systému se bude skládat z více tříd. Diagram tříd na obrázku 5.3 zobrazuje návrh tříd objednávkového systému a vzájemné vazby mezi nimi. Zároveň logicky uspořádává třídy do příslušných komponent a vzájemně je odděluje podle pravidel třívrstvé architektury. Kompletní návrhový diagram tříd je součástí přílohy B. Model bude tvořen entitami a DAO. Diagram tříd zobrazuje entity objednávkového systému a vztahy mezi nimi. Objednávka (OrderEntity) obsahuje kolekci položek objednávky (OrderItemEntity), zároveň má určen způsob platby (PaymentMethodEntity) a svůj stav (OrderStatusEntity). Způsob platby a stav objednávky budou mít vlastní tabulku v datovém zdroji, aby bylo možno libovolně měnit doménu jejich hodnot bez programových změn. V datovém zdroji bude ukládána také správa změn stavů (OrderStatusLogEntity), jež slouží 21

5.2. NÁVRH OBJEDNÁVKOVÉHO SYSTÉMU pro ukládání změn stavů pro každou objednávku a času těchto změn. K manipulaci entit nad datovým zdrojem budou sloužit obdobně pojmenované DAO. Ty tvoří rozhraní, pomocí nějž přistupují třídy aplikační vrstvy k datovému zdroji. Entity a DAO tvoří datovou vrstvu a jako takové nesmí být závislé na třídách vrstvy aplikační. Aplikační vrstvu bude tvořit třída OrderingServiceImpl. Ta realizuje služby aplikační logiky. Prezentační vrstva bude komunikovat s aplikační logikou pomocí dat ve formě DTO, je tedy třeba vytvořit pomocné třídy, jež budou používány třídou OrderingServiceImpl a budou konvertovat data mezi DTO a entitami vrstvy datové. Aplikační vrstva bude dále používat třídy DAO, pomocí nichž přistupuje k datovému zdroji. Prezentační vrstva bude mít MVC architekturu. Portlety slouží pro zpracování požadavků a předávání odpovědí, zobrazení bude realizováno pomocí vhodného prezentačního nástroje a model prezentační vrstvy je tvořen rozhraním aplikační logiky. Zpracovateli prezentační 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říd 23

Kapitola 6 Implementace objednávkového systému Při vývoji prototypu objednávkového systému byl dodržen návrh systému a vývoj je tedy rozdělen do tří částí podle logických vrstev aplikace. Těmi jsou vrstvy datová, aplikační a prezentační. Z hlediska formálního uspořádání jsou třídy datové a aplikační vrstvy součástí modulu Ordering Implementation, zatímco portlety jsou součástí webové aplikace internetového obchodu. 6.1 Vývoj datové vrstvy Zatímco perzistentním úložištěm je relační databáze, Java pracuje s objekty. Pro přenos dat mezi relační databází a objekty je použit nástroj pro objektově-relační mapování nad datovým zdrojem, Java Persistence API (JPA). Základními prvky JPA jsou entity a Entity- Manager. Entity slouží jako forma pro objektově-relační 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řídy OrderDAO, OrderItemDAO, OrderStatusDAO, OrderStatusLogDAO a PaymentMethodDAO. Ty zaobalují funkcionalitu EntityManageru a aplikační vrstvě nabízí potřebné metody pro správu dat nad datovým zdrojem. Datová vrstva s výhodou využívá generické programování, jež umožňuje abstrakci kódu tak, aby byl co nejméně závislý na objektových typech. DAO třídy rozšiřují třídu Generic- DAO, jež zaobaluje EntityManager a dokáže základní operace nad perzistentním úložištěm entit BaseEntity. Entity objednávkového systému proto rozšiřují BaseEntity, díky čemuž DAO získávají tuto jednoduchou funkcionalitu a šetří tím opakované vytváření základního kódu. Konfigurace entit je v případě objednávkového systému prováděna pomocí anotací, OrderEntity vypadá následovně: @Entity @Table(name = "WEBSHOP_ORDER") public class OrderItem extends BaseEntity<Long> { @Id @GeneratedValue(strategy = GenerationType.AUTO) private Long id; @ManyToOne 24

6.2. VÝVOJ APLIKAČNÍ VRSTVY } private PaymentMethodEntity paymentmethod; @OneToMany private List<OrderItemEntity> items;... Anotace @Entity označuje JPA entitu, řádek s anotací @Table přiřazuje tabulce v datovém zdroji explicitní název. Pomocí @GeneratedValue je entitě při vložení do úložiště automaticky vygenerováno unikátní identifikační číslo, anotace @OneToMany označuje vztah mezi entitami OrderItemEntity a OrderEntity, přičemž říká, že OrderEntity může být ve vztahu s více OrderItemEntity, ale ne naopak. Ucelenější ukázka třídy OrderEntity je zobrazena v příloze C. 6.2 Vývoj aplikační vrstvy Jádrem aplikační vrstvy je třída implementující rozhraní OrderingService. Ta se podle jmenných konvencí internetového obchodu jmenuje OrderingServiceImpl. Tato třída implementuje aplikační logiku přístupnou prezentační vrstvě. Zaobaluje proto veškerou funkcionalitu vrstvy aplikační i datové. OrderingServiceImpl využívá služeb tříd DAO k přístupu k datovému zdroji. Sama pak nad těmito daty provádí metody, jež jsou potřebné v prezentační vrstvě, jako je ukládání objednávek, získávání objednávek podle určených kritérií, manipulace stavů objednávek či získávání informací o změnách těchto stavů. Prezentační vrstva je přitom díky injektování závislostí, jež umožňuje Spring Framework, na této třídě programově nezávislá. V prezentační vrstvě je pouze deklarován požadavek na získání Ordering- Service, dodání implementace této třídy je pak již plně v řízení IoC kontejneru: @Service public class OrderingServiceImpl implements OrderingService { } @Autowired private OrderingService orderingservice;... Na příkladu je vidět požadavek na dodání bean implementující OrderingService. Anotace @Autowired značí, že má Spring kontejner automaticky přiřadit odpovídající bean, pokud takový najde. Dalším krokem je označení 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říklad @Service. Pokud je bean označen anotací, je třeba springovému kontejneru nastavit automatické vyhledávání tříd v konfiguračním XML souboru a dále nastavit cestu k těmto třídám. Spring IoC kontejner pak automaticky vyhledá bean OrderingServiceImpl a vloží jej prezentační vrstvě pod proměnnou orderingservice. V objednávkovém systému je použito automatické vyhledávání tříd, jež je nastaveno v konfiguračním XML souboru cestou k balíku, jenž má Spring prohledávat. 25

6.3. VÝVOJ PREZENTAČNÍ VRSTVY OrderingService, a tedy i OrderingServiceImpl, vyměňuje data s prezentační vrstvou ve formě DTO, s datovou vrstvou zase ve formě entit. Je proto třeba v aplikační vrstvě data konvertovat mezi těmito dvěma typy. K tomu je použito generické rozhraní Converter, jež je součástí Spring Framework. Pro konverzi jsou vytvořeny vlastní třídy implementující toto rozhraní. Výhoda použití rozhraní Converter se projevuje díky IoC kontejneru. Místo vytváření nové instance třídy pokaždé, když je třeba konvertovat entitu na DTO, je možné použít Springovou třídu ConversionService: @Autowired private ConversionService conversionservice; OrderEntity orderentity;... Order order = conversionservice.convert(orderentity, order.class); Seznam použitelných konvertorů je nastaven v konfiguračním XML souboru, díky čemuž Spring automaticky vyhledá správný konvertor, tedy třídu implementující rozhraní Converter, podle vstupních argumentů metody convert. Na příkladu je vidět metoda pro konverzi dat z OrderEntity do instance třídy Order. Instance třídy OrderEntity je konvertoru předána jako první argument, druhý argument slouží právě pro určení cílové třídy pro konverzi, v tomto příkladě je to třída Order. V příloze C jsou pak ukázány třídy pro konverzi dat mezi OrderItem a OrderItemEntity, přičemž je dbáno na ochranu práv společnosti IBA CZ, s.r.o. a projektově specifický kód je odstraněn. 6.3 Vývoj prezentační vrstvy Prezentační vrstva objednávkového systému splňuje MVC architekturu. Modelem je rozhraní aplikační logiky, zobrazení (view) realizují stránky JSP. Roli zpracovatelů (controller) obstarávají dva portlety. Jedním je portlet pro objednávání, pomocí nějž zákazníci provádí objednávky. Druhým je portlet sloužící pro správu objednávek administrátory. Portlety jsou tvořeny za použití Spring Portlet MVC Framework. Portlet je tvořen jedním zpracovatelem označeným anotací @Controller. Ten realizuje tři kroky objednávkového systému. Při vstupu do objednávání je zpracovateli poslán jako parametr odkaz na seznam kupovaných produktů do databáze. Výsledkem úspěšného objednání je zápis instance třídy Order do aplikační logiky. Ke zdrojům aplikační logiky přistupuje portlet formou injektování závislostí. Po nastavení cesty automatického prohledávání v konfiguračním XML souboru vyhledá Spring IoC kontejner na nastavené cestě vhodné komponenty a doplní je jako beany do proměnných označených anotací @Autowired. Jednotlivé kroky objednávání jsou realizovány pomocí anotovaných metod. Požadavek na akci zpracovávají třídy označené @ActionMapping, požadavek na vykreslení třídy s anotací @RenderMapping. Mezi těmito metodami se rozlišuje pomocí atributu params těchto anotací. Instance objednávky je mezi jednotlivými kroky ukládána v portletových relační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ě přecházet, 26

6.3. VÝVOJ PREZENTAČNÍ VRSTVY aniž by došlo ke ztrátě dat objednávky. Na následující ukázce je zobrazena manipulace s instancí objednávky při reakci portletu na požadavek na akci a v metodě pro vykreslení druhého kroku objednávání. V metodě pro zpracování požadavku na akci je instance objednávky uložena v atributu relace, v metodě pro vykonání požadavku na vykreslení je pak tato instance získána a vhodněji předána JSP stránce, v tomto případě 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ář pro zadání fakturačních a dodacích údajů je tvořen pomocí knihovny značek Form technologie Spring. Objednávka je předána JSP stránce jako atribut instance třídy Model, stránka následně pomocí knihovny značek Form vytváří formulář. Formulář čte a zapisuje přímo do potřebných atributů objednávky podle nastavení cesty v elementech knihovny Form. Validace zadaných dat podle určených kritérií je prováděna v portletu pomocí rozhraní Validator technologie Spring, jak je zobrazeno v příloze C. Ta ilustruje inicializaci a zpracování formuláře pro zadání fakturačních a dodacích údajů s ohledem na ochranu práv společnosti IBA CZ, s.r.o. Na následujícím příkladu je vidět internacionalizovaná část formuláře pro zadání jména zákazníka, jež dokáže předem vyplnit známé údaje a umožňuje validaci zadaných dat: <form:form id="${ns}orderform" action="${actionthreeurl}" method="post" commandname="<%=attribute_order%>" cssclass="order-form"> <form:hidden path="id"/> <p> <form:label path="invoiceaddress.customername"> <spring:message code="label-customername"/> </form:label> 27

6.4. TESTOVÁNÍ <form:input path="invoiceaddress.customername"/> <form:errors path="invoiceaddress.customername" element="span" cssclass="portlet-msg-error"/> </p>... </form:form> Výsledný formulář je zobrazen na obrázku 6.1. Styl portletu se přizpůsobuje vzhledovému nastavení portálu Liferay, a tím dodržuje jednotný vzhled celého portálu. Zároveň se při změně nastavení podoby portálu mění i vzhled portletové aplikace. Ukázkové obrazovky objednávkového systému jsou součástí přílohy D. Na ukázce portletu pro administrátory je ilustrována jednoduchost změny stylu portletu při změně vzhledu portálu Liferay. Zároveň je v případě administrátora portál nastaven na anglický jazyk, portlet tedy podle dostupné lokalizace komunikuje v nastaveném jazyce. Obrázek 6.1: Formulář pro zadání fakturačních údajů 6.4 Testování Testováno je za použití nástroje JUnit, přičemž integrované testování je umožněno díky nástrojům Spring Framework. Programově je testováno především chování metod třídy OrderingServiceImpl a její injektování. Testy jsou součástí zdrojového kódu a při každém sestavování aplikace jsou na lokálním připojení k databázi testovány metody aplikační logiky. Je prováděno jednotkové testování metod aplikační logiky. Je testováno správné připojení na databázi, správný zápis objednávek do databáze i fungování tříd pro konverzi. Je kontrolováno, zda při převodu mezi datovým zdrojem, entitami a DTO nedochází ke změně 28

6.4. TESTOVÁNÍ nebo ztrátě dat v instancích těchto tří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ě dodány třídám, jež je požadují. Uživatelsky pak byla testována prezentační vrstva systému. Obrázek 6.2 zobrazuje uživatelské testování třetího kroku objednávky. V horní části obrazovky jsou klikatelné odkazy na předchozí fáze objednávky, přičemž stávající krok je barevně vyznačen. Uživateli je dovoleno pouze přesunutí do předchozích kroků objednávání a tyto odkazy jsou odlišeny jako funkční. Pomocí čtvrtého odkazu je uživateli naznačeno, že následuje již jen potvrzení objednávky ze strany obchodu. Odkazy jsou funkční a nedochází při nich ke ztrátě žádných dat. Uživateli jsou dále zobrazeny kupované produkty, včetně množství a cen. Následně jsou pro kontrolu zobrazeny doručovací údaje. Tyto údaje byly validně zadány v předešlém kroku objednávání. Uživatel dále volí způsob platby a dopravy zboží a je mu nabídnuto i standardní textové pole pro sdělení speciálních požadavků či připomínek, jež jsou následně uloženy do objednávky. Obrázek 6.2: Obrazovka třetí fáze objednávání 29

Kapitola 7 Závěr Při řešení této bakalářské 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émů různých internetových obchodů nalezeny funkční a nefunkční požadavky na vyvíjený objednávkový systém. Následně byl pomocí UML diagramů systém analyzován a navržen tak, aby splňoval třívrstvou architekturu, přičemž prezentační 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říd byl proveden v diagramech tříd. Podle návrhu byl vytvořen prototyp objednávkového systému pro použití na portálu Liferay. Vytvořený objednávkový systém je modulární a splňuje třívrstvou architekturu. Prototyp objednávkového systému byl vytvořen v jazyku Java v technologii Spring Framework, datová vrstva je postavena na technologii Java Persistence API a prezentační vrstva využívá speciální springový nástroj pro tvorbu portletů, 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žňuje objednávání zboží vybraného v internetovém obchodu. Dovoluje provádění objednávek pro přihlášené i nepřihlášené uživatele, přičemž přihlášeným uživatelům nabízí komfortnější a jednodušší interakci. Objednávky systém ukládá do databáze a administrátorům nabízí nástroje pro jejich správu. Zdrojový kód aplikace splňuje zavedené formální konvence internetového obchodu. Objednávkový systém byl vytvořen modulárně, je proto možné libovolně měnit jeho komponenty. Díky rozhraní mezi aplikační logikou a prezentační vrstvou systému je dokonce možné rozšiřovat funkce portletové aplikace bez zásahů do aplikační logiky, stejně jako je možné libovolně měnit například datový zdroj či celou aplikační logiku bez jakékoliv potřeby upravit prezentační vrstvu systému. Do budoucna se tak nabízí například rozšíření objednávkového systému pro nasazení ve složitém firemním prostředí, kde proces objednávání závisí na vnitřních politikách podniku a kde můž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]: <http:// jcp.org/aboutjava/communityprocess/final/jsr168/index.html>. 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]: <http://jcp.org/ aboutjava/communityprocess/final/jsr316/index.html>. 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]: <http://jcp.org/aboutjava/ communityprocess/final/jsr154/index.html>. 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]: <http://jcp.org/aboutjava/ communityprocess/final/jsr317/index.html>. 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]: <http://jcp.org/aboutjava/ communityprocess/final/jsr245/index.html>. 3.2 [7] Firestone, J.: Defining the Enterprise Information Portal [online], Executive Information Systems, Inc., 1999, Dostupné z URL [cit. 2011-5-11]: <http://www.dkms. com/papers/eipdef.pdf>. 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]: <http://jcp.org/aboutjava/ communityprocess/final/jsr286/index.html>. 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]: <http://www.hippoportal.org/about/ portals-portlets-pages.html>. 2.1, 2.2 [10] Hoeller, J. a kol.: Spring Framework, Reference Documentation, 3.0 [online], 2011, Dostupné z URL [cit. 2011-5-11]: <http://static.springsource.org/spring/ docs/3.0.x/spring-framework-reference/html/>. 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]: <http://java.sun.com/ blueprints/corej2eepatterns/patterns/dataaccessobject.html>. 5.2.1 31

[12] Java BluePrints, Core J2EE Patterns, Transfer Object [online], Sun Microsystems, Inc., 2001, Dostupné z URL [cit. 2011-5-11]: <http://java.sun.com/blueprints/ corej2eepatterns/patterns/transferobject.html>. 5.2 [13] Java BluePrints, Model-View-Controller [online], Sun Microsystem, Inc., 2000, Dostupné z URL [cit. 2011-5-11]: <http://java.sun.com/blueprints/patterns/ MVC-detailed.html>. 3.2 [14] Krčá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]: <http://www.oasis-open.org/committees/ download.php/3343/oasis-200304-wsrp-specification-1.0.pdf>. 2.2, 2.2 [16] Layered Application Guideliness [online], MSDN, Microsoft Corporation, Dostupné z URL [cit. 2011-5-11]: <http://msdn.microsoft.com/en-us/library/ ee658109.aspx>. 3.1 [17] Manhartsberger, F.: Síla portálů: Využití enterprise portálů [online], 2000, Dostupné z URL [cit. 2011-5-11]: <http://www.systemonline.cz/clanky/ sila-portalu-vyuziti-enterprise-portalu.htm>. 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-615-24733-5. 2.3.2 [20] WebSphere Portal, Features and benefits [online], IBM, Dostupné z URL [cit. 2011-5-11]: <http://www-01.ibm.com/software/genservers/portal/ features/>. 2.3.1 32

Příloha A Specifikace případů užití Obrázek A.1: Potvrzení objednávky Obrázek A.2: Přihlášení 33

A. SPECIFIKACE PŘÍPADŮ UŽITÍ Obrázek A.3: Zrušení objednávky Obrázek A.4: Platba kartou Obrázek A.5: Správa objednávek 34

A. SPECIFIKACE PŘÍPADŮ UŽITÍ Obrázek A.6: Zadání fakturačních a dodacích údajů 35

Příloha B Návrhový diagram tříd Obrázek B.1: Návrhový diagram tříd 36

Příloha C Ukázky zdrojového kódu objednávkového systému @Entity @Table(name = "WEBSHOP_ORDER") public class OrderEntity extends BaseEntity<Long> { @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<OrderItemEntity> items; } public String getcustomerid() { return customerid; } public void setcustomerid(string customerid) { this.customerid = customerid; }... Příklad C.0.1: OrderEntity 37

C. UKÁZKY ZDROJOVÉHO KÓDU OBJEDNÁVKOVÉHO SYSTÉMU @Component("orderItemToEntityConverter") public class OrderItemToEntityConverter implements Converter<OrderItem, OrderItemEntity> { @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říklad C.0.2: OrderItemToEntityConverter @Component("entityToOrderItemConverter") public class EntityToOrderItemConverter implements Converter<OrderItemEntity, OrderItem> {... } 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říklad C.0.3: EntityToOrderItemConverter 38

C. UKÁ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říklad C.0.4: OrderingViewController 39

Příloha D Ukázky dalších obrazovek uživatelského rozhraní Obrázek D.1: Formulář pro zadání fakturačních a dodacích údajů 40

D. UKÁ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ěrečná obrazovka objednávání 41