Na tomto místě bude oficiální zadání vaší práce

Transkript

1 Na tomto místě bude oficiální zadání vaší práce Toto zadání je podepsané děkanem a vedoucím katedry, musíte si ho vyzvednout na studiijním oddělení Katedry počítačů na Karlově náměstí, v jedné odevzdané práci bude originál tohoto zadání (originál zůstává po obhajobě na katedře), ve druhé bude na stejném místě neověřená kopie tohoto dokumentu (tato se vám vrátí po obhajobě). i

2 ii

3 České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačové grafiky a interakce Bakalářská práce Informační systém pro restaurační zařízení Petr Vích Vedoucí práce: Ing. Radek Malinský Studijní program: Softwarové technologie a management, Bakalářský Obor: Web a multimedia květen 2014

4 iv

5 v Poděkování Děkuji Ing. Radku Malinskému, vedoucímu bakalářské práce, za cenné rady a podněty k řešené problematice. Dále bych chtěl velmi poděkovat své rodině a přátelům za morální podporu v průběhu studia i při psaní bakalářské práce.

6 vi

7 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

8 viii

9 Abstract The bachelor thesis deals with the design, implementation and subsequent deployment of the information system for restaurants in the production version. When designing information system was a major emphasis on the operation of the restaurant, cooking, drink and watching the raw materials needed for their preparation. In addition, the proposal also includes features for tracking orders and their status, time sheets of employees and monitor activities performed in the system. In the section describing the implementation are summarized technologies have been used for programming. The system is designed using a client-server architecture. Abstrakt Bakalářská práce se zabývá problematikou návrhu, implementace a následného nasazení informačního systému pro restaurační zařízení do produkční verze. Při návrhu informačního systému byl kladen hlavní důraz na provoz restaurace, přípravu pokrmů a nápojů, dále na sledování surovin potřebných pro jejich přípravu. Návrh také zahrnuje funkce pro sledování objednávek a jejich stavů, pracovní výkaz zaměstnanců a monitoring činností, které v systému vykonali. V části popisující implementaci jsou shrnuty technologie, které byly k programování použity. Systém je navržen pomocí architektury Klient-Server. ix

10 x

11 Obsah 1 Úvod 1 2 Popis problému, specifikace cíle Cíle projektu Analýza Uživatelské role Požadavky na informační systém Funkční požadavky Obecné požadavky Režim objednávek Správa systému Správa skladu Současná řešení Restaurace Chata Polanka Restaurace U Báby Šubrový - Kokořínský důl Zámecká restaurace Nové Hrady Restaurace v hotelu Erlebachova Bouda Systémy nalezené rešeršním vyhledáváním ABRA Software Pokladní systém VIRTUOS pro restaurace a hotely VECTRON Porovnání současných řešení Návrh řešení Výběr aplikačního rozhraní Aplikační servery Aplikační frameworky Hibernate Spring framework Databázové stroje Další použité technologie Shrnutí použitých technologií Diagramy aktivit Kontrola stavu zásob xi

12 xii OBSAH Zaplacení útraty Doplnění zásob Objednávka a dodávka pokrmu a nápoje Model případů užití Správa systému Objednávka a zhotovení pokrmu a nápoje Mapování požadavků na model případů užití Doménový model Vztahy mezi entitami Stavové diagramy Položka na objednávce Objednávka Surovina Analytický model Databázový model Model nasazení Realizace Model architektury Návrh uživatelského rozhraní Popis implementace Testování Kategorie testů Testování programátorem Usability test Low fidelity prototype Testování hotového systému Postup testování Výsledky testování Závěr 41 A Seznam použitých zkratek 47 B Obsah přiloženého CD 49 C Návrh uživatelského prostředí 51 D UML diagramy 55 E Dotazník existujících řešení 61 F Low-fidelity prototype 63

13 Seznam obrázků 3.1 Informační systém ABRA Vituos - pokladní systém Vectron - ukázky jednotlivých modulů Hibernate - architektura aplikace Přehled funkcí Spring frameworku - architektura aplikace Diagram aktivit - Kontrola stavu zásob Diagram aktivit - Proces zaplacení útraty Diagram aktivit - Proces zaplacení útraty Diagram případů užití - Příprava pokrmu a nápoje Stavový diagram - Položka objednávky Stavový diagram - Surovina Diagram modelu nasazení Základní layout informačního systému Zobrazení kategorie nápojů Zobrazení seznamu položek v jídelníčku Detail stolu v restauraci Prostředí baru / kuchyně C.1 Návrh uživatelské rozhraní - seznam zaměstnanců C.2 Návrh uživatelské rozhraní - detail pokrmu/nápoje C.3 Návrh uživatelské rozhraní - seznam stolů v restauraci C.4 Návrh uživatelské rozhraní - seznam stolů v restauraci C.5 Návrh uživatelské rozhraní - seznam stolů v restauraci D.1 Diagram aktivit - Objednávka a dodávka pokrmu a nápoje D.2 Stavový diagram - Objednávka od zákazníka D.3 Diagram případů užití - Správa systému D.4 Domnévý model D.5 Diagram Analytický model D.6 Diagram modelu architektury xiii

14 xiv SEZNAM OBRÁZKŮ

15 Seznam tabulek 3.1 Porovnání existujících programů Mapování požadavků na model případů užití Screener pro výběr uživatelů k testování Nálezy testování aplikace s uživateli xv

16 xvi SEZNAM TABULEK

17 Kapitola 1 Úvod Bakalářská práce se zabývá analýzou a návrhem informačního systému. První kapitolou je tento úvod. Ve druhé kapitole obnáší popis systému, seznam požadavků na budoucí systém a upřesnění obecných požadavků pro následné nasazení. Třetí kapitola se zaměřuje na analýzu systému, podrobné rozepsání funkčních a obecných požadavků. Dále jsou v kapitole zmíněna některá současná řešení podobných informačních systémů. V závěru kapitoly je srovnání výhod a nevýhod zmíněných systémů a srovnání s navrženým systémem. V úvodu čtvrté kapitoly jsou uvedeny aplikační servery, které se využívají jako běhové prostředí. Dále jsou v kapitole zmíněny aplikační frameworky, které v prvé řadě usnadňují práci programátorům a zvyšují bezpečnost celé aplikace. Podstatná část kapitoly se zabývá znázorněním požadavků na systém pomocí diagramů aktivit 1, diagramů případů 2 užití a stavových diagramů 3. Zbylá část kapitoly popisuje databázový, doménový a analytický model a model nasazení. V páté kapitole je podrobně vysvětlen model architektury. Dále se kapitola zabývá návrhem uživatelského rozhraní. Následuje popis implementace stěžejních částí informačního systému. Kapitola testování popisuje jednotlivé testy a jejich význam pro informační systém. Závěr kapitoly shrnuje testy a popisuje všechny nálezy. V poslední kapitole jsou sepsány výhody a nevýhody celé práce. Dále jsou uvedeny možnosti pro případné rozšíření současného návrhu řešení. 1 Diagram aktivit - Popis činnosti, která se vykonává i bez informačního systému (viz. 4.2). 2 Diagram případů užití - Diagram popisuje činnost, kterou vykonává systém (viz. 4.3). 3 Stavový diagram - Diagram popisuje jednotlivé stavy, kterých může vybraná entita nabývat (viz. 4.6). 1

18 2 KAPITOLA 1. ÚVOD

19 Kapitola 2 Popis problému, specifikace cíle Informační systém je soubor lidí, technologických prostředků a metod, které zabezpečují sběr, přenos, zpracování a uchování dat za účelem tvorby prezentace informací pro potřeby uživatelů. [7] Informační systém patří mezi často používané pojmy v oboru informačních technologií. Tímto pojmem je často myšlen software, ale tento pojem zahrnuje mnohem širší odvětví než pouze informatiku. Úkolem informačního systému je vykonávat předem stanovené procesy a zpracovávat vstupní data. V dnešní době je nasazení informačního systému nutnou, dalo by se říci až existenční záležitostí. Kvalitní systém pomáhá s organizací kontaktů na klienty (zákazníky), s požadavky od zákazníků (objednávek), i s plánováním budoucích obchodních aktivit. Díky informačnímu systému je možné naplánovat obchodní strategii s ohledem na předchozí provoz. 2.1 Cíle projektu Cílem projektu je navrhnout a implementovat informační systém pro řízení a správu chodu restauračního zařízení. Osobní cíle: Naučit se základy jazyka Java EE. Proniknout do logiky životního cyklu algoritmů. Prozkoumat existující frameworky 1 používané při programování webových aplikací. 1 Framework - pomocná struktura při programování aplikací. 3

20 4 KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE

21 Kapitola 3 Analýza Analytická část návrhu informačního systému klade důraz na funkční a obecné požadavky celého informačního systému. Hlavním úkolem je usnadnit řízení provozu restauračního zařízení (kontrola stavu zásob, objednávka nových surovin, řízení stavu objednávek, atd.). Závěrem jsou zmíněna existující řešení podobných informačních systémů. 3.1 Uživatelské role Uživatelské role mají v informačním systému stěžejní úlohu. Díky uživatelským rolím je možné rozdělit informační sytém do jednotlivých logických celků a také specifikovat jednotlivé úkoly jednotlivých uživatelů. Vedoucí - Uživatel Vedoucí má na starosti chod restaurace. Dále má na starosti zaměstnance, tvorbu a editaci jídelníčku, sledování objednávek materiálu, ale i objednávek od zákazníků. Kuchař - Uživatele Kuchař zajímají pouze objednávky pokrmů a jejich zhotovení. Barman - Uživatele Barman zajímají pouze objednávky nápojů a jejich zhotovení. Číšník - Uživatel Číšník má na starosti zákazníky. Vytváří nové objednávky a donáší pokrmy z kuchyně ke stolu. Dále má na starosti dokončení objednávek (placení, stornování). Skladník - Uživatel Skladník vytváří nové objednávky (případně kontroluje a edituje objednávky, které se vytvořily samy automatickou kontrolou). Kontroluje stav objednávek a při doručení objednávky zboží zásilku přijme. Potvrzením zásilky v systému se suroviny automaticky připíší na sklad. 5

