E-chef server a desktopový klient. Ladislav Záruba. ƒeské vysoké u ení technické v Praze Fakulta elektrotechnická Katedra po íta.

ƒeské vysoké u ení technické v Praze Fakulta elektrotechnická Katedra po íta Bakalá ská práce E-chef server a desktopový klient Ladislav Záruba Vedoucí práce: Ing. Tomá² Kadlec Studijní program: Softwarové technologie a management, Bakalá ský Obor: Softwarové inºenýrství 3. ledna 2011

iv

v Pod kování Rád bych pod koval v²em, kte í m p i tvorb mé záv re né práce podporovali. Zejména panu Ing. Tomá²i Kadlecovi za jeho pomoc p i e²ení problém s touto prací a mému kolegovi Josefu Linhovi. Také bych cht l pod kovat mým rodi m, kte í p i mn stáli nejen p i psaní této práce, ale i p i celém mém studiu na této ²kole.

vi

vii Prohlá²ení Prohla²uji, ºe jsem práci vypracoval samostatn a pouºil jsem pouze podklady uvedené v p iloºeném seznamu. Nemám závaºný d vod proti uºití tohoto ²kolního díla ve smyslu Ÿ60 Zákona. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o zm n n kterých zákon (autorský zákon). V Praze dne 3. 1. 2011.............................................................

viii

Abstract This work deals with the design and full implementation of electronic collection of recipes E-chef. Application includes server and desktop client. The result of this work is a functional application which allows users to search for recipes using labeling system and share their own recipes. The work also includes user and programmer manual. Abstrakt Práce se zabývá návrhem a úplnou implementací elektronické sbírky recept E-chef. Aplikace obsahuje serverovou a desktopovou klientskou ást. Výsledkem práce je funk ní aplikace, která uºivatel m umoº uje vyhledávat recepty pomocí systému ²títk a sdílet jejich vlastní recepty. Sou ástí práce je i uºivatelská a programátorská p íru ka. ix

x

Obsah 1 Úvod 1 1.1 Up esn ní zadání projektu............................. 1 1.2 Poºadavky...................................... 1 1.2.1 Nefunk ní poºadavky............................ 1 1.2.1.1 Obecné poºadavky........................ 2 1.2.1.2 Server............................... 2 1.2.1.3 Desktopový klient........................ 2 1.2.2 Funk ní poºadavky............................. 2 2 Analýza 5 2.1 Výb r technologií.................................. 5 2.1.1 Aplika ní server............................... 5 2.1.2 Databáze.................................. 5 2.1.3 Sí ová komunikace............................. 6 2.1.4 Vzdálené volání metod........................... 6 2.1.5 Technologie klientské aplikace....................... 7 2.2 Role......................................... 7 2.2.1 Náv²t vník (nep ihlá²ený uºivatel).................... 8 2.2.2 P ihlá²ený uºivatel............................. 9 2.2.3 Administrátor................................ 10 2.3 P ihla²ování uºivatel............................... 10 2.4 Recept........................................ 10 2.5 Vyhledávání recept................................ 11 2.6 Administrace ²títk................................. 12 2.7 Práce s databází.................................. 12 2.7.1 Nastavení p ipojení k databázi...................... 12 2.7.2 Soub ºná editace.............................. 13 2.7.3 Opoºd né na ítání dat........................... 13 2.7.3.1 Inicializace kolekcí........................ 14 3 Návrh 15 3.1 Nasazení aplikace.................................. 15 3.2 Schéma databáze.................................. 17 3.3 Objekty pro p ístup k databázi.......................... 19 3.4 Klientské rozhraní serveru............................. 19 xi

xii OBSAH 3.5 Rozhraní Pickable................................. 21 3.6 Architektura klientské aplikace.......................... 21 4 Implementace 23 4.1 Roº²í ení Hibernate entit............................. 23 4.2 Server........................................ 23 4.2.1 Kongurace serveru............................ 23 4.2.2 Nastavení RMI............................... 24 4.2.3 Nastavení Hibernate a p ipojení k databázi............... 25 4.2.4 Balí ky serveru............................... 25 4.3 Klientská aplikace.................................. 25 4.3.1 Dialogy................................... 25 4.3.2 Architektura aplikace............................ 27 4.3.2.1 Controller ( adi )........................ 27 4.3.2.2 Model............................... 27 4.3.2.3 View (pohled).......................... 27 4.3.3 Záloºky aplikace.............................. 28 4.3.4 Kongurace aplikace............................ 28 4.3.5 Lokalizace.................................. 29 4.3.6 Výb r ²títk................................ 29 4.3.7 Interaktivní tabulka............................ 29 4.3.8 Propojení prvk CategoryTree a CategoryTable............. 30 5 Testování 31 5.1 Zát ºový test.................................... 31 5.1.1 P íprava................................... 31 5.1.2 Výsledek................................... 31 5.2 Simulace chybových událostí............................ 32 5.3 Akcepta ní testy.................................. 33 6 Záv r 35 6.1 Postup p i vývoji.................................. 35 6.2 Zhodnocení pr b hu vývoje............................ 36 6.3 Dal²í vývoj systému................................ 37 A Instala ní a kongura ní p íru ka 41 A.1 Instalace....................................... 41 A.1.1 Server.................................... 41 A.1.1.1 Poºadavky aplikace....................... 41 A.1.1.2 Instalace databáze........................ 42 A.1.1.3 Instalace serveru......................... 42 A.1.2 Desktopový klient............................. 43 A.1.2.1 Instalace............................. 43 A.2 Kongurace..................................... 43 A.2.1 Server.................................... 43 A.2.2 Klient.................................... 43

OBSAH xiii A.2.2.1 Slovníky.............................. 44 B Uºivatelská p íru ka 45 B.1 Popis uºivatelského rozhraní............................ 45 B.1.1 Hlavní menu................................ 45 B.1.2 Uºivatelské menu.............................. 45 B.1.3 Záloºky aplikace.............................. 46 B.2 Záloºka zobrazení receptu............................. 46 B.3 Záloºka výb ru receptu............................... 47 B.4 Výb r ²títk..................................... 47 B.5 Nápov da aplikace................................. 47 B.6 B ºné akce uºivatele................................ 48 B.6.1 Registrace nového uºivatele........................ 48 B.6.2 P idání receptu............................... 48 B.6.3 Hodnocení receptu............................. 49 B.6.4 Komentování receptu............................ 49 B.6.5 Tisk receptu................................. 49 B.6.6 Administrace kategorií........................... 50 B.7 Chyby v aplikaci.................................. 51 C Seznam pouºitých zkratek 55 D Obsah p iloºeného CD 57

xiv OBSAH

Seznam obrázk 2.1 Schéma komunikace RMI............................. 6 2.2 Aplika ní role.................................... 7 2.3 Povolené innosti rolí................................ 8 2.4 P ípady uºití role Nep ihlá²ený uºivatel..................... 8 2.5 P ípady uºití role Uºivatel............................. 9 2.6 P ípady uºití role Administrátor......................... 10 3.1 Diagram nasazení.................................. 16 3.2 Schéma databáze.................................. 18 3.3 P ehled metod klientského rozhraní serveru................... 20 3.4 Schéma komunikace ástí MVC.......................... 22 B.1 Popis ástí hlavního okna aplikace........................ 46 B.2 Popis záloºky receptu............................... 47 B.3 Popis menu záloºky receptu............................ 48 B.4 Popis záloºky výb ru receptu........................... 49 B.5 Dialog p idání receptu - Krok Informace..................... 50 B.6 Dialog p idání receptu - Krok P ísady...................... 51 B.7 Dialog p idání receptu - Krok títky....................... 52 B.8 Náhled tisknuté stránky receptu.......................... 53 B.9 Ukázka chyby aplikace............................... 53 xv

xvi SEZNAM OBRÁZK

Kapitola 1 Úvod Cílem této práce je navrhnout a implementovat sí ovou aplikaci umoº ující sdílení recept mezi uºivateli. P i tvorb je nutné dbát na to, aby aplikace vyhovovala poºadavk m na pouºitelnost a p ístupnost a aby vyhledávání recept bylo co moºná nejjednodu²²í a co nejrelevantn j²í vzhledem k parametr m, podle kterých si uºivatel chce recept vybrat. Aplikace bude mít dv rozhranní. Desktopového klienta, coº je aplikace, která funguje jako samostatný program na uºivatelském PC a webového klienta, se kterým bude moºné p istupovat k aplikaci ve webovém prohlíºe i. Cílem této záv re né práce bylo podílet se na návrhu a vývoji serverové ásti, navrhnout a zcela implementovat desktopového klienta. 1.1 Up esn ní zadání projektu Zadání práce bylo up esn no zadavatelem t mito body: Aplikace musí být snadno roz²i itelná (modulární) Kaºdý recept bude mít ty i ásti název, suroviny, p íprava, doba p ípravy Recepty je moºné p idávat, upravovat, mazat, m nit jejich za azení v kategoriích. Kaºdý recept bude p i azen r zným kategoriím ve dvou strome cích kategorií podle typu jídla a podle základních surovin Oba stromy kategorií je moºné editovat (p idávat, mazat, m nit ozna ení kategorie) 1.2 Poºadavky 1.2.1 Nefunk ní poºadavky V této podkapitole jsou uvedeny v²echny poºadavky, které se nevztahují na funk nost, nýbrº na technologie, celkový návrh a zpracování projektu. 1

2 KAPITOLA 1. ÚVOD 1.2.1.1 Obecné poºadavky Tyto poºadavky se týkají celkového návrhu projektu a jeho dokumentace. Jsou to: Aplikace musí být rozd lena na serverovou ást a dal²í klientské ásti. Celý kód musí být ádn okomentovaný a p ílohou k práci musí být programátorská dokumentace ve formátu JavaDoc. 1.2.1.2 Server Serverová ást aplikace obsluhuje ve²keré poºadavky od klientských aplikací. Obsahuje ve ejné rozhraní, které komunikuje s klienty a poskytuje jim data. Poºadavky na serverovou ást aplikace jsou: Zaji² uje operace nutné pro práci s daty - p ipojení a dotazování k databázi. Denuje rozhraní pro klientské aplikace. Pouºití technologie Java Enterprise Edition. 1.2.1.3 Desktopový klient Tato ást systému E-chef je samostatn fungující aplikace, která bude uºivateli umoº ovat práci s daty pomocí sí ového spojení. Tato aplikace se p ipojuje k serverové ásti. Poºadavky na desktopovou aplikaci jsou: Aplikace musí být snadno pouºitelná a p ístupná a musí umoº ovat výb r recept pomocí jednoduchého systému ²títkování. Aplikace si nesmí pamatovat ºádná data, ve²keré záznamy jsou uloºeny v databázi, ke které klient vºdy p istupuje p es serverovou ást. Pro implementaci musí být pouºita technologie Java 6. 1.2.2 Funk ní poºadavky Tato podkapitola se zabývá poºadavky na funk nost, které jsou spole né v rámci celého systému. Jsou to: Registrace uºivatel P ihla²ování uºivatel Vkládání recept Umoºnit snadnou kategorizaci recept pomocí p idávání ²títk recept m Vyhledávat recepty

1.2. POšADAVKY 3 Zobrazovat recepty P idávat recepty Hodnotit recepty Komentovat recepty Spravovat vlastní recepty Dal²í dodate né funk ní poºadavky pro správce systému jsou: P idávání nových ²títk Správa existujících ²títk Moºnost povy²ovat b ºné uºivatele na dal²í správce systému

4 KAPITOLA 1. ÚVOD

Kapitola 2 Analýza Obsahem této kapitoly je analýza zadání projektu, výb r vhodných technologií a metod implementace pro jejich následné pouºití. 2.1 Výb r technologií V této podkapitole jsou uvedeny v²echny technologie vhodné pro tento projekt a jejich porovnání s moºnými alternativami. Jelikoº bude aplikace rozd lena do serverové a dvou klientských ástí, tak technologie JEE bude pro tento zp sob implementace více neº vhodná. Roz²i itelnost a centralizovanost jsou jedny z hlavních výhod této technologie. Rozd lení aplikace a pouºití standardu JEE jsou zárove nefunk ní poºadavky na aplikaci. 2.1.1 Aplika ní server JEE vyºaduje aplika ní server, na který bude nasazena serverová ást aplikace a webový klient. V tomto okamºiku je nutné ujasnit si technologie, které budeme pouºívat, protoºe ne kaºdý aplika ní server podporuje v²echny pot ebné technologie. Zvolili jsme Tomcat 6.0, který je jednoduchý, neobsahuje v²echny technologie standardu JEE, ale p i pouºití n kterých knihoven lze jeho moºnosti snadno roz²í it. 2.1.2 Databáze Pro ukládání dat bylo vhodné pouºít rela ní databázi. Jako rozumné varianty se jevily databáze PostgreSQL a MySQL. Zvolili jsme MySQL, protoºe nebude nutné pouºívat sloºité funkce SQL jazyka, ani roz²i ovat logiku aplikace aº do databáze. Jako jádro bude pouºito InnoDB, aby bylo moºné pouºít referen ní integritu, kterou podporuje. Z aplikace by bylo moºné p istupovat k databázi a provád t ve²keré dotazy p ímo. Mnohem elegantn j²í e²ení je pouºití objektov rela ního mapování (ORM). Nejlep²í moºnou variantou v sou asnosti je knihovna Hibernate 3.0. Tato verze podporuje mimo jiné i anotace, kterými lze mapovat entity na databázi s minimálním pouºitím kongura ního souboru Hibernate. Pro p ipojení k databázi MySQL je nutné, aby aplikace obsahovala knihovnu JDBC Connector pro MySQL. 5