22 6 KAPITOLA 3. ANALÝZA 3.2 Požadavky na informační systém Předmětem této kapitoly je popis funkčních a obecných požadavků na informační systém. Mezi funkční požadavky se řadí požadavky od uživatelů. Mezi obecné požadavky patří požadavky na použité technologie (operační systém, databáze) a další obecné požadavky, které přímo nesouvisí s logikou systému Funkční požadavky Systém bude umožňovat vytváření objednávek zboží. U každé objednávky bude seznam objednaných surovin. Po doručení objednávky se suroviny automaticky přidají na sklad. Systém bude umožňovat vytváření nových pokrmů a nápojů a jejich kategorií. Každá položka (pokrm, nápoj) může patřit do libovolného počtu kategorii. Systém bude umožňovat vytvoření objednávek pokrmů a nápojů. Objednávky pokrmů budou automaticky odeslané ke zpracování do kuchyně a objednávky nápojů na bar. Systém bude umožňovat vytvoření nového zaměstnance, editacei osobních údajů a také smazaní zaměstnance ze systému. Každý zaměstnanec bude mít alespoň jednu adresu, telefon a . Systém bude umožňovat sledování pracovních výkazů jednotlivých zaměstnanců. Systém bude umožňovat zápis zaměstnance na směnu. Systém bude umožňovat sledování jednotlivých objednávek. Dále bude kontrolovat, jaké objednávky vytvořil který zaměstnanec. Systém bude mít automatickou kontrolu stavu surovin. Při objednání položky se provede kontrola, zda je ve skladu dostatek surovin pro vytvoření další objednávky. V případě, že nebude dostatek suroviny, zablokují se všechny položky, které potřebují danou surovinu pro přípravu. Dále se automaticky vytvoří objednávka surovin. Surovina, která na skladu došla, bude přidána se seznam objednávky Obecné požadavky Informační systém bude využívat PostgreSQL databázi. Informační systém bude aplikace typu Klient-Server 1. Server bude plnit roli webového serveru a aplikačního serveru. Na serveru bude nainstalovaný Apache Tomcat. Informační systém bude mít přehledné a uživatelsky přívětivé grafické prostředí. 1 Klient-Server - Jedná se o typ softwarové architektury. Klient odešle požadavek, většinou prostřednictvím webového prohlížeče. Následně server požadavek vyhodnotí a odešle odpověd zpět klientovi.

23 3.3. REŽIM OBJEDNÁVEK Režim objednávek Číšník u daného stolu vytvoří objednávku pokrmů, která se odešle do kuchyně, a nápojů, kterou vybaví Číšník u baru. Objednané pokrmy a nápoje se v informačním systému evidují. Kuchař, nebo Číšník u baru, si zobrazuje položky a mění jejich stav. Každá položka objednávky bude mít právě jeden z uvedených stavů: Vybrané - položka je zvolena na objednávkový lístek, ale zatím není odeslána. Objednané - položka je závazně objednaná a odeslaná do kuchyně/na bar. V přípravě - zaměstnanci začali pracovat na přípravě pokrmu/nápoje. Připravené - položka je připravená k doručení zákazníkovi. Doručené - objednávka položky byla doručená zákazníkovi. Odmítnuté - zákazník odmítl přijmout pokrm/nápoj. Zaplacené - zákazník položku zaplatil. Jakmile si zákazník přeje zaplatit útratu, uvědomí Číšníka, který uzavře objednávku. Zákazník zvolí způsob platby (kartou, hotově, stravenkou) a zaplatí Číšníkovi útratu. Objednávka bude nabývat jednoho z následujících stavů Nezaplaceno - Neuzavřená objednávka. Zákazník si může přiobjednat položku z jídelního lístku. Zaplaceno - Objednávka je uzavřená a zaplacená. Zákazník už nemůže na objednávku přidat další položku. Stornováno - Objednávka je uzavřená, ale není zaplacená. Tento stav se použije v případě, že zákazník odešel bez placení, nebo odmítl z nějakého důvodu objednávku zaplatit. Jednotlivé položky jídelního lístku nabývají dvou stavů: Povoleno - ve skladu je dostatek surovin pro objednání alespoň jedné položky. Zakázáno - ve skladu není dostatek surovin pro objednání položky. Při změně stavu položky s "Povoleno"na "Zakázáno"je automaticky vytvořena objednávka surovin.

24 8 KAPITOLA 3. ANALÝZA 3.4 Správa systému Informační systém eviduje veškeré zaměstnance. Mezi hlavní funkce patří přidání, odebrání, editace a zobrazení všech zaměstnanců. U každého zaměstnance jsou osobní informace (jméno, příjmení, adresa, telefon, , telefon, atd.) a pracovní informace (plat a uživatelská role v informačním systému). Systém umožňuje sledovat pracovní výkaz všech zaměstnanců. Když přijde zaměstnanec do práce, přihlásí se do systému. Informační systém umožňuje spravovat suroviny používané pro přípravu pokrmů. Hlavní funkce jsou přidání, odebrání, editace a zobrazení surovin a jednotek (hmotnost, objem, počet). Surovina má název, množství, jednotku. Pomocí informačního systému je možné spravovat jídelníček, jeho kategorie (polední menu, akční nabídka, smažená jídla, přílohy, atd.) a také samotné pokrmy (smažený sýr, hranolky, gulášová polévka, zmrzlinový pohár, atd.). Hlavní funkce jsou přidání, odebrání, editace a zobrazení položek a kategorií. Kategorie má jen svůj název. Do každé kategorie mohou být přidávány položky. Položka má název, cenu, seznam surovin surovin a postup zhotovení položky včetně normování na jednu porci. 3.5 Správa skladu Uživatel Skladník může přidávat, odebírat, editovat a zobrazovat objednávky na suroviny. Každá objednávka obsahuje datum a seznam surovin, které jsou objednané, včetně jejich množství. Uživatel Skladník může pomocí informačního systému měnit stav objednávky surovin. Každá objednávka surovin bude mít jeden z následujících stavů: Vytvořené automaticky - objednávka byla vytvořena při kontrole stavu surovin. Vytvořeno - Objednávku vytvořil Skladník, případně editoval objednávku, která byla automaticky vytvořená. Objednáno - Skladník označil objednávku jako odeslanou dodavateli. Doručeno Dodavatel doručil suroviny. Suroviny se automaticky připočítali na sklad. Nedoručeno - Dodavatel suroviny nedoručil.

25 3.6. SOUČASNÁ ŘEŠENÍ Současná řešení Na trhu s informačními systémy je několik podobných systémů, které je možné porovnat s návrhem, který je předmětem této práce. Při vymýšlení informačního systému jsem navštívil několik restaurací, které používají pokladní nebo restaurační systém. Na základě předem vytvořeného dotazníku jsem se snažil zjistit, jaké funkce používaný systém podporuje, případně jak jsou s ním zaměstnanci spokojeni. V poslední řade jsem se ptal na pořizovací náklady na zakoupení, případně pronájem systému. Před výběrem systému pro zařízení je v prvé řadě nutné specifikovat typ restauračního zařízení. Funkce, které jsou zásadní pro spolehlivé fungování restaurace, se budou lišit například pro fastfood, pivnici a nebo pro restauraci. Informační systém restaurace typu fastfood nemusí obsahovat seznam stolů v restauraci. Pro tento typ zařízení je dostačující, aby se objednávka hned zaplatila. V restauračním zařízení typu pivnice by bylo výhodnější, aby účet nebyl vázaný na konkrétní stůl, ale přímo na zákazníka. A naopak v restauraci běžného typu je výhodné, když je objednávka k danému stolu. Další podstatný rozdíl je v sortimentu připravovaných pokrmů. Pokud se restaurace specializuje pouze na minutky 2 stačí, aby byl jeden centrální sklad. Naopak pokud se nabídce objevují i předem připravené pokrmy, bylo by vhodné, aby sklad surovin mohl obsahovat i hotové pokrmy Restaurace Chata Polanka Tato restaurace používá pokladní systém GASTON. Systém dokáže pracovat ve dvou různých režimech. Režim pro vedoucího podporuje funkce pro vytváření pokrmů a nápojů, rozmístění stolů v restauraci a správu skladu surovin. Režim pro číšníka podporuje vytváření objednávek. Mezi další funkce, které systém nabízí, patří tisk objednávek pokrmů v kuchyni, provedení inventury za určité období. Výhody systému Přihlášení zaměstnance pomocí čipové karty. Nevýhody systému Suroviny, které se použijí pro přípravu pokrmů, se musí ručně odepsat ze skladu - není zpětná vazba z kuchyně. Nepřehledná mobilní verze systému - informační systém má i svoji mobilní verzi, kterou jsem neviděl, ale v restauraci mi řekli, že pro svůj nepřehledný a složitý design spíše objednávku komplikovala a proto ji nepoužívají. Pokladní systém je podporován pouze pro platformu MS Windows. Pořizovací náklady na systém se pohybují v řádu tisíc korun. Zakoupení programu je jednorázové, nemá tedy časově omezenou licenci. 2 Minutka - pokrm, který se připravuje až po objednávce zákazníka.

26 10 KAPITOLA 3. ANALÝZA Restaurace U Báby Šubrový - Kokořínský důl V této restauraci informační systém zatím nepoužívají, ale majitel restaurace měl ucelenou představu, jaké funkce by měl systém obsahovat. S majitelem restaurace jsem v kontaktu. Během letních prázdnin je v plánu informační systém, který je předmětem této práce, nasadit do ostrého provozu. Funkce, které by měl systém obsahovat: objednávka pokrmů, objednávka nápojů, objednávka surovin, správa a tvorba jídelního lístku, provoz kuchyně a baru (původně chtěl majitel do kuchyně a na bar pouze tisk lístků. Po společné diskuzi jsme našli řešení jak vytvořit uživatelské prostředí tak, aby bylo jak použitelné v praxi, tak užitečné z pohledu systému), sklad surovin, kontrola zásob při objednávce pokrmů a nápojů Zámecká restaurace Nové Hrady V této restauraci používají pokladní systém SEPTIM. Systém v této verzi podporuje pouze objednávku pokrmů a nápojů. Objednávky pokrmů dokáže automaticky odeslat na tiskárnu do kuchyně. K systému se dají dokoupit další moduly, které restaurace zakoupené neměla Restaurace v hotelu Erlebachova Bouda Hotelový a restaurační systém, který zde používají se jmenuje DeCe. Jedná se o komplexní informační systém, který nabízí následující funkce: Objednávka pokrmů Objednávka nápojů Správa skladu surovin Inventura Systém podporuje pouze tisk lístků v kuchyni a na baru Přehled tržeb Obsluha restaurace si systém velmi pochvalovala. Na první pohled se systém zdál přehledný a intuitivní. I přes všechny kladné a pozitivní ohlasy bude systém nahrazen modernějším, který je programovaný přímo na zakázku hotelu.

27 3.6. SOUČASNÁ ŘEŠENÍ Systémy nalezené rešeršním vyhledáváním S informačními systémy v následující podkapitole nemám žádnou praktickou zkušenost. Pro rozšíření znalostí o fungování podobných informačních systémů jsem se inspiroval u výrobců systému ABRA Software Společnost ABRA Software a. s. 3 vyvíjí a prodává, případně pronajímá licenci na komplexní informační systém nejen pro restaurační zařízení. Informační systém je rozdělen do několika modulů, které by se daly shrnout do následujících kategorií. Řízení firmy - docházka, reporty 4, personalistika 5. Řízení výroby - výroba, gastro-výroba, kapacitní plánování. Vztahy se zákazníky - adresář, pošta, y a interní vzkazy. Řízení skladu - skladové hospodářství, čárové kódy. Správa financí - mzdy, daňová evidence, pokladna. Nákup a prodej - nákup, prodej, e-shop. Obrázek 3.1: Informační systém ABRA[38] 3 ABRA a. s. - Webové stránky společnosti jsou 4 Report - výstupy záznamů z informačního systému. 5 Personalistika - komponenta pro správu zaměstnanců.

28 12 KAPITOLA 3. ANALÝZA Pokladní systém VIRTUOS pro restaurace a hotely Virtuos 6 je komplexní informační systém pro restaurační zařízení a hotely. Informační systém obsahuje tyto části: Pokladna - Tento modul obsahuje celou řadu funkcionalit, např. mobilní číšník, věrnostní systém zákazníků, modul pro pizzerii, rezervaci stolů. Celou aplikaci je možné pohodlně ovládat dotykem, pokud jsou splněné hardwarové požadavky. Dále modul nabízí tisk účtenek, odpis surovin ze skladu. Všechny výstupy je možné zobrazit pomocí grafů. Sklad potravin Mezi funkce modulu Sklad potravin patří řízení provozu více skladů, minimální a maximální stav surovin, kategorizace potravin do skupin, managerské sestavy a výstupy, export dat do MS Excel. Modul Sklad potravin je přímo provázaný s funkcemi modulu Kuchyň a Pokladna Kuchyň - Součástí modulu Kuchyň je seznam receptů (modul obsahuje seznam základní receptur pro přípravu pokrmů a nápojů, dále obsahuje knihovnu s přibližně tisícem běžně používaných receptů), odpis surovin ze skladu, kalkulace jednotlivých pokrmů, rautů, spotřebu surovin pro jednotlivé pokrmy a také spotřební koš. Všechny moduly uchovají informace o všech důležitých změnách a operacích. Obrázek 3.2: Vituos - pokladní systém[39] 6 informační systém společnosti TPC spol. s r.o. - Webové stránky společnosti jsou

29 3.6. SOUČASNÁ ŘEŠENÍ VECTRON Společnost VECTRON vytváří pokladní a hotelový systém, ale také poskytuje hardwarovou podporu. Informační systém se stejným názvem jako je název firmy se skládá z několika na sobě nezávislých modulů. Skladový program Skladový program je určený pro správu skladu, vytváření sestav a odpisů jednotlivých surovin ze skladu. Mezi další funkce modulu patří zobrazení a tisk stavu zásob, hlavního i přidružených (kuchyň, bar) skladů. Dále modul podporuje provádění inventury (celkového skladu i přidružených skladů), flexibilní přepínání sazby DPH a také umožňuje vést pokladní deník. Hotelový program Tento modul poskytuje komplexní řešení pro hotelovou část, hlavně hotelovou recepci a případné pokladny, které mohou být umístěny kdekoli v lokální počítačové síti. Mezi další funkce patří ubytování hostů, vytváření statistik vytížení hotelu. Ke každému pokoji je možné zobrazit podrobnosti o kapacitě, volných místech a případně informace o uživatelském účtu ubytovaných osob. Systém také umožňuje sledování telefonních hovorů. Vectron Commander 7 Jedná se o centrální komunikační prostředek, který zajišt uje komunikaci mezi jednotlivými moduly a stará se jak o centrální aktualizaci dat, tak i o snadnou správu všech modulů z jednoho místa. Pomocí modulu Vectron Commander 7 je možné snadno dotvořit uživatelské rozhraní (povolovat, nebo zakazovat jednotlivé funkce). Obrázek 3.3: Vectron - ukázky jednotlivých modulů[40], [41], [42], [43] POS Touch patří mezi jeden z prvků hardwarové podpory společnosti. Jedná se o multifunkční dotykovou obrazovku se zabudovaným pokladním systémem. Dále zařízení obsahuje malý display otočený k zákazníkovi.

30 14 KAPITOLA 3. ANALÝZA Porovnání současných řešení V tabulce 3.1 jsou shrnuty výhody a nevýhody vybraných systémů (společně s navrhovaným systémem). Na trhu s informačními systémy je možné koupit kvalitní informační systém. Systémy se většinou skládají z jednotlivých a samostatných modulů. Je tedy možné systém lépe upravit na míru. Nevýhodou takovýchto systému je bezesporu pořizovací cena. Jedním z požadavků, které jsou kladeny na navrhovaný informační systém, je použití open-source technologií. Při použití open-source technologií se výrazně snižují i celkové náklady na systém, protože se nemusí platit licenční poplatky za používání komerčních systémů. Shrnutí Název Výhody Nevýhody GASTON jednoduché řešení, rozmístění stolů v restauraci nevzhledný design, ruční odpočet surovin ze skladu, obtížně použitelný mobilní číšník SEPTIM snadná obsluha pouze pokladna, tisk lístků v kuchyni DeCe řešení pro restauraci i hotel velmi chybový mobilní číšník, zastaralé řešení a bez aktualizací ABRA klient-server, více databází, jazykové mutace, možný pronájem licence Virtuos rozdělený na moduly, v kuchyni velký počet receptů Vectron rozdělený na moduly, možnost hlavního a přidružených skladů RIS - navrhované řešení klient-server, postaveno na opensource technologiích, minimální požadavky na klientský počítač, více typů databází vysoká cena, velmi vysoké hardwarové nároky pouze MS Windows pouze MS Windows Tabulka 3.1: Porovnání existujících programů pouze čeština, jeden centrální sklad

31 Kapitola 4 Návrh řešení V této kapitole jsou popsány používané technologie pro programování webových a podnikových aplikací. První část kapitoly je věnována aplikačním serverům. Další části jsou věnovány práci s databází, možnostem připojení k databázi a frameworkům pro vývoj aplikací. V závěru této kapitoly jsou popsány různé typy databází, které je možné použít při vytváření aplikací pomocí technologie Java EE. 4.1 Výběr aplikačního rozhraní Pro tvorbu webových a podnikových aplikací v Java EE existuje veliký počet technologií. V první části této kapitoly budou zmíněny nejpoužívanější technologie Aplikační servery Aplikační server je software, který zprostředkovává běh komponent distribuovaných aplikací. Také může obsluhovat několik různě nakonfigurovaných kontejnerů pro komponenty 1. Mezi nejčastěji používané komponenty patří webový, souborový, databázový, autorizační server, atd. Aplikační server není totéž jako webový server. Aplikační server plní daleko rozsáhlejší funkci a web server je pouze jedna komponenta z mnoha. Drtivá většina aplikačních serverů vychází z podpory standardu Java Platform Enterprise Edition (Java EE). Díky podpoře Java EE je možné využívat další vlastnosti (EJB 2, JMS 3, XML 4, SOAP 5, atd.). Aplikační server může mimo jiné plnit i roli managed serveru. Managed server je vzdálený počítač, který provozuje externí firma a na kterém je možné provozovat aplikace typu ABRA (zpravidla se jedná o aplikace, které mají vysoké nároky na hardware a zároveň 1 Komponenta - samostatně fungující část aplikačního serveru 2 EJB (Enterprice Java Bean) - Komponenta řízená serverem pro modulární vytváření aplikací. 3 JMS (Java Message Service) - Služba umožňující posílání zpráv mezi klienty. 4 XML (extensible Markup Language) - XML je univerzální znakovací jazyk. 5 SOAP (Simple Object Access Protocol) - Jednoduchý pro protokol na bázi XML. Protokol zařizuje výměnu dat mezi dvěma aplikacemi. 15

32 16 KAPITOLA 4. NÁVRH ŘEŠENÍ je zákazník potřebuje používat i mimo firemní kancelář). Hlavní výhoda managed serverů spočívá v přenesení odpovědnosti za správu hardwaru a zálohování na externí firmu, která se na tuto problematiku přímo specializuje. Apache Tomcat - open source 6 aplikační server vyvíjený firmou Apache Software Foundation. Apache Tomcat implementuje Java Servlet a JavaServer Pages (JSP) dle specifikací firmy Oracle. Glassfish - další z mnoha aplikačních serverů pro prostředí Java EE, které začala vyvíjet firma Sun Microsystems (dnes Oracle) Aplikační frameworky Aplikační framework je softwarová knihovna, která pomáhá programátorům při vývoji nové aplikace. Většina frameworků obsahuje kostru pro vytvoření aplikace, která obsahuje základní zabezpečení a velmi urychlí první část vývoje aplikace. Hlavními důvody, proč aplikační frameworky vznikly, bylo jednak ušetřit opakující se práci programátorům, dále snížit celkové náklady na vznik nové aplikace a v neposlední řadě vytvářet bezpečnější aplikace. Existuje řada specializovaných frameworků tzv. CMS 7 Aplikační frameworky se nepoužívají jen pro tvorbu grafického rozhraní (GUI 8 ), ale také pro tvorbu bussinnes logiky celé aplikace. Mezi hlavní výhody aplikačních frameworků patří: Snadnější udržitelnost a úprava zdrojového kódu aplikace. Propracovaný objektový návrh. Vysoká úroveň zabezpečení. Snížení nákladů na celkovou cenu aplikace. 6 Open source - licence pro volně šiřitelný software. 7 CMS (content managment system) - Tyto systémy se často používají při vytváření webových stránek nebo e-shopů. Uživatel pouze zvolí šablonu a doplní obsah aplikace. 8 GUI (graphical user interface) - uživatelské rozhraní výsledné aplikce