6 KAPITOLA 2. ANALÝZA 2.1.3 Sí ová komunikace V serveru budou implementovány primárn metody provád jící operace s databází. Co se webové klientské aplikace tý e, ta m ºe tyto metody volat p ímo, protoºe je integrována do serveru E-chef a bude spu²t na na aplika ním serveru paraleln s ním. Problém vzniká u desktopové klientské aplikace. Ta si musí se serverem vym ovat data po síti. Jistou moºností by bylo vytvo it metody na tuto komunikaci a vlastní protokol denující funkce r zných p íkaz a jejich syntaxe, coº je sloºité e²ení. Mnohem jednodu²²í je pouºit vzdálené volání metod (RMI), coº je sou ástí JEE. Server Tomcat v²ak vzdálené volání metod nativn nepodporuje. Nejsnaº²í varianta, jak zavést do serveru Tomcat podporu RMI, je pouºití frameworku Spring. Ten umoº uje distribuovat v²echny metody jako sluºby, které chceme vzdálen volat. 2.1.4 Vzdálené volání metod Vzdálené volání metod pouºívá protokol TCP/IP a jeho podstatou je moºnost volat metody umíst né na serveru a tím p esounout logickou ást aplikace na server. P enos dat zde funguje stejn jako ve standardní Java aplikaci. Metodám lze p edat objekt jako parametr a pouºít její návratovou hodnotu. Samotný p enos dat je v reºii RMI. 4. krok Klient Klient na základě přijatých informací naváže spojení se serverem. Nyní již může probíhat samotná komunikace a klient může volat vzdálené metody. Aplikační server Server E-chef 3. krok RMI registr odešle klientovi informace o serveru a službách, které server poskytuje. RMI registr může být nastaven, aby odesílal rozhraní tříd služeb klientovi. To je v našem případě zakázané a klientská aplikace tyto rozhraní musí obsahovat. 2. krok Klient se připojí na RMI registr a vyžádá si informace potřebné k připojení na aplikační server. 1. krok Aplikační server vytvoří RMI registr a definuje v něm služby s odkazy na sebe, které bude moct klient volat. RMI registr Obrázek 2.1: Schéma komunikace RMI Kv li pouºití vzdáleného volání procedur vznikla dv majoritní omezení. V²echny metody, jeº bude moºné volat vzdálen, bylo nutné umístit do t íd, které musí implementovat k sob p idruºené rozhraní, kde budou uvedeny v²echny volatelné metody. Toto rozhraní se nazývá Stub a musí být stejné jak na stran serveru, tak na stran vzdáleného klienta, který musí obsahovat hlavi ky metod, jeº m ºe volat. Proto bylo nutné vytvo it knihovnu, která bude

2.2. ROLE 7 sdílena ob ma t mito prot j²ky. Do této knihovny bylo také vhodné umístit entity databáze, protoºe i ty musejí být sdíleny. V²echny objekty, které si protistrany vym ují, musí být serializovatelné. V rámci jazyku Java tedy musí implementovat rozhraní Serializable, nebo to nesmí být objekty, ale jednoduché datové typy. Dal²ím omezením, které pouºití RMI p iná²í, je jeho dynamické pouºívání sí ových port. RMI vyºaduje povolení komunikace na portech v t²ích nebo rovno 1024. To znamená, ºe pokud chceme mít server zabezpe ený rewallem, musíme povolit v²echny tyto porty, ímº vzniká bezpe nostní riziko. 2.1.5 Technologie klientské aplikace Klientská aplikace slouºí primárn k zobrazování dat obdrºených ze serveru na vlastní dotaz a odesílá data vloºená uºivatelem. V klientské aplikaci se pro sí ovou komunikaci bude pouºívat stejná technologie jako v serverové ásti - RMI. Na rozdíl od serveru klientská aplikace nebude distribuovat ºádné sluºby, bude se pouze p ipojovat k RMI registru, který ho odkáºe na server. Aby klient mohl pouºívat stejné entity Hibernate, s kterými pracuje i server, musí taktéº obsahovat knihovny Hibernate, kv li anotacím v t chto entitách. Pro zobrazování uºivatelského rozhraní bude aplikace pouºívat knihovny Swing. 2.2 Role Podkapitola se zabývá rozd lením v²ech funkcí aplikace do rolí. Kaºdá role má vlastní mnoºinu práv a denuje akce, které uºivatel smí s aplikací provád t. Pro spln ní funk ních poºadavk aplikace bylo nutné vytvo it t i hierarchicky sloºené role: Administrator User Visitor Spravuje systém pomocí jednoduché administrace Přihlášený uživatel v systému Nepřihlášený uživatel (návštěvník) systému Obrázek 2.2: Aplika ní role Zde je seznam v²ech akcí, které jednotlivé role mohou provád t s tím, ºe role i jejich moºnosti jsou d d ny dle p ede²lého obrázku:

8 KAPITOLA 2. ANALÝZA Visitor + Otevření receptu + Prohlížení a vybírání štítků + Přihlášení + Registrace + Tisk receptu + Úprava nastavení aplikace User + Komentovat recept + Ohodnotit recept + Označení cizího receptu jako oblíbený + Přidat ingredienci + Přidat recept + Spravovat vlastní recept + Vložit recept do oblíbených Administrator + Spravovat ingredienci + Spravovat kategorii + Spravovat libovolný recept + Spravovat uživatele Obrázek 2.3: Povolené innosti rolí 2.2.1 Náv²t vník (nep ihlá²ený uºivatel) Nep ihlá²ený uºivatel smí pouze vyhledávat recepty dle ²títk a zobrazovat je. Nesmí mít ºádné právo na zm nu dat v aplikaci. M ºe se ale zaregistrovat a následn p ihlásit a zm nit svou roli na P ihlá²ený uºivatel. Přihlášení «precedes» Registrace Visitor (from Actors) Prohlížení a vybírání štítků Otevření receptu «precedes» Tisk receptu Úprava nastavení aplikace Pouze v rámci desktopového klienta Obrázek 2.4: P ípady uºití role Nep ihlá²ený uºivatel

2.2. ROLE 9 2.2.2 P ihlá²ený uºivatel P ihlá²ený uºivatel má stejná práva jako nep ihlá²ený uºivatel a navíc m ºe je²t vkládat, editovat a mazat své recepty. Dále má právo vykonávat v²echny innosti, které neupravují cizí recepty nebo ostatní data vloºená jinými uºivateli. Označit cizí recept jako oblíbený Ohodnotit recept «precedes» «precedes» Otevření receptu User (from Actors) Komentovat recept «precedes» (from Visitor) «precedes» Vložit recept do oblíbených Spravovat vlastní recept Přidat recept «include» Přidat ingredienci Uživatel smí přidávat novou přísadu, pouze při samotném přidávání receptu Obrázek 2.5: P ípady uºití role Uºivatel

10 KAPITOLA 2. ANALÝZA 2.2.3 Administrátor Administrátor aplikace smí d lat v²e, co aplikace umoº uje, v etn zm ny dat vloºených jinými uºivateli. Jeho dal²í pravomocí je povy²ovat uºivatele na administrátory. Po instalaci aplikace tedy bude zaregistrován jeden uºivatel s právem administrátora a ten m ºe toto právo ud lovat dal²ím uºivatel m. Spravovat kategorii Spravovat libovolný recept «extend» Spravovat vlastní recept (from User) Administrator (from Actors) Spravovat ingredienci Spravovat uživatele Obrázek 2.6: P ípady uºití role Administrátor 2.3 P ihla²ování uºivatel Tato podkapitola rozebírá opat ení, která bude nutno implementovat, aby nedocházelo k neoprávn ným p ihlá²ením do aplikace. P ihlá²ení probíhá na stran serveru, kam klientské aplikace ode²lou e-mail uºivatele a hash jeho hesla. Knihovny jazyku Java neobsahují metodu, která pouºívá stejný hashovací algoritmus jako MySQL. Proto bylo dobré si tuto metodu naimplementovat, aby se hodnoty daly porovnávat p ímo v SQL dotazu. Tato metoda byla umíst na do sdílené knihovny, protoºe její pouºití je nutné u v²ech klientských aplikací. Server po obdrºení údaj nejprve zkontroluje e-mailovou adresu. Pokud v databázi existuje záznam s tímto e-mailem, tak porovná k e-mailu p i azené heslo s heslem, které p ijal od klientské aplikace. Pokud si jsou tyto hodnoty rovny, server vrátí odpov o úsp chu nebo naopak informuje o neúsp chu. 2.4 Recept Recept je nejd leºit j²í entita v aplikaci. Recept by m l obsahovat ingredience, ze kterých se pokrm skládá, a postup, jakým se p ipravuje. Uºivatel musí mít moºnost ur it také mnoºství ingrediencí, které je zapot ebí. Dále by kaºdý p ihlá²ený uºivatel m l mít moºnost hodnotit recepty a p idávat komentá e k cizím recept m, aby mohl informovat ostatní o kvalit receptu a provád t p ípadné korekce v p íprav pokrmu.

2.5. VYHLEDÁVÁNÍ RECEPT 11 Uºivatel vkládající recept bude mít moºnost ho umístit do jedné i více kategorií za pomoci ²títk. Dal²í uºivatelé si potom mohou recept vyhledat jak podle ingrediencí, tak podle t chto kategorií. Celkové hodnocení receptu m ºe také slouºit jako koecient, podle kterého se nalezené recepty budou v seznamu výsledk adit. K receptu bude také moºné p i azovat ilustrativní obrázky, aby ostatní uºivatelé m li je²t lep²í p edstavu, jak pokrm vypadá. Tyto obrázky je moºné ukládat do soubor na serveru v p edem zvoleném adresá i, nebo je ukládat p ímo do databáze. Zvolili jsme variantu ukládání obrázk do databáze. P i ukládání do soubor by bylo nutné implementovat dal²í metody na ítání a ukládání obrázk, kdeºto p i ukládání do databáze se s obrázky manipuluje jako s bajtovým typem BLOB. Hibernate na práci s t mito záznamy dovoluje pouºít pouze základní java.persistence anotace a o ostatní práci se stará sám. Jedinou podmínkou je nutnost p ená²et pole bajt, nikoli obrázek jako objekt, takºe klientské aplikace musejí obsahovat metody na p evod obrázku do bajtového pole a naopak. 2.5 Vyhledávání recept Aby aplikace byla snadno pouºitelná, je nutné drºet se n kterých zásad, které uºivateli usnadní manipulaci s aplikací. Dal²í nutností je umoºnit mu, pokud vyhledává n jaký recept, aby na²el dle hledaných parametr jen ty nejrelevantn j²í výsledky. Proto byly zavedeny ²títky, které je moºné p idávat k recept m. Ty ozna ují jisté vlastnosti recept. Nap íklad zda-li je recept vhodný k ob du, zda-li je recept sváte ní ve e e, a v neposlední ad z jakých ingrediencí se pokrm skládá. Vhodné pro tento problém bylo uspo ádat si v²echny kategorie i ingredience do strom. Pro uºivatele je to p ehledné a umoº uje to dále kategorizovat jednotlivé ²títky. Z toho plyne, ºe kaºdý ²títek m ºe mít n kolik pod azených ²títk a uºivatel si m ºe vybírat libovolný z nich, tzn. vybráním ²títku vybere i v²echny pod azené. Stejný systém je i u ingrediencí. Stromy jsou navrhnuty tak, ºe existují skupiny kategorií, coº jsou logické celky t chto ²títk, jako nap íklad "Doba konzumace", která obsahuje kategorie "Ve e e", "Snídan ". Jedna skupina tedy odpovídá jednomu stromu. Receptu lze p i adit pouze kategorie i podkategorie, nikoliv celé skupiny, to by ve vyhledávání nem lo smysl. Kaºdá kategorie smí být uvedena pouze jako podkategorie jediné kategorie nebo jako ko en stromu v jedné skupin kategorií. Ingredience jsou trochu odli²ná skupina kategorií. Jsou tedy uspo ádány zvlá² v jednom strom, ve kterém jsou skupiny a podskupiny ingrediencí. Listy tohoto stromu jsou jiº kone n samotné ingredience, které lze vkládat do receptu. Vybírání receptu podle ingrediencí funguje stejn jako u kategorií. Pokud uºivatel vybere nap. "Mlé né výrobky", vybere tímto ve²keré ingredience, které jsou v této skupin. Jedna ingredience se m ºe vyskytovat vícekrát v r zných skupinách ingrediencí. Ingredience musí být vºdy za azena do n jaké skupiny, jinak podle ní není moºné vyhledávat. Pokud uºivatel zvolí p i vyhledávání více ²títk, tak z mnoºiny recept, které byly vybrány prvním ²títkem, vznikne nová mnoºina, která bude pr nikem p vodní mnoºiny recept a mnoºiny, kterou obsahuje pozd ji p idaný ²títek. Pokud vybere ²títek, který obsahuje více pod azených ²títk, tak vniklá mnoºina recept je slou ením mnoºin recept v²ech pod azených ²títk.