33 4.1. VÝBĚR APLIKAČNÍHO ROZHRANÍ Hibernate Hibernate je vysoce výkonný, objektově orientovaný framework, který zprostředkovává komunikaci s databází. Vytváří persistentní spojení s databází a díky propracovaným dotazům minimalizuje počet přístupů k databázi. V aplikační logice se hibernate nachází mezi POJO 9 objekty a databázovým serverem. Výhody, které Hibernate poskytuje: Zajišt uje mapování databázových tabulek na objekty Pro správnou funkci nepotřebuje aplikační server. Umožňuje změnu databáze bez jediné změny v kódu aplikace. Podporované databáze - MySQL, PostrgresSQL, DB2/NT, FrontBase, HSQL Database Engine, Oracle, a další. Obrázek 4.1: Hibernate - architektura aplikace[6] 9 POJO - plain old java object - jedná se o třídu, která má nadefinované parametry a dále jen getry a setry

34 18 KAPITOLA 4. NÁVRH ŘEŠENÍ Spring framework Spring framework je jeden z nejčastěji používaných aplikačních frameworků při vytváření enterprise aplikací v jazyku Java EE. Díky tomuto frameworku jsou vývojáři schopni vytvářet vysoce výkonné aplikace, které jsou zároveň snadno testovatelné a jejich kód je znovu použitelný. Spring framework je rozdělený do jednotlivých a na sobě nezávislých modulů, které je možné použít. Záleží pouze na programátorovi, jaké moduly použije. Spring framework obsahuje okolo 20 modulů, které je možné při programování používat, diagram jednotlivých modulů je zobrazen na obrázku 4.2. Obrázek 4.2: Přehled funkcí Spring frameworku - architektura aplikace[10] Ve zbytku této podkapitoly jsou podrobněji představeny některé moduly, které je možné použít. Core Container Tento modul obsahuje části Core, Beans, Context a Expression Language. Část BeanFactory je programována podle návrhového vzoru Factory 10. Expression language, jak prozrazuje název, je skriptovací jazyk pro generování html obsahu. Web Nejvíce používaným modulem z této části je modul Web-servlet, který poskytuje implementaci MVC. Spring MVC framework umožňuje čistě oddělit aplikační logiku od zbytku aplikace. 10 Factory - návrhový vzor, který se stará o vytvoření nové instance objektu dané třídy v momentě, kdy je potřeba.

35 4.1. VÝBĚR APLIKAČNÍHO ROZHRANÍ Databázové stroje V současné době jsou databáze nejčastějším datovým úložištěm používaným pro ukládání dat webových stránek. Existuje velké množství databázových strojů, které mohou být nainstalovány na server. MySQL - multiplatformní databáze, která je využívána u většiny webových aplikací. Komunikace s databází probíhá pomocí jazyka SQL, který se používá u většiny databází. MySQL má, stejně jako ostatní databáze, rozšíření pouze pro danou databázi. Díky vysokému výkonu, snadné použitelnosti a snadné dostupnosti (jedná se o open source) se MySQL databáze stala jednou z nejvíce použitelných databází. Nejběžněji se používá ve spojení v kombinaci tzv. LAMP (Linux, Apache, PHP, MySQL). MySQL databáze byla od začátku optimalizována hlavně pro rychlost i za cenu zjednodušení některých operací. Donedávna MySQL nepodporovalo pohledy, triggery. Pro jednoduchou správu konkrétní databáze a dat v ní uložených se nejčastěji používá aplikace phpmyadmin. PostgreSQL - objektově-relační databázový systém vydaný pod licencí MIT (jedná se o open source licenci). PostgreSQL je primárně vyvíjen pro UNIXové systémy, ale exitují také instalační balíčky pro ostatní operační systémy. Stejně jako MySQL i komunikace s PostgreSQL probíhá pomocí jazyka SQL. Tato databáze je optimalizována pro velmi velké objemy dat. Datový limit pro velikost jedné tabulky je 32 TB, pro velikost jednoho řádku je 400 GB a maximální velikost jedné položky je 1 GB. Pro jednoduchou správu konkrétní databáze a dat v ní uložených je možné používat aplikaci phppgadmin. SQLite - relační databázový systém vyvíjený pod licencí public domain 11. Celý databázový systém je obsažený v relativně malé knihovně psané v jazyce C. Databázový server je spuštěn jako samostatný proces a nejedná se, na rozdíl od většiny běžných databázových serverů, tedy o aplikaci typu Klient-Server. SQLite je pouze malá knihovna, která se přilinkuje přímo k aplikaci, dále pak s aplikací komunikuje pomocí jednoduchého rozhraní. Každá databáze je uložena v samostatném souboru (typicky se používá přípona DBM). V SQLite je implementován běžný standart SQL jazyka (opět jsou zde drobné odlišnosti spojené s typem databáze). 11 Public domain - licence na softwarové výrobky. Výrobky pod touto licencí nepodléhají autorským právům.

36 20 KAPITOLA 4. NÁVRH ŘEŠENÍ Další použité technologie V teto části kapitoly jsou uvedeny zbývající aplikace, které byly použity při vytváření aplikace. Jedná se o GIT, Mavem, Apache Tiles a Twiter Boostrap. GIT Git je softwarový nástroj pro programátory, který se používá převážně pro verzování jednotlivých části kódu. Hlavní přínos používání se projeví při programování jedné aplikace týmem programátorů. Další hojně používanou funkcí je vytváření jednotlivých vývojových větví, které je možné slučovat opět do jedné. Maven Maven je nástroj, který automaticky stahuje knihovny, které jsou při programování aplikace potřebné. Jaké knihovny se mají stahovat se definuje pomocí xml jazyka. Hlavním úkolem Mavenu je usnadnit práci programátorovi, který si díky této technologii nemusí stahovat knihovny sám, ale pouze předá řízení automatické obsluze. To samé platí při hlídání aktualizací knihoven. Apache Tiles Apache Tiles je šablonovací framework používaný pro vytváření jednotného vzhledu aplikace, dále se dá použít pro tvorbu uživatelského menu a všeobecně pro vykreslení společných částí webové stránky (hlavička, patička, menu, atd.) Boostrap Bootstrap obsahuje jak knihovny css, tak javascript. Hlavní použití je při tvorbě jednotlivých částí uživatelského rozhraní (modální formuláře, validace formulářů pomocí javascriptu, zobrazení informační hlášek, atd.) Shrnutí použitých technologií Pro potřeby tohoto projektu byly zvoleny technologie Tomcat, Hibernate, Spring framework a databáze PostgreSQL. Pro tvorbu uživatelského rozhraní byly zvoleny běžně používané technologie na tvorbu webových stránek (css a java script - přesněji knihovny bootstrap) Tyto technologie byly vybrány pro svoje jednoduché, snadné používání a zároveň velmi efektivní výsledky. Pro tvorbu jednotného layoutu celé aplikace byla zvolena knihovna Apache Tiles. Dále byly, hlavně během vývoje aplikace, použity technologie Git (pro zálohování a ukládání jednotlivých verzí aplikace) a Maven (pro jednoduché stahování aktuálních verzí podpůrných knihoven). Aplikace byla programována ve vývojovém prostředí Netbeans.

37 4.2. DIAGRAMY AKTIVIT Diagramy aktivit Diagram aktivit je jeden z mnoha typů UML 12 diagramů, který se používá pro modelování procedurální logiky, procesů a zachycení workflow 13. Při návrhu softwaru se diagramy aktivit používají pro schématické zachycení současných aktivit, které se vykonávají i bez informačního systému Kontrola stavu zásob Aktivita začíná v okamžiku vytvoření nové objednávky pokrmu nebo nápoje zákazníkem. V prvé řadě se musí provést normování surovin podle objednávky. Kuchař si odebere suroviny, které bude potřebovat na uvaření všech pokrmů a přípravu nápojů. V dalším kroku se musí ověřit, zda je dostatek surovin i pro přípravu dalších položek. Obrázek 4.3: Diagram aktivit - Kontrola stavu zásob V případě, že stav suroviny klesne pod hranici, ze které je možné uvařit další porci, musí se v jídelníčku zakázat všechny položky, které potřebují danou surovinu. Společně se zablokováním pokrmu nebo nápoje by se měla vytvořit nová objednávka surovin. Kontrolní systém je navržen tak, že pokud je položku možné objednat, tak je surovin na její přípravu dostatek. 12 UML (Unifite modeling language) - Jedná se o značkovací jazyk, který se používá pro modelování diagramů při návrhu softwaru. 13 Workflow - pracovní postup, postup při vykonávání činnosti.

38 22 KAPITOLA 4. NÁVRH ŘEŠENÍ Zaplacení útraty Diagram popisuje proces placení objednávky. Aktivita začíná žádostí o platbu. Zákazník si vybere hotovostní, nebo bezhotovostní způsob platby. V okamžiku dokončení platby je vytištěna účtenka. Obrázek 4.4: Diagram aktivit - Proces zaplacení útraty Doplnění zásob Diagram popisuje proces objednání a naskladnění surovin. Aktivita začíná komunikací s dodavatelem zboží. V případě, že vybraný dodavatel suroviny nemá, je vybrán nový dodavatel, který je schopný suroviny v daném termínu dodat. V dalším kroku proběhne závazná objednávka, potvrzení objednaného zboží ze strany dodavatele a dodání surovin. Po dodání surovin Skladník překontroluje zboží a následně suroviny přebere a naskladní. Obrázek 4.5: Diagram aktivit - Proces zaplacení útraty Objednávka a dodávka pokrmu a nápoje Diagram popisuje proces objednávky pokrmu a nápoje. Aktivita začíná vytvořením objednávky zákazníkem. Pokud je na objednávce i pokrm, odešle se objednávka i do kuchyně,

39 4.3. MODEL PŘÍPADŮ UŽITÍ 23 kde Kuchaři začnou pracovat na přípravě pokrmu. Nápoj vyřídí číšníci za barem a následně ho odnesou zákazníkovi. Stejně se vyexpeduje i hotový pokrm. Diagram aktivit se nachází v příloze D Model případů užití Případ užití je popis činnosti, která je vykonávána informačním systémem. Obecně by se dalo říci, že případ užití je seznam kroků popisující interakci mezi systémem a uživatelem (tzn. rolí). Rolí může být člověk nebo externí systém Správa systému Diagram případů užití správa systému definuje základní množinu operací pro správu celého systému. Všechny tyto operace může vykonávat uživatel s právy Vedoucího, nebo částečně i ostatní pověření uživatelé. Všechny případy užití mají podobnou logiku. Pověřený uživatel může zobrazovat záznamy, vytvářet nové záznamy, editovat a mazat stávající záznamy týkající se nastavení informačního systému. Diagram případu užití se nachází v příloze D Objednávka a zhotovení pokrmu a nápoje Diagram případů užití objednávka a zhotovení pokrmu a nápoje popisuje jednotlivé činnosti, které souvisí s objednávkou a přípravou pokrmu a nápoje. Z pohledu Kuchaře a Číšníka se činnosti podobají. Kuchař připravuje pokrmy a Číšník nápoje. Po přípravě je nastaven status objednávky na hotovo. Obrázek 4.6: Diagram případů užití - Příprava pokrmu a nápoje