12 KAPITOLA 2. ANALÝZA 2.6 Administrace ²títk Kv li zachování po ádku v datech aplikace nem ºe ani p ihlá²ený uºivatel p idávat kategorie. Jejich seznam by m l být vloºen do databáze ihned p ed uvedením aplikace do provozu. Zm ny a úpravy kategorií je potom moºné provád t pouze s právy administrátora. Uºivatel si tedy musí vybrat pouze z nabídnutých kategorií. U ingrediencí je správa trochu odli²ná. Ne vºdy je moºné vybrat ingredience p esn tak, jak je vyºaduje uºivatel. Proto ingredience m ºe p idávat sám uºivatel. A to tak, ºe pokud p idá k receptu p ísadu, která neexistuje v databázi, bude ingredience do databáze vloºena bez za azení do skupiny a administrátor o tom bude informován, aby p ípadn mohl ingredienci upravit a p ede²lo se duplicitám nap íklad jen kv li p eklepu v názvu p ísady. Ostatní operace nad ingrediencemi m ºe provád t op t jen administrátor. 2.7 Práce s databází K databázi je p ipojen pouze server, který pomocí knihoven Hibernate p ekládá databázové záznamy na jednoduché Java objekty denované podle t íd, které nesou název entity. Entitou se rozumí t ída, která za pomoci anotací ur uje, jak se data z databáze mají p ekládat (to jest, jaká entita p edstavuje jakou tabulku, jaká prom nná t ídy je vázána na jaký sloupec, jaký sloupec je primární klí, atd.). V d ív j²ích verzích Hibernate nebylo moºné pouºívat anotace. Celá kongurace se provád la v XML souboru hibernate.cfg.xml, kde bylo ur eno i ve²keré mapování. Ve verzi Hibernate 3.0 je jiº moºné pouºít velkou v t²inu anotací z balí ku java.persistence. Hibernate obsahuje i své vlastní anotace, které mají speciální ú ely, tedy roz²i ují pouºitelnost java.persistence anotací. Klienti volají metody objekt pro p ístup k databázi (Data Acces Object - DAO) na serveru. Tyto objekty obsahují ve²keré metody pro práci s daty v databázi E-chef. Kaºdá metoda, kterou je moºné volat klientem, musí být zve ejn na v rozhraní DAO, aby bylo moºné ji distribuovat p es RMI. Tato rozhraní jsou umíst na ve sdílené knihovn, aby klienti v d li, jaké metody je moºné volat, v p ípad webového klienta p ímo a v p ípad desktopového klienta vzdálen. Povinností kv li Hibernate je, aby volání jakékoliv metody manipulující s daty v databázi byla v transakci. Tudíº v²echny metody, které m ºe klient volat, otevírají novou transakci, provedou v²e pot ebné a v p ípad chyby celou transakci zru²í, jinak potvrdí (commit). Hibernate obsluhuje tyto transakce ve vlastní reºii. Nejedná se tedy o transakce v databázi. 2.7.1 Nastavení p ipojení k databázi K nastavení Hibernate slouºí tedy soubor hibernate.cfg.xml, který je nutné uloºit do výchozího balí ku aplikace, tzn. mimo v²echny ostatní balí ky. V tomto souboru m ºe být denováno k jaké databázi se má Hibernate p ipojovat, jaké bude pouºívat kódování p i p enosu a dal²í. Av²ak pro zachování dynami nosti bylo nutné zavést konguraci p ipojení k databázi do na²eho kongura ního souboru serveru, aby nastavení mohl snadno upravovat kdokoliv, kdo bude spravovat server a v kongura ním souboru Hibernate ponechat jen nastavení, které není pot eba m nit. Z tohoto d vodu bylo i nastavení Hibernate upraveno tak, aby

2.7. PRÁCE S DATABÁZÍ 13 parametry, které má smysl m nit, byly na ítány z kongura ního souboru serveru. Hibernate se tedy musí áste n nastavovat i za b hu programu. 2.7.2 Soub ºná editace Jedním z problém, který se musí p i práci s databází e²it, je konkurence p i editaci dat. I kdyº Hibernate poskytuje pro e²ení tohoto problému vlastní metody, v tomto projektu nebyly pouºity, protoºe konkuren ní editace m ºe v aplikaci reáln nastat pouze ve t ech p ípadech a vyplatilo se e²it soub ºnou editaci ve vlastní reºii. Situace, kdy m ºe nastat konikt: Editace receptu - uºivatel edituje recept a mezitím se n kdo pokusí o editaci nebo smazání toho samého receptu Konkurentní editace kategorií nebo p ísad administrátory Zm na/odebrání kategorií nebo p ísad p i editaci receptu Pokud uºivatel provede n kterou z t chto operací, m ºe nastat to, ºe uºivateli, který edituje jako první, se smaºou ve²keré jeho úpravy, nebo p i odebrání n kterých dat b hem editace vznikne výjimka ObjectNotFoundException (p i ukládání recept /kategorií/p ísad, které byly b hem editace smazány) nebo ConstraintViolationException (p i ukládání receptu, jehoº pod ízené ingredience nebo kategorie byly p i editaci smazány). Bod 1 je e²en pomocí zámk. Zámky jsou ukládány v seznamu p ímo v objektech pro manipulaci s daty. P ed úpravou n jakého objektu si aplikace zjistí, zda-li byl jiº ten samý objekt uzam en jiným uºivatelem. Pokud objekt uzam en nebyl, povolí editaci a objekt uzamkne na 10 minut, nebo do dokon ení úprav. Pokud je jiº objekt uzam en, ode²le klientské aplikaci notikaci o zámku a zakáºe editaci. Maximální doba pro uzam ení objektu je ochrana pro p ípadný pád klientské aplikace p i uzam ení n jakého objektu. Samotné odemykání tedy probíhá, pokud je zámek star²í jak 10 minut, pokud je uºivatel administrátor a zvolí násilné odemknutí, nebo pokud uºivatel ádn dokon í editaci a klientská aplikace odemkne objekt sama. 2.7.3 Opoºd né na ítání dat Pro zvý²ení výkonu aplikace bylo pouºito opoºd né na ítání (Lazy Fetching) v²ech kolekcí Hibernate objekt. Jedná se o základní vlastnost v²ech kolekcí, kterou lze sice vypnout, ale aplikace tím utrpí velké ztráty na výkonu. Je to metoda umoº ující fyzicky na ítat data z databáze pod ízených kolekcí objekt, aº kdyº k nim program p istoupí. Tzn. pokud máme entitu obsahující libovolnou kolekci a pokusíme se k této kolekci p istoupit, Hibernate teprve na te data z databáze. Oproti tomu je moºné pouºít klasické na ítání dat, kdy se v²echny kolekce a vazby entity na tou ihned p i na tení samotné entity. Pokud ale databáze obsahuje etná propojení mezi jednotlivými entitami, m ºe nastat situace, ºe p i staºení jedné entity Hibernate na te rekurzivn i celou databázi. Pro na²í databázi je tedy opoºd né na ítání nutné. Av²ak s pouºitím této metody vzniká problém. Hibernate nem ºe na íst data, pokud jiº byla transakce uzav ena a p i pouºití

14 KAPITOLA 2. ANALÝZA vzdáleného volání procedur neexistuje zp sob, jak by se data mohla opoºd n na íst ze serveru. Proto je nutné na íst n které kolekce, které plánujeme pouºít, jiº p ed odesláním dat klientovi. Této operaci se íká inicializace. 2.7.3.1 Inicializace kolekcí Inicializace se provádí voláním statické metody t ídy Hibernate initialize(). Tato metoda na te z databáze v²echny parametry a kolekce objektu, který této metod p edáme. Pokud jí p edáme kolekci, stane se tak pro v²echny objekty dané kolekce. Mnohdy se musí tato metoda volat rekurzivn, nap íklad pro získání celého stromu p ísad a kategorií. Poté co jiº klient má tyto stromy, je moºné snadno získat recepty dané ingredience i kategorie. Zavolá se metoda, inicializující kolekci recept dané kategorie/ingredience, vºdy p edtím, neº to aplikace poºaduje. Tím, ºe ukon íme relaci Hibernate, po na tení n jakého objektu entity nem ºeme inicializovat jeho kolekce, protoºe práv ukon ením relace vyjmeme objekt z kontextu Hibernate. Hibernate ale umoº uje snadno vracet entity do jeho kontextu zavoláním metody lock() relace Hibernate. Tato metoda standardn umoº uje uzamykat objekty databáze, av²ak pokud jí zavoláme s parametrem LockMode.NONE, provede jen to, ºe zvolený objekt uvede zp t do kontextu. Poté ho jiº m ºeme ve stejné relaci inicializovat. Podmínkou v²ak je, ºe tento objekt se nesmí li²it od objektu v databázi.

Kapitola 3 Návrh Obsahem této kapitoly je návrh struktury aplikace a jejích ástí. Dále se zabývá rozborem n kterých zvlá²tních p ípad, které si bylo vhodné ujasnit p ed samotnou implementací. 3.1 Nasazení aplikace Aplikace je rozd lena na server a dv klientské ásti. Webový klient je spu²t n paraleln se serverem na aplika ním serveru Tomcat 6.0. Uºivatelé k tomuto klientovi p istupují p es standardní webový prohlíºe, který se serverem komunikuje protokolem HTTP. Desktopový klient je samostatná aplikace, která se k serveru p ipojuje pomocí protokolu RMI. Uºivatelé, kte í se tedy cht jí p ipojit k aplikaci pomocí desktopového klienta, musí mít nainstalované Java Runtime Environment a mít k dispozici samotnou klientskou aplikaci. Server se p ipojuje k databázi MySQL. V na²em systému po ítáme s tím, ºe databáze je spu²t na na stejném za ízení jako aplika ní server, i kdyº to není nutné. Jednotlivé ásti aplikace a jejich propojení obsahuje diagram nasazení na obrázku 3.1. 15

16 KAPITOLA 3. NÁVRH «device» Client «executionenvironment» Browser «device» Server «executionenvironment» Application Server Servlet Hibernate TCP/IP «call» «send» AJAX «http» «JSON» GWT RPC RMI registry Vzdálené volání požadavku «device» Desktop Client «RMI» Apache Tomcat «executionenvironment» Database Desktop E-chef Application TCP/IP MySQL Obrázek 3.1: Diagram nasazení

3.2. SCHÉMA DATABÁZE 17 3.2 Schéma databáze Databáze byla navrºena tak, aby správn dodrºovala referen ní integrity, které engine InnoDB databáze MySQL podporuje. Hlavní entitou v tomto schématu je entita Recipe, p edstavující recept vkládaný uºivateli. Ta obsahuje vazbu na uºivatele (entita User), který recept p idal a uºivatele, kte í ozna ili jako oblíbený. Tato vazba obsahuje prost edníka RecipeFavourite kv li komentá i, který si k ní m ºe uºivatel p idat. Dal²ími entitami, které se váºou na recept, jsou komentá e a hodnocení receptu. Recept m ºe také obsahovat libovolný po et obrázk, které k n mu uºivatel vloºí. Vºdy jeden obrázek by m l mít záznam i v tabulce RecipeMainImage, která ur uje, ºe obrázek byl zvolen jako hlavní obrázek receptu. Obrázky jsou v databázi uloºeny jako typ BLOB, coº je bajtové pole. Entitami, podle kterých lze recept vyhledat, jsou p ísady (Ingredient) a kategorie (Category). Ty v aplikaci dohromady tvo í ²títky, které lze receptu p i adit. Vazba recept-p ísada op t obsahuje prost edníka RecipeIngredient kv li mnoºství, které je nutné uvést u kaºdé p ísady vloºené k receptu. I kdyº by bylo moºné vyjád it toto mnoºství v íslech, je tento atribut typu String, kv li jednotkám mnoºství, které uºivatel dopisuje sám. Kategorie recept a p ísady lze dále kategorizovat ve tvaru strom. Kaºdá kategorie m ºe mít libovolný po et pod ízených kategorií a musí spadat vºdy do jedné skupiny kategorií, kv li srozumitelnému rozd lení. Na druhou stranu p ísada nem ºe mít dal²í pod adné p ísady. Ty mohou být pouze listy stromu p ísad, av²ak kaºdá p ísada m ºe být umíst na do více skupin p ísad. Pokud není umíst na nikam, není podle ní moºné vyhledávat recepty, protoºe ve stromu ingrediencí nebude nikde zobrazena. Skupiny p ísad mohou zase obsahovat pod ízené skupiny p ísad. Tím je tedy moºné kategorizovat i p ísady a zavést tak op t stromovou strukturu, kde ko enem stromu je pomyslná skupina kategorií "P ísady". Teoreticky m ºe nastala situace, kdy jedna p ísada je umíst na do skupiny p ísad "A"a zárove do skupiny "B", p i emº skupina "B"je pod ízená skupina skupiny "A", coº není správné za azení p ísady, ve vyhledávání nemá smysl. O tento problém se musí starat sama aplikace, protoºe v rámci databáze toto denovat nelze. Kaºdá entita databáze, která není pouhým prost edníkem vazby, má sv j prot j²ek v entitách Hibernate. Datový model je zobrazen na obrázku 3.2.

18 KAPITOLA 3. NÁVRH user recipe_raiting «column» *PK id created email password «PK» + PK_user() 1 1 1 owner 0..* rater recipe_favourite «column» *PK recipe_id *PK user_id comment «PK» + PK_recipe_favourite(, ) 0..* 0..* «column» *PK recipe_id *PK user_id rate «PK» + PK_recipe_raiting(, ) 0..* 0..* image «column» *PK id recipe blobdata description «PK» + PK_image() comment «column» *PK id comment parent recipe user created «PK» + PK_comment() category «column» *PK id description name category_group parent «PK» + PK_category() 0..* 0..1 0..* 0..* 0..1 0..* 1 child child 0..* 0..* 1 recipe «column» *PK id cook_time directions name prepare_time user created last_edited «PK» + PK_recipe() recipe_category «column» *PK recipe_id *PK category_id 1 1 «PK» + PK_recipe_category(, ) 1 0..* 1 1 0..1 recipe_main_image «column» *PK recipe_id image_id «PK» + PK_recipe_main_image() 1 0..* ingredient «column» *PK id name «PK» + PK_ingredient() 1 1 1 1 recipe_ingredient «column» *PK ingredient_id *PK recipe_id quantity «PK» + PK_recipe_ingredient(, ) 0..* category_group «column» *PK id description name «PK» + PK_category_group() 1 ingredient_group «column» *PK id description name parent «PK» + PK_ingredient_group() 1 0..* 0..* ingredient_group_ingredient «column» *PK ingredient_group_id *PK ingredient_id «PK» + PK_ingredient_group_ingredient(, ) 0..* 0..1 child Obrázek 3.2: Schéma databáze

3.3. OBJEKTY PRO P ÍSTUP K DATABÁZI 19 3.3 Objekty pro p ístup k databázi DAO (Data Access Object) jsou objekty, které obsahují metody na ukládání, na ítání a mazání dat z databáze. P edává se jim, nebo vracejí objekt p edstavující záznam v tabulce. Tento objekt musí být vºdy denován podle n jaké Hibernate entity. V na²em p ípad tyto objekty pro p ístup k databázi obsahují i dal²í pomocné metody na uzamykání objekt nebo na jejich inicializaci. Podmnoºina metod t chto objekt tvo í rozhraní, na které se p ipojují klientské aplikace a uº p ímo, nebo protokolem RMI. Umoº ují klient m provád t v²echny operace, které lze d lat centráln na serveru. 3.4 Klientské rozhraní serveru Klientské rozhraní je podmnoºinou metod objekt pro p ístup k databázi (DAO). K t mto metodám mají p ístup klientské aplikace. Je tvo eno jednotlivými rozhraními, která jsou implementována samotnými DAO. V rozhraní pro vzdálené klienty je pouºito RMI pro distribuci t chto metod, které obsluhují entity Hibernate. Tzn. ukládají/na ítají záznamy v databázi, inicializují kolekce jiných entit (nutnost Hibernatu p i opoºd ném na ítání dat) a provád jí dal²í operace na datech. Distribuce t chto objekt jako sluºeb je provedena frameworkem Spring. Je to jediná vlastnost tohoto frameworku pouºitá v aplikaci a probíhá na základ kongura ního souboru Springu applicationcontext.xml p i zavád ní aplikace do aplika ního serveru. Ve²keré nastavení v tomto souboru se tedy zabývá pouze distribucí sluºeb pro RMI. Zde je seznam v²ech distribuovaných sluºeb. V²echny rozhraní DAO jsou umíst ny v knihovn sdílené klientskou i serverovou ástí aplikace. Jsou rozd leny do logických celk podle dat, se kterými pracují. UserService / UserDao - Obsluhuje uºivatele, ov uje správný login RecipeService / RecipeDao - Obsluhuje recepty CategoryService / CategoryDao - Obsluhuje kategorie a jim nad azené skupiny kategorií (p idání nových kategorií, odebrání kategorií) - pouºíváno pouze pokud je uºivatel administrátor IngredientService / IngredientDao - Obsluhuje ingredience (nové ingredience p idává kdokoliv, m nit i mazat je z databáze m ºe pouze administrátor) PickableService / PickableDao - Zvlá²tní service pro na ítání strom kategorií a recept a jejich inicializaci ImageService / ImageDao - Získávání a ukládání obrázk k receptu. Odd lené p ímo od receptu kv li velkému objemu dat p i na ítání více obrázk k receptu. Ne vºdy je nutné stahovat k receptu i v²echny obrázky.

20 KAPITOLA 3. NÁVRH Kaºdý objekt pro p ístup k databázi d dí ze spole né t ídy DaoDefault. Tato nad azená t ída se stará o získávání relace Hibernate. Ta se potom p ímo stará o vkládání, úpravu a mazání dat z databáze na základ objekt entit Hibernate. V²echny rozhraní t chto DAO obsahují metody, které musí vyvolávat výjimku RemoteException. Toto je pravidlo RMI. Výjimka nastane pokaºdé, kdyº na serverové stran ve vzdálené metod nastane n jaká dal²í nezachycená výjimka. Tato výjimka je vyvolána klasicky na stran serveru, kde vznikla a poté obalena výjimkou RemoteException a odeslána klientovi. Schéma v²ech rozhraní, která jsou implementována objekty pro p ístup k databázi, tvo ící klientské rozhraní serveru: Klientské rozhraní serveru «interface» CategoryDaoInterface Remote + addcategory(category) : Category + addcategorygroup(categorygroup) : CategoryGroup + findcategories() : List<Category> + findcategories(string) : List<Category> + findcategorygroups() : List<CategoryGroup> + findcategorygroups(string) : List<CategoryGroup> + getcategory(int, boolean, boolean) : Category + getcategorygroup(int) : CategoryGroup + removecategory(category) : void + removecategorygroup(categorygroup) : void + savecategory(category) : void + savecategorygroup(categorygroup) : void «interface» RecipeDaoInterface «interface» ImageDaoInterface + delete(image) : void + get(int) : byte[] + save(image) : Image + update(image) : void + addcomment(comment) : Comment + addrecipe(recipe) : Recipe + findrecipes(user, String) : List<Recipe> + findrecipes(user, String, boolean) : List<Recipe> + findrecipes(int, int) : List<Recipe> + getbestrecipes(int) : List<Recipe> + getbestrecipes(int, boolean, boolean, boolean) : List<Recipe> + getnewestrecipes(int) : List<Recipe> + getnewestrecipes(int, boolean, boolean, boolean) : List<Recipe> + getrandomrecipes(int) : List<Recipe> + getrecipe(int) : Recipe + getrecipe(int, boolean, boolean, boolean, boolean, boolean) : Recipe + getrecipesbycategories(list<integer>, int, int) : DataResult + getrecipesbycategoriesingredients(list<integer>, List<Integer>, int, int) : DataResult + getrecipesbyingredient(int, int, int) : DataResult + getrecipesbyingredientgroup(int, int, int) : DataResult + getrecipesbyingredients(list<integer>, int, int) : DataResult + getrecipesnestedbycategory(int, int, int) : DataResult + initongo(recipe) : Recipe + lock(recipe, User) : User + refresh(recipe) : Recipe + removecomment(comment) : void + removerecipe(recipe) : void + removerecipefavourite(recipefavourite) : void + removerecipeingredient(recipeingredient) : void + saverecipe(recipe) : void + unlock(recipe, User, User) : void + unlock(recipe, User) : void Remote Remote «interface» PickableDaoInterface «interface» IngredientDaoInterface Remote + getinitializedcategorytree() : List<CategoryGroup> + getinitializedingredienttree() : List<IngredientGroup> + initpickablefull(pickable) : Pickable Remote + addingredient(ingredient) : Ingredient + addingredientgroup(ingredientgroup) : IngredientGroup + findingredientgroups(string, boolean) : List<IngredientGroup> + findingredients(string) : List<Ingredient> + getingredient(int) : Ingredient + getingredient(int, boolean) : Ingredient + getingredientgroup(int) : IngredientGroup + getingredientgroup(int, boolean) : IngredientGroup + getorphaningredients() : List<Ingredient> + removeingredient(ingredient) : void + removeingredientgroup(ingredientgroup) : void + saveingredient(ingredient) : void + saveingredientgroup(ingredientgroup) : void «interface» UserDaoInterface Remote + adduser(user) : User + findusers(string) : List<User> + findusers(string, String) : List<User> + getuser(int) : User + getuser(int, boolean, boolean) : User + getuser(string) : User + getuser(string, boolean, boolean) : User + initongo(user) : User + removeuser(user) : void + saveuser(user) : void Obrázek 3.3: P ehled metod klientského rozhraní serveru Podrobný popis tohoto rozhraní je v programátorské dokumentaci.

3.5. ROZHRANÍ PICKABLE 21 3.5 Rozhraní Pickable Jedná se o zvlá²tní rozhraní implementované v²emi entitami Hibernate, pomocí kterých je moºné vybírat recept. To jsou ingredience, jejich skupiny a kategorie. Pickable interface uvádí metody: getchildpickables() - slouºí k získání pod ízených kolekcí entit, které také implementují toho rozhraní (nap íklad entita Category vrací po zavolání getchildpickables v²echny její pod ízené kategorie) getchildpickablesrecursively() - rekurzivn sjednotí v²echny pod ízené kategorie/ingredience a vrátí jejich seznam getchildrecipes() - vrací recepty, které daná entita obsahuje getchildrecipesrecursively() - vrací recepty, které obsahují v²echny pod ízené kategorie/ingerdience (rekurzivn sjednocené) V klientské aplikaci je potom jednoduché pracovat s objekty typu Pickable a získávat seznamy jejich recept a p ípadn vytvá et pr niky í sjednocení t chto mnoºin. 3.6 Architektura klientské aplikace Obsahem kapitoly je popis architektury aplikace ve smyslu rozd lení Model-View-Controller. MVC (Model-View-Controller) je rozd lení aplikace na nezávislé celky, kde kaºdý plní svou ur itou roli. Tyto odd lené ásti spolu komunikují. Rozd lení MVC tvo í tyto prvky: adi (Controller) - vyhodnocuje p íkazy uºivatele, provádí v²echny operace s daty a zprost edkovává komunikaci uºivatelského rozhraní a serveru za pomoci modelu pohled (View) - obsluhuje v²e, co se zobrazuje uºivateli, zachytává akce provedené uºivatelem a p edává je adi i, kompletní pohled bude tvo it v t²ina t íd aplikace, které bude pohled vytvá et a zobrazovat model (Model) - v²echny objekty pro p ístup k databázi (budou umíst ny ve spole né knihovn ) t ídy obsahující metody pro manipulaci s daty a jejich vým nu se serverem adi bude obsahovat p ímo instance modelu i pohledu, jejich metody tedy m ºe volat p ímo. Rozd lení dle MVC bude docíleno za pomoci etného mnoºství poslucha (ozna ovány jako "Listener"). Poslucha e umoº ují p edávat data potom, co uºivatel provedl n jakou akci zp tn z pohledu do adi e a tím se úpln odd lí ásti aplikace.