40 24 KAPITOLA 4. NÁVRH ŘEŠENÍ Správa systému Správa skladu Objednávka a zhotovení pokrmu Objednávka a zhotovení nápoje Správa zaměstnanců X Správa surovin X Příprava nápoje X Příprava pokrmu X Zaplacení útraty Zobrazení stavu X X Změna stavu objednávky X X X Vložení nového záznamu X X X X Editování záznamu X X Zobrazení záznamu X X X X Tabulka 4.1: Mapování požadavků na model případů užití 4.4 Mapování požadavků na model případů užití Mapování funkčních požadavků na jednotlivé případy užití slouží ke kontrole, zda je každý funkční požadavek pokryt alespoň jedním případem užití. Pro lepší vizuální přehled se vytváří tabulka. Do prvního sloupce tabulky se napíší případy užití. Do prvního řádku se napíší funkční požadavky na informační systém. Smyslem této tabulky je tedy znázornit, že každý funkční požadavek se váže alespoň k jednomu případu užití.

41 4.5. DOMÉNOVÝ MODEL Doménový model Doménový model je jedna z forem diagramu tříd. Diagramy tříd se používají při objektovém návrhu softwaru. Základním stavebním kamenem diagramu tříd je třída. Doménový model je obecný diagram z pohledu programovaní - neváže se k žádnému konkrétnímu programovacímu jazyku a je tedy platformně nezávislý. Struktura tříd je tak zjednodušená. Doménový model je první ucelený pohled na budoucí informační systém. Při tvorbě modelu se vychází z požadavků zákazníka. Ze zadání se nejprve identifikují klíčové entity, důležité atributy a vztahy mezi entitami. Entity se zakreslí do modelu jako třídy. Dle grafické notace jazyka UML se třídy zakreslují jako obdélníky vodorovně rozdělené na tři části. Doménový model pro zadaný informační systém je navržen na principu popsání celého systému pomocí tříd. Mezi třídami se využívá většiny základních vztahů. Nejprve se zaměříme na třídy Category a CategoryMember. Mezi těmito třídami je agregační vztah (viz 4.5.1). Objekty třídy CategoryMember sice mohou v systému existovat i bez určené categorie, ale nemají v systému další stěžejní využití. Diagram doménový model je v příloze D.4 Vztah kompozice (viz ), tedy silnější vztah mezi třídami, je mezi třídami Person a Position, Adress, Phone, , Timesheet. Všechny tyto vztahy by neměly žádný význam, kdyby neexistovala instance třídy Person, ke které by se položky mohly přiřadit Vztahy mezi entitami V jazyce UML existuje několik základních vztahů mezi entitami. Asociace je základní vztah mezi třídami. Třídy mohou existovat nezávisle na sobě. Ve výchozím stavu je entita obousměrná, tzn. první třída má odkaz na druhou a naopak. Agregace reprezentuje vztah typu celek - část. Znázorňuje se jako jednoduchá plná čára, zakončená na jedné straně prázdným kosočtvercem. Ten je umístěn u té entity, která reprezentuje celek. Entita reprezentující část může existovat sama o sobě a být součástí i jiných kolekcí. Vztah kompozice je velmi podobný vztahu agregace. Kompozice tvoří silnější vztah mezi entitami (třídami). Pokud zanikne třída reprezentující celek, automaticky zanikají všechny ostatní části. Poslední ze základních vztahů mezi třídami v UML diagramu je vztah generalizace (dědičnosti). Z pohledu programování se jedná o vztah dědičnosti. První entita zdědí všechny vlastnosti rodičovské entity a dále si může svoje chování přesněji upravit. Násobnost určuje kolik entit jednoho typu může odkazovat na jednu entitu typu druhého. Existují 3 základní typy násobnosti. číslo - označuje přesný počet entit (většinou se používá 1). hvězdička - označuje libovolný počet, včetně 0. interval - vyznačuje přesný počet odkazů v mezích intervalu, např. 0..1, 1..*, 3..5, atd.

42 26 KAPITOLA 4. NÁVRH ŘEŠENÍ 4.6 Stavové diagramy Stavový diagram slouží k názornému zobrazení životního cyklu entity. Stavový diagram popisuje stavy, kterých může entita nabývat. Dalo by se říci, že stavový diagram popisuje chování entit. Stavový diagram je velmi podobný diagramu aktivit, protože používá stejnou notaci. Zásadní rozdíl mezi stavovým diagramem a diagramem aktivit je v principu použití. Diagram aktivit popisuje aktivitu - činnost. Zatímco stavový diagram popisuje stavy právě jedné entity Položka na objednávce Stavový diagram popisuje stavy každé položky na objednávce zákazníka u stolu. V okamžiku výběru zákazníkem se položka přidá na objednávku, dokud se výběr závazně nepotvrdí, tak se položky (pokrmy ani nápoje) nikam neodešlou. Po závazném objednání se pokrmy odešlou do kuchyně a nápoje na bar. Na dobu, kdy je položka v přípravě, jsou tři stavy (objednáno, v přípravě a hotovo). Po doručení položky zákazníkovi následuje stav zaplaceno, pokud je vše v pořádku, nebo odmítnuto, pokud zákazník položku odmítl přijmout. Obrázek 4.7: Stavový diagram - Položka objednávky Objednávka Stavový diagram popisuje stavy objednávky. Objednávka vzniká prvním výběrem pokrmu nebo nápoje zákazníkem. Při vzniku objednávky se automaticky přesune do stavu Nezaplaceno. Pokud zákazník zaplatí vše, co si objednal, přesune se objednávka do stavu Zaplaceno. V informačním systému musí být také možnost objednávku zrušit. At je to z důvodu platební neschopnosti zákazníka či předčasným odchodem, atd. V každém případě je potřeba objednávku v informačním systém uzavřít. Pro tyto případy je zde stav Zrušeno. Stavový diagram je v příloze D.2

43 4.7. ANALYTICKÝ MODEL Surovina Stavový diagram popisuje stavy suroviny na skladě. Po doplnění objednané suroviny na sklad se nastaví stav suroviny na Dostatek suroviny. Kuchař při vaření odebírá surovinu ze skladu. Pokud množství suroviny klesne pod stanovený limit, změní se stav suroviny na Minimální stav surovin. Z tohoto stavu je možné se přesunout do stavu Dostatek surovin v případě, že dojde k doplnění zásob. Pokud je stav Minimální stav surovin, není možné dále objednávat pokrmy a nápoje, které potřebují k přípravě danou surovinu. Obrázek 4.8: Stavový diagram - Surovina 4.7 Analytický model Analytický model je dalším typem class diagramu. Tento model musí být daleko podrobnější než doménový model. Třídy v analytickém modelu musí obsahovat datové typy všech svých atributů. Nejen z toho plyne, že analytický model je platformně závislý a specifický pro určitý programovací jazyk. V názvu tříd, atributů a metod se nesmí vyskytovat diakritika (v doménovém modelu diakritika být mohla). Existuje několik oprávněných důvodů, proč musí být analytický model domyšlený do detailu. V první řadě není možné u složitých informačních systému v průběhu programování změnit logiku problému. Dalším důvodem jsou finance. Analytický model vytvoří zkušený programátor (analytik) a samotné programování provede méně zkušenější, který bude zároveň levnější. Diagram analytického modelu pro zadanou úlohu specifikuje a doplňuje doménový model (viz. D.4). Do diagramu jsou doplněny datové typy jednotlivých atributů tříd, návratové datové typy metod a vstupních parametrů. Dále je kladen důraz na zapouzdření tříd a atributů. Diagram analytického modelu je v příloze D Databázový model Relační databázový model patří mezi nejpoužívanější databázové modely, zároveň také patří mezi nejstarší typ modelu. Struktura databáze je velmi jednoduchá. Data se ukládají do tabulek, tabulky se skládají z libovolného, ale pevně stanoveného počtu sloupců a řádků. Všechny operace se pak provádějí nad celými tabulkami, jednotlivými sloupci, řádky nebo samostatnými buňkami.

44 28 KAPITOLA 4. NÁVRH ŘEŠENÍ Pro práci s databází se používá Hibernate, který namapoval jednotlivé databázové tabulky na třídy. Databázové tabulky tedy odpovídají třídám z analytického modelu. Hlavním důvodem pro vytvoření databázového modelu je zachycení všech případů, při kterých se bude pracovat s databází (ukládání nebo čtení dat). 4.9 Model nasazení Diagram modelu nasazení ukazuje hardware, na kterém bude vytvářený software nasazený. Dále také popisuje konkrétní nasazení softwaru (tzn. vazby mezi jednotlivými komponentami). V diagramu jsou znázorněny jednotlivé komponenty, které je potřeba nastavit, aby mohl informační systém bezchybně pracovat. Obrázek 4.9: Diagram modelu nasazení

45 Kapitola 5 Realizace Kapitola popisuje tvorbu uživatelského rozhraní a aplikační logiky celého informačního systému. Nejprve je popsán model architektury. V další části kapitoly je popsána tvorba uživatelského rozhraní. Dále kapitola obsahuje samotný popis implementace. Z důvodu velkého rozsahu je hlavní důraz kladen na stěžejní části systému. 5.1 Model architektury Model architektury se řadí do početné skupiny UML diagramů. Úkolem diagramu je graficky znázornit struktury architektury a případné vazby mezi jednotlivými vrstvami. Příloha D.6 zobrazuje rozdělení architektury informačního systému na tři vrstvy. Datová vrstva (na diagramu se nazývá model) se stará o komunikaci s databází. Aplikační logika celého systému se nachází ve druhé vrstvě. Tato vrstva se nazývá controller. Poslední, třetí vrstva se stará o zobrazení výsledků uživateli. Vrstva nese název view. Z webového prohlížeče je přístupná pouze poslední vrstva a uživatel přímo komunikuje pouze s ní. 5.2 Návrh uživatelského rozhraní Tato kapitola se věnuje popisu hlavních částí uživatelského rozhraní. Uživatelské rozhraní je pro uživatele velmi důležité. V případě kvalitního uživatelského rozhraní uživatelům usnadňuje používání celého systému. V kapitole Aplikační frameworky jsou uvedeny technologie, které byly použity pro potřeby programování aplikace. 29

46 30 KAPITOLA 5. REALIZACE Základní rozvržení Základní rozvržení je rozděleno do tří částí. V horní části se nachází hlavní menu celé aplikace (v závislosti na uživatelské roli se zobrazí příslušná nabídka). V prostřední části se nachází hlavní obsah příslušné stránky. V zápatí celé stránky je informační lišta. Obrázek 5.1: Základní layout informačního systému Správa zaměstnanců Komponenta správa zaměstnanců zobrazí v tabulce všechny zaměstnance. Mezi funkce patří vytvoření nového zaměstnance, případná editace jeho údajů nebo odstranění zaměstnance ze systému. U každého zaměstnance je dále možné zobrazit jeho detail, výkaz práce (tzv. timesheet) a v neposlední řadě také objednávky, které v systému vytvořil. Obrázek s návrhem se nachází v příloze C.1 Správa jídelníčku Na obrázku 5.2 je vidět názorná ukázka, jak se zobrazí jednotlivé kategorie pokrmů a nápojů. Uživatel bude moci tyto kategorie editovat. Součástí editace je také přidání dalších položek do zvolené kategorie. Obrázek 5.2: Zobrazení kategorie nápojů. Vstupem uživatele na stránku se zobrazí seznam všech kategorií pokrmů nebo nápojů, které se nacházejí v jídelníčku. Kategorii je možné editovat i smazat. V editaci je možné přidávat/odebírat jednotlivé.

47 5.2. NÁVRH UŽIVATELSKÉHO ROZHRANÍ 31 Položky na jídelním lístku Vedoucí nebo jím pověřený uživatel také bude moci spravovat (přidávat, editovat a mazat) jednotlivé položky jídelního lístku. Na obrázku 5.3 je názorně ukázáno jak bude vypadat seznam pokrmů a nápojů. Po zobrazení detailu se zobrazí postup přípravy zvolené položky, dále seznam potřebných surovin pro výrobu jedné porce a informace o nákupní a prodejní ceně. Tyto informace zobrazuje obrázek v příloze C.2 Obrázek 5.3: Zobrazení seznamu položek v jídelníčku. Vstupem uživatele na stránku se zobrazí seznam všech pokrmů nebo nápojů, které se nacházejí v jídelníčku. Položky je možné přidávat, editovat nebo smazat. V editaci je možné upravovat seznam surovin pro přípravu. Prostředí restaurace Po zvolení režimu Číšník se nejprve zobrazí seznam stolů (viz. příloha C.3), pokud u stolu bude vytvořena objednávka, zobrazí se stručné informace (jméno zaměstnance, celková hodnota objednávky). V opačném případě se po výběru stolu objednávka vytvoří. Detail stolu v restauraci bude vypadat dle obrázku 5.4. V záhlaví stránky se zobrazí informace o stole a objednávce. Dále se zde zobrazí navigační tlačítka pro operace s objednávkou. Pod informacemi o objednávce se nachází jídelní lístek. V pravé části obrazovky je seznam objednaných položek společně se stavem každé položky. Obrázek 5.4: Detail stolu v restauraci. Vstupem uživatele na stránku se zobrazí jednak informace o vytvořené objednávce, dále informace o stolu. V hlavní části stránky se nachází jídelní lístek a v pravé části seznam objednaných položek společně s cenou a stavem.

48 32 KAPITOLA 5. REALIZACE Prostředí kuchyně / baru Prostředí kuchyně a baru vypadá stejně. Tyto režimy se liší pouze v tom, jaký typ položek se zde zobrazuje. Po závazné objednávce se položky zobrazí zde. Na obrázku 5.5 můžeme vidět položky ve třech sloupcích, podle toho, v jakém stavu se daná položka nachází. Obrázek 5.5: Prostředí baru / kuchyně. Celá stránka je rozdělena do třech sloupců podle stavů. V každém sloupci je zobrazen vždy stůl, který má na objednávkovém lístku položku v odpovídajícím stavu, čas poslední změny stavu a akce, kterou je možné s položkou vykonat. Sklad surovin Režim Skladník obsahuje tři základní funkcionality. V této části kapitoly se zaměříme pouze na dvě z nich - Kategorie suroviny a Suroviny. Kategorie surovin obsahuje seznam kategorií, do kterých jsou suroviny na skladě rozděleny. Příslušná stránka vypisuje seznam do přehledné tabulky. V každém řádku je název kategorie, popis (nebo nějaké poznámky), celkový počet položek v kategorii, jakou hodnotu mají suroviny v kategorii. V posledním sloupci tabulky se nachází navigační lišta pro editování nebo smazání kategorie. V posledním řádku tabulky se zobrazena celková cena všech položek na skladě. Návrh uživatelského rozhraní je zobrazen v příloze C.5. Stránka zobrazující obsah jednotlivé kategorie surovin (ukázka je v příloze C.4) obsahuje v levé části seznam kategorií surovin a v pravé části přehlednou tabulku s výpisem jednotlivých položek zvolené kategorie. Každý řádek výpisu se týká jedné suroviny a obsahuje název, jednotku, v níž se surovina měří, cenu za uvedenou jednotku, celkovou cenu na suroviny na skladě a poslední sloupec opět zobrazuje navigační tlačítka. V posledním řádku tabulky je součet všech položek v kategorii a celková cena za kategorii.

49 5.3. POPIS IMPLEMENTACE Popis implementace Pro implementaci informačního systému byla zvolena třívrstvá architektura typu MVC 1. Jako první je popsána modelová vrstva - tedy práce s úložištěm dat. Pro komunikaci s databází byl vybrán objektově relační framework Hibernate (viz. kapitola ). Aplikace využívá model rozdělený do dalších samostatných vrstev. Nyní se na některé vrstvy podíváme podrobněji. Jednou z vrstev jsou entity. Entita je třída, ve které jsou nadefinovány privátní parametry, dále jen metody get a set pro jednotlivé parametry. Entity se namapují na databázové tabulky a dále se v aplikaci nepracuje s databázovými tabulkami, ale s celými objekty. Všechny doménové třídy se nacházejí v balíčku eu.petrvich.ris.domain. Dále model obsahuje servisní vrstvu, která se nachází v balíčku eu.petrvich.ris.service.- dao. Dalo by se říci, že servisní vrstva plní roli čehosi jako fasády nad jednotlivými entitami. Poslední vrstvou modelu kterou si zde představíme, je vrstva Repository. Třídy této vrstvy se nacházejí v balíčku eu.petrvich.ris.service.impl a jsou potomky třídy HibernateDaoImp, ve které jsou implementovány metody pro základní práci s databází. V další části kapitoly se podíváme na controller. Veškeré požadavky, které přijdou, řeší příslušný controller, který se vybere podle url adresy. Veřejné metody v controlleru jsou datového typu ModelAndView, díky kterému v metodě snadno nastavíme, jaké view má daný obsah zobrazit, a také snadno předáme parametry pro jeho vykreslení. Controller nikdy přímo nepracuje s databází, ale využívá k tomu právě modelovou vrstvu, konkrétně servisní třídy. Pro celou aplikaci je vytvořena abstraktní třída BaseController, ve které jsou definovány všechny instance na servisní třídy. Třída BaseController je přímým potomkem třídy AbstracController. V balíčku web se také nachází balíček validators, který obsahuje třídy pro validaci formulářů a také balíček editors. Třídy v baličku editors usnadňují práci při předání celého objektu, protože na základě unikátní informace (v našem případě se jedná o unikátní parametr id) o objektu dokáží z databáze načíst opět celý objekt. Poslední částí aplikace je vrstva view. Tato vrstva se nachází v adresáři WEB-INF/- views. Adresář obsahuje JSP soubory, které se starají o vykreslení dat uživateli. Layout celé aplikace je tvořen, jak již bylo zmíněno, pomocí Apache Tiles. Konfigurace layoutu se nachází v WEB-INF/tiles/tile-definition.xml. Tento soubor obsahuje konfiguraci pro jednotlivé typy layoutů. Zde se definuje na jaké stránce (respektive jaké skupině stránek) se zobrazí konkrétní část layoutu, atd. <tiles-definitions> <definition name="defaulttemplate" template="/web-inf /template/default/template.jsp"> <put-attribute name="header" value="/web-inf/ template/default/header.jsp"/> <put-attribute name="footer" value="/web-inf/ template/default/footer.jsp"/> </definition> </tiles-definitions> 1 MVC - Model-View-Controler. Architektura popisuje logickou strukturu systému a oddělení bussiness logiky od uživatelského rozhraní.

50 34 KAPITOLA 5. REALIZACE

51 Kapitola 6 Testování Jedním z posledních kroků při návrhu systému je testování softwaru. Před nasazením programu do ostrého provozu je potřeba jej řádně otestovat a ověřit, zda se informační systém chová tak, jak má a jak bylo při analýze domluveno se zákazníkem. Na první pohled se může testování zdát jako zbytečné protahování vývoje a bezpředmětné navyšování ceny. V každé literatuře, která se věnuje návrhu softwaru, je však na testování kladen veliký důraz. Při pravidelném testování je možné odhalit závažné chyby již ve stadiu vývoje a tím ušetřit drahocenný čas jak programátorů, tak testerů, a ušetřit tím nemalé prostředky, které by se musely vynaložit na opravu chyb. 6.1 Kategorie testů Softwarové testy je možné rozdělit do několika kategorií. Testy se mohou dělit podle způsobu použití (zátěžové, usability - testování uživatelského rozhraní, alfa testy, beta testy), atd Testování programátorem Test se provádí bezprostředně po dopsání nějaké logické části zdrojového kódu. Testování provádí sám programátor, nebo lépe programátor, který testovaný kód nepsal. Úkolem testování je odhalit syntaktické chyby v kódu Usability test Usability test je typ testování se zákazníkem. Jedná se o testování uživatelského rozhraní Low fidelity prototype Testování pomocí Low fidelity prototype se využívá hlavně v raných fázích vývoje aplikace, kdy ještě není hotový design aplikace, ale je zapotřebí otestovat, zda bude vymyšlené uživatelské rozhraní budoucím uživatelům vyhovovat. Velmi často se k tomuto typu 35