22 KAPITOLA 3. NÁVRH Ve výjimečných případech pohled komunikuje přímo s modelem. Zejména kvůli inicializaci kolekcí entit. Model Pohled Řadič odesílá data modelu k uložení, aktualizaci, inicializaci a volá metody modelu, které mu zpětně posílají data. odesílá data zobrazuje Pohled předává řadiči zprávy pomocí posluchačů, na základě uživatelských vstupů. Řadič Obrázek 3.4: Schéma komunikace ástí MVC

Kapitola 4 Implementace 4.1 Roº²í ení Hibernate entit Hibernate entity byly generovány p ímo z databáze. Vygenerované t ídy odpovídaly vlastnostem, které byly od entit poºadovány, aº na n které nedostatky ve vazbách, kde se v entitách musel zm nit jejich sm r. Nastaly v²ak p ípady, kdy bylo vhodné implementovat do entit i n jaké vlastní metody, i atributy. Atributy i metody musely být uvozeny anotací @Transient, která ur uje, ºe atribut i metoda je pouze pomocná a nemá být mapována na ºádný sloupec databáze. Jmenovit se jedná o tato roz²í ení: Recipe.getRating() - spo ítá hodnocení receptu na základ v²ech ohodnocení uºivatel, které jsou uloºeny v databázi - p ed pouºitím této metody je tedy nutné zinicializovat kolekci reciperatinglist receptu User.getOverallRating() - spo ítá hodnocení uºivatele, coº znamená zpr m rované hodnocení v²ech jím vloºených recept - je nutné mít inicializovanou kolekci recept uºivatele Recipe.image - jedná se o pomocný atribut, kam lze p i adit obrázek receptu a usnad uje p edávání receptu v rámci klientské aplikace - v p ípad desktopového klienta se p ed odesláním receptu serveru musí tento atribut vynulovat, protoºe obrázek, tedy objekt t ídy Image, není serializovatelný, tudíº ho nelze odeslat p es RMI 4.2 Server 4.2.1 Kongurace serveru Po startu serveru, t ída cz.cvut.fel.echef.cong.servercong na te atributy z kongura ního souboru ve svém jediném statickém inicializa ním bloku. To se d je p i nahrávání t ídy do JVM, tzn. p i nahrávání serverové ásti aplikace do aplika ního serveru. Tím je zaru eno, ºe se v²echny prom nné na tou d ív, neº s nimi za ne aplikace pracovat, tzn. p ed p ipojením k databázi nebo p ed distribucí sluºeb. JVM nahrává t ídy jak je pot eba, tzn. pokud je v jiné t íd ve statickém inicializa ním bloku odkaz na prom nnou v ServerCong, je zaru eno, ºe 23

24 KAPITOLA 4. IMPLEMENTACE JVM na te nejd ív ServerCong a tím i v²echny jeho prom nné je²t p ed pouºitím. V²echny prom nné a metody této t ídy jsou statické. 4.2.2 Nastavení RMI Dal²í t ídou v balí ku cz.cvut.fel.echef.cong, která umoº uje konguraci, je t ída cz.cvut.fel.echef.cong.registrysocketfactory. Je to t ída pouºitá v kongura ním souboru frameworku Spring applicationcontext.xml a slouºí jako generátor sí ových socket pro RMI registr. Protoºe pot ebujeme jen jeden port, na kterém bude server naslouchat, nejedná se o generátor, nýbrº ob dv metody vrací po celou dobu b hu programu konstantní ísla, která jsou uvedena v kongura ním souboru. Metoda createserversocket() vrací vºdy serverový socket naslouchající na portu 'registry_port', který je na ten z kongura ního souboru. Druhá metoda createsocket() vrací vºdy socket s portem 0, coº není pouºitelný port, ale server nikdy sám neza íná komunikaci, protoºe neexistuje ºádný p ípad, kdy by bylo pot eba, aby se server jako první pokou²el navázat komunikaci p es RMI. Metoda zde ale musí být p ítomna, protoºe to vyºaduje rozhraní java.rmi.server.rmisocketfactory, které musí t ída implementovat, aby mohla být pouºita v kongura ním souboru pro Spring framework. Zde je uveden úryvek kódu, který nastavuje registr: <bean id="registrysocketfactory" class="cz.cvut.fel.echef.config.registrysocketfactory"/> <bean id="registry" class="org.springframework.remoting.rmi.rmiregistryfactorybean"> <property name="serversocketfactory" ref="registrysocketfactory"/> <property name="clientsocketfactory" ref="registrysocketfactory"/> </bean> Tímto se denuje pouze RMI registr. Je²t je pot eba denovat samotné sluºby. Sluºba jako taková je pouze rozhraní, které je uve ejn né v registru. Denice sluºby musí také obsahovat odkaz na objekt nazývaný Bean, který tyto metody ve ejného rozhraní implementuje. Tyto metody budou jiº volány vzdálen. Mimo jiné je také nutné uvést název sluºby a registr, do kterého bude sluºba zavedena. Zde je uveden p íklad nastavení sluºby pro manipulaci s recepty: <bean id="recipebean" class="cz.cvut.fel.echef.dao.recipedao"> </bean> <bean class="org.springframework.remoting.rmi.rmiserviceexporter"> <property name="servicename" value="recipeservice"/> <property name="service" ref="recipebean"/> <property name="serviceinterface" value="cz.cvut.fel.echef.dao.recipedaointerface"/> <property name="registry" ref="registry"/> </bean> K sluºb se poté vzdálen p istupuje pomocí této adresy: rmi://ip_adresa_serveru:port_serveru/jméno_sluºby

4.3. KLIENTSKÁ APLIKACE 25 4.2.3 Nastavení Hibernate a p ipojení k databázi Konguraci Hibernate a p ipojení k databázi zprost edkovává t ída cz.cvut.fel.echef.util.hibernateutil, která ve statickém inicializa ním bloku na ítá základní konguraci z kongura ního souboru Hibernate a poté upravuje nastavení podle kongura ního souboru serveru. Je to pouze nastavení IP adresy a portu databázového serveru, jména a hesla uºivatele, který má právo zapisovat a m nit tabulky aplikace v databázi. T ída cz.cvut.fel.echef.util.hibernateutil tímto nastavením upravuje objekt t ídy com.hibernate.sessionfactory, tj. objekt, který vytvá í relace spojení serveru s DB. Tento objekt je pouºíván pouze ve t íd cz.cvut.fel.echef.dao.daodefault a v²ech t ídách, které d dí z této t ídy. DAO ze SessionFactory získává relaci Hibernate, díky ní vytvo í novou transakci s databází, provede pot ebné operace a transakci uzav e. 4.2.4 Balí ky serveru T ídy serveru jsou rozd leny do balí k podle jejich ú elu. Nejobsáhlej²í je balí ek webového klienta cz.cvut.fel.echef.web, ten obsahuje dal²í balí ky. Zde je seznam balí k v etn jejich popisu: 4.3 Klientská aplikace 4.3.1 Dialogy Tato podkapitola se zabývá tvorbou dialogových oken v aplikaci, které slouºí jako hlavní prost edek komunikace uºivatele s aplikací. Tvorba t chto dialog je v aplikaci zcela dynamická. Vytvá í se na základ toho, jaké metody t ídy cz.cvut.fel.echef.ui.dialog se volají a v jakém po adí. Argumenty t chto metod se li²í podle toho, jaký prvek by se m l do dialogu p idat. Vybraný zp sob je náro n j²í na implementaci, ale vhodný pro pozd j²í roz²i ování aplikace. Kaºdý dynamicky vloºený prvek dialogu je identikován vlastním et zcem znak. Podle tohoto et zce se dá odkazovat na prvek i po jeho vloºení a libovoln ho upravovat, nap íklad p idávat záznamy do vloºené tabulky. Instance t chto dialogových komponent jsou uloºeny v seznamu t ídy HashMap, kde klí je práv tento identikátor. Ve²keré prvky, které lze vloºit do dialogu, musí implementovat rozhraní cz.cvut.fel.echef.ui.dialogcomponent. Toto rozhraní obsahuje zejména hlavi ky metod, které upravují umíst ní prvku v dialogu, metodu která nastavuje hodnotu prvku (nap íklad text u textového pole, model dat u tabulky a podobn ). Celý dialog je rozvrºen pomocí rozloºení GridBagLayout. Implementované metody prvk pouze upravují jeho nastavení. T mto metodám se p edává objekt t ídy GridBagLayout, který je pozd ji umíst n do dialogu. Dialog umoº uje rozd lit jednotlivé prvky do sekcí. P i vytvá ení dialogu se konstruktoru udává argument, zda-li se sekce mají zobrazovat. V dialogu se vytvo í jednotlivé sekce a prvky se potom p idávají p ímo do nich. Zárove je moºné ur it, jaké prvky jsou povinné a je nutné je vyplnit. Po stisknutí tla ítka OK dialog zkontroluje, zda-li v²echny tyto prvky obsahují n jakou hodnotu. Pokud ne, zobrazí uºivateli chybovou hlá²ku se seznamem nevypln ných prvk.

26 KAPITOLA 4. IMPLEMENTACE Dialog se spou²tí a zobrazuje metodou rundialog(), která vrací jeho návratový kód. Vypln ná data obsahuje model, který lze získat zavoláním metody getmodel() po ukon ení dialogu. Model obsahuje v²echny vypln né hodnoty, na které se odkazuje pomocí identikátoru prvku. Celková práce s dialogem probíhá následovn : Vytvo í se instance t ídy cz.cvut.fel.echef.ui.dialog a pomocí jejich metod se postupn p idají sekce a jednotlivé prvky dialogu. Kaºdý prvek musí být vloºen s unikátním et zcem znak jako identikátorem. Denují se povinné pole dialogu pomocí metody setmandatory(). Dialog nemusí mít povinné ºádné pole. Pokud se jedná o edita ní dialog, nastaví se stávající hodnoty vstupním polím. Dialog se spustí metodou rundialog(). Potom co uºivatel potvrdí nebo zamítne provedné zm ny, program získá jeho model, který obsahuje v²echny hodnoty, jeº byly vypln ny. Tyto hodnoty jsou typu Object a po obdrºení je musíme p etypovat na objekty t ídy String, modely tabulek a podobné. Zde je uveden seznam v²ech prvk, které lze p idat do dialogu: Button klasické tla ítko, nastavuje se mu událost p i kliknutí na n j CategoryTable tabulka pro výb r ²títk, propojena s CategoryTree pro funk nost Drag and Drop, obsahuje vybrané ²títky CategoryTree strom ²títk, obsahuje kategorie, nebo p ísady, nebo ob tyto skupiny ²títk, propojen s CategoryTable pro funk nost Drag and Drop, obsahuje ²títky, které lze p esunout do prvku CategoryTable a tím i vybrat CheckBox klasické za²krtávací polí ko p edstavující moºnosti Ano/Ne ComboBox pole, umoº ující vybrat jednu z nabízených moºností EditableComboBox kombinace klasického textového pole a prvku ComboBox, obsahuje funkci automatického dopl ování podle textu, který uºivatel vpisuje FileChooser pole na výb r souboru obsahující tla ítko "Procházet" ImageFileChooser pole na výb r souboru obrázku InteractiveTable interaktivní tabulka PassField pole obsahující heslo, skrývá text TextArea velké více ádkové textové pole TextField klasické jedno ádkové textové pole V aplikaci jsou ve²keré dialogy vytvá eny pomocí t ídy cz.cvut.fel.echef.ui.dialogfactory. Jedná se o t ídu obsahující pouze statické metody, které slouºí jako "²ablona"a p i zavolání vracejí jiº p ipravenou instanci t ídy Dialog. Popis v²ech t chto metod lze najít v p iloºené programátorské dokumentaci.

4.3. KLIENTSKÁ APLIKACE 27 4.3.2 Architektura aplikace Cílem této podkapitoly je p iblíºit nální implementaci MVC architektury aplikace dle návrhu. 4.3.2.1 Controller ( adi ) Jádro aplikace, které provádí ve²keré operace, jeº vznikly na základ p íkazu uºivatele. Ve výjime ných p ípadech se nejedná o akce uºivatele, nýbrº o p íkazy vyvolané asova em. V aplikaci p edstavuje adi zejména instance t ídy cz.cvut.fel.echef.core.controller, která vytvá í objekty pohledu a modelu. Za dal²í ást adi e se dá povaºovat i t ída cz.cvut.fel.echef.core.main, která spou²tí samotnou aplikaci, na ítá nastavení ze soubor a denuje logování vzniklých chyb p i b hu aplikace. 4.3.2.2 Model Modelem aplikace jsou v²echny objekty pro p ístup k databázi (tzv. DAO). T ídy t chto objekt jsou umíst ny v knihovn E-chef, kterou musí obsahovat server i klientské aplikace. Instance t íd objekt pro p ístup k databázi jsou na ítány pomocí vzdáleného volání metod RMI. adi pomocí t ídy cz.cvut.fel.echef.core.beanloader na te p ed vytvo ením pohledu tyto objekty p ipojením na server a navázáním komunikace. Aplikace se m ºe na tyto objekty odkazovat pomocí identikátoru, coº je unikátní et zec znak pro kaºdý DAO. Díky n mu si zjistí název sluºby, která je dostupná na serveru, dle mapovacího souboru cong/beanmapping.cfg. Pokud se aplikace nem ºe se serverem spojit, informuje uºivatele o chyb a zobrazí kongura ní dialog aplikace, kde je moºné zm nit mimo jiné i adresu nebo port serveru. Mapovací soubor koresponduje s názvy sluºeb serveru, uºivatel by jej tedy nem l m nit. adi tedy obsahuje tém celý model aplikace. Výjimkou, kde není zcela dodrºeno rozd lení MVC, jsou t ídy modelu, jejichº instanci bylo vhodné umístit p ímo do jiného objektu. Jedná se nap íklad o t ídu cz.cvut.fel.echef.ui.categorytree, která je pouºita na n kolika místech v aplikaci. Tento strom ²títk na ítá data ze serveru sám p i jeho vytvo ení, nikoli p es adi. Dal²ím p ípadem je nap íklad inicializace objekt Hibernate. Tuto inicializaci je také vhodné provád t p ímo v objektu, který s daty pracuje. 4.3.2.3 View (pohled) Uºivatelské rozhraní, díky n muº aplikace komunikuje s uºivatelem, formátuje a zobrazuje data nebo chybové i informa ní dialogy na popud adi e. V t²ina t íd desktopového klienta tedy tvo í celý pohled. Jedná se o instaci t ídy pohledu cz.cvut.fel.echef.core.view a v²echny dal²í instance t íd v balí ku cz.cvut.fel.echef.ui, který obsahuje dal²í mnoºinu balí k. Pohled má ²est hlavních funkcí: Vytvá í úvodní obrazovku aplikace, která je zobrazena po dobu na ítání dat ze serveru Zobrazuje hlavní okno aplikace, coº je instance t ídy cz.cvut.fel.echef.ui.mainwindow

28 KAPITOLA 4. IMPLEMENTACE Vytvá í záloºky a jednotlivé ásti aplikace, které jsou od sebe odd leny. Tyto záloºky jsou p edávány hlavnímu oknu, pokud je uºivatel smí vid t. Vytvá í a zobrazuje dialogová okna, díky kterým uºivatel interaguje s aplikací (p idává recept, upravuje nastavení aplikace, apod.). P i ukon ení událostí zobrazuje jejich výsledek, chybové nebo informa ní hlá²ky. P edává uºivatelské vstupy adi i, který je vyhodnocuje a zpracovává. 4.3.3 Záloºky aplikace Pohled aplikace obsahuje n kolik ástí li²ící se svou funkcí. Jedná se o hlavní okno, jeº samo o sob obsahuje n které funkce a o záloºky, které jsou od sebe navzájem odd leny a komunikují spolu pomocí poslucha p es instanci t ídy cz.cvut.fel.echef.core.view, která je vytvá í, nebo i p es adi, pokud se jedná o operace vyºadující komunikaci se serverem. Zde je uveden seznam v²ech záloºek aplikace s popisem jejich funkcí: WelcomeTab uvítací obrazovka aplikace, obsahuje odkazy na nejlépe hodnocené a nejnov j²í recepty aplikace RecipeTab záloºka, která zobrazuje uºivateli recept, jeho komentá e a hodnocení, umoº uje editaci, odstran ní, tisk receptu a dal²í PickRecipeTab umoº uje vybrat recept pomocí ²títk a zobrazit ho FavouriteRecipesTab (pouze pro p ihlá²eného uºivatele) obsahuje seznam recept, které si uºivatel ozna il jako oblíbené MyRecipesTab (pouze pro p ihlá²eného uºivatele) obsahuje seznam recept, které uºivatel sám vloºil, umoº uje odstranit vybraný vlastní recept CategoryAdministrationTab (pouze pro administrátora) umoº uje spravovat íselníky kategorií a ingrediencí a obsahuje seznam neza azených ingrediencí, které byly p idány uºivateli UserAdministrationTab (pouze pro administrátora) zobrazuje seznam uºivatel v aplikaci, dovoluje vytvo it nového administrátora ze stávajícího uºivatele 4.3.4 Kongurace aplikace Nastavení aplikace probíhá je²t p ed vytvo ením adi e, po nastavení logování, kv li chybám v konguraci, které je vhodné také logovat. Aplikace na ítá ty i kongura ní soubory: cong/beanmapping.cfg soubor obsahující mapování vzdálených objekt na názvy sluºeb serveru podle unikátního et zce znak

4.3. KLIENTSKÁ APLIKACE 29 cong/cong.cfg kongura ní soubor, který nastavuje adresu a port serveru k n muº se aplikace p ipojuje a jazyk aplikace (popis nastavení je uveden v instala ní p íru ce - P íloha A) soubor jazyka z adresá e bundles obsahuje p eklady jednotlivých klí na jazyk, který ur uje název souboru s p íponou ".lang"(cz.lang, en.lang, atd.) cong/credentials.cfg obsahuje za²ifrované p ihla²ovací údaje, které si uºivatel p i p ihla²ování nechal aplikací uloºit V²echny kongura ní soubory jsou ve formátu Java Property. Samotnou konguraci provádí t ída cz.cvut.fel.echef.core.congconstraints svou statickou metodou congure(). Ta na te v²echny hodnoty z kongura ního souboru cong.cfg a nastaví podle nich statické parametry t ídy CongConstraints. Pokud je n jaká funkce aplikace závislá na konguraci, m ºe se odkázat na parametr této t ídy. 4.3.5 Lokalizace Hodnoty slovníku jsou na ítány p i spou²t ní aplikace, stejn jak je tomu u kongurace. Proto je nutné p i zm n jazyka, aplikaci restartovat. V²echny texty v aplikaci, pokud se nejedná o data z databáze, které nejsou lokalizované, jsou p ekládány pomocí t ídy cz.cvut.fel.echef.core.util. Tato t ída obsahuje statickou metodu translate(), která podle klí ového slova vyhledá et zec v nastaveném jazyce. Uºivatel m ºe nastavit pouze jazyk, jehoº slovník je umíst n v adresá i bundles, ve tvaru XX.lang, kde XX je dvoupísmenný kód jazyka. Pokud aplikace obsahuje tento slovník a uºivatel jej nastaví, aplikace podle této lokalizace formátuje i datum pomocí metody getformatteddate(). 4.3.6 Výb r ²títk Vybírání ²títk v aplikaci bylo navrºeno tak, aby struktura stromu, ve které mají být ²títky organizované, byla co nejvíce p ehledná. K tomu poslouºily t ídy JTree knihoven Swing a t ída cz.cvut.fel.echef.ui.dialog.components.interactivetable, od nichº d dí t ídy: cz.cvut.fel.echef.ui.dialog.components.categorytable tabulka, která obsahuje vybrané ²títky cz.cvut.fel.echef.ui.dialog.components.categorytree strom, který nabízí zatím nevybrané ²títky 4.3.7 Interaktivní tabulka Jedná se o vlastní komponentu aplikace pouºívající n které prvky z knihoven Swing. ádky tabulky se skládají ze samotných hodnot a objektu na pozadí, p ípadn tla ítka na odstran ní ádku. Hodnoty této tabulky mohou být jak textové et zce, tak libovolné objekty d dící od t ídy JPanel. Tabulka z textových et zc vytvá í objekt JLabel, takºe pozd ji pracuje i tak pouze s objekty d dícími od JPanel. D vodem ke vzniku této komponenty byl p edev²ím nedostatek funkcí tabulky JTable z knihoven Swing a jejich sloºitá kongurace.

30 KAPITOLA 4. IMPLEMENTACE 4.3.8 Propojení prvk CategoryTree a CategoryTable Tyto dva prvky je nutné pouºívat vºdy spole n. CategoryTree jako strom, ze kterého lze vybrat ²títky a CategoryTable jako seznam jiº vybraných ²títk. Pro jednoduchost byla do prvku CategoryTable zavedena metoda connecttocategorytree(), která spojí tabulku se stromem. Tím bylo docíleno, ºe vºdy, pokud propojíme n které tyto dva prvky, máme jistotu, ºe pokud je do tabulky p idána za pomoci metody Drag and Drop n jaká kategorie nebo ingredience, odstraní se tato poloºka ze stromu, aby nebylo moºné vybírat prvky duplicitn. Naopak, pokud z tabulky odstraníme n jaký ²títek, obnoví se v p ipojeném stromu s tím, ºe bude zachována jeho pozice ve stromu. Vybírání prvk respektuje kategorizaci ²títk. To znamená, ºe pokud ze stromu vybereme ²títek A, který je pod ízeným ²títkem vzhledem k ²títku B, coº má za následek p idání ²tíku A do tabulky a následn vybereme ²títek B, odstraní se ²títek A, protoºe zvolením ²títku B vybereme zárove i v²echny jeho pod ízené ²títky (viz. kapitola Návrh, sekce títky). P i vytvá ení stromu nebo tabulky ²títk m ºeme ur it, jaké typy ²títk bude prvek zobrazovat. Je moºné zvolit jednu z t chto mnoºin: ONLY_INGREDIENTS strom obsahuje pouze ingredience ONLY_CATEGORIES strom obsahuje pouze kategorie ONLY_INGREDIENT_GROUPS strom obsahuje pouze skupiny ingrediencí ALL strom obsahuje v²e, tabulka zobrazuje typ ²títku U stromu m ºeme dále ur it, jaké typy ²títk bude moºné vybrat: DRAG_ALL je moºné vybrat v²echny ²títky, které strom zobrazuje DRAG_ONLY_INGREDIENTS je moºné vybrat pouze ingredience, nikoli jejich skupiny NO_DRAG není moºné vybrat nic, strom je pouze informativní V²echny prvky stromu ²títk a v²echny objekty na pozadí ádk interaktivní tabulky jsou instance t ídy cz.cvut.fel.echef.ui.listitem. Tato t ída byla zavedena hlavn kv li sjednocení objekt, které lze p emis ovat technikou Drag and Drop. Instance této t ídy m ºe obsahovat svou ikonu a mít sv j název, který vrací jeho p epsaná metoda tostring(). Tento zp sob byl zvolen, protoºe je pak snadné umís ovat tyto objekty p ímo do instance t ídy JTree a jejich potomk. Strom, který objekt zobrazuje, pouºívá po p epsání n kterých jeho metod práv ikonu z objektu ListItem a jako popisek jeho uzl pouºívá práv textový et zec, který vrací metoda tostring(). K získávání t chto objekt slouºí statická metoda této t ídy getlistitem(). Ta vytvá í nový objekt t ídy ListItem, pokud je²t neexistuje, a zabalí do n j p ená²ený objekt, nap íklad kategorii, ingredienci, nebo jen jednoduchý textový et zec. Nov vzniklý objekt si ukládá, aby p i dal²ím volání této metody nevytvá ela dal²í objekt, ale pouºila d íve vytvo ený. Tím se zejména p i velkém po tu ²títk u²et í pam vyuºívaná stromy ²títk, které mají v celé aplikaci stejná data.

Kapitola 5 Testování Obsahem této kapitoly je popis test, kterými byla ov ena správná funk nost a stabilita aplikace. 5.1 Zát ºový test Tento test spo íval v napln ní databáze velkým mnoºstvím testovacích dat a následném testu v²ech funkcí aplikace. Test byl vzhledem k velkému objemu dat zam en na stabilitu a rychlost aplikace. 5.1.1 P íprava Databáze byla napln na cca 30 000 náhodnými záznamy, kde zhruba 10 000 záznam byly samotné entity receptu. Data byla vloºena do v²ech tabulek aplikace, p i emº se muselo dbát na referen ní integritu databáze. Po nahrání dat bylo spu²t no n kolik instancí desktopového klienta aplikace, pomocí nichº se ov ovala její stabilita a rychlost. Tito klienti se p ipojovali vzdálen, instance aplikací tedy byly spu²t ny na r zných po íta ích. 5.1.2 Výsledek A koliv aplikace m la del²í dobu odezvy na na tení vybraných recept, nenastaly ºádné problémy se stabilitou. Reak ní doba p i výb ru recept pomocí ²títk byla tém stejná jak p i jedné, tak i více p ipojených klientských aplikací, které vybíraly recepty ve stejný okamºik. Pokud by byl poºadován v t²í výkon aplikace, bylo by vhodné rozd lit server na více mezi sebou komunikujících server. 31