52 36 KAPITOLA 6. TESTOVÁNÍ testování používá pouze papír, na kterém jsou předem připravené jednotlivé obrazovky systému. Podle toho jak se uživatel rozhodne, mění moderátor testu jednotlivé obrazovky. Před zahájením programování celé aplikace byl vytvořený low fidelity prototype. S tímto prototypem bylo provedeno několik diskuzí s lidmi s oboru gastronomie a případnými zákazníky výsledného softwaru. Některé požadavky byly zakomponovány do návrhu aplikace a některé byly přesunuty do budoucí verze programu. Pro potřeby testu bylo vytvořeno celkem 5 scénářů. V další části kapitoly budou podrobně popsány scénáře jednotlivě. Úvodní obrazovka Na tomto scénáři se zobrazuje výběr jednotlivých rolí celého systému. Uživatel si v této fázi může zvolit, v jaké roli chce se systémem pracovat. Tento scénář dále dokáže zprostředkovat přihlášení zaměstnance na směnu. Role Vedoucí Scénář Vedoucí zobrazuje jednotlivé funkce této role. V rámci testu je možné si prakticky vyzkoušet v omezené míře veškeré funkcionality této role, jako je vytvoření nové kategorie pokrmů i nápojů, dále vytváření nových pokrmů a nápojů, společně s přiřazením surovin pro přípravu. Scénář dále zobrazuje veškerou funkcionalitu, kterou role umožňuje. Role Skladník Podobně jako předchozí scénář zobrazuje jednotlivé funkce role Vedoucí, tak i tento scénář zobrazuje jednotlivé funkce role Skladník. Scénář představuje jednotlivé obrazovky, se kterými bude tento uživatel pracovat. Role Číšník Tento scénář zprostředkovává jak bude vypadat role Číšník. V prvním kroku scénář zobrazuje seznam stolů v restauraci. Po výběru stolu se zobrazí detail konkrétního stolu. Na detailu se zobrazí podrobné informace o vybraném stolu, navigační tlačítka a celková cena objednaných položek. Dále se zobrazí jídelní lístek a v poslední části obrazovky se zobrazí seznam objednaných položek společně s cenou a stavem fáze přípravy, ve které momentálně jsou. Role Kuchař a Barman Poslední scénář zobrazuje společnou funkcionalitu pro dvě role v systému, a to pro roli Kuchař a Barman. Celá obrazovka je rozdělena do tří sloupců. V prvním sloupci se zobrazují položky se stavem objednáno, ve druhém sloupci se zobrazují položky ve stavu v přípravě a v posledním sloupci se zobrazují položky se stavem připraveno. Jednotlivé objednávky se rozdělují podle stolu, na kterém byla objednávka vytvořena, a u každé položky se také zobrazuje čas poslední změny stavu konkrétní položky. Celý test je zařazen jako příloha na konci textu práce.