32 KAPITOLA 5. TESTOVÁNÍ 5.2 Simulace chybových událostí Podstatou testu bylo nasimulovat v²echny chyby, které mohou vzniknout p i b ºném pouºívání aplikace. Tyto události jsou: Nesprávné nastavení klientské aplikace P í ina: Uºivatel aplikace nesprávn nastaví adresu nebo port serveru, ru n nesprávn upraví kongura ní soubor, nebo ho odstraní, p ípadn p esune jinam neº do ur eného adresá e. Akce: P i nesprávné konguraci aplikace zobrazí chybu a nabídne uºivateli kongura ní dialog, aby mohl toto nastavení upravit. P i nenalezení kongura ního souboru aplikace pouze zobrazí chybu o jeho absenci. Výsledek testu: OK Chyba v komunikaci s protistranou P í ina: Pod touto chybou se skrývá jakýkoliv problém s komunikací se serverem. Nastává p i úplném odpojení sít, pádu serveru, nebo ostatních chybách v p enosu dat. Akce: Aplikace zobrazí uºivateli chybovou zprávu. Uºivatel musí aplikaci ukon it, znovu spusit a p ípadn se p ihlásit. Aplikace spojení sama neobnovuje. Jiº otev ené recepty lze p i selhání komunikace stále prohlíºet. Výsledek testu: OK ve v²ech b ºných p ípadech, kdy chyba komunikace m ºe nastat. Chybné uºivatelské vstupy P í ina: Uºivatel nesprávn vyplní n které poloºky, které po n m poºaduje dialog. Akce: Pokud je poloºka dialogu povinná, je nutné jí vyplnit. Pokud tak uºivatel neu iní, dialog zobrazí chybovou hlá²ku (viz. Dialogy, kapitola Implementace). U n kterých poloºek v aplikaci je kontrola provád na odd len. Jedná se nap íklad o uvedený e-mail p i p ihla²ování, kdy p i jeho nesprávném vypln ní aplikace uºivatele upozorní a vyºaduje opravu. Výsledek testu: OK u v²ech kontrolovaných vstupních polí

5.3. AKCEPTAƒNÍ TESTY 33 5.3 Akcepta ní testy Tyto testy jsou denovány zadáním práce. Jedná se o test v²ech nefunk ních i funk ních poºadavk na aplikaci. Jejich úsp ²nost je podmínkou uznání této práce. Aplikace úsp ²n pro²la v²emi akcepta ními testy a spl uje v²echny poºadavky uvedené v zadání. Funk ní poºadavky byly dopln ny o tyto poloºky: Hodnocení recept P idávání komentá k recept m Tisk recept Administrátor aplikace m ºe povy²ovat b ºné uºivatele na dal²í administrátory

34 KAPITOLA 5. TESTOVÁNÍ

Kapitola 6 Záv r Cílem této práce bylo vytvo it systém pro sdílení recept koncipovaný jako aplikace klient/server, podílet se na vývoji serverové ásti a samostatn navrhnout a zcela implementovat desktopovou klientskou ást. Bylo nutné dbát na p ístupnost aplikace pro ²irokou ve ejnost. Sou ástí systému je i webová klientská aplikace, která byla vyvíjena paraleln s tímto projektem. 6.1 Postup p i vývoji Zpo átku bylo nutné ujasnit si celkovou architekturu aplikace a poºadavky na funkce systému. Na tomto úkolu bylo spolupracováno s vedoucím práce a v rámci serverové ásti i s mým kolegou, který m l za úkol zhotovit webového klienta. Analýza i tvorba aplikace byla rozd lena do dvou hlavních ástí podle architektury klient/server. Jejich vývoj probíhal do jisté doby paraleln, nejprve serverovou ástí, poté klientskými. P i vývoji klientských ástí probíhaly i men²í zm ny v ásti serverové. Po p edání poºadavk jsme se mohli posunout k dal²ímu bodu - analýza problému. V této chvíli bylo zapot ebí do detailu provést rozbor zadání: Volba vhodných technologií pro server Analýza funk ních poºadavk a vytvo ení rolí Analýza p ípad uºití aplikace Samostatn i analýza architektury desktopového klienta Po spln ní t chto bod musel být proveden návrh serverové ásti, kv li nutnosti denovat klientské rozhraní serveru. Návrh probíhal v t chto fázích: Návrh pravd podobného nasazení aplikace Návrh schématu datového úloºi²t podle entit, které bude nutné v aplikaci pouºívat Návrh rozhraní pro klientské aplikace 35

36 KAPITOLA 6. ZÁV R Samostatn provést návrh struktury desktopové klientské aplikace rozd lením dle architektury MVC Modely aplikace nebyly po celou dobu jejich existence xní. Drobné zm ny (zejména ve schématu databáze) vznikaly i b hem implementa ní fáze. Pomocí t chto p ipravených podklad jiº bylo moºné p ejít na dal²í krok - Implementace. Implementace serverové ásti probíhala op t spole n v t chto krocích: Vygenerování Hibernate entit z databáze a jejich úprava pro snadn j²í dal²í implementaci Implementace jednotlivých rozhraní a t íd, které dohromady tvo í celé klientské rozhraní distribuované p es RMI Umíst ní celého klientského rozhraní a entit Hibernate do spole né knihovny, pot ebné pro v²echny klientské aplikace Po vytvo ení klientského rozhraní jiº bylo moºné za ít implementovat i komunikující ást desktopového klienta - jeho model. Celá implementace probíhala v t chto krocích: Denice chyb, které mohou nastat p i b hu klienta a následná implementace logování a chybových notikací Implementace základní obrazovky a rozvrºení poºadovaných funkcí na jednotlivé záloºky Implementace p ipojení k serveru Implementace v²ech vlastních prvk v aplikaci Vytvo ení systému pro tvorbu dialogových oken Po úsp ²né implementaci systému bylo moºné p ejít na testování, které zaru ilo, ºe aplikace spl uje v²echny poºadavky stanovené vedoucím práce. 6.2 Zhodnocení pr b hu vývoje Technologie zvolené na za átku projektu se jeví jako vhodné pro tento p ípad. Znateln zjednodu²ily implementaci celého systému. Nedostatek p i pouºití technologie RMI je nedostate ná dokumentace, zejména pokud tento druh propojení serveru a klienta pouºijeme spolu s Hibernate. B hem implementace asto vznikaly problémy s inicializací kolekcí entit Hibernate. Dal²í p ekáºkou byl nedostate ný popis výjimek, které nastaly p i práci s RMI. Problémy zp sobující tyto výjimky se potom nedaly zcela snadno e²it a asto bylo nutné najít jiné východisko. I p es tyto men²í problémy jsem s aplikací velmi spokojen. Spl uje v²e, co jsem od ní o ekával.

6.3. DAL Í VÝVOJ SYSTÉMU 37 6.3 Dal²í vývoj systému Klientské rozhraní serveru je navrºeno tak, aby bylo jednoduché vytvá et dal²í aplikace, které mohou se serverem komunikovat. Proto je moºné do systému p idávat dal²í klientské aplikace, které jsou schopny pouºívat RMI jazyku Java. Dal²í vývoj systému by se tedy mohl ubírat tímto sm rem. Díky architektu e MVC, systému dialogových oken a rozd lení logických celk do záloºek, je celkem snadné upravovat desktopovou klientskou aplikaci a postupn roz²i ovat její funkce, kterými by v budoucnu mohly být nap íklad zobrazování zajímavostí k exotickým ingrediencím, ukládání receptu do formátu XML nebo vkládání více obrázk k receptu.

38 KAPITOLA 6. ZÁV R

Literatura [1] LaTeX online manuál http://www.cstug.cz/latex/lm/frames.html, stav z 1. 12. 2010 [2] K336 Info pokyny pro psaní bakalá ských prací https://info336.felk.cvut.cz/clanek.php?id=504, stav z 1. 12. 2010 [3] Jak na LaTeX: úvod http://www.root.cz/clanky/jak-na-latex-uvod/, stav z 1. 12. 2010 [4] Remoting and web services using Spring http://static.springsource.org/spring/docs/2.0.x/reference/remoting.html, stav z 1. 12. 2010 [5] Hibernate reference documentation http://docs.jboss.org/hibernate/core/3.6/reference/en-us/html_single/, stav z 1. 12. 2010 [6] Apache Tomcat 6.0 - Documentation http://tomcat.apache.org/tomcat-6.0-doc/index.html, stav z 1. 12. 2010 [7] Spring by examples - RMI http://cosminaru.ro/blog/2006/11/02/spring-by-examples-rmi/, stav z 1. 12. 2010 [8] J2EE - Java 2 Enterprise Edition http://artax.karlin.mff.cuni.cz/~ebik/nju/linuxem/j2ee/j2ee.html, stav z 1. 12. 2010 [9] Free Web Icons http://www.freeiconsweb.com, stav z 1. 12. 2010 39

40 LITERATURA

P íloha A Instala ní a kongura ní p íru ka Tato p íloha obsahuje postupy pro správnou instalaci a konguraci aplikace. A.1 Instalace A.1.1 Server V této ásti jsou uvedeny postupy pro instalaci serverové ásti systému. Po instalaci je nutné p ejít ke konguraci a nastavit p íslu²né hodnoty. Instala ní soubory serveru p iloºené na CD jsou: echef.war - Soubor obsahující zkompilovaný kód serveru, tento soubor se nasazuje do aplikace Tomcat 6.0 cong.cfg - Kongura ní soubor serveru ddl.sql - Skript pro vytvo ení schématu databáze A.1.1.1 Poºadavky aplikace Zde jsou uvedeny poºadavky, které je nutné splnit p ed instalací E-chef serveru: Instalace MySQL serveru - Databáze, která bude obsahovat datové schéma E-chef, p i emº není nutné, aby tato databáze byla nainstalována na stejném po íta i jako aplika ní server (ke stáhnutí zde: http://dev.mysql.com/downloads/mysql/) Instalace JRE - Java Runtime Environment, nutné pro spou²t ní aplikací programovaných v jazyku Java (ke stáhnutí zde: http://www.java.com/en/download/manual.jsp) Instalace serverové aplikace Tomcat 6.0 s podporou technologie "autodeploy"- voln dostupný aplika ní server pro Java aplikace (ke stáhnutí zde: http://tomcat.apache.org/download-60.cgi). Pokud server pouºívá rewall, je nutné povolit p íchozí komunikaci na portech >= 1024 a portu, na kterém bude naslouchat RMI registr 41

42 P ÍLOHA A. INSTALAƒNÍ A KONFIGURAƒNÍ P ÍRUƒKA A.1.1.2 Instalace databáze P ed samotnou instalací je nutné p ipravit databázi pro aplikaci, v níº je vhodné vytvo it zvlá² uºivatele, který bude mít právo p istupovat pouze ke schématu aplikace. Tohoto uºivatele vytvo íme po p ipojení k databázi uºivatelem, který má právo vytvá et dal²í uºivatele p íkazem: CREATE USER 'uzivatel' IDENTIFIED BY 'heslo'; Hodnoty uzivatel a heslo mohou být nahrazeny jinými libovolnými hodnotami. Po vytvo ení uºivatele je nutné vytvo it schéma pro uºivatele p íkazem: CREATE DATABASE databaze; Jméno databáze databaze zde m ºe být nahrazeno libovolnou hodnotou. Dal²ím krokem instalace databáze je p id lení práv vytvo enému uºivateli. Pod ú tem uºivatele, který má právo na p id lování práv ostatním uºivatel m spustíme tento p íkaz: GRANT ALL PRIVILEGES ON databaze.* TO uzivatel; Hodnoty databaze a uzivatel nahradíme p íslu²nými hodnotami, které jsme zvolili v p edchozích krocích. P ihlásíme se za vytvo eného uºivatele a ve vytvo ené databázi, do které se p epneme pomocí p íkazu USE databaze;, ve kterém nahradíme hodnotu databaze za p íslu²né jméno databáze a spustíme p iloºený SQL skript ddl.sql. V kongura ním souboru serveru poté upravíme prom nné pro p ipojení k databázi podle zvolených hodnot (viz. Kongurace). A.1.1.3 Instalace serveru Instalaci je moºné provést v t chto krocích: Zkopírovat soubor echef.war do adresá e webapps v domovském adresá i aplikace Tomcat 6.0. Tento soubor je p iloºen na CD. P ed zkopírováním je moºné soubor p ejmenovat, ímº se zm ní i název aplika ního kontextu webové stránky aplikace na název souboru. Musí se mu av²ak ponechat p ípona.war. Vytvo it adresá /etc/echef v p ípad Linuxové varianty, C:\echef v p ípad varianty pro Windows. Zkopírovat kongura ní soubor cong.cfg do vytvo eného adresá e a upravit ho podle vlastních pot eb (viz. Kongurace). Soubor je p iloºený na CD. Tomcat musí mít moºnost íst z tohoto souboru.

A.2. KONFIGURACE 43 A.1.2 A.1.2.1 Desktopový klient Instalace Klientskou aplikaci není nutné ºádným zp sobem instalovat, na po íta i jí lze ihned spustit. Aplikace má jen jeden poºadavek: p edem nainstalované JRE - Java Runtime Environment (ke stáhnutí zde: http://www.java.com/en/download/manual.jsp). První zaregistrovaný uºivatel bude vytvo en s administrátorskými právy. A.2 Kongurace A.2.1 Server Parametry serveru jsou nastavovány pomocí kongura ního souboru cong.cfg, který je umíst n v adresá i /etc/echef v Linuxové variant, nebo C:\echef ve variant pro Windows. Jelikoº je kongura ní soubor na ítán p i zavád ní soubor aplikace do serveru Tomcat, je nutné, aby p i kaºdé zm n kongurace byla aplikace znovu nasazena, nebo server Tomcat restartován. Kongura ní soubor obsahuje tyto prom nné: server_ip_address - IP nebo hostname sí ového rozhraní, které bude pouºito pro p ipojení vzdálených klient registry_port - port RMI registru, p ipojují se k n mu klienti db_ip_address - IP adresa databáze db_port - port, na kterém naslouchá databáze db_database_name - jméno databáze, která je pouºita pro tabulky E-chef db_user - uºivatel, který má práva zapisovat/ íst ve zvolené databázi db_password - heslo zvoleného uºivatele databáze Prom nné jsou uloºeny v tomto formátu, vºdy jedna na ádek: název_prom nné = hodnota A.2.2 Klient Konguraci klientské aplikace nemusí uºivatel provád t manuáln úpravou kongura ního souboru. Aplikace dovoluje zobrazit kongura ní dialog, který toto nastavení upraví. Pokud se klient nem ºe p ipojit k serveru, automaticky tento dialog nabídne.

44 P ÍLOHA A. INSTALAƒNÍ A KONFIGURAƒNÍ P ÍRUƒKA A.2.2.1 Slovníky Pro p idání moºnosti p ekladu aplikace do dal²ích jazyk lze nahrát soubor slovníku do pod adresá e bundles. Soubor musí mít název XX.lang, kde XX je dvoupísmený kód jazyka. Obsah souboru musí být ve formátu Java Property, tzn. soubor obsahuje prom nné odd lené koncem ádku zapsané tímto zp sobem: klí ové_slovo = p eklad

P íloha B Uºivatelská p íru ka Obsahem této p ílohy je jednoduchá uºivatelská dokumentace popisující zp soby pouºívání desktopového klienta E-chef. B.1 Popis uºivatelského rozhraní Celé uºivatelské rozhraní je rozd leno do t chto ástí: B.1.1 Hlavní menu aplikace Uºivatelské menu Záloºky aplikace Hlavní menu Toto menu se vyskytuje v horní ásti hlavního okna a poskytuje pouze základní funkce aplikace: B.1.2 P idání receptu P ihlá²ení/odhlá²ení, registrace a zm na hesla uºivatele Kongurace aplikace Uºivatelské menu Je umíst no v pravé ásti hlavního okna a poskytuje tyto funkce: P idání receptu P ihlá²ení/odhlá²ení a registrace uºivatele Zobrazuje nedávno nav²tívené recepty Zobrazuje vºdy t i náhodn vybrané recepty, obnovující se po jedné minut 45

46 P ÍLOHA B. UšIVATELSKÁ P ÍRUƒKA B.1.3 Záloºky aplikace Záloºky hlavního okna p edstavují odd lené celky s charakteristickým ú elem. P epína záloºek je umíst n pod hlavním menu a obsahuje tyto záloºky: Start - Uvítací záloºka aplikace Recept - Zobrazený recept Výb r receptu - Záloºka pro vyhledávání recept Oblíbené recepty - Recepty uºivatele ozna ené jako oblíbené Mé recepty - Vlastní recepty uºivatele Administrace ²títk - Záloºka pro správu ²títk, viditelná pouze administrátory Administrace uºivatel - Záloºka pro správu uºivatel aplikace, viditelná pouze administrátory Obrázek B.1: Popis ástí hlavního okna aplikace B.2 Záloºka zobrazení receptu Záloºka zobrazuje recept, jeho ingredience, p i azené ²títky, postup p ípravy a dal²í informace. Popis menu je zobrazen na dal²í stránce, popis celé záloºky je zobrazen zde:

B.3. ZÁLOšKA VÝB RU RECEPTU 47 Obrázek B.2: Popis záloºky receptu B.3 Záloºka výb ru receptu Hlavní a jedinou funkcí této záloºky je výb r recept pomocí ²títk. títkem se rozumí ingredience, kterou recept obsahuje, nebo jejich skupina a kategorie, do kterých recept spadá. Na jeden z nalezených recept lze p ejít kliknutím na ádek receptu. B.4 Výb r ²títk Pro výb r ²títk jsou k dispozici vºdy dv komponenty. Strom nabízených ²títk a tabulka vybraných ²títk. Kategorie nebo skupiny p ísad lze ve stromu jednodu²e rozbalit poklepáním na daný ²títek. Výb r ²títku se provádí jednoduchým p esunutím (p etaºením) ²títku my²í na tabulku. Tabulka, na které by se m l ²títek upustit, je vºdy zvýrazn na po zdvihnutí ²títku ze stromu. títek lze z tabulky odebrat kliknutím na jediné tla ítko na ádku ²títku - Odebrat. B.5 Nápov da aplikace V celé aplikaci je moºné pouºít nápov du kliknutím na ikonu Ikona je zobrazena jen na místech, které nápov du podporují.

48 P ÍLOHA B. UšIVATELSKÁ P ÍRUƒKA Obrázek B.3: Popis menu záloºky receptu B.6 B ºné akce uºivatele Cílem této ásti je popsat postupy nejb ºn j²ích inností uºivatele v aplikaci. B.6.1 Registrace nového uºivatele Registrace je jednoduchou záleºitostí. Sta í otev ít registra ní dialog pomocí tla ítka hlavního menu Uºivatel/Registrace. Po zobrazení dialogu je nutné vyplnit v²echny jeho hodnoty. Pokud nastane chyba, aplikace uºivatele upozorní a chybu mu popí²e. Po úsp ²né registraci se uºivatel m ºe p ihlásit pomocí uvedeného e-mailu a hesla tla ítkem Uºivatel/P ihlá²ení v hlavní nabídce nebo tla ítkem P ihlásit v uºivatelském menu. B.6.2 P idání receptu Pro p idání receptu musí být uºivatel p ihlá²en. Dialog pro p idání receptu lze otev ít tla ítkem Recept/P idat recept v hlavní nabídce nebo tla ítkem P idat recept v uºivatelském menu. Po kliknutí se otev e dialog nového receptu. Poloºky ozna ené vyk i níkem musí být vypln ny.

B.6. B šné AKCE UšIVATELE 49 Obrázek B.4: Popis záloºky výb ru receptu Aº budou vypln ny alespo údaje ozna ené jako povinné, m ºeme p ejít na dal²í krok P ísady, kde vyplníme v²echny p ísady, které recept obsahuje. P ed samotným p idáním je doporu eno p e íst si nápov du kliknutím na ikonu informace v dialogu. Po p idání minimáln jedné p ísady lze p ejít na krok títky tla ítkem Dále. V tomto kroku ozna íme recept ²títky. títky se vybírají zp sobem uvedeným v textu vý²e ( ást Výb r ²títk ). B.6.3 Hodnocení receptu Recepty ostatních uºivatel je moºné hodnotit. Toto hodnocení potom poslouºí da²ím uºivatel m jako informace o kvalit receptu. Recept lze ohodnotit kliknutím na hv zdi ku v informa ní tabulce na záloºce receptu. Po et vybraných hv zdi ek ur uje spokojenost s receptem. Hodnotit je povoleno pouze jednou a pouze recepty ostatních uºivatel, nikoli své. B.6.4 Komentování receptu Pro p idání komentá e k receptu je nutné otev ít okno komentá receptu. Tla ítko pro jeho otev ení se nachází na záloºce receptu v nabídce dodate ných informací. Po otev ení tohoto okna lze p idat nový komentá kliknutím na tla ítko P idat komentá nebo odpov d t na existující kliknutím na tla ítko Odpov d t. B.6.5 Tisk receptu Recept je moºné vytisknout pomocí tla ítka menu záloºky receptu Tisk receptu. Po stisknutí tohoto tla ítka se otev e standardní dialog pro úpravu nastavení tisku a po jeho potvrzení se

50 P ÍLOHA B. UšIVATELSKÁ P ÍRUƒKA Obrázek B.5: Dialog p idání receptu - Krok Informace zobrazí náhled stránky, která bude vytisknuta. Samotný tisk zahájíme kliknutím na tla ítko Tisk tohoto náhledu. B.6.6 Administrace kategorií Záloºka administrace kategorií obsahuje t i prvky. Strom kategorií, strom ingrediencí a tabulku neza azených ingrediencí. Pro editaci stromu lze pouºít pravé tla ítko my²i t mito zp soby: Kliknutí na kategorii ve stromu kategorií Editace kategorie P idání podkategorie Kliknutí do prázdné (bílé) plochy stromu kategorií Editace skupiny kategorií nebo p idání nové P idání kategorie, která není podkategorií Kliknutí na skupinu ingrediencí ve stromu ingrediencí Editace skupiny ingrediencí P idání ingredience P idání podskupiny ingrediencí

B.7. CHYBY V APLIKACI 51 Obrázek B.6: Dialog p idání receptu - Krok P ísady Kliknutí na ingredienci ve stromu ingrediencí Editace ingredience, v níº m ºeme upravit i v²echny skupiny ingredience Kliknutí do prázdné (bílé) plochy stromu ingrediencí P idání skupiny ingrediencí, která není podskupinou títky lze libovoln p esouvat mezi nad azenými ²títky pouze v rámci jednoho stromu. P esun ve stromu kategorií ²títek pouze p esune, p esun ve stromu ingrediencí zkopíruje p ená²enou ingredienci nebo p esune p ená²enou skupinu ingrediencí. Pro úplnou administraci skupin ingredience je moºné editovat tuto ingredienci. V dialogu bude zobrazena i správa jejích skupin. Neza azené ingredience lze p etahovat z tabulky do stromu ingrediencí do p edem p ipravených skupin. Detaily administrace jsou uvedeny v nápov d aplikace v záloºce administrace kategorií. Nápov du je moºné zobrazit kliknutím na tla ítko nápov dy této záloºky. B.7 Chyby v aplikaci Aplikace m ºe po dobu jejího spu²t ní zobrazit n kolik chyb, které mohou nastat i p i jejím správném pouºívání. Tato ást obsahuje seznam n kterých z nich a zp sob, jak je e²it. P ípadné detaily chyb aplikace ukládá do logovacích soubor v adresá i aplikace.

52 P ÍLOHA B. UšIVATELSKÁ P ÍRUƒKA Obrázek B.7: Dialog p idání receptu - Krok títky Chyba: Chyba komunikace se serverem. P í ina: Náhlé ukon ení spojení se serverem z d vodu odpojení klientského po íta e od sít nebo pádu serveru. e²ení: Zkontrolujte p ipojení k síti a restartujte aplikaci. Chyba: Nastala výjimka. P í ina: Jedná se o chybu (bug) v aplikaci. e²ení: Restartujte aplikaci a va²í akci zopakujte. Chyba: N která povinná pole nebyla vypln na. P í ina: Dialog obsahuje povinná pole, která musí být vypln na p ed jeho potvrzením. Tato pole jsou ozna ena vyk i níkem. Pokud dialog neobsahuje ozna ení povinných polí, je moºné, ºe jsou povinná v²echna pole. U n kterých prvk vypln ní znamená vybrání alespo jedné poloºky. e²ení: Chybová notikace vypí²e seznam polí, která je nutno vyplnit. Vypl te tato pole a akci opakujte. Chyba: K serveru se nelze p ipojit. P í ina: Chyba se zobrazuje p i startu aplikace a indikuje, ºe adresa a port serveru, které jsou uvedeny v kongura ním souboru, odkazují jinam neº na poºadovaný server, nebo je server nedostupný.

B.7. CHYBY V APLIKACI 53 Obrázek B.8: Náhled tisknuté stránky receptu e²ení: Po zobrazení této chyby nabídne aplikace kongura ní dialog, ve n mº je moºné upravit adresu serveru a port, na kterém naslouchá. Zjist te si správnou adresu a port serveru a poté tyto hodnoty vypl te do kongura ního dialogu. Pokud jsou zadané hodnoty vypln ny správn, zkuste se p ipojit pozd ji. Obrázek B.9: Ukázka chyby aplikace