53 6.1. KATEGORIE TESTŮ 37 Výsledky low-fidelity prototype testu Během testování bylo objeveno několik funkcí systému, které by v praxi práci se systémem spíše komplikovaly, a proto byly z návrhu systému odstraněny. Dále také byly, ve spolupráci s účastníky testu, do systému přidány, popřípadě editovány další funkce pro práci se systémem. Některé funkce byly zařazeny do další verze. Ze systému byly odebrány následující funkce. Uzamknutí stolu pouze pro konkrétního číšníka - v první verzi návrhu informačního systému plánování vytvořit zámek na konkrétní stůl pouze pro jednoho číšníka. Po diskuzi byla tato funkce označená za zbytečnou a komplikující práci číšníkům. Vytvoření objednávky surovin dle dodavatele - Skladník by mohl vytvářet opakující se objednávky dle dodavatele. S ohledem na možnou změnu ceny a také na veliký výběr dodavatelů by tato funkce byla zbytečná. Dále do systému byla přidána tato rozšíření Přidání stavu položek na objednávce - v první verzi návrhu systému měla položka na objednávce pouze tři stavy (objednáno, v přípravě, hotovo). Během testování vznikaly sporné situace, v jakém stavu je daná položka. Byly tedy přidány další stavy (vybráno, doručeno, zaplaceno a stornováno, pro lepší identifikaci a kontrolu objednané položky. Detail objednávky ve výpisu stolů - Při výpisu seznamu stolů se nejprve zobrazovalo číslo a kapacita stolu. Nebylo tedy na první pohled poznat zda má stůl vytvořenou objednávky. Na doporučení byl rozšířen popis stolu o informace vytvořené objednávky (cena, jméno zaměstnance a počet položek). Zůstává několik požadavků, které budou implementovány v další verzi. Vytváření přidružených skladů - Pro lepší fungování baru a kuchyně by se zaměstnancům hodilo mít některé suroviny na svém pracovišti. Zároveň je také potřeba aby i tyto suroviny byly pod kontrolou informačního systému. Řešením této situace je vytvoření vedlejších skladů a přesuny potřebných surovin z hlavního skladu do skladů přidružených. Počítání nákupní ceny suroviny - v současném řešení je pro všechny suroviny jednoho typu stanovena jedna konkrétní cena. Ceny se ale mohou v průběhu naskladňování surovin měnit. Bylo by dobré do systému přidat počítání průměrné nákupní ceny. Sledování trvanlivosti surovin - Ve skladu se vyskytují suroviny, které byly nakoupeny v rozdílném časovém horizontu. Systém by mohl toto sledovat a informovat skladníka o surovinách s končící lhůtou trvanlivosti.

54 38 KAPITOLA 6. TESTOVÁNÍ Testování hotového systému Pro toto testování se používají dvě základní metody. První metodou je kognitivní průchod. Zadavatel testu připraví několik scénářů na průchod jednotlivých částí. Hodnotí se, zda uživatel pochopil zadání úkolu, zda ví, jak má pokračovat, a na závěr, zda systém zobrazil výsledek úkolu (úspěch nebo neúspěch). Druhá metoda se jmenuje Heuristická evaluace. Heuristická evaluace obsahuje seznam pravidel, která by neměl testovaný software porušovat. 6.2 Postup testování Před zahájením testování se musí zajistit dostatečný počet lidí, kteří systém otestují. Pro výběr správných testerů 1 se používá screener 2. Korektně sestavený screener nesmí prozradit, o jaký produkt k testování se jedná, ale zároveň musí odhalit, že uživatel splňuje minimální požadavky pro zvládnutí testu. Skreener otázka možnosti požadovaný počet lidí [v %] Pracujete v oboru gastronomie? ANO / NE 50%, 50% Kolik Vám je let? do 25 / / / %, 35%, 45%, 10% Jak často chodíte do restaurace vůbec / občas / často 0%, 20%, 80% Pracujete na vedoucí pozici? ANO / NE 75%, 25% Tabulka 6.1: Screener pro výběr uživatelů k testování Vyhodnocením screeneru se provede výběr lidí, kteří mají potenciál software korektně otestovat. Před samotným zahájením testu je testerovi předložen tzv. pre-test 3. Po vyplnění pre-testu začíná samotný test uživatelského rozhraní. 1 Tester - osoba, která testuje zařízení, nebo software. 2 Screener - anonymní test nabídnutý velké množině potencionálních testerů. Po vyplnění testu se dle předem stanovených pravidel (pravidla určuje zadavatel testu) rozhodne, zda je tester pro náš test vhodný. 3 Pre-test - seznam otázek, které mají pomoci navodit příjemnou atmosféru testera s moderátorem testu.

55 6.2. POSTUP TESTOVÁNÍ 39 Test uživatelského rozhraní Test uživatelského rozhraní se skládá z několika předem připravených scénářů, které musí uživatel projít a v průběhu jednotlivé úkoly hodnotit. 1. Scénář - Vytvořte 3 nové uživatele. Prvnímu nastavte roli vedoucí, druhému kuchař a třetímu číšník. Po dokončení první části druhému uživateli změňte jméno a třetího uživatele vymažte. 2. Scénář - Vytvořte 5 surovin s libovolným množstvím na skladě. Dále vytvořte 4 nové položky. K vytvoření položek použijte Vámi vytvořené suroviny. Všechny nápoje přiřad te do jedné kategorie. Stejně tak všechny pokrmy do jedné kategorie. 3. Scénář - Vytvořte novou objednávku pokrmů a nápojů. Objednávku dokončete a zaplat te. 4. Scénář - Vytvořte novou objednávku surovin, kterou také dokončíte. 5. Scénář - Zapište u libovolného zaměstnance příchod do práce. Post-test Post-test slouží ke zhodnocení pocitů z testu, pro odlehčení atmosféry v případě, že testerovi se moc nedařilo. Po dokončení post-testu končí i celé testování s uživatelem.

56 40 KAPITOLA 6. TESTOVÁNÍ 6.3 Výsledky testování Výsledky testování s uživatelem jsou uvedeny v tabulce. Ke každému nálezu je uveden typ, který specifikuje vážnost nálezu. Uživatelské nálezy dělíme do 3 skupin (1 - kritická chyba, 2 - chyba, která nemá vliv na funkčnost, ale většině zákazníků působí komplikace, 3 - drobná chyba). Při testování s uživateli byly zjištěny následující nálezy: nález scénář skupina opraveno Při zadání velkého čísla do pole plat aplikace skončila chybou ANO - nastavení o- mezení pro délku čísla ve formuláři. Pokud je zadaná adresa, , telefon ve špatném poli a uživatel se přepne do jiné karty, formulář se neodešle, ale chybová hláška zůstane skrytá. Při zadání velkého počtu surovin při vytváření objednávky, nebo suroviny. Hodnota suroviny se zobrazí ve formátu exponentu - pouze u čísel větších než milion NE - Chyba bude opravena v další verzi. 3. a 4. 2 NE - Chyba bude opravena v další verzi. Tabulka 6.2: Nálezy testování aplikace s uživateli. Při testování aplikace s uživateli byly identifikovány nálezy sepsané v tabulce 6.2.

57 Kapitola 7 Závěr V této kapitole jsou shrnuty a ohodnoceny cíle a požadavky ze zadání celé práce. V následujícím odstavci jsou zmíněny jednotlivé body zadání. V implementaci jsou splněny všechny požadavky, které jsou uvedeny v zadání. Osobní cíle V úvodu celé práce jsem si stanovil několik osobních cílů, které mě podporovaly v osobní motivaci a díky kterým jsem si vybral jak téma této práce, tak i technologie, které byly při programování použity. Díky této práci jsem se naučil vytvářet aplikace na platformě Java EE s podporou aplikačního frameworku SpringMVC. Dále jsem si vyzkoušel práci s novými technologiemi Maven, grafický framework Bootstrap, databáze PostgreSQL, Apache Tiles. S některými technologiemi jsem se setkal i dříve, ale první praktickou zkušenost mám až díky bakalářské práci. Rešerše a porovnání systémů Komerční výrobky, se kterými se návrh porovnává v kapitole 3.6, mají sice některé nedostatky, ale jedná se o produkty, které jsou na českém trhu řadu let a stále na vývoji pracuje tým programátorů. Informační systém, který je předmětem této práce, je jistě konkurenceschopný komerčním řešením. Přínos práce Tato práce má velký potenciál a rozhodně by mohla být přínosná i pro komerční využití. Pokud půjde vše podle plánu, měl by být informační systém během letních prázdnin nasazen do ostrého provozu. 41

58 42 KAPITOLA 7. ZÁVĚR Rozšíření systému Informační systém by bylo možné rozšířit o další nové funkcionality. Implementováno by například mohlo být následující: Doprogramovat podporu pro používání dílčích skladů (samostatný sklad pro bar, kuchyň). Systém by dále mohl podporovat rozmístění stolů v restauraci, případně rozdělení stolů do více místností (například salonek, zahrádka atd.) Internetová rezervace stolu v restauraci. Podpora sociálních sítí. Informační systém by se mohl starat o automatické zobrazování akčních nabídek a denního menu na sociálních sítích. Rozšířit informační systém na mobilní zařízení (mobilní telefon, tablet). Objednávání surovin by se mohlo rozšířit o čtečku čárových kódů a umožnit zaměstnanci objednávat zboží pouhým přečtením kódu v obchodě.

59 Literatura [1] HEFFELFINGER, David R. Java EE 6 development with Netbeans 7: develop professional enterprise Java EE applications quickly and easily with this popular IDE. Birmingham, U.K.: Packt Open Source, 2011, iv, 374 p. Community experience distilled. ISBN [2] BURD, Barry. JSP: Javaserver pages, podrobný průvodce. Vyd. 1. Praha: Computer Press, 2003, 381 s. ISBN X. [3] ARLOW, Jim a Ila NEUSTADT. UML 2 a unifikovaný proces vývoje aplikací: objektově orientovaná analýza a návrh prakticky. Vyd. 1. Překlad Bogdan Kiszka. Brno: Computer Press, 2007, 567 s. ISBN [4] Entprice Java Bean. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, [cit ]. Dostupné z: <en.wikipedia.org/ wiki/enterprise_javabeans> [5] EXtensible Markup Language. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, [cit ]. Dostupné z: <en. wikipedia.org/wiki/xml> [6] Hibernate Quick Guide. In: Tutorials Point [obrázek]. Hibernate Quick Guide, 2014 [cit ]. Dostupné z: < architecture.jpg> [7] Informační systém. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, [cit ]. Dostupné z: <cs.wikipedia.org/ wiki/informační_systém> [8] Information System. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, [cit ]. Dostupné z: <en.wikipedia. org/wiki/information_system> [9] Java Message Service. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, [cit ]. Dostupné z: <en.wikipedia. org/wiki/java_message_service> [10] Overview of the Spring Framework. In: Overview of the Spring Framework [obrázek] [cit ]. Dostupné z: <docs.spring.io/spring/docs/3.1.0.m1/ spring-framework-reference/html/images/spring-overview.png> 43

60 44 LITERATURA [11] Simple Object Access Protocol. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, [cit ]. Dostupné z: <en. wikipedia.org/wiki/simple_object_access_protocol> [12] SQL. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, [cit ]. Dostupné z: <en.wikipedia.org/wiki/sql> [13] ABRA SOFTWARE A.S. ABRA Software a.s. [online] vyd [cit ]. Dostupné z: <abra.eu> [14] Apache Tiles [manual] [cit ]. Dostupné z: <tiles.apache.org/ framework/index.html> [15] APACHE. Apaneche Maven Project [manual]. 2014, [cit ]. Dostupné z: <maven.apache.org/what-is-maven.html> [16] DAVIS, Ziff. LLC. PCMAG DIGITAL GROUP. Application Frameworks: Specialized Application Frameworks [online] [cit ]. Dostupné z: < encyclopedia/term/37907/application-framework> [17] Git: [manual] [cit ]. Dostupné z: <git-scm.com/documentation> [18] MySQL: The world s most popular open source database [online] [cit ]. Dostupné z: < [19] UML [online] [cit ]. Dostupné z: < uml-navrh-systemu-pomoci-diagramu> [20] Apache Software Fondantion. Apache Software Fondantion [online] [cit ]. Dostupné z: < [21] Apache Tomcat. Apache Tomcat [online] [cit ]. Dostupné z: <http: //tomcat.apache.org/> [22] Application Framework. JANSSEN, Cory. Application Framework [online] [cit ]. Dostupné z: < application-framework> [23] Bootstrap. OTTO, Mark, Jacob THORNTON, Chris REBERT a Julian THILO. Bootstrap [online] [cit ]. Dostupné z: < [24] Co je aplikační server?. SKŘIVÁNEK, František. Databázový svět [online] [cit ]. Dostupné z: < > [25] Databázové modely. Databáze [online] [cit ]. Dostupné z: < [26] GlassFish Project Documentation Home Page. Glassfish [online] [cit ]. Dostupné z:

61 LITERATURA 45 [27] Hibernate Hibernate ORM documentation. Hibernate [online] [cit ]. Dostupné z: < [28] Hibernate Quick Guide. TUTORIALS POINT. Tutorials Point [online] [cit ]. Dostupné z: Hibernate Quick Guide [29] Java Platform, Enterprise Edition (Java EE) Technical Documentation: Java EE 7 Documentation. ORACLE. Java EE 7 Documentation [online] [cit ]. Dostupné z: < [30] LaTex. LaTex [online] [cit ]. Dostupné z: < org/wiki/latex/> [31] Microsft database. MICROSFT. Microsft database [online] [cit ]. Dostupné z: < [32] PHP: Hyper Text Protocol. PHP [online] [cit ]. Dostupné z: <http: // [33] PostfreSQL. PostfreSQL [online] [cit ]. Dostupné z: < // [34] Spring Framework: Reference Documentation. Reference Documentation [online] [cit ]. Dostupné z: < M1/spring-framework-reference/html> [35] Spring Framework. Tutorials Point [online] [cit ]. Dostupné z: <http: // [36] SQLite. SQLite [manual] [cit ]. Dostupné z: < org/> [37] XML Tutorial. XML Tutorial [online] [cit ]. Dostupné z: < [38] Informační systémy pro firmy všech velikostí. ABRA a.s. [obrázek] [cit ]. Dostupné z: < 6b830c27-cba8-11e3-90a d09270b-comp.png> [39] Pokladní systémy VIRTUOS pro restaurace a hotely. TCP.cz [obrázek] [cit ]. Dostupné z: < kasa.jpg> [40] Vectron. Vectron [obrázek] [cit ]. Dostupné z: < pic/vcom2/vcoml.jpg> [41] Vectron. Vectron [obrázek] [cit ]. Dostupné z: < pic/hotel/pokoj_l.jpg> [42] Vectron. Vectron [obrázek] [cit ]. Dostupné z: < pic/sklad/receptyl.jpg>

62 46 LITERATURA [43] Vectron. Vectron [obrázek] [cit ]. Dostupné z: < pic/vcom2/vcom_vykazy_l.jpg> [44] Vectron Systems CZ s r.o. In: Vectron Systems CZ s r.o. [online] [cit ]. Dostupné z: < [45] TPC spol. s r.o. [online] [cit ]. Dostupné z: <

63 Příloha A Seznam použitých zkratek Klient-Server - Softwarová architektura. MySQL - typ databáze. MSSQL - typ databáze. EJB - Enteprise Java Bean. Serverově řízená komponenta pro správu modulární vytváření aplikací. JMS - Java Message Servtice. Služba umožňující posílání zpráv mezi klienty. XML - extensible Markup Language. Univerzální značkovací jazyk. SOAP - Simple Object Acces Protokol. Jednoduchý protokol. pro komunikaci mezi dvěma aplikacemi. JSP - Java Server Pages. Skriptovací jazyk pro. Java EE - Java Enterprise Edition. Platforma pro vytváření. webových a podnikových aplikací. UML - Unifite Markup Language. PHP - Hypertext Preprocessor. LAMP - Linux, Apache, MySql, PHP. JSF - Java Server Faces. HQL - Hibernate Query Language. JPQL - Java Persistence Query Language. JPA - Java Persistence API. MVC - Model View Controller - Typ softwarové architektury. 47

64 48 PŘÍLOHA A. SEZNAM POUŽITÝCH ZKRATEK

65 Příloha B Obsah přiloženého CD -- readme.txt - tento text -- install.txt - postup instalace aplikace -- ris.war - zkompilovaná aplikace -- vichpetr-thesis-2014.pdf - text práce v PDF -- formular.pdf - prázdný formulář pro průzkum existujících řešení -- Apache Tomcat - aplikační server -- apidocs - dokumentace zdrojových kódů -- low-fidelity prototype - adresář se soubory k low-fidelity prototype testu -- text - adresář s textem práce -- figures - adresář s obrázky k práci -- Hron-thesis-2009.tex - text BP v TEX -- ris - zdrojové kódy (Netbeans project) 49

66 50 PŘÍLOHA B. OBSAH PŘILOŽENÉHO CD

67 Příloha C Návrh uživatelského prostředí Obrázek C.1: Návrh uživatelské rozhraní - seznam zaměstnanců Obrázek C.2: Návrh uživatelské rozhraní - detail pokrmu/nápoje 51

68 52 PŘÍLOHA C. NÁVRH UŽIVATELSKÉHO PROSTŘEDÍ Obrázek C.3: Návrh uživatelské rozhraní - seznam stolů v restauraci Obrázek C.4: Návrh uživatelské rozhraní - seznam stolů v restauraci

69 Obrázek C.5: Návrh uživatelské rozhraní - seznam stolů v restauraci 53

70 54 PŘÍLOHA C. NÁVRH UŽIVATELSKÉHO PROSTŘEDÍ

71 Příloha D UML diagramy Obrázek D.1: Diagram aktivit - Objednávka a dodávka pokrmu a nápoje Obrázek D.2: Stavový diagram - Objednávka od zákazníka 55

72 56 PŘÍLOHA D. UML DIAGRAMY Obrázek D.3: Diagram případů užití - Správa systému

73 Obrázek D.4: Domnévý model 57

74 58 PŘÍLOHA D. UML DIAGRAMY Obrázek D.5: Diagram Analytický model